Haskell's array libraries... are a mess. Specifically, there is now 
about half a dozen of them.

When I suggested that we should sort this stuff out and make one 
consistent library for handling arrays, the general reaction was "no, 
we're not going to do that. This is open-source. Competition is good. 
We're building a bazaar, not a cathederal."

Um, WTF? I just want to write a program that involves arrays. I 
shouldn't have to spent a week examining a dozen libraries that all 
provide similar-yet-slightly-different implementations of the same 
thing. Not if you want people to take Haskell seriously, at any rate...

I presume the remark is referring to the "cathederal and the bazaar" 
that is sometimes referenced in connection with OSS. Does anybody know 
what it says? (Presumably it claims that proprietry software is like a 
cathederal and OSS is like a bazaar or something...)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I presume the remark is referring to the "cathederal and the bazaar"
> that is sometimes referenced in connection with OSS. Does anybody know
> what it says? (Presumably it claims that proprietry software is like a
> cathederal and OSS is like a bazaar or something...)

My most profound apologies, but

http://tinyurl.com/d6sjjd

 - Ricky

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I presume the remark is referring to the "cathederal and the bazaar" 
> that is sometimes referenced in connection with OSS. Does anybody know 
> what it says? (Presumably it claims that proprietry software is like a 
> cathederal and OSS is like a bazaar or something...)

  WiyF: http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

-- 
                                                          - Warp

Post a reply to this message

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

Post a reply to this message

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).
The core language has exactly one type of array. (Ok, two if you count
dynamically allocated and statically allocated arrays as distinct, although
they behave basically in the exact same way.)

  The C++ standard libraries have two data containers which could be
considered "arrays" (std::vector and std::deque). Perhaps three if you
count std::string. They are pretty straightforward and well-defined.

-- 
                                                          - Warp

Post a reply to this message

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

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

Post a reply to this message

>  Really? C has no array handling libraries whatsoever (standard C, that 
> is).
> The core language has exactly one type of array. (Ok, two if you count
> dynamically allocated and statically allocated arrays as distinct, 
> although
> they behave basically in the exact same way.)
>
>  The C++ standard libraries have two data containers which could be
> considered "arrays" (std::vector and std::deque). Perhaps three if you
> count std::string. They are pretty straightforward and well-defined.

Yep, and then when you start using .net managed C++ there is the original 
.net way of creating arrays, and then the new way...

The problem is when using pre-written code and you're not sure which method 
it's using, you have to search back for statements like this:

String[,,] s = new String[5, 3, 10];
vector<int> iV(x, y);
array<int>^myIntArray = {1,2,3,4,5};

Then try and work out what's going on...

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> Yep, and then when you start using .net managed C++ there is the original 
> .net way of creating arrays, and then the new way...

  But .NET is not standard C++.

-- 
                                                          - Warp

Post a reply to this message

>  But .NET is not standard C++.

What bit of "Not so different with C and all its derivatives" did you not 
get?

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  But .NET is not standard C++.

> What bit of "Not so different with C and all its derivatives" did you not 
> get?

  Check the thread topic.

-- 
                                                          - Warp

Post a reply to this message