Live data from Hacker News

Why I still reach for Lisp and Scheme instead of Haskell

jointhefreeworld.org

61–70 of 172 posts

Re: Why I still reach for Lisp and Scheme instead of Haskell

#61
post #29

Because they're elegant. Haskell is a conceptual and syntax mess.

Haskell is very elegant and pretty. It's hard to describe what pretty is when it comes to programming languages, but imo golang is ugly, rust is good, and Haskell the best.

Re: Why I still reach for Lisp and Scheme instead of Haskell

#62
post #14

Earlier quoted context omitted.

Lisp was meant to be written with M-expressions instead of S-expressions anyway.

M-expressions were never implemented and never used.

Actually, variations on M-expressions have been created many times in the Lisp world. (Look what you can do with macros!) So far, none of them has caught on. The latest attempt for Scheme is SRFI-266, which creates a very nice infix expression sublanguage. If I were working on a team, I would encourage them to use this, but I don't know if it has enough traction to become widespread.

Re: Why I still reach for Lisp and Scheme instead of Haskell

#63
post #43

> You can pause, inspect objects, change values, and even redefine a broken function on the fly to test a fix in any environment (yes even in production, while running). I see this mentioned often, and it sounds amazingly useful (especially the part about fixing in production!). But how truly widespread is it among the Lisp dialects to be able to connect to a running program, debug, and hotfix it? I understand Common…

It’s common in Clojure as well as other Lisps. I was just doing that exact thing, modifying a running program in production, earlier this week, adding in print calls to gather debugging information and then modifying the code to fix the bug and it immediately going live and the correct behavior verified.

Re: Why I still reach for Lisp and Scheme instead of Haskell

#64
post #43

> You can pause, inspect objects, change values, and even redefine a broken function on the fly to test a fix in any environment (yes even in production, while running). I see this mentioned often, and it sounds amazingly useful (especially the part about fixing in production!). But how truly widespread is it among the Lisp dialects to be able to connect to a running program, debug, and hotfix it? I understand Common…

it's been my experience that when most people say "Lisp does this that or the other", what they usually mean is "Common Lisp does this that or the other". Often there's an implicit "with SLIME" in there as well

This is doable in Common Lisp, Scheme/Racket, and Clojure. Yes, it might require some tooling.

Re: Why I still reach for Lisp and Scheme instead of Haskell

#65
post #14

Earlier quoted context omitted.

For all practical purposes, the syntax of Lisp isn't just a cosmetic choice, though.

Lisp was meant to be written with M-expressions instead of S-expressions anyway.

If you want a Lisp that basically has M-expressions, try Dylan. It even started with an S-expression syntax initially and then converted to infix.

Re: Why I still reach for Lisp and Scheme instead of Haskell

#66

I don't believe monads are a "heavy handed abstraction" and that's what prevents people from prototyping in Haskell. What really prevents people from writing in Haskell at a reasonable speed is the poor language design. Programming languages are supposed to aid in reading by emphasizing structure. It's important to emphasize that a particular group of "words" constitutes a function call, or a variable definition, or…

Try Clojure with CIDER/nREPL (roughly similar to SLIME/SWANK).

Re: Why I still reach for Lisp and Scheme instead of Haskell

#67
post #24

Earlier quoted context omitted.

I don't see how: Racket: > (define (fact n) (if (= n 1) 1 (* n (fact (- n 1))))) > (fact 6) 720 OCaml: # let rec fact = function | 1 -> 1 | n when n > 1 -> n * (fact (n - 1)) in fact 6;; - : int = 720

Whenever someone complains about not being able to use a slightly different syntax, I assume they just don't have any neuroplasticity anymore.

I think syntax matches with our brains or not. I think anyone is capable of learning any syntax. The question is whether they want to. At some level, programming is art.

Re: Why I still reach for Lisp and Scheme instead of Haskell

#68
post #58
post #55

Earlier quoted context omitted.

> inner expressions must be indented more Not to support the parent comment, which I disagree with, but If you use multi-line let-bindings, those require that you indent not just more than the previous line, but as much as the first token after the let keyword on the previous line. It’s a very strange rule, all the more surprising because it’s inconsistent even with the rest of the language. It is totally avoidable i…

So you want to line the equals signs up or similar? let f = 9 fo = 10 foo = 123 in f+fo+foo vs. let f = 9 fo = 10 foo = 123 in f+fo+foo

No, the issue is if the first binding is on the same line as the `let`, you are required to write, e.g.:

    someValue = let f = 9
                    fo = 10
                    foo = 123
      in f+fo+foo
rather than:

    someValue = let f = 9
      fo = 10
      foo = 123
      in f+fo+foo
I think it used to be the case that it had to be indented past the `=` or the `let` even if it was't on the same line. Note also that `in` has to be indented past `someValue`, but doesn't need to be indented as far `let`.

This is fine:

    someValue = let
      f = 9
      fo = 10
      foo = 123
      in f+fo+foo
So, it is possible to land on sane indentation, but the parser is much pickier than, e.g., Python's off-sides rule, so it takes some trial and error for new users to find it, and it can be frustrating if you're just temporarily modifying an expression to quickly try something out.

I honestly think it would be less surprising if the parser just disallowed writing the first binding on the same line as the `let` entirely, treating it only as a block, but some people (bewilderingly) do seem to prefer to write their code with the excessive indentation (I'd imagine with editor support, rather than manually maintaining the spacing).

Re: Why I still reach for Lisp and Scheme instead of Haskell

#69
post #47
post #43

> You can pause, inspect objects, change values, and even redefine a broken function on the fly to test a fix in any environment (yes even in production, while running). I see this mentioned often, and it sounds amazingly useful (especially the part about fixing in production!). But how truly widespread is it among the Lisp dialects to be able to connect to a running program, debug, and hotfix it? I understand Common…

Python is not Lisp, but jumping into a Python REPL in a halfway-run program and poking at the internals easily is _very_ useful as a debugging tool, quickly getting you answers on some messier programs. It's a shame that other scripting languages that theoretically have the capabilities to do this don't do this (looking at you, node! Chrome dev tools are fine but way too futzy compared to `import pdb; pdb.set_trace()…

Yeah not having an equivalent to pdb.set_trace() is what turned me off compiled languages, but with AI I'm not even sure anymore.

Re: Why I still reach for Lisp and Scheme instead of Haskell

#70
> Remember that later, just adding a simple print somewhere is not going to work without refactor (welcome to the IO monad).

This hits home for me. Print statements are essential to the way I code. I use them to debug, to examine variables and parameters, to trace execution flow. I rarely use debuggers.

Post reply on HN