Lambda the Ultimate

They supposedly used as much as 900,000 lines of code.

http://c2.com/cgi/wiki?LispInJakAndDaxter

Naughty Dog wrote their own compiler (in Common Lisp) for a custom game development language (GOAL). GOAL is decidedly imperative and OOP and can be very low level (dealing directly with the PlayStation 2 hardware). I would not use it as an example of functional programming any more than I'd use Python or Forth code as such an example.

Is the compiler itself written in a functional style? Don't know.

Most larger Lisp apps are not really that 'functional', even if we allow the term to include mostly functional languages with side-effects.

An example is the Cyc system which is under development since more than twenty years. It uses a 'frame language' called CycL on top of Lisp (or C). So, I would not really say that it is written in a functional style. Cyc provides a 'knowledge base' with more than 100000 concepts and more than 2.5 million facts and rules written in CycL.

I guess Lisp compilers written in Lisp could count as more functional programs. Some are under active development for a long time (20+ years) and have ports to 10+ platforms.

Another example for a mostly functional program might be Axiom (recently forked as FriCAS and OpenAxiom). It is a computer algebra system, but with a functional language with an interesting type system. It uses Common Lisp for its runtime. Axiom is under development since 1973 (!) and has gone through all kinds of changes. There is also another programming language (Aldor) for it, which usually does not use Lisp. Originally Axiom has been developed by IBM research. Recently at least one forked version (FriCAS) has been ported to several Common Lisp implementations. It has a quite interesting and large manual (PDF).

Axiom's language, AFAIK, is kind of like ML, but specialized to the mathematical domain. It differs a lot from Maxima (the other large CAS written in Lisp) in that respect.
Big, big project. Used to be a commercial product (CAS) from IBM but I believe the PC market - and the cheap (as in cost) Mathematica - pushed it aside (it was mainly for workstations, I believe).
Has lofty goals. A language with which one could write one's Algebra papers in it - sort of like literate programming, but for Maths. EDIT: business-friendly license too, unlike Maxima (which uses the GPL). I suppose there could be a Real World (TM) use for this in some other software that needed such advanced functionality (even though here and there it's behind the curve when compared to the traditional proprietary CAS packages). Suffers of some linuxisms last I looked (compiling "everywhere" is/was not easy).

The new-ish Indian online travel portal, cleartrip.com is built almost entirely using ANSI Common Lisp.

GOSUB - since you seem to have registered just a while back, I guess you work for Cleartrip. No?

Mr. Srikumar, you guessed it right :)

In the summer I was at the office of Streamtech for a Lisp meeting.

They've got about ten programmers hacking Common Lisp at the moment, if I counted right. Most of which quite young. It was a really cool experience to feel the atmosphere. Lisp books lying around everywhere, guys (no girls) coming from other languages having to adopt to Common Lisp. A bit surreal in this day and age. I didn't register any complaints from them about the language, but then again we were at a Lisp meeting.

Streamtech started off doing web sites, in PHP i believe, till one of the owners discovered Common Lisp about five years ago and they decided to switch for most of their work. They're now pointing their arrows to online advertising. See their site.

In case you haven't been checking your gmail recently, Mike Wells et al have been posting gmail ads looking for fp/OCaml programmers for SF based mobile startup Skydeck. At least one ex-CMUer there, so it's not that much of a surprise :) There is a definite presence of startup folk at BayFP talks, so I wouldn't be surprised if there are more such startups in the area.

We have more like a dozen or so "real" programmers- we have ~80 people who write code, but most of those are traders, not programmers. Although we do have several hundred thousand lines of Ocaml code written, over the course of several years. Enough to know that the benefits of functional programming to large projects are not just hype.

I'd be interested to hear what the traders have to say about OCaml. I find it intriguing that people who aren't professional software developers are using it. Although I guess Mr. Minsky did say that partners review every line of code in the CUFP presentation.

Brian is a little closer. We actually have more than 20 people who spend a large fraction of their time programming in ocaml. That's not counting the occasional trader who does some hacking here and there or the partners who do code review.

Are any of the traders using OCaml for, e.g., modelling derivates or do they use C++ ? If not, do you think it's because they're used to C++ (habit) ? Could you comment on that, please, as I'm interested in OCaml for mathematical models (instead of the usual C/C++/Fortran).

I would imagine they use spreadsheets

Of course, you answered that because I actually meant quants. But now, thinking about it, actually, I don't know...don't some traders write their own models (e.g., do their own time series analysis, etc.)?

All the books I have mention C++ for the number crunching...Not spreadsheets.

APL and its newer offspring like J and K did see some significant use in the financial sphere.

Right. As far as I remember there were many stories about APL and ilk in the insurance world, often used by financial analysts, not people with "programmer" in their job titles.

I am not sure how true this is today, though.

I believe APL is alive and well in industry though I cannot quantify how widely used it is. Some proponents of APL have expressed an interest in our OCaml work.

There is an aging infrastructure of A+ at the large investment bank where Arthur Whitney was employed and where he had created A+. At one given point a small group (dozen or so) were supporting a business that is now probably being serviced by hundreds of programmers in your run-of-the-mill languages.

k and kdb+ is A+'s phoenix, and it is used for a niche market to provide time series analysis that poses too many problems for traditional relational databases.

You seem to know a lot about this...

I think this story is an interesting aspect of computing history on which nothing substantial was ever written, as far as I know. Any more information will be appreciated!

These languages definitely get less exposure than they should, there are many thousands of active developers and billions of dollars of business relying on the technologies. One important reason why you hear so little about them is that the users of languages like APL often don't think of themselved as "programmers". They are actuaries, chemical or electrical engineers, traders, etc. Most of them have no idea how they would express themselves on a forum like "Lambda the Ultimate".

Many APL vendors were very slow to adapt to the death of the mainframe, and have been very quiet for the last 2 decades. But today, excellent workstation versions exist, som even support object orientated programming, with interesting syntax for dealing with arrays of objects - and the market is recovering.

For an idea of what sort of work APL vendors are working on, see http://www.dyalog.com/version12.html or http://www.dyalog.com/help. Free educational and low-cost "non-commercial" versions are available from http://www.dyalog.com/download-zone.htm. The "array language community" also has a community web page at http://vector.org.uk.

Disclosure: The company I work for is a leading vendor of APL language systems.

Thanks. I followed the APL/J world closely a decade ago, but I lost touch.
You may be right about APL developers, but surely people building APL implementations (or of other languages in the family) are developers, indeed are programming languages implementors, so they should be (should become?) part of the wider PLT community.

Indeed they should, and making that connection is one of the jobs that we, as modern APL vendors, need to take seriously: Educating APL Developers so they know that when asked at by a "real programmer" what they do, they can say things like "I use a agile methodologies to write embedded domain specific notations for financial planning", rather than "Er... what's a methodology" :-).

Modern platforms really require the ability to use platform components. To the typical APLer this is not necessarily a clear step forward, although the availability of libraries seems such a clear win to the professional programmer. This is one reason why languages like APL have struggled a bit in the 80s&90's: The libraries and platforms have been a bit too hard to use for the last couple of decades and been beyond the grasp of the typical APL user, who does not have the necessary background. Vendors scrambled to put APL-like wrappers on constantly changing API's and often did a poor job. On the other hand, the professional programmer is not much better off, he doesn't grasp the subject matter and can't the the functionality quite right (the original intent having lost in the chinese whispering game called "analysis and design"). He IS able to quickly create a web page to edit header/details in beautiful technocolor and a "rich user experience", of course!

The good news is that platforms like Microsoft.Net are significantly easier to make palatable to APLers. There is of course a quarter of a million miles of documentation of framework classes to deal with, but Google helps :-).

Connecting APLers to the PLT community remains hard. The most productive / successful APLers tend to have a non-programming background, and (naturally) only care about cracking the next financial or technical problem. Givin that this "problem focus" is right at the heart of WHY the selected a tool like APL, changing their focus is perhaps not really something you want to do. If they wanted to hang out with programmers they would NEVER have gone against the tide and selected a "unpopular" tool like APL. You could almost say they picked APL because they "don't like programming"...

Of course, there ARE "professional APL programmers" who focus on bridging "the gap between APL and IT". And the APL vendors have the responsibility to do as you say. But APL vendors have tended to recruit from within the ranks of users, and often fall prey to the same "us and them" relationship with the rest of the IT community.

"APL - possibly the most unfortunately named programming language in the world (TM)."

There has been a new management team at Dyalog for nearly 3 years now and this is one of the key issues we know we must address. I made a small start this year by submitting a paper to the DLS at OOPSLA this year to talk about work we have done on arrays of objects. We have a long way to go yet, but the market trends really do seem to favour a resurgence of APL-style technology, so we think you'll be seeing much more from this community in the decade(s) to come.

I don't know why APL/J/K are referred to in the past tense. Kx at least is doing very well and its roster of customers is constantly expanding. The other APL companies don't seem to be hurting either: they are still around, there are still user conferences etc. However K (the language) is no longer a product and they only sell Kdb (the db), in which the user is "shielded" from K by an SQLish front-end. Thus whether that still counts as functional win is a toss.

And yes, I haven't known those days myself (too young) but I heard plenty of stories of APL being picked up by non-programmers, often people who wanted to bypass the "official" IT department and just get summit done, dammit, on their own terms. But you should keep in mind that APL doesn't have all the conceptual baggage of modern FPLs and has a simple syntax to boot.

APL is alive and well. Anyone who works with mortgages in large volumes will know a product called CAS which is written in Dyalog APL

This application has a rich user expression language based on vector operations that is easy for non-technical people to pick up and use.

Lisp has a steady use in industry but generally for small-scale applications like shopping carts for websites. I am not aware of any uses of Lisp in billion-dollar markets.

One such market already mentioned is travel (ITA).
Franz's list of success stories for their Common Lisp implementation is quite comprehensive (note the categories in the sidebar, not just the recent cases).

Thanks for posting the links but I can't find anything either recent or significant among them. ITA don't say what exactly they're using Lisp for. Franz have a huge list of ancient projects. Their "recent stories" are mostly years out of date and include Naughty Dog (who ditched Lisp almost 3 years ago AFAIK), art software called AARON with no mention of Lisp, a reference to the Lord of the Rings that also doesn't mention Lisp, a biotech called Symyx who don't mention Lisp, another biotech called GenWorks that do link to Franz but have no shop or product testimonials, middleware from Planisware that doesn't mention Lisp and the rest are all non-commercial academic research projects. Among all that, the only thing of any significance is the implication that Lisp is being used to some extent for airline tickets somewhere. I've no idea where, by whom or to what extent though.

In contrast, if you look for recent news about the ML family of languages you find that Microsoft are taking F# commercial and will bundle it with Visual Studio. That is news worthy.

So I would say that [flamebait deleted by admin] ML is thriving in industry.

I've taken the unusual step of editing the parent comment, because flamewars about languages are not on topic here (see the site policies). The rest of the comment could be considered informative, so I did not simply delete the comment and have not (yet) put the user on probation, although that's clearly becoming a strong possibility.

If anyone has a problem with this, please email me privately (anton@appsolutions.com), or if necessary, start a separate forum thread.

I'm not sure that his post should be considered informative. I'd say the post is 'misleading' or mostly 'wrong'.

A few examples:

Genworks is not a biotech company. They are selling a system for 'knowledge-based engineering'. That's also clear to understand if you read the article or look at the Genworks website.

Lisp is mentioned in the Aaron article. Lisp is also mentioned on the website: http://www.kurzweilcyberart.com/aaron/history.html

The 'Lord of the Rings' article mentions Mirai (a Lisp-written animation suite by Izware).

ITA Software has talked about their use of Lisp in their product called QPX: http://www.paulgraham.com/carl.html (2001) and here http://www.itasoftware.com/pdf/SIAM2007.pdf , for example the core of their search engine is written in 200KLOCs of Lisp. Also web page generation software. It is also known who uses it. Orbitz is a user (http://www.orbitz.com/App/Partners?z=89d3&r=2s).
More about QPX: http://www.itasoftware.com/solutions/qpx.html.

Sigh...

I'm not sure that his post should be considered informative. I'd say the post is 'misleading' or mostly 'wrong'.

I said "could be", not "should be". Either way, much as I'd love to see comments deleted for not living up to standards of accuracy or technical validity, the comment as published is within acceptable limits here.

Where exactly does that AARON page (not the one hosted by Franz) mention Lisp, even in the "history" section?

The Lord of the Rings article quotes "Raitt" who once worked on a product written in Lisp called Mirai but now works for Weta. Raitt said "Though Mirai has a little better tool set for sculpting, the animators can interact with, and manipulate, the puppets in Maya".

I still cannot see a clear indication of what ITA or Orbitz are using Lisp for. Giving a ternary reference to Paul Graham quoting an e-mail from someone at ITA that mentioned Lisp six years ago is not exactly compelling evidence of Lisp's current use in industry. Especially when the author writes to Paul Graham with the objection "please make a note that this message is old". Your QPX link also fails to mention Lisp.

Like I said, Lisp is not gaining the same traction as other (modern) functional programming languages like OCaml, F#, Haskell and Erlang...

As I was reminded sometime back, programming languages never really die, so I'd say that calling in the coroner would be premature.

I've personally never understood any particular reason why there should be animosity between the ML and Lisp communities? Neither of these communities is large enough at the current time to give Java or C# a run for the money - even if they were to consolidate by moving into a single camp. And I don't see it as a zero sum game - both will benefit from the promotion of more language diversity, rather than less.

Final Note: Advocacy, especially of the negative variety, is to be discouraged, going against both the spirit and policies of LtU.

Language advocacy is off topic. This concern was repeatedly raised (in the forum) by editors about the "Lisp is dead" messages, to no avail.

Let me add that these messages suffer from two more substantial issues: They are not interesting, since the opinion was posted here again and again recently, and furthermore satating this again and again with no interesting or in depth discussion of technical or other relevant factors (or at least providing links to such discussion) has little value for LtU readers.

Any more messages along these lines will lead to messages from the user being put on the moderation queue and thus require approval prior to appearing on the site.

Language advocacy is off topic

Was there advocacy?

They are not interesting, since the opinion...

What opinions are you referring to?

no interesting or in depth discussion of technical or other relevant factors (or at least providing links to such discussion)

I cited dozens of examples, gave many links and several quotes. Marco even responded "I found the post informative.". I concluded that we have seen dozens of examples of modern functional programming languages gaining traction in industry but nothing credible to indicate that Lisp is gaining traction.

From your objection, I assume you would like to hear speculation on what language features resulted in this?

For example, that Wadler's views are implemented in F# as "active patterns" and are of great practical benefit in F# because they allow views of native .NET data structures to be created and pattern matched over without having to copy data structures into native F# types. Would that be more on-topic?

Perhaps a new LtU article comparing and contrasting OCaml and F# in detail would be on-topic and of interest?

I'll gladly contribute if you have any constructive criticism...

Perhaps a new LtU article comparing and contrasting OCaml and F# in detail would be on-topic and of interest?

I'll gladly contribute if you have any constructive criticism...

Perhaps a new LtU article comparing and contrasting OCaml and F# in detail would be on-topic and of interest?

That would be of interest.

I'll write a blog article about it and cite it in an article here then.

I have high hopes for F# and see it as a real chance to make some inroads on some large C# based projects that I work on. In reading Robert Pickerings book and doing some translations, I get the feel that there's some slant towards cleaning up some of the syntax (I'm thinking of his default use of the #light syntax directive). At the low level, the languages are quite similar. But programming in the large is significantly different - no modules in F# and it leans towards integrating with the .Net. I haven't quite figured out whether I like the syntax used to encapsulate .Net just yet. It gets a little more complicated - but that's probably to be expected in a FP language that is so tightly integrated with the OO world.

...no modules in F#...

Actually F# does have modules. It does not have functors.

The two languages are sufficiently similar that porting significant commercial code bases has been quite painless for us (~15kLOC per week per person). F# goes to quite some lengths to mimic the OCaml stdlib even when .NET already provides the same functionality in a different form (look at Dictionary and Hashtbl, for example, which are completely independent implementations of hash tables).

Anyway, I'll get into it all in detail in my blog... :-)

you know Marco was referring to my post being informative about you.
http://lambda-the-ultimate.org/node/2491#comment-37511

BTW, here's an excerpt from Aaron's page, the one which you said had no Lisp references:
http://www.kurzweilcyberart.com/aaron/history.html
"AARON was built using Franz Inc.'s Allegro CL development tools."

along with Franz logo and link...

I think the admin is being a tad churlish. A discussion of FPL wins in the real world will necessarily devolve into a discussion of wins of this vs. that language because users are not interested in FPLs in general but in the specific language they are using: they live in separate communities, they are not oecumenic in that way. The abstract category of FPL that you are using exists in academia and in some technical forums like this one, not so much in the real world. Thus if you want to discuss real-world use of languages, that is something you have to face: it doesn't make sense to lump together, say, Lisp wins and ML wins and it is appropriate, on the contrary, to discuss whether Lisp or ML or both or neither is getting traction.

In another context, the parent comment might make sense. However, in this case the issue of Lisp vs. ML was originally raised and subsequently pushed not by a regular LtU member who has demonstrated an interest in the subjects discussed on LtU, but instead by someone who has admitted in this thread that he sees stirring up controversy as a way to advertise his business. He achieves this by making unnecessarily provocative statements, i.e. deliberate flamebait or trolls.

We don't see any value in allowing that to continue here. A number of regular members have made it clear in this thread, and in private email to the admins, that they agree. Anyone who is looking for that sort of discussion can find plenty of it on comp.lang.lisp and comp.lang.functional.

Anyone who is looking for that sort of discussion can find plenty of it on comp.lang.lisp and comp.lang.functional.

No, don't. Neither of those newsgroups is for FUD.

I was observing that such discussions have regularly occured in those places, as I'm sure you're aware. I wasn't endorsing newsgroup abuse. However, I should have stuck to dealing with what is acceptable here, and not dragged other forums into it.

My comment was intended for everyone (IOW, if you want to promote your stuff, keep it on your own site), but I didn't make this clear. Nevertheless, I agree with what you say.

As I was reminded sometime back, programming languages never really die, so I'd say that calling in the coroner would be premature.

"Lisp is dead" meant that "Lisp is not gaining the same traction as other (modern) functional programming languages like OCaml, F#, Haskell and Erlang".

I've personally never understood any particular reason why there should be animosity between the ML and Lisp communities?

The success of any modern functional programming language breeds contempt among the Lisp community. Consequently, interested programmers asking for objective comparisons between Lisp and OCaml are met with extreme hostility by the Lisp community. Note that the converse does not happen.

Neither of these communities is large enough at the current time to give Java or C# a run for the money - even if they were to consolidate by moving into a single camp. And I don't see it as a zero sum game - both will benefit from the promotion of more language diversity, rather than less.

The ML community would not benefit from the promotion of Lisp, or vice-versa. For example, the recent productization of F# by Microsoft has had a strong positive effect on OCaml, with thousands more people now learning about OCaml.

Even if anyone did announce a significant investment in Lisp, I believe the ML community would gain nothing from it.

Final Note: Advocacy, especially of the negative variety, is to be discouraged, going against both the spirit and policies of LtU.

I assume that I may draw comparisons between the relative success of different families of functional programming languages in industry on a thread about large-scale successes of functional programming, and question the validity of statements made by others?

I assume that I may draw comparisons between the relative success of different families of functional programming languages in industry on a thread about large-scale successes of functional programming, and question the validity of statements made by others?

"Keep in mind that LtU is a community site and regular and respected members are expected to let posters know when their posts violate the spirit of LtU. If you receive responses of this sort, it is firmly suggested that you review your contribution, and accept that your style of discussion or choice of topic may be inappropriate for this site."

To put it somewhat bluntly... You seem to be following an agenda that purposely pits one family of programming languages against another. That sort of advocacy is not particularly welcome.

The question of Common Lisp is mostly off-topic to the main thread anyhow. Common Lisp is not generally considered to be a functional PL, so its fate is not really tied to the original question. Scheme would generally be classified as functional, but that doesn't seem to be the under discussion.

Finally, as Ehud noted earlier, this dicussion is not particularly productive to advancing our state of knowledge concerning programming languages.

The success of any modern functional programming language breeds contempt among the Lisp community.

To put it more bluntly: by reading the type of items posted to the home page and the types of discussions that usually take place on LTU, not to mention prior complaints in this thread and Chris's suggestions, it should be clear why this type of discussion, both in tone and in subject, is unwelcome, especially if prolonged.

LtU is indeed a community site. Part of the respect I expect from members of the community towards each other is to listen to the sort of rebukes I and others have posted about the posts that required intervention. The firmly suggested wording in the policy page is not poetic license. If someone else, other than the member who received the complaint, wants to argue in favor of this type of discussion, I am all ears. Otherwise, the next step is putting the user on probation, so that all future posts will have to be approved prior to appearing on the site.

You seem to be following an agenda that purposely pits one family of programming languages against another.

Of course: I'm trying to draw an objective comparison and you can't do that without pitting languages against each other. From my point of view, the references to uses of Lisp in industry are not credible, not significant and not recent. In contrast, the references about SML, OCaml, F#, Haskell and Erlang in industry are credible, significant and recent.

In my mind, advocacy would be someone here telling others to use one language rather than another but not someone noting which languages are most popular in industry.

Common Lisp is not generally considered to be a functional PL...

I'm surprised to hear you say that, particularly when others in this thread are discussing whether or not delegates in C# make it an FPL.

IMHO, Lisp and JavaScript are close enough to being FPLs (for pretty much any definition) that they are certainly worth mentioning here whereas Python and C# or Java are not. That is entirely subjective, of course.

Do you agree that the meaning of the phrase "functional language" is used more often to mean "has first-class lexical closures" rather than "side-effect free" these days?

In my mind, advocacy would be someone here telling others to use one language rather than another but not someone noting which languages are most popular in industry.

I'm surprised to hear you say that, particularly when others in this thread are discussing whether or not delegates in C# make it an FPL.

[Edit Note: Must learn to curb on excesses....]

IMHO, Lisp and JavaScript are close enough to being FPLs (for pretty much any definition) that they are certainly worth mentioning here whereas Python and C# or Java are not. That is entirely subjective, of course.

Do you agree that the meaning of the phrase "functional language" is used more often to mean "has first-class lexical closures" rather than "side-effect free" these days?

Given vested interests in the outcome...

People come to us for advise on functional programming in industry precisely because we are impartial. Implying that we have a vested interest in showing some languages to be more popular in industry than others is silly.

Language preference in advocacy is typically driven by religious faith rather than anything objective. As my posts here have already shown, we've done our research, presented objective evidence and drawn our conclusions. That is not advocacy.

I see it as advocacy similar to that which is taking place in other venues.

Then you are mistaking advertising on usenet for advocacy here. On usenet, controversy fuels huge threads of discussion about us and our products, which is very cost-effective advertising for us. Here, the value for us is in reaching a wider audience, so we can afford to present useful information with self-citations rather than stirring up controversy.

JavaScript, Python, C#, and Java rely too much on mutation to be considered an FPL - they belong to the imperative class of object oriented languages. Even though both Scheme and Common Lisp are in the Lisp family of languages, Scheme would be considered an FPL and Common Lisp would not. My personal opinion is that there is a healthy respect between the ML and Scheme communities. OTOH, Common Lisp is as different from Scheme as it is from ML.

I identify FP with: (1) referential transparency; (2) first class and higher order functions - HOFs; and (3) parametric polymorphism and pattern matching.

In your previous statement you imply that purity is an essential part of a functional language. I appreciate that many people (particularly from the Haskell community) agree with you but I find drawing the functional line between Lisp and Scheme far too subjective. Indeed, the distinction is so blurry that I would avoid using the term "functional programming" in many cases.

Incidentally, have you studied LINQ and C# 3.0? You might be enlightened by articles like this one.

Implying that we have a vested interest in showing some languages to be more popular in industry than others is silly.

No, what's silly is claiming you don't have a vested interest, as you continuously promote your consulting business and chosen languages on different forums.

As my posts here have already shown

Your first post on here was a blatant advertisement for your consulting business embedded in a cheerleading post for F#. That post was removed for obvious reasons. Now you have managed to post your consulting link in a dubious thread that belongs more on comp.lang.functional than LtU. Congratulations, you have successfully played the search engine optimization game. Isn't that enough, or do you need your X vs Y language debates here too?

Here, the value for us is in reaching a wider audience, so we can afford to present useful information with self-citations rather than stirring up controversy.

But where is the value for LtU?

This website is primarily focused on programming language theory, not programming languages per se. That may seem like a ridiculous distinction at first, as the former is informed by the latter. But many surface details of specific programming languages are largely irrelevant here.

Comparisons for programming languages, especially those involving value judgements such as "better" or "more suitable for", require caution. For one thing, such comparisons, especially when not constrained (i.e. better at doing X for purpose Y), tend to escalate to flamewars; the participants of this forum seek to avoid endless arguments about whose language, paradigm, or typing discipline is "the best". For another, rigorous analysis of such questions is frequently a matter of software engineering as opposed to theoretical CS--and few such analyses are ever done and published. Many issues which frame the debate are matters of taste and beyond the reasonable purview of science.

Third, the introduction of popularity or "design wins" into an argument--is seldom productive to the topic of this forum, and often is little more than a glorified pissing contest. Languages like C/C++, Java, Javascript, Perl, and VB are far more "popular" than any functional language these days, regardless of strictness, purity, or typing discipline--yet nobody would suggest that we should all abandon PL research and just code in the current industrial fashion. Likewise, there may be an interesting line of inquiry as to why F# is being adopted much more and CL is not--but suggesting that this proves that F# is "better" than CL (or the opposite) is sheer fallacy. FWIW, I'm neutral on any F# versus Lisp debates, such as they exist. Simply noting which languages are most popular, however, is a "don't care" for most participants of this forum; we're mainly interested in the next generation of PLs and how we can improve. Arguing about which language is most popular, and disputing reported uses of a language in furtherance of such a debate, is definitely off-topic.

To address your last point--in my view, first class lexical closures (or a close approximation thereof) are a necessary but not a sufficient condition for FPL. Some means of doing higher-order functions is a requirement. Absolute purity is not a requirement, but a FPL should IMHO discourage use of mutable variables, and provide features which make them unnecessary in many cases--cheap recursion and TCO, libraries which avoid side effects, etc.

Aaron: right on the page, fat on the bottom: "AARON was built using Franz Inc.'s Allegro CL development tools." Allegro Common Lisp. Wikipedia ;-) on Aaron: 'Development of AARON began in the C programming language then switched to Lisp in the early 1990s.'

The Lord of the Rings article: " Raitt decided the best way to define the characters would be to sculpt combination shapes for their expressions. Mirai, a 3D sculpting engine that has been around for about 17 years, was the tool of choice.". Mirai was used for sculpting and modelling. All described in the article.

ITA. ITA Software is a company that developed a system called QPX. QPX is partly written in Common Lisp. The core search engine is mostly written in Lisp. Orbitz is one of their customer who uses that system. You can see from the website that they have lots of other users like Air Canada, Continental and others. QPX is an existing product. Currently they work on a new airline reservation system (RES), also partly in Lisp. That's a huge challenge. They have also multiple positions open for people with knowledge of Lisp. They also use Python, Java and C++. Technologies we like: Lisp. That 'someone' who wrote the mail is one of the Co-Founders and their Chief Scientist. There can be more said, but I'm getting tired...

For the last line the typical response is: “Lisp doesn't look any deader than usual to me.” ;-)

If there are still any genuine industrial adopters of Lisp then I would certainly like to investigate them and refer to them. However, I need credible sources and citations to Wikipedia, an out-of-date quote by Paul Graham and an anonymous statement on the ITA website just don't cut it.

I can well believe that Air Canada and Continental are customers of the company ITA that made a product called QPX that was once written in Lisp, and ITA are still advertising QPX. However, even if that is true it is not a primary relation between those major air lines and Lisp.

I'll it on my list but if you have any more reliable sources to back this up I'd really appreciate it.

http://www.itasoftware.com/careers/jlisting.html?jid=8

about eight are lisp related. And they recruited quite a few lispers the last couple of months.

Furthermore I know from ITA insiders they are expanding their lisp activities (and market) as should be a logical conclusion, seeing their hiring strategy.

More to the point: is there a particular reason ITA should be lying about their lisp usage? Is there something inherent about Common Lisp that makes it by default unfit for the airline industry?

More to the point: please confine your anti-lisp crusade to cll mr Harrop. Or better of course, stop it altogether if you can find the power within you.

LISP is still in use @ ITA - I was just recently reminded by it from a friend who joined the company this year. You don't just ditch the #1 code base in your field on a whim.

Any idea how much Lisp code is still in use at ITA or how much revenue they earn from it?

Re: #comment-37906:

Any idea how much Lisp code is still in use at ITA or how much revenue they earn from it?

It's a privately held company. No one's going to disclose the kinds of information you're asking for :)

As far as the past and current use of Lisp, Dan Weinreb has this to say on the subject:

We almost certainly have the largest team of Common Lisp programmers in the world.

Aww, sure, I'll disclose it, what the heck. The answer to how much revenue we get from the Lisp software is: all of it. Hey, it pays my salary...

Certainly Common Lisp is still in use at ITA, as much as it ever was and much more. QPX's basic technology has not changed in years, so what you've seen written about it is still true. We have more customers these days; many airlines use QPX. See our web site for a list of customers who have given us permission to talk about them. QPX has been substantially extended over the years and given new capabilities. It's under active development all the time and it is operated 24/7 at multiple data centers.

I am working on the other large project at ITA, a new airline reservation system, initially for Air Canada, to be known as Polaris. It has many components and ties into QPX and our other technologies for knowing how many seats are available on what flights and so on. It is a three-tier architecture (four if you count the web browser). The presentation tier is in conventional Java (servlets, etc). The business layer ("core") is in Common Lisp. The database is conventional Oracle. There are other pieces written in Python, plus the odd Perl and shell script and such.

The Common Lisp part is big. Lots of lines of code; I'm probably not supposed to say exactly. We have a huge team working on it. Whereas QPX is largely compute-bound, Polaris is a transaction-processing system (see "Transaction Processing" by Gray and Reuter). The "core" is by far the most complex and interesting part of Polaris.

My own work has to do with making the system highly-available, and particularly with being able to upgrade to new software versions while the system is running. The system has to be up all the time, once it goes into production (many months from now). Mostly this particular issue doesn't have much to do with Lisp one way or the other.

Regarding the learning curve: not really a problem. We give everybody copies of "Practical Common Lisp" and they learn it quickly. This is partly because we only hire excellent programmers. I like working at ITA so much because the people I work with are so great. I learn new things every day.

Ah, but is it "functional"? I see there is another discussion group named "What are the properties of functional languages?" If there were an agreed-upon crisp definition of what the question means, I could try to answer it. Common Lisp is a multi-paradigm language, supporting procedural, functional, object-oriented, etc. programming. Do we use higher-order functions? Sure. Do we use object-oriented programming? Yes, very heavily; lots of CLOS, a home-grown object-relational data mapping system based on CLOS, etc. Does our code look like the Scheme code in "Structure and Interpretation of Programming Languages?" No. We get lots of mileage our of Lisp macros; as I understand it, so does QPX.

MathWorks (you know, the makers of MATLAB) recently bought PolySpace (April 2007).
PolySpace specializes in source code verification technology, and it's all SML + MLton (AFAIK). They're a big MLton user, it seems.

That's pretty industrial - and successful - to me. Even more so when you consider who PolySpace's clients are: big, big names in Aerospace, Automotive, Biotech, etc.

here and
here too.

Also, I believe PolySpace employs Abstract Interpretation (Google: Cousot) throughout its source verification product.

It's just the ideal showcase for the power SML can bring to software engineering. I don't know if they use PolySpace on Matlab itself - that would make me feel better, as I use it myself - Consider the C bugs in Mathematica, or the recent multiplication bug in Excel.

This is fascinating, thank you. I was under the impression that Standard ML was basically dead in industry.

Mr. Harrop, you forgot to mention that Matlab uses (your?) OCaml code on their FFT routine (that subsequently generates C code). Shall we count that?

Also, let's not forget that the new ECMAScipt ("Javascript") specification is being written in SML.

Mr. Jon D Harrop, I presume 30 means your age?

tired of spamming the comp.lang.lisp newsgroups?
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/9d60e37981bbcfe3/ab3709cc24a117ed

Found lambda-the-ultimate to be a more effective media in your anti-Lisp crusade?

ML languages certainly offer many good features, but so do Lisp languages. Saying one is better or more modern or more useful than the other is no more productive than the old dynamic-vs-static-typing debate.

I think your energy at the subject is now explained by your age...

"Finally, don't forget that JavaScript is a functional programming language!"

tell that to most javascript webmonkeys! They certainly don't know anything other than imperative style at its worse...

I sympathize with the spirit behind this message - I erased some similar comments from my own earlier reply before posting - but let's stick to the technical discussion here.

If a poster gets particularly obnoxious, he'll be put on "probation" and his comments moderated. But as usual, ignoring obvious trolls is often the most effective strategy.

I found the post informative.

I think people underestimate the professional JS community [this is as person who came up out of it and the flash community]. The linguistic barbarities of programming in the web community was astounding 10-15 years ago - languages and frameworks gave about as many of the necessary abstractions as ASM. For example of the community's sensitivity, alistapart.com provides some amusing reading - an incredible amount of care is put into structuring and styling static content cleanly (albeit with the subtext of the content being generated). The push for (often functionally inspired) frameworks to ease security, modularity, efficiency, compatibility, and expressive concerns is no surprise. To start in this world, you need a pixel-perfect mindset, and that ultimately reflects in code as skill level increases.

If the comment is that the technology is accessible for hobbyists... sure. GUI-rich programming is fun and HOFs streamline callbacks (not that I'm a supporter of the latter use).

That doesn't mean, though, that most people using C# are doing functional programming, any more than people using C++ are necessarily doing object-oriented programming.

My instinct was also to quip that C# is not a real functional programming language. However, just the threading model of Windows Forms will encourage many C# programmers to use delegates, for example.

Whether or not you consider that to be "functional programming" is another matter, of course.

Linspire is a Linux distribution (as I understand it, it's the easiest one for the hypothetical "common user") that uses Haskell:

http://urchin.earth.li/pipermail/debian-haskell/2006-May/000169.html

If that is still true it's a big success story, too.

I gather Clifford Beshers has left Linspire. I guess that might leave a hole in their Haskell development team.

Does anyone have an update on this? I can't find any recent references to Linspire at all, let alone their continued use of Haskell since their lead Haskell developer left...

David Fox and I have left Linspire, Jeremy Shaw is still there finishing up some of the Haskell tools. We've formed a new company, SeeReason Partners, which you can read about in the HC&A Report.

We plan to continue developing the autobuilder, a Haskell program which builds Debian packages and archives. Our goal is to provide current archives of all Haskell tools and packages at hackage, so they will be easy to install on Debian based systems.

I hope these won't become the only only showcases in a decade. At least Ericssons engagement is not really new.

I think it's naive to expect the social acceptance problem of certain technologies ( and FP in particular ) will be solved by the industry and there will be a big player advocate Haskell instead of Java or .NET. Instead communities need to provide portals simplifying recruitment.

We are just at the beginning of a culture that is strongly influenced by the way the web can work effectively.

I know it's been mentioned already, but I think F# can and will have a major impact on the use of FP in the industry. It's very similar to O'Caml, and it can be used with M$'s video game development libraries, etc. It should at least help get people in the door of FP, and maybe a few game makers using F# for some cool stuff :)

Absolutely!

Everywhere I read about FP, you are there, selling F#. I don't know if I speak for the community on this, but I'm a little tired of it, myself. Please take that into consideration when you post comments like this.

Everywhere I read about FP, you are there, selling F#...

And OCaml, Scala and Mathematica...

Everywhere I read about FP, you are there, selling F#...

And OCaml, Scala and Mathematica...

It wasn't the F# I was criticizing, it was the selling.

I have mentioned this recently; not only F#, but also other things (That LINQ thing and ...). What should the community do? It is getting uglier...

...Python, Ruby and Javascript deserve the moniker "functional"...

Ruby does not have functions-as-values, so it's not in the same class as the other two languages. Blocks and .call() aside, HOFs are not practical in Ruby and have to be emulated via "function objects" -- making Ruby about as functional as Java. C++ has richer functional possibilities than Ruby.

...just saying that projects in all these languages should be included since they all meet the definition...

It's rare to see functional programming in those languages; and only Python offers reasonable support for it in the form of well integrated lazy lists, discussion of patterns and common HOFs like map.

I agree that introducing OO practitioners to FP, as a way to streamline their work and open their minds, is a good idea -- but only if you can do both of those things. FP in Ruby would be a syntactic train wreck and performance disaster; in JavaScript, it would be a matter of re-implementing the wheel; only in Python would you get a real taste (just a bit) of the real power of FP. Honestly, Python leaves me with a taste for Scheme... Clumsy FP is its own FUD.

It is disingenuous to include any of the major Ruby, Python and JavaScript projects under the "functional" moniker (at least any of which I am aware); it promotes the notion that FP is widely used while diluting its definition.

Jason, you make two points in your post: one about Ruby and the other about usage. I'll reply to them separately.

First, re: Ruby's .call() syntax. I humbly submit that Ruby's f.call(params) and CL's (#'f params) are in some sense morally equivalent: both .call and #' serve to conceptually and syntactically differentiate calls to function values from other kinds of call. If you disqualify Ruby due to .call then you have to disqualify CL as well.

Admittedly Ruby does make a distinction between methods and functions (blocks) that isn't present in CL (or at least very different). Interestingly, Scala makes essentially the same distinction. Its just that Scala has a lightweight syntax for converting a method to a function whereas with Ruby you must do it more explicitly by wrapping the method call in a block. This distinction doesn't prevent Ruby from meeting the definition: it allows functions as values (at least as much as CL does).

This distinction doesn't prevent Ruby from meeting the definition: it allows functions as values...

It allows values as functions which is not the same thing at all. I'd like to see some other points of view on this; but I think .call() completely disqualifies Ruby. I don't use CL, or know anything about it; I'm okay with it if CL is not really functional as a result of this extreme righteousness.

It allows values as functions which is not the same thing at all

I'd love to hear what you mean here. A block looks like a function to me. It can be bound to a variable and passed to methods or other functions (blocks). The result would seem to be a function as a value. Sure, the calling syntax for calling functions in Ruby looks a bit different from the syntax for calling methods, but as I pointed out, they are different things in Ruby (and Scala).

Ok, ok, we both know that Ruby block syntax is a shorthand way for creating a "function object" and the reason for "call" is to invoke a method on that object. I'm just saying I don't see any problem with mentally working with Ruby's blocks as if they were much like CL's funargs.

I'm okay with it if CL is not really functional as a result of this extreme righteousness.

Oooh, careful, let's not fan the Scheme vs CL flames. ;-) While I find your distinction a bit out of the norm, I have to admit it's at least principled.

If you're curious, in CL a symbol binding has 2 slots (actually several, but...whatever). One slot is for "normal" values, the other slot is for function values. The "extra" #' syntax in CL is how you say you want to use the functional slot.

The second point you raise is how the languages are used. Your point is that Ruby/Python/Javascript are generally not used functionally so they shouldn't be included for consideration.

Here we get into murky territory. Where the definition of a languages is pretty clear, its usage more likely to be a matter of conjecture. The best either of us can do is gather anecdotal evidence supporting or denying functional usage of these languages. In the end we can't really know for certain how they are used except in a sampling of projects we happen to have access to.

Second, even if I stipulate your point that the communities around these languages "mostly" don't use them functionally (and honestly my intuition agrees with yours), that still may leave us with some large projects that have been done in these languages using functional techniques and therefore those projects would have to be included as answers to the original poster's question.

Finally, my goal here isn't to "dilute the brand" of functional programming. It's just that honestly I think the OO vs functional debate is often couched in the wrong terms and that the artificial divide is why much of the current crop of programmers sees functional as "weird" and OO as "normal." Functional and OO programming should be seen as two related concepts that can live well together: see CL (CLOS), Scala, OCaml, and, yes, Python/Ruby/Javascript. The more interesting debate, IMHO, is in things like pure vs. impure and lazy vs strict.

Not sure I agree that FP and OO are "related" as closely as you seem to be suggesting. I don't think the divide is totally artificial. I think usage, or rather paradigm, matters. And in this respect, there are a number of fundamental differences between the two.

For example, the treatment of state. You don't have to throw in purity: even impure functional languages are all about avoiding state. OO on the other hand is about encapsulating state, not avoiding it. Major difference.

A second point is how they deal with adaptability. FP uses parameterisation for that, i.e. higher-order functions and parametric polymorphism. OO instead favors refinement, i.e. inheritance and subtyping.

Third I'd list is the well-known dualism with respect to extensibility. That is, OO is data-centric, and allows easy addition of new cases, while FP is operation-centric and allows easy addition of new functions. Of course, you can take that as an argument for saying that they complement each other well, but unfortunately, it is not easy to have both at the same time, even in a mixed language (the so-called expression problem). So in practice, you'll most likely choose one dimension.

There are other points, but these three are central, and AFAICS core of the reason why even in "mixed" languages, you largely see an obvious preference for one of the paradigms. They don't add up easily.

I agree.

I think the list of distinguishing elements you gave is very useful. I usually only remember to mention the first two...

I agree that usage matters in practice. But if you base the distinctions on usage you definitely end up with a continuum rather than a divide.

For example, as you say one of the core tennets behind OO is encapsulating state, but there's plenty of literature about the values of avoiding it as well (google "Java immutable objects"). Similarly, functional programming enables the avoidance of state but a non-trivial amount of e.g. Common Lisp code is about encapsulating it.

Similar arguments go for polymorphism/composition vs subtyping/inheritance. To say that OO favors subtyping is true, but it misses all the literature where leading OOists strongly encourage composition over inheritance. It also seems to ignore the work in adding sophisticated polymorphic type systems to OO languages whether it's the mainstream "generics" of C#/Java, the templates of C++, or more recently the higher kinded types in Scala.

The part where we completely agree is with the expression problem. This is exactly the lines where the OO vs functional question should be raised but very few of the people who ask "where's functional programming actually used" understand the issue. Interestingly the expression problem is exactly why the two paradigms work so well together. In a language with both the programmer has the option to think about the problem either way or, as you say, solve it in both directions.
http://www.daimi.au.dk/~esbenn/papers/TheExpressionProblem.pdf.

By the way, I want to emphasize that I'm no rabid OOist. If nothing else, my experience with Haskell has taught me that there's a radically different way at looking at some of the same kinds of problems. But again, it's a continuum. If you introduce type classes to a Java programmer as a way to define an "interface" and add it to type in a post-hoc fashion they'll probably follow the thought pretty well. It's not 100% accurate, but it's not exactly a deep divide either.

For example, the treatment of state. You don't have to throw in purity: even impure functional languages are all about avoiding state.

I agree that the current mainstream OO languages are mutation-oriented, and even if you try to use them in a more stateless way, their libraries and other features tend to fight you.

However, I think it's worth noting the point that Matthias Felleisen made on the PLT Scheme list yesterday, that the imperativeness of OO is a mainstream phenomenon:

Only the people who have turned OO into mainstream programming techniques have made it much more imperative than Scheme. In principle, there is no difference in imperativeness for Scheme and any good OOP language. It's purely a part of our social history that people continue teaching and practicing OOP with side effects.

This fits with things that Alan Kay has said, that have been quoted here in the past.

I think this also points to one decision factor for choosing how to characterize a language: if you imagine a language similar to current OO languages, but which is not mutation-oriented, you'd find it would start to need features like tail recursion support, mutation-free library code, a "let"-style expression, and a host of other things which I won't try to enumerate now. So my answer to the claim that mainstream language X is functional is: show me some non-trivial and significantly mutation-free code written in it, and then we'll talk.

(Here's one example, to set the bar: a ray tracer in a single C# 3 LINQ expression.)

As a particularly enlightening example of a different form of OO, Erlang can be considered something like an OO language without inheritance. What's that you say? Well, Erlang has objects (processes) that encapsulate state (process dictionaries). The objects (processes) get work done by sending messages to each other. Some might argue it's an important difference that Erlang messages are immutable - but Erlang messages can contain references (pids) to mutable objects (processes), so in practice messages in Erlang are pretty much like messages in OO. As far as I can tell, beside the inheritance issue, the main distinction between Erlang and mainstream OO is in granularity. Erlang is functional in the small and OOish in the large.

Oh yeah, and the other main difference is concurrency. Oh, and the other other main difference is manual dispatch. But besides those, what did the Romans ever do for us? ;-)

I'm not seriously suggesting that Erlang really is OO (whatever "really OO" means) nor am I suggesting that it should be. My point is that it's quite conceivable for a language I'll call Ertalk to be functional in the small and OO in the large. If Erlang is functional then Ertalk should be considered functional as well.

As a particularly enlightening example of a different form of OO, Erlang can be considered something like an OO language without inheritance. What's that you say?

What I say is check out the archives. ;) Here are some links to previous LtU discussions of this:

• In Maybe Erlang is OO after all?, Joe Armstrong claims that "Erlang is *more* OO than any of the other so called OO languages."

• From Ralph Johnson: Erlang, the next Java: "Processes in Erlang are objects. ... Erlang is a perfect example of the actor model, which is an example of the mystical view [of an OO system as one that is built out of objects that communicate by sending messages to each other, and computation is the messages flying from object to object.]"
• From Message Object Oriented vs Function Object Oriented, Matt Hellige writes "isn't the logical conclusion of "message-passing OO" actually Erlang?"
• Erlang to OTP: A heavy duty TCP/IP Client Server application, Chris Rathman writes "OO techniques of inheritance and polymorphism are a tad cumbersome in Erlang, and it would be difficult to scale." and Luke Gorrie, LtU Erlang expert extraordinaire, writes "Basically I think the 'OO in Erlang' stuff is mostly arm-waving. It's not really how you write Erlang programs, it's more of an interesting programming exercise. It's talked about as much as it is because it's always the first thing that people coming from an OO language want to know about (I know I did). Really Erlang has it's own wonderful programming style that eventually sinks in."
• Functional Object-Oriented Programming addresses related issues, with a brief mention of the Erlang idea.

Okay, my observation wasn't a striking example of original insight. But in my defense I was trying to show a model for an OO language that discourages mutation. In the case of "Ertalk" it would be by supporting powerful functional structures (tail recursion, pattern matching, etc) and making mutability feel "discouraged" by using keywords like get and set rather than the seemingly innocuous = or :=.

Coincidentally, on the erlang-questions mailing list today

"... The rest of the chapter was a discussion of why we thought that OO *design* might be acceptable but why OO *languages* are not. ..."

See EUC07 -- Inheritance in Erlang

see also the following keynote:

http://www.ccs.neu.edu/home/matthias/Presentations/ecoop2004.pdf
http://www.ccs.neu.edu/home/matthias/Presentations/ecoop2004.tar.gz

Here we get into murky territory. Where the definition of a languages is pretty clear, its usage more likely to be a matter of conjecture. The best either of us can do is gather anecdotal evidence supporting or denying functional usage of these languages.

An experienced "speaker" of Ruby -- like myself -- can tell you as much about usage patterns in their language as an experienced speaker of a natural language. In fact, because the semantic and syntactic space of programming languages is so much narrower than that of natural language, we can expect a practitioner to be able to tell us much more about a programming language than their own spoken language.

That's the usual way to go about learning the idioms of a new language -- you ask native speakers. If you want to learn how folks write Ruby, Python or JS, read some blogs and frequent Freenode. If you want to prove how they write it, well, you have a problem of definition before you have a problem of evidence -- you must define "sufficiently functional" and so forth. If you want to take that up, write us when you get back!

Functional and OO programming should be seen as two related concepts that can live well together: see CL (CLOS), Scala, OCaml, and, yes, Python/Ruby/Javascript.

Assuming the conclusion does not help us to demonstrate it...

As for your point about "living together", I think the two would be much better off with normalized trade relations and an extradition treaty. Same thing for logical languages and the other languages -- let's get used to the idea of multi-lingual development, instead of multi-paradigm development in one big portmanteau language.

normalized trade relations and an extradition treaty.

I guess the former concerns sharing data structures and the latter is all about propagating excpetions between two languages, right? (I am only half kidding...)

Had to think about it a bit; but that really does seem to be the best interpretation of my metaphor.

While Haskell invites us to think of a "sea of purity" with impure islands in it, I think we're better off to have sea of impurity dotted with purely functional islands. We want a means of communication that works for pure and impure languages, for dynamic and static languages, for strong and weak languages, for lazy and strict languages -- and once again we see the wisdom, if not the finality, of the UNIX pipes idea. The filesystem offers simple structuring abilities -- directories for trees, hard links for more general graphs, pipes for streams -- that can serve in the absence of a real cross linguistic type system.

This leaves out a whole class of 'medium' types -- like Eithers or arrays of infinite precision numbers -- but that's where the normalized comes in. The array of double has universal value -- the Ruby Proc, not so much. To put it another way, not every national specialty travels well. To get a French wine in California? Not a bad idea. But French bread? I've heard of people doing that, but they're never going to get hot French bread...

The problem I see with the CLR, the JVM family of languages or other attempts to share rich type systems among languages is their inherent complexity and the need to tie the implementation of the language to platform. Why aren't ISO 8601 dates, for example, good enough as a 'date type'? If you need something smaller and more efficient, maybe you just need epoch seconds.

The microformats movement definitely pushes us in the direction of domain specific, cross-linguistic 'types' (or rather, formats); ASN.1 is the grandaddy of microformats. Normalizing trade relations is a matter of using named pipes and ramfs as an 'exchange' or marketplace, writing apps as congolomerations of pipe listening services (instead of modules), and using parser generators to efficiently process types based on their definition.

Of course, this does not offer the simplicity of a shared data structure approach -- it demands familiarity with IPC, parsing, grammars -- not a lot, but some. It's not as efficient, either; though for big float arrays, you probably can't do better than a RAM filesystem for sharing. (That's what they do on Linux, anyhow.)

All this talk of filesystems and IPC does beg the question -- where does PL theory end and operating systems research begin? I think persistency, data sharing and distributed computing are the bridge between the two disciplines.

All this talk of filesystems and IPC does beg the question -- where does PL theory end and operating systems research begin? I think persistency, data sharing and distributed computing are the bridge between the two disciplines.

And robustness, security and recovery (all somewhat related). Few languages have processes which can be used to isolate and recover from mutually suspicious/malicious code.

And robustness, security and recovery...

Yes, I agree. It's said that Alan Kay will write a "bare metal" Smalltalk in 20,000 lines, which will provide all of its own operating system services, &c. If you can make writing operating systems cheap and easy -- virtualization helps with this -- than you definitely ease integration with your language environment; but it doesn't do much for sharing data. We might all be better off if "separation of concerns" came into play with persistency and security -- we leave those things to OS designers, to filesystems writers -- and the language designers can focus on their ideas about types.

An experienced "speaker" of Ruby -- like myself -- can tell you as much about usage patterns in their language as an experienced speaker of a natural language.

Really? Should it be "bag" or "sack", "hood" or "bonnet"? In PLs and NLs aren't idioms at least in part regional?

Ruby Parsec is a monadic parser combinator for Ruby. Does the average Ruby programmer consider it idiomatic? Who knows, but probably not. Does the average Ruby Parsec hacker? Who knows, but probably. Is it functional? I leave that to you.

Python as-is will not going to be "FP oriented" any time soon. This doesn't imply an empty intersection of feature sets of course.

With both first-class functions and pervasive support for generators, Python offers better support for FP than any of the other "scritping languages". Not saying I'm happy with it -- but if you must choose your poison...

The slate of languages in this particular space (Python, Ruby, JavaScript) would also need to include Lua. Some would weigh in that Lua comes closer than the other three to being FP savvy. But then I don't think any of these should be classified as FP languages - unless one is willing to make the term over-encompassing (and therefore somewhat useless) as a means of classifying languages.

Another data point we could throw into the mix would be the Oz programming language. IMO, Oz provides better facilities for declarative and functional programming than any of the above scripting languages. But, oddly enough, the kernal in Oz really doesn't have functions. Functions in Oz are syntactic sugar for procedures with a parameter tacked onto the end. So the question is whether a language that can do everything we assign to functional programming could be considered a functional programming language even though the kernel has no concept of functions?

Speaking about this field without mentioning Perl would be pretty incomplete...

Perl offers very good facilities for FP, better than Python (anonymous function are first-class in Perl). map() and grep() are part of the language and some features like prototypes allows for limited higher-order function with a very convenient syntax, without special syntax you still have complete HOF (just a little bit uglier).

Of course, Perl isn't really good at referential transparency or limitation of the stateful computations (though the $_ bit looks pretty much like a State monad in most case).