![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott <sco### [at] scott com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Yes, and C++ .net has standard libraries,
>
> Defined by which standard?
http://en.wikipedia.org/wiki/Standard_library
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |