|
![](/i/fill.gif) |
>>> 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
|
![](/i/fill.gif) |