We used Turbo C++ in my HS computer science class, but the AP test was still in Pascal at the time. My dad had an old copy of Turbo Pascal, so I used that to learn enough pascal to pass the test. I was completely blown away by the compilation times. In class, we fought over who got the 2 486 DX2s because you could compile simple programs in under a minute on it. On my wimpy AM386 at home Turbo Pascal compiled from scratch in seconds and did incremental compiles instantaneously.
A couple years later, I encountered common lisp for the first time; it was even better because you could recompile single functions. To this date, I still think very short iteration time is a super-power for program design.
The real question, what these kind of articles do not ask, is why Turbo Pascal was smaller?
Hand written assembly was optimised, Pascal is easy to compile language, but there are a lot of other things
- Segmented 16 bit pointers
- No graphics or images
- Limited OS - no glibc, could only save A: and C: drives
- Computers could not hibernate or sleep
- Computers did not have periheral devices or needed special software: printer, mouse
- No network
- No multitasking
- No portability
For the editor itself
- No autocomplete
- No colours
- Not very useful error messages
- VI like navigation experience (got much better in 5 years with Turbo Vision IDE framework)
Also
- All documentation was in a dead tree format
For the good reference point on sizes, the bible text is 4-5 MB.
"no glibc" makes programs bigger; they have to contain their own library. Presumably, that small TC executable made some DOS/BIOS calls; that would be its OS-supplied library. That gives you things like file I/O and reading the keyboard.
Anyway I don't think you're quite explaining it (in spite of a good effort and nice points) because, look, the mere hash table module in my TXR language has 30K of machine code. This happens to be 32 bit x86:
$ size opt/hash.o
text data bss dec hex filename
31558 100 8 31666 7bb2 opt/hash.o
It's just a bunch of hash table functions.
I cannot say, oh, my hash table functions are almost bigger than Turbo Pascal 3 for MS-DOS because of documentation (there isn't any), autocomplete (none and not applicable) or because I have networking, multitasking (also not applicable).
I mean, Turbo Pascal 3 probably has some internal hash table itself, and provides an entire language and IDE, in the same space as my hash table stuff.
/bin/ls on Debian 11, x86_64:
size /bin/ls
text data bss dec hex filename
131876 4728 4824 141428 22874 /bin/ls
What are the amazing features in ls? It does ANSI color and probably something with extended attributes; so, ooooh! that must be why it's four times bigger than Turbo Pascal 3?
I'm not sure what code size has to do with networking and multitasking. Size coding requires technique and caring about size. In the case of hash.c it's likely because the hash function has unrolled loops and is being inlined into all the functions that use it. It'd also reduce size a lot if a loop were used to iterate over the names and function pointers during initialization. I normally gain an intuition for these kinds of things because I have a keyboard shortcut that shows me the assembly of whatever code I'm writing, but I had to implement that feature into my editor myself, so I'm not sure how many other people do that. Bloat also isn't a mandatory price of the modern age we love. For instance, languages exist for 64-bit architecture that have binaries less than 400 bytes in size.
You are comparing apples to oranges. Fortran I developed in 1950s was 23K instructions. That was without fancy IDE and after spending 18 person years to develop. So, relatively, TP was obviously a very very tight code. Another comparison is GW Basic which was 80KB and so more than 2X in siz even though Basic is simpler language.
What bugs me is that even though vast majority of work is now outsourced to OS and external libraries and tremendous advances are made in compilation tech, our generated binary sizes are no where close to hand coded assembly. I mean not even close. For example, hello world manual assembly should take about 142 bytes. However, even assembler will spit out whooping 9KB binary for hello world in assembly language! Hello world in C will cost you a binary size of mind numbing 2000KB. https://drewdevault.com/2020/01/04/Slow.html
> No autocomplete - No colours - Not very useful error messages
There were colours. And the library was small and well documented with embedded help files containing examples. So autocomplete was no blocker. Errors were fine as far as I remember. Perhaps you mean turbo c++?
My Thinkpad 300 would like a word with you.
It can sleep to RAM and hibernate, done via apm if OS supports it or through keys, but basically everything is done by the BIOS and works fine with DOS.
Turbo Pascal taught me what is the minimum acceptable tooling for any programming language, good OOP programming foundations (Turbo Vision and OWL later on), systems programming doesn't need to be like the C mess, good compilation speed and modular programming.
Borlando Turbos included amazing docs accessible within the IDE, with useful code examples one could quickly copy+paste and try.
Great time to learn, before msdn collection, or the web as we know it now.
I was still at high school though so my graphical shell was pretty limited. I’m still pretty impressed I pulled off what I did though. Just goes to show how easy Pascal was.
I have started building an IDE for Algorand smart contracts (TEAL/PyTEAL) inspired by Turbo Pascal. It will go up on TurboTEAL.com within a couple of months. A lot of the core such as the Python -> PyTeal transpiler is already working. It will have the same look, built in instant context sensitive help, and a few other things.
Being stuck in a 3rd world country (with some sanctions at the time) I had trouble finding compilers, but I found a version of Turbo Pascal 6 on a BBS disc my brother had bought.
It was pretty much how I learned to program, but I can't say I miss the days when the program would crash, then you insert a blank line randomly in the source code and it would work again.
In comparison, you can get TCC (tiny compiler) which is 100KB in size and can produce 32/64 bit code, compile the Linux kernel and probably better optimizations.
TCC is non-optimizing and its 64-bit implementation was contributed by someone else and never finished. Borland Pascal has an IDE. Their executable has 7.141258 bits per byte of entropy. That's even higher than SectorLISP, a 436 byte development environment, which only has 6.300498 bits per byte of entropy. I wish I could travel back in time and the people who wrote Turbo Pascal could probably teach me a thing or two about size optimization tricks.
> I wish I could travel back in time and the people who wrote Turbo Pascal could probably teach me a thing or two about size optimization tricks.
Uh you’re doing fine. You are a complete beast and deeply inspiring.
P.S. At Microsoft I worked with Anders Hejlsberg, who created Turbo Pascal (and C#, typescript, etc.) I took full advantage of my position and peppered him with questions about compiler writing, which he endured with grace and good humor.
We used Turbo C++ in my HS computer science class, but the AP test was still in Pascal at the time. My dad had an old copy of Turbo Pascal, so I used that to learn enough pascal to pass the test. I was completely blown away by the compilation times. In class, we fought over who got the 2 486 DX2s because you could compile simple programs in under a minute on it. On my wimpy AM386 at home Turbo Pascal compiled from scratch in seconds and did incremental compiles instantaneously.
A couple years later, I encountered common lisp for the first time; it was even better because you could recompile single functions. To this date, I still think very short iteration time is a super-power for program design.
I have a project going that tries to bring back ultra short compilation times:
https://github.com/robertmuth/Cwerg
The real question, what these kind of articles do not ask, is why Turbo Pascal was smaller?
Hand written assembly was optimised, Pascal is easy to compile language, but there are a lot of other things
- Segmented 16 bit pointers - No graphics or images - Limited OS - no glibc, could only save A: and C: drives - Computers could not hibernate or sleep - Computers did not have periheral devices or needed special software: printer, mouse - No network - No multitasking - No portability
For the editor itself
- No autocomplete - No colours - Not very useful error messages - VI like navigation experience (got much better in 5 years with Turbo Vision IDE framework)
Also
- All documentation was in a dead tree format
For the good reference point on sizes, the bible text is 4-5 MB.
"no glibc" makes programs bigger; they have to contain their own library. Presumably, that small TC executable made some DOS/BIOS calls; that would be its OS-supplied library. That gives you things like file I/O and reading the keyboard.
Anyway I don't think you're quite explaining it (in spite of a good effort and nice points) because, look, the mere hash table module in my TXR language has 30K of machine code. This happens to be 32 bit x86:
It's just a bunch of hash table functions.
I cannot say, oh, my hash table functions are almost bigger than Turbo Pascal 3 for MS-DOS because of documentation (there isn't any), autocomplete (none and not applicable) or because I have networking, multitasking (also not applicable).
I mean, Turbo Pascal 3 probably has some internal hash table itself, and provides an entire language and IDE, in the same space as my hash table stuff.
/bin/ls on Debian 11, x86_64:
What are the amazing features in ls? It does ANSI color and probably something with extended attributes; so, ooooh! that must be why it's four times bigger than Turbo Pascal 3?
I'm not sure what code size has to do with networking and multitasking. Size coding requires technique and caring about size. In the case of hash.c it's likely because the hash function has unrolled loops and is being inlined into all the functions that use it. It'd also reduce size a lot if a loop were used to iterate over the names and function pointers during initialization. I normally gain an intuition for these kinds of things because I have a keyboard shortcut that shows me the assembly of whatever code I'm writing, but I had to implement that feature into my editor myself, so I'm not sure how many other people do that. Bloat also isn't a mandatory price of the modern age we love. For instance, languages exist for 64-bit architecture that have binaries less than 400 bytes in size.
1 reply →
You are comparing apples to oranges. Fortran I developed in 1950s was 23K instructions. That was without fancy IDE and after spending 18 person years to develop. So, relatively, TP was obviously a very very tight code. Another comparison is GW Basic which was 80KB and so more than 2X in siz even though Basic is simpler language.
What bugs me is that even though vast majority of work is now outsourced to OS and external libraries and tremendous advances are made in compilation tech, our generated binary sizes are no where close to hand coded assembly. I mean not even close. For example, hello world manual assembly should take about 142 bytes. However, even assembler will spit out whooping 9KB binary for hello world in assembly language! Hello world in C will cost you a binary size of mind numbing 2000KB. https://drewdevault.com/2020/01/04/Slow.html
So put this perspective.
> Hello world in C will cost you a binary size of mind numbing 2000KB
2MB? I'm not sure where that number comes from. Maybe I misunderstand what you mean. I just tried compiling
with gcc on a Mac. The binary is 13340 bytes. Surprisingly big, but not 2000000 bytes! 1/150 that size.
> No autocomplete - No colours - Not very useful error messages
There were colours. And the library was small and well documented with embedded help files containing examples. So autocomplete was no blocker. Errors were fine as far as I remember. Perhaps you mean turbo c++?
Not in Turbo Pascal 3.0 though.
> Computers could not hibernate or sleep
My Thinkpad 300 would like a word with you. It can sleep to RAM and hibernate, done via apm if OS supports it or through keys, but basically everything is done by the BIOS and works fine with DOS.
As impressive as that laptop was, it was released in the 90s and whereas the version of TP we are discussing was the 80s.
It still begs the question why OS X’s touch command is larger. :)
Related:
Things That Turbo Pascal Is Smaller Than (2011) - https://news.ycombinator.com/item?id=3175629 - Oct 2011 (114 comments)
Amusing article.
Turbo Pascal was an awesome IDE. I remember writing a lots of DOS software for it. Including a graphical shell (like early Windows).
Turbo Pascal taught me what is the minimum acceptable tooling for any programming language, good OOP programming foundations (Turbo Vision and OWL later on), systems programming doesn't need to be like the C mess, good compilation speed and modular programming.
All of that in PCs running MS-DOS in 1 MB RAM.
Thanks Borland.
Borlando Turbos included amazing docs accessible within the IDE, with useful code examples one could quickly copy+paste and try. Great time to learn, before msdn collection, or the web as we know it now.
With a DOS extender you could do a proper GUI shell and not worry about memory constraints if you had the memory.
I was still at high school though so my graphical shell was pretty limited. I’m still pretty impressed I pulled off what I did though. Just goes to show how easy Pascal was.
I have started building an IDE for Algorand smart contracts (TEAL/PyTEAL) inspired by Turbo Pascal. It will go up on TurboTEAL.com within a couple of months. A lot of the core such as the Python -> PyTeal transpiler is already working. It will have the same look, built in instant context sensitive help, and a few other things.
Being stuck in a 3rd world country (with some sanctions at the time) I had trouble finding compilers, but I found a version of Turbo Pascal 6 on a BBS disc my brother had bought.
It was pretty much how I learned to program, but I can't say I miss the days when the program would crash, then you insert a blank line randomly in the source code and it would work again.
For comparison, how large were EDLIN.COM, EDIT.EXE, QBASIC.EXE, and QB.EXE?
Now do "Things libLLVM (or libGCC) Is Larger Than"
Shanghai, Australia, and Saturn
In comparison, you can get TCC (tiny compiler) which is 100KB in size and can produce 32/64 bit code, compile the Linux kernel and probably better optimizations.
https://en.wikipedia.org/wiki/Tiny_C_Compiler
TCC is non-optimizing and its 64-bit implementation was contributed by someone else and never finished. Borland Pascal has an IDE. Their executable has 7.141258 bits per byte of entropy. That's even higher than SectorLISP, a 436 byte development environment, which only has 6.300498 bits per byte of entropy. I wish I could travel back in time and the people who wrote Turbo Pascal could probably teach me a thing or two about size optimization tricks.
> I wish I could travel back in time and the people who wrote Turbo Pascal could probably teach me a thing or two about size optimization tricks.
Uh you’re doing fine. You are a complete beast and deeply inspiring.
P.S. At Microsoft I worked with Anders Hejlsberg, who created Turbo Pascal (and C#, typescript, etc.) I took full advantage of my position and peppered him with questions about compiler writing, which he endured with grace and good humor.
1 reply →
How do you even define “entropy” of a program? It’s a byte stream where each byte is important.
3 replies →