Live data from Hacker News

Gallery of programming UIs

docs.google.com

111–120 of 124 posts

Re: Gallery of programming UIs

#111
post #83
post #44

Earlier quoted context omitted.

They should have used a Lambda-function for scaling. It's only code in a zip-container.

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.

Re: Gallery of programming UIs

#112

Lively! 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

Re: Gallery of programming UIs

#113

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.

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.

Re: Gallery of programming UIs

#114
post #42
post #24

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_lo…

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 :-)

Re: Gallery of programming UIs

#115

Lively! LivelyKernel (2008): https://www.lively-kernel.org/ lively.next (2017): https://lively-next.org cloxp (2015): http://cloxp.github.io/cloxp-intro.html

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.

Re: Gallery of programming UIs

#116

Lively! LivelyKernel (2008): https://www.lively-kernel.org/ lively.next (2017): https://lively-next.org cloxp (2015): http://cloxp.github.io/cloxp-intro.html

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.

Re: Gallery of programming UIs

#117
post #13

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! Unfortuna…

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.

Re: Gallery of programming UIs

#118
post #32

It's missing the highly influential Delphi, which was the precursor to .NET

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.

Re: Gallery of programming UIs

#119
post #24

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_lo…

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.

Re: Gallery of programming UIs

#120
post #108

Earlier quoted context omitted.

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.

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.
Post reply on HN