How do you tests functional patterns in TDD, or maybe better question is how do you drive your code by TDD to functional patterns?
For me it seems that all TDD movement is more in OOP side, but I wonder about good techniques for FP and TDD.
Write a single failing test.
Write the simplest code that passes.
Refactor.
There's nothing in there about OOP, FP, or any other programming paradigm.
Related
I'm struggling with understanding the difference between functional and imperative programming. From reading https://www.sitepoint.com/what-is-functional-programming/ I see that there are a number of principles in functional programming that I use all the time in what I thought was an imperative programming.
I've read that functional programs use pure functions, so does that mean every time I make or use a pure function I'm writing in the functional paradigm?
I've also passed functions in and used them as first class objects, does that mean I was writing in the functional paradigm?
I pretty much use all of the functional paradigm principles in my code, but I never thought I was doing functional programming. Is the act of using any of these functional programming principles considered the functional programming paradigm?
Functional principles are just techniques and ideas. These are the bread and butter of the functional programming paradigm, which is what happens when you take these tools and use their unique advantages to gain systemic advantages.
A pure function is just a function with no side effects. You've written a million of these. But now, if you write only pure functions, your app can be split across processing cores with no effort or risk.
You've used constants before. But if you almost always use constants, then the things that are variable are the only things you have to think about when tracing code, and that is quite an advantage.
And you've chained functions before, but when you make everything pipe-able your entire language begins to feel like wiring up data flows, rather than giving the computer step-by-step instructions. This is much easier for humans to reason about and is less error-prone.
The techniques always have their advantages. When they become baseline assumptions, those advantages multiply. That's the functional paradigm.
Moving my comments here for clarity:
good question! In this article medium.com/#charlesbailey333/… it talked about how Rust had advantages over C++ because it incorporates functional programming ideas better. The evidence they give is that it supports Map, Reduce, and Filter. It almost seems like they're saying that those functions are "functional programming functions", but I don't think those functions are anything special. – Joshua Segal 16 mins ago
Okay great! This I can help with. SO this author is struggling to use the actual term for what they're referencing. It's called "expressiveness". Basically it means how close is the code I'm writing to the mental model of what I'm doing? For example, you want to give someone directions on how to get from A to B. Ideally, you do this by expressing it in turns and street names. However, if your language forces you to express this using the angle of the accelerator pedal and the angle of the steering wheel, this is much clunkier to do. C++ did it clunky. Rust did it elegantly and expressively.
In general, the functional and declarative languages tend to be much better at "expressing" your ideas in code and visually. You have branching paths? Your code literally looks like a branching tree. You have a data flow with a transformer? Guess what friend, that's just a function that transforms X to Y and a some sort of pipe operator that takes care of looping and new info.
The thing is, expressiveness isn't a statistic or something you can optimize for. It's an emergent "feeling" when using the language. The paradigms are general principles that tend to be internally consistent that produce useful "feelings". FP feels like flowing pipes and transformations. OOP feels like gadgets and features that talk to each other. The different mental models have different uses. FP is better for data processing. OOP can be good for UI and stateful services. At the boundaries they can clash a little, which is where the clunk comes from in C++.
At this point anything that is "completely OOP" or "completely FP" is usually shit, to be frank, so it can be a little hard to see the identities of the two when they are so merged. If you do complete OOP you can't compose anything and you have to write a million connector classes. If you do complete FP you can't modify state or have side effects (like... uh... showing stuff on screen?). These are genres. What makes something a house beat? If something else uses a house beat is it automatically house music? Does anyone care about the categorization?
I am looking for a problem to solve which enables me to try out various programming languages and having a means to compare the pros & cons of them. This is similar to ToDoMVC which does the same task with various MVC frameworks.
Lisp 99 Problems looks pretty good but am looking for interesting suggestions that might take on a real world problem and be a touch less mathematical. Failing that, I might tackle a few of these anyway.
Programming languages I'm looking to try this with:
Haskell
Clojure
Javascript
Erlang
Scala
Elm
I've been reading up on functional programming a lot recently, and I finally decided that the best way to understand it is probably just to start using it. I spent some time looking at different reviews of functional languages, and I think I've settled on Haskell because of its supposed elegance and the fact that it seems to be the go-to pure functional language. Most recently I've been coding in Java, Python, and Perl, so I figure for this exercise I might as well pick a language that forces me to only use functional programming ideas rather than something like Scala or Lisp that also supports imperative programming (but if anyone has thoughts or opinions about this, I'd love to hear them).
Anyway, the whole point for learning the ideas of functional programming (for me at least) is that I've always heard that some problems are more naturally solved in that way. And I've always found that it's better to learn new things by applying them somehow rather than just going through mindless tutorials. So, that being said, what are some straightforward problems/projects that I can do to learn the essence of functional programming?
Try working through the Project Euler challenges. They get harder as you go, so tackling them one by one from a functional programming point-of-view would probably be a very good way of learning.
I have a free time and would like to do functional programming and learn some functional programming language.
But as we know the best theory it is practice. In this regard, I would like to know in which sector is most often used functional programming? I understand if the project is written in a functional language that is somehow justified. Therefore, such a question: what kind of projects easier and more profitable to write in functional languages?
Thank you
Compilers are often referred to as the "killer app" for functional languages with algebraic data types, like Haskell and ML. I have written compilers in a procedural language, in an object oriented language, and in functional languages, and a functional language is worlds better.
A compiler is also a relatively attractive project in that you can pick up, say, Andrew Appel's book on the used market, and build the whole thing yourself—just be sure to compile a very simple language.
interpreters, hand-written recursive descendant parsers, program analyzers
AI, data processing, scientific/financial/computationally intensive applications.
Financials, Statistics, and Scientific Computation are the three areas where Functional Programming are used the heaviest.
You could always throw together a simple statistics calculation package that works against one of the various social networks out there. An F# stats application against the StackOverflow would be an interesting project...
I thought the whole idea was to have only computation with NO state and NO side effects. Now if a Clojure app(or even worse, a reusable Clojure library ) can use and create any Java object, how can I be sure I don't get side effects or state ?
FP is a paradigm, a concept, but not necessarily a dogma. Clojure trusts the programmer to make thoughtful decisions about where he'll depart from FP. In exchange, Clojure offers the staggering cornucopia of code that is available in the form of Java libraries. This makes it relatively easy and painless to write a GUI app in Clojure, say, or a Web server or any of the things covered by Java library code.
Note that the Java "hole" is not the only escape hatch Clojure offers from FP: References and atoms hold state and Clojure offers functions to change it under controlled conditions. I think this pragmatic approach makes Clojure useful and will help make it popular.
You cannot be sure, apart from consulting documentation or using a java decompiler(?). This ability certainly defies the idea of pure functional programming, but the real world is not a particularly pure place and purely functional languages can't get much traction against it. Witness all the contortionism with monads in Haskell. Besides, mutable state is very powerful computationally — many algorithms become much faster and much more economical of memory when implemented with mutable state.
Clojure is not a pure functional programming language. What you said would stand in Haskell, but not in Clojure. Clojure encourages functional programming, but it doesn't force it. Clojure is built to help you program in a functional style, but also to allow you to actually get stuff done. Clojure makes sure that when you use state, you have to be explicit about it. If you want to be sure that you're programming purely functional, you have to make sure yourself. Clojure isn't pure, so it doesn't promise purity.
Because Clojure is meant for the real world it makes compromises, and therefore it isn't a pure functional language.
Haskell was made as a proof that it was even possible to make a pure functional programming language that could work in the real world, so if pureness is what you desire, your journey should take you there.
Referential transparency (which is a consequence of the lack of side effect) isn't the only motivation for functional programming. The concept of lazy evaluation is thought to be one of the central features of the functional style since it allows you to modularly construct programs.
In other words functional programming is at least as much about generic programming as it is about providing static safety guarantees. I'm pretty sure you already knew this, but I thought it might be appropriate to articulate the idea.
Allowing side effects is a bit of a trade-off which you need to justify for yourself. Many applications do need to deal with quite a lot of stateful computation, some languages are just more strict about dealing with this than others.
Functional programming has been around for years and years in varying degrees of "purity" sort of waiting for a killer app. Clojure explicitly embraces a specific application of functional programming, that is it focuses on single address space parallel programming and it's FP paradigm really shines in this area. Much of the java world is single threaded and hence does not need this tool.
So yes you are absolutely correct Clojure breaks the functional paradigm when it calls to java, because it doesn't really need FP for these parts and because the rest of the world provides so very much good code that also does not need Functional Programming.