Flex Is Not The Answer

Maybe someday, and it's definitely an option. Still, the Flash player isn't open source. And yes that matters. Also, Linux is still a second-hand citizen from Adobe's perspective, so far as I can tell. Much like Mac is still second-hand from Sun's perspective. Firefox is the only platform that stays on top of things, but their feature set and performance isn't quite there.

And there's the nice options for using Flash and Silverlight, for example, to implement HTML 5 features like the video tag.

But when it comes to apps (not sites), I still like Swing and Web Start personally, no matter what some people say. I just have to target years old versions due to that Mac issue.

In the future, things may change in who knows what ways, but that's for the future.

XML Is Only Complicated In Our Minds

I have a common history. I heard of XML and jumped all over it. It was king. Then I decided it was overly complicated and unneeded. Then JSON (simplifying concepts in YAML) came along promising a happier and simpler data interchange. Who needs namespaces and schemas and canonical forms and InfoSet and who knows what else?

Well, um, I'm back to liking XML, just a happier-go-luckier kind.

First, my beeves with JSON:

1. No comments. So that means not human readable.

2. The spec fits on the home page, but when people say "JSON" they often mean incompatible, nice things that don't involve quotation marks in the keys. And things like that.

3. A more extreme form of 2, along with the obvious implementation in browsers, assumes that all JavaScript is JSON. Just use "eval". Well, I know regex can validate it, but lazy code can lead to pain.

4. Heterogeneous lists are awkward. As in, first a text field, then a button, and so on. Note that some of the JSON examples simplify this issue because doing it right would look uglier. I think it applies at least to the "widget" example.

Back to XML, we really just try too hard to over-engineer things. It's the mindset. Take a sample from the JSON site. Here's the XML:

<menu>
  <header>Adobe SVG Viewer</header>
  <item action="Open" id="Open">Open</item>
  <item action="OpenNew" id="OpenNew">Open New</item>
  <separator/>
  ...

And the "equivalent" JSON:

{"menu": {
  "header": "SVG Viewer",
  "items": [
    {"id": "Open"},
    {"id": "OpenNew", "label": "Open New"},
    null,
    ...

Is that really simpler? Well, "the action and label values only need to be provided if they are not the same as the id". Um, shouldn't that apply to XML, too?

<menu>
  <header>Adobe SVG Viewer</header>
  <item id="Open">Open</item>
  <item id="OpenNew">Open New</item>
  <separator/>
  ...

Looking better. How about name value pairs? Isn't text data better than attribute values? Because it's extensible and you can wrap it in more markup, right? Well, how about just calming down. If JSON can have plain strings, I think XML can, too. Instead of this:

<init-param>
  <param-name>configGlossary:installationAt</param-name>
  <param-value>Philadelphia, PA</param-value>
</init-param>

say this:

<init-param
  name="configGlossary:installationAt"
  value="Philadelphia, PA"/>

Wow! Almost looks like JSON with those name value pairs! I didn't know XML had JSON features! But what if I wanted an object instead of a string? Just go back to using elements.

But it seems so very ad hoc. Um, well, yep. If you can be ad hoc (somewhat) with JSON, why not XML. And while you could write a schema for JSON (surely something exists?), do you usually? And is that okay? Now, I know schemas can be nice, but do you need them in every case?

Do you always need namespaces? Do you need them in JSON? If not, why not?

Meanwhile, the official DOM (especially originally) is just a terrible API, but plenty of good alternatives exist for just about every language in common use. And we're familiar with them.

So, remember, XML has lots of fancy specs and features which have proper occasions for use, but _don't use them when you don't need them_. Think happy thoughts, and XML can still be a good friend.

Scala More Abstract and C# More Concrete than Java

First, a bit of background. I love programming languages. I was working on my own now and then before I started getting into Scala. It was closer to Java, but still extensible. But the biggest difference from Scala was that I was targeting it to be very _concrete_.

By this, I mean that Java (while nowhere near as abstract as dynamically typed languages) is still somewhat abstract in nature. Methods are virtual by default (dynamically dispatched). You have to make an extra decision to define things as final. But Josh Bloch says to design for inheritance or forbid it.

While C# doesn't try to avoid inheritance, methods are _not_ virtual by default (something Java doesn't really support for instance methods). This makes it less abstract in its default style than Java. And extension methods are really static, too.

My idea was to make classes and methods default to 'final'. I find from coworkers and myself that it's easier to know what things do if there's only one definition. And I can usually add abstraction just when needed. At least, I think I can.

Scala goes the opposite direction, encouraging generic types, abstract types, everything dynamic dispatch where possible, full object orientation and instance methods, structural typing, mixin traits that allow overriding, and so on. This is doable also, but I'd like to see better support than what Eclipse has for control-clicking on definitions. If it is overridden in the project (or workspace), please show me the options especially if the top level definition isn't fully abstract/undefined.

And it's not too hard to image the abstract meanings of types and methods. And it's not as abstract as dynamic types. But it's an issue that shouldn't be ignored when going into Scala. Scala isn't a language that prefers the concrete.

LINQ For Java ...

LINQ for Java should look a lot more like db4o than Quaere. An independent project to do something like db4o's native queries would be nice. Maybe sit on top of JPA for ORM, or something like that.

$20 Bounty For JVM Mixins

I've mentioned that Scala jars are huge, and that's mostly due to mixins. Pack200 doesn't solve the whole problem, either. So, I'll donate $20 to whomever gets mixins into the JVM such that there's no need to forward every single method individually. I'm sure other languages could take advantage of that, too. (An extra $10 points for good handling of prototypes/delegation to arbitrary objects.)

Once upon a time, I offered a $20 for immediate objects (such as representing Integer objects directly in pointers by taking advantage of unused least-significant bits) in the JVM. I'll stand by that still, too.

That's up to $50 for the entreprising individual. Just think of all the pizza you could buy. Oh, and here's the Da Vinci Machine link for getting started. Though, to clarify, I do need the final result in an official Java release before paying.

Thanks much in advance.

IDE For Scala instead of Closures For Java

The more I think about it, the more I think that people who want closures in Java would be happy enough with Scala if they got used to it. _If_ it had competitive IDE support. And IDEs for Scala aren't nearly so controversial as closures for Java. (I can just hear the cries of "IDE support would ruin Scala!")

And _if_ Scala had really good IDE support, I wouldn't use Java if I could avoid it. Because no one is serious enough about getting rid of checked exceptions.

So I'm in the no closures for Java camp. Keep people happy.

Really.

And no ARM either, even if they get CICE. The whole overloading of 'do', 'try', and 'protected' seems scary to me. Much like the old-timey "we only have N operators in C++ so better overload them all we can" situation.

Methods That Look Like Vars

A couple of years ago, Tim Sweeney of Epic Games (makers of Unreal) gave a presentation on "The Next Mainstream Programming Language". See here for Cedric Beust's take.

One of the points brought out by Cedric is that evaluation should be "lenient by default". Here's a simple example in Java:

public class Numbers {
    public static final int FIRST = 1;
    public static final int SECOND = FIRST + 1;
}

The order of definitions matters a lot. You can't put the SECOND before the first. (And try circular dependencies across classes for some fun.) Well, if we used methods rather than constants, the order of appearance doesn't matter:

public class Numbers {
    public static int second() {
        return first() + 1;
    }
    public static int first() {
        return 1;
    }
}

Mr. Unreal Tournament says that the lack of dependency on definition order is better than than supposed performance gains.

Well, both examples are bulky due to Java syntax, but the methods version is obviously more work than the constants. Well, say we had a language where defining methods is as easy as defining constants. There are several such languages, and Scala happens to be one of them. This corresponds roughly to the second Java example:

object Numbers {
    def second = first + 1
    def first = 1
}

So remember, according to Mr. Sweeney, Scala's 'def' is your friend. (Unlike in Groovy where 'def' makes vars or methods, 'def' only makes methods in Scala.)

That said, I'm not super hip on all out functional programming. Immutable and semi-functional have their uses, but I'm not on the big time functional side of the Scala crowd. At least not for now.

Scala Bean Properties

First of all, Scala isn't Java even if it's interoperable. That's a pro or a con depending on your perspective. But that's how it is.

For example, take this class:

class Whatever {
  var name = "Tom"
}

As I've mentioned before, that generates accessor methods, not a public field. Scala is way more object oriented than Java.

But the accessor methods are named "name()" and "name_$eq()". Way more sane than Java in some ways, but not compatible with say, Hibernate. So until/unless such tools add Scala support, you need to be compatible on your own.

Well, Scala makes this one not too bad. Just add an annotation to generate standard Java "getName()" and "setName()" (in addition to the Scala-conforming accessors):

class Whatever {
  @scala.reflect.BeanProperty
  var name = "Tom"
}

Et voila. Or 'import scala.reflect._' to cut that down to simply '@BeanProperty'. Could be worse. Could use an IDE to generate source code. *Shudder*