
Some Notes About How I Write Haskell - chopin
https://blog.infinitenegativeutility.com/2017/12/some-notes-about-how-i-write-haskell
======
KirinDave
This is a good and well-written article, but it's worth noting that I think
many of the ideas here cut slightly against the grain of current Haskell best
practices. Which is not to say any specific part is right, but for example the
entire discussion on QuickCheck is hard to really make sense of and arbitrary
is a famously good use of type classes.

Probably the most countercultural paragraph is the paragraph on recommending
you make a fresh type rather than reuse an existing type. I think that you
lose so many useful operations eschewing maybe for your uniquely named Maybe
[1] that a type alias is probably a much better call there, and also captures
what you meant more generically. Further, stuff like Maybe over a more
specific instance works much better with valuable tools like Compose.

Similarly, the redundant constraint on Empty is the sort of thing that will
only trip you up in the real world.

All in all, great article tho.

[1]: People underestimate the compiler cost of deriving instances. It adds up
very fast if you derive lots of functors and foldables in your quest for
unique names everywhere.

~~~
davidmr
Thanks for your commentary too. I’m starting to learn Haskell, and the nature
of the language seems to lead to less “best practices” articles out there.

Seeing knowledgeable people comment on things written by other knowledgeable
people seems to be the best way to learn how Haskell is done in the wild (i.e.
anything outside the text I’m learning Haskell from at the moment)!

~~~
KirinDave
Full disclosure, I _like_ ConstraintKinds and constraint oriented programming
in many cases, and you can find evidence of that in my comment history.

------
ByzantineO6
From the earliest days, amateurs instruct computers, while professionals write
executable stories. I loved reading the projection of this quip into Haskell.

~~~
samwestdev
What is that supposed to mean?

~~~
mlevental
it's pretentious nonsense about how programming should be declarative rather
than imperative and the implication that Haskell (the one true God) is. this
point of view of course forgets that Turing tape machines came first and
lambda calculus second and that most theory is still done using TMs rather
than categories.

~~~
dtornabene
easy there, you might want to get your facts straight before you drop vitriol
like that. LC actually came first, via Alonzo Church in Annals of Mathematics.
Turing didn't publish his definition for another year and also, he did his PhD
thesis under Church in LC notation.

~~~
coldtea
> _LC actually came first, via Alonzo Church in Annals of Mathematics._

That's irrelevant, as early computers weren't programmed in LC, not build on
such an architecture. And of course algorithms and even programs (e.g for
Babbage's computer) existed before LC.

~~~
wz1000
No computers have ever been programmed via Turing Machines, or built on an
architecture resembling TMs(Von Neumann architecture can be described as a
register machine). TMs are simply a mathematical formalisation of the notion
of computation, equivalent in power to the lambda calculus.

However, most programming languages(including C, Java, etc.) look much more
similar to lambda calculus than a description of a Turing Machine - and for
very good reason. Have you ever tried describing a TM that encodes even the
simplest logic? It is a pain in the ass.

Indeed, most courses on the theory of computation that discuss Turing Machines
etc. don't ever expect students to fully describe a Turing Machine. Many times
they use a language reminiscent of the lambda calculus to describe Turing
Machines.

Just take a look at the definition of Turing Machines on wikipedia and
examples of TMs:
[https://en.wikipedia.org/wiki/Turing_machine#Formal_definiti...](https://en.wikipedia.org/wiki/Turing_machine#Formal_definition)

[https://en.wikipedia.org/wiki/Turing_machine_examples](https://en.wikipedia.org/wiki/Turing_machine_examples)

That resembles no description of programs that are written by humans to run on
computer systems, unlike the lambda calculus.

~~~
jcranmer
Random-access, multi-tape Turing machines are actually very good descriptions
of computer hardware. The description of Turing machines in practice (using
unary or binary notation on a single tape) is generally done because they're
simpler and no less powerful, but modern computers hew much closer to a state-
transition model embodied by Turing machines than a symbol rewriting process
embodied by Lambda calculus.

------
nocobot
I found the paragraph about iterating with list comprehensions very
illuminating. As someone who is just starting to learn Haskell, deciding when
not to use map / filter is something where my intuitions regularly seem to be
off.

~~~
tom_mellior
I like the fact (that I didn't know before) that you can use refutable
patterns in the way shown here, as filters in a list comprehension. That feels
almost like logic programming.

~~~
suj1th
As somebody who works with Scala, List comprehensions (and associated filters)
were indeed a surprise to me as well when I started hacking in Haskell. Their
resemblance to logic programming makes it so much more elegant, and so much
easier to reason about.

~~~
s4vi0r
How do you feel about Scala currently? I'm a Scala dev as well who's kind of
been moving away from it over the past few months.

I'm not really sure of the future of the language. Most of the super committed
community members are fans of the Haskell inspired style, which is great (its
how I write Scala, personally) but I'm not sure why you'd then choose Scala
over Haskell, or if you need the JVM, Eta or even Frege. The majority of
'casual' Scala people seem to use it as Kotlin with implicits more or less,
and as more and more libraries and features come up for Kotlin I'm not even
sure that it makes sense to use Scala for those people, given the larger
backing, better tooling, easier on boarding, etc for Kotlin.

~~~
kod
There are plenty of people who use scala as an ML on the JVM, not as a worse
Haskell. They just aren't as loud about it.

If you're looking for an ML kind of experience, Kotlin is a joke, it doesn't
even have pattern matching.

~~~
suj1th
_> If you're looking for an ML kind of experience, Kotlin is a joke, it
doesn't even have pattern matching._

Can't agree with this more. I just cannot figure the raison d'être of Kotlin.

~~~
s4vi0r
To me it seems sorta like reasonable Java. Tons of QoL upgrades that Java
hasn't (or won't, due to compatibility issues) implemented over the years make
it so that you can write Kotlin without absolutely having to rely on a massive
IDE or something like project Lombok. They've got great tooling and a lot of
support, and they've been adding in tons of great features (e.g inline
classes/value classes coming soon).

If I had to build a company today Kotlin would definitely be at the top of my
list; I may love other languages much more, but Kotlin and C# are easily at
the top of the developer experience imo, since they've got great
tooling/ecosystem/support and both are very approachable/average languages
that won't really scare anyone away like how Haskell might (despite it being
one of the most underrated/most scare monegered/most misunderstood languages
out there imo)

------
rs86
This is very weird Haskell. The fizz buzz example concatenating strings where
an alternative would fit and the pointful point free example for instance.

~~~
chopin
I liked the fizzbuzz example very much _because_ it was so unorthodox.

------
Bootvis
Title would be more clear if it didn’t start with the title of the blog.

