QuoteOriginally posted by: PolterQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: chocolatemoneyQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: chocolatemoneyI personally would not spend time learning an additional imperative language. I would invest time in trying to work out code with a new approach - pure functional in Haskell, OCAML, F#, for example. I guess that brings more challenges and insights, a fresh new perspective.http://www.wilmott.com/messageview.cfm? ... GDBTABLE=I
think this is a good piece of advice. What is your view on Scala, Hadoop etc.?Even now you see FP features entering C++ 11 and C#. FP is maths in code, yes?In Switzerland, probably because of the role and proximity of the EPFL, Scala has been growing quickly.Java will/is add(ing) FP features, going along the same path took by C++ 11 and C#. Let's see if this will slow down Scala growth.I think FP goes beyond the analogy with mathematical functions. FP in my view is the concept of immutability and a design where the building blocks of your code are function where you have an input and an output, and SW is the composition of those. A pure FP approach brings a completely different approach to design and SW engineering while I personally see adding lambdas and currying to your imperative code just some sort of syntactic sugar. Maybe I am too strict in my view of the matter..From aesthetics point of view, pure FP might have the edge but 'pure' languages (e.g. Smalltalk) were not a commercial success in general. C++ was called a 'better C' in the 90's.Engineers and traders tend to think in s/w blocks IMO so I think FP languages should not forget about modules and objects?QuoteWhat about Objects?So, should we forget OO and all program in functional programming languages? No! What the industry learned about OO decomposition in analysis and design stays valid.Central question: What goes where? In the end, need to put things somewhere, or risk unmanageable global namespace.New ObjectsPreviously: "Objects are characterized by state, identity, and behavior." (Booch)Now: Eliminate or reduce mutable state. Structural equality instead of reference identity. Concentrate on functionality (behavior)Can FP and OOP be combined?QuoteMartin Odersky visited SF Scala to share his perspective on getting the most out of this incredibly complex, and powerful, programming language.[...]He says, that in today's programming paradigm, we are in a transition period between imperative/object-oriented and functional programming. In the end, he predicts a fusion between both styles. Find out why!For more, see Martin Odersky's Keynote Speech at ScalaDays 2013 - "Scala With Style":[...]Version given later at SF Scala (combines slides w/ video):[...]I have limited bandwidth at the moment, so I will view it later.Some thinking out aloud:One of the issues with OOP is that it does not scale to large systems (maybe some of the reasons/issues may be resolved by FP?). An issue is to program large systems and FP is a more appropriate metaphor IMO, especially the part of interfaces (like COM or std::function).QuoteNow: Eliminate or reduce mutable state. Structural equality instead of reference identity. Concentrate on functionality (behavior)I think modelling state up-front (as with OOP) hinders flexibility. The Responsibility-Driven Method of Rebecca Wirfs Brock take a behavioural approach to OOP afair.I agree that programming is in a state of transition/evolution. But it will take some time before it becomes mainstream. On the other hand, most OO programmers can grasp the essence in a couple of hours (use .NET delegates and new stuff in C++ 11). A good test case is to define plug-in methods and Strategy to show how such a transition could take place.