Two ways to keep a language lean (2015) | Hacker News Reader

Two ways to keep a language lean (2015)

comp.lang.modula2.narkive.com

58 pointsbuzzybee15 comments

I know that it's one of IT's hard problems, but one of the best ways of keeping a language lean is renaming it after it accrues a certain amount of changes, or at least attaching a qualifier. If users are still interesting programming with HyperPascal, Modulatrix Xtreme Pro or "Mongolian Vowel Separator", then feel free to make some more considerable changes.

Otherwise I'd be very careful, and especially if it's actually a language with multiple implementations.

That is why we have version numbers.

Usually languages are extended. C++11 and C++14 are different languages, although the first is a subset of the second. That does not always hold. For example, Python2 and Python3 are different languages.

In line with the article: If you only provide a subset, give it a different name. Prepend a "mini" or "micro" or whatever. For example, "MiniPython" would be expected to provide a subset of Python.

> That is why we have version numbers.

This is why the authority for the language has version numbers. If it's just your compiler, it's a bit impertinent if not outright illegal to call it C 2.4.

And depending on the amount of changes, I don't think this is necessarily a good idea. Perl 6 comes to mind.

Python2 and Python3 are different languages.

I think this is a bad example, because they want to abandon Python2 and move everyone to Python3, yet, almost 10 years later, many people are still using Python2. So I would say that the Python way is NOT how one should keep a language lean.

I think it is the way you keep a language lean. If you want Python 3, you have only a few choices: You can make very few changes from Python 2, you can make breaking changes, or you can extend but not break. If you make very few changes, the language doesn't progress very much. If you extend but don't break, the language progresses, but it doesn't stay lean. If you make breaking changes, the language can stay lean, but you lose a bunch of users who stay with the previous version.

There is no perfect answer. Progressing, lean, and compatible: pick at most two.

The claim here is that if a language is not hyper-extensible the community will add crufty features to it over time and that is why languages originated by Niklaus Wirth are getting crufty.

But was Pascal ever more more minimal than C11? Maybe by some metrics, but the difference cannot be big.

Now there is plenty of stupidity in modern C standards, but that is mostly about letting compilers play hell with undefined behaviour in the name of over-aggressive optimisation. It doesn't fit in with the language-bloat thesis of the article.

Here's one metric: The Pascal 1990 ISO Standard was under 100 pages long. The C90 standard was about 230 pages, and the C11 standard about 700 pages long.

Did the pascal standard include the standard library? Because C does. Doesn't seem like a fair comparison unless both standards specified standard libraries with comparable features.

I'm pretty sure it included its equivalent functions and definitions

http://www.pascal-central.com/docs/iso7185.pdf

I would expect the standards to grow as they take care to nail down more and more corner cases.

I don't want to dismiss that: the "stupidity" I mentioned above is largely about making wrong decisions about those corner cases. Indeed, I suspect if the right decisions had been made, the standard could have been shorter. Though perhaps only by a factor two.

I would say, yes, Pascal was more minimal, either language to language, or language + library to language + library. Pascal was like programming while wearing a straightjacket; you did things Pascal's way or not at all. C let you do things in a number of different ways.

According to the comment, sustained simplicity occurs only

1. for as long as there is a champion to remind its practitioners, e.g. Wirthian languages at first

2. if they don't need to because they're extensible, e.g. Forth, Scheme, Smalltalk

Maybe these aren't the only requirements. Apache Groovy introduced annotations in version 1.7 so programmers could introduce their own syntactic extensions, and its backers often declared "no new syntax". Unfortunately, Groovy's project manager changed the @Trait annotation to a `trait` keyword in version 2.

There are still people working on Modula-2?

Yes, and there are still people working on GNU HURD.

It's just pushing the cruft down the road. In my opinion that cruft is harder to deal with when it is maintained in countless different ways but countless different people using countless different methodologies.

Reply on news.ycombinator.com