Smalltalk with James Robertson

So much for .NET delivering a seamless environment for dynamic languages:

Much early speculation on this change in focus comes from Jim Schementi, previously the program manager in charge of Microsoft's implementation of the Ruby software known as IronRuby. Schmenti reports on his blog that the team dedicated to working on IronRuby has decreased to one employee.

Over in Java-land, with Oracle in the driver's seat I just don't see it happening. So it looks like the future of dynamic languages is in the hands of the backers of those languages - and they won't get a lift from the big guys.

Technorati Tags: windows, dynamic languages

Tim Bray would like more choices for development on the Android platform:

And finally, as a citizen primarily of the Web, I can’t help but notice that in recent years, its interesting bits (Facebook, Wikipedia, Twitter, 37 Signals, Ravelry) are largely not being built in Java. I know first-hand that there is a substantial community of really first-rate programmers, people I admire, who for one reason or another just don’t want to deal with Java; and I’d like some of them to become Android developers.

It's interesting that Apple's policies (limiting development to the C family plus Javascript) have gotten so much attention - but the situation on Android isn't that different at the moment. Sure, it's not due to any Google policy, but the end impact works out the same way. Becoming a first class citizen on these devices just isn't that easy without help from the platform vendor.

Bray thinks things will start opening up by 2011; we'll see. I think it's going to be hard for outside developers to keep up with the platform as it changes and evolves...

Technorati Tags: android

InfoQ has another interesting interview up from QCon: a chat with Ralph Johnson and Joe Armstrong about what Smalltalk got right and wrong. There's video and a transcript at the link.

Technorati Tags: smalltalk, erlang, qcon

Michael explores the idea:

But it's the 21st century and it dawned on me that normalization is the futile act of trying to manually compress data. If you break up your data records in to its related component parts to -avoid duplicate data- then you're literally trying to re-invent compression ..badly.

Last night Michael pointed me to this article on something called "Entity Based Programming" - an approach that the author claims is better than OOP for MMOG (Massively Multiplayer Online Games). I read it with interest - the first three sections sounded interesting, and made some good points. Part four started to lose me though, as he veered into relational technology as the answer - by part five, I was completely off board. In a discussion of metadata, he had this to say about metadata for game objects:

You can’t do that with OOP: you can get some *similar* benefits by doing C-Header-File Voodoo, and writing lots of proprietary code … but … so much is dependent upon your header files that unless you really know what you’re doing you probably shouldn’t go there

This tells me that everything he knows about OOP comes from C and C++, which doesn't give me confidence in where he's coming from. It's the rest of part five that had me losing interest - his near obeisance to relational technology as a way to proceed. Apparently, he hasn't noticed that the large scale web apps - Twitter, Facebook, Digg - have all been bailing on relational technology, because it doesn't scale for their needs.

Based on what this guy writes - the need for speed - in MMOG systems, I simply cannot see relational as a scalable response. That's too bad, because the first three parts of his article were interesting. I'm not sure I'm sold on what he's pushing, but I was intrigued. Parts four and five? Totally lost me.

Technorati Tags: mmog, entity based programming, oop

Patrick McKenzie explains why everything you think you know (as a software developer) about names (personal names, not variables) is wrong. While email addresses don't share all of those problems, it's not safe to assume that everyone who goes into your system will have one...

I'm a big fan of only adding scaling to a system when you need it - but there are times when you know that you are going to need it. Like, say, yesterday, with the Apple/At&T iPhone pre-ordering system:

They're just using some web interface, not the exact same customers are using online, but not much better. It's probably the same servers. Basically, they were getting one pre-order thru every 20 minutes. They said the problem was system wide. Here's how it worked: They just kept mashing on the 'submit' button and getting error after error. On the umpteenth try, it'd go through and then the next step, whatever that was, would get error after error. After a long time, it would finally go through. What's worse is that the first step of the process reups your 2 year contract, so you can't walk away if you get fed up. I had to stick around until it went through, or i'd have a new contract but no subsidized phone.

I ran into that myself - and the error message from the Apple site probably confused some people. The site told me that there was an error at the point where I entered my Apple ID. That made me wonder, so I pulled out my existing iPhone and asked it to update a bunch of apps - just to get prompted for my password. I hadn't entered anything wrong; it was just the servers having problems.

This isn't a new thing, either - you would think that Apple and A&T would be ready for this by now.

Update: Well, it seems that AT&T didn't bother to test the new system:

As the iPhone 4 preorder disaster worsens by the minute, the blame looks to fall squarely on AT&T's shoulders as we learn more about what went wrong. The most damaging of these may be an source close to the carrier which now claims the system which AT&T was not tested before the launch.

Awesome.

Technorati Tags: apple, att, iPhone

It doesn't really matter that Android supports Flash, or whether Android based tablets do - Apple's major market share in the mobile space is driving change. Here's one developer's story, about why they are ditching Flash for their site:

Why? Because many of our employees and customers use iPhones. As it stood, the several Flash components on our home page either showed up as blank spaces on iPhones, or didn't provide the content we really wanted to deliver. We also anticipated a time when customers, the media, industry analysts and others would be viewing our pages on iPads -- perhaps even more so than on iPhones. In other words, we had to future-proof our site by removing Flash.

This is why I'm happy that I moved away from Wink (which uses Flash to drive the final screencast) back in 2008 - I managed to accidentally future-proof "Smalltalk Daily".

This is a decision I expect to see more of. Having two or more video formats is just too expensive (in terms of time, if not money). It's simpler to just drop out something that's HTML5 ready, like H.264.

Technorati Tags: flash, adobe, web development

Google has added a cloud storage service that is plug compatible with Amazon's S3:

Google Storage is interoperable with a large number of cloud storage tools and libraries that work with services such as Amazon Simple Storage Service (Amazon S3) and Eucalyptus Systems, Inc. To use these tools and libraries, all you have to do is change the request endpoint (URI) that the tool or library uses so it points to the Google Storage URI, and configure the tool or library to use your Google Storage developer keys.

That's pretty cool; it means that developers can flip back and forth pretty easily based on price and performance. The pricing looks competitive as well.

Technorati Tags: cloud, google, amazon

Dave Winer hits on something interesting here - in a post about the ongoing move past XML:

This is why I find the arguments of the JSON-only proponents either lazy or dishonest. I don't know which it is. They say that XML is too complicated, but that's wrong. Just ignore everything but elements, attributes and namespaces.

You need to read the whole thing to get the context, but - to summarize - Dave laments the way XML has been deemed as "too complex", and uses XMPP as an example of that. I thought about doing something with XMPP once, but after looking at it, decided against. I wanted to leave some time in my life for other pursuits, like eating and sleeping :)

Here's the thing though - over time, the architecture astronauts grab all emergent technologies. They got their hands on XML, and ended up getting lost in the weeds (I still subscribe to the Atom mailing list - you should see what level of minutiae gets discussed there these days).

Fear not though - JSON may be simple now, but once the astronauts are done with it, someone will have to invent yet another simple text transport scheme. It seems to be the way things happen in this industry.

Technorati Tags: xml, json, transport formats