Why isn't Haskell mainstream?
Sebastian Sylvan
first year (I'm still in my first year). At first I didn't like it but now
I really really love it.
First I though that it wasn't suitable for "real" programs and just a very
cool "toy" but I now more and more see that it really is an extremly well
suited language for almost any application imaginable, except those where
speed is absolutely crucial (where assembler should be used).
My observartion: Haskell seems to be a toy in the academic world, and the
academic world seems content with this. They don't seem to care that the
outside world is largely unaware of Haskell's greatness, it's seems like
they think it's quite enough that they can benifit from it.
So what do you think is needed for Haskell to be adopted in mainstream
applications?
My thoughts:
* Decent compilers. Code that's ten times slower than C++ is just not
acceptable. I read a paper about a new compiler intermediate language
(GRIN) and some new optimizations. I'm not well versed in the world of
compilers but from what I could gather it seemed very nice indeed.
Speed NEEDS to be a priority. Even though most applications don't really
need it. The "haskell is too slow" argument is something that's going to
work against it in any application, even if speed isn't crucial.
* Decent IDE's. Emacs just doesn't cut it, sorry. hIDE was decent, and I
understand it is now undergoing some work (rewrite?) but we need something
for the windows platform because, like it or not, if it's not on windows,
it's not going to be adopted by the "mainstream".
* Easier to use tools and libraries. Let me take an example here. I would
LOVE to program som OpenGL demos with Haskell to show off that it CAN be
used to write "cool" stuff. However it's nearly impossible to install the
damn library! If I follow the instructions to the letter I get a bunch of
error messages and nothing will work. I've spent hours trying to install
it "manually" but frankly I'm not a UNIX-geek, I don't really know how
makefiles work internally. I want a damn .exe to install the lib for me
and then get to work. My time should be spent writing applications that
win over users for Haskell, not wrestling the installation program for
HOpenGL.
This is a common pattern for Haskell libraries. It seems the authors are
happy when the library works on their computer, and just don't care that
most users don't really have the knowledge to manually tweak the
installation procedures. There should be easy-to-use windows installer for
all libraries. Windows IS very important.
* Tons and tons of example programs. Not just text based calculators or
parsers either. REAL applications. If I were to download a 3D game using
the latest OpenGL extrensions for vertex programs and pixel shaders and
then find out that it was written using Haskell in 3000 lines of code, I
would be very intrigued to learn more about that language.
It's very common to see some researcher write a small example program that
barely works and say "look, proof-of-concept" and then move on to other
interesting subjects.
We need to "suck up" to the average user (like python and java!).
We need to make it easy to get started with Haskell, with tons of
tutorials and example programs. Tons of easy-to-install (and
COMPLETE) libraries.
I have to this day not found a "good" GUI-library for Haskell. Good as in
easy-to-install, easy-to-use and complete.
And if there is a good GUI out there and I haven't found it, is it my
fault? NO! Hell no! I should be able to go to Haskell.org and have links
to stuff like this (I tried to use all libraries posted there).
I believe in Haskell, I think it can be used as a generic language in the
future. But not if the community closes up and "keeps the secret to
themselves".
I care about this because I don't want to apply for a job in the future
and end up in a company where I will be forced to wrestle the ugly beast
that is C++ when I could be using Haskell.
What do you think?
What are the reasons the mainstream hasn't adopted Haskell? I don't think
it's because Haskell isn't worthy of adoption by the general public. So
what is it?
Or am I wrong? Does Haskell just suck? Is it just a research project
without any real-world application?
--
----------------------------------------
| Sebastian Sylvan |
| ICQ: 44640862 |
| Tel: 073-6818655 / 031-812 817 |
| |
| <=================================> |
| |Det finns 10 sorters människor. | |
| |De som förstår det binära tal- | |
| |systemet och de som inte gör det.| |
| <=================================> |
----------------------------------------
Mark Alexander Wotton
> My first contact with Haskell was a mandatory course here at Chalmers my
> first year (I'm still in my first year). At first I didn't like it but now
> I really really love it.
> First I though that it wasn't suitable for "real" programs and just a very
> cool "toy" but I now more and more see that it really is an extremly well
> suited language for almost any application imaginable, except those where
> speed is absolutely crucial (where assembler should be used).
>
> My observartion: Haskell seems to be a toy in the academic world, and the
> academic world seems content with this. They don't seem to care that the
> outside world is largely unaware of Haskell's greatness, it's seems like
> they think it's quite enough that they can benifit from it.
>
> So what do you think is needed for Haskell to be adopted in mainstream
> applications?
>
> My thoughts:
>
> * Decent compilers. Code that's ten times slower than C++ is just not
> acceptable.
This isn't always true, either. Most of the time, programmer time is much
more important than computer time.
> I read a paper about a new compiler intermediate language
> (GRIN) and some new optimizations. I'm not well versed in the world of
> compilers but from what I could gather it seemed very nice indeed.
> Speed NEEDS to be a priority. Even though most applications don't really
> need it. The "haskell is too slow" argument is something that's going to
> work against it in any application, even if speed isn't crucial.
There are lots of people working on making better compilers.
They just haven't been doing it as long as the imperative guys have,
so the compilers aren't as mature. Optimising laziness is an active area
of research: doing it naively results in very slow code. Conversely, some
of the properties of haskell allow for optimisations that you either can't
do for C or are possible but a ridiculous amount of work. Haskell has a
relatively clean set of semantics, so it's sometimes possible to prove that
optimisations work, rather than relying on test cases.
Anyway, what I'm trying to say is that there is hope on this front. People
are routinely getting big speedups with optimisations like optimistic
evaluation.
> * Tons and tons of example programs. Not just text based calculators or
> parsers either. REAL applications. If I were to download a 3D game using
> the latest OpenGL extrensions for vertex programs and pixel shaders and
> then find out that it was written using Haskell in 3000 lines of code, I
> would be very intrigued to learn more about that language.
> It's very common to see some researcher write a small example program that
> barely works and say "look, proof-of-concept" and then move on to other
> interesting subjects.
This is an artefact of research funding, I suspect. You can get a paper
done with a prototype implementation: having a full-blown, mature
implementation doesn't get you much more. (The compiler is probably one
of the few exceptions to this.)
> What do you think?
> What are the reasons the mainstream hasn't adopted Haskell? I don't think
> it's because Haskell isn't worthy of adoption by the general public. So
> what is it?
To be honest, I think the advantages of Haskell only become really obvious
in the hands of a good programmer. (Having made this unsubstantiated and
rather inflammatory statement, I'm going to back away from it carefully and
hope that no-one notices.)
mrak
--
realise your life was only bait for a bigger fish
-- aesop rock
Ketil Malde
>> Speed NEEDS to be a priority.
I guess we could pursue the Java approach, make it slow enough that
speed becomes a constant pain in the neck -- it seems to have worked
for them?
>> What do you think?
I don't think it is at all important that Haskell become "mainstream",
as long as we have a bunch of bright, competent people developing
the language and the libraries.
If you look at the open source projects out there, it becomes
abundantly clear that a small group of devoted individuals are much
more worth than a huge mass of less skilled enthusiasts. I think we
have the critical mass that the language isn't too vulnerable, and
after that, quality is more important than quantity.
As for shelveloads of "Monads for Dummies", well, I couldn't really
care less.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Lennart Kolmodin
> first year (I'm still in my first year). At first I didn't like it but now
> I really really love it.
So do I. It is indeed an amazing language!
> * Decent compilers. Code that's ten times slower than C++ is just not
> acceptable. I read a paper about a new compiler intermediate language
> (GRIN) and some new optimizations. I'm not well versed in the world of
> compilers but from what I could gather it seemed very nice indeed.
> Speed NEEDS to be a priority. Even though most applications don't really
> need it. The "haskell is too slow" argument is something that's going to
> work against it in any application, even if speed isn't crucial.
Sometimes speed is critical but for the most time it's the programmers time
that counts. Most applications dont need more speed so "haskell is too slow"
is not a very strong argument.
> * Easier to use tools and libraries. Let me take an example here. I would
> LOVE to program som OpenGL demos with Haskell to show off that it CAN be
> used to write "cool" stuff. However it's nearly impossible to install the
> damn library! If I follow the instructions to the letter I get a bunch of
> error messages and nothing will work. I've spent hours trying to install
> it "manually" but frankly I'm not a UNIX-geek, I don't really know how
> makefiles work internally. I want a damn .exe to install the lib for me
> and then get to work. My time should be spent writing applications that
> win over users for Haskell, not wrestling the installation program for
> HOpenGL.
> This is a common pattern for Haskell libraries. It seems the authors are
> happy when the library works on their computer, and just don't care that
> most users don't really have the knowledge to manually tweak the
> installation procedures. There should be easy-to-use windows installer for
> all libraries. Windows IS very important.
Take a look at this url:
http://www.jelovic.com/articles/why_people_arent_using_haskell.htm
It's an article by Dejan Jelovic about haskell as a common language. To sum
up he sais that we need more libraries included with the haskell standard
distributions, and I agree.
> We need to "suck up" to the average user (like python and java!).
> We need to make it easy to get started with Haskell, with tons of
> tutorials and example programs. Tons of easy-to-install (and
> COMPLETE) libraries.
Both python and java include a huge library within their distributions. I
like that! :)
> Or am I wrong? Does Haskell just suck? Is it just a research project
> without any real-world application?
No, no and no. =)
// Lennart Kolmodin
Ulrich Hobelmann
> My thoughts:
>
> * Decent compilers. Code that's ten times slower than C++ is just not
> acceptable. I read a paper about a new compiler intermediate language
> (GRIN) and some new optimizations. I'm not well versed in the world of
> compilers but from what I could gather it seemed very nice indeed.
> Speed NEEDS to be a priority. Even though most applications don't really
> need it. The "haskell is too slow" argument is something that's going to
> work against it in any application, even if speed isn't crucial.
This just isn't an argument. Modern computers are fast enough for about
anything. People use interpreted languages like Perl and python
routinely, and the most popular language ist by far the worst -- the
horribly slooow Java -- and I haven't even seen a single good
application written in Java (and not many apps at all)! Well, Java is
mostly used on Servers, probably that's not the strongest asset for Haskell.
Anyway, speed isn't too important. Also it must be said that lots of
people did/are doing research on compilation. But Haskell is *so high
level*, even compared to strict languages like ML, that it's just kind
of hard to optimize certain basic things. But being high level allows
you to get other optimizations that you can't do for C or assembler
(have you ever seen an optimizing assembler ;) ?).
> * Decent IDE's. Emacs just doesn't cut it, sorry. hIDE was decent, and I
> understand it is now undergoing some work (rewrite?) but we need something
> for the windows platform because, like it or not, if it's not on windows,
> it's not going to be adopted by the "mainstream".
An IDE would be nice, certainly. But as long as people, especially in
the research community are quite happy with the emacs tradition and no
one writes something better, there's not going to be one.
This is one problem of these off-mainstream languages -- there doesn't
seem to be interest in writing tools for them. Most developers find it
more sexy to code boring C applications instead of building better
infrastructure for more powerful languages.
> * Easier to use tools and libraries. Let me take an example here. I would
> LOVE to program som OpenGL demos with Haskell to show off that it CAN be
> used to write "cool" stuff. However it's nearly impossible to install the
> damn library! If I follow the instructions to the letter I get a bunch of
> error messages and nothing will work. I've spent hours trying to install
> it "manually" but frankly I'm not a UNIX-geek, I don't really know how
> makefiles work internally. I want a damn .exe to install the lib for me
> and then get to work. My time should be spent writing applications that
> win over users for Haskell, not wrestling the installation program for
> HOpenGL.
> This is a common pattern for Haskell libraries. It seems the authors are
> happy when the library works on their computer, and just don't care that
> most users don't really have the knowledge to manually tweak the
> installation procedures. There should be easy-to-use windows installer for
> all libraries. Windows IS very important.
Right. But again, people don't write better libraries, if they aren't
paid for it, and if they don't need to... This is a bit of a
chicken-egg problem. Maybe someone experienced with this could write an
intro on how to port a library to haskell and to package it, I haven't
looked at it. I think if there's more current libraries, there will be
much more interest, and people will start porting stuff by themselves.
> * Tons and tons of example programs. Not just text based calculators or
> parsers either. REAL applications. If I were to download a 3D game using
> the latest OpenGL extrensions for vertex programs and pixel shaders and
> then find out that it was written using Haskell in 3000 lines of code, I
> would be very intrigued to learn more about that language.
> It's very common to see some researcher write a small example program that
> barely works and say "look, proof-of-concept" and then move on to other
> interesting subjects.
That's researchers. They aren't called "developers" for a reason ;)
>
> We need to "suck up" to the average user (like python and java!).
> We need to make it easy to get started with Haskell, with tons of
> tutorials and example programs. Tons of easy-to-install (and
> COMPLETE) libraries.
> I have to this day not found a "good" GUI-library for Haskell. Good as in
> easy-to-install, easy-to-use and complete.
> And if there is a good GUI out there and I haven't found it, is it my
> fault? NO! Hell no! I should be able to go to Haskell.org and have links
> to stuff like this (I tried to use all libraries posted there).
>
> I believe in Haskell, I think it can be used as a generic language in the
> future. But not if the community closes up and "keeps the secret to
> themselves".
> I care about this because I don't want to apply for a job in the future
> and end up in a company where I will be forced to wrestle the ugly beast
> that is C++ when I could be using Haskell.
Hmmm. Neither do I. But you might have to start your own company then.
> What do you think?
> What are the reasons the mainstream hasn't adopted Haskell? I don't think
> it's because Haskell isn't worthy of adoption by the general public. So
> what is it?
>
> Or am I wrong? Does Haskell just suck? Is it just a research project
> without any real-world application?
No, I think it could be used quite well, though I'm more of a strict
language person (ML, Scheme). Once out of the research corner, Haskell
could really shine.
Jerzy Karczmarczuk
> ... Modern computers are fast enough for about
> anything. People use interpreted languages like Perl and python
> routinely, and the most popular language ist by far the worst -- the
> horribly slooow Java -- and I haven't even seen a single good
> application written in Java (and not many apps at all)!
...
> Anyway, speed isn't too important.
The discussion concerning program speed seems to be an immortal issue.
While I agree that - at least for most programs - the brutal execution
speed should never be the first criterion, some gurus, notably some
teachers tend to abuse the half-truth: "human time, developing and
debugging is by far more important than the execution". I abused this
myself, so I feel entitled to criticize it.
1. Reckless usage of linear lists instead of indexed vectors with O(1)
access time may be harmful. Transforming a pretty, recursive, list-
based progam into an optimized, array-based one may be a true pain.
2. When you think only about cute elegance, compactness, etc., then
even if you are a conscious teacher, your psychic forces against
wrong - from the complexity point of view - algorithms weaken.
And you start using slow sorting routines, O(n^4) Delaunay trian-
gulations, lousy numerical procedures, etc.
Within a lazy language you begin to generate useless thunks, and
you complain that the memory usage become inacceptable...
(I have - unfortunately - seen papers which advocated functional
languages insisting mainly on the compact notation, e.g. fold (+)
used to sum some numbers, showing thus how easy is the numerical
integration in Haskell. Of course *nobody* serious would buy this.
On the other hand, I've seen a negative referee's report who
concluded: "this is just an applicative work, not a scientific
paper". So, people who want to work on applications of FP find
themselves too often between Scylla and Charybdis.)
So, please, BE CAREFUL!!
There is one psychological issue which should not be forgotten. When
rumors spread that Haskell is good for theoreticians, that Scheme is
'just' good for introductory courses on programming, etc., it becomes
extremely difficult to reach the professional programmers. The techni-
cal professionalism is essential. You might respond that Java and
often C++ programs are horribly written as well, if not worse. Doesn't
matter. It is the FP world which is regarded with suspicion, not all
those Javas and other C#...
> ... But being high level allows
> you to get other optimizations that you can't do for C or assembler
> (have you ever seen an optimizing assembler ;) ?).
Sure.
Eons ago there there was a family of macro-assemblers 'Compass' for
the CDC Cyber series mainframes. People added to them several routines
permitting to optimize the register usage, to optimize the peripheral
processor calls, etc. Nice stuff, rarely used...
> An IDE would be nice, certainly. But as long as people, especially in
> the research community are quite happy with the emacs tradition and no
> one writes something better, there's not going to be one.
Who is happy is happy. I do know a few people who aren't. This is not
just the question of an editor (personally I prefer Xcoral or Nedit than
Emacs, and under Windows such editors as TextPad, or WinEdt, but never
mind), but also some bookkeeping, say: module dependencies, reporting
the types of undeclared variables/functions, etc., all the stuff which
is ensured by the Clean IDE for example.
> This is one problem of these off-mainstream languages -- there doesn't
> seem to be interest in writing tools for them. Most developers find it
> more sexy to code boring C applications instead of building better
> infrastructure for more powerful languages.
My goodness... Do you think that Smalltalk is a "main-stream language"?
I think not. And the development tools, browsers, inspectors, debuggers,
etc. are, and were from the beginning in the center of attention of all
implementors.
Python has at least 4 different IDEs, such as IDLE, PyCrust, etc. The
DrScheme system is quite decent.
Alright, we know that for purely functional languages the interfacing is
a headache. It can be done, it IS being done, but there is a threshold
which is not reached yet, a visible, positive reaction coming from
people who work on applications, and make money with. But this will
happen one day.
Jerzy Karczmarczuk
Caen, France
Sebastian Sylvan
> > * Decent compilers. Code that's ten times slower than C++ is just not
> > acceptable. I read a paper about a new compiler intermediate language
> > (GRIN) and some new optimizations. I'm not well versed in the world of
> > compilers but from what I could gather it seemed very nice indeed.
> > Speed NEEDS to be a priority. Even though most applications don't really
> > need it. The "haskell is too slow" argument is something that's going to
> > work against it in any application, even if speed isn't crucial.
>
> Sometimes speed is critical but for the most time it's the programmers time
> that counts. Most applications dont need more speed so "haskell is too slow"
> is not a very strong argument.
I'm not arguing. I'm saying that *other* people will always be able to say
"well it's slower!" when they run out of arguments. =)
If it could give you speed comparable to C++ then there would be
absolutely no reason to use that language anymore for the bulk of the
applications.
>
> Take a look at this url:
> http://www.jelovic.com/articles/why_people_arent_using_haskell.htm
> It's an article by Dejan Jelovic about haskell as a common language. To sum
> up he sais that we need more libraries included with the haskell standard
> distributions, and I agree.
I don't agree.
While I understand that this is necessary for interpreted language where
the libraries need to be A) available on every machine which has the
language installed B) perhaps precompiled for speed, I don't think this is
the route for Haskell.
I'd much rather have Haskell be a general purpose tool, than "binding" it
too tightly to "specific" libraries (GUI, networking, whatever) via a
"standard" distribution.
There should be a better guide to the available libraries form
Haskell.org, making it easier to find the "best" one for your needs and
making it easier to link it with your project.
>
> > We need to "suck up" to the average user (like python and java!).
> > We need to make it easy to get started with Haskell, with tons of
> > tutorials and example programs. Tons of easy-to-install (and
> > COMPLETE) libraries.
>
> Both python and java include a huge library within their distributions. I
> like that! :)
Yes, that's nice, but it also limits those languages.
That whole awt/swing mess in Java for instance. Also, ever wonder why the
paint function takes a Graphics2D casted to a Graphics object so you have
to cast it BACK to Graphics2D? You guessed it, the standard libraries.
Binding the language to "specific" libraries is a BAD thing if you don't
have to do it (which you DO for interpreted languages). If something
changes you still have to support the old, which can clutter up the
library quite a bit.
Java's standard libraries is a great example of "more is better"-attitude
gone horribly wrong.
I really hope Haskell doesn't take the route of those two languages.
Shae Matijs Erisson
>> My first contact with Haskell was a mandatory course here at Chalmers my
>> first year (I'm still in my first year). At first I didn't like it but now
>> I really really love it.
>
> So do I. It is indeed an amazing language!
Me too!
> Take a look at this url:
> http://www.jelovic.com/articles/why_people_arent_using_haskell.htm
> It's an article by Dejan Jelovic about haskell as a common language. To sum
> up he sais that we need more libraries included with the haskell standard
> distributions, and I agree.
I also agree. I came from Python to Haskell, and I want to see all the
libraries that Python has written in Haskell. So I've started writing the
libraries that I want to use and can't find. Check out the cvs tree on
http://sf.net/projects/haskell-libs
The idea behind that project is something like a 'cvs-wiki' where you can
contribute code you've written, and hopefully we can come up with these missing
libraries.
>> We need to "suck up" to the average user (like python and java!).
>> We need to make it easy to get started with Haskell, with tons of
>> tutorials and example programs. Tons of easy-to-install (and
>> COMPLETE) libraries.
Yes!
One part of the haskell-libs project is a web-based library listing thingy,
something like freshmeat.net for Haskell projects. We have a rough but working
prototype, written by Isaac Jones (thanks Isaac!).
--
Shae Matijs Erisson - 2 days older than RFC0226
#haskell on irc.freenode.net - We Put the Funk in Funktion
Donn Cave
| Sebastian Sylvan wrote:
|> * Decent compilers. Code that's ten times slower than C++ is just not
|> acceptable. I read a paper about a new compiler intermediate language
|> (GRIN) and some new optimizations. I'm not well versed in the world of
|> compilers but from what I could gather it seemed very nice indeed.
|> Speed NEEDS to be a priority. Even though most applications don't really
|> need it. The "haskell is too slow" argument is something that's going to
|> work against it in any application, even if speed isn't crucial.
|
| This just isn't an argument. Modern computers are fast enough for about
| anything. People use interpreted languages like Perl and python
| routinely, and the most popular language ist by far the worst -- the
| horribly slooow Java -- and I haven't even seen a single good
| application written in Java (and not many apps at all)! Well, Java is
| mostly used on Servers, probably that's not the strongest asset for Haskell.
| Anyway, speed isn't too important. Also it must be said that lots of
| people did/are doing research on compilation. But Haskell is *so high
| level*, even compared to strict languages like ML, that it's just kind
| of hard to optimize certain basic things. But being high level allows
| you to get other optimizations that you can't do for C or assembler
| (have you ever seen an optimizing assembler ;) ?).
It is an argument, it's just that it's significance is debatable.
When the "language shootout" (http://www.bagley.org/~doug/shootout/)
made Objective CAML look pretty good, I'm sure I'm not the only one
who took another look at it. So far, to me it has turned out to be
a really nice implementation, not just fast but easy to write C/C++
extensions and works on every platform I've tried. That implementation
promotes its language. GHC wasn't terribly slow, but in my experience
it isn't nearly as portable as Objective CAML either - haven't been
able to build it anywhere, even on NetBSD which with gcc and ELF you
would think would be pretty likely to work. I'd trade some speed
of execution for an elegant language, but I do need to be able to
execute.
Donn Cave, do...@u.washington.edu
Franck Arnaud
> First I though that it wasn't suitable for "real" programs and just a very
> cool "toy" but I now more and more see that it really is an extremly well
> suited language for almost any application imaginable, except those where
> speed is absolutely crucial (where assembler should be used).
I have some doubts it is entirely suitable for large scale
commercial programming: projects with large body of code and many
programmers. Haskell, like many/most(/all?) programming languages,
seems to have been designed with the one-programmer hypothesis in
mind (that the world has 1 programmer who needs maximum flexibility,
rather than many programmers working on the same body of code, who
need maximum communication).
Things like lazyness may become quite problematic when applied to
large programs no one person understands fully, and when exposed
to teams with individuals of varying ability.
It also does make sense that unproven features spend some time
in research or at the margin of the mainstream before being widely
adopted. But in the end truly good ideas will be adopted. For
instance, garbage collection is now nearly universal, but it took
20 years to get to the mainstream.
Mark Carroll
Franck Arnaud <fra...@nenie.org> wrote:
(snip)
>I have some doubts it is entirely suitable for large scale
>commercial programming: projects with large body of code and many
>programmers. Haskell, like many/most(/all?) programming languages,
>seems to have been designed with the one-programmer hypothesis in
>mind (that the world has 1 programmer who needs maximum flexibility,
>rather than many programmers working on the same body of code, who
>need maximum communication).
What makes you say that? I don't get this vibe from Haskell at all.
For instance, GHC's hierarchical modules and Haddock for documenting
code seem to work well. hmake has also been coming along quite nicely.
Regular revision/version control systems work well. (We're
test-driving subversion.) At least, I don't see Haskell being any
worse than many other mainstream programming languages that are
routinely used for large scale commercial programming - except,
perhaps, for lack of a good IDE (I normally live inside emacs for
programming, so I don't notice this as much). My only complaint is
that GHC seems to need a lot of resources to compile some things -
that's an issue we're investigating. But all the abstraction that FP
offers is great.
>Things like lazyness may become quite problematic when applied to
>large programs no one person understands fully, and when exposed
>to teams with individuals of varying ability.
Well, an advantage of doing things purely functionally is that it
means a lot more when you test parts of the system in isolation - with
things like HUnit you can construct tests to make sure others' code is
meeting your expectations. There are profiling tools, etc. to help you
wrangle control of evaluation if you're not sure what's going on. I
agree it's an issue, but it's far from being a show-stopper.
>It also does make sense that unproven features spend some time
>in research or at the margin of the mainstream before being widely
>adopted. But in the end truly good ideas will be adopted. For
>instance, garbage collection is now nearly universal, but it took
>20 years to get to the mainstream.
Yes, certainly.
-- Mark
Jerzy Karczmarczuk
...
>>It's an article by Dejan Jelovic about haskell as a common language. To sum
>>up he sais that we need more libraries included with the haskell standard
>>distributions, and I agree.
>
> I don't agree.
> While I understand that this is necessary for interpreted language where
> the libraries need to be A) available on every machine which has the
> language installed B) perhaps precompiled for speed, I don't think this is
> the route for Haskell.
>
> I'd much rather have Haskell be a general purpose tool, than "binding" it
> too tightly to "specific" libraries (GUI, networking, whatever) via a
> "standard" distribution.
Please, let be serious and consequent. There is nothing "tight" in providing
a decent set of specific libraries. They, and only they ensure that
a language is being professionally used. General purpose tool? Yet another
one? Who will use it outside the (mythical concept known as the) Academia,
taking into account all necessary investments? Do you think that physicists
would use Fortran without NagLib, CERNlib, now netlib etc.?
> There should be a better guide to the available libraries form
> Haskell.org, making it easier to find the "best" one for your needs and
> making it easier to link it with your project.
I think that much more important is some critical quota of running
applications which show black on white that those libraries are
being effectively used.
>>Both python and java include a huge library within their distributions. I
>>like that! :)
>
>
> Yes, that's nice, but it also limits those languages.
Limits?
Are you sure that you know what are you saying?
> That whole awt/swing mess in Java for instance. Also, ever wonder why the
> paint function takes a Graphics2D casted to a Graphics object so you have
> to cast it BACK to Graphics2D? You guessed it, the standard libraries.
> Binding the language to "specific" libraries is a BAD thing if you don't
> have to do it (which you DO for interpreted languages). If something
> changes you still have to support the old, which can clutter up the
> library quite a bit.
> Java's standard libraries is a great example of "more is better"-attitude
> gone horribly wrong.
>
> I really hope Haskell doesn't take the route of those two languages.
I don't use Java, but I put a few of my students on some projects based
on Java3D and they were able to complete substantial parts of it in
2 weeks (I do not claim that they, nor I were happy with the result).
Once a library is well modularized and documented, all those stupidities
you mention above become irrelevant. All those 'tight bindings' which you
*DO* as you say, for interpreted languages is just a myth, is your
personal nightmare, not the reality. I agree that Java is clumsy, but
what about Python? Interpreted.
Having at least two popular *independent* GUI styles/packages/widgets
etc.: Tkinter and wxPython (and some others as well).
Graphical libraries? Working smoothly with PIL, with OpenGL, with SDL
(through pygame).
The OpenGL business may be used stand-alone, through PyOpenGL, through
ZOE, very simple, or through a complete, user-friendly (but very
simplified) layer: VPython.
Numerical packages permit to use Python as a vector/matrix language,
like Matlab. Etc. Etc.
The result is that legions use Python everyday...
OK, you will pray that Haskell take a different route. It did. So
what? Are we happy?
Jerzy Karczmarczuk
Sebastian Sylvan
> > I'd much rather have Haskell be a general purpose tool, than "binding" it
> > too tightly to "specific" libraries (GUI, networking, whatever) via a
> > "standard" distribution.
>
> Please, let be serious and consequent. There is nothing "tight" in providing
> a decent set of specific libraries.
Yes it is. If you can explain to me exactly what, say, HTML-parsing has to
do with Haskell, then I'll gladly step aside.
Fact of the matter is that if Haskell is supposed to be general purpose,
then HTML-parsing DOESN'T have anything to do with the language (and as
such does not belong in a standard distribution).
Putting the library up as a link to an independent developer on
haskell.org is different because when HTML isn't used anymore you can just
take down that link (or leave it!) and put up links to other libraries
instead. You haven't got any implied or expressed obligation to support
HTML-parsing in your "general-purpose" language.
There are already a ton of scripting languages that have many specific
libraries, (e.g. Python, Ruby) we don't need another one.
There are, however, not as many truly high-level general purpose languages
(like C# and C++, only higher level).
> > Yes, that's nice, but it also limits those languages.
>
> Limits?
> Are you sure that you know what are you saying?
Yes. I am of course talking from my own preferences. But I'm quite
confiedent that if you were to include say Tk as the de facto standard for
GUI's in Haskell then you would have an implied obligation to support Tk
"forever", even if something 10 times better comes along on the GUI front.
You could then supply a second library for GUI but that needlessly
clutters up the standard libraries.
Or you could just not bother implementing the "new" and sticking to Tk,
the result being that the bulk of users will never even know that there's
something better out there - they'll be too busy using Tk.
Or you could take a more impartial route, just link to the libraries from
the official site, careful not to imply any level of official support
anywhere.
There's nothing stopping you from including a "recommended libraries
installation" or something like that. But not standardizing it, requiring
that every haskell distribution has to include a set of libraries.
I don't have anything against building tons of python-like libraries, it's
just the idea that some standard organ (who? btw? There is no Haskell
committe right now is there?) should decide which libraries "make it" and
which don't just doesn't appeal to me.
So by all means, throw together tons of "useful" libraries, but don't tie
them to the language by calling them "standard".
> I don't use Java, but I put a few of my students on some projects based
> on Java3D and they were able to complete substantial parts of it in
> 2 weeks (I do not claim that they, nor I were happy with the result).
This is relevant how?
I'm not arguing against specific libraries, I'm arguinag against
"standard" specific libraries.
Yes Java 3D was useful to them. How about 2 years from now when the
minimum level of graphics fidelity requires per pixel specular
highlighted bumpmapped surfaces with stencil shadow volumes. Will Java 3D
still be useful then? Or will it be too busy keeping its
backwards-compability.
I'm guessing the it will be quite busy keeping backwards compability.
So yes libraries ARE useful, even if they are "standard", but they're not
any LESS useful if you "disown" them from the language and merely keep
them on a "recommended-list". They're probably more useful since they can
be updated more often (it's unlikely that a new language revision will be
released because one of the standard libraries has made a small change).
And, if the world changes, the library can be thrown away!
=====
If you're not interested in anything else but the "issues" then read no
further
=====
> OK, you will pray that Haskell take a different route. It did. So
> what? Are we happy?
There are two ways you can handle this. You can be a prick, or you can try
to understand my arguments, and respond in an polite and constructive
manner. You apparently didn't choose the latter.
No I'm not happy, as my entire post showed. I was wondering what we could
do to help Haskell become mainstream as a general purpose language (not as
a replacement for Visual Basic or Python or whatever - more as a
replacement for C# and C++).
The post was not "as long as it doesn't take the path of Python I'm
happy".
Something which should've been fairly evident.
It's not religion you know. I'm allowed to dislike the Python way of doing
things without getting baseless cheap-shots from you.
I say cheap-shot because that sentence above is, really, a cheap shot. You
KNOW that's not what I meant but you intentionally misunderstand me in
order to get in a snappy rhetorical ending to your pro-python-rally-post.
It's not religion. Ease up. It's just a tool.
Respectfully,
Franck Arnaud
> >I have some doubts it is entirely suitable for large scale
> >commercial programming: projects with large body of code and many
> >programmers. Haskell, like many/most(/all?) programming languages,
> >seems to have been designed with the one-programmer hypothesis in
> >mind (that the world has 1 programmer who needs maximum flexibility,
> >rather than many programmers working on the same body of code, who
> >need maximum communication).
> What makes you say that?
It's a feeling and not something proven of course (I'm not even
fluent in Haskell). Some factlets though: syntax, which is perl-ish
and trick-friendly, allowing to express the same things in many
ways hence decreasing readability in groups, as each developer
is likely to develop their own preferred dialect, putting a barrier
to entry on someone else reading the code. Each piece of punctuation
seems to be allocated an increasing amount of semantics (a paper
justified yet another punctuation-overloading extension by giving
an example where it had already been done...). Also reading the
Haskell literature, it seems most language features are judged
on how good they are in the small (at implementing such and
such patterns, or sometimes antipatterns) and never on how they
would scale to groups of programmers. Although I have to say
this is probably a general feature of virtually all programming
language research rather than Haskell in particular.
> At least, I don't see Haskell being any worse than many other
> mainstream programming languages that are routinely used
> for large scale commercial programming -
Certainly, but this is a rather mediocre yardstick. A language
that is to advance the field should be much better than the
status quo, rather than just no worse! (Haskell does certainly
provide significant advances in a number of areas.)
> Well, an advantage of doing things purely functionally
Sure, but you don't need lazyness to get the benefits of being
purely functional. My intuition is that referential transparency
is proven and ready for widespread use, but that lazyness needs
more research.
Sebastian Sylvan
> It's a feeling and not something proven of course (I'm not even
> fluent in Haskell). Some factlets though: syntax, which is perl-ish
> and trick-friendly,
I just don't recognize this at all. One of the key benifits of Haskell to
me is that the syntax is very clean and obvious. Whereas other languages
like python offer a billion different ways of doing things (among which
you'll find some functional tools such as map and zip), Haskell really
only offers two different "paradigms". I can't really name them but one is
where you use "where", "guards" and "pattern matching" and the other where
you use "let .. in" and "if statements".
Most people use them both in situations where one or the other is more
suited.
Sure there are some functions you can use to simplify (and maybe even
speed up) certain things (scan, fold, zip, map etc.), but they all usually
boil down to the same thing if you apply them.
C++, python and other languages suffer from this MUCH more.
Like I said, Haskell for me is very straightforward and "unified" compared
to those languages. Yet it's still very much expressive so you're not
limited in what you can do.
> Haskell literature, it seems most language features are judged
> on how good they are in the small (at implementing such and
> such patterns, or sometimes antipatterns) and never on how they
> would scale to groups of programmers.
Most languages are like this. It's hard to print out a milion line example
in a text book =)
I see no reason why Haskell wouldn't scale. Haskell programming is usually
pretty data-driven, and most data will probably have an abstract data type
in its own module so when you need to work on a data type you "check out"
that module and make the changes you want. Much in the same way you would
check out a class in C++.
My $0.02
Joachim Durchholz
> I see no reason why Haskell wouldn't scale.
The problem seems to be that lazy evaluation makes it difficult to judge
which calls will take how much time and space. Particularly if you're
feeding a function result from one black-box module into a function of
another black-box module.
In a strict language, I can experimentally determine the time needed:
just run the output-producing function with a few test cases, then the
input-accepting functions, sum the results, and voilà - you've got a
rough first estimate. In a lazy language, such a poor man's complexity
analysis is useless, anything less than a precise analysis can give you
wildly wrong results (because the unevaluated parts of the function
output may or may not be evaluated in the second function, depending on
the exact execution path).
To sum it up:
1) You need to look at the implementations of functions. That's counter
to black-box programming, something that's been becoming more and more
important as programs grows.
2) You need to analyze the interaction of any two program fragments that
are stuck together. Since this analysis must be redone at each higher
level (we've got to check the entire implementation after all), this
means that a program of N functions requires O(N^2) (actually
O(N*average_call_depth) analysis steps to make sure that no performance
traps are hidden inside it. This is exactly what constitutes "doesn't
scale".
If there are dependable and useful laziness annotations on the
parameters and result of a function, then things change: you don't have
to look at the implementation.
I'm not sure whether such a beast exists. If laziness annotations are
programmer-written, this means a lot of annotative work (something we
just got rid of thanks to HM typing). If they are compiler-inferred,
it's likely that the type error problem returns: the annotations become
so large that they get unreadable.
(The above is just what I gathered and inferred from various Usenet
posts, not personal experience. Corrections and clarifications welcome.)
Regards,
Joachim
--
This is not an official statement from my employer.
Russell Wallace
<syl...@dtek.chalmers.se> wrote:
>On Mon, 10 Feb 2003, Lennart Kolmodin wrote:
>
>> Sometimes speed is critical but for the most time it's the programmers time
>> that counts. Most applications dont need more speed so "haskell is too slow"
>> is not a very strong argument.
>
>I'm not arguing. I'm saying that *other* people will always be able to say
>"well it's slower!" when they run out of arguments. =)
So what? You can always say "it's slower" by finding the right
benchmark. (I'm surprised there isn't one for Haskell; it must be the
only language in the world that doesn't have benchmarks to "prove"
it's faster than C. Going by the benchmarks, C must be the slowest
language ever implemented :))
More to the point, none of that matters. Given the performance of
modern hardware, if someone uses "it's slow" [1] as a reason for not
using a language, what they really mean is "I don't like it, but I'm
afraid I won't sound 'logical' enough if I just give that as the
reason, so I'll come up with an excuse that sounds objective." (Which
is silly; programming is a branch of psychology, and "I don't like it"
is a perfectly valid reason for not using a language, but that's
another thing.) If that doesn't work, they'll just find another
excuse.
The upshot of that is, arguing with people who say "I don't want to
use Haskell because it's slow" is a waste of everyone's time. (And I'm
not even commenting here on whether Haskell or C is the better
language, only on the psychological facts.) If you want more people to
use Haskell, concentrate on genuine barriers like ease of installation
and learning and availability of standard libraries.
[1] That's not entirely true - things like quantum chemistry and 3D
games are still too slow on modern hardware. But people writing that
sort of software are already aware of the speed requirement and have
chosen their tools accordingly. I'm talking about the 90% of
applications where speed is irrelevant.
--
"Mercy to the guilty is treachery to the innocent."
Remove killer rodent from address to reply.
http://www.esatclear.ie/~rwallace
Sebastian Sylvan
> >I'm not arguing. I'm saying that *other* people will always be able to say
> >"well it's slower!" when they run out of arguments. =)
>
> So what? You can always say "it's slower" by finding the right
> benchmark.
>
> modern hardware, if someone uses "it's slow" [1] as a reason for not
> using a language, what they really mean is "I don't like it, but I'm
> afraid I won't sound 'logical' enough if I just give that as the
> reason, so I'll come up with an excuse that sounds objective."
Maybe. I'm pretty convinced though that if you were to take a brief look
at Haskell and spot the elegant syntax etc. and then see that it's only
marginally slower than C++, you're more likely to start using it than if
you see that it's 10 times slower.
Personally I don't care much for application speed, I don't even think 3D
games are as critical as they used to be (almost everything 3D-related is
taking place on hardware now, only AI and game logic is really done on the
CPU).
Sebastian Sylvan
> The problem seems to be that lazy evaluation makes it difficult to judge
> which calls will take how much time and space. Particularly if you're
> feeding a function result from one black-box module into a function of
> another black-box module.
If you need this it is entirely possible to have Haskell evaluate a "black
box" strictly. A data type could use the ! operator to signify its
constituents should be evaluated strictly. This should be used more than
it is, in any data type where extracting just one of the parts doesn't
make sense (complex numbers, quaternions etc).
So to summarize this point: if you NEED predictable time and space behavor
then write the code strict. Most of the time (in most applications) you
will never need completely predictable time and space behavior so you
write it lazily.
> 1) You need to look at the implementations of functions. That's counter
> to black-box programming, something that's been becoming more and more
> important as programs grows.
No you don't. Try it out, if it doesn't work for you, then you'll have to
write another function. It's no different from a strict language except
that in Haskell you can be sure that you will always evaluate as little as
possible. Just throw in a deepseq to evaluate it all the way down and
meassure the time and space complexity, write a "<=" in front of it,
remove the seq and there you go.
> 2) You need to analyze the interaction of any two program fragments that
> are stuck together. Since this analysis must be redone at each higher
> level (we've got to check the entire implementation after all), this
> means that a program of N functions requires O(N^2) (actually
> O(N*average_call_depth) analysis steps to make sure that no performance
> traps are hidden inside it. This is exactly what constitutes "doesn't
> scale".
Not really. What you seem to want are worst-case scenarios which can be
obtained as described above. You'll most likely not reach those levels in
a real program though. Which should be seen as a benifit compared to
strict languages. Whereas a strict function may ALWAYS use a certain
amount of time to do a task, the lazy version might save time when it can.
There shouldn't be any need to analyze the entire program together, just
analyze the worst-case (the strict case) scenario for each function and
rest assure that it will never be any worse than that.
Franck Arnaud
> Haskell really only offers two different "paradigms". I can't really name
> them but one is where you use "where", "guards" and "pattern matching"
> and the other where you use "let .. in" and "if statements".
I think there are more dimensions than that, see:
http://www.willamette.edu/~fruehr/haskell/evolution.html
> C++, python and other languages suffer from this MUCH more.
I'd rate Python close to Haskell on syntax (usable but could be
significantly more regular). C++ is much worse, but that's a world
champion for crap syntax.
Russell Wallace
<syl...@dtek.chalmers.se> wrote:
>Maybe. I'm pretty convinced though that if you were to take a brief look
>at Haskell and spot the elegant syntax etc. and then see that it's only
>marginally slower than C++, you're more likely to start using it than if
>you see that it's 10 times slower.
Mmm, I still don't believe it; I think someone who's otherwise
inclined to like it won't even bother inquiring about how fast it is
compared to C++. (I don't use it myself because, while it's
theoretically interesting, I'd probably end up gnawing one of my own
legs off if I had to program in it every day :) But I don't fool
myself about speed being the issue.)
>Personally I don't care much for application speed, I don't even think 3D
>games are as critical as they used to be (almost everything 3D-related is
>taking place on hardware now, only AI and game logic is really done on the
>CPU).
*nods* These days it's not uncommon to use a high-level scripting
language for the game content.
Christoph Breitkopf
> Sebastian Sylvan:
>
> > Haskell really only offers two different "paradigms". I can't really name
> > them but one is where you use "where", "guards" and "pattern matching"
> > and the other where you use "let .. in" and "if statements".
>
> I think there are more dimensions than that, see:
>
> http://www.willamette.edu/~fruehr/haskell/evolution.html
I don't think that these 'style' variations are all that relevant as
far as the mainstream is concerned. The important thing is how
bigger, real-world programs are constructed. I.e. mostly functional,
monadic style, whatever. If, for example, I end up with all my
leaf functions being of type a -> IO b, something is probably
wrong (IMO, at least). The easy of adding debugging output,
passing options, and such is rather relevant to larger scale
adoption of Haskell. Despite being a big fan of Haskell, all
I use it for are script-like programs - nothing larger yet.
Regards,
Chris
Mark Carroll
>
>http://www.willamette.edu/~fruehr/haskell/evolution.html
(-: Of course, most of the code on that page really isn't something
that one would normally write - there's what's possible, and what can
be reasonably expected in real code.
-- Mark
Joachim Durchholz
>
> Personally I don't care much for application speed, I don't even think 3D
> games are as critical as they used to be (almost everything 3D-related is
> taking place on hardware now, only AI and game logic is really done on the
> CPU).
Don't underestimate AI. From what I've heard, modern games easily stress
the processor to 100% with AI. (Particularly if there's AI for dozens or
hundreds of computer-controlled entities.)
Hannah Schroeter
Franck Arnaud <fra...@nenie.org> wrote:
>[...]
>adopted. But in the end truly good ideas will be adopted. For
>instance, garbage collection is now nearly universal, but it took
>20 years to get to the mainstream.
It would be nice if it *were* so. I'm still mostly caught in
C++ land with manual memory management :-E. At most poor (wo)man's
GC (AKA reference counting "smart" pointers). Bah.
Kind regards,
Hannah.
Sebastian Sylvan
> > Personally I don't care much for application speed, I don't even think 3D
> > games are as critical as they used to be (almost everything 3D-related is
> > taking place on hardware now, only AI and game logic is really done on the
> > CPU).
>
> Don't underestimate AI. From what I've heard, modern games easily stress
> the processor to 100% with AI. (Particularly if there's AI for dozens or
> hundreds of computer-controlled entities.)
On the other hand functional languages are pretty well suited for AI so it
might actually be one of those (rare) cases when Haskell is faster than
C++. Don't do much AI programming myself (none =)) but I've "heard" that
lazy evaluation really comes to its right with some AI algorithms.
Hampus Ram
Sebastian Sylvan <syl...@dtek.chalmers.se> wrote:
>* Decent compilers.
Yes, but it's not speed we need. We need less memory usage. You relly
need to think on how you code in haskell if you don't want your program
to eat huge amounts of memory. Heap profiling is a must and sometimes
you have to resort to unboxed arrays and other foul stuff.
>* Easier to use [...] libraries.
YES! This _must_ be fixed before Haskell can become widely used.
Unfortunately some try to remedy this by introducing new tools such
as hmake which I think is very bad. We do not need new tools, at least
not to configure/compile/install libraries, just ways to simplify
the use of the old ones (such as make and autoconf). Most of us
use many different languages (?) and we don't need (at least not I)
ten different programs that do the very same thing.
Another issue is the standard libraries. Why do I have to use ghc if I
want to use some decent data structures? A map is a map and a set is a
set, there is no reason what so ever not to make them standard.
>* Tons and tons of example programs.
Well, start to code... Seriously this is sort of a problem. Those who
would write these cool example programs don't use haskell since they
haven't seen any cool haskell programs. Most researchers don't have the
time to write anything but proof-of-concept.
>I have to this day not found a "good" GUI-library for Haskell. Good as in
>easy-to-install, easy-to-use and complete.
This is related to the "everything-is-so-damned-hard-to-compile" problem.
I like gtk somewhat and gtk2hs seems to be nice, if incomplete. However
last time I tried to compile gtk+hs it took quite some tweaking to get it
workning. This is no good.
>I care about this because I don't want to apply for a job in the future
>and end up in a company where I will be forced to wrestle the ugly beast
>that is C++ when I could be using Haskell.
... and here comes a part of the reason why this matters. Haskell
becoming mainstream isn't a question of avoiding questions about why
you're using unknown languages, but of making a better world and
increasing the number of people that can contribute to the haskell
community, i.e. making life easier.
But ask not what the haskell communiy can do for you, but what you can
do for it. I'm game for some serious programmingi/writing, are you?
/Hampus
--
"Man skall inte glädjas i onödan."
Ken Moore
<kolm...@dtek.chalmers.se> writes
>Sometimes speed is critical but for the most time it's the programmers time
>that counts. Most applications dont need more speed so "haskell is too slow"
>is not a very strong argument.
Do you remember APL enthusiasts pointing out total time to solve a novel
problem as the right measure of the language implementation?
--
Ken Moore
k...@mooremusic.org.uk
Web site: http://www.mooremusic.org.uk/
I reject emails > 300k automatically: warn me beforehand if you want to send one
Ketil Malde
> On Sun, 9 Feb 2003 23:41:15 +0100,
> Sebastian Sylvan <syl...@dtek.chalmers.se> wrote:
>> * Decent compilers.
> Yes, but it's not speed we need. We need less memory usage.
Amen. (Okay, not in all cases, perhaps not in many, but certainly in
my caseน, I need to fit as much data in memory as possible to be
efficient. I'm not sure unboxed arrays count as "foul" though,
they're pretty easy)
> >* Easier to use [...] libraries.
> YES! This _must_ be fixed before Haskell can become widely used.
The hierarchical libraries -- would it be possible to have them
separatley available with CVS or similar? I'd like them to be
separated from the compiler (since I like to be able to use different
ones), and I like to easily inspect and/or modify the code.
The idea is to get more hands and eyes into the code, and to make it
easier to integrate one's own code into the tree. Is this a way to
go?
>>* Tons and tons of example programs.
> Well, start to code... Seriously this is sort of a problem. Those who
> would write these cool example programs don't use haskell since they
> haven't seen any cool haskell programs. Most researchers don't have the
> time to write anything but proof-of-concept.
[...]
> But ask not what the haskell communiy can do for you, but what you can
> do for it. I'm game for some serious programmingi/writing, are you?
Here's my modest contribution: <http://www.ii.uib.no/~ketil/bio/> Enjoy!
-kzm
น EST clustering. Did that help? Thought not. :-)
--
If I haven't seen further, it is by standing in the footprints of giants
pirx
<syl...@dtek.chalmers.se> wrote:
>
> So what do you think is needed for Haskell to be adopted in mainstream
> applications?
>
> My thoughts:
>
>
1. I agree with various aspects raised in this stream: needs for better
IDE, more 'efficiency' (important issues raised by Jerzy Karczmarczuk) etc.
I also believe that the importance of speed is not central - OCAML seems to
be doing very well and it is not a mainstream yet. Pascal and its variants
were very fast (TurboPascal)and had good tools (Delphi) and still did not
became the mainstream. This is not about disagreeing with these points but
about extending them.
2. There is one aspect not raised - ecological niche for the language. A
new language simply needs a reason to be used - an area where nothing else
will do. If we look at the history of languages we can see that each one
that became seriously popular got started in some niche.
LISP - there wasn't much around then with enough flexibility for AI hacking
C - system language for UNIX
Java - applets
Perl - UNIX scripting
3. Two disclaimers though: - a language has to start in a niche, but can
evolve later (Java: applets-> J2EE)
- a niche does not have to be unoccupied, but then the language has to be
significantly 'better': Perl was much more flexible than shell+awk
combination
4. That naturally brings us to my favourite topic: what is a niche for
Haskell (or some other FP)? The question is _not_ what Haskell can do
better than other languages - but in each area Haskell could be so much
better than whatever is available there simply doesn't really count?
5. Additional new problem facing _any_ language nowadays is the
proliferation of the Java _platform_ and associated libraries and tools.
Years ago it was enough to connect a new language to the existing (small)
number of tools (PERL)and be able to write useful programs in some new
language. Nowadays Java platform is really towering above others -
libraries of collections, metadata interface, 3D, database etc mean that
Java will be used even for tasks Haskell would be clearly better (XML
processing) - simply because tools are there, they are callable from Java
and they use Java mindset to do things - so the learning curve is reduced.
--
pirx
Matti Nykanen
> 2. There is one aspect not raised - ecological niche for the
> language.
Now that you did raise this aspect, my understanding is as follows:
If an ecological niche is already occupied by some species (of a
programming language), then a fitter invading species does not
automatically conquer it. It is a random process whose probabilities
favour the newcomer, while the current occupants have safety in
numbers (of established user base).
Survival of the fittest is _not_ a law.
This probabilistic advantage merely ensures that the newcomer tends to
conquer the niche when this "battle game" is played repeatedly. It
does not guarantee victory in the _single_ round which actually takes
place in reality.
> 5. Additional new problem facing _any_ language nowadays is the
> proliferation of the Java _platform_ and associated libraries and
> tools.
So consider Haskell trying to replace Java as a programmer's tool of
choice. Upon learning Haskell the programmer might well like it better
than Java - that is the favourable probability. Whether this
particular programmer becomes a Haskell convert is then one random
event. Whether such random events accumulate to convert the entire
programmer population (where new problems of communication, inertia,
dispersal, etc. appear) is another matter.
--
Matti Nykänen
Sebastian Sylvan
> Another issue is the standard libraries. Why do I have to use ghc if I
> want to use some decent data structures? A map is a map and a set is a
> set, there is no reason what so ever not to make them standard.
Agreed. Standard data structures should be included with every Haskell
distribution. But as I've stated previously I dont believe the standard
library should include anything more specific (HTML-parsing, for
instance).
> >* Tons and tons of example programs.
>
> Well, start to code... Seriously this is sort of a problem. Those who
> would write these cool example programs don't use haskell since they
> haven't seen any cool haskell programs. Most researchers don't have the
> time to write anything but proof-of-concept.
I would write it if I could manage to install some libraries, like HOpenGL
for instance.
> ... and here comes a part of the reason why this matters. Haskell
> becoming mainstream isn't a question of avoiding questions about why
> you're using unknown languages, but of making a better world and
> increasing the number of people that can contribute to the haskell
> community, i.e. making life easier.
>
> But ask not what the haskell communiy can do for you, but what you can
> do for it. I'm game for some serious programmingi/writing, are you?
Sure. It's just hard to get something serious done (as in "cool" that will
attract new users) when I can't get any utilities and libraries to even
install properly.
BTW, thanks for giving me an "excellent" on the Haskell tram-lab =)
(he was a tutor for the introductory Haskell course here at Chalmers)
Hampus Ram
Sebastian Sylvan <syl...@dtek.chalmers.se> wrote:
>But as I've stated previously I dont believe the standard
>library should include anything more specific
Neither do I. C++'s standard library is really something to use as a
model. It includes most stuff that you might need that isn't too
specific. I.e. datastructures and general algorithms such as sorting
algorithms.
>I would write it if I could manage to install some libraries, like HOpenGL
>for instance.
Tried to install HOpenGL just to see how hard it was - needless to say
I didn't succeed...
>attract new users) when I can't get any utilities and libraries to even
>install properly.
Then perhaps you should concentrate on creating installable libraries
for cool stuff, or perhaps contact the authors of the libraries and
helping them remedy the problem. That's another way of contributing to
the community.
(And if you want to create a new cool GUI library for Haskell, mail me,
can't get it out of my head, need to code :))
[OT]
>BTW, thanks for giving me an "excellent" on the Haskell tram-lab =)
Well, one gets the grades one deserves...
[/OT]
Alan Baljeu
> > proliferation of the Java _platform_ and associated libraries and
> > tools.
>
> So consider Haskell trying to replace Java as a programmer's tool of
> choice. Upon learning Haskell the programmer might well like it better
> than Java - that is the favourable probability. Whether this
> particular programmer becomes a Haskell convert is then one random
> event. Whether such random events accumulate to convert the entire
> programmer population (where new problems of communication, inertia,
> dispersal, etc. appear) is another matter.
tasks. That's not the question, though. The question is whether Haskell
is better than Java, within the JVM, at enterprise programming tasks.
The answer is undoubtedly no, even if Haskell can be targetted to JVM.
Why? Because the millions of assorted libraries written for that
platform are geared towards Java style OOP. Haskell would be hard pressed
to access those unless someone developed a good, strong, easy to use
mechanism
to access Java class libraries in Haskell.
Alan
pirx
wrote:
> pirx <pi...@mail.com> writes:
>
>> 2. There is one aspect not raised - ecological niche for the
>> language.
>
> Now that you did raise this aspect, my understanding is as follows:
>
> If an ecological niche is already occupied by some species (of a
> programming language), then a fitter invading species does not
> automatically conquer it. It is a random process whose probabilities
> favour the newcomer, while the current occupants have safety in
> numbers (of established user base).
>
I'm not sure the probabilities favour the newcomer - just the opposite.
WHile the new language may be slightly better, the world is conservative -
there
is less experience with the new language, understanding, materials etc.
> Survival of the fittest is _not_ a law.
>
> This probabilistic advantage merely ensures that the newcomer tends to
> conquer the niche when this "battle game" is played repeatedly. It
> does not guarantee victory in the _single_ round which actually takes
> place in reality.
>
I think that history shows that the more mediocre but versatile species win
- if they were there first. See IBM mainframes in the 60's, COBOL or
FORTRAN and/or [flamesuit on] MS-Windows.
Singler round? Java had several approaches to business market. Not
sure about this one.
>> 5. Additional new problem facing _any_ language nowadays is the
>> proliferation of the Java _platform_ and associated libraries and
>> tools.
>
> So consider Haskell trying to replace Java as a programmer's tool of
> choice. Upon learning Haskell the programmer might well like it better
> than Java - that is the favourable probability. Whether this
> particular programmer becomes a Haskell convert is then one random
> event. Whether such random events accumulate to convert the entire
> programmer population (where new problems of communication, inertia,
> dispersal, etc. appear) is another matter.
>
True. But also: it seems highly unlikely for a Java programmer to ever use
haskell if he'd have to write all the libraries from the scratch...
So the hope will be rather to write some compelling apps in Haskell on top
of some recognized platform - like scripting language for Linux, Java
etc.Or something like that.
--
pirx
Ketil Malde
>> If an ecological niche is already occupied by some species (of a
>> programming language), then a fitter invading species does not
> I'm not sure the probabilities favour the newcomer - just the
Are you sure this is the right analogy? To me, it would seem more
appropriate to say that the languages are the environment, and that it
is the programmers that evolve.
*shrug*
-kzm
Matti Nykanen
> pirx <pi...@mail.com> writes:
>
> >> If an ecological niche is already occupied by some species (of a
> >> programming language), then a fitter invading species does not
>
> > I'm not sure the probabilities favour the newcomer - just the
>
> Are you sure this is the right analogy? To me, it would seem more
> appropriate to say that the languages are the environment, and that it
> is the programmers that evolve.
I meant the situation where the currently living members of two
different species compete on a resource in an environment. In time,
these species do evolve, but individual members don't, whereas the
environment just changes. That is why I considered programmers to be
the resource and languages the competitors, even though the former
live and die in the very real concrete biological sense while the
latter in just a figurative sense.
But true, my model is broken in that it does not differentiate between
individual languages and species. Rats. (Lots of 'em. In a
maze. Developing cancer.)
It is also true that programming languages are a cultural product, and
the "laws" of cultural evoultion may be a bit different. (I would say
"meme" if that wasn't sooo passé...)
Or in Daniel Dennett's words, "A scholar is just a library's way of
breeding more libraries." (And we are all just a newsgroup thread's
way of spawning new threads, I suppose.)
--
Matti Nykänen
Alan Baljeu
> It is also true that programming languages are a cultural product, and
> the "laws" of cultural evoultion may be a bit different. (I would say
> "meme" if that wasn't sooo passé...)
>
> Or in Daniel Dennett's words, "A scholar is just a library's way of
> breeding more libraries." (And we are all just a newsgroup thread's
> way of spawning new threads, I suppose.)
Now you're on the right track. Truth is, this is a "core war" game
on a massively parallel connection machine. Programming languages
are the viruses, programmers are the CPU's and we are connected by
the internet. Languages infect people, who subsequently write
libraries for it, write tutorials, and otherwise enhance the language.
These infected people disseminate their improvements to the language,
and disseminate the newly improved language across the net.
Occasionally some language-viruses interact within a person causing
them to emit an entirely new language which spreads across the net.
The optimum strategy for this game isn't known, but obviously
maximizing effective participation in the improvement effort is a
key factor.
pirx
precisely the way that a new programming language _has_ to take to succeed
nowadays! Unless it targets and is useful on an established platform (like
.NET or Java or LINUX) how otherwise it can became popular? A language
exists to express actions/algorithms better than others. But these actions
nowadays assume (almost 100% of the time) some execution platform. line-in-
line-out approach of the 60's doesn't work any more.
The problem is therefore how to map Haskell goodies on some existing
platform, what things don't map and how to replace them etc.
>
> Alan
>
>
>
>
--
pirx
Damien Sullivan
>On Sun, 9 Feb 2003 23:41:15 +0100,
>Sebastian Sylvan <syl...@dtek.chalmers.se> wrote:
>>* Decent compilers.
>
>Yes, but it's not speed we need. We need less memory usage. You relly
For my commercial and now academic purposes, it's speed *and* memory. I need
both. Speed of the compiler would be nice too, I have to say, but is less
vital.
Efficiency matters, damnit. Unless you're a scripting a language. If you're
trying to take over the world then your competitor is C++. ocaml seems to
have a shot at that, Haskell ha. Unless you abuse ghc's extensions a lot but
then what happened to easier coding?
>>* Easier to use [...] libraries.
And better libraries. I saw stuff on the Haskell mailing list about the time
library being just broken. And ocaml having a standard graphic library is a
draw for me. OTOH, Haskell using GMP rather than something slower has be
using it instead of ocaml for a class project right now.
-xx- Damien X-)
Damien Sullivan
>1. I agree with various aspects raised in this stream: needs for better
>IDE, more 'efficiency' (important issues raised by Jerzy Karczmarczuk) etc.
>I also believe that the importance of speed is not central - OCAML seems to
>be doing very well and it is not a mainstream yet. Pascal and its variants
>were very fast (TurboPascal)and had good tools (Delphi) and still did not
Personally I don't care about IDE; most Unix programmers won't. Efficiency
I'd say is necessary but not sufficient. If you have it network effects can
still shut you out. If you don't have it you're a scripting language, or
doomed. Well, Java's toodling along, but it has massive corporate backing and
hype and a massive standard library, which helps. But I know that Overture
switched from Java to *Perl* because Java was too slow -- and worse,
unpredictably slow due to the garbage collector.
>4. That naturally brings us to my favourite topic: what is a niche for
>Haskell (or some other FP)? The question is _not_ what Haskell can do
>better than other languages - but in each area Haskell could be so much
>better than whatever is available there simply doesn't really count?
My computer theory prof said the promise of FP is for parallel programming
with a lot of divide-and-conquer. Fast programs for single processors is just
too well taken, but parallel is hard. Not that the promise has been delivered
yet, but the niche is still open.
>5. Additional new problem facing _any_ language nowadays is the
>proliferation of the Java _platform_ and associated libraries and tools.
>Years ago it was enough to connect a new language to the existing (small)
>number of tools (PERL)and be able to write useful programs in some new
>language. Nowadays Java platform is really towering above others -
It's not just Java. Perl 5 has a lot of modules, and CPAN. Python in
particular has an excellent-looking (never used it myself) spread of
libraries, well documented from the python web page. Part of ocaml's appeal
for me is the idea that my thesis program can use some graphics and still run
easily anywhere else with ocaml -- unlike its predecessors, tied to unportable
Lisp and Scheme libraries.
-xx- Damien X-)
Joachim Durchholz
>
> Speed of the compiler would be nice too, I have to say, but is less
> vital.
This depends heavily on project size. Once you have six-digit LOC
figures and compilation takes several hours, compilation speed becomes a
central issue. (It's one of the central issues for C++ and Java.)
Ketil Malde
> Damien Sullivan wrote:
>> Speed of the compiler would be nice too, I have to say, but is less
>> vital.
> This depends heavily on project size. Once you have six-digit LOC
Not only that -- even a few minutes (or even seconds) is a pain; to
quote Paul Graham when he wants to describe something horrible:
| It would be like programming in a language without an interactive
| toplevel, and I wouldn't wish that on anyone.
It is often important to be able to work interactively with the
program, and long compile times is a hindrance to that.
On the other hand I don't much care how long 'ghc -O2' takes (as long
as it is finished when I return to work the next morning).
Joachim Durchholz
>
> On the other hand I don't much care how long 'ghc -O2' takes (as long
> as it is finished when I return to work the next morning).
That's exactly the point: for large projects, the compiler may take
longer than until next morning.
Mark Carroll
Joachim Durchholz <joachim....@gmx.de> wrote:
(snip)
>That's exactly the point: for large projects, the compiler may take
>longer than until next morning.
Mmmm. It would be nice if the compilation could conveniently be done
in parallel; we have a lot of spare CPU power around here that all
sees a common filesystem.
-- Mark
Damien Sullivan
>Damien Sullivan wrote:
>>
>> Speed of the compiler would be nice too, I have to say, but is less
>> vital.
>
>This depends heavily on project size. Once you have six-digit LOC
>figures and compilation takes several hours, compilation speed becomes a
>central issue. (It's one of the central issues for C++ and Java.)
IME Java was pretty speedy at compilation, C++ is fast until you bring in
templates. But it's been a while.
And yes, ghc's slow compilation is annoying, especially after experiencing
ocaml's zippiness. But it's livable for now. I imagine with a large project
you'd use a lot of separate compilation, so it'd be very rare you'd have to
rebuild a whole project. Hopefully interfaces are handled better than C's
header files (modify private class data, recompile everything), but I haven't
learned those parts of ocaml/Haskell yet.
-xx- Damien X-)
Ketil Malde
> And yes, ghc's slow compilation is annoying, especially after experiencing
> ocaml's zippiness. But it's livable for now.
As I said (or tried to say), use ghci. Or Hugs, which is even faster
in many cases.
> I imagine with a large project
> you'd use a lot of separate compilation, so it'd be very rare you'd have to
> rebuild a whole project. Hopefully interfaces are handled better than C's
> header files (modify private class data, recompile everything), but I haven't
> learned those parts of ocaml/Haskell yet.
ghc --make seems to work all right for me, but perhaps you could use
GNU make with -j to better exploit SMP, or a distributed make to
exploit a cluster.
The GHC manual has a chapter (4.9) on separate compilation, it may be
worth a look if compilation times bother you.
http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html
Joachim Durchholz
>
> Mmmm. It would be nice if the compilation could conveniently be done
> in parallel; we have a lot of spare CPU power around here that all
> sees a common filesystem.
Good idea... the larger the project (and hence compilation times), the
more CPUs are sitting around and waiting for work.
Unfortunately, it requires a lot of infrastructure. Language support
would be best (and a compiler that's written in a mostly referentially
transparent style would make parallelization easier).
Global analysis would work against parallelization - there are too many
dependencies between far-away code parts. Static typing makes global
analysis more worthwhile.
It might be interesting to have an "optimization-incremental" mode: if
the compiler cannot do all of the analysis during one night, just don't
do all the optimizations. (The optimizations better be rock-solid for
this to be practical: no use in bugs mysteriously vanishing after a
night's recompile because different optimizations were applied.)
Shae Matijs Erisson
> Mmmm. It would be nice if the compilation could conveniently be done
> in parallel; we have a lot of spare CPU power around here that all
> sees a common filesystem.
I know that I can do make -j8 when building GHC and get a marvelous speedup
on my SMP machine. Doesn't that mean that for most projects it's just a matter
of writing the Makefile correctly? Is there more to it than that?
--
Shae Matijs Erisson - 2 days older than RFC0226
#haskell on irc.freenode.net - We Put the Funk in Funktion
10 PRINT "HELLO" 20 GOTO 10 ; mapM_ putStrLn $ hello = "HELLO" : hello
Damien Sullivan
>pho...@ugcs.caltech.edu (Damien Sullivan) writes:
>
>> And yes, ghc's slow compilation is annoying, especially after experiencing
>> ocaml's zippiness. But it's livable for now.
>
>As I said (or tried to say), use ghci. Or Hugs, which is even faster
>in many cases.
I use hugs for typechecking or occasionally testing the values of some
function. I need ghc -O to actually use my program.
>The GHC manual has a chapter (4.9) on separate compilation, it may be
>worth a look if compilation times bother you.
I've only got 150 lines. Using separate compilation is just theoretical at
the moment, I'm not going to use it for this.
-xx- Damien X-)
Oleg
> And yes, ghc's slow compilation is annoying, especially after experiencing
> ocaml's zippiness.
I don't use Haskell, but just out of curiosity: why is GHC slow?
Cheers
Oleg
Costin Cozianu
>>What are the reasons the mainstream hasn't adopted Haskell? I don't think
>>it's because Haskell isn't worthy of adoption by the general public. So
>>what is it?
>
>
> To be honest, I think the advantages of Haskell only become really obvious
> in the hands of a good programmer. (Having made this unsubstantiated and
> rather inflammatory statement, I'm going to back away from it carefully and
> hope that no-one notices.)
>
> mrak
>
Maybe I'm a bad programmer, but how do you write a time and space
efficient QuickSort in Haskell ?
Ken Rose
> Mmmm. It would be nice if the compilation could conveniently be done
> in parallel; we have a lot of spare CPU power around here that all
> sees a common filesystem.
Take a look at http://www.vestasys.org. It's a software configuration
control system that includes, among other things, the ability to
precisely recreate any old build, and also the ability to distribute
work over a network of machines. It was developed at DEC SRC, and is
now open source.
It would take a bit of work by somebody to build a "bridge model", as
they call the compilation rules for a language, but that's really just
once per language.
It seems to me to be the niftiest thing of its sort since "make".
- ken
Joachim Durchholz
>
> Maybe I'm a bad programmer, but how do you write a time and space
> efficient QuickSort in Haskell ?
Maybe I'm just too lazy, but why don't you use library routines for sorting?
Lauri Alanko
> Maybe I'm a bad programmer, but how do you write a time and space
> efficient QuickSort in Haskell ?
The same way as in any other language: you write a destructive in-place
quicksort on an array. Look up STArray.
But I suspect that for most problems some other solution would be more
suitable.
Lauri Alanko
l...@iki.fi
Damien Sullivan
I don't know. A friend says "because it wasn't written to be fast". It can
find errors fairly quickly so I guess it's not the initial compile which is
slow (and Hugs goes quite quickly) but trying to speed up the code, and then
speed it up even more with -O. My best guess is that making lazy code
efficient is hard work, taking a long time for as yet limited results.
-xx- Damien X-)
Mark Carroll
Shae Matijs Erisson <sh...@ScannedInAvian.com> wrote:
>Mark Carroll <ma...@chiark.greenend.org.uk> writes:
>
>> Mmmm. It would be nice if the compilation could conveniently be done
>> in parallel; we have a lot of spare CPU power around here that all
>> sees a common filesystem.
>
>I know that I can do make -j8 when building GHC and get a marvelous speedup
>on my SMP machine. Doesn't that mean that for most projects it's just a matter
>of writing the Makefile correctly? Is there more to it than that?
It turns out that there was a bug in GHC that was slowing it down a
lot on our code, that has now been fixed. Thanks, yet again, to the
GHC team!
-- Mark
Raja R Harinath
Lauri Alanko <l...@iki.fi> writes:
> Costin Cozianu <c_co...@hotmail.com> quoth:
>> Maybe I'm a bad programmer, but how do you write a time and space
>> efficient QuickSort in Haskell ?
If you want a time and space efficient Sort, that is not necessarily
QuickSort, then it's easy.
> The same way as in any other language: you write a destructive in-place
> quicksort on an array. Look up STArray.
But why? You can write a perfectly good 'partition' that works on a
list.
Of course, if you have a list, a mergesort is much better. Unlike an
array mergesort, you don't need extra space. And, you get an O(n log
n) bound.
- Hari
--
Raja R Harinath ------------------------------ hari...@cs.umn.edu
Elveto
> There are already a ton of scripting languages that have many specific
> libraries, (e.g. Python, Ruby) we don't need another one.
> There are, however, not as many truly high-level general purpose languages
> (like C# and C++, only higher level).
:) please define your metric.
Sebastian Sylvan
=)
Uhm... Time-to-market? Lackof resemblence with machine code?
--
----------------------------------------
| Sebastian Sylvan |
| ICQ: 44640862 |
| Tel: 073-6818655 / 031-812 817 |
| |
| |
| Hard Work Often Pays Off After Time |
| But Laziness Always Pays Off Now! |
----------------------------------------