Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Project Oberon

projectoberon.com

Post reply on HN
Print view View original

41–50 of 90 posts

Re: Project Oberon

#41

Post by JoachimS »

vezzy-fnord wrote: post #2

Wow, this is excellent. The Oberon and Bluebottle OS materials have always been quite scattered, so someone putting them in a central index is quite convenient. For those unaware, Oberon's main qualities are the fact that it's a full operating system written in a garbage collected Pascal-like language (actually made by the same person who initially wrote Pascal) which uses said language's module system to provide reu…

The weird TempleOS has similar features: http://www.codersnotes.com/notes/a-constructive-look-at-temp...

Re: Project Oberon

#42

Post by kylebrown »

dang wrote: post #26

Project Oberon is a design for a complete computer system. Its simplicity and clarity enables a single person to know and implement the entire system, while still providing enough power to make it useful and usable in a production environment. Yes! We need so much more of this. If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. http://www.cs.virginia.edu/~cs655/rea…

Speaking of smalltalk, was project Oberon inspired by Alan Kay's STEPS project to implement a full OS + apps in under 20k LoC?

http://www.vpri.org/pdf/tr2008004_steps08.pdf

Re: Project Oberon

#43

Post by sanbor »

stream_fusion wrote: post #29
nabla9 wrote: post #11

Oberon had so many good ideas. It's still worth studying. The problem in the 90's: provide executable content across the net for browsers. Java was supposed to provide the portable universal binary code you could load and execute everywhere, except that it did not have the necessary features and was too complicated. Then came Javascript but it was broken mess for long time and needs binary format. There was Juice bac…

The problem with Java binaries on the client, was that the Java applet didn't have direct access to the DOM bindings. Instead, the applet rendered it's own GUI via the plugin, and the look and behavior was inconsistent with the rest of the browser experience. A similar story with activex and flash. It's a mystery why it has taken so long to get to the point where we can target the browser with a statically-checked hi…

Another problem with Java applets was that they were slow as hell for that time.

Re: Project Oberon

#44

Post by nickpsecurity »

vezzy-fnord wrote: post #2

Wow, this is excellent. The Oberon and Bluebottle OS materials have always been quite scattered, so someone putting them in a central index is quite convenient. For those unaware, Oberon's main qualities are the fact that it's a full operating system written in a garbage collected Pascal-like language (actually made by the same person who initially wrote Pascal) which uses said language's module system to provide reu…

Good summary. I'll add that Wirth's focus on simplicity makes it very easy to port to new hardware, too. Basically a compiler backend and some low-level stuff on bottom. Usually 1-2 students at ETH would do it over several months for each new architecture.

Re: Project Oberon

#45

Post by rattray »

nickpsecurity wrote: post #44
vezzy-fnord wrote: post #2

Wow, this is excellent. The Oberon and Bluebottle OS materials have always been quite scattered, so someone putting them in a central index is quite convenient. For those unaware, Oberon's main qualities are the fact that it's a full operating system written in a garbage collected Pascal-like language (actually made by the same person who initially wrote Pascal) which uses said language's module system to provide reu…

Good summary. I'll add that Wirth's focus on simplicity makes it very easy to port to new hardware, too. Basically a compiler backend and some low-level stuff on bottom. Usually 1-2 students at ETH would do it over several months for each new architecture.

> Google summary

Was this an autocorrect-typo of "good summary", or am I missing something?

Re: Project Oberon

#46

Post by rattray »

coldtea wrote: post #20
atomatica wrote: post #8

Earlier quoted context omitted.

Yes, thanks for the concise summary. The only thing I didn't understand is the part about garbage collection. What does garbage collection mean and what is the benefit in this implementation?

Hmmm, if you don't know what garbage collection is (and I don't mean this as sneer) how are you sure that you understood everything else said? In the sense that garbage collection is a pretty basic CS term, and the summary contained lots of CS terms and implied knowledge to understand it (modules, interfaces, persistence, etc).

Actually, as a self-taught developer who started with Python and never had to learn about memory management, "garbage collection" was a concept I only became familiar with after a few years of reading gradually more & more material, usually from HN. The other stuff in the summary above would have either made sense or been "guessable" to 3-years-ago-me.

Re: Project Oberon

#47

Post by nickpsecurity »

The work started when Wirth saw the same Xerox setup that Apple did. Wirth couldn't buy one so he just built his own lol. The first system Wirth and Jurg Gutknecht designed was Lilith [1]. They improved Pascal to make modular software in the form of Modula-2. They made a P-code-like assembler language called M-code to make compilation easier and raise assembler abstraction slightly. They then wrote most of the system in Modula-2. They had in about 2 years a computer, OS, compiler, and some apps. ETH used these day-to-day and they later morphed into Oberon system.

The brilliance of Wirth was keeping things simple. I think he overdid it but it served him well in many ways. He also kept things consistent where possible. Just having a simple language, compiler, libraries, and consistent + simple bytecode target would be better than what I've dealt with coding. Each iteration, he tries to improve the language and platform with lessons he learned from the first. He also ensures the lowest common denominator is easy to port, compile efficiently, and produce efficient code for.

A lot of inspiration. He's recently put Oberon on a custom, simple processor running on an FPGA. The latest incarnation of the system is A2 Bluebottle [2] with downloads here [3].

[1] http://www.cfbsoftware.com/modula2/Lilith.pdf

[2] http://www.sage.com.ua/en.shtml?e1l0

[3] http://www.oberon.ethz.ch/downloads/index

Re: Project Oberon

#48

Post by nickpsecurity »

rattray wrote: post #45
nickpsecurity wrote: post #44

Earlier quoted context omitted.

Good summary. I'll add that Wirth's focus on simplicity makes it very easy to port to new hardware, too. Basically a compiler backend and some low-level stuff on bottom. Usually 1-2 students at ETH would do it over several months for each new architecture.

> Google summary Was this an autocorrect-typo of "good summary", or am I missing something?

Good catch! I've edited it to correct it.

Re: Project Oberon

#49

Post by nickpsecurity »

vezzy-fnord wrote: post #9
atomatica wrote: post #8

Earlier quoted context omitted.

Yes, thanks for the concise summary. The only thing I didn't understand is the part about garbage collection. What does garbage collection mean and what is the benefit in this implementation?

Programming language with automatic memory management. Look up "garbage collection" for all the details in the world. The reason I brought it up is because it's a common trope that you can't do low-level programming with GC, and systems like Oberon are direct evidence to the contrary.

Exactly. I see the question on Stack Overflow all the time and just keep dropping a whole list of counterexamples. Too many myths in IT that hold mainstream back.

Re: Project Oberon

#50

Post by nickpsecurity »

nabla9 wrote: post #11

Oberon had so many good ideas. It's still worth studying. The problem in the 90's: provide executable content across the net for browsers. Java was supposed to provide the portable universal binary code you could load and execute everywhere, except that it did not have the necessary features and was too complicated. Then came Javascript but it was broken mess for long time and needs binary format. There was Juice bac…

It was a great project. Still faster than Javascript if run through an optimizing compiler. Combine that with today's best security schemes for browsers and you have a lot of performance for a better level of safety. Not going to happen, though. Not enough overhead & buzzword compliance to make it into a web stack. ;)
Post reply on HN