Which language is better for creating DSLs, Clojure or Haskell?

Another Quora answer. Part of my increasing admiration for the virtues of EDN in Clojure.

Which language is better for creating DSLs, Clojure or Haskell?

Clojure has a slightly different philosophy than most Lisps, I think.

In Clojure you’d be more likely to make your “DSL” in EDN (“Extensible Data Notation”, which is a bit like JSON but with more features). It’s completely integrated with / interoperable with Clojure itself. You can embed EDN anywhere in a Clojure program, and embed Clojure function calls anywhere in an EDN data-structure.

And you get “parsing” for free.

That’s how languages like hiccup are built.

So if you just want to make “a DSL” (ie. convenient high-level domain specific notation for an application) then 99% of the time, a hiccup-like EDN dialect is going to be fine, and you don’t have to write anything at all.

In that sense, code you don’t have to write is better than code you do.

If you need a specific DSL with a specific syntax which isn’t EDN (or s-expressions) then you’ll be back to writing your own parser.

Here, Clojure has its own Yacc-like and parser-combinator libraries. I’m not sure they’re very different from Haskell’s. But you don’t have Haskell’s algebraic data-types, so there’s no type system helping you. I guess it’s a bit more effort to get a Clojure DSL right using Instaparse etc. than in Haskell.

There is Spec, which does some of the job but is certainly more verbose and less elegant than Haskell’s algebraic data.

So yeah, Haskell probably wins for writing general DSLs but if you just want to make small, simple domain-specific notations for things in your application, and don’t mind the EDN look, then Clojure is fine. That’s trivially easy.

Microsoft adds Python to Excel

Several years late, it seems M$ is considering making Python native to Excel.

I wrote a … you guessed it … Quora answer as to why this makes sense for Microsoft.


Python has become massively popular with the data and machine learning communities in the last few years.

Tools like JuPyter are increasingly popular and serious interfaces for data-modellers who previously would have used Excel.

It absolutely makes sense for Microsoft try to embed Excel and itself into that emerging Python data ecosystem by making Python a first-class citizen (ie. default, guaranteed to be there) of Excel.

Not just a third-party add on for those who know about it and can make the effort to install it.

Not only does Python need to be standard within Excel, but access to pip and all the Python libraries needs to be there too. So that Excel becomes the equivalent of Anaconda

That’s the way that M$ can keep Excel relevant in the new data age.

This is not only a good idea for Microsoft. It’s the difference between Excel remaining a major player in data modelling and analysis tools, vs. declining into obscurity.