Yardena kindly supplied this link to an interview with Erik Meijer, Gilad Bracha and Mads Torgersen, talking about Programming language Design and Evolution. The interview was interesting with Gilad confirming something that I have suspected for a while, which is that state is optional, and that most/all? problems can be decomposed into immutable functions. The problem with pure functional programming though is that it is really hard to do well, simply because we just don't think of the world this way. We think of the world as having state and we find it easy to model the world as stateful. Gilad uses the example of the interviewer as being a thing that is "stateful", rather than being a sequence of immutable things each one with no prior memory, only existing for a given moment in time.
Given that programming is hard enough as it is, relaxing the constraint of "no state" and introducing the idea of encapsulated state is a big leap forward I think, and represents a great, still untapped opportunity when compared to "anything goes" procedural programming. Contrary to the "OO" marketing hype over the last decade, the dominant programing paradigm today is still procedural in my view. The direct consequence of procedural based hybrid languages like C++, Java and C#, that only pay lip service to OO and functional ideas, whilst lacking the uniformity to be truly functional or Object Orientated.
It was interesting to hear John McCarthy say that the idea of encapsulated state, as introduced with Smalltalk has been the only significant step forward in programming language design in the last 50 years since Lisp. It was painful to watch the interview as the interviewer made claims for languages like C++. Even going as far as claiming that Mac OS X was written in C++ (although OS X is written in C and Objective-C), and that we still need C++ for all our "Systems" programming needs today. Gilad winced more than once. Which prompted the question: "Why is it that "beautiful" languages aren't more popular if they are so much better?". Gilad tried to answer this one, using a form of Alan Kays "prior context" argument, saying that programmers didn't like new ideas, and that change needed to be introduced incrementally.
Interestingly it was the C# guy Mads, who debunked this half truth, by saying that programmers were interested in new ideas, but that "new thinking" didn't pay the bills. Mads also admitted that a lot of the work that lead to the dominant static VM platforms of today was based on wrong thinking stemming from compiler based, code optimisation ideas, and it would have been much better to have started off with a dynamic platform and to have layered on top an optional type system, much like Gilad advocates. He puts this realisation down to hindsight, forgetting to mention that people like Alan Kay and Dan Ingalls were advocating just this at the time.
The biggest disagreement was over the future role of C++ with Gilad claiming that the language was as good as dead, and that they should have stopped extending it long ago. The others, including Erik, felt that it was still useful with advances in static analysis tools still being made today. It was painful for me watching advances in IDEs and Operating Systems being attributed to C++ and it's prodigies Java and C#, when it is clear to anyone with any grasp of history that we owe the modern Graphical, Windowing Personal Computer world to Smalltalk. You could see the pain on Gilads face as he sat through this mis-representation of history, mostly by the interviewer.
Mads made the point, that the successful languages today are all incremental changes to the thing that existed before them, namely C. And I guess this is the rub. C/C++, Java and C# are all successful. Smalltalk is not. To the victor the spoils, which means that the victor gets to write history.
This is fine with me as long as Smalltalk gets to write the future :)
Subscribe to:
Post Comments (Atom)
3 comments:
Paul, at risk of going off on a tangent somewhat, I would love to discuss the idea that state is optional. Was thinking back to something that I worked on a couple of years back where I had to build a state model and something at the time just didn't quite feel right under the circumstances.
More recently I worked on a project where I had modeled a connection as either open or closed and these states seemed to make more sense, but some do not. I think we could make an interesting topic of this some day.
Hi Andrew,
Intuitively we know that state can get you into trouble. I try to use immutable objects when I can. I also prefer the use of closures (lamda expressions) over things like loops and loop variables. There is no possibility of getting the index wrong when doing this:
aCollection collect: [:item | item > 5].
This expression answers a new collection containing elements greater then 5 'collected' from the old collection. This approach is fully declarative and fully functional.
anObject := [:item | item > 5].
In Smalltalk, lambda expressions are also objects. So functions are objects too. They are just objects without state:
anObject value: 10.
This expression answers true. You can send messages to lamda expressions just as you would any other object. The 'value' of a lamda expression (block) is the answer you get when you execute it. Here the block takes an argument 10.
The key thing for me is uniformity. When I first heard about functional programming I didn't understand what all the fuss was about, because to me a function was just an object declared inline between '[' and ']' without state. To some one from a Smalltalk background a function is just another type of object. I see functional programming and OO programming as the same thing.
So the Object metaphor is uniform, dealing with scenarios where there is no state (lamda expressions) to scenarios where there is state (objects with instance variables) all the way up to treating modules and libraries as Objects (as in Beta and Newspeak).
I am woolly on functional programming, but from the little I've seen, I prefer the Smalltalk approach: "functions are objects too".
I'd like to here more about your experiences with state.
This is perfect because I need to know more about computer languages in order they can help me to develop a program to buy viagra easier.
Post a Comment