A philosophical difference between Haskell and Lisp (2015) • Hacker News Board

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

#111

Post by eru » Mon, Aug 03, 2020, 3:54 AM UTC

garmaine wrote: post #58

enriquto wrote: post #53

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…

Sounds more like applied math...

Nothing wrong with applied math. It's still math.

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

#112

Post by eru » Mon, Aug 03, 2020, 3:55 AM UTC

LesZedCB wrote: post #92

dan-robertson wrote: post #80

Earlier quoted context omitted.

I also followed a pure maths education. I like lisp (in the CL/emacs lisp family more than scheme which tends to have smaller composable functions) and Haskell. I find some parts of Haskell culture/styles to be quite silly however, and fewer parts of the lisp community to be silly. But that may just be because of Haskell’s greater popularity.

is haskell more popular now? what about clojure?

Perhaps greater memetic popularity?

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

#113

Post by eru » Mon, Aug 03, 2020, 3:57 AM UTC

> Having written my fair share of non-trivial Emacs Lisp (and a small share of Common Lisp; I’ve maintained Common Lisp systems) and my fair share of non-trivial Haskell I think I’m in a position to judge.

While I prefer Haskell, judging Lisps by Emacs Lisp isn't entirely fair. It's probably the worst Lisp in somewhat wide use.

('newLisp' is worse, of course. But thankfully no one in their right mind uses it.)

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

#114

Post by mncharity » Mon, Aug 03, 2020, 4:00 AM UTC

cc_ashby wrote: post #17

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…

> There is a strange... kind of poetry with Haskell. It is like math on wheels [...] pure and dream-like

For me too there is a feeling of poetry... but for me it's more the nails-on-blackboard grating of awful poetry, and the ice-pick-to-ears screeching of abrading subway wheels. :)

Lisps merely inspire me towards elegant craftsmanship. But Haskell tempts me to dream of more. It's my fault, but ouch.

Dreams of math made manifest. Of materializing a lattice of theories, each with types and operators and laws, simply extensible and composable - a push-out lattice. Dreams of programming that's more math than plumbing. And maybe someday, some future Haskell Next will permit that flight, that dance. But that's not Haskell.

Someone I know, will pull up the deep math of a problem domain, model it in Coq, and mentally compile it to Haskell, extending GHC internals as needed to better serve as compiler target. For a wetware compiler that gets only very limited support from current tooling. I can't do that. Not even close. I need a language and tooling that's on the same page as me, to serve as an extended self. And for this, that's not Haskell.

Many years back, someone in a conversation suggested a core skill of a professional C++ programmer, was cataloging the things which seem like good ideas, and might even serve well in some other OO language, but which tended to go badly in that era's C++. Along with many baroque workaround to salvage others.

Fewer years back, I'd a conversation about using Haskell in education. We talked of alternate preludes to remove historical clutter, and extensions to remove historical limitations. And turned up a fun divergence - he thought of learning Haskell as fairly easy, and I thought of it as ghastly hard. For his default context was programming in the small - vocabulary, functional mindset and such. And mine was... you the start at the other end, with the dream, the no-extraneous-complexity pure essence of what is needed... and now you have to learn the zoo of baroque work arounds, and crippling limitations, by which Haskell fails the dream.

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

#115

Post by eru » Mon, Aug 03, 2020, 4:00 AM UTC

nimih wrote: post #41

behnamoh wrote: post #11

Earlier quoted context omitted.

Is there something similar to (->>) in Haskell? Edit: corrected “—>”.

Assuming that (-->) is either a typo of Clojure's ->> or ->, or some CL macro that operates the same (I don't know any CL, admittedly), in Haskell there is the somewhat common & (as in, available in the standard library and the widely-used lens library, but not part of the prelude and a lot of folks seem to eschew it in favor of composing in "the other direction" with . and $), which is defined as `flip ($)` (i.e. re…

If you really want to, Haskell also has a few macro systems. They are just not used nearly as much as in Lisp.

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

#116

Post by eru » Mon, Aug 03, 2020, 4:03 AM UTC

thewakalix wrote: post #96

dwohnitmok wrote: post #63

Earlier quoted context omitted.

Ah I was wrong! That's what I get for not coding in Haskell in a year and not checking my answer with GHC. Function application always has higher precedence than infix operators so I can't emulate thread-first with functions in Haskell. If that wasn't the case, this would work (this was what I was thinking of) (|*>) :: b -> (a -> b -> c) -> (a -> c) (|*>) x f = (\y -> f y x) xs = 5 |*> take [1, 2, 3] Otherwise, I can…

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.

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

#117

Post by eru » Mon, Aug 03, 2020, 4:06 AM UTC

jim-jim-jim wrote: post #37

rbonvall wrote: post #26

Earlier quoted context omitted.

You can create it yourself: Prelude> s ->> f = f s Prelude> [1..100] ->> take 10 ->> filter (not . odd) ->> drop 3 [8,10]

I think `&` is this function. In Data.Function.

Or you can use >>> from Data.Function, if you prefer to go point-free.

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

#118

Post by sukilot » Mon, Aug 03, 2020, 4:08 AM UTC

reikonomusha wrote: post #101

dan-robertson wrote: post #84

Earlier quoted context omitted.

Strictly speaking, Common Lisp does not have series because they were not included in ANSI Common Lisp. Therefore even though you could use the macros provided with a separate streams package, you’d need to make sure that all your code used that package (rather than the CL definitions of let and lambda and so on) and properly declared stream functions. This ends up making code using streams not super composable which…

GHC does have special support for fusion and rewriting. See e.g. [1]. The laziness comes with the language, but turning it efficient requires a series of these rewrite rules expressed as GHC-specific metadata. [1] https://markkarpov.com/tutorial/ghc-optimization-and-fusion....

GHC is the most complicated compiler of any language (or very near to it), except perhaps Mathematica which is similar:

It's an optimizer for a graph-reduction engine.

It doesn't mean much to call out "special support" for any one bit of style of programming, since the language itself has nearly no concept of performance -- you just write functional code and the compiler will find the fastest runtime computation of the evaluation that it can.

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

#119

Post by eru » Mon, Aug 03, 2020, 4:08 AM UTC

dllthomas wrote: post #72

thom wrote: post #51

Earlier quoted context omitted.

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.

I very much enjoyed a Kmett talk where he described needing to parameterize some lens thing with an index, a monad it would operate under, the source focus, the target focus, and three different containing structures, with some pieces repeated... and then realizing the type arguments said `i m a s t a b u` and decided he had probably gone too far.

What's interesting is that Ed Kmett isn't even a dyed in the wool Haskeller. He has more than a foot in the C++ world.

He's quite brilliant, but I still haven't really gotten used to the full power of lenses, yet. I only used them in simple ways.

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

#120

Post by eru » Mon, Aug 03, 2020, 4:09 AM UTC

garethjrowlands wrote: post #27

behnamoh wrote: post #11

Earlier quoted context omitted.

Is there something similar to (->>) in Haskell? Edit: corrected “—>”.

Not really. In the example, function composition, `.`, joins the functions together. You can smash a list of functions together but they'd all have to take and return the same type, and the list would introduce commas and square brackets, so it wouldn't look quite the same.

You might be able to do some type trickery with heterogeneous lists? But I don't think it would be worth it.