Comment by 10ren | Hacker News Reader

Comment by 10ren | Hacker News Reader

It was a risk though, because I had to trust that I understood the problem domain well enough to invest a lot of time in the parser/interpreter. - First comment on blog http://www.moserware.com/2008/04/towards-moores-law-software...

Solving a problem is hard. Generalizing it to a class of problems is harder. Encapsulating it in a language with specialized syntax and semantics is harder still.

I think this is one reason that DSLs are not that popular, and is one reason why most new languages mimic existing languages like crazy (apart from for user-familiarity to ease adoption). The exceptions, like brainfuck and lolcats, use familiar semantics; and are only novel in syntax.

As for a Moore's Law for software, I'm going with Fred Brooks' Law of "No Silver Bullet". Complexity is hard, the best we can do is abstract away foundational concepts into components, as we understand them, and then SOTSOG.

The TCP/IP diagram syntax is really cool - but because it's clear, not because it's short; I think the parsing code in C would actually be shorter than the ASCII art.

Given that DSLs are hard, it does not follow that sticking "foundational concepts" into "components" is a better strategy than DSLs. If you write a DSL, you are standing on the shoulders of real giants. If you rely on components, you are going with the recently formed current conventional wisdom, and you are standing on the shoulders of relative peons.

Note that Fred Brooks argues for conceptual integrity, provided by a single human being, as the most important guarantee of product quality. If you use components, then you are accepting a system partitioning that has been decided many layers above you. If you design languages, then you cut out most of those layers. This gives you far more control over product quality.

Yeah, it's hard. Quality is hard. If your primary goal is anything other than quality, you will probably not produce a product with much of it. That's the real reason why there's no silver bullet.

"If you write a DSL, you are standing on the shoulders of real giants."

In what sense do you mean that? Serious question, not sarcastic. It seems to me that if you build a DSL you're not standing on anybody's shoulders, which seems rather a disadvantage, but I say this to show you what I'm not understanding in your point, not as a criticism, as I believe you meant something else.

You are standing on the shoulders of people who design languages, vs. standing on the shoulders of people who write libraries. Languages are much closer to the central concepts in computing, and the people who work on them have done a lot more careful and general thinking, in general, than what goes into libraries. Libraries are great to build on, but only so long as they are almost exactly what you need already, because you can't change them to any significant degree.

There's a reason why all the best languages (lisp/forth/etc) are language building languages, not library building languages. A library building language is just a DSL that you can't modify. You can write anything in it, but so what? You can write anything in Brainfuck too - that's what the term "Turing tarpit" was coined to describe.

When someone tells you what their favorite language is, you should ask what that person does. If all they do is write web apps, they probably like their language because it is a good web app DSL. Nothing wrong with that, except that it doesn't scale (webapps scale, but they do it by scaling the database, not the language).

Reply on news.ycombinator.com