Win a copy of Python Continuous Integration and Delivery this week in the Python 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
20
In last 30 days
2
Total given
0
Likes
Total received
76
Received in last 30 days
4
Total given
25
Given in last 30 days
1
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Sean Corfield

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.
3 weeks 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.
3 weeks 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!
3 weeks 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!
3 weeks 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).
3 weeks 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.
1 month ago
I think programmers using languages professionally that they learned in college is a relatively new trend -- and I don't believe it's a good one. Very few seasoned programmers that I know are using the languages they learned in college. Colleges should be teaching foundational thinking around programming. A great course is University of Washington's CS304 which teaches the principles of programming languages using Standard ML, Racket, and Ruby -- so you learn about (both static and dynamic) type systems and functional programming and a fairly pure form of object-oriented programming and metaprogramming...

My college taught a little BASIC, a little assembler, and a lot of Pascal. But I also taught myself about a dozen other languages while I was at college and my first paid work was in COBOL and assembler, followed by C, then C++, then Java (starting in '97). Since then I've used ColdFusion (CFML), Groovy, Scala, and now Clojure in production. "The Pragmatic Programmer" recommends trying to learn a new programming language every year if you can -- there are certainly enough of them out there! -- and it's a lofty goal but it's good advice. Over the last several years, I've learned Elm, Go, Rust, and Kotlin. Of those, only Go was a disappointment to me.

Academics generally don't do a good job of teaching a programming language because they don't work it in day-in, day-out, so they don't know the pitfalls and the idioms. They are much better at teaching the principles of programming and that is what colleges should be teaching, in my opinion.
1 month ago

Terry Broman wrote:Convince me I need to learn yet another programming language.


The book "The Pragmatic Programmer" encourages developers to grow their skills by setting a goal (p14) to "Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet (see page 267)."

It's a lofty goal. I've tried to pick up new languages as often as I can but it's more like every two years or so. In addition to using Java, Groovy, Scala, and Clojure at work, over the years, I've also learned Go, Rust, Elm, and Kotlin, and a bit of Ruby and SML -- via online courses and tutorials. I highly recommend reading that book and trying to follow its advice (it covers a total of eight goals across pages 14 & 15).
1 month ago
I'm not any sort of authority but wanted to respond to a couple of Hugh's points here...

Hugh Mungus wrote:I have literally just started actually learning how to write Kotlin in the last few days. It seems pretty straight-forward so far and I can certainly see the attraction of having a more concise way to write code. It doesn't seem to lack any of the many features of Java (but perhaps I haven't seen those yet) and adds several other nice features, like null safety.


This comparison to Java on the Kotlin web site lists Java features that Kotlin does not support, as well as the (long) list of features that Kotlin adds. Several of the "missing" features are considered problematic in Java by many programming language designers and some other features have (better) alternatives in Kotlin. The JVM supports a lot of languages these days and each of them represents a set of trade-offs that their designers have considered and prioritized. As a developer, whether you "like" a language or not is very subjective. For example, Kotlin omitting Java's static members and instead offering package-level functions, object declarations, and companion objects seems to me like a much more flexible and consistent approach.

But is that all Kotlin is trying to be? Or is there a bigger vision at play here that I just haven't come across yet? For instance, do the creators of Kotlin hope to make Kotlin work with OTHER languages as well, such as PHP or Python? Are they hoping to REPLACE Java at some point or do they plan to essentially stay a language that always gets converted to Java via a preprocessor?


Kotlin, like most JVM languages, compiles down to JVM bytecode directly -- it is not a preprocessor that produces Java. Kotlin, like several other fairly recent languages, also has options to compile to other targets (such as JavaScript and also native code via LLVM -- see this blog post announcing Kotlin/Native, from April 2017).

I won't presume to answer the vision/goals questions asked here, and I'm looking forward to seeing answers to those questions from others with more insight.
1 month ago
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.
9 months 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.
9 months 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?
1 year 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!).
1 year 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).
1 year 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).
1 year ago