Redpill me on Haskell

I've been into it and even wrote my thesis about it. Let's say it may give you a different perspective and make you appreciate functionality, but in practice it is an awkward way to solve most problems. Its claims about code cleanliness are often suspect. On the contrary, Haskell code tends to be syntactically ass-backwards and thus borderline illegible.

Haskell is a weird language, and probably nothing like you've seen before.

At first you will like:

"Wait, so there are no for or while loops?"
"If I use only pure functions how do I make the computer do anything useful?"
"Why do I need fucking Monads to print Hello World?"
"Why are the no classes? How do you fuckers do anything on this language".

Many times you will ask "How do I do X?", and the answer you will find is "You don't want to do that".

Because Haskell makes what is simple on other language hard, so that the truly hard stuff becomes simple.

You will get frustrated. But trust your elders, trust the people that told you that it was worth it, that Functional Programming is the right way. Don't give up user. Eventually you will find the sun.

Attached: kboo.jpg (842x577, 83K)

you're from dpc discord arent u

I don't get haskell function signatures. Why is it so much better to describe a functon mapping some (a, b, c) to (x, y) as a => b => c => x => y and not just (a, b, c) => (x, y)? With the former it's harder to distinguish between inputs and outputs, you can't insert b or c before a when currying, and there's all sorts of dumb shit about the output.

Because partial functions. If you want to change the order you can use flip functions.

And then I'll get fucked in the ass by the GC.

It has it's uses, mostly to teach you to reason and solve problems in functional way, you'll appreciate immutable data structures, referencial transparency, value semantics and all the sweet things.
Sadly like all languages that force a certain paradigm it can become limiting like cyclic graphs for example.

I believe you are talking about the functor definition right? for example (a -> b) -> f a -> f b indicate a function that takes a bunction and a container, giving a new container, (a -> b) -> (f a -> f b) is a function that takes a function and transform that function making it compatible with the container, then it applies that new function to the original container, that's because higher order functions.

without memeing, I've been learing haskell and found this interesting:
data Tree a = Node A (Tree a) (Tree a)
| Empty
deriving (Show)

this is a recursive data type for a binary tree. You could give assign this type to a massive binary tree of infinite size without incurring any sort on memory penalty thanks to another interesting feature of Haskell which is thunks.

You could then write a function to walk this binary tree with ease and the type here would keep you from erroring in leaf nodes. Looking at other code for something similar is usually pretty painful. I think the only other language I've seen that can approach such a thing gracefully is Common Lisp, but I don't believe it has recursive data types, or much of a type system at all for that matter.

Attached: 1528241768877.png (499x338, 35K)

Haskell is a language that relax its standards even if it would make it more successful as a language. Haskell has been around for quite awhile and is just recently been getting more attention outside of academia with functional concepts sneaking their way into other languages. There are some industries using Haskell and it's growing but its definitely not a dominant force because Haskell refuses to compromise.

Haskell contains a lot of very interesting concepts and is pretty different from the type of programming most people are familiar with. Learning to program Haskell feels a lot like it felt when you first started learning to program unless you started with Scheme or something. Most people recommend using Haskell to learn functional programming since it requires you to use only pure functions and how things like Monads actually work when you encounter them in other languages. It's a really great way to learn how to actually use lambdas, recursion, pattern matching, ADT's, type interfaces, etc.

One thing that's hard to do without once you get used to it is concepts like folding, mapping, and filtering. Haskell defines a class of instructions for these and then each data type can define their own implementation of it. This is extremely useful when working with things like trees. Which is why one of the things Haskell is good at is writing compilers.

It's not really practical to actually use for anything. There are libraries for it, yes, but it's just a bit too "out there". Learning it will be a great exercise in developing your programming mindset, especially if you do something like SICP with it, and the functional mindset will transfer easily to something like Clojure, which gives you access to either the JVM or JS engine so you can actually build things.

not to say it's not out there, but it is practical for some things. I just started a project at work using it to semantically parse and check serialized data coming from a multitude of sources. It's nice the code doesn't care much about IO it just takes it and does what it needs to. It's incredibly fast and most importantly i can make distinct types out of primitives (in my case strings) so that certain types of strings are always handled the right way.

Attached: qualifications.png (500x225, 85K)

On this note, small projects (like your personal portfolio) could be fun to do in Haskell. Things that are meant solely to process data can be done in Haskell, with great efficiency (although you might struggle against the language, sometimes, especially when you're laying out your proofs). Just don't expect to build freelance web apps with it. Also look into Elm, alongside Clojure.

It is genuinely used in industry. It's just not widely adopted because everyone is afraid of it despite how much more productive it is. And robust.

>in practice it is an awkward way to solve most problems
t. some guy who wrote a haskell once

This

Solving this without functional style is fucking agony and tedious

Recursive datatypes exist in Java too. What's your point?

>so that the truly hard stuff becomes simple.
Especially writing programs that take advantage of multicore systems.

haskell is not an acceptable alternative to C. It's just a fucking toy. Use the right tools and don't lie to yourself about the nature of programming

Well, all languages are toys compared to C to begin with.

There was an interesting thread a few months ago with some guy who apparently wrote a profitable cryptobot in Haskell. No proof, of course, but he seemed legit.

I was exaggerating a bit. It's definitely used, and I've even worked at one of the very few places that does (might be did, now) use it. Not to sound like a complete jackass, but in my experience (at a very well known tech company and 4 high-performance tech startups, so by average I don't mean "local business IT guy slash programmer", just your regular bootcamp/CS grad) the average programmer can't really grok the functional mindset well enough for it to be worth using. They might be able to pull of underscore.js with a bit of work, and that's nothing. To be productive with Haskell you really have to understand it, much more so than C# or Java or JS (or other common languages, although I will give JS some slack, since there's a pretty huge productivity rift between someone who has formally learned JS and someone who "just" writes it). You could stick a green intern on C# and they'll probably be contributing within a few days. So that's definitely a barrier to adoption. The other one I've found is that much of what Haskell can do efficiently can be done almost as efficiently in other languages. Could an HFT firm use Haskell and improve performance? Maybe. Is the expected increase worth porting an entire system from C++? Probably not.

(defun csg-intersection-intersect-all (obj-a obj-b)
(lambda (ray)
(flet ((inside-p (obj) (lambda (d) (inside-p obj (ray-point ray d)))))
(merge 'fvector
(remove-if-not (inside-p obj-b) (intersect-all obj-a ray))
(remove-if-not (inside-p obj-a) (intersect-all obj-b ray))
#'

Attached: asras1.jpg (528x512, 11K)

meant to include, "and Haskell is a bit of an anomaly, even in [the functional language] domain"

I'd like to see your reasoning, the only times I've seen Haskell get unreadable is when you need to start working around the language for performance reasons.

Why is it an anomaly, is it because it encapsulates every non functional part inside monads (IO and State)? or am i missing something

Mostly just in comparison to other well-known functional languages. Clojure and the lisps look nothing like Haskell, and don't really require any sort of understanding of lambda calculus to use. Before I learned Haskell, I used Emacs for years, and it generally wasn't difficult to use Emacs lisp to a desired effect. While Elm is also pure like Haskell, it has a strong bias towards UI building, and they don't really "feel" the same in practice - if you've used Elm you probably know what I mean.

that sounds neat. lately i've been looking at trying to offload some basic infrastructure over to HalVM. The idea of a minimal attack-surface unikernel seems like it'll be hot soon--real hot

>Clojure and the lisps look nothing like Haskell,
That is because they are not purely functional at all.
As for pure FP, Haskell is pretty much the archetype.
All pure functional languages look a bit like haskell.

a -> (b -> c) is isomorphic to (a, b) -> c, here's the proof:

curry f x y = f (x, y)
uncurry f (x, y) = f x y

Since they're isomorphic, you can use either. So why would you purposely choose the more syntactically noisy, less convenient, and more expensive uncurried version?

These types you mention are NOT isomorphic by the way. These two are:
>a -> (b -> (c -> (x -> y)))
>(a, b, c, x) -> y
and these two are:
>a -> (b -> (c -> (x, y)))
>(a, b, c) -> (x, y)

Because you can do
(a) to (b, c, x, y)
(b) to (a, c => x, y)
(a, b) to (c => x, y)
(b, a) to (c => x, y)
(a, b, c) to (x, y)
and many more with this technique without writing new code.
Passing partially applied functions can be helpful too in some cases.
Also the compiler can reason about a ton of shit this way.