4 ms·

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 cre

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. To have a reasonable claim that you're writing a language, you'd need to write something with a different syntax and/or model of execution, and somehow embed it in your language. Arguably regexes and SQL count, though the perennial problem there is that to the host language, they're just opaque strings. None of this is to say your APIs are bad. Embedding one language in another is hard--that's why they're so often just opaque strings. Beyond that, as this article points out, embedding a new language gives anyone working with your code a significant obstacle. For most things, little languages aren't the right tool--standard imperative/functional programming goes a really long way.

deleted 3y ago
[deleted]
naasking 3y ago
> 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 https://okmij.org/ftp/ML/#DSLs [2] https://higherlogics.blogspot.com/2008/09/mostly-tagless-interpreters-in-c.html https://higherlogics.blogspot.com/2008/09/mostly-tagless-int... [3] https://higherlogics.blogspot.com/2013/09/combinator-calculus-edsls-in-c.html https://higherlogics.blogspot.com/2013/09/combinator-calculu... [4] https://higherlogics.blogspot.com/2009/01/embedded-stack-language-for-net-redux.html https://higherlogics.blogspot.com/2009/01/embedded-stack-lan... [5] https://higherlogics.blogspot.com/2015/02/kanrennet-featherweight-relational.html https://higherlogics.blogspot.com/2015/02/kanrennet-featherw...
- hyperpape 3y ago
  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).
jadyoyster 3y ago
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.
- burakemir 3y ago
  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.
Marazan 3y ago
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.

deleted 3y ago

[deleted]

naasking 3y ago

> 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 https://okmij.org/ftp/ML/#DSLs [2] https://higherlogics.blogspot.com/2008/09/mostly-tagless-interpreters-in-c.html https://higherlogics.blogspot.com/2008/09/mostly-tagless-int... [3] https://higherlogics.blogspot.com/2013/09/combinator-calculus-edsls-in-c.html https://higherlogics.blogspot.com/2013/09/combinator-calculu... [4] https://higherlogics.blogspot.com/2009/01/embedded-stack-language-for-net-redux.html https://higherlogics.blogspot.com/2009/01/embedded-stack-lan... [5] https://higherlogics.blogspot.com/2015/02/kanrennet-featherweight-relational.html https://higherlogics.blogspot.com/2015/02/kanrennet-featherw...

hyperpape 3y ago
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).

jadyoyster 3y ago

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.

burakemir 3y ago
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.

Marazan 3y ago

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.