Things That Turbo Pascal Is Smaller Than (2011) | Hacker News Reader

Things That Turbo Pascal Is Smaller Than (2011)

prog21.dadgum.com

68 pointsarkj32 comments

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.

> 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.

"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.

> For instance, languages exist for 64-bit architecture that have binaries less than 400 bytes in size.

In V (https://github.com/vlang/v/) for example, with the currently experimental native backend, you can produce executables, that are < 400 bytes:

    $ cat examples/hello_world.v
    println('Hello, World!')
    $ ./v -b native -o hw examples/hello_world.v
    $ ls -l hw
    -rwxrwxr-x 1 delian delian 183 Mar 13 17:51 hw
    $ ./hw
    Hello, World!

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

    #include <stdio.h>
    main(){
      printf("Hello, world\n");
    }

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.

It still begs the question why OS X’s touch command is larger. :)

Things That Turbo Pascal Is Smaller Than (2011) - https://news.ycombinator.com/item?id=22843140 - April 2020 (170 comments)

Things That Turbo Pascal Is Smaller Than (2011) - https://news.ycombinator.com/item?id=15104766 - Aug 2017 (15 comments)

Things That Turbo Pascal Is Smaller Than (2011) - https://news.ycombinator.com/item?id=11733610 - May 2016 (2 comments)

Things That Turbo Pascal is Smaller Than (2011) - https://news.ycombinator.com/item?id=4592997 - Sept 2012 (58 comments)

Things That Turbo Pascal is Smaller Than - 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).

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.

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 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.

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.

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.

Amazing opportunity. That software is just crazily good.

The question is even with him can we do that for other software.

How do you even define “entropy” of a program? It’s a byte stream where each byte is important.

Shannon entropy. https://github.com/jart/cosmopolitan/blob/master/libc/rand/m... You can even measure a program in terms of physics constants too.

Not trying to be rude here; Just trying to understand…

My issue is: sure, you can measure it, but does the result even make sense? Like, OK, we can compute how “random” an instruction stream is, but what purpose does it serve?

ISAs aren’t designed in a random manner, so what’s the point in comparing the entropy values of two different programs? The only thing I can think of is determining how compressible a given program is. But, that doesn’t tell us anything about performance/instruction (or byte).[a]

[a] For example, AES-512 can pack massive amounts of functionality into 5 or so bytes

It's useful to be able to calculate the density of information. For example, redbean uses it to determine whether or not it's profitable to apply gzip. It has nothing to do with isa. That's kind of the point. For example, I could have written a routine that said, don't bother compressing files with the extension jpeg, jpg, png, gz, zip, etc. or I could have used information theory like I did. Another cool example is I've never seen any code that has higher information density than biology.

Reply on news.ycombinator.com