2015-07-06

Towards functional

(another entry in the "let the greats make my points" series…)

At some point I was getting uncomfortably close to the expressive possibilities of plain old C, and started learning C++. But C++ always had to me this air about it connecting it to UML excesses, to baroque Design Patterns for things that might have been expressed with a handful of words, to "big, spongy frameworks" (as Yegge said?)… the kind of things that made me wary of going into J2EE to begin with, some long time ago. 



Is it over-engineering? 

Or is it that the human mind can't keep track of enough details at once and looses mooring once you are deep enough in the stack of abstraction; that once you're floating in abstractions you stop minding piling on them? That's a dark thought… (*)

And then I found this: "Design patterns are a bug report against your language" (Peter Norvig, maybe paraphrased)

And Alan Kay, calling them "one of the 10 most disastrous things about programming" in an interview.

I had heard of Lisp before, of course, but never paid any attention. Now I started finding lots of things about it making me wanting to change that. I went through The Little Schemer and started SICP, … and I hope to finish it eventually.

But the other interest pulling me was hardware (“People who are really serious about software should make their own hardware” ;P), and I got an embedded C job. So "functional" for now is rather reduced for the moment to coding more consciously in plain C. (yes, I do think that caring about function pureness and intelligent use of macros to generate / avoid code does count as a step in that direction [UPDATE: and looks like Carmack agrees!])

But for now I will just keep here the beacons that keep pulling me towards functional.
If you try to solve a hard problem, the question is not whether you will use a powerful enough language, but whether you will (a) use a powerful language, (b) write a de facto interpreter for one, or (c) yourself become a human compiler for one. We see this already begining to happen in the Python example, where we are in effect simulating the code that a compiler would generate to implement a lexical variable.  
This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough - often that I'm generating by hand the expansions of some macro that I need to write. 
[…]  
Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp.   
… there's so much more on this, but I'm still trying to get everything lined up. Stallman saying that OOP is "not interesting" (because of LISP), Dijkstra saying that OOP is snake oil… Alan Kay, inventor of SmallTalk and OOP pioneer saying that Lisp is "the greatest single programming language ever designed"… Yegge commenting on C++ success being a freak anomaly powered by the 90's rise to power of Microsoft and the Windows API… 

(heh, interesting. Compare to Apple rather avoiding C and C++: Pascal in the original Macintosh, then Objective Pascal… Alan Kay working in Apple, and his insistence on SmallTalk being "message-oriented" vs "object-oriented"… Jobs saying in the 90s that Microsoft had won and so there'd be a small Dark Age for a decade (this was about the OS, but that implies the triumph of its API)… Objective-C in NeXT… Dylan in the 90s with the Newton (and how it seems to be surprisingly fondly remembered by the functional community), now Swift ("Objective-C without the C")…)

What would have happened if, instead of C, Lisp had been the language to use? Maybe we were not so far; Stallman was a MIT LISPer, and the legacy stayed in emacs… Feels like C was a kinda myopic low-hanging-fruit enabler which later only made hard things harder.

[UPDATE: Turns out that the classical essay "Worse is Better" is all about this: "Unix and C are the ultimate computer viruses." ]



Well, I forgot the references to Tim Sweeny, from Epic (Unreal), saying in different ways that the GPGPU model is not scaling well, that we could be better using software rendering, and that we need easier programming: functional much better than imperative multithread. Haskell in, C++ out. That was in 2005 and 2009.

But just now I find that Carmack was on Quakecon 2013 talking about having taken a week off to immerse in Lisp and go through SICP, and that he's experimenting with Haskell himself! And he goes on to ask interestingly related things: what would have happened if he had done Quake 1 on Quake-Scheme instead of Quake-C?

All of this is interesting because IIRC Lisp lost to others because of performance and memory usage – "Lisp programmers know the value of everything, but the cost of nothing". Maybe it was simply too early? Anyway, looks like the pendulum really is swinging.

Funny too that Carmack goes towards functional with the argument against "clever programmers":
A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention.
* Just as Dijkstra saying that the "the competent programmer is fully aware of the strictly limited size of his own skull"; Knuth saying pretty much the same, and suggesting that multithreading won't last…

(And while we're at it, Dijkstra appreciative about LISP but less about others: "When FORTRAN has been called an infantile disorder, full PL/1, with its growth characteristics of a dangerous tumor, could turn out to be a fatal disease." Funny that PL/1 was a grandfather of C! But turns out that Dijkstra directly wrote in favor of Haskell and against Java and C++… so no need to infer what he would have thought.



The reading that really, finally gave me some insight into the usefulness of the esoterics of functional languages and algorithm analysis, even if you are implementing in C:
http://www.cs.indiana.edu/~dfried/mex.pdf (particularly the long quote from page 28)



Looks like this post might keep growing as more and more examples keep appearing… so, to be continued!

1 comment

  1. The reading that really, finally gave me some insight into the usefulness of the esoterics of language and algorithm analysis: http://www.cs.indiana.edu/~dfried/mex.pdf (particularly the long quote from page 28)

    ReplyDelete