bitmapper

It would be, if the code wasn't so horrifically bitrotted at this point. GHC has changed a lot since Elm last got any meaningful update, and they decided to use unsafe GHC primitives everywhere that have no support guarantee. You have to fix a bunch of issues with the compiler source before it will even compile on a relatively new version of GHC.

this got replaced with ghcup iirc

What do you mean the function to create a directory? When would you be creating directories outside of derivation build phases?

I find the options search to be generally suitable for that case https://search.nixos.org/options

This is just a ChromeOS tablet except it's running a customized version of ChromiumOS?

There's cadmium there, yeah. But cadmium is not addictive, and is not a reason for cigarettes being addictive. Removing the cadmium will not make cigarettes less addictive.

Tobacco plants pull metals in from the soil, which includes cadmium, and radioisotopes of polonium and lead.

For simple languages, it can be a bit of a pain to write and maintain a lexer and a parser. For example, if I'm gonna parse JSON and nothing more, I think it's a bit silly to use a two external DSLs when I could use a simple eDSL. I think Happy and Alex both have their places, absolutely. For parsing full on programming languages I can imagine using parser combinators to be a bit painful. But parser combinators work great for a lot of cases.

https://hoogle.haskell.org/ can be helpful for this

I'm really not a fan of IHP for that purpose due to how it redefines so much of the Haskell Prelude without making it clear it does that.

I don't really think many people are calling it a panacea. From my experience in the community most people I know who write Haskell write it for productivity reasons (including me, I'd rather be using Idris 2 with algebraic effects though.)

I'm not saying it's somehow magically more productive than other languages, because it's useless to throw around stuff you can't really prove like that, just some people find it to be the case.

I've never found "everyone writing their own DSL" to be problematic, because it's all exposed through the Monad/Applicative/Functor classes, so the way you use them are all very similar. Honestly, the usage of such eDSLs is one of my favourite parts of writing Haskell.

I use Haskell at my work for our main application, and we've been looking at adopting a style guide like https://kowainik.github.io/posts/2019-02-06-style-guide

And about interesting applications in Haskell, I'd consider https://hasura.io/ pretty interesting!

EDIT: And about language extensions, yeah, they can be a problem. What we do is settle on a base set of extensions, and if you want to use another one, you need to provide sufficient justification for it.

I personally don't like Rust (I like to have a garbage collector for what I do), but I don't think it's a hard to read language.

Readability is an incredibly subjective thing. For example, APL might look like an absolute mess to most people but to the people who know it, it's incredibly easy to read. All "readability" means in this context is that it's familiar to you.

In my opinion, the only truly hard to read languages are languages that require you to keep large amounts of context in memory while reading a specific part of the codebase, be it due to lack of support for abstractions for proper encapsulation, messy overloading, insane inheritance hierarchies, or something else.

EDIT: Readability also requires you have a codebase that's well written, and even that's subjective.

Parametric polymorphism is even older than that! It's almost 60 years old, having originated in CPL.

Honestly, my main issues are with the lack of generics and the "dynamically typed effect system". The idea of a minimalist runtime and language reminds me of Clean a little bit.

Fair enough! Sorry, I didn't intend that to be rude, I just genuinely didn't understand as it seems to be two very conflicting ideologies merged.

Since when are generics automatic casting?

I cannot comprehend what would drive someone to make this.

Yeah! I worked with Robert Smith on porting it to modern CL implementations.

Not a fun codebase.

I used to use CL quite a bit, but have since abandoned it for Haskell, so I'm a bit biased.

There's a number of issues with that:

- I'd be missing all the optimizations that can be performed due to purity.

- There's more to Haskell's type system than just vanilla Hindley-Milner, and the implementation of it isn't particularly trivial. https://github.com/stylewarning/coalton is the closest thing and it's still missing a large amount of the type system.

- Doing the implementation would be a significant amount of work to get it to integrate well with the language, and it would be a layer tightly glued on top instead of integrated with the language. I've seen many good DSLs embedded in lisp, but a type system is hard to embed in any language because it changes fundamental semantics of the language. Typed Racket is a massive project and it's lacking things like ADTs.

- A major part of Haskell is the standard library, a good chunk of the semantics of Haskell people use on a day to day basis, like monads and etc, are a part of the standard library.

And then when things like dependent types get involved, I'm betting that the amount of bugs greatly decreases, even more than that.

eh, iirc fused-effects is used in production, along with haskell (obviously)

I already brought this up with them, they knew about it but decided that it "doesn't have enough usage so we aren't worried about people getting our product confused with it".

My favorite example of this is probably Clean, which solves this using uniqueness types. You can have unique values that are managed using compile time memory management, but also are free to use garbage collected values.

It makes for a very performant pure functional language. My only gripe is that the stdlib is abysmal, and hardcoded into the compiler.