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.)