Hacker News Reader

Comment by rer | Hacker News Reader

How would you do GUIs to make them compose, script, and show the kind of info CLIs can?

This is what I like about user interfaces in Emacs. They are richer than command line interfaces as you have programmatic access to values (this gives you composition and scripting), yet they also hide information in their graphical representation bringing them closer to GUIs.

(Compared to well-designed GUIs Emacs interfaces aren't very pretty, though.)

I'd point to the work done on tangible UIs and programming environments for that.

For example, the work on tangible UIs eg- Self: http://www.selflanguage.org/

This is a good demo of what could be done in the Self environment: https://www.youtube.com/watch?v=Ox5P7QyL774

GUI and non-programmability are tangential things. I don't think they're implicitly bound together.

However, GUIs are implicitly more complex than text steams. Sure, they can be programmable, and conposable, but it's an uphill battle, and CLI just does it so effortlessly.

The CLI only does so effortlessly because of all the work done to make it effortless. Pipes, string formatting, argument parsing. If the same amount of work was put into a direct manipulation GUI as was put into unix, it would be just as effortless, if not more.

Why are terminals still based on the concept of a teletype? It is fully one dimensional. You have to fit all interactions through that one dimension. (Multiple terminal windows are a kind of hyperspace, I suppose.)

And that one-dimensionality is exactly what makes it easy to compose.

Multiple terminal windows are a kind of hyperspace, I suppose.

If only if you could easily pipe from one terminal to another.

Named pipes[1] will do that for you.

[1] http://www.linuxjournal.com/content/using-named-pipes-fifos-...

I have recently found myself pondering what would have happened if a micro computer back in the BBS days could have handled access to multiple BBSs at the same time. My suspicion is that we would be looking at something very similar to what a multi-tab web browser is giving us these days.

Mmm I don't know. Self looks like yet another overdesigned thing at 100k+ lines of code that doesn't compile. After 3 mins on the site, I can't figure out the main thing it does.

Sure, the adaptive compilation is nice, and message sends and type inference, but how well do the UIs work?

It's sort of cool to see Urs Hölzle and Craig Chambers in the papers section.

http://bibliography.selflanguage.org/_static/urs-thesis.pdf

I mean, it is almost 30 years old, so you have to take that into consideration. A lot of stuff had to be built from scratch.

As for what it "does", what does the smalltalk environment do? It's a combination of a programming language with graphical programming tools. It does anything it is programmed to do.

Self is the language that invented prototypical inheritance and the Morphic UI framework, one of which (morphic) is now used in pretty much all modern Smalltalks, and the other of which (prototypical inheritance) got picked up by a little language called Javascript, which you may have heard of. In addition, Self provides provisions for multiuser networked UI, kind of like Google Docs does.

Given, it's not exactly usable for modern projects, but it's worth studying.

I didn't know this, thanks! It looks like one can have composition after all. http://ftp.squeak.org/docs/Self-4.0-UI-Framework.pdf

They can't: that's the price you pay for the abstraction. Smalltalk got the closest, but if you really want to dig into a GUI, at the end of the day, you have to read the code behind it.

Maybe I should read the code behind Smalltalk. I'm glad the day isn't over.

You mean AppleScript?

No, AS didn't do nearly as good a job as ST did.

Reply on news.ycombinator.com