Lambda the Ultimate

The fact that the community can help evolve the language by supplying new language/library/tooling implementations is news (well, is new). Forking is a poor way to accomplish this given that what you're doing is forking a mainline, supported, unified implementation (do you expect F# developers to use your forked version in production?). Forking is not a very good way to help maintain a unified F#. In fact, it's pretty much the dual of unification...

Better to vet your implementations with the F# language designers themselves and the F# community. If the new addition(s) makes sense for general purpose use, then chances are much better today that it gets in.

So, the news isn't that F# is an open source technology, but that the community can now influence F# directly via vetted feature contributions to the mainline implementation. As with any language, adding features needs to be conservative in nature since once you add a language feature, there's no taking it out if compatibility is important to you... Further, the entire F# family of technologies are now open for contribution, not just the core language.

This is a bit unfair. The fact that the maintainers are now have a framework in place to accept patches is a huge deal, meaning they are going to use that framework. Open source done right must be two way communication, not one way. So this is really a change for the better.

Every time I've accepted a patch for TagSoup, I've pretty much regretted it. So now I don't incorporate patches: if someone sends me a patch, I'll almost always try to do what the patch provides, but in a different way that is more integrated with the code. Sometimes I fail at this, and some of my own changes are really more patches than anything else, but for me the most important part of the TagSoup code is not its feature set but its conceptual integrity. It has a certain way of doing things that nobody else quite seems to grasp.

So there is two-way communication in the sense that I make changes based on user suggestions (when I have time, which I haven't had lately!), but it doesn't take the form of the now-classic open source mdoel of development. And people do fork TagSoup and sometimes I even encourage it: I say, "If you want it to do X for your purposes, go ahead, it's open source after all; but I'm not changing the behavior of my version of the code."

I believe there will be push back on most patches for the reasons you state, but just having a process in place to at least evaluate patches is already a huge step forward.

Otherwise, you are criticizing the open source model in general, and not specifically F#'s adoption of this model. So its not really fair to dismiss F#'s adoption of a model you don't accept as not being newsworthy, because many people do accept this model (or at least, have more faith in it).

What I'm actually skeptical about, I suppose, is not open source / free software, but the bazaar development model. Cathedrals can be just as much open source as bazaars, and TagSoup could perhaps be characterized as a lady-chapel.

Lets not forget that all those languages are not pure FP, but rather multi-paradigm, including some form of OO, which makes sense anyway.

The main issue was the "one paradigm to rule them all".

Rumor has it that the O in OCaml refers to "object."

I guess most of the OO bashing comes from people that only know the Java OO model, without having experimented other ways of doing OO.

A blend of paradigms is the best way, maybe not for beginners, but worthwhile for any professional.

Java OO is not very good OO. Scala OO is pretty good, traits as mixins are quite nice.

Yep, quite right.

Java 8 OO is somewhat better with the addition of lambdas, default methods (which allow interfaces to function a little like mixins/traits) and streams. To the extent you can now write a webserver in a single interface. Of course, those of us stuck on Java 6 are not so lucky. Is Java 8 too late to the party to ever see production use? I can't help but feel that the language is in maintenance mode now.

I just joined a greenfield project in Websphere ==> Java 6. :(

As for the Java state, I think it depends a lot how Oracle drives the development forward.

I do however, remember two languages that had a lot of momentum in Europe and I used to care about them, just to watch them fade away due to mismanagement of the respective owners, Clipper and Turbo Pascal/Delphi.

All three belong to the multi-paradigm world with OO support on the side.

(This would explain why a number of OOPLs borrowed always more unashamedly from long time FP ideas, if only to stay in the "race" for the modern programmer acceptance? Typical mainstream example : from C# v1.0 to C# v5.0)

AFAIC, I have long ago ceased to either praise or bash OO as a paradigm of its own to model computation. Its induced bias by its one-size-fits-all way to model the real world and to compute over those models with a state easily too intrusive also becomes too evident after a while... in an ever repeating struggle between the taming of essential complexity vs. the accidental one, even when considering a metric as rough as the # of SLOC.

"No big point in beating a dead horse."

But what I've eventually realized is more troubling than being "just" a "too naive" paradigm which promised a little too much or a little too early :

while few of these languages have an overall design really interested in pleasing the PLT or type systems purists (if anyhow at all) many of them hope to attract as much of the software engineering camp as possible.

I feel that the designs of those have often disappointed in the long run by their not committing very thoroughly to what they aimed at, except for a few, like Eiffel, committed from its early design to do "some OO" less vaguely, with better explained and justified important, non-obvious design decisions (way beyond just the concrete syntax, etc) - and for its announced, preferred target precisely : SE.

Curiously, though, it's also the latter (languages) that knew the most unexpected (and quite undeserved) indifference from the very camp they were striving to serve better by their design rationale, say, more-thorough-than-the-usual (for the usual in OO, anyway).

That's what I would find the strangest, even (or especially) from my practitioner point of view, if I didn't know also about the influence of fashions, trends, and market economics, in that domain.

Maybe, there are after all, in the long run, more stable incentives for more observable language design improvements coming from academia, and benefiting more easily those functional languages which (for a good while anyway) didn't have to compromise themselves with the unpredictable irrationality of the markets, and in the tumultuous winds of broader, ever evolving programmer bases?

Not that I am against the markets, quite the opposite, but just trying to point out what sort of factors may serve vs. do disservice to conscious, well-intended efforts to improve language design in a given, chosen direction.

Not sure about Simula, but Smalltalk already had a few FP ideas.

But yeah, programming languages are all about fashion.

Usually they get adopted because of vendor X pushes them, or you need them for framework/library Y in domain Z.