I think this pretty much sums it up.
http://prog21.dadgum.com/116.html

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

On 30/10/2011 10:01 PM, Darren New wrote:
> I think this pretty much sums it up.

I haven't seen TP3, but I've seen TB5.5.

In fairness, the IDE is just a program that does some text-mode 
"graphics". (IIRC, it does respond to the mouse - but using a mouse in 
text-mode is just painful.) The IDE doesn't actually do all that much. 
It's a text editor. There's a button that compiles your program. If 
there's an error, it takes you to that line in the program. I believe 
you can also step-debug your code too. And there's online help. That's 
about it, really. You can't have more than one file loaded at once. (If 
you edited the current file, you have to save it before you can open 
another one.) There is no syntax highlighting. There is no special 
navigation beyond what any generic text editor would provide. There's no 
special interface for specifying complicated compiler options. It 
doesn't really do very much.

Now, to the actual claims of the post: I'm not entirely sure I buy it 
that the compiler and IDE fit in 40KB of space. For one thing, I was 
fairly sure that the compiler was a separate binary from the editor. 
Second, from what I remember there's a couple of other files that need 
to go with it for it to work. (You can leave out the help files if you 
don't mind help not working.) As I recall, it would all fit onto a 720K 
floppy and still leave space to actually do some work. The actual 
install media ran to 7 disks.

jQuery is a huge, complex library written in raw JavaScript. It probably 
contains source comments and who knows what else besides. I'm sure some 
of the libraries that come with Turbo Pascal are much bigger than the 
compiled binary for the compiler. (It came on *seven disks*, remember.)

The yahoo.com homepage is utterly encrusted with advertisments and 
stories. It is very graphics-heavy, and it no doubt has a ton of 
JavaScript automating all the flashing banners and blinking lights. (Not 
to mention all the Flash.) Anyone can produce bad websites; Yahoo is 
just one of the better-known examples. (The Wikipedia homepage is 15KB - 
very much smaller.)

An entire OS is larger than a compiler? SAY IT ISN'T SO! :-P

zlib.h - OK, I have no explanation for why this would be more than 1,000 
bytes long. It's only a header file, after all. (IOW, it tells you the 
name of the compress and decompress functions. Unless those names are 
*really* long, I can't see how two function names can be 80KB in size.)

The touch command - no explanation.

The vim quick reference PDFs - well, yeah, there's 8 entire font files 
embedded within that. That'll be why it's so big. (Quite apart from all 
the elaborate kerning commands that TeX typically generates.)

The compiled code for the Erlang parser - Given how trivial Erlang's 
syntax is, I don't really have an explanation for that one. There's 
probably some overhead for having hot-swappable code, but beyond that... 
I don't really have an answer.

The Wikipedia page for C++. According to Firefox, the page itself is 
40KB. Not 200KB. It references two images that are about 40KB each. The 
stylesheet probably adds a few bytes... I'm not sure how the guy came to 
200KB as the total size. But sure, 18 pages of rich formatted text plus 
accompanying diagrams... I guess that's going to be fairly large.

So, yeah. Some things are bigger for a reason. Other things are bigger 
for no obvious reason at all...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> An entire OS is larger than a compiler? SAY IT ISN'T SO! :-P

  "Image" means "jpeg".

> zlib.h - OK, I have no explanation for why this would be more than 1,000 
> bytes long. It's only a header file, after all. (IOW, it tells you the 
> name of the compress and decompress functions. Unless those names are 
> *really* long, I can't see how two function names can be 80KB in size.)

  zlib consists of a lot more than just two functions. There are probably
at least a hundred functions and a couple of dozens of types. (For example,
zlib contains wrapper functions that simulate the usage of the standard I/O
functions.)

> The touch command - no explanation.

  It has multiple command-line parameters (which have to be parsed and
interpreted), a help text for all those parameters, probably tons of
different error messages and probably tons of code dealing with the unix
file system (as it might not be the same thing to 'touch' a file, a directory,
a soft link, a pipe, a device, etc). Some statically linked libraries might
add unused code to the executable as well.

-- 
                                                          - Warp

Post a reply to this message

>> An entire OS is larger than a compiler? SAY IT ISN'T SO! :-P
>
>    "Image" means "jpeg".

How do you take a picture of an OS?

Regardless, it's no secret that image data takes up far more space than 
code does. I gather there was a time when people predicted that Moore's 
Law would mean that you would be able to store your entire life on a 
computer soon - after all, 10MB is enough space to store the contents of 
an entire *library*, right?

>> zlib.h - OK, I have no explanation for why this would be more than 1,000
>> bytes long. It's only a header file, after all. (IOW, it tells you the
>> name of the compress and decompress functions. Unless those names are
>> *really* long, I can't see how two function names can be 80KB in size.)
>
>    zlib consists of a lot more than just two functions. There are probably
> at least a hundred functions and a couple of dozens of types. (For example,
> zlib contains wrapper functions that simulate the usage of the standard I/O
> functions.)

And here I was thinking it just takes data and returns compressed data...

>> The touch command - no explanation.
>
>    It has multiple command-line parameters (which have to be parsed and
> interpreted), a help text for all those parameters, probably tons of
> different error messages and probably tons of code dealing with the unix
> file system (as it might not be the same thing to 'touch' a file, a directory,
> a soft link, a pipe, a device, etc). Some statically linked libraries might
> add unused code to the executable as well.

The Turbo Pascal compiler also has many command-line options, and - I 
would suggest - *far* more error messages than the touch command. Not to 
mention a complete Pascal parser, AST manipulations, code generator, 
etc. Clearly it "should" be way, way bigger.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> An entire OS is larger than a compiler? SAY IT ISN'T SO! :-P
> >
> >    "Image" means "jpeg".

> How do you take a picture of an OS?

  "iPhone 4S" is not an OS. It's a cellphone.

> after all, 10MB is enough space to store the contents of 
> an entire *library*, right?

  Not really. A medium-length book may well take 1 MB to store, especially
if you store layout and style as well.

> >    zlib consists of a lot more than just two functions. There are probably
> > at least a hundred functions and a couple of dozens of types. (For example,
> > zlib contains wrapper functions that simulate the usage of the standard I/O
> > functions.)

> And here I was thinking it just takes data and returns compressed data...

  It's not that simple. There are many places where you could be reading
from or writing to. For example if you want to decompress from RAM to RAM,
that's a completely different process than if you want to decompress from
a file to RAM streamed (iow. you don't want to load the entire compressed
file to RAM at once). Compressing is even more complicated because you have
all kinds of options. Then there are utility functions to make this process
easier so that you can skip the nitty-gritty details if you don't care about
them.

  (Remember that zlib is in C, and hence there's not much abstraction.)

-- 
                                                          - Warp

Post a reply to this message

>> How do you take a picture of an OS?
>
>    "iPhone 4S" is not an OS. It's a cellphone.

Hmm, interesting...

>> after all, 10MB is enough space to store the contents of
>> an entire *library*, right?
>
>    Not really. A medium-length book may well take 1 MB to store, especially
> if you store layout and style as well.

I think my numbers are off slightly. Regardless, the original quote 
[which I can't seem to find now] was that "in 10 years' time" computers 
will have so much storage that you can easily store a textual 
representation of everything that ever happens in your life.

Think about it. I've got a file somewhere which contains a complete copy 
of The Holy Bible. It's 0.5MB. And that's quite big, as books go. So 
with a 3TB HD, I ought to be able to store quite a few books. If we 
assume 1MB per book, that's... over one million books. More material 
that you can read in a single human lifetime.

The point being, when they wrote that, they were assuming that text is 
all you would ever use computers to store. Consider the possibility of 
storing graphics, sound and even video, and suddenly 3TB doesn't seem 
very big at all. Suddenly it starts to actually look kinda small... and 
that's something that writers decades ago wouldn't have foreseen.

>>>     zlib consists of a lot more than just two functions.
>
>> And here I was thinking it just takes data and returns compressed data...
>
>    It's not that simple. There are many places where you could be reading
> from or writing to. For example if you want to decompress from RAM to RAM,
> that's a completely different process than if you want to decompress from
> a file to RAM streamed (iow. you don't want to load the entire compressed
> file to RAM at once). Compressing is even more complicated because you have
> all kinds of options. Then there are utility functions to make this process
> easier so that you can skip the nitty-gritty details if you don't care about
> them.
>
>    (Remember that zlib is in C, and hence there's not much abstraction.)

I had expected the zlib itself merely takes a pointer to a buffer full 
of data, and a pointer to an empty buffer, and moves data from one to 
the other, compressing or decompressing as requested. I'm surprised it 
actually implements anything as high-level as file access.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I had expected the zlib itself merely takes a pointer to a buffer full 
> of data, and a pointer to an empty buffer, and moves data from one to 
> the other, compressing or decompressing as requested. I'm surprised it 
> actually implements anything as high-level as file access.

  If the data you are decompressing doesn't fit into RAM, how are you
supposed to decompress it? (Answer: By streaming. In other words,
decompress small parts at a time. This requires more than one simple
"decompress this" function.)

-- 
                                                          - Warp

Post a reply to this message

On 10/31/2011 3:24, Invisible wrote:
> The Wikipedia page for C++. [...] But sure, 18 pages of rich formatted text plus
accompanying
> diagrams... I guess that's going to be fairly large.

I think his point is that the encyclopedia page for describing C++ is bigger 
than the entire development environment for implementing TP.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

On 10/31/2011 9:35, Invisible wrote:
>>> How do you take a picture of an OS?
>>
>> "iPhone 4S" is not an OS. It's a cellphone.
>
> Hmm, interesting...

Again, he's pointing out that a *picture* of a computer is bigger than the 
entire compiler that runs on that computer.  He's making amusing 
comparisons, not something you should really be deeply concerned about.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

On 31/10/2011 05:36 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> I had expected the zlib itself merely takes a pointer to a buffer full
>> of data, and a pointer to an empty buffer, and moves data from one to
>> the other, compressing or decompressing as requested. I'm surprised it
>> actually implements anything as high-level as file access.
>
>    If the data you are decompressing doesn't fit into RAM, how are you
> supposed to decompress it? (Answer: By streaming. In other words,
> decompress small parts at a time. This requires more than one simple
> "decompress this" function.)

As I say, I would have expected a function that takes two buffers, and 
then returns some sort of indication of how much data it processed. You 
can then call it again to process the next chunk. The only really tricky 
bit is flushing the end of the stream.

But yeah, I guess that might be complicated enough to merit having 
functions especially for the common case of wanting to compress a file 
on disk...

Post a reply to this message