Lambda the Ultimate

I think Erlang style features (immutable message passing and lightweight processes) can be added to any language as easily as threads, which are almost but not quite orthogonal to other language features.

When does addition of such features make a new language? In theory, any language might become the Erlang of the future when used suitably. Is the change larger than adding oo or strong types to a language? Or smaller?

(Let's use the phrase "nature vs nurture" or n-vs-n to describe the conundrum of whether a language makes it easy to do something or not based on "DNA" alone, rather than needing something bolted on. Every Turing complete language can do anything by nurture — only some do so easily by nature. Please take all my comments modulo the n-vs-n meme so we don't make another n-vs-n thread.)

In essence, I think it's useful to discuss the semantic effect desired in Erlang independently of the language. We just haven't a coined buzzword for it yet, like oo or types. Aren't the key words async, immutable, and message? That would spell aim, with the disadvantage it's an English word. (Ambiguity doesn't help terms.) You could call Erlang's style aim-oriented, or xyz-oriented for some other combination of good acronym letters.

Don't the Erlang guys call it Concurrency-Oriented-Programming?

Lightweight Message Passing (LMP), (LWMP), which has the nice property that it's hard to tack oriented on to it :) Doesn't really emphasize the lightweight processes part, which is unfortunate.

I would say that it should apply to CSP-like languages like occam and Limbo (I guess that's up for debate). Anyway, here are some test cases:

Limbo, occam and Erlang are LMP languages.
Termite is an LMP system based on Gambit scheme.
LmpLib is an LMP library for superlang.

Looks alright, doesn't seem like a sellable acronym though.

I think Erlang style features (immutable message passing and lightweight processes) can be added to any language as easily as threads

Not any language. Erlang-style concurrency requires processes to be isolated from each others' variables; that would be hard to add to C. It could be done, but it'd be more work than threads.

John Stracke: Erlang-style concurrency requires processes to be isolated from each others' variables; that would be hard to add to C.

I know. One must often simplify a lot to reduce comment size by a 1000 to one factor to fit in contexts like this. So in my post, by "easy" I meant something like "on the general order of difficulty as". And it's tempting to turn the word "process" into a long exegesis so you might allow my next remark, but I won't.

It could be done, but it'd be more work than threads.

Depends. Suppose C never had threads before, and your goal was to end up with both the pthreads API and implementation on all major platforms. And suppose you had to write the docs for pthreads, and bring folks up to speed. All that would be included in the cost of "adding threads to C" if you weren't able to ride on history.

I'd say that was at least as expensive as what you'd have to do in order to present a partial (as pthreads is partial) implementation of consistent Erlang-ish immutable message passing in lightweight "processes" in C. So I don't know why you bothered to disagree.

Now, if I was going to add Erlang style concurrency to another language, I'd actually be implementing it in C (or C++), giving me a "partial implementation" for the language in question only. I expect this will be easier than adding (say) pthreads to C from scratch. So I'd argue in the opposite direction you did. Split the difference? [cf]

...the PLs with the biggest upside (at the moment) are Scala and F#. Both try to leverage VMs that are in widespread use and play nice with code written in more widely used languages.

_{(History hasn't been kind to languages that might be unkindly classified as parasites, but I'm guessing that is bound to change at some point).}

Chris, the crystal ball never talks about qualities of PLs but always about brands. Java is the language for enterprise applications. C++ is for systems programming. Ruby is the language for Web 2.0. Erlang does concurrency right. JavaScript is for the web browser. Python glues and binds everything etc. These are brands, not "a good multiparadigm programming language for the CLR or JVM". In our beloved IT trash world of hope, hype and hystery this doesn't make a difference. An "academic" language is one where people take a look and say "oh, interesting" and move on.

Chris, the crystal ball never talks about qualities of PLs but always about brands.

Java is the language for enterprise applications.

C++ is for systems programming.

Ruby is the language for Web 2.0.

Erlang does concurrency right.

JavaScript is for the web browser.

Python glues and binds everything etc.

In our beloved IT trash world of hope, hype and hystery this doesn't make a difference.

What languages are we discussing now?

Well, we do discuss Scala and Oz quite a bit...

Part of the reason I asked my original question was that I am not sure LtU is as inviting to new members as it once was, and new views often come from new people with new ideas.

If it wasn't for Luke who educated us about Erlang, I am not sure we would have realizdd just how cool it was that early on.

Perhaps ML5 ?

I think the concatenative languages (Factor, Joy, Cat) are a whole lot more expressive than most of the languages being discussed. Or maybe it's time that true data flow languages make a comeback (e.g., Lucid).

Link fixed. Thanks.

Those are the same caveats that come with any interpreted language. The same examples are used by Python, as I recall.

Hmm, that's a good point, and could be addressed through non-interpreted implementations (although possibly "thread"-switching cannot receive the same speedup).

However, while I didn't delve into it further to understand, I assume things are worse in Erlang due to the need to copy data.

Does Erlang need to copy data? Its variables are immutable, so why not share them among processes? (As long as they're running in the same memory space, that is.)

John Stracke: Does Erlang need to copy data?

No, so sharing among processes is feasible as you suggest. Erlang processes appear to have separate addresses spaces because they can't test sharing in absence of mutation; so an implementation can choose. (Makes for location independence, e.g.)

Reasoning about options for processes in absense of mutation is entertaining. :-) But it's somewhat hard to talk about. I'm not speaking from Erlang experience. This is just the line of reasoning I explored a while back, and mentioned in another LtU thread.

Message passing can be implemented either way, and has been; there have in fact been several non-copying Erlang implementations over the years. The main problem is then to avoid long garbage collection pauses.

As far as I know, the practical experience so far has been that message passing by copying actually works well enough. But perhaps that's because we have adjusted our programming styles; also, who knows whether it carries through to all future interesting cases?

Processes have separate heaps because that makes it easier to impose per-process resource limits, to protect the system from one process that allocates too much memory, as Erlang aims to enable robust systems even in the presence of buggy code.

However, binaries (the type of raw byte strings) are shared in BEAM. They are allocated in a shared area, and reference counted (no worry about cycles). I suspect most of the really large messages in an Erlang system would be binaries, because file and network IO based on binaries.

I don't understand. What consequences might this have for programming languages?

This is a good question with a complicated answer. The LAP research is conceptual and doesn't usually get into computer codes, and it often sounds like linguistics, but the LAP objective is communication processes between computing agents (ie programs), often in an IT (information technology) setting. Examples are e-commerce, and contracting. It is concerned with modeling, understanding and properly representing these processes. I thought that this paper from the 2005 conference was interesting for taking a broad perspective. The discussion of objectivity vs actualism touches on some of the programming issues. A quick look will give you an idea of the types of programming that would be needed.

Briefly LAP programming will emphasize several styles: reactive programming, knowledge representation, and "information" processing. LAP is about knowledge, information and data. Now for the hard part. Information implies explicit use of situation (and/or state) as well as event representation. A useful overall style should embrace all of these issues. Language metaphysics and traditional practices often divide up these issues into separate conflicting categories.

My own conclusion is that both logic programming and event programming with situation are needed in the same language. There is nothing really hard about doing this but the logic programming community won't go there, (My opinion) and the imperative community is distracted by other issues. Oddly often the same issues but from a different perspective.

LAP really is a different perspective and it conflicts with existing practices. If you believe as I do that this is fundamental and important to the future of computing then it is time for a review of all standard practices in light of this theory.

In the mid-90's, I taught a standardized Erlang course to grunt programmers at Ericsson in four days. (I believe those programmers subsequently worked on the AXD-301 project, by the way.) That seemed to work out fairly well. At the end of the week, they were by no means experts, but ready to start working and continue learning. This was not by accident -- the designers kept Erlang simple and practical to make it easy to get started. I believe C/C++, to take a random example, would require far more effort to get to the same point.

So one should note that, first, even if it seems esoteric, a programming language need not be difficult to learn. Second, sometimes the big problem in getting up to speed may be to personally commit to actually going ahead and working with a language.