mboost-dp1
low level programmering- den snart tabte kunst?
Windcape (97) skrev: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.
C er faktisk et meget lille sprog, og det er sikkert nemmere at lære end java/C#. Det kan dog være nemmere at lave fejl pga. den frie pointeraritmetik o. lign.
Seriøst, K&R er kun på 272 sider og det er det eneste du kommer til at bruge om sproget.
Windcape (100) skrev:Selvfølgelig gør jeg det.
Okay. Det har ikke fremstået ret tydeligt i dine indlæg.
Windcape (100) skrev:Jeg men bare ikke at det er et direkt incitament til at skulle fokusere på kompetance D, fordi man arbejder med kompetance A.
Nogle kompetencer er nemmere at lære ifm. visse aktiviteter.
Nogle kompetencer er nærmest umuligt at lære direkte, men skal læres indirekte.
Jeg er uenig. Og da jeg har tutored folk der først har lært enten C eller Java, og så C#, kan jeg med erfaring sige at folk generelt mener at C# er meget nemmere at lære fordi:onetreehell (101) skrev:C er faktisk et meget lille sprog, og det er sikkert nemmere at lære end java/C#.
- Bedre fejlmeddelser
- Bedre udviklingsværktøjer
Compileringsfejl i C og C++ er simpelthen uforståelige.
Den dag jeg for brug for at arbejde C, skal jeg nok købe den.onetreehell (101) skrev:Seriøst, K&R er kun på 272 sider og det er det eneste du kommer til at bruge om sproget.
Pt. har jeg Fowler's Domain Specific Languages, som jeg skal have gjort færdig. (Efter en mindre sommerferie pause med Conn Iggulden's serie om Djengis Khan).
Windcape (105) skrev:Det afhænger af hvem man er.
Hvordan træner du kompetencen "løse et problem med divide-and-conquer fremgangsmåden" uden at programmere? :-)
Windcape (105) skrev:Programmering falder mig mere naturligt end de fleste andre. Det ligger vel i generne *shrug*
Også jeg, men ikke synderligt relevant for debatten.
Windcape (91) skrev:"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.
Disse her ting er jo netop noget som alt inden for programmering bygger ovenpå.
Dermed giver de en dybere forståelse for (næsten) alt inden for programmering.
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!
De her ting er ikke kun nødvendige for low level sprog - der er præcis ligeså nødvendige i high level sprog.
De er bare mere synlige i low level sprog.
Og assembler bygger oven på transistorer, og transistorer bygger oven på hvordan silicium har ledeevne, osv.arne_v (108) skrev:Disse her ting er jo netop noget som alt inden for programmering bygger ovenpå.
På ingen måde. Og det er en påstand du på ingen måde bevise.arne_v (108) skrev:Dermed giver de en dybere forståelse for (næsten) alt inden for programmering.
Nej, overhovedet ikke. Hvis de var nødvendige, så ville folk jo netop have kendskab til dem. Det faktum at folk ikke har kendskab til dem, betyder at de ikke er nødvendige.arne_v (109) skrev:De her ting er ikke kun nødvendige for low level sprog - der er præcis ligeså nødvendige i high level sprog.
Ellers må du jo komme med et modbevis. Hvilket sandsynligvis ikke kan lade sig gøre.
Fordi de kun er nødvendige at arbejde med i low-level sprog!arne_v (109) skrev:De er bare mere synlige i low level sprog.
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!)
For ethvert program der ligger lidt over hello world niveauet vil det være nødvendigt med noget low level forståelse af en eller anden art for at kunne lave et fornuftigt design ved andet end tilfældighed.
Windcape (111) skrev:Nej, overhovedet ikke. Hvis de var nødvendige, så ville folk jo netop have kendskab til dem. Det faktum at folk ikke har kendskab til dem, betyder at de ikke er nødvendige.
Enten har de kendskab til det eller så outputter de bare noget kode af tilfældig kvalitet.
Og hvis de har kendskab til det, skriver de elendig kode.arne_v (114) skrev:Enten har de kendskab til det eller så outputter de bare noget kode af tilfældig kvalitet.
C programmører skriver altid elendig Java eller C# kode. Det er ligeså meget et faktum som det du siger nu.
Og kvaliteten af kode handler mere om forståelse for det sprog du skriver den i, end noget som helst andet.
Faktisk vil jeg sige der er større chance for at folk skriver elendig kode, hvis de har lært C.
Windcape (115) skrev:
Og hvis de har kendskab til det, skriver de elendig kode.
C programmører skriver altid elendig Java eller C# kode. Det er ligeså meget et faktum som det du siger nu.
Du har stadig ikke fattet pointen.
Prøv og læs #87 en gang mere.
Vi snakker stadig om Java/C# programmører og hvorvidt de bør lære low level ring eller ej. Vi snakker ikke om C programmører - de er nødt til det (ihvertfald hvis man betragter C som et low level sprog - og det gør man normalt idag).
Min erfaring siger mig det modsatte. Næsten samtlige ting du kan lære ved low-level programmring er nemlig direkte forkerte i high-level programmering.arne_v (119) skrev:Baseret på erfaring ikke på et bevis.
Folk er bedre til at træffe rigtige design-mæssige beslutninger hvis de har lært at kode ordenlig high-level. Så de forstår og kan udnytte den teknbologi de arbejder med.
Hvis det ikke kan bevises, så har jeg i så fald, ligeså meget ret som du har.
At du arbejder med mennesker som af underlige grunde skal lære C før de kan finde ud af at kode Java, betyder jo ikke at resten af verden arbejder med de samme slags mennesker.
De mennesker jeg arbejder med, snakker med, eller hjælper/underviser i forskellige emner inden for softwareudvikling, deler ihvertfald ikke din overbevisning.
Konkret eksempel: En folk ingeniører med C baggrund, havde svært ved at forstå delegates i C#. Mens en datamatiker med baggrund i Java, ikke havde noget problem.
Og jeg er sikker på at en webdesigner med erfaring i JavaScript, ville have endnu nemmere ved at forstå det!
Jeg kan give konkrete eksempler. Kan i?
At du arbejder med mennesker som af underlige grunde skal lære C før de kan finde ud af at kode Java, betyder jo ikke at resten af verden arbejder med de samme slags mennesker.
De mennesker jeg arbejder med, snakker med, eller hjælper/underviser i forskellige emner inden for softwareudvikling, deler ihvertfald ikke din overbevisning.
Konkret eksempel: En folk ingeniører med C baggrund, havde svært ved at forstå delegates i C#. Mens en datamatiker med baggrund i Java, ikke havde noget problem.
Og jeg er sikker på at en webdesigner med erfaring i JavaScript, ville have endnu nemmere ved at forstå det!
Jeg kan give konkrete eksempler. Kan i?
Windcape (121) skrev:
Næsten samtlige ting du kan lære ved low-level programmring er nemlig direkte forkerte i high-level programmering.
Virkeligt?
Low level kan være meget forskelligt.
Men hvis vi nu fokuserer lidt på assembler programmering (det er måske ikke det bedste eksempel, men det er vel på en måde det klassiske eksempel på low level).
For ethvert program i et høj niveau sprog findes der et tilsvarende assembler program som resulterer i samme kode udførsel.
Deraf må vi kunne udlede at de ting der gælder for assembler programmering med hensyn til kode udførsel faktisk også gælder for programmer i et høj niveau sprog.
Det gør der vel principelt ikke, da JIT'd code jo ikke nødvendigvis er det samme hver gang. (Hvis det var, havde vi jo ikke brug for JIT)arne_v (124) skrev:For ethvert program i et høj niveau sprog findes der et tilsvarende assembler program som resulterer i samme kode udførsel.
Også min umiddelbare tanke (og da også min måde at forklare det på)arne_v (125) skrev:Det burde han ikke have, da C function pointers svarer ret meget til C# delegates.
Men tydeligvis handler det for de fleste om det sprogmæssige, og ikke om det underliggende tekniske.
Hvilket også er hvorfor folk med erfaring i JavaScript har nemmere ved at forstå closures, end Java/PHP/C programmører. Da JavaScript i sig selv er indbegrebet af at bruge closures.
Hov, det var ENDNU en ting man kan lære i et highlevel sprog! Sjovt, ikk?
Udover at C ikke nødvendigvis har signatur-check (hello Void Pointer, how are you today)arne_v (129) skrev:Faktisk er det også tæt sprog mæssigt.
Så nu er function pointers pludselig højniveau? Kan i bestemmer jer?arne_v (130) skrev:Du synes at dt er sjovt at man lærer højniveau features i et højnibeau sprog?
#136
Argh idiot! En delegate behøver ikke at være en closure!!!
Argh idiot! En delegate behøver ikke at være en closure!!!
#140
closures handler om scoping (og garbagecollection til dels) og det gør delegates ikke! Jeg forstår ikke hvorfor jeg skal forklare dig det her.
closures handler om scoping (og garbagecollection til dels) og det gør delegates ikke! Jeg forstår ikke hvorfor jeg skal forklare dig det her.
#141
Du forholder dig alt for teoretisk til tingene. Prøv engang at brug tingene i praksis, og så forhold til dig dem ud fra det.
delegates er function pointers til named eller anonymous methods, og closures (i form af lambda expressions) er function pointers til named eller anonymous methods.
Very much same same!
Du forholder dig alt for teoretisk til tingene. Prøv engang at brug tingene i praksis, og så forhold til dig dem ud fra det.
delegates er function pointers til named eller anonymous methods, og closures (i form af lambda expressions) er function pointers til named eller anonymous methods.
Very much same same!
http://csharpindepth.com/Articles/Chapter5/Closure... - Jon Skeet er også enig med mig.
Og resten af verden kan heller ikke bestemme sig for forskellen, navnmæssigt.
At akademikerne så er uenige, kan umuligt være vores problem!
Og resten af verden kan heller ikke bestemme sig for forskellen, navnmæssigt.
At akademikerne så er uenige, kan umuligt være vores problem!
Man har længe brugt delegates i OOP sprog (hvor closures ikke er mulige). I .Net har man så implementeret closures og kaldt dem delegates. Kom ud af din C#/.Net-boble.
Lol. Det var ikke mig der hev monads ind.
Windcape (142) skrev:Du forholder dig alt for teoretisk til tingene. Prøv engang at brug tingene i praksis, og så forhold til dig dem ud fra det.
Lol. Det var ikke mig der hev monads ind.
Hvilke sprog? D kalder også deres closures for delegates!onetreehell (145) skrev:Man har længe brugt delegates i OOP sprog (hvor closures ikke er mulige). I .Net har man så implementeret closures og kaldt dem delegates. Kom ud af din C#/.Net-boble.
Monads er da ret praktisk, f.eks. GetEnumerator i .NET er implementeret som en Monad.onetreehell (145) skrev:Lol. Det var ikke mig der hev monads ind.
Windcape (142) skrev:delegates er function pointers til named eller anonymous methods, og closures (i form af lambda expressions) er function pointers til named eller anonymous methods.
Ja.
Windcape (142) skrev:Very much same same!
Absolut ikke.
Delegates er ganske rigtigt function pointers.
C# spec:
A delegate type represents references to methods with a particular parameter list and return type. Delegates make it possible to treat methods as entities that can be assigned to variables and passed as parameters. Delegates are similar to the concept of function pointers found in some other languages, but unlike function pointers, delegates are object-oriented and type-safe.
Men closures er mere end bare function pointers.
C# spec kommer ikke med en definition.
Men så finder vi noget udenfor.
Wikipedia:
In computer science, a closure (also lexical closure, function closure or function value) is a function together with a referencing environment for the nonlocal names (free variables) of that function. Such a function is said to be "closed over" its free variables. The referencing environment binds the nonlocal names to the corresponding variables in scope at the time the closure is created, additionally extending their lifetime to at least as long as the lifetime of the closure itself.
http://en.wikipedia.org/wiki/Closure_%28computer_s...
Og Jon Skeet i dit eget link:
To put it very simply, closures allow you to encapsulate some behaviour, pass it around like any other object, and still have access to the context in which they were first declared.
Det karakteristiske for closures (og det som navnet kommer fra !) er at de fanger konteksten fra hvor de blev created.
Så alle delegates er ikke closures.
Windcape (143) skrev:Jon Skeet er også enig med mig.
Nej. Han er uenig med dig.
Hvis du faktisk læser den tekst du linker til vil du se:
Of course we could use an interface in C# as well, but it would be significantly messier and wouldn't let us use anonymous methods and lambda expressions - which are precisely the features which implement closures in C#
Wikipedia har også forstået den pointe:
C# anonymous methods and lambda expressions support closure to local variables:
Windcape (143) skrev:At akademikerne så er uenige, kan umuligt være vores problem!
Akademikerne er ikke specielt uenige. De fleste af dem forstå simple definitioner.
Der er lidt diskussion om hvorvidt Java anonymous classes er closure lignende eller primitiv closure - p.g.a. kravet om final specifier på alt der captures. Men det er en anden problem stilling.
Windcape (127) skrev:
Hvilket også er hvorfor folk med erfaring i JavaScript har nemmere ved at forstå closures, end Java/PHP/C programmører. Da JavaScript i sig selv er indbegrebet af at bruge closures.
Hov, det var ENDNU en ting man kan lære i et highlevel sprog! Sjovt, ikk?
Givet #148 kan vi så udlede at du skal igang med at lære nogle high level sprog?
:-)
Alrekr (144) skrev:Google keywords: Difference bewteen delegates and closures
Første hit giver bl.a. denne forklaring: "Closure is a programming language concept. Delegate is its realization in MS.NET."
Ja.
http://stackoverflow.com/questions/951871/whats-th...
Hverken det svar eller det accepterede svar er særligt gode.
Hvis et .NET spørgsmål er besvaret af en af de gode: Jon Skeet, Marc Gravell, Eric Lippert, Pavel Minaev etc. kan du godt regne med at det er rigtigt.
Med totalt ukendte er chancerne ca. de samme som på newz.dk!
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