Henning Thielemann wrote:
Productivity, robustness, maintainability: purity, type system,
etc. Parallelism!
'type system' is something where C derivatives and scripting languages
are weak - but their users count this as advantage.
Rarely (maybe in the 70's but not since C89). They count as an advantage
simplicity, portability and efficiency. If you can provide a better type
system to C while keeping these points, you are welcome. Still, it is
easy to make your code strongly typed in C with some discipline.
I want to raise the
question again, whether it is reasonable to move convinced C and Perl
programmers to Haskell - They will want to write C and Perl style
programs using Haskell.
Not necessary. I am coming from C/C++ and I use Haskell for what I like
it, that is functional programming.
I think it is better to attract the people who
find 'filter' and 'map' good in Python and want to get to know the
original language.
filter and map exist also in non functional languages. lambda and
composition are much more uncommon outside the FPL world and much more
difficult to 'emulate'.
On Thu, 4 Oct 2007, Don Stewart wrote:
Yep, its similar to the elevator pitch, but a little shorter, and
mentions why as a programmer this is worth your time.
I'm not sure "monadic effects" is terribly motivating for someone who's
heard about Haskell, and just wants to get things done faster, and more
reliably -- which is really what Haskell can be about.
My experience is, that 'purely functional' made me curious because I
wanted a nice, elegant language which is not cluttered with much
patches. 'Monadic effects' sounded strange and made me even more curious.
Exactly the same for me but I prefer arrows to monads ;-) BTW, I do not
understand why Arrow does not have a delay operator which would store
its input and return its previous input. This would be quite helpful to
describe signal processing and control system with SF (this question
came to mind while reading the draft of H.Liu and P.Hudak on space leaks).
What bother me about Haskell is that unfortunately I cannot use it in my
work (numerical analysis) because of its lack of _efficiency_ and to a
lesser extend of stability and portability. Despite that I am pretty
sure that it will be solved in some future.
a+, ld.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
