14 ms·

Niklaus Wirth, or the Importance of Being Simple

304 points by madmax108 3y ago

xg15 3y ago
Sometimes a picture is wirth a thousand words.
WalterBright 3y ago
> in the sense that the limitations and exclusions of the language design were precisely what made compact implementations possible and widely successful. All of the Pascals that were widely successful extended the language in key ways. I was an initial fan of Pascal, until I discovered that a large amount of my time was spent trying to work around limitations of the language. With C, those workarounds disappeared and I was far more productive. (I know C compilers always have numerous extensions, most of them of dubious value, but still, plain C remains a far, far more useful language than the Pascal of "Pascal User Manual and Report". Which is why C buried Pascal.)
- userbinator 3y ago
  One could argue that C's success is largely because it was even simpler than Pascal and more generic --- a notable example is that Pascal has I/O built-in to the language, while C defined them as part of the standard library (which could even not be present.)
  - WalterBright 3y ago
    From a compiler writer's perspective, C is much more complex than Wirth's Pascal. Pascal's builtin I/O was a major impediment to its usability. However, one really great feature of Wirth's Pascal is nested functions with access to outer scopes, which D wholeheartedly embraces. They really are slick. I use them heavily.
    - dist1ll 3y ago
      > one really great feature of Wirth's Pascal is nested functions with access to outer scopes, which D wholeheartedly embraces Can you give an example? What does the function access in the outer scope? Is it like an environment-capturing closure?
      - WalterBright 3y ago
        It can access the variables in an outer scope: int moon(int s) { int sum(int x) { return s + x; } return sum(3); } An extra parameter is passed to the nested function, called a "static link", which is a pointer to the stack frame of the statically enclosing function. This is in addition to the usual "dynamic link" which is a pointer to the stack frame that called the nested function. Nested functions can also be nested, and can access variables in enclosing functions by walking the static links back. The neato thing about this is it makes stack frames work exactly like members of a struct. In fact, a pointer to a nested function is analogous to (and binary interchangeable with) a pointer to a stack object.
        loup-vaillant 3y ago
        My first (and only) serious compiler had such nested functions, though without stack frames. Instead my VM had two stacks: one for function arguments and locals, and the other for return addresses, same as Forth. I had no stack frame at all. Instead, the compiler kept track of the stack offset of every accessible local (relative to the top of stack). That way the implementation of my nested function was kind of trivial: there were no difference between true locals like `x` and locals from an outer scope like `s`, except of course for the possibility of shadowing. One reason this was not special is that internally, it was nested scopes all the way down: there was one scope per local variable, so merely declaring two variables already means dealing with nested scopes. Once that was out of the way adding nesting functions was really easy (I believe it added less than 20 lines to my compiler). Nowadays I think I would use a single stack instead, but if my language is simple enough I’ll probably skip the frame pointer and just keep track of offsets like I did this first time.
  - cxr 3y ago
    > One could argue that C's success is largely because[...] Why do so many ignore the obvious? Ergonomics matters. At a time when most programmers didn't touch type (even the big stars), the economy of being able to type `int foo(int bar) { ... }` is a major productivity boost in comparison to `PROCEDURE foo(VAR bar: INTEGER); BEGIN ... END foo;`. Hell, that even bothers modern programmers. I mean, I know people whose entire reason for switching to Chrome when it came out was that the toolbars at the top of the screen were 18 pixels shorter or whatever. That's it. People are incredibly capricious. Factor in the environment—Unix has a widely acknowledged beauty/elegance in its design—and it's not hard to see why people gravitated to C, even at a time when Pascal was anointed as the official development language by Apple for a platform where people were known to be able to make money writing apps and selling them to businesses and consumers alike.
- jdougan 3y ago
  As I said in another forum earlier this week, "A lot of the hate centered around how it wasn’t a systems programming language, when it wasn’t supposed to be one. It’s like complaining your driving instructor’s car can’t be used to dig a trench without extensive modification." After BASIC, I learned on Pascal (Apple and IBM). It was invaluable to clarify in my mind how programming structures work, as opposed to the (fun) chaos of early BASICs. I really didn't need much more than the I/O available in standard Pascal at the time. And it hid details like endianness that I was not yet ready to handle. Were there problems? Of course. Among others, the vendors should have done a lot more to standardize extensions, the P1 parameterized array bounds should have been in the initial spec, and while the P-machines had many virtues, performance was not one of them. Far too many of the early implementations just ran the P-code in an interpreter.
  - WalterBright 3y ago
    It's been well over 40 years since I wrote Wirth Pascal code, but one of the problems was one couldn't write a line without a line ending. That's not an activity confined to system programming!
    - jdougan 3y ago
      Sure. But for the output of the tiny calculator class project we did, it just didn't matter.
      - WalterBright 3y ago
        Yes, Pascal is good for that purpose.
        082349872349872 3y ago
        Many of the decisions for Pascal seem aimed for a teaching language as opposed to a production language. For instance, in a production language, optimisation of generated code is worth a longer compile cycle, but in a teaching language (where programs are repeatedly resubmitted until they barely run, and then are never touched again) short* compile cycles are everything and quality of generated code is an afterthought. * and cheap: I remember in the days of 30 engineers sharing a VAX that if one person was compiling at a time everything was snappy, but (especially near the end of quarters!) if ten people tried compiling at once interactive latency suffered greatly. Classroom use must've been even worse.
- pjmlp 3y ago
  Pascal also has had numerous extensions. No one used Pascal of "Pascal User Manual and Report" from 1976. Strangley compiler extentions are only cool when talking about C, in fact, most C developers have no idea what ISO C is actually all about.
  - AnimalMuppet 3y ago
    I did, in 1986 through 88. The only extension it had was separate compilation. (This was on PDOS running on a 68000, for the morbidly curious.) And I agree with WalterBright. Unextended C was far more usable than unextended Pascal.
    - pjmlp 3y ago
      From the looks of Small-C and RatC not really that usable. During the 1980's there was already several usable Pascal alternatives, plus Modula-2 came out in 1978 exactly to fix the shortcomings of Pascal without extensions, and the largely ignored ISO Extended Pascal came in 1991, retifying many of the 1980's common extensions. Using original Pascal, was really when there was no alternative, like myself trying to fit some form of Pascal compiler into a 48 KB on top of Timex 2068 ROM, which naturally wouldn't fit. Neither did the Darthmound BASIC JIT compiler for that matter, or one of those Small-C / RatC alternatives.
      - WalterBright 3y ago
        I remember the Modula-2 crowd being rather bitter that the advent of C++ sunk M-2. One of the M-2 compiler guys ruefully said to me "I backed the wrong horse." (Zortech C++ had taken the PC market by storm then.) The success of ZTC++ is why Borland changed direction from Pascal to C++. I heard rumors that Microsoft had been internally developing its own OOP language, but abandoned it and switched to C++ also after the success of ZTC++.
        unscaled 3y ago
        Borland did keep supporting Pascal in addition to C++ then, no? They introduced Object Pascal with Turbo Pascal 5.5 IIRC, and later kept extending that with Delphi. As far as I know, their strategy was playing both Pascal and C++ up through the bitter end with Delphi and C++ Builder. I don't know which of them, C++ or Pascal/Delphi, but Delphi was certainly popular enough at its heyday. Obviously, Object Pascal was a very far cry from the Pascal User Manual and Report, and even at its extended version it was strictly less powerful than C++, so your point still stands. But it was more beginner-friendly. In my opinion, the moment you got beyond the basics (no pun intended), it was friendlier than BASIC or Visual Basic, while far more powerful. That was quite a sweet spot. Once I felt comfortable with C++, I couldn't go back to Pascal. Even with the extensions, there were some things that were too painful for me like lack of RAII, lack of Generics, short strings by default. Perhaps some of these are addressed by Free Pascal or modern versions of Delphi nowadays, but that ship has sailed. I feel like Pascal with its extensions worked great in the 1980s and 1990s, and I have very fond memories of my time using it, but it just doesn't have much to offer anymore. There are other beginner friendly languages out there that are powerful enough and have better tooling and far larger communities. And it was all about the tooling and community all along.
- jhbadger 3y ago
  However, Wirth himself realized the problems of Pascal and his later languages are basically improved versions of Pascal -- Modula, Modula-2, and Oberon. But these languages didn't even really displace Pascal itself let alone C -- but maybe if he had named them in a way that made it clear to outsiders that these were Pascal improvements they would have had more uptake.
  - pjmlp 3y ago
    Object Pascal got most of those improvements, hence why it was hard for them to be adopted, maybe if a big OS vendor had picked them instead of C++, or later Java it would have helped. At least we have some of Oberon ideas living on Go, which despite my usual rants, is preferable to plain C.
yawaramin 3y ago
Nice tribute to Wirth. I just have some feedback :-) > ...modular languages offer one implementation for each interface. Unfortunately, this is totally incorrect. Modular languages absolutely allow any interface to have multiple implementations which can be chosen amongst. This corresponds to how a Java 'interface' can have multiple implementations. In fact programming to the interface and swapping the implementation is one of the main selling points of interfaces. > Some of those constraints remained long after advances in hardware and software made the insistence on one-pass compilation seem obsolete. With compile speeds nowadays we can only wish that this insistence was obsolete. It's needed now more than ever with the slow-as-molasses compilers (apart from a notable few) of today.
- pjmlp 3y ago
  He is talking in the context of modules as in Modula-2 and Oberon, not language types, or the split interface/implementation, which goes towards your point as Modula-3 and Ada allowed various interface module/package declarations to the same implementation. Still not the same as Objective-C/Java interfaces that later on become more widely known, or Standard ML modules, CLU clusters, all of them type system based.
  - yawaramin 3y ago
    It's not clear to me that he means only Modula-2 and Oberon when he says 'modular languages', especially as just in the previous paragraph he says: '...stopped caring much for purely modular languages, including Ada as it was then'
    - pjmlp 3y ago
      Modular languages are languages that support modules. https://en.wikipedia.org/wiki/Modular_programming https://en.wikipedia.org/wiki/Modular_programming See "Languages that formally support the module concept include..."
- kragen 3y ago
  what he says is correct about languages like modula-2, oberon, ada, ocaml, c, and c++, at least within a single compilation. you can have multiple implementations of the interface described in a single .h file, but you have to choose at most one of them every time you go to compile. this is distinct from how things like java work; java doesn't have this problem c++ compilation is mostly slow not because c++ compilers use lalr parsers (they don't) but because c++ programs commonly wedge lots of the implementation into the "interface", i.e., the .h file, and use recursive textual #include non-c++ compilers are super fast
mark-r 3y ago
I can't believe I missed the news of his death. Pascal was my language of choice for many years. RIP, Niklaus.
dang 3y ago
Recent and related: Closing word at Zürich Colloquium (1968) - https://news.ycombinator.com/item?id=38883652 https://news.ycombinator.com/item?id=38883652 - Jan 2024 (28 comments) Niklaus Wirth, 1934-2024: Geek For Life - https://news.ycombinator.com/item?id=38871086 https://news.ycombinator.com/item?id=38871086 - Jan 2024 (61 comments) Niklaus Wirth has died - https://news.ycombinator.com/item?id=38858012 https://news.ycombinator.com/item?id=38858012 - Jan 2024 (403 comments)
nxobject 3y ago
Huh, the article mentioned a fact that I could have never expected: Logitech was an indirect sire of Wirth, since people from ETH had wanted to commercialize Modula-2. [1] Their first product: a Modula-2 development system bundled with a 3-button mouse. [1] https://web.archive.org/web/20210324044010/http://www.edm2.com/index.php/Logitech https://web.archive.org/web/20210324044010/http://www.edm2.c...
- Agraillo 3y ago
  Everywhere the company showed their Modula-2 development system people started making inquires about the mouse and its availability as a separate item, Logitech scrambled to put together a developers kit for DOS and started to offer the mouse for sale Brilliant. It's very important to notice early enough that the clients prefer buying not exactly what you're selling...
thadt 3y ago
Perhaps part of the issue with the "evolution of the programming language field in recent years" is that 'simplicity' is a high cost optimization. Most every 'simple' system I've been a part of building started life as an oversized beast, laboriously wrestled into a more streamlined form. Making complicated things is cheaper, easier, and lets you say 'yes' more often to smart, persuasive, people. Simple takes a lot of time, effort, and "getting to no" with people that have good reasons for the things they want to add.
- onetimeuse92304 3y ago
  Making complicated things may only be cheaper initially. I think the problem is that to learn to make simple things you first need to learn making complicated things. This is my story and pretty much the story of every person I ever talked to that learned to make simple things. Some people get it faster, some get slower and some never learn to appreciate simplicity, but everybody first had to learn to make before they learned to make simple. So now realise we were through decades of exponential growth of the number of developers and at any point in time people with experience were greatly outnumbered by people with little experience and the answer becomes easier to formulate. Simplicity isn't something that is easy to teach. The best ways to do it I found is by mentoring and working with people, but there are so many people you can meaningfully mentor on a daily basis. People with experience are so outnumbered (and also promoted up if they are any good) that it is very hard for an average apprentice programmer Joe to be able to find his master.
  - hyperthesis 3y ago
    A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. - Gall's Law
    - onetimeuse92304 3y ago
      No, that's not true. Easily disproven by example: I have many times seen smart engineers with little experience design and immediately implement an extremely complex solution to a very simple problem. Don't believe everything people say. Just because somebody called something "a law" does not mean it is true.
justanotherjoe 3y ago
I never like this platonic view of there being one 'perfect language', maybe yet invented, that stood above all others. Instead I am always more of a 'classist'(i didn't find any word for it). I believe there is one class of language, of which it's not hard to achieve, that for all intents and purposes are all equally good. A bit like the notion of 'turing completeness' except turing completeness is way too broad and measure another thing. But I'm betting that the 'best' language is already achieved, and there are quite a few of them. Which ones, that's up to debate.
teleforce 3y ago
The litmus test for simplicity of a programming language design is its compilation speed, if the language compile fast it is simple but if the language compile slow it is overly complex. Modern programming languages like Go and D have fast compilation, but C++ and Rust compile much slower. Go is a direct descendent of Wirth's languages namely Modula and Oberon, while D is not albeit some of its feature like nested function is directly taken from Pascal [1]. Interestingly both were designed by authors with engineering background, and personally I think the simplicity is not a coincident since typical engineers loath to embrace any form of complexity. [1]Nested function: https://en.wikipedia.org/wiki/Nested_function https://en.wikipedia.org/wiki/Nested_function
- pjmlp 3y ago
  Thankfully C++ modules are on the right path to improve the story on the C++ side. Using C++23 standard library, alongside modules, and cargo/vcpkg binary caches for 3rd party libs is quite fast. Rust well, until cargo does offer the option to use binary libraries, it will always lag behind in what C++ tooling is capable of. Maybe if scache becomes part of it.
  - pjmlp 3y ago
    Naturally I meant conan/vcpkg.
  - foofie 3y ago
    > Using C++23 standard library, alongside modules, and cargo/vcpkg binary caches for 3rd party libs is quite fast. I don't think your assertion makes sense. The only thing that conan/vcpkg brings to C++ is precompiled dependencies which you don't have to build yourself. You get the same result if you build those libs yourself, packaged them in a zip file somewhere, and unpacked that zip file in your project tree whenever you had to bootstrap a build environment. The problems that conan/vcpkg solve are not build times or even C++, they are tied to the way you chose to structure your project. With C++, you get a far greater speedup if you onboard a compiler cache tool like ccache and organize your project around modules that don't needlessly cause others to recompile whever the are touched.
HackerThemAll 3y ago
Being simple... And then there comes Rust in all its glory with "my string constant".to_string() awkwardness and Golang with datetime to string formmating using "2006-01-02 15:04:05.999999999 -0700 MST"... Modern languages are full of idiosyncrasies that work like putting left hand in the right pocket, and from behind.
- avgcorrection 3y ago
  > And then there comes Rust in all its glory with "my string constant".to_string() awkwardness Would you feel better if it was `"my string constant".to_owned_string()`?
- laerus 3y ago
  You are confusing "simple" with "easy". When you are trying to solve hard problems the "easy" way you are going to have bigger problems later than just awkwardness.
  - bunderbunder 3y ago
    I'm not sure I would call Rust's solution "simple" either. My sense is that fine-grained, per-object, deterministic memory management simply cannot be made simple or easy, because the very thing you're trying to do is inherently complex and difficult. I realize it doesn't provide the same level of safety guarantees that you get out of Rust, but I am very sympathetic to Zig's approach of having no implicit default allocator, so that I can instead just use something simple and easy to reason about like an arena allocator in the 90% of cases where that's good enough for my purposes.
- notTooFarGone 3y ago
  You could use the constants that everyone uses like time.RFC3339 or ISO 8601. Why it is under the hood allowed to define your own timeformat is quite obviously legacy data. At least it's human readable.
zubairq 3y ago
Makes me think of Rich Hickey and Clojure when I think of simplicity in this context! But, good article!
highfrequency 3y ago
> Like a Renaissance man, or one of those 18-th century "philosophers" who knew no discipline boundaries, Wirth straddled many subjects. It was in particular still possible (and perhaps necessary) in his generation to pay attention to both hardware and software. Wirth is most remembered for his software work but he was also a hardware builder > One of his maxims was indeed that the field remains driven by hardware advances, which make software progress possible. > One of his maxims for a successful career was that there are a few things that you don't want to do because they are boring or feel useless, but if you don't take care of them right away they will come back and take even more of your time, so you should devote 10% of that time to discharge them promptly. > Wirth seems to have decided in reaction to the enormity of Algol 68 that simplicity and small size were the cardinal virtues of a language design, leading to Pascal
jafo1989 3y ago
Niklaus Wirth could afford to be simple, he lived in simpler times where demand was much lower than today, being chased by much less investment. Change was measured in years, compute and storage options were limited. I wonder how many of his OSes / programming languages spanned multiple heterogeneous compute architectures. Don't get me wrong, love the guy...but wonder what kind of impact he would have if in his prime today...
- kragen 3y ago
  it's unclear whether this comment is describing the extreme opposite of the truth out of ignorance or for satirical purposes
- cade-117 3y ago
  Don't need to "wonder". Just use a Wirthian-inspired language and see where it takes you. For me, been coding C++ for nearly 30 years and last few months have been taking Modula-3 (M3) for a "test drive". M3 is "complete" and early on it was very obvious to me that the "C++ experiment" has gone on for too many decades. The amazing thing is that M3 was "complete" since the late 1980's, thanks to the programming-language gurus at DEC/Olivetti/etc. You can sense in the M3 literature that these/other gurus were aware of the "issues" that C++ would develop in the future. As Wirth would imply, all you need is a lightweight/simple language-core that can be used to create great libraries.
Agraillo 3y ago
The article mentioned Philippe Kahn (Borland co-founder) as the student of Wirth, never heard the fact before. The podcast [1] confirms this. Probably the Borland's decision to buy Compass Pascal might be influenced by his Kahn's early impressions. [00:07:12] ... I remember you had a choice between two programming language and on one side they taught Fortran and Fortran is the language of science, or it was the language of scientists. [00:07:40] And then there was this new class that was started by this Professor Niklaus Wirth about Pascal. And it was, I think the first or second year it was taught. There were a lot of people in the Fortran class and not that many people in the Pascal class. So I said, oh, I'll go to the Pascal class. [00:07:59] And that's how I met Professor Wirth. And that was great. That was my favorite class from that moment because he's such a, such an enlightened person and a clear thinker that it was a great, great experience for me. [1] https://ethz.ch/en/news-and-events/eth-news/news/2022/05/we-are-eth-podcast-philippe-kahn.html https://ethz.ch/en/news-and-events/eth-news/news/2022/05/we-...
- chubot 3y ago
  That's a very cool fact! Whenever I read these stories, I kinda wish I grew up ~one generation earlier in computing. It seems like the industry was smaller and more exciting Although probably Microsoft made the industry worse for a lot of people (definitely Borland) -- I think many people forget that these days
cade-117 3y ago
I'm shocked about passing of Niklaus Wirth, just found out now. Been in "bunker mode" last few months due to porting C++ code to Modula-3 (M3) code. I'm using the cm3 Modula-3 distribution at https://github.com/modula3/cm3 https://github.com/modula3/cm3 I have been thinking alot about Pascal/Modula origins of M3 (Re: Wirth) as well as the DEC/Olivetti/CriticalMass/etc. people related to crafting M3, due to ELEGANCE and ADDICTIVENESS of the Modula-3 programming language. Been coding C++ for nearly three decades and it's obvious the designers of M3 as well as Wirth et al. were "prophetic", in that they had an idea of the {bloat, complexity} problems that will afflict an ever-growing C++ spec/standard; Scott Meyers C++ experiences concerning C++'s "issues" is notable. A programming language does not have to be a "complexity beast" in order to be productive for encoding knowledge into code. Note, a large-scale codebase makes C++ "cracks" more obvious. M3 provides a good cognitive-load paradigm during design/implementation of the code; thanks to principles of, more notably, modula programming, revelations, opaque-types. M3 gets to the point in a very elegant manner and made me realise early in the porting process that the "C++ experiment" has gone on for too long. This is how good M3 is. One book on M3, i.e. "Nelson's" book, is essentially the M3 spec; a spec from the late 1980's which feature-packed the language in a concise/logical manner. No multi-decadal evolving specs/committees as in C++. No compiler that does not support a language-feature. As in Wirth's paradigm, M3 has a relatively lean/simple language-core that can be used to create useful libraries/programs. Harbison's book can help flesh out some detail due to the former book sometimes being a bit less verbose; may be due to my applied-science background where I selected the "C", not "Pascal", route when starting computer programming decades ago. The tutorial links, etc., at the github site are useful. Anyway, once doing enough C++ (even at pre-C++-11 level), M3 will be an understandable surprise. Yes, it is important for the core of a programming language to be SIMPLE as well as being PRACTICAL and COGNITIVE-LOAD-EFFICIENT. My recent experiences lead me to believe that Modula-3 achieves this well. Gees ... Wirth is gone.
lincpa 3y ago
[dead]

304 points by madmax108 3y ago

xg15 3y ago

Sometimes a picture is wirth a thousand words.

> in the sense that the limitations and exclusions of the language design were precisely what made compact implementations possible and widely successful. All of the Pascals that were widely successful extended the language in key ways. I was an initial fan of Pascal, until I discovered that a large amount of my time was spent trying to work around limitations of the language. With C, those workarounds disappeared and I was far more productive. (I know C compilers always have numerous extensions, most of them of dubious value, but still, plain C remains a far, far more useful language than the Pascal of "Pascal User Manual and Report". Which is why C buried Pascal.)

userbinator 3y ago
One could argue that C's success is largely because it was even simpler than Pascal and more generic --- a notable example is that Pascal has I/O built-in to the language, while C defined them as part of the standard library (which could even not be present.)
- WalterBright 3y ago
  From a compiler writer's perspective, C is much more complex than Wirth's Pascal. Pascal's builtin I/O was a major impediment to its usability. However, one really great feature of Wirth's Pascal is nested functions with access to outer scopes, which D wholeheartedly embraces. They really are slick. I use them heavily.
  - dist1ll 3y ago
    > one really great feature of Wirth's Pascal is nested functions with access to outer scopes, which D wholeheartedly embraces Can you give an example? What does the function access in the outer scope? Is it like an environment-capturing closure?
    - WalterBright 3y ago
      It can access the variables in an outer scope: int moon(int s) { int sum(int x) { return s + x; } return sum(3); } An extra parameter is passed to the nested function, called a "static link", which is a pointer to the stack frame of the statically enclosing function. This is in addition to the usual "dynamic link" which is a pointer to the stack frame that called the nested function. Nested functions can also be nested, and can access variables in enclosing functions by walking the static links back. The neato thing about this is it makes stack frames work exactly like members of a struct. In fact, a pointer to a nested function is analogous to (and binary interchangeable with) a pointer to a stack object.
      - loup-vaillant 3y ago
        My first (and only) serious compiler had such nested functions, though without stack frames. Instead my VM had two stacks: one for function arguments and locals, and the other for return addresses, same as Forth. I had no stack frame at all. Instead, the compiler kept track of the stack offset of every accessible local (relative to the top of stack). That way the implementation of my nested function was kind of trivial: there were no difference between true locals like `x` and locals from an outer scope like `s`, except of course for the possibility of shadowing. One reason this was not special is that internally, it was nested scopes all the way down: there was one scope per local variable, so merely declaring two variables already means dealing with nested scopes. Once that was out of the way adding nesting functions was really easy (I believe it added less than 20 lines to my compiler). Nowadays I think I would use a single stack instead, but if my language is simple enough I’ll probably skip the frame pointer and just keep track of offsets like I did this first time.
- cxr 3y ago
  > One could argue that C's success is largely because[...] Why do so many ignore the obvious? Ergonomics matters. At a time when most programmers didn't touch type (even the big stars), the economy of being able to type `int foo(int bar) { ... }` is a major productivity boost in comparison to `PROCEDURE foo(VAR bar: INTEGER); BEGIN ... END foo;`. Hell, that even bothers modern programmers. I mean, I know people whose entire reason for switching to Chrome when it came out was that the toolbars at the top of the screen were 18 pixels shorter or whatever. That's it. People are incredibly capricious. Factor in the environment—Unix has a widely acknowledged beauty/elegance in its design—and it's not hard to see why people gravitated to C, even at a time when Pascal was anointed as the official development language by Apple for a platform where people were known to be able to make money writing apps and selling them to businesses and consumers alike.
jdougan 3y ago
As I said in another forum earlier this week, "A lot of the hate centered around how it wasn’t a systems programming language, when it wasn’t supposed to be one. It’s like complaining your driving instructor’s car can’t be used to dig a trench without extensive modification." After BASIC, I learned on Pascal (Apple and IBM). It was invaluable to clarify in my mind how programming structures work, as opposed to the (fun) chaos of early BASICs. I really didn't need much more than the I/O available in standard Pascal at the time. And it hid details like endianness that I was not yet ready to handle. Were there problems? Of course. Among others, the vendors should have done a lot more to standardize extensions, the P1 parameterized array bounds should have been in the initial spec, and while the P-machines had many virtues, performance was not one of them. Far too many of the early implementations just ran the P-code in an interpreter.
- WalterBright 3y ago
  It's been well over 40 years since I wrote Wirth Pascal code, but one of the problems was one couldn't write a line without a line ending. That's not an activity confined to system programming!
  - jdougan 3y ago
    Sure. But for the output of the tiny calculator class project we did, it just didn't matter.
    - WalterBright 3y ago
      Yes, Pascal is good for that purpose.
      - 082349872349872 3y ago
        Many of the decisions for Pascal seem aimed for a teaching language as opposed to a production language. For instance, in a production language, optimisation of generated code is worth a longer compile cycle, but in a teaching language (where programs are repeatedly resubmitted until they barely run, and then are never touched again) short* compile cycles are everything and quality of generated code is an afterthought. * and cheap: I remember in the days of 30 engineers sharing a VAX that if one person was compiling at a time everything was snappy, but (especially near the end of quarters!) if ten people tried compiling at once interactive latency suffered greatly. Classroom use must've been even worse.
pjmlp 3y ago
Pascal also has had numerous extensions. No one used Pascal of "Pascal User Manual and Report" from 1976. Strangley compiler extentions are only cool when talking about C, in fact, most C developers have no idea what ISO C is actually all about.
- AnimalMuppet 3y ago
  I did, in 1986 through 88. The only extension it had was separate compilation. (This was on PDOS running on a 68000, for the morbidly curious.) And I agree with WalterBright. Unextended C was far more usable than unextended Pascal.
  - pjmlp 3y ago
    From the looks of Small-C and RatC not really that usable. During the 1980's there was already several usable Pascal alternatives, plus Modula-2 came out in 1978 exactly to fix the shortcomings of Pascal without extensions, and the largely ignored ISO Extended Pascal came in 1991, retifying many of the 1980's common extensions. Using original Pascal, was really when there was no alternative, like myself trying to fit some form of Pascal compiler into a 48 KB on top of Timex 2068 ROM, which naturally wouldn't fit. Neither did the Darthmound BASIC JIT compiler for that matter, or one of those Small-C / RatC alternatives.
    - WalterBright 3y ago
      I remember the Modula-2 crowd being rather bitter that the advent of C++ sunk M-2. One of the M-2 compiler guys ruefully said to me "I backed the wrong horse." (Zortech C++ had taken the PC market by storm then.) The success of ZTC++ is why Borland changed direction from Pascal to C++. I heard rumors that Microsoft had been internally developing its own OOP language, but abandoned it and switched to C++ also after the success of ZTC++.
      - unscaled 3y ago
        Borland did keep supporting Pascal in addition to C++ then, no? They introduced Object Pascal with Turbo Pascal 5.5 IIRC, and later kept extending that with Delphi. As far as I know, their strategy was playing both Pascal and C++ up through the bitter end with Delphi and C++ Builder. I don't know which of them, C++ or Pascal/Delphi, but Delphi was certainly popular enough at its heyday. Obviously, Object Pascal was a very far cry from the Pascal User Manual and Report, and even at its extended version it was strictly less powerful than C++, so your point still stands. But it was more beginner-friendly. In my opinion, the moment you got beyond the basics (no pun intended), it was friendlier than BASIC or Visual Basic, while far more powerful. That was quite a sweet spot. Once I felt comfortable with C++, I couldn't go back to Pascal. Even with the extensions, there were some things that were too painful for me like lack of RAII, lack of Generics, short strings by default. Perhaps some of these are addressed by Free Pascal or modern versions of Delphi nowadays, but that ship has sailed. I feel like Pascal with its extensions worked great in the 1980s and 1990s, and I have very fond memories of my time using it, but it just doesn't have much to offer anymore. There are other beginner friendly languages out there that are powerful enough and have better tooling and far larger communities. And it was all about the tooling and community all along.
jhbadger 3y ago
However, Wirth himself realized the problems of Pascal and his later languages are basically improved versions of Pascal -- Modula, Modula-2, and Oberon. But these languages didn't even really displace Pascal itself let alone C -- but maybe if he had named them in a way that made it clear to outsiders that these were Pascal improvements they would have had more uptake.
- pjmlp 3y ago
  Object Pascal got most of those improvements, hence why it was hard for them to be adopted, maybe if a big OS vendor had picked them instead of C++, or later Java it would have helped. At least we have some of Oberon ideas living on Go, which despite my usual rants, is preferable to plain C.

yawaramin 3y ago

Nice tribute to Wirth. I just have some feedback :-) > ...modular languages offer one implementation for each interface. Unfortunately, this is totally incorrect. Modular languages absolutely allow any interface to have multiple implementations which can be chosen amongst. This corresponds to how a Java 'interface' can have multiple implementations. In fact programming to the interface and swapping the implementation is one of the main selling points of interfaces. > Some of those constraints remained long after advances in hardware and software made the insistence on one-pass compilation seem obsolete. With compile speeds nowadays we can only wish that this insistence was obsolete. It's needed now more than ever with the slow-as-molasses compilers (apart from a notable few) of today.

pjmlp 3y ago
He is talking in the context of modules as in Modula-2 and Oberon, not language types, or the split interface/implementation, which goes towards your point as Modula-3 and Ada allowed various interface module/package declarations to the same implementation. Still not the same as Objective-C/Java interfaces that later on become more widely known, or Standard ML modules, CLU clusters, all of them type system based.
- yawaramin 3y ago
  It's not clear to me that he means only Modula-2 and Oberon when he says 'modular languages', especially as just in the previous paragraph he says: '...stopped caring much for purely modular languages, including Ada as it was then'
  - pjmlp 3y ago
    Modular languages are languages that support modules. https://en.wikipedia.org/wiki/Modular_programming https://en.wikipedia.org/wiki/Modular_programming See "Languages that formally support the module concept include..."
kragen 3y ago
what he says is correct about languages like modula-2, oberon, ada, ocaml, c, and c++, at least within a single compilation. you can have multiple implementations of the interface described in a single .h file, but you have to choose at most one of them every time you go to compile. this is distinct from how things like java work; java doesn't have this problem c++ compilation is mostly slow not because c++ compilers use lalr parsers (they don't) but because c++ programs commonly wedge lots of the implementation into the "interface", i.e., the .h file, and use recursive textual #include non-c++ compilers are super fast

mark-r 3y ago

I can't believe I missed the news of his death. Pascal was my language of choice for many years. RIP, Niklaus.

dang 3y ago

Recent and related: Closing word at Zürich Colloquium (1968) - https://news.ycombinator.com/item?id=38883652 https://news.ycombinator.com/item?id=38883652 - Jan 2024 (28 comments) Niklaus Wirth, 1934-2024: Geek For Life - https://news.ycombinator.com/item?id=38871086 https://news.ycombinator.com/item?id=38871086 - Jan 2024 (61 comments) Niklaus Wirth has died - https://news.ycombinator.com/item?id=38858012 https://news.ycombinator.com/item?id=38858012 - Jan 2024 (403 comments)

nxobject 3y ago

Huh, the article mentioned a fact that I could have never expected: Logitech was an indirect sire of Wirth, since people from ETH had wanted to commercialize Modula-2. [1] Their first product: a Modula-2 development system bundled with a 3-button mouse. [1] https://web.archive.org/web/20210324044010/http://www.edm2.com/index.php/Logitech https://web.archive.org/web/20210324044010/http://www.edm2.c...

Agraillo 3y ago
Everywhere the company showed their Modula-2 development system people started making inquires about the mouse and its availability as a separate item, Logitech scrambled to put together a developers kit for DOS and started to offer the mouse for sale Brilliant. It's very important to notice early enough that the clients prefer buying not exactly what you're selling...

thadt 3y ago

Perhaps part of the issue with the "evolution of the programming language field in recent years" is that 'simplicity' is a high cost optimization. Most every 'simple' system I've been a part of building started life as an oversized beast, laboriously wrestled into a more streamlined form. Making complicated things is cheaper, easier, and lets you say 'yes' more often to smart, persuasive, people. Simple takes a lot of time, effort, and "getting to no" with people that have good reasons for the things they want to add.

onetimeuse92304 3y ago
Making complicated things may only be cheaper initially. I think the problem is that to learn to make simple things you first need to learn making complicated things. This is my story and pretty much the story of every person I ever talked to that learned to make simple things. Some people get it faster, some get slower and some never learn to appreciate simplicity, but everybody first had to learn to make before they learned to make simple. So now realise we were through decades of exponential growth of the number of developers and at any point in time people with experience were greatly outnumbered by people with little experience and the answer becomes easier to formulate. Simplicity isn't something that is easy to teach. The best ways to do it I found is by mentoring and working with people, but there are so many people you can meaningfully mentor on a daily basis. People with experience are so outnumbered (and also promoted up if they are any good) that it is very hard for an average apprentice programmer Joe to be able to find his master.
- hyperthesis 3y ago
  A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. - Gall's Law
  - onetimeuse92304 3y ago
    No, that's not true. Easily disproven by example: I have many times seen smart engineers with little experience design and immediately implement an extremely complex solution to a very simple problem. Don't believe everything people say. Just because somebody called something "a law" does not mean it is true.

justanotherjoe 3y ago

I never like this platonic view of there being one 'perfect language', maybe yet invented, that stood above all others. Instead I am always more of a 'classist'(i didn't find any word for it). I believe there is one class of language, of which it's not hard to achieve, that for all intents and purposes are all equally good. A bit like the notion of 'turing completeness' except turing completeness is way too broad and measure another thing. But I'm betting that the 'best' language is already achieved, and there are quite a few of them. Which ones, that's up to debate.

teleforce 3y ago

The litmus test for simplicity of a programming language design is its compilation speed, if the language compile fast it is simple but if the language compile slow it is overly complex. Modern programming languages like Go and D have fast compilation, but C++ and Rust compile much slower. Go is a direct descendent of Wirth's languages namely Modula and Oberon, while D is not albeit some of its feature like nested function is directly taken from Pascal [1]. Interestingly both were designed by authors with engineering background, and personally I think the simplicity is not a coincident since typical engineers loath to embrace any form of complexity. [1]Nested function: https://en.wikipedia.org/wiki/Nested_function https://en.wikipedia.org/wiki/Nested_function

pjmlp 3y ago
Thankfully C++ modules are on the right path to improve the story on the C++ side. Using C++23 standard library, alongside modules, and cargo/vcpkg binary caches for 3rd party libs is quite fast. Rust well, until cargo does offer the option to use binary libraries, it will always lag behind in what C++ tooling is capable of. Maybe if scache becomes part of it.
- pjmlp 3y ago
  Naturally I meant conan/vcpkg.
- foofie 3y ago
  > Using C++23 standard library, alongside modules, and cargo/vcpkg binary caches for 3rd party libs is quite fast. I don't think your assertion makes sense. The only thing that conan/vcpkg brings to C++ is precompiled dependencies which you don't have to build yourself. You get the same result if you build those libs yourself, packaged them in a zip file somewhere, and unpacked that zip file in your project tree whenever you had to bootstrap a build environment. The problems that conan/vcpkg solve are not build times or even C++, they are tied to the way you chose to structure your project. With C++, you get a far greater speedup if you onboard a compiler cache tool like ccache and organize your project around modules that don't needlessly cause others to recompile whever the are touched.

HackerThemAll 3y ago

Being simple... And then there comes Rust in all its glory with "my string constant".to_string() awkwardness and Golang with datetime to string formmating using "2006-01-02 15:04:05.999999999 -0700 MST"... Modern languages are full of idiosyncrasies that work like putting left hand in the right pocket, and from behind.

avgcorrection 3y ago
> And then there comes Rust in all its glory with "my string constant".to_string() awkwardness Would you feel better if it was `"my string constant".to_owned_string()`?
laerus 3y ago
You are confusing "simple" with "easy". When you are trying to solve hard problems the "easy" way you are going to have bigger problems later than just awkwardness.
- bunderbunder 3y ago
  I'm not sure I would call Rust's solution "simple" either. My sense is that fine-grained, per-object, deterministic memory management simply cannot be made simple or easy, because the very thing you're trying to do is inherently complex and difficult. I realize it doesn't provide the same level of safety guarantees that you get out of Rust, but I am very sympathetic to Zig's approach of having no implicit default allocator, so that I can instead just use something simple and easy to reason about like an arena allocator in the 90% of cases where that's good enough for my purposes.
notTooFarGone 3y ago
You could use the constants that everyone uses like time.RFC3339 or ISO 8601. Why it is under the hood allowed to define your own timeformat is quite obviously legacy data. At least it's human readable.

zubairq 3y ago

Makes me think of Rich Hickey and Clojure when I think of simplicity in this context! But, good article!

highfrequency 3y ago

> Like a Renaissance man, or one of those 18-th century "philosophers" who knew no discipline boundaries, Wirth straddled many subjects. It was in particular still possible (and perhaps necessary) in his generation to pay attention to both hardware and software. Wirth is most remembered for his software work but he was also a hardware builder > One of his maxims was indeed that the field remains driven by hardware advances, which make software progress possible. > One of his maxims for a successful career was that there are a few things that you don't want to do because they are boring or feel useless, but if you don't take care of them right away they will come back and take even more of your time, so you should devote 10% of that time to discharge them promptly. > Wirth seems to have decided in reaction to the enormity of Algol 68 that simplicity and small size were the cardinal virtues of a language design, leading to Pascal

jafo1989 3y ago

Niklaus Wirth could afford to be simple, he lived in simpler times where demand was much lower than today, being chased by much less investment. Change was measured in years, compute and storage options were limited. I wonder how many of his OSes / programming languages spanned multiple heterogeneous compute architectures. Don't get me wrong, love the guy...but wonder what kind of impact he would have if in his prime today...

kragen 3y ago
it's unclear whether this comment is describing the extreme opposite of the truth out of ignorance or for satirical purposes
cade-117 3y ago
Don't need to "wonder". Just use a Wirthian-inspired language and see where it takes you. For me, been coding C++ for nearly 30 years and last few months have been taking Modula-3 (M3) for a "test drive". M3 is "complete" and early on it was very obvious to me that the "C++ experiment" has gone on for too many decades. The amazing thing is that M3 was "complete" since the late 1980's, thanks to the programming-language gurus at DEC/Olivetti/etc. You can sense in the M3 literature that these/other gurus were aware of the "issues" that C++ would develop in the future. As Wirth would imply, all you need is a lightweight/simple language-core that can be used to create great libraries.

Agraillo 3y ago

The article mentioned Philippe Kahn (Borland co-founder) as the student of Wirth, never heard the fact before. The podcast [1] confirms this. Probably the Borland's decision to buy Compass Pascal might be influenced by his Kahn's early impressions. [00:07:12] ... I remember you had a choice between two programming language and on one side they taught Fortran and Fortran is the language of science, or it was the language of scientists. [00:07:40] And then there was this new class that was started by this Professor Niklaus Wirth about Pascal. And it was, I think the first or second year it was taught. There were a lot of people in the Fortran class and not that many people in the Pascal class. So I said, oh, I'll go to the Pascal class. [00:07:59] And that's how I met Professor Wirth. And that was great. That was my favorite class from that moment because he's such a, such an enlightened person and a clear thinker that it was a great, great experience for me. [1] https://ethz.ch/en/news-and-events/eth-news/news/2022/05/we-are-eth-podcast-philippe-kahn.html https://ethz.ch/en/news-and-events/eth-news/news/2022/05/we-...

chubot 3y ago
That's a very cool fact! Whenever I read these stories, I kinda wish I grew up ~one generation earlier in computing. It seems like the industry was smaller and more exciting Although probably Microsoft made the industry worse for a lot of people (definitely Borland) -- I think many people forget that these days

cade-117 3y ago

I'm shocked about passing of Niklaus Wirth, just found out now. Been in "bunker mode" last few months due to porting C++ code to Modula-3 (M3) code. I'm using the cm3 Modula-3 distribution at https://github.com/modula3/cm3 https://github.com/modula3/cm3 I have been thinking alot about Pascal/Modula origins of M3 (Re: Wirth) as well as the DEC/Olivetti/CriticalMass/etc. people related to crafting M3, due to ELEGANCE and ADDICTIVENESS of the Modula-3 programming language. Been coding C++ for nearly three decades and it's obvious the designers of M3 as well as Wirth et al. were "prophetic", in that they had an idea of the {bloat, complexity} problems that will afflict an ever-growing C++ spec/standard; Scott Meyers C++ experiences concerning C++'s "issues" is notable. A programming language does not have to be a "complexity beast" in order to be productive for encoding knowledge into code. Note, a large-scale codebase makes C++ "cracks" more obvious. M3 provides a good cognitive-load paradigm during design/implementation of the code; thanks to principles of, more notably, modula programming, revelations, opaque-types. M3 gets to the point in a very elegant manner and made me realise early in the porting process that the "C++ experiment" has gone on for too long. This is how good M3 is. One book on M3, i.e. "Nelson's" book, is essentially the M3 spec; a spec from the late 1980's which feature-packed the language in a concise/logical manner. No multi-decadal evolving specs/committees as in C++. No compiler that does not support a language-feature. As in Wirth's paradigm, M3 has a relatively lean/simple language-core that can be used to create useful libraries/programs. Harbison's book can help flesh out some detail due to the former book sometimes being a bit less verbose; may be due to my applied-science background where I selected the "C", not "Pascal", route when starting computer programming decades ago. The tutorial links, etc., at the github site are useful. Anyway, once doing enough C++ (even at pre-C++-11 level), M3 will be an understandable surprise. Yes, it is important for the core of a programming language to be SIMPLE as well as being PRACTICAL and COGNITIVE-LOAD-EFFICIENT. My recent experiences lead me to believe that Modula-3 achieves this well. Gees ... Wirth is gone.

lincpa 3y ago

[dead]