3 ms·

> If you really do need to change an array, how do you do it in Haskell? ...It's like someone really wants to implement bubblesort in Haskell but instead the so

by dxbydt 9y ago

> If you really do need to change an array, how do you do it in Haskell? ...It's like someone really wants to implement bubblesort in Haskell but instead the solution ends up being to implement quicksort because the bubbling is difficult. You nailed it! As a math major myself, I completely empathize with this pov. The vast majority of languages present themselves as minor tools that can be used to solve your problem. The goal is to solve your problem, not figure out the tool. If I want to decompose a matrix via cholesky or schur or QR or LU or what have you, I just want to be able to set arrays willy-nilly without thinking so much about how to accomplish the same thing without setting the array. The Haskell way of "let's not really set the array, it's not what you want" which a bunch of comments have expressed here, focuses the attention on the tool, not my problem at hand. I honestly don't give 2 shits about your tool, whether you call it C or python or octave. I care about my problem, not your tool. So your tool should just stand aside, let me do my thing & not complain. That's exactly why the vast majority of applied researchers in math stick to matlab/octave or ml researchers to python or vision/robotics guys to c++ or insert your speciality here... In each case, the tool is one tiny minor part of the problem solving process. As a quant,I would worry about convergence of pde's and getting the term structure right - yes the whole thing is in c++ but I don't spend days and nights thinking about what does c++ want, I just care about the math. With Haskell, I do have to stop what I am doing and focus on the tool. The language says, lets think about a nice function composition that elegantly yields this transform without dirty mutation. I know such a transform exists,but looking for it is not my day job. Most applied math & applied ml work is seriously messy and highly imperative, for which such elegance is a mismatch, because of time constraints imposed by capitalism. If we were all working with plenty of free time, yes I could concoct the perfect elegant transform every single time, but I don't have that kind of luxury. Haskellers who advocate pausing a bit and rethinking the problem, solving a different problem instead, or expressing the computation recursively with function transforms etc. to suit their language are perfectly honest and right - it's just that I don't have the fucking time to do those things. So yeah, the language is great, but I don't get paid enough to rethink every dirty thing I do with these dirty imperative languages so that it becomes a neat elegant exercise I can marvel at. There is honestly not enough time in the world or money to compensate for the amount of time it would take to rework all the dirty mutable spaghetti that constitutes the majority of day to day work. We all try, but outside of textbook examples and a few select domains, nice fp doesn't scale. It's not a language issue. It's just the times we live in. It's all quite sad, because when I was in school, I actually led a talk using John Hughes' famous fp advocacy paper, where I expanded his examples into finmath, but once you work in industry and see the frantic pace and general messiness of the code base, you realize even the second coming of Jesus Christ won't get us anywhere.

tome 9y ago
> but I don't spend days and nights thinking about what does c++ want You have a magical talent as a C++ programmer then.
beaconstudios 9y ago
I think you're missing the point. The reason for functional programming isn't just that it looks pretty - immutable data makes state conflicts and shared data problems more explicit and forces you to handle them, function composition encourages designing small composable units that make coding faster as you go, that sort of thing. Functional programming tries to force you onto the more long-term-beneficial line on this famous graph: https://martinfowler.com/bliki/images/designStaminaGraph.gif https://martinfowler.com/bliki/images/designStaminaGraph.gif The ironic thing about the example you linked is that if you're trying to implement bubble sort and Haskell pushes you into quick sort, that's a good thing because bubble sort is objectively incorrect. The oldest excuse in the book for bad design is that one does not have time, and while it is often objectively true, it's also true that good design actually saves you time in the long run. Awful spaghetti code is the fastest code to write but in a year's time when it takes a month to get a 2-point story completed because of all the hacks and //TODOs and workarounds you'll wish you wrote it right the first time.
- jordigh 9y ago
  I regretted using bubblesort as an example because the O(n^2) performance is not relevant to my point. Let's consider a Knuth-Fisher-Yates shuffle instead. Pretty easy to describe by mutating an array, and I don't think it's wrong or pigheaded to implement it that way or that I'm just being too stubborn to see how great it is to implement it in a Haskell way.
  - beaconstudios 9y ago
    I think the important point is that functional programming languages push you to immutability because it's a more sensible default. You can still write mutable code but the fact that code is always mutable in other languages can cause problems where none should exist.

by dxbydt 9y ago

tome 9y ago

> but I don't spend days and nights thinking about what does c++ want You have a magical talent as a C++ programmer then.

beaconstudios 9y ago

I think you're missing the point. The reason for functional programming isn't just that it looks pretty - immutable data makes state conflicts and shared data problems more explicit and forces you to handle them, function composition encourages designing small composable units that make coding faster as you go, that sort of thing. Functional programming tries to force you onto the more long-term-beneficial line on this famous graph: https://martinfowler.com/bliki/images/designStaminaGraph.gif https://martinfowler.com/bliki/images/designStaminaGraph.gif The ironic thing about the example you linked is that if you're trying to implement bubble sort and Haskell pushes you into quick sort, that's a good thing because bubble sort is objectively incorrect. The oldest excuse in the book for bad design is that one does not have time, and while it is often objectively true, it's also true that good design actually saves you time in the long run. Awful spaghetti code is the fastest code to write but in a year's time when it takes a month to get a 2-point story completed because of all the hacks and //TODOs and workarounds you'll wish you wrote it right the first time.

jordigh 9y ago
I regretted using bubblesort as an example because the O(n^2) performance is not relevant to my point. Let's consider a Knuth-Fisher-Yates shuffle instead. Pretty easy to describe by mutating an array, and I don't think it's wrong or pigheaded to implement it that way or that I'm just being too stubborn to see how great it is to implement it in a Haskell way.
- beaconstudios 9y ago
  I think the important point is that functional programming languages push you to immutability because it's a more sensible default. You can still write mutable code but the fact that code is always mutable in other languages can cause problems where none should exist.