Micro languages in Clojure via macros and let | Hacker News Reader

Micro languages in Clojure via macros and let

will.groppe.us

20 pointsmacmac20 comments

In most general of terms a programming language would be ideal for a problem domain if the domains problems could be expressed directly in the language. You would sit down with the domain experts and have a conversation, that conversation could be converted directly to code. In fact if the language was expressive enough the experts could express the problems directly to the computer. No current language, that I'm aware of, achieves this goal. However Clojure by nature of it being a Lisp, allows you to easily add to the language to bring it closer to the domain it will be used in.

It's certainly no silver bullet, and does add to the learning curve of new programmers, but if used properly can be a great tool for writing concise and correct code.

My problem is that the code linked in the article looks ugly as hell. Even the micro-language created.

Compare this ...

    (filter (and (< :table1/a 5) (= :table1/b "x")) (collect :table1))

To this ...

    from row in table1
    where row.a < 5 and row.b == "x"

Also, compare this ...

    (collect :projects :invoices [:projects/id :projects/name 
           (as :inv_id :invoices/id) :invoices/date])

To this ...

    from proj in projects
    from inv in invoices
    select { proj.id, proj.name, inv_id => inv.id, inv.date }

For me the ideal programming language would be one readable by humans.

Maybe we can get it a little more Clojure-ish:

    (dosql [a :table1/a b :table1/b]
      (filter (and (< a 5) (= b "x"))))

Makes the filter part more readable (to a Lisper), and introduces variable scope in a more idiomatic manner. The macro needs to take care of the :table1/a expansion and substitution within its scope. dosql might already be taken but not important for my point, I think.

Maybe you still don't like this, but I think it reads a little better for someone used to Clojure.

But can the sql be made to work w/ a non-sql storage engine? The lisp code facilitates this abstraction while raw sql is just that.

That's not sql ... that's Linq from .NET. You can query with it whatever you want: in-memory data-structures, DB, Xml, LDAP.

Here's a MongoDB provider that has basic Linq support: http://github.com/samus/mongodb-csharp

Of course, the actual syntax of LINQ is baked in the compiler's rules, and you can't invent new syntax in the way LISP lets you to.

But why is that have to be the case? There's nothing stopping a compiler from being extensible, other than hard-work. I played with Boo for a month ... it comes very close to that. Perl6 also lets you do it, but it remains to be seen how good it is.

touche, I should have studied your examples longer as the second one it is clearly not straight sql. I have always been a bit jealous of linq and I agree there should be a language which allows the compiler to be extended. Smalltalk allows this to some degree particularly the research done by SCG: http://scg.unibe.ch/research/helvetia/examples

But are you complaining about Lisp syntax in general, or this DSL implemented using Lisp macros in particular?

Both I think.

I'd like a language that lets me define syntax that's readable by kids with basic english/math skills.

From the languages I've tried, Boo came closest to that, but the error messages it throws are awful, and development seems to have stagnated. Maybe Perl6 will be that language, who knows?

Haskell also seems to have a macro-system, but I wouldn't call Haskell a language readable by kids.

Two points: if your complaint is about Lisp in general, then it's not really relevant to the post. Some people can read Lisp syntax just fine. So, for them, the DSL is readable.

Second point is that since the beginners know nothing, they don't have preconceived notions of what programs should look like. Having just taught an intro to programming course, I am very aware that even the semantics of something like "i = 2" can be misunderstood by beginners. One advantage of the Lisp syntax for beginners is that it's extremely simple and consistent.

Chuck Moore has said almost exactly this about Forth. I think this is a property shared between all the low-syntax, high-power languages, including Forth, Lisp, Smalltalk, Lua, etc. But the downside is that there is an inevitable tooling issue where you can achieve concise constructions that read well, but the language and development environment don't "really know" what's going on in the problem domain's microlanguage and can't enforce the concepts or help to debug in the ways a specialized language implementation can. And so as your needs get bigger and you want to make a polished, easy-to-use package, you inevitably drift from libraries, to macros and meta-programming, to data files, and then towards the full parser/compiler/interpreter gamut.

Cool, but what about code maintainability? Why add microlanguages? I'm sure your microlanguage is superintuitive to you, because you wrote it, but I, as a new coder on your code, don't want to learn it.

> I'm sure your microlanguage is superintuitive to you, because you wrote it, but I, as a new coder on your code, don't want to learn it.

I'm sure your API is superintuitive to you, because you wrote it, but I, as a new coder on your code, don't want to learn it.

I'm sure your library is superintuitive to you, because you wrote it, but I, as a new coder on your code, don't want to learn it.

Mmm. No. It takes longer to learn a language than an API, in general. I don't think I'm wrong about that?

That is a valid concern, although a well designed micro language will likely also reduce the code base significantly and thereby leave less to learn. If it is well constructed it will also serve as an easy way of learning about the domain which you will have to anyway.

Fair enough. Or, a well designed micro language may just be that, well designed but entirely unnecessary :)

As anamax points out, you could say the same thing about a well designed anything, so this isn't an argument against languages, so it isn't an argument at all. It reminds me of how most of the objections people make to macros apply just as well to functions.

Touché!

Every codebase and accompanying API is something you have to learn. If you don't want to learn, best not ever do maintenance. A "microlanguage" is just better suited to the problem domain than a normal API.

In this case, he's trying to make it more idiomatic within the surrounding Clojure code, and thus, more intuitive for the intended user.

See http://paulgraham.com/progbot.html

Reply on news.ycombinator.com