God, I Hate Classpaths

I have to wire up a ColdFusion to an Axis Web Service. I’ve spent the past 3 hours trying to figure out freaking classpath issues: something about a ClassCastException from a org.apache.commons.logging.LogFactory. I’m giving up for the day. Stupid freaking classpaths.

Pete Wright Ends Relationship With MS to Embrace Ruby on Rails

Pete Wright, whose TabletPC Sudoku program was “shot in the head” by Microsoft’s surprise release of their own version (join the group, Pete!), has ended his long relationship with MS consulting in order to fully embrace a job working with Ruby on Rails. His post is obviously cathartic, but he echoes the not-uncommon sentiment that within the Ruby community one is more likely to encounter passionate, involved people.

This is only true because Ruby is still at the “enthusiasts” place in the adoption curve. Once upon a time, the passionate people were embracing Java and VB: the languages that Pete now associates with drones. If Ruby crosses the chasm, it, too, will eventually become the domain of boring people.

Sun Hires JRuby Developers: How Much To Read Into This?

Sun has hired Charles Oliver Nutter and Thomas Enebo, the two core JRuby developers with the charge of bringing JRuby to fruition.

I’ve held for a while now that the crucial step for Ruby to cross the chasm and become an “early majority” language was hosting / 100% transparent interop with one or both of the CLR and the JVM.

A word of caution: Jim Hugunin was hired by Microsoft two years ago and only now is IronPython a 1.0 release. Probably Nutter and Enebo will face some of the same issues within Sun that Hugunin has faced within Microsoft: in addition to working on the parser and code generation and so forth, there’ll be (undoubtedly engrossing) involvement at the platform level, interaction with the tool team(s), etc. My guess is that the tool-support complexities will be a little less complex (Visual Studio being so central to any Microsoft development system) and the platform complexities a little harder (evolving the Java platform being more democratic / bureaucratic).

A second word of caution: the single-core era stopped short of eliminating the problems with “everything is an object.” Today, we know about how fast a single processor will run. There will be incremental improvements, but the speed of a single thread of processing in 2016 is probably not going to be even twice as fast as a single thread of processing today. And this topping out of the Moore’s Law “free lunch” conflicts with the premise that all types should be abstracted into objects. The million-fold penalty of accessing main memory versus accessing a register or an in-cache value is enough to introduce human-noticeable lag when applied to arrays of just several thousand values. Of course that does not disqualify languages with heap-based numerical values from the large majority of programming tasks. But neither is it true that we can simply put aside the question because calculations are “fast enough.”

There’s still definitely a performance question relating to not just the performance of numerical values but the implementation of some advanced operations (continuations) within the managed platform’s virtual machines. Meanwhile, of course, the physical machines are moving towards the multicore and manycore eras, which will rewrite all the rules on performance.

Oh! Oh! And Ruby still needs the freaking Smalltalk browser and persistent workspace!

Ruby Read

According to Tim O’Reilly’s always interesting quarterly analysis of the book industry, Ruby is doing extraordinarily well, with a 689% quarterly increase in sales and is now approaching Perl in terms of book sales.

Caveats include the (some would say profound) difference between book sales and use. Most Perl programmers already have accumulated books on the topic. Similarly, C# showed a spike in book sales, but that is almost certainly largely a reflection on the release of VS2005 and not an indicator of a sudden shift towards that language.

Having said that, an important component of programming language popularity is “buzz” and the perception created by a sudden increase in books/seminars/articles. With sites like Digg creating “flash-interest,” and increasing the volatility of the marketplace for attention, “buzz” may play an even bigger role in whatever The Next Big Language is than it did in the success of C++ and Java (two languages whose success was undoubtedly boosted by the amount of associated teaching / discussion).

When Your Nutshell Gets to 1300 Pages…

“Java in a Nutshell” weighs in at 1264 pages. Matt Croyden, sez:

[Y]our programming language just might be complicated when you have trouble telling the difference between its Nutshell book and a telephone book.

[via James Robertson]

This is somewhat unfair, as the bulk of “JiaN” is a library reference, but it’s certainly true that Java and C# have grown more complex as they’ve evolved, while certain other languages (Lisp, Smalltalk) have seen continuing simplicity as a feature of the language.

I think that one force in play in the market for programming language popularity is pressure towards a “collapse toward simplicity.” It’s not the only force, in my opinion it’s not likely to be the major force, but it certainly played a part in the rise of Java. Of course, Java was equally an example of the force towards familiarity: it seemed quite like C++. Similarly, I think one reason why Ruby is currently the belle of the ball is its similarity to Perl.

Can’t We All Just Interoperate, Part 2

Success! I can access Tablet SDK functionality from Java. Rather than use COM, my original tactic, I did what I joked about: used C++/CLI so that the call is Java->Unmanaged C++->C (Win32)->Managed C++! Pretty funny, but not all that hard to follow in the source code. I have to say, I’m going to guess I’m the first person to write code to convert a jstring into a char* and pass that into a gcnew System::String!

Look for an article on DevX by the end of the month.

Can’t We All Just Interoperate?

So I’m trying to write a program to manipulate the Tablet PC Input Panel from within a Java application. So I have to use JNI to interop with a native .DLL written in C++. My DLL uses Win32 to find the handles to the Java application edit windows and then uses COM to manipulate the TIP. I dunno’: I feel like throwing some gcroot<String ^>s in there, just to cover all bases.

Teachability Important to Programming Language Success

Eric Gunnerson, discussing “Why so many languages?” makes the key point that “Compactness and simplicity have big benefits as well in programming languages.”

Once upon a time, I made a good living teaching Java. Sometimes I taught it to C and C++ developers, sometimes I taught it to COBOL developers. One way or the other, in a week you could really deliver value: if people understood imperative structured code, you could really move them towards an understanding of object-oriented programming in just a week. Same for C# 1.0.

Even so, you had to talk about “well, not everything’s an object,” and deal with function-call semantics and equivalence and so forth. Personally, I think that the inclusion of native types was a critically beneficial language-design decision for Java, but it does complicate teaching. In .NET, it’s even harder to teach, because you can’t say that value types are limited exceptions.

About a year ago, I had a friendly debate with my colleague Allen Holub about the changes in the then-new C# 2.0 and Java 5 languages. One disagreement we have is that Allen doesn’t like generics, I do. I tend to like explicit typing, my feeling is that 99% percent of the time you have a type intent that you can memorialize with a few finger strokes and gain Intellisense and better comprehension. But Allen cleverly didn’t argue the finger-typing issue, he said that what he disagrees with is that generics are not OO, thereby making the language harder to learn.

He’s right. Once upon a time, C was relatively easy to learn; learning how pointers work was the big issue. Now, I can’t imagine someone “picking up” C++ and not being absurdly non-productive. Never mind the STL, how many freaking ways are there just to represent a string? John Montgomery recently posted the surprising factoid that the most commonly used languages by non-professional programmers are HTML, JavaScript, and C++, more than VB or Java or Perl. One wonders what perception these people gain of the task of professional programming.

This is why, when thinking about trends in language syntax, I think there’s a possibility, although not necessarily a likelihood, of a collapse towards simplicity and the widespread embrace of a LISP-like or Smalltalk-like language.

Table Input in Java

Tablet Input in Java

Wednesday, June 07, 2006

10:06 AM

Turns out that, contrary to what I’d feared, the Tablet Input Panel for the Tablet PC does recognizes SWT components as text labels, and you can use the TIP to add recognized handwriting to a Java/SWT application:

So now, the challenge of programming forms in Java for the Tablet PC reduces to the problem of setting the TIP context dynamically from Java so that you can command it to bias the handwriting towards the expected entry type (a date or a phone number or what-have-you). The difficulty with that is that as far as the TIP is concerned, all java.exe executables look alike. So I’ll have to figure out some way, within Java, to register for a callback when the TIP gets activated. Then, use JNI to set the TIP context. Stay tuned?

Created with Microsoft Office OneNote 2007 (Beta)
One place for all your information

Download: Table Input in Java.one