Once you go functional, you can never go back

The &quot;six distinct features of a functional language&quot; are misleading&#x2F;inaccurate:<p>1. Laziness: Not required. See Lisp, Scheme, ML, OCaml, etc.<p>2. Functions as first-class citizens: This is probably the only hard and fast requirement.<p>3. No Side Effects: Not required. Again, see Scheme, ML, and Rust.<p>4. Static Linking: Certainly not, but the author seems to mean static <i>binding</i>, which is more important. However, a functional language doesn&#x27;t actually need any binding aside from function invocation (see Lambda Calculus). `Let` bindings are generally available and very useful.<p>5. No explicit flow control: Function invocation <i>is</i> flow control. Loops aren&#x27;t functional, but some functional languages have them.<p>6. No commands&#x2F;procedures: If the author means &quot;no top-level function definitions&quot; that is clearly not true. Some functional languages even have macro languages.<p>This article gives the (incorrect) impression that functional programming is about a set of restrictions you must follow 100% of the time. Functional programming is a style that can be used in any language, as long as you can pass functions around as values. It wasn&#x27;t pretty, but Java &lt;=1.7 could still support a functional programming style by using `Callable` objects.<p>The `map` and `reduce` operations are certainly possible in imperative languages. Python has them built-in, they can be written in C++, and so on.

I feel a bit sorry for people getting introduced to &quot;functional programming&quot; from the imperative world. The plethora of language features available in FLs distracts them from the main <i>endeavour</i> of FP - which is modeling your problem domain in terms of function <i>composition</i>.<p>With that perspective, one can do FP in pretty much any language and reap all of its conceptual and engineering benefits. Without that perspective, one can end up completely avoiding functional modeling of the problem domain at hand when using a language tailored to FP and end up faring no better than when using a language encouraging imperative style.<p>FWIW ..<p>&gt; Fibonacci sequence in LISP-oid Scheme<p>.. has exponential complexity whereas the C version runs in O(n).<p><pre><code> long fib(long n) { return n &lt; 2 ? n : fib(n-1) + fib(n-2); } </code></pre> .. is the C equivalent of the same badly performant fib implementation.

&gt; Since this is impossible in imperative languages, I can&#x27;t give you a comparison.<p>I&#x27;ll bite. Here&#x27;s foldr() in JavaScript, written in an imperative style:<p><pre><code> function foldr(func, list) { var r = []; for(var index = list.length-1; index &gt;= 0; index--) { r = func(list[index], r); } return r; } </code></pre> It isn&#x27;t defined via pattern matching, but it&#x27;s absolutely a higher-order function. Functional programming is a collection of ways of thinking about problem solving, and it can be applied to any language.

IIUIC, the example they give of recursively calculating the Fibonacci series is pretty much _the_ textbook example of how not to use recursion --- it&#x27;s O(2^n) and doesn&#x27;t use tail calls, which means it&#x27;s slow and will gobble memory.<p>Actually calculating the Fibonacci series efficiently in a non-lazy functional language looks surprisingly non-trivial. In Haskell it&#x27;s pretty simple:<p><a href="http:&#x2F;&#x2F;blog.srinivasan.biz&#x2F;software&#x2F;fibonacci-numbers-the-slow-way-or-the-fast-and-lazy-way" rel="nofollow">http:&#x2F;&#x2F;blog.srinivasan.biz&#x2F;software&#x2F;fibonacci-numbers-the-sl...</a>

I love FP, but it always seems a bit disingenuous to claim that it is &quot;pure&quot;. Most programs raison d&#x27;être is to do IO (that is to say to have side-effects), so by construction most programs are impure.<p>Bjarne Stroustrup has a say about C++: you don&#x27;t pay for what you don&#x27;t use. I like to think about it that way for FP: you don&#x27;t pay for side effects you don&#x27;t use.

&gt;As you can see, notation in functional languages is much closer to classic mathematical notation.<p>I&#x27;m yet to be convinced that this is a good thing.

As someone who worked with OCaml and C++, and now working with Scala, I must concur.<p>First weeks or months are hard, because you have a lot of new mechanism (and syntax) to learn. Then, when things gets easier, designing reusable components with function composition become almost systematic. In the end, you&#x27;ll be able to write code that feels like poetry (it&#x27;s very difficult to put words on that feeling, so I understand if it sounds like a bad piece of propaganda to you).

This statement seems wrong:<p>&quot;Functional programming languages fall under the declarative languages category, meaning algorithms are written in form of relations between steps&quot;<p>The author also notes that productivity is a pro of FP. While I like much of the elegance of languages like Haskell and Lisp, its never been clear if it is actually more productive in writing real code -- and if so is it grossly more productive, or only by small margins.

The difference between his two fibonacci implementations is recursiveness, not &quot;fp-ness&quot;. You could write fib in a imperative style that is close to the mathematical definition and readable to boot, for example, in ruby:<p><pre><code> def fib(n) case n when 0, 1 n else fib(n-1) + fib(n-2) end end puts fib(10) # =&gt; 55</code></pre>

Seeing all this incorrect Scheme code hurts...<p><pre><code> (define (lastHalf L N) (if (= N 0) L); Base Case (if (or (= N 1) (&lt; N 2)) (cdr L) ;else (lastHalf (cdr L) (- N 1))) ) Would be: (define (last-half L N) (if (= N 0) L (if (&lt; N 2) (cdr L) (last-half (cdr L) (- N 1)))))</code></pre>

While Haskell is undoubtedly better suited to writing concise implementations of sorting algorithms, the C++ versions given could have been written in a much shorter and clearer fashion.

<i>&quot;In order to call a language purely functional, it has to have 6 distinct features&quot;</i><p>Is there an international standard or a some sort of formal proof?

I&#x27;m not sure if there&#x27;s anything inherently imperative about OO, as the author seems to imply. In addition, I&#x27;m not sure just how distanced most FP languages are from the von Neumann model. I know APL, J and K are categorically non-von Neumann.<p><i>Static linking<p>All variables are allocated at compile time and are statically linked. No need to go into more details.</i><p>I think they meant static binding?

&#x27;Functional&#x27; means a different way of <i>thinking</i>, not of coding.)<p>Also Functional != Haskell. Its laziness messed everything up. Functional subset of Scheme (without set!) is better to grasp the essential ideas (not cluttered with irrelevant types or cryptic syntax).

I&#x27;m not sure if this counts as going &#x27;functional&#x27; but after having done the FP Scala course I tried out lodash, and now its the <i>default</i> dependency in all my web projects :D

Haskell is fun to play with, but most definitely isn&#x27;t on the list of &quot;languages the boss will actually let you use if you ask nicely.&quot; The JVM FP languages like Scala and Clojure are probably more worthwhile to learn, from that perspective (maybe F# if you&#x27;re in .NET-land).<p>I learned Haskell first (man, what a slog that was) to come to grips with FP, then Scala so that I would actually have the opportunity to use a bit of functional programming on the job.<p>Update: Downvotes? Apparently I said something controversial here.

It&#x27;s a me, the author. Let me start.<p>First of all, I would like to address the 6 distinct features I was talking about in the theoretical introduction. Those 6 features&#x2F;rules are described in the same way in a book called &quot;Introduction to Scheme&quot;. I&#x27;m guessing I haven&#x27;t explained it very well. Basically, what I meant is that those are the rules functional languages should follow in order to be called pure functional languages. I didn&#x27;t say that that is the case with most languages, nor that this is the case with Haskell or Scheme. I know most of them don&#x27;t, but that&#x27;s just a piece of theory. And yes, I did mean static binding, I apologize, since linking and binding are denoted by the same word in my language.<p>Next thing, about the algorithms. Fibonacci example was just to show closeness to mathematical notation and I know it&#x27;s probably the worst way to use recursion because of the O(2^n) time complexity. But, again, complexity was not the point of the example. About the notation, I&#x27;m guessing it&#x27;s just me then. I was a lot more comfortable with pure mathematical notation, as I like things to be formal as much as they can, and that&#x27;s something that mathematics provide.<p>The whole point of the post itself was to give a small introduction to functional programming and show off features that may not be available in most imperative languages.<p>Of course, as I&#x27;ve also said in the outro, I&#x27;m not really planning on switching to purely functional languages, I was just trying to say that they can be fun in some situations and for some problem solving. The different way of thinking is what makes it so fun, at least for me.<p>About higher-order functions, I truly was mistaken, as I&#x27;ve thought that was a thing for functional languages only. Guess I don&#x27;t have that much experience in the imperative world, as I&#x27;ve never came across them in my line of work.<p>So please, don&#x27;t take this article as anti-imperative, as it&#x27;s most certainly not.<p>So, tl;dr, I instantly liked functional programming and I wanted to share some features that I liked the most, and haven&#x27;t seen in imperative way.<p>I do apologize for misleading&#x2F;possibly incorrect parts, and I shall edit those in my earliest convenience.

That is not a good font. Very hard to read on my screen (non-retina).

`reduce` is rather `foldl` than `foldr`.

&gt; Few months ago, I came across a new paradigm (to me, at least) called functional programming.<p>You can never go back, at least from the perspective of someone two months into learning it.