Algorithms + Data Structures = Programs - Episode 162: Sean Parent on the History of Pascal

Episode Date: December 29, 2023

In this episode, Conor and Bryce chat with Sean Parent about Pascal, C, Unix, Modula(-2/3) and more!Link to Episode 162 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the Guest:Sean Parent is a senior principal scientist and software architect managing Adobe’s Software Technology Lab. Sean first joined Adobe in 1993 working on Photoshop and is one of the creators of Photoshop Mobile, Lightroom Mobile, and Lightroom Web. In 2009 Sean spent a year at Google working on Chrome OS before returning to Adobe. From 1988 through 1993 Sean worked at Apple, where he was part of the system software team that developed the technologies allowing Apple’s successful transition to PowerPC.Show NotesDate Recorded: 2023-12-12Date Released: 2023-12-29Jonathan O’Connor ADSP EpisodesSean Parent tweet on ADSP Episode 154Software Unscripted Ep77: How Programming has ChangedArrayCast Ep68: Brian Ellingsgaard and the Rayed-BQN Games FrameworkUCSD PascalPascal Programming LanguageSteve Wozniak’s SWEET16p-code machineApple LisaLarry TeslerObject PascalDelphiUnixVAX/VMSC LanguageTurbo PascalApple PascalMetrowerks CodeWarrior IDEModula LanguageModula-2 LanguageModula-3 LanguageOberon LanguageArthur WhitneyAnders HejlsbergCompiler Construction by Niklaus WirthLilith ComputerTilt FiveJeri EllsworthIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0

C was never a particularly elegant language. That's just. Pascal, by comparison, is a very elegant language. C was always difficult to parse compared to Pascal. So there were a lot of things working against it. But one of the things working for it is C from the get-go tended to have direct compilers targeting the assembly language of whatever machine you were working on. Where Pascal still, for the most part, relied on P code with a few exceptions. Apple had a compiler to 68K, but almost everybody else was running through P code.

And so Pascal was viewed as being slow and interpreted. And the whole object Pascal thing was viewed as being Apple's extension. And so it did not get wide use outside of the Apple ecosystem. Welcome to ADSP, the podcast, episode 162, recorded on December 12th, 2023. My name is Connor, and today with my co-host Bryce, we continue our conversation with Sean Parent. And in this episode, chat with him about the history of Pascal, Pascal versus C, other Nicholas Wirth programming languages, and more. We've now skipped ahead over Zach. Happy holidays.

You know, the holidays have passed, and I think it should be right before New Year's... What do you call that with respect to the... What are we, Julian? Gregorian calendar? One of the two. Happy New Year's or Happy New Year's Eve if you're listening to this now. And the original reason that we were bringing Sean back is...

We will link this at the top of the show notes to this episode. We did a series of conversations with Jonathan O'Connor where we were talking about a plethora of stuff, but a couple of the episodes focused on Pascal versus Ada versus C. And there was a bunch of stuff that we chatted about, but Sean, you ended up replying to, I believe it was the tweet on episode 154, which was I think like part two or part three of that talk. And I'm not going to read out everything because it was about three or four tweets in a row. But you mentioned a bunch of stuff that didn't get mentioned in that conversation. You know, if I peruse through this tweet, it's mentioning the Apple Lisa and Mac OS were written in a combination of Pascal and 68K. And then you mentioned a bunch of different books, a bunch of different computers. And I'll probably just leave it there

and just throw it over to you. And you can start wherever you want to start with the things that we missed and that you were sort of screaming in your head, how come they're not mentioning this? How come they're not mentioning this? And that's what the next, either part two or part three,

or maybe do we one part of this conversation will be. Yeah, so a combination of that. And then then I was listening to software unscripted and and you made a guest appearance there, Connor, on on that podcast. And you mentioned that you were born, I think, in 1990, if that's correct. That is correct. That is correct, yes. Yeah, which just made me feel very old. I joined Apple three years before you were born. I mean, we were interviewing on my other podcast at Raycast, Brian Ellingsgaard, who is 18, which means that he was born in 2005. So, you know, I don't, I didn't know.

People shouldn't be that young. I know. So like, I didn't know how young he was. And then when he said he was 18, I was like, oh God, that makes sense. If you're feeling old about me and I'm feeling old about Bryant, you know, it's just this vicious, vicious feedback loop here. Yeah. Yeah.

And like, like not, not knowing kind of you know pascal and and that history was was interesting pascal had had a had a a pretty significant heyday and even going all the way back to the apple 2 uh there was a an implementation of ucsd pascal which if you wanted to you know program you know a you know, a 68K processor, which was the old Apple II, was an 8-bit processor. So even doing, you know, 16-bit assembly language that executed in 6502 as a way to write 16-bit assembly language easier. So Pascal had a bit of a heyday at that time, and there was an implementation from University of California, San Diego, UCSD. That's what I was thinking that UCSD stood for,

but I was like, that can't be, there must be some other acronym and that's the only one I know, so that's what I'm thinking of. But that's just what it stood for. Yeah, so an implementation came out of there and it was based off of something called p-code where p-code is basically a bytecode

that's easily interpreted. And so the idea with UCSD Pascal was you could, it was kind of pre-Java, Java, it was you could compile your Pascal code down to p-code, and then you could run that p-code any place that had a p-code interpreter, and building a p- code interpreter was dead simple so it meant that you could write write pascal code and have it run basically anywhere so pascal itself became kind of the moral equivalent to what we would now think of as as python which is kind

of an application language if you needed to to write software and you weren't, you know, to solve a problem, right, using a programming language as an app, right, so you're writing software to solve a problem as opposed to building a product. Pascal got an awful lot of use in that environment. And it also became a great teaching language and then it started to bleed into system languages so the the original uh lisa uh was written the operating system itself was written in a combination of pascal uh compiled to 68 000 and 68k assembly language and then then Larry Tesler, who had come out of Xerox PARC, worked with Nicholas Wirth, who created Pascal to define Object Pascal. And that kind of became the language of choice

for writing applications on the Lisa. And that same basic model moved into the early macintosh so the initial macintosh the operating system was written in a combination of 68k assembly language and pascal and then most applications written on top of the early macintoshes were written in object pascal you know object pascal eventually morphed into Delphi. So there's a direct lineage there. But what happened was Unix took root in universities and kind of displaced many computer operating systems like VaxVMS got eventually displaced with Unix distributions. And Unix was very much built around the C language. And so C started getting taught in universities and displaced Pascal as a language of choice for a teaching language.

And there became this large ecosystem of developer tooling built in C. And so there became all these external pressures to move towards C. So eventually in kind of early 90s timeframe, Apple transitioned Mac development from Pascal to C. And Photoshop was originally written in, in object Pascal in 1990. And let's see, probably around 92, I would guess Photoshop was ported from object Pascal to C plus plus. And that was back in C front days where it was,

you know, Bjarne's compiler that compiled C plus plus code into C. And then you compile a C code into your machine code. And wait, so you said that this shift was just happening because Unix was gaining popularity and Unix was associated with C. And you mentioned that C started to get taught in universities because of this.

But at the same time, Pascal and Object Pascal or versions of Pascal were also being taught. So it was just momentum that Unix and c had more momentum than the the family of pascal languages yeah it was it was largely just momentum it got to the point where you know it was like well i could write this in pascal but look there's all these these tools that do this in c and you start hiring people and it became hard to hire somebody who knew Pascal. They knew C. So there was this momentum shift.

And from kind of building an operating system, there were certain things that were a little bit easier to express in C. It was just easier to circumvent the type system and kind of do whatever you wanted. Although in Pascal, Apple would do that by just dropping into 68k assembly language and writing little snippets like that where C was not sufficient. But, you know, for a while there, it was very unclear that

C was never a particularly elegant language. Pascal, by comparison, is a very elegant language. C was always difficult to parse compared to Pascal. So there were a lot of things working against it. But one of the things working for it is C from the get-go tended to have direct compilers targeting the assembly language of whatever machine you were working on, where Pascal still, for the most part, relied on p-code with a few exceptions. Apple had a compiler to 68K, but almost everybody else was running through p-code, and so Pascal was viewed as being slow and interpreted. The whole object Pascal thing was viewed as being Apple's extension, and so it did not get wide use outside of the Apple ecosystem. Talking about p-code reminds me that, and this is going to be embarrassing for Connor and I, during our previous discussion, Connor, I don't

think we talked about the fact that I'm pretty certain that the book ADSP, Algorithms Plus Data Structures Equals Programs, is largely in Pascal. And in fact, I believe that my original encounter with P-code was that there's a like a simple day, they write like a little Pascal compiler in the book, with a very slimmed down version of the VM. And I only just now remember, so clearly neither of us have read the book that recently. Well, I mean, because of the conversation with Jonathan, I did go out immediately after recording that. I bought a hard copy book and it's sitting on my shelf now. And because it was when he said that, yes, it's considered like a teaching book for Pascal. I was like, oh, that's, you know, clearly we haven't read it.

But like we didn't even know the basics of what I thought this book was like, a generic just kind of data structures and algorithms book. But yes, so at some point we will read it. I did not know that about in the ADSP book. Yeah, there was Turbo Pascal first appeared on, well, I was going to say Windows, but DOS, I think would be correct. So on Microsoft's platform. And yeah, Turbo Pascal was just an amazing, you know, little IDE and compiler that was just blazing fast. And it was the same name as the Pascal that Apple had on Apple II. But Apple Pascal on a Mac was an interpreted Pascal that was very much centered around kind of, you know, programming as an application, right, as opposed to programming an application. So same way you would use Python today, right?

You just want to solve a problem. And it was, you know, very slick environment and debugging environment, very easy to use, very limited. I think in your talk, somebody said, like, you could only have one file for a Pascal program. Not true, but that was true in Apple Pascal. And that file itself could only be 32K in size. And I actually wrote a school project in Pascal and ended up writing another tool in Compile Pascal that would process my Pascal to minify it so that, because I had to turn in the school project in Apple Pascal, and so that I could fit more in the 32K. And so I turned in two listings. One was the unminified code,

and then one was the code that actually ran, which was greatly reduced. And probably a lot less readable. And a lot less readable. Also included, there was an escape patch so you could execute assembly language and so there were sections of code where i just hand wrote them in assembly language and escaped from pascal to assembly language so so not completely legit but you know it was it was interesting i think a lot of ideas from Apple Pascal then got carried over into, and Turbo Pascal, into ThinkC and then into MetroWorks Code Warrior. I think the other thing that damaged Pascal

was Nicholas Wirth didn't, you know, he did Pascal and then he did Object Pascal, and then from what he learned from Object Pascal, he created Modula 2. Well, first Modula and then Modula 2. And then created Oberon. And so, you know, he was a university guy. And so he was kind of creating this stream of little languages. And so abandoning his previous work. And so I think that ended up damaging things right there got to be the point where you know i i did work actually shipped a product that

was partially written in module 2 before metro works did code warrior greg galanos wrote a module 2 compiler for mac I probably still have someplace here my Modula 2 book. People were doing, well, is it going to be Modula 2 next? Are we doing Modula 2? Are we doing Object Pascal? Oh, wait, now we're doing Oberon?

What's going on? And so just that lineage kind of confused the marketplace. And C++ had this much more straightforward story that is uh it's incredibly reminiscent of what i mean i've told this story a couple times on the podcast of what arthur whitney has done with the all the different k languages that he's written that he'll finish with one even more aggressively will delete it, clear all of the remnants of it off his workstation or laptop

and then move on to the next thing. And yeah, there's definitely that same kind of effect on the community that's using it. You know, people, is K6 going to be the final one? Is K7, is there going to be another one? And I think every time that a new one is created, people are more and more cautious to move to the next one or do we just keep using what we have? Yeah yeah and i wonder because the next name that comes to

mind is on our andrew hausberg out of microsoft but he's almost the opposite of that has worked on a ton of different like majorly successful languages but has not it hasn't been like you know they he made sure that the community was going to survive and continue to thrive and then just moved on to the next project, which I guess is for any aspiring programming language creators, all, in which case there'll be a bit of excitement around that. But I had no idea that that was kind of the reputation around what Virth was doing. Yeah, I've often thought if you take a compiler class in school, you basically learn the Dragon Book, which is a great book. But unless you're going to end up building compilers out of school, which very few people will, I think it's overkill. And Nicholas Wirth's languages and his compiler books are much simpler. The way Nicholas Wirth always built a language, I call it

LL1 to the bottom, which is he would define an LL1 grammar, which is a very simple recursive descent grammar with no backtracking. If you don't get success on the next token, then your code is wrong. And his compilers all generated code straight from the parser. He never built an AST. So he would compile straight from the parser into P code or into assembly language. And so it's a much simpler approach if you want to build a quick compiler one-off. It's really easy to build a little stack machine interpreter and then build a compiler that's recursive descent, and you just generate the code for your own stack machine straight out of your parser, and you don't deal with ASTs, and you don't deal with extra complexity.

But is a Lisp really like its scheme in the Dragonbook, right? I believe it is scheme in the Dragonbook, right? I believe it is Scheme in the Dragonbook. Yeah. Is it really that much harder? I mean, I do think they build an AST in that book, but is it really that much harder to parse? Oh, no. It's not that the parser in that language is that much simpler.

It's just that they go through all the steps of building a compiler, and it's like you build your AST, and then you do passes on it for optimizers. And you look, the Dragonbook is a thick book and nobody makes it through the Dragonbook in a quarter. I mean, come on, you're not actually doing that. I can't remember the name for Virat's book, but it's a small, small book. And if you look like you know nicholas veert built i think i mentioned it on twitter um a machine called the lilith which was basically a modula 2 machine what do you mean by he built a machine i mean they were manufacturing and you could order a lilith and you know like you could order an apple 2 you could order a lilith it was an expensive machine and did he design the chip

or he just built it? It was a combination of doing the chip design because the processor on it basically executed the bytecode coming out of the Module 2 compiler directly. And so it had its own custom CPU, its own custom hardware. It had a portrait display. It had its own module tube-based operating system, kind of a window-based operating system.

Quite an impressive feat at the time. You can look up, you can probably find emulators someplace to run a Lilith. At the time, I salivated over these things. It was like, oh, I really want a Lilith computer, but no possible way that I could afford one. You basically need to be in research at a university with some kind of government funding to get a Lilith. It was one of those dead ends in the evolution of

hardware and software. It's an interesting era because these days you could not, I think, create your own machine at the same scale. You need to be... A lot of people kind of do now with FPGAs. So I kind of think you could these days. You could basically build your own processor FPGAs and build, you know, I kind of think you could these days with, you could basically build your own processor FPGAs and build custom ASICs. The only place where I see people doing that is kind of emulating old game hardware. But you don't think that that era in the past was a golden era

of hardware and software design and that we're now in a much more homogenized era and an era where the, certainly the high end of chips is only for, or only the high end, or let me put it another way, the high end of computers today. And I don't mean like the most powerful computers, but like, you know,

the best computers, you know, the, the, the computers in your phone that are in your laptop, you know, something like the Nintendo Switch, those are produced by gigantic corporations and have huge, huge amounts of investment to go into them to produce them. Whereas, you know, back in the 70s and the 80s, you could create a thing that was a good thing at a much smaller

scale. Not quite maybe in your garage, but sort of close. It's interesting that, you know, I don't think, well, it's somewhat the same. It's like, you know, Steve and Steve, right, created the Apple One, you know, famously in the garage. And, you know, did the work for the Apple Two as well. Very small scale. And there's no way that you would do that today and compete with with a Mac or a Windows box. There's just no way. But at the same time for them they were creating something that ultimately would compete with you know minis and mainframes and there was no way for them to directly compete with that yeah and surprisingly the barrier to do like small entry-level hardware

these days is really low i mean if you look at small startups like Tilt 5, which just does an amazing setup for augmented reality for board games, which is very cool. And so it's little Pico projectors in glasses uh jerry ellsworth's work absolutely brilliant hardware and it's basically you know one woman a small company a small team who's who's who's doing uh this this relatively inexpensive custom hardware i guess you have a i guess you have a fair point um yeah and so you know and you see like one-off little consumer products all over the place will somebody build an entry-level laptop or os or something that eventually displaces mac and windows i don't know maybe

you know i think it's it's doable um really it's just you're not going to start with a head-on attack. You're going to start building something that Apple and Microsoft view as a non-threat toy in the same way that Deck viewed the Apple II as a toy. Not anything that would be at all competitive

with them ever. Have you tried this? Because I had never heard of Tilt 5 5 and when you mentioned ar board games i have always thought that uh i've only ever done one dnd campaign dungeons and dragons for the one percent of our audience that doesn't know what that refers to and uh it was cool but it was done virtually during the pandemic with my siblings and siblings partners and it was uh very cool but it was done through like a 2d online you know like you're going to the board and whatnot and it's i think you get a lot more out of having like a real board or if you go to

a game store and you have one of those sort of like you know uh not battlefields or whatever have you have you have you ever played dnd at a at a game store no but i have been to uh game stores trust me having the online thing to like keep track of all the state is actually very convenient okay well my point my point being though is regardless of if you're doing it in person with a dungeon master that is expert at you know moving things around making spatially aware stuff or you're doing it on this 2D thing, the real, like, first, like, you know, world-class experience that you want is this kind of AR thing where the dungeon master has, you know, ahead of the campaign gone forward, set this up of the different corners that you, oh, the mist comes over. Sure, the Dungeon Master can narrate that, but with the swoosh of a hand, the mist actually appears on this. And you could do it virtually. Everyone has a set of glasses.

They're just staring at whatever table. I want to use my imagination. It's like reading a book. Movies are nice, but sometimes one wants to read a book. All right. Bryce is not invited to the future Dungeons & Dragons campaign that I will have using this Tilt 5 technology. But I went to this site. And as soon as you said that, I was like, wait, is there a company that already has the hardware to do this?

And sure enough, they've got like a little demo of it. It doesn't show a D&D campaign, but exactly this kind of thing where everyone's got a little controller and they're playing these little fun games. Anyways, this is a long-winded of like this is something that's been in the back of my head of like this future technology would be awesome have you used this and do you know if like it's actually at the state where you can do this kind of stuff oh yeah so so this is the tilt 5 stuff is actually jerry's you know second generation be sure to tune in next year when we finish part three of our three-part conversation with sean parent about tilt 5 5, augmented reality, and more. And be sure to check your show notes either in your podcast app or at adsptopodcast.com for links to anything we mentioned in today's episode, as well as a link to a GitHub discussion where you can leave comments, thoughts, and questions. Thanks for listening.

We hope you enjoyed and have a great day. Low quality, high quantity. That is the tagline of our podcast. It's not the tagline. Our tagline is chaos with sprinkles of information.