Live data from Hacker News

APL Interpreter – An implementation of APL, written in Haskell (2024)

scharenbroch.dev

61–70 of 75 posts

Re: APL Interpreter – An implementation of APL, written in Haskell (2024)

#61
post #18

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…

Appreciate the resources!

Re: APL Interpreter – An implementation of APL, written in Haskell (2024)

#62
post #29

Seeing "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.

Unicode inherited most of APL's encoding sets from EBCDIC code pages. Almost no one would choose to work in EBCDIC today, so it is practical to just say Unicode as the last encoding left standing (for everyone not working on legacy APL code on [emulated] IBM mainframe hardware).

Re: APL Interpreter – An implementation of APL, written in Haskell (2024)

#63
post #43

Earlier 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.

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)

#64
post #53

Earlier 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.)

This is almost exclusively just online behaviour. Everyone I met in person is very nice :).

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)

#65

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…

I loved the book "Real World Haskell" [1] when it first came out in 2008. It feels like a shame it hasn't aged well and there hasn't been an updated edition since then. Especially because it was focused on things like "here's how you build example web services" as a good place to discuss everything else by having the end goal of the book's "narrative" structure be real world things you might build. It may still help to glance at a little, but things have advanced so much in the decade and a half since the book was written it is hard to recommend, but it still feels like there should be a book like it updated for current day to be out there to more heartily recommend. If there is one I don't know of it, but I haven't followed Haskell as much as I'd like in my professional career.

[1] https://book.realworldhaskell.org/

Re: APL Interpreter – An implementation of APL, written in Haskell (2024)

#66
post #43

Earlier 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.

> This is what happens when you let Mathematicians name things on chalkboards.

Doubly so with APL!

Re: APL Interpreter – An implementation of APL, written in Haskell (2024)

#67
post #43

Earlier 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.

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.

Re: APL Interpreter – An implementation of APL, written in Haskell (2024)

#68
post #67

Earlier 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.

In Haskell's case that is indirectly Lisp's fault. Lisp heard of Algol (C's design-by-committee "grandparent" on the family tree) identifier restrictions and thought they were silly. (I think Lisp is also often classified as Haskell's great-grandparent on the family tree? Lisp -> Scheme -> ML -> Haskell, I think?) As with most of that FP family the boundary between "operator" and "identifier" is real thin to nonexistent.

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…

[deleted]

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…

I don't question your experience but I think this is not a great example of that. That was a random HN commenter, not Haskell's community (which is quite large and diverse).
Post reply on HN