Live data from Hacker News

Why I still reach for Lisp and Scheme instead of Haskell

jointhefreeworld.org

91–100 of 172 posts

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

#92
post #8

> Lisp hackers have been effortlessly reshaping the language for decades using the powerful macro system and extending and bending the language to their will. I've written a bit of Racket code ( https://github.com/evdubs?tab=repositories&q=&type=&language... ) and I still haven't written a macro. In only one case did I even think a macro would be useful: merging class member definitions to include both the type and t…

Sometime back 15 years ago [0], I hit a bit of an existential crisis regarding my career and the kind of work I was doing. I thought the particular technology I was working in was "part of the problem", as I felt pigeon-holed by .NET and C# to always be a corporate-monkey CRUD consultant. So, I went out in search of something better. Different programming languages. Different environments. Just something that wasn't…

> [...] who thought it was okay to yell at people about [...]

That society as a whole accepts this kind of abuse, no matter industry or circumstances, is beyond me. It's an abuse of power. If anybody did this to anyone, the only appropriate response should be to walk and never come back. Nobody would want to accept this kind of crap from family and friends, so why is it ok in a professional setting? Because of the money/power dynamics at play? We need consensus in society to walk, that would end it in no time.

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

#93
post #79

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…

> (syntax-rules ...) The very first time I tried to use it, I ran into its limitations syntax-case is the general purpose construct to use. syntax-rules is a restricted, easy-things-should-be-easy construct. https://www.scheme.com/tspl2d/syntax.html

You don't need syntax case to do advanced things though. Alex shinn's match.scm uses all the dirty syntax-rules trick.

It is pretty awful to write things like that.

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

#94
post #90
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…

People do it in Clojure all the time in the dev setup. And you technically can do in your customer environments too, but it's of course a bit of a cowboy thing to do there.

"Cowboy thing" is putting it mildly. It invites/incentivises terrible behavioral patterns. The next guy looking has no idea what happened to that running system. (That next guy may well be you yourself a week or month later.)

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

#95
post #77

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…

> It's important to emphasize that a particular group of "words" constitutes a function call, or a variable definition, or a type definition -- whatever the language has to offer. Syntax highlighting? Please take a look at https://play.haskell.org/ I am completely baffled by this comment. Are you missing the parenthesized function calls by any chance? If so then I can relate a bit.

No, it's not syntax highlighting.

For background: my first time in college, I was studying typography. An integral part of this trade is figuring out what is easier for people to read by answering questions s.a. what is the best line length, what number of columns per page is the best, what number of ascent elements per font face is the best, considering letter frequencies and coincidence and so on.

It also comes with the editing part, as in the trade of taking a manuscript (a text intended to be published) and making sure that the text meets certain reader expectations in terms of consistency, clarity, structure. This, obviously, includes the use of punctuation, but it's more about the language structure, things like adjectives order or anaphora usage etc.

Programming languages can be judged using the same rules, because, in the end of the day, we read them and need to interpret them. People have particular strengths and weaknesses when it comes to reading: we can remember the anaphora's anchor for only so long, we can hold only so many "variables" in fast-to-access memory, we only can do so many levels of adverb phrase nesting and so on.

Haskell was designed by someone completely oblivious to human abilities to read. It's very demanding and straining when it comes to extracting structure from text in the same way how, in English, you'd struggle to extract structure from so-called "garden path" sentences, because it's intentionally obfuscated. I don't believe Haskell is intentionally obfuscated, instead, I attribute the poor performance to the lack of awareness on the part of the author.

To convey the same point by means of example: Haskell is almost uniquely bad in that given a program

    A B C
the programmer can't tell if the program is actually A(B, C), or B(A, C), or C(A, B), or A(B(C)), or A(C(B)), or (A(B))(C), or (B(C))(A), or (B(A))(C), or (C(B))(A).

There's absolutely no reason a language should offer these kinds of puzzles, especially in a very large quantity as Haskell does. Removing this "feature" would make the language a lot easier to work with.

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

#96
post #79

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…

> (syntax-rules ...) The very first time I tried to use it, I ran into its limitations syntax-case is the general purpose construct to use. syntax-rules is a restricted, easy-things-should-be-easy construct. https://www.scheme.com/tspl2d/syntax.html

It's just not good because you need to work around its limitations, whatever its purpose is. Not good for prototyping because it's the red tape you need to cut to get work done. Red tape isn't, in general, a bad thing, but when it comes to prototyping it is.

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

#97
post #77

Earlier quoted context omitted.

> It's important to emphasize that a particular group of "words" constitutes a function call, or a variable definition, or a type definition -- whatever the language has to offer. Syntax highlighting? Please take a look at https://play.haskell.org/ I am completely baffled by this comment. Are you missing the parenthesized function calls by any chance? If so then I can relate a bit.

No, it's not syntax highlighting. For background: my first time in college, I was studying typography. An integral part of this trade is figuring out what is easier for people to read by answering questions s.a. what is the best line length, what number of columns per page is the best, what number of ascent elements per font face is the best, considering letter frequencies and coincidence and so on. It also comes wit…

Mmm.I think I understand where you are coming from. You can write incomprehensible code in Haskell very easily and I agree that some people tend to write Haskell in a way that is easy when writing but very hard during reading.

But that is a choice. I prefer not using complex function compositions and the lenses due to this, split complex expressions into a bunch of let bindings etc..

So you also can write very readable code in Haskell.

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

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

A common workflow is to run code to test some function in the REPL and then promote it to a test when you are ready, and this process has been the smoothest in lisps, especially since you can create your own test harness if you need to.

Fun fact is that giving AI repls also reduce error rates so much that you can save up to half the tokens/time or more.

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

#99
post #89
post #57

Earlier quoted context omitted.

When I learned Scheme, I liked the language but strongly disliked macros and quotation. I'd only been using it a short while and when I searched for solutions to a few problems these "fexpr" things kept appearing up, which i didn't understand, and this "Kernel" language. I decided to learn it since "fexprs" were apparently the solution to several of my problems. This wasn't easy at first - I had to read the Kernel Re…

Think of macros as what you want when you want to perform computation at compile time rather than run time. An example: building the equivalent of a switch statement, but that compares (via string equality) with a set of strings. The macro would translate this into code that would do something like a decision tree on string length or particular characters at particular positions. Basically anything that's done with a…

The other motivation for me is to drastically reduce boilerplate code. I can’t believe people here are saying they never use macros, they are so good for this that avoiding them sounds to me like a skill issue! Overuse can damage readability, sure, but so can pretending macros are not an option.

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

#100

Earlier quoted context omitted.

Sometime back 15 years ago [0], I hit a bit of an existential crisis regarding my career and the kind of work I was doing. I thought the particular technology I was working in was "part of the problem", as I felt pigeon-holed by .NET and C# to always be a corporate-monkey CRUD consultant. So, I went out in search of something better. Different programming languages. Different environments. Just something that wasn't…

> [...] who thought it was okay to yell at people about [...] That society as a whole accepts this kind of abuse, no matter industry or circumstances, is beyond me. It's an abuse of power. If anybody did this to anyone, the only appropriate response should be to walk and never come back. Nobody would want to accept this kind of crap from family and friends, so why is it ok in a professional setting? Because of the mo…

> Nobody would want to accept this kind of crap from family and friends

Hm… I think I have bad news for you.

Post reply on HN