A Pythonista's Review of Haskell

https://bytes.yingw787.com/posts/2020/01/30/a_review_of_haskell/

by yingw787 • 6 years ago

112 102 6 years ago

bytes.yingw787.com

pjdorrell• 6 years ago

In Python

type(type) is type

evaluates to True. And that is not permitted in mathematical type theory that the Curry-Howard correspondence applies to.

yingw7879• 6 years ago

On lobste.rs somebody pointed out that undefined satisfies the Curry Howard correspondence for Haskell, and I was wondering whether the proper analogue for Python would be NoneType in that case.

Comment here: https://lobste.rs/s/ovebeq/pythonista_s_review_haskell#c_gz0...

TheAsprngHacker4• 6 years ago

What Python and other dynamically typed languages call "types" aren't types at all in the theoretical sense. In type theory, types are properties ascribed to programs that describe their behavior and are part of a language's static semantics (AKA checked at compile time). Dynamically typed languages are really untyped (or from a certain perspective, "unityped," meaning that every expression has the same type: https://existentialtype.wordpress.com/2011/03/19/dynamic-lan...).

pdexter4• 6 years ago

Although it itself is deprecated, the TypeInType extension does exist.

https://www.seas.upenn.edu/~sweirich/papers/fckinds.pdf

https://www.reddit.com/r/haskell/comments/4180k3/what_is_typ...

matt-noonan• 6 years ago

And the only reason the language pragma is deprecated is because TypeInType is now just how things are, by default, with no opt-out.

Areading3144• 6 years ago

This page made me permanently write off Haskell:

https://wiki.haskell.org/Prime_numbers

It is so much work, so much effort to develop some very mediocre, very slow, and incomprehensible implementations of an undergraduate level algorithm. I ended up picking CL for the project I was working on (Project Euler) and never looked back.

yingw7879• 6 years ago

You are of course entitled to your own opinion, but I would say that’s unfairly harsh towards Haskell. GHC Haskell not only compiles down to a binary, it can also transpile to C—-, both of which can run performantly.

I started off FP with lodash, then moved to Python and built in functions, and I’ve tasted the benefits of applying functional programming in production, and so that’s what makes learning Haskell interesting and worthwhile to me. I’m looking forward to bringing what I’ve learned from Haskell towards the rest of the code I write, even if it’s not in Haskell.

Areading3144• 6 years ago

I write Python for a living, and it is an astoundingly productive language. What it gets right is the compromise between functional, object-oriented, and imperative styles. I too have been fascinated by the "pure functional" type languages, but they always fall short when it comes to "real world" projects.

pdexter4• 6 years ago

C-- is one of the stages of its compilation to a binary IIRC. I wouldn't say it "can transpile to C--", as if C-- is an optional target which the user then does something else with.

bjoli2• 6 years ago

You can implement the regular sieve of erathostenes using mutable unboxed vectors if you like. If you did not spend enough time in Haskell to realize that you are in no position to judge it.

On the other hand, I would have used CL as well...

whateveracct3• 6 years ago

If you did not spend enough time in Haskell to realize that you are in no position to judge it.

Sadly this will never stop anyone from doing it anyway.

I had a VPE (didn't know Haskell) who tried to read some of the team's Haskell and couldn't grok it despite his many years of software experience. His response? Spout that "people are saying the Haskell codebase is hard to understand" without any indication that he was in fact "people."

Areading3144• 6 years ago

"mutable unboxed vectors"? You mean like a C array? How primitive and horrifying!

oisdk• 6 years ago

What's developed on that page is not a simple sieve of Eratosthenes. You can of course write a simple prime sieve in Haskell like you would write in any imperative language, and it would be pretty much just as efficient.

The algorithms on that page are for incremental prime sieves. These are far more difficult to implement than a fixed-size sieve. What's more, I would argue that the Haskell implementations on that page are far shorter and easier to understand than the imperative counterparts. Take this version, for example:

    joinT ((x:xs):t) = x : union xs (joinT (pairs t))
      where pairs (xs:ys:t) = union xs ys : pairs t
    
    gaps k s@(x:xs) | k < x     = k:gaps (k+2) s
                    | otherwise =   gaps (k+2) xs
    
    primes = 2 : _Y ((3:) . gaps 5 . joinT . map (\p-> [p*p, p*p+2*p..]))

Compare those 5 lines to any of the algorithms found in:

Pritchard, Paul. ‘Improved Incremental Prime Number Sieves’. In Algorithmic Number Theory, edited by Leonard M. Adleman and Ming-Deh Huang, 280–88. Lecture Notes in Computer Science. Berlin, Heidelberg: Springer, 1994. https://doi.org/10.1007/3-540-58691-1_67.

Sorenson, Jonathan P. ‘Two Compact Incremental Prime Sieves’. LMS Journal of Computation and Mathematics 18, no. 1 (2015): 675–83. https://doi.org/10.1112/S1461157015000194.

ngcc_hk• 6 years ago

Any js-er review?

yingw7879• 6 years ago

If you mean Javascript to Erlang, probably not for the foreseeable future. I want to learn to ship product for a bit, and hopefully I can talk about that :)

hopia9• 6 years ago

What kind of products are you building?

mcaruso• 6 years ago

I'm a JS dev that learned Haskell over the past few years. Anything in particular you're curious about?

I guess if I were to mention one thing I really miss in Haskell it's having easy, generic dictionary types a la JSON. Give me some syntax sugar to write a dictionary like JSON objects, where the properties are ordered by insertion (unlike most HashMaps that are unordered or rely on some predefined Key ordering). Also I'd love some better record types.

intrepidhero• 6 years ago

"A functor instance lifts a function over some structure to affect only the values within. An applicative (a monoidal functor) leverages a structure and function together while lifting the function over structure. A monad (an applicative functor) creates new structure whilst in the process of lifting a function over existing structure."

I think https://xkcd.com/483/ should apply to programming languages too. ;-)

But seriously, can someone put this in English? Is it really more complicated than "apply a function to every object in a list"?

yingw7879• 6 years ago

I actually wrote a monad tutorial last year: https://bytes.yingw787.com/posts/2019/12/06/monads/

After reading about monads...honestly no, there is no way to simplify it. Without understanding the type system, it’s alien.

TheAsprngHacker4• 6 years ago

But "apply a function to every object in a list" isn't the definition that the author is getting at!

Most programmers probably know "map" as being an operation takes a function and a list and returns a list of the results of the function applied to each element of the input list. However, the "map" operation can be generalized to generic types other than lists, where it has different behavior but shares certain properties. In functional programming, the idea of a functor gives a name to this pattern.

The idea is that if you have some generic type `T a` covariant in `a`, there is a function `map : (a -> b) -> T a -> T b` that can "lift" every function `f : a -> b` into a function `map f : T a -> T b`. The lifting operation respects function composition and identity.

However, what if the function has multiple arguments, e.g. `f : a -> (b -> c)`? Then, `map f : T a -> T (b -> c)` An applicative functor lets you convert that `T (b -> c)` into a `T b -> T c`. So, with applicative functors, you can individually map each parameter of a multi-parameter function.

A monad is a functor that can be "flattened." It has an operation `join : T (T a) -> T a`, as well as an operation `return : a -> T a`. A monad can be seen as generalizing the idea of flattening a list, or generalizing async/await.

greydius2• 6 years ago

Small correction: Join should be T (T a) -> T a

anko2• 6 years ago

I really like your description. One thing i don't understand though, is why generalising these operations is considered a good thing?

In my day to day I spend a bit of time writing functional code, and a lot of time reviewing it, and when you generalise in this manner it hides a lot of the details of the algorithmic complexity. Is this operation happening in a future? or is on a list? You could argue that the type signature will let you know, but quite often it's inferred.

Suddenly I find myself needing an IDE just to do code reviews. People make arguments about naming variables and suddenly we're back to using hungarian notation.

I also find it's easy to make mistakes - you do a flatmap instead of a map and the Nones just vanish. Or you're composing so many generic functions that the intent of the code just disappears.

I guess i just wanted to see if it's just me.

gizmo686• 6 years ago

From the official documentation:

Functors: uniform action over a parameterized type, generalizing the map function on lists.
Is it really more complicated than "apply a function to every object in a list"?

It is defined for more data structures then just a lists. Other than that, not at all.

As far as I can tell, the only reason Haskell has both map and fmap is because "map" came first. When applied to a list, fmap and map are identical.

wk_end• 6 years ago

Well, in the case of functors - yes, that's basically it. Except it's also "apply a function to every object in a tree", "apply a function to an optional object (if it's there)", and so on (there's a list of ones built into Haskell's standard library here [1]).

And then the real kicker is - very often stuff can use that general functor idea ("apply a function to whatever objects are inside this wrapping object, whatever it is") instead of being written against a specific, concrete kind of thing. And then you can use that stuff in all kinds of unexpected places, and combine it with other stuff written in the same way, and it all composes together and works harmoniously.

[1] https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelu...

nybble413• 6 years ago

I think it's important to point out that Functor, Applicative, etc. are not only about "containers" like lists and trees which hold a specific set of concrete values but also things like IO actions ("compose this pure function with the result of the readLine action, producing a new action") or even regular functions (where the map operation is just function composition). When other languages import the concept they unfortunately often specialise it to only work on containers.

bontaq• 6 years ago

For things like this I recommend going to wikipedia and looking up "Functor" -- there's some weird dislike of category theory terms but we're all fine with terms like "singleton" or "Factory"

You'll see the definition and be like, "shit that's just a map." We sell each other a bit short.

Likewise for applicative, monoid, monad -- they're mathematically pretty clear and if you squint while assuming a list is a category, you can probably read most of the definitions and get it.

functor -> equivalent of map for lists

monoid -> equivalent of having an identity ([]) and a join (a.concat) for lists

applicative -> equivalent of turning one element into a list

monad -> equivalent of unwrappering list items, applying a function to each, and rewrapping it

This is just for lists, but the terms are more powerful than that and have many variations. The nice thing is because it's universal. You don't have to wonder, "have I done this pattern right," because you test the laws for them. It might also help, for some of the laws, to remember identity and associativity as like from multiplication -- ie 1 * 9 = 9, 3 * 2 = 2 * 3

TheAsprngHacker4• 6 years ago

applicative -> equivalent of turning one element into a list

This is only one part of the definition of an applicative. Applicatives must also preserve the monoidal operation (product). That is, there is a function `pair : f a -> f b -> f (a * b)`. Then, you can map functions of multiple arguments by turning `(a * b) -> c` into `f (a * b) -> f c` via `map` and passing it the result of the applicative `pair` operation.

monad -> equivalent of unwrappering list items, applying a function to each, and rewrapping it

I'm not sure how precise or accurate this definition is. I'd say that a monad is about collapsing multiple layers of a functor into one layer.

This is just for lists, but the terms are more powerful than that and have many variations. The nice thing is because it's universal. You don't have to wonder, "have I done this pattern right," because you test the laws for them. It might also help, for some of the laws, to remember identity and associativity as like from multiplication -- ie 1 * 9 = 9, 3 * 2 = 2 * 3

Yup, I agree that this is a benefit of generalizing these operations based on their common structure.

6gvONxR4sf7o• 6 years ago

Is it really more complicated than "apply a function to every object in a list"?

Not more complicated, but yes more general. Perhaps "apply a function to every object in a data structure," even when that data structure can be kind of a abstract.

elbear• 6 years ago

One thing that could help you understand is that Haskell has many types which act kind of like containers of primitive values.

One example is `Maybe a` which has a value `Just a`. `a` can have any type, including `String`, `Int`, `Float`, etc. But a function that accepts a `String` can't take `Just String` as an argument.

This is the problem that `Functor` solves. It applies your function to the value inside the container.

`Applicative` applies a function that takes two arguments to the values inside two containers. For example, you have the function: `<> :: String -> String -> String` and you apply it to two `Just String` values, like this:

    ghci> liftA2 (<>) (Just "hello") (Just " world")
    Just "hello world"

crimsonalucard7• 6 years ago

Haskell has no null definition of type Char, at least according to this Stack Overflow answer. Python doesn't distinguish between Char and String types with single and double quotes, so empty char is empty string is an empty list. It seems weird to me that for all the typing wealth Haskell provides, this base case doesn't exist, though I personally don't know what it is.

An empty string is equivalent to an empty list []

If you want a null use the maybe monad.

inimino4• 6 years ago

As anyone who has used C will recall, a char is just a small integer. And just the same in Haskell, a char is exactly one character. Once you understand that, this confusion makes about as much sense as expecting an integer to be "empty".

I suspect this kind of question would be better asked on the Haskell IRC channel or similar rather than trawling stack overflow for insights. If someone has the relevant missing insight they can quickly point it out and save a lot of confusion.

crimsonalucard7• 6 years ago

it does make sense. 1/0 = undefined aka null. The thing with haskell is that the concept of null is typed as part of a sum type meaning it will be handled with no runtime errors.

unnouinceput• 6 years ago

Quote: "I don't think you can do anything like this with Python or any other practitioner's language that I'm familiar with"

So, then you're not familiar with C/C++, Java, C#, Pascal/Delphi, Ada - to say the least.

rgoulter• 6 years ago

What's the equivalent of

    -- zs' = [Just 2, Nothing, Just 4]
    zs' = (fmap . fmap) (+1) [Just 1, Nothing, Just 3]

in C?

FeepingCreature5• 6 years ago

At least on the D side:

    Nullable!int[] zs = [2.nullable, Nullable!int(), 4.nullable];
    // no partial application, and
    // separate template parameters and runtime parameters
    // so (fmap . fmap) (+1) is one function
    Nullable!int[] zs2 = map!(apply!(i => i + 1))(zs).array;

The C version probably has a lot more function pointers, and may use nonstandard compiler functions like closures. But in principle you could do the same thing.

giornogiovanna5• 6 years ago

Yes, of course you can encode it in any language you want, but the point is that ML-ish languages make it extremely natural to think like this, and Java makes it impossibly painful. Haskell makes traditional imperative algorithms painful, though, which is arguably a greater loss.

woadwarrior012• 6 years ago

Of all the languages I've seen, Swift seems to be the best compromise between ML style FP and imperative programming.

sweeneyrod4• 6 years ago

ML-ish languages make it extremely natural to think like this

You say that, but actually fmap doesn't exist in OCaml (or I assume any other common MLs). Of course you can embed a language and type system within it that does have it (https://blog.janestreet.com/generic-mapping-and-folding-in-o...) but that's different.

goto11• 6 years ago

I guess you can implement fmap in any language with higher-order functions including Python. The point is it is built into Haskell and supported by a number of fundamental types out of the box.

Silhouette2• 6 years ago

So, then you're not familiar with C/C++, Java, C#, Pascal/Delphi, Ada - to say the least.

Well, yes, strictly speaking you can do just about anything in just about any Turing complete language if you work hard enough. However, expressing patterns like that with the powerful, general semantics and the elegant syntax of the Haskell version is not something that is offered by any of the other languages you mentioned.

It was perhaps an unfortunate choice of example, because many languages do have first class support for some sort of array/list type and some sort of optional/nullable type and so might offer a reasonably tidy implementation of this specific case. However, in Haskell, the exact same technique would apply just as much to any choices of Functors. Indeed, you can often write generic algorithms that work with any choices of Functors (or Applicatives, Foldables, Monoids, etc, depending on what minimal functionality is required for your algorithm to make sense). Likewise, there are very many generic algorithms already available in libraries that can be used with both the standard instances of those typeclasses and new ones you write yourself. This is the big win for Haskell's type and typeclass system, or what the original author refers to as its emphasis on structure.

smegma2• 6 years ago

Not sure about the last two you listed, but those languages don't support parametric polymorphism which means that although you can write a `fmap` method for things, the compiler can't check its type properly. At best you can write an interface, but that interface won't be able to guarantee that the functor returned by fmap is the same one you started with.

hopia9• 6 years ago

Java and C# at least should support (parametric) polymorphism via Generics. In Haskell you don't need GHC Generics to achieve parametric polymorphism though, it's used for different things.

nurettin• 6 years ago

IMHO, the solution to high cognitive load, given a high enough reward, is just persistent, methodical execution towards learning.

It will never converge towards being easy to handle. The load doesn't come from being inexperienced, it comes from keeping the big picture in your head (all your types and their interactions) instead of iterative thinking.

whateveracct3• 6 years ago

this isn't true - at least not in my years of professional experience

I barely keep anything in my head most of the time when programming in haskell. It's kind of related to the "emphasis on structure" point from the article. All of a type's "interactions" are just functions. There aren't any second-order things to consider due to referential transparency.

hopia9• 6 years ago

I agree, type signatures & inference and referential transparency offload the cognitive load from your head to the compiler/IDE.

Functions that actually work on the data structures are generally guaranteed to be able to work on the said data. This way you don't need to constantly be mindful of what the data looks like, the compiler does that for you.

sjakobi• 6 years ago

FYI OP: I posted your review on r/haskell where it got several comments: https://www.reddit.com/r/haskell/comments/ewjnf4/a_pythonist...

yingw7879• 6 years ago

Thank you very much for sharing it there! The more the merrier :)

hopia9• 6 years ago

Making it to the end of an almost 2000 page Haskell book in only 3 months is quite the feat.

While quite confusing to many, myself included, I would've loved to hear more about the types vs terms distinction, and overall about what's possible with type level programming. That's something fairly unique among programming languages after all.

I'd certainly be interested in reading more of the author's thoughts if he continues down the path of using Haskell to solve problems.

bojo• 6 years ago

I would highly suggest https://thinkingwithtypes.com/ - it's not a 2000 page monster, and specifically addresses what you are interested in.

hopia9• 6 years ago

I've been reading that book occasionally for months but honestly, many parts are somewhat too advanced for me for now. I've sort of backed off from type level programming for now to maintain productivity with building actual things. Still, I'd like to read about it from someone coming from imperative languages.

yingw7879• 6 years ago

Thank you! I’m on sabbatical so I was reading full time. I believe John (the guy who wrote the set of notes I credited) started writing them two years ago, and did two passes over the book. I also skipped a bunch of exercises nearer the end (parser combinators I need to review). Don’t feel bad if you take your time!

Python is still my strongest language, and I’m planning on shipping product for a bit after this, so I will be using that for the next few months. I’ll do my best to circle back to Haskell, I love the community and see its potential in what I want to do. Subscribe to my email list if you want to stay updated!

zzo38computer• 6 years ago

They mention indentation, but you don't have to use their indentation and can use braces and semicolons instead if you prefer, which is what I prefer, too. So, I think the indentation isn't so much of the problem.

A Pythonista's Review of Haskell

Related Stories