Code Quarterly

Here is my brief review of the articles as a whole. As a little background, I've been writing Lisp professionally for a while at many companies, both start ups and top-tier tech companies. I like writing about Lisp[1], and have been so far as to write blog posts ranging from why parentheses are a good thing to what kinds of data types Common Lisp has. I think there is still a place for writing about Lisp, but I don't think this e-zine accomplished the task to make it interesting. Lisp unfortunately attracts a lot of fluff writing. Writing about how wonderful, deep, rich, or sophisticated it is. Writing about how it completely blows one's mind and takes you to this baroque, fluid land of programming literacy. I must admit that I've even been sucked into the vortex at a point in my Lisp career. Then there are particular topics that get rehashed over and over again: what makes a Lisp? which is the best Lisp? which is the most practical? lisp-1 vs. lisp-2? was r6rs a failure? why are macros so great? why does Lisp subsume every programming language ever? I found in this e-zine—whose title I can't repeat without bloating the paragraphs I write—that I didn't really gain anything after reading it all. What did I learn about T? I just learned that it was some language with interesting concepts, backed up with a paltry offering of examples. What did I learn about Apple? To me, it seemed like an opinion: Since Apple isn't doing wacky Lisp things, it no longer is catering to those…

I don't know if someone has already cited this lengthy interview to Hal Abelson (co-author of SICP) about this change, but I think it is worthy to point it out: http://www.codequarterly.com/2011/hal-abelson/

Speaking as someone who's been following the project for a few years and once actually bothered to learn Hoon, your first paragraph is probably the best criticism of Urbit I've seen. I do think there is an interesting system buried under all the obfuscation, but the uncritical groupthink within its user base is obnoxious. I kind of doubt "produce a vanguard of true believers" is a primary goal of the project, but Yarvin doesn't really seem to discourage that behavior either. That said, the old "it's just typical Moldbug" trope isn't much better than the propaganda his followers spout, and the rest is pretty weak too. AFAIK, the Urbit term for "file" is "file". I don't know which funny weird name you're thinking of for "network endpoint", as that's not really a separate concept in the system. Hoon's cores (which I assume you're at least passingly familiar with) are pretty distinct from closures in any language I know... I mean, do you also complain that Java uses the word "object"? (Forgive me if I omit the part where I ascribe sinister motives to the creators of Java due to their choice of vocabulary.) As for "implementations of well-known computer science concepts", cue Rich Hickey[1]: > It's interesting, because Clojure provides almost nothing you can’t find somewhere else. But I do think it occupies an otherwise empty spot in the multidimensional space of language features and capabilities. In other words, even if your claim is true, it describes almost every project…

> So what is really needed is a startup culture that provides for years of uninterrupted development and focus. Not just startups, but any worthwhile project really. From an interview with Rich Hickey: "I started [Clojure] while on a sabbatical I had given myself. Not a break from work, but a break to work, as a completely free person. I gave myself leave to do whatever I thought was right, with no regard for what others might think, nor any motivation to profit. In releasing it, I had the normal expectations for a new language—that ten to a hundred people might use it. Maybe I would get some help or code contributions. It has taken off, and subsequently demanded far more time than the sabbatical I planned. So, I’m trying to recoup some of the investment I’ve made. Had it been a financially motivated undertaking, I’m sure Clojure would not exist, but I don’t regret having invested in it." http://codequarterly.com/2011/rich-hickey/

It depends on the person. Does writing tests help you understand the problem, and if so, does that help you solve it faster? Only you can answer that. Here's a quote from Rich Hickey that really struck home with me: > I never spoke out 'against' TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design. (http://www.codequarterly.com/2011/rich-hickey/) Another question to ask is does this help others understand the problem? You often don't write tests for yourself, but for other people, including the later you that has popped the problem off the mental stack long ago. Writing tests might lose you time right now, but the net gain of time saved by others may make up for it. Let me emphasize the word "may", because you might make the problem clearer by writing documentation in English rather than code. So the only conclusion…

This comment should not be [dead] (if you don't want to give/dock me karma for irahul's comment, down-/upvote my reply to this comment): irahul 7 hours ago | link [dead] > For example, Rich Hickey, the author of Clojure, said recently at the Strange Loop conference "We say, “I can make a change because I have tests.” Who does that? Who drives their car around banging into the guard rails!?" Rich has spoken about it other time with an interview with Fogus: http://www.codequarterly.com/2011/rich-hickey/ Hickey: I never spoke out ‘against’ TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design. He said something on the similar lines about development on CLR: Fogus: Clojure was once in parallel development on both the JVM and the CLR, why did you eventually decide to focus in on the former? Hickey: I got tired of…

Hal Abelson on the end of SICP at MIT (2011) http://codequarterly.com/2011/hal-abelson/

Naturally, other Lisps have advantages over Clojure, but here's a few advantages of Clojure. You might also want to check out this interview: (http://codequarterly.com/2011/rich-hickey/) * Enormous reach: access to both Java and Javascript ecosystems. (If you count ClojureScript. I don't know how Clojure CLR for .NET). * Immutability by default. When you want state, its primitives help with concurrency. * A good set of basic data structures, including lazy sequences.

Rich Hickey created the Clojure programming language and he has the same background as you. In school, he focused on music, and his creative energy was directed at music composition. There is a mountain of anecdotal evidence suggesting a link between the type of mind that creates music and the type of mind that creates software. After school Hickey got a job at a music studio, and it was there that he first encountered computers. See here: http://www.codequarterly.com/2011/rich-hickey/ Fogus: What drew you to programming? Hickey: I was running a recording studio and got a computer for it. I was intrigued by what it could do—this was in the relatively early days of MIDI—and filled with the possibilities of what it might do. So I taught myself C and assembly language and started writing music software. I was immediately hooked.

> Inference : ClojureCLR seems to be dead :( For at least a few years now. I remember watching a Hickey talk where I think I recall him saying it was even before 2011, but the exact name escapes me at the moment. However, I was able to find this snippet from 2011: Fogus: Clojure was once in parallel development on both the JVM and the CLR, why did you eventually decide to focus in on the former? Hickey: I got tired of doing everything twice, and wanted instead to do twice as much. http://codequarterly.com/2011/rich-hickey/

Hal Abelson talks about those examples in this interview: http://www.codequarterly.com/2011/hal-abelson/ . The students who were taking 6.001 had just had a course in calculus the previous semester, so the math in the examples would be fresh in their minds.

See also: http://www.codequarterly.com/2011/hal-abelson/ The change wasn't the primary subject of that interview but Seibel is a Lisper so he was clearly interested in hearing about it and asks some interesting questions about it.

You might find this recent interview with Abelson to be interesting, esp with respect to the history of SICP at MIT: http://www.codequarterly.com/2011/hal-abelson/

I don't know what, if anything, is going on at Berkeley, but Hal Abelson talked quite a bit about the switch from SICP to a different intro course at MIT when I interviewed him for Code Quarterly http://www.codequarterly.com/2011/hal-abelson/ and it wasn't about abandoning Scheme or "not teaching core computer science". (Well, maybe a bit less core computer science in the intro course but that was basically so that CS people could have more time later for CS without all that annoying EE stuff. And vice versa.)

One of my favorite resources is the #clojure tag on Twitter. I use Tweetie and have bookmarked a search on that. Here are a few sites from my GReader http://www.bestinclass.dk/blog.html http://nakkaya.com/ http://freegeek.in/blog/ https://groups.google.com/group/clojure And here are a few tabs that I currently have open (Maybe this weekend I will get to them :D) https://github.com/dbushenko/ClojureBlog http://skillsmatter.com/podcast/scala/talk-by-patrick-fredriksson http://brehaut.net/blog/2011/ring_introduction http://www.codequarterly.com/2011/rich-hickey/ (Interview with Rich) http://news.ycombinator.com/item?id=2682191 http://news.ycombinator.com/item?id=2709319 Hope these help :)

That's precisely the problem. Many in the rails community do use it as a substitute for thinking. In general, I'm not the biggest DHH supporter (although, he's made me a ton of money, indirectly, via rails), but I do like that he's stirring the pot here. Back in the 90s and early 2000s, I wrote tests, when needed. Sometimes before application code, sometimes after, it was a discretionary tool that I had in my arsenal that helped me both solve problems and feel confident that "my code won't break". At some point in time the majority of the rails community decided that if you don't test, you're a terrible programmer. Full Stop. The problem with this was that testing tools were terrible at the time, RSpec, before it's API solidified was breaking every other release, things like capybara and selenium and watir, always kinda worked, but not really, and you'd often spend 10 minutes writing the business logic, and then 40 minutes writing tests, getting them to pass, wrestling with external dependencies, etc. Furthermore, because people were practicing test-based application design, you were constantly re-writing your codebase and your test suite, because if you're designing for tests, you're not designing for the domain, and as domain requirements changed, and broke your testing model, you basically had to fix everything, and you couldn't get a handle on the domain because you had to be ruled by tests. All that said, I do think tests are useful. TDD isn't as useful for…

I happened to read this interview (http://www.codequarterly.com/2011/rich-hickey) with Rich Hickey today which I'm sure has been posted here before. I mention this because of this statement: > When we drop down to the algorithm level, I think OO can seriously thwart reuse. In particular, the use of objects to represent simple informational data is almost criminal in its generation of per-piece-of-information micro-languages, i.e. the class methods, versus far more powerful, declarative, and generic methods like relational algebra. Inventing a class with its own interface to hold a piece of information is like inventing a new language to write every short story. This is anti-reuse, and, I think, results in an explosion of code in typical OO applications. Clojure eschews this and instead advocates a simple associative model for information. With it, one can write algorithms that can be reused across information types.

Making your code public is a good exercise in taking the criticism of others, and learning which type of criticism you can easily discard. My GitHub page is far from impressive, it's mainly a collection of project that I think are fun to work on, or things I like to play around with in my spare time. Still, I make half-baked things public because I'm hoping someone will come along and offer feedback. In terms of negative feedback, I refer you to this interview with Rich Hickey. http://www.codequarterly.com/2011/rich-hickey/ Here's the section I'm thinking of. Fogus: What would you say to people who claim that Clojure is not a “real Lisp”? Hickey: Life is too short to spend time on such people. So even the creator of a programming language (not trivial to implement!) has to field a fair amount of flak from nay-sayers. So if you're inspired to write something, put it out there. The worst thing that can happen is that someone will offer to help. The people tearing it down are spending their lives criticizing rather than creating.

I am in a similar situation to the author of this article: learning to program after having having tried and given up ages ago. I believe the problem lies in trying to learn a complex language from the bottom up. In the OP's words: "Recently I took on the enormous task of learning Objective-C from the bottom up and I was struck by something I couldn’t shake: this is too hard." I believe one must consider the top-down approach: figure out what you want to do accomplish first, paint the solution in broad strokes, then fill in the details. Hal Abelson touched on this in a recent interview: "there also really are people who like to understand stuff bottom-up. It’s not to my taste. To my taste the most important thing is the idea that you build on abstraction." http://www.codequarterly.com/2011/hal-abelson/. Get over your discomfort not knowing every detail before the fact, consider what the solution to your task might be and try it. For a non computer example: you meet a French girl who you want to get to know her better. You could drown yourself in learning the intricacies of French grammar, pronunciation, spelling, etc.. or you could muster your courage and engage in simple dialogue of the 'me- Tarzan you- Jane' type. Might work and you could fill in the details later.