I can't believe I wasted my whole afternoon with this

I use xmonad and it's great!
I didn't even have to learn Haskell at all.
Fuck your shit OP.

If you can't present the concept as it would look in C then you don't understand it. If it looks retarded in C then you've discovered it was retarded to begin with.

It's very easy to handle in C but it's not as useful unless you want first-class blocks. It also makes the stack explode.

for example, the basic building block of haskell represented in c is
struct { int ready; union { void* (*thunk)(); void* done; }}
It's not necessarily useful to represent it in C, you see.

Pick one faggot.

So sorry you "lost" time you could have spent watching cartoons for children.

What's the benefit of Haskell vs other FP languages?

He's right though. There's a quality component to learning.

Funnily enough it has had the most work put into it. If you're going to spend your time optimizing a high-level program out the ass, you should probably do it in Haskell. It has a reasonably well selected feature set: if the type system can control something it's either easy or balls-out hard, so you can tell if it's worth it pretty quickly.

So, you found 5 answers to your question, but since you immediately shit your pants whenever you see math, you couldn't comprehend them.

At least try to feel inadequate, and maybe your dumb ass will do something about it.

Maybe it's easier to start with some concrete monad, not an abstract concept. What programming language are you most familiar with?

If you know Java 8: Stream and Optional are monads, sort of. Notice both have a map() method, which returns monadic type. This is why we say, these are monads.

The return type of map is essential. Everything is wrapped in monad. Remember: You can't get anything out of the monad.

That's just like my opinion about monads, anyway.

Say, you have three teachers trying to teach you about concept X. The first teacher tells you concept X means A, but the second teacher says concept X is actually B, while the third teacher says the previous teachers are wrong and it's more like C except it isn't so you are more or less back to square one.

Are you stupid for not understanding it or do you think they could have argued between them to get their shit together before shoving it down your throat?

en.wikipedia.org/wiki/Monad_(functional_programming)

Wikipedia actually has a pretty good explanation about it.

this is what happens when you try to understand meme languages using pseudoparadigms that have completely nothing to do with how the application works on the machine

she's better than the uncanny valley between 90' and 00' anime which was first haruhi

Can't say I am an expert of Java 8, but I have worked a bit with its streams and lambdas so I thought I understood them well, but then I looked at the API and map()'s return type is defined as Stream. Is this special syntax/notation for something? As far as I know, when using map(), I can chain another Stream operation to it, so I thought it returned a Stream and not whatever Stream means.

HW let me post

KyoAni went full-moeblob with K-On! and never recovered, ruining both Haruhi Season 2 and pretty much all of anime in the process.

Thanks, KyoAni!

No, it wasn't. It wasn't fine.

So what can I do with Haskell that justifies its existence? It seems like it's overcomplicated and you spend most of your time solving problems the language creates rather than the problem you intended to solve.

You could write some articles in academic babble.

fun fact: Holla Forums runs on haskell now
github.com/Cipherwraith/alacrity

Stream is the same as Stream.The extra is just a declaration that T is a type parameter. The compiler needs to know that is doesn't have to go look for a class named "T" in the classpath.

This is necessary because in Stream#map, T can be any type. It does not have to be the type of the stream.

For instance, you could map a stream of Strings to their lengths. In that case T would be java.lang.Integer.

forgot the link: docs.oracle.com/javase/tutorial/extra/generics/methods.html

Really? Because I would argue it is not running most of the time. :^)

You could jerk yourself off to type theory or this:
import Data.List (partition)qsort :: (Ord a) => [a] -> [a]qsort [] = []qsort (x:xs) = qsort less ++ [x] ++ qsort more where (less, more) = partition (

That would be because it isn't just a mappable collection of objects. It's anything that has certain properties. There are useful monads which aren't burritos.

You could write a blog post explaining prisms.
It's actually really easy to use but most of the people who use it like complicated things so most the material around it is complicated.

They basically let you define a type with some hidden boilerplate logic and a set of compatible functions. With do notation they can do some nutty shit because you're really writing a bunch of nested functions that are being applied with your particular monad's logic.

That looks like it must be very slow. Normally qsort is done in place. Is it able to magic up that optimization under the hood?

It isn't unless you're doing quick select and you carefully handle your concatenation. Real quick sort requires mutation so it's longer -- about as long as it is in C.

>itt mostly plebs
this thread is pure fucking cancer.

Thank you for your specific criticisms.

Specifically, he means that people who don't smoke Haskell cock are cretins who can't into programming and can probably barely control a turtle graphics app in qbasic.

Haskell has a lot of good stuff in it. It also has lazy semantics, and therefore is a worthless meme language. The truth is, people who can't make that distinction tend to be cretins who've never seen the good stuff anywhere else, so they accept the bad as somehow unavoidably bound together with the good.

god is a monadic quantum consiousness

I can agree with that.

I thought
at first, since most of the time they manage to make articles dryer and harder to understand than the papers that defined the thing in the article, but holy shit, its formal definition is the simplest explanation I have found so far.

en.wikipedia.org/wiki/Monad_(functional_programming)#Formal_definition

If the definition is correct and I understood it well, any class/type is a monad if:
>It is defined as a set M of types t, therefore this monad would be M t, or M in generics notation to be honest, this rule seems dumb
>You can put values of type t in a M monad with a function of this monad, essentially m.insert(t)/m.add(t) or M(t) to a C++/Java set (considering Haskell is supposed to be stateless, the latter seems more likely, but in practical terms there wouldn't be much difference)
>Here comes the real deal: M should have a method that extracts all t values from the monad, then processes them with a given function (we will call it f, accepting an argument of type t and returning a value of type M), then returns a monad M with an arbitrary number of b values inside it.
What the last method does is basically extracting each t-typed member of the M monad, then passes each t to f (or f(t)), which returns a M monad (or null, in which case that f(t) call is ignored, like the case of Maybe/Option) with any number of b-typed objects inside it. The last step (known as flatten-ing in Scala) extracts all b-typed objects of each M returned by each f(t) and then builds a single big M with all the b values it got.

So, one of the inherent properties of monads is that it, since a monad M always returns another monad M, you can just keep chaining calls to M methods to transform a M to M in an arbitrary number of transformations (mapping/filtering/whatever). For example, if we want to transform a M to a M passing by a M type, we could write something like c_to_mb(t_to_mc(mt)), or more cleanly, mt.map(t -> M(c)).map(c -> M(b)), which returns an M (or M in case map() doesn't flatten the result) we got from the pipeline M | M | M.

This can make code shorter, cleaner and less error prone due to bogus values present in the map since error control is built in into the mapping functions. Another side effect is that code is relatively easy to parallelize because you can split the contents of the monad in parts and compute them separately (because f is just aware of the t it is being passed and therefore doesn't rely on anything else) and then recompose them when all threads have finished.

Some people compare monads to programmable semicolons, but that's somewhat obtuse. If anything, what you can do with monads is programmable semicolons, but the analogy is shit; what you can do with monads is basically bash pipes, and if you have ever had the temptation to write a long ass line of chained piped commands written in bash, then you probably already understand what can be done with monads.

In other words, the Kleisli Triple rules, which define what a monad is, can be simplified as:
>A monad is a generic type (Monad in C++, Java and )
>A monad which contained data type is t and monadic type (monadic type is to a monad what M is to M) is M should have a method to "wrap" a passed t-typed argument in it, so an M can contain said t-typed argument
>Given a function with return type M and a t-typed parameter, the monad will pass each of its t-typed contents to said function, essentially transforming the M monad to a M monad

Now the question is, why the fuck are Haskell devs so obtuse about it? And more importantly, how is this a workaround to make state somehow not count as state?

well I like said, learn mercury.

main(IO0, IO2) :- io.write_string("Hello, world!", IO0, IO1), io.nl(IO1, IO2).% that's a fakely verbose version of:better_main(!IO) :- io.write_string("Hello, world!", !IO).

main gets passed "the state of the world" which is modified by I/O predicates and is threaded through them. Since the state of the world is handled in such a way as it's never required to be duplicated, mercury can as an optimization modify the world in-place. Which is pretty fucking convenient considering that it can't be duplicated at all. In mercury and in Clean and similar languages, it's a type error to try to duplicate the state of the world, or any other unique type. This fake optimization is also a real optimization that can be really applied when arrays and such are uniquely threaded through a program. "Threading" here obv. not used in the sense of concurrency.

With the IO monad Haskell does the exact same thing. It's just prettier and, apparently, harder to understand.

When you tell someone "a monad is anything that satisfies these laws" they usually say BUT WHAT IS IT. However, the only way to understand it is to accept that it is a mathematical abstraction, thus all the terrible tutorials that try to skip that.