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. :-/
> 
> It wouldn't be so bad if we were talking about complete libraries that 
> differ stylistically or something. But we're not. We're talking about 
> several libraries, each of which only covers about 20% of what you might 
> like to do. But each library covers a different 20%. Which means you're 
> virtually *forced* to use several of them at once... *sigh*
> 
> Apparently everybody else thinks this is "perfectly OK".

Irony: Haskell was invented because there are numerous "competing" 
functional programming languages, and people wanted to concentrate their 
efforts on just one such language.

So having several different but essentially equivilent programming 
languages was "bad". But having several different but somewhat 
overlapping array libraries is "good" and even "to be encouraged". WTF?

Post a reply to this message

>> What bit of "Not so different with C and all its derivatives" did you not
>> get?
>
>  Check the thread topic.

Yes, and C++ .net has standard libraries, what on Earth is your problem, do 
you really not have anything better to do?

Post a reply to this message

Invisible wrote:

> So having several different but essentially equivilent programming 
> languages was "bad". But having several different but somewhat 
> overlapping array libraries is "good" and even "to be encouraged". WTF?

Sounds like they drank the OSS flavored kool-aid.

-- 
~Mike

Post a reply to this message

>> So having several different but essentially equivilent programming 
>> languages was "bad". But having several different but somewhat 
>> overlapping array libraries is "good" and even "to be encouraged". WTF?
> 
> Sounds like they drank the OSS flavored kool-aid.

I have no idea what the heck kool-aid is, but... yes.

Don was the person who rejected my suggestion for working on unifying 
the libraries. Don is also the guy who regularly posts graphs of the 
number of packages being submitted to the Haskell package database. 
(Because, after all, it's the number of packages that matters, right? 
Not, say, the quality of those packages or how many people they're 
useful to or even whether they compile at all...)

Don's position was that "the perfect container API hasn't been invented 
yet" and that we need to "experiment" and that these multiple different 
array libraries would "compete" for users and the best one would win. Or 
something like that.

 From where I'm sitting, we've got a library that does A, B and C, 
another one that does A, D and E, another that does C, D and F, and yet 
another that does X, Y and B. And I'd really like to just have a single 
library that does A through Z easily and without fuss. :-P

IMHO, "competition" only works if people actually have the time and 
inclination to try out all the alternatives and pick the one they like 
the best. That probably works for parser libraries. (Indeed, Haskell has 
at least two major ones - Parsec and PolyParse.) I'm not sure it works 
well for a bunch of array libraries when none of them covers more than a 
few use cases.

But hey, it's only my opinion. And I suck at Haskell, remember? :-S

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >> What bit of "Not so different with C and all its derivatives" did you not
> >> get?
> >
> >  Check the thread topic.

> Yes, and C++ .net has standard libraries,

  Defined by which standard?

> what on Earth is your problem, do 
> you really not have anything better to do?

  Look who's talking. ;)

-- 
                                                          - Warp

Post a reply to this message

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.

> Don's position was that "the perfect container API hasn't been invented 
> yet" and that we need to "experiment" and that these multiple different 
> array libraries would "compete" for users and the best one would win. Or 
> something like that.

Interesting assertion ... I don't know what to say.

>  From where I'm sitting, we've got a library that does A, B and C, 
> another one that does A, D and E, another that does C, D and F, and yet 
> another that does X, Y and B. And I'd really like to just have a single 
> library that does A through Z easily and without fuss. :-P

No problem compartmentalizing libraries. But, you really don't need two 
libraries that do A, and three that do C, etc ...

> IMHO, "competition" only works if people actually have the time and 
> inclination to try out all the alternatives and pick the one they like 
> the best. That probably works for parser libraries. (Indeed, Haskell has 
> at least two major ones - Parsec and PolyParse.) I'm not sure it works 
> well for a bunch of array libraries when none of them covers more than a 
> few use cases.

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 ...)

> But hey, it's only my opinion. And I suck at Haskell, remember? :-S

Yeah, right .. Sounds like the Haskell community is dominated by a bunch 
of egos that have closed themselves off from any outside ideas and 
believe that what they think is right, and no one else is.

That's just the sort of thing that will cause a project to stagnate and 
die.

-- 
~Mike

Post a reply to this message

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

http://en.wikipedia.org/wiki/Standard_library

Post a reply to this message

>>> 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.

...OK, *now* I'm depressed. :-/

>> Don's position was that "the perfect container API hasn't been 
>> invented yet" and that we need to "experiment" and that these multiple 
>> different array libraries would "compete" for users and the best one 
>> would win. Or something like that.
> 
> Interesting assertion ... I don't know what to say.

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.

> 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".

>> But hey, it's only my opinion. And I suck at Haskell, remember? :-S
> 
> Yeah, right .. Sounds like the Haskell community is dominated by a bunch 
> of egos that have closed themselves off from any outside ideas and 
> believe that what they think is right, and no one else is.

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.

> 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. :-(

Post a reply to this message

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