|Issue 242 – September 11, 2017|
If you haven’t heard, Dr. Gerald Jay Sussman, co-author of Structure and Interpretation of Computer Programs, will be speaking at Clojure SYNC in New Orleans. We will be very honored by his presence. I’ve announced two other speakers as well. Emily Ashley will be speaking about resolving inconsistencies between formal models and users’ informal mental models. And Zach Tellman will be talking about what he learns in the research for his book Elements of Clojure. There are more speakers lined up, but you’ll have to wait in intense anticipation.
Please get your tickets soon and start to research travel. If you are undecided, what would convince you to come? And if you haven’t bought your tickets yet, what are you waiting for? I’d love to hear where you’re at. As always, just hit reply.
There are still speaking spots left. I’m especially looking to fill them with people who are underrepresented in the industry. Our industry has a shameful and increasing trend of white male members. I’ve already got three white males on the roster, so I’m not reaching out to any more. Please let me know if there’s someone you know who would like to speak (including yourself) that you’d be willing to introduce me to. Personal connection seems to be the best way to sign someone up. Thanks!
Please enjoy the issue.
PS Want to get this in your email? Subscribe!
A quick and interesting look at how Ward Cunningham and other eXtreme Programming pioneers were inspired by Christopher Alexander to make software that improves the world. How far “Agile” has veered from that vision.
A short take by Peter Norvig on a study done showing that Common Lisp and Scheme faired very well against Java and C++ (and other language) in terms of time to develop, length of program, and even performance. Not surprisingly, Norvig did very well when using Lisp. But I’d love to see him try it again with Java to compare not only apples to apples, but Red Delicious to Red Delicious. Wouldn’t it be fun to do this with Clojure?
This is a recent talk by Gerald Jay Sussman talking about his current line of research. He’s concerned with programming systems that don’t get us caught in corners where we have to start over to make progress. We should be sacrificing some performance for this feature. I’m expecting him to be speaking about something like this at Clojure SYNC. I think this topic is vitally important. We can’t possibly have found the best way to compute. We need to be thinking about the future.
A Philip Wadler paper from 1985. I like it for a few reasons. One is it’s very clear, unassuming, and humble. Two is it publishes a functional programming technique (“Design Pattern”??) and we don’t see enough of that. And three is that it is perhaps the best exposition of a parser combinator I’ve ever seen. I recommend it highly.
A great book about how to measure things traditionally deemed unmeasurable. It has a very good description of what it means to measure, why we measure, and how to measure. We measure to decrease error and we can never decrease it to zero. It talks about how to estimate whether the cost of measuring will outweigh the benefit of decreased error. It addresses how small samples might not be good enough for scientific proof, but they’re plenty good for business or life decisions. The end got a little too technical for my casual reading, but it could serve as a good reference of techniques when I need them. This book is good for anyone who needs to show measurable results.
Bozhidar Batsov lovingly critiques Clojure Documentation. Though his pronouncements might seem harsh, I believe he is right: our documentation is not great. I appreciate at the end his plea for us, as a community, to take it upon ourselves to make it better.
A description of the Jane Street development style by Yaron Minsky.
A nice article by Elena (sorry, I can’t find her last name). It’s a deceptively simple topic. Perhaps because I had been listening to talks by Barbara Liskov who practically invented modularity in software, I’m sensitized to see good explanations of it. This stuff might seem obvious now, but this, like most things in computing, had to be invented. This is a great explanation of it with very practical examples.
Metaphors We Compute By YouTube
A greaty talk by Alvaro Videla about how the metaphors we use shape how we think of problems and hence guide our solutions. It’s a very important topic for us since we deal with such abstract objects in our work. We can’t communicate these abstract ideas without metaphor, so we should choose our metaphors wisely.