
A Plea for Lean Software (1995) [pdf] - tosh
https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf
======
jll29
It is worth re-posting this, and re-reading Wirth's works every couple of
years. The module concept of Oberon's predecessor Modula-2 is still unrivalled
today: _.def modules that specify the interface and that can be compiled
separately from their_.mod implementations, which may not even exist when a
client application can already be coded against the compiled interface in a
type-safe way.

Also, Wirth's book Compilerbau (in German, not sure if it was translated) is a
piece of pristine clarity; at just ~100 pages in pocket paperback form,
everyone reading it immediately feels writing a compiler or byte-code
interpreter is simple and they can do it.

~~~
pjmlp
I love Wirth's work, but that has been available in Ada, Mesa, Mesa/Cedar and
a plenty of other languages as well.

And since it is available in Ada, it is rivalled today.

More to the point, Ada allows for multiple interface packages, an idea also
copied by Modula-3, where the same package can be exposed in different ways to
multiple clients.

For example, the same package can have a public interface for in-house consume
that is wider than the official public interface for third parties.

~~~
jolux
> For example, the same package can have a public interface for in-house
> consume that is wider than the official public interface for third parties.

Isn’t this similar to package private in Java or internal in C#?

~~~
pjmlp
Not really, because the interface is separate from the implementation and you
can provide multiple interface packages for the same implementation package.

So client A sees mylib-public-A, client B sees mylib-public-B, but both link
to the same mylib so to speak.

~~~
jolux
Ahhh, neat!

------
wombatmobile
"With Project Oberon we have demonstrated that flexible and powerful systems
can be built with substantially fewer resources in less time than usual. The
plague of software explosion is not a "law of nature."

What then, in the software world, is a "law of nature", and how might we
discover such a law/s by examining evidence, such as, the evidence deposited
over the last 25 years of software proliferation?

Might we examine source code, or executable code?

Or number of users?

Or revenue from sales?

Or aesthetic qualities of the source code, such as structure, legibility, or
maintainability, or portability; or qualities of the executable code, such as
size, performance, or intuitiveness of the UI?

~~~
eterps
One thing that has been sorely missing IMO in the last 25 years of software
proliferation is a complete usable system that can be understood in its
entirety by a single human being in one lifetime.

It doesn't have to be your day-to-day desktop, but for learning, research and
experimenting I think solutions with that goal would still be worthwhile.

~~~
chriswarbo
Viewpoints Research Institute (VPRI) tried to make such a system around 10
years ago [http://www.vpri.org](http://www.vpri.org) (e.g.
[http://www.vpri.org/pdf/tr2012001_steps.pdf](http://www.vpri.org/pdf/tr2012001_steps.pdf)
)

IIRC it bootstraps from a prescheme-like language into a Smalltalk-like
dynamic language (
[https://www.piumarta.com/software/maru](https://www.piumarta.com/software/maru)
[https://www.piumarta.com/software/cola](https://www.piumarta.com/software/cola)
), and uses PEG parsers (
[https://en.wikipedia.org/wiki/OMeta](https://en.wikipedia.org/wiki/OMeta) )
to implement domain-specific languages, e.g. the Nile graphics language (
[https://github.com/damelang/nile](https://github.com/damelang/nile) )

~~~
eterps
Thanks, I am aware of the research at VPRI. However nothing coherent seems to
have come out of it. Yet I am running a complete Oberon system on my laptop as
we speak. And all source and documentation is available at
[http://www.projectoberon.com](http://www.projectoberon.com) I really liked
the idea though.

~~~
scroot
I really wish he would release the updated Oberon book in another format
besides PDF.

------
theptip
I don't really buy the core premise that "Enhanced user convenience and
functionality supposedly justify the increased size of software, but a closer
look reveals these justifications to be shaky".

Users can still choose to use vi, or emacs, or textpad, or whatever stripped-
down, fast, minimalist software they prefer; the old stuff hasn't gone away.
Meanwhile, my IDE re-compiles/re-parses my program as I type, and tells me
immediately if there are errors. I choose to use the bigger, "slower" program
because it makes me dramatically more productive. Sure, input latency might
not be as good as a barebones editor, but that cost more than pays for itself
(as always, for me -- YMMV).

I can appreciate the aesthetic desire for a lean, minimal program, but to
ignore the very real productivity benefits that come from tolerating larger
programs is, I think, myopic.

This comes up around here a lot in the context of slow web pages; a very
important thing to note that I think is often overlooked is that it's not just
the user's productivity that matters. If developers have to spend 2x the time
optimizing their code to fit in a limited memory allocation, then that's 2x
the cost to the consumer for the same amount of features (or 1/2 the features
for the same price). If speed/performance is a feature that your customers
want to pay for, they will let you know. If it's not, then your competitor
will eat your lunch by building more features that users actually care about,
while you optimize your existing feature-set.

Programs are bounded by "feels slow" on one side, and "expensive to optimize
further" on the other. If 99.9% of your users (i.e. the lay users, excluding
the experts in the HN crowd) don't perceive your program/page to be slow, why
would you optimize further? Sure, if you're Google, a few ms faster can equate
to millions of dollars of revenue, but that's not the fitness landscape that
most software evolves in.

~~~
wtetzner
> If 99.9% of your users (i.e. the lay users, excluding the experts in the HN
> crowd) don't perceive your program/page to be slow, why would you optimize
> further?

And how do you know if they perceive it to be slow? I suspect that if you did
optimize it to be faster (e.g. lower latency interactions), they would notice
the improvement, even if they weren't sure why it "felt" better.

> If speed/performance is a feature that your customers want to pay for, they
> will let you know.

I don't buy that. Customers often don't even know it's a possibility that
their software could be faster.

In my experience, often lay users don't think of individual programs as being
fast or slow. They either assume the "internet" is being slow, or their
computer is slow. However, I think they do notice when performance is better.
They say it "works better" or "feels more reliable", but they don't
necessarily know why.

~~~
theptip
> And how do you know if they perceive it to be slow?

Ask them, or listen to what they are saying without you asking. (I.e. UI/UX
research 101.) For an IDE with a large userbase (for example JetBrains'
product line), there are plenty of bug reports / user reviews which complain
about performance, and so it's possible to get a picture of how many users
perceive your app to be slow.

Note, I chose my words carefully there -- if your users don't perceive the
site to be slow, they may still respond positively to imperceptible
performance improvements. To measure that you do A/B experiments. There's a
lot of ink spilled on this subject; Google has done some really good research
here.

> Customers often don't even know it's a possibility that their software could
> be faster.

Fair, I probably oversimplified there. More precisely, "If speed/performance
is a feature that your customers will pay for, you should be able to measure
that fact."

You don't necessarily need to invest in the performance improvements to
measure this; when Goole investigated this they simply added artificial delay
and measured the effects on revenue. From this you can estimate the gradient
of the $-revenue / ms-latency slope, and figure out how much it's worth
investing in improving your app/site's latency.

~~~
cxr
> so it's possible to get a picture of how many users perceive your app to be
> slow.

No, it isn't. That's "Recognizing Survivorship Bias 201".

~~~
tlb
People, depending on their expectations, will perceive your app as one of
these categories:

\- A: not slow

\- B: slow, but still using

\- C: intolerably slow and no longer use it

Indeed, you can't measure C with a survey. But for most apps, it's probably
reasonable to assume a distribution of thresholds where, if B/(A+B) (ie, the
result you get on a survey of users for "is it slow") is less than 5%, there
probably aren't many in C.

~~~
cxr
That's bad science.

~~~
tlb
User surveys are never going to be good science. Surveys are confounded by
massive variation in response rates. For instance, I haven't filled out a user
survey in many years because I have better things to do. They can only ever
give a vague indication that something might or might not be a common issue.

The scientific approach to find out if app slowness is a problem is to make a
much faster version, give that to some fraction of users in an RCT and see if
their usage goes up. But that makes no sense for a business. If you make the
effort to develop a fast version, just give that to everyone and move on to
the next thing that might get you more users.

------
Rochus
> _Nikolaus Wirth: A Plea for Lean Software (1995)_

He spells Niklaus, see
[https://en.wikipedia.org/wiki/Niklaus_Wirth](https://en.wikipedia.org/wiki/Niklaus_Wirth).
And yes, he has a sound, pragmatic attitude towards software systems.

Nikolaus is another famous person.

~~~
jll29
Nikolaus with an "o" aka St. Nicholas or (Saint) Nicholas of Bari, was an
early Christian bishop of Greek descent based in what is now Demre, Turkey.

~~~
wombatmobile
In 1931 the Coca-Cola Company began placing Coca-Cola ads in popular
magazines. Archie Lee, the D'Arcy Advertising Agency executive working with
The Coca-Cola Company, wanted the campaign to show a wholesome Santa who was
both realistic and symbolic. So Coca-Cola commissioned Michigan-born
illustrator Haddon Sundblom to develop advertising images using Santa Claus.

For inspiration, Sundblom turned to Clement Clark Moore's 1822 poem "A Visit
From St. Nicholas" (commonly called "'Twas the Night Before Christmas").
Moore's description of St. Nick led to an image of a warm, friendly,
pleasantly plump and human Santa. (And even though it's often said that Santa
wears a red coat because red is the color of Coca-Cola, Santa appeared in a
red coat before Sundblom painted him.)

In the beginning, Sundblom painted the image of Santa using a live model — his
friend Lou Prentiss, a retired salesman. When Prentiss passed away, Sundblom
used himself as a model, painting while looking into a mirror.

------
kummappp
'strongly typed language increases the productivity' How was this tested? Was
there a control group? I would argue that currently Javascript and Python have
been greatly improving the productivity. The type system works well in the
maintenance, API definitions and 'no unit tests' scenarios, but when you have
to do something you don't have yet any clue about -for exmple at the start of
a years long app development project, the type system is just in the way.

~~~
yodsanklai
> How was this tested? Was there a control group?

I agree this deserves some study. But...

> when you have to do something you don't have yet any clue about the type
> system is just in the way

Even if you don't have any clue, you usually know the types of your functions
and data structures.

I mostly write Python and OCaml code. Each langage has its use cases, but I
rarely feel the OCaml type system is in my way. When it's in my way, it's
because my code is incorrect in an obvious way.

~~~
kummappp
Yeah, the type system helps in that, but for a unit testable product you need
factory methods, which produce some valid and invalid cases. If you write
simple tests for those it is a type checker on it's own and the type checker
is just overhead. If I could choose my next project from two similar
implementations where the other would be type checked and the other unit
tested with basic datatype factors (at least) I would choose the unit tested
one.

I would use typed API's though, because it saves documentation reading time
and makes the editor autocomplete to work like magic.

~~~
wtetzner
> If you write simple tests for those it is a type checker on it's own and the
> type checker is just overhead.

This is not true. Unit tests cannot replace a type system, just like a type
system cannot replace unit tests.

You need a unit tests because a type system cannot check for all possible
types of correctness.

However, unit tests can only check for the presence of bugs; they cannot prove
their absence. On the other hand, a type system can prove that certain classes
of errors cannot exist in the program.

------
dang
If curious see also

2018
[https://news.ycombinator.com/item?id=17872400](https://news.ycombinator.com/item?id=17872400)

2014
[https://news.ycombinator.com/item?id=8537970](https://news.ycombinator.com/item?id=8537970)

2014 (and better)
[https://news.ycombinator.com/item?id=8301511](https://news.ycombinator.com/item?id=8301511)

------
mro_name
thank you very much for this official resource, I just knew djb's copy.
There's also the predecessor in german reading "Die Software Explosion"
[https://darknet.mro.name/1994-wirth-
explosion.txt](https://darknet.mro.name/1994-wirth-explosion.txt)

IMO a great read for everybody interested in long-term reliability or
sustainability.

------
dzonga
crazy back then, people were still complaining about c and c++. c, easy
language to get started, but a bazooka to your foot and head.

~~~
Gibbon1
I feel like C is like the old joke where a man goes to the doctor and says,
doc I got broken bones in a dozen places. And the doctor says, well stay out
of them places.

~~~
pjmlp
See Azure Sphere for such example, while MSR advocates moving away from it,
the Azure Sphere team has decided otherwise, advocating its use as main SDK
language, due to market culture.

The expected end result, in spite of the mitigations put in place, is the
Azure Sphere 20.07 Security Enhancements bug fixes release.

[https://techcommunity.microsoft.com/t5/internet-of-
things/az...](https://techcommunity.microsoft.com/t5/internet-of-things/azure-
sphere-20-07-security-enhancements/ba-p/1548973)

~~~
Gibbon1
Joke cuts both ways.

I write firmware in C because flash memory costs us money. I wouldn't
recommend C or C++ otherwise. Stay away.

On the other hand C is kind docile as long as you avoid doing 'insert long
list of sketchy stuff'.

