Haskell?

1757 views
Skip to first unread message

Jared

unread,
Jul 19, 2010, 7:34:14 PM7/19/10
to Clojure
I am curious; for the people with Haskell experience why did you
decide to use Clojure? I am asking this because Haskell and Clojure
seem to solve similar types of problems. When would you want to use
Haskell instead of Clojure and visa-versa?

Raoul Duke

unread,
Jul 19, 2010, 9:04:10 PM7/19/10
to clo...@googlegroups.com

or, how about CAL?

Wilson MacGyver

unread,
Jul 19, 2010, 9:31:11 PM7/19/10
to clo...@googlegroups.com
1 word. JVM.

the amount of java libs to be tapped is amazing. My experience with
haskell libs has been mixed bag.

In the case of clojure, XML parsing, database connection,
kicking up a web server, natural language parsing.
"There is a Jar for that"

OTH, there are situations where we can't use JVM. This is
where we fall back to other languages/runtime. Sometimes
it's haskell, sometimes it's c/c++, sometimes it's objective-c.

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

--
Omnem crede diem tibi diluxisse supremum.

Mark Engelberg

unread,
Jul 19, 2010, 10:20:13 PM7/19/10
to clo...@googlegroups.com

I think stateful things are too hard to do in Haskell, and they are an
important part of most real-world programs. Clojure's blend of
persistent data structures with a variety of reference-type objects
that can contain them feels much more pragmatic to me. Also, I'm just
happier working in a dynamically-typed language.

As a side note, years ago, I wanted to write something in Haskell that
worked like Clojure's memoize (which is implemented in a half-dozen or
so lines of code in Clojure's core), and asked about it on the Haskell
mailing list. I was pointed to a PhD dissertation on the topic of how
to write memoize in Haskell. All I could think was, "Do I really want
to be using a language where memoize is a PhD-level topic?"

Sean Corfield

unread,
Jul 19, 2010, 10:28:44 PM7/19/10
to clo...@googlegroups.com
On Mon, Jul 19, 2010 at 4:34 PM, Jared <tri...@gmail.com> wrote:

The JVM. So I can mix'n'match Clojure into applications that I already
build on the JVM with several other languages.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

Rayne

unread,
Jul 19, 2010, 11:47:58 PM7/19/10
to Clojure
Because monads make me cry, and I like the JVM.

Laurent PETIT

unread,
Jul 20, 2010, 1:44:58 AM7/20/10
to clo...@googlegroups.com


2010/7/20 Laurent PETIT <lauren...@gmail.com>
Because I saw Haskell as a good language to shape my mind, and then I found Clojure a

... and then I found Clojure, a good language to shape my mind, have things done, and (eventually I hope), help pay the bills.
(yeah, the short answer is "JVM" ;-) )

... wait .., that's unfair: I also find Clojure more pragmatic in certain areas ( "there's a story for mutation")
 

2010/7/20 Jared <tri...@gmail.com>

Nicolas Oury

unread,
Jul 20, 2010, 4:07:26 AM7/20/10
to clo...@googlegroups.com
I have used Haskell as a main language 7 or 8 years.

I changed for (in no particular order):
1. macros and all the lispy meta things.
2. Clojure classification of stateful things
3. JVM, but with enough independance 
4. A part of my research is on type systems more souple than ML's or Haskell's. The program in my mind can't be typed in Haskell.
  Waiting for the perfect static type system, as expressive as a dynamic one, I'd rather use a dynamic type system.
5. Haskell makes it difficult to have the write something and refactor until its perfect. You have to think it perfect and then write it.
This is fun too, but difficult depending on what you do.

Chas Emerick

unread,
Jul 20, 2010, 7:19:38 AM7/20/10
to clo...@googlegroups.com
Nicolas, just out of curiosity, what program (or class of program(s))
are you interested in that "can't be typed in Haskell"? I'm always
interested in seeing examples of static typing preventing the
implementation of certain classes of programs, insofar as such things
are an antidote to my tidal fascination with statically-typed languages.

- Chas

LordGeoffrey

unread,
Jul 19, 2010, 9:40:46 PM7/19/10
to clo...@googlegroups.com
When i code i don't think of them as close. Possibly because Haskell's
functional purity, strong type system, pervasive laziness puts it in
another grade "above" clojure.

Clojure feels closer to Scheme to me, and I don't think it just all the
parenthesis. So the decision for me was between clojure and
(plt-)scheme. The access to java portability and functionality was very
important.

Mark Derricutt

unread,
Jul 19, 2010, 11:33:32 PM7/19/10
to clo...@googlegroups.com
I liked the *look* of CAL - and was quite impressed that it had an
eclipse plugin. But it seems to be dead from what I can see on the
website. Or at least rather dormant.

--
Pull me down under...

On Tue, Jul 20, 2010 at 1:04 PM, Raoul Duke <rao...@gmail.com> wrote:
> or, how about CAL?

Nicolas Oury

unread,
Jul 20, 2010, 10:09:28 AM7/20/10
to clo...@googlegroups.com
On Tue, Jul 20, 2010 at 12:19 PM, Chas Emerick <ceme...@snowtide.com> wrote:
>
> Nicolas, just out of curiosity, what program (or class of program(s)) are you interested in that "can't be typed in Haskell"?  I'm always interested in seeing examples of static typing preventing the implementation of certain classes of programs, insofar as such things are an antidote to my tidal fascination with statically-typed languages.
>
> - Chas

Mainly DSLs that do not fit in the Haskell type systems and type
checkers for them.
Also : www.cse.chalmers.se/~wouter/Publications/ThePowerOfPi.pdf
(Warning: advertisement)

Another thing is the fact that writing big pattern matching of a
closed type does not work for the kind of program I do.
(At some time, we developed a tool to assemble a big pattern matching
from fragments in different files.
It just feels better to organise your program by theme, rather than
by functions...
I really appreciate having protocols, multimethods and case/cond and
to be able to work at this 3 levels.
Of course, all that can be done in Haskell by tricking the type system.
(For example type classes + forall + GADTs and type families). But
you spend more time tricking the type system than coding.)

But I would really love static typing that is as convenient as dynamic
typing (see the paper above for details about why dependant types are
great).
(Warning: advertisement)

Nicolas.

Brian Hurt

unread,
Jul 20, 2010, 11:20:22 AM7/20/10
to clo...@googlegroups.com
On Mon, Jul 19, 2010 at 10:20 PM, Mark Engelberg <mark.en...@gmail.com> wrote:

I think stateful things are too hard to do in Haskell, and they are an
important part of most real-world programs.  Clojure's blend of
persistent data structures with a variety of reference-type objects
that can contain them feels much more pragmatic to me.  Also, I'm just
happier working in a dynamically-typed language.

As a side note, years ago, I wanted to write something in Haskell that
worked like Clojure's memoize (which is implemented in a half-dozen or
so lines of code in Clojure's core), and asked about it on the Haskell
mailing list.  I was pointed to a PhD dissertation on the topic of how
to write memoize in Haskell.  All I could think was, "Do I really want
to be using a language where memoize is a PhD-level topic?"


I wasn't going to reply to this, as this isn't the place to do language advocacy.  But this comment has made it to the top of both reddit/programming and hacker news, so some sort of response is needed.

First of all, it's not that hard to write a memoize function in Haskell.  Either recognize that because you're updating state, you need to be in a monad (I'd recommend Control.Monad.State), or use unsafePerformIO.

But the real error you committed is one that Clojure newbies make as well, and very much does apply to Clojure.  You confused *a* solution to the problem with the problem itself.  Memoization is the *solution*- what's the problem?  The problem is that you have this value that is very expensive to compute, that you may not need at all, and that you only want to compute once if you do need it.  This is a job for lazy evaluation- especially in Haskell where everything is lazily evaluated anyways.  Memoization is, in fact, just one way to implement lazy evaluation in languages that are not lazily evaluated.  Lazy values are useful in a lot of situations other than lazy lists (aka seqs).

Second of all, this is a problem Clojure faces as well!  Maybe not around memoization, but definitely around other issues.  For example, consider the following: how do you implement a doubly linked list efficiently in Clojure?  The answer is: you don't.  But a doubly linked list is a solution, not a problem.  The problem is that you need a data structure where it is cheap to both add and remove elements from both ends.  The proper solution in Clojure is to implement one or another (applicative, lazy) dequeue.  But in this case it's very easy for a programmer new to functional languages and Clojure to confuse this solution with this problem- doubly linked lists are the solution for that problem in everything from Cobol and Pascal to Java, C#, Ruby, and Python.  "What?  You want me to either accept a huge speed and memory hit, drop to Java, or go read some weird book I've never heard of written in yet another programming language nobody uses (ML) just to implement a doubly linked list in Clojure?  What sort of stupid language is this?"

Here's to hoping that newbies to Clojure don't adopt the same attitude to Clojure you adopted to Haskell.

Brian

Sang Noir

unread,
Jul 20, 2010, 12:19:55 PM7/20/10
to Clojure
I'm really tickled by the reaction to this comment on places like
reddit. Especially how all the Haskell apologists are rushing to the
defense of their language even though it's obvious that no Haskell
programmer UNDERSTANDS the language, especially the type system.

Not exaggerating here. To confirm it, ask them about monads. Here's a
conversation I had with an expert Haskell programmer, edited for
length and spelling:

Him: A functor is a type with a method for taking a "container" and
applying a function to its contents, and returning a container the
same size with the return values of those function applications
Me: We have that. It's called map.
Him: Yes
Him: In Haskell it's called fmap
Him: So a monad is that, plus two other methods
Him: return takes a single value and makes a container with that value
in it
Him: join takes a container of the same kind of container and flattens
them
Me: ...
Him: So the container
Me: Then monads are just data structures
Him: Well no
Me: Lists are monads, right?
Me: So why isn't "Monad" called "DataStructure"
Him: Correct, but
Him: Well that's what it's called in category theory

He went on to talk about monoids and applicatives. What he was trying
to say without actually admitting it was that these things have weird
names just for the sake of making everything more complicated than it
needs to be. This, people, is what you get when you design a language
around a type system: Meddlers with PhDs in category theory, making
desperate grabs for job security. Actually, it's an established fact
that a type system is never one of the interesting or useful parts of
a language, and that's why I stick to languages which don't have a
type system in the first place.

Brian Hurt

unread,
Jul 20, 2010, 2:02:01 PM7/20/10
to clo...@googlegroups.com
On Tue, Jul 20, 2010 at 12:19 PM, Sang Noir <noir.s...@gmail.com> wrote:
I'm really tickled by the reaction to this comment on places like
reddit. Especially how all the Haskell apologists are rushing to the
defense of their language even though it's obvious that no Haskell
programmer UNDERSTANDS the language, especially the type system.


You are mistaking "they don't understand the concept" with "they failed to explain it in simple enough terms for you to understand, once in IRC".
 
A map is (or at least could be) a monad (a variant of the list monad)- but not all monads are maps.

The only real way to learn monads is to use them- the same way the only real way to learn macros is to use them ("they're just like C preprocessor macros, kinda...").

Here is the problem I have with the snarky comment: it's encouraging people to treat their languages as blub languages.  Now, remember- a language being a blub language isn't saying anything about the language itself, it's saying something about the programmer's attitude to that language.  The essence of a blub language is that the blub language programmer looks at more powerful languages and goes "I don't see a need for that, Blub does everything you need it to do", even while dismissing less powerful languages for being less powerful.  It's not the language, it's the programmer.  Remember that when I say:

Clojure is a blub language for a lot of people on this list.

If you look at Haskell, and go "why the hell do I need that?  Clojure does everything I need", then, for you, Clojure is Blub.

Brian

Rich Hickey

unread,
Jul 20, 2010, 2:03:54 PM7/20/10
to Clojure
There is no purpose to a message like this.

Everyone, please refrain from language wars. Haskell is a tremendously
ambitious and inspiring language, for which I have the highest
respect. There is zero point in bashing it (or its users) in this
forum.

Thanks,

Rich

Nicolas Oury

unread,
Jul 20, 2010, 1:03:53 PM7/20/10
to clo...@googlegroups.com
On Tue, Jul 20, 2010 at 5:19 PM, Sang Noir <noir.s...@gmail.com> wrote:
> Me: So why isn't "Monad" called "DataStructure"

Me: Because they are not data structures.
They are an abstraction that can represent computations. One kind of
computation are the non-deterministic ones.
They look like lists.

But parsing, continuations, states program are monads.
m a means a computation that returns something of type a.

That's actually a concept that has a meaning even in a dynamically
typed language.
And it can be useful in Clojure, too. You can put the do notation as a
macro and use this useful abstraction.

One particular monad is a list and another one (the free monad) is a
tree representing programs. But most monad are not data structures.
That's far more general than that.

Haskell is a great language and brings a lot of clever ideas.

Raoul Duke

unread,
Jul 20, 2010, 3:43:45 PM7/20/10
to clo...@googlegroups.com
On Mon, Jul 19, 2010 at 8:33 PM, Mark Derricutt <ma...@talios.com> wrote:
> I liked the *look* of CAL - and was quite impressed that it had an
> eclipse plugin.  But it seems to be dead from what I can see on the
> website.  Or at least rather dormant.

it is somewhat back. apparently. kinda.

http://groups.google.com/group/cal_language/browse_thread/thread/183df7bf7366acb1

nickikt

unread,
Jul 20, 2010, 6:21:59 PM7/20/10
to Clojure
Here is a bit on monads for clojure programmers.

A monad tutorial for Clojure programmers (part 1)
=> http://onclojure.com/2009/03/05/a-monad-tutorial-for-clojure-programmers-part-1/
(don't jet understand monads either but I think it sounds interesting
(and complicated))

I want to learn haskell at some point. It seams to have some
interesting concepts and learning it would make me (and everybody) a
better programmer.

If there are people wanting to study and/or work with complex
typesystems let them do there thing.

If you want to bash on something bash some easy target like php or C+
+.

On 20 Jul., 21:43, Raoul Duke <rao...@gmail.com> wrote:
> On Mon, Jul 19, 2010 at 8:33 PM, Mark Derricutt <m...@talios.com> wrote:
> > I liked the *look* of CAL - and was quite impressed that it had an
> > eclipse plugin.  But it seems to be dead from what I can see on the
> > website.  Or at least rather dormant.
>
> it is somewhat back. apparently. kinda.
>
> http://groups.google.com/group/cal_language/browse_thread/thread/183d...
Reply all
Reply to author
Forward
0 new messages