8 ms·

I still fantasize about having lisp "all the way down", but I'm not sure what I mean or ought to mean when I am fantasizing. On the one hand, I mean implementin

by ra88it 9y ago

I still fantasize about having lisp "all the way down", but I'm not sure what I mean or ought to mean when I am fantasizing. On the one hand, I mean implementing lisp in hardware as fundamentally as possible (don't really know why this would be valuable, but I'm still drawn to it). On the other hand, I mean having lisp be the foundation at the software level (ie., the kernel and the rest of the OS; I can more easily see how this would be valuable). Can someone here speak to the notion of a lisp machine in the future? Is there any chance this could happen? Would it be valuable? Does anybody else here have this same dream/fantasy/whatever-you-want-to-call-it? (edited slightly for wording and clarity)

rekado 9y ago
We have Guix as a system configuration/package manager, the GNU Shepherd as an init, and the GuixSD initrd itself, all of which are written in Guile Scheme. With the GNU Hurd important parts of the OS could be written in Scheme as well. The problems start with the desktop, where we don't really have anything that's well-integrated and lispy. Sure, there's StumpWM (Common Lisp), and there's Emacs, but they are separate programmes and there's no link between them. There is McCLIM[1], a GUI toolkit which looks like a continuation of lisp machine ideas, but as far as I know it does not have an active community (unlike Guix and Guile, whose communities actively work on a Scheme-powered operating system). [1]: https://common-lisp.net/project/mcclim/excite.html https://common-lisp.net/project/mcclim/excite.html
- lispm 9y ago
  The MCCLIM community is somewhat active, but very small...
- digi_owl 9y ago
  Sadly the GUI world seems uninterested in that kind of "interactivity". Instead they keep taking away options and in general dumbing down the UIs with the belief that this will make computers more approachable for the masses. But at that point, why bother? Build a games console or a cable TV box with a web browser and call it a day...
- zeveb 9y ago
  I really wish the GNU project would standardise on Common Lisp rather than Scheme. Lisp-2, false NIL, full-powered macros — Common Lisp has a lot going for it. An emacs written in Common Lisp, running in StumpWM, running atop a CL Guix, Shepherd & GuixSD would be a thing of beauty.
  - lispm 9y ago
    Stallman does not like Common Lisp.
    - erikj 9y ago
      I wonder if he really liked Lisp Machine Lisp or ZetaLisp.
      - lispm 9y ago
        That's what he has used and IIRC he claims to have implemented CL. But if you see what was missing in elisp: object system, closures, keyword arguments, ... That stuff was also in LML.
    - zeveb 9y ago
      I know, but I just don't get it. Common Lisp sure feels closer to elisp than Scheme does, and I'm constantly missing things from Common Lisp when I'm writing elisp (e.g. read macros, packages or character as a type distinct from integers). For me, at least, elisp just feels like a primitive Common Lisp while Scheme feels like a completely different language with a similar surface syntax.
      - lispm 9y ago
        My take: he did not like the added complexity in CL compared to Maclisp or even simpler Lisps. I doubt he is a big believer in Scheme either.
  - rekado 9y ago
    > Lisp-2, false NIL, full-powered macros — Common Lisp has a lot going for it. Heh, I find none of these things desirable :) I guess some people are just wired differently. I prefer a single namespace for all values, #F as the only false value, and (optionally) hygienic macros with syntax-case (which does not prevent traditional macros of the defmacro kind).
kabdib 9y ago
It happened (for a while) with Dylan on early, unshipped versions of the Apple Newton. Dylan was an object-oriented variant of Scheme, and there was an OS that was implemented nearly all the way to the metal in it. At least that's what I heard; I was working on the C++ based Newton OS, and sat next to the Dylan guys for a while, until they were told to stop work on their stuff. So I could have the level of "metalness" wrong.
- pvg 9y ago
  The Newton didn't have hardware designed to facilitate running Dylan, though, so it seems a somewhat lesser level of metalness.
  - kabdib 9y ago
    The MMU on the ARM 610 had features intended for Dylan, that were designed by one of my ex-cow-orkers; the sub-page protection system (1K granularity) was put there specifically to improve the garbage collection behavior of the system. (The sub-page protections allowed better than 4K granularity of physical page sharing, which helped a lot, since RAM on the newt was always precious). The original MessagePad might not have had enough memory to run a serious Dylan environment. But unshipped versions of the tablet newt ("Senior") did have enough, and my understanding is that they did, at least for a while.
    - mikelevins 9y ago
      I worked on bauhaus, the second Dylan-based Newton OS--that is, the one developed in parallel with the C++/Newtonscript one. It used the C++ microkernel and it used the 7 low-level bottleneck functions from C QuickDraw. Everything else was written in Dylan. I'm not sure whether it would fit on Junior; it might not. It was about half a megabyte. I don't remember how much room Junior had. I ran it daily, though, on a Senior prototype. It wasn't a Lisp machine in the usual sense, though, and not just because it didn't have hardware tags bits and so forth. The development environment didn't run on Newton hardware; it was a heavily-customized version of Macintosh Common Lisp called Leibniz which ran on Mac hadware. Our Newton hardware was ribbon-cabled to the Macs' Nubus slots. Leibniz had both Common Lisp and Dylan development environments in the same runtime image, complete with text editors and listener windows for Lisp and for Dylan. We used Common Lisp code to manage and customize the development environment, and we used Dylan code to implement bauhaus OS features. So I guess, in a sense, the combination of Mac hardware plus Newton hardware plus Leibniz acted sort of like a Lisp machine, but less featureful.
mikebenfield 9y ago
I used to dream about this too. Not so much anymore though. I feel like static type systems have progressed enough that dynamic typing really has little appeal to me at this point, especially the idea of dynamic stuff "all the way down." Nowadays my fantasy is more along the lines of: * a machine with a simple instruction set for CPU and GPU and without slow transfers between the two * a modern statically typed language that can be used to program both CPU and GPU, that's basically "Rust, but better, and with simpler syntax without braces and semicolons and commas and with easier macros and..." * some simple garbage collected extension language for runtime/dynamic stuff. Still statically typed though.
- lispm 9y ago
  Well, on a Symbolics Lisp Machine you could run Ada, C, Pascal, Fortran and some other exotic stuff. Probably there was an ML for it and I guess you could bring up an early Haskell compiler (Yale Haskell) on it.
  - DonaldFisk 9y ago
    I'm pretty sure Prolog was there too. If I'm not mistaken Symbolics C had safe pointer arithmetic and a garbage collector.
    - lispm 9y ago
      Prolog was one of the main language offerings, though it was not statically typed. ;-)
- TeMPOraL 9y ago
  > Rust, but better, and with simpler syntax without braces and semicolons and commas and with easier macros and... Makes me wonder: could there be a fully statically typed variant of Lisp? Did anyone try that?
  - Solarsail 9y ago
    Well, there is Shen. Static typing, I think it can do dependent typing... Doesn't have the affine types of Rust tho. Not sure how it works out to use in practice. Discussed here, for example: https://news.ycombinator.com/item?id=9297665 https://news.ycombinator.com/item?id=9297665
DigitalJack 9y ago
I think about this often. I'm a hardware designer (digital design asic fpga), so in theory I could help here. I don't really know what was special about the lisp hardware though... As far as I could tell it was mainly about helping with the type system and getting that to run at a reasonable speed on hardware of the day. So I've dismissed the idea of a custom processor. It just doesn't seem to have much value vs using ARM or RISC-V or x64. I've thought about the kernel aspect, but this mainly seems like drudge work. reimplementing stuff that's been a solved problem for a long time with linux. Not to mention drivers, which would be a massive massive effort. So I sort of settled on the idea of a lisp based userland. That seems at least feasible. I don't really understand containers well enough to understand what exactly is exposed to a program you are writing. I've heard you can run statically compiled programs without installing a base distribution. So maybe that would be where to start.
- gglitch 9y ago
  "Lisp-based userland" is how I'm going to describe Emacs from now on.
- zokier 9y ago
  I would imagine that LISPy CPU would have stuff like CONS/CAR/CDR as primitive instructions, and probably memory management heavily optimized for processing lists.
  - msla 9y ago
    The original LISP machine, the IBM 704, had CAR and CDR as primitives. And boy, were they primitive: > These names are hold-overs from the original implementation of LISP on the IBM 704. That machine had partial-word instructions to reference the address and decrement parts of a machine location. The a of CAR comes from "address", the d of CDR comes from "decrement". the c and r come from "contents of" and "register". Thus CAR could be read "contents of address part of register". http://www.iwriteiam.nl/HaCAR_CDR.html http://www.iwriteiam.nl/HaCAR_CDR.html
baldfat 9y ago
Why Lisp machine? (To solve this problem which is no longer a problem today. Therefore it would be a solution looking for a problem) "Why Lisp Machines? The standard platform for Lisp before Lisp machines was a timeshared PDP-10, but it was well known that one Lisp program could turn a timeshared KL-10 into unusable sludge for everyone else. It became technically feasible to build cheaper hardware that would run lisp better than on timeshared computers. The technological push was definitely from the top down; to run big, resource hungry lisp programs more cheaply. Lisp machines were not "personal" out of some desire make life pleasant for programmers, but simply because lisp would use 100% of whatever resources it had available. All code on these systems was written in Lisp simply because that was the easiest and most cost effective way to provide an operating system on this new hardware."
richardjdare 9y ago
Ever since I found out about Lisp machines I've been a bit obsessed with them. When I got the leaked distribution of Symbolics Genera going in Linux I felt like I was in possession of a crashed UFO. The user experience of the Listener, with its rich output (almost a "scrolling desktop") was exactly what I wanted from a command line. As I imagined what that system would be like if development had continued I started getting so many ideas, it was thrilling. And at that time I hardly knew Lisp! What excited me was the user experience of the Listener, the notion of programming being a way to use the computer, not just to construct software - and the way each piece of software in the system was practically an API for my own use. This was sci-fi stuff to me, extremely inspiring. I don't know how we could move towards the creation of modern Lisp machines. Disappointingly for this old Amiga user, we don't really have regular computers that aren't ugly old x86 any more. But I think about trying to work these ideas into my software development all the time. Genera had such an impact on me I can't avoid it.
- digi_owl 9y ago
  Consider then that it was what RMS lived and breathed for years. Also i feel that to a more limited sense this is what draws people to the unix CLI. And in turn what sold OSX to academia beyond media production courses. And something that both Apple and Linux userland programmers ignore at their peril.
- msla 9y ago
  > Disappointingly for this old Amiga user, we don't really have regular computers that aren't ugly old x86 any more. A Raspberry Pi is "regular computer" enough for me, at least as a hack platform. Ditto all the other ARM SBCs which are largely similar. (Odroid is fairly nice, too.) The special microcoded systems are dead, but ARM is a nice enough design and it's available from a ton of different sources.
- vram22 9y ago
  >the notion of programming being a way to use the computer, not just to construct software - and the way each piece of software in the system was practically an API for my own use. I've never used a Lisp machine, but based on your description, it sounds like the experience of using them might have been somewhat like using the Oberon system created by Niklaus Wirth- or the other way around (based on a BYTE magazine article [1] about Oberon that I read, IIRC - never used Oberon either). [1] I thought so because this part of your comment: >the way each piece of software in the system was practically an API for my own use matched somewhat with something I read in that BYTE article, which was something to the effect that once you had written a subroutine in Oberon, it could be called from anywhere in the OS. IOW, in a sense, the whole OS was like a single program, that you could program. Cool concept. Though the Oberon system might have been much less evolved, or whatever - as I said, used neither, just interested in the thing. P.S. From the Wikipedia article about Wirth: https://en.wikipedia.org/wiki/Niklaus_Wirth#Humor https://en.wikipedia.org/wiki/Niklaus_Wirth#Humor [ Wirth has reportedly told the joke that, because Europeans pronounce his name properly, while Americans pronounce it as "nickel's worth", he is called by name in Europe and called by value in America. ]
ohdrat 9y ago
https://loomcom.com/genera/genera-install.html https://loomcom.com/genera/genera-install.html Was gonna try this but haven't yet. After it's up, then what?
joelg 9y ago
One of the original Lambda the Ultimate papers was "Lambda: the Ultimate Opcode" that described the hardware design of a computer whose ISA was Lisp itself. The paper is full of strange alien ideas like not having an ALU (Lisp is naturally symbolic; why would we need it?). Guy Steele and Gerry Sussman also made a working processor from this design, but only fabricated a few prototypes (apparently it was absurdly slow, even by their standards). If you come by Gerry's office he'll gladly show one off to you. http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-514.pdf http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-...
troupe 9y ago
So I know this isn't what you are talking about, but you might find this interesting in terms of a machine that you interact with using lisp. It is basically a very small computer using an Arduino chip as the processor: http://www.technoblogy.com/show?1INT http://www.technoblogy.com/show?1INT
DonaldFisk 9y ago
There have been various suggestions over the years: LispOS, Tunes, Loper. There have even been some sucesses: Movitz, Mezzano. A few years back, I managed to get a Lisp interpreter written in x86 assembly language reading from a floppy and running on the bare metal on an old 32-bit laptop. I think the leading edge has moved on from Lisp Machines, but as the mainstream took a wrong turning a long time ago, that still has a long way to catch up. For me, the hot topics in system design are capability-based security, dependent types, and live programming. My "dream" is to have a statically typed Lisp (with type inference) running on commodity hardware (x64), and either compiling to the bare metal (faster) or to byte code (smaller, less work, and portable). This would be image-based, so no file system would be necessary, and have a single-address space, so you could treat the entire internet as if it were part of your machine's memory. It would have a structure editor instead of an Emacs variant. This is probably more than I'll ever have time to do. I have implemented my own Lisp dialect (which could form the basis of the system proposed above), and am using it to develop a visual dataflow programming language (http://web.onetel.com/~hibou/fmj/FMJ.html http://web.onetel.com/~hibou/fmj/FMJ.html). Many here and elsewhere are skeptical of the value of this, but I'm convinced it's the right thing. My short-term goal is to add dependent types to the new language.
flavio81 9y ago
>Can someone here speak to the notion of a lisp machine in the future? Is there any chance this could happen? Would it be valuable? Yes, of course it would be highly valuable. The reason of the superiority of a Lisp machine is the following: On a Lisp machine, what you manipulate is not files (text files or binary files), but meaningful information stored as s-expressions that can be directly shared by many applications, instead of being sent (copied) through pipes between processes in separate address spaces. This is where the power of a Lisp machine lies. This, and much more, is masterfully explained in this paper by Robert Strandh: http://metamodular.com/lispos.pdf http://metamodular.com/lispos.pdf Recommended reading!!
FullyFunctional 9y ago
You should examine why you dream of this; what is the attraction? This isn't my itch, but some possible answers could include having hardware enforced type safety and architectural support for efficient execution. To give a rather extreme example of what is possible with a dedicated architecture, study the Reduceron [1,2]. IMO, doing something similar for Lisp would be much much easier. Could it be done? Yes, absolutely and it would be great fun. You'd have to work with an FPGA though unless you have a sizable fortune to fab a chip (though 28nm is almost affordable). [1] https://www.cs.york.ac.uk/fp/reduceron https://www.cs.york.ac.uk/fp/reduceron [2] https://github.com/tommythorn/Reduceron https://github.com/tommythorn/Reduceron PS: Reduceron has a hardware garbage collector

by ra88it 9y ago

rekado 9y ago

We have Guix as a system configuration/package manager, the GNU Shepherd as an init, and the GuixSD initrd itself, all of which are written in Guile Scheme. With the GNU Hurd important parts of the OS could be written in Scheme as well. The problems start with the desktop, where we don't really have anything that's well-integrated and lispy. Sure, there's StumpWM (Common Lisp), and there's Emacs, but they are separate programmes and there's no link between them. There is McCLIM[1], a GUI toolkit which looks like a continuation of lisp machine ideas, but as far as I know it does not have an active community (unlike Guix and Guile, whose communities actively work on a Scheme-powered operating system). [1]: https://common-lisp.net/project/mcclim/excite.html https://common-lisp.net/project/mcclim/excite.html

lispm 9y ago
The MCCLIM community is somewhat active, but very small...
digi_owl 9y ago
Sadly the GUI world seems uninterested in that kind of "interactivity". Instead they keep taking away options and in general dumbing down the UIs with the belief that this will make computers more approachable for the masses. But at that point, why bother? Build a games console or a cable TV box with a web browser and call it a day...
zeveb 9y ago
I really wish the GNU project would standardise on Common Lisp rather than Scheme. Lisp-2, false NIL, full-powered macros — Common Lisp has a lot going for it. An emacs written in Common Lisp, running in StumpWM, running atop a CL Guix, Shepherd & GuixSD would be a thing of beauty.
- lispm 9y ago
  Stallman does not like Common Lisp.
  - erikj 9y ago
    I wonder if he really liked Lisp Machine Lisp or ZetaLisp.
    - lispm 9y ago
      That's what he has used and IIRC he claims to have implemented CL. But if you see what was missing in elisp: object system, closures, keyword arguments, ... That stuff was also in LML.
  - zeveb 9y ago
    I know, but I just don't get it. Common Lisp sure feels closer to elisp than Scheme does, and I'm constantly missing things from Common Lisp when I'm writing elisp (e.g. read macros, packages or character as a type distinct from integers). For me, at least, elisp just feels like a primitive Common Lisp while Scheme feels like a completely different language with a similar surface syntax.
    - lispm 9y ago
      My take: he did not like the added complexity in CL compared to Maclisp or even simpler Lisps. I doubt he is a big believer in Scheme either.
- rekado 9y ago
  > Lisp-2, false NIL, full-powered macros — Common Lisp has a lot going for it. Heh, I find none of these things desirable :) I guess some people are just wired differently. I prefer a single namespace for all values, #F as the only false value, and (optionally) hygienic macros with syntax-case (which does not prevent traditional macros of the defmacro kind).

kabdib 9y ago

It happened (for a while) with Dylan on early, unshipped versions of the Apple Newton. Dylan was an object-oriented variant of Scheme, and there was an OS that was implemented nearly all the way to the metal in it. At least that's what I heard; I was working on the C++ based Newton OS, and sat next to the Dylan guys for a while, until they were told to stop work on their stuff. So I could have the level of "metalness" wrong.

pvg 9y ago
The Newton didn't have hardware designed to facilitate running Dylan, though, so it seems a somewhat lesser level of metalness.
- kabdib 9y ago
  The MMU on the ARM 610 had features intended for Dylan, that were designed by one of my ex-cow-orkers; the sub-page protection system (1K granularity) was put there specifically to improve the garbage collection behavior of the system. (The sub-page protections allowed better than 4K granularity of physical page sharing, which helped a lot, since RAM on the newt was always precious). The original MessagePad might not have had enough memory to run a serious Dylan environment. But unshipped versions of the tablet newt ("Senior") did have enough, and my understanding is that they did, at least for a while.
  - mikelevins 9y ago
    I worked on bauhaus, the second Dylan-based Newton OS--that is, the one developed in parallel with the C++/Newtonscript one. It used the C++ microkernel and it used the 7 low-level bottleneck functions from C QuickDraw. Everything else was written in Dylan. I'm not sure whether it would fit on Junior; it might not. It was about half a megabyte. I don't remember how much room Junior had. I ran it daily, though, on a Senior prototype. It wasn't a Lisp machine in the usual sense, though, and not just because it didn't have hardware tags bits and so forth. The development environment didn't run on Newton hardware; it was a heavily-customized version of Macintosh Common Lisp called Leibniz which ran on Mac hadware. Our Newton hardware was ribbon-cabled to the Macs' Nubus slots. Leibniz had both Common Lisp and Dylan development environments in the same runtime image, complete with text editors and listener windows for Lisp and for Dylan. We used Common Lisp code to manage and customize the development environment, and we used Dylan code to implement bauhaus OS features. So I guess, in a sense, the combination of Mac hardware plus Newton hardware plus Leibniz acted sort of like a Lisp machine, but less featureful.

mikebenfield 9y ago

I used to dream about this too. Not so much anymore though. I feel like static type systems have progressed enough that dynamic typing really has little appeal to me at this point, especially the idea of dynamic stuff "all the way down." Nowadays my fantasy is more along the lines of: * a machine with a simple instruction set for CPU and GPU and without slow transfers between the two * a modern statically typed language that can be used to program both CPU and GPU, that's basically "Rust, but better, and with simpler syntax without braces and semicolons and commas and with easier macros and..." * some simple garbage collected extension language for runtime/dynamic stuff. Still statically typed though.

lispm 9y ago
Well, on a Symbolics Lisp Machine you could run Ada, C, Pascal, Fortran and some other exotic stuff. Probably there was an ML for it and I guess you could bring up an early Haskell compiler (Yale Haskell) on it.
- DonaldFisk 9y ago
  I'm pretty sure Prolog was there too. If I'm not mistaken Symbolics C had safe pointer arithmetic and a garbage collector.
  - lispm 9y ago
    Prolog was one of the main language offerings, though it was not statically typed. ;-)
TeMPOraL 9y ago
> Rust, but better, and with simpler syntax without braces and semicolons and commas and with easier macros and... Makes me wonder: could there be a fully statically typed variant of Lisp? Did anyone try that?
- Solarsail 9y ago
  Well, there is Shen. Static typing, I think it can do dependent typing... Doesn't have the affine types of Rust tho. Not sure how it works out to use in practice. Discussed here, for example: https://news.ycombinator.com/item?id=9297665 https://news.ycombinator.com/item?id=9297665

DigitalJack 9y ago

I think about this often. I'm a hardware designer (digital design asic fpga), so in theory I could help here. I don't really know what was special about the lisp hardware though... As far as I could tell it was mainly about helping with the type system and getting that to run at a reasonable speed on hardware of the day. So I've dismissed the idea of a custom processor. It just doesn't seem to have much value vs using ARM or RISC-V or x64. I've thought about the kernel aspect, but this mainly seems like drudge work. reimplementing stuff that's been a solved problem for a long time with linux. Not to mention drivers, which would be a massive massive effort. So I sort of settled on the idea of a lisp based userland. That seems at least feasible. I don't really understand containers well enough to understand what exactly is exposed to a program you are writing. I've heard you can run statically compiled programs without installing a base distribution. So maybe that would be where to start.

gglitch 9y ago
"Lisp-based userland" is how I'm going to describe Emacs from now on.
zokier 9y ago
I would imagine that LISPy CPU would have stuff like CONS/CAR/CDR as primitive instructions, and probably memory management heavily optimized for processing lists.
- msla 9y ago
  The original LISP machine, the IBM 704, had CAR and CDR as primitives. And boy, were they primitive: > These names are hold-overs from the original implementation of LISP on the IBM 704. That machine had partial-word instructions to reference the address and decrement parts of a machine location. The a of CAR comes from "address", the d of CDR comes from "decrement". the c and r come from "contents of" and "register". Thus CAR could be read "contents of address part of register". http://www.iwriteiam.nl/HaCAR_CDR.html http://www.iwriteiam.nl/HaCAR_CDR.html

baldfat 9y ago

Why Lisp machine? (To solve this problem which is no longer a problem today. Therefore it would be a solution looking for a problem) "Why Lisp Machines? The standard platform for Lisp before Lisp machines was a timeshared PDP-10, but it was well known that one Lisp program could turn a timeshared KL-10 into unusable sludge for everyone else. It became technically feasible to build cheaper hardware that would run lisp better than on timeshared computers. The technological push was definitely from the top down; to run big, resource hungry lisp programs more cheaply. Lisp machines were not "personal" out of some desire make life pleasant for programmers, but simply because lisp would use 100% of whatever resources it had available. All code on these systems was written in Lisp simply because that was the easiest and most cost effective way to provide an operating system on this new hardware."

richardjdare 9y ago

Ever since I found out about Lisp machines I've been a bit obsessed with them. When I got the leaked distribution of Symbolics Genera going in Linux I felt like I was in possession of a crashed UFO. The user experience of the Listener, with its rich output (almost a "scrolling desktop") was exactly what I wanted from a command line. As I imagined what that system would be like if development had continued I started getting so many ideas, it was thrilling. And at that time I hardly knew Lisp! What excited me was the user experience of the Listener, the notion of programming being a way to use the computer, not just to construct software - and the way each piece of software in the system was practically an API for my own use. This was sci-fi stuff to me, extremely inspiring. I don't know how we could move towards the creation of modern Lisp machines. Disappointingly for this old Amiga user, we don't really have regular computers that aren't ugly old x86 any more. But I think about trying to work these ideas into my software development all the time. Genera had such an impact on me I can't avoid it.

digi_owl 9y ago
Consider then that it was what RMS lived and breathed for years. Also i feel that to a more limited sense this is what draws people to the unix CLI. And in turn what sold OSX to academia beyond media production courses. And something that both Apple and Linux userland programmers ignore at their peril.
msla 9y ago
> Disappointingly for this old Amiga user, we don't really have regular computers that aren't ugly old x86 any more. A Raspberry Pi is "regular computer" enough for me, at least as a hack platform. Ditto all the other ARM SBCs which are largely similar. (Odroid is fairly nice, too.) The special microcoded systems are dead, but ARM is a nice enough design and it's available from a ton of different sources.
vram22 9y ago
>the notion of programming being a way to use the computer, not just to construct software - and the way each piece of software in the system was practically an API for my own use. I've never used a Lisp machine, but based on your description, it sounds like the experience of using them might have been somewhat like using the Oberon system created by Niklaus Wirth- or the other way around (based on a BYTE magazine article [1] about Oberon that I read, IIRC - never used Oberon either). [1] I thought so because this part of your comment: >the way each piece of software in the system was practically an API for my own use matched somewhat with something I read in that BYTE article, which was something to the effect that once you had written a subroutine in Oberon, it could be called from anywhere in the OS. IOW, in a sense, the whole OS was like a single program, that you could program. Cool concept. Though the Oberon system might have been much less evolved, or whatever - as I said, used neither, just interested in the thing. P.S. From the Wikipedia article about Wirth: https://en.wikipedia.org/wiki/Niklaus_Wirth#Humor https://en.wikipedia.org/wiki/Niklaus_Wirth#Humor [ Wirth has reportedly told the joke that, because Europeans pronounce his name properly, while Americans pronounce it as "nickel's worth", he is called by name in Europe and called by value in America. ]

ohdrat 9y ago

https://loomcom.com/genera/genera-install.html https://loomcom.com/genera/genera-install.html Was gonna try this but haven't yet. After it's up, then what?

joelg 9y ago

One of the original Lambda the Ultimate papers was "Lambda: the Ultimate Opcode" that described the hardware design of a computer whose ISA was Lisp itself. The paper is full of strange alien ideas like not having an ALU (Lisp is naturally symbolic; why would we need it?). Guy Steele and Gerry Sussman also made a working processor from this design, but only fabricated a few prototypes (apparently it was absurdly slow, even by their standards). If you come by Gerry's office he'll gladly show one off to you. http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-514.pdf http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-...

troupe 9y ago

So I know this isn't what you are talking about, but you might find this interesting in terms of a machine that you interact with using lisp. It is basically a very small computer using an Arduino chip as the processor: http://www.technoblogy.com/show?1INT http://www.technoblogy.com/show?1INT

DonaldFisk 9y ago

There have been various suggestions over the years: LispOS, Tunes, Loper. There have even been some sucesses: Movitz, Mezzano. A few years back, I managed to get a Lisp interpreter written in x86 assembly language reading from a floppy and running on the bare metal on an old 32-bit laptop. I think the leading edge has moved on from Lisp Machines, but as the mainstream took a wrong turning a long time ago, that still has a long way to catch up. For me, the hot topics in system design are capability-based security, dependent types, and live programming. My "dream" is to have a statically typed Lisp (with type inference) running on commodity hardware (x64), and either compiling to the bare metal (faster) or to byte code (smaller, less work, and portable). This would be image-based, so no file system would be necessary, and have a single-address space, so you could treat the entire internet as if it were part of your machine's memory. It would have a structure editor instead of an Emacs variant. This is probably more than I'll ever have time to do. I have implemented my own Lisp dialect (which could form the basis of the system proposed above), and am using it to develop a visual dataflow programming language (http://web.onetel.com/~hibou/fmj/FMJ.html http://web.onetel.com/~hibou/fmj/FMJ.html). Many here and elsewhere are skeptical of the value of this, but I'm convinced it's the right thing. My short-term goal is to add dependent types to the new language.

flavio81 9y ago

>Can someone here speak to the notion of a lisp machine in the future? Is there any chance this could happen? Would it be valuable? Yes, of course it would be highly valuable. The reason of the superiority of a Lisp machine is the following: On a Lisp machine, what you manipulate is not files (text files or binary files), but meaningful information stored as s-expressions that can be directly shared by many applications, instead of being sent (copied) through pipes between processes in separate address spaces. This is where the power of a Lisp machine lies. This, and much more, is masterfully explained in this paper by Robert Strandh: http://metamodular.com/lispos.pdf http://metamodular.com/lispos.pdf Recommended reading!!

FullyFunctional 9y ago

You should examine why you dream of this; what is the attraction? This isn't my itch, but some possible answers could include having hardware enforced type safety and architectural support for efficient execution. To give a rather extreme example of what is possible with a dedicated architecture, study the Reduceron [1,2]. IMO, doing something similar for Lisp would be much much easier. Could it be done? Yes, absolutely and it would be great fun. You'd have to work with an FPGA though unless you have a sizable fortune to fab a chip (though 28nm is almost affordable). [1] https://www.cs.york.ac.uk/fp/reduceron https://www.cs.york.ac.uk/fp/reduceron [2] https://github.com/tommythorn/Reduceron https://github.com/tommythorn/Reduceron PS: Reduceron has a hardware garbage collector