Where You Find It

The Portland Tribune has a story about a local boy dying after having
been ill (shortness of breath, stomach cramps) for a week. His family
believes in "faith healing" and does not believe in western medicine
or apparently any medicine. (What would they consider food?)

http://www.portlandtribune.com/news/story.php?story_id=121379440855614400

Religion is what it is for each individual and family. In this case I
don't think the boy was given a choice, let alone the tools to make up
his own mind. That's not unusual. Most religion is passed down I
suspect.

As a Type I diabetic who knows almost nothing about health or
medicine, I have to say what little description this article provides
of the boy's symptoms, and the duration of them before his death,
*could* indicate Type I diabetes. This is a very manageable illness,
and whatever the true cause of death, the week in which the family
could have sought treatment but did not, was tragically long.

The boy also happens to be the cousin of a baby girl who also died
after the family refused medical treatment. Does this family simply
rationalize that their god does not love them? Or does not love these
specific kids? Or that everyone just dies when they die? (Which again
makes me wonder, why does anyone in their family eat meals?)

Filed under "apparently unnecessary tragedies to children, but I don't
understand".

SVG and Flash

Steve Dekorte wonders...

"Considering that ActionScript is really just Javascript with some
rendering APIs, once SVG is ubiquitous (effectively taking care of the
rendering API), will there be much point to Flash?"

http://www.dekorte.com/blog/blog.cgi?do=item&id=3468

(Aside: ActionScript is _worse_ than JavaScript, as it is a kind of
JavaScript+Java-semi-static-typing hybrid. Anyway...)

What Steve's really getting at is SVG vs. Flash. Flash goes well
beyond rendering, into multimedia, interactivity, environment/network
integration, etc. SVG has some support for JavaScript callbacks and
not much interactivity beyond that. SVG currently only (mainly?) runs
in some browsers, with all the pro's and con's. (I think Adobe's SVG
engine used to run stand-alone. Maybe others do as well?)

Flash could be a good foundation for an SVG engine. SVG could be a
good foundation for a Flash-like replacement.

I'd like to see SVG advance into a more fully capable engine for
*interactive* structured graphics, and beyond that a more fully
capable platform for many kinds of applications. SVG could be our best
hope for moving beyond the browser per se.

Those foundations require a simpler language than JavaScript and a
better security model than the browser or even Flash. The
interactivity model should provide a mix of
declarative/constrain/dataflow as well as imperative (i.e. callbacks
and mutable data, e.g. display lists).

The Emerging Enterprise in the Cloud

Jon Rose writes...

I have been working on a case study with Claude Courbois of NASDAQ for a few months now. We finally finished it up and published it over at InfoQ.com. NASDAQ has a very cool application, Market Replay, which utilizes AIR (desktop) & S3 (data). I am personally fascinated by how much the world has changed, as the platforms allowed NASDAQ to roll out an enterprise application with very minimal hardware infrastructure...

These technologies... I believe that their innovation will really mean more opportunities... They are enabling us to bring to market many ideas that were previously too difficult or costly to implement.

Or even just ideas too time-consuming too implement. Development groups with an idea can go and grab a fair bit of infrastructure without all the hoopla needed to requisition all the pieces within an IT data center. If the ideas prove out then in some cases they could or should be brought back "in-house". In other cases, they may be fine in the cloud.

Erlang Supervisor Hierarchies in Scala

Initial attempts to duplicate Erlang in other languages tend to make a lot of simplifying assumptions, either knowingly or unknowingly. Distribution is a big feature often overlooked initially, and beyond that "supervisor hierarchies" in which various distributed processes are either workers (do the real work) or supervisors (ensure the real work continues in the face of process or node failures).

Jonas has started an implementation of supervisor hierarchies for Scala's agents, as well as a basic "generic server" framework approximating Erlang's gen_server, etc. So far I think it's all running in one JVM, but it's a good start at illustrating all that Erlang does on behalf of a distributed system.

Above the Fray

Steve Yegge relays a fracas about language interoperability...

He [Chris] asked this really innocent question. He goes, "You know, I don't really know much about this stuff..."

Which is bad, you know. When somebody says that to you at Foo Camp, it means they're settin' you up.

He says, "So how do these languages talk to each other?"

And the room just erupted! It was chaos. All these people are like, "Oh, it's easy!" And the rest of them are like "No, it's hard!" And they're arguing, and arguing, and arguing. They argued for an hour.

And then they stood up, still arguing, and they kept talking about it, heading into the dinner tent. And they sat down, going at it for like three hours.

It was chaos.

Because some people were saying, "Well, you know, if Ruby's gonna call Python, well, uh, you just call, right? You just share the same stack, right?"

And the others are like, "Well, what about different calling conventions? What if they support optional vs. non-optional arguments? What if they support default arguments? What about the threading model? What about the semantics of, you know, the this pointer? What about all this stuff?"

And they're like (waving hands) "Ooooh, we'll gloss over it, gloss over it, smooth it over." And the reply is: "You can't. This is fundamental. These languages work differently!"

And oh my god, it was really interesting. And it was also very clear that it's ten years of research and implementation practice before they get this right. Before you'll be able to have a stack of calls, where you're calling from library to function, library to function in different languages.

So today, VMs are good for interoperability, but you've gotta use a bridge.

I thought this was going to be interesting, then I found the conversation was about language interoperability *within* a VM.