torbjørn marø Skrevet 17. oktober 2011 Del Skrevet 17. oktober 2011 Det er bare nisje-problemer som er enklere med dynamisk typing, du kan godt nevne eksempler på dette, men faktum er at dynamisk typing er nyttig i helt spesielle tilfeller, og derfor mener jeg det er en dårlig idé at det er obligatorisk i et språk. Det må du gjerne påstå, men sier du noe er et faktum bør du dokumentere det. Jeg opplever det anderledes. Dynamisk typing gripper inn i måten du tenke på når du løser et hvilket som helst problem. Igjen: det er ingen ting du kan gjøre i et dynamisk språk som du ikke kan gjøre i et statisk, men dynamiske språk får deg til å gjøre det anderledes. For dem som ikke vet det så er jeg altså først og fremst en C#-utvikler (siden 2001/2002). Jeg har jobbet med dynamiske språk i 3 år eller noe sånt, men C# er fortsatt det jeg bruker til daglig. Så jeg vet selvsagt hva du (GeirGrusom) snakker om. Du har derimot sagt (mener jeg å huske) at du ikke er villig til å forsøke et dynamisk språk før du har blitt overbevist. Jeg hevder utviklere bør beherske alle sentrale programmeringsparadigmer, hvor dynamisk typing er en av de mer sentrale. I alle andre tilfeller vil statisk typing medføre at parseren kan plukke opp flere programmeringsfeil, Det er overraskende hvor sjelden man gjør slike feil. Spesielt når man likevel driver testdreven utvikling - som jeg må innrømme omtrent er et møst i dynamiske språk. Man tar da på seg noen av kompilatorens oppgaver, og får til gjengjeld en større frihet. Men det er interessant i denne sammenhengen om dette har betydning for valg av språk for en helt fersk utvikler. Jeg heller mot at et dynamisk språk gir den beste og raskeste feedbacken på det man gjør, men det kan hende et kompilatorsteg kan hjelpe. Merker bare at nybegynnere ofte blir sittende i timevis å forsøke å blidgjøre kompilatoren før de får sitt første program til å kjøre... Og feilmeldingene er stort sett ikke særlig hjelpsomme for n00bene heller. compileren kan lage mer effektiv kode, Ja, kompilatoren kan lage mer effektiv kode. Men det kan være mere tungvindt å kode det man skal gjøre. Så det blir en avveiing hvorvidt du mener utvikleren skal slite eller du vil at runtimen skal gjøre jobben for deg. Eksplosjonen av dynamiske språk de siste 10-15 årene skyldes hovedsakelig at maskinene nå er så kraftige at prisen man betaler for dynamisk typing stort sett ikke har betydning. Men innen noen nisjer har det selvsagt det. og parseren i IDE-et kan hjelpe deg mye mer ved å vise dokumentasjon mens du skriver. Det er nesten morsomt hvor avhengig vi er av intellisense i C#. Flertallet av utviklere i verden klarer seg fint uten. Selv kodet jeg C# i en helt enkel teksteditor i 2 år før jeg begynte med Visual Studio (anbefales ikke, men det gjorde at jeg ble godt kjent med rammeverket). I Ruby, Python og lignende erstattes dette bl.a. av glimrende tilgang til dokumentasjon i den interaktive REPLen, igjen gjort tilgjengelig takket være språkenes dynamiske egenskaper. IDE'er for dynamsiske språk kan også integrere dokumentasjon på samme måte som Visual Studio. For en nybegynner er det også ganske viktig å være klar over datatyper. Skal du jobbe med noe annet enn webutvikling, vil du dulte borti språk hvor dette er et ganske sentralt tema. Jepp. Og nå må vi huske på å ikke blande statisk typing med sterk typing. 1 Lenke til kommentar
GeirGrusom Skrevet 17. oktober 2011 Del Skrevet 17. oktober 2011 For dem som ikke vet det så er jeg altså først og fremst en C#-utvikler (siden 2001/2002). Jeg har jobbet med dynamiske språk i 3 år eller noe sånt, men C# er fortsatt det jeg bruker til daglig. Så jeg vet selvsagt hva du (GeirGrusom) snakker om. Du har derimot sagt (mener jeg å huske) at du ikke er villig til å forsøke et dynamisk språk før du har blitt overbevist. Jeg hevder utviklere bør beherske alle sentrale programmeringsparadigmer, hvor dynamisk typing er en av de mer sentrale. Har jeg hevdet det noengang? Jeg har benyttet både Python og PHP så det ville jo blitt litt teit. Du kan godt slutte å antyde at det er mine evner som programmerer som er problemet til at jeg ikke ser ting fra din side også takk. Lenke til kommentar
torbjørn marø Skrevet 17. oktober 2011 Del Skrevet 17. oktober 2011 (endret) For dem som ikke vet det så er jeg altså først og fremst en C#-utvikler (siden 2001/2002). Jeg har jobbet med dynamiske språk i 3 år eller noe sånt, men C# er fortsatt det jeg bruker til daglig. Så jeg vet selvsagt hva du (GeirGrusom) snakker om. Du har derimot sagt (mener jeg å huske) at du ikke er villig til å forsøke et dynamisk språk før du har blitt overbevist. Jeg hevder utviklere bør beherske alle sentrale programmeringsparadigmer, hvor dynamisk typing er en av de mer sentrale. Har jeg hevdet det noengang? Jeg har benyttet både Python og PHP så det ville jo blitt litt teit. Du kan godt slutte å antyde at det er mine evner som programmerer som er problemet til at jeg ikke ser ting fra din side også takk. Jeg beklager, var ikke meningen å antyde noe om dine evner, kun om din vilje til å forsøke å se på noe anderledes (og godt mulig jeg husker feil der også, da beklager jeg igjen). Men jeg mener like fullt at utviklere bør beherske å gjøre større prosjekter i dynamiske språk - har hevdet dette før. Det gjør ikke deg mindre verdt enn f.eks. alle dem som kun bruker dynamiske språk. Flere teknikker og mestring av flere vertøy vil gjøre deg bedre på et generelt grunnlag! Endret 17. oktober 2011 av torbjørn marø Lenke til kommentar
GeirGrusom Skrevet 17. oktober 2011 Del Skrevet 17. oktober 2011 Men jeg mener like fullt at utviklere bør beherske å gjøre større prosjekter i dynamiske språk - har hevdet dette før. Det gjør ikke deg mindre verdt enn f.eks. alle dem som kun bruker dynamiske språk. Flere teknikker og mestring av flere vertøy vil gjøre deg bedre på et generelt grunnlag! Sant nok, men det er ikke egentlig det vi diskuterer Og som nevnt før finnes det språk med begge deler. For min del, synes jeg at selv dynamiske språk bør ha muligheten for statisk deklarering selv om type systemet er dynamisk av natur, nettopp fordi jeg mener at dynamisk typing har såpass få unike bruksområder, men har såpass mange tekniske ulemper at et språk burde minimum være statisk typet. Det ville vært morsomt dersom CPython implementerte valgfri statisk typing, og se hva som ville dominert. Lenke til kommentar
torbjørn marø Skrevet 17. oktober 2011 Del Skrevet 17. oktober 2011 (endret) Og som nevnt før finnes det språk med begge deler. Fantom er et eksempel på et slikt språk, og det språket er ganske interessant. Der er det løst slik at om man aksesserer en metode eller et felt gjennom dot-notasjon (obj.field) så gjøres det en type check, men man har også en dynamisk invocator (obj->field) som ikke foretar en type check. (Dette er ikke det samme som dynamic i C#, men kan løses med dynamic + DynamicObject) Men jeg er ikke med deg på at alle språk burde ha dette. Personlig har jeg i alle fall aldri savnet statisk typing i språk som Ruby, Erlang eller Clojure. I de to sistnevnte er evnen til å enkelt koke sammen ad-hoc typer i form av lister og tupler som mixer innhold essensielt. Folk må velge de språkene de mener er best egnet til å løse de oppgavene de har. Men man bør (sier det en gang til) kjenne hvilke valgmuligheter man har. Endret 17. oktober 2011 av torbjørn marø Lenke til kommentar
GeirGrusom Skrevet 17. oktober 2011 Del Skrevet 17. oktober 2011 Brukte dynamisk typing til noe i BASIC kompilatoren. Når den skulle forkorte uttrykk med konstanter, så brukte jeg dynamic for å la .NET run-timen bestemme resultatet og regne ting sammen. Dette gjorde at jeg slapp unna en ganske omfattende jobb med dette, det var bare å bruke ExpressionVisitor til å regne om alle binæroperasjoner eller monooperator på konstanter eller uttrykk som evaluerer til konstanter. Uten dynamic hadde det blitt en ganske stor jobb. Men for meg er dette unntakstilfeller som ikke burde være en grunn til å velge et språk for en nybegynner. Datatyper er ekstremt viktig del av programmering, enten du driver med dynamiske språk eller ikke, og min mening er at å lære dette godt er ganske viktig. Lenke til kommentar
Ikon Skrevet 17. oktober 2011 Del Skrevet 17. oktober 2011 Jeg ville absolutt ikke anbefale å begynne å lære deg Java(C# har jeg aldri sett noe på) hvis du skal lage en spillmotor. Grunnen til det er hvor mye som gjøres for deg når du bruker Java, som du aldri ser. Java er nok ikke en versting her, men det er ille nok. Hvis du bare er ute etter å lage små enkle spill, så er det np å bruke Java. Men jeg siktet til spillprogrammering, og da mener jeg spillmotor programmering. Ikke at du nødvendigvis skal lage en motor, det er for stor jobb, men å forstå hvordan en skikkelig spillmotor fungerer. Da må du rett og slett ned i C++. Hvis du har som mål å lage en mod, så trenger du selvfølgelig ikke å vite hvordan en spillmotor fungerer, men skal du lage et spill fra bunn, så er det temmelig nytting å forstå hvorfor du trenger å ha en egen memory manager, eller en resourcemanager, eller hvordan et quadtree fungerer, når du skal bruke shadere og når du ikke skal, shadertrees, memory padding, hva en kompiler gjør med koden din, osv.osv.osv.osv.osv..... Annet enn at du må krangle med at C++ er temmelig elementært når det kommer til typesystemer, reflection, metainformasjon, låsing og multi-threading, så må du fortsatt gjøre den samme jobben. Mange ting er derimot vesentlig enklere å gjøre. Du kan fint se på compiler output både fra Java og C# compileren, samt JIT compileren dersom du skulle ønske det. Du må fortsatt skrive resource manager Du må fortsatt skrive vektor, matrise og kvaternion klasser Du må fortsatt skrive octree Du må fortsatt skrive collision detection Du må fortsatt skrive shadere Du må fortsatt implementere scriptstøtte Du må fortsatt implementere støtte for forskjellige ressurser Jeg mener så absolutt ikke at Java/C# ikke kan brukes til å lage spillmotorer, jeg mener at hvis du skal lære deg å lage/bruke en spillmotor er det nyttig å se det fra C++ sin side. Nå vet jeg ikke hvor lav nivå det er mulig å komme med Java, da jeg har aldri brukt det som et lavnivå språk. Men jeg vil nå påstå at hvis du bruker Java til lavnivå programmering så er jo hele poenget med Java borte. Da kan man liksågodt bruke C++ som språk. Men, jeg er enig i at C++ har en masse problemer og derav et av de største: At man må gjøre alt selv! Dog, det har kommet flere og flere apier som gjør hverdagen enklere, men så fremt du ikke skal lage et spill fra bunn av, er jeg enig i at det er lite å bruke C++ til annet enn å lære å programmere. Jeg mener at hvis man lærer C++ først, setter man utrolig pris på høynivå språk og sammtidig har du fått en forståelse for hva som faktisk foregår(Så fremt du har fått en god innførelse i C++ da...) Lenke til kommentar
torbjørn marø Skrevet 17. oktober 2011 Del Skrevet 17. oktober 2011 Datatyper er ekstremt viktig del av programmering, enten du driver med dynamiske språk eller ikke, og min mening er at å lære dette godt er ganske viktig. Det er jeg enig i. Og det kan godt være du har rett i at man kan ha nytte av å introduseres for programmering vha. et språk som er strengt og eksplisitt på typer. Eller kanskje man burde brukt et språk som Haskell - de utviklærne der er veldig stolte av typesystemet sitt. Men det finnes flere måter å se på typesystemer på. Ducktyping er også et interessant og nyttig type-konsept. Selv er jeg mer tilhenger av å lære programmering slik man gjør det på MIT / via SICP: Begynn med så få og enkle byggestener som mulig, og bygg på ettehvert. Til dette er de dynamiske språkene bedre egnet. Lenke til kommentar
Johan Skrevet 18. oktober 2011 Del Skrevet 18. oktober 2011 Dynamisk typing har en del fordeler, spesielt i dynamiske problemer. Dessverre er det slik at ikke alle typekorrekte programmer kan bevises statisk, og her snakker vi ikke bare om sære teknikaliteter. For eksempel kan ikk apply(), fra lisp-verdenen, types statisk. I de tilfellene hvor det er klønete eller motstridene å bruke typesystemet er dynamisk typing som regel greiere å drive med. Skal en drive med macros, så må man nesten ha dynamisk typing. Typed Racket bruker visst statisk typing og har en form for makroer, men bare "hygeniske" sådan. Det at typesjekkingen er statisk eller dynamisk har ikke nødvendigvis noe å si om hvordan datatyper virker generelt. Se på common lisp, det er dynamisk typet, men det har også et veldig rikt typesystem. Hvis man erklærer typer på ting kan også kompilatoren produsere svært rask kode. Ofte kan man i common lisp slå "selv C" i hastighet, typisk via kompilerte klosurer, og annet runtime-generert snacks. 1 Lenke til kommentar
torbjørn marø Skrevet 18. oktober 2011 Del Skrevet 18. oktober 2011 Det at typesjekkingen er statisk eller dynamisk har ikke nødvendigvis noe å si om hvordan datatyper virker generelt. Se på common lisp, det er dynamisk typet, men det har også et veldig rikt typesystem. Hvis man erklærer typer på ting kan også kompilatoren produsere svært rask kode. Ofte kan man i common lisp slå "selv C" i hastighet, typisk via kompilerte klosurer, og annet runtime-generert snacks. Jepp, slik er det i Clojure også. Man utvikler uten å deklarere typer, men for performance kan man i ettertid spesifisere typer et par sentrale steder, og koden går potensielt mange ganger raskere. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå