Live data from Hacker News

Little languages are the future of programming

chreke.com

31–40 of 216 posts

Re: Little languages are the future of programming

#31

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 then there's the issue of the language itself:

- can you even design it properly?

- is it tested?

- is it debuggable?

- how does it integrate with the rest of your program(s)? with the rest of your system(s)?

- what's the performance, and does it matter?

- is it documented?

- who is going to maintain it 1 year from now? 5 years from now?

Re: Little languages are the future of programming

#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 fit together and understand from a high level.

The last thing they were working on at my previous company was a YAML format to define a server, to go through the organisational structure of the company to manage computer systems.

Some people mentioned LISP in this comment thread. For me LISP is an intermediate language, I would never want to build a large system in LISP. It's not how I think about computation.

Re: Little languages are the future of programming

#35

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…

Ruby used to have the $SAFE feature for sandboxing, but it was removed because it was buggy, added a lot of complexity, and wasn't actually that useful. Linux has all the various isolation features that make Docker work, but people still recommend not running untrusted code in Docker containers because of the potential for oversights/"bugs" in Linux's API. I suspect that programming languages / VMs don't include these features because they are very hard to get right and add a disproportionate amount of complexity for their utility.

Re: Little languages are the future of programming

#36
Empirically speaking, it seems more like rich languages are the past, present and future of programming. Rich as in, has a strong standard library. Python, go, etc.

The only "little" languages I can think of that I'd reasonably ask people to use at work are lua, make(~), awk, and (ba)sh.

Re: Little languages are the future of programming

#37
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…

I agree, they are the same! regex is an example of an eDSL that most general-purpose languages support. The king of eDSL:s is of course Haskell. I recommend looking up parser combinators for anyone who has ever struggled with an understanding way to complex regex expressions.

Re: Little languages are the future of programming

#38

Earlier quoted context omitted.

Oh, please, making reasonable good DSL might take a month or even years. Also wrestling with parser and borrow checker not an easy task for average user.

I'm no Rust zealot but the borrow checker is arguably one of the core benefits for the average user. Wrestling with it means they are not yet ready for systems programming and need to understand move semantics more deeply.

Borrow checker is fine. But from the library writer perspective its pain and take enormous amount of time to make it sound. One does not simple checkout "nom" and test thing in few minutes.

Re: Little languages are the future of programming

#39

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…

Can you expand on you mean when you say that Lisp is not ‘how [you] think about computation’. I have never seen that phrase used regarding Lisp, usually it’s mentioned in regards to logic or other much less mainstream paradigm than the imperative/semi-functional paradigm in Lisp.

Re: Little languages are the future of programming

#40
Unlikely. On one hand notations should be a commodity and they indeed should be unique to the task. There is no point and no way to try making a unified notation for music and chess. On the other hand there is no point to make multiple notations for the same thing. And programming is indeed the same thing from lowest to highest levels, composable like a Russian doll, or we won't be able to build large systems. So the future of programming is a single notation that actually reflects what programming is. We do not have it yet, this is why we have so many "programming languages".
Post reply on HN