Clojure Gazette 1.76
Pyramids, Hypermedia, and Clojure-land
Clojure Gazette
Issue 1.76May 18, 2014
Editorial
Hi Clojurites!
You will notice something new in each link this week. There is now a link to a discussion for each page. (Note: Now defunct.) is the best place to talk about functional programming or talk about anything with functional programmers. Come participate in the discussions!
Enjoy the issue.
Sincerely,
Eric Normand
PS Have a suggestion for the Gazette? Just reply to this email!
Software Talks for the Ages
It may come as no surprise, but I watch, read, and listen to lots of stuff online. The main reason to start the Gazette was to share the great stuff I found. At first, I was a little skeptical that what I was sharing could be new to people. I like sharing classics, which are the most likely to be known.
However, there will always be an audience for great content, no matter how old. It may be new to you, or it may be worth rewatching. It's probably better than most of the new stuff out there, anyway. Peter Christensen has put together a list of his favorite talks, with a similar sentiment.
David Lorge Parnas Keynote at OOPSLA 2007
When I first heard about David Parnas's work, I was a little skeptical. It sounds so much like waterfall and lots of work that I just don't have the energy to do. But the more I work in software engineering, the more I believe that specs and precise documentation is a great way to force you to think. Read these slides to see a summary of his process to create complete specs.
Parnas's idea of tabular expressions is a huge step forward for software engineering. Civil engineers have blueprints and plans. They are understandable by the builders, the customer, and anyone else involved in the project. We need that kind of document that all of the stakeholders in a software project can understand.
Although I'm increasingly a fan of this kind of thing, I also like an opposing view. If an engineer produces documents for a builder to follow to build the product, who are the engineers writing documents? What are the documents? Who are the builders? What is the product? In the waterfall model, the system architects write specs, which are passed to the programmers who build a program. Glenn Vanderburg claims that the programmers are the engineers, their program is the document, the compiler is the builder, and the product is the complied software. His talk has a pretty sophisticated argument.
Hypermedia APIs with Steve Klabnik (JavaScript Jabber)
REST is one of those things that seems to be used only to say what is not REST. That's probably because people call things REST without understanding what it means. Then people correct them---"REST is not CRUD", "REST is not JSON", "REST is not concatenating strings into URLs"---and REST comes off looking like it's negative.
While there is a lot of "that's not REST" in this podcast, it also includes a lot of "this *is* REST". It's a hard concept to explain. But this podcast is the best short description I've heard. I recommend it to you. Afterward, you'll be saying "that's not REST" yourself.
Distributed Systems and the End of the API
I often find myself designing systems in my head, only to realize too late that the communication required between the parts would not work. Complex syncing, peer-to-peer topologies, or some other difficult pattern.
But why is it difficult? It's only difficult because most of our tools are made to build Client/Server applications, which is just one of many possible configurations.
Chas Emerick has been working on a new project called Quilt . While it's still somewhat secretive, it is obviously about facilitating distributed systems without traditional APIs. This post is a great introduction to the history of the API and a beginning of a way forward.
Elm: Concurrent FRP for Functional GUIs
I recently read Evan Czaplicki's thesis about Elm. It is extremely readable and adds a lot to the state of the art of Functional Reactive Programming. I don't know if I'll ever use Elm myself, but Functional Reactive Programming is definitely in my future. The 40-line Mario demo is reassuring that Elm is onto something. There's lots of possibilities there.
CrossClj
An interesting tool to explore the interdependencies of Clojure libraries.
Social Programming a Pyramid
I was actually at OOPSLA back in 2008 when this talk was given, but I missed it. I found it last week and, well, it's a great talk about how labor was organized to build the pyramids.
What struck me most is that the structure of the pyramids was so ad hoc, while the process of construction and organization evolved so rapidly. It reminds me a lot of people developing processes, managing scrums, and defining best practices, all to organize labor to brute-force a solution. Where is the architecture process?
[DISCUSS](http://discuss.purelyfunctional.tv /t/social-programming-a-pyramid/36)
A Rubyist in Clojure-land
I don't know Ruby, but I do know that learning multiple languages has a profound effect on your code in any language. David Chelimsky shows how learning Clojure helped him refactor some Ruby code to be shorter, clearer, and faster.
