- About concurrency and functional programming - 3 Updates
- cmsg cancel <mcqnma$9it$3@dont-email.me> - 2 Updates
- memcpy - 1 Update
- Why all tutorials/books use non-unicode string? - 2 Updates
| 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:45PM -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. |
| Christopher Pisz <nospam@notanaddress.com>: Feb 27 04:09PM -0600 On 2/27/2015 6:31 PM, Ramine wrote: > quality of programming in general of the products. > Thank you, > Amine Moulay Ramdane. What was your question on C++? -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| bleachbot <bleachbot@httrack.com>: Feb 27 10:31PM +0100 |
| bleachbot <bleachbot@httrack.com>: Feb 27 10:44PM +0100 |
| Vir Campestris <vir.campestris@invalid.invalid>: Feb 27 08:11PM On 12/02/2015 08:57, Luca Risolia wrote: >> I think Android is a pretty important market too. The trouble is there >> are a variety of CPUs, so you really need to stick to Java. > It's a well known fact that C++ is more portable than Java. (1) references? (2) Not at the binary level. Andy |
| legalize+jeeves@mail.xmission.com (Richard): Feb 26 11:40PM [Please do not mail me a copy of your followup] no@notvalid.com spake the secret code >> The choice as you've described it is a false one. It isn't a choice >> between fast and quality. >But surely quality and time are correlated, right? Schedule/time here refers to the idea of a fixed delivery date, i.e. we must ship this game in time for Christmas, not the time required to develop a feature. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Feb 26 11:42PM [Please do not mail me a copy of your followup] Bo Persson <bop@gmb.dk> spake the secret code >A problem is that if you tell the truth up front, you will hardly ever >get any checks. >That's worse than being caught with "bad predictions". Both of these are symptomatic of an environment with a low trust dynamic. This is something that comes up constantly in discussions of agile development. The bottom line is that without trust, people will fall back into gaming the system in one way or another. Both of the dysfunctional behaviors described above ("punished for telling the truth" and "lying to secure approval") are results of a low trust environment. In an environment where trust is prevalent, neither of these kinds of dysfunctions occurs. How do you gain trust? There is no silver bullet for this because it is a problem of human relations and not one of technology. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| 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.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment