Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Little languages are the future of programming

chreke.com

Post reply on HN
Print view View original

51–60 of 216 posts

Re: Little languages are the future of programming

#51

Post by yellowapple »

lolinder wrote: post #14

A "little language" is just an abstraction over a small part of the domain. Equivalent abstractions can be and are written as libraries. In a Turing-complete host language, the primary difference is that these libraries don't get the privilege of inventing new syntax, but that's almost always a good thing. We already have major headaches switching between JS, SQL, and {insert backend language here}. Introducing tens…

> We already have major headaches switching between JS, SQL, and {insert backend language here}.

I used to agree wholeheartedly with this, but now I pretty strongly disagree; in my decade or so of cumulative code-monkeying experience, having to understand the nuances of some "convert $BACKEND_LANGUAGE to JS and SQL" layer has been far more headache-prone than just, you know, writing JS and SQL. All about using the right tool for the job - and I know of very few languages that are the right tool for all three of those jobs (let alone the myriad other jobs that might pop up as soon as you expand beyond a simple CRUD app).

Re: Little languages are the future of programming

#52

Post by CipherThrowaway »

AlotOfReading wrote: post #11

People have been making this argument since the 80s and possibly even earlier. My experience is often the opposite. Little languages are usually far, far harder than (mis-)using "big" languages for small tasks. The problem is that your DSL has to be understood by other people, including future you. Programming tasks are vast, combinatorially explosive state spaces full of weird potential interactions between features…

I think EDSLs are the happy medium here.

Re: Little languages are the future of programming

#53

Post by zabzonk »

samsquire wrote: post #32

Join any company and organisation and look at their build and deployment tooling. Unless they are using Kubernetes and even then, you shall find a very complicated bunch of languages: - shell scripts - Dockerfiles - Kubernetes YAML - Makefiles - Bazel - Ansible - python scripts - Jenkins XML - Groovy scripts - Ruby scripts - CloudFormation - Terraform - Fabric or other deployment deployment script It's very hard to f…

any company that is doing something that is web-based. many have huge functions that have zero to do with the web.

Re: Little languages are the future of programming

#54

Post by bazoom42 »

ssivark wrote: post #16

Here's something I don't understand: How are "little languages" different from a bunch of functionality wrapped into a library/module? Is it just that (with some convenient syntax sprinkled on top), or is there more to it? I would imagine that most of the value comes from being able to "refactor" thought patterns to match the best way to cleave the domain into composable concepts -- and it seems like we do this all t…

An “internal DSL” is a library with a a design which makes it “feel” like a language. JQuery is the classic example. An “external DSL” has its own syntax, like regexes.

Re: Little languages are the future of programming

#55

Post by frou_dh »

yellowapple wrote: post #49

I think this works best if the little languages all share as much syntax and semantics as possible. A good example of this is OpenBSD's assortment of configuration file syntaxen for OpenSMTPd, pf, httpd/relayd, etc.; each of those "little languages" differ considerably in their problem domains, but they all seem to share a vaguely-Tcl-ish syntax and have largely converged in semantics and typical structure. Another i…

GNU Guile was supposed to be such an ubiquitous language but AFAIK it didn't really take off.

Re: Little languages are the future of programming

#56

Post by pasquinelli »

lovecg wrote: post #13
AlotOfReading wrote: post #11

People have been making this argument since the 80s and possibly even earlier. My experience is often the opposite. Little languages are usually far, far harder than (mis-)using "big" languages for small tasks. The problem is that your DSL has to be understood by other people, including future you. Programming tasks are vast, combinatorially explosive state spaces full of weird potential interactions between features…

And even if you do invest in proper documentation and support, you still have to overcome the hurdle that people just _don’t want to spend time learning your one-off language_ - there’s nontrivial opportunity cost in learning something that won’t be useful anywhere else. So people will just do the bare minimum which will lead to misunderstanding and bugs.

part of me wants to argue that the interface to a complex piece of software is a language, really, and if it were a self-consciously made language, it could be a lot better in a number of ways.

but, i think you're probably right.

Re: Little languages are the future of programming

#57

Post by gpderetta »

015a wrote: post #45

Is the engineering footprint of an organization really better if everything is implemented in twenty different languages, versus just three or four? Everything else aside, quality of the language, scope, etc; just the number. You have to expect everyone to know each language; know the ins, outs, idioms, gotchas, etc. You have to be able to hire for the languages. You need the language runtimes in your environment, ev…

That's the inner platform syndrome, and yes, it is bad.

Re: Little languages are the future of programming

#58

Post by valenterry »

Spark_Ed wrote: post #18
auxfil wrote: post #17

This is a “deepity”. We already do this. We constantly do this in programming: “The idea is that as you start to find patterns in your application, you can encode them in a little language—this language would then allow you to express these patterns in a more compact manner than would be possible by other means of abstraction. Not only could this buck the trend of ever-growing applications, it would actually allow th…

Maybe the author is trying to predict that there will be boom in DSLs like there was for JS frameworks? Funnily enough, I'm just wrapping up a DSL for our in-house web component engine that creates an abstract data layer all components share. The pattern was easy enough that I'll probably build more DSLs like it when an API isn't flexible enough

The better the programming language, the less need for a custom language. You can then create the DSL inside of the host language. This requires flexibile syntax to some degree and a fairly advanced typesystem if it should be statically typed - hence not too many languages are a good choice here.

Re: Little languages are the future of programming

#59

Post by msla »

maweki wrote: post #50
AlotOfReading wrote: post #11

People have been making this argument since the 80s and possibly even earlier. My experience is often the opposite. Little languages are usually far, far harder than (mis-)using "big" languages for small tasks. The problem is that your DSL has to be understood by other people, including future you. Programming tasks are vast, combinatorially explosive state spaces full of weird potential interactions between features…

> Programming tasks are vast But little languages could be a nice interface for the non- or semi-programming tasks. Do you really want your domain experts to fiddle with the core of your application or do you want your programmers to do that? A little language could be a great interface to encode specific business rules and domain logic. The author gives SQL as an example of a little language and we do indeed already…

> Do you really want your domain experts to fiddle with the core of your application or do you want your programmers to do that?

The Curse Of Almost: Your tool is great, it's almost perfect... except for that one little thing it can't do, which your users need to do, which, therefore, leads to masses of ugly hacks unless you provide access to an escape hatch where sufficiently motivated experts can drop down to a real language which doesn't have your DSL's limitations and get the job done.

It's the Curse Of Almost because, if it were too much worse of a fit for the problem, nobody would even think of using it to solve that problem. Getting someone 90% there and crapping out puts your users in a more awkward position, especially if they feel they've invested effort in whatever tool they have.

An example is Talend versus CSV: Talend is an ETL Solution which Extracts data from some source, Transforms it according to a graphical DAG of ideally stateless components, and Loads it into some other storage. It's also a happy, friendly GUI on top of Java, which is nice, because the Real World isn't kind to happy, friendly GUI solutions which expect CSV is going to conform to any of your syntax rules or other misguided preconceptions about files having structure. So, when you have to run a Talend pipeline on vaguely-comma-delimited text files which may once have been machine-readable, you can make your own component which is literally just a block of Java code to parse the file using the Zerg Rush Of Ad-Hoc Rules Technique, an oft-overlooked method for designing parsers. You can also use that kind of thing to make components which are tasteless enough to demand state variables other than the stereotyped kind Talend itself provides.

Re: Little languages are the future of programming

#60

Post by kaba0 »

btschaegg wrote: post #22

On that note: Am I the only one that's constantly surprised by the absence of proper sandboxing solutions when so many programming languages now provide (otherwise pretty useful) means of running code dynamically in a script-like fashion? In C#, I can pull in Roslyn, and compile a string on the fly as a C# script; but the way the .NET standard library is structured makes it pretty much unfeasible to prohibit outside…

As far as I know most in-process sandboxing has been deprecated because it is in contrast to maintainability. E.g. Java decided against its Security Manager, because it is way too easy to leave the proper checks out of a new feature, leaving the whole thing vulnerable with a false sense of safety. Instead, process-level isolation is recommended.
Post reply on HN