[HN Gopher] Oberon (2009)
___________________________________________________________________
Oberon (2009)
Author : lproven
Score : 210 points
Date : 2022-08-26 09:55 UTC (13 hours ago)
(HTM) web link (ignorethecode.net)
(TXT) w3m dump (ignorethecode.net)
| kissiel wrote:
| What the hell is this site's encoding? However I try to decode
| it, I get misdecoded 'u'.
| progval wrote:
| Originally UTF-8, then decoded as Latin-1, then re-encoded to
| UTF-8. You can recompute the exact bytes in the page with this
| Python code: >>>
| 'Zurich'.encode('utf-8').decode('latin1').encode('utf-8')
| b'Z\xc3\x83\xc2\xbcrich'
| Someone wrote:
| FTA: "When ETH ZA1/4rich started its own computer science
| program in the 60s, buying computers from the US turned out to
| be a bit of an issue. They were expensive and often unsuitable
| for European use (what with our strange umlauts and stubborn
| insistence on speaking languages different from English)"
|
| I guess they started buying computers from the US :-)
| perihelions wrote:
| I think it's a double-encoding error. Text was encoded into
| utf-8, whose bytes got misinterpreted as codepoints, and
| encoded again. u in utf-8 is (c3 bc), and U+00c3, U+00bc are A,
| 1/4 respectively. $ echo 'Zurich' | iconv -f
| latin1 -t utf-8 ZA1/4rich
| carapace wrote:
| You can try Oberon OS in the browser, e.g.:
| http://schierlm.github.io/OberonEmulator/emu-wasm.html?image...
|
| Via Javascript emulator:
| http://schierlm.github.io/OberonEmulator/
| ekidd wrote:
| Not only have I heard of Oberon, I've written code for it!
|
| The Oberon programming language is a nicer-than-average
| descendant of Pascal and Modula-2. The compiler was reasonably
| fast even in the 90s.
|
| The UI was strange enough to feel really interesting. As the
| article mentions, you could type a command anywhere and click it.
| And the older version I used had tiling windows, although this
| seems to have changed.
|
| But one especially neat feature is that the system was based
| around a rich-text format that you could extend! I wrote a little
| clock widget that I could instantiate anywhere, inside any rich
| text, and it would give me a live time readout.
|
| In practice, Oberon already felt like a toy system when I used
| it, because it was missing tons of useful software. But as toy
| systems went, it was rich and original and well-worth a couple of
| weekends of exploring and coding.
|
| If you enjoy the idea of operating systems that explored a
| different path, this is one of the more interesting ones. If
| you're fascinated by systems like the Lisp Machine, or SmallTalk,
| or OLPC, where the entire system is meant to be easily
| understandable and hackable, take a look.
| slim wrote:
| Also the whole OS was a 1.44' bootable floppy disk which booted
| in 10 seconds on a 486
| sleepydog wrote:
| I think you meant it fit on 3.5" floppy drive (1.44 MB).
| Fitting on a 1.44 foot floppy disk would be much less
| impressive :P
| mod wrote:
| Bigger is better!
|
| I'd love to see that disk. Maybe you'd wheel it out on one
| of those TV carts all my teachers had.
| Bluecobra wrote:
| I think they did make 14" WORM optical disks at some
| point:
|
| https://i.redd.it/dgvtw0tmgxk81.png
| aliqot wrote:
| 8 inch floppies for the rest of us Phillistines
|
| https://upload.wikimedia.org/wikipedia/commons/a/aa/Flopp
| y_d...
| karmakaze wrote:
| I remember those 8" (WANG) floppies.
| slim wrote:
| absolutely :)
| suprjami wrote:
| Is there an image of this floppy floating around anywhere?
| goatsneez wrote:
| FYI, a flavor of Oberon will also fly to space soon it turns
| out...
|
| https://arxiv.org/abs/1709.03404v1
| i_don_t_know wrote:
| Interestingly, one of the authors (Felix Winkelmann) created
| Chicken Scheme and their Oberon compiler appears to be
| written in it.
| Rochus wrote:
| That's an interesting paper, thanks for the link. Though the
| resulting language is barely Oberon anymore, since even type
| extension is removed, not only dynamic memory management (and
| with it the GC). It seems to have less features than Oberon-0
| described in Wirth's compiler book.
| 082349872349872 wrote:
| > _...all memory accesses are indirect ... module-data is
| position independent and may be moved in case memory should
| fail due to radiation damage._
|
| I once used a debugger that shipped with a rather snarky
| easter egg command: "find my bug". One of its more useful
| suggestions was "Maybe a cosmic ray error? Use smaller
| chips!".
| PcChip wrote:
| Wouldn't smaller chips make the problem worse?
| 082349872349872 wrote:
| I think it jocularly meant "use something with fewer
| gates and a smaller cross section", not "use a smaller
| feature size". Or I could easily have misremembered: this
| was all last century.
| AnimalMuppet wrote:
| > Or I could easily have misremembered: this was all last
| century.
|
| Don't understate the difficulty of remembering. This was
| all last _millennium_.
| aliqot wrote:
| Important not to also understate that some of us spent
| more time in the former than the current.
| tanakian wrote:
| True! Smaller and closer the units, more probability that
| the particle would hit something useful.
| [deleted]
| mhd wrote:
| The timeline does skip a bit too fast over Medos-2[1], the
| predecessor of the Lilith's operating system, using Modula-2.
| That plugs the gap between the Alto-Oberon timeline, with Oberon
| basically being both a continuation of that and a simplification
| of Smalltalk and the whole software environment in total
| (surprise: Wirth is not a fan of it [2][3]).
|
| [1]: https://www.research-
| collection.ethz.ch/handle/20.500.11850/...
|
| [2]: https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf
| (PDF)
|
| [3]: https://en.wikipedia.org/wiki/Wirth%27s_law
|
| [Edit: corrected reference to Ceres, which was the Lillith
| _successor_ ]
| romwell wrote:
| Never heard of?
|
| Come on! It's the most interesting thing yet to happen in desktop
| computing.
| rbanffy wrote:
| I made the same complaint when Apple discontinued the Newton.
| It was their most interesting computer. In the long run, an
| evolutionary dead-end (Unix won), but still interesting.
| lproven wrote:
| I personally tend to agree with you, and yet, as a researcher
| and writer about OSes and so on, I never even heard of it until
| a few years ago. It is, sadly, quite obscure.
| scroot wrote:
| The Oberon book (by Wirth, updated in 2013) is excellent in that
| it describes the entire Oberon system, from the processor on up
| in a single volume.
|
| https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf
| whartung wrote:
| For whatever reason, that PDF is incomplete. The ToC goes
| through Chapter 16, but the text includes only up to Chapter 9.
|
| Part 2 is:
| https://people.inf.ethz.ch/wirth/ProjectOberon/PO.Applicatio...
|
| Part 3 is:
| https://people.inf.ethz.ch/wirth/ProjectOberon/PO.Computer.p...
|
| A fun point about the 3rd part. If you've ever been flummoxed
| by the basics of floating point math, part 3 discusses the
| fundamentals in 2 pages with a big fonts. One of the most
| succinct discussions I've seen on FP.
|
| I can't seem to find the original 1992 edition in PDF. It feels
| like a lot of information (not just source code) is culled from
| the later versions (2005, 2013) of this book.
| zelphirkalt wrote:
| Too bad the link in the article is offline:
| http://bluebottle.ethz.ch/ and
| http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads takes forever to
| load somehow.
| lproven wrote:
| "Bluebottle" is now called A2 and it's on Github now:
|
| https://github.com/btreut/a2
|
| I've done quite a bit of editing on the Wikipedia article,
| including bringing stuff across from Russian Wikipedia (via
| Google Translate).
|
| https://en.wikipedia.org/wiki/A2_(operating_system)
|
| The most active user and development community for A2 seems to
| be in Russia. There's a Telegram group too but I don't speak
| the language so I can't follow very much of it at all.
| indeyets wrote:
| This link seems to be active too
| http://cas.inf.ethz.ch/projects/a2/
| mwexler wrote:
| This was going to be the next Pascal... back when Pascal was a
| thing. I do remember chatting with some Borland folks about how
| they would be supporting it (Turbo Oberon?), but they weren't
| really very enthusiastic about it. Of course, that was early 90s
| and they were still shipping floppies, so...
|
| (edit: didn't remember the year, so left it as a range)
| mhd wrote:
| You're missing one step here, as the "next Pascal" was Oberon's
| predecessor Modula-2. For which there were some 8/16-bit
| compilers around, including a _Turbo Modula-2_.
|
| Didn't seem to work out back than for a few reasons, one
| probably simply being that "Pascal" had a certain name
| recognition. Also, OO was coming around which Modula-2 didn't
| have, and by the time Oberon was invented, _Object Pacal_ was
| already a thing.
| gtirloni wrote:
| I remember being impressed by Modula-3 back then. I wish it
| wasn't so difficult to compile the compiler.
| mhd wrote:
| Ah, Modula-3, one of my perennial favorites. Definitely a
| different continuation of Modula-2 than Wirth's own Oberon.
| Agree on the tooling issues. If it would've "sold" better,
| so many languages of the last two decades could've been
| avoided.
| lboasso wrote:
| If you want to try out only the Oberon language, you might be
| interested in oberonc [0] an oberon-07 self-hosting compiler for
| the JVM. There are other several Oberon implementations for
| different platforms listed here[1]
|
| [0] https://github.com/lboasso/oberonc
|
| [1] http://oberon07.com/compilers.xhtml
| Rochus wrote:
| [1] is not complete; this one is missing:
| https://github.com/rochus-keller/Oberon/ ;-)
| _fz_ wrote:
| Project Oberon 2013 emulator and RISC compiler in Go:
| https://github.com/fzipp/oberon
| https://github.com/fzipp/oberon-compiler
| Rochus wrote:
| Looks like quite a diligence; I wrote an Oberon to C++
| transpiler some years ago; here is a C++ version of the
| Oberon system: https://github.com/rochus-
| keller/OberonSystem/tree/master/CP.... My Oberon+ compiler
| generates CIL bytecode and C99 source code. Here is a
| version of the Oberon system which runs on .NET (cross-
| platform, without emulator): http://software.rochus-
| keller.ch/OberonSystem_SDL_CLI_Assemb.... And here is the
| corresponding C99 version: http://software.rochus-
| keller.ch/OberonSystem_ObxIDE_Cgen_20.... Both are directly
| generated from the sources in https://github.com/rochus-
| keller/OberonSystem/tree/FFI, using SDL2 for platform
| independence.
| Koshkin wrote:
| I remember trying out an Oberon-07 compiler some years back. The
| speed at which it worked was impressive: it was able to build
| itself and the standard library modules in a small fraction of a
| second.
| JulianMorrison wrote:
| Pascal family languages parse quickly because they won't let
| you use anything before it's defined.
| lproven wrote:
| True, AIUI, but there's a bit more to it than that.
|
| This paper is very readable and talks about Niklaus Wirth's
| _ruthless_ approach to compiler optimization. https://citesee
| rx.ist.psu.edu/viewdoc/download?doi=10.1.1.90...
| jdvh wrote:
| That's not why Pascal compiles quickly. Resolving undefined
| symbols isn't difficult or slow, it just means that you have
| to keep track of what's resolved and what's unresolved and
| that takes up memory, which was very precious back in the old
| days of Pascal. Pascal is designed for very fast single-pass
| compilation, but symbol resolution is only a small part of
| it.
| [deleted]
| fm77 wrote:
| Well, not really. Consider the following:
| type ItemPtr = ^Item; SomeOtherType
| = record a,b,c:integer; end;
| Item = record Data:string;
| Next:ItemPtr; end;
|
| The first time the parser hits "Item", its not defined.
| pklausler wrote:
| Pascal require(s|d) a "forward" declaration on such a type,
| no?
| lloydatkinson wrote:
| Probably a controversial opinion, but I absolutely wish this
| was more common. It's a thing in F# as well. With JS/TS
| projects I always ensure the ESLint rule for only using
| what's been declared before is enabled.
|
| I don't want to scroll up and down a file constantly when
| referring to previous things that might reference something
| at the bottom of the file, which then references something
| near the top, which then references something in the middle,
| which then references something at the bottom again... I
| despise working in that manner.
| quickthrower2 wrote:
| I find it a non issue when you can use go to definition and
| go to previous position shortcuts.
| muth02446 wrote:
| I am trying to do something similar here: http://cwerg.org
|
| Starting with a very efficient compiler backend.
| samsquire wrote:
| I am interested in alternative GUI tech. If you find this
| interesting you might find my declarative frontend idea
| interesting called additive-guis
|
| https://GitHub.com/samsquire/additive-guis
|
| The idea is you define how the GUI should appear by describing
| it. The GUI changes in real time based on what you describe.
|
| And I also designed a GUI primitive I called GUI thunking,
| inspired by Haskell. The idea is you can chain together behaviour
| on a GUI by interacting with the future directly.
|
| https://GitHub.com/samsquire/gui-thunks
| aliqot wrote:
| You might be interested in Acme and Rio from the Plan9 system!
| It had some interesting UI paradigms like 3 button clicking and
| highlight to instantiate.
|
| Additive guis seems like a really cool approach that I wish we
| had more of these days given that everything seems to be web-
| based anyway. Most interfaces sadly want to be a mishmash of
| MacOS and a catch-all mobile operating system.
|
| https://en.wikipedia.org/wiki/Rio_(windowing_system)
|
| https://9p.io/wiki/plan9/Using_acme/index.html
| tanakian wrote:
| >The idea is you define how the GUI should appear by describing
| it. The GUI changes in real time based on what you describe.
|
| That's how Oberon Gadgets were working. Later the same idea was
| used in Blackbox Component Builder.
| nightpool wrote:
| What does "HLL" stand for here? Wikipedia offers "High-level
| language", but I can't quite get that to fit in this context.
| alexisread wrote:
| It does mean high level language, and in this context it's
| trying to illustrate that Oberon is used to write the OS and
| drivers, despite having GC, a repl, objects and other high-
| level constructs (compare with C for example).
|
| The general assumption is that if you don't have exact control
| over memory and threading, you can't write an OS.
| lproven wrote:
| Yes, high-level language. (I submitted this post & wrote the
| title.)
|
| Oberon is _both_ the programming language _and_ the operating
| system, including the IDE and the compiler and the UI.
|
| "Oberon" is the name of the whole thing, and it's about 30K LOC
| in total. The entire thing is smaller than a typical Linux
| console-mode text editor.
|
| The original OS -- that is the entire thing, from kernel to
| tiling UI to compiler -- was about 12K LOC:
| http://www.edm2.com/0608/oberon.html
|
| The compiler is about 4K LOC:
| https://dercuano.github.io/notes/oberon.html
|
| In Linux terms it is hard to even comprehend how tiny this OS
| is.
| nightpool wrote:
| Kind of a strange thing to mention in the title given that it
| doesn't show up anywhere in the article at all (which is
| entirely about the UI/UX)
| lproven wrote:
| The article is the best introduction and overview I know.
| There are many more comprehensive sites.
|
| The revival is worth a look:
|
| http://www.projectoberon.com/
|
| This academic paper is highly readable and interesting:
|
| https://news.ycombinator.com/item?id=15704806
|
| Wikibooks has excellent docs in depth:
|
| https://en.wikibooks.org/wiki/Oberon
|
| But I often cite the Ignore the Code post when someone
| doesn't know what Oberon is. I used it in a comment
| elsewhere on HN, and thought "why not submit it?" and here
| we are. The word "language" wouldn't fit in the title,
| AFAICR.
| [deleted]
| butterisgood wrote:
| This seems to talk about the variant called Active Oberon. It's
| an interesting and expressive language that's fairly active.
|
| It can run native or hosted. It can build binaries for your host
| or for Oberon itself. The Fox compiler is pretty neat!
| samoit wrote:
| This operating system looks pretty much like Plan9. I do not know
| if there is any relation between those two.
| Jtsummers wrote:
| The main thing it shares with Plan 9 is in the Acme editor
| which was inspired by Oberon.
| https://news.ycombinator.com/item?id=32606415
| samoit wrote:
| Thanks
| tanakian wrote:
| Inferno got more influence from Oberon system, because in
| Inferno userspace programs were working in the same address
| space.
|
| But in Oberon everything worked in the same address space.
| dang wrote:
| Related:
|
| _Oberon OS Walkthrough (2009)_ -
| https://news.ycombinator.com/item?id=25786470 - Jan 2021 (59
| comments)
|
| _Oberon (2009)_ - https://news.ycombinator.com/item?id=6498878 -
| Oct 2013 (31 comments)
|
| _Oberon, a delightfully insane system_ -
| https://news.ycombinator.com/item?id=593323 - May 2009 (30
| comments)
|
| (Lots of previous Oberon threads generally so maybe I won't list
| them)
| KingOfCoders wrote:
| Had to learn at university :-)
| jon_adler wrote:
| Same. Professor John Gough was heavily involved in Modula-2 and
| Oberon compilers at the time. I really liked using it.
| haspok wrote:
| The zooming reminds me of Prezi, except that Prezi is in 3D...
| (maybe Oberon is where they got their original idea from?).
|
| As interesting as it sounds and looks, I cannot imagine
| constantly zooming in and out (or panning) just to switch
| windows. Maybe I am so indoctrinated with the standard Windows
| task switcher concept that I don't want it to work in any other
| way. I was also completely lost when I tried to create a Prezi
| presentation instead of Powerpoint.
|
| On the other hand it is great to see something different in the
| UI world. I remember only one such other concept that didn't make
| it into mainstream: the UI where you just move the mouse, but
| don't need to click...
| galaxyLogic wrote:
| Instead of zooming I think a better approach is Windows-within-
| Windows. Or is that the same thing? You don't need to "zoom" so
| much as "enter" into a sub-desktop. Which is different than
| multiple desktops side-by-side.
|
| Smalltalk had/has this feature. You create a new "project-
| window". You can then "enter" it and within it you can open any
| number of windows including project-windows.
|
| This works really well with programming where you are
| performing a task which requires a set of windows to be open, a
| class-browser, method-browser, change-list-window, debugger
| etc. As you are programming you soon discover you will need to
| do something else "first", perhaps fix a bug. You open a new
| project-window and "enter into it" to do that. Your current
| context of whatever you were doing remains as is in the parent
| window. Perhaps you leave an open debugger there halted at a
| given stack-frame, so you can continue that debugging later.
| Maybe even tomorrow.
|
| When your bug is fixed you close its sub-project-window and
| come back up to what you were doing before.
|
| If you can't fix the bug immediately you can leave its project
| window in place but exit into the parent-project and do
| something else there while keeping the bug-fix project open,
| and visible as a window-icon in its parent project-window.
|
| The same approach could be adopted by the whole OS, and in a
| sense Smalltalk is an OS. So I'm waiting for MS or Linux or Mac
| come up with something similar. Not "multiple desktops" but
| "nested desktops". Or is there something like that already
| (outside of Smalltalk)?
| 4bpp wrote:
| Up until the mid-2000s, a lot of complex GUI applications
| (such as Visual Studio 6) in the Windows world used a
| paradigm somewhat ambiguously named MDI (cf.
| https://documentation.help/Win32/MDI%20Frames.htm) which is
| what you describe sounds like. Unfortunately, UI design/HCI
| fashions turned against it hard and it went all but extinct;
| last I checked, few GUI toolkits even support it. Gtk was on
| the vanguard of the anti-MDI _Bildersturm_ since its
| inception, and Qt 's implementation
| (https://doc.qt.io/qt-6/qmdiarea.html) already suffered from
| bit rot when I checked it out some 10 years ago.
| s-video wrote:
| I installed the Oberon OS (A2) emulator and showed it to my
| friend. We burst out laughing at that program that makes a
| skeleton run across the screen. If you keep executing it, it just
| spawns more skeletons and we had a skeleton parade.
| smm11 wrote:
| Linux installs that didn't understand your video card had the
| zoomable desktop nailed down in the late-90s.
| pacod wrote:
| When I started to study computer sciences in Germany in 1991, we
| used Oberon on X11 terminals during the the initial "Praktische
| Informatik I" lecture as our first programming language. Oberon
| being new, the professor said he wanted to make sure that
| everyone starts under the same conditions and with no pre-
| knowledge. So we wrote our linked lists, hash tables, trees,
| sorting algorithms etc. in Oberon.
|
| That time almost all students had a track-record coding on Apple,
| Commodore or Atari homecomputers and/or had worked with Turbo-
| Pascal and -C. Because the Oberon system was not very stable nor
| user friendly, the Oberon environment was met only with little
| support by the students. For example I remember that the compiler
| crashed reproducible on certain inputs. There also was no
| debugger and the editor did not meet expectations.
|
| After finishing the lecture, most students (including) me, never
| touched Oberon again. But hey, let's re-visit it after 30 years
| again and see how it feels today.
| dfawcus wrote:
| As I described it to some folks recently, Go can be simply
| characterised as a slightly stripped version of the Oberon-2 (or
| Component Pascal) language, recast in a C like syntax, and with a
| number of small additions.
|
| Removed from Oberon-2: Sets, Type Extension (classful OO scheme)
|
| Added by Go: Maps, Slices, Strings, Interfaces, Channels,
| Coroutines.
|
| Such that I suggested it is well worth reading the Oberon-2
| language report.
|
| As to the coroutines, possibly Oberon-2 had them in its standard
| module library (as Modulo-2 did)?
| Rochus wrote:
| > Go can be simply characterised as a slightly stripped version
| of the Oberon-2
|
| Well, not really; there are not much similarities between
| Oberon and Go besides the receiver syntax of Oberon-2 bound
| procedures (which was invented by Mossenbock btw) and the fact
| that both are garbage collected. In your list "removed from
| Oberon" you should add type inclusion (Go doesn't even have
| implicit coercion); there is an intersection of keywords and
| also := appears in Go, but the semantics are rather different;
| coroutines were defined as an option in the Oakwood guidelines,
| but by different people than the language authors; I never met
| an Oberon compiler which implements them.
| dfawcus wrote:
| Yeah - I skipped the type inclusion, as I just viewed it as a
| misfeature, assuming we're talking about the implicit casts
| between different number types.
|
| As to ':=' in Go, yeah - a new thing over Oberon-2. Since
| assignment in Go uses C style '=' whereas Oberon uses Pascal
| style ':=', I certainly was not confusing them.
|
| The characterisation came about because of an implicit
| complaint (from C programmers) about a choice of Go for a
| project. Now never having used Oberon-2, but having read the
| report, I used the comparison to a stripped version it as a
| way of showing how simple the language actually was.
| Something like 25 pages being sufficient to describe it.
|
| The things which struck me were: O2 MODULE
| becomes Go package (and similar syntax use) O2 NEW
| retained as Go new, but &Foo{} generally preferred O2
| export of symbol via '\*' tag becomes Go export via capital
| letter. O2 Open arrays replaced by Go slices or
| strings. O2 WITH because Go 'type switch' O2
| 'type guard' becomes Go 'type assertion' O2 VAR
| parameters to PROCEDURES become Go pointer parameters to
| funcs
|
| But in the end it is very much a subjective thing, so unless
| using the non classful parts of Oberon-2 reveals significant
| differences, I'd have to stick with my evaluation.
| Rochus wrote:
| > Something like 25 pages being sufficient to describe it.
|
| Wirth attached importance to the fact that there are only
| 16 pages; on closer inspection, however, one realizes that
| not everything has been specified and the omission of
| redundant descriptions easily leads to ambiguity in the
| given writing style.
|
| > in the end it is very much a subjective thing
|
| The differences and little similarities, as far as
| specified, are objectively ascertainable. But of course
| there are far more important things. From my point of view
| Oberon (including Oberon-2 and especially Oberon-07) is too
| minimalistic for non-academic projects anyway. That's why I
| threw my hat into the ring with Oberon+ (http://www.oberon-
| lang.ch ); its specification is still small with about 50
| pages.
| tanakian wrote:
| coroutines module comes with Oberon S3 system. also Ulm's
| Oberon compiler has coroutines module.
| Rochus wrote:
| Thanks. I don't know the Ulm compiler, and I unfortunately
| don't have System 3 (can you please provide a link with the
| source code and/or a working Linux binary?), but I have the
| source code of V2 and V4 (both ETH and Linz versions, from
| 1992 to Linz 1.7) where there are no coroutines.
| mseepgood wrote:
| > Added by Go: Maps, Slices, Strings, Interfaces, Channels,
| Coroutines.
|
| Also added by Go: Type parameters (generics)
| dfawcus wrote:
| The characterisation was against Go 1.15 as that is what is
| current in the version of Debian we're using (11?).
|
| So other than noting that Go 1.18 adds Generics but they can
| be ignored due to us targeting 1.15, they weren't mentioned.
|
| As I recall the another thing we get in 1.18 (as a side
| effect of the Generics constraints mechanism) is a slight
| improvement in static checking for certain constructions of
| type switch.
| groos wrote:
| Oberon was a mostly successful experiment in minimalism. Once
| when I was surprised by a compile error that I didn't think was
| correct, it didn't take me too long to pinpoint the line in the
| Oberon compiler source (written by Wirth) which was causing it
| and understand why it was the way it was. You cannot do this with
| any 'modern' system today.
| btbuildem wrote:
| Interesting to learn about this! It's not as drastically
| different as expected from the initial write-up.
|
| The zoom-to-switch-context reminds me of Figma (a design tool) --
| personally I like the metaphor of managing hierarchy with scale
| while mapping spatial relationships to functional ones.
|
| The idea of mixing "data" and "code" is intriguing. I might have
| to play with an install locally!
| ducktective wrote:
| I think tilling WM workflows are more practical than the UI
| design the article is describing:
|
| >Everything is a Command Line
|
| Tilling WMs naturally favors TUI apps and opening up a quick
| terminal in which you input text to do your task.
|
| >To launch applications or execute commands, you first type them
| somewhere and then middle-click them
|
| keybinding meta+d: dmenu-run
|
| >Everything is Zoomable
|
| Tilling WMs with workspaces (or tags) are more efficient than
| context switching by trying to find the desired window via
| zooming in and out.
| zokier wrote:
| > Tilling WMs naturally favors TUI apps
|
| I don't see how that is the case at all
| rbanffy wrote:
| I think that it could be because text stream based apps (such
| as a TTY and the utilities that make no assumptions about
| screen geometry) are friendlier than, say, a web browser
| rendering a page that assumes its canvas is 1920 pixels wide.
|
| OTOH, you can make a TUI that (rightfully) thinks the
| terminal window is always 80x25 (because God made the VT-100
| that way for a reason) and it'll be very hostile to any
| tiling WM.
| DaiPlusPlus wrote:
| > Tiling WMs naturally favors TUI apps
|
| More like: "Tiling window managers only work well with
| resizable TUI apps" - there's still far too many text-mode
| programs that assume fixed-size console buffer dimensions
| (think: software still using ancient versions of ncurses) -
| also assuming that your chosen terminal emulator is capable of
| dynamically resizing (and re-flowing) normal stdout text.
| ducktective wrote:
| The most widely used GUIs (web apps) are already resize-
| friendly (like Bootstrap or flex box).
| DaiPlusPlus wrote:
| Those aren't TUIs unless they somehow work in Lynx.
| mhd wrote:
| I don't know what definition of TUI we're using, but if we're
| talking about ncurses style whole-terminal-window GUI,
| there's no inherent advantage. Responsiveness being limited
| by character width actually sets harder limits for "TUI"s.
|
| It _does_ favor the kind of text-centered UI done by Oberon-1
| and imitated by Plan 9 's ACME, where there's little to no
| use of x-y addressing and text just flows.
| loloquwowndueo wrote:
| The text-based UI reminds me of the Acme text editor from Plan 9
| (it's now also available for other OS so easy to try) :
|
| https://en.m.wikipedia.org/wiki/Acme_(text_editor)
| pdubroy wrote:
| Acme was inspired by Oberon, and Oberon was inspired by a
| system called Cedar[1] which was created at Xerox PARC.
|
| From "Acme, A User Interface for Programmers"[2] by Rob Pike:
|
| _> Cedar was, however, the major inspiration for Oberon
| [Wirt89], a system of similar scope but much smaller scale.
| Through careful selection of Cedar's ideas, Oberon shows that
| its lessons can be applied to a small, coherent system that can
| run efficiently on modest hardware. In fact, Oberon probably
| errs too far towards simplicity: a single-process system with
| weak networking, it seems an architectural throwback._
|
| _> Acme is a new program, a combined window system, editor,
| and shell, that applies some of the ideas distilled by Oberon.
| Where Oberon uses objects and modules within a programming
| language (also called Oberon), Acme uses files and commands
| within an existing operating system (Plan 9). Unlike Oberon,
| Acme has does not yet have support for graphical output, just
| text. At least for now, the work on Acme has concentrated on
| producing the smoothest user interface possible for a
| programmer at work._
|
| [1]:
| http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-83-1...
|
| [2]:
| https://www.usenix.org/legacy/publications/library/proceedin...
| 082349872349872 wrote:
| Niklaus Wirth spent a sabbatical at PARC[0] in 1976, so the
| inspiration was direct (or at least via Mesa).
|
| [0] in fact, he's said he built the FPGA Oberon[1] because
| his favourite mouse[2] was a departure gift from PARC, but of
| course, he can't buy any system today that would allow him to
| keep using it, so he built one. Now that's a yak shave.
|
| [1] https://news.ycombinator.com/item?id=32606760
|
| [2] I've seen a not-still-in-use wooden mouse from the
| Englebart days, but I believe Bucky's is plastic.
| mhd wrote:
| > Oberon is very much in active use at ETH Zurich. We used it as
| one of our main operating systems.
|
| The article being from 2009, this must've been an interesting
| period for the students, as back then the introductory
| programming course was using Eiffel, taught by Bertrand Meyer
| himself.
| jeffreygoesto wrote:
| I remember a cooperation with some ETH people (Sjur Vestli and
| his master brain Roberto?) trying to use realtime oberon to
| enter the midsize league of robocup end of the 90s. Never
| happened to participate which was a pity.
|
| Ah. Found some traces:
| https://www.ifr.mavt.ethz.ch/research/xoberon/
| ThePadawan wrote:
| My 0.02CHF: I studied at ETHZ from 2008 to 2015, and I've heard
| about Oberon once or twice back then, and read about it at
| least twice that much on HN.
|
| Never used it, never knew anyone who used it, never knew anyone
| who worked on it (though I believe the chair had slots for
| theses available at the time).
| bluelu wrote:
| I graduated 2007 at the ETHZ.
|
| When I started studying, some student pcs were even running
| Oberon (no login was required). Only some IT students used
| them as it was too complicated for students from other
| departments. They were then later replaced with linux/windows
| machines.
|
| If my memory serves me right, when you bought a laptop
| through the university neptun program, you had oberon
| preinstalled too (or at least a dvd to install it) was
| provided.
|
| As for Bertrand Meyer, I also visited his programming class.
| I still remember that he really focused on invariants, and
| you had to write each code line basically twice.
| kitsune_ wrote:
| I just had a flashback, we had to do a weird exercise with
| hats and long strings between students in Meyer's class
| when he talked about inheritance.
| Shacklz wrote:
| > that he really focused on invariants
|
| Oh the horror those classes were. Meyer is a great guy, and
| in hindsight I appreciate his ideas quite a bit. But the
| idea to take Eiffel for an introductory course, the
| questionable exercises (being encouraged/forced to write
| the code twice, once as invariant and once for the actual
| execution) plus the terrible Eiffel-IDE made those classes
| very easy to loathe.
| ThePadawan wrote:
| I like to look back on my college years and ask myself
| "well, what did I actually learn".
|
| And looking back, "I learned to deal with being
| completely overwhelmed with shitty tools, questioning if
| the opposite party has any clue what they're talking
| about, then had to work out how to pass that class" seems
| like one of the most useful career skills to pick up in
| your first year.
|
| Who cares about the programming language.
| flwidmer wrote:
| Mandatory reference: https://vole.wtf/coder-serial-killer-
| quiz/ I'm sure everyone who was in his classes played this
| game :D
| flwidmer wrote:
| I was there from 2006 to 2012. The OS course (I think that's
| third or fourth semester) was being taught with Active
| Oberon. Must have been in 2007 or 2008, so might have changed
| right after. Eiffel, Oberon, Event-B are just the most
| notable examples of things that we were being taught that
| have never become mainstream.
| cestith wrote:
| When I started uni the program was switching from Pascal
| for existing CS majors to Ada for new majors.
| pjmlp wrote:
| Yet those are the kind of things universities are great,
| one get to learn about technologies that changes one's
| point of view (ideally), something that self taught or
| professional schools hardly achieve.
| ekidd wrote:
| I think that my ideal CS education would include 3
| things:
|
| 1. "We're going to ask you to build real software, with
| real tools, in a group. Even if it's only for one
| course."
|
| 2. "We're going to ask you to do some theory and write
| some proofs."
|
| 3. "We're going to show you some wild stuff that looks
| like it belongs on an alternate timeline."
|
| (3) might be something like Oberon, or Racket, or some
| eccentric faculty project. Or even just teaching all your
| CS majors Haskell, if you don't have any genuinely
| eccentric faculty projects to inflict on students.
|
| Innovation is often driven by people who are aware of
| what might have been.
| mhd wrote:
| I think the choice of _first_ language really says a lot
| about the whole program. More so today than yesteryear,
| where there was a larger contigent of people with prior
| exposure to programming.
|
| Do you start more abstract, and if so with functional,
| imperative or OO underpinnings? Do you intend to switch
| languages rather soon or later?
|
| The good thing about Oberon, language set aside, is that
| you could get started without a lot of adminstrative
| debris. No 80% of the screen covered in an IDE, not even
| a big ol' "public static void main" that you're told to
| gloss over.
|
| I can see good arguments for sticking to one language
| throughout many courses, too. Sadly that often means C++.
| pjmlp wrote:
| Well, that is how CS is mostly taught in European
| universities, across their software engineering degrees.
|
| For those that want CS theory only, there is applied
| mathematics into computation majors.
| throwaway17_17 wrote:
| I think had I been a student with those options I
| wouldn't have ended up a lawyer by profession. The
| American university's CS, in general, is not that
| appealing (with a few exceptions obviously).
| ThePadawan wrote:
| > Or even just teaching all your CS majors Haskell, if
| you don't have any genuinely eccentric faculty projects
| to inflict on students.
|
| We got taught Eiffel Freshman year, C and Haskell
| Sophomore year, and after that, whenever a course used
| another language (Java, C#, C++), the prof just said
| "you'll pick it up".
|
| (That's leaving out the usual-for-academia-but-still-
| weird stuff like MATLAB and Verilog)
| huerlisi1 wrote:
| Did start there in 1999. We had some Oberon exposure, but not
| that much. There were some workstations upstears in the
| computer room that did run the OS. Those were almost never
| occupied... So we simply used them to connect to some Solaris
| workstations using X forwarding:-)
| Shacklz wrote:
| You probably had some classes with Gutknecht at some point,
| who apparently contributed significantly to Oberon.
|
| That being said, I'm in the same boat as you. I have
| definitely heard more about Oberon here on HN than at ETHZ.
| pjmlp wrote:
| I surely have used it, during 1996 - 2000.
|
| Thanks to Oberon I learned what is possible to achieve with GC
| enabled systems programming languages, it was this experience to
| lead me to play archeology on our library, Usenet, gopher, FTP,..
| and discover what the world of programming languages outside Bell
| Labs actually like.
|
| Young pupil fell astray from UNIX church never to look into it
| again with the same wonder.
| nivethan wrote:
| As someone with wide eyed wonder at Bell Labs what
| languages/OSes would you recommend to get as far away from the
| unix world?
| pjmlp wrote:
| Plenty, http://progtools.org/article_new.php?name=safe_system
| s§i...
|
| Or you can start with Burroughs, VAX/VMS, Mesa/Cedar, Lisp
| Machines, Smalltalk, IBM i, z/OS.
| ElevenLathe wrote:
| Oberon is also a great beer from Bell's in Kalamazoo, MI.
|
| https://bellsbeer.com/beers/oberon-ale/
| Rochus wrote:
| cheers
| mwcampbell wrote:
| > Oberon is very much in active use at ETH Zurich. We used it as
| one of our main operating systems.
|
| I wonder if any blind students, or other disabled people who need
| accessibility tools, had to confront the general lack of
| accessibility in simple, niche GUI systems such as this one. I
| suppose someone could have been given the assignment to extend
| Oberon with a screen reader or other accessibility tool, ideally
| without having to implement their own speech synthesizer first.
| samatman wrote:
| It seems (and this surprises me not at all) that this was
| addressed in 1998 in Linz, Austria:
| https://www.dinf.ne.jp/doc/english/Us_Eu/conf/csun_99/sessio...
| mwcampbell wrote:
| Very cool, and forgive me for not doing more research myself.
| Also, I should have thought of using a Braille display
| instead of a speech synthesizer, since for that, all they
| would have had to do is send commands to a device connected
| to a serial port. Of course, that would be more complicated
| now with USB, never mind Bluetooth.
| gostsamo wrote:
| Check the prices of braille displays though.
| samatman wrote:
| ETH Zurich can afford them.
| unnouinceput wrote:
| You know, serial to usb convertors (and vice-versa) do
| exists, and are like $5 only.
| [deleted]
| jrm4 wrote:
| Dangit. This is the sort of thing that's equal parts frustrating
| and exciting, in that I've had a lot of these ideas independently
| and this is the first time I'm discovering that someone has
| implemented them. Especially this infinite canvas idea, which I'm
| very confident would work wonders for me (and many other people)
| mostly owing to the power of "spatial memory," which I feel like
| is a wildly underused human feature. (e.g. memory palaces)
| joshspankit wrote:
| An important thing to be aware of is that spatial memory is not
| universal, and thee is quite a bit of variation among those who
| have the ability to use it successfully.
|
| I don't say this to discourage. Quite the opposite: I say this
| to say if someone doesn't understand the benefits of your ideas
| don't take it as a general "this will not work" but instead go
| share them with someone else
| chillpenguin wrote:
| Croquet's Greenlight app has the canvas idea in a web app. Also
| it is multi-user. Worth checking out.
___________________________________________________________________
(page generated 2022-08-26 23:00 UTC)