Hacker News new | ask | show | jobs
by sedachv 5836 days ago
"It's the difficulty of the macro-concepts that makes the most difference and most people find imperative programming and mutable state and infix syntax easier to handle than declarative programming and immutability and prefix syntax."

Where is the empirical data to support this?

1 comments

If by "empirical" you mean rigorous, double-blind style studies then obviously there aren't any just as there aren't really any for any serious programming language design questions.

The overwhelming (and it really is overwhelming) market preference is for imperative, infix languages with rich syntax. The extraordinary claim that this is purely circumstantial is the one that requires extraordinary proof.

No one who has taught functional programming to students has complained of higher failure rates. University students, high school students, middle school students, disadvantaged inner-city middle school students, elementary school, pre-elementary school (what do you think Logo is?).

In America, there is also overwhelming market preference for junk food. It doesn't mean junk food is better for you.

I don't think there's really much of an analogy between programming languages and food.

So what's your explanation then? If functional languages are no more difficult to learn and are more powerful why are they not used? Why have Python and Ruby flourished while Lisp and ML remain academic obscurities?

I still say the burden of proof is on the FP advocates. If you want to claim that everybody is doing it wrong you should have a pretty strong case.

"I don't think there's really much of an analogy between programming languages and food."

Programming languages are cultural, not technical, artifacts. For reasons why one language is used by more programmers at a given point in time than another you need to turn to sociology. Lisp has some clearly superior technical ideas, which is why it has continued to be used and expanded for the last 50 years, and why all the other languages you mention (Python, Ruby, ML) drew ideas there. On the other hand, a language like Perl (and as Python and Ruby will eventually be) is briefly popular, but has no compelling technical features or metaprogramming facilities for people to continue to use and expand it when another shiny new language comes along.

Programming languages are cultural, not technical, artifacts.

Sociology is a factor but that's wildly overstating the case. The fact that people prefer to borrow from Lisp rather that adopt it is telling. Many programmers are aware enough of Lisp to take inspiration from it but choose not to use the language itself.

There's a subtext of arrogance in the claims FP and Lisp advocates make about the popularity of various programming languages. In my experience most of those people don't actually write much code. I gave up on the Common Lisp community years ago after realizing that it was full of people that would rather sit around discussing how things should be than actually building something.

Clay Shirky talks about people knocking out an important app in 2 days PHP here: http://www.ted.com/talks/clay_shirky_how_cognitive_surplus_w...

I doubt very much that the typical Lisp crowd would have gotten past arguing which web templating library to use.

"Sociology is a factor but that's wildly overstating the case."

And how does anything you wrote after this sentence not support my argument?

A language like Perl ... has no compelling technical features or metaprogramming facilities for people to continue to use and expand it when another shiny new language comes along.

See the CPAN and especially modules such as PPI, Moose, and Devel::Declare.

And that still hasn't stopped the Perl 5 community from feelings of inferiority (see http://blogs.perl.org/users/ovid/2010/03/perl-5-is-dying-a-f... for example), and more importantly it hasn't stopped Perl 6 from being built. Which is a shame, because I would much rather have seen something like Perl on Rails, or in any case work going towards building on all the stuff already there in CPAN instead of duplicating all that work in PHP and then Python and then Ruby and then maybe even Perl 6 sometime this decade.