3 ms·
What I like about Oberon's module system is that there is no distinction between a library and an app or command. In Oberon an 'executable' has 1 or more comma
by eterps 7y ago
What I like about Oberon's module system is that there is no distinction between a library and an app or command.
In Oberon an 'executable' has 1 or more commands, somewhat similar to how git has more commands like pull, push & commit.
But everything is reusable you don't need a libgit at some point if you need support for it in another application. Neither do you need to invoke a command in a process and capture its output.
In Oberon git and libgit would be the same thing. Everything you execute as a command is directly reusable as native functional calls from other apps.
- zozbot234 7y agoOne can do this quite easily in Windows as well, via RUNDLL32. Not sure if Linux has a direct equivalent, however.
- eterps 7y agoThat's still just going one way (doing a library call in this case). In Oberon there is no distinction between a .DLL and an .EXE so to speak. A compiled module is (or can be) both.
- pjmlp 7y agoNot as Oberon. In Oberon not only is every module an application, the exported procedures are available as commands on the REPL and callable via mouse actions as well. However in modern Windows you try to achieve a similar experience via what PowerShell allows for (.NET, COM and DLL entry points) and OLE Automation. Still is isn't as easy and painless as the whole Oberon OS allowed to.
- p_l 7y agoInterestingly, the same applied AFAIK to Multics - generally, as an end user, you had one process, and everything you ran in it was loadable, run-time linkable modules.