Kotlin doesn’t have true pattern matching, and that’s fine. In order to make matchable classes in Scala, there is an awful lot of overhead required to make it work, and I highly respect Kotlin’s goal of not adding much overhead anywhere. But that doesn’t mean we can’t try to make our own way to get something closer to pattern matching. Continue Reading
Today, we’ll be talking about something controversial: static methods. I have yet to read anything that says static methods are good and useful, other than Effective Java recommending them in the use of static factory methods. There are some really interesting (and somewhat dumb) arguments out there against them that rarely, if ever, even get explained. Notably, I’m providing a rebuttal to the article, Utility Classes Have Nothing to do With Functional Programming.
Today, we’re going to look at the good and bad of static methods; what they’re good for and what they’re not.
When I first laid eyes on Java 8’s Stream API and found out that it worked lazily (then found out what that meant), I was blown away and utterly baffled. It didn’t seem possible at all. Eventually, I was able to wrap my head around it, realizing it was done with my favorite design pattern: the Decorator Pattern!
In this post, I’m going to go through and write up a simplified implementation, only going through the
reduce() methods. We’ll also be ignoring the ability to parallelize the calls. Lastly, for the sake of readability, I’ll be ignoring
extends in the generics. Continue Reading
First, I’d like to thank everyone who took my survey from last week. It wasn’t important (and, according to some of you, it was ‘dumb’), but it was something I was curious about I’m glad I got all of your feedback. The results are in: Continue Reading
I wrote a poll to see what people what people’s preference was concerning functional composition.
If you have seen my most recent post about explicit currying in python, you may remember that I hadn’t bothered to wrap my head around trying to use keyword or default arguments. Also, as the title of my article stated, you had to very explicitly design the function to be curried, instead of having something reusable.
Well, some people cleverer than me took a good whack at it and here’s what they’ve got:
Currying in Python – from the Computer Science blog. He goes over every step of the way towards making a function that could be used as a decorator (though he doesn’t seem to know what a decorator is; he’s new to python) to transform normal functions into curried functions. It’s not especially pythonically written (again, he’s new to the language), and it’s big, but it works.
KISS Python Curry – a github python module by
Last week, I talked about currying a little bit, and I’ve been thinking about how one could do in languages that don’t have it built in. It can be done in Java, but the type of even a two-parameter function would be something like
Function<Integer, Function<Integer, Integer>>, which is bad enough. Imagine 3- or 4-parameter functions.
There’s also the fact that calling curried functions doesn’t look good. Calling the two-parameter function with both parameters would look something like
func.apply(1).apply(2). This isn’t what we want. At worst, we want to be stuck with
func(1)(2), but that’s not possible in Java. At best, we want to be able to choose
func(1)(2) (calling it with the first argument at one point in time and using the second one later) OR
func(1, 2), depending on our current need. It’s possible to do so in python, so I’m using that. Continue Reading