8 ms·

Late 70s and 80s: forget BASIC, we had Pascal and C

85 points by ikari_pl 3y ago

ikari_pl 3y ago
Diving into the history of higher level programming languages in the 80s, with most focus on Pascal, some on C, and a honorable mention of Forth. By continuing the spirit of "how come things we have today are the way they are", the article aims to answer why was Pascal so influential, what made it so popular, when did we get C and how was it different. It's also a follow-up to an article appreciated on Hacker News that focused on how original BASIC compared to competition (and why The Famous Quote isnt' adequate to the BASIC most of us may know) - https://news.ycombinator.com/item?id=38743062 https://news.ycombinator.com/item?id=38743062
- PeterStuer 3y ago
  Forth was a very natural transition if you came into programming from the RPN style HP41cv calculator, an iconic machine for it's time
unwind 3y ago
This looks like a fun historical view of programming in the 70s and 80s. The section about C, though, I'm sorry to say is littered with flaws and should be rewritten and/or proof-read by someone with more knowledge about the language. Not impressed.
- guenthert 3y ago
  Indeed. I noticed "Going further, as was a common convention in assembly to pass the return value in the A (for 8-bit, later AX for 16-bit, and EAX for 32-bit) register of the processor (because it is faster than by a value in memory),". That is not the reason. While on many architectures, except perhaps 6502, it was faster (before we had first level data caches as fast as registers), the reason was reentrancy. And the Z80A in an Amstrad CPC6128 was clocked with 4MHz, not 3.5MHz like a Speccie. (sorry, couldn't resist)
  - flohofwoe 3y ago
    > And the Z80A in an Amstrad CPC6128 was clocked with 4MHz, not 3.5MHz... It's quite common to be mistaken though, because the Z80 in the CPC was not running at full 4 MHz speed (even though it's clocked at 4Mhz). The gate array would set the Z80's WAIT pin for 3 out of 4 clock cycles to create a window for the gate array to read pixel data from memory. This causes the Z80 to fall into a 4-cycle-aligned pattern, meaning that memory access machine cycles were stretched from 3 to 4 clock cycles, resulting in an effective speed of somewhere between 3 and 4 MHz (depending on the instruction mix, but probably averaging somewhere around 3.5 Mhz). > ... the reason was reentrancy. ...wouldn't passing the return value on the stack also allow reentrancy? Passing args and return values in registers instead of on the stack would definitely be faster, and on 8-bit CPUs, every clock cycle mattered.
    - ikari_pl 3y ago
      > ...wouldn't passing the return value on the stack also allow reentrancy? Passing args and return values in registers instead of on the stack would definitely be faster, and on 8-bit CPUs, every clock cycle mattered. But stack is memory. At least in these systems. So I think the problems could rise if we would throw concurrency into the picture, where you also have to synchronize the memory access, maybe?
      - flohofwoe 3y ago
        Switching to a different "thread" would also switch to a different stack though (although that would be kinda tricky on a 6502 where the stack is hardwired to the $100 page). Actual multithreading on an 8-bit CPU is a bit of an esoteric topic though, usually one only has to deal with interrupt service routines running concurrently :)
      - Jare 3y ago
        You're already using the stack for parameters without compromising reentrancy; using the stack for the return value is trivial. Just like parameters, it's easier and faster to use registers where possible in those old systems.
j4yav 3y ago
I learned BASIC and Pascal, and bounced off of pointers at C (went to Perl instead). I probably wouldn’t have learned Pascal without my first experience programming on a Pc that booted into BASIC.
rwmj 3y ago
C didn't work well on 8 bit CPUs (although it did exist). Z80 was infamously difficult to target for C code. See this stackoverflow topic: https://retrocomputing.stackexchange.com/questions/6095/why-do-c-to-z80-compilers-produce-poor-code https://retrocomputing.stackexchange.com/questions/6095/why-...
- ikari_pl 3y ago
  I've always thought the problem is that C today doesn't target 8-bits well? The optimizations that most sources mention mostly did not exist in the first version of C
  - jacquesm 3y ago
    No, C on 8 bits was terrible. You could get it to work but the compilers were slow and the code was bloated compared to assembly.
    - kjs3 3y ago
      And many/most of them were subsets of the C you'd get on, say, a PDP-11, at the time (although I understand they got better over time). That was what always put me off using C on the 8-bitters. Turbo Pascal on the other hand.......
    - shrimp_emoji 3y ago
      Even in the '90s, Diablo was a mix of C and assembly for the bits that C was too slow for! I've heard it said that, if they had the C compilers of today back then, the C code might've been good enough -- hardware being constant -- for them to have totally ditched the assembly, but I don't know how true that is.
      - jacquesm 3y ago
        Yes, but those C compilers of today run on the hardware of today! You wouldn't have been able to compile those C compilers to the point of efficiency required to build them in the first place. Lots of technology is like that. In order to do VLSI you need to do LSI, in order to do LSI you need MSI and so on all the way back to thin film circuits and then individual components. You can't normally skip such steps it's all incremental improvement on what's already there. In software it isn't much different and that software rode in lock-step with the hardware. The best I could do on a relatively fast micro of the 80's in terms of control, expression and eventually execution speed was a very nice macro assembler and given the speed of the storage devices and the raw clock speed of the CPU that was an accomplishment in itself. It pretty much maxed out the hardware. In spite of using clever stuff (hash tables for symbol lookups for instance, which ate up some of that precious memory, RAM disks etc) it still gook a good bit of time to assemble a 16K ROM image. But then I got an Atari ST with a whopping 1M of RAM, a 10 MB hard drive and Mark Williams excellent C compiler and it was off to the races. That was a real game changer for me.
rurban 3y ago
We also had Smalltalk, Prolog (esp. Visual Prolog) or Lisp.
paleface 3y ago
The linked Forth article, is a good read - I haven’t seen it before, either!
anta40 3y ago
Somethink I never think about: "It wasn’t always that easy to develop a program and run it on the same machine" Really? Of course I'm not talking about embedded system. But PC in the 70s/80s, like Apple II, ZX-80, TRS-80 etc etc. I guess we, 90s kids, are too spoiled :)
- mysterydip 3y ago
  I've been reading the ZX Spectrum Visual Compendium from Bitmap Books (https://www.bitmapbooks.com/products/sinclair-zx-spectrum-a-visual-compendium https://www.bitmapbooks.com/products/sinclair-zx-spectrum-a-...) and it has a lot of developer anecdotes in there. One of them (Clive Townsend) was talking about their development process: "The original Saboteur! code was written on an actual Spectrum so everything - the source code, assembler program, and object code - had to be in memory at the same time. I'd work on a routine, compile it, then save it. To test it, I'd reset the Spectrum and load the newly compiled routine along with other necessary code, graphics and data. After testing, I'd reset the Spectrum again and re-load my source code and the assembler program. All from cassette! Nightmare!"
  - ikari_pl 3y ago
    Sometimes you could have something plugged into the extension port to snapshot the memory, so you can switch easier, AND not lose your changes. It sounds horrible NOT to have it when writing a game like that (I love Sabouteur! Spent more time playing the 2nd part :))
PeterStuer 3y ago
I do not remember anyone on the Mac's using Turbo Pascal, as there was a far superior offering named Lightspeed Pascal by Think Technologies. As I remember it, it would take Borland the better part of a decade to catch up to the level of Pascal IDE quality Think offered in 1986.
- ikari_pl 3y ago
  Borland never really cared to support Turbo Pascal for Mac, from what I've read. Most of TP popularity is from the PC market after all
- nxobject 3y ago
  THINK Pascal and the THINK Reference was fantastic – instant compilation times, live debugging with one of the best symbolic debuggers I've ever used (complete with live statement and expression evaluation), concise and organized documentation of the Toolbox at your fingertips, complete with examples. The equal of Turbo Pascal on the Macintosh. The Macintosh Toolbox had, early on, a reputation for being a little bewildering with a lot of new system libraries to handle (memory management, resource management, UI/TextEdit, DIY event dispatching... it seems strange to explain to people how we would have to manually detect menu events based on location, and then manually respond to menu events), but THINK Pascal gave you a lot of courage.
tromp 3y ago
Yes, we had Pascal and C in the 80s. But what kid growing up in the 80s would go out of their way to purchase a Pascal compiler and learn an academically oriented language when their home computer comes with a very accessible built in programming language, providing direct access to sound and graphics and all the things they need to program their very own game? That most of their friends also had access to and for which the computer magazines at the time provided program listings with detailed explanations? The rare kid that wanted to wring out more performance than BASIC could provide was happy to explore the depths of programming in assembly. I know I had my share of fun making a connect-4 player in Z80 assembly that used the color attribute memory on the ZX Spectrum to search all variations. Learning Pascal a few years later in my CS studies was early enough for me.
- pjmlp 3y ago
  You would buy, or rent from the local library, a book for ZX Spectrum and type that Pascal compiler source code in. https://worldofspectrum.net/pub/sinclair/books-pics/p/PascalAufDemZXSpectrum.jpg https://worldofspectrum.net/pub/sinclair/books-pics/p/Pascal...
  - jacquesm 3y ago
    That never happened. At least, not in my circles. The progression was typically Basic of some variety (whatever your system shipped with), peek & poke, machine code, assembler and later on either C or Turbo pascal assuming enough time had passed. Pascal on 8 bit was just too damn slow compared to the alternatives to be very useful and compile times were horrendous. Even the university students that had access to Pascal compilers for the most part only used them to turn in their assignments and avoided it for everything else. I did a little contest with a friend: we both wrote a chess program, he wrote his state of the art with a ton of optimizations in Pascal, I wrote mine in assembler. His program never stood a chance against a very simplistic implementation that only had minimax and a greedy (strictly material based) evaluation routine. Good times :)
    - stevekemp 3y ago
ofrzeta 3y ago
On the Atari ST (and the Amiga I am told) there were several Modula compilers available. You can download the source of the Megamax Modula-2 compiler from Thomas Tempelmann's homepage: http://www.tempel.org/files-d.html http://www.tempel.org/files-d.html
- jhbadger 3y ago
  Logitech (yes, the mice/keyboard company) also had a Modula-2 compiler/IDE for the PC as well in the mid 1980s. It supported the mouse, unsurprisingly for Logitech, even though mouse support on DOS wasn't that common yet. http://www.edm2.com/index.php/Logitech_Modula-2 http://www.edm2.com/index.php/Logitech_Modula-2
- cmrdporcupine 3y ago
  I had Personal Pascal and Megamax Modula-2 on my ST. Great software. But most people used GFA Basic, which was structured, compiling, BASIC with a Pascal sheen to it. Or, if they were serious, they used C. The API for the AES and VDI was developed with C in mind, because it was written in C. Void pointers all over, stuff that Wirth-languages despised. GEM/TOS bindings for other languages were terrible, I never got Modula-2 to work well for GEM development, it simply didn't ship with bindings for it. I didn't have a C compiler, so to do anything GEM-ish... it was GFA. But TFA is about the early 80s, and is out to lunch. Only professionals with expensive PCs had access to C and Pascal in the early 80s. Though I guess there were Pascal dialects in the Apple II world, they weren't that commonly used.
baz00 3y ago
No thanks! The compilers were extremely slow. If you wanted to hang around all day waiting for your stuff to compile then that was fine but it wasn't a solution for most of us. Plus the majority of the market was 8-bit machines. In the early 80s I wrote a lot of code in (BBC) BASIC and assembly. That was extremely fast to build and run, with optimisations where necessary. For example to use a CP/M machine at the time with turbo pascal, it'd take at least 10 minutes to get the machine up and compile something simple. On the BBC Micro at the time, my preferred machine, there would be working code in under a minute. That was a big gain. They were used for test automation at the time over HP-IB (IEEE-488), eventually replaced with PCs running 16-bit Visual Basic on Windows.
- mikewarot 3y ago
  >The compilers were extremely slow. I'm sorry you had such a slow machine to put up with. You didn't get to experience the joy that was Turbo Pascal on an 8 Mhz 286 with 0 wait states. You'd get almost instant compile/run cycles. It was great!
  - cmrdporcupine 3y ago
    ... That's not early 80s though :-)
    - mikewarot 3y ago
      1984 ish
livrem 3y ago
A bit strange to mention Lazarus as if it was a thing of the past ("could never match...") but then also mention a few lines below that the last release was a week ago (almost two weeks now). It looks to me like the project is reasonably active? https://wiki.lazarus.freepascal.org/Lazarus_3.0_release_notes https://wiki.lazarus.freepascal.org/Lazarus_3.0_release_note...
- ikari_pl 3y ago
  It's more of a statement about life of not-mainstream open source projects vs what companies with many dollars can do. From the two, it's Delphi that's dead to me ;-)
MichaelRo 3y ago
>> Late 70s and 80s: forget BASIC, we had Pascal and C Well for once, PCs were ridiculously expensive back in the day so that rules out using the PC version of Borland Pascal / C. I had them in school, but we had mostly CP/M based machines and only two PCs. A 286 AT and an 8086 XT. If I recall correctly we had Borland Pascal 5.0 and it worked blazingly fast on both machines. Then some dumbass decided to upgrade to Borland Pascal 6.0 and wiped out 5.0 from the XT machine (lack of space, maybe? but mostly supidity) and replaced it with 6.0. It was horrendously slow. Like I got my first look into today's "enterprise" compile times :) Pressing F5 (or F9 or something to compile, I don't recall the exact key) took about a minute to start showing the compilation dialog. Several more minutes to compile. Compared to instantaneous on 5.0. Rendered the whole thing unusable on the XT. On the other hand I hated working on school's computers. They were overcrowded, too few for too many students and I always had barely enough time to type the examination programs (I was studying computer science) needed to get my grades, never enough time to fiddle and experiment. Or game. So for that I used my dear home computer, a ZX-Spectrum compatible clone manufactured locally: http://retroit.ro/wp-content/uploads/2019/12/hc-85-maro-678x381.jpg http://retroit.ro/wp-content/uploads/2019/12/hc-85-maro-678x... Initially I did BASIC but as time progressed, I needed more speed and interpreted BASIC was hopelessly slow. I wanted to program TETRIS actually :) So I switched to Pascal, more precisely HiSoft Pascal for ZX Spectrum. Here's the book I learned from, there was no Internet back then so the book was quintesential: https://imgur.com/a/qweDG2E https://imgur.com/a/qweDG2E Actually that's also where I learned and understood memory management. Linked lists, allocation, deallocation. Before C, for me there was Pascal. One thing that blew my mind and didn't understood it until I programmed and ran it with my own hands was recursively referring to the defined structure ... in the very structure. You know the C definition: typedef struct node { int val; struct node * next; } node_t; How the heck can you refer to something that's not yet defined in a way, I was thinking. So, I eventually implemented that TETRIS in Pascal and I've no idea how I did it without a debugger... I guess with print statements and just thinking with pen an paper. Worked well enough although it did crash on occasion and I never figured out why :) Anyhow, sometime later I got my hands on HiSoft's compiler for BASIC. Very cool thing, you'd load the compiler from cassette then you'd write your program in the regular ZX-Spectrum BASIC and then RANDOMIZE USR <some number> (address of loaded compiler) and the thing would put machine code somewhere in the remaining memory and provide you with the address and size. So you could save the machine code directly on cassette and run it directly next time. And all that in less than 40Kb of memory for BASIC code, compiler code, resulting compiled program and stacks etc. Believe it or not, I rewrote that TETRIS in BASIC and was able to compile and run it. Bonus it never crashed, I guess the BASIC version was inherently more stable.
tored 3y ago
There is an unwarranted hate against BASIC. BASIC has of course also evolved since then and you can still write professional software in numerous BASIC dialects just as in Pascal. Few years ago I evaluated FreePascal for writing desktop applications, I ended up instead with the BASIC dialect PureBasic (albeit commercial), better out of the box experience. Pascal is also slightly more verbose than BASIC.
- kjs3 3y ago
  Anyone who thinks BASIC is useless or a kids game has never seen what can be done with something like HP Rocky Mountain BASIC.
- jackhack 3y ago
  You could absolutely write professional software in BASIC. As a kid I wrote my first "professional" product in Applesoft. My family used to rent videotapes (Betamax!) from a little video shop on the corner. They kept records of who rented what on paper cards -- they literally wrote in the customer name and phone # on a paper card and put it in a box. They would go through that box each day and see what was overdue, calling the customer to remind them to return. I was a curious kid so I asked the owner "how do you keep track of everything? Do you really go through all those cards every day to see what is due? Does anything get lost?" I told the owner "I can put all this on a computer and make it so you'll never lose track of who has what" and he said "tell you what, you create that and I'll buy it!" I wrote a little program in Applesoft basic, using a light pen, that could keep track of the customers and video titles -- what was available, what was out, what was due, and what was overdue. The owner LOVED it! Customers had a "membership" card with a bar code on it.The clerk just had to scan the member card, a barcode for "checkout" (taped to the side of the screen) and then the bar code on the tape. No keyboard. Happy beep meant success. Check-in was the same process. And once a day they could check the "overdue" screen to see who to contact. The customer name, phone number, and name of movie was right there. They weren't crazy about entering the names of all the tapes and sticking the bar code stickers on them, but once complete business was so much easier & faster. It took me the better part of the summer to write this and I was paid $200 (a fortune for a 12 year old kid!) and given "free movie rentals for life." The owner was good to his word, and even after he bought a movie rental franchise many years later (maybe Blockbuster?) my family still enjoyed free rentals though the apple 2 was long since retired.
black_13 3y ago
[dead]
cmrdporcupine 3y ago
Phh... Wealthy PC owners had Pascal and C. In the early 80s, us plebs had 8-bits that ran BASIC or we programmed assembly. Hell, my parents wouldn't even pay for an assembler for my VIC-20 so I programmed 6502 machine code by hand with POKE and DATA statements with the explicit opcodes. Sure, if your dad was an accountant or something, and let you use his PC, you might have access to Turbo Pascal or something, I dunno. But that was a very expensive machine, and market penetration on 16-bit machines was extremely low until the mid80s. Late 80s, different story.
- paleface 3y ago
  Heh, how the other half live!… My memory of programming in the eighties, was a pad of ruled paper, and a rotation of Usborne books from the library.
whartung 3y ago
Interpreted BASICs (such as BASIC-PLUS on DEC, MS-BASIC on micros) big benefit at the time was speeding up the develop cycle by working with source code in RAM, and running directly from it, thus skipping the edit/load cycle across crushingly slow I/O. Turbo Pascal on CP/Ms breakthrough was bringing a similar experience to a compiled language. So you got fast turn arounds, with better performing code. Turbo did this by compiling from RAM, to RAM, and skipping the link process. The Turbo runtime was already loaded in RAM and used by Turbo itself, so the binary just called already RAM resident routines. When the final COM file was saved, it simply bulk copied the runtime to disk and attached the compiled code at the end. This is one reason why even small programs created large COM files with Turbo, they all bundled the entire runtime. There's nothing particularly slow about a C compiler, but when you wrap it in reading from disk and writing to disk, or, even worse, writing assembly that then had to be assembled, then stacking on a link step, and turn around craters. The practice of several C files having to be linked together involved yet more I/O. Ostensibly there was a benefit of not having to recompile all of the files all of the time (but note, especially on CP/M at the time there were no timestamps on files, so "make" wasn't a real option to do this), hoping for a net win. Linking also let your program include only the routines it truly needed, reducing footprint. Linkers have lots of benefits, performance during the dev cycle is simply not one of them. As you started to write larger Turbo programs, utilizing include files, and having to write to disk (because the RAM wasn't enough for your code any longer), and Turbo most certainly slowed down. But still not quite as bad as something like C as, again, there was no real linking phase. I have, I think, a 1200 line Pascal program, in several include files, that builds on a 4Mhz (simulated) Z80 and, yea, you can sit there watching the lines tick by. Doesn't take minutes, but it's definitely a time to get a sip of coffee and catch breath looking out the window. The Atari series had ACTION, which was a very Turbo like system using a simple Algol-esque language. It, too, had a bundled runtime on the ROM cartridge, with a very fast compiler. I tried a C compiler on the Atari, and tossed it after my first build. It was absolutely horrific. The Atari (along with the Commodores) had notoriously slow disk drives.
simonblack 3y ago
I was a little different. After a couple of years or so on BASIC from 1979 onwards, and a very tiny dabble with Pascal, I spent the next four or five years on assembly, both Z80 and 8086. This was followed by a couple of years in COBOL, before I graduated to UNIX and C, where I've been comfortable ever since.

85 points by ikari_pl 3y ago

Diving into the history of higher level programming languages in the 80s, with most focus on Pascal, some on C, and a honorable mention of Forth. By continuing the spirit of "how come things we have today are the way they are", the article aims to answer why was Pascal so influential, what made it so popular, when did we get C and how was it different. It's also a follow-up to an article appreciated on Hacker News that focused on how original BASIC compared to competition (and why The Famous Quote isnt' adequate to the BASIC most of us may know) - https://news.ycombinator.com/item?id=38743062 https://news.ycombinator.com/item?id=38743062

PeterStuer 3y ago
Forth was a very natural transition if you came into programming from the RPN style HP41cv calculator, an iconic machine for it's time

unwind 3y ago

This looks like a fun historical view of programming in the 70s and 80s. The section about C, though, I'm sorry to say is littered with flaws and should be rewritten and/or proof-read by someone with more knowledge about the language. Not impressed.

guenthert 3y ago
Indeed. I noticed "Going further, as was a common convention in assembly to pass the return value in the A (for 8-bit, later AX for 16-bit, and EAX for 32-bit) register of the processor (because it is faster than by a value in memory),". That is not the reason. While on many architectures, except perhaps 6502, it was faster (before we had first level data caches as fast as registers), the reason was reentrancy. And the Z80A in an Amstrad CPC6128 was clocked with 4MHz, not 3.5MHz like a Speccie. (sorry, couldn't resist)
- flohofwoe 3y ago
  > And the Z80A in an Amstrad CPC6128 was clocked with 4MHz, not 3.5MHz... It's quite common to be mistaken though, because the Z80 in the CPC was not running at full 4 MHz speed (even though it's clocked at 4Mhz). The gate array would set the Z80's WAIT pin for 3 out of 4 clock cycles to create a window for the gate array to read pixel data from memory. This causes the Z80 to fall into a 4-cycle-aligned pattern, meaning that memory access machine cycles were stretched from 3 to 4 clock cycles, resulting in an effective speed of somewhere between 3 and 4 MHz (depending on the instruction mix, but probably averaging somewhere around 3.5 Mhz). > ... the reason was reentrancy. ...wouldn't passing the return value on the stack also allow reentrancy? Passing args and return values in registers instead of on the stack would definitely be faster, and on 8-bit CPUs, every clock cycle mattered.
  - ikari_pl 3y ago
    > ...wouldn't passing the return value on the stack also allow reentrancy? Passing args and return values in registers instead of on the stack would definitely be faster, and on 8-bit CPUs, every clock cycle mattered. But stack is memory. At least in these systems. So I think the problems could rise if we would throw concurrency into the picture, where you also have to synchronize the memory access, maybe?
    - flohofwoe 3y ago
      Switching to a different "thread" would also switch to a different stack though (although that would be kinda tricky on a 6502 where the stack is hardwired to the $100 page). Actual multithreading on an 8-bit CPU is a bit of an esoteric topic though, usually one only has to deal with interrupt service routines running concurrently :)
    - Jare 3y ago
      You're already using the stack for parameters without compromising reentrancy; using the stack for the return value is trivial. Just like parameters, it's easier and faster to use registers where possible in those old systems.

j4yav 3y ago

I learned BASIC and Pascal, and bounced off of pointers at C (went to Perl instead). I probably wouldn’t have learned Pascal without my first experience programming on a Pc that booted into BASIC.

rwmj 3y ago

C didn't work well on 8 bit CPUs (although it did exist). Z80 was infamously difficult to target for C code. See this stackoverflow topic: https://retrocomputing.stackexchange.com/questions/6095/why-do-c-to-z80-compilers-produce-poor-code https://retrocomputing.stackexchange.com/questions/6095/why-...

ikari_pl 3y ago
I've always thought the problem is that C today doesn't target 8-bits well? The optimizations that most sources mention mostly did not exist in the first version of C
- jacquesm 3y ago
  No, C on 8 bits was terrible. You could get it to work but the compilers were slow and the code was bloated compared to assembly.
  - kjs3 3y ago
    And many/most of them were subsets of the C you'd get on, say, a PDP-11, at the time (although I understand they got better over time). That was what always put me off using C on the 8-bitters. Turbo Pascal on the other hand.......
  - shrimp_emoji 3y ago
    Even in the '90s, Diablo was a mix of C and assembly for the bits that C was too slow for! I've heard it said that, if they had the C compilers of today back then, the C code might've been good enough -- hardware being constant -- for them to have totally ditched the assembly, but I don't know how true that is.
    - jacquesm 3y ago
      Yes, but those C compilers of today run on the hardware of today! You wouldn't have been able to compile those C compilers to the point of efficiency required to build them in the first place. Lots of technology is like that. In order to do VLSI you need to do LSI, in order to do LSI you need MSI and so on all the way back to thin film circuits and then individual components. You can't normally skip such steps it's all incremental improvement on what's already there. In software it isn't much different and that software rode in lock-step with the hardware. The best I could do on a relatively fast micro of the 80's in terms of control, expression and eventually execution speed was a very nice macro assembler and given the speed of the storage devices and the raw clock speed of the CPU that was an accomplishment in itself. It pretty much maxed out the hardware. In spite of using clever stuff (hash tables for symbol lookups for instance, which ate up some of that precious memory, RAM disks etc) it still gook a good bit of time to assemble a 16K ROM image. But then I got an Atari ST with a whopping 1M of RAM, a 10 MB hard drive and Mark Williams excellent C compiler and it was off to the races. That was a real game changer for me.

rurban 3y ago

We also had Smalltalk, Prolog (esp. Visual Prolog) or Lisp.

paleface 3y ago

The linked Forth article, is a good read - I haven’t seen it before, either!

anta40 3y ago

Somethink I never think about: "It wasn’t always that easy to develop a program and run it on the same machine" Really? Of course I'm not talking about embedded system. But PC in the 70s/80s, like Apple II, ZX-80, TRS-80 etc etc. I guess we, 90s kids, are too spoiled :)

mysterydip 3y ago
I've been reading the ZX Spectrum Visual Compendium from Bitmap Books (https://www.bitmapbooks.com/products/sinclair-zx-spectrum-a-visual-compendium https://www.bitmapbooks.com/products/sinclair-zx-spectrum-a-...) and it has a lot of developer anecdotes in there. One of them (Clive Townsend) was talking about their development process: "The original Saboteur! code was written on an actual Spectrum so everything - the source code, assembler program, and object code - had to be in memory at the same time. I'd work on a routine, compile it, then save it. To test it, I'd reset the Spectrum and load the newly compiled routine along with other necessary code, graphics and data. After testing, I'd reset the Spectrum again and re-load my source code and the assembler program. All from cassette! Nightmare!"
- ikari_pl 3y ago
  Sometimes you could have something plugged into the extension port to snapshot the memory, so you can switch easier, AND not lose your changes. It sounds horrible NOT to have it when writing a game like that (I love Sabouteur! Spent more time playing the 2nd part :))

PeterStuer 3y ago

I do not remember anyone on the Mac's using Turbo Pascal, as there was a far superior offering named Lightspeed Pascal by Think Technologies. As I remember it, it would take Borland the better part of a decade to catch up to the level of Pascal IDE quality Think offered in 1986.

ikari_pl 3y ago
Borland never really cared to support Turbo Pascal for Mac, from what I've read. Most of TP popularity is from the PC market after all
nxobject 3y ago
THINK Pascal and the THINK Reference was fantastic – instant compilation times, live debugging with one of the best symbolic debuggers I've ever used (complete with live statement and expression evaluation), concise and organized documentation of the Toolbox at your fingertips, complete with examples. The equal of Turbo Pascal on the Macintosh. The Macintosh Toolbox had, early on, a reputation for being a little bewildering with a lot of new system libraries to handle (memory management, resource management, UI/TextEdit, DIY event dispatching... it seems strange to explain to people how we would have to manually detect menu events based on location, and then manually respond to menu events), but THINK Pascal gave you a lot of courage.

tromp 3y ago

Yes, we had Pascal and C in the 80s. But what kid growing up in the 80s would go out of their way to purchase a Pascal compiler and learn an academically oriented language when their home computer comes with a very accessible built in programming language, providing direct access to sound and graphics and all the things they need to program their very own game? That most of their friends also had access to and for which the computer magazines at the time provided program listings with detailed explanations? The rare kid that wanted to wring out more performance than BASIC could provide was happy to explore the depths of programming in assembly. I know I had my share of fun making a connect-4 player in Z80 assembly that used the color attribute memory on the ZX Spectrum to search all variations. Learning Pascal a few years later in my CS studies was early enough for me.

pjmlp 3y ago
You would buy, or rent from the local library, a book for ZX Spectrum and type that Pascal compiler source code in. https://worldofspectrum.net/pub/sinclair/books-pics/p/PascalAufDemZXSpectrum.jpg https://worldofspectrum.net/pub/sinclair/books-pics/p/Pascal...
- jacquesm 3y ago
  That never happened. At least, not in my circles. The progression was typically Basic of some variety (whatever your system shipped with), peek & poke, machine code, assembler and later on either C or Turbo pascal assuming enough time had passed. Pascal on 8 bit was just too damn slow compared to the alternatives to be very useful and compile times were horrendous. Even the university students that had access to Pascal compilers for the most part only used them to turn in their assignments and avoided it for everything else. I did a little contest with a friend: we both wrote a chess program, he wrote his state of the art with a ton of optimizations in Pascal, I wrote mine in assembler. His program never stood a chance against a very simplistic implementation that only had minimax and a greedy (strictly material based) evaluation routine. Good times :)
  - stevekemp 3y ago

ofrzeta 3y ago

On the Atari ST (and the Amiga I am told) there were several Modula compilers available. You can download the source of the Megamax Modula-2 compiler from Thomas Tempelmann's homepage: http://www.tempel.org/files-d.html http://www.tempel.org/files-d.html

jhbadger 3y ago
Logitech (yes, the mice/keyboard company) also had a Modula-2 compiler/IDE for the PC as well in the mid 1980s. It supported the mouse, unsurprisingly for Logitech, even though mouse support on DOS wasn't that common yet. http://www.edm2.com/index.php/Logitech_Modula-2 http://www.edm2.com/index.php/Logitech_Modula-2
cmrdporcupine 3y ago
I had Personal Pascal and Megamax Modula-2 on my ST. Great software. But most people used GFA Basic, which was structured, compiling, BASIC with a Pascal sheen to it. Or, if they were serious, they used C. The API for the AES and VDI was developed with C in mind, because it was written in C. Void pointers all over, stuff that Wirth-languages despised. GEM/TOS bindings for other languages were terrible, I never got Modula-2 to work well for GEM development, it simply didn't ship with bindings for it. I didn't have a C compiler, so to do anything GEM-ish... it was GFA. But TFA is about the early 80s, and is out to lunch. Only professionals with expensive PCs had access to C and Pascal in the early 80s. Though I guess there were Pascal dialects in the Apple II world, they weren't that commonly used.

baz00 3y ago

No thanks! The compilers were extremely slow. If you wanted to hang around all day waiting for your stuff to compile then that was fine but it wasn't a solution for most of us. Plus the majority of the market was 8-bit machines. In the early 80s I wrote a lot of code in (BBC) BASIC and assembly. That was extremely fast to build and run, with optimisations where necessary. For example to use a CP/M machine at the time with turbo pascal, it'd take at least 10 minutes to get the machine up and compile something simple. On the BBC Micro at the time, my preferred machine, there would be working code in under a minute. That was a big gain. They were used for test automation at the time over HP-IB (IEEE-488), eventually replaced with PCs running 16-bit Visual Basic on Windows.

mikewarot 3y ago
>The compilers were extremely slow. I'm sorry you had such a slow machine to put up with. You didn't get to experience the joy that was Turbo Pascal on an 8 Mhz 286 with 0 wait states. You'd get almost instant compile/run cycles. It was great!
- cmrdporcupine 3y ago
  ... That's not early 80s though :-)
  - mikewarot 3y ago
    1984 ish

livrem 3y ago

A bit strange to mention Lazarus as if it was a thing of the past ("could never match...") but then also mention a few lines below that the last release was a week ago (almost two weeks now). It looks to me like the project is reasonably active? https://wiki.lazarus.freepascal.org/Lazarus_3.0_release_notes https://wiki.lazarus.freepascal.org/Lazarus_3.0_release_note...

ikari_pl 3y ago
It's more of a statement about life of not-mainstream open source projects vs what companies with many dollars can do. From the two, it's Delphi that's dead to me ;-)

MichaelRo 3y ago

>> Late 70s and 80s: forget BASIC, we had Pascal and C Well for once, PCs were ridiculously expensive back in the day so that rules out using the PC version of Borland Pascal / C. I had them in school, but we had mostly CP/M based machines and only two PCs. A 286 AT and an 8086 XT. If I recall correctly we had Borland Pascal 5.0 and it worked blazingly fast on both machines. Then some dumbass decided to upgrade to Borland Pascal 6.0 and wiped out 5.0 from the XT machine (lack of space, maybe? but mostly supidity) and replaced it with 6.0. It was horrendously slow. Like I got my first look into today's "enterprise" compile times :) Pressing F5 (or F9 or something to compile, I don't recall the exact key) took about a minute to start showing the compilation dialog. Several more minutes to compile. Compared to instantaneous on 5.0. Rendered the whole thing unusable on the XT. On the other hand I hated working on school's computers. They were overcrowded, too few for too many students and I always had barely enough time to type the examination programs (I was studying computer science) needed to get my grades, never enough time to fiddle and experiment. Or game. So for that I used my dear home computer, a ZX-Spectrum compatible clone manufactured locally: http://retroit.ro/wp-content/uploads/2019/12/hc-85-maro-678x381.jpg http://retroit.ro/wp-content/uploads/2019/12/hc-85-maro-678x... Initially I did BASIC but as time progressed, I needed more speed and interpreted BASIC was hopelessly slow. I wanted to program TETRIS actually :) So I switched to Pascal, more precisely HiSoft Pascal for ZX Spectrum. Here's the book I learned from, there was no Internet back then so the book was quintesential: https://imgur.com/a/qweDG2E https://imgur.com/a/qweDG2E Actually that's also where I learned and understood memory management. Linked lists, allocation, deallocation. Before C, for me there was Pascal. One thing that blew my mind and didn't understood it until I programmed and ran it with my own hands was recursively referring to the defined structure ... in the very structure. You know the C definition: typedef struct node { int val; struct node * next; } node_t; How the heck can you refer to something that's not yet defined in a way, I was thinking. So, I eventually implemented that TETRIS in Pascal and I've no idea how I did it without a debugger... I guess with print statements and just thinking with pen an paper. Worked well enough although it did crash on occasion and I never figured out why :) Anyhow, sometime later I got my hands on HiSoft's compiler for BASIC. Very cool thing, you'd load the compiler from cassette then you'd write your program in the regular ZX-Spectrum BASIC and then RANDOMIZE USR <some number> (address of loaded compiler) and the thing would put machine code somewhere in the remaining memory and provide you with the address and size. So you could save the machine code directly on cassette and run it directly next time. And all that in less than 40Kb of memory for BASIC code, compiler code, resulting compiled program and stacks etc. Believe it or not, I rewrote that TETRIS in BASIC and was able to compile and run it. Bonus it never crashed, I guess the BASIC version was inherently more stable.

tored 3y ago

There is an unwarranted hate against BASIC. BASIC has of course also evolved since then and you can still write professional software in numerous BASIC dialects just as in Pascal. Few years ago I evaluated FreePascal for writing desktop applications, I ended up instead with the BASIC dialect PureBasic (albeit commercial), better out of the box experience. Pascal is also slightly more verbose than BASIC.

kjs3 3y ago
Anyone who thinks BASIC is useless or a kids game has never seen what can be done with something like HP Rocky Mountain BASIC.
jackhack 3y ago
You could absolutely write professional software in BASIC. As a kid I wrote my first "professional" product in Applesoft. My family used to rent videotapes (Betamax!) from a little video shop on the corner. They kept records of who rented what on paper cards -- they literally wrote in the customer name and phone # on a paper card and put it in a box. They would go through that box each day and see what was overdue, calling the customer to remind them to return. I was a curious kid so I asked the owner "how do you keep track of everything? Do you really go through all those cards every day to see what is due? Does anything get lost?" I told the owner "I can put all this on a computer and make it so you'll never lose track of who has what" and he said "tell you what, you create that and I'll buy it!" I wrote a little program in Applesoft basic, using a light pen, that could keep track of the customers and video titles -- what was available, what was out, what was due, and what was overdue. The owner LOVED it! Customers had a "membership" card with a bar code on it.The clerk just had to scan the member card, a barcode for "checkout" (taped to the side of the screen) and then the bar code on the tape. No keyboard. Happy beep meant success. Check-in was the same process. And once a day they could check the "overdue" screen to see who to contact. The customer name, phone number, and name of movie was right there. They weren't crazy about entering the names of all the tapes and sticking the bar code stickers on them, but once complete business was so much easier & faster. It took me the better part of the summer to write this and I was paid $200 (a fortune for a 12 year old kid!) and given "free movie rentals for life." The owner was good to his word, and even after he bought a movie rental franchise many years later (maybe Blockbuster?) my family still enjoyed free rentals though the apple 2 was long since retired.

black_13 3y ago

[dead]

cmrdporcupine 3y ago

Phh... Wealthy PC owners had Pascal and C. In the early 80s, us plebs had 8-bits that ran BASIC or we programmed assembly. Hell, my parents wouldn't even pay for an assembler for my VIC-20 so I programmed 6502 machine code by hand with POKE and DATA statements with the explicit opcodes. Sure, if your dad was an accountant or something, and let you use his PC, you might have access to Turbo Pascal or something, I dunno. But that was a very expensive machine, and market penetration on 16-bit machines was extremely low until the mid80s. Late 80s, different story.

paleface 3y ago
Heh, how the other half live!… My memory of programming in the eighties, was a pad of ruled paper, and a rotation of Usborne books from the library.

whartung 3y ago

Interpreted BASICs (such as BASIC-PLUS on DEC, MS-BASIC on micros) big benefit at the time was speeding up the develop cycle by working with source code in RAM, and running directly from it, thus skipping the edit/load cycle across crushingly slow I/O. Turbo Pascal on CP/Ms breakthrough was bringing a similar experience to a compiled language. So you got fast turn arounds, with better performing code. Turbo did this by compiling from RAM, to RAM, and skipping the link process. The Turbo runtime was already loaded in RAM and used by Turbo itself, so the binary just called already RAM resident routines. When the final COM file was saved, it simply bulk copied the runtime to disk and attached the compiled code at the end. This is one reason why even small programs created large COM files with Turbo, they all bundled the entire runtime. There's nothing particularly slow about a C compiler, but when you wrap it in reading from disk and writing to disk, or, even worse, writing assembly that then had to be assembled, then stacking on a link step, and turn around craters. The practice of several C files having to be linked together involved yet more I/O. Ostensibly there was a benefit of not having to recompile all of the files all of the time (but note, especially on CP/M at the time there were no timestamps on files, so "make" wasn't a real option to do this), hoping for a net win. Linking also let your program include only the routines it truly needed, reducing footprint. Linkers have lots of benefits, performance during the dev cycle is simply not one of them. As you started to write larger Turbo programs, utilizing include files, and having to write to disk (because the RAM wasn't enough for your code any longer), and Turbo most certainly slowed down. But still not quite as bad as something like C as, again, there was no real linking phase. I have, I think, a 1200 line Pascal program, in several include files, that builds on a 4Mhz (simulated) Z80 and, yea, you can sit there watching the lines tick by. Doesn't take minutes, but it's definitely a time to get a sip of coffee and catch breath looking out the window. The Atari series had ACTION, which was a very Turbo like system using a simple Algol-esque language. It, too, had a bundled runtime on the ROM cartridge, with a very fast compiler. I tried a C compiler on the Atari, and tossed it after my first build. It was absolutely horrific. The Atari (along with the Commodores) had notoriously slow disk drives.

simonblack 3y ago

I was a little different. After a couple of years or so on BASIC from 1979 onwards, and a very tiny dabble with Pascal, I spent the next four or five years on assembly, both Z80 and 8086. This was followed by a couple of years in COBOL, before I graduated to UNIX and C, where I've been comfortable ever since.