Interesting read! On a semi-related topic: I tried learning Haskell this past weekend out of curiosity that I last tried it some 10+ years ago while still in college. I found resources for it scant. Coming from more modern languages/tooling like Go/Rust, I also struggled quite a bit with installation and the build/package system. I tried the stack template generator for yesod/sqlite and after some 15 minutes of it in…
The easiest and fastest way to get everything installed is ghcup https://www.haskell.org/ghcup/ As for being successful, there are several nice books, and several active forums. I've gotten good answers on the Libera IRC network #haskell channel, and on the Haskell matrix channel #haskell:matrix.org If you want to get started without installing anything, there's the exercism track: https://exercism.org/tracks/haskell…
APL Interpreter – An implementation of APL, written in Haskell (2024)
61–70 of 75 posts
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#62Seeing "all built-in functions and operators are single unicode symbols" stood out to me, given that APL existed well before Unicode did. It's not that it's wrong today, but that wasn't always the case. My father used APL back in high school, and that was before the earliest year mentioned in the "History" section of the Unicode Wikipedia article.
It wasn’t Unicode but it wasn’t ASCII either. I think here unicode is probably shorthand for not ASCII.
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#63Earlier quoted context omitted.
Usually you want `foldl'` (with ' at the end), the strict version of `foldl`. It prevents the creation of intermediate thunks, so effectively a tail recursive iteration over the list in constant space. `foldr` I almost never use, but it would be for: the return value is a lazy list and I will only need to evaluate a prefix.
The naming conventions are nicely sadistic.
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#64Earlier quoted context omitted.
> When the dude uses `foldl` over lists and `foldr` with `(*)` (numeric product) it is not the language that's the lost cause. This is a great example of Haskell's community being toxic. The author clearly mentioned they're new to the language, so calling them a "lost cause" for making a beginner mistake is elitist snobbery. I usually don't point these things out and just move on with my life, but I went to a Haskell…
Can I ask which conference? Did people behave towards you in that way at that conference, or are you referring to behaviour online? I will try to use whatever authority I have in the Haskell community to improve the situation. (Still, hopefully in this case it's clear from instig007's reply that it's not a member of the Haskell community behaving in that way.)
The conference I mentioned was ZuriHac. After the key-note Q&A there was a small hallway discussion around how to grow the adoption / reach of Haskell. The conversation revolved around mostly technical points (like how Haskell is superior to x, because of y). What I found interesting was that there was little to no talk about the steep learning curve, developer ergonomics or business use-cases.
The thing is, if someone has not yet learned about functional programming, strong type systems or category theory, why / how would they see the advantages or the power of pure functions, lazy evaluation, Monads, etc. At the same time, their opinions or struggles are often dismissed due to their lack of knowledge. The parent comment is a prime example of this.
Edit: This is a great 10-minute talk that touches on the general topic: https://www.hytradboi.com/2025/419859c5-6a8f-4a49-b324-0f225... She covers a lot of this better than I can.
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#65Interesting read! On a semi-related topic: I tried learning Haskell this past weekend out of curiosity that I last tried it some 10+ years ago while still in college. I found resources for it scant. Coming from more modern languages/tooling like Go/Rust, I also struggled quite a bit with installation and the build/package system. I tried the stack template generator for yesod/sqlite and after some 15 minutes of it in…
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#66Earlier quoted context omitted.
The naming conventions are nicely sadistic.
This is what happens when you let Mathematicians name things on chalkboards. They don't want to run out of chalk and they get tired of spelling whole words very easily so they use short names and silly symbols. The name foldl' is "just" "fold left prime". Remember ' means "prime" from calculus class and thinking that was silly even then? Accidentally infected Haskell at a young age.
Doubly so with APL!
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#67Earlier quoted context omitted.
The naming conventions are nicely sadistic.
This is what happens when you let Mathematicians name things on chalkboards. They don't want to run out of chalk and they get tired of spelling whole words very easily so they use short names and silly symbols. The name foldl' is "just" "fold left prime". Remember ' means "prime" from calculus class and thinking that was silly even then? Accidentally infected Haskell at a young age.
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#68Earlier quoted context omitted.
This is what happens when you let Mathematicians name things on chalkboards. They don't want to run out of chalk and they get tired of spelling whole words very easily so they use short names and silly symbols. The name foldl' is "just" "fold left prime". Remember ' means "prime" from calculus class and thinking that was silly even then? Accidentally infected Haskell at a young age.
Yeah it's definitely unusual to allow ' to be part of the name of a variable, especially considering that it is, like C, the quote for character types.
Aside: I've got half a feeling you could implement an APL-like directly in Haskell as a DSL using Unicode-named functions. I've seen Unicode Haskell files that look like APL (and GHC supports a surprising amount of that almost out of the box, as I recall).
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#69> Apparently Haskell’s performance isn’t that bad, but I don’t plan on using Haskell for anything that is remotely performance-sensitive. Trying to optimize Haskell code does sound like an interesting problem, but it might be a lost cause. When the dude uses `foldl` over lists and `foldr` with `(*)` (numeric product) it is not the language that's the lost cause.
> When the dude uses `foldl` over lists and `foldr` with `(*)` (numeric product) it is not the language that's the lost cause. This is a great example of Haskell's community being toxic. The author clearly mentioned they're new to the language, so calling them a "lost cause" for making a beginner mistake is elitist snobbery. I usually don't point these things out and just move on with my life, but I went to a Haskell…
Re: APL Interpreter – An implementation of APL, written in Haskell (2024)
#70> Apparently Haskell’s performance isn’t that bad, but I don’t plan on using Haskell for anything that is remotely performance-sensitive. Trying to optimize Haskell code does sound like an interesting problem, but it might be a lost cause. When the dude uses `foldl` over lists and `foldr` with `(*)` (numeric product) it is not the language that's the lost cause.
> When the dude uses `foldl` over lists and `foldr` with `(*)` (numeric product) it is not the language that's the lost cause. This is a great example of Haskell's community being toxic. The author clearly mentioned they're new to the language, so calling them a "lost cause" for making a beginner mistake is elitist snobbery. I usually don't point these things out and just move on with my life, but I went to a Haskell…