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."
I like it. It looks like they've taken the power of C/C++ macros, wrapped it up in a clean simple syntax, and applied it to Java.
When I first started programming in Java, I was at a loss without my macros. The concept of macros and code expansion are so powerful, but often overlooked because they can be hideously difficult to debug and enhance.
I do not fail; I succeed at finding out what does not work.
Does it do anything that Groovy or Scala don't already?
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 ..."
Seems like cool language. Much like Spring and the new JVM languages, it seems like this exists primarily to address shortcomings that Java has because it hasn't come out with new versions for so long.
Eclipse already writes a lot of Java for you, so this seems like a natural extension. Of course, this is a ridiculous state of affairs. When a most code in a language is boilerplate, it's time for a new version, that takes care of that for you. I mean could you imagine anyone releasing a Java-like language today that didn't have first class treatment of properties, didn't have syntax for applying a function to every member of a collection, and didn't have better type inference?
It's interesting that it compiles to Java, I don't think it'll be long before, it'll start to completely skip the Java phase.
Democracy Now! - your daily, uncensored, corporate-free
"but"? I think you meant "Also". :P
I read TFA and all I got was this lousy cookie
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.
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).
To have the .NET framework backwards compatible (like Java) you'll need to have all .NET frameworks installed which requires 4 GB. In what universe is that lightweight?
Yes. Java was (and is) a lot faster than Smalltalk. Sorry, but that *is* significant.
Of the languages that you list, only Lisp is faster, or even nearly as fast as, Java. And Lisp is hard to wrap your mind around. (And here I'm assuming that you mean compiled Common Lisp.) Also, in the early years of Java, a free compiler was unusual. Having a language with a free compiler was a real win. That's much less a consideration now, but now that shape of the language landscape has a lot more inertia.
I think we've pushed this "anyone can grow up to be president" thing too far.
Well. This would be possible. The predecessor of Xtend (2) was Xtend (1) and Xpand which are the sucessors of the openArchitectureWare transformations. And 3-5 year of Xtend or oAW experience is possible. Nevertheless, I am waiting for some dumb job offer writing just like the one you sketched ;-)
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.
.NET runtime is lightweight? I wouldn't count windows, xbox, and wp7 as 'multiplatform.'
"Many people, even some IDEs, insist on generating getters and setters, even when there isn't a JavaBean in sight."
Yes, but that's precisely to cater to the case that in future, there may be a need to do something else. It's partly more problematic with Java because in C# it's quick and easy to do:
public string Name { get; set; }
Whilst in Java, it of course takes longer and creates more code clutter to do:
private string _name;
public getName() { return this._name; }
public setName(string name) { this._name = name; }
Of course, C# properties aren't perfect, unless you do things in a more Java-esque way and don't use the automatic properties feature of C# 3.0 they force you to instantiate back in the constructor which is one of my bugbears with it, although some would argue that's how it should be done anyway.
The issue is largely that if you change simple fields into properties (or getter/setter pairs in Java) later on because you genuinely do need to do something when the variable is read or set then it can be a breaking change, by doing it from the outset then that's not the case. It's about minimising the potential impact of future changes, and you simply never know how long your code will be out there how it will be used, how it's use will change. Getters and setters insulate from that.
"The database open assignment was a case in point. It should just have been something like conn.dbOpen()"
This IMHO was an example of bad use of properties, see point 3 of shutdown -p's original response to you as to why, not to mention the risks you potential face by way of resource cleaning in doing this sort of thing. Anything can be misused, but I do not believe it's a fair argument against the feature, because the feature in the hands of competent developers certainly leads to much better code. I'm not a fan of catering to the lowest common denominator, HTML5 does this and it's an awful spec with so many missed opportunities (i.e. it makes accessibility worse, it lowers software development quality standards reducing maintainability etc.) - effectively it makes crap markup standard make crap, poorly maintainable, poorly accessible markup standards compliant, rather than raising the standard to allow things to move forward as XHTML has done by increasing the amount of XML parsable (even if not served as XML) markup out there.