6 ms·

>I consider it very inelegant to sort a list only for extracting the largest element. Which I explicitly stated would not be happening in my example. In reali

>I consider it very inelegant to sort a list only for extracting the largest element. 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. But the point wasn't to show how to get the largest element in a list but rather to show how non-strict (i.e. "lazy") evaluation can make the simplest code actually correct. Obviously this doesn't apply in every possible case, but if you compare it to e.g. C which is pretty much never the case, it's a win in elegance IMO. >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. > noticing that the underlying basics have changed AGAIN in Haskell... Not sure what you mean here, are you complaining about standard library changes? 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. >Really, I consider the following C thing to be so much clearer and better engineering: 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. * 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 short of the more advanced dependant type applications.

jstimpfle 9y ago
> 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.
- alien_at_work 9y ago
  >I'm pretty sure most experienced software architects would not approve this as a robust approach. What approach? Not caring which sort is used? I explicitly stated that in actual practice I wouldn't do that. I simply took a quick example to make a point and you're turning it into an interigation. Look, you don't like Haskell. Fine, don't use it. I'm not cashing checks from your choice of programming language, use whatever you like.
  - jstimpfle 9y ago
    No, I actually mean the approach where you explicitly pick a "sort" implementation that would yield a linear-time smallest-element when evaluated lazily. I don't know if a popular sort with this property exists, but anyway, relying on that is too clever. It's not obvious and also fragile (maybe the sort changes at some point its constant or even asymptotic behaviour?) If you want the smallest element, get the smallest element by scanning the list. No big deal. Well, I'm sorry for turning this into almost an emotional issue. I guess I am the one who is cashing checks here. It does annoy me: I have seen way too many advocating that makes it seem like this vague idea of "safety by type-safety" is the only issue that comes up in software development. It is not. It doesn't help all that much for correctness, and other aspects like modularity, efficiency, portability, compiling speed, development speed etc. are at least equally important for the vast majority of projects. (I could say I've "wasted" a lot of time for investing in Haskell before learning that these other qualities matter as well, but I would not go this far. It's been a good investment, even if it's not a practical language) It is no coincidence that most Haskell projects never take off. Just look around at the software in existence. What you can find is mostly little tinker projects. When I look at some higher-profile libraries for example for web programming, they focus way too much on some perceived gains from very advanced type system tricks, but they are basically too hard to use in a practical setting. The big links page on Haskell.org has mostly toy projects and broken links. When I look at the open projects page at toptal.com I can see exactly one Haskell project, and it is about refactoring a completely unmaintainable Haskell codebase! There are areas, like compilers, where Haskell seems to do quite well, but for the most part it is impractical. Even most Haskellers don't disagree that it's mostly good for expanding your mind, exploring mathematical ideas etc.

jstimpfle 9y ago

> 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.

alien_at_work 9y ago
>I'm pretty sure most experienced software architects would not approve this as a robust approach. What approach? Not caring which sort is used? I explicitly stated that in actual practice I wouldn't do that. I simply took a quick example to make a point and you're turning it into an interigation. Look, you don't like Haskell. Fine, don't use it. I'm not cashing checks from your choice of programming language, use whatever you like.
- jstimpfle 9y ago
  No, I actually mean the approach where you explicitly pick a "sort" implementation that would yield a linear-time smallest-element when evaluated lazily. I don't know if a popular sort with this property exists, but anyway, relying on that is too clever. It's not obvious and also fragile (maybe the sort changes at some point its constant or even asymptotic behaviour?) If you want the smallest element, get the smallest element by scanning the list. No big deal. Well, I'm sorry for turning this into almost an emotional issue. I guess I am the one who is cashing checks here. It does annoy me: I have seen way too many advocating that makes it seem like this vague idea of "safety by type-safety" is the only issue that comes up in software development. It is not. It doesn't help all that much for correctness, and other aspects like modularity, efficiency, portability, compiling speed, development speed etc. are at least equally important for the vast majority of projects. (I could say I've "wasted" a lot of time for investing in Haskell before learning that these other qualities matter as well, but I would not go this far. It's been a good investment, even if it's not a practical language) It is no coincidence that most Haskell projects never take off. Just look around at the software in existence. What you can find is mostly little tinker projects. When I look at some higher-profile libraries for example for web programming, they focus way too much on some perceived gains from very advanced type system tricks, but they are basically too hard to use in a practical setting. The big links page on Haskell.org has mostly toy projects and broken links. When I look at the open projects page at toptal.com I can see exactly one Haskell project, and it is about refactoring a completely unmaintainable Haskell codebase! There are areas, like compilers, where Haskell seems to do quite well, but for the most part it is impractical. Even most Haskellers don't disagree that it's mostly good for expanding your mind, exploring mathematical ideas etc.