A possibility I haven't seen mentioned is that the style guide of their employer, together with a few employers who pay out-sized salaries (Google, Amazon, Facebook...) could account for the difference.
Around 2006-2007, I TAed a course at Cornell (CS212 I think?) that did exactly this. Three other TAs and I basically got to fork the course. We did a bunch of R&D into tooling and taught a small group of interested and motivated students how to build a non-trivial piece of software from start to finish. I think it worked out very well.
> Eve is our way of bringing the power of computation to everyone, not by making everyone a programmer but by finding a better way for us to interact with computers. On the surface, Eve is an environment a little like Excel that allows you to "program" simply by moving columns and rows around in tables. Under the covers it's a powerful database, a temporal logic language, and a flexible IDE that allows you to build anything from a simple website to complex algorithms.
1. Modern programming tools have a decades-long head start
2. Why denigrate group ware?
While this may not succeed, I have little reason to believe future improvements will all be evolutionary (I know you hedged there, saying "probably"). A lot can be learned from shedding assumptions. If the result of the project is inspiration for building tools on top of traditional programming models, the originators may be disappointed, but I'd call that success in basic research.
There are many ways to continue to extend the `Distance` type, and many other types that can be constructed in the same fashion. Each extension should be considered in the context of the code base it's going to operate in. For example, it's not difficult to create a new protocol, some generic functions with type constraints, and end up with an `Area` type with a fully correct relationship to `Distance`. I may write about such extensions as I continue to explore this space.
Factoring out a common constructor in tests is an example of making the tests resilient against changes in the underlying code. If the constructor changes, the tests need to be fixed in one place, not in 50.
Other examples may be around a `setup` method. If the method is private, don't test it. Then you can refactor freely. If it's public, test the pre/post conditions around the method in as few places as possible (hopefully one). Even if other tests rely on the object having been "setup", just trust that it works. If the specification of `setup` changes, you just have the `setup` tests to update, not the entire object.
I wrote an app that takes aspects of this to the next level, especially the cases where they recommend when to use it.
In my app, you capture a full window instead of a portion of the screen. Then the snapshot is continually updated. It's not for saving, just for cross-reference really. Though it also works really well in presentations and demos.
I'll add two points that I think are more important than any that have been mentioned so far.
1) A good API is hard to misuse.
– Documentation is great, but what's even better is when the naming conventions and responses from the API are so well named and their purposes are so obvious, that it's hard to misuse.
2) A good API is helpful and informative when you've misused it.
– Sent in an invalid key? The response should say so, and not just return an anonymous error. Is your request missing a required header field? A required parameter? An incorrect type for a parameter? Unused parameters? Yes, good documentation can help with these issues. But one of my biggest problems with documentation is that you can't look up what you don't know you need to look up (especially when there aren't any good tutorials).
https://developer.apple.com/news/?id=06282017b