APL Interpreter – An implementation of APL, written in Haskell (2024) • Hacker News Board

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

#71

Post by simonmic » Sat, Jun 07, 2025, 1:46 AM UTC

nickzelei wrote: post #16

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…

It's not just you. There are a ton of resources of different kinds and freshness, and they're hard for a newcomer to find and evaluate quickly, so luck enters into it. Please also try: https://joyful.com/Haskell+minimap

The tools are a bit complex due to the long history and the design choices of other tools, beginning with GHC. Often they are understood only partially, or they are too hard to write about clearly and teach/learn quickly, or they have failure modes that haskellers navigate instinctively but newcomers without support get stuck on.

Like shae I recommend keeping a haskell chat room handy for quick tips, but don't get too sidetracked. The IRC channel has a greater tendency toward intricate language discussions than the matrix room.

ghcup is a good tools manager; stack can also install tools, and has better support for Windows.

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

#72

Post by simonmic » Sat, Jun 07, 2025, 2:05 AM UTC

nickzelei wrote: post #58

itishappy wrote: post #17

Earlier quoted context omitted.

My understanding is that Cabal has more or less supplanted Stack. Use GHCup to install everything, then use `cabal init`, `cabal run`, or `cabal repl` like you would in Go/Rust. Stack builds on top of Cabal, and used to solve a bunch of problems, but the reasons for it's existence are no longer super relevant. It still works totally fine if that's your thing though.

That is so interesting and is a point where GPT has failed me if this is true. My understanding was the stack was the choice due to having better ergonomics over cabal. Apparently that isn't true? I Found that stack init was pretty decent at setting up a project structure, but can't say I tried cabal init. I initially installed ghcup via homebrew but found that did not set things up correctly and had to follow the in…

stack does generally have better UX. cabal hasn't supplanted it (and won't). But each has their strengths, the right tool for the right job.

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

#73

Post by tome » Sat, Jun 07, 2025, 7:11 AM UTC

kccqzy wrote: post #55

tome wrote: post #51

Earlier quoted context omitted.

I have the definitive answer to this question in my article “foldl traverses with State, foldr traverses with anything” https://h2.jaguarpaw.co.uk/posts/foldl-traverses-state-foldr... In short: use foldl’ when you’re iterating through a list with state. foldr can be used for anything else, but I recommend it for experts only. For non-experts I expect it’s easier to use for_. For more details about that see my article…

Is it really easier to use for_? It forces you to think about effects rather than pure data. So you end up packaging data into effects through State or similar monads. So is it really easier if you force people to use Monad (well technically Applicative)?

Yes, absolutely, I would say for almost every programmer, certainly for me. "Scrap your iteration combinators" goes into more detail. foldl' is a bit too simple to replace with for_, but for almost every other use case, yes, I do use for_. In fact, I find it remarkably liberating compared to the "iteration combinator" conventional wisdom that has been passed down from Haskeller to Haskeller over the years.

I don't feel that monads are particularly complicated. I have several non-Haskellers programming in Haskell at work, using monads. They just think they're writing a sequence of statements. I feel that mixing monads is complicated, which is why I recommend an IO-wrapper effect system (Bluefin or effectful), so that you don't need to mix.

https://h2.jaguarpaw.co.uk/posts/scrap-your-iteration-combin...

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

#74

Post by mrkeen » Wed, Jun 11, 2025, 7:09 AM UTC

pierrebeaucamp wrote: post #46

instig007 wrote: post #6

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

> The author clearly mentioned they're new to the language, so calling them a "lost cause" for making a beginner mistake is elitist snobbery.

"Lost cause" was the author's description of the language.

The author didn't take the role of a student and ask how to do something. He took on the role of a teacher to tell others it couldn't be done.

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

#75

Post by pierrebeaucamp » Wed, Jun 11, 2025, 2:58 PM UTC

simonmic wrote: post #70

pierrebeaucamp wrote: post #46

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…

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

fair enough :)