We use cookies to ensure you have the best browsing experience on our website. Please read our cookie policy for more information about how we use cookies.
What are you looking for, is classical "Functional-vs-Imperative" holywar :). There are tons on that in the internet.
It's "managing calculations"-vs-"managing state". In functional style you feel yourself like a mathematician constructing complete function. In imperative you feel yourself like a programmer thinking "how state will change" if I write this.
Classical "what it is"-vs-"how to do it".
HashMap solution could be written in functional style too.
My personal thoughts on that - functional features are good, give better readability. I'd suggest using them in things like list comprehensions, e.g. you want to filter, count, aggregate something for elements. But personally I prefer mostly imperative code, because it's self-contained and self-explaning. E.g. you know what's going on for sure, though you have to write more code.
Also, functional-styled code is more bugless in terms of multithreading and multicore/multinode processing - e.g. filters, aggregators/reducers is good paralellable architecture. That's why it's often used in things like map-reduce, data processing and so on.
In terms of memory/runtime - depends on environment and implementation of functional language. In most cases they are constantly equal. But there are some cases when functional code under-the-hood generates a lots of object which "annoy" garbage collection. And also, there are some problems which require managing state directly. E.g. immutability would be an overdose.
Let's say you can always do better in imperative. But in most cases you gain more because of shortness and cleaniness of functional. However, you still need to be sure what it's doing under-the-hood and use it carefully.
Sparse Arrays
You are viewing a single comment's thread. Return to all comments →
What are you looking for, is classical "Functional-vs-Imperative" holywar :). There are tons on that in the internet. It's "managing calculations"-vs-"managing state". In functional style you feel yourself like a mathematician constructing complete function. In imperative you feel yourself like a programmer thinking "how state will change" if I write this. Classical "what it is"-vs-"how to do it".
HashMap solution could be written in functional style too.
My personal thoughts on that - functional features are good, give better readability. I'd suggest using them in things like list comprehensions, e.g. you want to filter, count, aggregate something for elements. But personally I prefer mostly imperative code, because it's self-contained and self-explaning. E.g. you know what's going on for sure, though you have to write more code.
Also, functional-styled code is more bugless in terms of multithreading and multicore/multinode processing - e.g. filters, aggregators/reducers is good paralellable architecture. That's why it's often used in things like map-reduce, data processing and so on.
In terms of memory/runtime - depends on environment and implementation of functional language. In most cases they are constantly equal. But there are some cases when functional code under-the-hood generates a lots of object which "annoy" garbage collection. And also, there are some problems which require managing state directly. E.g. immutability would be an overdose.
Let's say you can always do better in imperative. But in most cases you gain more because of shortness and cleaniness of functional. However, you still need to be sure what it's doing under-the-hood and use it carefully.