[BiteCode_dev]

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".

[geysersam]

I think one of the biggest counter examples to your argument is SQL.

It's been around a long time. It's not general purpose. It's considered the best option there is if your setup allows you to use it.

[pjc50]

SQL persists because it's an interchange format, not just a programming language. It's one of the few programming languages you'll see embedded in other languages - and generating SQL from other languages is a common source of security bugs. You can't upgrade away from SQL without changing both ends of that connection.

You can write large programs in SQL, but it's generally considered good practice not to.

(I feel I ought to mention LINQ here, not to make any specific point but just to fanboy about it)

[Akronymus]

For LINQ, I personally vastly prefer the fluent version (IEnumerable.Select(..).Where(...) and so on) over the SQl like syntax.

[P5fRxh5kUvp2th]

same, and in fact, despite using C# since before LINQ even existed, I don't even know how to write the sugar candy version of it.

Part of that is me coming from C++ and its algorithm header and the other part is that the code is just easier to read and understand than the sugar candy version (to me, atleast).

[BiteCode_dev]

As to not repeat the same argument: https://news.ycombinator.com/item?id=33704199

[geysersam]

It's still quite little compared to general purpose languages with similar expressive power in the same domain.

[kibwen]

Plenty of people prefer language-integrated things like LINQ over SQL, although we can argue whether or not LINQ represents a kind of DSL.

[cultofmetatron]

SQL is a beast of a language and there's definitely room for improvement. Also it's not Turing complete

[ourlordcaffeine]

Mysql 8 is turing complete with the recursive common table expressions

[falcolas]

Somewhat pedantic argument: SQL is kinda dead. Sure, modern databases use upgraded dialects of it, but they are custom to each database and often incompatible with plain SQL. There are even many cases where modern databases don't support even standardized SQL constructs.

The easiest example of where databases and SQL part ways: UPSERT. It doesn't exist in standard SQL.

ref. https://jakewheat.github.io/sql-overview/sql-2016-foundation...

[geysersam]

Many modern products use SQL. Supabase and BigQuery comes to mind, but the examples are basically inumerable.

There are others of course. But I'd rather call SQL challenged (by graphql etc.) than dead.

[paulryanrogers]

SQL has MERGE

[falcolas]

Forest for the trees, my dude.

[paulryanrogers]

Then let me address the forest. Modern DBs offer SQL as an on-ramp for the most common DML and querying. This further entrenches it as a data language and why SQL just won't die.

There are always more proprietary methods where one needs them. That doesn't mean SQL is dying, it means SQL will likely grow to include some of those too.

[cies]

> 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 you ask me.

Small does not mean w/o functions, without NS, without map/filter: it means "not general purpose".

[BiteCode_dev]

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 those small languages, until we found out that we prefer a car to do shopping.

[majkinetor]

> 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.

[williamcotton]

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?

[tester756]

>So why are shell languages still around?

Are they? I don't use them more than once a year

[mcluck]

I'd say you're in the extreme minority then. I'm not a bash hacker but I usually end up writing a little script for myself at least once a month. Even just doing `command && command` is technically using a shell language

[BiteCode_dev]

So you are using bash once in a while (once a month is not a lot for a programmer) for niche use case (the specialty of bash: short scripts).

Hence, you are making the point "little languages are not the future". It has found its local optimum.

[mcluck]

I said I write custom scripts about once a month. I use bash literally every day. But I also wasn't arguing the future of programming languages. The parent here said that shell languages aren't being used

[t-3]

Still alive and quite well. In fact, as more and more programs are written, they become more and more useful. We're already well into an era where programming can be nearly entirely ignored in favor of merely scripting new behavior out of the interactions between existing programs.

[pjc50]

Shell languages have "must be easy to type in execution order" and "must integrate with random programs on the filesystem" as an overriding consideration. You're not going to get that with Java.

[sargstuff]

gawk compiled via webassembly to allow for running in browser allows 'modern' gui input / output beyond the command line interface while still retaining the ability to be just a cli program.

[williamcotton]

The irony of your horse analogy is that a horse is more general purpose than a car. A horse can travel along train tracks, roads, sidewalks, and hiking trails.

[williamcotton]

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 writing glue code that takes orders of magnitude more memory and CPU time.

2.) Static analysis. This means tools that are better at finding bugs, finding optimizations, visualizing structure, etc.

[lolinder]

Both of these things are theoretically true, but only if the little language has enough resources behind it to optimize and build enough tooling. A big language is much more likely to have those resources because the target market is big enough to justify it. A niche little language will likely never get that kind of mass behind it, so the tools will be lacking and the runtime won't be optimized.

[williamcotton]

Big general purpose languages don’t have the capability for certain kinds of performance improvements or static analysis so the market size isn’t a factor.

[lolinder]

My point isn't that the big languages can do everything that a little language could theoretically do, it's that the little languages won't have the resources to pull them off, nor will they have the resources to even do what the big languages do.

Proper debugging, syntax highlighting, language servers, security audits. These are things that engineers in the real world expect a language to have, and each little language would have to reinvent each of them. In contrast, a library can piggyback off of the tooling provided in the host language.

So even if a language can deliver on the performance and static analysis that it promises (which few will), it cannot reach adoption because it cannot provide the infrastructure needed.

(That doesn't need even get into the onboarding concerns that I and others have raised about having a codebase that is strung together from a dozen tiny languages.)

[williamcotton]

Proper debugging, syntax highlighting, language servers, security audits. These are things that engineers in the real world expect a language to have, and each little language would have to reinvent each of them.

I don’t always see this as the case and this might be a very fruitful area for research. What I mean is, much like how we have tools like bison, antlr, and the k framework, I could easily see this notion extending to language servers, etc.

As for onboarding, well, who are we onboarding? New software engineers working on a general purpose language or new operations members working on a DSL?

I remember a time when CSS and HTML had yet to be consumed by a general purpose language and the onboarding for new web designers was significantly easier.

[lolinder]

> I don’t always see this as the case and this might be a very fruitful area for research. What I mean is, much like how we have tools like bison, antlr, and the k framework, I could easily see this notion extending to language servers, etc.

Yeah, I could see this happening, to a point. I'm not convinced it will happen, because what would be the impetus?

> I remember a time when CSS and HTML had yet to be consumed by a general purpose language and the onboarding for new web designers was significantly easier.

So do I. I had a friend whose dad wanted to start building web pages for a living, right at the moment when that job was starting to vanish.

At least two factors were involved in that shift:

1. More and more companies wanted web applications, not simple web sites. A functional web app requires engineering effort or it falls apart, whereas a simple web site just requires making things look right. Once these companies had engineers for a web app, it was simpler just to pay them to build out a marketing page than to hire that out (even if hiring it out would have been cheaper).

2. WordPress was becoming more and more approachable, and others like SquareSpace stepped in to make it even easier for a non-technical person to build a website. Companies that didn't need engineers for an app realized that they could do a good enough job for their needs by just using these tools in-house.

I suspect this is the fate of any little language that successfully eliminates the need for engineers: if we can take a piece of a domain and describe it in a DSL that is streamlined enough for no-effort onboarding, it won't take very long for the DSL to be made redundant by GUI tools that are even easier to use.

At that point, the DSL either goes away entirely or it morphs into something bigger to meet more complex needs (as HTML/CSS/JS did).

(This doesn't apply to DSLs like Regex and SQL that are designed for use by engineers, but then we're back to the question of whether an external DSL is pulling its weight relative to an equivalent library.)

[origin_path]

It is a fruitful area for research! Truffle is an example of the sort of framework you mean. Implement a parser+interpreter using Truffle and you get JIT compilation, GC, debugging, profiling and more stuff for free on top of the JVM.

[hinkley]

I don’t want to spend all day playing human debugger because your little language doesn’t support debugging.

I’m not here to tell you how very clever you are for reinventing the wheel. I have my own shot to get done and that’s easier when we make a smaller language out of our general purpose language by agreeing to style guidelines, instead of avoiding solving social problems with technology by creating your own game to change the rules.

When everyone in your group expects the rest of the team to commit 10% of our attention to their tool or module, that doesn’t scale. If we go more than 50% total our capacity to solve problems becomes hamstrung.

If you work someplace where new devs are useless for a year, you’ve likely already got the snowflake disease.

[williamcotton]

What does any of what you’ve written have to do with the concerns raised by the author of the article?

[hinkley]

> 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.

From the top level comment.

It’s also the primary failure mode for DSLs. There’s never any thought for tracing and debugging, and so it becomes a peaen to the primary author(‘s ego).

Once you no longer have impostor syndrome it gets much harder to play along with these ego trips. It’s not that I’m too dumb to understand your DSL, it’s that you’re a fool who thinks writing your own language is the pinnacle of success. It’s very rare for it to better than a decent API and you’re thinking about yourself, not your coworkers.

That’s why everyone always mentions SQL. It’s the exception to the rule, not an example of when DSLs can be good. Remember XSLT. Remember a dozen other failed DSLs. Per decade. Forever and ever.

[dinosaurdynasty]

There are certain kinds of analysis a non Turing complete language can have that a Turing complete language can never have.

[williamcotton]

I think I figured out the issue in this discussion. The article is actually about general purpose vs domain specific and not really about big and little… and unfortunately since most “DSLs” are APIs written for in general purpose languages the author resorted to using the term “little language”.

[BiteCode_dev]

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).

[williamcotton]

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.

[BiteCode_dev]

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.