ZZT's original source code was lost. Years later, Adrian Siekierka painstakingly reverse-engineered the original Pascal code till -- when compiled with the original version of Turbo Pascal -- produced a byte-for-byte identical executable. Amazing! Read more:

- https://blog.asie.pl/2020/08/reconstructing-zzt/

- https://news.ycombinator.com/item?id=22609474

- https://benhoyt.com/writings/zzt-in-go/

In the DOS era, Turbo Pascal was probably the easiest way to get into programming, outside of Basic. And on Windows 3.1/95, Delphi was eye-opening how easy GUI programming could be.

In many ways, I feel like we have gone backwards from there. How was it possible for the Turbo Pascal / Delphi compiler to produce a small binary for a fully-featured GUI program when today similarly powerful software is orders of magnitude larger in size?

That's because the "fully featured" of the 90s would be barely usable today. Or to rephrase: the frameworks and programs of today are not "similarly powerful" to the ones from the mid 90s, even if you just recompiled the app from 25 years ago with the current version of your framework (theoretically ;), it would gain support for unicode (codepages where just...), internationalization, accessability, support for networks (who still knows Novell?),... . Except for SAP, they somehow succeeded at combining the user-hostileness of the 90's UIs with the resource consumption of contemporary programs ;).

Turbo Pascal had been the language I used after BASIC, with which I started.

What you're arguing seems to be "you think you just wanted a banana, but it turns out the customers needed various banana sizes, levels of ripeness, even special alternative hypoallergenic banana breeds, so instead you get a gorilla to fetch you the right banana from the jungle for each situation."

I do think that there is truth to that, but to be honest I think that in an ideal world that would account for some these orders of magnitude, but leave out the majority of them. It is really, really easy to underestimate just how much faster and bigger computers have gotten in the last thirty years.

What I find a more compelling argument for the majority of this increase in software size and CPU usages is that letting the software bloat and slow down the level that the customers tolerate is a form of externalizing costs for developers. A lot of developer convenience comes at the cost of the end-user, imo. And even if the developers care, then the companies that employ them don't mind saving money that way.

Saying that in a thread about TurboPascal is strange. I mean notepad needs about 5 seconds to start on my windows 10 work computer. And the usability of windows 10 is ... not.

I suspect the issue is more of the runtime overhead of supporting it over the entire stack. That's a bigger cost that people would only want to pay if they were actually going to use it. So then you're in the situation of having to support unicode and non unicode versions of everything.

That isn't unicode though. That's a font. You can have bitmap unicode fonts if you want.

Let's put it this way. Say you have a unicode aware library and only ever use the ASCII compatible codes. You aren't using more space for fonts.

If you want to read a Chinese document, yes you would need to then install Chinese fonts. That would take space yes. But it's possible. If you only speak Chinese that's something you have to deal with.

Could you have a font for every unicode point at the same time, probably not, but most people don't need to read most code points most of the time.

On fitting in RAM's, in depends. From 1993 to 1998 the changes where huge.

And not only top-down procedural programming as was the norm for Pascal in those days, the Breakout demo was a lesson in OOP.

For anyone not up to date with ~30 year old exchange rates.

I seem to remember it being the late 90s so that's my bad memory.

Funny, we also call it t'euro in Yorkshire too!

So many modern systems do not have anything even close to this. I wonder if its inherent in the nature of the simpler x86 DOS based systems of the time, where its simply impossible with modern pace of change, cross-platform needs, and complexity to have something like that.

It was the only creative coding framework that had complete, offline documentation like that at the time I might add. OpenFrameworks is still mostly autogenerated stubs for example.

IMO it was one of the things that gave Processing an edge in educational contexts over all alternatives. I was pretty sad to see p5.js not fully continue that tradition and require that you go online to read the docs, and that it's not a static website but that text is rendered with javascript when you open it (still complete and with examples though).

https://processing.org/

https://p5js.org/

Although I think that p5.js is growing faster, as it's more accessible (browser IDE, not typed) and the artworks are easier to distribute online.

New languages tend to be open source and the ethos is read the source. Which I think is wrong.

This was a good couple of years before I discovered the Internet at university so there was no easy access to learning resources. I'd tried to pick up C a couple of times without much luck before learning TP, and it wasn't until after that that I then was able to transfer what I'd learnt from Pascal to C - although again that was aided by another great Borland product, C++ Builder :)

Today, good luck looking for examples.

I also learned Turbo Pascal without any books (I had a Basic book, because that came with the computer). But it was way easier. Drawing pixels was as easy as just selecting your (double buffered!) display mode and, well drawing pixels. Same with the reading of e.g. the joystick port or the mouse, you'd just read it.

A few years later, my Pascal background sailed me into a half-decade stint as a custom app dev working with Delphi. That, in turn, led to a job at Borland testing the Kylix and C++Builder IDEs. Good times.

I still miss Delphi. Nowadays it's normal to have IDE plugins to the point it's a dealbreaker if they don't exist. But at the time the idea of a component library and coding environment that was easily extensible in its own language was pure magic. I had so much fun playing with both VCL and the IDE itself.

It's a shame Borland left the grassroots devs behind in their quest for the enterprise market, and more or less killed any growth in community adoption. It was a really cool setup, at least through Delphi 7 or so.

A few years later at 16, I actually got paid for developing a small app for managing my dad's customers, paid by the company he worked for. Part of that money went into getting a legal version of TP6.

Good times :)

A belated license to be exact :P

After I started working, I had a hand in selecting Borland C++ as our in-house development platform, and we paid Borland a fortune in licensing fees. Which would have gone to Intel or another company if it were not for my, and other folks in my cohort's experience with pirated Borland products as students.

There is a lesson in there, somewhere.

(I had a mouse driver disc, 5.25, that wasn't pirated, it felt like something from a parallel universe with its machine-printed label)

I'm not sure how true this was, as I've yet to see any real official sources speaking about this myself but it seems like it was like that. But most of my thoughts about this comes from being in the piracy space back in the days so I really have no idea if this was ever a real thing or not.

To be more accurate, Lazarus is a GUI IDE for Free Pascal, not a successor. The same way Emacs can be an IDE for C that you'll compile with GCC.

I know, Delphi effectively replaced Turbo Pascal from the Borland side, even though Delphi could have been "just" an add-on to Turbo. They just didn't take that route.

A tour-de-force of its day, and it deserved all the acclimation that it got.

And that's how I learned that mature compilers are better than 1.0 release compilers.

A far cry from today’s complex build systems that take forever to compile a program which can do exactly the same thing.

Many years ago, I remember building FPC 2.0 something on a Windows PC (512 MB RAM) and it took no more than 5 minutes.

https://en.wikipedia.org/wiki/COM_file#DOS_binary_format

EXE (aka MZ) is using other memory models

https://devblogs.microsoft.com/oldnewthing/20200728-00/?p=10...

I know I've used it on CP/M first.

It was really, really fast.

https://www.tmssoftware.com/site/blogold.asp?post=759

I hope I was appreciative enough at the time, as I am now. That helped bootstrap my career.

What's this "PC-semi-compatible" of which you speak?

But soon, Flight Simulator became the benchmark for compatibility, and I think the final nail was that Lotus 1-2-3 required an actual PC compatible machine. That plus the rise of clone BIOSs pretty much ended the brief era of generic, 8088, non-PC compatible machines, save for niche domains.

An interesting artifact of this era was when Steve Ciarcia of BYTE magazine released his 8088 board, and it was not PC compatible. He made some different design decisions.

Halt and Catch Fire covers this. I could be wrong though.

https://www.imdb.com/title/tt2543312/

https://en.wikipedia.org/wiki/MBC-550

So a lot of “clones” may have been this close as the Columbia was.

In college I used a student loan to buy my first Apple computer, the Macintosh Plus. By chance there was a classified ad in the college newspaper for a copy of Turbo Pascal for the Mac — some professor was selling it for like $40 or something. I snagged it.

It had the manual, thankfully, but very simply tools for Macintosh development. No ResEdit, but the odd R-Maker app that expected you to create a Macintosh resource as a text file and then run it through the tool to create the resource fork.

My first few apps were Turbo Pascal implementations of algorithms from the Computer Recreations column of Scientific American (thankfully requiring little UI — a window and a few buttons typically).

Later I would learn of and move on to THINK Pascal — a much more Mac-centric IDE. Later still I would take the leap to THINK C....

But I will always look back on Turbo Pascal and remember it with fondness. It was a time when I was entering a wild new world and Turbo Pascal was there to hold the door open for me.

I recall writing programs large enough to require use of the overlay facility, which essentially let you page in different parts of your program under DOS.

I also recall meeting David Intersimone, a great ambassador of Borland, sometime in the 80s - might have been later 80s - when he visited my university as a guest of the local ACM chapter.

One day my dad brought home Turbo Pascal so I gave it a shot. I wrote Conway's Game of Life, and was shocked when it ran correctly the first time. Never wrote another line of BASICA.

Much later I turned pro and moved on to other languages, but my dad kept messing around with Pascal until he was in his 70s.

This overall "if it compiles it works" philosophy is quite common among Pascal-family languages, and derived languages like Ada. Though there is also PL/I if you want a language with a loosely Pascalish syntax that relies on the complete opposite design style - the one that was carried over to C and its derivatives.

Sigh. Kids nowadays, etc. Look up which was the original language ridiculed for its "belt-and-braces" approach to type safety, in contrast to C, the freewheeling language of Kewl H4xx0rs (although they weren't yet spelled that way).

Now excuse me, there's a cloud I have to go shake my fist at.

It was really common for people to stuff pointers in ints and ints in pointers and do all kinds of really abusive things with the memory system in C. It was all fun and games until the program died with nary a stack trace. (Stack traces were pretty amazing the first time I saw them!)

There were even big commercial libraries that did really odd stuff. Motif (big early Unix UI framework) did a lot of weird stuff.

Pascal was pretty straightforward and disciplined compared to that, although I'm sure developers who were too clever for their own good found ways to do silly things.

At work we had many, many thousands of lines manipulating strings, high and low level, and full project was over 300kLOC plus many heavy dependencies. We spent just a day or two to convert it to be Unicode capable.

Since we've had hardly any issues, and Unicode is not something we need to think about in the day-to-day.

"Scott MacGregor of Microsoft said that Bill Gates "couldn't understand why our stuff was so slow" compared to Turbo Pascal. "He would bring in poor Greg Whitten [programming director of Microsoft languages] and yell at him for half an hour" because their company was unable to defeat Kahn's small startup, MacGregor recalled.[21] " https://en.wikipedia.org/wiki/Turbo_Pascal

They tried this on a project at my workplace. After six months of money spent on "yelling", they finally started to fix the issues.

It did everything possible in memory, avoiding reading and writing of temporary files. Microsoft tools did it with the file I/O for multiple passes, a traditional solution for coping with limited RAM and applying optimization steps and targeting different processors.

Then the web came (and I got confused) and I've never regained such clarity in programming as with Delphi on my little Windows desktop.

But then at some point we got a copy of Turbo Pascal (my Dad was an engineer and was always bringing interesting stuff home for me to try) and I started banging on that. In my senior year of HS I got super into it when I took another class. I did the whole year's curriculum in a couple months and then wrote an asteroids clone in class. It kind of drove the teacher nuts cause he said he had nothing left to teach me and he got annoyed when I started sharing the program with other students and they were playing the game instead of working.

The one thing I remember not grokking when using TP was pointers. I wrote my whole asteroids program with fixed size arrays. I don't think it helped that I didn't really have anything great in terms of books and no one around me really understood how to use them well to talk to me about it. A year later when I started learning C/C++ in college I got it quick though. I didn't even switch to CS till after I decided where to attend, I had originally planned on studying Aeronautical Engineering and the whole Turbo Pascal adventure made me change my mind.

I keep wondering if I have a copy of that program sitting on a floppy disk and I could recover it. I don't actually own a computer with a floppy drive though, even though I might have an old internal floppy drive sitting in a box.

USB floppy drives are quite cheap to buy, and in my case it was totally worth the money!

Technojock's Turbo Toolkit?

It was a UI and eventually object toolkit for Pascal apps and it was pretty damn cool for the time.

There isn't much online about it, but everyone I knew who was working in TP or BP swore by this in the early 90s..

https://www.computerhistory.org/collections/catalog/10277966...

While the original colours are too intense for my taste, I do sometimes switch to the Noctis Azureus theme in VS Code when I find myself thinking of him.

More relevant to the thread at hand: Martin Odersky wrote Turbo Modula-2.

https://www.artima.com/articles/the-origins-of-scala

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

(as with C# vs Scala, Hejlsberg's Turbo Pascal was faster and more popular than Odersky's Turbo Modula-2)

Niklaus Wirth has done an immense work. From Euler to Oberon, passing by Modula, he is a great visionary and a decades determinant mind.

Happy Birthday Turbo Pascal. (TP means something else in the US).

I remember sitting at the living room table on many evenings, studying a stack of printed out source code. My task was to contribute to translating a bulletin board system called WWIV.

https://en.wikipedia.org/wiki/WWIV

I went on to study Turbo C, which came with a wonderfully informative manual also. That experience formed the foundation of my programming in the next decades (2~3).

https://www.contrapositivediary.com/?page_id=5070

I was blessed to have learnt TP before C.

Happy birthday Turbo Pascal!

Editor, compiler, debugger (separate full-screen output buffer alt-f5 iirc), graphics.

And oh complete stdlib docs that worked offline and in-app so you didn’t get out of “flow”. With copy-pastable examples in the help.

In a few MB.

I really don't know why languages like C, Java or JavaScript started to allow variable definitions everywhere. Needing to declare variables first leads to much cleaner functions.

But Python's leaky scopes are even worse than up-front declarations.

C89 allowed you to declare variables at the top of any block, not just functions, so you could declare variables that only exist within in if block. For example:

  if (flag) {
      int c;
      while ((c = getchar()) != EOF) {
          /* code */
      }
  }

I remember it looking like this: https://imgur.com/EuOVL8c

I briefly documented how to run Turbo Pascal 3.00A on a CP/M system a while back:

https://github.com/skx/z80-playground-cpm-fat/blob/main/TURB...

I'm doing that on a single-board Z80-based system, and it has to be said that writing pascal is a pleasure on such a machine. 64k of memory, and yet code compiles to real executables "instantly".

https://github.com/linker3000/Z80-Board/blob/master/snake.pa...

On my computer now, it's smaller than:

    - License.txt which comes with "TurboPascal (with DOSBox)"  (42,044 bytes)

    - sqlanywhere.vim, syntax highlighting file for the SQL dialect of SQL Anywhere (41,929 bytes)

    - parse.py, the URL parser in Python's urllib (42,057 bytes)

    - doc_testing.html the Rust By Example section on writing tests in comments (42,059 bytes)

    - pwd.exe (print working directory) in GitHub Desktop (42,296 bytes)

    - WindowsExplorer.admx the XML policy file describing the available
        settings in Windows Explorer (42,461 bytes)

It's also less than half the size of Xcode's PNG-compressed Retina application icon (83,056 bytes).

[1] This includes such gems as cat (40,848 bytes), tac (40,808 bytes), and tee (40,968 bytes).

[2] Where even /usr/bin/true weighs in at an astonishing 100,512 bytes, despite its entire text section disassembling to

    pushq %rbp
    movq %rsp, %rbp
    xorl %eax, %eax
    popq %rbp
    retq

    # zsh glob for regular files that are smaller
    print -l /usr/bin/*(.L-39731)  # Some ~500 results
    # Not interpreted or using system libraries
    file /usr/bin/*(.L-39731) | egrep -v '(script|dynamically)'  # 0 results

Thinking I'm probably a member of the last generation to have the magic experience of computers quiting the realm of science fiction, stuff we only saw at movies, to become a real world tool. People born after that time surely experience them as trivial, mundane stuff, one is used to since forever. For me, to this day, computers still feel a bit "magic", like flying cars, but that actually happened.

Man, this reminds me of amber screen monitors. I liked them better than the green screen ones, but somehow, the amber ones seemed to be much less popular, at least in areas where I was.

I will never forget how great it is to have some simple IDE with a "run" button/key, and build simple UI toys with points/lines/rectangles/... (what was it? tortoise? turtle? idk) for a school kid in that age. it was pure magic to bend pixels to my will.

I also spent quite a lot of time working on a type of rough wireframe 3d CAD editor in regular Turbo Pascal when I was in the 8th grade. I used equations I got from a little reference book my dad had brought from some garage sale or whatever to figure out how to do rotations and perspective.

We also used it in AP computer science class which was probably the highlight of high school for me.

I also liked JPI Modula 2: http://www.edm2.com/index.php/TopSpeed_Modula-2

However, Turbo-C rocked and allowed me to write code for DOS and Macintosh (MPW).

Pressing F9 would compile and run the selected "demo" super easily.

One of my earliest memories of using a computer, I think.

A couple of years later as a senior I used TP 3 using "Turbo Vision" to write a simple learning focused stats package for a professor's book (_Quality Control, 4th Edition_). I found out later that same package was being used for the production line of Jim Beam whiskey.

I also wrote a few shareware programs in TP and put them on Simtel in the early 90s. It was pretty cool getting random checks in the mail for utilities like "vgalogin", a Novell login frontend in VGA mode with a floating message of the day.

One day, a spiffy program called Compas Pascal appeared from Denmark, which Philippe Kahn bought and renamed Borland Turbo Pascal. Turbo Pascal was sort of shocking, since it basically did everything that IBM Pascal did, only it ran in about 33K of memory including the text editor. This was nothing short of astonishing. Even more astonishing was the fact that you could compile a small program in less than one second. It’s as if a company you had never heard of introduced a clone of the Buick LeSabre which could go 1,000,000 MPH and drive around the world on so little gasoline than an ant could drink it without getting sick.

Was so much fun writing it. The interface was fun to write. You could use it to tell apart isosceles triangles from equilateral triangles, for example.

The machine I used only had two floppy drives and still I recall TP was fast as a Ferrari.

It hadn't occurred to me that Pascal is actually younger than me, though not by much.

Pascal? Limited interest among system/OS kernel programmer nowadays. Still a fine language for building applications, though.

Later on me and a bunch of friends programmed a Sokoban-clone called “Project S” for MS-DOS: it used the graphics mode “X” for smooth scrolling; we even bought a commercial .mod player library for the sound effects and background music.

Whenever TP or Delphi get brought up, people wax nostalgic about how amazing they were, and that they are actually unmatched to this day in certain aspects.

I know the adoption of both got hurt by Borland's and Embarcadero's corporate shenanigans. However, FreePascal and Lazarus are reportedly just as good as Borland's products, but without the business issues. Despite that, they seem to barely get used. Why?

Byte Magazine, Philippe Kahn, Chaos Manor..

The Atari was from Germany, and I didn't know German at all, but I knew a bit of English. And so probably that was an important factor in why it was more attractive than whatever Basic or Assembler I had on the host system.

[1] https://en.wikipedia.org/wiki/GEM_(desktop_environment)

https://www.abandonwaredos.com/abandonware-screenshot.php?gi...

It didn't have the trademark Borland IDE yet, but along with this Pascal book from the library, I had hours of fun.

Computer Programming in Pascal the Easy Way https://a.co/d/3uPpxAw

put together a sieve of eratosthenes from algorithm as a kid and thought I was hot shit. something about watching a computer slowly tick through primes was so satisfying.

good times.

Wrote a couple of interesting things a few years later in TP 5.5, including a BBS/Kom system and a MUD (with 4 dial-in lines).

Found the source a few years back, was an interesting read a few decades later.

But part way through my class we switched from UCSD to Turbo Pascal, which only needed one floppy and just absolutely blazed. It was like a space age rocket ship.

https://en.wikipedia.org/wiki/Turbo_Pascal

..though you may have been able to run it with the Z-80 Softcard

Teacher would make us use vi in the first year. I still could not believe that you could just put a break point and stop the program in the middle of exectution to inspect variables. It was like magic to me.

50% is certainly due to the language Pascal itself. Niklaus Wirth designed the language in a way so it can be compiled in a single pass. In general the design of Pascal is in my opinion truly elegant and compared to other programming languages completely underrated. Wirth published a tiny version of his compiler written in Pascal itself in a 1976 book called "Algorithms + Data Structures = Programs".

In the late 70s Anders Hejlsberg took that version and translated it into assembly. He certainly must have changed the codegenerator since Wirth's version emitted bytecode for a tiny VM whereas Anders version produced machinecode, however if you take a closer look especially at the scanner and parser of Turbo Pascal and Wirth's version you can see that they are very similar. Back then Anders was not so much a language guy in my opinion but much more an assembly genius. And that resulted in the other 50% of why Turbo Pascal was so fast:

-) The entire compiler (scanner/parser/typechecker/codegenerator/ and later the linker) was written in assembly.

-) The state of the compiler was held as much as possible in cpu registers. If e.g. the parser needed a new token from the tokenstream, all registers were pushed to the stack and the scanner took over. After the scanner fetched the next token, registers where restored.

-) The choice of which register hold what was also very well thought through. Of course the cpu dictates that to a certain extent but still lots of elegant usage of the "si"/"di" register in combination of non repetitive lodsb/stosb instructions were done.

-) The entire "expression logic" (expression parsing / expression state / code generation for expressions) was kinda object oriented (yes, in assembly) with the "di" register hardwired as the "this" pointer. If the compiler needed to handle two expressions (left expression and right expression), then one was held in the "di" register and the other one in the "si" register. Since the "di" register was hardcoded, you will find lots of "xchg di,si" in the codebase before a "method" (a procedure with the "di" register as a "this" pointer) will be called.

-) Clearly the cpu registers were not enough in order to hold the entire state of the compiler so heavy use of global variables were made. Global variables have the advantage of not needing a register in order to access them (e.g. "inc word ptr [$1234]").

-) Parameter passing was done through registers and were possible stack frames were avoided (too expensive), meaning no local variables (still heavy usage of push/pop within a procedure, does this count as a local?)

-) Parameter passing done through registers allowed procedure chaining: instead of "call someOtherProc; retn" at the end of a procedure just "jmp someOtherProc" was used to a great extent.

-) Jump tables everywhere. In general the compiler was quite table driven.

-) Avoiding of strings as much as possible and if needed (parsing identifiers / using filenames) then avoiding to copy the strings around as much as possible, meaning all strings were held in global variables. The big exception here was of course the copying of the identifiers from the global variable into the symbol table.

-) Starting with Turbo Pascal 4.0, hash tables were used as symbol tables. Arena allocator for memory management.

I am sure I forgot a lot, I reverse engineered Turbo Pascal back in the late 90s. Most of the above applies to Turbo Pascal 7.0, but lots have not changed in earlier versions over time.

It is a shame that such a wonderful codebase is buried under the "closed source, proprietary software" label. It is clear that today nobody would write a compiler the way Turbo Pascal was written, not even in a high level language but the codebase has some many tricks, so many elegant solutions, that it is a real pity that this is not open source. Of course the codebase is on the web, just not the official one.

Thank you Anders Hejlsberg for such a wonderful piece of software.

> Jump tables everywhere. In general the compiler was quite table driven.

It would be interesting to see how this approach fares in the face of modern branch prediction on modern CPUs.

It's also largely irrelevant if you want optimized code generation, especially across multiple procedures, since that requires you to read abstract representations of the code into memory and deal with them globally which is the opposite of single-pass compilation.

I think it's uncontroversial that most fast, statically compiled languages benefit greatly from quick debug builds. It's just that very few of them are designed with this in mind.

> How do you do, fellow kids?

Archive.org has a copy though: https://web.archive.org/web/20231201001803/https://blog.marc...

Not that there is a lot of content on that page beyond the title.

30 years ago they had the same complaints like we have today

Happy Birthday

At some moment Borland released, free as in beer, the 3 and 5 versions. Binaries should be out there somewhere for those curious.

I'm sure young people would be surprised to see what 5.5 provided. The on-screen help was amazing: cut and paste useful examples from the help of many functions. And the instantaneous compiling... :)

I started with 4.0, so that's my baseline. Then 5.0 added overlays (IIRC) and 6.0 introduced Turbo Vision, which was a kind of magic to me :).

It's interesting how a _programming language/IDE_ can bring such warm feelings.

That philosophy probably seeped into Turbo Pascal to some degree.