151–160 of 181 posts
Prelude> take 5 . filter even . drop 3 $ [1, 2, 3, 4, 5, 6, 7, 8, 9]
[4,6,8]
(remove-if-not #'evenp '(1 2 3 4 5 6 7 8 9) :count 5 :start 3)
(1 2 3 4 6 8)Javascript and Python have similar capabilities, but they're missing the stream fusion optimization mentioned at https://chrisdone.com/posts/stream-composability/ Javascript: a = [...Array(20).keys()] p = x=>!(x%2); a.slice(3).filter(p).slice(0,3) Python: a = range(20) p = lambda x: not x%2 filter(p, a[3:])[:3]
(remove-if-not #'evenp '(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15) :count 5 :start 3)
(1 2 3 4 6 8 10 12 14 15)
a = (1..15)
r = []
c = []
a.each.with_index do |e, i|
if i [1, 2, 3, 4, 6, 8, 10, 12, 14, 15]
a = (1..15)
l = a.take(3)
c = 0
m = a.drop(3).map.with_index { |e, i| [e, i, e.even?] }.take_while { |e, i, p| c +=1 unless p; c [1, 2, 3, 4, 6, 8, 10, 12, 14, 15]This is interesting to read having worked with Clojure, but never Haskell or CL. I expected the Haskell examples to look alien and the CL to look familiar, but the idiomatic Clojure solutions to the examples are almost identical to the Haskell solutions. E.g. take 5 . filter (not . p) . drop 3 becomes (->> s (drop 3) (filter (complement p)) (take 5)) ; for some sequence s I think it is also true of Clojure that it st…
Now there's a different discussion to be had about laziness and immutability but for a lot of stuff it doesn't really come into play.
We have laziness in Clojure but don't think we have stream fusion. Yet the functional approach works just fine for most things and is preferred.
Even in JS which doesn't even have built-in laziness most new stuff uses a functional approach (underscore,lodash etc) wherever possible too.
CL is just unique in that it has a very long history and a huge standard library. They have many of these monolithic functions that other languages simply don't have built-in.
Earlier quoted context omitted.
> 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 m…
God, reading these comments generates inspiration in me to create a pristine, beautiful language for you all to lust over. Lolol
Even with category theory, the overwhelming emphasis is on using it for proof rather than for its expressiveness. A fun example... from a very collegial course in pre-Covid January, sniff... Categories work over PreSets - no predicate of member equality required. But say I claim to be handing you a PreSet. You can't verify that claim. Your ability to prove anything is very limited. Sad for mathematicians. But fine as API. But that's not where attention is.
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?
I can trace it well less well in guile which is the usual scheme I use for daily projects but it's not something I've had huge trouble with on medium sized projects >10,000 lines.
Earlier quoted context omitted.
Ok, now it fails - how are you going to interpret the stack trace?
Not sure what you mean, it depends on the implementation. The cheapest cop out answer would be: use racket and step through until you reach the point where it fails. The IDE even gives you a nice handy list of the current continuation. I can trace it well less well in guile which is the usual scheme I use for daily projects but it's not something I've had huge trouble with on medium sized projects >10,000 lines.
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!
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.
Javascript and Python have similar capabilities, but they're missing the stream fusion optimization mentioned at https://chrisdone.com/posts/stream-composability/ Javascript: a = [...Array(20).keys()] p = x=>!(x%2); a.slice(3).filter(p).slice(0,3) Python: a = range(20) p = lambda x: not x%2 filter(p, a[3:])[:3]
but the slices here would spoil it
there is https://docs.python.org/3/library/itertools.html#itertools.i... islice however...
I'm a little bit confused about the notion that composition isn't used much in lisp as opposed to Haskell. Isn't composition literally the benefit of S-expressions, prefix notation, and everything being a function?
Lisps lack implicit currying, so function composition becomes much more verbose. And functions aren't that important in CL, not everything is a function and CL is usually written in an OOP or procedural style. CL is more about data and AST composition then anything else. Moreover, CL is a lisp-2, so in a very real sense, functions are second class citizens in the language.
https://github.com/eschulte/curry-compose-reader-macros
Functions are not second class citizens. They are privileged with their own namespace. That's a perk, not a penalty.
One notable form of composition in CL is method combination. Does any other language support something like that?
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'…
I'm surprised no one has plugged Hoogle. It was the hands-down best resource to make Haskell reasonable for me. But even still, I found code that I wrote in Haskell not unlike the plentiful amount of code I wrote in Perl: returning to it after the fact was tedious.