> Which I explicitly stated would not be happening in my example. In reality, you couldn't just use "sort", you'd need to make sure it was a sort with the right behavior.

I'm pretty sure most experienced software architects would not approve this as a robust approach. Notice that this is a property that actually matters, and it's not captured in the type system (most things aren't).

>>just because the type system doesn't know that the list is non-empty (which I assume here).

>In modern haskell there is a type where the list is statically known to be non-empty.

Sure, go ahead and add another type to make everything more incompatible... no, this approach doesn't work out in practice. There are much more invariants than you can hope to capture with new types in any practical project.

> I personally hope Haskell keeps periodically breaking backwards compatibility until they fix more of the ugly parts of the standard. I'd hate to see it go the way of Java and be stuck with a hideous e.g. file access model because that's what the very first release had.

I absolutely agree with you that everybody should strive to improve their own stuff. But with public, standard libraries, it's a different thing. You simply can't afford to have a hard dependency on stuff that breaks randomly. From an economic perspective, it's much, much simpler to just write your own getMin routine without any dependencies at all. It's not rocket science. And the practical gains by some vague idea of "type safety" for this little procedure are nearly zero.

> I find such a function not remotely clear and definitely not better engineered.

> * It's using a "for loop" so it could be a filter, fold, map or any combination of those. I can't know without reading it.

This is just not true. Almost any beginner to programming can understand this immediately, it's not much effort to understand this to almost anyone. Contrary to the Haskell version (the more realistic one - the one I listed). The average time to ramp up any beginner to understand the Haskell version, and the average time to anyone already competent enough to figure this ad-hoc thing out, is much higher.

Do not think that just because there is a for loop this is somehow wrong. There is a simple statement below the for loop and everyone can immediately spot what happens there (it's a "fold", if you like to think in these terms. That was not hard). Any suggestion to the contrary, that's just zealotry.

> * The function this proposes to replace was able to find the max of any type which can be ordered. This proposed replacement can only do ints. Given the radically reduced scope, the typing is sufficient but you won't have to add many features before the C compiler simply cannot help you anymore. Haskell's type system is much more powerful, stopping just sort of the more advanced dependant type applications.

Sure, thanks, I know that. See, I don't care. I don't need that in my own practice. If I want to find a routine which returns the max integer I do this. If I really needed to write a generic routine (which I don't), I would do C++ or Python or whatever other standard procedural approach. Nothing wrong with that. Any of these is more understandable, more deterministic in runtime behaviour, more modular (less dependencies), easier to write, easier to maintain, etc.