Aldri programmert før - veldig innstilt på å lære meg Java. Hvilke bøker?

[DawnDusk]

Hei!

 

Jeg er blitt veldig motivert til å lære meg programmering, og jeg ønsker i den forbindelse å starte med Java. Hvis jeg velger å studere data og programmering, er det Java lærestedet vil bruke.

 

Men jeg har ingen tidligere erfaring med programmering. Som person er jeg en som ønsker å sette meg godt inn i ting, forstå hvorfor ting er som det er og hvorfor det skjer. Derfor ønsker jeg, hvis vi ser det i et langsiktig perspektig, å sette meg godt inn i Java.

 

Likevel, alt har en start. Noen som har tips til gode bøker? Som gir meg en god forståelse, men som også er laget for en uten tidligere erfaring.

 

Ser at den sticky tråden øverst anbefaler "Core Java 2", men håper å få flere erfaringer - både rundt denne og andre bøker.

 

Takk for hjelp! ;D

Endret 18. mars 2010 av DawnDusk

[Jann - Ove]

Sams teach yourself java in 21 days er helt grei; den gir en strukturert og fin innføring i Java. Engelsken er lettfattelig, og den går gjennom det meste du "må" få med deg.

 

Men om jeg var deg ville jeg vurdert et annet språk, siden det fins språk som lettere gir dyp forståelse og rom for utforskning av hvordan ting henger sammen. Jeg ville startet med Ruby om jeg skulle startet på nytt idag, det flyter mer naturlig, og den ultimate boken er tilgjengelig helt gratis."Pickaxe" eller Programming Ruby: The Pragmatic Programmer's Guide er en av de beste introduksjonene til et språk som fins, og et prakteksempel på flott teknisk skriving på engelsk - avansert men samtidig lettforståelig. Verktøyet "irb" gir rom for å rote rundt i språket mens det kjører, og det meste av Ruby-kode er både vakker og forståelig.

 

Hvilket språk som ditt eventuelle framtidige lærested bruker bør være 100% irrelevant for ditt valg av første programmeringsspråk. De fleste læresteder starter litt på bunnen igjen, og god programmering handler om mer enn å spesialisere seg i et enkelt språk. Det du lærer av strukturert og logisk tenking mtp programflyt vil kunne brukes i ethvert programmeringsspråk.

 

Velg et språk som virker gøy, og et språk som er lett å lære. Det fins mange gode alternativ, for å nevne noen: java, python, ruby, php, asp .net, c# +++

 

Velg et språk du får brukt til noe halvveis praktisk; kunne du tenkt deg å prøve deg på web-utvikling, velg et språk som egner seg til det, er målet gui-programmer, velg et språk som egner seg til det.

Endret 18. mars 2010 av Jann - Ove

[Unlimited LTD]

Støtter dette. Sam's Lær deg selv Java på 21 dager (Norsk ) brukte jeg selv for å lære java på egenhånd. Den gir en meget god bakgrunn, selv om den kan være litt utdatert på GUI biten. Holder litt mye på med gammel AWT eventbehandling, men det er bare en minimal del. Kan jo være greit å lære det også da.

[TorkilG]

+1 for Python

 

Java er ikke et spesielt godt første språk.

[GeirGrusom]

Hva er egentlig bedre i Python enn Java for nybegynnere?

[Noble]

Det viktigste er ikke hvilket språk du lærer deg, men at du forstår grunnleggende programmering. Du vil muligens falle tilbake til det første språket du lærte deg etter å ha prøvd litt etterhvert.

 

Vil anbefale C/C++ eller java. PHP er muligens også et bra alternativ, syntaksen er rimelig lik C/C++, men det er lette å lage noe "håndfast" slik at du ikke blir lei i begynnelsen.

[MailMan13]

Java er et utmerket første programmeringspråk, kanskje det beste.

 

- Java er typesterkt. Kanskje det aller viktigste.

 

- Java har en stilren, konsistent syntaks.

 

- Java er veldig objektorientert, både i språk og API. Det finnes ingen språk jeg kjenner som eksplisitt håndhever grunnleggende objektorienterte teknikker i like stor grad som Java gjør. C# kommer nært, men der er ofte konseptene pakket inn i syntaktisk fluff og .NET API'et har mye ballast fra gammle VB konvensjoner som ikke er like pedagogisk gunstige. I Java er alt rett frem objekter og typer, som er det man trenger å få kontroll på først.

[GeirGrusom]

C# kommer nært, men der er ofte konseptene pakket inn i syntaktisk fluff og .NET API'et har mye ballast fra gammle VB konvensjoner som ikke er like pedagogisk gunstige. I Java er alt rett frem objekter og typer, som er det man trenger å få kontroll på først.

 

Dette virker som du har tatt litt ut av lufta for en C# utvikler som meg.

[MailMan13]

Tja, kommer vel an på hvor mye du ligger i det.

 

I både winforms og asp api'ene har noen feller og ting som ikke er helt slik man ville designet det i dag med mye statiske klasser (MessageBox.Show() anyone?) og sideeffects (som hva i ****** som trigger registrering av __doPostback for å nevne en sentral og stygg en)

 

Reflection i bøtter og spann for å løse trivielle ting uten å måtte forholde seg til typer. Hver gang du tilordner noe til Datasource-property til en kontrol i winforms eller ASP er nesten alt som skjer i bakgrunnen reflection-hacks, implementert med det eneste mål at utvikleren skal slippe å forholde til dependency injection. Det var kanskje måten å gjøre det på i '98 da VB6 var state-of-the-art, ikke nå lenger.

 

Vil ikke si at det ene er bedre enn det andre i praksis, når utvikleren vet hva han/hun gjør, men i en læresituasjon er det anerledes.

 

Det er kanskje lettere å kjenne igjen en observer implementasjon når grensesnittene heter "FooObserver" og "BarObservee" enn om det er et eller annet i en autgenerert metode står += til et multidelegate.

 

Ikke det at C# ikke kan være like bra som Java, men det er mye i .NET rammeverket som ikke alltid er like pent. Slike ting synes jeg gjør Java pedagogisk bedre plattform enn enkelte sentrale deler i .NET er.

Endret 19. mars 2010 av MailMan13

[TorkilG]

Java er et utmerket første programmeringspråk, kanskje det beste.

 

- Java er typesterkt. Kanskje det aller viktigste.

 

- Java har en stilren, konsistent syntaks.

 

- Java er veldig objektorientert, både i språk og API. Det finnes ingen språk jeg kjenner som eksplisitt håndhever grunnleggende objektorienterte teknikker i like stor grad som Java gjør. C# kommer nært, men der er ofte konseptene pakket inn i syntaktisk fluff og .NET API'et har mye ballast fra gammle VB konvensjoner som ikke er like pedagogisk gunstige. I Java er alt rett frem objekter og typer, som er det man trenger å få kontroll på først.

 

Java er et fantastisk programmeringsspråk om man skal lære seg objektorientering, men når man skal lære seg å programmere er programmeringsparadigmen mer i veien enn til nytte. Det viktigste og mest motiverende er å få ting til å skje!

 

Dette er en potensielt veldig polariserende diskusjon som vi kan ta et annet sted, en annen gang.

 

Liker Daniel Liangs javabok best av de jeg har lest. http://java.sun.com/javase/6/docs/api/ kan også være nyttig

[GeirGrusom]

Tja, kommer vel an på hvor mye du ligger i det.

 

I både winforms og asp api'ene har noen feller og ting som ikke er helt slik man ville designet det i dag med mye statiske klasser (MessageBox.Show() anyone?) og sideeffects (som hva i ****** som trigger registrering av __doPostback for å nevne en sentral og stygg en)

 

Reflection i bøtter og spann for å løse trivielle ting uten å måtte forholde seg til typer. Hver gang du tilordner noe til Datasource-property til en kontrol i winforms eller ASP er nesten alt som skjer i bakgrunnen reflection-hacks, implementert med det eneste mål at utvikleren skal slippe å forholde til dependency injection. Det var kanskje måten å gjøre det på i '98 da VB6 var state-of-the-art, ikke nå lenger.

 

Vil ikke si at det ene er bedre enn det andre i praksis, når utvikleren vet hva han/hun gjør, men i en læresituasjon er det anerledes.

 

Det er kanskje lettere å kjenne igjen en observer implementasjon når grensesnittene heter "FooObserver" og "BarObservee" enn om det er et eller annet i en autgenerert metode står += til et multidelegate.

 

Ikke det at C# ikke kan være like bra som Java, men det er mye i .NET rammeverket som ikke alltid er like pent. Slike ting synes jeg gjør Java pedagogisk bedre plattform enn enkelte sentrale deler i .NET er.

Mye av det som ble skrevet for .NET 1.0 som fortsatt ligger igjen har mye tullete ting. Reflection funksjonene returnerer arrays istedet for IReadOnlyCollection<T> for eksempel, ettersom generics ikke dukket opp før i 2.0. Det er også mange forskjellige implementasjoner av Collections, som er en uting. Windows Forms er fullt av dette. Men Windows Forms er i stor grad erstattet av Windows Presentation Foundation for de aller fleste oppgaver.

 

Men Java er på ingen måte bedre enn .NET her. Swing er rotete, og ettersom java mangler delegates, lambdauttrykk og closures, er eventhåndtering mildt sagt verbost i Java.

[MailMan13]

Men Java er på ingen måte bedre enn .NET her. Swing er rotete, og ettersom java mangler delegates, lambdauttrykk og closures, er eventhåndtering mildt sagt verbost i Java.

Rotete vet jeg ikke, men verbost er det. Det kan være bra eller dårlig, skal man lære ting fra bunnen av er det ikke sikkert det er så dumt å være måtte være bevisst på mønstrene som ligger bak, ikke bare dobbeltklikke i designeren og skrive koden der pointeren havner. Swing er langt mindre avhengig av reflection til alt mulig enn .NET, så på det punktet vil jeg si det er mye bedre.

 

Uansett hva man sier om "sånn gjøres det i j2se" så går det an å si "det kan man gjøre like bra i .NET også", det er ikke det som er problemstillingen. Jeg har aldri påstått at det ikke går an å lage gode ting med .NET, men at det finnes ofte for mange dårlige løsninger i tillegg til dem gode, som du sier, ballast fra .NET 1 og klassisk VB/VBScript, og det er man ikke i stand til å differensiere selv i en læringssituasjon. Java har en bedre ratio mellom gode og dårlige løsninger og mindre arvegods fra utdaterte modeller.

Endret 19. mars 2010 av MailMan13

[GeirGrusom]

Mener du sånn som AWT vs. Swing? Eller det at java inneholder merkverdig mange klasser og funksjoner som er markert "deprecated" i dokumentasjonen?

[MailMan13]

Mener du sånn som AWT vs. Swing? Eller det at java inneholder merkverdig mange klasser og funksjoner som er markert "deprecated" i dokumentasjonen?

At mange klasser ender opp som Deprecated er jo et godt eksempel på at dem prøver å holde forholdet mellom gode og dårlige løsninger høyt.

 

Da faser dem faktisk ut det som ikke var så fett likevel, og gir beskjed til koderen at det finnes bedre måter å gjøre dette på, kanskje man skal kikke på det en gang til.

 

Tenk om man hadde fått det når man instansierer f.eks et RecordSet, eller bruker Type.PropertyInfo med navnet i en string i stedet for å injisere en delegate C# ...

Endret 19. mars 2010 av MailMan13

[GeirGrusom]

Det er to ting som er irriterende i .NET reflection:

- Funksjoner returnerer arrays (samme i Java)

- Ingen bruk av generics (GetAttributes returnerer et array av object... ARGH!)

 

Det hadde vært fint å sett et konkret eksempel på recordset saken din, ettersom jeg ikke kan finne noen recordset klasse, og heller ikke helt forstår hva du mener.

[MailMan13]

ADODB.RecordSet, et spøkelse fra COM+/VBScript dagene som ikke vil dø.

 

Problemet med reflection er ikke at implementasjonen av reflection i seg selv er dårlig, da har du misforstått fullstendig. Problemet er at reflection gjennomsyrer mye av .NET API'et til ting som som løses utmerket fint med andre, langt mindre kostbare og langt mer robuste metoder.

Endret 19. mars 2010 av MailMan13

[GeirGrusom]

Er ikke ADODB erstattet av OleDB?

Selv bruker jeg System.Data.Common.IDbConnection, fordi da er det veldig lett å bytte databasemotor uten å skrive om hele programmet. Da får du ikke noe RecordSet, men en DataReader istedet.

 

Jeg var ikke klar over at .NET bruker mye reflection, men jeg har heller ikke kikket på hva selve .NET API-et gjør under skallet, og jeg vet ikke hva det har å si for nybegynnere.

[MailMan13]

Er ikke ADODB erstattet av OleDB?

Jo, for lenge siden. Hadde det vært Sun bak spakene compileren gnålt om at den var deprecated siden i 2002. Det var poenget.

 

Jeg var ikke klar over at .NET bruker mye reflection, men jeg har heller ikke kikket på hva selve .NET API-et gjør under skallet, og jeg vet ikke hva det har å si for nybegynnere.

Når den vanligste måten å referere et datafelt på er å sende inn navnet som en string, heller enn å referere til et grensesnitt eller delegate er man på villspor mener jeg. Da taper man både robusthet (evt. feil dukker ikke opp før runtime), testbarhet og ytelse, men det finnes andre oppfatninger omkring det.

[GeirGrusom]

Poenget er vel at det er ikke ulovlig å bruke ADODB, men det er langt enklere å bruke de nyere API-ene, som fører til at gamle programmer ikke plutselig slutter å fungere fordi ADODB var et teit påfunn.

Nå har .NET interfaces som skal gjøre det enkelt å bytte databasemotor, men RecordSet er ikke en del av dette API-et, så kanskje ADODB ikke lar seg flytte uten videre. Deprecation er ikke bra for de som vedlikeholder kode, særlig når det er en slik ting som er absolutt ikke-kritisk, ettersom ADODB egentlig er et COM system, mens System.Data inneholder native klienter for SQL Server og Oracle, samt støtte for OleDB og ODBC.

 

Nr 2: Gjør ikke LINQ to SQL akkurat dette? Den baserer seg utelukkende på delegates, og en objektorientert modell blir automatisk dannet av databasemodellen.

Dessuten: hvordan er Java noe bedre her?

[MailMan13]

Poenget er vel at det er ikke ulovlig å bruke ADODB, men det er langt enklere å bruke de nyere API-ene, som fører til at gamle programmer ikke plutselig slutter å fungere fordi ADODB var et teit påfunn.

Nå har .NET interfaces som skal gjøre det enkelt å bytte databasemotor, men RecordSet er ikke en del av dette API-et, så kanskje ADODB ikke lar seg flytte uten videre. Deprecation er ikke bra for de som vedlikeholder kode, særlig når det er en slik ting som er absolutt ikke-kritisk, ettersom ADODB egentlig er et COM system, mens System.Data inneholder native klienter for SQL Server og Oracle, samt støtte for OleDB og ODBC.

 

Nr 2: Gjør ikke LINQ to SQL akkurat dette? Den baserer seg utelukkende på delegates, og en objektorientert modell blir automatisk dannet av databasemodellen.

Det må du forklare for meg. I jobben min forvalter vi systemer fra 1998 og fremover, og har stort sett alle generasjoner av MS plattformer fra VB5 til .NET 3.5 representert. Jeg kan ærlig talt ikke se hva en warning fra kompilatoren hadde gjort meg når vi håndterer utdaterte API'er, som vi gjør hver dag. Microsoft sluttet å offisielt støtte VB 6 og ADODB i 2008, så per definisjon er det faktisk "Deprecated", så hvorfor bør ikke compileren si ifra om det?

 

Deprecation er bra, det gjør at leverandøren kan flagge noe som utdatert og ikke bør brukes uten å fjerne støtten for det. "Deprecated" betyr ikke "forbudt", eller "teit påfunn". Det betyr "her finnes det noe bedre som du heller bør bruke", og det vil jeg ha beskjed om, spesielt om jeg koder ting jeg ikke er vant til og har i fingrene.Man kan fremdeles bruke AWT, selv om SWING har vært ute lenge, hvorfor er det da galt at man blir minnet på at dette ikke er måten å gjøre det på når man kaller en AWT komponent?

 

Linq til database retter opp en del om man lager småting som ikke fordrer en full ER mapper, men nå er det ganske mye i et program som ikke er SQL da. F.eks bindingen mellom verdifeltet i en dropdown i winforms/asp skjer ved at navnet til propertyet som skal bindes legges inn som en streng, kommer man ikke rundt med LINQ til SQL. Hadde man kunnet sende inn en delegate som henter verdien, eller implementert et grensesnitt til en modell som kontrollen kan lese hadde det vært løst, men det kan man ikke, det er tekststrenger som regjerer.

 

Akkurat her føler jeg for å sitere meg selv igjen:

Uansett hva man sier om "sånn gjøres det i j2se" så går det an å si "det kan man gjøre like bra i .NET også", det er ikke det som er problemstillingen. Jeg har aldri påstått at det ikke går an å lage gode ting med .NET

 

Dessuten: hvordan er Java noe bedre her?

Ja, man referer sjelden typer eller oppførsel ved hjelp av strings i Java. Sender man data til et eller annet i API'et er det nesten alltid en typet datamodel som skal inn. Skal man lære eller undervise programmering er det måten å gjøre det på, siden det er en variasjon over dette som ting kommer til å bli gjort i fremover.

 

Jeg mener ikke .NET/C# er underlegent Java, men jeg mener Java er mer stilrent, og hakket bedre pedagogisk til å lære programmering fordi det håndhever en del måter å gjøre ting på som det er litt lettere for å "hoppe bukk" over i .NET, eller ikke kommer eksplisitt frem. Ikke at .NET kode ikke kan gjøres god og riktig som du tror jeg mener.

Endret 19. mars 2010 av MailMan13