5 ms·

I'm sympathetic to the GUI dream, but do note that language is far richer than pictures: we graduate from picture-books to literature, and from pointing and gru

by wtbob 11y ago

I'm sympathetic to the GUI dream, but do note that language is far richer than pictures: we graduate from picture-books to literature, and from pointing and grunting to speaking. I do think that a Smalltalk future might have actually managed to be the best of both worlds, combining images and text into one coherent whole. But it never really came to fruition. As things are, since I may not have both, I'll choose the power of text over the ease of pictures.

pavlov 11y ago
To me, the GUI dream isn't really about pictures -- it's about structure. Humans are much better at understanding visual and symbolic representations of structure than prose. Purely textual interfaces don't take advantage of that. The structure that we currently have is file hierarchies and URLs (just another form of Unix-style path strings), and files containing sequences of text with no more structure than line breaks and indentations -- and after 40 years, we haven't even agreed on how to represent those in ASCII. The whole thing is barely removed from sectors on disk. Smalltalk's class browser let you drill into a live hierarchy of objects and edit them in place. That's already much more advanced than our static blobs of text in a lifeless path hierarchy. And that was in 1975.
- Ace17 11y ago
  This wasn't without huge limitations. The image often is considered as a mistake ( http://www.ianbicking.org/where-smalltalk-went-wrong.html http://www.ianbicking.org/where-smalltalk-went-wrong.html )
- woah 11y ago
  I've got to disagree, because representing everything as an object involves a serious amount of cognitive overhead. You're limiting yourself to things that can be represented as objects and still make sense, plus you've got to write the code to make your ideas fit into the object box (methods, interfaces, this, public private etc). I've been working on some networking protocols, and I started by modeling each node as an object. Seemed to make sense. But there's a lot of overhead. Send, receive methods etc etc, and then you've got to instantiate them and then collect the data from the objects afterwards to see how the network did. I switched my code over to being a bunch of stateless functions that operate on a network graph and stuff got a lot less verbose. This is not necessarily always the case, but I would hate working in an environment where I was forced to always use a very specific metaphor for my work.

by wtbob 11y ago

pavlov 11y ago

To me, the GUI dream isn't really about pictures -- it's about structure. Humans are much better at understanding visual and symbolic representations of structure than prose. Purely textual interfaces don't take advantage of that. The structure that we currently have is file hierarchies and URLs (just another form of Unix-style path strings), and files containing sequences of text with no more structure than line breaks and indentations -- and after 40 years, we haven't even agreed on how to represent those in ASCII. The whole thing is barely removed from sectors on disk. Smalltalk's class browser let you drill into a live hierarchy of objects and edit them in place. That's already much more advanced than our static blobs of text in a lifeless path hierarchy. And that was in 1975.

Ace17 11y ago
This wasn't without huge limitations. The image often is considered as a mistake ( http://www.ianbicking.org/where-smalltalk-went-wrong.html http://www.ianbicking.org/where-smalltalk-went-wrong.html )
woah 11y ago
I've got to disagree, because representing everything as an object involves a serious amount of cognitive overhead. You're limiting yourself to things that can be represented as objects and still make sense, plus you've got to write the code to make your ideas fit into the object box (methods, interfaces, this, public private etc). I've been working on some networking protocols, and I started by modeling each node as an object. Seemed to make sense. But there's a lot of overhead. Send, receive methods etc etc, and then you've got to instantiate them and then collect the data from the objects afterwards to see how the network did. I switched my code over to being a bunch of stateless functions that operate on a network graph and stuff got a lot less verbose. This is not necessarily always the case, but I would hate working in an environment where I was forced to always use a very specific metaphor for my work.