Kann mann alles um eine Sprache herum wissen?
-
Hallo,
ich bin fast etwas verzweifelt, darum nmuss ich euch einfach mal fragen!
Ich habe angefangen c++ zu lernen, kann ich auch relativ gut (mehr als Grundlagen)
Jetzt mache ich C# mit dem VS2005!
Alles bis jetzt rein aus interesse und aus hobby, wollte das später aber viell auch beruflich machen.Hab jetzt ein 1200 Seiten Buch C# auch fast durch, lese nebenbei kleinere sachen und auch andere bücher!
Habe vorher auch schon einige C++ Bücher gelesen.Doch merke ich 1.: das ich einige Sachen nach einer gewissen zeit wieder vergesse (kann mir nicht alles merken)
und 2tens das ich es mir nciht vorstellen kann wirklich alles rund um c# oder c++ zu wissen!
Wenn ich einige Sachen von leuten hier im forum so lese, denke ich "Du weisst nix"...aber muss ich das auch alles wissen?So im detail?Ist das normal, kann man das alles garnicht wissen und muss eben immermal nachschauen in büchern oder sonstwo?
Ist es auch normal das man einige sachen schnell wieder vergisst oder andere eben nicht wirklich gleich begreift?Weil langsam schwindet meine motivation, weil ich denke, ich werde das nie wirklich bringen weil ich immer was vergesse und nie alles wissen kann!
Helft mir bitte!
PS ich programmiere seit ungefähr 3jahren, allerdings nciht täglich und auch keine 8h am tag!
-
Ist_das_moeglich? schrieb:
Ist das normal, kann man das alles garnicht wissen und muss eben immermal nachschauen in büchern oder sonstwo?
ja, das ist normal und kein beinbruch.
-
Wenn man einige Jahre täglich 8h mit einer Sprache arbeitet und sich für neue Sprachfeatures interessiert und nicht immer nur das alte bekannte verwendet, dann kann man schon irgendwann sehr viel wissen. Aber gute Ideen für Design, Algorithmen usw. sind viel wichtiger als das perfekte beherrschen einer Sprache.
-
Hallo
Auch ich bin der Meinung das man nicht alles auswendig wissen muß, sondern einen guten Überblick haben sollte und weiß wo man Details nachschlagen kann.
Wichtiger ist Praxiserfahrung und eher allgemeines Verständnis von Aufgabenlösung/umsetzung.bis bald
akari
-
Tja, diesbezüglich hat sich das Leben eines Programmierers auch kräftig verändert, oder? Vor ein paar Jahren noch war es in erster Linie mal wichtig, die Programmierung an sich gut zu beherrschen, optimale Algorithmen und Vorgehen zu finden, und sich selbst eine gute Werkzeuggrundlage zu schaffen.
Heute schreiben wir zu 90% gleich aussehende "Business-Objekte", welche die ewig selben Datenbanken ansprechen, und mit den ewig selben Data Binding Konzepten kommunizieren, gebunden an Textfelder und Labels. In dominierenden Enterpriseentwicklungsumgebungen wie Java oder .NET gibt es ja fast jeden Scheiß schon vorgefertigt, ich muss es mit ein paar Handgriffen im Prinzip nur noch anpassen. Klar muss ich heute immernoch "eigenen" Code schreiben der möglichst Effizient sein sollte, aber die Notwendigkeit, vorhandene Techniken zu lernen ist wohl um ein Vielfaches gestiegen.
Der eine oder andere wird mir jetzt Gegenbeispiele liefern, und vielleicht irgendein wissenschaftliches Programm o.Ä. anführen. Tatsache ist dass wohl die meisten Berufsprogrammierer, welche typische Anwendungen der Geschäftswelt entwickeln, mehr zu Fließbandarbeiter geworden sind. Ein Formular nach dem anderen zusammenklicken, per SQL Tabellen definieren, eine Zugriffsklasse schreiben, mit dem Formular verknüpfen. Und das wiederholt sich dann immer und immer wieder, bis das krönende Highlight am Schluss kommt: Die Darstellung eines Balkendiagrammes auf Grundlage von Daten in der Tabelle XY. Jetzt muss man schon fast sein Gehirn einschalten, wenn man nicht eine der quietschbunten Komponentensammlungen unzähliger Drittanbieter verwendet.Was ich damit sagen will: Heute ist es sehr wichtig, sich mit diversen Frameworks, Klassenbibliotheken und (Hype-)Technologien auseinander zusetzen. Das sieht man schon an der durchschnittlichen Stellenanzeige.
"Wir suchen ambitionierten Java EE-Programmierer, der sich mit Java ServerFaces, Spring, Hibernate, Struts, JSP, HTML, Ajax, Web 5.0, JavaScript, CSS, XML, JSON auskennt und der coole Web 2.0-Beta-Logos entwerfen kann".
Früher hat das Programmieren mehr Spaß gemacht. Vielleicht hat es ein wenig länger gedauert, vllt. hat man auch mehr Fehler gemacht, aus denen man erst lernen musste. Aber die Arbeit war abwechslungsreicher und erforderte mehr Eigeninitiative und Kreativität. Und ich denke in Zukunft werden wir noch mehr nach dem Baukastenprinzip arbeiten.
-
Das hängt von dem Feld ab, in dem man arbeitet. Mit früher und heute hat das erstmal wenig zu tun.
-
marco.b schrieb:
Tja, diesbezüglich hat sich das Leben eines Programmierers auch kräftig verändert, oder? Vor ein paar Jahren noch war es in erster Linie mal wichtig, die Programmierung an sich gut zu beherrschen, optimale Algorithmen und Vorgehen zu finden, und sich selbst eine gute Werkzeuggrundlage zu schaffen.
Heute schreiben wir zu 90% gleich aussehende "Business-Objekte", welche die ewig selben Datenbanken ansprechen, und mit den ewig selben Data Binding Konzepten kommunizieren, gebunden an Textfelder und Labels. In dominierenden Enterpriseentwicklungsumgebungen wie Java oder .NET gibt es ja fast jeden Scheiß schon vorgefertigt, ich muss es mit ein paar Handgriffen im Prinzip nur noch anpassen. Klar muss ich heute immernoch "eigenen" Code schreiben der möglichst Effizient sein sollte, aber die Notwendigkeit, vorhandene Techniken zu lernen ist wohl um ein Vielfaches gestiegen.
Der eine oder andere wird mir jetzt Gegenbeispiele liefern, und vielleicht irgendein wissenschaftliches Programm o.Ä. anführen. Tatsache ist dass wohl die meisten Berufsprogrammierer, welche typische Anwendungen der Geschäftswelt entwickeln, mehr zu Fließbandarbeiter geworden sind. Ein Formular nach dem anderen zusammenklicken, per SQL Tabellen definieren, eine Zugriffsklasse schreiben, mit dem Formular verknüpfen. Und das wiederholt sich dann immer und immer wieder, bis das krönende Highlight am Schluss kommt: Die Darstellung eines Balkendiagrammes auf Grundlage von Daten in der Tabelle XY. Jetzt muss man schon fast sein Gehirn einschalten, wenn man nicht eine der quietschbunten Komponentensammlungen unzähliger Drittanbieter verwendet.Was ich damit sagen will: Heute ist es sehr wichtig, sich mit diversen Frameworks, Klassenbibliotheken und (Hype-)Technologien auseinander zusetzen. Das sieht man schon an der durchschnittlichen Stellenanzeige.
"Wir suchen ambitionierten Java EE-Programmierer, der sich mit Java ServerFaces, Spring, Hibernate, Struts, JSP, HTML, Ajax, Web 5.0, JavaScript, CSS, XML, JSON auskennt und der coole Web 2.0-Beta-Logos entwerfen kann".Früher hat das Programmieren mehr Spaß gemacht. Vielleicht hat es ein wenig länger gedauert, vllt. hat man auch mehr Fehler gemacht, aus denen man erst lernen musste. Aber die Arbeit war abwechslungsreicher und erforderte mehr Eigeninitiative und Kreativität. Und ich denke in Zukunft werden wir noch mehr nach dem Baukastenprinzip arbeiten.
leider ja, die arbeitsstellen bei denen man kreativ sein muss sind gering geworden. aber es ist noch nicht ganz so aussichtslos wie du schreibst.
-
Ich weiß, ich übertreibe gern.
-
Kann mann alles um eine Sprache herum wissen?
Da eine Sprache eine endliche Menge* ist, lautet die Antwort: Ja. Oder irre ich mich hier?
* es gibt eine endliche Menge an Regeln, ebenso wie reservierten Woertern.
-
Ist_das_moeglich? schrieb:
Doch merke ich 1.: das ich einige Sachen nach einer gewissen zeit wieder vergesse (kann mir nicht alles merken)
Man behält halt Dinge, die man regelmäßig verwendet bzw mit denen man sich lange beschäftigt hat besser. Aber oft kann man verloren geglaubtes Wissen schnell reanimieren, wenn man mal wieder ein Buch/Artikel/Code zu dem Thema überfliegt.
und 2tens das ich es mir nciht vorstellen kann wirklich alles rund um c# oder c++ zu wissen!
Warum sollte man das nicht können?
-
rüdiger schrieb:
und 2tens das ich es mir nciht vorstellen kann wirklich alles rund um c# oder c++ zu wissen!
Warum sollte man das nicht können?
Warum sollte man das können wollen? Dann hat man entweder nen ziemlich einseitigen Job oder is nen totaler Nerd.
-
DEvent schrieb:
Kann mann alles um eine Sprache herum wissen?
Da eine Sprache eine endliche Menge* ist, lautet die Antwort: Ja. Oder irre ich mich hier?
* es gibt eine endliche Menge an Regeln, ebenso wie reservierten Woertern.
Die Regeln und Symbole können erstens unbegrenzt komplex miteinander kombiniert werden, wodurch eine Sprache idR unendlich ist. Zweitens ist "alles um eine Sprache herum" nicht das gleiche wie jedes Element der Sprache zu kennen.
-
Das kommt auf die Sprache drauf an. Aber in 3 Jahren kann man garantiert nicht alles lernen, was es zu lernen gibt, mach dir also keine Sorgen. Ich programmier seit ca. 8 Jahren in C++ und kann noch lange nicht ueberall mitreden. Aber wenn du dir Programme anschaust, die du vor 1-2 Jahren geschrieben hast, und die, die du heute schreibst, solltest du einen Unterschied merken, sonst ist etwas in deinem Lernprozess falsch.
Es kommt auch drauf an, wie du lernst/programmierst.Sehr bekannt zu dem Thema ist uebrigens der Aufsatz Teach Yourself Programming in Ten Years
DEvent schrieb:
Kann mann alles um eine Sprache herum wissen?
Da eine Sprache eine endliche Menge* ist, lautet die Antwort: Ja. Oder irre ich mich hier?
* es gibt eine endliche Menge an Regeln, ebenso wie reservierten Woertern.
Das Alphabet ist endlich, die Sprache mitnichten.
-
Aber wenn du dir Programme anschaust, die du vor 1-2 Jahren geschrieben hast, und die, die du heute schreibst, solltest du einen Unterschied merken, sonst ist etwas in deinem Lernprozess falsch. Es kommt auch drauf an, wie du lernst/programmierst.
Das ist immer so, der aeltere Code ist furchtbar, wenn man ihn dann nach paar Jahren ansieht.
Da gibt es aber ein guten Artikel ueber alten Code:
Things You Should Never Do, Part I - Joel on Software
http://www.joelonsoftware.com/articles/fog0000000069.html
-
wenn man ne sprache ein paar jahre verwendet, hat man die gängigsten best practices drauf. das ist noch lange nicht alles, was eine sprache zu bieten hat, sorgt aber für sauberen (sprich: leicht nachvollziehbaren) code. halte es auch nicht wirklich für erstrebenswert, unbedingt alles über eine sprache auswendig wissen zu wollen. ist ja auch kein beinbruch, wenn man nochmal nachguckt. meiner erfahrung nach reicht es völlig aus, wenn man ne grobe vorstellung davon hat, wo man nachgucken muss.
Things You Should Never Do
hehe, refactoring... das killt arbeitsstunden ohne ende ^^
-
DEvent schrieb:
Das ist immer so, der aeltere Code ist furchtbar, wenn man ihn dann nach paar Jahren ansieht.
Da gibt es aber ein guten Artikel ueber alten Code:
Things You Should Never Do, Part I - Joel on Software
http://www.joelonsoftware.com/articles/fog0000000069.htmlNaja, es gibt aber auch ein paar Ausnahmen: Manchmal ist man gezwungen neu zu schreiben (z.B. weil der verwendete Compiler und die Bibliotheken seit 10 Jahren nicht mehr supportet werden, und es Probleme mit neuen Plattformen gibt).
Wobei selbst da noch Refaktoring angebracht ist um den Code erstmal in einen Stand zu bringen der a) verständlich ist und sich b) besser auf eine neue Plattform übertragen lässt.
cu André
-
DEvent schrieb:
Da gibt es aber ein guten Artikel ueber alten Code:
Things You Should Never Do, Part I - Joel on Software
http://www.joelonsoftware.com/articles/fog0000000069.htmlDer Artikel finde ich nicht besonders gut. Das Hauptargument stützt sich auf diese Behauptung:
"The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed."Die Idee, dass Code, in dem besonders viele Bugs gefunden und beseitigt worden sind, jetzt besonders fehlerfrei sein soll, ist absurd. Code, den man nicht versteht, ist ein Risiko. Erstens weiß man nicht, wieviele Bugs darin noch lauern. Wenn die bisher nicht aufgefallen sind, dann wohl nur, weil sie in weniger oft genutzten Regionen liegen. Zweitens ist der Code wahrscheinlich eben nicht gut getestet, zumindest nicht in dem Sinne, dass es eine gute Abdeckung durch automatische Tests gibt. Gäbe es das, wäre es ja relativ leicht, in dem Code zu arbeiten. Drittens ist jede Änderung riskant, wenn man nicht weiß, worauf das alles Auswirkungen hat. Im Laufe der Zeit wird die Entwicklung immer vorsichtiger und langsamer und kommt schließlich praktisch zum Stillstand.
Das heißt nicht, dass durch Neuimplementation alles automatisch besser wird, das muss gut bedacht sein, aber manchmal hat man keine Wahl.
-
ich glaube auch nicht, dass der artikel so gemeint war. es geht eher darum, dass man ein stück code, welches man eben nicht anfassen muss, gut genug ist. wenn man z.b. ein interface hat, um einen popup dialog anzuzeigen und dieses einfach nur irgendwo verwendet, dann gibt es praktisch keinen grund, die implementierung dahinter anzufassen. gerade im GUI bereich ist code meist voller hacks und weichen, um bugs auf allen möglichen plattformen zu beheben. und solange man an diesen code nicht ranmuss, weil man ihn erweitern will, gibt es kaum einen grund, ihn neu zu schreiben.
wenn man natürlich gerade an einem stück code arbeitet und merkt, dass die geplante erweiterung kaum in den bestehenden code einzufügen ist, dann sollte man sich überlegen, den code zu refactoren. aber mit bedacht. denn es kann genau das passieren, was der autor des artikels erwähnte: man schmeisst irgendwelche hacks raus, weil sie einem unnötig erscheinen. und 2 wochen später steht kunde Y vor der tür, der die anwendung auf nem citrix server mit windows 98 clients laufen lässt und beschwert sich, dass keine dialoge mehr angezeigt werden
-
thordk schrieb:
und solange man an diesen code nicht ranmuss, weil man ihn erweitern will, gibt es kaum einen grund, ihn neu zu schreiben.
Sicher, aber darum kann es ja wohl kaum gehen. Niemand, der von seiner Software leben muss, geht das Risiko einer Neuimplementation ohne Grund ein.
Joel sagt, Code würde nicht von selbst rosten. Da hat er durchaus recht, allerdings steht Code ja nicht einfach so in der Gegend rum. Da wird normalerweise schon hin und wieder was erweitert, verbessert, gefixt. Im Laufe der Zeit "verrottet" der Code.
-
Wenn man ein gutes Design hat und die implementation nach belieben austauschen kann, "verrotet" da gar nichts. Da tauscht man einfach das entsprechende Modul aus und der Rest des Systems merkt davon nichts.
Aber ich wollte einfach nur anmerken das es fast immer so ist, dass alter Code haesslich und schlecht aussieht und man immer in der Versuchung ist diesen Code wegzuwerfen und von vorne anzufangen. Dabei bietet Refactoring einem eine bessere Alternative: Man baut das Geruest neu, dass aus dem gut getesteten und von bug gefixen Code enthaelt.