Forum: Ausbildung, Studium & Beruf Was ist richtig, was ist falsch?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Be B. (bebo)


Bewertung
-5 lesenswert
nicht lesenswert
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.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.
von Weich W. (hand_werker)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Manfred (Gast)


Bewertung
7 lesenswert
nicht lesenswert
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.

von Weich W. (hand_werker)


Bewertung
-6 lesenswert
nicht lesenswert
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.

von Mark S. (voltwide)


Bewertung
0 lesenswert
nicht lesenswert
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
von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Peter (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Irgend W. (Firma: egal) (irgendwer)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Michael B. (laberkopp)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Felix U. (ubfx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Reinhard S. (rezz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von IQ130+ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dr. Yes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Udo S. (urschmitt)


Bewertung
0 lesenswert
nicht lesenswert
"Real programmers can write assembly code in any language."
von Larry Wall

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Senf D. (senfdazugeber)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Motzkopp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Senf D. (senfdazugeber)


Bewertung
1 lesenswert
nicht lesenswert
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.

von klausi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.