3 ms·

>My goal is "as fast as C (TM)". Enjoy using C then. You suggested that haskell was bad because it was not fast enough. If "not as fast as C" is not fast eno

>My goal is "as fast as C (TM)". Enjoy using C then. You suggested that haskell was bad because it was not fast enough. If "not as fast as C" is not fast enough, then virtually every language is not just bad, but much worse than haskell. >I said Haskell doesn't make it easy And I showed you that it is in fact trivially easy. >Here are the actual array docs, BTW That is a random, user-edited wiki page. I linked to the actual docs.

yummyfajitas 12y ago
If "not as fast as C" is not fast enough, then virtually every language is not just bad, but much worse than haskell. I agree. The only languages I've used that are remotely competitive for my purposes are static JVM languages (Java and Scala), Ocaml, and Julia for array ops. Haskell comes closer than many others, but just isn't there yet. The docs you linked to are a 3'rd party package marked "experimental". I'll also suggest that you are glossing over most of the difficulties in using them. It's trivially easy to call `unsafeRead`. It's not so easy to wrap your operations in the appropriate monad, apply all the necessary strictness annotations to avoid thunks, and properly weave this monad with all the others you've got floating around. (That last bit is fairly important if you plan to write methods like `objectiveGradient dataPoint workArray`.)
- imanaccount247 12y ago
  >(Java and Scala), Ocaml, Except scala and ocaml are both slower than haskell. >The docs you linked to are a 3'rd party package marked "experimental". No it is not. What is the point of just outright lying? >I'll also suggest that you are glossing over most of the difficulties in using them I'll suggest that if you want people to believe your claim, then you should back it up. Show me the difficulty. Because my week 1 students have no trouble with it at all. >It's not so easy to wrap your operations in the appropriate monad You are literally saying "it is not easy to write code". That is like saying "printf" is hard in C because you have to write code. It makes absolutely no sense. Have you actually ever tried learning haskell much less using it? >apply all the necessary strictness annotations to avoid thunks All one of them? Which goes in the exact same place it always does? And which is not necessary at all? >and properly weave this monad with all the others you've got floating around. Ah, trolled me softly. Well done.
  - yummyfajitas 12y ago
    I don't know why you are responding so angrily. The page you linked to explicitly says "Stability experimental" in the top right corner. I also don't know why you are behaving as if I dislike Haskell. I enjoy Haskell a lot, I just find getting very good performance to be difficult. You can browse my comment history to see a generally favorable opinion towards Haskell if you don't believe me. I also gave you a concrete example of a reasonable and necessary task I found difficult: specifically, numerical functions which need to mutate existing arrays rather than allocating new ones, e.g. gradient descent. Every time I've attempted to implement such things in Haskell, it takes me quite a bit of work to get the same performance that Scala/Java/Julia/C gives me out of the box (or Python after using Numba).
    - tome 12y ago
      > "Stability experimental" in the top right corner. This is a bit of a strange convention in the Haskell world. Libraries tend to be marked "experimental" even when they are completely stable and the correct choice for production use. Note that Data.Text[1] is also marked "experimental", and it is perfectly stable and the correct choice for Unicode in Haskell. > 3'rd party package Data.Vector is 3rd party in the sense that it is not part of the GHC base package, but so what? It is now considered the correct library for using arrays in Haskell. [1] http://hackage.haskell.org/package/text-1.1.1.3/docs/Data-Text.html http://hackage.haskell.org/package/text-1.1.1.3/docs/Data-Te...
      - yummyfajitas 12y ago
        I stand corrected. My mistake.
        codygman 12y ago
        I would like to help you with any Haskell performance problems you had, contact me via the email in my profile if interested.
        tome 12y ago

yummyfajitas 12y ago

If "not as fast as C" is not fast enough, then virtually every language is not just bad, but much worse than haskell. I agree. The only languages I've used that are remotely competitive for my purposes are static JVM languages (Java and Scala), Ocaml, and Julia for array ops. Haskell comes closer than many others, but just isn't there yet. The docs you linked to are a 3'rd party package marked "experimental". I'll also suggest that you are glossing over most of the difficulties in using them. It's trivially easy to call `unsafeRead`. It's not so easy to wrap your operations in the appropriate monad, apply all the necessary strictness annotations to avoid thunks, and properly weave this monad with all the others you've got floating around. (That last bit is fairly important if you plan to write methods like `objectiveGradient dataPoint workArray`.)

imanaccount247 12y ago
>(Java and Scala), Ocaml, Except scala and ocaml are both slower than haskell. >The docs you linked to are a 3'rd party package marked "experimental". No it is not. What is the point of just outright lying? >I'll also suggest that you are glossing over most of the difficulties in using them I'll suggest that if you want people to believe your claim, then you should back it up. Show me the difficulty. Because my week 1 students have no trouble with it at all. >It's not so easy to wrap your operations in the appropriate monad You are literally saying "it is not easy to write code". That is like saying "printf" is hard in C because you have to write code. It makes absolutely no sense. Have you actually ever tried learning haskell much less using it? >apply all the necessary strictness annotations to avoid thunks All one of them? Which goes in the exact same place it always does? And which is not necessary at all? >and properly weave this monad with all the others you've got floating around. Ah, trolled me softly. Well done.
- yummyfajitas 12y ago
  I don't know why you are responding so angrily. The page you linked to explicitly says "Stability experimental" in the top right corner. I also don't know why you are behaving as if I dislike Haskell. I enjoy Haskell a lot, I just find getting very good performance to be difficult. You can browse my comment history to see a generally favorable opinion towards Haskell if you don't believe me. I also gave you a concrete example of a reasonable and necessary task I found difficult: specifically, numerical functions which need to mutate existing arrays rather than allocating new ones, e.g. gradient descent. Every time I've attempted to implement such things in Haskell, it takes me quite a bit of work to get the same performance that Scala/Java/Julia/C gives me out of the box (or Python after using Numba).
  - tome 12y ago
    > "Stability experimental" in the top right corner. This is a bit of a strange convention in the Haskell world. Libraries tend to be marked "experimental" even when they are completely stable and the correct choice for production use. Note that Data.Text[1] is also marked "experimental", and it is perfectly stable and the correct choice for Unicode in Haskell. > 3'rd party package Data.Vector is 3rd party in the sense that it is not part of the GHC base package, but so what? It is now considered the correct library for using arrays in Haskell. [1] http://hackage.haskell.org/package/text-1.1.1.3/docs/Data-Text.html http://hackage.haskell.org/package/text-1.1.1.3/docs/Data-Te...
    - yummyfajitas 12y ago
      I stand corrected. My mistake.
      - codygman 12y ago
        I would like to help you with any Haskell performance problems you had, contact me via the email in my profile if interested.
      - tome 12y ago