
Why no one uses functional languages (1998) [pdf] - todsacerdoti
https://dl.acm.org/doi/pdf/10.1145/286385.286387
======
noelwelsh
FP is going mainstream. In the same way that mainstream OO wasn't pure OO in
the manner of Smalltalk but instead hybrid languages like C++ and Java (and
more recently Python), mainstream FP isn't Haskell but languages like JS (w/
Typescript), Scala, Kotlin, Rust, Swift, and friends taking core ideas from
academic FP and presenting them in way that works better for industry.

~~~
IshKebab
Mmm maybe, but none of those languages (afaik) have explicitly pure functions
which is the keystone of functional programming.

~~~
dirkt
It's really really hard to get things right with pure functions. Haskell
struggled with this for decades. You can't expect to be able to import this in
some random language and just make it work.

So random languages just pick what they like (lambda expressions, weaker forms
of algebraic data types, sometimes the complete typeclass concept, various
forms of Monads from "unnecessarily specialized because whoever picked it
didn't understand it" to "properly done"0.

And while having pure functions certainly forces you to get things right, you
don't need to do this when copying ideas. And there are functional languages
(some very old, like Lisp) that never had pure functions in the first places.

------
_hardwaregeek
Tooling is such a huge factor. I'd love a functional language that had build
tools as nice as rustup and cargo.

Indeed I'd place Rust as an example of a language that got it right. Sure,
Rust isn't functional, but it's confusing on first usage, so close enough :D

In all seriousness, the big issue that functional languages have to get over
is that most programmers are not great mathematicians, so declarative
programming feels very weird and confusing. With Rust the big issue is all the
rules about memory. How did Rust solve it?

For one, they made the language as familiar as possible. Rust's syntax is
extremely close to C/C++, even if the semantics aren't. As much as PL people
claim syntax doesn't matter, it does. ReasonML is a project with a similar
philosophy.

Next, they put a lot of work into documentation and explanations, especially
at the compiler level. Rust's compiler messages are fantastic and often
anticipate beginner mistakes. I'd love a functional language that detects when
the code looks kinda imperative and gently guides you towards the functional
option.

And finally, they had a killer app like Wadler mentions. Performant memory
safety is pretty hard to argue against. Even a manager could see the potential
upsides. I wonder what sort of killer app one could create for functional
languages? Reason with ReasonReact could have robust UI as one, but that's
still not as good of a sell as performant memory safety.

~~~
gridlockd
Performant memory safety is not that big of a feature. GCs are fast enough
unless you have real time constraints.

If have real time constraints, you probably do not care about memory safety
that much, unless your system is safety critical.

If your system is safety critical, you are using lots of tooling for
validation beyond memory safety - and probably some form of model based code
generation. That tooling just does not exist for newcomer languages.

~~~
fauigerzigerk
Tracing GCs are only fast and predictable enough if you devote roughly half of
your memory and a significant share of CPU/battery to them.

And of course garbage collection is only part of what's needed for memory
safety.

~~~
thu2111
That's not been true for a while.

GCs like ZGC can handle tiny heaps with no pauses, pretty minimal heap wastage
and a ~10% throughput hit vs a more middle of the road GC. You're thinking of
the Go GC and assuming they must be all like that.

~~~
fauigerzigerk
I'll be very happy once claims about improved GC performance turn into actual
reality for my workloads.

What is "pretty minimal heap wastage"?

As far as I can see, ZGC (which is currently marked as experimental) doesn't
give any specific performance guarantees. It'll be interesting to try.

 _" How much headroom is needed very much depends on the allocation rate and
the live-set size of the application. In general, the more memory you give to
ZGC the better."_

[https://docs.oracle.com/en/java/javase/13/gctuning/z-garbage...](https://docs.oracle.com/en/java/javase/13/gctuning/z-garbage-
collector1.html#GUID-A5A42691-095E-47BA-B6DC-FB4E5FAA43D0)

~~~
thu2111
Heap wastage is tunable vs CPU time, but it's less than the 100% go uses. If
you have spare RAM your app will run faster, is the usual tradeoff.

------
pritambarhate
I think languages by themselves rarely become popular. There is some killer
feature that a language offers which makes a certain class of problems very
easy to solve. For example, Rails did it for Ruby, Go's stdlib makes it very
easy to write performant network services, Java's promise of platform-
independent code, huge stdlib and a free compiler and (later) free IDEs when
almost all other compilers and IDEs were paid, C# - Microsoft's deeply
integrated ecosystem, Rust's memory safety and the promise of fearless
concurrency.

Functional languages are lacking such killer features which makes them 10x
more productive for widely faced problems. I am learning Clojure to learn more
about the functional paradigm, but I don't see any particular type of software
that I could do with it which I couldn't achieve with Java, Go, JS or Python
all of which I already know well enough.

~~~
nilkn
I think you could argue that type-safe STM is such a feature for Haskell. It's
something that I really miss when using threads or async essentially anywhere
else. I would probably jump for Haskell over Rust as a result for heavily
concurrent or multithreaded programs. Rust is memory safe, but it can't
express purity and it can't enforce that STM transactions should be safely
retryable.

I would also argue that Elm offers close to a 10x factor for certain types of
front-end web applications. It's a very closed system, which is a matter of
great controversy, but in areas where you can exist within that system it is a
dramatic leap forward compared to anything else in my experience.

If you consider Erlang/Elixir functional languages, I would argue that BEAM
can offer close to a 10x factor for certain types of distributed or concurrent
applications as well.

You mentioned Clojure, though, and I don't know what the killer 10x feature
would be there.

------
jierenchen
We should draw a distinction between FP as religion and FP as tool kit.

FP as religion has failed to gain acceptance because it imposes too much cost
on the user. I have to rethink my whole stack in terms of category theory AND
deal with your terrible ecosystem? Hard pass.

FP as toolkit, on the other hand, has been a smashing success. Most of the
core ideas of FP are mainstream now and some of the latest advances in non-FP
ecosystems (React, for example) are based on FP ideas.

~~~
eru
FP ideas have been seeping into the mainstream for quite some time now.

The oldest: GC was originally invented for Lisp. It's common now.

Type inference was big in FP before it made the jump to language like Java or
C++ much more recently.

Generics were a natural idea in a typed FP context. Mainstream languages got
them, now.

I'm looking forward to algebraic data types becoming really common. (The
simplest explanation is that they are C-style unions with tags to tell you
which case you are in. The compiler enforces that the tags correspond to how
you use them.) Some mainstream languages are starting to add them.

~~~
jierenchen
> The oldest: GC was originally invented for Lisp. It's common now.

LISP was so ahead of its time, its parents still haven't met yet. Not very FP,
but another gem from SBCL: saving and restoring program state for later use.
Now there's the CRIU [0] project for doing this with Linux and Docker
containers.

> I'm looking forward to algebraic data types becoming really common.

I'm not too familiar with the full scope of algebraic data types. Wondering:
does Typescript have this or is it still missing a few key components? Really
like how it has Union types, which I wish Scala would have.

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

~~~
eru
Algebraic data structures mostly just means union types.

(That's the + in the algebra. The * comes from bundling multiple values
together, like in a tuple or in a C-style record, virtually all languages
already have that.)

There's also Generalized Algebraic Datatypes (GADT). They are a bit more
complicated. So I don't expect mainstream languages to pick them up anytime
soon.

About GC: you _can_ do pure functional programming without a GC. But it
requires lots of big guns from more advanced theory. (Mostly stuff like linear
typing.) However imperative programming without a GC is comparatively simple.

So it's no wonder that historically, GC was invented for FP first, and GC-free
FP was only discovered later.

(And for general CRUD or web programming, or basically anything outside of low
level systems programming, GC is more productive in terms of programmer time
than other approaches. At least given currently known techniques.)

------
asp_net
A more recent view: "Who Cares About Functional Programming?"

[https://thomasbandt.com/who-cares-about-functional-
programmi...](https://thomasbandt.com/who-cares-about-functional-programming)

------
csours
> 'Much of the attractiveness of Java has little to do with the language
> itself, but with the associated libraries ... (Much of the unattractiveness
> is due to the same libraries)'

------
wiineeth
Jane street is a very successful company that uses Ocaml for everything. Any
other companies like that?

~~~
ccortes
Brazilian nubank, they mainly use clojure

~~~
mercer
And they recently acquired Plataformatec, the company behind Elixir.

------
anonytrary
Programs are incentivized by need, and businesses and users are the primary
consumers of programs. If FP and OOP both satisfy those needs nearly
indistinguishably, but one of them is easier for the vast majority of
programmers, then guess which one everyone is going to use?

Working for a company has taught me that people will try to get away with
doing as little as possible when it comes to satisfying a business need.

~~~
rumanator
> Working for a company has taught me that people will try to get away with
> doing as little as possible when it comes to satisfying a business need.

Aka productivity.

~~~
tluyben2
Sure but skipping all best practices in favor of fast delivery might bite you
later on.

~~~
eru
Functional programming is mostly touted as being able to keep productivity up
in the long term.

(And detractors mostly complain that it takes too long to get started, not
that the long term is unmaintainable.)

------
fulafel
I think in the current crop of languages, the "functional language" concept
has shifted its purpouse:

1 GP languages have adopted FP enabling features, so we can do FP just fine in
many mainstream languages, and it is infact very common (see eg React, Ramda
popularity on frontend and many recent FP features in Kotlin, Java, C++, etc).

2 At the same time FP leaning languages are more popular than ever, to the
point it would be ridiculous to claim "nobody uses functional languages" given
the visible positions of Clojure, Erlang/Elixir, ReasonML/Ocaml, F#, Scala,
etc on the scene.

I think adding 1+2 together tells us that FP is on a real streak. People
choose use FP langauges, not because of their capabilities, but because of the
mindsets, ecosystems and culture they promote, along with promising to
consistently pave the way for FP problem solving instead of often falling back
to imperative.

~~~
thu2111
(1) keeps cropping up but these new languages are hardly "FP" or even using
"FP" features. I think we give FP research way too much credit.

Pure functions? No, none of those languages can even express the concept
except maybe C++ with the const keyword (which is as old as Haskell itself).

Immutable data structures? Even very modern languages like Kotlin don't really
have them. You can define a data structure where the fields are immutable
after construction but it's not transitive. There are read only collections
but not immutable collections, without doing extra work. Maybe immutable
collections will turn up at some point, there's a proposal to add them, but
it'll just be a library not a language feature.

Type inference? New languages don't use full blown Hindley-Milner TI, they do
much more limited TI that's designed to strike a balance between readable
error messages, documented APIs, IDE performance and so on. Meanwhile the
concept of TI is obvious and required no inspiration from anywhere - anyone
who ever looked at source code will be struck by the repetition required.

Generics? C++ templates started being discussed in 1985, and it's again a
pretty obvious concept that would occur to anyone who wanted to offer type
safe collections.

I honestly can't see the huge impact FP supposedly had on mainstream
programming. All the ideas its advocates try to claim for their own are either
not used, or are obvious but usually not implemented the same way. My guess is
if Haskell had never existed modern languages would look exactly the same.

~~~
fulafel
Many FP languages also lack these.

Try these: closures, first class functions, garbage collection, anonymous
functions.

~~~
thu2111
All except first class functions are found in Java. I don't think many people
would claim Java is an FP language.

~~~
fulafel
I think the discussion is in danger of going the way of a Möbius strip...
Language features originating in FP have been adopted by GP languages, which
was the point :)

~~~
thu2111
But those features were found in Java 1.0 so the influence can't be that
strong, given it was heavily advertised as an object oriented language at the
time.

~~~
fulafel
From the list, only GC was in early Java. GC was popularized by Lisp (was
added in the 60s?) and other FP languages like ML (had gc from the start in
1973) decades before.

------
andi999
Maybe another reason is: there is two kinds of software, one is programms
which process input data and transform them to output data. And then there is
software which operates hardware, like steering of the stepper motors of a
robot, or the firmware of a washing machine. Functional languages are
(rightfully) immediately dismissed for these kinds of problems. Then there is
a grey zone: GUI programming, this is almost hardware progamming and FP have
been trying but not doing well in this domain (might be wrong though).
Hardware programming doesnt come up often IT departments, so maybe this is a
blind spot, but basically you are loosing a big share of the market.

Ps: something special might be with the erlang telco system, but i have no
idea about it

~~~
didibus
This is true, but it depends which language we're talking about. There are two
definitions to FP. The stricter one is about having immutable data and pure
functions. In that one, it's fundamentally only a computing language, not a
programming language, in that by definition it cannot tell the computer to
perform any action, as purity implies no side effects.

That means you always need an additional layer which then drives the side
effect. For a lot of programs, that adds some complexity to the program. The
programmer has to model their side effects with this layer in mind. The layer
means the programmer loses control over the fine grained details of the side
effect as well, which might hurt performance, or make certain things more
difficult.

That said, there are impure FP languages. Where you can program the machine to
do whatever you want, and also make computation functionally with immutable
data and pure functions.

Clojure is such a language. I'm very biased towards it FYI, as it's the
language I enjoy most as of now. But I think it's important to bring it up.
Defaulting to immutable and pure computations, but letting you perform all
kinds of controlled mutation and side effect really seems like a good future
to me.

Rust in a sense is pretty similar. While it doesn't use a strict functional
sense of immutability and purity of data and functions. The borrow checker
tracks all changes to data and assigns ownership of access, which is kind of
similar to immutability and purity. Yet it lets you do unsafe things when
required, often for interopping with peripherals and the machine itself.

Erlang like you mentioned is another example of this.

I think those languages might have a better future, and are slowly starting to
pick up on popularity. Even in JS for example, lots of people are adopting
this style. So if not a programming language, at least the paradigm seems to
become more and more popular.

As an aside, for example, there is a Clojure dialect called ferret
[https://ferret-lang.org/](https://ferret-lang.org/) which is designed for use
on microcontrollers. It has immutable data structures and support all the
functional aspects of Clojure, yet targets real time control applications.

~~~
eru
Immutable data and pure functions aren't as big as an obstacle as you might
think.

Uniqueness types allow you to use immutable variables and still directly model
side effects and state changes. Arguably better than mutable variables do so.

(Haskell is not a good language for that kind of control. Though you could
make a language that looks quite a lot like Haskell that fits. And people have
done so.)

~~~
didibus
Isn't uniqueness typing just a more restrictive form to Rust's linear types?
And since Rust itself is often forced to rely on unsafe blocks for programming
tasks (as opposed to computing tasks), then wouldn't that be true of a
language with uniqueness types as well?

Also, I'm guessing you mean Clean or Miranda? Any idea why they aren't more
popular than Haskell? Or why Haskell doesn't adopt uniqueness typing?

~~~
eru
Linear types and uniqueness typing are so close together that people often mix
them up. Yes, that's basically what I am talking about.

For general usage monads are much easier to deal with than Clean's "pass
around the world" system. (I only used Clean for a bit, but haven't used
Miranda, yet.) However, linear types for Haskell have been in the works for
some time. See eg
[https://www.reddit.com/r/haskell/comments/dpr276/what_is_the...](https://www.reddit.com/r/haskell/comments/dpr276/what_is_the_status_of_ghc_linear_types/)

(Similarly, GHC now support strict Haskell, too, on a per module basis.)

Uniqueness typing shines when you want to split up your 'real-world' object,
so you can eg manipulate individual memory cells or ports etc independently.

Rust goes into unsafe mode for multiple reasons. You could eliminate most of
those, if you were willing to take the complexity of dependent types. Ie more
or less that means the programmer taking on a greater burden of proving code
to be safe to the compiler; instead of relying on Rust's more automatic but
conservative system.

------
mrobot
Just a couple gripes, they seem like non-problems today:

Training -- Schools should be covering the training problem in this PDF, and i
think that would help a lot.

Availability -- GHC is no longer an 'adventure' to install

Packagability -- Can't you just build standalone programs with most FLs?

Popularity -- Aren't they getting more popular?

"They don't get it" \-- I don't think the example given of "i need some
documentation and stability" applies anymore.

~~~
gerikson
> Training -- Schools should be covering the training problem in this PDF, and
> i think that would help a lot.

This just raises a chicken-and-egg problem: why should schools (primary,
secondary or tertiary) teach a language that is not "mainstream"?

Is there a language that is more "functional" than Python or Lua that's
designed to be a teaching language?

------
dloss
"[...] this allows Haskell to be used as a scripting language for Microsoft's
Internet Explorer web browser". Interesting. Never heard of that.

[https://www.microsoft.com/en-
us/research/publication/scripti...](https://www.microsoft.com/en-
us/research/publication/scripting-com-components-haskell/)

EDIT: Add link

~~~
LockAndLol
If WASM had access to the DOM, I imagine we'd start seeing a replacement of JS
and a democratization of web languages. I however dread the day I get to read
a full-stack C/C++ webpage.

~~~
dep_b
You can get a full-stack .net webpage with Blazor already

~~~
tasogare
I’ve been playing with it in the last two days, and while it’s a bit annoying
to have to deal with CSS for UI instead of XAML and the recompilation cycle,
the framework is impressive. A lot of things can be done without touching
JavaScript directly, and when in need the interop works well.

------
randomsearch
Conjecture: programming will become split between “just build my app” and an
elite set of programmers who do the most demanding work, eg cloud
infrastructure for Amazon, Google etc. The latter will mostly use FP, the
former will use JS et al.

I think the reason most coders (and I include myself) don’t use FP is that we
don’t have enough training in it, we often don’t have a strong mathematical
background, and we have an imperative mindset. It’s harder to learn those
things, it’s a different way of thinking than we use in our day to day lives -
much like mathematics is difficult for most people to grasp, because it
doesn’t come naturally to them. Humans are not theorem provers.

As competition for jobs soars and wages plummet (hello, remote work
revolution!), more of the top X% of coders will be forced to learn FP to
maintain their competitive advantage, and you’ll end up with a lot more people
using it. Some of that will trickle down, but most of us will be writing JS
rather than Haskell for the rest of our lives.

~~~
pritambarhate
>> an elite set of programmers who do the most demanding work, eg cloud
infrastructure for Amazon, Google etc. The latter will mostly use FP, the
former will use JS et al.

I don't think this is true. In fact Go seems to be at the front and center of
most of the Cloud Native infrastructure projects such as Kubernetes, Docker,
Prometheus, and many others.

~~~
randomsearch
Wasn't a comment on the status quo, but rather the future.

I think the Go trend confirms my point: an isolated group of programmers have
been able to adopt Go for that kind of infrastructure, but outside of those
shops most people are quite determined never to use Go and rant about it a
lot.

In the same way, Go will be replaced by FP and app developers will not go near
it.

------
dotemacs
Here is a list of companies using using Clojure & ClojureScript:

[https://clojure.org/community/companies](https://clojure.org/community/companies)

~~~
random32840
Lists like this strike me as somewhat meaningless. Those companies probably
also use bash scripts, hardly represents a significant chunk of the product.
How _much_ of their codebase is in Clojure?

------
lifeisstillgood
We have had these discussions for many years (even pg wrote about Blub IIRC),
but the real reason (IMO) is that _language choice matters far less than we
like to think_.

What business we choose to build with the language will outweighs the impact
of language choice a hundredfold.

Our decisions on CI/CD, our discipline on building clean architecture with
whatever language we like matters more.

In short, the things that make development a productive and enjoyable
experience are linked less to the language than to the skill and
professionalism of the development team - and "weird" languages tend to have
more skilled and professional developers working in them, so the causality /
correlation tends to get mixed up.

The upshot is, worry less about learning Lisp at work, and more about fighting
your corner on why we should rewrite that 3,000 line monster engine module
that we all call each day but making changes to it is a nightmare.

~~~
bad_user
> " _What business we choose to build with the language will outweighs the
> impact of language choice a hundredfold._ "

This is on one hand a truism that actually adds nothing to the discussion. In
achieving success, of course the business matters. Even more so the best
simplifications come from understanding the business domain, not from the
tools used.

\---

On the other hand it's also patently false. Build a web browser in Ruby. Build
an operating system in JavaScript. Build your average web app in C/C++.

The tools used have inherent limits, being optimized for certain domains and
not others, can make us more productive, can lower the defect rate and can
keep us happy enough to see the project released.

In my experience _some_ static FP languages can lower the defect rate, can
make certain problems easier to tackle, can make the code easier to maintain
and refactor and due to performance being reasonable, they tend to be more
general purpose than other languages — this trait being a consequence of
static typing, making performance good enough, coupled with the languages
themselves still being high level enough.

\---

> " _learning Lisp at work_ "

Ah, I see the problem ... many of you thought Lisp is some sort of secret
sauce. It isn't, it never was, Lisp is a freaking mess.

The real problem in our industry is not applying the scientific method for
advancing it. We thus rely on fashion and salesmen to sell us magic pills.

~~~
pron
> On the other hand it's also patently false.

The sentence "language choice matters far less than we like to think", which
means something like "switching between _most_ pairs of languages in most
situations doesn't make a big difference", and your examples which mean "there
exist pairs of languages as well as situations where switching between them
makes a big difference" are completely compatible.

In fact, I would say that the latter is not interesting because of course we
know there are situations where high-performance languages are more or less
appropriate, but the interesting question is whether languages that have
similar aims and performance, and differ mostly in their linguistic features
make a big difference.

> In my experience

Unfortunately, people will also support the effectiveness of homeopathic
medicine based on their experience, and much more enthusiastically. I'm not
doubting your sincerity, nor even the facts of your situation, but this
doesn't count as evidence. On the other hand, the fact that different
languages are tried in different places, in an industry with strong selective
pressures, the fact that no single language or paradigm completely overtakes
all others is evidence in favor of there _not_ being a very big bottom-line
impact.

~~~
willtim
> the fact that no single language or paradigm completely overtakes all others
> is evidence in favor of there not being a very big bottom-line impact.

Or perhaps because no paradigm is universally applicable to all cases. There
will be a bottom line impact if the wrong tool is picked for the job.

~~~
pron
Sure, but what I'm saying applies when comparing different languages that
_are_ reasonable choices for a given domain.

Anyway, this isn't a poll, and while opinions -- one way or another -- shape
the _popular_ opinion, they don't settle the empirical question.

------
carapace
FWIW if you're not using algebra to write your software you're not quite doing
FP just yet.

Doing math on software to make new software is the overlooked part of FP in my
opinion. You hear about "first-class functions" and "referential transparency"
a lot but not as much about "equational reasoning".

------
threatofrain
I like framing FP and OO as technologies, and technology takes money and time
to improve. The technological aspect comes from the ability of language and
IDE teams to translate your programming style into an efficient program.

------
RcouF1uZ4gsC
I think there is a fundamental reason. The computer is inherently mutable. As
a result, the basic abstractions of operating systems are mutable.

Thus, except for nicely contained problems such a text transformation (see
Pandoc for an awesume use of Haskel), interfacing with the computer and the
rest of the world becomes an impedence mismatch. Yes, monads are awesome, but
you shouldn't need a math PhD, to print "Hello World" to the screen and
understand what it is doing.

The other issue is performance. Yes, performance is generally good enough,
except when it is not, and when it is not, it is not obvious why you are
having issues or what you can do to fix them. This once again comes to the
abstraction mismatch between the mutable computer and the pure functional
language.

~~~
alipang
Monads are among the simplest abstractions you can find in computing. Compared
to almost anything you need to understand in software development (how the
hell do I make webpack do the thing I need?) they're ridiculously easy.

The fact that so many devs are scared of monads and believe outrageously silly
things like you need a math phd to understand them seems to be similar to
being afraid of drinking dihydrogen monoxide. Even though it's only water, it
has a complicated sounding scary name, so it must be bad.

~~~
saagarjha
There’s also a huge number of people who are fairly bad at explaining what
exactly it is. I don’t think I should fault them, per se, it’s sort of trying
to explain why water is wet.

------
dang
See also from 2014:
[https://news.ycombinator.com/item?id=8082728](https://news.ycombinator.com/item?id=8082728)

------
femto113
Interestingly written 3 years after the introduction of a functional language
that eventually went on to become the most popular language there is.

~~~
LockAndLol
Which language are you talking about?

~~~
motogpjimbo
The one that controls the web application you're currently using.

~~~
SCdF
Controls the comment collapsing, everything else doesn't require JS.

------
thdrdt
My experience so far with functional languages (as an OOP-er):

* After a whole evening studying I am able to subtract 1 from 5.

* After spending hours checking what is wrong it just does not compile.

* After the hello world part there are no libraries that can be used for web development.

* Lack of good documentation.

* Lack of good tutorials.

But lately I discovered Elixir and I believe this could be a language that
would change my mind about functional programming. Phoenix looks great and
LiveView matches .NET Blazor (which I use a lot).

But then there is still the question: why even bother using a functional
language? Because I have little experience in functional languages this is
hard to answer for me.

Edit: _" After a whole evening studying I am able to subtract 1 from 5."_ I
should have formulated this different. What I meant was: sometimes you follow
a very long tutorial about a functional language. You will learn a lot about
the syntax but in the end when you try to use it, you will only get to the
basics of writing a function that subtracts x from y.

~~~
StreamBright
Funnily enough 5 - 1 works almost in every language the same way. Maybe with a
different syntax but I cannot think about any FP language where I cannot do
it.

~~~
smabie
I mean Lisp. But It's pretty debatable whether Lisps are functional languages.
Imo, static typing is a requirement, at least culturally.

~~~
eru
As far as I can tell at the International Conference on Functional Programming
the Schemers are treated as full member of the functional programming
community, despite lacking static types.

Static types are neat, and FP people tend to really like them, but I wouldn't
call them a strict requirement even culturally.

You can make a statically typed Lisp, of course. Just like you can make a
dynamically typed ML-like language. Haskell even sort-of supports that. See
[https://gitlab.haskell.org/ghc/ghc/-/wikis/defer-errors-
to-r...](https://gitlab.haskell.org/ghc/ghc/-/wikis/defer-errors-to-runtime)

