In general, I am turned off as well from the abstractionauts in the software world, particularly those found in the Haskell realm, and highly prefer more pragmatic functional languages like F#, Racket, and Elixir/Erlang.
In general, I am turned off as well from the abstractionauts in the software world, particularly those found in the Haskell realm, and highly prefer more pragmatic functional languages like F#, Racket, and Elixir/Erlang.
I’ve worked on software in a few different industries, but the ones that needed particularly good reliability were mostly related to hardware deployed in challenging environments. For example, it’s never good to discover a bug in production when your firmware update process involves helicopters. :-) I’ve also worked on software that used quite intricate data processing algorithms, where any bugs could manifest as subtly incorrect behaviour that might not be noticed until it was too late and some serious failure had been caused.
I didn’t specifically pursue these kinds of projects, they just happen to be common themes in the roles I’ve taken over the years. In time, I developed an interest in tools and processes for producing software that is significantly more reliable than much of what our profession produces, yet not necessarily on the level of say threat-to-life or running-a-satellite code where extreme measures might be justified almost regardless of cost. I firmly believe that even with the inevitable pressures driving commercial software development, the standards in our business could be much higher than they often are today, and that much of the problem is due to people — developers, managers, users — not realising what else is achievable or what it would really cost.
Is there any way you can give examples of this in Haskell?
If I'm just blind to them by now I'd like to know, but most "abstractionaut" criticisms I've heard seem to ignore the pragmatic ideals driving the reasons for the abstraction and ignoring inherent complexity.