Yeah, Modula-3 had everything that the new kids like Java/C#/Go try to sell you years before, but I think Trestle would need some modernization before it could keep up visually with Qt/Gtk/etc (assuming that you can still "sell" that, as the kids these days really like their whitespacey Electron). It's a bit like Common Lisp's CLIM in that regard.
And, of course, in a land where Bell Labs won, upper-case keywords instead of glyphs are hard to sell.
Java designers officially mentioned Modula-3 as source of inspiration, sadly they forgot value types and AOT in the process and are still catching up on that front.
C# is finally there, since .NET Native and the improvements they keep doing since C# 7. Sadly WinDev keeps ignoring what comes out of DevDiv, they worship their COM with C++ implementations.
Go, well, plenty to catch up in regards to Modula-3 features.
While upper case keywords are a bit of a bummer, like on Visual Basic and most modern SQL tooling, there are options to automatically format keywords into uppercase.
Among all modern alternatives, I would say C# 11 and Swift are the closest to Modula-3, with a rich ecosystem in the backpack.
D and Nim could also be candidates, but they still miss much of the tooling to make them competitive in current times.
Modula-3 (not designed by Wirth, but tangentially mentioned in the article) was a practical disaster. Phenomenally verbose, and with a type system implementation that could easily confuse a complex class with an int.
It also had go-like structural interfaces, if that floats your boat. Pretty much everyone I knew hated working with it.
What benefits would you see Modula-3 offering over the numerous other languages available today?
There wasn't anything particularly special about it when I last used it in the 1990s. It wasn't a bad language, but there wasn't anything particularly compelling about it or its implementations, either. There was nothing that really made it more useful than C++, or even Delphi and Java.
I think Modula-2 was also quite influential in one of the main programming languages for modern industrial PLCs, called Structured Text. One of its features are lightning fast compile times compared to C++.
Point taken, but I feel all those languages had good runs. Modula-2 might have had less commercial success but still holds some intellectual interest. I sort of got sick of the web treadmill in 2013 as it felt like "learn a new toolkit every 18 months" and am primarily interested in something with longevity in that niche.
If people wanted an object-orientated compiled language that didn't interlink with and offer a smooth transition from C, there were already alternatives (e.g. Modula).
Modula 2 is much like C in it's close-to-the-metal performance abilities.
On the downside, if you want to call it that, is a more prominent syntax (keywords instead of curlies, upper-case keywords, etc).
On the upside it lacks any unsafe operations, except for dealloc. In addition, it has actual modules in lieu of includes, hence it's blazingly fast to compile and/or recompile. It'a a pity it didn't catch on, the language lacked a company to back and promote it. AT&T promoted C, Apple promoted Objective C, Microsoft promoted VB...
Modula-2 wasn't really a contemporary of C's. By the time it was released, C had already taken over the world. Plus, it's yet another case of something that looks good but has never really been tested. While not quite Modula-2, in the early oughts I was working on a large project that was half written in C++ and half in Ada. We're talking millions of lines of code in both languages here. The Ada code looked nice but we were cursing when we had to work with it for two reasons: we had to consult thick Ada manuals to grapple with language intricacies, and compilation times were frustratingly slow. With C++ we could spend more time thinking about the algorithms as there was less "language lawyering", and we could run more tests (ironically, C++ now suffers from both of these problems). Perhaps that's why to this day I prefer smaller languages with short compilation times (I like Clojure but dislike Scala; I like Zig but dislike Rust).
My point is that when people say that one language is technically superior to another, what they really mean is that it's superior in the technical aspects that they themselves value more than the aspects where the other language is technically superior. This is all fine, except that these personal preferences aren't distributed equally. This is a little like the Betamax vs. VHS debate. Sure, Betamax had a superior picture quality that some valued, but VHS had a superior recording time, which others valued but that latter group was bigger.
As for C# -- strong disagree there. I think they're making the classic mistake of trying to solve every problem in the language and soon, resulting in a pretty haphazard collection of features, quite a few of them are anti-features, making up a pretty complicated language. For example, they have both properties and records, while in Java we figured that by adding records we'll both direct people toward a more data-oriented form of programming and at the same time make the problem of writing setters so much less annoying to the point it shouldn't be addressed by the language (while properties have the opposite effect of encouraging mutation). They've painted themselves into a very tight corner with async/await (the same with P/Invoke, which constrained their runtime's design making it harder to add user-mode threads), and I think they've made a big security mistake with interpolation -- something we're trying to avoid with a substantially different design. Also, while richer languages do have a lot of fans, all else being equal more people seem to prefer languages with fewer features. Our hypothesis is that it's better to spend a few years thinking how to avoid adding a language feature (like async/await or properties) than to spend a few months adding it.
Also, every feature you add constrains you a little in the future (and every language makes this tradeoff early when it's trying to acquire users, but once it's established you need to be more careful). That's why we try to keep the abstraction level high at the expense of a quicker and tighter fit to a particular environment. This delays some things, but we believe it keeps us more flexible to adapt to future changes. It's like having an adaptation budget that you don't want to fully spend on your current environment (I think P/Invoke and properties are such examples of overfitting that pays well in the short term and make you less adaptable in the long term). The complexity budget is another you want to conserve. Add a language feature to make every problem easier, and over time you find yourself not only constrained, but with a pretty complex language that few want to learn.
I would dearly love to see a full-blown Modula-3 revival. It's one of these old, moribund languages that I have a huge soft spot for, especially since I'm a Pythonista and large parts of Python were lifted directly from Modula-3.
I also kind of have a thing for innovative languages that never really took off. Not just M3, but I'm also deeply fascinated by Algol 68.
Oh, definitely, but just because the implementation sucks doesn't mean that the idea isn't there.
Modula-3 was also pretty slow compiling, but it also compiled interfaces so that it could refer to them. Unfortunately, the underlying objects could change during a compilation because of partial revelation, so parts of the system would have to be recompiled when the builder found those cases. I'm sure Modula-2 could have been faster in that regard, not having the opportunity for a type to be elaborated more in later compilation units.
Back in the 90s when Modula 2 was that latest thing, the selling point was that it was as efficient as C (in theory), but safer. The Wirth languages were called 'bondage and discipline' languages for the safety they offered to beginning programmers. No buffer overflows, and you could specify a metres type and be assured that someone wouldn't accidentally cast an variable of type yards to it. It also offered modular programming with implementation hiding.
Maybe Modula-3 is too distant from Mesa to make this a valid point, but if not, there's a discussion to be had about why the Mesa-influenced Modula-3 (or the arguably essentially similar Ada) didn't sweep all before it in the 90s.
Is it that the "small set of sharp tools" provided by C, and the "safe and somewhat onerous discipline" provided by Modula-3 represent two points on an evolution that's converging towards the ideal systems programming language? Or maybe the language level is the wrong level at which to be considering this, as if we were analyzing prose at the level of phonemes?
And, of course, in a land where Bell Labs won, upper-case keywords instead of glyphs are hard to sell.
reply