i've been implementing my wiki system in haskell... types are /far/ too rigid in many circumstances.
to link code from two libraries together, i had to serialize html to string and reparse it with another library, all because their html asts - though the same - used incompatible types of IO.
still going to stick with haskell, because it's the best way to work with pandoc... but it's difficult to trust for serious software development while several libraries work like this.
on the plus side, i can be relatively confident in the code if it typechecks... but this is no replacement for just running the code and correcting afterwards
haskell's laziness means it can't reap the optimization benefits of strict type systems either - such a silly language!
while it's fun to prove things in types, this is not the way to go to just get things done.
@jakeisnt huh! what about the laziness stops it from being optimised? i would have thought that would make it *more* optimisable since a compiler gets more options on when it could run code.
@zens @jakeisnt yeah you can't do superoptimization on a strict language because a strict language definitionally has extra guarantees about execution time and ordering. i think jake is probably just not using the right abstraction for the job, which is admittedly the cause of a lot of inefficiency when working with more expressive tools
@zens @jakeisnt i'm not an expert on haskell but lazy languages have potential for optimization that is actually confusingly/surprisingly effective, such as evaluators based on interaction nets and Lamping etc. proposals for rewriting rules that give the appearance of negative complexity for some functions when fusion occurs
GHC is fairly conservative from a theoretical perspective, mostly because it doesn't really need to be faster and is quite complex
@zens @jakeisnt it leaves a lot on the table in a way that isn't mandated by the language at all, it's just that GHC already has a lot of involved optimization systems. those could probably be replaced in many ways with supercompilation by evaluation plus superoptimization at an evaluation level. I'm saying that just based on a vague understanding of Haskell's semantics and the received knowledge that GHC is complicated, but I presume such a more elegant compiler would basically be clean-sheet
My understanding is that the main bottleneck preventing GHC from doing more optimizations is that it's only compiling & optimizing a single file at a time BEFORE linking. It's pretty easy for GHC to determine where laziness isn't desired, and there's ways to turn off laziness if you need to.
For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).