This past week I wrote about JavaFX and Scene Builder implementation in Clojure. In the meantime I’ve found a more effective interop between Scene Builder and Clojure utilizing the plugin clojurefx. Utilizing the previous week’s problem that we had (i.e. have a button and label. When the button is pressed the text of the label switches between “Moo” and “Cow”) we can use the clojurefx library for easier implementation of action listeners and fxml. The steps are as follows:
These past several days I looked into the viability of JavaFX and Scene Builder in Clojure. What this meant was going through several poorly google-translated articles of Japanese and Chinese blogs and trying out random methods. That being said, today you’ll get the gist of how to set up JavaFX in Clojure, how to set up Scene Builder (specifically using generated .fxml files in Clojure), and how to handle actions in Clojure. Now a quick preamble: there are two ways to handle actions that I found, both work, one is more elegant (in my opinion), but appears to be less powerful. This simply could be because I have yet to figure out a better way to implement it using Clojure namespaces. This tutorial will be straight to the point, for additional details I will link to several blogs. Anyhoo, on with the JavaFX setup!
So this past week I spent a couple of days making an API in Clojure to scrape data from the ATP World Tour website. Here are a github link and a clojars link to the project. Anyways, instead of aimlessly discussing the API I’ll talk about some of the things I learned about Clojure while making the API.
- How map actually works. I never really understood how map worked other than I just thought it was a cool way to reduce nested for loops. The way I think of it now is kind of like this. Let’s say you have a list of items you want to pass through a function f(x). Map iterates through that list and passes each item through and let’s you use it in f(x).
- Testing is amazing. So initially I went by the program testing features using the println command and a (defn -main [& args] ..). It’s so much more effective to have testing because you always end up changing features around, trying to optimize things, etc. And every once in a while that leads to you breaking your program (or features in it). While you may get explicit errors when the program itself crashes, it won’t tell you when features that you knew previously to have run correctly no longer run correctly. Hence why testing. Honestly, before Clojure I was never big on testing or test driven development. Even a stint of using Ruby on Rails hadn’t changed my opinion on testing until now.
- Midje – it makes testing in Clojure a lot easier. Check it out. Also lein midje :autotest is amazing.
- Java interloping can be useful! Certain common Java functions are already integrated into Clojure (e.g. subs = substring), but those that are not can still be very useful. I found myself using the .indexOf function as a base for a large chunk of my testing (as it helped determined if a substring was a part of a string). In hindsight, this can be cut out by simply using regex checks, but at the moment it was a useful learning tool that helped demonstrate Java’s utility.
- Be careful about how you name your files/namespaces. Seriously. Typos were an incredible headache when trying to get testing up and running and the errors were utterly confusing.
Those were some of my adventures in Clojure this past week. Hope you got something out of it. I plan to write a more comprehensive guide at some point down the line. Cheers!
Over this past week I decided to take up Clojure (probably as a result of so much frustration with VBA making me seek out a sensible programming language to regain sanity…). So in this post I’ll discuss three things: why Clojure? And some of the pros of the language and some of the pitfalls (from a learners perspective). Let’s begin!
Clojure is a Lisp-variant that runs on the JVM. I say variant because although it has many similarities to Lisps, there are instances where Clojure is different (e.g. cosmetically removing redundant brackets). Furthermore, Clojure embraces the JVM – there is full integration with Java. If you have a class in Java to be ran, you can do so through Clojure in a simple, succinct, and easy to read way. As a Java programmer this was a huge plus as it gave me a sort of safety net in case I hated the rest of the language (which proved to not be the case). So why Clojure? Well I had three specific reasons for choosing it, which I’ll exclude from the pros and cons list since we’ll leave that for what I learned over the course of learning (yes, slightly redundant).
- Expressiveness – naive me read something about language expressiveness. What if I could write my Java programs in a tenth of the code! Think of all the productivity. (This turns out to be fairly accurate…)
- Readability – I find Lisps and Clojure in particular to be far more readable and aesthetically pleasing to look at. Why does this matter? Well going over thousands of lines of confusing Java and Python code can get confusing at times. This seems to be a more productive and sane alternative
- Functional programming – I’ve heard a lot about it and a lot of buzz regarding Common Lisp. Clojure seemed like the most friendly way to get into functional programming since, given the JVM environment and Java integration, there was a fallback to OOP.
Those were the three main reasons I ended up studying Clojure this past week. I would say it has paid off – the language is amazing in my opinion. If I had known about it two years ago I would have taken it up instead of Python. Anyways I spent the week learning it by developing a shoddy API (probably won’t maintain it haha, it was a learning experience), doing some 4clojure problems, messing around on tryclj, and reading a few books (these are non-affiliate links). Doing so I came across a few pros and cons of actually learning Clojure. Let’s start with the cons first though.