Kevlin Henney

The idea of starting from 0 and then defining a successor function is the basis of Peano numbering. Interestingly, the original λ paper did not use 0, but it is consistent with (and included in) most presentations of Church numerals. I find myself agreeing about being suspicious of number systems without 0... although, that said, I have a soft spot for Roman numerals 😉

Eiffel did not originally include any lambda/block/closure kind of object and, if anything, appeared stylistically opposed to anything that might smack of brevity and convenience! It was a language that made Pascal look compact. It did later (Eiffel 3 onwards?) adopt a number of conveniences, including lambda-style constructs.

Yes, that each of these pieces is a starting point rather than a finish line is very much the idea of the book.

Exactly! When Java 8 added lambdas, Java did not be come functional; it became more object oriented. See my talk, Lambda? You Keep Using that Letter: https://www.youtube.com/watch?v=orcSUE0Jjdc

The short answer is 'yes'. Sometimes what I learn is factual, because it is a consequence of nature that we can't know everything. Someone will surprise us with something we simply hadn't considered or lacked the right depth of knowledge for. But sometimes what we learn is down to perspective and presentation. Even presenting on a topic that you already know, someone else will have a perspective that will inevitably be different to your own, and you can visit a familiar topic in a way that makes it new.

The 97 came from the original discussion that led to the series. On Bruce Eckel's programming list, Richard Monson Haefel was trying to compile 10 things every software architect should for a talk. He received so many ideas that he thought it might make a good book. When it came to number, he wanted a number that was around 100, but not trying too hard not to be 100 (e.g., 99 and 101), so 97 was chosen!

It is difficult to fit a simple flow to the many diverse topics, so we chose the order that would be fairest and also the easiest to refer back to. I did this with 97 Things Every Programmer Should Know and we did the same for 97 Things Every Java Programmer Should Know. Because the topics are so short, the range and diversity of subject matter you can cover in one sitting has a rounded completeness to it!

It took us some time to settle on the message and those simple words for the dedication. So thank for your comments.

It's impossible to know everything, and keeping up to date with every paradigm, framework, etc. may not even be the right way to pursue knowledge. There are, in fact, a couple of pieces in the book that deal with learning and navigating the vast quantity of change and information out there. My personal take is that it helps to consider what you need to keep up with. Prioritise and separate out things you want to specialise and dive deep into from the things where you are happy to pick up tourist-level knowledge, and those from things where awareness that they exist is enough. You will your priorities change with time and as your knowledge grows.

As Trisha said, "It depends". And it really does! What each person knows and needs to know is dependent on so much more than will fit in a simple answer. What we hoped in the book was to be able to offer people a large enough sample and cross-section of what we think people should know, and in that people will be able to find their own path.

You're welcome! Thank you.

We used the limit of no more than three included in the book because this ensured that more voices were heard. I introduced this limit for 97 Things Every Programmer Should Know after I observed that contributions roughly followed a power law (actually, IIRC, it was an inverse square law), so a few people submit many (two people contributed nine pieces each!) and most people submit one. If you place a threshold on a skew distribution, it shifts the mean hugely. As a result, 97 Things Every Programmer Should had 73 contributors, where other books in the series tend to have contributors numbering in the fifties. When we started 97 Things Every Java Programmer Should Know, it made sense to be upfront about the publication limit. By an extraordinary coincidence, we also ended up with 73 contributors. That limit of three has meant that these two books have the greatest representation of any of the books in the 97 Things series.

The books are very different. The advice in 97 Things Every Programmer Should Know can be said to be broader and not tied to specific languages or libraries. As its title says, these are things every programmer should know, so although some advice will use a specific language or technology to make its point, these are to make examples concrete; the points are transferable. With 97 Things Every Java Programmer Should Know, the focus is much more specific to the Java language, JVM platform (e.g., VM performance and GC) and Java communities (e.g., JUGs and the JCP). Pieces are more specific, and there is more code. There are pieces that are more general, or whose points could equally apply elsewhere, but these points that a Java programmer should also know do not form the majority.

To add to what Trisha said, I can report that 97 Things Every Programmer Should Know has been used as a lunchtime session / book club book in a number of companies. We can hope that 97 Things Every Java Programmer Should Know will enjoy a similar future!

Paradigms are not strictly disjoint and the paradigm landscape is richer and more varied than many people expect. For example, Java's OO paradigm is very different to, say, Python's, and Excel's expression of functional programming is very different to Haskell's. There is a lot of variety and range!

So to add to Trisha's "It depends" we need to understand that Java has a number of features that better support OO than FP. It is unlikely Java will ever be a functional programming language and there is a lot in the existing language that works against functional programming. For example, by default Java is imperative in how it treats its data. Changing such a default is like changing the laws of physics. It would break everything, and for minimal value. Java also doesn't support functions! This is the most basic construct in functional programming, but Java only permits classes and interfaces as top-level constructs.

Certainly, Java can be programmed in a way that is influenced by FP, and Java 8+ makes this easier. Adding lambdas and streams brings Java closer to FP, but neither streams nor lambdas are specific and unique to FP. If you look at blocks and collection pipelines in languages such as Smalltalk and Ruby, it looks more like Java is becoming more OO!

The contributions to 97 Things Every Programmer Should Know are licensed under Creative Commons Attribution, and so the contributions may be shared appropriately. That github repo is taken from the GitBook version (https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/) which in turn was taken from the original Wiki (since taken down) for the book.