3 ms·

> While Unix is clearly tied to C at an API level, the actual ABI is entirely based on machine code, and can be accessed through any language that can produce a

by eterps 7y ago

> While Unix is clearly tied to C at an API level, the actual ABI is entirely based on machine code, and can be accessed through any language that can produce a binary. I see your point, but the Oberon system does have an ABI, it's not necessarily coupled to the Oberon language but it is coupled to the linker of the system. I have created binaries for Oberon in a rudimentary assembler, it's not hard to have them work together with the native libraries (modules). In fact it's less convoluted than ELF for example.

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 ago
  One can do this quite easily in Windows as well, via RUNDLL32. Not sure if Linux has a direct equivalent, however.
  - eterps 7y ago
    That'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 ago
    Not 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 ago
  Interestingly, 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.
scroot 7y ago
Oberon is a gift to the computing world. It is one of the few examples of a top-to-bottom design of a full computing system (The Smalltalk Blue Book is also like this, sans the hardware). I think the world is ready, or almost ready, for a comeback in this kind of design. Given that we have so many open, compatible standards (JSON, Office Documents/XML, hell even TCP/IP, etc, etc), the "traditional" problems of esoteric systems and their incompatibilities with each other, like we had back in the late 80s and 90s, seem to melt away. We are at a point where we can and should be experimenting with completely new systems from the ground up. Otherwise we will never get anything new, and everything will just be some iteration of Unix for the rest of time -- like medieval scholastics endlessly debating Aristotle and not discovering anything truly novel.

by eterps 7y ago

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 ago
One can do this quite easily in Windows as well, via RUNDLL32. Not sure if Linux has a direct equivalent, however.
- eterps 7y ago
  That'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 ago
  Not 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 ago
Interestingly, 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.

scroot 7y ago

Oberon is a gift to the computing world. It is one of the few examples of a top-to-bottom design of a full computing system (The Smalltalk Blue Book is also like this, sans the hardware). I think the world is ready, or almost ready, for a comeback in this kind of design. Given that we have so many open, compatible standards (JSON, Office Documents/XML, hell even TCP/IP, etc, etc), the "traditional" problems of esoteric systems and their incompatibilities with each other, like we had back in the late 80s and 90s, seem to melt away. We are at a point where we can and should be experimenting with completely new systems from the ground up. Otherwise we will never get anything new, and everything will just be some iteration of Unix for the rest of time -- like medieval scholastics endlessly debating Aristotle and not discovering anything truly novel.