Why are functional languages usually magnitudes slower than procedural languages (C, C++, etc)?

>luajit is magnitudes slower than C
i'm lmaoing at your life

Chicken Scheme compiles to native code by way of C.

it seems easier to convert imperative statements on to say x86 or ARM

Because your processor isn't functional *dabs*

functional programming requires different, slower data structures compared to imperative programming
non-template generics require unpacking of the datatype
The reason that functional programming is nice is because immutable by default data structures allow for easy multithreading, as you don't have to worry about race conditions, etc.
also common lisp is not functional

Attached: 1539536882544.png (418x108, 7K)

Tail recursion is very nice as well when supported by the compiler or interpreter.
>no stack overflows ever again

Can you show an example of this?

>The reason that functional programming is nice is because immutable by default data structures allow for easy multithreading, as you don't have to worry about race conditions, etc.
Honestly what is the point of easier multithreading if the whole thing runs worse anyways?

Which is where procedural languages get it right. It's okay to have mutable data if you want, but when you do multi-threading just stick to something like message passing to keep that part safe, etc.

Because they are comfy.

Depends on your use-case, performance isn't the only relevant factor (maintainability, extensibility, etc.) and many programs don't need to be high-performance: if the program takes 2ms longer to run, but is much easier to write, reason about, and modify, then the trade-off is acceptable.

This kill haskell autism in 2007, muh cores but too slow.

Pure functional languages can't do hashtable or Array lookup/change in O(1) pure functional programming is slow in vital datastructures.

They an do O(1) lookups
They can't do O(1) puts/changes since you would need to change the state of the table.

The real source of slowness is dynamic "typing".
Statically typed functional languages can be compiled to machine code much more easily, but none is as fast as well written modern C++ or Fortran. This is because imperative languages, by their nature, are easier to translate and optimize.
However, good progress has been made in terms of compilers, so we can expect high performance from purely functional languages too in the future, especially statically typed ones.

In the case of Haskell it all comes down non-strict evaluation. Letting the compiler decided when to execute things makes it really hard to reason about code speed optimization.

Lazy eval was a mistake.

There are current lower-bounds that suggest purely functional languages are slower than imperative languages [1] [2].

[1] Amir M. Ben-Amram and Zvi Galil. On pointers versus addresses. Journal of the ACM, 39(3):617–648, July 1992.
[2] Nicholas Pippenger. Pure versus impure Lisp. In ACM Symposium on Principles of Programming Languages, pages 104–109, January 1996.

Why are Functional languages (Lisp, Haskell, OCaml)) orders of magnitude faster than procedural languages (Python, Ruby, Perl) Jow Forums ?

Compiled/JIT vs Interpreted or very immature JIT.

>> What are persistent data structures.

And this is why C and C++ are fast. Extremely mature compilers, and additions to the language specifically made to make the compiler's job easier.

>down to mere hundreds of milliseconds or smaller
>mere hundreds of milliseconds

Haskell is almost as old as C++
LISP predates C

Maybe PhD professors really don't make good compilers.

>Because machine code is procedu

fpbp

except for the cases where tail recursion cant happen.

Memory copying and the gc pressure that comes with it when you exclusively use immutable data structures.

A functional program is far easier to prove correct. The primary goal of your software might be "have no bugs" with performance being a distant secondary concern. This is actually often the case.

A lot more money and resources are given to C and C++ than Haskell or the various lisp dialectics. The fact that they're faster than languages like JavaScript and Python shows that PHD professors are very good at making compilers on their own.

>SBCL with proper declarations can for all intents and purposes be considered C speed.
Bullshit.

has nothing to do with the quality of compilers
the memory model of functional programs isn't how computers work
using immutable data means that data needs to be copied all the time under the hood
you can't get around that, you can only optimize it out sometimes

>using immutable data means that data needs to be copied all the time under the hood
Imagine unironically believing this.

I'd argue otherwise. GHC for example in the case of Maps in Haskell can enforce the concept of immutable data on the programmer, but the compiler can itself mutate the Map rather than making a fresh copy if it can reason that it's safe to do.

>he compiler can itself mutate the Map rather than making a fresh copy if it can reason that it's safe to do
that's what I said, you can optimize it out, sometimes
Other times you have to make a copy, which is slow
You can write a functional program in a way that ensures what you're doing never needs to copy data uneccessarily but at that point you're basically writing imperative code anyway

>mere hundreds of milliseconds

Attached: 1517290003841.png (925x720, 630K)

It's more like tens of milliseconds and runs infrequently. Compared to what it was before it's extremely good now.

>in this thread, people make excuses for their poor choices regarding their educations and careers

???

The vast majority of developers aren't proving their programs correct.
Unless you meant prove informally.

I mean both. Functional code is both easier to formally proof and easier to informally reason about and test. The latter being what I was going for though.

OCaml syntax gave me ptsd.
Lisp and Haskell are comfy thanks to based SICP and based Dutch professor

>easier to informally reason about
not when your functional solution is 3 times as complex as an imperative one

sounds like a "i don't know how do to functional and keep trying to write imperative code" kind of answer

You don't actually know functional programming if you believe this.

if you think that the functional solution to every problem is more efficient then you don't know anything about programming period
It's only more efficient sometimes, yet retards are insisting it's better all the time

>efficient
>complexity

you're moving goal posts

If it's a procedural problem then write a procedure. Real procedural problems are rare though, usually they are artificial because you need to interface with an existing procedural system.

Who the hell is talking about efficiency? We were talking about complexity.

>Real procedural problems are rare though
any persistent system, any program that does more than take an input and return an output is a "procedural problem"

Holy... JS confirmed for being RACIST?

The procedural context is typically only the skin of the problem, the computations that need to be performed are best expressed in a functional way. Unless there are no computations and you're doing nothing more than CRUD.

non-answers:
- procedural nature of machine code
- garbage collection

examples of fast programming languages:
- ATS
- SBCL (Common Lisp)
- mlton (optimizing compiler for Standard ML)
- sometimes hasklel and ocaml

Language developers simply don't invest as much into optimizing the language and generated code as they could. It's possible to get rid of most allocations and turn the memory into mutable/reused when it's strictly scoped, generate statically dispatched code paths instead of general dynamically dispatched when, tracking repeated constant expressions and so on. Functional programming has so much potential and even potential to be significantly faster in higher scale than procedural, but no one is aiming for it, shame.

using stateless code where you can is obviously the sane way to do it, but saying it's only the skin of the problem is very ignorant, complex simulations or interfaces to real-life hardware is not "only the skin" and would only be made more complex and less efficient by attempting to make them pure functional
Don't make the mistake of assuming just because FP works for your particular area of programming that it works everywhere

scary given that last week I've spend reducing latency between request and response from 2ms to 500us

Even Haskell supports state.

Playing these pauses for your slow code is not acceptable anymore in 2018.

Attached: .png (1148x729, 121K)

saying "it's just not optimized" is a very hand-wavy non-answer
optimization is not magic, there are things that are possible and things that aren't
the paradigms behind functional programming like heavy use of lambdas and non-mutation mean in a general sense, it's slower, optimization can turn that into a program that's as fast as imperative some of the time. To say it could be faster doesn't make much sense because machine code is imperative

and? Imperative languages support lambdas and pure functions

Only a few support lambdas.

Having a pure function isn't an accomplishment.

>Persistence
You can model persistence in the functional paradigm you dope.
>any program that does more than take an input and return an output
This is literally every single deterministic program.

The point is you can program in both styles in either, it's a meaningless thing to say
Many programming languages support lambdas, what mainstream lanaguage doesn't?

C

lol

>This is literally every single deterministic program.
No it isn't. Many programs run over a period of time, constantly taking inputs and emitting outputs while maintaining a persistent state. Again saying "You can do this" is meaningless. You can do everything with any programming paradigm. The point is some are more suited to certain use cases than others. Functional programming isn't so suited to programs that maintain state, of which there are many

Standard ML used to be pretty fast. The spec is provably type safe which allows compilers (notably MLTon) to make extremely aggressive whole-program optimizations. I think it is still the only language with literal no-cost polymorphism.

What? No cost? MLTon monomorphizes over entire modules!

>Why are functional languages usually magnitudes slower than procedural languages (C, C++, etc)?

Functional languages have a tendency of allocating new objects all the time, because they are about not mutating the existing things. Sometimes it helps, in important things it sucks due to lots of unneeded allocation and deallocation.

Why are functional languages good though: expressiveness, predictability, and not having to worry about memory issues. This helps when programming.

You shouldn't try to do everything in a purely functional language, but rather understand the functional programming, and use it's patterns to make your software better.

If something is expressible as a while loop, then you can convert it into a version that uses tail recursion.

should i use elm instead of react+redux? i heard elm inspired react

but procedural languages compile into functional IR

Why would you do that? Besides it the language doesn't support loops for some weird reason.

>non-answers:
>- procedural nature of machine code
>- garbage collection
except it literally is the reason
functional languages create a shit ton of garbage that needs to get collected, because everything is immutable
the way to "optimize" this is to use cow, which is very hard to implement in a non buggy way, just look at the disaster that is btrfs.

GC can be reduced with escape analysis, which is even more effective when everything is immutable