4 ms·

Chiming in a bit late here, but for years I have said that there are really only two kinds of UI that I want: a cli REPL (maybe with something like ncurses), an

by hyperion2010 9y ago

Chiming in a bit late here, but for years I have said that there are really only two kinds of UI that I want: a cli REPL (maybe with something like ncurses), and a full powered 3d game engine. Everything else in between is going to be a poorly implemented version of one or the other of those two, so just pick which end of the spectrum you want to be on for the purposes of rendering and user interaction, and build your browser apps like cli/ncurses, or implement them inside of quake3 and force your users to login by learning how to plasma surf.

throwaway613834 9y ago
How in the world would a UI like that of (say) Microsoft Word be a "poorly implemented version of a CLI REPL or a 3D game engine"?
- kuschku 9y ago
  MS Word has a full 3D engine for text effects.
  - throwaway613834 9y ago
    Sure, and you can type text with it just like in a CLI. But how does that support the claim, is the question.
    - kuschku 9y ago
      I’m not sure, I just hoped maybe providing some context may shed some light on it.
- hyperion2010 9y ago
  I guess I mean poorly implemented not in the sense that they don't work (early 90's word is an engineering marvel) but the sense that in order to get them to work you are left with enormous amounts of baggage that will come back to haunt you in the future. The 'classic' windowing toolkits and WYSIWYG implement the 2d portion of a 3d engine using a whole bunch of really cool hacks (necessary at the time) in order to run efficiently on a 286. Now days GPUs give us the luxury of not really having to worry about the cost of repainting the screen. The way QT, gtk, windows, etc. implement their interaction paradigms redraw/etc can all be subsumed by a 3d engine, and when it comes time to say, render a 3d graph inside of a hypertext document, then you don't face the huge abstraction impedance mismatch of having to drop into opengl because nothing else exits. I'm not saying that you don't need the constructs that were developed to build the classic 2 interaction paradigms, in fact you will find most if not all of them recapitulated in every 3d engine. The point is that 3d engines are essentially the logical end of any input/rendering loop you can imagine and if you develop tools long enough the infrastructure and abstractions they provide will eventually be needed and if you were using a 3d engine from the start then you won't have to implement all that functionality from the beginning, usually without the benefits of decades of experience and tens of millions of users banging on your code. To give a more concrete example -- think about how much it still sucks trying to get multimedia or good user interaction _inside_ of a word document. If word were implemented on top of a good 3d engine, then when you get the digital version of a paper the 2d projection graph is now suddenly trivial rendered because that is how it was created in the first place and the document format and editor have those capabilities from the start. Somehow this reminds me of the first programming I ever really did in Squeak [0]. 0. http://squeak.org/ http://squeak.org/
slfnflctd 9y ago
One of the first things new computer users latch on to (including myself, long ago) is their graphical capabilities, and one of the first things budding geeks learn - which was once even more true than now - is that there is a vast array of incompatible dedicated hardware and software used for them. This disincentivizes learning, as no one wants to spend a bunch of effort acquiring knowledge that is useless in the future. If everyone was using a similar 3D engine on similar hardware (or with the hardware abstracted away) for everything non-text, with comparable libraries, they could just jump in and start learning how to manipulate the graphical environment immediately as children, and build on those same methods anywhere they went for a lifetime. [The 2D stuff would obviously be a subset.] It would dramatically increase efficiency of all graphical development across the board. Also, it became apparent to me very early on that windowed GUI environments were inherently less productive and reliable for common tasks than "something like ncurses" as you say (the old AS/400 interfaces come to mind, a great many of which are still in use for good reason). The 2D GUI interface is much more finicky & time consuming to design properly, as well. In short, I couldn't agree more. One of the biggest frustrations I have with the entire field is how much time is wasted on counterproductive efforts. How many man-hours have been flushed away on 'perfectly aligning' graphical text boxes that never needed to be graphical in the first place? I understand how this is driven by underlying economic & social dynamics, but it's still galling.

throwaway613834 9y ago

How in the world would a UI like that of (say) Microsoft Word be a "poorly implemented version of a CLI REPL or a 3D game engine"?

kuschku 9y ago
MS Word has a full 3D engine for text effects.
- throwaway613834 9y ago
  Sure, and you can type text with it just like in a CLI. But how does that support the claim, is the question.
  - kuschku 9y ago
    I’m not sure, I just hoped maybe providing some context may shed some light on it.
hyperion2010 9y ago
I guess I mean poorly implemented not in the sense that they don't work (early 90's word is an engineering marvel) but the sense that in order to get them to work you are left with enormous amounts of baggage that will come back to haunt you in the future. The 'classic' windowing toolkits and WYSIWYG implement the 2d portion of a 3d engine using a whole bunch of really cool hacks (necessary at the time) in order to run efficiently on a 286. Now days GPUs give us the luxury of not really having to worry about the cost of repainting the screen. The way QT, gtk, windows, etc. implement their interaction paradigms redraw/etc can all be subsumed by a 3d engine, and when it comes time to say, render a 3d graph inside of a hypertext document, then you don't face the huge abstraction impedance mismatch of having to drop into opengl because nothing else exits. I'm not saying that you don't need the constructs that were developed to build the classic 2 interaction paradigms, in fact you will find most if not all of them recapitulated in every 3d engine. The point is that 3d engines are essentially the logical end of any input/rendering loop you can imagine and if you develop tools long enough the infrastructure and abstractions they provide will eventually be needed and if you were using a 3d engine from the start then you won't have to implement all that functionality from the beginning, usually without the benefits of decades of experience and tens of millions of users banging on your code. To give a more concrete example -- think about how much it still sucks trying to get multimedia or good user interaction _inside_ of a word document. If word were implemented on top of a good 3d engine, then when you get the digital version of a paper the 2d projection graph is now suddenly trivial rendered because that is how it was created in the first place and the document format and editor have those capabilities from the start. Somehow this reminds me of the first programming I ever really did in Squeak [0]. 0. http://squeak.org/ http://squeak.org/

slfnflctd 9y ago

One of the first things new computer users latch on to (including myself, long ago) is their graphical capabilities, and one of the first things budding geeks learn - which was once even more true than now - is that there is a vast array of incompatible dedicated hardware and software used for them. This disincentivizes learning, as no one wants to spend a bunch of effort acquiring knowledge that is useless in the future. If everyone was using a similar 3D engine on similar hardware (or with the hardware abstracted away) for everything non-text, with comparable libraries, they could just jump in and start learning how to manipulate the graphical environment immediately as children, and build on those same methods anywhere they went for a lifetime. [The 2D stuff would obviously be a subset.] It would dramatically increase efficiency of all graphical development across the board. Also, it became apparent to me very early on that windowed GUI environments were inherently less productive and reliable for common tasks than "something like ncurses" as you say (the old AS/400 interfaces come to mind, a great many of which are still in use for good reason). The 2D GUI interface is much more finicky & time consuming to design properly, as well. In short, I couldn't agree more. One of the biggest frustrations I have with the entire field is how much time is wasted on counterproductive efforts. How many man-hours have been flushed away on 'perfectly aligning' graphical text boxes that never needed to be graphical in the first place? I understand how this is driven by underlying economic & social dynamics, but it's still galling.