Live data from Hacker News

Why Did Symbolics Fail? (2009)

danweinreb.org

51–60 of 64 posts

Re: Why Did Symbolics Fail? (2009)

#51

Earlier quoted context omitted.

Symbolics stuff not just worked, it worked remarkably well on the very modest hardware and solved real word problems. For an example of unimaginable by "modern standards" quality , go ahead and take a look at the Common Lisp documentation produced by Symbolics (the art of writing, "motorcycle maintenance" kind of clarity and conscience) which is buried somewhere inside bitsavers and take a look at the sources of Open…

Everything in the Java language is done so as to prevent clueless people from messing up too much. It is an useful goal, but it impairs creativity and productivity. Complex concepts are either not implemented or forbidden outright. This is even in contrast to its closest competitor, which is C#. The latter has evolved a lot since its creation, while in the Java world lambdas are the hot new thing. But hey, you can hi…

That's an opinion commonly held by people who think they are hot shit.

(and for the record, I don't really like java either)

Re: Why Did Symbolics Fail? (2009)

#52
post #47
post #43

Earlier quoted context omitted.

You did benchmarking so you may be able to confirm/deny this: I've heard that Lisp machines went out of favor because Lisp just ran faster on a VAX. Was this the case?

Besides horrible management---echoing Zigurd, a friend and contemporary, I was at one point reliably told that manufacturing, R&D and marketing were paying no attention to each other, such that manufacturing had built a factory that couldn't make the latest hardware R&D had developed, which was done completely independently of what marketing thought was needed---they were killed by non-recurring engineering (NRE) cos…

I can't find a reference for this, but I seem to recall that Azul uses virtualization features of modern CPUs to decrease the read-barrier overhead; if that is correct, then that's a case of the general-purpose hardware fortuitously getting features to out-compete special-purpose hardware.

Re: Why Did Symbolics Fail? (2009)

#53
post #33

Earlier quoted context omitted.

For corporations, consistant work is often more desirable than exceptional work. Amassing thousands of lines of code that only exceptional programmers can use, understand and modify is a liability, not an asset, no matter how efficient it is.

Which is a quality of a fundamentally broken organizational system that measures power in (and therefore optimizes for) number of people controlled, as well as the government-directed economy that underwrites it.

tl;dr: there's a reason most startups prefer javascript to smalltalk.

Which is a quality of a fundamentally broken organizational system

No, it's a quality of a robust organizational system. Let's take a program that parses html as an example. What would you think of an html parser that only works well with high quality, strictly structured html and breaks under poorly formatted html? You would call it a fragile, broken system. But a parser that deals equally well with low quality html would be a well thought out, robust system. And here's the key to the point I was making: the robust system could be relied upon to do its job consistently even under less than ideal conditions.

A system that requires exceptional engineers to maintain it is a huge source of risk for any company. If your current exceptional engineer leaves for whatever reason, you have to find another one. If the reason your engineer left is your company is suddenly facing insolvency thanks to a nasty patent dispute, all you may be able to afford to hire is a college grad to maintain what you've already got.

Re: Why Did Symbolics Fail? (2009)

#54
post #52
post #47

Earlier quoted context omitted.

Besides horrible management---echoing Zigurd, a friend and contemporary, I was at one point reliably told that manufacturing, R&D and marketing were paying no attention to each other, such that manufacturing had built a factory that couldn't make the latest hardware R&D had developed, which was done completely independently of what marketing thought was needed---they were killed by non-recurring engineering (NRE) cos…

I can't find a reference for this, but I seem to recall that Azul uses virtualization features of modern CPUs to decrease the read-barrier overhead; if that is correct, then that's a case of the general-purpose hardware fortuitously getting features to out-compete special-purpose hardware.

No, the older version of their GC used bulk VM operations, but not virtualization features, and there was still a penalty reported ... errr, I can't find it now. Probably in a Clifford Click blog posting. I just skimmed the new edition of Jones' GC book (http://www.amazon.com/gp/product/1420082795/), published before it could consider the newer one; it talks about the changes needed on stock hardware but I didn't see any estimation of costs while glancing through it. (I'm not searching any more right now because it's obsolete.)

The base papers are:

Pauseless GC, uses a read barrier instruction in their custom 64 bit RISC chips: https://www.usenix.org/legacy/events/vee05/full_papers/p46-c...

And the newer one that they're using in that old hardware and the software on commodity hardware Zing JVM, the Continuously Concurrent Compacting Collector (C4), which I have not studied (the paper was published 2 weeks after the Joplin tornado trashed my apartment and rather disrupted my life): http://www.azulsystems.com/sites/default/files/images/c4_pap...

It's possible they figured out how to minimize or eliminate the penalties of the original software read barrier they applied to the Pauseless system in C4 (or perhaps in relation to their custom vs. newer commodity hardware); I just did a quick skim of the relevant part of the C4 paper and a few keywords and couldn't tell.

This is all great stuff that I hope to get back to soon....

Re: Why Did Symbolics Fail? (2009)

#55
post #53

Earlier quoted context omitted.

Which is a quality of a fundamentally broken organizational system that measures power in (and therefore optimizes for) number of people controlled, as well as the government-directed economy that underwrites it.

tl;dr: there's a reason most startups prefer javascript to smalltalk. Which is a quality of a fundamentally broken organizational system No, it's a quality of a robust organizational system. Let's take a program that parses html as an example. What would you think of an html parser that only works well with high quality, strictly structured html and breaks under poorly formatted html? You would call it a fragile, bro…

I guess you don't agree with our host's "Beating the Averages" essay: http://paulgraham.com/avg.html, specifically:

The average big company grows at about ten percent a year. So if you're running a big company and you do everything the way the average big company does it, you can expect to do as well as the average big company-- that is, to grow about ten percent a year.

The same thing will happen if you're running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble.

Re: Why Did Symbolics Fail? (2009)

#56
post #53

Earlier quoted context omitted.

Which is a quality of a fundamentally broken organizational system that measures power in (and therefore optimizes for) number of people controlled, as well as the government-directed economy that underwrites it.

tl;dr: there's a reason most startups prefer javascript to smalltalk. Which is a quality of a fundamentally broken organizational system No, it's a quality of a robust organizational system. Let's take a program that parses html as an example. What would you think of an html parser that only works well with high quality, strictly structured html and breaks under poorly formatted html? You would call it a fragile, bro…

You're speaking from the perspective of someone who has to be responsible for something without understanding it, which is another pathology endemic to that system. By only using black box reasoning, of course you come to the conclusion that you need many such boxen in case one malfunctions in an unforeseeable way.

The thing is, the level of intelligence to maintain the software has to exist somewhere. If it's not vested in a small number of people able to actually understand the system, then the intelligence ends up being an emergent property of the human automatons, Chinese-room style, with the now-important "manager" pretending to control it when in fact nobody does.

Re: Why Did Symbolics Fail? (2009)

#57
post #55
post #53

Earlier quoted context omitted.

tl;dr: there's a reason most startups prefer javascript to smalltalk. Which is a quality of a fundamentally broken organizational system No, it's a quality of a robust organizational system. Let's take a program that parses html as an example. What would you think of an html parser that only works well with high quality, strictly structured html and breaks under poorly formatted html? You would call it a fragile, bro…

I guess you don't agree with our host's "Beating the Averages" essay: http://paulgraham.com/avg.html , specifically: The average big company grows at about ten percent a year. So if you're running a big company and you do everything the way the average big company does it, you can expect to do as well as the average big company-- that is, to grow about ten percent a year. The same thing will happen if you're running…

I couldn't agree with the article more. I should have come up with a different tl;dr for the previous post, considering everything I wrote in this thread has specifically been about corporations and not startups. Sorry about the confusion.

Re: Why Did Symbolics Fail? (2009)

#58
post #53

Earlier quoted context omitted.

tl;dr: there's a reason most startups prefer javascript to smalltalk. Which is a quality of a fundamentally broken organizational system No, it's a quality of a robust organizational system. Let's take a program that parses html as an example. What would you think of an html parser that only works well with high quality, strictly structured html and breaks under poorly formatted html? You would call it a fragile, bro…

You're speaking from the perspective of someone who has to be responsible for something without understanding it, which is another pathology endemic to that system. By only using black box reasoning, of course you come to the conclusion that you need many such boxen in case one malfunctions in an unforeseeable way. The thing is, the level of intelligence to maintain the software has to exist somewhere. If it's not ve…

You're the only one in this thread talking about human automatons, outsourcing and broken corporate structures. I'm explaining why a healthy corporation would want to use a simpler and easier to understand system over a more complex, harder to understand one. Nothing more, nothing less.

The thing is, the level of intelligence to maintain the software has to exist somewhere.

Yes it does. Nothing I've said suggests otherwise. But, let's say you can lower the amount of intelligence required to actually understand the system. Not much, just from "exceptional" (by which I mean 10x or the top 1% of programmers working in the field) to "average" (by which I mean the median level of intelligence for programmers working in the field). If you can do that, you lower your risk over the long term. If someone leaves, you can easily hire a replacement and get them up to speed.

Re: Why Did Symbolics Fail? (2009)

#59
post #43

I worked in an expert systems company in the 80s (one mentioned in the Phillips thesis referenced in the danweinreb article). Take all this with a dose of IIRC. As part of out work, we evaluated and benchmarked Xerox Interlisp machines, Symbolics systems, VAXen, later Gold Hill etc. to find a cost-effective delivery platform. We even eventually funded the development of a delivery-focused subset of Common Lisp. One a…

You did benchmarking so you may be able to confirm/deny this: I've heard that Lisp machines went out of favor because Lisp just ran faster on a VAX. Was this the case?

I don't have any of the old papers / results. But my recollection is that the Lisp workstations greatly outperformed LISP on a contemporary VAX for a given cost, in part because of the workstation's microcoded instruction set tailored to Lisp. Over time, though, commodity hardware increased significantly in relative performance simply due to the economies of scale in producing it.

You might've been able to buy a Xerox workstation for, say, $15K-$20K, while a VAX box was over $100K. BUT for a production system, the VAX could run multiple Lisp processes at the same time. (I'm guessing at costs here, it's been too long.)

Also, Richard Gabriel did a bunch of Common Lisp benchmarks, might help to look for them. (Great fellow.)

The real threat to Symbolics et al, circa 1987, was things like Gold Hill Common Lisp running on, say, a IBM PC/AT with a 286 chip and maybe a meg of memory. At, perhaps, $3,000. It ran pretty fast, the Gold Hill tech folks were very good. But GHCL had an unsophisticated development environment compared to Symbolics / Xerox.

As excellent as the workstation environments were for development, a market demands that you eventually deliver a cost effective product into customers' hands. (Or is that too much old-think?)

Re: Why Did Symbolics Fail? (2009)

#60
post #58

Earlier quoted context omitted.

You're speaking from the perspective of someone who has to be responsible for something without understanding it, which is another pathology endemic to that system. By only using black box reasoning, of course you come to the conclusion that you need many such boxen in case one malfunctions in an unforeseeable way. The thing is, the level of intelligence to maintain the software has to exist somewhere. If it's not ve…

You're the only one in this thread talking about human automatons, outsourcing and broken corporate structures. I'm explaining why a healthy corporation would want to use a simpler and easier to understand system over a more complex, harder to understand one. Nothing more, nothing less. The thing is, the level of intelligence to maintain the software has to exist somewhere. Yes it does. Nothing I've said suggests oth…

> let's say you can lower the amount of intelligence required to actually understand the system

Every system has accidental complexity, so a better language can obviously help achieve this. However, Java does not do this. What Java does is lower the intelligence required to make changes without understanding the system, by having few abstractions and effectively making the programmer work in an intermediate language with added redundancy.

And while this approach allows for cheaper unskilled programmers to be used, they take up more time figuring out what to attempt to change and then crossing their fingers hoping the code will compile. A similar amount could have been spent for an intelligent consultant working in a high level language and serving several such clients, but management would rather feel secure by having someone they control.

> I'm explaining why a healthy corporation

Once it's in the territory of hiring more people instead of better people, you have something that prioritizes control over obtaining results, which is not healthy. Unfortunately, it can indeed still pass for a healthy corporation and live many decades, a source of many modern ills.

Post reply on HN