A short post to say that I've just launched a new project called Unpythonic. It's a collection of articles introducing various concepts and techniques for functional programming in Python.
I love the Clojure language, but I don't think there's any use pretending that the combination of expressiveness, power, and repl-driven development can result in some staggeringly dense code. Everyone that writes Clojure is guilty of this at one time or another; you start with the core of your function,
I have a small weakness for silly text games like Candy Box and A Dark Room, and most recently Kittens Game (“a Dark Souls of incremental gaming”). The common feature of these games is that, for the most part, the UI is just numbers on a web page, and you perform certain actions to increase those numbers to purchase upgrades that further your ability to increase the numbers.
One of the great things about this style of game is that the barrier to entry is very low (which is probably why there are approximately a brazilian of these things around), and the games in the genre are differentiated almost solely by the quality of their mechanics (without silly things like “art” to get in the way). You, the reader, might even be interested in dipping your toe in the world of incremental games. If you want to add one to the pile, I recommend you use React to do it.
Circular.io is a clone of Buffer, or at least the Buffer of about 5 years ago. Back then, all buffer did was let you schedule posts to Twitter, to be sent at regular intervals throughout the day. It was on HN about 3 years back, and has been running since then. And
I've used friend to provide auth in my projects a few times, and considered it many more before resorting to my own hand-rolled business. Most of the reason for this is that is just seems so complicated. Workflows? Credentials? I just want to check a password and stash a user object in the session, end of story. After I did some investigating, though, it turns out that you can usefully deploy friend for even very simple workflows, if you understand how it works.
This weekend I made http://worldclassifiedlist.com on a whim. Past experience suggests that I'm not likely to derive any value from the site itself, so before it's completely forgotten, overlooked by an indifferent world and relegated to an unnoticed screenshot on my portfolio page, I thought I might wring a few ideas out of the making-of.
Besides the post scheduling, the main reason people come to http://www.redditlater.com/ is the subreddit analysis feature. This lets folks enter in a subreddit and tells them when the best time to post on a given subreddit is.
Little do they know, it tells me about them, too.
When boot first appeared in my usual rotation of clojure news, I must confess that I didn't really see what the fuss was about. It seemed like someone had taken leiningen and broken out all its parts into functions, which you could then use to get your dependencies, build your project, and so forth. Don't you see! Leiningen is just a build tool, but boot could be anything. It could even be a build tool!
The way we make websites has changed a lot since I started doing it, and it's important to keep up-to-date on new tools and techniques. That said, I've been noticing that I've not spent as much time churning through new frameworks and whatnot as I used to – in fact, I've picked out a few tools that I've been using for years.
Frege is a strongly-typed functional language for the JVM. Its goal is to mirror Haskell as closely as is possible on the platform, and as far as I can tell it does a pretty decent job. It seems performant enough, and more importantly grants access to a Haskell-esque type system. This makes it a pretty good complement to Clojure for those problems where a strong typing system is important.
The downside to Frege is that, even though documentation exists (and is actually quite expansive given the language's limited adoption), it's still hard to find straightforward how-tos by googling. So here's some much-needed frege-related blogspam to fill out those results.
In Clojure (and many other languages), a multimethod is an implementation of multiple dispatch as an alternative to single dispatch.
Traditionally, if you define several methods with the same name on
different classes, the type/class of the first argument (in Python,
many other languages implicit) is used to pick which method to call. This is
called “single dispatch” because the decision of which method to call is left
up to the inferred type of a single argument.
Multimethods take the approach of leaving the dispatch up to the user; you can dispatch on any value at all. You just need to supply a function that returns the value on which you wish to dispatch, and a method for each possible value. For certain cases, this is a lot more flexible than single dispatch.
Functional programming is often described in terms of its contrast with object-oriented programs; that is, you write functions that act on data instead of objects that wrap data and use methods to act on themselves. Functional programming wonks (like me) will tell you that writing code this way is generally better than OO, but I don't want to do that (right now).
However, in this post, I'm not here to argue either side. Today, I'm just going to demonstrate a few equivalent approaches to the same problem: validating data.
One of my favorite genres of article to write are the ones that involve refactoring some code to make it more functional, and (hopefully) improve it on the way. With that in mind, I've decided to embark on a tour of some of the things users of other popular dynamic languages can take away from the ideas behind Clojure, even if they never use it themselves. Today, I'll be taking an old Python library I wrote and refactoring it to fit a few ground rules.
I hate the term “Digital Nomad”. Whenever I see it in the context of an article or blog post, it reeks of pretension and better-than-thou-ness – which, I rush to point out, is not a vibe I ever get from actually talking to fellow travellers in person. Usually, when I meet someone who asks about my lifestyle, I just laugh and say I'm homeless but employed.
Whatever you want to call it, a life of permanent travel seems to have a broad appeal, at least with some segment of society. And, as such, it's something I occasionally get asked questions about. Today, I'll answer questions that I haven't been asked, but feel free to ask more in the comments and I'll answer.
The inspiration for the article I wrote last week entitled Clojure is not for geniuses was inspired by Tommy Hall's talk at Euroclojure 2014, wherein he made an offhand joke about preferring Clojure for its minimal syntax, as he possesses a small brain (both his blog and his head suggest this assertion is false). I had intended to bring this up with the original article, but got sidetracked talking about immutable things and never got back around to it. Here I'd like to address that, along with some discussion that arose in various forums after the first article.
It's a common attitude that functional languages with immutable collection semantics, such as Clojure, are for a) pretentious language geeks, or b) actual genius programmers. I'm in no position to defend against point a) given the body of my writing on this blog, so today I'd like to write an article about point b).
I travel a lot these days. I'd call myself a “digital nomad” as a shorthand, if there was any way to say it without sounding impossibly smug. Let's just say I'm homeless but employed and my wife and I live in AirBnbs.
One of the challenges of moving around so much is dealing with language barriers. For the most part, even in places where English isn't widely understood, it's perfectly possible to get whatever you need with gestures, chief among them pointing and holding up money. It's the little things that are harder when you can't speak the language.
Update: Voting is live! Vote for my app at https://clojurecup.com/#/apps/booker, then check out some more deserving entries at https://clojurecup.com/#/apps and vote for them too!
I've just spent about 30 hours this weekend coding up Booker, my entry to the 2014 Clojure Cup, in which I participated as a one-man team. It was pretty exhausting, and the app doesn't do quite as much as I was hoping it might, but I'm still quite happy with how it all turned out. Here's how my weekend went.
Clojure has an approachability problem. In part, this is due to the relatively unusual syntax, but that can't get all the credit. When it comes to building server-side web applications, a major sticking point is the “lack of frameworks” problem, and more to the point, the common Clojurian's response:
“Clojure users prefer to assemble their own stack from small, composable libraries.”
So you wrote an app. Great! Next step is to put it somewhere where people can use it. This tutorial will walk you through the process of deploying your app.