6 ms·

Why isn't Haskell, or any other functional language, popular for this sort of thing? Turning A into B is what FP excels at, and you shouldn't have to reason abo

• KirinDave 11y ago
  The only functional langauges to gain much popularity here are OCaml and F#. Haskell tends not to be a go-to choice here because it... well... there are a lot of reasons. It's a tough language to learn compared to its competitors because it's basically a few really awesome modern features in a massive graveyard of failed academic initiatives that are now enshrined in the lore of the language because one or two useful libraries used them.
  • codygman 11y ago
    > it's basically a few really awesome modern features in a massive graveyard of failed academic initiatives that are now enshrined in the lore of the language because one or two useful libraries used them. Err... can you qualify this? Based on my knowledge of Haskell this isn't a fair assessment at all.
    • KirinDave 11y ago
      Based on my knowledge, it's very fair. How many language extensions are available vs placed in common use? Where is the guidance on which to use? You WILL use at least 3 I can think of off hand very commonly. And how many failed lens libraries preceeded the current (quite good) dominant library that still show up on google and even get included in? How many people still run versions of Yesod using now-unfavored abstractions? The Haskell community really got its shit together over the last 3 years. Cabal got a lot better, a bunch of key libraries got good, our compiler is fixed some major bugs. But these developments do not magically erase people who have navigated the prior 5 years of Haskell where a lot of these technologies got established. I love Haskell, I really do. I wish I could ship more code with Haskell, and like it as well. But the OP asked about why Haskell didn't take off. Its ecosystem was in what we might call a state of growth and flux at the time a lot of stream and batch computation systems were shipping. Oh and uh, I think Haskell's community is full of some truly toxic people, an intersection of some of the ugliest and most arrogant personalities of the Scala world who's primary education strategy can only be called "negging." You will know these people when you find them. Compared to the Clojure community or the F# community or the Erlang community which are also forward thinking, interesting and skilled... it looks positively hostile. You may not care about that, but I refuse to endorse or use technologies who's community leadership is so toxic. Why, I've stopped using Linux in anything but legacy apps because I completely despair of that project from ever rising above is puerile and cliquish roots.
      • codygman 11y ago
        > Alright, I'll give you that there are a ton of GHC extensions after getting a list of them, all 106 as of GHC 7.10[0]. This does make me wonder why having so many extensions was never an issue for me. > The Haskell community really got its shit together over the last 3 years. Cabal got a lot better, a bunch of key libraries got good, our compiler is fixed some major bugs Agreed. > I love Haskell, I really do. I wish I could ship more code with Haskell, and like it as well. But the OP asked about why Haskell didn't take off. Its ecosystem was in what we might call a state of growth and flux at the time a lot of stream and batch computation systems were shipping. Fair enough. > Oh and uh, I think Haskell's community is full of some truly toxic people, an intersection of some of the ugliest and most arrogant personalities of the Scala world who's primary education strategy can only be called "negging." I've seen this personality type in other languages, but not Haskell yet. I too abhor the "negging" type, as well as the subculture that term arose from. 0: all ghc extensions OverlappingInstances UndecidableInstances IncoherentInstances DoRec RecursiveDo ParallelListComp MultiParamTypeClasses MonomorphismRestriction FunctionalDependencies Rank2Types RankNTypes PolymorphicComponents ExistentialQuantification ScopedTypeVariables PatternSignatures ImplicitParams FlexibleContexts FlexibleInstances EmptyDataDecls CPP KindSignatures BangPatterns TypeSynonymInstances TemplateHaskell ForeignFunctionInterface Arrows Generics ImplicitPrelude NamedFieldPuns PatternGuards GeneralizedNewtypeDeriving ExtensibleRecords RestrictedTypeSynonyms HereDocuments MagicHash TypeFamilies StandaloneDeriving UnicodeSyntax UnliftedFFITypes InterruptibleFFI CApiFFI LiberalTypeSynonyms TypeOperators RecordWildCards RecordPuns (Deprecated, use NamedFieldPuns instead) DisambiguateRecordFields TraditionalRecordSyntax OverloadedStrings GADTs GADTSyntax MonoPatBinds RelaxedPolyRec ExtendedDefaultRules UnboxedTuples DeriveDataTypeable DeriveGeneric DefaultSignatures InstanceSigs ConstrainedClassMethods PackageImports ImpredicativeTypes (deprecated) NewQualifiedOperators (deprecated) PostfixOperators QuasiQuotes TransformListComp MonadComprehensions ViewPatterns XmlSyntax RegularPatterns TupleSections GHCForeignImportPrim NPlusKPatterns DoAndIfThenElse MultiWayIf LambdaCase RebindableSyntax ExplicitForAll DatatypeContexts MonoLocalBinds DeriveFunctor DeriveTraversable DeriveFoldable NondecreasingIndentation SafeImports Safe Trustworthy Unsafe ConstraintKinds PolyKinds DataKinds ParallelArrays RoleAnnotations OverloadedLists EmptyCase AutoDeriveTypeable NegativeLiterals BinaryLiterals NumDecimals NullaryTypeClasses ExplicitNamespaces AllowAmbiguousTypes JavaScriptFFI PatternSynonyms PartialTypeSignatures NamedWildCards DeriveAnyClass
• optimiz3 11y ago
  Probably because functional languages don't actually at excel scientific computing relative to Python, C#, Java, and JavaScript. :D Edit: I kid, but most of the languages I just mentioned have very fast native compilers, easy ways of invoking low-level interop, functional-style libraries if you want them, and (except for Python) C-like syntax making it easy to cut-and-paste.
  • tokipin 11y ago
    No need to kid. Self-described "FP" languages are a pain in the ass for the type of programming scientists do. I don't even know what kind of programming those languages aren't a pain in the ass for.
    • fsloth 11y ago
      "I don't even know what kind of programming those languages aren't a pain in the ass for." If we limit the discussion to ML languages, they are generally very nice e.g. for datastructure transforms (including interpreters and compilers). Static typing with type inference makes implementations short, and, if written in good style, are correct when they compile. There are various other reasons why one would not want to use them. For me it's platform stability and availability - while I enjoy functional languages in principle - I yet seem to choose C++ more often than not for my hobby projects. I would say learning self-described fp-languages have made me a better programmer who values static typing more than before.
      • restalis 11y ago
        "I would say learning self-described fp-languages have made me a better programmer who values static typing more than before." FP paradigm has indeed didactic value and the experience gained in a functional language may translate into a plus of productivity ...in other languages. When you have to get things done, the functional language's embedded arm-twisting (well, mind-twisting actually) doesn't help! That's when you'll either abandon the (idea of) "pure" functional language for a multi-paradigm language (that will allow you to keep a mainly functional style with limited deviations when the situation warrants it) or you'll keep pushing yourself and throw the blame on you for not being good enough with a language that wasn't designed from very beginning for much anything but the FP standpoint (for the sake of it).
• cpbotha 11y ago
  The large number of high quality scientific and computational libraries that are easily available for Python (most things are a "conda install" or "pip install" away) plus the Jupyter (literate programming) notebook (although that now supports other languages) currently make a very compelling case for using Python instead of Haskell and most other functional languages.
• Tomte 11y ago
  Because the Python ecosystem is huge, with real scientists writing real libraries to get stuff done. The Haskell crowd seems to write monad tutorials that are either cute or unintellegible, and stratosphere-high level stuff where I wouldn't have the slightest clue what I can use them for (Arrows? Zippers?).
  • msie 11y ago
    And Lenses!
  • j-pb 11y ago
    C'mon zippers are not that hard, and really useful. Lets say you want to do processing of some xml file. Normally you'd walk the tree and do manipulations in place. With zippers however, you can inspect every intermediary tree result, you can rethink you problem so that you walk the tree once to extract interesting information, then compute a changeset for the tree, maybe merge it with a differently computed changeset, and then apply the union of them. I build a ocr system in clojure on zippers and it was a lot of fun. You could for example extract a list of all the words, with line wraps removed, then do the correction on that view/lense of your data, and reapply the changes without having to worry to reintroduce the pesky linewraps, because they were never removed from the original document.
    • deleted 11y ago
      [deleted]
  • alricb 11y ago
    Haskell tends to attract people who like programming languages as programming languages. It encourages a style that's completely different from what you're taught in your basic Fortran/C/Java/Matlab course. If, like a lot of scientist, you've done a little imperative programming already, Python isn't much of a step; Haskell, at least as it is presented usually, is another bag entirely. This means you have a much larger audience, and therefore it's more likely that someone will already have written a tool of your domain in Python.
  • codygman 11y ago
• ntoshev 11y ago
  The diff between Haskell and Python is not functional programming, I program functionally in Python, it is the type system. This is subjective, but having tried Elm with its Haskellish type system, it seems that the type system makes me think hard about things that ultimately don't matter much. It might depend on your problem, but I doubt it. Even doing numerical computation with Theano I find myself better off just executing subexpressions and seeing results and the shape of the tensors interactively is more useful than thinking really hard how the operations transform the shape.
  • j-pb 11y ago
    If you're using persistent datastructures like pyrsistent I could agree, but vanilla python is very unsuited for functional programming. Even JS has better lambdas.
  • codygman 11y ago
    > This is subjective, but having tried Elm with its Haskellish type system, it seems that the type system makes me think hard about things that ultimately don't matter much. It might depend on your problem, but I doubt it. Even doing numerical computation with Theano I find myself better off just executing subexpressions and seeing results and the shape of the tensors interactively is more useful than thinking really hard how the operations transform the shape. If it is true that the type system, perhaps static type systems in general, make you think hard about things that ultimately don't matter much... why not go for the most dynamic and interactive language possible? Clojure perhaps. I've been toying with the idea that either fully dynamic and as interactive as possible or full dependent typing is the generally right answer. By right, I mean what you should reach for with most programming tasks if you aren't going to put effort into selecting one tailored to your task.
• yomritoyj 11y ago
  Regarding Haskell specifically, Haskell makes it cumbersome to write code that mutates data structures, which is what you need to efficiently implement many numerical algorithms. But I'm a fan of Haskell's [REPA](https://hackage.haskell.org/package/repa https://hackage.haskell.org/package/repa) which provides multidimensional arrays with complete control over which operations are computed immediately and which are deferred and can be combined later with other operations. This allows many computations to be expressed in a high-level array-oriented way without incurring the cost of creating huge temporaries. C++ template libraries like Eigen can do this, but give much less control to the user on what is deferred.
  • codygman 11y ago
    > Regarding Haskell specifically, Haskell makes it cumbersome to write code that mutates data structures Can you provide some Haskell examples that are cumbersome, then provide an example that isn't in another language of your choice? Also, have you tried using lens for this?
    • yomritoyj 11y ago
      Compare the implementation of a simple numerical program in Haskell https://github.com/jmoy/avb-econ-hs/blob/f6d65af480c99045573fd2f8be23572240d3c9e2/Main.lhs https://github.com/jmoy/avb-econ-hs/blob/f6d65af480c99045573... to that in Julia https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/b558946c4c4d22a79478174ed157800ba828859f/RBC_Julia.jl https://github.com/jesusfv/Comparison-Programming-Languages-... Despite the Haskell program using the elegant facilities provided by REPA, the fact that mutable part (the `writePolicy`) has to be written in a different style than the pure parts since it is a monadic action seems cumbersome to me.
      • codygman 11y ago
        I agree that the Julia looks nicer, despite the fact I usually dislike so much nesting. > the fact that mutable part (the `writePolicy`) has to be written in a different style than the pure parts since it is a monadic action seems cumbersome to me. It has to be written differently more because it's using the state monad. You can write monadic actions that resemble pure code, for instance: > replicateM_ (readFile "/etc/issue") ["Ubuntu 15.10 \\n \\l\n\n","Ubuntu 15.10 \\n \\l\n\n","Ubuntu 15.10 \\n \\l\n\n","Ubuntu 15.10 \\n \\l\n\n","Ubuntu 15.10 \\n \\l\n\n","Ubuntu 15.10 \\n \\l\n\n","Ubuntu 15.10 \\n \\l\n\n","Ubuntu 15.10 \\n \\l\n\n","Ubuntu 15.10 \\n \\l\n\n","Ubuntu 15.10 \\n \\l\n\n"]
• stefantalpalaru 11y ago
  > Why isn't Haskell, or any other functional language, popular for this sort of thing? Because some of the scientists doing this are bellow average programmers. Look at the author singing praises to Python while benefiting from C, Fortran and Cython. He doesn't understand that what actually matters is what's under the hood, and you want him to learn functional programming and rewrite his algorithms?
  • ovis 11y ago
    That seems very unfair. I have no reason to think the author doesn't understand that Python libraries are built on carefully written C and Fortran, and based on the article they seem to be a perfectly competent programmer.
    • stefantalpalaru 11y ago
      Have you missed the title? He gives undue credit to one of the most unfit languages for HPC ever. Python is not made to be efficiently implemented, yet the author cheerfully writes "I choose to use Python for performance critical scientific computing code". That's the unfair part right there: lying to people about the proper uses of Python.
• aswanson 11y ago
  Not enough developer uptake for Haskell early on; quite frankly because it requires a thoughtshift that many developers find too difficult to do.