Warp wrote:
> scott <sco### [at] scottcom> wrote:
>>> Haskell's array libraries... are a mess. Specifically, there is now about 
>>> half a dozen of them.
> 
>> Not so different with C and all its derivatives (C++, C++ STL, C++ .net), 
>> there are many different array handling "libraries", fun if you work with 
>> code that uses all sorts of different approaches :-)
> 
>   Really? C has no array handling libraries whatsoever (standard C, that is).

#include <string.h>
technically speaking. :-)

And you'd have to count malloc() and free() and memset() and all that stuff. 
It's not especially sophisticated, mind, but that counts, doesn't it?

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
>> Yes, and C++ .net has standard libraries,
>   Defined by which standard?

http://www.ecma-international.org/publications/standards/Ecma-335.htm

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Invisible wrote:
> Yeah. It's a hoot. You use one library that uses array-X, and another 
> library that uses array-Y, and now your program must waste time 
> converting from one to the other. Great fun. :-/

Could be worse. Could be Ada, where you have things like "library of arrays 
holding bytes in memory" and "library of arrays holding bytes from I/O 
operations" and they aren't the same and there's (AFAIK) no standard 
conversion functions.

Great, if your computer isn't using 8-bit bytes for memory. For all the rest 
of us, rather a PITA.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Mike Raiford wrote:
> Invisible wrote:
> 
>>> Sounds like they drank the OSS flavored kool-aid.
>>
>> I have no idea what the heck kool-aid is, but... yes.
> 
> Read http://en.wikipedia.org/wiki/Drank_the_kool-aid it's interesting, 
> and gives the source for the expression.

I thought the Heaven's Gate Away Team was the source of that expression, but 
I guess that was apple sauce.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Darren New wrote:

> Could be worse. Could be Ada, where you have things like "library of 
> arrays holding bytes in memory" and "library of arrays holding bytes 
> from I/O operations" and they aren't the same and there's (AFAIK) no 
> standard conversion functions.
> 
> Great, if your computer isn't using 8-bit bytes for memory. For all the 
> rest of us, rather a PITA.

That's advanced. :-D

OTOH, Haskell has something extremely similar... A library for arrays, 
and a seperate library for C-compatible arrays. The advantage being that 
the C-compatible version has fast I/O (wanna guess why?), but slow 
everything else...

Post a reply to this message

Invisible wrote:
> You appreciate them *now*... Wait until you start using a language where
> the standard way to iterate over a data structure is to pass your "loop
> body" (as a lambda function argument) to the function that does the
> traversal. :-P

C++0x?

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Invisible wrote:
> > You appreciate them *now*... Wait until you start using a language where
> > the standard way to iterate over a data structure is to pass your "loop
> > body" (as a lambda function argument) to the function that does the
> > traversal. :-P

> C++0x?

  It will indeed introduce core features which help a lot in this matter.

  For example the current standard library has a for_each() utility
function which in theory makes it easier to loop through an iterator
range and apply some function to each element. However, in practice
doing this is so cumbersome that few people prefer that over the more
traditional for loop. The reason is that there's no way in the current
C++ to embed the function into the for_each() call. Instead, you have
to write the function separately and give the name to for_each(). Great
if you already have such a function, but more trouble than it's worth
if you don't, which means you have to write the function.

  Also even if you go through the trouble of writing the function, it
still has its limits. Most prominently, it's not a closure, which means
that the function has no access to the variables in the scope where the
for_each() is executed. This reduces the usability of for_each() even
further, compared to the traditional for loop (where there rather
obviously *is* access to all the variables in scope).

  The C++0x (well, C++1x, really) standard will most probably introduce
lambda functions and closures, which addresses all these problems, and
more. You will be able to write your function directly as a parameter
to for_each() (or whichever generic function you want to use) as a
lamdba function, and this lambda function can (optionally) have access
to all the variables in scope.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> The reason is that there's no way in the current
> C++ to embed the function into the for_each() call. 

> that the function has no access to the variables in the scope where the
> for_each() is executed. 

Technically, these are both the same problem. :-)  I just thought that was 
an amusing observation when I saw it: C *does* have closures. It just 
doesn't have nested function scopes, so closures and pointers-to-functions 
are the same thing in C.

I really have to wonder, sometimes, how far people are going to mutate C++ 
before they just give up and decide they're done. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:

>   For example the current standard library has a for_each() utility
> function which in theory makes it easier to loop through an iterator
> range and apply some function to each element. However, in practice
> doing this is so cumbersome that few people prefer that over the more
> traditional for loop. The reason is that there's no way in the current
> C++ to embed the function into the for_each() call. Instead, you have
> to write the function separately and give the name to for_each(). Great
> if you already have such a function, but more trouble than it's worth
> if you don't, which means you have to write the function.

Indeed.

Haskell doesn't do anything that's "impossible" with other languages. 
You can do "functional programming" in any programming language that has 
a certain minimal set of features. It's just that in other languages, 
it's so much trouble to write your code in this way that no sane person 
would bother. (Quite apart from the compiler not being specifically 
optimised for it.)

>   Also even if you go through the trouble of writing the function, it
> still has its limits. Most prominently, it's not a closure, which means
> that the function has no access to the variables in the scope where the
> for_each() is executed. This reduces the usability of for_each() even
> further, compared to the traditional for loop (where there rather
> obviously *is* access to all the variables in scope).
> 
>   The C++0x (well, C++1x, really) standard will most probably introduce
> lambda functions and closures, which addresses all these problems, and
> more. You will be able to write your function directly as a parameter
> to for_each() (or whichever generic function you want to use) as a
> lamdba function, and this lambda function can (optionally) have access
> to all the variables in scope.

Mmm, interesting...

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I really have to wonder, sometimes, how far people are going to mutate C++ 
> before they just give up and decide they're done. :-)

  You make it sound like C++ is the only language which is constantly
being developed further by adding new features and new libraries (and
that this is somehow a negative thing?). That other currently used languages
are more or less "ready" and do not change much.

  Of course that's pure BS. Most currently popular languages are being
constantly developed further and their libraries enhanced. Look at Java, C#
or the .NET framework. It's not that long ago that Java didn't even have
generics. Now it has them. What is the current version of .NET? 3.something?
And each major version introduced new features. Look at Haskell: That's
probably one of the languages which is going through the largest amount
of development. Things which were hard or cumbersome to do in the past
are being fixed in newer versions by adding new features.

  Why do you deliberately make it sound like C++ is the only modern language
for which new features are being added? Why do you deliberately ignore all
the other languages for which the exact same thing is true? Why do you
deliberately make it sound like it's a *bad* thing that the language is
being developed further? Why are you deliberately singling out C++ from
all the other languages? Are you deliberately trolling?

  I don't know if I'm just being paranoid, but I honestly think that you
are doing this for the simple reason that you know that you are going to
troll me.

-- 
                                                          - Warp

Post a reply to this message