Live data from Hacker News

A philosophical difference between Haskell and Lisp (2015)

chrisdone.com

141–150 of 181 posts

Re: A philosophical difference between Haskell and Lisp (2015)

#141
post #65

The main difference is that in lispy languages you wouldn't use the language itself to solve the problem. You'd extend it. I'd write a function that is (drop3-take5 test list) which does exactly what it says. This might seem like huge overkill, but when the specs change and I need to set the start and stop from a config file I can easily refactor drop3-take5 into (drop-n-take-m n m test list), with a let around it to…

Ok, now it fails - how are you going to interpret the stack trace?

Re: A philosophical difference between Haskell and Lisp (2015)

#142
post #2

When I was new to Haskell (and also not an experienced programmer), the following example on “functional style” had a huge positive impact on me -- where the same program is re-written in ten different ways, each time making it more modular & composable: http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way... (section 3.1... Feel free to ignore everything before/after that) It feels so much easier to both und…

I love the "modifying version 1 is left as an exercise to the viewer."

And I'll definitely read more of that blog.

Re: A philosophical difference between Haskell and Lisp (2015)

#143
post #95
post #48

A small note: composition is not better than monolithism. The article makes it feel like it is but it is not. They are two perfectly valid approaches when it comes to solving problems. Often a mix of both is used. Monoliths tend to be better at solving common real life problems efficiently while composition is better suited for unexpected abstract problems. We need both. For example GNU binutils are not very "unixy",…

I did find it ironic that composition was called UNIX philosophy, when most UNIX tools are complicated functions with many options much more akin to the lisp function examples. (Of course it's the "UNIX pipes" part of the philosophy that's being alluded to, but it's still a funny twist)

cat -v

Re: A philosophical difference between Haskell and Lisp (2015)

#144
post #126

There is a strange... kind of poetry with Haskell. It is like math on wheels, math applied to procedures, math with... time. Its appeal to me is like the appeal of math to me, not like real analysis math but abstract algebra math. The beauty, the purity of mathematics of younger days that once became lost after encountering the sad complexities of the world. Understanding every little aspect and being able to prove e…

Math with time (and space/memory)... You just found the difference between computer science and math. And the reason proof-of-work in blockchains is possible.

Regarding time... It's sometimes not easy to say what happens when in a Haskell program. Yes, monads give you a sequence, but it's usually not the one sequence of an imperative language.

Re: A philosophical difference between Haskell and Lisp (2015)

#145
post #62

There's a more fundamental philisophical difference: Common Lisp promotes the use of doclines and apropos tools in order to discover and understand behaviour, with symbol names that tend to describe the function of what they represent. Haskell leans on type signatures and symbolic operators. IMHO, a pseudo-random sequence of non-word symbols tied to a type signature is of very little use. IE, something fabricated: (-…

> IMHO, a pseudo-random sequence of non-word symbols tied to a type signature is of very little use.

Having only ever dabbled in Haskell, I feel the same way, but I'm aware that proficient Haskell programmers don't tend to agree. How do you rate your Haskell skills?

I've heard the same said of another 'weird and wonderful' language: Forth. Yes, it's incomprehensible if you aren't familiar with the language, but that's not really who the language is for.

Re: A philosophical difference between Haskell and Lisp (2015)

#146
post #116

Earlier quoted context omitted.

Using right-associativity of function types, and by sugaring the lambda into another function argument, we can rewrite this as (*-) :: (a -> b -> c) -> b -> a -> c (*-) f x y = f y x This reveals that (*-) is simply flip, which is in the Prelude (re-exported from Data.Function). Alternatively, Hoogling the original type signature will reveal the same thing. So the example doesn't require any new functions: import Dat…

If you don't like flip, you could also do xs :: [Int] xs = 5 & (`take` [1, 2, 3]) & filter (/= 1) & head & (`take` [1, 2, 3]) But I'm not sure that's a better style than flip. I really like `on` from Data.Function, too.

For maximum readability I'd be tempted to write the lambdas explicitly.

  xs =
    5
      & (\n -> take n [1, 2, 3])
      & filter (/= 1)
      & head
      & (\n -> take n [1, 2, 3])

Re: A philosophical difference between Haskell and Lisp (2015)

#147

There is a strange... kind of poetry with Haskell. It is like math on wheels, math applied to procedures, math with... time. Its appeal to me is like the appeal of math to me, not like real analysis math but abstract algebra math. The beauty, the purity of mathematics of younger days that once became lost after encountering the sad complexities of the world. Understanding every little aspect and being able to prove e…

Paid haskeller here.

That feeling you describe quickly goes away when you use the language everyday. Once that happens, you can start weighting it as a tool.

And overall, my assessment is that purity and practicality are not competing aspects. I would say that purity conttibutes to the practicality of haskell.

Re: A philosophical difference between Haskell and Lisp (2015)

#148
post #109

Earlier quoted context omitted.

Yep, sorry. This is a matter of feeling, completely irrational, but just my experience. When I program in lisp I get the same feeling when I'm solving an ODE by hand, or a Diophantine equation, or designing a numerical method to approximate the solution of a PDE, or finding the Euler-Lagrange equations of a physical problem. The thing is real and it gets shit done really fast; it is just exhilarating. Moreover, lisp…

Do you prefer analysis over algebra? How do you eat your corn? (I prefer algebra and Haskell. But I like Lisp well enough.)

I like geometry first, then algebra and analysis. I work mostly by teaching analysis and doing some research.

Re: A philosophical difference between Haskell and Lisp (2015)

#149
post #51

Earlier quoted context omitted.

I think there are some pipe-like operators in the popular Lens library (and presumably others as well). However, writing Haskell, you quickly get used to everything being backwards.

I find the Lens operators in Haskell just the most hilarious API in all of computing, even knowing that there is some sense to it.

While I have found the majority of my interactions with Haskell (and ML family languages) deeply satisfying, I have never really used Lens in anger, having been put off each time I've tried to get into it. Although, I remain slightly simpathetic since - as you say - there is some theory underlying it all.

I may be mistaken, but I think I have seen a handful of "Lens-lite" type libraries for use in production since it's such a large library, which seems.. uh.. suboptimal.

Re: A philosophical difference between Haskell and Lisp (2015)

#150
post #50

Earlier quoted context omitted.

This comes for free from Haskell's automatic partial application (that arises from Haskell's pervasive use of function currying). So several different Haskell variants of Clojure's `compose` correspond to different versions of Clojure's threading macros. Clojure's threading macros arise because it's a little bit more awkward in Clojure to partially apply functions (either anonymous functions with # or use `partial`)…

What's the syntax in Haskell for thread-first (-> in Clojure) which inserts the result of the previous operation as the first argument, versus thread-last (->>) which inserts it at the end, so is more amenable to composed curried functions?

I think the Prelude answer would be to use `flip`[1], along with composition (`.`) or application (`$`) as usual.

    flip :: (a -> b -> c) -> b -> a -> c 

[1]: https://hackage.haskell.org/package/base-4.14.0.0/docs/Prelu...
Post reply on HN