
Why Isn't Functional Programming the Norm? [video] - gyre007
https://www.youtube.com/watch?v=QyJZzq0v7Z4
======
_han
The top comment on YouTube raises a valid point:

> I've programmed both functional and non-functional (not necessarily OO)
> programming languages for ~2 decades now. This misses the point. Even if
> functional programming helps you reason about ADTs and data flow, monads,
> etc, it has the opposite effect for helping you reason about what the
> machine is doing. You have no control over execution, memory layout, garbage
> collection, you name it. FP will always occupy a niche because of where it
> sits in the abstraction hierarchy. I'm a real time graphics programmer and
> if I can't mentally map (in rough terms, specific if necessary) what
> assembly my code is going to generate, the language is a non-starter. This
> is true for any company at scale. FP can be used at the fringe or the edge,
> but the core part demands efficiency.

~~~
bryanphe
In terms of performance, the way we build applications today is _such a low
bar_ that IMO it opens the door for functional programming. Even if it is not
as fast as C or raw assembly - if it is significantly faster than Electron,
but preserves the developer ergonomics... it can be a win for the end user!

I created an Electron (TypeScript/React) desktop application called Onivim [1]
and then re-built it for a v2 in OCaml / ReasonML [2] - compiled to native
machine code. (And we built a UI/Application framework called Revery [3] to
support it)

There were very significant, tangible improvements in performance:

\- Order of magnitude improvement in startup time (time to interactive,
Windows 10, warm start: from 5s -> 0.5s)

\- Less memory usage (from ~180MB to <50MB). And 50MB still seems too high!

The tooling for building cross-platform apps on this tech is still raw & a
work-in-progress - but I believe there is much untapped potential in taking
the 'React' idea and applying it to a functional, compile-to-native language
like ReasonML/OCaml for building UI applications. Performance is one obvious
dimension; but we also get benefits in terms of correctness - for example,
compile-time validation of the 'rules of hooks'.

\- [1] Onivim v1 (Electron)
[https://github.com/onivim/oni](https://github.com/onivim/oni)

\- [2] Onivim v2 (ReasonML/OCaml) [https://v2.onivim.io](https://v2.onivim.io)

\- [3] Revery:
[https://www.outrunlabs.com/revery/](https://www.outrunlabs.com/revery/)

\- [4] Flambda: [https://caml.inria.fr/pub/docs/manual-
ocaml/flambda.html](https://caml.inria.fr/pub/docs/manual-ocaml/flambda.html)

~~~
tick_tock_tick
They already said they were working in games. None of what you said applies to
that field.

~~~
shadowgovt
I have a suspicion this is only semi-true.

For controlling what the CPU and RAM are doing? Yes. The graphics shader, on
the other hand, is a pipeline architecture with extremely tight constraints on
side-effects. The fact the shader languages are procedural seems mostly
accident of history or association to me than optimal utility, and the most
common error I see new shader developers make is thinking that C-style syntax
implies C-style behaviors (like static variables or a way to have a global
accumulator) that just aren't there.

The way the C-style semantics interface to the behavior of the shader (such as
shader output generated by mutating specifically-named variables) seems very
hacky, and smells like abstraction mismatch.

~~~
vbarrielle
Not exactly shaders, but for GPGPU stuff, futhark [0] seems to show that a
functional paradigm can be very good to produce performant and readable code.

[0] [https://futhark-lang.org/index.html](https://futhark-lang.org/index.html)

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

~~~
gambler
What a coincidence. This sounds exactly like what happens with OOP. Every
discussion here gets swarmed with clueless people who think Java is the apex
of OO programming, because that's what gets taught in universities these days.
They don't understand any of the core concepts that prompted Xerox Park to
develop the OO paradigm in the first place. They aren't aware of any of the
relevant research. They operate under the assumption that OO was born out
complete ignorance of functional programming, even though people who kick-
started its rise were keenly aware of Lisp (for example, Alan Kay frequently
references McCarthy's work and research papers in his talks). Etc, etc.

~~~
senderista
I think the Smalltalk paradigm is deeply defective and the Actor model (the
purest form of OOP to my mind) remedies most of its faults but perpetuates
some others. A few flaws:

\- Modeling all communication as synchronous message-passing. Some
communication (such as evaluating mathematical functions) is naturally modeled
as synchronous procedure calls, while communication which is naturally modeled
as message-passing should be asynchronous by default (to address unpredictable
latency, partial failure, etc.).

\- Emphasizing implementation inheritance as the primary means of code reuse.
This is now generally acknowledged to be a mistake, so I won't elaborate.

\- Deferring all method resolution to runtime. This makes the amazing
introspective and dynamic capabilities of Smalltalk possible, but it also
makes it impossible to statically verify programs for type-correctness.

\- Relying on mutable local state rather than explicit, externalized state.
This is controversial, and it's a defect of the Actor model as well (yes,
passing new parameters into a tail-recursive message receive loop is
equivalent to mutating local state). The partisans of OOP and the Actor model
believe this to be a virtue, enabling robust emergent collective behavior from
small autonomous software agents, but it makes predicting large-scale behavior
difficult and debugging nearly impossible.

~~~
lazulicurio
There was an article on state in OOP posted here a few days ago that I found
very thought-provoking[1]. The blog post and related youtube videos are pretty
interesting as well[2][3][4].

[1]
[https://news.ycombinator.com/item?id=21238802](https://news.ycombinator.com/item?id=21238802)

[2] [https://medium.com/@brianwill/object-oriented-
programming-a-...](https://medium.com/@brianwill/object-oriented-programming-
a-personal-disaster-1b044c2383ab)

[3]
[https://www.youtube.com/watch?v=QM1iUe6IofM](https://www.youtube.com/watch?v=QM1iUe6IofM)

[4]
[https://www.youtube.com/watch?v=IRTfhkiAqPw](https://www.youtube.com/watch?v=IRTfhkiAqPw)

------
lewisjoe
Richard Gabriel’s famous essay “Worse is better”
([https://www.jwz.org/doc/worse-is-better.html](https://www.jwz.org/doc/worse-
is-better.html)) is an interesting perspective on why Lisp lost to C. In a
way, the same arguments (simplicity vs consistency vs correctness vs
completeness) can be made for why functional programming lost to OOP.

But those philosophical perspectives aside, personally I find my brain works
very much like a Turing Machine, when dealing with complex problems. Apart
from my code, even most of my todos are simple step-by-step instructions to
achieve something. It’s easily understandable why like me, other non-math
folks would prefer a Turing Machine over Lambda Calculus’ way of writing
instructions.

This could be why OOP/Imperative was often preferred over FP.

~~~
strangenessak
> _personally I find my brain works very much like a Turing Machine_

Exactly this. How baking a cake in FP looks like:

* A cake is a hot cake that has been cooled on a damp tea towel, where a hot cake is a prepared cake that has been baked in a preheated oven for 30 minutes.

* A preheated oven is an oven that has been heated to 175 degrees C.

* A prepared cake is batter that has been poured into prepared pans, where batter is mixture that has chopped walnuts stirred in. Where mixture is butter, white sugar and brown sugar that has been creamed in a large bowl until light and fluffy

Taken from here: [https://probablydance.com/2016/02/27/functional-
programming-...](https://probablydance.com/2016/02/27/functional-programming-
is-not-popular-because-it-is-weird/)

~~~
chii
but now that you've written the cake baking data type, with a little small
tweak, you've got a bread baking data type.

~~~
Torwald
I'd rather have a baking class that takes an argument for what I want to bake,
either bread or cake, and spares me the details of how baking is done. I don't
have to know that a preheated oven is one that is at 175 grades etc

~~~
EpicEng
And when your oven has a problem with it's heating element you'll have no idea
why your cake didn't turn out well. We're supposed to be engineers, right?
Learning how things work is good.

~~~
Torwald
My comment was supposed to be a joke about the vernacular in which OO tends to
get presented.

------
cryptica
OOP was designed to prioritize encapsulation at the expense of referential
transparency. Functional programming was designed to prioritize referential
transparency at the expense of encapsulation.

You cannot have referential transparency and encapsulation at the same time.

In order to prevent mutations (which is a requirement of FP), a module cannot
hold any state internally; this necessarily means that the state must be
passed to each module action from the outside. If state has to be passed to
each module action from the outside, then this necessarily means that the
outside logic needs to be aware of which state is associated with which action
of which child module. If higher level modules need to be aware of all the
relationships between the logic and state of all lower level (child) modules,
that is called 'leaky abstraction' and is a clear violation of encapsulation.

Encapsulation (AKA 'blackboxing') is a very important concept in software
development. Large complex programs need to have replaceable parts and this
requires encapsulation. The goal is to minimize the complexity of the contact
areas between different components; the simpler the contact areas, the more
interchangeable the components will be. It's like Lego blocks; all the
different shapes connect to each other using the same simple interface; this
gives you maximum composability.

Real world software applications need to manage and process complex state and
the best way to achieve this is by dividing the state into simple fragments
and allowing each fragment to be collocated with the logic that is responsible
for mutating it.

If you design your programs such that your modules have clear separation of
concerns, then figuring out which module is responsible for which state should
be a trivial matter.

~~~
overgard
Encapsulation is desirable because it limits the possibility space of what can
operate on a set of data. Referential transparency is desirable because pure
programs are much easier to reason about. If I understand what youre saying,
it seems youre saying referential transparency and encapsulation are at odds
and encapsulation is more valuable, but I disagree. Hiding state maybe keeps
things tidy and enforces that you need to use the API, but its not really the
point IMO. The point of encapsulation is managing state mutations. Hiding
state is only a small part. You dont need to hide state as much when its
immutable because then you don’t need to care what other code is doing with
your emitted data structures because it doesn’t effect you.

~~~
cryptica
Encapsulation doesn't necessarily mean hiding state. It means hiding the
implementation details of how actions mutate the state. The same action called
on a different kind of module instance can end up mutating the instance's
internal state in a completely different way. The higher level logic should
not be concerned with how a module performs an action.

------
bpyne
I think we need to get past the point of believing in some FP revolution in
which enlightenment happens and people suddenly switch to Haskell, OCaml,
Clojure, etc. FP is happening in a more evolutionary way with newer languages
like Kotlin, Scala, F#, etc. taking ideas from Haskell, SML, and Lisp.

I'm not pretending to be the first to state this observation but I feel like
it needs reinforcement here.

~~~
overgard
I think most of the growth of FP is coming from libraries and hybrid
languages. Things like React and Redux and streams/linq style operations on
data structures, or default immutability. I don’t think “pure” languages will
ever really become dominant but a lot of the best ideas are being borrowed.

------
gpderetta
I do not pretend to be a particularly skilled programmer, but in my not so
long career I have picked up a bunch of tools: a few algorithms here and
there, some data structures, some programming techniques like encapsulation,
late binding, higher order functions, pipelines, various form of polymorphism
(dynamic, static, ad hoc, inheritance based, structural or whatever), some
concurrency patterns (message passing, shared memory, whatever). I end up
using whatever seems more appropriate to me for a specific problem depending
on intuition, personal preference and experience.

Now, various subsets of the items above have been labeled with different names
(functional, procedural, OOO, generic, whatever), but of course most of the
time no two people can agree on which subset deserves which label.

I must not be the only one, because a lot (but not all) of very successful
languages are not very opinionated and let people mix and match bits as
needed.

------
yodsanklai
I didn't listen to the video, but the title raises questions. What is
functional programming? Nowadays, most languages are multi-paradigm, it's not
so clear what is functional programming (or a functional programming
language).

For instance, it's very common to have data types with mutable state in OCaml,
or to use non-mutable data-structures, closures, higher-order functions in let
say Python. I don't see such a clear dichotomy between functional/non-
functional programming languages anymore.

Besides, there are other language "features" that I feel have more impact on
the code I write. For instance, static/dynamic typing, asynchronous I/O vs
actors vs threads, module systems.

I see functional programming more as a tool and a programming discipline,
well-suited to solve some problems, rather than a paradigm that one should
adhere no matter what.

~~~
pyrale
The talk actually takes time to answer these questions.

The title is also a bit clickbaity because the talk acknowledges that fp as a
style is becoming common.

------
onion2k
JavaScript isn't a functional language itself, but you can use a functional
library like lodash/fp ([https://github.com/lodash/lodash/wiki/FP-
Guide](https://github.com/lodash/lodash/wiki/FP-Guide)) on top of it to get
all that lovely functional goodness in your frontend and node code. Using
lodash/fp has made my frontend state management code a lot nicer, and I'm
really only just starting out with it.

~~~
Tade0
You may want to consider Ramda.js instead:
[https://ramdajs.com/](https://ramdajs.com/)

IMHO does a better job than Lodash, because:

1\. All functions are automatically curried.

2\. The order of parameters lends itself to composition.

EDIT: 3. Transducers.

~~~
enlyth
I never understood the point of Ramda. It's like it's trying to replace the
core functionality of JS with something that's completely orthogonal to what
the language actually is, but it's just a bolted on library.

I've worked on codebases where people ignore all built-in JS functions (like
Array.map/filter) and write Ramda spaghetti instead with multiple nested pipes
and lens and what not to show off their FP purism.

Most of the time, you don't need any of this, it just makes the codebase
unreadable, and hard for new people to join the project and be productive in a
timely fashion.

~~~
wdroz
Maybe to avoid questionable behaviors, like in the article posted 3 months ago
"Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript" [0]

[0] -
[https://news.ycombinator.com/item?id=20242852](https://news.ycombinator.com/item?id=20242852)

~~~
Roboprog
Things like Ramda and jquery help avoid fighting against IE and other browser
nuances, as well.

Even when there seem to be native functions/ methods to do something. That’s
where the monster lives.

------
pnako
Because it's not that useful.

There is an contest organized by the International Conference on Functional
Programming:
[https://en.wikipedia.org/wiki/ICFP_Programming_Contest](https://en.wikipedia.org/wiki/ICFP_Programming_Contest)

It was more or less designed to show the superiority of functional programming
languages. Yet in that contest C++ has done better than OCaml or Haskell...

The FP crowd seems to be more active doing advocacy than writing code. Yes, we
know, there is that one trading company using OCaml. It's such a niche
language that they have to pretty much maintain the toolchain and standard
library themselves. Meanwhile, plenty of more successful companies use C++, C#
or Java with no problem.

If you want to convince someone of the superiority of FP, write a real killer
application. A new browser to compete with Chrome, a video game that can
dethrone Skyrim or the Witcher 3. Maybe a DBMS that's even better than
PostgreSQL? Basically: show, don't talk.

~~~
iLemming
Just because you don't see it, doesn't mean it's not happening.

\- Have you ever heard about how Walmart handles Black Fridays?

\- Do you even know what's behind Apple's payment system?

\- You ever used Pandoc, Couchbase, Grammarly, CircleCI, Clubhouse.io,
Pandora, Soundcloud, Spotify?

\- Have you ever asked a question - what is an app like WhatsApp that was sold
for $19 Billion runs on?

\- or How Facebook fights spam, Cisco does malware detection or AT&T deals
with abuse complains?

\- How Clojure is used at NASA or how Microsoft uses Haskell?

Frankly, I don't even know what's there to debate about. Functional
programming is already here and it's been used in the industry for quite
awhile already and its usage growing in a quite steady pace. Almost every
single programming language today has certain amount of FP idioms, either
built-in or via libraries. So yeah, while you're sitting there, contemplating
about if FP useful or not, people been building hundreds of awesome products.

~~~
pnako
I said: it's not _that_ useful. I did not say it's completely useless.

Every large (or even small) company has people writing stuff in Perl, Bash,
Haskell, Ruby, Rust, VBA, Scala, Lua or what not. I've been that guy, too.

More often than not it is a distraction more than anything, and it ultimately
ends up being rewritten in C++, Java or Python. I think there are some niches
where it helps; OCaml has had some success with static analysis and proof
assistants, or even with code generation projects like FFTW.

~~~
iLemming
Honestly, do you really think a company with only 35 engineers could build,
scale and sell a product like WhatsUp for even a fraction of that amount but
using C++, Java or Python? I seriously doubt that.

Look, I've seen both sides and I know this for sure (this isn't a mere
opinion, this is a certain fact) - FP allows to build and maintain products
using smaller teams.

You don't have to trust my word, do your research, google "companies using
Clojure" (or Haskell, OCaml, Erlang, etc). You will see that either those
companies are not too big, or the FP teams in large companies not very large.
Skeptics often cite this fact, claiming it to be the proof that FP codebases
don't scale to large teams. The truth is - you don't need a big team to build
a successful product with FP language. And the number of startups using FP
langs is steadily growing.

------
hevi_jos
Because it is not the best solution for most computer problems.

Simple as that.

I am a functional and OOP programmer myself. I find functional way more
elegant for modeling most mathematical problems, but OOP way better at
modeling real life things with states.

OOP and states introduce lots of problems and complexity, but the solution is
not removing states, or a series of complex mathematical entelechies.

In fact "removing states" is not really removing them. It is creating new
objects with static states on it. It makes it super hard to model real life.

(dynamic)States exist in real life. Temperature, pressure, height, volume,
brightness, weight...

There are programmers that understand programs as a religion, they only
program in one system ans believe it is the best thing in the world and
everybody should be forced to use it. I feels sorry for them and the people
that depend on them.

The solution will be new paradigms that are neither OOP nor FP.

~~~
psychoslave
>(dynamic)States exist in real life. Temperature, pressure, height, volume,
brightness, weight...

It's more like, states better match our more common way to model our sense-
data. It's easier to grasp for us, but it doesn't mean it's the way that will
cause provide the best desirable results.

If you take the example of mass in physic, most of the time it's perfectly
fine to deal with it as an first class attribute of an object. But it's not
how Higgs mechanism aboard the notion.

------
HALtheWise
One thing I haven't seen brought up in this thread yet is support for foreign
language embeddability. For example, Python code is technically quite slow,
but that often doesn't matter much because it is easy to write external
functions in C or C++ that behave like normal Python functions. I imagine that
it would be more difficult to embed C++ code into a language with strong
functional gauruntees. In that sense, the performance of Python is close to
the performance of the fastest language with the same paradigm, which is (with
current compilers) better for imperative programs that are structurally more
similar to how the CPU operates.

------
LandR
Good ideas take a long time to catch on in tech, regardless of how much anyone
believes its a fast moving industry.

------
axilmar
Functional programming? absolutely 100% yes.

Functional programming languages? well, it depends on the problem.

If performance is an important issue, most of the time functional programming
languages are a big 'no'.

~~~
pyrale
Well, if performance is really an issue, I guess anything that is not C, C++,
rust or a thin wrapper over those languages or legacy libs written in the
likes of Fortran won't be an option, so yes.

That being said, it seems like performance is not an issue for most of the
code written these days, aside from not writing quadratic solutions for
problems solvable in linear time.

If you use java, .net, go or the likes, odds are you would be fine with a
functional language ; and if you need performance with those languages, odds
are that you will need arcane knowledge equivalent to what you would need to
know to make performant fp code.

------
AlexandrB
This video exists in an alternate reality where marketing departments do not.
Many of these languages became popular not because of some intrinsic property,
but because of a strong marketing push by one or more backing companies. There
was a period of time, not so long ago, where "object oriented" was basically a
checkbox on language marketing copy, and if your language didn't have it you
would get scoffed at.

~~~
WhompingWindows
Can you give contemporaneous examples? I'm curious if there are companies out
there actively pushing their language/framework, as opposed to sort of
passively posting/updating without marketing.

~~~
stkdump
The lines between marketing and "passively posting" are very blurry,
especially in the tech world. Is Linus T. marketing, when in a technical
presentation about git he says "if you like SVN you might wanna leave"? Is
Mozilla marketing, when they claim in technical blog posts that rust provides
system language level performance while being safe?

------
hootbootscoot
OO is merely a style of laying out imperative code for the compiler to put
into proper linear order.

End of the day there are instructions emitted in a linear fashion and other
instructions running (OS?) can provide an execution context ("Hi process,
here's your memory area with pretend addresses do you can think it's all
yours, you go over there to Core-2 and run at Z priority.")

OO is not particularly easy to learn WRT FP, but it does have the contextual
advantage of having been delivered on the back of FAST compiled languages like
C++.

Java runs as fast as the big money thrown into it's VM can make it run. If the
JVM were dog-slow, you would see lower adoption of it.

Ocaml as used by corps like Jane Street etc,is not directly for running
application code from (or rather, the application in question does code
generation.)

High level languages could be expected to adopt either code-generational or
Cython-style approaches. (Chicken Scheme, for example)

C++ merely has the historical accident of bridging 2 generational worlds of
computing, hence you can find C++ full-stack.

Anyone for doing DSP purely in Ruby with no C-libs?

------
gfs78
It´s basically because of marketing, fads, hype but we also have to take into
account that FP is probably ok for the Hacker News audience but way too
complex for the average developer.

Most code is LOB apps and social media apps churned by software factories and
internal IS/IT areas. In these kind of projects coding is a rite of passage
before becoming a team leader or a project manager, so most devs won´t invest
much in their coding skills. As a result the average code tends to be badly
decomposed procedural code over a procedural-like class hierarchy and devs
just follow the fads because this is what gets them jobs.

Adding FP to this formula could prove really wrong for those in charge of
projects. Better to be conservative and use Java, C#, Python or even
nodejs/JavaScript as they allow to churn the same procedural code of ever just
in different clothes.

------
vkaku
Because simple is better than perfect.

~~~
iLemming
Well, funny you said that. Clojure people put simplicity above everything else
[https://www.youtube.com/watch?v=34_L7t7fD_U](https://www.youtube.com/watch?v=34_L7t7fD_U)

------
FpUser
I got another question. Why don't those prophets leave intelligent people
alone and let them use whatever tooling/approach they find appropriate for
solving particular problem instead of heating the air trying to
propagate/force whatever ideology they carry.

~~~
JustSomeNobody
Because those profits don't think your definition of appropriate in this
context is correct.

------
BrissyCoder
People at the places I work keep memeing links to blog posts along the lines
of "OOP is dead. Functional programming is the new king".

Yet to see a single line of a functional language in production.

As other commenters have mentioned most decent modern lanuages are multi-
paradigm.

~~~
fheld
might be interesting for you, Lips in production:

[https://tech.grammarly.com/blog/running-lisp-in-
production](https://tech.grammarly.com/blog/running-lisp-in-production)

~~~
capdeck
I used to work in a company that had part of the process written in Lisp and
it was in true production. Once the (fp) guy left the company everyone else
had to support that code. What a nightmare that was. No one wanted to touch it
with a ten foot pole. Should we had another FP guru in our midst, that may
have turned out differently. But everyone was in agreement that that part
needs to be rewritten in a language that everyone else is using. In real life
- if most stuff in your company is FP and there is plenty of expertise to go
around - do FP. If not - do not. :-)

~~~
Qwertystop
Arguably, if you knew that A: there was code in Lisp and B: only one person
knew how to support it, they should have either rewritten it while the one who
understood it was still there, or had more people learn Lisp, or hired more
people who knew Lisp. It shouldn't have been allowed to reach the point where
someone quit without anyone else having a clue.

------
rafaelvasco
I feel it's because functional programming is not a general application
methodology. It excels at several idioms that we use as programmers but I feel
it's something more specialized and niche then OO programming. I personally
use OO as a base and iterate from there, using Functional idioms where is
applicable. Some classes of programs can be described in its entirety in
functional terms, but they're a small portion compared to the whole.
Everything can be expressed in OO idiom, even if it's not the optimum way; I
don't know if the same can be said of Functional. Would like to know more;

~~~
yogthos
I've been working with FP for around a decade now, and anything you can
express in OO can be expressed with FP just as easily and often in a much
simpler and more easily maintainable fashion. I copresented a talk on how my
team uses FP in our platform if you're interested in more details:

[https://www.youtube.com/watch?v=IekPZpfbdaI](https://www.youtube.com/watch?v=IekPZpfbdaI)

------
didibus
Do not try and make the computer functional. That's impossible. Instead, only
realize the truth... THERE IS NO COMPUTER. Then you will see that it not the
computer that is functional, it is yourself.

------
Sniffnoy
Hm, so, Feldman claims that it wasn't the OO that made C++ popular, but rather
the other features added on top of it that C with Classes didn't have. But one
of those features that C with Classes didn't have was virtual functions.
Without that, it's not clear how OO C with Classes really is. This potentially
undermines Feldman's argument, because he hasn't ruled out the possibility
that virtual functions were one of the key factors in C++'s success.

------
typedef_struct
These things are not all-or-nothing.

I have one compute device, the GPU, that I program with its language (eg GLSL,
OpenCL).

I have another compute device, the CPU, that I program with its language (eg
C, C++).

I have code to control these devices, that mostly handles scheduling and
waiting on the results of these computations (as well as network traffic and
user input), and I program that in a language that supports functional style
(eg C#, TypeScript).

------
dzonga
as someone who made my first SPA, using Elm & met the presenter once in NY.
functional programming is elegant and nice. but practicality is another
different matter. for it, to be the norm, it has to have 10x advantages over
the status quo. on the frontend, part JS already offers some features of
functional programming, with some imperative parts. On the backend, none of
the functional languages you would want to use such as Ocaml match say the
ecosystems of Python, Java, Node.js & .Net world.Hell even F# which is an
excellent language, is treated like the bastard step son of Microsoft

~~~
iLemming
Clojure & Clojurescript are very practical and pragmatic. I've been writing
Javascript for quite long time, I have tried and used most *script languages:
Coffescript, Typescript, Livescript, Gorillascript. I've looked into Elm,
ReasonML and Purescript. Clojurescript today has is the most balanced one - it
gives you real productivity boost, simple FFI, different bundling options,
gradual typing and generative testing, code that is clean, concise and very
easy to reason about. It is a shame people dismiss it for some dogmatic
reasons even without given it a try.

------
flowerlad
Functional programming is not new, it has been around for many decades. The
reason it didn't catch on is because it doesn't map very well to how our brain
works. Human brains are object oriented, so OOP is very easy to grasp.

The real question is, why are people now taking a second look at functional
programming. And the answer is Moore's law. Moore's law is coming to and end,
and CPUs are not getting faster. Instead they are adding more and more cores.
To take advantage of lots of cores you need concurrency. OOP is not very
concurrency-friendly because objects have state, and to avoid corrupting state
in a multi-threaded environment you need locks, and locks reduce concurrency.
Functional programming doesn't have state, so you don't need locks, so you can
get better concurrency.

~~~
cuddlecake
> Human brains are object oriented, so OOP is very easy to grasp.

Can I cite you on this? Because I have only ever seen this explained in
Programming 101, where Java is the language they teach.

I wonder where this sentiment comes from. I imagine it came from marketing.

~~~
McWobbleston
Yeah I've gotta be honest the first few times I was taught OOP I couldn't
quite grasp the purpose. I like it now for encapsulation of state, but
generally I find it much easier to deal with records + pure functions as
building blocks.

------
asutekku
It might be nice to some but man if you are not required to learn a dozen
different paradigms to use it. It’s expensive (harder to teach) and not
intuitive for a beginner.

------
zygimantasdev
Maybe Elm itself is a killer app, but certainly not elm-ui. I don't think
Datomic is a killer app too. Its certainly not comparable to Rails/OSes at
scale

~~~
vim-guru
Sorry, but I think you need to take another look at Datomic

~~~
mac01021
Datomic is really neat but, for any system that operates at significant scale,
I think the approximately-10-billion-datom capacity is probably too great a
concern.

For example: Stop&Shop has 415 stores, and

    
    
      365 days * 415 stores * 100 purchases per day * 50 datoms per purchase
    

will fill up your system in 14 years without even spending datoms on inventory
and the like. And that "100 purchases per day" could be low by a factor of 5
or 10 (I don't know).

~~~
dustingetz
Datomic shards naturally though – Datomic queries are functions that take
database values as input. You can pass multiple database values as input and
join across them. This is a first-class construct. I don't remember if this
works in Cloud but it definitely works in onprem.

------
hosh
Part of Python's strength is in its ecosystem related to machine learning.
That, and it is a popular language to teach to kids these days.

------
pbreit
To this newbie, procedural is ===SO=== much easier to understand.

~~~
iLemming
Actually it's the other way around. For someone who is not exposed to
programming at all, it is much easier to pick up a language like Clojure. This
is not merely my opinion - I have seen it multiple times, with different
people.

Julie Moronuki who never had any exposure to programming at all and has a
degree in linguistics decided to learn Haskell as her first programming
language, just as an experiment. Not only she did manage to learn Haskell and
become an expert, she co-authored one of the best selling Haskell books. I
remember her saying that after Haskell other (more traditional) languages
looked extremely confusing and weird to her.

~~~
alisiddiq
I only had experience of coding in Matlab in university, and started learning
Clojure in my first job. It was very intuitive.

------
hootbootscoot
So, I DO believe that this earnest high-level programmer is very earnest, I
just don't think that he is starting with a full deck of cards. The manner in
which he quickly brings up "C" and it's "killer app" being systems
programming, and then jumps into the Javascript morass, it sort of suggests
that he should start with first principles on how computers function.

Computers are imperative devices. I don't think that a for-loop or a map
function fundamentally impede understanding of this concept. I DO think that
pretending that languages that run on top of Virtual Machines need to
aknowledge their dependency heirarchy and stop attempting to "level/equalize"
the languages in question. One would use C in order to write a VM like V8 that
then could run your scripting language. The core of Autocad is surely C++ with
some lower-level C (and possibly assembler) regardless of whichever scripting
language has then been implemented inside of this codebase, again, on a
virtual machine.

The Operating System is a virtual machine. The memory management subsystem is
a virtual machine.

Javascript runs on browsers. (Or V8, but then that was originally the JS
engine of a browser) and has inherent flaws (lack of type system, for one)
that limit it's use in specifying/driving code generation that could provide
lower level functionality. THAT is the essential issue. VHDL and Verilog can
specify digital logic up to a certain level of abstraction. C++ and C code
generation frameworks can be used to generate HDL code to some degree, to the
degree that libraries make them aware of the lower-level constructs such HDL's
work in. I have no doubt that Pythons MyHDL presents a very low learning curve
in terms of having the Python interface, but then the developer needs to be
aware of what sort of HDL MyHDL will output and how it will actually perform
in synthesis and on a real FPGA.

We don't need MORE layers of opaque abstraction. People need to learn more
about how computers work as abstraction doesn't obviate the need to know how
the lower levels work in order to optimize ones higher level code.

I can provide specific examples regarding libraries that purport to provide a
somewhat blackbox interface, but upon deeper examination DO, in fact, require
intimate knowledge of what is inside.

Abstractions are imperfect human attempts to separate concerns and they are
temporary and social membranes.

Now, having said all of this: If a person ran a Symbolics Lisp system, such a
system was holistic and the higher-level Lisp programmer could drill down into
anything in the system and modify it or see how it was made.

I digress... read the source code for any magical black boxes you are thinking
of employing in your work.

~~~
mac01021
Some of those sources are pretty daunting...

~~~
hootbootscoot
indeed... hence the desire for blackboxes.

leaky abstractions require the occasional lid-lifting... and all abstractions
have a tendency to leak somewhere or other, especially if they attempt to be
all encompassing.

I think FP is certainly a viable high-level specification but ultimately there
is lower-level code 'getting stuff done' (lol, "side effects") One has to be
at least roughly aware of HOW ones specification is getting implemented in
order to solve problems that arise and in order to optimize.

This is all the more compelling reason to cease this relentless push to "cram
more stuff down the tubes" or "add more layers to the stack"

I honestly think that we need to return to KIS/KISS (keeping it simple)

SIMPLIFY and remove extraneous stuff that prevents one from having a total
mental model of what is happening.

------
pts_
Because it is difficult and funding flows to workflows which treat software
like brick laying.

------
sheeshkebab
‘cause software development is as far away from math as plumbing. there, don’t
need to watch the video anymore.

------
austincheney
I cannot watch the video as youtube is blocked at my office. But I can answer
the premise.

OO is the norm because it is has immediate business value and is easier to
teach to young people. Most programmers in the work place are produced from
educational institutions. Educational institutions has competitive
quantifiable

FP requires thinking in terms of calculus. This isn't hard, personally I find
it much faster and easier. Thinking in calculus does require some maturity,
and possibly some analytical experience, young students may not find
comfortable.

\---

This question can also be answered in terms of scale.

FP reinforces simplicity. Simplicity requires extra effort, often through
refactoring, in order to scale or allow extension for future requirements.
This is a mature approach that allows a clearer path forward during
maintenance and enhancements, but it isn't free.

OO scales immediately with minimal effort. OO, particularly inheritance,
strongly reinforces complexity, but scale is easily and immediately available.
This is great until it isn't.

