Rich Hickey:
We focus on ourselves ... rather than [on] the programs.
Software should be made of simple components because it makes the software better, not because it makes it easier for us as developers.
Doug Crockford about developing JSON:
One interesting story about leaving things out: as we got closer to releasing JSON I decided to take out the ability to do comments. When translating JSON into other languages, often times the commenting piece was the most complicated part. By taking the commenting out we reduced the complexity of the parsers by half—everything else was just too simple.
I have wondered about why comments are not part of JSON. Now it makes sense.
One of the best features of JSON is that it’s stable. If your program works now, it will work forever, and that is an attractive thing.
Yum. He has found a reasonable data structure format that could indeed last forever.
I still get notes from people saying they’ve got great ideas for the next version. But there isn’t going to be a next version. I always say you’re free to invent a new standard and promote it as much as you like.
This morning, in the Clojure Gazette, I mentioned that Clojure was still looking for the "vital point" of the browser. Could this library hit that vital point?
Get ready for major fundage.
A well-chosen and well-designed reference explaining how to convert Javascript to Clojurescript.
A good talk by Miško Hevery. I like his point that he likes constructors that have no logic. They simply assign data values passed to them to the appropriate fields instead of doing a lot of reasoning about the values. He likes to decomplect the logic from the data, and claims that it makes code more testable.
It reminds me of Clojure, where data values are typically built using literal maps. Clojure encourages a separation between logic and data construction and generally avoids this problem which is common in Java.
Just what I needed. Clojure is developing faster than I can keep up. But we need to come up with better names for libraries.
I really like style guides.
Avi Flax reviewing Clojure Programming:
The writing, examples, and organization are all excellent. And the book gets extra points for going beyond just explaining the language and how to use it, by being extra-comprehensive and covering how to really use the full Clojure ecosystem to build really useful software.
This is worth highlighting: if the book had been comprised of only chapter 1, “Down the Rabbit Hole”, and the first 2 parts, “Functional Programming and Concurrency” and “Building Abstractions”, it would have been an excellent book which I’d be recommending wholeheartedly. The inclusion of the subsequent parts, “Tools, Platform, and Projects”, “Practicums”, and “Miscellanea” make the book an invaluable resource and a fantastic value.
I will have to get it.
Daniel Spiewak:
... a "pluggable" type system is really not very useful unless you can compose multiple type systems into a coherant whole, and this is where problems arise. Anyone who has studied type theory in a formal context and run a few soundness proofs will understand that seemly innocuous and self-contained type rules will almost always interact in surprising ways.
This is certainly true if you are enforcing a strict type discipline on your language and rejecting programs that do not comply with this discipline, as type systems do. But it has yet to be shown that useful static analysis parts cannot be composed. They merely provide information, so they may be able to work orthogonally.
By and large though, I think that most of the awesome bullet-points that Clojure hits have already been stolen whole-sale by Scala. :-) A few examples: vector, map/set, agents (in Akka), STM (in Scala STM), SLIME (see ENSIME), etc. The Scala community is very actively watching the Clojure community. Y'all are a very fertile source of inspiration!
