From what I've heard from a friend of using other people's code in one particular scientific field (stringly type some of the things, probably accidentally, don't document this), an at-least-passable type system would be a huge improvement.
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?).
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.
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.
There are "Real World" Haskell resources, in fact there is even a book named Real World Haskell[0], though I recommend Haskell Book[1] these days since it takes an approach of teaching from first principles.
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.
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.
Err... can you qualify this? Based on my knowledge of Haskell this isn't a fair assessment at all.
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.
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
DeriveAnyClassEdit: 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.
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.
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).
I see FP languages being able to excel at the kind of projects with large, maintainable codebases that evolve over a decade and are shared between dozens of developers. Service oriented architectures serve the same goal -- isolating behavior and state locally, and being explicit about mutation and state changes over time.
"R, at its heart, is a functional programming (FP) language. This means that it provides many tools for the creation and manipulation of functions. In particular, R has what’s known as first class functions. You can do anything with functions that you can do with vectors: you can assign them to variables, store them in lists, pass them as arguments to other functions, create them inside functions, and even return them as the result of a function."
Weak example is Wikipedia list of Functional Programming Languages list R as one. https://en.wikipedia.org/wiki/Functional_programming#R
R describes itself as a Functional programming Language:
The language syntax has a superficial similarity with C, but the semantics are of the FPL (functional programming language) variety with stronger affinities with Lisp and APL. In particular, it allows “computing on the language”, which in turn makes it possible to write functions that take expressions as input, something that is often useful for statistical modeling and graphics. https://cran.r-project.org/doc/manuals/r-release/R-lang.html
Academic Evidence: "The Journal Trends in Functional Programming" also list R as a functional programming language.
R is an environment and functional programming language for statistical data analysis and visualization. Largely unknown to the functional programming community, it is popular and influential in many empirical sciences.
http://link.springer.com/chapter/10.1007%2F978-3-642-40447-4...
The issue might be it isn't Haskel so it is not 100% functional but there are more Functional Programming Languages then Haskel.
PS This is why so many programs in R are poorly written because people try to force OO into R when they could do things Functional. That is also why my eyes bleed when I see people looping through everything in their R scripts.
Yes, you can write R code in a functional style in places when convenient, but one floor down it's still running that loop you didn't want to see. It's a language based on mutable values and sequential execution and looping, not pure function calls and recursion. The syntax itself is very much sequential, unlike stereotypical FPLs. Even the lexical scoping design relies fundamentally on mutable environments. So yes, people do seem to enjoy proudly declaring R a FPL citing a few features, but as I said, those features make R as much a FPL as Python.
That was very condescending and I am sure don't know who Hadley Wickham is? I wouldn't call his understanding "Shallow."
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?
https://github.com/jmoy/avb-econ-hs/blob/f6d65af480c99045573...
to that in Julia
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.
> 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"]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?
That's the unfair part right there: lying to people about the proper uses of Python.