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.
Problem: You need to extends some Java interface or class to use some Java API, and for some reason Clojure's java interop tools are too unwieldy to do it cleanly.
I saw this post by Grasswire today, and I couldn't resist the urge to throw down a Fizz-Buzz-pocalypse. So, here's my implementation in Clojure, along with a list of ways that Clojure clearly wins. (That last sentence was to be read tongue-in-cheek, Scala is a good language too. Besties!).
I recently had occasion to test out using Parquet with protobufs. I got some simple tests working, and since I had to do a lot of reading to get to this point, I thought I'd do the world a favor and document the process here.
I recently stumbled across a neat library called Flambo. Flambo is a clojure wrapper for Spark, and it does a really great job keeping everything nice and Clojure-y. I wanted to show you so you can enjoy it too!
Hello sir. I'm here to talk to you today about accepting Clojure into your workflow. Do you have a few minutes? I'd like to show you these ten ways that Clojure can help you make better software. Good, here we go!
In May, I left Canada to do some long-term travelling with my wife. I don't mention it here because this isn't tumblr, but it does mean that I have some problems many people don't, such as figuring out when I can return in the Schengen Area. This is a problem that has been solved, but I've yet to see it solved well, so I
It's that time of year again! Today, we'll look at just over a half-year's worth of Github data to draw unsubstantiated conclusions about the relative popularity of programming languages. Ok let's go!
For the past few years, most of my posts have been beginner-intermediate essays on various clojure features and coding techniques. Since a lot of people have told me that they like my blog as a genre piece, I decided to pull some of my favorites into one place, and order them by difficulty, from Clojure beginner on up so that folks don't have to root around.