Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I still reach for Lisp and Scheme instead of Haskell

jointhefreeworld.org

Post reply on HN
Print view View original

111–120 of 172 posts

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

#111

Post by vintermann »

openuntil3am wrote: post #36
crabbone wrote: post #21

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…

Your criticism of Haskell is entirely subjective. There are lots of people, myself included, that like and prefer Haskell's syntax.

There aren't a lot of Haskell programmers, so "lots" is maybe an exaggeration.

I see OP's point. Haskell feels (or felt, I admit I haven't been keeping up the last 15 years) needlessly obtuse sometimes, like how people love to invent new infix operators all the time.

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

#112

Post by Skeime »

T-R wrote: post #68
floxy wrote: post #58

Earlier quoted context omitted.

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…

I feel like you are describing that the parser is too lenient rather than too picky. It could just require you to always put `let` and `in` on their own lines, in which case the indentation makes sense, I think. It's only when trying to keep more stuff on the same line that the details of Haskell's indentation rules come into play.

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

#113

Post by attila-lendvai »

ggm wrote: post #2

> Actually, in my opinion, Scheme (and Lisp) allows you to express complex systems and problem domains in more simple terms than any other language can. Short article. Worth reading. But all I swallowed was this one sentence. Its the sytax. If you like semicolons, thats why you like Pascal-like languages.

it's not just the syntax. the entire language, and even the ecosystem in general, has relatively few atoms that can be combined with a higher degree of freedom than the alternatives.

it has both upsides and downsides. the upsides mostly win for me.

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

#114

Post by mchaver »

spockz wrote: post #84
galaxyLogic wrote: post #80

(In Haskell) > just adding a simple print somewhere is not going to work without refactor Interesting. How do people cope with this in practice? Does it mean you can't really use log() -statements for debugging?

You could wrap it in an unsafeIO function to make it return `()` again. However, I’ve had very little use of printing for debugging. In Haskell you write small (ish) and pure functions that you can test extensively with property based testing. The types already help a lot as well. So basically the only place where you deal with unexpected input is at the communication boundaries of the app where you are in some form…

That's fine for a library or locally run executable, but I've worked on distributed systems in Haskell and you really need logging in place to track what is going on.

Of course, you will have IO somewhere in a executable where you can handle logging so just separate pure and IO and make sure you have good tests for the pure functions. Also, linting to catch partial functions and dangerous lazy ones (or use an alternative prelude).

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

#116

Post by shawn_w »

shawn_w wrote: post #74
privong wrote: 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…

That sort of hotfix workflow isn't really a thing in Racket or Scheme in general. Changing the definition of a function doesn't update everything else that calls that function like it does in CL. Maybe emacs lisp works that way?

You know, after some testing with a bunch of different scheme implementations, I take back what I said, at least for working in a REPL.

    (define (displayln msg) (display msg) (newline))
    (define (inner x) (+ x 1))
    (define (outer x) (inner x))
    (displayln (outer 5))
    (define (inner x) (+ x 2))
    (displayln (outer 5))
outputs 6 and 7 in every one I tried, not the 6 and 6 I expected.

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

#117

Post by imdoor »

I think I much prefer Haskell DSLs over Lisp macros as the basis for APIs in foreign code. That might be due to my relative inexperience with Lisps, but macros just seem to make all the bad aspects of dynamically typed langues much worse. Looking at some piece of code in isolation, not only is it often impossible to tell what is the type/shape of data that are coming in (as is common with dynamic type systems) but with macros added to the mix I also can't tell what the control flow is. So to understand what a single piece of code is doing, I find myself chasing for hints that are scattered throughout the entire codebase.

Contrast this to Haskell's use of DSLs – although they really can be quite dense sometimes, I feel like, when I get stuck, I can always just dig into the documentation on Hackage, and figure out things from the type definitions (even when explanations in docs are lacking). Though it does require being comfortable with the abstractions being used (monads and such). Rust is similar in this manner but to a lesser extent.

But again, maybe the macro critique stems from my inexperience with them.

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

#118

Post by spockz »

mchaver wrote: post #114
spockz wrote: post #84

Earlier quoted context omitted.

You could wrap it in an unsafeIO function to make it return `()` again. However, I’ve had very little use of printing for debugging. In Haskell you write small (ish) and pure functions that you can test extensively with property based testing. The types already help a lot as well. So basically the only place where you deal with unexpected input is at the communication boundaries of the app where you are in some form…

That's fine for a library or locally run executable, but I've worked on distributed systems in Haskell and you really need logging in place to track what is going on. Of course, you will have IO somewhere in a executable where you can handle logging so just separate pure and IO and make sure you have good tests for the pure functions. Also, linting to catch partial functions and dangerous lazy ones (or use an alterna…

Sure you want logging and tracing (in the RPC sense not Debug.Trace.trace).

Most of this can still be done from IO places where the pure functions collect enough error information bubbling up (e.g. content and line/col of parser errors etc.) to not need ad hoc print statements for debugging.

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

#119

Post by crabbone »

openuntil3am wrote: post #36
crabbone wrote: post #21

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…

Your criticism of Haskell is entirely subjective. There are lots of people, myself included, that like and prefer Haskell's syntax.

This is not what "subjective" means. You can't argue something is subjective because many people don't agree with an opinion.

When someone argues subjectivity (in a negative sense), they need to show that the opinion does not rely on facts, rather it's based on... nothing (feelings).

I offered a very easy way to numerically assess the negative impact of poor language design choices made by Haskell designers. It's not about what I "feel" about the language: in Java, you write three-words program, and you get, usually, a unique interpretation. In Haskell, you write a three-words program, and you get 9 (nine) possible interpretations. It's impossible for a human to examine nine interpretations simultaneously and figure out which of them are valid and might fit the context. So, reading a Haskell program takes longer and requires more effort than a Java program.

Of course, Haskell programmers find ways to adapt to their misfortune. They try to avoid pathological cases (eg. writing four-words programs, let alone five!), they memorize a lot of acronyms and non-typographical symbols that they later use to prune the search for a possible meaning of the program. They invent conventions on top of the bare language design that constrain the search space for possible programs to make their task easier.

It's absolutely possible that after layers of conventions and a long time spent memorizing various acronyms and symbols, Haskell programmers catch up to speed of programmers in other languages: after all, the superficial difficulties with the language might seem like a small price to pay for the access to the language's riches that lay beyond the surface. The language grammar rules cannot account for the entirety of the performance of the programmers who chose to write in the language.

This situation is very similar to the "universal" (claimed, but not in practice) mathematical language, which is extremely difficult to read, write, edit, typeset... yet the tradition of using it prevails and the overwhelming majority of mathematicians use, and prefer using the "universal" mathematical language even though much saner alternatives exist.

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

#120

Post by orthoxerox »

sparkie wrote: post #57
0x3444ac53 wrote: post #30

Earlier quoted context omitted.

For what it's worth, anytime I have written a macro it's usually not because it's needed, but just because I think it'll be fun :)

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…

Which implementation do you use?
Post reply on HN