Gallery of programming UIs(docs.google.com)
docs.google.com
Gallery of programming UIs
https://docs.google.com/presentation/d/1MD-CgzODFWzdpnYXr8bEgysfDmb8PDV6iCAjH5JIvaI
123 comments
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.
`tig` is a good example of this for viewing info about a git repo, though I'd be interested in hearing others.
The key part is keyboard control and training. If one knows the relevant shortcuts and codes by hand working can be quite fast.
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.
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.
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/
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/
*> TUI (Terminal UI) IDEs here (the likes of DBase/Foxbase/Foxpro/etc).
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".
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".
my first programming class (high school, 2008) used Borland Turbo Pascal. it was honestly a very pleasant user experience.
Free Pascal is one successor of Turbo Pascal which is still very fast and nice to work in. It has a TUI.
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.
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.
And, later, Borland C++. I still have fond memories of that blue-green screen.
Good points.
>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.
>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.
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...
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.
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.
GUIs normally support keyboard navigation and TUIs can often use mouse. Some application may support keyboard poorly, but that would be the problem with that particular application, or GUI toolkit it uses, rather than the general GUI/TUI distinction.
right, what did Linus Torvalds use? Emacs or Vim?
Customized version of MicroEmacs: https://en.wikipedia.org/wiki/MicroEMACS
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.
> 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.
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.
I didn't even know Google Drive had a throttling mode.
Right. That seems like something from the era of 1990s hosting services with very limited capacity.
Right. That seems like something from the era of 1990s hosting services with very limited capacity.
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.
They should have used a Lambda-function for scaling. It's only code in a zip-container.
Scaling they code they can easily. The issue is with collaborative editing and keeping everybody in sync - which is the job of Google docs.
Google should have used Amazon's cloud? Really? They have one of their own.
The suggestion was a jab at another HN hype story, from yesterday.
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
wow so a platform with a robust sharing capability is not designed for certain 'types' of sharing. So the user has to be aware the internal implementation of each google cloud service and use them accordingly. I say this scenario is acceptable for a startup offering. Not so for one of the most concentrated comp sci engineering org.
Additionally, this is Google Slides. So sharing is inherent in the name of the product
Additionally, this is Google Slides. So sharing is inherent in the name of the product
TIL, Google Drive built on the Geocities platform.
Our firewall blocks it for some reason.
As requested, here is a PDF: https://drive.google.com/file/d/1RPX_9u01MEU-QDWU4h-90QF9XqZ...
Thank you!
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...
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
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
The Amiga version of STOS, AMOS, was nice and quite popular. Wasn't as fast as Blitz Basic II though.
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)
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)
The modern "descendants" of the latter could be said to be Hollywood, which is alo available on non-Amiga platforms:
http://www.hollywood-mal.com/screenshots.html
http://www.hollywood-mal.com/screenshots.html
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.
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 :-)
Accuracy nitpick:
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.
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.
It's missing the highly influential Delphi, which was the precursor to .NET
It sure is, as well as it's powerful brother, Borland/Inprise C++ Builder, two IDEs that definitely deserve a spot on this list.
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.
Don't forget FoxPro
Impressive! However, no mention of Oberon or BlackBox; that's a serious omission.
http://fruttenboel.verhoeven272.nl/Oberon/index.html,
https://github.com/pdewacht/oberon-risc-emu,
http://blackboxframework.org/index.php?cID=home,en-us
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
No Klik & Play?! It was the reason I can say I was building and distributing my own games back in 5th grade!
No Lego Mindstorms!? I was building Robots with six degrees of freedom in middle school!
No Lego Mindstorms!? I was building Robots with six degrees of freedom in middle school!
I had Klik & Play back on Windows 3.1! (And then later The Games Factory on '95.) It was great for a little while but I rapidly got to the point where it felt like it was getting in my way rather than making things easier.
I /wish/ I'd had Lego Mindstorms, always wanted some but we could never afford it.
I /wish/ I'd had Lego Mindstorms, always wanted some but we could never afford it.
TGF was definitely what got me started in programming as a kid. Super intuitive to learn and use before I was 'ready' to use a text-based language.
Mindstorms was pretty much a variant of Scratch. Never heard of Klik&Play - I'll check it out, thanks.
Mindstorm is actually a variant of Labview (by National instruments) - which is a flow based prog environment. Different from scratch and it's clones.
The Mindstorms that I remember (~2004, on the RCX 2.0) was nothing like LabVIEW; I haven't played with Scratch, but from what people have shown me of it, it is very similar to how I remember Mindstorms.
I've taught students both mindstorms NXT and Scratch, and they're quite different. Scratch is basically procedural programming with blocks instead of text. Mindstorms has some of that, but variables/data connections are really different and wierd to get your head around if you're already a programmer. I've not used labview so can't compare to that.
This has been posted before (https://news.ycombinator.com/item?id=14290909) but I think the list has been updated since then.
It's interesting how you see the same idea pop up in different forms over the years.
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.
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.
Yes, Lazarus is decent. Others they missed from the client-server GUI tools are PowerBuilder and Gupta Technologies' SQLWindows (one of the first GUI development tools for Microsoft Windows):
https://en.wikipedia.org/wiki/Gupta_Technologies
I didn't like PowerBuilder myself. But Delphi and Visual Basic were more easy to understand and still powerful. Did some work in both.
https://en.wikipedia.org/wiki/Gupta_Technologies
I didn't like PowerBuilder myself. But Delphi and Visual Basic were more easy to understand and still powerful. Did some work in both.
Working link to (I hope) the same document: https://docs.google.com/presentation/d/1MD-CgzODFWzdpnYXr8bE...
Correct, that's the slideshow version. Let me know if that isn't working and I'll post a PDF snapshot
Should have been a PDF to start with.
Not working anymore... thanks in advance for fixing.
Please post the PDF so its downloadable
Thanks very much. Web version (incl. download links) struggles for me in primitive Australia
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
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
I still want code bubbles[1] in pretty much everything. So nice for exploring code - you don't necessarily care about whole file X, just the chain of code paths you're currently navigating.
[1]: https://docs.google.com/presentation/d/1MD-CgzODFWzdpnYXr8bE...
[1]: https://docs.google.com/presentation/d/1MD-CgzODFWzdpnYXr8bE...
Lively!
LivelyKernel (2008): https://www.lively-kernel.org/
lively.next (2017): https://lively-next.org
cloxp (2015): http://cloxp.github.io/cloxp-intro.html
LivelyKernel (2008): https://www.lively-kernel.org/
lively.next (2017): https://lively-next.org
cloxp (2015): http://cloxp.github.io/cloxp-intro.html
I wish lively.next could get some more funding or otherwise take off. It would really change how people make complex web applications
Hi Robert! I thought (perhaps incorrectly) that Lively was largely the same programming experience as Squeak, just in the browser. Do you have any screenshots showing new programming experiences in lively.next or cloxp?
Personally, I think the interaction model is closer to Self than to Smalltalk. A walk-through of building a morphic app is here: https://lively-next.org/doc/todo-list-tutorial.html
Lively also got some influence from Emacs in terms of integrating tooling and support for remote development. One example, connecting to another webpage and modifying it via lively: https://www.youtube.com/watch?v=gbp30e_QYvY. Apart from JavaScript, it is easy to integrate other languages as well, e.g. you can connect to a running Python process via https://github.com/LivelyKernel/lively.py) and then use workspaces and file editors inside of Lively to modify and run Python code. This stuff is based on a generic RPC mechanism that connects Lively worlds and other runtimes: https://lively-web.org/users/robertkrahn/2015-06-12_l2l-map.....
cloxp is following more a traditional Smalltalk-model, the core component is a system browser for Clojure namespaces.
Lively also got some influence from Emacs in terms of integrating tooling and support for remote development. One example, connecting to another webpage and modifying it via lively: https://www.youtube.com/watch?v=gbp30e_QYvY. Apart from JavaScript, it is easy to integrate other languages as well, e.g. you can connect to a running Python process via https://github.com/LivelyKernel/lively.py) and then use workspaces and file editors inside of Lively to modify and run Python code. This stuff is based on a generic RPC mechanism that connects Lively worlds and other runtimes: https://lively-web.org/users/robertkrahn/2015-06-12_l2l-map.....
cloxp is following more a traditional Smalltalk-model, the core component is a system browser for Clojure namespaces.
lively.next looks exactly like something I’ve been thinking about. How come though that the demo video shows it in use on Linux but the desktop application is macOS only?
If you don't want to run your own Lively installation locally then all it needs is a web browser.
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.
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.
At one stage on the eve journey they were showing a sort of wiki/database thing that I wanted to use very much. It seemed like it'd be fantastic for iteratively organising the kind of information you encounter in your day to day life. Unfortunately that version of eve never saw the light of day as far as I know. Does anyone know of anything that works similarly?
It's here if you want to poke at it: https://github.com/witheve/eve-experiments/tree/af13f8d5f8a5...
Amazing, thanks.
You don't have a screenshot, or any more leads on finding it do you? It sounds like an interesting concept but I'm having trouble finding an image of it.
Am I the only one who looks at the DEC VT05 from 1970 and thinks that it still looks cool? I guess it's because I was 5 or so when Space 1999 was on, and everything looked like that, but I think there's something timeless and classic about the lines of the design.
(Waits for someone from HN to say that one is still their main terminal as they eschew software terminals, etc!)
(Waits for someone from HN to say that one is still their main terminal as they eschew software terminals, etc!)
A lot of these look cool to me. I wonder how many of the environments could be brought up in a VM?
They forgot: http://move.rupy.se/file/logic.png (2005)
You can download the program here: http://rupy.se/logic.jar
You can download the program here: http://rupy.se/logic.jar
I made one in 2013 that broke documents into tiles along grammatical boundaries that could be dragged around like app icons on smart phone home screens: https://youtu.be/tztmgCcZaM4?t=1m25s
I miss WYSIWYG UI design IDE's. One can waste sooo much time fiddling with browser UI's to get it to work right on different browser brands/versions/sizes. It's a time sink that must cost the world billions. Can't we have a WYSIWYG browser standard instead of client-side-auto-flow crap?
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 ;-)
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 ;-)
How would that work? The developer would have to generate and approve a rendering for every permutation of width, height, and pixel density?
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.
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.
You have to do such testing now with JS/DOM-based resizing. The only real difference is that it's done on the server side, which simplifies things because you have only 1 rendering engine instead of say 50 client versions. And, often 2 sizes are usually fine, and 3 if you have a big audience. And it can increase the general resolution (magnification) to fill the current screen. JavaScript resizers, such as bootstrap often do similar now: you reach a threshold before they reshuffle, and in between the thresholds, they just multiply width by a constant factor to fill the screen. And bootstrap is buggy and inconsistent.
Thanks for posting this! This is the kind of content I love to see on HN.
Wow, Visual Basic... It takes me back to my AOL proggie days!
Wow, Visual Basic... It takes me back to my AOL proggie days!
If you're feeling nostalgic - just create some VBA, amazing how it's hardly changed... This picture taken from Word 2016 a few seconds ago: https://i.imgur.com/w3qX8Oa.png
Indeed VBA is a very curious phenomenon. It is cool from the retro-lover point of view (and nostalgia makes me enjoy having to code it occasionally in the real life) yet a horrible atavism from the modern developer point of view. The built-in code editor is not much smarter than Notepad is and the language itself is a ridiculous cargo-cult-level OOP imitation with no real OOP nor functional (wouldn't these be of great use in Excel?) concepts, just a slightly face-lifted QBasic capable of defining simple algorithms and interfacing native code. I can hardly understand why it still hasn't been phased-out and replaced with Python or something like that.
Because it's not for programmers, it's for IT-savvy accountants.
Yet despite all that VB6 and VBA are very productive, inexperienced users can get things done and experienced users can get things done quickly.
Why? It (VB6) was the first language I've learnt and I have had a lot of fun coding it as a kid (so I can think in it and have no bias against it) yet I don't understand how can it be considered productive or any good at all compared to Python or even JavaScript. One can probably say that Python and JavaScript are more complex and harder to learn - I would disagree: everything you can code in VBA can be coded in Python or JavaScript in the same manner, with the same simplicity and ease, conscious usage of concepts that can be considered advanced and/or tricky for non-programmers to undetsatnd is optional. What part other than the fact it doesn't ever change or that it reminds them about their childhood actually makes people like VBA?
It was the one tool there that I got a warm "man, I could crank some code with that". All the others were cognitively heavy and I could just feel the mental effort. It has a laser like focus on getting a usable app into a user's hands with minimum fuss - wysiwyg and zero pretension.
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.
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.
PSA:
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':
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':
It might be that the Google docs throttling mode might just drop those extras. Check back when it's not popular?
I think I moved the speaker notes into the body of the slides, but the doc is so swamped I can't get in to see! Perhaps I dropped some in the process. I'll look into it. If you can remember anything in particular that is missing please let me know.
I was just able to check. I unfortunately don't remember what the speaker notes said exactly, I fuzzily recall there being multiple lines.
I've searched a couple of HDDs for old copies; no go.
I've searched a couple of HDDs for old copies; no go.
A lot of grid style environments. Unless I somehow scrolled past it, the missing big one is 'Excel'.
First slide says "Not covered: spreadsheets".
Edit: however, a little more recognizion to spreadsheets would have been nice, since some of the UIs are so evidently rooted in that metaphor
Edit: however, a little more recognizion to spreadsheets would have been nice, since some of the UIs are so evidently rooted in that metaphor
They could have covered VBA.. which is available on the office suite. I still use it today for outlook and excel automation.
Not sure if this would count but I'd say some of the software that implemented Shlaer-Mellor OOA and code generation tools of the late 80s/early 90s might be included here too. Unfortunately can't find a great screenshot other than these:
https://www.edrawsoft.com/images/shapes/soft-shlaermellor.pn... https://www.edrawsoft.com/solutions/shapes/shlaer-mellor-ooa...
https://www.edrawsoft.com/images/shapes/soft-shlaermellor.pn... https://www.edrawsoft.com/solutions/shapes/shlaer-mellor-ooa...
While we saw there some Smalltalk development UIs, I was clearly missing some 'modern' Visualworks screenshot with the classic 4 slot upper part and the large code window below (similar to the System Browser on slide 3):
https://1.bp.blogspot.com/-XO7l9e-ukCI/UKSshW0IKRI/AAAAAAAAF...
https://1.bp.blogspot.com/-XO7l9e-ukCI/UKSshW0IKRI/AAAAAAAAF...
A bit of a plug, but for my senior project, my team is working bringing Patchworks (slide 80) to Atom. It's currently not open source (but will be after completion of the project). We are working with an author of the original paper. http://austinhenley.com/pubs/Henley2014VLHCC_Patchworks.pdf
I came across the Alfa proof language recently (precursor to Epigram and Agda). Had this neat natural deduction editor: http://www.cse.chalmers.se/~hallgren/Alfa/Tutorial/ndstyle.h...
I guess if you're just trying to show interfaces and not every language this is ok... but if you're trying to show every languages interface there are tonnes missing. Here are a few I used.
HP Basic (~1974-1980ish)
Autolisp (~1986-1995)
Turing (~1989-2000)
I've never seen so many examples and variations of Jackson Structured Programming!
https://en.wikipedia.org/wiki/Jackson_structured_programming
https://en.wikipedia.org/wiki/Jackson_structured_programming
Interesting how some UIs appear to be limited either to education, end-user programming, or professional software development, and others (e.g. Smalltalk) strive to be universal and work as an integral part of the OS's user interface.
Nice set of pictures.
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.
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.
Yeah it would have been nice to see Genera. It was interesting and distinctive.
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.
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.
Hey Mikel, are the Sk8 sources/binaries anywhere? Is it possible to run Sk8 nowadays if one has access to hardware running classic MacOS?
There seems to be a copy of one of the technology releases here:
https://www.macintoshrepository.org/2625-apple-sk8
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.
https://www.macintoshrepository.org/2625-apple-sk8
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.
Apple made the source for SK8 available, and someone has posted it on GitHub:
https://github.com/waywardmonkeys/apple_sk8
https://github.com/waywardmonkeys/apple_sk8
Nice; thanks!
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.
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.
I didn't see any shell programming either...
wow Google can't even deal with a butt out cordial HN hug? Really reflects well for their cloud offerings... sheesh
Wow.. Google Drive got swamped!
No Delphi? No Visix Vibe?
[deleted]
I missed Visual Studio and C/Java Builder.
Shameless plug: https://medium.com/@kloudtrader/private-beta-and-kloudtrader...
Trying to build a better programming environment and platform for algorithmic trading
http://KloudTrader.com
Trying to build a better programming environment and platform for algorithmic trading
http://KloudTrader.com
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".