Slashdot Mirror
Eclipse Launches New Programming Language
An anonymous reader writes "Eclipse has launched a website for a new JVM language, called Xtend. It's built with Eclipse's Xtext and compiles directly to Java code, similar to what CoffeeScript does to Javascript. It's not just an announcement but it's already there and useable, including a very feature-rich Eclipse integration."
The "You want performance? Fuck you, have more features instead!" of IDEs.
"We saw what you did with your classes, so we added some more classes to your classes to hide your classes because we have more class."
"We saw what you did with your syntax so we added some more syntax to your syntax to hide your syntax because we are more syntaxy."
"We saw that java still sucks so we added some more suckiness to java's suckiness to hide java's suckiness because our suckiness sucks less ... sort of ... maybe ..."
"... because our next step is to distract you from our new suckiness by adding more xml ..."
We are using Xtext (2.0) and its companion Xtend (2.0) to build domain specific languages. Together with Xbase, a part grammar for expressions, we can build new DSLs for various purposes in no time. And it is not such a code bloat as some people might think. When you develop applications with a wide range of models, these EMF-based tools are quite practical. Beside that, we evaluated ATL, QVT, and Xtend in various scenarios. Right now it looks like, that Xtend is very well suited to build generators to source code of other languages especially Java and Scala. It also made a good impression in model-to-model transformations.
And leads to extremely bad code. Goto has the same thing - it can be extremely powerful, but overusing it leads to really bad code.
It's not so much about overuse. Rather, it's the misuse of macros and gotos (and any other coding construct) that can lead to bad code. Macros and gotos get a bad rap because they get misused more often than other constructs, mostly by those who are really new to programming. When used appropriately, these constructs can make code more readable and easier to maintain. It's too bad that so many students are being taught to avoid gotos at all cost; better to teach them when gotos can be used to good effect.
This author takes full ownership and responsibility for the unpopular opinions outlined above.
You do know that the Java runtime is an order of managitude smaller than the .NET runtime dont you (and that is not even considering that .NET also requires the bulk on Windows while Java does not). In short, your knowledge is severly out of date - you musta been drinking the Microsoft koolaid. Well, here is news for you, .NET will be superceded by another Microsoft product long before people stop using Java (especially in the Enterprise space).
Who cares if Oracle kill their Java. The Free Software OpenJDK is where the action is at. Then there is IBM Java, and GNU gcj/classpath, and Kaffe, and others. It is not a situation like .NET where if Microsoft kills it then it'll die everywhere (due to the proprietary licensing).
First we got told that writing person.name = "John" is bad. Bad, bad, bad. I never understood why.
I don't know who said that it's bad, but certainly no-one sane.
What was said is that you need API transparency, such that, if you later need to add validation that prevents person.name="" from compiling, you don't have to change the clients in any way. In Java, it was not given proper consideration when designing the language, and so the only workaround was to pre-emptively wrap all fields in get/set methods, and only use the latter from other classes, so that, if you ever need to add some code there, you can do so. However, the fault lies squarely with the language here. For example, in Eiffel, public fields are absolutely normal, because field access is indistinguishable from no-arg method call on API client side, so you can always substitute one for another.
(By the way, if anyone tells you that writing one-liner get/set methods which do nothing but directly return or set the field is "encapsulation", it's the best indication that person saying so only knows OOP as a cargo cult, where they use specific words without properly understanding their meaning - as if they were some kind of powerful spells that magically solve problems by merely being mentioned.)
In a previous job, I inherited C# code that had statements like db.open = true. Whaddya think that meant? Why, it opens the db connection, via the setter, of course! And indeed, assigning false...
Would it be any better if it was Java code that had a method named setOpen()?
In reality, it boils down to giving sane (i.e. principle of least surprise) semantics to class members. Whether they are properties explicitly because the language allows it, as in C#, or implicitly defined by their name by convention, as in Java, the expectations are the same. I use a few simple rules to determine if something should be a property:
1. If (foo.Bar != foo.Bar) - i.e. if reading the value twice without doing any other changes to the global state of your system gives two different values - then Bar should not be a property.
2. If, after setting foo.Bar = x, getting it returns something different from x, then Bar should not be a property. This one is arguable, since some people like to put normalization code in property setters - trimming strings, replacing nulls with blanks etc. Personally, I disagree with that practice; however, the rule applies even then, you just need to use the common sense definition of "same" and "different" - i.e. not operator==, but what makes most sense for value domain of that property.
3. If setting foo.Bar = x, for any x, can throw any kind of exception other than the one indicating contract violation by the caller (e.g. in .NET, ContractException, ArgumentException or InvalidOperationException), then Bar should not be a property. A "contract exception" is defined as one that sane callers should never catch (.NET 4+ enforces this by making ContractException internal). Most certainly, something throwing IOException or SqlException or similar things is absolutely not a property.
4. If reading from or writing to foo.Bar cannot be safely done on the UI thread for the fear of blocking it long enough to adversely affect UI responsiveness, it should not be a property. This one is also subjective, since it does not define "long enough" or "adversely affect", but it's one of those cases where you know it when you see it.
Can we please get C with sane declarator syntax? And some form of generic programming? And function literals? And a better-working separate compilation model that doesn't require people to wrap their entire interface declaration in #ifdef/#endif?
Then, yes, we can just program in C.