Live data from Hacker News

Little languages are the future of programming

chreke.com

61–70 of 216 posts

Re: Little languages are the future of programming

#62
While I also believe several commenter’s opinion that libraries, frameworks can easily become DSLs themselves (e.g. isn’t Java streams basically a DSL for stream processes inside another language?), one really can’t talk about polyglottism without mentioning the ingenuity of GraalVM.

You basically write a dumb, easy parser and AST interpreter for your language, and it will magically turn into a JIT compiled dynamic language with state-of-the-art GCs and better performance than what you could likely come up with. And the best thing is that it really unifies the computing model where you can pass a python object to some js lib, effectively giving you every library ever written for any (implemented) language, which is the real productivity booster.

Re: Little languages are the future of programming

#64

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…

Indeed.

That's why we have languages with functions now, because people didn't want to manually do a register dance in assembly.

That's why we have name spaces, because naming conventions only take you so far.

That's why we have map and filter (or equivalent) because that's what most loops are doing anyway.

Generation after generation, we discover that we all use common abstractions. We name them design patterns, then we integrate them in the language, and now they are primitives.

And the languages grow, grow, bigger and bigger. But they are better.

More productive. Less error prone. And code bases become standardized, simple problems have known solutions, jumping to a new project doesn't mean relearning the entire paradigm of the system in place.

Small languages either become big, or are replaced by things that are big, for the same reason most people prefer a car to a horse to go shopping.

Not that horse ridding will totally disapear, but it will stay in their optimal niche, they are not "the future".

Re: Little languages are the future of programming

#66

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…

Yes, to add to your point: nobody has managed to used the "outputs" of the STEPS project to do something useful.

There was a cool "wordprocessor-like" (Franken?) demonstrated which was created with a small number of lines, it should be a huge success in the FOSS world no? Well no, nobody managed to make it work.

Re: Little languages are the future of programming

#67

Lisp

I was a little surprised he took until the final paragraph to mention Racket. If he had played around with it then I think the article might have read differently.

  " Racket is a Lisp dialect that’s specifically designed for creating
  new languages (a technique sometimes referred to as
  language-oriented programming). I haven’t had time to play around
  much with Racket myself, but it looks like a very suitable tool for
  creating 'little languages'."

Re: Little languages are the future of programming

#68
Interesting article, I immediately had to think about terraform. The problem I'm having with specialized languages (even with SQL) is that it always creates additional interfaces and almost always creates ugly string formatting if you want to integrate (SQL) or ugly duplication (Terraform) if you keep it separate.

I like the idea of abstraction but in my mind it is very easy to have the power of a "little language" inside an all purpose language by using a package. E.g. SQLAlchemy or Pulumi as the alternative to the little languages of SQL and TF.

Re: Little languages are the future of programming

#69
I disagree and would say DSLs should go away if possible.

DSLs like SQL are the norm and you can see the problem of them in basically every project.

You either use ORMs or you end up hand rolling SQL rows into Structs or Classes.

The whole mapping usually looks like crap and contains a bunch of implicit corner cases, which eventually end up being a footgun for someone.

Usually the SQL sever runs somewhere else, the ports are wrong, the language version is wrong, or a migration failed and a function is missing yada yada....

The same is usually true for Regexp. There are a billion dialects and every single one of them is basically unreadable, incomplete or just weird.

The same is true for microservices with tons of config files for dev, staging, testing and production...

Everything has its own version, can be down or mutate some random state somewhere while depending one other servcies.

It always breaks at the seams.

Increasing the amount of DSLs increases the amount of seams and thus makes software worse.

Re: Little languages are the future of programming

#70
post #10

I don't think it's so much "little" languages (commonly DSL) that matter. It's more the jumps in expressivity. You don't use a full on Turing-complete language when you need to match strings written in a regular language. Instead, we write the language we want as a regexp, and then use a regexp engine to match it. I agree with much of the problems listed in the article. The author even manages to stumble onto some of…

What's a “total language”?
Post reply on HN