Will learning this make me a better programmer?

> it has a slower implementation
>being this deluded and assblasted
Not much really. just that Haskell has gained quite a lot of traction lately and there is plenty good material around as a result, and the libraries are growing rapidly.

no. it's like any old language except you pass your whole state as a parameter to every function (which means slowness)

its slower by design, thats not an opinion

>opinions

Attached: 1444053433833.jpg (640x638, 34K)

>Functional languages
>Not regular languages
Did you perchance mean imperative languages?

Attached: d1a2e29fd14ce6469e497e9dce328703.jpg (247x247, 5K)

I find Haskell's type system much nicer, starting with type classes. OCaml has first class modules instead but they often lead to weird errors with abstract types. You also won't learn monads and won't know the pleasure of non-strict evaluation by default. Haskell has richer type system overall (for example rank n types).

I know that GUI libraries are kinda lacking - you can find a working library for it but they are only minor ones or bindings to imperative libraries.

That only applies if I care about making GUI apps right?

>Will learning this make me a better programmer?
not

...false, if you write in a functional language like this you need some serious refactoring

Haskell has a nice syntax for creating one-off computations with infinite, lazily evaluated data structures. For anything with lots of IO it’s a nightmare.

sorta

After the phase of spamming maps and filters everywhere, I don't notice that much of a change in my imperative programming - and I wrote a ton of Haskell

You really shouldn't be passing that much state around. The idea is that a lot of state is managed by the language and so you don't have to think about it.
Even if you did want to live your whole life inside ST, it wouldn't result in copying a ton of state every function call. The STG Machine (the runtime) doesn't even use a call stack in the traditional sense, and calling functions doesn't necessarily mean copying arguments; it often just means a jump (or nothing, since GHC is really, really good at optimizing).

So, one should write I/O wrappers in other languages for haskell applications that do the heavy lifting?

The problem in my opinion is that lazy evaluation combined with IO is a performance nightmare in the making. How I’d do it is write in an imperative language and run compiled Haskell programs within that

"patterns" in "regular" languages are just abstractions your language is not strong enough to express.

The part about GUI libraries - yes; the rest - no.

>The problem in my opinion is that lazy evaluation combined with IO is a performance nightmare in the making
Why would it be? Also, it's non-strict and not lazy and the difference is that the compiler performs strictness analysis and makes the parts that always have to be evaluated strict. It obviously doesn't fix everything so that's why you can make annotations about strictness.
>write in an imperative language and run compiled Haskell programs within that
Actually that's how one could try to explain IO monad to a newbie.

Haskell is impractical and needlessly difficult -- created by academics for academics, but adopted by autistics worldwide who jerk off all over it being needlessly convoluted for doing non-academic programming.

If you want to become a better programmer, just learn a Lisp (Scheme and Clojure are highly recommended) or Erlang/Elixir for getting your brain all twisted up in functional programming, or learn a language with the Hindley-Milner (or similar) type system, such as Rust or OCaml, for getting type systems and generic programming jammed into your head.

most useful functional patterns can be expressed with minimal stress in any language that supports first class functions

I think I get what you mean -- the way monads work, but if you do it right, you're not passing the whole state as a parameter to every function, and the use of a monad is an abstraction that the compiler optimizes away to make it *seem* like you're passing the state around on a high level, but the machine code is a rather different, optimized version that doesn't quite do the same thing you're expressing at a higher level.

based npc user

Closure isn't a Lisp, it's an abomination.

Most procedural/OOP languages don't even have basic shit like HKTs, let alone actually advanced type system features
Lmao

lol idiota

I just looked up Monads and I'm wondering why anyone would ever bother with shit like this
homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf
This is supposed to be some kind of super clear, seminal paper on the topic?

Monads are a great idea. But they're better left to the academics, theorists, and implementers.
Haskell would be such a better language if it presented a programmer-friendly API instead of a researcher-friendly API.

listening to haskellers talk about types is like listening to fundamentalists talk about jesus
just smile and don't say anything

>Will learning this make me a better programmer?
No

>Also, what kinds of programs does it excel at writing?
Examples of functional programs explaining functional concepts; some prototypes maybe

>Monads are a great idea. But they're better left to the academics, theorists, and implementers.
monads are a simple idea implementable in any programming language made out to be 100 times more complicated than they really are due to FPtard elitism

To have a monad typeclass (i.e to have a bind and return function that works for any monad) you need HKTs which are not common in mainstream languages.

But it's true, monads are a simple idea.

you don't need "types" at all to implement something equivalent to a monad, you can do it easily in lua or any equivalent scripting language

We'll sure, that's just if you want type safety while doing it.

i swear the way you guys talk about types you'd think you were being paid for it

This

Learning functional concepts will really help make you a better programmer and help you write more beautiful code.

>Why did Cardano choose Haskell as their development language?
did you have a look at cardanos main programmer, yet?

The main point of a static type system is to express the behaviour of your program. If your type system is inexpressive you're better off with dynamic type system.

Type systems based on Hinsley Milner like Haskell 98 are more expressive than the average procedural/OOP language even though you only need write the type annotations you feel like. Global type inference makes programming with static typing effortless.

are you an inline wikipedia bot

Why are you even participating in this conversation if you don't bother paying attention?

I know what types are

no, haskell is just a meme language.
If you want something functional that will make you a better programmer learn:
Lisp
lambda calculus
combinator calculus

So then you know that functional programming languages tend to have powerful type systems.

how is that relevant to anything that was being discussed

Type systems in FPLs tend to be the only ones expressive enough to describe concepts such as monads. Otherwise you lose type safety, which is a bad thing.

You can describe monads in any fucking type system although current statically typed imperative languages usually don't have the faculties to do so naturally (you just have to jump through hoops to do so)

> Type systems in FPLs tend to be the only ones expressive enough to describe concepts such as monads. Otherwise you lose type safety, which is a bad thing.
So.... you can express monads in languages without expressive type systems... you just lose type safety.
BTW, function programming != strong/static/whatever typing. You can have an untyped functional language, too.

slower than what? and context please?

You can describe a monad instance, such as a List, in a type safe manner if you have rank 1 parametric polymorphism, like most langs. You can't describe any monad or operations over any monad without rank 2 polymorphism which is not common out side of FPLs.

Monads were first used to describe semantics of programming languages. Then somebody noticed they could use it for IO in Haskell. That's like taking a shortcut so that your language is closer to its semantics. The thing is that there is no better way to describe IO (and a lot of other things) in a non-strict language (but people do keep looking for one; algebraic effects being one of candidates).

If you understand the idea of monads then the only difference when using Haskell is the type system: most notably higher-kinded types and type classes. You either learn them and benefit from the abstraction or you stay a brainlet. But yeah, I see Haskell as a research language - see below.

>Haskell would be such a better language if it presented a programmer-friendly API instead of a researcher-friendly API.
I think the point is that Haskell people are trying to find the right way for expressing things. And it takes time. However, there are people who use Haskell in practice. I mostly hear about backend stuff but then there are projects like xmonad and I've heard of Haskell being used for crucial parts of a system (for example in banks where a mistake could cost a lot).
>Monads are a great idea. But they're better left to the academics, theorists, and implementers.
In a lazy language the concept of a monad is so important that you won't be able to abstract away from it unless somebody finds a better way to describe side effects - there simply is no easier way right now.

Sure, and there are good examples of dynamically typed FPLs like Scheme.

But the topic of this thread is Haskell and one of Haskell's strengths is its rich type system based in FP theory.

>most useful functional patterns
Being:
>first class functions
>type classes
>algebraic data types
>higher-kinded types
Yeah, first class functions can be expressed with first class functions. Algebraic data types can be expressed with interfaces, although ugly.

Then say haskell or strongly-typed FPs or HM-typed languages, not a generic term like FP.

>You can't describe any monad or operations over any monad without rank 2 polymorphism which is not common out side of FPLs.
it's common in dynamic scripting languages, and emulating monad functionality is trivial even in tradtional statically typed language

You can't write a typesafe >>= in a traditional static type system. You can't even write fmap. Not without losing their characteristic polymorphism.

>Will learning this make me a better programmer?
no, it's a waste of time

>tend
>1 .[no object, with infinitive] Regularly or frequently behave in a particular way or have a certain characteristic.

Note the use of the word "emulate"

That's a weasel word for second class functionality. If you must "emulate" functionality and not simply implement it directly, it's a botched job.

>rank 2 polymorphism
Did you mean higher kinded types? "Rank 2 polymorphism" hits only rank 2/n types which I don't see anywhere near monads.

I'm not sure how it's a weasel word, it's perfectly clear that "emulate" means second class functionality, that's usually good enough for the circumstances where you want to use monads in an imperative language

So what about Haskell having to emulate side effects with monads?

Algebraic data types are better expressed in terms of universally quantified functions desu. Then you can enforce the closed constraint implicitly, rather than having to jump through hoops to seal your inheritance hierarchy.
But that can be painful because many langauges don't have polymorphic lambda expressions. And it's still an improper approximation if every type is inhabited by null.

Except in the context of PLs use, there's huge conflation between static typing and functional languages. You were speaking overly generically.

Of course, I got terminology a little mixed up there. I meant to describe the presence of either first order or second order type constructors.

You can consider that a flaw, if you like.

there's a huge conflation between static typing and imperative languages too