TP is about the same size as Leor Zolman's C compiler for the 8080.
Fast-forward about seven years, and my company was looking at an interpreted BASIC implementation that took about 120K. Since this was supposed to live in ROM, you could think about it as Real Money. We dug into it and found all kinds of fat -- the usual 13 fear-based reimplementations of strlen and strcpy, about a zillion porting layers, endless amounts of cut-and-paste nonsense.
Somewhere between 1978 and 1985, the software industry's drive to be lean and mean on PCs died. I found myself writing 'sed' scripts to do peephole optimization on the intermediate assembly language of one of the C compilers we were using. It was pathetic.
Now, of course, I light my cigars with gigabytes. But in terms of actual cost, I'm still a cheap bastard and I probably don't spend any more money per year on CPUs, memory or storage than I did 30 years ago.
Had a chance last year to write a mission-critical hunk of code that /had/ to fit into 1920 bytes. I can't tell you how much fun that was.
Big bucketloads of business terms and concepts were stolen from the military.
Tactical advantages, strategic initiatives, anyone? And what about the ranking system in your average BigCo? They guys aren't called Sergeant or General but in effect it's the same.
I assumed he meant that a bunch of different programmers on the project thought they could avoid buffer overruns by either wrapping or completely re-implementing strlen/strcpy themselves. And probably not ending up any more safe than the standard versions.
mission-critical = consulting company, govt contractor, some organization with advanced bureaucracy
another question: why is sed in quotes?
tis true what you say. somewhere in that time, better hardware and better storage became an excuse to write worse software. and this has continued unchecked to the present.
programmers rejoice in the option to be lazy, sloppy and ignorant as if this signifies great advances in software. small advances perhaps relative to the huge advances in hardware and storage. but the real loss is one of skill.
Cool post, but I really like this paragraph from his "recovering programmer" page (linked in the sidebar):
"Somewhere along the lines, I realized I was looking at everything backward, from an implementation point of view, not from the perspective of a finished application, not considering the user first. And I realized that the inherent bitterness and negativity of programming arguments and technical defensiveness on the web were making me bitter and negative. I've consciously tried to rewind, to go back to when programming was a tool for implementing my visions, not its own end."
My go-to tool for sites without rss is http://feed43.com which I find easy to set up. Also important to point out that it plays nice with the sites it scrapes.
Example... Problem: I love lurking in ask.metafilter but only want to see threads that have a "best answer" marked. No official feed for that.
I'm also a huge fan of feed43 but I've managed to hit my head more than a few times on its limitations. Coincidentally just this weekend I wrote a teeny program as a replacement for feed43. I've got all my scrapers working with XPath (which I prefer for this situation) but it's very straightforward to add a new site. https://github.com/dgilman/atom_maker
so you're saying you're incapable or just too lazy to write your own "rss". the second s is for simple. you have all the tools you need in any base unix installation to automate this. it would take you minutes to do.
perhaps this is precisely the point of the recovering programmer comment. there is a reluctance to doing anything for oneself. fear of implementing something for yourself, your own way, because someone else has implemented it their way, placed it in a repository and it's managed to gain a following of users.
god bless the people who still enjoy diy and writing negative code.
Jesus, kid, you created an account 5 hours ago and already have -16 karma.
Get a grip, do not insult people unless you have a pretty good argument (and even then try not to), don't assume you're smarter, don't assume you're more hardcore or hard working, don't reply unless you've got something worthwhile to say and just be nice in general.
And implementing your own script that fetches content from the web and compiles a RSS feed is nice and all that, but you cannot make a generic crawler unless you want your feed filled with junk, so you'll have to customize it for each website in particular ... and why bother?
I mean, it's a privilege for a website to be read by me, the reader and this relationship rarely works both ways. And for valuable content that I might miss, that's why I'm still on Hacker News.
The 60 Minutes interview passed over the Apple II very briefly, but it was tremendously significant, for being one of the first computers popularized with a killer app.
Obviously, this wasn't the be-all and end-all, but VisiCalc did for sure sell many Apple II computers.
My first encounter with TP was as a high school senior in 89/90 in an AP programming course. What a blast.
Anyway, for those who miss it, the binaries for Borland TP/TC were released some time ago. Probably linked off the Wikipedia page.
The entire Borland Turbo series was cool. I had Turbo C, Pascal, and BASIC. Though Quick BASIC was the gold standard (and almost as fun), my heart will always have a soft spot for the original Borland DOS text-based IDEs.
In terms of utility value per byte of executable, that was such an interesting time. There were so many cool boot sector viruses and utils during that era. Anyone else remember that full-featured DOS-based .COM text editor that fit in a single floppy disk sector (512B)? The original text-based DESQView? So many, many neat programs given the limited hardware.
I really liked Turbo C... It was so nicely integrated: the editor, compiler, linker, visual debugger and excellent help system. It also had a nice paned IDE which actually looked good and made it very usable on those old DOS systems. [I had been using Alcyon C on the Atari ST and Lattice C on PC before I discovered Turbo C].
I always have been (and still am) a fan of the Borland series of developer tools - still using C++Builder today and still liking it.
"Philippe Kahn is a technology innovator and entrepreneur, who is credited with creating the first camera phone solution sharing pictures instantly on public networks. [...]
Kahn has founded four successful technology companies: His current company, Fullpower Technologies, of which he is CEO, Starfish Software, LightSurf Technologies, Borland. Fullpower provides solutions converging life sciences, wireless technology, sensing such as accelerometrics, nanotechnology and MotionX solutions. MotionX is the core technology that powers the Jawbone UP Band and the Nike+ GPS solutions."
I've learned English trying to understand documentation for Turbo Pascal 7 :) That, and playing games.
The first game I've made was written in Turbo Pascal in 13h. It was 2d arcade shooter, witch "asteroids" physics, tiled terrain, and diablo-like system of better weapons and enhancements to buy to your ship. And it was under 600 kb (including graphic), because I didn't knew how to use extended memory from Pascal. It was procedural code with few global variables that contained whole state of game. Code was just many procedures calling each other, and I divided it all into 2 files, because TP had limit on code size to 65536 bytes or sth like that. So I just cut and pasted a few procedures to the second file.
It was horrible code, but it worked, and was quite easy to modify despite the lack of architecture, because it was small. And because adding hacks when you have global variables is easy.
And most importantly - the game was quite fun to play. Unfortunately I've lost it in hard disk accident a few years ago.
Anyway - constraints are good for you, because you have some hard decisions made for you. And caring over implementation details more than about the result is bad. Now I program with all the cool technologies, use oo principles, design patterns etc, but it's less fun, and the result is most often unfinished project. I just can't keep motivation all the way from buidling foundations to making it a finished game.
Maybe that's because now I have job and less time (and energy) for hobby, or the fact that I'm doing more ambitious projects now. But I think it's also because now I overengineer. Maybe it's time to try small and ugly coding once again?
I'm trying to remember what all I used to run from a single 360k DOS floppy on a 640k 8088. I had at least DESQView, QEdit (which might be the editor you're thinking of), and a VT100 emulator.
Literally true. The 2600 had no framebuffer, because there wasn't enough RAM to fit the displayed screen. Stuff was generated at runtime as the raster progressed down the screen.
Turbo Pascal wasn't my introduction to programming, but it was where I started to find my way. The edit, compile, test was factors of magnitude faster than any other compilers.
Like the post says, it was very small, even for the time. The editor + compiler was smaller than most text editors and many non-programmers would use it as a word processor. At a time when a lot of systems only had 160KB floppy drives (and no hard-drive), the size made a difference.
One great feature I remember was you could add inline assembler for things that needed to be faster (my IBM clone processor was only 4.77MHz). I spent hours shaving cycles off my Conway's Life program that was half Pascal and half assembler.
I have much the same history as you. Started out in basic, but turbo pascal was what really got me going. I must admit that sometimes I really miss those days. But then I remember the horrible feeling when the diskette and the backup diskette with my hard work died, and suddenly I don't miss it that much after all.
While Turbo Pascal 3 was good, any true connoisseur would tell you that the pinnacle of Turbo Pascal evolution was the version 5.5 (with an exception of one annoying item in the editor †).
† The Find box was overlapping the highlighted search item when latter happened to be in the top visible line.
5.5 was the best - yellow font on blue background will always bring fond memories, may be I should set Eclipse to that :)
And then came 6.0 and Turbo Vision - out of a sudden it was so easy to write programs with windows. I still remember how I was reading printed out Turbo Vision manual.
Ahh the warm feelings of memories.
My first job involved Modula2 and the Brief editor. As I recalled Modula2 was supposed to be the successor of Pascal but I guess it never really took off. At least I've never met anyone who did any programming in Modula2.
This reminds me of .kkrieger[1], a game made by German demo group. It's a 3D game where the executable at 96k is smaller than most readme.txt files for other games.
If we cut down all the abstractions layers we're using every day we could create amazingly small program than ran at blistering pace. Of cause development time would explode :-)
That wasn't the only thing that was small about TP. The entire documentation for version 2 was a single book about 8 inches high, 5 1/2 inches wide and about an inch think. You could learn the entire language, IDE, library, and debugger in a weekend.
Only six months before I met TP I had been using punch cards on the University's mainframe. TP2 was pure shock and awe.
According to the OP, "You could learn the entire language, IDE, library, and debugger in a weekend." This implies that the manual covers a lot more ground than The C Programming Language, which (AFAIK) doesn't say anything about Emacs, GDB, GCC, sockets...
You are assuming i386 and amd64 have the same code density, which is not true, also you are neglecting the Mach-O headers and how sections are zero-padded for alignment.
The object code is significantly less then the size of the binaries, Mach-O files (and ELF files and PE-COFF files) zero pad sections, allign them and generally have extraneous sections.
So, now what? The article mentioned Lion's touch(1) size, and I wanted to point out that it actually covers two arches. We know there is padding, alignment, headers and density whatnot. The end result is that makes a negligible difference between the two arches, hence "~half".
It might be fun to compare think/lightspeed pascal/c since they included a full GUI IDE (and inline assembler) as well as full support for the Mac toolbox. (These products were to the Mac what borland's products were for DOS and Windows.)
I know you could fit early versions of lightspeed pascal or c on a single floppy disk with a copy of System 3.2.
I seem to remember MS "Programmer's Workbench" for C/C++ 6 on DOS in the early 90s. It was a PITA, and I far and away preferred the Borland tool stack.
The one thing the MS C compiler seemed good at was compiling gigantic "translitered" functions (generated by a code translator of the company where I was working at the time). Otherwise, meh.
Turbo Pascal for Windows was simply awesome, (unfairly) compared to the C SDK for Windows 3.X, as well. The windowing library (objects), and the way it linked methods as event callbacks were much easier to read and write than hand-crufted event loops/switches in C. MS eventually made something comparable in C++, but I was long gone to *nix land by the time that mattered.
What I meant was Microsoft's bloated and unwieldy C compiler, I don't recall if it had achieved the moniker 'visual' by DOS 4 or if that waited until Win95 release. It came in a green box on at least 4 floppies and was a PITA to use. Turbo Pascal, compared to that, made me wonder why Microsoft didn't adopt it as their 'main' implementation tool.
>Bill Gates saw the success of Turbo Pascal "in very personal terms, and 'couldn't understand why [Microsoft's] stuff was so slow. He would bring in poor Greg Whitten [programming director of Microsoft languages] and yell at him for half an hour.' He couldn't understand why Kahn had been able to beat an established competitor like Microsoft."
It's certainly possible that someone was using TurboPascal (discontinued mid 90s) at same time as VisualC or the early version of MS C.
Probably because it's statically linked with some standard libraries. If you write a hello world app in C++ and compile/link with all the defaults, you'll see similar results.
You should use OpenBSD, then it's only 10k. As for why, objdump -s gives some hints. Lots of the file is really just zeros (you can see this with hexdump too), and the various sections of the file are padded for alignment.
I learned programming with Turbo Pascal. I remember appreciating how it used a "Smart Linker" could produce really small executables because it stripped out any unreferenced code. I can't remember now how small the Hello World .exe files were, but they were small.
I'm surprised that nobody mentioned Wirth and Oberon yet. His '95 paper "A Plea for Lean Software" mentions Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."
Turbo Pascal was my first programming language. I thought it was the coolest thing ever that I could write a game, put it on a floppy disk and share it with all my friends.
I wish there was something like Github back then; I lost all my early source code years ago. It would be fun to see how terrible it looked :)
Yep. I loved it so much that I wrote a really evil hack to use Turbo Vision in 640x480 graphics mode -- by hooking the vsync interrupt, comparing Turbo Vision's text-mode output to a shadow copy, and making the corresponding changes to the (graphical-mode) displayed output. Net result, Turbo Vision with an added GraphicObject.
That's good to hear. I still had to download an 80MB iTunes update recently, but hopefully the update tech they're using will spread across the company.
I would be surprised if the CP/M version was any smaller. Turbo Pascal was smaller and faster than anything else at the time. However, the CP/M version would not have been a native compiler. Pascal generally compiled to p-code which was then interpreted (and was therefore slower).
The CP/M version was a native compiler. The real limitation with the Z80 version was that recursion required either a compile time switch or annotation on the functions (It's so long ago I can't remember)
Somewhere I have a copy of just the editor portion of turbo pascal (from memory it's around 13K) that I snaffled when I worked for Borland in the mid 80s. Sadly no good anymore as 16 bit COM programs won't run on my 64 bit system.
And it must have made it into another gem from Borland: Sidekick. I used that extensively until I moved entirely off DOS. (Sidekick was a TSR--Terminate and Stay Resident-- utility program that could be launched by hotkey from single-tasking DOS. There was an editor, calculator and ASCII table! IIRC.)
UCSD Pascal compiled to p-code. Other Pascals compiled to native code. The Wikipedia entry for Turbo Pascal indeed mentions that the TP-generated executables were extremely fast, which was a revelation to UCSD users.
Looking around my old DOS files, qbasic.exe is 254,799 bytes, plus a 133,810 help file. 400kb is larger than anything on that list, but we can think of lots of things larger than 400k. I don't seem to have Turbo C++ on my system any more, but it came on floppies and was probably no more than 15MB unpacked.
The entire MS-DOS 5.0 distribution is around 2.2MB. Norton Utilities is 2,316,176 bytes. For a complex application that uses graphics and fonts, Print Shop is 2,716,489 bytes. The average Flash game is larger these days, although that is largely due to music and bitmaps. Individual files in my /usr/bin that are larger than all of MS-DOS or Norton include python2.7 (2,375,356) mono (2,637,288), gdb (3,888,248), doxygen (5,413,488), and smbclient (6,512,344), and these files are stripped.
Linux kernel modules are still relatively small. Most are under 50k, although mac80211 is 257,001 and i915 is 451,033. The psmouse module is 73,312, almost twice the size of Turbo Pascal to drive my mouse.
Most files in /bin are still small. Turbo Pascal is just barely larger than ed (38,464) and cat (38,484), and is smaller than touch (42,552) on my system as well.
Turbo Pascal is also smaller than the gzipped man file for rsync (49,400), /etc/bash_completion (58,739), the Neko compiler (176,073) and DLL (94,203) for Windows, and GNU cmp for Windows (57,344).
Yes, most files in /bin are small, but that's because they're dynamically linked to libc, amongst others. I bet you virtually all of them would be larger than Turbo Pascal if statically linked.
I cut my teeth with two programming languages, Smalltalk and Delphi (basically Turbo Pascal for Windows), and was actually just screwing around with Free Pascal (http://freepascal.org/) on a nostalgia kick.
I ended up learning Delphi mostly by happenstance--I ended up getting gifted a free copy of Delphi 3, whereas VisualBasic and Visual C++ were comparatively expensive at the time--but I am incredibly, incredibly glad that I learned that first. Where C++'s grammar is convoluted, confusing, and contradictory, Turbo Pascal's and Delphi's manage to be very simple and straightforward with comparable power. I spent a lot less time coming to terms with syntax, and a lot more time familiarizing myself with machine code, calling conventions, and libraries.
Having a straightforward grammar doesn't just help the compiler use less space. It helps your brain use less space on raw syntax.
it also helps you logically deduce stuff you don't know. I remember that after a while, I could almost guess the names of functions that I didn't really know - that's what having a naming convention and regular syntax do for you
Yeah, I don't think that C++ killed Delphi. Java killed Delphi.
Java may kinda look like C++, but Java 1.1 acted a lot like Borland Pascal plus a UCSD pcode-system. Nested blocks, strong typing, easy string manipulation, portable interpreter. And support for strings over 255 chars long, too! :-)
Pascal's grammar is so simple by design that it can be parsed and codegenned in a single recursive descent pass. Not many languages are like that, especially these days.
No, but only by definition. Passing through an s-expression representation is a requirement for a lisp compiler, because the tree to be compiled might have been built at runtime. Certainly lisp's grammar is no more complicated than pascal's.
Nor, frankly, is K&R C, which is is also a very simple representation. The ANSI process added some edge cases that complicated it, but really it's pretty simple.
I don't know any practical algorithm for handling closures that'll let you code-gen Lisp in one pass, but in general writing Lisp compilers is frightfully easy: http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf
I believe that's how the Clojurescript compiler currently works (though I haven't looked at the code in detail). Compilers that don't do it that way usually have optimizations going on in between the parse and codegen phases, not because it's impossible to do with Lisp syntax.
The problem is not with Lisp syntax. The problem is with Lisp's semantics, which makes it much more difficult (if at all possible) to compile in one pass. Things like closures, conditions or macros are absent in Pascal.
It's easy to write very small interpreters, even ones that JIT code. So much so that some approaches to shrinking software have historically been to write a little VM interpreter, and compile the source code to target that rather than the actual CPU. A compiler that produces code that no longer requires a runtime (in the VM sense - inverted control) is slightly more work.
Turbo Pascal's code generation was simple and naive. It had little optimization. It literally output the machine code as it parsed. There was no AST, not even an expression tree.
(I have the source code to the final version of the Turbo Pascal compiler on my disk. It was used for Delphi 1.)
As far as I know it is still under copyright. Anders Hejlsberg's name is in the comment headers; it was largely rewritten in 1986 and 1987 for TP4. I believe it belongs to Embarcadero, the company I work for, after they bought the developer tools division from Borland.
I have no idea about releasing it. I'm entirely the wrong end of the company to ask about it.
Those billion Lisp implementations primarily exist because Lisp is fashionable; Pascal is not. In the past, toy Pascal compilers have actually been a popular project (especially in introductory compiler courses).
Not necessarily. Some grammars can be parsed with simpler code than others, but optimizations can make a compiler larger. Also of note is that Turbo Pascal was written by hand in assembly language, and the executable wasn't likely to have been linked with any libraries.
Indeed TP did not have any linking step. I still recall trying to fruitlessly find "Link" on the menu for quite some time until it hit me -- oh, no linking needed. But TP did include a run-time with each of the generated executable. This run-time was part of the compiler and it was approximately 10K (from memory, so I could be wrong). That makes the compiler about 22Kbytes worth of code, which is even more impressive.
Turbo Pascal 6.0 was the pinnacle of IDEs. Or the pinnacle of my joy in programming, which, of course, is difficult to distinguish. :-)
I spent hours upon hours poring over VGA graphics code in Pascal, then assembly (called by Pascal, since I wasn't sophisticated enough to understand how to build a stand-alone EXE from ASM) in high school. I would tweak things, then run against the slick built-in profiler, then refine some more. Some time later, I came across this vast information pipe called Usenet and found out that everything I worked on was years out of date, since ModeX provided dramatically faster access to video memory. Ignorance is bliss...
Fast-forward about seven years, and my company was looking at an interpreted BASIC implementation that took about 120K. Since this was supposed to live in ROM, you could think about it as Real Money. We dug into it and found all kinds of fat -- the usual 13 fear-based reimplementations of strlen and strcpy, about a zillion porting layers, endless amounts of cut-and-paste nonsense.
Somewhere between 1978 and 1985, the software industry's drive to be lean and mean on PCs died. I found myself writing 'sed' scripts to do peephole optimization on the intermediate assembly language of one of the C compilers we were using. It was pathetic.
Now, of course, I light my cigars with gigabytes. But in terms of actual cost, I'm still a cheap bastard and I probably don't spend any more money per year on CPUs, memory or storage than I did 30 years ago.
Had a chance last year to write a mission-critical hunk of code that /had/ to fit into 1920 bytes. I can't tell you how much fun that was.