4 ms·

These comments are burying the lede, or burying the (lede). The author said that VisiCalc was written in Lisp and I said "wtf? Then I reread it and said "seri

by ralphc 2y ago

These comments are burying the lede, or burying the (lede). The author said that VisiCalc was written in Lisp and I said "wtf? Then I reread it and said "seriously, wtaf?" I've never heard that before. Was the original Apple ][ version written in Lisp?

dang 2y ago
I wish! But no. It was written in 6502 assembly language: https://rmf.vc/implementingvisicalc https://rmf.vc/implementingvisicalc Edit: Oh - the OP is talking about a later version of VisiCalc. Bricklin and Frankston were both MIT CS grads, so it would make sense. But at what point did VisiCalc get ported to Lisp? You're right—this is burying the lede!
- ralphc 2y ago
  I don't see it mentioned anywhere else. If someone gets a copy of VisiCalc and look at it in a hex editor, are there ways to tell that it's written in a Lisp?
  - whartung 2y ago
    Yes. Apply common sense. Especially considering the state of Lisp back in the day, not to mention the utter lack computational power that a 1MHz 6502 has. It’s not even worth considering the concept of them writing in some high level proto-lisp that is cross compiled into 6502 from a larger machine. While a lot of software was cross assembled on larger hardware for microcomputers back in the day, almost nothing of note was written in a high level language. (To wit someone will mention things like the Canon Cat being written in a Forth dialect, which is why I said “almost”.)
    - eichin 2y ago
      Or to hit more closely, in 1983 or so there was Grammatik https://en.wikipedia.org/wiki/Grammatik https://en.wikipedia.org/wiki/Grammatik , a grammar-checking tool for CP/M (on Z80 so it had a little more power than the 6502) written entirely in Forth - I spent a bit of time prying an interpreter prompt out of it. Consider that the PDP-10 was effectively around 500khz, and the 704 that lisp was invented on (and gave us the CAR and CDR names) "could execute up to 12,000 floating-point additions per second". It was a couple of years before Pascal and C really caught on for micro development, but it really wasn't the barren wasteland of raw machine code that you seem to be suggesting...
    - ralphc 2y ago
      Look up a couple of comments. From Dan Bricklin himself, "We wrote it in something we called IL, which is a Lisp derivative."
- _19qg 2y ago
  the "version 2" of VisiCalc was written in IL, a "Lisp derivative" https://conservancy.umn.edu/bitstream/handle/11299/113026/oh402b%26f.pdf https://conservancy.umn.edu/bitstream/handle/11299/113026/oh...
- gilbetron 2y ago
  "Ceruzzi: For legal reasons? Bricklin: Both. We couldn’t afford to spend money on time-sharing. We could buy our own machine. In those days, development – a lot of people did development, as Bob explained, on another machine. And then from that other machine, you loaded to the micro because the development systems on the micros weren’t up to it. That’s how Microsoft Basic was done – that’s how Microsoft ended up having a PDP-10 I think. They eventually used XENIX to do their development. We did the same thing. We developed all our own tools over the years. We improved the tools. We wrote our own implementation language, a higher level language. In fact, that’s one of the issues that eventually came in, is that in the early days of the PC industry, there were so many different machines and you didn’t know which was a winner. You sold to each manufacturer. So you had to port all over the place. That’s what Digital Research was – a porting company. Microsoft was a porting company. That’s what we did. We had to figure out ways to port the same product and cookie cutter it out. And everybody went a little different and you had to fight with them. Otherwise, the costs would go up. So we eventually moved things to a higher level language. We did our version 2 of VisiCalc, in a higher level language. Ceruzzi: What language? Bricklin: We wrote it in something we called IL, which is a Lisp derivative. It was like writing in Java or something like that today. An interpreter. Microsoft had a similar type of thing for Multiplan. They wrote in a language which let them use a cookie cutter to put it on many different machines. But the Apple II version of the VisiCalc II (VAV) was written in assembly code. We realized that to port that was going to be so expensive. When we ported from the Apple II and Apple III, doing the IIe was next, then to port to the IBM PC it’s a different code base. The way we did the VisiCalc code base is, since we had our own tools, we hired Seth Steinberg, who had worked at the [MIT] Architectural Machine Group – Media Lab, real experience, real bright guy, helped bring a culture into our company. Free Cokes came from him. He ordered it and all that stuff. Lotus and others all copied this. It helped bring that type of environment from MIT into our company and spread hopefully to others. What Seth did is he said, “I’m going to do an idiomatic translation, basically, from the 6502 code to a Z80 code to do the TRS80.” And what he did was he modified the compiler to list the two sources synced on labels. The compiler we used had macros and it had no ‘go-to’s in it. Basically it was all IF THEN ELSE and stuff. It was a macro assembler" https://conservancy.umn.edu/bitstream/handle/11299/113026/oh402b%26f.pdf?sequence=1&isAllowed=y https://conservancy.umn.edu/bitstream/handle/11299/113026/oh...
- rozzie 2y ago
  At Software Arts I wrote or worked on the IL interpreter for the TRS 80 Model III, the DEC Rainbow, the Vector Graphic, the beginnings of the Apple Lisa port, as well as the IBM PC port. To put you into the state of mind at the time, - in the pre-PC era, the microcomputer ecosystem was extremely fragmented in terms of architectures, CPUs, and OS's. 6502, z80, 68K, z8000, 8088. DOS, CPM, CPM/86, etc. Our publisher (Personal Software) wanted as much breadth of coverage, as you might imagine - one strong positive benefit of porting from 6502 assembly to IL and using an interpreter was that it enabled the core code to remain the same while leaving the complex work of paging and/or memory mapping to the interpreter, enabling access to 'extended memory' without touching or needing to re-test the core VisiCalc code. Same goes for display architectures, printer support, file system I/O, etc. - another strong benefit was the fact that, as the author alludes to, the company was trying to transition to being more than a one hit wonder by creating a symbolic equation solver app - TK!Solver - that shared the interpreter. Of course, the unavoidable result is that the interpreter - without modern affordances such as JIT compilation - was far less snappy than native code. We optimized the hell out of it and it wasn't unusable, but it did feel laggy. Fast forward to when I left SoftArts and went across the street to work for my friend Jon Sachs who had just co-founded Lotus with Mitch Kapor. Mitch & Jon bet 100% that the PC would reset the ecosystem, and that the diversity of microcomputers would vanish. Jon single-handedly wrote 1-2-3 in hand-tuned assembly language. Yes, 1-2-3 was all about creating a killer app out of 1.spreadsheet+2.graphics+3.database. That was all Mitch. But, equally, a killer aspect of 1-2-3 was SPEED. It was mind-blowing. And this was all Jon. Jon's philosophy was that there is no 'killer feature' that was more important than speed. When things are moving fast and the industry is taking shape, you make the best decisions you can given hunches about the opportunities you spot, and the lay of the technical and market landscape at that moment. You need to make many key technical and business decisions in almost an instant, and in many ways that determines your fate. Even in retrospect, I think the IL port was the right decision by Dan & Bob given the microcomputing ecosystem at the time. But obviously Mitch & Jon also made the right decision for their own time - just a matter of months later. All of them changed the world.
  - dang 2y ago
    Thank you!—that fills out the story very nicely.

by ralphc 2y ago

dang 2y ago

I wish! But no. It was written in 6502 assembly language: https://rmf.vc/implementingvisicalc https://rmf.vc/implementingvisicalc Edit: Oh - the OP is talking about a later version of VisiCalc. Bricklin and Frankston were both MIT CS grads, so it would make sense. But at what point did VisiCalc get ported to Lisp? You're right—this is burying the lede!

ralphc 2y ago
I don't see it mentioned anywhere else. If someone gets a copy of VisiCalc and look at it in a hex editor, are there ways to tell that it's written in a Lisp?
- whartung 2y ago
  Yes. Apply common sense. Especially considering the state of Lisp back in the day, not to mention the utter lack computational power that a 1MHz 6502 has. It’s not even worth considering the concept of them writing in some high level proto-lisp that is cross compiled into 6502 from a larger machine. While a lot of software was cross assembled on larger hardware for microcomputers back in the day, almost nothing of note was written in a high level language. (To wit someone will mention things like the Canon Cat being written in a Forth dialect, which is why I said “almost”.)
  - eichin 2y ago
    Or to hit more closely, in 1983 or so there was Grammatik https://en.wikipedia.org/wiki/Grammatik https://en.wikipedia.org/wiki/Grammatik , a grammar-checking tool for CP/M (on Z80 so it had a little more power than the 6502) written entirely in Forth - I spent a bit of time prying an interpreter prompt out of it. Consider that the PDP-10 was effectively around 500khz, and the 704 that lisp was invented on (and gave us the CAR and CDR names) "could execute up to 12,000 floating-point additions per second". It was a couple of years before Pascal and C really caught on for micro development, but it really wasn't the barren wasteland of raw machine code that you seem to be suggesting...
  - ralphc 2y ago
    Look up a couple of comments. From Dan Bricklin himself, "We wrote it in something we called IL, which is a Lisp derivative."
_19qg 2y ago
the "version 2" of VisiCalc was written in IL, a "Lisp derivative" https://conservancy.umn.edu/bitstream/handle/11299/113026/oh402b%26f.pdf https://conservancy.umn.edu/bitstream/handle/11299/113026/oh...
gilbetron 2y ago
"Ceruzzi: For legal reasons? Bricklin: Both. We couldn’t afford to spend money on time-sharing. We could buy our own machine. In those days, development – a lot of people did development, as Bob explained, on another machine. And then from that other machine, you loaded to the micro because the development systems on the micros weren’t up to it. That’s how Microsoft Basic was done – that’s how Microsoft ended up having a PDP-10 I think. They eventually used XENIX to do their development. We did the same thing. We developed all our own tools over the years. We improved the tools. We wrote our own implementation language, a higher level language. In fact, that’s one of the issues that eventually came in, is that in the early days of the PC industry, there were so many different machines and you didn’t know which was a winner. You sold to each manufacturer. So you had to port all over the place. That’s what Digital Research was – a porting company. Microsoft was a porting company. That’s what we did. We had to figure out ways to port the same product and cookie cutter it out. And everybody went a little different and you had to fight with them. Otherwise, the costs would go up. So we eventually moved things to a higher level language. We did our version 2 of VisiCalc, in a higher level language. Ceruzzi: What language? Bricklin: We wrote it in something we called IL, which is a Lisp derivative. It was like writing in Java or something like that today. An interpreter. Microsoft had a similar type of thing for Multiplan. They wrote in a language which let them use a cookie cutter to put it on many different machines. But the Apple II version of the VisiCalc II (VAV) was written in assembly code. We realized that to port that was going to be so expensive. When we ported from the Apple II and Apple III, doing the IIe was next, then to port to the IBM PC it’s a different code base. The way we did the VisiCalc code base is, since we had our own tools, we hired Seth Steinberg, who had worked at the [MIT] Architectural Machine Group – Media Lab, real experience, real bright guy, helped bring a culture into our company. Free Cokes came from him. He ordered it and all that stuff. Lotus and others all copied this. It helped bring that type of environment from MIT into our company and spread hopefully to others. What Seth did is he said, “I’m going to do an idiomatic translation, basically, from the 6502 code to a Z80 code to do the TRS80.” And what he did was he modified the compiler to list the two sources synced on labels. The compiler we used had macros and it had no ‘go-to’s in it. Basically it was all IF THEN ELSE and stuff. It was a macro assembler" https://conservancy.umn.edu/bitstream/handle/11299/113026/oh402b%26f.pdf?sequence=1&isAllowed=y https://conservancy.umn.edu/bitstream/handle/11299/113026/oh...
rozzie 2y ago
At Software Arts I wrote or worked on the IL interpreter for the TRS 80 Model III, the DEC Rainbow, the Vector Graphic, the beginnings of the Apple Lisa port, as well as the IBM PC port. To put you into the state of mind at the time, - in the pre-PC era, the microcomputer ecosystem was extremely fragmented in terms of architectures, CPUs, and OS's. 6502, z80, 68K, z8000, 8088. DOS, CPM, CPM/86, etc. Our publisher (Personal Software) wanted as much breadth of coverage, as you might imagine - one strong positive benefit of porting from 6502 assembly to IL and using an interpreter was that it enabled the core code to remain the same while leaving the complex work of paging and/or memory mapping to the interpreter, enabling access to 'extended memory' without touching or needing to re-test the core VisiCalc code. Same goes for display architectures, printer support, file system I/O, etc. - another strong benefit was the fact that, as the author alludes to, the company was trying to transition to being more than a one hit wonder by creating a symbolic equation solver app - TK!Solver - that shared the interpreter. Of course, the unavoidable result is that the interpreter - without modern affordances such as JIT compilation - was far less snappy than native code. We optimized the hell out of it and it wasn't unusable, but it did feel laggy. Fast forward to when I left SoftArts and went across the street to work for my friend Jon Sachs who had just co-founded Lotus with Mitch Kapor. Mitch & Jon bet 100% that the PC would reset the ecosystem, and that the diversity of microcomputers would vanish. Jon single-handedly wrote 1-2-3 in hand-tuned assembly language. Yes, 1-2-3 was all about creating a killer app out of 1.spreadsheet+2.graphics+3.database. That was all Mitch. But, equally, a killer aspect of 1-2-3 was SPEED. It was mind-blowing. And this was all Jon. Jon's philosophy was that there is no 'killer feature' that was more important than speed. When things are moving fast and the industry is taking shape, you make the best decisions you can given hunches about the opportunities you spot, and the lay of the technical and market landscape at that moment. You need to make many key technical and business decisions in almost an instant, and in many ways that determines your fate. Even in retrospect, I think the IL port was the right decision by Dan & Bob given the microcomputing ecosystem at the time. But obviously Mitch & Jon also made the right decision for their own time - just a matter of months later. All of them changed the world.
- dang 2y ago
  Thank you!—that fills out the story very nicely.