PBT is awesome but I would still like to have tests I can easily reason about when implementing a tricky algorithm. The way I see it, TDD is the specification, PBT is for finding gaps in my specification.
> I'd have to look up what the "/" in "M/L" means in the 5th reply (I didn't)
M/L means that M is a field-extension over L. A concrete example would be C/R (the complex numbers over the reals).
Algebraic number theory, in particular Galois theory, studies field extensions by looking at the group of symmetries: the field automorphisms of the larger field that fix the smaller field. For the concrete example above, the Galois group is a group with two elements: the identity function and the function that maps i to -i and keeps real numbers fixed. It's not a coincidence that the dimension of C as an R-vector space is the same as the size of this group (or that the degree of the polynomial that has i (and -i) as roots has degree 2).
To add to that my current struggle: Most stuff is geared towards conda and terrible engineering practices (requirements.txt and not even locked versions). If you want to actually build and deploy something on actual hardware, you are in a world of hurt. And even for training the dependency situation is so ridiculous that most repos come with their own Dockerfile.
I marvel at the cool machine learning demos but I'm kind of sick working on this stuff, tbh.
* Frequent feedback from stakeholders and customers
* Retrospectives
* Standups
These can be annoying but they help make sure that the right thing is developed.
Things I don't like:
* Things get rushed to get them done before the sprint ends (even if there is no deadline pressure)
* On the other hand, everything takes at least two weeks to get done
I feel that this turns the output of a very high-performing developer into that of a mediocre developer. I'm not a 10x developer, so I can cope. ;)
Things I don't like but don't blame on Scrum:
* Jira
* Storypoints
* Estimating: All estimates beyond the current sprint are completely unreliable. Still, people use storypoints to derive release dates and worse, measure the productivity of employees using them.
FWIW, until I learn of better processes, I prefer Scrum without "buts" and with continuous deployment.
From the FAQ, I don't get why the code has to be GPL licensed. It talks about libraries, "entire combinations", "software modules that link" and "work as a whole".
On your second point: Can't they argue that they implement against an API, which could be provided by non-GPL software as well?