This is the first post of my new BlogBook, Programming Wisdom.
This initial post starts off by discussing exactly what I mean by "wisdom" in the context of programming. Non-programmers may still be interested as it is more about wisdom than programming.
On programming.reddit.com, I have referred to a list of Big Haskell Projects I'm keeping. I've been keeping it in my head, because it's been short, but I thought I should go ahead and start actually keeping one.
Haskell as a language intrigues me, but I can't help but notice that there aren't a lot of large projects that use it. My intuition suggests that this could be difficult, because I suspect the type system may become increasingly unwieldy. I once asked about this directly, and the results were less than impressive. I'm asking for examples of large projects because concrete results trump my intuition.
In the interests of honesty and transparency, I'm actually going to keep this list in a public place and try to keep it updated as people suggest things until either A: It satisfies me and I start trying to learn Haskell or B: It becomes too much of a time sink, which would basically mean that there are a lot of large projects. That is, my goal is not to keep a list in perpetuity, but just until the point is made.
Update March 8, 2007: This has been up for three weeks now and attracted some attention from some people who really ought to know. I'm willing to say now that pending further updates, I see no compelling reason to believe that Haskell is practical for larger projects. Furthermore, Haskell arrogance is totally unjustified by evidence. It may someday be proven a compelling choice for Real Programming, but there isn't even any significant evidence of that, let alone enough to justify arrogance.
I've got a Django review in the pipe, and it's generally positive. It's still cooking both so I can gather more experience, and while some fact-checking occurs.
But there's something still missing that I can't put my finger on. I think cutting away even more of the general cruft of making web apps is bringing it out. I've been programming on the web for nearly ten years now, and something's not right. Despite the fact that I have gotten generally good at programming, and I keep refactoring and refactoring, I keep writing the same web page over and over again: I've got a tree of heterogeneous objects that I need to render, which itself a view of a graph-like structure, I allow the user to manipulate it somehow, and I have to propagate those changes back to the database. And for some damn reason, no matter what I do, there's always something super-special about this form that requires special treatment and requires further extension of the frameworks or libraries I'm using.
(Note this programming post meanders a lot; part of the point is that I don't entirely know where I'm going with this.)
The problem I see with most introduction to closures is they choose examples that can be done easily with a standard for loop, or some other standard construct, leading a student to ask (with great justification!) what the point is and why (s)he should bother. In my opinion, the best place to start understanding them practically is to look at their ability to decouple logic, because there they have benefits that are difficult or even impossible to replicate without them.
So despite the huge amount of verbiage on the net about closures, I thought I'd take another crack at explaining it with examples that actually do something that is much harder to do without closures.
Every program of any complexity needs to be configured. The traditional answer is to put this in some sort of text file, or something else that is fundamentally static data that must be read in and parsed. (That is, for the purposes of this discussion the Windows Registry is a static text file.)
If you are programming in a language that can take a program in at run-time, like Python, Ruby, or Perl, and you are targeting an advanced audience, the configuration file should actually be a program. In the degenerate case, the programming language can easily look like a configuration file, but then, if you need the full power of programming, it's sitting right there.
Update Dec. 24th: Similar thoughts w.r.t. build tools. I think declaration-based systems tend towards "demoware"; any arbitrary task can be made to look good in the demo of a declarative system, but it seems inevitable that before you can even blink, you need a scripting language. And ultimately, as with ant vs. rake, it's simpler just to pull in the full scripting language that to fall prey to Greenspun's Tenth Rule in your "simpler" declarative language.