Invisible wrote:

> While it's a reasonable theory, I don't think you can have competition 
> between half a dozen semi-broken packages.
> 
> I mean, look at web browsers. There's IE, there's Safari, Firebox, 
> Opera, etc. But imagine if there was one browser which could do HTTP and 
> FTP, but didn't understand HTML. And another browser that understands 
> HTML and CSS, but only handles HTTP and not FTP. Now imagine another 
> browser that handles HTTP and HTML, but doesn't support forms, but does 
> support Java... Would they "compete"? Or would everybody just concluse 
> that this whole web dealy isn't worth the effort?
> 
>> No problem compartmentalizing libraries. But, you really don't need 
>> two libraries that do A, and three that do C, etc ...
> 
> See above.
> 

Oh, so it's much worse that I thought.

>> How many libraries does it take to deal with such an elementary 
>> concept as an array? (I assume we're talking about what is essentially 
>> a vector, a list of values, no particular data structures like hash 
>> tables, linked lists and the sort ...)
> 
> Well... Haskell is slightly unusual in that it prefers data structures 
> to be immutable. Hence it offers immutable arrays. No other language 
> does. Look at BASIC, Pascal, C, C++, C#, Java, Perl, Tcl, etc., and 
> arrays are always mutable. Only in Haskell does such an animal as an 
> immutable array exist.
> 
> The Haskell data structure of choice is a list or a tree, because these 
> can be recursively defined. Arrays are not recursive, but it is possible 
> in various ways to pretend that they are. Similarly, immutable arrays 
> aren't particularly useful, but there are various ways to make mutable 
> arrays look immutable while retaining efficiency.
> 
> So, to summarise, arrays are slightly tricky in Haskell. There are 
> design choices to be made, and the optimal choice varies depending on 
> what you want to do. By contrast, C arrays are "just arrays".
> 

I see. So, essentially Haskell prefers to deal with data structures, 
rather than flat arrays?

> 
> Either that, or I come across as sounding like an idiot so people ignore 
> the content of what I'm saying.
> 
> Don and friends all seem like highly intelligent people. Maybe they just 
> have other priorities or something, IDK.
> 

Who knows...

>> That's just the sort of thing that will cause a project to stagnate 
>> and die.
> 
> Er, yeah.
> 
> But hey, it's already begun. Every day, mainstream programming languages 
> continue to steal Haskell's inovative ideas. Maybe someday soon Haskell 
> truly will wither and die. :-(

Yep, and I believe I use a few of Haskell's stolen features every day. 
I've learned to really appreciate C#'s lambda expressions :)

-- 
~Mike

Post a reply to this message

>> While it's a reasonable theory, I don't think you can have competition 
>> between half a dozen semi-broken packages.
>>
>> I mean, look at web browsers. There's IE, there's Safari, Firebox, 
>> Opera, etc. But imagine if there was one browser which could do HTTP 
>> and FTP, but didn't understand HTML. And another browser that 
>> understands HTML and CSS, but only handles HTTP and not FTP. Now 
>> imagine another browser that handles HTTP and HTML, but doesn't 
>> support forms, but does support Java... Would they "compete"? Or would 
>> everybody just concluse that this whole web dealy isn't worth the effort?
> 
> Oh, so it's much worse that I thought.

Er... yah.

> I see. So, essentially Haskell prefers to deal with data structures, 
> rather than flat arrays?

Not so much that... Haskell likes to deal with immutable data 
structures. That is, data structures that never "change". So to "change" 
your data structure, rather than modify it, you create a modified copy.

Which is greate if you're working with, say, a binary tree. You just 
copy the node that changed, and the parent nodes above it. (Any 
unchanged nodes can be "shared" between the new and old trees.) But for 
an array, you don't really want to copy a few million array elements 
every time somebody changes one freaking element!

Haskell already has facilities for modifying files on disk - and what is 
a disk file? It's an array of bytes. So you can use the same facility 
(i.e., monads) to handle mutable arrays - that is, arrays that you can 
modify in-place, like in every other programming language on earth. It's 
just a little less convinient to work with them that way.

As a result, you have libraries that try all sorts of tricks to either 
make immutable arrays fast, or make mutable arrays look like immutable 
ones... Then there are arrays specialised to particular element types... 
You get the idea.

>> But hey, it's already begun. Every day, mainstream programming 
>> languages continue to steal Haskell's inovative ideas. Maybe someday 
>> soon Haskell truly will wither and die. :-(
> 
> Yep, and I believe I use a few of Haskell's stolen features every day. 
> I've learned to really appreciate C#'s lambda expressions :)

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

Post a reply to this message

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