Börja programmera?

AndreasC skrev:

Kan någon förklara för mig hur ett programmeringsspråk kan vara begränsat till endast vissa plattformar, i grunden handlar det ju bara om ettor och nollor iallafall.

Som redan sagts så kan koden vara OS-specifik. Dvs att man i sitt program använder sig av funktionalitet som operativsystemet levererar. Vidare så ser maskinkoden olika ut beroende på vilken processor som används, så det gäller för kompilatorn att översätta programmet till rätt instruktioner och med rätt instruktionssyntax. Exempelvis så har x86 och motorola liknande instruktioner, men med operanderna skiftade mot varann.

I Java och andra plattformsoberoende språk, kan programmen köras i en runtimemiljö så att själva koden ser lika ut oavsett plattform. Det skulle exempelvis vara helt möjligt att göra C-program på samma sätt, men det är inte särskilt effektivt så det är bättre att ge olika kompilatordirektiv för de olika plattformarna. Den koden kan endera kompileras direkt på den avsedda plattformen eller kompileras av en s.k crosscompiler för andra plattformar. (kod för exempelvis en MAC kan kompileras på en PC om den har en sådan kompilator) Men det ger i slutändan olika versioner av maskinkod från samma källkod, om källkoden inte innehåller annan plattformsspecifik fuktionalitet. Då får man ange olika alternativ i sin kod, alternativt göra olika versioner även i källkoden.

sebbz skrev:

Samtidigt kan man lära sig mycket programmeringsteknik med en bra bok i språket ifråga.. IMHO ska en programmeringsbok innehålla både ren språkteori (syntax osv) men även programmeringsteori.

Visst är det så :)

Men det är få böcker som tar upp båda sakerna och definitivt ingen som tar upp båda sakerna ur ett djupare perspektiv än grunderna.

PeW skrev:

Men det är få böcker som tar upp båda sakerna och definitivt ingen som tar upp båda sakerna ur ett djupare perspektiv än grunderna.

Mycket sant. Å andra sidan så kan man klura ut en hel del själv utifrån grunderna. Är man riktigt seriös ska man dock, precis som du påpekar, studera dessa ämnen fristående.

sebbz: Att beskriva syntaxen i C++ som en syntax som känns igen från andra språk känns förvånande för mig. Kan du nämna något språk utom C som C++'s syntax påminner om??? :q

PEW: Allmänbildningen i minneshanteringen kan, tror jag, lättare komma efter att man sett de första grunderna än innan. Naturligtvis är det olika för olika personer, var och en blir salig på sin fason... men pekare och minneshantering tillhör ju inte det mest intuitiva i programmering innan man fått kläm på det. Och hur bra kompileringsfelsmeddelanden får du eg. från assembler? Inte alltför uttömande föreställer jag mig? Ju mer kryptiska felmeddelanden man får ju svårare blir det ju... Dessutom: min kommentar on nördar gällde folk som idag programmerar "vanliga" program i Assembler för att de kan... inte den användning som språket ev. hade för 20+ år sedan.

AndreasC skrev:

Kan någon förklara för mig hur ett programmeringsspråk kan vara begränsat till endast vissa plattformar, i grunden handlar det ju bara om ettor och nollor iallafall.

Ett bra exempel på hur krångligt det kan bli är C. Beroende på vilken maskin du kör på kommer heltalsrepresentationerna: short, int, long (tror jag de heter??) att vara olika långa. Detta kan få överraskande konsekvenser om man flyttar ett program från en dator till nästa. Dessa tre heltalsrepresentationer skiljer sig alltid åt genom att ha olika många siffror "till sitt förfogande" (vilket innebär att det största och minsta tal som kan representeras i de tre typerna skiljer sig kraftigt åt.) Det speciella med C är att en short på en maskin kan vara kortare än en short på en annan maskin, och motsvarande för övriga typer. Om du flyttar ett program till en maskin som har lägre antal bitar att representera en viss typ i, så kan du plötsligt få overflow-problem. Dvs dina tal, kan plötsligt börja tolkas som andra tal...

Jag vet inte hur mycket du vet, så det kanske var jättelätt att begripa vad jag menar, annars kan du läsa detta exempel.
Låt oss säga att vi hade någon typ som bara var 4 bitar på en maskin och 5 på en annan. (Tror ingen typ är så kort, men som exempel betraktat...) Den vänstraste siffran är teckenbit: 0 för + och 1 för -.

Talet 1101 = 01101 = plus 2^3 + 2^2 + 2^0 = 13 på 5-bitars maskinen och
1101 = minus 2^2 + 2^0 = -5 på 4-bitars maskinen.
Alltså samma tal tolkas olika.

aasah skrev:

sebbz: Att beskriva syntaxen i C++ som en syntax som känns igen från andra språk känns förvånande för mig. Kan du nämna något språk utom C som C++'s syntax påminner om??? :q

PHP, till exempel :}. Fast jag förivrade mig nog lite, för jag kommer inte på så mycket mer.

Jag tror inte knepet ligger i att hoppa in i första bästa programmeringsspråket direkt om man vill bli en bra programmerare. Först och främst ska man nog skaffa sej en ordentlig förståelse om vad programmering handlar om samt därtill hörande ämnen.
Själv har jag läst programkonstruktion i tre delar där vi mestadels programmerade i SML. Påminner litegrann om haskell, som PeW nämde tidigare. Funktionell programmering.
Sista delen handlade om algoritmer och datastrukturer. Man märkte snabbt att programmering är så mycket mer än att bara kunna ett programmeringsspråk.

Mycket intressant tråd detta, men jag känner att det måste spinnas vidare på det Gein skrev. Jag tycker att det viktigaste programmeringsspråket av alla saknas... psuedokod! Även om det inte är kompilerbart, så är nog det en av de viktigare förutsättningarna en programmerare har (förutom det språk den programmerar i...) för att lyckas skriva ett dugligt program (även om koden inte innehar mer än 10 rader).

C++ lär antagligen vara det alternativ en "nyutbildad" programmerare väljer att använda om den vill att dens kod ska arbeta bra mot datorns hårdvara. För den skull är det inte sagt att C++ är det "bästa" programmeringsspråket. Där kommer förutsättningar och, möjligen, pengar ha en stor betydelse.

Det programmeringsspråk som är och kommer att förbli (förutsatt att inget revolutionerande sker) det snabbaste är maskinkod. Alla kompilatorer riktar in sig mot detta, men eftersom det finns ett flertal olika uppsättningar av instruktioner som en given processor kan förstå, så kommer högnivåspråks (C++, VB, Pascal för att ta dom kanske mest kända) kompilerade resultat(hastighet/effektivitet) att vara beroende av den plattform den är skriven för från grunden.

Psuedokod. Det är den viktigaste formen av programmering, eftersom vi människor saknar en bestämd uppsättning av instruktioner för att lösa ett bestämt problem.

Översättningen från psuedokod till programmeringsspråk är den intressanta biten och det är där programmerare skiljer sig ifrån varandra - hur bra lösningar dom kommer på, det sätt dom löser problemet på, det antal lösningar dom kommer på. Bra exempel på detta finns i mängder här på wF.

Nu känner jag att jag svamlat tillräckligt mycket om vad jag tycker programmeringsspråk är och kan ta mig till mods att svara på den egentliga frågan :)

Programmering
1 del Objektorientering
1 del Operativsystemsarkitektur
2 delar Logik
½ till X delar Fantasi

Vad jag tycker att mycket programmeringslitteratur inte belyser är vikten av att göra hög- och lågdesign när man utvecklar mjukvara!

Är det någon som kan tipsa om nåt bra? Jag har inte hittat än så länge..

PEW: Allmänbildningen i minneshanteringen kan, tror jag, lättare komma efter att man sett de första grunderna än innan. Naturligtvis är det olika för olika personer, var och en blir salig på sin fason... men pekare och minneshantering tillhör ju inte det mest intuitiva i programmering innan man fått kläm på det. Och hur bra kompileringsfelsmeddelanden får du eg. från assembler? Inte alltför uttömande föreställer jag mig?

Vi tycker olika :) ... Assembler är primitivt och avskalat, vilket ger en skolning i datorarkitekturens grundstenar, vilket å sin sida är mer eller mindre en nödvändighet för en bra förståelse till de högre språken och teknikerna. Varken assembler eller C är sämre än sitt verktyg (kompilatorn) vad det gäller felmeddelanden och det är inte representativt för språket i sig.

Salig och salig.. jag är glad åt att ha den grunden då det underlättat en hel del. Liksom att jag är glad åt att ha läst grundläggande linjär algebra nu när jag går fortsättningskursen i linjär algebra osv... speciellt när jag sett hur andra formligen kört fast i debuggern i C och C++ tack vare att de lärt sig "för mycket finesser" för att förstå grunderna. :)

Engine^ skrev:

Mycket intressant tråd detta, men jag känner att det måste spinnas vidare på det Gein skrev. ... Översättningen från psuedokod till programmeringsspråk är den intressanta biten och det är där programmerare skiljer sig ifrån varandra - hur bra lösningar dom kommer på, det sätt dom löser problemet på, det antal lösningar dom kommer på. Bra exempel på detta finns i mängder här på wF....

Nu känner jag att jag svamlat tillräckligt mycket om vad jag tycker programmeringsspråk är och kan ta mig till mods att svara på den egentliga frågan :)

Programmering
1 del Objektorientering
1 del Operativsystemsarkitektur
2 delar Logik
½ till X delar Fantasi

Visst är det sant att programmering är mycket mer än att kunna programspråk. Minst lika viktigt eller viktigare är lösningen som sådan. Å andra sidan kan man som ny inte få "tänket" om man inte lär sig ett språk. Man måste prova hur det funkar i praktiken, och den känslan kan man varken få genom att läsa algoritmer eller skriva pseudokod enbart. Att man sedan inte är en bra programmerare om man kan ett språk aldrig så bra om man inte kan något om algoritmer eller inte kan tänka i pseudokod är en annan sak, tycker jag.

Sedan: programmering måste inte ske med hjälp av objektorientering. Det beror på vad man skriver för program och hur stort det är. "Hello World!" i OO är enbart fånigt - så tillvida att det inte på något sätt utnyttjar den tekniken alls. Små program som inte använder sig av finesserna i OO kan lika gärna skrivas PO. De första programmen man tar på programmerandets bana är inte - om programmeraren är klok - några stora program. Att inte använda mer finesser än vad som behövs är ju en del i det man lär sig.

PEW - vi har olika åsikt om huruvida Assembler är ett bra nybörjarspråk. Det är allt. Och jag har inget emot att du har en annan åsikt... ;)

AndersC, oavsett vilket språk du väljer att börja med finns det två råd jag vill ge dig.

1. När du börjar programmera, bygg upp dina program efter hand. Skriv en liten bit, tex en funktion/procedur/metod i taget. Kompilera! Rätta tills det går igenom kompileringen. Skriv nästa bit. Kompilera! Rätta... osv. Det går i allmänhet mycket fortare i längden att ta tiden att skriva i småryck. För då vet du alltid att det var det du skrev senast som det var fel i. Om du skriver en A4 först och kompilerar så kan det vara fel på många ställen och att reda ut alla fel blir värre ju fler man har på en gång.
2. Om du får flera kompileringsfel på en gång, ta bara hand om det första. Kompilera om. Ta hand om det första. Kompilera om... tills du är av med alla. Skälet är att många kompileringsfel ger upphov till följdfel, som försvinner av sig själva när du fixar till roten till det onda.
   Lycka till med programmeringen! :)

aasah: Jag håller med dig i det du skriver och det kan väl liknas vid att lära sig att cykla. När jag skrev en del objektorientering, så tänkte jag inte att man skulle knappa ihop ett "Hello world!"... :OO

aasah->
AndreasC ställde sin topic som att han inte bara ville lära sig ett programmeringsspråk, utan han vill lära sig grunden för alla språk och de olika teknikerna. För att vara så generell som möjligt och betona grunden landar man i datorns arkitektur. Vidare så handlar långt ifrån all programmering om PC eller Mac... jag ser därmed inte hans topic som att han nödvändigtvis ska bygga coola spel med sitt första språk.

För mig så var assembler en bra första kontakt med programmering. Det behöver inte gälla för alla naturligtvis, men om man går lite längre och funderar kring det vettiga i upplägget som många skolor har så blir ivf jag fundersam. Dvs att de börjar med högnivåspråk och sen visar på lågnivåspråken för de som är intresserade. Många upplever detta som fel ordning. Och många av de som fastnat i pekarvärlden har gjort det pga att de inte gått lågnivkurser eller så har de inte greppat den ordentligt. En inte alltför ovanlig uppfattning är alltså att man bör gå från lågnivå och uppåt - inte tvärtom. Så om jag ska dra parallell med att cykla så kan jag väl skriva att man bör lära sig gå innan man lär sig cykla :p

Nedåt finns det en gräns i abstraktion. Uppåt kan man grotta in sig hur mycket som helst :)

Jag är beredd att hålla med PeW. Men jag skulle nog vilja göra det så att man samtidigt som man lär sig sitt första högnivå språk lär man sig datorns arkitektur, hur det man skriver påverkar systemet och vad man egentligen åstadkommer med sina tecken och tal som man pillar in i en fil och kompilerar.

Beror kanske på att man är ivrig? Man dör inte av att gå lite kurser som inte direkt ger ett resultat, ibland kommer inte resultatet förräns senare :)

Självklart, men intresset borde ökas om man ser ett resultat - annars kan det lätt bli så att man tröttnar på det man läser och sedan glömmer bort det. Man dör inte heller av att läsa om arkitekturen parallellt med programmeringen. ;)

Sant. Men med ett högnivåspråk som exempelvis Java, är arkitekturen dold vilket gör att steget mellan programmering och realitet blir stort. Att bara läsa om initiering av interruptvektorer eller relativ adressering utan att testa på riktigt (labba) kan det ju bli ännu mer avlägset.

Jaja.. har väl inget mer att tillägga annat än att världen inom datavetenskapen är stor och det finns åtskilligt att grotta in sig på :bire