chanson

Has anyone been working on using LLVM to do just-in-time code generation for the Erlang virtual machine?

Depending on the design and structure of the Erlang virtual machine, it doesn't seem like it would be all that tough a project. And it could provide a nice performance boost for those projects that are starting to use Erlang like CouchDB and ejabberd.

For an example of what I'm talking about, there's a project called VMKit that has implemented the Java and .NET virtual machines atop LLVM with reasonable performance. Essentially, if you have a virtual machine, rather than skipping either just-in-time or static code generation entirely, or trying to do it all yourself for some specific platform on which you want to run, take a look at what you can do with LLVM and see if you can leverage its code generation instead.

As seen on the LLVMdev mailing list: Jon Harrop, Fibonacci example in OCaml:

Here is a complete 104-line native code compiler for a tiny subset of OCaml that is expressive enough to compile an external Fibonacci program: [...]

The compiler is itself written in OCaml, of course; for those who don't know, OCaml or Objective Caml is an object-oriented dialect of Standard ML, a purely functional language.

Jon's name rang a bell because I just listened to the second of two podcasts from .NET Rocks on the F# functional programming language — Jon Harrop Makes Us F# and F# Moves Forward — that Microsoft will be including with future versions of VIsual Studio. F# is itself a derivative of OCaml, runs atop the .NET Common Language Runtime, and can interoperate with other code

F# is interesting because, due to its functional and side-effect-free nature, one can get a huge amount of parallelism out of straightforward code. (It's the lack of side effects that allow such analysis to be performed.) The Xbox Live matching service, for example, is using a TrueSkill engine developed in F# by Microsoft Research.

OCaml on LLVM is interesting in a lot of the same ways: You have a functional language that's very amenable to all sorts of analysis and optimization, and an abstract platform that can run on an extremely wide variety of systems very efficiently. It's really the best of both worlds, where you will be able to write the parts of your software that need to be highly parallel and mathematically rigorous in a language amenable to it, and interface that to the rest of your application in a very natural fashion.

It's great to see that Jon is enjoying exploring OCaml atop LLVM and I can't wait to see what kind of fun results!

The next CocoaHeads Silicon Valley meeting will be on Thursday, April 12, 2007 from 7:30-9PM in the Hong Kong conference room at Apple. That's just inside the entrance to Infinite Loop 1, the main headquarters building at Apple's campus in Cupertino.

See the web site for details, directions, and the organizer's contact information.

R. Tyler Ballance will be talking about C#, Microsoft .NET 3.0 and Visual Studio.NET 2005 as someone who has used both platforms extensively. But don't worry, he's not pitching us on becoming a Microsoft developer! He'll be comparing and contrasting it with Objective-C, Cocoa, Xcode and Interface Builder — even covering some of what's coming in Leopard — and he may even cover what the Open Source community has to offer with Mono.

As always, we'll also be hanging out and talking about Cocoa in general, discussing new and cool things that have come up in the past month, and helping each other out. Join us!

Robert C. "Uncle Bob" Martin of ObjectMentor bought a new MacBook Pro and appears to be very pleased with it. Uncle Bob is quite well-known in the object-oriented design and agile development & Extreme Programming communities, and it's great to see him join the Macintosh world.

I saw him speak at a C-SPIN meeting a few years back — Testing is about Specification, not Verification (March 2003) — and it was painful watching him fight his Windows laptop while setting up. I suspect between his new MacBook Pro and Keynote he'll be much, much happier. I suspect he'll also find Xcode, Cocoa, and Objective-C very interesting too, especially coming from Java and Microsoft .NET.

This guy must be kidding. Introduction to Model/View/ViewModel pattern for building WPF apps (John Gossman):

Model/View/ViewModel is thus a refinement of MVC that evolves it from its Smalltalk origins where the entire application was built using one environment and language, into the very familiar modern environment of Web and now Avalon development.

Yeah, because Model-View-Controller is just so inadequate when you're using visual human interface construction tools to create desktop applications or web applications.

I mean, it's not like anyone else has had an "interface builder" as an integral part of their platform. Or tools for creating web applications out of reusable and composable "web objects."

Chris Brumme, Apartments and Pumping in the CLR [cbrumm's WebLog]:

The MTA [Multiple-Threaded Apartment] is effectively a free-threaded model.  (It’s not quite a free-threaded model, because STA [Single-Threaded Apartment] threads aren’t strictly allowed to call on MTA objects directly).  From an efficiency point of view, it is the best threading model.  Also, it imposes the least semantics on the application, which is also desirable.  The main drawback with the MTA is that humans can’t reliably write free-threaded code.

Well, a few developers can write this kind of code if you pay them lots of money and you don’t ask them to write very much.  And if you code review it very carefully.  And you test it with thousands of machine hours, under very stressful conditions, on high-end MP machines like 8-ways and up.  And you’re still prepared to chase down a few embarrassing race conditions once you’ve shipped your product.

Uh, what?

Look. I'm generally the first to point out — quite vocally at times — that 90% of software developers are crap. That's just Sturgeon's Law, exacerbated by a management culture that continues to treat software development like a manufacturing rather than R&D activity.

But writing threaded code isn't bloody rocket science. You just have to follow a few simple rules, like "Use a synchronization mechanism to manage access to shared data structures," and "Don't assume an API is thread-safe unless it's documented as such," and learn a couple simple synchronization primitives. Are so many developers so terrible that it's more worthwhile to develop APIs that hide threads from them than to keep a clean and general framework and expect them to be able to figure it out?

Then again, the exceptionally poor quality of most developers is a good jutsification for my high consulting rate.

On Friday, Rob Relyea on Microsoft's Avalon team described some major design flaws in the "new" XAML technology used by Microsoft in Longhorn.

First, Rob describes how the Avalon team feels that parsing XAML to instantiate your human interface will have performance problems, and that's why they're pushing "XAML compilation." Now, maybe they did try it and measure it and determine that this would be the case, and that some form of pre-parsed binary XAML is the best option for Longhorn application developers. But the sense I get from his post is that it's based on conventional wisdom ("parsing XML is slow") and not measurement.

However, they're not simply promoting compilation into a pre-parsed binary version (BAML), though that is available. No, they're promoting compilation into source code instead. Yes, in 2003 Microsoft developers are still promoting source code generation as the best way to develop your application's human interface despite the fact that other platforms were doing this in a superior, entirely data-driven fashion more than a decade previous.

The second major design flaw is related to the first. It turns out that when you generate code from a XAML file, you don't simply get some set-up code, it generates a new class!

Have the people responsible for this not been paying attention to the last twenty-five years of practice in object-oriented programming? Why the hell do you want a new class generated for every single window (or "form" in Windows newspeak) you create? Model-View-Controller exists for a reason, and a good one at that! But it wasn't invented at Microsoft, and it's not typical Visual Basic developer practice, so it must not matter all that much.

Fortunately, they seem to be starting to understand. According to Rob, they're planning on getting rid of the option that allows you to solely generate code from a XAML file; insetad, they're going to promote a combination of BAML and code generation that loads the BAML. This is definitely a step in the right direction, at least in addressing the first flaw.

But the people working on XAML need to get some significant experience with other frameworks before designing a new one. Then maybe they'll see that you shouldn't have to subclass the world just to create applications.

Stan Lippman, famous C++ author, is working on Visual C++ now at Microsoft. You'd think this would mean better standards conformance, better cross-platform support, and so on.

Wrong.

Reading his weblog about "Managed C++" it's obvious that Microsoft wants to lock C++ in their trunk too. They're adding all sorts of extensions, new keywords, new syntax, all to better "integrate" C++ into .NET. And incidentally make any code you write using their extensions horribly non-portable.

Now, I've worked on ports of games to the Mac. Sometimes they're a bit difficult because their original developers abuse semi-standard language features. Many times they're a lot more difficult than they should be because developers use non-standard language misfeatures like anonymous unions. This is going to make the problem much, much worse.

What really gets me is that the majority of Windows C++ developers don't even seem to know the difference between Microsoft's tools, frameworks, and language extensions and what's actually supported within the standard language.

OK, there's another thing that gets me about some of what Lippman talks about. For instance, Managed C++ is getting "properties." This is an attempt to create something vaguely similar to (but more limited than) Key-Value Coding. Microsoft could have instead decided to keep more class metadata around at runtime; this would enable them to both avoid cluttering up the language with extra keywords and syntax and get even greater flexibility in a way that could be supported easily by other vendors and eventually rolled into the standard language.

Oh, wait, they're not going to do that. That would mean doing something that could possibly benefit someone other than Microsoft.

Windows has long had support for a "Recent Documents" listing in its Start menu. Functionally this menu behaves the same as the Recent Documents folder in the Apple menu in both the traditional Mac OS and in Mac OS X.

On the Mac, management of this list is handled entirely by the operating system. The Finder and the standard Open and Save dialogs work together to ensure the list is always up to date.

On Windows, however, you have to do the work yourself. In the second part of his series on implementing document-based applications in C# with Windows Forms, Chris Sells describes how to do this:

In addition to seeing their files in the Explorer, users are accustomed to seeing their most recently accessed documents in the Start->Documents menu. If you want those files to be added to that list, you'll have to call the Win32 function SHAddToRecentDocs, exposed from shell32.dll. Unfortunately, there's no .NET wrapper for that function, so you'll have to use a bit of Win32 interop to gain access to it:

And then he shows us the code.

In the article, Sells also describes how to manipulate the Windows registry to ensure that your application will be bound to its document type, and to associate an icon with both documents and the application. Predictably, you have to do this in code. Yes, core Windows functionality like managing the recent documents list is not only left for every application developer to implement, the mechanism used to implement it isn't even natively supported by .NET.

Sells also goes on an irrelevant tangent about how easy it is to build an MDI application when you have a working SDI application. MDI is the abominable "many document windows inside a maximized parent application window so you can't work in more than one application at once" interface Microsoft has been trying to get developers to stop using for the past eight or nine years; it stands for "Multi-Document Interface." SDI stands for "Single-Document Interface" and presents a much more natural interface to users, where there's no giant "parent window" preventing them from working with multiple applications at once.

Predictably, creating an MDI application also involves writing a bunch of code. At least its interface is defined using the form designer, and not by writing even more code. But why would you even want to foist an MDI application on your users when it's easier to build a better SDI application?

Let me get this straight: This is the state of the art in Windows application development? And people think it's cost-effective to build enterprise applications using these tools? On Mac OS X using either Cocoa or Carbon the operating system manages recent items for you. It's trivial to associate a file extension with your application: You just declare it in your application's property list, and the operating system notices. It's trivial to associate an icon with your application, and with any of its documents: You just declare them in your application's property lists, and the operating system notices. And there's no MDI garbage to get in users' way as they work on ever-more-complex tasks using multiple tools at once.

With Cocoa on Mac OS X, you can accomplish more using less code. This is especially true with Panther and the introduction of NSController, but all of what I talk about above was our reality in early 1999 with Mac OS X Server 1.0.

Scoble pointed to a great piece in .NET Developer's Journal: Not Performing Due Diligence Has Companies and .NET Paying the Price.

I'm sad to say that the same thing is happening in the Cocoa world. There are vendors out there promoting themselves as Cocoa developers that have no in-house Cocoa experience. There are also vendors out there claiming that nobody has more than a certain amount of Cocoa experience. Then when these people's clients don't get the benefits they expect from Cocoa, they wind up blaming Cocoa. This poisons the well for everyone.

There are people out there who have experience with Cocoa from before Mac OS X 10.0 was released in March 2001, and even before Mac OS X Server 1.0 was released in early 1999. It was once called OpenStep, and it's the second generation of a framework that originally shipped on NEXTSTEP in 1988. Good developers with OpenStep and NEXTSTEP experience are expensive; you will not find them at bargain-basement rates. On the other hand, they're worth it because they'll get things done far faster than a team learning on your dime at a bargain-basement rate.

That was the impetus for starting my Outsourcing Vendor Evaluation service. But I'm not limiting myself to the Mac or Cocoa or WebObjects worlds; what it all comes down to is the ability to detect bullshit. And that I can do whether you're talking about Cocoa, Carbon, WebObjects, .NET, ASP, Java J2EE...

On Windows, many developers seem to want to run as fast as possible away from Microsoft Visual C++ and embrace Microsoft's C# and .NET platform for new development. Most Windows developers that I've seen seem downright enthusiastic about these technologies. It's disconcerting; I'm not used to seeing Windows developers (or users) be enthusiastic about their platform.

On the Mac, many developers are trying to hold onto C++ and Carbon for as long as they can, even for new development. A new Mac developer on the Carbon list actually said he wished Apple had a C++ framework that used MFC-like "message maps" for Mac OS X-only Carbon development "to make it easier to build software fast!" (Paraphrased.) And Metrowerks is spending money & time building a next-generation C++ PowerPlant framework for Mac OS X-only Carbon development! And some developers keep on Apple's case to try and maintain feature parity between Carbon and Cocoa.

Fortunately, Apple isn't giving in to them as much as they might think. For instance, WebKit has a Carbon wrapper, but it's just a wrapper; WebView is really a Cocoa framework and if you want to extend it you're going to have to use Cocoa. The Cocoa Controller layer is only really possible to do with a rich dynamic runtime; it'll never make it to Carbon. You can only build screen savers using Cocoa and Objective-C. You can only build preference panes using Cocoa and Objective-C. Virtually all new applications coming out of Apple are built using Cocoa and Objective-C.

(Keynote, SoundTrack, LiveType, iCal, iPhoto, iSync, iChat AV, Safari... Final Cut and Logic don't count, since they ware originally developed for the traditional Mac OS and thus aren't new. Neither does Shake, since it was originally developed for Irix and X11 — though it wouldn't surprise me at all to see it rearchitected as a Cocoa application in the next couple of years.)

The future of development on Windows is C# and .NET. This has been clear since Microsoft first released .NET, and it's especially clear in light of the latest PDC and Longhorn.

The future of development on the Mac is Objective-C and Cocoa. This has been clear ever since Apple bought NeXT, and it's especially clear in light of the latest WWDC and Panther.

Deal with it.

So Windows Longhorn includes a new .NET application framework called WinFX, code-named "Avalon."

Turns out I was overly optimistic in my estimation of what Avalon was. It turns out Avalon is just a system for specifying your application's human interface in an XML-based language, XAML, and even specifying what actions in your code will be invoked by different interface elements. And then, get this: You generate C# code from this that actually creates your interface!

Gosh wow, golly gee! You mean I can use XML to drive a code generator? Ooo! Where do I sign up?

Why the hell does it need to generate code just to create an interface? Why the hell does it need to generate code just to associate a control with an action method? What decade are we living in again? Interface Builder on NEXTSTEP was doing this stuff right in 1988. Why are people acting like Longhorn's getting it marginally less wrong than previous Windows frameworks is such a big deal?

There's even a system like XAML available for Cocoa: GNUstep Renaissance. Renaissance lets you specify your interface in an XML file, too, and has for quite a while. (Nicola Pero first released it on December 26, 2002.) The big difference is that with Renaissance, you just load this "gsmarkup" file at run time and it generates the interface and binds it to your objects right then!

What's more, it includes a layout manager system similar to Java's for automatic interface layout. So you don't even need to specify sizes of controls, you can just let the layout manager handle everything.

Here's what a simple gsmarkup looks like (taken from the Renaissance Tutorial):

<gsmarkup>
  <objects>
    <window title="This is a test window" closable="no">
      <button title="Print Hello!" action="printHello:" target="#NSOwner" />
    </window>
  </objects>
</gsmarkup>

This gsmarkup file specifies an NSWindow with no close box and the title "This is a test window", which contains an NSButton titled "Print Hello!" that sends -printHello: to the object that owns gsmarkup (set when the gsmarkup is loaded). Note that you don't have to specify the size of the button, where in the window it is, etc. You can if you want (or need) to, you just don't have to. And if you don't specify a target for a control, its target is assumed to be nil (the First Responder).

You can use id attributes in a markup to name objects and then refer to them using the standard reference (#foo) notation to wire them together within the same gsmarkup file.

And here's something even cooler: When a gsmarkup is loaded, an associated strings file is also loaded if one exists. This makes it very easy to translate gsmarkup-based applications into other languages. You don't even need to change the gsmarkup (especially if you're using layout managers) — you just have to supply a strings files for the other languages!

And possibly the best part: Renaissance works on both GNUstep and Mac OS X. You only need to maintain a different menu structure between the two; for everything else, you can use a single set of markup files (assuming you're using layout managers). One codebase, one interface spec, multiple platforms.

For more information, check out the Renaissance Manual.

Evidently Microsoft has a partial clone of the Enterprise Objects Framework for .NET, called ObjectSpaces. Or perhaps it's more of a clone of the old NeXT DBKit, or EOF 1.1.

It looks pretty simple to use at first glance, but also seems pretty unsophisticated. For instance, it doesn't seem to have the concept of an editing context, only data stores. Editing contexts are very powerful; they provide sandboxing, interaction with a data store, undo support, and generally manage your enterprise object graph. Also, it looks like queries are just strings in a special query language; there didn't seem to be a use of anything like qualifiers or fetch specifications.

Granted, I was looking at a very simplistic demo of an earlier release. ObjectSpaces is still under development and is supposed to be shipped with a later release of .NET; it's something else that's going to be talked about at the Microsoft PDC.

I wonder how hard it would be to knock out something similar in Objective-C.

I wonder if Apple's going to have an object-relational mapping framework for Cocoa before Microsoft ships ObjectSpaces.

Lots of people in the weblog universe are talking about the upcoming Microsoft Professional Developers Conference in Los Angeles. The PDC is where Microsoft is going to be shipping their first development release of Longhorn, their successor to Windows XP.

There are a whole lot of code names being used for various different parts of Longhorn. Aero, Avalon, etc. Just keeping track of the code names is a full-time job.

One of these, Avalon, corresponds to some new application framework that people like Scoble keep hinting will make the browser obsolete. They say it'll do this by turning the operating system into some sort of fancy information environment. Here's my prediction for what Avalon really is...

I think Avalon will do the following: First, it will let developers specify their application's interface via XML, probably through a graphical interface editing utility. Second, it will let developers bind model objects directly to interface elements. Third, it will let these model objects reside — somewhat transparently — on a server, rather than on the client side. Fourth, it will exist as a runtime that is included in Longhorn, so an actual Avalon application will consist of an assembly containing only the XML interface files and the code for the model objects or model object proxies.

In short, Avalon will be an implementation of something Apple has had for several years now: WebObjects Java Client. With Java Client, you build your interface in Interface Builder, which generates an XML file. You use the EOInterface framework to bind interface elements directly to model objects and operations on them (queries etc.). The model objects live on a WebObjects application server, but they can have custom client-side proxies that you can add your own logic to. The Java Client runtime is a jar file that can either be downloaded to the user's machine as necessary via Java Web Start or as a Java applet, or it can be installed directly on a client machine.

There are two twists to this: Java Client works pretty much anywhere you have a Java 2 Standard Edition 1.3.1 or later virtual machine. That means you can deploy Java Client applications to Mac OS X, to Windows, and probably even to Linux and Solaris and all sorts of other platforms. More importantly, though, Java Client is itself just a foundation for Direct to Java Client.

Direct to Java Client automatically generates Java Client applications on the fly from a data model and a collection of business rules. You can customize the objects used in the data model and you can customize the business rule set to customize your application; you don't need to spend your days in Interface Builder laying out interfaces for CRUD (create, read, update, delete) applications.

Avalon sounds like great news for Windows desktop application developers. After all, in 2006 they'll be able to get benefits that have been available since the late 1990s with WebObjects!

Joel is smoking the good stuff! Or is he drinking the purple stuff?

Joel Spolsky of Joel on Software is actually claiming ".NET appears so far to be one of the most brilliant and productive development environments ever created." He goes on to say "ASP.NET is as big a jump in productivity over ASP as Java is to C. Wow."

Living inside Microsoft's locked trunk for too long obviously ruins your sense of perspective. They've been steadily improving their tools over the years, but they started in such a truly awful state that what they have now seems like absolute luxury to Windows developers. If these people would bother to look outside their cramped quarters occasionally, they'd see that they really, honestly don't have it very well off at all.

Here's a choice quote:

I love the fact that you can use an ASP.NET calendar widget, which generates HTML that selects a date on a monthly calendar, and be confident that the "date" class you get back from that thing (System.DateTime, I believe) will be the exact same date class that the SQL Server classes expect. In the past you would not believe how much time we wasted doing things like reformatting dates for SQL statements, or converting COleDateTimes to someOtherKindOfDateTime.

I'd believe it because I've seen the kind of crap you have to go through to get anything done with Microsoft's development tools and programming interfaces. In fact, I've written ported Macintosh software to Windows with them, and even tried to build Macintosh software with them (using their terrible Macintosh MFC SDK). It's amazing Windows developers are ever able to get anything done.

Contrast that to OpenStep, WebObjects, and the Enterprise Objects Framework circa late 1995. There is one date class, NSGregorianDate. You didn't have to write low-level code to access databases, so you didn't have to worry about turning dates into strings you could embed in SQL statements. Instead, your Enterprise Objects - objects transparently backed by your database could just have attributes containing NSGregorianDate objects and The Right Thing would happen automatically.

As I read through this, I find more and more absolutely laughable comments. For instance:

First, they had the world's best language designer, the man who was responsible for 90% of the productivity gains in software development in the last 20 years: Anders Hejlsberg, who gave us Turbo Pascal (thank you!), Delphi (thank you!), WFC (nice try!) and now .NET (smacked the ball outta the park).

Yes, the creator of Turbo Pascal is responsible for all of our productivity gains in software development. Especially since, even though Joel credits him as a "language designer" he didn't really "design" Pascal or Object Pascal. Not, say, Alan Kay, leader of the team that invented true Object-Oriented Programming in the 1970s at Xerox and popularized it in 1980 with Smalltalk-80. Then again, that's 22 years ago - maybe it doesn't count (since Joel said "20 years"), even though industrywide movement to OOP didn't really have critical mass until the 1990s...

Perhaps with .NET, Microsoft is only 5 years behind where NeXT was in 1995 with OpenStep, WebObjects, and the Enterprise Objects Framework. But they're still 5 years behind where NeXT was, and now that NeXT has funding - in the form of millions of Apple Macintosh users running Mac OS X - they're starting to move ahead quickly. If they can bring back the Objective-C version of EOF for Cocoa, they'll be way ahead of the game.