Functional Programming
-
Who's yet to open the book on this? This is one such topics where the whole world starts doing something about, but I keep it safe in my todo list. Just a quick question from the dummies perspective. 1. Will functional programming make all the OOAD concepts obsolete or it can get along well with OOAD? 2. What's your take? You like it?
Tried to get into "real" FP a couple times but I haven't found a single tutorial starting with something FP does better than, let's say, OOP or even procedural. On the other hand, functional concepts are creeping into languages like C# where I've been using them extensively. Heck, even variable.dosomething(parm).dosomethingelse(someotherparm) is, as a matter of fact, functional.
-
Who's yet to open the book on this? This is one such topics where the whole world starts doing something about, but I keep it safe in my todo list. Just a quick question from the dummies perspective. 1. Will functional programming make all the OOAD concepts obsolete or it can get along well with OOAD? 2. What's your take? You like it?
-
Actually, Forth did what it was designed for reasonably well. Unlike MUMPS, which was developed by (hold your breath) *doctors*! And the VA STILL uses it. One of the only 'languages' that allowed you write a complete program in a string variable (using user input) and execute it immediately. One nice thing was there were only 25 reserved words, each one starting with a different letter (Z was for anything that did not fit) and a program was allowed use just the first letter for the reserved word.
A human being should be able to change a diaper, plan an invasion, butcher a hog, navigate a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects! - Lazarus Long
MUMPS is an old, procedural language and I was not thrilled to have to learn it in 2001. However, the database Cache is BLAZING fast and works very well for storing Medical data. Fortunately, I no longer have to code MUMPS, but I still respect the speed.
-
for mine it's something everyone talks about as the new sliced bread, and later all but disappears into some niche, like lisp or prolog, or even forth.
Message Signature (Click to edit ->)
I did a large project in Forth back in the '80s. Never again. Forth is a write only language
-
Was Forth a fourth generation language? Can you imagine interpreting a job requirement that says what is needed is, "Go, Forth and Javascript".
- I would love to change the world, but they won’t give me the source code.
-
Functional programming preceeded OOP. OOP is (I think) a better idea. Turbo Pascal started out as a functional language. Fortran is a fucntional lanugage. C is a functional language. Javascript is not functional, but it is a functional language. Visual Basic was a functional language. My problem with the sudden interest (by people who don't matter) in functional programming is that everyone thinks OOP should be abandoned, or that functional crap should be injected into the OOP paradigm. These people are, for lack of a better term, retards.
From Wikipedia: In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm in that programming is done with expressions or declarations instead of statements. Functional code is idempotent: a function's return value depends only on its arguments, so calling a function with the same value for an argument always produces the same result. This is in contrast to imperative programming where, in addition to a function's arguments, global program state can affect a function's resulting value. Eliminating side effects, that is, changes in state that do not depend on the function inputs, can make understanding a program easier, which is one of the key motivations for the development of functional programming. Fortran and C are not functional programming languages. Having functions does not make a language functional. And one of the reasons for renewed interest in functional languages is they have certain advantages when trying to parallelize programs.
-
I did a large project in Forth back in the '80s. Never again. Forth is a write only language
-
I did a large project in Forth back in the '80s. Never again. Forth is a write only language
I've heard the "write-only" complaint about Perl and APL, too ... I've seen horrible Perl; but also have seen huge Perl apps that were a cakewalk to understand. APL worked very well at giving you the whole algorithm in a concise picture. Ask Morgan-Stanley how "K works, for people who are under serious coding pressure. I'd say it's a matter of developer community and praxis, without which every language can be a bomb. Language (syntax) requirements never prevent all the bad things you *can* do. Check out Linus Torvalds' comments on why not C++, referenced tangentially here (nevermind the flamebait) [medium.com/codeiq/object-oriented-programming...](https://medium.com/codeiq/object-oriented-programming-the-trillion-dollar-disaster-️-92a4b666c7c7\])
-
From Wikipedia: In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm in that programming is done with expressions or declarations instead of statements. Functional code is idempotent: a function's return value depends only on its arguments, so calling a function with the same value for an argument always produces the same result. This is in contrast to imperative programming where, in addition to a function's arguments, global program state can affect a function's resulting value. Eliminating side effects, that is, changes in state that do not depend on the function inputs, can make understanding a program easier, which is one of the key motivations for the development of functional programming. Fortran and C are not functional programming languages. Having functions does not make a language functional. And one of the reasons for renewed interest in functional languages is they have certain advantages when trying to parallelize programs.
Sounds like "static methods" are a step in the "functional" direction then. And enumerators.
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.' ― Confucian Analects
-
From Wikipedia: In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm in that programming is done with expressions or declarations instead of statements. Functional code is idempotent: a function's return value depends only on its arguments, so calling a function with the same value for an argument always produces the same result. This is in contrast to imperative programming where, in addition to a function's arguments, global program state can affect a function's resulting value. Eliminating side effects, that is, changes in state that do not depend on the function inputs, can make understanding a program easier, which is one of the key motivations for the development of functional programming. Fortran and C are not functional programming languages. Having functions does not make a language functional. And one of the reasons for renewed interest in functional languages is they have certain advantages when trying to parallelize programs.
From what you wrote, it sounds like the use of deterministic and non-deterministic functions. How does functional programming differ from traditional OOP where the developer knows they are writing a deterministic or non-deterministic function within a class?
-
I've thought about this same thing myself quite a bit. OOAD (OOP) is a tool. Functional Programming is a tool. Most of the time you read things about how one tool or the other solves all problems. But that is the same as thinking that a hammer solves all problems. There are concepts from both things that can make your code better. OOP / OOAD is really a way of organizing your code. It is not really more than that. But authors had to write books and those books had to meet a minimum length of pages so it exploded! Functional Programming (FP) did the same thing: exploded in publication. But again, Functional Programming contains some concepts that are novel and helpful. The one big concept from FP is the idea of "No Side Effects". Managing state while concurrent processes are running is a challenge. FP has exploded because concurrent processing has exploded in hardware. Suddenly you need a way to guarantee that you're not overwriting what another "thread" of execution is doing. So, as we consider Foundational Concepts of programming paradigms we see that the two (OOP and FP) can be very useful together. One for organizing your code. The other for managing state in a concurrent environment. Here's a very nice article I just googled that talks about Core Functional Programming Concepts[^]
Quote:
FP has exploded because concurrent processing has exploded in hardware. Suddenly you need a way to guarantee that you're not overwriting what another "thread" of execution is doing.
How is this any different than writing multithreaded code where the developer knows the scope of the variables used? I use the Task Parallel Library in .NET a lot, and never have any trouble with one thread/task affecting variables in another.
-
From what you wrote, it sounds like the use of deterministic and non-deterministic functions. How does functional programming differ from traditional OOP where the developer knows they are writing a deterministic or non-deterministic function within a class?
-
Who's yet to open the book on this? This is one such topics where the whole world starts doing something about, but I keep it safe in my todo list. Just a quick question from the dummies perspective. 1. Will functional programming make all the OOAD concepts obsolete or it can get along well with OOAD? 2. What's your take? You like it?
Language Vb.net and C# have Linq which provides these OOP languages with FP. Switching from a OOP language to an FP language is another mater. I keep saying my next project I'll write in F#. but my designs always wind up using OOP constructs so I stick with my OOP language and use all of its FP features.
-
Quote:
FP has exploded because concurrent processing has exploded in hardware. Suddenly you need a way to guarantee that you're not overwriting what another "thread" of execution is doing.
How is this any different than writing multithreaded code where the developer knows the scope of the variables used? I use the Task Parallel Library in .NET a lot, and never have any trouble with one thread/task affecting variables in another.
It’s not necessarily a whole lot different. Functional programming “automatically” supports structures and methods that support this type of thing a bit more easily than procedural or OOP languages. It’s also a way of thinking that is a part of FP. And, you can definitely do the same things with different tools. That is what confuses newer devs the most, I think. Of course some languages and some language types make certain things harder or easier.