Slashdot Mirror

← Back to Stories (view on slashdot.org)

Eclipse Launches New Programming Language

Posted by timothy on from the onslaught-of-new-languages dept.

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."

4 of 238 comments (clear)

  1. EMF by prefec2 · · Score: 4, Informative

    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.

    1. Re:EMF by prefec2 · · Score: 3, Informative

      I work at university right now. We have a lot of projects together with software companies. I for myself are in a project were we design a language and tools to develop railway control centers based on programmable logic controllers (PLC) with Funkwerk-IT. That means our target languages are the IEC 61131-3 languages (e.g., FBD, ST). The general idea is, that you can model your railway control business logic in an appropriate language instead of coding it in FBD or ST. Part of the project was the design of a railway topology description language (and meta-model) which has been a valuable input to their own projects.

      In another project about scientific workflows, a colleague of mine is writing an BPNM to BPEL converter in Xtend. And transformations for some scientific workflow notations (SWN). Here the big thing is that SWN are data flow oriented while BPNM and BPEL are control flow oriented.

      A third project is about measuring software properties, based on their code and composition (architecture) and to monitor their run-time behavior. This effort is called MAMBA and will hopefully be presented at CSMR 2012.

      Personally I used Xtend and Xpand a year ago to wrote an application based on JSF/Richfaces and all that stuff and I had to do a lot of similar things in the backing beans for my templates. So I wrote a small Xtext grammar and a generator in Xpand (utilizing also Xtend) to produce this similar code. It gave me quite a boost, as there was now less space for errors. The language itself is ugly and can be made better, but it took me a workday to build it including the generator.

      The best thing about modeling, you can concentrate on the problem domain and forget about the implementation domain while formulating thing for the problem domain. Well, this is not new, XML and XSD went down the same path, however, the EMF tools are better integrated and they are closer to the data processing while XML is closer to data storage (conceptually).

  2. Re:Here comes the injenction by SplashMyBandit · · Score: 3, Informative

    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).

  3. Re:Tell me it ain't C# by shutdown+-p+now · · Score: 4, Informative

    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.