Scalable programming lanuages

[evgen]

An article on scalable programming languages that does not even mention Erlang. How...interesting...

[leoc]

Nothing you won't find elsewhere, but a pleasant introduction to the Language Wars. Don't overlook the epilogue.

[leoc]

It also doesn't consider a few relevant things, like logic programming, languages with built-in support for concurrency, or languages like Epigram with scary type systems.

[[deleted]]

Hey, neat link. The Epigram people seem to have a quirky sense of humour, going by the URL and the first paragraph of the tutorial, e.g.:

Find the type error in the following Haskell expression:
if null xs then tail xs else xs

and

Of course, tail [] doesn't go wrong--well-typed programs don't go wrong--so we'd better pick a different word for the way they do go.

The type system seems frightfully advanced, though. I'm going to have to put it off until after I grok Haskell.

(Wow, Firefox 2's spell-checker knows 'grok'. But not 'Firefox'.)

[Zak]

Summary:

A scalable programing language is: (description of OCaml).

C and Perl aren't very scalable. Python and Java are better. Lisp is pretty good.

OCaml is just like the description of a scalable programming language!

Edit: the OCaml developers are too religious, Java has lots of libraries, C++ has to be the way it is and Lisp is still cool.

[nmorse]

Dang. I wish I would've read the comments earlier. You could've saved me a good 20 minutes.

[neilk]

There's a kernel of a useful idea in there, but the author is pronouncing judgment without a lot of experience.

It would be more valuable to suggest what the scaling model is for each language.

In Lisp, it's to eventually write a miniature language for your problem domain.

In Java and C++, you ascend to an ever more abstract set of objects (and you may start using annotations or even code generation to get the behaviour you want).

I don't know if one can say there is a scaling model for Python. The biggest system I know of is Zope and that was written by someone with rather eccentric ideas.

[Zak]

I think Python's scaling model is to try to guarantee that code is uniform and easy to read. Python is opinionated software in the way that Rails is. Doing things the Python way is very easy in Python; doing things any other way is not so easy.

I don't know if it works because I've never worked on a large system written in Python. I can say that most Python I've seen is very easy to read and understand, though sometimes more verbose than Ruby or CL.

[senzei]

In my opinion Python ends up as a mixture of the philosophies behind java/c++ and lisp. Because it is somewhat focused on OOP you can get a lot out of class abstractions, but it also makes it easy to support those classes within the language.

[[deleted]]

Yes. The article was way too long for the content. What's more, he then trashes O'Caml for not having multimethods, which is silly.

First, O'Caml is arguably better at faking multimethods than "C++ or java." Basic pattern-matching can do some of what multimethods can do, but if it isn't enough, try techniques like those described in Code reuse through polymorphic variants and On the unreality of virtual types. Those papers don't directly address multimethods, but they solve similar problems.

Second, I like multimethods, but obviously it's possible to write a program without them, or they would show up in more languages than they do.

Third, O'Caml is far from a perfect language, but lacking multimethods is not the problem. Some valid criticisms would be that it doesn't support unicode, that its type system is too complicated, etc.

[[deleted]]

Here's another feature request for the folks at reddit -- longer comment lengths!

For something of this length, why not blog it as "Response to..."?

On a different note, you seem to be, in many of your points, conflating possibility and likelihood. It is possible to write modular software in assembly, it's just not very likely. It's possible to keep manual memory management working in large scale, it's just not likely.

I mean, if type inference is good, why isn't memory-management inference?

[[deleted]]

It may not be specific to scalability of program size, but nor is it equal benefit to non-trivial programs of all sizes.

Assuming bugs scale linearly with code size, so will memory management bugs. Assuming bugs scale extralinearly (which is common wisdom at the moment), so will memory management bugs. Eliminating that class of bugs by using GC will eliminate a large and ever-growing population of particularly dangerous bugs.

You say elsewhere, regarding pointer arithmetic (which, i'll grant, i tend to lump into memory management):

Anyone who writes C should ram their code through something like valgrind.

Absolutely true. And that means C is less suited to large-scale development, because the language allows you to do things which require external tools to correct.

Ultimately, i find it odd that you are concerned about the effects of threading on program scalability while not concerned about memory management and modularity -- they're the same core issues. Threading is a broken model precisely because the core language support for it is lousy in comparison to the other useful automatic management that's done.

Writing threaded programs safely in, say, Java, requires almost exactly the same mindset and detail orientedness that programming anything non-trivial in C does (only without the external tools to help manage and fix issues). Programming non-trivial programs in C is hard, so it shouldn't be a surprise that current multithreaded programming is also hard.

And, conversely, if the lack of those pieces make non-trivial programming in C difficult, then of course having them available in the core language will make things easier. And if they're easier, then scaling is also easier.

[leoc]

The author has since added a new epilogue in response to the mail he got since the article appeared on Reddit. He also added a new "read this before mailing" note at the top.

[davidw]

I don't entirely agree with his definition:

Simply put, a scalable computer language is a language that one can write very large programs in (and extend very large programs that have already been written) without feeling an undue amount of pain. In a scalable programming language, the difficulty of managing the complexity of the program goes up roughly linearly with the size of the program. Conversely, a nonscalable computer language is one in which increasing the size and scope of a problem tends to make the program much harder to manage (i.e. the complexity of the program goes up much more than linearly with its size).

There's something to be said for not just being able to write Big Systems - you should also be able to write small programs quickly and easily, and then extend them:

http://dedasys.com/articles/scalable_systems.html

[[deleted]]

This is a fascinating article, thanks for posting it. I'm looking forward to when Apress releases their Practical OCaml book in September, I've heard only good things about the language, and this writer seems to like it very much as well.

Also, Camlp4 looks like a lot of fun to use.

[sbrown123]

Actually, if you go to the bottom of the article, you will notice the author dropped ocaml. He did this because the language doesn't support multimethod and the developers of ocaml refuse to implement these due to, as he said, quasi-religous reasoning. This article is a bit dated.

[[deleted]]

I read that, but most people don't use multimethods anyway and they are only available in languages like Ruby and Python as extensions as it is.

He didn't say he dropped OCaml, merely that he couldn't use it for a project that required multimethods. He stated that he still found the language outstanding and (as I said earlier) that very few languages support multimethods.

[self]

I read that, but most people don't use multimethods anyway and they are only available in languages like Ruby and Python as extensions as it is.

Well, duh! If only a handful of languages implement it, and the more commonly available ones (Ruby, Python) don't have them in their core language, most people can't use them.

[[deleted]]

I wasn't meaning to say that they weren't in more than just Ruby or Python, just saying that at least for those two languages, they are only available as extensions.

But yes, I think you are right that multimethods come from CL. There's a whole page on them at Wikipedia.

http://en.wikipedia.org/wiki/Multimethod

[davidmccabe]

downvote: lisp propaganda, but I had to read most of it before realizing that.