Expected to see TUI (Terminal UI) IDEs here (the likes of DBase/Foxbase/Foxpro/etc). Disappointed, because they were hugely used "programmer interfaces" for a long time and influenced GUIs when they came up.
Heck, a lot of retail TUIs still run on them (and some of them are in process of being changed to "web apps" bypassing desktop apps). They were yesterday's full stack (design a database, build forms, run CLI commands, write OO code, package and distribute - all in one shell).
I think the post should be titled "programming GUIs" and not "programming UIs".
I think Terminal UIs are under-valued. When well-designed, they enable a great combination of efficiency of operation and visibility of the model of the system.
`tig` is a good example of this for viewing info about a git repo, though I'd be interested in hearing others.
I love tig and use it for staging/unstaging lines/chunks.
Another tool I'd recommend (although I don't tend to use it so much now) is lnav, which makes jumping around/searching log files really straightforward http://lnav.org/
Yes, you still see them in general stores, etc. in India and I bet in other countries as well. The speed of data entry and operations of those apps by operators well-versed with using them, blows any GUI apps our of the water. Not that I dislike GUIs, they are fun to build and use, but talking here about business benefits. And of course it is not all black and white, there are other benefits of GUIs too.
Some were/are written in compiled XBASE versions like Clipper, so speed of loading and running (apart from speed of operator use) is good too.
Indeed. Visual Basic for DOS was a mind-blowig discovery for me as a retro-loving kid that was coding VB6 for Windows while playing mostly DOS games. I wish something alike (though based on a modern language like Python) existed today letting us create modern cross-platform TUI apps visually...
Wow, "create modern cross-platform TUI apps visually" - I think you're onto something here. I'm not totally convinced on the "visually" part, but I love the idea of cross-platform apps with text-based user interface.
Is there a conceptual difference between GUI and TUI? Same UI elements, only represented by different technical means. CLI is different, but CLI does not have to be text-only.
TUIs are pretty much driven by keyboard input. GUI's are mostly mouse oriented. That's a big difference.
I have seen people use terminal data entry applications (mostly using the NumPad part of keyboard) with such speed/accuracy, no one using a GUI/Mouse will be able to match.
Currently, Google Drive is telling me: "Wow, this file is really popular! It might be unavailable until the crowd clears. Try again." (Page title: "Too Many Requests")
I didn't even know Google Drive had a throttling mode.
> I didn't even know Google Drive had a throttling mode.
Google Docs (docs, spreadsheets, and presentations) is designed for collaborative editing. It scales really well to lots of docs; it scales to a decent number of people collaborating on a single doc.
If many people want to simply view a single document, use the "publish" menu item. It's more restrictive (iirc, it doesn't show chat, comment threads, document history, or live updates) but AFAIK has no limit on how many people can view at once.
To be fair, Google Docs' core offering is live collaborative editing, not 'being a CDN'. Sure, there are ways they can support each at different times if they really wanted to, but it seems perfectly reasonable for them to say that when it gets to an N that they'd have to put significant engineering effort into supporting, that that's not what it was designed for, and that if someone wants CDN behaviour do that they can always export the document and put it on an actual CDN
The user data is tied to the location of the data center. the files may not be replicated past the most proximal location for his use. Regular performance/networky issues then come into play.
I'm missing a lot of the ones I used. Though most of them weren't that different from normal texteditors in a terminal. Well, they were actually editors in a terminal...
Jonathan Edward's research has explored novel ways of programming, so naturally this selection is going to be more focused on atypical interfaces. Those environments that you used are very similar to current programming systems, and so they probably don't make the cut of being thought provoking and informative to look at in 2018. Beyond the historical curiosity and nostalgia, that is.
The Wikipedia page doesn’t really give any impression of what it’s like to program in RPG with SEU, and with SDA. I wouldn’t say they’re very close to using vi or Emacs at all.
I have very bad memories of STOS BASIC, mostly around how very slow it was.
The RPG we used was column based, Flag number in this column, command in that column and so on. We used paper to do the program and then keyed in on a terminal emulator running on a ps/2 that was connected to the central computer over a modem. When running programs they got put in a batch queue and we had to wait until it was our turn and then the printer started spitting out the resulting data. You made sure to think before running things :-)
For the record, in 1997 it was still DrScheme - it wasn't renamed to Racket until 13 years later. And it didn't run on OS X, because OS X was still 4 years away. Also, IIRC, most the really interesting UI that features in that screenshot didn't exist yet - it was just the file editor on top and the REPL on bottom.
I don't think that this is prioritizing degree of influence, particularly for popular programming systems. Jonathan Edward's research has explored novel ways of programming, so naturally this selection is going to be more focused on atypical interfaces.
It is mind-blowing when you have some sort of idea of how complex an endeavor it is to create programming IDEs and UIs, and to see in one document how many man-hours must have gone into them and their iterations over the years.
This is also something that I find very impressive. Everywhere you look, the same thought comes up. All these buildings in the city have been built by someone sometime with so much effort. Then again, I think: maybe not so surprising after all if you consider that 100bn humans have ever lived. That’s a lot of man-hours available there
Readit News
Heck, a lot of retail TUIs still run on them (and some of them are in process of being changed to "web apps" bypassing desktop apps). They were yesterday's full stack (design a database, build forms, run CLI commands, write OO code, package and distribute - all in one shell).
I think the post should be titled "programming GUIs" and not "programming UIs".
`tig` is a good example of this for viewing info about a git repo, though I'd be interested in hearing others.
Another tool I'd recommend (although I don't tend to use it so much now) is lnav, which makes jumping around/searching log files really straightforward http://lnav.org/
Each time one has to look at the screen to target with mouse or touch it becomes slow.
This all can be done with a GUI as well, as long as one doesn't create too many windows, where the user has to find the correct window all the time.
Don't forget the classic DOS IDEs, such as QBasic or Turbo Pascal / Turbo C. The latter were based on a very nice framework named "Turbo Vision".
https://www.freepascal.org/
I use it for writing small command-line utilities sometimes, and it's great to work in. The EXEs created are also quite small.
It's also supposed to be quite cross-platform, supporting (maybe with some limitations) many more platforms than just Windows and Linux.
>Heck, a lot of retail TUIs still run on them
Yes, you still see them in general stores, etc. in India and I bet in other countries as well. The speed of data entry and operations of those apps by operators well-versed with using them, blows any GUI apps our of the water. Not that I dislike GUIs, they are fun to build and use, but talking here about business benefits. And of course it is not all black and white, there are other benefits of GUIs too.
Some were/are written in compiled XBASE versions like Clipper, so speed of loading and running (apart from speed of operator use) is good too.
I have seen people use terminal data entry applications (mostly using the NumPad part of keyboard) with such speed/accuracy, no one using a GUI/Mouse will be able to match.
I didn't even know Google Drive had a throttling mode.
Google Docs (docs, spreadsheets, and presentations) is designed for collaborative editing. It scales really well to lots of docs; it scales to a decent number of people collaborating on a single doc.
If many people want to simply view a single document, use the "publish" menu item. It's more restrictive (iirc, it doesn't show chat, comment threads, document history, or live updates) but AFAIK has no limit on how many people can view at once.
Right. That seems like something from the era of 1990s hosting services with very limited capacity.
Cobol on an IBM AS/400
RPG also on an IBM AS/400 https://en.wikipedia.org/wiki/IBM_RPG
Devpac Assembler https://en.wikipedia.org/wiki/HiSoft_Systems
STOS Basic https://en.wikipedia.org/wiki/STOS_BASIC
PLC https://en.wikipedia.org/wiki/Programmable_logic_controller
There were some interesting "multimedia authoring systems" on the Amiga which might warrant inclusion, such as Amiga Vision (https://www.youtube.com/watch?v=u7KIZQzYSls) and Scala (https://www.youtube.com/watch?v=k20Wvlqb96g)
http://www.hollywood-mal.com/screenshots.html
I have very bad memories of STOS BASIC, mostly around how very slow it was.
For the record, in 1997 it was still DrScheme - it wasn't renamed to Racket until 13 years later. And it didn't run on OS X, because OS X was still 4 years away. Also, IIRC, most the really interesting UI that features in that screenshot didn't exist yet - it was just the file editor on top and the REPL on bottom.