Att börja programmera - Lite tankar, åsikter och massa frågor.

Mekatronikingenjörerna läser det, d.v.s folk som läser lite maskin, datorteknik, och el. Problemet med denna utbildning är att de bara läser grunderna om allt, i.o.f.s så blir de breda.
Tar vi högskole-Mekatronik på 180hp, så är de förståeligt att de inte av enbart den utbildninen blir grymma programmare,området datateknik, maskiningenjör samt elektronikingenjör. Nå det finns ändå gott om arbete för dem då det behövs folk som kan lite av allt..

En maskiningenjör har självklart stor nytta av Assembler i och med den metallnära naturen i det maskinnära arbetet.

Jag kunde datastrukturernas uppbyggnad och fördelar/nackdelar långt innan jag lekte med Assembler. Det mesta är sunt förnuft. Vet man inte vilken datastruktur man skall använda är det bara att läsa på om dem. Det är inte självklart vilken datastruktur man bör använda bara för att man kan Assembler, det kan snarare vara tvärtom om man är så ignorant och självsäker att man inte ens kollar upp det.

Att man skulle ha nytta av Assembler för att använda och förstå trådhantering eller exceptions är vansinnigt fel. Jag har då aldrig dragit sådana paralleller i mina applikationer med multi-threading. Hade folk vetat mer om Assembler hade fler känt hur onödigt det är att kunna programmera på lågnivå när man skriver större objektorienterade applikationer på högnivå. Jag kommer aldrig att få tillbaka de där Assembler-timmarna och vill hjälpa andra högnivåprogrammerare att slippa dem också.

bud_bundy> Det är sant att utvecklingen gör att fler företag riktar in sig på enbart högnivåprogrammering för sina produkter, men det kommer alltid att behövas lågnivåprogrammerare också, och dessa är absolut inte mer "elite" än de andra. Det är två olika slags kompetenser som inte ska blandas samman; det vore som att säga att en elektriker är sämre än en byggnadsarbetare, bara för att byggnade behöver byggas innan elen dras. Mjukvaruutveckling är ett stort område.

Har man inte koll på sina algoritmers tidskomplexitet eller är medveten om hur man valt att kompromissa mellan tid vs utrymme så spelar det ingen roll om man kan assembler eller ej. När det gäller grundläggande kunskaper om hur processorn fungerar så tycker jag att ni ägnar er åt en tacksam icke-diskussion. En abstrakt bild av allmän datorarkitektur och den moderna CISC-RISC hybriden som vi kallar för x86 får man på ett par timmar. Att bilda sig en uppfattning om koncept som registrar/stacken, segmentering/protected mode, branch prediction/out-of-order execution, ALU/FPU, SIMD, L1/L2/L3 cache kombinerat med lite praktiskt pillande för att få en känsla för olika operationers "kostnad" tar max ett par dagar [1].

Dessutom så tycker jag att det är hög tid att ta död på myten om hur C/C++ direkt mappar till den underliggade arkitekturen och därmed erbjuder bästa möjliga prestanda. Sanningen är ju att mappningen som dessa språk gör är ganska primitiv och inte alls tar hänsyn till parallellism eller cachen som är de dominerade faktorerna för prestandan man får ut av en modern processor. Det är just detta som gör att språk som t.ex. K (interpreterat APL-aktigt språk) totalt krossar C och C++ i tyngre matematiska beräkningar eftersom språket och dess implementation är optimerat med cachen i åtanke.

[1] The microarchitecture of Intel and AMD CPU’s
http://www.agner.org/optimize/microarchitecture.pdf

Kodar man för ren prestanda så får man självklart lägga ner tid på saker som SIMD stöd, cache-optimeringar och parallisering (med t.ex. MPI/OpenMP). För att en kompilator ska kunna generera SIMD/MIMD kod så måste språket vara designat för det från grunden och upp, vilket inga generella språk i dagens läge är. Skillnaden är som sagt att C/C++ låter programmeraren göra nästan vad han vill och inte inför några restriktioner.

Visst nytta, men sensorkontruktion är främst teknisk fysiks område, sedan kanske en från datateknik.. Kommunikation där emellan med t.ex profitbus, seriell(RS232), analog görs av programvaror som labview, där färdiga moduler bara finns att klippa in. Hur lätt som helst att göra ett lågpassfilter, t.o.m. min morsa klarar det. Däremot göra ett optimerat lågpassfilter i C, är inte lika lätt. Dock behövs det som sagt duktiga programmerare för att göra dessa moduler för oss ej likabra programmerare. För varför uppfinna hjulet flera gånger?

Obs att jag inte försöker värva folk till att inte läsa assembler, bara rätt val av programmering för rätt person. Att "alla" programmerare ska läsa assembler speciellt för persondatorer, tycker jag är lite som att tipsa html, flash, databasprogrammerare att läsa ett civilprogram.
*edit*
Samma sak är det med java och den nya classen scanner, det finns ingen mening att alla java-programmerare behöver trixa med någon buffert. Likaså det med att läsa och skriva till filer som har blivit lättare i java 5, om jag minns rätt.

Naturligtvis, man kan komma väldigt långt med C++, men det jag syftade på var en felaktig föreställning om att om att den abstrakta arkitekturen som C och C++ bygger på inte bara är en "generell" modell utan att den även skulle vara den "bästa" modellen ur ett prestanda perspektiv.

För en som kan lite om programmering skulle jag start förorda ett objektorienterat språk. Många programmeringsuppgifter som blir lite större blir mycket mer överskådliga och hanterbara då man programmerar objektorienterat.

Jag har programmerat väldigt mycket i C++ förrut men har alltid tyckt att vissa saker är lite omständiga. Speciellt så saknar jag ett bra standardklassbibliotek så man slipper göra alla saker själv. C++ är också ett "hack" då man programmerar objektorienterat. Många saker som t.ex referenser som borde underlätta programmerandet blir bara jobbigt med C++. Man kan bara lagra en referens i en C++ klass om man gör det precis då man skapar objektet, dvs i konstruktorns specialtilldelningssats. Vill man lagra en referens till en klass vid ett senare skede så måtse man antingen kopiera hela klassen eller skicka in en pekare.

Jag började programmera Java ordentligt för två år sedan eller så. Jag blev såld ganska snabbt. Alla konsitgheter som jag inte gillade i C++ fungerar som jag vill i Java. Referenser kan lagras i klasser, man har ett stort klassbibliotek som är smidigt att använda och garbage collectorn gör livet så mycket enklare då man slipper destruktorer och minnesläckor. Jag saknar verkligen inte .h filer heller. Jag skulle säga att jag utvecklar minst dubbelt så snabbt i Java som i C++.

Jag trodde som många att java skulle vara lite segt, men med de nya versionerna java5 och speciellt java6 så är java riktigt snabbt. Jag skulle vilja säga att om man inte speciellt tänker på att optimera när man programmerar så blir Java program oftast snabbare än C++ program. Det beror mycket på att det ofta blir väldigt mycket kostsamma minnesallokeringar i C++.

Den senaste utvecklingsplattformen från Sun för Java, Netbeans 6, är också väldigt trevlig. Grafiska applikationer är mycket enkelt att skapa med det och man får också mycket hjälp att göra vanliga operationer som att överlagra funktioner, skapa konstruktorer, getters, setters etc. Det kan man göra med en funktion som automatiskt genererar prototyper och funktioner.

Ni kanske har märkt att jag verkligen gillar Java. Det har gjort mitt jobb så mycket roligare

"Referenser" i Java är ju bara ett annat namn på pekare, är ju inte samma sak om en referens i C++.

"C++ är också ett "hack" då man programmerar objektorienterat."
På vilket sätt? På vilket sätt skulle Javas OOP modell vara bättre?

"Jag skulle vilja säga att om man inte speciellt tänker på att optimera när man programmerar så blir Java program oftast snabbare än C++ program."

Nej, knappast då Java uppmuntrar till en mer slösaktig programmeringsmodell med massor onödiga allokeringar och överanvändande av saker som exceptions.

"Det beror mycket på att det ofta blir väldigt mycket kostsamma minnesallokeringar i C++."
På vilket sätt gör man mer allokeringar i C++? I C++ kan man ju t.o.m. göra stack-allokeringar, som är mycket snabbare än heap allokeringar.

Angående OOP (ursäkta tjatet om assembler )

Förstår man hur processorn jobbar så lär man sig även OOP ( Object-oriented programming ) lättare. OOP är i grunden inget annat än att jobba på datamängder med ett visst gränssnitt (enligt mig). OOP går i princip och programmera mer eller mindre med de flesta språk.

När det gäller superdatorer m.m. så känner jag till att de ibland specialskriver kompilatorer. Missminner jag mig inte helt så läste jag någon sådan för Itanium när den skulle komma ut. Då kan kompilatorn optimera koden för aktuell processor men samtidigt bör programmeraren förstå hur den skall koda för att kompilatorn skall kunna optimera bra.

Tillverkar ett företag en ny processor idag så tror jag det är en nödvändighet att de även skriver någon eller några kompilatorer för den processorn så de får programvara.

Javas referenser är nästan samma som pekare jo, med skillnaden att du inte kan ändra på dom på samma sätt. Du kan även ha en referens till en array, säg arr, som t.ex ger dig längden på arrayen med arr.length.

Java har speciella keywords for t.ex interfaces (interface, implements) medan med C++ gör du multipla arv av abstrakta klasser. Det är i praktiken samma sak men det blir betydligt tydligare i Java koden vad du vill åstadkomma. Multipla arv är också en sak som jag inte gillar(koden blir väldigt grötig), jag gillar interface modellen bättre. I C++ måste man implicit skriva att man vill använda polymorfism med keywordet virtual fastän polymorfism är en av meningarna med objektorienterad kod. Det känns helt enkelt som att C++ kom till genom att man tog C och slängde på en massa nya funktioner istället för att tänka igenom det från grunden.

Skapande av objekt (med new) är snabbare i Java än i C++ p.ga av minneshanteringsmodellen. C++ anropar en malloc varje gång medan Java skapar objektet i sin egen heap utan att anropa malloc varje gång. Sök på nätet så får du se på sådana exempel. Jag hittade ett exempel på benchmark (tyvärr inte nyaste versionerna) som visar skillnader i allokering och metodanrop.
http://kano.net/javabench/index

Jag säger inte att C++ är dåligt eller så. Man kan göra allt i C++ (kanske t.om för mycket), det känns bara som att det börjar bli dags för ett nytänk med C++ standarden.

Att ett programmeringsspråk inte är lämpligt för vissa typer av programmering behöver inte nödvändigtvis betyda att språket i sig är dåligt eller felaktigt designat. Alla programmeringspråk bygger på kompromisser och i C++ fall handlade det om att försöka utöka ett språk för systemprogrammering (C) med ett utökningsbart (statiskt) typsystem som inte krävde runtimestöd. Alla de saker du räknar upp som svagheter hos C++ är just det som ser till att C++ fortfarande kan räknas som ett språk för systemprogrammering.

Visst finns det brister i C++ men i 99 fall av 100 så finns det en rimlig förklaring varför språket utvecklats som det gjort. För den som är intresserad så är det bara läsa boken "Design and Evolution of C++" för få reda på detaljerna.

Ska man klaga på något så är det att folk fortfarande är utomordentligt dåliga på att förstå att projekt med olika ekonomiska och tekniska förutsättingar faktiskt kräver olika sorters programmeringsspråk.

Håller fullständigt med dig. Olika språk för olika projekt. Ska man göra systemprogrammering är det helt klart C eller C++ som gäller (eller assembler om man är lagd åt det hållet). Att jag gillar Java för allmänna program håller jag dock fast vid. Det är enkelt att utveckla i och är portabelt och faktiskt väldigt snabbt nuförtiden.

Nej, new är inte alltid snabbare i Java än i C++. När Java väl allokerar på heapen är det långsammare. Jag betvivlar dock inte att det går snabbare i medel. Det är inte särskilt svårt att optimera med en egen heap om man kan slösa med minnet.

Problemet är dock att Java tvingar användaren att använda heapen hela tiden. Även om Javas heap är optimerad så är den fantastiskt mycket långsammare (i magnituden 10 000) än att allokera på stacken i C++.

Swing är ett annat problem med Java, det är väldigt långsamt i jämförelse med t.ex. Win32API applikationer.

Har du testat Java 6, det verkar vara mycket snabbare på alla plan än java 5 och äldre. Jag har inte haft några problem med att swing är långsamt med det.

Sen det där med minnesallokeringen. Jag skulle vilja säga att din siffra 10000 gånger långsammare är falsk. Enligt IBM tar en allokering i java i storleksordningen 10 instruktioner. Sen så har faktiskt java 6 stackallokering. Det kallas escape analysis (se länken).

http://www.ibm.com/developerworks/java/library/j-jtp09275.htm...

Att allokera ett objekt i java kan vara lika snabbt som att utföra en addition. När något triggar en collect så kan det däremot gå åt lite tid, men den kostnaden amorteras ju över många allokeringar. Dessutom är allokeringar i Java inte alls alltid heap-allokeringar eftersom kompilatorn kan använda stackallokering för lokala object (escape analysis).

En fördel med C++ är dock att man själv kan sköta sitt minne och återanvända tidigare allokerat minne.

Swing är säkert snabbare i Java 6. Jag använder i regel inte Java applikationer så jag vet inte.

Min siffra kom från en egen testbänk som jag skrev för något år eller två sedan. Var antagligen Java 5 (Linux, Suns VM), kommer inte ihåg vilken version säkert. Jag vet inte hur många allokeringar man måste göra för att komma upp i ett snitt på 10 cykler per allokering, men det måste vara många fler än jag gjort. Faktum är att den första allokeringen som utfördes av benchmarkprogramet tog i storleksordningen 100 000 cykler (sedan gick det snabbare). Detta var inte under en körning utan utan i medel efter en många körningar av benchmark-programmet. Sedan kan man hävda att det skall ta 10 cykler. Under mitt dåvarande Linux-system var det inte tal om de hastigheterna. Möjligt att det är annat med Java 6, jag har inte testat.

Även om Java VM kan allokera ett objekt på stacken under vissa förhållanden finns det inget sätt att explicit tvinga att ett objekt allokeras på stacken.

Om du gjorde ett sånt test så hade förmodligen inte koden JIT kompilerats. Varje gång du startar om ett program så är det okompilerat. Default för java SE är nånting i stoleksordningen 1500 anrop innan det kompileras, men det kan man ställa om ifall man vill.

För att göra ett test som bättre visar hur det fungerar så ska man köra flera loopar i programmet istället för att starta om det eftersom koden då är kompilerad.

Att objekt är lokala och kan stackallokeras är inte något ovanligt. Dessutom så stackallokeras ju alla lokala variabler som innehåller primitiva datatyper.

Antagligen så körde du klient-versionen och det i tolkat läge. Den maskinkod som server-versionen av jvm'en genererar efter att koden exekverats tillräckligt länge är en helt annan sak.

Benchmarking är svårt, speciellt för dynamiska språk, så man bör nog vara försiktig med att dra slutsatser från dem om man inte har väldigt bra koll.

edit:
Jag gissade inte när jag sa att allokering kan gå lika snabbt som en addition. Faktum är att med en bra garbage collector så är heapallokering just en enda heltalsaddition. Det här stycket förklarar skillnaden mellan heapallokering i C++ och i Java:

från http://www.javacoffeebreak.com/articles/thinkinginjava/abitab...
You can think of the C++ heap (and a slow implementation of a Java heap) as a yard where each object stakes out its own piece of turf. This real estate can become abandoned sometime later and must be reused. In some JVMs, the Java heap is quite different; it's more like a conveyor belt that moves forward every time you allocate a new object. This means that object storage allocation is remarkably rapid. The "heap pointer" is simply moved forward into virgin territory, so it's effectively the same as C++'s stack allocation. (Of course, there's a little extra overhead for bookkeeping but it's nothing like searching for storage.)

edit2: en annan fördel med garbage collection i ett språk som Java är att objekten kan flyttas och därmed packas ihop på ett sätt som optimerar cache-användningen. Detta är svårare för garbage collectorn att göra i C++ (och görs normalt sett inte alls utan GC).

---

Snabbare 1 ms hit o dit. I vissa lägen kan det avgöra. Men en som vill lära sig programmera bör först lära sig programmera inte vad som är 1 ns snabbare än det andra. Lär man sig tänkandet i ett språk är det inte så vårt att övergå till ett annat. Då det är samma sak för det mesta förutom annan syntax.

Och sen finns det inget språk som är bäst. Alla används i olika situationer.
Det är som att säga att Tyska e bättre än Ryska. Om du är i "Rysk-miljö" hjälper dig inte att du kan tyska. Sen finns det språk som är svårare än andra.

Känns som folk försöker komma med sina "makalösa kunskaper" till en som vill börja programmera för att han är intresserad utav det. Ni pratar om stack och gc, vad jag tror e att trådskaparen skiter i detta nu. Han vill lära sig programmera och vill veta vilka språk det finns. Ni skapar språk krig.

Jag håller med delar av tidigare talare Sockan. Man bryr sig inte om att allokeringar på heapen är långsammare i Java än C++ när man ska välja mellan dem. Det som är relevant är i så fall att den ena av dem har en garbage collector medans den andra ger friare minneshantering och kräver således lite mer förkunskaper för att komma igång med.

Ursäkta att jag drar upp den här tråden igen men jag testade just lite Ruby för första gången och det verkar vara ett väldigt trevligt och snyggt språk. Tänkte bara instämma med tidigare inlägg som rekommenderade det.

Inte en chans. C++ har visserligen tappat mycket mark i vissa områden de senaste tio åren, särskilt där prestandan inte är kritisk och kortare produktionstid väger tyngre (tid är pengar). De språk som "stulit marknadsandelar" från C++ är framför allt Java och C#. Men C++ kommer att leva vidare. Som du säger så är det fortfarande förstahandsvalet för spelprogrammering. Men även om ett bättre språk (och fullvärdiga bibliotek) för prestanadakrävande program skulle dyka upp imorgon, så skulle inte C++ försvinna på ett bra tag i alla fall.

Tänk på att det fortfarande finns COBOL-system i drift som kräver COBOL-kunniga programmerare, och COBOL hade sin storhetstid på 60- och 70-talen. Oavsett vilka nya trender och språk som dyker upp så kommer det säkert finnas behov av C++-kunnigt folk i minst 50 år till. Så gå ur tiden kommer det inte att göra.

Tja, Pascal är ett. I vilket fall har man i Pascal manuell minneshantering, och möjlighet att spränga in assemblykod där man tycker det passar. Men C är ett bättre val än Pascal för maskinnära kod i åtminstone 9 fall av 10.