2010-09-28
The Perennial Java Problem
The hypothetical “good programmer” should learn a new programming language every year in order to keep up with the latest and greatest in the programming world and keep their brains nice and fresh. This is of course old news to anyone who has read The Pragmatic Programmer and similar works but it doesn’t hurt to bring it up every once in a while! When working on AppScale I got to learn Ruby and was infinitely happier for doing so, and while AppScale also uses Python I don’t feel as though it’s sufficiently different to justify calling that my language for this year. So with that said, I investigated what I will politely refer to as “the Perennial Java Problem”:
The Perennial Java Problem: Find a programming language that sucks less than Java but can still be used for real work.
If you are a programmer who has used Java, you likely already know what I’m talking about: Java is great but has some serious shortcomings. For starters, using Java without Eclipse or NetBeans is a death wish. This is already lethal for a person like me, who had fallen into the “vi/emacs or GTFO” mentality. Disagree with me? Try programming the sample apps for the Android without Eclipse. I tried it, succeeded, and learned a lot for my trouble, but it’s truly a second-rate experience compared to using Eclipse to do the same job. So why do you need Eclipse for this? Because (insert drum roll sound here) Java is ridiculously verbose. I know, you already knew that. But the sheer complexity of the jobs Java now supports means that you can BE A BIG MAN and use vim and ant and the COMMAND LINE to take an hour to run the first iteration of a note pad application on the Android or you can spend five minutes doing it in Eclipse. Sheer pragmatism demands that you break out of the “vi/emacs or GTFO” mindset if you want to program in certain languages.
As far as I’m concerned, Ruby solves the Perennial Java Problem for me well enough – it is simple enough that I can actually use vim to program in it and not regret the decision until the day I die. It can do the things I actually need to do to get work done with extreme ease – read and write files in less than a dozen lines of code, write a web application that I can actually use in an hour, and the inevitable “throwaway scripts” that Ruby excels at that are just enough of a pain in the ass that I can’t use Python or Java for. Granted, I still give the fantastically worthless award of “best web framework” to Python Google App Engine’s webapp, since it truly embodies the spirit of you have work to do so I’m doing to make this as simple as possible for you. However, reading/writing files and shell scripting is still a pain in Python compared to Ruby (To the Pythonistas out there: it’s not that bad – it’s just not as easy as Ruby).
So why don’t I just go get married to the Ruby programming language then, since I’m obviously so in love with it? Well, although I obviously love Ruby, there still is the whole “learn a programming language a year or your brain will rot and you will do is think Ruby until the day you die” issue. This nicely brings us back to the (modified) Perennial Java Program:
The Perennial Java Problem: Find a programming language that you don’t already know that sucks less than Java but can still be used for real work.
Historically speaking, the latest and greatest programming techniques are inevitably stolen from functional programming languages (e.g., garbage collection, dynamic typing), so why not just cut out the middleman and learn a functional programming language? Well it’s because of that last bit of the problem: the language needs to be one that I can do real work in. And the experience for me with a functional programming language is always very similar to the following:
- Invention: The Gods of Functional Programming have bestowed upon us mere mortals a new functional programming language, X.
- Sales Pitch: This language can compute a lazy infinite set of integers IN ONE LINE IN PARALLEL OMG
- Sold: I immediately decide that this language is amazing and all others are immediately inferior
- Disappointment: I can’t figure out how to read or write a file in less than a dozen lines without breaking all the fundamental concepts the language holds dear to its heart.
- Depression: I return to the previous programming language I was using and am unable to bring back anything profound from the functional programming world to it.
Part of the reason that functional programming languages haven’t clicked with me is points (3) and (4) – I’ve decided to use this language for everything and maybe I shouldn’t. This is partially my fault: it’s easy to say X is great for this so let’s use it for everything. For Ruby this works fine most of the time but for Java not so much (specifically with respect to shell scripting). When approaching functional programming languages I (perhaps mistakenly) approach them with the mindset of how is this an improvement over what I’m using now? And since they (perhaps naturally) fall short on the things that I need to do for my work, maybe I’m setting myself up for failure with them.
Let’s then look at a (relatively) new programming language and examine exactly what problems it solves:X10. It’s one of the many “runs on JVM” languages but has the following features that I find particularly interesting:
- First-class functions and anonymous functions – functions can be passed around to other functions, stored in variables, or not if you don’t want to.
- Domain specific: It aims to solve the problem of writing concurrent applications – so it doesn’t aim to replace Ruby/Python for your shell scripting and web app needs, but bills itself as the language to use when you have some serious computation to do.
- Compiles to Java bytecode for serial execution mode or (more interestingly) to C to be deployed over MPI
- If compiling to Java bytecode, can interact with Java code
- Looks very much like what UPC was for C – adding simple but powerful PGAS abstractions
The second point is the crucial one from what we’ve been talking about here: it aims to do concurrent / distributed programming very well and not so much of anything else. This is fine by me, as I can still stick by my favorite Ruby for all other tasks and use X10 for the tougher work. Furthermore, its Java interoperability is a nice touch should I really happen to need something from Java-land (although I can’t think off the top of my head what I would need in this programming domain).
Will X10 “suck less than Java for doing real work”? Time will tell. But initial hopes are high – the Eclipse integration is very nicely done and the documentation in there is extremely helpful. And while X10 looks like it will be a “need to use an IDE” language, that’s fine by me as long as it gets the job done.
2008-07-16
The Quine Kata
Many software developers agree that the best way to be a good programmer is to program. That sounds obvious to most of us (even those that don’t program), but it’s simply not enough to program whatever it is you do for a living. Improving your coding techniques on your work code helps, but I think it’s best to try out your new techniques on code that’s totally different from what you normally do. I picked up on it a while ago from CodeKata, and it’s why I like messing around with language interoperability and other random stuff that I haven’t had to use thus far in my programming life. It just boils down to the adage given by Abraham Maslow: If the only tool you have is a hammer, you will see every problem as a nail. So get out there, learn tons of different techniques (and possibly programming languages), and get as many tools mastered as possible! That being said, some background is necessary. I recently came across an interesting notion in the current book I’m reading, Gödel, Escher, Bach. It’s called a quine, and can be summed up in a kata-like form as follows: Write a program that uses no input and outputs only the source code of that program. Wikipedia has some interesting solutions to the problem (one of which didn’t even work for me), but they all seem to rely on the ability of the printf function to engulf itself. If you haven’t looked at the solutions yet, give it a try. It’s not particularly obvious what to do, but when you see the solution you’ll have the “aha” moment that typically accompanies katas. That being said, I got more out of the kata by trying it in a language that I’m decent (but not great) at with, Scala. My Scala solution to the Quine Kata is: Unfortunately to get it exactly the same you need to remove the newlines so that the code is all on one line (which I would have put it in originally if the formatting on WordPress didn’t chop it off). If there’s a new language you’re so-so with, try it out! Even though you’ve seen the C solution from Wikipedia and this Scala solution that uses the same technique, there’s still much to get out of trying this out in a new language. If there isn’t a new language you’re messing around with, why not? Go out there and pick one already! Make sure that you use ‘diff’ to compare the results to make sure they’re EXACTLY the same (there were a few times when I was close but not exactly so) Two other interesting questions remain: how do you get the newlines in (presuming you can), and are there other tricks you can use in other languages to achieve this goal? There’s a Scheme solution on Wikipedia but it doesn’t seem to produce the exact same output (but I don’t know Scheme well enough to defend this argument). Furthermore, using printf in whatever language you use is essentially a C solution since the style of your code is basically C (e.g., how similar the C and Scala solutions are). This type of program is interesting to me in the same way that Reflection is (although they’re completely different): that they both are like metaprograms (programs that produce programs or programs that program). I’ll definitely go more into depth later on Reflection since there’s quite a bit that it offers. But the Quine Kata has merit in a different way: that the program produces exactly whatever you produced to make the program. It definitely follows the spirit of Gödel, Escher, Bach (also something we’ll review once I’m done reading it) and is just fun to mess around with for a little while (which is why it’s great as a kata).object Quine extends Application {
var s = "object Quine extends Application { var s = %c%s%c; printf(s, 34, s, 34); }";
printf(s, 34, s, 34);
}
2008-06-30
First Thoughts on Scala
Another side project I’m exploring this summer is the Scala programming language. It’s got a ton of wild and wacky features and is interesting enough to merit further exploration. That being said, I’ve used Scala on and off for a few weeks and have come up with the following thoughts on Scala: For those not familiar with Scala, it’s object-oriented (objects are “first-class”) and functional (functions are “first-class”). These have been here for a while independently, with Smalltalk from 1980 (in terms of OO languages) and Lisp from 1958 (in terms of functional languages). They’ve also been here for a while together: a notable one I’ve used in the past is O’Caml, and a library for Java exists that provides the language with closures (Functional Java). So what makes Scala special? Scala runs on the Java Virtual Machine, and can use your current Java libraries effortlessly. There’s a lot to be said already for that, since it’s well known that academic and functional languages suffer from lack of good library support (something Java has in spades). Others have claimed that Scala can compile to MSIL and run on via the .NET Framework, but even with the official instructions I’ve had nothing but problems across several architectures and operating systems. The other big difference between Scala and other functional, object-oriented languages (asides from the library support) is the syntax style. Languages like O’Caml and O’Haskell give you OO in the style of their original language (e.g., ML for O’Caml and Haskell for O’Haskell), which is great if you’re already an amazing functional programmer. But arguably the biggest reason functional languages haven’t been accepted is that it’s so hard to train an imperative, OO programmer (who likely was brought up on C, C++, or Java) to program in an ML/Lisp/Haskell-like language. The syntax/symantics learning curve to jump to these three languages is just too daunting for most programmers. Since Scala is closer to the C-like languages in terms of syntax and semantics, it’s inherently an order of magnitude (at least!) easier to learn than the traditional functional languages. And since it still has some minor remnants of functional syntax and semantics in it (e.g. the last statement in a function is its return value), it’s easy for functional language users to pick up. If you’ve believed every word I’ve written blindly so far you may think Scala is the best thing since, let’s say, sliced bread. Scala’s got its weaknesses, for sure, but it’s oddly enough also its strengths (possibly…). The first language I really got to know well was Java. And I’d venture to say that Scala is the lazy programmer’s Java in many ways. Much of the syntax is aimed at getting rid of all the repetitive, boiler-plate code that you had to write over and over and copy and paste (and violate the DRY principle). You can also do operator overloading, which isn’t immediately useful in many circumstances but looks interesting to us particularly for reasons I’ll discuss in a future post. Finally, the set of characters you can’t use when naming functions is pretty small, at least compared to Java. Your function names can have “!”, “?”, “+” and pretty much anything you like. Again, this isn’t immediately useful, but can be made more useful through the use of coding standards (e.g., functions that return boolean values can always end in a question mark ala “isServerLive?()”). Like in Perl, with Scala, there’s more than one way to do anything. But the fact that I just drew parallels between Perl and Scala may scare you (it certainly scared me). Scala code has the potential to be incredibly readable and incredibly writable if good coding practices are used, but just like Perl, the majority of code will likely be crap without it. You skip over a whole class of Perl-based problems with Scala since there’s no dynamic typing (all typing is statically inferred), which could possibly save the language. But the obscene number of choices still makes me suspicious. Consider: Statements can be delimited by a newline or a semi-colon (and you don’t have to be consistent about it throughout your code). Any operator can be overloaded. Functions can have almost any character in their names. Functions with no parameters can be called without the parentheses. Functions can becurried. Functions can be called in the same million ways that Perl did plus more, the key example being the following: Suppose I write 3 + 2. This is syntactically the same as writing 3.+(2), namely calling the Integer’s plus function and passing it in the value two. There’s a little bit of weirdness going on in this specific example since it sees “3.” as “3.0″ and thus as a Double instead of an Int, but in cases where there’s actual variable names this works in the previously described manner. Not the longest example, but you can extrapolate and see all the possibly crazy combinations of code that can pop up. And if you don’t believe me, go ask an experienced Perl developer how many orders of magnitude separate the best Perl code from the worst. So there’s a bit of possible danger in Scala-land. But I’m still pretty excited about it. Being able to store functions in arrays and pass them and their arguments around is pretty cool (and much faster for me to write coming from Java and C). The thing that sold me on Scala is the following code snippet, which took me about an hour to write. I was reading a paper on the Chapel programming language and their “cobegin” blocks that would automatically run the inside of the block in parallel (FYI “cobegin” was not invented by Chapel) and wanted to see if I could whip it up in Scala. The fact that I could in such a small amount of time is why I’m so excited about Scala. Granted, this version only does “println” in parallel, but presumably could be extended without mountains of work involved. object Kata { cobegin(stuff) def cobegin(parallelStatements: Array[String => Unit]) { def spawn(p: => Unit) { Of course if you don’t know Scala you’re not expected to know what this does and why it works, but this gives a good example of the syntax you’ll see in it and what it’s like. If you haven’t learned a new programming language in a while (let’s say a year) go learn Scala! The tutorial is amazing and it’ll keep you busy until C++0x comes out (which I’m certainly looking forward to) or whatever type of language you’re into shows up.
def main(args: Array[String]) {
var stuff = new Array[String => Unit](10)
for (i <- 0 to stuff.length – 1) {
stuff(i) = (j:String) => println(j)
}
}
for (i <- 0 to parallelStatements.length – 1) {
spawn { parallelStatements(i)(i.toString) }
}
}
val t = new Thread() { override def run() = p }
t.start()
}
}
