Hacker News Reader

Comment by jfe | Hacker News Reader

i feel like each "new" general-purpose language project is just nipping at the boot-heels of the much bigger problem of constructing large-scale systems that can be fully understood by a few (2-3) people.

VPRI's research has shown that one important method for constructing large-scale systems that can be understood by small teams is to have a pipeline of problem-specific languages that express major portions of the system. they were able to reduce LOC for a typical OS with networking and graphics by 3 or 4 orders of magnitude.

general-purpose languages can't compete with DSLs in terms of expression, and yet we keep inventing them. i think our lack of imagination is starting to show. compilation and language design will need to become much more common-place if we expect to continue scaling up.

a tower of babel in computing is healthy, no matter how much employers want us to be easily-replaceable cogs in an IT machine.

View on HN

(1) This language has been invented long ago; its name is Haskell. Eta is a JVM backend / target for it.

(2) A good general-purpose language is good at creating pseudo-DSLs, also known as abstractions or APIs. This can include customized syntax, but usually it's not a brilliant idea. DSLs using the common syntax are quite prevalent in Lisp / Scheme / Clojure, or in Ruby. Haskell is reasonably good at creating DSLs, much better than e.g. Java.

I think it might interest you that Haskell-like languages are one of the best languages for programming EDSLs after Lisp-like languages. If I recall correctly, Standard Chartered uses an EDSL written in Haskell that's maintained by ~10 Haskell programmers and the remaining ~90 people program inside of this EDSL for specifying new rules. Similar case for Facebook and their spam filter rules.

The hard part is finding the right abstractions on which to build your large-scale system. When you have those abstractions, you can build a DSL to help you implement your system. Or you can build an API for an existing language. They are two sides of the same coin and I can see arguments for / against either approach.

I think where your criticism is really valid is that they are building tools that they think will help them address the real problem. But it's not clear that they have a real problem yet and that they fully understand it. If they do and Eta is their "DSL" to solve it, then that's great.

I have way too often fallen into the trap of finding (or dreaming about) the right language / IDE / etc. to solve my problem instead of actually working on the problem and gaining a better understanding of it. It's so easy to spend all your time on technical details because it's fun when you really should be worrying about the stuff that pays the bills.

I agree with this personally, but if you read through VPRI's publications you will find that the vast majority of their DSLs seemed to converge to "functional with some special features (which you could implement in Haskell using monads)". This is especially interesting, since in early publications they started with a number of truly different designs.

I think general purpose languages have primacy because they have the flexibility to allow the author to create a DSL for the problem domain being addressed. I.e. Bottom up programming.

every framework we use -- library, language, runtime, operating system, hardware -- makes decisions that constrain what we can express.

languages like haskell, lisp, or ruby may make it easy to create new control structures that blend well with the existing syntax, but new control structures don't help if it's still annoying to write, say, very long lines of free-form text -- a problem that xml handles more gracefully than lisp. syntax makes a difference.

i think it's unlikely we'll win a several-orders-of-magnitude decrease in complexity by confining ourselves to the syntax decisions of one language.

Wait. VPRI made an OS?

Reply on news.ycombinator.com