Kann mann alles um eine Sprache herum wissen?
-
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.
-
DEvent schrieb:
Wenn man ein gutes Design hat und die implementation nach belieben austauschen kann, "verrotet" da gar nichts.
Dann gibt es ja auch keinen Grund, den Code wegzuwerfen. Die Probleme fangen an, wenn diese Voraussetzungen nicht gegeben sind.
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.
Stimmt, man muss den Code durch Refactoring am Leben halten, damit er nicht verrottet.
-
Hi,
wenn interressiers schon ob man in einer Sprache alles weiß? Und spätestens wenn man wirklich alles weiß kommt die nächste Sprachrevision und die Sprache entwickelt sich weiter. So ist nun mal das Leben.
Man arbeitet ja nicht um Compiler glücklich zu machen, sondern um eine Augabe zu lösen. und da hat immer noch die Regel, die mir mein allererster Programmierlehrer mal beigebracht hat gültigkeit:
"Die Kunst besteht im Weglassen!"Wo ist der Unterschied, ob ich nur mit ein paar Möglichkeiten der Sprache arbeite oder die komplette Sprachensau auf meine Auzfgabe loslasse.
Ein Programm ist ein Konstrukt, das eine bestimmte Aufgabe zu erfüllen hat. Sein Wert wird daran gemessen, wie gut es diese Aufgabe erfüllt. Also muß es vor allem korrekt und zuverlässsig sein.
Selbst die von vielen so beschworene Performance und Ressourcenschonung ist in vielen Bereichen für die Katz (das Programme trotzdem ein vernünftiges Zeitverhalten aufweisen sollten ist natürlich klar).
Was kostet denn heute noch Speicherplatz oder Rechnergeschwindigkeit oder Arbeitsspeicher. Für Programme, die auf einer Vielzahl von Computern laufen sind das sicher noch Argumente, aber für Programme, die nur für einen eng begrenzten Aufgabenkreis geschrieben sind sitzt die teuerste Ressource eindeutig 30 cm vor dem Rechner. Also muß vor allem mit dieser Ressource sparsam umgegangen werden.Wichtig ist doch vor allem, daß man das Programm in vernünftigem Zeitrahmen hinbekommt, daß man auch am Ende der Programmierung noch jedes Detail des Programms versteht, daß es so formuliert ist, daß man selbst es auch nach 10 Jahren noch überblickt und problemlos warten kann und das es so geschrieben ist, daß auch andere es warten und weiterentwickeln können (manchmal eher kontraproduktiv für die EIGENE Zukunft).
Vor allem IMMER davon ausgehen, daß das Programm einem noch in 10 bis 15 Jahren nachschleichen wird. NIEMALS Worten wie "nur mal schnell" glauben. Was nur mal schnell gemacht werden soll wird oft ganz schnell liebgewonnen und soll dann erweitert werden. Wenns dannn wirklich nur mal schnell zusammengerödelt ist kommt der dicke Brocken anschließend.Also versuchen, das Programm in viele kleine Aufgaben zu zergliedern und diese in Blackboxen packen, die man dann ohne zu überlegen zu einem großen zusammensetzen kann und wo man von jeder mit einem Satz sagen kann was sie macht. Was darunter im konkreten zu verstehen ist spielt nicht den Leierkasten, das richtet sich nach den konkreten Aufgaben. Es macht keinen Sinn unbedingt um jeden Preis alles mit generischer Programmierung oder Klassenhierarchien und Vererbung lösen zu wollen. Aber wenn ich eine Aufgabe habe die danach ruft, dann muß ich es eben nehmen. 'Das heist aber nicht, daß es für die nächste Aufgabe auch wieder sinnvoll ist.
Wichtiger als die 100%ige Beherrschung einer Programmiersprache ist doch auf jeden Fall die klare Überblickung der Aufgabe. da kann man sich nicht auf die "Inhaltszulieferer" verlassen, sondern muß das Problem selber mit durchdenken und bevor überhaupt die erste Quelltextzeile geschrieben wird, muß man so viel wie möglich Einfluss darauf nehmen, daß die Aufgabe erst mal richtig formuliert wird und nicht das Pferd vom falschen Ende aus aufgezäumt wird. Wer, wenn nicht wir soll das sonst machen, den "Inhaltszulieferern" fehlt doch vielfach die ausreichende Fähigkeit strukturiert und logisch zu denken. Die sehen NUR ihren fachlichen Hintergrund und schließen daraus auf Zusammenhänge. Wir müssen dann mit dem Wissen aus BEIDEN Ecken dafür sorgen, daß da beides zusammenkommt.
Viel wichtiger als die allseitige Beherrschung der Programmiersprache ist doch die Fähigkeit, eine Aufgabe logisch zu gliedern und zu sehen was zusammengehört und was nicht. Also erst mal die Gesamtaufgabe nehmen und versuchen mit 3-10 Begriffen/Sätzen sagen was zu machen ist. Dann jeden von den Begriffen nehmen und wieder mit 3-10 Begriffen sagen was zu machen ist. Versuchen eine Sache in verstänliche Teile gliedern, von denen ich mir auf anhieb was drunter vorstellen kann was sie machen. Wenn man das bis zur eigentlichen Funktionsweise gemacht hat, so daß man das ganze als "menschlicher Interpreter" danach abarbeiten kann ist meistens die Formulierung für Herrn Compiler die kleinste Übung. Aber solange ich mir über das wie nicht völlig im klaren bin, ist es sinnlos zu hoffen, daß mir der Quelltext schon beweisen wird, daß es geht.
Gruß Mümmel