Lisp Badge (2021) | Hacker News Reader

Lisp Badge (2021)

technoblogy.com

112 pointstosh14 comments

It's hard to tell but it looks like they have open- and close-parenthesis on the base (un-shifted) layer, which is awesome.

That always puzzled me about the Space Cadet on the Symbolics Lisp Machines... you designed a machine from scratch that is ostensibly intended to be used and programmed with an awful lot of lisp code, but you expect the programmer to hit Shift+0 and Shift+9 each time they want a paren? C'mon.

Anyways this looks awesome; wish I had a use case for it.

The Symbolics Space Cadet keyboard had dedicated paren keys:

http://xahlee.info/kbd/space-cadet_keyboard.html

Here's the rumor I heard from Gumby about why it was designed that way:

https://news.ycombinator.com/item?id=12187422

DonHopkins on July 29, 2016 | parent | context | favorite | on: Unexecute

The Lisp Machine keyboard had dedicated open and close parenthesis keys, so you could hold a hefty bag of nitrous oxide in your other hand while you typed s-expressions.

qwertyuiop924 on July 29, 2016 [–]

Wait, what are you doing with that nitrous oxoide? Should I start worrying?

DonHopkins on July 29, 2016 | parent [–]

Reflecting on the S-expressions I just typed!

qwertyuiop924 on July 29, 2016 | root | parent [–]

Well, when you're done with the nitrous oxide, just toss whatever you wrote into the obfuscated code contest.

DonHopkins on July 29, 2016 | root | parent [–]

There's a reason the paren keys had really fast auto-repeat!

Edit by way of reply since the edit window is closed:

I apparently have seen pics of what I thought was the symbolics space cadet but apparently it's some other keyboard with parens on 0 and 9.

My bad.

The MIT Lisp Machine keyboard and also the Symbolics keyboard(s) had parentheses on shift-9 and shift-0. They also had unshifted parentheses a row below, right next to the P.

Interesting, on AZERTY (french) keyboards, parentheses are unshifted. They are on 5 and on ° (the key just right of 0). On the other hand, { is on alt gr on 4, [ on alt gr on 5, ] on alt gr ° and } on alt gr + (right of °). I wonder if it influences the programming languages that people prefer, even just a bit. Or maybe the style? Unshifted parenthesis makes function call easier for example.

I know it sounds silly, but one of the things that I particularly like about Lisp is the lack of the shift key. Notably, you can use identifiers-like-this. Yea, I haven't made the plunge to move () off the shift key, but I barely notice it compared to having to alwaysTypeLikeThis or type_like_this.

The keyboard fatigue adds up, and it's just an intangible I like about the language.

nuh uh. They were where square brackets [ and ] are on a "normal" keyboard. See image here: https://twitter.com/qrs/status/863959923339792384

Reminds me of Lisperati1000 https://twitter.com/lisperati/status/1357029088343506944

The original Lisp badge (or rather, SCHEME badge):

Design of LISP-Based Processors or, SCHEME: A Dielectric LISP or, Finite Memories Considered Harmful or, LAMBDA: The Ultimate Opcode, by Guy Lewis Steele Jr. and Gerald Jay Sussman, (about their hardware project for Lynn Conway's groundbreaking 1978 MIT VLSI System Design Course) (1979) [pdf] (dspace.mit.edu)

http://dspace.mit.edu/bitstream/handle/1721.1/5731/AIM-514.p...

HN discussion (excerpted with updated archive.org links):

https://news.ycombinator.com/item?id=8859918

gavinpc quoted Alan Kay from this video:

https://news.ycombinator.com/item?id=8860680

gavinpc on Jan 9, 2015 | next [–]

Here is Alan Kay from a talk that was just on HN today.

https://www.youtube.com/watch?v=ubaX1Smg6pY&t=8m9s

    The amount of complication can be hundreds of times more than the
    complexity, maybe thousands of times more.  This is why appealing to
    personal computing is, I think, a good ploy in a talk like this because
    surely we don't think there's 120 million lines of code—of *content* in
    Microsoft's Windows — surely not — or in Microsoft Office.  It's just
    incomprehensible.
    
    And just speaking from the perspective of Xerox Parc where we had to do this
    the first time with a much smaller group — and, it's true there's more stuff
    today — but back then, we were able to do the operating system, the
    programming language, the application, and the user interface in about ten
    thousand lines of code.
    
    Now, it's true that we were able to build our own computers.  That makes a
    huge difference, because we didn't have to do the kind of optimization that
    people do today because we've got things back-asswards today.  We let Intel
    make processors that may or may not be good for anything, and then the
    programmer's job is to make Intel look good by making code that will
    actually somehow run on it.  And if you think about that, it couldn't be
    stupider.  It's completely backwards.  What you really want to do is to
    define your software system *first* — define it in the way that makes it the
    most runnable, most comprehensible — and then you want be able to build
    whatever hardware is needed, and build it in a timely fashion to run that
    software.

    And of course that's possible today with FPGA's; it was possible in the 70's
    at Xerox Parc with microcode.  The problem in between is, when we were doing
    this stuff at Parc, we went to Intel and Motorola and pleading with them to
    put forms of microcode into the chips to allow customization and function
    for the different kinds of languages that were going to have to run on the
    chips, and they said, What do you mean?  What are you talking about?
    Because it never occurred to them.  It still hasn't.

https://news.ycombinator.com/item?id=8860722

DonHopkins on Jan 9, 2015 | prev | next [–]

I believe this is about the Lisp Microprocessor that Guy Steele created in Lynn Conway's groundbreaking 1978 MIT VLSI System Design Course:

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

My friend David Levitt is crouching down in this class photo so his big 1978 hair doesn't block Guy Steele's face:

The class photo is in two parts, left and right:

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

Here are hires images of the two halves of the chip the class made:

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

The Great Quux's Lisp Microprocessor is the big one on the left of the second image, and you can see his name "(C) 1978 GUY L STEELE JR" if you zoom in. David's project is in the lower right corner of the first image, and you can see his name "LEVITT" if you zoom way in.

Here is a photo of a chalkboard with status of the various projects:

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

The final sanity check before maskmaking: A wall-sized overall check plot made at Xerox PARC from Arpanet-transmitted design files, showing the student design projects merged into multiproject chip set.

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

One of the wafers just off the HP fab line containing the MIT'78 VLSI design projects: Wafers were then diced into chips, and the chips packaged and wire bonded to specific projects, which were then tested back at M.I.T.

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

Design of a LISP-based microprocessor

http://dl.acm.org/citation.cfm?id=359031

ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-514.pdf

Page 22 has a map of the processor layout:

http://i.imgur.com/zwaJMQC.jpg

We present a design for a class of computers whose “instruction sets” are based on LISP. LISP, like traditional stored-program machine languages and unlike most high-level languages, conceptually stores programs and data in the same way and explicitly allows programs to be manipulated as data, and so is a suitable basis for a stored-program computer architecture. LISP differs from traditional machine languages in that the program/data storage is conceptually an unordered set of linked record structures of various sizes, rather than an ordered, indexable vector of integers or bit fields of fixed size. An instruction set can be designed for programs expressed as trees of record structures. A processor can interpret these program trees in a recursive fashion and provide automatic storage management for the record structures. We discuss a small-scale prototype VLSI microprocessor which has been designed and fabricated, containing a sufficiently complete instruction interpreter to execute small programs and a rudimentary storage allocator.

Here's a map of the projects on that chip, and a list of the people who made them and what they did:

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

1. Sandra Azoury, N. Lynn Bowen Jorge Rubenstein: Charge flow transistors (moisture sensors) integrated into digital subsystem for testing.

2. Andy Boughton, J. Dean Brock, Randy Bryant, Clement Leung: Serial data manipulator subsystem for searching and sorting data base operations.

3. Jim Cherry: Graphics memory subsystem for mirroring/rotating image data.

4. Mike Coln: Switched capacitor, serial quantizing D/A converter.

5. Steve Frank: Writeable PLA project, based on the 3-transistor ram cell.

6. Jim Frankel: Data path portion of a bit-slice microprocessor.

7. Nelson Goldikener, Scott Westbrook: Electrical test patterns for chip set.

8. Tak Hiratsuka: Subsystem for data base operations.

9. Siu Ho Lam: Autocorrelator subsystem.

10. Dave Levitt: Synchronously timed FIFO.

11. Craig Olson: Bus interface for 7-segment display data.

12. Dave Otten: Bus interfaceable real time clock/calendar.

13. Ernesto Perea: 4-Bit slice microprogram sequencer.

14. Gerald Roylance: LRU virtual memory paging subsystem.

15. Dave Shaver Multi-function smart memory.

16. Alan Snyder Associative memory.

17. Guy Steele: LISP microprocessor (LISP expression evaluator and associated memory manager; operates directly on LISP expressions stored in memory).

18. Richard Stern: Finite impulse response digital filter.

19. Runchan Yang: Armstrong type bubble sorting memory.

The following projects were completed but not quite in time for inclusion in the project set:

20. Sandra Azoury, N. Lynn Bowen, Jorge Rubenstein: In addition to project 1 above, this team completed a CRT controller project.

21. Martin Fraeman: Programmable interval clock.

22. Bob Baldwin: LCS net nametable project.

23. Moshe Bain: Programmable word generator.

24. Rae McLellan: Chaos net address matcher.

25. Robert Reynolds: Digital Subsystem to be used with project 4.

Also, Jim Clark (SGI, Netscape) was one of Lynn Conway's students, and she taught him how to make his first prototype "Geometry Engine"!

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

Just 29 days after the design deadline time at the end of the courses, packaged custom wire-bonded chips were shipped back to all the MPC79 designers. Many of these worked as planned, and the overall activity was a great success. I'll now project photos of several interesting MPC79 projects. First is one of the multiproject chips produced by students and faculty researchers at Stanford University (Fig. 5). Among these is the first prototype of the "Geometry Engine", a high performance computer graphics image-generation system, designed by Jim Clark. That project has since evolved into a very interesting architectural exploration and development project.[9]

Figure 5. Photo of MPC79 Die-Type BK (containing projects from Stanford University):

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

[...]

The text itself passed through drafts, became a manuscript, went on to become a published text. Design environments evolved from primitive CIF editors and CIF plotting software on to include all sorts of advanced symbolic layout generators and analysis aids. Some new architectural paradigms have begun to similarly evolve. An example is the series of designs produced by the OM project here at Caltech. At MIT there has been the work on evolving the LISP microprocessors [3,10]. At Stanford, Jim Clark's prototype geometry engine, done as a project for MPC79, has gone on to become the basis of a very powerful graphics processing system architecture [9], involving a later iteration of his prototype plus new work by Marc Hannah on an image memory processor [20].

[...]

For example, the early circuit extractor work done by Clark Baker [16] at MIT became very widely known because Clark made access to the program available to a number of people in the network community. From Clark's viewpoint, this further tested the program and validated the concepts involved. But Clark's use of the network made many, many people aware of what the concept was about. The extractor proved so useful that knowledge about it propagated very rapidly through the community. (Another factor may have been the clever and often bizarre error-messages that Clark's program generated when it found an error in a user's design!)

9. J. Clark, "A VLSI Geometry Processor for Graphics", Computer, Vol. 13, No. 7, July, 1980.

[...]

The above is all from Lynn Conway's fascinating web site, which includes her great book "VLSI Reminiscence" available for free:

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

These photos look very beautiful to me, and it's interesting to scroll around the hires image of the Quux's Lisp Microprocessor while looking at the map from page 22 that I linked to above. There really isn't that much too it, so even though it's the biggest one, it really isn't all that complicated, so I'd say that "SIMPLE" graffiti is not totally inappropriate. (It's microcoded, and you can actually see the rough but semi-regular "texture" of the code!)

This paper has lots more beautiful Vintage VLSI Porn, if you're into that kind of stuff like I am:

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

A full color hires image of the chip including James Clark's Geometry Engine is on page 23, model "MPC79BK", upside down in the upper right corner, "Geometry Engine (C) 1979 James Clark", with a close-up "centerfold spread" on page 27.

Is the "document chip" on page 20, model "MPC79AH", a hardware implementation of Literate Programming?

If somebody catches you looking at page 27, you can quickly flip to page 20, and tell them that you only look at Vintage VLSI Porn Magazines for the articles!

There is quite literally a Playboy Bunny logo on page 21, model "MPC79B1", so who knows what else you might find in there by zooming in and scrolling around stuff like the "infamous buffalo chip"?

https://web.archive.org/web/20210131033223/http://ai.eecs.um...

Being able to only upvote you once feels so little.

Many thanks to sharing this information with us.

Reminds me of LambdaChip: https://lambdachip.com/index/

This looks awesome but I feel like it would get old really fast writing any amount of code on that tiny keyboard. Somehow doesn't stop me from wanting one though.

Typing on the keyboard is surprisingly fun.

For larger programs you can interact with the Lisp Badge via a serial console. Here's a setup for using Emacs's built-in serial support. This makes programming the Lisp Badge very similar to working in SLIME, with an on-target REPL and the ability to evaluate code fragments onto the target:

http://forum.ulisp.com/t/emacs-for-programming/236/13

I used that mode to port Emacs's Tetris to the Lisp Badge:

http://forum.ulisp.com/t/tetris-on-the-lisp-badge/945

After (save-image) and unplugging from serial, I had a portable Lisp-hackable handheld gaming system. I made small tweaks to the game code -- like new cheat modes or modified sound effects -- with the built-in keyboard.

At least it has dedicated open and close paren keys like the CADR keyboard!

http://xahlee.info/kbd/lmi-cadr_keyboard.html

Reply on news.ycombinator.com