Comment by ncmncm | Hacker News Reader

Comment by ncmncm | Hacker News Reader

They about lost me at page 10, "In C/C++, the dimensions of an array must be declared at the beginning of a function)". First, no opening "(". What kind of Lisp hacker does this? Second, both in C and in C++ functions can (of course) take variable-sized arrays. (And, there is no such language as "C/C++"). If you are trying to explain why a Lisp company failed, is it the right place to put obviously false propaganda about the winners?

On page 14, several howlers in one, "[Word tagging] eliminates the need for data type declarations in programs and also catches bugs at runtime, which dramatically improves system reliability." Where to start? Dynamic type errors are a major cause of program failures in obligate runtime-bound languages, today. Word tagging turned out to be a dead end, easily outmatched by page tagging in normal architectures.

Higher up on page 14: "... an extra instruction in the final 386 architecture to facilitate garbage collection." What instruction? Was there one, really?

Also on page 14: Asserting novelty of virtual memory in the '80s, really?

Page 16: Calling out the importance of their proprietary debugger gives the lie to the claim on page 14.

Page 20: "Many potential customers of Symbolics were interested solely in Symbolics' software. However, customers could not buy the software without purchasing a expensive LISP machine." It looks like the authors would like to think the software was attractive. But of course any such potential customers could get the same software from MIT without a 5x$ machine hanging off. Did they?

Page 28: "The Symbolics documentation was outstanding ... former Symbolics employees still treasure them." People developing important things can't afford to spend enough attention on docs to make them outstanding, because the important things demand that attention.

And, yes, the kerning is positively abominable. No TeX?

That PDF document was produced by some historical interviewers, not Symbolics. Your comment roundly criticizes Symbolics for someone else's work. Only in the words it contains does it have anything to do with Symbolics documentation!

Unable to discover the affiliation of its authors (not stated in the document itself), I can't tell where it did come from -- although it is hosted by several sites around the world, not just MIT. It shows internal evidence of font character code corruption, typical in the 2001 era of moving a document from one kind of system to another, or even just trying to change font-set. Note the prevalence of capital U's where an apostrophe belongs, and the clipped text in the second "competitive wheel" diagram. In fact, the diagrams show all the signs of being pasted in from an incompatible system: that wheel diagram is no longer circular, and the egregious box-and-pointer diagrams show the character misplacement typically exacerbated by PDF encoding.

None of that would have issued from Symbolics Press.

I may be a little defensive on the issue of paying attention to docs -- why else would I make a thoughtful response to a down-voted comment from someone with a history of them? At Symbolics, I was pleased that my technical writer colleagues shared the same title of MTS as us developers. I led the small team which developed Symbolics' document development system Concordia, and its document formatter -- which btw was contemporary with TeX and drew upon Knuth's published paragraph and equation layout algorithms. Also I personally inspected every pixel of every character (and all the pixels between) in every font used in Symbolics documentation. In a side-by-side comparison, Symbolics docs would look superior to something from 1986 TeX. One might see how even Prof. Knuth himself wished that Computer Modern had had the attentions of a professional font designer.

Finally, the paper itself explained that such in-house efforts were all of a piece with the rest of the company's engineering ethos.

Leaving aside ad hominem remarks... I do not criticize Symbolics at all, or the documentation it (or you) produced. I do criticize the authors; either they were Lisp apologists themselves, or allowed themselves to be misled by Lisp apologists.

And, they kerned badly. I leave to you which was the greater offense.

There’s no assertion of inventing virtual memory - only that the platform had it as a feature. And for “novelty”, yes it was for personal, even minicomputer, systems at the end of the 1970s when they were conceived.

Also you’re confusing Symbolics software (post LM2) with the very barebones MIT CADR release. It was far better than that and the closely related LMI release. RMS rantings on this subject have only the most tenuous connection to reality (much like their originator ;).

Finally, Symbolics online hypertext docs (via Document Examiner) really were great. When one is attempting to expand the market for a powerful, yet esoteric system, good docs make that system more approachable. Sadly I think they really did run out of Lisp hackers as an audience but they did try.

What was invented though was a garbage collector tuned for virtual memory.

Let us stipulate that the docs were outstanding. The syllogism, then, dictates that the code wasn't important.

An independent measure may be derived from the value placed on the code when the company went into receivership, and from how widely it found use, afterward, detached from its overpriced host machine.

They were both important and at least for a while, Symbolics had the resources to fully indulge both. Do crappy Google docs assure their ubermenschitude? :)

It’s two different questions, to discuss the quality of their code and to discuss the value placed on it. It didn’t match the development and operational model of the tech world when they went into receivership, hence a low value.

Bad code and unimportant code can be as badly documented as (good or bad) important code, and often are.

Initial quality of code is largely independent of its importance, although important code improves. I am happy to stipulate that theirs was admirable code, besides being admirably documented. Still: the implication is that few people ran it, and any consequences of running it faded quickly.

When there's a choice of only two of good, important, or well-documented, a well-run organization chooses the first two.

C/C++ is just referring to two things. "In the NFL/NBA, median player salary is greater than $700,000."

If you're not giving them this, I don't expect you're reading the rest with a very charitable interpretation. And variable sized arrays weren't really supported in C/C++ until C11/C++11, and this was written in 2001.

C++ was not a force in 1987, so it is decidedly peculiar to mention it at all. And, even in 1987, malloc and alloca were both available everywhere. So, no, this is propaganda; not important by itself, except insofar as it unmasks the authors' biases.

Annnnd, C99 VLAs as such were not in C++11 at all, and were removed ("made optional") in C11, recognized as a mistake. That does not, of course, mean that C or C++ functions' array arguments were ever restricted to a fixed size.

Variable sized arrays are supported all the way back to 1978 K&R C and earlier, with dynamic allocation and pointer arithmetic. You just don't have nice syntax for managing them. You can implement a decent Lisp in C.

The bullshit about C/C++ is immediately preceded by a claim that everything in "LISP" is represented by lists at the lowest level, which is in contrast with other languages that have fixed arrays, like C/C++.

The people who wrote this garbage paper were not properly familiar with Lisp, C or C++.

> In C/C++, the dimensions of an array must be declared at the beginning of a function)". First, no opening "(". What kind of Lisp hacker does this? Second, both in C and in C++ functions can (of course) take variable-sized arrays. (And, there is no such language as "C/C++").

In c, an array has fixed size and dimensionality. You can, of course, create your own data structure using a pointer which allows you to access an unbounded number of objects; but that, in c parlance, is not an array.

And in c89, all variables must be declared at the beginning of a lexical scope (though not necessarily the beginning of a function).

C supports variable-length arrays since C99[1][2]. Alas, Lisp Machines preceded C99.

[1]: https://en.wikipedia.org/wiki/Variable-length_array#C99

[2]: https://en.cppreference.com/w/c/language/array

Yes, but they're optional as of c11.

> an extra instruction in the final 386 architecture to facilitate garbage collection.

Despite the tone problems of the post I'm replying to, I'm honestly curious about this: Is there such an opcode? I can't think of one, and I like to think I know things about x86 ISAs, despite all the dark corners that architecture has. Are they, somehow, confusing it with the iAPX 432, as unlikely as that sounds?

Anyway, here's the claim in context:

> (Interestingly, Symbolics at one time was working with Intel to build a development platform based on the 386, which led to the inclusion of an extra instruction in the final 386 architecture to facilitate garbage collection).

The only thing that comes to mind are the new 386 Bit Test instructions which could speed up manipulating tag bits in pointers and also any garbage collector bits.

> They about lost me at page 10:

How did you get past "[o]n the lowest level, LISP represent [sic] all objects, even the expressions of the language itself as lists" right in the previous sentence?

> What kind of Lisp hacker does this?

Right.

Reply on news.ycombinator.com