Lära sig C språket?

Jag ser faktiskt den dynamiska typningen som en fördel för nybörjaren. Ett statiskt typat språk skulle hitta en del fel vid kompileringen, men den typiska lösningen för de programmeringsövningar man gör i nybörjarkurserna kan skrivas på 10 till 15 rader kod (utan att använda list comprehensions). I C++1[14] gör auto att man klarar sig utan de flesta av deklarationerna man var tvungen att skriva i tidigare versioner, men det blir inte riktigt lika enkla och snygga lösningar.

Skall man döma av vad jag sett brukar uppgifterna vara formulerade (eller tillrättalagda om du vill ha negativ klang) så att Pythons egna typer lämpar sig för lösningen. De inbyggda typerna tillsammans med den dynamiska typningen gör att man slipper en massa typdeklarationer och de blir ofta lite mer koncisa än motsvarande lösning i C++.

Beträffande uppgift 5 ovan uppfattade jag det som att det var en övning där man själv skulle skriva just en kö med en länkad lista. Är det inte lite fusk att använda sig av std::forward_list då? Gör man inte det borde väl lösningarna blir snarlika?

DD1320 är inte en "lär dig at första stegen inom programmering"-kurs utan handlar snarare om att lära sig olika datastrukturer och algoritmer. På den här nivå skulle jag inte tro att man har några större fördelar av att köra Python. Den stora nytta är i början när det finns listor, tupler och strängar utan att man behöver tänka på det.

@Garumental och @Wienerschnitzel

Håller med om att man måste skriva kod med tanke på att man läser den långt oftare än den skrivs, är därför det är totalt irrelevant om något går att skriva några rader kortare i ett språk jämfört med ett annat. Det erfarenhet visar är att explicit är bättre än implicit (trots att de förra typiskt ger lite mer kod).

Håller däremot inte med om att effektivitet är irrelevant. Dels betyder mer effektiv kod idag längre batteritid på mobila enheter och färre spenderade cykler i "molnet" (där tar man ofta betalat för CPU-tid). Dels ska man alltid lösa varje givet problem med ansatsen "do the simplest thing that could possibly work" (som vissa blandar ihop med "det första de kommer på"), min erfarenhet är att enkla lösningar kommer av att programmeraren förstår problemdomänen och enkla lösningar typiskt också är bland de mest effektiva (men uppenbart att många programmerare sovit sig igenom kurserna som behandlar algoritmer och abstrakta datatyper...).

Anta att er lärare hade rätt och effektivitet är irrelevant. Förklara då alla resurser som plöjts ner i JIT för Java, varför är "effektivitet" den egenskap Apple trycker hårdast på i Swift, varför startade Google ett projekt för ett språk som effektivt hanterar "concurrent programmering" (Go), varför försöker folk lura ut hur delar av program kan köras på GPUer, etc?

Skriver man program där effektivitet är irrelevant skriver man antagligen inget mer än lite klister mellan ett gäng middle-wares. Man har då istället spenderat resurser (pengar) på att inhandla middle-wares där utvecklarna typiskt lagt signifikant tid på att göra något effektivt, varför skulle man annars använda middle-wares?

OOP är definitivt ingen silver bullet, det passar väldigt bra till simuleringar, GUI-programmering och liknande. OOP är ren katastrof ihop med parallel programming och concurrent programmering (som inte är samma sak) då metodanrop är associerade med ett implicit tillstånd (objektet) och inte självklart hur det tillståndet ska hanteras mellan trådar (OOP trycker på inkapsling av tillstånd, parallel/concurrent absolut kräver explicit kunskap om hur data representeras och potentiellt modifieras). OOP har aldrig heller resulterat i speciellt återanvändbar kod, något som Erlangs skapare gillar att påpeka

"I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

Ser inte heller hur Java och C# skulle på något sätt skulle ha en signifikant högre abstraktionsnivå än C. Språk som Clojure, Haskell och Rust har definitivt en högre abstraktionsnivå, t.ex. omöjliggör språken race-conditions om man inte explicit åsidosätter det. Men lägger man till GC till C (vilket kan göras via bibliotek) så är det bara bristen på "boundary checks" och lite syntaktiskt socker (som inte alltid är en fördel, implicit vs explicit) som skiljer C från de andra.

OOP är ett sätt att strukturera sitt program, inte en egenskap i något specifikt språk. Förstår man OOP kan man använda det när det är vettigt även i C, både i form av polymorfism via arv (är lite syntaktisk lite bökigare än C++/Java/C#) och likt JavaScripts "prototype-based" polymorfism (klart enklare i C och den metod jag oftast använder).

@Darkboot

Om du kör huvudsakligen Windows, så tycker jag att C# är ok att börja med, eftersom det finns så automatiserade funktioner för att skapa ett fönster, lägga till text och knappar osv på en gång. Då får man snabbt resultat som syns och får lite hum om hur det fungerar.

Sen kan man rätt snabbt gå över och kika på C om man vill lära sig mer grunder och hur saker faktiskt fungerar med minne och grafikhantering osv.

Själv började jag med AMOS på Amigan och även lite Amiga-Basic, och gick senare lite kurser i C på Gymnasiet och Universitetet, samtidigt som jag körde AmigaE hemma för att kunna göra lite roligare saker som småspel och ritprogram med lite mer grafik och jag mest körde på Amigan hemma, med sitt fina PowerPC-kort och allt

Nu blir det inte mycket programmerat, men på jobbet om jag behöver något snabbt så är det enklast med C# just för att man får upp ett grafiskt gränssnitt så snabbt utan att behöva ha koll på att reservera minnen och själv jobba mot grafikkort osv.

@darkboot
Jag har försökt lära mig olika språk men aldrig riktigt greppat det, sen började jag med VB.net relativt nyligen och har lärt mig rätt mycket, just nu håller jag på med en krypterad chatt, viktigaste är att du själv känner att språket är kul och att du kan åstadkomma det du vill göra i språket.

I min åsikt, lyssna inte på vilket språk som är bäst, känn efter själv vad du känner är roligast.

Ni som säger att prestanda inte är lika viktigt idag, hur tänker ni då? Det är nu det verkligen är viktigt att skriva bra kod, och välja språk efter det. Hårdvaran utvecklas knappt längre (i jämförelse med 10 år tillbaka i tiden), hur ska man då kunna göra större och mer avancerade program om man inte strävar efter att skriva så bra och effektiv kod som möjligt?

Absolut. Men hur ser det ut om 5 år? Ska programutvecklingen stanna upp bara för att hårdvaruprestandan inte ökar med mer än ~5 % per år? Resurser blir större i högre takt än vad prestandan utvecklas idag.

Jag tror att vi kommer se en tid där det blir mer viktigt igen.

Framtiden har aldrig varit såhär intressant som den är nu, inom IT. Vi har pressat dagens teknik (läs: 1970s teknik) så pass långt att det måste utvecklas något helt nytt för att det ska hända något mer än förbättrad strömförbrukning en intjänad klockcykel. Detta är ytterst intressant och jag tror att vi som datavetare och systemutvecklare kommer att få vara med om en stor förändring inom de kommande 30 åren. Nu spårade detta ur lite, och jag känner att jag kan fortsätta snacka om sånt här in på småtimmarna, men det hör inte hemma där

Kommandes från embedded-sidan måste jag påpeka att det programmeras fortfarande en ryslig massar prylar där prestanda är minst lika viktiga som förr (mikrovågsugnen, ABS-bromsen, trafikljuset, fönsterhissen, ja i princip vilken pryl som helst som har en liten processor i sig). Om någon säger att prestanda inte är viktigt betyder de att de har desktop-skygglapparna på. Kliver vi upp till mobiltelefonerna betyder varje onödig instruktion som utförs kortare batteritid och kort batteritid har vi alldeles för gott om.

Jag kanske var lite otydlig.

Min kommentar var riktad enbart mot uttalanden om att prestanda är oviktigt. Jag menade inte att man måste programmera mobiltelefoner i C. Å andra sidan kan man fundera på hur effektivt Java egentligen är. Jag känner flera personer som kör en gammal GSM-telefon. Den kan inte alls lika mycket, men de behöver inte ladda den oftare än var tredje vecka.

PS. Jag tycker fortfarande inte att C är ett bra val för den som skall lära sig programmera. Väljer man ett språk med redan fungerande listor, tupler och strängar kan man fokusera på övningarna istället för att bråka med minneshanteringen i C. DS.

@Marowak: lite mer avancerade spel har typiskt sina prestandakritiska delar i C++ (C är idag rätt ovanligt i spel), även på mobilerna. I både Android och Windows Phone försökte man initialt skippa stöd för "native" utveckling, i båda fallen fick man släppa på detta (NDK introducerades i Android 1.5 och WP8 fick stöd för "native development").

WP7 visade väldigt tydligt hur viktigt C++ är för en sådan plattform, många tyckte OSet och de program som följde med WP7 (t.ex. webbläsaren) hade riktigt bra flyt. Problemet var att 3:e-partstillverkare kunde bara få motsvarande upplevelse i väldigt enkla applikationer och det visade sig att Microsoft själva skrev i princip alla sina egna program för WP7 i C++, inte "managed" C#.

En annan väldigt stor fördel för C/C++ på mobiler är att rent krasst så är detta de två enda språk du hittar som verkligen är cross-platform. Stora kodbaser som kan förväntas köras på flera OS-plattform, som t.ex. spelmotorer, är betydligt enklare att anpassa till resp. OS om de är utvecklade i C eller C++ då det idag inte finns ett större OS som saknar C++ kompilator och finns nog inget OS i någon kategori som inte har en C-kompilator.

Angående inbyggda system så kan dessa vara långt mer än de små och enkla system många initialt associerar med detta. Jobbar själv en hel del med "inbyggda system" där plattformen består av 2-4 socket Xeon E5 och massor med 10-100Gbit/s Ethernet portar. Många skulle nog kalla dessa för "servers" och linjen är nog rätt luddig, skillnaden här är att prestanda är absolut kritiskt då man har en last som måste kunna hanteras inom en viss tid (så skalning av enskilda transaktioner över flera CPU-kärnor är inte möjligt) och varje maskin måste kunna hantera en viss aggregerad last (separata transaktioner måste skala över kärnor) då det finns begränsning i hur mycket ström systemet kan dra.

Ett relativt vanligt krav är att man ska klara minst 10Gbit/s per CPU-kärna, det betyder upp till 14.4M paket per sekund eller under 200-250 klockcykler (~70µs) per paket i genomsnitt. Företag som Ericsson, Nokia, Huawei, Cisco m.fl. ställs alla inför liknade problem och inne på dessa företag hittar man massiva C-kodbaser, även nyutvecklingen sker typiskt i C. Kodbaserna räknas typiskt i tiotals miljoner rader kod, man har testat bl.a. C++ men erfarenheten är språk med mer komplicerade funktioner fungerar illa i system som är väldigt stora, med riktigt hårda prestandakrav och där väldigt många personer är involverade.

@anon81912: angående effektivitet så är min erfarenhet att det inte alls finns ett motsatsförhållande mellan enkel kod och effektiv kod. Skulle säga att oerfarna programmerare alt. erfarna programmerare med dålig domänkunskap har svårt att skriva kod som är både enkelt och effektiv, men förstår man sin domän väldigt väl så klarar man av att göra enkla (eng. simple) lösningar och steget till att även göra dessa till bland det mest effektiva lösningarna ligger i hur man modellerar/representerar data (extremt kritiskt för skalning över CPU-kärnor) och vilka algoritmer man använder.

Tittar man framåt så tvivlar jag att det blir mindre fokus på effektivitet, när företag allt mer flyttar in sina serverrum i "molnet" så får man en väldigt konkret koppling mellan effektiviteten på de program man kör och driftkostnaden då Amazon EC2, Microsoft Azure, m.fl. tar betalt efter hur mycket CPU-tid, hur mycket RAM och hur mycket lagringsutrymme man använder.

Säger däremot inte att man därmed ska skriva allt i C, t.ex. Java har sedan Java7 blivit helt fantastisk effektivt. Redan sedan 1995 pratade man om att Java (eller vad som helst som kör bytekod på en VM) i teorin kan bli lika snabbt (eller till och med snabbare) som C/C++. Tog nästan 20 år, men något gjorde man väldigt rätt i samband med Java7 för många saker är numera lika snabba i Java som i C/C++. Däremot kommer alltid språk med garbage-collector dra mer RAM (GC blir väldigt ineffektiv om VM inte får ha en hel del "slack" mellan när data slutas refereras och när den faktiskt skräpsamlas) och sakna hårda realtidsegenskaper. Så C/C++ lär knappast försvinna inom överskådlig tid.

@anon81912: Skulle inte använda orden "prestanda" och "LINQ" i samma mening, men förstår vad du skriver.

Tror inte riktigt vi diskuterar samma sak heller. I de flesta lägen är prestanda irrelevant (80/20-regeln), då ska man definitivt köra varianten att skapa en temporär sträng i ditt fall.

Jag menar på arkitekturnivå blir den enkla lösning väldigt ofta bland de mest effektiva. Man kanske måste använda en binärheap för att hålla reda på timeouts i stället för att bara ha dem i en lista, specifikt för C så finns väldigt många fall där man helt kan undvika allokera minne (vilket både garanterar att det inte kan gå fel p.g.a. out-of-memory, man kan inte läcka minne och det är mycket snabbare än dynamiskt minne).

Förutsätter man att alla är proffs lär projektet kantra rätt snabbt. Är just den insikten de som utvecklat riktigt stora och komplexa system gjort, där har slutsatsen blivit att enklare språk är att föredra även om det blir lite mer kod (och i praktiken är det betoning på lite, de skillnader folk hävda finns kanske stämmer på ett 10k rader program, vid >100k eller än mer programmerar man typiskt i väldigt domänspecifika APIer där det blir lika många satser i C som i C# som i Python). Jag debuggar tusen gånger hellre dålig C-kod än dålig C++ kod, i C är allt explicit vilket är ovärderligt när man ska förstå andras kod.

Vi hade (eller har fortfarande, men det vidareutvecklas inte lägre) relativt mycket Python-kod (jag var själv väldigt pådrivande i detta...), handlar om ~100k rader. Initialt fungerande det rätt bra, men med tiden (när de blev allt mer bekväm med Python) började vissa använda allt mer avancerade språkfunktioner. Att försöka förstå delar av den koden och än värre debugga skiten är idag en mardröm, har skrivit om det mesta nu i C++11 (relativt C-lik kod fast STL, closures och automatiskt minneshantering används, ingen OOP) och det är löjligt mycket snabbare, faktiskt mindre kod för tillfället (men beror nog mer på att man förstår problemdomänen bättre nu).

Här kan man vara jämföra Java med C#. Man ser ofta klagomål på allt som Java saknar, men hur många >1M rader kod projekt hittar man i C#? Java är mer lämpligt för riktigt stora projekt, inte trots att det är ett enklare språk utan just p.g.a. av detta.