Gnome: apps in JavaScript hebben de voorkeur
De ontwikkelaars van de Gnome-desktopomgeving stellen dat applicaties bij voorkeur in JavaScript worden geschreven. Het Gnome Project belooft developers te zullen ondersteunen bij het schrijven van Gnome-apps in de scripttaal.
Volgens developer Travis Reitter ontstond er tijdens een recente bijeenkomst van Gnome-developers een discussie over de 'beste' programmeertaal voor het bouwen van applicaties binnen de Gnome-desktopomgeving. Nadat de nodige voorkeuren waren besproken, viel de keuze bij het Gnome Project op JavaScript, een scripttaal die al breed gebruikt wordt voor het bouwen van webapplicaties.
Het Gnome Project stelt dat het bij het opstellen van documentatie voor developers voorrang zal geven aan JavaScript. Daarnaast zullen ontwikkelaars worden aangemoedigd om apps in JavaScript te schrijven en het Gnome Project belooft developers de workflow voor het bouwen van Gnome-applicaties in deze scripttaal te optimaliseren.
De keuze zou op JavaScript zijn gevallen onder andere omdat de prestaties van moderne JavaScript-engines in de afgelopen jaren flink zijn verbeterd. Daarnaast wordt JavaScript breed gebruikt bij de bouw van webapplicaties en ook in bijvoorbeeld Windows 8 worden veel apps gebouwd met behulp van de scripttaal.
Reacties (56)
Heel logisch. Als Gnome dicht bij de web-wereld blijft, is straks niet alleen Android en Unity een kandidaat voor tablets, maar maakt Gnome ook een kans.
Als die-hard C/C++ programmeur ben ik de laatste tijden ook uitstapjes aan het maken naar node.js. Het lijkt mij vooral leuk om applicaties te schrijven die gebruik maken van een framewerk dat naadloos code migreert tussen de browser, mobiele telefoons, servers in de cloud, en gewone desktop PCs. Ik denk dat veel initiatieven in de javascript wereld dit uiteindelijk misschien nog wel mogelijk gaan maken ook. Het bouwen van multi-agent of multi-actor systemen is toch nog wel net ietsje minder flexibel dan straks code over V8 engines heen en weer sjouwen.
Enige opmerking: die engine moet nog veel kleiner. Javascript op een ARM 7 (in een Lego Mindstorms NXT) bijvoorbeeld.
Als die-hard C/C++ programmeur ben ik de laatste tijden ook uitstapjes aan het maken naar node.js. Het lijkt mij vooral leuk om applicaties te schrijven die gebruik maken van een framewerk dat naadloos code migreert tussen de browser, mobiele telefoons, servers in de cloud, en gewone desktop PCs. Ik denk dat veel initiatieven in de javascript wereld dit uiteindelijk misschien nog wel mogelijk gaan maken ook. Het bouwen van multi-agent of multi-actor systemen is toch nog wel net ietsje minder flexibel dan straks code over V8 engines heen en weer sjouwen.
Enige opmerking: die engine moet nog veel kleiner. Javascript op een ARM 7 (in een Lego Mindstorms NXT) bijvoorbeeld.
Verdorie, geen Ruby 
Volgens mij wordt voorbij gegaan aan waar je het voor gebruikt. Heb je geen performance nodig kun je met JS prima werken. Maar laten we niet vergeten waarom de taal is uitgevonden en laten ze het daarbij laten.
C en C++ zijn de performance talen maar ja die hebben nou eenmaal het nadeel dat je wat meer kennis nodig hebt en dat het bouwen van een applicatie meer tijd kost.
De discussie was er eerder ook al tussen de VB en C++ mensen, VB lekker snel en simpel scherm ontwikkelen en C++ heeft de performance.
Waarschijnlijk zal deze discussie altijd wel blijven...
C en C++ zijn de performance talen maar ja die hebben nou eenmaal het nadeel dat je wat meer kennis nodig hebt en dat het bouwen van een applicatie meer tijd kost.
De discussie was er eerder ook al tussen de VB en C++ mensen, VB lekker snel en simpel scherm ontwikkelen en C++ heeft de performance.
Waarschijnlijk zal deze discussie altijd wel blijven...
Het is zonder meer waar dat je voor C++ meer kennis en ervaring nodig hebt om een applicatie te bouwen. Dat het echter meer tijd kost is onzin, als je ervaren bent met C++ kun je daar zeer snel applicaties mee bouwen, en het resultaat is dan ook sneller dan dezelfde applicatie in eein scriptingtaal geschreven.
Scriptingtalen zijn gewoon wat laagdrempeliger voor mensen zonder al te veel programmeerervaring.
Scriptingtalen zijn gewoon wat laagdrempeliger voor mensen zonder al te veel programmeerervaring.
Waarom eigenlijk niet Gnome's eigen programmeertaal: Vala?
Ik vond het idee wel aardig: De syntax van Vala is grotendeels geleend van C# en het compileert onder water naar C, wat door GCC weer naar binaries gecompileerd word. Gebruiksvriendelijke syntax waar iedere C#/Java programmeur mee aan de slag kan en razendsnel. Al gaat dit natuurlijk wel ten koste van de portability en voor debuggen moet je terugvallen op gdb.
Ik vond het idee wel aardig: De syntax van Vala is grotendeels geleend van C# en het compileert onder water naar C, wat door GCC weer naar binaries gecompileerd word. Gebruiksvriendelijke syntax waar iedere C#/Java programmeur mee aan de slag kan en razendsnel. Al gaat dit natuurlijk wel ten koste van de portability en voor debuggen moet je terugvallen op gdb.
In het bron artikel is bij de reacties te lezen dat Vala zeker een goede optie was maar Javascript veel bredere steun heeft om de beschikbare engines sneller en stabieler te maken.
Er zijn enorme development teams bij Mozilla en Google bezig om de Javascript engines steeds maar sneller te krijgen. GNOME heeft niet genoeg mankracht om Vala net zo snel te verbeteren als Javascript nu gaat. Dus denken ze dat Javascript in the long run een betere keuze is dan Vala.
En die argumentatie vind ik zeker niet gek.
Er zijn enorme development teams bij Mozilla en Google bezig om de Javascript engines steeds maar sneller te krijgen. GNOME heeft niet genoeg mankracht om Vala net zo snel te verbeteren als Javascript nu gaat. Dus denken ze dat Javascript in the long run een betere keuze is dan Vala.
En die argumentatie vind ik zeker niet gek.
Toch wel opmerkelijk, omdat bij de ontwikkeling van versie 3 van GNOME zo zwaar werd ingezet op Vala.
Voor mensen met snelheidsproblemen, benchmarks als http://blog.famzah.net/20...php-performance-benchmark en vele andere geven aan dat de snelheid met engine's als v8 etc tegenwoordig erg snel zijn (sneller dan python etc in de meeste gevallen die ik gezien heb). Toegegeven, benchmarks zijn meer theorie dan praktijk, maar als nog laat het een trend zien.
Waarom javascript nogsteeds langzaam lijkt in browsers komt door de DOM, wat voor de rest volledig los staat van javascript zelf. Met dingen als node.js is de performance erg goed en het wordt tegenwoordig gebruikt door bedrijven als linkedIn en yahoo.
Waarom javascript nogsteeds langzaam lijkt in browsers komt door de DOM, wat voor de rest volledig los staat van javascript zelf. Met dingen als node.js is de performance erg goed en het wordt tegenwoordig gebruikt door bedrijven als linkedIn en yahoo.
Interessant hoe mensen zich laten leiden door het gebruik van JavaScript in verschillende browsers, die verschillende API 's aanbieden.
JavaScript is een flexibele, elegante taal waarmee je redelijk vlug uit de voeten kan. Zie http://en.wikipedia.org/wiki/JavaScript voor een.aantal interessant features, zoals dat je als je wil volledig functioneel kan programmeren.
Bijv. NodeJs http://nodejs.org/ is een voorbeeld waar Javascript voor servergerichte zaken wordt gebruikt, en met succes
JavaScript is een flexibele, elegante taal waarmee je redelijk vlug uit de voeten kan. Zie http://en.wikipedia.org/wiki/JavaScript voor een.aantal interessant features, zoals dat je als je wil volledig functioneel kan programmeren.
Bijv. NodeJs http://nodejs.org/ is een voorbeeld waar Javascript voor servergerichte zaken wordt gebruikt, en met succes
[Reactie gewijzigd door 12013 op dinsdag 5 februari 2013 14:34]
"Wordt al door veel mensen gebruikt" is ook echt de enige reden die ik kan verzinnen om voor JavaScript te gaan. "De engines zijn beter geworden" is een non-argument.
Okee, een scripttaal is misschien ook handig voor platformonafhankelijkheid en om makkelijker en sneller applicaties te kunnen bouwen. Maar dan is Python volgens mij nog een logischer keuze.
Okee, een scripttaal is misschien ook handig voor platformonafhankelijkheid en om makkelijker en sneller applicaties te kunnen bouwen. Maar dan is Python volgens mij nog een logischer keuze.
Tijden veranderen. Ik kan er niet direct negatief over zijn. Wel wat huiverig daar gezien Javascript naar mijn mening (nog) niet volwassen genoeg is.
Ik denk persoonlijk dat het geen foute beslissing is, wel wat vroeg nog.
Ik denk persoonlijk dat het geen foute beslissing is, wel wat vroeg nog.
Ik zou eerder C(++) verwachten. Wel wat moeilijker programmeren maar wel bloedje snel.
Tegenwoordig zijn bijna alle GNOME apps nog in C geschreven. Maar GUI apps in C schrijven is geen pretje.
Tuurlijk, C is veel sneller dan Javascript of Python, of een andere geinterpreteerde taal, maar die snelheid heb je zelden nodig bij grafische apps. Daarnaast ben je veel sneller klaar als je een grafische app maakt in Javascript dan als je hem in C maakt. Mocht je echt de snelheid nodig hebben kan je altijd in C een library maken met de functies die echt performant moeten zijn, en die zijn dan vrij eenvoudig aan te roepen in Javascript, door middel van GObject introspection.
Persoonlijk vind ik Python een mooiere taal, maar Python is heel moeilijk te sandboxen. De GNOME ontwikkelaars willen namelijk graag de touwtjes in handen hebben, en willen dus dat je vooral de GNOME libraries gebruikt voor bijv. File I/O, networking en andere zaken. Bij Javascript kan je dit heel makkelijk forceren door simpelweg alleen de GNOME libraries beschikbaar te maken in de omgeving, by Python is dat veel moeilijker te forceren.
Tuurlijk, C is veel sneller dan Javascript of Python, of een andere geinterpreteerde taal, maar die snelheid heb je zelden nodig bij grafische apps. Daarnaast ben je veel sneller klaar als je een grafische app maakt in Javascript dan als je hem in C maakt. Mocht je echt de snelheid nodig hebben kan je altijd in C een library maken met de functies die echt performant moeten zijn, en die zijn dan vrij eenvoudig aan te roepen in Javascript, door middel van GObject introspection.
Persoonlijk vind ik Python een mooiere taal, maar Python is heel moeilijk te sandboxen. De GNOME ontwikkelaars willen namelijk graag de touwtjes in handen hebben, en willen dus dat je vooral de GNOME libraries gebruikt voor bijv. File I/O, networking en andere zaken. Bij Javascript kan je dit heel makkelijk forceren door simpelweg alleen de GNOME libraries beschikbaar te maken in de omgeving, by Python is dat veel moeilijker te forceren.
En deze constructie, hoevaak kom je dat tegen? Waarom zou ik hiervoor geen class gebruiken? Waarom wil je eigenlijk uberhaupt een variabele uit een andere functie wijzigen? Ik denk dat dat meer zegt over het ontwerp van jouw programma dan over het ontwerp van de taal Python.
Door de gebrekkige indentatie is het niet duidelijk (waarom werkt [code] niet op de frontpage?), maar het is niet zo zeer een variabele uit een andere functie dan een variabele uit een bovenliggende functie door een geneste functie. In Javascript is dit zeer gebruikelijk, en in zekere zin een ander programmeer-paradigma. In Python 3 kan dit zonder problemen, in Python 2 moet je iets beter je best doen.
Of je het wilt is een ander verhaal natuurlijk, maar in Javascript kom je dergelijke constructies ontzettend vaak tegen. En ook in closures, waar deze methode nog veel belangrijker is eigenlijk.
Of je het wilt is een ander verhaal natuurlijk, maar in Javascript kom je dergelijke constructies ontzettend vaak tegen. En ook in closures, waar deze methode nog veel belangrijker is eigenlijk.
Geen probleem:
def test():
count = 0
def f(l):
nonlocal count
for i in l:
count += i
f([10, 20, 30])
return count
print(test())
[Reactie gewijzigd door MadEgg op woensdag 6 februari 2013 07:34]
Hmm... okee ik zie dat er een nieuw keyword aan python 3.0 is toegevoegd. Gefeliciteerd 
Maar dit is natuurlijk een "hack" van de Python makers achteraf... het is niet dat ze hiermee rekening hebben gehouden bij het ontwerp van de taal. Dus "mooi" is wat mij betreft anders...
Volgende uitdaging: probeer dit dan eens in Python < 3.0
Maar dit is natuurlijk een "hack" van de Python makers achteraf... het is niet dat ze hiermee rekening hebben gehouden bij het ontwerp van de taal. Dus "mooi" is wat mij betreft anders...
Volgende uitdaging: probeer dit dan eens in Python < 3.0
In Python 2 kan het ook, maar dan wordt het wat hackier. In Python 3 is het nonlocal statement met een reden toegevoegd, om dit (beter) mogelijk te maken.
Ook in Python 2 heb je wel toegang tot variabelen in een hogere scope, maar dan (in beginsel) uitsluitend read-only. Doe je een assignment (zoals count += i) dan wordt aangenomen dat count een variabele in de huidige scope is. Dat kun je voorkomen door niet rechtstreeks aan count toe te kennen, maar aan onderdelen daarvan. Een oplossing is dan:
Ook in Python 2 heb je wel toegang tot variabelen in een hogere scope, maar dan (in beginsel) uitsluitend read-only. Doe je een assignment (zoals count += i) dan wordt aangenomen dat count een variabele in de huidige scope is. Dat kun je voorkomen door niet rechtstreeks aan count toe te kennen, maar aan onderdelen daarvan. Een oplossing is dan:
Doordat count een list is en je de teller in het eerste element in die lijst bijhoudt ziet hij de de statement 'count[0] += i' niet als een assignment aan count maar als assignment aan 'count[0]', waardoor dit wel werkt. Mooi is anders, maar extreem lelijk is het nou ook weer niet.def test():
count = [0]
def f(l):
for i in l:
count[0] += i
f([10, 20, 30])
return count[0]
print test()
Je bent geslaagd
Maar idd mooi is anders, en dat was mijn oorspronkelijke punt
Dat "nonlocal" is er eigenlijk maar als een afterthought bijgeklust door de bedenkers van Python.
Maar idd mooi is anders, en dat was mijn oorspronkelijke punt
Dat "nonlocal" is er eigenlijk maar als een afterthought bijgeklust door de bedenkers van Python.
Bloedje snel is niet echt nodig in de meeste desktop-applicaties. Maar volgens mij is het al een crime om een rich-text editor te maken met JavaScript, laat staan ingewikkelder applicaties.
Als je snel moet, kun je volgens mij nog steeds wel met C++ terecht. Het artikel zegt dat de voorkeur wordt gegeven aan JS.
Als je snel moet, kun je volgens mij nog steeds wel met C++ terecht. Het artikel zegt dat de voorkeur wordt gegeven aan JS.
Rich text editing is een van de meest ingewikkelde applicaties denkbaar.
Toch kun je rich text editors in alle soorten en maten voor niets krijgen, dus ik denk dat dat niet helemaal waar is.
Er zijn bijna geen rich text editors te vinden die ook daadwerkelijk goed werken. Sterker nog, eigenlijk alles wat wel goed werkt, valt op de een of andere manier terug op het weergeven van code (zoals wikitext, bbCode of HTML) en is dus geen echte WYSIWYG-oplossing.
Gnome is zijn eigen graf aan het graven met dit soort onzinnige beslissingen. Op den duur gaat nog blijken dat Canonical gelijk heeft met zijn strategische keuzes van de laatste tijd.
Zou leuk zijn als je de andere reacties leest of tenminste uitlegt waarom dit onzinnig is. GNOME shell is grotendeels in javascript geschreven enzo.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
