Live data from Hacker News

A philosophical difference between Haskell and Lisp (2015)

chrisdone.com

71–80 of 181 posts

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

#71
For marketers who’ve been keeping an eye on the SEO landscape for a few years now, you’ll know that Google has made several big changes to their search engine algorithms. So far, there’s been Panda, Penguin, Hummingbird, and Pigeon, as well numerous 2.0, 3.0, and 4.0 updates to those as well. If you lost track of that zoo, you’re not alone, and many marketers have gone the past few years thinking that if you stuff enough keywords into your website, you’ll be fine. That won’t exactly get you where it used to 5 years ago, however, because today’s algorithms have more emphasis on optimizing the pages for the user – not just for search engine crawlers.

Another one of the big problems you see with SEO today is how marketers approach it. While many marketers consider all things SEO to fall under one umbrella of activities, there are actually two distinct branches to be addressed: on-page and off-page SEO. To help you learn more about the in’s and out’s of each, and re-tune your current strategy to be up-to-date, here’s a thorough overview and explanation of some best practices:

What is On-Page SEO? When you think of the most basic search engine optimization tactics like using keywords in your copy and optimizing the meta description, HTML code, title tags, and alt tags, that’s the foundation for on-page SEO. On-page SEO refers all the measures that can be taken directly within your website to improve its position in the search rankings. This includes those basic tactics listed above, but also takes into consideration things like overall content quality, page performance, and content structure.https://www.bloggerzune.com/2020/06/Off-page-seo.html?m=1

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

#72
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.

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.

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

#73

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)) """…

Even though it's more "Pythonic", I tend to avoid your Python version. I think my favorite way to write that would be:

> import whatever > filter(_ not in y, foo)

For me it's more readable. To each their own, of course.

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

#74
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: (-…

People who write Haskell don't just leave their symbolic operators undocumented. It's definitely heavy on the symbols but that and type signatures are certainly not the only tools Haskell devs have.

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

#75
post #68

Earlier quoted context omitted.

I disagree. With composition we have general building blocks which can be combined in an infinity of ways, and remain available to combine with newly added functions. The monolith way provides a fixed, non upgradable set of possibilities, so if your need does not fall into what already exists you need to add yet another monolith (see remove-if vs remove-if-not).

Change the Haskell example to read 3 and 5 as n and m from an external file. All of a sudden your beautiful code is now a huge mess and you need to refactor the one liner into at least three separate functions to try and keep the Maybe types from taking everything over. Meanwhile in lisp I would have written a special drop3-take5 function in the first place. Then refactoring it would just take replacing 3 with n and…

Isn't that the exact same thing you would do in Haskell? How you read from a config file in Haskell seems irrelevant here, and troubles with it are more related to purity than composition.

  dropNTakeM p n m = take m . filter p . drop n

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

#76
post #16

Common Lisp doesn’t just have LOOP, it also has Series [1]. I think the actual philosophical difference may be that Haskell does this with compiler support for stream function composition, whereas Common Lisp does it with a set of language-level macros any user could write (if they were as smart as Richard Waters). [1] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node347.html

Stream fusion in Haskell is done with rewrite rules. On the one hand, it's totally true that you're no longer really writing Haskell, and the facility for rewrite rules itself needed (at some point) to be added to the compiler. But at this point I can make my own data structures fuse (potentially in new ways) without further changes to the compiler.

https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

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

#77
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…

This seems like an unsustainable approach: will you need to write these bespoke functions for any combination of behaviors you would need?

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

#78
I was a bit puzzled. Clojure seems to provide both avenues.

The "Common Lisp" version:

  (for [i (range 1 10)
        :when (even? i)
        :while (
A Haskell-y version (according to the article):

  (->> (range 1 10)
       (take-while #(
Using Clojure's transducers:

  (into [] (comp
            (take-while #(

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

#79
post #74
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: (-…

People who write Haskell don't just leave their symbolic operators undocumented. It's definitely heavy on the symbols but that and type signatures are certainly not the only tools Haskell devs have.

On the one hand, the parent's comment is certainly hyperbole.

On the other hand, it's also the case that too any Haskell projects are under-documented. Probably worse than the typical language, and certainly worse than the best-in-class.

On the gripping hand... while types make poor documentation, they are always correct documentation, and they are automatically generated documentation. When I write Python or (apparently) Common Lisp, I can expect to get reasonable documentation by interrogating anything someone hands me. In Haskell, insofar as I have learned to get good information from the types, I get some (correct!) documentation for things that I have newly assembled myself!

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

#80

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…

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.
Post reply on HN