Zitat von IK

---

Ein argumentum ad hominem ist immer auch eine argumentative Bankrotterklärung.

---

Schön, daß Du das auch so siehst. Dann war also Deine Argumentation in dem Moment bankrott, wo Du an meinen Ausführungen völlig vorbei mit Du bist von der "der Weg, den ich gegangen bin, ist eh der Beste"-Fraktion. ankamst.

Zitat

---

Der Trend hin zur objektorientierten Programmierung ist ja genau diesem modernen Ansatz geschuldet.

---

Ich habe auch schon in C objektorientiert programmiert. Ja, in C, nicht in C++. Damit hat man die Effizienz von C und die Übersichtlichkeit von C++. Der Haken ist allerdings, daß die Sprache einen nicht dazu zwingt, das auch wirklich sauber zu machen (private / public usw.), das muß man dann schon freiwillig machen.

Zitat

---

Technisch am effizientesten wäre es wohl, alles direkt in Assembler zu implementieren

---

Nein, wäre es nicht, heute nicht mehr, schrieb ich ja auch schon. Weil die Compiler heute so gut sind und die Pipelines so lang, daß man das von Hand nicht wirklich mehr besser machen kann. Ich hab auf Motorola-DSPs (die 56k-Reihe) noch in Assembler programmiert, und eine Pipeline von ein, zwei Befehlen kann man noch von Hand überblicken, aber bei heutigen CPUs geht das kaum mehr. Es dürfte nur extrem wenige Programmierer geben, die in der Lage sind, z.B. mit x86-Assembler den GCC auf seinen höheren Optimierungsleveln zu schlagen.

Daß ich Assembler dennoch für wichtig halte, liegt am vertieften Verständnis, was man daraus gewinnt. So wie man ja in der Praxis auch ein lineares Gleichungssystem einfach mit entsprechenden Befehlen in Matlab & Co löst - aber im Studium sollte man schon auch mal Gauß & Co bei kleineren Systemen in der Größenordnung von 6x6 mit Papier und Bleistift nachvollzogen haben. Oder, ein wenig trivialer, aber selber Ansatz, auch wenn man eine Division praktisch mit dem Taschenrechner macht, sollte man sie schon auch "zu Fuß" beherrschen.

Übrigens bringt Dir Assembler dann auch tieferes Verständnis, warum man gelegentlich in C sehr kuriose Effekte bekommt. Beispielsweise, wenn Du in C ein 0x00000001 (also 32bit-1) um 32bit nach links shiftest, dann bekommt man je nach Compiler und Hardware ganz unterschiedliche Ergebnisse. Auf x86 ist das Ergebnis davon nämlich 1, auf PowerpC ist es 0 (es wäre allerdings auch je nach Optimierungslevel des Compilers jedwedes andere Ergebnis zulässig - bis hin dazu, die Shift-Operation und den gesamten im Scope folgenden Code wegzulassen). Das Verhalten des x86 kommt daher, daß im Maschinenbefehl für 32bit-Shifts nur 5bit für die Shiftweite vorgesehen sind, und da die untersten 5 bit der Zahl 32 null sind, übersetzt sich das in einen Shift um 0 bit. Bei PowerPC hingegen werden dafür 6bit genutzt, folglich wird die 1 nach links rausgeshiftet, und es ergibt sich 0.

Zitat

---

So legen Java-Programme eine Performance hin wie der Musikantenstadl

---

Das ist längst vorbei. JIT-Compiler und Hotspot-Technologie machen es möglich. Java kann schnell sein, jedenfalls im Ablauf - das Starten dauert halt. Und man muß eben die JVM auch noch laden. Daß Java-Programme in der Praxis oftmals total zäh ablaufen, liegt nicht an Java, sondern daran, daß Java-Entwicklung eben nicht ganz trivial ist - oftmals werden da halt Lehrbeispiele als Codebasis genommen.

Am übelsten natürlich, wenn es um graphische Oberflächen geht, wo man bei eventgesteuertem Ablauf schon einiges verkehrt machen kann. Es geht halt einfacher, wenn man die eigentliche Arbeitsroutine direkt aus der Eventschleife heraus aufruft, aber die Schwupdizität der Software leidet dann natürlich. Man kann aber auch in der Eventschleife nur das Starten des eigentlichen Tasks anstoßen, nur ist das in der Programmierung dann halt deutlich aufwendiger, weil man sich dann die ganzen Schwierigkeiten paralleler Tasks einfängt. Wenn es nur z.B. um ein Config-Tool geht, würde ich mir den Aufwand dafür auch nicht machen.

Ein ganz paar Abstraktionsebenen darunter war das vor 10, 20 Jahren (und embedded auch heute noch) so ähnlich mit Interrupt-Programmierung.

Zitat von IK

---

Der Mensch neigt leider oft dazu, seinen eigenen Weg als den einzig Wahren hinzustellen

---

Das ist durchaus richtig, und prinzipiell wäre das ein berechtigter Einwand Deinerseits. Was mich daran allerdings irritiert hat, das war, daß ich bereits dargelegt hatte, wieso das keineswegs nur meine Perspektive ist, sondern daß genau dieser Gesichtspunkt gar zu einem in der Industrie (wie Automotive. Luftfahrt und auch Medizin) etablierten Standard geführt hat. Da ich C beherrsche, Pascal ebenfalls und mich mit MISRA befaßt habe, kann ich eben daraus den Schluß ziehen, daß man mit MISRA C auf pascalhafte Weise programmiert - und der logische Grund, wieso man überhaupt zu MISRA kam, sind die mir ebenfalls wohlvertrauten Ergebnisse der Leute, welche direkt mit C eingestiegen sind.

Natürlich will ich nicht abstreiten, daß ein wirklicher Crack auch mit C unsauber einsteigen kann und as dann hinterher aus purem Intellekt heraus dennoch absolut sauber durchziehen kann. Theoretisch ist das möglich. Praktisch sind mir Cracks dieser Art aber nur äußerst selten begegnet. Das kommt daher, daß Du solche absoluten Top-Leute auch nur für absolute Top-Gehälter bekommst, während es andererseits die Ausnahe ist, daß Kunden breit sind, auch dementsprechende Top-Preise für die resultierenden Produkte zu bezahlen.

Übrigens zum Thema Profilneurose, ich sehe mich da durchaus in der Tat als deutlich über dem Durchschnitt, weil ich immerhin die Probleme begreife und sie von vornherein umschiffe. Zur absoluten Top-Liga reicht's aber keineswegs, die würde nämlich mitten in die Problemfelder rein und es dennoch sauber machen. Wäre aber in meiner Praxis schon deswegen suboptimal, weil ich nunmal meine Programmierung so machen muß, daß durchschnittliche Kollegen ohne weiteres mit meinem Code sauber zurechtkommen können, genauso wie ich das auch von denen erwarte. Übrigens ist auch hier MISRA durchaus hilfreich, und in der Praxis haste zwei Sorten von Leuten, die sich darpber beschweren. Erstens die Top-Leute, die dadurch deutlich unter ihrem Niveau coden müssen (das ist aber die Ausnahme), und zweitens die Leute, deren Beschwerde nur zeigt, daß sie Teil des Problems dabei sind.

Zitat

---

Ich persönlich würde Java empfehlen, du aber Assembler.

---

Nein, Assembler würde ich zum Einstieg mitnichten Empfehlen, das ist ja noch schlimmer als C. Zum Einstieg würde ich sowas wie Pascal empfehlen, meinethalben auch Modula (auch wenn ich das nicht gemacht habe, aber es ist von der Idee her ähnlich). Denn da erst lernt man, strikt zwischen signed und unsigned, zwischen Integer und Float, zwischen Pointer und Integer zu trennen. In C und erst recht in Assembler ist das alles irgendwie eine Sauce, und wenn man da nicht von Anfang an klare Verhältnisse im Kopf schafft, dann ist meine praktische Erfahrung aus dem Industrieumfeld, daß es dann sehr schwer wird, das im Nachhinein noch einzuschleifen.

Und das hat nichts mit mangelndem Intellekt der Leute zu tun. Daß mir solche Dinge nämlich klar sind und anderen in meinen bisherigen Umfeldern nicht, kommt nicht daher, daß ich eine viel hellere Leuchte wäre als sie, sondern daß ich das von Anfang an richtig gelernt habe.

Ob Asembler, Pascal usw. was bringt, hängt aber natürlich schon auch davon ab, auf welcher Ebene man denn überhaupt tätig wird. Wenn man C programmiert, ist Assembler meiner Meinung nach Pflicht - also nicht, daß man es aktiv können muß, sondern es reicht durchaus, wenn man auf einer einigermaßen simplen CPU mal ein paar kleinere Tutorial-Aufgaben erfolgreich bewältigt hat, beispielsweise auf dem immer noch durchaus verwendeten guten alten Z80. Sieb des Erathostenes für Integerzahlen bis sagen wir 65k implementieren wäre da eine adäquate Übungsaufgabe. Und Pascal ist auch Pflicht, damit man überhaupt mal lernt, sauber zwischen Datentypen zu trennen, die man in C einfach casten kann.

Macht man dagegen das, was ich als eigentliche richtige Informatikertätigkeit sehe, dann ist es völlig wurscht, ob man überhaupt irgendeine Programmiersprache kann. Wichtig ist dann vielmehr, ob man ein System begreift, ob man die Spezifikationen zusammenbringt, ob man merkt, wann sie unvollständig oder widersprüchlich sind, und das Allerwichtigste dabei, daß man überhaupt in der Lage ist, zu kapieren, was der Kunde eigentlich will, und das in Specs zu übersetzen. Das hat mit Programmieren gar nichts mehr zu tun, sondern ist genau das abstrakte, mathematische Denken, was ein guter Informatiker beherrscht. Mathematiker sind da übrigens auch gar nicht mal so schlecht.

Freilich hat man dann noch nicht all die netten weiteren Dinge abgedeckt, die man heute so braucht - Synchronisation zwischen Threads, Zustandsautomaten und was weiß ich nicht alles. Das habe ich mir dann in der Praxis angeeignet, weil ich das brauchte, aber im Studium hatte ich das nicht. Dafür kann ich Dir aus dem Kopf sagen, wieso Du unter Umständen EMV-Probleme kriegen wirst, wenn Du einen Verbraucher mit Wechselspannung über stumpfe Pulsweitenmodulation regelst. Oder wieso sich gewickelte Spulen bei ausreichend hohe Frequenzen auf einmal wie Kondensatoren benehmen. Aber das ist Wissen, was man zur Software-Entwicklung nicht wirklich braucht. (;

Zitat

---

Dann kann es mit nativen Programmen immer noch nicht mithalten, weil die Übersetzung zur Laufzeit auch wieder auf die Performance geht.

---

Kommt drauf an - ja, zum Startup kostet das Zeit. Wenn das Programm aber lange läuft, ist das quasi egal. Deswegen sehe ich für Java auf Serverseite da kein Problem in dieser Hinsicht. Java ist heute in der Ausführung längst nicht mehr das, was es in den 90ern mal war.

Zitat

---

Ich bin mir nicht sicher, was du mit "Arbeitsroutine" meinst

---

Naja triviales Beispiel, nehmen wir ein Schachprogramm, wo man den Zug eingibt. Die Berechnung des Antwortzuges sollte nicht direkt aus der Eventschleife für das Mausevent der Zugeingabe erfolgen, sondern in einem parallelen Thread oder Task gestartet werden. Bei so einigen echt zähen Programmen wird das aber eben nicht gemacht, weil die Abarbeitung zwar schon nervig lange dauert, aber andererseits nicht sooo lange, daß es wirklich ein Showstopper wäre.

Ob das nun Task oder Thread heißt, das hängt ganz vom jeweiligen OS ab. Unter Windows und Linux würde man es wahrscheinlich Thread nennen, wobei man im Beispiel des o.g. Schachprogramms die eigentliche Engine durchaus auch nicht nur in einem parallelen Thread (also desselben Prozesses wie die GUI), sondern in einem parallelen Task (also ganz andere EXE) realisieren kann - das hat sogar einiges für sich. Unter anderen OS gibt es die Unterscheidung zwischen Task und Thread überhaupt nicht, da heißt das immer "Task" - mir fallen da so einige Beispiele aus der Embedded-Welt ein, soweit nicht RT-Linux genutzt wird.

Naja, ich bezog mich dabei ja auch auf embedded-OS - da haste u.U. nichtmal ein "Programm" in dem Sinne wie eine EXE unter Windows oder ein ELF unter Linux. Da springt der Bootloader in die Mainloop des OS rein, und die Tasks werden dann in der User-Main eingerichtet und angestoßen. Einen eigenen Adreßraum haben die nicht unbedingt, weil embedded-CPUs oftmals keine MMU haben und deswegen keinen virtuellen Adreßraum für die Prozesse bereitstellen können.

Die fehlende MMU hat übrigens ganz erhebliche Konsequenzen, denn wenn der physikalische Speicher aus Kostengründen nicht gerade übermäßig bestückt wird, und andererseits logische und physikalische Adressen identisch sind, dann kannste Dir ja vorstellen, was passiert, wenn man da mit dynamischer Speicherverwaltung loslegt. Egal, ob das nun vom Framework mit dynamischen Konstruktoren/Destruktoren gemacht wird oder wie in C vom Nutzer mit malloc/free. Die Speicherfragmentierung ist nur eine Frage der Zeit. Deswegen ist das nach dem MISRA-Standard schlicht untersagt. Bleibt also nur der Stack als Falle, und deswegen ist auch Rekursion und die Benutzung dynamischer Funktionszeiger in Objekten verboten.


Übrigens, ein schönes aktuelles Beispiel für das, was ich oben sagte. Es ging ja durch die Medien, daß die neue Boeing 787 nach 248 Tagen Dauerbetrieb sich selbst abschaltet. Wenn man mal als Zeitscheibe 10ms annimmt, was für RTOS durchaus üblich ist, dann kommt man dazu, daß man mit 2^31 genau an diese 248 Tage ranreicht. Ganz offensichtlich wurde hier also irgendwas mit Software-Timern verkehrt gemacht.

Da es schon bei 2^31 passiert, wie es aussieht, dürfte es auch noch ein Problem mit signed integer sein. In C sind overflows bei signed integer aber schon vom C-Standard her undefiniert, weil nichtmal definiert ist, wie denn negative Zahlen darzustellen sind - ob als Zweierkomplement, ob als Vorzeichen und Betrag oder auch als Einerkomplement. Das kommt nämlich ganz auf den Compiler und die CPU an. Deswegen nimmt man an der Stelle keine signed, sondern unsigned, für die der Overflow sehr wohl definiert ist. Also ein ganz klassischer Fehler mit signed/unsigned-Fehler, genau was ich bereits als Beispiel nannte. Sowas wäre einem Programmierer eher nicht passiert, dem man das Programmieren mit Pascal beigebracht hätte.

Aber selbst wenn man das mit unsigned macht, kann man da immer noch danebenhauen, wenn einem nicht klar ist, was denn da detailiert passiert. Nehmen wir mal der Einfachheit halber an, wir würden die Timerwerte in 8-bit-Variablen speichern, unsigned, also von 0 bis 255. Nehmen wir weiter an, wir wollen prüfen, ob ein Intervall von t_diff=8 Einheiten vergangen ist.

Macht man es naiv, also auf die falsche Weise:
if (t_current > t_previous + t_diff)
- dann haut man schon daneben. Nehmen wir an, t_diff sei 8, t_previous sei 250, und es seien seitdem erst 2 vergangen, d.h. t_current=252, so daß die Abfrage also auf FALSE rauskommen müßte. Was aber passiert? Links steht 252, rechts steht 250+8=(mod256)2. 252>2, also TRUE. Oooops.

Die richtige Art lautet deswegen:
if (t_current-t_previous > t_diff)
Selber Fall, setzen wir mal ein: 252-250 > 8 - und das ist korrektermaßen FALSE. Was passiert nun, wenn man 7 weitere verstreichen läßt, also t_current dann 250+9=259=(mod256)3 ist? Dann sollte ja TRUE rauskommen.
3-250=(mod256)3-250+256=9 > 8 - jau. Unter einer Modulo-Arithmetik gelten eben bestimmte Äquivalenzumformungen aus dem Zahlenbereich Z nicht mehr.

Kleiner Fehler, große Wirkung - und im Übrigen ein Fehler, der gemessen an seiner Trivialität für Boeing recht teuer werden dürfte. Signed/unsigned-Fehler sind, ähnlich wie Buffer Overflows und vergessene breaks in Zustandsautomaten, immer wieder gerne präsentiert mit freundlicher Unterstützung der Programmiersprache C. Besonders lustig ist an der Stelle natürlich, daß ausgerechnet der Int-Datentyp, für den ein Over/Underflow undefiniert ist, in C der Default-Int ist, denn int ohne Zusatz ist automatisch signed. Zu den Breaks ist es natürlich idiotisch, daß man den break setzen muß, wenn man nicht in den nächsten case durchlaufen will - was man so gut wie nie will, weswegen es sinnvoller wäre, daß der nächste case automatisch ein break impliziert, sofern man nicht explizit ein continue setzt. Da merkt man eben, daß C ein portabler Makro-Assembler ist. Die Art, wie Strings in C definiert sind (nullterminiert ohne Größenangabe), führt natürlich auch immer zu unterhaltsamen Fehlern.

Zum Einsteigen ist das einfach zu gefährlich, genau wie man Fahrschüler ja auch nicht gerade auf ein 180PS-Motorrad setzt, oder in einen Sportwagen mit Heckantrieb. Wenn die ein 50PS-Motorrad fahren können bzw. einen Fronttriebler, DANN können sie sich damit als Basis an anspruchsvollere Geräte wagen.

Aber C ist eben auf Geschwindigkeit optimiert und deswegen ausgesprochen unfreundlich zum Programmierer. Undefinierte Teile des C-Standards werden bewußt genutzt, um Compilern mehr Optimierungsfreiheiten zu geben - in sichereren, aber langsameren Sprachen gäbe das einfach einen Fehler. Sowas wie bei dem Boeing-Fall kommt dann dabei raus.

Womit ich jetzt übrigens nichts gegen Boeing oder deren Zulieferer gesagt haben will, das ist nur gerade mal einer der aktuellen Fälle, die durch die Medien gehen.

Nur ganz kurz - genau weil viele ET/MB-Ings eben NICHT mit C "klarkommen" (was bei den völlig unnötigen Fallstricken von C auch kein Wunder ist), hat die Autoindustrie den MISRA-Standard geschaffen. Der läuft im Prinzip darauf hinaus, daß man erhebliche Teile dessen nicht ausnutzen darf, was C ermöglicht. Also man darf es schon, muß dann aber im Einzelfall rechtfertigen, warum genau man das nun wirklich braucht. Es bleibt ein Umfang übrig, mit dem man C auf ziemlich pascalhafte Weise programmiert und erhebliche Teile der Standardbibliotheken überhaupt nicht benutzen darf. Aus gutem Grund.

Zitat von Instant Karma

---

Man sieht aber auch, dass MISRA teils doch sehr auf den Embedded Bereich ausgelegt ist.

---

Ja, da kommt es her.

Zitat

---

Rekursionen abzuschwören z. B. macht bei knappen Ressourcen und zeitkritischen Systemen mit hohem Sicherheitsbedarf schon Sinn

---

Nicht nur da. Wenn man sich mal überlegt, wieso der Stack eigentlich dann hochläuft, dann kommt es daher, daß z.B. die Register weggesichert werden, was natürlich Zeit kostet. Das ist auch auf schnelleren Systemen nicht anders. Zudem kann man (theoretisch) jede Rekursion auch iterativ formulieren. Praktisch gesehen gibt es natürlich Fälle, wo die iterative Formulierung so umständlich wird, daß das an sich schon wieder zur Fehlerquelle wird.

Beispielsweise bei Strategiespielen der Minimax-Algorithmus, wo man rekursiv immer dieselbe Funktion aufruft und mal den Spielwert maximiert, mal minimiert, je nachdem, welche der beiden Seiten gerade "dran" ist. Die erreichte Suchtiefe wird als Parameter mitgegeben, und bei Erreichen der eingestellten Maximaltiefe ist man an den Blättern des Suchbaums angelangt. Das ist jedenfalls die vereinfachte Darstellung des Prinzips. Das könnte man auch iterativ machen, aber das würde dann schnell unübersichtlich und vor allem schwer zu testen.

Kritischer sind schon Sachen wie Pointer-Arithmetik, wo man sich recht schnell vertut, was ja auch ein Grund für die beliebten Buffer-Overflows ist. Übrigens ist das auch ein Grund, wieso 64bit-Portierungen oftmals nicht so einfach sind, wie man es sich denkt. Man kann das sauber machen, dann hat man auch kein Problem damit, aber in der Praxis ist an sehr vielen Stellen die implizite Annahme da, ein Pointer sei 32bit breit, und das wird dann fies. In Pascal wäre das kein Problem, weil das Casting von Pointern zu Integer und das Rechnen damit so gar nicht möglich sind.

Interessant und vor allem lehrreich hierzu: 20 issues of porting C++ code on the 64-bit platform

Ich hab auch schon Code geschrieben, der diese und noch einige weitere Annahmen gemacht hat, das war wirklich dreckig programmiert - aber das war auch hardwarenahe Treibersoftware, und der Durchsatz ließ sich mit einigen Tricks und Überprüfen des resultierenden Maschinencodes mal eben verdreifachen, in C wohlgemerkt. Sowas ist ja nicht nur für embedded interessant, sondern durchaus auch für die gesamte Mobil-Welt, Stichwort Akkulaufzeit. Zumal da ja auch keine Renner vom Kaliber eines i7 verbaut werden.

Zitat von Instant Karma

---

Richtig, und dann is' die Wartung auch noch schwierig.

---

Eben, und genau das zu verhindern ist ja Sinn z.B. von MISRA. Klar kann man sagen, wer C super kann, der kommt auch mit fieserem Code klar. Praktisch gesehen ist das Problem dabei nur, daß man nicht nur Top-Entwickler einstellen kann, weil die auch Top-Gehälter wollen, während nicht alle Kunden bereit sind, auch Top-Preise für Top-Produkte zu bezahlen.

Zitat

---

Kommt halt immer auf den Einzelfall an.

---

Jepp. Bei MISRA (und vergleichbaren Standards in anderen Branchen) geht es nicht darum, bestimmte Dinge strikt zu verbieten, sondern es sind nur Richtlinien. Im Einzelfall darf man die auch sehr wohl durchbrechen - muß aber dann technisch begründen, worin der Vorteil besteht, man muß die Auswirkungen analysieren und die fehlerfreie Funktion nachweisen. Das ist Arbeit, die man sich macht, wenn es wirklich keinen besseren Weg gibt - und genau das ist der Zweck, daß man das nicht leichtfertig aus Bequemlichkeit tun kann.

Zitat

---

Wir lernen zwar einige best practices der Industrie und vertrauen darauf, dass das auch so alles stimmt.

---

Das Umfeld dazu muß man natürlich auch bedenken: Gerade in KMUs sind nur ein oder zwei Entwickler wirklich mit einem konkreten Projekt vertraut. Fünf Jahre später ist davon vielleicht keiner mehr im Unternehmen und/oder ist mit anderen Projekten zugestopft. Andererseits müssen die Änderungen oder Fehlerbehebungen in der geplanten Zeit über die Bühne gehen, denn am Zeitplan hängt ja auch die Preiskalkulation. Wenn die Zeitplanung gesprengt wird, macht das Unternehmen Verlust an der Sache, und anders als Unis (deren Aufgaben aber auch ganz andere sind) kann ein Unternehmen daran auf Dauer pleitegehen. Zudem sind Zeitpläne immer knapp kalkuliert, weil Anbieter mit reichlicher Kalkulation preislich nicht mithalten können und daher die Ausschreibungen nicht gewinnen.

Zitat

---

Du hast ja mal anklingen lassen, dass du vom Bachelor allein nicht viel hältst...

---

Er ist jedenfalls nicht mit dem alten Diplom gleichwertig, das ist anhand der Studienzeit auch gar nicht möglich. Die andere Frage ist natürlich, ob man denn das zusätzliche Wissen in der Praxis überhaupt braucht, was oftmals so nicht der Fall ist.

Weiterhin ist natürlich auch entscheidend, wenn man in die Industrie will, was die denn vom Bachelor hält, und das war zumindest zu Beginn des Bachelors der eigentliche Hemmschuh. Zwar hatte die Industrie so einen Schnellabschluß selber gefordert, aber als er dann von der Politik geschaffen wurde, hat die Industrie ihre eigenen Forderungen nur zögerlich angenommen. Das kam aber auch daher, daß speziell deutsche Personaler stockkonservativ sind, denn sie können ihrem Chef eher erzählen, daß es keine geeigneten Bewerber gebe, als zugeben, daß sie auch mal bei der Auswahl danebengelegen haben. Einfach, weil sie sich unsicher waren, was sie denn nun mit einem Bachelor anfangen sollten.

Blättern wie Welt und FAZ zufolge, die man ja ohne weiteres als Sprachrohr der Wirtschaft ansehen kann, ist das Problem beim Bachelor derzeit wieder etwas anders gelagert: Und zwar bemerken die Unternehmen jetzt, daß jemand mit einem total vollgestopften Studienplan und außerdem deutlich jüngerem Abschlußalter noch nicht so recht die Lebenserfahrung hat (ach nee??). Es ist daher nicht unbedingt einfach, die Leute brauchbar in ein Team zu organisieren.

Dabei geht es erheblichenteils um "soft skills", womit allerdings nicht "mit Powerpoint rumposen" gemeint ist. Arbeitsorganisation, Zeitplanung, Kommunikation sind so die Eckpfeiler. Gerade letzteres. Merkste mir im Forum jetzt nicht unbedingt so an, aber hier werde ich dafür ja auch nicht bezahlt. (;

Zitat von Instant Karma

---

Hätte man mir die freie Wahl gelassen, hätte ich mich wohl für das Diplom entschieden. -Das aber rein aus Bequemlichkeitsgründen, weil man bis zum Vordiplom und darüber hinaus locker "Vier Gewinnt" spielen kann

---

Das kam sehr drauf an, wo man studiert hat, und zwischen TU und FH lagen da auch nochmal Welten.

Zitat

---

Ich frage mich nun aber grad, wo der Vorteil des Masters mit dem theoretischen Wissen denn ist, besonders im Vergleich zur versäumten Berufserfahrung...

---

Kommt sicher sehr drauf an, ob Du beim Einstieg in die Industrie denn eine Branche erwischst, in der genau dieses Wissen gefragt ist. Wenn ja, haste natürlich einen Vorteil.

Zitat

---

Bei uns im Master werden für mich recht interessante Module angeboten: KI, 3D-Modeling, Game Design, App Development, Mediendidaktik

---

Bei 3D-Modeling sehe ich eine Schnittstelle zu neuen Fertigungsverfahren wie 3D-Druck, der abseits des Billig-Endverbraucher-Spielzeugs durchaus industrierelevant wird, wenn er den von Gartner mal postulierten Hype-Zyklus in die Endphase der realistischen Umsetzung durchlaufen hat.

Vergiß aber alles, was mit Spielen zu tun hat. Die Bezahlung in der Branche ist unterirdisch, die Arbeitszeiten dafür jenseits von gut und böse. Viel arbeiten für wenig Geld ergibt aus meiner Sicht keinen Sinn. Zumal es nichtmal befriedigend ist, weil in der Spielebranche überhaupt kein Qualitätsbewußtsein herrscht. Weder auf Seiten der Hersteller noch auf Seiten der Kunden; letztere kaufen ja ohnehin wirklich jeden Müll.

Das ist deutlich anders überall dort, wo irgendeine Art von Zulassung notwendig ist. Medizinsysteme, Luftfahrt, mit Abstrichen auch die Autoindustrie. Oder wo Fehlfunktionen zu sehr hohem Schaden führen würde, etwa bei Steuerungsanlagen von Hochöfen oder Kraftwerken. Richtig Kohle soll man dem Vernehmen auch als SAP-Experte machen können.

Was ich Dir empfehlen würde, wäre alles, was irgendwie mit Projektmanagement zu tun hat, wenigstens mal reinriechen. Beispielsweise Entwicklungsmodelle wie Wasserfall, iterierter Wasserfall, V-Modell, bei kleinen Projekten sicherlich auch agile Entwicklung.

Anspruchsvoll ist es auch, Kundenwünsche überhaupt erstmal zu verstehen und dann in eine Spezifikation zu gießen, die vertraglich vereinbart wird. Nicht immer ist das, was der Kunde fordert, auch das, was er eigentlich will. Genau das zu erkennen und dem Kunden am Ende eine abweichende Lösung zu präsentieren, die aber sein Problem viel besser löst, ist ja eine Rechtfertigung für hiesige Preise.

Zitat

---

Gut, DAS Problem habe ich nicht.

---

Nee, dafür aber nen nicht so linearen Lebenslauf, was bei deutschen Personalern meistens schlecht ankommt. Das ist in anderen Ländern anders. Wenn jemand beispielsweise zwei Jahre ne Auszeit macht und als Rucksack-Tourist die Welt bereist, kommt das in Deutschland nicht unbedingt so gut an. In den USA wäre die Sichtweise, daß derjenige offensichtlich mit vielen verschiedenen Kulturen zurechtgekommen ist und sich daher auf sehr unterschiedliche Mentalitäten einzustellen gelernt hat, also durchaus etwas Positives. Nur, Master oder nicht Master ändert ja am Lebenslauf jetzt auch nichts mehr, spielt insofern also dafür keine Rolle.

Zitat von Instant Karma

---

Ja okay, aber so Fertigungskram interessiert mich leider gar nicht, sonst hätte ich Industriedesign oder Maschinenbau studiert.

---

Ich meinte das auch mehr so, daß die 3D-Modelle, die gedruckt werden sollen, ja auch erstmal erstellt werden müssen. Faszinierend daran ist ja, daß man auch Dinge mit Innenstruktur fertigen kann, die sind dann in etwa so aufgebaut wie Knochen auf mikroskopischer Ebene. Fest, aber dennoch leicht. Das ging bislang nur, indem man z.B. Guß geschäumt hat, aber dabei kriegt man eben keine definierte Struktur, sondern irgendeine, und das ist dann nicht so fest.

Da sind auch noch ganz andere Möglichkeiten denkbar. Man könnte beispielsweise eine Kette aus 3D-Scannern mit Textilverarbeitungsanlagen kreuzen, wodurch dann vollautomatische Maßanfertigung bzw. Anpassung von Grundmustern "on demand" denkbar wären. Wäre sicherlich ein Knaller für die Bekleidungsindustrie. Im abgespeckten Stadium könnte man auch erstmal nur ein Matching zwischen den 3D-Daten des Kunden und der bestehenden Bekleidungspalette durchführen. Jede Wette, daß der Onlinehandel daran interessiert wäre, um die Rücksendungsquote wegen schlechter Paßform zu reduzieren.

Zitat

---

Andererseits bin ich auch nicht so übertrieben geldgeil, doch die Arbeitsbelastung schreckt mich schon ab, ja.

---

Vor allem in Kombi mit der Bezahlung, wo man eben nicht sagen kann, daß man das zehn Jahre macht und dann ein reichliches Finanzpolster hat, um sich anderweitig zu orientieren.

Zitat

---

Mein derzeitiger Plan ist, mir einen Vernunftjob zu suchen und nebenbei in meiner Freizeit einfache Smartphone-Games zu entwickeln.

---

Das wäre eine tragfähige Lösung.

Zitat

---

Richtig, das sollte uns von den Indern unterscheiden. ^^

---

Oh ja. Wer schonmal Projekte gesehen hat, die nach Indien ausgelagert wurden.. besonders viel kommt dabei oftmals nicht raus. Was neben kulturellen Schwierigkeiten auch erstens daher kommt, daß die richtig guten Inder nicht in Indien, sondern in den USA arbeiten, zu US-Gehältern. Und zweitens, daß viele junge Leute dort auf Druck der Eltern aus Prestigegründen irgendwas Technisches studieren, aber eigentlich viel lieber z.B. Handwerker wären.

Zitat

---

Grund zum verzweifeln sehe ich noch nicht, aber die ganz tolle Karriere werde ich wohl anderen überlassen müssen.

---

Wenn man sich den Job anguckt, den Chefs da zu machen haben, möchte ich deren Job aber auch nicht haben. Mit Technik hat man effektiv nichts mehr zu tun. Man liest Berichte, man schlägt sich mit Budget- und Personalplanung herum, macht Mitarbeitergespräche, hängt in endlosen Meetings herum.

Zitat

---

Was würdest du denn an meiner Stelle tun?

---

Ne klare Empfehlung kann ich Dir nicht geben, weil die ja auch von den jeweiligen eigenen Prioritäten abhängt. Aber ich kann sagen, was ich abwägen würde:

- wie sehr willst Du den Master an und für sich machen?
- wie gerne magst Du die Uni?
- wie attraktiv ist es im Vergleich dazu, JETZT mit einem tragfähigen Gehalt zu leben?
- wie gut ist der Job, den Du jetzt in Aussicht hast?
- wie sehr bist Du auf Deutschland fixiert? (In anderen Ländern zählt das Papier, was man vorzeigen kann, deutlich weniger als in Deutschland. In Deutschland hingegen könntest Du beim nächsten Abschwung, wenn die Unternehmen wählerischer werden, mit dem Master einen Vorteil haben.)