mbo

> If I knew you write code like this, I would feel compelled during code review to squeeze my brain to try to see whether there is some library function that does what you just did.

That's because the author didn't put a type hole before declaring arguments.

  zoop :: (a -> b -> b) -> b -> [a] -> b 
  zoop = _
  <interactive>:10:8: error:
    • Found hole: _ :: (a -> b -> b) -> b -> [a] -> b
      Where: ‘a’, ‘b’ are rigid type variables bound by
               the type signature for:
                 zoop :: forall a b. (a -> b -> b) -> b -> [a] -> b
               at <interactive>:9:1-38
    • In the expression: _
      In an equation for ‘zoop’: zoop = _
    • Relevant bindings include
        zoop :: (a -> b -> b) -> b -> [a] -> b
          (bound at <interactive>:10:1)
      Valid hole fits include
        zoop :: (a -> b -> b) -> b -> [a] -> b
          (bound at <interactive>:10:1)
        foldr :: forall (t :: * -> *) a b.
                 Foldable t =>
                 (a -> b -> b) -> b -> t a -> b
          with foldr @[] @a @b
          (imported from ‘Prelude’
           (and originally defined in ‘Data.Foldable’))

Here, GHC has figured out that, yes, `zoop` is in fact directly equivalent to `foldr`. And it'll do this with all other holes involved in the iterative type hole development process. So, you don't have to worry about whether there is some library function that does what the author did. GHC will do that for you.

It's improved in the last year or so. It's not perfect by any stretch of the imagination but I find that it's one of the better supported languages out there, second to of course Java/Kotlin/TypeScript/C#.

Yes

Walder's Law states that:

      In any language design, the total time spent discussing
      a feature in this list is proportional to two raised to
      the power of its position.
           0. Semantics
           1. Syntax
           2. Lexical syntax
           3. Lexical syntax of comments

In future, I would suggest not nitpicking the most trivial, irrelevant detail of a language's design. Please consider the level of effort it has taken to create this language.

A communications channel controlled by the workers and not the managerial structure? This is a truly tragic development.

It's almost like they could have used some sort of specialised tree data structure where each tree node was assigned to some spatial region on the map, where successive levels were assigned to increasingly smaller regions.

It's related. Atlassian runs on AWS.

Okay, I got really confused by this whole mandatory thing. I never said FP should be mandatory at scale. I said it had a moderate benefit at scale. You respond with "well actually, it's not mandatory at Google-scale" so I assumed that you were trying to refute the fact that FP has benefit at scale.

You also followed this up with

> The kind of problems that emerge at scale are not the kind of problems FP tackles.

I cherry picked these examples to demonstrate that you're completely talking out of your ass here.

> I didn’t say it is impossible to do X with FP - I said it is not necessary to do X in FP. You can convince yourself of that by looking for larger-scale non-FP counter-examples to the ones you've cherry-picked.

I never said it wasn't possible to tackle these problems without FP.

You need to get rid or the assumption that "if X is better than Y at task Z, everyone will use X rather than Y for task Z". You've used that line of logic to attempt to invalidate FP's capabilities. It simply does not make sense.

Okay, so given this answer here's what I would do:

1) I wouldn't make it the entry level course. It's clearly a paradigm that's used by a minority of people, so it doesn't make sense to start educating students with it.

2) I mandate that all students take it, maybe in their 3rd year. We're going to mandate it because there are tangible benefits (which we've assumed for the sake of this argument). They're going to find it harder and more confusing because its's different to what they're used to. A lot of them may not like it and won't see immediate benefits. Some may even come to dislike it. Frankly, I don't care, some will pick it up and learn about it further. And when the students that disliked it inevitably run it into the future, they sufficiently prepared to deal with it.

We're back to square 1: forcing it down student's throats. If you still think that we shouldn't be forcing students to learn FP in schools, I think you have a problem not with FP but with structured curriculums.

Sorry, I mean scale as in "large scale projects".

Spark is the quintessential Google-scale FP project - it was even born out of the MapReduce paper by Google!

And there's plenty of other large-scale projects that are arguably in an FP style specifically to deal with the problems associated with scaling them: the Agda/Isabelle proof checkers, the seL4 kernel, the Chisel/FIIRTL project, Erlang/OTP, the Facebook Anti-Spam system (built on Haxl), Jane Street's massive investment into OCaml, Twitter's investment into Scala.

Not all scale problems are distributed problems. Some distributed problems are tackled by FP, and some aren't. Ultimately, these large-scale projects pop up at similar rates to the usage of the language themselves. It's intellectually dishonest to say that FP can't be used to tackle large scale problems, and the problems that occur at scale, because its repeatedly validated that it can.

Okay, so FP is more difficult to learn. Assume for the sake of this argument that FP has a tangible benefit over other paradigms, that manifest themselves at scale. You're tasked with educating students in this paradigm, but they complain that it is more difficult than the techniques that they are used to.

What do you do?

New members of our team are greeted with a "Hi, my name is mbo. Here's your desk, here's your copy of The Red Book, good luck."

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

> Why can't FP's benefits be obvious so that it doesn't require evangelists?

Because there aren't immediate benefits. They only pop out at scale and with complexity, as I said.

> similar real world massive productivity improvement to Imperative Programming

Because there isn't. It's a reasonable benefit, but it's not transformative. I think it's there, enough to commit to FP completely, but the massive productivity improvement doesn't exist, or at least, only exists in specific cases, e.g. the WhatsApp + Erlang + 50 engineers parable (you could argue that this is due to the actor model and BEAM, rather than FP. An argument for a different day).

I feel like this hard + reasonable benefit isn't really efficient utilisation of people's time, especially when there's things like Deep Learning floating around. I think the immediate reaction to a lot of what FP evangelists claim is a shrug and a "I guess, but why bother?"

The issues is that you get benefits for sticking to one paradigm, because then everything is made of the same stuff.

If everything is an object, then you can use all your tooling that works with objects, which is everything. If everything is pure, you get easy parallelism. If everything is an actor, you get easy distributability. If everything is a monad or function, you get easy compositionality. The list goes on. Smalltalk, Erlang and Haskell are languages with very dedicated fan bases, which I theorise is because they went all in on their chosen paradigm.

The sad part is that this is a common experience - universities have done a bad job at teaching FP. I think there are good pieces of FP education, particularly Learn You a Haskell and https://github.com/data61/fp-course - friends have gone through these have questioned "why wasn't I taught like this the first time around".

> I've never touched any FP since, unless you count borrowing clever lambda snippets.

I'd urge you to give it another shot if you have spare time. Even in spite of all the dogshit things associated with it, it's a paradigm I've bet my career on.

> Why does functional programming need to be taught in schools but all the other various programming topics did not?

Because I think it is harder for people who have programmed with other paradigms - following an inverse law, most things should get easier to learn with experience, not harder. It's foreign, it's weird, it's back to front. It doesn't have an immediately obvious benefit to what people are used to, and the benefits it has come at scale and up against the wall of complexity (in my opinion). It's hard to adopt upfront. At the small scale it's often painful to use. The syntax is weird. It's aggressively polymorphic, reasoning in abstractions rather than concretions. I could go on (and yet I still adore it).

The only reason FP has been successful as it is, is because its evangelists are incredibly vocal, to the point of being fucking annoying sometimes. It's had to be forced down people's throats at times, and frankly, there's no better place to force a paradigm down someone's throats than at a university, where non-compliance comes at academic penalty, and when the mind is most impressionable.

EDIT: I wrote this comment before watching the video. I stand by this comment, but the video is very good and I wholeheartedly agree with its conclusions.

As someone who writes pure FP for a living at a rather large and well known org, these threads physically hurt me. They're consistently full of bad takes from people who don't like FP, or haven't written a lick of it. Subsequently, you get judgements that are chock full of misconceptions of what FP actually is, and the pros and cons outsiders believe about FP are completely different from its practitioners. It's always some whinge about FP not mapping "to the metal", which is comical given say, Rust's derivation from what is quite functional stock.

My personal belief? We just don't teach it. Unis these days start with Python, so a lot of student's first exposure to programming is a multi-paradigm language that can't really support the higher forms of FP techniques. Sure, there may be a course that covers Haskell or a Lisp, but the majority of the teaching is conducted in C, C++, Java or Python. Grads come out with a 4 year headstart on a non-FP paradigm, why would orgs use languages and techniques that they're going to have to train new grads with from scratch?

And training people in FP is bloody time consuming. I've recorded up to 5 hours of lecture content for devs internally teaching functional Scala, which took quadruple the time to write and revise, plus the many hours in 1-on-1 contact teaching Scala and Haskell. Not a lot of people have dealt with these concepts before, and you really have to start from scratch.

Functional programming at Atlassian: https://youtu.be/HSQ9ET0bOYg

Note that not everyone FP lang is verb-noun. Sure, most are, but your F#/Elixir/Scala's are more often than not written in a noun-verb form with the `|>` operator or something vaguely equivalent (syntax extensions in Scala's case).

When are higher-kinded types roadmapped for Java?

You know, I really agree with a lot of this. It's maybe not an unreasonable argument to make that maybe OO-heavy or Akka-ish Scala might be a better investment for a lot of people, considering the weight and momentum of the communities maintaining these, and these expressiveness of the language in these domains.

But I think if we're only talking about pure FP, or at least something close to very pure, I think you're still getting a better deal than Haskell, even in spite of all those quite legitimate downsides you mentioned. My own personal biases mean that I will always prefer pure FP to anything else (I personally didn't love Akka and Play when I used them briefly), but that's an argument for another day.

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.

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

If you're injecting your settings at the root of your reader monad (which almost all Haskell applications are structured around), how many function calls are you between your monad stack and where you need to thread settings to? 3? Maybe 4? This isn't an issue in practise. It's a 4 line diff.

Source: 3 years of pure FP Scala in prod

I replied with this elsewhere in the thread, but maybe Dhall? https://dhall-lang.org/

Functional? Check. Type annotations? Check. Not Turing complete? Check. Compiles to multiple config formats? Check.

https://dhall-lang.org/ too

Perhaps something like the discussion that takes place on Letterboxd or Rateyourmusic?

If you like "functional and runs on the JVM" you might like ScalaJS too. It's a mature transpiler, and the community has rallied to ensure that all the important libraries compile both to the JVM and to JS.

TypeScript does not have higher-kinded types. I'd link sources but it's difficult to prove the negative here. It just doesn't have any.

They've been in Scala for at least a decade (iirc), with few alterations. How long does it take for "experimental weird feature" to become "reasonable solution to a problem that should be copied". Another five years?