Habt ihr das auch schon erlebt? Es gibt Programmiersprachen mit vielen tollen Features. Und dann kommen "erfahrene" Kollegen daher und behaupten, daß man schlecht programmiert, weil man die Features der Sprache nutzt, wie sie gedacht sind, statt sich an irgendwelche Hochschul Weisheiten zu halten. Z.B. static Variablen sind böse, weil man sie schlecht testen kann. Warum hat die Sprache dann solche bösen static Variablen, wenn man sie nicht nutzen soll? Oder Interfaces werden für alles verwendt, weil das guter Programierstiel sein soll. Dabei sind Interface Funktionsaufrufe häufig die, für die der Prozesser die meißten Befehle ausführen muß. Ist das, was an der Uni gelehrt wird, wirklich gut? Oder ist es nur guter Stiel, für den man einen hohen Preis zahlt. Meißtens aus Performance Sicht.
Be B. schrieb: > Ist das, was an der Uni gelehrt wird, wirklich gut? Studium ist jenseits von Gut und Böse, da bekommt man eben alles gezeigt was geht und wie man es je nach Blickwinkel und Anwendungsgebiet bewertet.
Beitrag #6366142 wurde von einem Moderator gelöscht.
Beitrag #6366147 wurde von einem Moderator gelöscht.
Beitrag #6366152 wurde von einem Moderator gelöscht.
Als Einsteiger solltest du erst mal zuhören und alles machen, was dir gesagt wird. Besonders wenn die Bezahlung gut ist. Ist doch nicht dein Problem, wenn die Alten alles machen wollen wie seit 50 Jahren und dann alles länger dauert.
Weich W. schrieb: > Ist doch nicht dein Problem, > wenn die Alten alles machen wollen wie seit 50 Jahren > und dann alles länger dauert. Ganz ärgerlich wird es dann, wenn die Software der Alten auch noch stabil funktioniert.
Tut sie spätestens dann nicht mehr, wenn der Support der verwendeten Frameworks endet und dann jährlich Millionen für die Wartung bezahlt werden müssen.
Bin selbst so ein alter Knabe, der irgendwann anfing Atmel-uCs in C zu programmieren. Zum Brennen nahm ich Burn-O-Mat, unter Linux. Das klappte irgendwann nicht mehr weil die passende JAVA-Version nicht ohne Weiteres zu haben war. Also gewechselt auf das darunterliegende Kommandozeilen-tool AVRdude, ein einzeiliges bash-script erstellt und seitdem gibt es keine Probleme mit dem flashen. Zu Anfang habe ich programmiert mit AVR-Eclipse IDE- war irgendwie recht sperrig. Also gewechselt auf Codeblocks. Das aber ist ab LMDE3 unstabil und seit LMDE4 absolut unbrauchbar - offensichtlich gibt es dafür keinen Support mehr. Also hab ich mal hier ins AVR-Forum gesehen und mich etwas aufgeschlaut zum Thema. Und dort findet sich ein wenig kryptischer Befehlscode, den man an den Anfang des Quelltextes stellt und nun läuft Kompilieren & Flashen in ca 2 sec von der Kommandozeile aus. Wirklich schade, dass ich das jetzt erst entdeckt habe - vielen Dank dafür an die Entwickler. Fazit - wenn man eine Möglichkeit findet, die aufgeblähte GUIs zu umgehen und vor der Kommandozeile nicht zurückschreckt, kann man sich in der Zukunft eine Menge an Komplikationen ersparen. Es ist eben auch bei Linux sehr wohl zu spüren, wenn man mit seinen Lieblingsspielzeugen allmählich in eine Nischenecke gelangt.
:
Bearbeitet durch User
Ohne Beispiele macht es wenig Sinn. Be B. schrieb: > Z.B. static Variablen sind böse, weil man sie schlecht testen kann. > Warum hat die Sprache dann solche bösen static Variablen, wenn man sie > nicht nutzen soll? Das Argument (schlecht testen) ist ja richtig. Wenn das kein Problem ist, sind sie sprachlich sinnvoll. > Oder Interfaces werden für alles verwendt, weil das guter > Programierstiel sein soll. Dabei sind Interface Funktionsaufrufe häufig > die, für die der Prozesser die meißten Befehle ausführen muß. "Interface" hat erstmal viele Gesichter. Und ob er häufig dafür die meißten Befehle ausführen muß oder er es meistens nicht muss, ist sicher individuell. > Ist das, was an der Uni gelehrt wird, wirklich gut? Oder ist es nur > guter Stiel, für den man einen hohen Preis zahlt. Meißtens aus > Performance Sicht. Es ist erstmal eine Art von Struktur, die man kennen sollte. Im täglichen Leben gibt es dann noch viele andere, die auch ihre Berechtigung haben. Endlos lange Namen und Routinen mit 10 LOC und 20 Kommentarzeilen lernt man natürlich eher auf der Uni. Wenn man dann aber Safety-Code macht oder unterschiedlich erfahrene Entwickler, dann begegnet man dem auch in RL.
Be B. schrieb: > Habt ihr das auch schon erlebt? > > Es gibt Programmiersprachen mit vielen tollen Features. Und dann kommen > "erfahrene" Kollegen daher und behaupten, daß man schlecht programmiert, > weil man die Features der Sprache nutzt, wie sie gedacht sind, statt > sich an irgendwelche Hochschul Weisheiten zu halten. Code schreibt man i.d.R. nicht für sich selbst und er wird viel öfter gelesen (von einem selbst und von anderen) als er geschrieben wird. Daher sollte man ein offenes Ohr für Meinungen und sachliche Kritik von Anderen/Kollegen haben. Nur weil eine Sprache ein Feature anbietet, bedeutet das nicht, dass dessen Verwendung immer gerechtfertigt ist. > Z.B. static Variablen sind böse, weil man sie schlecht testen kann. > Warum hat die Sprache dann solche bösen static Variablen, wenn man sie > nicht nutzen soll? Deine Kollegen sind gut, denn sie argumentieren sachlich. Es stimmt, dass man statische Variablen schlecht testen kann. Die Frage, die du mit den Kollegen diskutieren solltest, ist, welche Alternativen bietet dir die Sprache oder wie kannst du den Nachteil beim Testen ausgleichen. Oder ist die Verwendung statischer Variablen in diesem Fall gegenüber anderen Optionen gerechtfertigt. Es hilft aber definitiv nicht ad hominem zu argumentieren, z.B. indem du die Kollegen wegen ihres Alters oder sie als "erfahren" in Anführungszeichen herab würdigst. Man sollte offen für sachliche Kritik sein, egal wie lange jemand schon programmiert (das gilt auch für "die Alten"; zudem ist es eine Binse, denn genau das ist die Definition von "sachlich": Unabhängigkeit vom Subjekt). > Oder Interfaces werden für alles verwendt, weil das guter > Programierstiel sein soll. Dabei sind Interface Funktionsaufrufe häufig > die, für die der Prozesser die meißten Befehle ausführen muß. Du solltest nochmal das Kapitel zu dynamischer und statischer Polymorphie lesen. > Ist das, was an der Uni gelehrt wird, wirklich gut? Oder ist es nur > guter Stiel, für den man einen hohen Preis zahlt. Meißtens aus > Performance Sicht. Vorsicht: premature optimization. Der heilige Grahl ist natürlich sowohl die Lesbarkeit des Programms als auch die Performanz durch die Verwendung eines Sprachfeatures zu verbessern.
Be B. schrieb: > Z.B. static Variablen sind böse, weil man sie schlecht testen kann. > Warum hat die Sprache dann solche bösen static Variablen, wenn man sie > nicht nutzen soll? Du musst bedanken das die Programmiersprache auf die du hier gerade anspielst rund 50 Jahre alt ist und noch sehr viel effektivere Möglichkeiten besitzt um dich selbst ins Knie zu schießen. Und warum sind die immer noch alle drin? Die Antwort lautet wie so oft Komptabilität mit vorhergehenden Versionen. Da wir vieles über Jahrzehnte mitgeschleppt obwohl man mittlerweile weiß dass das problematisch ist und man besser einen anderen Weg nimmt. In einer "Guten" Programmiersprache gibt es mindestens 1000 verschiedenen Möglichkeiten um ans selbe Ziel zu kommen - und nicht alle werden unter allen Randbedingungen gleichwertig funktionieren:-) Das mit den static ist nicht nur mit einer Kleinkalieber ins Knie schießen, das ist schon sich mit beiden Knien unter einen Panzer legen. Eine kleine static variable in einer Funktion die von einer Funktion aufgerufen wird wie wiederum von einer Funktion aufgerufen wir die in einer multi-thread Umgebung läuft und du suchst dir einen Wolf warum da sporadisch falsche Daten fabriziert werden. Da sollte man sehr sehr genau wissen wann, wie, wo und vorallem warum man sowas unbedingt einsetzten will. Richtig schön wird das wenn sowas z.B. in einem Framework drin ist den man zugekauft hat um etwas Zeit bei der Realisierung zu Sparren und man dann am Ende ein vielfaches der ursprünglich geplanten Zeit für die Fehlersuche benötigt. An solche Probleme haben die Erfinder der Sprache noch nicht mal im Traum dran gedacht das es die jemals geben wird, genauso wenig die die Schreiber frühere Standardbibliotheken und schon garnicht die die es bis heute noch nicht geschafft haben über ihren 8-Bit AVR Horizont hinaus zu blicken.
Manfred schrieb: > Ganz ärgerlich wird es dann, wenn die Software der Alten auch noch > stabil funktioniert. Weich W. schrieb: > Tut sie spätestens dann nicht mehr, wenn der Support der verwendeten > Frameworks endet und dann jährlich Millionen für die Wartung bezahlt > werden müssen. Erfahrene Softwareentwickler verwenden keine Frameworks, schon gar keine die sich so lange automatisch updaten bis sie nicht mehr funktionieren. Irgend W. schrieb: > Du musst bedanken das die Programmiersprache auf die du hier gerade > anspielst rund 50 Jahre alt ist und noch sehr viel effektivere > Möglichkeiten besitzt um dich selbst ins Knie zu schießen. > Und warum sind die immer noch alle drin? Die Antwort lautet wie so oft > Komptabilität mit vorhergehenden Versionen Wohl auch, weil sie sich bewährt haben. Selbst wenn mit Java aufgewachsene sich nicht denken können, wozu man pointer und DLLs braucht, wie eine Software die nicht minutenlang vom garbage collector aufgehalten wird funktionieren kann, wieso man Interoperabilität will statt closed environment.
:
Bearbeitet durch User
Michael B. schrieb: > Erfahrene Softwareentwickler verwenden keine Frameworks Endlich werden hier mal Nägel mit Köpfen gemacht. Erfahrene Softwareentwickler nutzen nicht nur keine Frameworks, sie nutzen generell gar nichts, was von anderen entwickelt wurde, da es sich dabei erfahrungsgemäß um Spaghetticode handelt. Erfahrene Softwareentwickler verwenden auch generell keine VM-Sprachen, da sie wissen, dass nur eine ordnungsgemäß nativ kompilierte Konsolenapplikation die nötige Performance liefert. Konzepte wie garbage collection oder run time checks sind prinzipiell minderwertig und wurden für unerfahrene Programmierer geschaffen.
Manfred schrieb: > Weich W. schrieb: >> Ist doch nicht dein Problem, >> wenn die Alten alles machen wollen wie seit 50 Jahren >> und dann alles länger dauert. > > Ganz ärgerlich wird es dann, wenn die Software der Alten auch noch > stabil funktioniert. Wobei dahin ja viele Wege führen.
Reinhard S. schrieb: > Manfred schrieb: >> Ganz ärgerlich wird es dann, wenn die Software der Alten auch noch >> stabil funktioniert. > > Wobei dahin ja viele Wege führen. Aber allen modischen Ansätzen zu folgen und System von Grünschnabeln von der Uni ohne nennenswerte Berufserfahrung machen zu lassen ist sicher kein bewährter Weg die geforderte Stabilität in akzeptabler Zeit und innerhalb des bewilligten Kostenrahmens zu erreichen.
Immer wieder schön euren Egos beim sich Profilieren zuzuschauen. Wer ist hier der beste Programmierer und wer der allerbeste? Große Kinder hinter großen Bildschirmen.
"Real programmers can write assembly code in any language." von Larry Wall
Felix U. schrieb: > Erfahrene > Softwareentwickler nutzen nicht nur keine Frameworks, sie nutzen > generell gar nichts, was von anderen entwickelt wurde, da es sich > dabei erfahrungsgemäß um Spaghetticode handelt. Erfahrene > Softwareentwickler verwenden auch generell keine VM-Sprachen, da sie > wissen, dass nur eine ordnungsgemäß nativ kompilierte > Konsolenapplikation die nötige Performance liefert. Konzepte wie garbage > collection oder run time checks sind prinzipiell minderwertig und wurden > für unerfahrene Programmierer geschaffen. Nicht das Kind mit dem Bade ausschütten. So wie wir heute ganz klar die werthaltigen Autos oder Möbel oder Haushaltsgeräte erkennen können (die, die es noch gibt), so kann man heute die soliden Frameworks, Sprachen und Tools erkennen. Und ja, die meisten grafischen fancy Tools und Werkzeuge oder auch GC-Sprachen werden geschaffen, um es Anfängern möglichst einfach zu machen. Dass dabei die allermeisten IDE-basierten Klick-Bunty-Codegeneratoren genauso schnell verschwanden wie sie kamen, dass Rust GC nicht mehr kennt, etc. bedeutet nur, dass ein erfahrener Entwickler nicht mehr auf jeden neuen Zug aufspringen muss um mitzuhalten. Kann er auch garnicht. Jedes Jahr kommen Leute aus der Schule oder Uni, die ihr "ganzes Leben" nur (Python, Rust, ...) kennen und nicht nebenher eine 40-Stundenwoche mit solider Technik hatten.
A. S. schrieb: > Jedes Jahr kommen Leute aus der Schule oder Uni, die ihr "ganzes Leben" > nur (Python, Rust, ...) kennen und nicht nebenher eine 40-Stundenwoche > mit solider Technik hatten. Die Grünschnäbel lernen es nach 5 - 10 Jahren im Beruf aber auch noch, dass es nicht gut ist jedem Trend blind hinterherzulaufen.
Senf D. schrieb: > A. S. schrieb: > Jedes Jahr kommen Leute aus der Schule oder Uni, die ihr "ganzes Leben" > nur (Python, Rust, ...) kennen und nicht nebenher eine 40-Stundenwoche > mit solider Technik hatten. > > Die Grünschnäbel lernen es nach 5 - 10 Jahren im Beruf aber auch noch, > dass es nicht gut ist jedem Trend blind hinterherzulaufen. Das kommt automatisch, wenn man genügend Supportfälle und Produktionsprobleme selbst unter Hochdruck lösen musste. Wenn einer der Grünschnäbel in dem Bereich mitarbeitet, wo ich ggf. die Probleme auf den Tisch bekomme, dann unter meinen altbackenen Regeln, ansonsten kann er alles dann komplett alleine und eigenverantwortlich machen und ich Sorge dafür, dass er die Scheisse möglichst selbst ausbadet.
Motzkopp schrieb: > ansonsten kann er alles dann komplett alleine und eigenverantwortlich > machen und ich Sorge dafür, dass er die Scheisse möglichst selbst > ausbadet. Lernen durch Schmerz ist sehr effektiv.
Motzkopp schrieb: > kann er alles dann komplett alleine und eigenverantwortlich machen und > ich Sorge dafür, dass er die Scheisse möglichst selbst ausbadet. Sehr gute Strategie! Wie gehst du da vor, dass sich die Leute an deine Regeln halten?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.