Programmieren? Kurzer Einblick was so passiert...

[morly]

Hi Leute,
warum so ein langes Post? Tja: möchte mal einen kleinen Einblick ins Programmieren geben und was die beteiligten Leute hier so treiben...

Zur Erklärung - das klingt alles so leicht: "kann das mal wer fixen" - "noch immer der Fehler" - "..."
Unsere Images werden mit 2 Programmiersprachen realisiert, Python und C++. C bzw. C++ ist meiner Meinung nach eine der besten Programmiersprachen die es gibt, allerdings keine triviale Geschichte.

Zum Beispiel ist hier der Programmierer alleine fürs komplette Speichermanagement verantwortlich. Speicher den ich anfordere (wird im sog. Heap abgelegt) wird dort reserviert und nicht mehr freigegeben - dafür bin ich selber verantwortlich. Viele programmieren voller Elan darauf los, wenn alles funktioniert sind alle happy - nur vergessen viele den angeforderten Speicher wieder freizugeben. Für alle die sich etwas auskennen:

Type *myVar;
myVar = new Type;
myVar = 0;

Also: hier wird ein Pointer mit dem Typ Type angelegt und mit der zweiten Zeile (new) Speicher (im Heap) reserviert. Nur den Zeiger auf Null setzen (3. Zeile) gibt den Speicher nicht frei, da fehlt folgendes:

delete myVar;

Also: Code funktioniert, nur der Speicher wird nicht freigegeben - je öfter sowas passiert, desto weniger Speicher ist vorhanden - und das delete kann man leicht mal vergessen. Was haben wir hier: ein sog. Speicherloch ("Memory Leak"). Dieser Fehler findet sich fast überall (auch bei komm. Software).
Darum haben andere Programmiersprachen auch die sog. "Garbage Collection" (Java, C#, ...). Da genügt es wie im ersten Beispiel den Zeiger auf 0 zu setzen oder noch einfacher, dass die Variable die Gültigkeit verliert (Unterprogramm zu Ende, ...). Der "Garbage Collector" erkennt das von selber und gibt den Speicher frei... Aber das benötigt natürlich CPU Resources (ist also langsamer) - darum verzichtet C++ darauf.
Tja - aber unsere Images sind nunmal in C bzw. C++ geschrieben und glaubt mir, da fehlen so einige "delete"

Nun zum nächsten Punkt: wenn ihr etwas programmieren könnt und ich geb euch ne Aufgabe ist das wie das Lösen eines Rätsels - man arbeitet sich heran bis alles wie gefordert funktioniert. Viele vergessen den Code zu dokumentieren, also Kommentare hinzuzufügen, es geht ja eh alles. Und wenn man seinen eigenen (!!) Code ca. 4-6 Woche später wieder sieht weiss man nicht mehr was man geschrieben hat. Man benötigt auch für kleine Programme ne Weile wieder zu verstehen was man da so fabriziert hat. Sourcecode ist immer anders, auch für die selbe Aufgabe und vom selben Programmierer.

Jetzt machen wir das ganze noch schwieriger: ihr schreibt ein kleines C++ Programm und gebt es einen anderen - der soll es verstehen/Debuggen/Fehler finden. Das ist wirklich schwer und selbst für kleine Programme bedarf es grosser Übung. Wenn einer gut programmieren kann heisst es noch lange nicht das er auch gut Sources lesen kann - auch das muss man üben. Und gerade C bzw. C++ ist bekannt dafür extrem effizienten code zu schreiben - aber diese Dinger sind extrem schwer zu lesen. So wurde die Lösung des 8-Damen-Problems in 3 Anweisungen programmiert - irre!

So - und jetzt zu unseren Images: hier verstecken sich vieeeeeeeele C++ Files mit dazugehörigen Header Files - tausende und abertausende "Lines of Code" von vieeeeeelen verschiedenen Entwicklern. Zusätzlich noch Python Sources - die arbeiten natürlich zusammen. Jeder fixt etwas, dadurch entsteht was anderes, es wird was erneuert, altes bleibt bestehen, ... Seiteneffekte ohne Ende. Da muss man erst mal ansatzweise verstehen was die Programmierer alles so gemeint haben - dokumentiert ist ja auch nichts - das wird dann richtig komplex!!

Ich will nicht irgendwie den schlauen Michl mimen - aber mal einen kleinen Einblick bieten was die Leute hier machen. Und da sind mal schnell 100 Stunden vorbei ohne das man gross weiter ist. Ihr seht schon - das geht etwas weiter als ein Modellauto zu kleben oder sonstiges (nichts gegen Modellbau - ist spitze!). Kurzum, hier sind viele Leute beteiligt die in der IT-Branche richtig Geld machen könnten - die leisten super Arbeit.

Ich weiss auch, dass es niemand böse meint mit "blöder Tunerbug noch himmer nicht gefixt" oder so, aber vielleicht helfen die angeführten Zeilen einem "Nicht-Programmierer" etwas die Komplexität und Schwierigkeit zu verstehen.

Also dann,
bravo wer so weit gekommen ist und dieses riesige Post gelesen hat
wir fighten weiter und versuchen natürlich weiter Fehler auszubügeln und Neuerungen zu implementieren.

Happy Coding,
morly

[ReWard]

Danke morly für die Super Beschreibung.

Ich hoffe jetzt geht vielen mal ein Licht auf.

[Anskar]

Danke morly!
Da sag ich mir "Schuster bleib bei Deinen Leisten" ist mir alles doch zu hoch, da teste ich lieber und gebe dann Feedback.
Kapiert habe ich noch nicht mal ansatzweise etwas, liegt halt an den Grundvoraussetzungen.

Mach weiter so ! Danke für Deinen unermüdlichen Einsatz!

MfG

[morly]

Kapiert habe ich noch nicht mal ansatzweise etwas, liegt halt an den Grundvoraussetzungen.

Hi Anskar - hab ja ehrlich mit einem Feedback von dir gerechnet - auf dich ist Verlass!
Weisst: musst nicht alles verstehen (Speicher, Pointer, ...) - hab das eben geschrieben um die Komplexität anzuführen von dem was hier betrieben wird.

Und ehrlich - welchem Banker ist bewusst was er wirklich jeden Tag bedient - und welchem Arzt was er so durchklickt...

Und wenn du sagst du verstehst es nicht hab ich eins geschafft - du weisst, das es kompliziert ist

[Macbest]

Das hast du sehr gut beschrieben morly, klasse.

[balou1974]

Ich denke, debuggen(Fehlersuche) fremder Programme ist mit das Schwierigste was man sich vorstellen kann. Man muss auch bedenken, viele Dinge gibt es ohne Quelltext (Source) gerade im Receiver- und Handy-Bereich und nur weil ein Programm auf einer Architektur läuft, bedeutet es lange nicht, dass es auf anderen Architekturen ebenso läuft.
Jedes Programm greift auf Betriebsystem und Treiber zu und C oder C++ sind ja auch nur Programmier-Hochsprachen, d.h. beim Übersetzen (compilieren) wird alles in die Maschinensprache des jeweiligen Prozessors übersetzt (PPC, MIPS, ARM, SH4, x86, IA64 usw.) und anschliessend wird <gelinkt> was bedeutet, dass ein Programm für das jeweilige Betriebssystem gebaut wird (es werden dazu auch noch Daten aus fertigen Bibliotheken hinzugefügt). Aber es geht ja noch weiter, jedes System enthält duzende Chips die ihrerseits wieder eine Firmware benötigen (an die kommt man ja meist nicht ran da in den Chip gebrannt). Und dieses ganze System greift in einander, vielfach sind noch Workarounds für bekannte Fehler nötig, da fertige Chips nur sehr schwer gefixt werden können. Das bedeutet man umgeht ein bekanntes Problem (nicht immer elegant). Also mal eben ist nicht ... Selbst Firmen wie Intel liefern gleich einige Dokumente mit die bekannte CPU-Fehler auflisten. Allerdings gibt es bei AMD und Intel den Microcode der beim Rechnerstart in den Prozessor geladen wird und vieles fixen soll. Ob es sowas auch im Embeddedbereich gibt kann ich nicht sagen. "Mal eben" oder "mal schnell" ist schwer beim Programmieren.

Daher ein fettes DANKE SCHÖN an die Team-Leute !!!

[morly]

Ich denke, debuggen(Fehlersuche) fremder Programme ist mit das Schwierigste was man sich vorstellen kann.

Genau das wollte ich ausdruecken. Ein bekannter Programmierer sagte mal zu mir: ich schreibe so viele Hacks wie moeglich, Kommentiere entweder unwichtiges oder falsch und erzeuge Code den niemand wirklich lesen kann (in seiner Programmierbude) - auf die Frage warum antwortete er: weil meinen Code niemand verstehen, warten oder aendern kann - somit bin ich unkuendbar...
Anmerkung: er ist nicht mehr bei dieser Firma...

[svox]

weil meinen Code niemand verstehen, warten oder aendern kann - somit bin ich unkuendbar...
Anmerkung: er ist nicht mehr bei dieser Firma...

Hehe und er hat es sicherlich ernst gemeint.

[BPanther]

@morly: Danke, wirklich gut beschrieben.