Login
Newsletter

Thema: Was ist Ihre bevorzugte Skriptsprache?

70 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von jph am Fr, 30. Juli 2010 um 15:05 #

PHP und Python sind definitiv keine Skriptsprachen. Perl ebenso.

Bescheuerte Umfrage...

  • 0
    Von gargamehl am Fr, 30. Juli 2010 um 15:13 #

    Es gibt keine scharfe Abgrenzung zwischen "Skriptsprache" und "dynamisch typisierter Programmiersprache". PHP, Python, Perl werden durchaus Skriptsprachen genannt.

    0
    Von Der_Andi am Fr, 30. Juli 2010 um 15:49 #

    PHP und Python sind definitiv keine Skriptsprachen.

    Dann weisst du sogar mehr, als die Entwickler...

    Von der PHP-Startseite (direkt oben links):
    PHP is a widely-used general-purpose scripting language...


    0
    Von fgdfgdfsg am Fr, 30. Juli 2010 um 18:13 #

    Kommt halt auf die Sichtweise an. Python oder Perl kann man für Skripte benutzen, aber auch zur Entwicklung konventioneller Software. Traditionell sind es Skriptsprachen aber die moderne Sichtweise ist es sie als Skriptsprachen zu bezeichnen...

    0
    Von Furgas am Fr, 30. Juli 2010 um 20:33 #

    Noe, das passt schon so. Bei den drei Sprachen werden die Programme zur Laufzeit interpretiert, damit gehören sie zu den Skripsprachen.

    • 0
      Von Neuer am Fr, 30. Juli 2010 um 20:46 #


      echo 'print "hallo"' >test.py
      python -m py_compile test.py
      rm test.py
      python test.pyc

      Merke: Module compiliert CPython nur einmal, cached danach den Bytecode in ".pyc" Dateien. Für Hauptprogramme wird kein .pyc angelegt, ginge aber auch.

      Wenn Du nur Bytecode hast und Python eine VM hat, wo ist der Unterschied zu Java, ausser in der Syntax? Auch Java übersetzt .java Dateien in .class und führt die dann in einer VM aus.

      Für mich macht nicht die Existenz eines Compilers den Unterschied aus. Der Unterschied ist in der Kompression der Sprachelemente und der Dynamischen Typisierung, aber in jedem Fall in der Möglichkeit Module für sich alleine stehend zu übersetzen.

      Sonst wäre Java eine Skriptsprache.

      Gruss,
      Kay

      • 0
        Von sauer2 am Sa, 31. Juli 2010 um 02:46 #

        Also für mich ist eine Skriptsprache eine Sprache, die in andere Software (nicht Bibliotheken) eingebettet ist, welche mit einer anderen Sprache programmiert wurde. Die Skriptsprache steuert den groben Ablauf, für alles andere wäre sie ev. zu langsam.

        • 0
          Von Neuer am Sa, 31. Juli 2010 um 12:22 #

          Hallo Du,

          Du meinst: http://en.wikipedia.org/wiki/Glue_language und da heisst es "normalerweise eine Skriptsprache.

          Denn Java hat "JNI" (Java Native Interface), eine Anbindung an native Sprachen, weil es für manches zu langsam war. Folglich wäre Java eine Skriptsprache, weil es als Gluelanguage eingesetzt wird?

          Logischerweise ist die Überlappung gigantisch gross, aber ich meine "Recht" /TM/ zu haben.

          Was ist der Unterschied von Java und Python, beantworte die Frage, und Du kommst darauf, dass sie technisch vom Design sehr ähnlich sind, bis auf einen Unterschied, den ich nannte.

          Gruss,
          Kay

      0
      Von dfghouighiudfghdif am Sa, 31. Juli 2010 um 12:23 #

      Normales Basic (zB QBasic) wird üblicherweise auch zur Laufzeit interpretiert und ist trotzdem keine Skriptsprache.... ;-)

      • 0
        Von Neuer am So, 1. August 2010 um 00:22 #

        Hm, wieso eigentlich nicht? Es gab mal Visual Basic Script, dass die gleiche Syntax hatte.

        Kann es sein, dass BASIC (meine erste Programmiersprache) einfach nur zu alt ist? Oder dass es keine Modularisierung hat (weiss nicht), oder warum?

        Gruss,
        Kay

    0
    Von Bolitho am Sa, 31. Juli 2010 um 07:19 #

    Ich schließe mich dem an! Man hätte viel klarer abgrenzen müssen, wie Script-Sprache im Kontext dieser Umfrage definiert wird.

    Stellt das eine Sprache dar, die eine Erweiterung eines bestehenden Programms ermöglicht? Genau das würde ich als Scriptsprache bezeichnen.

    Das ganze an einem Compiler festzumachen, der direkt Code für eine spezielle Architektur erzeugt halte ich für eine veraltete Ansicht. Im Zeitalter von JITs ist das keine wirklich aussagekräftige Einteilung mehr; außerdem gibt es ja auch beim Compilieren in einen anderen Byte-Code Übersetzungsarbeit.

    Vielleicht sollte man eher eine Einteilung in "Vollsprache" und "Spartensprache" (dafür gibts ja den Ausdruck DSL) in Anlehnung an die Einteilung bei Fernsehsendern vornehmen. Wobei bei den DSL ja dann der Anwendungsbereich eine Rolle spielt...

    Vielleicht sollte man daher direkt vom Anwendungsbereich ausgehen und die Umfrage zu verschiedenen Anwendungsbereichen stellen; also etwa:
    Welche Sprache nutzen Sie für Administrative Aufgaben? Welche für persönliche Automatisierungsaufgaben? Welche für Stand-Alone Applikationen?

    So in dieser Art etwa.

    • 0
      Von oxy am Sa, 31. Juli 2010 um 12:16 #

      Na, Scriptsprache ist im Kontext dieser Umfrage so definiert, dass die die aufgelistet sind dazu gehören...

      • 0
        Von Bolitho am Sa, 31. Juli 2010 um 12:43 #

        Na, Scriptsprache ist im Kontext dieser Umfrage so definiert, dass die die aufgelistet sind dazu gehören...

        Na toll... definiere ich bin draußen oder so.

        Welche Länder finden Sie toll:

        1 - Amerika
        2 - Deutschland
        3 - Die EU
        4 - Apfelkuchen

        Das ist zwar überspitzt und überzeichnet, aber genau so sinnvoll wäre diese hier. Natürlich kann ich eine Menge über eine Auswahl definieren, aber es der Abstimmende kann im Kontext schwerlich entscheiden, wenn der Zusammenhang zwischen den Werten und dem Urspungsbegriff nicht stimmig sind.

        Zudem ist die Aussage des Ergebnisses ziemlich wenig ausdrucksstark.

      0
      Von Neuer am Sa, 31. Juli 2010 um 12:28 #

      Da gibt es 2 Klassen von Entwicklern:

      a) Ein Werkzeug für alles, egal wie tauglich.
      b) Mehrere Werkzeuge, die vermeintlich angepasst sind.

      Ich tendiere zu a) kann es aber (noch) nicht durchhalten. So schreibe ich Shell-Skripte, weil Python das (noch?) nicht einfach genug macht, andere Prozesse schnell mal zu automatisieren.

      Und ich nutze noch eine besonders streng typisierende Sprache (Ada), weil ich in Python noch keinen Compiler habe, der dem nahe kommt. Das ändert sich ja vielleicht mal. :-)

      Gruss,
      Kay

      • 0
        Von Bolitho am Sa, 31. Juli 2010 um 12:45 #

        Und ich nutze noch eine besonders streng typisierende Sprache (Ada), weil ich in Python noch keinen Compiler habe, der dem nahe kommt. Das ändert sich ja vielleicht mal. :-)

        Python ist doch streng typisiert! Es ist im Gegensatz zu Ada eben dynamisch; somit (und wegen des allg. Objektmodells) kann man dafür eben keinen so effizienten Compiler schreiben. Wobei ich bei Ada den Fokus ja doch eher auf der Beweisbarkeit und Korrektheit sehen würde...

        • 0
          Von Neuer am So, 1. August 2010 um 00:37 #

          Hallo Du,

          hast ja Recht, dynamisch und sehr konsequent darin, dass wirklich alles ein Objekt ist, Module, Klassen, Literale, alles einfach. Und dann aber auch darauf ausgelegt, dass die Typen dann keine Grenzen darstellen, sondern in einander übergehen, so dass es egal ist, ob bei "a in b", was b eigentlich wirklich ist.

          Der meiste Code, weiss deshalb garnicht, welche Typen genau er bearbeitet, sondern nutzt nur Interfaces. Ich habe gerne mal "readable" oder "iterable". Das empfinde ich als nicht streng typisiert, zumal "interfaces" anders als z.B. in Java nicht gut überprüfbar sind.

          Bei Ada verwende ich dagegen inkompatible Integer (z.B. new Integer range 1..8), die sich gerade dadurch auszeichnen, dass sie nicht verwechselt werden können. Anders als bei C++ kann man nicht char *, 0L, char, short, int, etc. alle miteinander verwechseln, ohne selbst zu casten.

          Ich weiss nicht, wie man diesen Aspekt einer Sprache nennt, ich schreibe daher "besonders streng", bin aber für Vorschläge offen.

          Gruss,
          Kay

0
Von Python am Fr, 30. Juli 2010 um 15:10 #

Universell (Web, Gui, Script, Mobil App (Android), usw usf) einsetzbar und m.M.n. sexy Syntax.

Von Batteries Included und den Sitepackages mal abgesehen ;)

  • 0
    Von ff am Fr, 30. Juli 2010 um 15:53 #

    das einzige was mich an Python nervt ist der Interpreter. Der kommt ziemlich fett daher und kann bei 3-4 gleichzeitig laufenden Skripten (daemons) locker RAM schlucken.

    0
    Von oxy am Sa, 31. Juli 2010 um 12:24 #

    Vor allem das universell schätze ich sehr an Python.

    Außerdem ist der Interpreter quasi auf jedem Linux vorhanden.

    Nur für ein paar Befehle hintereinander mit ggfs ein paar IFs - da ist doch Shell ein wenig zielführender ;)


0
Von gargamehl am Fr, 30. Juli 2010 um 15:15 #

Groovy hätte man durchaus noch per Namen nennen können.

mehr ..
0
Von klöte am Fr, 30. Juli 2010 um 15:19 #

wenn es sehr schnell gehen muss -- SHELLSCRIPT
wenn es schnell gehen muss und mächtig sein soll -- PERL
wenn es mächtig und zukunftssicher sein soll -- PYTHON

  • 0
    Von jph am Fr, 30. Juli 2010 um 15:22 #

    Zukunftssicher = nicht abwärtskompatibel? :-P

    • 0
      Von klöte am Fr, 30. Juli 2010 um 15:30 #

      wenn man ab JETZT in Python3 entwickelt, dann durchaus ... ;-)

      0
      Von klöte am Fr, 30. Juli 2010 um 15:30 #

      wenn man ab JETZT in Python3 entwickelt, dann durchaus ... ;-)

      0
      Von Lexi am Sa, 31. Juli 2010 um 00:22 #

      Ich bin froh, dass ein klarer Schnitt gemacht wird. Das ist besser als irgendwelche Altlasten herumzuschleppen. Alte Anwendungen anzupassen ist leicht, wenn sie gut entwickelt waren.

      • 0
        Von Neuer am Sa, 31. Juli 2010 um 12:34 #

        Noch habe ich den Schritt zu Python3 noch nicht ernsthaft versucht, und Python 2.7 gibt mir dann noch weniger Anlass, da sie viele Sachen dahin portiert haben.

        Solange Python3 noch nicht der Default in Redhat und/oder Debian ist, komme ich wohl noch mit Python2.6 und später 2.7 klar.

        Mir fehlt bei Python3 einfach der Grund warum ich das nutzen sollte. Langsamer soll es sein, zumindest mal kein Argument. Bei print muss ich jetzt Klammern schreiben, was meiner Stümper-Debug-Aber-Schnell Technik #1 echt weh tut, nämlich einfach "print var" einfügen und Test nochmal laufen lassen. Wenn ich da dann mehrere Versuche brauche, bis beide Klammern da sind, dann verliere ich nur Zeit. ;-)

        Wenn Sie den print Token wieder einführen, dann bin ich vielleicht dabei. ;-)

        Gruss,
        Kay

        • 0
          Von Christian am Sa, 31. Juli 2010 um 14:18 #

          print als Funktion ist nun einmal sinnvoller, als print als Statement. Außerdem tun runde Klammern nun nicht wirklich weh ;-)

          • 0
            Von Neuer am Sa, 31. Juli 2010 um 14:55 #

            Hallo Du,

            ich bin irgendwie auf der Deutschen Tastatur hängen geblieben, und da tun auch runde Klammern schon weh. Tja, weiss auch nicht wieso, derzeit habe ich nur auf der Arbeit eine Englische, und das auch nur übergangsweise...

            Gruss,
            Kay

            • 0
              Von Lexi am Sa, 31. Juli 2010 um 17:09 #

              Wenn dir runde Klammern weh tun, dann bist du selbst schuld. Ich hätte Verständnis, wenn dir die geschweiften Klammern weg tun, aber dir runden? Die tippe ich, dank Zehn-Finger-Zehnsystem, ohne Verrenkung und fehlerfrei.

              • 0
                Von Neuer am Sa, 31. Juli 2010 um 18:38 #

                Immer, wenn jemand fehlerfrei in einem Posting schreibt, und dieses Fehler enthält, wird er angreifbar.

                Ich tippe so schnell wie ich denken kann mit etwa 5-6 Fingern, wobei manche allerdings aber auf wenige Tasten beschränkt sind, etwa die Daumen für Space und ALT-GR, aber bei 1000 runden Klammer, bleiben bei mir "8" oder "9" stehen, weil ich da nicht die vollständige Präzision habe.

                Das ich mit "Shift" kein Problem habe, kann man daran erkennen, dass ich auch hier gerne mit Grossbuchstaben schreibe. Da ist der kleine Finger gut geeignet (Strg darf er auch).

                Das von Dir angesprochene System ist wohl eher für SekretärInnen sinnvoll, oder? Schliesslich hat unsereiner ja die Fähigkeit dafür zu sorgen, daß man nicht soviel tippen muss. :-)

                Gruss,
                Kay

0
Von _Michael_ am Fr, 30. Juli 2010 um 16:50 #

Windows Powershell auf pro-linux - lustig. :D
Also ich nutze meistens shell-scripte für einfache Sache (mehr bekomme ich mit Shell aufgrund fehlender Kenntnisse auch nicht hin ^^). Python ist eigentlich ne tolle Sprache. Hab die schon für eine automatisierte Textfile-Modifikationen genommen, das geht mit Scriptsprachen einfach schneller als mit C++, und für Blender hab ich mir auch schonmal nen Mini-Exporter gebastelt.
Python ist definitiv für kleinere Sachen super geeignet. Für richtige Programme nehme ich dann aber doch lieber Java oder gleich C++. Dafür gibts einfach mehr und einfacher einzubindene Libs

  • 0
    Von Python am Fr, 30. Juli 2010 um 17:28 #

    Hast schon Red Hat, Google, ILM etc erklärt das Python nur was für kleine Sachen ist?

    0
    Von fjkgnfdjknfkj am Fr, 30. Juli 2010 um 18:24 #

    Benutz doch Jython, da kannst du alle Java-Libs benutzen und hast trotzdem den Komfort von Python. Ist am Anfang möglicherweise etwas schwierig zu verstehen, wie man die Java-Libs richtig einbindet (classpath, imports, Konvertierung zw. Java- und Python-Klassen) aber nach dieser Hürde heißt es dafür einfach nur noch Copy & Paste.

    Ich programmiere seit ein paar Jahren sehr viel mit Ruby (auch "normale Software") und bin dann bei JRuby gelandet. Die Kombination aus einer modernen dynamischen Sprache und einem mächtigen Pool aus Libraries finde ich einfach unschlagbar. Und in Strukturierungsmöglichkeiten (Klassen, Modules) kann sich Ruby durchaus mit Java oder C++ messen. Gehört allerdings auch einiges an Disziplin und Umdenken dazu, da daraus schnell ein Haufen Spaghetti-Code werden kann...Umgekehrt kann sich ein Java- oder C++-Projekt, wenn man Anfangs nicht höllisch aufpasst, in einen unwartbaren Haufen Schrott verwandeln, aus dem man nur schwer rauskommt.

0
Von pvb am Fr, 30. Juli 2010 um 16:55 #

Ich kann doch C/C++
Und dafür habe ich auch eigene und fremde Bibliotheken
Also mache ich auch kleine Progrämmchen in C/C++
Was sollen Scriptsprachen da für Vorteile bringen ?

Ok, ich nutze PHP für Web Sachen und lege mir ab und zu ein paar shell Scripte an.

  • 0
    Von T-Virus am Fr, 30. Juli 2010 um 17:05 #

    Für größere Sachen machen Programme Sinn aber wenn du bestimmte Dateien z.b. suchst und dies häufiger, dann ist ein Shellskript sinnvoller als ein eigenes Programm :/

    0
    Von Python am Fr, 30. Juli 2010 um 17:26 #

    Also ich schreib Programme lieber in Python als in C++ wenn es nicht gerade auf Performance ankommt.

    Ganz einfach weil viel Arbeit weg fällt z.B. dank dynamischer Typenverwaltung oder der riesen Lib.

    0
    Von dhusfiughdfi am Fr, 30. Juli 2010 um 18:29 #

    >Ich kann doch C/C++
    >Und dafür habe ich auch eigene und fremde Bibliotheken
    >Also mache ich auch kleine Progrämmchen in C/C++
    >Was sollen Scriptsprachen da für Vorteile bringen ?

    Die kleinen Progrämmchen werden viel schneller fertig, da weniger Code nötig ist. Außerdem sind sie viel leichter zu debuggen, da die Speicherverwaltung komplett vom Interpreter übernommen wird. Auch kann man ohne externe Libraries Stacktraces selber produzieren. Eigene alte C/C++-Bibliotheken kannst du mit praktisch allen modernen Skriptsprachen weiterhin ansprechen, wobei eine Portierung auch kein großer Aufwand sein sollte.

    >Ok, ich nutze PHP für Web Sachen und lege mir ab und zu ein paar shell Scripte an.
    Lern Ruby, da hast du die Einfachheit von Shellskripten und die Mächtigkeit von C++... ;-)

    • 0
      Von pvb am Fr, 30. Juli 2010 um 18:51 #

      > Die kleinen Progrämmchen werden viel schneller fertig, da weniger Code
      > nötig ist. Außerdem sind sie viel leichter zu debuggen, da die
      > Speicherverwaltung komplett vom Interpreter übernommen wird.

      Das halte ich für ein Gerücht.
      Neben der Beherrschung der Sprache, kommt es im wesentlichen darauf an, die verwendeten Bibliotheken (in und auswendig) zu kennen. Bei mir ist das hauptsächlich Qt und meine eigene Bibliothek.

      Und da habe ich mit C/C++ nun mal mehr Routine.
      Wenn ich jetzt extra für kleine Progrämmchen was anderes nehmen sollte, als bei meiner normalen Entwicklertätigkeit,
      wäre ich bestimmt langsamer.

      • 0
        Von Neuer am Fr, 30. Juli 2010 um 20:52 #

        Hallo Du,

        ich habe Qt fast immer nur mit Python benutzt, habe ich da was verpasst?

        Ausserdem kennst Du bestimmt das Konzept des Prototypen? Der wird nach ganz anderen Regeln entwickelt. Ich schreibe Programme in Ada, die ich vorher in Python als Prototyp hatte. Das geht dann natürlich viel langsamer, aber insgesamt viel schneller, weil ich am Anfang vorallem Agilität brauchte.

        Gruss,
        Kay

        • 0
          Von Python am Fr, 30. Juli 2010 um 22:01 #

          Vorallem entfällt auch hier wieder mit PyQt sehr viel...

          z.B. entfallen komplett die Header Dateien

          • 0
            Von pvb am Sa, 31. Juli 2010 um 09:13 #

            Vieles ist eben Geschmackssache.

            Qt ist in C++ geschrieben und daher ist es meiner Meinung nach am sinnvollsten auch in C++ zu programmieren, wenn man Qt verwenden will.

            Die eigenen Bibliotheken kann ich zwar mit http://swig.org auch für Scriptsprachen nutzbar machen aber ich sehe da noch nicht den Vorteil.
            Eher in Gegenteil sehe ich Nachteile. So zum Beispiel bei mehreren Threads, was zwar in Python unterstützt wird aber von den meisten Scriptsprachen nicht.

            • 0
              Von Neuer am Sa, 31. Juli 2010 um 12:45 #

              Hallo Du,

              in Python kannst Du doch auch einfach Prozesse benutzen, die sich ihre Daten teilen. Das ist eh geschickter als Threads, wo Du nicht sauber genug trennst. Guckst Du http://docs.python.org/library/multiprocessing.html das ist neu und sieht eigentlich recht einfach aus, quasi Pythonic.

              Ich habe z.B. Python in einem Projekt XMLRPC ausprobiert, das ist total einfach so z.B. die Engine von der GUI zu trennen. Ratz fatz hast Du den Mehrwert, dass das Starten der GUI überall geht, mehrere gehen, und dass es ausfallen kann.

              Mit Threads in C++ rumzuhünern, ist dagegen kein Spaß und ziemlich zeitaufwendig, wenn Du einen Bug hast.

              Gruss,
              Kay

              0
              Von Bolitho am Sa, 31. Juli 2010 um 12:48 #

              Qt ist in C++ geschrieben und daher ist es meiner Meinung nach am sinnvollsten auch in C++ zu programmieren, wenn man Qt verwenden will.

              Wenn dem so wäre, dürften alle Programme unter Linux nur in C geschrieben werden... :huh:

              ergo: Ziemlicher Unsinn diese obige Aussage!

        0
        Von feindflug am Fr, 30. Juli 2010 um 21:13 #

        Also ich bin davon abgerückt Anwendungen noch in C zu schreiben. Zum Teil wegen miesen Design/Syntax(bspw. Zeichenketten und ncurses Geraffel) zum anderen wegen den Entwicklungsprozess(Testen & Wartung). Natürlich gibts auch häßliche Seiten bei Python, aber derzeit bin ich mit Python zufriedener.

        0
        Von gfhdhnjmjkhf am Sa, 31. Juli 2010 um 13:36 #

        >Das halte ich für ein Gerücht.
        >Neben der Beherrschung der Sprache, kommt es im wesentlichen darauf an, die
        >verwendeten Bibliotheken (in und auswendig) zu kennen. Bei mir ist das
        >hauptsächlich Qt und meine eigene Bibliothek.

        Das wiederum halte ich für ein Gerücht. ;-) Eine Sprache lebt doch gerade davon eine große Menge an Libraries zu haben, damit man nicht bei *jedem* Programm erstmal 20-mal das Rad neu-erfinden muss. Klar hast du deine eigene Bibliothek, aber ich nehme an, dass du auch die andauernd erweitern musst. (Und sowas läuft ja auch nicht immer ohne Fehler ab...)

        Und glaub mir, die Bibliotheken unter C/C++ sind die Schlimmsten. Die meisten kann man intuitiv überhaupt nicht benutzen, da heißt es erstmal Anleitung lesen, Frustration, Anleitung lesen, Googlen, usw..... Unter Ruby dagegen sind Libraries kinderleicht zu installieren ("sudo apt-get install mechanize", im Code: "require 'mechanize'"). Dann kann man die interaktive Rubykonsole starten, und ein bisschen rumspielen. Ob du es glaubst oder nicht, aber viele Libraries kann man ohne Anleitung benutzen. Ich benutze zB die appengine-jruby Libs und die sind nahezu null dokumentiert, trotzdem funktionieren sie perfekt. Einmal in den Code reingeschaut, Funktionsnamen genommen, fertig. Unter C++ muss man gerade bei komplexen Libs wie Qt erst einmal alles mögliche Zeug initialisieren, Pointer weiterreichen usw usf. Oft sind diese Libraries vom Codestyle so invasiv, dass sie ihren Codestyle dem eigenen Code aufzwingen, es sei denn man betreibt gewissen Aufwand und schreibt einen Wrapper drumrum.

        Als früher fast nur C++ benutzt hatte, hatte ich deswegen auch kaum Libraries benutzt. Jetzt kann ich mit Ruby allemöglichen erdenklichen Mini-Projekte in 2-3 Stunden programmieren.

        Wie lange würdest du brauchen um einen Bot zu schreiben, der Freundesnetzwerke bei Facebook ausliest und in eine Datenbank schreibt? Dank Mechanize, Regular Expressions und Datamapper schreib ich dir so ein Teil in 1-2 Stunden!!! (Natürlich auf der Datenbank deiner Wahl!!) Ich wette mit dir, dass du so ein Progg auch ohne Plan von Ruby an einem Tag hinkriegen würdest... Oder letztens musste ich für meinen Chef (unter Zeitdruck) ein Progg schreiben, dass eine Datei Datensätzen in eine Geodatenbank schreibt. Komplett von Scratch hat es ca. 5 Minuten gedauert das Progg zu schreiben, weitere 5 Minuten und es war debugged und lief.

        >Und da habe ich mit C/C++ nun mal mehr Routine.
        >Wenn ich jetzt extra für kleine Progrämmchen was anderes nehmen sollte, als bei
        >meiner normalen Entwicklertätigkeit,
        >wäre ich bestimmt langsamer.
        Schon klar dass du in C/C++ mehr Routine hast, wenn du sonst keine anderen Sprachen benutzt. (PHP zähle ich mal nicht mit, weil man es nur für Webapps benutzen kann.) Aber es ist auch so, dass zB Ruby extrem leicht zu erlernen ist. Guckst du dir einmal ein Tutorial an, schon kannst du loslegen, weil die Befehle ähnlich wie in anderen Sprachen sind. Ruby, Python und Perl sind nicht wie C++. C++ muss mühsam erlernt werden, bis man erstmals in der Lage ist größere sinnvolle Programme zu schreiben. Ruby macht Spaß, immer, man kann direkt loslegen.

        Ich erinnere mich noch an die qualvolle Zeit damals, als ich nichtmal geschafft hatte ein Hello World kompiliert zu kriegen.

        Wenn ich Ruby programmiere oder debugge habe ich das Gefühl die ganze Zeit vorwärts zu kommen und super produktiv zu sein. Kein Rumärgern mit Pointern, Templates & Co. Es gibt nur noch Referenzen, die schlimmstenfalls Null sind, alles ist per default generisch... Wenn du schnell etwas ausprobieren willst, kannst du es schnell in die Ruby-Konsole reinpasten. (Z.B. eine Regular Expression oder um rauszufinden, welche Methoden ein Objekt anbietet...)

        Und nur mal um einen Eindruck der Fähigkeiten von Ruby zu kriegen, hier mal ein kleines TicTacToe-Progg: http://pastebin.org/435841
        halbe Stunde, 45 Zeilen, 1kB... Wie siehts mit der C++-Lösung aus? ;)

        • 0
          Von pvb am Sa, 31. Juli 2010 um 14:56 #

          Hier mal unser Projekt:
          http://pvbrowser.org
          Die Server kann man da übrigens auch in Python programmieren.

          Hier die eigene Bibliothek, von der ich gesprochen habe:
          http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classes.html
          Damit und zusätzlich noch Qt,
          kann ich auch viele kleinere Progrämmchen schnell erstellen.

          • 0
            Von arwerk,irdegrt am Sa, 31. Juli 2010 um 15:35 #

            Sicher, aber die Ruby-Lösung ist immer schneller erstellt und weniger Lines Of Codes. Hier mal ein Beispiel aus deiner Lib (http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/rltime_8cpp_source.html):

            00263 t.year = year + time.year;
            00264 t.month = month + time.month;
            00265 t.day = day + time.day;
            00266 t.hour = hour + time.hour;
            00267 t.minute = minute + time.minute;
            00268 t.second = second + time.second;
            00269 t.millisecond = millisecond + time.millisecond;
            00270
            00271 y = t.year;
            00272 if(t.month > 12 || (t.month==12 && t.day==31 && t.hour>=24)) y++;
            00273 m = t.month;
            00274 if(t.month > 12 || (t.month==12 && t.day==31 && t.hour>=24)) m = 1;
            00275
            00276 switch(m)
            00277 {
            00278 case 1: // january
            00279 maxmonth = 31;
            00280 break;
            00281 case 2: // february
            00282 maxmonth = 28;
            00283 if(y%4==0) maxmonth = 29;
            00284 break;
            00285 case 3: // march
            00286 maxmonth = 31;
            00287 break;
            00288 case 4: // april
            00289 maxmonth = 30;
            00290 break;
            00291 case 5: // may
            00292 maxmonth = 31;
            00293 break;
            00294 case 6: // june
            00295 maxmonth = 30;
            00296 break;
            00297 case 7: // july
            00298 maxmonth = 31;
            00299 break;
            00300 case 8: // august
            00301 maxmonth = 31;
            00302 break;
            00303 case 9: // semptember
            00304 maxmonth = 30;
            00305 break;
            00306 case 10: // october
            00307 maxmonth = 31;
            00308 break;
            00309 case 11: // november
            00310 maxmonth = 30;
            00311 break;
            00312 case 12: // december
            00313 maxmonth = 31;
            00314 break;
            00315 default:
            00316 maxmonth = 0;
            00317 break;
            00318 }

            In Ruby wärs:
            ["year","month","day","hour","minute","secound","millisecond"].each{|z| eval "t.#{z} = #{z} + time.#{z}"}
            y = t.year
            if(t.month > 12 || (t.month==12 && t.day==31 && t.hour>=24)) y+=1
            m = t.month
            if(t.month > 12 || (t.month==12 && t.day==31 && t.hour>=24)) m = 1
            maxmonth = if [1,3,5,7,8,10,12].include?(m)
            31 # januar, march, may, july, august, october, december
            elsif m == 2
            (y % 4 == 0) ? 29 : 28 # february
            else
            30
            end
            #Wenn keiner der Monate zutrifft, wird maxmonth nil, womit man sich Abfrage wie "if #(maxmonth == 0) /* Fehler... */" spart, da arithmetische Operationen auf maxmonth #sofort eine Nilexception hevorrufen.


            Das sind 56 Zeilen vs. 12 Zeilen!!!


            Und wäre die Library in Ruby oder Python, könntest du auch von C/C++ aus zugreifen....

            Also wenn du mich fragst, hat C/C++ außerhalb der Systemprogrammierung und speziellen Nischenanwendungen keinen Nutzen mehr.

            • 0
              Von pvb am Sa, 31. Juli 2010 um 15:53 #

              Das Innere der Library ist vielleicht länger,
              aber nicht deren Benutzung.

              Außerdem wirst Du an der Library sehen, dass das was mit Automatisierungstechnik zu tun hat. Bei Ruby ist da wahrscheinlich Schluß.

              PS:
              Die Library läuft übrigens nicht nur unter Unixoiden und Windows, sondern sogar unter OpenVMS.

              • 0
                Von pvb am Sa, 31. Juli 2010 um 16:05 #

                Eine Anmerkung zur Kürze von Code

                Man kann in fast allen Sprachen Dinge sehr kurz formulieren.
                Besonders bekannt dafür ist Perl.

                Die Lesbarkeit eines Programmes steht aber dann wieder auf einem anderen Blatt.

                Bei ähnlichem Codingstil werden die Programme in fast allen Sprachen ähnlich viele Zeichen verbrauchen.

              1
              Von Python am Sa, 31. Juli 2010 um 17:51 #

              Jetzt will ich mal ne A4 mit Code in dem Stil von dir:

              "["year","month","day","hour","minute","secound","millisecond"].each{|z| eval "t.#{z} = #{z} + time.#{z}"}
              y = t.year
              if(t.month > 12 || (t.month==12 && t.day==31 && t.hour>=24)) y+=1
              m = t.month
              if(t.month > 12 || (t.month==12 && t.day==31 && t.hour>=24)) m = 1
              maxmonth = if [1,3,5,7,8,10,12].include?(m)
              31 # januar, march, may, july, august, october, december
              elsif m == 2
              (y % 4 == 0) ? 29 : 28 # february
              else
              30
              end"

              Mal sehen wieviele Ruby Geeks dann diese A4 Seite problemlos checken ohne 10x zu lesen XD

              • 0
                Von hefti am So, 1. August 2010 um 17:00 #

                Ja, man braucht lange um eine A4 Seite voll mit Metaprogrammierung zu verstehen, nur kann die eben auch so viel wie 10 Seiten ohne (immer unter Bedingung, dass es sinnvoll eingesetzt wird). 10 Seiten lesen, dauert auch länger als eine zu lesen.

                Das Problem bei Metaprogrammierung wie bei allen "cleveren" Sachen ist, dass es womöglich jemand überhaupt nicht oder falsch versteht. Ich würde daher instance_eval, class_eval oder eval nie ohne Kommentar benutzen, womit es dann natürlich wieder länger wird. ;-)

0
Von zettberlin am Fr, 30. Juli 2010 um 18:16 #

gibt es allen Ernstes Leute, die "kleine Hilfsprogramme" in JavaScript schreiben?

In PHP geht das tatsächlich, auch, wenn es allemal krude ist. Aber JavaScript? Gibt es denn Erweiterungen, mit denen man mit der JavaScript-Engine auf die nötigen Systemressourcen zugreifen kann?

Ich hoffe doch eher nicht .-|

  • 0
    Von sauer2 am Fr, 30. Juli 2010 um 18:27 #

    wieso? mit qtscript funktioniert das und Gnome zieht da halt nach.

    • 0
      Von zettberlin am Fr, 30. Juli 2010 um 20:13 #

      Ahhh - verstehe.

      Qtscript führt Scripte in ECMA-Synthax aus. Ist das unter Linux vom Konqueror getrennt? Oder kann ich auch auf einer Website JavaScripte ablegen, die dann von qtscript ausgeführt werden?

      Für "kleine Aufgaben" halte ich das Ganze dann aber weiter für überflüssig. Meistens geht es doch um sehr spezielle Dinge, die man mit einem Script erledigen will und da sind Bash und Perl so ausgefeilt, dass man eigentlich nichts anderes braucht.
      Oder hat JavaScript irgendwelche Vorteile, von denen ich noch nicht gehört habe?

      • 0
        Von sauer2 am Sa, 31. Juli 2010 um 02:51 #

        Soweit ich weiß ist der JavaScriptinterpreter für QtScript unabhängig von Browsern.
        Aber bei Dingen, die man sonst in Bash macht, wüsste ich so auch keinen Vorteil, warum man sie in JavaScript erledigen sollte. Ich meinte eher so Mini-GUIs für irgendwelche speziellen Anpassungen von GConf etc so mit Schieberegler und anderen Bedienelementen.

        0
        Von Bolitho am Sa, 31. Juli 2010 um 07:57 #

        Als Beispiele könnte man dafür auch Plasmoide anführen! Auf kde-look.org kannst Du ja mal in diesen stöbern; da sind einige in JS geschrieben dabei...

        Auch generelle Anpassungen am plasma-desktop sind per JS machbar; so ist ein Ziel der KDE-Entwickler somit Distributoren ein einfaches Mittel an die Hand zu geben, spezifische Einstellungen des Desktops über Scripte zu realisieren.

        Sollte ich das ein wenig krude dargestellt haben, wird sebas hier sicherlich das ganze klarstellen :-)

    0
    Von argonaut am Fr, 30. Juli 2010 um 19:36 #

    Installier die mal Paket "seed" und führe beispielsweise folgendes JavaScript aus: gtktextview.js

    0
    Von hosi am Sa, 31. Juli 2010 um 01:11 #

    Es gibt auch Ansätze, JavaScript serverseitig laufen zu lassen:
    http://en.wikipedia.org/wiki/Comparison_of_Server-side_JavaScript_solutions

    Damit lässt sich prinzipiell mit JavaScript alles machen...

Pro-Linux
Traut euch!
Neue Nachrichten