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
23
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

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?
5 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!).
5 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).
5 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).
5 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
5 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!
6 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!
6 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.
6 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
6 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.
6 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!
6 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.
6 months ago
Liutauras is absolutely spot-on: if you wany to use a language as a way to learn functional programming, you're going to be better off with Clojure.

As you rightly assumed, if you go with Clojure for your startup project, you're going to find yourself learning a lot of things from scratch and rewriting quite a lot of your application. Although I believe you can use Clojure with Spring, I don't know of anyone who does -- Spring is really the opposite of Clojure's mindset in many ways. Clojure is certainly good for microservices, but getting started with web and API development has quite a learning curve because it's very different to what you're used to. Clojure eschews frameworks in favor of composing small, focused libraries -- and there is a lot of choice so even choosing your first stack becomes quite a big exercise that involves learning new thinking and new terminology.

If you were starting from scratch, I'd wholeheartedly recommend Clojure -- and I'd be happy to answer questions and help you get up and running. Since you already have a Java code base with Spring, you'll find it a lot easier to incrementally rewrite it in Kotlin.

I've looked at Kotlin and I don't really see the point of learning it, for myself. Yes, it's a (much) better Java, much more concise, and it has an interesting "solution" to the null pointer problem but, as Liutauras said, it's too similar to Java to learn anything new from it.
6 months ago

Kent O. Johnson wrote:Liutauras, I found two Seven languages books, the 2010 Seven Languages in Seven Weeks by Bruce Tate and the 2014 Seven More Languages in Seven Weeks by Bruce Tate, Fred Daoud, Ian Dees, and Jack Moffit.

I have the Pragmatic Programmer and highly recommend it to any fellow programmer aspiring to become a greater programmer.


Yup, those are the three books I was referring to!
6 months ago