Some of you who follow me may have noticed a tendency of mine to “hack” programming languages more than really use them (other than reflection via annotations in languages such as Java; I hate that stuff), and today is no different. Today, we look as using what would be normal higher-order functions as Python decorators to create new functions that encapsulate the idea of both the higher-order function as well as the passed-in function under one name. Continue Reading
It’s been a crazy year for me. Loads of excitement and disappointment all around. First off, in July 2016, I lost my job at my first real programming gig due to cutbacks. Luckily, I had saved up about 3 months worth of minimal living expenses, and besides that, I had paid off my credit cards enough to use them for extra cushion. I got a temporary job with Best Buy for about a month starting in mid-late December 2016 until mid January 2017 helping out with delivery and installs of home theater equipment. This was nice, as it got me up to date on what’s available in the market, but it really did not last long.
It took me another several months before my next job, working for a lady from my church who, in it’s most basic sense, owned a franchise of a moving company. That was lots of good, hard work with a relatively steady paycheck. Around the same time, I made two big decisions.
My first decision was to try to write another book. I had had an idea for quite some time, and I really wanted to write it down and make a little money off of it. More on this later The other decision was to start looking for work that wasn’t local. I come from central Wisconsin, and the three main cities around there are Wausau, Stevens Point, and Marshfield, and from what I could tell, there just wasn’t enough programming work for all the programmers in the area. So, I decided I could deal with looking in Madison, too, since I have friends from college that moved to the Madison area. It wouldn’t be going somewhere that didn’t have anybody I knew. Well, in September, I started a job at Epic. The place is awesome, and their idea of “competitive pay” is “compete with California, despite it being way cheaper to live in Wisconsin”. I highly recommend the place. And getting the job and moving down here has been the highlight of this year.
After moving in, I decided to give myself a little while to adjust before getting back into writing for the blog and getting back to work on my book. By the way, I had signed the contract to do the book already, so it would be bad to back out. Well, as you can see by the lack of posts, I haven’t really made that come back. I talked to my publisher about backing out, and they want the book to be finished so they suggested that I try to find someone else to finish it for/with me. So, I’m asking all of my readers, would any of you be willing to help me finish this book? You probably want to know the subject, don’t you? It’s about Design Patterns in OO-Functional Hybrid languages. I have the outline written, as well as the first three proper chapters (plus a preface and intro). Code examples are done in Kotlin. If there’s anyone who’s willing to help, email me at sad2project at gmail dot com. Thank you, and have a wonderful New Year!
Oh, there also won’t be any book reviews this year, other than to recommend every fiction book written by Brandon Sanderson. When it comes to programming books, I’ve probably started 5 or 6 this year without getting more than a third of the way through. Right now, I’m intent upon finishing Implementing Domain-Driven Design as well as Domain Modeling Mad Functional. Also, there’s a new, 3rd edition of Effective Java I’d like to read through.
Man, I’ve had this idea in my head for more than a month now (luckily I wrote it down, too), waiting until the day I wrote this post. I didn’t write it because I was busy with the move and new job, but now things are finally settling down!
Here’s the thing: When you really dig into it, proper object-oriented programming and functional programming are pretty similar. The biggest difference is that object-oriented programming likes to use encapsulation to hide the real data behind facades of objects – requiring you to define methods attached to the type that know about private details – while functional programming is quite up front about it all – making it so that you generally get switch-like structures (but WAY better) that allow you write one function to handle all of the different types.
A side-effect of this has been two different ways to call functions: as methods and as stand-alone functions.
object.methodCall() // Vs functionCall(object)
Actually, the second kind could be procedural or functional in style. It’s impossible to tell without more arguments.
Due to functional programming loving to compose functions together, it likes to have the “subject” of the function as the last argument so that the function could be curried or partially applied to a base function that could be composed with other functions that work on the same type or output type. It’s really cool and really handy. But with procedural style, the tendency is to put the “subject” as the first argument in order to show its prominence.
object.methodCall(argument) // OO style functionCall(object, argument) // procedural style functionCall(argument, object) // functional style
Interestingly, Python methods are actually explicitly defined in the procedural function style, but are called in the OO style (usually). This sparked an idea within me, which, with knowing how so many other languages do functions, guided me to today’s idea. What if you could define a function in a single way, but use it in any of the three ways listed above? Continue Reading
Okay, so you may know that I recently got a new job, and because of it, I moved to a new area. Well, I’m fairly settled in now and will start to post again. It still won’t be completely regular. First, I’m still working on my next book. Second, I’m still trying to figure out what activities I’m going to be regularly scheduling into my life at the end of the day. This blog will be a part of that for sure (I’ve got a few ideas I really want to get out!), but I do still need to focus on my book.
This Saturday, I’ve got a new post lined up for you, so get hyped and check it out!
Yeah, I did it again; I went several weeks (more than a month!) without posting anything. This time, it’s not laziness, I promise 🙂
I started a new book! This book will be on how design patterns evolve when functional programming (specifically first class functions and lambdas) mix in with an object-oriented language. I’ve already got several chapters written!
I also got a new job! I’ve been pretty much unemployed (and underemployed) since July of last year (so, for over a year now), but I finally found a job! It’s an exciting opportunity, but I have to move 2.5 hours away, so a lot of my life will also be devoted to getting ready for that.
I have a few blog posts planned out for you guys, and maybe I’ll get to them soon, but don’t expect anything before I’m done settling in, early in September.
Lastly, I’d like to get my spare book copies out, so I’ll just go with the simplest way to get rid of them: ask for them in the comments! I have 8 left. Just comment below, include your email address, and I’ll contact you privately to get your shipping details. This is first-come-first-serve.
Hello, dear readers, and welcome to my thoughts on the MVP (Model-View-Presenter) pattern, which I finally got around to learning. I had tried before, but everybody always explained it so abstractly that, even when compared to MVVM abstractly, I couldn’t tell what it was. But I recently got to see the pattern being implemented in some live-coding episodes I don’t really have a whole lot to share; I’m focusing on one mini anti-pattern within the typical implementation that I’d like to provide alternative ideas for.
General Thoughts on MVP
First, I will give you my overall thoughts on MVP. My first thought about it is, “Is this really any different than MVC?” And truly, MVP is pretty much what I had always thought of MVC to be. The problem wasn’t MVC, in my opinion, but what so many people had come to think MVC was. Having heard what Uncle Bob has said about MVC, it’s clear that there has been severe “evolution” to the community’s understanding of MVC, but the MVC I was taught in college is almost exactly the same thing as MVP, with all the differences being negligible compared to the differences between my understanding of MVC and so many others’ understanding.
Beyond all that, though, I do like MVP, overall. When done correctly, it follows the Clean Architecture. Unfortunately, many people’s understanding of a domain model (or “entity” in Clean Architecture) goes against what I follow, which is akin to Domain Driven Design’s understanding, which I believe Uncle Bob (the creator of Clean Architecture) leans toward as well. With that said, I’m fine with letting others do that part however they like, since there are so many conflicting ideas about it. Really, the pattern is fine, except for the one anti-pattern I’m focusing on today.
Cyclic References in MVP
From what I’ve seen, everyone implements MVP with a cyclic reference. And I can understand why, it’s the simplest and most obvious way to implement the pattern. Almost no matter what system you develop in, the View is also going to be the system that receives events, and for the events (or commands derived from the events) to get to the Presenter, the View must have a reference to the Presenter. This is all as it should be. The problem comes from the fact that the Presenter is then expected to give commands back to the View after doing its business with the Model. Typically, this is done by a simple method call on the View object that is stored on the Presenter. Boom! Cyclic reference. The View holds a reference to the Presenter, which holds a reference to the View.
How Do We Get Around This?
The most obvious way to get around a cyclic reference is to instead pass the View in as an argument to the Presenter’s methods. This is simple, straightforward, and just a tad tedious (that’s a lot of typing “this”), but if you care about avoiding cyclic references, this is certainly a way to go.
Another way to go is to return some sort of command object. This is sort of old-fashioned OO and would likely require a lot of type checking and casting to determine which kind of command is returned and grabbing the data needed to do it. I would not recommend this.
A “solution” that I’ve seen someone use is to make the reference to the View a weak reference (one that isn’t counted by the garbage collector). While this gets around the biggest reason why cyclic references are bad, it doesn’t actually get rid of the cycle. If you don’t really care about cyclic references, I would still recommend doing this at least, and if you’re doing MVP in Android, I recommend checking out the android-arch-sample repository on GitHub, as it shows how someone can use a weak reference as well as some other scaffolding to make it so the Presenter replaces its View object when there’s a configuration change (such as rotating the screen), since configuration changes cause the Activity (which doubles as the View) to be destroyed and rebuilt. It also has the single greatest use of a stateful Singleton I’ve ever seen. There’s a way around it needing to be a Singleton, I’m sure, but I don’t actually want to get around it, it’s so clever.
So, what do I think is the best solution to avoiding cyclic references? Lambdas. It’s similar to the command solution, but instead of returning a command, you returns an anonymous function via lambda or method reference which the View will then call, passing itself in as an argument. It’s more functional, and not just because it uses higher-order functions. Rather, it’s more functional because the Presenter methods now have something to return. They can be pure (though they’re not likely to be because the model will be accessing some sort of mutable data store, most likely), since they’re not calling the “void” methods on View. It leaves the impure functions to be called at the outermost layer, the View, which is ideal.
What Do I Really Think?
Now, having said that I think that lambdas are the best solution, I’m not actually convinced of that. Theoretically, it’s the best, since the Presenter never has any reference to the View, but is it actually?
- It relies on the View to call the returned function, which it can totally ignore doing, and easily forget to do.
- Even using lambdas isn’t likely to keep the Presenter pure because it accesses the Model, which is likely to use a mutable data store.
- All you’re really doing is moving the same calls you were going to make anyway, but not they’re in a lambda or method reference.
My actual suggestion, until I can come up with a better idea or better reason for something else, is to pass the View in as an argument. That is, unless you’re using Android (it’s the only system I know of that destroys and completely rebuilds its Activities – or equivalent), where I recommend following the pattern in the android-arch-sample repository.
Until next time, thank you for reading.