Slashdot Mirror

now i'm feeling more than just a little bit nostalgic.. if you are too, here's a fix: http://www.masswerk.at/flyer/

When Djikstra wrote his article, languages like C and Pascal with while() and do {} while() loops did not exist.

If you think that while-loops were popularized by C or Pascal, I have a surprise for you. Note, this is from 1960, but the first version of the language already had in in 1958!

Heck, when Dijkstra wrote it, there was already Simula-67 out there, which had classes and objects, virtual functions with overriding, and access modifiers (on top of everything Algol had). If you ever wondered where "virtual" and "new" in C++ came from by the way, that's its origin.

And then there was Algol 68, with structs and unions (again, that's where C stole that stuff), function pointers, and a lot of other gimmicky stuff. Also, "void".

Most of the things in programming are much older than people assume these days.

BTW, here is the Algol-60 standard. It's pretty short, so should be an easy read, but if you haven't seen it before, you'll be surprised at how much was there already, given that we're talking about something that started its life in 1958 (that's when the first Algol report was published, 1960 was a later revision).

Well, except labels don't necessary point to the function entry.

But the craziest version of this that I've seen is in Algol-60. There, "label" is actually a data type of sorts - while you cannot declare variables of that type, you can use it to declare procedure (function) arguments. At runtime, the procedure can then goto such a label argument, which allows for a nonlocal exit to the point designated by the caller (in effect, this is setjmp/longjmp - devised in 1958!).

They also had the notion of a "switch", which is basically an array of labels - either locally declared, or also passed as a procedure argument in a similar fashion.

If you haven't seen this, you should check it out: http://www.masswerk.at/google6...

Oh and here is a speech synthesizer using Web Audio API: http://www.masswerk.at/mespeak/

Do you prefer a slow emulated real system, or a fast but minimal toy?.

K&R's book on C is wordy. The true classic is the Revised Report on the Algorithmic Language ALGOL-60. In its original typeset form, it is 19 pages.

It's strictly a language spec, though, not a book explaining "why" as well as "what".

By modern standards, it's still somewhat underspecified. Especially in parts such as computed gotos, but there were a few other bits as well - which is why they needed Modified Report on the Algorithmic Language Algol 60, the rationale for which is:

Meanwhile, various defects have been noted in the language definition which have unnecessarily hindered the use of ALGOL. Although the existence of subsets has given some assistance to the compiler-writer and user of the language, numerous problems exist, some of which were noted in the Revised Report.

Hence the need for a detailed commentary and standard interpretation has become apparent. Such a commentary is now available, defining the modifications necessary to produce this Report from the Revised Report.

Finally, it describes a language which didn't have an extensible type system, didn't have pointers, had only 4 basic types (integer, real, Boolean, label) and arrays and procedures thereof, and didn't even have strings as first-class values (yeah, you had "text" type, but you could only produce values of it from string literals and pass it around - no operations on strings at all; you can't even read a string from standard input!).

K&R's book on C is wordy. The true classic is the Revised Report on the Algorithmic Language ALGOL-60. In its original typeset form, it is 19 pages.

Languages which need 1000-page books are badly designed.

Actually the K&R book is 272 pages (including index)... and if a language can be transcribed to 19 pages of text it's obviously lacking...

K&R's book on C is wordy. The true classic is the Revised Report on the Algorithmic Language ALGOL-60. In its original typeset form, it is 19 pages.

Languages which need 1000-page books are badly designed.

Ok, seriously. Why Algol-60?

Because it is one of the three languages that started it all, and one that affected all existing mainstream languages most. Curly braces of C, and the block construct that they represent, began their life as "begin .. end" in Algol-60.

Because it is at the same time a very beautiful language - especially considering the time when it was designed - and one with some very advanced constructs, not found even in many modern languages, that can pose significant challenge to implement efficiently, especially in an otherwise constrained environment such as sandboxed CLR. To list a few such features: computed goto, label variables/function arguments and the associated nonlocal goto, arbitrarily nested functions with variable capturing, and call-by-name. Challenges are fun.

Because it's a very important milestone in history of CompSci in general, and language design in particular (in case it's not quite obvious yet, I'm a language design geek), a piece of it that I wish to preserve. Apparently, I'm not alone in that, either - there's also GNU Marst - curiously enough, written by another Russian dude.

Because Simula-67 (the first OOP language ever, and the ultimate ancestor of virtually every statically typed OO language today, including C++, Java and C#) is a strict superset of Algol-60, and I wanted to go after it next.

And, of course, just for fun. I mean, this is Slashdot, right? We routinely get people installing KDE2 on NetBSD running on toasters with 7-segment indicators here; I think my little fetish is relatively benign in contrast.

(To bring the above references to Algol-60 language features into some context for those not familiar with the subject, the final Algol-60 language spec is here; it's a fairly short read.)

After all everybody her on SlashDot knows that Algol-68 is the most recent version!

Algol-68 is an entirely different language from Algol-60. It's not evolutionary, but a complete, ground-up redesign, by very different people. It's also a very interesting one, and important in its own right, since C borrowed a lot of things from it, down to keywords (VOID, INT, SHORT, LONG, STRUCT and UNION are all Algol-68 keywords with virtually the same meaning they have retained in C).

It would be fairly interesting thing to implement as well, but in many ways it's a much more rationally designed language than Algol-60, dropping some overly exotic and complicated features, and, consequently, implementing it is less of a challenge (I guess they had had enough real-world experience writing compilers by then to conclude that some features of Algol-60 looked good on paper only...).

Looks like someone beat you to it!

You're free to port it to work under mass:werk termlib but I'm not feeling adventurous enough for that.

No, but there is a unix-like environment written in javascript!

I don't know about Emacs, but someone made a JavaScript terminal which contains a version of VI (striped-down albeit)

> write a JavaScript port of vi Already done: :) http://www.masswerk.at/jsuix/

Oh, come on. Surely you can implement a terminal in JavaScript?

I'm rather impressed with this

Eliza needs an AI-optimized Firefox to run the JavaScript program for artificial intelligence.

AI Mind is a more advanced artificial intelligence at the Saint Stephen AI Project.

Mind.html is a Tutorial Artificial Intelligence that will work properly only if JavaScript works as well in Firefox as in Internet Explorer.

LOL. I saw a similar Javascript terminal app that ran in the browser and sorta simulated an actual unix OS, but I thought it was just a sort of joke. Did you really think that such an idea would actually be useful?

I wouldn't be surpised if it was JS/UIX. Trying that and TiddlyWiki solidified my concept of how to resolve my UI issues as a web developer.

Anyway, don't worry about YouOS. It'll fail.

I'm not worried about it - I don't want it to fail. Competition's good for business. =)

I was a little miffed at Murphy for his timing yesterday though.

Besides, it's available under a modified BSD license. I'm learning JavaScript by writing Atomic OS; I expect I might be able to learn a thing or two from their project.

Aw, come on. You gotta admit that this UN*X-like OS in JavaScript thing is pretty cool. :)

...but I can't find the story. Anyway, I like JS/UIX. Wish I could be talented enough to do that.

I'd go a step further (higher). As more and more things are moving to the Web, and as web application are getting richer and richer, I'd guess that in the next 5 or so years the OS will become quite irrelevant to the end user, who will access a lot more "desktop" applications through a web interface.

With regards to the discussion, I couldn't care less about Marketers, but saying cookies are bad because of companies like doubleclick, is like saying images are bad, because of animated gifs. Cookies have lots of really useful applications, when you want to persistant states with out requiring regristration (which I hate).

It used to be that sites were not really customizable. Those that were, were like what netscape.com is right now, and any change required page reloads and were generally undesirable. With the advancement of a standard DOM (pretty much everyone supports level 1), you can now do lot's of really cool stuff - allowing users to change things around at light speed, making it practical and not just a bloated nuciance. The JS/UIX term is a great example of this: http://www.masswerk.at/jsuix/

However, if you want to create something that last more than just one brower session, and works well on a per user basis (particularly for people on lan's), the only real way is to use cookies. Of course you don't store any more information in there than needed.

Or we need a browser to run an OS...
JS/UIX

Well, the guy has written an E.A.L (Easy Algorithmic Language) compiler in Javascript. :)

http://www.masswerk.at/demospace/eal/eal.htm

JS/UIX - A Short Documentation (based on v.0.42) by Norbert Landsteiner

[Logo removed -- attempt to defeat lameness filter]

1) What it is

JS/UIX is a virtual OS written entierly in JavaScript to be run in any standard web-browser (type 4.0 or higher). The user interface - a simple 80 colums terminal - is implemented in DHTML but could be implemented in any other JavaScript compliant application environment as p.e. Macromedia Flash(TM).

JS/UIX features a UN*X-like operating environment with no intention of any full POSIX compatibility. Some standard commands have been implemented at full range others with just simple syntax or basic functionality, while new commands have been added. The only application for now is a simple implementation of vi (visual editor).

JS/UIX is now a mere demonstration object. A serious application could be its use as an interface to a server-shell or CGI-process via a rlogin like protocoll, where any transaction data could be encrypted and stored in an additional HTML-[I]FRAME.

Fig. 1: Possible implementation of a remote interface [removed to get by lameness filter]

A second application could be an embedded service, which would be executed local to the client but would retrieve remote data from a host via HTTP and CGI.

Fig. 2: Possible implementation of a local service using remote data [removed to defeat lameness filter]

2) Features & Functions

a) Users and Files

JS/UIX accepts any valid user name as login with the exception of "exit" and "root" (or any of their derevative spellings). "exit" will close the console while "root" is a protected user showing a password prompt. (root:machtNix) (Future versions might allow password control for all users via a "passwd"- command. A practical implementation - see above, fig. 1-2 - would probably not give access to unregistrated users. This should be a demo feature only.)

A valid login triggers the following steps: - an entry in /etc/passwd is searched or generated - an entry in /etc/group is searched or generated - the home directory /home/ is generated if not found - the home directory and user-variables are set - the history file /home//.history is loaded or generated - the file /etc/profile is searched and executed

"root" has the UID 0 and is allocated to the groups 0 (system) and 1 (wheel), while a normal user acquires a UID greater than 100 and is allocated to the groups 1 (wheel) and 2 (users) with GID 2.

The same steps are taken at "su" (switch user) but the working directory will not be set to the home directory ($HOME). (See the note on "su" below.)

A typical allocation of users and groups after a login with user-id "guest" will look like the following:

$ cat /etc/passwd root:*:0:1:root:/root:/bin/sh guest:*:101:2:guest:/home/guest:/bin/sh

$ cat /etc/group system:0:root users:2:guest wheel:1:root,guest

Fig. 3: Users and groups after login with user-id "guest"

After login the user will be prompted with the default prompt:

[guest@masswerk.at:2]$ _

showing the user-name, host and PID as defined in $PS. (default value: [${USER}@${HOST}:${PID}]) A normal user's prompt will be marked with the suffix "$" while the root user's prompt is marked with the suffix "#". (Hard coded, no $PS2 by now!)

Note: Currently the prompt is not a function of the shell but of the kernel (triggered by the TTY-interface). This should be fixed in future versions.

b) Files

Files are stored virt

Heck, you can even write your own Unix operating system:

JSUIX

Try this site to see what I mean.
http://www.masswerk.at/jsuix/