mboost-dp1
low level programmering- den snart tabte kunst?
#50
Hvad vil du da definere grundlæggende C som?
Og jeg har ikke brug for C, så det er stadigvæk spild af tid at lære. Jeg vil hellere lære Haskell, eller Scala, da det faktisk invitere til at lære koncepter der er brugbare i andre sprog. (Specielt Monads er et koncept alle burde lære om!)
Og ligeledes når man kan over 15 forskellige sprog, hvor en 5-10 stykker af dem er C syntaks, så er det tæt på umuligt at huske hvilke sprog der benytter hvilken syntaks.
Modsat giver du det indtryk at du ikke kan kode i særlig meget andet end C.
Hvad vil du da definere grundlæggende C som?
Og jeg har ikke brug for C, så det er stadigvæk spild af tid at lære. Jeg vil hellere lære Haskell, eller Scala, da det faktisk invitere til at lære koncepter der er brugbare i andre sprog. (Specielt Monads er et koncept alle burde lære om!)
Og ligeledes når man kan over 15 forskellige sprog, hvor en 5-10 stykker af dem er C syntaks, så er det tæt på umuligt at huske hvilke sprog der benytter hvilken syntaks.
Modsat giver du det indtryk at du ikke kan kode i særlig meget andet end C.
Windcape (40) skrev:Og hvorfor tror i så konsekvent at CPU'en er relevant for optimeringer?
Det burde være ret åbenlyst at CPU forbrug i en del tilfælde er det der skal optimeres.
Windcape (40) skrev:På mobiler handler performance mere om UI virtualisering, og threading, end det handler om CPU.
Muligt. Jeg ved ikke ret meget om praktisk mobil udvikling.
Men den kendsgerning at der er situationer hvor CPU forbrug ikke er vigtigt udelukker jo ikke at der er andre situationer, hvor det er vigtigt.
En dygtig udvikler skal have en toolbox der kan klare mange forskellig situationer.
Windcape (40) skrev:Og hvorfor skal det så være C/C++? Påstår du virkelig at det er de eneste sprog i verden uden GC?
Der er andre muligheder.
Men antallet af sprog:
- som har pointere og dynamisk allokering af memory
- ikke har GC men kræver eksplicit release af memory
- er rimeligt udbredt
er noget begrænset. C og C++ er ret oplagte.
Windcape (40) skrev:
En optimering er ubegrundet indtil du
a) har et performance problem
b) har profilet din app, og fundet hvor problemet er.
Netop.
Windcape (40) skrev:
Vi kan også antage at der er 1000 ting som giver meget større optimeringer, end et for loop.
Læs evt. det du skrev ovenfor.
Det er ikke bedre at antage at noget ikke er et problem end det er at antage at det er et problem.
CPU brug er ellers ret så irrelevant for størstedelen af alt IT i dag!arne_v (52) skrev:Det burde være ret åbenlyst at CPU forbrug i en del tilfælde er det der skal optimeres.
Hvor finder du CPU optimeringer i ERP, webudvikling, eller mobile? Hvornår har du sidst bedt en SAP konsulent om at optimere CPU forbruget?
Jamen, så må i jo hellere komme i gang med at lære en masse om UI virtualiseringer, ASP.NET cachcing, osv.arne_v (52) skrev:En dygtig udvikler skal have en toolbox der kan klare mange forskellig situationer.
Fordi i kan jo åbenbart kun klare lowlevel C problemer pt.!
#51
Det er et godt spørgsmål. Jeg synes som minimum at man skal være bekendt med de fleste almindelige syntaktiske konstruktioner i sproget (og hvad de betyder (sådan nogenlunde)). Jeg synes man bør vide en smule om structs og brugen af disse. Endelig er det et stort plus hvis man har læst i sin K&R :-)
Hvorfor?
Det er et godt spørgsmål. Jeg synes som minimum at man skal være bekendt med de fleste almindelige syntaktiske konstruktioner i sproget (og hvad de betyder (sådan nogenlunde)). Jeg synes man bør vide en smule om structs og brugen af disse. Endelig er det et stort plus hvis man har læst i sin K&R :-)
Specielt Monads er et koncept alle burde lære om!
Hvorfor?
Windcape (41) skrev:
Og alligevel skriver de altid super grim, og ulæselig kode.
Langtfra altid.
Men man skal forstå C og dets forskellige paradigmer for at kunne læse det.
Windcape (41) skrev:Fordi "hwnd" er super mere læsbart end "windowHandle".
(jeg vil mene at en mere traditionel C stil ville være window_handle fremfor windowHandle)
Det er nok meget et spørgsmål om traditioner. C har en tradition for forholdsvis korte navne.
Da sproget blev opfundet var hardware resourcer meget begrænsede.
Men der er også i nogle tilfælde andre grunde til det.
C89 eksempel:
windcape.h version A
#ifdndef WINDCAPE_H
#define WINDCAPE_H
extern window *handle_window_foo;
extern window *handle_window_bar;
#endif
versus:
windcape.h version B
#ifdndef WINDCAPE_H
#define WINDCAPE_H
extern window *hwndfoo; /* handle to window foo */
extern window *hwndbar; /* handle to window bar */
#endif
Windcape (49) skrev:
Man lærer intet ved at tegne det i hånden. Grafer er en grafisk repræsentation, for at give et hurtigere overblik. Hvordan de er skabt er ligegyldigt.
Hvordan kan det på nogen måde være ligegyldigt hvordan de er skabt?!
Som med de fleste ting, så er glemmer man det hvis man ikke holder det ved lige.onetreehell (55) skrev:#51
Det er et godt spørgsmål. Jeg synes som minimum at man skal være bekendt med de fleste almindelige syntaktiske konstruktioner i sproget (og hvad de betyder (sådan nogenlunde)). Jeg synes man bør vide en smule om structs og brugen af disse. Endelig er det et stort plus hvis man har læst i sin K&R :-)
Hvis du skal vedligeholde viden omkring 15+ sprog, så kan du jo næsten ikke brug tid på andet!
Fordi det gør det utrolig nemt at udvide eksisterende kode med ny funktionalitet. Og har ikke de begræsninger som interfaces har.onetreehell (55) skrev:Hvorfor?
C# har desværre kun monads på compiler-niveau :(
Windcape (54) skrev:Hvor finder du CPU optimeringer i ERP, webudvikling, eller mobile? Hvornår har du sidst bedt en SAP konsulent om at optimere CPU forbruget?
Har du nogensinde set CPU forbruget på det lag af web servere hvor SSL terminerer for et travlt web site?
CPU forbrug er skam også relevant for web løsninger.
CPU forbrug er også relevant for SAP. Hvis du kigger på top resultater for SAP benchmark vil du se at de typisk laves med 256 core configs.
CPU er ikke eneste flaskehals ved hverken web eller SAP, men det er endnu en af de ting som man skal have styr på.
Windcape (54) skrev:Jamen, så må i jo hellere komme i gang med at lære en masse om UI virtualiseringer, ASP.NET cachcing, osv.
Windcape (54) skrev:Fordi i kan jo åbenbart kun klare lowlevel C problemer pt.!
Hm.
Nu går diskussionen vel på at:
- du mener at man kun skal lære high level stuff
- vi mener at man skal lære både high level og low level stuff
Jeg synes ikke at have set nogen argumentere for at man kun skal lære low level stuff.
Og de fleste C programmører lever åbenbart stadigvæk i den tidsalder, sådan rent mentalt!arne_v (56) skrev:Da sproget blev opfundet var hardware resourcer meget begrænsede.
Som? At skulle bruge kommentarer for at forklare hvad en variabel er for, er direkte dårlig kode.arne_v (56) skrev:Men der er også i nogle tilfælde andre grunde til det.
Jeg kan anbefale at læse Uncle Bob's "Clean Code". Det burde næsten være et krav for alle C programmører!
Windcape (48) skrev:Jeg kan allerede grundlæggende C. Men der går typisk Jeg oversatte en rijndael implementation fra C til C# for 5-6 år siden.
Har dog ikke haft brug for at arbejde med C siden.
Det er næppe nok til at forstå C.
Windcape (48) skrev:Og der sandsynligvis 10-20 år før jeg for brug for det igen.
Meget muligt.
Men derfor kunne det jo godt udvide din horisont at studere noget C.
Eller assembler.
Eller Bliss.
Og tror du selv på at det ville hjælpe at implementere en CPU specific algoritme i din ASP.NET business logic ?arne_v (59) skrev:Har du nogensinde set CPU forbruget på det lag af web servere hvor SSL terminerer for et travlt web site?
Og man kan bruge 2 måneder på at lære noget lowlevel man aldrig skal bruge hele sit liv, eller man kan bruge 2 måneder på at lære noget man aktuelt skal bruge i sit arbejde.arne_v (59) skrev:vi mener at man skal lære både high level og low level stuff
I mener at man skal spilde sin tid på at lære ting som stort set er unødvendige for 99% af alt IT arbejde i dag, fordi at i er nostalgiske.
Windcape (62) skrev:Og tror du selv på at det ville hjælpe at implementere en CPU specific algoritme i din ASP.NET business logic ?
Da det ikke er den kode som bruger CPU kraften (muligvis kører koden ikke engang på den server hvor CPU kraften bruges), så vil det jo ikke hjælpe.
Men at der findes kode i systemet som ikke gør systemet CPU bound læser jo ikke problemet med at der er anden kode som gør.
Ja? helt klart.arne_v (63) skrev:Så du ville bruge version A fremfor version B?
Variabler skal være dokumenterede i sig selv. Noget C programmører åbenbart aldrig har lært.
Et hurtigt kig på SO finder f.eks. http://stackoverflow.com/questions/6998602/strtok-...
Der er jo dårligt nok én variabel som ikke er forkortet!
Windcape (65) skrev:Ja? helt klart.
Windcape (65) skrev:Variabler skal være dokumenterede i sig selv. Noget C programmører åbenbart aldrig har lært.
Som sagt er der lidt tradition i C verdenen for korte variable.
Det gør koden lidt svær at læse for dem som ikke er vant til det, men for dem som er vant til det er det helt naturlig.
I et eller andet omfang er forkortede navne en del af C coding convention.
Nå men tilbage til eksemplet. Jeg må tilstå at det var en lille fælde. Det er et problem med version A i C89 (som jeg eksplicit specificerede). C89 garanterer kun at eksterne navne
betragtes som forskellige hvis de første 6 tegn er forskellige. Det gør det meget uheldigt at bruge handle_ først i navne.
Windcape (67) skrev:#66
Det er kun fordi du ønsker at læse det sådan. Men jeg ville heller ikke forventet andet fra dig.
Jeg har ingen præferencer når jeg læser hverken dine eller Arne-v's indlæg. Jeg tolker ikke på dine indlæg. Jeg læser hvad du skriver. Og du har indtil flere gange udtalt dig på en måde der giver udtryk for at du er i besidelse af den endelige sandhed. Det har så dog til tider vist sig at du når det kom til stykket tog noget så grueligt fejl.
Jeg gættede på at der var et trick. Men det er jo igen noget som er meget implementeringsspecifikt.arne_v (68) skrev:Jeg må tilstå at det var en lille fælde.
Sådanne små gimmicks kan tage år og dag at lære.
Har du ikke lært du ikke må lyve Hubert? Vi ved jo godt det ikke passer!Hubert (69) skrev:Jeg har ingen præferencer når jeg læser hverken dine eller Arne-v's indlæg.
Windcape (70) skrev:
Men det er jo igen noget som er meget implementeringsspecifikt.
Kode hvis funktionalitet er implemenations specifik eller undefined er ikke korrekt kode.
Windcape (70) skrev:Sådanne små gimmicks kan tage år og dag at lære.
Ja.
Det tager tid at mestre noget.
Nogle klassiske citater:
:-)
It is what we think we know that keeps us from learning.
I am not young enough to know everything.
To know that one knows what one knows, and to know that one doesn't know what one doesn't know, there lies true wisdom.
When I left him, I reasoned thus with myself: I am wiser than this man, for neither of us appears to know anything great and good; but he fancies he knows something, although he knows nothing; whereas I, as I do not know anything, so I do not fancy I do. In this trifling particular, then, I appear to be wiser than he, because I do not fancy I know what I do not know.
:-)
Windcape (72) skrev:
Spøjst, C er vel ellers et af de sprog hvor der skrives MEST compiler-specifikt kode!
Ja. Mængden af ting der er implementations specifik eller undefined er ret stor i C. Og det er faktisk ikke helt nemt at skrive korrekt kode.
Men jeg har dig lidt mistænkt for at tænke på system specifikke biblioteker. Og de gør naturligvis koden ikke portabel, men de kan sagtens være veldefineret C.
Windcape (49) skrev:Jeg ville nok kalde dig idiot hvis jeg var en af dine studerende.
Man lærer intet ved at tegne det i hånden. Grafer er en grafisk repræsentation, for at give et hurtigere overblik. Hvordan de er skabt er ligegyldigt.
Jeg er uddannet gymnasielærer, min metode er baseret på solid pædagogisk viden på området, samt mine personlige erfaringer med både at gøre det og ikke at gøre det.
Med mindre du har teoretisk og/eller praktisk erfaring med læringspædagogik, der matcher mig, så vil jeg fraråde dig at udtale dig om ting, du ikke har forstand på. Især på sådan en skråsikker måde.
Windcape (49) skrev:arne_v's holdninger er heller ikke den endelige sandhed. Jeg ser ingen grund til at rette ind til højre.
Du har helt ret. Men du udtaler dig til tider utroligt skråsikkert. Som f.eks. ovenstående quote.
Jeg har nok undervist flere i programmering end dig ;-)Spiderboy (75) skrev:Med mindre du har teoretisk og/eller praktisk erfaring med læringspædagogik, der matcher mig, så vil jeg fraråde dig at udtale dig om ting, du ikke har forstand på.
Derudover lærer det at tegne en graf dig intet om at udvælge det rigtige data der skal vises i grafen. Så igen har du fokuseret på det forkerte område, og lært folk noget irrelevant.
Der undervises heller ikke i det samme i dag, som folk blev undervist i for 40 år siden, fordi at vi har bedre værktøjer i dag, og derfor kan fokusere undervisningen på et højere niveau.
Eleverne lærer meget MERE i dag, end for 40 år siden. Fordi at de ikke skal spilde tid på tidskrævende bagateller.
Derudover er det en generalisering at sige at man ikke kan lære ved brug af værktøjer.
Jeg kan sige at man godt kan lære at forstå pointere og memory-management i C#. Så kan i sige at i er uenige. Men i kan ikke sige at det ikke passer.
Så medmindre i også vil have at jeres argument er den enegyldige sandhed, så er det netop rigtigt at konkluderer at det ikke er nødvendigt at lære C og assembler, da man kan lære den fornødne viden på andre måder.
Og hvis i stadigvæk er uenige, så må i jo nyde at lege med hulkort, mens vi andre bygger produkter der bruges af rigtige mennesker, i den rigtige verden -- uden at spilde tid på lowlevel programmering!
Jeg kan sige at man godt kan lære at forstå pointere og memory-management i C#. Så kan i sige at i er uenige. Men i kan ikke sige at det ikke passer.
Så medmindre i også vil have at jeres argument er den enegyldige sandhed, så er det netop rigtigt at konkluderer at det ikke er nødvendigt at lære C og assembler, da man kan lære den fornødne viden på andre måder.
Og hvis i stadigvæk er uenige, så må i jo nyde at lege med hulkort, mens vi andre bygger produkter der bruges af rigtige mennesker, i den rigtige verden -- uden at spilde tid på lowlevel programmering!
Windcape (76) skrev:Jeg har nok undervist flere i programmering end dig ;-)
Har du nogen pædagogisk baggrund for det, eller er du bare selvlært underviser?
Windcape (76) skrev:Derudover lærer det at tegne en graf dig intet om at udvælge det rigtige data der skal vises i grafen. Så igen har du fokuseret på det forkerte område, og lært folk noget irrelevant.
Absolut ikke. De lærer især hvordan en graf egentlig fungerer og hvordan man aflæser en graf. Det er absolut ikke indlysende for de fleste 1. g'ere, selv om de har haft det meget i folkeskolen.
Windcape (76) skrev:Der undervises heller ikke i det samme i dag, som folk blev undervist i for 40 år siden, fordi at vi har bedre værktøjer i dag, og derfor kan fokusere undervisningen på et højere niveau.
Samme her. F.eks. bruger mine elever computer til dataopsamling i fysikøvelserne.
Windcape (76) skrev:Eleverne lærer meget MERE i dag, end for 40 år siden. Fordi at de ikke skal spilde tid på tidskrævende bagateller.
At forstå en graf er så absolut ikke en bagatel.
Nej, selvfølgelig ikke.Spiderboy (78) skrev:Har du nogen pædagogisk baggrund for det, eller er du bare selvlært underviser?
Jeg lærte det i folkeskolen. Men det har jo nok noget med alderen at gøre.Spiderboy (78) skrev:Absolut ikke. De lærer især hvordan en graf egentlig fungerer og hvordan man aflæser en graf. Det er absolut ikke indlysende for de fleste 1. g'ere, selv om de har haft det meget i folkeskolen.
Desuden så er grafer ikke egnet til dataaflæsning. De er egnet til at give et nemt overbliks, som man så kan drage hurtige konklusioner ud fra.
Skal du så ikke stå og råbe af dem, at papir&blyant er så meget bedre?Spiderboy (78) skrev:Samme her. F.eks. bruger mine elever computer til dataopsamling i fysikøvelserne.
At forstå at en graf er så manipulerbar som noget kan blive, er ikke en bagatel. At tegne den selv hjælper dig ikke til den forståelse.Spiderboy (78) skrev:At forstå en graf er så absolut ikke en bagatel.
Windcape (60) skrev:arne_v (56) skrev:Da sproget blev opfundet var hardware resourcer meget begrænsede.
Og de fleste C programmører lever åbenbart stadigvæk i den tidsalder, sådan rent mentalt!
Jamen så behøver vi jo heller ikke at forbedre fx bilmotorer, for vi har jo stadig masser af olie?
Og vi behøver heller ikke forbedrer vindmøller?
Windcape (80) skrev:Nej, selvfølgelig ikke.
Med andre ord, du er helt clueless om hvordan man lærer mest effektivt med undtagen af hvad du har lært ved lidt trial & error?
Windcape (80) skrev:Jeg lærte det i folkeskolen. Men det har jo nok noget med alderen at gøre.
Ikke alle er som dig. Der findes mennesker som ikke synes det er så nemt.
Windcape (80) skrev:Desuden så er grafer ikke egnet til dataaflæsning. De er egnet til at give et nemt overbliks, som man så kan drage hurtige konklusioner ud fra.
Du har helt ret, men det er ikke formålet her. Formålet er at forstå hvad en graf overhovedet er for noget.
Windcape (80) skrev:Skal du så ikke stå og råbe af dem, at papir&blyant er så meget bedre?
Lad nu være med at blive useriøs.
De skal lave det i hånden én gang - de resterende 3 år må de gerne lave dem elektronisk.
Windcape (80) skrev:At forstå at en graf er så manipulerbar som noget kan blive, er ikke en bagatel. At tegne den selv hjælper dig ikke til den forståelse.
At forstå den er manipulerbar er ikke en bagatel, nej. Men det lærer de senere.
Først bliver de nødt til at forstå hvad en graf er.
Windcape (77) skrev:
Derudover er det en generalisering at sige at man ikke kan lære ved brug af værktøjer.
Jeg kan sige at man godt kan lære at forstå pointere og memory-management i C#. Så kan i sige at i er uenige. Men i kan ikke sige at det ikke passer.
Værktøjer er helt fine.
Men hvis man skal lære hvordan man programmerer med manuel deallokering af dynamisk allokeret memory, så ville jeg vælge et værktøj der passer til opgaven. C og C++ understøtter den opgave perfekt. C# gør ikke.
Års praktisk erfaring med tutoring af andre studerende, er noget jeg vil betragte som bedre end et kursus på lærerseminariet.Spiderboy (83) skrev:Med andre ord, du er helt clueless om hvordan man lærer mest effektivt med undtagen af hvad du har lært ved lidt trial & error?
En nyuddannet lærer kunne nemt være mere clueless omkring undervisning af studerende end mig.
Hvordan ved DU hvordan dine elever lærer bedst, når du ikke har arbejdet sammen med dem, og undervist dem i de ting de specifikt har problemer med?
Men da du alligevel aldrig skal udføre sådan en opgave i C#, er den derfor irrelevant.arne_v (84) skrev:Men hvis man skal lære hvordan man programmerer med manuel deallokering af dynamisk allokeret memory, så ville jeg vælge et værktøj der passer til opgaven. C og C++ understøtter den opgave perfekt. C# gør ikke.
Altså kan du passende lærer det, hvis du skal udvikle noget i C eller C++. Men hvis du ikke koder i C/C++, er der ingen grund til at lære det, da det ikke er relevant for dit arbejdsområde.
Windcape (77) skrev:Og hvis i stadigvæk er uenige, så må i jo nyde at lege med hulkort, mens vi andre bygger produkter der bruges af rigtige mennesker, i den rigtige verden -- uden at spilde tid på lowlevel programmering!
Du har vist slet ikke fattet pointen i det vi skriver.
Pointen er ikke at man skal skrive i low level sprog.
Pointen er at man bliver bedre til at skrive i high level sprog, hvis man forstår low level sprog.
NB: Og C er som nævnt tidligere nævnt stadig ret udbredt.
Og jeg er stadigvæk uenig.arne_v (87) skrev:Pointen er at man bliver bedre til at skrive i high level sprog, hvis man forstår low level sprog.
De ting du lærer i low-level sprog er kun nødvendige for at arbejde med low-level sprog. Altså er de hamrende ligegyldige hvis man arbejder med high-level sprog!
I har stadigvæk ikke kommet med et eneste eksempel på et real-life scenario hvor noget man kun kunne lære i et low-level sprog, er nødvendigt for at skrive high-level kode. (Sikkert fordi sådan en problemstilling slet ikke findes!)
Windcape (86) skrev:Men da du alligevel aldrig skal udføre sådan en opgave i C#, er den derfor irrelevant.
Hvis man ikke er interesseret i hvad der foregår under motorhjelmen og er villig til at overlade en pæn del af de interessante design beslutninger til folk med en dybere forståelse, så er det ret irrelevant.
Men det er dæleme et lavt ambitions niveau.
Jeg kunne også synes at det er et lavt ambitions niveau ikke at ville lære X og Y teknologier/paradigmer.arne_v (90) skrev:Men det er dæleme et lavt ambitions niveau.
Der er viden nok i verden til at holde en beskæfiget med at lære noget nyt indtil man dør, så hvorfor spilde tiden på at lære noget man ikke har brug for?
"dybere forståelse" er ekstremt subjektivt. Det er en "dybere forståelse" inden for et meget lille område. Det giver dig ikke "dybere forståelse" for alle de andre områder.
Windcape (85) skrev:Hvordan ved DU hvordan dine elever lærer bedst, når du ikke har arbejdet sammen med dem, og undervist dem i de ting de specifikt har problemer med?
Pas på med antagelserne.
Udover mine førnævnte kompetencer har jeg også 5 års erfaring i flere lektiecaféer, som jo er meget en-til-en coaching om specifikke problemer.
Windcape (88) skrev:Hvis jeg blev stillet for sådan en opgave, ville jeg løse den på computeren, printe det, og så tegne det op i hånden på et andet stykke papir.
Undrer mig ikke, for du har slet ikke forstået formålet med opgaven.
Hvis du vidste noget om pædagogik, ville du vide, at læring er meget procesorienteret. Dvs. du lærer af at lave opgaven. Det færdige produkt er mindre vigtigt - i læringssammenhæng.
Windcape (89) skrev:De ting du lærer i low-level sprog er kun nødvendige for at arbejde med low-level sprog. Altså er de hamrende ligegyldige hvis man arbejder med high-level sprog!
En gang til for prins Knud:
Når du lærer et low-level sprog, lærer du ikke kun et low-level sprog, men lærer også indirekte et mængde andre kompetencer, som kan være nyttige i andre sammenhænge.
Derfor kan old-school lærdom godt supplere dig som high-level udvikler.
Windcape (89) skrev:I har stadigvæk ikke kommet med et eneste eksempel på et real-life scenario hvor noget man kun kunne lære i et low-level sprog, er nødvendigt for at skrive high-level kode. (Sikkert fordi sådan en problemstilling slet ikke findes!)
Det er fordi at ingen har påstået det. Læs hvad vi skriver.
Ingen antagelser. Det var et spørgsmål.Spiderboy (92) skrev:Pas på med antagelserne.
Udover mine førnævnte kompetencer har jeg også 5 års erfaring i flere lektiecaféer, som jo er meget en-til-en coaching om specifikke problemer.
Ikke for alle. Faktisk er det for mange vigtigt at lave noget færdigt, som de kan forholde sig til, frem for at lave små tasks uden nogen sammenhæng i. Specielt inden for IT!Spiderboy (92) skrev:Hvis du vidste noget om pædagogik, ville du vide, at læring er meget procesorienteret. Dvs. du lærer af at lave opgaven. Det færdige produkt er mindre vigtigt - i læringssammenhæng.
Bevis at disse kompetancer, som kan være nyttige i andre sammenhænge, ikke kan opnåes i andre sprog!Spiderboy (92) skrev:Når du lærer et low-level sprog, lærer du ikke kun et low-level sprog, men lærer også indirekte et mængde andre kompetencer, som kan være nyttige i andre sammenhænge.
@Windcape - Nu har du undermineret dig selv.
Det kan godt være du kender mange teknologier og facts derom, men når du så samtidigt påstår at java er lidt cross-platform, viser du jo at din påståelighed gør din hullede viden total ubrugelig.
Når du så konkluderer at koden fra #15, er for at lave koden thread-safe viser jo at din evene til at resonere ikke eksisterende.
At du så antyder, du ser dig selv så vidende og begavet som som arne_v viser sin selvopfattelse er til at lukke op og skide i.
Du bliver aldrig en god programmør.
Du bliver den der irrerterende know-it-all kolega, der ikke rigtigt kan skabe resultater, fordi logiken ikke hænger sammen, og derfor i stedet vil prøve at hævde sig selv, ved at kritisere andres arbjde på det grundlag, at du ved bedere om et eller andet irellevant.
Du kommer til at sejle fra arbejdsplads til arbejdsplad.
Sluk PC'en, gå en tur i skoven, stik en finger i jorden og find ud hvad du egentlig er god til.
Men vigtigst af alt: Stop med at sprede din påståelige, fiktionelle non-logik her på newz.
Det kan godt være du kender mange teknologier og facts derom, men når du så samtidigt påstår at java er lidt cross-platform, viser du jo at din påståelighed gør din hullede viden total ubrugelig.
Når du så konkluderer at koden fra #15, er for at lave koden thread-safe viser jo at din evene til at resonere ikke eksisterende.
At du så antyder, du ser dig selv så vidende og begavet som som arne_v viser sin selvopfattelse er til at lukke op og skide i.
Du bliver aldrig en god programmør.
Du bliver den der irrerterende know-it-all kolega, der ikke rigtigt kan skabe resultater, fordi logiken ikke hænger sammen, og derfor i stedet vil prøve at hævde sig selv, ved at kritisere andres arbjde på det grundlag, at du ved bedere om et eller andet irellevant.
Du kommer til at sejle fra arbejdsplads til arbejdsplad.
Sluk PC'en, gå en tur i skoven, stik en finger i jorden og find ud hvad du egentlig er god til.
Men vigtigst af alt: Stop med at sprede din påståelige, fiktionelle non-logik her på newz.
Windcape (93) skrev:Ingen antagelser. Det var et spørgsmål.
Du skrev "Hvordan ved DU hvordan dine elever lærer bedst, når du ikke har arbejdet sammen med dem, og undervist dem i de ting de specifikt har problemer med?". Men fred være med det. :-)
Windcape (93) skrev:Ikke for alle. Faktisk er det for mange vigtigt at lave noget færdigt, som de kan forholde sig til, frem for at lave små tasks uden nogen sammenhæng i. Specielt inden for IT!
Der er selvfølgelig mange fagdidaktiske særtegn, men at læring er temmelig procesorienteret er ret universelt.
Men du har ret i, at nogle går meget op i at få et ordentligt produkt. Det får de også rig lejlighed til senere, men man skal lige kravle før man kan gå. Du lærte nok heller ikke alt hvad du ved om programmering på én gang, men løbende blev bedre og dermed fik et bedre produkt.
Windcape (93) skrev:Bevis at disse kompetancer, som kan være nyttige i andre sammenhænge, ikke kan opnåes i andre sprog!
Det har jeg heller ikke påstået. Du har lidt med at læse min påstand på en lidt anden måde end jeg har skrevet den.
Lad os for eksempel tage generic collections i C#. Den kan man læse om på MSDN og tusind andre steder og blive god til at bruge dem ved at bruge dem.
Men hvis du - blot en enkelt gang - har prøvet manuelt at skulle implementere forskellige typer linked lists i C får du en indsigt i collections, som er svær at få ved blot at anvende dem i C#. Du forstår pludselig hvorfor algoritmekompleksiteten er som den er ved de forskellige operationer på de forskellige typer collections.
Jeg siger ikke, at du ikke kan undvære alt dette. Blot at have nede og pille under motorhjelmen kan give dig nogle indsigter der ikke er lettilgængelige ved bejtening af bilen eller at læse i manualen.
Der er også andre sprog som ikke har generics. Hvad er pointen? Derudover så er generics i Java bare boxing, hvor generics i C# er rigtige generics.Spiderboy (95) skrev:Men hvis du - blot en enkelt gang - har prøvet manuelt at skulle implementere forskellige typer linked lists i C får du en indsigt i collections
C vil jo nærmere gøre det modsatte, ikke give nogen indsigt i generics over hovedet. C (eller måske C++) er nok det værst mulige sprog du kan bruge til at demonsterer algoritmer med!
Nonsense. Det kan du ligeså godt lære i C# som enhvert andet sprog.Spiderboy (95) skrev:Du forstår pludselig hvorfor algoritmekompleksiteten er som den er ved de forskellige operationer på de forskellige typer collections.
Og fordelen ved at lære det i f.eks. C# er at du kan fokusere på algoritmen, og ikke spilde din tid med sprogmæssige finurligheder, og compileringsfejl som ikke er læsbare for mennesker.
Det er altid bedre et vælge et mindre nemmere tilgængeligt sprog til at demonsterer teoretiske koncepter i. Det gør det nemmere for de studerende at forstå hvad der faktisk foregår, frem for at spilde tid på problemer med sproget/compileren.
Point taken, eksemplet var ikke så godt, da man jo blot kan implementere en linked list i C#. Men det ændrer ikke meget ved pointen: man kan få nogle indsigter når man virkelig får olie på fingrene, som er svært at få på andre måder.
Anerkender du overhovedet, at når du træner kompetence A, er det muligt at udover lære kompetence A også lærer kompetence B, C og D som en sideeffekt?
Anerkender du overhovedet, at når du træner kompetence A, er det muligt at udover lære kompetence A også lærer kompetence B, C og D som en sideeffekt?
Spiderboy (98) skrev:Point taken, eksemplet var ikke så godt, da man jo blot kan implementere en linked list i C#. Men det ændrer ikke meget ved pointen: man kan få nogle indsigter når man virkelig får olie på fingrene, som er svært at få på andre måder.
Det var en umulig opgave: Bevis man ikke kan ...
Selvfølgelig gør jeg det.Spiderboy (98) skrev:Anerkender du overhovedet, at når du træner kompetence A, er det muligt at udover lære kompetence A også lærer kompetence B, C og D som en sideeffekt?
Jeg har lært det meste jeg ved om andre paradigmer i sprog der ikke direkte tilhører disse paradigmer.
Jeg men bare ikke at det er et direkt incitament til at skulle fokusere på kompetance D, fordi man arbejder med kompetance A.
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