

What Haskell taught me about writing Swift - astigsen
https://realm.io/news/swift-summit-abizer-nasir-lessons-from-haskell/

======
inglor
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.

~~~
codygman
> 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.

~~~
iamcurious
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!

~~~
codygman
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?

~~~
iamcurious
_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.

------
jeremyjh
"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?

This is the fourth result from Googling the phrase: "Haskell before IO monad":
[http://stackoverflow.com/questions/17002119/haskell-pre-
mona...](http://stackoverflow.com/questions/17002119/haskell-pre-monadic-i-o)

~~~
jmgrosen
apocryphal: (of a story or statement) of doubtful authenticity, although
widely circulated as being true

------
morqon
Quite a few good tips here. Transcript and code samples too!

------
rmrfrmrf
I never thought of using a typealias for a function or specific form of
dictionary; that's very cool! Thank you!

