+ 15
I think this is not totally correct, because you are forgetting all the compiler optimisations. Let see what optimisations are done in Haskell, for instance : - 'common subexpression elimination' : computes common subexpression only once - inlining of functions thanks to the function definition - specialisation of functions (like templates in C++ : the same function is automatically generated a multiple of times to be more efficient ; zero-cost at runtime) - lazyness : an expression is evaluated only if it is necessary to evaluate it - function fusion. Quoted from the website, in the case of lists, for instance "these intermediate lists never exist in memory entirely". So there are optimisations to avoid at maximum allocation and deallocation of objects. - stream fusions : optimized into efficient for loops (wich also means only one memory allocation for the whole operation) From : https://wiki.haskell.org/GHC_optimisations And you can look at benchmarks! Haskell is efficient!
5th Mar 2021, 7:17 AM
Théophile
Théophile - avatar
+ 12
In terms of speed I think you are right. On the lowest level everything boils down to mutable operations (changing bits in memory). Immutability is a higher level concept, that helps the programmer controlling state changes throughout the program. It's a bubble to protect us from our own fallacies. If we talk about memory usage, I would say this depends on the programming language. For example, Clojure applies "persistent data structures" and "structural sharing". This eliminates the need to allocate lots of new memory, when we only change a small part of a large data structure. Some languages are not so graceful with memory management of immutable data. https://augustl.com/blog/2019/you_have_to_know_about_persistent_data_structures/
5th Mar 2021, 7:17 AM
Tibor Santa
Tibor Santa - avatar
+ 11
I think functional programming has the benefit to concisely describe complicated operations with short expressions. For example, map and filter, they also translate to "for loops" eventually, but they are declarative in saying: "I want this function run through my data" - whereas a for loop is imperative by nature, saying: "take each value from this group of values, and do something with it". Maybe it does not sound very different, but functional languages can very easily compose (chain) multiple functions that would be possible imperatively by nesting many for loops. This programming style has the benefit to convey the intention of the program to the developer more clearly, but obviously it does have additional costs, comparing to imperative instruction to change memory bit by bit.
5th Mar 2021, 7:21 AM
Tibor Santa
Tibor Santa - avatar
+ 11
Good question and it also depends on whether "slow" applies to: 1) writing code, 2) understanding and editing prewritten existing code, 3) compiling or 4) running the written code. :) The answers to those four different options are likely different. Worth creating a matrix and weighing the options?
6th Mar 2021, 2:19 PM
Marko Rillo
+ 10
Now, let's consider another thing : C is meant to be a system programming langage. It means that you have full control of what you are doing. I don't know any pure functional langage meant to be a system programming langage. They are usually not designed to be low-level. However, as we can see in the case of Haskell, functional programming langages can be very efficient, at the end. Yes, procedural programming in C is fast. But I could argue that procedural programming in Python is not. 😉
5th Mar 2021, 7:25 AM
Théophile
Théophile - avatar
+ 10
I'd wager that most people write faster C than assembly, and most people write faster C# than C. That's because the compiler generally does a pretty good job optimizing while you get tired eventually. There's no reason we can't keep climbing the abstraction ladder so long as compilers follow suit. There is no "inherent" slowness in any language. Immutability isn't really a show-stopper, if you have a function that operates on immutable data then the compiler can probably reason about your code a lot better, optimize better, and optimize away all the copying later. It's a win-win for both you and the compiler. That's in an ideal world anyway.
8th Mar 2021, 8:14 AM
Schindlabua
Schindlabua - avatar
+ 9
I would say the loss in speed made by functional language by avoiding mutable states can easily be balanced by the fact that for the same reason it makes it easier to implement parallel processing in them ( as less mutable states means less synchronisation and locking overheads ) And I think in every case where speed practically matters, a multithreaded functional program will always have an edge over single threaded procedural C program.
5th Mar 2021, 12:41 PM
Arsenic
Arsenic - avatar
+ 9
#define CPP ChillPill if you are try to parallelise stuff in C, you will eventually run into issues where the mutable variables are shared between concurrent processes which will end up costing more runtime overheads ( as then we also have to create some syncing mechanism involving locking and unlocking mutexes for it ) And on other hand if you have a functional program containing all pure function, it will not only make it easier to implement multithreading but will also reduce some runtime overheads ( as a pure function will have no mutable state )
5th Mar 2021, 1:05 PM
Arsenic
Arsenic - avatar
+ 5
Sonic C++ faster than C, and Java faster than C# How?
6th Mar 2021, 4:25 AM
Kiwwi#
Kiwwi# - avatar
+ 3
I always thought that C was the fastest programming language, this topic is very interesting as well big O notation in algorithms performance...
6th Mar 2021, 5:01 AM
Frank Castro
Frank Castro - avatar
+ 3
In most of the cases, YES. They need the infrastructure that inevitably adds overheads over what can theoretically be attained using assembler by hand. Specifically, first-class lexical closures only work well with garbage collection because they do allow values to be carried out of scope. I hope this will clarify your doubts.
10th Mar 2021, 4:17 AM
Shaili Shah
Shaili Shah - avatar
+ 2
so in general functional langs compile a bit slow but runs at good speed, right?
5th Mar 2021, 4:36 PM
Kiwwi#
Kiwwi# - avatar
+ 2
When you want to be fast use Fortran! https://www.nature.com/articles/physci231208a0
5th Mar 2021, 9:01 PM
Jholler
Jholler - avatar
+ 2
Yes there are so many people and I also thing that c is the fastest language that's why we learn c first then after other languages
6th Mar 2021, 5:12 AM
亗𝙰𝙽𝚄𝚁𝙰𝙶亗
亗𝙰𝙽𝚄𝚁𝙰𝙶亗 - avatar
+ 1
Sonic is right 👌👌👌👌
6th Mar 2021, 4:45 AM
亗𝙰𝙽𝚄𝚁𝙰𝙶亗
亗𝙰𝙽𝚄𝚁𝙰𝙶亗 - avatar
0
In most cases, YES. They require infrastructure that inevitably adds overheads over what can theoretically be attained using the assembler by hand. Specifically, first-class lexical closures only work well with garbage collection because they allow values to be carried out of scope. I hope this clarifies your doubts. Have a nice day.
10th Mar 2021, 6:18 AM
Shaili Shah
Shaili Shah - avatar