A Plea for Lean Software (1995) [pdf]

https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf

by tosh • 6 years ago

163 137 6 years ago

people.inf.ethz.ch

Rochus4• 6 years ago

Nikolaus Wirth: A Plea for Lean Software (1995)

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

Nikolaus is another famous person.

tosh• 6 years ago

ty!

jll292• 6 years ago

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.

Rochus4• 6 years ago

Long before computer science, even though the ideological attitudes might be similar ;-)

zeveb• 6 years ago

(Saint) Nicholas of Bari

Of Myra, actually — his relics were stolen from his tomb in Myra by sailors from Bari, where they remain today, but he probably never even visited there.

wombatmobile2• 6 years ago

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.

kummappp4• 6 years ago

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

Rochus4• 6 years ago

I assume we agree that "productivity" doesn't just cover writing code, but also avoiding/finding bugs and maintaining the code over a long period by different people. TypeScript is a big progress over JavaScript in this respect.

mcv5• 6 years ago

That's not my experience, sadly. We switched from Javascript to Typescript over a year ago, on a fairly new project, but it mostly results in more errors that need to be fixed, that wouldn't have been errors in Javascript.

Being able to specify interfaces is absolutely nice, but overall I'm not convinced it's worth the trouble.

dgb232• 6 years ago

I'm not convinced of TS as of yet for my needs. The vast majority of bugs and complexity in UI code seem to come from state management, asynchronicity, complex validation and the like. Static typing doesn't help with any of these or at least not to a degree that is sufficient. TS also doesn't seem to help at all with performance, which I find to be the most important trade-off for introducing types and the implied complexity.

I'm heavily biased towards small teams and small to medium programs though. I can at least imagine how TS improves ad-hoc documentation in some cases, which can definitely help in the "maintaining the code over a long period by different people"-scenarios.

mhd4• 6 years ago

Implementing Oberon the language went hand in hand with implementing Oberon the operating system. So when we're talking about productivity he's mostly talking about operating systems and interfacing with hardware, where you usually have more clearer concepts. The direct comparison would be assembly or C here.

For web gadgetry or exploratory ad statistics, you might end up with different productivity-enhancing features.

yodsanklai• 6 years ago

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.

kummappp4• 6 years ago

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.

Jetrel2• 6 years ago

Yeah, this pretty much echoes my experience working with type-safe languages.

In the case of my anecdote here, I'm mostly talking about typescript, but I've worked with a bunch of other ones in a non-web context.

Every single time, without fail, when I get a "snag" from the type-system, it's complaining about something real. Sometimes it's a trifling bug, like a typo, but ... even there it's usually pretty nice to have the type system immediately jump on it and report it, without me having to deploy the thing and run it and only then find out that something is wrong.

But the other class of bugs - that's where it's solid gold. It'll often catch really sneaky bugs, bugs related to "nullability", where some object I'm blindly using isn't guaranteed to stay allocated during the use case I expect it to be useable in, and holy smokes are those a lifesaver. Having had to deal with those bugs from the opposite direction, they're an unleaded nightmare to try to fix without the type system pinning down exactly the culprit that would be causing it. Every time I see one, I immediately think "wow, this would have been a 5-10 hour nightmare if I had to fix this because of some production bug". I've been in the office till 10pm, and ... I never want to do that again if I can avoid it.

carterklein13• 6 years ago

I think that JavaScript and Python, from my experience, certainly increase speed... but that definitely != productivity.

If you want to get something up and running fast, then JS/Python should absolutely be your go-to. We have an "innovation sprint" every quarter where everyone gets to try out changes and new features and anything else they wish to hack with our system, and I would say 99% of people choose to do this work in JS/Python.

However, my personal opinion is that productivity's first and most important pillar should be maintainability, followed closely by readability, with speed relatively far behind.

Again, this is just my two cents, but I equate Python or JavaScript to sending a message without things like capitalization and punctuation. Works perfectly fine for Slack, but not as well for writing a novel.

aszen2• 6 years ago

Adding types at the start of a years long project is going to help massively later on at some slight friction early on. Static typing makes explicit connections between code that are usually implicit in dynamic languages, these connections if left untyped will break sooner or later once more programmers start contributing code without having the implicit knowledge about how the code is connected

guidoism• 6 years ago

Python is strongly typed. Maybe you are confusing strong vs static typing.

kummappp4• 6 years ago

Yeah I did mix them. Thanks.

kummappp4• 6 years ago

But I bet Python has a loopholes in the type system as well. I mean you can take the stack, and modify the running code in every way possible at runtime, but it is a slightly mad thing to do.

phtrivier• 6 years ago

There were (arguably unsuccesful) attempts at testing such things in labs: https://danluu.com/empirical-pl/

My interpretation is that the conclusion, at the moment, is that we can't know for sure, scientifically, which one is "better".

That being said, I sill have to find the randomized, double blind test that proves a hammer is the right way to hit a nail.

wry_discontent• 6 years ago

I don't see how you could test a statement like that scientifically. Maybe you could argue, for most people? For certain people? People conceive of problems and solutions differently and I doubt it is particularly standarizable in terms of type systems.

bob1029• 6 years ago

Strong typing over the long term will always produce a more maintainable software product when used correctly. For many applications, you might not encounter enough complexity for it to matter strongly one way or another. Once you do finally encounter that application with 40 different entity types, 12 different business contexts that each of those can uniquely interact within, and hundreds of properties for each, you will be scrambling to find some way to bring order to your chaos.

Dynamic typing is useful if you are forced to develop software before you understand the business model or if you need to expose some DSL to your users. I normally view it as a short term option that is typically reached for when not enough actual engineering has occurred (in more complex systems). It's also mandatory for working within certain domains (i.e. the web). I think this last point is why so many seem to think its a perfectly acceptable way to carry on in any sense.

marcosdumay• 6 years ago

the type system is just in the way

That's an usual symptom that you are trying to write untyped code in a typed language.

There are few cases where types do get in the way, but in the huge majority of the cases the types are there for you to explore your ideas on them first, and only mess with the code once they make sense.

rvense• 6 years ago

for example at the start of a years long app development project, the type system is just in the way.

Subjectively, my experience is that writing out the type definitions and signatures of main functions is a great way to start exploring an unknown problem space.

eternalban• 6 years ago

when you have to do something you don’t have yet any clue about

This is an experience issue, not a type-system issue. Rapid refactoring is also possible during initial passes while design is settled.

AnimalMuppet3• 6 years ago

I think in software engineering, the answer to almost everything is "it depends".

Strongly typed languages increase productivity if the cost of a type mismatch bug exceeds the cost of defining and specifying the types. That's true for some programs, and it's not true for others.

jll292• 6 years ago

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.

Rochus4• 6 years ago

The module concept of Oberon's predecessor Modula-2 is still unrivalled today

The module concept of Oberon is also very good (leaner than Modula's). There are also other languages with good module concepts, e.g. Ada, or the CLR based languages.

Wirth's book Compilerbau ... is a piece of pristine clarity

For a certain type of compiler (rarely used today).

mhd4• 6 years ago

That would be "Compiler Construction", the last version being freely available[1].

Given that Oberon is a simpler language than pretty much all of its predecessors and that the latest revision went even further, I'd be interested what Wirth does think about contemporary strongly typed system languages like Rust or Go (the latter being quite, erm, influenced by Oberon). Or heck, Eiffel, being the language of his successor at ETH Zürich.

IIRC he didn't have a high opinion of functional programming.

[1] https://people.inf.ethz.ch/wirth/CompilerConstruction/index....

mhd4• 6 years ago

Ah, found it here[1]:

"To postulate a state-less model of computation on top of a machinery whose most eminent characteristic is state, seems to be an odd idea, to say the least. The gap between model and machinery is wide, and therefore costly to bridge."

[1] https://people.inf.ethz.ch/wirth/Articles/GoodIdeas_origFig....

pjmlp12• 6 years ago

Easy, it thinks they are full of bloat, including Go.

Each release of Oberon-07 drops features, it is reduced to a C like with GC, with a single form of loop constructions.

fauigerzigerk• 6 years ago

Sounds like COM type libraries.

pjmlp12• 6 years ago

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.

jstimpfle3• 6 years ago

Don't forget C, which has separate compilation as well ;-). And you can trivially make multiple interfaces, too.

bpyne2• 6 years ago

Ada came to mind when the parent mentioned separate interface and implementation files. Making methods in the implementation private unless they appear in the interface was an inspired design decision. I use only Oracle's PL/SQL dialect but I appreciate the design of Ada more the longer I code. Honestly, I'd consider using full-blown Ada in modern software development. It gives you the ability to write really clean code.

wtetzner6• 6 years ago

OCaml (and probably Standard ML) also have powerful module systems that I would argue rival Modula-2's module system.

jolux2• 6 years ago

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#?

wtetzner6• 6 years ago

The module concept of Oberon's predecessor Modula-2 is still unrivalled today

I'm not familiar with Modula-2's module system. What does it provide that the module system of OCaml does not?

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

I believe .mli files can be compiled separately from the matching .ml files, and client modules can be compiled against an .mli that does not have a corresponding .ml file.

And OCaml also supports functors, so modules can be parameterized.

Sorry, not arguing that Modula-2's module system is not good, guess I'm just not convinced that it's unrivalled today. And for all I know ML's module system was probably influenced by Modula-2.

wombatmobile2• 6 years ago

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

eterps5• 6 years ago

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• 6 years ago

Viewpoints Research Institute (VPRI) tried to make such a system around 10 years ago http://www.vpri.org (e.g. 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/cola ), and uses PEG parsers ( https://en.wikipedia.org/wiki/OMeta ) to implement domain-specific languages, e.g. the Nile graphics language ( https://github.com/damelang/nile )

kqr6• 6 years ago

a complete usable system that can be understood in its entirety by a single human being in one lifetime.

Wait, what does that even mean? I assume it cannot, then, run on hardware executing any form of microcode because that adds many man-years of what's essentially software complexity to the problem.

What I'm trying to say is that at some point you have to draw a line and say "anything below this line is considered the platform the software runs on, and does not need to be included in the understanding" and where you draw this line is completely arbitrary.

One might argue that x86 is a platform that doesn't have to be understood, as long as one understands its interface. Someone else can argue that the JVM is a platform whose internals need not be understood. Yet other people popularly picture the web browser as their platform. In the extreme case in the other direction, electrical circuits (with a dash of quantum mechanics, I think?) could be considered the platform of the x86.

I have yet to hear a rational argument for why a particular thing counts as "the platform" more than any other.

joveian• 6 years ago

NetBSD (and I'd guess OpenBSD) are closer to that than any other similarly functional operating systems I know of. Still quite a lot of code (and arguably not complete, depending on how you define that) but way easier than Linux.

keedon• 6 years ago

http://www.projectoberon.com/ has all of the source and the Oberon book

p_l• 6 years ago

If you reduce essential complexity to minimum, such a task is trivial to experienced engineers and computing scientists, like Wirth himself.

Like many such products, it will work so long as you're able bodied and only need the same human language as the author, preferably one that doesn't have complex requirements and can fit in 7 bit ASCII.

I no longer have the source, but a great example someone once gave was that Oberon had pretty minimal support for anything, to the point that sharing information by email was hard due to "how do I share my paper" problem.

dzonga• 6 years ago

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.

hinkley• 6 years ago

Didn't we just complain about C++ this weekend?

Gibbon12• 6 years ago

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.

pjmlp12• 6 years ago

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

theptip6• 6 years ago

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.

minimuffins• 6 years ago

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

This doesn't really disagree with the argument from the piece. You could summarize this line of thinking this way: The pressures at work in the software market drive us to create slower and slower software. It seems like everyone actually agrees on that point.

The only real disagreement seems to be how to respond to the fact. It's either, "Well shucks, that's just the way it is. At least I have auto-complete" or a feeling that, despite the pressures to just bloat and expand and slow down forever, it would be nice if we tried to combat it.

theptip6• 6 years ago

I think that's a fair comment.

My counterargument would be that if the new way of building software proposed in the OP was actually a significant improvement, someone would have built a new IDE with it, and eaten JetBrains' lunch. Instead, we got Atom; prioritizing pluggability/extensibility/hackability over footprint/latency.

To be clear, I'm not arguing for a fatalistic position that "there's nothing we can do about it". We can, and do, optimize performance when required.

I'm just arguing for a more nuanced appreciation of the cost/benefit calculation that's at play here.

Either there's an explicit cost/benefit being done (e.g. a PM weighs the "go faster" story vs. the "add new widget" story) or an implicit one (app #1 prioritizes speed, app #2 prioritizes features, and customers vote with their dollars; market share reveals which is more valuable).

ramzyo• 6 years ago

Thanks for your comment, as a VIM user who often turns up my nose at “slow” IDEs it helped me to understand a perspective that I would otherwise ignore, and reminded me that ultimately it’s what works for the individual that matters over any dogmatism that I may have.

To offer an alternative perspective on this bit,

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?

For me personally as a practitioner of software engineering; because I can, and it’s meaningful to me to optimize in the broader context of designing and implementing a system, in part to see what’s possible in addition to the personal enjoyment of going through the process.

That being said, for a company focusing on optimizing value to customers as a function of engineering resource allocation, I agree that it doesn’t make sense to optimize. You summed it up nicely with “...but that’s not the fitness landscape that most software evolves in.”

cxr10• 6 years ago

Thanks for your comment, as a VIM user who often turns up my nose at “slow” IDEs

Note that the mention of Vim by the original commenter is a red herring arising out of lack of familiarity with Wirth. In Wirth's eyes, even Vim would appear monstrous.

To appreciate Wirth's point requires realizing that his frame of reference is the Oberon (eco)system, which includes an OS, a mouse-driven graphical shell, a compiler, and the underlying CPU in an HDL all in a few tens of thousands of lines of code.

wtetzner6• 6 years ago

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.

jayd16• 6 years ago

After a threshold the business value drops off substantially. How often does a consumer pick between competitors and choose based on speed? I would assume that's vastly in the minority.

You see some shakeups here and there. A large push to a new browser once a decade, etc. but features are king most of the time.

theptip6• 6 years ago

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.

loup-vaillant• 6 years ago

https://www.youtube.com/watch?v=k8gIJOy0c2g

It's not just developer writing a program for one user. It's a very small number of developers writing programs for many many users (unless you make custom software). The impact of what devs do is multiplied by the number of users. That includes the negative impacts of being slow or requiring more resources than necessary.

Imagine Photoshop users having to buy more RAM not just because it is needed by some functionality, but because that functionality used more RAM than was actually necessary. The sheer waste, in money, carbon footprint, and pollution...

Granted, optimising takes time. Time that would be taken to write features. There's a tradeoff there. But we should keep the competition in mind here: there's a difference between a feature being unavailable because you spent time optimizing, and a feature being available elsewhere instead. While it make sense for Photoshop devs to push features as fast as they can, it doesn't to users any good if Krita already offers those features. (I'm ignoring incompatibility here, but you get the idea.)

The incentives are all wrong in my opinion. We should have fast, lean, correct programs to work with. They just don't happen in the current economic system.

dang• 6 years ago

If curious see also

2018 https://news.ycombinator.com/item?id=17872400

2014 https://news.ycombinator.com/item?id=8537970

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

mro_name• 6 years ago

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

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

A Plea for Lean Software (1995) [pdf]

Related Stories