Dart: Dynamisk Statisk Programmering

Jeg glæder mig til at få fingerene i Dart. Det virker som om Kasper og de andre har gjort sig rigtig mange fornuftige overvejelser, også om det komplicerede økosystem som Dart introduceres i. Jeg håber ikke at det ender i en krig imellem giganter der hellere vil holde på markedsandele end at understøtte fornuftige teknologiske løsninger.
Jeg skal i hvert fald hjem og kode Dart ...

Chancen for at Dart nogensinde bliver en success er pt. Alt alt for lille, personligt tror jeg ikke meget på projektet. Det afholder mig dog ikke altid for at afprøve nye ting, hvis de tilbyder noget af fantastisk høj værdi. Men so far har jeg ikke hørt andet end at JavaScript er så slemt og med Dart bliver alting meget nemmere.
Hvis man har dygtige programmører og styr på hvad man laver, kan man sagtens bygge store applikationer i JavaScript.
Hvis du ikke kan det med JavaScript, så kan du nok heller ikke med Dart.
Hvis Dart nu tilbød noget andet og mere som jeg syntes løste nogle udfordringer for mig, så ville jeg kaste mig over det. fx havde en tættere integration med DOM'en så alt var observable. Hvis alle dets indbyggede typer var observable. Hvis den havde indbygget understøttelse for undo/redo med command patternet. Så ville min nysgerrighed være vakt.
Men at badmouthe JavaScript er misforstået, ufatteligt uambitiøst og letkøbt IMHO.

Jeg startet med Pascal i starten av firserne, gik så over til Delphi, og derfra til en blanding af PHP, Javascript og til dels pascal (freepascal).

Har aldrig haft store problemer med typechecking i JS, eftersom jeg ikke har problemer med at bestemme (og se i min kode) hvad mine typer skal være.
Måske har jeg en for meget objekt orienteret baggrund, men jeg kan slet ikke se problemet.
JS er et scriptsprog, og fungerer fint nok til det det er beregnet til.

For mig ser det ud til, at Google prøver at gøre JS om til et kompileret sprog, men dem har vi sgu nok af fra før. Mere end nok..

Har du problemer med typecheck, så er problemet efter min mening i dit programmeringsmiljø.

Jeg kan være enig i, at du kan have problemer dersom du insisterer på at benytte Notepad til JS programmering.

Enig Allan

Dart kan muligvis rette op på nogle af JavaScripts lidt mindre heldige sider, primært performance og typningen. Problemet er bare at disse problemer i det samlede webudviklingsbillede er relativt små, det er HTML og CSS der leverer inkompatibilitet, kontraintuitive funktioner, og funktionalitetshuller i hobetal. Inklusive JavaScript (eller Dart) har man 3 forskellige syntakser, hvilket ikke gør sagen bedre.

Kunne vi få HTML erstattet af noget bedre, så tror jeg måske at der er gevinst.

Jeg vil langt hellere satse mine penge på de fremtidige udgaver af JavaScript, som efter alt at dømme kommer til at stå mål med Dart.

Udviklingen inden for JavaScript/HTML5 de sidste to-tre år er noget af det bedste, der er sket for IT nogensinde, godt hjulpet på vej af en voksende bevågenhed omkring design patterns i miljøet, herunder CommonJS.

JavaScript er ikke perfekt, og det bliver Dart heller ikke.
Al den dårlige JavaScript kode der er lavet bliver ikke bedre i Dart. Folk der ikke kan skrive ordenlig kode, om det er i JavaScript eller noget andet, kan heller ikke skrive ordenlig kode i Dart.
Det ændrer ikke noget.
Folk der ikke kunne lave kvalitetsløsninger i Java/JEE, kan heller ikke i Rails eller Grails. (A fool with a tool.....).
Om det er så er mere produktivitetsfremmende at lave Dart i stedet for JavaScript, tja, det vil jeg stille mig tvivlende overfor. Jeg tager hatten af for at Google forsøger at gøre noget ved JavaScript, men jeg tror de forsøger at løse problemet et forkert sted. GWT var i hvert fald helt forkert (og Java som udgangspunkt var også temmelig underligt - meget umoderne og verbose sprog med en noget stagneret udvikling).

Man kan ALT med assembler. Your point...??

At facilitere løsningen af opgaver, med et bedre sprog end nuværende status quo, kan alt andet lige kun være et plus, i min bog.

I min optik er Dart interessant fordi:
- Det lover bedre, hurtigere, nemmere og mere robust web programmering end med javascript.
- Det er med vilje lavet meget pragmatisk, således at så mange som muligt, kan springe på så let og så hurtigt som muligt.

Om Dart vil få success må tiden vise. Det er som bekendt langtfra altid de bedste løsninger der "vinder". Men jeg har i hvert fald tænkt mig at prøve det, når jeg får tid... (suk).

Hvorfor? (ærligt spørgsmål)

En compiler til UI koden, er et tilbageskridt - der har Dart klart fat i den rigtige tilgang.
Java som input, var en løsning der handlede om hvilket sprog mange kendte til, ikke hvilket sprog der var godt til opgaven.
UI beskrives på web deklarativt i en kombination af HTML/CSS, med dynamiske elementer i JavaScript, ikke i JavaScript imperativt i Java. Se hvor lang tid Gmail er om at loade (XML er faktisk ikke så tosset til UI, ligesom det heller ikke er det til dokumenter).
Debugging ender tit i GWT genereret output, hvilket så igen tager uforholdsmæssigt lang tid at rode rundt i.
GWT er meget besværligt at kombinere med andre JavaScript frameworks (JavaScript dårligdom, som GWT ikke løser).
GWT er en tung klods til internet brug (den er bedre til Intranet-brug).
Ingen nogen ordenlig cross browser løsning på styling issues (hvilket er noget af det allervigtigste i web udvikling).

Dart tilbyder faktisk en hel del. F.eks. er der konstruktioner som type-check (det er optional med du kan få det). Der er interpolerede strenge. Der er klasser og pakker, interfaces mm.

Du kan sågar oversætte det til JavaScript, således at du kan udvikle i et moderne sprog, hvor der kan ræssoneres omkring hvad programmet gør, og så kan det afvikles i moderne browsere som findes nu.
Det er da godt. :-)
Om programmørene er dårlige eller gode har intet med sagen at gøre, derfor skal man da stadigt prøve at benytte bedre og bedre værktøjer.

Dart er blot den seneste der melder sig under fanen for optional dynamic typing. Inden for de sidste par år er dette også set i bl.a. Fantom og C#.

Og jeg er enig, det er dybt pragmatisk at man nu får mulighed for at være statisk når man kan og dynamisk når man skal. Type-systemet skal være en hjælp, ikke stå i vejen. Denne fejl lider f.eks. Java udpræget af og Scala er nærmest paranoid i dets søgen efter det ultimative type-system (upåagtet af hvor svært det så er at bruge korrekt i praksis).

Ingen tvivl om at Dart vil være JavaScript langt overlegent. Det er ikke svært at forestille sig full-stack udvikling hvor server backend (a la node.js) og klient frontend (browser) smelter sammen og tilvejebringer nye brugbare designmønstre som erstatning for model2, MVC og MVP. Bare at se hvor nemt asynkron fork-join kan foregå, får jo JavaScript og Java versionen til at ligne tortur (C# har dog lignende support for futures).

Eftersom Google kan rulle Dart ud til 33% af alle browserbrugere på en nat, er der vist heller ingen tvivl om at sproget har bootstrappingen på plads. At de fokuserer på cross-compilation synes at være et nødvendigt onde, da de er nødt til at understøtte 100% af markedet.

Udover de lokale danskere er "megastjerner" som Gilad Bracha (medforfatter til Java spec'en) og Joshua Bloch (chef arkitekt på Java libraries) ligeledes involveret. Der må foregå nogle heftige slåskampe imellem disse to, der står diametralt modsat når det kommer til type-system. :)

Dog håber jeg på god interoperabilitet med JavaScript (eller rettere JSON, som er samtlige alternativer underlegent) og en modernisering (eller rettere, simplificering) af DOM. Nå ja, og så kunne det også være interesant at erstatte Java med Dart, på Android.

Foregår måske det meste "webudvikling" ikke i UI compilere, netop for at isolere folk fra HTML (og i mindre grad CSS og javascripts) dårligdomme? ASP.NET? JSP? JSF? Etc...
Jeg troede netop at en af GWT's styrker var at glatte en masse browsernykker ud, tager jeg fejl?
Desuden siger GWT at man kan debugge direkte i java, tager jeg fejl?
Jep, Gmail og lign. tager lang tid at loade. Min fornemmelse er at det gør sig gældende for alle programmer der baserer sig på massive mængder javascript, uden at kunne sige det med sikkerhed.

Jeg tror ikke man skal regne med "interoperationalitet" med javascript. Det er to forskellige sprog, og man må vælge det ene eller andet, til non-trivielle opgaver.
Jeg tror nok at der allerede er et JSON library, det er selvfølgelig oplagt (du mente nok overlegent snarere end underlegent).
Mht. til DOM, så er min forståelse at den er W3C herre over, men Dart's DOM api, som man programmere imod når man koder til browseren, "glatter" DOM'en væsentligt ud, og gør den mere behagelig at arbejde med. Jeg mener at deres mentale model her er Jquery som udgangspunkt.
Som jeg læser det, har "mobile" fra starten været en af deres bullits mht. Dart, så mon ikke vi snart ser et Dart VM til en Android browser....

Godt fanget, jeg mente selvf. overlegent. ;)

Uden tvivl. Jeg tænkte dog mere på at lade Dart erstatte Java som platform sprog. Det er efterhånden meget svært at få øje på Google ingienører i diverse JSR ekspert grupper, hvilket lugter af at Google (ligesom Microsoft iøvrigt) har brændt nallerne rigeligt og istedet ønsker at være herre over egen skæbne. Måske deres drøm er Dart som frontend sprog og Go som system sprog.

Nej det er templating mekanismer der tilbyder en transparent metode til webopbygning, og det er ganske anderledes. Det er stadig en deklarativ tilgang til mediet. Deusden er der total transparens til JavaScript og CSS fra dette lag.

Det kan godt være det er en styrke, men det er ikke formålet. Browser-impedans kan klares meget lettere uden en klods som GWT. Men alle frameworks er selvfølgelig nødt til at tilbyde en løsning på browser-impendans. GWT er ikke bedre eller dårligere end nogen af de mange andre libraries der eksisterer.

Ja så længe GWT producerer korrekt output. Men da JavaScript har en mange gange meget udefinerbar opførsel, ender man i JavaScript debuggeren alligevel.
Det er sjældent jeg er nødt til at debugge bytekode når jeg udvikler Java ;-)

Nemlig, og det kunne jo lugte af, at det måske ikke lige var sagen når nu de fleste browsere er bygget til hurtigt at kunne håndtere UI's lavet på en måde med XHTML, CSS og JavaScript og ikke 100% bygget i JavaScript med DOM-manipulation.
GWT er interessant, da det viser hvor meget man kan opnå ad den vej. Men til udvikling af ret store UI's er det meget svært at ræssonere omkring UI, da det ikke er erklæret, men interativt programmeret.

Heri er jeg helt enig, for Scalas inferiøre type-system, som kun lader 10% (måske højt sat) af udviklere være produktive, kan ikke overvinde Java (min egen holdning naturligvis, men når jeg ser folk sidde i timer og slås med type checkeren, så er det altså meget uproduktivt).
Dart rammer sweet spot med optional dynamic typing, og en meget hurtig specialiseret VM.

Min pointe er at jeg har meget svært ved at få øje på noget der gør at Dart rent faktisk kan holde hvad Google lover. Hvis de skulle holde det skal der noget meget mere ambitiøst til en en erstatnig for JavaScript.

Jeg køber det slet ikke. JavaScript er et ret godt programmeringssprog. Jeg tester en teori for tiden og spørger folk der udtaler sig kritisk om JavaScript om hvad det er de ikke kan lide ved det. Og på et meget lille grundlag viser det sig tit at problemerne har noget med DOM'en, HTML, CSS og crossbrowser-issues at gøre, mere end det er JavaScript. Det løser Dart ikke.

Kodeordet her er lover. Så længe ingen har gjort det i praksis er det et håb. Jeg kan ikke få øje på det der skal indfri dette løfte når jeg kigger Dart spec'en igennem. (se i øvrigt citater nedenfor on hvorvidt Dart er godt)

Lidt citater fra: http://en.wikipedia.org/wiki/Dart_(programming_language)

Apple engineer Oliver Hunt, working on the WebKit project (which powers both Safari and Google's own Chrome browser) has stated:

Adding an additional web facing language (that isn't standardized) doesn't seem beneficial to the project, if anything it seems harmful (cf. VBScript in IE).

Mozilla's Brendan Eich, who developed the JavaScript language, has stated:

I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM. So 'Works best in Chrome' and even 'Works only in Chrome' are new norms promulgated intentionally by Google. We see more of this fragmentation every day. As a user of Chrome and Firefox (and Safari), I find it painful to experience, never mind the political bad taste.

Det korte af det lange: Dart er en dødssejler som erstatning for JavaScript. Men det kommer nok til at leve et liv som GWT. Så er det bare ærgeligt for de virksomheder der er hoppet med på vognen når Google stopper support for GWT og senere Dart. Man må håbe de har fået værdi nok ud af deres produkt og er klar til at investere i en omskrivning.

Jeg ved ikke om "drøm" er det rigtige ord, men ideen virker da plausibel, og de snakker da også om de to sprog i den kontekst. Synes forøvrigt også Go er et temmeligt spændende sprog, som ikke bare er "system" længere.

Lad os nu se, det er early days. Jeg er helt enig i, at noget som på sigt er Chrome-only, IE-only, eller noget-som-helst-andet-only ikke er vejen frem. Det er jo også derfor det første de producerede var en javascript compiler, ellers ville sproget aldrig komme ud. Det er helt sikkert at massen af kørende javascript i dag, er en stor mur at overvinde. Men man har set underligere. Kan du huske pre-ios-og-android dagene, med Windows Mobile? Hvor lang tid er det nu det er siden? Massive teknologi-skift sker jævnligt i IT branchen, sådan er det, og intet er umuligt. Man skal heller ikke undervudere, at de fleste nok ville mene at Dart er teknologisk og brugsmæssigt bedre end javascript, og at mange dagligt bander javascript til helvede. We'll see....

fra hans Goto talk: http://gotocon.com/dl/goto-cph-2012/slides/Keynote_Dart.pdf

Det er s*u også sjældent når man bruger GWT. Faktisk er det ikke sket for mig endnu. Jeg ved ikke hvad du har haft rodet dig ud i, men GWT er efterhånden rimelig modent. Jeg vil sige at i vores projekter virker det bare.

Det er lidt overraskende med alt det GWT hate man læser her. Koder i alle i GWT dagligt og hader det, eller snakker i om noget i har prøvet engang for flere år siden?

Jeg skriver i øjeblikket GWT til daglig, og min holdning er splittet.

På den ene side, er paradigmet fantastisk; at man i sit favorit Java IDE kan udforske API'er og genkende patterns fra andre UI toolkits (editors, renderers, formatters etc.) hvor man rent faktisk kan skrive komponenter og genbruge disse igen senere! Udviklingsmodellen minder meget om Wicket, med den forskel at state holdes på klienten, hvor den efter min overbevisning også hører til. GWT er uden tvivl langt bedre end JSF og lignende overkomplicerede templating teknologier, ingen tvivl om det.

På den anden side, så er omkostningen ved GWT bl.a. at man bliver enddog meget afhængig af sine værktøj, så hver gang Firefox f.eks. opdaterer automatisk (sker en gang om måneden i disse dage), skal man ud og lede efter (eller bygge) en kompatibel Development plugin. Kompilering kan også ende med at tage oceaner af tid. Det største problem er dog nok, at det er enormt svært at integrere et CSS design (man f.eks. har fået stillet tilrådighed af en designer) med GWT/Java komponenter. Og man skal helt sikkert holde sig til standard GWT, og ikke rode sig ud i SmartGWT og GXT der har alt for meget overhead med sig og andre ulemper.

Så GWT er smart, og programmer er nemme at vedligeholde, men det virker nok bedst for større dynamiske data-drevne sider med rigt UI.

http://eloquentjavascript.net/chapter6.html

Hvis ikke - nothing to see here.

Jeg er ikke nogen fan af UI-delen af GWT så det bruger vi ikke i vores projekt. I stedet er vores brugergrænseflade opbygget i ren HTML og CSS - det er sådan vores designere kan lide det (og det eneste de kan finde ud af...). Vi tilføjer så funktionalitet til HTML'en således:

val widget = new HTMLPanel(html)  
RootPanel.get.clear  
RootPanel.get.add(widget)  
val journal = new TextBox  
journal.addChangeHandler{Window.alert("New journal: "+journal.getText)}  
widget.add(journal, "journal_textbox")

Hvor vores HTML-designer har markeret et html element med id="journal_textbox" der hvor han gerne vil have en sådan textbox.

Det genialle er netop at man kan holde state på klient samtidig med at man kan programmere server og klient i samme sprog og som en helhed. Vi har udviklet et JSON API til server-klient kommunikation. Samme API kan også bruges af vores kunder til server-server kommunikation. Det er to fluer med et smæk.

Selve UI design-API'et er der så mange forskellige meninger og religioner om at vi aldrig får det eneste rigtige. Det vil være meget naivt at tro at Dart kan ændre på det faktum. Der findes flere forskellige bud inden for GWT på alternative UI API'er. Jeg er som sagt til KISS og det virker godt for os.

Uha, det lyder ikke så godt, og overrasker mig. Hvordan hænger det lige sammen? Browserversioner i koden...??

Hmm, det lyder heller ikke så godt. Havde indtryk af at det kunne lade sig gøre, og var meningen at man nemt kan gøre det. Er det forskellen på virkeligheden og papiret?

Jeps, det var også mit indtryk, og det er helt fint. Nogen af os sidder jo og kæmper med sådan nogen systemer dagligt :-)

Er det sådan noget her du mener: http://expertstalk.org/post/11600649189/foreach-method-in-dart ?

Close but no cigar ;)

Det er sådan noget som dette:

forEach(replacements, function(replace) {  
    text = text.replace(replace[0], replace[1]);  
  });  
  return text;  
}

og dette:

function negate(func) {  
  return function() {  
    return !func.apply(null, arguments);  
  };  
}

Versionsstyring er jo tricky. Plugins skrives konservativt til og med én browser version. Hvis så pluginen er henvendt 11, men browseren nu er 12, ja så bliver pluginen slået fra. Dette gælder både Firefox og Chrome, de eneste browsere jeg bruger.

Hmm, det lyder heller ikke så godt. Havde indtryk af at det kunne lade sig gøre, og var meningen at man nemt kan gøre det. Er det forskellen på virkeligheden og papiret?

Ja det er nok meget godt formuleret. Faktisk er jeg ikke sikker på der er nogen som helst imperativt UI bibliotek, der løser dette problem. Styling via CSS sker jo via DOM selectors, som man jo netop abstraherer fra (jeg plejer at tænke på det som bottom-up der skal snakke med top-down).

Det skal dog retfærdigvis siges at UIBinder (GWT markup direkte i HTML, lidt ligesom Wicket), som er noget af det nyere, forsøger at råde bod på det.

Det er kun udvikleren selv der har problemet. Det er en browser plugin der bruges når man vil debugge. Personligt bruger jeg den slet ikke.

Slutproduktet virker i alle browsere.

Det tager 3-4 minutter at compile et af vores projekter, kun til én permutation (typisk Firefox). Så hvis vi ikke brugte development mode, ville vi ikke lave andet end at vente på compileren. Det må være nogle meget små projekter du har gang i så.

slettet - dobbelt indlæg.

En hurtig computer kan oversætte mit projekt på ca. 1 minut. Ja det er irriterende. Jeg kompenserer ved at lave mere før jeg går i gang med at teste :-).

Man kunne ønske at de arbejdede lidt på oversætter-hastighed herunder iterativ oversættelse. Det er jo ingen naturlov der siger at det skal tage 50 gange længere at lave javascript end det tager at lave bytecode.

Det er nok eksistensen af dev mode der gør at ingen har brugt tiden på at optimere oversætteren.