Google komt met 'javascript-alternatief' Dart

Google heeft een previewversie van de nieuwe programmeertaal Dart onthuld. Dart is opensource en gericht op webapplicaties. Volgens Google kan het een eenvoudig te leren alternatief vormen voor het breed toegepaste javascript.

Vorige maand verschenen er al berichten dat Google werkt aan een nieuwe programmeertaal, maar details waren nog niet bekend. Inmiddels heeft Lars Bak, onder andere verantwoordelijk voor de V8-javascriptengine in Chrome, Dart officieel voorgesteld.

Dart is volgens Google zowel een gestructureerde als een flexibele programmeertaal voor het bouwen van webapplicaties. Ook moet de taal relatief eenvoudig te leren zijn. Bovendien zou Dart in hoge mate schaalbaar zijn en niet alleen soepel kunnen draaien op browsers van mobiele telefoons, maar ook op servers goed moeten presteren.

Bak schrijft verder dat de nieuwe scripttaal gebruikmaakt van optionele types, een classificatiemethode die in sommige programmeertalen wordt toegepast. Dart zou het mogelijk maken om aan het schrijven van code te beginnen zonder types; deze elementen kunnen later worden toegevoegd. Dart-programma's kunnen op twee manieren draaien: in een eigen virtual machine of door deze te compileren naar javascript-code. In toekomstige versies van Chrome integreert Google mogelijk een Dart VM, maar de compiler is al beschikbaar.

Google heeft de previewversie van Dart op de website Dartlang.org online gezet. Op de thuisbasis van de nieuwe programmeertaal, die als opensource beschikbaar is, zijn ook programmeervoorbeelden en technische uitleg te vinden.

Reacties (154)

[iain]

Static typing. Erg jammer. Ik blijf voorlopig nog lekker werken met CoffeeScript.

[Fuzzillogic]

Static typing is een *absolute must* voor grotere projecten. Imo zijn het vooral beginners en scripters die dynamic typing prettig vinden. Maar op een gegeven moment besef je dat een IDE heel veel toegevoegde waarde kan bieden als de IDE wéét van wat voor een type een bepaald object is, en dat het heel veel vage bugs kan voorkomen. Nog afgezien van de beter mogelijkheid tot polymorphing en hogere snelheid.

[Kanarie]

Imo zijn het vooral beginners die denken dat een statische taal ze gaat beschermen in een groot project.

Het echte probleem blijft omgaan met complexiteit en het beheersbaar maken van die complexiteit met duidelijke en onderhoudbare code.
In dynamische talen is het eenvoudiger om mooie en leesbare code te schrijven, koppel dat aan een volledig dekkende suite tests en je kan projecten van elke grootte aan.

[onox]

Natuurlijk is het zo dat je niet moet denken dat static typing alleen je gaat beschermen bij het maken van complexe software. Toch is het wel zo dat static typing je kan helpen omdat je extra informatie over de werking van de software specificeert en de compiler bepaalde fouten kan detecteren, i.p.v. dat je test suite of gebruiker tijdens runtime dit doet.

Fouten worden in deze volgorde gedetecteerd: editor > compiler > testing > user. Hoe later, hoe duurder. En als ik de garantie heb dat bepaalde fouten niet kunnen optreden door een slimme compiler te gebruiken, dan heb ik dat liever dan dat ik het risico loop om nog allerlei exceptions te krijgen tijdens runtime. En denk niet een test suite altijd volledig en juist is

[Reactie gewijzigd door onox op 23 juli 2024 02:01]

[Kanarie]

Een test suite specificeert het gedrag van de code die je hebt geschreven om de tests te laten slagen. Mijn testsuite dekt dus volledig de code.
Elke feature staat beschreven in automatische tests die draaien bij codewijzigingen. Je weet dus onmiddelijk als je iets fout hebt gedaan bij een verandering.
Dit zijn de echte tests die je beschermen tegen fouten, static typing bied je alleen schijnveiligheid.

De juistheid van de gemaakte oplossing is sowieo niet automatisch te controleren. Niet met static typing en niet met een testsuite.

[RayNbow]

Een test suite specificeert het gedrag van de code die je hebt geschreven om de tests te laten slagen. Mijn testsuite dekt dus volledig de code.

Dat je testsuite het gedrag van je code specificeert wil natuurlijk niet automatisch betekenen dat je ook volledig dekking hebt.

Elke feature staat beschreven in automatische tests die draaien bij codewijzigingen. Je weet dus onmiddelijk als je iets fout hebt gedaan bij een verandering.

En een typechecker bewijst of je programma well-typed is, dus weet je onmiddelijk of je ook iets fout gedaan hebt bij een programma.

Dit zijn de echte tests die je beschermen tegen fouten, static typing bied je alleen schijnveiligheid.

Testsuites en typechecking zijn beide tools om iets over je code te zeggen, maar het is niet noodzakelijk dat de een de ander volledig overlapt. Met testsuites moet de programmeur zijn best doen om volledige zijn code te dekken, terwijl de typechecker altijd een bewijs levert voor heel je programma. Daarentegen zijn typesystems in de regel genomen niet expressief genoeg om al het gewenste gedrag te specificeren.

De juistheid van de gemaakte oplossing is sowieo niet automatisch te controleren. Niet met static typing en niet met een testsuite.

Waarom biedt static typing volgens jou dan alleen schijnveiligheid en testsuites dan niet?

Er bestaan trouwens wel (delen van) programma's die gegeven een type en een implementatie wel automatisch op juistheid te controleren zijn omdat er maar slechts 1 enkele implementatie bestaat. Zo bestaat er maar 1 mogelijke functie met het type (a -> (b -> c)) -> (b -> (a -> c)).

[Dreamvoid]

koppel dat aan een volledig dekkende suite tests

Dan verschuif je gewoon het moeilijke werk van het coden naar het testen! Dat lijkt me een recept voor ellende: een lekker makkelijke, fout tolerante taal, waar je erop vertrouwt dat je eventuele fouten wel bij het testen gaat vinden.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 02:01]

[Kanarie]

Je schrijft je tests voordat je de code schrijft. En dat is een best practice voor static en dynamic talen.

[Xenan]

In dynamische talen is het eenvoudiger om mooie en leesbare code te schrijven,

Wel eens F# geprobeerd? Heel eenvoudige, mooi leesbare en compacte code. Een beetje als Python, maar dan wel volledig statisch getypt.

[Dreamvoid]

F# is erg mooi, maar face it: het gaat nooit als next-gen universele webtaal geaccepteerd worden.

[iain]

"Static typing een absolute must", dat bestrijd ik. Mijn ervaring is vooral dat beginners static typing prettig vinden. Het geeft een bepaalde vorm van schijnveiligheid. De gedachte dat je compiler je behoed van fouten is een gevaarlijke gedachte. De ernstigste problemen zijn niet domme programmeerfouten waarin je een verkeerd object als parameter meegeeft, maar de fouten waarin je het probleem verkeerd begrepen hebt. Leesbaarheid van de code is dan veel belangrijker.

En juist polymorphe objecten maken is zo verschrikkelijk rot in statische talen. Dynamische talen zijn zo verschrikkelijk veel makkelijker te testen, juist omdat je zonder problemen een mock of test double als argument kan gebruiken in je tests.

Een beetje hulp van je IDE is natuurlijk handig, maar het is me al die overhead van type declaraties en meuk zoals interfaces niet waard. Dan gebruik ik liever een goede editor zoals Vim, die me op andere manieren meer productiviteit biedt.

[RayNbow]

Een beetje hulp van je IDE is natuurlijk handig, maar het is me al die overhead van type declaraties en meuk zoals interfaces niet waard.

Een beetje moderne taal heeft tegenwoordig type inference zodat je geen types hoeft op te geven. Zonder expliciet types op te hoeven geven verschilt zo'n taal aan de buitenkant weinig met een dynamische taal.

[iain]

Type inference maakt het een stuk prettiger om te typen, dat is waar. Toch maakt het qua functionaliteit wel uit. Duck typing is imho erg handig.

Edit: maar zaken als deterministisch refactoren is wel iets wat je mist in dynamische talen ja.

[Reactie gewijzigd door iain op 23 juli 2024 02:01]

[Xenan]

Mijn ervaring is vooral dat beginners static typing prettig vinden.

Pardon? Beginners vinden juist dynamisch typing prettig. Kijk maar naar de populariteit van PHP bij de script kiddies.

[djsubzero]

Idd, bij static typing komen de meeste fouten veel vroeger naar boven (compile-time). Dynamic typing heeft ook zijn voordelen, maar het is veel handiger dat dit niet standaard is. Zoals in .net4 kan dit ook maar dan expliciet.

[RayNbow]

Static typing. Erg jammer.

Dart is optionally typed. In dat opzicht lijkt het op iets wat Erik Meijer een tijdje terug schreef: Static Typing Where Possible, Dynamic Typing When Needed (PDF).

[Ivos]

Klinkt interessant, maar hoe groot is de kans dat dit aanslaat, dwz er ook daadwerkelijk grote groepen mensen gebruik van gaan maken? Als het echt mogelijk is om er makkelijker en netter* code mee te schrijven dan met JS zou het zomaar wat kunnen worden denk ik?

(* ligt natuurlijk altijd aan de coder en niet aan de taal, maar ik heb weinig ervaring met JS, en als ik dan vaak voorbeelden doorkijk van JS komt het op mij behoorlijk chaotisch over...)

[Rob Coops]

Javascript is vrijwel niet echt netjes te schrijven simpel weg omdat het origineel alleen bedoelt is om hele simpele kleine dingen mee te doen. Van daar ook dat het zo traag als dikke stront is, en er allerlei werk gedaan moet worden binnen de javascript VM om het nog een beetje te laten performen.

Dit taaltje wordt op het moment gebruikt om dingen te doen die helemaal nooit bedoeld of zelfs bedacht zijn door de ontwerpers van de taal om die reden kun je vrijwel niet anders dan op zijn best zo min mogelijk rommel maken tijdens het schrijven van de code maar echt netjes is het eigenlijk nooit. Althans niet in verhouding tot wat mogelijk is met een taal die wel bedoeld is om echt complexe dingen te doen.

[YopY]

Javascript is vrijwel niet echt netjes te schrijven simpel weg omdat het origineel alleen bedoelt is om hele simpele kleine dingen mee te doen.

Oneens. JS kun je net zo netjes schrijven als andere talen, als je er maar wat werk in stopt. Ok, voor dingen als modules moet je wat gekke taal-truuks uithalen (zie ook: Javascript Module Pattern), maar voor de rest valt het genoeg mee. Ligt eraan hoeveel discipline de developer heeft, en of ze kunnen weerstaan om aan 'premature minification' te gaan doen.

Van daar ook dat het zo traag als dikke stront is, en er allerlei werk gedaan moet worden binnen de javascript VM om het nog een beetje te laten performen.

Oneens, en deze keer met feiten. NodeJS out-performt met gemak (bijvoorbeeld) een LAMP-stack, zowel qua ruwe performance (duizenden requests / seconde) als developmenttijd.

[Dreamvoid]

Van daar ook dat het zo traag als dikke stront is

Dat is steeds minder het geval, JS engines zijn behoorlijk rap tegenwoordig. Of het allemaal even secure is, dat is vraag 2 maar zolang het allemaal niet te complex wordt is snelheid niet echt meer een gigantisch issue. Zie oa ook Metro/WinRT in Windows 8 - dat was echt niet in JS gemaakt als het niet vergelijkbare performance had als Win64 native of .NET.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 02:01]

[rednek]

Ik weet niet waar je het over hebt maar "Javascript is vrijwel niet echt netjes te schrijven simpel weg omdat het origineel alleen bedoelt is om hele simpele kleine dingen mee te doen" Gaat natuurlijk nergens over. Waar de taal ooit voor bedoelt is en waar het heen gaat heeft niks met de duidelijkheid van de taal te maken.

Javascript kan heel duidelijk zijn het is maar hoe je het schijft.

[killercow]

En laten we vooral dingen blijven zeggen over talen die wel zelf machtig zijn in plaats van over talen waar we alleen over gehoord hebben.

[Bartjeh]

Ligt voornamelijk aan de coder ja. Nou wil er ook nog wel is wat JavaScript geminified worden wat het er ook niet leesbaarder op maakt. Of methodchaining een paar regels achter elkaar.

Vind het alleen wel jammer dat ik in het bovenstaande voorbeeld volledig document.getElementById zie staan. Ik had toch wel gehoopt dat ze iets als jQuery-achtige notatie zouden gebruiken.( $("#message") ) Scheelt weer een bak typwerk

[Reactie gewijzigd door Bartjeh op 23 juli 2024 02:01]

[Wwwillem]

Paar regels uit de example code:

document.query("#menu").nodes.add(sliderMenu.node);

document.query('#next').on.click.add((e) {
sliderMenu.selectNext(true);
});

Ze hebben wel goed naar jQuery gekeken. Het ondersteunt ook classes en interfaces, wat beheer van je project gemakkelijker zal kunnen maken.

Het lijkt me ook relatief makkelijk te implementeren voor browser-bouwers als google er een beetje aan meewerkt, dus wie weet.

[YopY]

Ik denk eerder dat dat de Javascript Selectors-API is, die op zijn beurt (waarschijnlijk) gebaseerd is op JQuery en companen die de selector-stijl populair gemaakt hebben.

En ik denk / hoop zelf dat JS libraries gewoon gebruikt kunnen worden vanuit Dart.

[abitvin]

getElementById() hoort bij de DOM en is een API en hoort niet bij de JavaScript taal zelf. Maar je hebt gelijk ik vind het daarom ook een slecht voorbeeld.

[berend_engelbrecht]

Iets wat je in het voorbeeld wel ziet en wat in javascript niet kan is de declaratie van de variable Element element. Het feit dat javascript niet strongly typed is, is een van de grootste manco's van die taal.

[Killemov]

... iets als jQuery-achtige notatie zouden gebruiken.( $("#message") ) ...

*kuch* prototype.js *kuch*

[Auredium]

Afwachten. Niet al Googles plannen zijn in goud veranderd. Ik vraag me ook af in welke mate dat dergelijke webstandaard fragmentatie wenselijk is. Honderd verschillende programmeertalen om dezelfde functies online te kunnen uitvoeren maakt het uiteindelijk alleen maar lastiger.

Wel is het zo dat ik vind dat programmeren in het algemeen veel makkelijker moet kunnen. Ik verwacht dat in de midden-lange termijn programmeren zo extreem makkelijk is geworden dat iedere kleuter en huisvrouw met gemakkelijk de meest complexe taken kan programmeren zonder ellenlange code te hoeven kloppen. Zo'n talen zijn er al, maar ik verwacht dat ze in de toekomst standaard zijn. Dus makkelijker mag en kan zeker, maar of dit nu hiervoor gaat zorgen of het alleen maar meer fragmentatie is?

Wel is het zo dat dat Google via Android veel kan pushen.

[watercoolertje]

Wel is het zo dat dat Google via Android veel kan pushen.

Hoe dan? Ze gaan echt niet JS disablen ofso Enige wat ze kunnen doen is hun eigen diesten ombouwen maar daar merkt niemand echt wat van (behalve dat het misschien sneller/slomer) wordt...

[Killemov]

Tot het moment dat Google vindt dat ze genoeg marktaandeel heeft en het standaard "Dart" wordt en optioneel javascript.

[Aham brahmasmi]

Voorbeelden van andere standaarden die Google met hun marktaandeel heeft verdrukt?

[-Tom]

Standaarden op ICT gebied? Of standaarden in het algemeen?

Google heeft sinds haar oprichting weldegelijk standaarden uit de markt gedrukt. Misschien niet de standaarden die jij hier bedoelt, maar ooit was Hotmail de trend, was Altavista de standaard voor zoekmachines en was Googlen nog geen officieel woord in de dikke van Dale.

Google geniet een positief imago, ze zijn in enorm veel sectoren binnengedrongen als succesvolle, maar soms ook matige, spelers. Android, Gmail, Streetview, Maps, Google Documents en op het moment in mindere mate Google+. Maar ook de zelfbesturende auto gaat wellicht in de toekomst een grote rol in ons dagelijks leven spelen.

Er zijn weinig concrete situaties aan te wijzen waar Google daadwerkelijk een standaard de markt uit heeft gedrukt. Echter hebben ze aangetoond dat ze succesvol zijn als het gaat om het penetreren van bestaande markten en zelfs het oprichten van geheel nieuwe markten.

[Hydra]

Er is nogal een verschil tussen iets de markt uit drukken en gewoon een alternatief bieden dat door de markt opgepakt is. Apple bijvoorbeeld heeft Flash redelijk de markt uitgedrukt door het niet te ondersteunen op de iDevices (iets waar ik het in dit geval overigens mee eens ben), maar dat is wat anders dan een alternatief bieden waar mensen zelf op overstappen omdat het simpelweg beter is. Facebook heeft het marktaandeel van Friendster en MySpace overgenomen voor het grootste deel, Google van Altavista en Yahoo, en Gmail van Hotmail, gewoon omdat deze producten beter waren dan hun voorgangers.

[koter84]

.....Apple bijvoorbeeld heeft Flash redelijk de markt uitgedrukt door het niet te ondersteunen op de iDevices.....

Ook ik ben een voorstander hiervan, maar toch heb ik niet het idee dat flash echt minder is geworden. Volgens mij wordt er "gewoon" een "App" gemaakt van een website als die gebruik maakt van flash. Op een iDevice is flash dan inderdaad de markt uitgedrukt, maar daarvoor in de plaats heb je nu iets wat nog erger is... Apps die puur en alleen worden gemaakt voor de iPhone, omdat die niet kan omgaan met flash...

[hing]

Google is volgens mij in veel Europese landen de "standaard" search engine.

[dtech]

Chrome wordt voorlopig geen monopolie-browser. IE heeft nog altijd de helft (op desktop).

De enige manier dat Dart een sirieuze browser zou kunnen worden is als een aantal grote browsers (en dan denk ik natuurlijk aan Chrome & Firefox) een VM inbouwen en de compiler goed genoeg werkt zodat er geen grote performance-hit is in Safari & IE t.o.v. native JS (IE is natuurlijk al relatief langzaam met Javascript)

Maar ik denk vooral dat de taal zich moet bewijzen aan developers. Als hij fijn is & de tools goed zijn dan gaan developers deze vanzelf gebruiken.

[Snobbieh]

Is Dart een browser dan? Als ik het kan lezen, is het een vervang alternatief voor JS

[Verwijderd]

Chrome en Android voorzien van Dart ondersteuning. In dat geval heb je al een heleboel mensen die het kunnen gebruiken zonder het zelf door te hebben.

Daarnaast kunnen een compiler voor Dart bij Mozilla aanleveren, dan hebben ze FF waarschijnlijk ook al mee. Google is immers de hoofdsponsor van Firefox (85% inkomsten van Mozilla), maar het contract loopt (as far as I know) in 2011 af. Ik denk dat het "Dart" fenomeen toch wel even ter sprake komt/is gekomen als het over een verlenging van sponsorschap gaat.
Firefox heeft trouwens al laten weten dat ze JavaScript niet echt een top-taal vonden. Als ze Dart prettiger vinden gaan ze JS misschien zelfs helemaal uitfaseren (langetermijn plan uiteraard).

Als die 2 het eenmaal ondersteunen kan je er bijna niet meer omheen dat het een succes wordt. Zeker niet met Google's (over het algemeen genomen) uitgebreide tutorials en developers hulp.


ps; bronvermelding
http://techcrunch.com/200...-with-google-for-3-years/

[Xenan]

Firefox heeft trouwens al laten weten dat ze JavaScript niet echt een top-taal vonden.

Niemand vindt Javascript een toptaal. Maar de nieuwe versies gaan vele fouten repareren en dat lijkt me een betere route dan een nieuwe taal. Zeker als het ontworpen wordt door een bedrijf dat geen ervaring heeft met language design. Een goede taal ontwerpen, daar komt veel kennis en ervaring bij kijken.

[Dreamvoid]

Aan de andere kant kent Google, als de grootste JavaScript developer ter wereld, als geen ander de beperkingen van die taal

[Josaus]

Ja zekerwel, misschien wordt Google wel veel sneller als ze een eigen taaltje ontwikkelen, misschien gaat het alleen maar voor problemen zorgen, we zullen zien!

[dwilmer]

Google heeft eerder al Go ontworpen, dus ze hebben ervaring. Daarnaast lijkt de taal syntactisch heel erg op C++ en Javascript. Ik denk dat ze een soort combinatie van C++ en Javascript hebben gebruikt, waarbij ze de beste stukken bij elkaar willen brengen. En als je met beide talen veel ervaring hebt, is het eenvoudiger om ze te combineren.

Verder vind ik de komst van classes erg goed, al vraag ik me af of hoe closures gaan werken. Dat is namelijk een erg krachtig onderdeel van Javascript waarvan ik heb gelezen dat zoiets ook in Dart komt.

Ik ben sowieso benieuwd of het echt zo veel beter is dan Javascript. Een kwestie van mee spelen en afwachten. En hopen dat er snel libraries komen zoals jQuery, want het grootste deel van wat nu met Javascript ontwikkeld wordt maakt zwaar gebruik van zulke libraries.

[--Andre--]

Libraries zoals jQuery? Ik zie liever zoiets als onderdeel van de taal, in plaats van zo'n library.

[Pyronick]

Vergeet niet dat Google ook nog het alsmaar populairder wordende Chrome heeft en binnenkort ook nog wat meer nadruk op Google TV gaat leggen.

Dit soort situaties kennende stappen Mozilla en waarschijnlijk Opera ook in. Als Apple, Facebook (in dit soort gevallen ook een grote speler) of Microsoft hierbij ook nog eens mee zouden doen dan is de toekomst zo goed als vastgesteld.

Echter is er nu ook iets als WebM wat ook nog niet zo vlot wordt gestandaardiseerd. Maar gezien er steeds meer hardware acceleratie te vinden is in mobile hardware (Texas Instruments OMAP4, Rockchip RK29xx en ZiiLabs ZMS-20) en ook AMD APU's in de nabije toekomst ziet het er goed uit.

Ook is er SPDY, wat volgens mij eerst zijn weg heeft gevonden via Chrome, nu Firefox en binnenkort waarschijnlijk ook andere browsers.

[kidde]

Ze gaan echt niet JS disablen ofso

Doen ze feitelijk al!

Ga maar na: Qua JS-ondersteuning hobbelen ze net zover achterop als IE (van MSFT).
Opera biedt ondersteuning voor nieuwere versies, en Firefox vanzelfsprekend voor de allernieuwste versies.

Juist die allernieuwste versies van Javascript maken JS tot een 'bijna volwaardige' programmeertaal. Echter, de verouderde JS-versie die Chorme ondersteunt is een niet-volledige programmeertaal die toch een beetje kreupel is.

Als Google nu ipv. de nieuwere JS-versies Dart gaat lopen pushen, betekent dit dat er behalve Mozilla en Opera niemand de nieuwste JS-versies gaan ondersteunen.

[Rob Coops]

Het voordeel is dat het naar javascript kan compilen dat houd dus in dat fragmentatie beperkt kan blijven omdat je het geheel simpel weg als Javasript kunt exporteren en kun gebruiken in andere browsers zelfs als Dart door andere niet wordt ondersteunt.

Iedereen programmeren.... lektober is alles wat ik daar op ga zeggen.

Google kan via Android geen programmeer tallen pushen omdat anders dan het aanbieden ze niets meer kunnen doen. Het probleem is dat zeker voor Android de meeste "bedrijven" bestaan uit een verzameling script kiddies met weinig meer ervaring of kennis dan het geen ze op gepikt hebben tijdens de lessen programmeren voor beginners op school en de twee a drie jaar ontwikkelen voor het een of andere bedrijf waar ze elkaar toevallig hebben leren kennen. De kans dat deze mensen de tijd, het geld en de moeite er voor over hebben om een nieuwe taal te leren om precies het zelfde mee te doen als ze nu al doen met Javascript is extreem klein. De enige reden om zo iets te gaan doen is als deze taal meer dingen mogelijk maakt of het mogelijk maakt heel erg veel sneller te werken dan ze op dit moment kunnen doen.
Microsoft heeft al meerdere malen geprobeerd dit soort alternatieven voor javascript te pushen maar over het algemeen blijft het hangen op het feit dat de taal weinig anders is dan javascript waar de functies en constructs allemaal net even anders zijn ondanks dat het technisch misschien veel beter is kun je er weinig meer mee dan met javascript en dus zal de doelgroep niet massaal overstappen omdat het gewoon te veel tijd en geld kost om de nieuwe taal te leren.

Als je echt iets wilt verbeteren dan zul je een aantal dingen moeten doen. Om te beginnen moeten alle partijen (en dat lijkt me een aangewezen taak voor W3C) het eens worden over welk alternatief het worden gaat en daar naast moeten alle 3 de grote browsers deze implementeren. Daar naast moet de keuze echt sneller krachtiger en beter zijn dan javascript en of meer dingen mogelijk maken dan javascript nu doet. Dan en alleen dan zal de ontwikkel gemeenschap overstappen op de nieuwe taal simpel weg omdat hun concurrenten dat misschien ook doen en dan meer mogelijkheden hebben dan zij nu hebben.
Zelfs dan is het nog zaak dat je minimaal een aantal van de grote spelers zo gek krijgt dat ze ook echt minimaal in een aantal projecten die nieuwe taal gebruiken om zo aan de rest te laten zien wat er zo al niet mogelijk is.

Tot die tijd durf ik met aan zekerheid grenzende waarschijnlijkheid te zeggen dat deze taal anders dan een leuk speeltje voor de mensen binnen Google die dit ontworpen hebben niet veel verder gaat komen dan een korte opleving binnen kleine groep developers die graag experimenteert met nieuwe talen.

[Xenan]

Microsoft heeft al meerdere malen geprobeerd dit soort alternatieven voor javascript te pushen

Heb je daar voorbeelden van? Heel lang geleden heeft Microsoft VbScript als alternatief gepositioneerd maar daar zijn ze al lang van teruggekomen. Nu steunt Microsoft de ontwikkeling van Javascript en biedt zelf ook verbetering aan richting de standaardencommissie.

[Reactie gewijzigd door Xenan op 23 juli 2024 02:01]

[blouweKip]

Microsoft heeft al meerdere malen geprobeerd dit soort alternatieven voor javascript te pushen maar over het algemeen blijft het hangen op het feit dat de taal weinig anders is dan javascript waar de functies en constructs allemaal net even anders zijn ondanks dat het technisch misschien veel beter is kun je er weinig meer mee dan met javascript en dus zal de doelgroep niet massaal overstappen omdat het gewoon te veel tijd en geld kost om de nieuwe taal te leren.

Met een groot verschil dat dit een open taal is.

[Dreamvoid]

C# is een open taal, een ECMA en ISO standaard.

Maar al die alu-hoedjes theorieen zijn niet erg waarschijnlijk, Google gaat ongetwijfeld Dart als open ECMA, ISO of GPL standaard formaliseren zodra er een beetje belangstelling voor is, net zoals dat met alle andere talen ging. Uiteindelijk komt het erop neer of de andere browsermakers:
a) Dart technisch goed genoeg vinden
en
b) Google het succes gunnen

Het eerste zal best goed zitten, maar het laatste...daar zal Google de PR afdeling voor aan het werk moeten zetten. Daar hebben wij als toeschouwers/commentators weinig invloed op.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 02:01]

[Verwijderd]

Nee, dit is niet open.
Er is een wel open source implementatie van beschikbaar maar Dart is gewoon 100% eigendom van Google. Net zoals de VP8 video codec in WebM niet open is maar gewoon 100% eigendom van Google.

Als Google van Dart een open script taal van wil maken dan moeten ze het eigendom over het fotmaat overdragen aan een standaardisatieorganisatie zoals bijvoorbeeld aan Ecma Internationaal (waar nu Ecmascript zit) zoals bijvoorbeeld Microsoft ook gedaan heeft met C# zodat C# ene open standaardi s geworden.

Nu is Dart niet meer open dan Actionscript (flash) of Xaml (silverlight). Oh nee wacht, XAML is als specificatie al onder een vrij licentie uitgebracht en dat heeft Google met dart nog niet gedaan.

[Verwijderd]

Inderdaad. En je hoeft ook niet altijd verwachten dat ieder plan goud waard is, dat blijkt vaak later pas.

Maar ik vind het ook niet echt een slimme strategie om teveel verschillende wegen te willen bewandelen, je verdunt daarmee je potentie. Verliest Google haar kernactiviteiten niet uit het oog?

Google search kan bijvoorbeeld nog steeds niet op datum / tijd filteren c.q. sorteren en dat vind ik een groot manco. Bestaat er al een datum / tijd / lokaliteit meta-tag? Anders wordt het hoog tijd.

Vaak is informatie alleen relevant binnen een bepaald tijdvak.

[Seraph1987]

Bij geavanceerd zoeken van google staat er wel een uitvouwbaar + [Datum, gebruiksrechten, regio en meer] waarbij je een selectie kunt maken m.b.t. een tijdvak.
Bedoel je dat?

[Verwijderd]

Dat lijkt er inderdaad al wat op. Dank je. Ik ga die geavanceerde pagina als standaard instellen. Dat lijkt me wel handig. Nu nog een sorteer functie. Een zichtbare page-rank teller lijkt me in dat verband ook wel handig. Ik wil graag boven en onder limieten in kunnen stellen net als bij SQL, maar gebruiksvriendelijk / grafisch.

Hier de link voor mensen die deze pagina niet meteen kunnen vinden:

http://www.google.nl/adva...2B&hl=nl&biw=1920&bih=930

[Reactie gewijzigd door Verwijderd op 23 juli 2024 02:01]

[kidde]

Maar die datumfunctie is natuurlijk een nogal lam en verkreupeld aftreksel van hetgeen men bijvoorbeeld in het decennia oude '(POSIX-) find' kan vinden: Men kan niet eens tussen twee zelf gekozen tijdstippen zoeken!

Weet je bijvoorbeeld dat een artikel uit 2007 stamt, heb je aan deze zgn. "feature" geen enkele drol. En ook als je "artikelen ouder dan een jaar" zoekt, hetgeen natuurlijk nogal eens gebeurd omdat de Google-database vol copy-paste troep van "een persbericht van gister" staat, heb je ook al totaal geen ene drol aan Google. Dus wat data betreft vind ik het een totaal nutteloze zoekmachine. Maar ja, vziw momenteel wel het beste wat we hebben; hoewel archive.org soms beter werkt.

Maw: Ik ben het er wel mee eens dat het fijn zo zijn als Google zich ook een beetje meer bleef richten op de zoekmachine.

[skatebiker]

Sterker nog, ze kunnen nog geeneens de 'navigator.language' eigenschap uitlezen.

Als ik een Engelstalige OS, Engelstalige browser en mijn Google ID de standaardtaal op engelsw zet, dat openen Google diensten, ook Android Market) standaard op Nederlands. En als ik onderaan de pagina de taal op Engels zet blijft ie even zo maar de volgende dag is het weer Ne4derlands.
Heel vreemd.
Google is toch Amerikaans ???

Zou dat met Dart opgelost worden ???

[Reactie gewijzigd door skatebiker op 23 juli 2024 02:01]

[HerrPino]

JavaScript is ooit bedacht door Netscape, door Brendan Eich. De enige overeenkomt met Java zijn de eerste 4 letters in de naam. Wat dat betreft is de naam een beetje ongelukkig gekozen.

[Dreamvoid]

Formeel heet het dan ook ECMAScript, maar die naam gebruikt niemand.

[kidde]

Formeel heet het dan ook ECMAScript, maar die naam gebruikt niemand.

Strikt genomen is dat voor zover ik begrijp onjuist, Javascript versies 1.6 en later heten helemaal geen ECMAscript, omdat ze nog niet gestandardiseerd zijn.

[Verwijderd]

Naam was marketing, mensen hebben graag java, dan noemen we dit javascript en alle java fans gaan hier gegarandeerd naar kijken.

Een mooie quote:
"Java is to JavaScript what car is to carpet"

[Dirk van Bergen]

Je ziet wat over het hoofd. Namelijk dat JavaSCript en Java compleet los van elkaar zijn. Zo is JavaScript, waar Dart het alternatief voor is, niet van Oracle. En dus je hele rant niet op de goede plek

[SiC123]

Dart is een vervanging van Javascript (ecmascript) niet van Java. Javascript lijkt niet op Java en is ook niet van Sun / Oracle.

[MneoreJ]

Ik verwacht dat in de midden-lange termijn programmeren zo extreem makkelijk is geworden dat iedere kleuter en huisvrouw met gemakkelijk de meest complexe taken kan programmeren zonder ellenlange code te hoeven kloppen.

Die droom is al zo oud als er computers bestaan (of zolang er HLL's bestaan, althans, een paar decennia in ieder geval), is nog nooit verwezenlijkt, en zal (naar mijn persoonlijke mening, let wel) ook nooit verwezenlijkt worden.

De moeilijkheid van programmeren zit hem niet in de syntax en ook niet zozeer in het abstractieniveau van de talen, hoewel daar telkens verbeteringen geboekt worden (en geboekt zullen blijven worden). Het is het nauwkeurig opschrijven van iets waarvan je alleen ongeveer weet wat het is dat de moeilijkheid is, en daar helpt geen taal tegen. "Complex" is niet hetzelfde als "tijdrovend". Tijd kan de computer je wel uit handen nemen, maar essentiële complexiteit niet. De vraag van wat complex is verschuift hooguit.

Dit is redelijk OT omdat het duidelijk is dat Dart niets te maken heeft met een algemene droom van programmeren in de handen van de massa te brengen. Het is een JS-alternatief dat van vergelijkbare complexiteit is, maar gestroomlijnder.

[johnbetonschaar]

Die droom is al zo oud als er computers bestaan (of zolang er HLL's bestaan, althans, een paar decennia in ieder geval), is nog nooit verwezenlijkt, en zal (naar mijn persoonlijke mening, let wel) ook nooit verwezenlijkt worden.

Helemaal mee eens. Zoals je zelf al aangeeft zit de complexiteit van programmeren hem niet in de taal zelf, of hoe je die taal toepast, maar in de probleemstelling zelf.

UIteraard kun je de probleemstelling proberen zo veel mogelijk te reduceren door een enorme berg aan kant-en-klare oplossingen voor gangbare subproblemen aan te bieden, maar dat werkt ook maar tot op zekere hoogte. Zo gauw je al die standaardoplossingen gaat combineren tot iets nieuws dat nog niet bestaat (als het al wel bestond hoefde je het ook niet te programmeren natuurlijk), dan komt daar toch gewoon weer allerlei logica en interactie bij kijken, die volledig buiten de belevingswereld van 'iedere kleuter en huisvrouw' ligt.

Komt nog bij dat het belangrijkste dat al die 'makkelijke' RAD (rapid application development) talen, libraries en ontwikkelomgevingen ons geleerd hebben, is dat ze tot klunzige, instabiele en inefficiente programma's leiden. Hoe meer kant-en-klare bouwstenen je de 'programmeur' aanreikt, hoe makkelijker het wordt om domweg wat dingetjes aan elkaar te slepen zonder na te denken over de kwaliteit van het eindresultaat. Je ziet dit vooral terug bij al die talen die bedoeld waren om 'makkelijk' en toegankelijk te zijn voor iedereen, zoals Visual Basic en Delphi bijvoorbeeld. In principe kun je daar schitterende programma's mee maken, maar het overgrote deel van de software die in die talen is gemaakt is echt van een bedroevend laag niveau.

[Fuzzillogic]

Ik kan zo ongeveer elk initiatief om javascript overbodig te maken toejuichen. Maar Dart stelt me dan ook weer wat teleur: het is een goed begin, static typing, classes, iets uitgebreidere runtime, maar vergeleken met de high end programmeertalen als Java en C# is het nog steeds slechts driewieler-niveau. Ik zou nog steeds geen grote applicaties willen maken met Dart.

[iain]

Driewieler-niveau? Het ontbreekt aan standaard libraries in JS, maar de taal is, dankzij de functionele elementen, veel krachtiger dan Java en C# ooit zullen worden.

[Fuzzillogic]

Ok, javascript kent wel wat leuke grappen, maar bij javascript lijkt dat veel te vaak op een toevallige bijkomstigheid dan expliciet ontworpen. Dat "veel krachtiger" bestrijd ik iig.

Bovendien worden dat soort functies ook meer en meer aan .NET en Java toegevoegd. Vergeet ook niet dat de JVM nu aangepast is voor scripting-talen: geen probleem dus om Javascript binnen een Java-project te gebruiken, als dat handig blijkt te zijn.

[iain]

Dynamische talen binnen de JVM gebruiken is ook erg gaaf: het zet de deur open voor talen als JRuby en Clojure.

Dat Java en C# de laatste tijd ook functionele aspecten toevoegen aan hun taal, geeft aan dat ook zij inzien dat dit de weg voorwaarts is, toch?

[Xenan]

de taal is, dankzij de functionele elementen, veel krachtiger dan Java en C# ooit zullen worden.

C# heeft ook functionele elementen en de lambda syntax is compacter. Daarnaast ondersteunt C# vanaf versie 4.0 ook dynamisch programmeren. Je bewering dat dat Javascript krachtiger zou zijn dan Java of C# laat zich moeilijk onderbouwen.

[Dreamvoid]

Ze zitten natuurlijk met de eis dat het makkelijk naar JavaScript te compileren moet zijn voor backwards/crossbrowser compatibility. Het is een stap in de goede richting, maar het zal nooit "de redding van het web" zijn ofzo.

Java en/of C#/F# zouden misschien in een ideale wereld de (client-side) webtalen zijn, maar face it: noch Oracle, noch Microsoft kunnen anno 2011 Google, Mozilla, Opera en Apple ooit overtuigen om het in hun browsers te implementeren. Dat hadden ze rond 1997 moeten doen, toen alles nog open lag en Sun, Netscape en Microsoft de giganten van het web waren.

Dan geef ik Google nog meer kans, ook al is het een wat minder ambitieuze taal.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 02:01]

[Mijzelf]

Ik denk dat je in geen enkele scripttaal grote applicaties zou moeten willen maken.

[iain]

Je bedoelt, zoals Facebook (PHP) of Twitter (Ruby)?

[Fuzzillogic]

Dan nog, willen en kunnen zijn verschillende dingen. Facebook heeft een PHP-compiler geschreven omdat het anders te traag was. Sowieso vind ik PHP vergeleken met bijv. Java ook nog maar "meh" op zijn best. En draait Twitter tegenwoordig niet ook "gewoon" op java?

[iain]

Je mist het punt: met talen als PHP, Ruby, Perl en Python is het heel goed mogelijk om grote applicaties te maken. Dat Facebook en Twitter met hun extreme traffic tegen performance grenzen aanlopen is een ander issue.

Zaken als static typing zijn slechts zijwieltjes (om jouw metafoor met driewielers even te lenen).

[Fuzzillogic]

Je mist mijn punt: willen en kunnen zijn verschillende dingen. Ja, je kunt met PHP etc prima websites maken, ook grotere. En nullzijdank zijn de IDE's tegenwoordig beter in staat om het type van variabelen te gokken van PHP. Maar het blijft gokken met dynamic typing.
Static typing was ooit vooral een noodzaak wegens beperkt geheugen, CPU en compilertechnieken, maar tegenwoordig met groeiende code en krachtige IDE's is het een niet te missen hulpmiddel geworden.

[iain]

Code completion "niet te missen"? Gezien de gigantische hoeveelheid applicaties geschreven in dynamische talen, blijkbaar wel toch? Dynamische talen compenseren vaak het gebrek aan deterministische code completion door de API heel duidelijk en simpel te maken. Java heeft vaak last van complexe API's waardoor inderdaad code completion onmisbaar wordt.

[Xenan]

Dynamische talen compenseren vaak het gebrek aan deterministische code completion door de API heel duidelijk en simpel te maken.

Kun je dat onderbouwen met voorbeelden?

[Passenger]

*kuch* http://www.readwriteweb.c...w-twitter-scales-with.php

[Passenger]

Wat een onzin. Bekijk dit lijstje voor de grap eens:
http://www.developerdrive...built-with-ruby-on-rails/

Stuk voor stuk sites die geheel of gedeeltelijk op Ruby on Rails draaien.

En voor al deze applicites geldt ongetwijfeld dat ze gebruik maken van tools die in andere talen (al dan niet scripting talen) geschreven zijn. Het is IMHO dom om er naar te streven om alles in één taal te moeten doen. Of dat nou PHP, Ruby, Java of C# is. Zoals altijd blijft hier ook weer gelden, the right tool for the right job.

[Verwijderd]

Blijkbaar is het voor de Ruby mensen erg moeilijk om code te onderhouden! Basecamp ziet er nog steeds zo uit als 4 jaar geleden en nog steeds werkt dat systeem belachelijk traag en vanuit een project management oogpunt een 'joke'.

[Passenger]

Toch hebben ze een paar miljoen users die het kennelijk geen grap vinden...

Ik zie de relevantie van je stelling niet helemaal. Hoe een bedrijf als 37Signals besluit productontwikkeling uit te voeren staat totaal los van het feit of je in een scripttaal grote applicaties kunt ontwikkelen.

[capono]

Javascript heeft al hel wat pogingen overleeft. Is dus blijkbaar zo slecht nog niet.

[Dreamvoid]

Probleem is dat niemand de concurrentie een overwinning gunt, dus daarom zijn Java, C#/Silverlight en ActionScript/Flash geen universele standaard geworden, en zitten we noodgedwongen nog met JavaScript, een aan alle kanten uitgebouwde en vertimmerde scripttaal die nooit bedoeld was om volwaardige applicaties mee te schrijven.

Ben benieuwd of Google dit keer de concurrentie kan overtuigen. Maar een volgende "Mexican standoff" dreigt weer.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 02:01]

[simplicidad]

Probleem is dat niemand de concurrentie een overwinning gunt, dus daarom zijn Java, C#/Silverlight en ActionScript/Flash niks geworden

Er zit een foutje in uw zin

Probleem is dat niemand gesloten formaten de overwinning gunt, dus daarom zijn Java, C#/Silverlight en ActionScript/Flash niks geworden. En mag ik iets toevoegen ? Terecht !!!!

- Java heeft het patenten probleem
- C#/Silverlight is veel Microsoft only / zaken zoals mono te spijt die altijd achterlopen
- Actionscript/Flash werkt ook enkel maar lekker op Windows platformen en is op mobiele devices een R-A-M-P.

Het enige wat DART zou kunnen redden is dat ze in handen geven van een open consortium of zo, anders zie ik het echt niet overleven. Apple-Webkit/Opera en de Mozilla foundation zie ik - als het echt een meerwaarde bied - het zonder problemen dan implementeren. Het probleem zal zoals zo vaak de ondersteuning van Redmond zijn.

[Reactie gewijzigd door simplicidad op 23 juli 2024 02:01]

[Dreamvoid]

- C#/Silverlight is veel Microsoft only / zaken zoals mono te spijt die altijd achterlopen

Precies mijn punt - C# en Silverlight zijn 100% open (ISO & ECMA zelfs), maar alsnog implementeren Mozilla/Apple/Google het niet en werken ze niet aan Mono omdat het een Microsoft product is. Vanuit hun oogpunt is dat goed te rechtvaardigen - waarom zou je voor je concurrent werken? Liever die developer-uren in het optimaliseren van de eigen JS engine stoppen. Idem met Java trouwens, ook een open taal en open spec (al is daar 1 extra grote gebruiker van: Google met Dalvik). Maar voor de toekomst van het web is het vooral belangrijk dat de *beste* technologie wordt gekozen, niet degene met de beste PR.

JavaScript is ook niet door een open consortium uitgevonden, maar gewoon 100% door Netscape gepusht, met slim lobbywerk is Microsoft aan boord getrokken, en pas later is het als ECMA/ISO standaard aangenomen. Commissies en praatgroepen vinden geen nieuwe dingen uit, ze standaardiseren alleen bestaande technologie.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 02:01]

[kidde]

U begaat een grove vergissing: Volgens vele definities is C# / Silverlight helemaal niet open. Dit 100% open noemen is natuurlijk je reinste nonsens. Begin maar eens te specificeren met wat 'open' is, anders is iedere discissie zinloos.

Kom eens met feiten o.i.d! Een lijstje van openheidscriteria zodat we een score kunnen toekennen, en kunnen vergelijken.

Om even op weg te helpen, hier een voorbeelde van openheidscriteria die van toepassing zouden kunnen zijn op een programmeertaal:

-Wordt deze beheerd door een non-profit organisatie waar iedereen lid van kan worden? ECMA faalt hier overigens keihard omdat niet iedereen lid kan worden van ECMA. Python met bijv. de PSF scoort hier wel hoge punten.
-Kan iedereen input hebben op de standaard?
-Hebben gemeenschaps-leden stemrecht over de toekomstige richting van de programmeertaal? C# en Silverlight falen hier alwéér keihard, alleen MSFT bepaalt de toekomst, in tegenstelling tot bijv. Java (in het verleden dan) en Python.
-Kan iedereen vrij beschikken over de standaard?
-Kan iedereen een afgeleide maken van delen van de standaard en deze hergebruiken?
-Kan iedereen een graits patentlicentie krijgen op patenten die eventueel op de taal van toepassing zijn? Hier zijn de meningen verdeeld, maar met zoveel discussie kunnen we in ieder geval Silverlight zeker niet 100% open noemen.
-Zijn er verschillende implementaties gemaakt door verschillende leveranciers beschikbaar? Ook hier faalt Silverlight wederom keihard omdat van de nieuwste versies altijd alleen implementaties van Microsoft beschikbaar zijn.
-Is alles gespecificeerd, dwz wordt er niet bepaalde informatie achtergehouden?
-Zijn de discussies open? Ook hier faalt ECMA wederom keihard omdat hun beslissingsproces / mailinglijst niet openbaar zijn.

Gezien bovenstaand lijstje komt al het ECMA-spul en het meeste MSFT-spul op een "openheidsschaal" echt niet verder dan een schamele 50%. Het geinige is dat veel Google spul ook rond de 50% scoort, maar op de punten waar MSFT goed scoort, scoort GOOG-spul slecht en vice versa.

[Reactie gewijzigd door kidde op 23 juli 2024 02:01]

[Dreamvoid]

Open als in de klassieke zin des woords: een openbare spec waar iedereen gebruik van mag maken. Al die extra andere voorwaarden zijn een inflatie van het begrip "open" en vertroebelen de discussie alleen maar met FUD.

Dit bijvoorbeeld:

-Zijn er verschillende implementaties gemaakt door verschillende leveranciers beschikbaar?

WTF heeft dit met open of niet open te maken? Als je een open standaard publiceert, en niemand implementeert het, is het dan niet open meer?

En:

-Kan iedereen een afgeleide maken van delen van de standaard en deze hergebruiken?

Yeah, embrace & extend!

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 02:01]

[kidde]

Open als in de klassieke zin des woords: een openbare spec waar iedereen gebruik van mag maken.

Exact, daar zorgen alle bovengenoemde voorwaarden juist voor! Anders gezegd: Iedereen mag gebruik maken van de openbare weg, maar wel onder bepaalde voorwaarden, dus hoe openbaar is open dan? Open op zich zegt natuurlijk geen drol behalve dat het een leuk marketing woordje is, net als het door u gebruikte FUD. Beiden in uw reactie gebruikt totaal zonder inhoud.

Dus hoezo FUD? Verklaar? Wie wordt waarover aan het twijfelen gebracht en bang gemaakt?

Het is wel fijn een beetje met deze termen lopen te smijten maar zonder verklaring zijn het holle termen.

Toepassing door verschillende leveranciers / partijen zegt natuurlijk iets over hoe succesvol een standaard door meerdere partijen gebruikt kan worden.

Immers, als een standaard zgn. open is, maar het lukt nooit iemand er een tweede compatibele implementatie te maken, is de standaard dan wel open? Toen Siemens en Alstom beiden probeerden een ERTMS implemenatie te maken en de resulterende implemenaties waren niet compatibel, zei dat dan niet iets over het falen van ERTMS als open standaard?

Maw: Ik kan een standaard die helemaal niet zo open is het marketingwoordje 'open' op plakken, en hopen dat mensen als u niet verder kijken en er niet inhoudelijk op in (willen) gaan. Als meerdere partijen geen compatibele implementaties kunnen maken, komt echter aan het licht dat mijn standaard kennelijk helemaal niet zo open is.

[Reactie gewijzigd door kidde op 23 juli 2024 02:01]

[A Noniem]

Mono zit anders vrij rap achter de feiten, ik gebruik het zelf vrij veel en het werkt prima

[Rembert]

Tjah... op zich is javascript niet zo heel goed - lees de geschiedenis er maar eens op na. Maar ondertussen werkt het wel prima, zeker met allerlei libraries. Ruimte voor verbetering is er. En zo te zien zou Dart wel eens zo'n verbetering kunnen zijn. Maar dat gaat pas slagen als alle grote browser-bouwers het omarmen. Ik betwijfel of Microsoft dat ooit zal gaan doen zolang Dart onder de vleugels van Google bestaat.

[rbroen]

De tweede zin van het artikel is: "Dart is opensource...", in hoeverre is dit zo? Ik kan zo snel geen onderbouwing vinden voor deze zin.

De naam "Dart" zal wel flink beschermd zijn door Google, dat geloof ik wel.
De dart compilers, zijn die open source?
Kunnen concurrenten zelf compilers gaan ontwikkelen?
De programmeer taal, is die beschermd? Vrijheid hierover heeft natuurlijk voor- en nadelen.

[zenica]

Als je de link naar de sources voor de compiler http://code.google.com/p/...ng_edge%2Fdart%2Fcompiler

[rbroen]

Tnx, ik zie dat de dart-compiler een BSD-style license heeft.

[Reactie gewijzigd door rbroen op 23 juli 2024 02:01]

[Verwijderd]

Tnx, ik zie dat de dart-compiler een BSD-style license heeft.

wat is daar mis mee?

[Dreamvoid]

Een taal kan dan ook niet open source zijn Wat ze ws bedoelen is dat de specificatie openbaar en gratis is. En dat de compiler die ze erbij leveren OS is.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 02:01]

[Cubic X]

Nóg meer talen om voor het web te programmeren.....er wordt alleen maar meer gefragmenteerd zo, om die reden hoop ik dan ook dat deze nieuwe taal faalt.

JavaScript in combinatie met een goed framework of library (jQuery bijvoorbeeld) werkt prima in de huidige tijd!

[Reactie gewijzigd door Cubic X op 23 juli 2024 02:01]

[Nedra]

Tuurlijk werkt een goede library prima, maar met die insteek veranderd er natuurlijk nooit wat. DART geeft weer een mogelijkheid om te zien hoe het anders kan, en dat alleen al kan zorgen voor veranderingen of eye-openers. Als het goed gecompileerd kan worden naar javascript is brouwserondersteuning ook geen probleem toch? standaard DART en gecomileerde javascript als fallback..

[Vexxon]

Hoe laat Dart precies zien dat het ook anders kan?
Waarom zou ik een nieuwe programmeertaal gaan leren wat gecompileerd wordt naar een taal die ik allang ken?

[Verwijderd]

Waarom zou men C bedacht hebben als je assembly kan programmeren?

[Mijzelf]

Voor de portability?

[RielN]

Als het beter is dan bestaande noem ik het vooruitgang. Kunnen we een oude links laten liggen en zo maken we progressie.
Ik hoop dus dat dit beter is en níet faalt

[ultimasnake]

Ik heb nu even niet de tijd om me erin te verdiepen, maar het voorbeeld plaatje laat het naar mijn mening ietwat omslachtige document.getElementByID zien, ik zou eerder hopen op een 'css-selector' in een vergelijkbare vorm als JQUERY dat doet.

Verder valt of staat dit natuurlijk afhankelijk van de overige browsers, anders zal het hetzelfde leed ondergaan als VBScript. Aan de andere kant zit ik zelf nu niet echt te wachten op een nieuwe programmeertaal binnen een website, er is al zo veel wat je moet kunnen/ondersteunen.

[djsubzero]

als je verder in de voorbeeld code kijkt, kom je jquery-achtige zaken tegen.

[YopY]

Zie de W3C Selectors API recommendation en Mozilla's documentatie over de Document.querySelector functie. Het is al een recommendation, en volgens de Mozilla documentatie hebben alle gangbare browsers er al een paar jaar ondersteuning voor (Firefox 3.5, Chrome 1, IE 8, Opera 10). Waarschijnlijk gebruikt JQuery dat ook als de browser het heeft.

[roy-t]

Dit is volgens mij al de 3e programmeertaal ontwikkeld door Google die 'het helemaal zou moeten zijn' maar ook nu weer is het niet duidelijk wat Google's nieuwe taal beter zou moeten doen dan de al lang bestaande concurrenten.

Het wordt mij door dit artikel ook niet duidelijk en van de vorige Google talen heb ik ook niets meer gehoord behalve dan dat er intern gebruik van wordt gemaakt.

Maar het zou nog goed kunnen dat het deze keer anders is natuurlijk, maar ik zou graag de speer punten van de Dart taal duidelijk gemaakt hebben. Nu is het gewoon javascript met een alternatieve syntax voor mij (het compileert immers zelfs naar JS).

[Killemov]

De code die nu in het artikel staat is wellicht niet illustratief genoeg, maar lijkt niet veel meer te doen dan wat ook al met prototype.js kan. HET ding dat Dart beter had kunnen doen is juist strong typing zodat je bij het ontwikkelen direct dor de IDE gecorrigeerd kan worden.
[code]
$("message").update("Hello from Prototype.js");
[/code]

[Reactie gewijzigd door Killemov op 23 juli 2024 02:01]

[sys64738]

Het voorbeeld is inderdaad wat slap gekozen. Haal de methode declaratie weg en het lijkt net javascript.

Ik denk trouwens dat je static typing bedoelt ipv strong typing. Iets kan strong typed zijn zonder dat je tijdens het programmeren weet wat voor type het uiteindelijk wordt (en dus kan de compiler / IDE je niet helpen). Ruby en SmallTalk werken bv. zo.

Verder ben ik benieuwd of Googles derde poging een succesvolle nieuwe taal te introduceren wel aanslaat. Ze weten in ieder geval wel van volhouden maar ik heb er een hard hoofd in.

[Zoijar]

Nu is het gewoon javascript met een alternatieve syntax voor mij (het compileert immers zelfs naar JS).

C++ compileert ook naar C, toch is het een vrij andere taal. Niettemin zou ik ook graag het voordeel van Dart uitgelegd krijgen door iemand...


Ik gaf dus een fout in argumentatie aan. Als je zegt dat dart niets anders is dan JS met een andere syntax omdat het zelfs naar JS compileert, moet (of kan) je dus ook stellen dat C++ niets anders is dan C met een andere syntax omdat het immers naar C compileert. Een stelling waar velen het niet mee eens zullen zijn.

[Reactie gewijzigd door Zoijar op 23 juli 2024 02:01]

[Wolfos]

C++ compileert naar binary, net zoals C.

[Zoijar]

Dat ligt helemaal aan je compiler Veel compilers compilen gewoon lekker naar C zodat ze dan, bijvoorbeeld, de code generatie van gcc of de intel compiler kunnen gebruiken. Een voorbeeld is Comeau C++, niet een van de minste.

Comeau:
"The compiler is based upon the Edison Design Group C++ frontend, also utilized in the Intel C++ Compiler. Rather than produce an executable directly, Comeau C/C++ outputs C code and requires a separate C compiler in order to produce the final program. Unlike the Intel compiler, Comeau C/C++ can employ several back ends."

Dat is sowieso een veel gebruikte strategie tegenwoordig. Je kan een hele andere taal maken en die compilen naar elke taal die expressief genoeg is. In het geval van Dart is dat dus JS. Een slimme zet, want elke browser heeft al JS support. Je gaat ook natuurlijk niet zelf naar binary-form compilen als je een nieuwe taal ontwerpt, want dat is veel te lastig om goed te doen voor elk platform. Nee, je gebruikt daar gewoon de back-ends voor die er al zijn, en die erg goed zijn in geoptimaliseerde binary code te genereren. Als elke taal/compiler een eigen intel optimizer zou moeten bevatten was het snel afgelopen met nieuwe talen.

[Reactie gewijzigd door Zoijar op 23 juli 2024 02:01]

[roy-t]

C++ als pre-processor voor de C compiler was wel zo, maar dat is toch al lang niet meer zo?

[rednek]

C++ als pre-processor voor de C compiler was wel zo, maar dat is toch al lang niet meer zo?

Nee gcc is tegenwoordig zo goed dat hij dat gelijk naar bin zet.

[Zoijar]

Niet gelijk. De gcc front-ends zetten het om naar GENERIC/GIMPLE. Pas daarna wordt er Assembly gegenereerd, en dat wordt daarna pas naar binary vorm omgezet. Maar bijvoorbeeld C, C++ en Java worden allemaal in generic omgezet door de respectievelijke front-ends. Java gaat dan bijvoorbeeld van generic naar java bytecode (of machinecode). Alle talen compilen naar generic op gcc; het gaat nooit "gelijk" naar bin, dat zou ondoenlijk zijn.

Maar dat maakt allemaal niet zo veel uit; het punt was dat als een taal naar een andere taal compilet, dat het dan wel degelijk een hele andere taal kan zijn en zeker niet alleen een andere syntax. Dat is ook wel logisch, want elke taal is wel turing complete en dus in kracht allemaal equivalent. Dat was ook eigenlijk alles dat ik zei, waarop ik meteen naar -1 werd gemod en werd geclaimd dat C++ naar binary compilet, wat een onvolledige uitspraak is.

[Reactie gewijzigd door Zoijar op 23 juli 2024 02:01]

[djsubzero]

Werd tijd. Ik hoop dat het wat word. Javascript trekt op niks. Het is een zootje ongeregeld waarop steeds is verder gebouwd. De syntax wijkt teveel af van de meeste object georiënteerde c-achtige talen, en de compatibiliteit tussen browsers is ook een ramp.

[RayNbow]

De syntax wijkt teveel af van de meeste object georiënteerde c-achtige talen

Dat is op zich niet een valide reden om JavaScript aan de kant te schuiven. Verder vind ik de syntax juist veel op de C-familie lijken.

en de compatibiliteit tussen browsers is ook een ramp.

Dat heeft te maken met het DOM model van de verschillende browsers, niet JavaScript.

[djsubzero]

Maar er is een omschakeling bezig ( al lang) van desktop naar web. Voor een developer die c++ / c# / java gewend is, zitten er in javascript toch een hoop zaken die anders zijn. Buiten de accolades en haakjes zie ik weinig overeenkomsten (classes, interfaces, static typing, ...).
Wat dat DOM model betreft heb je gelijk, daar heb ik trouwens dezelfde mening over. De technologie die momenteel voor het web word gebruikt is gemaakt voor textopmaak, en niet voor rich applications.

[YopY]

Maar er is een omschakeling bezig ( al lang) van desktop naar web. Voor een developer die c++ / c# / java gewend is, zitten er in javascript toch een hoop zaken die anders zijn. Buiten de accolades en haakjes zie ik weinig overeenkomsten (classes, interfaces, static typing, ...).

Dat klopt, maar is dat erg? Javascript trekt meer naar de functionele programmeertalen, en voor het web (maar ook voor de server) heeft dat voordelen zodat je bijv. eenvoudig callbacks kunt aangeven voor asynchron uitgevoerde functionaliteit.

Als je C# gewend bent zul je ook even gaan slikken als je F# voor het eerst probeert. Als je Java gewend bent zul je ook even slikken als je Scala ziet (de functionele onderdelen daarvan). Maar alles heeft zijn plek.