No Thanks Netflix

I use Linux. I've been thinking about Netflix, but also considering other services such as the one from Tivo and Amazon, since I already have Tivo. But I also have iTunes and a video-capable iPod, which I love dearly, so I am kind of watching where Apple TV is going. I would have to buy a Mac *and* Apple TV. I got rid of my last old Mac a while back. But that's a net positive. I almost have Windows out of the house entirely and do not want to build any more dependencies on the one my wife still uses.

But now that Netflix has declared my business to be unimportant...

Netflix plans to adopt Silverlight as the foundation for its instant-viewing feature; a demo showed off high-quality streaming video overlaid with DVD-like menus and controls.

My decisions just got one step easier. Maybe next time, Netflix, when you decide not to rule me out of your internets.

The Simple Things You See Are All Complicated

Note: IronicPython actually *adds* to the CLR to achieve a DLR.

Step forward? Whatever.

Maybe Knot

From http://astoria.mslivelabs.com/...

The goal of Microsoft Codename Astoria is to enable applications to expose data as a data service that can be consumed by web clients within a corporate network and across the internet. The data service is reachable over HTTP, and URIs are used to identify the various pieces of information available through the service.

But, em, er, to find out more about Microsoft's "data service... reachable over HTTP" you are expected to download several Microsoft Word documents.

Bzzzt. Next?

On The Other Hand: Don't Fidget With Widgets

Peter Fisk puts the net in its place. Well, he makes reasonable parallels anyway.

As for "newer" things like flex, xaml (silverspoon or something?), hey, the same ideas have been around quite a while too. Sending GUIs and graphics over a network was not unheard of in dynamic languages in the late 1980s.

If only someone had made NeWS a bit more available.

Don't fidget with widgets, draw!

When run on workstations with 10 MIPS or faster processors, interactive response is excellent, indicating that ezd’s simple structured graphics drawing model can be widely applied.

Short Stack

Don Box on books...

I’ll read the shortest book on the topic.

Let me repeat that.

I’ll read the shortest book on the topic.

Amen. I just saw a pre-announcement for a book on Continuous Integration. The book is supposed to run at 320 pages. That seems kinda big for a book on CI. Either the book is incorporating a lot of related topics, which I'd rather not have included, or there is a lot more to read on CI than I'd imagined.

And I'm doubting I want to *know* that much about CI, let alone *read* that much on it.

Reality Based

Tim Ewald...

Building something real has a way of focusing your decisions about technology.

Adobe to Open Source Flex

That's kind of cool, in a way.

:-)

(Not) On Top Of The Web?

Mark Baker says Adobe Apollo would be...

so much better had they simply innovated on top of the Web

I don't understand how Apollo is not "innovating on top of the web". Sure, it is not *solely* on top of the web. But the browser is not *solely* on top of the web either, is it? I mean the browser accesses the desktop. Apollo apps can do the same, only as a developer I can use Apollo's desktop abilities to go beyond the browser's desktop abilities.

Is one (the browser) a good "web" use of the desktop, but the other (Apollo) not a good "web" use of the desktop? Why or why not?

Apollo simply points out how badly the browser generally sucks and essentially stagnated. Working groups or whatever, there is some catching up to do, on top of the web or not.

Over time I expect to be able to browse in Apollo as well as run all kinds of other, more expressive applications that are "on the web" or even off. At some point down the road turning off Firefox could be an option.

Actionscript Loses Eval

Like Javascript, previous versions of Actionscript had eval(). The latest, Actionscript 3.0, does not.

Peter Fisk's Smalltalk and Lisp in Flex is a treasure in its own right. But in light of Adobe taking away eval(), the desire to have some kind of language interpreter at runtime goes exponential.

I could do with evaluating Actionscript at runtime. There are legitimate reasons to have a fairly-Javascript-like language for customizing interactive applications, although Lisp and Smalltalk appeal to me more, personally.

But Adobe appears intent to make Actionscript as much a static language as possible, and one that has a fairly strict boundary between development-time and run-time. Sadly.

I don't think this can or should be chalked up to security. There are better solutions to security than to throw out run-time evaluation altogether.

Oh well. As Peter has demonstrated, reflection still works fine, so you just build your own eval() for whatever language you desire.

Dependencies

Tim Bray writes about IT...

But the real take-away is this, and it’s something that worries me more and more. I’m convinced that, increasingly, the proportion of enterprise software development based on dynamic languages and AMP technologies and Rails and rapid-iteration continuous-beta “Web 2.0” thinking will increase for the foreseeable future. But that doesn’t mean that Java or .NET or even COBOL are going away, and the brutal truth is that we don’t really don’t have anything like industry consensus on the best practices for integrating Rails and PHP and Java EE and .NET/SQLServer and Cobol/IMS and Ada and all the other weird old shit that’s out there doing boring vital business functions.

It's worse than that.

I've worked on all kinds of systems for design, manufacturing, collaboration, and more. These systems were written in Lisp, Smalltalk, Modula-like languages, C++, C, Java, and more.

The systems that caused problems were those that had unnecessary dependencies among the components. Some of these couplings were all in the same language, designed roughly together. Others of these were in different languages, designed at different times by different people.

Most of the Lisp and Smalltalk systems had as many problems as the others. The nature of the languages made them somewhat easier to deal with. Somewhat.

IT systems are parallized for several reasons. First and foremost is that past systems have so many unnecessary dependencies that they are nearly impossible to disentangle. Significant, ongoing, incremental improvements are few and far between.

Yesterday's best practices did not circumvent this, except in rare circumstances. Tomorrow's likely will not either, except in rare circumstances.

I would almost always choose a dynamic language over a static one, even over those that have implicit and/or optional type checking. (Oh, no. Don't comment on that here.) I would also lean towards rest, atom, "web 2.0", etc. Those are the ways to go.

But incredible diligence will be required to turn those into long-term, evolvable, systems that continue to meet the needs of the business with reasonable investment. (I'm not sure how to measure "reasonable investment", but the cost of change should be somehow proportional to the difference between the business functions already built and the business functions to be built.)

And Now An Example That Works

Alright then, updating to Actionscript 3 the example linked in the previous post which was Actionscript 2, we get something that works, like this...

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="initApp(event)">
    <mx:Script>
    <![CDATA[
             import flash.events.Event;
             import flash.events.MouseEvent;
             import mx.containers.Panel;
             import mx.controls.Alert;
             import mx.controls.Button;
             import mx.controls.Label;
             import mx.controls.TextInput;

             public var submit_button:Button = null;
             public var first_text:TextInput = null;

             public function initApp(event:Event):void {
                 var panel:Panel = new Panel();
                 panel.title = "Hello World";
                 addChild(panel);

                 var label:Label = new Label();
                 label.text = "First Name";
                 panel.addChild(label);

                 first_text = new TextInput();
                 first_text.text = "Patrick";
                 panel.addChild(first_text);

                 submit_button = new Button();
                 submit_button.label = "Submit";
                 panel.addChild(submit_button);

                 submit_button.addEventListener(MouseEvent.MOUSE_UP, onMouseUp);
             }

             public function onMouseUp(event:MouseEvent):void {
                 Alert.show("Hello " + first_text.text + "!", "Message");
             }
       ]]>
    </mx:Script>
</mx:Application> 

If you have the free Flex 2 SDK you can compile and run it like this...

$ mxmlc something_else.mxml
Loading configuration file /home/patrick/flex2/frameworks/flex-config.xml
/home/patrick/dev/patrick.logan/flashstuff/formstuff/something_else.swf (143036 bytes)
$ flashplayer something_else.swf 

Another Flex Tip

I got another promising tip from Garrett Hart here inside Liberty Mutual...

He sent along this Adobe documentation on "Dynamically Creating User Interface Components". Here we go...

Em, hold off on this one. The code as it is in the article seems to be for ActionScript 2 rather than ActionScript 3. There were substantial changes in the display object class hierarchy.

Back to the drawing board, but the Vista Smalltalk swf example is still a good indicator.

Update

The url Garrett refers to in the comments is this one. Blogger kind of mangled it.

Vista Smalltalk for Flash

A hat tip to Patrick Mueller in the comments of my most recent post on starting up with Flex.

I'd not been paying much attention to Vista Smalltalk. Very nice. And Peter Fisk seems to be using the controls from mx.controls that I had problems with. Now to dig into his code to figure out what if any magic lies behind his Lisp or if I was simply missing something.

Either way, good news. The blogs come through.

My RIA Is Dynamic -pause- Naught

Update: It's been a while but there are some corrections to this post.

• The Flex API *does* support drawing on pixmaps so a MacPaint-like capability using this would be efficient.
• All the controls can be created using the Flex 2 API fr ActionScript 3. There is just a minimal mxml wrapper required around the AS code. I can dig it out here if anyone wants to see it, but I'm too lazy at the moment.

End

I've been playing with Flex2 (I'd go all out with Apollo except it does not run on Linux yet and I don't have steady access to Windows XP or Mac OSX). I have some questions that I've posted to some lists, but maybe this blog can attract some feedback as well.

No Pixmaps?

First some general impressions: Flex could be so good, but I am not sure if it is. The basic display architecture is reasonably what I'd expect. I am kind of surprised there isn't a pixmap level drawing capability. (Or is there and I missed it?)

I created a simple paint program that frequently cycles through colors, transparency, and line width. After a minute of "painting" the retained structured graphics system bogs down and mouse events are handled fewer and farther between.

No Intelligent Redisplay?

Which leads to my next question: even if all graphics have to be retained as heavyweight objects, does the repaint really have to slow down mouse handling so dramatically, so soon? If my program is adding a new line just a few pixels long, shouldn't the damage and repaint occur in a small rectangle around that line? I cannot tell what's going on in the slowdown to be sure.

Since I have not found in the API any smart damage capability (e.g. "invalidate just this region for repainting") and only a display-wide "invalidate" then I might assume the entire display list is being repainted unnecessarily. Since the API does have a reasonable hit detection capability then I would expect that to be used to determine what to repaint, if the system had some understanding of where the damage is.

Controls Must Be Precompiled?

I would really like to generate some UI controls (e.g. labels and input controls) based on some data received from somewhere in the course of the application. I wrote a little app to try this out. Then I ran into an error at runtime when trying to add a label to a vbox... "TypeError: Error #1006: getInstance is not a function."

Apparently all the controls in mx.controls can *only* be created through XML and the Flex mxmlc compiler. Actually this is not strictly true since the -keep switch will keep around the generated ActionScript files. Em, not the most beautiful or concise code considering the app consists of a window, a vbox to stack controls, and one static text control.

All kinds of craps are generated that have *nothing* to do with the app. This can also be seen in the runtime behavior of the XML version of this simple thing. While the few small Flex apps I have written to date come up and are ready very quickly, the XML generated app comes up slowly. Looking at the code it is apparently due to all kinds of initialization of things the app will never use.

Ugh - factories initializing craps - a very heavyweight stretch of code. Generated from XML input run through a compiler. (Apparently in spite of ActionScript having reasonable support for XML *in* the language, mxml code can only be generated from a compiler written in Java that runs at build-time. (Or on a "server" if you want to call out to one that can run the compiler for you!)

The result is "rich" but not very "interactive" -- especially given the heritage of ActionScript as a dynamic language. ActionScript, Flex, and such appear to be based in the developers Java heritage. The result is a Java-ization of what used to be a dynamic browser environment into a fairly static Java webstart/applet-like environment.

So given that mxml generates AS code and I can duplicate that, then to some degree this code could be hand-written and be data-driven at runtime (i.e. be done via a "gui interpreter" of data just like a browser interprets HTML). I am going to look into this some more. The code is readable if not concise. It only needs to be done once.

I'd love to find out Flex provides an easy-to-program, dynamic GUI/graphics capability. Almost the opposite appears to be case so far. Several companies are apparently building apps like word processors for Apollo. They have to be doing some fairly low-level and efficient stuff with the text layout and redisplay. I wonder what level of the API they are using and how much code they've had to write themselves.

I could be missing wide swaths of the API that just isn't covered in the typical documentation aimed at building static GUIs in an IDE via XML.

Gambit / Termite / Erlang

Dominique Boucher compares Erlang with Gambit Scheme, and in particular Termite, which is an Erlang-like system the runs on Gambit. His conclusion...

I would choose Erlang over Gambit-C+Termite for the development of a new scalable and robust distributed application. That being said, Gambit-C is a nice piece of software (in fact my preferred Scheme system), it has a great debugger, and the Scheme Now! project will certainly lead to a number of good portable libraries for Scheme. But from the perspective of an industrial developer, Erlang wins easily.

I would have to go along with this conclusion for almost any system that might have to be "production-ready" in the next couple two, three years. On the other hand I think Gambit Scheme is the better investment for the long haul. Erlang is a great language, and OTP is a solid framework for distributed systems. But Scheme is the better "foundation" language and Gambit has all the qualities of Erlang to become a solid foundation for all kinds of distributed systems, even an Erlang system, as exhibited by ETOS (Erlang-to-Scheme).

And In The Darkness Bind Them

secretgeek is a bit more tongue in cheek about this than the Church would recommend...

Lisp is so simple that you can implement it in any language in just a few pages of code. This might never happen though, because once you've learnt lisp you'd never want to write anything in any language other than lisp, so you wouldn't bother implementing lisp in any language other than lisp.

Lisp can be fully implemented in lisp in just a handful of lines. I just implemented lisp in lisp, fully, while i was hopping onto a bus and paying for my bus ticket all at the same time...

Only lispers have a true definition of fun.

Dichotomies

Jim Waldo comments on a resurrected Jini and OSGi thing...

In fact, OSGi and Jini are service architectures built for completely different contexts. OSGi is a service architecture for services that are in the same address space. It allows you to build programs out of cooperating services. And for that sort of thing, it is pretty good.

Exactly what makes Erlang so nice as a "service-oriented" programming language:

• Invoking services in another process is easy.
• There is no distinction between a service in the same address space and one in another address space.
• There are no guaranteed service behaviors, i.e. Erlang faces head-on the problems inherent in distributed systems.

Practice Begets Simplicity

Smalltalk is a much simpler language than Ruby. The ideal implementation is correspondingly simple. This has several positive implications, as Avi Bryant points out...

Dan Ingalls did a lovely binary compatible re-implementation of the Squeak VM in Java as an exercise to learn the language, in a tiny fraction of the time that JRuby has taken, because everything important, down to the parser, compiler, process scheduler, windowing system, and IDE, were implemented in Smalltalk anyway and so could be reused. That’s the kind of trick I’d like to see Ruby able to pull off.

There are a number of idiosyncracies in Ruby, in spite of its relative simplicity. Part of the problem is Ruby has been around well over a decade with just one implementation by essentially one developer.

Consider that in Smalltalk's first decade it changed fairly drastically and did not settle until toward the end of that decade. Also consider during that time there were a handful of implementors, many users, and the intent was to change the language for the better.

Not For Long?

Yes, Seaside is mighty nice. But for two reasons:

• Browsers still suck as an application platform after so many years.
• Programming languages still suck at distributed processing after so many years.

Tweny years ago had someone suggested that in 2007 something like Seaside would be the leading edge of developing distributed systems for end-user interaction, I would have blown my coffee out through my nostrils.

Yes, Seaside is mighty nice. Sadly.

Iraq - That's Right

MoveOn is holding a virtual town hall on the Iraq catastrophe.

You can attend a local house party and view/participate from there if you'd like.

Here is a banner and link you can put on your blog if you'd like.

They are asking which candidate has the best position on Iraq in your opinion. Here is my opinion, which I don't believe is so very far off from many opinions, if not expressed in the same way...

It is a *fucking* mess and getting out of it won't be easy, but I hope several people eventually go to jail because of it. I won't vote for anyone who does not admit it was a mistake, should never have occurred, and vows to apologize to the world as the next president of the United States. Enough bullshit.

That's right. I probably will not vote for president in 2008 unless I change my mind of this.