51–60 of 181 posts
Earlier quoted context omitted.
Is there something similar to (->>) in Haskell? Edit: corrected “—>”.
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 dislike the lisp convention of remove-if, remove-if-not, etc. Filter and take isn't much better. The python convention is much nicer: [x for x in foo if x not in y] Turns out, this can be expressed in Lisp: (list x for x in foo if x not in y) I've implemented this into my fork of Lumen that runs on Python. https://github.com/shawwn/pymen It feels very nice to use: > (list x for x in (range 10) if (= (% x 2) 0)) """…
But list comprehensions suffer from the same problem the author is taking about, they don't compose. Its even worse than CL remove-if variant, where one can reify the filter into a function that can then compose.
Earlier quoted context omitted.
I followed a (pure) mathematics education, and I totally dig lisp. On the other hand, I abhor haskell and hate almost everything about it!
This comment would be more informative if you briefly explained why you abhor it and hate almost everything about it.
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 macros are so dirty and fun that using them feels like kinky sex.
Haskell is like category theory. Sure, it is pure and general, and you can create set theory and the rest of math from it. But it is certainly the most boring thing that I can think about.
But hey, whatever floats your boat.
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",…
Any particular reason why Lisp doesn't also tend to compose with smaller functions? Did it just happen to evolve that way? Is it easier to get the types of the smaller functions right when you have a compiler to help you like you do in Haskell?
Clojure takes that approach
I dislike the lisp convention of remove-if, remove-if-not, etc. Filter and take isn't much better. The python convention is much nicer: [x for x in foo if x not in y] Turns out, this can be expressed in Lisp: (list x for x in foo if x not in y) I've implemented this into my fork of Lumen that runs on Python. https://github.com/shawwn/pymen It feels very nice to use: > (list x for x in (range 10) if (= (% x 2) 0)) """…
For those that didn't know, Haskell does of course have list comprehensions: [x| x Here's an example finding consonants: [c| x
A nice thing about Haskell list comprehensions is they're based on a trivial transformation to monad syntax, which makes it easier to factor out complex list transformations into multiple little bites. I've run into this problem in Python. Also, Python list comprehensions can often behave very unexpectedly due to mutability.
Here's an example of the monad syntax:
[(x,y) | x do
x Any particular reason why Lisp doesn't also tend to compose with smaller functions? Did it just happen to evolve that way? Is it easier to get the types of the smaller functions right when you have a compiler to help you like you do in Haskell?
Earlier quoted context omitted.
This comment would be more informative if you briefly explained why you abhor it and hate almost everything about it.
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…
If we talk about the approach of using larger building blocks with named parameters, that's also typical in UNIX, since most UNIX commands have zillions of named arguments, even more so than typical Common Lisp functions. Typically it is easier in using interactive command languages to fill out common options to a command, than to write programs.
For example 'ls' does not expose a bunch of functions to combine, but is a powerful command with lots of named options:
https://man7.org/linux/man-pages/man1/ls.1.html
Named parameters/arguments are not generally common in Lisp. Emacs Lisp did not have them and wanted to avoid them explicitly.
Heavy use of Composition is idiomatic in lisps, too. It’s just the syntax doesn’t rub your face in it: It’s pretty common to see form in lisp that ends in a dozen close-parentheses as we see chains of forms being passed as arguments to other forms. It would be weird if composition wasn’t idiomatic in a language with first-class functions.
The loop macro isn’t good evidence: it’s notable precisely because of its difference from typical lisp usage. I’ve heard lisp programmers claim to refuse to use loop because it clashes with the rest of the language. I’m less interested in purity, and it is so convenient sometimes...if only as a clear illustration of just how much power and potential for abuse the CL macro system provides. Amd let’s just leave CLOS and metaobject protocols under the tarp for now :-)