Closures, Objects, Forklifts, and the quest for truth

My first post on Closures has so far netted 2,235 hits. My second one took in 1,346 while my CodeMunger post has picked up a similar 1,338. The majority of this traffic has come in from Reddit with a smaller chunk coming in from YCombinator’s Reddit-like “Startup News” page.

I wrote these posts because the subject matter was interesting to me. I really had no idea that they’d be read this extensively. (At the time I wrote them I was planning on increasing my readership by doing a few more Emacs articles in order to pick up an extra 10 or 20 hits a day from Google!) The response was largely positive, due in no small part to the timing of Joel’s recent piece on the general “dribble of morbid, meaningless, thoughtless comments” that blog entries so often provoke. There was one guy, however, that was so angered by my overall stupidity (and the fact that I’ve introduced a lot of noise into the search engines) that he needed to go into graphic detail about the violent things he wanted to do to me. (Dude… I’m not the one that posted the article on Reddit. Sheesh.) I have felt pretty lame for posting my ideas to the web anonymously– it’s rather cowardly– but given my unanticipated infamy I think I’ll continue to hang back for a while.

At the same time, traffic such as this does not necessarily equate to readers. It certainly doesn’t mean thoughtful attention. Even Sean Ross’s balanced and well stated post seems to miss the things that I think are key to the discussion:

1) The entire point of the closure/OOP articles is to explore what Paul Graham meant when he wrote on page 2 of ANSI Common Lisp, “With macros, closures, and run-time typing, Lisp transcends object oriented programming.” So yes, I’m writing more from a explorative standpoint. I haven’t yet come to a conclusion about what I think about these things– but these first insights and ah-ha moments that I’m getting by pursuing this line of thought have been more fun than any other programming exercise I’ve ever undertaken.

2) And no, it’s not about closures vs. CLOS or anything like that: closures and objects appear to have an unusual tao-like relationship. And OOP itself is such a slippery concept that the idea that there is “one true implementation/approach” is… well… unrealistic. (And it’s pretty cool that you could, if you wanted to, implement in Lisp whatever vision of OOP you prefer. You don’t currently have the freedom to go the other way in the current reigning OOP languages.)

3) My 7 years of professional life have been predicated on the assumption that OOP should be the fundamental to all that you do in your programming labors. Some really smart people have done just fine without OOP… and see no need to incorporate it into their designs. How is it that folks like that are solving problems with closures and so forth? Are they imitating OOP techniques when they solve real problems? Or is it the other way around? Do advanced OOP programs tend toward having a veneer covering a hacked-out typeless stew of ugliness that belies the core premises built into the design of their languages?  What’s going on here?

And this brings me to Miklos Hollender’s quiet plea for sanity. Am I missing something important in my current quest for beauty and truth? Yes our tools might suck and our languages might hobble us… but shouldn’t I find a zen like contentment in my professional life in spite of all this? My answer to this is two part. One: if you are a professional programmer and you lack a fluency in the core concepts of real computer science, you ought to be doing something to remedy your ignorance. (And if ignorance doesn’t make you feel stupid, then there’s not much anyone can do for you.) Two: normal people in any other line of work would be angry if they were forced to do a job with markedly inferior tools. Programmers should not be content to carry water with pails and a yoke when forklifts and fifty gallon drums are available. While indeed there are many zen-like pleasures to be had in the simple things of life, maintaining badly architected code is not one of them. (At the same time, Miklos probably has a good point that meeting our clients’ needs with tools that are reasonably suitable for the task may not be “fulfilling”… but there’s no reason it can’t be a pretty cool job that we programmers execute well in spite of some of these “academic” issues.)

Nevertheless… there are questions that seem to have gotten lost in the curriculum and tool-kits and language wars. I, for one, would like to look into them. Of course… the next time I post something that difficult and controversial that I can expect to get page views in the thousands… well… I just might take the time to clean it up a little more. (And maybe avoid such shameless hyperbole, too.)


6 Responses to “Closures, Objects, Forklifts, and the quest for truth”

  1. Miklos Hollender Says:

    I think I might have formed my comment in a misunderstandable way.

    Of course understanding CS concepts is important even in menial business logic programming. For example, when I was learning C# I checked out the online tutorials on how to read an Excel file and I felt depressed – it’s always been something like 8-10 lines of code. Then it dawned on me that the only reason is that tutorial writers assumed their readers don’t really know jack shit about OO, and if I do it the correct OO way – subclassing ADODataTable and overriding the constructor – it becomes almost as easy and nice as in Python f.e.

    Same thing for functional programming. I always wondered why system engineers or support consultants are happy to set a large number of configuration options but refuse to write even the simplest logic routines. Why? After thinking hard about it I think they don’t have any problem with variables, commands and conditions – what they are afraid of is loops, because loops in imperative programming can only be verified to be correct by execution, which is swift-paced environment means execution in your head. So if loops were replaced by something like mapcar a whole new bunch of people could be drawn into writing logic.

    So in this I agree and therefore this is not the point of my comments.

    Rather the point is that I think you might be too attached to the concept of software engineering. Hacking Apache is software engineering. Writing the usual database/forms/rules/reports/export/import business apps is NOT. It’s designing an information system. This information system could as well be designed for filing cabinets – we just HAPPEN to design it in software code because this is the most efficient known way of doing it. It’s like that f.e. when my father fries meat on garden parties on the wooden fireplace, he uses a harrow disc instead of a large pan. It did not make him a farmer – it’s just that the harrow disc proved to be the most useful pan for slowly and evenly frying the meat. The emphasis is on cooking and it’s just a happenstance it’s done on a harrow disc. It’s not the other way around, the point is NOT the using a harrow disc for some purposes where one of them happens to be cooking.

    So in this kind of business design – the equivalent of cooking – is everything and the code is a byproduct. And if you don’t have analyst above you, but you are the analyst, then it’s the design that can give you joy, satisfaction and ego. You have all the freedom to come up with original, tasty and interesting “foods” for business and yet you are unhappy because the knife for slicing the meat is not sharp enough. Who cares? It may be a discomfort but what the real point of this job is the joy of design – “They want something salty? Let’s try turkey with prawns and salty cheese.”

  2. Miklos Hollender Says:

    Language wars…

    you know I think the main reason of the wars is that there are at least three different classes of programmers:

    1) technical programmers (who love computers)
    2) academic programmers (mathematicians disguised as programmers)
    3) business programmers (information system designers disguised as programmers)

    1) want scalability, performance, stability, and a stiff environment that prevents common errors as their projects tend to be big and they have to work with a lot of mediocre people

    2) want expressive power because their tasks have very high algorithmical complexity

    3) want to be able to do a lot of simple tasks as quickly as possible.

    Actually there are overlaps between 2) and 3) (f.e. Rails shows us how can advanced concepts be used to speed up many little menial tasks) and therefore I think you are going towards a good direction. (I just disagreed on the perceived importance of the problems.)

    But the point is that these three fields are as different as construction engineering from automotive engineering. It’s not one profession anymore.

    Therefore it’s kinda to fun watch language wars – it’s like construction engineers would keep telling to automotive engineers that you HAVE to use concrete or it won’t be solid 🙂

  3. lispy Says:

    “Rather the point is that I think you might be too attached to the concept of software engineering.”

    I think I’m justifiably bored with coding the same style of solutions over and over again. I would like to work at a higher level of abstraction to code tools and frameworks to help alleviate some of this tedium. I think I can do so in a CodeMunger friendly manner… but I need to master some real engineering concepts before I can pull this sort of thing off well. I think this can be a real win for everybody: I get to work on interesting stuff… and my company gets a more configurable/flexible/maintainable code base.

  4. Dru Nelson Says:

    lispy, i understand your choice of being anonymous.

    however, you should at least put a contact form up on your site.

    that way people who want to share in the lispness and emacsness
    and communicate with you rather than with a blog entry comment

  5. lispy Says:

    You got it, Dru.

    You can now contact me at learninglisp at [that google webmail place] dot com. And I even put a contact link on the main page.

    (PS… I like the tag on your site: “20 minutes into the future.” Max Headroom was my favorite sci-fi show back in the day. I think of it as the “Firefly” of the eighties. Sorta. Okay, more like the “Tron” of TV. ;))

  6. Mark Miller Says:

    Hi lispy. Reading your blog it feels like we’re on the same journey. I can really relate to this comment:

    I think I’m justifiably bored with coding the same style of solutions over and over again. I would like to work at a higher level of abstraction to code tools and frameworks to help alleviate some of this tedium.

    Same with me. I picked Squeak (Smalltalk) as the language I’m learning with, though I like Lisp for a little variety. I respect the language. It’s just not my style right now.

    I’ve had a similar experience to yourself with the blog posts. Some of mine have gotten thousands of hits as well, through reddit (I don’t post them on there either). Fortunately I haven’t gotten many truly vile comments from those who, like you said, think I’m polluting the internet. I think this sort of thing points to why languages like Lisp, Smalltalk, etc. have stayed in the minority. There are always a few spoil sports who think of themselves as the godly experts, and if you say one thing wrong they jump you. Don’t let them get you down. Stay focused on why you got interested in this in the first place, and keep blogging! 🙂 Even if we’re learning this stuff, and interpreting things differently than the experts, or making misstatements of facts, people can discuss these things politely, and we can help inform others.

    I think posting “learning” blogs can help people relate better to what would otherwise be obscure languages, because we’re coming at it as people who are unfamiliar with it, just as they are. The experts find it difficult to reach newbies, even if they want to. They’ve tended to stay away from the popular technologies of today, unlike us (I worked with .Net before I got into this), and so they don’t have a context by which to reach people who work with them.

    Re: beauty vs. practicality

    I like this quote from Alan Kay:

    “I think the main thing about doing OOP work, or any kind of programming work, is that there has to be some exquisite blend between beauty and practicality. There’s no reason to sacrifice either one of those, and people who are willing to sacrifice either one of those I don’t think really get what computing is all about. It’s like saying I have really great ideas for paintings, but I’m just going to use a brush, but no paint. You know, so my ideas will be represented by the gestures I make over the paper; and don’t tell any 20th century artists that, or they might decide to make a videotape of them doing that and put it in a museum.”

    BTW, you said something about OOP feeling like a “slippery” concept to you. My post here might help you with that. Most of it concerns a speech Kay gave 10 years ago. I have a partial transcript of his speech that focuses on his concept of OOP. He gets to the heart of what justifies it. It wasn’t just invented as a neat way to write programs, and if all you had was the “Shape, Ellipse, Circle” treatment of OOP, you haven’t heard the whole story. Check it out. I think you’ll find it interesting.

    Kind regards.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: