Lesen verlernt?

Du weisst doch aber dann immer noch nicht, wie Du einen Algorithmus implementieren musst, damit er z.B. übersichtlich oder schnell sein muss.
Die Auswahl an Funktionen wurde doch schon getroffen.

Parameter von Funktionen sind zudem völlig uninteressant, da es bei jeder Script- und Programmiersprache ausführliche Referenzen gibt, wo man das Nachschlagen kann.
Welche Parameter du in einer Stringfunktion wie angeben musst steht auf der ersten Seite bei einem google-query.

Aber gut, bei PHP ist das alles eine ganz andere - simplerere - Sache.
 
Original geschrieben von honeyboy
Da bin ich anderer Meinung; wenn ich einen Parameter verändere, sehe ich, welche Auswirkungen das auf das Program hat bzw. sogar welche Fehlermeldungen verursacht. Daraus kann ich (zumindest ich persönlich ;) ) dann erfahren, was die einzelnen Parameter bedeuten, und so kann ich mir eine "Sprache" auch anlernen...

Nein eben nicht. Das einzige was du lernst ist wie du welche Funktionen für welchen Zweck nutzt, das hat mit Programmieren eigentlich so gut wie nichts zu tun.

Richtiges programmieren fängt da an, wo ich mir gedanken über Struktur und Design mache, wo wartbarkeit und erweiterbarkeit ein Ziel ist.
Funktionalität ist kein Ziel sondern pflicht.

Das problem ist wenn mann nur auf Funktionalität programmiert wird mann nie grössere Projekte angehen können, denn spätestens bei der Warbarkeit:
Schlüsselsatz: A verändern ohne das B davon etwas merkt.
geht dabei verloren.

Schlussendlich:
Schlechter Code.

Um dies zu vermeiden muss mann sich Wissen anlernen, das in keiner Referenz steht. Wissen das einem Bücher vermitteln können, sonst wird sich da nichts daran ändern. Und ich sagte es im Eingangspost schon, es gibt sehr wenigen Code den ich im PHP Forum entdecke bei dem ich sagen würde, oh da hat sich jemand was dabei gedacht.
Der meiste Code ist funktional und das wars.
Leider.

Was allerdings einem in keinem Buch beigebracht wird sind die Grundbausteine einer Prorgammierung
z.b. Das Geheimnis der While Schleife und ähnliches.
Da hilft nur Probieren und austesten
Das stimmt nicht, mann muss sich nur an gute Bücher halten. Z.b ist OReilly eine Wissensquelle die tiefer geht und aufzeigt wie was implementiert ist.

Ich rede so oder so nicht nur von Büchern die bei 0 anfangen, und einem nur die Syntax und verschiedenen Anweisungen beibrigingen. Denn das ist ungefair 0,1 % Wissen der Programmiersprache.
Ich programmiere seid etlichen Jahren in mittlerweile 11 Programmiersprachen, hauptsächlich Java und dennoch lerne ich immer wieder neue Sachen kennen die ich so nicht kannte.
Zwar deprimierend, das mann immer noch irgendwo am Anfang steht, aber solange es den meisten so geht :-)
 
Also bei mir is das meist so:

Zuerst bekomm ich irgendwo von einer Sprache Wind, und will mal wissen was dahinter steckt, dann guck ich mit Diversen Tutorials und beispielcode das ich selbst was zusammen bekomm.
Meist ist es dann so, das ich mir denke, ich hohl mir bei gelegenheit n Buch, aber dann kommt es 1.) immer anders und 2.) als man denkt.
Dann bin ich meist so beschäftigt mich mit der Sprache zu befassen, das ich kein Buch mehr brauche um damit zu Programmieren, und da ich n armer 11. klässler bin, spaar ich mir dann mein Geld.

Die einzige Sprache, für die ich mit ein Buch gekauft hab war...
tada:
Code:
JAVA
Das Buch hatt ich mir gekauft, weil ich da ganz zufällig im Geschäft drüber gestolpert bin, und n paar Tage zuvor den entschluss gefasst hab mich da mal schlau zu machen, was es denn mit diesem Java so auf sich hatt...

Im nachhinein betrachtet, hatt mir dieses eine Buch nicht nur Java sondern später auch noch für C++ und PHP gefolfen, da ich natürlich auch dort OOP brauche...

Also ich seh das so, das man bei extrem großen Schritten, wie von Prozeduraler auf OOP programmierung schon ein Buch haben sollte, ansonsten kann man drauf verzichten....

Naja ich hab sogar Assembler ohne Buch gelernt ;-) (gibt ja heuzutage kaum noch Bücher dazu)

Wobei ich dazu sagen muss, das ich kein Buch brauche um Logische Struktur in einem Code niederzuschreiben, und das kann meines erachtens auch kein Buch wirklich beibringen, das kommt wenn man die Grundzüge einer Sprache kann von ganz alleine
 
Zuletzt bearbeitet:
Ich programmiere seid etlichen Jahren in mittlerweile 11 Programmiersprachen, hauptsächlich Java und dennoch lerne ich immer wieder neue Sachen kennen die ich so nicht kannte.

Beeindruckt bin :-) ich kenne noch nicht mal 11 den Namen nach oder zählst du Dialekte mit ?

Aber zurück zum Thema:
Nach meiner meinung besteht eine Programmiersprache aus
Syntax und Functionen / Module
Den Grundaufbau / Gerüst wie ich ein Programm schreibe ist bei ettlichen Programmsprachen
zumindes ähnlich - darum auch mein Hinweis das es Umsteigern leichter fällt
Die grobe Richtung wie ich ein Problem zerlege das ist die eigendliche Kunst beim Proggen

-Ok Ausnahmen bestätigen die Regel - auch ich kenne Progammiersprachen die mit nix
andres Vergleichbar sind - aber das lassen wir mal aussen vor :-)

Naja ich hab sogar Assembler ohne Buch gelernt (gibt ja heuzutage kaum noch Bücher dazu)

Wobei ich dazu sagen muss, das ich kein Buch brauche um Logische Struktur in einem Code niederzuschreiben, und das kann meines erachtens auch kein Buch wirklich beibringen, das kommt wenn man die Grundzüge einer Sprache kann von ganz alleine
Joo :-)
 
Zuletzt bearbeitet:
melmager hat gesagt.:
Beeindruckt bin :-) ich kenne noch nicht mal 11 den Namen nach oder zählst du Dialekte mit ?

Sorry sollte nicht wie angeben anhören, habe noch beim Senden drücken überlegt ob das so rüber kommt.
1VBScript
2JavaScript
3PHP
4C
5C++
6C#
7Ruby
8Java
9 LISP
10 Perl
11 XML & XSLT & XPath
Bash / awk usw steht da jetzt nicht dabei ;), wobei ich dazusagen muss Perl, und Lisp sind rudementäre Kentnisse, nicht viel weiter als Grundkentnisse :)

melmager hat gesagt.:
Aber zurück zum Thema:
Nach meiner meinung besteht eine Programmiersprache aus
Syntax und Functionen / Module
Den Grundaufbau / Gerüst wie ich ein Programm schreibe ist bei ettlichen Programmsprachen
zumindes ähnlich - darum auch mein Hinweis das es Umsteigern leichter fällt
Die grobe Richtung wie ich ein Problem zerlege das ist die eigendliche Kunst beim Proggen

Wenn du mit zerlegen == analysieren meinst, dann ist dies ein Teil der Kunst. Aber nicht alles.

Was gibt es bei einer Programmiersprache zu lernen?
a) Die Syntax und Anwendungsweise.
b) Die Tiefen der zugehörigen Klassenlibrary (sprich die Feinheiten)
c) Datenstrukturen, wie geplant und angewandt
d) Weitergehende Librarys, Java z.b J2EE, PHP z.b PEAR usw
e) weiter Forschung über Verhalten der Sprache, performance Vorteile & Nachteiler jener Datenstrukturen.
usw.

Das lernen einer Programmiersprache hört nicht bei b) auf. Und nein mann kann sich kein guten Stil anprogrogrammieren wenn mann sich keine weiterführenden Bücher kauft. Ok in den Jetzt lern ich ... oder in 21 Tagen wird kein Code gezeigt der einen weiterhilft, aber in Fortgeschrittenen Bücher über Patttern und Algorythmen wird einem viel gezeigt was weiterhilft :)
 
Hi Chris,

wie du weißt bin ich ja ein Exot, was die Wahl meiner "Lieblingssprache" angeht.
ich betreibe die ganze Sache nun schon fast (fehlen noch ein paar wenige Monate)
10 Jahre. Natürlich nicht durchgängig intensiv, aber doch recht konzentriert würde
ich meinen.

Angefangen habe ich mit den Grundlagen einfachster Programierung vor nun
schon fast 23 Jahren. Natürlich damals noch keine Sprachen, die es hier zu
erwähnen lohnen würde.

Und nun kommt der Kern:
Ich habe genau das gemacht, was du durchaus zurecht als den falschen Weg
bezeichnest. Ich habe sehr viel learning by doing gemacht, habe aber immer auch
meterweise Bücher besorgt, um die nötigen Referenzen zu haben, damit ich
nachschlagen kann. Habe mich oft an Codebeispielen anderer ergötzt und eine
wie ich finde gewisse Genialität im "Umschreiben" und "Anpassen" entwickelt.

Es funktioniert und ich habe mittlerweile (nach soo langer Zeit) dann doch auch
ein gewisses Verständnis für die (dir bekannte) Sprache entwickelt und kann auch
eigenen Code schreiben. Aber trotzdem rächt es sich jetzt, wo wirklich sehr große
Projekte anstehen doch, dass ich in vielerlei Hinsicht die Materie nicht über das
jeweils nötige Maß vertieft hatte.

Wer immer die Perspektive hat, Programmierer zu werden und gleichzeitig noch
die Möglichkeit hat, es auf dem Weg zu machen, den Chris oben empfiehlt, dem
kann ich nur raten, es so zu machen. Alles andere rächt sich irgendwann, sofern
das Know-How irgendwann benötigt wird.

Ich jedenfalls habe den Eindruck, dass es JETZT für mich schwerer ist, den "Stil"
nochmal umzubauen, den ich mir angeeignet habe. Das Einzige, was mir zu meiner
Entschuldigung einfällt ist, dass ich auf so vielen Spuren gleichzeitig fahre, dass
ein grenzenloses Expertentum in einzelnen Bereichen einfach unmöglich ist bzw.
geworden ist.

OT: Ich gebs trotzdem nicht auf, weil ich bisher noch alles schaffe, was ich machen
muss und außerdem ein richtig fieser Beißer bin, der nicht aufgibt, bevor das Opfer
erledigt ist. ;)

Gruß
Martin
 
Original geschrieben von Martin Schaefer
Ich gebs trotzdem nicht auf, weil ich bisher noch alles schaffe, was ich machen
muss und außerdem ein richtig fieser Beißer bin, der nicht aufgibt, bevor das Opfer
erledigt ist. ;)
Deshalb gibt der Erfolg dir Recht, was man von diversen "PHP-Koriphäen" nicht gerade behaupten kann :rolleyes:, und damit ist alles in Butter würde ich sagen ;)
 
Original geschrieben von Martin Schaefer

Wer immer die Perspektive hat, Programmierer zu werden und gleichzeitig noch
die Möglichkeit hat, es auf dem Weg zu machen, den Chris oben empfiehlt, dem
kann ich nur raten, es so zu machen. Alles andere rächt sich irgendwann, sofern
das Know-How irgendwann benötigt wird.

Ich jedenfalls habe den Eindruck, dass es JETZT für mich schwerer ist, den "Stil"
nochmal umzubauen, den ich mir angeeignet habe. Das Einzige, was mir zu meiner
Entschuldigung einfällt ist, dass ich auf so vielen Spuren gleichzeitig fahre, dass
ein grenzenloses Expertentum in einzelnen Bereichen einfach unmöglich ist bzw.
geworden ist.

OT: Ich gebs trotzdem nicht auf, weil ich bisher noch alles schaffe, was ich machen
muss und außerdem ein richtig fieser Beißer bin, der nicht aufgibt, bevor das Opfer
erledigt ist. ;)

Danke Martin :)

Mann muss letztendlich nur Vertrauen haben das die Autoren der Bücher recht haben. Kleines Beispiel, als ich damals mit Turbo Pascal (upps die 12. Sprache :-) ) angefangen habe da gab es kein OOP Hype und ohne OOP habe ich PHP & ASP Programmiert.
Das verständniss für OOP ist im ersten Moment meist nicht gegeben, es wirkt wie eine verkomplizierung einer einfachen Sache. Diese Aussage hört mann öfter von jenen die mit PHP und OOP in berührung kommen.
Und genau da muss das Vertrauen ansetzen:
"Es wirkt zwar für mich nicht sehr sinnvoll im Augenblick, aber wenn die Authoren, und die meisten erfahrenen Programmierer der Meinung sind das OOP die Zukunft gehört, dann will ich das jetzt erstmal glauben und OOP vorurteilsfrei lernen"
Der Lohn der Geschichte ist, das es irgendwann "klick" macht und einem die Vorteile offenbart werden.

So ist es bei vielen Dingen, ich lern mir im Augenblick Jakarta Struts an und auch hier stellt sich erst die Frage:
Wieso soll ich mich mit solch einem komplizierten (mittlerweile nicht mehr) Konfiguration von Webanwendungen rumärgern wenn ich das MVC selber implementieren kann.
Ich habe dennoch das Buch studiert, sämmtliche Beispiele nachprogrammiert und damit experimentiert, mittlerweile bin ich überzeugt von Struts als eine Hilfe die mir in der Zukunft noch gute Dienste leisten wird.
Genau in diesem Augenblick arbeite ich zum lernen an meiner Homepage holyfly.de und arbeite diese so um das sie über Struts läuft.

Genauso ist es mit gutem Code, dieser wird einem regelrecht eingebläut wenn mann mit den Code der Beispiele arbeitet.
Ganz wichtig: Lieber 10 - 20 EUR mehr investieren und ein Buch holen das von renomierten Verlagen stammt.
z.b Addisson-Wesley, OReilly, WROX usw.
Der Code in diesen Büchern ist meist eine nummer proffessioneller.
 
Naja es kommt drauf an....

wenn es schnell gehen muss und ich weder Lust noch den Nerv habe, dann fange ich einfach so an, aber ohne ein gewisses Grundgerüst an Wissen geht
es meines Erachtens sowieso nicht. Am Beispiel programmieren, also ich würde es nicht bis nur schwer hinbekommen, aus einem Codeschnippsel, der ein Teilproblem, was ich zum EInarbeiten in eine neue Programmiersprache lernen will, löst, den Rest des Programms o.ä. drum herum zu bauen.
Aber ich setze mich dann nicht unbedingt 2Stunden (auch wenn das schätze ich mal nur eine fiktive Zeit war) hin und blättere das Buch durch, sondern wähle oft direkt die Kapitel gezielt aus die ich für den Moment als wichtig erachte und lese da mal Quer bzw komplett je nachdem... und wenn ich dann merke mir fehlt doch noch was lese ich weiter....

Also ich denke ich komme mit dieser Methode recht gut klar.
 
Zurück