Why don't you use Haskell? Are you an OOPajeet?

Go home gwern

If anyone has any Haskell questions, I'm happy to help out.

General questions, learning resources, cabal/hackage stuff, ...

Too much work to convince the compiler to output the codes
that
just
do
what
I
want.

I love haskell but it's still a forced GC language.

Is Haskell book a good resource?

Not really. It's more of a book to learn from scratch rather than a reference.

It's a decent book but for learning I usually recommend CIS194 followed by NICTA course.

Haskell From First Principles (I don't like calling it Haskell Book since that tacitly makes it the default) is certainly better than Learn You a Haskell for example, since the latter doesn't have excercises.

In terms of an actual reference, the best is arguably the Haskell 2010 report, but it's out-of-date compared to language-extension-heavy modern usage.

wishing the computer could read your mind is generally not a good mentality for a programmer to have

hackage.haskell.org/package/Chart-1.1/docs/Control-Lens-Operators.html

>100 operators

Because I'm not paid to use Haskell.

>Why don't you use Haskell?
After years of learning imperative programming and OOP it's difficult to think about programs in a purely functional way. I get the idea behind it but when I think about a program I automatically think about loops and data structures and pointers and its difficult to break out of that and think about definitions and patterns.

It also seems like haskell is only purely function if you never need to interact with the real world. If you want to read/write a file, accept user input, or even display some text you end up having to use some kind of pseudo functional programming so whats even the point?

Hi! Monadic IO isn't "better than" "regular IO", it's just a clean interface for IO for a pure language like Haskell. Also note that "Haskell doesn't have side effects" is a misnomer, since as you note a program with no side effects can't do anything!

The truth is that Haskell *functions* have no side effects. Haskell *functions* can't do IO. In a language like C or Java or Python or Scheme, when you call a function, that function might access the filesystem or mutate a global variable or send a message across the network before returning. In Haskell, the act of calling a function can't cause any of those things. Instead, a function might return an IO "action" that can be run to do those things. The result is a property haskell functions have that's usually referred to as referential transparency (or "purity", as you might hear it): calling a function with the same arguments always returns the same results.

In short, what you hear about Haskell has less to do with having *no* side effects, and more to do with separating the act of calling functions from the act of running side effects.

Also important to note is that the concept of a monad isn't necessary for Haskell's IO model. Monad is just an abstraction for types with a certain API, and IO is one thing that has this API

tl;dr
>functions can't have side effects so in haskell you use monads to have side effects
whatever. you've yet to explain why this is anything more than a needless abstraction with fancy jargon. Why should I like any of this more than (print "hello")?

Because what I'm really getting from you, which I've gotten from everybody else who tries to explain it is:
>side effects are bad and messy and make errors and stuff, so haskell functions don't have any side effects
>except side effects are still necessary if you actually want to do anything useful
>so haskell functions actually can have side effects except it doesn't count because we call such functions 'monads' instead of 'functions' and that somehow makes the existence of side effects no longer a problem

(Also you haskell people also have a hard time with brevity, so try to limit your response to three sentences.)

Writing in hipster languages is awful in general because they lack proper tools. Of course some autist will come and screech that features are bad and intellisense is for bad programmers and so are proper debuggers, but for normal people lacking tools is a huge problem. And the existing tools are huge pieces of shit (e.g. if you set up a project with cabal and add a library dependency, allowing any version, if cabal only finds this library with an unspecified version number, it will fail).
Another problem is lack of a decent community. If you ever have a non-trivial problem, you're most likely not going to find anything useful on the Internet, because nobody uses this hipster shit, so nobody has those problems. I remember that when I was looking for some trivial standard library function, almost every related question on stack overflow was about implementing it by hand (and it was really a trivial function), which just shows that almost everyone who tries this language only ever uses it for toy programs.
And specifically about Haskell, I really hate how it's one huge leaky abstraction. As a functional language it's really high level, but you still need to keep worrying about low level details (e.g. foldl vs foldl' vs foldr, lazy vs strict in general, using tail recursion whenever possible). And let's not forget how there are like 10 ways of representing a string, and most library functions assume one representation (but not the same one). And conversion is obviously not implicit.

ERLANG OR DIE

Haskell advocates also have an annoying habit of claiming every language other than Haskel isn't actually functional.
>scheme isn't functional because you can write to the disk with it!

Except any program in haskell that writes to the disk is going to have that side effect too, no matter how much jargon they hide it behind, so any USEFUL haskell program is going to be just as "not functional" as any scheme program.

The key aspect we're interested in is that referential transparency is preserved. This means one can reason about the program and opens doors to take advantage of equational laws and abstractions based on them. It also means that the type of a function tells you very useful things about it, see Theorems for Free by Wadler.
These things have real value in day-to-day programming because they help us write code we're confident in and fearlessly refactor it.

We definitely write Haskell programs that write to disk. We just write them in a way that preserves referential transparency.

Haskell and monads very much reminds me of this cool story I heard once... what was it called again...

oh yeah, The Emperor's New Clothes.

Hey! You sound combative, and from what you've said here it seems like you didn't really understand what I had said. Unfortunately, if you've misread it this poorly, I don't think I can help you understand in three sentences, but I'll do my best to clarify.

- As I mentioned, monads aren't intrinsically connected to actual program side effects (printing, network, etc). The two are unrelated except for API choices in the language's core library.
- As I mentioned, you obviously need side effects for your program to do anything. They aren't bad!
- As I mentioned, haskell functions *can't* have side effects. The act of applying a function to arguments doesn't have any side effects, and a monad isn't a function.

At the end of the day, performing side effects in Haskell isn't any harder than in any other language. In some ways it's more convenient, since the common API lets you compose them nicely and pass them around as arguments (read: define your own control structures without a macro language).

My goal is to help people understand, not to have a cultural debate, so I'm sorry that you're letting your preconceived notions get in the way. I know you're doing it in good fun, and I can't force you to be open to learning new ideas, but my hope is that you realize "purely functional" thing isn't just rhetoric (not that I necessarily feel that purity is the right choice)

tl;dr
>[haskell jargon about if you now what a function does, then you can rewrite it.]
amazing, so you can read the function type instead of the function body and know what it's supposed to do, and therefore you can re-implement it. Except for the function type to encompass all the behavior you need to know, it must necessarily be as complex as the function body. So you've simplified nothing.

It's very easy to refactor scheme code too, just don't be a fucking cowboy.

>throwing another wall of text at me when I asked for three sentences
Haskell advocates are notorious for this sort of passive aggressive behavior. They think they can win over everybody by throwing up walls of jargon and beating people into submission this way.

(They hate being called out on this btw.)

Why are haskellfags terrified of admitting their language does side effects? They dance around the issue and bring out every piece of jargon in the book.

Just say "We have side effects, but we make sure to mark them with a special type so you know you're doing side effects"

That's exactly what I've been saying. Haskell has side effects. Side effects aren't bad. Functions themselves don't have side effects.

Yeah, what they're basically saying is
>haskell functions never have side effects because any function that has side effects gets called a monad instead of a function
That's just wordplay. A monad in haskell is just a special syntax for functions that allows those functions to have side effects.

They try to claim this extra secondary syntax is useful, but it isn't. Look, I can write a function with no side effects in scheme too:
(define (square x) (* x x))

And I didn't need any special syntax to do it. And it composes too; I can do shit like (add1 (square (sub1 5)))

Deos the type of square tell me that square has no side effects? No, but I can just read the function definition to figure that out. So what does monads give me? Is it just a bullshit way of marking every function with a type that says "this guy does side effects"? If this is all about types then boils down to another debate about strong dynamic typing vs strong static typing (but of course getting a Haskell adovcate to admit that would be like pulling teeth, they will insist on using their own special haskell jargon.)

I've also seen it claimed that monads in haskel are useful because they allow you to put operations in sequential order or let you do imperative programming or some bullshit.

Why is haskell 'do' bullshit any better than scheme's 'begin', which also executes in order?

>Functions themselves don't have side effects.
Monads are functions that, in haskell, are permitted to have side effects. Admit it.

main =
putStrLn "What is your name?" >>
getLine >>= \name ->
putStrLn ("Nice to meet you, " ++ name ++ "!")

What is 'main' here ACTUALLY, if not a function that has side effects?

Monads are not just for doing side effects, but side effects in haskell are managed via monads.

You can have a Maybe Monad (that has no side-effects) that just checks an output for nil every time it's passed to another function.

Also, can I just say that is god awful syntax?

(define (main)
(println "What is your name?")
(println (string-append "Nice to meet you " (read-line) "!")))

Isn't that so much nicer? You don't have to do any of that >> >>= -> bullshit. String concatenation syntax is neither here nor there, but my god the scheme code is just so much cleaner overall.

>Monads are not just for doing side effects, but side effects in haskell are managed via monads.
Monads in haskell are functions that are PERMITTED but NOT REQUIRED to have side effects.

Happy now?

Haskell is a language that thinks having two different types of syntax for functions, one that permits side effects and one that forbids them, simplifies things. Except to explain how 'simple' this is they spam you with walls of jargon.

I'm too stupid for functional programming. What are you going to do about it? Come over to my house and make me sit on your lap to study? Huh?

Functional programming is dead simple; just learn a dialect of lisp and stay away from the haskell cultists.

I don't care what haskellfags do because I have no interest in type theory. In their eyes it makes everything more neat and tidy and easier to reason about. I mostly program in scheme (kek)

But I don't have any money to pay your tutor fee user, is there any other way we can work out a deal?

Everybody can teach themselves scheme. It's that simple.

Attached: 1437651613223.png (811x599, 481K)

Sure user, just follow along: youtube.com/playlist?list=PLE18841CABEA24090

read SICP

Follow this instead
youtube.com/watch?v=a0YrCABCOEY

Because I have a job

Will I regret learning haskell as my first programming language

jeff bezos wrote amazon in lisp and now he is the richest chad ever.

a what?

it's using types to so that it's easy to know when your program is going to make a side effect. Also it makes it easier for you to separate the side effects from the "pure code" that is the core of your program.

i don't think so. I learnt it as my first and I'm fine.

Because I write firmware.

#include
#include
int main(void) {
char name[256];
puts("What is your name?");
fgets(name, sizeof(name), stdin);
size_t nameLen = strlen(name);
if (nameLen >= sizeof(name) - 1) {
puts("Your name is too long! Change it!");
} else {
name[nameLen - 1] = '\0'; // remove newline
printf("Nice to meet you, %s!\n", name);
}
}

Watching only the videos is fucking useless, they are only extremely useful if you read the book and do every exercises at the same time.

hence "follow along"

I like Lisp (Scheme). They had an excellent book with the Wizard Book (SICP).
With Haskell, the two books I tried gave me the creeps. Totally anal retentive. I don't want to know the mathematical concepts behind Haskell, or at least not without getting to know how this language works. Sorry, but Haskell seems to be entirely made by and for weirdoes.

well he didn't use the do notation which would make it similar to your scheme code but without the parentheses.

Is it wrong if I like Hasklel AND Lisp?
Lisp is fluid and powerfull, Haskell makes you think about stuff like types a lot.

Peace.

I use a unityped FP-oriented language because Haskell code takes forever to compile and Haskell isn't that good for interactive use. I do miss return type polymorphism sometimes.

>It can't be used to make real applications
paulgraham.com/avg.html
cnet.com/news/yahoo-buys-viaweb-for-49-million/
Many such cases.

Don't fall for Jow Forums memes

>if you simply exercise a little self-restraint
That's a general argument against being given guarantees by the computer. Building on immutable primitives is very important in a language if you want to do sensible FP. Otherwise you'll quickly see a rise in libraries that use mutability hacks because of whatever excuses the developers come up with. It's fine to build mutable data structures on top of immutable ones are as a side feature. Racket and Clojure are good enough in this regard; Scheme and CL really aren't.

>not wanting gwern-kun on Jow Forums

How do I speed up my builds? Is it hopeless with Template Haskell?

>yahoo buys viaweb
>immediately gets re-written in python
>leddit becomes big
>immediately gets re-written in python
hmmm

What do you think of Cardano?

Attached: download.png (243x208, 3K)

No he didn't. Lispers thrive on spreading FUD and straight out lies. That's all they do.

...

>Jow Forums
lol

Cardano is a shitcoin.

>Writing in hipster languages is awful in general because they lack proper tools
Elixir is a hipster language and it has the best tooling ever.

>And specifically about Haskell, I really hate how it's one huge leaky abstraction. As a functional language it's really high level, but you still need to keep worrying about low level details (e.g. foldl vs foldl' vs foldr, lazy vs strict in general, using tail recursion whenever possible).
This is the best point against Haskell, though I disagree that tail recursion in particular is an abstraction leak. It is an optimization you need to keep in mind, but it is at your abstraction level, not below it. Space leaks caused by laziness, on the other hand, are a real and severe violation of abstraction.

>Also, can I just say that is god awful syntax?
Check out lexi-lambda.github.io/hackett/. It's like Haskell, but with the Correct Syntax.

this is so fucking retarded how could you ever think this kind of bound checking works

Sounds about right. Lisp is great for prototyping, but it was very hard to hire Lisp programmers until recently and it still isn't easy.

>using anything but snake_case

>using anything but the-best-case

for some reason I've always found Lisp et. al, Haskell, OCaml, and other "not popular" languages to have the best tooling and best environments. They often include support for features that are 60 years old yet are still missed in popular languages.

When is season 2 starting?

The HtDP light novel is a better starting point if you're new to the whole cross-franchise universe.

>OCaml
>best tooling
Seriously? Was your prior programming experience with INTERCAL? I am not sure how you can compare OCaml's tooling to, say, that of Common Lisp.

Is there any profit in learning a niche language, or are the only people who care about niche languages the people who learn them?

>using anything but camelCase for variables (functions are variables too), PascalCase for types and UPPER_CASE for constants
but it works, I've just tested it
There are still many cases it fails:
1) if puts fails
2) if fgets fails
3) if strlen(name) == 0 (^D to shut stdin was pressed)
It also should report an error if either puts or printf within if-else fails

who are the better programmers, the original ones or the maintenance guys. who make the most money?

Depends on what kind of profit you are after. If you want a mundane job that pays well, you are better off knowing mainstream languages. A recognized expert at a niche language can earn more, but a programmer with mediocre knowledge of the same language won't. If you want to be your own boss, launch a startup or accomplish something most programmers never do, I think Paul Graham's point still stands. If you are building WhatsApp, you better know Erlang.

I've heard it from several programmers (who didn't know each other) that Ruby on Rails allowed them to build products faster than their competition. Even Django wasn't as productive, one of them said. If they're right, it means not all niche languages with an advantage are as exotic as Haskell and Erlang.

But that's the thing. A purely functional program has no side effects, and doesn't do anything. And people don't actually write applications in Haskell, so neither do Haskell programs.

>A purely functional program has no side effects
Side effects can be expressed in a pure way.

What do people actually use Haskell for? Is it some sort of academic thing?
What's the distinction between an application and a program here?

>Why don't you use Haskell?

Attached: CZK3HG3UEAAHqbD.jpg (1024x1024, 175K)

Because only Scheme Lisp grants me the ability to cast spells

> (((Lisp)))

I like how thick the XML book is.

>Haskell
Why do you use a programming language version of yourself?

Lexi is a transsexual. Hackett makes my skin crawl.

>Hackett makes my skin crawl.
Why, though? (Other than Lexi zirself.)

This might be the best joke currently on Jow Forums

Does there need to be another reason?

It just seems kind of weak. I don't particularly like Lexi, but a real programmer should be able to appreciate code written by abominations from beyond the stars.

It's a fringe variation on an already fringe language written in another fringe language. And afaik it's not even particularly performant.

So why should I or anybody use it? The author being a tranny is really just icing on the shit cake; suppose I spent my time learning this system and he decides to off himself or find a new hobby? Trannies are anything but reliable.