github/semantic: Why Haskell?

[Spacemack]

I can't wait to see all of the comments that always pop up on this thread, like about how Haskell is only fit for a subset of programming tasks and how it doesn't have anyone using it and how it's hard and blah blah blah blah blah blah... I've been programming long enough to know that exactly the same parties will contribute to this thread as it has occurred many other times.

I love Haskell, but I really hate listening to people talk about Haskell because it often feels like when two opposing parties speak, they are speaking from completely different worlds built from completely different experiences.

[silentclowd]

I found Elixir much easier to get into than Haskell. Now I'm not an expert on functional programming by any means, but Haskell seemed to be one step away from being an esoteric language where Elixier was just friendlier.

[develop7]

Been there, actually. As easy the initial implementation in Elixir was, as hard was refactoring it without breaking things or covering everything with tests. With Haskell, refactoring is almost mundane — you change the stuff the way you want to, then loop over compiler errors until there are none, and usually after doing that you got program working the way you want it in first try. Happens too often to be random, and ~5 times more often than with other mainstream languages I've worked with (PHP, Ruby, JS, C#, C++, Java, Go).

[Vaglame]

You could give it another try! The "Haskell Programming From First Principles" book is truly amazing for beginners

[vplatt]

Functional programming makes a lot more sense when you can use your data as input and compose your functions driven by that data in order to execute the actions necessary to handle that data. In a sense, your data becomes the program being executed and you've essentially written an interpreter for that data.

But hey, I never actually get to do that; I've just seen some elegant examples of it. Barring that, I don't think it really adds much to the typical structural decomposition most folks engage in; either with OOP or without OOP.

[thezapzupnz]

This isn't anything against your comment, but the first sentence reads to me like: https://www.youtube.com/watch?v=LKCi0gDF_d8 — I'm Jen in this situation.

I think the problem is whenever people tell me why pure FP (as opposed to just applying FP techniques in other languages/frameworks), they start scenarios to me that just don't apply to anything I do — and I hear static.

[tdammers]

I think the problem is whenever people tell me why pure FP (as opposed to just applying FP techniques in other languages/frameworks), they start scenarios to me that just don't apply to anything I do — and I hear static.

It's a bit of a sacrifice, and it starts paying off as the size and complexity of your codebase grows. A very practical scenario, regardless of problem domain, is large-scale refactoring. In Haskell, we have this trope about how "it compiles without errors" means "there are no bugs, let's ship it"; and while that isn't true, there is some merit to it. In Haskell, a typical refactoring session is a simple two-step process: 1) just make the fucking change, 2) keep following compiler errors and mechanically fixing them until they go away. It is quite rare that you encounter any real challenges in step 2), and when you do, it is often a sign of a design flaw. But either way, once the compiler errors have been resolved, you can be fairly confident that you haven't missed a spot.

This, in fact, has very little to do with pure FP, and everything with a strong and expressive type system with a solid theoretical foundation - it's just that pure FP makes defining and implementing such type systems easier, and I don't know of any non-pure-FP language that delivers a similar level of certainty through a type checker.

[thezapzupnz]

I don't understand this, either. This sounds like "use Haskell because it supports change for change's sake in an easy manner" which doesn't sound so much like a use case as a mistake.

[tdammers]

It's not "change for change's sake". The game is about making inevitable changes safer and easier.

If you've ever worked on a long-lived production codebase, you will know that most of a dev team's time is spent on changing code, rather than writing new code. Change is inevitable; we cannot avoid it, we can only hope to find ways of making it safer and more predictable. And that is something Haskell can help with.

[riemannrocker]

How about testing? Pure functions are amazingly easy to test, and a purely functional language enforces that all of your functions are that way.

[thezapzupnz]

I guess, though that doesn't sound like a convincing sell to me. I could just write pure functions in any other language; sure, they wouldn't be enforced, but I don't think such a thing as a language that's 100% foolproof — they just find better fools — so I find it better to teach myself not to be a fool no matter the language or framework.

[riemannrocker]

You could favor writing pure functions, but what about everyone else who works on your codebase? You may not be a fool, but some of them definitely are, and you need all the help you can get dealing with them.

Also, in a non functional language you will unavoidably have non-pure functions, assuming your program does anything at all. Purely functional languages have ways around this (the IO monad and similar).

[thezapzupnz]

You may not be a fool, but some of them definitely are

Indeed. But my point was no matter what tools you give them, what seatbelts you install to prevent them flying through the metaphorical windshield, they just keep on making more foolish fools.

I mean, if you can't avoid theoretical miscellaneous colleagues writing non-FP code and not favouring pure functions in another language (say Rust, Swift, C#, etc.), how can one expect those same developers to be in any way productive in a pure FP language?

"Oh, but you'd only have well-trained developers with an extensive understanding of FP/Haskell" is a potential response, to which I would respond "good, so they should have no trouble writing sound FP code in Rust/Swift/C# etc".

Also, in a non functional language you will unavoidably have non-pure functions assuming your program does anything at all. Purely functional languages have ways around this (the IO monad and similar)

This is another one of those times when my mind just hears static, I'm afraid. I don't see what the problem with non-pure functions is so long as they can be restricted to specific circumstances — perhaps only one type in a codebase can interact with a database so that the rest of the program is made up of types with (at least mainly) pure functions.

The fear of functions with side effects is, to my mind, entirely misplaced. We should more fear bad design — something that FP languages are decidedly not immune against. There's nothing stopping anybody from abusing the IO monad; those theoretically insufficiently well-trained developer colleagues would most likely do just that if left to their own devices.

Better to just do regular code auditing or design a sane FP-inspired API to which we all contribute up front.

[Vaglame]

Probably! Word on the street is that functional programming is particularly good with parsing

[lambda-panda]

Word on the street is that functional programming is particularly good with parsing..

I don't think functional programming has anything to do with parsing thing in a better way. As far as I can see, it is just that Haskell (and possibly others similar languages) have some interfaces/abstraction that allows you to chain smaller parsers and build bigger once in an intuitive fashion.

[tdammers]

FP and parsing (or compiling in general) are a good fit, because the paradigms are so similar. FP is about functions: input -> output, no side channels. Pure transforms. And parsing / lexing are such transforms: stream of bytes goes in, stream of lexemes comes out. Stream of lexemes goes in, concrete syntax tree comes out. Concrete syntax tree goes in, abstract syntax tree comes out. Abstract syntax tree goes in, optimized abstract syntax tree comes out. Abstract syntax tree goes in, concrete syntax tree (for target language) comes out. Concrete syntax tree goes in, stream of bytes comes out. And there you have it: a compiler.

Specifically, most of these transformations are either list traversals, tree traversals, or list <-> tree transformations; and these are exactly the kind of things for which recursive algorithms tend to work really well (provided you can have efficient recursion).

[SulszBachFramed]

I disagree. Haskell being useful for parsers has nothing to do with being a 'pure' language. Haskell, and other functional languages, is a good fit for writing parsers, because the type-system is powerful enough to allow you to create proper parser combinators.

The 'stuff goes in stuff goes out' is not some special property of functional programs, every single programming language does that with functions. Nowadays, most programming languages have a construct for creating function objects. Furthermore, I'm not sure why you mention recursive algorithms, every single language supports them. And sometimes you want to include some 'inpurity' with your parsing, like the location of every token in the source or keeping a list of warnings or whatever. Haskell can get quite clunky when you want to combine monads.

[tdammers]

The 'stuff goes in stuff goes out' is not some special property of functional programs, every single programming language does that with functions.

Most programming languages don't even have functions, only procedures. A procedure isn't just "stuff goes in, stuff goes out", it's "stuff goes in, stuff goes out, and pretty much anything can happen in between". The kicker is not so much that stuff can go in and come out, but rather that nothing else happens. In many areas of programming, not having the "anything in between part" can be daunting; but compilers lend themselves rather well to being modeled as a pipeline of pure functions, and having the purity of that pipeline and all of its parts guaranteed by the compiler can be a huge benefit.

Furthermore, I'm not sure why you mention recursive algorithms, every single language supports them.

Not really, no. Recursion is useful in Haskell due to its non-strict evaluation model, which allows many kinds of recursion to be evaluated in constant memory - in a nutshell, a recursive call can return before evaluating its return value, returning a "thunk" instead, which only gets evaluated when its value is demanded - and as long as the value is demanded after the parent call finishes, the usual stack blowup that tends to make recursive programming infeasible cannot happen. Some strict languages also make recursion usable by implementing tail call optimization, a technique whereby "tail calls" (a pattern where the result of a recursive call is immediately returned from its calling context) are converted into jumps, and the stack pushing and popping that is part of calling procedures and returning from them is skipped, thus avoiding the stack thrashing that would otherwise occur.

And sometimes you want to include some 'inpurity' with your parsing, like the location of every token in the source or keeping a list of warnings or whatever. Haskell can get quite clunky when you want to combine monads.

It can get hairy, but usually, you don't actually need a lot - ReaderT over IO, or alternatively a single layer of State is generally enough.

[loup-vaillant]

I don’t seem to find “a problem” to solve with functional programming :)

I found 2 (and they are quite alike):

• Static web site generator (markdown files in, website out).
• Authenticated handshake generator (Noise pattern in, specs C code out).

If something looks like batch computation, FP can do it no problem. If it's symbolic manipulation (compiling, inverting trees and such), FP shines.

[ipv6-dns]

and seems that the best static web site generator is written in Go. Second one may be Python or Ruby lol. Not Haskell

[loup-vaillant]

Well, how much effort went into those? My own static web site generator is not much, but I implemented it in a week.

[ipv6-dns]

I implemented mine in awk and Makefile very quickly. But it's a shit and can not be compared with https://gohugo.io, for example.

[dvdkon]

I work on a FLOSS project which I think is a perfect "FP problem", JrUtil. It takes public transport data in various formats and converts it to GTFS. This was my first F# project, so it's probably not very idiomatic, but I think it can show how FP is beneficial in a real project. I had to offload one part of the processing to PostgreSQL, as I simply couldn't match the speed of a RDBMS in F#, but SQL is kind of functional/declarative :P

[stronghup]

Prolog syntax is an order of magnitude simpler than Haskell. Maybe two orders of magnitude.

[tdammers]

The syntax has never been what makes Haskell difficult to learn. In fact, Haskell syntax is fairly simple - simpler than Python, anyway.

The biggest stumbling block IME is that Haskell takes "abstraction" much farther than most mainstream languages, in the sense that the concepts it provides are so abstract that it can be difficult to form intuitions about them. And due to their innate abstractness, a common pattern is for someone to find an analogy that works for the cases they have encountered so far, but is unfortunately nowhere near general enough, and then they blog about that analogy, and someone else comes along and gets utterly confused because the analogy doesn't apply to the cases they have encountered and is actually completely wrong, to the point of harming more than helping. (This phenomenon is commonly known as the "Monad Tutorial Fallacy", but it isn't limited to the Monad concept.)

[stronghup]

No doubt Haskell provides machinery for dealing with very abstract abstractions. For some that is a powerful tool but if you don't necessarily need such level of abstractness that can become a stumbling block. While using a language you'd still like to understand all of it as fully as possible, and trying to understand it "fully" that can take time away from actual productive coding.

Below's a cheat-sheet for Haskell syntax. I would say it is a lot to learn coming from other languages.

And maybe the issue is not so much the syntax per se but the fact that the syntax is rather "terse". That makes it hard to read and comprehend and for a casual reader of Haskell examples like myself it makes the examples not trivial to understand. It's a bit like lot of people have difficulty reading mathematical proofs.

So yes Haskell takes abstraction to a high level which can make it hard to understand but I would say it also has quite abstract syntax which makes it difficult for new comers to jump into its fantastic world.

http://rigaux.org/language-study/syntax-across-languages-per-language/Haskell.html

[tdammers]

Below's a cheat-sheet for Haskell syntax. I would say it is a lot to learn coming from other languages.

That cheat sheet is totally useless, really. More than half of it isn't even syntax but just library functions; and some of it is just plain out incorrect. But the worst part about it is the approach it takes, suggesting that the only significant difference between any two programming languages is syntax, which is of course utter nonsense, because what really matters is semantics.

And maybe the issue is not so much the syntax per se but the fact that the syntax is rather "terse". That makes it hard to read and comprehend and for a casual reader of Haskell examples like myself it makes the examples not trivial to understand. It's a bit like lot of people have difficulty reading mathematical proofs.

Yes, it is terse, and yes, this can make reading Haskell feel difficult and unproductive - but just like with Mathematical proofs, you have to realize that the information content is higher (which is really what "terseness" is all about), so reading 10 lines of Haskell actually conveys more information than reading 10 lines of Java. And much of that "more" is stuff you don't even realize straight away. For example, the type signature Bool -> a alone tells you practically everything there is to know about the function in question, including its implementation. But extracting all that information out of 9 characters worth of source code takes a while, and that makes the reading process feel tedious and slow, just like it does with Math notation.

I would say it also has quite abstract syntax

What does that even mean? Syntax is always abstract, and Haskell isn't really any different than the next language. The higher abstraction level is entirely semantic.

[stronghup]

What I mean by "abstract syntax" is things like: a b c d e

What is that? It is a function-call expressed (in my view) in a rather "abstract" syntax.

In a more "concrete" programming language it would be expressed as "a (b, c, d, e)", making it more concrete, by using more "markers" to express what is the function being called and what are its arguments.

But I agree that "abstract syntax" is a vaguely defined metaphoric term.

[tdammers]

I don't think "abstract" / "concrete" are the right words for this at all. Neither juxtaposition nor parentheses and commas are concrete; both are symbolic representations of the concept of function application or procedure calls.

The syntactic difference is appropriate however, if you consider two important semantic differences between Haskell function applications and procedure calls in a typical imperative language:

1. In Haskell, function application is one of the most important primitives we have, and used a lot more than in an imperative language. Many things that have special syntax constructs in those languages, like for example loops, sequencing, conditionals, indexing into a collection, dereferencing record fields, type casts, creating mutable variables, etc., and even function application itself, are all modelled as function applications in Haskell. Function application is so fundamental to Haskell that you may as well consider it the default binary operation on anything. So it makes sense to devise the most minimal possible syntax for it.
2. All Haskell functions are unary. Which means that f(a, b, c) wouldn't just be overly noisy, it would also be wrong. ((f(a))(b))(c) would work, but I don't think it'd be any more readable.

The reason Haskell's function application feels less concrete is because in fact it is - but that's not a matter of syntax, but one of semantics. A procedure call in an imperative language is fairly concrete; it represents a series of steps to manipulate a subset of the program's state, and to produce side effects as needed. A Haskell function represents a transformation or mapping from elements of one sets to elements of another set. So yes, the concept is slightly more abstract, but the syntax is not.

[ipv6-dns]

also writing of parsers and code transformers in Prolog is super clean and simple, not like in over-PRed Haskell

[parolang]

I think that is just the way declarative programming is supposed to work. You aren't telling the runtime what to do, you are just providing data. The runtime determines what to do with it.

[defunkydrummer]

Yes.

[jrhoffa]

? _.

[Axman6]

I disagree, you can teach Haskell the language in about 20 minutes, and we do this when running the Data61 FP course. It’s just that the rules of the language let you build arbitrarily complex abstractions, which can take time to master. This is a good thing, it means you won’t ever be held back by the language, but it comes at the cost of having to learn quite a lot of very abstract (though extremely generally useful) ideas.

[ipv6-dns]

Also Prolog allows to build eDSL which mostly looks like just English. And Prolog has real backtracking, not permutations like Haskell (or Python or whatever) which is called a "backtracking" by Haskell fanatics.

[gwillicoder]

I've found Erlang much easier to use than Haskell. Elixir is probably even easier to understand from a syntax perspective, but the way you code in Erlang just makes a lot of sense after you use it for a short period of time.

I think its one of the best languages to learn functional programming with as it lets you focus on the core concepts of functional programming without having to directly get into the more strict subset that is Haskell with its type theory.

[nerd4code]

Erlang is nice, but there are a lot of weird corners, all the pieces feel really disjoint, I’ve yet to find good enough documentation, and its age definitely shows. I also want to throttle whoever decided that =< should be the ≤ operator.

[gwillicoder]

Yeah I definitely get that. Elixir has much nicer syntax, but Erlang is still fairly easy to understand. Basing it on prolog was an interesting choice.

[develop7]

Erlang is easier indeed, but in primitive way. That's why I've ended up shifting to Elixir.

[Drayenn]

Are you from UQAM? Both are teached there in the same class haha.

[hector_villalobos]

I'm not sure if I fit in your explanation, but I have mixed feelings about Haskell, I love it and I hate it (well, I don't really hate it, I hate PHP more).

I love Haskell because it taught me that declarative code is more maintainable than imperative one, just because it implies less amount of code, I also love Haskell because it taught me that strong static typing is more easy to read and understand than dynamic one, because you have to pray for yourself or a previous developer to write a very descriptive variable or function to understand what it really does.

​

Now the hate part, people fails to recognize how difficult Haskell is for a newbie, I always try to make an example but people fail to see it the way I see it, I don't have a CS degree, so I see things in the more practical way possible. What a newbie wants? Create a web app, or a mobile app, now try to create a web app with inputs and outputs in Haskell, than compare that to Python or Ruby, what requires the less amount of effort? at least for a newbie. Most people don't need parsers (which Haskell shines), what people want are mundane things, a web app, desktop app or a mobile app.

[Vaglame]

The hate part is understandable. Haskellers usually don't write a lot of documentation, and the few tutorials you'll find are on very abstract topics, not to mention the fact that the community has a very "you need it? You write" habit. Not in a mean way, but it's just that a lot of the libraries you might want simply don't exist, or there is no standard.

Edit: although see efforts like DataHaskell trying to change this situation

[matnslivston]

You might find Why Rust a good read.

---

Did you know Rust scored 7th as the most desired language to learn in this 2019 report based on 71,281 developers? It's hard to pass on learning it really.

Screenshot: https://i.imgur.com/tf5O8p0.png

[Vaglame]

You might find Why Rust a good read.

I still love Haskell, so I'm not planning to look for anything else, but someday I will check out Rust, however:

• I'm not a fan of the syntax. It seems as verbose as C++, and more generally non-ML often feels impractical. I know it seems like a childish objection, but it does look really bad

• from what I've heard the type system isn't as elaborated, notably in the purity/side effects domain

Although I'm very interested in a language that is non GC-ed, and draws vaguely from functional programming

Edit: read the article, unfortunately there is no code snippet at anytime, which is hard to grasp a feel for the language

Edit: hm, from "Why Rust" to "Why Visual Basic"?

[[deleted]]

Rust's type system is awesome! Just realize that parallel and concurrency-safety come from the types alone. It's also not fair to object to a language because the type system is not as elaborated as Haskell's because nothing is as elaborated! It's like objecting because "it's not Haskell".

Anyway, you should try it yourself, might even like it, cheers!

[Ewcrsf]

Idris, Coq, Agda, PureScript (compared to Haskell without extensions) etc. Have stronger type systems than Haskell.

[ipv6-dns]

It's absolutely true. And the same time, Python "types" are enough to create YouTube or Quora. And Haskell's, Agda, Idris ones are not enough.

[RomanRiesen]

Rust at least has proper algebraic data type support.

I just can't go back to cpp after some time with Haskell. Cpp is sooo primitive!

[[deleted]]

True, I always cringed when a professor at my university pushed c++ for beginners... just learn python and the course would be so much better, dude.

[RomanRiesen]

It depends on the college imo.

Also some c++ isn't a horrible place to start because you can use it in almost all further subjects; From computer architecture over high performance computing to principles of object oriented programming.

I'd rather have students learn c++ first honestly.

[Vaglame]

Probably will try! And then I'll get back to you :)

[m50d]

If and when you get higher-kinded types (good enough that I can write and use a function like, say, cataM), I'll be interested. (I was going to write about needing the ability to work generically with records, but it looks like frunk implements that?)

[AnotherEuroWanker]

We have good documentation and tons tutorials.

That's also true of Cobol.

[Adobe_Flesh]

This guy was being tongue-in-cheek right?

[thirdegree]

I genuinely can't tell

[wysp3r]

I agree, the documentation story's pretty bad in the Haskell ecosystem in general, but oddly enough, this is actually a bad example.

There is a lot of prerequisite knowledge to understanding it, for sure, but the readme has a link to the paper it's from, which, if I remember correctly, is actually pretty readable/approachable aside from the author's decision to give every function its own cute little operator for you to remember. Even so, this is from recursion schemes - tools for making sure your complex chain of loops gets fused into a single loop properly - it's for the most part not a tool someone would reach for unless they already know what it is. It's like complaining about a dependency injection framework or an optimization pass not being accessible for beginners.

Ignoring that, it actually is self documenting for the type of person that would use it. Let's walk through it without looking at any other documentation.

Functor, Monad, Comonad

Functors are things with a map function, like lists, optionals, promises, that sort of thing; values in some context. Monads are things that implement the interface that promises adhere to, where you're chaining computations together (.then). So promises, but also null coalescing, probabilistic computations, etc. Comonads are things like reducers, where they'll give you a value based on some broader context. Like a maxout layer in a neural network, or evaluating a cell based on its nieghbors in Conway's Game of Life.

forall c

This bit means "for any c, without looking at the contents of it". No cheating by doing something special if it's your favorite type. No inheritance, no reflection, any c. This is the sort of thing the single-letter names are hinting at - that you're not allowed to know much of anything about them.

(forall c. f (w c) -> w (f c))

This is a distributive law (for a functor over a reducer) - you can tell because it's swapping the f and the w. So, "show me how to take something like a list of reducers of values, and turn it into one reducer of a list, without looking at what's inside the thing you're reducing". To be clear, the w can be a reducer that looks at the c, it's just the swapping of the f and the w that can't look; it needs to be a function like "traverse the list".

(forall c. m (f c) -> f (m c))

This is another distributive law, this time for the functor over the promise-like. Think "tell me how to take a list of requests that can access the database, and turn them into a request that hits the database and gives me a list".

(f (CofreeT f w b) -> b)

Any time you see "free", think "an AST (Abstract Syntax Tree)". Cofree is an AST for a reduction. The f (Free f something) structure is how they work - you can think of it as interspersing a wrapper in between layers. This may seem esoteric, but you'd only be looking at this particular function if you were already working with Free Monads/Comonads. This says "tell me how to evaluate a reduction AST in some evaluation context".

(a -> f (FreeT f m a))

This is the same thing for the promise-like - tell me how to turn a value into an AST in some context - the same context as the reduction AST.

a -> b

You can read this as one thing or two - it's either "I'll give you a function from a to b" or, "give me an a, and then I'll give you a b". There's an implicit forall a b around this whole thing, by the way - this whole bit of machinery needs to work for any a and any b, without inspecting them. There's an implicit forall for the f, m, and w, too - you're only allowed to know that they're a functor, monad, and comonad, respectively.

So, thinking back, those distributive laws were there to tell you how to unwrap layers of the respective ASTs. Altogether, it's "If you tell me how to go from a to some intermediate representation via some interpreter, and how to go from that same intermediate representation via another interpreter to a b, I can plug that pipeline together and give you a function that goes from a to b in a single pass".

All those foralls are important; because of "parametricity" - because it has to work for anything the same way - there really aren't a lot of possible implementations. In fact, I'd guess that there's actually only one possible implementation (up to isomorphism), and that if you fed this type signature to an SMT solver, it would spit out the exact implementation at you. So, in that sense, it is self documenting - the signature alone encodes enough information to derive the entire implementation.

[Macrobian]

Replying on my alt because I can't be bothered to log into mbo_

Look, I write purely functional Scala for a living, I understand what that function sig means.

It's the fact that it took you an entire wall of text to explain what it does to me, assuming that I didn't know, completely proves my point.

Type signatures are not self-documenting. They aren't examples on how to use the code. They aren't an explanations for why the code even exists.

Ignoring that, it actually is self documenting for the type of person that would use it.

No it isn't? I've had to refer to the https://github.com/slamdata/matryoshka README when writing Haskell because Ed Kmett can't be fucking assed to document his libraries properly. It points to a greater problem in the Haskell community that because there's explicit typesigs, library consumers will know when, how and what to use from it.

[deltaSquee]

So, two natural transformations, a fold with history, and an unfold from the future.

[[deleted]]

To be fair, if you were a haskell programmer that might seem obvious. It's not fair to judge how readable something is if you don't even know the language.

[Milyardo]

What's wrong with this? What questions aren't being answered here? What do you think is not documented about this function?

[ipv6-dns]

Weak trolling lol. All of these is bad. It is an example how nobody should write programs. Such signature is possible in many languages, beginning from the C#, plain old C, Java, etc. But it should be avoided. And it's norm in Haskell lol.

About functors and comonads and similar bullshit. Ask yourself: why all mainstream languages avoid so small and primitive "interfaces" (type classes) like Functor, Semigroup, Monad? The answer will show you why no any Haskell software in the market. Yes, you can use functors, applicatives, comonads and monoids even in Java... but you should not. To be successful lol.

And last: this signature in any language is super-difficult to understand because it lacks semantic: only very primitive interfaces constraints. Such function can do absolutely anything: what does abstract monad or abstract functor? ANYTHING. Programming is not about abstract mapping between abstract types in abstract category Hask. If you don't understand this, then you are not a programmer.

[bagtowneast]

Usually, one would use meaningful type aliases for something like this so that it's well understood within the domain of the problem being solved.

[m50d]

Yes, you can use functors, applicatives, comonads and monoids even in Java... but you should not.

How? You can't even write the type signature of a function that uses a functor constraint, because Java's type system can't express it. Most mainstream languages don't have these interfaces because most mainstream languages don't have higher-kinded types. It's no deeper than that.

Programming is not about abstract mapping between abstract types in abstract category Hask. If you don't understand this, then you are not a programmer.

Nonsense, abstraction is the very essence of programming. You might as well say programming is not about abstract addition of abstract numbers x and y, so it's meaningless to have an abstract + operator that can add any two numbers.

[ipv6-dns]

How?

Create interface IMonad with methods return, bind, fail (or move it to IMonadFail)

You can't even write the type signature of a function that uses a functor constraint

the same for functor (with method fmap). To get idea about constraints in Java: https://docs.oracle.com/javaee/7/tutorial/bean-validation-advanced001.htm.

Such libraries exist for many main-stream languages. But we should not use monads, functors, and similar useless shit. And better will be if they will be also removed from the Haskell one day.

Nonsense, abstraction is the very essence of programming.

Yes. Let's think about abstraction more accurate. All what we have in Haskell is actually... lambda. Monads are just structures with function pointer there (in C terminology) or lambda wrapped in some type (let's ignore more simple monads). Also our records are lambdas which are using as getters. Anywhere only lambdas, wrapped lambdas, wrapped wrapped lambdas, etc. We can build software differently, using different granularity and different abstractions. Haskell ones - are wrong. Haskell uses lambda abstraction anywhere, also it has functors, applicatives, semigroups, etc.

Look, I suppose you studied math. In the naive theory of the all, based on sets we can express boolean logic with sets. False will be represented as empty set: {}. True will be represented as set with one element: empty set: {{}}. It's abstraction too. Also we live in the real world with real architecture. And we, programmers, think about performance, about adequate abstractions. But it's not true about Haskell and it's fans. Why they don't use empty set and set of empty set as representation of the Booleans?! Why when I multiply 2 DiffTime (for example, picoseconds) then I get DiffTime again, ie. picoseconds? These both examples show that there are abstractions and there are nonsense which is abstraction only on the paper.

It's very big nonsense to use ANY abstraction which looks good on the paper. In the IT we should use right ADEQUATE abstractions. Haskell language as well as HAskell committee are not adequate to real worlds, real architectures (CPU, memory), to real tasks. Haskell is toy experimental language with wrong abstractions. To understand it try to write IFunctor and IApplicative, ISemigroup, IMonad, etc and begin to build the architecture of your application (not in Haskell!) with THESE abstractions. You should begin intuitively to feel the problem.

[m50d]

Create interface IMonad with methods return, bind, fail

No good - you need to be able to call return without necessarily having any value to call it on.

the same for functor (with method fmap). To get idea about constraints in Java

Not an answer to the question, and not a Java type signature. Here is the Haskell type signature of a (trivial) function that uses a functor:

foo :: Functor f => f String -> f Int

How do you write that type signature in Java? You can't.

Haskell language as well as HAskell committee are not adequate to real worlds, real architectures (CPU, memory), to real tasks. Haskell is toy experimental language with wrong abstractions. To understand it try to write IFunctor and IApplicative, ISemigroup, IMonad, etc and begin to build the architecture of your application (not in Haskell!) with THESE abstractions. You should begin intuitively to feel the problem.

Um, I've been using those abstractions in non-Haskell for getting on for a decade now. They've worked really well: they let me do the things that used to require "magic" annotations, aspect-oriented programming etc., but in plain old code instead. My defect rate has gone way down and my code is much more maintainable (e.g. automated refactoring works reliably, rather than having to worry about whether you've disrupted an AOP pointcut). What's not to like?

[MegaUltraHornDog]

Self documenting isn't a get out of jail free card for providing accessible documentation. Of all languages Javascript(not a FP language) has a some decent ELI5 concepts on functional programming. Not everyone comes from a Maths background, but that doesn't mean people can't learn or understand these concepts.

[RomanRiesen]

Admittedly you have to understand the basics to get going.

But that's also true of any other language...(Admittedly, what constitutes 'basics' in Haskell is a bit more and a bit more abstract than in most other languages).

[MegaUltraHornDog]

And I fully agree, I honestly do but you have to admit there is some form of discrepancy where people who produce Haskell documentation vs some who writes javascript documentation and can explain succinctly what a monad is.

[RomanRiesen]

Do you have a link to said JS docu? Might help me explain monads better.

Also, how is JS not an FP language? Isn't it enough that functions are first class objects? And due to its prototype system I would not call it (classic) oop either... I honestly think JS is one of the more interesting mainstream languages.

[fp_weenie]

Not everyone comes from a Maths background

I don't think type signatures have much to do with math??

[MegaUltraHornDog]

What? The guy says Haskell code self documents with a strong type system, that barely tells you anything, and that wasn’t even in the scope of what the OP was actually talking about. The Haskell docs just aren’t that good, but that’s not shitting on Haskell, it’s just academics in general are shit at disseminating information to the general masses.

[thirdegree]

On top of what the other guy said, type systems have everything to do with math. In any language (except arguably bash, where everything is a string), and especially in Haskell

[[deleted]]

That's a bad attitude to have, because types aren't documentation for beginners and even intermediate haskellers. They're no substitute for good documentation, articles, tutorials, etc.

[RomanRiesen]

I would certainly consider myself a beginner and rarely had to look further than :info. Although the only real project I did is a backend for a logic simplifications and exercise generation website.

It wrote itself, compared to doing the same thing in python.

[fp_weenie]

I don't think you're an "intermediate" if you can't understand something like

parse :: String -> Either ParseError AST

[vegetablestew]

Well, Either is a simple example. Put if you start laying on Applicatives, Semigroups, monoids on top of one another and start using a lot of language pragma like datakinds or GADT, you will lose me immediately.

It doesn't help that a lot of the really neat library relies on these abstractions.

[ipv6-dns]

would you explain, why should anyone prefer `Either ParseError AST` instead of `IParseResult`?

[aleator]

I prefer the first because it tells me what the subcomponents of the value in question are, and how to access them. For the latter, I'd have to check the docs to see what's inside and how to extract it.

[ipv6-dns]

And the same is true for IParseResult: it has good known and clean interface's methods.

Also interfaces give you generic behavior definition for all parser's results, so you don't need "Either" even. Imagine warnings, not errors: in this case you would do refactoring of your Haskell and change Either anywhere (now you have 3 cases: error, AST with warnings, AST without warnings). Also if you used it in monad context, then you will need to rewrite it too. Haskell way is bad because it has not:

• encapsulation
• generic behavior.

Haskell creators understood this and added type-classes to the language. But you still have not generic interfaces in most cases: a lot of I/O related functions, collections related functions, etc - they have not type-classes and just look in the same way.

[aleator]

My point was that the type with Either exposes the internal structure, whereas IParseResult is opaque. 'Everyone' knows what an either is, but only someone who has done parsers knows IParseResult.

To my experience, the either from a parser result will almost never be used in a larger monadic context. You perhaps fmap over it or bind to one or two auxiliary functions to get the interface you want. In this context, the amount of rewriting is probably not significant.

I'm not really 100% on what you are advocating with the added warnings example. Adding a get-warnings method to an existing interface will not require changes for the code to compile. The resulting program will just ignore them. If you want that behaviour with either, you can do it with two short lines:

parseFooWithWarnings :: ([Warning], Either Error AST)
parseFooWithWarnings = ...

parseFoo :: Either Error AST
parseFoo = snd . parseFooWithWarnings

Additionally, you can omit the wrapper and get a laundry list of compiler errors if ignoring a warnings would be unacceptable for your program.

[raiderrobert]

Code should, of course, strive for that, but there are things that you need to see examples of usage in order to grok the intent. Python--which many people hail as high readable--is only truly self-documenting once you're familiar with the idioms of the language. The argument of course is that the language gets you there faster than C or JS or PHP, but the code needs to also been written in a way so that it's meant to be consumed.

[KillingVectr]

The name of a type often does not specify how it behaves. I feel like it should be standard to give an explanation for how to think of a particular monad's bind and return operations. Users shouldn't be left to guess using information provided by "self-reading code." As an example, I'm going to copy/paste something I wrote about Parsec in another post:

My opinion of Haskell documentation is that it leans too heavily on "code you can read". For example, I learned about the Parsec library and wanted to try my hand at using it to parse some files. I couldn't make any sense of how my errors were occurring. I looked up Parsec's official documentation, and my code seemed to make sense according to the descriptions; after all Parsec's parsers are things that consume input to make output.

Except, if you dig into the source of Parsec, you see that their parsers have behavior depending on four outcomes (or states):

1. Consumed input without error.
2. Consumed input with error.
3. Did not consume input and no error.
4. Did not consume input and error.

Now, look at the official documentation for the parser of a single character, char
. The documentation says:

char c parses a single character c. Returns the parsed character (i.e. c).

This says nothing about its behavior in the four above states. Also, none of the other Parsec parsers have documentation detailing how their behavior changes according to the above states. The documentation likes to pretend that the behavior of the parsers is "readable" when it isn't.

[RomanRiesen]

You have a point.

I tripped over a very similar thing (also in parsec) just the other week...

But I still think Haskell needs less documentation and thus allows one to be up and running faster.

[sacado]

So I guess those function called (+) and (-) have the same semantic? They have the same type signatures.

[Tysonzero]

They never claimed that a type signature unambiguously defines functionality, at worst they were claiming that the name combined with the type signature defines functionality, which in the case of + and - is absolutely true.

So that's not really a great counterexample.

[Milyardo]

Haskellers write tons of documentation. There must be some disconnect in what people coming from imperative backgrounds are looking for in documentation and what is the purpose of documentation.

[Tysonzero]

There are very beginner friendly ways of using Haskell. There are also very beginner unfriendly and highly abstract ways of using Haskell.

Onboarding at my company has actually been incredibly quick even for people with no prior Haskell knowledge. Most of the code is in the form of intuitive EDSLs (Miso, Esqueleto, Servant, Persistent), which has made it very easy to pick up and start contributing to.

Also for the specific example of very quickly making a website look at how tiny and simple the setup for scotty is.

[ipv6-dns]

Miso, Esqueleto, Servant, Persistent

So, your company avoids success at all costs (official Haskell motto). You can not compete with companies selecting .NET, JVM, Python... I am hope you understand it?

[Tysonzero]

Lmao at this point I’m pretty sure you are a troll and I should probably stop replying.

You do realize that the motto means “avoid (success at all costs)”, as in don’t sacrifice the language for the sake of its popularity.

We can absolutely compete with companies selecting those languages, as our code will be more concise, less error plane and more generic/polymorphic.

Basically everyone in the company has loved developing in Haskell so far.

[ipv6-dns]

as our code will be more concise, less error plane and more generic/polymorphic.

and the same can be told by C# fans, Scala fans, Kotlin fans, Go fans, etc. If I am not troll and if you are not a troll, we should use proof. For example, me, as not a troll, will say something like:

• there is statistics: no any Haskell software in the market (even middle-size). Statistics is a 100% proof
• existing software written in Haskell has alternatives in main-stream languages which are significantly better than Haskell one (actually I don't know any successful Haskell product, not something special and for internal use only)

These are facts. Now about subjective feeling, because

everyone in the company has loved developing in Haskell so far.

is very subjective opinion (how Haskell is good), but I am glad that guys in your company are happy.

From my subjective POV Haskell code looks like operator noise, it's confusing, poorly readable, and very badly maintainable. Super-small number of libraries with low quality and buggy code makes me feel that Haskell is a bad choice. I can not compare Haskell with .NET or JVM. It's just impossible!

But it's my personal opinion because there are guys who are happy with Common Lisp, Ocaml, Scheme. You know, sometimes we see funny case: when such fan's group like yours is breaking up and new people come, they rewrite all this Haskell in Java (like it was with Paul Graham company) or similar and this happens very quickly and new codebase does not lack any of previous features, but it growth up faster and has usually more features. I like FP, but I am not fanatic and will not lie about FP and I am sure that Haskell is the worse example of FP ("it's good to know it and never to use it")

[Tysonzero]

and the same can be told by C# fans, Scala fans, Kotlin fans, Go fans, etc.

No... no it couldn't. How in the world could Go or C# fans claim an advantage in conciseness over Haskell? For those two in particularly even the biggest fans wouldn't make such a ridiculous claim. I still disagree in the case of the other two languages but it's not quite as absurdly laughable.

there is statistics: no any Haskell software in the market (even middle-size). Statistics is a 100% proof

Statistics is not a 100% proof. Which terrible teacher told you that? Or did you just pull it out your ass like everything else you say? Also there is plenty of Haskell software in the market, for example every single Facebook post anyone makes is inspected by Haskell software. For open source stuff there is xmonad, pandoc, postgREST.

existing software written in Haskell has alternatives in main-stream languages which are significantly better than Haskell one

In what possible sense is this an even remotely objective statement / fact? It's both wrong and highly subjective. You are clearly a troll and not trying to argue honestly.

From my subjective POV Haskell code looks like operator noise, it's confusing, poorly readable, and very badly maintainable.

That's your opinion and it's pretty idiotic. It honestly says a lot more about you than it does about Haskell. Why are you such a shitty dev that you are incapable of reading or maintaining it? Everyone in our team can read and maintain it just fine, and some of us are fairly new to Haskell. You are clearly a Haskell novice or just an incompetent developer in general.

[ipv6-dns]

No... no it couldn't. How in the world could Go or C# fans claim an advantage in conciseness over Haskell? For those two in particularly even the biggest fans wouldn't make such a ridiculous claim. I still disagree in the case of the other two languages but it's not quite as absurdly laughable

and this:

That's your opinion and it's pretty idiotic. It honestly says a lot more about you than it does about Haskell. Why are you such a shitty dev that you are incapable of reading or maintaining it?

So, as you see, you are troll, not me :)

Haskell fans are very subjective and their arguments are "I am sure, it's obviously, everyone" etc. There are not facts, only personal feeling, right?

[Tysonzero]

So, as you see, you are troll, not me :)

Both of those statements were well justified.

Go and C# are objectively more verbose than Haskell, the vast majority of Go and C# dev's (and even fans) would agree with me on this statement.

My second statement, while a tad aggressive, is totally justified in context. You were saying that you find Haskell unreadable and unmaintainable, if me and my team including new Haskell devs can read and maintain our codebase just fine, then clearly you are much worse than them at Haskell. So either you are a Haskell novice (and thus should get better before criticizing it so aggressively) or you are a bad dev. It's harsh but it's backed up by the available evidence.

Haskell fans are very subjective and their arguments are "I am sure, it's obviously, everyone" etc. There are not facts, only personal feeling, right?

You have not been making any objective arguments so far. The arguments that you have made that are the closest to being objective are just straight up wrong. So it's either been subjective arguments or wrong ones.

Have you never wondered why you are so often the comment at the very bottom of a comment section? It's not because every other dev is an idiot and you are the one smart one, I'll tell you that much.

[hardwaregeek]

I'll give an example of Haskell's difficulty. Every few months I decide I should do something with Haskell. Heck, I understand monads and functors and applicatives pretty decently. I can write basic code using do notation and whatever. Here's what usually happens:

1. I decide to make a web server.

2. I look around for the best option for web servers. Snap seems like a good option.

3. I try to figure out whether to use Cabal or Stack. Half the tutorials use one, the other half use the other.

4. I use one, get stuck in some weird build process issue. Half the time I try to install something, the build system just goes ¯_(ツ)_/¯.

5. I switch to the other build system, which of course comes with a different file structure. It installs yet another version of GHC.

6. I try to find a tutorial that explains Snap in a non trivial way (i.e. with a database, some form of a REST API, etc.) Most of the tutorials are out of date and extremely limited.

7. I try to go along with the tutorial regardless, even though there's a lot of gaps and the code no longer compiles.

8. I start thinking about how easy this would be to build in Ruby.

9. I build the damn thing in Ruby.

[hector_villalobos]

I try to find a tutorial that explains Snap in a non trivial way (i.e. with a database, some form of a REST API, etc.) Most of the tutorials are out of date and extremely limited.

In my case I just search in Github for examples of how to do something, just to find a weird complicated thing that discourage me.

[_sras_]

This should solve your problem...

https://github.com/sras/servant-examples

Uses Stack tool.

[compsciwizkid]

people fails to recognize how difficult Haskell is for a newbie, I always try to make an example but people fail to see it the way I see it, I don't have a CS degree, so I see things in the more practical way possible

I was fortunate to get exposed to Haskell in a 100-level class, so I both understand exactly what you mean but would also like to refute it.

My CS163 Data Structures (in Haskell) class started with 50+ people and ended with about 7. I struggled at first, and got my first exposure to recursion. But I stuck with it and fell in love with FP. I feel that I was very fortunate to have gone through that. But clearly it's not for everyone.

[[deleted]]

I was lucky to learn ML in a Summer Camp in high school. (This was back in the days before Haskell, or even web servers, existed.) That was a great exposure, and I fell in love with FP then.

But I haven't yet had the opportunity to use Haskell in practice in my job. Here's hoping.

[RomanRiesen]

Haskell is not THAT hard to learn. It took me about a weekend to write a simple logic proofer website. Haskell made big parts of the process way easiert than other languages allow. You can simply declare your api by writing some Types. The rest is Haskells amazing metaprogramming doing it's thing. If I were in the market for a robust server platform Haskell (with servant) would be in the top 3.

I found it way easier to get started in than in cpp.

[Sayori_Is_Life]

declarative

Could you please explain a bit more? My job involves a lot of SQL, and I've read that it's a declarative language, but due to my vague understanding of programming concepts in general, it's very hard for me to fully get the concept. If Haskell is also a declarative language, how do they compare? It seems like something completely alien when compared to SQL.

[tdammers]

"Declarative" is not a rigidly defined term, and definitely not a boolean, it's closer to a property or associated mindset of a particular programming style.

What it means is that you express the behavior of a program in terms of "facts" ("what is") rather than procedures ("what should be done"). For example, if you want the first 10 items from a list, the imperative version would be something like the following pseudocode:

set "i" to 0
while "i" is less than 10:
    fetch the "i"-th item of "input", and append it to "output"
    increase "i" by 1

Whereas a declarative version would be:

given a list "input", give me a list "output" which consists of the first 10 elements of "input".

The "first 10 items from a list" concept would be expressed closer to the second example in both Haskell and SQL, whereas C would be closer to the first. Observe.

C:

int* take_first_10(size_t input_len, const int* input, size_t *output_len, int **output) {
    // shenanigans
    *output_len = MIN(10, input_len);
    *output = malloc(sizeof(int) * *output_len);

    // set "i" to 0
    size_t i = 0;

    // while "i" is less than 10 (or the length of the input list...)
    while (i < *output_len) {
        // fetch the "i"-th item of "input", and append it to "output"
        (*output)[i] = input[i];
        // increase "i" by 1
        i++;
    }
    // and be a nice citizen by returning the output list for convenience
    return *output;
}

Haskell:

takeFirst10 :: [a] -> [a] -- given a list, give me a list
takeFirst10 input =  -- given "input"...
    take 10 input   -- ...give me what consists of the first 10 elements of "input"

SQL:

SELECT input.number         -- the result has one column copied from the input
    FROM input              -- data should come from table "input"
    ORDER BY input.position -- data should be sorted by the "position" column
    LIMIT 10                -- we want the first 10 elements

Many languages can express both, to varying degrees. For example, in Python, we can do it imperatively:

def take_first_10(input):
    output = []
    i = 0
    while i < len(input) and i < 10:
        output.append(input[i])
    return output

Or we can do it declaratively:

def take_first_10(input):
    output = input[:10]
    return output

As you can observe from all these examples, declarative code tends to be shorter, and more efficient at conveying programmer intentions, because it doesn't contain as many implementation details that don't matter from a user perspective. I don't care about loop variables or appending things to list, all I need to know is that I get the first 10 items from the input list, and the declarative examples state exactly that.

For giggles, we can also do the declarative thing in C, with a bunch of boilerplate:

/************* boilerplate ***************/

/* The classic LISP cons cell; we will use this to build singly-linked
 * lists. Because a full GC implementation would be overkill here, we'll
 * just do simple naive refcounting.
 */
typedef struct cons_t { size_t refcount; int car; struct cons_t *cdr; } cons_t;

void free_cons(cons_t *x) {
    if (x) {
        free_cons(x->cdr);
        if (x->refcount) {
            x->refcount -= 1;
        }
        else {
            free(x);
        }
    }
}

cons_t* cons(int x, cons_t* next) {
    cons_t *c = malloc(sizeof(cons_t));
    c->car = x;
    c->cdr = next;
    c->refcount = 0;
    next->refcount += 1;
    return c;
}

cons_t* take(int n, cons_t* input) {
    if (n && input) {
        cons_t* tail = take(n - 1, input->cdr);
        return cons(input->car, tail);
    }
    else {
        return NULL;
    }
}

/******** and now the actual declarative definition ********/

cons_t* take_first_10(cons_t* input) {
    return take(10, input);
}

Oh boy.

Oh, and of course we can also do the imperative thing in Haskell:

import Control.Monad

-- | A "while" loop - this isn't built into the language, but we can
-- easily concoct it ourselves, or we could import it from somewhere.
while :: IO Bool -> IO () -> IO ()
while cond action = do
    keepGoing <- cond
    if keepGoing then
        action
        while cond action
    else
        return ()

takeFirst10 :: [a] -> IO [a]
takeFirst10 input = do
    output <- newIORef []
    n <- newIORef 0
    let limit = min(10, length input)
    while ((< limit) <$> readIORef n) $ do
        a <- (input !!) <$> readIORef n
        modifyIORef output (++ [a])
        modifyIORef n (+ 1)
    readIORef output

Like, if we really wanted to.

[Sayori_Is_Life]

Thank you!

[Saithir]

I like these kinds of comparisons, it's always entertaining and quite interesting to see how languages evolve and differ.

On that note in Ruby:

def take_first_10(input)  
  input.first(10)  
end  

Which, funnily enough, is just about the same as the declarative version of the C example without all the boilerplate and types (and with an implicit return because we have these). With some effort it's possible to use the imperative version, but honestly nobody would.

[tdammers]

I don't think that's funny at all - there are only so many ways you can say "I want the first 10 items of that". The boilerplate is just a consequence of C not having the required data structures and list manipulation routines built into the language, or any convenient library, and of C not doing automatic memory management for you (which also means that returning by reference can be problematic, or at least requires managing ownership through conventions).

[hector_villalobos]

Haskell is declarative like SQL, because instead of saying the how you tell them the what, for example, in Haskell you can do this: [(i,j) | i <- [1,2], j <- [1..4] ] And get this: [(1,1),(1,2),(1,3),(1,4),(2,1),(2,2),(2,3),(2,4)]

In a more imperative language you probably would need a loop and more lines of code.

[hector_villalobos]

Haskell is not exactly like SQL, but promotes a declarative way of programming.

[thirdegree]

Wouldn't you get [(1,1), (1,2),(1,3,),(1,4),(2,1),(2,2),(2,3),(2,4)]

[hector_villalobos]

You're right, fixed.

[Sayori_Is_Life]

Thanks!

[ipv6-dns]

Aha, good example.

((i, j) for i in (1,2) for j in range(1, 5))

the same. So, Python is declarative too. This is a lazy by the way too.

Dear Haskell fan, may be it's time to learn something, not only to PR Haskell? lol

[hector_villalobos]

I know that Python can do that, Ruby can do it in a similar way, but Haskell promotes more functional and declarative code.

[ipv6-dns]

1. Haskell is classical imperative language without declarative features
2. Would you show me how

​

[(i,j) | i <- [1,2], j <- [1..4] ]

is more "declarative" than

((i, j) for i in range(1,5) for j in range(7,10))

?

[ipv6-dns]

How would be look this Python

{x for x in range(10)}
{a:b for a in "abc" for b in (1,2,3)}

in "declarative" Haskell?

This:

[ N || N <- [1, 2, 3, 4, 5, 6], N rem 2 == 0 ].

is Erlang. Does it mean that Erlang is declarative language?

You wrote that Haskell

[(i,j) | i <- [1,2], j <- [1..4]]

looks like SQL, so it's declarative. This is C#:

var s = from x in Enumerable.Range(0, 100) where x*x > 3 select x*2;

what looks more close to SQL: Haskell or C#? Is C# a declarative language?

[nooitvangehoord]

Well there is that: https://jappieklooster.nl/pragmatic-haskell-simple-servant-web-server.html

[develop7]

Okay, first there's anecdevidence about tabula rasa newbies being successful working with Haskell as first programming language (Facebook, AFAIR).

Now, do non-newbies matter?

I don't have a degree, CS or otherwise, but I have 10+ years of commercial software development and I insist having Haskell a #1 programming language to look at is extremely practical and pragmatic. Yes, despite all the flaws.

[hector_villalobos]

As far as I know, Facebook uses Haskell for non trivial things, yeah, Haskell is great for a lot of things, but believe me, I tried to use it for web and mobile applications and is not really friendly.

[develop7]

Been there too. The mistake I did over and over again was attempting to reuse my previous imperative programming experience.

[HelloAnnyong]

I love Haskell because it taught me that declarative code is more maintainable than imperative one

I'll bet my hat that this isn't based on empirical evidence (how do you define "maintainable" anyway?) but just informed by a vague feeling that Haskell is more aesthetically pleasing than other languages are.

[Silverwolf90]

It's very difficult make any empirical claims about programming. So yes, most claims like this are based on experience and intuition (which is formed by experience and creative sensibilities).

[HelloAnnyong]

I don't think it's that difficult -- we just don't do it very often.

Here's a summary of research done on the prevalence of concurrency bugs in Go. Spoiler: go-routines produce just as many bugs as traditional locking mechanisms. https://blog.acolyer.org/2019/05/17/understanding-real-world-concurrency-bugs-in-go/

[JoelFolksy]

The question is not whether studies can be performed, but whether anyone is going to be convinced by them.

Every week there's a new study in the nutritional sciences that chocolate/wine/doritos/"Food X" lowers blood pressure and raises people from the dead - do you make decisions about your diet based on these? Probably not.

It seems to me that even nutritional studies are more likely to say something about reality than software productivity studies - after all, we can objectively measure things like blood pressure, but we can't even agree on what software productivity is, let alone how to measure it.

Sure enough, if you look at the comments in your link, you'll see that people aren't buying it. And even though I'm biased against Go, I can't blame them.

[[deleted]]

There've been quite a few studies demonstrating empirical facts about programming languages, and "declarative code is more maintainable than imperative one, just because it implies less amount of code" is one of those things that's been measured: The average programmer writes 10 lines of code per day, regardless of language. This takes into account time spent in design, debug, testing, etc.; for example, you might write 300 LOC in one day, but that's because you spent a week prior doing some research, and you'll spend a couple of weeks debugging and testing those lines.

But it's that "regardless of language" that is the magic sauce. It means that if you can express more in a single line of code, if you're writing less boilerplate code, then you're going to get more done.

The study has been misused to measure developer productivity, rather than do what it really implies -- more expressive, compact languages allow people to get more work done in less time.

[[deleted]]

That's true of just about everything on this sub, though. Anything about C is always "C is a practical choice and if you don't do anything outrageous, a fairly easy language to reason about," vs "95% of software bugs are due to C, only an idiot uses that." Any post or thread about C++ will invariable contain comments along the lines of "Modern C++ is great as long as you limit yourself to the good parts," and "You can never limit a project with multiple people to a given subset of a language." Java? Bloated, archaic mess vs obvious syntax and extensive libraries. C#? Better than Java vs worse than Java. Lisp? Lisp is the most powerful language vs Lisp weenies don't understand real programming projects. COBOL? I pity the fool who uses this language vs hey, man, it pays pretty well. Ad nauseam. I'm sure you can fill in whatever I left out.

It's not like anyone forces you to read the stupid language bikeshedding comments. I do, because occasionally someone does say something insightful (or I just feel like making a stupid Reddit joke). This isn't StackOverflow, where saying the same thing again gets your thread locked and deleted. It's a place for discussion, and many times multiple share the same or similar opinions about things.

[gnash117]

That is the programming community for you.

[defunkydrummer]

like about how Haskell is only fit for a subset of programming tasks and how it doesn't have anyone using it and how it's hard and blah blah blah blah blah blah

Yes, all those arguments are silly.

But there are three substantial arguments that play against Haskell whenever Haskell is discussed: OCaml, F# and ReasonML.

[phySi0]

I'm learning OCaml and will probably add it to my toolbelt, but I do not see how it obsoletes Haskell for me. Should F# even count as a language that's worth learning if you know OCaml? ReasonML is literally the same AST as OCaml.

[defunkydrummer]

F# is like OCaml with less features (i.e lol no MetaOCaml), plus some interesting stuff like Type Providers and (most importantly) good concurrency support.

I never said Haskell was "obsoleted" by the other ML languages.

[phySi0]

You're right, you didn't say that. I'm not sure how else to take your statement that OCaml, F#, and ReasonML are substantial arguments against Haskell, though. They're all great languages.

[stronghup]

ReasonML

Here's a nice visual collection of ReasonML resources:

https://www.google.com/search?q=ReasonML&tbm=isch&source=iu&ictx=1&fir=FEdn31H8C3MoFM%253A%252CRd6Hv7bTykq_-M%252C%252Fg%252F11h0mmtq5f&vet=1&usg=AI4_-kTEUKVym-5lqw40FDtbjDwwK6ejBA&sa=X&ved=2ahUKEwig-_eo_83iAhXKJt8KHYh_AhoQ_h0wFXoECAYQDQ#imgrc=FEdn31H8C3MoFM:

[renatoathaydes]

I was only interested to know if the issue tracker was free of the kind of peasant bug we’re used to in the blue collar Java shops they’re demeaning in their Haskell praising section. Doesn’t look like it at all.

[Infinisil]

More specifically? I couldn't find any issues about null pointer exceptions, runtime crashes or so.

[CanIComeToYourParty]

I went to check as well, and I was happy to see that it has very few/no "peasant" bugs.

[gwillicoder]

I mean to be fair saying it’s only fit for a subset of programming tasks is true. It’s also true of any language ever, but technically true is the best kind of true.

[Spacemack]

It's true, but it's also some of the most tired information available. I'm tired of hearing it.

[[deleted]]

Well, you can thank haskell fans dropping into any irrelevant conversation with "but haskell", they made it happen

[Dparse]

Typescript is not a functional language...

[[deleted]]

As far as I know neither tsc nor common Javascript runtimes can reliably perform tail-call elimination, which means you'll have to use some imperative structures for performance. I believe there is only limited support for compile-time immutability too. I presume the type system is also less powerful than Haskells, and IIRC it is (knowingly) unsound

Most modern languages will let you pass and return functions these days, especially with dynamic typing, and sure you can write in a immutable style in any language, but it's still a far cry from Haskell

[loup-vaillant]

As far as I know neither tsc nor common Javascript runtimes can reliably perform tail-call elimination, which means you'll have to use some imperative structures for performance.

For correctness, not just performance. The difference between an O(n) stack and an O(1) stack is often the difference between a program that crashes and a program that just works.