For me library support, for networking in particular, has been the major hurdle. It gets problematic when too many libraries are still marked as experimental and only partially implements the specification (e.g. protocol) that they are supposed to handle. Also after a quick look at the source for some common (networking) libraries I found a few too many calls to error to feel comfortable. It's not okay for a library to bring down my application behind my back, error should be reported even if this uglifies the code and interfaces. Furthermore I think that Haskell would benefit from moving some commonly used functionality such as HTTP, SQL and XML support into the standard libraries. I haven't seen any news about the progress of HaskellNet but I guess it could solve my problems. I really don't have much problems with tool support, speed and the like. I'm convinced it's a library (and library documentation!) thing.
As for the 'popularity' of Haskell, someone made the very common sense remark that all successful languages have been promoted by some large corporation. (Please note 'successful' stands for 'spread of use', not 'quality' here.) If fp is to reach the mainstream, it will probably be because of some centralized support from outside the academic world. Maybe something like a 'Haskell Consortium' or 'Haskell Initiative' to promote Haskell should be set up. An example could be the promotion of SystemC for hardware and software co-design by the Open SystemC Initiative www.systemc.org . Availability of an IEEE standard for Haskell would also be a good thing for its acceptance, I think.
Having someone pay a group of people to hack on Haskell implementations would indeed be desirable. Without knowing the details Ubuntu looks like a promising model. If we could just find a willing billionaire out there... Cheers, Johan
On 07/08/06, Johan Tibell
Having someone pay a group of people to hack on Haskell implementations would indeed be desirable. Without knowing the details Ubuntu looks like a promising model. If we could just find a willing billionaire out there...
If I were a billionaire I'd love to sponsor haskell development. Hmm, I'll add it to my goal list ;) Regards, -- Intelligence is like a river: the deeper it is, the less noise it makes
Hello Piotr, Monday, August 7, 2006, 5:29:10 PM, you wrote:
Having someone pay a group of people to hack on Haskell implementations would indeed be desirable. Without knowing the details Ubuntu looks like a promising model. If we could just find a willing billionaire out there...
If I were a billionaire I'd love to sponsor haskell development. Hmm, I'll add it to my goal list ;)
too late - GHC is many years funded by MS Research -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
If I were a billionaire I'd love to sponsor haskell development. Hmm, I'll add it to my goal list ;)
too late - GHC is many years funded by MS Research
I'm aware of that, I was just making a call for more money to deal with organizational stuff (running haskell.org, creating and maintaining a Cabal package database etc)
Hello Johan, Monday, August 7, 2006, 5:25:34 PM, you wrote:
think that Haskell would benefit from moving some commonly used functionality such as HTTP, SQL and XML support into the standard libraries.
http, smtp and other networking protocols - yes. xml/sql is too large things. actually, haxml package is already included in GHC sources distribution and i think that it should be excluded from there because it's too large, far more than any other package bundled with GHC -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
http, smtp and other networking protocols - yes. xml/sql is too large things. actually, haxml package is already included in GHC sources distribution and i think that it should be excluded from there because it's too large, far more than any other package bundled with GHC
The problem I'm having with SQL right now is that there are a number of not complete and splintered implementation efforts. Having one library outside GHCs libraries but still promoted as the default implementation (and hosted under haskell.org) would be enough. Same for XML. I think most of my problems would be solved if cabal-get turned out to something like Ruby Gems so I could easily pull the packages I need to the machines I need (and also get dependencies and a way to remove the packages without leaving files scattered on my file system).
Hello Johan, Monday, August 7, 2006, 7:25:47 PM, you wrote: (sorry for too late answer)
http, smtp and other networking protocols - yes. xml/sql is too large things. actually, haxml package is already included in GHC sources distribution and i think that it should be excluded from there because it's too large, far more than any other package bundled with GHC
The problem I'm having with SQL right now is that there are a number of not complete and splintered implementation efforts. Having one library outside GHCs libraries but still promoted as the default implementation (and hosted under haskell.org) would be enough.
that is because there many developers what had different vision. you can't force them to work together. all that we can do is to declare one library as "standard" one so that the developers who want to contribute to some DB library will work on improving this concrete lib moreover, competition is the only source of progress, so having several competing libs might be better actually than having one "ultimate" one
Same for XML. I think most of my problems would be solved if cabal-get turned out to something like Ruby Gems so I could easily pull the packages I need to the machines I need (and also get dependencies and a way to remove the packages without leaving files scattered on my file system).
one of Google SoC projects is to implement this cabal-get at last end. i hope that situation will change during a next month (when a summer will end :) ) returning to the question discussed by me - i'm all for having better libs and make some of them "standard". but i'm against distributing with GHC any libs that is larger than base lib. to be exact, i want that all multimedia/gui/xml libs will be excluded from ghc, including opengl-based, fgl, openal, object-io, haxml -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin
The problem I'm having with SQL right now is that there are a number of not complete and splintered implementation efforts. Having one library outside GHCs libraries but still promoted as the default implementation (and hosted under haskell.org) would be enough.
that is because there many developers what had different vision. you can't force them to work together. all that we can do is to declare one library as "standard" one
While having a single standardised library is a nice goal, I think a first step would be to highlight the current state and pros and cons of the various options. Perhaps we could at least have wiki pages with recommendations? So that a potential user of some particular functionality - whether it is database accesss, GUI, XML, web application development, and so on - can make an as informed decision as possible? -k -- If I haven't seen further, it is by standing in the footprints of giants
While having a single standardised library is a nice goal, I think a first step would be to highlight the current state and pros and cons of the various options.
Perhaps we could at least have wiki pages with recommendations? So that a potential user of some particular functionality - whether it is database accesss, GUI, XML, web application development, and so on - can make an as informed decision as possible?
I think that would be great. I'm not really qualified to speak of the relative merits of different libraries. Perhaps if someone (I) created a wiki page and then the respective authors could contribute?
participants (4)
-
Bulat Ziganshin -
Johan Tibell -
Ketil Malde -
Piotr Kalinowski