There's maybe too much focus on elegant and good code, systems that support better correctness, when in reality what works best are systems that have an okay degree of correctness assurance and mainly prioritize iteration and prototyping.
Does Haskell lose this battle?
You shouldnt be attached to code. You should feel able to delete and reiterate without too much hesitation. Does Haskell encourage too much "correctness scaffolding?"
@deshipu does it matter how approximate to "the ideal solution" something is if the effort to approach it barely gets an ROI in terms of time-to-outcome?
@simonmic fantastic advice. I've been avoiding Stack and just using cabal, often with Nix. Do you feel Stack is important for being more productive and getting things released and distributed?
@simonmic Thank you for all this stellar advice. I will try some of it out when I try making a plugin for @dillo, since that should be a relatively small project.
I feel for Haskell to survive it needs to be as easy to put together and get running and distributing as Python and Golang is.
I feel like sometimes the idea of starting a new Haskell project is so burdensome, and there's no real "official" way of doing certain things that actually works consistently (like static binaries) that I sometimes just decide a project's not worth it.
We're also in the age of AI now where it's like everything is reduced to glue.
Is there any future in languages like #haskell where AI makes code a factor of small frequently and easily replaced glue and scraps, where whatever is most trained on and most hackable, most easily replaced/iterable is king?
Are big pieces of software that benefit from the architectural assurances Haskell brings a dead paradigm?
AI is here to stay and I feel if something was not already in or out of orbit, it may never reach escape velocity