Javaskript/ECMAScript ur datavetenskapligt perspektiv

Hej

Jag har funderingar runt JS/ES och dess låga status på universitet och högskolor.

Förutom David Flanagans bok och artiklar av Douglas Crockford, så är det svårt att hitta något som behandlar ämnet ur datavetenskapligt perspektiv.

Förslag på artiklar mottages tacksamt. (Jag bifogar en uppsats jag har skrivit som har ett måttligt akademiskt anspråk.)

Specifik fråga 1: Vilka ord skulle du använda för att beskriva språket?

"ECMAScript is an imperative, loosely typed, interpreted scripting language, with first class objects."

"ECMAScript is parsed, tokenized (sometimes called “compiled”) and run by a script engine, within a context (a browser for JS, Flash for AS, etc)"

Specifik fråga 2: ECMAScript saknar STDIN och STDOUT. Vad är det vackra ordet för sådana språk?

Lars Gunther

Jag kommer även med lite synpunkter på uppsatsen.

Felstavningar:
*saknas ett t i javaskript:
Med denna nya praxis används javaskrip endast för att förhöja användbarheten på en sida, och aldrig så att en sida får försämrad användbarhet.
*Det heter föredra:
Inkonsekvens samt felstavning:
About Javascript: http://developer.mozilla.org/en/docs/About_JavaScript
JavaSvript Language Resources (länkar bl.a. till ECMA-standarderna) http://developer.mozilla.org/en/docs/JavaScript_Language_Resources

Du är inkonsekvent i hur du anger syntax:
innerHTML, XmlHttpRequest och Window-objektet
bör vara: innerHTML, XMLHttpRequest och window

Du är även inkonsekvent i namngivningen av Javaskript. I de flesta fallen stavar du javaskript. Ibland JavaScript. "Begreppet DOM-skriptning rymmer dock mer än bara en övergång till DOM-metoder. Det är en filosofi som ser sig själv såsom varandes motsats till DHTML-erans dåliga JavaScript."
Jag tycker du ska köra helt på det senare då man sällan byter namn på språken man programmerar i. Python heter inte pyton på svenska C sharp heter inte Ciss eller C vass. (Du översätter heller inte "Flash" till blixt eller skirver det med gemener)

1: Jag skulle nog välja Crockfords beskrivning: The World's Most Misunderstood Programming Language

2: Standard streams har jag hört användas.

1. Jag skulle nog göra en kompromiss mellan båda dina förslag: Det är ett i huvudsak dynamiskt typat objektorienterat språk som vanligen körs interpreterat. Sen är det värt att minnas att:

• Det har stöd för statisk typning, t.ex. var x:Integer = 3;
• Objektorienteringen ser inte riktigt ut som i de förhärskande objektorienterade språken (som C# och Java) vilket innebär att vissa menar att det inte är objektorienterat "på riktigt", men det beror mest på ens definition av "objektorienterat". Det stödjer dock objekt, en form av arv, dynamisk bindning, etc, allt som ska finnas i ett objektorienterat språk.
• Det behöver inte nödvändigtvis vara interpreterat - det är mest en fråga om själva implementationen av motorn. Det finns inget som hindrar att man kompilerar Javascript.

2. Standardströmmarna tas inte upp av specifikationen, men det behöver inte betyda att de inte stöds - återigen, det är en fråga som lämnats över till den specifika implementationen.

Sen får du arbeta lite med vetenskapligheten (språk, källkritik etc), men det överlåter jag glatt åt din handledare :)

Slutligen vet jag inte riktigt om jag håller med om att Javascript har "låg status" på universiteten och att det är orsaken till att det inte finns några högre kurser i frontendutveckling (förresten, gör det inte? källa? ;) ), problemet har nog andra orsaker. Jag känner lite folk som forskar om programmeringsspråk och de har väl i allmänhet tämligen höga tankar om Javascript som språk, däremot bryr de sig föga om GUI-programmering. Användbarhetsfolket, däremot, har en tendens att försöka frikoppla användbarhet och design från specifika plattformar, särskilt plattformar som ändras så snabbt som webbläsare. Problemet som jag ser det är alltså att de som intresserar sig för hur man ska framställa bra kod sällan är desamma som intresserar sig för hur man ska framställa bra användargränssnitt - vilket är synd, imo, eftersom en bra programmerare är nödvändig (om än inte tillräcklig) för att man ska få fram ett bra program. Men det kanske bådar gott för dig om du vill doktorera på't?

spango skrev:

1. Jag skulle nog göra en kompromiss mellan båda dina förslag: Det är ett i huvudsak dynamiskt typat objektorienterat språk som vanligen körs interpreterat. Sen är det värt att minnas att:

• Det har stöd för statisk typning, t.ex. var x:Integer = 3;

Inte i ES 3. Det kommer i ES 4, dock ej med typen integer...

spango skrev:

• Objektorienteringen ser inte riktigt ut som i de förhärskande objektorienterade språken (som C# och Java) vilket innebär att vissa menar att det inte är objektorienterat "på riktigt", men det beror mest på ens definition av "objektorienterat". Det stödjer dock objekt, en form av arv, dynamisk bindning, etc, allt som ska finnas i ett objektorienterat språk.

Första klass funktioner med andra ord. Som Smalltalk och förebilden Scheme.

(ES 4 kommer, som du troligen vet, ha klasser och interface.)

Uppfinnaren av hela OO-tänkandet (nu glömmer jag hans namn) hade inte andra klassens objekt (klassbaserat arv) i åtanke när han skapade paradigmet... Hans favoritspråk är just Smalltalk.

JS funkar att programmera både strukturerat (procedurellt) och OO. Språket - som jag ser det - är inte OO. Men man kan använda det för OO-programmering.

Till och med ALex "Dojo" Russel har fått det om bakfoten, då ett av hans paradnummer är att säga "allt är objekt"... Som om det inte fanns strängar, siffror eller booleska värden. Detta arv från Java erkänner dock Brendan E som ett misstag. Hade han gjort om språket idag hade det inte varit någon skillnad alls mellan strängar och strängobjekt.

spango skrev:

• Det behöver inte nödvändigtvis vara interpreterat - det är mest en fråga om själva implementationen av motorn. Det finns inget som hindrar att man kompilerar Javascript.

Jo, förvisso. Det används ju internt i FFox och andra Mozilla produkter... Skall fundera på en bättre formulering.

spango skrev:

2. Standardströmmarna tas inte upp av specifikationen, men det behöver inte betyda att de inte stöds - återigen, det är en fråga som lämnats över till den specifika implementationen.

Källa? Jag bygger mitt påstående på ett svar från Lars Hansen på ES 4 mailinglistan (redaktören för specen). Jag dristade mig föreslå att ES 4 skulle ha sprintf och skrev i hastigheten printf. Som svar fick jag att det inte skulle funka just eftersom STDOUT inte finns i standarden.

Man kan emulera standardströmmarna - som i JS-skalet eller konsollen i Firebug, men inte ens de stödjer en så enkel sak som read (?). Känner du till någon implementation som har äkta standardströmmar? (Jag har inte kollat server-side JS.)

spango skrev:

Sen får du arbeta lite med vetenskapligheten (språk, källkritik etc), men det överlåter jag glatt åt din handledare :)

Uppsatsen i fråga var på A-nivå, så den blev med beröm godkänd (av min handledare som inte har koll alls på ämnet). Källkritiken anser jag dock vara utmärkt. Jag har hittat originalkällan på nästan allt jag skriver.

Jag tackar verkligen för all konstruktiv kritik - men en fråga återstår att besvara: Vad mer finns det som är skrivet med vetenskapliga anspråk i ämnet? Jag skulle kunna vidga frågan: Vad finns det om front-end webbtekniker?

Om statusen: Jag har letat igenom nästan alla högskolors kursutbud. Jag har inte hittat en enda kurs på B- eller C-nivå som gäller front end. Vet någon om det finns sådana kurser på någon högskola så hör av er till mig!

itpastorn skrev:

Språket - som jag ser det - är inte OO.

Well, that depends on what you definition of "is" is... ;) Jag håller inte med, men känner du att du kan motivera din ståndpunkt så kör på det. Spelar iofs marginell roll för ditt ämne så jag ska inte tjata om det.

itpastorn skrev:

Jo, förvisso. Det används ju internt i FFox och andra Mozilla produkter... Skall fundera på en bättre formulering.

Jag tycker det räcker med att säga att det är "vanligen interpreterat". Återigen, det spelar inte speciellt stor roll för ditt ämne, så nöj dig med en enkel förklaring som täcker det mesta.

itpastorn skrev:

Man kan emulera standardströmmarna - som i JS-skalet eller konsollen i Firebug, men inte ens de stödjer en så enkel sak som read (?). Känner du till någon implementation som har äkta standardströmmar? (Jag har inte kollat server-side JS.)

Tja, äkta och äkta, man kan hantera standardströmmarna från Javascript i både JScript.Net (som väl iofs inte är 100% ES) och Rhino som följer med Sun JRE >6, och rimligen alla andra implementationer som inte är tänkta att köras i en webbläsare.

itpastorn skrev:

Om statusen: Jag har letat igenom nästan alla högskolors kursutbud. Jag har inte hittat en enda kurs på B- eller C-nivå som gäller front end. Vet någon om det finns sådana kurser på någon högskola så hör av er till mig!

Vet inte om den här räknas som A-kurs eller inte, men den brukar iaf läsas av rätt många på B- eller C-nivå: http://people.dsv.su.se/~pierre/i/i.cgi?href=public/ip_summary/ip3.txt&session=
Men du, hur många programmeringskurser över A-nivå finns det alls som tar upp gränssnittprogrammering för en specifik miljö?

itpastorn skrev:

Jag tackar verkligen för all konstruktiv kritik - men en fråga återstår att besvara: Vad mer finns det som är skrivet med vetenskapliga anspråk i ämnet? Jag skulle kunna vidga frågan: Vad finns det om front-end webbtekniker?

Det verkar vara skralt med det, så det kanske är upp till dig att börja utreda området. Go for it! (y)

Jag är smått kritisk till de termer du föreslår.
Jag tycker din vana att kalla språket för Javaskript är en fördummande försvenskning, som för tankarna ännu mer till Java än vad Javascript i sig gör. Eftersom skript är ett svenskt ord så kan mindre vetande uppfatta det som att det är ett skriptspråk med koppling till Java. Jämför med C# och .net som inte blir uttalas "C-skarp"/"Ciss" (som noten) eller ".nät" på svenska. Dessutom bör Javascript stavas med stort J.
Jag stör mig smått på termen diskreta javaskript då termen diskret bland dataloger har en annan betydelse än i vanlig svenska. Visserligen är väl risken liten för missuppfattningar, men jag stör mig ändå på termen.
Samma sak med att översätta graceful degradation till feltolerans. Graceful degradation bör inte översättas till feltolerans, även om feltolerans är en viktig komponent för att få "graceful degradation" att funka. (Jämförelse: Du skulle inte översätta "truck" på engelska till väg bara för att du behöver en väg att köra din lastbil på)
Rekommenderad term enligt mig: Snäll nedgradering.

Faktamässigt ser artikeln överlag bra ut, dessa språkliga påpekandena är bara mindre detaljer. Jag tyckte ändå att det var värt att kommentera dem eftersom du har skickat ett förslag till datatermsgruppen. Risken med att översätta termer på ett sätt som bara nästan är rätt är att en svensk term passar som översättning av en engelsk i vissa fall, men ter sig fånig i andra fall.

@nitro2k01: Jag svarar i en ny tråd, specifikt för terminologin.

Fler tips och reflektioner i denna tråd välkomnas.