News for hackers. Stuff that matters.
Re:Solving `UK Passport Application` with Haskell by tikhonj on Sunday June 29, 2025 @01:15AM (#44410532)
At some point, I did a rough count, and the number of operators you encounter in "normal" Haskell code—avoiding lens or domain-specific libraries—was pretty close to the number of operators you'd encounter in, say, JavaScript. This was a while ago and I don't want to redo the exercise now, but, even if we're being generous to JavaScript, practical Haskell needs on the order of 2x as many operators as practical JavaScript, not 10x.

Haskell has some up-front incidental complexity, but it's a difference of degree not kind from popular starting languages. It's easy to underestimate how much you had to learn about Algol-style languages that you've just internalized so well that you don't even realize. I've taught some complete programming beginners (high or middle schoolers) Java and Python and, especially one-on-one, I've seen how they get confused by things I did not even remember required explanation!

For example, in Python, people put : in the wrong place and don't understand how = works. "Basic" syntax like : and = are far more complex than we realize, we've just learned the basics so well that it's second nature. It's similar to how native English speakers don't even realize we have rules for adjective order ("big red ball" vs "red big ball"), while language learners run into it like a brick wall.

Re:Solving `UK Passport Application` with Haskell by ngruhn on Sunday June 29, 2025 @03:09AM (#44410908)
I don't know if you just counted the JavaScript operators but if you count all the instances where some random symbol is used then it's really a ton. There is

    yield*
    function*
    a?.b?.c
    function f(x = 3) {
    x ??= 3
    ...
TypeScript adds even more:

    a!.b
    Type<T>
    type A = B extends C ? D : E
    ...
    
and there are countless ECMA proposals and TypeScript feature request that want to pile on even more. People seem to have zero qualms about cryptic syntax. I think the difference is that this syntax is mostly very ad-hoc. If you know the language already, this just adds a liiiittle bit extra to solve some very specific problem. On the other hand, Haskell operators like <$>, <*>, >>= are extremely general. After years I still learn about new and unexpected ways that you can use them (e.g. what the hell is `fix <$> id`). But paradoxically, because they can be used in so many seemingly unrelated contexts, you have no idea what to use them for at all initially.
Re:Solving `UK Passport Application` with Haskell by dmead on Sunday June 29, 2025 @01:20AM (#44410542)
Combinator style, while good and well designed and all they only ended up inventing the next perl.

#haskell on freenode in the 2000s was a really fun place. I could not for the life of me convince anyone else to use the language.

Re:Solving `UK Passport Application` with Haskell by tomsmeding on Sunday June 29, 2025 @04:12AM (#44411206)
The IRC channel still exists! It's on libera.chat now, though.
Re:Solving `UK Passport Application` with Haskell by gylterud on Sunday June 29, 2025 @03:38AM (#44411031)
Oh, I owe a lot to freenode and #haskell and #math in particular. I remember one of them ran a lecture on category theory, live. It was also there I first heard about Martin-Löf type theory.

It was such a great time and place for a young person interested in learning about Haskell.

Re:Solving `UK Passport Application` with Haskell by dmead on Sunday June 29, 2025 @06:37PM (#44417223)
Do you remember who ran it? I used to go to hack phi at UPenn, which attracted a significant chunk of the community.
Re:Solving `UK Passport Application` with Haskell by gylterud on Monday June 30, 2025 @02:07AM (#44419950)
The lecture? No, unfortunately.
Re:Solving `UK Passport Application` with Haskell by eru on Sunday June 29, 2025 @02:11AM (#44410690)
Combinators (in the Haskell sense) have nothing to do with whether you write your functions with letters or with comic book swearing.
Re:Solving `UK Passport Application` with Haskell by librasteve on Sunday June 29, 2025 @02:22AM (#44410730)
err, no

the perl6 guys ended up inventing the new perl (now renamed raku)

https://rakujourney.wordpress.com/2024/10/12/raku-burritos/

the first perl6 parser (pugs) was written in Haskell btw

Re:Solving `UK Passport Application` with Haskell by dmead on Sunday June 29, 2025 @09:25PM (#44418269)
I'm aware. I was using the world pejoratively. Combinator style degrades into line noise.
Re:Solving `UK Passport Application` with Haskell by librasteve on Monday June 30, 2025 @04:44AM (#44420920)
no doubt its fashionable to think "perl == line noise == bad"

however, there are certain sub languages (slangs) where the use of punctuation chars as operators is very helpful, of course regex is the most compelling where the code is parsing one char at a time

  my regex url {
    ^                                # Start of line
    [<http> s? '://']                # Match http or https
    ['www.' ]?                       # Optional www.
    [<[\w\-]>+ '.' ]+                # One or more domain segments
    <[a..z]> ** 2..6                 # TLD, 2 to 6 lowercase letters
    [ '/' <[\w\-./?%&=]>* ]?         # Optional path/query
    $                                # End of line
  }
imo raku has improved the situation a lot by introducing "regex 2.0" with deep support for unicode and with built in grammars that can work smoothly with regex
Re:Solving `UK Passport Application` with Haskell by dmead on Monday June 30, 2025 @03:10PM (#44426795)
Ahh not sure I agree. The reputation for being unreadable is pretty well deserved. It didn't happen for no reason.
Re:Solving `UK Passport Application` with Haskell by librasteve on Monday June 30, 2025 @03:56PM (#44427177)
ok - I agree that there was a culture of golfing and obscurity in some sections of the perl coder base

it was inevitable that a simpler language - Python - would take the big slice of scripters who wanted something easier to learn and to read

I'm sad that perl no longer has a credible niche for script level coders who want to learn a more powerful and more expressive language than Python ...

Re:Solving `UK Passport Application` with Haskell by skybrian on Sunday June 29, 2025 @07:53AM (#44412356)
I think that’s true as far as it goes, but there are further reasons why Haskell is more difficult. Here is one:

In Haskell, the lack of parentheses for function calls plus currying means that to read a function call, you need to already know how many arguments the function takes, which I feel adds a new level of difficulty over languages where you can often guess what a function does based on its name, without looking it up.

As a result, often Haskell reads more like math, where without knowing each symbol’s definition, you’re lost.

I’ve seen cryptic JavaScript too, but less often.

Re:Solving `UK Passport Application` with Haskell by jameshh on Sunday June 29, 2025 @08:33AM (#44412590)
> the lack of parentheses for function calls plus currying means that to read a function call, you need to already know how many arguments the function takes

While I agree with the general sentiment of what you are saying, note that the syntax has nothing to do with it, it is purely about Haskell using currying excessively. The syntactic translation between Haskell and JS is straight-forward and 1-1:

    f x y z      ->  f(x)(y)(z)
    f x (y,z) w  ->  f(x)(y,z)(w)
I agree that excessive currying is not great, and generally push for non-curried arguments unless a curried form realy is used in practice. But for this to really be comfortable, and to still enjoy all the hgiher-order programming that's nice with Haskell, we would need good records (strucural, anonymous, extensible), which it doesn't really have right now, so we are stuck with currying.
Re:Solving `UK Passport Application` with Haskell by skybrian on Sunday June 29, 2025 @10:54AM (#44413653)
Yes, you could write the same thing, but defaults and language conventions matter. Writing curried functions in JavaScript is awkward enough that nobody does it by default. If you did, people would ask why in a review.
Re:Solving `UK Passport Application` with Haskell by IshKebab on Sunday June 29, 2025 @10:22AM (#44413399)
> practical Haskell needs on the order of 2x as many operators as practical JavaScript, not 10x.

Yeah but the JavaScript operators are almost all universally understood. There are some exceptions and mistakes, like `===` which shouldn't exist, and `.?` which is new but fairly standard. But most of the operators are just standard maths stuff, normal array/field accesses, etc.

Haskell has normal operators plus a bunch of weird operators that you need to learn. Even if the raw number of operators is only 2x, the number of operators that you have to learn is probably 10x.

Especially when you consider that Javascript operators are fixed so you have to learn them once, whereas Haskell operators are user-defined and Haskell programmers love defining them.

Re:Solving `UK Passport Application` with Haskell by cbsmith on Sunday June 29, 2025 @10:52AM (#44413635)
I still don't understand equality in JavaScript. ;-)
Re:Solving `UK Passport Application` with Haskell by IshKebab on Sunday June 29, 2025 @12:51PM (#44414488)
The only thing to understand is that you need a blanket ban on `==` and `!=` using ESLint.
Re:Solving `UK Passport Application` with Haskell by endgame on Monday June 30, 2025 @10:43PM (#44430093)
Haskell operators are generally well-chosen to have a consistent visual language:

* $ is "function application" - f $ x = f x, but lets you elide nested parens: f $ g $ h x = f (g (h x))

* & is "reverse function application" x & f = f x. This reads nicely in pipelines as "and"

* <$> is "fmap" what is like a lifted application over a structure: f <$> [1, 2, 3] = [f 1, f 2, f 3]

* <&> is "reverse fmap", which is nice when you have a big lambda

* Anything in <_> brackets is generally a "lifted" version of some operator

* And so on