Mit was anfangen?!

Hallo Marco!

HTML ist eine Markup Sprache, d.h. Du kannst damit etwas am Computer (meistens innerhalb deines Webbrowsers) darstellen, aber Du kannst nichts berechnen. HTML wird meistens in Verbindung mit anderen Programmiersprachen verwendet, die etwas erzeugen. Das Ergebnis kann dann (unter anderem) in HTML dargestellt werden.

Wenn Du mit dem Programmieren beginnst, wirst Du eher eine 'richtige' Programmiersprache lernen wollen. HTML kommt dann so nebenbei.

C ist da ein guter Kandidat, noch besser ist es meiner Meinung nach Du faengst mit einer Sprache wie Python oder LISP an. Ich glaube es ist am besten erst mit einer high-level Sprache anzufangen (z.B. Python oder Ruby oder Lisp oder ...), dann das K&R Buch zu lesen (Einfuehrung in C, siehe unten), und dann die fortgeschrittenen Techniken zu erlernen.

Viel wichtiger als mit welcher Programmiersprache du anfaengst ist aber, welche Literatur Du liest und WIE Du lernst. Zwar gibt es zwischen den einzelnen Programmiersprachen grosse Unterschiede: Aber bevor Du Dich mit denen auseinandersetzt (Du wirst eh mehrere Sprachen lernen muessen/wollen), musst Du erstmal das Programmieren ganz allgemein lernen. Am wichtigsten ist es dabei das Du dich auf die Algorithmen, Strukturen usw. konzentrieren kannst und das Du sehr schnell Ergebnisse zu sehen bekommst.

Was Du am besten machst:

* Theorie lesen
* Code anschauen
* Code schreiben
* ueber Code diskutieren.

Alles ungefaehr gleich intensiv.

Am Anfang deckt ein Lehrbuch meistens eh alles (zumindest die ersten drei) ganz gut ab, weil es in einem guten Buch viel Beispielcode und Uebungsaufgaben geben sollte. Du musst dann halt auch wirklich die Uebungen live am Rechner ausprobieren und damit herumspielen. Also nicht lesen und davon ausgehen das Du alles verstanden hast.

Wenn Du etwas Erfahrung gesammelt hast musst du dann (neben weiteren Buechern) immer wieder in die Programmierprojekte von anderen reinschauen (Die Open Source Kultur ist da ein Geschenk des Himmels), und natuerlich Deine eigenen Programme schreiben.

Buchempfehlungen

Phase I: Noch gar keine Programmiererfahrung (eines auswahelen):

How To Think Like An Computer Scientist http://www.ibiblio.org/obp/thinkCSpy/

Head First Java http://www.amazon.de/Head-First-Java/dp/0596009208

Phase II: Maschinennahe programmierung:

The C Programming Language (K&R) http://en.wikipedia.org/wiki/K%26R

Phase III (alle lesen):

The Pragmatic Programmer. From Journeyman to Master http://www.amazon.com/Pragmatic-Prog…r/dp/020161622X

Structure and Interpretation of Computer Programs http://mitpress.mit.edu/sicp/full-text/book/book.html (wird am MIT als Phase I buch verwendet, gehoert aber eher hier hinein.)

Code Complete (2nd Edition) http://www.amazon.com/Code-Complete-…l/dp/0735619670

The Algorithm Design Manual http://www2.toki.or.id/book/AlgDesignManual/

Head First Design Patterns http://www.amazon.com/Head-First-Des…s/dp/0596007124

Refactoring: Improving the Design of Existing Code http://www.amazon.com/Refactoring-Im…e/dp/0201485672

Test Driven Development http://www.amazon.com/Test-Driven-De…e/dp/0321146530

Es gibt noch viele andere gute Buecher die man unbedingt lesen sollte die mir aber grad nicht einfallen. nach Phase drei kennst du dich Da aber eh selbst gut genug aus um zu wissen wie Du weitermachst.

Phase IV ist dann Spezialisierung, d.h. Du weisst zu dem Zeitpunkt z.B. das Du dich fuer Artificial Intelligence interressierst und moechtest Dir dieses buch kaufen:

http://www.amazon.com/Artificial-Int…d/dp/0137903952

Falls Du (wie ich) lieber aus einem Buch lernst das man aufklappen kann: Alle Buecher bei denen ich auf eine online Version verlinkt habe gibt es auch als Hardcopy.

Zum Schluss noch ein Klassiker:

http://norvig.com/21-days.html

wow! was für eine hilfe... danke
ich bin gerade an dem punkt wo ich dringend an einem projekt arbeiten sollte...
ich habe eine cms seite angefangen in php, aber ich mag php nicht und hab bis jetzt java gelernt, wobei man php leichter zum laufen bringt als jsp.
mich interessiert ganz stark womit die homepage der fachschaft (fsinf.at) erstellt wurde...
mich würds ur interessieren zu wissen wie man so eine cms seite - wie die von der fs - selber erstellt.
weiss das jemand? bitte um hilfe

"How to think like a Computer Scientist" gibt es auch in einer Version für Java und ist auch für den Java Einstieg echt empfehlenswert.

lg Stefan

ich empfehle java ist auch eine insel (openbook). gibt eine tolle einführung und einen überblick über die sprache. behandelt sogar corba/rmi

link: http://www.galileocomputing.de/openbook/javainsel6/

Zitat von beat

ich empfehle java ist auch eine insel (openbook). gibt eine tolle einführung und einen überblick über die sprache. behandelt sogar corba/rmi

link: http://www.galileocomputing.de/openbook/javainsel6/

Ich empfehle dieses Buch ausdruecklich _nicht_. :

1.) Das Buch konzentriert sich viel zu sehr auf das Erlernen einer konkreten Programmiersprache (in diesem Fall Java) und zu wenig aufs Programmieren. Geschichte von Java, Motivation von Java, Syntax von Java,... All das ist gut zu wissen, aber sicher nicht wenn man anfangt zu programmieren. In dem Buch steht ausguehrlich beschrieben welche Zeichen in einem Indetifier stehen duerfen, aber wie und wozu man einen Identifier eigentlich benutzt wird kaum und nur sehr unzureichend erwaehnt.

2.) Ungefaehr 2/3 des Buches befassen sich mit Bibliotheken aus der Java Standardbibliothek. Eine Bibliothek zu erlernen, die man spaeter vielleicht niemals verwendet, anstatt die Grundlagen zu erlernen, die man zum Programmieren benoetigt? Die meisten Bibliotheken sind zudem viel schneller zu erlernen, wenn man sich erstmal mit Datenstrukturen und Designpatterns auskennt: Swing lernen vor dem Observer Pattern? JavaStreams lernen vor dem Decorator Pattern? Corba lernen in Phase I ? CORBA?? Ich glaube nicht das das klug ist.

3.) Java ist nicht unbedingt die beste Wahl fuer eine erste Programmiersprache : Java ist relativ low-level und es gibt in Java so viele Syntaxeigenheiten die man lernen (oder noch schlimmer: Ignorieren) muss, bevor man sich auf das Programmieren selber konzentrieren kann. Wer sich mit Java auseinandersetzen will, dem empfehle ich Bruce Eckels "Thinking In Java". Aber erst in Phase III.

Fuer mich klingt das Buch nach Lernen in Slow Motion.

Ich hab auch versucht mit Java ist auch eine Insel zu beginnen, fand die Geschichte von Java und so zwar recht interessant, aber fürs Programmieren lernen nicht wirklich geignet.

Auch empfiehlt es ziemlich stark Eclipse, was man sich für den Anfang gleich mal wieder abgewöhnen sollte, da man wenn man mit Eclipse beginnt nichtmal sinnvoll weiss wie man eine main Methode beginnt und sich einen sehr schleissigen Programmierstil angewöhnt.

lg Stefan

Ich fand Java ist auch eine Insel nicht sonderlich gut.Es setzt einiges vorraus - als totaler Anfänger wäre Head First Java besser geeignet.
Bei Eclipse muß ich zustimmen.Man sollte nie als Neuling mit einer Entwicklungsumgebung anfangen,die einem alles abnimmt und/oder schleissigen Code produziert.
Am Anfang am besten alles selber machen da lernt man aus seinen Fehlern am meisten auch wenns schwer fällt.
Je nachdem kann es gut sein sich HTML anzueignen um schnell ein Resultat zu sehen und sich damit zu befassen, den Code hinter einer Seite bez. später beim Programmieren den Code hinter einem Programm zu sehen.Viele schreckt ja schon der Sourcecode einer einfachen Seite ab:o

Falls man als totaler Anfänger Java lernen will, ist das "How to think like a computer scientist - Java Version" super geignet ... Head First Java oder sowas kann man sich dann noch immer zulegen, aber ich hab zuerst probiert aus irgendwelchen komischen Boku Folien zu lernen und hab keine Zusammenhänge verstanden. Dann Insel ... auch nicht wirklich weitergekommen. Aber mit "How to think ..." hab ich dann echt Java von Grund auf bis zur Objektorientierung Programmierung gelernt. Die Lists, Trees u.s.w. hab ich dann mal ausgelassen in dem Buch, die waren mir etwas zu abstrakt geschrieben.

Eventuell sollte man sich aber anschauen wie man eine Eingabe in Java (zB mit Scanner) einliest, damit es ein bischen lustiger wird und man nicht dauernd neu kompilliern muss.

lg Stefan

I/O ist in Java allerdings so ziemlich das Komplizierteste überhaupt..... BufferedReader ByteArrayInputStream InputStream blah

Zitat von hal

I/O ist in Java allerdings so ziemlich das Komplizierteste überhaupt..... BufferedReader ByteArrayInputStream InputStream blah

I/O ist überhaupt etwas, womit man Anfänger nicht quälen sollte. Sprachen ohne read-eval-print-loop sind das Letzte (nicht nur für Anfänger, auch wenn man einigermaßen effizient Software entwickeln will).

Zitat von a9bejo

Swing lernen vor dem Observer Pattern?

Man muß es mit der Patternreligion jetzt auch nicht übertreiben; eine Callbackfunktion ist eine Callbackfunktion ist eine Callbackfunktion, auch wenn sie aus syntaktischen Gründen in eine Klasse verpackt werden muß. Um das Konzept einer Callbackfunktion in Swing zu verstehen, muß man wirklich keine Patternbücher gelesen haben. (Ja, ich habe Swing-Applikationen entwickelt, nein, ich habe es dabei nie nötig gehabt, über "Observer" nachzudenken; event handler ist übrigens ein tausendmal besserer Ausdruck im Bezug auf Swing.)

Generell haben viele der hochgelobten Patterns nichts mit Design von Softwaresystemen zu tun, sondern sind nur Artefakte davon, daß Leute minderwertige Sprachen wie Java verwenden. (Gut, so gesehen haben sie schon mit Design zu tun, aber nur mit Design durch Leute, die es Mitte der Neunziger und nach extensiver Erfahrung mit den Qualen von C++ und angeblicher (ich glaube nicht daran) Erfahrung mit Smalltalk nicht geschafft haben, eine Sprache mit "foreach"-Schleife zu designen.)

Zitat von Plantschkuh!

(Ja, ich habe Swing-Applikationen
entwickelt, nein, ich habe es dabei nie nötig gehabt, über "Observer"
nachzudenken; event handler ist übrigens ein tausendmal besserer
Ausdruck im Bezug auf Swing.)

Ich habe nicht behauptet man koennte es nicht anders lernen. Ich sage
nur das es der laengere und schwierigere Weg ist. Swing verwendet
Observer nunmal sehr viel. Wenn ich das Pattern kenne, verstehe ich
die Motivation und Funktionsweise leichter. Wenn ich eh beides
irgendwann lernen muss, dann mach ich das doch am besten aufbauend?

Zitat von Plantschkuh!

Generell haben viele der hochgelobten Patterns nichts mit Design von
Softwaresystemen zu tun, sondern sind nur Artefakte davon, daß Leute
minderwertige Sprachen wie Java verwenden.

Auch hier muss ich dir wiedersprechen: Auch wenn Du nur in den (sehr
seltenen) Genuss kommst, ausschliesslich sehr abstrakte Sprachen
verwenden zu duerfen ('minderwertig'/'hochwertig' passt hier nicht
finde ich), ist es wichtig sich mit Patterns auszukennen. Auch wenn
ein Pattern in einer Sprache integriert ist, verschwindet es meistens
nicht, sondern es bleiben die meisten Eigenschaften eines Patterns
(Kontext, Motivation, Konsequenzen usw.) immer noch relevant. Nur
wenige verschwinden wirklich in abtrakteren Programmiersprachen. Was
wegfaellt ist nur die Implementierung.

Ist Iterator noch ein Pattern, wenn es in die Sprache integriert ist
(z.b. smalltalk)? Streng genommen vermutlich nicht. Aber deswegen ist
es immer noch wichtig, dass ich die Notwendigkeit fuer einen Iterator
in einer Problemstellung erkennen und ihm einen Namen geben kann.

Oder ein anderes Beispiel: Vererbung ist fuer einen Java programmierer
kein Design Pattern mehr. Trotzdem muss ein Java Programmierer aber
noch wissen was Vererbung ist und wie man sie anwendet.

http://norvig.com/design-patterns/

Sorry, falls das hier in zu spezifische Sphären driftet... andererseits ist diese Diskussion zumindest die Illustration dafür, daß keiner (oder anders betrachtet: jeder) weiß, wie man Informatik am besten lernt und lehrt. Im Prinzip kannst du also mit den Empfehlungen von a9bejo loslegen, sie sind zumindest um Ecken besser als viele viele andere. Völlig richtig sind sie nicht, aber völlig richtig gibt es auf diesem Gebiet eben nicht.

Zitat von a9bejo

Ich sage nur das es der laengere und schwierigere Weg ist. Swing verwendet Observer nunmal sehr viel.

Vielleicht bin ich ja einfach nur viel dümmer als der durchschnittliche Java-Programmierer, aber ich finde "du gibst eine Callback-Funktion an, die aufgerufen wird, wenn dieser Button geclickt wurde--weil James Gosling eine Gurke ist, mußt du die Funktion in eine anonyme Klasse ohne sonstigen Sinn verpacken, sorry" weder länger noch schwieriger als "also hier ist mal ein UML-Diagramm, in dem jedem Subject eine Ansammlung von Observern zugeteilt ist; das Interface von Subject beinhaltet die Operationen Attach, Detach und Notify..." *schnarch*

Ich glaube ein Teil meines großen Problems mit zu überzeugten Pattern-Anhängern ist, daß sie zu glauben scheinen, Leute wären zu blöd, um quasi bottom-up Muster zu erkennen, deswegen muß man sie ihnen von einem total hohen abstrakten Niveau ausgehend top-down eintrichtern. Spätestens nach der dritten Swing-Komponente sehe ich, daß sie wohl alle mit dem gleichen Callback-Mechanismus ausgestattet sind, und bin damit sowohl zeitlich als auch in der praktischen Erkenntnis dem Heini voraus, dem man gesagt hatte, bevor er sein erstes Java-GUI schreiben darf, muß er erstmal einige Kapitel im GOF-Buch lesen.

Zitat

Wenn ich eh beides irgendwann lernen muss, dann mach ich das doch am besten aufbauend?

Wenn ich muß und wenn die Sache aufbauend ist. Ich stelle beides in Frage.

Zitat

Auch hier muss ich dir wiedersprechen: Auch wenn Du nur in den (sehr seltenen) Genuss kommst, ausschliesslich sehr abstrakte Sprachen verwenden zu duerfen ('minderwertig'/'hochwertig' passt hier nicht finde ich), ist es wichtig sich mit Patterns auszukennen.

Praxisbeispiel. In meiner Arbeit besuche ich in C++ Knoten in einem Graphen, wobei wir verschiedene Knotentypen haben und ich für jeden Knoten eine ganze Reihe von Attributberechnungsfunktionen aufrufen muß.

• Observer für den Callback zur Attributberechnung? Bevor du das Interface spezifiziert hast, rennt mein erster Test, der auf dreiste Weise über einen Pointer auf ein Objekt eine Methode dieses Objekts aufruft, ohne daß irgendwer ellenlange Doku darüber geschrieben hätte, wer jetzt genau das ConcreteSubject ist.
• Visitor für die Typumwandlung auf den konkreten Knotentyp? Bevor du 270 (ja, so viele Typen haben wir) absolut identische accept()-Methoden geschrieben hast, habe ich fröhlich downgecastet und weiß, daß deine Sorte das wohl grauslich findet, es aber trotzdem viel besser in unser Design (das nicht broken ist; die Welt, die wir modellieren, ist halt einfach so, daß man oft downcasten muß) passt.
• Chain of Responsibility für die Liste der Funktionen, die für jeden Knoten ausgewertet werden sollen? Ein Vollkoffer werde ich sein, statt der STL meine eigene Implementierung einer verketteten Liste zu verwenden, nur um bangen zu dürfen, ob eh jede Funktion die nächste in der Kette aufruft, und um mir jede Möglichkeit, die Berechnung sinnvoll zu parallelisieren, zu verbauen.

Ich habe nicht den Eindruck, daß es so wichtig ist, sich mit Patterns auszukennen, die einem nur im Weg wären...

Zitat

Ist Iterator noch ein Pattern, wenn es in die Sprache integriert ist (z.b. smalltalk)?

Darüber können sich die Leute Gedanken machen, die den Begriff des Patterns nicht für völlig überbewertet halten.

Für mich gibt es bei Iteratoren schon Muster: In C++ ist das Muster, daß ich für jeden Container ein-zwei Zeilen boilerplate code schreibe, was normalerweise zwar verpönt ist, aber wenn der boilerplate code nicht boilerplate code heißt, sondern Pattern (die Benennung ändert nämlich wahnsinnig viel daran, daß sich ständig der gleiche Code wiederholt), dann darf ich das und werde sogar für die Eleganz meines Codes gelobt; Teil des Musters ist auch, daß ich mich für jede einzelne Iteration ein wenig gräme.

In Smalltalk ist das Muster, daß ich do: schreibe und mit meinem Programm fortfahren kann, während andere Leute sich noch den Kopf zerbrechen, wie sie hier am besten das Iterator-Pattern instanziieren.

Zitat

Aber deswegen ist es immer noch wichtig, dass ich die Notwendigkeit fuer einen Iterator in einer Problemstellung erkennen und ihm einen Namen geben kann.

Der Name ist do: . Der Name ist map. Der Name ist mapcar und Konsorten. Der Name ist for_each oder transform oder viele andere Varianten, und immer schön brav multiplies, bind2nd und project1st verwenden, weil der Bjarne leider auch falsche Prioritäten gesetzt hat. Was kümmert mich, ob GOF Jahrzehnte nach der ersten Implementierung von Lisp einen tausendsten Namen erfunden haben? Das Konzept war vor ihnen da und allgemein bekannt.

Zitat

Oder ein anderes Beispiel: Vererbung ist fuer einen Java programmierer kein Design Pattern mehr. Trotzdem muss ein Java Programmierer aber noch wissen was Vererbung ist und wie man sie anwendet.

Ja. Ich muß auch wissen, wie ich in meinen Graphen meine Methoden aufrufe. Und ich weiß es, ohne darüber Bücher zu lesen oder zu schreiben. Es sagt hier keiner, daß man nicht verstehen soll, was man tut. Im Gegenteil, ich bin sehr dafür, daß man versteht was man tut, anstatt krampfhaft zu versuchen, seinem Anwendungsgebiet Kapitel soundso des [tex='n'][/tex]

-ten Pattern-Buchs überstülpen zu wollen.

Zitat

http://norvig.com/design-patterns/

Kenn ich, und es hat mich vorhin auch gejuckt, Folie 9 zu zitieren. Gibts irgendwas konkretes darin, das mich überzeugen würde, daß mein Programm, von dem auch der Herr Norvig nichts weiß, aus drei bis fünf Standardkomponenten zusammengestöpselt gehört?

Zitat von hal

I/O ist in Java allerdings so ziemlich das Komplizierteste überhaupt..... BufferedReader ByteArrayInputStream InputStream blah

Hmmm ... also ich bin JavaAnfänger und finde (mit Scanner) Input nicht so kompliziert. Jetzt ist die Frage warum du meinst es sei so komplex. Meinst du die Benutzung oder das Verstehen? Die Benutzung ist (mit Scanner und jetzt mal Consoleninput) halbwegs einfach solange man auf Exceptions verzichtet (weil man die ja als Anfänger nicht wirklich lernen muss). Das Verstehen der daruntervorgehenden Dinge, das Verstehen was Scanner genau macht, also wie das mit den ganzen Streams und so ist ... wahrscheinlich ist das das komplizierte, oder?

lg Stefan

Jaja klar das weiss ich das es vor Scanner viel komplizierter war (danke das ich erst jetzt mit Java beginne ), was ich mich frage ist (da es ja mit Scanner einfacher geworden ist) Scanner nicht verwendet oder die Eingabe vor Scanner meint oder die Theorie hinter Scanner und Eingabe/Ausgabe in Java meint?

lg Stefan

Naja, ich hab mit Java 1.4 angefangen mit Java