Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Nieuws » Pro » Development » Eclipse komt met nieuwe programmeertaal Xtend

Eclipse komt met nieuwe programmeertaal Xtend

Door Dimitri Reijerman, zondag 6 november 2011 12:26, views: 22.177

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.

Extend logoVolgens 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.

Volgende 13:04 Hack laat navigatie-app Nokia op andere WP-toestellen werken
Vorige 11:33 Tonido komt met energiezuinige plugserver TonidoPlug2
Advertentie

Categorieën

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 69 reacties zichtbaar690 Off-topic / Irrelevant: 68 reacties zichtbaar68+1 On-topic: 48 reacties zichtbaar48+2 Informatief: 2 reacties zichtbaar2+3 Spotlight: 0 reacties zichtbaar0
«  1  2  »

Door RutgerM, zondag 6 november 2011 12:27

Score: 1
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)

Door morrowyn, zondag 6 november 2011 12:39

Score: 0
Ik zou zeggen lever je contributies in bij de eclipse foundation

Door RutgerM, zondag 6 november 2011 13:03

Score: 0
Ben al overgestapt naar Netbeans... :)

Door Redsandro, zondag 6 november 2011 21:08

Score: 1
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.

Door R4gnax, maandag 7 november 2011 08:54

Score: 1
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.

Door bwerg, zondag 6 november 2011 12:48

Score: 1
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.

Door Wolfos, zondag 6 november 2011 13:30

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

Door ZpAz, zondag 6 november 2011 13:34

Score: 0
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.

Door YopY, zondag 6 november 2011 15:06

Score: 0
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.

Door de Zeester, zondag 6 november 2011 15:26

Score: 1
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.

Door MaestroMaus, maandag 7 november 2011 08:18

Score: 1
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.

Door Wolfos, maandag 7 november 2011 19:05

Score: 0
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.

Door dev10, zondag 6 november 2011 14:41

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

Door Glodenox, zondag 6 november 2011 12:48

Score: 1
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.

Door OddesE, zondag 6 november 2011 19:31

Score: 1
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

Door Mr_Dark, zondag 6 november 2011 21:57

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

Door Litpho, zondag 6 november 2011 15:51

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

Door cornedor, zondag 6 november 2011 12:28

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

Door Glodenox, zondag 6 november 2011 12:36

Score: 1
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.

Door dtech, zondag 6 november 2011 18:04

Score: 1
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.

Door elbo, zondag 6 november 2011 16:40

Score: 1
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.

Door OddesE, zondag 6 november 2011 20:48

Score: 1
Aangezien xtend naar de zelfde bytecode compileert
Nee:
Xtend-code wordt gecompileerd naar Java-broncode
Vervolgens wordt die Java broncode weer gecompileerd naar bytecode.

Door sanderev66, zondag 6 november 2011 12:35

Score: 1
Doet me erg aan Linq denken als ik dit zo lees :p

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)

Door Neverwinterx, zondag 6 november 2011 13:33

Score: 1
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 zondag 6 november 2011 13:51]

Door YopY, zondag 6 november 2011 15:08

Score: 1
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.

Door Fjerpje, zondag 6 november 2011 12:46

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

Door Ruudjah, zondag 6 november 2011 12:49

Score: 0
Nog eventjes geduld. Google ➴ Dart is nu bij 0.0.4, maar bijna wekelijks komt er + 0.0.1 bij. ;)

Door sumac, zondag 6 november 2011 14:52

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

Door TeMo, zondag 6 november 2011 12:49

Score: 1
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 TeMo op zondag 6 november 2011 12:52]

Door Cyb, zondag 6 november 2011 14:29

Score: 1
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.

Door YopY, zondag 6 november 2011 15:10

Score: 1
Jawel, Eclipse en deze plugin :p. 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.

Door Blokker_1999, zondag 6 november 2011 12:54

Score: 1
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?

Door windwarrior, zondag 6 november 2011 13:01

Score: 1
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.

Door TeMo, zondag 6 november 2011 13:26

Score: 1
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.

Door da Burp, zondag 6 november 2011 14:42

Score: 1
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.

Door Rinzwind, zondag 6 november 2011 13:36

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

Door YopY, zondag 6 november 2011 15:12

Score: 1
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.

Door merethan, zondag 6 november 2011 15:57

Score: 1
(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.

Door mjtdevries, zondag 6 november 2011 13:47

Score: 1
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.

Door y-pop, zondag 6 november 2011 13:52

Score: 0
ah CoffeeScript voor Java, nice

Door Dykam, maandag 7 november 2011 11:20

Score: 0
Echter wel statisch, met flexibiliteit door middel van type inference.

Door Zidane007nl, zondag 6 november 2011 14:00

Score: 0
Ze hadden beter Eclipse kunnen verbeteren. Het installeren van plug-ins duurt vaak erg lang ...

Door hackerhater, zondag 6 november 2011 15:01

Score: 0
Het installeren er nog aan toe.
Had veel liever dat ze eens wat aan die dependancy hell deden

Door YopY, zondag 6 november 2011 14:02

Score: 2
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?

Door dokzero5, zondag 6 november 2011 14:31

Score: 1
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 dokzero5 op zondag 6 november 2011 14:46]

Door YopY, zondag 6 november 2011 15:16

Score: 1
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 :p)

Door ari3, zondag 6 november 2011 23:53

Score: 1
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.

Door RSchellhorn, zondag 6 november 2011 16:04

Score: 2
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?

Door ErikKo, zondag 6 november 2011 14:03

Score: 0
Waar is de bron dat dit nieuw is? Ik heb hier ruim een jaar geleden al een keer mee gewerkt.
Het is overigens een erg eigenaardige taal. Voor programmeurs zal het alles behalve intuitief werken.

Door _Erikje_, zondag 6 november 2011 14:09

Score: 0
Het getting started voorbeeld op de xtend site slaat helemaal nergens op. Hoe omslachtig kan je dat stukje java schrijven. Daarnaast het gebruik van underscores voor de variabele naam 8)7

doe een eerlijke vergelijking of doe geen vergelijking.

Snap niet waarom ze contributen aan groovy???

Door Cyb, zondag 6 november 2011 14:25

Score: 1
Hoe omslachtig kan je dat stukje java schrijven
Het gaat om generated code. Iets wat de underscores expliciet duidelijk maken.
Snap niet waarom ze contributen aan groovy???
Groovy is slechts één van de velen.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 13:04 Hack laat navigatie-app Nokia op andere WP-toestellen werken
Vorige 11:33 Tonido komt met energiezuinige plugserver TonidoPlug2
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011