Derive a common utility or library for options and constraints from something like scopt and Unfiltered’s parameter validation library. With a common way to specify input arguments, functions to produce boiler plate for command like programs and web endpoints would be easy to write. This would be a great use for scalaz / validation.
What does a compiled curried method in Scala look like in java? Compile this:
object Concat {
def concat(s: String)(ss: String) = s + ss
def concat(s: String)(i: Int) = i + s
}
Now inspect the resulting class with javap:
Compiled from "Concat.scala"
public final class Concat extends java.lang.Object{
public static final java.lang.String concat(java.lang.String, java.lang.String);
}
After compilation curried methods look like normal, multi-parameter methods. It doesn’t matter how many parameter lists you define, nor how many parameters each list takes; in the end you get a plain old method. Knowing this we should expect overloading to work fine, so let’s overload our curried method:
object Concat {
def concat(s: String)(ss: String) = s + ss
def concat(s: String)(i: Int) = i + s
}
As expected, this compiles, and javap gives expected output:
public final class Concat extends java.lang.Object{
public static final java.lang.String concat(java.lang.String, int);
public static final java.lang.String concat(java.lang.String, java.lang.String);
}
Great, let’s use it!
object Concat {
def concat(s: String)(ss: String) = s + ss
def concat(s: String)(i: Int) = i + s
}
object Concatter {
def greet(who: String, msg: String) = Concat.concat(who)(msg)
}
And compile:
Concat.scala:7: error: ambiguous reference to overloaded definition,
both method concat in object Concat of type (s: String)(i: Int)String
and method concat in object Concat of type (s: String)(ss: String)java.lang.String
match argument types (String)
def greet(who: String, msg: String) = Concat.concat(who)(msg)
^
one error found
Well, that was unexpected! The compiler let us overload a curried method, but it won’t let us use either of them. The error tells us that the compiler is unable to disambiguate the method. This seems strange as we’re explicitly passing values for all arguments. Try as we may, there simply is no way to use these methods as defined. As it turns out, this is a problem of scope. Let’s try different access modifiers:
object Concat {
def concat(s: String)(ss: String) = s + ss
protected def concat(s: String)(i: Int) = i + s
}
object Concatter {
def greet(who: String, msg: String) = Concat.concat(who)(msg)
}
This compiles because Concat.concat(s: String)(i: Int) is not in scope at the call site (it’s not accessible). However, within Concat both are in scope:
object Concat {
def concat(s: String)(ss: String) = s + ss
protected def concat(s: String)(i: Int) = i + s
def con = concat("")("")
}
Concat.scala:4: error: ambiguous reference to overloaded definition,
both method concat in object Concat of type (s: String)(i: Int)String
and method concat in object Concat of type (s: String)(ss: String)java.lang.String
match argument types (java.lang.String)
def con = concat("")("")
^
one error found
If you’re overloading curried methods, remember that you must demarcate their potential scopes with access modifiers. Two overloaded curried methods with the same access levels will never be callable; they will compile unless you try to use them. Perhaps a more fundamental lesson to learn from this is to eschew method overloading in general, always.
For several years now I’ve felt that, at some point, I’d like to move to New York City. I visited the city for the first time in 2009, and I was just taken. Its history, strength, character, diversity, and cultural wealth captivated me.
Still, there was something else. I had just recently discovered the Scala programming language. I’m a polyglot programmer but I’ve spent a lot of time on the jvm. When I was exposed to Scala, my first reaction was merely: “Wow, this is cool!” And then the paradigm shift began as I inadvertently embarked on a mind-altering journey into the world of functional programming. It’s been frustrating, illuminating, continuous, and it just keeps going.
But I digress. One of the reasons that I’m moving to New York is that there are many bright, passionate people that make up a vibrant community of programmers; functional and aspiring-to-be alike. It is a place where exploring concepts with others is easier; a place where cross-pollination of ideas and paradigms common. What’s more, there are companies building great products that are harnessing this energy (like the one I’m joining). I’ll be making the switch from full-time Java to full-time Scala, and while I’m new to the company’s industry, I’m no newbie to Scala. I’m full of an excitement laced with a bit of healthy fear, and I can’t wait to start.
— Ayn Rand
First things first, open a linux or mac terminal and tap into the RSVPs stream:
curl http://stream.meetup.com/2/rsvpsWhat you’re seeing now is each RSVP to a public Meetup group as we receive it. When a user clicks an RSVP button or an application calls the RSVP method, the server handling the…
Last night, Erin and I opened presents that had arrived in the mail from my parents. One of them was a folded, unassuming manilla envelope, and inside was another folded manilla envelope. I unfolded the inner envelope to reveal a 5x5 floppy disk which, at first, confounded me. Looking at its label I immediately recognized my mother’s handwriting; it identified the disk as “Chris’ Game.” It was accompanied by a note from her, stating “The floppy disk may have Chris’s first programming efforts - a game in Q-basic, I think.” These simple words are precious.
My family is not one of technophiles, and in fact they might be better described as technophobic. They worked at a small college with a quaint computer lab, and one day a friend told me I could use that to make a game. My mind was blown! He then introduced me to the computer that would become my first workstation: an IBM (compatible) 80286 with a turbo switch. It was running a later version of DOS with a menu-driven UI called DosShell. Having almost no previous exposure to computers, I didn’t know how to be picky.
My friend didn’t know much, but he knew that much more than I did. He showed me how to navigate the system, how to start the QBasic environment, and how to evaluate simple statements (print to the screen, basic operators and math functions). I didn’t know what any of this stuff was, but I soaked it up with wonder and learned quickly. I don’t remember the exact date, but this must have been in the summer of 1992 or 1993. In the following weeks I spent countless solitary hours exploring the computer, spending most of my time in QBasic. A day or two in, I started writing my game.
I remember this game. I remember its source code. It was a text-based game of monsters, magic, and battle. I remember the depression I felt when I concluded that it was impossible to randomize the output of a fight, a problem on which I had spent a day or two hacking to no avail. And then I discovered the interpreter’s help system, which eventually led me to the RAND function (a pseudo-random number generator). This proved to be a solution to my problem, and behold, nondeterministic battles! Anything was possible! I did what I wanted, coding with pure joy and blissfully ignorant of any consequence other than bugs in my game. Everything I did, I did to make the game better: I added stronger monsters, magic, shops, items, weaponry, and commerce (you could buy and sell items and weapons). It was awesome! More than awesome, it revealed a lasting passion in me at a fairly young age: I loved to program.
I’ve received many gifts of sentimental value in my life, but never one I’d describe as “grounding.” In a month I’ll be 30 years old. 30! We change and we grow, and sometimes an analysis of who we are compared to who we were leaves us puzzled. To hold this 5x5 floppy disk in my hand; to reflect on the stumbling, clueless child that I was as I elatedly copied my source code to and from its magnetic memory some 17 years ago is truly grounding. What lies encoded on this disk is an immutable fragment of me; a reminder of who I am. I cannot imagine a better gift!
Happy New Year to all. To open 2011 I impart this simple declaration to myself and you all alike:
Do what you love and do it with passion. If you aren’t happy, do something else.
Last weekend I attended the first annual WebDirections USA conference, in Atlanta, GA. My primary takeaway is that JavaScript on the server side will continue to make enormous gains comparable to those made by rails when it first appeared on the scene.
Yeah, that’s huge.
Of all the sessions, NodeJS and the expert panel resonated with me over the rest. The node session was a simple, thorough primer; nothing of any apparent philosophical value. However, the expert panel, and specifically a bold assertion made by Tantek Çelik, sent my head into overdrive. His thesis: in 5 years, every server side language will be dead or dying, being replaced by JavaScript. For a split second I merely giggled, and then I went somber; pensively spiraling into a future far different than the one I had imagined, and certainly different from the one I wanted to see.
This assertion did not sit well with me. The rails phenomenon shocked the web world, in many ways for the better, but it is a phenomenon I have never fully embraced.
On Friday night I engaged Tantek about this issue, hoping to gain a better understanding of his perspective, as well as my own, since he had dealt me a debasing blow. He clarified his prediction: in 5 years, all other language communities will have ceased to grow, and likely be in recession. Why? Ubiquity. JavaScript is the most widely deployed language on the planet, and huge numbers of people have at least some knowledge of it, as well as CSS and HTML. It is also a comparatively productive and relatively simple language, converging on what seems to be critical mass.
What do you get when you mix ubiquity, simplicity, and productivity? World takeover. Well, maybe.
I take issue with this idea. I have not yet fully formed my opinion, but the thought does cause me a bit of anxiety, and I shared this with Tantek.
What’s my deal? Am I sour that my preferred languages are not on the forefront of the next apparent revolution in web development? Maybe a little, but that’s hardly the crux of it.
Typing (integer.sayHello())
This is a battle that goes back decades. Dynamic interpreted languages are popular for at least two reasons: they are, or rather, they seem to be, simpler to learn and use, and they are more productive in the day-to-day development cycle. I am perhaps a minority among my fellow generation Yers in that I prefer static typing. No, I don’t like superfluous typing and no, I don’t merely want a static hint at what an argument is capable of (though you could make a fair argument for this). I prefer static typing because it is inherently more correct.
Static typing guarantees that, in terms of the expressed capabilities of a program’s abstractions, the calls made on these abstractions are logically sound. That is, during the compilation phase, if you call a method sayHello on an instance of Integer, the compilation will fail. It simply isn’t possible to make this mistake.
Further, many dynamic languages (PHP, ruby, python, javascript, …) allow arbitrary changes to arbitrary references throughout a program’s abstractions. That is, given an object Math which contains a reference PI, such that Math.PI equals 3.14159, it is possible for any piece of code to change that reference, such that Math.PI might then be 42, or 0, or “some arbitrary value of some arbitrary type.” In fact this practice, “monkey patching” as pythonistas call it, is embraced in many of these communities. You might call this flexibility, but on a good day I call this a poor facility for abstraction, and on other days insanity.
In a static language, this is simply not allowed. Some languages, specifically Scala (via implicit conversions), provide this same kind of structural flexibility without sacrificing static integrity. Static typing has a historical stigma of pain, but it is has improved in leaps and bounds. I only hope we haven’t lost the attention of developers.
Null (i = null; i.toString())
JavaScript, like most languages, supports the notion of a null pointer (or null reference). In most languages, including JavaScript, no tool will help you avoid this. Any object can be assigned this value, even in most static languages, in which it is viewed as a subtype of all types. In such an environment, a null pointer is a ticking time bomb. You get no help from tooling, so if you forget to check something (and we do this all the time), you get a runtime error. Seasoned developers struggle with this; it is a non-intuitive problem. On the other hand, many functional languages (like Scala and Haskell), employ monadic types to remove this problem.
The problem of null is neither new or superficial. The inventor of this concept, Sir Charles Antony Richard Hoare, spoke to an audience about the history of null, regarding it as a “billion dollar mistake.” Incidentally, he also says quite a lot about static typing in that talk, so I do suggest watching it.
Concluding
I think Tantek might be right, even if in a slightly lessened fashion. Further, while the future I want to see differs from the one I feel impending, I’m not in despair. Rather, I’m currently enjoying hacking on NodeJS, all the while seeking out what I see as the ideal future.
— Tony Hoare
— Tony Hoare
