Even though the UI's are largely text, in some ways they make a greater effort to communicate with the user than many of today's "best practices."
In this case, it's both big things like the verbosity of the command responses, and little things like the beautiful font with its crossed sevens. More information above the page scroll? The top of the window gets a jagged edge like a torn piece of paper. (The anti-skeuomorphic crowd should avert its eyes.)
Also notice how technical information is expressed in human terms. How much memory is left? 11,334 "words." I know that a word can also be a technical term, and I don't know if that's the context being used here, but there were other programs of the era that translated bytes into human-thinkable words, so it's possible that this is doing the same.
Along those same lines, notice how an unknown or unexpected time is expressed as "forever" and not %NAN% like I see everywhere from airport status boards to AppleTV. It reminds me of AmigaDOS, which in directory listings could report file access as "Yesterday at 6pm" or "Tuesday at 1:35am." This could even be extended. My friend's A1000 showed file dates like "Last Christmas."
It's a kind of attention to detail that is missing in higher systems today, even though today's machines have far more horsepower to make it happen.
However "about an hour ago", "last week", "a few years ago", etc. is really annoying in e.g. IM software or file managers. I always have a clock on my screen, and I much prefer having an exact timestamp from which I can quickly determine as much information as I need.
The notable exception to this preference is using the "halfling" mode of KDE Fuzzy Clock (and clones) where the current time appears as, for example "Second Breakfast".
In addition to what you mention, it screws up archival uses if you're not diligent - copy/paste or screenshot something, and if the date is at all contextually relevant... well, it isn't any more.
It depends on your use case. Not everyone needs the kind of granularity that comes with the usual directory listing.
For me, the older the file, the less granular I need the date shown. "Christmas Eve 2012" is a more useful date to me than "2012-12-25T01:42:09+00:00."
How is modern Emacs in that regard?
Thanks for the hint.
A list of differences: https://bitbucket.org/mituharu/emacs-mac/src/f3402395995bf70...
> Official repository: https://bitbucket.org/mituharu/emacs-mac/overview
> This is "Mac port" addition to GNU Emacs 26. This provides a native GUI support for Mac OS X 10.6 - macOS 10.15. Note that Emacs 23 and later already contain the official GUI support via the NS (Cocoa) port. So if it is good enough for you, then you don't need to try this.
> If you'd like to install with Homebrew, please
$ brew tap railwaycat/emacsmacport
$ brew install emacs-mac
if you using cask
brew cask install emacs-mac or brew cask install emacs-mac-spacemacs-icon
To disable this tap, please:
$ brew untap railwaycat/emacsmacport
I believe there is a devolutionary effect in technology, it has been observed multiple times, which can be summarily described such that even though new technology supplants older tech, older tech still works: this serves only to frustrate the kids into making newer tech/redefining work.
Old machines don't really become less useful: the users needs change.
We can learn things from old, perfectly working tech. But around the edges of the zeitgeist, a lot of great old well worked and worn things get forgotten in the rush to new shine ..
One ubiquitous example is when a web page asks for a phone number and it requires the input to be in a specific format. Considering how simple it is for a computer to strip out non-numeric information and reformat a string, this is mind-numbingly annoying to me.
The more rigid/precise but also guided the input, the less errors and misunderstandings can happen. The trade-off is very small and comes down to a very minor annoyance and in some cases there are only upsides because a more guided experience can be more convenient.
Of course, if the user doesn't succeed in entering a phone number when asked for a phone number, the user will probably need to confront that fact eventually (or fail to achieve what he or she set out to achieve) but it doesn't have to be during the typing into the field.
In fact, that is how web forms worked in the early and mid 1990s IIRC, and I have second-hand information that it was easy to get random users to interact productively with a web form during those years compared to how easy it was to get them to interact productively with other UIs, e.g., a form implemented in Windows 95.
Speaking of the 500, it says, "There was one task from that era you almost certainly wouldn’t have done on your Amiga though, and that was connect it to the Internet... Later Amigas received Internet abilities..."
The first Amiga was the A1000 — two years before the 500 — and was perfectly capable of internet communication. It's where I first saw a web browser. Sure, the connection was dialup, but so was everyone's back then.
The best IDEs today have incorporated bits and pieces of these ideas but nobody has put it all together in one seamless box the way the Lisp Machines did. I really miss that experience.
It's still a work in progress, but a lot of progress have been made recently. What is really needed is more applications, and we invite anyone who's interested to play around with it and perhaps build something for it.
I have implemented a user interface for Maxima that uses McCLIM, taking advantage of many of the same features shown in the original post: https://github.com/lokedhs/maxima-client
If you just want to see what it looks like, here's a video: https://peertube.mastodon.host/videos/watch/df751bd5-5a26-44...
I guess this blurs into the user experience. The interface, which McCLIM is based on, gives a lot of the widgets and interaction modes you need for something like a Lisp machine experience, but you really need your entire development and end-user environment to be built up with the above points as well.
I kind of try to illustrate that in the video I linked. Every object is that is displayed is a Lisp object such as the individual parts of Maxima expressions. You can see the underlying Lisp expression after the Lisp listener window is opened.
One major component that is missing is a good editor that takes advantage of all of this. There is Climacs, which is actually quite powerful but it has issues. There is also other efforts, including one by myself but nothing is really ready for production. This is an area where some interested developers could make a huge difference.
Built with reasonably recent McCLIM and SBCL. At one point, had it running under CCL on one of my Raspberry Pi boxes (the 3, I think). Would have made a cool pocket, ersatz LispM.
Yeah, I know it's a mess. With the exception of updating the calls to the inspector just now (in case anybody tried to build it), it's just as I last left it a few years ago - with the proverbial hood open, subsystems not really working, and parts lying all over the floor.
One idea has been to use a common low level interface such as SDL to implement a backend, which would then be very easy to get to work on Windows. Like you said, some Windows developers would have to provide input as to which one would be the most appropriate.
Note that sbcl is just another Common Lisp implementation, you could use others as well.
A big reason for that is its X dependency and focus on X/Linux as the prime development platform rather than a cross-platform base by default. Other projects (Pharo, Squeak, Factor IDE) have done a much better job at tackling similar issues.
Under the hood the MacIvory implements a Front-End Processor to mimic their workstations. It's a multistage boot: boot the Mac, start the FEP ("Breath of Life"), start Genera. Oddly, while the FEP on real Symbolics boxes is a 68K, the MacIvory CPU handles it directly, sort of like a bootloader.
There's a nice memory dump here: http://fare.tunes.org/LispM.html
The MacIvories and UX-series embeddable systems run FEP from their ROMs, but both FEP and OS on those use "Embedded" hardware model, where they use a memory-based buffer to provide "stream" used to communicate with "Life Support" software.
The VLM (Ivory rev5) systems, aka OpenGenera, don't have proper FEP (only a lisp debugger image) and in their case the LifeSupport application contains an embedded CPU implementation and implements loading of world files directly (thus bypassing the main purpose of FEP)
I was introduced to the TI Explorer for a project in 1987 and really enjoyed working in the environment.
That has been release a long time ago.
It's yet another "past did it better".. I tried to make it poetically naive.
a) hypercard integration (HyperIvory)
b) the lisp cons cell icon where one cell points to the apple logo
Now try that with Flutter.
We could surely build an execution environment (which is what this is) with some other of the newer languages, broken as they may or may not be.
Languages can vary on top of that.
There was even support for C, good enough that there's a demo video of libpbg being compiled and used.
It shows a debug session where C code running on the lisp machine (VLM in this case, unknown variant of the VLM though) is debugged to fix JPEG decompression error.
The Original Java Utopia, the world dreamed up by Sun where Java Applets would abolish the Windows desktop and the JVM would obsolete platform dependence, was a shadow of this idea with a fundamentally more static language, and one more like Smalltalk than Lisp.
But with Java we've already lost the thread of an active environment, one which is responsive to on-the-fly reprogrammability and deep inspection. Maybe it could be done in terms of the JVM, but Java never seems to be used that way.
Dunno what happened to Visix, but there were a few other similar style IDE's in the works in the 90's ..
One of the worst parts is that you don't do web development in the web browser itself.
It lacks lots of features to get there:
- you can't dwell into the browser internals (or modify them), and the internals aren't written in Js.
- you can't save the running state of the system to disk
Then the development experience still exists when using commercial Common Lisps, and Smalltalk provides also such full stack and interactive experience.
I mean, Unreal Engine Editor is pretty close to having a lot of the mechanics right, in terms of a parallel/similar implementation.
Perhaps its just not in the nay-sayers view, or there's a disagreement about what the interface/execution environment 'really' is. Anyway, with its management of C++ builds, UE could probably be pushed to compete with this rig.
I disagree a bit with commercial Common Lisps. It's been a while since I used one (Allegro, Lucid), but I never felt they were full-stack integrated in the way that Genera was. Maybe though that's just nostalgia 25 years down the line and I'm remember that it "wasn't Genera". They were a fine environment to work in.
Smalltalk...I think you got me there. There were/are some very nicely integrated Smalltalk environments. Good point.
Only with Smalltalk. And then, Common Lisp has a more powerful OOP system and usually runs faster.