Win a copy of Machine Learning Systems: Designs that scale this week in the Scala forum
or Xamarin in Action: Creating native cross-platform mobile apps in the Android forum!

Sean Corfield

Rancher
+ Follow
since Feb 09, 2011
Sean likes ...
Clojure Linux Mac OS X Monad
Veteran software architect, working mostly in the web space on the JVM. Developing with Clojure since 2010.
Bay Area, CA
Cows and Likes
Cows
Total received
18
In last 30 days
0
Total given
0
Likes
Total received
72
Received in last 30 days
0
Total given
24
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Sean Corfield

It's been a bit quiet in here lately so I thought I would drop some news about an easier process to get started with Clojure!

For a while now, the Clojure/core team at Cognitect have been working on improving the "entry" process for using Clojure. In the past, you either downloaded the JAR and ran that directly at the terminal -- which was a very bare bones experience -- or you installed one of the Clojure build tools (Leiningen or Boot) in order to get a REPL up and running, or run your program or your tests. Recently, a new command-line tool has been made available and the Getting Started section on Clojure's web site has been updated.

If you're on a Mac, it's as simple as brew install clojure which will install both a basic clojure command and a more friendly clj command (that uses rlwrap around clojure to provide history and editing at the terminal).

If you're on Linux, you can use curl to download an installation script but packaged versions are coming (for apt-get etc).

If you're on Windows, a PowerShell installer is in the works (but, hey, if you're on Windows 10, you can install Ubuntu etc via Windows Subsystem for Linux and use the Linux installer script -- and that works just fine).

The new command line tool starts a REPL by default but can also fetch library dependencies and add them to the classpath. It can also run your code, providing options to specify the "main" function and arguments to that, as well as JVM options.

Dependencies are specified in a file called deps.edn (EDN is an enhanced form of JSON). You can specify libraries on Maven Central or Clojars (the Clojure community's Maven-compatible repository -- for arbitrary Clojure projects). You can also specify dependencies as Git coordinates (a URL to the source code repository and the SHA to identify the commit to use) or on the local file system (so you can manage multiple projects locally that depend on each other).

The command line tools introduce the concept of aliases (somewhat borrowed from Leiningen) that let you layer and combine dependencies and options in ways that are very powerful. Here's my .clojure/deps.edn file with several useful aliases for running tests, benchmarking, measuring memory usage, starting various types of REPL, choosing which version of Clojure to use etc.
1 month ago
I'm very interested in Kotlin (and several other JVM languages) but have zero interest in the Android (or iOS) platform so I would not be in favor of merging the forums.
1 month ago
The Kotlin in Action book promo still says "waiting on winners info" and it's been nearly a month. I thought winners had to get their info in within eight days, and would get confirmation within three days?
8 months ago
Broadly speaking, there are two approaches to TDD (Test-Driven Development), sometimes referred as the Chicago school and the London school, that differ strongly in their use of mocks. The Chicago school a.k.a. "Classic TDD" builds up from the bottom, working from the inside to the outside, and doesn't need mocks (because you've already built the real objects). The London school a.k.a. "Mockist TDD" builds down from the top, working from the outside to the inside, and relies heavily on mocks for objects-yet-to-created. This blog post from Georgina McFadyen of 8th Light is a good overview (a lot more material can be found online).

BDD (Behavior-Driven Development) expands on the London school of TDD in some ways, focusing on expected behavior at a higher level, and using different terminology in order to move your thinking away from "tests" to "specifications". Some people feel BDD is harder for beginners to learn than TDD (but I don't agree), and because it's an outside-in approach, some texts will lean heavily on mocking for BDD. I prefer to follow the BDD approach overall but rely very little on mocking (perhaps I feel less need for mocks since I work primarily in a functional language -- Clojure -- rather than an object-oriented language?). Since I believe you can work effectively in a top-down, outside-in manner without mocking, I tend to encourage BDD/TDD beginners to avoid mocks if possible -- partly because of the issues that Pete is running into here (and if you're doing TDD, actually writing your tests first, and you use mocking techniques, then you will tend not to write final or anonymous classes because mocking works against that... which is another reason to avoid mocking!).
8 months ago

Pete Letkeman wrote:If you are using IntelliJ based IDE then I can tell you that at least in Android Studio with a few clicks you can turn your Java code into Kotlin.


I don't like IDEs in general (and I dislike IntelliJ particularly), and I have no Java code to convert. Funnily enough tho', I just installed the latest version of IntelliJ yesterday to work on an issue with Cursive and Expectations (a BDD-style testing library I maintain in Clojure). Despite that, and my current ongoing process of learning Kotlin, it hadn't even occurred to me to try out IntelliJ's Kotlin support!

I use Atom for all my editing with ProtoREPL for Clojure. I should check to see what sort of Kotlin support it has (I've been writing Kotlin so far with whatever defaults Atom uses).
8 months ago
I'm a Clojure developer and I'm very happy with Clojure (I've been using it in production since 2011 now). One of the Clojure IDEs is Cursive, which is a plugin built on IntelliJ's IDE, and the author of Cursive, Colin Fleming, has started using Kotlin to minimize the Null Pointer Exceptions he gets when trying to work with the IntelliJ code from Clojure (idiomatic Clojure embraces null and uses it in very specific ways -- Java API code tends to throw nulls at you all the time and wrapping that in Clojure leads to non-idiomatic Clojure code that is overly focused on null handling!). Colin's enthusiasm for Kotlin has fascinated me for a while so, along with the Pragmatic Programmer's advice to learn a new language every year, this seems like a great opportunity to dig deeper into Kotlin.

I very much doubt I'd want to switch from Clojure to Kotlin but it never hurts to know another language -- and I've worked with Java, Groovy, and Scala on the JVM prior to picking up Clojure.

So far I'm still working through the Kotlin website, learning the language, but I'm quite impressed with the simplicity that Kotlin has achieved compared to Java, and I love the way it has extended a number of (ugly) Java standard library classes with convenience methods that make using those classes so much more natural and fluid (the I/O stuff in particular).
8 months ago
Just in case anyone decides to play around with Clojure and then also decides to play around with Kotlin, I created a Kotlin compilation task for Boot (one of Clojure's build tools): https://github.com/seancorfield/boot-kotlinc
8 months ago
Super excited to have won a copy of this book! I'm a firm believer in The Pragmatic Programmer's advice to learn a new language every year and Kotlin has been on my list for a while so this will encourage me to put it at the top of the list, roll up my sleeves, and actually learn it!
8 months ago
Much appreciated Dmitry. There have been some efforts to make Clojure for Android viable but application startup time is an issue (using ClojureScript and going the React Native approach seems more suited).

It sounds, from your answer, that Kotlin's two big "selling points" -- compared to the languages I already know -- are the null-aware type system and the suitability for Android development.

We have quite a few languages now that are much more concise than Java -- it's a good time to be on the JVM!
9 months ago
I've worked with a number of JVM languages in production (Java, Groovy, Scala, and for the last seven years Clojure) but I haven't tried Kotlin yet.

Nearly all of the talk I've seen about Kotlin focuses on how it helps you avoid the dreaded NPE by introducing the idea of nullable and non-nullable versions of types and requiring explicit handling of null when "converting" between the two.

Aside from that feature, could the authors provide a short "elevator pitch" of why I should consider Kotlin, given the languages I already use?

Thank you.
9 months ago
It’s instructive to compare those Java versions with three (very short, simple) Clojure versions in this article: http://blog.klipse.tech/clojurescript/2016/04/20/fibonacci.html
9 months ago
In Functional Programming, you wouldn’t be updating in place — your hash map would be immutable — so there wouldn’t be any concurrency issues to avoid.
9 months ago
In addition to the Clojure forum here on the ranch, there's a very active Slack community for Clojure (over 11,000 members). You can sign up here and then login here or via the desktop app if you already have that installed (I'm in about a dozen Slack, and an admin on Clojurians). The #beginners channel there is very friendly and welcoming!
9 months ago
We used Apache OLTU (Jose JWT, specifically), for the tokens, because we built our own OAuth2 provider. We didn't use any wrapper libraries, just raw Java interop, but looking at buddy-auth is probably worthwhile, if it automates some of what you want (I haven't used it).

Ring is the basic library on which almost everything else is built in Clojure's web world. I don't know which app server you prefer but most folks either use Ring's embedded Jetty adapter or the http-kit library (Jetty plays nicer with New Relic but we use http-kit in production and have workarounds for New Relic).

For routing, you'll either want Compojure or Bidi (we use both, but mostly Compojure), or perhaps Compojure-API if you want fancier REST support.

For any SQL database, org.clojure/java.jdbc is the cornerstone library -- part of the set of Contrib libraries (the closest thing to a "standard library" that Clojure has) -- and I happen to be the maintainer, so I can definitely answer questions there (although we're a heavy MySQL shop and I barely use PostgreSQL).

I remember Tim's comment -- that was the "Programming with Hand Tools" talk, right? They say that you only understand why you "need" Spring when you have suffered the pain of the problems it exists to solve. Those problems pretty much don't exist in Clojure. That said, I strongly recommend looking at Stuart Sierra's Component library which is the closest thing to Spring you'll find in Clojure but exists to solve a very specific problem regarding initialization (and finalization) of global resources, such as database connection pools, etc. We use Component very heavily at work.
9 months ago