19 ms·

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

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.

progval 8y ago
> Now if I _ever_ came across a useful Haskell product There's at least git-annex and pandoc
- brlewis 8y ago
  also postgrest
- spudlyo 8y ago
  Shellcheck[0] is the Haskell program I use the most. [0]: https://github.com/koalaman/shellcheck https://github.com/koalaman/shellcheck
root_axis 8y ago
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.
- neeleshs 8y ago
  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.
  - gunnihinn 8y ago
    It will come for you, too, one day. We all float down here.
  - StreamBright 8y ago
    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 https://issues.apache.org/jira/browse/ZOOKEEPER-801
    - neeleshs 8y ago
      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;"
RcouF1uZ4gsC 8y ago
The most useful product in Haskell for me personally is pandoc the universal document converter. https://pandoc.org https://pandoc.org
- endymi0n 8y ago
  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.
  - type0 8y ago
    odd or not, Haskell isn't really a mainstream language and pandoc deserves all the praise that it gets.
sleepybrett 8y ago
.. that said, Kafka is written in Scala.
- deleted 8y ago
  [deleted]
- StreamBright 8y ago
  Well parts of it yes but not 100%: https://github.com/apache/kafka/tree/trunk/clients/src/main/java/org/apache/kafka https://github.com/apache/kafka/tree/trunk/clients/src/main/...
- geodel 8y ago
  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.
blueside 8y ago
All the better hamburgers cost more
- pbhjpbhj 8y ago
  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.
  - dfox 8y ago
    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.
SilasX 8y ago
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.)
nindalf 8y ago
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/ https://code.fb.com/security/fighting-spam-with-haskell/
- willtim 8y ago
  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-in-kubernetes-25da87430301 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.
  - jamougha 8y ago
    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.
    - yawaramin 8y ago
      OCaml will lose the GIL when multicore lands in ... the next few years I guess :-)
- dsirola 8y ago
  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 http://paulgraham.com/avg.html
the_af 8y ago
> 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? :)
- TeMPOraL 8y ago
  > 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.
  - coldtea 8y ago
    >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).
    - 8y ago
Tinyyy 8y ago
They don't really make a 'product' but Jane Street uses Ocaml for all their development.
- jashmatthews 8y ago
  Rust was also bootstrapped from OCaml.
iamwil 8y ago
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.
- endymi0n 8y ago
  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.
- bb88 8y ago
  > 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.
gizmo686 8y ago
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.
- endymi0n 8y ago
  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.
coldtea 8y ago
>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...
- pas 8y ago
  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).
bb88 8y ago
> 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.
lmm 8y ago
> 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?
- thdespou 8y ago
  > 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!
- mamon 8y ago
  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.
  - dnautics 8y ago
    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.
mbo 8y ago
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?
lewisf 8y ago
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.
- FPGAhacker 8y ago
  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.
  - tybit 8y ago
    Without getting into what is and isn’t functional programming, exhaustive pattern matching is a very useful feature present in some functional languages.
welly 8y ago
> 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. 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.
- jlawson 8y ago
  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.
  - sooheon 8y ago
    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?
karmasimida 8y ago
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.
- StreamBright 8y ago
  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.
hannofcart 8y ago
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.
- weberc2 8y ago
  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.
bcherny 8y ago
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.
- eklavya 8y ago
  I use functional languages because I care about products. What makes you think otherwise?
steinuil 8y ago
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
- garmaine 8y ago
  Also Pandoc and git-annex are both written in Haskell.

progval 8y ago

> Now if I _ever_ came across a useful Haskell product There's at least git-annex and pandoc

brlewis 8y ago
also postgrest
spudlyo 8y ago
Shellcheck[0] is the Haskell program I use the most. [0]: https://github.com/koalaman/shellcheck https://github.com/koalaman/shellcheck

root_axis 8y ago

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.

neeleshs 8y ago
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.
- gunnihinn 8y ago
  It will come for you, too, one day. We all float down here.
- StreamBright 8y ago
  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 https://issues.apache.org/jira/browse/ZOOKEEPER-801
  - neeleshs 8y ago
    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;"

RcouF1uZ4gsC 8y ago

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

endymi0n 8y ago
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.
- type0 8y ago
  odd or not, Haskell isn't really a mainstream language and pandoc deserves all the praise that it gets.

sleepybrett 8y ago

.. that said, Kafka is written in Scala.

deleted 8y ago
[deleted]
StreamBright 8y ago
Well parts of it yes but not 100%: https://github.com/apache/kafka/tree/trunk/clients/src/main/java/org/apache/kafka https://github.com/apache/kafka/tree/trunk/clients/src/main/...
geodel 8y ago
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.

blueside 8y ago

All the better hamburgers cost more

pbhjpbhj 8y ago
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.
- dfox 8y ago
  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.

SilasX 8y ago

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.)

nindalf 8y ago

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/ https://code.fb.com/security/fighting-spam-with-haskell/

willtim 8y ago
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-in-kubernetes-25da87430301 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.
- jamougha 8y ago
  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.
  - yawaramin 8y ago
    OCaml will lose the GIL when multicore lands in ... the next few years I guess :-)
dsirola 8y ago
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 http://paulgraham.com/avg.html

the_af 8y ago

> 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? :)

TeMPOraL 8y ago
> 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.
- coldtea 8y ago
  >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).
  - 8y ago

Tinyyy 8y ago

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

jashmatthews 8y ago
Rust was also bootstrapped from OCaml.

iamwil 8y ago

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.

endymi0n 8y ago
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.
bb88 8y ago
> 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.

gizmo686 8y ago

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.

endymi0n 8y ago
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.

coldtea 8y ago

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

pas 8y ago
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).

bb88 8y ago

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

lmm 8y ago

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

thdespou 8y ago
> 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!
mamon 8y ago
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.
- dnautics 8y ago
  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.

mbo 8y ago

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?

lewisf 8y ago

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.

FPGAhacker 8y ago
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.
- tybit 8y ago
  Without getting into what is and isn’t functional programming, exhaustive pattern matching is a very useful feature present in some functional languages.

welly 8y ago

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

jlawson 8y ago
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.
- sooheon 8y ago
  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?

karmasimida 8y ago

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.

StreamBright 8y ago
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.

hannofcart 8y ago

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.

weberc2 8y ago
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.

bcherny 8y ago

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.

eklavya 8y ago
I use functional languages because I care about products. What makes you think otherwise?

steinuil 8y ago

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

garmaine 8y ago
Also Pandoc and git-annex are both written in Haskell.