Eclipse komt met nieuwe programmeertaal Xtend

De Eclipse Foundation heeft een nieuwe programmeertaal gebouwd, Xtend geheten. Volgens Eclipse verhelpt Xtend een aantal tekortkomingen van Java. De nieuwe programmeertaal is via een plugin geïntegreerd in de Eclipse-ide.

Volgens Eclipse is Xtend geen Java-vervanger, maar moet het gezien worden als een alternatief in situaties waar Java niet of minder goed zou voldoen. Zo biedt Xtend onder andere ondersteuning voor zogenaamde closures, switch expressions en zijn er extensies beschikbaar voor types.

Xtend biedt volgens Eclipse ook als voordeel dat het veel 'overbodige' elementen uit de Java-syntax weglaat. Hierdoor zou er minder code nodig zijn om applicaties te bouwen, waardoor de code niet alleen beter leesbaar is maar ook sneller kan worden geschreven en makkelijker is te onderhouden.

Xtend-code wordt gecompileerd naar Java-broncode waardoor deze gebruikt kan worden voor debugging. Voor de Eclipse-ide is een Xtend-plugin beschikbaar, zodat ontwikkelaars aan de slag kunnen met de programmeertaal. Eclipse heeft ook documentatie voor zijn nieuwe programmeertaal online gezet.

Reacties (69)

[YopY]

Woepie, nog eentje. Een tijdje terug kwamen de mensen achter de IntelliJ IDEA IDE ook al met een 'java-maar-dan-beter' taal in de vorm van Kotlin.

Maar de vraag is 'waarom'? De Java taal kan inderdaad beter, veel boilerplate, mist wat features etc, maar is het vereenvoudigen van Java daarbij de oplossing, ipv een volledig nieuwe taal te ontwikkelen?

Ik bedoel, ik ben tegenwoordig met Scala bezig, en dat komt me toch een stuk professioneler over - niet van 'kom we maken een taal omdat java sux lol', maar van 'laat onsch functionele programmeerparadigmas combineren met OO' of iets in die trant. En ze zijn niet bang om de Java paradigmas los te laten - dus in plaats van een laagje syntactische suiker wat dit lijkt te zijn bovenop Java hebben ze een nieuwe taal ontwikkeld.

En ook nog korter. Voorbeeldje: op de Xtend website staat een voorbeeldje waarbij je korter een functie kunt definiéren omdat je geen return type hoeft aan te geven:

def getTheListOfNames() {
newArrayList("Tomte","Pippi","Carlson")
}

In Scala is dit korter:

def getTheListOfNames = List("Tomte","Pippi","Carlson")

En gewoon prettiger, imho, omdat er nog minder boilerplate omheen zit en het compacter is. (Dit kan Kotlin overigens ook, maar dat terzijde)

Stiekem moet ik nog eens een dikke vergelijking doen van dit soort nieuwe talen.

Wat mij vooral ontbreekt is het waarom achter de talen vaak. Waarom (weer) een Java-afgeleide maken als die er al zijn in de vorm van bijvoorbeeld Scala?

[RSchellhorn]

De ideeën achter Xtend en Scala verschillen nogal van elkaar. Scala moet je zien als een losse programmeertaal, die toevallig compatible is met Java bibliotheken (en visa versa), tenminste zolang je de JVM en niet de .Net variant gebruikt.
Xtend is, zoals ook op hun website staat, een Java extensie. Een taal naast Java, en maakt dan ook deel uit van het code generator subproject van Eclipse. Het wordt ook al liefkozend de CoffeeScript voor Java genoemd

Op closures na leent Xtend trouwens geen constructies uit het functionele paradigma. Closures zullen bovendien ook worden toegevoegd aan Java 8 (ja! dit keer echt...). Het zijn vooral OO uitbreidingen en verbeteringen. Ook daarmee verschilt het dus van Scala, die beide paradigma's op gelijk niveau plaatst.

Tot voor kort (halverwege dit jaar) was de IDE support voor Scala trouwens ronduit slecht. Een pijnlijk punt wat de meeste nieuwe JVM talen delen. Xtend kent dit probleem in ieder geval niet als Eclipse project. Wel ben ik een beetje bang hoe ik dit in mijn Maven build moet inpassen ...

In je voorbeeld kan je beter een lazy val maken van je lijst. Waarom elke keer een nieuwe immutable lijst aanmaken?

[Kura]

Ik zie het probleem niet zo in het aangeven van returntypes. Wel zo netjes. En nu moet je het alsnog in je documentatie handmatig gaan aangeven dat er een array terugkomt. Kan zijn dat ik iets mis dat dit geen issue is (weinig ervaring met Java).

[Reactie gewijzigd door Kura op 23 juli 2024 18:49]

[YopY]

Daar is ook niet zoveel problemen mee, en je moet het inderdaad opzoeken of achterhalen als je het niet voor je neus hebt. Met goede IDE tools kun je dat echter wel achterhalen, aangezien je in de praktijk niet naar de code van een functie kijkt om te zien wat voor returntype het heeft.

Het is ook alleen maar een issue omdat het weer meer code is dat je moet schrijven. Ik heb genoeg Java gedaan (en zal het in de toekomst waarschijnlijk nog wel vaker doen), en het telkens weer typen van 'public static Map<String, List<String>> wordt op laatst wel saai.

Het is ook eigenlijk niet nodig - als ik ergens een 'return "asdf";' zie, weet ik wel dat de functie een string teruggeeft - en dan kan een compiler dat ook wel bepalen.

Gewoon voor de grap, stukje Java dat een string teruggeeft versus een stukje Scala dat hetzelfde doet:

public static String fietsbel() {
return "asdf";
}

versus Scala, waar ook lekker veel syntactische suiker in zit:

def fietsbel = "asdf"

Scheelt toch weer 2/3e aan code dat je moet schrijven en lezen.

(alleen jammer dat het vijf keer zo lang duurt om te compilen )

[ari3]

Het is ook eigenlijk niet nodig - als ik ergens een 'return "asdf";' zie, weet ik wel dat de functie een string teruggeeft - en dan kan een compiler dat ook wel bepalen.

Dat kan een compiler dus niet. Hoe weet de compiler dat jij bedoelt dat het return type String is? Mischien wil je juist een interface type of een superklasse.

Om het mischien nog beter te illustreren, het volgende:

return new ArrayList();

Als de compiler het return type moet bepalen, hoe doet hij dat dan? Immers kan het return type ArrayList zijn, maar ook een van de interfaces (Collection, List, Iteratable, etc.) of een superklasse (AbstractList, Object, enz.) zijn.

[Verwijderd]

Opzich een goede ontwikkeling waar Google toch ook al mee bezig was ?

Als ze Ecplise nu eens wat gebruiksvriendelijker maken... het is echt een vreselijk pakket (aan het worden)

[bwerg]

Het kan echt vreselijk zijn als iets niet werkt (installatie van plugins etc.) maar zodra het wél werkt vind ik het echt een top-IDE. Veel kleine dingetjes die gewoon heel intuïtief werken.

[Wolfos]

Ik vind het zo'n trage IDE. Sowieso alle IDE's die niet via een native taal werken.
Zelfde geld voor MonoDevelop.

[dev10]

De IDE's van JetBrains werken niet via een native taal (Java) maar werken desondanks snel en goed.

[ZpAz]

Heuj, iemand die het met mij eens is. Zoveel mensen vinden Eclipse of Netbeans "geweldig" en ik vind het een programma met een gare interface. Nee geef mij maar Visual Studio of XCode. Het is dat ik NetBeans voor school moet gebruiken, anders had het er al lang niet meer opgestaan.

[YopY]

De jaren hebben Eclipse inderdaad weinig goeds gedaan. Er komen wel veel goeie ontwikkelingen uit de Eclipse foundation rollen, maar niet een goed afgestemd en performante IDE helaas.

[Verwijderd]

Eclipse is vanaf de beginperiode al erg log en traag geweest. Visual Studio is sinds versie 2010 ook niet meer in een 'native' taal geschreven en dat merk je; als niet de allersnelste hardware gebruikt dan is ook deze IDE niet meer vooruit te branden.

Met Netbeans heb qua snelheid weinig problemen gehad; een IDE waarvan de executable geen 'native' code is en toch niet irritant langzaam is kan dus wel.

[MaestroMaus]

Huh, wat?! Netbeans sneller dan Eclipse? Netbeans is trager op zowel mijn lowspec laptop als mijn highend desktop.

Nouja, zoals hierboven al vermeld: het gaat allemaal om persoonlijke voorkeur. De een vindt Netbeans fijner, de ander Eclipse.

[Wolfos]

Visual Studio is pas bloated. Ding doet er meer dan een minuut over om op te starten, en een project openen is ook niet echt snel.

[Glodenox]

Bedoel je soms de Google App Engine? Die laat je toe om gewone Java code te draaien op de infrastructuur van Google. Google is ook wel met wat eigen talen bezig geweest, maar ik kan me niet herinneren of die ook in de Java runtime draaiden. In elk geval zijn ze volgens mij anders aangezien ze niet compileren naar Java-code, maar rechtstreeks naar Java bytecode.

[OddesE]

Ik denk dat hij Dart bedoelt, het Google alternatief voor Javascript. Maar goed dat is dus niet echt te vergelijken omdat Java en javascript (ondanks de gelijkende namen) twee compleet verschillende talen zijn.

nieuws: Google komt met 'javascript-alternatief' Dart

[Mr_Dark]

Of misschien "Go" (Golang, http://golang.org/) Dit is een compleet nieuwe programmeertaal gebaseerd op C++, C#, Python en Java

[morrowyn]

Ik zou zeggen lever je contributies in bij de eclipse foundation

[Verwijderd]

Ben al overgestapt naar Netbeans...

[Sando]

Bij mij precies andersom, al weet ik niet meer waarom. Netbeans if van Sun/Oracle? Eclipse van iedereen?

Volgens mij vond ik de Eclipse community groter en was dat broodnodig, en ben ik voor PHP ook via Aptana bij Eclipse gekomen.

Is het iemand trouwens wel eens opgevallen dat Flash Builder net als Aptana nogal een subset-ripoff is van Eclipse? Hoe is dat mogelijk, als je bedenkt dat Flash Builder een commerciële tool is? Het zou mooi zijn als je Flash Builder functionaliteit in Eclipse aan de praat kon krijgen, dan kan je lekker devven in Linux.

[R4gnax]

Kun je ook: Flash Builder is namelijk gewoon een plugin voor Eclipse. Deze wordt door Adobe in twee smaken geleverd. Eentje is een totaalpakket, waarbij er inderdaad een kaalgestripte rebranded versie van Eclipse geinstalleerd wordt en de andere is gewoon een plugin die in bestaande Eclipse installaties geinstalleerd kan worden.

[Litpho]

En dingen die niet in OSGI hoeven ook makkelijk buiten OSGI installeerbaar maken (zoals tot voor kort BIRT).

[Blokker_1999]

Kan iemand het volgende eens uitleggen?

Xtend-code wordt gecompileerd naar Java-broncode waardoor deze gebruikt kan worden voor debugging.

Bedoelen ze nu echt dat ze er 'gewoon' terug java code voor maken? maw gewoon een andere syntax maar uiteindelijk eenzelfde resultaat?

[windwarrior]

Java code wordt omgezet naar java byte code, wat vervolgens weer door de virtual machine omgezet wordt naar machinecode.

Xtend code wordt omgezet naar dezelfde java byte code als java zelf, dus draait op alle machines met java geinstalleerd.

[Rinzwind]

In artikel staat xtend code wordt 'gecompileerd' (wat niet klinkt als compileren maar goed...) naar java broncode. Niet bytecode dus.

[YopY]

Het is wél compileren - compileren is het omzetten van de ene taal naar een lager gelegen taal. In het geval van Java gaat het van Java naar Bytecode, dat geinterpreteerd wordt door de JVM en 'on the fly' vertaald wordt naar native / machine code. Xtend pleurt hier nog eens een laag bovenop.

C++ werd van origine ook vertaald / gecompileerd naar C, dat op zijn beurt gecompileerd wordt naar native code.

[merethan]

(wat niet klinkt als compileren maar goed...)

Compileren is in feite niet meer dan vertalen. Eventueel met wat andere functionaliteit als includes enzo boven de code plakken. Wel, dat is hier het geval.

[Verwijderd]

Sterker nog, XTend wordt ook omgezet naar java code (dus niet de byte code). Waardoor het mogelijk is de XTend code als java code te lezen en te gebruiken.

[da Burp]

Ik mag hopen dat ze wel een debugger hebben ontwikkeld voor de XTend code. Dat is meestal het lastige punt met dit soort taal extensies. Er is immers weer een extra mapping nodig van de regels XTend code naar de Java code. Ik kan zo snel niets vinden in de documentatie een debugger. Als je alleen de Java code kan debuggen word je daar als ontwikkelaar niet echt vrolijk van.

[mjtdevries]

Als je op de documentie url klikt in het artikel, dan zie je onderaan twee screenshots die dat heel inzichtelijk maken.

Links de Xtend code, en rechts de Java code die er van gemaakt word.

[Verwijderd]

Ja.

[cornedor]

Vraag me af of een Java applicatie in Xtend minder performance heeft als 1 in puur Java.

[Glodenox]

Het lijkt me wel dat er hier en daar wat vreemdere Java constructies gaan voortvloeien uit deze taal. Maar op het eerste zicht van de documentatie lijkt het me toch dat er een redelijk goede conversie wordt gedaan naar performante Java code. Ik denk dat het performantie-argument dus vooral afhangt van de kwaliteit van de programmeur. Een goede programmeur zal waarschijnlijk in Java de beste oplossing kunnen maken en een iets minder goede zal waarschijnlijk minder slechte code schrijven als hij van Xtend gebruik maakt.

[dtech]

Ik denk dat het wel meevalt. Als de Xtend compiler compiled naar goede java-constructies kan de java-compiler deze goed optimaliseren, voor zover de Xtend zelf niet al efficiente java-constructies kan maken.

Net zoals bij bijv. C->Assembler->Native zijn moderne compilers beter dan programmeurs voor het compilen. Je moet hele goede assembler programmeurs hebben wil je de performance verbeteren.

[Verwijderd]

In theorie maakt dat niet uit. Er is bij java voor gekozen om de compilatie naar byte code zo simpel mogelijk te maken en de jvm de optimalisaties te laten doen bij het interpreteren (of just in time compileren) van de byte code. Aangezien xtend naar de zelfde bytecode compileert heeft het ook de zelfde optimalisaties als elke andere byte code.

Het zou natuurlijk kunnen dat de xtend compiler byte code oplevert die niet efficient door de jvm geoptimaliseert kan worden, maar ik neem aan dat ze daar wel rekening mee zullen houden.

[OddesE]

Aangezien xtend naar de zelfde bytecode compileert

Nee:

Xtend-code wordt gecompileerd naar Java-broncode

Vervolgens wordt die Java broncode weer gecompileerd naar bytecode.

[Verwijderd]

Doet me erg aan Linq denken als ik dit zo lees

http://msdn.microsoft.com/en-us/library/bb397926.aspx

Wel jammer dat ze hiervoor een heel nieuwe programmeertaal verzinnen. Linq is in de .NET talen geïntegreerd. (Hence the name)

[Neverwinterx]

Het doet me erg aan vanalles en nog wat denken. Ze nemen her en der wat van over, ik zie niets nieuws.
Veel dingen kun je al in C# of Scala of consoorten zoals die advanced type inference, closures, operator overloading, extensies, properties.
Meer nog de closures, advanced type inference (voor closures toch) en extensies komen in java 8.
Bij bepaalde keuzes zoals het toelaten van operator overloading stel ik me toch vragen: ik dacht dat we daar onderhand toch van afgestapt waren. Ook types in switch statements: het moedigt alleen maar fout design aan.

[Reactie gewijzigd door Neverwinterx op 23 juli 2024 18:49]

[YopY]

Linq is een library dat gebouwd is op basis van de mogelijkheden van de taal (dwz closures en extension methods en dergelijke) - LINQ was dus alleen mogelijk door de taalfeatures van C# die met de tijd toegevoegd zijn.

En nee, het is geen taal om Linq na te bouwen, andersom juist - linq wordt mogelijk door deze taalfeatures.

[Cyb]

Eén van de vele nieuwe JVM talen. Ik vraag me af wie en of iemand het uiteindelijk gaat winnen. Scala is momenteel de populairste schat ik ruwweg, zowel in de industrie als in de wetenschap. Scala is alleen niet geschikt voor de wat zwakkere programmeur.

[YopY]

Scala is alleen niet geschikt voor de wat zwakkere programmeur.

Eens en oneens. Eens omdat het gewoon zo is, , maar oneens omdat je de standaard Java code ook kunt omzetten naar Scala, maar dan korter. Het wordt pas lastig voor de 'zwakkere' programmeur omdat er heel veel syntactische suiker in zit (woei, operator overloading) en functionele programmeerparadigma's die je maar net moet kunnen begrijpen.

Ik geloof zo dat je elk stukje Scala kunt herschrijven zodanig dat een amateurprogrammeur het ook wel kan begrijpen.

[RSchellhorn]

Scala kent geen operator overloading hoor. Zelfs geen operators! Alles is OO. Dat je functies met een parameter als infix operator mag schrijven is iets anders.

1 + 1 = 1.+(1)

[Neophyte808]

"Xtend-code wordt gecompileerd naar Java-broncode waardoor deze gebruikt kan worden voor debugging."

Dus als ik het goed begrijp is het uiteindelijke geschreven programma nog steeds in Java, is het dus nog steeds geëmuleerd en is multiple inheritance nog steeds niet mogelijk. Nee, ik zie de meerwaarde hiervan niet echt in.

[Devil N]

De meerwaarde zit, mijns inziens, vooral in dat Java gewoon een kuttaal is om in te programmeren, vergeleken bij moderne managed talen zoals bijvoorbeeld C# en Python. En als je bijvoorbeeld voor iets als Android programmeert, waarbij Java een gegeven is (en als de native C SDK je iets te hoog gegrepen is), dan is het wel fijn om een alternatieve JVM taal hebben om voor te kunnen kiezen. Met name als die taal alle fluff en omslachtige rotzooi uit Java omzeilt, zoals Xtend lijkt te doen.

[gimbal]

De meerwaarde zit, mijns inziens, vooral in dat Java gewoon een kuttaal is om in te programmeren

Problem between keyboard and chair. Geen problemen met die taal, simpel en schoon. Het enige wat echt een oppoetsbeurt kan gebruiken is de SDK zelf en daar is Oracle nu net mee bezig binnen het Java 8 platform.

[Devil N]

Seriously, zet die roze bril af en probeer eens wat andere programmeertalen voor de verandering. Dan merk je al snel hoe oubollig en karig Java is aan de ene kant, en overdreven bloated aan de andere kant. Zaken als delegates, closures, lambda expressies, events, properties en extension methods zijn allang standaard prik in de meeste moderne talen. Zelfs C++ is inmiddels al aardig up-to-date in dat opzicht. Java krijgt misschien, toevallig, eventueel volgend jaar iets wat een beetje lijkt op lambda expressies, na jaren van discussies met weinig resultaat.

Ondertussen vereist Java wel dat je ladingen met boilerplate code schrijft voor de meest simpele dingen als bijvoorbeeld property access en event handling. Ja tuurlijk, de meeste IDE's bevatten hiervoor automatische generators, maar als een taal voor z'n dagelijkse workflow zo zwaar leunt op code generatie, dan is er m.i. toch iets fout gegaan in het design van de taal.

Overigens is dit ook exact de reden waarom er zoveel alternatieve JVM talen zijn inmiddels. In de documentatie van Xtend staat letterlijk dat het de bedoeling is om de goede delen van Java te behouden, alle fluff eruit te knippen, en de broodnodige features toe te voegen die Java al lang ontbeert.

[ErrieR]

Klinkt alsof ze Groovy beter hadden kunnen integreren.
Groovy ( groovy.codehaus.org/ ) is een taal die rechtstreeks compileert naar Java, en naadloos integreert met bestaande Java libs/classes. Heeft ook gewenste features zoals closures.

[RSchellhorn]

Groovy is een dynamische taal en (dus) niet direct een alternatief voor het statisch getypeerde Java (en Xtend).

[Squee]

Leuk zo'n nieuwe taal, maar mijn vraag is meteen; hoe zit het met de concurrency support? En eerlijkgezegd kon ik daar zo snel niets over vinden, sterker nog, op geen enkele pagina die ik tot nu toe er over bekeken heb kwam het woord 'concurrency' of 'parallel' in voor... en dat vind ik toch wel vreemd als je een nieuwe taal introduceert in het huidige multi-core tijdperk. Het lijkt me geen slim idee om dan niet vanaf de grond af rekening te houden met concurrency; of je het nou impliciet of expliciet ondersteunt.

Of is het dergelijk object georienteerd dat het meteen een data-parallel implementatie ondersteunt? Is er iemand hier die hier toevallig meer over weet?

[seba]

Als ik het goed begrijp heb je nog altijd de hele java taal ter beschikking en kun je concurrency hetzelfde regelen als in java.

[Fjerpje]

Bah, weer zo'n programmeertaal waar je weer apart iets voor moet installeren.

[Cyb]

Juist niet. Het is een JVM taal, dus je hoeft t.o.v. een PC waar al een JRE op staat, niets extra's te installeren.

[YopY]

Jawel, Eclipse en deze plugin . En waarschijnlijk een compiler om deze code om te zetten naar Java - ik hoop wel dat het een standalone tool is en niet zodanig geintegreerd is in Eclipse dat je het alleen vanuit Eclipse kunt compileren.

[Verwijderd]

Hoe had jij het liever dan gezien? Als een volledige nieuwe programmeertaal waar je een totaal andere compiler voor nodig hebt?

Het enige wat er gebeurt is dat de XTend code omgezet wordt naar java code. De hele taal is eigenlijk een soort syntatic sugar voor Java.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:49]

[Ruudjah]

Nog eventjes geduld. Google ➴ Dart is nu bij 0.0.4, maar bijna wekelijks komt er + 0.0.1 bij.

[sumac]

En dan zijn ze over twee jaar bij 0.0.58? Of wat wil je zeggen?