Hallo zusammen, ich bin dabei eine Ausarbeitung über Scriptsprachen zu schreiben. Es geht speziell um Python und Perl. Also welche Sprache ist wofür besser geeignet, was für einen Sinn haben generell Scripte, Vor und Nachteile gegenüber Hochsprachen und einige Besipiele für Python und Perl. Dies alles ist aber recht theoretische gehalten. Nun würde mich mal interessieren für welche Dinge ihr Scripte benutzt? Also wir haben ein Labor indem es um die Entwicklung von Steuergerätesoftware geht. Hier haben wir verschiedene Tools wie Matlab/Simulink und CANalyzer im Einsatz. Habt ihr da Anwendungen für Python, Perl ..... ? Nutzt man Scripte zum Generieren von Headerfiles, Auswertung von Messdaten? Das sind Anwendungen die ich mir so vorstelle aber ob man sie dafür wirklich nutzt weiss ich halt nicht. Schon einmal Danke für eure Antworten. Gruß Christian
Christian schrieb: > Nun würde mich mal interessieren für welche Dinge ihr Scripte benutzt? Hier: Verifikation von ICs in der Halbleiterindustrie, einschließlich der Ansteuerung diverser Messgeräte via GPIB. Nachvollziehbarkeit und Reproduzierbarkeit sind hier die wesentlichen Stichworte, warum das alles in Scripte gegossen wird.
Hallo, ich nutze Perl hauptsächlich um Dateien o.ä. zu parsen. Aus meiner Sicht ist da gerade Perl unschlagbar. Einige Perl Scripte laufen auf Linux-Servern um mir das Management und die Verwaltung zu vereinfachen. Und ich setzte Perl und PHP in verschiedenen Modulen auf Webservern ein. Für 'richtige' Programme benutze ich fast nur C, C++ und C#. Python nehme ich ab und an mal her wenn ich was schnelles mit einer GUI brauche. Da sind mir die meisten anderen Sachen zu fett. Und weil wir hier in einem uC Forum sind, da nehme ich natürlich C bzw. Assembler. Grüße aus Berlin
Ähnlich wie Jörg nutze ich Python zum Ansteuern von Messgeräten über GPIB, USB, LAN (über NI VISA) und zum Testen von Baugruppen. Python steuert unsere Hardware und die Messgeräte an, fährt die Testparameter ab und schreibt die Ergebnisse in LaTex Files, die dann zum PDF gemacht werden können. Hat gegenüber LabView (vorherige "Lösung") den enormen Vorteil, dass wir Hardware-Entwickler da selber mal was erweitern und ändern können. Python ist ja sehr gut lesbar und verständlich. In unserem Fall IronPython, um unsere Hardware über unsere .NET DLL anzusteuern.
Vielen Dank bis hier hin! Das mit dem Parser habe ich in meiner Arbeit schon aufgeführt, da ich selbst einen Parser für DBC Files geschrieben habe. Das mit der Ansteuerung der Hardware ist mir neu aber hört sich interessant an. Bzw. in Verbindung mit HIL-Prüfständen habe ich das mal gehört. Bin mal gespannt was ihr noch so mit Scriptsprachen bewältigt.
Christian R. schrieb: > Ähnlich wie Jörg nutze ich Python zum Ansteuern von Messgeräten > über > GPIB, USB, LAN (über NI VISA) und zum Testen von Baugruppen. Python > steuert unsere Hardware und die Messgeräte an, fährt die Testparameter > ab und schreibt die Ergebnisse in LaTex Files, die dann zum PDF gemacht > werden können. > Hat gegenüber LabView (vorherige "Lösung") den enormen Vorteil, dass wir > Hardware-Entwickler da selber mal was erweitern und ändern können. > Python ist ja sehr gut lesbar und verständlich. In unserem Fall > IronPython, um unsere Hardware über unsere .NET DLL anzusteuern. Warum dann nicht direkt mit Visual Studio ud C#?
Hallo Christian, wir setzen Perl im Umfeld der "Software-Produktion" für Automotive Embedded Systeme recht umfangreich ein, um (Textformat-) Dateien zu bearbeiten, also (proprietäre) Formate konvertieren, neue Dateien erzeugen mit Informationen aus u.U. mehreren anderen Dateien, Ausgaben von Kommandozeilen-Tools weiterbearbeiten Perl ist hier flexibel, kommt auch da zum Einsatz wo make mit Text/Stringbearbeitung an seine Grenzen stößt (v.a. der Wartbarkeit ;-) ) Python setzen wir bei uns kaum ein, möglicherweise ginge das genauso, wurde halt mal mit Perl begonnen ... Gruß Erik
Neugieriger schrieb: > Warum dann nicht direkt mit Visual Studio ud C#? Da ist uns E-Technikern zuviel "Geschwurbel" drum herum, was mit dem eigentlichen Problem nichts zu tun hat. Klar ginge sicherlich auch, aber setzt immer Visual Studio voraus. In Python geht vieles einfacher und da reicht ein Texteditor und der Interpreter.
Hallo, Neugieriger schrieb: > Warum dann nicht direkt mit Visual Studio ud C#? Wozu? C# und .NjET mögen ganz nett sein, um GUI-Programme für Windows zu schreiben, haben aber sonst nur Nachteile: teuer, unflexibel, kurzfristig von der Plattform und langfristig vom Goodwill des Herstellers abhängig... Welcher verantwortungsbewußte, zukunftsorientierte Unternehmer würde so etwas freiwillig antun? Das sind doch businesskritische Gefahren für den ordentlichen Geschäftsbetrieb und eine potentielle Kosten- und / oder Abhängigkeitsfalle. LG, Karl
Und noch einer der nicht verstanden hat, dass C# nicht an Windows oder Microsoft gebunden ist. -.-
Hallo Christian, Christian schrieb: > ich bin dabei eine Ausarbeitung über Scriptsprachen zu schreiben. Es > geht speziell um Python und Perl. Also welche Sprache ist wofür besser > geeignet, was für einen Sinn haben generell Scripte, Vor und Nachteile > gegenüber Hochsprachen und einige Besipiele für Python und Perl. > Dies alles ist aber recht theoretische gehalten. Nun würde mich mal > interessieren für welche Dinge ihr Scripte benutzt? > Also wir haben ein Labor indem es um die Entwicklung von > Steuergerätesoftware geht. Hier haben wir verschiedene Tools wie > Matlab/Simulink und CANalyzer im Einsatz. Habt ihr da Anwendungen für > Python, Perl ..... ? > Nutzt man Scripte zum Generieren von Headerfiles, Auswertung von > Messdaten? Das sind Anwendungen die ich mir so vorstelle aber ob man sie > dafür wirklich nutzt weiss ich halt nicht. wir entwickeln, vertreiben und implementieren Software für die Erkennung von Betrugsmustern im Banken- und Versicherungsumfeld. Dabei fallen häufig große Datenmengen an (einige Millionen Datenzeilen mit mehreren hundert bis mehreren tausend Spalten), die dann sehr schnell und reproduzierbar verglichen und analysiert werden müssen. Dabei verwende ich Perl und flex/C für die Konvertierung von Textdaten, für Statistik und alles andere Python; für viele performancekritische Sachen habe ich aber auch ein paar C-Module für Python entwickelt. Auch für die Systemverwaltung, die Entwicklung von Webinterfaces mit Django sowie zur Visualisierung von Daten und deren zeitliche Entwicklung ist Python immer wieder eine feine Sache. HTH, Karl
Wir nutzen Python zur Messdatenauswertung. Die Daten werden vom Prüfstand in einer CSV- oder einer TDMS-Datei (National Instruments Format) gespeichert. Über ein Konsolenaufruf oder eine kleine GUI wird diese Messdatei ausgewählt und ausgewertet. Diagrammplots werden dann per Matplotlib erzeugt und per Reportlab wird dann recht komplexe und kundengerechte PDF-Reports erstellt, inklusive Datentabellen und den Diagrammen. Die Auswerteparameter werden Produkt- und Kundenabhängig aus einer XML-Datenbank ausgelesen. Der Nachteil besteht für mich darin, dass man doch mal eine Exe benötigt. Wir verteilen unsere Prüfstands- und Auswertesoftware auch ins Ausland. Würden wir den Quelltext rausgeben, würden die Mitarbeiter dort anfangen zu modifizieren etc. Über Lösungen wie Py2Exe lässt sich zwar eine Exe erzeugen, das funktioniert mit Matplotlib und Reportlab jedoch nur leidlich.
Hallo TriHexagon, TriHexagon schrieb: > Und noch einer der nicht verstanden hat, dass C# nicht an Windows oder > Microsoft gebunden ist. -.- ach Gottchen, ja, ich kenne Mono ganz gut, aber es ist ja trotz allem nur ein Notnagel. Mit C# wird man nur unter Windows richtig glücklich, genauso wie man mit Perl nur unter UNIX richtig glücklich wird. Man kann Windows zwar auch mit Perl skripten. Tatsache, das geht -- aber es ist halt wie mit einem Käsehobel zu onanieren: wenig unterhaltsam und sehr, sehr schmerzhaft. Um so etwas zu tun, muß man gute Gründe dafür haben, und "weil es irgendwie geht" ist keiner. Zumal es ja moderne Bibliotheken wie QT gibt, die unter allen diesen Desktop-Systemen schmerzfrei, angenehm und komfortabel funktionieren. Und an denen Miguel de Icaza nicht mitarbeitet. ;-) LG, Karl
Hallo MarcusW, MarcusW schrieb: > Der Nachteil besteht für mich darin, dass man doch mal eine Exe > benötigt. Wir verteilen unsere Prüfstands- und Auswertesoftware auch ins > Ausland. Würden wir den Quelltext rausgeben, würden die Mitarbeiter dort > anfangen zu modifizieren etc. Über Lösungen wie Py2Exe lässt sich zwar > eine Exe erzeugen, das funktioniert mit Matplotlib und Reportlab jedoch > nur leidlich. Was spricht denn gegen Python-Bytecode? HTH, Karl
Hi Karl Käfer, ok da muss ich dir schon zustimmen, hörte sich zunächst nach Hetze gegen C# an :). Wobei Mono ohne GUI schon zu gebrauchen ist.
Hallo Karl Käfer
>Was spricht denn gegen Python-Bytecode?
So wirds zur Zeit auch gemacht. Ist trotzdem ne unschöne Sache, aus den
pyc-Dateien soll man wohl wieder den Quelltext extrahieren können.
Außerdem muss auf dem Zielrechner Python mit allen verwendeten Paketen
installiert sein (numpy, scipy etc. etc.)
Mit dem Hinweis auf das Problem der Exe-Erzeugung wollte ich auch
eigentlich nur sagen, dass der Vorteil einer Skriptsprache auch zu ihrem
Nachteil werden kann. Ich hab mir vor einem Jahr auch nicht erträumt,
dass aus meinem kleinen Datenkonvertierungsskript mal eine richtige, an
mehreren Standorten eingesetzte Auswertung wird.
Wie macht ihr das, wenn ihr Skripte an den Kunden ausliefert? Quelltext
oder doch eine Exe?
Hi, > geht speziell um Python und Perl. Also welche Sprache ist wofür besser > geeignet Wenn Du keinen Glaubenskrieg entfachen willst, bohrst Du hier nicht tiefer ... ;-) Im Ernst: Python und Perl sind gleichwertig und gleich mächtig. Eine Entscheidung, was eingesetzt wird, hängt vom der Vorgeschichte des Projekts und den eingesetzten Entwicklern ab. > was für einen Sinn haben generell Scripte, Vor und Nachteile Vergleich Compiler-Sprache vs. Script-Sprache: gegenüber Script-Sprachen ermöglichen Compilersprachen i.d.R. die höhere Performance, wobei z.B. Python mit dem Bytecode sozusagen just in time ein Zwischencompilat erstellt, um bei der Abarbeitung Zeit zu sparen. (bei Perl gibt es m.W. nach etwas ähnliches) Script-Sprachen haben gegenüber den Compiler-Sprachen eine bessere Turnaround-Zeit in Sachen Bugfixing oder Entwicklung - der Schritt compilieren und Linken entfällt! Das wird gravierend, wenn das übersetzen Deines Projektes in Compiler-Sprache einige Stunden dauert! Also: Änderung 10 Sekunden, compilieren und Linken eine Stunde (wenn's blöd läuft!), Test ... Bei Script-Sprachen sieht das so aus: Änderung 10 Sekunden, Test ... Das sagt schon alles. Ein weiteres Argument für Script-Sprachen: die Textverarbeitung (aka Strings) ist bereits built in und gut integriert, aus u.U. mehreren Zeilen C-Code wird eine kurze Anweisung. Und zum Schluss ein Argument für Script-Sprachen, denen Compiler-Sprachen praktisch (theoretisch schon :-) ) nichts entgegensetzen können: Die Integration und Verbindung verschiedener Systeme/Programme. Da kommt es nicht mehr auf Performance an, die ist dann eh im A***. Sondern darauf, schnell und flexibel arbeiten zu können - also den Output einer Kommandozeile effizient parsen - weil's gar nicht anders geht und keine API vorhanden ist - und daraus den Input für ein anderes Programm/System machen und dies starten. (siehe oben Turnaround-Zeit) Ach ja, last but not least: einen Nachteil haben Script-Sprachen im Allgemeinen - du kannst Dich recht wenig (!) davor schützen, das ein anderer deinen Code liest, modifiziert und wo anders weiter nutzt. Einen absoluten Schutz davor gibt es allerdings auch bei Compiler-Sprachen nicht! Schönen Tag noch, Thomas (c) creative commons ... ;-)
Thomas K. schrieb: > Wenn Du keinen Glaubenskrieg entfachen willst, bohrst Du hier nicht > tiefer ... Genau das möchte ich nicht und die 2 Sprachen waren vorgegeben. Mir geht es wirklich nur um Einsatzgebiete. Das mit den Vor und Nachteilen habe ich bereits schon geschrieben und ich, dass ich einige deiner Punkte mit meinen decken.
Servus, ich nutzte Python um einen USB auf CAN Adapter anzusprechen. Diesen Adapter kann auch auch unter C/C++ ansprechen aber das ist mir dann zu viel Aufwand. In Python ging es recht schnell Messages vom CAN zu lesen und Messages zu schreiben. Einfach ein paar Zeilen Code unter Notepad erstellen, durch die Python Shell aufrufen und fertig. Zudem ist es praktisch, dass dieses Script unter Win und Linux verwendet werden kann. CANalyzer nutzen wir auch aber dort haben die Scriptsprachen bei uns keinen Einzug erhalten, da Vector ihre eigene Sprache (CAPL) hat. Ich würde dort auch lieber Python einsetzen aber ich hatte noch keine Zeit das mal zu testen. Die Auswertung mit CANalyzer klappt auch nicht immer so gut. Hier wäre ich über einen Erfahrungsaustausch froh. Generell würde ich jedem empfehlen neben einer Hochsprache noch eine Scriptsprache zu lernen. Es gibt viele kleine Dinge, die man damit erledigen kann.
Hallo MarcusW, MarcusW schrieb: >>Was spricht denn gegen Python-Bytecode? > > So wirds zur Zeit auch gemacht. Ist trotzdem ne unschöne Sache, aus den > pyc-Dateien soll man wohl wieder den Quelltext extrahieren können. Naja, Kompilate kann man auch wieder deassemblieren, das ist ähnlich kompliziert und wesentlich teurer als die Software zu kaufen. > Außerdem muss auf dem Zielrechner Python mit allen verwendeten Paketen > installiert sein (numpy, scipy etc. etc.) Naja, die verwendeten Bibliotheken mußt Du bei einem Kompilat ja auch in ein Installationspaket einpacken. Das sehe ich jetzt nicht als Nachteil. Den Aufwand, Installationspakete zu erstellen, hat man ohnehin immer. Ob ich in Setup.exe noch einige Python-Libraries als Bytecode installiere, ist kein allzu großer Aufwand. > Mit dem Hinweis auf das Problem der Exe-Erzeugung wollte ich auch > eigentlich nur sagen, dass der Vorteil einer Skriptsprache auch zu ihrem > Nachteil werden kann. Ich hab mir vor einem Jahr auch nicht erträumt, > dass aus meinem kleinen Datenkonvertierungsskript mal eine richtige, an > mehreren Standorten eingesetzte Auswertung wird. > > Wie macht ihr das, wenn ihr Skripte an den Kunden ausliefert? Quelltext > oder doch eine Exe? Kommt darauf an... :-) Einige wenige Kunden bekommen Quellcode, weil sie für diese zusätzliche Zukunftssicherheit bezahlen. Alle anderen erhalten Bytecode oder nutzen die Software sogar nur als gehosteten Service. LG, Karl
Hallo Thomas, Thomas K. schrieb: >> was für einen Sinn haben generell Scripte, Vor und Nachteile > > Vergleich Compiler-Sprache vs. Script-Sprache: gegenüber Script-Sprachen > ermöglichen Compilersprachen i.d.R. die höhere Performance, wobei z.B. > Python mit dem Bytecode sozusagen just in time ein Zwischencompilat > erstellt, um bei der Abarbeitung Zeit zu sparen. (bei Perl gibt es m.W. > nach etwas ähnliches) Perl macht das so, daß es den Quellcode erstmal komplett in Bytecode übersetzt und dann den Bytecode ausführt. Python hingegen übersetzt zwar ebenfalls in Bytecode, speichert den Bytecode aber in *.pyc-Dateien oder optimiert als *.pyo-Dateien ab. Solange die Quelldatei nicht verändert wird, verwendet Python für jeden weiteren Lauf die bereits übersetzte Version, was die Kompilierungszeit ein spart. In Perl kann man dieses Verhalten nachbauen und den Bytecode abspeichern und ausführen; während Python das automatisch macht, muß man es bei Perl erzwingen und ohne Hilfsmittel erkennt Perl nicht, ob die Quelldatei verändert wurde. > Ein weiteres Argument für Script-Sprachen: die Textverarbeitung (aka > Strings) ist bereits built in und gut integriert, aus u.U. mehreren > Zeilen C-Code wird eine kurze Anweisung. Nunja, wenn ich eine RICHTIG schnelle Textverarbeitung brauche, dann erzeuge ich C- oder C++-Code mit (f)lex und / oder bison... But this is not for the faint of heart. ;-) Andererseits kann man die so erzeugten Kompilate problemlos in Python und / oder Perl einbinden und damit die performancehungrigen Teile des Programms gezeilt beschleunigen, während weniger performancekritische Teile von den schnellen Entwicklungszyklen einer Skriptsprache profitieren können. > Und zum Schluss ein Argument für Script-Sprachen, denen > Compiler-Sprachen praktisch (theoretisch schon :-) ) nichts > entgegensetzen können: Die Integration und Verbindung verschiedener > Systeme/Programme. Es geht dabei auch um die Zugänglichkeit diverser Technologien, die in Skriptsprachen regelmäßig viel einfacher zu erreichen sind. > Ach ja, last but not least: einen Nachteil haben Script-Sprachen im > Allgemeinen - du kannst Dich recht wenig (!) davor schützen, das ein > anderer deinen Code liest, modifiziert und wo anders weiter nutzt. Einen > absoluten Schutz davor gibt es allerdings auch bei Compiler-Sprachen > nicht! Da man zumindest Perl und Python als kompilierten Bytecode ausliefern kann, hält sich diese Gefahr in Grenzen. Und die Wahrscheinlichkeit jemand zu finden, der aus dem Bytecode einer dieser Sprachen wieder Quellcode machen kann, ist wahrscheinlich deulich geringer als jemanden zu finden, der das mit einem deassemblierten Kompilat machen kann. Assembler können beispielsweise hier im Forum ziemlich viele, aber den Bytecode von Perl oder Python lesen vermutlich keine zehn. BG, Karl
Thomas K. schrieb: > Ein weiteres Argument für Script-Sprachen: die Textverarbeitung (aka > Strings) ist bereits built in und gut integriert, aus u.U. mehreren > Zeilen C-Code wird eine kurze Anweisung. Das Argument mag für C korrekt sein, aber die Stringklassen in C++ stehen dem, was die Scriptsprachen zu bieten haben, auch kaum nach.
Jörg Wunsch schrieb: > Thomas K. schrieb: >> Ein weiteres Argument für Script-Sprachen: die Textverarbeitung (aka >> Strings) ist bereits built in und gut integriert, aus u.U. mehreren >> Zeilen C-Code wird eine kurze Anweisung. > > Das Argument mag für C korrekt sein, aber die Stringklassen in C++ > stehen dem, was die Scriptsprachen zu bieten haben, auch kaum nach. Und verglichen mit den entsprechenden Klassen von Qt sind die sogar noch ziemlich unhandlich. Was übrigens für die gesamte STL gilt.
pks schrieb: > Und verglichen mit den entsprechenden Klassen von Qt sind die sogar noch > ziemlich unhandlich. Daher schrieb ich auch absichtlich in der Mehrzahl. Ich wollte mich nicht nur auf die STL beschränken, sondern hatte dabei durchaus auch Qt im Blick. Bei dem ist das String-Handling kaum noch unbequemer als in den Scriptsprachen. Wäre höchstens das memory management, welches C-ähnlich explizit ist, sodass man dynamisch erzeugte Objekte halt auch explizit am Ende ihrer Lebensdauer freigeben muss.
Josef Hübl schrieb im Beitrag #4403833: > Python ist mir in der Praxis (Automotive-Industrie) so gut wie noch nie > untergekommen. Zumindest hattest du ja nun mehr als zwei Jahre Zeit zum Recherchieren … > Allerdings ist es > ganz schön nervig, wenn man sich in ein Perl-Skript einlesen muss um > einen Fehler zu beheben. Schlecht wartbare Programme kann man nach wie vor in jeder Sprache schreiben. Man kann eine Perlscript natürlich so schreiben, dass ihn hernach keiner mehr lesen kann, aber man kann ihn auch so schreiben, dass ihn sogar noch jemand bei Bedarf (geringfügig) modifizieren kann, der zuvor noch nie Perl in der Hand hatte. BTDT.
vom letzten und diesem C3 :-) http://cdn.media.ccc.de/congress/2014/h264-hd-web/31c3-6243-en-The_Perl_Jam_Exploiting_a_20_Year-old_Vulnerability_hd.mp4 http://cdn.media.ccc.de/congress/2015/h264-hd-web/32c3-7130-en-The_Perl_Jam_2.mp4 und ja ich benutze Perl auch gerne.
:
Bearbeitet durch User
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.