I still prefer Java.

I still prefer Java over other languages.

The Background: Javabot

I’m a fairly regular contributor to javabot, an IRC bot written for the Freenode ##java channel. I don’t know that I’d be considered a major contributor (I’m not listed in the credits, for example, so maybe I do know – and I’m not a major contributor) but I have a few solved issues to my credit…

But I think my contributions to the Javabot project are nearing an end, and the reason is really rather sad: Kotlin. Javabot recently underwent a conversion from Java to Kotlin.

Kotlin, as a language, looks really neat. It has features that I think Java could use; it’s probably a viable alternative to Java and, to some degree, Scala. I know a number of programmers who are using Kotlin, and what they describe sounds good.

But I don’t know Kotlin. I know a lot of coders, and of those, very few programmers who use Kotlin – and even though Kotlin looks neat, I can’t use it apart from cottage projects like javabot. The ecosystem around Kotlin is just too small.

That means that any contribution I had for Javabot would be severely limited by my own skill level in Kotlin – which is not experienced enough to even describe as “kotlin newbie” but is still stuck at “laughable.” Any code I wrote for javabot would be more of a burden than a benefit, since the code would have to be severely vetted.

I wouldn’t want a contribution to be a burden – any contribution of mine would be intended to make the world better, not harder. So I think that my participation in the project is limited by my own good intentions.

Prefer Java. Really.

The result, then, is that I’d suggest that coders use Java, even though it’s not as cool or as full-featured as some other languages might be. I’d be willing to consider projects in Scala, which has a viable ecosystem at this point (and has no difficulty leveraging Java’s ecosystem), and even Groovy (which leverages the Java ecosystem more than its own, as far as I can tell).

That’s not to say that Kotlin doesn’t have viability in its future, nor is it to say that I have no interest in learning Kotlin – it’s just a recognition that a new language is a burden to contributors, and because I don’t want to shoulder nor cause that burden, I’d suggest sticking with a language that’s common for the programming environment in which you live.

Addendum

I don’t blame the author for moving to Kotlin – javabot is a cottage project, really, and he actually did ask contributors their opinions before migrating. I voted for the migration. I just didn’t anticipate how I feel about it today as a result.

Essential Slick: a review

Essential Slick” is a book by Richard Dallaway and Jonathan Ferguson, published on underscore.io. It’s designed to be a compact guide to Slick, a database-access library for Scala, and succeeds admirably in its goal, even in early-access form.

The book is very easy to read; it’s published in multiple forms (epub, HTML, and PDF). I chose to read the HTML version, as I’m reading it on a Macbook, and HTML just seemed the most generic.

However, the content is the most important part.

I’ve tried to play with database access in Scala; I usually end up working with a model written in Java, accessed via Hibernate, because of familiarity with Hibernate and, more importantly, because the documentation for various Scala database access mechanisms is simply inaccessible to me – generally being unclear or simply not working.

I have tried Slick tutorials, for example, and the Hello, Slick example projects – only to have them fail out of the box or simply not working, without clear explanations.

I’m pleased to report that this has not been the case with Essential Slick – the code has worked very well, and been explained clearly.

While in early access, there are a few minor problems – for example, in the book’s source code they use durations early on without specifically including them or describing them. (The example project, however, does include all required types.) Likewise, the output from the example project is slightly different (being far less verbose) than the book’s project code.

These are not real problems, at all; durations are fairly obvious, and the debug output is actually very informative. It just wasn’t entirely expected.

The exercises are useful, and are accompanied by explanations of various problems you might encounter; this is very newbie-friendly (as one would hope from an introductory text) and therefore targets its audience perfectly.

Topics proceeding through the book include selection, modeling, and combining actions (i.e., building complex transactions). Along the way, some assumption of Scala knowledge is expected, but it’s not written arrogantly – Scala beginners can expect to understand the content.

By the end of the book, even in early access form, readers can expect to have functional and useful knowledge on Slick, and can expect to be able to write workable applications leveraging relational databases and Scala.

I’ve found the book to be highly informative – and, if you’re using Slick, necessary, compared to the other Slick resources out there. Highly recommended.

A few thoughts for a Monday…

Life has changed a lot lately.

First, I changed employers; I’ve left Red Hat (for various reasons) and am now working for a company that will give me a little more direct purpose, along with an imperative for using Scala. (Did you see what I did there? Scala’s typically a functional language, not an imperative one, so.. um… a pun’s still funny if you have to explain it right?)

Second, my wife and I both use the Microsoft Surface 3, in addition to our regular working computers. This means that unless you count virtual servers, I’m using more instances of Windows than anything else. (If you factor in remote hosts, Linux is still ahead.)

It’s an interesting set of changes. The job is going to be a lot of fun – a lot of work, but it’s a good fit for me, I think. Red Hat’s still a great company; if I’d not changed jobs, I’d still have been pleased to work for them.

However, this is a good change, and Scala is something I’ve enjoyed as a very casual observer; this gives me a chance to really roll up my sleeves and approach the language with a real intent and purpose.

Functional programming’s going to take some getting used to, though. I’m reading an excellent book, “Functional Programming in Scala,” but deep into the book – I cheated and read ahead – it says “Cause side-effects but shuffle them around so their location is more tolerable.” (Not a quote, even though it’s in quotes.) I’m not sure that’s a terrible idea – at some point you do have to have an actual effect – but the way it’s offered is odd. It introduces an inconsistency in the FP paradigm, and then handwaves it away.

The Surface is a wonderful device. Since it’s running the same platform as my other Windows devices (as opposed to the Surface 2’s Windows RT) I can migrate seamlessly between computers; the form factor is different, but little else is.

The form factor, however, is quite a change. I find the lack of an Insert key to be very much the absolute worst thing about the Surface – a lot of programs use it, and they left it off of the physical keyboard. (The virtual keyboard has it but eats up a lot of your screen space. I’ll use it on occasion, but definitely I far prefer the physical keyboard, which is part of the cover.)

Apart from the Insert key, the right mouse button relies on time of contact, which is something to get used to; an alternative is to use a Bluetooth mouse (or USB mouse). I’m still adjusting to that aspect of the Surface, but it’s less of a deleterious effect than the lack of a physical Insert key.

With all of that said, the Surface’ ability to be a tablet is fantastic. It’s my new book reader, hands down; the larger screen (compared to the Nook HD+) and more solid feel (along with the much higher resolution) is excellent for reading.

However, I’m moving away from Amazon; most of my library’s in the Kindle format, and I suppose that can’t entirely change (what with prior investment) but honestly, the Nook Reader application on Windows is far better; with the Amazon application for Windows, I can’t read my own content, and with Nook I can. I’m an author; I get my own books in EPUB format, and I purchase a lot of books in EPUB. With the Kindle for PC app, I can’t read them on the Surface; I have to use the Nook HD+ or my phone.

It’s not good that I can’t use my Surface for reading my own content. It’s not the Surface’ fault – it’s Amazon’s. If and when Amazon fixes it, I’ll be willing to use their reader again (and I’d prefer it, because that’s where most of my library is), but until then, Nook for Windows wins by simple default. It’s just as readable, and the fact that I can import my own content makes it a huge win.