- cmsg cancel <mcqnlr$9it$2@dont-email.me> - 3 Updates
- About concurrency and functional programming - 3 Updates
| bleachbot <bleachbot@httrack.com>: Feb 27 10:31PM +0100 |
| bleachbot <bleachbot@httrack.com>: Feb 27 10:44PM +0100 |
| bleachbot <bleachbot@httrack.com>: Feb 27 10:57PM +0100 |
| Ramine <ramine@1.1>: Feb 27 04:31PM -0800 Hello, In this post i am going to speak about an important subject... There are a number of factors that have influenced the adoption of high-order functions in languages like Java, C++ and Delphi. One of the important factor is the proliferation of multi-core processors and, with that, the desire for more parallel and concurrent processing. The map/filter/reduce style of functional programming is very friendly to parallelization, allowing the programmer to easily make use of multiple cores, without writing any explicit threading code. Functions, plus a map/filter/reduce programming pattern, and immutability are the core of functional programming. Together these things make for powerful tools of parallel and concurrent programming. Also one of the very important things of functional programming is immutability and composability in the presence of concurrency, and i have just read the following webpage about "The Functional Revolution in C++", here it is: http://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/ But i have noticed that this guy called "Bartosz Milewski" is saying that the functional programming revolution is unvoidable, but i don't agree with him, because from experience i have come to conclusion that in most of the projects aroun the world the parallel part`s quantity of there source code is much smaller than the serial part`s quantity of there source code, an i really think that this fact will not change, so from this fact i have come to the conclusion that the functinal programming revolution will not bring much to the imperative languages when it comes to concurrency, because since on most programming projects the parallel part`s quantity of the source code is much smaller than the serial part`s quantity of the source code, so applying the higher level abstractions of functoinal programming to them will not bring much improvement to maintenability, expressiveness or costs or time or competitivity or quality of programming in general of the products. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Feb 27 04:44PM -0800 Hello, I will add this: If you read this again: http://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/ You will notice that "Bartosz Milewski" is saying that object oriented programming is not composable in presence of concurrency... but i think he is not correct... because what you can do is write near the property's interface(and don't forget to use set and get) and the methods that they are thread-safe, so when you you will inherit from the parent class, you will just read near the interface of the parent's class wich one is thread-safe and you will take that into account when you will compose by ineritance, and i think that this is easy to do and that it's efficient and no need for functional programming. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Feb 27 04:57PM -0800 Hello.. In this post i am going to speak about an important subject... There are a number of factors that have influenced the adoption of high-order functions in languages like Java, C++ and Delphi. One of the important factor is the proliferation of multi-core processors and, with that, the desire for more parallel and concurrent processing. The map/filter/reduce style of functional programming is very friendly to parallelization, allowing the programmer to easily make use of multiple cores, without writing any explicit threading code. Functions, plus a map/filter/reduce programming pattern, and immutability are the core of functional programming. Together these things make for powerful tools of parallel and concurrent programming. Also one of the very important things of functional programming is immutability and composability in the presence of concurrency, and i have just read the following webpage about "The Functional Revolution in C++", here it is: http://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/ But i have noticed that this guy called "Bartosz Milewski" is saying that the functional programming revolution is unvoidable, but i don't agree with him, because from experience i have come to conclusion that in most of the projects aroun the world the parallel part`s quantity of there source code is much smaller than the serial part`s quantity of there source code, an i really think that this fact will not change, so from this fact i have come to the conclusion that the functinal programming revolution will not bring much to the imperative languages when it comes to concurrency, because since on most programming projects the parallel part`s quantity of the source code is much smaller than the serial part`s quantity of the source code, so applying the higher level abstractions of functoinal programming to them will not bring much improvement to maintainability, expressiveness or costs or time or competitivity or quality of programming in general of the products. I will add this: You will notice that "Bartosz Milewski" is saying that object oriented programming is not composable in presence of concurrency... but i think he is not correct... because what you can do is write near the property's interface(and don't forget to use set and get) and the methods that they are thread-safe, so when you you will inherit from the parent class, you will just read near the interface of the parent's class wich one is thread-safe and you will take that into account when you will compose by ineritance, and i think that this is easy to do and that it's efficient and no need for functional programming. Thank you, Amine Moulay Ramdane. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
No comments:
Post a Comment