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…
A philosophical difference between Haskell and Lisp (2015)
141–150 of 181 posts
Re: A philosophical difference between Haskell and Lisp (2015)
#142When 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…
And I'll definitely read more of that blog.
Re: A philosophical difference between Haskell and Lisp (2015)
#143A 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)
Re: A philosophical difference between Haskell and Lisp (2015)
#144There 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.
Re: A philosophical difference between Haskell and Lisp (2015)
#145There'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: (-…
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)
#146Earlier 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.
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)
#147There 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…
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)
#148Earlier 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.)
Re: A philosophical difference between Haskell and Lisp (2015)
#149Earlier 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.
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)
#150Earlier 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?
flip :: (a -> b -> c) -> b -> a -> c
[1]: https://hackage.haskell.org/package/base-4.14.0.0/docs/Prelu...