Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!

Sean Corfield

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

Recent posts by Sean Corfield

Tim Holloway wrote:If you're like Amazon and don't mind random massive hour-long outages. ... Last bank I worked at...

I can imagine a bank being a bit squeamish about CD but NuBank has shown that can work, even for a bank: (and I'm sure there are other banks that have CD these days).

Bugs make it to production whether you're doing CD or not, but if you have confidence in your code review process and your automated testing process, and have the ability to get even a single bug fix through that pipeline to production quickly, then CD is nothing to be afraid of -- but it is all about having good hygiene in your software development/deployment which, unfortunately, a lot of companies lack.

My original comment was meant to be more of a "Wouldn't it be great if you could be confident that every version of your main branch was well-tested enough to be deployed?" -- which I think is something every software development team should aspire to.

And to tie it into the original topic of this thread, a good argument (in my mind) for beginners to start with basic tooling and the command line is that they get a much better handle on automation upfront, and I think that knowing how to automate tasks around build/test/deploy is a really important skill for a software developer -- an IDE hides so much of that. I've known developers raised on visual tools and big, fancy IDEs and they often have no idea how to even compile their code from the command line, let alone automate anything.
3 weeks ago

Tim Holloway wrote:That would be a change from the current setup where the git server gets polled every 5 minutes and does a generic build when any change gets committed without regard to deployability.

But wouldn't it be even better to be in a situation where every change committed (to the main branch) could go straight to production?

Where I work, all changes go through PRs (pull requests) and are both reviewed by people and are automatically tested (by BitBucket Pipelines) and every approved, merged change to the main branch is automatically deployed to our staging environment. And then management (QA & Product Owners) can decide to push any artifact that made it to staging to one or more production servers via a web UI and deployment is fully automated. Our goal is to remove that gating factor and have every commit to the main branch go to production automatically and we're pretty close to the confidence level needed for that for most of our apps built from our monorepo.

Our full CI build cycle to staging takes about 20-30 minutes right now (we're working to tighten that up) and we can currently go to a full production deployment across the cluster in about 15-20 minutes from staging so we are currently capable of deploying changes over half a dozen times a day for a standard work day, which is a massive improvement from where we were a few years ago.
3 weeks ago
Woo-hoo! Thank you, Alexander. Looking forward to reading your ebook.
3 months ago

Sebastian Makowiecki wrote:Thank you. Indeed an interesting thought to learn a bit of Haskell - never crossed my mind actually.

I actually hoped at least some of the LISP dialects would come up, happy to see Clojure on the list. Conceptually LISP is such an appealing yet so intimidating concept I am always too afraid to go at it as a result. I goota though since it will make me a better person no doubt.

Clojure is pretty approachable and the community is extremely welcoming to beginners. I've been doing Clojure in production for a decade now and I've never been happier as a programmer!

If you're interested in learning Clojure, the Clojurians Slack is an essential resource (with thousands of folks to help you out). will let you sign yourself up and is where the action is.

There's also a Clojure forum here on the Ranch -- -- but it hasn't had much activity in the last couple of years (although I'm always happy to help people in that forum).
3 months ago
In Haskell, you really can't avoid monads -- any code with side effects is monadic in Haskell, for example, and monads are a commonly-used abstraction for a lot of other things too.

That said, monads aren't really as "scary" as you might think -- I pretty much guarantee you're already using monadic forms in your day-to-day programming without even knowing it. Using Optional<> in Java? Monads. Using a for-comprehension (present in several languages)? Monads. In Haskell, they are just more obvious and more formalized.
3 months ago
Having built large web apps in multiple languages (and multiple paradigms) over two and half decades now, I think I'd place web apps in general squarely in the FP camp.

Handling a web request is a function from request to response, possibly producing side effects alongside that response, and as you noted concurrency is so much simpler in FP languages!

I think we can make a lot of inroads in UI work with an FRP style approach (Functional Reactive): React/Redux/etc has shown us what is possible, with some great FP wrappers around those (see Reagent/Reframe in ClojureScript, for example).

As background, I did OOP from early '92 (and was on the ANSI C++ Standards Committee for eight years before transitioning to Java, then Groovy, then Scala) although I'd studied FP at university in the '80s and via Scala I came back to FP and have been doing Clojure full-time since 2011 now.
3 months ago
Hi Alexander!

In the description of the book, it says "In it, you’ll discover Functional Declarative Design and other design principles perfect for working in Haskell, PureScript, F#, and Scala."

I work in Clojure (and have done for over a decade now) so I'm wondering whether the book would be useful to me, given that you seem to be focused on static type systems and it looks like monads play a large role too?
3 months ago
Just found this thread through the April journal and it is a fascinating read. I was several posts into the thread before I noticed that the first piece of code was actually just the long-hand way of writing the second piece of code... Although I've worked with Java since 1997, my main day-to-day language is Clojure so the second piece of code, with the short function expressions, was very readable to me -- and my mind just sort of glossed over the first piece of code as "some verbose piece of Java that could be written more succinctly".

It was only as I got further into the thread that I realized the problem Monica was asking about was all centered on the types involved behind the scenes. To me, working in a dynamically-typed language based on abstractions, that question simply hadn't occurred. Which really made me appreciate two things:

1) just how impressive it is that functional style programming has been grafted on to Java in a way that offers such a succinct syntax,
2) just how much work goes into understanding how it works behind the scenes!

It's given me a much better appreciation of the amount of machinery that was added to Java's standard library and to its compiler, in order to support this style of programming.

2 years ago
An alpha of the PowerShell installer for Windows is now available:
2 years ago
Almost no one I know in software development is using the language(s) they were taught in academia -- and I actually don't think most "real world" programming languages are good for teaching about programming fundamentals. When I did my BSc in (Math and) Comp Sci, we did a little assembler to learn about the machine level (and we studied different machine architectures), we did a tiny bit of BASIC in the first year just to support Math coursework, and a lot of Pascal over the three years, so we could learn about pointers and memory (stack vs heap) and data structures and algorithms, problem decomposition, and so on.

The University of Washington has a CS304 course available online as "Programming Languages" which teaches fundamentals of various styles of programming -- statically typed functional (Standard ML), dynamically typed functional (Racket), and dynamically typed object-oriented (Ruby), on the assumption that students will encounter plenty of the "fourth quadrant" (statically typed object-oriented) once they get out into the commercial world.

I learned about a dozen languages at university (in my spare time, for fun), and I've never used any of them commercially. Over my career, I've used about a dozen languages in production -- and I've had to learn new languages to stay employable (my arc was loosely COBOL -> C -> C++ -> Java, with ColdFusion, Groovy, Scala, and Clojure since then, all on the JVM), and I've tried to follow the advice in "The Pragmatic Programmer" to "learn a new programming language every year". It's a lofty goal and I've typically only managed one language every two years, but over the last decade I've played with Elm, Go, Rust, and Kotlin (and was only disappointed with Go). I think learning new programming languages generally improves your skill in your "home" language, because you get to look at problems in a different way.

At this point, the programming language space is pretty crowded -- and only likely to get more so, I suspect -- so being a polyglot just makes sense from a career point of view.
2 years ago

R.J. Arzki wrote:specific scripting/programming language, like Groovy

I'm curious as to why you would categorize Groovy like that? I would consider Groovy to be a full, general-purpose language for the JVM -- just like Clojure, Kotlin, Scala, and several other languages that have appeared since Java.
2 years ago

Campbell Ritchie wrote:

Sean Corfield wrote:. . . I didn't start any threads in this promotion! . . .

You only need to reply to be eligible to win. And thank you for the generous donation to the runner‑up

I should read the rules more closely! I'll bear that in mind for future book promotions. I felt embarrassed given that I already won Kotlin in Action when that was the promo back in October 2017.

Congrats to whoever the new winner is!
2 years ago
That can't be right -- I didn't start any threads in this promotion! Someone else should win, not me. Please donate my book to another poster!
2 years ago

Peter Sommerhoff wrote:could you share which resources you meant? Were those suitable for programming beginners?

Unfortunately, I don't remember specifically what I read/used. It may well have been stuff recommended by folks in the Kotlin Slack. I do think the docs on the main Kotlin site are pretty good, as "new language" documentation goes.

As to suitability for complete beginners... that's really hard for me to judge these days, having been programming professionally for close to forty years (and five years "for fun" before that).
2 years ago
What a great question! I'll be interested to hear Peter's take on this.

I agree that Python would normally be a good recommendation for a brand new programmer but given the interest in Android apps, I would be comfortable suggesting Kotlin. Java is a simple, straightforward language but it has a lot of boilerplate that is distracting for beginners and it's very verbose. When I learned Kotlin, I found the tutorials to be excellent (much better than anything I've seen for Java) and the community is very enthusiastic and helpful (the Kotlin Slack was where I asked a lot of my newbie questions). If I were just getting started and wanted to build Android apps, I think I would find the cleanliness of Kotlin much more approachable than Java!

If your grandson does go with Kotlin, please make sure to keep us posted on how he's doing with it.
2 years ago