
Things That Turbo Pascal is Smaller Than (2011) - vasco
http://prog21.dadgum.com/116.html?0
======
jonsen
And it was learnable. I mean, you could learn every detail of the language
with a reasonable effort. Just read through the manuals, which are extremely
well written. Not many modern languages you can say that about.

~~~
mtkd
There was a conversation in a ruby channel about this recently.

I mentioned that if 15 years ago you had suggested that in 2012 you would need
HTML, CSS (and probably LESS), JS (and probably JQuery + CoffeeScript +
Backbone), SQL or Mongo and Ruby or PHP or similar just to do a simple form
application - we would have laughed.

I got shot down - "it's a web application now, so not comparable".

But I really think it is comparable. The number of technologies you need to
know reasonably well to do a basic business function online is nuts.

To make it worse the number of flavours of languages or components involved
and the requirement to hire vertical developers (specialising in one language)
rather than developers who could understand the full domain means that
business web apps are becoming unmaintainable more quickly.

These tools and languages in the hands of startup teams with above average
commitment/experience/knowledge are fantastic, but for general business use
they are big step backwards.

I've noticed several sites recently that are including more than one version
of JQuery (and a copy of Prototype) on the same page - which is a symptom of
this to me.

Don't get me started that I could press F9(?) 15 years ago and Turbo Pascal
would build in 2 secs on a 386. Takes irb that long to start on this 8 core.

~~~
smacktoward
I don't know if this is really a fair comparison. You can do simple forms in
plain HTML if you want to, after all. No CSS required, no Ruby or PHP, no
scripting, no nothing.

If you want to _persist_ the form submissions you need to have some logic
(which brings in a programming language) and a database (which brings in SQL,
or maybe structured text files), but that's just as true in a single-user or
client-server application as it is in a Web application. The only differences
are that the fifteen-years-ago application probably used a language like
Visual Basic rather than PHP or Ruby, and a simple embedded database engine
like Jet (<http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine>) rather
than a standalone database server. But the basic concept of a form-based
application hasn't changed much, and the scope of knowledge you need to build
one hasn't changed much either.

 _I've noticed several sites recently that are including more than one version
of JQuery (and a copy of Prototype) on the same page - which is a symptom of
this to me._

This is more of a symptom of idiots having access to programming tools. Idiots
haven't changed much in the last fifteen years either. There were plenty of
line-of-business apps written in (say) VB whose code would make you scream
"Burn it! Burn it with fire!"

~~~
DigitalJack
offtopic, but because I disagree with the HN policy of not informing people
when they've been banned I'm posting this.

iRobot, your account has been banned for over 100 days. Unless someone turns
on the "show dead" switch in their profile, they can't see what you post.

------
eckyptang
I was thrown at turbo Pascal at university. Horrible language to be honest as
it was utterly painful to produce any reasonable data structures in it. The
verbosity usually broke the memory constraints of the machine just before you
finished what you were doing meaning hours of search and replace on
identifiers to shorten them to clean up ram for the editor. Ick.

It made me actually long to get back to a m68k based sun 3 with a c compiler
which took literally 2 minutes to compile hello world if some asshat wasn't
running emacs on the same box which was swapping to disk 100% of the time...

However what they managed to cram in was impressive.

~~~
tluyben2
Hmm, I don't have that experience; TP worked well for me and I created quite
substantial commercial projects which made me a 'wealthy' student in
university. Especially when they introduced overlays we were able to use all
those kilobytes :) I have good experiences with it and I still have all the
sources of the software I wrote then (a lot of it is still sold and a lot I
ported to Delphi after that and is still sold). Do you have concrete examples
of what you are referring to? I used structures, but never too complex as I
came from assembler (Z80/68k) and didn't (and don't) really see the use of
very complex structures. Reasonable worked fine.

~~~
marshray
That Sun workstation probably had multiple megabytes of RAM and cost 4x more
than a fully loaded PC. The 68k had a flat 32-bit address space and even
virtual memory.

TP was heroic for what it could do in the 16-bit segemented x86 architecture
in well under 640k of RAM. It was the first high level language implementation
that made "real" developers consider using something other than hand-coded
asm.

~~~
eckyptang
12mb :) It cost more but the time to market was much lower and it was multi
user so I think the trade off on cost was quite good.

------
michael_miller
The comparisons the article makes are not apples-to-apples. The authors start
with a binary file, and compare it to uncompressed text files. For example,
zlib.h on Mountain Lion is 80511 bytes, but only 22031 bytes when gzip
compressed (around half the size of Turbo Pascal).

The article's tone implies that these were the 'good old days' when compilers
were small and fast. However, priorities have rightly changed. We now have
computers that can execute billions of operations per second without breaking
a sweat, I/O devices which can perform tens of thousands of IOPS, and laptop
GPUs that can push 3D content to a 5.1 million pixel display. It's likely that
Turbo Pascal was highly optimized to deal with the constraint's of that day's
computers. A lot of developer man hours were almost certainly allocated to
shaving off extra bytes from the executable. It's usually not worth devoting
such man hours to tiny performance improvements, considering the beefy
hardware most people have.

~~~
klodolph
> The article's tone implies that these were the 'good old days' when
> compilers were small and fast.

That's reading a lot into two short paragraphs. Tone doesn't come across well
in text, and the shorter the text is, the harder it is to figure out tone.

I don't hear nostalgia for the 'good old days' in the article, what I hear is,
"Wow! What a feat of engineering to fit an IDE and compiler into 40k!" We get
the same kick out of watching demo competitions. Have you seen the "Elevated"
demo? Including the music, sound effects, textures, everything, it's only
4k...

<http://www.youtube.com/watch?v=_YWMGuh15nE>

------
EdgarVerona
I was a big fan of Turbo Pascal. It was a great learning language, and had a
robust library that was really fun for beginners to tinker with! I'd almost
call it the Python of its time.

------
mgkimsal
"The entire Turbo Pascal 3.02 executable--the compiler and IDE--was 39,731
bytes."

Many _icons_ are bigger than that these days (and with Retina displays, will
continue to grow).

~~~
klodolph
OS X 10.0.4 was released in 2001 and had 128x128 pixel icons in 24-bit color
with 8-bit alpha, at 66k each. It was not typical to compress them.

------
nhebb
And it's still available for download:

<https://downloads.embarcadero.com/free/turbopascal>

------
4ad
Previous discussion: <http://news.ycombinator.com/item?id=3175629>

------
waivej
That's a great article! I learned to really program on Turbo Pascal, and if I
remember correctly, the small executable made it easier to store programs on
the "program disk". Though by the time I built my own computer, it had dual
floppies so it wasn't as big of a deal.

------
greggman
I used Turbo Pascal and other environments even smaller environments (anyone
remember Action! (editor + compiler in 16k and ran on a 48k machine,
<http://en.wikipedia.org/wiki/Action!_(programming_language)>)

That said:

* the machine I ran Turbo Pascal on had a 115meg hard drive which was large compared to my co-workers 80meg drives.

* Turbo Pascal could not edit or display Chinese, Japanese, Korean.

* The editor could not search and replace across files with undo like my current editor. Nor do I think it could do a regex IIRC.

* It could not tag 40k+ files and bring up help on any function in near realtime.

* It could not refactor code.

* The machine ran in 80x50 characters. No windows. I could not view both reference material and my code at the some time on the machine, I needed a book. If I didn't have the book I needed I had to either go to a library or find a tech bookstore. (I only new of 3 in all of both Northern and Southern Califorina).

* The machine I ran it on had no networking.

* I had to manually edit config.sys, autoexec.bat and move DIP switches when ever any new devices were added. There was no USB only serial and parallel.

* When my program crashes I often had to reboot the machine.

* There were no fonts, everything was text.

* There were no images except a few icons in my apps. No way to easily display a company logo or screenshots in docs.

* There were few if any libraries. If I needed to read an image or parse a file I had to write it from scratch. If I needed to draw some graphics I had to poke registers. If I wanted to play audio I had to do device specific stuff.

I'm sure we could go on listing all the things those machines did not do nor
did Turbo Pascal do compared to today's environments with their large
libraries and access to all the stuff we've built up today.

Sure I miss the time when I could basically own the entire machine but I'm
happy that today I can just plug in a USB stick or a digital camera and they
just work. That I can participate internationally in multiple languages. That
1-20meg images are trivial to manipulate and display. That mp3s, wavs, and
other audio is ubiquitous, etc....

Those simple days were fun but a little reflection will show that today's
supposed complexity has made it easy to take a lot of things for granted. In
the Turbo pascal days. If you wanted to display a photo it would take hundreds
or thousands of lines of code, especially if you wanted it to work for more
that just your machine. Today it's step 1: copy file from camera, step 2 <img
src="path/to/file.jpg" />

I'm not going back.

~~~
mixmastamyk
Although I used it in the early nineties, I had a much different experience
than you mention. TP had Turbo Vision, a very usable windowing library. You
could open code in one window and help in another ... hotkeys opened up the
help on the current word etc.

I also dialed into BBSs and downloaded .gifs of elle macpherson, so plenty to
do. All on a 386/40. I moved up to a 486/40 at some point.

p.s. You can't go back.

------
outside1234
And it had an editor too! Turbo Pascal was what I cut my teeth on and to this
day I have fond memories of how productive I was in it.

------
abc_lisper
Thats pretty awesome! I have written my first program in Turbo Pascal :)

~~~
runn1ng
My first program was in QBasic, but I actually learned _how to write code_ in
turbo pascal. :)

...and delphi. and c#. and java. and perl. and scala. But well, you know what
I mean.

(and I learned how _not_ to write code in C++ and PHP.)

------
kps
The stock V6 UNIX kernel is 28,684 bytes, and /bin/sh is 5888.

------
cottonseed
There should be a followup, "Things That Turbo Pascal is Faster Than". Sure to
be included are "loading the wikipedia C++ page" and "loading the photo of the
iPhone 5 on apple.com".

------
colomon
I was really impressed by this, until it occurred to me that the _source_ code
for the C64 Forth compiler I used back in the day was probably considerably
smaller than 39K. :)

~~~
tisme
39K worth of Forth is a very large program. Most forth code never grows beyond
a couple of screens. That doesn't mean there isn't a lot of functionality, it
just means that forth is unusually dense.

------
mixmastamyk
39k for the executable? or with libraries?

They had some in those days, they were called "overlays" although that might
have been in the 90's and dos protected mode, etc. I'm sure the help, etc were
in separate files.

------
marshray
Google's home page <https://www.google.com/>

HTML+images is about 42k in my browser.

------
tome
It would be very nice if this was presented in an appropriate graphical format
for easier comparison.

