Login
Newsletter

Thema: Was ist Ihre bevorzugte Skriptsprache?

61 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
mehr >_
1
Von Hr. Dingens am Fr, 27. Februar 2015 um 14:12 #

Shell-Script, wenn's unbedingt mal sein muss.

  • 1
    Von Unerkannt am Fr, 27. Februar 2015 um 14:27 #

    Dito.

    Wenn es Richtung komplexerer Abläufe geht, würde ich aber zu Python greifen.

0
Von jens jens am Fr, 27. Februar 2015 um 14:38 #

Üblicherweise Shell-Skript ziehe jedoch Python vor. Mittlerweile verstärkter Fokus auf Ruby, durch neuere Werkzeuge wie chef und puppet bekommt diese mittlerweile eine stärkere Bedeutung.

0
Von MichaMEG am Fr, 27. Februar 2015 um 14:50 #

Je nach Anforderung/Projekt: PHP (auch auf der Konsole), Perl, Shell, Python, Sonstige ...

Zur Zeit tendiere ich zu Python, aber nur falls ich genügend Zeit habe etwas komplett neu zu machen, da ich da nicht soviel selber geschriebene Libs in Python habe.

Und angefangen hat alles auf meinem Schneider CPC 464: https://de.wikipedia.org/wiki/Amstrad_CPC
mit "Locomotive BASIC" : https://de.wikipedia.org/wiki/Locomotive_BASIC

;)

Dieser Beitrag wurde 2 mal editiert. Zuletzt am 27. Feb 2015 um 15:02.
0
Von morob65 am Fr, 27. Februar 2015 um 14:56 #

ich verwende fast immer shell skripte.

0
Von hjb am Fr, 27. Februar 2015 um 15:06 #

Da ich nur Bash (und eingeschränkt zsh), Perl und Tcl beherrsche, ist die Auswahl natürlich eingeschränkt :) Ich versuche zunächst das Problem mit Bash zu lösen, wenn es aber etwas komplizierter wird oder wenn sich Perl-Module anbieten, nehme ich Perl. So ist in den letzten Jahren die eine oder andere Mini-Applikation entstanden.

0
Von Bolitho am Fr, 27. Februar 2015 um 15:40 #

Liebe PL Redaktion, es gibt in der IT kaum ein Wort, welches mit mehr Bedeutungen bedacht ist als das Wort "Scriptsprache". Ich persönlich benutze es gar nicht mehr, weil damit zu wenig eindeutig ausgesagt werden kann. Wenn Ihr es schon benutzt, könntet ihr dann nicht klarer abgrenzen, *was* genau damit im dem Kontext gemeint ist?

Automatisierte Abläufe sind die Domäne von Skriptsprache
Die im Sinne von die einzige oder im Sinne von die Hauptdomäne? Und egal was von beidem, wieso eigentlich? Oder soll das Eure Definition sein? Wieso nicht schreiben "Welche Sprache zur Automatisierung von Abläufen"? Dann braucht man das unsägliche Wort nicht verwenden und der Kontext ist sofort klar!

(Typo Hinweis: Im Text fehlt ein "n" bei "Scriptsprache" - es muss der Plural sein)

0
Von mullah am Fr, 27. Februar 2015 um 16:37 #

Alle Config-Dateien in json und als Interpreter JavaScript in Form der ultraschnellen neuen Engines mit JIT.
Das wärs :-)
*träum*

0
Von Paulibaer am Fr, 27. Februar 2015 um 18:29 #

Ich schreibe häufig kleine Programme zur Visualisierung von physikalischen Vorgängen mit Perl/Tk.
Ich habe schon oft versucht auf Python umzusteigen, aber irgendwie kann ich mich nicht trennen.
Der Mensch ist ein Gewohnheitstier.

  • 0
    Von bssh am Fr, 27. Februar 2015 um 19:21 #

    Muss man ja auch nicht. Zum Glück kann man aus vielen Sprachen wählen, und es ist letztlich eine Geschmacksfrage.
    Es ist lange her, dass ich Perl benutzt habe, aber ich wurde damit nicht warm. Python ist mir von alles Sprachen generell die liebste. Manche mögen das erzwungene Einrüclen nicht, bevorzugen die Klammern von C, mir gefällt es dagegen sehr gut. Meiner Meinung nach ist es deutlich leichter lesbar und bearbeitbar als Perl. Wer Perl mag, sollte es vielleicht eher mal mit Ruby versuchen :-)

0
Von traxanos am Fr, 27. Februar 2015 um 20:36 #

Mittlerweile nicht nur als Webscriptsprache sondern auch als Shellscript zur Steuerung von Serveraufgaben

0
Von traxanos am Fr, 27. Februar 2015 um 20:36 #

Mittlerweile nicht nur als Webscriptsprache sondern auch als Shellscript zur Steuerung von Serveraufgaben

mehr Lua
0
Von pvb am Sa, 28. Februar 2015 um 07:59 #

Shell Scripte kommen natürlich manchmal vor aber
eigentlich programmiere ich in C oder C++.

Wenn es um Script Sprachen geht,
dann ist Lua mein Favorit,
weil ich das in meine eigenen C/C++ Programme einbauen kann, um diese scriptingfähig zu machen.
Bibliotheken kann man mit
http://swig.org
mit einer Sprachenanbindung versehen.

0
Von pinguinesser am Sa, 28. Februar 2015 um 09:23 #

Perl: Wenn es ne GUI braucht (Tk, Gtk+) aber immer weniger. Es ist wirlklich unlesbar nach einer gewissen Zeit, man muss es täglich nutzen sonst vergisst man die obskure Synthax sehr schnell. Man hockt da wie ein Ägytologe und vesucht die Zeichen zu entziffern.
Äh was macht dieses seltsame Konstrukt jetzt noch mal, da gab es doch wieder ein Sonderfall wenn .... Irgendwie cool aber wenig praktikabel.

PHP: Wenn es etwas 'komplexer' wird und Netzsupport gebraucht wird, manchmal nehme ich hier auch Perl, je nachdem was es da schon an fertigen Modulen gibt nehme ich die eine oder andere Sprache. Ansonst auch für Webentwicklung (läuft alles lokal), wobei ich da immer wenige PHP verwende und so viel wie es geht in den Client stopfe (JavaScript).
Habe PHP eine Zeit lang auch beruflich nutzen 'müssen',
für "richtige" Webentwicklung ist es ein krampf, obwohl es sich 'professionalisiert' hat, es gibt ganz nette Frameworks aber unter der Haube stinkt es immer noch, die Sicherheitsmägel sind immer noch extrem und hahnebüchen. Erst letzten wieder auf Heise eine entspr. Meldung wo man sich einfach nur an den Kopf fasst.

bash: Wenn es Systemscripte sind die hauptsächlich nur andere Programme aufrufen und ein bischen Ablauflogik gebraucht wird und das Ganze automatisch regelmässig aufgerufen wird. Also sowas wie Backupscript, brenn- bildbearbeitung, ocr-script, ... Manchmal wächst so ein Programm auch und macht es dann doch in bash, wo man dann denkt, mist, hätte ich doch gleich eine neuere Scriptsprache genommen. bash ist ähnlich kryptisch wie Perl allerdings noch überschaubar auch wenn man es nur gelegentlich nutzt. Für so simples Zeug wie oben ist es ideal.

Python: Finde ich persönlich einfach scheisse, tut mir leid ich verstehe die Begeisterung einfach nicht. Versionschaos mit 2.x/3x, lahm, Whitspace als Synthaxelement ist der grössete Murks schlechthin.
Für grössere Programme taugt es auch nicht, das OO-System ist nur auf den ersten Blick toll, hat einige grobe Mängel mit dem man böse auf die Fresse fallen kann. Das Ding ist nur gehypt weil es Ubuntu, google (für ein paar Projektchen) nutzt und einige US-Unis ihre Anfängerkurse darauf umgestellt haben (vorher so ein Lispdialekt), da werden automatisch viele Pythonfanboys herangezüchtet die eh noch nie was anderes gesehen haben und für die das Beste ist.
Die ganzen angeblichen Vorteile sind reine Werbeaussagen die genauso auf andere Scriptsprachen zutreffen.

Ruby: Habe ich auch mal eine Zeit lang getestet war extram lahm, aber die Sprache selbst ist sehr schick. Wie das heute aussieht keine Ahnung, angeblich immer noch sehr lahm, ist auch nicht so populär, hat eigentlich nur wegen Rails grössere Bedeutung erlangt aber Rails selbst ist auch auf dem absteigenden Ast seit jede andere Sprache ähnliche Frameworks bietet, bin da allerdings auch nicht mehr so firm darin wie da der aktuelle Stand ist.

  • 1
    Von pvb am Sa, 28. Februar 2015 um 09:34 #

    Warum nehmen die Leute nicht gleich C++ ,
    wenn auf Linux der g++ doch bei jeder Distribution dabei ist?

    Und für GUI dann Qt.

    0
    Von kamome umidori am Sa, 28. Februar 2015 um 09:52 #

    > wobei ich da immer wenige PHP verwende und so viel wie es geht in den Client stopfe (JavaScript).

    Ist ja sehr in - empfinde ich als totale Fehlentwicklung, denn ordentlich geschriebenes PHP finde ich besser als jemandem zu erlauben seinen JS-Code unbesehen auf meinem Rechner auszuführen (halte ich für viel unsicherer). Ich bin froh über NoScript - aber ärgere mich über die vielen Websites, bei denen nicht mal mehr das Menü funktioniert ohne JS.

    0
    Von 1234567890 am Sa, 28. Februar 2015 um 10:27 #

    Whitespace als Syntaxelement ist hervorragend!. Code in Python ist für mich der leserlichste und wartbarste.

    {
    Ich verstehe um Himmels Willen nicht, warum so viele Sprachen die unsägliche C-Syntax mit den umherflatternden Blockklammern "{" kopieren.

    }

    Könntest ja mal Lua / LuaJIT probieren. Lesbar und schnell aber leider viel schwächere Batterien als Python.

    0
    Von Unerkannt am Sa, 28. Februar 2015 um 10:39 #

    Python: [...] Versionschaos mit 2.x/3x, lahm, Whitspace als Synthaxelement ist der grössete Murks schlechthin.

    In wie fern ist Python langsamer als Perl? Das Versionschaos hast du bei Bash schon innerhalb einer Version (Bash vs Sh). Whitespaces als Syntaxelement hast du bei Bash ebenfalls. Dürftest dich ja schon auf Perl6 freuen, dann hast du das Versionschaos in noch einer Sprache mehr.

    Verstehe nicht warum du das nur Python ankreidest. Du musst Python natürlich nicht mögen, andere tun es halt und ich gehöre dazu.

    0
    Von shitposter am Sa, 28. Februar 2015 um 12:20 #

    Das wirklich schlimme ist ja, dass CRuby und CPython von den zuerst genannten nichts gelernt haben, was die Implementierung angeht. Die direkte Community ist auch sehr schmerzbefreit.

    Ein Beispiel: Die C-API ist dermaßen schlecht, dass sie es nicht erlaubt, mehr als eine Instanz des Interpreters (nützlich für Debugging, Sandboxing usw.) zu erstellen.
    Stattdessen wird es sich auf so ein C Antipattern verlassen, wo irgendwo im Pythonheader durch eine Funktion eine Instanz erstellt und verwaltet wird.

    Selbst Perl kann das besser. Selbst TCC - eigentlich ein C-Compiler, den man zufällig auch einbetten kann- kann das besser. Selbst bei SQLite hat man die Notwendigkeit erkannt und deshalb wird Version 4 mehrere Umgebungen erlauben.

    0
    Von mullah am Sa, 28. Februar 2015 um 12:56 #

    So isses.
    Drum bin ich auch auf node.js rueber. Seit die Leute anfangen zu kapieren, was das tolle an funktionaler Programmierung ist, beginnen sie auch endlich, JavaScript zu verstehen.

    JavaScript hat schon eine bemerkenswerte Karriere hingelegt in den letzten Jahren: JavaScript auf dem Client, JavaScript auf dem Server, JavaScript auf der Datenbank... - fehlt nur noch auf dem Linuxsystem. Als Pendant für die Powershell sozusagen.
    Und mit JIT ist das *richtig* schnell geworden.

    Sysadmins sind halt sehr konservativ und können eher selten "richtig" programmieren bzw. Man kann froh sein, wenn sie in 1 Sprache einen Dreiteiler hin bekommen. Von wegen die geeignetste Sprache aussuchen - *lol*

    Zu C++ (hier im Thread): Viel zu komplex und fehleranfällig. Eine Ansammlung von Fehlgriffen und Deprecates aus 3 Jahrzehnten. Steinzeit der Software Entwicklung und zurecht auf dem absteigenden Ast. Entweder gleich C wenns um die letzten 5 % Performance geht oder halt gleich was modernes...

    • 0
      Von pvb am Sa, 28. Februar 2015 um 13:52 #

      > Zu C++ (hier im Thread): Viel zu komplex und
      > fehleranfällig. Eine Ansammlung von Fehlgriffen und
      > Deprecates aus 3 Jahrzehnten. Steinzeit der Software
      > Entwicklung und zurecht auf dem absteigenden Ast.
      > Entweder gleich C wenns um die letzten 5 %
      > Performance
      > geht oder halt gleich was modernes...

      Vorteilhaft ist aber, daß es einen herstellerunabhängigen Standard gibt.
      http://www.open-std.org/jtc1/sc22/wg14/www/standards
      http://www.open-std.org/jtc1/sc22/wg21/docs/standards
      Jedenfalls besser als so manche kurzlebige Sau, die schon mal hier durch das Dorf getrieben wurde.

      Und "unmodern" würde ich C auch nicht nennen,
      wenn ich z.B. an die IoT denke (Programmierung von Microcontrollern / SoC).

      Und Qt, besonders wenn ich an Linux denke, ist eines der wichtigsten Frameworks.

      • 0
        Von #! am Sa, 28. Februar 2015 um 14:02 #

        Was haben C/C++ mit Skripten (im Sinne von interpretierten Programmen) zu tun?

        0
        Von pinguinesser am Sa, 28. Februar 2015 um 15:00 #

        Was nützt mir ein "Standard" wenn die Sprache defekt ist? Was nützt mir ein Standard wenn aktuelle Compiler immer auf den Stand des letzten oder vorletzten Standards sind?
        Was die letzten Jahre in C++ in den Standard eingeflossen ist hat doch noch mehr Leute von diesem verkorksten Müllhaufen weggetrieben. C++ ist ein barocker Zombie, mit 5 Armen, 2 Köpfen jedes Teil von woanders übernommen und schlecht rangeflickt und das wird dann als grossartiges Feature verkauft.

        C++ macht nur noch in wenigen Ausnahmen Sinn und dann auch nur wenn man sich auf abgespecktes Featureset beschränkt. Qt versteckt die meisten Grausamkeiten, wer mit Qt seine Programme strickt hat von den Untiefen von C++ nicht wirklich Ahnung, das ist eher C++ mit Stützrädern. Das geht ja schon beim eigenen Makesystem los....

        • 0
          Von mullah am Sa, 28. Februar 2015 um 16:55 #

          Da hast du (leider) sehr recht...
          Heftig aber absolut hinreichend beschrieben.
          Ein wildes Sammelsurium aller guten und saublöden Ideen der letzten 30 Jahre.
          Niemand hat offenbar den Mut, da mal aufzuräumen und den uebelsten Unsinn raus zunehmen...
          Bzw. Ja, doch. Nur heißt das dann nicht mehr C++ sondern C# oder Java oder Swift ;-)
          Die hätten imho eh lieber bei "C mit Klassen" bleiben sollen. Oder "C mit allem". Heute dies morgen das und so kommts zu dem Monster mit 2 Köpfen und 5 Armen... - barock in der Tat - gut beschrieben.
          Aber wie gesagt, nicht mehr lange. Absteigender Ast. Was für Oldies die nichts neues mehr lernen können und gerne über alte Zeiten schwelgen - weist du noch, 14-18, da hats unter Wasser noch gestaubt. Und der Karl hatte ne Methode die konnte schneller RAM besorgen als alloc. Ja das war noch ein Hund...

          • 0
            Von pvb am Sa, 28. Februar 2015 um 17:24 #

            > Was für Oldies die nichts neues mehr lernen können
            > und gerne über alte Zeiten schwelgen -
            > weist du noch, 14-18,
            > da hats unter Wasser noch gestaubt. Und der Karl
            > hatte ne Methode die konnte schneller RAM
            > besorgen als
            > alloc. Ja das war noch ein Hund...

            Ich bekenne, dass ich so ein Oldie bin und vor über 30 Jahren zu der Erkenntnis gekommen bin, dass C die Vorteile von Assembler und einer Hochsprache wie Fortran miteinander vereint.
            In diesen 30 Jahren habe ich und meine Kollegen nur Murks gebaut und die neue Generation wird alles besser machen.

            • 0
              Von mullah am Sa, 28. Februar 2015 um 21:52 #

              C != C++
              Und Murks zu programmieren hat nichts oder nur wenig mit der Sprache zu tun.
              Hab nie behauptet, dass ein Programm schlecht ist, nur weil es in dieser oder jener Sprache geschrieben ist. So what?!

              Ggfls. anfälliger als notwendig (PHP), das ja.
              Ggfls. schwieriger als notwendig (Kampf mit Technik), das ja. Und genau darum geht es ja in dem ganzen Thread: Warum wählt man diese oder jene (Skript-) Sprache. Wenn du vor 30 Jahren eine für damals vielleicht richtige Entscheidung getroffen hast, weil es nix anderes / besseres gab, wäre dieselbe Entscheidung mit den heutigen Umständen dann auch noch richtig? Wohl kaum. So what?!

        0
        Von mullah am Sa, 28. Februar 2015 um 17:05 #

        Danke fuer die nette Antwort - hier meine Anmerkungen:
        Standard schön und gut. Hat aber jede Sprache in meist besserer Form; wozu bräuchte es sonst z.B. Qt? Und viel von dem "Standard" ist mehr als suboptimal.
        Hersteller unabhängig. Naja also da sag ich jetzt mal lieber nix zu...
        Zu C und "modern": Damit ist bei einer Sprache was anderes gemeint, ist schon klar, oder?

        Greets!

    0
    Von Spiderbit am Mo, 2. März 2015 um 02:40 #

    Nach deiner Logik sind 3raeder auch besser wie Fahrräder ohne solche hilfsraeder für Kleinkinder.

    Sicher bei sehr grossen Projekten mit viel teamwork mag z.b. Stativ typeing besser sein aber das kann man auch nachrüsten Google hilft.

    Zum speed versteht nicht warum das immer das primäre Gegenargument ist für 99 % aller desktop apps und consolenscripts sollte es schnell genug sein der Vorteil ist einfach bei Skriptsprachen das man Entwicklungszeit zumindest bei kleinen Sachen spart und die Optimierung auf weniger CPU Zeit lohnt oft einfach nicht bzw hab ein karaoke game mit Python geschrieben. Klar die engine lief über pyrex aber wo ist da das Problem gibt ja kein Grund nicht zu mischen wenn an der stelle ne andere Sprache besser geeignet ist

mehr C++
0
Von Tronar am Sa, 28. Februar 2015 um 19:08 #

Meine ist C++, und ich meine tatsächlich Skriptsprache! Mit dem passenden Interpreter ist das null problemo: http://root.cern.ch/
Das ist auf den ersten Blick eine wissenschaftliche Spezialsoftware, auf den zweiten aber ein C++-Interpreter und Entwicklungstool. Die wissenschaftliche Auslegung besteht nur aus einer mitgelieferten Sammlung von Bibliotheken, die man nicht benutzen muß.
Das Ding ist wie eine Shell, man kann am Prompt C++-Befehle eingeben, und die werden sofort ausgeführt. Man kann Skripte verfassen und sie wahlweise kompilieren oder interpretieren lassen, der Interpreter kann nahtlos kompilierte Libraries einbinden und bietet viele nützliche Funktionen für Debugging usw.
Man kann Objekte vom Interpreter komplett in spezielle Dateien hinausschreiben mit der momentanen Belegung ihrer Datenfelder und Subklassen, samt Typ-Informationen usw., und sie anderswo wieder einlesen, so daß sie wieder im Speicher des Interpreters sind.
Das Ganze ist ein riesengroßer Spielplatz von C++-Aufbauten mit ausgiebig Dokumentation, Tutorials, Foren usw., nützlich für wenig Bewanderte wie auch für Anspruchsvolle, aber keineswegs exklusiv für Physiker gemacht.

  • 0
    Von pvb am Sa, 28. Februar 2015 um 20:06 #

    Ist das ähnlich wie Matlab Simulink?
    http://de.mathworks.com/

    Oder Octave?
    https://www.gnu.org/software/octave/

    Oder Scilab?
    http://www.scilab.org/

    0
    Von #! am Sa, 28. Februar 2015 um 20:39 #

    Mag ja sein, dass das wie mit einem Interpreter funktioniert. Für "Skripte" benutze ich aber eher eine höhere Sprache in der ich weniger schreiben muss und das Skript lesbar bleibt.
    Dieser Ansatz vereint aber doch die schlechten Eigenschaften beider Welten (Langsamkeit + Verbosität / schlechter überschaubarer Quelltext).

0
Von schmidicom am So, 1. März 2015 um 08:37 #

Ich würde ja gerne zu einem Shell-Script greifen aber da sich jeder Shell-Interpreter anders verhält und es somit verdammt aufwendig ist das eigene Script auf allen zum laufen zu bringen schreckt mich das ziemlich ab.

  • 1
    Von hjb am So, 1. März 2015 um 11:32 #

    Es gibt kein Shell-Problem. Schon mal was von #! (gesprochen shebang) gelesen?

    #!/bin/bash

    am Anfang des Skripts, und es wird die Bash verwendet. Damit ist das Verhalten überall genau gleich.

    • 0
      Von schmidicom am So, 1. März 2015 um 11:48 #

      Dadurch wird das Problem lediglich local umgangen und ein weiteres geschaffen, eine gute Scriptsprache sollte Interpreterunabhängig sein was die Shell nicht ist.

      Fazit: Nicht wirklich massen tauglich.

      • 2
        Von Mr. X am So, 1. März 2015 um 12:21 #

        Sag mal: Wie willst du denn eine interpretierte Skriptsprache ohne ihren Interpreter verwenden?

        Richtig! Gar nicht! :P

        • 1
          Von Unerkannt am So, 1. März 2015 um 12:50 #

          Nein. Er möchte eine interpretierte Sprache benutzen ohne von einer speziellen Implementierung eines Interpreter abhängig zu sein.

          • 0
            Von schmidicom am So, 1. März 2015 um 12:57 #

            Genau so ist es und weil bei den Shell-Scripts genau dieses Kriterium nicht erfüllt wird ist es meiner Meinung nach auch unverantwortlich überhaupt noch darauf aufzubauen.

            Dieser Beitrag wurde 2 mal editiert. Zuletzt am 01. Mär 2015 um 12:58.
            • 2
              Von Unerkannt am So, 1. März 2015 um 13:33 #

              Man kann versuchen sich auf Posix-Shell zu beschränken. In wie fern man damit allerdings Glück mit den verschiedenen Interpretern hat, vermag ich auch nicht zu sagen.

              http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_01

              • 1
                Von ksh am So, 1. März 2015 um 18:35 #

                Wenn man Shell Skripte möglichst portierbar halten will, dann einfach die KORN-SHELL nehmen. Ich habe mit Linux(RedHat), Solaris und AIX Maschinen zu tun. Auf allen ist die KSH die Standard-Shell und alles ist gut. Die Korn Shell ist zwar vom Sprachumfang hinter der Bash, aber was bringen mir schöne, neue Möglichkeiten, wenn ich sie nur eingeschränkt nutzen kann? Von daher ist auf allen Maschinen der kleinste gemeinsame Nenner installiert und schon klappt das mit der Portierbarkeit ;-)

        2
        Von Schlemil am So, 1. März 2015 um 15:49 #

        Gott, was für ein Schwachsinn! :down:

        Ich möchte ein C-Programm auch mit dem Cobol-Compiler übersetzen können, und Cobol Programme mit dem von Modula , usw. - Unfaßbar wieder, was hier für "Experten" aufschlagen.

        Mahlzeit Leute! :P

1
Von klonk am So, 1. März 2015 um 19:17 #

Mein Senf dazu:
Shell: Wenn es klein ist und lediglich ein automatisierter 'Überbau' ist.
Perl: Wenn man darin geübt ist und das gewünschte schnell umsetzen kann oder wenn es eine passende Lib servierfertig gibt.
Python: Wenn es ein bisschen komplexer wird und es noch keine Vorarbeiten dazu gibt
Ruby: Wenn man Python doof findet und nicht speziell auf Libs aus Perl oder Python angewiesen ist.

  • 1
    Von klonk am So, 1. März 2015 um 19:20 #

    Nachtrag:
    Grundsätzlich keine größeren evtl. komplexeren Dinge mehr mit Perl anfangen .... es sei denn es gibt einen technischen Zwang dazu und es wird 'sauber' geschrieben und gut dokumentiert(Bruuuhahahahaha ;-) )

1
Von 80686 am Mo, 2. März 2015 um 08:06 #

Bash oder für komplexere Dinge PHP (auf der Shell)

Pro-Linux
Unterstützer werden
Neue Nachrichten