...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
Dennis S. schrieb: > ...und vergisst sie nicht wieder? Use it or lose it.
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.
Habe ich es nicht gesagt? Hier tritt der Effekt schon auf: Beitrag "Atmel Studio probleme wenn optimization aktiv" MfG Paul
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.