Vill lära mig programmering! HJÄLP!

Åja, man behöver ju inte hålla på med minneshantering bara för att man kodar C++. Om något är det väl trevligt att ha möjligheten att rota lite djupare i systemet när man väl når en sådan nivå att det börjar bli aktuellt.

Jag vill nog mena på att man först bör ställa sig frågan vad man vill koda, och till vilka plattformar man vill koda, och sedan bestämma sig för ett språk. Visst, Python är väldigt lätt att lära sig vad jag förstått, och det är relativt kraftfullt, men man är i princip låst till de vanligaste plattformarna. Är man bara ute efter att nå resultat snabbt, och nöjer sig med att skriva programvara för de vanligaste plattformarna kan det vara ett alternativ.

Fikar man efter att på sikt jobba som kodapa är det väl Java eller C# som gäller i nuläget. Har dock ingen koll på vilken kunskapsnivå man måste besitta, eller hur lång tid det tar att nå dit, för att vara anställningsbar.

För min del var C++ det givna valet, då jag inte är särskilt intresserad av att skriva programvara för vanliga datorer, utan är mer inne på lite obskyrare plattformar. Jag tror inte det finns något annat språk som är lika versatilt och användbart när det kommer till den saken, ja, givet förstås att man inte har fritid och brains nog att lära sig assembly för de plattformar man är intresserad av :>

Du har förstås helt rätt i att inlärningskurvan för C++ är något brantare än språken du föreslår, men det är långt från någon oöverstiglig mur ens för den som aldrig kodat förr. Är man seriös med att vilja lära sig programmera, har lite tålamod, och inte förväntar sig att kunna uträtta storverk efter ett par veckor, så grejar man det utan problem.

---

TS, känner du dig sugen på C++ är det en baggis att testa på. Nu känner jag inte till några svenskspråkiga resurser för C++programmering, men det finns många bra engelskspråkiga dito. Här är ett par sidor jag använder som referenser, som också har nybörjartutorials:

http://www.cplusplus.com
http://www.cprogramming.com

Det är nog en bra idé att börja koda i en IDE (hehe), exempelvis Code::Blocks. Den är gratis, löjligt lätt att confa upp, relativt kraftfull, och innehåller inte en massa för nybörjaren förvirrande grejer som är fullständigt onödiga för den som inte håller på med rent enorma projekt (hej Visual C++). På sikt, om du kommer så långt att du börjar bli avancerad, kan du sedan enkelt byta miljö om du känner för det, språket du skriver är fortfarande detsamma. Code::Blocks räcker dock väldigt långt för de allra flesta. Du behöver bara installera den och göra lite grundläggande konfiguration (tar sisådär 5 min), så är du igång och kan koda.

Vidare är det inte så dumt att komplettera upp med en pappersbok, dels för att få programmeringsuppgifter såhär i början tills du kan börja koda sådant du vill koda, och dessutom som referensverk för framtiden. Jag gillar C++ Direkt av Jan Skansholm, men det finns en massa andra bra böcker också. Det är ju en smaksak det där, så det kan vara bra att investera lite tid och energi i att hitta en som funkar för dig.

Även jag skulle rekommendera Python. Det är lätt att börja med och du kommer in i tänket. När man väl lärt sig ett språk är det lättare att lära sig andra. Det viktigaste är att man kommer igång och att man inte kör in i nån bergvägg i början.

Utveckla med konkreta exempel. Varför suger C++? Varför bör de övriga språken du listar undvikas? Vilka är deras tillkortakommanden?

Oj, det där är ju helt beroende på vad det är frågan om för ECU, och på vilken nivå du vill rota i det. Det kan vara allt från att sitta i något program och mappa/ändra driftsparametrar från menyer, till att knacka assembly om du vill ändra ECU:ns funktion i grunden.

Är du ute efter att chiptrimma är det frågan om det förstnämnda, dvs ingen programmering alls i den bemärkelse ordet har i den här tråden. Det jävligaste där är väl egentligen att få tag i programvaran du behöver.

Vill du hålla på med det från grunden kan du ju kolla på Megasquirt och liknande projekt, och modifiera koden till dem efter behov.

Mjo, obviously, det finns inte så värst många andra skäl till att man skulle börja fippla med ECU:er. Men är det frågan om att typ bara mappa om klabbet, eller att börja rota i det hela på lite mer fundamental nivå som i att göra det på riktigt och därmed som delmoment vara tvungen att byta ut insprutningsdatorn/tändningscontrollern/yadda yadda helt och hållet? Var ligger ambitionsnivån?

Kan rekommendera dessa:

http://www.youtube.com/user/phpacademy/videos?view=1
http://www.youtube.com/user/thenewboston/videos?view=1

Ah, ett mycket bättre svar än ett ounderbyggt påstående att språken suger och bör undvikas

Kan tyvärr inte se filmerna, då jag f.n. sitter mitt ute på havet och surfar via världens tröttaste satellitlänk, men känner igen en del i artikeln där. Är dock långt från en så avancerad programmerare att jag kan nicka igenkännande på samtliga punkter, har helt enkelt inte hållit på med sådant som gjort att den beskrivna problematiken drabbat mig.

Sedan är väl frågan om det finns något språk som prickar rätt på samtliga punkter. Jag har förvisso inte så mycket referensmaterial, men det känns som att man skulle kunna hitta liknande listor om varenda språk som existerar. Sådant som är fördelaktigt i en situation kan vara en nackdel i en annan, och det är väl alltid någon form av tradeoff som måste göras i en ända för att vinna mark i en annan.

Om jag kommer ihåg det tar jag en kik på filmerna när jag kommer hem om ett par veckor.

Åhå, det gör du via en färdig programvara om det alls går, det är alltså inte frågan om någon regelrätt programmering.

Något förenklat kan du se mappen som en matris med värden på vilken öppningsgrad spridarna ska ha, och vid vilken vevvinkel spridarna ska börja spruta in (helt enkelt: hur mycket soppa ska motorn få, och när ska den få den), vid olika lastfall. Du har varvtal på ena axeln, och massflödet luft genom manifoldern på andra. Programmet i sig styr egentligen bara hårdvaran, interpolerar fram värden utefter mappen, och gör förhållandevis minimala korrektioner av bränsletillförseln utgående från lambdavärde och data från knacksensorerna om sådana finns. I realiteten är det nog något fler parametrar med i bilden på en modern bil, för att ytterligare kunna optimera förbränningen. Det som är intressant för dig att modifiera är hursomhelst mappen, inte programmet i sig.

Det skulle dock inte förvåna mig det minsta om det normala är att man helt enkelt byter ut den befintliga promen som mappen ligger lagrad på mot en dito med en aggressivare map, och sedan kompenserar programmet för eventuella individuella egenskaper hos varje motor mha lambda- och knacksensorer live. Man ska alltså inte ens vara säker på att det går att plocka ut chipet, skriva en ny map till det, och stoppa tillbaka det.

Det andra alternativet är att mappa manuellt genom att helt enkelt köra bilen i bromsbänk och försöka nå de driftslägen som mappen täcker, och sedan ställa in bränsleblandningen med lambdavärdet som referens. Om det nu går att ändra själva mappen live, så är det fortfarande frågan om att sitta i ett program på laptopen och ändra värden i detta, inte att sitta och skriva regelrätt kod. Detta tror jag dock generellt sett det inte går att göra på de insprutningsdatorer som sitter i vanliga bilar, utan det ska till customgrejer. Och även om det går ska du komma över programvaran för att göra det, och den lär tillverkarna/de auktoriserade verkstäderna hålla hårt i.

Vill du verkligen ha möjlighet att mappa exakt som du vill, är det nog dessvärre så att du måste byta ut hela insprutningsdatorn. Vill du utöver det hålla på med programmering som är relaterad till biltrimning, så är det antingen att designa din egen insprutningsdator, eller att involvera dig i något av de DIY-projekt som redan finns, som gäller. Det är dock inte direkt nybörjargrejer om man säger så.

1. I en naiv implementation: ja. Men det inget som hindrar att man använder sig av persistent data types precis som i Clojure. Avsett vilket så kommer det definitivt bli långsammare än att använda en mutable list och använder man C++ så bryr man sig ofta om effektivitet

2. I C++ finns det inget krav på att ha klasser bara för att få polyformism och har aldrig varit det sedan första versionen. Med s.k. "value argument templates" (template-parameters är ett värde och inte en typ, kom i slutet av 90-talet) så kan du även få samma flexibilitet som i Clojures "multimethod", d.v.s. foo(1) och foo(2) kan anropa olika funktioner, trots att de bara skiljer sig i värdet och inte typen som är "int" i båda fallen.

3. I Lisp och Lisp-dialekter då kan man direkt modifiera AST (Abstract Syntax Tree), mig veterligen kan inget annat språk detta, så ja: det finns saker du kan göra i Lisp med makron som inte går att göra i C++.

4. I C++11 kan du skriva remove({1,2,3}, 1) eller vector<int>({1,2,3}).size() (remove är inte medlem av "vector"). BTW: [1,2,3].remove(1) i Python är en meningslöst då det skapar en temporär list, tar bort element '1' ur denna och kastar bort resultatet. Men förstår poängen.

5. Du är långt ifrån den första som hävdar detta och för små och eventuellt medelstora program kan jag till viss del hålla med, beror på vad programmet gör. I stora program stämmer det helt enkelt inte. Visst kommer det vara en skillnad, men den kommer vara inte alls vara den "faktor 10 mindre" som vissa hävdar att t.ex. Python blir jämfört med C++. Skulle säga att skillnaden kommer definitivt vara mindre än en faktor 2.

6. Clojure är ett bättre val än Java i många fall där Java idag används, men det finns definitivt områden där Clojure helt enkelt inte går att använda men Java fungerar. Dels så tar Clojure program något mer RAM än motsvarande Java program, så program med väldigt stora data-set kanske inte fungerar. Sedan så körs program skrivna i Java snabbare än motsvarande program skrivet i Clojure (se nästa punkt) så prestanda kan bli för dåligt

7. Det är en åsikt och du får ha vilken du vill. Statiskt typade språk har tre stora fördelar. De exekverar snabbare då kompilatorn har mer information och kan därför göra mer aggressiva optimeringar (testa att lägg till type-hints i Clojure i en inre loop, det kan göra STOR skillnad). Uppenbara buggar där man t.ex. använder en sträng där det måste vara ett nummer hittas tidigare (lägre utvecklingskostnad då buggar hittas tidigare). Saker som "intellisense" är betydligt mycket enklare och mer träffsäkert om språket är statiskt typat, något Anders Hejlsberg, skapare av C#, väldigt ofta brukar tala om.

8. Mät och se att du har fel. Lägg sedan till type-hints till ditt program och se att det i många fall blir klart snabbare då kompilatorn kan optimera lite till, men det är fortfarande inte lika snabbat som Java. Här finns en sådan mätning , notera att många av Clojure programmen använder type-hints och ändå är 2-12 gånger långsammare än Java. Notera också att Clojure använder mellan 1-6 gånger så mycket RAM. Och då använder Java 3-50 gånger så mycket RAM som C++....

Jag skriver C "for a living". Anledningen till att vi kör C är därför att programvaran används i områden som är extremt prestandakritiskt och där vi och våra konkurrenter tävlar i att ha den snabbaste och mest skalbara (över många CPU-kärnor) programvara då kunderna är beredd att betala väldigt mycket pengar för att de i sin tur ska kunna bygga produkter som är snabbare och mer effektiva än deras konkurrenter. Tycker det är otroligt intressant och mycket av de problemen du tar upp kring mutable-state och liknande finns naturligtvis, men för att citera Rob Pike, en av grundarna av Go,
share by communicating, don't communicate by sharing
skriver man sitt program på detta sätt så är mutable-state en tillgång (ger snabbare program) och problemen undviks då data inte delas mellan trådar. Vad Clojure hjälper dig med är att på ett säkert och korrekt sätt kommunicera genom att dela och det ÄR svårt att göra rätt i ett språk med "mutable" state.

Ber om ursäkt för att denna tråd spårat ur lite.

Men som kompensation kan jag försöka skriva någon som är on-topic och luta mig lite på diskussionen ovan

En ganska fundamental del i designen av ett språk är hur typer hanteras. Exempel på typer är helttal, strängar och varje klass är en distrikt typ. Ett språk kan vara "stark" eller "svagt" typat, det kan också vara "dynamiskt" eller "statiskt" typat. Ibland ser man att folk blandar ihop dessa koncept och bara talar om svagt/dynamiskt typade språk som samma sak och starkt/statiskt typade språk som samma sak, vilket är nonsens.

Statiskt typade språk verifierar att källkoden uppfyller alla krav på att en acceptabel typ används i alla anrop och tilldelningar vid kompilering

Dynamiskt typade språk verifierar att en acceptabel typ används när programmet körs.

Ett starkt typat hindrar dig som programmera från att använda "fel" typ. Om funktionen vill ha ett heltal och du skickar med flyttalet 1.0 så kommer det inte accepteras då dessa två har olika typer.

Ett svagt typat försöker konvertera sina argument till något som "verkar vettigt" om det inte är rätt typ från början.

Som vanligt är saker och ting inte svart och vitt. Språk är oftast endera statiskt typade eller dynamiskt typade, men starkt/svag skalan är väldigt flytande.

Några exempel:
Python, Clojure: dynamiskt & starkt typat
1 + "10" bli fel, listor av typen [1, "10"] är inga problem

JavaScript, Perl, TCL: dynamiskt & svagt typat
1 + "10" = 11, listor av typen [1, "10"] är inget problem

C++, C#, Java: statiskt & starkt typat
1 + "10" kompilerar inte, listor av typen [1,"10"] går att få till men blir krånligt då man måste gå via en gemensam typ eller via en typ som kan innehålla 1 och "10" på något sätt (finns bibliotek för detta för C++, t.ex. boost)

C: statiskt & relativt svagt typat då pekare till alla typer alltid kan hanteras som pekar till okänt, void*, och void* kan tilldelas till pekare av vilken typ som helst...
1 + "10" kompilerar inte, listor av typen [1,"10"] är lite svårt att prata om då C inte har listor som del av språket, går inte att skapa en array som innehåller detta. Går alltid att skapa en lista som har element av typen "void*" och då fungerar det ju.

Sedan har vi Go... Det är rent formellt statiskt & starkt typat, men språket hanterar konceptet "interface" på ett väldigt annorlunda sätt. Personligen har jag inte använt Go speciellt mycket ännu, men av det lilla jag testat måste jag säga att språket verkar briljant i hur det löst problemet. I Go så finns inga klasser och inte typ-hierarkier. En typ implementerar ett givet interface om typen har alla metoder som ett visst interface innehåller. Resultatet av detta är att man får polymorfism, man får statisk typ-check, men man kan ändå programmera i stort sett på exakt samma sätt som i dynamiskt typade språk som t.ex. Python och Clojure! Man kan också jobba med objekt på samma sätt som i OOP-språken (C++, Java, C# m.fl)!

Vilket som passar dig bäst går inte att säga, beror väldigt mycket på vad du vill göra. Men efter att skrivit ett brandtal om Go så vill jag nog ändra min rekommendation från Python till Go. Du behöver ju inte ens installera något för att börja lära dig, länken jag listade ovan, d.v.s http://golang.org/ låter dig skriva och köra Go-program direkt i din webbläsare. Naturligtvis kan du installera Go på din dator också, finns för gratis nedladdning för Windows, Linux och OSX.

Kolla Mr1.buying

Han förklarar allting, väldigt lätt att förstå, många programmeringsspråk, på svenska.

Lycka till!