As both a mathematician and a programmer who often works on projects where high reliability is essential, I want to like the concept behind this book. However, based on the website and sample chapters, it’s not clear that there will be strong arguments made here about either scalability or performance, which are the usual practical problems with trying to employ formal methods and very “mathematical” abstractions. Sadly, the early repetition of the usual faux quicksort example and the casual dismissal of arguments by “purists” about the difference is going crush the author’s credibility among a large group of programmers by the end of page 7, which is not a good omen.
> However, based on the website and sample chapters, it’s not clear that there will be strong arguments made here about either scalability or performance
I've read most of it, performance is addressed after correctness.
The trick is that your correct API never has to change to get better performance.
I don't want to give too much away though and I highly recommend this book.
Do you mind sharing what industry you work in and how you got there? I am mainly caught by "as both a mathematician and a programmer who often works on projects where high reliability is essential". I was a mathematician (or more strictly am a failed mathematician) who also does software, and so I am always curious what other domains people with this background work in.
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.
Do you mind sharing what industry you work in and how you got there?
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.
> I am turned off as well from the abstractionauts in the software world
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.
