Die meisten, die sich im Projektgeschäft bewegen oder sich öfters mal bewerben, werden es ja schon gemerkt haben: Bewirbst Du Dich auf eine HW-Stelle kannst Du mit 5-10% weniger Gehalt rechnen, als bei einer Softwarestelle, Warum das so ist, das soll dahin gestellt sein. Ein sehr erfahrener Abteilungsleiter hat mir mal gesagt: "Ingenieure entwickeln besser Software" ... ... als Informatiker, weil sie die Spielereien weglassen und sich auf das wichtige konzentrieren. Auch verstünden sie die Aufgabe meistens besser und arbeiten schnörkelloser. Es wird aber noch andere Gründe geben. Egal. Meinen einleitenden Satz will ich nämlich eigentlich so verstanden wissen; "Ingenieure entwickeln besser Software" ... ... anstatt sich mit Hardware abzuquälen, will heissen: Man orientiert sich besser rechtzeitig richtig im Markt! Ein Beispiel: ============ Ein Job aus meinem Fachgebiet, in dem ich noch vor Jahresfrist fest angestellt war, der 10 Jahre Knowhow braucht, soll mir jährlich max 70k einbringen, was fast weniger ist, als ich zuvor hatte und dies, obwohl mein Thema (Leistungselektronik) im Moment sehr gefragt ist! Ein anderer Job, wo es nur um C-Programmierung geht, die in einem PicoBlaze laufen soll (Knowhow, dass mich zu beschaffen keine 2 Jahre nebenher gekostet hat), wird mal sofort mi 75k+ und verhandelbar angegeben, Das ist leider kein Einzelall, würde Ede sagen, sondern die Regel! 1) Je mehr C, desto mehr Geld. Je mehr Kupfer, desto weniger. 2) Einfaches VHDL bringt mehr, als HF-Analogtechnik (auch so ein Thema von mir) 3 ein bissl Excel und Matlab ist ebenfalls höher eingestuft, als Bauteilkenntnisse, Schaltungstechnik etc. Ich kann aus alledem nur schlussfolgern: a) Hardwareentwickler sind nicht gefragt - von wegen Mangel b) die, die arbeiten, haben weniger -> Macht euch auf in die Software, liebe Kollegen Wenn es noch eines letzten Beweises bedurft hätte, dann kann man sich ja mal die Stundensätze im Projektmarkt ansehen, die gezahlt werden: http://www.gulp.de/kb/st/stdsaetze/sstext.html (2. Grafik) Engineering : ca. 62,- Softwareentw : ca. 68,- Macht satte 10.000 mehr Umsatz = Brutto im Jahr, womit es sich so einigermaßen lohnt. Meine eigenen aktuellen Werte laufen auf >72 für die Software und maximal 63,- für Hardware. Niedrige Sätze sind momentan 65,- (SW) und 55,- (HW). 55,- sind umgerechnet nicht einmal 60k. Bei dem grossen Mehraufwand ist das für einen Erfahrenen Mann lachhaft. Aber dann wundern, wenn es keiner macht.
es geht noch besser, man nimmt einen, der erst Hardware erstellt und dann die Software programmiert, und dieser wird dann mit <62€ abgespeist.
oder er springt nach Abgabe des SCH ab und hüpft zu einem anderen Kunden, wie man es mir schon erzählt hat. Das SCh sollte ich dann noch mal bearbeiten :-) Neeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee Daaaaaaaaaaaaaaaaaankeeeeeeeeeee
das ist eben oft das Problem, weil vile Firmen das nicht miteinkalkulieren, weil Geiz bekanntlich geil ist
Ich halte das für Unfug. Was gute Software ist, wissen viele Entscheider oft gar nicht zu beurteilen. Sobald die Problematik komplizierter wird und z. B. stabile Algorithmen gefragt sind, muss der Nichtinformatiker passen. Es geht nicht darum, einen bekannten Algorithmus selbst zu implementieren, Gott bewahre. Wenn man aber nicht weiß, dass es diesen oder jenen Algorithmus gibt, dann kann auch nicht gezielt danach bei Google suchen und eine Bibliothek raussuchen, die diesen Algorithmus bereits implementiert hat. Ich kannte mal einen Chef, der die einfachsten Algorithmen seiner Mitarbeiter nicht verstanden hat und unmögliches verlangt hatte: Noch mehr Funktionalität in kürzer Zeit, bei Algorithmen, die auch er versteht. Sein Problem war: Er war zur Jahrtausendwende Quereinsteiger und hielt sich für einen guten Programmierer und war geistig nicht in der Lage, zu akzeptieren, dass seine Ausbildung einfach nicht ausreichte.
Aktionär schrieb: > Sobald die Problematik komplizierter wird > und z. B. stabile Algorithmen gefragt sind, muss der Nichtinformatiker wie oft braucht man das im Berufsalltag ? also ich kann diese Situationen an einer Hand abzählen pro Jahr. Zu 90 + x % braucht man solche Dinge nicht. Bei Informatikern habe ich teils oft gesehen, dass die völlig unpragmatisch an Lösungen ran gehen. Da wird für einfache Probleme ein komplexes UML Model erstellt und raus kommt eine Architektur wo jeder SW - Prof begeistert wäre, aber das ganze wird auch entsprechend teuer. Falls mal später ein anderer Entwickler ran geht, muss der sich erst in das komplexe Model einarbeiten. Dann ist manchmal der pragmatische Ing mir lieber, der zwar auch Schichtentrennung bei der SW Entwicklung berücksichtigt, aber dennoch problemorientierter an die Sache ran geht. Von wegen : "was muss die Software können" und nicht "wie muss eine Architektur aussehen, damit sie SW technisch perfekt ist" soll natürlich nicht verallgemeinert sein, es gibt auch sicher viele Informatiker, die sehr pragmatisch denken. Ist lediglich eine Beobachtung von mir
Das ist wie mit dem Super 1 Mio Dollar Weltraum Kugelschreiber der NASA und dem 1 Rubel Bleistift der Russen: Der Informatiker löst Softwareprobleme wie beim Weltraum Kuli, der Ing wählt die "russische Methode". ;-)
Ich hab ja in meine Leben beide Stufen durch gemacht. Ich hab in meiner Schul- und Lehrzeit als Programmierer gearbeitet, bin inzwischen Elektroingenieur, programmiere aber auch von Zeit zu Zeit in der Arbeit. Ich vermute der große Unterschied bei mir ist, dass ich dazwischen unixoide Betriebssysteme kennen gelernt habe, und somit verstanden habe, wie man Probleme einfach und elegant löst. Vielleicht ist auch der Unterschied, dass man als Ingenieur Werkzeuge anders sieht. Damals als Programmierer waren die Werkzeuge selbst die Herausforderung. Heute benutze ich Werkzeuge einfach als Werkzeuge und suche mir die Werkzeuge aus, die zweckmäßig sind. Deshalb habe ich beispielsweise schon lange keinen SQL-Server mehr benutzt. Textdateien sind für mich in den meisten Fällen ausreichend.
Coder schrieb: > wie oft braucht man das im Berufsalltag ? also ich kann diese > Situationen an einer Hand abzählen pro Jahr. Zu 90 + x % braucht man > solche Dinge nicht. Kommt drauf an, was dein "Berufsalltag" ist. Klar, der grösste Teil der Programmierer werkelt irgendwo an kleineren Projekten, wo es hauptsächlich darum geht, bestehende Komponenten zu kombinieren. Beispielsweise ein Funkmodul, ein Embedded-Betriebssystem, ein Display und ein paar Libraries. ABER irgendwer muss diesen Kram auch entwickeln. Wer Betriebssysteme, Programmiersprachen, Compiler oder grosse Libraries spezifizieren soll, der kommt um eine solide Informatik-Bildung nicht herum. Die ganzen Informatikkonzepte sind dort eben Alltag, und nicht "unsere" Bits und Bytes.
P. M. schrieb: > ABER irgendwer muss diesen Kram auch entwickeln. Wer Betriebssysteme, > Programmiersprachen, Compiler oder grosse Libraries spezifizieren soll, > der kommt um eine solide Informatik-Bildung nicht herum. Die ganzen > Informatikkonzepte sind dort eben Alltag, und nicht "unsere" Bits und > Bytes. Hmm, die Frage ist, ob man das im Informatikstudium überhaupt noch richtig lernt. Ich hatte noch das Glück privat unter DOS auf dem IBM-PC zu entwickeln, da bekommt man hautnah die Grundlagen mit. In der Lehre habe ich dann gelernt wie furchtbar externe Biliotheksroutinen sind. Inzwischen benutze ich nur noch die Standardbibliotheken die bei der Umgebung dabei sind.
Geraffel schrieb: > Das ist wie mit dem Super 1 Mio Dollar Weltraum Kugelschreiber der NASA > und dem 1 Rubel Bleistift der Russen: > Der Informatiker löst Softwareprobleme wie beim Weltraum Kuli, der Ing > wählt die "russische Methode". > > ;-) Das ist ein modernes Märchen und außerdem: Ein Bleistift bei Schwerelosigkeit im Raumschiff lebensgefährlich. Da muss nur die Mine abbrechen und irgendwo durch eine Ritze zur Technik gelangen.
Christian Berger schrieb: > Hmm, die Frage ist, ob man das im Informatikstudium überhaupt noch > richtig lernt. Ich hatte noch das Glück privat unter DOS auf dem IBM-PC > zu entwickeln, da bekommt man hautnah die Grundlagen mit. In der Lehre > habe ich dann gelernt wie furchtbar externe Biliotheksroutinen sind. An der Uni habe ich auch Assembler gelernt. DOS kenne ich noch aus meiner Kindheit/Jugend. Man muss nicht zwangsläufig unter DOS entwickelt haben, um "nahe am Grundsystem" zu sein. Ich kann mir nicht vorstellen, dass es Informatikstudiengänge ohne Assembler gibt. Mir ist schon als Jugendlicher aufgefallen: Programmieren lernt man am besten am Quelltext, mit Papier und Bleistift. Alle Ansätze, schnell mal was zusammenzuklicken, scheitern, wenn man gerade noch im Begriffe ist, eine Sprache zu lernen. Ich habe mich mal an Delphi gewagt und bin grandios gescheitert. Dann habe ich mir Borland Pascal besorgt und ganz einfache Programme geschrieben. Danach habe ich mich an C/C++ gewagt. Bei Bibliotheken: Man muss wissen, wonach man sucht. Als Informatiker kommt man auch in Kontakt mit Graphalgorithmen und linearer Programmierung. Wenn man nicht weiß, dass diese oder jene Aufgabenstellung ein bekanntes graphentheoretisches Problem darstellt, dann bildet man die Aufgabenstellung auf eine bestehende, allgemeine Implementierung ab. Oder aber LP: Wenn man nicht weiß, dass ein Problem der linearen Optimierung vorliegt, wird auch nicht zu einer bestehenden Implementierung des Simplexalgorithmus greifen. Ein gutes Beispiel ist auch die Sortierung von Objekten. Mittlerweile hat jede Programmiersprache eine Implementierung von Quicksort dabei. Dem Algorithmus übergibt man ein Strategieobjekt, das -1, 0 oder 1 zurückgibt, wenn zwei Objekte miteinander verglichen werden. Die konkrete Ausformung einer Strategieklasse ist ziemlich einfach, aber das eigentliche Quicksort ist nur einmal implementiert.
Gerald Hellinghaus schrieb: > Die meisten, die sich im Projektgeschäft bewegen oder sich öfters mal > bewerben, werden es ja schon gemerkt haben: Bewirbst Du Dich auf eine > HW-Stelle kannst Du mit 5-10% weniger Gehalt rechnen, als bei einer > Softwarestelle, Warum das so ist, das soll dahin gestellt sein. [snip] Ist das heutzutage wirklich so herum? Eine sehr schöne Anekdote dazu: In einer Firma (angeblich USA) verdienten die HW-Entwickler deutlich mehr als die SW-Entwickler. Einer der Software-Typen ging dann mal zum Boss und fragte wieso das so sei? Die Antwort: Software ist doch nur Tippen! Ich weiss nicht ob ich darüber lachen kann, ist manchmal zu nahe an der Realität.
Coder schrieb: > Aktionär schrieb: >> Sobald die Problematik komplizierter wird >> und z. B. stabile Algorithmen gefragt sind, > > wie oft braucht man das im Berufsalltag ? also ich kann diese > Situationen an einer Hand abzählen pro Jahr. Zu 90 + x % braucht man > solche Dinge nicht. Der war gut ;) Coder schrieb: > Von wegen : "was muss die > Software können" und nicht "wie muss eine Architektur aussehen, damit > sie SW technisch perfekt ist" Ersetze das Wort 'perfekt' durch 'einwandfrei' und du hast zwei Sätze zitiert, die für mich exakt dasselbe bedeuten.
Geraffel schrieb: > Das ist wie mit dem Super 1 Mio Dollar Weltraum Kugelschreiber der NASA > und dem 1 Rubel Bleistift der Russen: > Der Informatiker löst Softwareprobleme wie beim Weltraum Kuli, der Ing > wählt die "russische Methode". > > ;-) Das der Kuli aber entwickelt wurde, weil das Graphit einer abgebrochenen Bleistiftmine zu Kurzschlüssen führen kann (im Weltraum ein Desaster) und die Bleistiftspitze eingeathmet werden kann, wird mal munter verschwiegen :-)
edson schrieb: > Ersetze das Wort 'perfekt' durch 'einwandfrei' und du hast zwei Sätze > zitiert, die für mich exakt dasselbe bedeuten. verstehe schon was du meinst. Es gibt aber einfach Dinge, da braucht man nicht eine SW technisch einwandfreie Architektur. Beispiel : Kunde möchte ein billig Pressholzfertighaus, das keine 100 Jahre halten soll, so im Ami Style. Viele Informatiker aber kränkt sowas in ihrer Ehre und sie stellen ein Haus hin, was jeder EU Norm, jeder DIN Norm usw entspricht und mindestens 5 Generationen ohne Probleme hält. Nur wenn der Kunde das gar nicht wollte und schon gar nicht bezahlen will ? dann ist es manchmal besser, man lässt die 5 mal gerade sein und gibt dem Kunden was er will. Bei nem Wirbelsturm wird wieder die Kellerdecke saubergefegt und wieder ein Fertighaus drauf gestellt, was oft billiger kommt, als eine Ruine von Fachleuten aufwendig nach dem Sturm restaurieren zu lassen.
Warum wird immer gleich mit Superlativen um sich geschmissen? Nur weil einer mal etwas mehr nachdenkt, heißt das nicht, dass er das "perfekte" System haben will. Das wird mir gerne vorgeworfen. Ich mache mir Skizzen auf Papier und denke scharf nach. Einfach drauflos programmieren, gibt's bei mir nicht. Als Informatiker ist mir die Komplexitätstheorie sehr wohl vertraut und auch Verfahren, um dem Dilemma der NP-schweren Probleme zu entkommen, kenne ich auch. Dann muss mir aber kein neunmalkluger Ingenieur erzählen, dass es sinnlos sei, nach der perfekten Lösung zu suchen, und das, obwohl ich das Wort "perfekt" bis dahin nie in den Mund genommen habe. Als Informatiker ist mir nämlich auch bewusst, dass man es sich nicht zu einfach machen kann und die erstbeste Lösung zu nehmen, die einem einfällt. So arbeiten viele meiner (ehemalige) Kollegen. Lieber schnell hingepfuscht, anstatt anständig nachgedacht und ein Stück Code geschaffen, das die nächsten Monate übersteht. Leider ist es so, dass viel Code geringe Lebensdauer hat, weil man einem Problem nach dem andere hinterherjagt. Das ist das Arbeitsweise von Leuten, die ständig reden, Lösungen müssen schnell und einfach sein. Das kosten Zeit, Nerven, Geld.
Coder schrieb: > Beispiel : Kunde möchte ein billig Pressholzfertighaus, das keine 100 > Jahre halten soll, so im Ami Style. Viele Informatiker aber kränkt sowas > in ihrer Ehre und sie stellen ein Haus hin, was jeder EU Norm, jeder DIN > Norm usw entspricht und mindestens 5 Generationen ohne Probleme hält. Ganz bestimmt nicht. Meine Erfahrung ist eine ganz andere. Der Kunde verlangt die verrücktesten Systeme und es alles unnötig kompliziert gemacht. Ich betreue einen Kunden, der z. B. ein Programm einer anderen Firma mit unserer Software verbinden will. Und in der Spezifikation steht dann: Die von der Software gesandten Daten werden in Tabelle X abgespeichert. Nach 30 Tagen wandern die ins "Archiv" in Tabelle Y, um dort wiederrum nach 60 gelöscht zu werden. Der Kunde will Statistik haben und dazu müssen Daten beide Tabellen konsultiert werden. Die einfache Lösung wäre gewesen: Man hat nur noch Tabelle X und Datensätze werden erst nach 90 Tagen gelöscht. Andere Kunden halten einen Spezifikation teilweise vor. Die sagen, es gilt Regel A. Nach einer Woche heißt es: Es gilt Regel A, mit Ausnahme B. Wieder eine Woche später gibt's mit C den Sonderfall von B. Ist natürlich Frevel zu verlangen, dass man gleich zu Beginn mit einer perfekten Spezifikation arbeitet. Spezifieren ist genauso anspruchsvoll wie das Programmieren. Aber jede Woche eine neue Salve von Sonderregeln, ist einfach unmöglich, weil ja bereits Code besteht, der eventuell verworfen werden muss.
Aktionär schrieb: > Andere Kunden halten einen Spezifikation teilweise vor. Die sagen, es > gilt Regel A. Nach einer Woche heißt es: Es gilt Regel A, mit Ausnahme > B. Wieder eine Woche später gibt's mit C den Sonderfall von B. Ist > natürlich Frevel zu verlangen, dass man gleich zu Beginn mit einer > perfekten Spezifikation arbeitet. Spezifieren ist genauso anspruchsvoll > wie das Programmieren. Aber jede Woche eine neue Salve von Sonderregeln, > ist einfach unmöglich, weil ja bereits Code besteht, der eventuell > verworfen werden muss. Mit sich ändernden Anforderungen kriegt man jedes, aber auch wirklich jedes Software-Projekt grausam ermordet. Man muss die Kunden endlich mal dazu erziehen, dass sie das gefälligst sein lassen sollen. Oder sie müssen eben unterschreiben, dass es dann länger dauert und teurer wird, wenn sie während der Projektlaufzeit ständig die Spezifikation ändern.
Gerald Hellinghaus schrieb: > -> Macht euch auf in die Software, liebe Kollegen Das hört sich so an, als klappert man etwas mit der Tastatur. Ich arbeite in einem Unternehmen, das länger (einige Monate) nach einem Programmierer gesucht hat, der sich auch mit den Hardwarehintergründen der Leistungselektronik etc. auskennt. Inzwischen haben die wohl einen gefunden.
Aktionär schrieb: > Aber jede Woche eine neue Salve von Sonderregeln, > ist einfach unmöglich Dann hat man die falsche Geschäftsgrundlage. Entweder werden Preise (und Termine etc.) aufgrund einer eigenen (!) Aufwandsabschätzung anhand von Lasten- und Pflichtenheft gemacht. Vertrag kommt zustande, wenn beide sich auf diese Unterlagen einigen. Genau das ist dann die Arbeitsgrundlage. Änderungen ziehen neue Aufwandsabschätzungen nach sich, meist mit Mehrkosten. Wenn das wiederum von beiden Seiten akzeptiert wird, geht es damit weiter, und die Wünsche reduzieren sich üblicherweise schnell, wegen der Kosten und des Zeitaufwands. Werden die Mehrkosten nicht akzeptiert, gibt es die Änderungen nicht. Beim Bäcker kannst du auch nicht erst ein Brötchen für ein paar Cent bestellen, und hinterher zum selben Preis noch ein Kilo Schnitzel und ein Pfund Honig drauf haben wollen, Butter gehört ja auch noch dazu. Oder man lässt sich nach Zeit bezahlen, und der Kunde kann die bezahlte Zeit verplempern, wie er will. Beides geht und erzieht den Kunden auch. Wer aber erst ohne klare Regeln einen zu niedrigen Festpreis zusagt, ist selbst schuld. "Aber das ist doch klar, daß das mit enthalten sein muß!" Die Kunden, die zu solchen Nachforderungen neigen, wollen sich aus gutem Grund nicht auf klare Bestimmungen festnageln lassen. Aber dann ist von vornherein offensichtlich, daß man ewig tanzen muß, um mal an sein Geld zu kommen. Jeder, wie er will.
Geraffel schrieb: > Das ist wie mit dem Super 1 Mio Dollar Weltraum Kugelschreiber der NASA > und dem 1 Rubel Bleistift der Russen Urban legend.
Alex W. schrieb: > Das der Kuli aber entwickelt wurde, weil das Graphit einer abgebrochenen > Bleistiftmine zu Kurzschlüssen führen kann (im Weltraum ein Desaster) > und die Bleistiftspitze eingeathmet werden kann, wird mal munter > verschwiegen Warum sollte man auch Blödsinn äußern?
Aktionär schrieb: > Ich kann mir nicht vorstellen, > dass es Informatikstudiengänge ohne Assembler gibt. Ich mir schon. Schau Dich mal in der Welt um. Es gibt so unglaublich viel Software bei denen grundlegendste Regeln verletzt wurden. Beispielsweise werden da Arraygrenzen nicht überprüft. Das sind Dinge, die jedem Assemblerprogrammierer klar sind, und deshalb eigentlich auch jedem C(++) Programmierer klar sein müssten. Trotzdem machen es die meisten falsch. Und das ist in C(++) fatal. Das ist auch einer der Gründe, warum meine Meinung von Informatikern so niedrig ist. Die meisten die ich bislang getroffen habe verstehen ihr Handwerk noch weniger als ich. Und ich bin jetzt wirklich kein Experte.
Ich bin schon oft in Kritik geraten. Von der Ausbildung bin ich ET-Ingenieur, brachte mir das Programmieren anhand von Informatiker-Bücher bei (z.B. B. Stroustrup). Aber ich habe nur in Ing.-Teams gearbeitet, da waren andere Dinge wichtig: z.B. Bytes sparen, damit eine kleinerer/billiger Eprom verwendet werden konnte. Somit habe ich mich angepasst, und werde oft kritisiert. Meist sind es ziemlich primitive Argumente, z.B. Verwendung von #define statt const. Einmal hat jemand meinen Chef angeschrieben und sich über meinen Code beschwert. Interessanter waren das meist syntaktische Sachen, die aber vom Misra-Standard verlangt waren. Misra kannte dieser "Kollege" nicht. Mein Chef schrieb zurück: Jeder Programmierer findet den Code der andereren unleserlich, aber Misra muss eingehalten werden.
Jürgen G. schrieb: > Meist sind es ziemlich primitive Argumente, z.B. Verwendung von #define > statt const. Behandeln, besser optimieren, die meisten Compiler die beiden Varianten nicht gleich? Außer dass dir beim const der Compiler auf die Finger schaut und zur Not auch haut?
>Behandeln, besser optimieren, die meisten Compiler die beiden Varianten >nicht gleich? Denke ich nicht. Ich vermute, dass beim const eine RAM-Variable angelegt wird. Da der Compiler jede C-Datei separat compiliert, weiß er nicht, ob von der const-Variable die Adresse mit & gebildet wird in einer anderen Datei. Bei ganz knapp bemessenen uC-Code kann das eine Rolle spielen. Bei einem #define wird einfach der Inhalt ersetzt und die Konstante direkt im Maschinencode eingefügt. >Außer dass dir beim const der Compiler auf die Finger schaut und zur Not >auch haut? Wüsste nicht, was du dabei meinst. Bei einem #define wird vom Precompiler der ursprüngliche Inhalt eingefügt.
1 | #define INTVAR 5.3
|
2 | const float intvar= 5.3; |
3 | |
4 | int i = INTVAR; |
5 | int j = intvar; |
Da dürfte mir bei beiden Initialisierungen der Compiler "auf die Finger hauen". Echte Informatiker ziehen vermutlich die const-Version vor.
>Da dürfte mir bei beiden Initialisierungen der Compiler "auf die Finger >hauen". Selbst mit -Wall meckert der gcc nicht. Wieso sollte er? Beim ersten wird 5.6 als int angesehen und das Komma mit allem danach sowieso abgeschnitten und beim zweiten castet der compiler den float nach int, von sich aus. Höchstens noch, dass er meckert, weil dadurch Daten verloren gehen. Aber wer in einen int einen float schiebt, wird schon wissen was er tut...
Wenn es sich bei dem const um einen Integertyp handelt, wird bei C++ kein Platz im RAM angelegt. Das ist bei C++ explizit so festgelegt. (Demzufolge wird aus dem Modul auch keine Variable mit dementsprechenden Namen exportiert.) Die Idee dahinter ist, die Präprozessoranarchie von C einzudämmen, und eben, z. B. ein const int A = 3; ein Ersatz für das #define A 3 sein zu lassen, ohne Speicher zu verschwenden.
Herrje, hier ist ja mal wieder die geballte Fachkompetenz unterwegs, ... Wie oft manch Inschenör hier schon bei maximal mittelschweren algorithmischen Fragestellungen ausgestiegen ist durfte man ja schon bewundern. Der Begriff "Dynamische Programmierung" ist nur selten bekannt und die einfache pragmatische Lösung des Ings entpuppt sich als die naive Brute-Force Lösung... Von Themen wie Komplexitäten und Graphen mal ganz abgesehen, ...
Vielleicht sollte es heißen "Ingenieure entwickeln irgendwie Software" ;-) Wobei teilweise nicht mal so sehr der Code das Problem ist, aber öfter mal die Änderungsdokumentation... es soll Leute geben, die schon mit 1-2 Zeilen vernünftigem Kommentar beim Einchecken überfordert sind.
der Dipl-Inf.-Hasser schrieb: > Wenn es sich bei dem const um einen Integertyp handelt, wird bei C++ > kein Platz im RAM angelegt. Das ist bei C++ explizit so festgelegt. > (Demzufolge wird aus dem Modul auch keine Variable mit dementsprechenden > Namen exportiert.) > > Die Idee dahinter ist, die Präprozessoranarchie von C einzudämmen, und > eben, z. B. ein > const int A = 3; > ein Ersatz für das > #define A 3 > sein zu lassen, ohne Speicher zu verschwenden. Was haben Sie für einen Computer? Ein Computer, bei dem der Binärcode nicht in den Hauptspeicher geladen wird? Das Verwenden von Konstanten hat außerdem ganz andere gewichtige Vorteile. Einerseits kann der Compiler besser optimieren, andererseits verringern sich typische Programmierfehler. In funktionialen Programmiersprachen kann man noch viel bessere Sachen machen. Wenn eine Funktion f(x1,x2,...xn) die Eigenschaft hat, zu jedem Zeitpunkt immer das gleiche Ergebnis (bei gleicher Eingabe zurückzugeben), dann kann man die Funktion schon zur Übersetzungszeit ausgeben, wenn die Funktion nur Konstanten als Eingabe hat. So würde "fakultaet(5)*x" schon zur Übersetzungszeit zu "120*x" evaluiert werden und man spart sich fünf Multiplikationen pro Durchlauf.
> Vielleicht sollte es heißen "Ingenieure entwickeln irgendwie Software" > ;-) "Besser" ist etwas unpassend in diesem Kontext, da es viele Kritierien zur "guten" Softwareentwicklung gibt - schneller Code (da sind #defines oft besser) - kurz, kompakt - leicht portierbar - OS - unanhaengig - leicht lesbar, gut kommentiert - nicht leicht lesbar und kopierbar, wenn der Code geschuetzt werden soll - leicht erweiterbar und pflegbar ...
Wer glaubt eigentlich allen Ernstes, alle Ings würden gleich gut oder gleich schlecht SW entwickeln? Entsprechend Informatiker, Physiker oder andere? Noch platter geht es ja kaum. Nicht einmal alle BWLer sind gleich.
BWLer machen schon lange SW. Mit Beschränkung auf Powerpoint und Excel.
Zuckerle schrieb im Beitrag #2335435: > Die beste Software machen die Physiker Ich hatte letztens mit FPGA Code zu tun, den ein self made Programmierer mit C-Erfahrung erschaffenhatte. Alles war als SW-Konzept gelöst und überall blickte multi-tasking-Denken durch, wo RT gefragt gewesen wäre. Der Herr hatte ursprünglich Physik studiert, dann 3 Jahre an der Uni gearbeitet und schließlich 6 Jahre Software gemacht, um dann beim VHDL zu landen. Überflüssig zu erähnen, dass der Herr bei einem kleinen Dienstleister arbeitet, der damit protzt, super duper Ingenieure in seinem Team zu haben. Gibt es eigentlich nicht mal so eine unabhängige Prüfstelle fürs VHDL-Entwicklen?
unbekannter Freiberufler schrieb: > Gibt es eigentlich nicht mal so eine unabhängige Prüfstelle fürs > VHDL-Entwicklen? Nein, was hilft sind (unabhängig von der Programmiersprache): -Richtlinien zum Codieren, die verbindlich eingehalten werden müssen -Peer Code Reviews -Einsatz von automatischen Test-Tools (weiß ehrlich gesagt nicht wie es bei VHDL aussieht; für z.B. C, C++, Java gibt es da jede Menge) Nur wird das in vielen Firmen (auch zum Teil in großen Konzernen) eher lasch gehandhabt, und so landet jede Menge nicht wirklich guter Code im fertigen Produkt.
>C, C++, Java gibt es da jede Menge
Würde mich mal interessieren, was genau da nach was geprüft wird. Leider
finde ich nur eine Hand voll Tools zum Download wenn ich nach "C Test
Tools" suche. Kannst du mir ein Stichwort oder einen Wikiartikel oder so
nenen, in dem sowas beschrieben wird?
Ich hab mir jetz nicht alle Beiträge durch gelesen. Gerald Hellinghaus schrieb: > "Ingenieure entwickeln besser Software" ... > ... als Informatiker, weil sie die Spielereien weglassen und sich auf > das wichtige konzentrieren. Auch verstünden sie die Aufgabe meistens > besser und arbeiten schnörkelloser. Es wird aber noch andere Gründe > geben. Kann ich fast so bestätigen. Kann aber sagen das dein Abteilungsleiter wahrscheinlich 55 - 60 Jahre alt ist und aus einer Zeit stammt als Software-Engineering noch in den Kinderschuhen steckte. Ich bin Praktikant in einer fabless Semiconductor Company und merke das für mich als Informatikstudent der Spagat zwischen "dienlich der Aufgabe und schnell verfügbar" und "dienlich der Aufgabe und durchdacht" ziemlich schwer am Anfang war. Mittlerweile hab ich mehrere Praktika in dieser Firma absolviert und kann sagen das ich so langsam ein Gefühl dafür entwickle für welche Aufgabenstellung welche Herangehensweise von Nöten ist. Ich würde deswegen sagen obige Aussage ist eine Teilwahrheit. Bei kleinen Skripten in Perl o. Python ... stimmt die Aussage, aber bei größeren Projekten (z.B. Test-Umgebung für Hardware) kann ich aus meiner Erfahrung sagen das es funktioniert aber die Wartbarkeit/Erweiterbarkeit nicht berauschend ist. Es kommen dann meist Monolithen die -hoffentlich- nie wieder angerührt werden, und das ist meist nicht der Fall. Zu der Thematik mit den UML-Diagrammen: - Wenn man im Team arbeitet unverzichtbar. - Wenn man Projekte hat die sich über die Zeit ändern -> unverzichtbar Ich persönlich verwende sie auch gerne um den ET-/Phy-kollegen in einer Präsentation auf möglichst einfache Weiße die Problematik klar zu machen. Es ist einfach allgemein-verständlicher wenn man Kompetenzübergreifend arbeitet.Genauso verlange ich genaue Darstellungen von meinen Kollegen.
> Gibt es eigentlich nicht mal so eine unabhängige Prüfstelle fürs > VHDL-Entwicklen? Solche Prufstellen gibt es ja, nennt sich Diplom. Und je nach Inhalt und Tiefe hat der Absolvent einen Nachweis, was er erlent hat und damit in etwa können sollte. Ich habe in beiden Bereichen ähnlich tiefe Erfahrung, beides aber sowohl praktisch als auch theoretisch erlernt. Wir hatten sowohl SW-Entwurfsstrategien, Compilerbau, Unix, S5, Treiberentwicklung, als auch theoretische Physik, Algorithmik, Nachrichtentechnik, Digitaltechnik und Halbleiterphysik. In anderen Studienrichtungen hast Du eben weniger oder gar keine Software, ausser vielleicht ein bissl C. Kommt halt drauf an! Jeder Arbeitgeber oder Projektgeber muss sich am Ende selber entscheiden, wen er nimmt und was sein Aufgabengebiet erfordert! Wenn es nur einfaches Programmieren ist und sich der Sachverhalt auf Physik bezieht, dann mag ein SW-kundiger Physiker genau der Richtige sein. Ob so jemand in VHDL fit ist, das Denken für Digitaltechnik besitzt, testfreundliche Entwicklungsmethoden kennt, Systemdesign beherrscht und sein Design im gesamtkontekt optimieren kann, sowie gleichzeitig auch die angrenzenden Elektronik-lastigen Themen beherrscht, das sei dahingestellt. Ich bevorzuge in meinem Team Fachleute, die die Erfahrung einiger Jahre haben, in dem Feld gerabeitet haben, das sie bearbeiten und das auch vernüftig studiert haben.
Ingenieure entwickeln per se nicht besser Software. Das sagen Ingenieure, die ihre Kompetenzen - Softwarekenntnisse - leider nicht einschätzen können, weil sie dazu nicht in der Lage sind. Wenn hier viele der Meinung sind, dass das so ist, behaupte ich von der Kanzel herunter: "Informatiker entwickeln besser Schaltungen". So'n Quatsch, Rosa
Nils S. schrieb: >>C, C++, Java gibt es da jede Menge > Würde mich mal interessieren, was genau da nach was geprüft wird. Leider > finde ich nur eine Hand voll Tools zum Download wenn ich nach "C Test > Tools" suche. Kannst du mir ein Stichwort oder einen Wikiartikel oder so > nenen, in dem sowas beschrieben wird? Statische Code-Analyse, Open Source: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#Open-source_or_non-commercial Statische Code-Analyse, kommerzielle Anbieter: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#Commercial
Surfen ist auch so etwas, was manche nicht so richtig beherrschen :-)
Harald, erst lesen, dann denken, dann schreiben. Mark, Danke :) ein Stichwort wie eben das "static code analysis" hat mir gefehlt, danke :)
Nils S. schrieb: > static code analysis Ich glaube, darum geht es ja, dass man solche Dinge erlernt hat und nicht erst erfragen muss. Man kennt den Begriff, die Anwendungen, kann es einordnen und von anderen Fällen abgrenzen und hat es wenigstens schon mal benutzt. Dafür ist das Studieren da! In der Software wie in der Hardware gibt es Hundertausende solche Begriffe, Methoden, Vorgehensweisen und Tricks und wer das nicht gesehen und später auch im Überblick hat, wird an viele Aufgaben komplett falsch herangehen. Da muss man sich einfach auch mal selber zurücknehmen und akzeptieren, dass ein Einzelner immer nur einen winzigen Ausschnitt von Wissen behaben kann. Alles andere wird er zu simpel einstufen und glauben, er kann es irgendwie auch. Harald schrieb: > Jeder Arbeitgeber oder Projektgeber muss sich am Ende selber > entscheiden, wen er nimmt und was sein Aufgabengebiet erfordert! Das stimmt absolut. Leider werden heute überall Anfänger und Billigheimer drangelassen, statt Fachleute zu nehmen, weil niemand mehr deren Wert erkennt, denn die Entscheider sind selber Billigheimer, die sich überschätzen.
Hallmackenreuther schrieb: > Dafür ist das Studieren da! Danke fürs Gespräch, du kannst du nicht davon ausgehen, dass jeder hier studieren war. Ich hab gelernt, was Arbeiten heisst, geh weiter an deinem Schreibtisch spielen.
Mark Brandis schrieb: > Nils S. schrieb: >>>C, C++, Java gibt es da jede Menge >> Würde mich mal interessieren, was genau da nach was geprüft wird. Leider >> finde ich nur eine Hand voll Tools zum Download wenn ich nach "C Test >> Tools" suche. Kannst du mir ein Stichwort oder einen Wikiartikel oder so >> nenen, in dem sowas beschrieben wird? > > Statische Code-Analyse, Open Source: > http://en.wikipedia.org/wiki/List_of_tools_for_sta... > > Statische Code-Analyse, kommerzielle Anbieter: > http://en.wikipedia.org/wiki/List_of_tools_for_sta... Man sollte unterscheiden zwischen statischer Code-Analyse und Test. Testframeworks wie TestNG und JUnit für Java, CppUnit für C++ usw. Damit schreibt man wohldefinierte Testfälle, die dann mindestens einmal täglich ausgeführt werden. Man sollte statische Codeanalyse nutzen, ohne auf Testfälle zu verzichten.
Klaus Wachtler schrieb: > Wer glaubt eigentlich allen Ernstes, alle Ings würden gleich gut oder > gleich schlecht SW entwickeln? > Entsprechend Informatiker, Physiker oder andere? > > Noch platter geht es ja kaum. > > Nicht einmal alle BWLer sind gleich. Aber nachts sind alle Katzen grau. Informatiker sind halt die Spezialisten. Das sollte man akzeptieren und sich nicht auf seiner Erfahrung ausruhen. Softwarenentwicklung ist mehr als nur Programmieren, Hauptsache, es funktioniert. Ich freue mich immer, wenn jemand Softwareentwicklungsliteratur liest, was selbst unter Informatikern nicht immer der Fall ist. Von einem guten Entwickler erwarte ich, dass er sich auskennt in Algorithmen und Komplexitätstheorie, Automatentheorie, Architektur und Programmiersprachen. Man muss nicht aspektorientierte Programmierung anwenden oder mögen, aber man muss wissen, was es damit auf sich hat. Da Nichtinformatiker kaum mit Komplexitätstheorie und Algorithmik in Berührung kommen, haben sie gewisse Nachteile. So sehe ich häufig, dass einige Menschen es sich besonders kompliziert machen, weil unbedacht einen Mealy-Automaten bauen, wenn es doch ein Moore-Automat genauso getan hätte. Nein, nicht genauso, sondern bessern, denn: Ein Mealy-Automat ist viel komplizierter zu pflegen. Oft entstehen durch solche unbedachten Entscheidungen Zeitverzüge von vielen Manntagen. Das ist kein Witz!
>So sehe ich häufig, dass einige Menschen es sich besonders kompliziert >machen, weil unbedacht einen Mealy-Automaten bauen, wenn es doch ein >Moore-Automat genauso getan hätte. Nein, nicht genauso, sondern bessern, >denn: Ein Mealy-Automat ist viel komplizierter zu pflegen. Oft entstehen >durch solche unbedachten Entscheidungen Zeitverzüge von vielen >Manntagen. Das ist kein Witz! Ist es tatsächlich nicht. Vormals Elektrotechnik habe ich neben BWP auch noch Informatik studiert, weil ich als E-Techniker zwar programmieren konnte, aber keine Ahnung von Komplexitäts- und Automaten-Theorie hatte. Ich hatte die Basics einfach nicht drauf gehabt. Vielleicht hätte ich vor zwei Jahren auch behauptet, ich als E-Techniker kann doch Software entwickeln. Konnte ioch aber aus heutiger Sicht eben nicht. Rosa
Hallo, vergesst mal das Studium, Einarbeiten kann man sich immer, soweit Interesse da ist. Praxis zählt viel mehr!!!
bruder-herz schrieb: > vergesst mal das Studium, Einarbeiten kann man sich immer, soweit > Interesse da ist. Praxis zählt viel mehr!!! Aber ohne ein vernünftiges Fundament wirst du immer ein Hacker bleibt. Und dieses Fundament wird in einem Studium gelegt.
Die Programmierer streiten sich, wer den Job verdient und wer gehen muss. So ist es richtig. Ich habe mich auch schon in meiner FH beschwert. Die Hochschule hat kaum eigene Stellenangebote, suggeriert aber, dass das Informatik-Studium Chancen bringt. Für den Prof. eine feine Sache: Geld kommt und die Arbeit ist bequem. Viele Dinge sind Halbwissen: + Kein Programmieren von Interrupts im Fach Betriebssysteme, aber immer schön das Unix anhimmeln. + Hardware ist auch kein Problem: Das Bild der Intel-CPU betrachten aber bitte nirgendwo den Program-Counter setzen. + N über K sollte man schon erklären, am besten aber nicht mit dem Urnenversuch. + 4 Jahre Informatikstudium ohne 10-Fingersystem sind überhaupt kein Problem, man kann es dann mit SEHR-GUT abschließen. + Mit welcher Suchtechnik findet die SQL-Datenbank innen einen RECORD: Nobody knows... + FUZZY-TECHNIK bekommt man erklärt ohne wissen zu müssen, dass Regelkreise auch schwingen können. Aber große Visionen! + Für den Netzwerk-Prof. sind Kabel nur wegen der Stabilität verdrillt: Dann schreibt doch mal über Satelliten-Internet. Neben Embedded-Steuerungen sollten Informatiker eigentlich auch den PC programmieren. Aber das wird ja in den USA gemacht. Folgenden Satz hätte ich in der FH hören wollen: "Deutschland ist ein IT Importland". So kann ich nun versuchen zwischen Logitech und USB-Hub noch eine Marktlücke zu finden. Als Informatiker erlebte ich die Embedded-Programmierung eher autoritär. "Du sollst viel Text produzieren und Klappe halten!" Es werden hier sämtliche Teile des Projektes exakt benannt und dokumentiert.
Es ist eben auch so, dass die meisten selbsternannten Informatiker nichts drauf haben und denken, eine Studium befähigt sie zum intelligenten Planen und Arbeiten. Codezeilen hinschreiben ist aber letztlich auch nichts anderes, als Sätze hinformulieren, wie es ein Theologie oder Soziologiestudent tut. Wo ist da die Leistung??? Wissen ist gefragt! Wer das Wissen hat, warum bei der Commerzbank wieder mal ein Server nicht richtig geht, der kriegt dort als Entwicker 85TDE. Wenn er weiss, warum bei Mama der Staubsauger nicht geht, kriegt 5,- die Woche Taschengeld. Kein Mensch braucht Programmierer. Wir haben Inder und Chinesen genug.
Robocash schrieb: > + Kein Programmieren von Interrupts im Fach Betriebssysteme, aber immer > schön das Unix anhimmeln. > + Hardware ist auch kein Problem: Das Bild der Intel-CPU betrachten aber > bitte nirgendwo den Program-Counter setzen. > + N über K sollte man schon erklären, am besten aber nicht mit dem > Urnenversuch. > + 4 Jahre Informatikstudium ohne 10-Fingersystem sind überhaupt kein > Problem, man kann es dann mit SEHR-GUT abschließen. > + Mit welcher Suchtechnik findet die SQL-Datenbank innen einen RECORD: > Nobody knows... > + FUZZY-TECHNIK bekommt man erklärt ohne wissen zu müssen, dass > Regelkreise auch schwingen können. Aber große Visionen! > + Für den Netzwerk-Prof. sind Kabel nur wegen der Stabilität verdrillt: > Dann schreibt doch mal über Satelliten-Internet. Man merkt schon, dass Sie von der FH sind.
McDesign schrieb: > Es ist eben auch so, dass die meisten selbsternannten Informatiker > nichts drauf haben und denken, eine Studium befähigt sie zum > intelligenten Planen und Arbeiten. Soviel ich weiss, vergibt man sich sein Diplom noch nicht selbst - von selbsternannt kann also keine Rede sein. Und: Ja, man sollte dort lernen, wie man systematisch arbeitet. Ich hab da zumindest viel mitgenommen, das mir heute hilft, besser als andere zu sein. > Codezeilen hinschreiben ist aber > letztlich auch nichts anderes, als Sätze hinformulieren, wie es ein > Theologie oder Soziologiestudent tut. Dafür hat man ja seine Programmierer :-) > Wo ist da die Leistung??? In der Analyse und Umsetzung von realen Problemen in die digitale Welt. > Wissen ist gefragt! So isses. Etwas davon lernt man im Studium. > Kein Mensch braucht Programmierer. Wir haben Inder und Chinesen genug. So sieht der Code auch aus. Chris D.
McDesign schrieb: > Kein Mensch braucht Programmierer. Wir haben Inder und Chinesen genug. McProgrammierer? Mit Verlaub: Programmieren oder besser gesagt, Software zu entwickeln, ist eine anspruchsvolle Tätigkeit. Besser als in der Commerzbank eine abgestürzte Software zu identifizieren, ist es, Software zu bauen, die 1. weniger abstürzt, 2. und wenn sie abstürzt, dann so, dass sie möglichst wenig Schaden anrichtet und auch nur die eine Funktionalität nicht mehr angeboten werden kann, die abstürtzt. Das nennt sich Robustheit. Beispiel: Textverarbeitung. Die Textverarbeitung kommt regelmäßig in einen Zustand, in der es nicht möglich ist, Wörter fett zu machen. Dann gibt es Exception. Bei einer guten Architektur würde einfach ein Dialog aufploppen und Nutzer auf die Fehlfunktion hinweisen. Bei einer schlechten Architektur verabschiedet sich das komplette Programm und damit auch das Dokument, an dem man gearbeitet hat.
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.