It’s said that the fox knows many tricks, but the hedgehog knows one big trick. If Java is the hedgehog, with objects as its one big trick, then OCaml is the fox, with lots of different tools for structuring code. Many of the things you’d use objects for in Java have simpler, cleaner, or safer alternatives in OCaml: tuples and records for structuring data, higher order functions in place of one-method anonymous inner classes, parametric polymorphism for collections instead of pervasive downcasts (although this has improved with the introduction of Java generics), functors and signatures in place of (compile-time) parameterization of code with interfaces.
Nonetheless, sometimes you want objects—as I did recently when interfacing with some object-oriented native code—and you can get them in OCaml too (objects are of course the O). But they aren’t quite the objects that you’re used to in Java. In Java, you can put two objects with a common superclass into a single List. I tried to do that in OCaml and got a mysterious type error. It took me some time, a little research, and a little profanity, but I got my code working and learned some things. (more…)
It’s pretty easy to get overly confident about the correctness of your code when you program in OCaml. After all, the strict type checking eliminates whole classes of bugs at compile time; you never fight them because your code never builds with them. Even so, I still love running automated tests. The compiler can’t catch all boundary conditions and it certainly can’t verify any situation that is dynamically built at runtime.
At Skydeck, we use OUnit for our unit tests. It’s really straightforward to use because, not surprisingly, it follows the typical n-unit pattern: set-up and tear-down test cases, implement individual tests, and gather them all into suites for execution. Similar to other implementations — cppunit for example — you need to write your own test suites with OUnit. It’s repetitive work, ripe for automation and almost makes you miss reflection (but not quite). So we threw together a module to automate this and hooked it into ocamlbuild. Now adding a new test is simple: we just write new test functions and OCaml does the rest. I love being able to add tests quickly even more than I love that feeling when all the tests pass.
Below is the code that generates the test suite. If you’re using ocamlbuild and want to integrate with it, I’ve included the relevant sections from our myocamlbuild.ml too. (more…)
We love OCaml at Skydeck, as Jake has written about before, and we often hear from programmers with questions and comments about it. Some love OCaml, some don’t know anything about it, but many have it on their list of languages to try yet haven’t gotten around to it. Well, it’s pretty simple to get up and running — just download, build, and start hacking!
Really, it’s that simple. If you want to get there as quickly as possible, follow these five steps:
What is a full-stack web framework, and what is it good for?
Back in the day (which day being 1995 or thereabouts) there was essentially one web framework. It was a Perl module, called CGI.pm, which decoded the CGI request and provided functions to construct HTML and a CGI response. (CGI.pm is still around, but the past tense adds to the mood of misty reminiscence.) It didn’t have a template system (but Perl “here documents” let you embed HTML directly in your script), or session management (you rolled your own—it’s not hard), or a persistence layer (you used the filesystem, or DBI.pm to talk to SQL databases), but it was simple, easy to use, and easy to understand.
Now, after more than a decade of progress, we have this gigantic Java stack trace of a system running various frameworks and libraries. Somehow I don’t think this monster of delegation is the “full stack” that people have in mind. This setup does not seem easy to use and understand. How did we get here? As usual, with the best of intentions. We’re programmers, so we invented abstractions.
In fanciful moments I like to think of a running program as a little spaceship following a trajectory through the computer’s “state space”–the space of possible values of each of its memory locations. This is a big space (2 to the power of the number of bits of memory in the machine) so easy to get lost in. The problem of writing a correct program is how to keep the spaceship on course.
If the ship is on course it’s easy to move it in the right direction. If it’s gotten off course, we have to figure out where it is and make some correction to get it back on course. If we don’t realize it’s gotten off course we’ll move it in what we think is the right direction, and probably make things worse. If we get too far off course we might not be able to recover at all. We’re better off staying on course in the first place.
Last week was abuzz with discussion of RIA. I credit Hinkmond Wong’s post about porting F3 to Java ME with starting it, but most would point to Silverlight. Discussion predominantly revolved around desktop browsers and web downloads, although this video demonstrating Silverlight for Windows Mobile looks great. But really, either or both can be extremely significant in mobile. I hope it’s as more than just another RIA platform though. Rather than restrict them to a constrained environment, I’d like to be able to embed them in downloaded applications that can extend the functionality of each in order to take advantage of features native to the phone.
Stepping back briefly, Silverlight is Microsoft’s cross-browser plugin for delivering .NET Web applications. F3 is a Java scripting language created with the goal to make GUI programming easier, with nice features over something like JavaScript: static typing, type inference, and the ability to import and call any Java class.
The competition for RIA in mobile will be stiff. However, the ability to embed and extend these technologies in applications is largely untapped, even though it could provide a unique solution to a fundamental problem in mobile development: when you can’t easily update your installed code, it’s hard to provide dynamic functionality and features. The Orbit project will embed OpenLazlo into Java ME, but it’s not clear that applications will be able to extend its functionality. Silverlight and F3 are each equally poised to provide this if they:
Allow the installed application and embedded code to interact.
Allow the runtime to be extended (e.g. platform invoke or JNI).
Provide a user-controlled security policy as opposed to requiring a complicated signing process, or worse, a more restrictive sandbox.
Both companies have unique advantages supporting their solution. Sun has the nearly ubiquitous distribution of Java ME on mobile handsets, however today that is in the form of MIDP/CLDC, whereas F3 (and Orbit) require CDC. Microsoft owns a mobile operating system which could allow for tighter integration, although Silverlight on the desktop is a subset of the .NET runtime (but so is the .NET compact framework).
We saw some of Microsoft’s cards last week, but not many in terms of mobile. With Sun, we’ve seen activity on F3, PhoneME Advanced, and the acquisition of SavaJe IP, so we can hope they are heading in this direction. To be sure, neither company solely dictate the functionality of phones, but with JavaOne this week, hopefully Sun will provide some leadership.
Jason’s post about the FCC’s “four freedoms” calls to mind the distinction between “open-source software” and “free software” (free as in speech) . While the term “open-source” focuses on what you get (the source), the words “free software” draw attention to your freedoms: to use, study, and modify the software without restriction. These freedoms are in the same spirit as the FCC’s freedoms, and are similarly contested in this era of walled gardens and locked-down platforms.
Free software may mean different things to you, depending on who you are. If you’re a hobbyist or run a small business you might like that it generally comes at no cost. Or you might be idealistic about intellectual property and feel (with Jefferson) that “he who lights his taper at mine, receives light without darkening me”. Maybe you see a business opportunity in supporting the ferment of activity around free software.
But if you’re a programmer, the importance of using free software instead of proprietary software is that it makes it much easier to do your job. Programming is reasoning about code, and the whole point of keeping software proprietary is to prevent you from reasoning about what goes on inside it.
Making software that works is really hard. I don’t say this because I’m a programmer and I want it to sound more impressive; I wish it were easier. But we programmers put endless hours into getting it right, and still your laptop blue-screens, your phone reboots, the rocket crashes into Mars.
The words we use to describe making software (in job ads, for instance: develop, design, write, architect, build, engineer) are glibly positive. They make it sound like a monotonic process, like laying bricks. But any programmer knows that working code comes in fits and starts. Most of the hours go not into designing or building, but into understanding: what a library call actually does, what’s happening in some code you’re trying to modify, why a bug doesn’t show up in the debugger. (This is why it’s hard to estimate how long a programming task will take; to estimate the task you have to understand it, but it’s the understanding that takes the time.)
Perhaps the best way to describe it is this: making software is reasoning about code. The methods of reasoning about code are the same as those of math or logic – considering all the cases that might arise, arguing by induction, breaking a larger argument into parts – although in programming we usually do it informally. In order to do a better job of programming (to program faster, with fewer bugs), we have to do a better job of reasoning about code.
In my next few posts I’ll talk about a few ways we’re trying to do that at Skydeck.
There are a number of runtime environments available or in the works for open phone platforms (e.g. Python, Perl, Ruby, Java). Instead of using one of these, we decided to port a runtime for a language you may not have heard of, called OCaml.
If you’re interested in writing code faster and with fewer bugs, you should give OCaml a look. Its advanced type system prevents whole classes of bugs in the same way that garbage collection does. We like it so much that we use it whenever we can.
At first we thought that “whenever we can” meant only on the server; we thought the time it would take to port OCaml to phone operating systems would be prohibitive. However, after a little investigation, we decided to port the bytecode runtime to the Nokia S60 platform. It is turning out to be easy. The runtime is a beautiful piece of code and very portable.
Doing our own port gives us the same degree of control as writing native code, while retaining the productivity advantages of a runtime environment. It also helps maintain portability across different platforms.
We expect OCaml to make a big difference in our ability to get working software out the door. Programming everything in C++ seems insane by comparison.
Mark Lam wrote a great post Monday about reasons to choose Java for embedded systems development. He starts with an anecdote about wanting to abstract away the complex security issues involved with native programming by creating a scripting language.
However, in order for the content to be interesting, the scripting language needed to provide more and more functionality like that of a full programming language. After numerous enhancements to the script engine, eventually I realized that I am re-inventing a solution just like the Java programming language.
This path has been — and likely will continue to be — followed by many companies building mobile products in order to isolate security risks and provide custom adapters for platform differences across a broad range of handsets. But it’s a lot of work to build a runtime environment from scratch, so Mark is hoping to persuade his readers to choose Java before investing in that work. Because he is addressing an audience of embedded system developers, some of Mark’s points and his ultimate conclusion do not necessarily apply to mobile ISVs. However, his underlying argument is sound: using a runtime environment provides many advantages, and rolling your own will come up lacking.
Just in case you’re not convinced that you should seriously consider using a runtime environment for mobile development, the Symbian Developer Network is publishing a series about it. The first two present a business case (pdf) and describe the concept (pdf).
Today, if the handset runs an OS with a closed development environment, then the only managed environments available are JavaME and in some cases, Flash Lite. But a lot of interesting possibilities exist for handsets that have an open development environment, such as Symbian (S60/UIQ), Windows Mobile, Linux. Coming up, we’ll talk about some of the possibilities we considered and what we wound up using.
