thosakwe

I remember being 11 or so and installing this homebrew onto my DS...

I had NO IDEA what Linux was at the time, but DSLinux helped me deepen my interest in computer science.

So, thanks to the creators, and everyone who contributed code.

In my humble opinion (I'm still new to Haskell), the best way to do that is to contribute to existing Haskell tooling.

That's something I'm looking into doing myself. It would be great to help improve tools like cabal and the haskell-language-server.

I think that will go a long way towards making Haskell more beginner-friendly, and easier to use in production.

You make a valid point about the added complexity of combining parser combinators with functors and other concepts.

Honestly, if I were writing a compiler, I would go with your approach as well.

Correct, that function doesn't have to parse immediately, but it does have to be aware your monad exists.

This isn't a problem if you're the one writing the function, but if you're using a 3rd party library that doesn't know about your monad, then fmap can be very useful.

Yes, but if it we're talking about parser monads, then usually you can't apply a function directly to a parser's result without either:

1. Being within the same monad. For example, you can `bind` a `Parser a` to a function only if it returns `Parser b`.

2. Performing an actual action and breaking it out of its monad.

For example, if you're using the Parsec library, and you have a `Parser Int`, you can't get to that int without using a function like `parse`, performs the actual action of parsing input text.

With a functor, you can compose a `Parser a` within an `a -> b` function, instead of having to return `Parser b` in your function.

So if you have a `Parser Int`, and you want to turn it into a parser that multiplies its parsed input by 2, you can write `fmap (*2) myParser`, instead of having to write `myParser >>= \a -> return (a * 2)`.

Parsers being functors means it's easier to compose them with other things, without having to actually perform the parse until you need to.

I learned Haskell this year.

After reading this article, the conclusion I drew was, "Cool, so I can `fmap` over my parser now and transform what I parse using functions."

To answer your other questions: I'm not sure it means much for the code that does the actual parsing, nor how you specify the grammar's rules, it's more about being able to transform the output using functions.

If your static analyzer is a function, you could now write `fmap staticAnalyzer myParser`.

Thanks for sharing this great article. It explained lenses very clearly, without me having to read a paper first.

Another reason is that imperative languages have a lot of business inertia around them. It's expensive to rewrite existing code or switch to a new language, and most businesses can't justify this cost.

I love functional programming, but I doubt most companies that sell CRUD apps care about it.

I read "Start Small, Stay Small" in 2021. More modern advice is on YouTube instead of books. Try channels like Noah Kagan, or Microconf.

Seeing so many new languages running on WASM is exciting. I wonder if we'll see a language with a just-in-time WASM compiler soon...

I maintained a project like this for several years. My genuine advice to anyone considering creating an open-source library: either keep it super small forever, or make it closed-source + charge for licenses.

I wonder why tree-shaking wasn't always the default for, say, JS bundlers. If a compiler/analyzer knows what the entry point of a program is, as well as any symbols it exports to the outside world, isn't it relatively simple to figure out what's not being used?

I could be misunderstanding something.