5 ms·

In short Moore's Law. Between 1970 and 2010 if you could design special purpose hardware that ran 10 times faster than the state of the art you would need to g

by antt 8y ago

In short Moore's Law. Between 1970 and 2010 if you could design special purpose hardware that ran 10 times faster than the state of the art you would need to get it to market in volume in under 3 years. If you took any longer the general purpose CPUs from Intel would by that point be within spitting distance of your superior architecture, at a fraction of the cost. That's what happened to Symbolics, general purpose PC's could run their software faster than the dedicated machines they designed.

shawn 8y ago
Also Lisp sucks in large groups. The simplicity is both its biggest strength and weakness. There are fewer smart people by definition, and the smartest people tend to want to make money. The net result is that you end up with blub powering the world. Luckily, there’s a way out: have your lisp machine transpile to blub.
- antt 8y ago
  The smartest people I know are not making any money. It is the mediocrities with delusions of grandeur that do.
- gnulinux 8y ago
  > the smartest people tend to want to make money. Citation needed. This is the exact opposite of my experience in life so far. Anecdotal maybe, but I met quite a few people from >10 different countries.
- deleted 8y ago
  [deleted]
chr15p 8y ago
Also if you make hardware absolutely optomised for Lisp then all the C, FORTRAN, and Cobol (this was the 1970's!) programmers aren't particularly interested because it does nothing for their code. So the Lisp machines were targeting a fairly small segment of the market that might have exploded into the mainstream but didn't, so they had less income to reinvest and therefore struggled to maintain their lead over the general purpose/mass market hardware vendors.
- lispm 8y ago
  The early architectures were micro-programmable. For example the Xerox Lisp Machines were using the exact same hardware as the Smalltalk or the Xerox office systems running Mesa-software. See: https://en.wikipedia.org/wiki/Xerox_Star https://en.wikipedia.org/wiki/Xerox_Star Symbolics had C, Pascal and Fortran compilers written in Lisp running on their machines. Others developed an Ada system for these machines. Drawback for all those: expensive and running not that fast. The interesting part: they allowed interactive development in these languages and one could run some C software a bit more safely due to runtime type checking. Examples for non-Lisp programs running on them: TeX and the usual X11 server. The explosion did not happen during their lifetime, because the whole package was expensive (RAM&Disk was very expensive), it was tied to higher-end hardware with lots of memory, it has never been ported to other architectures on the metal (an Alpha machine - expensive already - would have been fast enough to run a full Lisp OS - but all one had was an emulator for it ... there was not enough manpower to make it run natively) and because the OS was mostly limited to one person, one GUI and one Lisp per machine - it was no real server OS with securely (somehow) separated programs.
  - scroot 8y ago
    Possible additional point: going into the 80s/90s (the last gasps of "alternative" personal computing architecture), there were not many widely-adopted standards across computing. This is why we all bitched about file incompatibility across systems etc. But now we have all of this great stuff: format standards, APIs, hell, even TCP/IP is a universal standard that allows all manner of exotic hardware to speak to the rest of the world. I think something like Lisp/Smalltalk/SomethingNewOS machines might have another shot here soon, especially with the loss of gains from Moore's law
    - 3rdAccount 8y ago
      I'd love to have a true Lisp or Smalltalk OS.
      - scroot 8y ago
monocasa 8y ago
IDK. There were plenty of competitors to x86, both old and new, well into the late 90s. Lisp machines died off well before that. Moore's law was an inevitable churn, but it was predictable (that was the point). You knew what gate count you could get at what cost in the future, so you could plan ahead still. IMO, what killed them off were caches. First because more than half their shtick was that they ran their VM interpreter in microcode in order to avoid the bus contention between the interpreter and the code it was trying to run. When the inner loop of an interpreter can fit into icache, that gain is moot. (This is the same reason why those silly memcpy and strcpy single instructions you see in just about every cisc exist. They weren't that silly at the time, about half your bandwdith would be ifetch otherwise). And less importantly at the time, in a caching architecture their naive implementation with lots of pointer chasing is about worse case from a data flow perspective.

by antt 8y ago

shawn 8y ago

Also Lisp sucks in large groups. The simplicity is both its biggest strength and weakness. There are fewer smart people by definition, and the smartest people tend to want to make money. The net result is that you end up with blub powering the world. Luckily, there’s a way out: have your lisp machine transpile to blub.

antt 8y ago
The smartest people I know are not making any money. It is the mediocrities with delusions of grandeur that do.
gnulinux 8y ago
> the smartest people tend to want to make money. Citation needed. This is the exact opposite of my experience in life so far. Anecdotal maybe, but I met quite a few people from >10 different countries.
deleted 8y ago
[deleted]

chr15p 8y ago

Also if you make hardware absolutely optomised for Lisp then all the C, FORTRAN, and Cobol (this was the 1970's!) programmers aren't particularly interested because it does nothing for their code. So the Lisp machines were targeting a fairly small segment of the market that might have exploded into the mainstream but didn't, so they had less income to reinvest and therefore struggled to maintain their lead over the general purpose/mass market hardware vendors.

lispm 8y ago
The early architectures were micro-programmable. For example the Xerox Lisp Machines were using the exact same hardware as the Smalltalk or the Xerox office systems running Mesa-software. See: https://en.wikipedia.org/wiki/Xerox_Star https://en.wikipedia.org/wiki/Xerox_Star Symbolics had C, Pascal and Fortran compilers written in Lisp running on their machines. Others developed an Ada system for these machines. Drawback for all those: expensive and running not that fast. The interesting part: they allowed interactive development in these languages and one could run some C software a bit more safely due to runtime type checking. Examples for non-Lisp programs running on them: TeX and the usual X11 server. The explosion did not happen during their lifetime, because the whole package was expensive (RAM&Disk was very expensive), it was tied to higher-end hardware with lots of memory, it has never been ported to other architectures on the metal (an Alpha machine - expensive already - would have been fast enough to run a full Lisp OS - but all one had was an emulator for it ... there was not enough manpower to make it run natively) and because the OS was mostly limited to one person, one GUI and one Lisp per machine - it was no real server OS with securely (somehow) separated programs.
- scroot 8y ago
  Possible additional point: going into the 80s/90s (the last gasps of "alternative" personal computing architecture), there were not many widely-adopted standards across computing. This is why we all bitched about file incompatibility across systems etc. But now we have all of this great stuff: format standards, APIs, hell, even TCP/IP is a universal standard that allows all manner of exotic hardware to speak to the rest of the world. I think something like Lisp/Smalltalk/SomethingNewOS machines might have another shot here soon, especially with the loss of gains from Moore's law
  - 3rdAccount 8y ago
    I'd love to have a true Lisp or Smalltalk OS.
    - scroot 8y ago

monocasa 8y ago

IDK. There were plenty of competitors to x86, both old and new, well into the late 90s. Lisp machines died off well before that. Moore's law was an inevitable churn, but it was predictable (that was the point). You knew what gate count you could get at what cost in the future, so you could plan ahead still. IMO, what killed them off were caches. First because more than half their shtick was that they ran their VM interpreter in microcode in order to avoid the bus contention between the interpreter and the code it was trying to run. When the inner loop of an interpreter can fit into icache, that gain is moot. (This is the same reason why those silly memcpy and strcpy single instructions you see in just about every cisc exist. They weren't that silly at the time, about half your bandwdith would be ifetch otherwise). And less importantly at the time, in a caching architecture their naive implementation with lots of pointer chasing is about worse case from a data flow perspective.