Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
Java Programming IBM

Eclipse Launches New Programming Language 238

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

Eclipse Launches New Programming Language More

Eclipse Launches New Programming Language

Comments Filter:

  • I like it (Score:3)

    by msobkow ( 48369 ) on Saturday November 05, 2011 @01:43PM (#37959250) Homepage Journal

    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.

    • Re: (Score:2)

      by msobkow ( 48369 )

      It's interesting to see Java replacing C as the back-end of compilers, though many still prefer the "Assembly" approach of producing JVM byte-code instead.

    • Re: (Score:2)

      by nepka ( 2501324 )

      The concept of macros and code expansion are so powerful, but often overlooked because they can be hideously difficult to debug and enhance.

      And leads to extremely bad code. Goto has the same thing - it can be extremely powerful, but overusing it leads to really bad code.

      • Re: (Score:2)

        by siride ( 974284 )

        If you use C-style macros. Lisp-style macros are a lot better.

      • Re:I like it (Score:4, Interesting)

        by onefriedrice ( 1171917 ) on Saturday November 05, 2011 @02:56PM (#37959808)

        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.

        • The problem with languages with macros is that unlike, say, Smalltalk, you generally never know when macros might apply when and so change the meaning of what you are looking at unless you understand the *entire* program...

        • Re: (Score:2)

          by HiThere ( 15173 )

          Sorry, but it's not just people who are new to programming that use macros to make their code unintelligible. I've known some really foul examples that had been programming professionally for over a decade. I've got to assume that the macros fit in with how they thought about the code, because (well, in at least one case) he could pick up the code 6 months later and still readily understand it. But nobody else could.

          For that matter, back in the days that structured programming was still fighting to get e

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      The concept of Lisp macros and code expansion are so powerful, and they are easier to debug and maintain because they are not merely a matter of replacing strings (rather, the postponing of evaluating a lisp form so that you can modify the language).

    • Optional parentheses, optional semicolons...this is a neckbeard flamewar in the making.

    • Me too, for use with the Java ecosystem. They've taken some good ideas from Jython and Smalltalk. I wonder how smooth debugging is though?

    • Re: (Score:2)

      by msobkow ( 48369 )

      The key power C macros had over any Template-type construct I've seen is that you can actually paste the name of the macro arguments to form unique variable names within the macro. So a single macro could expand to three or four different functions, a handful of variables, etc.

      Yes, people are prone to hanging themselves by abusing macros, but you can do some wicked code simplification that expands inline to maximize performance. I had macros in my library of useful stuff that turned all the declaration

  • Groovy / Scala (Score:2, Interesting)

    by Anonymous Coward

    Does it do anything that Groovy or Scala don't already?

    • Re: (Score:2)

      by prefec2 ( 875483 )

      Xtend is merely designed for model to model and model to text transformations. Yes you can also use it for other tasks. And yes Scala has some similar concepts.

    • Compile to readable Java code instead of jvm bytecode? Also I wouldn't really lob Scala in the same bag, it is a rather different animal, if you ask me.

    • Re: (Score:2)

      by osu-neko ( 2604 )

      Does it do anything that Groovy or Scala don't already?

      Does any language do anything that any other Turing-complete language doesn't do? Doesn't seem like a sensible question. A more intelligent question would be, "Does it do anything differently?" And yes, it does.

    • simple answer... no. And groovy is easier to read and code.

    • That was my first question too, comparing to Groovy. I think the answer is that Groovy has significant runtime requirements (notably dynamic typing and invocation) whereas Xtend appears to purely compile down to plain Java. I suspect that means that you can run it in an ordinary container without extra tooling like Groovy. But a cursory look at the docs suggests that they do have some runtime library requirements (I see a StringConcatenation class and an InputOutput class, for example)

  • Eclipse (Score:5, Funny)

    by ZankerH ( 1401751 ) on Saturday November 05, 2011 @01:58PM (#37959382)
    The "You want performance? Fuck you, have more features instead!" of IDEs.

  • Java needs new versions (Score:3, Interesting)

    by bigsexyjoe ( 581721 ) on Saturday November 05, 2011 @02:06PM (#37959432)

    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.

    • it seems like this exists primarily to address shortcomings that Java has because it hasn't come out with new versions for so long.

      Yes, because 100 days [convertunits.com] is a very long time.

      • 7 was almost a minor revision when compared to anything Microsoft is doing, or with 1.5 and 6. 7 actually looked promising at first, but pretty much every single feature that seemed like a game changer was delayed.

        There's tons and tons of libraries out there that try to emulate what other languages can do, and do it with horrible style due to Java's approach to syntax. Just look at Guava Collections: A large array of workarounds for features that the language should support. But predicates that come with a

      • Most important features users expected from Java 7 have been pushed back to Java 8. Which will come out next year. Maybe. And which will be required to preserve backward compatibility with previous source, forcing hard compromises to be made (see generics in 1.5). Real improvements to Java will now be be mostly on the JVM, to help these new languages grow, as Java the language painted itself in a corner a while ago.

  • EMF (Score:5, Informative)

    by prefec2 ( 875483 ) on Saturday November 05, 2011 @02:11PM (#37959454)

    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.

    • What kind of models do your applications support, and in which industry (or industries) are they used?

      I'd love to hear about how one gets to be an expert in model-driven programming.

      • Re:EMF (Score:4, Informative)

        by prefec2 ( 875483 ) on Saturday November 05, 2011 @05:19PM (#37960792)

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

        • Cool! I'll have to try it in my work at modelling schedules for railways and other transport networks.

    • However the article's Xtend is something different than Xtend (2.0) from the open architecture ware stack that you are using ;D

      Even if you are as deep into it as you are, it helps to read the damn article.

      Which opens the question: why the fuck is that Eclipse project called Xtend and not something different?

      • Re: (Score:3)

        by prefec2 ( 875483 )

        Well the interesting thing is: I was talking about http://www.eclipse.org/Xtext/#xtend2 [eclipse.org] which looks for me by any definition exactly like http://www.eclipse.org/Xtext/xtend/ [eclipse.org] . However, xtend2 is different from xtend+xpand which were its predecessors [http://www.eclipse.org/modeling/m2t/?project=xpand]. So reading the news (again), I found out that the Eclipsians see the language in a quite different light as the modeling guys from itemis. But I am absolutely sure that this is the same language. Otherwise I

        • Hm,
          but we are talking about: http://www.eclipse.org/Xtext/xtend/ [eclipse.org] (this article)
          And (you): http://www.eclipse.org/Xtext/ [eclipse.org]

          Or not? For me this new Xtend does not look like anything from oAW ... but I'm only an interested follower not a user of oAW, so I might be mistaken.

          • Re: (Score:3)

            by prefec2 ( 875483 )

            Yes it is different from the old oAW stuff. However, the Xpand language is now part of this new Xtend. You can use guillemont-expressions in text expression e.g., '''Some Text >''' which is a Xpand-Expression inside the '''...'''. However, all the foreach macros and templates form Xpand are gone, as there are similar constructs in Xtend.

  • Scalability and performance are important.

  • Since when did that language become significant?

    Also, bad analogy. CaffeeScript compiles to JavaScript source code. This new language from Eclipse compiles to Java bytecode (just like Groovy, Scala, +various other languages).

    • Re: (Score:2)

      by prefec2 ( 875483 )

      nope. Xtend compiles to Java, which is compiled to JVM byte code.

    • Since when did that language become significant?

      Since some languages have started to lag more than a decade behind other languages, and since people have realized that certain language features (e.g. closures) lead directly to better designed libraries.

      • I'm pretty sure JavaScript has closures.

        • JS does, yes. Java does not, which is what the language described in TFS adds to it (among other things).

          That said, JS is missing many other things that help writing good libraries. A module system, for one.

          • And my question was

            Since when did that language [CoffeeScript] become significant?

            And even besides that. I also mentioned Groovy and Scala, both target JVM had contain closures.

  • I got the tutorial project created, but I don't see an option to compile/run it as Xtend?

    • This kind of hints at generatign Xtext language artifacts?
      http://www.eclipse.org/Xtext/documentation/2_1_0/035-domainmodel-java.php [eclipse.org]

      Anyway, what gives? I guess the Eclipse people just assume people can figure out how to compile some new language in Eclipse? Or figure out how to use Xtext and somehow understand how Xtend related to it?

      Or maybe something went wrong related to the install? I had to guess from about 20 packages which to install with various combinations of stuff with different versions.

      So, still

    • Re: (Score:2)

      by prefec2 ( 875483 )

      I did not play with your tutorial. However, in most cases there is a file with a *.mwe2 extension (or similar). Right click on it and choose under Run as ... the option run as MEW workflow.

      • Thanks. Sadly, I can't find a file with a mwe2 extension in the Xtend tutorial project.

      • OK, I got it working. Basically, I (think I) must have installed just the runtime and UI parts. I assumed Eclipse would take care of dependencies. So, nothign ran. Then I tried again and installed more modules, but the turotial still did not work. Then I dleeted the tutorial project, and remade is as an example. And now it works.

    • I got it working; see my other comment here, but basically I did not have all the required modules installed. The download instructions could be a lot clearer on exactly what you should be installing. I think I ended up with just the UI and SDK the first time.

  • I don't care about type inference. My IDE does a good job. And I like static typing. But well, the language has closures and typed switches, so why not. But then the set/get feature.

    First we got told that writing person.name = "John" is bad. Bad, bad, bad. I never understood why. Sure, getters and setters are very useful, beans and all, and it can take away some trouble, but if you really need a function that does more than change the value of field x, why call it setX()?

    Anyway, that's the current practice:

    • Just be thankful it does not use white space as a block closure.

    • Re:Tell me it ain't C# (Score:5, Informative)

      by shutdown -p now ( 807394 ) on Saturday November 05, 2011 @04:48PM (#37960532) Journal

      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.

      • Re: (Score:2)

        by tgv ( 254536 )

        You're completely right, but the lunatics are running the asylum sometimes. Many people, even some IDEs, insist on generating getters and setters, even when there isn't a JavaBean in sight.

        Your points about properties are all true, but a subset of what I would like to see: namely that an assignment operator just performs an assignment, and nothing else. The database open assignment was a case in point. It should just have been something like conn.dbOpen(). We might have conventions for function names that d

        • a subset of what I would like to see: namely that an assignment operator just performs an assignment, and nothing else.

          I think it's perfectly reasonable for assignment operator to also perform validation, and raise property change notifications. Also, in case of computed properties, an assignment to one (if computation is two-way) can reasonably recompute the source, unless it's an expensive operation.

        • Re: (Score:3)

          by Xest ( 935314 )

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

  • Lets take C, wrap it in C, then wrap that in C and then wrap the whole thing in yet more C.

    Can we please just program in C?

    • Re:Yet Another C Variant (YACV) (Score:5, Insightful)

      by shutdown -p now ( 807394 ) on Saturday November 05, 2011 @04:49PM (#37960542) Journal

      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.

      • C seems pretty sane to me. Just about everything you really depend on is written in C. The linux Kernel is written in C.

        And just about every language that supports those things you plead for is written in C.

        Can we please just write in C

        Generics are ughhh. They introduce more trouble then they are worth. They are clever though.

        Function literals? Pointer to a function much?

        Sane? Please! gimme a break.

        • C seems pretty sane to me.

          Did you see any other similar low-level languages to compare to? Say, Modula-2?

          Just about everything you really depend on is written in C. The linux Kernel is written in C.

          That's because C happened to be in the right time at the right place, and by now became pretty much the only language in its low-level niche. It doesn't make it perfectly designed for that niche, however.

          Generics are ughhh. They introduce more trouble then they are worth.

          It seems that you're thinking of Java generics, but the term itself is (pardon the pun) more generic than that. And what's "ugh" about them? They cover many use cases which are done with macros in vanilla C, but do so in a much m

  • Just what we need....

  • This is not compiling for me starting with the "static":

    class Test2 {
            static main(String[] args) {
                    println("hello");
            }
    }

    Too bad they don't provide a simple hello world example anywhere that is easy to find.

  • This will be used to create another pointless layer of abstraction away from the real (non-eclipse) world. At the end of every day I am do glad I don't have to touch that POS for another 18 hours. Consider this: during development eclipse loads classes directly from class files, while applications operationally load from jar files. There is no way to tell eclipse to load its classes in exactly the same was as an operational system, and no way to know for sure which classes will be loaded.

    Rubbish.

    • Well,

      that is not Eclipse ... it is just a classpath issue. After all if you launch a program from Eclipse for debugging it is generally running inside of its own JVM.

      I suggest you try to get a grasp what a classpath is (and what a PATH is a MANPATH and a LDPATH etc.)

      If you have trouble how to configure your classpath in Eclipse ask a coworker.

      As a hint, check the .clasthpath file in your project. There is no need to be able to write such an XML file, but you should easily see that the classpath is composed

  • I'm not interested in some tweaks to syntax that save a few lines I type automatically (or that Eclipse could automatically generate) in Java already. The overhead of learning a new language at all, with its typos and brainos, is bigger than any productivity or accuracy benefit it brings.

    What would be useful would be a language that deterministically compiles to a runnable logic graph, and back from flowchart to text, that's as straightforward to program lexically in as Java, which we already know. And that

Slashdot Top Deals

Last yeer I kudn't spel Engineer. Now I are won.

Close