Hallo Leute, ich studiere E-Technik und hatte bis jetzt die Programmierung mittels C, und C#. Nun stelle ich mir die Frage, was später für Sprachen im Beruf zum Einsatz kommen? Speziell interressiert mich, mit was ein Leistungselektronik, elektrische Energie und Antrieb Ich freue mich, wenn ihr etwas aus eurem Berufsleben preisgeben könntet. MFG Land
LISP, Haskell und Prolog sind die wichtigsten. C solltest du gleich vergessen. Ernsthaft: C, C++, Im Testbereich Python, im Toolbereich Java, außerdem natürlich MATLAB (wenn du das mitzählst) S.
Stefan schrieb: > LISP, Haskell und Prolog sind die wichtigsten. C solltest du > gleich > vergessen. > > Ernsthaft: C, C++, Im Testbereich Python, im Toolbereich Java, außerdem > natürlich MATLAB (wenn du das mitzählst) > S. Also als "normaler" E-Techniker Automatisierung wirst du fast nur SPS-Sprachen wie Codesys oder propiritäres Zeuch finden. C ist da eine gute Grundslage, mehr nicht. Wenn du Antriebe / Motore entwicklst wirst du ziemlich zwangsläufig by µC / embedded ankommen, dann geht es eher in Richtung C, C++ und Mathlab.
Für die Arbeit, für die ich bezahlt wurde (also nicht nur private oder Uniprojekte) habe ich bisher C, C++ und Java (und VHDl, wenn man das zählen will) eingesetzt. Ein Kollege musste aber zum Beispiel auch mit Fortran programmieren.
> Autor: Quentin Biawa (land) > Datum: 11.01.2017 11:30 > Nun stelle ich mir die Frage, was später für Sprachen im Beruf zum > Einsatz kommen? Warte erst mal ab. Wenn du später SPS-Steuerungen programmierst wirst du praktisch bei jedem Hersteller, und es gibt weltweit ein paar davon, mit einer bestenfalls neuen Syntax konfrontiert. Das geht von einfacher Assembler-Anwendung bis hin zur Pascall ähnlichen Hochsprache wie bei B & R. Warum eine Pascall ähnlichen Hochsprache wie bei B & R bei einer Garagentor- Ansteuerung nötig ist habe ich bis heute nicht verstanden. Es geht auch einfacher, aber das versteht dann ja jeder !
Die Programmiersprache ist gar nicht so wichtig. Entscheidend sind die verwendeten Konzepte und Mechanismen. Also z.B. OOP, aber z.B. auch RTOS oder digitale Signalverarbeitungsalgorithmen. Wenn man die Grundlagen beherrscht, kann man sie recht leicht auf eine neue Programmiersprache übertragen.
Das kommt darauf an. Auf der untersten Ebene (µP und Konsorten) wirst Du Assembler (können viele schon nicht mehr), C und gelegentlich C++ brauchen. FPGAs haben ihren eigenen Zweig bzw. ihre eigene Sprache. B&R sind als der SPS-Familie zugehörig eine "eigene" Spezies. Interessant für Leute, die den Output ihrer Simulationssoftware direkt in eine SPS packen wollen. Ich glaube aber nicht, dass Quentin diese Richtung gemeint hat. Außerhalb der Mikrokontroller oder oberhalb der Treiberebene ist es fast immer "Firmenpolitik", welche Sprache bevorzugt wird. Fortran kann ich mir aber nur vorstellen, wenn der Chef wenigstens 65 Jahre alt ist, bzw. dessen "oberster" Entwickler.
Wenn du eine graphische Programmiersprache (z.B. LabVIEW oder Simulink) sowie eine textuelle Programmiersprache (Vorzugsweise C) beherrschst dann kannst du daraus fast alles ableiten was dir im Arbeitsleben über den Weg läuft. Lediglich ein tiefer Einstig in die objektorientierte Programmierung könnte dann noch schwieriger werden. Mit fortschreitender Erfahrung wirst du dann feststellen, dass eine Programmiersprache lediglich ein Werkzeug ist, und es eher darauf ankommt ein tiefes Systemverständnis zu entwickeln sowie eine saubere SW Architektur zu entwerfen. Just go for it!
Quentin B. schrieb: > Speziell interressiert mich, mit was ein > Leistungselektronik, elektrische Energie und Antrieb Kommt eben stark drauf, was du machst dh welchen Job du haben wirst. Wenn du z.B. oft Daten auswerten, verarbeiten und visualisieren musst (z.B. weil du als Testingenieur für Leistungselektronik arbeitest und du gerade die Daten von mehreren Testruns deiner Bauteile bekommst), kann es schon sein, dass du als gewiefter E-Techniker, der Python kann, schon nach Hause gehst, während dein Kollege, der nur Excel beherrscht, noch eine Nachtschicht einlegen muss... Aber da es ja heutzutage eher unüblich ist, dass man von Studienabschluss bis zur Pension nur einen Job hat, würde ich versuchen, erstmal die Grundlagen zu lernen (und die lernt man in jeder Programmiersprache). Wenn dich Programmieren wirklich interessiert solltest du durchaus einen Kurs aus "Grundlagen der Datenstrukturen" mit dazugehöriger (Programmier)übung aus dem Informatikstudium als Freifach belegen. Ist vielleicht ein wenig Arbeit, aber bringt dir sehr viel.
Für Motorsteuerungen etc. vor allem Differntialgleichungen, Z-Transformation, Regelungstechnik, höhere Mathematik. Die Umsetzung auf SPS/µC/DSP ist dagegen zweitrangig. Mit C und C# deckst Du alles ab (von embedded bis zur Visu am PC). Vertiefe Dich in diese Sprachen (Diplomarbeit, Studentische Hilfkraft, Hobby, Semesterjob) und versuche, jedes Jahr eine weitere (und sei es nur oberflächlich) kennenzulernen.
Sprachen sind nur mittel zum Speck. Bin in Leistungselektronik und Antriebsthemen unterwegs.... Wir machen viel in C, C++ (visualdsp++), skripte schreibe ich alle in python, dann noch Matlab/Simulink und VHDL, für Prüfstände kommt noch Labview zum einsatz (bin nicht so der Fan davon :D) Kennste eine kommste in ne andere schnell rein. Wenn du unbedingt was lernen willst, mach VHDL da darfste en bissel anders denken und lernst was... Und das kannste später sicher mal brauchen ....
Zocker_50 schrieb: > Pascall Auch hartnäckige Wiederholung macht es nicht besser. Der namensgebende Bursche hieß "Pascal" mit nur einem "l".
Lothar M. schrieb: > Zocker_50 schrieb: >> Pascall > Auch hartnäckige Wiederholung macht es nicht besser. Der namensgebende > Bursche hieß "Pascal" mit nur einem "l". Am wichtigsten ist immer noch Zeh.
Amateur schrieb: > Fortran kann ich mir aber nur vorstellen, wenn der Chef wenigstens 65 > Jahre alt ist, bzw. dessen "oberster" Entwickler. Es ging um eine alte getestete Steuerung, die angepasst werden musste. Da ist es einfacher, dass jemand in Fortran was ändert, als alles neu zu schreiben und wieder zu testen oder zertifizieren zu lassen. Ich wollte damit auch nur ausdrücken, dass alles kommen kann.
Ich habe auch fast nur mit proprietären Sprachen (oder zumindest proprietären Dialekten von "Standards") zu tun. AWL für Siemens-SPSen Transact-SQL für den Microsoft SQL Server Die halb-grafische Konfigurationssprache der Produkte meines eigenen Arbeitgebers C#. Ist theoretisch offen und alternative Implementierungen existieren, praktisch doch auch recht proprietär PHP habe ich ganz selten mal in der Hand.
Grafisch und hier noch nicht genannt: Agilent "VEE". Da ist man unter sich ;) Wird oft im Prüffeld eingesetzt, wenn der Gerätepark vornehmlich aus HP, AGILENT, KEYSIGHT usw. besteht. Wenn Du das kannst, melde dich bei mir. Aber auch jeder andere im Raum Berlin ist herzlich eingeladen :) StromTuner
Claymore schrieb: > Die Programmiersprache ist gar nicht so wichtig. Entscheidend sind die > verwendeten Konzepte und Mechanismen. Also z.B. OOP, aber z.B. auch RTOS > oder digitale Signalverarbeitungsalgorithmen. Wenn man die Grundlagen > beherrscht, kann man sie recht leicht auf eine neue Programmiersprache > übertragen. Im Prinzip vollkommen richtig. Leider sind viele Personaler an der Stelle nicht besonders schlau und erwarten, dass man genau die Programmiersprache XYZ beherrscht.
Zocker_50 schrieb im Beitrag #4860560:
> Spielt das überhaupt eine Rolle ?
Bewirb Dich mal mit einem Anschreiben, wo Du schreibst, Erfahrung in
"Pascall" zu haben. Einmal mit doppel-L wäre ein Posting-Tippfehler,
aber zweimal nicht.
Zum Topic, also Assembler ist embedded nach wie vor wichtig, selbst wenn
man nur noch recht wenige Anteile darin macht. Man muß nämlich schon
eine Vorstellung haben, in was eine Zeile Code denn letztlich umgesetzt
wird und sich mitunter auch mal ansehen, was der Compiler da rauswirft.
Mark B. schrieb: > Leider sind viele Personaler an der Stelle nicht besonders schlau und > erwarten, dass man genau die Programmiersprache XYZ beherrscht. Kann auch hin und wieder sein Gutes haben. Ich hatte mal ein lustiges Gespräch bei einer Firma, da wurde ich gefragt, ob ich Sprache X könne. Ja, schon, hab ich schonmal mit programmiert und so einiges gemacht. Nein, ob ich das so richtig extrem gut könne. Da wurde ich mißtrauisch und hakte nach, daß man sich doch ohnehin parallel zum Code auch die Doku durchliest, wenn man sich einarbeitet. Die Antwort war der Brüller: Der Code WAR die Doku. Bei mir ging die rote Warnleuchte an, ich hab mich schon in einem riesigen Haufen von laienhaft zusammengeschustertem Spaghetticode gesehen, worauf ich keine besondere Lust hatte. Wenn der Entwicklungsprozeß schon Pfusch ist, der auf Wartbarkeit nicht abgestellt ist, wird der Code ja auch nicht besser aussehen. Also habe ich einen Testballon losgelassen und ganz freundlich gefragt, ob denn geplant sei, die Entwicklung auf eine professionellere Basis zu stellen. LOL - Das Gesicht des Chefs versteinerte sich regelrecht. Ich wußte in dem Moment, daß diese Firma bei mir genauso durchgefallen war wie ich bei denen, und ich war froh drum.
Nop schrieb: > Da wurde ich mißtrauisch und hakte nach, daß man sich doch ohnehin > parallel zum Code auch die Doku durchliest, wenn man sich einarbeitet. > Die Antwort war der Brüller: Der Code WAR die Doku. Man kann in jeder Programmiersprache schlechten Code schreiben ;-)
Nop schrieb: > LOL - Das Gesicht des Chefs versteinerte sich regelrecht. Ich wußte in > dem Moment, daß diese Firma bei mir genauso durchgefallen war wie ich > bei denen, und ich war froh drum. Gut gemacht! ;-) Kommt mir bekannt vor! Mein 1. Job nach dem Studium war auch ähnlich! Konnte das nicht gleich erkennen, da ja "Testdoku" zu jedem Bug gemacht wurde! Da wurde geflucht, der ganze Spaghetticode auf der Baustelle zusammengeschustert! Keine einzige Doku, evtl ein kleines Wiki war da, das haben wir aber selbst erstellt. Der Teamleiter hatte sowieso keine Ahnung für ihn kostete Doku und Test nur wertvolle Zeit! Also halt genau wie Negativbsp. im Lehrbuch - wie man es nicht machen sollte! Sagte dann auch so nicht mehr! Qualität zählt, gleich beim 1. Mal richtig machen! Hab dann keiner zu aber danach gings besser. Trotzdem kündigte ich mit Freude da ich einen neuen besser bezahlten Job bekam. Die Top3 der Sprüche dort: Testen ist für Feiglinge Code ist die beste Doku (!) Einfach machen dass es geht
klausi schrieb: > Code ist die beste Doku (!) Man hört das ja öfter mal. Code sollte im Optimalfall schon so geschrieben sein, dass er auch Doku ist, aber dass er die Doku darstellt, ist natürlich Blödsinn. Diese Auffassung rührt zumindest teilweise wohl aus einem Missverständnis (nicht im beschriebenen Fall natürlich): https://www.martinfowler.com/bliki/CodeAsDocumentation.html
Shellfisch schrieb: > https://www.martinfowler.com/bliki/CodeAsDocumentation.html Zitat von der Seite: > One of the common elements of agile methods... Hier hab ich aufgehört zu lesen. Eigentlich alle mir bekannten Projekte, die wirklich knallhart "agil" aufgezogen wurden, sind gnadenlos damit abgesoffen und wurden anschließend doch wieder mühsam zurück auf einigermaßen konventionelle Entwicklung umgebaut. Wer mag, kann ja mal schmökern: Einmal ein verirrter, verunglückter agiler Versuch mit Test Driven Development[1] und einmal jemand, der den "Scheiß-Sudoku-Löser" dann mit etwas Nachdenken runterprogrammiert[2]. [1] http://ronjeffries.com/xprog/articles/oksudoku/ ff. [2] http://norvig.com/sudoku.html
Nop schrieb: > Da wurde ich mißtrauisch und hakte nach, daß man sich doch ohnehin > parallel zum Code auch die Doku durchliest, wenn man sich einarbeitet. Jeder hat eine andere Vorstellung von Code und Doku. Doku braucht es natürlich für - andere Projektbeteiligte (also nicht Entwickler) - ein übergeordnetes Verständnis - nicht aus dem Code ersichtliche Aspekte (Randbedingungen, Erfahrungen, Entscheidungen) Wenn aber ein Programmierer eine Doku der Quellen braucht (oder meint intensiv pflegen zu müssen), dann ist entweder der Programmierer ungeeignet oder die Quellen. Beides kenne ich.
Nase schrieb: > Hier hab ich aufgehört zu lesen. Ich halte agile auch nicht für Snakeoil (auch wenn es für einige das richtige sein mag). Aufzuhören brachte Dich aber um den Link: http://www.developerdotstar.com/mag/articles/reeves_design_main.html Dort beschreibt Reeves ein grundlegendes Missverständnis von Software-Design zu anderen Disziplinen. Im Beispiel oben würde der Bewerber sagen: Nein, technische Zeichnungen kenne ich nicht sehr gut, aber es gibt ja eine Beschreibung zu dem Getriebe. (Und natürlich sollte es die geben, sie wird aber kaum das lesen der Zeichnung erleichtern)
Nase schrieb: > Wer mag, kann ja mal schmökern: Das ist ein überaus idiotisches Beispiel für TDD. 99.9976% der Softwareentwicklung bestehen nicht aus dem Finden von eleganten Algorithmen für isolierte, übersichtliche Probleme, sondern daraus, irgendwelche Daten trivial verändert hin und her zu schieben und dabei keine Nebenwirkungen zu übersehen.
Achim S. schrieb: > - andere Projektbeteiligte (also nicht Entwickler) > - ein übergeordnetes Verständnis > - nicht aus dem Code ersichtliche Aspekte (Randbedingungen, Erfahrungen, > Entscheidungen) Eben, und vor allem Punkt 2 ist daran entscheidend, aber auch der Rest ist wichtig. Das ist nämlich die Denkarbeit, die zum Code geführt hat. Hat man nur den Code der Vorgänger, muß man sich das rückwirkend erschließen, also reverse engineering machen. Geht, ist aber sch**ße und außerdem teuer (weil langwierig). Besonders, wenn man es auch noch mit Multitasking zu tun hat, wo die Tasks miteinander kommunizieren, synchronisieren und was weiß ich. Zumal "keine Doku" üblicherweise noch schlimmere Folgen hat, weil das dann passiert, wenn in einer Pfuschbude gleich drauflosgehackt wird. Das Problem ist dann nicht nur, daß es keine Designdoku gibt, sondern es gibt auch nur ein adhoc-Design, ein Designreview hat es nie gegeben, und das wird ein gewachsenes System (auf gut deutsch: ein Haufen Spaghetti). Genau deswegen war es mir recht, daß der Chef der Pfuschbude dann nicht wollte. Der hat ja nichtmal begriffen, daß er ein ernstes Problem hatte. > Wenn aber ein Programmierer eine Doku der Quellen braucht Was genau ist "Doku der Quellen"? Also z.B. ne Schnittstellendoku sollte schon da sein: WAS kann das Modul (und was nicht!), WIE steuert man es an, WELCHE Ergebnisse kann es zurückliefern? Im Code selber halte ich es so, daß ich immer dann kommentiere, wenn ich länger nachdenken mußte. Bei kniffeligen Passagen ist dann schonmal im Schnitt genausoviel Kommentar wie Code drin. Vorteil ist aber, wenn ich in nem halben Jahr nochmal ran muß, finde ich mich rasch ein. Und wenn wer anders in 5 Jahren da Bugs beheben muß, weiß er anhand der Kommentare, was der Code bewirken SOLL, und ob es Codierfehler oder schon Denkfehler waren.
klausi schrieb: > Die Top3 der Sprüche dort: > Testen ist für Feiglinge > Code ist die beste Doku (!) > Einfach machen dass es geht Das Extrem ist sicherlich auch nicht gut. Aber in meiner aktuellen Firma erlebe ich gerade das genaue Gegenteil: Da steht eher die Einhaltung des formalen Prozesses im Vordergrund als das eigentliche Vorankommen mit der Software. Hauptsache es ist alles richtig dokumentiert, es werden seitenlange Verwahrensanweisungen abgearbeitet, um den formal korrekten Prozess eingehalten. Zu den anderen Abteilungen und nach "oben" wird dann kommuniziert wie wichtig bei uns die Qualitätssicherung sei. Aber die eigentliche Software ist schei***. Da sitzen zwei Entwickler dran (u.a. ich), kommen kaum hinterher die Anforderungsliste abzuarbeiten und an jeder Ecke wird man ausgebremst. So entsteht höchstens auf dem Papier qualitativ hochwertige Software.
Geplagter schrieb: > Aber die eigentliche Software ist schei***. Sicher, dass es nicht an dir liegt?
genervt schrieb: > Geplagter schrieb: >> Aber die eigentliche Software ist schei***. > > Sicher, dass es nicht an dir liegt? Ich hoffe doch nicht ;-) Ich bin da relativ neu dran. Vielleicht habe ich da einfach einen anderen Blick drauf.
Guter Code kann Doku sein, dazu gehört eben der Testcode, bei letzterem sieht es meist mau aus. Veraltete Doku in Form von Word Dokumenten ist Zeitverschwendung IME
Skippy schrieb: > Guter Code kann Doku sein Denk ich auch. In jeder mir bekannten textuellen Programmiersprache kann man Kommentare schreiben für alles, was nicht unmittelbar im Code erkennbar ist. Eine Bedienungsanleitung ersetzt es natürlich nicht.
Ein Anforderungsmanagent auch nicht. Allerdings gibt es auch keine agile Methode, die darauf verzichtet. Wohl gibt es anscheinend Organisationen, die darauf verzichten, aber das ist dann nicht agil, sondern chaotisch, und die gab es schon immer.
Geplagter schrieb: > Das Extrem ist sicherlich auch nicht gut. Aber in meiner aktuellen Firma > erlebe ich gerade das genaue Gegenteil: Da steht eher die Einhaltung des > formalen Prozesses im Vordergrund als das eigentliche Vorankommen mit > der Software. Hauptsache es ist alles richtig dokumentiert, es werden > seitenlange Verwahrensanweisungen abgearbeitet, um den formal korrekten > Prozess eingehalten. Zu den anderen Abteilungen und nach "oben" wird > dann kommuniziert wie wichtig bei uns die Qualitätssicherung sei. > > Aber die eigentliche Software ist schei***. Da sitzen zwei Entwickler > dran (u.a. ich), kommen kaum hinterher die Anforderungsliste > abzuarbeiten und an jeder Ecke wird man ausgebremst. > > So entsteht höchstens auf dem Papier qualitativ hochwertige Software. Extreme Übertreibungen sind natürlich in keine Richtung gut. Wobei der Fall, dass zu viel dokumentiert wird, deutlich seltener auftritt als die "Doku? Mir doch scheißegal" Einstellung vieler Programmierer.
Geplagter schrieb: > Ich hoffe doch nicht ;-) > > Ich bin da relativ neu dran. Vielleicht habe ich da einfach einen > anderen Blick drauf. Euch scheint ein erfahrender Softwareentwickler zu fehlen, das klingt ein wenig nach Klitsche mit "günstiger" Gehaltsstruktur. Sieh zu, dass man dir ein paar passende Schulungen verpasst, wenn du die nicht kriegst, schau dich nach nem neuen Job um! Wenn sich da nicht ändert, dann steckt in 1-2 Jahren das Projekt derart im Dreck, dass der Frust eskaliert und dann ist es ohnehin zu spät.
genervt schrieb: > Euch scheint ein erfahrender Softwareentwickler zu fehlen, das klingt > ein wenig nach Klitsche mit "günstiger" Gehaltsstruktur. Exakt so ist es. Wenn ich schon lese, dass es nur zwei Entwickler gibt... > Sieh zu, dass man dir ein paar passende Schulungen verpasst, wenn du die > nicht kriegst, schau dich nach nem neuen Job um! Mach das besser sofort! > Wenn sich da nicht ändert, dann steckt in 1-2 Jahren das Projekt derart > im Dreck, dass der Frust eskaliert und dann ist es ohnehin zu spät. Na hoffentlich kein Amoklauf.
Um mal auf die Ausgangsfrage zurückzukommen: Ich habe (beruflich!) bisher nur VBA benutzt-um Excelprogramme zu schreiben. Kein Witz. Zwar nur in Werkstudentenstellen und meine Skripte waren auch schon relativ ausgewachsen (das letzte Projekt hatte insgesamt ca. 12.000 Codezeilen, Kommentare und Leerzeilen nicht einberechnet), ich war aber froh um meine Java- und C-Vorlesungen. Das hat den Einstieg erheblich erleichtert, ich mußte mir VBA autodidaktisch beibringen. Ansonsten: Sprachen lernt man relativ fix. Viel wichtiger ist, Konzepte wie OOP verinnerlicht zu haben wenn man gute Programme schreiben will. Ansonsten: Möglicherweise brauchst du für den von die angesprochenen Bereich gar keine Programmierkenntnisse. Du entwickelst Hardware, die irgendwann mal einem Softwerker vor die Füße geworfen wird mit den Worten "Mach!". Dann arbeitest du aber möglicherweise mit einem CAD-Programm, das irgendeine abgefahrene Programmiersprache für Skripte unterstützt und die du nutzen könntest (was erstmal nie ein Nachteil ist).
genervt schrieb: > Euch scheint ein erfahrender Softwareentwickler zu fehlen, das klingt > ein wenig nach Klitsche mit "günstiger" Gehaltsstruktur. Ich weiß: Eigenlob stinkt, aber in bin schon ein erfahrener Softwareentwickler. Und eine "Klitsche mit günstiger Gehaltsstruktur" ist das auch nicht. > Wenn sich da nicht ändert, dann steckt in 1-2 Jahren das Projekt derart > im Dreck, dass der Frust eskaliert und dann ist es ohnehin zu spät. Weg möchte ich da eigentlich nicht, da sonst alles stimmt: Kollegen, Vorgesetzte, Gehalt, Anfahrt... Dass das Projekt in Verzug ist, scheint auch keinen zu stören, im Gegenteil über jeden kleinen Fortschritt freuen sich alle. Insofern läuft es für mich ganz gut. Ist halt nur frustrierend, wenn man weiß es könnte viel schneller und besser voran gehen. Insofern eskaliert der Frust eher bei mir - und nicht bei denen, wo er eigentlich eskalieren sollte.
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.