Abstract

Examples of currying, or partial application, are often simple enough to get the concept across, without suggesting real-world uses. This article describes a simple, practical currying example.

Introduction

I’m not the world’s best functional programmer; I’m still getting my head around many of the concepts. The functional approach appeals to me greatly, but there are common functional constructs that I’m still internalizing.

Until fairly recently, currying, or partial application was one of those concepts. It’s not a difficult idea to understand; most of the examples I’d seen make the concept of currying easy enough to grasp. But the examples never translated well into practice for me; they had little bearing on the kinds of programming I do every day. I just couldn’t think of a place where I was likely to use currying in my day-to-day programming. (This, obviously, speaks more to my lack of imagination than anything else.)

Then, I stumbled across a use that drove home the power of this simple technique.

In this article, I’ll be using the Scala programming language, but the concepts are not specific to Scala.

A few of us Scala enthusiasts in and around the Philadelphia, PA, area have been throwing around the idea of a Philly-area Scala group. Courtesy of Mark Chadwick, we already have a cool name; we just need the people to go with it.

The proposed group name is PHASE, for Philly Area Scala Enthusiasts. This name is a blatant riff on BASE, the Bay Area Scala Enthusiasts group. PHASE currently has a mailing list. We’re trying to gauge how much interest there is in Scala, in the Philadelphia area. If you’re interested, please come join the mailing list.

If we can get 20 people (give or take), we have a big enough group to warrant monthly meet-ups. The idea, obviously, is to provide a means for Philly-area Scala users and fans to get together and network, share experiences, help each other out, invite speakers, evangelize Scala–whatever.

If you think this sounds as interesting and useful as we do, then stop by the mailing list and sign up, so we know how to reach you.

Introduction

I have been doing my personal development primarily in Scala lately, and I use the excellent SBT (Simple Build Tool) program to build my code.

To make the my libraries accessible to others, I could simply place the jar file somewhere, such as the “download” area of the project’s GitHub repository. This works fine, as long as the jar has no dependencies. However, if my jar depends on other libraries, anyone using my code has to chase down and install those dependencies. A better solution is to create and deploy a Maven file, since the POM file will capture those dependencies.

As it happens, SBT has excellent support for Maven. It will generate a POM automatically, and it will publish to a Maven repository. In most cases, you never have to write a single line of Maven XML; SBT handles all that for you.

Since I already have a public server, I found it easier to create and manage my own Maven repository, rather than try to get authorization to publish to a well-known one.

This brief article describes one way to get SBT to publish to a personal Maven repository.

I wrote a Scala-based SQL REPL called SQLShell. To make it more portable, I chose to write a Scala readline wrapper API that talks to multiple underlying readline implementations; that way, SQLShell could use whatever was available, without the need for special-case code. (The readline wrapper API, which supports editline, GNU Readline and JLine, is available in my Grizzled Scala library. See the grizzled.cmd and grizzled.readline packages.)

Naturally, I wanted to support tab completion. But, as it happens, most completion APIs are a little clunky. They give a bare minimum of information, leaving a fair amount of work to the caller.

For documentation, simple markup is often best. For instance, I used to write this blog in reStructured Text; the blogging engine’s Python back-end converted the reStructured Text markup to HTML. (I now use Markdown.)

When I started writing more Scala, I wanted to do something similar with the documents (the user’s guides, README files, etc.) that go with the code I write. I looked for a reStructured Text parser in Scala or Java, but I couldn’t find one, and I didn’t feel like writing one. I could probably have used the existing DocUtils package with Jython, but that seemed like a lot of extra overhead, just to generate HTML from a simple text markup file.

The Scala 2.8.0 Beta 1 prerelease was released on January 27, 2010. I have finally begun converting my Scala code to 2.8. During the first pass of the conversion, I changed my code to get replace calls that are now deprecated or no longer supported. The second pass, however, has been more interesting.

Scala 2.8 adds many new features. So far, I’ve only managed to play with a few of them, but those few features I’ve tried really make a difference. For instance:

• Named and default arguments have allowed me to simplify some of my objects and classes, sometimes dramatically. Alternate constructors and overloaded methods often just go away, to be replaced by a single method with default parameter values. I really like this feature in other languages, like Python, and I’m thrilled that Scala finally has it.

• The new @tailrec annotation is fabulous. There are places in my code where I assumed tail call optimization was happening, but I hadn’t bothered to verify it by looking at the byte code. Using @tailrec, I’m quickly finding the ones where my assumptions were wrong, without having to disassemble the class files myself. This one simple feature is proving to be an incredible time-saver.

• The revamped Scala REPL is a joy to work with. The addition of tab completion alone has proved to be incredibly useful.

As I dig further into Scala 2.8, I fully expect to find other wonders. I am looking forward to digging more deeply into the redesigned collection libraries.

Over the past few years, I’ve become more and more of a skeptic and rationalist. (Long live the Age of Enlightenment.) Along the way, I’ve become enamored of various skeptically-oriented podcasts.

Mark Crislip (an M.D. and infectious disease specialist) has several entertaining podcasts:

• Puscast, a biweekly, CME-accredited review of the infectious disease literature. I actually find this one to be good listening, despite not being a health care worker.

• A Gobbet o’ Pus. Podcasts based on Crislip’s Rubor Dolor Calor Tumor blog. These are usually short, about five minutes or so, and touch on medical-related issues.

• Quackcast, a “podcast review of Quacks, Frauds and Charlatans. Oops. That’s not right. That should be Supplements, Complementary and Alternative Medicine i.e. SCAM.” Highly rational and frequently hilarious.

In addition, there are a couple others I like:

• Skeptic’s Guide to the Universe. A panel of skeptics, most of whom are involved in the New England Skeptical Society. Plenty of good info on this podcast, as well as a weekly dose of rational thinking. Worth listening to. Episodes range from 20 minutes to 45 minutes in length.

• Brian Dunning’s Skeptoid, a short, typically single-topic, skeptical podcast. Most episodes are under 15 minutes.

I’m always on the lookout for other podcasts people think are interesting. Feel free to share.

How not to build a database:

1. Create a schema, and fill it with useful data.
2. As needs grow, and you have to consume slightly different kinds of data, don’t fix the schema; instead, clone the original schema, and hack the clone to fit the new data.
3. Repeat step 2 at least 30 times.

I’m often surprised how poorly structured corporate production databases can be. It’s clear, in hindsight, that such databases weren’t planned. They grew in the same way that many American suburbs grow: in fits and starts, driven by the need for revenue and profit, with minimal technical oversight.

Many people in corporate America seem to be designing data solutions without even a rudimentary understanding of database design, using tools like Microsoft Access (or PHP and MySQL).

The easy availability of simple database tools is not always a good thing. Microsoft Access, in the hands of some folks, is like a pistol in the hands of a 6-year-old: You can explain the principles of safe use over and over again, but there’s still a strong likelihood the kid’s going to shoot himself in the foot.

I picked up a copy of Beginning Scala a week ago, and I’m finding it to be a useful complement to Programming in Scala. I dropped a quick note to David Pollak, the author of Beginning Scala, and in his response, he wrote:

Oddly enough… I think Beginning Scala is kinda useless for folks who are already into Programming in Scala… but I’m glad you’re finding it useful!

He’s wrong, though, at least for me.

I’m currently teaching myself C# (with .NET to follow); my client is building a new data warehouse, and the support tools will be Windows-based. As a newly minted consultant, it also can’t hurt to have .NET/C# experience under my belt, even if I generally prefer to do my development anywhere but Windows. As a consultant, I need to maximize the possibility of getting future contracts; if that means doing Windows, I’ll do Windows (and program where I’d prefer to program at home).

As pretty much anyone who knows me knows, I am not a huge fan of Microsoft. I’ve spent a large part of my career programming on Unix-like systems. From 1999 to 2008, I worked for an independent software vendor, as a core member of their development team; the product was written almost entirely in Java.

I like the Java VM. It’s mature, it’s fast, it’s highly portable, and there are loads of languages running on it. When I was developing full-time in Java, I was the only member of the team whose desktop ran Linux; everyone else used Windows. With Java, it didn’t matter. In fact, it was an advantage. Several of our clients ran our software on Unix-like systems; having at least one developer who used and tested our product on Linux was a win. Our nightly build system was a cheap Linux server, as well; since Java runs anywhere there’s a Java VM, anyone on our team (as well as any of our customers) could run executables produced on that Linux box.

But Java, the language, depresses me lately. It’s being left in the dust by other languages. Scala, my current favorite language on the Java VM, incorporates many newer (and some not so new) ideas that have yet to find their way into Java.