5 ms·

It’s a pity some people still build important apps in PHP and Spring PHP/Spring only sucks if you dont know how to use. Functional Programming is getting a fo

It’s a pity some people still build important apps in PHP and Spring PHP/Spring only sucks if you dont know how to use. Functional Programming is getting a foothold on the mainstream, because if you care about performance you care about concurrency Since when FP is high performance and better concurrency support? Pick the right tool please.

idProQuo 13y ago
>Since when FP is high performance and better concurrency support? Lately I've been going back and forth between taking Udacity's Intro to Parallel Programming course (using CUDA, a C++ extension) and reading Learn You A Haskell For Great Good. I've found that while FP principles are cool to think about, they're also crucial for writing proper concurrent code. If you write a kernel (a function executed by many threads in parallel) that produces side effects, you'll end up with a mess (since you can make no assumption about which threads will get to a particular part at which time). Furthermore, when you design parallel algorithms, knowing how monoids work is useful: you want to be doing operations that are associative and have empty implementations (+0, *1, AND true, OR false) so that they can be run in any order. In short, Haskell forces you to stop thinking about the order in which your commands will be run, which is also a constraint imposed by parallelism.
- taeric 13y ago
  Of course, when you are coding in such a way that you know what all of your shared resources are, sometimes it is convenient to be the one in charge. I pretty much always go to a cooking analogy. Knowing how many spoons/dishes/ovens/stovetops/etc is critical to specifying an algorithm for making a large dinner. In many kitchens, you even have to account for how long it takes to clean said items to know how many you will need. Basically, when designing an algorithm (or recipe), I think I fully agree with what you are saying. When you are designing the plan of attack on how something will actually be done, you typically have to go lower. Now, I fully expect/hope that that part of the task could be done mechanically. I think it is safe to say that compilers aren't as far as many advocates put forth.
Morgawr 13y ago
>Since when FP is high performance and better concurrency support? FP is a huge step forward for concurrent development. The availability of immutable and (especially) persistent data structures is a key point in getting a concurrent application to work well. One of the core points behind FP is to reduce (or even remove) side effects in software development. Those side effects are what make concurrent development hell and unmaintainable. By logic, using FP makes concurrent development easier to handle. As for performance, it's not that obvious whether or not FP is better or worse than other paradigms. Had you asked me ten years ago then the answer would've been obvious (it'd be worse) but interpreters, compiler development, type systems and all that jazz has improved a lot in the recent years.
codygman 13y ago
For the majority that aren't concerned with realtime processing (total fine grained control isn't needed) concurrent FP is much simpler than the alternatives. FP code (ala Haskell) can also be very aggressively optimized. Also, most of the time programmers shoot themselves in the foot with that total fine grained control some languages give. This doesn't mean they don't need to exist, just that FP can server a majority who think they need total control much better with more than acceptable performance.

idProQuo 13y ago

>Since when FP is high performance and better concurrency support? Lately I've been going back and forth between taking Udacity's Intro to Parallel Programming course (using CUDA, a C++ extension) and reading Learn You A Haskell For Great Good. I've found that while FP principles are cool to think about, they're also crucial for writing proper concurrent code. If you write a kernel (a function executed by many threads in parallel) that produces side effects, you'll end up with a mess (since you can make no assumption about which threads will get to a particular part at which time). Furthermore, when you design parallel algorithms, knowing how monoids work is useful: you want to be doing operations that are associative and have empty implementations (+0, *1, AND true, OR false) so that they can be run in any order. In short, Haskell forces you to stop thinking about the order in which your commands will be run, which is also a constraint imposed by parallelism.

taeric 13y ago
Of course, when you are coding in such a way that you know what all of your shared resources are, sometimes it is convenient to be the one in charge. I pretty much always go to a cooking analogy. Knowing how many spoons/dishes/ovens/stovetops/etc is critical to specifying an algorithm for making a large dinner. In many kitchens, you even have to account for how long it takes to clean said items to know how many you will need. Basically, when designing an algorithm (or recipe), I think I fully agree with what you are saying. When you are designing the plan of attack on how something will actually be done, you typically have to go lower. Now, I fully expect/hope that that part of the task could be done mechanically. I think it is safe to say that compilers aren't as far as many advocates put forth.

Morgawr 13y ago

>Since when FP is high performance and better concurrency support? FP is a huge step forward for concurrent development. The availability of immutable and (especially) persistent data structures is a key point in getting a concurrent application to work well. One of the core points behind FP is to reduce (or even remove) side effects in software development. Those side effects are what make concurrent development hell and unmaintainable. By logic, using FP makes concurrent development easier to handle. As for performance, it's not that obvious whether or not FP is better or worse than other paradigms. Had you asked me ten years ago then the answer would've been obvious (it'd be worse) but interpreters, compiler development, type systems and all that jazz has improved a lot in the recent years.

codygman 13y ago

For the majority that aren't concerned with realtime processing (total fine grained control isn't needed) concurrent FP is much simpler than the alternatives. FP code (ala Haskell) can also be very aggressively optimized. Also, most of the time programmers shoot themselves in the foot with that total fine grained control some languages give. This doesn't mean they don't need to exist, just that FP can server a majority who think they need total control much better with more than acceptable performance.