Google komt met Dart-programmeertaal

Een aantal ontwikkelaars bij Google heeft een nieuwe programmeertaal ontwikkeld. Details over het Dart-project van de zoekgigant zijn echter nog schaars; pas volgende maand zal Google op een conferentie meer bekend maken over Dart.

Dart zou een gestructureerde programmeertaal zijn die naar alle waarschijnlijkheid bedoeld is voor het bouwen van webapplicaties en mogelijk een alternatief zal zijn voor javascript. Google zegt in oktober op de Goto-conferentie meer details over de nieuwe programmeertaal bekend te zullen maken.

Bij de presentatie van Dart in oktober is onder andere Lars Bak van de partij. Hij is een van de ontwikkelaars van de V8-javascriptengine die in Chrome is te vinden. Ook Gilad Bracha, software-engineer bij Google, zal bij de presentatie aanwezig zijn. Hij ontwikkelde in 2006 de Newspeak-programmeertaal.

Dart is de derde programmeertaal die door Google-ontwikkelaars naar voren wordt geschoven. In juli 2009 werd Simple gelanceerd, maar deze programmertaal is weinig succesvol gebleken. Een half jaar later lanceerde Google het Go-project. Deze taal heeft meer succes gehad en wordt door de zoekgigant intern gebruikt voor bepaalde taken.

Reacties (106)

[Verwijderd]

Dit is een kopie van een interne mail van vorig jaar: http://markmail.org/message/uro3jtoitlmq6x7t

Daar wordt dit project nog "Dash" genoemd. In de mail wordt onderstreept dat Google doorgaat met Javascript en Dart proberen zo breed mogelijk in de markt te krijgen.

Als iemand de aanname kan doen dat Javascript "fundamentally broken" is voor grote apps, tool support en performance, dan is Google dat wel. Ik denk dat iedereen het er mee eens is dat programmeren op de client veel beter kan en moet om webtechnologie ook voor complexe, grote UI in te zetten.

Ik vind het zelf goed dat ze dit zo gaan doen. Concurrentie is altijd goed, en ze zullen Javascript voorlopig niet los laten. Toen Google Chrome uit kwam had ook iedereen zo iets van "we hebben toch al Firefox?" Uiteindelijk heeft die performance race een paradigm shift opgeleverd en worden Web apps nu ineens heel serieuze applicaties. Als Dart voor de concurrentie zorgt, en Javascript vervangt of dwingt het te verbeteren, dan is dat winst voor iedereen.

[garagaholic]

Tja, het zou niet het enige, eerste of laatste zijn wat in 'het wereldje' als "fundamentally broken" wordt aangemerkt en gewoon tot in de lengte van dagen gebruikt wordt (wellicht zelfs veel meer dan de verbeteringen erop!). Overigens zeggen ze in die mail niet dat het kapot is, maar dat het zijn fundamentele fouten kent die niet 'gemakkelijk' op te lossen zijn met addendums.

Er moet in mijn ogen overigens wel iets heel speciaals gebeuren, willen mozilla, MS en Apple ineens Dash/Dart opnemen in hun browsers... Maar goed, wellicht wordt het ineens heel erg populair .

[Vytek]

De vraag waarom een nieuwe taal beantwoord ik met een quote uit een blog post van Zef Hemel:

“Stop inventing languages!”
An oft heard critique when any new language is introduced is “Why a new language? Please stop inventing new languages!” This sentiment is wrong. If people would not be inventing new languages, we would still be writing assembly code, or be stuck writing COBOL. It is through experimentation that we came to the current state of programming languages. We’re not there yet. We’re not done. Therefore, any new language should be welcomed and studied. While most will not survive, they may influence their successors.

[Reactie gewijzigd door Vytek op 23 juli 2024 06:27]

[Antipater]

Inderdaad. Ik zou nog verder willen gaan, er zou veel meer geinvesteerd moeten worden in nieuwe talen. Het is bizar hoe snel de hardware is veranderd en wat voor nieuwe problemen door software moeten worden opgelost. Deze veranderingen zijn vele malen sneller gegaan dan dat programmeertalen zich hebben ontwikkeld.

Het kost voor een nieuwe, praktische taal zo'n 5 tot 10 jaar om volwassen te worden en dan nog zoiets om een userbase op te bouwen. Daarnaast duurt het vele jaren voordat de lessen van innovatieve en academische talen ingang vinden in de praktische talen. Van alle nieuwe talen zijn er ook maar een paar succesvol. Alles in de IT gaat snel, maar dat geldt niet echt voor programmeertalen.

Java zal bijvoorbeeld pas bij versie 8, waarschijnlijk over enkele jaren, ondersteuning krijgen voor lambda expressies. Het heeft de makers van Java dan meer dan twintig jaar gekost om te realiseren dat ze een feature nodig hebben die nu al zowat een halve eeuw oud is. Of neem Ruby als voorbeeld. Al is het nu best wel mainstream, sommige mensen zien dit nog als een 'hippe nieuwe' taal, maar Ruby is al in 1993 bedacht. Volgens mij moest de pentium toen nog uitkomen.

[Gamebuster]

Ruby

Mijn primaire programmeertaal

[Shadoxfix]

Is het wel een slimme zet om een nieuwe programmeertaal te maken?
Meeste mensen die nu programmeren hebben als een programmeertaal waarmee ze het liefst werken.
De enige reden om over te stappen die ik zou kunnen bedenken is als deze programmeertaal krachtig en efficiënt is.

[Freeaqingme]

Why Programming languages? (via)

Weliswaar geschreven door een belg , maar zeker interessante stof.

[mr.paaJ]

Of een redelijk efficiënte maar makkelijke vergevingsgezinde taal. Genoeg nieuwe mensen die weinig eisen stellen maar wel wat willen maken.

[CodeCaster]

Een taal moet juist niet vergevingsgezind zijn, want als jij A tikt waarmee je eigenlijk ook B kunt bedoelen, is het aan de interpreter om te interpreteren wat jij bedoelt. Dat gaat al mis bij talen als CSS en PHP, nóg een taal met die insteek zal niet veel goeds doen.

[Zunflappie]

Waarom mag het niet 'vergevingsgezind zijn'?

Kan software niet intelligent genoeg worden gemaakt om kleine foutjes zelf te snappen en te verbeteren?

[Antipater]

Waarom mag het niet 'vergevingsgezind zijn'?

Kan software niet intelligent genoeg worden gemaakt om kleine foutjes zelf te snappen en te verbeteren?

Dat kan wel, maar is alleen zinvol als het 100% duidelijk is wat er wordt bedoeld door de programmeur, en dat is maar zelden het geval. Het is namelijk veel erger om met subtiele fouten te zitten terwijl je programma wel draait, dan een programma dat niet door de interpreter/compiler heenkomt maar wel direct duidelijk maakt wat je verkeerd doet. Dat laatste lijkt vervelend, maar is in feite vele malen gebruiksvriendelijker.

Ik heb geen analogie met auto's voorhanden dus dan maar deze: als je een handgeschreven recept voor medicijnen krijgt die de apotheker niet goed kan lezen, wil je ook liever dat ie even de huisarts belt dan dat je een medicijn 'op de gok' meekrijgt.

[HerrKauwer]

Nee, omdat je dan niet weet wat je kunt verwachten. Met hele rare problemen die heel moeilijk te vinden zijn als gevolg. Ik heb veel liever een duidelijke foutmelding dan een taal die zelf uit gaat zoeken wat ie moet doen

[Verwijderd]

CSS is geen programmeer taal maar een 'markup' taal, deze moeten net wel vergevingsgezind zijn. Dit is hun kracht en flexibiliteit.

In een markup taal kan je geen berekeningen of logica uitvoeren, het is enkel een beschrijving die de applicatie moet interpreteren. (Idem voor XML en HTML)

Het is maar goed ook dat de browser niet crashed zodra hij iets ziet dat hij niet begrijpt in CSS, zo zal je website nog altijd werken in oude browsers als je border-radius:5px; gebruikt. Een oude browser die dit niet begrijpt zal het gewoon negeren, een nieuwe browser zal het gebruiken.

Bij PHP daarentegen, wel een programmeer taal heb je volledig gelijk.

[mr.paaJ]

Da's waar, er zijn genoeg makkelijke talen

[Verwijderd]

Wat we nodig hebben is juist een moeilijke taal; namelijk een taal waar een compiler naartoe kan vertalen. Dan krijgen we juist meer mogelijkheden, want dan kunnen de makkelijke talen weer als ingang voor die compilers dienen.

[theemstra]

En omdat Javascript enorm vervelend is om te schrijven, omdat niet iedere browser alles accepteerd en anders uitvoert.

[YopY]

Maar dat ligt hem niet aan de taal, maar aan de niet-standaard API's die elke browser aanbiedt voor bijvoorbeeld AJAX.

[Verwijderd]

Het gaat niet alleen om de niet-standaard API's; zelfs de w3c standaard api's worden niet door iedereen geimplementeerd.

Om een overzicht te geven van de ondersteuning van w3c standaarden (standaarden met de status "working draft", "candidate rec." "proposed rec." en "recommendation"):

IE 9.0: 54%
Firefox 6.0: 86%
Safari 5.1: 77%
Chrome 13.0: 90%
Opera 11.5: 73%

Ter illustratie ook enkel w3c standaarden met "recommendation" status:

Internet Explorer 9.0: 73%
Firefox 6.0: 93%
Safari 5.1: 93%
Chrome 13.0: 93%
Opera 11.5: 98%

Bron: http://caniuse.com

Het grote probleem met w3c standaarden is dat ze pas bruikbaar zijn als elke major browser de standaard ondersteunt. Bij internet explorer (zie bovenstaande overzicht) is dit 54% of 73% van de standaarden. Dat is vervelend, want hierdoor vervalt een groot deel van de features, simpelweg doordat het niet cross-browser werkt.

Een paar voorbeelden van ontbrekende features zijn MathML, SVG filters en SVG animations.

Daarnaast is het ook goed om te noemen dat er nieuwe versies van EcmaScript zijn. Toegevoegde features zijn generators en array comprehensions: https://developer.mozilla.org/en/new_in_javascript_1.7

Een simpel voorbeeld:

var a = 1;
var b = 3;

[a, b] = [b, a];

Dit kan men ook gebruiken voor multi-return values van functies:

function f() {
return [1, 2];
}

var a, b;
[a, b] = f();

Jammer genoeg duurt het nog even voordat dit in elke browser is ondersteund. Echter zie ik zelf meer mogelijkheden in de taal uit te breiden in plaats van een nieuwe taal introduceren. Door Dart te introduceren, krijg je fragmentatie in de clientside-scripting-markt. Uiteindelijk komt het op het volgende neer: Dart en JavaScript hebben het zelfde probleem; het is of cross-browser of het wordt hem niet.

edit: typo.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:27]

[Verwijderd]

Tja als we nu gewoon een soort bytecode taal hadden, die met moderne compilertechnieken naar geoptimaliseerde native code kon worden vertaald, dan kon iedere webdeveloper zijn eigen "browser" meesturen met de html, mocht ie dat willen...

[Verwijderd]

Ze zouden inderdaad beter af zijn om eerst alle browsers dezelfde standaarden te laten hanteren, en niet allemaal eigen varianten op de standaarden, of van die 'leuke' features / prototypes etc.

[Verwijderd]

Beter nog, gewoon een soort heel simpele basis-taal op iedere browser draaien. Iets dat dicht bij een soort machinetaal ligt, waar gewoon geen inconsistenties in kunnen komen. En de graphics API gewoon opengl maken.

[JeromeB]

Die platformen zijn er eigenlijk al heel lang, bijvoorbeeld Java, Shockwave/Flash en Silverlight. Het probleem is dat de grote browser-makers nooit een consensus zullen bereiken. Iedere browser-maker stelt andere eisen aan zo'n platform en vaak willen ze het liefst een eigen platform pushen. Het W3C of het ECMA zou de specificaties voor zo'n platform kunnen vastleggen. Helaas hebben deze organisaties vaak laten zien dat dit proces vrij log is en innovatie vaak in de weg staat

[Verwijderd]

Het stomme is dat juist zo'n bytecode-basislaag veel makkelijker is om consensus over te krijgen (imho). Dat gedrocht van html/javascript/dom/css/etc./etc. is toch een veel lastiger iets, zou ik zo zeggen.

Bytecode hoeft helemaal niet complex te zijn. Java is veel te complex, omdat er ook abstracties zoals "classes", en garbage collection in zijn verweven. Maar deze abstracties zorgen er alleen maar voor dat de taal minder generiek wordt. Je kunt in zo'n taal zelf bijvoorbeeld geen nieuwe taal implementeren, want dat wordt veel te sloom.

NaCl van google heeft volgens mij de beste kans van slagen, al mogen ze het wat mij betreft veel meer ontkoppelen van de browser-apis (zoals de DOM).

[Ook al Bezet]

En omdat Javascript enorm vervelend is om te schrijven, omdat niet iedere browser alles accepteerd en anders uitvoert.

Ik denk niet dat het toevoegen van een nieuwe taal die situatie zou verbeteren. Dan moet je namelijk ook nog eens rekening gaan houden met browsers die Dart niet ondersteunen en ben je toch weer met Javascript bezig. Aangezien dit project volledig uit de koker van Google lijkt te komen kan ik me voorstellen dat het lang zou duren voordat andere browsers het gaan ondersteunen.

[boontje88]

In deze vroege memo (waar ze het overigens nog over Dash hebben), spreken ze over een converter die Dash/Dart kan omzetten naar javascript, zodat je apps ook nog in legacy browsers zou kunnen draaien. Nu is het natuurlijk maar de vraag of deze browsers snel genoeg zijn om je Dart brouwsel te kunnen draaien, maar dat even terzijde

Een groot nadeel van javascript vind ik zelf dat het bij grotere applicaties snel onoverzichtelijk wordt. Je kunt veel oplappen met tal van libraries (jQuery + Backbone + Underscore + Tmpl + Modernizr is geen ongebruikelijk combinatie), maar de syntax blijft gewoon niet zo heel lekker leesbaar. Wat dat betreft klinkt dit wel een beetje zoals Coffeescript (kan ook naar JS converten), maar Google heeft het daarnaast ook over fundamentele performance improvements. Dat is natuurlijk heel welkom voor hun javascript intensieve applicaties zoals Maps.

[Verwijderd]

Als je in C hebt geprogrammeerd en de pointers snapt, dan is javascript best te begrijpen. Ik vind het bijvoorbeeld een leuke flexibele taal. Visual Basic of Basic vind ik pas een bagger taal. goto exit ;-)

[Precision]

Ik gok en hoop dat ze 't op een manier maken waarbij Dart een snelheidswinst heeft op Chrome en alle browsers die het ondersteunen en dat anders de output gewoon een fallback is naar javascript. Dus dat Dart javascript output.

[Precision]

Er komen meer en meer libraries en frameworks uit die dat probleem voor jou oplossen bvb jquery maar er zijn er veel meer

[Tarabass]

Maar daar hebben we toch GWT al voor, java schrijven en compilen als javascript?

Ik gebruik liever een framework als jQuery, dat vind ik erg fijn en geeft veel mogelijkheden tot het schrijven van snelle code. Daarnaast zie ik het niet snel gebeuren dat bedrijven 'even' overstappen op een nieuwe taal, omdat het makkelijker zou zijn.

[SuperDre]

Daar veranderd een nieuwe taal niets aan.. It's just another language..

[Verwijderd]

Javascript is een bijzonder beest an sich, maar zeker niet "vervelend" om in te schrijven. Daarbij houdt javascript zich alsnog aan de standaarden, omdat het de standaard is. Heel veel browsers hebben desondanks hun eigen interpretatie van JS, met Internet Explorer in het bijzonder waarvoor je als webdeveloper vaak nog je in allerlei bochten moet wringen om de boel aan de praat te krijgen.

Een nieuwe taal ontwikkelen is prima, en heel interessant. Maar of het snel bruikbaar zal zijn is de vraag. Wellicht dat er een parser wordt ontwikkeld voor Dart > JS?

[84hannes]

De meest gebruikte programmeertalen van nu zijn bepertkt tot een enkel platform (C#), in handen van een bedrijf dat er niet om schuwt om zaken waar ze niet genoeg winst op maken af te stoten (Java) of in de basis stokoud (C/C++). Als een nieuwe taal de voordelen van huidige scripttalen weet te combineren met de efficientie van C(++), dan is er zeker een markt voor.
@MrMonkE
Ik bedoelde eigenlijk alle .net talen, maar je hebt gelijk. .net is een plaform. En Mono is door Novell (Attatchemate) gedumpt, dus het is maar te betwijfelen of dat er over 5 jaar nog is. j# verscheen in 2002, c# al in 2001. Verder is er gewoon niet echt een markt voor mensen die in de Jva-taal op een .Net platform willen programmeren, dus j# is ook praktisch dood.

[Reactie gewijzigd door 84hannes op 23 juli 2024 06:27]

[MrMonkE]

.NET is een framework, geen programmeertaal.
Er is een hele lading aan talen waar .NET mee kan worden gebruikt waaronder c++, c#, vb.net, delphi enz enz.. (wel bijna 100 denk ik)

Tevens is er een opensource vorm die MONO heet.

Wanneer er geen gebruik wordt gemaakt van de microsoft specifieke namespaces zal een programma net zo makkelijk op mono als op .net moeten draaien.

-editje-
Wat ik ook nog even wil zeggen.
Microsoft had eerst j#, maar toen ging Sun (nu Oracle) vervelend doen.
Daardoor zijn ze volgens mij aan c# begonnnen.
Ik kan me voorstellen dat Google dat wil voorkomen.

[Reactie gewijzigd door MrMonkE op 23 juli 2024 06:27]

[ThomasG]

.NET is inderdaad een framework, maar tegelijkertijd ook een platform, met een overkoepelende taal, namelijk MSIL (wat erg veel weg heeft van assembler). De programmeertalen voor .NET (met uitzondering van o.a. C++) kun je zien als een soort van frontend voor MSIL. Het ligt er aan welke taal je prettiger vind om mee te werken. Een programma geschreven in C# of VB.net zou in principe de zelfde MSIL code moeten opleveren (uitzonderingen op bepaalde dingen daargelaten).

Daarnaast moet je het wel goed zeggen natuurlijk, C# was helemaal geen vervanger van J#, beide talen bestaan gewoon naast elkaar. J# was bedoeld om het voor Java programmeurs gemakkelijker te maken om over te stappen op het .NET Framework.

[YopY]

C++ is niet per definitie efficiënt - je moet een goeie programmeur zijn om alles eruit te halen wat erin zit. Geheugenmanagement en concurrency zijn best lastig in C/C++, om maar een voorbeeld te geven.

[Dreamvoid]

in handen van een bedrijf dat er niet om schuwt om zaken waar ze niet genoeg winst op maken af te stoten

Uh, dit geldt voor alle produkten ooit gemaakt door elk bedrijf.

Maar het is logisch, Google is 'keeping up with the Joneses'. Apple en Microsoft hebben al hun eigen talen (Objective-C en C#), dan kunnen zij niet achterblijven toch?

[Beatboxx]

Inderdaad, voor grote websites zoals T.net is een script dat 15% minder serverload vereist van gigantishe waarde. Waarschijnlijk van genoeg waarde om één ontwikkelaar 2 weken op cursus te sturen.

[Verwijderd]

Wat ik niet snap is dat er gesproken wordt over een programmeertaal, in het artikel staat dat het een alternatief wordt voor Javascript. Javascript is ook een scripttaal.

Beide zullen een client-scripttaal zijn dus qua server load gaat het geen bal schelen

[Sir Isaac]

Dat is wel erg kort door de bocht. Sommige talen zijn lastiger te intepreteren bijvoorbeeld omdat een teken verschillende betekenis heeft. Dan moet de interpreter uitzoeken wat er wordt bedoeld en dat kost cpu cycles. Een niet web gerelateerd voorbeeld is Matlab, waar bijvoorbeeld de ' verschillende betekenissen heeft. En zo zijn er meer verschillen tussen talen die impact hebben op het cpu gebruik.

[Spockz]

Dit is alleen van enig belang bij geinterpreteerde talen. Zodra je naar een gecompileerde taal gaat heb je hier nog maar 1x `last' van. Namelijk, bij het compileren. Daarna maakt het allemaal niet meer uit wat het symbool kan betekenen.

[ZpAz]

Mja, en wat maakt het verschil tussen een programmeer en een scripttaal.

Kijk je naar Node.JS dan gebruik je gewoon Javascript, maar het wordt voordat het uitgevoerd wordt wel gecompileerd in plaats van geïnterpreteerd.
Netzoals Javascript in de meeste moderne browsers (o.a V8 van Chrome en Nitro van Safari) ook gecompileerd wordt.

Google's meeste projecten kennende is het gewoon dat je iets schrijft in Dart, en deze het voor jou omzet naar HTML en Javascript wanneer nodig. Zodat het gewoon in alle hedendaagse browsers blijft werken.

Netzoiets als Cappuccino bijvoorbeeld. Je schrijft in een 'Objective C like' taaltje. En als het uitgevoerd wordt wordt het voor je om gezet in HTML, CSS en Javascript. Een voorbeeld wat ik hiermee gemaakt heb is bijvoorbeeld een Flickr browser hier is dus voor mij geen regel HTML, CSS of JS aan de pas voor gekomen.

[Reactie gewijzigd door ZpAz op 23 juli 2024 06:27]

[Cergorach]

mogelijk een alternatief zal zijn voor javascript

Wellicht dat het net zoiets wordt als java en javascript. Java kan prima serversided draaien, javascript gebruik je voor clientside. Wellicht verdwijnt het verschil tussen clientside en serverside en wordt dezelfde taal gebruikt voor beide, ik weet het niet. Er zijn te weinig details bekend.

Waar ik wel weer bang voor ben is dat na een jaar Google het hele zootje zonder pardon de vuilnisbak in gooit, ik zou als ontwikkelaar daar heel huiverig voor wezen. We zien het eerlijk gezegd wel, er zijn over de laatste decennia tig talen opgedoken, ook tig weer verdwenen.

Een lijst met programmeertalen door de jaren heen:
http://en.wikipedia.org/w..._of_programming_languages

[MrMonkE]

".. en mogelijk een alternatief zal zijn voor javascript."

Zelf denk ik dat google gewoon onder het Oracle/Java juk vandaan wil en een volwaardige eigen programmeertaal wil hebben.

[dcm360]

In tegenstelling tot wat de naam doet vermoeden heeft JavaScript maar weinig met Java en daarmee ook weinig met Oracle te maken.

[Ook al Bezet]

Inderdaad, voor grote websites zoals T.net is een script dat 15% minder serverload vereist van gigantishe waarde. Waarschijnlijk van genoeg waarde om één ontwikkelaar 2 weken op cursus te sturen.

Javascript draait in de browser, niet op de server.

[Jo-W]

Oh? Wij draaien javascript in de server. Op deze manier werken we met maar 1 taal en delen we code tussen de server en de browser

[EYE_EYE]

Ben ik wel benieuwd naar in welke engine je die JavaScript draait op de server.
(Serieus)
En hoe je dan communicatie regelt tussen clients en server via JavaScript.
(openminded)

[Verwijderd]

Wij gebruiken Lotus Domino XPages, en daar gebruik je ook server-side javascript. Deze javascript wordt gecompileerd naar pure Java bytecode.

Het voordeel is dat je zowel client- als serverside, dezelfde programmeertaal gebruikt. Door de achterliggende compilatie naar Java, kan je ook zonder problemen andere java-classes en servlets aanroepen (in de serverside JS dus).

[boe2]

serverside javascript, wat?

[GoddXX2]

http://nodejs.org/

[mathijsc]

Zie je best vaak. Er zijn hele webservers in javascript geschreven.

[Gamebuster]

Ik heb aardig wat serverside JS ervaring achter mn kiezen

NodeJS bijv, maar ook Rhino (js to java compiler)

[Verwijderd]

Welke javascript implementatie gebruiken jullie als ik vragen mag? Voorzover ik weet is namelijk alleen SpiderMonkey (van Mozilla) geschikt voor een multi-threading server, dus het is interessant om alternatieven te weten.

[Denni]

Echter is dit geen server-side-programmeertaal en het is dus onwaarschijnlijk dat deze taal de server veel zal ontlasten...

[Gamebuster]

NodeJS heeft een uitstekende performance, aanzienlijk beter dan de standaard php interpreter

[Verwijderd]

Ik denk dat het hier gaat om een clientside-taal; aangenomen dat de bestandsgrootte gelijk blijft, zal er voor de server niets veranderen. Wat wel kan, is dat Dart de ontwikkeltijd kan reduceren. Dit bespaart de developer uren en dus kan er meer worden gedaan in minder tijd.

Of het gaat hier om een server- en clientside-taal, waarbij grens tussen server en client vervaagt. Aangezien ze noemen dat het een vervanging van JavaScript wordt, ga ik er van uit dat het om een clientside-taal gaat.

[Tharulerz]

Hoe gemakkelijk javascript ook is, het heeft zijn beperkingen, en als deze taal zaken anders of efficiënter aanpakt, dan zie ik niet in waarom je die niet zou kunnen gebruiken (desnoods enkel voor intern gebruik).

Het probleem onstaat pas als Google deze promote als het nieuwe javascript maar andere browsers dit niet implementeren, en web developers moeten developen in 2 talen (wat ze dus niet gaan doen, en waardoor javascript de basis blijft).

[Blokker_1999]

Met die redenering werd er vandaag enkel maar in assembler geschreven. Of had C++ en C# overbodig geweest.

Ook programeertalen moeten evolueren en met de tijd meegaan. Stilstaan == achteruitgaan.

[MrDoodoo]

Volgens deze redenatie hadden .NET, Delphi, Java, of noem maar op ook nooit gemaakt hoeven worden. Dan hadden we nog met FORTRAN gewerkt

[marcvangend]

Ach ja, hadden we wel een nieuwe zoekmachine nodig? We hadden toch Altavista? En hetzelfde geldt voor die browser en dat mobiele OS... Wat mij betreft heeft Google al vaak genoeg laten zien dat ze met interessante en zinvolle verbeteringen kunnen komen (al is niet alles een succes), dus ik heb goede hoop.

[rboerdijk]

Mensen die echt kunnen programmeren, interesseert het niet welke taal ze gebruiken. Die hebben binnen de kortste tijd een nieuwe programmeertaal op een dusdanig nivo dat ze hem effectief kunnen gebruiken ( details kosten, toegegeven, wat meer tijd).

[theemstra]

DaRT was toch een Microsoft applicatie voor een soort bootable live Windows omgeving?

[kmsch]

Dat is DaRT ja, niet Dart Ongetwijfeld gaat over die namen weer hommeles komen.

[Shadoxfix]

Microsoft Diagnostics and Recovery Toolset(DaRT).
Op de Microsoft pagina staat dat het gebruikt kan worden voor systemen die niet meer booten.

[theemstra]

@koeny3
Jup

@mutakalah
Klopt, heb het wel eens gebruikt

[Jormungandr]

DART is ook het OS van de EMC Celerra NAS.

[Verwijderd]

Dart is ook een sport, zo kunnen we nog wel effe doorgaan!

[Verwijderd]

En een auto

Ik verwacht dat Dart een taal is die javascript zal genereren.
Zoals Scott Hanselman al in blog aangeeft:

JavaScript is an assembly language. The JavaScript + HTML generate is like a .NET assembly. The browser can execute it, but no human should really care what’s there. - Erik Meijer

Daar hoeven maar een paar mensen in te programmeren.
Normale stervelingen gebruiken frameworks en generatoren.

[Dlocks]

Ik ken wel de DoubleClick DART-cookie die Google al jaren gebruikt:

De DoubleClick DART-cookie wordt door Google gebruikt in de advertenties die worden weergegeven op websites van partners

Bron: http://www.google.nl/supp...n/answer.py?answer=100557

[eagle00789]

ik vraag me af wat voor een nuthet heeft dat google zich bezig blijft houden met het ontwikkelen van programmeertalen. we hebben er al genoeg. nog een er bij....
maak het maar lekker onoverzichtelijk voor de gebruikers en admins

[YopY]

Gebruikers en admins hebben niks te maken met programmeertalen, zolang de zooi maar werkt. Developers hebben er wel mee te maken, en die zouden de beste taal voor een bepaalde taak moeten uitkiezen (als ze er verstand van hebben).

Ikzelf ben er vlak voor om een alternatieve taal voor client-side taken aan te bieden, aangezien de keuze daar nogal beperkt is. Je hebt Javascript, talen zoals Coffeescript die vertaald worden naar Javascript (en een bakkes aan ongemakkelijkheden oplossen), maar (vast) ook wel script interpreters die andere talen kunnen lezen - maar dan zit je met overhead, aangezien de interpreter ook weer in Javascript geschreven moet worden.

We wachten geduldig af.

[Blokker_1999]

Op termijn misschien als vervanger voor alle andere talen die vandaag op android/chromeos gebruikt worden om patent/IP kwesties zoals met Oracle uit de weg te gaan.

[dZinee]

Opmerkelijk dat google zelfs hiermee aan de slag gaat...Ben het gedeeltelijk eens met Mutakalah, maar af en toe moet er natuurlijk innovatie zijn..

Soms bestaande dingen wegzetten om nieuwe dingen te laten ontstaan. ben benieuwd hoe google dit weer gaat doen

[themole]

Je weet nog te weinig over deze programmeertaal om iets te zeggen over het nut van de taal. Het punt is dat door de jaren heen veel programmeertalen zijn gekomen en zijn gegaan. Alle momenteel grote programmeertalen zijn ooit klein begonnen.

Als alternatief voor Javascript zou ik het misschien wel omarmen. Het lastigste in dit geval zou de ondersteuning voor deze taal zijn. Alle grote browsers ondersteunen Javascript, google kan ondersteuning zo in chrome inbouwen. Of Mozilla, Microsoft en Apple zin hebben om deze taal te gaan ondersteunen is dus nog maar de vraag. Als maar 20% van de gebruikers Dart ondersteund als webontwikkelaar moet ik kiezen tussen javascript of Dart, dan kies ik voor Javascript.

Tuurlijk kan je altijd met een plugin werken, maar dit is natuurlijk een drempel voor de gebruiker.

[Reactie gewijzigd door themole op 23 juli 2024 06:27]

[Wolfos]

Als jij een plugin nodig hebt om je site te laten werken, dan vind ik dat jij iets niet goed doet inderdaad.

[Dreamvoid]

De plugin van nu is de webstandaard van morgen...

[Defspace]

Als ik zou speculeren waarom er een nieuwe taal komt dan zou ik zeggen om client en server side volledig transparant te maken.
Nu doe je server bijvoorbeeld in php/python/ror/java/cf en client met javascript. Als je nu een taal hebt die zowel server als clientside hetzelfde is dan kan dat enorm uitmaken.

[Verwijderd]

Een taal die alles kan ?
http://en.wikipedia.org/wiki/Ada_%28programming_language%29
Was ook een groot succes !

Talen worden succesvol als ze van extra waarde zijn in een specifiek toepassingsgebied. Php vind ik maar een rottaal, maar het is wel de beste taal om een website te bouwen. JS heeft ook zijn nadelen, maar het is het beste wat er is om client-side browser-apps te maken. Daardoor worden nieuwe talen populair. Niet omdat ze voor alles beter zijn.

[ZpAz]

Javascript! Met Node.JS kan je Javascript Serverside doen, en clientside werkt Javascript uiteraard al

[Moonsurfer_1]

Verdorie, daarmee hebben ze mijn idee ingepikt (no kidding)... Ik wou zelf een prototype van iets dergelijks uitwerken voor mijn masterproef binnen een jaar...

In mijn versie van het idee zou het dan mogelijk zijn om zowel interpreted (zoals javascript), ofwel intermediate (zoals .NET met een just-in-time compiler) ofwel compiled code op te nemen (native code in een sandbox voor zware applicaties). Het voordeel van intermediate of compiled code zou ook zijn dat je code niet zomaar zichtbaar zou zijn voor de buitenwereld...

Ik heb dit idee gekregen omdat ik dacht aan: wat ontbreekt er nu om cloudcomputing helemaal populair te krijgen en ook daadwerkelijk alle applicaties op het web te laten verlopen? En toen dacht ik: een object-georienteerde client-side webtaal die als vervanging voor flash en javascript zou kunnen dienen, die open-source is en die het mogelijk maakt om zware applicaties (zoals onder andere games) gemakkelijk op het web te draaien en waar de ontwikkeltijd niet veel langer is dan java, en ook de syntax hierop gelijkt.

Helaas, nu google met dit idee komt, zal ik naar iets anders moeten zoeken voor mijn masterproef...

[Dreamvoid]

die open-source is

Welke taal je ook gebruikt, het hangt nog altijd van de developer af of hij zijn code open source wil maken. Je kan moeilijk verplichten dat iedereen die je taal gebruikt, zijn code openbaar moet maken. Welke licensie wil je dan verplichten?

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 06:27]

[Verwijderd]

Programmeertaal? Euhm... Scripttaal eerder.

[lamme23]

Scripten is ook programmeren. Je hoeft alleen niet te compileren.

[Verwijderd]

Scripten is ook programmeren. Je hoeft alleen niet te compileren.

Jup, dat is 't voordeel van scripten. Maar even on-topic, Is het in deze tijd wel slim om met een nieuwe taal te komen? Steeds meer talen veranderen in deze tijd, asp.net word minder gebruikt, html 5 duwt flash weg.

Maar, misschien is 't toch wel slim, omdat er zoveel weggaan, kun jij ze als groot bedrijf genaamd Google vervangen. En het is meteen populair omdat je echt "Het" internetbedrijf bent. Dus dan zou je twee vliegen in één klap hebben, dat is toch al helemaal geweldig?

[Dreamvoid]

HTML5 en Flash zijn geen talen, JavaScript en ActionScript zijn (script)talen.

[Verwijderd]

Scripten is niet programmeren.

Als je programmeert maak je iets nieuws wat eerder nog niet bestond (zelfs al had iemand anders exact hetzelfde gemaakt). Als je script gebruik je functies die door iemand anders verzonnen zijn om een geheel voorspelbaar resultaat te krijgen.

Daarbij heb je bij een scripttaal altijd nog een interpreter nodig.

[Daspeed]

Scripten is wel degelijk programmeren

A scripting language, script language or extension language is a programming language that allows control of one or more applications. "Scripts" are distinct from the core code of the application, as they are usually written in a different language and are often created or at least modified by the end-user.[1] Scripts are often interpreted from source code or bytecode, whereas the application is typically first compiled to native machine code.[2]

Zowel bij scripttalen als bij gecompileerde talen wordt er vaak gebruik gemaakt van functies die al bestaan. Die zitten dan meestal in een API.

Daarnaast bestaan er talen die zowel geïnterpreteerd als gecompiled kunnen worden en volgens jouw definitie zouden die niet kunnen bestaan.

[Verwijderd]

Wikipedia quoten heeft compleet geen zin, aangezien lang niet alles wat op wikipedia staat waar is.

Een taal is in principe niets anders dan een verzameling van regels (grammatica, spelling) die bepalen hoe die taal werkt. Je hebt hierin gesproken/geschreven (natuurlijke) talen, zoals bijvoorbeeld Nederlands en Engels. En computertalen zoals COBOL, C, C++, C#, Java, Javascript, (Visual) Basic, enz.

Zodra je een compiler maakt die van een stukje tekst in een bepaalde taal geschreven weer native (byte) code maakt of vertaalt naar een taal die door een runtime begrepen is (.NET of JRE) spreek je over een programmeer taal. Wanneer je een programma's hebt die de taal kan lezen en direct kan uitvoeren zoals bijvoorbeeld een webbrowser, heb je het over een scripttaal. Dus er zullen ook best talen kunnen zijn die beide zijn. (Python bv)

Het doel van javascript is het bieden van een mogelijkheid om eenvoudig interactieve mogelijkheden op een website te leveren. Als jij een compiler zou maken die JS code naar bytecode omzet zou je zelf extra water bij de wijn moeten doen. Want JS werkt met het idee van er is een "Document" object waar het op werkt. In een object geörienteerde programmeer taal (C#, Java) begin je altijd als eerste met het opzetten van een "Applicatie object" waar je functies van aanroept en zo nodig nieuwe functies aan toevoegd. (Want tja, alleen een leeg applicatiescherm is niet zo bijzonder). Unmanaged talen zijn dan nog een stapje lager waarbij je zelf ook het geheugen moet beheren. (en lagere niveaus gaan zelfs nog verder)

Het gebruiken van APIs of Frameworks heeft niets te maken met of het een script of programmeertaal is. In principe gebruikt tegenwoordig élk programma wat binnen een OS draait een of andere API of Framework.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:27]

[Daspeed]

Waar is jouw bronvermelding voor alle beweringen die je maakt?

Douglas Crockford (auteur van 'JavaScript: The Good Parts'):

JavaScript, aka Mocha, aka LiveScript, aka JScript, aka ECMAScript, is one of the world's most popular programming languages.

Op de site van Python:

Python is a programming language that lets you work more quickly and integrate your systems more effectively.

Site van Ruby

A dynamic, open source programming language with a focus on simplicity and productivity.

Al die mensen weten het vast minder goed dan jij

Als ik in een taal aan het werken ben die zowel geïnterpreteerd als gecompiled kan worden, weet ik dan volgens jouw definitie pas na interpretatie of compilatie of ik heb geprogrammeerd?

[R4gnax]

Het doel van javascript is het bieden van een mogelijkheid om eenvoudig interactieve mogelijkheden op een website te leveren. Als jij een compiler zou maken die JS code naar bytecode omzet zou je zelf extra water bij de wijn moeten doen. Want JS werkt met het idee van er is een "Document" object waar het op werkt. In een object geörienteerde programmeer taal (C#, Java) begin je altijd als eerste met het opzetten van een "Applicatie object" waar je functies van aanroept en zo nodig nieuwe functies aan toevoegd. (Want tja, alleen een leeg applicatiescherm is niet zo bijzonder). Unmanaged talen zijn dan nog een stapje lager waarbij je zelf ook het geheugen moet beheren. (en lagere niveaus gaan zelfs nog verder)

In moderne browsers is JavaScript anders al jarenlang JIT-compiled naar bytecode, ipv direct uitgevoerd. Tegenwoordig zijn o.a. de Firefox en Chrome runtime environments al slim genoeg om selecte hotspots te identificeren en direct naar native code (x86, x64, etc.) te compileren.

Verder wordt er voor JavaScript als taal inderdaad een zogenaamd 'global object' gedefinieerd, wat de rol van de globale scope vervult zoals die in andere programmeertalen bestaat. In browsers valt dat globale object inderdaad toevallig samen met het venster wat de sandbox behelst waarbinnen JavaScript mag draaien. (Window is in dit geval gewoon wat je als "Applicatie object" betiteld.) Maar in andere JS implementaties kan het goed zijn dat er een andere constructie is die als het globale object dienst doet. (Bijv. in NodeJs, IronJS, etc.)

[Reactie gewijzigd door R4gnax op 23 juli 2024 06:27]

[rmpel]

Wat een bull****.

Volgens jouw redenering is een schrijver die bestaande woorden gebruikt geen schrijver.
En volgens dezelfde definitie moet een stratenmaker dus zelf zijn stenen gaan bakken?

"Daarbij heb je bij een scripttaal altijd nog een interpreter nodig."
En wat denk je dat een compiler doet? Het enige verschil is dat bij een script-taal het compilen bij run-time geschiedt.

"Als je programmeert maak je iets nieuws wat eerder nog niet bestond"
Tuurlijk, en als je het goed doet verdien je er goud geld mee. Maar de gebruikte taal heeft daar NIETS mee te maken.

Neem bijvoorbeeld PHP; Volgens jouw definitie is dit scripten (er is geen compiler nodig) en dus geen programmeren. Hoe verklaar je dan dat in PHP enorm veel projecten genaakt worden "die nog niet eerder bestonden"? Daarbij KUN je PHP ook compilen, echter, dat bind het project aan een bepaald platform, waarbij de standaard methode (interpreteren) platform onafhankelijk is.

"Als je script gebruik je functies die door iemand anders verzonnen zijn"
Ok, dus eigenlijk zeg je, alleen de jongens van Intel zijn programmeurs, want zelfs het laagste niveau programmeertalen (assembler) maakt gebruik van functies (op-codes) die door iemand anders (Intel) verzonnen zijn.