Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Acme focuses entirely on the idea of text as user interface

Sounds a little like Oberon. I wonder how many people have used both.



If you read the acme[1] paper you will see Rob Pike explicitly acknowledges the influence of Oberon.

This can be seen even more clearly in Acme's more direrect predecessor: help[2]

[1]: http://doc.cat-v.org/plan_9/4th_edition/papers/acme/

[2]: http://doc.cat-v.org/plan_9/1st_edition/help/


Thank you. I didn't know there was a direct influence. It's intriguing, because the two cultures share a similar design style: "aggressive use of a small number of abstractions" as Ken Thompson put it. I like that design style.


From the comments -

Rob Pike (about 2 hours ago) : What Russ doesn't stress enough is the major thing Acme brought, beyond what it borrowed from Oberon etc.: the contextual right click. One button click gets what I want, be it the next appearance of a word, the line the compiler's complaining about, a man page, a PDF file, a UPS delivery notice, whatever. If the data's here, jump the mouse to the location (another thing Russ didn't point out) and highlight it. If it's not there, load it and jump to it.

One click, context-driven. It's hard to appreciate how powerful and effective that is without trying it.


I think the line of descent is Cedar -> Oberon -> Acme.

My Oberon usage was quite a while ago (really liked the system, although it was a bit impractical). The big difference being the object-/module-oriented nature of it, as compared to acme's Unix text piping.

Oberon's System 3 is a pretty decent example of transitioning from a text-based environment to a richer GUI, by the way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: