
Two ways to keep a language lean (2015) - buzzybee
http://comp.lang.modula2.narkive.com/GgnXF0Ab/the-two-ways-to-keep-a-language-lean
======
mhd
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.

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

~~~
dkersten
_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.

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

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

~~~
1wd
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.

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

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

[http://www.pascal-central.com/docs/iso7185.pdf](http://www.pascal-
central.com/docs/iso7185.pdf)

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

------
Animats
There are still people working on Modula-2?

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

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

