Lambda the Ultimate

inactiveTopic Language Construction
started 12/8/2003; 10:42:51 AM - last post 12/9/2003; 11:53:31 AM
logarithm - Language Construction  blueArrow
12/8/2003; 10:42:51 AM (reads: 259, responses: 5)
Language construction has been an interest of mine for some time. The design of languages and compilers is fascinating. Some people use lex and yacc and program their compiler or interpreter in C; some people come up with LR parsing schemes on their own; some code it all by hand. I was wondering if many others here have the same itch that I do, and what's interesting about it for them?

This also partly addresses a pet peeve of mine. People who really like alternative languages (for example, Haskell) seem very likely to be people who want to construct compilers or interpreters for said languages. You've got 5 or 6 Scheme implementations floating around, 3 or 4 Haskell implementations, but not a relatively large amount of development work (that I know of) using the languages for purposes not relating to (1) parsing them, (2) optimizing them, (3) or compiling/interpreting them. Am I right -- how can this situation be changed?

andrew cooke - Re: Language Construction  blueArrow
12/8/2003; 11:35:46 AM (reads: 248, responses: 2)
The Haskell community produces an annual report that describes how Haskell is used. The current version can be downloaded here (html version directly). I think the original aim was for this to show how widespread Haskell use is. However, looking at it with fresh eyes, there is an awful lot of general development work and comparatively little commercial use.

I think that shows that Haskell isn't widely used in industry. Which is a pity, but probably doesn't really surprise anyone. On the other hand there are a lot of projects there - it's clear a lot is going on. A lot of code is being written with Haskell, even if much is toolkits, compilers, tracers, etc.

Is this a bad thing? It doesn't worry me. The language seems to be flourishing, even though the core development seems to be done by a worrying small number of people (what happens if SPJ is run over by a bus?). It's clearly possible to use it to develop quite complex systems, since some of those projects are, indeeed, complex systems. So the "problem" is more the lack of "commercial" use.

If you want to change that (personally, I think it can change by itself) I suppose you should try to guess why people don't use it commercially and work to remove those obstacles. One reason might be GUIs. Another might be "propoganda". The trouble is that there are as many opinions about this as people (maybe this is a lower bound - I can change opinions on the subject at whim).

One thing I am considering doing, is using Haskell at work as my scripting language. Others have done so. At the moment I use Python, but as I become more fluid with Haskell (and IO), I am beginning to think it possible. Since my employers regard Python with hostility anyway, I doubt Haskell will be more of a problem - they are both horrible modern flash-in-the-pan languages to them.

Andris Birkmanis - Re: Language Construction  blueArrow
12/9/2003; 12:17:56 AM (reads: 214, responses: 0)
For our Web-app DSL we do not use parsers (err, not primarily). Instead, we provide several graphical editors for manipulating graphical expressions (a full IDE in fact), so in a way it's the application developer who builds AST, not a parser. Also, the DSL/IDE is targeted for internal use, so there is no problem with propaganda. The users still provide a lot of feedback. Looks like ideal conditions for growing a language, eh? ;-) Being so close to industrial use is not unstained blessing, though - there are times when instead of saying "no, this does not fit into design" you have to accept the push. Another problem the business-orientedness brought is the target language. Compiling to Java is not the funniest thing to do. All too often I wish it had lightweight closures and continutions :-) If only Scheme implementations on top of JVM were a bit faster :-)

Ehud Lamm - Re: Language Construction  blueArrow
12/9/2003; 10:21:34 AM (reads: 172, responses: 0)
Am I right?

Actually I think you are wrong. It is a frequent observation which is worht debunking.

When you normalize the amount of work being done per the size of the user population of each language, you see that there's quite a lot of work on scripting, web development, numeric processing etc. being done using Scheme, Haskell etc. Others here may want to mention their favorite projects.

The second reason people tend to feel the way you do is that compared to other groups PL enthusiasts using so-called niche languages are, obvsiouly, more interested in PL technologies. Thus, in these languages you find more work on compiling, optimizin, partial evaluation etc. It is easy to jump to the wrong conclusion and assume that this comes at the expense of "real" develoment work. But this is not valid reasoning.

Please notice that I am not saying that all languages exhibit exactly the same distribution of projects. But the situation is much more nuanced than the one you describe.

Notice by the way that when the size of the group increases dynamics change. For example, you can see many nice PL-centered projects based on Python, but there's also, of course, plenty of classic software being developed.

Some related links:

Functional Programming in the Real World


How to Use Scheme

Ehud Lamm - Re: Language Construction  blueArrow
12/9/2003; 10:42:03 AM (reads: 166, responses: 0)
using Haskell at work as my scripting language

Now that's an interesting question. Haskell or Scheme, which should one choose for scripting work?

Manuel Simoni - Re: Language Construction  blueArrow
12/9/2003; 11:53:31 AM (reads: 161, responses: 0)
I also think this is not right. From the niche languages I am a bit familiar with, Scheme and O'Caml, I'd say there's lots of interesting things going on that aren't PL technology related.

Scheme has actually dozens of implementations, libraries - SLIB, and real world projects - the Scheme shell, the the Scheme constraints window manager and many more.)

Besides the interesting projects of the O'Caml team at INRIA, there are two large collections of "real world" O'Caml applications and libraries: and