If LISP part sounds good, this article will give you more detail on what the experience was like. LISP and Smalltalk experience are unparalleled to this day. I still want a modern equivalent in mainstream, native language.
Depends on the implementation. Let me clarify: a modern, systems language whose primitives are close to the machine. C, Ada, Rust, and Nim w/out GC are examples of what I’m talking about. Far as LISP’s, PreScheme was an early attempt at a low-level LISP. It was also mathematically verified for correctness in VLISP project.
That’s a good counterpoint on C. I guess I included it since it’s the status quo which has been updated a few times. Nowhere near as modern as others, though.
It is entirely programmed in the Oberon programming language and each part of the system can be easily modified just like with TempleOS or a Lisp machine.
re homogeneous OS. Exactly! I was thinking it should be first or early on reading it. Then, I thought maybe author just assumed everyone heard about it. I focused on LISP/Smalltalk. It definitely should’ve been mentioned, though, since it competed with the C family of languages for systems programming, was safe, fast compiles, and whole school ran on it at one point.
re just like LISP machine. No, see my article. There’s barely any comparison except the simplicity and fast iterations of the base language. Ok, let’s say you had an error in your app which was due to your OS. You could load it up in the IDE seeing the error plus the current state of the app. If it was OS, you could load its internals. Then, you could hot-fix the running system with changes propagated throughout the OS.
Far as I know, Oberon was miles away from ever doing that. It’s that kind of thing that made me do counterpoints on Wirth where simplicity, esp for compiler, shouldn’t be main focus. I’d rather have the complexity of implementing a LISP machine if it meant my job as a developer on average project was that much more productive. Likewise, complex compilers like LLVM make code super-fast. I’d like to have both fast-to-compile and fastest-when-running as options. Wirth only wanted former.
So, it was homogeneous, easy to program, and easy to compile. It wasn’t near the LISP experience, though. That’s the gap I want folks perfecting imperative languages to close. One of them anyway.
Haha. Yeah, well, some universities were willing to invest in good hardware vs cheapest crap they can find. Too bad they were rare and/or the prices didn’t come down. Now days, you can put a LISP interpreter on a FPGA. There’s also a x86 kernel for Common LISP in development. I haven’t looked into it deeply, though.
Now that you make me think about it, I do remember to have seen an FPGA based machine for Oberon-2, for sale somewhere (can’t find the link anymore, sorry). Never tried one, though… :-(
Consequently, this also makes Unix philosophy rule 5, “Store data in flat text files”, redundant. Store data as it should be intended to be stored. Don’t go out of your way to mangle it so it is “human readable”, these are computers! Some (actually I’d say most) data is not meant to be expressed as text.
That doesn’t make the Unix philosophy redundant, it just means the author disagree with it. Some would say ‘misunderstands it’. The point is not that data is most naturally expressed as text but that data is most easily manipulated as text.
It’s most easily manipulated by bit-twiddling machines as binary. Text is a form of binary on those machines. There’s many forms of text, too. The easiest format is likely whatever allows parsing by fastest instructions in small amount of L1 cache with fewest calls to RAM. That may or may not be text for a given application.
What I said. Machines process binary with specific operators. The easiest things for machines to work with will be binary in ways using those operators. You said “data is most easily manipulated as text.” That’s not true unless the text-oriented algorithms run most efficiently on the machine. On developer side, I/O libraries abstract it all away anyway.
If LISP part sounds good, this article will give you more detail on what the experience was like. LISP and Smalltalk experience are unparalleled to this day. I still want a modern equivalent in mainstream, native language.
Lisp is a native language!
Depends on the implementation. Let me clarify: a modern, systems language whose primitives are close to the machine. C, Ada, Rust, and Nim w/out GC are examples of what I’m talking about. Far as LISP’s, PreScheme was an early attempt at a low-level LISP. It was also mathematically verified for correctness in VLISP project.
I really don’t know what you mean by “modern” since you also included C in valid examples, but Common Lisp is pretty close to the machine.
That’s a good counterpoint on C. I guess I included it since it’s the status quo which has been updated a few times. Nowhere near as modern as others, though.
Oberon operating system is another homogeneous OS from Niklaus Wirth.
It is entirely programmed in the Oberon programming language and each part of the system can be easily modified just like with TempleOS or a Lisp machine.
re homogeneous OS. Exactly! I was thinking it should be first or early on reading it. Then, I thought maybe author just assumed everyone heard about it. I focused on LISP/Smalltalk. It definitely should’ve been mentioned, though, since it competed with the C family of languages for systems programming, was safe, fast compiles, and whole school ran on it at one point.
re just like LISP machine. No, see my article. There’s barely any comparison except the simplicity and fast iterations of the base language. Ok, let’s say you had an error in your app which was due to your OS. You could load it up in the IDE seeing the error plus the current state of the app. If it was OS, you could load its internals. Then, you could hot-fix the running system with changes propagated throughout the OS.
Far as I know, Oberon was miles away from ever doing that. It’s that kind of thing that made me do counterpoints on Wirth where simplicity, esp for compiler, shouldn’t be main focus. I’d rather have the complexity of implementing a LISP machine if it meant my job as a developer on average project was that much more productive. Likewise, complex compilers like LLVM make code super-fast. I’d like to have both fast-to-compile and fastest-when-running as options. Wirth only wanted former.
So, it was homogeneous, easy to program, and easy to compile. It wasn’t near the LISP experience, though. That’s the gap I want folks perfecting imperative languages to close. One of them anyway.
Well, you are right… but such comparison is a bit unfair.
LISP hackers were lovely cheaters in this regard.
It’s easy to live edit your kernel if you have soldered an interpreter to use as a processor before! :-D
Haha. Yeah, well, some universities were willing to invest in good hardware vs cheapest crap they can find. Too bad they were rare and/or the prices didn’t come down. Now days, you can put a LISP interpreter on a FPGA. There’s also a x86 kernel for Common LISP in development. I haven’t looked into it deeply, though.
Now that you make me think about it, I do remember to have seen an FPGA based machine for Oberon-2, for sale somewhere (can’t find the link anymore, sorry). Never tried one, though… :-(
In 2015, however, Wirth wrote about a low cost one.
It was called OberonStation. Site is down now but article has description and pics.
That doesn’t make the Unix philosophy redundant, it just means the author disagree with it. Some would say ‘misunderstands it’. The point is not that data is most naturally expressed as text but that data is most easily manipulated as text.
It’s most easily manipulated by bit-twiddling machines as binary. Text is a form of binary on those machines. There’s many forms of text, too. The easiest format is likely whatever allows parsing by fastest instructions in small amount of L1 cache with fewest calls to RAM. That may or may not be text for a given application.
What on earth are you talking about?
What I said. Machines process binary with specific operators. The easiest things for machines to work with will be binary in ways using those operators. You said “data is most easily manipulated as text.” That’s not true unless the text-oriented algorithms run most efficiently on the machine. On developer side, I/O libraries abstract it all away anyway.