[vezzy-fnord]

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 reusable/chainable interfaces throughout the whole OS, support for orthogonal persistence and most notably, its highly unconventional user interface that bridges the power of the CLI and the GUI together in this vaguely hypertext-like workspace where you can dynamically live program the UI itself through on-screen text that can serve as an entry point or continuation to perform all sorts of computations, things you'd normally write hacky scripts for. Closest analogue is Xerox's Cedar.

You should consider trying it and stealing a few ideas from it for the greater good.

[dang]

> on-screen text that can serve as an entry point or continuation to perform all sorts of computations, things you'd normally write hacky scripts for.

The Acme editor famously works this way. So, in a rudimentary way, does the Emacs scratch buffer. It's a weird amalgam of text editor and REPL: you evaluate snippets of text and get the output in-place, and then edit the text to get what you want next. This live-text-as-code way of working is not how I'm used to interacting with a programming system and always slightly rewires my brain. But even in that simple form, you can grasp in it the beginnings of a whole computational paradigm, all the way up to UI. (Computational models don't usually imply a UI—this is an exception, as are spreadsheets.) Oberon must be the most systematic realization of this. I'd like to try it.

[vezzy-fnord]

Which is unsurprising, because Rob Pike was openly influenced by Oberon in the design of both Acme and the original Plan 9 windowing system 8½ and its current successor rio.

Oberon exploits it further, though. Plan 9 does use chording, programmable text and plumbing but only insofar as it complements the synthetic file system interface, whereas Oberon is more thoroughly object-oriented and can have the text serve as a pointer to various OS subsystems, creating a sort of graphical continuation-passing style, as I alluded.

[aggyger]

The acme editor was new to me so thanks for that. The comment about spreadsheets reminded me of an interview on the Thoughtbot Podcast with Chris Granger about a new IDE being developed called Eve. [podcast link](http://giantrobots.fm/111) If I understand correctly, the idea is that its like excel, but you use it to build domain editors, but it revolves heavily around constraint solvers? I don't know, but the podcast episode is awesome. Bottom line is that I'm giddy to use it [link to the announcement post](http://www.chris-granger.com/2014/10/01/beyond-light-table/)

[skybrian]

Perhaps something like an ipython notebook would be the "modern" way to do it?

[antimagic]

Or getting more modern, Swift playgrounds in the latest versions of XCode have a similar kind of feel to them.

[e12e]

> highly unconventional user interface that bridges the power of the CLI and the GUI together in this vaguely hypertext-like workspace where you can dynamically live program the UI itself through on-screen text that can serve as an entry point or continuation to perform all sorts of computations, things you'd normally write hacky scripts for. Closest analogue is Xerox's Cedar.

Sounds a lot like Smalltalk's print-it/do-it? I suppose the idea orginated with Oberon?

[pjmlp]

Wirth worked with Cedar at Xerox and wanted a similar experience at ETHZ.

[JoachimS]

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

[magicmu]

Thanks for this summary, I've been struggling for the last few minutes to try and figure out what the hell Oberon was. That sounds awesome!!

[atomatica]

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?

[vezzy-fnord]

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.

[nickpsecurity]

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.

[coldtea]

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).

[rattray]

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.

[ghshephard]

Garbage collection was never really anything I recall being discussed in my Cmpt Science curriculum, back in 1990-1993, though there was lots of interesting theory about memory allocation/deallocation/defragmentation. It wasn't until I ran into Java around 2000 or so that people started talking about Garbage Collection.

I'm not saying that it didn't exist, it was just less of a priority 25 years ago than 15 years ago.

[todd8]

Everyone has different experiences and interests in college, but I recall Garbage Collection as an important subject decades before 2000. I studied CS in the 1970s (and 1980s) and garbage collection was already an important subject. It was a part of the ACM recommended CS curiculum as far back as 1968. Google Scholar reveals thousands of results for "garbage collection algorithm" before 1990. The subject was studied by great computer scientists (Lamport, Dijkstra, and Liskov are all Turing award winners) and the results were fun and interesting:

1989

  AW Appel: "Simple generational garbage collection and fast allocation"

1988

  JF Bartlett: "Compacting garbage collection with ambiguous roots"

  J Crammond: "A garbage collection algorithm for shared memory parallel
  processors"

1987

  AW Appel: "Garbage collection can be faster than stack allocation"

  DI Bevan: "Distributed garbage collection using reference counting"

1986

  B Liskov, R Ladin: "Highly available distributed services and fault-tolerant
  distributed garbage collection"

1985

  J Hughes: "A distributed garbage collection algorithm"

1983

  H Lieberman, C Hewitt: "A real-time garbage collector based on the lifetimes
  of objects"

1982

  RJM Hughes: "A semi‐incremental garbage collection algorithm"

1981

  J Cohen: "Garbage collection of linked data structures"

1977

  HC Baker Jr, C Hewitt: "The incremental garbage collection of processes"

1976

  Douglas W. Clark: "An efficient list-moving algorithm using constant workspace"

  PL Wadler: "Analysis of an algorithm for real time garbage collection"

  

1975

  Guy L. Steele, Jr.:"Multiprocessing compactifying garbage collection", CACM

  Edsger W. Dijkstra, Leslie Lamport, et al.: "On-the-fly garbage collection:
  an exercise in cooperation"
  

1974

  Gary Lindstrom: "Copying list structures using bounded workspace"

1973

  Edward M. Reingold: "A nonrecursive list moving algorithm"

1972

  H. D. Baecker: "Garbage collection for virtual memory computer systems"
  
  Ben Wegbreit: "A space-efficient list structure tracing algorithm"

1969

  Robert R. Fenichel, Jerome C. Yochelson.: "A LISP garbage-collector for
  virtual-memory computer systems"
  
  Joseph Weizenbaum: "Recovery of reentrant list structures in SLIP"

1967

  H. Schorr, W. M. Waite: "An efficient machine-independent procedure for
  garbage collection in various list structures"

  Peter J. Denning: "The working set model for program behavior"

1963

  Daniel J. Edwards: "Secondary Storage in LISP"

The Communications of the ACM, during this period, was the most read CS Journal. Articles appearing there were intended to be of interest to the widest population of computer scientists and 19 of them were on garbage collection.

LISP, APL, LOGO, ML, Prolog, CLU, Scheme, Cedar, Smalltalk, Icon, SML, Mathematica, J, Haskell, Python, Dylan, Self, Lua and Javascript are all important, garbage collected programming languages that came before the late 1990's.

[pjmlp]

Well reference counting is also GC in CS speak and back then most BASIC systems made use of it.

Also by the time Java was known, some of us already knew about Lisp, Smalltalk, Modula-3, Eiffel, Prolog, ML....

[kragen]

What school did you go to?

[sklogic]

Weird. How could you miss Lisp and Smalltalk in the early 90s?

[kjs3]

Says a lot about your program. It was a topic of huge importance when I was studying CS (1985-1989ish).

[brandonmenc]

> actually made by the same person who initially wrote Pascal

Niklaus Wirth, for those interested.

[escherplex]

A reminder of how curious it is that PARC had all of Kay's, Smith's and Wirth's handiwork under their belt, all the rudiments of today's PC with mouse-controlled icon WYSIWYG GUIs back in the late 1970s, and never had the imagination to go anywhere viable with it (but give it away as dramatized in 'Pirates of Silicon Valley'). Same could be said of PalmPilot and the smart phone.

[pjmlp]

I do Xerox PARC archeology, always looking for documentation from those days.

This was triggered by having been a Smalltalk and Oberon user on their glory days.

It made me realise how much the IT world lost by having UNIX clones going mainstream instead of these systems. Specially the culture that still insist in using their computers as if they had a PDP-11.

[osahal]

Sounds fantastic, but I'm sure it's not. If you made billions on a product such as did Xerox you'd be keen to fully investigate a technology that threatens to supplant your bread and butter product, fear will drive you to do this. Once the product has been developed you will look at it and say "Product X has a return of y, while there are zero customers for this newfangled product", this is more than enough for the board to reject the new idea, many of them think the new technology is just a passing fad anyway.

[david927]

I wouldn't call it lack of imagination, and it was all quite viable. Senior management simply punted on listening to anyone.

[applecore]

Is there a screencast available of this “chainable” interface? I haven't seen anything quite like it since The Mother of All Demos in 1968.

[vezzy-fnord]

There's not much in the way at all of video demonstrations for it, but I did find this: https://www.youtube.com/watch?v=UTIJaKO0iqU

It might be of help.

[nickpsecurity]

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.

[rattray]

> Google summary

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

[nickpsecurity]

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

[avodonosov]

The language: is it Oberon or Component Pascal (which was a descendant of Oberon)?

[user543823]

It is specifically Oberon-07[0], a 2007 revision of the original Oberon from 1986, which is still being worked on by Niklaus Wirth with updates as recently as this year.

Component Pascal is a superset of Oberon-2, itself an extension of the original Oberon that tacked on limited OOP support and a handful of other tricks. Component Pascal was not a Wirth-designed set of extensions, however Blackbox Component Builder is quite the nice piece of kit in its own right.

Unfortunately the availability of modern implementations for the Wirthian languages leaves something to be desired. The only implementations that cover both 64-bit platforms and any semblance of cross-platform support is the Vishap Oberon Compiler[1], Gardens Point Component Pascal[2], GNU Modula-2[3] and m2c[4].

There's also an Oberon-07 to JavaScript implementation[5].

At this point, the very small Wirthian languages community has been mostly focused on Oberon-07. It's worth noting there are a few Modula-2 fans about still poking at things, such as the Modula-2 R10[6] effort.

[0]: http://oberon07.com/

[1]: http://oberon.vishap.am/ (Oberon-2 compiler, limited Oberon-07 support)

[2]: http://gpcp.codeplex.com/ (Component Pascal for .NET)

[3]: http://www.nongnu.org/gm2/ (Modula-2 GCC front-end)

[4]: http://nongnu.org/m2c/ (Modula-2 to C compiler)

[5]: http://oberspace.dyndns.org/oberonjs.html

[6]: http://bitbucket.org/trijezdci/m2r10

[rednab]

> Unfortunately the availability of modern implementations for the Wirthian languages leaves something to be desired.

There is the Delphi-compatible, GPL-licenced Free Pascal¹). GNU Pascal²) is also still around but might or might not meet your definition of 'modern implementation'.

¹) http://www.freepascal.org

²) http://www.gnu-pascal.de