5 ms·

By all accounts, LispM's were awesome systems to use but lost out due to heavy marketing from unix vendor companies.

by cathexis 10y ago

qwertyuiop924 10y ago
They were also really expensive, and there have always been people who hated Lisp for the syntax.
- DonaldFisk 10y ago
  On Symbolics Genera they had the option of using C, Pascal, Ada, Fortran, or Prolog.
- deleted 10y ago
  [deleted]
- catnaroek 10y ago
  Lisp's syntax is okay, but its semantics is absolutely horrendous. Even ignoring the features that make it not so great a high-level language (such as the lack of a workable static semantics, forcing programmers to dynamically test what can be taken for granted in more civilized languages), Lisp is an even worse low-level systems language. In the 80's, the only way one could reasonably hope to use Lisp as a systems language was to run it on hardware explicitly designed to run Lisp. Of course, hardware support for features like dynamic typing and efficient dynamic allocation of lots of small objects doesn't come for free - this is what made Lisp machines expensive.
  - qwertyuiop924 10y ago
    Well, some of us like Dynamic Typing. Just because you don't doesn't make it horrendous. Given, it can be unpleaseant in certain contexts, but Lisp has really good metaprogramming support, so you can add syntax for a runtime type system relatively simply. It's not optimal, and it certaibly isn't the fastest thing, but it works if you want it. And nowadays, CL (and several of the Schemes) provide more powerful type systems, and sometimes even compile-time typing. All optional, of course.
    - catnaroek 10y ago
      I don't have anything against the presence of dynamic typing - it's in fact very useful. What's annoying is the absence of meaningful static typing: parametric polymorphism and exhaustive pattern matching help me prove things about what my code does and how it can be used by others, but their usefulness is reduced to zero when dynamically typed code is allowed to break the proofs' assumptions. To be perfectly clear: it doesn't bother me in the slightest that a dynamically typed module can break the internal state of another dynamically typed module, since in most likelihood I'm the author of neither, and I respect other people's right to write their code however they wish. So I'd be fine with a Racket-like contract system, where well-typed modules can't be blamed. But, if I understand correctly, what Common Lisp has is nothing like this.
      - qwertyuiop924 10y ago
        I don't know. I'm not a CL user. I understand that they actually do have a type system, which can be used to verify that your inputs are of the correct type and match your assumptions. As for contracts, I wouldn't be surprised if someone wrote a macro for it: they're not exactly rocket science, at their simplest. Don't ask me: I'm using Chicken Scheme, which provides both (to an extent: The documentation is worryingly vague about how the type system handles failure).
        catnaroek 10y ago
        Checking alone isn't the point. As things stand, it's no better than C, where the type checker can approve your code, yet it still has undefined behavior.
        qwertyuiop924 10y ago
        So you want exhaustive matching? I don't know if any lisp provides that by default. One of them probably does, somewhere. But since you don't mind Lisp syntax, and really like type systems, have you tried Shen? (http://www.shenlanguage.org http://www.shenlanguage.org) it's an interesting project.
  - lispm 10y ago
    Nice rant, but mostly wrong. > Even ignoring the features that make it not so great a high-level language (such as the lack of a workable static semantics, forcing programmers to dynamically test what can be taken for granted in more civilized languages) There are many more high-level features, than static semantics. Lisp is designed for runtime flexibility, not static semantics. Runtime flexibility allows lots of interesting high-level features. > In the 80's, the only way one could reasonably hope to use Lisp as a systems language was to run it on hardware explicitly designed to run Lisp. Lisp ran fine on five MIPS machines. Current systems have several hundred times the compute power. The hardware was explicitly designed for Lisp in the late 70s when nothing comparable was available (single-user powerful workstations for AI/Math researchers developing large systems like Macsyma) and most development took place on time-shared mainframes with many users. The market that demanded this was a high-end market, thus the systems were developed, even though the were expensive. Starting in the mid 80s, Common Lisp was moved to 1 to 10 MIPS workstations from SUN, SGI, Apollo, DEC, IBM, NeXT, Tectronix, and many others. The main problem at that time was that it would need 10 MByte RAM to run efficiently, which was expensive in the early 80s. 10 Mbyte. Today Lisp runs fine on an modern processor and some people tinker with Lisp-based operating systems, again. > Of course, hardware support for features like dynamic typing and efficient dynamic allocation of lots of small objects doesn't come for free - this is what made Lisp machines expensive. What made them expensive was the custom development for a small market, ten to twenty years ahead of their time. It was not the technology complexity of the hardware. People were buying future technology for lots of money, where comparable technology would appear 20 years later - the first Lisp Machines with object-oriented operating systems appeared in the late 70s for $100000 a piece. Some of Lisp Machines used 8 bit ECC to provide error checking and correction, when memory wasn't that reliable. It made them even more expensive, because ECC memory was even more expensive than normal memory boards. With memory sizes from 4MB to 20MB. Minor Lisp/Smalltalk support then went into the SPARC chips from SUN. Lisp ran quite well on those. > dynamic typing and efficient dynamic allocation of lots of small objects Every iPhone does that now, since Apple's Objective-C and the iOS frameworks are actually that: efficient dynamic allocation, of runtime-typed small and large objects. If you want to see Lisp on a small machine, buy a Roomba cleaner. http://www.irobot.com/For-the-Home/Vacuuming/Roomba.aspx http://www.irobot.com/For-the-Home/Vacuuming/Roomba.aspx Their software was developed in Lisp already twenty years ago on tiniest hardware. https://en.wikipedia.org/wiki/Roomba https://en.wikipedia.org/wiki/Roomba L – A Common Lisp for Embedded Systems https://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf https://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf It will clean your home, using Lisp on tiny hardware.
rbc 10y ago
I had a couple of them, a 3620 and a MacIvory. With all the focus on AI, maybe Lisp optimized hardware will return in some form, perhaps a bit like GPUs have become a trend. There was a lot of clever code written on top of Genera. It would be a shame for it to get re-written due to the loss of the Lisp machine platforms.

By all accounts, LispM's were awesome systems to use but lost out due to heavy marketing from unix vendor companies.

qwertyuiop924 10y ago

They were also really expensive, and there have always been people who hated Lisp for the syntax.

DonaldFisk 10y ago
On Symbolics Genera they had the option of using C, Pascal, Ada, Fortran, or Prolog.
deleted 10y ago
[deleted]
catnaroek 10y ago
Lisp's syntax is okay, but its semantics is absolutely horrendous. Even ignoring the features that make it not so great a high-level language (such as the lack of a workable static semantics, forcing programmers to dynamically test what can be taken for granted in more civilized languages), Lisp is an even worse low-level systems language. In the 80's, the only way one could reasonably hope to use Lisp as a systems language was to run it on hardware explicitly designed to run Lisp. Of course, hardware support for features like dynamic typing and efficient dynamic allocation of lots of small objects doesn't come for free - this is what made Lisp machines expensive.
- qwertyuiop924 10y ago
  Well, some of us like Dynamic Typing. Just because you don't doesn't make it horrendous. Given, it can be unpleaseant in certain contexts, but Lisp has really good metaprogramming support, so you can add syntax for a runtime type system relatively simply. It's not optimal, and it certaibly isn't the fastest thing, but it works if you want it. And nowadays, CL (and several of the Schemes) provide more powerful type systems, and sometimes even compile-time typing. All optional, of course.
  - catnaroek 10y ago
    I don't have anything against the presence of dynamic typing - it's in fact very useful. What's annoying is the absence of meaningful static typing: parametric polymorphism and exhaustive pattern matching help me prove things about what my code does and how it can be used by others, but their usefulness is reduced to zero when dynamically typed code is allowed to break the proofs' assumptions. To be perfectly clear: it doesn't bother me in the slightest that a dynamically typed module can break the internal state of another dynamically typed module, since in most likelihood I'm the author of neither, and I respect other people's right to write their code however they wish. So I'd be fine with a Racket-like contract system, where well-typed modules can't be blamed. But, if I understand correctly, what Common Lisp has is nothing like this.
    - qwertyuiop924 10y ago
      I don't know. I'm not a CL user. I understand that they actually do have a type system, which can be used to verify that your inputs are of the correct type and match your assumptions. As for contracts, I wouldn't be surprised if someone wrote a macro for it: they're not exactly rocket science, at their simplest. Don't ask me: I'm using Chicken Scheme, which provides both (to an extent: The documentation is worryingly vague about how the type system handles failure).
      - catnaroek 10y ago
        Checking alone isn't the point. As things stand, it's no better than C, where the type checker can approve your code, yet it still has undefined behavior.
        qwertyuiop924 10y ago
        So you want exhaustive matching? I don't know if any lisp provides that by default. One of them probably does, somewhere. But since you don't mind Lisp syntax, and really like type systems, have you tried Shen? (http://www.shenlanguage.org http://www.shenlanguage.org) it's an interesting project.
- lispm 10y ago
  Nice rant, but mostly wrong. > Even ignoring the features that make it not so great a high-level language (such as the lack of a workable static semantics, forcing programmers to dynamically test what can be taken for granted in more civilized languages) There are many more high-level features, than static semantics. Lisp is designed for runtime flexibility, not static semantics. Runtime flexibility allows lots of interesting high-level features. > In the 80's, the only way one could reasonably hope to use Lisp as a systems language was to run it on hardware explicitly designed to run Lisp. Lisp ran fine on five MIPS machines. Current systems have several hundred times the compute power. The hardware was explicitly designed for Lisp in the late 70s when nothing comparable was available (single-user powerful workstations for AI/Math researchers developing large systems like Macsyma) and most development took place on time-shared mainframes with many users. The market that demanded this was a high-end market, thus the systems were developed, even though the were expensive. Starting in the mid 80s, Common Lisp was moved to 1 to 10 MIPS workstations from SUN, SGI, Apollo, DEC, IBM, NeXT, Tectronix, and many others. The main problem at that time was that it would need 10 MByte RAM to run efficiently, which was expensive in the early 80s. 10 Mbyte. Today Lisp runs fine on an modern processor and some people tinker with Lisp-based operating systems, again. > Of course, hardware support for features like dynamic typing and efficient dynamic allocation of lots of small objects doesn't come for free - this is what made Lisp machines expensive. What made them expensive was the custom development for a small market, ten to twenty years ahead of their time. It was not the technology complexity of the hardware. People were buying future technology for lots of money, where comparable technology would appear 20 years later - the first Lisp Machines with object-oriented operating systems appeared in the late 70s for $100000 a piece. Some of Lisp Machines used 8 bit ECC to provide error checking and correction, when memory wasn't that reliable. It made them even more expensive, because ECC memory was even more expensive than normal memory boards. With memory sizes from 4MB to 20MB. Minor Lisp/Smalltalk support then went into the SPARC chips from SUN. Lisp ran quite well on those. > dynamic typing and efficient dynamic allocation of lots of small objects Every iPhone does that now, since Apple's Objective-C and the iOS frameworks are actually that: efficient dynamic allocation, of runtime-typed small and large objects. If you want to see Lisp on a small machine, buy a Roomba cleaner. http://www.irobot.com/For-the-Home/Vacuuming/Roomba.aspx http://www.irobot.com/For-the-Home/Vacuuming/Roomba.aspx Their software was developed in Lisp already twenty years ago on tiniest hardware. https://en.wikipedia.org/wiki/Roomba https://en.wikipedia.org/wiki/Roomba L – A Common Lisp for Embedded Systems https://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf https://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf It will clean your home, using Lisp on tiny hardware.

rbc 10y ago

I had a couple of them, a 3620 and a MacIvory. With all the focus on AI, maybe Lisp optimized hardware will return in some form, perhaps a bit like GPUs have become a trend. There was a lot of clever code written on top of Genera. It would be a shame for it to get re-written due to the loss of the Lisp machine platforms.