mboost-dp1
En der ikke er så glad for JavaScript
[list]
[li]No method overload [...][/li]
[/list]
Ikke direkte nej, men man kan hurtigt wrappe en funktion omkring switch (typeof var).
[list]
[li]No type for a function parameter means no hint for its possible value[/li]
[/list]
Igen, typeof.
[list]
[li]The autocomplete does not work correctly forcing you to keep using “Search” to find the possible actions[/li]
[li]This results in going back and forth to the documentation to see how a library can be used (if you’re lucky and the library has one)[/li]
[li]The name of variables are much shorter making them less descriptive (because sometimes you have to type them completely – no help from your IDE)[/li]
[/list]
Blah, blah, blah. Det handler bare om at få fat i en ordentlig IDE samt kodestil og dokumentation.
Godt nok kan statiske typer i nogle tilfælde være lidt for ufleksible, men dynamiske typer lider af et andet problem, som ofte er meget værre.
Med dynamiske typer kan først fange typefejl på runtime. Det er ikke rart at udvikle i et sprog hvor man får runtime fejl, som kunne være fanget ved kompilering.
Fornuftigt designet polymorphism kan til gengæld dække de fleste behov. Man har ikke den totale frihed som dynamiske typer giver, men til gengæld betyder de få begrænsninger man har at det faktisk kan lade sig gøre at verificere ved kompilering om koden kan resultere i en typefejl. Samtidigt får man fleksibilitet nok til at håndtere alle normale anvendelser.
Det generiske eksempel er når man implementerer en container. På det tidspunkt ønsker man ikke at begrænse hvilke typer der kan gemmes i containeren, man ønsker at alle typer kan gemmes deri. Men når man instantierer sin container vil man gerne begrænse den til en bestemt type.
Med et fornuftigt design af polymorphism kan referencer/pointere til en container angive typen af objekter der må ligge i den container. Dermed kan det hver gang containeren tilgås verificeres ved kompilering at der anvendes korrekt type.
Med dynamiske typer kan først fange typefejl på runtime. Det er ikke rart at udvikle i et sprog hvor man får runtime fejl, som kunne være fanget ved kompilering.
Fornuftigt designet polymorphism kan til gengæld dække de fleste behov. Man har ikke den totale frihed som dynamiske typer giver, men til gengæld betyder de få begrænsninger man har at det faktisk kan lade sig gøre at verificere ved kompilering om koden kan resultere i en typefejl. Samtidigt får man fleksibilitet nok til at håndtere alle normale anvendelser.
Det generiske eksempel er når man implementerer en container. På det tidspunkt ønsker man ikke at begrænse hvilke typer der kan gemmes i containeren, man ønsker at alle typer kan gemmes deri. Men når man instantierer sin container vil man gerne begrænse den til en bestemt type.
Med et fornuftigt design af polymorphism kan referencer/pointere til en container angive typen af objekter der må ligge i den container. Dermed kan det hver gang containeren tilgås verificeres ved kompilering at der anvendes korrekt type.
Lord Daniel-Dane (2) skrev:Ikke direkte nej, men man kan hurtigt wrappe en funktion omkring switch (typeof var).
Ja.
Men det er godt nok ikke en køn konstruktion.
Lord Daniel-Dane (2) skrev:Det handler bare om at få fat i en ordentlig IDE
Autocomplete kan vel per definition ikke fungere så godt i et duck typing sprog som i et static typed sprog - uanset hvor god IDE'en nu måtte være.
kasperd (3) skrev:Med dynamiske typer kan først fange typefejl på runtime. Det er ikke rart at udvikle i et sprog hvor man får runtime fejl, som kunne være fanget ved kompilering.
Det synes ikke at være et problem i masser af web apps.
Jeg ville blive bekymret hvis jeg sad i et fly og de computere som styrede fly og kontroltårne var skrevet i et sådant sprog.
Min fornemmelse er dog at det ikke er usædvanligt at komme forbi websites hvor javascript giver runtime fejl. Og så vidt jeg har forstået er flere større javascript applikationer faktisk ikke skrevet i javascript, men derimod skrevet i et højere niveau sprog og derefter compileret til javascript.arne_v (5) skrev:Det synes ikke at være et problem i masser af web apps.
kasperd (12) skrev:Og så vidt jeg har forstået er flere større javascript applikationer faktisk ikke skrevet i javascript, men derimod skrevet i et højere niveau sprog og derefter compileret til javascript.
Der er visse muligheder: GWT, Script#, Dart etc..
Men det er nok trods alt en meget lille del af de JS apps der findes.
Formentligt mindre end 1%.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund