Functional programming encourages the use of recursive functions in order to tackle bigger problems, allowing you to avoid mutable state and express the problem as small problems. One of the most popular example of recursive functions is the factorial function, which can be written in python as follows:
num must be an integer greater than 0
if num == 1:
return num * factorial(num - 1)
That’s the old-school approach to recursive functions and an effective enough function for typical usage. But the biggest problem with typical old-school recursive functions is the stack buildup. If the input is too large, a recursive function will cause a stack overflow. Continue Reading
When I first started learning python and read about how they do class methods, I was a bit thrown off. To be an object-level method (rather than class-level, like Java
static methods), the first parameter needed to be
self. Technically, you could name it whatever you wanted, but the first parameter was supposed to be assumed to be an object of the same type as what you were working on, and it is convention to call it
I was confused. Up until then, I’d marveled at how python kept everything more concise than pretty much every other language that I’d worked with. Now they were putting in something that required extra typing. It took a while to understand why it was even necessary, especially since it was a little while yet before they even showed class-level methods. Then I realized that they would need something to distinguish between the two, and pretty much anything you did to accomplish that goal would require extra typing. So I let it go. Continue Reading
I’ve done a few posts on the Hamcrest library, and I really do enjoy using it, but there are a few changes I would love to make to it. I understand most of the design decisions that they made, but I think some of them weren’t really worth it.
Most of the changes I would make to the library help to lighten the load of Hamcrest, since I feel like there are a few things that weigh it down unnecessarily. This is why I call my changes Litecrest. It won’t be an actual library; this is all just thinking aloud. I also hope that you’ll learn a little about designing libraries from this. Continue Reading
In Effective Java by Joshua Bloch, it is explained that if you create a class, you should “design and document for inheritance or else prohibit it” (item 17). It gives some very good advice about making classes to be extended, but I always felt it lacking in patterns for doing so. I highly recommend Effective Java to any Java programmer, as it has good tips for just about every level of Java programmer (other than maybe a super expert).
I would dig into the tips that he provides, but that would be invading on his great work, and it would probably make my article too long for my liking. Continue Reading