Druckbare Version
Ich würde mich auch als Gast verstecken, wenn ich keine Ahnung hätte:Zitat:
Zitat von Unregistriert
Java: git es seit 1995
Python: 1991
OSEK: 1994
Linux: 1992
Bring mal etwas, was wenigsten aus den 70er Jahren stammt, darf auch Ende der 70er sein!
Noch ein Tipp: Ich bin älter als BASIC.
Nächstes Mal sollten die einfach die Entwicklung der Software hier ins Forum auslagern. Die Schlauberger hier werden natürlich 100% fehlerfreie Software abliefern und den Amateuren mal so richtig zeigen wie programmiert wird.
jup, und zwar in Assembler oder Algol oder Fortran, wenn sie da schon geboren waren :D
Das ist das schöne daran, man muß nicht damals geboren worden sein, man kann es auch später noch lernen.
ich habe auch erst 1991 das erste mal in COBOL programmiert und 1992 in APL2.
Beides stammt von vor meiner Geburt.
Man muß es halt lernen, verstehen und beherschen, dann kann man damit auch fehlerarme bis fehlerfreie Progamme schreiben.
Wobei es hier ja gar nicht um fehlerfreie Programme geht sondern wie man durch Beachtung grundlegender Softwaredesign Regeln eben Fehler soweit minimiert und kapselt, das sie keine negativen Auswirkungen haben.
Bei meinem Messgeräte Projekt, habe ich einen Dr. der Informatik als Produktmanager, muß aber erst mal erklären, warum ich viele Rechnungen so aufteile, das möglichst viel mit Division durch 2 hoch n läuft.
Heute wird in den Unnis halt von PCs mit Multicore GHz CPUs ausgegangen, Das man insgesammt nur 2K für Variablen hat und ein Singlecore mit 16MHz möglichst stromsparend in so einem mobilen Messgerät mit Datenlogger werkeln soll, da bekomme ich ständig gesagt "so tief stecke ich da nicht drin".
Ich muß dann erst mal erklären, das vier Aditionen und zwei einfache Shift right sowie dann noch zweimal je eine Adition plus Shift Right halt schneller ist als 6 Werte zu adieren und anschließend eine Division durch 6 auszuführen.
Scheint so das auf vielen Unis keine Grundlagen mehr vermittelt werden.
So Absolventen kommen dann halt auch zu ESA Forschungsprojekten und sollen da natürlich möglichst frisch von der Uni sein damit sie auf dem neusten Stand sind.
Wenn das Basiswissen aber nicht vermittelt wurde und keinerlei Erfahrung vorhanden ist, kostet das halt richtig Kohle wenn mit dem Crash eines Marslanders rauskommt "so klappt es nicht".
Das dann das Testing genauso wie das Qualitätsmanagement versagt, schließt das ganze dann ab.
Eigentlich kenne ich diese Form von Trollerei und pseudointelligente Sprüche wie von Man in the moon und dem Unregistrierten (wenn das sogar mal nicht diesselben sind) nur aus einem einzigen Forum...ist nix los im mikrocontroller.net?
Wird Zeit das morgen wieder die Arbeit anfängt...
Edit:
Verlang nicht zu viel von diesen Leuten. Jemand der so redet hat noch nie den Vorteil einer strukturierten Arbeitsweise verstanden. Diesselben Leute würden auch eine Platine routen ohne sich vorher einen Schaltplan zu machen, fangen an wild draufloszuprogrammieren ohne vorher wenigstens ein grundlegenes Struktogramm zu entwerfen und evt. Schwachstellen schon vorher zu finden (Code kommentieren dauert nur unnötig und ist langweilig, und wozu zum Geier soll man denn noch eine Klasse selber programmieren?) und sehen einen Test ls erfolgreich an, wenn das Gerät beim Einschalten eine Power-On-LED leuchten läßt.Zitat:
Zitat von i_make_it
Kurz: Der Unterschied zwischen Ingenieurskunst und Bastelei.
Ätzend finde ich solche Menschen nur, wenn ich mit ihnen arbeiten muß. Ich arbeite gern mit einer fachlich vollkommen inkompetenten Person zusammen, wenn nur Lernwille und die Fähigkeit zum selbständigen Denken vorhanden sind. Die kann man wenigstens mit Erklärungen und Wissenweitergabe geradeziehen und hat irgendwann mal möglicherweise einen fähigen Kollegen. Gegen fachliche Naivität, gepaart mit Dummheit und Ignoranz, ist mir leider kein Kraut bekannt.
Vieleicht hat es ja auch was positives.
Zum Trollen werden die Posts ja gelesen.
Wenn die statistischen 10% der Informationen beim Lesen hängen bleiben, werden die Trolle durchs lesen hier ja schlauer.
Wenn die statistischen 10% stets hängen bleiben würden, wäre in den letzten Posts schon vorher mehr als nur die Aufzählung von ein paar Programmiersprachen herumgekommen.
Und was das Lesen von Threads, gepaart mit Dummheit und Ignoranz, macht, konnte wir erst kürzlich im Langlebige-Elkos-Thread sehen.
Bei uns in der Firma heist das Kraut Kündigung.Zitat:
Zitat von White_Fox
Ich bin jetzt knapp 8 Monate da und etwa ein Drittel der Neuzugänge schafft die Probezeit nicht.
Erst kommt, eine Woche Selbststudium für einen Kunden oder ein Projekt, dann 2-3 Monate Einsatz im Team und dann die erste Einzelaufgabe. Da entscheidet es sich dann.