What is it with these people making these Haskell lectures?
"Let's show a bunch of half confusing combinators and talk about how immutability is great". As someone who writes Haskell at his job, I find that baffling.
Why would I want to try out Haskell for the reasons shown in the lecture? Convince me with business prospects - not by showing people code they will not understand in 10 minutes unless they already do.
The thing is - there are _tons_ of good examples of using functional programming and Haskell concepts in Swift, using monads in async programming (ala promisekit) or using monads for JSON parsing to get nice syntax are both very real use cases that could save developers lots of time.
One last thing - my Haskell code compiles _a lot_ more than it works, saying "if it compiles it works" is one of the most damaging things people say about Haskell. Having a strong type system does not mean your code somehow doesn't have the hardest class of bugs. Not to mention it's all nice and dandy that it will let you pass stuff around - but when you implement an algebraic structure (like a Monad or a Monoid or whatever) you are the one in charge of making sure it abides to all the laws of that structure - this is fine but it would be awesome if people said that when they show you what monads are, the compiler helps verify your code with your help by you spending time proving assertions about your structures - not magically.
I love Haskell, and I think it taught me a lot about Swift, being able to do things like `Either` in Swift because it has strong enums is awesome (product types ftw). Can we please show people what actually works from Haskell instead of just saying monads and then giggling about it?
I'm sorry for the negative comment - it clearly looks like the author of the talk did a good job preparing it and he's a good speaker - I just think focusing on what he did does a disservice to Haskell and functional programming.
"Can we please show people what actually works from Haskell instead of just saying monads and then giggling about it?" — I think the speaker would wholeheartedly agree with you.
In several places, he says that learning and applying functional concepts can be hard, that it takes intellectual work, that is isn't just "magic".
If you're heading out to WWDC, Abizer Nasir is elaborating the talk for AltConf, Wednesday 10th. A good chance to talk this over in person: http://altconf.com/schedule/
> saying "if it compiles it works" is one of the most damaging things people say about Haskell
I've recently been getting a lot of logic errors with code at work I'm working on for a typeclass instance, so the "if it compiles it works" phrase has been banging around my head.
It's not always true with how most Haskell is written, however even the current logic errors I'm having, I can imagine how I could turn them into type errors or how I could encode the logic in the types.
However you can still get a logic error with your types as well. I think it's still a win as long as encoding those logic errors doesn't increase complexity too much.
To truly encode it you need dependent types, but even then you might get a beautiful specification and a program that is proved to satisfy it, only to find that you had the specification wrong. Wow, is programming hard!
I mostly agree, but I'll say (usually at the cost of more complexity upfront) you can encode quite a bit of logic into Haskell's type system.
But yes, you can easily create a beautiful specification for the wrong thing. I think that is worlds better than accidentally creating the right thing. We want precision right? Not to brute force try solutions until one seems to work that blows up later?
you can encode quite a bit of logic into Haskell's type system
You are right, it has limits, but we can push those limits quite a bit. A nice trick is to avoid Bool and look for richer types instead. For instance, avoid <= :: a -> a -> Bool. Use compare :: a -> a -> Ordering.
We want precision right? Not to brute force try solutions until one seems to work that blows up later?
Not sure. I like precision. I like to study it, I like to be able to use, I hate when other people don't use it, but I have come a long way building the discipline to use it consistently. Some days I still choose nasty hacks.
"I believe it was developed as a research programming language, and apocryphally, they didn’t have a way to get code in and out of the system. They couldn’t figure out how to create a pure functional I/O system until they came up with the I/O monad."
Uhm. No. No one has ever written a program that doesn't have some I/O facility. How would you even know if it ran?
I can get saying something like this over a few beers. But if you are going to speak or publish, maybe just go ahead and Google it?
"Let's show a bunch of half confusing combinators and talk about how immutability is great". As someone who writes Haskell at his job, I find that baffling.
Why would I want to try out Haskell for the reasons shown in the lecture? Convince me with business prospects - not by showing people code they will not understand in 10 minutes unless they already do.
The thing is - there are _tons_ of good examples of using functional programming and Haskell concepts in Swift, using monads in async programming (ala promisekit) or using monads for JSON parsing to get nice syntax are both very real use cases that could save developers lots of time.
One last thing - my Haskell code compiles _a lot_ more than it works, saying "if it compiles it works" is one of the most damaging things people say about Haskell. Having a strong type system does not mean your code somehow doesn't have the hardest class of bugs. Not to mention it's all nice and dandy that it will let you pass stuff around - but when you implement an algebraic structure (like a Monad or a Monoid or whatever) you are the one in charge of making sure it abides to all the laws of that structure - this is fine but it would be awesome if people said that when they show you what monads are, the compiler helps verify your code with your help by you spending time proving assertions about your structures - not magically.
I love Haskell, and I think it taught me a lot about Swift, being able to do things like `Either` in Swift because it has strong enums is awesome (product types ftw). Can we please show people what actually works from Haskell instead of just saying monads and then giggling about it?
I'm sorry for the negative comment - it clearly looks like the author of the talk did a good job preparing it and he's a good speaker - I just think focusing on what he did does a disservice to Haskell and functional programming.