There is so much beauty in those screenshots. The more technology advances, the more elegant old machines appear.
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.
I agree completely with the first half of your post.
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[0] (and clones) where the current time appears as, for example "Second Breakfast".
Yes! I hate reverse-relative time indicators, it is absolutely an anti-pattern.
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."
The 'words' in this case are a very technical term, as they are the smallest addressable element, in this case 40bit-long - one word can contain half of a CONS cell, two or one instructions, a 32bit integer, a pointer (normal and forwarding), an extended character, and 1-4 array elements (including 4 simple characters aka ASCII).
It reminds me of Emacs. Which seems approximately a virtualized Lisp machine. The pieces that are missing, like a typeface editor could probably be hacked up (and the reason it hasn't is that most people can't design better typefaces). Emacs calendar even has a human oriented interface. http://ftp.gnu.org/pub/old-gnu/Manuals/emacs-20.7/html_chapt...
Emacs + SLIME + Common Lisp was designed to be an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a Lisp Machine. And it succeeds admirably in that intent.
Back when I was an heavy UNIX user, in search of nice IDE like features, I settled with XEmacs because the community was more open minded regarding the integration of graphical capabilities.
If you're running Mac, I suggest the railwaycat fork, which is basically GNU emacs plus some quality of life features that RMS is against like applescript/os integration, smooth scrolling and nice fonts
> 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
and then
$ 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
>There is so much beauty in those screenshots. The more technology advances, the more elegant old machines appear.
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 ..
It also feels like we've gone from a mode of thinking that computers should work for people to an era of people working for computers.
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.
We don't do this kind of thing for very good reasons.
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.
That fact nonwithstanding, users might be better served by having more "freedom of expression", e.g., by software that lets the user type any text into any field.
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.
This is what happens when very smart computer scientists and engineers sit down and build a pure developer's computer from scratch, from the hardware up. It's the most elegant IDE ever invented. It takes a while to get used to it, but once you do, the separation between programmer and computer simply vanishes and you "become" the computer. Describing the experience to a programmer who has never used it is like describing an acid trip to someone who has never done acid: It's always going to sound exaggerated or scary and thus not very interesting.
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.
Most IDEs today should really drop the "I" as they tend to be a collection of loosely connected tools rather than a truly integrated environment. In some cases that's not a bad thing, but the "I" is vestigial.
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
I think it’s wonderful to think McCLIM but it’s important to note that so much of the value of the Lisp machine’s interface is derived from (1) the OS level integration of the dynamic language, (2) the single-process aspect (everything lives in the same memory space, all objects can interact without serialization, and (3) the fact that developers thought that documentation and interaction were a true part—a first class citizen—of the development of their software.
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.
If you run everything in your Lisp image, on top of McCLIM then you have that experience.
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.
I would say you could get it, but loading up a Lisp image doesn’t give you it for free. Folks (like yourself!) need to build actual applications in CLIM, or better yet, an operating system whose UI is driven by something like CLIM.
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.
McCLIM's native Windows backend is in a very early stage of development, if not abandoned. You can use McCLIM on Windows with an X server, e.g. VcXsrv or Xming.
Since none of the McCLIM contributors use Windows, there have been very little work on a Windows backend.
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.
McCLIM is and has always been a total mess (stability, look and feel, speed, platform support, feeling of robustness) and I would definitely not recommend it, at its current state, to non-hardcore Common Lispers (since it's likely to do more harm than good and turn people off CL entirely).
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.
Got one of these myself (in a IIci with a Daystar accelerator and an 8-24-GC video card, 8MW of memory, standard Genera patched for Y2K). It was quite expensive to source and to rehabilitate. Lisp machines are a bit hard to get used to, and I definitely don't claim to be a Lisp deity, but their interfaces demonstrate a great deal of thought and orthogonality that's profoundly missing from a lot of modern UI.
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.
The FEP on 3600 was 68k - on Ivories FEP is normal Ivory program started from ROM.
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 have one whose enclosing/host Mac II no longer boots (I changed the CMOS battery, which was the cause last time, but no joy). No local Apple/Mac repair shop I can find will even look at it. Does anybody know a boutique, antique computer repair service?
The electrolytic capacitors in your Mac II are most likely dead and need to be replaced. It is reasonably easy to do if you are at all handy with a soldering iron. There are also many people that offer recapping as a service. Try asking on 68kMLA.
I don't know if you're joking or being sarcastic, if this was the case sorry. If this is a genuine question, then you'll have a lot of fun learning more about Lisp Machines:
I believe that the user experience from this system, and similar, can be equally attained with other languages. Of course, Lisp all the things, and I will agree there is no need of any other language, if that is to be argued .. but!
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.
I don’t agree. The programming language needs to have a dynamic and incremental runtime. Genera wasn’t some large static OS; everything was written in Lisp and could be defined, redefined, or augmented at runtime. The design of the OS depends on this.
I agree and that’s what the Lisp machines did brilliantly. In it’s current incarnation, and Turing yadda yadda aside, you wouldn’t be able to do what you can on the Lisp machine if you’re starting with C.
Its not far from being able to do that, though. UE already has very well integrated, introspective build tooling - whats missing is an editor, basically, that could handle the code-base of UE, and then .. wouldn't take much effort to integrate and complete the dynamic runtime/compiler-onboard loop.
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 web browser has been trending this way ever since JS was added to it. It's an active environment controlled by a dynamic language, it simply isn't done as well, and it isn't done entirely consistently across web browser implementations. The shortcomings and flaws don't negate the fact it is the same kind of thing.
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.
There were Java environments in the very early days which attempted to make the dream of Smalltalk-like execution/programming environments feasible .. there was one called "Visix Vibe" which used Java to make fantastic GUI's for easy deployment, and had the ability to ship source with all products, meaning the components could be edited in-environment.
Dunno what happened to Visix, but there were a few other similar style IDE's in the works in the 90's ..
> It's an active environment controlled by a dynamic language, it simply isn't done as well, and it isn't done entirely consistently across web browser implementations
One of the worst parts is that you don't do web development in the web browser itself.
>The web browser has been trending this way ever since JS was added to it. It's an active environment controlled by a dynamic language,
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
- as a language, JavaScript even in its current spec is still behind Common Lisp in power and features... For example, even decades later, lisp s-expressions are still superior to JSON!
Sure they did, JVM and CLR are kind of approximations of this.
Then the development experience still exists when using commercial Common Lisps, and Smalltalk provides also such full stack and interactive experience.
Yeah, I think its really just a bit of NIMBY in terms of opposing views. "Nobody has done that yet" isn't really true - just nobody has commercialized a new-generation implementation of the Symbolics ideology in a way that is easily recognized.
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.
JVM & CLR are an interesting counterpoint. I'm not sure I agree, but that's interesting to think about.
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.
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.