![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
winterkoninkje) wrote2009-05-10 02:40 am
What Killed Smalltalk Could Kill Ruby, Too
I like Smalltalk. Of any of the OO options it's by far my favorite. And yet, this most powerful language of the '70s has been relegated to oblivion. Robert Martin of Object Mentor Inc. gives a talk at Rails Conf 2009, "What Killed Smalltalk Could Kill Ruby, Too", which is well worth watching. I've since abandoned the whole OO paradigm in favor of functionalism, but I think this talk also has a good deal to say to the Haskell community (in fact, hat tip to Nick Mudge on Planet Haskell).
In particular, around 37:00 to 41:00, Martin talks about one of the three major things to kill Smalltalk. This one is the greatest danger for the Haskell community: arrogance and parochialism as a result of an emphasis on purity. The complaint is a common one, though I think the mention of purity is something which should be taken with depth. (Certainly purity is one of the highest horses we Haskellers will climb upon.) In an interesting addition to the usual dialogue, Martin posits professionalism as the countervailing force we need to maintain in the face of the growth of the community.
I highly recommend the video. The actual talk starts about six minutes in, and after the ending at 50:00 there's a Q&A session with a couple good questions.
no subject
Alex: *falls apart laughing*
Lindsey: Smalltalk! I meant Smalltalk! Augh!
Alex: How do you really feel about OO?
no subject
To me, paradigms are tools. If the situation calls for a flat-head screwdriver then use the flat-head. Don't try to fit a Phillips-head screwdriver into a flat-head socket, otherwise you just break the screw (and your programming project).
OO might be good for larger programs whose solution is amenable and is solved simply in an OO way. Solving the same problem in an old-style non-OO way (like with the language C, for example) would probably produce something so convoluted and spaghetti as to be almost unmaintainable.
no subject
My big thing is more about what is taken for the skeleton on which everything else is hung. For that, nothing can beat the pure functional paradigm in my world: a powerful type system, type inference, parametric polymorphism, referential transparency, algebraic data types, etc. These features are so basic and so pervasive that they really must be built in at the lowest layers. Type safety isn't something you can just turn on and off, otherwise there's no safety.
As far as OO goes, I think this OOPSLA debate (http://www.dreamsongs.com/Files/ObjectsHaveFailed.pdf) really says a lot. The OO model of the world has some major insoluble problems, so it can't be used as the core. And yet, OO as we understand it today really must devour everything in order to deliver on the promises of the paradigm. All experiments I'm aware of to combine it with functional programming without being dominant have all been named failures and relegated to obscurity: Common Lisp's objects, Ocaml's objects, O'Haskell. (Scala gives a more even split and hasn't been around long enough to fail yet; it'll be interesting to see if it takes off.)
Despite the failures of OO, there are certain problems for which interface inheritance and mixins do give much cleaner code than equivalent formulations in current functional languages. So there's certainly room for something like OO within the functional world. After making the changes necessary in order to get over the fundamental issues and the integration problems, I think this new thing won't look much like OO to the Java, Python, and Ruby crowds. I'd be interested to see it though.
no subject
I don't see any paradigm, language, what-have-you as better than all other paradigms, language, what-have-yous. The best I would ever give a programming language, paradaigm, or what-have-you is that it: 1) best in a particular situation or that 2) it fits most of the situations programmers typically run into during development. It it true that multi-paradigm languages have beaten out single-paradigm ones, but not because they are 'better'. I'd argue that it is because of number 2 above.
Granted, functional programming may make certain things for the programmer easier to write, easier to understand, maybe some things more efficient (in terms of computer resources used), or maybe more complete but I don't see it as ultimately killing off OO. OO may be the dominant paradigm that most programs are written in these days but I think that reflects the fact that programmers are trying to solve problems that are far more complicated and dynamic these days than computer programs written 50 years ago.
OO is good at being able to encapsulate the complexity of a program so the programmer has a better time understanding it and it is good at being dynamic. Those abilities are needed in today's development world, so OO is dominant and the static way of 50 years ago is not. It is not, I'd say, because OO is 'better' than the old static way. If the development world needed the static way more than the OO way, then things would switch.
I see, ultimately, functional programming and OO as cordoning themselves off (so to speak) and fulfilling certain niches. It may also be the case that the functional paradigm is just so damned useful at most everything that it replaces OO as the dominant paradigm. Again, however, if that were to take place, it's because the functional paradigm is just more 'damned useful'.
no subject
If you'll read the link I posted, that is in fact not the conclusion of many folks at OOPSLA— one of the leading conferences on object-oriented programming. Certainly the paradigm claims this as a benefit, but propaganda does not make it so. And just because OO is more expressive than structured programming ("the old way") doesn't say anything about functional languages; straw men and all that. For an explanation of why OOP helps modularity in comparison with structured programming, see this post (http://r6.ca/blog/20090511T013939Z.html) which also details one of the reasons functional programming is becoming popular (by continuing on that path further than OO languages do).
In addition to limiting scope away from global variables, the other organizational benefit of OO is polymorphism. However, subtype polymorphism (ala OO) is much harder to reason about than parametric polymorphism (ala FP), and parametric polymorphism captures a great majority of the polymorphism that is desired in practice. If you don't think that subtype polymorphism is hard, consider the fact that Sun Microsystems got it wrong for arrays in Java. Certainly subtype polymorphism has its uses, but these are fewer than is often thought; in any case, the real organizational benefit comes from having any variety of polymorphism, which FP does in spades.
Nothing about FP contraindicates modularity. Functional programs tend to be more modular than object-oriented programs because of the greater expressive power. And I've worked on large projects in both paradigms. Perhaps you're confusing structured programming (C, Fortran,...) with functional programming (Haskell, Lisp,...)? You'd be hard pressed to get more dynamic than Common Lisp.
no subject
I read the OOPSLA link and I did not mean to say that OO is the absolute best at being able to encapsulate the complexities of programs. I meant that sentence to be a relative measurement, not an absolute measurement, which is why I used the word 'good' instead of something like 'best'. I meant the sentence 'OO is good at being able to encapsulate the complexity of a program' to mean that compared to something like a simple procedural programming paradigm it does a better job at capturing the dynamism that is inherent in many programming projects and the modularity needed to understand the complexities. The functional paradigm may be more ideal at capturing far more of that dynamism and modular requirement than OO... I'd agree with that point and I never intended to say that the OOPSLA article or your conclusions were inherently wrong. I'd say that the OOPSLA article's specific list of points are correct, if you take them in a general sort of way, but that there are many aspects of the argument that are too finely grained as to be almost near-sighted. It's a fascinating read, nonetheless.
I was trying to describe a "usefulness heuristic". I don't take sides on paradigms, languages, etc. (as I said before, I find them silly). The most I'm willing to say is this: there are certain domains of problems that languages, paradigms, and whatevers cover. Use the tool that is appropriate and sufficient for that domain problem. OO may be imperfect at covering all the problems within its domain (and I applaud efforts to make a paradigm more imperfect at that task than OO) but that really is besides the point. There may be times in the future, even if functional programming hit in a big way, that OO might be a more effective and understandable solution than a similar functional solution (I even had a thought experiment to go along with this assertion, but I'm really trying not to be long-winded :) ).
no subject
And yet you do when you say a particular paradigm succeeds in being useful for a given domain/problem ;p
There's nothing wrong with utilitarianism, but it is a philosophy like any other. As is nihilism, much despite trying to say nothing. All I'm saying is that my utility-o-dar consistently rates FP higher than OOP (except in a few rare aforementioned cases).
no subject
Hey now :) I'm not defending OO here. I'm merely saying to use the right tool for the job. If the right tool for the job is functional programming, by all means, use it. I'm saying the situation determines which paradigm, language, etc. is best for that situation.
All I'm saying is that my utility-o-dar consistently rates FP higher than OOP (except in a few rare aforementioned cases).
I'd agree with you, just like OO or a functional paradigm is usually best than writing something in a procedural paradigm. But (and this is the one and only point I've been trying to make since my first reply to your post) that doesn't necessitate that OO or a functional paradigm is best in ALL cases... sometimes the procedural way is better. That's determined by how useful the paradigm is to that particular situation. Just because a paradigm is more expressive in a mathematical/a priori way doesn't mean that it is best in all circumstances. Computer science is partly an engineering discipline and there are always mitigating circumstances and constraints that determine things.
And no, contrary to my educational background, I'm not falling back on a philosophy. I'm merely falling back on observation, which I've put into practice as a heuristic.
no subject
(and I applaud efforts to make a paradigm less imperfect at that task than OO)
no subject
Again, however, if that were to take place, it's because the functional paradigm is just more 'damned useful' rather than the functional paradigm being 'better'.