Informatiker vs. Ingenieure
-
Gregor schrieb:
Programme sind wesentlich komplexer als die meisten Sachen, mit denen sich Ingenieure jenseits der Informatik auseinandersetzen.
Du hast keine Ahnung. Ich interessiere mich gleichermaßen für Informatik wie Elektrotechnik. Informatik ist (im Vgl. zu Elektrotechnik) eine "higherlevel Ebene" wo man bequem das heruntertippt was man gerne haben mag. So einfach funktioniert das bei Elektrotechnik nicht.
Selber (neue) Schaltpläne entwerfen (nicht vorhandene kopieren,..) für die trivialsten Schaltungen aus diskreten Bauteilen erfordert jahrelange Erfahrung.
Dagegen kann ein Programmieranfänger (im Vergleich zu einem Elektrotechnikanfänger) schon sehr viel auf die Beine stellen.Nun kann man das nicht so wirklich miteinander Vergleichen. Informatik bedeutet nicht Codeäffchen spielen. Genau so wenig bedeutet Elektrotechnik logic-gates und ICs zusammenlöten. Jedoch wenn du so einen Unsinn wie im Zitat schreibst, sollte dir bewusst sein, dass man in der Elektrotechnik bereits für die Analyse einfachster Wechselstrom Schaltungen (die zB nur aus 2-3 bauteilen, darunter Energiespeicher) besteht, Differentialgleichungen lösen muss und sich mit der komplexen AC-Rechnung herumschlagen muss..
Was hier manche Leute für Vorstellungen haben... da muss ich einfach den Kopf schütteln.
-
wirklichnein schrieb:
Gregor schrieb:
Programme sind wesentlich komplexer als die meisten Sachen, mit denen sich Ingenieure jenseits der Informatik auseinandersetzen.
Du hast keine Ahnung. Ich interessiere mich gleichermaßen für Informatik wie Elektrotechnik. Informatik ist (im Vgl. zu Elektrotechnik) eine "higherlevel Ebene" wo man bequem das heruntertippt was man gerne haben mag. So einfach funktioniert das bei Elektrotechnik nicht.
Selber (neue) Schaltpläne entwerfen (nicht vorhandene kopieren,..) für die trivialsten Schaltungen aus diskreten Bauteilen erfordert jahrelange Erfahrung.
Dagegen kann ein Programmieranfänger (im Vergleich zu einem Elektrotechnikanfänger) schon sehr viel auf die Beine stellen.Nun kann man das nicht so wirklich miteinander Vergleichen. Informatik bedeutet nicht Codeäffchen spielen. Genau so wenig bedeutet Elektrotechnik logic-gates und ICs zusammenlöten. Jedoch wenn du so einen Unsinn wie im Zitat schreibst, sollte dir bewusst sein, dass man in der Elektrotechnik bereits für die Analyse einfachster Wechselstrom Schaltungen (die zB nur aus 2-3 bauteilen, darunter Energiespeicher) besteht, Differentialgleichungen lösen muss und sich mit der komplexen AC-Rechnung herumschlagen muss..
Was hier manche Leute für Vorstellungen haben... da muss ich einfach den Kopf schütteln.
Was war jeweil das größte Software und Elektrotechnik Projekt das du gemacht hast?
-
Gregor schrieb:
Programme sind wesentlich komplexer als die meisten Sachen, mit denen sich Ingenieure jenseits der Informatik auseinandersetzen. Ich behaupte einfach mal, dass ein Staubsauger wesentlich einfacher aufgebaut ist, als ein kleines Programm mit einigen zehntausend Codezeilen. Wenn aber die Taetigkeit in einem wesentlich komplexeren Gebiet stattfindet, dann werden Dinge wie Erfahrung deutlich relevanter.
Wie hast du denn die Komplexität von "Sachen" und Programmen miteinander verglichen?
-
wirklichnein schrieb:
Gregor schrieb:
Programme sind wesentlich komplexer als die meisten Sachen, mit denen sich Ingenieure jenseits der Informatik auseinandersetzen.
Du hast keine Ahnung. Ich interessiere mich gleichermaßen für Informatik wie Elektrotechnik. Informatik ist (im Vgl. zu Elektrotechnik) eine "higherlevel Ebene" wo man bequem das heruntertippt was man gerne haben mag. So einfach funktioniert das bei Elektrotechnik nicht.
Selber (neue) Schaltpläne entwerfen (nicht vorhandene kopieren,..) für die trivialsten Schaltungen aus diskreten Bauteilen erfordert jahrelange Erfahrung.
Dagegen kann ein Programmieranfänger (im Vergleich zu einem Elektrotechnikanfänger) schon sehr viel auf die Beine stellen.Nun kann man das nicht so wirklich miteinander Vergleichen. Informatik bedeutet nicht Codeäffchen spielen. Genau so wenig bedeutet Elektrotechnik logic-gates und ICs zusammenlöten. Jedoch wenn du so einen Unsinn wie im Zitat schreibst, sollte dir bewusst sein, dass man in der Elektrotechnik bereits für die Analyse einfachster Wechselstrom Schaltungen (die zB nur aus 2-3 bauteilen, darunter Energiespeicher) besteht, Differentialgleichungen lösen muss und sich mit der komplexen AC-Rechnung herumschlagen muss..
Was hier manche Leute für Vorstellungen haben... da muss ich einfach den Kopf schütteln.
Hi. Ich denke, Du hast missverstanden, wie ich "komplexer" gemeint habe. Ich meinte damit eine Menge. Du musst einen Überblick über viele einzelne Elemente behalten. Ein mittelgroßes Softwareprojekt hat ganz schnell mal ein paar hunderttausend Codezeilen. Aus so vielen einzelnen Komponenten ist ein mittelgroßes E-Technik-Projekt nicht aufgebaut. Die Herausforderung bei der Softwareentwicklung kommt deswegen oft nicht durch die Entwicklung bestimmter kleiner Codestücke, sondern dadurch, dass man eine unglaublich große Menge an diesen hat. Wie Du durchaus richtig bemerkst, ist das in der Elektrotechnik anders. Dort hast Du "komplexes" Verhalten jedes einzelnen Bauteils, dafür wesentlich weniger davon. Mir ist durchaus bewusst, dass damit jede Menge Herausforderungen verbunden sind.
Also nicht, dass das falsch herüberkommt. Ich habe durchaus höchsten Respekt vor den Leistungen von Elektrotechnikern. Ich sehe auch gerade die Elektrotechnik innerhalb der Ingenieursdisziplinen als DIE Paradedisziplin an.
Abgesehen davon: Natürlich berechnen alle Elektrotechniker in ihrem Studium mal die Eigenschaften von einem Schwingkreis und meinetwegen auch von etwas komplexeren Schaltungen. Aber Du kannst mir nicht erzählen, dass die sich bei Schaltungen mit 100++ Elementen noch hinsetzen und erstmal die Differntialgleichung aufstellen. Solche Berechnungen werden dann von Computern bzw. CAD Programmen gemacht.
-
Der noch nicht verbindlich festgelegte Trollfaktor ist wahrscheinlich eine Funktion f=troll(a,b,c,...) mit vielen Möglichkeiten zur sauberen und stabilen Formulierung des Algorithmus?
daddeldu! 
-
Gregor schrieb:
Trotz allem habe ich beim Programmieren nicht das Gefühl, dass ich mein Programm aus vorgefertigten Komponenten zusammensetze.
Stimmt, da hast du Recht. Das ist auch eine interessante Überlegung, wie solche Komponenten aussehen könnten.
Die Heterogenität der Programmiersprachen und -Umgebungen ist da sicherlich auch nicht hilfreich bzw. frisst viele Ressourcen.Oder vielleicht lassen sich in der Softwareentwicklung nicht so gut generisch wiederverwendbare Bausteine herausbilden? Alleine in der Bildverarbeitung gibt es ja so unglaublich viele unterschiedliche Anwendungsfälle, dass man da wohl kaum mit einer handvoll Standardkomponenten auskommt. Andererseits sind da so Standardfälle wie Formen- und Farberkennung, Hand-/Gestenerkennung oder Gesichtserkennung.
-
Bashar schrieb:
Ich denke, man kann das nicht direkt vergleichen, weil die Ursachen für schlechte Qualität andere sind, und die Auswirkungen auch. Schlechte Codequalität hat ihre Ursachen in Unfähigkeit und Selbstüberschätzung. Man könnte zwar anführen, dass für gute Codequalität oft nicht ausreichend Zeit zur Verfügung steht, aber das ist letztlich auch Selbstüberschätzung ("wir schaffen das!") und kein bewusster Tradeoff ("wir sparen jetzt 2 Wochen, dafür bekommen wir 5 zusätzliche Bugs, 10% längere Entwicklungszeit für zukünftige Erweiterungen und können in 5 Jahren den Code wegschmeißen"). Die Auswirkungen sind auch in erster Linie schlechte Wartbarkeit und Erweiterbarkeit.
Schlechte Qualität bei "anfassbaren" Dingen hat dagegen ihre Ursachen hauptsächlich im Kostendruck, das sind bewusste Abwägungen, so dass man irgendwo z.B. ein Bauelement einspart und gegen leicht schlechtere Signalqualität eintauscht, solange alles im Rahmen bleibt.Sorry, aber das kann ich gar nicht nachvollziehen. Erstens hat schlechte Qualität auch bei Software ihre Ursache im Kostendruck und Abwägungen ("schreiben wir das selbst oder kaufen wir einfach die weltweit bewährte Bibliothek zu"). Zweitens sind Selbstüberschätzung ("die Fertigungsstraße lässt sich problemlos in 3 Monaten in Betrieb nehmen, keine Ahnung warum der Lieferant 5 Monate vorschlägt") und kein bewußter Tradeoff ("jetzt schickt das Lastenheft endlich raus, wenn sich noch was ändert können wir das ja kurzfristig nachbestellen") in diesen Bereichen ebenso gängige Muster.
Auch wenn Du Dir Gründe für Kostensteigerungen oder Scheitern bei Bauprojekten anschaust - zumindest soweit man das aus der Presse rekonstruieren kann - findest Du die gleichen "Anti Pattern", die auch Softwareprojekte zum Scheitern bringen.
"Schlecht" kennt keine Fachgebiete.
-
peanuts schrieb:
Ich behaupte auch mal, dass eine mittelgroße Software bereits komplexer ist als ein modernes Hochhaus oder der mechanische Teil eines Autos.
Man kann sowas ja auch schön an Projektplänen messen... z.B. hat ein Projektplan für einen (mittelgroßen) Fabrikbau vielleicht 4000 Einzelvorgänge im Projekt - ein Vorgang ist dann sowas wie "Firma XY montiert Türen". Die Vorgänge müssen alle in die richtige Reihenfolge gebracht werden, um einen Deadlock zu vermeiden. Auch ist gerade die Planung der eigentlichen Bauphase mit der Planung von Anlieferungen (z.B. weil gewisse Wege/Straße nicht permanent verfügbar sind) ein massiv-paralleler Vorgang, wie man ihn nur in Multithreading-Applikationen mit einigen 100 parallelen Vorgängen wiederfinden würde.
Viele Programmierer stöhnen heute wegen der komplexen Abläufe in parallelen Anwendungen, aber viele Maschinen und Automaten sind bereits seit Jahren Systeme mit Parallelverarbeitung, bei denen verschiedene Motoren Dinge gleichzeitig und doch zusammen bewegen.
peanuts schrieb:
Dazu kommt, dass wir nicht systematisch arbeiten können, weil die Softwareentwicklung ein kreativer Prozess ist.
Eine faule Ausrede. Kreativität ist keine Entschuldigung dafür, sich an Normen und Standards zu halten, um Programme zu untergliedern und damit die Komplexität zu beherrschen.
Außerdem, angenommen man muß bei einem Motor oder einer Maschine 20% Kosten einsparen, verlangt dies ebenso Kreativität, wie man hier vorwärtskommt. Denn trotz der schon öfter genannten längeren Historie anderer Ingenieurdisziplinen gibt's ja kein Handbuch für "wie mache ich den Staubsauger 20% billiger ohne daß er schlechter funktioniert" - das kann man ja auch nur über denken lösen.
Ich persönlich halte inzwischen den Hauptunterschied zwischen Softwareentwicklung und anderen Ing-Disziplinen darin begründet, daß man Software so schreiben kann, daß man sie nicht mehr visualisieren kann, d.h. man kann Software so entwerfen, daß sie sich der standardisierten Überprüfbarkeit durch andere Personen entzieht. Das ist in anderen Bereichen viel schwieriger, zwar möglich, aber dort auch durch erprobte Normen und Standards auch gar nicht mehr akzeptiert.
Ganz simpel, niemand würde akzeptieren, daß ein Schaltplan mit schrägen Linien gezeichnet würde. Das ist so in den Köpfen verankert, auf die Idee kommt niemand. Aber im Programm kann man so coden, und dann fällt das auch - solange es funktioniert - nie auf.
-
Marc++us schrieb:
Ganz simpel, niemand würde akzeptieren, daß ein Schaltplan mit schrägen Linien gezeichnet würde. Das ist so in den Köpfen verankert, auf die Idee kommt niemand. Aber im Programm kann man so coden, und dann fällt das auch - solange es funktioniert - nie auf.
Das Beispiel hinkt zu arg.
-
Marc++us schrieb:
peanuts schrieb:
Ich behaupte auch mal, dass eine mittelgroße Software bereits komplexer ist als ein modernes Hochhaus oder der mechanische Teil eines Autos.
Man kann sowas ja auch schön an Projektplänen messen... z.B. hat ein Projektplan für einen (mittelgroßen) Fabrikbau vielleicht 4000 Einzelvorgänge im Projekt - ein Vorgang ist dann sowas wie "Firma XY montiert Türen". Die Vorgänge müssen alle in die richtige Reihenfolge gebracht werden, um einen Deadlock zu vermeiden. Auch ist gerade die Planung der eigentlichen Bauphase mit der Planung von Anlieferungen (z.B. weil gewisse Wege/Straße nicht permanent verfügbar sind) ein massiv-paralleler Vorgang, wie man ihn nur in Multithreading-Applikationen mit einigen 100 parallelen Vorgängen wiederfinden würde.
Viele Programmierer stöhnen heute wegen der komplexen Abläufe in parallelen Anwendungen, aber viele Maschinen und Automaten sind bereits seit Jahren Systeme mit Parallelverarbeitung, bei denen verschiedene Motoren Dinge gleichzeitig und doch zusammen bewegen.
Wer stellt den Projektplan für einen Fabrikbau auf? Wahrscheinlich nicht ein Anfänger der gerade von der Hochschule kommt. Software mit Multithreading wird aber oft von Leute geschrieben die gerade ihr Studium abgeschlossen haben oder sogar noch studieren.
Wenn man Software so planen würde, wie einen Fabrikbau, würde man wahrscheinlich noch viel größere Projektpläne haben. Sowas wie "Firma XY montiert Türen" sieht bei SW wohl eher so aus: "Rein gehen soll man auch irgendwo können, macht da mal noch was hin" ... "Ich will da auch noch durchschauen können, damit ich seh was dahinter ist, dass soll dann immer beleuchtet werden, wenn ich davor steh" ... "Wer hat jetzt da ein Fenster eingebaut? Da kann ich ja garnicht mehr durchgehen. Macht mal eine Glastür hin" ... "Warum geht die Tür jetzt nicht mehr auf? Ach da blockiert ein Kabel die Tür. Verleg das mal so rum." ... "Warum kann ich denn jetzt nicht mehr sehen, was hinter der Tür ist. Ich glaube ihr solltet die Glasscheibe mal putzen" ... "Die Scheibe ist doch sauber, aber irgendwer hat das Kabel falsch verlegt und das Licht geht nicht mehr, das muss doch wieder so rum...
-
wirklichnein schrieb:
Gregor schrieb:
Programme sind wesentlich komplexer als die meisten Sachen, mit denen sich Ingenieure jenseits der Informatik auseinandersetzen.
Du hast keine Ahnung. Ich interessiere mich gleichermaßen für Informatik wie Elektrotechnik. Informatik ist (im Vgl. zu Elektrotechnik) eine "higherlevel Ebene" wo man bequem das heruntertippt was man gerne haben mag. So einfach funktioniert das bei Elektrotechnik nicht.
Selber (neue) Schaltpläne entwerfen (nicht vorhandene kopieren,..) für die trivialsten Schaltungen aus diskreten Bauteilen erfordert jahrelange Erfahrung.
Dagegen kann ein Programmieranfänger (im Vergleich zu einem Elektrotechnikanfänger) schon sehr viel auf die Beine stellen.Du redest Quatsch.
Auch ich interessiere mich für Elektrotechnik als auch Informatik.Und auch in der Elektrotechnik gibt es die diversen Grundschaltungen wie Tiefpassfilter, Hochpassfilter, Kippstufe, Spannungsteiler, Strombegrenzer usw. und auch da wird dann aus diesem Schaltungsbaukasten eine größere Schaltung gebaut. Und ein Anfänger, der diese Grundschaltungen kennt, der kann auch sein kleines Hobbyprojekt problemlos realisieren und seine Schaltung selber entwerfen.
In der Elektrotechnik ist es lediglich so, daß man viele Einzelgrundschaltungen gar nicht mehr zusammenfügen muß, weil es schon dafür fertige ICs gibt, die die gegebene Aufgabe schon können und sogar noch genauer und besser sind, als eine der oben genannten Grundschaltungen aus diskreten Bauteilen.Die Schwierigkeiten fangen in der Praxis erst da an, wenn dieses Sammelsurium aus Baukästchenschaltungen zu einem großen ganzen zusammengefügt werden wollen und die einzelnen Schaltungen sich gegenseitig stören oder hohe Frequenzen und Taktraten notwendig sind.
Aber solche Probleme treten auch in großen Softwareprojekten auf, wenn hier und da Änderungen notwendig sind und das kann dann auch kein Hobbyprogrammierer mehjr lösen.Und selbst solche Grundschaltungen zu entwerfen, das entspricht in der Informatik dem Entwerfen von eigenen Algorithmen.
Der Unterscheid ist nur, daß es in der Informatik viel mehr Algorithmen gibt, als in der Elektrotechnik an Grundschaltungen.
-
Marc++us schrieb:
peanuts schrieb:
Ich behaupte auch mal, dass eine mittelgroße Software bereits komplexer ist als ein modernes Hochhaus oder der mechanische Teil eines Autos.
Man kann sowas ja auch schön an Projektplänen messen... z.B. hat ein Projektplan für einen (mittelgroßen) Fabrikbau vielleicht 4000 Einzelvorgänge im Projekt - ein Vorgang ist dann sowas wie "Firma XY montiert Türen". Die Vorgänge müssen alle in die richtige Reihenfolge gebracht werden, um einen Deadlock zu vermeiden. Auch ist gerade die Planung der eigentlichen Bauphase mit der Planung von Anlieferungen (z.B. weil gewisse Wege/Straße nicht permanent verfügbar sind) ein massiv-paralleler Vorgang, wie man ihn nur in Multithreading-Applikationen mit einigen 100 parallelen Vorgängen wiederfinden würde.
Viele Programmierer stöhnen heute wegen der komplexen Abläufe in parallelen Anwendungen, aber viele Maschinen und Automaten sind bereits seit Jahren Systeme mit Parallelverarbeitung, bei denen verschiedene Motoren Dinge gleichzeitig und doch zusammen bewegen.
Das Zeichnen eines ollen Netzplans kannst Du doch nicht mit einer massiv parallelen Anwendung vergleichen. Die Parallelität wie Du sie aufführst ist in unserem täglichen Handeln verankert während Threading jenseits bekannter Standardlösungen "uns" komplett überfordert und ein noch ungelöstes Problem darstellt.
-
Der Netzplan wird ja irgendwann ausgeführt.
-
Einfach einmal nachgefragt: Ist das noch alles ernsthaft aus eigenem Wissen und Erfahrung geantwortet?
Ich fürchte hier den Trollfaktor t=f(a,b,c,...) :p
-
µ schrieb:
Marc++us schrieb:
peanuts schrieb:
Ich behaupte auch mal, dass eine mittelgroße Software bereits komplexer ist als ein modernes Hochhaus oder der mechanische Teil eines Autos.
Man kann sowas ja auch schön an Projektplänen messen... z.B. hat ein Projektplan für einen (mittelgroßen) Fabrikbau vielleicht 4000 Einzelvorgänge im Projekt - ein Vorgang ist dann sowas wie "Firma XY montiert Türen". Die Vorgänge müssen alle in die richtige Reihenfolge gebracht werden, um einen Deadlock zu vermeiden. Auch ist gerade die Planung der eigentlichen Bauphase mit der Planung von Anlieferungen (z.B. weil gewisse Wege/Straße nicht permanent verfügbar sind) ein massiv-paralleler Vorgang, wie man ihn nur in Multithreading-Applikationen mit einigen 100 parallelen Vorgängen wiederfinden würde.
Viele Programmierer stöhnen heute wegen der komplexen Abläufe in parallelen Anwendungen, aber viele Maschinen und Automaten sind bereits seit Jahren Systeme mit Parallelverarbeitung, bei denen verschiedene Motoren Dinge gleichzeitig und doch zusammen bewegen.
Das Zeichnen eines ollen Netzplans kannst Du doch nicht mit einer massiv parallelen Anwendung vergleichen. Die Parallelität wie Du sie aufführst ist in unserem täglichen Handeln verankert während Threading jenseits bekannter Standardlösungen "uns" komplett überfordert und ein noch ungelöstes Problem darstellt.
So schlimm ist Multithreading jetzt auch nicht. Viele Sachen lassen sich schon mit einem Parallel-For erledigen. Beim Rest muss man halt sorgfältig planen und sauber programmieren, das passiert aber bei der SW-Entwicklung oft nicht.
-
Ich glaube, dass das Problem ist, dass ausprobieren bei der Softwareentwicklung billig ist. Wenn ich ein Haus immer wieder neu baue, bis sie stehen bleibt, dann wird das teuer.
Bei vielen Softwareentwicklern ist es aber üblich, dass sie so lange den Code ändern, bis er funktioniert. Probieren kostet ja nichts (ausser Arbeitszeit). Das nennt sich dann auch "Frickelei".
In anderen Bereichen baut man auch mal Prototypen. Und da ist es einfacher, sich erst Gedanken zu machen und dann erst an die Werkbank zu gehen.
Leider beobachte ich das auch im professionellen Bereich zu oft.
-
tntnet schrieb:
Bei vielen Softwareentwicklern ist es aber üblich, dass sie so lange den Code ändern, bis er funktioniert. Probieren kostet ja nichts (ausser Arbeitszeit). Das nennt sich dann auch "Frickelei".
Ich bin mal frei zu ergänzen:
Systematisches und zielgerichtes Probieren = Lernen, Prototyping, ...
Planloses und zielloses Probieren = FrickeleiImmerhin gibst eine jede Menge Software nur für die computergestützt "Frickelei"
-
zeus schrieb:
Systematisches und zielgerichtes Probieren = Lernen, Prototyping, ...
XD
-
Ich bin Maschinenbauingenieur und habe nach der Uni direkt in der Konstruktion eines Mittelständischen MBau Unternehmens angefangen, also ziemlich direkt vergleicbar mit der Tätigkeit eines Programmierers in der IT. Ein MBau Absolvent ist genauso wie ein Informatikabsolvent kein guter Programmierer ist, kein guter Konstrukteur. Dieser wird er erst in seinen ersten Berufsjahren. Bei einem Konstrukteur ist es aber so, dass sein Arbeitsergebnis immer maschinell (eine Art Unit Test) und natürlich IMMER auch von seinem Vorgesetzten bis ins Detail überprüft wird. Eine Zeichnnung wird niemals in Produktion gehen, bevor ein Verantwortlicher da gründlich mit dem Rotstift dran war. Und ich kann mich noch erinnern, wie die Zeichnungen am Anfang immer und immer wieder mit reichlich Rotstift zurück kamen. Ich denke es ist in den meisten Berufen ganz normal, dass Absolventen nicht die Ausbildung haben, um auf Anhieb gute Arbeit zu leisten (Meine Frau ist Lehrerin, die haben im Studium eigentlich überhaupt nichts Praxisrelevantes gelernt. Wie man unterrichtet lernt man ni der Schule
).Bashar schrieb:
Ach ja, in bin Ingenieur, schreibe aber Software. Das sind die schlimmsten
Ja die sind wirklich schlimm
Ich arbeite inzwischen in der Simulation wo ich hauptsächlich für die Softwareentwicklung verantwortlich bin. Was da von den Kollegen jahrzehntelang zusammengefrickelt wurde, heieiei...
-
Gregor schrieb:
BTW: Die Chipindustrie ist definitiv nicht älter als die Informatik. Teilweise kann man Chipdesign sogar als Informatik sehen. Im Informatikstudium "designt" man zumindest auch schonmal einen kleinen Prozessor inklusive dem Befehlssatz. Wir haben das damals noch mit einem CAD Programm gemacht. Und dann haben wir darauf ein Programm für die Türme von Hanoi realisiert und simuliert. Mit Hardwarebeschreibungssprachen wie VHDL sind wir im Rahmen von Eingebetteten Systemen auch in Kontakt gekommen.
[OffTopic]An welcher Hochschule/Uni hast du Informatik studiert @Gregor? Klingt sehr interessant![/OffTopic]
@xepre
Was erwartest du von einem "frischen" Informatiker? Nicht jeder Informatiker ist automatisch ein guter Programmierer. Im Studium lernt man halt
nur die Basics. Dann gibt es da noch das Praxissemester und paar Softwareprojekte ( aus letzterem lernt man nicht so viel wie im Praxissemester *imo* - was ich mitnehmen konnte war das man mit Frickelei nicht immer weiterkommt ). Aber ein Semester Berufspraxis ist natürlich nicht viel aber dennoch eine wichtige Erfahrung. Was ich sagen will :Erwarte anfangs nicht zu viel ( weil Informatik != Programmierer ), viel schlimmer finde ich sind die, die aus ihren "Fehlern" nicht lernen oder sich nicht verbessern möchten.