It just doesn't get any better than this.
(except for Idris of course)
It just doesn't get any better than this
Zachary Sanchez
Jordan Hughes
Until you need to do side effects (as you do in EVERY SINGLE PROGRAM) and then it gets ugly.
IO monad is such an ugly workaround for the problem and a lie you can tell yourself that your program is somehow still pure even though the RealWorld variable you made up to mask the fact that your function is impure is literally defined to be NOTHING.
Jaxon Edwards
Monads are perfectly simple and easy to work with, it only gets ugly when you start stacking them and then you have to start worrying about transformers.
Sebastian Brooks
Horseshit implementation, slow GC, massive consume memory, nightmare strings handler.
Josiah Smith
I don't mind monads per se, just the ones that attempt to mask the fact that Haskell, since it includes side effects, is no longer pure.
The IO monad / RealWorld is just self-deception. It's impure. It's not like RealWorld actually captures the entire state of the universe. It doesn't even exist in the final code. There's no way to ever redo the function with the same input parameters and receive the same output.
Or rather, since RealWorld actually does not exist, it is very easy to call the function with the same parameters - and get different ouput, aka, it's an impure function.
Aiden Perry
Well yeah, that's kind of the point - to represent impure interactions within a language with exclusively pure semantics.
You shouldn't ever be worrying about RealWorld, it's nothing more than an implementation detail.
Aaron Nguyen
But all the Haskell sites I've read claim that this makes the IO operations pure, which I'm absolutely convinced they are not.
If they admitted that these operations are impure, they wouldn't use quirky type bullshit like this to hide this fact and just have honest to god impure functions, like C. Maybe with an "impure" keyword or something.
But somehow, they deluded themselves into thinking that this is pure. I keep wondering if there's something I didn't get. There may be.
Josiah Hill
Thinking more about this, I realize that they couldn't possible remove the IO parameter since then you couldn't guarantee order of execution.
My point about impurity still stands.
Jayden Morgan
1.shit community filled with insecure autists with superiority complex
2. shitty unfinished libraries with almost no documentation.
3. no real ide (hurr durr you aren't real programmer if you need ide - goto #1)
Jayden Gutierrez
You sound like someone who hasn't written more than "Hello World" in Haskell
the point *isn't* to deceive ourselves - the point is to find some abstraction that is general enough to capture all sorts of effect, and how you can sequence them (since this is a fundamental problem in a lazy language), while also reflecting this fact in types, so that you don't lose the benefits from them
Daniel Ross
I understand that it's necessary for sequencing. The compiler could just omit the function call or do them in any order unless you use IO to create dependencies.
But does this make the IO function pure?
Blake Lewis
>My point about impurity still stands.
No it doesn't, you're not getting the idea behind IO monads at all. Thanks to them, Haskell, the language itself, is absolutely pure - IO monads only execute when you pass a composed structure of chained monadic IO values to the "main" function. But before anything is executed, while you're composing IO values (the contents of which you can't yet access directly), everything is still pure - nothing has happened yet, and the structure you're building up will always be of the same form and produce side effects no matter which order you evaluate it in. Indeed, the only impure phase is when this pure structure gets passed to "main", this execution obviously isn't pure, but Haskell the language is.
Now, is all this worth it? I honestly can't decide. Referential transparency across the program is great and it isn't that cumbersome to work with, but on the other hand a lot of time it's unnecessary complexity.
Charles Green
I couldn't get Euterpea working.
Ryder Diaz
>produce side effects
produce no side effects
John Davis
The composition of values of type IO a is done in a pure way. The execution of such a value is not.
Gavin Nelson
first - no, that's the whole point of monads, to capture "effectful" computations (which would be the opposite of "pure")
second (and more important) - w h o c a r e s ?
I don't use monads because I can say "Oh look this is pure I'm so cool" - I use monads because they allow me to more easily write code which is also susceptible to reasoning via types
Justin Thompson
seriously how do you get around not being able to have random access arrays?
Parker Bennett
Common Lisp
Go
There you go. Two superior languages.
Connor Kelly
>go
Julian Fisher
Show me code in your prefered programming language that uses parametric polymorphism and I'll show you some unmaintainable trash
Levi Price
What's wrong with Go?
No generics? Who cares? Get real, faggot.
Kevin Martin
Clojure
Lucas Young
i was trying to decide between OCaml and Haskell. Does it really matter if i will mostly be doing web dev and maybe a little systems programming?
Nathaniel Nelson
Speed can compete with C
Memory usage and garbage collection admittedly make it a poor choice for systems programming.
It's excellent to reason in and for non systems level work it's a fantastic language. Immutability and multithreaded by default can give you a ton of power.
Pure functional programming makes the easy stuff hard, sure, but the really hard stuff like parallelism becomes easy.
What I'm surprised is getting little attention is the power of the type system. Once you learn how to read the error messages the type system consistently guides you toward correct reliable behavior which is really makes haskell/purescript/elm a pleasure to work in
William Stewart
Do you want to program with me?
Christian Parker
Parker Richardson
>Speed can compete with C
lol
Jason Anderson
Program with me
Michael Morales
polymorphic code is unironically easier to maintain than monomorphic code.
Gabriel Wood
t. someone who hasn't spent time in industry
Carter Parker
t. Someone who only has polymorphism experience via c++ templates
Jackson Rogers
SML
Christopher Sanders
Idris is friggin cool. There's a lot of neat shit you can do with the dependent typing. However, I just moved my toy project off of it and back to Haskell since I needed STM (). Idris will be great when it's mature, but right now, I don't have stackage or really much of anything.
Dominic Brooks
Haskell written naively is already on the same order as C speed, and it will take 1/10th or less lines of code to do it.
If you know how to micro optimize and pull out immutability, and use strict data types where necessary. the speed will rival C, plus no segfaults.
Most Haskell library functions will compile down to the equivalent binary as well optimized C.
Face it. The only reason you write C is because you like working very hard to gain very little
Tyler Long
>Haskell written naively is already on the same order as C speed, and it will take 1/10th or less lines of code to do it.
that's wrong on so many levels
Caleb Russell
The speed thing is bullshit but the lines thing absolutely isnt
Nathaniel Wilson
Effects are the new solution
Oliver Bailey
>Haskell written naively is already on the same order as C speed
Any evidence?
Jaxson Hernandez
How do effects work?
Henry Ross
>plus no segfaults
I segfaulted ghci several times
Kevin Adams
Not this guy and not writing haskell, but I remember reading this thread:
stackoverflow.com
Seems that, since the compiler has tons of information about the code, it can do some nice optimizations, despite or perhaps because of the high level of abstractions.
Here is another link
wiki.haskell.org