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".
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.
Additionally, this is Google Slides. So sharing is inherent in the name of the product
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
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)
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.
No Lego Mindstorms!? I was building Robots with six degrees of freedom in middle school!
I /wish/ I'd had Lego Mindstorms, always wanted some but we could never afford it.
Two they missed: Lazarus (based on Delphi) and Qt. I've dabbled with Lazarus, people who use it a lot tell me it's great. I use Qt professionally and it's the most enjoyable way of building GUI applications that I've found.
I didn't like PowerBuilder myself. But Delphi and Visual Basic were more easy to understand and still powerful. Did some work in both.
By the way another worth adding IMO (as it has serious industry use and traction) is Grasshopper (a plugin for Rhino) - focussed on 3d modelling. Very common in Architecture and design fields
LivelyKernel (2008): https://www.lively-kernel.org/
lively.next (2017): https://lively-next.org
cloxp (2015): http://cloxp.github.io/cloxp-intro.html
cloxp is following more a traditional Smalltalk-model, the core component is a system browser for Clojure namespaces.
If you want to run it locally via https://github.com/LivelyKernel/lively.installer then it should run well in MacOS and Linux. On Windows you might need to use a proper bash (e.g. git bash or the Ubuntu subsystem).
There is a desktop app for mac os that wraps the installer and gives you a menu bar entry for controlling the lively server but in the end it is just a frontend for what the installer does.
(Waits for someone from HN to say that one is still their main terminal as they eschew software terminals, etc!)
You can download the program here: http://rupy.se/logic.jar
Most internal work-related projects don't need "responsive" (resizing) anyhow; and the server could re-calc widget sizes & spacing if needed for small screens such that you don't need a fat client to manage flow engines. And they waste screen real-estate: WYSIWYG was more compact. I could point to the screen and tell it EXACTLY where to drag somebody off my lawn ;-)
That may have worked back when everyone was using an 800x600 CRT, but it sounds unfeasible today with so many devices and orientations to consider.
Wow, Visual Basic... It takes me back to my AOL proggie days!
Drop a button, double click, cursor will be at correct location in generated hook, write your code code, ship it. The experience in Python/js just can't compete to that.
I sure have complained about VB and for certain types of code it would be a nightmare but I've also shipped it. It gets something right that the mathematisation of programming misses time and again and is in denial that it matters.
The last time I opened this presentation there were a bunch of speaker notes with incredibly insightful additional details and trivia attached. A picture might be a thousand words, but the notes added insightful context that the picture couldn't add itself.
If anyone can get in touch with the owner of this document, please let them know the speaker notes have been lost. They really need to be re-added!
Unfortunately I didn't download a copy of the old version D':
I've searched a couple of HDDs for old copies; no go.
Edit: however, a little more recognizion to spreadsheets would have been nice, since some of the UIs are so evidently rooted in that metaphor
I say somewhat since era of main use is more important than initial year of release.
I was surprised not to see two things about Common Lisp: Symbolics's Genera UI for software engineering, and the modern Paredit editor methodology for Lisps.
It does show SK8, which, although it's not obvious from looking at it, was a Lisp environment.
It was implemented in Common Lisp--specifically Macintosh Common Lisp, which is the direct ancestor of Clozure Common Lisp--on the pre-OSX Mac system. That's sort of obvious if you look at the menubar in Slide 7.
The ScriptEditor shows a snippet of SK8Script, which was the first working implementation of AppleScript. SK8 compiled SK8Script to Common Lisp, and thence to native code. The runtime underneath was Macintosh Common Lisp, and you could open a Lisp listener window or editor window if you wanted, and work directly in Lisp.
The funny-looking window design has a practical purpose: it doesn't look like any other widely-used window design, which means that when you used SK8 to create a Mac application, the SK8 tools always looked distinct from all of the application windows that were under development.
The funny-looking windows are notable in another way: their non-rectangular outlines required a custom code resource (a WDEF), which you could write in Lisp with MCL.
As with all of the other environments illustrated in these slides, there are lots of details that are not obvious from the image. This sample screen shows someone in the middle of constructing a working giant scrollbar by snapping together boxes and arrows and editing scripts attached to them.
SK8 was very direct-manipulation-oriented. You could do a lot of stuff by dragging objects onto the screen, snapping them together, and opening inspectors to edit visual properties, event-handlers, and attached behaviors. You could grab an arbitrary screen object and drop it into a message box to get an expression that, when evaluated, yielded a reference to the dropped object.
It did a lot with containment--for example, you could put objects on the screen by adding them to a container called the Stage, and there was a containment hierarchy that routed events to handlers. The model was extremely flexible; for example, you can see in the Script Editor that the programmer wants an event to set the fillcolor of rj1 to green, but Dave Yost (one of the SK8 authors) used to like to demonstrate setting the fillcolor to a Clint Eastwood movie, which would then begin playing in the background of the targeted object.
I haven't downloaded it and looked at it.
One of the slides at that URL has Dave Yost's Clint Eastwood fillColor displayed in it. :-)
I think you can run it as long as you have a PPC machine. Perhaps one of the Mac OS emulators that emulates the PPC could do it, too, if you had the ROM files.
In case you're not familiar with ROM files, the old Mac OS, before OSX, was not really an operating system in the usual sense; it was really a large subroutine library, the bulk of which was burned into ROMs in Apple hardware. Emulators for the old Mac OS need to have working copies of the contents of those ROMs in order to run the Mac OS. ROM files are a little bit inconvenient to come by unless you have an old working Mac and a tool for copying the ROMs.
Way back in 2004 I proposed an open-source project to build a new SK8-like environment, and even got buy-in from some of the original developers and users of SK8. Then I got terribly sick and didn't work on anything at all for a couple of years. When I finally began to work again, it was with a lot less energy and ambition than I'd had before.
If you want to build it you'll need a working copy of MCL and a PPC mac. The requirements may be slightly narrower than that. SK8 had some low-level bits that might rely on some details of the Mac System version or hardware. I don't rememberenough of the details anymore, but you might need to try a few different PPC models and system versions. System 7 or 8 is probably a decent bet, as is any mac hardware that was shipped with it.
borland turbo range?
Trying to build a better programming environment and platform for algorithmic trading