5 ms·

isn't the whole point that you write code completely differently in functional languages? rather than writing loop code to populate an array, you'd do something

isn't the whole point that you write code completely differently in functional languages? rather than writing loop code to populate an array, you'd do something like the following (in JS as I'm not a haskell programmer): const row = (len, onPositions) => { return (new Array(len)).map((item, index) => onPositions.includes(index) ? 1 : 0); }; const matrixWithDiagonal = (len) => { return (new Array(len)).map((r, index) => row(len, [index])); } the point being, that the code generates the result directly, rather than making space for values and then looping through toggling the positions that should be set to on. note: you wouldn't really use the (new Array()) construct generally speaking (and it doesn't work with .map anyway) but it's easier than including underscore or ramda in the example.

jordigh 9y ago
The original example is just to try to find something where you need to modify an array. Sure, you can create identity matrices without modifying an array, but that's just changing the parameters of the problem. If you really do need to change an array, how do you do it in Haskell? Your solution is the typical thing you do in Haskell. You might know how to perform an algorithm by modifying an array, but now you suddenly have your hands tied and you can't do that anymore. Now you have to come up with an alternative way. 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 or unusual in Haskell.
- beaconstudios 9y ago
  a fair point, but I think it would at least be worth mentioning that if you're trying to modify a variable in Haskell you need to step back and figure out if what you're doing makes sense.
- chongli 9y ago
  In Haskell you usually don't want to modify stuff in memory. That's a manual optimization which is beneath the level of abstraction for typical use. Instead, you write high level code describing how to generate new arrays (or vectors or matrices or what have you) from inputs and let the underlying implementation of the library and compiler deal with optimization. For example, the Haskell vector package [0], implements a ton of optimizations for looping, including stream fusion. Instead of manually trying to loop over an array the way you would in C, Haskell encourages you to use a library like vector to hide those low-level details and let you focus on only the task you want to accomplish. This method is extremely powerful because the underlying implementation has been completely hidden. This lets you swap out the underlying implementation often with a single line change to an import statement. [0] http://hackage.haskell.org/package/vector http://hackage.haskell.org/package/vector
- tome 9y ago
  > If you really do need to change an array, how do you do it in Haskell? https://news.ycombinator.com/item?id=15017853 https://news.ycombinator.com/item?id=15017853
- lmm 9y ago
  I've seen C programmers starting C# get very agitated that they can't "just read the underlying bytes" or whatever. Using low-level techniques from another language doesn't always make sense when learning a new language; often you need to take a step back and find the idiomatic solution to what you were actually trying to do.
- 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.
- marcosdumay 9y ago
  It's incredibly rare that the problem you are trying to solve requires that you alloc an array and modify values in place, instead of something else that gives you the same result. Haskell is normally not suited for those cases anyway, because of stop-the-world garbage collection and hard to predict performance. But, if you want to do that anyway, there's IOArray. You will just have to program everything on IO, and will get an executable that inherits the ordering of your code like any imperative language. Yet, way more often than not, people that think they have that problem just want to write C/Java/watever code in Haskell and have no good reason for dictating every detail of the machine behavior.
  - dllthomas 9y ago
    > You will just have to program everything on IO Sort of, but I think this misleads a little bit. You will have to program your manipulation of the array in IO, and thus anything using the actions manipulating the array. Intermediate computations could be outside IO. And of course there's also ST.
hood_syntax 9y ago
> completely differently Not completely. Mutating state and I/O are done in a more imperative style via monads. > the whole point Depends on who you are I guess. The big wins for me in Haskell are the type system and purity by default. Of course I absolutely love the composability that functional programming offers, but there are other functional programming languages. Haskell I like for those reasons in particular. Disclaimer: I'm still a newbie when it comes to fp and Haskell.
- beaconstudios 9y ago
  to be clear, by "the whole point" I didn't mean "the primary benefit". Just that as a very fundamental point, you have to write code very differently for that code to be functional.
  - hood_syntax 9y ago
    I realized that after I read your reply to the other comment. I certainly understand that sentiment.
tome 9y ago
> isn't the whole point that you write code completely differently in functional languages? That's certainly the conventional wisdom, but I think it's becoming less and less the case and we discover what are good styles to program in and imperative and functional styles are ending up converging somewhat.
- beaconstudios 9y ago
  I think it's more that people are realising the an imperative syntax on a functional language is both accessible and benefits from functional design. See elm, the functional aspects of modern JS, and probably some other examples that don't come to mind right now.
  - tome 9y ago
    And functional constructs are appearing in imperative languages, lambdas, iterators, etc. etc..
    - beaconstudios 9y ago
      iterators have been around for a long time and certainly aren't a functional construct. Lambdas are just syntactic sugar for functions in most cases.

jordigh 9y ago

The original example is just to try to find something where you need to modify an array. Sure, you can create identity matrices without modifying an array, but that's just changing the parameters of the problem. If you really do need to change an array, how do you do it in Haskell? Your solution is the typical thing you do in Haskell. You might know how to perform an algorithm by modifying an array, but now you suddenly have your hands tied and you can't do that anymore. Now you have to come up with an alternative way. 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 or unusual in Haskell.

beaconstudios 9y ago
a fair point, but I think it would at least be worth mentioning that if you're trying to modify a variable in Haskell you need to step back and figure out if what you're doing makes sense.
chongli 9y ago
In Haskell you usually don't want to modify stuff in memory. That's a manual optimization which is beneath the level of abstraction for typical use. Instead, you write high level code describing how to generate new arrays (or vectors or matrices or what have you) from inputs and let the underlying implementation of the library and compiler deal with optimization. For example, the Haskell vector package [0], implements a ton of optimizations for looping, including stream fusion. Instead of manually trying to loop over an array the way you would in C, Haskell encourages you to use a library like vector to hide those low-level details and let you focus on only the task you want to accomplish. This method is extremely powerful because the underlying implementation has been completely hidden. This lets you swap out the underlying implementation often with a single line change to an import statement. [0] http://hackage.haskell.org/package/vector http://hackage.haskell.org/package/vector
tome 9y ago
> If you really do need to change an array, how do you do it in Haskell? https://news.ycombinator.com/item?id=15017853 https://news.ycombinator.com/item?id=15017853
lmm 9y ago
I've seen C programmers starting C# get very agitated that they can't "just read the underlying bytes" or whatever. Using low-level techniques from another language doesn't always make sense when learning a new language; often you need to take a step back and find the idiomatic solution to what you were actually trying to do.
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.
marcosdumay 9y ago
It's incredibly rare that the problem you are trying to solve requires that you alloc an array and modify values in place, instead of something else that gives you the same result. Haskell is normally not suited for those cases anyway, because of stop-the-world garbage collection and hard to predict performance. But, if you want to do that anyway, there's IOArray. You will just have to program everything on IO, and will get an executable that inherits the ordering of your code like any imperative language. Yet, way more often than not, people that think they have that problem just want to write C/Java/watever code in Haskell and have no good reason for dictating every detail of the machine behavior.
- dllthomas 9y ago
  > You will just have to program everything on IO Sort of, but I think this misleads a little bit. You will have to program your manipulation of the array in IO, and thus anything using the actions manipulating the array. Intermediate computations could be outside IO. And of course there's also ST.

hood_syntax 9y ago

> completely differently Not completely. Mutating state and I/O are done in a more imperative style via monads. > the whole point Depends on who you are I guess. The big wins for me in Haskell are the type system and purity by default. Of course I absolutely love the composability that functional programming offers, but there are other functional programming languages. Haskell I like for those reasons in particular. Disclaimer: I'm still a newbie when it comes to fp and Haskell.

beaconstudios 9y ago
to be clear, by "the whole point" I didn't mean "the primary benefit". Just that as a very fundamental point, you have to write code very differently for that code to be functional.
- hood_syntax 9y ago
  I realized that after I read your reply to the other comment. I certainly understand that sentiment.

tome 9y ago

> isn't the whole point that you write code completely differently in functional languages? That's certainly the conventional wisdom, but I think it's becoming less and less the case and we discover what are good styles to program in and imperative and functional styles are ending up converging somewhat.

beaconstudios 9y ago
I think it's more that people are realising the an imperative syntax on a functional language is both accessible and benefits from functional design. See elm, the functional aspects of modern JS, and probably some other examples that don't come to mind right now.
- tome 9y ago
  And functional constructs are appearing in imperative languages, lambdas, iterators, etc. etc..
  - beaconstudios 9y ago
    iterators have been around for a long time and certainly aren't a functional construct. Lambdas are just syntactic sugar for functions in most cases.