The wikipedia article says that, when designing Google's language, all three of them had to agree on every single feature so no "extraneous garbage" crept in. The C developers dream language was basically an updated Oberon. That's them dropping the QED on C supporters for me. :)
Funny thing is, Oberon family was used to build both apps and whole operating systems. Whereas, Thompson et al's version is merely an application language lambasted for comparisons with system languages. I don't know if they built Oberon up thanks to tooling and such or if they've dropped back down a notch from Component Pascal since it's less versatile. Just can't decide.
Note: Imagine where we'd be if they figured that shit out early on like the others did. We'd be arguing why an ALGOL68 language wasn't good enough vs ML, Eiffel DbC, LISP's macros, and so on. The eventual compromise would've been better than C, Go, or ALGOL68. Maybe.
I still use Acme, a plan9 text editor that was based on Oberon and it is the best software ever. Just the notion that "all text is a potential action" blows all other usability notions out of the water.
Want a drop down menu ? : make a file in the current directory with the name of the menu, put the commands in it you want in the menu. Done. And that can go as deep as you like.
Those commands can include snippets of shell code that act on the current document e.g. | sed s/[a-z][A-Z]/g
Highlight some text, middle click that command and the command runs on the selected text.
Add to that a file system for the text editor :
date > /n/acme/new
execute that and you get a new document containing the date
When using it, it feels limitless. You build a command set that matches your current project. There's a pattern matcher too: the plumber, so you can click somefile.c:74 and the editor opens that file at that line. so "grep -n someregex ???.c" and you get a list of clickable "links" to those files.
When you browse the plan9 source code you might see the unusual
void
main(args)
we follow that convention so one can 'grep -n ^functionname ???.c' and you get a source code browser
I'll stop there, and I've only scratched the surface
??? means * - you can't type * . c without spaces in HN !
That's pretty wild. I might have to try it some time. The Oberon interface was certainly interesting. More interesting was that hyperlinked documents became the default way of doing apps that replaced native ones in many places. Something Oberon did before that they rejected. ;)
Nonetheless, I'm hesitant to put a execution system in a text editor. One of my favorite aspects of them is that they load, edit, and/or render data. The data stays data. Means throwing one in a sandbox was always safest route to inspect files I wasn't sure about. An Oberon-style text editor that links in other apps functionality might be a nightmare to try to protect. It's why I rejected that style of GUI in the past.
Composability, it's what makes Unix Unix. Doug McIlroy and his pipes, that's what makes it powerful in th ehands of a skilled operator. Your system grows with you
Possibly a nightmare for someone else to reason about, so I accept that aspect. But every long time plan9 user I know (and that's about 20 I know by name to their face + more I meet at conferences) finds going back to plain old unix a retrograde step. It's like going back to a 16" b&w tv.
Funny thing is, Oberon family was used to build both apps and whole operating systems. Whereas, Thompson et al's version is merely an application language lambasted for comparisons with system languages. I don't know if they built Oberon up thanks to tooling and such or if they've dropped back down a notch from Component Pascal since it's less versatile. Just can't decide.
Note: Imagine where we'd be if they figured that shit out early on like the others did. We'd be arguing why an ALGOL68 language wasn't good enough vs ML, Eiffel DbC, LISP's macros, and so on. The eventual compromise would've been better than C, Go, or ALGOL68. Maybe.