Moserware

I think this roughly reflects my philosophy in languages as well. You basically have two options: you can bend your problem to your language or your language to your problem. The former is epitomized by Java and Python--all Java and Python code looks the same, regardless of what it's actually doing. The latter is the domain of Lisp and Haskell and Forth and so on.

I'm unabashedly in favor of the latter.

Ultimately, it's easier to reason about some domain in that domain. I would love my code for any particular project to look very similar to what I would write on a whiteboard when solving the problem. If I'm solving something inherently mathematical, I want the code to resemble math notation. If I'm writing some parsing code, I want it to resemble a grammar. If I'm writing an interpreter, I want it to resemble the operational semantics of the language. This fits into more "practical" domains as well: if I'm writing a web app, I want the routing to look like, well, routing and the database code to look as close to the database structure as possible.

Any details in the implementation rather than the domain should be separated from the domain logic. If you're trying to make the domain logic mirror the domain itself, this is essentially inevitable. This makes your code more general and easier to debug. You can redirect your domain logic to a different backend, and it's much easier to figure out whether you have a problem in the implementation or the logic.

More generally,…

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-part-3-of-3.html?showComment=1208359740000#c3537318119823933797

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.

From reading about DF, and especially the NYT profile of DF and the creators, I get the strong impression that DF is very much being done the hard way, even ignoring the C++ aspects, and one could cut down the complexity tremendously with good abstractions and things like DSLs.

(Think the Viewpoints OS strategy - with good enough abstractions and DSLs, you can do an OS or languages in very small sourcebases; I'm still in awe of their TCP/IP strategy - parsing the RFC illustrations! http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html )

That would be a project worth doing.

I'm reminded about the STEPS report of using ascii art from the rfcs as a DSL for describing tcp:

Writeup/comment:
http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html

Comment thread:
https://news.ycombinator.com/item?id=846028

The vpri texts:
http://www.vpri.org/writings.php

Appendix e and section "A Tiny TCP/IP Using Non-deterministic Parsing" of "STEPS Toward The Reinvention of Programming: First Year Progress Report, December 2007.":

http://www.vpri.org/pdf/tr2007008_steps.pdf

Does implementing TCP/IP stack using the RFC (as in parsing diagrams straight from RFC) counts?

Then it was done in OMeta [1].

Previous discussion: A full TCP/IP stack in under 200 LoC (and the power of DSLs) [2].

There's also a PNG parser (but it is not parsing any documentation) in 20 lines of OMeta [3].

[1] http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html

[2] https://news.ycombinator.com/item?id=846028

[3] http://joshondesign.com/2013/03/18/ConciseComputing

I did it many times elsewhere in this thread already.

For example, this one: http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html

Or Nanopass itself, not just as a tool for building DSLs, but as an example of a nice and clean DSL (of course, if it could bootstrap itself it would have been even better):

https://github.com/akeep/nanopass-framework

Or everything you can find in my github repositories (username: combinatorylogic).