Warp wrote:

> Current computers have multi-gigabyte RAMs, so who cares?

This kind of attitude annoys me too...

>   What I like about C++ is that it provides strong tools for creating
> very abstract code which is very memory-efficient at the same time.

What I dislike about C++ is its vast complexity. Even you surely won't 
try to claim that C++ is a "simple" language? ;-)

However, surely in anybody's books, abstract + efficient = very good 
thing. I certainly won't argue with that one.

>   For example, if I want to create a class named "Pixel" which has a
> nice public interface (and with its actual implementation hidden), and
> with all kinds of commodity functionalities, I can do so. Yet I can do
> so in a way that lets me create, for example, an array of 1000000 such
> Pixels which only requires, for example, 4000000 bytes of memory (4 bytes
> per pixel) and nothing more.
> 
>   I can even create several types of pixels (for example varying in number
> of color components and bits per color component), each one with the same
> interface. I can create functions which take "anything that looks like a
> Pixel" (ie. implements certain public functions) and do something to it.
> All this still requiring just a minimum amount of bytes per pixel. If I don't
> need, for example, dynamic binding, then no memory is needlessly wasted in
> a useless virtual table pointer. Also memory is not needlessly wasted in
> ancillary memory allocation data, keeping the memory usage still at 4 bytes
> per pixel (or whatever the actual amount of data in the pixel is).

Haskell *can* do this - but it needs to become vastly easier.

In Haskell, I can make a list of Bool values where each one takes 
exactly 1 bit of storage (plus some constant overhead for the array 
itself). You use the array just like any other structure, but under the 
surface it's doing bit shifts and so forth for you to extract the bit 
you requested. All lovely and transparent.

The *problem* is... it's unreasonably hard to extend this lovely 
functionality to *new* data types. It's already set up for common 
primitive types like Booleans and integers and characters, but you'll 
have to poke around deep in the innards of the compiler's library source 
code if you want to do the same trick for your own types. It shouldn't 
be like that. But, currently, it is. :-(

>   So in many "high-level" languages it's a tradeoff between abstraction
> and memory usage. You can't have both at the same time. In C++, to a
> relatively large extent, you can. That's what I like about C++.

It's something that is obviously desirable to have, and it's something 
that's being actively worked on in Haskell. (For example, the recent 
"ByteString" library, which vastly decreases the time and space 
requirements for string processing.) I guess ultimately time will tell...

Post a reply to this message