Live data from Hacker News

A difference between Haskell and Common Lisp

chrisdone.com

31–40 of 203 posts

Re: A difference between Haskell and Common Lisp

#31
post #26

Earlier quoted context omitted.

Minor nitpick. Technically, this: #(->> % (drop 3) (filter p) (take 5)) Is equivalent to: take 5 . filter p . drop 3

One could also change the Haskell. Data.Function (&); Control.Arrow (>>>) -- the pipe operator seems to be all the rage these days (|>) = (&) -- forward application + forward composition xs |> (drop 3 >>> filter p >>> take 5) Only function application xs |> drop 3 |> filter p |> take 5

I never understood the appeal of the pipe operator. It's a kludge to work around the need to eta-expand chained function compositions, which in turn is a kludge to work around the value restriction, which in turn is a kludge to prevent the combination of polymorphism and storage effects from breaking type soundness. Haskell doesn't need any of this.

Re: A difference between Haskell and Common Lisp

#32
Having worked on one of the largest common lisp projects I have to say this is spot on. And monolithism it's not just visible on level of functions it's visible on higher level. Common lisp nudges you to write monolithic applications and it's crucial to keep many details in one head (in case of big project - many heads).

Also I think Clojure is scheme, so overall approach is different.

Re: A difference between Haskell and Common Lisp

#33

I'm confused by the last example. There are no elements greater than 5 in the list (1 2 3 4). Also, I'm not sure why they used takewhile instead of filter in the last haskell part.

I assumed it to be a typo; i.e., it should say "less than".

`takeWhile` is different to `filter` in that is returns the input list until some element matches the predicate, whereas `filter` returns all elements that match the predicate. For example, if the predicate is `(< 5)` and the input was `[9, 2, 3, 6]`, then `takeWhile` would return an empty list, but `filter` would return `[2, 3]`.

Re: A difference between Haskell and Common Lisp

#34
post #32

Having worked on one of the largest common lisp projects I have to say this is spot on. And monolithism it's not just visible on level of functions it's visible on higher level. Common lisp nudges you to write monolithic applications and it's crucial to keep many details in one head (in case of big project - many heads). Also I think Clojure is scheme, so overall approach is different.

No, Clojure isn't Scheme. Scheme has hygienic macros and pattern matching on syntax, which in turn Racket's `syntax-parse` library makes even better.

Clojure... well... has that ugly `defmacro` kludge.

EDIT: I was being kind of unfair. Clojure also has kickass collections in its standard library, which Scheme doesn't have.

Re: A difference between Haskell and Common Lisp

#35

Perhaps it's just me, but I don't see that Haskell and Lisp are that similar, other than... 1. They're both programming languages. 2. They both allow you to pass functions as arguments to other functions. Am I missing something here? Why are the two linked? Is it because Lisp is seen as the birthplace of functional languages (because of point 2)?

Yeah, people talk about "functional languages" as if they're a unified thing. IMO the differences between the strongly typed ML/Haskell tradition and the Lisp tradition are as big as the differences between either and "OO languages" or "imperative languages", but that's not the way it's usually presented.

Re: A difference between Haskell and Common Lisp

#36
Common Lisp has these kitchen-sink functions and macros because it was a standard developed by a committee whose goal was to incorporate several popular implementations of Lisp that each had several decades worth of of cruft. Lisp was big enough business at the time that having several mutually incompatible versions of Lisp was making knowledge sharing and business difficult. And having a standard was important for many reasons.

update: spelling and...

The real philosophical differences between Haskell and Lisp are basically apples and oranges. Lisp's composition strategy is the recursive application of symbolic expressions... the famous EVAL and APPLY. I don't know enough about the theoretical underpinnings of Haskell to make any kind of apt comparison but my intuition suggests that to do so would be moot. They're just too different.

Re: A difference between Haskell and Common Lisp

#37

Earlier quoted context omitted.

Minor nitpick. Technically, this: #(->> % (drop 3) (filter p) (take 5)) Is equivalent to: take 5 . filter p . drop 3

Is take 5 . filter p . drop 3 An anonymous function call in Haskell? I don't know the language (although it's on my to-learn sequence).

Yes, written in pointless style. You could make it less pointless by replacing the (.)s with a point.

    \xs -> take 5 (filter p (drop 3 xs))
https://wiki.haskell.org/Pointfree

Re: A difference between Haskell and Common Lisp

#38
I'm not entirely sure that this is due to philosophical differences. The fact that Haskell is lazily evaluated makes writing functions that do only one thing much easier, since there is no performance hit for writing code like:

  take 5 . filter (not . p) . drop 3
In a strictly evaluated language. This would involve iterating over the list three different times. (Kind of not really, since take 5 isn't going to be that expensive.)

Re: A difference between Haskell and Common Lisp

#39

Common Lisp has these kitchen-sink functions and macros because it was a standard developed by a committee whose goal was to incorporate several popular implementations of Lisp that each had several decades worth of of cruft. Lisp was big enough business at the time that having several mutually incompatible versions of Lisp was making knowledge sharing and business difficult. And having a standard was important for m…

The theoretical foundation of Haskell is a typed lambda calculus called System F-omega. GHC Haskell has some additional features that are inexpressible in System F-omega.

Re: A difference between Haskell and Common Lisp

#40

I'm not entirely sure that this is due to philosophical differences. The fact that Haskell is lazily evaluated makes writing functions that do only one thing much easier, since there is no performance hit for writing code like: take 5 . filter (not . p) . drop 3 In a strictly evaluated language. This would involve iterating over the list three different times. (Kind of not really, since take 5 isn't going to be that…

[deleted]
Post reply on HN