Bullet. Fucking. Dodged

Bullet. Fucking. Dodged.

Attached: bullet-dodged.png (1546x1184, 292.94K)

How about...

Guidelines for
Respectful
Intercommunication between
DevOps
Systems

Attached: 1984982984.jpg (480x270, 18.78K)

that's just pure phallophobia - fear of CoCks
which is sublimated transphobia, obviously

So is haskell pozzed or not? I want to know if it's worth sinking time into

The "functional programming community" is deeply poz'd.

I don't understand. I thought they were equivalent.

Every programming """community""" is pozzed but I'm asking if haskell's dev team itself has gone full silicon-valley

If this is important to you what you want to do is maximise age, while minimising academic support. The problem is that a programming language is rarely these things and functional, depending on your definition of the word the following (reasonable languages) come to mind: Common Lisp, Clojure, Erlang, and Ocaml. If you're interested in employment keep in mind that Erlang and Ocaml programmers are primarily employed in Sweden and France respectively while Clojure (less so) and Common Lisp (especially) programmers are primarily employed in the US.

never mind lol

Attached: lmao.png (899x169, 31.48K)

...

If you're too lazy to make a thread properly, damned if I'll waste my time reading it.

Maybe I'm just rationalizing already having spent a month learning haskell to myself, but haskell still looks better than those. It's got a much stronger set of libraries, a clean syntax, and it's statically typed (Ocaml is too though). I hope adopting a code of conduct is just a way of preventing the silicon valley people from attacking them since almost everyone involved in haskell is a white male, and not a sign of the true desires of the dev team. But I suppose as we've seen before if you give these shit-disturbing trannies and inch, they'll take a mile.

It's fun to dip your feet in, but it's very easy to get sucked into its world and only to end up being useless in the "real world."

it's something that looks like a cake, that has cake in it, but that also has shit in it. If you eat the whole cake, you can honestly say that you benefited (part of it was real cake). If you've never seen cake before, and eat very selectively, then it can be a mind-blowing experience for you. Wow! The world has (real) cake in it!
The cake is ML. There's a bit of cake in the purity, and in other bits.
The shit is monads (yes, even though they are used for the purity; you can get purity without them), lazy semantics, pointfree programming, the whole "let's make this shit as visually dense as Perl and as semantically dense as a black hole" community that treats clear, readable code as the mark of a novice, etc.

>but you can do higher higher order programming with monads
in Haskell.
just Haskell.
Do you want to spend a lot of time gitting gud, and then at the end of that time discover that none of your efforts are transportable to any other language? That these difficult walls that you climbed don't even fucking exist anywhere else? Then eat the shit.

I wasn't trying to say these were better languages, just trying to meet user's needs while being reasonable. They each have something nice about them though, Erlang can't be competed with for making truly fault tolerant systems, Common Lisp has many implementations of a single static standard and simple means to extend the language meaning you can test across implementations, you can write code and be assured it will run in 30 years, and you can easily abstract away boiler plate by making little dsl's, Clojure is really great if you need to access legacy Java code or if you really like the everything is data/a map thing with the same ability to make little dsl's easily like Common Lisp, lastly Ocaml, all I can say is first class modules are really fugging good.

That's exactly where Haskell goes downhill. You start off with very clean semantics that make sense, and pretty soon you find yourself reading a category book just so you can fit in with the other "wizards" in their collective intellectual masturbation. I much prefer the approach Ada took in uncompromising readability.

*category theory.

I spent some time reading about erlang thanks to your post, and it looks very interesting and very practical in regards to the concurrency and availability needs of modern public-facing web applications. I think I'm going to give either it or Elixir a shot. Thanks m8

You can use monads in pretty much any language, but pretty much any OO or functional language makes them easy to add. You just might not get special syntax like you have in Haskell for working with them.

Category theory is about the structure of mathematics. It makes sense to apply it to the structure of your program and your data. Algebra defines ways data can interact. If mathematicians have done all this work, why shouldn't we use it.

Elixer is much better for that sort of thing, that's why it was made. If you're the user who really cared about community keep in mind Elixer's community is just Ruby's community.

but you don't, and it would be stupid, not just ugly. Your mastery of monads is even less meaningful than mastery of a single character in a fighting game. The concepts that you get from Haskell, that aren't just borrowed from better languages that you could learn instead, are useless concepts. It's fake knowledge, born of fake learning. If you knew every detail of Scientology you could at least tell some funny stories about it. Haskell is a product of masochism: let's see how far we can get away with design decisions that we know at the outset are bad and harmful. It turns out, you can get pretty far if a big cult like "language of the year" suicides its members and then its own organization into you.
but you led with the other argument and not these for a reason.

Because the mathematics works in the wrong direction. It is easy to observe a system, make names for things, discover isomorphisms, and compose our abstractions into a mathematical model.

It's much harder to go in the reverse, and build a perfect mathematical structure, which then decomposes into real running code. Reality is "ugly" and is hard to translate from abstractions to concrete solutions. The best algebraic model which represents real computation ends up looking like all the popular languages you already know.

Yeah I saw, that but it is what it is I guess. All the good contemporary languages and frameworks nowadays are funded by silicon valley corporations who force this stuff in as a condition for their support. Elixr/Erlang just look a lot more practical for the type of stuff I want to do, I got as far as building a little imageboard in haskell, but it was really painful and took a while for such a simple application. I'll read a book or two on elixr/erlang and mess around with one or the other for a bit to get a better feel for it, but I think they're much more what I want than haskell. Also just looking through some frameworks available for both: erlang has a few web-frameworks like chicagoboss so if you really wanted to avoid the pozz it seems like I could do what I wanted with just erlang

The only reason to learn Haskell is to learn why to give up learning something. It's a valuable lesson.

My general advise is: If you're just try to get something done use the tool you know, if you're trying to get lots of things done learn the best tool, and if you're trying to learn something try something unfamiliar. If you're on the fence about it, I'd encourage you to pick your tool based on its individual merits within this framework and not its community. I'd consider Elixer or Clojure the best tool for writing web applications currently, and I don't think you'd regret picking Elixer over Erlang for this task, unless you think there is something you can learn from Erlang that Elixer can't teach you (I don't think there is).

People use monads in javascript. See the promise monad.
What does that even mean? That's like saying mastery of adding two numbers together.

Haskell makes you stupid.
Haskell makes you forget early childhood experience.

Much like the entirety of comparing Haskell with Idris, Monads aren't difficult at all, but uniqueness types are nicer when it comes to composability, learning curve, and clarity. (Idris is also more expressive and correct but it's not really relevant here)

I appreciate the advice, my goal is to learn some useful & fun languages, and build things with them that I can put on my resume so I'm not stuck developing C# & Java enterprise stuff for the rest of my life. That's kind of why I'm leaning a bit more towards erlang, because I'm sure it has more use in business. You're probably right about ignoring the community too, from what I've seen on social media every programming community seems to attract a lot of weirdos (and not the fun kind). Best to just stay away from that stuff

KYS chodekikey
c-c-c-COMBO BREAKER!!!!!!!!

ah, that's a good reason as well, best of luck user.

On the topic of Haskell, can someone please explain to me or link an explanation of what a monad is? I have tried looking it up in the past, but if you ask five people you always get twelve different answers.

context fun(int val) { return printf("%i", val);}context monad(context val, function fun) { return fun(unwrap(val));}
Monads conceptually are a function that is passed two things: a context and a function which takes a normal value and returns a context. What it does is unwraps the context, apply a function to the unwrapped context (a normal variable), and return a context. a context is the state of the program at a point in time. a unwraped context would be some sort of data, in the case of the pseudo code example a int. The function can do anything to the value, what it does here run a function printf which modifies the program context and returns this aswell as printing to the screen.

So, just a retarded contraption to not admit that functional programming is a joke, right?

As I mentioned here: there are better solutions that exist while maintaining purity, and neither of these things are required for functional programming if you don't want the beneficial properties of purity, for example none of the languages I listed here are pure, and 3/4 are dynamically typed:

Purity is a meme, it's only useful for academic fart huffing

As I mentioned but didn't elaborate purity has some nice properties namely the typical benefits of strong staticly typed languages: better debugability, and abstraction, with guarantees to get the benefits of functional programming: better concurrency, debugability, and abstraction (through composition). You really don't give up that much for it, and especially not once you factor in type inference and/or a system of uniqueness types.

You can literally call Erlang from Elixir so it shouldn't be a problem.

kekt
I was going to say "GHC contracts HIV," but I like yours better.

Haskell is a language. GHC is a Haskell compiler. GHC is now pozzed.

read UNQUALIFIED RESERVATIONS

This

It's a complete fucking meme and it's impossible to do anything in Haskell. If you want to learn that kind of bullshit learn straight up ML.

Put simply it's a nested data structure which can be joined into a single data structure of the same type. For example:
- "Maybe Maybe Int" can be joined to be a "Maybe Int"
- "[[Int]]" can be joined to be a "[Int]"
- A computation of computations can just be called a computation
- Promises in javascript let you join nested callbacks so you don't have to indent a billion times
It is an abstraction that lets you get rid of nested stuff.

How does IO fit into this?

It falls under the computation of computations example I gave. IO is actually the State monad, but the state it's carrying is the RealWorld. In order to do an IO action you essentially need to have the instance of RealWorld. The State monad lets you thread some state between a series of function calls and then return a final value.
This probably wasn't a very good explanation as this was about what the IO monad actually was. If you are programming in Haskell you don't really need to know how it's implemented internally. Feel free to ask more questions though.

A monad is a special type. It's best described by the operations are defined on it:

# Put value `x` in Monadpure x = Monad x# Apply function `fn` to `x` when `x` is in MonadMonad x >>= fn

A monad is an abstraction that encompasses data structures, objects, classes, state machines, timers, file handles, etc. Anything that specifies the way primitive values can be manipulated can be a monad. A chess piece, for example, can be a monad because there are specific positions it can move to. A list is a monad, too, because it links a bunch of values one after another. Monads allow you to define its behavior once and have it run every time your program interacts with it.

It might be beneficial, for example, to say your chess piece can only exist at certain positions by implementing the ``>>='' function:
ChessPieceMonad x >>= fn = if (validPosition (fn x)) then ChessPiece (fn x) else NotAChessPiece
The chess piece can only be accessed by other functions via the ``>>='' operation, so you can make sure certain things are done every time the monadic value is touched. This general idea can be used for doing more complicated, potentially dangerous stuff like logging to a database every time someone logs in to your server.

That's all you should ever know about monads. Don't try to read about it beyond what I wrote here because it's a massive waste of time. It's a lot of pseudointellectual mental masturbation that has never resulted in better software. Haskell is cargo cult bullshit for retards who want to larp as mathematicians.

Attached: trashman.jpg (1516x892, 115.96K)

Completely wrong. Also just saying it's a programmable semicolon is missing the point.

Prove it. Show me a way of doing computations on primitives that can't be implemented as a monad.

I'm not saying that's the strict definition of a monad. It's just that the most common/obvious use of monads (e.g., Writer, IO, State) is exactly that.

You could probably find counter example from the fact that you can't turn Set into a monad since you can't map over it.

The way I understand it, you could have something like this:

x is of type List, and f is a function that takes string and returns List

Then you can do x >>= f to apply f to all elements of x, and combine the resulting Lists into a single List. That's the job of the ">>=" operator, which you define yourself.

In this case, the monad is "List".

I've found it easier when teaching people about monads to talk about join instead of bind. It's easier for them to see the fmap and join as separate operations first.
x >>= f = join $ f x
which is the same as
x >>= f = join (fmap f x)

...

Loosely translated: