3 – What Can I Rely On?

In the last post we have seen that it will take me years to finish this project. The question is, what can I rely on, what can I build upon. What are the tools that I can use, without worrying that they are obsolete before my own tool even becomes usable?

Programming Language

In the case of RPCmagiX I have made a bad choice. I used Itcl 2.2 for implementing the GUI, and as soon as I had finished it, ITcl 3 came out and it was incompatible in some subtle but crucial ways. But even if it had not been so obvious, today Tcl is mostly dead.

Perl was my choice for WADL, and although Perl is still much more alive than Tcl ever was, it is not really dominant any more. Perl 6 has taken too much time, there was a lot of FUD about Perl’s imminent death, and at the moment Python is king and Ruby the fashionable contender.

I really hate Python. It’s personal, probably nothing that you’ll understand, but a language that relies on indentation for structure, c’mon! That’s nothing but a bad, tasteless joke. So Python can’t be it.

Ruby seems to be OK as a language, but I have no idea how it will fare. It could easily be the next Tcl. Remember: we are talking about at least three years before the shelf life of my program even begins!

COBOL would be a good candidate for a language that is guaranteed to never die. But who would want to work in COBOL? Nope, not even joking

And then there is another thing: I would like to use one language for the tool and for the code it creates.

Currently I work with Java. It took me a time to like it, but now I do. Yes, it’s a big ecosystem, yes it suffers from the fact that they had to reinvent the wheel and everything else that already was there, but now it is pretty mature and complete. And it has Eclipse. Working with Perl I never missed an IDE. A lot of Emacs windows on a big virtual desktop, some teminal windows, that’s all I ever needed.

Not so with Java. Java is pretty unusable without an IDE. But when you have something like Eclipse, when you have an integrated, incremental compiler, when you don’t write texts but actually manipulate parse trees, then all sorts of funny things are possible. Think of the refactoring support, and suddenly Java is a very flexible and dynamic language.

And Java has some other advantages: It won’t go away. Too much important code depends on it. Java is like Cobol, only a much more likeable language, and one with absolutely superior tools. Java is such an important language, because so much code for banks and insurances is written in it. There is a reason why there is a Java Enterprise Edition.

And for all that reasons my potential users are very, very likely to use Java. When I want to maximize the impact of my tool, Java is an ideal language.

But then, very similar things could be said about C#. Same category of language, same capabilities. A year ago I have written a nice mult-threaded system in it, and as a language I like it. Why not, it’s Java, deliberately disguised in an incompatible syntax, but there is no essential difference, and some solutions they have come up with, are really, really clever. For instance I like partial classes and miss them in Java.

On the other hand, it’s a matter of principle. I don’t like a language that is so tightly controlled by an entity like Microsoft. I don’t like working on Windows either. Yes, there is Mono, but when you go the Microsoft way, you really want Visual Studio.

Apart from that, it can have actual advantages when your tools are open source. Remember my ill-inspired decision for Itcl? Well, it is open source after all. For more than 10 years we have compiled Itcl 2.2 on all our AIX and Linux systems, and I see no reason why this can’t go on. A closed source core component would long since have been unsupported. Think of Visual Basic. Sure, Microsoft offered a migration path into .NET, but that’s only the core language. People often had augmented it with third-party components, and they often were not ported. We sure do have some of those cases.

Libraries And Frameworks

And then there’s all the stuff other people do. After all, what I’ll do is basically Model Driven Design. Eclipse has a whole big group of projects under that title. Shall I use them. Can I?

They play a different game. They play a numbers game. The Eclipse Modeling Project has seven people only on its Project Management Council. Look at the list of projects on that page. Everything on that list looks interesting and like something that I could need, but I would have to spend all my time, work, free, sleeping, just to follow all that.

And then think of all that constantly changing. Try imagining the hassle with keeping all that in sync. It’s impossible, and even if I could do that, it would not help me, it would only slow me down.

No. I won’t do it. It may be possible to catch up with these things later though, for instance at a time when I have some people helping me. If they are interested in the field at all, they would probably have worked with those tools and frameworks. They would probably know how to bridge the gap between EMF and my own core abstractions. After all, whatever I come up with, it must be semantically equivalent to EMF, because if it were not, it couldn’t be as expressive.

Yes, I know, in a way it’s a waste of time to re-invent such things, but I simply can’t tie my own core abstractions to something that is completely out of my control. This would be irresponsible. On the other hand, when my own modeling structures are largely equivalent, when they simply have to, we can always bridge that single gap later, and by doing so, we will gain access to the whole infrastructure. At least that’s the theory

So What’s Left?

I consider Java to be a good choice as a language, and I consider the Enterprise Edition in release 6 sufficiently mature. I will use all of that (well, probably not JSF, but who knows), and I won’t use any other framework.

The whole design will be very abstract, most of it completely oblivious of the environment it runs in. In the end there will be some channels where input comes from, the models will have to be stored, there will be code generators, but all that can be abstracted away, done by primitive stubs in the beginning, done by plugins later. The only things that I have to worry about now are my code abstractions and how expressive they are.

I can and should program away in my simple sandbox, not caring about slick user interfaces and high performance. While I do that, all sorts of things will happen. Computers will get faster, new frameworks, new GUI systems may come up and get mature, and I’ll connect to them when I need to. Doing it from the beginning would only be a waste of time.

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.