Hacker News Reader

> So, how come Ruby is more marketshare than, say, SML?

How much of that still applies if you take away Rails (and all the marketshare that came from it, and all the resulting tools, etc.)? Having a killer application makes a big difference.

The killer application of SML seems to be teaching, and awesome compiler research. With all due respect to SMLers, that's much less likely to interest hordes of average web developers.

Separating a language from the things you build in it kinda misses the point of the language. Ruby inspired / allowed Rails. Sadly, Lisp and SML haven't have powered anything of similar popularity.

And I think this is what the author was saying. In Lispland you don't get something like Rails, you get a bunch of 80% solutions, all different.

Separating a language from the things you build in it kinda misses the point of the language.

What if the things you build in it are all largely similar, mostly small variations on a common theme?

It's the difference between "Foo is a great language", and, "Foo is a great language for building applications that do Bar."

"How much of that still applies if you take away Rails"

Why no rails in lisp? I think the essay gives a good answer to that question.

I have no idea what Rails actually does, but I recently wrote a web application for a school project in Common Lisp, using just libraries (Hunchentoot, LML2 and Postmodern mostly) that aren't really meant to work together in any significant way, and I can't imagine the programming of the application would've been made any easier by using any sort of "framework". And I only wrote one macro if I remember correctly. So perhaps in some sense Lisp doesn't need "rails", good libraries are enough. Anecdotal, I know.

this explains it all ;)

"I'm always wary of arguments along the lines of 'we weren’t successful because we were too awesome.'"

What do you mean by "we?" Implicit in the Lisp Curse is the distinction between the Lisp language and its users. Furthermore, later in that essay, I wrote:

One result of these secondary and tertiary effects is that, even if Lisp is the most expressive language ever, such that it is theoretically impossible to make a more expressive language, Lispers will still have things to learn from other programming languages. The Smalltalk guys taught everyone -- including Lisp hackers -- a thing or two about object oriented programming. The Clean programming language and the Mozart/Oz combo may have a few surprises of their own.

Note the use of the words "even if" in that first sentence. That means that I'm open to the idea of there being a more expressive programming language than Lisp. Especially after taking a look at languages such as Clean and Mozart/Oz (which I learned about by reading Hacker News). And if such a programming language doesn't exist, then (as I wrote in that paragraph) Lispers would still have to have a measure of humility.

Remember that the essay focuses on expressive power, but no one claims that that is the only thing that matters in a language. I did not imply that much. Paul Graham has noted that libraries are probably more important than the base language, nowadays. I took pains to point out that Lisp hackers aren't innocent. Re-read the section where I compared Lisp hackers being satisfied with Emacs and Smalltalk hackers having stellar development environments.

> For instance, Qi's type inferencing engine is Turing complete

Why is that good? Decidability is a nice property of a type system...

It's not good, it's very bad. Haskell researchers spent years, in fact, attempting to make sure that it was both decidable and ran in less than exponential time.

The fact that some people actually think an undecidable type system is an advantage is simply an astounding disconnect from reality.

This is also an issue in Dependent Types. But the case is not as clear cut as you paint it as some argue that the expressibility lost and complexity gained in the system by forcing type checking to terminate is not worth it in practice.

http://www.seas.upenn.edu/~liminjia/research/papers/lambda-e...

I'm aware of differing opinions, I just think I'm right ;)

Did they succeed? I vaguely remember a lecture last year where the lecturer told us that type checking in SML was exponential in the worst case ..

Type annotations have reduced those cases to very rare instances, but yes there are still cases where the type checker can produce exponential runtime.

"So, how come Ruby is more marketshare than, say, SML? Could it possibly be that most people just find it easier?"

Marketing. Hype. And the familiarity of Ruby's Algol-like syntax.

Recall that before Ruby (and Python) became popular, the scripting language world was ruled by Perl. And most programmers were pretty happy with that. Perl was a mature language. It had tons of libraries. And it generally did what people wanted.

Then, out of nowhere, started a litany of "Perl sucks!" screeches, mostly coming out of the mouths of Python and Ruby fans. By now they've repeated that mantra so often that it's become dogma throughout much of the rest of the programming world, even (and often especially) for people who've never even written a line of Perl.

Ruby and Python took that anti-Perl hatred and rode it all the way to the bank.

Sure, Ruby also had Rails.. which was yet more hype. PHB's started ordering their websites to be written in it, despite having not the faintest clue what it was. Much the same happened with Java.

As for Lisp and SML. They suffer from being "just too weird".

It'll be interesting to see what happens with F# in the long run, as it suffers from much the same "weirdness" as SML (being based on OCaml, which itself was based on SML). Will having a megacorp behind it make enough of a difference?

Then, out of nowhere, started a litany of "Perl sucks!" screeches

Nowhere? Haha, I was there and I'll tell you how it was: a whole bunch of people who'd started writing Perl in 1994 for CGI scripts had cause to revisit their own work a year or 5 years later to maintain it or to add features and found it utterly incomprehensible. The experience burnt us so badly that we all went looking for languages that were less "write only". Python and Ruby had been around for a while at that point, but they got a huge boost from people fleeing Perl. And most of those people are still using Python and Ruby today.

Perl was and still is a great language for what it was intended for: automating system administration tasks, and reporting on them, stuff you can do in 50 lines of code. But for 50,000 line applications worked on over 10 years by dozens of different people, it was never a good choice.

"a whole bunch of people who'd started writing Perl in 1994 for CGI scripts had cause to revisit their own work a year or 5 years later to maintain it or to add features and found it utterly incomprehensible."

You can write garbage in any language. If these people found their own code incomprehensible, it's their own fault.

"But for 50,000 line applications worked on over 10 years by dozens of different people, it was never a good choice."

I've yet to be convinced that Ruby or Python are any better. In many ways they're even worse.

Yes, you can write anything in any language that's Turing complete, but that's not the point. Perl's mantra is "there's more than one way to do it", and so you get code that does it a million different ways. Python emphasizes there being only one right way, and so Python code is inherently more maintainable.

Python code is inherently more maintainable.

Even Python 2.7 versus 3.x belies that.

Does every Python programmer use the same sorting mechanism? Object decomposition technique? File layout? Naming conventions? Web framework? Database? Testing strategy? Documentation format? Installation mechanism? Editor?

Semi-enforced consistency of indentation would have contributed very little to the maintainability of any project to which I've contributed. I care more about finding and understanding and modifying code than whether I need to run it through a tidier.

"Out of nowhere"? One of the perennial topics of the mid to late 90s was the idea that Perl needed major fixes to remove common pitfalls (e.g. the object model, syntax warts (nested structures are just horrid), etc) and be more suitable for large projects.

Years passed.

Perl 6 was talked about.

Years passed.

Nothing happened. People gave up and moved on. The same thing's happened to PHP - years of broken things not being fixed eventually causes people to distrust the language's future and prevented it from moving into new niches.

Lisp is more complex, with far more redeeming features, but by now it shares the same failed-promise challenge: I've been writing software for a couple decades, so I missed out on the early history of Lisp, but for most of that time I've kept hearing about how great it is and how it'll soon be as productive as the inferior languages people actually use to get work done - and that point's always been in the future, never the present. Clojure is the only potential exception which I see to that and, to be honest, a large part of that would be due to the Java community's foundation.

Nothing happened.

See http://onyxneon.com/books/modern_perl/ for another view of Perl 5 history.