September 8th, 2006
Turbo C# is available now.
I blogged about this 2 weeks ago. The install had been smooth (besides that I had to install .NET 1.1?!) and at look quite clean. The IDE cannot deny that is is made with .NET:

Well, Borland a little bit more work, even for a free product would have suited you better, the installer and the registration are so 90ty.

Perhaps it gets better in 100 years, when I have to register a new copy:-)
Posted in
Java |
No Comments »
August 21st, 2006
After some assembler (8080!), the first programming language I learned had been Turbo-Pascal. If I remember correctly; it could not have been Turbo, as I was 12 years old at that time and Turbo did not yet exist then - well it does matter that much - I definitely used Turbo-Pascal later.
Borland seemed to find the name “Turbo” not very professional, so they dropped it. As IDEs are now a commodity, the professional touch is gone and the Turbo is (nearly) back!
As C# has some appeal to me, it looks like I could use another creation of Anders Hjelsberg…
Posted in
Architecture, Java |
No Comments »
July 2nd, 2006
Remember http://www.javalobby.org/java/forums/t74270.html?start=0? It seems that everybody read and replied on it:-)
Nearly all proposals made (even the one I added my self) have a serious problem: They don’t play well with interfaces.
First I like to define what I mean when I talk about a Property:
A Property is a member where get().equals(get()) and set(x) => get().equals(x).
The java.util.Properties fulfill this condition nicely, as do simple members like names, etc. The Properties-class was actually what got me the idea: As I was faced at work of writing hundreds of getter/setter and member declarations, I took a short-cut and handled this by named attributes. The only thing we lost (besides some CPU-cycles) was type-safety (not a concern in the situation) and the clear binding that allowed refactoring (important then, no issue now). Most of non-trivial get/set are actually interceptors that don’t modify the behaviour from a simple member access. If this is not true you don’t a have Property in the sense of this text.
Why the concept of properties at all? Because it carries important semantics. The user of a property is encouraged to rely on this, this will simplfy code and makes programm more stable if the rule can be checked by an “meta-assert”.
So general advice, if “dynamic” properties will do: Go for it, especially in web-programming where you can spit out String for numbers and dates.
Well, I admit that this is not too satisfying, so here a better solution, but it’ll require a JSR:
The property keyword
The keyword property is somewhat similar in it use as the enum keyword.
property {
int a,
String b,
HashMap m
}
Read the rest of this entry »
Posted in
Java |
2 Comments »