I am surprised you think my comment had anything to do with a dominate language, since as you know I use many types of languages, don’t believe in “one true way”, and even turned you on to Python, and believe that I am pragmatic..

Having said that, and looking past languages, do think trends happen and I think there is a current evolution trend emerging in OO languages.

What I see it that OO languages that use either lazy dynamic runtime typing or eager compile time typing, are being increasingly be influenced by FP constructs for working with collections of values, immutability, pattern matching for dispatch, strong typing with type inference, higher-order functions, lazy evaluation, Monadic effects to specify side-effects, etc..

What I was trying to point out is that I am inclined to think right now that OO languages + these FP features and using an FP style is a more likely to be the evolutionary trend then a move away from OO toward the list of functional languages that you have in your essay. Thus I think the programmer will get to choose their own way to architect their solutions using patterns that might be more OO then FP or more FP then OO.

Tony

For example, Erlang will continue to play a huge role in any projects I’m involved in for the foreseeable future, at my current employer or at any future employers, regardless of how “dominant” it is, and that’s perfectly acceptable for the type of people for whom I like to work because they see the clear values of productivity, reliability, concurrency, hot upgrading, speed of development, maintainability, and code brevity that Erlang brings to production systems. I’ll continue to use Perl and Python and Ruby and Tcl wherever they fit well. I’ll apply Java (if possible via Clojure, Scala, or Jython) or C++ or C if I need them. I don’t use Haskell or OCaml in production today but it could happen in the future. (I don’t touch Windows anymore so I don’t mention any F#, C#, etc.) It’s all about getting there quickly with a system that performs well without acquiring an unmaintainable mess along the way.

Worrying about what language is “dominant” is pretty pointless, don’t you think? Seems like that way of thinking would apply best to people who think building a system is most effectively accomplished by paying 100 developers of average or less capability rather than paying 10 great developers.

And finally, I don’t believe I said or implied anything about patterns going away. I simply said that the GoF “Design Patterns” were focused on OO, not FP, and that different patterns exist for the latter, often built into the languages themselves. In their interview I linked to, the GoF authors expressed similar thoughts, and of course Peter Norvig’s presentation linked in a previous comment pretty much says it all.

I am sure that you are aware of Richard P. Gabriel’s “Worse is Better” vs. “The Right Thing” essay http://www.dreamsongs.com/WIB.html

and maybe you even know his “Theory of Technology Acceptance” from his 1990′s “Models of Software Acceptance: How Winners Win” slide deck http://www.dreamsongs.com/Files/AcceptanceModels.pdf

I believe if you look at Gabriel’s “Theory of Technology Acceptance” and plugin pure/non-pure FP Languages vs. OO languages + FP constructs (Such as VB.NET or C# 3.0 with LINQ which is Haskel’s Monads) then you might find that the future just might be dominated by “Worse is Better” OO languages + FP constructs, and not “The Right Thing” FP languages, so patterns just might be with us for longer than you might think.

All the best,

Tony

There’s certainly a lot more boilerplate required in the OO forms. I agree that FP aren’t necessarily required in FP/EDA as much as in OO. But GoF succeeded most of all in providing a lingua franca for programmers/architects to communicate more effectively by sharing a common understanding and foundation.

Nice essay.

Cheers,

Darach