
Who cares about functional programming? - asp_net
https://thomasbandt.com/who-cares-about-functional-programming
======
aequitas
I consider FP to just be one of the tools in my programming toolbox. And apply
it where it will fit best. Because not every problem should be solved with FP,
nor with OOP for that matter.

Though it is sometimes educational to apply only a single solution to all
problems. Just to see how far you can stretch the usefulness of the tool.

A nice talk about where (and where not) to apply FP is this talk by Gary
Bernhardt:
[https://www.destroyallsoftware.com/talks/boundaries](https://www.destroyallsoftware.com/talks/boundaries)

~~~
seph-reed
So true. Generally, whichever one best matches the feeling best is how I go.

Some things really feel like objects, they've got little personalities,
friends, parents... a whole list of talents and characteristics. OOP it is.

Other things are more like physics. It doesn't really need to have a name to
exist, there doesn't need to be a container, it always acts predictably. Time
to get functional.

I've also been using a tactic which I have no idea what it's really called,
but I call it augmentation. I think of them like those crystals you add to
your weapons in diablo or other RPGs. The gist is: a public readonly member
which takes the object that holds it as an argument and has extra
functionality. So like:

``` class Staff { public readonly flamePower = new FlameAugment(this); } (new
Staff()).flamePower.doSomethingSpecialInvolvingStaff(); ```

~~~
duncan-donuts
Wouldn’t that just be a form of inversion of control? It feels a lot like
dependency injection, though maybe I’m misunderstanding from the example.

~~~
seph-reed
Definitely like a form of inversion of control. Wouldn't think to call it that
because the inversion is so shallow, and the control is always accessed from
the context of the typical controller. It doesn't feel like what I use IOC
for, though there is a similarity.

------
chowells
Functional programming alone is not very compelling. It's just a slightly
different way of organizing your code and data, with different tradeoffs in
terms of what code is easy and what code is hard.

If all you do is present examples of using higher-order functions and
algebraic data types, people will be pretty justified in saying "this doesn't
really change anything important." And that's because it doesn't!

Even in Haskell, once you learn the language, code is code. Sure, laziness
means learning new ways to think about composing code, but that's just a small
detail. In the end, the things that matter are same. Everything you know about
performance optimization still applies. The only difference is the look of the
code used to express it.

You replace for loops with higher-order iteration combinators! Woo! It doesn't
really change anything. You replace goto with recursion. Big deal! It's all
the same thing. (At least in a language with proper tail-call elimination.)

There is no giant breakthrough happening because there really isn't anything
to break through... At least as long as all you care about is "functional
programming".

There are languages where more interesting things are going on than just
functional programming, though. And those have actual promise for providing
real benefits. Haskell has a type system that provides real benefits in terms
of documentation and correctness. That is actually useful. But it's not
"functional programming."

So yeah. I don't care about functional programming. I care about things that
are actually improvements.

~~~
Risord
I don't either consider living without local mutable variables and loops as a
clear improvement. But I do think that designing your application such way
that it won't rely (or rely as little as possible) on spooky actions at a
distance is.

~~~
chowells
Sure, but that's a best practice in every language. Saying "this language
makes you do the thing you swear you're doing anyway" doesn't sound like a
practical difference.

The second-order effect of "everyone has to do what you're claiming you do" is
meaningful, yes. But it's really hard to convince programmers there's value
there. Look how many people still say C is a fine language, you just have to
not mess up. And not rely on any library that messes up. It's really tough to
market the thing everyone should be doing anyway as a feature, even when the
difference between "should do" and "is required to do" is huge in practice.

~~~
Risord
I like pragmatic definition of FP by Eric Normand: We recognize separation
between data, calculations (pure functions) and actions (impure stuff) while
using always simplest category.

To me it seems like especially juniors would get benefit from this
separations. So is it more like: "this language makes you do the thing that
experienced programmers do once a while and juniors avoid [purity] at all
costs". It would be interesting to see how juniors would work with
functional(-first) language. Would they be able to craft same not-even-god-
knows-what-it-does piece of art? What I have seen so far lot of side effects
is typically required.

------
hellofunk
I don’t see what the big deal is. I wrote clojure professionally for many
years, full-time. It’s just as easy to write spaghetti in that language as in
something more traditional.

~~~
JohnFen
Honestly, I've never seen a language or paradigm that you can't easily write
spaghetti in.

~~~
AnimalMuppet
Yeah. The trick is, can you write not-spaghetti in it?

~~~
JohnFen
Well, I've not seen a language/paradigm that makes in impossible to write good
code in, either.

While there are differences, of course, I honestly don't think the choice of
language makes the major difference in code quality. What makes the major
difference is skill, conscientiousness, and work processes.

~~~
timbit42
> Well, I've not seen a language/paradigm that makes in impossible to write
> good code in, either.

8-bit BASIC.

------
jaked89
FP tends to have a disregard for practicality, and performance especially.
Yes, it's elegant, by being abstract, but this abstraction comes at a cost.

After falling in love in it, I wrote a large project in F#, but eventually had
to ditch it and rewrite in C#. A simple analysis of any F#-generated IL will
reveal this.

~~~
thelazydogsback
F# code can certainly be written in C# style (no DU's, use nulls instead of
option types, mutables, etc.) and should not differ much from the C# IL. Seems
like doing this on the hot-path (or re-write a few fn's in C#) should be
enough -- why did you need to ditch re-write the whole project?

EDIT: Just saw your reply. I do agree about the IDE -- having ReSharper,
OzCode, etc., on my side is a great advantage on the C# side, even though I'm
an F# fan as well.

Also at this point C# is a fine FP programming language itself. (Can 8.0
finally pattern-match tuples sanely?) The only thing missing are DU/sum-types.

~~~
platz
unfortunately C# pattern matching is really only a glorified switch with
destructuring that doesn't provide any level of exhaustiveness checking that
is very helpful in maintaining code under conditions of change.

~~~
thelazydogsback
Agreed. Even w/o DU's/sum-types/case-classes, there could be a compiler option
when matching an instance against a lists of sub-classes that a warning/error
is generated if the list of sub-classes does not fully cover the parent class.
(It should be fairly easy to write a Rosyln-based plug-in that enforces this.)
Typescript allows you to express this kind of thing pretty well -- maybe some
of that work will end up migrating to C#. F# used to be the C# feature
playground, but that's probably changing now. Not sure if TypeProviders will
ever make it...

~~~
platz
TP's I don't think have quite borne out the usefullness-to-complexity ratio

~~~
thelazydogsback
Agreed, but anything is better than some 3rd-party tool (that may or may not
be integrated into the build) doing one-off ad-hoc code generation. I think
any C# meta-programming facility would be a good step. Certainly the TP
interface(s) could be simplified for C#.

~~~
platz
well there are T4 templates for C# code-gen, although I can't say I've ever
been eager to use them.

------
NotATroll
I dare say the reason many people are hesitant to adopt Functional programming
is that:

A) They aren't, they're probably already programming in a functional
programming style. Just not in a _purely_ FP language (Which I would never
adopt to begin with)

B) A lot of FP articles come off as the musings of zealots obsessed with
monads, which often barely make any sense to, well, anyone. The less sense it
makes at first glance, almost guarantees people will want to avoid it. Yes,
maybe _I_ can understand it. But I'm (hopefully) not the only maintainer of
the codebase, and trying to communicate some FP concepts back & how to use
them really, really isn't easy.

~~~
Twisol
> A) They aren't, they're probably already programming in a functional
> programming style.

This hasn't really been my experience. OOP in particular has a very specific
design mindset, and I've seen that play out over several codebases. There
isn't really anything I can call "functional" in a system fundamentally based
on cyclic (often) graphs of mutable objects.

I think what may be implicit (and hence miscommunicated) in discussions about
FP/OOP is that it's not about programming in the small (i.e. specific
algorithms, blocks of code), it's about programming in the large (modules and
their relationships; management of persistent data). Many examples I see of
FP/OOP are algorithmic, and hence uninteresting -- you can get some nice ideas
for how to condense your code or express the core ideas better, but it isn't
exactly a paradigm shift.

Every Turing-complete language can encode any computable function; algorithms
may have complexity distinctions but are ultimately not far removed. The
FP/OOP discussion would be better served discussing the architectural
implications of these styles.

> B) A lot of FP articles come off as the musings of zealots obsessed with
> monads, which often barely make any sense to, well, anyone.

Monads are an example of a dominant architectural pattern in FP that takes
advantage of the core conceit of the paradigm. I think monads tend to be
explained at the algorithmic level, which is unfortunate -- in many ways,
they're about decoupling domain logic from control logic, which (I will posit)
is desirable in any system, not just one that's FP.

------
pbiggar
Completely agree. There are a couple of "killer features" of functional
programming that led to us adopting it both to build Dark, and for Dark
itself. Immutable values makes it so much easier to reason about programs. And
then removing null and exceptions.

The downsides: a bit of a learning curve for programmers used to OO; some
classes of problems are easier with OO, though not as many as you'd expect.

The real downside I've seen is that so much valuable information is in
academic papers that aren't approachable.

~~~
tybit
As someone that likes functional principles but hasn’t found a simple
functional language with good IDE support, I’m more worried about an
approachable language than approachable papers.

Hoping you’re successful in helping to solve this.

------
phtrivier
> > To be widely used, a language should support interlanguage working,
> possess extensive libraries, be highly portable, have a stable and easy to
> install implementation, come with debuggers and profilers, be accompanied by
> training courses, and have a good track record on previous projects.

> The first five of those factors, which are mainly technical, are provided by
> almost all of the functional languages.

That seems like a very generous statement. Unless the author is talking about
some functional language I don't know.

Is there an FP language which _really_ has the extensive libraries of Java /
Python / C++ / JS ? (You might argue with Clojure and anything with a FFI..)

Is there an FP that has a debugger and profiler as Visual Studio for C++,
Eclipse for Java, and your browser for JS ? (No, you REPL does not count as
debugger.)

Is there any language that as `interlanguage working` (ok, this one is unfair,
only JVM and C really count...)

Is there an FP that has an implementation that's not a nightmare to install ?
(ok, this one's even more unfair - _everything_ is a nightmare to install...)

~~~
tigershark
F#

~~~
thrower123
F# should be more popular. But C# is just good enough that the small amount of
extra effort of using F# is a speed bump that's hard to get past.

------
coldtea
> _However, looking at how discontent programmers are with Objective-C, not so
> much anymore. Not even the immaturity of the tooling around the language
> like its IDE Xcode could stop the migration._

Actually it has little to do with some huge "discontent" towards Objective-C,
and more with Apple presenting Swift as the way forward and their main
officially supported language...

> _So why are most of the young contenders stuck with little recognition in
> their niches, while Swift is taking off so quickly?_

Again, because no functional language has a huge company promoting it as THE
language its devs should use, like Swift has with Apple. F# is not MS's
favorite, for example...

> _For developers building applications in the Apple ecosystem, the primary
> hard problem seems to be Objective-C. In other words, ”the pain” is so
> significant that developers were almost desperately waiting for an
> alternative language and are now happily joining the movement of the Swift
> language._

Yeah, no...

> _The first five of those factors [interlanguage working, possess extensive
> libraries, be highly portable, have a stable and easy to install
> implementation, come with debuggers and profilers], which are mainly
> technical, are provided by almost all of the functional languages._

Not really. Compared to C#, Java, Javascript, it's not even close...

> _Following the theory of "The Chasm", FP would need to solve a severe
> problem that could not be solved with existing approaches in order to make a
> breakthrough (finding its "killer app")_

Not really. Swift doesn't solve any special problem "that could not be solved
with existing approaches", C# doesn't, Java doesn't, and in general, most
successful languages don't.

They succeed because of platform stronghold (UNIX -> C, MS -> C++, OSX/iOS ->
Swift) and other such reasons...

~~~
AnimalMuppet
In my opinion, Java succeeded for two reason: the (not quite fulfilled)
promise of "write once, run anywhere", and the library. In the beginning, it
didn't have "platform stronghold" anywhere, not even on Sun. (Although, if the
platform was "everywhere", there weren't many alternatives.) And the language
itself was not a spectacular advance. But the library was _massive_. And the
promise of "run everywhere" was very tempting.

------
kstenerud
At the end of the day, it comes down to performance. We've been lucky for a
long time where the hardware improvements seemed to almost come for free, but
the golden age of Moore's law is over, and people finally are realizing that
their code needs to be tighter in order to achieve performance. FP doesn't
mirror how the actual machine instructions work, whereas imperative languages
do. And this means that when you inevitably hit a performance wall, it's
generally easier to solve it in an imperative environment because you can
already visualize what's going on underneath (save for gc stalls or whatnot).
FP has its places to shine, but without the ability to see how the sausage is
made (and tweak it), you're always at risk of an unbreachable wall.

~~~
tom_mellior
> FP doesn't mirror how the actual machine instructions work, whereas
> imperative languages do.

Can you explain what FP concepts don't "mirror how the actual machine
instructions work"? Arithmetic maps to arithmetic instructions. Calls map to
calls or jumps, which are well-supported by hardware. If statements map to
conditional jumps. Pattern matching maps to something like switch statements
(plus extra jumps), which are not hardware features, but they aren't hardware
features in imperative languages either. What else? Oh, you don't write
"malloc" or "new" to allocate memory (which, again, don't map directly to
individual machine instructions). That's about it, I think. What am I missing?

~~~
kstenerud
Generators don't mirror the hardware. They are higher order tricks with hidden
costs that can bite you if you're not careful. Lazy evaluation is a
convenience that is dangerous to think of as free, as is recursion. Code-as-
data limits the kind of addressing that can be used in the chip itself. There
are mitigations for 95% of cases, of course, and nothing's stopping you from
changing the algorithm entirely or parallelizing or whatever. I'm not saying
that FP is a dead end. What I'm saying is that it comes with a cost in that
you end up limiting your options if you hit a roadblock, because you can't
just modify the imperative path due to the higher order functionality you're
relying on. FP is very powerful, but that power doesn't come for free. For
real-world applictions, a mixed approach will work best for most things.

~~~
tom_mellior
> Generators don't mirror the hardware.

You mean like this?

    
    
        #include <stdio.h>
        #include <stdlib.h>
    
        struct generator_state {
            int next_value;
            int limit;
        };
    
        struct generator_state *enum_from_to(int from, int to) {
            struct generator_state *generator = malloc(sizeof *generator);
            generator->next_value = from;
            generator->limit = to;
            return generator;
        }
    
        int has_next(struct generator_state *state) {
            return state->next_value <= state->limit;
        }
    
        int next(struct generator_state *state) {
            return state->next_value++;
        }
    
        int main(void) {
            printf("try to enumerate from 1 to 10\n");
            struct generator_state *generator = enum_from_to(1, 10);
            while (has_next(generator)) {
                printf("%d\n", next(generator));
            }
            return 0;
        }
    

Oh no! Imperative programming doesn't mirror the hardware!

> Lazy evaluation is a convenience that is dangerous to think of as free

So your problem isn't really FP, it's Haskell?

> as is recursion

It's dangerous to think of any computation as free, so... OK.

> Code-as-data limits the kind of addressing that can be used in the chip
> itself.

I don't know what you mean here, but "code as data" isn't a universal feature
of FP languages. Even in Lisp it's essentially a compile-time abstraction for
macro expansion, you don't massage your function definitions at runtime. And
once your code is compiled to machine code, what exactly is the problem with
using all of the chip's addressing modes?

Maybe by "code as data" you mean "first-class functions", i.e., that you can
have pointers to code that you can store in data structures? I'll spare you
the C example of function pointers because we've established above that C is a
terrible language that doesn't map nicely to the hardware ;-) Maybe it's
Pascal you want!

------
platz
> Since the early 2000s, functional programming has become more and more
> popular

This is because pre-2000's, OO was particularly well-suited to desktop
software and dominated that space, which also happened to be a space which
occupied a large fraction of total development.

OTOH, tasks of data transformation, which after the 2000's became in more
demand as software moved more and more from the desktop to the server, is
particularly well-suited to FP (due to being on the other side of the
expression problem).

The shift from desktops to servers has real consequences on language design.

Microsoft even admitted this as one of the reasons they're trying to bolt on
FP features to C#.

------
rafaelvasco
I architect my code in layers. Generally OO based then specifically functional
based; I find that works best for me.

~~~
IggleSniggle
You should do whatever works for you! But, have you encountered the idea of
"Functional core, imperative shell?"

[https://www.javiercasas.com/articles/functional-
programming-...](https://www.javiercasas.com/articles/functional-programming-
patterns-functional-core-imperative-shell)

~~~
maximente
i think the original talk by Gary is basically perfect for this bc it shows
the power of mixing FP and non-FP in an imperative but flexible language
(ruby)

it's... a little different in Haskell bc it basically makes you work in this
paradigm already, so not a huge value add imo

all that is to say, just watch the original talk:

[https://www.destroyallsoftware.com/talks/boundaries](https://www.destroyallsoftware.com/talks/boundaries)

------
tiborsaas
> FP would need to solve a severe problem that could not be solved with
> existing approaches in order to make a breakthrough

So the question the author is asking is whether there is problem which can
only be solved via lambda calculus and not by turning machines or at least the
difference should be significant in favour of lambda calculus.

Since both approaches are equivalent models of computation, I have to bet on
the "no such killer app" side.

~~~
6gvONxR4sf7o
It's not "can't solve" in the sense of abstract computation, but rather "can't
solve" in the sense of "you couldn't build facebook in the brainfuck
language."

------
patientplatypus
FP is fun, but there aren't many good languages for it. Haskell is too
academic, Clojure is fun but hasn't taken off, Scala is too complicated (Java
with FP shoehorned in, who thought this was a good idea?).

I like FP but 90% of the time you'd be better off with just Python because
other developers will be able to work with it and there are libraries. Or
Golang or Node or whatever.

Frustrating, but it is what it is.

~~~
johnisgood
How about OCaml?

[https://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/](https://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/)

[https://ocaml.org/learn/tutorials/functional_programming.htm...](https://ocaml.org/learn/tutorials/functional_programming.html)

~~~
johnisgood
This is a newer one, with advanced topics and probably other changes:
[https://www.cs.cornell.edu/courses/cs3110/2019fa/textbook/](https://www.cs.cornell.edu/courses/cs3110/2019fa/textbook/)

------
imvetri
Please don't fancy functional programming in javascript. Its a powerful
paradigm and should be used in a language with powerful compiler.

~~~
tom_mellior
JavaScript compilers are about the most powerful ones out there.

~~~
imvetri
Sorry. I should have shared the example I was thinking of as well.

Just my example.

[lengthy_array].map(function).filter(function).reduce(function).

JS compiler just runs them.

A compiler to be powerful to handle such functional programming syntax should
also have ability to inline the functions as a single function.

the above example could be recompiled as

[lengthy_array].array_operation(Three function composed into one)

~~~
tom_mellior
Oh, forgot to answer here. As a compiler developer I'm _very_ surprised by the
assertion that this wouldn't be optimized by something like V8 or GraalVM's
JavaScript engine. But I couldn't JavaScript myself out of a paper bag, so I
don't know how to verify this myself.

------
msla
Compilers care about functional programming in its side-effect-free form
because you can only optimize code you can understand the side effects of, and
side-effects generally foreclose on optimization. The most obvious example is
the volatile keyword in C, and how that forces a lot of memory traffic the
compiler would otherwise be able to avoid.

~~~
ncmncm
That is the theory.

In practice, the optimizations compilers implement using the advantages of
known lack of side effects and mutation generally just aim at recovering part
of the performance lost through excess copying.

------
myrryr
How the hell did Kotlin end up on the non functional list, and Scala did?

Kotlin code tends to be at least as functional as Scala is.

If Kotlin isn't functional, then Scala isn't, and if Scala is functional, then
Kotlin most certainly is.

~~~
jillesvangurp
You can do functional in Java as well; and people do. It's probably something
purists look down on as inferior; and they'd probably be right. However, it
does bring advantages relative to non functional Java code and it's been
creeping into the language and frameworks for many years now. Kotlin sort of
sits in between Scala and Java. Where Scala only grudgingly allows you to do
things like for loops and other imperative stuff, Kotlin is a lot less
conflicted about this while providing most of what you'd want out of a
functional language as well. It supports both styles pretty well.

As a consequence the "my language is more functional than yours" is less
relevant these days. If you look at the mainstream languages (Javascript,
Java, C#, Rust, Go, Python, Ruby, Kotlin, Scala, Swift, etc.) they all borrow
some things from the functional world. They all have some sort of collections
supporting things like map, reduce, fold, etc. They all have some notion of
lambda functions and passing function references around. Etc. In several of
those languages, this has been the case for quite long as well. All of those
languages have in common that they are relatively new.

Bucketing languages as functional and non functional is less clear cut than it
used to be. In that sense, functional programming has gone mainstream and most
programmers are exposed to it now. 25 years ago when I started out, we had
some functional programmer pioneers teaching at my university and I got
exposed early to what at that time definitely was not very practical in terms
of real world applicability. I had my compiler course on parser generator
frameworks written in gopher (a haskell predecessor). I even got exposed to
monads during that course. You won't see a lot of Kotlin coders talk about
monads but when you start talking about side effects, they'll have plenty of
solutions nevertheless.

Arguably, Scala is a bit more puristic on this front but the practical value
over less puristic languages is not that enormous.

------
jahaja
Isn't FP simply too esoteric to ever become properly mainstream?

~~~
DonaldPShimoda
No, definitely not. FP concepts are catching on in mainstream languages. Lots
of languages now support optionals instead of implicit nulls, maps and filters
over lists, higher-order functions, etc. These all originated in FP and have
just made their way over to the more mainstream imperative languages.

Not only that, but FP is must more a state of mind than a set of language
features. You can write functional code in practically any language, really,
although some of them will make it easier than others.

~~~
jahaja
Looking in from the outside, I just can't see how a project written in most
esoteric-leaning languages can scale beyond like 5 developers without becoming
an unreadable mess simply due to the expressiveness of the language.

~~~
DonaldPShimoda
> I just can't see how a project written in most esoteric-leaning languages
> can scale

Well what do you mean by "esoteric-leaning"?

It seems like you just mean "languages I'm not used to", which is a very
limiting perspective, but perhaps I've misinterpreted you here.

Obviously nobody thinks you should write your production code in Brainfuck
(which is an actual esoteric language).

But there are plenty of places that use functional languages in production.
Functional language are not esoteric by nature — they're just different. It's
like calling SQL an esoteric language just because you're used to Java.

Jane Street uses OCaml for everything, Facebook uses Haskell and ReasonML
(which is really OCaml), Galois uses Haskell, Microsoft has F# and F* and a
Haskell group, GitHub uses Haskell... There are plenty of examples of
functional languages in industry. They're not esoteric, and they do scale when
implemented correctly (same as anything else).

> without becoming an unreadable mess simply due to the expressiveness of the
> language.

...?

I don't mean this rudely, but are you sure you know what "expressiveness"
means? More expressive languages are not inherently more or less readable than
other languages. They simply enable you to do things you couldn't do in those
other languages.

C is more expressive than, say, x86 assembly by the inclusion of features like
types. Do types make your code less readable? I don't think so.

Java is more expressive than C by the inclusion of classes. Do classes
inherently make your code less readable? I don't think so.

Haskell is more expressive than Java by the inclusion of higher-kinded types.
Do HKTs inherently make your code less readable? Not if you know what they are
and how to use them — which you would if you use a language that supports
them. So I don't think so.

------
kangnkodos
The article doesn't mention all the programmers being (forcibly) introduced to
functional programming concepts by using React and Redux.

Perhaps this is another possible way to jump the chasm?

------
mosdl
Lots of words without much value, just like FP!

Seriously, why is this on the homepage? Doesn't contain anything interesting
about FP.

~~~
hans1729
>Lots of words without much value, just like FP!

not sure if

a) people didn't get the pun

b) the pun wasn't intended

or c) both

:thinking:

~~~
DonaldPShimoda
It's a bad pun, if it was meant as one. FP is all values and few words,
compared to OO languages.

~~~
TurboHaskal
I am not sure if you have been paying attention to the strongly typed,
category theory zealots lately (who seem to claim they hold the one and only
valid functional programming viewpoint). The size of vocabulary and relations
they end up juggling put any over engineered OO system to shame.

It is attracting the same kind of people that 15 years ago would have reached
for (and preached) the GoF book.

~~~
DonaldPShimoda
> I am not sure if you have been paying attention to the strongly typed,
> category theory zealots lately

Well (1) this is not inherent to all functional programming, and (2) the joke
appears to imply that code written in FP will be more verbose with less
content, which is surely not the case. (And also (3) I'm guessing you meant
"statically typed" instead of "strongly typed", since the latter is poorly
defined and not generally the subject of discussion among functional
programmers that I've interacted with.)

I also have met quite a few people who are into category theory, and none of
them have made any claim about holding "the one and only valid functional
programming viewpoint". But the people I talk to are genuine academic
researchers and not armchair academicians, so perhaps there's a difference
there.

~~~
TurboHaskal
You are right on all points.

As for the category theory zealots I have found at work or at conferences,
none of them were academics, but rather what I would describe as clueless
narcissists overdosed on FP Kool-aid.

~~~
DonaldPShimoda
Ah yeah, that's the unfortunate part of those communities haha. But every
community has some of those. :)

When you say "conferences", do you mean academic conferences or
industry/language-specific conferences?

I found that there were plenty of people deep into category theory at ICFP
this year (an academic conference), but most of them had very reasonable
perspectives on the utility of CT and things to that effect.

