what are the advantages of haskell over semi-functional programming languages
such as Perl, Common Lisp, etc.?
What are the mysterious "side effects" which are avoided by using Haskell, which
everyone talks about? Null pointers?
Don't you ever get null pointers in Haskell, including when doing IO?
Aren't Haskell's advantages outweighed by its complexity (Monads, etc.) and
rigidity?
Last but not least, I would like to learn from those among you who are former
PERL developers, why you switched to Haskell.
Many thanks.
phiroc
_______________________________________________
Haskell mailing list
Has...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
> [...] semi-functional programming languages such as Perl [...]
now this is an interesting view ...
For one reason or another Haskell never turns out to be my final
implementation language my my programs gain in the process.
Joel
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On 4/26/07, phi...@free.fr <phi...@free.fr> wrote:
We'll do this one first:
What are the mysterious "side effects" which are avoided by using Haskell,
which
everyone talks about? Null pointers?
Side effects are usually things like mutable state. In Haskell variables
don't vary. "x=x+1" isn't valid in Haskell. This means, among other things,
that functions always do the same thing given the same input (they can't
depend on some mutable state changing value), which is great since you'll
never get those "oh I forgot that I must first call foo before I call bar,
or I'll get an error". This really is a HUGE win, since programming with
state is unreasonably error-prone. I'm afraid it's next to impossible to
convince anyone that this is true, unless they're willing to give it a
serious try, though :-)
Null pointers are possible when you're dealing with C functions mostly. You
don't use pointers in Haskell normally, only when you're interfacing with
external C libraries etc.
Hello,
>
> what are the advantages of haskell over semi-functional programming
> languages
> such as Perl, Common Lisp, etc.?
For me? Purity. I mean you can get plenty of the benefits of FP in any old
language (witness C# 3.0), but the one thing you can never get by just
adding support for a "functional style" in another language is purity. Once
purity is gone, it's gone! It can't be retrofitted on an existing language.
Purity is great because it makes it much easier to write programs without
making silly mistakes. When writing programs in languages with lots of side
effects you have to sort of keep a "mental log" in your head for all
possible execution paths ("in this branch x is equal to y plus w, and this
pointer here is null in the other branch x is null and..."). For me I can
quite literally *feel* "brain resources" being freed up when using Haskell,
which I can use to get stuff done quicker (or probably more accurate: I can
feel how much brainpower I waste on book keeping and keeping track of this
"mental log" when using languages like C++).
Also purity is very interesting when you want to paralellize programs (a
pure function can be executed on any thread, at any time, and its guaranteed
to never interfer with the computation of other functions -- in impure
languages this doesn't hold at all!). This is probably the killer app for
functional programming IMO. FP is cool for a number of reasons, but I think
"isn't almost unusable in a multithreaded setting" is what sets it apart the
most from imperative languages.
Haskell also has STM which is great for that low level shared state
concurrency that you sometimes need (no locks, monitors, or any of that
non-composable, insanity-inducing, messiness!)
> Aren't Haskell's advantages outweighed by its complexity (Monads, etc.)
> and
> rigidity?
I can sometimes feel that Haskell looses out on not being user friendly in
the Java sense (i.e. "cut out any feature that can't be understood in five
minutes by a chimp"). Some things do take some effort to learn, but there is
a huge payoff for it (it's really powerful!). But yeah, there might be
plenty of folks who will never bother learning about them, and they won't
understand your code.
--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
There are plenty of advantages to Haskell; but it doesn't mean that
it's the only language I use now. I read an article about Perl vs.
Python once, and the point that stuck with me most was "The Perl motto
is TMTOWTDI, and Python's just another WTDI." The same applies to
Haskell, or any other language for that matter. I love Haskell; my
code is usually bug-free (or close) the first time I run it because of
its features like having no side effects. But I still use Perl for
system administration, and I'm developing a window manager in Scheme
now because of its features.
As far as Haskell's disadvantages, I don't see monads as a
disadvantage; most descriptions of them are complicated, but there are
plenty of good tutorials out there. Rigidity is a double edged sword;
it helps keep your code working, but it does make you jump through some
hoops to get certain things working.
-Rob Hoelz
I'm new to these ideas too--especially since my college math training
is non-existent. I found the following wikipedia articles
particularly illuminating on the topic of side-effects:
http://en.wikipedia.org/wiki/Side_effect_%28computer_science%29
and
http://en.wikipedia.org/wiki/Referential_transparency
FP is a completely different way of thinking about solving a problem
than is generally used in imperative programming. It's a lot more
like math (see Alonso Church, Lambda Calculus, and Haskell Curry,
after which Haskell is named and the process called "Currying," ->
another great wikipedia read: http://en.wikipedia.org/wiki/Currying
where some of the real power of FP comes from).
The main advantage to solving the problems in this way is that you can
be more sure (like mathematical proof kind of sure) that your program
does what it's intended to do.
As far as language vs language discussion, I say get a book, or look
on the net for a tutorial (try haskell.org for starters) and try it
out and see if it works for you. That's what I'm doing. It's fun!
But, use the right tool for the job, of course, as Rob pointed out.
Cheers,
Mike (FP Ultra-Noob)
> _______________________________________________
> Haskell mailing list
> Has...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>
--
http://clembie.livejournal.com
http://shadowofaculture.blogspot.com
http://deadlylittlepills.com
Hi Welcome to the mailing list.
Problem with partially functional languages in my opinion is if you can
do things the way that your most use i.e. imperative programming you
will do it
Perl, Python, Lisp, Scheme and etc have features that support functional
programming but I would wager that you will find more imperative code
written in those languages then you would functional code. People tend
to do things in the way there most accustom too and most developers are
educated in and work in imperative languages so if you really want to do
FP then your better to stick to a language that doesn't support other
more familiar paradigms otherwise you will find yourself falling back on
more comfortable and familiar ways of doing things.
Side effects include I/O, mutable assignment (destructively writing to
memory), generating random numbers etc.
Haskell of course has to allow these things otherwise it could not
produce useful programs it just does a lot better job of isolating these
side effects from Code
that does not have these side effects which have many benefits first
most being the ability to compose/glue code together in all sorts of
neat ways and not having to worry about unintentional side effects.
Advantage of Haskell over most other languages would be the core
language itself and its ability to glue software components together in
a safe way. This
advantage doesn't come without some pain and learning curve though.
Haskell is also a great language to learn new ideas and ways of thinking
about building software this is my interest in this language at this
time.
Haskell is a good place to start if you are looking to write something
from scratch
Unfortunately this is not my case.
Disadvantages of Haskell are unfortunately greater then its advantages
as beautiful a programming language as Haskell is it lacks Libraries ( A
great glue language without many components to glue together is a sad
irony) and Tooling
Haskell is not a language to get stuff done quickly in. I will probably
use Monads in a real world project in VB.NET 9 before Haskell.
I am not a Perl fan but CPAN is very cool when I have had to do
something in Perl I could find what I need there and it was well
documented too.
Haskell to me is the promise of a dream yet unrealized in which you
easily glue together components together and it just works maybe one day
these components will actually get written.
Troy
For the record, you're probably thinking of Higher-Order Perl, by Mark Jason
Dominus.
HTH,
Keith
http://www.amazon.com/Higher-Order-Perl-Transforming-Programs/dp/1558607013
I think the other kind of null pointers are more important.
If you call a method
MyObject getObjectFromStrings(String s1, String st)
in java, you may have to check both your strings - they may be null, and
subsequent logic may call string methods on them, which would raise an
exception.
Also, the method may return null, and you may have to handle this with
an if-statement.
MyObject theObject = getObjectFromStrings(first, second);
if (theObject != null) {useObject(myObject);}
In Haskell, you would have a function
getObjectFromStrings::String->String->MyObject
This can not be called with any other types than strings - the type
system will not allow it. If you need to express the idea of maybe
receiving a worthless value, you need to use the type Maybe, like this:
getObjectFromStrings::Maybe String->Maybe String->Maybe MyObject
and you would use pattern matching to implement the two possibilities of
a Maybe: Nothing and Just value.
getObjectFromStrings Nothing Nothing = Nothing
getObjectFromStrings (Just firstString) (Just otherString) = (Just (
MyObject { f= firstString.....
For most programming, the obligatory checking of possible null values
just disappears.
Arne
Mark Dominus has a blog that people on this list might enjoy
http://blog.plover.com/
He writes a lot about math and programming, which are favorite topics on
this list.
________________________________
Admittedly, this is phrased in an inflammatory manner, however, the
original sentiment is actually pointing out an advantage of Java over
Haskell. Here is the original paragraph in context:
Sebastian Sylvan wrote:
> I can sometimes feel that Haskell looses out on not being user friendly
> in the Java sense (i.e. "cut out any feature that can't be understood in
> five minutes by a chimp"). Some things do take some effort to learn, but
> there is a huge payoff for it (it's really powerful!). But yeah, there
> might be plenty of folks who will never bother learning about them, and
> they won't understand your code.
IOW: Java's advanced features are separable from its basic features.
I.e. you can teach Java without teaching generics or anonymous inner
classes. In Haskell, OTOH, you can't even learn how to do IO without
learning Monads, or at least glossing over oddities like a new syntax.
And thats not even getting into issues like statelessness and lazy
evaluation.
So for a new user, Java is the better language. You can get into its
features slowly and as you see the need for them. Haskell requires you
to learn a number of mind-bending concepts right up front. Java has a
gentle learning curve and Haskell has a vertical jump.
But, Sebastian is right. The leap is worth it. Its the same as what
someone once said about LISP: even if you never get to use Haskell
regularly, you will be a better programmer when you finally "get it".
> IOW: Java's advanced features are separable from its basic features.
> I.e. you can teach Java without teaching generics or anonymous inner
> classes. In Haskell, OTOH, you can't even learn how to do IO without
> learning Monads, or at least glossing over oddities like a new syntax.
> And thats not even getting into issues like statelessness and lazy
> evaluation.
As for Java, this is not quite true. In Java, you cannot write a “Hello
world!” program without stumbling over classes and static methods. And if
you start using I/O, you will soon have to deal with rather complex class and
object structures. (At least this used to be the case.)
> […]
Best wishes,
Wolfgang
but you shouldn't -
if you can teach the type-correct use of arrays (it's done for decades),
then you can teach generic collections (at least their proper usage),
and what's the problem with the anonymous class in
x.addActionListener(new ActionListener(){ void actionPerformed(..){..}});
back to the original question (see subject): one advantage that gets
easily overlooked
is lazy evaluation, leading to better modularization, because you can
decouple
object (stream) generation from transformation from consumption,
and still be space efficient. with eager evaluation this would require
jumping through many hoops,
destroying the logical structure of the program.
and once you're lazy, then it's mandatory to be pure.
Cf. one of the classical (1984!) answers to the "advantages" question:
John Hughes: why functional programming matters,
http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
Best regards, J.W.
This not the first inflammatory comment he has made
>>But, Sebastian is right.
Sebastian will be right when I see Chimpanzees coding in Java :)
>> The leap is worth it.
I am not so sure it was for me.
I guess It depends on what you are looking for I have spent the last
year learning Haskell and I have learned some very interesting concepts.
I can't help but wish that Haskell turned out to be a more practical
language for me to code something useful in every time I looked for
Haskell libraries I was a disappointed.
I can't help feeling that last year might have been better
spent learning Erlang (which is this years language for me to learn).
I really enjoy Functional programming (at least until I try to do
something serious then frustration sets in). I can't produce software in
a timely and cost effective fashion without a large body of high
quality, documented and maintained libraries.
I get the feeling that Haskell is for researchers to explore ideas about
programming in but no one is interested in doing The grind work of
cranking out useful basic libraries.
I guess you need borrow some of those Java Chimps :).
Am I the only person on the list that feels this way ?
I guess I am feeling a bit bitter of spending so much time on Haskell
and having so little to show for it.
Troy
-----Original Message-----
From: haskell...@haskell.org [mailto:haskell...@haskell.org]
As a Java chimp embarking on the Haskell journey myself, I'd be
interested in hearing about specific ways that learning Haskell has
changed the way you program Java. How do you employ the "very
interesting concepts" that you have learned through your study of
Haskell in your Java programming? Do you employ them at all? _Can_
they be employed in Java? Has it made you a better Java programmer?
Cheers,
Mike
I reinvented functional programming when I was using Java rather than
Haskell making me use Java more succintly. I knew something was
seriously wrong with imperative programming and Java's type system all
those years I spent working on the implementation for IBM. I was pleased
to learn that Haskell incorporated many of my ideas (and more) -
validating my original suspicions. The fact that many of the concepts in
Haskell I had already "invented" made the language easy for me to learn
(as in, "oh yeah of course that makes perfect sense" in response to
discover monads).
I produced many Java projects in an attempt to demonstrate what I
thought was wrong, but few of them remain due to loss of interest.
http://jtiger.org/
http://code.google.com/p/pure-functional-java/
In regard to the original question, 'What are the mysterious "side
effects" which are avoided by using Haskell, which everyone talks about?
Null pointers?', my response is "yes".
Looking at a NullPointerException (NPE), these exist because of the
imperative nature of the code; with explicit order of evaluation and
potential side-effects. In an attempt to highlight the absurdity of the
fact that a NPE even exists, I like to tell people that "NPEs occur when
you write a program that says, 'give me the something that is not there
yet'". Now, if you have read Stephen Hawking's Brief History of Time and
the chapter titled, Arrow of Time, you will know that "the arrow of time
will not reverse". How absurd it is to suggest otherwise by imperative
programmers! Simply, a programming language that allows an expression of
"give me the non-existent something" contains a logical absurdity.
let p(something) = something exists
let q(something) = something is non-existent
let r = p ? 段
let s = p ? q
therefore r
therefore s
but r ? 毗 !!
I have long considered (well before I knew about Haskell) formulating a
more concrete proof that imperative programming contains many logical
absurdities.
Remember, forall software. software is based on the lambda calculus. I
believe that you can prove this.
Tony Morris
http://tmorris.net/
[cut]
And then you come to Haskell and you -can- say, "Give me the something that is
not there yet."
It has affected my Java/C/C++ programming a lot.
1. I am much more careful how I combine ( inherit, compose, aggregate )
code because of potential side affects
2. It has helped to find certain types of bugs in Java code more easily
that come up because of subtle effects introduced by combining code
together
3. It has helped me to write code that is more composable
4. Haskell has increased my awareness of how important type safety is So
I use Java Generics more now to enforce more type safety when I can
(sometimes I am stuck deploying to java 1.4) (I also use C++ templates
to do the same thing for C++) But these are often feel like hacks
Haskell's type system is a thing of pure beauty haven't seen anything
quite like it in any other PL (ML and OCAML are as close as I have seen
but still fall short) and Generics and Templates really can't compare
You really want the compiler to help you out as much it can. Have it
tell you when you are doing something that you shouldn't be doing.
By the way Mike thanks you just totally cheered me up I guess I just
needed to sit back and think about what I have learned and how valuable
it is to me.
Troy
-----Original Message-----
From: haskell...@haskell.org [mailto:haskell...@haskell.org]
On Behalf Of mike clemow
Sent: Friday, April 27, 2007 4:16 PM
To: has...@haskell.org
Subject: Re: [Haskell] Re: Newbie: what are the advantages of Haskell?
Troy,
As a Java chimp embarking on the Haskell journey myself, I'd be
interested in hearing about specific ways that learning Haskell has
changed the way you program Java. How do you employ the "very
interesting concepts" that you have learned through your study of
Haskell in your Java programming? Do you employ them at all? _Can_
they be employed in Java? Has it made you a better Java programmer?
Cheers,
Mike
On 4/27/07, Taillefer, Troy (EXP) <troy.ta...@lmco.com> wrote:
> _______________________________________________
> Haskell mailing list
> Has...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
> _______________________________________________
> Haskell mailing list
> Has...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
Please give me the libraries that are not there yet! *duck*
We wait for people to need the libraries, then a large amount of delayed work is
forced.
Al Falloon wrote:
> Taillefer, Troy (EXP) wrote:
>> Java sense (i.e. "cut out any feature that can't be understood in five
>> minutes by a chimp")
>>
>> Got to love comments like this they are constructive, objective,
>> mature and accurate.
>>
>> Glad we have your expert opinion to give us the gospel.
>>
>> Can I get an amen? How about a Hallelujah ?
>
> Admittedly, this is phrased in an inflammatory manner, however, the
> original sentiment is actually pointing out an advantage of Java over
> Haskell. Here is the original paragraph in context:
>
> Sebastian Sylvan wrote:
>> I can sometimes feel that Haskell looses out on not being user
>> friendly in the Java sense (i.e. "cut out any feature that can't be
>> understood in five minutes by a chimp"). Some things do take some
>> effort to learn, but there is a huge payoff for it (it's really
>> powerful!). But yeah, there might be plenty of folks who will never
>> bother learning about them, and they won't understand your code.
>
> IOW: Java's advanced features are separable from its basic features.
> I.e. you can teach Java without teaching generics or anonymous inner
> classes. In Haskell, OTOH, you can't even learn how to do IO without
> learning Monads, or at least glossing over oddities like a new syntax.
> And thats not even getting into issues like statelessness and lazy
> evaluation.
however, you cannot even print a message without learning a few things
about classes. C++ is even worse in this aspect though, using both
classes and operator overloading for a hello world. I think the haskell
first learning step is quite acceptable if you manage to get the syntax
right (beginners tend to mess up indentation rules for do etc)
>
> So for a new user, Java is the better language. You can get into its
> features slowly and as you see the need for them. Haskell requires you
> to learn a number of mind-bending concepts right up front. Java has a
> gentle learning curve and Haskell has a vertical jump.
>
> But, Sebastian is right. The leap is worth it. Its the same as what
> someone once said about LISP: even if you never get to use Haskell
> regularly, you will be a better programmer when you finally "get it".
>
> _______________________________________________
> Haskell mailing list
> Has...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
- --
- --
- ------------------------------------------------
Johan Henriksson aka Mahogny aka Stålis
mah...@areta.org / jo...@student.chalmers.se /
johan.he...@biosci.ki.se
MSc Engineering
PhD student, Karolinska Institutet
http://www.areta.org
http://www.mtek.chalmers.se/~johen/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGMnr9TMgAX9vPlc4RAhqNAJ9lKF+nlEvLJ/vWcQcOSitV1ffnLwCfYl5T
tpNKzvDIN+S7XW3ifAl5Ik8=
=UvYY
-----END PGP SIGNATURE-----
> I really enjoy Functional programming (at least until I try to do
> something serious then frustration sets in). I can't produce software in
> a timely and cost effective fashion without a large body of high
> quality, documented and maintained libraries.
>
> I get the feeling that Haskell is for researchers to explore ideas about
> programming in but no one is interested in doing The grind work of
> cranking out useful basic libraries.
> I guess you need borrow some of those Java Chimps :).
>
> Am I the only person on the list that feels this way ?
No. You're not. I wish I knew the language better so I could start
working on those libraries. I love the language, but can't use it.
--
Michael T. Richter <ttmri...@gmail.com> (GoogleTalk:
ttmri...@gmail.com)
Never, ever, ever let systems-level engineers do human interaction
design unless they have displayed a proven secondary talent in that
area. Their opinion of what represents good human-computer interaction
tends to be a bit off-track. (Bruce Tognazzini)
This is why we have:
* hackage.haskell.org, a centralised library repository, with
documentation and src. note that around 15 new libs are appearing
each week!
* libr...@haskell.org, for discussing improvements and extensions
* haskell.org/cabal, to ease building new libraries
Feel free to help out!
-- Don
I am also a newbie to Haskell, but I also must confess having a sort of
religious conversion. I also admit that the learning curve for Haskell, and
in particular associated theory is steep, and I am only on the fist rung of
the ladder. Some of what I say here has been echoed by others in answer to
your query on the utility of Haskell.
I think most would agree that a language, be it natural or artificial,
constrains or enhances they way you think, and perhaps even what you can
think, and what you can create. Historically many technical problems remained
intractable until the invention of the right language, the language of
classical algebra, or the differential calculus I think are good common
examples. Who would argue that Italian is a great language for operas?
I find even at the elementary level, many common algorithms seem to me
naturally obvious when expressed in Haskell. Other have also pointed out that
the category theory constructs that allow Haskell to remain a purely
functional language, allow you to bring in 'the heavy guns' of standard
mathematical reasoning. With out discussing what proof is really all about,
it very powerful if that concept can be imported into the art of programming.
I also think that the relationship between parallel computing and functional
languages will become very important in to following decades as we hit
'Moore's wall'.
Now for my real truth, it is just down right great fun, hacking at its best.
If asked for a one line description on what Haskell is I would say that it is
'Lisp on steroids'. Paul Graham has plenty to say about the utility and
elegance of Lisp, I would like to know what he thinks of Haskell. I am going
to paraphrase Graham: 'If a lot of really smart people are using something,
and you can't see why, maybe its worth your time to see if you can see what
they see'. Just to give you an idea of where I am coming from I started out
putting food on the table in the 70's writing PDP 11 assembler programmes.
Suppose you don't even use Haskell in a project directly, maybe you develop
your programme 'conceptually' in Haskell, and write it in whatever makes
practical sense in your environment and market. You may end up with an
artfully designed set of code, that is easier to maintain, with clear
abstraction barriers.
In assaulting the learning curve I have found that I am building up a
collection of texts, papers, blog postings, etc. If I don't understand one
source, maybe another will give me some insight. I will just mention one of
the many reference that I have found useful: 'Functional Programming -
Practice and Theory' By Bruce J. MacLennan (ISBN 0-201-13744-5). Oh, and of
course the classic, 'Structure and Interpretation of Computer Programs' by
Ableson and Sussman. Neither is an 'Hakell' book, but I have found them
hyper-useful for practical foundational material.
I would be interested to know what materials you are using to learn Haskell,
and am glad to see that I am not the only 'newbie' :-)
Best Regards,
Robert Emerson
P.S. I didn't even mention Domain Specific Embedded Languages! Big time
advantage.
There had to be some reason you were still hanging around on this list. ;-)
I think that one can make a really good case for learning Haskell on
the basis that knowing how to program in Haskell will make you a
better programmer in any language. There's some recognition about
that regarding functional programming in business; I know Jane St.
Capital only hires programmers with FP experience and uses Ocaml on
the inside because they know that programmers who can program in these
languages produce good code.
I'm glad to hear that your experience with Haskell has made you a
better Java programmer and it cheers me up to think that there's
something inherently beneficial to learning the language per se, even
if there aren't a lot of libraries to make it as productive as other
languages _yet_.
Cheers,
Mike
Which ones? "those libraries" cannot come into existence until someone
says what's actually missing. (The bulk of CPAN is crap and is
certainly not worth being reimplemented.)
-Udo
--
"Object-oriented programming is an exceptionally bad idea which could
only have originated in California." -- E. W. Dijkstra
HTTP. We also need better availability of libraries, and a more
standard and reliable way to install them and specify their
dependencies. We could also do with a good debugger. These are being
addressed by the Google Summer of Code project.
In addition we could do will a million bindings to every obscure
library out there - libtiff and fftw have both come up in the last
week - and each one will be critical to a small number of users.
Thanks
Neil
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGMyqXc1ZCC9bsOpURAq6FAJ0birdTJgMzY8Tv6ccSZ/6F882y3gCfTdVy
> d0eJ8h41z1vwKwDPiZ8S9J4=
> =79EF
> -----END PGP SIGNATURE-----
A fundamental building block that is superior in maintainability and
reusability to objects and procedures, a type system that is actually of
help and not a hindrance, and mathematical purity.
> What are the mysterious "side effects" which are avoided by using Haskell, which
> everyone talks about? Null pointers?
Side effects are changes made to the environment by a procedure (beyond
returning its result), particularly those that you forgot about, that
get executed in the wrong order, and that change values under your feet
when you least expect it.
> Don't you ever get null pointers in Haskell, including when doing IO?
What's a pointer? But we do get bottoms sometimes (rarely, the type
system often prevents you from stumbling over them), which is simply the
price you have to pay if you want a Turing-complete system.
> Aren't Haskell's advantages outweighed by its complexity (Monads, etc.) and
> rigidity?
You know about Design Patterns? *Those* are complex. Dozens of
Rube-Goldberg-Machines designed to circumvent inadequacies in languages
that should have been abandoned 20 years ago.
If you try to apply the Design Patterns book to Haskell, half of the
patterns vanish, because they solve non-problems, most of the rest
becomes much simpler and only a few are added. One particularly simple
new pattern is the Monad, which the gang of four couldn't discover for
lack of a language powerful enough to express it. (Monad easily
subsumes Composite, generalizing and simplifying it in the process. The
application of Monad to IO is straight forward, and then Monad also
subsumes Command.)
Btw, there's nothing rigid about Haskell. I can adapt my Haskell code
much quicker to new requirements than is possible with either C or Perl,
and the Haskell code has the added benefit of still working after the
change.
> Last but not least, I would like to learn from those among you who are former
> PERL developers, why you switched to Haskell.
Because Perl is a royal PITA and Haskell is not. Haskell also has no
inclination to yell "ARRAY(0xdeadbeef)" or "no method 5 in package
FooImpl" at me instead of producing sensible output (see also: type
system).
-Udo
--
I can ALWAYS build faster code if it doesn't have to work. (unknown source)
Hi Neil, a good debugger ? What is in Google Summer of Code about it ?
I just found it:
http://hackage.haskell.org/trac/summer-of-code/ticket/6
that havent student related.
I was studing about debuging techs for haskell to build a nice
debugging enviorment in HIDE or some other IDE. It's my bacharelor
final work.
I and my teacher are thoughting about trying "observes" in a transparent way.
The user click and point to in a source local... but the observes dont
appear in the code. We will try integrate another technique from HAT
in this imaginary (still)debugging interface.
If you or some other has suggestions to me, please.
Rafael
The Haskell-cafe mailing list is designed for precisely the kind of discussion in the current thread. But Has...@haskell.org is a low-bandwidth mailing list for announcements and the like.
Thanks
Simon
> Hi Neil, a good debugger ? What is in Google Summer of Code about it ?
Updating Hat, www.haskell.org/hat - see
http://code.google.com/soc/haskell/about.html
> I was studing about debuging techs for haskell to build a nice
> debugging enviorment in HIDE or some other IDE. It's my bacharelor
> final work.
>
> I and my teacher are thoughting about trying "observes" in a transparent way.
> The user click and point to in a source local... but the observes dont
> appear in the code. We will try integrate another technique from HAT
> in this imaginary (still)debugging interface.
You probably want to check out the GHCi debugger (in GHC head), and
GuiHat [http://www-users.cs.york.ac.uk/~ndm/hat/]
Thanks
Neil
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
We're building some debugging features into GHCi. This started with Pepe
Iborra's Summer of Code project last year, and more recently Bernie Pope
reworked the breakpoint support during his internship here at MSR Cambridge. We
are actively working on polishing what we have for inclusion in the next major
GHC release.
The GHCi debugger is based on imperative debugging techniques: breakpoints,
single stepping, etc. It's a live debugger rather than post-mortem. We
focussed on accessibilty, rather than functionality: so the debugger is always
on, and it works with everything that you can compile in GHCi. It lacks some of
the advanced debugging features you'll find in Hat, for example, but we hope it
makes up for that by being more broadly accessible.
More information on the debugger is here:
http://hackage.haskell.org/trac/ghc/wiki/NewGhciDebugger
although note that development is ongoing and more features have been added
since the wiki was last updated.
All the debugging functionality is exposed by the GHC API, so it's certainly
possible to build debugging support into an IDE based on GHC.
Cheers,
Simon
A lot of thanks Neil and Simon.
I am cross posted/migrated this to Haskell-cafe per Simons request
sorry for the late response I don't check this email on weekends
I really dislike Perl as a programming language but I have to strongly
disagree about your statements about CPAN and the quality of its
contents.
I have worked professional in Perl (Feel free to feel sorry for me) for
over a year
and I have always been impressed with what I could find in CPAN.
Perl obviously has a niche and is "well supported by its community".
Perl is popular so it must have some merit. I don't subscribe to the
flawed reasoning that Perl Hackers just don't know any better or that
they are dumb, or intellectual inferior in some way. Programmers have
very good and valid reason for choosing their tools and I will have
words for those who irrational state otherwise especially in a
belittling manner I am pro choice.
I am going to borrow some Ebonics
"Don't language Hate Appreciate"
Troy
-----Original Message-----
From: haskell...@haskell.org [mailto:haskell...@haskell.org]
On Behalf Of Udo Stenzel
Sent: Saturday, April 28, 2007 7:06 AM
To: has...@haskell.org
Subject: Re: [Haskell] Re: Newbie: what are the advantages of Haskell?