...und vergisst sie nicht wieder? Hintergrund der Frage ist, dass ich
irgendwo den (zweifelhaften) Tipp gelesen habe jedes Jahr eine neue
Programmiersprache zu lernen.
Auf der einen Seite finde ich das durchaus sinnvoll sich zumindest auf
dem neusten Stand zu halten auch wenn das Neuste nicht unbedingt das
Beste sein muss.
Anderseits müsste man sich auch überlegen was es heißt eine Sprache
gelernt zu haben. Ein Buch lesen reicht meiner Meinung nach nicht und
ein Jahr um eine Sprache komplett zu durchdringen halte ich dann schon
für anspruchsvoll.
Wie haltet ihr das?
Gruß
Dennis
Ich bin der Meinung man lernt eine Sprache dann, wenn man sie braucht.
Die Syntax hat man ja in kürzerster Zeit drauf, da sie sich doch alle
sehr ähneln. Die Grundkonzepte sind natürlich interessanter. Wer sich
z.B. in Assembler, C und C++ auskennt, der hat sich auch schnell in
andere Sprachen eingearbeitet.
Dennis S. schrieb:> ...und vergisst sie nicht wieder? Hintergrund der Frage ist, dass ich> irgendwo den (zweifelhaften) Tipp gelesen habe jedes Jahr eine neue> Programmiersprache zu lernen.
Richtig, der Tipp ist sehr zweifelhaft.
> Auf der einen Seite finde ich das durchaus sinnvoll sich zumindest auf> dem neusten Stand zu halten auch wenn das Neuste nicht unbedingt das> Beste sein muss.
Warum "neuester Stand"? Programmiersprachen sind kein Selbstzweck.
Und so viel hat sich da in den letzten Jahrzehnten nicht getan.
> Anderseits müsste man sich auch überlegen was es heißt eine Sprache> gelernt zu haben. Ein Buch lesen reicht meiner Meinung nach nicht und> ein Jahr um eine Sprache komplett zu durchdringen halte ich dann schon> für anspruchsvoll.
Eben.
> Wie haltet ihr das?
Man lernt genau die Sprachen, die man auch verwendet und davon gibt es
vielleicht zwei, drei.
Bei Sprachen, die Du nicht verwendest, fängst Du nach einem Jahr wieder
bei Null an, die investierte Zeit ist verloren.
Reinschnuppern ist noch etwas anderes: ob einem eine Sprache zusagt,
muss man ja irgendwie ermitteln :-)
Die einzige Möglichkeit eine Programmiersprache zu lernen ist, aktiv zu
programmieren. Bücher lesen bringt da nichts, wenn Du das Gelesene nicht
gleich anwendest.
Und Nachhaltig geht da nichts, wenn Du ein Jahr nicht programmiert hast,
stehst Du fast wieder wie ein Anfänger vor der Sprache... Ist halt sehr
komplex.
Nimm Dir ein Projekt, fang an und programmiere. Dann lernst Du viel
mehr. Bücher und Internet helfen Dir, wenn Du beim Anwenden nicht weiter
kommst.
Man hat eigentlich -wie bei Sprachen auch- nur dann einen Nutzen davon
und behält sie auch ausreichend gut im Kopf, wenn man sie dann auch
zumindest sporadisch nutzt. Ansonsten läge wohl der einzige echte Nutzen
davon, jedes Jahr eine neue Sprache zu lernen nur in sich verbessernder
Lernmethodik -und Lernfähigkeit.
Der Nutzen ist aber wirklich fraglich, m.E. liegt der weitaus größte
Aufwand (und Nutzen) eben nicht im Lernen der Sprache, sondern vielmehr
in der Kenntnis des entsprechenden Umfelds, d.h. der Libraries,
Frameworks etc. .
Dennis S. schrieb:> Hintergrund der Frage ist, dass ich irgendwo den (zweifelhaften) Tipp> gelesen habe jedes Jahr eine neue Programmiersprache zu lernen.
Ich würde mich da grundlegend fragen:
WOZU soll das GUT sein?
WAS ist das ZIEL, das damit erreicht werden soll?
Lothar M. schrieb:> WAS ist das ZIEL, das damit erreicht werden soll?
Ist doch klar:
Wer hat den Größten?
ähh...
Wer hat die größte... Liste in der Vita...
Vlad T. schrieb:> Lothar M. schrieb:>> WAS ist das ZIEL, das damit erreicht werden soll?>> Ist doch klar:> Wer hat den Größten?> ähh...> Wer hat die größte... Liste in der Vita...
Kann alles, aber nichts richtig.
So blöd sind die in der Personalabteilung doch auch nicht.
mfg.
Vlad T. schrieb:> Lothar M. schrieb:>> WAS ist das ZIEL, das damit erreicht werden soll?>> Ist doch klar:> Wer hat den Größten?
Nicht notwendig. Eine Sprache dafür extra zu lernen ist sicher
übertrieben, aber für mindestens einen Zweck ist das schon ganz
sinnvoll: Man kriegt teils eine ganz andere Sichtweise auf bestimmte
Themenstellungen und Probleme, wenn man das mal im Kontext einer
-konzeptuell evtl. ganz anderen- Programmiersprache betrachtet.
Thomas E. schrieb:> So blöd sind die in der Personalabteilung doch auch nicht.
Darauf würde ich nicht wetten...
Ich bin der Meinung, daß es am Vernünftigsten ist, sich mit EINER
Programmiersprache zu befassen und diese so gut wie möglich zu
beherrschen.
Das Beherrschen betrifft vor Allem die Eigenarten und syntaktische
Fallstricke. Man schreibt sich auf Papier in 5 Minuten einen
symbolischen Ablaufplan, spielt ihn mit Bleistift und Radiergummi auf
Plausibilität durch und dann sucht man 5 Wochen nach der richtigen
Syntax für die jeweiligen Befehle.
Vor Allem sollte man jedwede "Optimierungs-Varianten" des Kompilers
abschalten, denn schließlich möchte man SEIN Programm laufen haben und
nicht das, was der Kompiler meint, daraus erzeugen zu wollen.
MfG Paul
Diese Frage hier zu stellen, könnte man schon fast als Provokation
auffassen. Hier sind ja Assembler und gerade noch C akzeptabel, alles
andere ist schon unnötig. Im Mikrocontroller-Kontext auch verständlich.
Aber außerhalb eines so eingeschränkten Bereichs ist dieser Tipp gar
nicht schlecht. Martin Luerssen hat es schon angesprochen. Es geht nicht
darum, die Sprachen perfekt zu beherrschen, sondern eine andere
Blickweise auf Programmierung allgemein zu bekommen. Es gibt so viele
Möglichkeiten zu programmieren (imperativ, deklarativ, objektorientiert,
funktional, mit dynamischer Typisierung,...), und viel davon versteht
man erst, wenn man mit einer entsprechenden Sprache gearbeitet hat. Und
oft merkt man dann, wie elegant sich gewisse Probleme eigentlich lösen
lassen, und dass man das auch in seiner "Stammsprache" ähnlich umsetzen
kann.
Paul B. schrieb:> Das Beherrschen betrifft vor Allem die Eigenarten und syntaktische> Fallstricke. Man schreibt sich auf Papier in 5 Minuten einen> symbolischen Ablaufplan, spielt ihn mit Bleistift und Radiergummi auf> Plausibilität durch und dann sucht man 5 Wochen nach der richtigen> Syntax für die jeweiligen Befehle.
Bitte was...? Selbst ein Anfänger dürfte nach ein paar Tagen jeden
Algorithmus, den er sich "aufmalen" kann, auch in der Sprache umsetzen
können.
Paul B. schrieb:> Vor Allem sollte man jedwede "Optimierungs-Varianten" des Kompilers> abschalten, denn schließlich möchte man SEIN Programm laufen haben und> nicht das, was der Kompiler meint, daraus erzeugen zu wollen.
Und das ist jetzt wirklich Unsinn, den du da erzählst. Die
Compiler-Optimierungen können gut und gerne Faktor 100 bei der
Performance bringen. Und der Compiler macht ganz genau das daraus, was
DU willst. Der MEINT überhaupt nicht, der WEISS haargenau wie es geht.
P. M. schrieb:> Und der Compiler macht ganz genau das daraus, was DU willst.
Oh nein! Der macht genau was du ihm sagst, nicht was du willst.
Das kann ein himmelweiter Unterschied sein.
Alle Versuche, einen do-what-I-mean-not-what-I-say Compiler zu
produzieren, sind kläglich gescheitert.
P. M. schrieb:> Bitte was...? Selbst ein Anfänger dürfte nach ein paar Tagen jeden> Algorithmus, den er sich "aufmalen" kann, auch in der Sprache umsetzen> können.
Nicht: "Bitte was?" sondern "Bitte richtig und Alles zitieren, was
dazu gehört!
Paul B. schrieb:> Ich bin der Meinung, daß es am Vernünftigsten ist, sich mit EINER> Programmiersprache zu befassen und diese so gut wie möglich zu> beherrschen.
Vielleicht haben verschiedene Sprachen auch völlig verschiedene Syntax?
Könnte das sein? Desahlb riet ich dazu, EINE Sprache zu erlernen und
diese zu beherrschen.
P. M. schrieb:> Und das ist jetzt wirklich Unsinn, den du da erzählst. Die> Compiler-Optimierungen können gut und gerne Faktor 100 bei der> Performance bringen.
Wenn das Programm zu Anfang nicht fehlerfrei ist, dann ist es sehr
sinnvoll, KEINE Optimierung eingestellt zu haben, BIS man den Fehler
eindeutig gefunden hat. Ein anderes Vorgehen erzeugt mehr Schaden als
Nutzen.
Das kannst Du für Unsinn halten oder nicht.
MfG Paul
Programmieren (oberhalb von Knight-Rider-Lauflichtern in Assembler) ist
zu 90% Einstellungssache und Architekturverständnis. Die Sprache ist nur
ein Implementierungsdetail.
Es geht überhaupt nicht darum, irgendwelche APIs oder Libs auswendig zu
können -- auch wenn einige unter "Programmieren können" genau das
verstehen -- sondern um höhere Konzepte und Herangehensweisen. Und ums
Neugierigbleiben. Im weitesten Sinne Kultur und Allgemeinbildung statt
Fachidiotie.
M. M. schrieb:> Wer sich z.B. in Assembler, C und C++ auskennt, der hat sich auch schnell in> andere Sprachen eingearbeitet.
Und wer sich in Perl auskennt will niewieder umsteigen :-)
Paul B. schrieb:> Wenn das Programm zu Anfang nicht fehlerfrei ist, dann ist es sehr> sinnvoll, KEINE Optimierung eingestellt zu haben, BIS man den Fehler> eindeutig gefunden hat.
Das mag auf die Phase zutreffen, in der man sich noch mit der
korrekten Syntax einer Programmiersprache herumschlägt und hernach
noch hinreichend viele Schusselfehler macht.
Später dagegen hilft dir das gar nicht, denn ein nicht optimiertes
Programm verhält sich erstens zeitlich völlig anders als das
optimierte (und wenn man nicht massig Überkapazitäten an Speicher
und Rechenzeit eingeplant hat, dann kann es gut sein, dass die Aufgabe
damit gar nicht lösbar ist), und oft genug merkt man die Fehler erst
dann, wenn die Optimierung aktiviert wird und der Compiler nicht mehr
stur eine 1:1-Umsetzung der aufgeschriebenen Zeilen generiert. Ein
Klassiker bei der Sprache C wäre ein vergessenes "volatile".
Tom K. schrieb:> Programmieren (oberhalb von Knight-Rider-Lauflichtern in Assembler) ist> zu 90% Einstellungssache und Architekturverständnis. Die Sprache ist nur> ein Implementierungsdetail.
Für viele Sprachen trifft das zu. Gerade in C++ und auch in gewissen
Skriptsprachen kann man aber Dinge tun, die nicht in 80% der gängigen
Sprachen auch vorkommen. Das ermöglicht dann völlig neue
Architekturansätze, ABER auch eine genaue Kenntnis der Sprache. Das ist
dann kein Implementierungsdetail mehr, da man es nicht 1:1 auf andere
Sprachen übertragen kann.
Nicht jede Sprache ist für den vorgesehenen Zweck geeignet.
Btw, Assembler ist eigentlich ein Werkzeug, das Programme in
Madchinensptrache in Machinencode übersetzt.
Paul B. schrieb:> Hier tritt der Effekt schon auf:
Ja, und? Weil ein Programm buggy ist, feilt man so lange am Compiler,
bis er einen Würgaround für den Bug gefunden hat, oder was wolltest
du damit sagen?
Jörg W. schrieb:> Ja, und? Weil ein Programm buggy ist, feilt man so lange am Compiler,> bis er einen Würgaround für den Bug gefunden hat, oder was wolltest> du damit sagen?
Ich wollte damit das Gleiche sagen, wie Vorgestern auch:
Paul B. schrieb:> Wenn das Programm zu Anfang nicht fehlerfrei ist, dann ist es sehr> sinnvoll, KEINE Optimierung eingestellt zu haben, BIS man den Fehler> eindeutig gefunden hat. Ein anderes Vorgehen erzeugt mehr Schaden als> Nutzen.
MfG Paul
Dennis S. schrieb:> Wie lernt man eine Programmiersprache> ...und vergisst sie nicht wieder?
1. Buch oder Tutorial durcharbeiten
Durcharbeiten ist dabei aber mehr als das einmalige Durchlesen des Buchs
von der ersten bis zur letzten Seite und das Copy/Pasten der Beispiele.
Durcharbeiten umfasst vor allem auch das Zurückblättern im Buch, um
Dinge, die in früheren Kapiteln behandelt wurden, zu festigen, sowie das
Verändern und Erweitern der Beispielprogramme, um zu sehen, ob man das
Gelesene wirklich verstanden hat.
2. Selber nichttriviale Programme schreiben
Die in den Büchern gezeigte Beispiele sind meist sehr einfach gehalten
und überwiegend auf die Stärken der jeweiligen Programmiersprache
fokussiert. Erst bei einem "richtigen" Projekt zeigt sich, wie sich die
jeweilige Sprache in unterschiedlichen Teilaspekten wie Datentypen, I/O,
Abstraktionsmöglichkeiten usw. schlägt. Falls man dabei auf scheinbar
unüberwindliche Schwierigkeiten stößt, sollte man auch nicht sofort
aufgeben und die Sprache ad acta legen, sondern mittels Internetsuche
das Problem lösen. Ob die Sprache für einen taugt oder nicht, kann man
frühesten dann beurteilen, wenn man mindestens ein mittelgroßes Programm
mit nicht allzu einfachen Ablauf- und Datenstrukturen fertiggestellt
hat.
3. Mit Fortgeschrittenen diskutieren
Nämlich über Softwarestrukturierung, bewährte Vorgehensweisen,
Implementierungstechniken, Optimierungsmöglichkeiten, usw. in der
jeweiligen Sprache anhand konkreter Beispiele. Nicht nur selber
diskutieren, sondern auch die Verfolgung der Diskussion anderer (bspw.
auf stackoverflow.com oder in einschlägigen Programmiersprachenforen
hilft sehr viel weiter.
Während Punkt 1 mit wachsender Programmiererfahrung in der jeweiligen
Sprache mehr und mehr an Bedeutung verliert, sind die Punkte 2 und 3 ein
nie endender Prozess.
> Hintergrund der Frage ist, dass ich irgendwo den (zweifelhaften) Tipp> gelesen habe jedes Jahr eine neue Programmiersprache zu lernen.
Der Tipp stammt aus dem Buch "The Pragmatic Programmer" von Andrew Hunt
und Dave Thomas.
Es dort aber nicht darum, zig Programmiersprachen bis ins letzte Detail
zu beherrschen, sondern die Programmiererei einmal von einer höheren
Warte zu betrachten, Scheuklappen abzulegen und gängige Lehrmeinungen zu
hinterfragen. Das geht am besten dadurch, dass man sich die möglichen
Alternativen nicht nur kurz anschaut, sondern sich mit ihnen etwas
intensiver auseinandersetzt.
Diese beiden Punkte finde ich besonders wichtig:
Martin L. schrieb:> Man kriegt teils eine ganz andere Sichtweise auf bestimmte> Themenstellungen und Probleme, wenn man das mal im Kontext einer> -konzeptuell evtl. ganz anderen- Programmiersprache betrachtet.Jan H. schrieb:> Und oft merkt man dann, wie elegant sich gewisse Probleme eigentlich> lösen lassen, und dass man das auch in seiner "Stammsprache" ähnlich> umsetzen kann.
Hin und wieder etwas tiefer in eine neue Sprache hineinzuschnuppern ist
für jeden, der sich nicht nur gelegentlich mit Softwareentwicklung
beschäftigt, nicht nur aufschlussreich, sondern auch nützlich.
Wenn jemand nun aber meint, er müsste auf einer Checkliste jeweils bis
zum 31.12. jedes Jahres eine neue Programmiersprache als "gelernt"
abhaken, handelt alles andere als pragmatisch und damit ganz sicher
nicht im Sinne der Autoren des o,g, Buches.
Paul B. schrieb:> Ich wollte damit das Gleiche sagen, wie Vorgestern auch:
Das hat ihm aber genau nicht geholfen: ohne Optimierung wurde sein
Bug aus irgendeinem Grunde versteckt. Er nahm folglich an, dass sein
Code in Ordnung sei, was er aber offenbar nicht ist.
Jörg W. schrieb:> Das hat ihm aber genau nicht geholfen: ohne Optimierung wurde sein> Bug aus irgendeinem Grunde versteckt. Er nahm folglich an, dass sein> Code in Ordnung sei, was er aber offenbar nicht ist.
In Ordnung.
Halt....Wieso macht man dann eine Optimierung überhaupt schaltbar?
Ich denke, daß das endet wie das Lied:
"Wenn der Topf aber nun ein Loch hat..."
Lassen wir es gut sein.
MfG Paul
Paul B. schrieb:> Halt....Wieso macht man dann eine Optimierung überhaupt schaltbar?
Zum Debuggen schaltet man die Optimierung gerne ab, da nur so Schritt
für Schritt durchgesteppt werden kann. Und früher dürfte es auch eine
Performance-Frage gewesen sein, da gewisse Optimierungen sehr aufwendig
sind.
Jörg W. schrieb:> Das hat ihm aber genau nicht geholfen: ohne Optimierung wurde sein> Bug aus irgendeinem Grunde versteckt. Er nahm folglich an, dass sein> Code in Ordnung sei, was er aber offenbar nicht ist.
Das Einschalten der Optimierung ist ja die Regel. Meines Wissens nach
sind die Compiler beim "optimierten" Modus deswegen deutlich intensiver
getestet worden als ohne. Leider hat man dann das erwähnte Problem beim
Durchsteppen.
P. M. schrieb:> Paul B. schrieb:>> Halt....Wieso macht man dann eine Optimierung überhaupt schaltbar?>> Zum Debuggen schaltet man die Optimierung gerne ab, da nur so Schritt> für Schritt durchgesteppt werden kann.
Z. T. sind Debugger und der Programmierer nicht immer in der Lage dem
optim. Code zu folgen.
Bei manchen Compilern kann der Debugger bei stark optim. Code nur noch
schwer bis gar nicht genutzt/nachvollzogen werden. Der Maschinencode ist
in solchen Fällen schwer, weil nur schwer verständlich, auf seine
Richtigkeit überprüfbar.
P. M. schrieb:> Zum Debuggen schaltet man die Optimierung gerne ab, da nur so Schritt> für Schritt durchgesteppt werden kann.
Wobei es reichlich albern ist, einen Code schrittweise durchzugehen,
der nicht der ist, den ich am Ende eigentlich benutzen will.
Dann verzichte ich lieber auf das sauber lineare schrittweise
Durchgehen, und debugge stattdessen das, mit dem ich am Ende auch
arbeiten will. Dass man sich im Enbedded-Bereich auch Debughilfen
zimmern muss (volatile deklarierte Zwischenergebnis-Variablen, mal
einen NOP, auf den man garantiert immer einen Breakpoint setzen kann
etc. pp.), gehört halt zu dem Knoffhoff, das man in der Branche sich
persönlich aufbauen muss.
Jörg W. schrieb:> Wobei es reichlich albern ist, einen Code schrittweise durchzugehen,> der nicht der ist, den ich am Ende eigentlich benutzen will.
naja, wenn man Algorithmen debuggt, geht es ja eher um logische Fehler
oder Fälle, die man übersehen hat.
Bugs, die auf Programmierfehler zurückzuführen sind, sind eher selten,
da die mit geeigneten Warnungs-Leveln direkt beim Erzeugen des Codes
bemängelt werden. Klar gibt es solche Release-Mode-Only Bugs. Aber die
große Mehrzahl lässt sich auch mit Debugsbuild finden.
Optimalerweise entwickelt/testet man aber Algorithmen vorher ohnehin
besser auf dem PC in einer Art Softwareumgebung, die die gleichen
Schnittstellen bietet, wie das Target. -> SiL
Vlad T. schrieb:> Bugs, die auf Programmierfehler zurückzuführen sind, sind eher selten,> da die mit geeigneten Warnungs-Leveln direkt beim Erzeugen des Codes> bemängelt werden.
Widerspricht meiner Erfahrung. Wir haben eigentlich so gut wie nur
noch derartige Bugs, und auch die Warnungen helfen dann irgendwann
nicht mehr.
