functional programming

The book Design Patterns: Elements of Reusable Object-Oriented Software was one of the texts that changed how we think about software design. This book came out in 1994 through the efforts of Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, later remembered as Gang Of Four (GoF) GoF Design Patterns: The Origin, the Impact The book’s importance lies in its effort to review the software production done up at that moment, giving more structure to the concept of Software Design

Java introduced the concept of checked exceptions. The idea of forcing developers to manage exceptions was revolutionary compared to the earlier approaches. Nowadays, Java remains the only widespread language to offer checked exceptions. For example, every exception in Kotlin is unchecked. Even in Java, new features are at odds with checked exceptions: the signature of Java’s built-in functional interfaces doesn’t use exceptions. It leads to cumbersome code when one integrates leg

Java has long been infamous for its NullPointerException. The reason for the NPE is calling a method or accessing an attribute of an object that has not been initialized. var value = foo.getBar().getBaz().toLowerCase(); Running this snippet may result in something like the following: Exception in thread 'main' java.lang.NullPointerException at ch.frankel.blog.NpeSample.main(NpeSample.java:10) At this point, you have no clue which part is null in the call chain: foo, or the value ret

I’ve tried Go in the past, and the least I could say is that I was not enthusiastic about it. Chief among my griefs was how the language handled errors, or more precisely, what mechanism it provided developers with to manage them. In this post, I’d like to describe how a couple of popular languages cope with errors. A time before our time I could probably go back a long time, but I needed to choose a baseline at some point. In this post, the baseline is C. If you search for 'err

Some, if not most, of our judgments regarding technology stacks come either from third-party opinions or previous experiences. Yet, we seem to be adamant about them. For a long time (and sometimes even now), I’ve seen posts that detailed how Spring is bad because it uses XML for its configuration. Unfortunately, they blissfully ignore the fact that annotation-based configuration has been available for ages. Probably because of the same reason I recently read that Spring is bad…​

This week, I learned about a nifty 'new' feature of Optional that I want to share in this post. It’s available since Java 9, so its novelty is relative. Let’s start with the following sequence to compute the total price of an order: public BigDecimal getOrderPrice(Long orderId) { List<OrderLine> lines = orderRepository.findByOrderId(orderId); BigDecimal price = BigDecimal.ZERO; (1) for (OrderLine line : lines) { price = price.add(line.getPrice());

Consider 2 types X and Y, and a function f defined as: class X, class Y and val f = { _:X → Y() }. In Kotlin, it’s possible to call the function f with a parameter of type X using invoke(): fun f(x: X) = Y() val y: Y = f.invoke(X()). The following calls the function f with a parameter of type X using invoke().

This is the 4th post in the From Imperative to Functional Programming focus series. This week, I’ll first implement the Dijkstra algorithm, then migrate the code to a more functional-friendly design. Dijkstra’s algorithm allows to find the shortest path in any graph, weighted or not, directed or not. The only requirement is that weights must be positive.

With Java 8 streams, it seems Functional Programming has won. Long live statelessness and recursion! Reality is a bit more nuanced: as always in software programming, it depends. I believe that the more tools in your toolbelt, the better it is. When all you have is a hammer, everything looks like a nail. In Functional Programming, every function needs to be pure: output only depends on input, and there are no side-effects. For this reason, Java methods to create infinite streams are not u

This is the 3rd post in the From Imperative to Functional Programming focus series. There’s a whole category of problems related to grouping e.g.: Given a collection of person, return a list of pairs with the first value the age, and the second one the collection of persons of that age. Given a collection of orders, return a list of pairs with some price range e.g. $0-$100, $101-$200, etc. as the first value, and the number of such orders as the second one. Given a collection of words, retu

This is the 2nd post in the From Imperative to Functional Programming focus series. Last week, we ported the migration of a Scala application from imperative to functional in Kotlin with the help of the Arrow library. This was pretty easy: the example was laid out for us. This week, I’d like to go for more fundamental stuff.

This is the 1st post in the From Imperative to Functional Programming focus series. Some time ago, I watched the talk FP to the max. While the end of the talk is quite Scala-ish, the beginning can be of interest regardless of the language. In the talk, the speaker tries to migrate a standard imperative-like application using a functional approach. I wanted to check if it was possible to do the same in Kotlin.

Recently, I had some some fun writing functional Kotlin to solve the FizzBuzz test. I asked for some feedback, and one of the answer I received was in Clojure: In Clojure there's the classic way, with condp and mod. There's also another way using cycle that I saw some years ago. The range and the 2 cycles will generate the fizz & buzz, the rest just decides what to print.Will be easier for you with syntax highlighting -> screenshots pic.twitter.com/wOPJD0BpGM— Alexandre Gris