Er det altid godt at være dynamisk?

Men jeg havde sådan set forventet at universitetsverdenen studerede den slags.

Universitetsverdenen studerer primært det, den kan få forskningsmidler til, og den slags komparative studier er det svært at få penge til -- og de er ret dyre, hvis resultaterne skal være nogenlunde troværdige. For det kræver, at man finder programmører, der har præcist den samme mængde af erfaring med Haskell og Python. Og det vil ofte betyde, at man træner ikke-programmører fra bunden i de to sprog med lige lang tid til hvert sprog.

Der har været lavet komparative studier, men dem, jeg kender til, er ret gamle, og lavet med forholdsvis små populationer.

Nemt nok: Du finder programmer i Haskell og oversætter dem så direkte som muligt (linje per line) til Python, og ser om du kommer til at introducere fejl, som statisk typecheck ville have fanget.

Jeg ved ikke hvad det skal forestille at teste. Selv hvis jeg ikke introducerede en eneste fejl af nogen slags, så ville jeg jo ikke kunne påstå at jeg havde bevist noget. Der er ingen analogi til Prechelts studie. Transskribering er en meget atypisk måde at udvikle software på.

Derimod ville jeg vældigt gerne se et komparativt studie af produktivitet i programmeringssprog som inkluderer mere moderne statisk typede sprog; en opdatering af Prechelt. Men jeg havde sådan set forventet at universitetsverdenen studerede den slags.

Jeg mener naturligvis: Hvordan skal jeg gennemføre et eksperiment i stil med Prechelts.

Nemt nok: Du finder programmer i Haskell og oversætter dem så direkte som muligt (linje per line) til Python, og ser om du kommer til at introducere fejl, som statisk typecheck ville have fanget.

Så i begge sprog er du jo nødt til at konvertere til en numerisk type. I stedet for "cowboytricket " * 1, hvorfor bruger du ikke parseFloat eller number lige som du ville gøre i fx C#?

og er amerikansk separator tåbeligt fordi du skal krudt på at konvertere eller hvordam skal det forstås?

Jeg kan slet ikke se hvordan jeg vil komme i mål med et dynamisk sprog, når man laver store refaktoreringer i store projekter. Her er compileren guld værd.

Og det er et sted hvor man kan se at ikke alle typesystemer og dermed ikke alle statisk typede sprog er skabt ens. Hvis man sammenligner refactoring i C# og Java, så er det min erfaring at i C# er man sikker på at det refaktorerede program virker på samme måde som det oprindelige. I Java sker det at der bliver forskel. Det er fordi type-systemet i Java i nogle tilfælde (generics) blot er syntaktisk sukker og at programmer der egenligt er syntaktisk forkerte alligevel virker.

Og derfor mener jeg i øvrigt at Java bør få reified generics og custom valuetypes ASAP.

Jeg fortrækker statiske sprog, men er glad for dynamics i C# som man kan bruge hvor det giver mening.

Jeg kan slet ikke se hvordan jeg vil komme i mål med et dynamisk sprog, når man laver store refaktoreringer i store projekter. Her er compileren guld værd.

Funktionen skal summere to inputfelter og returnere resultatet til et tredje og tage højde for at værdierne er indtastet med decimalkomma og ikke tåbeligt amerikansk decimalpunktum.</p>
<p>Læg mærke til, at fordi jeg ikke kan definere fval som en real så er jeg nødt til at lave cowboytricket med at gange fval med 1, for ellers betragtes det som en streng.

Det er igen i dårligt eksempel, det helt samme vil fx ske i C#.

var a = ... streng fra UI var b = ... anden streng fra UI var c = a + b

Så i begge sprog er du jo nødt til at konvertere til en numerisk type. I stedet for "cowboytricket " * 1, hvorfor bruger du ikke parseFloat eller number lige som du ville gøre i fx C#?

og er amerikansk separator tåbeligt fordi du skal krudt på at konvertere eller hvordam skal det forstås?

Du kan downloade oversættere her:

Jeg mener naturligvis: Hvordan skal jeg gennemføre et eksperiment i stil med Prechelts.

Jeg har skam prøvet både SML og Miranda.

Jeg er ikke forsker, hvordan vil du have jeg skal gøre det?

Du kan downloade oversættere her:

• Standard ML: MLton
• Haskell: Haskell
• F#: Windows, Linux, macOS

Mig bekendt er der ikke krav om en forskeransættelse for at kunne hente og bruge dem.

Det er en idé i hvert fald, jeg har ikke selv prøvet at skrive CL med typeannotering, så det kan godt være jeg overvurderer deres praktiske anvendelighed.

Jeg har prøvet CL med typeannoteringer, og du overvurderer deres praktiske anvendelighed. Statisk er de primært nyttige som lavniveau-optimering ("x er altid et fixnum"), hvor visse oversættere så kan advare hvis de kan se at du ikke overholder annoteringen. De er ikke specielt nyttige til at udtrykke f.eks. sum- og produkt-typer på en statisk verificérbar måde.

http://evanfarrer.blogspot.com/2012/06/unit-testing-isnt-enough-you-need

Interessant udviklingsstrategi. Først skriver man et programbibliotek i et dynamisk typet sprog, og så oversætter man det linie for linie til et statisk typet sprog.

Jeg ville have foreslået ham at bruge Common Lisp i stedet for Python og Haskell, for så kunne han bare have tilføjet typer i stedet for at skrive noget om. Det er en idé i hvert fald, jeg har ikke selv prøvet at skrive CL med typeannotering, så det kan godt være jeg overvurderer deres praktiske anvendelighed.

Han får mere eller mindre gendrevet påstand 2 og 3, hvilke ikke kan overraske. Det kan godt være han har hørt folk sige de ting mange gange, men derfor behøver jeg ikke være enig i dem. Påstand 1 derimod er jeg enig i, med det forbehold at unit testing er ikke den eneste måde at teste på. Men den påstand kan hans metode hverken be- eller afkræfte.

Men altså, nej, det er ikke et svar på Prechelt, for det studerer noget helt andet.

Prøv i stedet ML, Haskell eller F#.

Jeg er ikke forsker, hvordan vil du have jeg skal gøre det?

Med moderne type inferens er der iøvrigt ikke den store forskel på hvor meget der skal skrives. De fleste type erklæringer kan undlades.

Ja man kan hurtigt gøre kål på typesystemet hvis der er inferens ;) Jeg er generelt enig med dig, men jeg synes det er et tveægget sværd.

C# tillader at du strør om dig med "var", og C++ har tilsvarende "auto".

Hvis det bruges for flittigt, så kan meget af det smarte ved statiske typer forsvinde efter min mening, idet typerne bliver "usynlige".

Bevares, typesystemet bliver kontrolleret og skal stadig stemme overens - så du får ikke flere typefejl ved at bruge inferens.

Analogi: Jeg undlader ofte typerne i fx. Haskell og SML mens jeg udvikler/itererer over et design, og så tilføjer jeg dem når jeg er ved at være færdig, og nu ved hvilke specifikke typer jeg gerne vil have og ikke bare de allermest generelle der kan bruges (som jo er resultatet hvis du bruger Hindley-Milner inferens).

Det er væsentligt nemmere at lave en editor eller IDE der kan hjælpe programmøren når der er tale om et statisk typet sprog. Du får med det samme at vide at den der går ikke, ligesom at editoren giver forslag til hvad det er, du vil skrive. Editoren kan også hjælpe med at refactorere hvis du eksempelvis vil omdøbe en funktion, så kan den automatisk finde alle kald til denne funktion og også rette der.

Med moderne type inferens er der iøvrigt ikke den store forskel på hvor meget der skal skrives. De fleste type erklæringer kan undlades.

Hvis man må være lidt fræk, så er den største styrke ved dynamisk typede sprog at man skal kunne mindre og have mindre forståelse for koncepter som eksempelvis typer. Man kan prøve sig frem. Men til gengæld mister man hjælpen fra udviklingsmiljøet, så det bliver hurtigt til en ulempe når nybegynderen avancerer.

Til gengæld har jeg spildt vanvittig meget tid på statisk typede sprog der enten kræver ekstremt meget upfront arbejde eller tager lang tid om at fange de fejl, der alligevel vil blive fanget ved kørsel af programmet.

Jeg er 800% på holdet for statisk typede sprog men du har ret her. Det er almindelig best practice at alt kode skal køre i automatisk test inden det kommer i produktion og såfremt man har ordentlig coverage så fanges den slags fejl. Personligt er jeg hurtigere til at finde fejl i statisk typede sprog, men det er nok forskelligt fra person til person.

Men der hvor kæden falder af er når en anden skal overtage koden. Han får meget lidt guidance når typerne mangler. Når han kalder metoden "getFirstElement" på et objekt, så er det ikke vil at sige hvad der sker fordi det i princippet kan være en vilkårlig metode med navn "getFirstElement" der kaldes.

På samme måde når det handler om refactorying. Hvis jeg vil rename metoden "f" så er det ikke givet hvilke af metoderne "f" der er "in scope" for renaming. I praksis mister man en række muligheder for auto refactoring når typerne forsvinder.

Læg mærke til, at fordi jeg ikke kan definere fval som en real så er jeg nødt til at lave cowboytricket med at gange fval med 1, for ellers betragtes det som en streng.

Du mener, du har ikke styr på javascript i browsere, og det er sprogets skyld? Input felter er strings, så du vil altid få en string ud. For at omdanne til den korrekte type bruger du Number(fval) - Number("2.1") giver som forventet 2.1.

Vi du dermed sige, at når du koder i et statisk typet sprog, så har du aldrig nogensinde fået en typefejlmeddelelse fra compileren?</p>
<p>Så er du enten den bedste programmør i verden, eller du har aldrig programmeret noget mere kompliceret end "Hello World" i statisk typede sprog.

Nej. I det omfang de fejl sniger sig ind bliver de fanget før koden kommer i decideret brug. Det er irrelevant om compileren eller programmøren fanger dem.

Til gengæld har jeg spildt vanvittig meget tid på statisk typede sprog der enten kræver ekstremt meget upfront arbejde eller tager lang tid om at fange de fejl, der alligevel vil blive fanget ved kørsel af programmet.

Og nu hvor vi er på emnet, så kan jeg ikke lade være med stærkt at opfordre til at se denne video om svagt typede sprog (javascript):
<a href="https://www.destroyallsoftware.com/talks/wat">https://www.destroyallsof…;

Det giver 2, ganske som forventet.

function calsum(firstval,secondval,endsum) 
{
	var fval = document.getElementById(firstval).value.replace(',','.');
	var sval = document.getElementById(secondval).value.replace(',','.');
	document.getElementById(endsum).value = (1<em>fval+1</em>sval).toFixed(2).replace('.',',');
}	

Læg mærke til, at fordi jeg ikke kan definere fval som en real så er jeg nødt til at lave cowboytricket med at gange fval med 1, for ellers betragtes det som en streng.

Og det er i min optik udtryk for et programmeringssprog som tangerer det sublime lort.

Det er det der er kernen med Javascript, man kan ikke altid forudsige hvad der sker, pga. den manglende typing.

var a = 1;
var b = 1;</p>
<p>Og hvad mon så a+b giver -- tadaaaah : 11.

Som nævnt andetsteds er svaret 2, men hvad nu hvis vi laver nogle små varianter:

'1' + 1 + 1 giver '111' 1 + 1 + '1' giver '21' 2 + '2' giver '22' 2 * '2' giver 4 {2} giver 2 {2} + 2 giver 2 2 + {2} giver uendelig løkke ({2}) giver uendelig løkke {{2}} giver 2 {{}} giver undefined {({})} giver {} {({2})} giver uendelig løkke 1 + {} giver '1[object Object]'

Det giver alt sammen god mening. Eller hva'?

Bare fordi man smækker Typescript på Javascript gør det ikke sproget til et strongly typed sprog, det er meget vigtigt at holde fast i den forskel. Den primære udfordring jeg selv støder ind i når jeg bruger weakly typed sprog som JS er som regel at det kan være svært at gennemskue om en varibel rent faktisk er af den type du forventet, f.eks. et string[] det pludselig er blevet et string[][], den type problematikker er ikke eksisterende i strongly typed sprog som Java, C# osv.

Enig. Typescript er ikke et særlig godt eksempel på et sprog med statiske typer. Der er jeg enig med Torben, Standard ML eller lignede er et langt bedre eksempel. Hindley-Milner typesystem, inferens, totalitets-check osv.

medium.com-blogindlægget ender i øvrigt med at konkludere at Typescript som modkandidat til vanilla JS ikke giver meget merværdi. Bl.a. pga. veludviklede værktøjer til vanilla JS såsom JSlint - altså et eksternt program til at foretage statiske checks, bl.a. af typerne. Det nuancerer for mig diskussionen gevaldigt :)

Min egen erfaring er, at nogle programmer med meget dynamisk opførsel er nemmere at kode i dynamisk typed sprog som Scheme, Lisp og Python.

I større programmer foretrækker jeg statiske typer fremfor dynamiske. Jeg mister overblikket over typerne hvis ikke de står skrevet i koden, når projektet runder nogle tusinde liniers kode og bliver spredt over flere filer.

jeg hverken oplever eller laver selv de fejl en compiler fanger.

Vi du dermed sige, at når du koder i et statisk typet sprog, så har du aldrig nogensinde fået en typefejlmeddelelse fra compileren?

Så er du enten den bedste programmør i verden, eller du har aldrig programmeret noget mere kompliceret end "Hello World" i statisk typede sprog.

Stærkt defineret og svagt definerede sprog kunne også være en betegnelse?

Det har en lidt anderledes betydning:

Stærkt typede sprog vil fange alle typefejl, enten før eller under kørsel. De kan altså godt være dynamisk typede. Scheme er et eksempel.

Svagt typede sprog vil ikke fange (alle) typefejl, så nogle operationer udføres på værdier, hvor det ikke giver mening.

Det gælder f.eks. maskinsprog, hvor man rask væk kan gange en stringpointer med pi og bruge resultatet som returadresse. Det gælder også f.eks. unions i C, hvor du kan have en union af double og funktionspointer, lægge pi i double-feltet, hente værdien ud via pointer-feltet og kalde den som en funktion.

Lad mig åbne ballet med Prechelt(2000). Det samme program tager kortere tid at udvikle i dynamiske sprog, vel og mærke uden at korrektheden lider.

Ikke underligt, når de statisk typede sprog, der sammenlignet med er C, C++ og Python. Prøv i stedet ML, Haskell eller F#.

Jeg trumfer med http://evanfarrer.blogspot.com/2012/06/unit-testing-isnt-enough-you-need.html

Der er meget man kan kritisere JS for, men det har bare ikke noget at gøre med statisk vs. dynamisk. Et statisk typet JS vil producere nøjagtigt den samme værdi eller fejlmeddelelse.

Bare fordi man smækker Typescript på Javascript gør det ikke sproget til et strongly typed sprog, det er meget vigtigt at holde fast i den forskel. Den primære udfordring jeg selv støder ind i når jeg bruger weakly typed sprog som JS er som regel at det kan være svært at gennemskue om en varibel rent faktisk er af den type du forventet, f.eks. et string[] det pludselig er blevet et string[][], den type problematikker er ikke eksisterende i strongly typed sprog som Java, C# osv.

('b' + 'a' + + 'a' + 'a').toLowerCase()

Der er meget man kan kritisere JS for, men det har bare ikke noget at gøre med statisk vs. dynamisk. Et statisk typet JS vil producere nøjagtigt den samme værdi eller fejlmeddelelse.

Og hvad mon så a+b giver

Det giver 2, ganske som forventet.

Stærkt defineret og svagt definerede sprog kunne også være en betegnelse?

Og nu hvor vi er på emnet, så kan jeg ikke lade være med stærkt at opfordre til at se denne video om svagt typede sprog (javascript):https://www.destroyallsoftware.com/talks/wat

('b' + 'a' + + 'a' + 'a').toLowerCase()

var a = 1; var b = 1;

Og hvad mon så a+b giver -- tadaaaah : 11.

Vil til en hver tid foretrække et sprog hvor jeg forlods kan definere typen.

Statiske typer finder fejl, men det er ikke det samme som at statisk typede programmer har færre fejl.

Ganske vist er type-annotering en aktivitet der finder fejl, men det er en blandt mange: Afprøvning, unit tests, granskning, omhu - det er alt sammen aktiviteter som også finder fejl, og som konkurrerer om software-udviklerens tid. Hvad der er den bedste brug af tiden, det finder man ikke ud af uden at måle.

Så hvor er empirien? Hvor er studierne? Jeg håber forskningen på DIKU har andet at tilbyde end anekdoter og karikaturtegninger...

Lad mig åbne ballet med Prechelt(2000). Det samme program tager kortere tid at udvikle i dynamiske sprog, vel og mærke uden at korrektheden lider.

Eric Elliot har en ret fornuftig post om det: <a href="https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b">ht…;

Du burde få 10x thumbs up bare for den. Meget god læsning

Jeg arbejder primært med dynamiske sprog men har været forbi et par statiske også. Fordelen ved de statiske sprog er for mig til at overse - jeg hverken oplever eller laver selv de fejl en compiler fanger. Det er en anden type fejl, der opstår - og de ville også opstå i statiske sprog.

Eric Elliot har en ret fornuftig post om det: https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b

Alt er selvfølgelig kontekst-afhængigt - det her er baseret på erfaring med webudvikling.

... så er du kureret for ideen om, at "dynamisk" lyder bedre end "statisk".

Efter at have fejlsøgt kode i mange år, vil jeg til enhver tid foretrække statiske sprog.

Dog kan jvm-sprog stadig drille, da generics' typecheck (desværre) kun sker i compileren og ikke på runtime. I den ideelle verden gør det jo ingen forskel, men meget ofte er kodebasen kompileret til en anden version af et library, end den version som koden faktisk eksekvere med. Og så ser man samme type-fejl på runtime, som når Erlangs pattern matching falder over en ukendt værdi eller python dict eller ValueError.