Things That Turbo Pascal is Smaller Than
prog21.dadgum.com
prog21.dadgum.com
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.
Awesome. What was that for? Please don't leave us hanging :)
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.
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.
What does that mean?
"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."
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.
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.
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.
Solution: http://feed43.com/2602451534003772.xml
Problem: I really like the PS238 comic but there's no direct feed
Solution: http://feed43.com/ps238-link-only.xml
Another tool that looks promising but I haven't really dug into yet is http://scraperwiki.com (pardon the pun)
edit: It is indeed linked in the HTML if you view source. Not sure why your browser or whatever isn't picking it up. Looks like this:
<link rel="alternate" type="application/atom+xml" title="Atom feed" href="atom.xml"/>
VisiCalc was, essentially, _the_ killer app of the early PC era.
The march of progress. ;-)
Obviously, this wasn't the be-all and end-all, but VisiCalc did for sure sell many Apple II computers.
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 always have been (and still am) a fan of the Borland series of developer tools - still using C++Builder today and still liking it.
http://en.wikipedia.org/wiki/Philippe_Kahn
"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."
The good ol' days.
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?
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.
† The Find box was overlapping the highlighted search item when latter happened to be in the top visible line.
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.
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 :-)
Only six months before I met TP I had been using punch cards on the University's mainframe. TP2 was pure shock and awe.
$ file /usr/bin/touch
/usr/bin/touch: Mach-O universal binary with 2 architectures
/usr/bin/touch (for architecture x86_64): Mach-O 64-bit executable x86_64
/usr/bin/touch (for architecture i386): Mach-O executable i386
cp /usr/bin/touch ./; for arch in i386 x86_64; do lipo -thin $arch touch -o touch.$arch; done; ls -l touch*
-r-xr-xr-x 1 lloeki staff 44016 31 Oct 11:37 touch
-r-xr-xr-x 1 lloeki staff 19440 31 Oct 11:37 touch.i386
-r-xr-xr-x 1 lloeki staff 19440 31 Oct 11:37 touch.x86_64The boxes are the same, the content is different.
> cat touch.x86_64 | perl -p -e 's/\0//' | wc -c
19407
> cat touch.i386 | perl -p -e 's/\0//' | wc -c
19408
> otool -tV touch.x86_64 | wc -l
742
> otool -tV touch.i386 | wc -l
808
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".
I know you could fit early versions of lightspeed pascal or c on a single floppy disk with a copy of System 3.2.
>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.
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.
- Cheap - Fast - Good
Choose any two
With TP, you got all three!
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 :)
... god that code was ugly.
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.
Have you tried DOSBox?
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).
Edit; not meant sarcastic, I would really like to see such a simple parser as was implied.
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.
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.
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.)
Is that still under copyright? And chance it could be released?
I have no idea about releasing it. I'm entirely the wrong end of the company to ask about it.
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.
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! :-)
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...