Hacker News Reader

> This really isn't the same. If you're just building up objects/data structures in your host language, and calling functions/methods on them, then you're not creating a language. It doesn't matter how slick/fluent or whatever else your API is, you're just working in the host language.

It can be. They're called EDSLs, "embedded domain specific languages". The point is to embed the language semantics in the host language via judicious choice of data types, and then methods implement semantics-preserving transformations on them. The more expressive the type system, the more expressive the languages you can safely embed in the host language, and you then have all the debugging capabilities and libraries of the host language at your disposal.

This pattern is very common in Haskell, Oleg is well known for doing this with OCaml [1], but you can also do this in typical OO languages like C#. Arguably C#'s IEnumerable<T> interface is such an EDSL for set programming, and here's a simply typed lambda calculus [2], here's an SKI combinator calculus [3], here's a stack-based language [4], and here's a logic programming EDSL based on µKanren [5].

[1] https://okmij.org/ftp/ML/#DSLs

[2] https://higherlogics.blogspot.com/2008/09/mostly-tagless-int...

[3] https://higherlogics.blogspot.com/2013/09/combinator-calculu...

[4] https://higherlogics.blogspot.com/2009/01/embedded-stack-lan...

[5] https://higherlogics.blogspot.com/2015/02/kanrennet-featherw...

I feel like minikanren matches pretty closely to what I wrote about regex and sql? The execution model really isn’t visible from the surface syntax.

And while you probably don’t embed it as a string, you do basically have a shim layer between the host language and the natural ways of expressing a logic program.

My point is something like “if you’re doing something like SQL or regex or minikanren, you have a claim to implementing your own language, but the normal case is just another API.”

There is a reason we’re talking about Oleg! He’s really unusual (in a good way).

I would disagree. One of my biggest revelations and improvements to my programming from reading SICP was the concept that as soon as you start to declare functions you are starting to create an abstraction over hte host language and as a result a new language for your problem will emerge.

This begs the question: what is the benefit of treating nearly all program writing as "language design".

Using that frame of reference I can use it to spot where my abstraction/program design breaks down when I start using too much "raw programming language" to glue between different parts of my program together. That suggests I have a gap in how my domain objects relate to each other.

I may be wrong but I think that's not the view of the modern PL community. If your API talks about values, combinators, and has (implicit) laws about them then I would certainly consider that a language.

Maybe the view that APIs are little languages can be seen as the view of the postmodern PL community.

Since object orientation brought the possibility of adding little languages to the masses and a few decades later value objects and lambdas and generics where added to all OO languages, a postmodern view may be quite an applicable and useful perspective to deal with this question.