3 ms·
I'm currently reading Mössenböck's introduction to OOP (1992), and I'd say it's all pretty much by design. Refreshingly for that era, he doesn't recommend using
by mhd 4y ago
I'm currently reading Mössenböck's introduction to OOP (1992), and I'd say it's all pretty much by design. Refreshingly for that era, he doesn't recommend using OOP for everything, and he's aware of other language's features that C++ later embraced, like generics (Ada/Eiffel), but argues that they might not be necessary for what it aims at.
And the latter is something we don't see as much these days, where people don't like "gaps", and compiled languages are measured by what they can't do (Go being one notable exception, it seems). For the Oberon system, Oberon was enough, and anything more would probably not have been worth it. Wirth and Mössenböck didn't really aim at meteorology super computers or whatever was the HPC rage in the late 80s/early 90s.
- pjmlp 4y agoWhich makes sense in 1990's computing world, and I was a big Oberon fan. However there is a reason why it didn't stop at Oberon-2, and Component Pascal, Active Oberon, Zonnon and others followed up. Not everyone at ETHZ agreed on the minimalism, and for some low level coding it was proven that having stuff like untraced references (introduced in Active Oberon, based on Modula-2+/Modula-3 work) actually made sense. Latest revisions of Active Oberon also have some kind of generics support.