From: J.s on 28 Jul 2010 11:24 As I am continuing my freshman year of college majoring in cs it seems I stand alone with the view of abuse or at least over-use of OOP concepts and the knowledge of functional programming in general. Of the many people I have met who are currently or have recently graduated with a cs degree, very few have ever learned any functional programming or anything other than c# and java. What recently got my attention though was an article I found on f# from one of Microsoft developer's blogs [http://blogs.msdn.com/b/ dsyme/archive/2010/04/12/f-2-0-released-as-part-of-visual- studio-2010.aspx]. In it Don Syme (a developer of f#) explains what both f# is to other programmers, but the part that disturbed me was where Syme implies functional programmers are not "focus(ed) on ... the process of writing code": "Q: What is functional programming? Functional programming languages express ideas at a higher level and allow users to focus on the challenge of problem solving instead of the process of writing code. A programming language like F# provides a tool bag of functions that users can pick from to solve their problem. Functional programming includes concepts such as immutability to reduce dependencies between components, generics to express solutions that work over many different kinds of data, and functions as values to make it easy to abstract units of a solution into reusable pieces." Does anyone have any thoughts on this?
From: Georg Bauhaus on 28 Jul 2010 12:16 On 28.07.10 17:24, J.s wrote: > Functional programming languages express ideas at a higher level and > allow users to focus on the challenge of problem solving instead of > the process of writing code. A programming language like F# provides a > �tool bag� of functions that users can pick from to solve their > problem. Functional programming includes concepts such as > immutability to reduce dependencies between components, generics to > express solutions that work over many different kinds of data, and > functions as values to make it easy to abstract units of a solution > into reusable pieces." > > > > Does anyone have any thoughts on this? Yes, and Grady Booch has said a few things against functional programming (hype) very recently no less substantiated than the above collection of claims. I haven't met anyone who thinks that knowing functional programming style, in particular familiarity with the consequences of no mutable values isn't a valuable experience. As is the experience of so called fusions, and of mutable variables in functional programming languages (really functional any longer?): the inevitable consequence of trying to make a functional program meet the requirements of predictable SPACE and TIME complexity. To distinguish the above quote about F# from language marketing, consider the questions: "What is an idea at a higher level?" (explaining "idea" and "height") "When one assembles functions a la Hughes (point free style), how is the thinking process different from that performed by the OO-programmer assembling classes and their protocols?" "Regarding OO vs functional, is one good without the other?" (which one?) Georg
From: Jeffrey R. Carter on 28 Jul 2010 12:31 On 07/28/2010 08:24 AM, J.s wrote: > > Does anyone have any thoughts on this? I think some relationship to Ada should be established when posting here. -- Jeff Carter "The time has come to act, and act fast. I'm leaving." Blazing Saddles 36
From: Dmitry A. Kazakov on 28 Jul 2010 12:40 On Wed, 28 Jul 2010 08:24:08 -0700 (PDT), J.s wrote: > As I am continuing my freshman year of college majoring in cs it seems > I stand alone with the view of abuse or at least over-use of OOP > concepts and the knowledge of functional programming in general. OOP is over-used? And knowledge of FP is what? > Of the many people I have met who are currently or have recently > graduated with a cs degree, very few have ever learned any functional > programming or anything other than c# and java. Maybe > What recently got my attention though was an article I found on f# > from one of Microsoft developer's blogs [http://blogs.msdn.com/b/ > dsyme/archive/2010/04/12/f-2-0-released-as-part-of-visual- > studio-2010.aspx]. In it Don Syme (a developer of f#) explains what > both f# is to other programmers, but the part that disturbed me was > where Syme implies functional programmers are not "focus(ed) on ... > the process of writing code": > > "Q: What is functional programming? > > Functional programming languages express ideas at a higher level and > allow users to focus on the challenge of problem solving instead of > the process of writing code. This claim was made for each and every programming paradigm. It need to be substantiated, and especially for FP, which does not look very promising at all. > A programming language like F# provides a > �tool bag� of functions that users can pick from to solve their > problem. I.e. the decomposition is procedural, welcome back in 60's... > Functional programming includes concepts such as > immutability to reduce dependencies between components, How is immutability to reduce dependence? An immutable argument must be taken from somewhere. And immutable results does not even exist. He probably meant side effects. It is to be shown that procedural decomposition to reduce need in side effects. I doubt it does. And the whole computing is about side effects. Programming is how side effects can be engineered. > generics to > express solutions that work over many different kinds of data, Different kinds of data? He probably meant types. Ah, but types smell OOP, right? I hope it is not about passing integer where real expected? GP is about dealing with sets of types. To substantiate the claim it is to show how types and their sets can be described and manipulated within FP, easier, quicker, safer, more maintainable etc. > and > functions as values to make it easy to abstract units of a solution > into reusable pieces. Function as a value of what? And what is the difference? Maybe a side effect of the call? Anyway I don't see how values can be reusable. > Does anyone have any thoughts on this? FP is yet another attempt to make programming declarative. That won't happen until last programmer dies. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: (see below) on 28 Jul 2010 13:47 On 28/07/2010 17:40, in article g24nvegdi17t$.1azxwn1rwjixi$.dlg(a)40tude.net, "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote: >> "Q: What is functional programming? >> >> Functional programming languages express ideas at a higher level and >> allow users to focus on the challenge of problem solving instead of >> the process of writing code. > > This claim was made for each and every programming paradigm. It need to be > substantiated, and especially for FP, which does not look very promising at > all. Indeed, it has been "promising", but not delivering, for a very long time. >> Functional programming includes concepts such as >> immutability to reduce dependencies between components, > > How is immutability to reduce dependence? An immutable argument must be > taken from somewhere. And immutable results does not even exist. He > probably meant side effects. ... And the > whole computing is about side effects. Programming is how side effects can > be engineered. Precisely. Except that it is about *effects*, just plain *effects*. The "side" is propagandistic scare-language added by the FP fundamentalists. (I originally spelled that "fundamnetalists" -- Freudian slip 8-). > FP is yet another attempt to make programming declarative. That won't > happen until last programmer dies. 8-) I was at a short talk given by one of the leading FP propagandists. He drew an S-curve depicting technological penetration against time, and admitted that FP was still at the bottom left, far from lift-off. After 50 years! (McCarthy's "Recursive functions of symbolic expressions and their computation by machine, Part I" was published in 1960. We still seem to be waiting for Part II: "real-world relevance".) -- Bill Findlay <surname><forename> chez blueyonder.co.uk
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: team-ada (was e: Interfacing Ada with C Next: ANN: GtkAda contributions v2.8 |