They were trying for 10k lines of code(I think I saw Alan Kay mention online that they got to about 20k lines).

Do you have a link to the project? I'm failing to find it on that page.

Not op, and can’t google now but the project was called STEPS, they did a down-to-metal os including network and GUI (and mote) in 20k lines.

Don’t remember anything about office suite. Related names I remember are Alan Kay, Dan Amelang, Alessandro Wirth and Ian Piumarta.

The biggest artifact from STEPS was Frank, which was at the time bootstrapped using Squeak Smalltalk and included the work from Ian Piumarta (IDST/Maru, which was a fully bootstrapped LISP down to the metal), Dan Amelang (Nile, the graphics language, and Gezira, the 2.5D graphics library implemented in Nile, which both depended on Maru), Alex Warth (OMeta, which had some sort of relationship to Ian's work on Maru), Yoshiki Ohshima (a lot of the experimental things from Alan's demos of Frank were made by Yoshiki) and then several other names. I got close to getting Frank working, but honestly, I'm not sure it's worth it at this point. A lot of the work is 10-15 years old, and the last time I dove in, I ran into issues running 32-bit binaries. The individual components are more interesting and could be packaged together in some other way.

Since it was a research project, STEPS never quite achieved a cohesive, unified experience, but they proved that the individual components could be substantially minimized and the cost of developing them amortized over a large project like a full GUI environment. Nile and some of the applications of Maru, like a minimal but functioning TCP/IP stack that can be compiled to bare metal by virtue of being made in Maru, still fascinate me.

Work on Maru is ongoing, albeit run by a community (with some input from Ian), Nile has been somewhat reborn of late, Ohm is again under active development as the successor to OMeta and Alan is still around.

(Source: Dan is a friend and colleague, and I've met a few of the STEPS/VPRI people that way.)

Is there some place STEPS fans can gather and gather our notes? There are archives of the FONC mailing list here [1].

I'm an outsider and also never got Frank to work. I was waiting for the Nile/Gezira thesis to get a high level (but hopefully also some detailed) descriptions) of how they handled graphics. I vaguely remember getting parts of idst working but for each of these projects, there were always multiple versions lying around. Sometimes in odd places.

I read Alex Warth's thesis and it's well written, in a way that makes it very easy to understand. So, of course, I had to implement my own OMeta variant [2].

Also, the VPRI website itself says it's shutting down (presumably folks moved to HARC at that time?).

Edit to add that OMeta is the language agnostic parser and compiler!

[1] https://www.mail-archive.com/fonc@vpri.org/ [2] https://github.com/asrp/pymetaterp

> Is there some place STEPS fans can gather and gather our notes? There are archives of the FONC mailing list.

Maru development is documented on an active mailing list.[1] Ohm development is being coordinated through GitHub. I'd personally like to take the extant code from OMeta/JS and the JS implementation of Nile & Gezira, and modernize them.

Recently I've been wondering if there's enough interest for a Discord server or something. (In the spirit of STEPS, it'd be ideal to make a new collaborative thing that's really different than static text/audio/video on the web, but gotta start somewhere. :) ) Unfortunately, I have had other, higher-priority projects at the moment, so I have taken no initiative to try to build a community.

I will also say that in my opinion, it's not clear to many of the people who made this stuff how special it is. The only exception to that is Bret Victor, who actually is not well-understood, but even the banana pudding versions of his ideas are typically much better than the industry's.

> I'm an outsider and also never got Frank to work. I was waiting for the Nile/Gezira thesis to get a high level (but hopefully also some detailed) descriptions) of how they handled graphics. I vaguely remember getting parts of idst working but for each of these projects, there were always multiple versions lying around. Sometimes in odd places.

I've never gotten Frank to work, and I abandoned my attempts. I've seen it run, though. The name was fully truthful: it really is Frankenstein's monster.

I did get Nile + Gezira to work (albeit in a very crude way by printing numbers to the console rather than hooking it up to a frame buffer). That's how I met Dan. I don't want to betray any confidences with him, but there is ongoing work with Nile.

Here's Dan himself presenting a related language at Oracle Open World in a demo (around 25 mins in).[2] (Full disclosure: I worked on the demo.)

If it were me getting started, I would take a look at the JavaScript implementation of Nile in Dan's Nile repo on GitHub. It should more or less work out of the box, and there's an HTML file containing a fairly full subset of Gezira. The only problem is that the JS style is way out of date, and so it does some things that are heavily frowned upon today. It may not work with tools like Webpack.

The Maru-based Nile is trickier to get working, but it does work. The issue with Ian's Maru is that it's quite hard to reason about and lacks clear debugging tools. I've gotten both up and running. I seem to remember the Boehm GC was pivotal in getting Maru to bootstrap and then run Nile.

> I read Alex Warth's thesis and it's well written, in a way that makes it very easy to understand. So, of course, I had to implement my own OMeta variant [2].

Pymetaterp is cool! I agree: Warth's work on OMeta was impressive. In some ways, Ohm feels inferior to me, though they're both good tools with lots of potential.

OMeta is the one tool from STEPS that is basically simple to understand and use without having to do a bunch of code archaeology.

> Also, the VPRI website itself says it's shutting down (presumably folks moved to HARC at that time?).

VPRI closed because STEPS ended and because Alan had to retire at some point. HARC and/or CDG Labs continued the work, but then closed as well. (I don't know all of the details, but someone here suggested SAP withdrew funding. That would track with what I do know.)

Today, Ian is teaching in Japan, Dan is at Vianai, Alex is at (IIRC) Google, Yoshiki is at Croquet, Bret Victor is doing Dynamicland, Vi Hart is at Microsoft Research and then Alan is retired. There were quite a few others I'm missing, and they are all doing interesting things as well.

[1] https://groups.google.com/g/maru-dev

[2] https://www.oracle.com/openworld/on-demand.html?bcid=6092429...

I've put up a barebones Slack [1] and editable Wiki [2]. I might fill that with info I have in the coming weeks since I realized all I had were scattered files.

Diving into this a bit, I remembered that fonc had it's own (now defunct) wiki. [3] It seems like a lot of the important pages were unfortunately not updated though.

[1] https://join.slack.com/t/footprintsorg/shared_invite/zt-o7ch... [2] https://hackmd.io/SB4QqG7bSxmgoUvPPoSzUA [3] http://vpri.org/fonc_wiki/ [3, archive.org] https://web.archive.org/web/20110901193854/http://vpri.org/f...

> I will also say that in my opinion, it's not clear to many of the people who made this stuff how special it is. The only exception to that is Bret Victor, who actually is not well-understood, but even the banana pudding versions of his ideas are typically much better than the industry's.

I would love to hear more about how you believe not only outsiders, but also the people who made this misunderstand this work?

How do you see the importance of STEPS and Bret Victor's work? I'm a big fan, and you clearly have a lot of knowledge. I'd love to read more!

Thanks, a lot of this is new and useful to me.

> Recently I've been wondering if there's enough interest for a Discord server or something. (In the spirit of STEPS, it'd be ideal to make a new collaborative thing that's really different than static text/audio/video on the web, but gotta start somewhere. :) ) Unfortunately, I have had other, higher-priority projects at the moment, so I have taken no initiative to try to build a community.

I don't really like Discord because they keep asking for phone verification and early on, they were pretty aggressively shut down alternate client attempts.

What about Mattermost? I could try to set one up though initially, we wouldn't have email notifications or a CDN. Might not be so good if the initial group is small.

Slack? Don't know how they compare to Discord but at least they don't ask for phone verification.

A subreddit? A mailing list? Some kind of fediverse thing?

If there's some possibility of migrating to our own platform, I guess it doesn't matter as much where we start.

I could try to set something up in the coming week. But interest in this HN thread will still have died by that time.

> I did get Nile + Gezira to work (albeit in a very crude way by printing numbers to the console rather than hooking it up to a frame buffer). That's how I met Dan. I don't want to betray any confidences with him, but there is ongoing work with Nile.

Nice! I'm not anywhere near that. I'm still looking for a description of what it _is_ and at a very high level, how does it work internally? Something like "it's mathematical notation to describe the pixel positions/intensities implicitly via constraint equations; it uses a <something> solver for ...". What's in quote could be way off and is from memory of what I remember seeing.

> I've gotten both up and running. I seem to remember the Boehm GC was pivotal in getting Maru to bootstrap and then run Nile.

I also vaguely remember something about getting the right Boehm GC version so that some of

> Pymetaterp is cool! I agree: Warth's work on OMeta was impressive. In some ways, Ohm feels inferior to me, though they're both good tools with lots of potential.

Thanks! I share similar thoughts about Ohm. Having a visual editor is very nice, though I tend to use breakpoints for parser debugging [1].

Edit to add that id-objmodel [2] is another STEPS project I found to be simple and useful as an idea.

[1] See, for example, "Debugging" in https://blog.asrpo.com/adding_new_statement [2] https://www.piumarta.com/software/id-objmodel/

> I ran into issues running 32-bit binaries

You could use a VM to workaround this issue no?

It seems to me that making a working demo of Frank as an open source project should be the first priority even if it runs only in a 32-bit VM, because then if the demo is interesting, you may even get help from other for "modernizing" Frank so that it runs natively.

I have a (mostly) working Frank. I have collected all the source code, papers and talks from VPRI and the Squeak and Croquet research community, several TB but it needs to be organised. Volunteers? morphle at ziggo dot nl. I'm working on a many core processor for FPGA, ASIC and Wafer Scale Integration to run all these bytecoded VM's and GUI's.

Can you link to both the Maru community and the reborn Nile work? I've always tried to follow the latter, but [1] seems to be the only place to find information and it's been silent for a long time.

[1] https://github.com/damelang/nile/issues/3

Maru development is documented on an active mailing list.[1]

Dan did a demo of a related language to Nile at Oracle Open World in September 2019. (Full disclosure: I worked on the demo.) I would predict that more information will be forthcoming about Nile this year.

[1] https://groups.google.com/g/maru-dev

[2] https://www.oracle.com/openworld/on-demand.html?bcid=6092429...

Can you publish what you have collected?

I plan to: a working system. That seems to be true to the spirit of STEPS, VPRI and Alan Kay himself.

My collection needs to be reorganised so we can publish it. You can help us do that. morphle at ziggo dot nl

Thank you, funnily enough this lead me back to the orange website:

"STEPS Toward the Reinvention of Programming, 2012 Final Report Submitted to the National Science Foundation (NSF) October 2012"

https://news.ycombinator.com/item?id=11686325

The 'Word' equivalent was called Frank but AFAIK nobody has been able to reproduce what was demonstrated..

Quite painfully ironic for a software research project that they didn't use properly a VCS..

They did use VCS, actually, but a lot of them used SVN and each person in the STEPS project was hosting their own code. Most of those servers have gone dark now, though you can find random ports over to GitHub (rarely with the version history). As far as I can tell, Dan Amelang and Alex Warth were the only two who used git or moved their code over to git.

See:

https://en.m.wikipedia.org/wiki/Ometa (including reference section)

Or go to: http://www.vpri.org/writings.php

If I recall correctly you want: "STEPS Toward the Reinvention of Programming, 2012 Final Report Submitted to the National Science Foundation (NSF) October 2012" (and earlier reports)

Discussed on hn: https://news.ycombinator.com/item?id=11686325

And: https://news.ycombinator.com/item?id=585360

Notable for implementing tcp/ip by parsing the rfc.

"A Tiny TCP/IP Using Non-deterministic Parsing Principal Researcher: Ian Piumarta

For many reasons this has been on our list as a prime target for extreme reduction. (...) See Appendix E for a more complete explanation of how this “Tiny TCP” was realized in well under 200 lines of code, including the definitions of the languages for decoding header format and for controlling the flow of packets."

(...)

"Appendix E: Extended Example: A Tiny TCP/IP Done as a Parser (by Ian Piumarta) Elevating syntax to a 'first-class citizen' of the programmer's toolset suggests some unusually expres- sive alternatives to complex, repetitive, opaque and/or error-prone code. Network protocols are a per- fect example of the clumsiness of traditional programming languages obfuscating the simplicity of the protocols and the internal structure of the packets they exchange. We thought it would be instructive to see just how transparent we could make a simple TCP/IP implementation. Our first task is to describe the format of network packets. Perfectly good descriptions already exist in the various IETF Requests For Comments (RFCs) in the form of "ASCII-art diagrams". This form was probably chosen because the structure of a packet is immediately obvious just from glancing at the pictogram. For example:

  +-------------+-------------+-------------------------+----------+----------------------------------------+
  | 00 01 02 03 | 04 05 06 07 | 08 09 10 11 12 13 14 15 | 16 17 18 | 19 20 21 22 23 24 25 26 27 28 29 30 31 |
  +-------------+-------------+-------------------------+----------+----------------------------------------+
  |   version   |  headerSize |      typeOfService      |                     length                        |
  +-------------+-------------+-------------------------+----------+----------------------------------------+
  |                     identification                  |  flags   |                  offset                |
  +---------------------------+-------------------------+----------+----------------------------------------+
  |       timeToLive          |         protocol        |                    checksum                       |
  +---------------------------+-------------------------+---------------------------------------------------+
  |                                               sourceAddress                                             |
  +---------------------------------------------------------------------------------------------------------+
  |                                             destinationAddress                                          |
  +---------------------------------------------------------------------------------------------------------+

If we teach our programming language to recognize pictograms as definitions of accessors for bit fields within structures, our program is the clearest of its own meaning. The following expression cre- ates an IS grammar that describes ASCII art diagrams."