OberonScript: a safe scripting language and runtime for web apps (2007)(ralphsommerer.com)
ralphsommerer.com
OberonScript: a safe scripting language and runtime for web apps (2007)
http://www.ralphsommerer.com/obn.htm
37 comments
[deleted]
For a more modern take, Nim has a type system inspired by the Pascal/Oberon/modula family, adds macros and other powerful metaprogramming features, has simple syntax inspired by Python, and can compile to JavaScript (in addition to C).
"code of the compiler is available... for personal, non-commercial and non-governmental use."
Rendering the project irrelevant at a stroke. A pity.
Does the language do anything that Dart doesn't?
Does the language do anything that Dart doesn't?
It doesn't do anything most modern languages do.
Oberon is one of the confusing family of Oberons that come from a confusing family of Modulas that comes from Pascal. Most of them come from Niklaus Wirth or try to build on his ideas.
The reason I say confusing is that, for example, there's no one Oberon. There's Oberon, Oberon 2, Active Oberon etc [1]. They differ in things like
- they may or may not have things like for loops
- they may or may not have various OOP features
- they may or may not have pointers
- they may or may not have three different types of looping constructs with different constraints (you can exit a do loop, but not a while loop etc.)
and so on, depending on ... well depending on nothing but Wirth's ideas of what a programming language should be. There are at least two OSes built with Oberon: Oberon and Bluebottle.
There are fans of this family of languages, and I've even participated in discussions (on a Russian programming forum) where people would defend to the death the choice of three different loop constructs with different semantics (you can break inside LOOP, but not inside FOR or WHILE etc.), or the difference between procedure and function etc.
[1] https://en.wikipedia.org/wiki/Oberon_(programming_language)
[2] https://en.wikipedia.org/wiki/Oberon_(operating_system)
[3] https://en.wikipedia.org/wiki/Bluebottle_OS
Oberon is one of the confusing family of Oberons that come from a confusing family of Modulas that comes from Pascal. Most of them come from Niklaus Wirth or try to build on his ideas.
The reason I say confusing is that, for example, there's no one Oberon. There's Oberon, Oberon 2, Active Oberon etc [1]. They differ in things like
- they may or may not have things like for loops
- they may or may not have various OOP features
- they may or may not have pointers
- they may or may not have three different types of looping constructs with different constraints (you can exit a do loop, but not a while loop etc.)
and so on, depending on ... well depending on nothing but Wirth's ideas of what a programming language should be. There are at least two OSes built with Oberon: Oberon and Bluebottle.
There are fans of this family of languages, and I've even participated in discussions (on a Russian programming forum) where people would defend to the death the choice of three different loop constructs with different semantics (you can break inside LOOP, but not inside FOR or WHILE etc.), or the difference between procedure and function etc.
[1] https://en.wikipedia.org/wiki/Oberon_(programming_language)
[2] https://en.wikipedia.org/wiki/Oberon_(operating_system)
[3] https://en.wikipedia.org/wiki/Bluebottle_OS
For whatever reason, Wirth did not seem to be a big believer in standardization efforts (maybe he got burned out by the ALGOL effort). So he always reserved the right to change his mind about his languages. If he could save a compiler pass, or make the compiler faster, by changing the language, he often would.
And the people in Wirth's orbit (The OberonScript author did his PhD with Wirth) were naturally interested in programming languages, and the compilers were small and well designed, so they were easy to modify.
Last of all, while Wirth is a very practical guy (having designed multiple workstations full-stack), but he never pursued commercial practicality or industrial applicability as an objective in itself. He'd rather pursue whatever his research agenda at the time was, and if industry found something useful to pick up, good for them.
And the people in Wirth's orbit (The OberonScript author did his PhD with Wirth) were naturally interested in programming languages, and the compilers were small and well designed, so they were easy to modify.
Last of all, while Wirth is a very practical guy (having designed multiple workstations full-stack), but he never pursued commercial practicality or industrial applicability as an objective in itself. He'd rather pursue whatever his research agenda at the time was, and if industry found something useful to pick up, good for them.
> It doesn't do anything most modern languages do
It's a general purpose language you're comparing to other general purpose languages, so of course.
The different versions of oberon, ok, but look at the different versions of C#, scala, SQL, C++ etc etc.
> on nothing but Wirth's ideas of what a programming language should be
Produce something as good as pascal and then I'll be impressed (I've tried and it isn't easy). Wirth is a deeply competent language designer, the diss is undeserved.
It's a general purpose language you're comparing to other general purpose languages, so of course.
The different versions of oberon, ok, but look at the different versions of C#, scala, SQL, C++ etc etc.
> on nothing but Wirth's ideas of what a programming language should be
Produce something as good as pascal and then I'll be impressed (I've tried and it isn't easy). Wirth is a deeply competent language designer, the diss is undeserved.
> Wirth is a deeply competent language designer, the diss is undeserved.
He is a competent language designer, but his ideas about what a language should be are strange at best, and this is reflected in the languages he designs.
While Pascal was (and in many ways still is) a gem for its own time, all of the languages he produced since have been hardly more than a regurgitation of the same ideas, with a strange fixation on the "procedural programming purity at any and all costs" (hence the chase for a loop construct you can't exit, single-return procedures/functions etc.)
He is a competent language designer, but his ideas about what a language should be are strange at best, and this is reflected in the languages he designs.
While Pascal was (and in many ways still is) a gem for its own time, all of the languages he produced since have been hardly more than a regurgitation of the same ideas, with a strange fixation on the "procedural programming purity at any and all costs" (hence the chase for a loop construct you can't exit, single-return procedures/functions etc.)
It's actually very significant that Wirth stayed on the same track after Pascal. That indicates that he saw more to study in the realm of "structured programming" as it was understood in the 70's. Later people in CS academia had careers to build and this ushered them towards pushing other paradigms, but industry has been rather pragmatic on the whole: most code, most of the time, is still structured imperative, still using the same handful of constructs, and still following the guiding forms of structured code: sequence, selection, iteration. The new languages do support many other features, but this is reflective of their role as broad toolboxes that support very large codebases, while a Wirthian language has at least one fundamentally different, well-specified benchmark of success: how efficiently the compiler compiles itself and the operating system. As an object of research, it can afford to be particular about how it gets there, while most engineering teams in industry will settle for whatever can ship.
And if we look at his languages at continued attempts to find the optimum of that space they represent a great resource to tap into - decades of effort to find exactly the right primitives and featureset for the task. That doesn't mean they are the ones to use for all jobs, but "what did Wirth do" is a great starting point.
And if we look at his languages at continued attempts to find the optimum of that space they represent a great resource to tap into - decades of effort to find exactly the right primitives and featureset for the task. That doesn't mean they are the ones to use for all jobs, but "what did Wirth do" is a great starting point.
Good point, thanks. To your last line you can add others who worked on closely related fields like Brinch Hansen, looking for the 'right' primitives for concurrency.
Edit: and by extraordinary coincidence PBH pops up on HN right now https://news.ycombinator.com/item?id=24913959
Edit: and by extraordinary coincidence PBH pops up on HN right now https://news.ycombinator.com/item?id=24913959
Unlike you I actually know about this stuff (though it's much faded by now I admit).
The looping issue is because modelling it - that is, giving it clear and simple formal semantics - was not trivial. The single-point of exit stuff is also there for the same reason. I'd agree that it's possibly not a good choice given the alternatives if you are doing non-verified code, but he had his reasons.
If you ever wonder why modula-3's garbage collector only collected memory, you could not hook into it in the form of a destructor for management of resources other than memory, go and read up the complexities that being able to piggyback on a destructor brings. It gets bad.
We could have some agreement but with "regurgitation", "strange fixation", "strange at best#" - this is the sound of you not understanding and not realising it, not wirth's deficiencies.
If you think you can do better then go ahead. You'll learn a lot.
The looping issue is because modelling it - that is, giving it clear and simple formal semantics - was not trivial. The single-point of exit stuff is also there for the same reason. I'd agree that it's possibly not a good choice given the alternatives if you are doing non-verified code, but he had his reasons.
If you ever wonder why modula-3's garbage collector only collected memory, you could not hook into it in the form of a destructor for management of resources other than memory, go and read up the complexities that being able to piggyback on a destructor brings. It gets bad.
We could have some agreement but with "regurgitation", "strange fixation", "strange at best#" - this is the sound of you not understanding and not realising it, not wirth's deficiencies.
If you think you can do better then go ahead. You'll learn a lot.
> The looping issue is because modelling it - that is, giving it clear and simple formal semantics - was not trivial.
Literally hundreds of programming languages have loops without unnecessary and random constraints
> The single-point of exit stuff is also there for the same reason.
The same reason of what exactly?
> I'd agree that it's possibly not a good choice given the alternatives if you are doing non-verified code
At what point Oberon code becomes verified?
> If you think you can do better then go ahead.
I realise that you haven't left Wirth's lab for the past 30 years, but there are hundreds of programming languages. Go ahead, you'll learn a lot.
Literally hundreds of programming languages have loops without unnecessary and random constraints
> The single-point of exit stuff is also there for the same reason.
The same reason of what exactly?
> I'd agree that it's possibly not a good choice given the alternatives if you are doing non-verified code
At what point Oberon code becomes verified?
> If you think you can do better then go ahead.
I realise that you haven't left Wirth's lab for the past 30 years, but there are hundreds of programming languages. Go ahead, you'll learn a lot.
> Literally hundreds of programming languages have loops without unnecessary and random constraints
Hm? show me the 'unnecessary and random constraints' in looping. It was fundamental to the semantics that looping wasn't simple formally IIRC
> he same reason of what exactly?
It's literally there in the preceding sentence.
> At what point Oberon code becomes verified?
It didn't (AFAIK), hence my "possibly not a good choice". But as you don't know history, https://en.wikipedia.org/wiki/Euclid_(programming_language) which "is descended from the Pascal programming language". IIRC the london underground train controller software was done with euclid. Please note the wide range of restrictions in the language - all for simplicity, from which reliability must in part depend.
> I realise that you haven't left Wirth's lab for the past 30 years,
don't be insulting
> but there are hundreds of programming languages. Go ahead, you'll learn a lot.
Like: scala? And C#? VB.net, VBScripting, a little bash, pascal, modula2, delphi, javascript, a flex/bison & antlr, python, sql, prolog (edit: C & C++) - these are all langs I've used commercially. If you want langs I've played with the list includes dylan, haskell, erlang, modula3 and others I can't think of now.
Like I said, If you think you can do better then go ahead.
Edit: what your angry reaction is concealing from you is I'm not unsympathetic to your view, but you can't see it and won't learn from it.
Hm? show me the 'unnecessary and random constraints' in looping. It was fundamental to the semantics that looping wasn't simple formally IIRC
> he same reason of what exactly?
It's literally there in the preceding sentence.
> At what point Oberon code becomes verified?
It didn't (AFAIK), hence my "possibly not a good choice". But as you don't know history, https://en.wikipedia.org/wiki/Euclid_(programming_language) which "is descended from the Pascal programming language". IIRC the london underground train controller software was done with euclid. Please note the wide range of restrictions in the language - all for simplicity, from which reliability must in part depend.
> I realise that you haven't left Wirth's lab for the past 30 years,
don't be insulting
> but there are hundreds of programming languages. Go ahead, you'll learn a lot.
Like: scala? And C#? VB.net, VBScripting, a little bash, pascal, modula2, delphi, javascript, a flex/bison & antlr, python, sql, prolog (edit: C & C++) - these are all langs I've used commercially. If you want langs I've played with the list includes dylan, haskell, erlang, modula3 and others I can't think of now.
Like I said, If you think you can do better then go ahead.
Edit: what your angry reaction is concealing from you is I'm not unsympathetic to your view, but you can't see it and won't learn from it.
> what your angry reaction is concealing from you
> don't be insulting
Let's see about "my" reactions and "being insulting"
- Unlike you I actually know about this stuff
- this is the sound of you not understanding and not realising it
- If you think you can do better then go ahead. You'll learn a lot.
Take your holier than thou attitude and shove it where the sun don't shine.
> don't be insulting
Let's see about "my" reactions and "being insulting"
- Unlike you I actually know about this stuff
- this is the sound of you not understanding and not realising it
- If you think you can do better then go ahead. You'll learn a lot.
Take your holier than thou attitude and shove it where the sun don't shine.
> read up the complexities that being able to piggyback on a destructor brings. It gets bad.
Here's the Wikipedia page on the topic: https://en.wikipedia.org/wiki/Object_resurrection
Here's the Wikipedia page on the topic: https://en.wikipedia.org/wiki/Object_resurrection
Thanks for the well-informed response.
Sounds rather shallow to me, really. I can see the point in building a kernel in the safe subset of Rust, to provide strong assurances about memory-management. I can see the point in building a kernel in SPARK to provide even stronger and more general assurances of correctness. I see the point in developing a kernel using a fully formal methodology, like Sel4. I can see the fun in hand-tuned kernels written in assembly, like KolibriOS. What's interesting about using a language with slightly different imperative building-blocks? Rust wouldn't be worth learning if it were merely C with different iterative statements.
Or are there significant advantages to the various Oberons, that I'm unaware of?
Sounds rather shallow to me, really. I can see the point in building a kernel in the safe subset of Rust, to provide strong assurances about memory-management. I can see the point in building a kernel in SPARK to provide even stronger and more general assurances of correctness. I see the point in developing a kernel using a fully formal methodology, like Sel4. I can see the fun in hand-tuned kernels written in assembly, like KolibriOS. What's interesting about using a language with slightly different imperative building-blocks? Rust wouldn't be worth learning if it were merely C with different iterative statements.
Or are there significant advantages to the various Oberons, that I'm unaware of?
I'm no expert but it seemed to me the whole Pascal, Modula, Oberon story is in big part about Wirth chasing/exploring some optimal/balanced¹ programming language.
So, it makes a lot of sense to have many variants and an evolution retracing both his learnings and opinions (that can change with time, and do, hopefully) and exploring different variations on a common theme.
And developping an OS in any of these languages is pretty much a real-life test of their adequacy (meaning they are not just some vacuous formal exercise).
Iirc, Wirth achieved some relatively lean but powerful languages at some point.
Also, I don't understand your opposition to writing a kernel in some form of Oberon, but accepting pretty much any other language/paradigm ?
¹ Not that there is only _one_ optimal language.
Iirc, Wirth achieved some relatively lean but powerful languages at some point.
Also, I don't understand your opposition to writing a kernel in some form of Oberon, but accepting pretty much any other language/paradigm ?
¹ Not that there is only _one_ optimal language.
> I don't understand your opposition to writing a kernel in some form of Oberon, but accepting pretty much any other language/paradigm
When people talk about developing a kernel in a language other than C, the question that springs to mind is So what does this choice of language bring to the table?
Rust and especially SPARK bring significant assurances of correctness, as they both improve greatly on the unsafety (supposing that's a word) of the C language.
The same is true of a middle-of-the-road language like Java, but Java isn't ideally suited to kernel development. (If OS researchers prove me wrong on this point, then that's great, of course.)
Assembly isn't a very compelling choice of language in terms of safety/correctness assurances, but I can see the appeal for a hobbyist OS, or for a carefully tuned high-performance codebase.
From what I know of Oberon, using it for kernel development isn't in itself very interesting. Does it offer the guaranteed absence of broad categories of runtime errors? I guess it's still probably a rather safer language than C, and I presume its performance is ok, but this isn't anything new.
(Of course, I've only talked about language. There are plenty of other ways an OS can be interesting besides the language it's implemented in, but that's the topic at hand.)
When people talk about developing a kernel in a language other than C, the question that springs to mind is So what does this choice of language bring to the table?
Rust and especially SPARK bring significant assurances of correctness, as they both improve greatly on the unsafety (supposing that's a word) of the C language.
The same is true of a middle-of-the-road language like Java, but Java isn't ideally suited to kernel development. (If OS researchers prove me wrong on this point, then that's great, of course.)
Assembly isn't a very compelling choice of language in terms of safety/correctness assurances, but I can see the appeal for a hobbyist OS, or for a carefully tuned high-performance codebase.
From what I know of Oberon, using it for kernel development isn't in itself very interesting. Does it offer the guaranteed absence of broad categories of runtime errors? I guess it's still probably a rather safer language than C, and I presume its performance is ok, but this isn't anything new.
(Of course, I've only talked about language. There are plenty of other ways an OS can be interesting besides the language it's implemented in, but that's the topic at hand.)
> The same is true of a middle-of-the-road language like Java, but Java isn't ideally suited to kernel development. (If OS researchers prove me wrong on this point, then that's great, of course.)
Microsoft had an experimental OS called Singularity [1]
--- start quote ---
The lowest-level x86 interrupt dispatch code is written in assembly language and C. Once this code has done its job, it invokes the kernel, which runtime system and garbage collector are written in Sing# (an extended version of Spec#, itself an extension of C#) and runs in unprotected mode.
--- end quote ---
And don't forget that SIM cards in your phone run a Java... -ish [2,3]
[1] https://en.wikipedia.org/wiki/Singularity_(operating_system)
[2] https://www.defcon.org/images/defcon-21/dc-21-presentations/...
[3] https://en.wikipedia.org/wiki/Java_Card
Microsoft had an experimental OS called Singularity [1]
--- start quote ---
The lowest-level x86 interrupt dispatch code is written in assembly language and C. Once this code has done its job, it invokes the kernel, which runtime system and garbage collector are written in Sing# (an extended version of Spec#, itself an extension of C#) and runs in unprotected mode.
--- end quote ---
And don't forget that SIM cards in your phone run a Java... -ish [2,3]
[1] https://en.wikipedia.org/wiki/Singularity_(operating_system)
[2] https://www.defcon.org/images/defcon-21/dc-21-presentations/...
[3] https://en.wikipedia.org/wiki/Java_Card
There's also the JX research operating system, which used Java.
https://en.wikipedia.org/wiki/JX_(operating_system)
https://en.wikipedia.org/wiki/JX_(operating_system)
Project Treble also allows writing userspace drivers in Java.
Then besides JX, there was SquawkVM for SPOT, Solaris research for Java drivers, and embedded vendors like PTC and Aicas do support bare metal Java runtimes, which is basically an OS at that point.
Then besides JX, there was SquawkVM for SPOT, Solaris research for Java drivers, and embedded vendors like PTC and Aicas do support bare metal Java runtimes, which is basically an OS at that point.
I think part of the argument is that if you want to have confidence in the correctness of a system, the system has to be so small and simple that anyone can fully understand it and keep it all in their head. For example, how do you know that the toolchains for Rust, Spark, sel4 work correctly? Have all aspects been verified or proven? Can a single person fully understand them? I’m not saying that’s the necessarily best criterion. The point is that all the guarantees that Rust, spark, Haskell, etc give are only meaningful if you can trust the tools to correctly implement them. Simplicity of the tools is one approach.
> how do you know that the toolchains for Rust, Spark, sel4 work correctly? Have all aspects been verified or proven
In the case of Sel4, yes. The ARMv7 assembly code has been shown to be free of bugs. [0][1]
SPARK Ada does not have a formally verified compiler, but there are various Ada compilers that are approved for use in life-and-death applications. The Boeing 777 flies on Ada code, for instance. [2] To my knowledge, compiler bugs aren't a major practical concern for SPARK, although a formally verified compiler would be a great addition.
C has a fully verified compiler in CompCert. [3] I know of no other language with a fully verified compiler. (CompCert supports almost all C features, so it will either produce a valid binary for the input C code, or else fail with an error.)
Rust has a bit of a history of troublesome compiler bugs. I think we're a way off seeing Rust used in critical systems, assuming it would even make sense to use a language like Rust. Memory management is handled quite differently in applications like avionics.
> Can a single person fully understand them?
The compilers/linkers? I imagine the most well-informed developers on the Rust and Ada compilers pretty much know how everything works, but really that's just a guess. If someone were to make a compiler specifically for SPARK, it could be simpler than a full Ada compiler, as SPARK forbids most Ada features. I don't know that this is likely to happen though.
[0] https://docs.sel4.systems/projects/sel4/frequently-asked-que...
[1] https://sel4.systems/Info/FAQ/proof.pml
[2] http://archive.adaic.com/projects/atwork/boeing.html (This is about Ada, and is not specifically about the SPARK subset)
[3] https://en.wikipedia.org/wiki/CompCert
In the case of Sel4, yes. The ARMv7 assembly code has been shown to be free of bugs. [0][1]
SPARK Ada does not have a formally verified compiler, but there are various Ada compilers that are approved for use in life-and-death applications. The Boeing 777 flies on Ada code, for instance. [2] To my knowledge, compiler bugs aren't a major practical concern for SPARK, although a formally verified compiler would be a great addition.
C has a fully verified compiler in CompCert. [3] I know of no other language with a fully verified compiler. (CompCert supports almost all C features, so it will either produce a valid binary for the input C code, or else fail with an error.)
Rust has a bit of a history of troublesome compiler bugs. I think we're a way off seeing Rust used in critical systems, assuming it would even make sense to use a language like Rust. Memory management is handled quite differently in applications like avionics.
> Can a single person fully understand them?
The compilers/linkers? I imagine the most well-informed developers on the Rust and Ada compilers pretty much know how everything works, but really that's just a guess. If someone were to make a compiler specifically for SPARK, it could be simpler than a full Ada compiler, as SPARK forbids most Ada features. I don't know that this is likely to happen though.
[0] https://docs.sel4.systems/projects/sel4/frequently-asked-que...
[1] https://sel4.systems/Info/FAQ/proof.pml
[2] http://archive.adaic.com/projects/atwork/boeing.html (This is about Ada, and is not specifically about the SPARK subset)
[3] https://en.wikipedia.org/wiki/CompCert
If I understand it correctly, the primary purpose of the whole Oberon ecosystem is as an educational tool. And in that, I can see value. Having a holistic consistent system in one language/paradigm that you can build or analyze from the ground up has definite pedagogical value.
Right.
I think you would be pretty hard pressed to design a system as functional and as clear as the Oberon System in so compact a manner that you can fit essentially all of it in one book (and implement it with a tiny team): https://people.inf.ethz.ch/wirth/ProjectOberon/index.html
I must admit I was a user of the system many years before I read the book, and I enjoyed reading the book considerably more than working with the system, but it's still a gem of a design. [Edited to fix link]
I must admit I was a user of the system many years before I read the book, and I enjoyed reading the book considerably more than working with the system, but it's still a gem of a design. [Edited to fix link]
your link misses an `i` in `wirth`
Thanks! I copied it from Prof Wrth's own homepage ;-)
> Does the language do anything that Dart doesn't?
No. But Oberon demonstrates how one can implement real systems with a very little language; and with an extremely small footprint compared to Dart (you can fit a whole operating system into one or two megabytes). There are a lot of other differences; Oberon is a truly statically/strictly typed language wheras the type system in Dart is intentionally optional; you can write an Oberon parser in a couple of hours (in contrast to more complex and ambiguous languages like Dart or Go). Oberon was optimized for use as an educational language and was successfully used for this purpose e.g. at the ETH Zurich. Wirth wanted the minimum necessary for his language, without unnecessary luxury, which only increases the development and learning effort.
No. But Oberon demonstrates how one can implement real systems with a very little language; and with an extremely small footprint compared to Dart (you can fit a whole operating system into one or two megabytes). There are a lot of other differences; Oberon is a truly statically/strictly typed language wheras the type system in Dart is intentionally optional; you can write an Oberon parser in a couple of hours (in contrast to more complex and ambiguous languages like Dart or Go). Oberon was optimized for use as an educational language and was successfully used for this purpose e.g. at the ETH Zurich. Wirth wanted the minimum necessary for his language, without unnecessary luxury, which only increases the development and learning effort.
Sounds rather like the application of the Forth philosophy to conventional imperative programming.
(Curiously I was saying just the same thing yesterday about Tcl - https://news.ycombinator.com/item?id=24898886 )
(Curiously I was saying just the same thing yesterday about Tcl - https://news.ycombinator.com/item?id=24898886 )
See https://people.inf.ethz.ch/wirth/Articles/Modula-Oberon-June... for the philosophy
Well, they did write an OS in Oberon. Not sure how much of the language is included in the Script.
2007 probably needs to be added to the title. I get the feeling that progress is a bit slower than anticipated.
2007 probably needs to be added to the title. I get the feeling that progress is a bit slower than anticipated.
gridlockd(1)