
My aim in designing the first Tiny Lisp Computer was to create the smallest practical self-contained computer, with its own display and keyboard, that you could use to program in Lisp.
This second version extends the original Tiny Lisp Computer with four improvements: it uses the ATmega1284 to give it more program space; it includes parenthesis matching to make it easier to enter programs; it allows you to connect it to a computer via the USB port, to enter programs from the Arduino IDE's serial monitor; and it includes a built-in program editor, to allow you to make changes to programs without having to enter them again. [...]
As an example of using the program editor, enter the following function b that blinks the LED on pin 13 once a second:
(defun b (x) (pinmode 13 t) (digitalwrite 13 x) (delay 500) (b (not x)))Suppose we now want to change the delay parameter to 250 to make it blink twice as quickly. First give the command:(edit 'b)The editor prints the current context:(lambda (x) (pinmode 13 t) (digitalwrite 13 x) (delay 500) (b (not x)))where lambda is the internal representation for a function. Get to the delay command by typing:ddddThe editor prints:((delay 500) (b (not x)))Now get to the 500 by typing:adaThe editor responds:500Replace this with 250 by typing:r250The editor responds:250We can confirm that we've changed the correct value by backing up with:bbThe editor responds: (delay 250) Quit from the editor with:qFinally run the program to confirm that the change has been made:(b nil)
Code-data equivalence FTW! I am also pleased to note the tail-call elimination.
For the next version, and before mounting it on a Power Glove, I'd like to suggest adding support for the Atari 2600 Keyboard Controllers. Oh look, someone wrote a recent-ish review!
A constructive look at the Atari 2600 BASIC cartridge:
Honestly, I don't think the Atari 2600 BASIC has ever had a fair review. It's pretty much reviled as a horrible program, a horrible programming environment and practically useless. But I think that's selling it short. Yes, it's bad (and I'll get to that in a bit), but in using it for the past few days, there are some impressive features on a system where the RAM can't hold a full Tweet and half the CPU time is spent Racing The Beam. I'll get the bad out of the way first. [...]
And given that the Atari 2600 only has 128 bytes of memory, it's expected that the programs are going to be rather short. I at first thought that you had 64 bytes for the program, but no -- it's 64 bytes for the program, variables and runtime expression evaluation! [...]
Despite it being only 4,096 bytes, there's a pretty credible, windowed(!) integrated development environment in there. [...] The "STATUS" window (you can see it in the screen shot from the other day) shows memory usage (how many bytes, called "symbols") and how fast the program will run (1, 2, 4, 8, 15, 30 and 60 are the speed values and they reflect how often the interpreter is run -- once a second, twice a second, on up to 60 times a second). The "PROGRAM" window obviously contains the program (all nine lines if you have that many).
Previously, previously, previously, previously, previously, previously, previously, previously, previously, previously.
The Atari 2600 BASIC must presumably be the contender for the least useful not deliberately useless programming environment. The only thing I can think of in contention is Pico Basic for the Sinclair MK14 http://www.robsons.org.uk/archive/members.aol.com/mk14emu/pico.htm (the things we did in Britain in the early 80s along with giving ourselves 240V mains electric shocks and being sexually abused by BBC DJs and MPs).
I'd also nominate the Casio FX-7000G calculator's BASIC to be on that list. It had an 8x16 character display, and 422 "steps" of memory. (A step is a byte, but they tokenized all BASIC keywords to one byte each.)
Typing on it was next to impossible, because of the tiny rubbery keys, and the layout used a combination of shift and alpha keys with the letters laid out in A thru Z underneath the other numbers, along with special characters for keywords and punctuation. The graphing was nice, but you really, really needed the 200-page paper manual at your side to figure out anything other than four-function math.
I still have mine from the late 80s, and it works, but it's like the fastest way of burning out three CR-2032 batteries short of a piece of wire across the terminals. I put batteries in it recently, and tried typing out a 10 PRINT "HELLO" / 20 GOTO 10 and that took me about fifteen minutes of studying that horrible keyboard like I was trying to crack a bank vault.
More info:
http://www.computinghistory.org.uk/det/6045/Casio-fx-7000G-graphing-calculator/
Ha. I don't remember Casio doing a BASIC one. A friend had a Sharp one which was dog slow but actually reasonably powerful and useful.
Casios 20 year old (as opposed to 30 year old) graphing calculators had a pretty darn useful BASICish language. Sure, slow as fuck, and no real graphics (though 3 colors on the CFX models!), but certainly useful for writing things like small platform games when bored in class.
Pffft such luxury! The Casio FX-502P had only a single row of digits, and we programmed games on that.
(Admittedly not very good games. There was a simple two player "tennis" game involving a circle moving backwards and forwards where you had to press a key to "hit" this ball at each end of the display. We worked hard for our entertainment in 1980.)
I still have my Casio fx-6000G, sort of working after 29-ish years. The keyboard is limited, but it matches the limited quasi-BASIC (no line numbers, only 10 labels, no subroutines, no functions, only goto, only 26 variables, arrays used to overlap each other). Your canonical example should look like:
Lbl 0
"HELLO"
Goto 0
...which still works. The only thing I wrote that I specifically remember was Fibonacci. You didn't need that 200 page manual because it was so limited and intuitive.
It was useful for its intended purpose: It let Atari call the 2600 a "video computer system," thus placing it in a different (and presumably advantageous) category than a video game system when it came to international trade and tariffs.
Will I get lynched if I ask: why choose Lisp for this?
I'm sorry, did this project strike you as something that was attempting to solve a real-world problem in the most prosaic possible way?
As Deckard said: "... like any other machine. They're either a benefit or a hazard. If they're a benefit, it's not my problem."
(Ahem. Jamie's a former Symbolics Lisp Machines hacker. He has ended a post ranking common programming tools on their status in Greenspun's tenth rule: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Come for the art, the club nights, the pizza or the snark, stay for learning about computer history.)
((C) Robert T Morris, better known for the Morris worm).
When did jwz do Symbolics hacking? I thought he was a TI Explorer guy, mainly because that's what that group at CMU had.
I keep hoping someone will get TCP/IP working in Meroko so it can be useful as a newsreader, thanks to some of the stuff in the jwz Explorer archive that's amazingly still available.
It's sad that most lisp projects nowadays are born and die as nothing but toys for nostalgics and very few of them try to address a real world problem. Lisp has become the DeLorean of programming languages.
I have a few million dollars worth of clojure deployed. It does useful stuff if you count capitalism things as such.
Sorry, I forgot about clojure. I know I should like it under a rational point of view, but there's something about it that still doesn't feel like a Lisp. The lack of a native implementation, the immutability of data structures and the forced functional approach feels a bit limiting when you're used to Common Lisp.
Yeah, it's weirdly opinionated and tied to the JVM (or JSVM) - but I get to work in a REPL, live in emacs, and my paren keys hurt. shrug
You sound way more convincing than http://clojure.org. They should sell it like that.
How about for the future-kids an even more etheral solution...a hex-pad SDN_holgraphic nortbound controller ..