Hacker News Reader

Comment by endymi0n | Hacker News Reader

I know a business coach who regularly asks his audience "Who here makes better burgers than McDonalds?". When half the audience raises their hand, he asks them why they don't outsell this giant company.

Functional programming advocats, especially for the "pure" ones like Haskell, always strike me as odd. It seems that all the beauty of those languages make people obsess over that beauty and purity while keeping them from being productive.

Meanwhile, people with simpler languages like Go just get stuff done that is useful and makes people happy. Now if I _ever_ came across a useful Haskell product, I'd be happy to test drive it, shouldn't be a problem by now with all the container technology. But the closest I ever came to using a functionally developed product was RabbitMQ (written in Erlang). That one was _such_ a pain to use and operate — must have been the developers still dreaming in the purity of its code instead of writing some installation docs. I moved on to Kafka later and didn't regret it a minute.

Rant off.

View on HN

Selling a lot of burgers encompasses much more than making good burgers. By the same token, good products entails much more than making a programming language choice.

Functional programming, at its heart, is about using self-imposed constraints to avoid certain classes of programming mistakes.

If your application domain doesn't have big consequences for these classes of programming mistakes, then it can seem like functional purity can be a luxury or frivolous. However, if your application domain suffers greatly from those classes of programming mistakes, such as distributed systems, then it may be worth it to consider what functional programming might buy you.

So yes, just because you use a functional programming language won't help you sell your widgets or make a great product. And you can spend lots of time fucking around with it for its own sake and still not sell widgets or make a great product. However, if you understand what its constraints buys you, then you can make your job of building these things in certain domains much easier.

Now that's an excellent point, I agree. However, at its heart, Kubernetes does not even have that many distributed features. It's a rather classic master-slave architecture that shells out a lot of distributed primitives to etcd (which could be a much better candidate for the points you mentioned), but on the other hand, it's a mainly a system orchestration system that juggles an operating system, syscalls, SECCOMP, firewalls and related stuff — exactly the area where Golang shines and Haskell would have a rather hard time.

In this way, I rather like the tradeoff that the OP post shows: It's at least _possible_ to write Go code that's almost as defensive, safe and exhaustive as a safer language could provide, it's just a lot of manual work and discipline. For the small subset of code that needs these guarantees, it's possibly overall more consistent and efficient to take this route than splitting code into different languages with different strengths.

> So yes, just because you use a functional programming language won't help you sell your widgets or make a great product. And you can spend lots of time fucking around with it for its own sake and still not sell widgets or make a great product.

It comes down to trust. You're either fucking with your code in a powerful programming language that lets you do everything, or your fucking with the language restrictions to get your code to compile in the first place.

You can either go eat at McD's which sells pre-cooked burgers from minimum wage employees which kills the flavor and the taste of the meat being served but is extremely safe, or you can go to an upscale burger joint where artisans grind their meat in house and cook it to a perfect medium rare.

These days, I prefer the latter.

> It comes down to trust. You're either fucking with your code in a powerful programming language that lets you do everything, or your fucking with the language restrictions to get your code to compile in the first place.

> ...or your fucking with the language restrictions to get your code to compile in the first place

I think that's a wrong and outdated view on strong type systems.

A good type system is also an ergonomic one. What people start to experience is that the compiler is actually a friend that helps you write code and keep yourself true to your own promises. When new people start Elm, PureScript or Haskell (or another lang with ADTs and Type Inference), they might be a bit overwhelmed with the paradigm shift, if coming elsewhere, but if you are new to programming, there's nothing inherently more difficult in Haskell than in other languages—the cost of wrong code is just apparent earlier.

It doesn't come down to trust, it comes down to the realization that your mind can keep track of less information than a computer, and that you, as a programmer, are forgetful and make mistakes. The compiler is there to help you when you stumble over your own feet.

NOTE: I'm only including strongly, statically typed languages with type inference in the above. "FP langs" by itself is far too broad to be a useful categorization.

Even experiences FP folks complain about how difficult it is to program in Haskell due to its purity. Further, the high barrier to entry you describe is an even bigger deal to organizations than to individuals. It’s a cost that needs to be paid for every employee. And it’s not just the language features, but FP languages tend to have issues like poor documentation, poor editor integrations, multiple standard libraries, multiple build tools, multiple string types, home-grown project file syntax, multiple preludes, many extensions, etc. All of these boost the learning curve in addition to the issues with the language itself.

In my limited experience with functional programming, I've come away with the impression that the problems you're describing are why you don't see a lot of companies that use FP exclusively.

But I think the advantages that OP is lauding are also there, and "space shuttle code" might just be where it shines. Reading that comment in this post made me immediately think of Haskell. The Clojure components at my company fits the "space shuttle" description of importance, and its dependability is striking compared to the rest of our code. Part of it may be that being written in a different language allows its concerns to be separate from the rest of the application too, but I do think the FP paradigm is simply good in this domain.

Sure, but I doubt all of Kubernetes is written in this style, so it’s probably not worth writing everything in Haskell. Note also that there’s nothing about FP that prohibits it from addressing the aforementioned practical problems. Some Haskell-like could swoop in and totally steal Go’s lunch if they would simply prioritize practicality over experimentation.

> Some Haskell-like could swoop in and totally steal Go’s lunch if they would simply prioritize practicality over experimentation.

I don't know. It seems like it would be easy enough to build an AST to make sure there were no unknown conditions that didn't lead to a return statement.

I don’t understand how your post relates to mine. I was saying that if a static functional language focused more on simplicity, readability, good tooling and documentation, etc then it would eat Go’s lunch without trading off any of Haskell’s important characteristics (I.e., robust type safety).

> I think that's a wrong and outdated view on strong type systems.

I wasn't really talking about type systems specifically, I was thinking along the lines of the Rust borrow checker here, and lower level programming like assembly and C.

> A good type system is also an ergonomic one. What people start to experience is that the compiler is actually a friend that helps you write code and keep yourself true to your own promises.

I see a lot of people make the mistake that type safe code is bug free code. "It compiles, therefore ship it."

> It doesn't come down to trust, it comes down to the realization that your mind can keep track of less information than a computer, and that you, as a programmer, are forgetful and make mistakes. The compiler is there to help you when you stumble over your own feet.

You trust the compiler to find bugs. Awesome. Luck be to you. I trust unit tests more than the compiler. Mostly because I wrote them. The compiler, I didn't.

You don't write the compiler, of course, but you do write or rather design the types that your program uses. The typechecker ensures that they're consistent within the system of logic that they set up.

By your logic, it's not enough to have faith in unit tests because you wrote them; you must also write the test framework and runner.

I have also developed a strong preference for the latter. I was always on the fence until I got my hands on generative testing (quickcheck, etc).

Now I want the powerful language and I can just slam it with generated tests to get the same level of confidence as the guardrail languages (in practice definitely, although I understand this is not true in theory, so unspit your coffee Haskell people).

Oh right and this is currently Clojure, so a functional language that definitely does help me make a great product. Less time implementing correctly means more time for product refinement.

Writing good generative tests is extremely laborious, in general. It's hard to get an informative sample of the input space.

As a professional Haskell dev, it definitely makes me more productive even discounting the higher quality of the results. Everything the language does for me is something less I have to think about it. And reusable abstractions, surprise, reduces work later making things go faster still.

Hopefully sometime soon I can share an example of this.

Your language example, and the burger example seems flipped. I assume you prefer artisan burgers, which means you like no language restrictions.

Badly chosen restrictions are not good, we can all agree. But what do good restrictions look like? Back in the day, programmers prided themselves on being able to do their own memory management, and bristled at the idea of a compiler or the runtime doing it for them. Now, that's the exception, as most of the time, we don't think about memory management in most languages we program in.

As time marches on, we'll find more of these restrictions that we all eventually agree are good practices, and the next generation of programmers will take it as a given in programming.

As a look beyond functional programming restrictions, I encourage you to check out Peter Alvaro's talk on Distributed Systems. Here, he talks about how queries over distributed systems is really hard to reason about, because time is now relative--there's no central clock to measure time. However, if we restrict ourselves to a language whose queries cannot express negation, a lot of the hard stuff about distributed systems go away.

https://www.youtube.com/watch?v=R2Aa4PivG0g

Functional programming, at its heart, is about imposing a particular kind of constraints with the hope that it will have an impact on program quality. The evidence does not suggest that FP is successful at that goal. Its chosen constraints are likely the wrong ones. There are a few programming paradigms that are "about constraints," and perhaps one of them will end up making a big difference, but it appears FP is not the one.

Nearly all modern programming languages being created have adopted functional features.

Swift, rust, c#, reason

I really liked this explanation of functional programming, and why it might be useful in certain contexts.

> I know a business coach who regularly asks his audience "Who here makes better burgers than McDonalds?". When half the audience raises their hand, he asks them why they don't outsell this giant company.

There is indeed a lesson here, but which one do you think it is? It's certainly not that McDonald's makes better (or "simpler") hamburgers: once you taste good hamburgers you can never go back to McDonald's (and yes, I make better hamburgers too, even though mine won't win any prizes!). To me, the lesson is that there's more to success than product quality. The established brand matters, the scale at which you can sell a (possibly inferior) product matters, how low you can get away with paying your employees matters, how well you can survive PR disasters matters, etc.

If you had to make burgers, would you rather make cheap and mediocre ones, or would you rather enjoy making premium burgers? :)

> It's certainly not that McDonald's makes better (or "simpler") hamburgers

At the risk of derailing the thread, that would be the lesson I wish people would take away from that example.

Criticizing fast food like that is dumb signalling IMO; McDonald's!hamburger != homemade!hamburger. It's an entirely different product sharing the same name and some of the ingredients. It tastes different, and has a different form factor. People like this, even if many don't want to admit it to others (or themselves). When I go for a McD's hamburger instead of a foodtruck one, or when I say I prefer chain restaurant pizza over a home made one, it's because I want a different product. Treating the two as the same category is like treating tea and coffee as the same thing.

Plenty of places can get me a significantly better burger in under a minute. McDonald's is not high up inside its category.

Among my circle of friends it is. People either like it or not, and if they like let's say the BigMac they either want that or not, but wouldn't really substitute it with a Burger King Whopper or a KFC Grander. They usually like that too (more or less, depending on the individual), but that's then a conscious decision to okay, let's eat something different. Even if the burger is in the name.

The fries are great though. Sometimes I go there for the fries, and occasionally I get a burger on the side

You should visit Belgium.

This is what kills me: McDonald's doesn't even make good burgers for its price range and speed of service. Plenty of competitors where I live make equally mediocre burgers cheaper and faster. Of course, if you wanted to enjoy a good burger you wouldn't go to any of them, McD's included.

It's all about the brand, unfortunately.

>People like this, even if many don't want to admit it to others (or themselves)

People only like the cheapness and the convenience (and perhaps the no-surprise factor).

Everything else being the same (price and time to prepare), nobody would eat McDonalds vs a quality burger (except the kind of people who eat Hot Pockets for the taste, but that's a much smaller demographic than McDonalds buyers).

I disagree. I like the taste of McD!burger and I like the taste of foodtruck!burger. They are entirely different tastes; sometimes I want to experience the former, sometimes the latter.

No-surprise factor isn't that big of an issue if you're buying; restaurants tend to have consistent food quality & taste too.

Disagree. I’m not a hardcore foodie, but I enjoy the entire spectrum of food, from fast-food to food trucks to homemade to Michelin 3-star restaurants. And sometimes I want Taco Bell, or yes, even McDonalds.

Tons of the chefs who work at or own those Michelin starred restaurants would agree with you - they almost universally love to eat low tier, mass market fast food

The fact that there is a mass(ive) market for fast food is proof alone that people like it (enough to eat it and spend their money on it). I’m with any of the posters above who like fancy burgers as well as fast-food burgers.

Where McD’s really shines, though, is their breakfast offerings. And with that said, I think I will head there now for a quick breakfast (I live ~5 blocks from McDs).

I remember watching a TV program where they took some typical fast food (McDonalds, KFC, etc) and presented it on a plate in a way you would expect in a more expensive restaurant. Everybody who tasted it rated it higher than food from the the fast food chain.

It seems many or even most people can't tell the difference and the ambience and service is as important as the food.

Penn & Teller's "Bullshit" show did a similar experiment with "bottled" (actually, tap) water. It turns out most people rate tap water better if it's served in a bottle and told it comes from a natural spring.

It surprises me in the case of frozen patties like McDonald's though. A frozen patty looks nothing at all like an actual burger made from ground meat. It tastes differently as well, of course, but what matters is that it looks completely different!

> Meanwhile, people with simpler languages like Go just get stuff done that is useful and makes people happy.

Kubernetes' reputation is just the opposite: that far from being a simple and useful thing, it's an overengineered, overcomplicated solution to a self-inflicted problem (deploying a distributed monolith).

> But the closest I ever came to using a functionally developed product was RabbitMQ (written in Erlang). That one was _such_ a pain to use and operate — must have been the developers still dreaming in the purity of its code instead of writing some installation docs. I moved on to Kafka later and didn't regret it a minute.

Erm, Kakfa was developed in Scala, whose advocates far more of a reputation for purist pontification than Erlang developers do. Maybe all that beauty and purity is actually good for something?

Calling Scala "purist language" sounds riddiculous to me. It is a hybrid of object-oriented and functional styles, with tons of weird hacks like case classes for pattern matching, implicits, type inference that kind of works, but is not full Hindley-Milner, Java bindings that require weird conversions between Java and Scala collection types, _ as a wildcard in few different places. Scala is the opposite of purism. There's a reason why Odersky's "Programming in Scala" has over 800 pages - even listing all the hacks used in the language is not trivial.

Erlang is not at all a pure functional language, fyi. Functions definitely have three very important core side effects that are optional: message sending, message retrieving, and dying (raising an exception).

I would call the erlang system the "one white lie" category of purity on the FP purity scale. It is, by the way, a huge tradeoff that makes operating in EVM languages far easier than, say Haskell.

> deploying a distributed monolith

This is not what Kubernetes is for.

Take a step back and understand what you're criticising. You just look uninformed.

> Kubernetes' reputation is just the opposite: that far from being a simple and useful thing, it's an overengineered, overcomplicated solution to a self-inflicted problem (deploying a distributed monolith).

Thats why companies pay the buck to get 24/7 support. Because its that good!

The paucity of useful tools/libraries written in Haskell as compared to languages like Go are more due to the fact that there are far more people in the Go ecosystem than Haskell, rather than because Haskellers are too busy navel gazing.

This disparity in numbers is in turn is primarily because golang/Python/C is inherently much more approachable than Haskell because the average programmer has cut his/her teeth writing imperative code for a significant portion of their early programming career. The jump to functional way of thinking requires a certain leap of the mind, that most people don't want to take the trouble doing because they seem to be happy "getting things done" in golang or Python.

However, that is not to say that we shouldn't be striving for correctness in code that Haskell fosters, or the inherent simplicity that it forces on you because you are forced to separate your IO and effect-full code from the pure bits. These are things worth striving for. These are broad principles worth emulating even when you are coding in an imperative language.

To turn your McDonalds analogy around: sure, a McD will let you just get your food requirements out of the way quickly and cheaply (i.e. just "get stuff done"). But in the long run, it's bad for you.

Haskell is a healthy salad to an [insert favourite imperative language] burger.

The things that keep me from using Haskell aren’t the functional bits but the overall complexity of everything. There are apparently several build tools, preludes, compiler extensions, string types, etc and figuring out when to use which is a major pain. And to top it all off, there’s the tediousness of the syntax, the pervasive use of symbol identifiers, and the general preference for code-golf programming vs readable programming. And THEN there is the tedium of the functional purity.

I really, really want to use Haskell because it’s type system seems neat in general, but the type system doesn’t justify all of the tedium. Go definitely loses on type system, but it wins in many of these other areas and so the trade offs are just better.

I agree with the general sentiment of your post, but the idea that Kafka is somehow less painful to operate than Rabbit is ridiculous. I love Kafka, but I can't think of a more painful software to maintain in production.

In my experience, Kafka has been relatively painless. Sure, it needs zookeeper. But zk has turned out to be start it and forget it kind of infrastructure for us.

Util one day ZK fails in the most spectacular way and nobody knows the internals of it and you lose data. Just because is something fine for a time does not mean that it is reliable. Without telling us how many nodes you are running ZK/Kafka on this information is useless.

Others were not so lucky: https://issues.apache.org/jira/browse/ZOOKEEPER-801

I'm not claiming it's perfect. Our cluster of > 15 Kafka nodes and 3 node zk ensemble has had no major issues in over 4 years in production. That's something. And from the bug - "GC logging/tuning is clearly where I dropped the ball, just using the defaults;"

It will come for you, too, one day. We all float down here.

>But the closest I ever came to using a functionally developed product was RabbitMQ (written in Erlang). That one was _such_ a pain to use and operate — must have been the developers still dreaming in the purity of its code instead of writing some installation docs. I moved on to Kafka later and didn't regret it a minute.

Err, RabbitMQ is one of the easiest to setup and stabler queues/messaging systems. And I'm no user/fan of Erlang...

I found Kafka easier to set up. RabbitMQ is a bit finicky when it comes to config, monitoring, administration, but it's pretty okay, and works well enough if you really need AMQP semantics (selective ack of messages).

I agree with the spirit of what you're saying. Too often I've seen folks on HN dismiss languages because they didn't have features X or Y, usually with a condescending "maybe this language's creators should read some PL theory". I remember circa 2013 or 2014, it became impossible to read threads related to Go because the entire thread would always be "a Real Language(TM) needs Generics". Look at the success Go has seen in the last decade while doing the opposite of what HN thought was correct.

That said, there do exist useful products written in Haskell. For example, Facebook writes a lot of spam fighting code in Haskell. https://code.fb.com/security/fighting-spam-with-haskell/

The lack of "generics" (parametric polymorphism) in Go has certainly made the incidental complexity in Kubenetes much higher: https://medium.com/@arschles/go-experience-report-generics-i...

Go and Haskell are really at different ends of a spectrum. Haskell is a very high level language, which makes building and reasoning about very complex software much easier (at the expense of a learning curve and fine control of space usage).

Go is a low-level language with no learning curve and a very limited facility to abstract (by design it seems).

Personally I would have written something like Kubenetes in Haskell or OCaml, with perhaps the odd performance critical section in C or Rust.

Ocaml has a GIL. I've worked with people trying to build a distributed system in a language with a GIL and do not recommend it.

OCaml will lose the GIL when multicore lands in ... the next few years I guess :-)

It's part of the Blub Paradox[1]. If you don't know about better things, you won't miss them. But once you do know about more powerful things, it's hard to go back to living without them.

[1] http://paulgraham.com/avg.html

I wonder if it’s not the language that causes the products, but more that programmers that are drawn to functional languages are less likely to care about product.

That said, lots of things are functional: chunks of Facebook, Twitter, and Microsoft (and I assume Google) are written in OCaml, Haskell, Reason, and F#. Jet is built in F#. Jane Street famously uses OCaml, and Scala is becoming the standard language for hedge funds. Spark apps are usually written in Scala. Etc.

I use functional languages because I care about products. What makes you think otherwise?

> Now if I _ever_ came across a useful Haskell product

There's at least git-annex and pandoc

Shellcheck[0] is the Haskell program I use the most.

[0]: https://github.com/koalaman/shellcheck

also postgrest

Erm, excuse me? Idiomatic Erlang is definitely not the purely functional, obsessed with correctness and types oasis of Haskell. And a the community that birthed Kafka (Scala) has much more in common with the Haskell community than the Erlang community.

Furthermore, why are you using the user interface as a yard-stick to judge language paradigms with?

Because I'm not in the business of making hamburgers nor am I interested in doing so.

Struggling to see this business coach's point. Is he saying that McDonalds makes better burgers than me because I'm not selling a million burgers a day? Because that's a load of crap.

He's saying that when it comes to serving customers, there are critical concerns besides how good the burger is.

E.g. Low cost, made quickly, scalable (easy to train workers from any culture, uses ingredients that can be sourced at scale across the globe, etc), consistency (burger is always up to standard regardless of time or place).

Serving customers is not a contest of who can make the best burger.

Still, his point is easy to turn around on him. Why is he "just" a business coach, selling his personal labor? Why trust what he has to say if he isn't CEO of the world's largest MNC for business coaching services? It's easy to take it ad absurdum as well: if any pundit or political scientist thinks they have better ideas than Trump, why aren't they the sitting leader of the free world?

OCaml is not Haskell, but it does provide almost all of the guarantees Haskell does. Here's a list of popular software you might have used written in OCaml:

- the Flow and Hack compilers

- Facebook's Messenger app

- Jane Street's entire trading infrastructure (and everything else they do)

- XenServer

- some parts of Docker, including the TCP/IP networking stack on OS X and Windows

Also Pandoc and git-annex are both written in Haskell.

They don't really make a 'product' but Jane Street uses Ocaml for all their development.

Rust was also bootstrapped from OCaml.

Seems like you have bad experiences with functional programming, but it's a little strange to rat on the advocates that are trying to figure out how to take potentially useful functional programming concepts and make them mainstream and/or explore alternative ways to quickly build robust systems.

Good examples of this translating to huge gains for the overall community are React + Redux.

I'm quick to admit that functional language ecosystems are not as mature, which might lead to lesser organizational productivity but no need to rat on functional programming in general.

A lot of things seem to get lumped into “functional” programming. The lexicon changes so I may just be behind the times, but ensuring every condition of branch logic is covered is not an aspect of functional programming as I understand it. And I may be wrong.

Without getting into what is and isn’t functional programming, exhaustive pattern matching is a very useful feature present in some functional languages.

All the better hamburgers cost more

Not true in the UK, McDo really ain't that cheap anymore (or perhaps I'm poorer than I think).

The better burgers made by large commercial chains are more expensive though.

That largely depends on supply and demand in the particular locality. Primary value of McD is that they are global enough that such effects are mostly averaged out and the core products are essentially same globally and the pricing is consistent at least on country level. One thing that recently surprised me is that KFC does not work in the same way and the menu is totally different across not only EU countries, but even franchise holders in same country.

The most useful product in Haskell for me personally is pandoc the universal document converter.

https://pandoc.org

While I ashamedly admit to having using pandoc myself already (it's been a while, but it wasn't even a bad experience), to me it still feels a little bit odd that this relatively obscure document converter is already the most famous product in a language I see hyped in every second HN thread.

odd or not, Haskell isn't really a mainstream language and pandoc deserves all the praise that it gets.

> It seems that all the beauty of those languages make people obsess over that beauty and purity while keeping them from being productive.

Much of theoretical physics is beautiful. Only when one takes it off the blackboard and into the real world does it turn ugly.

If you a proffesional chef, I would hope you are fammilar with other methods of producing burgerz than McDonalds, even if they don't sell as well.

Haskell is a highly opinionated reasearch language. This makes it a great languages to talk about. People could make many of the same points with, say Scala or Ocaml, but because those languages arent as opinionated, it is harder to use them as a basis for discussion than a language which is heavily opinionated about the subject in question.

With all due respect, I wouldn't consider Golang any less opinionated than Haskell, just into a completely different direction. Whether or not that's a good thing: I don't know.

There are better operating systems than Windows; there are also better languages than English. (I think that's a quote but can't find the source atm.)

FP advocates strike me the odd way that they trying to argue FP can reduce the intrinsic complexity of the problem itself, but they have no proof of it, or their 'proovies' are essentially faith.

This is not true at all.

This:

    #include<stdio.h>
    main()
    {
      int sum; int x; sum=0;
      for(x=1;x<=50;++x) 
      {
         sum = sum + x; 
      }
        printf(" 1+2+...+50=%d\n",sum);
      }

Is more cognitive load and error prone than this:

    (println (reduce + (range 1 50)))

This is mostly what experienced FP advocates tell you. Btw. you can transpile the latter to the former.

.. that said, Kafka is written in Scala.

Well parts of it yes but not 100%:

https://github.com/apache/kafka/tree/trunk/clients/src/main/...

Maybe it was. Currently Kafka codebase has twice the Java code than Scala. Over time I have seen Scala code keeps shrinking and Java code keeps rising in repo.

Reply on news.ycombinator.com