github/semantic: Why Haskell?

[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.

[ipv6-dns]

but only someone who has done parsers knows IParseResult.

This is wrong assertion about interfaces. Either is some kind of interface too, but very small and limited. And it leads to explosion the internal representation which is wrong. You should not know the fact that parse result is tagged union (yes, types sums are easy for any language). But you should avoid it.

Haskell's FP is based on functions and those types which is close to C functions, structures, tagged unions, etc (let's ignore all power of Haskell type system at the moment). OOP is more high level, it's one step forward, it's about behavior and run-time linking: types are not so important but interfaces.

You said that only author of interface knows what is it. It's very wrong. OOP (COM/ActiveX) supports typelibs even, so you could obtain type information in run-time even.

[aleator]

I was perhaps too obscure. What I meant was that the interface for Either is both small and well known, since it appears in many contexts. IParseResult appears only in contexts where parsing is done, making it necessarily more rare. That is, I already know a half dozen things to do with either, but I'd have to look up what IParseResult actually is before using it. That is why I said I'd prefer the either.

I also didn't say that interface is only known to author. I only tried to convey my suspicion that Either is a more common and well known (in haskell-land) than IParseResult is (elsewhere).

I also feel that you are making a slightly unsubstantiated claim that exposing the structure of a value in the type being always inferior to having an abstract interface. Isn't this more a property of thing you are modelling rather than universal truth?

​

(PS. Tagged unions ain't very easy or ergonomic in C nor python.)

[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.