Lisp Symbolics Macivory 3 with loaded software(twitter.com)
twitter.com
Lisp Symbolics Macivory 3 with loaded software
https://twitter.com/rainerjoswig/status/1213484071952752640
11 comments
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".
[0] https://github.com/KDE/kdeplasma-addons/blob/master/applets/...
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".
[0] https://github.com/KDE/kdeplasma-addons/blob/master/applets/...
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.
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 is absolutely an anti-pattern
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."
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."
I’m okay with that. It’s still an absolute date. It’s the relative dates I abhor.
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.
[deleted]
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.
How is modern Emacs in that regard?
How is modern Emacs in that regard?
Emacs probably surpassed XEmacs in that regard more than a decade ago.
Yeah, that is when I switched focus back into Mac/Windows as my main platforms and IDEs.
Thanks for the hint.
Thanks for the hint.
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
Railwaycat on github: https://github.com/railwaycat/homebrew-emacsmacport
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
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
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/emacsmacportThanks, I am mostly on Windows and IDEs nowadays, just wondering about the current state of affairs.
>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 ..
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.
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.
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.
You would be amazed at what people mindlessly enter into fields if you don’t enforce thinking.
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.
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.
I am quite confident that a large majority of the population would be more than happy with an Amiga 500, updated to deal with modern Web.
Totally. I mean .. this is a thing:
https://hackaday.com/2017/01/03/getting-the-amiga-500-online...
https://hackaday.com/2017/01/03/getting-the-amiga-500-online...
That Hackaday article is a little odd to me.
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.
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.
Indeed, I just doubt it could handle the Quake sized web pages, hence my point about being updated for the Web.
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.
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.
Maybe [1] https://en.wikipedia.org/wiki/Pharo ?
Especially in combination with [2] https://en.wikipedia.org/wiki/Moose_(analysis) .
The McCLIM project implements this user interface and can be used today: https://common-lisp.net/project/mcclim/
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...
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 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.
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 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.
The idea is that McCLIM is a base and that there are so many applications (like a listener) that it approaches an actual development environment.
https://drive.google.com/file/d/18p8-ip98iev9LW-Gtf0TMOJbfgY...
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.
Source code:
https://bitbucket.org/symbolicsimulation/com.symsim.oss.lisp...
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.
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.
Source code:
https://bitbucket.org/symbolicsimulation/com.symsim.oss.lisp...
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.
Do you happen to know whether there's any McCLIM library that works on Windows with SBCL?
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.
A useful step could be for some Windows developers to recommend which low-level graphics API McCLIM should use.
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.
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.
You can pay for LispWorks (inseado of sbcl) and it will run CLIM programs under Windows.
Note that sbcl is just another Common Lisp implementation, you could use others as well.
Note that sbcl is just another Common Lisp implementation, you could use others as well.
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.
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.
There's a nice memory dump here: http://fare.tunes.org/LispM.html
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 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)
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.
https://68kmla.org
https://68kmla.org
In what general area do you live?
MA/NH, USA.
You might want to reach out to the guys at the Rhode Island Computer Museum. It's worth a trek down there anyway to get a tour of their warehouse.
http://www.ricomputermuseum.org/
http://www.ricomputermuseum.org/
For historical background, see Lisp Machine Wikipedia article: https://en.m.wikipedia.org/wiki/Lisp_machine
I was introduced to the TI Explorer for a project in 1987 and really enjoyed working in the environment.
I was introduced to the TI Explorer for a project in 1987 and really enjoyed working in the environment.
When will this be released ? let's hope the prototype does not get shelved and forgotten.
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:
https://en.wikipedia.org/wiki/Lisp_machine
That has been release a long time ago.
https://en.wikipedia.org/wiki/Lisp_machine
That has been release a long time ago.
Entirely sarcastic. You can even see that on my profile description.
It's yet another "past did it better".. I tried to make it poetically naive.
It's yet another "past did it better".. I tried to make it poetically naive.
Here's another Lisp Machine demo showing some of these ideas in action: https://www.youtube.com/watch?v=o4-YnLpLgtk
Two things I found cool while using mine:
a) hypercard integration (HyperIvory) b) the lisp cons cell icon where one cell points to the apple logo
a) hypercard integration (HyperIvory) b) the lisp cons cell icon where one cell points to the apple logo
Great demo.
Now try that with Flutter.
Now try that with Flutter.
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.
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.
There needs to be common base runtime capable of complex types, objects, runtime redefinition support, exception handling etc.
Languages can vary on top of that.
Languages can vary on top of that.
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.
You could do it with a language like Lua on top of C, though.
Unreal Engine.
Exposes an API and lets you use it dynamically but (huge but) doesn't let you modify the entirety of Unreal Engine itself dynamically at runtime.
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.
Genera supported in fact multiple languages, though I believe Lisp was used as intermediary representation.
There was even support for C, good enough that there's a demo video of libpbg being compiled and used.
There was even support for C, good enough that there's a demo video of libpbg being compiled and used.
That's fascinating, got a link to the demo video somewhere? I can't seem to muster the fu ..
It's JPEG, not PNG, but here you go, a demo by Kalman Reti (one of the Symbolics' developers):
https://www.youtube.com/watch?v=o4-YnLpLgtk
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.
https://www.youtube.com/watch?v=o4-YnLpLgtk
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.
Thanks, that's really intriguing. Ah, to think of all the things that could have been ..
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.
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 ..
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.
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!
etc etc
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!
etc etc
Maybe you could, and you can believe whatever you want, but in 30 years, no one has.
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.
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.
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.
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.
....except Terry Davis.
>I believe that the user experience from this system, and similar, can be equally attained with other languages.
Only with Smalltalk. And then, Common Lisp has a more powerful OOP system and usually runs faster.
Only with Smalltalk. And then, Common Lisp has a more powerful OOP system and usually runs faster.
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.