Pigeon Holdings

On the line: 020809

• Got a copy of Masterminds of Programming, which has a silly title, but which includes pretty thorough, and very interesting, interviews with a number of designers of well-known programming languages, including: C++, Objective-C, ML, Haskell, Java, C#, BASIC, Awk, Perl, Eiffel and others. I find it fascinating how different these people are and how varied their views about programming and computer science are. Gives me hope, somehow, to see that there is a lot of healthy diversity in the field of language design, and lots of room for different views and approaches. Worth a read.
• Also picked up Beautiful Architecture, which has essays from developers of various largish computer systems, including Facebook, Project Darkstar, JPC, Jikes JVM, Eiffel, Xen, KDE, and GNU Emacs, among others. Not much to say yet, as I’m just digging in.
• The DaVinci Machine project continues to plug along, and Attila Szegedi posted to the JVM Languages Group that he’s made a build of the latest DaVinci JVM available for download, if you’re using OS X. This is a nice, helpful, contribution and hopefully will make life easier for people who just want to try it out without fussing with Mercurial changesets and an (occasionally) complex build setup. Attila, by the way, is one of the maintainers of the Rhino JavaScript engine for the JVM, as well as a proponent of an interoperability mechanism among JVM languages (the so-called meta-object protocol, or MOP).
• For some reason, there’s some work on Groovy working well with Clojure–see this post by Andres Almiray on invoking a Clojure script from Groovy. Very clean, kudos.
• Charles Nutter got JRuby working on Android again, whereas another guy is working on a dialect of BASIC for Android, called Simple (which is open-source). Interesting to see where this will go–I assume we’ll see more and more languages targeted at Android over time, and wonder how that will affect the experience for app developers.
• JetBrains has released version 1.0 of the Meta Programming System (MPS), which, for me at least, failed the tutorial test–even building a small language to calculate values was a grind through one after another of abstract, foreign concepts. The bulk of it appears to be open-source. I think the most interesting idea is that we (somehow) get away from restricting our language designs based on the limits of our ability to parse symbols from text files, and use a language modeling tool instead, which builds editors for us.

One of my favorite interviews from Masterminds of Programming was the one with Tom Love, who co-developed Objective-C with Brad Cox. Tom is funny and insightful, though, oddly enough for a book about programming languages, he focuses less during the interview on language design itself and more about the problems of writing and maintaining large code bases, team and project management, and so on. Favorite quote from the interview:

“I’m currently working with a government client that has 11 million lines of code, some of which is 25 years old, for which there are no test cases. There’s no system-level documentation. They even stripped out the comments in the code as an efficiency measure a few years ago, and it’s not under configuration control, and they issue about 50 patches per month for the system and have been doing so since 1996. That’s a problem.” Tom Love, Masterminds of Programming

Posted in Uncategorized | No Comments »

On the line: 240709

• Reading Programming Clojure, great introduction to the Clojure programming language.
• Nice example of using Clojure to sweep a set of IP addresses to see who’s running SSH
• Write your Maven POM using YAML via the impressive Yamlpom plugin. Includes converter from POM XML to YAML, worked right out of the box.
  
• Best Indian food in Berlin so far, by far, hands down: India Palace. And: they deliver.
• You know a technology has arrived when it has its own brand of humor.
• Got a question I posted read and discussed on the Java Posse podcast this week. This is some kind of accomplishment.

Posted in Uncategorized | No Comments »

On what Open Source is, and is not

(accidentally deleted this post; re-adding under the same date)

Just found this post on a discussion forum for an open source project called HandBrake. The author is one of the HandBrake developers, as far as I can tell. A must-read. To quote:

I am aware of no open source software either currently or previously available that catered to the needs, whims, or desires of end-users. That isn’t what it’s about. If you want the freedom to tell someone what you want and expect them to do it, that’s called commercial software, where you make your intentions known with your purchasing decisions and vote with your wallet. That is not open source.

At some point I’d like to write about my experience contributing to FOSS projects. It’s been interesting and educational to have had the experience on both sides of the equation, as user and as developer.

There’s another angle which the HandBrake forum author doesn’t touch on, which is use of open source software within a company. I’m currently working at a gig where open source libraries are used exclusively. There simply is no commercial software in sight for the main project we’re developing, though internally there are some groups that use Windows and there are licenses for those. What is interesting is to see how little interest the technical leadership has in actually contributing back to open source projects we rely on. It’s simply never discussed and the couple of times I suggested specific steps–for example, submitting a set of Maven build files we’d developed to compile a library we rely on–the response was lukewarm. I don’t know what the solution is, but it certainly seems odd that nowadays you can build a whole software product line without ever paying a dime or even contributing back to the process in any way.

Posted in Uncategorized | No Comments »

Avoiding the Next Big Language

I was just listening to a podcast introducing the F# language, and what struck me was that the two folks being interviewed–Chris Smith and Dustin Campbell–didn’t talk at any time about F# being the next big language for the CLR. Rather, they focused on what they thought the advantages were, and invited people to just try it out, in fact, to just continue using whatever language they were already using on the CLR, but to be open to using F# when it seemed called for. You can find the podcast here.

I contrast this with what I’ve been seeing in various discussion forums around the web–the ones for Java and JVM users seem to be the biggest culprits here–where selecting a programming language seems to be a winner-takes-all proposition. It seems to me that, at least from a marketing angle, it’s better to promote your own language (or the one you currently like) as an alternative, rather than the one which everyone should pick up–must pick up, in fact–after dropping whatever language they are currently using.

Competitions is useful in the market of ideas. Just yesterday, Jonas Bonér posted a great presentation on approaches to concurrent and parallel programming in the JVM. What’s clear from that talk is that in that area of investigation there is not only competition, but also room for experimentation. There’s even room for more than one implementation of a given idea, such as Actors. We saw this some years ago with dependency injection/inversion of control and O/R mapping, among others. And it’s clear that while there are winners (e.g. Spring for IOC and Hibernate for ORM) there is still room for other approaches even over the long term.

On the JVM we do see some people promoting a mix of languages to solve problems–for example, JRuby on Rails calling into Java libraries, or Groovy used as a build tool for regular Java applications instead of some XML-based build tool. But then, if we really believed that we could just mix-and-match, I doubt we’d be seeing the long, heated, rather anguished discussions about “which language to use”.

It seems to me on the one hand that for a certain class of organization it’s very important to have a single, mainstream language used for the bulk of programming tasks. I’ve worked at that sort of IT shop before, and I can see the value in that approach. They have a known quantity, their developers can move between projects more easily, it’s a straightforward proposition to find programmers skilled in a mainstream language, etc. That sort of environment also seems to favor a number of secondary aspects around language selection, including language and library stability, technical support, documentation, training and educational materials, and backwards compatibility during upgrades to the language and libraries.

I’ve also worked at shops on the other end of the language-selection spectrum which are willing to combine whatever set of tools got them to their end goal. They expect their programmers to be comfortable with a pile of programming tools, the same way we’d expect a carpenter to work with both power and hand tools. One gig that comes to mind relied on a combination of Perl, Lua, Java and C to get the job done, with a healthy amount of scripts written in Bash, Awk and Perl for admin tasks.  It wouldn’t have been a stretch for them to add, say, Python and Ruby to that mix. They were, as far as it goes, language agnostic, though I wouldn’t say they were picking up new languages just for the heck of it. It’s just that they saw the value in each individual language and had no policy enforcing the single-language principle.

One group of programmers is of the opinion that there we in the IT industry will in the future no longer settle on one or two “mainstream” languages for, say, business applications. Rather, we will gradually move towards a model where a number of languages are used in concert, with each one applied to solve part of the problem.That seems counter-intuitive to me, as I’m not sure what fundamentals in the industry have changed; we certainly have had a plethora of stable, useful languages available for the last 30 years, and yet it seems that just a small handful rise to the top of the list at any given time. What would drive a move towards real polyglot computing?

Another group seems to feel that just as was the case in previous generations, we will run into the lack of flexibility in the current mainstream choices, for example Java or C#, and will find another one (or one+) to take its place. That generational change may be driven by external demands which the current crop of languages simply cannot fully or easily address, for example, the rise of the manycore system.

What I believe–and the reason I’m writing this–is that it’s counter-productive to be talking about the Next Big Language. If there is a NBL, believe me, you’ll know it, either because you jump on that bandwagon early and make a bazillion bucks or because you ignore it and find your job prospects shrinking faster than your worth in the marketplace. If, for economic reasons you want to make sure to be an early adopter, well, in this industry you have a lot of ground to cover, and likely you’re no better as a fortune teller than anyone else. In other words: wait for it, it will come.

I think it’s more interesting to talk about what different programming languages–big or not–allow me to do that those in my current toolset don’t. This podcast on F#, I think, took the right approach in just encouraging curiosity and interest in a different way of doing things.

Posted in Uncategorized | No Comments »

What do you want from your special FX?

Posted in Uncategorized | No Comments »

Bite through the skin to get to the pulp

I just came across PulpCore, a open-source 2D rendering and animation framework for the Java plug-in. I found the demos really impressive, in part because the experience of launching them was so straightforward and non-intrusive. It made me think–wait for it–that I was launching something in Flash. But these are Java applets; it’s just that they’ve actually taken the time to subvert the normal launch process so that you’re not reminded that, first, this is written in Java, and second, this is going to take awhile. Go check out the demos, see if you don’t agree. Among others, there’s a fun, silly little game called Milpa, a cool compositing demo, and a nice demo with layered text, among many others.

Discovering PulpCore allowed me to re-discover two cool Java libraries, Phys2D and JBox2D. Both are ports of a “2d rigid body physics engine, written in C++ by Erin Catto” called Box2D. From what I could pick up on various forums and blogs, Phys2D is based on an older version of JBox2D; the API is apparently somewhat easier to use than JBox2D, but the latter has been working on improving performance over time, so that at this point, JBox2D is faster, but Phys2D somewhat easier to use. Whatever: they both demo well. I like that you can hit the space bar to cause boxes and beach balls to go rocketing into whatever pile of bricks are shifting around on-screen. Rigid-body physics doesn’t have to be boring.

Back to PulpCore. I think PulpCore has that first-day-of-spring feel to it. I don’t mean that it’s new, or that you can’t see the same types of graphics effect using a dozen different languages these days, but rather the author’s own enthusiasm for the thing comes through in the demos. The demos just seem cool to me. Nice choice of colors. Clean layout. Each demo has a clear focus. Sharp edges. Good user experience.

I get this same kind of feeling quite often with Processing demos. It’s somehow refreshing to me that people are writing these little apps, making this dynamic, evocative artwork, just for the sheer joy of it. They aren’t telling you they’ve found the next big thing, they’re showing you what something that makes them happy, that excites them, draws them in. Maybe they spent hours, days, weeks getting that demo to run well and look nice. All of that energy, focus, drive, and joy in creating this work comes across to the person viewing the end product, at least, that’s my experience of it. Check out the videos posted by flight404 on vimeo.com to see more of what I’m talking about.

I used to get this same feeling about the demos posted about a language then called F3. The language is now becoming a product–on the eve of it’s first full release–but in the meantime, the life has been sucked out of it; marketing is in full swing and we’re being told, again and again, how this will be (one of the) next big thing(s). But I miss that old feeling, that spark of life that I got from the first demos the developer of F3 used to post once a month or so. I don’t want to be told that I’m going to have the next big thing, I want to experience something–I mean, I don’t even want to experience something special, I’m not looking for that, but if you do your job right, that’s what happens–I pick up on your enthusiasm, the fun you had creating this thing. It’s the life that is on full display when someone discovers joy, excitement, something cool–and pours that into their artwork and it reflects back outwards towards you, the visitor. I hope that the technical work that’s taking place around F3–a full compiler, a new runtime, graphics libraries–will be thrown into the shoebox and they all end up as newer, better tools in the hands of people seeking joy. Me, I don’t need another stinking RIA app. I just wanna have a little fun.

Posted in Uncategorized | No Comments »

Visual Guice

I’ve been meaning/intending to try out Google Guice for awhile now; just saw they threw together a simple graph visualization for dependencies declared in Guice. Looks nice. I haven’t found a Spring visualization library yet that I like, and I don’t use one. I end up having to keep track of it in my head or by navigating through the config files. For some modules I’m working on, it’s kind of a hassle.

I don’t think visualization solves all problems, but back when I used to do more database design as part of project development, having a well laid-out ERD was a huge help in communication. If the database is well designed, part of which (in my mind) implies consistency, having an ERD at hand is like having a good street map when you’re toodling around town. ERDs save a lot of time finding your way around the database, planning and writing queries, and work as a focal point in discussions–I often found there was no problem in getting non-technical folk to pick up the model format and be able to make their points using the diagram. ERDs are actually pretty easy to keep in sync with the database, at least as far as entities, attributes, constraints and such are concerned. The biggest chunk of work was actually in laying the elements of the diagram out, always trying to keep the relationship lines from crossing each other. It was often worth a pat on the back if you found a layout that was neither too large (across many pages) nor too cramped, and which was easy to follow.

Which all reminds me of a great little tool written by Alex Moffat a few years ago for drawing UML sequence diagrams. The tool was called Sequence. I don’t think he’s been maintaining it, but other people have picked it up and incorporated it here and there; there’s a version that generates sequence diagrams from JavaDoc tags, for example. The best thing about Sequence was that Alex wrote a small DSL with which you could describe a sequence of operations very concisely. There is a parser for the DSL, though it exists purely to create the diagrams. I think Sequence is a great example of little tools that make your life a lot easier. Here’s one example of the syntax (taken from the help docs).

Comments.newComment {
  CommentFactory.newComment -> "the new comment" {
    Comment.<> {
      IDGen.nextID -> newId;
      Transaction.add(this);
      Comments.getSize -> size;
    }
  Comments.addToCache(the new comment);
  }
}

which leads to this

Posted in Uncategorized | No Comments »

Fruit flies in the JVM

Fresh winds are whipping through the JVM development community, and they aren’t–apart from JavaFX–coming from Sun. The hype around multiple (“more than 200!”) languages running on the JVM has led an acceptance that running something other than Java, and something other than a simple scripting language, on the JVM, is not only a distinct possibility but also a competitive advantage allowing developers to expand their toolkits and skillsets horizontally rather than orthogonally. What I mean is that new languages, or new implementations of existing languages, on the JVM allow developers with an investment in JVM stacks to try new things out without leaving that stack behind.

It’s odd, but now I’m getting the feeling there are new languages popping up for the JVM on a monthly basis; this is mistaken, since in reality, getting a language to a stable enough state to be published seems to a take many months or even several years of hard development work. Still, we are seeing much more than just JVM-based implementations of Python and Ruby, and we’re seeing it happen more quickly than I think anyone would have expected. And they are announced without much fanfare and without much corporate backing or marketing muscle behind them; that’s a change, and a welcome one.

I think there are several core developments to the landscape that are enabling this:

• It’s much easier to test against multiple OSs these days, what with dual/triple boot machines, live CDs, and virtualization; that means your language can be relevant on the 3-4 major OS platforms from day 1.
• The infrastructure to host code, source control, and to document what you’re doing is now very, very cheap. With a little elbow grease you can promote your new product with a spit and polish that a few years ago would have only been possible if you had money in the bank. This is a big plus for developers who want to see the samples, APIs, and run the 5-minute build-a-blog test.
• There’s more acceptance of new languages, and, I think, the arrival of production-ready implementations like JRuby and Groovy on the JVM offers hope that we have real alternatives in solving real problems, and that we no longer need to commit to one language and one stack in building out our applications.
• The widespread use of RSS/Atom-based promotion, blogs, and online video draws much more attention, at low or no cost, to the work you’re promoting, and it happens much more quickly than before.
• The consultants who used to make a killing on promoting Java are seeing their rates fall and need new markets to conquer. OK, that’s being mean, but these people are offering free promotion in very public forums–not just blogs but conference presentations and workshops.

What’s missing, I think, but not far off, is making IDE support for new languages a core component of a new language’s early code drop. The more people write language support plugins for the major JVM IDEs (Eclipse, NetBeans, IDEA), the more the IDE developers try to improve this support and build out their support libraries, and the more end-users see that these IDEs are no longer aimed merely at Java. I think that the IDE situation needs to improve some more; given the pace at which these plugins are being developed, it seems, from the outside, to remain a pretty time-consuming task to get full-featured language support in an IDE. Part of this depends on the complexity of the target language–for example, Scala has a reputation among those developing plugins for it to be pretty hairy, and in the time elapsed since Scala first started drawing more interest, we are still stuck with one complete plugin for Eclipse, and two plugins, for NetBeans and IDEA, that are not even in an alpha release yet. I do wonder if the task can’t be made easier, though. How, I’m not sure (I’ve never tried writing one), but if we can simplify the task and shorten the development cycle, we’ll enter into a really fertile period for language development, where releasing a language plugin, possibly for 3 IDEs at once, wil be considered commonplace rather than unusual.

Some “new” languages that just popped up on my radar are Mantra and JSqueak; there was also Talc and Fan a few months ago. Here’s a list of languages that I’m starting to keep an eye on–it’s a pretty limited list, given what’s actually out there. The links point to the home page for the project.

• Scala: “Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages. It is also fully interoperable with Java.” Scala needs no introduction, since it gained a lot of attention, especially in the last six months.
• Fan: no one-liner for this one (maybe that’s a good thing). One of its strengths is portability across the JVM and CLR. The authors introduced the Fan language to the JVM Languages mailing list a few months back, and recently got some airtime from Cedric Beust and Stephen Colbourne.
• Talc: “The language Talc is an interpreted scripting language for quick and easy programming. It is simple, straightforward, and aimed at aficionados of the C family, despite its Pascal-inspired declarations. Particularly notable features are static typing, mostly C-like syntax, and the all-important curly braces”. Check out the author’s (Elliott Hughes) blog; he recently posted an interesting comparison of Java bytecode generation libraries. I find Talc interesting in part because it’s aiming to be a language with a small “l”, aiming primarily at small scripting tasks.
• Mantra: “Mantra (Hindi for “magical incantation”) is a new dynamically-typed programming language that is syntactically similar to Java but with the flexibility and ease of programming of Ruby or Python. Mantra is not an interpreted language. Source code is translated to Java and so Mantra programs integrate trivially with plain Java code.” Mantra is the brainchild of Terence Paar, the author of the increasingly popular Antlr parser generator.
• CAL: “A lazily evaluated, strictly-typed language…with many similarities to Haskell”; see also their introduction on the JVM Languages mailing list
• JSqueak: “JSqueak is a Squeak interpreter written in Java.” Squeak is a Smalltalk dialect. Very cool–the demo available from the homepage runs a Squeak development environment in your browser as an applet.
• Clojure: “Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.”. There are some great screencasts introducing Clojure available as well.

A good place to hang out and hear from those writing languages for the JVM is the JVM Languages Google Group. If you haven’t been following it, check out the archives; many of the most active JVM languages developers have showed up there, and there are a number of threads describing the languages in some detail.

I would be remiss if I didn’t mention Sun’s role in promoting all this, and the success they’ve had doing so. Their hiring of two JRuby core developers, and their investment in supporting Ruby and JRuby in NetBeans, as well as GlassFish, have all seemed to pay off handsomely; JRuby seems to be a real contender to standard Ruby for rubynauts. We haven’t seen as much from the Jython developers (two of whom Sun also hired), at least in public announcements; but there’s reason for hope, as they seem to have Django running (to some degree), are closing in on Python 2.5 compatibility, and will have support for Python/Jython in NetBeans by the time NetBeans 6.5 is out later this year. Anyway, seems like a good strategic move by Sun.

I should probably mention JavaFX as well, but I think I’ll wait until the SDK comes out next month and we see how well it plays in the developer community. I’ve been following the compiler mailing list since it was established, as well as that of the new scenegraph API on which the language relies, but it’s really too early to say how it will play in Peoria. The early enthusiasts are, well, enthusiastic, but outside of some pretty simple demos on the web we don’t really have anything to see at this point, much less anything useful. But they have some smart people working on it, there are some cool ideas in the language, Chris Oliver has written some awesome demos, and in general, I’m hopeful.

I’m looking forward to more surprises.

Posted in Uncategorized | No Comments »

Maxine-ize your investment

I thought it was worth mentioning that another stealth research project at Sun has been open-sourced (GPL v2.0), in this case, a new virtual machine written in Java called Maxine. There are presentation slides available from JavaOne 2008. Maxine came out of nowhere as far as I’m concerned; I’m glad that Sun is still investing in this kind of research, and that they’re making it available as free software.

The Maxine project owners note a set of limitations, but I think the idea itself is interesting regardless of current limitations, although they note it’s not a new idea to write a JVM in Java itself. What may be new is that they are taking advantage of Java 5 features including generics, annotations, etc. which they believe gives them a leg up.

What I’m wondering is if this will, or could, ever be a useful replacement for HotSpot. I’d be surprised, but OTOH my sense in following the HotSpot mailing lists, as well as blog postings about it, is that HotSpot is a pretty damn complex piece of software. Certainly the advantages of writing in a higher-level language than C++ seem to make it worth the effort–or at least, an area worthy of investigation.

If you’re interested in these sorts of things, it’s worth keeping an eye on the Da Vinci Machine project, which aims to explore enhancements to the JVM to make it a better/more comfortable target for languages other than Java. I also recommend Cliff Click’s blog; Cliff used to work at Sun on the HotSpot server compiler. He is following interesting research on JVM implementation techniques and provides a useful map and commentary on what he finds.

Posted in Uncategorized | No Comments »

Tools in use

I decided to stop using a Java-based IRC client, jIRC for one written specifically for OS X (I’ve been using OS X at home and Linux for work)–the Mac utility, Colloquoy, is just excellent in all ways. And what I realized is that for some tools like this, the issue isn’t Java versus another language, or SWT vs Swing, but rather that Java has to offer a compelling platform to target so that good, experienced application developers target it for their apps. There are tons of junk applications written in C or C++ that are just as ugly, slow and annoying to use as the worst Java GUI app you’ve ever used. It’s just that overall enough of the right people are attracted to the non-Java platforms that we end up with a good selection of good apps to use.

I still use jEdit regularly, although not full-time anymore; it used to be my editor of choice. If you’re a programmer, I think jEdit proves the cross-platform goals of Java really pay off. I also use Cyberduck, an FTP client for the Mac, which is also written in Java. Really great tool. The best thing is, they don’t mention Java once on their home page. I’m pretty sure they only have a UI for the Mac, which is fine by me in this case. What I like is that they are using Java to get the job done, and it helps them get the job done.

Point being: I try to choose great tools. Some of them are written in Java. End of story.

Posted in Uncategorized | No Comments »