As my interest in functional programming grew, I knew a good way to
understand it is to write about it. In this series, I've been
exploring how functional programming impacts Java and the related
ecosystem.

java.Next

Many languages vie to replace Java as the primary way we manipulate
the Java virtual machine, but choosing between them is
daunting. This series attempts an "apples-to-apples" comparison
between Groovy, Scala, and Clojure, to help developers
understand which is the best tool for their job.

Applying patterns to presentations was a stretch, another in a long string of potentially specious relationships between things that pop into my head from time to time. Yet, I couldn't give this idea up. Despite myself, I continued to identify patterns (and anti-patterns) in my own talks and others. I thought about writing it down, but at the time, the concept was still restricted to technical presentations, and I realized the audience for such a book would be entertaining to many of my presenter friends, but to not many other people. But then I realized that all professionals must do presentations at one time or another. more...

Creating a technology radar for yourself helps you formalize your thinking. . .You should treat your technology portfolio like a financial portfolio (in many ways, they are the same thing). . .Most C-level types get more advice from sales men than people in their own company. . . While this is a wild fantasy, wouldn't it be great if one of the formalities during job interviews became the trading of radars, personal and company, as a way for each to assess the other? more...

Maven is opinionated, rigid, generic, and dogmatic, which is exactly what is needed at the beginning of a project. Before anything exists, it's nice for something to impose a structure, and to make it trivial to add behavior via plug-ins and other pre-built niceties. But over time, the project becomes less generic and more like a real, messy project. Early on, when no one knows enough to have opinions about things like lifecycle, a rigid system is good. Over time, though, project complexity requires developers to spawn opinions, and tools like Maven don't care. more...

I'm convinced that the iPad is the first iteration of the next major computing platform. PC's will become work and power user tools, but everyone will use iPad-like things for many tasks. This is the first incarnation - can you imagine what these things will look like in 5 years? more...

Finding a good system that doesn't get in your way yet allows you to organize all the things going on in your life (both personal and professional) is surprisingly difficult, given the number of tools that purport to do just this. more...

When a community fades, the fanaticism of the remaining members increases proportionally for every member they lose, until you are left with one person whose veins stick out on their forehead when they try to proselytize people to join their tribe, which rocks, and leave that other tribe, which sucks. more...

This series aims to reorient your perspective toward a functional mindset, helping you look at common problems in new ways and find ways to improve your day-to-day coding. It explores functional programming concepts, frameworks that allow functional programming within the Java language, functional programming languages that run on the JVM, and some future-leaning directions of language design. The series is geared toward developers who know Java and how its abstractions work but have little or no experience using a functional language.

Learning to think like a functional programmer

Functional programming has generated a recent surge of interest with claims of fewer bugs and greater productivity. But many developers have tried and failed to understand what makes functional languages compelling for some types of jobs. Learning the syntax of a new language is easy, but learning to think in a different way is hard. In the first installment of his Functional thinking column series, Neal Ford introduces some functional programming concepts and discusses how to use them in both Java and Groovy.

Exploring functional programming and control

Functional languages and frameworks let the runtime control mundane coding details such as iteration, concurrency, and state. But that doesn't mean you can't take back control when you need to. One important aspect of thinking functionally is knowing how much control you want to give up, and when.

Filtering, unit testing, and techniques for code reuse

Functional thinking series author Neal Ford continues his guided tour of functional programming constructs and paradigms. You'll look at number-classification code in Scala and take a glance at unit testing in the functional world. Then you'll learn about partial application and currying — two functional approaches that facilitate code reuse — and see how recursion fits into the functional way of thinking.

Thinking functionally, Part 3

Make Java code more functional by changing less

Immutability is one of the building blocks of functional programming. This Functional thinking installment discusses the many aspects of immutability in the Java language and shows how to create immutable Java classes in both traditional and newer styles. It also shows two ways to create immutable classes in Groovy, removing much of the pain of the Java implementation. Finally, you'll learn when this abstraction is appropriate.

Exploring the implications of natively coupled abstractions

Summary: Working every day in a particular abstraction (such as object orientation) makes it hard to see when that abstraction is leading you to a solution that isn't the best alternative. This article is the first of two that explores some implications of object-oriented thinking for code reuse, comparing them to more-functional alternatives such as composition.

Object-oriented vs. functional building blocks

Programmers accustomed to using the building blocks of object orientation (inheritance, polymorphism, and so on) can become blind both to its shortcomings and to alternatives. Functional programming uses different building blocks to achieve reuse, based on more general-purpose concepts like list transformations and portable code. This installment of Functional thinking compares coupling via inheritance with composition as reuse mechanisms, and pinpoints one of the key differences between imperative and functional programming.

Treasures lurking in Groovy

Over time, languages and runtimes have handled more and more mundane details for us. Functional languages exemplify this trend, but modern dynamic languages have also incorporated many functional features to make developers' lives easier. This installment investigates some of the functional features already lurking in Groovy, showing how recursion hides state and how to build lazy lists.

Metaprogramming + Functional Java

With Groovy, metaprogramming and functional programming form a potent combination. See how metaprogramming enables you to add methods to the Integer data type that take advantage of Groovy's built-in functional capabilities. And learn how to use metaprogramming to incorporate the Functional Java framework's rich set of functional features seamlessly into Groovy.

Memoization and caching

Modern dynamic languages have incorporated many functional features to take mundane tasks off developers' hands. This article explores the benefits of caching at the function level with Groovy, contrasting it with an imperative approach. It illustrates two types of caching — intramethod and external — and discusses the advantages and disadvantages of the imperative and functional versions.

How patterns manifest in the functional world

Contrary to popular belief, design patterns exist in functional programming — but they sometimes differ from their object-oriented counterparts in appearance and behavior. In this installment of Functional thinking, Neal Ford looks at ways in which patterns manifest in the functional paradigm, illustrating how the solutions differ.

Same problem, different paradigms

Design patterns represent just one way to solve problems, but if you primarily use object-oriented languages, you may come to think in design patterns. In this installment of Functional thinking, Neal Ford illustrates solutions to a common problem — incompatible interfaces — using traditional design patterns, metaprogramming, and functional composition. Each approach has pros and cons, but thinking about the design of the solutions helps you see problems in new ways.

The Interpreter pattern and extending the language

The Gang of Four's Interpreter design pattern encourages extending a language by building a new language from it. Most functional languages let you extend the language in a variety of ways, such as operator overloading and pattern matching. Although Java doesn't permit any of these techniques, next-generation JVM languages do, with varying implementation details. In this article, Neal Ford investigates how Groovy, Scala, and Clojure realize the intent of the Interpreter design pattern by allowing functional extensions in ways that Java does not.

Type-safe functional exceptions

Java developers are accustomed to handling errors by throwing and catching exceptions, which doesn't match the functional paradigm. This Functional thinking installment investigates ways to indicate Java errors functionally while still preserving type safety, shows how to wrap checked exceptions with functional returns, and introduces a handy abstraction named Either.

Using Either and generics to create Scala-style pattern matching in Java

Scala's ability to perform dispatch based on pattern matching is a feature much envied by Java developers. This installment shows how a combination of standard data structures and generics provides a pattern-matching-like syntax in pure Java.

How next-generation JVM languages add nuance to method dispatch

Next-generation languages for the Java platform have more-flexible method-dispatch mechanisms than the Java language. In this Functional thinking installment, Neal Ford explores dispatch mechanisms in functional languages like Scala and Clojure, showing new ways to think about executing code.

Synonyms hide similarities

Functional programming constructs are appearing in all major languages now, but they can be hard to spot because they're identified by a wide variety of common names. This installment of Functional thinking shows the same example written using seven different functional frameworks and languages, investigating similarities and differences.

More functional comparisons across languages

Various functional languages and frameworks feature many of the same abstractions and behaviors but name them differently. In this Functional thinking article, series author Neal Ford optimizes the solution from the preceding installment by improving the algorithm and adding caching, illustrating how each language or framework accommodates the required changes.

java.Next

Martin Fowler makes a perceptive observation: the real legacy of Java
will be the platform, not the language. More than 200 languages run on
the JVM now, and its inevitable that one of them will eventually
supplant Java as the best way to program the JVM. Even if that doesn't
happen and Java evolves, it will take on features and characteristics
found in next-generation languages on the JVM.

This series explores 3 next-generation JVM languages: Groovy, Scala,
and Clojure, comparing and contrasting new capabilities and
paradigms. This series will enlighten Java developers with a glimpse
into their own near future, providing scaffolding to learn and
incorporate new concepts.