Google står bag nyt programmeringssprog

Meh.. Java = browser-baseret ? skulle der ikke stå javascript ?

#0 skrev:

På den kommende gotocon konference i Århus vil Google fremvise et nyt programmeringssprog kaldet Darth.

FYA

Jeg glæder mig. Keynoten on Go sidste år var også super.

(Lidt navngivning. GOTO eller GOTO;con er det overordnet navn. GOTO;Aarhus er for Århus)

Hvis microsoft lavede en åben standard baseret på C# og XAML som blev eksekveret på samme måde som Javascript/HTML, som ikke kræver plugin (silverlight) - ville man have det bedste sprog/syntax nogensinde...

(dog måske med CSS support i stedet for XAML Styling, som ikke er skide god)

#4

Nu må du lige væbne dig med tålmodighed. BUILD er først på Tirsdag.

(Og Silverlight 5 har et fallback til at bruge HTML5 for video)

#5 Hvilket sikkert virker glimrende hvis man har en browser som understøtter H.264

blacktiger (6) skrev:

#5 Hvilket sikkert virker glimrende hvis man har en browser som understøtter H.264

Hvilket man selvfølgeligt har!

Men det er jo rigtigt nok også en svaghed ved HTML5 video, der er ingen standard for video-format ;-)

de skulle da have kaldt den G++

Et vildt gæt: Det er endnu et { curly-brace; } baseret programmeringssprog!

#8 Så vidt jeg er orienteret så er navnet G++ allerede en compiler til C++, så mon ikke det ville forvirre mere end det ville gavne.

Montago (4) skrev:

Hvis microsoft lavede en åben standard baseret på C# og XAML som blev eksekveret på samme måde som Javascript/HTML, som ikke kræver plugin (silverlight) - ville man have det bedste sprog/syntax nogensinde...

Tjoo... men hvis den ikke kræver plugin skal alle browsere jo understøtte den native... altså, jeg er stor tilhænger af .NET og specielt C#, men selvom store dele af det er åbent er det tydeligt at det er designet til Windows i flere dele af frameworket, desværre. Og selvom frameworket er godt, er det bestemt ikke uden hverken fejl eller belastende legacy-problemer, synes jeg.

Men det du beskriver er jo bare SilverLight uden SilverLight :).

cryo (11) skrev:

Men det du beskriver er jo bare SilverLight uden SilverLight :).

I like your way of thinking sir.

#11-12

Jeg har en stærk mistanke om at browser producenterne ikke ligefrem vil juble ved tanken om at skulle implementere noget så stort som et komplet SL.

Jeg tror at ideen er DOA.

MadFarmer (1) skrev:

skulle der ikke stå javascript ?

Lars Bak har været med til at udvikle VMs til både Java og Javascript. Gilard Brachas baggrund kender jeg ikke.

At konkludere at en baggrund i Java betyder at der nok er tale om et browserbaseret sprog giver ikke ret meget mening da java bruges meget mere på servere end i browsere, og java i browseren ikke er understøttet som standard.

Et programmeringssprog til webudvikling bør faktisk skjule for udvikleren hvilket sprog der anvendes i browseren.

Javascript skulle efter sigende ikke være det mest velegnede sprog til at udvikle struktureret kode. Personligt har jeg ikke erfaringer nok med det til at selv vurdere det.

Hvis man vil lave et sprog til at udvikle webservices, så bør det som udgangspunkt køre på serveren. Men det bør samtidigt generere dele af kode som kan køre på klienten.

Det første skridt i den retning er at lave html forms som automatisk valideres på serversiden, og hvis klienten understøtter javascript valideres det også på klientsiden. På den side garanterer sproget at valideringen giver samme resultat, og javascript udgaven er kun for forbedret brugervenlighed mens serversiden er ansvarlig for sikkerhed.

Udviklerne skal også fuldstændigt afskærmes fra enhver mulighed for at håndtere forms direkte. Det skal være sprogets ansvar at konstruere forms og håndtere svarene på dem sådan at beskyttelse imod xsrf angreb ligger på et enkelt sted.

Som det næste skridt kan man begynde at anvende ajax og flytte interaktive features ud i klienten. Det kræver at udvikleren kan fortælle hvad der må flyttes ud i klienten og hvad der absolut skal blive på serveren.

Hvis sådan et sprog er godt designet kan det både køres 100% på serveren med en klient helt uden scripting support eller delvist på serveren og delvist på klienten.

Det vil altså være transparent både for udvikleren og for brugeren om der anvendes javascript eller ej. Eneste forskel er hvor hurtigt interaktive features virker. Serveren sender et lille stykke javascript med hver side. Hvis klienten forstår det kan mere javascript inkluderes og give brugeren en hurtigere oplevelse end hvis klienten ikke understøtter javascript.

Hvis man først har udviklet et sprog der kan opfylde ovenstående, så er det sikkert forholdsvis nemt at udvide compiler og runtime miljø til at kunne generere andre script sprog til klienterne således at javascript koden kan erstattes helt eller delvist med java, flash eller NaCl.

Det første sprog jeg hørte om til at udvikle webservices var <bigwig>. Der er sikkert sket meget siden dengang, men det kunne være interessant at høre hvor meget af det samme der stadigvæk fokuseres på.

#14
Man får ikke point på newz for at skrive lange kommentare, slet ikke en masse sludder !

Montago (15) skrev:

#14
Man får ikke point på newz for at skrive lange kommentare, slet ikke en masse sludder !

Så må du jo fortælle hvad for noget af det der er noget sludder, så vi allesammen kan lære noget!

Jeg kan heller ikke se nogen fejl i det kasperd skriver.

Man ku' måske fortsætte det lidt ved at sige, at hvis input-typerne i html havde lidt bedre muligheder for indbygget validering, kunne man reducere behovet for client-side scripting. Forestil jer at man f.eks. kunne lave et input-felt til tal, og angive min- og max-værdier sådan her:

<input type="text" type="float" minimum="-100" maximum="100">

Eller input af e-mail:

<input type="text" type="text" validation="regular expression">

Hvorfor ikke bare <input type="email"> ?

Man kunne også lave en lang række fast-definerede typer, men jeg tænkte det måske burde laves lidt mere generisk.

markjensen (18) skrev:

Hvorfor ikke bare <input type="email"> ?

Wow, det ville jo være en genial feature. Der findes så mange webforms med et email felt hvor deres validering er forkert og de afviser fuldstændigt gyldige email adresser. Hvor ville det være skønt hvis man blot kunne angive i koden at et felt skal indeholde en email og så få både browser og server til at validere det med et standard stykke kode, som faktisk validerer det i henhold til gældende RFC i stedet for ad-hoc metoder som altid er implementeret forkert.

kasperd (20) skrev:

Wow, det ville jo være en genial feature.

Specielt til mobiler, som f.eks. Windows Phone, der har forskellige keyboard layouts til forskellige slags input:

http://msdn.microsoft.com/en-us/library/system.win...

kasperd (20) skrev:

Wow, det ville jo være en genial feature. Der findes så mange webforms med et email felt hvor deres validering er forkert og de afviser fuldstændigt gyldige email adresser. Hvor ville det være skønt hvis man blot kunne angive i koden at et felt skal indeholde en email og så få både browser og server til at validere det med et standard stykke kode, som faktisk validerer det i henhold til gældende RFC i stedet for ad-hoc metoder som altid er implementeret forkert.

Det er vist en del af html5, så det kommer vel på et tidspunkt.

pippithehippie (10) skrev:

#8 Så vidt jeg er orienteret så er navnet G++ allerede en compiler til C++, så mon ikke det ville forvirre mere end det ville gavne.

g++ eller gpp er kommandoen for C++ compileren i GCC (GNU Compiler Collection)

markjensen (22) skrev:

Det er vist en del af html5, så det kommer vel på et tidspunkt.

:(

http://ishtml5readyyet.com/

Lyder spændene.