A lire sur:
http://www.techrepublic.com/blog/programming-and-development/when-to-use-functional-programming-languages-and-techniques/6801
As IT professionals, we have to balance
proficiently executing on current projects with proven technologies and
learning to implement new ways of doing things. Software development
arguably changes more rapidly than any other aspect of IT, making it an
even tougher challenge.
Given the limited amount of time, it’s often difficult to decide what new techniques to learn. The questions of if and where to use functional programming languages/techniques strikes me as one of the tougher calls to make these days.
There is a strong case to be made that either functional languages or the other kinds can be object-oriented. LISP, considered by many an archetypal functional language, is a prime example. In other words, you can use either kind of language to implement object-oriented principals (and some would argue, more “purely” in functional languages). Similarly, you can write bad code in any language.
So, what kinds of problems are functional languages (if used well) superior at solving? Surveying the literature, problems that require lots of concurrency and parallelism jump out as obvious candidates. Erlang, for instance, was used prominently at Ericcson in the telecommunications equipment field, and more recently to power messaging startup WhatsApp. Interestingly, the famous Lucent (via Western Electric, not Bell Labs) 5ESS telephone switch is another example of a prominent functional programming success story. If you’ve placed a phone call to or in the United States in the last 30 years, chances are you used one of these devices, and the code that keeps its database (with more than 1,000 relations) consistent, was written in a custom language called Pdiff, which in turn was written in Standard ML.
That brings us to another area where functional languages seem to shine: domain specific languages (DSLs). If your problem domain is so hairy that the usual design patterns we’re used to in typical enterprise languages like Java and C/++ fail to efficiently solve them, a DSL might be just the trick. You wouldn’t build your whole system with a DSL, but, like the 5ESS switch, you could use it to code a critical function in a way that is easier to understand and maintain and, therefore, ensure its quality. Functional languages are killer at creating DSLs.
One interesting example I found is a DSL to process exotic financial derivatives. This illuminates another area where functional languages/approaches shine: math-heavy algorithms. If you need to solve a problem that can decompose into a series of mathematical operations, the kind of thing you’d tackle with a DSP chip or GPU, then a functional language is likely a good choice for expressing the solution.
Another way to think about this kind of problem is: Could you solve it, at a small-scale, with a spreadsheet? If the answer is yes, then you’ve got two choices: get a product that can compile spreadsheets into your platform of choice (many exist), or express it in a functional language. This is a useful analogy, because it highlights how functional languages (which seem so math-centric) can handle operations we’re used to in other languages, like conditional statements. If you’ve ever used the IF function in a spreadsheet, then you have your answer. Functional languages, like the other kinds, are Turing Complete, and can be used to code any problem. The trick, it seems, is to code different parts of your system in languages that are most effective at expressing that part of the problem domain.
Great, so, I’ve got you interested in functional programming, now what the heck do you? When trying to build a new capability within my team, my preferred approach is to identify a potential pioneer. Someone who can grok the new ideas, drink the proverbial punch, and then bring that knowledge back to the team and evangelize. Send that person out for training, and then (as I think you should do with any training course) have them share what they learned with the team (buy them all a meal at the same time too, it helps). But only do so when you’ve identified a project or task where a functional approach makes sense. If folks don’t start to use what they’ve learned within 30 days, it’s likely gone.
If you want to incorporate functional code into your larger system, one approach is to have the language compile into the same bytecode as your main system; Scala runs on JVMs, and there is F# for the .NET CLR (and other platforms). You can always just run your code in one of the other functional language environments (such as Haskell, Clojure, OCaml, etc.) and expose it with a REST API as well.
Takeaway: If
a project requires lots of concurrency/parallelism, its own language,
or lots of math, you should think functional programming.
Given the limited amount of time, it’s often difficult to decide what new techniques to learn. The questions of if and where to use functional programming languages/techniques strikes me as one of the tougher calls to make these days.
If and where to use functional programming
First, let’s define our terms. A functional language or technique is one in which the sole or dominant form of expressing algorithms is the evaluation of mathematical functions, avoiding state changes and mutable data. This is as against declarative, imperative, and procedural languages/techniques, which emphasize changes in state.There is a strong case to be made that either functional languages or the other kinds can be object-oriented. LISP, considered by many an archetypal functional language, is a prime example. In other words, you can use either kind of language to implement object-oriented principals (and some would argue, more “purely” in functional languages). Similarly, you can write bad code in any language.
So, what kinds of problems are functional languages (if used well) superior at solving? Surveying the literature, problems that require lots of concurrency and parallelism jump out as obvious candidates. Erlang, for instance, was used prominently at Ericcson in the telecommunications equipment field, and more recently to power messaging startup WhatsApp. Interestingly, the famous Lucent (via Western Electric, not Bell Labs) 5ESS telephone switch is another example of a prominent functional programming success story. If you’ve placed a phone call to or in the United States in the last 30 years, chances are you used one of these devices, and the code that keeps its database (with more than 1,000 relations) consistent, was written in a custom language called Pdiff, which in turn was written in Standard ML.
That brings us to another area where functional languages seem to shine: domain specific languages (DSLs). If your problem domain is so hairy that the usual design patterns we’re used to in typical enterprise languages like Java and C/++ fail to efficiently solve them, a DSL might be just the trick. You wouldn’t build your whole system with a DSL, but, like the 5ESS switch, you could use it to code a critical function in a way that is easier to understand and maintain and, therefore, ensure its quality. Functional languages are killer at creating DSLs.
One interesting example I found is a DSL to process exotic financial derivatives. This illuminates another area where functional languages/approaches shine: math-heavy algorithms. If you need to solve a problem that can decompose into a series of mathematical operations, the kind of thing you’d tackle with a DSP chip or GPU, then a functional language is likely a good choice for expressing the solution.
Another way to think about this kind of problem is: Could you solve it, at a small-scale, with a spreadsheet? If the answer is yes, then you’ve got two choices: get a product that can compile spreadsheets into your platform of choice (many exist), or express it in a functional language. This is a useful analogy, because it highlights how functional languages (which seem so math-centric) can handle operations we’re used to in other languages, like conditional statements. If you’ve ever used the IF function in a spreadsheet, then you have your answer. Functional languages, like the other kinds, are Turing Complete, and can be used to code any problem. The trick, it seems, is to code different parts of your system in languages that are most effective at expressing that part of the problem domain.
Great, so, I’ve got you interested in functional programming, now what the heck do you? When trying to build a new capability within my team, my preferred approach is to identify a potential pioneer. Someone who can grok the new ideas, drink the proverbial punch, and then bring that knowledge back to the team and evangelize. Send that person out for training, and then (as I think you should do with any training course) have them share what they learned with the team (buy them all a meal at the same time too, it helps). But only do so when you’ve identified a project or task where a functional approach makes sense. If folks don’t start to use what they’ve learned within 30 days, it’s likely gone.
If you want to incorporate functional code into your larger system, one approach is to have the language compile into the same bytecode as your main system; Scala runs on JVMs, and there is F# for the .NET CLR (and other platforms). You can always just run your code in one of the other functional language environments (such as Haskell, Clojure, OCaml, etc.) and expose it with a REST API as well.
Aucun commentaire:
Enregistrer un commentaire