What Is Good About Haskell?

https://doisinkidney.com/posts/2019-10-02-what-is-good-about-haskell.html

by nuriaion • 7 years ago

286 399 7 years ago

nicoburns3• 7 years ago

My Haskell isn't good enough to translate, but I'd love to see these examples in Rust. I believe Rust has all of the Haskell features mentioned in this article, but with a much more familiar syntax.

The tree data type in Rust could be:

    enum Tree<A> {
        Leaf(A),
        Node(A, Box<Tree<A>>, Box<Tree<A>>),
    }

sampo• 7 years ago

Why should

    enum Tree<A> {
        Leaf(A),
        Node(A, Box<Tree<A>>, Box<Tree<A>>),
    }

be more "familiar" syntax than

    data Tree a
      = Leaf
      | Node a (Tree a) (Tree a)

?

roar-of-time3• 7 years ago

The syntax and terminology (enums, structs, etc.) is more familiar to C++ / C# / Java users.

tiborsaas3• 7 years ago

I know what enum is, but data for me is just 1 and 0.

Are we assigning here with the =? What does the pipe symbol mean? Why pipe instead of another =? Why the weird formatting?

To me Haskell's look is too off-putting. With the Rust example I have a good guess what will the resulting object will look like.

But I know it's just a learning experience. Once I would know Haskell your example looks more elegant to me. I just don't get it from looking at it :)

HorstG3• 7 years ago

There is a huge unreadability right there staring at me: What does that Box<> do, and why? Rust is borrowing more and more of the obscurities of C++, and thats not a good thing...

enlyth• 7 years ago

Because everyone knows what an enum is, and that <A> will be a generic type, from first glance. There's nothing to guess, apart from Box being some kind of pointer abstraction.

Looking at the second definition it's not immediately apparent what 'a' is and "Node a (Tree a) (Tree a)" seems just like a bunch of words concatenated by spaces, it has no apparent structure or meaning, unless you're used to writing Haskell/ML/Lisp/etc.

nicoburns3• 7 years ago

There's no reason why it should be more familiar. But it is more familiar to the huge number of developers who are used to ALGOL/C family languages.

loeg4• 7 years ago

Literally the punctuation ("<>{}()") and lexical structure is more familiar to anyone who's written any C-family language (C, C++, Java, ...). I say this as a C programmer with more or less equal (near-zero) Rust and Haskell experience.

HelloNurse3• 7 years ago

    Node(A, Box<Tree<A>>, Box<Tree<A>>),

is obviously nested (a Node contains an A and two Trees) and the trees are optional (they are contained in a Box, whose purpose is obvious without even knowing the language)

    | Node a (Tree a) (Tree a)

might or might not be nested, given the cheerful taste for currying and juxtaposition without punctuation that prevails in Haskell syntax, and it isn't obvious what purpose the parentheses serve (just grouping ?) and whether the trees are optional.

LandR• 7 years ago

I would say the second one is more intuitive to me, it reads like I have a Tree type and it can be either a Leaf or a Node.

The rust example to me isn't immediately obvious that it's an either / or situation other than that must be how an enum works (I know enums from other languages)

perrohunter• 7 years ago

Because of the memory safety in rust, it’s now clear those left and child nodes could be missing since there’s no null in rust.

saghm• 7 years ago

Given that GP already stated they don't know enough Haskell to translate all the examples, it seems pretty clear to me that by "familiar" they mean "in a language I'm familiar with".

steveklabnik4• 7 years ago

It ends up looking like a halfway point between the two. A little of column A and a little of column B.

ur-whale3• 7 years ago

but with a much more familiar syntax.

This is actually one of my main two beefs with Haskell:

     . The language is really interesting from a feature point of view, but the syntax, oh man. Looking at Haskell code when you switch back and forth from a more conventional language (C/C++/JS/Java/C#/Python/etc...) is a major headache. I can switch from C++ to Python without a second thought. Not so with Haskell.

     . You can't really predict how something will actually execute, that's left to the language to decide. While in some situations this is a desirable feature, in many, it isn't at all, especially if you're writing performance critical code.

jonsen2• 7 years ago

1. The language is really interesting from a feature point of view, but the syntax, oh man. Looking at Haskell code when you switch back and forth from a more conventional language (C/C++/JS/Java/C#/Python/etc...) is a major headache. I can switch from C++ to Python without a second thought. Not so with Haskell.

2. You can't really predict how something will actually execute, that's left to the language to decide. While in some situations this is a desirable feature, in many, it isn't at all, especially if you're writing performance critical code.

gabipurcaru2• 7 years ago

I've been using Haskell for quite a bit in production. My personal take, as an engineer who is generally skeptical of fancy language features:

Plus:

- The type system. It can make your life a huge pain, but in 99% of the cases, if the code compiles, it works. I find writing tests in Haskell somewhat pointless - the only places where it still has value is in gnarly business logic. But the vast majority of production code is just gluing stuff together

- Building DSLs is extremely quick and efficient. This makes it easy to define the business problem as a language and work with that. If you get it right, the code will be WAY more readable than most other languages, and safer as well

- It's pretty efficient

Minus

- The tooling is extremely bad. Compile times are horrendous. Don't even get me started on Stack/Cabal or whatever the new hotness might be

- Sometimes people get overly excited about avoiding do notation and the code looks very messy as a result

- There are so many ways of doing something that a lot of the time it becomes unclear how the code should look. But this true in a lot of languages

verttii5• 7 years ago

What about runtime stuff? I've found Haskell is very good at abstracting away your concerns about the runtime considerations and sometimes it will come back to bite you. I mean all that stuff you want to see into when you're running your app in production, like caching, function invocation times, threads etc.

gabipurcaru2• 7 years ago

Can't really comment on that - most of the code I use is built on the awesome Haxl[0] so we never have to worry about those things. I'm curious what other people think though

[0] https://github.com/facebook/Haxl

roar-of-time3• 7 years ago

Yep, GHC is an incredible compiler and Haskell is an incredible language. If only Haskell had a package manager as slick as Cargo, I'd use it for just about everything.

atoav2• 7 years ago

I never really understand why I would want a type system until I learned Rust and was forced to learn it. Now I don't understand what I was thinking before..

mehrdadn• 7 years ago

What were you using before?

the_af17• 7 years ago

Don't even get me started on Stack/Cabal

Is Stack not adequate? I thought the consensus was that it was ok. Is it really more horrible than say Maven or SBT or whatever in other languages?

hope-striker3• 7 years ago

I guess it's comparable to Maven, but people usually use Maven with an IDE, and Stack on the command line, so that's not very encouraging. Anyway, compared to something like NPM (Node.js) or Cargo (Rust), its user experience is extremely lacking.

pwm3• 7 years ago

The great news is that tooling is rapidly improving these days. VSCode with the new ghcide is simply amazing. Ghcide is still new and thus has a few rough edges (eg. TH) but overall it lifts the Haskell IDE experience into the 21st century. Give it a try.

chungus• 7 years ago

tldr: I am NEVER nervous about refactoring some Haskell code.

Good:

After working in a variety of organizations using, typed but also dynamic languages I'm now writing all my back-end code in Haskell. I'm becoming more and more convinced that for multi-year, multi-programmer applications (a language like) Haskell is the only way to make it sustainable, while still being able to add features.

Stephen Diehl has a great writeup on "what he wish he knew when he was learning haskell" http://dev.stephendiehl.com/hask/

It's difficult to say to someone "Just go read books for a couple of months because you need to understand purity, laziness, cross compilation, monad transformers (go read The Book of Monads), 20+ language pragmas. etc etc"

It does however feel like I'm learning useful stuff, and it's a lot of fun to get an executable that runs FAST.

gnud• 7 years ago

ML seems to be a much more developer-friendly approach to me. Eager evaluation, no problem "escaping" to imperative code, no "purity". All the benefits of functional programming, a good type system, and a great module system.

I'm constantly sad that Standard ML is so outdated. No good tooling, no real unicode support, etc.

At least we have ocaml and F#.

toastal• 7 years ago

PureScript is an strict ML too and even closer to Haskell than F# and OCaml as it doesn't have the object-oriented bits and is pure (doesn't allow the same level of side effects like mutability as those two without the very explicit 'unsafe' functions).

fistOfKross• 7 years ago

I got curious about Haskell some years ago because of a complete career disappointed with other languages. Ive put out some semi big apps in this language, that have been working well in production. I code for fun and Haskell is the most fun. Sure, there has been a couple of problems with tooling and its hard to find best practices, but I seem to be able to live with. I get a little depressed when having to work with other languages. For me its the end game.

Beltiras3• 7 years ago

Friend of mine is always trying to convert me. Asked me to read this yesterday evening. This is my take on the article:

Most of my daily job goes into gluing services (API endpoints to databases or other services, some business logic in the middle). I don't need to see yet another exposition of how to do algorithmic tasks. Haven't seen one of those since doing my BSc. Show me the tools available to write a daemon, an http server, API endpoints, ORM-type things and you will have provided me with tools to tackle what I do. I'll never write a binary tree or search or a linked list at work.

If you want to convince me, show me what I need to know to do what I do.

eterps• 7 years ago

This a 100%. If Haskell proponents focused more on stuff that is described in https://pragprog.com/book/swdddf/domain-modeling-made-functi... instead of algorithms a lot more devs could use it in their day-to-day job.

yakshaving_jgt4• 7 years ago

It's all there to be used, it's just unfortunately Haskell proponents seem not to talk about it as much. Most of the discussion is around "interesting" stuff.

My company does everything in Haskell, but it's almost all just boring plumbing code. APIs, JSON, databases, HTTP stuff, HTML templating, etc. It works great.

atroche3• 7 years ago

Came here to say exactly this.

And also to point to this excellent article: https://pchiusano.github.io/2017-01-20/why-not-haskell.html

cousin_it• 7 years ago

Joel Spolsky called it two decades ago: https://www.joelonsoftware.com/2002/12/11/lord-palmerston-on...

Until you’ve done Windows programming for a while, you may think that Win32 is just a library, like any other library, you’ll read the book and learn it and call it when you need to. You might think that basic programming, say, your expert C++ skills, are the 90% and all the APIs are the 10% fluff you can catch up on in a few weeks. To these people I humbly suggest: times have changed. The ratio has reversed.

Read the whole article, it's pretty amazing. Parts of it are just as relevant to mobile development today as to desktop development back then.

tiew9Vii• 7 years ago

They do exist.

I use

http://hackage.haskell.org/package/optparse-applicative for small cli apps

http://hackage.haskell.org/package/envparse For any Docker microservice

http://hackage.haskell.org/package/aeson-1.4.5.0/docs/Data-A... For all JSON work. Sometimes I’ll use it with lenses which is massively powerful but a rabbit hole

I’ll use http://hackage.haskell.org/package/stm when dealing with parallel execution

https://github.com/brendanhay/amazonka For anything dealing with AWS

https://github.com/haskell-works?tab=repositories Projects for Kafka and avro

http://hackage.haskell.org/package/warp For trivial micro services or Scotty if more than a few endpoints

http://hackage.haskell.org/package/persistent For dealing with Postgres

http://hackage.haskell.org/package/parsec For dealing with any text parsing.

The tools are available, they can make things like cli apps and micro services trivial. However if you have never used a ML language before you will have a steep learning curve as very different to C style/based languages.

I was once of the opinion Haskell is academic, what can you use it for in the real world. Then I studied with it, played with it admittedly on and off over 1-2 years, hit hurdles where I had to think as so different to what I’ve learnt before. Eventually it clicked, it’s very hard and frustrating now in my day job using typical enterprise or popular languages. It’s not about convincing, it’s about having a open mind and wanting to learn something different

Beltiras3• 7 years ago

Those look really promising. My boss is big on TDD and open to developing cutting edge technologies. I'm going to have a look and see if I can propose a project using these tools.

pytester2• 7 years ago

"Packages exist for doing this" isn't the same thing as "this is a good ecosystem for doing this kind of work" though.

I'm fairly convinced that Haskell is good at preventing the kinds of bugs which you might run into writing, say, a parser or other kinds of very complex logical code, but I'm less convinced that the nature of the language helps with the kinds of issues you get hooking together APIs, databases, etc.

misterdoubt• 7 years ago

Sure, they exist. But pointing out that they exist is not "show me what I need to know to do what I do."

Instead, the next high-profile HN Haskell link will be the thousandth demo/intro/tutorial that yet again implements some core data structure.

Rather than showing how Haskell is great for working with databases.

Or working with Kafka.

Or integrating with AWS.

Or parsing text.

Or running microservices.

Or any of the other hundred things that I'm going to do a dozen times before I need to reimplement binary trees.

gowld7• 7 years ago

Haskell makes you hate your day job, but doesn't offer you a better day job, because it is a tease of something better.

tramav• 7 years ago

Does Data.Aeson parse JSON as UTF-8 and numbers as decimal? You know, in real world business applications we don't use float/double or ASCII.

bjz_• 7 years ago

You might be interested in checking out https://typeclasses.com/. You have to subscribe, but they have some free content, including this nice section: https://typeclasses.com/phrasebook, which gets right into printing to the console, and working with state, multi-threading and mutation.

amelius• 7 years ago

It's the other way around. Haskell is good at plumbing, while real algorithms are better done in a fast low-level language.

gowld7• 7 years ago

Haskell is good at plumbing in research programs, not in production systems that require monad transformers or extensible effects.

mumblemumble6• 7 years ago

So, I love me some ML-style languages, including Haskell, but I've also come to think that Rich Hickey is right about the real problems of business programming not being well solved by digging in on things like static typing.

For example, pattern matching against static types is cool, but, compared to pattern matching directly against data, Clojure-style, is even cooler. One makes the code a bit more concise and readable, but not necessarily a whole lot more maintainable. The other takes one of the more annoying and error-prone portions of my (say) Java code and renders it far more manageable.

There's a recent LispCast that talks about this a bit: https://lispcast.com/what-is-data-orientation/

chrisseaton• 7 years ago

What's the difference between 'business programming' and other types of programming? I don't really know what distinction people are trying to make here.

leshow7• 7 years ago

I don't know how you can claim that static typing & pattern matching don't help with maintainability. In languages with exhaustiveness checking and good pattern matching you can often make a change in one spot and literally just follow the compiler errors to implement a new feature. They help massively in refactoring, and that's important for maintanability.

agentultra3• 7 years ago

Rich is a smart person but I think he's missing some gaps in his knowledge of type theory and experience working with Haskell.

In one of his recent talks he made the claim that `Either a b` is not associative which.. well it is since it's provably isomorphic to logical disjunction which _is_ associative.

I thought what he might be looking for are _variant_ types which are possible to implement in Haskell but are a bit complicated for reasons. There are libraries for it or you can try languages like Purescript or dependently typed languages like Idris, Agda, or Lean.

Regardless I don't find his particular brand of vitriol appealing. If he doesn't really have a lot of experience working with Haskell like type systems, why does he feel the need to have an opinion about them?

To be fair I used to have a lot of the opinions pointed out in the article and reflected in many of the comments here. An old blog post of mine [0] muses on the utility of static types. I was seriously into Common Lisp at the time.

The problem with past me then was that I hadn't taken the time to learn and understand Haskell to form an opinion. I had learned Common Lisp out of frustration to win an argument that it as an old, crusty language that nobody used or needed anymore... and lost. I hadn't done the same yet for Haskell and would join the chorus of people repeating things like, "Haskell is an academic language but is not pragmatic for real-world use." It's embarrassing looking back on it.

I've learned enough Haskell in recent years to ship a feature into a production environment and teach a small group of people to hack on it. It's pretty great and I much prefer working with it than I do with weakly-typed or dynamically typed languages. The amount of work I can do with the amount of effort I have to put in has a great ratio in Haskell. The initial learning curve to get there is hard but it's worth it in the end.

[0] https://agentultra.com/blog/strict-types/

zelly4• 7 years ago

pattern matching against static types is cool, but, compared to pattern matching directly against data, Clojure-style, is even cooler

Maybe it's cool, but I think static types can be "cool" too. When you take the fashion statement out of the question, what are you left with? One is polymorphism at runtime and the other is at compile time. I'll take the compile time one.

_bxg17• 7 years ago

As someone who takes sublime pleasure in writing types around a domain, Rich Hickey's rightness on this issue makes me profoundly sad.

Here's an article I read a while back (from the same author it turns out!) which nearly converted me to the dynamic-types camp: https://lispcast.com/clojure-and-types/

AzzieElbab• 7 years ago

why not both when applicable?

ken2• 7 years ago

When I first studied compilers, I was amazed that writing a compiler used every other subfield of computer science I'd studied. It's the acid test of language design. A language that can easily be used to write compilers can do almost anything well.

And every non-trivial program I've worked on is 90% of a compiler. (You could describe compilers as just "some business logic in the middle", too, if you were in Architecture Astronaut mode.) You don't think HTTP servers use "pattern matching"? You don't think API endpoints would benefit from "ridiculously easy" testing? This is your bread and butter.

This article is showing how to implement if-statements and null-checks in Haskell, and reduce your code size by half. I bet you have some of those in your software. I'm not sure how this could be much more relevant, without reducing its usefulness by being overly specific.

gowld7• 7 years ago

You are conflating computer science (complete writing) with software application development.

In the real world, software has a CS "core", plus 95% boring data copying and gluing APIs together, where availability of libs and tools is far more important than theoretical correctness properties and the most general abstraction possible. This is why Haskell looks so nice in blog posts but terrible in a production system.

In Haskell, updating fields in a records is still an active area research.

leshow7• 7 years ago

Sum types infinitely useful in regular, non-algorithmic code you find every day. Look at something like redux and redux actions, those are essentially sum types and would benefit greatly from a pattern matching syntax. The benefits for this stuff is literally anywhere.

BoiledCabbage• 7 years ago

My best advice is do not try to learn functional programming via Haskell. It has done more to turn people off of functional programming that just about anything.

If you want to learn statically typed functional programming learn Elm (which takes only a few days), then one of F# or OCaml.

If you want to learn dynamically typed Functional Programming, learn Clojure or Racket/Scheme.

They amount of investment it takes to see return on learning Haskell makes it terrible for an introductory language. And every proponent of it glosses over this part. It has some advanced concepts but its not an introductory language.

There is so much benefit you can get to your coding from learning FP that you should pick a language that allows you to see and judge that value prop on your own quickly, not have to invest so much time to be haskell proficient to try to get the return on your learning.

claudiawerner• 7 years ago

I found Elm's type system to be extremely cumbersome in comparison to Haskell's.

jcora• 7 years ago

Or go all in and actually expose yourself to an entirely different programming paradigm, there is so much more to "FP" that you can only find in Haskell and beyond.

taneq• 7 years ago

It has done more to turn people off of functional programming that just about anything.

The only thing worse in my book is FP evangelists. FP has some cool ideas and is an interestingly different way to do things compared with imperative programming, but enough exposure to the “FP is obviously the best paradigm and anybody who isn’t a fanatic is clearly just unenlightened” crowd will sour anybody on it.

phonebucket• 7 years ago

I'm relatively new to Haskell, but Yesod has a good reputation for web application logic, and moreover comes with a free book introducing both itself and Haskell: https://www.yesodweb.com/

kerkeslager• 7 years ago

What I'm about to say is a criticism of you, but please don't take it personally. It's also a criticism of me, because my day job is essentially the same as yours.

In general terms, almost everything you and I do is either a CRUD app, or something overcomplicated which would be better-implemented as a CRUD app. There's not technological advancement happening here. And usually you're not even doing a new CRUD app, you're just reimplementing an earlier CRUD app with better CSS and JS and a different marketing team to tout it. IF there's an innovation in your company it's not the CRUD app developer who's innovating. We're just reimplementing the wheel over and over, because the other wheel implementations are closed source and owned by a competitor.

If you want to innovate, you have to take on harder problems that aren't CRUD apps. That's where languages like Haskell shine. Haskell doesn't shine because it's better, it shines because it's different, and suited for different tasks. The tasks for which Haskell is suited haven't been saturated yet, so there's still room for innovating on the technical side of things.

So yeah, I can't show you how to do what you do with Haskell--the reason you'd want to use Haskell in the first place is to do something different from what you (and most other developers, myself included) are doing. The reason you'd want to write Haskell is to solve technical problems which haven't already been solved.

You're right to bring up binary search trees and linked lists as criticisms of the Haskell community, because those are also pretty solved areas: touting binary search and linked lists as the powers of Haskell completely undersells Haskell. Haskell learning materials fall into two basic categories: complete beginner stuff, and Ph.D. theses written in an alien language. This is, unfortunately, part of why there's any innovation to be had here: having very little mid-level learning material creates a barrier for entry that keeps people from reaching a level where they could innovate. The same is true for the communities of many less-widely-used languages.

This has been a rather cynical post, I realize. I'm not sure there's any recommendations here: I'm certainly not going all-in on learning Haskell and using it to innovate, myself. CRUD apps pay the bills and innovation is risky. I find interest and novelty in other areas of my life.

oisdk10• 7 years ago

I wasn't really trying to convince anyone to use Haskell at their day job: I am just a college student, after all, so I would have no idea what I was talking about!

I wrote the article a while ago after being frustrated using a bunch of Go and Python at an internship. Often I really wanted simple algebraic data types and pattern-matching, but when I looked up why Go didn't have them I saw a lot of justifications that amounted to "functional features are too complex and we're making a simple language. Haskell is notoriously complex". In my opinion, the `res, err := fun(); if err != nil` (for example) pattern was much more complex than the alternative with pattern-matching. So I wanted to write an article demonstrating that, while Haskell has a lot of out-there stuff in it, there's a bunch of simple ideas which really shouldn't be missing from any modern general-purpose language.

As to why I used a binary tree as the example, I thought it was pretty self-contained, and I find skew heaps quite interesting.

reificator9• 7 years ago

> functional features are too complex and we're making a simple language. Haskell is notoriously complex

This is a true statement. (Opinion yada objective yada experience yada)

In my opinion, the `res, err := fun(); if err != nil` (for example) pattern was much more complex than the alternative with pattern-matching.

This is also a true statement. (yada yada)

The insight I think you're missing is this piece right here: `we're making a simple language`. Their goal is not necessarily to make simple application code. That's your job, and you start that process by selecting your tools.

For certain tasks, pattern matching is a godsend. I'm usually very happy to have it available to me when it is. And I do often curse not having it available in other languages to be honest.

But Go users typically have different criteria for what makes simple/reliable/maintainable/debugable/"good" code than Haskell users have. Which is why the two languages are selected by different groups of people handling different tasks. You're making a tradeoff between features and limitations of various languages.

And the language designers have an even different criteria for those things. In this case, adding pattern matching would absolutely make the language itself more complex, and they apparently don't believe that language complexity is worth the benefits of pattern matching. I think that's a perfectly reasonable stance to take.

zelly4• 7 years ago

I learned Haskell and it's a giant waste of time. I'm not the only one who regrets functional programming either. Since then I vowed never to take things seriously that have zero connection to real world results. It's not possible to regret mastering x86 assembly for example, because even if that skill is relatively useless, it makes you better at many tangential things which can be decidedly useful; C and OS programming for example. Functional programming doesn't have this potential because it (proudly) exists as an abstract model with no connection to the machine or any physical processes for that matter. It's the string theory of computer science.

If you like math/category theory, go deep on the math itself. Your knowledge will be transferable to more than just some man-made story (like a programming language).

rifung2• 7 years ago

Since then I vowed never to take things seriously that have zero connection to real world results. It's not possible to regret mastering x86 assembly for example, because even if that skill is relatively useless, it makes you better at many tangential things which can be decidedly useful; C and OS programming for example. Functional programming doesn't have this potential because it (proudly) exists as an abstract model with no connection to the machine or any physical processes for that matter

Hm interestingly I actually felt like learning Haskell had a huge benefit to my day job, probably much more than I imagine learning x86 assembly would. (Though admittedly I have learned some assembly in the past and that was also helpful).

I feel like Haskell forced me to write better code by forcing me to think about side effects. I don't know that I would actually use it in a production project because unfortunately real projects often rely a lot on state, even if constrained to a subsystem, and I still find it difficult to reason about the performance of a Haskell program.

Not trying to invalidate your point; perhaps you were already very good at what I learned via Haskell =] I admit I also find Haskell much more enjoyable to program in for the most part.

nepeckman• 7 years ago

I totally disagree. Functional programming teaches practices that are helpful regardless of what paradigm you use. Pure functions by definition adhere to dependency injection and single responsibility principle. While most programming languages don't enforce immutability, being aware of mutation is a generally helpful skill. There's a reason that lambda have become table stakes for new programming languages, and that's because composing functionality is a generally useful feature. I have never been paid to write in a functional language, but learning from functional languages has always improved my general programming skills.

_bxg17• 7 years ago

This is a very narrow-sighted perspective. Most application-level programming these days happens in languages that are "abstract model[s] with [little] connection to the machine or any physical processes". You just happen to be a type 2 programmer: https://josephg.com/blog/3-tribes/

schoen• 7 years ago

One thing I've found interesting in my very limited experience of Haskell is the connection to formally verifiable properties. Programs written in C or assembly very often have correctness and safety problems—among many others, memory corruption problems. Haskell and many related systems help provide tools to check programmatically that various large classes of error condition can't be present in a code base.

You might think that this isn't worth the mathematical rigamarole that comes with it and that it's grown up with, but as people have seen in a number of other HN threads, formal methods are having a renaissance now and the tools we have that engage with them can get us a lot further than they could in the 1960s.

I have written many bugs, of many different kinds, in other languages that could have been detected automatically by a type system like Haskell's. I'm not suggesting that that makes the other languages inherently bad, or that other programmers (or I) couldn't adopt other methods that would also help avoid these errors, but I think the ease with which Haskell's approach can do it is something interesting to consider.

patientplatypus2• 7 years ago

THANK YOU

_bxg17• 7 years ago

I've been curious: what does it take to find a job in software that isn't just gluing things together? Where do you have to go to write interesting algorithms at work? In our golden age of open-source, does that stuff only ever happen at FAANG and research labs?

ci5er• 7 years ago

Everywhere! 3rd gen factory robotics, and manipulator control. Movie cg renderers and asset transformation pipelines (heck, get busy and finish inkscape!) Ehr systems. ERP systems. Risk management systems. Decision support systems. Trading systems. Field service support systems. Scheduling, packing, routing systems.

Now everything has an ui, and data innies and outies, but gosh! That's just connectors to the diamond!

oppositelock2• 7 years ago

Those jobs exist, but are few and far between, since cool ideas tend to be packaged up into reusable libraries, and don't need to be redeveloped, while everyone else uses these reusable libraries differently, so you have a constant need for "sanitation engineers". Tensorflow or OpenCV or UnrealEngine get written once, then everyone uses them to build whatever they're building. You write some cool glue around these, that's the interesting code, then spend most of your time wiring everything together into a larger package that actually does something useful.

Once you've wired everything together, now you need to track version, build artifacts, manage release processes, test them and qualify them, etc, so you do a lot of QA and DevOps work.

QA, DevOps and sanitation engineering is so product specific that it can't be packaged up, it's a craftsmanship position, and that's why all of us spend most of our time doing this kind of work.

iainmerrick• 7 years ago

Most people at Facebook and Google aren’t writing algorithms either.

Chris_Newton• 7 years ago

I look at this the other way around: if you’re only writing CRUD applications and relatively simple user interfaces for them, you tend to end up doing join-the-dots programming, but for almost any other field I’ve ever worked in, things get more interesting.

For example, we have a client at the moment who makes a type of device with a lot of user-configurable behaviour. An embedded web server allows access to its UI from a browser, and we were originally brought in to build that web UI for them. On the face of it, this is a substantial but straightforward SPA development, just one where the back end happens to talk to APIs that communicate with various physical components in the device rather than a traditional database.

However, it turns out that the way users view that device and how they want it to behave is very different to the way you have to program the various physical components to make useful things happen. That means even in this superficially simple project, we have some interesting algorithms in the front-end to present application-specific visualisations of the current state of the system, and we have a much more involved algorithm sitting behind that UI that converts the user’s tidy, intuitive view of the world into the very untidy and often counter-intuitive data formats required internally to program the hardware components.

To make this comment slightly more topical, I’ll also mention that the behind-the-scenes algorithm is essentially a form of compiler, taking a serialised version of the user’s world as input and running through a pipeline that systematically converts the data into the required internal formats. The first generation was written in Python, and has proven to be reasonably successful, but we are always a bit nervous about maintaining it just because of the number of edge cases and interactions inherent in the world we’re operating in. For the second generation, we made a big decision to go with Haskell instead, and for this sort of work, there were very welcome benefits including greater expressive power when writing data-transforming code and a strong type system that prevents mistakes like accidentally forwarding data from one pipeline step to the next without applying an appropriate transformation.

I agree with Beltiras’s point in the GP comment, and I probably wouldn’t choose Haskell to implement the kinds of software mentioned in that comment for much the same reasons. However, it definitely has real value in the sort of situation I described above, where we have both integrations with other systems but also substantial data crunching to do.

mbo4• 7 years ago

So, I've been a Scala programmer for the last 3 years, and have been effectively writing Haskell in Scala reasonably effectively.

The pure FP Scala community understands your complaints more than the Haskell community.

https://typelevel.org/ is chock full of

a) useful utilities for actually writing applications

b) decent documentation. Not just pages of type signatures, but demonstrations of the libs usage.

Everything you need is here: JSON, config, units of measure, streams, testing, validation, a really nice JDBC wrapper (https://tpolecat.github.io/doobie/)

Throw in https://http4s.org/ and you've got yourself a rock-solid, purely functional stack with sensible, documented APIs, a more readable syntax and better tooling support.

I urge anyone who learnt some Haskell, thought "man this shit sucks, I'm never going to write something useful in this" to at least give FP Scala a chance. Here's a useful service template to start hacking with: https://github.com/http4s/http4s.g8.

AdieuToLogic5• 7 years ago

Another great resource for doing FP in Scala is "Functional Programming in Scala"[0]. It's a very well written book and goes far in introducing key FP concepts IMHO.

0 - https://www.manning.com/books/functional-programming-in-scal...

dwohnitmok3• 7 years ago

I feel conflicted about this having programmed in both OO-heavy and pure FP Scala. On the one hand, sure if you want to write pure FP in Scala, some of the tooling is better than Haskell. Most notably the IDE situation with IntelliJ's Scala plugin has made leaps and bounds in progress the last few years and mostly handles pure FP Scala code just fine. And having access to the JVM ecosystem is an absolute god-send and huge boost to productivity. This is true even outside of library dependencies when coding. If you try deploying to production with Haskell, there's often a large gap in production tooling (monitoring, diagnostics, GC tuning, etc.) when compared to the JVM.

On the other hand Scala has its own share of infelicities when it comes to pure FP. I've mentioned this elsewhere, but the core language of Scala, that is the language that is left after you desugar everything, is OO and the FP part is really just a lot of syntax sugar mixed in with standard library data structure choices. That means if you're coming from a pure FP background a lot of things will seem like hacks (methods vs functions/automatic-eta-expansion, comparatively weak type inference, the final yield of a for-comprehension, subtyping to influence prioritization of implicits for typeclasses, monomorphic-only values vs. polymorphic classes, etc.). Treating Scala as an OO language side steps a lot of these warts.

And then there's the social factors; the Scala community is split on how much it embraces pure FP and pure FP is a (significant) minority within the community. This carries over to the library ecosystem where things are basically split into Typelevel/Typelevel-using and non-Typelevel libraries. Many workplaces have a fear (well-placed and not so well-placed) of the Typelevel ecosystem. Years ago Scalaz was something akin to the bogeyman in some places. Cats has a bit of a softer image, but still comes off as an "advanced" library in the Scala ecosystem.

Most of the social weight I feel is behind the non-pure-FP parts of Scala. Sure some of the libraries in pure FP Scala have good documentation (but I don't actually think the situation here is far better than Haskell's once you leave the core Typelevel libraries). The ones with excellent documentation though live outside the land of pure FP (Akka, Play, Spark, Slick, etc.).

thrower123• 7 years ago

Yeah, this more or less completely misses the point of what a working programmer would need to be doing. I honestly can't remember the last time I had to implement a data structure for real, and not just for the hell of it because I was bored. The closest I come is generally some sort of domain-specific shell that composites some data together.

I feel like the F# community tends to be more grounded in reality. Or at least I'm more exposed to the side of it that is trying to popularize it in Microsoft, as a useful tool for Domain Driven Design and the like.

h91wka14• 7 years ago

Haskell is a beautiful research language. Its usecase is to supply subjects for PhDs and MScs, which it fulfills perfectly. Also it's extremely fun to learn and play with.

I would never bring it to the production though, reasons being:

1) Production code should be understandable by an on-call person at 4 am. If business logic is buried under layers of lenses, monad transformers and arrows, good luck troubleshooting it under stress. And real systems do break, no matter type safety.

2) It's a research language, and a big part of the research is about control flow. And therefore haskell has _way too many_ ways to combine things: monad transformers of different flavors, applicative functors, arrows, iteratees, you name it. And libraries you find on hackage choose _different_ ways to combine things. In the business code you probably want to combine multiple libraries, and you inevitably end up with unholy mess of all these approaches. Dealing with it takes more time than writing business logic.

3) Developers look at these fancy research papers and try to reproduce them. As a result, very basic things become extremely hard and brittle. I saw a real-live example when applying a transform to all fields of a record took a team 2 days of discussion in slack, because "writing this manually?! it won't scale to record with 100 fields".

4) Architecture is extremely sensitive to the initial choices due to isolation of side effects. Because if you suddenly need to do something as simple as logging or reading a config in a place where it wasn't originally anticipated, you're in for a bumpy ride.

ukj8• 7 years ago

Architecture is extremely sensitive to the initial choices due to isolation of side effects.

This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation.

It requires you to be perfect at Waterfall ( https://en.wikipedia.org/wiki/Waterfall_model ).

Real-world problems laugh at such idealism.

mic473• 7 years ago

Architecture is extremely sensitive to the initial choices due to isolation of side effects.

Only if you choose to isolate all side effects from each other. Actually Haskell makes refactoring really easy, so you can adapt your implemention to changing requirements easily.

youerbt7• 7 years ago

This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation.

This is simply bs. Haskell is actually a language (that I know of) where, IMO, your initial choices matters least. And that's because it's gives you great refactoring experience.

vapou• 7 years ago

Do you have any evidence to back this up?

In my experience working in the largest Haskell team in the world, dealing with various applications and services in production: none of what you said is close to reality.

h91wka14• 7 years ago

All the evidence is out there in Hackage. I backed up my points with some argumentation at least, and you dismissed it based on personal experience that we have no way of verifying. So, not changing my mind yet.

nuriaion• 7 years ago

At which company is the largest Haskell team in the world?

magicalhippo7• 7 years ago

Maybe you could shed some light on how to deal with the issues mentioned?

Especially point 4 sounds very painful. I frequently have to add logging or special case handling at different places in our code base.

thedataangel2• 7 years ago

I write Haskell commercially, and none of the problems you list are problems my team actually has in reality.

adambyrtek• 7 years ago

Your comment would be much more interesting and constructive if you actually took the time to refute the individual points instead of just saying that it's not a problem for you.

h91wka14• 7 years ago

How do you deal with #4?

sanxiyn2• 7 years ago

Then Haskell failed. To quote from Haskell 2010 Language Report, the primary goal of Haskell was: "It should be suitable for teaching, research, and applications, including building large systems".

Applications and building large systems are explicitly goals of Haskell. Haskell was never intended to be a research language.

coldtea3• 7 years ago

"Avoid success at all costs" is also an explicit goal of Haskell.

Haskell was never intended to be a research language.

Intended and actively tried not to be are two different things...

rishav_sharan2• 7 years ago

Agree with #1. I think Elm is probably the best functional language in this regard. Contains all the important bits yet is small and opinionated enough to be easily readable.

If only weren't web only and run as a private project. An elm like language with llvm backend would be amazing

platz7• 7 years ago

Elm is like the Go of the FP world. It really works for some people, but others find working in a kneecapped language infuriating.

leshow7• 7 years ago

I think Elm gets old after a couple weeks when you realize how handicapped it is as a language. Personally, I think something like Reason/OCaml is a great place to start. Haskell is a good choice too but laziness adds an additional hurdle. The core of Haskell is actually pretty simple; it's algebraic data types, parametric polymorphism, and typeclasses.

If only weren't web only and run as a private project.

Yeah, the way the project is run is troubling.

machiaweliczny2• 7 years ago

Elm is copy-paste language (too much, maybe can/will be improved)

implicit2• 7 years ago

I've done commercial Haskell work and it was fantastic. Almost all of the things you mention are problems with technical leadership and not Haskell itself. These problems are all very, very easy to deal with.

1) Many of us have also seen the C++ library or application that busts out the template metaprograms at every opportunity. Haskell is the same. Use restraint when bringing in new libraries and programming techniques. (as an aside, I have yet to encounter a single problem that I thought merited the use of arrows)

2) You also see this in other languages, though to a lesser degree. The same techniques we use with other languages work just as well in Haskell: As leadership, form a strong opinion on the best way to write control flow and ensure that everything uses a consistent style.

3) Are your engineers running around implementing random research papers? This has nothing to do with Haskell.

4) In practice, this is almost never a big problem. Refactoring a pure function to an effectful function is easy and safe. In a production setting, almost all of your functions run in some monad already, so it's pretty rare to run into a situation where you suddenly need to percolate effects through many functions.

h91wka14• 7 years ago

problems with technical leadership

I've never been lucky enough to get a full-time Haskell job (nor did I try), so my experience is based on single-man development & prototyping using the existing stuff found on Hackage. I presume that it may be different for a huge organization that can afford to build the entire ecosystem from the ground up while enforcing design rules (and these rules must be created by an exceptionally brilliant architect!). But in other languages you don't have this situation.

Many of us have also seen the C++ library or application that busts out the template metaprograms at every opportunity.

C++ and boost set standards a bit low, to be honest.

Are your engineers running around implementing random research papers? This has nothing to do with Haskell.

Not research papers, just the usual business logic. The problem is that research papers set the code style. Also they are not "my engineers".

In practice, this is almost never a big problem.

It typically is, because changing internal implementation is reflected in the interface, and for each invocation of the function change has to propagate through _the entire_ call stack to some place running in IO monad or whatever.

almost all of your functions run in some monad already

You defy your own argument. If that's how you design application, what's the point of bothering with side effect isolation then?

gowld7• 7 years ago

That's right. Java is advertised as a "workman-like language" (today we should say worker-like) because it doesn't require a guru leader to get a working project built.

At my job, software is only have the engineering, we need to save half our brains for product/business issues.

lallysingh10• 7 years ago

WTF is your oncall person doing reading code at 4am? What state of mind do you expect this person to have at that time? What are they expected to do?

That's a huge red flag.

As for the rest.. I don't think the language was the problem at that team.

biesnecker• 7 years ago

What are they meant to do if the world starts burning at 4am? Wait until a reasonable hour? Oncall fires at 4am suck but they're part of running critical services.

magicalhippo7• 7 years ago

Just yesterday we got a support call at 2am which quickly escalated to one of my dev coworkers. He had to dig through code to find the problem and push a fix at 3am.

The problem had to be fixed right then as further delays would cause heavy disruptions of the operation for that day, which would have been very bad for our customer.

While support can deal with most issues, it's not entirely uncommon that us devs have to step up and either help fix the issue by analyzing the relevant code, or actually push a fix in the middle of the night.

antisemiotic2• 7 years ago

Production code should be understandable by an on-call person at 4 am.

I don't like the "simple language means understandable code" argument being thrown around like it was some obvious fact. I'm currently working on a project whose major component is a byzantine home-grown message passing framework written in pretty much Java-in-C++ (old school OO with liberal use of shared pointers. Not that I would call C++ in any form "simple", but I do think that C++ without template magic is simpler than Haskell with GHC magic, or, say, any Lisp with a lot of macros). Maybe it's a case of grass being greener on the other side, but I'd gladly take a monad transformer stack or a DSL written in Lisp macros over doing the same song and a dance over and over again just to implent a tiny new functionality, or trying to deduce the logic from someone else's sea of boilerplate.

I mean, taking this logic to extreme, one could say that code written in assembly is easy to understand: it's adding a value to EAX now, then it jumps over there...

This being said, Haskell does have something in it that encourages one to design a ballistic algebra that runs in the type system before even pointing a gun at one's foot.

h91wka14• 7 years ago

This being said, Haskell does have something in it that encourages one to design a ballistic algebra that runs in the type system before even pointing a gun at one's foot.

Haskell is not even a total language, so type system doesn't magically divert gun from your feet. You can easily prove False in Haskell (there's a Prelude function for doing this!), enough said. And if you want types keep your feet safe, it's possible of course, at a _great_ cost, and not in Haskell.

08-152• 7 years ago

Cute how none of this relates to the article. Why do you have a list of straw-man bullet points to rattle off whenever someone says "Haskell"? Who hurt you?

duxup• 7 years ago

Those don't seem like "straw-man bullet points".

excursionist• 7 years ago

Production code should be understandable by an on-call person at 4 am. If business logic is buried under layers of lenses, monad transformers and arrows, good luck troubleshooting it under stress. And real systems do break, no matter type safety.

You can say the same thing about production Java code buried under layers of frameworks, factories, facades, proxies, aspects, annotations, etc. I don't see why readable, maintainable code can't be written as easily in Haskell as Java, C++, Python - you just have to make writing clean code a priority.

BubRoss• 7 years ago

I think this points to a difference that I don't see highlighted enough - influential doesn't mean best.

If you are stuck on a plane are you going to watch citizen kane or something from the last couple of years. What about an Akira Kurosawa movie? They top film critics' lists of the 'best' movies, but really they are some of the most influential movies of all time.

Lisp and Haskell aren't the 'best' languages to use the vast majority of the time, but they heavily influential and have contributed a lot to computer science.

bpyne6• 7 years ago

"1) Production code should be understandable by an on-call person at 4 am. If business logic is buried under layers of lenses, monad transformers and arrows, good luck troubleshooting it under stress. And real systems do break, no matter type safety."

Let's assume that your on call person is a developer. (If the person is not a developer, (s)he is not going to comprehend any language.)

1) If your application is written in Haskell, the on call developer would more than likely have been involved in the code base and reads Haskell. Your assertion about not comprehending it seems suspect.

2) You have a serious process issue if a developer is woken from a sound sleep to track down, correct, thoroughly test, and promote a fix for the bug in the middle of the night. The number of cases in which this happens should be close enough to zero to call it zero.

Your comment sounds like an attempt to cast Haskell as a purely academic language because it fails a (poorly) made up real world scenario. I'm NOT a Haskell-er so I don't feel a need to defend it. I do find the reasoning behind the criticism poorly thought out.

oarabbus_• 7 years ago

1) do you mean to imply all languages are equally parseable?

2) You’ve never worked in a company where a bug brought down prod and an on-call has to fix it?

pwm3• 7 years ago

Many others have replied to your concerns already, nevertheless allow me to add my own experience to the pile, as someone writing Haskell for food:

1) For a team of Haskell programmers reading Haskell code is just the norm. It's the same as for a team of Python programmers reading Python code. Also as a side-note: I never in my 15 years of professional life had a 4am call. Maybe I'm lucky, I don't know. In my experience automated tests, code reviews, sane deployment policies, etc... all minimise the chance of this ever happening. Haskell's powerful type system helps a lot here as it saves you from a whole array of problems upfront. I feel much more confident deploying Haskell code to production than code in any other language.

2) In commercial projects engineers tend to do things in sane and simple ways. This is not surprising really. Just cause you can does not mean you should. It's not Haskell specific but a general principle ie. KISS.

3) "Fancy research papers" at times can actually be really helpful. If you happen to have a problem that someone wrote a paper about that saves you time having to rediscover the solution. Having lots of research papers is imho a great strength of Haskell. That being said KISS from above applies here. If your problem is simple then do it simply.

4) Architecture in general is much less sensitive to change in Haskell than in other languages in my experience as the type checker guides you when you want to change your code. Refactoring in Haskell is pure joy. Re logging/configuration/etc... there are well-known patterns to deal with these as you would imagine, it's not like no one had to solve these problems in Haskell before. There are also tools (eg. Debug.Trace) in case you need some quick ad-hoc printf-style debugging. The same really as in any other language.

I don't want to write about all the pros of the language, others have done so already, just wanted to add my own professional experience to the mix.

leoh• 7 years ago

4) Architecture is extremely sensitive to the initial choices due to isolation of side effects. Because if you suddenly need to do something as simple as logging or reading a config in a place where it wasn't originally anticipated, you're in for a bumpy ride.

Not a serious Haskeller at all, so not sure if this is a terrible practice, but for logging, `unsafePerformIO` could work in a pinch without changing types.

euske• 7 years ago

I think Haskell is conceptually cool, but I just can't stand its symbols and grammars. To me, "=>" means comparison and "|" means an OR, and I'm cringed to see $s and \s in a program code that makes it look like LaTeX. I also prefer the boundary of terms and expressions to be consistently marked up with parenthesis. I know this is just a matter of taste, but sometimes it affects your motivation a lot.

ggm2• 7 years ago

I have had this the syntax is horrid conversation many times. I share your traits of how symbols are seen and mentally spoken clouding the concept. My adversaries argue from positions of clearly complete comprehension of the algebraic intent of these 'words' and they can't understand my confusion. It's like arguing with a native English speaker about illogical spelling, it just gets a "get over it" response.

ur-whale3• 7 years ago

I 100% agree. Haskell is a very sad story in that regard: the language brings tons of cool features to the table only to turn away most of its potential customers because of how ugly and weird it looks.

jolmg3• 7 years ago

"=>" means comparison

In what language? Did you mean ">=" or "<="? They mean the exact same thing in Haskell.

"|" means an OR

It also means the same thing in Haskell.

  data Maybe a = Nothing | Just a

"data of type `Maybe a` is either `Nothing` OR `Just a`."

  max a b | a > b = a
          | otherwise = b

"max of a and b is either a when a > b OR b otherwise."

  odd x || x >= 5

"x is odd OR x is greater than or equal to 5"

A cool thing about Haskell is that it lets you define new operators. In the parsec package, you get the operator <|>, which keeps the meaning of OR but works with parsers.

  csvCell = csvQuotedCell <|> csvNonQuotedCell

"a CSV cell is either a quoted cell OR a non-quoted cell".

I'm cringed to see $s and \s in a program code that makes it look like LaTeX

I don't think they're so common that the comparison is valid. $s implies Template Haskell, which should be used sparingly. \s implies lambdas, which are nowhere near as common as the use of backslashes in LaTex.

I also prefer the boundary of terms and expressions to be consistently marked up with parenthesis.

The way you wrote this, makes me think you prefer to write 2 + 5 * 2 as 2 + (5 * 2). You can do that, just like in any other language. I don't think it's common to add parenthesis redundantly in any language though.

If you actually meant something like preferring f x y to be written as f(x, y), it's not just a matter of taste. It's so the syntax makes sense with partial application. You can do

  f x y = ...
  g = f x
  h = g y

and it would be more confusing to write

  f(x, y) = ...
  g = f(x)
  h = g(y)

tome3• 7 years ago

$s implies Template Haskell

I think it's more likely to mean function application ...

tom_mellior9• 7 years ago

This is a good discussion of a problem that suits Haskell well, but it's unfair to Python in some respects.

For example: I haven't read or written a lot of Python in a while, but would Python programmers really want to implement mutation in such a class by copying dicts around? The hand-wringing about "oh no, I wrote the condition as not is_node" is silly since one could just define an is_leaf method that can be used without negation. And "changing heapToList to return a lazy sequence makes it no longer return a list, oh no!" is just as silly, since one would of course not do that but define a separate heapToSequence (and probably base heapToList on that).

Also: "pattern matching and algebraic data types which have massive, clear benefits and few (if any) downsides". They have downsides whenever your data is not tree-shaped. Yes, a lot of data is tree, but then a lot isn't. I work in compilers, which is often touted as a prime application of ML-family languages, and this is very true, but not 100%. If you can have sharing in your abstract syntax tree (like a goto node that might refer to a target node somewhere else in the tree), you start to have difficulties. And you get even more difficulties when you try to model control flow graphs and the like. Nothing insurmountable, but still things where it's suddenly good to have other tools than only algebraic datatypes. OCaml is good in this regard.

platz7• 7 years ago

You are free to use a Map in Haskell whenever it suits you. Nothing requires to to use ADTs when it would not make sense to do so.

tom_mellior9• 7 years ago

Sure, I said the issue was not insurmountable. But (and yes, I know Haskell programmers won't necessarily agree) there are contexts in which following a direct, mutable reference is superior to indirecting through a map.

contravariant3• 7 years ago

Wait, why do the leaves contain no data? What's the point of even adding them then?

With data in the leaves you could easily do something like:

    @dataclass
    def Node:
        data: "Any"

    @dataclass
    def Tree(Node):
        left:  Node
        right: Node

using the new dataclasses module. You could also add a type parameter to the above if you really wanted to.

The pattern matching will need to be done manually though, following python's philosophy of duck-typing.

Edit: An alternative involves abusing the pattern matching that python does have to write things like:

    data,*subnodes = myTree
    for node in subnodes:
       # etc

but whether that's really a good idea is debatable.

ggm2• 7 years ago

The leaves are intended to stand for more complex leaves the actual data type held in the tree is boring, only its properties of nodes and leaves matter. (I think)

tom_mellior9• 7 years ago

Wait, why do the leaves contain no data? What's the point of even adding them then?

You need something to represent a completely empty tree. You also need something to represent in a Tree node that "there is no child here". It makes sense to use the same thing for both. In Python and other languages with nullable references you can just use None (or null, or ...) for this. But ML-family languages have no nullable references. You could use option types instead, but that would look pretty complex, something like (my Haskell is rusty):

    data Tree a = Maybe (TreeStructure a)

    data TreeStructure a = TreeNode (Maybe (TreeStructure a)) (Maybe (TreeStructure a))

(You should be able to use Tree a in the definition of TreeNode, but I wanted to show the "real" structure, which you would also have to care about when pattern matching.)

It's easier to have an empty leaf instead. Personally I would possibly call it EmptyLeaf or maybe NoTree instead of just Leaf.

contravariant3• 7 years ago

At this point we're basically discussing what kind of tree you want. Including if you truly need an empty tree (which is maybe necessary if you want to do Monad like operations that don't return a result, but then doing so on a tree is pretty weird in the first place, and I'm not entirely sure what you'd do if a node in the middle of the tree returned Nothing, do you just throw away its children?). The best design will depend on what you need a tree for as well as in what language you will implement it.

But yeah if you want an empty tree I'd recommend just using None in python. You'll just need checks like 'if node' where you'd otherwise have pattern matching; you could improve QoL a little by defining an iterator over the existing children. If you really want a separate object then you run into all kinds of annoying stuff, including the fact that by default python will allocate separate objects for all of them, which is 1) slow and 2) bad for memory usage.

super_mario2• 7 years ago

A leaf is a node that has no children. So you don't need to represent it directly. Just check both children and if they are both None, it's a leaf.

Empty tree can be represented with root node that is a leaf and has no data.

functionalias• 7 years ago

Being a good person is a goal in itself.

In the same way, Haskell is a good language, it's a moral language. Of course this causes some pain, but it's worth it.

zimbatm• 7 years ago

One thing that makes programming difficult is how much context needs to be held in the live part of the brain. Past N items (let's say 4), the brain has to swap those values and it makes programming much much slower.

Most of the article is spent explaining this sideways; with Haskell you need to hold less aspects in the head because they are either eliminated entirely (purity) or can be deferred to the compiler (types), ... What we learn is that Haskell is easier to implement tree-like structures.

I think this is what most language proselytes are trying to convey in their articles. But don't talk about explicitly. Inevitably they will pick a task that is easy to achieve in the language because the developer environment aligns well for that use-case, and then let the reader infer that this applies to all programming tasks.

Basically we are trying to benchmark humans, without building a proper model of how humans work. The next evolution in programming will be done by properly understanding how we work and interact with the computer.

unixhero• 7 years ago

I wouldn't know. It was impossible to learn.

ur-whale3• 7 years ago

I wouldn't know. It was impossible to learn.

People shouldn't downvote you: the sarcasm bit is funny, and it does actually point out to one of the major reason Haskell is not gaining more acceptance in spite of its many great features:

     . the syntax is completely alien (to the point of turning quasi APL-ish in some cases) and scares away potential users.

     . the community is so focused on esoteric stuff that the "how do I do X that's super easy to do in traditional languages" is completely missing from the conversation.

jonsen2• 7 years ago

the syntax is completely alien (to the point of turning quasi APL-ish in some cases) and scares away potential users.

the community is so focused on esoteric stuff that the "how do I do X that's super easy to do in traditional languages" is completely missing from the conversation.

the_af17• 7 years ago

The syntax is not alien. Care to give an actual example that confused you?

TheSmoke• 7 years ago

offtopic: if anyone's interested -- Standard Chartered Poland is looking for Haskell hackers: https://twitter.com/MikolajKonarski/status/11782723158152192...

axilmar• 7 years ago

To play the devil's advocate here: no post speaks about any serious disadvantages of Haskell.

So, for a programming language that has so much to offer, why isn't it adopted more?

Could it be that it doesn't actually increase productivity to such a degree to justify the cost of change?

Legit question, I am not trying to be a troll.

reikonomusha• 7 years ago

I can’t say for Haskell, but I can say for Lisp, which similarly gets these “look how great” articles but also similarly doesn’t see a huge up-tick in usage.

Whether you’re a student fresh out of school, or you’ve been unemployed for 10 years as a sysadmin, or you’re an expert programmer already, Common Lisp is accessible to you. Those examples are real; they’re backgrounds of folks I either used to or currently work with. Being paid helps immensely.

So it’s not that the language is unlearnable, unreadable, or out-of-reach. (The pot-shots that random commenters in forums like these take on the language are usually shallow or even outright wrong.) In some cases, it’s even demonstrated to be asymptotically more productive.

So what’s the deal? I personally think it’s just that productivity isn’t in and of itself incentivizing enough. You know Python and C++, you’re relatively proficient at them, you know how to get the job done with them, why learn something new? Haskell/Lisp won’t get you a job (necessarily), it won’t allow you to do something with a computer that you fundamentally couldn’t do before, and it’ll suck up a lot of your time to figure out what’s going on with them. Moreover, there’s no big organization behind it (like Mozilla or Facebook or Microsoft or ...) so where’s the credibility? A bunch of researchers at some university? A bunch of open-source hackers?

I think one has to be personally invested in becoming a broadly more knowledgeable and more skilled programmer, just for the sake of it, and (IME) most people aren’t like that. I think one has to also have a penchant for finding simpler or more fundamental ways of solving problems, and that has to turn into an exploratory drive. Even if one is like that, learning Haskell is one of a hundred possible paths to improve oneself.

My comment shouldn’t be misconstrued as supporting a mindset of it being OK to just know a couple languages well. I think the hallmark of an excellent programmer is precisely this broad knowledge of not just tools, but ways of thinking, in order to solve the gnarly problems that come up in software.

agentultra3• 7 years ago

So, for a programming language that has so much to offer, why isn't it adopted more?

In my experience it's usually some combination of FUD echoed throughout these comments such as:

Haskell is an academic language and cannot be understood be mere mortals

Well everyone is mortal and some people have learned Haskell so this is obviously hyperbole and meaningless. Is it difficult to understand? Yes... but I have a theory that this is largely because we aren't taught to think in the way Haskell asks us to. Most of us in industry invariably learn Haskell as a second or third language and by then certain patterns and expectations are present in our brains that we hold as truths.

The tragedy of this argument is that people think you have to understand everything in Haskell in order to get started. They point to more advanced features like lenses and profunctor optics and all of this jargon as proof. However I don't ever recall having to learn the entirety of template metaprogramming to get started in C++.

There's really a pyramid of features and the amount of Haskell you need to know to get started is small.

It is too hard to hire Haskell programmers

It's as hard as you make it out to be. There are plenty of people out there who would love to program in Haskell for their day job. When I started posting jobs for Haskell programmers my queue was full, constantly.

The problem is that unless your organization is fully invested in Haskell people in your organization will find ways to hijack this process in order to make it come true by moving the goal posts. It might be hard to find Haskell programmers in your area so they'll say you can't hire remote developers. Say you'll train people up into Haskell and they'll say we don't have anyone experienced enough, or not enough time, etc, etc.

It's not hard to hire programmers. It's hard dealing with people who don't want Haskell to be adopted in your org.

The documentation is poor, there aren't enough libraries, etc

This may have been true more than ten years ago but it no longer holds. The documentation is phenomenal. It seems rough if you're not used to reading type signatures. However once you are familiar with rudimentary levels of Haskell this disappears fast. Haskell is documented. Whenever you add a top-level signature you're adding documentation that not only enriches the program but documentation that cannot be wrong, go out of date, etc.

I think this one gets bandied around a lot by developers from big ecosystems that have deep corporate pockets to fund the development of frameworks, libraries, and tooling. Haskell has been getting more of that but it's still nothing compared to Java/.NET/Swift, etc.

Regardless there are libraries for every common task and ones that can do things with Haskell's type system that you simply cannot in other languages (or can only emulate, poorly, with possibly buggy run-time code introspections, templates, macros, etc).

The real world is messy and Haskell's type system just gets in the way

The real world is messy so why would you want to use a tool that makes incorrect programs permissible?

This comes up from folks who like how easy it is to get started with dynamic languages which are permissive about their inputs. I like this property of dynamic languages too.

What I don't like is all of the run time inspection I have to do in order to know what data is safe to use. At first this doesn't seem like a problem with unit tests and a tight feedback loop. However at larger scales in a code base it makes refactoring and reasoning about high-level patterns much harder. And despite the claim that "type errors are rarely ever the source of production issues anyway," I still find TypeError: undefined is not a function in logs more often than they'd like to think.

The point of all this is that we ship this code confident that we probably nailed ~85% of the problem and we tolerate the risk that there will be some number of errors that will be reported after the fact. Ship early and ship often. However in practice this sucks up a lot of time as a project matures.

I rather like the experience of not having to chase down where an errant null check as missed or where some code mistakenly mutated a shallow copy. I don't even have to think about that in Haskell. I can focus on the business domain logic.

AnimalMuppet2• 7 years ago

Three answers:

First, it doesn't fit everywhere. The best advice I received is that FP fits best when you can think about your program as a pipe - data comes in, data goes out. The more your program doesn't look like that, the less well FP fits.

Now, Haskell can do non-FP things, but you're fighting against the nature of the language to do so. It's probably better to pick a language that you don't have to fight in order to write your program.

Second (though I'm not sure that this is actually a reason that people pay attention to): Compile time. How long does Haskell take to compile a multi-million-line code base? How long does Go take? (Yes, I know that Haskell may take fewer lines. It won't be enough fewer to make the compile time shorter, though, nor anywhere close.) If you've got a multi-million-line code base, you've probably got a reasonably large team, and you've probably had them for years. If they each compile, say, five times per day, and there are twenty of them, and they've been doing it for ten years, the time spent in compiling adds up to real serious money lost.

Third: For a large team, they won't all be A students. Half the programmers will be below average. I'm not sure that Haskell is a great language for them. I wonder if they can't do more damage with Haskell than they could with, say, Go. (Of course, they could do a lot of damage with C++, too...)

oisdk10• 7 years ago

Well, adoption rates of programming languages has almost nothing to do with the features and qualities of the language itself. Swift is big because it's backed by Apple, Go is big because it's backed by Google, Javascript because it's on the web, etc. Python might actually be the only language that succeeded "on its merits" to some extent, and even then it seems more to do with some early success and libraries than the core nature of the language itself.

As the author of the post, I don't actually think I can make a compelling argument for why someone should switch to using Haskell in their day job. I don't have real experience in the software engineering industry, and from what little I do know language choice doesn't make a huge difference.

That said, I think it's valid to say that a given pattern is bad, or another pattern is better. I was trying to argue for that in the post in a couple cases that I think Haskell does well.

tu7001• 7 years ago

I think we can code ADT in Python: https://github.com/lion137/Functional---Python/blob/master/t...

lidHanteyk4• 7 years ago

Python may be terrible, but this poster doesn't know Python at all. Here's how to fix the first snippet:

    leaf = object()

Huh, that's funny, it's shorter than the Haskell? Why is that? Let's keep going.

    def merge(lhs, rhs):
        if lhs is leaf: return rhs
        if rhs is leaf: return lhs
        if lhs[0] <= rhs[0]: return lhs[0], merge(rhs, lhs[2]), lhs[1]
        return rhs[0], merge(lhs, rhs[2]), rhs[1]

Ugh. My mouth tastes funny. Livecoding on this site is always disorienting. I need to sit down for a bit. Exercise for the reader: Continue on in this style and figure out whether the Haskell really deserves its reputation for terseness and directness.

Edit: I kept reading and was immediately sick. __dict__ abuse is a real problem in our society, folks. It's not okay.

    def insert(tree, elt): return merge(tree, (elt, leaf, leaf))

The Haskell memes are growing stronger as I delve deeper into this jungle. The pop-minimum function here is a true abomination, breaking all SOLID principles at once. I can only imagine what it might look like in a less eldritch setting:

    def popMin(tree):
        if tree is leaf: raise IndexError("popMin from leaf")
        return tree[0], merge(tree[1], tree[2])

We continue to clean up the monstrous camp.

    def listToHeap(elts):
        rv = leaf
        for elt in elts:
            rv = insert(rv, elt)
        return rv

The monster...they knew! They could have done something better and chose not to. They left notes suggesting an alternative implementation:

    def listToHeap(elts): return reduce(insert, elts, leaf)

Similarly, if we look before we leap:

    def heapToList(tree):
        rv = []
        while tree is not leaf:
            datum, tree = popMin(tree)
            rv.append(datum)
        return rv

And again, the monster left plans, using one of the forbidden tools. We will shun the forbidden tools even here and now. We will instead remind folks that Hypothesis [0] is a thing.

Haskell's an alright language. Python's an alright language. They're about the same age. If one is going to write good Haskell, one might as well write good Python, too.

[0] https://hypothesis.works/

newen2• 7 years ago

So `tree` is either a `tuple` or an `object`? Seems pretty terrible in terms of typing.

lidHanteyk4• 7 years ago

The original was not better. More importantly, recall that Haskell's type system is unsound, so it's not like you can trust your Haskell code either. Just because it type-checks does not mean that it works. In either language, you'll want to write some tests. I mentioned Hypothesis for Python; for Haskell, there's also QuickCheck.

olooney• 7 years ago

I agree with your criticisms, the Python version presented in the article is rather baroque. In particular, the use __dict__ seems to have little justification and serves only to "uglify" the Python.

Here's my version of skew heap in Python 3, edited down to just the essential operations. (Link to slightly fuller version: https://gist.github.com/olooney/97643d07d69d22015ae5bb70c121...). It seems about as clean as the Haskell version presented, mainly because I used None to represent leaves (which is quite Pythonic.) Relative to the code presented in the article, it also benefits from a clear partition of trees of immutable nodes on the one hand, and a class to represent the mutable heap interface on the other.

    from typing import NamedTuple, Any, Optional

    class Node(NamedTuple):
        """A single Node in a binary tree."""
        value: Any
        left: Node
        right: Node

    def merge(p: Optional[Node], q: Optional[Node]) -> Node:
        """
        Implements the critical "merge" operation which is
        used by all operations on a SkewHeap. The merge operation
        does not mutate either tree but returns a new tree which
        contains the least item at the root and is in heap order.
        The resulting tree is not necessarily balanced.
        """
        if p is None: return q
        if q is None: return p

        if q.value < p.value:
            p, q = q, p

        return Node(p.value, merge(p.right, q), p.left)


    class SkewHeap:
        """
        A SkewHeap is a heap data structure which uses an unbalanced binary tree to
        store items. Although no attempt is made to balance the tree, it can be
        shown to have amortized O(log n) time complexity for all operations under
        the assumption that the items inserted are in random order.
        """   
        def __init__(self, items=tuple()):
            """
            SkewHeap() -> new, empty, skew heap.
            SkewHeap(iterable) -> new skew heap initialized from the iterable.
            """
            self.root = None
            for item in items:
                self.push(item)

        def push(self, value: Any):
            """Add an item to this heap."""
            node = Node(value, None, None)
            self.root = merge(self.root, node)

        def pop(self):
            """Remove the least item in this heap and return it."""
            if self.root is None:
                raise ValueError("Cannot pop empty SkewHeap")
            else:
                value = self.root.value
                self.root = merge(self.root.left, self.root.right)
                return value

        def union(self, other: 'SkewHeap') -> 'SkewHeap':
            """Return a new heap which contains all the items of this and another heap combined."""
            ret = SkewHeap()
            ret.root = merge(self.root, other.root)
            return ret

        def __bool__(self) -> bool:
            """Return true iff the heap is non-empty."""
            return self.root is not None

    def test():
        h1 = SkewHeap()
        for item in [42, 13, 50, 11, 14, 50, 91, 72, 91]:
            h1.push(item)
        h2 = SkewHeap([63, 15, 1, 22, 91, 11, 92, 99, 93])
        h = h1.union(h2)

        while h:
            print(h.pop())

Maybe someday I'll read an article comparing two languages where the author's greater familiarity with one language over the other isn't the dominating factor, but it won't be this day.

oisdk10• 7 years ago

I really wasn't trying to compare Python to Haskell, rather I was trying to show a few example features in Haskell with the Python code as a reference for the "standard" way to do a binary tree type thing. Other than the (admittedly awful) `__dict__` stuff, the rest of it is pretty standard. In contrast, the code you've written here is non-mutating, and uses tuples to represent a tree. If you were to google, say, "BST in Python" I'd wager almost none of the implementations would follow that style. If I was to write a skew heap in Python (that I intended to use), I would likely do it in a non-mutating way (although I certainly wouldn't use tuples and `leaf = object()`).

The point of the post was really to argue that simple features like pattern matching, ADTs, and so on, should be in languages like Python and Go. Also I wanted to make the point that functional non-mutating APIs could be simple and tend to compose well: the `unfoldr` example was all about that. In that vein, it was important that I compare the Haskell code to an imperative version.

For instance, with your `reduce` improvement: I agree that the `reduce` version is better! It's simpler, cleaner, and easier to read. But Python these days is moving away from that sort of thing: `reduce` has been removed from the top-level available functions, and you're discouraged from using it as much as possible. The point I was making is that I think that move is a bad one.

Finally, while the Python code here is shorter, you still don't get any of the benefits of pattern-matching and ADTs.

* You can only deal with 2 cases cleanly (what if you wanted a separate case for the singleton tree?).

* You are not prevented from accessing unavailable fields.

* You don't get any exhaustiveness checking.

lidHanteyk4• 7 years ago

Python has some basic pattern matching. ADTs are alright, but if you notice that MLs implement them by tagged unions, then really this is a request for syntax and ergonomics, not semantics.

Python is untyped. This fundamental separation between Python and Haskell is non-trivial, and can't be papered over. Your complaints about exhaustiveness, field existence, and case analysis are all ultimately about the fact that Python's type system is open for modification, while Haskell's is closed; in Haskell, we can put our foot down and insist that whatever we see is an instance of something that we've heard of, but in Python, this is simply not possible.

I agree, when it comes to Python's moves. I am about ready to leave Python 2, but I'm not going to Python 3.

Scarbutt2• 7 years ago

Your recursive merge function will blow the stack for large inputs and it will be slow.

whateveracct2• 7 years ago

I've worked at multiple Haskell shops. They've all had problems. None of the problems were actually attributable to Haskell..but Haskell was an easy target for blame by management. I'd say that's Haskell's biggest problem in a professional setting.

I know Haskell and Go about equally. Meaning I know all the language features & common libs & have a grip on their runtimes. Go on day 1 was way easier to write and understand than Haskell on day 1. Now that I've normalized their learning curves, Go didn't get much easier to work with. Haskell did - I use my brain way less when writing Haskell than when writing Go.

But even then, Haskell or Go. It's all just the same stuff.

I've pretty much given up talking on the Internet to people about Haskell. Arguing against some of the pts in this thread about how Haskell isn't good for production.

I'll continue to write Haskell for pay for the foreseeable future. If I'm lucky, I'll do it the rest of my career. I don't see any reason why not.

proc0• 7 years ago

..but Haskell was an easy target for blame by management. I'd say that's Haskell's biggest problem in a professional setting.

I would say that's a software company's biggest problem instead. I really don't understand how someone with little or no coding experience can be in a leadership position with other programmers who are supposed to be problem solvers and have all the details of how to build something. The bigger the gap in knowledge, the more communication breaks down and the hierarchical structure becomes useless.

whateveracct2• 7 years ago

someone with little or no coding experience can be in a leadership position

I had one where the leader in question had coding experience but didn't know Haskell at all.

Despite this [1], they tried to read some code (that the Haskellers has no issues with) and couldn't, so he deemed the codebase unreadable and eventually called for a rewrite. Worse, during the debate about the rewrite, there was constant discussion about how the code was unreadable and bad, but it was never sourced to this leader. Instead it was asserted with weasel words only.

[1] Maybe it was because of this..this leader was driven by confidence in their experience and seniority.

bojo2• 7 years ago

This comment pretty much sums up my own experience, including learning Go, then Haskell, and the final takeaway - have pretty much given up talking on the internet about Haskell.

chowells2• 7 years ago

I have to disagree with the thesis here in its entirety. ADTs and pattern matching are not what makes Haskell good. Every article like this one just serves to show people the non-compelling bits of Haskell. The parts you can use in every other language, if you want to.

The parts of Haskell that make it a good language aren't the things that you can just write a tutorial for. They're about software engineering, not code snippets.

Purity and immutability remove entire classes of bugs caused by spooky action at a distance. When you assert this, people claim "I don't have those bugs", forgetting about the time someone else changed a function they wrote to mutate one of its arguments, breaking code three steps up the call chain.

Parametric polymorphism documents what information a function cannot use within its definition. If you point this out, people ask what good that serves. There's no way to explain how much easier it is to get things done when you can write a function and know that no matter what values are passed in, there cannot be special cases that trip you up.

I see people try to explain why the `Maybe` type is better than null values, and have their explanations rejected with "You still have to check for it. All you're doing is changing the syntax of the check." I've seen variations on that theme in maybe 10 different HN threads over the last 6 years. When all you talk about is ADTs and pattern matching, why would anyone ever look at the bigger impact of the type system? The relevant detail here is that an `Integer` can never be null, not that you use `Maybe Integer` to talk about potentially missing values.

Further in that same direction, I see people say that the `IO` type just complicated things because your program has to do I/O anyway, so it always needs to be in `IO`. This is exactly the same as the `Maybe` problem, but that similarity is even further from being addressed by articles about pattern matching and ADTs. No, the similarity isn't "monads". Anyone who talks about them here has missed the point entirely. The point is that parametric polymorphism completely prevents distinguishing IO values from non-IO values, so code that's not written to work with IO values cannot do IO accidentally.

There are a lot more cases, especially when you get into more sophisticated things possible in the type system using ghc extensions like generalized algebraic data types or higher-rank types.

But all of the reasons you should be using Haskell in reality come down to practical large-scale software design concerns. The language lacks features that make several common classes of bugs possible. It makes several other common classes of bugs take a lot more work to implement than the non-buggy way to solve the same problem. These aren't things you can just write a short article about. They're things that require years of experience and introspection to see are even problems, and a willingness to accept that a lot of the problem is the ecosystem, not an individual failure to execute. None of that fits in an article.

I think articles about how great pattern matching and ADTs are make the language look worse, because anyone with some experience can say look at what's actually happening and say "I can do that in <other-language>, Haskell clearly doesn't have anything to offer." In other words - stop writing these articles. They drive people away from Haskell, not encourage them to look at the good parts.

eli_gottlieb2• 7 years ago

Honestly, I think it's worth bragging about just how much code re-use and modularity one can get out of combining parametric polymorphism with ad-hoc polymorphism (type-classes).

chowells2• 7 years ago

I agree with that. Foldable and Traversable are complete marvels of usability.

cannabis_sam• 7 years ago

It’s hilarious to read all kinds of rationalizations for why haskell is not useful.

Servant + Aeson beats any api backend in any language, period. If you combine that with Elm on the frontend you’ve got a great onboarding path for new devs to learn enough haskell to work on the backend.

Of course, for production, ignore lenses, monad transformers, free monads, effect systems, etc. They’re awesome, but the complexity is not worth it in practice at this time.

acroback• 7 years ago

This article reminds of my coworker, touts Haskell all the time, ends up writing shitty Java code which is difficult to understand and performs like molasses.

Real world is not perfect, it is immutable with plenty of side effects. Using Haskell for day to day messy work is not trivial and should not be considered IMO, u nless you have Haskell gurus all around.

I would rather take a dumb language like Go or Java over Haskell for work code.

mbo4• 7 years ago

Real world is not perfect, it is immutable with plenty of side effect

Perhaps we should use a language that is immutable and can reason about side-effects. Like Haskell?

haolez2• 7 years ago

Haskell seems cool, but if I’m going to invest time in a different programming paradigm, I’m more curious about APL/K/J. They seem more useful as well (to me).

_bxg17• 7 years ago

Practically speaking what I've heard is that the value of learning Haskell isn't so that you can then go use Haskell, it's so that you can then go write code in other languages as if it were in Haskell

haolez2• 7 years ago

I think that’s unfair. Haskell is used in the real world to solve really hard issues, like anti-spam at Facebook.

I’m simply more impressed by array-oriented languages :)

patientplatypus2• 7 years ago

The problem with Haskell is that it's smarter than most developers. You can study really hard and maybe you'll be good at Haskell. And then you'll find that there are no common libraries for the things you want to do because all the other developers were writing them in Python.

Such is life.

MadWombat4• 7 years ago

This is about as far as I got with this...

"While it solves the problem of methods, and the mutation problem, it has a serious bug. We can’t have None as an element in the tree!"

Uhm... what?! Why not? You check that your left and right are None and if they are it is a leaf. And if they are not it is not. What your data value is doesn't matter and you can have as many None values in the tree as you like. Your tree doesn't need leaves to define where it ends, it ends when there are no more branches.

oisdk10• 7 years ago

What about the singleton tree with just None in it? As in, what's the difference between `node(None, leaf(), leaf())` and `leaf()`?

Or the following:

             x
            / \
           /   \
          /     \
         y       None
        / \      / \
       /   \    /   \
    Leaf  Leaf Leaf Leaf

MadWombat4• 7 years ago

This

             x
            / \
           /   \
          /     \
         y       None
        / \      / \
       /   \    /   \
    Leaf  Leaf Leaf Leaf

Looks like this.

             x
            / \
           /   \
          /     \
         y       None

There is no reason to explicitly define leafs

ekimekim• 7 years ago

I think python was a poor comparison here. The claim "python doesn't have algebraic data types" doesn't really make sense. Algebraic data types let something be an X or a Y. In python, everything can be an X, or a Y, or a Z, or anything else. In the tree example, an ideomatic tree structure in python would just be a 3-tuple (left, right, value). There's no need to define anything.

Don't get me wrong, I'm all for algebraic data types and think every statically typed language should have them, but it's nonsensical to talk about them in the context of a dynamically typed language.

The author commented elsewhere on this page that the article was mostly a response to missing these features in golang - I think that would've been a much clearer comparison that showed what you were really missing.

zapzupnz• 7 years ago

For those who were wondering about seeing this in Swift. You probably weren't, and I'm aware I could've leaned a bit harder on things that were built-in, but I was basically trying to meet in the middle between representing the Haskell code as written in the interview and something vaguely Swifty.

https://gitlab.com/snippets/1900852

What Is Good About Haskell?

Related Stories