Orchid XP v7 <voi### [at] devnull> wrote:
> Warp wrote:

> >   I actually find it a bit worrying that it seems that no programming
> > language introduced in the last 20 years which has got some popularity
> > seems to offer any tools *whatsoever* to create memory-efficient programs
> > (at least not without resorting to really ugly code which bypasses nice
> > modular design).

> I was about to say "Haskell" - but it's not new enough...

  You are telling me you can create very memory-efficient programs in
haskell without resorting to ugly low-level hacks?
  That seems to be contradictory to what I remember you saying about
those ugly arrays which can be modified in-place and such.

  OTOH, I just can't stop thinking about programming from a modular point
of view. To me a program consists of "concepts". This "concept" is some
kind of module which contains some properties, ie. members (variables,
functions...) Optimally, still from a modularity point of view, these
modules will have an *abstract* public interface (ie. one which does
not expose its internal structure).

  For example, a "pixel" is a concept. On the inside it consists, for
example, of four bytes (or four 16-bit words): The red, green, blue and
alpha components. However, from a modular point of view, these are
internal implementation details, hidden from the outside. The public
interface of this module consists of abstract functions which can be
used to manipulate its contents and behavior.

  Now, this is of course just a concept. It doesn't really exist
physically yet. When you instantiate this concept you get an "object".
You can instantiate the concept many times, getting many "objects".
All these objects can be manipulated through the abstract public
interface.

  The relevant question, from an optimization point of view, is how
much memory do these objects require? If you want to create one million
of such objects, how much memory do they require?

  In C++ you can often make it so that the objects require as much
memory as the contents of the object (eg. 4 bytes) times the number
of objects (plus a few additional bytes for book-keeping). So for
example one million of such objects could require only 4 million bytes
(plus a few bytes more). And this still while keeping the abstraction
of these objects: You still don't need to know what these objects look
in the inside. The inside of the objects doesn't need to be exposed.

  In Java this is impossible. You can't make such objects to take only
4 million bytes of memory, no matter what you do. If for the "pixels"
to take that much memory is completely imperative, what you can do is
dump the nice modular abstractions and nice public interfaces completely
and resort to very ugly hacks using integer arrays. This, of course,
causes all kinds of maintenance problems. (For example, if you would
like in the future to use 8-byte pixels instead of 4-byte ones, you are
screwed.)

  I don't have the slightest idea how all this works in Haskell, though.
Being a functional language it probably doesn't even have the concept of
"module", nor the concept of "object". Can you create "concepts" (such
as "a pixel") at all? Can you instantiate these "concepts" (and, for
example, put them inside diverse types of data containers)? Does it have
the concept of "abstraction" and "public interface" which hides
implementation details?

  If I'm not completely mistaken, in Haskell you can probably define
things like "a pixel consists of these four elements". However, that
already exposes the internal structure of a "pixel". That's asking
for maintenance trouble (because then code that uses that "pixel"
concept will assume it has those four elements, which means that it
may not be possible to modify it in the future without breaking
existing code).

  Maybe there's another completely different way of doing these things
in a functional language like Haskell? I just can't get around the
modular way of thinking about programming.

-- 
                                                          - Warp

Post a reply to this message