"functional" entries
3 simple reasons why you need to learn Scala
How Scala will help you grow as a Java developer.
With Scala Days nearly upon us, the Fort Mason Center in San Francisco will be awash with developers excited to share ideas and explore the latest use-cases in this “best of both worlds” language. Scala has come a long way from its humble origins at the École Polytechnique Fédérale de Lausanne, but with the fusion of functional and object-oriented programming continuing to pick up steam across leading-edge enterprises and start-ups, there’s no better time than right now to stop dabbling with code snippets and begin mastering the basics. Here are three simple reasons why learning Scala will help you grow as a Java developer, as excerpted from Jason Swartz’s new book Learning Scala.
1. Your code will be better
You will be able to start using functional programming techniques to stabilize your applications and reduce issues that arise from unintended side effects. By switching from mutable data structures to immutable data structures and from regular methods to pure functions that have no effect on their environment, your code will be safer, more stable, and much easier to comprehend.
Read more…
Java 8 functional interfaces
Getting to know various out-of-the-box functions such as Consumer, Predicate, Supplier
In the first part of this series, we learned that lambdas are a type of functional interface – an interface with a single abstract method. The Java API has many one-method interfaces such as Runnable, Callable, Comparator, ActionListener and others. They can be implemented and instantiated using anonymous class syntax. For example, take the ITrade functional interface. It has only one abstract method that takes a Trade object and returns a boolean value – perhaps checking the status of the trade or validating the order or some other condition.
@FunctionalInterface
public interface ITrade {
public boolean check(Trade t);
}In order to satisfy our requirement of checking for new trades, we could create a lambda expression, using the above functional interface, as shown here:
ITrade newTradeChecker = (Trade t) -> t.getStatus().equals("NEW");
// Or we could omit the input type setting:
ITrade newTradeChecker = (t) -> t.getStatus().equals("NEW");
Fun, functional, and teachable?
Can Elixir bring functional programming to a much wider audience?
I was delighted to talk with Dave Thomas, co-founder of the The Pragmatic Programmers and author of their in-progress Programming Elixir. I’m writing Introducing Elixir for O’Reilly, and we both seem to be enjoying the progress of the language. Read more…
What’s New in Java 8: Lambdas
A hands-on introduction to Java 8's most exciting new feature
Java 8 is here, and, with it, come lambdas. Although long overdue, lambdas are a remarkable new feature that could make us rethink our programming styles and strategies. In particular, they offer exciting new possibilities for functional programming.
While lambdas are the most prominent addition to Java 8, there are many other new features, such as functional interfaces, virtual methods, class and method references, new time and date API, JavaScript support, and so on. In this post, I will focus mostly on lambdas and their associated features, as understanding this feature is a must for any Java programmer on-boarding to Java 8.
All of the code examples mentioned in this post can be found in this github repo.
What are lambdas?
Lambdas are succinctly expressed single method classes that represent behavior. They can either be assigned to a variable or passed around to other methods just like we pass data as arguments.
You’d think we’d need a new function type to represent this sort of expression. Instead, Java designers cleverly used existing interfaces with one single abstract method as the lambda’s type.
Before we go into detail, let’s look at a few examples.
Example Lambda Expressions
Here are a few examples of lambda expressions:
// Concatenating strings
(String s1, String s2) -> s1+s2;
// Squaring up two integers
(i1, i2) -> i1*i2;
// Summing up the trades quantity
(Trade t1, Trade t2) -> {
t1.setQuantity(t1.getQuantity() + t2.getQuantity());
return t1;
};
// Expecting no arguments and invoking another method
() -> doSomething();Have a look at them once again until you familiarize yourself with the syntax. It may seem a bit strange at first. We will discuss the syntax in the next section.
You might wonder what the type is for these expressions. The type of any lambda is a functional interface, which we discuss below.
Read more…
Building an Activity Feed System with Storm
One of many wonderfully functional recipes from the Clojure Cookbook
Editor’s Note: The Clojure Cookbook is a recently published book by experienced Clojurists Luke VanderHart and Ryan Neufeld. It seeks to be a practical collection of tasks for intermediate Clojure programmers. In addition to providing their own recipes, Ryan and Luke accepted contributions from a number of people in the community. One of those contributors was Travis Vachon–in this excerpt from the Cookbook, Travis gives you a tried and true recipe for working with Clojure and Storm.
Problem
You want to build an activity stream processing system to filter and aggregate the raw event data generated by the users of your application.
Solution
Streams are a dominant metaphor for presenting information to users of the modern Internet. Used on sites like Facebook and Twitter and mobile apps like Instagram and Tinder, streams are an elegant tool for giving users a window into the deluge of information generated by the applications they use every day.
As a developer of these applications, you want tools to process the firehose of raw event data generated by user actions. They must offer powerful capabilities for filtering and aggregating data and must be arbitrarily scalable to serve ever-growing user bases. Ideally they should provide high-level abstractions that help you organize and grow the complexity of your stream-processing logic to accommodate new features and a complex world.
Clojure offers just such a tool in Storm, a distributed real-time computation system that aims to be for real-time computation what Hadoop is for batch computation. In this section, you’ll build a simple activity stream processing system that can be easily extended to solve real-world problems.
First, create a new Storm project using its Leiningen template:
$ lein new cookbook-storm-project feeds
In the project directory, run the default Storm topology (which the lein template has generated for you):
$ cd feeds
$ lein run -m feeds.topology/run!
Compiling feeds.TopologySubmitter
...
Emitting: spout default [:bizarro]
Processing received message source: spout:4, stream: default, id: {}, [:bizarro]
Emitting: stormy-bolt default ["I'm bizarro Stormy!"]
Processing received message source: stormy-bolt:5,
stream: default, id: {}, [I'm bizarro Stormy!]
Emitting: feeds-bolt default ["feeds produced: I'm bizarro Stormy!"]
This generated example topology just babbles example messages incoherently, which probably isn’t what you want, so begin by modifying the “spout” to produce realistic events.
Formulating Elixir
Simon St. Laurent and Jose Valim explore a new functional programming language
I was delighted to sit down with Jose Valim, the creator of Elixir, earlier this month at Erlang Factory. He and Dave Thomas had just given a brave keynote exploring the barriers that keep people from taking advantage of Erlang’s many superpowers, challenging the audience with reminders that a programming environment must have reach as well as power to change the world.
Elixir itself is a bold effort to bring Erlang’s strengths to a broader group of developers, adding new strengths, notably metaprogramming, along the way.
Watching Elixir grow has been a unique experience for me. I’ve seen other languages (JavaScript and XSLT) emerge, but Elixir combines solid foundations on prior (Erlang) work with a remarkably open conversation about how to structure the language. Jose tries things and asks for feedback, takes suggestions well, and values questions about how best to make the language accessible. Even without a standards organization, the process has remained open, stable, and productive.
Whether you’re interested in Elixir itself or just in the challenges of creating a new combination in a world filled with past experiments, it’s well worth listening to Jose Valim.
- We’ve had functional programming since 1959 – why the burst of interest now? [2:10]
- Moving from Ruby to Erlang “making Rails thread-safe, that was my personal pain-point” [3:13]
- “Every time I got to study more about the VM, the tooling and everything it provides, my mind gets blown.” [6:12]
- Why Elixir started, and how it’s changed as Jose learned more. [10:08]
- Integrating new Erlang features (R17 maps) into Elixir. [15:43]
- When can you use Elixir in production? [18:07]
I’m looking forward to seeing a lot more Elixir, even as I need to catch up on updating Introducing Elixir. I’m not sure it will conquer the world immediately, but it will certainly leave its mark.
Transformative Programming
Flow-based, functional, and more
“Small pieces loosely joined,” David Weinberger’s appealing theory of the Web, has much to say to programmers as well. It always inspires me to reduce the size of individual code components. The hard part, though, is rarely the “small” – it’s the “loose”.
After years of watching and wondering, I’m starting to see a critical mass of developers working within approaches that value loose connections. The similarities may not be obvious (or even necessarily welcome) to practitioners, but they share an approach of applying encapsulation to transformations, rather than data. Of course, as all of these are older technologies, the opportunity has been there for a long time.
The Return of Flow-Based Programming
No Flo and its successful Kickstarter to create a unique visual environment for JavaScript programming reawakened broader interest in flow-based programming. FBP goes back to the 1970s, and breaks development into two categories:
“There’s two roles: There’s the person building componentry, who has to have experience in a particular program area, and there’s the person who puts them together,” explains Morrison. “And it’s two different skills.”
That separation of skills – programmers creating separate black box transformations and less-programmery people defining how to fit the transformations together – created a social problem for the approach. (I still hear similar complaints about the designer/programmer roles for web development.)
The map-like pictures that are drawing people to NoFlo, like this one for NoFlo Jekyll, show how the transformations connect, how the inputs and outputs are linked. I like the pictures, I’m not terribly worried that they will descend into mad spaghetti, and this division of labor makes too much sense to me. At the same time, though, it reminds me of a few other things.
NoFlo diagram for noflo-jekyll
Think Functionally to Simplify Code
Let the environment do more of the work
Functional programming keeps growing. While it has long been a popular topic in academic circles, and many of my CS-educated friends wonder why it took me so long to discover it, the shift in approach that functional programming requires made it a hard sell in the commercial world. As our computers have become more and more powerful and our problems more complex, functional programming approaches and environments seem better able to shoulder those loads.
Neal Ford, Meme Wrangler at ThoughtWorks, has been showing developers how to shift from classic imperative models to cleaner functional approaches. I was lucky to get to talk with him at OSCON, and we’ve also posted his OSCON talk, with many more concrete code examples.
The Politics of Recursion
How close to the metal must programmers be?
Recursion predates computers, but computers’ ability to repeat the same task over and over made recursion a common approach to solving complex problems. Factorials might be a classic example of what recursion can do, but recursion enables many more divide-and-conquer approaches, as well as useful approaches to infinite loops.
You may be nodding your head, thinking “sure, but we don’t need to think about that any more.” Or you may be nodding your head, thinking “if only anyone remembered this stuff any more.”
Until a year or so ago I was in the first camp. I knew the basics of recursion, applying it once in a while to calculations and tree-walking, but it didn’t seem central. Loops and queries of various kinds seemed to make recursion a marginal topic. Usually, seeing recursion was a sign for me to move on, marking a story as “more magic than I needed to know about.”
Erlang forced me to learn recursion—well beyond factorials and trees. Single-assignment variables are a stern master, making me rethink most of the logic I’d used for the last thirty years. There were pleasant surprises, too, like the usefulness of infinite loops in Erlang processes. By the end of writing Introducing Erlang, I had my first genuinely fond feelings for recursion.
Now that I think I have a handle on recursion, I’m paying much more attention to it than I used to, and suspecting I’ve crossed a line. It seems like every language has its own dividing line between amateur and expert, but recursion seems to be a line that crosses programming broadly. Languages meant to be approachable go out of their way to make recursion invisible, while languages meant for experts (or those aspiring to be experts) leave recursion in the open.
Read more…
Practice Makes Programmers
A few iterations make even functional programming digestible
Programming gets easier and easier as you do more of it. Languages and logic become familiar, in ways that extend from looking up less and less all the way to muscle memory in your typing. The first few iterations in a new language are often difficult, as everything seems odd. Shifting not just to new languages but to new approaches makes practice even more important.
One of my worst features has been that I never liked to practice. I understood rehearsing, working together in a group, but practicing? Exercises, especially for the sake of exercise, were never my thing. That character flaw has hobbled my writing. I can come up with examples for books, focusing tightly on an issue I’m explaining. But then, really? I have to ask readers to go solve a particular (already solved) problem?
I’m not alone in this—too many writers have inflicted that attitude on their readers. Exploring sample code is not the same as writing your own code. Miguel de Icaza points out that:
When you finish a chapter in a modern computing book, there are no exercises to try. When you finish it, your choices are to either take a break by checking some blogs or keep marching in a quest to collect more facts on the next chapter.
During this process, while you amass a bunch of information, at some neurological level, you have not really mastered the subject, nor gained the skills that you wanted.
We can fix this.
Read more…