Lambda the Ultimate

why the lucky stiff's "tryruby" is the latter, an AJAX doodad with Ruby on the server. It is intended to be a collaborative set of Ruby tutorials. why wrote a teeny bit more about it here.

...which can be found Here. IIRC, the biggest problem was that JavaScript runs out of stack space real fast.

Oh, and, the language of the 50's is more than happy to keep surprising us. :-)

There's this one as well. It includes full first class continuations, a 'just in time' compiler and a lot of r5rs.

I played around with this and got it working with Firefox.

I added a set-timeout! function which lets you call Scheme functions at set times via the Javascript setTimeout call. This combined with continuations could be turned into a Scheme light weight threading library that runs in the browser. Albiet slowly :)

Over six years ago, in December 1989, I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas... I chose Python as a working title for the project...

...I've been saying for over a decade that the industry has ignored Nicklaus Wirth's post-Pascal work to its detriment, assuming that the alternatives are C and C++. Project Oberon is one of the best OS/language design texts I own, if not the best.

Oberon was recently discussed on Lambda. In that discussion is a link to the PDF version of the book, if you don't want to fork over a $100 to Amazon.

Is there anything in particular from the book that you could highlight?

It is great that the book is available electronically.

It's been a long time since I've read it, and I'd have to dig my copy out, but the things that impressed me overall about Project Oberon were that it resurrect the idea that everything, from language to OS to applications, should be integrated instead of being treated separately, that a language could be a good "systems language" (with direct hardware access) and "safe language" (you have to declare modules "unsafe" explicitly in order to have direct hardware access) simultaneously, and that orthogonality is a good idea from top to bottom; the classic Oberon environment made essentially all operations extremely easy to visualize/leverage because the text-command system plus their three-button mouse operations led to great fluidity in code adding commands to a text, where the user could then easily execute the new command in essentially a GUI interpretation of a REPL.

But remember, I said that Wirth's post-Pascal work was ignored by industry to its detriment relative to C and C++. I still look more forward to an industrially-popular language that inherits more from O'Caml or Haskell than any member of the Pascal or C families.

I was a big Turbo Pascal/Delphi user back in the day, and always was mildly interested in Oberon -- I remember a PC-based integrated IDE/OS version. I just don't remember there being much to distinguish it from other Pascal dialects, for instance Turbo Pascal 5.5 w/ modules and classes. Or maybe Oberon inspired these features...?

...being more about building an entire system from the ground up. Ambitious projects like Oberon and Modula-3 are no longer pursued. Instead, languages have tried to coexist with the operating system and stake their claims as virtual machines. Wirth's Component Pascal is an a scaled back Oberon that tries to live in the component interfac space.

We linked to many more examples that included full source code for simple interpreters and such. Luke's Scheme in JS comes to mind (it was mentioned here in the last couple of days, or search the archives) comes to mind, but there are many others. I totally agree that the only way to learn this stuff is to look at examples. The next step is to implement some simple languages yourself.

Of course...

(I was joking. I know I need to get that bell I promised, but after awhile my humour will grow on you)

Is it like a fungus, a lichen or a moss? :-)

Then you must find C to be antiquated. Oberon does more than C (even with the lack of unsigned types): it has a proper module system, fascist type checking, runtime NULL and array bounds checks, which literally _every_ compiler allows you to turn off at least on a module-by-module basis (if not finer-grained via source code pragmas), and proper garbage collection. It's possible to touch low-level stuff and type-cast, as long as you import the SYSTEM module.

In other words, unsafe things are made difficult and patently obvious to the code reader, while safe things are made convenient.

As far as why it is so loud, well, it's statistically rare for folks to name variables or procedures IN ALL CAPITALS. So what better choice to use for keywords? Just look at how often people bitch and moan whenever Bjarn adds _yet_ _another_ keyword to C++, which inevitably conflicts with someone's function, #define, variable, class name, etc. To my knowledge, this has NEVER occured in Oberon.

The number of keywords in the language is pretty diminutively small, too. C has more keywords, IIRC, and in any case, the whole language report is only 20 pages. It's not going to kill you, unless you _let_ it.

If this bothers you, feel free to write a macro for your editor of choice to auto-capitalize Oberon keywords. I remember that the editor for AmigaBASIC (and I believe VisualBasic as well) does this; you are free to type in any case you prefer, but the keywords are auto-capitalized. Think of it as similar to syntax coloring, or pretty printing in the absence of proper boldface.

I wasn't blaming them.

If someone is to blame, it's CS programs that make these techniques look hard and mysterious.