Draconian Overlord - Latest Comments in JavaFX Decompiled

Re: JavaFX Decompiled

Dan — Tue, 17 Mar 2009 02:25:46 -0000

You can't avoid 'int wrappers' in a language/VM where ints are not objects. They are going to be wrapped.

What they built here is a JavaFX to Java translator and compiler. This has been done many times before with other languages, like Ada ( to C ) and Smalltalk/X ( to C ).

Doesn't mean it is 'wrong', it is a very powerful way to develop a language, and also provides compatability with the host language pretty easily.

Saying it is somehow 'cheating' is wrong. C was concieved as a portable assembly, and Java is the "C" of the JVM. Sure, it lacks in expressive power, but so does C.

Re: JavaFX Decompiled

shaberman — Fri, 27 Feb 2009 12:17:23 -0000

Thanks for the reply, Det.

> also functional abstraction in the large.

This is an interesting assertion--I disagree, in general, but will keep it in mind and see if my opinion changes.

> If you can't imagine an average programmer to deal with traits, you
> should see some of my colleagues which are struggling hard with
> the bunch of interface, implementation, delegation chaos they
> created when trying to achieve the same goal.

I can appreciate most Java systems are done wrong--however, my observation has been that most of it is self-generated complexity from architects thinking they must have an "enterprise" system that is all the current hotness of "DI", "decoupled", "patterns", etc. On my last gig I saw this--a whole bunch of interfaces, tied together with Spring, etc., etc., that was a nightmare. But none of it was really needed to build the system--the programmers just thought "this is the way you do J2EE".

> Only a simple example: Open a file, iterate through all its lines and
> print it to standard out, if the line matches a given regex pattern.

Straight Java:

for (String line : FileUtils.readLinesThatMatch(path, regex)) {
System.out.println(line)
}

Okay, it is up to me to build the "FileUtils" abstraction, but that is easy if done once. The Java File API being bad/incomplete shouldn't reflect on Java the language.

Granted, Give me C#-style static extension methods and it gets better. Give me closures and it gets better. Both of which are incremental/syntactic "Java++" improvements and not a dynamic typing system (Groovy) or a different typing system (Scala).

I think the problem with J2EE today is that most architects would have solved the "print lines in a file" problem with an interface IFileOpener, another IFileLineMatcher, added just 1 implementation of each, and then injected them with Spring.

> (And btw: There are so much tools around J2EE that add such hidden
> extra stuff all the way only to get things done for enterprises, I would really
> like to have a concise and high level language to express such things

I agree, most tooling sucks.

Re: JavaFX Decompiled

Det — Fri, 27 Feb 2009 08:07:01 -0000

> My current rule of thumb: if you can decompile a “Java++” contender’s code into the regular
> Java syntax, and have it look pretty darn close to what you’d type out by hand, then you’ve
> found your true “Java++” language.

Then I would say, I don't want a Java++ language (means: Java++ is not better than C++ over C). I indeed need the abstraction level that not only provides syntactic sugar in the small (type inference reduces one line of 80 chars to 20 chars.) but also functional abstraction in the large.

If you can't imagine an average programmer to deal with traits, you should see some of my colleagues which are struggling hard with the bunch of interface, implementation, delegation chaos they created when trying to achieve the same goal.

I have colleagues in our necessarily big size enterprise development who struggle hard with the complexity they introduced into their hand written code to get the results they would otherwise get in some clear readable lines in other languages.

The simplicity of the Java language made them write so much technical stuff to get the domain requirements implemented, the code became hard to maintain, as the "implementation details" always are in the way in understanding what the previously intended meaning is.

In Java, the domain purpose is always behind the implementation. In other languages the implementation is mostly behind the domain description.

Only a simple example: Open a file, iterate through all its lines and print it to standard out, if the line matches a given regex pattern.

Do this in Java and do this in Groovy (or Scala, for all I care).

And then extrapolate this experience to an 80 developer times 8 year enterprise project.

(And btw: There are so much tools around J2EE that add such hidden extra stuff all the way only to get things done for enterprises, I would really like to have a concise and high level language to express such things in a coherent syntax instead of switching between all this different add-on-compilers, configuration files and stuff...).

Re: JavaFX Decompiled

shaberman — Mon, 09 Feb 2009 14:09:03 -0000

The benefit is less typing.

I want the decompiled output to look like regular Java, not the "Java++" source language. The source "Java++" should have all the type inference, closure, extension method, etc., goodness of something like C# or boo.

The benefit being I get a nice/succinct syntax (which is, IMHO, mostly why "dynamic" languages are so popular these days--its the syntax, not the dynamic typing), but without introducing lots of "not Java"/complex semantics like the current "Java++" contenders do (e.g. Groovy, Scala, JRuby all add complex semantics on top of basic Java that I don't see the need for).

Re: JavaFX Decompiled

Mark — Mon, 09 Feb 2009 13:05:32 -0000

>>My current rule of thumb: if you can decompile a “Java++” contender’s code into the regular Java syntax, and have it look pretty darn close to what you’d type out by hand, then you’ve found your true “Java++” language.

Riiiggghhtttt..... then you have.... Java?

And the benefit is?