alt.hn

1/10/2025 at 1:50:40 PM

The Siren Song of Little Languages

 https://www.wilfred.me.uk/blog/2019/03/24/the-siren-song-of-little-languages/

by Qem

1/13/2025 at 9:16:57 AM

My take is that, for productive work, language is much less important than everything around it. I need at the very least some kind of package management and dependency resolution system. Sometimes I want to read a CSV file, turn some of the content into JSON and serve it over HTTP. In an environment with sensible libraries, that's just a case of glueing stuff together. The problem is not little languages, it's little ecosystems.

by red_admiral

1/13/2025 at 12:10:07 PM

There was 3 reasons for python success : it's easiness, it's price and the most important the number of libraries

by poulpy123

1/13/2025 at 12:52:55 PM

What do you mean by "price"? The language and its interpreter are free, but so are most languages from its time, so what are you referring to exactly?

by lblume

1/13/2025 at 1:06:59 PM

That's the point of the joke. If it had cost money, it would never have become as popular.

by red_admiral

1/13/2025 at 6:11:28 PM

yeah I mean the price of 0$/€/any currency. And not all languages were free, especially one of the main place where python encountered first the success that made it so big was in the universities and in research, were software like matlab, mathematica, IDL or maple were (very expensive) kings before.

by poulpy123

1/13/2025 at 4:46:56 AM

> The problem seems to be languages with a small, well written specification.

that’s why I’m making my language as big and poorly specified as possible:

https://hyperscript.org

by recursivedoubts

1/13/2025 at 6:21:18 AM

I think it is a problem of incentives: programming languages with small, elegant specs are often created by academics, and academia and the software industry have fundamentally incompatible incentives.

by emmanueloga_

1/13/2025 at 11:55:11 AM

People in academia know enough computer science to appreciate that everything can be reduced down to unification and function application (+ side effects) and they advocate for expressiveness in the same sense that a manager on a team of people working with an industrial language advocates for simple and readable code (because he wants to streamline the onboarding process, and because he's constantly hiring juniors instead of seniors).

Common patterns in functional languages are considered "too clever" in most workplaces. Because they leave new hires dumbfounded and no one has got the time to explain them how to do their job. It's not that they're too "clever" but rather that the average coworker is too "dumb". But that's not a jab at anyone in particular, it's a consequence of our work culture -- and "clever" and "dumb" are not statements about intelligence, but about experience and team composition.

Basically the incentives are actually opposite to each other. It takes a long time to wrap your head around languages like Haskell because you actually have to know some theory, you can't just wing it. Javascript however...

On one side of the spectrum there's imperative languages and on the other end there's declarative ones. So this dichotomy creates friction and inertia.

by Vampiero

1/13/2025 at 3:58:54 PM

Here's a different take: Languages like Haskell aren't solving the problems companies actually experience (for the most part). High on that list of real problems is "how do I get effective work out of these <relatively inexpert> programmers?" And often the domain that the programmers are being asked to work in strongly constrains viable languages as well. (Web browsers and JavaScript would be an example.)

I love Lisps, but for most companies, it's not the right investment. People don't leave school knowing lisp, its flexibility can be a downside with inexperienced developers, and it doesn't have the kind of ecosystem something like JavaScript or Python or Java or even C++ have. Nor can you easily hire contractors to help you on a project or to help clean up a mess.

Businesses like solutions that can be planned for, that are easy to hire for, that one can get help with if things go badly.

by adamc

1/13/2025 at 5:06:02 PM

When I started programming most of the world that I encountered seemed to be written in C++. I don't think Haskell and C++ are hugely different in terms of how long it takes to become proficient in them. The programmers I come across nowadays don't seem to be much different in terms of their ability from those C++ programmers. I think that if Haskell hasn't succeeded then the idea that workers are too dumb (or don't have the time) is not the cause. There are many smart people in industry who know about Haskell but do not find it attractive.

by discreteevent

1/13/2025 at 2:36:04 PM

The author seems to miss that many people don't write their lisp (or their game, or their code-golfing one-liner, or their befunge program) for it to be used, they write it because they enjoy writing a lisp.

As for those who believe their language of choice can actually become mainstream, it's a long, soul-crushing and miserable road.

by pyrale

1/13/2025 at 6:50:00 AM

It's so easy to get wrapped up building tools and frameworks and protocols and never do anything with them, or do anything else with your life, so I think it's important to have reasonable expectations.

Understanding what kind of things people will build with you language would probably help, so you don't waste time trying to please people who will not use your language anyway.

by eternityforest

1/13/2025 at 7:16:24 AM

Being popular is not the only goal of a programming language. Scheme is very successful language, not because it's much used but because it's small and elegant it's often used as a teaching tool and hence it has come to influence many of the designers of more popular languages.

by noelwelsh

1/13/2025 at 4:00:41 PM

Successful in academia. Not at all successful in terms of real-world use.

by adamc

1/13/2025 at 4:14:12 PM

I don't see why it's a "siren song". Being lured by sirens is deadly. Implementing a small language is a fun hobby and can be a useful learning experience.

by demetrius

1/13/2025 at 7:42:22 PM

It’s an issue with all metaphorical language. You want to compare it with one thing (irresistibility of the call, as TFA) and some non-zero percentage of your audience makes a different association (lured to their doom, as your interpretation).

by baruz

1/13/2025 at 1:04:57 PM

Actually using the language is something Jon Blow is definitely getting right with Jai, if it ever releases.

by whatsakandr

1/13/2025 at 5:34:07 AM

I'm not sure I understand the cryptography analogy.

by tptacek

1/13/2025 at 1:19:38 PM

"Some crypto primitives can be small and elegant, but to provide practical security they generally need extra layers on top of them," is what I understood. I'd compare it to simple textbook RSA vs. the whole ceremony of PKCS #1 padding. It fits into the broader theme that the simplest thing to implement is rarely the best thing to use.

by LegionMammal978

1/13/2025 at 5:50:12 AM

It's a fun observation, but the causality in this feels off. There are tons of esoteric programming languages that are difficult to write in and no one talks about because they have no other value. BF is not very useful for writing things in, but it has some value in being easy to implement. Would anyone sane genuinely encourage others to write something nontrivial in BF? What person looks at BF and says "ah, yes, this is a language I might like to write my next spreadsheet app and networking library in, let me play around in it for a bit to see if it might work", much less follow up with "oh no, I got distracted reimplementing it instead"? On the other hand, if I'm implementing an interpreter for fun, I'm going to pick something with a nice spec and my ability to actually use it is irrelevant. BF is great for implementing a spec exactly such that all existing tests and benchmarks just work.

I think the more likely scenario in a counterfactual world where Shen and Forth are difficult to implement is not that we have more things written in Shen and Forth, but that we have strictly fewer reasons to talk about Shen and Forth.

I am not convinced that the group that builds implementations and the group that builds the kinds of things that beget ecosystems for anyone other than compiler developers actually have much overlap. I do, however, think there is a strong overlap between the group that builds implementations and terminal-stage new-language addicts. An ecosystem for other things will maybe happen later if there's some other value to the language.

Where I think the article does hit on something is slightly less direct: users are more tolerant of a messy specification than implementors. C, C++, Python, Java and all the other languages that people actually use are ugly as sin at a semantic level, and yet we get by with copious handwaving. There are many problems, of course, with some of the handwaving users do to reason about these languages (hello, many warts of C), and generally, a preference for spec a user can keep in their head is a big productivity win, but if you want a language that people can use, you can afford to make your language a bit more complicated.

TL;DR: idk, make your pretty language with a beautiful spec if you want. Most languages are unused anyway. But there probably are diminishing usability returns for maximal spec beauty. If you care about that kind of thing, that is.

by oddity

1/13/2025 at 9:26:04 AM

I struggle to take such an article seriously when it cites Brainfuck as an example. A common use of Brainfuck isn't to write programs, but rather to prove that it is possible to write programs. This isn't exactly comparable with small Lisps or Forth.

by machinestops

1/13/2025 at 11:04:06 AM

I work in the same building as Urban Mueller (creator of BF). He told me the point of BF was to implement a compiler ;)

by rausr

1/13/2025 at 2:53:28 PM

You can write a program that takes BF code as input and outputs valid C source that would execute it in less than 20 lines of well formatted ANSI C using nothing more than putchar, getchar, while, pointer inc/dec and dereference, so I can imagine a full compiler for it would be super simple too.

(Though I bet an optimising compiler would be a _little_ more complicated) ;)

by jhonsrid

1/13/2025 at 11:32:44 AM

He told me its there to import geometry from standard formats into marching cubes and then octrees.

by InDubioProRubio