Historical errata for Functional Programming: A PragPub Anthology

In the last paragraph, second sentence, there is a missing word “you” before the word “need”. It should say ,“Instead of FP being seen as the strange way you need to write in order to deal effectively with parallelism, …”

This example:

public int incrementCounter(int counter) {
return counter;
}

Causes unnecessary consternation for polyglot programmers, because this post-increment usage is idiomatic only in certain languages - those in which counter is passed by value or copied, and is completely decoupled from the actual argument passed to the function.

If some OO languages were to treat int as a reference type, or the argument was a string or an object, implicitly passed by reference, then this example is equivalent (negatively so) to the example just following it, where the increment changes global state.

This is a whole lot of conceptual overhead to wade through, when, for the purposes of illustration, the body of the function could simply be:

return counter + 1;

One of the cool features of this code is in the get_response function.

There is no get_response function anywhere in the code.

“…This makes macroprogramming, an inherently difficult activity, about as easy
as it’ll ever get. …”

I think, it was supposed to mean “an inherently EASY activity” - after all that seems to be the USP of Clojure :)

“but it does requires a different way of thinking about problems,”

“requires” should be “require”

“Instead of FP being seen as the strange way need to write in order to deal effectively with parallelism”

Possibly change “need” to “needed.” The sentence doesn’t read smoothly with “need.”

“What’s we’ve just done with the filter method and Predicate interface simulates
a concept from the functional world”

“What’s” should be “What”

In Chapter 12 Getting Parallel with Elixir code example elixir/spawn7.exs is reproduced twice. The second instance on PDF page 94 should be replaced with code example elixir/spawn8.exs

elixir/spwan7.exs example is shown twice. There is no elixir/spawn8.exs example is not shown but in page 91 - it still say “$ exlisir spawn8.exs”

( Also - it is a bit hard to jump from spawn7.exs to spwan8.exs - complexity is a bit to hard to follow )

“A higher-order function is a function that can be passed into, or returned from, another function.”

Mentioned in www.amazon.com/gp/customer-reviews/R16AP8TE2ALDSG/ref=cm_cr_getr_d_rvw_ttl?ie=UTF8&ASIN=1680502336

The above definition is incorrect. A HOF is a function that can take functions as input, or return functions as output.

This concerns the practical example about stock prices in Chapter 3. At the bottom of the page is the following method definition:

def isNotOver500(stockPrice : StockPrice) = stockPrice.price < 500

The method name and body conflict, as the method would return false if stockPrice.price == 500. The body also conflicts with the description of the method on page 20 that reads “The isNotOver500 will return true if the price is less than or equal to $500, false otherwise.” The <= operator should be used in the method body instead.

In the paragraph describing the apply and update methods, the final sentence reads “For a collection, the update method takes an index and returns a reference to the object at that position.” This is incorrect. Since the paragraph discusses list collections (e.g. scala.collection.mutable.Seq), the sentence should instead say that the update method takes an index and a new element to insert into the list at the given index.

In the paragraph describing the apply and update methods, one sentence reads “For a collection, apply takes an index and returns the value at that position.” The sentence should specify that this is for list collections (e.g. Seq) since collections like Map and Set don’t have indexes. Map uses the apply method for a similar purpose (takes a key and returns the corresponding value) while Set uses the apply method to check if it contains a given element.

When explaining the assoc function for maps with an example that creates a map new-mike from a map mike with some keys overwritten, the last sentence states that “the existing new-mike is not affected.” What should be said is “the existing mike is not affected” since mike existed before the assoc function was called and new-mike was made.

Under the Get an Agent section, just before the first code example, a sentence reads, “Here we create an atom version of our counter, and a function to increment it.” The sentence should read, “Here we create an agent version…” because this section concerns agents, not atoms.

In this quote on how functional languages deal with mutation, the claim is made that Haskell deals with side effects by using monads.

“Practical functional programming languages emphasize immutability and functional purity, but they must have some means of modeling a changing world that stops short of total functional purity. In Haskell, probably the most strict functional language, you can model change using monads, and otherwise maintain strict purity.”

This is a common misconception and is actively harmful for people trying to learn about monads. Monads are NOT a way to deal with mutations or side effects. Haskell’s approach to dealing with impure computations (sometimes called “effects as data”) is it’s own standalone concept. Monads make it easier to sequence these effects but they are NOT themselves the effect system.

Conflating the two concepts makes them both harder to understand and learn. This is not helped by a lot of the language used in the Haskell community where the effect system is often described as “the IO monad”.