
Hello, What do you think about the following proposal to try to activate people to build up new not-yet-seen Haskell libraries? I remember a discussion a couple of months ago where somebody said that it is more important to have imperfect libraries than to not have a perfect one. This proposal aims for populating your favorite missing libs... First, the libs could be diveded into two parts: to those that are under construction (where some reorganization may occur in near future ~ dev libs) and to those that are more or less stable (where reorganization is not likely to occur in the next few years ~ stable libs). And these libs could be distributed with the Haskell compilers so that they are usable instantly. Second, to populate the dev libs with new funcs, it would be relatively easy to organize monthly competitions with the new HaskellWiki-pages. Idea could be something like - On the first day of the month, a lib design is released on the HaskellWiki, giving 12 competitions a year. - Who completes most of the funcs, documentation, examples FIRST, etc, wins the competition. - Competition tasks (e.g. an individual func) are weighted somehow. - The HaskellWiki has page histories, which can be used to make judgements in cases where a task has no clear winner. - Prices: a name on HaskellWiki Hall of the Fame page or something similar... If there is enough interes in this kind of activity, there is a need for a couple of volunteers to organize everything and to work as judges on the competition days (or weeks). They should decide, what the competition is about etc. What do you think? Pros & Cons? Would you take part in this kind of competition(s), if these were organized? Anybody interested in developing this idea further? I'll guess many people have their favorite missing libs that could be build this way in collaboration and so do I. br, Isto

Hi,
On 3/2/06, Isto Aho
couple of volunteers to organize everything and to work as judges on the competition days (or weeks). They should decide, what the competition is about etc. What do you think? Pros & Cons? Would you take part in this kind of competition(s), if these were organized?
I don't think these kinds of competitions work in open source development. Especially not with such a small community as Haskell's. The beauty of open source development is the cooperation between programmers that share their code and discuss ideas with others. All that disappears when you start a competition because sharing code and discussing ideas might help others rather than helping yourself. Read the following article for further information: http://www.osx86project.org/index.php?option=com_content&task=view&id=127&Itemid=2 But that being said, I still applaude your initiative and the fact that you're trying to come up with some concrete and constructive ideas as to how we might get some more libraries. We do indeed need more libraries. I think one of our problems here is that people somehow set to bar too high. I get the feeling that people are afraid of showing their code (I know I am) because they think that it must be very well-polished and have a very well-thought-though design. It's like everything Haskell needs to be elegant and beautiful as a mathematical theorem. But it will probably do us good to allow for some hackish libraries. They can always be improved upon later. Cheers, /Josef

On Thu, 2 Mar 2006, Josef Svenningsson wrote:
But it will probably do us good to allow for some hackish libraries. They can always be improved upon later.
How can you improve the API later without breaking code that relies on it? In my experience the design, that is the signature of the functions, the naming scheme and the organization in modules, is often the problem and it is hard to change that later.

On 3/3/06, Henning Thielemann
On Thu, 2 Mar 2006, Josef Svenningsson wrote:
But it will probably do us good to allow for some hackish libraries. They can always be improved upon later.
How can you improve the API later without breaking code that relies on it?
You can't. You have to brake the code. Which is not that big a deal. The old version of the library doesn't disappear off the face of the earth just because there is a new version. I agree that backwards compatibility is a good thing but it is not as important as some people make it. Constructive destruction is needed sometimes if we want to make progress. /Josef

Josef Svenningsson wrote:
On 3/3/06, *Henning Thielemann*
mailto:lemming@henning-thielemann.de>
On Thu, 2 Mar 2006, Josef Svenningsson wrote: > They can always be improved upon later.
How can you improve the API later without breaking code that relies on it?
You can't. You have to brake the code. Which is not that big a deal. The old version of the library doesn't disappear off the face of the earth just because there is a new version. I agree that backwards
This was the reason for the thought about the division of the libs clearly to the mature ones and the developing ones. If this was shown somehow to the lib users, at least they would know, if they take a larger risk that their code will break in near future -- I have to admit that this doesn't sound that good any more... There are some systems (could be called interpreters) where the new versions of the libs can be loaded from the web in the console (something like ghci). What would it require to have a repository of old versions of the libs, so that no code would ever break, if the compiling machine had internet connections? Something like import Directory version 4.7.3 and somewhere the address of the repository? The import line could have it at the end overriding the default setting... Does the cabal do that? (Sorry, knows nothing about cabal at the moment.) br, Isto

On Fri, 3 Mar 2006, Isto Aho wrote:
There are some systems (could be called interpreters) where the new versions of the libs can be loaded from the web in the console (something like ghci). What would it require to have a repository of old versions of the libs, so that no code would ever break, if the compiling machine had internet connections? Something like import Directory version 4.7.3 and somewhere the address of the repository?
This sounds like http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory

Henning Thielemann wrote:
On Fri, 3 Mar 2006, Isto Aho wrote:
There are some systems (could be called interpreters) where the new ... compiling machine had internet connections? Something like import Directory version 4.7.3 and somewhere the address of the repository?
This sounds like http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory
Thanks for showing this! I think that R and Perl have systems that work well enough. Something like containing a base system, some libs are considered "base libs" and then there are about zillion different libraries. Many libs do overlap somehow, some are poorly maintained but anyhow most of the stuff can be reached from a central repository (or from its mirror). The "base libs" grow in time, may making some other libs obsolete. (Ok, I should read the docs etc but does Cabal do this?)
br, Isto

Josef Svenningsson wrote:
On 3/2/06, *Isto Aho*
mailto:isto.aho@dnainternet.net> wrote: <idea about library competition snipped> is about etc. What do you think? Pros & Cons? Would you take part
I don't think these kinds of competitions work in open source development. Especially not with such a small community as Haskell's.
What do you think of the discriminating hackers competition?
The beauty of open source development is the cooperation between programmers that share their code and discuss ideas with others. All that disappears when you start a competition because sharing code and discussing ideas might help others rather than helping yourself. Read the following article for further information: http://www.osx86project.org/index.php?option=com_content&task=view&id=127&Itemid=2 http://www.osx86project.org/index.php?option=com_content&task=view&id=127&Itemid=2
But that being said, I still applaude your initiative and the fact that
Ok & thanks! Maybe the idea was bad. However, I was thinking something very much simpler than in the article not involving any money. Idea was to have a "speed contents" (who does most in a few moments - there is no time to steal or exchange ideas), "with relatively easy tasks" (like some statistical distributions, tests, density functions found from elementary text books or some missing utility functions, if there are such etc), "with spirit to do quickly something to be reorganized later". But of course, if the user base is so small that topic would be interesting to only a couple of users, then who would do the reorganization or just maintenance - probably nobody. Isn't this situation the "egg-chicken" problem?
to bar too high. I get the feeling that people are afraid of showing their code (I know I am) because they think that it must be very well-polished and have a very well-thought-though design. It's like
The other thing that I consider a barrier is the often mentioned truth that there are lots of other libs available in other languages and FFI. Somehow, this sounds like "if you need to do math, use octave, R etc, but not Haskell". Why to introduce an extensive Haskell math or some other lib? Feeling like I could list tons of reasons but probably none really strong ones :)
some hackish libraries. They can always be improved upon later.
Yep! br, Isto

On 3/3/06, Isto Aho
What do you think of the discriminating hackers competition?
I'm sorry but I'm not aware of it. Ok & thanks! Maybe the idea was bad. However, I was thinking
something very much simpler than in the article not involving any money. Idea was to have a "speed contents" (who does most in a few moments - there is no time to steal or exchange ideas), "with relatively easy tasks" (like some statistical distributions, tests, density functions found from elementary text books or some missing utility functions, if there are such etc), "with spirit to do quickly something to be reorganized later". But of course, if the user base is so small that topic would be interesting to only a couple of users, then who would do the reorganization or just maintenance - probably nobody. Isn't this situation the "egg-chicken" problem?
Hmmm. Maybe a speed contest would be a rather nice thing after all. Having a small contest will at least draw some programmers attention to the problem. When the competition is over there will be at least a few libraries that one can start working from and improve for those programmers that get hooked by the problem. And given that the contest isn't too long or too ambitious the amount of duplicated work and avoided communication could be held to a minimum. Well, that would be the ideal scenario anyway. But even though we might not so lucky as to get the ideal scenario I think it is worth a shot. I guess I've changed my mind :-) The other thing that I consider a barrier is the often mentioned truth
that there are lots of other libs available in other languages and FFI. Somehow, this sounds like "if you need to do math, use octave, R etc, but not Haskell". Why to introduce an extensive Haskell math or some other lib? Feeling like I could list tons of reasons but probably none really strong ones :)
Yes, tell me about it. It's like we only pretend that it's nice to program in Haskell but when it comes down to actually implementing a library nobody wants to do it. Or is it just that people aren't interested? Cheers, /Josef

On 03/03/06, Josef Svenningsson
On 3/3/06, Isto Aho
wrote: What do you think of the discriminating hackers competition?
I'm sorry but I'm not aware of it.
He's probably referring to the ICFP. See http://icfpcontest.org/ - Cale

On 3/4/06, Cale Gibbard
On 03/03/06, Josef Svenningsson
wrote: On 3/3/06, Isto Aho
wrote: What do you think of the discriminating hackers competition?
I'm sorry but I'm not aware of it.
He's probably referring to the ICFP. See http://icfpcontest.org/
Oh, that one :-) I've even helped organizing it.... Well, the icfpcontest is a completely different thing because the aim is not to create something useful. It's only purpose is to have fun. And since I've had a lot of fun with that contest I'd say it fulfills its purpose. Cheers, /Josef
participants (4)
-
Cale Gibbard
-
Henning Thielemann
-
Isto Aho
-
Josef Svenningsson