Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 56 reacties, 11.760 views •

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.

Gnome logoHet 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)

Reactiefilter:-156055+139+210+31
Moderatie-faq Wijzig weergave
Ik vind het een goede en verstandige keuze. Javascript is sneller dan python door de moderne engines, iedereen kan het schrijven, en het brengt geen gui security problems met zich mee zoals qt4 in c++. Daarnaast is customizability vaak lastig, maar met javascript kan dit prima.

De functionele backends zullen overigens nog gewoon in c en c++ geschreven worden dus met snelheid zit het echt wel in orde.
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.
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.
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.
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:
def test():
count = [0]

def f(l):
for i in l:
count[0] += i

f([10, 20, 30])
return count[0]

print test()
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.
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
:)
Dus ook sneller door kwaadwillige n. Die melden een bug / exploit dus niet maar gebruiken het zelf.

/doomdenker
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 6 februari 2013 07:34]

Verdorie, geen Ruby :-(
Exact, dat is ook De Wet van Gates.

(Er was geen apart artikel op de Wiki, wel een vergelijkbare)

http://en.wikipedia.org/wiki/Wirth%27s_law

edit: Whoeps, dit was een reactie op Redsandro :P

[Reactie gewijzigd door ik.ben.iemand. op 5 februari 2013 15:39]

(..) dus waarom zou het geen volwaardige programmeertaal zijn?
Het voelt toch met veel dingen nog steeds niet efficiŽnt. Check de Dune 2 port of die Amiga Emulator. Dat je met javascript een chip van een kwart eeuw geleden alleen kan emuleren op cutting edge hardware, het lijkt wel alsof hardware steeds sneller wordt zodat de programmeertalen steeds langzamer kunnen worden.
Hoe zit het bij windows 8? Geven ze de voorkeur aan XAML of HTML en Javascript?
Mono is geen taal maar de library die c# compileert.
Rich text editing is een van de meest ingewikkelde applicaties denkbaar.
Ja, kan het niet oneens zijn met je. Kost letterlijk op het programmeer werk de laatste jaren. De hoeveelheid resources die mening nauwelijks interessante apps nodig hebben is ronduit schokkend.

Het veel gehoorde argument is dat er toch genoeg resources zijn. Heel leuk, maar ik draai veelal veel spul tegelijk en dan is het zo op :(.

Als ik kijk naar wat ik vroeger met 1MB memory kon kan ik nog wel ff huilen.
Grappenmakers. Na Mono en C# nu een nog tragere taal? Nog meer bloatware dus. Laat ze het gewoon bij gecompileerde talen houden. Ik zie geen reden waarom we van beproefde techniek af moeten.
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.
Zou leuk zijn als je de andere reacties leest of tenminste uitlegt waarom dit onzinnig is. GNOME shell is grotendeels in javascript geschreven enzo.
Nog trager? Javascript is razend snel. En iedere browser update maakt het sneller.

Java gemaakt in de gangbare IDE's is traag. Maar dat is iets heel anders dan javascript

Op dit item kan niet meer gereageerd worden.



HTC One (M9) Samsung Galaxy S6 Grand Theft Auto V Microsoft Windows 10 Apple iPad Air 2 FIFA 15 Motorola Nexus 6 Apple iPhone 6

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True