Hvilket sprog skal man lære?

På Informationsvidenskab og Digital Design får vi en masse studerende, som er dygtige, men ikke specielt interesserede i matematik og lignende fag. De drømmer om job som designere, projektledere, ux'ere og andet et godt stykke fra udviklerstolen på projekter.

For at få en it-uddannelse, er man desværre stadig nødt til at lære at programmere. Mit institut traf for 4 år siden en beslutning, om at undervise i Actionscript, som er programmeringssproget i Flash. Det er en platform, som det kostede en masse penge at købe licenser til, men fordelen var, at platformen kunne bruges i en række af fag (vi har siden skiftet til gratis studielicenser til Flash Builder, frem for de dyre Creative Suite-pakker).

Vores studerende lærer Actionscript i deres programmeringsfag, og kan efterfølgende bruge Actionscript og evnerne til programmering, i de mere produktorienterede fag som Interaktionsdesign og Design, og til at bygge prototyper i f.eks. bachelorprojekter.

Alternativerne til Actionscript, er Java og Python, som begge har været prøvede, og andre vil måske foreslå Ruby on Rails eller noget fjerde.

Min vurdering er, at der er fordele og ulemper ved at undervise i hvert af disse sprog. Java har et hav af lærebøger, det har Actionscript virkelig ikke, og Java er det som mange vil møde i erhvervslivet. Java er til gengæld ikke særlig velegnet til at lave GUI og prototyper - ift. Flash/Actionscript - og det er de primære opgaver på uddannelsen.

Efter 3 år med undervisning i Actionscript, har jeg lært at leve med beslutningen, og jeg er vant til at forsvare den. For i de studerendes bevidsthed, er Flash død. Kun fra et undervisningsperspektiv, giver det mening at bruge Flash/Actionscript. For skifter man sprog for tit, ryger der meget med ud med badevandet. Og mange kurser berøres. Desuden får man en mængde studerende, der ikke kan tage de samme kurser med de samme forudsætninger, da de har lært noget forskelligt.

Mit svar til det, er at det er svært at sikre, at det man lærer på 1. semester også er det erhvervslivet efterspørger, når man kommer ud 5 år senere. Så det bør ikke være det primære fokus, at undervise i det der er "hot" lige nu. Selv om det sikkert virker mere motiverende, end noget der ikke er "hot" (læs: død).

Og så er der jo også selve udviklingsmiljøet. Vi bruger Flash Builder, som er Adobes version af Eclipse. Det er lidt buggy, men det virker det meste af tiden. Her bør man igen tænke på, hvilket miljø man skal undervise i sproget i. Er det et miljø for begyndere?

I de nye versioner af Flash og Flash Builder, er det muligt at porte sine programmer til iOS, Android og Blackberry. Man kan faktisk lave apps til iPhone og Android med Actionscript. Det er helt sikkert med til at redde Actionscript i nogle år, da Objective-C er langt sværere at gå igang med (min vurdering), hvis man kan lidt Actionscript allerede. At det ikke kan blive nær så Apple-lignende produkter, som hvis man udvikler i XCode, siger sig selv.

Mit spørgsmål er: Hvor vigtigt er det, at universiteterne "følger med" programmeringssprogene, og hvad der efterspørges i erhvervslivet?

Tankegangen i programmeringen, er jo i reglen sværere end syntaksen. Har man lært at "tænke algoritmisk", dvs. nedbryde problemstillinger i mindre dele, som kan generaliseres, har man efter min mening mestret det sværeste ved programmering.

Skal universiteterne skifte sprog efter behov, selv om det vil betyde, at omskole underviserne (også de der indirekte berøres, ved at f.eks. studerende på deres designfag ikke længere kan det sprog som der bruges) og lave en række kurser om, hver gang man skifter sprog.

Hvor meget betyder det for forståelsen af programmering, hvilket sprog man programmerer i?

Michael Niebuhrs billede

Kommentarer (65)

Robert Larsen

...er døde sprog. Der kommer ikke understøttelse på de mobile enheder og du kan stort set det samme i HTML5/JavaScript. Se bare de browserspil, som er lavet i denne kombi.

Så jeg ville helt sikkert arbejde med JavaScript. Det kan også bruges på serversiden (via Node.js), selvom det nok ikke er så typisk i erhvervslivet endnu.

PHP og ASP er ret populært på serversiden...Ruby er også godt på vej op.

Men som udvikler skal du under alle omstændigheder sætte dig ind i flere sprog, alene for at få inspiration. Når man skal lave en konkret løsning, bør man vælge det værktøj (sprog), som passer bedst til opgaven, men man får bedre forståelse for ét sprog, ved at lære et par andre også.

Jeg køber ikke helt tesen om at man kan lære algoritmer og datastrukturer i alle sprog. Selvfølgelig kan man det, men hvorfor så ikke lære dem i et sprog, man faktisk kan bruge efterfølgende? Hvorfor spilde tid på at lære et sprog, som ingen længere bruger?

Leonard Kramer

Jeg kan (måske) godt se hvorfor man ville undervise i Actionscript for 5 år siden, men i dag vil jeg mene at det ville være langt mere relevant at lære HTML5+javascript.

Umiddelbart gør det måske ikke den store forskel, men for mig at se må det være mere motiverende for en studerende at lære et sprog med fremtid i.

Noget andet er at jeg syntes som udgangs punkt ikke at man bør undervise i teknologier som kræver at en student skal ud og købe licens for at kunne bruge. Det er muligvis ikke relevant nu (efter I skiftede til studielicenser), men selv om studielicenser også gælder for deres hjemme computere, så gælder den jo i hvert fald ikke efter de er færdige med deres studier og måske har lyst til at holde deres færdigheder ved lige.

Michael Niebuhr

Jeg køber ikke helt tesen om at man kan lære algoritmer og datastrukturer i alle sprog. Selvfølgelig kan man det, men hvorfor så ikke lære dem i et sprog, man faktisk kan bruge efterfølgende? Hvorfor spilde tid på at lære et sprog, som ingen længere bruger?

Du har fat i kernen, her. Det må føles meget demotiverende, at sidde med et sprog der er dødt i manges opfattelse. Der er jo heller ikke rigtig søgning til opslåede Cobol-jobs, er der?

Men du skal tænke på, at disse studerende ikke vil være udviklere. De søger en mere humanistisk rolle på et projekt, som der jo også findes mange af. Nok især når man kigger fremad, hvor flere og flere udviklerjobs vil blive outsourcet på større projekter.

Problemet med sådan noget som Javascript, er i mine øjne udviklingsmiljøerne og autocompletion (WebStorm er noget af det bedre). At du med det samme henviser til node.js og sikkert JQuery i næste kommentar, siger noget om hvordan det hurtigt griber om sig, ift. hvor meget man skal kende til. Modargumentet er selvfølgelig, hvor meget mere man kan!

Der er Actionscript en forholdsvis lukket verden, og derfor også lettere at undervise i. Jeg vil slet ikke argumentere for at det er fremtiden, men stiller spørgsmålet hvor vigtigt det er hvilket sprog man lærer - som designstuderende eller på en anden humanistisk it-uddannelse.

Jonas Nyrup

Hvad er forståelsen af programmering?

  1. At have et godt nok kendskab til et programmeringssprog til let at kunne skrive et program?
    På datalogi i Odense skiftede vi sidste år java ud med python i det første programmeringskursus, bl.a. for at de studerende fik en blødere indgang til programmering da der også er en del af studieretninger der følger dette kursus.

  2. At kende konsekvenserne (hukommelsesforbrug, køretid) af hvordan man skriver sit program?
    I så fald er det yderst lærerigt at vælge et lavniveausprog, da man får en grundigere forståelse for hvad højniveausprogene abstrahere væk.

  3. kunne læse en anden persons program og nogenlunde overskue programmets funktionalitet? Svarende til tysk på C-niveau i gymnasiet, hvor man blot skal forstå meningen i en tekst.

Der findes et hav af programmeringssprog og ingen af dem er perfekte/universielle.
Så find ud af hvad i skal bruge programmeringen til og vælg sprog ud fra det.

Poul-Henning Kamp

Jeg vil personligt anbefale at man lærer et eller andet generelt "værktøjsvenligt" sprog, så man har et generelt sprog med i bagagen til at tygge på data med.

Pt. er mit bedste skud nok Python, men det er sådan set ikke vigtigt hvilket sprog, bare det er noget man altid har eller altid kan få adgang til.

(ie: ikke Haskell, Erlang eller INTERCAL :-)

Jarle Knudsen

Jeg vil personligt anbefale at man lærer et eller andet generelt "værktøjsvenligt" sprog, så man har et generelt sprog med i bagagen til at tygge på data med.


Helt enig. Man kan altid lave spaghettikode i alle sprog ;O)

På en måde lyder det som:

Jeg vil gerne lære mig at køre bil. Hvilken mærke skal jeg vælge Toyota, Mazda eller Porsche?...

Hvad med at sætte sig ind i trafikregler først?


(på mine studier startede vi med Borland Turbo Pascal, os så udvidet til Simula på Solaris og C++. Årgang senere blev C++ udskiftet med Java)

Jesper Louis Andersen

Du vil godt have et sprog der har en stor output-faktor. Det vil sige et sprog hvor det er nemt at skrive programmer og hvor du hurtigt kan se output. Hvis de studerende allerede ved noget om HTML, så er Javascript oplagt. Det visuelle kommer ret hurtigt og du kan hurtigt komme til at lave sjove ting med output. Python er også et godt valg fordi det giver dig et forbandet godt værktøj til at lave limprogrammering og bygge ting op omkring.

Hvis fokus er datastrukturer og algoritmer er Python nok et bedre valg, for så går det hele ikke op i hurtige hacks for at få en hjemmeside til at se ordentlig ud. Hvis fokus derimod er design, så kan Javascript nok hjælpe med til at holde interessen fordi man som studerende kan se hvorledes Javascript kan benyttes til at forbedre UX på en hjemmeside.

Hvis du derimod godt vil lære at programmere, for programmeringens skyld, så skal du have fat i et andet sprog. Faktisk skal du nok have fat i et par stykker: C, Haskell, Prolog, Erlang eller lignende. Det ville give dig en god ballast for det maskinnære, det rent-beregnelige, det deklarative og det distributive.

Peter Lind

Klart javascript/html5 og/eller python. Det er fantastisk nemme sprog at komme i gang med og kan bruges mange steder. Derudover er det nemt at lære at programmere med dem.

Java kan også overvejes, men det vil nok være bedre at vælge en nyere udgave, a la Scala eller lign. Overordnet vil det dog næppe virke positivt for studerende, der ikke er interesserede i at programmere.

Peter Lind

Hvis du derimod godt vil lære at programmere, for programmeringens skyld, så skal du have fat i et andet sprog.

Det kan du så afgjort også lære med javascript, hvis du faktisk er interesseret i det.

Jørgen Elgaard Larsen

Valget af sprog må jo også komme lidt an på, hvilke ambitioner man har for de studerende.

Hvis programmering anses som noget, de studerende helst vil undgå, så er det nok ikke relevant at uddanne dem til at blive superprogrammører og have styr på alle former for algoritmer, datastrukturer, kompleksitet og andet. I det tilfælde skal man naturligvis vælge noget relativt simpelt.

Jeg mener godt, at man kan skele til, hvad de studerende kommer til at arbejde med, når de er færdige. På de mere generelle, hardcore uddannelser (f.x. datalogi) betyder det ikke helt så meget, fordi sproget ikke er det vigtige. Man kan altid lære nye sprog. Men på uddannelser, hvor der kun undervises specifikt i et enkelt sprog, kan det være sværere for de færdiguddannede at generalisere til at bruge et andet sprog.

Man kan jo godt gætte på, hvilke sprog, der vil være efterspørgsel efter i fremtiden. Og det ser ikke lovende ud for ActionScript.

Hvor meget betyder det for forståelsen af programmering, hvilket sprog man programmerer i?

Det betyder nok ikke så meget, om det lige er Perl, PHP eller Python. Men det betyder en del, om man lærer at skrive programmer, eller bare at bruge et træk-og-slip-værktøj.

Det har også betydning, hvilket domæne, sproget er udviklet til. En grafiker ville nok kunne lære at programmere i COBOL, men vil have svært ved at relatere det til grafik.

I forhold til Informationsvidenskab og Digital Design ville jeg helt klart vælge et sprog, som giver en større forståelse for de medier, som de studerende skal arbejde med fremover.

Design/grafik-branchen har længe lidt under, at meget få designere forstår idéen bag HTML. Langt de fleste (også nyuddannede) laver et design, der ser virkelligt flot ud på tryk og på deres egen skærm - simpelthen fordi de ikke er opdraget til at tage hensyn til varierende skærmstørrelser. Det er blevet lidt bedre nu, hvor der er mobile enheder at tage hensyn til, men der er lang vej igen.

Hvis designerne blev uddannet til at formgive hjemmesider i håndskrevet CSS og JavaScript frem for PhotoShop, ville de beherske deres medie langt bedre.

Også derfor er ActionScript et elendigt valg - det forstærker blot idéen om faste skærmstørrelser.

Jon Bendtsen

På en måde lyder det som:

Jeg vil gerne lære mig at køre bil. Hvilken mærke skal jeg vælge Toyota, Mazda eller Porsche?...

Hvad med at sætte sig ind i trafikregler først?


Helt enig. Undervisningen skal da være tidsløs, for den skal jo helst holde så lang tid som overhovedet muligt. Industrien er flygtig, skifter til nye sprog og paradigmer regelmæssigt, og desuden så bruger forskellige virksomheder forskellige sprog og løsninger. Vi skal uddanne generalister, det er først så sent som muligt at folk skal specialisere sig.

Torben Mogensen

Tankegangen i programmeringen, er jo i reglen sværere end syntaksen. Har man lært at "tænke algoritmisk", dvs. nedbryde problemstillinger i mindre dele, som kan generaliseres, har man efter min mening mestret det sværeste ved programmering.

Det er nok den vigtigste pointe i indlægget. Mange programmeringskurser vælger sprog efter et anvendelsesområde -- som for eksempel webprogrammering, numeriske beregninger eller noget tredje. Og så forsvinder programmeringsprocessen (computational thinking) i en tyk sovs af biblioteksfunktioner, GUI-builders, IDE'er og meget mere, som godt nok er ting, man skal bruge til at løse "rigtige" opgaver, men som blot er distraktioner, når man skal lære at programmere.

Så i princippet er det ligegyldigt hvilket sprog, man bruger til at undervise programmering i, når blot det ikke indeholder alt for mange distraktioner såsom:

  • Man kan ikke programmere det uden en IDE.
  • Man skal skrive en masse uforståelige magiske ord for blot at lave et program, der lægger to tal sammen.
  • En uigennemskuelig beregningsmodel.
  • Uforståelige fejlmeddelelser.
  • Mange uforudsigelige special cases.
  • Kan kun køre eller udvikles på en specifik platform.
  • Så store programbiblioteker, at eleverne bruger alt for meget tid på at lede efter funktioner, der kan løse problemet, i stedet for selv at løse det.

Så det ideelle til at lære at programmere er egentlig et meget skrabet sprog med et meget skrabet bibliotek. Når man så har lært det, kan man skifte til et anvendelsesorienteret sprog med masser af værktøjer og kæmpestore biblioteker.

Jon F. Hansen

Nu har jeg selv været så heldig at have dig som forelæser det første år på Informationsvidenskab (jeg er i gang med 3. semester). Jeg kom over på studiet efter at have læst datalogi ét år, hvor jeg endte med at blive træt af al matematikken. På datalogi var det Java, vi arbejdede med, og jeg synes, indlæringskurven var en hel del stejlere end med ActionScript. Det skyldtes nok også, at der gik lang tid, inden jeg på datalogi så et resultat af alt mit hårde arbejde; altså et gui. Det er meget muligt, jeg er visuelt handicappet, men jeg mener, man har nemmere ved at forstå idéen med objektorienteret programmering, når man kan se, at én funktion kan bruges til at lave mange bolde i forskellige farver, størrelser etc., der hopper rundt på skærmen.

Jeg synes, ActionScript har været en fin - for mig 2. gang - indgang til objektorienteret programmering, da man hurtigt har kunnet se resultater. Og igen, uddannelsen er ikke lavet til at spytte programmører ud.

Naturligvis har det været en anelse demotiverende at skulle lære ActionScript, når det er på kraftigt tilbagetog, og derfor ville der helt sikkert være noget at vinde ved eksempelvis at undervise i HTML og JavaScript. At undervise i denne kombination af sprog ville passe fint med vores øvelsestimer, da resultatet af vores ActionScript skulle sættes op på en "hjemmeside", vi selv skulle kode, og der var mange af mine medstuderende, der synes, HTML og CSS var rigtig spændende. Så det kunne være rigtig interessant at koble det visuelle HTML/CSS sammen med det objektorienterede JavaScript.

Pelle Söderling

Hej Michael

Men du skal tænke på, at disse studerende ikke vil være udviklere.

Med dette formoder jeg at der menes at de ikke vil være backend/system-udviklere?

Frontendudvikling idag kræver en hvis grundlæggende forståelse for programmering uanset om du vil lave UI's til Web eller Desktop - men ikke nødvendigvis dyb forståelse eller low-level forståelse, men derimod bred high-level forståelse.

Hvis man kun lærer dem ActionScript eller Javascript, vil de næppe være meget bevendte som frontend-udviklere til Desktop-applikationer skrevet i Java/C#/C++ etc og omvendt. Medmindre det er på så overordnet et niveau at det snarere er photoshop end en editor de har brug for.

Jeg har forståelse for at man gerne vil fokusere tiden på UI design og ikke ønsker at gå for meget i dybden med programmeringen, men det betyder nok desværre også at der vil være færrer stillinger de kan gå direkte ud og besætte når de er færdige med studiet, medmindre virksomheden har mod på at oplære dem.

Som minimum mener jeg man bør lære dem både en Web teknologi og en Desktop teknologi - I forhold til UI implementering og design er dette 2 meget forskellige paradigmer.

Den grundlæggende webstack de bør lære i forhold til UI design er HTML/CSS/Javascript (tiden er ved at være moden til at inkludere HTML5 teknologier her også, såsom brugen af Canvas) - tilgengæld kan du glemme alt om serverside teknologier såsom node.js, PHP osv. dette er ikke relevant for UI udvikling og må betragtes som hørende udenfor studiets fokus. Tilgengæld bør studiet overveje at inkludere jQuery som efterhånden er så adopted at det kan betragtes som en industristandard, det letter også UI udvikling i Javascript betragteligt og fjerner fokus fra alle cross-browser issues.

I forhold til Desktop-udvikling har jeg reelt svært ved at pege på andet end C# og Visual Studio (som findes i en ganske udmærket gratis udgave der egner sig fint til formålet: http://www.microsoft.com/visualstudio/eng/products/visual-studio-express... ).
Det er der flere grunde til - Visual Studio er en begyndervenlig IDE, med rigtig god intellisense support.
GUI editoren heri er formentlig den bedste på markedet (og lysår bedre end hvad du finder indenfor Java verdenen).
Og et faktum er også at det meste desktop udvikling indenfor erhvervslivet stadig er målrettet Windows platformen.
Det er også et bedre sprog end Javascript til at undervise basal OOP i, såfremt man finder dette vigtigt for studiet.
Desuden vil det betyde at de også allerede kender til Visual Studio som IDE hvis de kommer til at arbejde med frontend-udvikling på et ASP.NET projekt, som også er ved at være en meget udbredt web-teknologi i erhvervslivet.

En anden fordel ved at lære dem både et websprog som Javascript og et general purpose sprog som f.eks. C# vil være at de vil få den første oplevelse af hvor mange ting de har til fælles og hvor mange af teknikkerne der går igen. Det vil give dem en større forståelse for programmeringssprog generelt og gøre at de vil have lettere ved at tage springet til at lære flere.

Peter Lind

I forhold til Desktop-udvikling har jeg reelt svært ved at pege på andet end C# og Visual Studio (som findes i en ganske udmærket gratis udgave der egner sig fint til formålet: http://www.microsoft.com/visualstudio/eng/products/visual-studio-express... ).
Det er der flere grunde til - Visual Studio er en begyndervenlig IDE, med rigtig god intellisense support.


Dvs. lær folk at man ikke kan programmere uden intellisense. Det fejler inden man er kommet i gang.

GUI editoren heri er formentlig den bedste på markedet (og lysår bedre end hvad du finder indenfor Java verdenen).
Og et faktum er også at det meste desktop udvikling indenfor erhvervslivet stadig er målrettet Windows platformen.

Her kunne man så fokusere lidt bredere og give folk lidt bedre evner, så vi også med lidt held kan undgå at forstærke den i forvejen problematiske tendens der er i Dk til at fokusere på Microsoft produkter.

Så kunne vi muligvis få bedre udviklere, der fokuserer mere på problemerne og den løsning, der skal bruges, frem for at deres IDE skal hedde noget med Visual for ellers kan de ikke finde ud af det.

Kevin Harritsø

Jeg synes man bør:

  • Lære et maskinnært programmeringssprog, fx. C.
  • Lære et applikationsegnet sprog, fx Java.
  • Lære et hack / script / m.v. sprog, fx. Python.

Herefter kan man passende så begynde at danne sin egen mening om hvornår en given opgave skal løses i hvilket sprog. Man kunne passende kigge på nogle eksempler på assembler niveau og se hvad de forskellige compilere genere ud fra kildefilerne.
Så lære softwareingeniører omkostningerne ved at kaste rundt med diverse objekter og elektronikingeniører lærer at applikationsprogramming ikke altid kan betale sig i C.

Herudover synes jeg også at man bør lære at holde styr på sin kode, lære at sætte toolchains op og lære at lave et releasescript så de kan lave software releases af det software de hacker på.

Carsten Hansen

Da jeg i 1988-90'erne gik til eksamen, så var det på kvaderet papir. Så var man tvunget til at lave et strukturet program og kunne den basale syntax. Hvis det er på computer, så er der en fare for copy/paste programmer.

Det kan nok ikke bruges, hvis programmeringen består af GUI/grafik :-)

Der er nok ikke mange tilbage som mig, der altid laver HTML/CSS i hånden.

Pelle Söderling

Dvs. lær folk at man ikke kan programmere uden intellisense. Det fejler inden man er kommet i gang.

Nu handler det jo netop om UI udvikling hvor man typisk har brug for at interagere med et forretningslogik lag (som nogle andre i firmaet har udviklet), dette er ofte dårligt dokumenteret og uden intellisense vil alternativet være at du skal grave rundt i kildekoden til dette library for at finde ud af hvad funktionerne hedder du skal kalde.

Intellisense er et værktøj som er kommet for at blive, det letter udviklingen betragteligt og især for folk der interesserer sig mere for UI design end programmering er det en stor hjælp - vi kan ikke blive ved med at hænge fast i hvordan vi gjorde tingene i 90'erne.

Her kunne man så fokusere lidt bredere og give folk lidt bedre evner, så vi også med lidt held kan undgå at forstærke den i forvejen problematiske tendens der er i Dk til at fokusere på Microsoft produkter.

Det lyder fint at fokusere bredt, men hvis du vil lære folk Desktop udvikling på tværs af Windows, MacOSX og Linux så udvander du det så meget at den eneste reelle teknologi der kan leve op til dit krav er Java, hvor UI udvikling er notorisk ringe. Istedetfor at uddanne nogle UI Designere der rent faktisk kan gå ud og få et job og en karriere, så vil du hellere udstyre dem med en teknologi hvor UI udvikling er så handikapped at de vil skulle bruge mere tid på at slås med dette end at lære noget om UI design - blot for at bekæmpe hvad du mener er en problematisk Microsofts tendens i dansk erhvervsliv?

Jeg interesserer mig reelt ikke for om der står Microsoft eller ej på produktet - jeg interesserer mig for hvad der er det bedste produkt i undervisningsammenhæng og Microsoft laver nu engang nogle ret gode udviklingsværktøjer - specielt i den ende hvor brugerens primære interesseområde netop ikke er programmering, hvilket flere her i debatten lader til at glemme.

Carsten:

Der er nok ikke mange tilbage som mig, der altid laver HTML/CSS i hånden.

På hobby-niveau har du helt sikkert ret, men jeg kender ikke nogen der arbejder professionelt med frontend-udvikling der ikke håndkoder deres HTML og CSS :)

Peter Lind

Nu handler det jo netop om UI udvikling hvor man typisk har brug for at interagere med et forretningslogik lag (som nogle andre i firmaet har udviklet), dette er ofte dårligt dokumenteret og uden intellisense vil alternativet være at du skal grave rundt i kildekoden til dette library for at finde ud af hvad funktionerne hedder du skal kalde.

Så fordi nogle udviklere i nogle virksomheder er elendige til deres job vil du gøre UI udviklere generelt afhængige af en bestemt IDE? I stedet for at give dem en bedre overordnet indsigt i deres fag, så de også kan lære lidt mere om at klare sig selv senere hen?

Det lyder fint at fokusere bredt, men hvis du vil lære folk Desktop udvikling på tværs af Windows, MacOSX og Linux så udvander du det så meget at den eneste reelle teknologi der kan leve op til dit krav er Java, hvor UI udvikling er notorisk ringe. Istedetfor at uddanne nogle UI Designere der rent faktisk kan gå ud og få et job og en karriere, så vil du hellere udstyre dem med en teknologi hvor UI udvikling er så handikapped at de vil skulle bruge mere tid på at slås med dette end at lære noget om UI design - blot for at bekæmpe hvad du mener er en problematisk Microsofts tendens i dansk erhvervsliv?

Man kunne også lade være med at fokusere på en bestemt teknologi og lade folk lære mere generelt ved at give dem flere teknologier - og så sørge for at de lærer hvad det faktisk handler om, i stedet for hvordan man drag/dropper i Visual Studio. For der er andre ting derude (og nej, java er ikke det eneste).

Og jeg mener ikke det er en problematisk Microsoft tendens, det er en problematisk tendens. Tjek hvad der bliver slået op af jobs i Dk sammenlignet med lande rundt omkring os, så vil du se en ret stor forskel. Danmark er langt hen af vejen en monokultur og en af de primære grunde er de skyklapper folk får på allerede under uddannelsen.

Troels Henriksen

Herudover synes jeg også at man bør lære at holde styr på sin kode, lære at sætte toolchains op og lære at lave et releasescript så de kan lave software releases af det software de hacker på.

Jeg tror du skal læse blogindlægget igen. Det er helt specifikt ikke fremtidigt programmører der her skal undervises i programmering.

Selv vil jeg være ukreativ, og foreslå HTML/JavaScript. Hvis man hurtigt vil have resultater, så er det svært at overgå. Alternativt ville jeg anbefale Python med et lettilgængeligt GUI-bibliotek.

Pelle Söderling

Så fordi nogle udviklere i nogle virksomheder er elendige til deres job vil du gøre UI udviklere generelt afhængige af en bestemt IDE?

Nu handler det i dette tilfælde ikke om at lære IDE'er - det handler om at lære 2 UI design paradigmer, nemlig Web og Desktop. Jeg vil da klart foreslå man bruger en anden editor til Web-delen netop for at give mere adspredelse i værktøjsvalget, men når det kommer til at lære om Desktop UI design, så er det så stort et emne at det ikke nytter noget at eleverne skal slås med værktøjerne. Når nu det bedste værktøj til dette formål på markedet findes i en gratis udgave, mener jeg det vil være direkte dumt ikke at udnytte dette så man kan fokusere på det væsentlige i undervisningen.

Man kunne også lade være med at fokusere på en bestemt teknologi og lade folk lære mere generelt ved at give dem flere teknologier

Du glemmer at det er uddannelser med fokus på UI, det giver ikke mening at bruge en masse tid på at lære dem flere forskellige sprog, platforme og operativsystemer - hvis det var det man interesserede sig for havde man nok valgt datalogi-studiet.

Og jeg mener ikke det er en problematisk Microsoft tendens, det er en problematisk tendens. Tjek hvad der bliver slået op af jobs i Dk sammenlignet med lande rundt omkring os, så vil du se en ret stor forskel.

Jeg anfægter ikke at en meget stor del af erhvervslivet i Danmark anvender Microsoft teknologier - det ved jeg lige så vel som dig at de gør!
Jeg anfægter at NÅR nu det er tilfældet, så vil det jo være torske-dumt af uddannelserne at ignorere Microsoft teknologier når det er det erhvervslivet efterspørger.

Jeg er klar over der er mange herinde der ikke ser noget problem i at tage de studerende som gidsler i kampen mod det onde Microsoft-imperie, men hvis resultatet er at man uddanner til arbejdsløshed hvad skal vi så bruge det til?

De Microsoft orienterede virksomheder i Danmark kigger netop efter Microsoft teknologier på eksamensbeviset, hvis du ikke kan præsentere dem, så ryger du med stor sandsynlighed nederst i bunken eller direkte i papirkurven.

Du lyder jo til selv at være godt inde i disse jobopslag, så du ved lige så vel som mig at det der efterspørges er kompetencer i meget specifikke teknologier (ofte Microsoft teknologier) - et typisk opslag til en frontend webudvikler i DK kunne indebære følgende teknologier: HTML/CSS/Javascript/ASP.NET/C#

Hvis du kommer med HTML/CSS/Javascript/PHP/Python/C/C++/Ruby/ActionScript, er sandsynligheden for at du får jobbet formentlig ret lille medmindre der er få ansøgere.

Peter Lind

Nu handler det i dette tilfælde ikke om at lære IDE'er - det handler om at lære 2 UI design paradigmer, nemlig Web og Desktop.


Dit første argument for C# var IDE. Det gør det ret nærliggende at påpege at det ikke handler om at lære en IDE og at du gør folk en bjørnetjeneste ved at binde dem til en IDE.

Jeg vil da klart foreslå man bruger en anden editor til Web-delen netop for at give mere adspredelse i værktøjsvalget, men når det kommer til at lære om Desktop UI design, så er det så stort et emne at det ikke nytter noget at eleverne skal slås med værktøjerne. Når nu det bedste værktøj til dette formål på markedet findes i en gratis udgave, mener jeg det vil være direkte dumt ikke at udnytte dette så man kan fokusere på det væsentlige i undervisningen.

Jeg har svært ved at se at værktøjet er vigtigere end hvad man lærer, jvf. Torbens kommentar ovenfor.

Du glemmer at det er uddannelser med fokus på UI, det giver ikke mening at bruge en masse tid på at lære dem flere forskellige sprog, platforme og operativsystemer - hvis det var det man interesserede sig for havde man nok valgt datalogi-studiet.

Nej, det glemmer jeg ikke. Jeg synes til gengæld det giver fantastisk god mening at lære folk at være mere abstrakte i stedet for at binde dem til én teknologi, som de så sidder fast i. Man kunne eksempelvis tage fat i mobile devices og hvordan man laver UI der. Hvis du lærer det på de forskellige platforme, så vil du have meget nemmere ved senere at udvikle til andre ting også.

Jeg anfægter ikke at en meget stor del af erhvervslivet i Danmark anvender Microsoft teknologier - det ved jeg lige så vel som dig at de gør!
Jeg anfægter at NÅR nu det er tilfældet, så vil det jo være torske-dumt af uddannelserne at ignorere Microsoft teknologier når det er det erhvervslivet efterspørger.

Jeg er klar over der er mange herinde der ikke ser noget problem i at tage de studerende som gidsler i kampen mod det onde Microsoft-imperie, men hvis resultatet er at man uddanner til arbejdsløshed hvad skal vi så bruge det til?

Jeg tvivler så bare på at man i det lange løb uddanner til arbejdsløshed. Jeg tror - i modsætning til dig - på at arbejdsmarkedet vil tilpasse sig, når arbejdsstyrken ændres. Specielt hvis arbejdsstyrken overordnet bliver mere fleksibel og ikke kun kan bruge MS produkter, men kan bruge MS produkter eller andre ting.

Du lyder jo til selv at være godt inde i disse jobopslag, så du ved lige så vel som mig at det der efterspørges er kompetencer i meget specifikke teknologier (ofte Microsoft teknologier) - et typisk opslag til en frontend webudvikler i DK kunne indebære følgende teknologier: HTML/CSS/Javascript/ASP.NET/C#

Hvis du kommer med HTML/CSS/Javascript/PHP/Python/C/C++/Ruby/ActionScript, er sandsynligheden for at du får jobbet formentlig ret lille medmindre der er få ansøgere.

Er der mange om udbuddet kan virksomhederne vælge hvad de vil. Er der ikke, må de overveje om andre kan opfylde kravet - eller om man evt. har tænkt for snævert i forhold til krav.

Så forskellen synes at være, så vidt jeg kan se, at du er glad og tilfreds med status quo, mens jeg ikke er.

Pelle Söderling

Så forskellen synes at være, så vidt jeg kan se, at du er glad og tilfreds med status quo, mens jeg ikke er.

Jeg har ikke travlt med at gøre studierne til kampplads for hvilke teknologier erhvervslivet skal anvende, hvis det er det du mener. Som erhvervsdrivende forbeholder jeg mig 100% denne ret og hvis jeg ikke kan finde kvalificerede udviklere i Danmark, så må jeg kigge andetsteds.

Jeg tvivler så bare på at man i det lange løb uddanner til arbejdsløshed. Jeg tror - i modsætning til dig - på at arbejdsmarkedet vil tilpasse sig, når arbejdsstyrken ændres

Hvis jeg skal vælge en dansk udvikler der skal have 25-35k i månedsløn, så skal det være fordi det faglige niveau er højt og at vedkommende matcher de kompetencer jeg efterspørger. Mine krav ændrer sig ikke fordi arbejdsstyrken ændrer sig - vi lever idag i en meget lille verden - om jeg skal drive virksomhed i DK eller østeuropa er et spørgsmål om 2 timers rejsetid, det er flintrende ligegyldigt.

I Ukraine, Rumænien og lign. vil jeg kunne få kvalificeret arbejdskraft med 5+ års erfaring til ca. 8-10k/mnd.
Jeg vil gerne støtte op om at skabe arbejdspladser i Danmark, men det må være rimeligt at forvente at niveauet så også er højere. Hvis det både forventes at vi i erhvervslivet skal videreuddanne de nyuddannede før de kan bruges og samtidig skal betale dem 3 gange mere i løn, så taber de nyuddannede altså til østeuropa - det er desværre den virkelighed de seneste års udvikling har medført, verden er i sandhed blevet lille.

Men hvad status quo angår, så er jeg ikke specielt tilfreds med at man uddanner frontend-udviklere i ActionScript og kun ActionScript. Hvis jeg skal bruge en Web UI designer, så vil du få meget svært ved at overbevise mig om at jeg skal vælge en UI designer hvis baggrund udelukkende er ActionScript. Ligeledes hvis jeg skal bruge en Desktop UI designer har jeg også meget svært ved at se hvad jeg skal med en der har en baggrund i flash-udvikling. Skal jeg have lavet noget Flash, så kan vi tale om det, men det var vist mere aktuelt i forrige årti.

Problemet her er at uddannelserne uddanner så generelt (og i forældede teknologier) at de beder os om at videreuddanne dem før de kan bruges til noget - større virksomheder har muligvis ressourcerne til dette, mindre virksomheder har ikke. Danmark er i høj grad en kultur af mindre virksomheder, så dette udgør et problem.

Jeg har svært ved at se at værktøjet er vigtigere end hvad man lærer, jvf. Torbens kommentar ovenfor.

Ang. Torbens kommentar kan jeg sagtens følge ham hvis det handler om at uddanne programmører - jeg tror den var ment som et generelt indspark i forhold til at lære programmering, men det her handler om UI udvikling. Desktop UI udvikling handler om at skabe brugerflader og det rigtige værktøj hertil gør at undervisningen kan fokusere på hvad det vil sige at skabe brugerflader og lade eleverne afprøve teorierne, komponenterne involveret osv. nemt og bekevemt i en god drag'n'drop editor - det handler reelt meget lidt om kode, men mere om usability, layout, brugervenlighed vs brugbarhed, hvilke UI controls der er gode til at understøtte hvilke scenarier, UI patterns for diverse scenarier osv.

Hele den diskussion er svær at tage hvis eleverne først skal være eksperter i programmering for at kunne designe en UI eller hvis de skal slås med dårlige UI designers.

Det er også det eneste valide argument jeg kan se for at man har valgt at undervise i Flash/ActionScript til at starte med da den også indeholder en fornuftig UI editor til dette formål - desværre er tiden bare løbet fra det og fokusområdet er lidt for snævert.

Jon Bendtsen

Problemet her er at uddannelserne uddanner så generelt (og i forældede teknologier) at de beder os om at videreuddanne dem før de kan bruges til noget - større virksomheder har muligvis ressourcerne til dette, mindre virksomheder har ikke. Danmark er i høj grad en kultur af mindre virksomheder, så dette udgør et problem.


Problemet er her at når du ikke længere kan sælge produkterne i den nuværende teknologi når den bliver til den forældede teknologi, så skifter du bare medarbejderne ud, for de kan jo kun den forældede teknologi, og når de ikke er på din lønningsliste så er de ikke længere noget problem for dig.

Derfor skal folk uddannes tidsløst så de forstår de grundlæggende paradigmer, funktioner, data, metoder, ... således at folk let kan skifte til nye teknologier.

Pelle Söderling

Derfor skal folk uddannes tidsløst så de forstår de grundlæggende paradigmer, funktioner, data, metoder, ... således at folk let kan skifte til nye teknologier.

I praksis sker der somregel bare det at når folk uddannes tidsløst i noget, så lærer de aldrig hvad det vil sige at lave noget nutidigt.
Istedetfor at uddanne teoretikere, ser jeg hellere at man indenfor dette område uddanner praktikere med teoretisk indsigt - hvis de kun kan teorien og kun har arbejdet med esoteriske sprog og værktøjer ingen i dansk erhvervsliv anvender, så får de det altså rigtig svært.

I forhold til at omstille sig oplever jeg sjældent at folk der har været ude i erhvervslivet i et par år har specielt svært ved dette - de første år giver ofte langt mere erfaring og teoretisk indsigt end studiet.

Det springende punkt er efter endt uddannelse når de nyuddannede skal ud og søge deres første job, det er her de fleste tabes på gulvet og her har uddannelserne et medansvar.

Desuden, skifter man altså ikke bare medarbejdere ud - det er ikke robotter, i forhold til din forretning besidder utrolig mange af disse medarbejdere en hel masse forretningskritisk viden om din virksomhed og produkter - hvis du først har haft en medarbejder i mere end et års tid, vil det (udover fra et menneskeligt perspektiv) også rent økonomisk give god mening at videreuddanne vedkommende - den viden vedkommende ligger inde med hvis et produkt skal overføres til en ny platform vil i den sammenhæng være guld værd (denne viden kan du i praksis IKKE købe dig til :-)

Jon Bendtsen
Pelle Söderling

Det er ikke min oplevelse at arbejdsgiverne gør sig sådanne langsigtede tanker, i stedet for ser de langt mere på bundlinien i næste kvartal så de kan få udbetale deres bonus.

Der er stadig ledere af den gamle skole som ikke har forståelse for hvad det vil sige at have videnarbejdere ansat.

Men der er kommet mere fokus på det og det er mit indtryk at specielt yngrer erhvervsdrivende har langt mere forståelse for dette og vil gå langt for at holde på en videnarbejder der ligger inde med kritisk information om virksomhedens systemer og produkter (et faktum man som videnarbejder selvfølgelig bør udnytte til lønforhandlingerne).

Nu taler du om bonus, hvilket indikerer en mellemleder og de kan desværre til tider have andre motiver end virksomhedens bedste.

Lars Tørnes Hansen

Python er rigtig godt valg. Det sprog er mit nye sprog til scripts og mindre programmer.
Der findes et IDE der hedder Eric5: http://eric-ide.python-projects.org/ jeg gerne vil anbefale folk at bruge, ellers der også IDLE 3. (Eric 5, og IDLE 3 er for Python 3.x serien)

Der er også Qt og QML, som er Qt software der skrives med et Javascript inspireret sprog:
http://doc.qt.digia.com/qt/qdeclarativeintroduction.html
http://en.wikipedia.org/wiki/QML

I vi ovre i sprog der oversættes til kildekode, så kan man bruge:
Object Pascal med FreePascal compileren og som IDE kan man bruge Lazarus: http://wiki.lazarus.freepascal.org/Lazarus_Documentation.

Michael Niebuhr

Jeg takker for de mange gode forslag og perspektiver.

Python var faktisk modus operandum på studiet, indtil for 4 år siden. Så kom en ny underviser til, der selv var bedre til Java.

Og det bringer mig til et andet problem: at få studenterundervisere, der forstår faget, og kender sproget+miljøet+de gængse problemer. Det mister man nemlig, når man skifter sprog. Foruden opgaverne, lærebøgerne, og eksemplerne. Altså en stor beslutning.

Mit eget råd til instituttet, er at have et sprog på 1. semester, og et andet på 2. semester. Det kan fint være Javascript, med henblik på at matche sproget med HTML5/CSS3.

Den egentlige gevinst, ser jeg i at modellere et responsivt design i (eksamens)opgaverne på 2. semester. Det vil i den grad ruste de studerende til studiejobs, og give dem nogle redskaber som de kan arbejde videre med på egne (primært web)projekter.

Web-området har jo traditionelt været ugleset blandt systemudviklere, men de dage må da snart være forbi. Det håber jeg også, at mit gamle institut får øjnene op for (jeg har i hvert fald argumenteret hårdt).

Som nogle debattører peger på, er det nok ikke afgørende, hvad det første sprog er, bare det i det mindste er nogenlunde nemt at lære, og IDE ikke giver for mange udfordringer (læs: problemer).

Dette er jo i høj grad tilfældet, hvis man skifter til et andet sprog på 2. semester.

Den risiko jeg kan se, er at de dårligste studerende (de der er mindst med, forståelsesmæssigt), vil få rigtig svært ved at skifte til et nyt sprog. Forskellen mellem de dårligste og de bedste vil øges, og det vil blive endnu sværere at stille opgaver, som er udfordrende nok for de dedikerede, og realiserbare for de svageste (igen svagest forståelsesmæssigt).

Man kunne også argumentere for, at de svageste får en ny start ved at skifte sprog. Den tror jeg desværre ikke på, da de jo netop vil være begyndere igen - og ikke fortsættere som resten af holdet.

Jeg tror en stærk kombination vil være Python på 1. semester, og Javascript/HTML/CSS på 2. semester. Det vil være en udfordring at finde studenterundervisere (instruktor), og kurserne vil skulle laves helt om. Dette er slet ikke uladsiggørligt, men det vil kræve en økonomisk anerkendelse, som instituttet næppe vil give. Heller ikke for at skyde uddannelsen ind i det 21. århundrede (min vurdering).

Det skal til sidst i parantes bemærkes, at kandidatstuderende kan vælge fag med hhv. Objective-C- og Java-programmering. Sådan har det hele tiden været, men disse fag når selvfølgelig kun de studerende der er særligt interesserede i at tilegne sig programmeringskundskaber (mange falder i øvrigt fra - i indeværende semester over halvdelen. I sidste semester en lignende mængde. De starter helt fra scratch, forståelsesmæssigt, viser det sig, og bliver hurtigt sat. Desværre.)

Kim Hjortholm

At fortsætte med flash som undervisningsprog virker som et meget besynderligt valg - flash er på vej væk, mere præcis lige så hurtigt som skiftet til mobile enheder foregår... og det går rasende hurtigt
Steve Jobs fravalg af flash på IOS platformen var dødsstødet til det sprog og udviklingsmiljø. Uddannelse i flash er stort set lige med kompetence til ikke eksisterende jobs.

Undervisning i HTML5 og et eller flere javascript frameworks vil være langt bedre bud på kompetencer der vil kunne bruges når man var færdig med uddannelsen uanset hvilke gren man måtte lande på.
Evnen til at bruge frameworks og sætte sig ind i disse er en nøglekompetence i forhold til mange typer af webrelaterede jobs.

Endelig vil undervisning i et populært udvilings framework og et objektorienteret sprog være et godt valg - ruby on rails / ruby som et muligt godt valg hvor læringskurven skulle være mindre end for Objective-C/Java

Peter Jensen

python er et rigitgt godt sprog, og nemt at lære og usædvanligt alsidigt, bruger det selv til alt fra små scripts over database programmer (Psycopg, nå ja så skal man også lige lidt sql) til afløsning for scilab med numpy og scipy.........desuden skal man også kunne alle de andre sprog når man har brug for det, men personligt mener jeg at enten kan man programmere (og så er man heldig) eller også kan man ikke, men så kan man jo bare få et job i en bank eller sådan noget.

Jesper Madsen

Det du giver dine studerende er et værktøj. Hvis de ikke synes det er anvendeligt, så kommer det ikke i værktøjskassen. Da det for mange muligvis er det tætteste de nogensinde kommer på at programmere, så er det vigtigt at give dem noget de kan bruge. Hvis de skulle videre til andre programmeringssprog, så ville de også opleve, at det efterhånden blev ligegyldigt hvilket sprog de brugte. Da de, med flere sprog "under vesten", sagtens ville få øje på algoritmer og generelle teknikker. Men for nybegyndere, så vil de fleste kunne slå op og finde kodeeksempler, og rette dem til, men de forstår ikke hvad koden gør, og de vil sikkert ikke kunne fremstille den selv. Næste gang de skal våge sig til at kigge på noget kode, vil de have dine kodestumper i hovedet, og kan de ikke bruge dem når de er færdige, så kan de ikke selv skabe noget kode. Er man på begynder niveau, med kun et programmeringssprog under vesten, så er der meget langt til at lære noget nyt.
Jeg ville nok vælge at tage HTML 5, Javascript og CSS 3 med, og vise både hvordan man kan gøre i actionscript, og hvordan man gør tilsvarende i HTML 5, og så lade de studerende selv vælge hvad de vil lave opgaver i.

Martin Brynskov

Tusind tak, Michael, for en aldeles glimrende for-og-imod-gennemgang af mulighederne, når man skal vælge introducerende programmeringssprog (and everything that goes with it) for humanister.

For the record var det mig, der tog beslutningen om at vælge ActionScript (det objektorienterede sprog, ikke Flash) for fire somre siden. Det var dælme ikke noget let valg, og man kan mene mange ting om det.

I parentes vil jeg bemærke, at jeg har været både en stor tilhænger af Flash (på mobil fra ca. 2003-06 (se bare, hvad det kunne i Japan), ikke på web), samtidig med at jeg efterfølgende var aldeles skeptisk og hilste Jobs' dolk i ryggen på Adobe meget velkommen.

Jeg skal ikke gentage Michael gode argumenter for og imod, men blot nævne to forhold.

(1) På Informationsvidenskab på Aarhus Universitet har der over årene (siden 1986) været afprøvet introducerende programmeringssprog i stort set alle afskygninger (kronologisk): Pascal, C, Beta, HyperTalk, SuperTalk, Prolog, Java, Python og ActionScript (mindst). Det korte af det lange er, at de alle har haft argumenter for og imod.

Jeg gik selv til skriftlig eksamen på papir i Beta. Compileren gik altid ned. Men det var fedt. Syntes jeg. Og her er en væsentlig pointe. At lære at programmere starter i høj grad med at se sig selv som "programmør". Der er en kultur knyttet til ethvert værktøj, også programmeringssprog.

Når man vælger et programmeringssprog og -omgivelse til en uddannelse, signalerer man i høj grad en identitet, som de studerende skal kunne føle sig hjemme i.

Digital Design (kører nu på femte år) og Informationsvidenskab skal dels favne ret bredt ift. studenteroptaget (fx mht. uddannelsesmæssig baggrund, fremtidige jobønsker og identitet), dels imødekomme folk helt uden forudsætninger (og umiddelbar motivation) for algoritmisk tænkning -- på lige fod med rimelig ferme script kiddies.

Ift. ActionScript vil jeg sige: It seemed like a good idea at the time, all things considered.

(2) Prøv at checke en jobannonce med titlen "Digital Designer". Udgangspunktet er ret konsekvent Adobes Creative Suite.

Det siger godt nok ikke meget om uddannelsen "Digital Design" på Aarhus Universitet, for den sigter ikke mod den grafiske branche, i modsætning til fx en interaktiv grafiker fra Mediehøjskolen (DMJX). Men det giver alligevel et pejlemærke for nogle forventninger om, hvad "kreative" "digitale" "designere" orienterer sig i forhold til.

Man skal ganske enkelt kunne lave digitale produkter -- fra websites, embedded, fysisk, wireframes, skitser, mock-ups, prototyper osv. Og meget ofte er det skitsen, der er det centrale.

De værktøjer, herunder ikke mindst programmeringssprog- og omgivelser, man har i sin værktøjskasse, afgør pretty much, hvad man kan lave.

Pointen her er ikke, at man nødvendigvis skal lade sig begrænse af værktøjerne. Alle programmører ved, at man da altid kan lære et nyt sprog osv. Java-schmava. Who cares. Digitale designere lærer også at lodde og sy (fx sin egen computer).

Men når man ikke har fundet sin identitet som "programmør" -- og måske slet ikke skal finde sig til rette med den titel -- så betyder valget en hel del.

Det var de to pointer.

Det varer nok ikke så længe, før vi skifter igen. Fem år er en fin periode -- se bare på Kina og Coca-Cola.

For mig ville det ideelle valg lige nu være HTML/CSS/Javascript + Python (evt. Java) + Processing. Men ingen af dem har "hele pakken" med både robuste IDE'er (auto-complete, refactoring, unit testing ...), tilhørende "kultur", objektorientering, frontend/backend-ideel og umiddelbar erhvervsrelevans. Desuden har vi ikke instruktorer (og undervisningsplaner), der lige kan levere varen uden forberedelse. Fuldstændig som Michael argumenterer.

Derudover har vi masser af erfaring med både at skifte sprog efter 1. eller 2. semester, og med at lade være. At skifte slår ekstremt negativt ud på flere parametre.

Så, bare for at sige tak til Michael, og til alle de mange gode forslag og kommentarer -- det er dælme ikke så let.

Som salig Shalespeare skrev:
To code or not to code, that is the question;
Whether ’tis nobler in the mind to suffer

The buttons and arrows of outrageous interfaces,

Or to take tools against a sea of troubles,

And by opposing, mend them.

Anders Scheel

Jeg kan se at det er en ret udbredt misforståelse at flash er på vej væk fra de mobile platforme.

Jo, der kommer ikke flere flash-playere til de mobile browsere, men Adobe har i den grad fokuseret på app-udvikling (med Air).

I de nyeste versioner er der mulighed for (med Stage3D) at tilgå de mobile grafikkort - 2D/3D grafik - med programmérbare shadere(!).

Med samme kode (med små undtagelser, selvfølgelig) kan man altså target Android og IOS (og Web for den sags skyld).

Til undervisning synes jeg også at FlashBuilder/Actionscript dækker meget bredt:

  • "Objektorieteret" udvikling
  • CSS-principper
  • Enkel integration til mange forskellige typer webservices.
  • Problematikker ved udvikling til forskellige platforme, skærmstørrelser, opløsninger osv.
  • Hurtig prototyping til mobile platforme - smart til de studerendes projekter, tænker jeg?
  • små 2D/3D spil/app's og engine udvikling til mobil (indføring af grundprincipperne i lineær algebra, textures, index og vertex buffers, culling, stencil-tests osv.)

Når det er sagt, så er actionscript et forfærdeligt sprog, som låner gode og dårlige principper fra en del kendte sprog, som C-grenen, Python og javascript, og har flere en fundamentale mangler i min optik. Eksempelvis kan man ikke overloade metoder eller override constructor (eller gøre den private!).

Dertil kommer at SDK´et og FlashBuilder er relativt buggy - for de studerende vil dog næppe være noget problem.

Nå, det var mit bidrag til lidt mere for og imod ActionScript/Flash til undervisning.

Mvh. Anders :-)

Esben A Black

Jeg tror aldrig det "rigtige" sprog bliver fundet til de studerende du beskriver. Når det er sagt så tror jeg det vigtige er at tilrettelægge undervisningen således at brugen af sproget viser hvilke problemer de(t) kan løse.

I min tid på AU lærte jeg mest når jeg blev sluppet løs på et konkret problem/projekt og selv skulle finde frem til en løsning.

Så jeg siger vælg et sprog, lav nogle opgaver hvor en del af løsningen er givet, eks. et API til at hente data, og bed om en løsning der bygger på den eksisterende kodebase.

Jeg så, men kan selvfølgelig ikke huske kilden en undersøgelse der konkluderede at der ikke er nogen gevinst, i udviklingstid, ved at bruge stærkt typede sprog som java, det kunne være et incitament til at vælge et andet som Javascript eller Python.

Anders Tolborg

Jeg er nysgerrig. Hvad mener I, når nogle af jer skriver, at de studerende burde lære HTML5? Altså.. hvad er det lige præcis de skal lære?

Michael Niebuhr

Jeg vil tro, at det man mener, er at lave Flash-lignende produkter på en HTML5-platform. Altså grafik og multimedie-elementer vha. HTML5-tags og Javascript-programmering. Det er vel den rolle, som de nye elementer i HTML5 er tiltænkt.

Når man foreslår HTML5 i et programmeringsfag, er det pga. koblingen til Javascript (og JQuery). Dette kunne for så vidt foregå i almindelig "oldschool" HTML, men med f.eks. Canvas i HTML5 er der lidt mere basis for Flash-lignende produkter.

Pelle Söderling

"Jeg så, men kan selvfølgelig ikke huske kilden en undersøgelse der konkluderede at der ikke er nogen gevinst, i udviklingstid, ved at bruge stærkt typede sprog som java, det kunne være et incitament til at vælge et andet som Javascript eller Python."

Det lyder som noget værre vrøvl for at være ærlig, der er så mange fordele i typestærke sprog at denne diskussion burde være død idag. Det kan ikke svare sig at bruge tid på runtime type debugging når compilere og IDE's (static analysis) idag kan finde disse problemer langt tidligere i forløbet i typestærke sprog. Desuden ender folk i typesvage sprog ofte med alligevel at nævne typerne i underlige kommentarer og lign. fordi de godt kan lide Intellisense supporten. Det er muligt typesvage sprog er lettere at gå igang med for begyndere, men til langt de fleste større projekter er det mere en ulempe end en fordel.

Jens Peter Jensen

@Pelle.
Jeg vil ikke mene, at runtime performance er den vigtigste parameter i valg af typestærkt/typesvagt sprog til indledende programmering, men snarere en pædagogisk overvejelse.
Jeg har selv oplevet studerende, hvis primære problem (i Matlab) var, at de kæmpede med en masse (for dem) uforståelige fejlmeldinger fra oversætteren, når de lavede spandevis af typefejl. Her tror jeg det ville have hjulpet med et sprog, hvor man (som i java, C++, ..) skal erklære variable med den ønskede type, så man bliver tvunget til at være bevidst om, hvilke typer, man jonglere med.

Pelle Söderling

Hej Jens

Jeg snakkede reelt ikke om runtime performance, men snarere debugging på runtime niveau vs compile time niveau - hvor jeg til enhver tid mener disse fejl bør fanges så tidligt i forløbet som muligt (debugging koster nemlig meget hurtigere langt mere tid end det at skulle skrive et par type navne foran variabler).

Men nu er dette jo ikke den eneste faktor man bør tage hensyn til i forhold til at introducere programmering, mange af de sprog folk lærer sig selv på egen hånd (til hobbyprojekter og lign.) er somregel typesvage (Javascript og PHP især). Så jeg vil ikke afvise der kan være pædagoiske årsager til at vælge et typesvagt sprog til undervisning, men jeg er enig i at man ikke skal lave ret meget i det førend fordelene ved et typestærkt sprog slår igennem.

Torben Mogensen

Jeg snakkede reelt ikke om runtime performance, men snarere debugging på runtime niveau vs compile time niveau - hvor jeg til enhver tid mener disse fejl bør fanges så tidligt i forløbet som muligt (debugging koster nemlig meget hurtigere langt mere tid end det at skulle skrive et par type navne foran variabler).

Og selv det at skrive typenavne kan man spare ved at bruge typeinferens. Det giver det bedste af begge verdener: Man slipper (ligesom i dynamisk typede sprog) for at skrive typeerklæringer over det hele, og man har den tidlige fangst af fejl, som kendes fra eksplicit typede sprog. Den primære ulempe er, at fejlmeddelelserne er mindre præcise (og mere kryptiske) end i eksplicit typede sprog.

Dynamiske typer har nogle enkelte små fordele for eksempel omkring metaprogrammering, men det er de færreste programmører, der skal skrive selvfortolkere eller partielle evaluatorer.

Til begynderundervisning kan man dog godt bruge dynamisk typede sprog. Dynamisk typede sprog kræver selvdisciplin, og det er ikke så dumt at lære det, når man skal programmere.

Peter Lind

Jeg snakkede reelt ikke om runtime performance, men snarere debugging på runtime niveau vs compile time niveau - hvor jeg til enhver tid mener disse fejl bør fanges så tidligt i forløbet som muligt (debugging koster nemlig meget hurtigere langt mere tid end det at skulle skrive et par type navne foran variabler).

Det er så igen en af de ting der kommer an på hvordan man lærer at programmere og hvilke værktøjer man bruger. Jeg bruger primært svagt-typede sprog (php, javascript, python, etc) og jeg oplever intet problem i forhold til forbrug af tid mht debugging. Tværtimod fanges disse fejl meget hurtigt i processen, fordi test og arkitektur tvinger dem frem. I modsætning hertil har jeg set folk gå helt kolde når de skulle finde ud af hvorfor deres c# ikke ville compile ... eller kastede rundt med runtime exceptions.

Svagt-typede sprog vs. stærkt-typede sprog burde være en non-starter diskussion på nuværende tidspunkt, men da folk insisterer på ikke at kunne se ud fra det skyttehul de har gravet sig ned i, så har vi stadig de diskussioner, i stedet for at fokusere på de praksisser, der gør dem totalt overflødige.

Nikolaj Brinch Jørgensen

Det lyder som noget værre vrøvl for at være ærlig, der er så mange fordele i typestærke sprog at denne diskussion burde være død idag. Det kan ikke svare sig at bruge tid på runtime type debugging når compilere og IDE's (static analysis) idag kan finde disse problemer langt tidligere i forløbet i typestærke sprog. Desuden ender folk i typesvage sprog ofte med alligevel at nævne typerne i underlige kommentarer og lign. fordi de godt kan lide Intellisense supporten. Det er muligt typesvage sprog er lettere at gå igang med for begyndere, men til langt de fleste større projekter er det mere en ulempe end en fordel.


Skriver du ikke unittests? Det burdei hvert fald være noget som skulle læres samtidigt med programmering (Python er et godt valg, Ruby ligeså).
Mener du typesvag eller dynamisk typet? Man behæver ikke skrive typerne i mange typestærke sprog, da compileren tager sig af det (type inferens). Her betaler du så for ultraslow compilering (Scala).

Den debat du har gang i med typed vs un-typed vs dynamically typed languages er religion, der er ikke noget der er bedre end andet.

Pelle Söderling

Religion og religion, det er jo også en nem måde at afvise debatten på - det er jo ikke sådan at vi beskæftiger os med metafysik her.

Som Torben skriver er der nogle få områder hvor dynamiske sprog har en fordel, men det er ikke de områder 99% af det kode der skrives i dynamiske sprog bruges til.

Jeg har mindre imod type inferens, sålænge det ikke misbruges, jeg er f.eks. ikke stor fan af "var" keywordet i C#. Det er generelt bare dovenskab ikke at skrive typerne når det er åbenlyst, det gør koden mindre vedligeholdesvenlig.

Generelt er det der bruges mest tid på ikke at skrive koden (den tid det tager at skrive typer er grænsende til ligegyldigt), det er at debugge fejl i koden. Generelt bliver fejl dyrere at fikse jo senere i forløbet de fanges - at overlade fejlene til runtime niveau betyder ikke så meget hvis fejlene er nemme at teste for, men det er ikke altid så nemt, slet ikke hvis vi går ind i concurrency verdenen (som jo idag er mere relevant end nogensinde da vi får flere kerner, men ikke specielt meget hurtigere kerner), her kan det betyde meget at fejl fanges af compileren eller via statisk analyse før runtime niveau.

Der kan være mange andre gode grunde til at vælge et af disse sprog, men at de er dynamisk typede er kun et godt argument til specielle scenarier - ikke til alm. applikations- og webudvikling.

Torben Mogensen

Man behæver ikke skrive typerne i mange typestærke sprog, da compileren tager sig af det (type inferens). Her betaler du så for ultraslow compilering (Scala).

Typeinferens behøver ikke at medføre langsom oversættelse. Moscow ML oversætter for eksempel lynhurtigt, selv om den laver typeinferens. Det er primært optimeringer (inlining, dataflowanalyse osv.), der tager tid, og det laver Moscow ML ikke meget af, mens Scala laver en del. Dog skal det siges, at Scalas typeinferens nok tager mere tid end MLs, da Scalas typesystem er mere kompliceret pga. klassesystemet. En kort beskrivelse af faserne i Scalacompileren kan ses på https://wiki.scala-lang.org/display/SIW/Overview+of+Compiler+Phases

Finn Aarup Nielsen

Lære et applikationsegnet sprog, fx Java.
Lære et hack / script / m.v. sprog, fx. Python.

Hvad er "et applikationsegnet sprog"? Er Python et applikationsegnet sprog? På Linux er der efterhånden mange applikationer der er skrevet i Python. Jeg er blevet overrasket over at selv et så centralt program i Ubuntu som "/usr/bin/update-manager" er i Python. Andre Python applikationer jeg har brugt er dropbox, gwibber, jokosher og gramps.

Nikolaj Brinch Jørgensen

Religion og religion, det er jo også en nem måde at afvise debatten på - det er jo ikke sådan at vi beskæftiger os med metafysik her.

Som Torben skriver er der nogle få områder hvor dynamiske sprog har en fordel, men det er ikke de områder 99% af det kode der skrives i dynamiske sprog bruges til.


Ok, religion var måske også en overdrivelse. Så lad os sige at det er præference, om man bedst kan lide stærk typede eller dynamisk typede sprog. Der er ikke noget bevis for at det ene er bedre end det andet. Ellers må du da meget gerne frembringe det?

Jeg har mindre imod type inferens, sålænge det ikke misbruges, jeg er f.eks. ikke stor fan af "var" keywordet i C#. Det er generelt bare dovenskab ikke at skrive typerne når det er åbenlyst, det gør koden mindre vedligeholdesvenlig.


Det er så igen din holdning, og ikke noget du kan henføre til nogen form for generel term.

Generelt er det der bruges mest tid på ikke at skrive koden (den tid det tager at skrive typer er grænsende til ligegyldigt), det er at debugge fejl i koden. Generelt bliver fejl dyrere at fikse jo senere i forløbet de fanges - at overlade fejlene til runtime niveau betyder ikke så meget hvis fejlene er nemme at teste for, men det er ikke altid så nemt, slet ikke hvis vi går ind i concurrency verdenen (som jo idag er mere relevant end nogensinde da vi får flere kerner, men ikke specielt meget hurtigere kerner), her kan det betyde meget at fejl fanges af compileren eller via statisk analyse før runtime niveau.

Nej hvis man sjusker og starter sit arbejde i en editor, så kan man hurtigt slaske noget kode sammen, og så kan man bagefter bruger 80% af tiden i debuggeren. Generelt er jeg modstander af debuggeren, da den ofte (kun min erfaring med at lede udvikler teams) producere noget rigtigt dårlig kode i sidste ende.
Grunden er, at koden blvier skrevet primaturt, og antagelserne der eksisterede for den kode der blev skrevet var forkerte. Det forsøges så løst med debugger og if-sætninger, i stedet for at få styr på sine antagelser og få skrevet hele koden rigtigt (altså om, på baggrund af tests der beskriver antagelserne).

Når du omtaler concurrency, hvad fejler så præcist et sprog som Erlang? Det er et vældig godt sprog (og runtime) til concurrency, og det er i høj grad både et dynamisk og dynamisk typed sprog. Det er så godt, at concurrency modellen i det stærkt typede sprog Scala er taget derfra.

Hvilket sprog er det som har en compiler der kan fange concurrency-fejl, og som iøvrigt er et sprog der benyttes udenfor academia?

Der kan være mange andre gode grunde til at vælge et af disse sprog, men at de er dynamisk typede er kun et godt argument til specielle scenarier - ikke til alm. applikations- og webudvikling.


Det er så din holdning. Min holdning er at dit udsagn er noget vrøvl. Java er i den grad dynamisk typed, når vi snakker runtime opførsel. Og man må sige der er temmelig udbredt. Ligeledes er Python, PHP, Ruby og også Groovy m. fl. Hvilke sprog er det du mener der er stærkt typede, som egner sig så vældig godt til applikations-/webudvikling?

Nikolaj Brinch Jørgensen

Dog skal det siges, at Scalas typeinferens nok tager mere tid end MLs, da Scalas typesystem er mere kompliceret pga. klassesystemet. En kort beskrivelse af faserne i Scalacompileren kan ses på https://wiki.scala-lang.org/display/SIW/Overview+of+Compiler+Phases


Ja Scala kompliere langsomt, og så skal de fleste udviklere bruge enormt lang tid på at slås med typesystemet (da det er meget komplekst) for overhovedet at producere noget. Den tid skal oveni, så et typesystem der skal battles med, og en compiler der er langsom til at verificere det, det er noget skidt for Scala salget. Det har en fyr som David Pollak også for nyligt sagt i et interview.

Michael Niebuhr

Jeg tror vi er kommet lidt væk fra sporet, men netop den løsagtige omgang med typer i Javascript, er en af mine dårlige erfaringer med at undervise i det sprog.

Som det andet sprog man lærer, synes jeg dog at den indvending er af mindre karakter.

Er der nogen der har erfaring med OOP-undervisning i Javascript, der kan lede opmærksomheden hen på noget godt undervisningsmateriale - opgaver/litteratur/inspiration?

Christian Hammer

Jeg har igennem 8 år undervist på en ungdomsskole (14-16 årige) og har forsøgt med bl.a. Java på Eclipse og noget C på et tidspunkt. Men intet har fungeret så enkelt og nemt som JavaScript/HTML/CSS på en tekst-editor.
Det er min erfaring, at undervisning på begynderniveau faktisk kan drage fordel af JavaScripts "manglende" stærke typer - de fleste mennesker forstår, og kender allerede til, begrebet "objekt" og "interface" (blot disse koncepter forklares jordnært) og med det som udgangspunkt, er det nemt at guide eleverne ind i programmeringens verden.
Og det er ikke kun i undervisning, jeg bruger JavaScript - professionelt arbejder jeg intensivt med det dagligt og kender en hel del til diverse finurligheder, især mht DOM-håndteringen og browser/versions-forskelligheder. Dette kan man, på begynderniveau, godt abstrahere fra og vælge en specifik browser at arbejde op imod.
Normalt bruger jeg de første halvanden time til at tale (professionelt set ret overfladisk) om XML/HTML, box-modellen, farver, filer, linking etc - altså ren HTML. Eleverne får hurtigt noget "selvskabt" på skærmen og efter en lyngennemgang af CSS, sendes de til w3schools for at lege videre med CSS & HTML.
Dernæst guider jeg dem igennem JavaScript, der oftest er at få et billede til at bevæge sig henover skærmen. Ret hurtigt fatter de fleste at hvad der gælder x-retningen også må gælde y-retningen og efter ca 4-5 timers undervisning, flyver billeder og tekst lystist rundt.
At optakten til den egentlige programmering er kort, ser jeg som en undervisningsmæssig nødvendighed. Det skal også være sjovt og eleverne skal hurtigt opleve, at skridtet til at lave spil (har muligvis noget med aldersgruppen at gøre) virker pludseligt overkommelig. Det giver ikke plus-point at skulle bruge lang tid på udviklingsmiljøer, typer, klasse-hierarkier & nedarvning, namespaces, scoping etc.
Hverken professionelt eller i min undervisning bruger jeg diverse (JavaScript-)biblioteker. Oftest er disse mere overhead end egentlig gavn og det er ikke videre svært selv at lave samme funktioner. Derimod kan det give mening at lave sit eget lille "undervisnings-bibliotek", der tager brodden af de tungeste opgaver.

Pelle Söderling

Christian: Jeg er helt enig i at der gælder et andet udgangspunkt når man har med den aldersgruppe at gøre og når det ikke handler om at uddanne professionelle programmører - men om at skabe nysgerrighed for emnet.

Når det er sagt forstår jeg dog ikke helt din holdning til at gå udenom Javascript libraries, jeg synes netop de abstraherer besværligheder såsom cross-browser issues væk og dermed gør at man kan fokusere på at skabe mere værdi hurtigere. Det er SÅ meget nemmere at udvælge og manipulere elementer på skærmen med et library såsom jQuery og kender man allerede til CSS selectors er det utrolig let at gå til - ærlig talt mener jeg elever i netop denne målgruppe vil kunne opnå visuelle resultater hurtigere ved netop at tage et sådant library i brug. Professionelt forstår jeg heller ikke helt din tilbageholdenhed, jQuery er efterhånden en industri-standard indenfor javascript udvikling og det er uendelig meget nemmere at finde folk der forstår at videreudvikle og vedligeholde projekter lavet i jQuery end projekter udviklet i "hjemmebiks-library v0.1" og det fungerer altså også bedre for medarbejderne når de skal videre at kunne skrive ekspertise i jQuery på CV'et - hvis du kigger på jobopslag er det meget ofte en kompetence der lægges vægt på når der søges javascript-udviklere.

Michael Niebuhr

Meget positivt at høre om din undervisning, Christian.

For nogle år siden var jeg i praktik som gymnasielærer i Datalogi på Katedralskolen i Aarhus. Underviseren havde udviklet sit eget kursusmateriale netop i Javascript.

Det var noget værre spaghettikode, der kom ud af det, men de studerende var utrolig glade for at kunne komme hurtigt i gang med "spændende hjemmesider". På den måde var det det helt rigtige valg.

På universitetet vil der samtidig skulle undervises i OOP, frameworks og modellering. Der er det ikke hensigtsmæssigt at blive i en teksteditor, og arbejdet med klasser og hierarkier skal være overskueligt. Vigtigst af alt, må det ikke ende i spaghettikode, da bedømmelsen af eksamensopgaverne beror på argumentationen for og udførslen af opbygningen af programmerne.

Mht. jQuery, er jeg enig i at det giver langt bedre programmer, hurtigere, men ikke nødvendigvis en bedre forståelse. Tværtimod.

Christian Hammer

Pelle: For at tage den professionelle del først, så arbejder jeg med JavaScript på en måde, hvor der (endnu) ikke findes biblioteker der giver rimelig mening at bruge. Havde jeg været mere GUI-orienteret kunne et bilbiotek måske have relevans. Dog har jeg flere eksempler på, at det var nemmere, hurtigere og mindre resourcekrævende at selv bygge dnødvendige GUI-element op. Et konkret tilfælde brugte jQuery + jQuery-ui + noget opsætningskode, der samlet beløb sig til knap ½ MB. Jeg kunne lave samme(!) tooltip på knap 1K, uden yderligere biblioteker.
Jeg oplever at der er en tendens til at hive "multiværktøjet" frem, hver gang der er noget det skal løses, fremfor at bruge en smule tid på at sætte sig ind i hvad det konkrete problem er og hvad der er den "enkleste" løsning.
Men nu er diskussionen ikke hvorvidt jeg ikke er vild tilhænger af JS-bibliotek A, B eller C. :)
Set fra et undervisnings-synspunkt, vinder man, i mine øjne, ikke noget ved at inddrage et større bibliotek - især ikke tidligt i forløbet. Gør man det, kommer der hurtigt forvissing omkring hvad der er bibliotek og hvad der er kernen af JavaScript.
F.eks. at lave en animation - som vi gør efter de nævnte ca 4 timer (på uret) - koster ikke ret meget kode i ren JavaScript og giver samtidig mulighed for at give et lille indblik i tråd/multitasking-begrebet.
Man kan, naturligvis, vælge at introducere et bibliotek - så længe det passer ind i undervisningen.

Pelle Söderling

Michael: Enig i at jquery ikke giver bedre "lowlevel" forståelse - et generelt problem ved high-level sprog og frameworks.

Men i Christians målgruppes tilfælde er forståelse formentlig mindre vigtig end at få successoplevelser - så det hurtigere at kunne nå resultater og slippe for at slås med crossbrowser issues mener jeg vil være et plus i den sammenhæng.

Christian Hammer

Michael: Mht OOP kræver det vel ikke klasse-hierarkier? Som jeg anskuer JavaScript er det faktisk mere objekt-orienteret end f.eks. Java og C++ - objekter er første-klasses borgere i JS og modellering behøver heller ikke være klasse-modellering. Som jeg forstod det, er du jo ikke ved at uddanne Dataloger, men mere en slags "programmerings-brugere".
Frameworks kunne sagtens introduceres via f.eks. jQuery (hermed håber jeg at imødekomme Pelle ;-)
Om eleverne bruger en Windows Notepad eller et rigere miljø, ændrer vel ikke på hvorvidt god navngivning, gode kommentarer, konsistent indryknings osv tages i brug? Ved at have "frie hænder", fordres også et vist ansvar og hvis afleveringerne kræve læsbar og forstålig kode, er det op til den enkelte elv at sikre dette - uanset udviklingsmiljø.

Christian Hammer

Pelle: Som jeg vist fik nævnt, klarer jeg cross-browser issues ved at advokere for en enkelt browser :) Snyd, ja - men det virker. jeg fortæller naturligs hvorfor og kommer her ind på at der er forskelle. Men det er rigtigt at x-browser problematikker er en unødvendig komplicerende faktor i undervisningen og at eg. jQuery kunne hjælpe lidt her. Igen er det et spørgsmål om biblioteket giver plus eller minus på besværligheds-kontoen.

Michael Niebuhr

Med OOP i vores kursussammenhæng menes nedarvning, polymorfi, strategy pattern, decorator pattern, MVC, og lignende. Jeg vil helst anvende en IDE, der giver mig code completion og et overblik over mine klasser, metoder, konstruktører, osv. Meget gerne med farvekodning eller ikoner, så det er tydeligt (i hvert fald vist) hvad der er hvad.

Jeg siger ikke, at det ikke kan lade sig gøre at modellere det samme i Notepad, men det er ikke en opgave jeg vil bryde mig om at stille studerende. Jeg finder det en stor hjælp, at vise hvad punktum efter myString eller myObject giver af muligheder. Det er for mig den hurtigste vej til overblik, og indgang til API.

Det kursus jeg omtaler er et fortsætterkursus på andet semester på Informationsvidenskab, hvor de studerende er bekendte med et sprog og konstruering af mindre programmer (billedmanipulering, lommeregner, Haiku-generator, f.eks.). De skal gå fra spaghetti/begynderkode til velkonstrueret OOP.

Christian Hammer

OK, så er målet og udgangspunktet naturligvis noget andet. Jeg har flere elever der kommer igen året efter, og de arbejder typisk videre med java @ Eclipse. I og med de allerede kender til - og til en vis grad, er blevet bidt af - programmering, er Java et udemærket og logisk videre skridt. Det ligger også bedre til, at introducere compilere, import/includes, statiske typer etc på dette niveau, hvor eleven kan se fordelene ved disse ting.
Men for at være djævlens advokat for en kort bemærkning, hvad er egentlig det overordnet mål for dit kursus på I.V.? Vil du skabe gode programmører - eller give en lidt dybere indsigt i programmering til folk der for 80% vedkommende, ikke vil komme ud i at programmere igen?
Skulle det sidste være tilfældet, kan jeg se der er en mulighed for "blot" at lave en avanceret viderebygning på første kursus. Men dette giver selvfølgelig ikke den store mening, hvis de skal være brugbare programmører.
Ifm min undervisning har jeg måtte sande at 95% af eleverne blot er nysgerrige og max 5% vil arbejde videre med det. Derfor er det vigtigt for mig, at få underholdnings-værdien godt op, så eleverne i det mindste ser programmering som andet end et nørde-fag.

Michael Niebuhr

Kort fortalt, som blogindlæget også startede, er studerende på Informationsvidenskab ikke tænkt som "programmører". Deres faglighed bygger på en forståelse af programmering, og andre aspekter af udvikling. Det kan være modellering (traditionelt vha. UML), og kendskab til de mest brugte OOP-begreber og patterns.

Derfor er en forståelse af programmering historisk vægtet højere, end store programmer og stor kompleksitet i arbejdet. De studerende arbejder med at forstå og implementere patterns, og modellerer på papir (eller i en grafisk editor), samtidig med udviklingen af mindre systemer. De afslutter kurset med en gradueret eksamen, hvor de bedømmes på en skriftlig opgave om et system de har udviklet i en gruppe. Programmet er altså bilag for opgaven, og bedømmelsen sker på baggrund af en skriftlig rapport om programmets opbygning, funktionalitet og indhold.

Log ind eller opret en konto for at skrive kommentarer

IT Businesses