On Sun, Jul 3, 2011 at 8:04 PM, Sean Corfield <seancorfi...@gmail.com> wrote: > On Sun, Jul 3, 2011 at 3:34 PM, James Keats <james.w.ke...@gmail.com> wrote: >> For example I suggest you look at this video/transcript and pay >> attention in particular to the point of debate between Joe Armstrong >> of Erlang and Martin Odersky of Scala >> http://www.infoq.com/interviews/functional-langs >> , in particular around the point where Odersky says "I’m not quite >> sure I buy that...". (also of additional relevance to those two points >> are http://erlang.org/pipermail/erlang-questions/2011-May/058769.html >> and also http://www.scala-lang.org/node/1637), and if you're further >> interested you may wish to read Eric Meyer's essay in the book >> Beautiful Architecture regarding a previous Simon Peter Jones Haskell- >> related publication, titled "Software Architecture: Object-Oriented >> Versus Functional". > > I've read that book (a month or two ago) but I'll go back and re-read > that essay in light of this thread.
I think you mean Bertrand Meyer's piece, extolling the virtues of OO in general (and Eiffel in particular)? I thought it was a terribly self-serving piece. Meyer has a strong bias and quite a bit of disdain for anything that isn't Eiffel - which shines right thru that essay to the point of making it fairly worthless, IMO. It has no objectivity :) I read the interview transcript for Syme, Armstrong and Odersky and I have to be honest that I found Armstrong almost incoherent and half the time couldn't figure out what he was trying to argue at all - so I'm not sure what point you're trying to make by referring to that interview, sorry. Similarly Armstrong's musings on the Erlang list about the entire world being a single flat "namespace" full of functions that are globally unique seems rather incoherent too. He talks about the problems with using modules to organize functions (and, yes, modularity can be hard) but then proposes something that would be no different (functions made unique by either having nearly random names or a structured set of metadata that would really be indistinguishable from modules in the first place - see http://erlang.org/pipermail/erlang-questions/2011-May/058773.html). The Scala forum discussion is more useful and relevant: TL;DR - objects are occasionally the most natural model for solving a problem. And in Clojure, mutable (shared) state is "occasionally" the most natural model for solving a problem. That doesn't seem newsworthy to me, just that a pure functional approach might not always lead to the cleanest solution. That's kind of a "duh!" because otherwise why would we need STM... And then there's the Ruby rant. Yeah, I'd be pretty ticked off that I got shot in the foot by combining two or three libraries that otherwise ought to behave reasonably together. Global method injection is pretty nasty. When I first read about multi-methods and protocols in Clojure I was a bit worried that library code might cause a similar problem by redefining functions out from under me, by virtue of more specific "overloading" but it hasn't been a problem yet and when I look at how those features are used in various libraries, I'm no longer so worried. I have other reasons for not liking Ruby so it's ability to shoot you in the foot like that doesn't change my opinion of the language (nor does it change its widespread popularity for a certain class of programmers / companies). Overall then, modularity is hard and sometimes a shared / mutable state solution is cleaner... And I agree with both points. Am I missing something in your concerns? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
