Det bedste du kan gå i gang med først er Python.
--
THE GAME

Overvej c# også. Man kan ikke sige at et programmeringssprog er bedre end det andet. Man kan sige, jeg kan bedst li' det eller det. Men skal du lave applikationer, ville jeg ikke gå efter Java. C#, C++ eller VB.NET Lettest og komme i gang med, er nok VB.NET. C# næste nemmest, og slutligt C++. Det er i hvert fald det jeg synes og have oplevet
--
Smerter? : http://paincare.dk[...] Forslag til HOL: http://hol.uservoice.com[...]

I Microsoft verdenen er et .NET sprog uundværligt. Jeg ville vælge C# frem for Visual Basic bla. fordi det så er nemmere at lære C++ og Java. C++ er et meget stort sprog, og jeg ville starte med at blive god til Java eller C#.
--
Tilhører grænselandet mellem XP og Win 7

#2 Pjat... Man kan da satgtens lave fine applikationer i Java... OpenOffice f.eks. ?!. ... Hvis vi snakker OOP, kommer det meget an på hvor stejl en indlæringskurve du er villig til at bestige, om det er vigtigt at din applikation er platformsuafhængig, og om du evt. vil bruge samme programmeringssprog til senere at bygge web-appllikationer... //Torben
--

Der er faktisk meget guf i den der #1 #4 Jeg sagde IKKE at man ikke kunne lave applikationer med Java. Jeg siger blot, at det ikke var den vej jeg ville gå, hvis jeg skulle kaste mig over og lave windows applikationer.
--
Smerter? : http://paincare.dk[...] Forslag til HOL: http://hol.uservoice.com[...]

Du skal nok nærmere slå dig på C# hvis du vil programmere applikationer til Windows. Har indtryk af at det bredt set er ved at være anerkendt som Visual Basics afløser. Hvis du sigter efter at dine programmer skal kunne køre på flere platforme har Java fordel ved køre på en virtual machine (trade-off: performance). Javas SDK (JDK) indeholder i øvrigt enormt mange standard-klasser som er lige til at bruge, mens der findes mange uofficielle libraries der dækker funktionalitet som ikke findes i JDK'en (FTP connectivity, JAI for avanceret billedbehandling mm.). Uden at vide det vil jeg dog tro at også C# er ved at have et rimelig fornuftigt antal klasser at trække på.
--
Amiga 600 med 7MHz 68k Motorola CPU, 2MB chip RAM, 8MB fast RAM og 4GB flash HDD på IDE controller. Kører Crysis med 16x AA =)

Tak for alle besvarelserne. er der ikke noget med at C++ er hurtigere end C# ?
--
Gæstebruger, opret dit eget login og få din egen signatur.

C++ er lidt tættere på maskinen jo, men lyt til de andre. Java og C# er nemmere at lære. I sidste ende har det betydeligt mere at sige at du benytter algoritmer der skalerer ordentligt end at du bruger det ene sprog frem for det andet.
--
Amiga 600 med 7MHz 68k Motorola CPU, 2MB chip RAM, 8MB fast RAM og 4GB flash HDD på IDE controller. Kører Crysis med 16x AA =)

Hvis du patu vil bruge et programmerings sprog, så er assembler bedst - Dog er ren maskinkode bedre, men det er jo ikke et sprog. Skal så også siges, at selvom assembler er det bedste sprog for computeren - Så har det en stor ulæmpe, det er besværligt/langsommeligt at programmere i. mvh.
--
Sjovere med ting som folk ikke vil se og høre: www.hardware-infos.com[...] 920 klare sig bedst her i normale opløsninger.

#9 Man programmere sgu' ikke ret meget i assembler mere - det er snart 20 år siden, at dét var et hit! Assembler bruger man idag primært til at debugge maskinkode og cracke programmer, og det ville være komplet idioti at gå igang med at lære dét! #0 Du skal gå efter at lære et C-baseret sprog (C, C++, C#, Java etc.), da det er det der har den bredeste kompatibilitet. Java er let at komme igang med, da det er et "gratissprog". Hent den nyeste JDK og NetBeans, så er du flyvende. Java har den fordel, at det er den type programmer, som kan afvikles på flest mobiltelefoner og PDA'er. Hvis du hellere vil lære et sprog, der er lettere at håndtere og læse, så skal du gå efter Pascal (mit foretrukne ;) eller Visual Basic (hvem kan ikke huske dengang, der fulgte en Basic-compiler med styresystemet? ;).
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

Super. Sidste spørgsmål er C # det samme som c#.net?
--
Gæstebruger, opret dit eget login og få din egen signatur.

Bare lige for at korrigere #6 lidt, så kører C# også under en VM (sammen med de andre sprog der udgører .NET platformen). Hvad performance angår, så er der MANGE delte meninger om C# vs. Java vs. C++ (og ANSI C etc. ). Jeg er selv af den opfattelse, at en dygtig Java-programmør kan vride mere performance ud af det, end en halvskidt C++ programmør. Med det vil jeg sige, at du ikke skal lade dig forblænde af performance til at starte med... Der går nok alligevel et pænt stykke tid inden du kommer til at få den slags behov. Lån istedet et par basis-bøger, og se hvad der ligger lettest for netop dig... //Torben
--

#11 Ja, C# er et .NET-sprog.
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

Tak for hjælpen allesammen.
--
Gæstebruger, opret dit eget login og få din egen signatur.

At I kan være bekendte overhovedet at nævne Visual Basic - VB er jo satans yngel i 0'er og 1'er. C# og Java er ganske gode udgangspunkter, og har mange features tilfælles (C# er lavet med udgangspunkt i blandt andet C++ og Java). Tag og arbejd lidt med en af dem, og skift over til den anden derefter, så kan du selv finde frem til, hvilken en du bedst kan lide. Du bør dog overveje, om du ikke skulle tage en decideret uddannelse inden for programmering hvis du vil til at programmere mere avancerede programmer, og måske endda leve af at programmere - ikke at det ikke kan lade sig gøre uden en uddannelse, men det er ofte en fordel (især hvis du også hører lidt efter i timerne). Markedet for programmer går i mange retninger, f. eks. programmer til iPhonen, programmer til brug i en browser (f. eks. webmail) og alm. programmer som Word og firewalls - så det handler mere om hvad du gerne vil lave. #9 Assembler er da på ingen måde bedre til en nybegynder inden for programmering. Kode skrevet i assembler kan være bedre optimeret, men det kræver jo at programmøren kan finde ud af at skrive effektiv low-level kode.
--

Hvor bruger man egentlig effektivt assembler i dag ?, hvis vi ser bort fra indlejrede systemer og den slags. De fleste styresystemer har jo mig bekendt en C compiler ?!...
--

#16 Det hvor assembler hyppigst bliver brugt, er når man udvikler højniveau-sprog som eks. C++ & Pascal / Delphi (unit's & libraries). Man bruger også assembler til at udvikle specialkode til drivere, der skal kommunikere med hardware - eks. grafikkortdrivere og lign., hvor der ikke findes andre muligheder. Meget af hele DirectX-kernen er feks. også lavet direkte i assembler, idet der ikke fandtes andre muligheder for at få det optimale ud af koden. Hver gang der kommer nye CPU'er med nye instruktionssæt på markedet, skal der også sidde nogen folk og programmere procedure-biblioteker (DLL's) i assembler, for at man kan bruge de nye instruktioner uden at kende til assembler (igen: omsætning til højniveau-sprog).
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

Mht. til at få job, så er C# med godt .NET kendskab det suveræne valg mht. hvor let/svært det er lære og hvor gode job-muligheder der er. Du skal ofte ikke tænke så meget på performance, når det handler om kode til firmaer. 90% af performance i C# handler om at lave "god kode" der ikke skaber garbage collection (Google det evt.). Jeg laver spil med XNA (C#) og her er performance selvf. et issue pga. framerate. Dog viser erfaringerne fra de udviklere der poster mest, at C# yder ret godt, og man kan forvente 10% mere ved at bruge C++. C++ er mere hardcore og bruges stadig af 99% af alle spil-udviklere pga. netop performance. Du har med C++ mere kontrol med memory, men denne kontrol medfører også muligheden for seriøse fejl som kan være helt umulige at debugge (finde grunde til). C++ har noget der hedder "pointers", som for en nybegynder kan være helvedes svært at forstå og svært at bruge ordentligt. Og som nævnt svært at debugge. Når man compiler C++ kode bliver det lavet om til maskin-kode. Dvs. afviklingen går meget hurtigt. Når man compiler C# kode, så laves det om til en mellemting og mens koden bliver kørt, så compiles der også igennem noget der hedder CLR. Her tabes noget performance, men der er så mange andre fordele, at det fungere godt. Java har været foretrukkent i firmaer (ihvertfald i drift-center jeg arbejder i) og man går over til C#. Grunden til, at man ikke bruger C++ mere, er pga. de seriøse fejl der kan opstå og muligheden for buffer overflows. Mht. at lave din egen firewall - hvis du vil lave noget, der ligger sig dybt i systemet (mellem OS og netkortet), så skal du bruge C++ og vide en DEL om netværk og windows OS. Det er meget svært at give sig i kast med. Java er da udemærket, men det performer simpelthen så ringe. Det er dog meget let at lære (ift. andre sprog) og der er sikkert mange tutorials ude. Det vil være fint at lære, og du vil så ikke være så Microsoft-fikseret i din viden. Langt de fleste firmaer bruger dog Microsoft, og .NET er guld værd, hvis man kender det godt. En anden ting - programmering kan du ofte ikke bruge til noget som en enkelt-stående viden. Ofte skal du kommunikere med databaser, Active Directory, lave GUI osv. osv. Men kan du et sprog godt, så skal man bare ind et sted og få noget erfaring med det.
--

#18 Pointers er ikke spor svært - det er jo blot en variabel (et tal), der henviser til en adresse i hukommelsen, hvor der ligger en buffer. Forstår man at arbejde med pointers, så får man helvedes meget mere fart ud af hukommelses-manipulation i forhold til et bytecode sprog, der bruger en eller anden form for overlay-objekt til at styre det.
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

#18 C# har jo intern GC (Garbage Collection) så medmindre du skal benytte et API der ikke selv udnytter dynamisk GC så det oftest ikke noget man skal bekymre sig om.. Men som du siger så det om at lave effektiv kode der ikke laver mere end nødvendigt.. Og nu vi er ved at snakke performance så har C# mange indbyggede readers/writers til alle mulige formål som du kan bruge out-of-the-box men jeg ved at i mange tilfælde kan du selv optimere det meget bedre hvis du dygtig programmør og benytter en helt basic reader fx.. Har oplevet en der gjorde læsning af nogle elementer 5-6 gange så hurtig.. Han tog tid på hvor hurtigt den læste 100 elementer så det var ret sikkert, men det API som vi skulle arbejde med var så også RET mangelfuldt og virkelig dårligt opbygget med et hav af fejl.. Men hvis du ved hvad du laver kan du ofte få mere performance ud af det ved at køre det meget basic.. Men dog behøver man ikke tænke på performance i mange situationer da selv dårlig kode og dårlig oprydning og udnyttelse af resourcer bliver opvejet af dit system måske ikke er så kompleks/stort og ikke skal lave så fandens meget arbejde og derved vil du ikke mærke det ydelse du kunne ha fået.. Du kan sagtens lave et kundesystem eller vare/køb med rigtig dårlig kode og opbygning, udnyttelse af resourcer etc hvor det stadig kører hurtigt og godt jo.. Dog vil jeg sige C# er godt og nemt.. Du får rigtigt mange biblioteker du kan bruge til alt muligt.. Plus at hvis du googler dig frem så der masser af eksempler, hjælp og ting du kan gøre brug af.. Så det også nemt.. Dog vil jeg som allerede sagt gentage uddannelse ville være en god ting.. Selve sproget er ikke så skide vigtigt.. Det er mere at lære opbygning af systemer effektivt.. Relationer og sammenhænge.. Objekter der skal interagere med hinanden.. Så længe du har lært hvordan man sammensætter ting og opbygger dem korrekt og udnytter ressourcer i din kode så er sproget ikke så vigtigt.. Det ligesom hvis du har lært at køre bil så har du lært at koble ud, skifte gear og køre ordentligt.. Så det ikke så vigtigt hvilken bil du kører i... Hvis du tager en ordentligt uddannelsse så kommer du også til at lære bredt om mangt og meget men ikke så dybt.. Fx. som datamatiker lærer du at opbygge GUI, lave dine egne GUI elementer, arbejde med databaser, reagere på events, og generel programmering og opbygning på en hensigtsmæssig måde for systemets krav..
--
Intel C2Q 2.66Ghz Q9450 | Asus P5Q3 Deluxe@Wifi | 4x1GB Corsair XMS 1333Mhz DDR3 | ATI HD4870 1GB DDR5 | 700W CoolerMaster Real Power M700

Bare som en 'final note' (ikke for at skabe en religionskrig, men fordi ret skal være ret, og jeg ikke kan lade være...) : Java performer ikke nødvendigvis dårligere end C#... Der er godt nok talrige eksempler som undebygger denne påstand, men nok lige så mange som modbeviser den. Hvis vi snakker spil, så er der AFAIK nogle 'specielle' API, som hægter sig lidt dybere ned i OS, men som platform generelt er det min opfattelse at de to sprog er meget lige... Min personlige erfaring er også, at de begge platforme performer ca. ens, når de 'kæmper' på lige kår. C# og .NET er nok den mest fremtrædende platform i DK, men stikker man næsen udenfor landets grænser, er Java nok den største spiller når det kommer til 'Managed code'. En hel del af allermest anerkendte API er da også opstået i Java-verden, og herefter adopteret af enten MS selv, eller et open source community. C#'s API er ret ekstensivt, og syntaksen i sproget er noget mere kompleks end eks. Java. Af egen erfaring kan jeg til gengæld sige, at man ikke altid skal regne med at de preprogrammerede klasser i C#'s API opfører sig som ventet... Hvis jeg (igen) skal snakke af egen erfaring, er Java nok lidt mere 'stabilt' og simpelt. Du kommer ikke nødvendigvis til at lære hvordan man opbygger GUI og den slags, blot ved at tage en datamatikeruddannelse. Det gør du muligvis hvis din uddannelse tager afsæt i C#/.NET, da du her er fastlåst til Visual Studio og dens drag'n drop designer... Men den slags har jo heller meget at gøre med egentlig programmering :)... //Torben
--

#17... Det var lidt det der var min pointe :).
--

#9 Der er vidst noget du har misforstået omkring hvad assembler sprog er for noget. Symbolsk representation af maskinkode. Det er et mellemled mellem høj-niveau programmerings sprog og maskinkode. Grunden til at det eksistere er fordi maskinkode er for bøvlet at sidde med direkte (mennesket har dog nemmere ved at se på ord end tal). Det er hverken "værre" eller "bedre" for din computer end alt muligt anden kode, det er dog bedre for de flestes forstand at undgå det. Det er der netop for at man kan fokusere på at løse problemer, uden at tænke for meget på computeren arkitektur. #16 I rene assembler sprog er der 1 til 1 forhold mellem assembly statements og maskine instruktioner. Det gør det meget nemmere at holde styr på nøjaktig hvor meget memory man bruger, og hvor hurtigt det kører. En erfaren assembly programmør kan ofte skrive mere effektiv kode, en noget der først igennem en compiler eller oversætter. Hvis du har et loop i et større program der skal køre ofte, og det er vigtigt det kører hurtigt, kan det være en fordel at skrive netop den lille del af programmet i assembly. #0 Assembly er hul i hovedet at gå i gang med. Tag først en af de mere overskuelige "høj niveau" sprog. Som andre har sagt, vil jeg foreslå C#/Java til at starte med. C# hvis du er mest til windows. Der kommer du hurtigt i gang med at lave noget, så kan du altid bekymre dig om registre og stakke senere, hvis du skulle få lyst.
--
www.dancewiththedr.frac.dk[...]

#23 Så har jeg ikke misforstået noget:) Maskinkode er betydeligt nemmere i mine øjne - Hvorfor skrive kommandoer, når man kan bruge et simpelt hexdecimalt tal - Jeg fatter det ikke, og jeg har heller aldrig selv anvendt assembler. Godt være det er langsommeligt at programmere i, men det er noget mere simpelt at programmere i - Har du set f.eks. vituel basic? Mange lange ord, som der slet ikke har nogen ummiddelbar sammenhæng med hvordan CPU'en arbejder - Måske er det bare mig, men jeg synes det er blevet meget besværligt at programmere, i forehold til de gamle commodore 64 tider:) mvh.
--
Sjovere med ting som folk ikke vil se og høre: www.hardware-infos.com[...] 920 klare sig bedst her i normale opløsninger.

#24 Sikke da en gang vrøvl! Højniveausprog ligger tættere på menneskelig tankegang end lavniveausprog, ergo er de enklere at benytte. I et moderne sprog kan jeg udføre det samme stykke arbejde på 10 linier, som jeg kan på 100 linier i assembler, hvis ikke flere.
--
Zzzz

#24 Mig bekendt står de hexadecimale tal jo netop for en kommando, og derefter en adresse som kommandoen skal udføres på, så forskellen er bestemt til at overse. Hvis du har det nemmere med at arbejde på et niveau, hvor du kan se CPU'ens arbejde mere direkte så kudos, men jeg tvivler på, at det er noget som #0 kan gøre brug af. #25 Enig, det er klart nemmere.
--

#24 Har selv haft en instruktor sidste år der kunne læse ting (hurtigt) direkte ud af maskinkode, hvis det bare var ia-32. Han brugte dog assembly til programmere. Det var stadig noget langsommere end folk der kodede i højniveau, men der skal jo bruges programmøre til lav niveau. Hvis du er komfortabel med det, så kan jeg kun sige godt for dig (ikke sarkastisk. Jeg har hørt løse rygter om, at der skulle være ret store penge i det). Dog vil jeg aldrig foreslå assembly/maskinkode til nogen andre, da langt de fleste forøger deres chancer for at få kraft i hjernen af at kigge på det.
--
www.dancewiththedr.frac.dk[...]

#24 Øh... måske skulle det lige overvejes at BASIC er noget af det mest simple at programmere i, så selvfølgelig var det lettere at programmere på en C-64. Jeg har faktisk et reference kort liggende til Commodore 64, en enkelt A5 side der beskriver samtlige funktioner du kan bruge når du programmerer. Det siger bare lidt om hvor simpelt det er. #27 Har du en kilde til det? Jeg kan ikke rigtigt se hvordan kompleksiteten af et programmeringssprog hænger sammen med risikoen for at udvikle kræft i hjernen? #0 Personligt ville jeg ikke ane hvad jeg skulle anbefale, de programmeringssprog jeg kan er ikke noget der bliver brugt i moderne PC'ere. Dog synes jeg at C# virker som et rigtigt fornuftigt forslag, det var ihvertfald det jeg selv ville kaste mig over hvis jeg skulle til at lære noget nyt :)
--
Spiller faktisk kun Dawn of war 2 for tiden - tilføj LeetDonkeyDK på live hvis du vil spille lidt team med en rank 25.

#28 så du sætter lighedstegn mellem antallet af funktioner og simpelthed? Simpelt er da snarere VS Forms, hvor du kan lave drag and drop, og så kun lige skrive en konkret event - det kan nok læres noget hurtigere end at overskue et A5 ark med uforståelige glypher. - her tænker jeg på en skolepraktikant der lavede en lille regnemaskine - den operation var ikke særligt svær at overskue og komme langt med - og med et resultat man kunne finde på at bruge - i modsætning til at få et kommandolinie program der er kodet med polsk notation fordi det var nemmest at implementere med det lille ovebrlik man havde i BASIC. - Jeg er helt enig i at man bør starte ud i et højniveau sprog (og helst et med værktøjer til at lave GUI) også selvom der er flere instruktioner og mere man ikke kan med det samme. Desuden har Visual Studio den store fordel i mængden af tutorials, guides og howtos der ilgger online.
--

#28 Det var en joke. Det jeg prøver at sige er at langt de fleste finder det svært, langsommeligt og bare generalt træls at arbejde med.
--
www.dancewiththedr.frac.dk[...]

#29 Ja, det vil jeg, men det kommer vel an på hvad der ligger til grund for ordet 'simpelt'. Mht. overskueligheden var det jo det man havde at gøre med dengang, jeg er enig med dig i at det var et helvede at gennemgå et program på flere hundrede linjer med kode da der ofte var et par gosubs osv. hvor man så kunne scrolle frem og tilbage én linje af gangen - Det var bestemt ikke optimalt.
--
Spiller faktisk kun Dawn of war 2 for tiden - tilføj LeetDonkeyDK på live hvis du vil spille lidt team med en rank 25.

#30 Hehe fair nok, jeg fangede den så bare ikke ;) Jeg troede lige at der var kommet 'ny' forskning der viste at jo mere vi brugte hovedet jo større risiko for hjernekræft var der :P
--
Spiller faktisk kun Dawn of war 2 for tiden - tilføj LeetDonkeyDK på live hvis du vil spille lidt team med en rank 25.

Man kan slet ikke lave et moderne windows-program i assembler, uden at skulle refere til højniveau-funktioner der er indbygget i windows, så assembler er udelukkende noget folk blærer sig med at kunne, fordi det er det sværeste sprog at kode seriøse programmer i. @@ADR1 PUSH EBX MOV EBX, EAX PUSH EBX CALL @CreateWindow POP EBX POP EAX DEC EAX JNZ @@ADR1 RET Ihh jo - dét er skam let nok at forstå (ps. koden laver 100% rav i den ;-)
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

class Pet { public double Cuteness; public double Attackness; public double GetAwesomeness() { return Cuteness * Attackness; } public bool Own(Pet pet) { return GetAwesomeness() > pet.GetAwesomeness(); } public Pet(double cuteness, double attackness) { Cuteness = cuteness; Attackness = attackness; } } Pet dog = new Pet(1, 3); Pet cat = new Pet(4, 2); Console.WriteLine("General principle of nature:\n" + (cat.Own(dog) ? "Cats own dogs... Obviously." : "Dogs own or are equivalent to cats. What the hell?")); Kan en af de glade lavniveaunørder ikke lige gengive det i Assambler?
--
When in doubt, YOU SUCK!

#34 Kunne jeg godt, men jeg gider sgu' ikke spilde en aften på det - hehe ;-)
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

Fordelen ved høj-niveau er jo netop, at man ikke hele tiden skal opfinde hjulet, men kan genbruge funktion som andre har lavet mest optimelt. Selvom man laver ting i assembler, så laver man ret sikkert fejl og det er ikke sikkert det er hurtigere. F.eks. kan man læse fil-indhold ind i memory på få linier i C#. Skulle man gøre dette i assembler, så skulle man først kode hele funktionalitet til at kommandere disken til at læse osv. Med assembler kode skal man holde styr på sin memory, og derfor skal man kode noget memory management for at det skal være effektivt. Efterhånden har man kodet et lile OS for at en simpel funktion skal kunne lade sig gøre. Det er godt til embeddede systemet. Små hardware-dingenoter som har meget begrænset RAM og CPU, hvor man skal presse max ud af systemet. Med windows er der stor buffer med RAM og CPU og bla. derfor bliver business applikationer IKKE lavet i assembler. Det mest springede punkt er dog nok, at fejl formindskes MARKANT, når man laver tingene i et managed sprog pga. mindre memory fejl. #19 Pointers er sikkert ikke svære for dig, fordi du HAR lært det, men jeg vil stadig påstå, at det er svært for rigtigt mange. Det er nemt at forstå det overfladiske koncept, men det er svært at forstå ordentligt så man bruger det uden at lave memory fejl engang imellem - og de er pissesvære at debugge. man skal holde tungen lige i munden, men samtidig er det også et kraft-fuldt værktøj. #0 Læs på C#. Køb en nybegynder bog - se nogle tutorials osv. Der er massere guf derude som du vil kunne bruge i fremtiden.
--

Som sidenote... Hvis antallet af keywords er ligerefrem proportionalt med kompleksitet, er C# da den HELT forkerte vej at gå ?!. -Og, medmindre man har nogle seriøse autistiske træk, er assembler da fuldkommen og aldeles tidspilde, undtaget... 1. At man selv synes man er mere skarp til assembler, end dem som laver C-compilere. 2. At der er MEGET tungtvejende grunde til at bruge xxx ekstra timer på at vride for xx nanosekunder mere performance ud af applikationen. Der KAN selvfølgelig være gode grunde til at kunne assembler/maskinkode teknikker (eks. hvis man selv har lavet sin CPU... !), men at lave seriøse programmer i ren assembler, svarer for mig til at sidde og håndtegne samtlige 65000000 transistorer i den næste i386 CPU... //Torben
--

#36 Pointere er altså hverken svære at bruge eller debugge. Tænk på en pascal type som "Str: PChar" eller det ekvivalente "char *str" i C(++). Det er også pointers, idet de henviser til et område i hukommelsen, hvor der er opbevaret en streng af bogstaver, der ofte er afsluttet med nul. Det er da noget alle med en smule erfaring kan hitte ud af. Personligt programmerer jeg meget i Delphi / Pascal (hedder idag CodeGear RAD Studio), og det giver en fin debugging af pointers under programafvikling.
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

#37 Arrr... Det giver nu ellers god mening at bruge assembler til eks. pixelbehandling af grafik og billeder. Her er der en hel del mere at hente end blot et par nanosekunder, idet højniveau-sprog ofte har indbygget et væld af unødvendige procedurekald i grafikbehandling, der ikke beregnes af GPU.
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

c++ er bedst ... Men lad os lige slå fast, at der nok ikke fandes mange programmeringssprog, hvis en sådan opfattelse ikke er subjektiv. (QT er i øvrigt det bedste C++ framework.) Assembler er spændende at lære og man lærer hvordan computeren 'tænker' hvis man kan assembler, men det er næppe det, som man først bør give sig i kast med. Java og python (og nok også C# - selvom det er lavet af MS) er bestemt også interessante sprog.... (Jeg kender ikke meget til VB, men jeg vil ikke anbefale det. Det har haft sin storhedstid - og der er intet, der tyder på at det er en ever-green)
--
Er ikke begejstret for monopoler som Post Danmark, Intel og MS

Uh, I har vel bemærket, at trådens opretter forsvandt efter #14, ikke?
--
When in doubt, YOU SUCK!

#34 Haha. Siden du skal starte på datalogi, så får du heldigvis selv muligheden for noget lignende. I computer og netværk på Q2, kommer der assembly til både IA-32 og JVM. #41 Jeps, nu er vi bare nogen der hygger os med, at give hinanden ret i, at assembly ikke er vejen frem når man skal starte med at programmerer
--
www.dancewiththedr.frac.dk[...]

#42 IA-32 har ikke nødvendigvis noget med assembler at gøre, da det blot drejer sig om processor-arkitektur. JVM Assembly har heller intet med maskinkode at gøre, idet det drejer sig om at snakke med JVM (Java Virtual Machine) på bytecode-niveau (mao. man skriver bytecode selv, i stedet for at lade en compiler gøre det). Rigtig assembler består i direkte manipulation af CPU'ens registre.
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

#37 det handler ikke om at være bedre assembly-programmør end dem, der laver compilerne. Det handler om at skrive den mest målrettede kode. En compiler kan ikke garantere den mest optimale kode ved oversættelse fra højniveau til lavniveau. Compilet kode er ikke nødvendigvis meget langsommere end ren assembly, men der kan forekomme tilfælde, hvor den er. Jeg kan ikke lige finde nogle eksempler på dette, måske andre kan? Ja - i mange tilfælde er det tidsspilde at kode i ren assembly, da hastighedsforskellen er uden betydning. Det er dog interssant at stifte bekendtskab med for at lære, hvad der sker i en cpu. Da jeg havde el på htx sidste år kunne vi selv vælge hvilket sprog vi ville kode i (så længe det compiles til .hex), og der valgte jeg assembly for at komme så tæt på hvad der skete i mikroprocessoren, hvor mange andre valgte c pga. enkeltheden.
--
I dag er den første i resten af dit liv

#9 Kode skrevet i assembler kan være bedre optimeret, men det kræver jo at programmøren kan finde ud af at skrive effektiv low-level kode. Man skal være en _rigtig_ dygtig programmør for at kunne optimere på kode genereret af en bare halvgod C++ compiler. Og generelt til topic: Hvad du lærer først er IKKE vigtigt, det svære ved programmering er logikken og algoritmerne. Når du har styr på de generelle ting tager det kun et par dage at lære et nyt sprog, da de i bund og grund ligner hinanden meget. Og så snart man har styr på program-logik, så er det kun simpel syntax og keywords man skal sætte sig ind i for at lære et nyt sprog. #40: c++ er bedst ... Kan godt være jeg ikke fangede sarkasmen i dit indlæg, men vil bare lige nævne at dette er det værste vrøvl jeg længe har hørt. Hvis du seriøst mener at "c++ er bedst" uanset hvilken opgave man skal knække, så er det fordi du ikke aner en brik om hvad du snakker om. Hvis det derimod var for sjov så er joken på mig og i må nu alle pege og grine ;)
--
Gigabyte GA-EX58-EXTREME * Core i7 920 * 3x2 GB Mushkin 1333MHz * 2x GTX260-216 SLI

#44 Et eksempel hvor assembler er bedre end andet kode er billedbehandling, hvor man skal behandle en stor data-buffer / pointer, der indeholder et pixel-array. Det kunne være, at man skulle finde alle pixels med rødlig toning og ændre dem til blålig toning - her ville assemblerkode virkelig komme til sin ret! #45 Vi er enige i, at man skal vælge det sprog, der er bedst til opgaven. Men C(++) er nu engang det sprog, der er mest udbredt, og der findes C-compilere til windows, linux, unix, android, symbian osv., og derfor er C det bedste sted at starte, da det giver de fleste muligheder.
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

#43 Rigtig assembly er ikke andet end symbolsk maskinkode. Du kalder det symbolsk maskinkode til IA-32 fordi det er den arkitekturs maskinkode du representerer (når du skriver til IA-32) Hvad du kan i IA-32 er helt op til hvad instruktions sæt og instruktions format arkitekturen giver dig. Det nytter jo ikke noget du skriver kommandoer som en arkitektur ikke forstår. Selvom du bruger en virtuel maskine, som java for eksempel kører i, findes der stadig arkitektur, og derved også et sæt instruktioner og instruktions formater. JVM har et assembly sprog nøjagtig som IA-32, og de fleste andre arkitekturer har det. At man skriver direkte til registre i ia-32 og ikke JVM, gør ikke det ene til et rigtigt assembly sprog og det andet forkert.
--
www.dancewiththedr.frac.dk[...]

#46: Jeg skrev som bekendt ikke noget om hvad der er "det bedste sted at starte". Jeg pointerede bare at "c++ er bedst" er noget vrøvl. Jeg tror vi i bund og grund er enige :) Jeg elsker selv C++.
--
Gigabyte GA-EX58-EXTREME * Core i7 920 * 3x2 GB Mushkin 1333MHz * 2x GTX260-216 SLI

#48 Næh, for jeg hader C++ - gnæk gnæk ;-)
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

#36 Ja pointers er ikke ret nemt og kan nemt lave rigtigt rigtigt meget rav i den.. Kender bl.a. et et system med et virkelig mangelfuldt API.. Nogle metoder ryder pointers op efter dig, men ikke altid.. Så der skal man selv lokalisere din oprindelige pointer når du færdig med den og fjerne den medmindre den bare skal blive ved at flyve rundt i din memmory og ta plads indtil miljøet lukkes ned.. Det er FANDME skod!! #37 Fuldstændigt rigtigt! For mig at se er det meget få tilfælde det kan bruges så hvorfor opfinde hjulet igen? Nej GENBRUG er sundt!! Udnyt hvad andre har lavet for dig og byg videre på det istedet.. #38 Jeg nu glad for C#'s evner til selv at rydde op med GarbageCollection. Men som jeg nævnte til #36 så kan det bare nemt få gruelige konsekvenser hvis du ikke har helt styr på det.. Og oprydning synes jeg også godt kan blive lidt tricky da du i hvert kald og metode skal vurdere hvad skal bruges mere og hvad skal ikke.. Der det meget nemmere at GC gør arbejdet for dig uden du skal bekymre dig om noget som helst.. Nu har jeg nok også blot det syn fordi jeg har arbejdet med et system hvor dem der udviklede det har fucket det totalt op og det er spækfyldt med fejl (på trods af det er det største indenfor sit felt) #39 Nu kommer det vel også an på om det er paint du skal lave eller photoshop? For kunne også godt forestille mig sidstnævnte ville blive lidt hårudtrækkende at sku begynde på.. #42 Det faktisk derfor jeg vil undgå uddannelser på det niveau.. Har flere venner der har prøvet det og da fint lige at få lidt grundlæring i det og forståelse for det, men der er bare så meget teoretisk som du oftest ikke vil skulle ud og bruge alligevel.. Du lærer nok også en masse andet smart men det med at lære sindsyge vilde sorteringsteknikker/mønstre og alt muligt andet der står jeg sku af for det er ikke det jeg kommer til at sku bruge i størstedelen af mit arbejde alligevel.. men det jo så forskelligt hvordan folk har det med det.. #44 Det er da spændende hvad der sker i en cpu men det da også kun til forståelsesbrug for mit vedkommende.. Og vil da også mene at den hastighedsforskel ofte enten ikke vil være mærkbar medmindre systemet er stort og krævende for ellers synes jeg nutiden maskiner er ret effektive så begrænset hvad du kan mærke af boost.. Men skal da ikke kunne sige om det ville være noget der kunne måles.. #46 Blot fordi det er til mange platforme gør det vel ikke det bedste..? Gammel lort er der som regel meget af fordi det nye er der ikke nået at komme så meget af endnu (det jo nyt) Bare se på et hav af G3'er der fræser rundt overalt.. Men nye lækre Audier er der ikke lige så mange af.. Min pointe er blot at blot fordi det er udbredt gør det ikke bedst sted at starte.. Man skal også ta meget andet med i tanken som fx om det nye har noget som det gamle ikke har.. Er det nye nemmere/smartere? Om nogle år vil du så ærge dig over du valgte det gamle lort eller begyndte på noget nyt som der måske så begynder at komme meget mere af? Hvordan står du rustet til fremtiden med et cv med udelukkende c på? Er din gensalgsværdi da god eller kræver det nyinvestering (læs: læring) i nyt alligvel, bare nogle år senere?
--
Intel C2Q 2.66Ghz Q9450 | Asus P5Q3 Deluxe@Wifi | 4x1GB Corsair XMS 1333Mhz DDR3 | ATI HD4870 1GB DDR5 | 700W CoolerMaster Real Power M700

en god programmør kender og har prøvet lidt af hvert, man bør vide hvordan en CPU virker og hvad registre og hukommelse osv er for noget, et par dage med assembler og hardware på laveste niveau sætter alting godt i perspectiv og man forstår derfor større systemer bedre og kan udnytte de resurser man har mest optimalt. i dag er der alt for mange PC programøre, uden denne viden, jeg vil faktisk ikke kalde dem for rigtige programøre med for scriptere ! det hele er tydeligt læsbart tekst der kalder funktioner og routiner som all mulige andre har lavet, det er jo netop derfor at vi skal have 3GHz maskiner for at læse en hjemmeside, ja så er jeg også bil bygger da jeg har skiftet bil batteriet helt selv i min bil.
--
Homemade H2O Cooling + much more [L]http://www.webx.dk[...]

#51 Jeg giver dig ret i man ska ha prøvet lidt af hvert, men at vide hvordan registre, pointers, cpu og hukommelse virker kan godt gøres uden at skulle kastes ud i et programmeringssprog der viser dig det.. Du kan godt få det forklaret på andre måder.. Ved modeller hvor du skal bruge maskinkode der illustrerer processen der foregår hvor du skal lave nogle udregninger.. Du ska jo heller ikke kunne splitte en computer ad for at kunne finde ud af hvordan den fungerer.. Du kan godt få perspektivet på andre måder jo.. Det blot min pointe.. Udnyttelse af resourcer og systemer er da også noget jeg går op i men derfor kan jeg stadig godt lave et basalt salgssystem med kunder, varer, ordrer i som fylder et par mb og det fungerer alletiders.. For der er det ikke stort arbejde der skal laves eller store objekter der arbejdes med.. Hvorimod fx hvis du skal bearbejde meget og stort, plus dine rutiner ikke er optimerede så kan det sagtens mærkes.. Men det er jo ikke det man oftest vil sidde med /synes jeg ihvertfald ikke).. Der er da altid andre tilfælde hvor det er mere vigtigt at optimere men for at jeg optimerer mit kode i et windows forms program til desktops med handelssystem der kan du ikke mærke den store forskel jo.. 3Ghz maskiner for at læse en hjemmeside? Hvor kom det nu fra? Der er krævende sider og der er ikke krævende sider.. Du kan da ikke stille sådan generalisering op om sådan noget.. Nej du da ikke bilbygger.. Du bruger noget andre har lavet, hvilket jo er så skidt siger du.. Du har da ikke selv lavet plastik, udvundet metal opbygget batteriet.. Du har ikke bygget din bil fra egne pladedele du selv har fremstillet..
--
Intel C2Q 2.66Ghz Q9450 | Asus P5Q3 Deluxe@Wifi | 4x1GB Corsair XMS 1333Mhz DDR3 | ATI HD4870 1GB DDR5 | 700W CoolerMaster Real Power M700

#45 Et sent svar. Nej, jeg kan faktisk godt lide c++ - men når jeg sætter det på spidsen. C++ er bedst er det med en ironisk arrogance ... #52 icreate-c-sharp. Dit brugernavn angiver jo at du godt kan lide c-sharp, og det er fint. Du har også ret i at man i f.eks C++ skal have godt styr på pointere. Selvom jeg bliver ved med at høre rygter om at garbage-collection er godt (hvad jeg egentligt ikke er ubetinget uenig i), bliver jeg også ved med at høre om applikationer, der gør noget tungt, hvor garbage-collectoren bliver en rigtig tidstyv. Så kan du sige, at det ikke er realistisk at han som begynder kommer i den situation - i så fald ja, men hvis der er tale om et simpelt program er det også simpelt at holde styr på pointere (og kan f.eks ske med smartpointere med reference-count i c++) Nu er C# jo et java-plagiat, og java har (haft?) noget svært ved at gøre simple ting som bit-operationer og andre 'low-level' ting. Umiddelbart kunne jeg forstille mig at det også var et C#-problem. (Nu kender jeg ikke C#, så dette er skrevet med risiko for at blive irettesat.) Slutteligt - men også mest vigtigt, så ved man ikke om C# har nogen større fremtid. MS lever på hele tiden at skifte teknologi. For 10 år siden var VB bare fremtidens sprog (set med MS + deres fans briller). Hvordan ser situationen for VB ud nu - hvordan synes du det gik? Lad mig bare svare. Mange, der satsede på VB ville i dag nok ønske at de havde holdt sig til C++ eller skiftet til java ... C++ og java vil findes i fremtiden - men jeg vil tillade mig at tvivle på C#.
--
Er ikke begejstret for monopoler som Post Danmark, Intel og MS

#53 Jeg vidste ikke at man kunne ha ting der kunne hjælpe med pointers, men jeg har da arbejdet med et objekt der kunne hjælpe og frigive dem igen... Men siger bare at som nybegynder er det måske nemmere ikke at skulle tænke på det og dermed er risikoen for de laver fejl der mindre... Siger ikke at det absolut er et område man aldrig skulle prøve at rode med, men som start kan det være nemmere at ha mindre at skulle bekymre sig om og kunne opbygge struktur og fejlhåndtering måske... Det med vb var en død fisk giver jeg dig ret i... Men med den store lancering af .NET tror jeg det er noget MS vil holde lidt bedre styr på med alt det som det indeholder... Og specielt med c# som hovedmanden er det gået rigtigt stærkt... Men synes heller ikk at MS har de mangler og fejl som vb ellers havde (synes jeg ihvertfald)... Det hurtigt blevet spredt ud hvilket aldrig er en garanti men tror det er blevet indtaget fordi det nemt, fungerer og er ready to use out of the box... Tror .NET er familien ms har lært lektien fra tidligere og vil kæmpe for at holde ved og som derved vil blive en rum tid... Udstiller ingen garantier men jeg tror min fremtid er sikret...
--
Intel C2Q 2.66Ghz Q9450 | Asus P5Q3 Deluxe@Wifi | 4x1GB Corsair XMS 1333Mhz DDR3 | ATI HD4870 1GB DDR5 | 700W CoolerMaster Real Power M700

Garbage-collection er jo sådan set et udtryk for, at man ikke selv formår at håndtere hukommelse og buffers, og derfor skal have et "ekstra lag" af programmel til at gøre det for sig.
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

#55 Det kan du måske have ret i, men undskyld min mistillid til folks glemsomhed og eventuelle evner eller mangel på samme.. MEN når man sidder og arbejder med et API til et standart produkt som er førende og største indenfor sit felt og det er spækket med fejl og mangler (ikke kun garbage collection, men også her) så kan jeg ikke lade være at tænke at selvom det måske ikke optimerer på samme måde som det kunne være gjort så synes jeg det er et skønt alternativ.. For hvis firmaer der udvikler software som de førende indenfor et felt, ikke kan finde ud af det så tænker jeg hvis store firmaer med teams og arkitekter etc. ikke kan få det lavet ordentligt så kan vi andre vist også nemt ende i de situationer..
--
Intel C2Q 2.66Ghz Q9450 | Asus P5Q3 Deluxe@Wifi | 4x1GB Corsair XMS 1333Mhz DDR3 | ATI HD4870 1GB DDR5 | 700W CoolerMaster Real Power M700

#54 Du modsiger mig jo sådan set ikke - vi vægte bare forskellige ting. Udstiller ingen garantier men jeg tror min fremtid er sikret... Ja, og hvis du er en dygtig programmør så er din fremtid nok sikret uanset C#'s fremtid. #45 Endnu et ps. Jeg ved selvfølgelig godt at C++ ikke altid bare er det bedste ... Det afhænger som du er inde på af opgaven - men C++ er meget allround, men er selvfølgelig ikke som Python til script og ML til funktionel brug ...
--
Er ikke begejstret for monopoler som Post Danmark, Intel og MS

En RIGTIG programmør ved, at han/hun skal vælge det sprog, der med mindst indsats løser opgaven bedst muligt. Derfor er det også en fordel at kunne lidt af hvert ;-)
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

#57: Jamen så er vi helt enige! :)
--
Gigabyte GA-EX58-EXTREME * Core i7 920 * 3x2 GB Mushkin 1333MHz * 2x GTX260-216 SLI

#55 "Garbage-collection er jo sådan set et udtryk for, at man ikke selv formår at håndtere hukommelse og buffers, og derfor skal have et "ekstra lag" af programmel til at gøre det for sig." Jeg synes nu mere det er en erkendelse af, at det ikke kan betale sig at bruge tid på længere, fordi man ikke længere behøver det. Hvis maskinen formår at gøre arbejdet tilfredstillende, hvorfor så ikke spare på krudtet og bruge det til at lave funktionalitet i stedet? Det er IMHO blot et skridt op ad evolutionsstigen... Men bevares - det har også sine ulemper. Jeg KAN sandsynligvis ikke skrive god kode længere uden min garbage collector :)
--
Zzzz

#60 Følgende Delphi/Pascal-eksempel er da ikke svært, selvom det bruger pointere: http://pastebin.com[...] Skulle man have brugt garbage-collection, så var den buffer, som filen blev indlæst i samt filobjektet, blevet hængende i hukommelsen, indtil GC'en synes det skulle frigives. Jeg kan godt lide at have kontrol over, hvordan hukommelsen reserveres og frigives i mine programmer. GC er måske nemmere at håndtere, og man sparer et par linjer kode i det man laver - til gengæld, så skal der udføres en masse skjult arbejde, som man ikke har styr på. P.S: Jeg ved godt, at mit eksempel kun er anvendeligt på små filer ;-)
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

#61 Det arbejde der udføres i GC behøver du vel ikke at ha' styr på? :) Dit eksempel ... tjaeh, GC ville frigive hukommelsen 5-10 sekunder senere. Pointen er ikke i de linier kode du sparer, men de fejl du sparer, fordi du ikke behøver huske at rydde op efter alt du hiver i luften. Synes din beskrivelse var langt fra virkeligheden. Jeg har i hvert fald ingen kollegaer som ville "gå tilbage" til unmanaged kode, hvis de skulle vælge - mig selv inklusive.
--
Zzzz

#62 Vi kan blive enige om, at GC er lettere at arbejde med, og derfor bedre egnet til mindre gode programmører, der skal lave simple programmer. GC klarer sig også fint på mobile platforme som telefoner og PDA'er. Men når vi kommer til seriøs programmering, som drivere, kernel, spil, Direct3D og den slags, så er GC for langsomt, og her skal man bruge den traditionelle og hurtige løsning med direkte reservering og frigivning.
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

#63 Hele ideen med at inkludere GC flytte en programmørs at flytte fokus fra teknik til mere problemorienteret tilgang til programmering. Den simple oversag, det er simpelthen ikke pengene værd at have programmøre til at sidde og bruge tid på noget mange applikationer slet ikke ville kunne mærkes. Om det så er en god eller dårlig ting, vil der nok være delte meninger om. I nogen sammenhæng er det udemærket, i andre har hver eneste resurce betydning og man vil nok vælge at overlade så lidt som muligt til uigenskuelige compilere/oversættere. Hvis du kigger på hvad slags job der flest af lige pt, vil jeg sige at industrien umidlbart hælder til det første. At sige java/c#, er bedre egnet til mindre erfarne programmøre vil jeg tildels give dig ret i, men det ændre ikke på det faktum, at dygtige programmøre også for meget ud af at kunne fokusere på solidt design af klasser, gode algoritmer etc etc, istedet for at have flere variabler, der i og for sig ikke hjælper med at løse et givent problem.
--
www.dancewiththedr.frac.dk[...]

#64 God hukommelsesstyring er del af udviklingen af gode klasser og komponenter. Jeg tror det er afhængigt af, hvad man er vandt til - personligt bryder jeg mig ikke om GC, da jeg ikke har fuld kontrol over placeringen af variabler og buffere. Når jeg udvikler til mobil, så bruger jeg java/midp, og her har jeg for uvane hele til at "nullify" mine variabler uden grund, når jeg ikke skal bruge dem mere xD
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

#63 ... Vi kan blive enige om at GC er lettere at arbejde med, og derfor giver programmøren fri til at bruge krudtet på vigtigere ting, som f.eks. at lave et godt design. Der er et kæmpe marked for netop den her slags tiltag - Garbage Collection, Object-Relationship mappere, ting som sparer tid og bekymringer, og lader programmøren bruge tid på at forstå problemstillingen, fremfor at nørkle med teknikken... Men det er da langt mere en prioritering, end et udtryk for at "man ikke selv formår at håndtere hukommelse og buffers".
--
Zzzz

#65 Tror du har helt ret i at det er et spørgsmål om vaner. Personligt, har jeg ikke ret stor erfaring med c/c++, da Universitetet fokusere kraftigt/udelukkende på java i den smule programmering der har været indtil videre. Jeg er dog en smule ærgelig over det, da jeg egentlig selv ville fortrække c++. Bryder mig ikke om at overlade så meget kontrol til JVM, og ville gerne have flere muligheder for at gå direkte til hukomelsen, hvilket java efter min erfaring absolut ikke giver (ikke engang i jvm assembly). Java klarer dog jobbet I langt de fleste tilfælde, og multiplatform er da også rart. Det har nok i mit tilfælde mere at gøre med at være kontrol freak. Med klasse design tænkte jeg nu mere i de lidt mere teoretiske baner med koncepter (oop) som indkapsling, effektiv brug af interfaces/polimorphism etc.
--
www.dancewiththedr.frac.dk[...]

#66 Hvis man oplæres i et sprog, der har en underlæggende GC, så lærer man jo aldrig at håndtere hukommelsen egenhændigt, og dermed går man glip af nogle magtfulde optimeringsmuligheder. Desuden afskærer man sig selv fra at kunne programmere effektivt på kerne-basis. #67 OOP er jo et spørgsmål om at lave en base, som kan udvides til flere ting, og dermed spare sig selv for at gentage den programmering, der ligger i basen. Som udgangspunkt har OOP intet at gøre med hukommelsesstyring, men jeg forstår din pointe. Det er muligt, at direkte hukommelsesstyring er i starten af en udfasning. Men hvis man virkeligt vil frem, eller hvis man virkeligt vil ind og kode i kernesystemer, så kommer man ikke uden om, at skulle benytte traditionel hukommelsesstyring - på godt og på ondt ;-)
--
http://xlinx.dk[...] E6600, 4GB PC2-6400, GA_965P_DS4_R1, 9800GT

#68 "Men hvis man virkeligt vil frem, eller hvis man virkeligt vil ind og kode i kernesystemer, så kommer man ikke uden om, at skulle benytte traditionel hukommelsesstyring - på godt og på ondt ;-)" Det er vist din indskudte sætning som gælder... Ellers kender jeg da en god håndfuld fremragende .NET programmører, som vil blive kede af at vide at de ikke er med "fremme"... If you catch my drift.
--
Zzzz

#68 Helt enig. Vi har dog brugt del energy på at programmere direkte i IA-32 assembly og oversætte simple programmer til assembly i hånden. Ikke at man når at blive erfaren, men så man ved hvad der foregår. Med hensyn til OOP så har vi snakket forbi hinanden. Hukomsels styring har intet at gøre med koncepter bag OOP. Det var netop også min pointe at ved at fjerne fokus fra teknik, giver man mere plads til mere konceptionel optimering. Med hensyn til drivere, kernels, compilere til maskinkode og lign. så er et "højniveau" sprog some java ikke det rigtige valg. Det gør dog programmøre inden for andre fælter mindre gode, de har bare et andet fokus
--
www.dancewiththedr.frac.dk[...]