A-Z of Programming Languages: Erlang

The latest entry has Joe Armstrong discussing Erlang in the ongoing series of interviews with PL designers (The A-Z of Programming Languages). Two related things caught my eye. The first is the obvious truism about language features:

Removing stuff turns out to be painfully difficult. It's really easy to add features to a language, but almost impossibly difficult to remove things. In the early days we would happily add things to the language and remove them if they were a bad idea. Now removing things is almost impossible.

The other thing that I found intriguing was his mention of integrating version control into the language:

We have mechanisms that allow the application software to evolve, but not the language and libraries itself. We need mechanisms for revision control as part of the language itself. But I don't know how to do this. I've been thinking about this for a long time. Instead of having external revision control systems like Git or Subversion I'd like to see revision control and re-factoring built into the language itself with fine-grain mechanism for introspection and version control.

Not sure what he has in mind?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What Joe has in mind

Not sure what he has in mind?

Why, "Verlang", of course!

i dunno

1) it would be nifty, if possible, to start with a language design that makes it possible to move thing out to libraries, out of the core language, w/out breaking code?! maybe a command line option however that ways which old version to emulate, so that some libraries are included by default.

2) i haven't rtfa, but might it have to do with the hot swapping possibilities of erlang?

Something like L PL ?

Something like L PL? (this one is different from the L PL defined by the wikipedia, I guess there are two PLs named L).

Have a look at the 'while example', while is not defined in the language it self, but instead is a library/user definition.

There is a lot of languages

There is a lot of languages like this. Just read 20 threads of usenet://comp.lang and you'll be amazed at how parameter-obsessed some languages are.

However, don't think parameterizing everything gets you anything of value. This is the big mistake, in my humble opinion, the Fluid AOP people are making. I seriously heard them say something to the effect of, "instead of binary decisions, we need parametric decisions."

*smack forehead*

No. It's a complete shame that AOPs success -- generalizing blackbox code generators -- is now being taken in the wrong direction from what practitioners want. Whereas AOP generalized exit points in blackbox code generators, Fluid AOP wants to generalize blackboxes themselves, while addressing none of the real practical limitations of blackbox generators (as I understand it).

Nice to admit it

It's nice to admit it, but it would be better to RTFA IMHO.

ja, tho didn't help much

at least for me -- it is still a pretty nebulous comment by Joe.

although if i had to guess, it is not about hot swapping after all, it is more like perl/python's ability to require a runtime version?

still, unclear. would love to hear more detail.

We need mechanisms for

We need mechanisms for revision control as part of the language itself. But I don't know how to do this. I've been thinking about this for a long time.

I've been wondering about it too. In particular, how could it be done without the program running inside of an image? If it all runs in an image, it gets easier as the runtime is already in complete control and there has been work on safe live upgrade.

Perhaps the compiler could be integrated with a source control system, and should auto-compile upgrade code from the last tagged release.

What if...

What it every code change, and I mean, every, even adding stuff (procedures, functions etc) being considered a well defined refactor?

Quickly thinking we would have two kinds of refactors. One to improve the existing code without changing the behavior (or the final result?). This is to what the term 'refactor' usually refers to. And a second one that would be any other code change.

I think that the first one would always have to be explicit, but the second could optionally be auto-detected by the development or the version control environment.

This is pure speculation over stuffs I've been thinking about lately, of course.

Does anyone else notice the lack of background expertise?

Joe Armstrong is an incredibly bright person who has developed our generation's killer language for fault tolerant computing. However, he often lacks any degree of depth in knowledge outside his core concentration. For instance, his Why OO Sucks rant is just that: a rant with no problem domain expertise. In fact, that rant uses ridiculously bad problem domain models to prove a strawman argument (his Date model is not properly encapsulated and can be easily subverted by client API users!)

Likewise, the same thing here: Joe is outside his domain of expertise.

He is smart, and recognizes a problem, but he lacks the expertise at the moment to do anything actionable.

Not sure what he has in mind?

Maybe he doesn't either. Heck, he says, "But I don't know how to do this." He's simply a smart guy with a lot of pragmatic feedback for computer scientists who care to listen. He's describing a pain that a world-class programmer feels, and is surely a pain average programmers feel as well (but may not notice it as much as the "pain profiles" of the two stereotypes likely differ).

Bottom line: There are lot of people with crazy ideas out there. Execution matters.

As an aside, the earliest evidences I've seen of people advocating this idea in the mainstream was Toronto University professor Greg Wilson, in his ACM Queue article where he advocated XML Everywhere for programming.

Greg Wilson: “Extensible Programming for the 21st Century”. ACM Queue, November/December 2004-05.

Although Greg never really went anywhere with this idea, I like how he hangs his ideas off Guy Steele's super famous Growing a Language OOPSLA speech.

I know what I need

Basically what is needed is the capability to update a running image with a set of changes, and roll back to a previous release if needed.

Assigning a version to each function and storing a relationship graph (a release) in the system (image) would be a good starting point.