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)
Interessant hoe javascript als meest geschikte programmeertaal gekozen kan worden.
Toegegeven, de afgelopen jaren is de taal weer een heel stuk verder geevolueerd. Maar een volwaardige programmeertaal zou ik het toch nog niet durven noemen.
Waarschijnlijk bedoelen ze overigens ECMAScript.
Toegegeven, de afgelopen jaren is de taal weer een heel stuk verder geevolueerd. Maar een volwaardige programmeertaal zou ik het toch nog niet durven noemen.
Waarschijnlijk bedoelen ze overigens ECMAScript.
[Reactie gewijzigd door frickY op dinsdag 5 februari 2013 14:21]
ECMAscript is Javascript. Het verschil is puur bureaucratisch, in de realiteit zijn de termen uitwisselbaar.
Verder is Javascript gewoon Turing complete en kun je er alles mee programmeren wat je ook in elke andere taal kunt bouwen, dus waarom zou het geen volwaardige programmeertaal zijn?
Javascript is al jaren de belangrijkste en meestgebruikte programmeertaal ter wereld, omdat er bijna geen omgeving of apparaat te vinden is waar het niet op draait. Van televisies tot tablets, van telefoons tot consoles, overal draait Javascript. Wil je een applicatie maken die echt platform onafhankelijk is, dan kun je bijna niet om Javascript heen.
De voornaamste reden dat Javascript door velen niet serieus genomen wordt is omdat bijna niemand de moeite neemt om de taal echt te leren. Genoeg programmeurs denken "ah, curly braces, dit ken ik wel", terwijl in feite Javascript totaal niet werkt zoals andere C-achtige talen. Alleen de syntax heeft er iets van weg, maar daar houden de overeenkomsten ook wel op.
Mensen zouden er goed aan doen de video's van Douglas Crockford te kijken of zijn boek "Javascript: the good parts" te lezen voordat ze afgeven op Javascript. Waarschijnlijk komen ze er dan achter dat er weliswaar zeker wel wat mis is met de taal, maar dat er ook een paar hele mooie features in zitten die je lang niet in elke taal tegenkomt.
Een goed beginpunt is deze Google Tech Talk: http://www.youtube.com/watch?v=hQVTIJBZook
Wil je er echt induiken, dan is deze serie een aanrader: http://yuiblog.com/crockford/
Verder is Javascript gewoon Turing complete en kun je er alles mee programmeren wat je ook in elke andere taal kunt bouwen, dus waarom zou het geen volwaardige programmeertaal zijn?
Javascript is al jaren de belangrijkste en meestgebruikte programmeertaal ter wereld, omdat er bijna geen omgeving of apparaat te vinden is waar het niet op draait. Van televisies tot tablets, van telefoons tot consoles, overal draait Javascript. Wil je een applicatie maken die echt platform onafhankelijk is, dan kun je bijna niet om Javascript heen.
De voornaamste reden dat Javascript door velen niet serieus genomen wordt is omdat bijna niemand de moeite neemt om de taal echt te leren. Genoeg programmeurs denken "ah, curly braces, dit ken ik wel", terwijl in feite Javascript totaal niet werkt zoals andere C-achtige talen. Alleen de syntax heeft er iets van weg, maar daar houden de overeenkomsten ook wel op.
Mensen zouden er goed aan doen de video's van Douglas Crockford te kijken of zijn boek "Javascript: the good parts" te lezen voordat ze afgeven op Javascript. Waarschijnlijk komen ze er dan achter dat er weliswaar zeker wel wat mis is met de taal, maar dat er ook een paar hele mooie features in zitten die je lang niet in elke taal tegenkomt.
Een goed beginpunt is deze Google Tech Talk: http://www.youtube.com/watch?v=hQVTIJBZook
Wil je er echt induiken, dan is deze serie een aanrader: http://yuiblog.com/crockford/
[Reactie gewijzigd door Dingen op dinsdag 5 februari 2013 14:37]
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.(..) dus waarom zou het geen volwaardige programmeertaal zijn?
Dat heeft niet zoveel met Javascript te maken, maar vooral met de trage manier waarop browsers met beeld en geluid omgaan. De DOM helpt ook niet bepaald mee. Een implementatie als node.js (waarin je niks te maken hebt met deze vertragende factoren) is razendsnel.
Maar sowieso is efficiënt omgaan met hardware niet de heilige graal van computerwetenschap. Natuurlijk is het aardig als je applicatie ook op wat mindere hardware nog functioneert, maar veel belangrijker is dat je code testbaar, leesbaar en onderhoudbaar is. Wat dat betreft hebben we echt grote stappen vooruit gemaakt sinds de jaren '80.
Maar sowieso is efficiënt omgaan met hardware niet de heilige graal van computerwetenschap. Natuurlijk is het aardig als je applicatie ook op wat mindere hardware nog functioneert, maar veel belangrijker is dat je code testbaar, leesbaar en onderhoudbaar is. Wat dat betreft hebben we echt grote stappen vooruit gemaakt sinds de jaren '80.
Voor image processing, 3d of andere intensieve data processing kan je toch gewoon Webgl gebruiken, Webgl levert bijna native OpenGL snelheden zodat je zelfs de modernste graphics algoritmes vloeiend kan renderen in je browser, En dat gezeik over dat javascript niet in staat zou kunnen zijn volwaardige apps te draaien is echt nergens op gestoeld, Ik heb al tig c++ apps geport naar javascript, En het draaide gewoon perfect. zelfs zeer recente gpu demo's, je moet alleen weten hoe je het moet programmeren. Ik heb ooit nadat ik al een tijdje op de noob manier programmeerde een framework (geprogrammeerd door google) helemaal uitgeplozen en kwam er achter dat ik het helemaal verkeerd deed, sinds dien is het bijna 1 op 1 zoals elke andere machine taal. Het is vooral zaak dat je wanneer je in een andere taal een class maakt een function maakt, En de methodes kan je aanmaken met door prototype tussen de class naam en methode naam te zetten, Dan hoef je alleen nog een createObject( name ) parser te maken die de juiste class oproept en voila 
Wel grappig ik heb al zoveel c++ en java software geport en vaak het enige wat ik hoef te doen is de qualifiers weghalen en in de body vervangen door var, parseint voor ints waar het echt iets dat is alles..
Ook hoor ik iemand zeuren over de gebrekkige debugging, Hah ik hoop dat deze persoon nooit Opengl/DirectX gaat programeren
, Javascript geeft gewoon altijd direct de juiste line, Kheb nog nooit hoeven nadenken over een js fout Ook kan je in chrome tenminste, vet goed bladeren door de code vanuit een tree van funtie's als er een fout is zodat je altijd kan vinden waar de error door veroorzaakt is.
Wel grappig ik heb al zoveel c++ en java software geport en vaak het enige wat ik hoef te doen is de qualifiers weghalen en in de body vervangen door var, parseint voor ints waar het echt iets dat is alles..
Ook hoor ik iemand zeuren over de gebrekkige debugging, Hah ik hoop dat deze persoon nooit Opengl/DirectX gaat programeren
, Javascript geeft gewoon altijd direct de juiste line, Kheb nog nooit hoeven nadenken over een js fout Ook kan je in chrome tenminste, vet goed bladeren door de code vanuit een tree van funtie's als er een fout is zodat je altijd kan vinden waar de error door veroorzaakt is.[Reactie gewijzigd door kajdijkstra op dinsdag 5 februari 2013 19:19]
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
(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
[Reactie gewijzigd door ik.ben.iemand. op dinsdag 5 februari 2013 15:39]
http://www.youtube.com/watch?v=NftT6HWFgq0
Dit is inderdaad wel waar het op neerkomt, hoewel het overall programma wel sneller word.
Dit is inderdaad wel waar het op neerkomt, hoewel het overall programma wel sneller word.
Turing complete is niet het enige wat er toe doet, of wel?Verder is Javascript gewoon Turing complete en kun je er alles mee programmeren wat je ook in elke andere taal kunt bouwen, dus waarom zou het geen volwaardige programmeertaal zijn?
En dus is het gelijk de belangrijkste taal ter wereld? Ik begrijp je logica echt niet.Javascript is al jaren de belangrijkste en meestgebruikte programmeertaal ter wereld, omdat er bijna geen omgeving of apparaat te vinden is waar het niet op draait.
JS is leuk, maar ik wil er geen grote of kritische applicaties mee maken.
Als je echt weet hoe JS werkt (en niet zoals de meesten er maar vanuit gaat dat je wel weet hoe het zit), is er geen enkele reden om er geen grote of kritische applicaties mee te bouwen. Het is namelijk prima mogelijk om de goede onderdelen van JS uit te buiten en de slechte onderdelen juist te vermijden.
Belangrijk voor development van interactieve applicaties (bijvoorbeeld web-apps) zijn de "closures" die je in javascript kunt maken. Dit zijn eigenlijk functies die je kunt meegeven aan andere functies. Zo kun je makkelijk event-handlers definieren. Het leuke is dat je vanuit deze closures weer variabelen in de eigen scope kunt vangen en tegelijk variabelen in een hogere scope kunt benaderen. Dit maakt het heel natuurlijk.
In talen als C en C++ kan men alleen maar dromen van deze handige constructie, getuige ook de ingewikkelde constructies die men in de loop der jaren heeft bedacht om dit op te vangen (zie bijvoorbeeld Qt).
De laatste tijd is men ook aan het proberen om andere talen af te beelden op javascript, zie bijvoorbeeld het Emscripten project. Het is alleen jammer dat javascript _net_ niet de juiste primitieven heeft om alles op een efficiente manier te vertalen. Hopelijk gaat men daar wat aan doen, want dit kan weer leiden tot een hoop verbetering op het gebied van programmeertalen (onderzoekers kunnen dan immers hun talen afbeelden op javascript, en de resulterende programma's kunnen dan ineens op heel veel hardware efficient draaien).
In talen als C en C++ kan men alleen maar dromen van deze handige constructie, getuige ook de ingewikkelde constructies die men in de loop der jaren heeft bedacht om dit op te vangen (zie bijvoorbeeld Qt).
De laatste tijd is men ook aan het proberen om andere talen af te beelden op javascript, zie bijvoorbeeld het Emscripten project. Het is alleen jammer dat javascript _net_ niet de juiste primitieven heeft om alles op een efficiente manier te vertalen. Hopelijk gaat men daar wat aan doen, want dit kan weer leiden tot een hoop verbetering op het gebied van programmeertalen (onderzoekers kunnen dan immers hun talen afbeelden op javascript, en de resulterende programma's kunnen dan ineens op heel veel hardware efficient draaien).
closures zijn grotendeels ondersteund in de laatste versie van C++, toch? En QT vind ik best intuitief om in te programmeren. Layouts samenstellen in QT vind ik ook beter werken dan bijvoorbeeld HTML+CSS en Windows Forms.
Door de 'oneindige' flexibiliteit van Javascript vind ik het juist lastig om niet-triviale systemen te ontwikkelen. Ik heb aan een project gewerkt waarbij de GUI van een embedded systeem in Javascript werd opgebouwd. De constructies die nodig waren om inheritance etc te implementeren zijn niet echt eenvoudig te begrijpen. En ook als ik een keer de javascript-frameworks in ga met een debugger om te snappen wat er onder water fout gaat heb ik al heel snel geen idee meer wat er gebeurt. Geef mij maar een typed language, waarbij je in elk geval weet wat voor ding je als argument aan een functie moet meegeven. De type-checker kan je beste vriend zijn, mits hij duidelijke foutmeldingen geeft
Door de 'oneindige' flexibiliteit van Javascript vind ik het juist lastig om niet-triviale systemen te ontwikkelen. Ik heb aan een project gewerkt waarbij de GUI van een embedded systeem in Javascript werd opgebouwd. De constructies die nodig waren om inheritance etc te implementeren zijn niet echt eenvoudig te begrijpen. En ook als ik een keer de javascript-frameworks in ga met een debugger om te snappen wat er onder water fout gaat heb ik al heel snel geen idee meer wat er gebeurt. Geef mij maar een typed language, waarbij je in elk geval weet wat voor ding je als argument aan een functie moet meegeven. De type-checker kan je beste vriend zijn, mits hij duidelijke foutmeldingen geeft
Dat is niet helemaal waar, anders was javascript en scripttaal ook uitwisselbaar.ECMAscript is Javascript. Het verschil is puur bureaucratisch, in de realiteit zijn de termen uitwisselbaar.
JavaScript is EEN ECMAScript implementatie, net als ActionScript en TypeScript(wat dan weer wel nar JavaScript compiled).
En waar JavaScript bij mij tegen aan loopt is dat het nog altijd erg lastig te debuggen is, waar de meeste programmeer talen dat toch beter doen (veelal omdat er een compiler voor hangt). En dan hebben we het nog niet over gehad over typing in JavaScript (iets wat TypeScript mooi oplost, zoals veel andere dingen die JS onnodig moeilijk maken).
Je kunt er zeker hele leuke dingen mee doen, getuige HTML5 maar het draaid op even veel platformen als enige andere taal. Waarom? Omdat er nog altijd iemand een omgeving moet schrijven waar het in draait. Iets wat met de meeste "echte" programeer talen niet hoeft. Net als wat je er mee kunt. het kan wel op een TV draaien maar niet magisch dingen gaan doen die niet eerst in een andere taal geprogrameert zijn, namelijk een javascript engine en API.
De grens tussen scripting en programmeren word lastig te leggen door de managed talen zoals C# en Java, die veel gemeen hebben met script talen: ze worden niet rechtstreeks gecompileerd.
[Reactie gewijzigd door LOTG op dinsdag 5 februari 2013 15:03]
Dat is alleen formeel zo. In de praktijk is Javascript dé implementatie van ECMAscript en zijn andere implementaties (zoals Actionscript) een variatie hierop.JavaScript is EEN ECMAScript implementatie
ECMAscript bestaat alleen op papier. Wanneer ECMAscript in de realiteit wordt gebruikt, heet het Javascript, tenzij er een variant wordt bedoeld, dan heet het naar de variant.
Ad Turing-compleetheid: schrijf eerst eens een paar programma's in Brainfuck voordat je dit als argument aanvoert in een praktische discussie.
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.
De functionele backends zullen overigens nog gewoon in c en c++ geschreven worden dus met snelheid zit het echt wel in orde.
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.
Javascript apps hebben helemaal niet de voorkeur. Het artikel is misleidend in die zin dat voor beginnende programmeurs Gnome de voorkeur heeft aan javascript.
Een andere kandidaat was python. Uiteindelijk hebben ze voor javascript gekozen omdat ze er vanuit gaan dat zo'n mensen op zich al in contact zijn gekomen met javascript of met zo'n syntax.
Zelf gaan gnome onderdelen en apps nog altijd gebruik maken van C(++) De realiteit is minder gewaagd dan de titel doet vermoeden.
Misschien slecht voorbeeld gezien het ding voor geen meter verkoopt, maar het is niet omdat je in Windows 8 apps kunt schrijven met HTML5/Javascript dat je opeens geen andere talen meer kunt gebruiken of dat half metro in jscript is gebouwd.
Een andere kandidaat was python. Uiteindelijk hebben ze voor javascript gekozen omdat ze er vanuit gaan dat zo'n mensen op zich al in contact zijn gekomen met javascript of met zo'n syntax.
Zelf gaan gnome onderdelen en apps nog altijd gebruik maken van C(++) De realiteit is minder gewaagd dan de titel doet vermoeden.
Misschien slecht voorbeeld gezien het ding voor geen meter verkoopt, maar het is niet omdat je in Windows 8 apps kunt schrijven met HTML5/Javascript dat je opeens geen andere talen meer kunt gebruiken of dat half metro in jscript is gebouwd.
[Reactie gewijzigd door simplicidad op dinsdag 5 februari 2013 14:25]
Hoe zit het bij windows 8? Geven ze de voorkeur aan XAML of HTML en Javascript?
Ook Javascript. Er is een speciale lib daarvoor, WinJS, en die is best netjes.
Waar haal je precies vandaan dat ze bij Windows 8 de voorkeur geven aan Javascript?
In Windows 8 is in de win rt runtime com based. C++ is weer terug van weggeweest. Andere talen kunnen erop in haken waaronser zelfs javascript...
Top dat Apple van begin af aan heeft gekozen voor native apps in iOS. Objective C is de taal van voorkeur. En dat native zie je terug aan de performance en snelle werking. Dit heeft ook geholpen in de populariteit van objective c en heeft ook weer invloed op de ontwikkeling voor mac os x.
Javascript mist belangrijke constructs die gewoon zijn in andere talen. En is natuurlijk trager. Heeft ook wat leuke uniekere features.. Daar niet van. Maar soms komt t gekunsteld over.
Top dat Apple van begin af aan heeft gekozen voor native apps in iOS. Objective C is de taal van voorkeur. En dat native zie je terug aan de performance en snelle werking. Dit heeft ook geholpen in de populariteit van objective c en heeft ook weer invloed op de ontwikkeling voor mac os x.
Javascript mist belangrijke constructs die gewoon zijn in andere talen. En is natuurlijk trager. Heeft ook wat leuke uniekere features.. Daar niet van. Maar soms komt t gekunsteld over.
Er staat toch echt:
Als ik het goed gebruik kun je prima apps schrijven zonder HTML5, dat staat ook in principe los van JavaScript. Je gebruikt dan de C-libs die andere talen ook gebruiken om een app te bouwen. Je kunt HTML apps wel includen in een native app, maar dat hoeft niet.
Zie ook:
http://developer.gnome.or...ble/hellognome.js.html.en
en
http://developer.gnome.or...me_to_the_grid.js.html.en
Voor system libraries gebruiken ze nog steeds C, maar voor de rest is Javascript toch echt de eerste keus die ook vanuit het development ondersteund en gepromoot gaat worden."Our decision is to support JavaScript as the first class language for GNOME application development. This means:
- We will continue to write documentation for other languages, but we will also prioritize JavaScript when deciding what to work on.
- We will encourage new applications be written in JavaScript.
- We will be working to optimize the developer workflow around JavaScript.
C will remain the recommended language for system libraries"
Als ik het goed gebruik kun je prima apps schrijven zonder HTML5, dat staat ook in principe los van JavaScript. Je gebruikt dan de C-libs die andere talen ook gebruiken om een app te bouwen. Je kunt HTML apps wel includen in een native app, maar dat hoeft niet.
Zie ook:
http://developer.gnome.or...ble/hellognome.js.html.en
en
http://developer.gnome.or...me_to_the_grid.js.html.en
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.
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.
Mono is geen taal maar de library die c# compileert.
Mono is nog veel meer, mono is/zijn ook de libraries die in wezen de CLR implementeren. Verder zijn het ook de tools die het dev'en vergemakkelijken onder Niet-windows omgevingen.
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
Java gemaakt in de gangbare IDE's is traag. Maar dat is iets heel anders dan javascript
alles is wel meteen echt opensource 
Daar heb je vrij weinig aan als er niet ook een open licentie aan hangt.
Niet helemaal waar. Exploits en bugs kunnen bijvoorbeeld sneller ontdekt worden.
Dus ook sneller door kwaadwillige n. Die melden een bug / exploit dus niet maar gebruiken het zelf.
/doomdenker
/doomdenker
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.
Ik zou eerder C(++) verwachten. Wel wat moeilijker programmeren maar wel bloedje snel.
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.
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.
Okee, dan daag ik je uit om het volgende stukje Python code te laten werken, zonder de variabele "count" global te maken en zonder functies te elimineren.Persoonlijk vind ik Python een mooiere taal
[code=python]
def test():
count = 0
def f(l):
for i in l:
count += i
f([10, 20, 30])
return count
print test()
[/code]
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.
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.
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.
"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.
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]
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.
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.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 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
