I just ordered a Framework yesterday. I'm not interested in the 12th gen chip, but is there any other reason I might want to cancel & re-order today? i.e. would I be getting an older design?
If you want to play with this data, it's available in various formats [1]
I happened to use this last week because we needed test data for a community tree in an app we're building. There are nine communities, and we needed test cases with 0, 1, and many subcommunities. This not only provided ready test cases, but the team is learning celestial facts while working on the feature!
Edit: some dead links there. This "bootstrap" directory contains the custom tangler and the custom rule processor. This 10K, plus the tiny configs in the root, are the only code in the project not in documents.
I used it on a project with many thousands of files and hundreds of (mostly dynamic) build rules. This was a literate program, and most build steps required the extraction of code from the source docs --- including build rules themselves --- and I still maintained sub-second updates.
This kind of as-you-type evaluator is extremely valuable to me. I've written a few tools to support this in emacs, and I use the JS one all the time.[0]
I also wrote one for Graphviz (which outputs to an SVG buffer), and sometimes I'll put the output from the JS playground in `play-graphviz` mode so I can see real-time graph output from JS (by writing code to print dot graphs). ATM I don't know any other tools that can do that sort of thing, let alone compose independent ones to that end. Long live Emacs!
[0] https://bitbucket.org/gavinpc/play-modes/src/default/js-play... (There is an odd bug in OSX where the first character of the input is eaten, so I always begin these "playgrounds" with "/// playing with <whatever>". There are some other oddities which I should document.)
At least "Bomb" would be short. "Full Metal Jacket" is a dreadful name in every sense, worsened only by the author's cringeworthy backstory. To paraphrase the parent, it reeks of immaturity.
I "wouldn't hold that against" the tool if it had technical merit.
> When have you ever had to unnecessarily break API compatibility because something you thought was an Option[T] result turned out to be really a T, always?
That would be a breaking change. And should be, if you're into that sort of thing.
The objection is to the opposite case: What was a T is now an Option[T]. I don't know Scala specifically, but that's a breaking change in every typechecked language I know. Rich is arguing that it shouldn't be. But it could be possible even in typed languages through union types. For example, you can do this in TypeScript by changing T to T | undefined, which is a superset of T.
But, although my current manager is excellent at supporting his team and would never think such a thing, let alone say it, the truth is that, unless you're a professional researcher, you really do have to do the hammock-driven thing on your own time, either by working it into your routine or by taking a long sabbatical (as Rich did). It's something I struggle with, even at a very good workplace.
"Nothing is more precious" than the chance to think through a problem over a long term, and as things stand, the best tool for thinking is still the mind, not the keyboard. I can see how that takes a leap of faith when your chief deliverable is code.
Anyway, maybe a better introduction for your typical manager is,
> The most expensive problems are problems of misconception.
It takes one to know one. (Or so I would like to think.)
Rich's writing, presentations, and example of overall conceptual discipline and maturity have helped me focus on the essentials in ways that I could not overstate. I'm glad (but not surprised) to see so much appreciation for him around here, even among non-Clojurists (like myself).
At the risk of fanboyism, I am constantly referencing his ideas* to my team, and I give them my blessing to watch any of his talks as soon as they come out.
* That is, the old but sometimes obscure ideas whose importance he's brought to his audience.
Same (from my uncle, who then worked at Martin Marietta on the shuttle tankers).
While I enjoyed reading through them and learned a number of concepts, his books helped demonstrate that I was not going to become an electrical engineer. I just didn't know what to do with it. Whereas, I was exposed to programming books at the same time (starting with David A. Lien) and was like a fish in water.
Also, RIP Radio Shack, though it was really a slow death by degrees.
Which leads to this link: https://groups.google.com/g/clojure/c/OnagUrQZ1NE/m/Uwm8fvak...
Where Rich comments on the thinking behind this.
Also see https://clojure.org/reference/lisps , which compares Clojure with other Lisp dialects on this and other points