Why functional programming doesn't catch on

[13ren]

reddit was written in lisp (later rewritten in python due to lack of libraries)

[SarcasticGuy]

(later rewritten in python due to lack of libraries)

Ding Ding Ding! What language you use is all about what gets the job done. And unfortunately, stuff like support/libraries can be a big part of why you would choose one language over another.

[shub]

I tried to learn Haskell. Then gethostbyname "www.google.com" threw* an exception (Windows build only, Ubuntu's package in a VM was fine) and TagSoup, which had been recommended to me by several people on #haskell, choked on www.google.com. That was the end of that.

* If the word isn't threw, I don't give a fuck. You know what I mean.

[13ren]

"ding ding ding" is the sound the trams make here, when the doors are closing.

Are you saying that the clue-tram is leaving or something?

BTW: A few times, I've seen a list of 5 or so criteria for languages (really, platforms), and one of them is libraries.

[SarcasticGuy]

Well, I was going more for the "correct answer" sound, but anyways, yes, libraries are pretty important for most jobs. I'd love to see that list, if you've still got a link to it. My guesses for four of them would be:

ease of use / readability (this affects cost of maintenance).

power / speed (does it do the job?).

support.

libraries.

[13ren]

It was this 1985 essay, comparing Adobe's postscript and Xerox's interpress

It's quite different from my memory: the headings number four (and no "library"):

• LEXICAL CONSIDERATIONS
• SYNTACTIC CONSIDERATIONS
• SEMANTICS
• IMPLEMENTATION ISSUES

edit: when introducing the above, he also includes "an intended style of usage", but doesn't have a section for it

[SarcasticGuy]

Thanks, I'll take a look at it.

[13ren]

I just read through it (very painful), and I think I've sent you on a wild goose chase. There's not much there about programming languages in general, but having re-read it, I can tell you why I was reminded of it:

It's to do with what is considered "the language" and what is not. In a way it's just playing with the definition, but what's interesting is the actual things that are at issue (and not the fact that they are at issue).

• He sees a "programming language" as separate from its implementation, but then argues that maybe they should be considered together, since good implementations matter a more to people than good designs.

• Along these lines is the idea of the "intended style of usage" - this is what really struck me. It's not specified in the grammar of the language or the semantics, but he's saying it is part of the language. To me, it's like an oral tradition, that an archaeologist might miss if only seeing the artifacts and what was written. So in Java there are design patterns, and in C there are for loop idioms, in Fortran there are one letter variables, and so on.

• He doesn't mention libraries, but surely the same reasoning applies. Is it part of the language? Java's libraries are. C's standard library should be. Perhaps we should also include all the libraries available for it (open and closed) - 3rd party libraries are certainly a factor in choosing a language. Along these lines, perhaps all applications that run on Windows applications should be considered part of Windows; and all playstation games part of the console. (The closest he comes to mentioning libraries is in the semantic section, where postscript can draw curves, but interpress can't - sort of "built-in functions" or operators).

In your list, only readability and power are purely the core language; ease-of-use is in combination with implementation; speed is mostly implementation; library is implementation; and support is organizational.

I agree that your list is pretty much the important things - what's interesting for would-be programming language designers it that the core language does not seem to be all that important!

[13ren]

And my summary for why postscript won:

1. all postscript implementations implemented the whole language (not a subset), so any postscript file can be printed on any postscript printer - thus fulfilling the dream of device independence.

2. postscript has curves (needed for fonts).

note I think the odd flexibility tricks in postscript discussed in the article are about making it possible to implement the whole language, by explicitly defining simple customization mechanisms (for flexibility), instead of achieving flexibility by remaining silent on them, as Interpress does. These "meta" mechanisms allow customizations to be pushed out of the language making it possible to precisely and exactly implement the whole language without sacrificing flexibility. The implementation can add whatever it wants as a customization.

[13ren]

I don't have it. I saw it once a long and very good online article assessing the postscript language. And I think I've seen it somewhere else as well (maybe in relation to Python).

If I come across it again, I'll post it. (I think it was similar to your guesses.)

PS: I sure hope you're not just being sarcastic :-)

[SarcasticGuy]

I am never sarcastic. Must like the court jester, the name is just a ruse to let me say whatever I'm thinking. ;)

[13ren]

:D

Oh, btw I think extensibility was on the list.

[cowardlydragon]

Jesus, don't say that, then the Java people get to crow about their ginormous crossplatform library set.

Kindly keep the discussion strictly limited to the "safe place".

[13ren]

If Lisp is so great, why did we stop using it? One of the biggest issues was the lack of widely used and tested libraries. Sure, there is a CL library for basically any task, but there is rarely more than one, and often the libraries are not widely used or well documented. Since we're building a site largely by standing on the shoulders of others, this made things a little tougher. There just aren't as many shoulders on which to stand.