Forumet - Programmering

Programmering

8173 0 193
Tja, 40 minuter per dag är inte så mycket om du tänkt lära dig någonting ordentligt. Ska du lyckas skapa någonting och lära dig någonting mer beständigt så bör du nog utöka varje session till någon timme i alla fall - sedan behöver ju inte nödvändigtvis hålla på varenda dag.

Vad du ska börja med beror lite på vad du vill göra, vad du har för förkunskaper, och vilka verktyg du har tillgång till. Om det är allmän programutveckling du vill syssla med så skulle jag personligen rekommendera att du börjar med Python. Har du lite pengar att lägga ut så skulle jag rekommendera ​​den här boken. Annars finns den här boken att tillgå gratis.

När det gäller vad du ska börja med så rekommenderar jag dig inte att göra som så många andra och tro att du genast ska skriva en grafisk instant messenger, eller nåt. Börja i liten skala. Skriv ett program för att räkna ut hur mycket växel (och i vilka valörer) du ska få efter ett köp. Ett program för att validera personnummer. Ett program för att hitta alla palindromer under 1000000. I början bör varje program du skriver kunna färdigställas inom några timmar, så att du inte tappar suget.

När du väl har fått hygglig koll på språket, samt den logik som krävs vid programmering, så kan du kika på PyGame om du vill ha något lite roligare att jobba på. Jag själv finner att det är väldigt stimulerande och lärande att göra små spel.

Vill du ha fler idéer på övningar så kan jag säkert stå till tjänst.
Börja med Haskell, inte Python. Med Haskell får du lära dig att strukturera dina program bättre redan från början. (Fun fact: Haskell är det språk som först lärs ut till datavetare på Chalmers, och används i många mer avancerade kurser där.) Det är dessutom ett till strukturen enklare språk än Python. http://learnyouahaskell.com/ är en tutorial avsedd för nybörjare som är väldigt pedagogisk och lättläst.

Spana också in:

karleksproblem:

Jag kanske inte har tid...träningar ständigt och samt läxor


Att programmera är inte som att gymma, i att om du spenderar en liten stund om dagen med det så ser du dina muskler växa konstant. Det är mer som att spela ett instrument; genom att öva lite varje dag så kan du lära dig att spela, men ska du bli duktig så måste du ha ett genuint intresse och vara villig att spendera mycket tid med det.
Åtta:

Att programmera är inte som att gymma, i att om du spenderar en liten stund om dagen med det så ser du dina muskler växa konstant. Det är mer som att spela ett instrument;


Jag spelar 3 instrument och jag tränar så jag borde kunna det... :P

Nej men allvarligt...jag är 13 och jag vill lära mig så mycket jag kan nu, sedan kanske jag fortsätter med det en längre period[smile]

Men tack för svaren [smile]
Ankan3:

Visualstudio 2005 eller C++ som det ochså kallas.


C++ är ett programspråk. Visual Studio är en IDE. De är två vitt skilda saker.

Bajwa:

åtta vad är skillnaden med en hacker (inte cracker) och programmerare?


En hacker är ett extremt vitt begrepp om någon som söker kunskap eller förbättring av sitt intellekt eller en produkt genom att t.ex. ta isär, bygga eller ändra någonting. T.ex. skulle man kunna kalla någon som fixar buggar i ett ljudsystem för en hacker. Eller någon som rootar en smartphone för att kunna bygga någon ny applikation. Som sagt, det är ett extremt vitt begrepp.

En programmerare är någon som programmerar någonting. Varför personen gör det är irrelevant. Precis som en målare är en person som målar, oavsett om personen gör det för att täcka en husvägg eller för att täcka en tågvagn med grafitti.
Jag tycker du ska börja med Java. Bra att komma in i objektorienterad programmering med en gång. Använd dig av Eclipse så kommer det bli mycket enklare. Dock är dina 40 minuter per dag på tok för lite. Räkna med minst ett par timmar per dag. Kom även ihåg att det inte bara handlar om att lära dig att skriva kod, du måste även behärska mer avancerade algoritmer och en hel del matematik. Även bra språkkunskaper behövs eftersom det mesta du kommer finna inom ämnet är på engelska.
Lyssna inte på köttfärssås, HobGoblin eller Ankan3; de har bevisligen ingen aning om vad de pratar om. Jag skulle som sagt först och främst rekommendera Haskell, därefter F#, Python eller C#, i den ordningen.

HobGoblin:

Jag tycker du ska börja med Java.


köttfärssås:

Netbeaans, Java. Enkelt språk som troligtvis kan göra allt du vill göra med det.


Ett överkomplicerat, föråldrat skitspråk, menar du? Ett hett tips är att hålla sig så långt bort från Java som möjligt.

HobGoblin:

Bra att komma in i objektorienterad programmering med en gång.


Direkt skadligt snarare, speciellt om man gör det genom Javas idiotiska vanföreställning om att OOP är The One True Way.

Ankan3:

Visualstudio 2005 eller C++ som det ochså kallas.


Ankan3:

Sök på google på C++ for dummies och välj en sida som heter blinkenlights.


Herregud, nej! Det finns få språk som är tardigare än Java, men C++ är ett av dem.
Gentlernen:

Ett överkomplicerat, föråldrat skitspråk, menar du? Ett hett tips är att hålla sig så långt bort från Java som möjligt.


Överkomplicerat? Finns massa färdiga metoder som gör det lättare.[wink]

Gentlernen:

Herregud, nej! Det finns få språk som är tardigare än Java, men C++ är ett av dem.


Bägge är de mest använda inom spelbranchen osv.
köttfärssås:

Överkomplicerat? Finns massa färdiga metoder som gör det lättare.[wink]


Ja, Java har ett enormt klassbibliotek. Det ändrar inte på det faktum att språket är överkomplicerat och gör sitt bästa för att vara ivägen. Som ett exempel, hur bär du dig åt för att generera alla primtal i Java? Det är en rad kod i Haskell:
primes = go 2 where go n = n:filter (\a -> a `mod` n /= 0) (go $ n+1)


Antalet buggar per kodrad är konstant oavsett språk; vill du skriva buggfri kod ska du skriva så få rader som möjligt, någonting som är omöjligt i Java om du jämför med moderna språk. Och det är bara en liten del av Javas fail. Jag har inte tid att skriva mer om det just nu, men jag kan skriva några sidor om det senare om du är intresserad.

köttfärssås:

Bägge är de mest använda inom spelbranchen osv.


Det finns en enda anledning till att C++ alls används till nya projekt idag: prestanda. Java används överhuvudtaget inte, och C++ kan nog vara på väg ut tidigare än anat.
Åtta:

Som sagt, det är ett extremt vitt begrepp.


kan också vara en som bygger om sin brödrost till en limpistol. MacGyver är hacker [party]

sylar:

C är ett bra språk att kunna också. Det är bra att veta hur saker fungerar på lägre nivå så att man inte bara snöar in på högnivåspråk.


håller med här :P

Gentlernen:

men jag kan skriva några sidor om det senare om du är intresserad.


do it!
ankzor:

gärna[smile] Har egentligen bara läst JAVA och assembler så har ej mkt att jämföra med.


Det var ganska vitt skilda saker det, hur kommer det sig att du inte hållit på med C om du jobbat med assembler?

Anyway, det finns ett antal problem med Java, men här är de (IMO) största.

1. Typsystemet. Har du noterat att du precis alltid är tvungen att deklarera vilken typ allting har i Java? Du kan inte använda ett heltal utan att deklarera det som Int eller Integer, du kan inte använda en funktion utan att deklarera dess returtyp, etc. Det beror på att kompilatorn är korkad. Faktum är att det vore fullt möjligt att använda type inference, dvs. att avgöra vilken typ ett uttryck har beroende på dess beståndsdelar. Betrakta följande kod:
int a, b = 27;
String str = "hej tomtegubbar";
System.out.println(a + b*str.length());

Varför behöver vi tala om att a och b är heltal, och att str är en String? Det framgår klart och tydligt att str måste vara en String, eftersom vi tilldelar den "hej tomtegubbar." Likaså måste b vara ett heltal eftersom vi tilldelar 27 till b. Slutligen ser vi att även a måste vara ett heltal, eftersom vi adderar a till ett annat heltal. Detta bidrar kraftigt till nästa punkt, nämligen...

2. Javakod är pladdrig. Du måste skriva väldigt mycket Java för att åstadkomma någonting. Ta t ex Haskellkoden jag postade ovan för att generera alla primtal - hur lång är motsvarande kod i Java?

3. Allting är ett objekt. I Java är allting ett objekt. Fristående funktioner är inte tillåtna. Detta är ett stort problem, eftersom objektorientering inte alltid är optimalt, eller ens lämpligt, att använda. Ett praktexempel är Math-klassen; en hel hög med matematiska funktioner som egentligen borde varit fristående, men istället måste klumpas ihop i en samlingsklass full av statiska metoder.

Allting är ett objekt-mentaliteten leder ofta till överkomplicerade
program fulla av Factories, Managers, Singletons och andra spännande designmönster vars främsta uppgift är att kompensera för det faktum att du inte kan använda funktioner. Inte nog med att du skriver mycket mer kod för att åstadkomma samma sak du kunnat göra med en enkel funktion, du flyttar dessutom runt funktionaliteten så du måste läsa igenom 5-6 klasser bara för att få veta vad som pågår. Recept för buggar!

Detta innebär också att idéer som högre ordningens funktioner, dvs. att använda funktioner som argument och returvärde för andra funktioner, blir omöjligt. Varför är detta dåligt? Betänk följande kod:

for(int i = 0; i < numbers.length; ++i) {
numbers[ i ] = numbers[ i ] * numbers[ i ];
}

Ganska enkel kod; vi går igenom en array och utför någon operation för varje element i den. Dock finns ett problem med den här koden: vi har blandat ihop två fundamentalt olika uppgifter - att iterera genom en array och att kvadrera ett tal. Hade Java haft ordentligt stöd för funktioner hade vi istället kunnat göra såhär:
int squareIt(int n) {
return n*n;
}
forEach(numbers, squareIt);

Vi har generaliserat funktionen "gör någonting med varje element i en array," och kan därför återanvända den. Koden blir dessutom kortare och klarare, och därför lättare att både skriva och läsa.

Detta kanske ser fånigt och onödigt ut med dessa småexempel, men den verkliga fördelen kommer när man bygger större system: kan man generalisera koncept till funktioner kan man sedan sätta ihop dessa småfunktioner till större funktioner, utan att skriva en massa limkod runtikring.

4. Generics. Från början hade Java inte generics, dvs. du kunde inte säga ArrayList<Integer> a = new ArrayList<Integer>();. Istället använde du helt enkelt ArrayList a = new ArrayList(); för att få en ArrayList som kan innehålla precis vad som helst. Detta ledde helt uppenbart till program som inte var typsäkra (eftersom du förlorade all typinformation när du stoppade in ett objekt i din ArrayList) och därför både farliga och långsamma. Farliga därför att om du anropar ((String)a.get(7))).substring(5, 10); och det sjunde elementet i a egentligen är en Integer så exploderar allting, och långsamma därför att programmet spenderar en hel massa tid på att casta objekt fram och tillbaka. Fr o m Java 6 (eller är det 5?) har Java stöd för generics, men de är implementerade genom type erasure för att inte bryta bakåtkompatibilitet, dvs. det är bara syntaktiskt socker ovanpå den gamla, osäkra strukturen. Det förbättrar visserligen prestandan genom att färre casts är nödvändiga, men går fortfarande relativt enkelt att lura.

5. Märkliga beteenden du inte kan förklara utan att vara expert på JVM. Ta t ex det här lustiga exemplet med autoboxing:
public class test {
public static void main(String[] args) {
Integer a = 127;
Integer b = 127;
Integer c = 128;
Integer d = 128;
System.out.println("a == b: " + (a == b ? "japp" : "nix"));
System.out.println("c == d: " + (c == d ? "japp" : "nix"));
}
}

Utan att kompilera och köra det, kan du lista ut vad programmet kommer att skriva ut, och förklara varför?

6. Konstanter existerar inte. Det är sant. Betänk följande:

class SomeClass {
private int foo = 0;
public void doSomething() {this.foo = this.foo + 1;}
}

class Outer {
public final SomeClass blah = new SomeClass();
}

Sansat beteende hade här varit att Outer.blah nu är konstant och inte kan ändras. Så är dock inte fallet; vi kan ändra värdet på Outer.blah genom att helt enkelt anropa Outer.blah.doSomething();. Bristen på konstanter gör det otroligt bökigt att skapa omuterbara datatyper, och eftersom data som kan förändras och andra exempel på stateful programmering (dvs. att en funktions beteende kan variera beroende på andra saker än dess indata) är en av de största källorna till buggar är detta naturligtvis väldigt problematiskt.

...och det är därför Java är skadligt och bör undvikas. C++ har några problem gemensamt med Java, utöver en hel drös egna, men de är så fint beskrivna i C++ FQA att jag knappast behöver skriva någonting om saken här.