Live data from Hacker News

Little languages are the future of programming

chreke.com

131–140 of 216 posts

Re: Little languages are the future of programming

#131

Earlier quoted context omitted.

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, the…

There’s two things that the article mentions that your omni-language has massive problems with: 1.) Performance. For example a run-time for a user-friendly little language that maps HTTP requests to SQL queries can be much faster than a language that does the same thing by plugging user-friendly APIs together. A custom run-time can parse an HTTP request string directly into SQLite op code while the JS developer is wr…

In your story, the small language fits local optimum, and becomes popular in its niche where it's good at.

So small languages are not the future, which is what the article suggests.

They are either niche (bash), dead (tcl), or gets big (sql).

Re: Little languages are the future of programming

#132
post #13

Earlier quoted context omitted.

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.

> you still have to overcome the hurdle that people just _don’t want to spend time learning your one-off language_ That's an important point. Maybe as an academic someone is more inclined in learning new languages for the sake of intellectual interest, but on the engineering side, having uniformity of language is a big plus. I ask myself, by the way, if the author misses the point not considering that all code that t…

Academics are not so hot on DSLs as one may think. Typically, they are viewed as padding material to the real research contribution. Anecdotally, I can recall papers being bashed because of the use of a DSL, but not applauded because of it.

Re: Little languages are the future of programming

#133
post #126

Little languages are the past and yes, the future. We just don't recognise them. It was common in the 60s and 70s to have the hardware manufacturer ship all the OS and languages with their hardware. The languages were often designed for specific problem domains. The idea of general purpose languages (FORTRAN, PL/1, etc) was uncommon. You can see this in K&R (the original edition anyway) where they justify the idea of…

> Every API is itself a "little language"

I came to this conclusion early in my career. It went something like this:

A - "To do this, just create this object, fill in these properties, and call these methods."

B - "Okay, I did that, but it crashed."

A - "Yeah, it's because you set the properties in the wrong order. This property relies on this other property under the hood. Set them in this order."

B - "Still crashes."

A - "Yeah, you called the methods in the wrong order. This method relies on that method. Call them in this order and it works."

My conclusion was that the lisp philosophy of building a lot of little sub language was equivalent to what people were doing with OO in C#/Java. Either way you have to learn the "right" way to put things together which is dictated by unseen forces behind the scene.

Of course, I also concluded that most people work differently than I do. For most people, if the code "looks right" (ie recognizable syntax) then they're able to tell themselves a story that it's familiar and their intuition is able to pick up the slack for finding the right enough way to use most arbitrary APIs (just as long as they don't exceed some level of incomprehensibility). On the other hand, I have to understand the underlying logic or I use the API the wrong way pretty much every time.

So for most people lots of APIs is actually a much better cognitive way for them to work whereas for me API soup and lisp macros are the same conundrum.

Re: Little languages are the future of programming

#134
> For example, SQL is a little language for describing database operations. Regular expressions is a little language for text matching. Dhall is a little language for configuration management, and so on.

> There are a few other names for these languages: Domain-specific languages (DSL:s), problem-oriented languages, etc. However, I like the term “little languages”, partially because the term “DSL” has become overloaded to mean anything from a library with a fluent interface to a full-blown query language like SQL, but also because “little languages” emphasizes their diminutive nature.

Ahem, so is SQL diminuitive or not? Because, SQL is NOT diminuitive. SQL is Turing complete.

Re: Little languages are the future of programming

#135

> SQL is a little language for describing database operations Yeah, SQL is not a little language anymore. It started as one, but because a lot has been added to it and SQL flavors for Oracle or Postgres are anything but tiny. Windowing, nesting, json handling... I think the author is kinda proving with this that a successful little language does not stay little, and hence little languages are not the future. And don'…

DSLs are great for job security in small organizations. They might as well be regarded as criminal.

Re: Little languages are the future of programming

#136
Among the problems this article ignores is the relatively large fixed cost needed to go from a framework/internal-DSL to a separate "language." Unless you are in a situation where lots of people have that same problem, then it actually creates more complexity than it solves to have an separate language to solve the sub problem.

Re: Little languages are the future of programming

#137

Earlier quoted context omitted.

There’s two things that the article mentions that your omni-language has massive problems with: 1.) Performance. For example a run-time for a user-friendly little language that maps HTTP requests to SQL queries can be much faster than a language that does the same thing by plugging user-friendly APIs together. A custom run-time can parse an HTTP request string directly into SQLite op code while the JS developer is wr…

In your story, the small language fits local optimum, and becomes popular in its niche where it's good at. So small languages are not the future, which is what the article suggests. They are either niche (bash), dead (tcl), or gets big (sql).

1.) Bash is not niche.

2.) SQL is not a general purpose programming language and is used as an example of a little language by the author.

I can clearly imagine a future where instead of a few large general purpose languages we have a multitude of niche languages that have better performance characteristics, better tooling and smaller individual learning curves.

Re: Little languages are the future of programming

#138
post #85

Earlier quoted context omitted.

> 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. So why are shell languages still around? Why are they not replaced by C#, C++, Java or another big (=general purpose) language? I find your horse->car comparison more akin to the sh->bash->zsh transition. Zsh is not as small as sh, but still it is in the small league is…

Shell languages are a very good example, because they have been replaced mostly by bigger languages. First by perl, then by python. Now a day, most people don't write bash if it must be more than a few lines: it fits niche perfectly, like horse ridding. But you are not going to do website with bash anymore, server swarm deployment with powershell or build your encoding pipeline in fish. Tasks that we used to do using…

> server swarm deployment with powershell

I do this routinely with powershell. Powershell is not bash or fish, its highly usuable in all situations except those that require greatest performance and even then there are solutions for various types of problems.

Re: Little languages are the future of programming

#139
post #85

Earlier quoted context omitted.

> 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. So why are shell languages still around? Why are they not replaced by C#, C++, Java or another big (=general purpose) language? I find your horse->car comparison more akin to the sh->bash->zsh transition. Zsh is not as small as sh, but still it is in the small league is…

Shell languages are a very good example, because they have been replaced mostly by bigger languages. First by perl, then by python. Now a day, most people don't write bash if it must be more than a few lines: it fits niche perfectly, like horse ridding. But you are not going to do website with bash anymore, server swarm deployment with powershell or build your encoding pipeline in fish. Tasks that we used to do using…

Do you prefer a car or a touring bus when you go shopping? Because making an analogy between a car and horse doesn't really make any sense.

Why not have a niche language for making websites? Or for server swarm deployment? Or a video encoding pipeline?

Re: Little languages are the future of programming

#140

Earlier quoted context omitted.

In your story, the small language fits local optimum, and becomes popular in its niche where it's good at. So small languages are not the future, which is what the article suggests. They are either niche (bash), dead (tcl), or gets big (sql).

1.) Bash is not niche. 2.) SQL is not a general purpose programming language and is used as an example of a little language by the author. I can clearly imagine a future where instead of a few large general purpose languages we have a multitude of niche languages that have better performance characteristics, better tooling and smaller individual learning curves.

I won't repeat the other comments I made, but in summary, yes bash is niche, stuck in a local optimum, no sql is not small anymore.
Post reply on HN