Bisher habe ich mit C und C++ programmiert (= ein paar einfache Programme zusammengehackt). Aber wenn man mit C/C++ mehr als einfache Konsolenprogramme machen will, wirds ein Kuddelmuddel. Dateihandling und Netzwerk sind ne Wissenschaft für sich und der Einsatz von zig Bibliotheken ist auch inflationär. Von GUI will ich gar nicht reden...

Ich suche daher eine einfache, schnell erlernbare (Hoch-)Sprache. Optimal wäre, wenn so Sachen wie Dateien lesen/schreiben, Netzwerk, einfache GUI, etc. gut unterstützt werden. Die Sprache sollte einigermaßen bekannt sein, um bei Fehlern schnell Hilfe/Anleitungen zu finden. Wenn es eine gute IDE gibt und die Sprache auch unter Win und Mac benutzt werden kann, wäre ich zufrieden!

Mir geht es nicht um große Projekte oder "schöne" Programme. Ich will einfach schnell was für meine Bedürfnisse zusammenschustern, ohne großen Aufwand. Ausführungsgeschwindigkeit der Programme ist zweitrangig.

Was gibts da für passende Sprachen? Java? Perl? Python? Weitere? Was ist empfehlenswert?

Cheetah schrieb:

Was gibts da für passende Sprachen? Java? Perl? Python? Weitere? Was ist empfehlenswert?

Ist alles empfehlenswert, wobei ich mit Perl bisher nicht wirklich was gemacht habe. Du wirst allerdings nicht drumherum kommen, zig Bibliothken zu verwenden. Es erfordert vielleicht ein wenig Struktur im Source-Ordner und auch Wissen innerhalb der IDE, wie man die Bibliotheken anspricht und einbindet, aber dafür gehts danach um so schneller. Man muß das Rad nicht neu erfinden. Die Hilfen sind jeweils immer ein bißchen anders strukturiert und zu finden, aber nach ein bißchen Übung ist das kein Problem mehr.

Die Latte liegt vielleicht am Anfang recht hoch, aber es lohnt sich, sich damit mal intensiv auseinander zu setzen, auch wenn sich am Anfang nicht wirklich Programmierergebnisse ergeben. Aber letztendlich kommt man da nicht rum, egal welche Sprache man wählt.

Ich persönlich mag Perl sehr gerne, da man damit mit wenig Zeilen viel REsultate erzeugen kann. Allerdings ist die Objektorientierung damit ein Krampf; außerdem habe ich bisher nur wenige bis gar keine IDE dafür gefunden.

Python wäre das nächste Mittel der Wahl. Dafür gibts imho auch gute IDEs bzw. Plugins für solche, sie ist gut strukturiert, man kann so gut wied jedes Programmierkonzept verwenden, dass man will, und man muss keine Geschweiften Klammern verwenden. Habe damit allerdings noch nicht programmiert.

Um Java würde ich erst mal einen Bogen machen. Einerseits ist die Sprache sehr mächtig, andererseits nicht unbendingt einsteigerfreundlich.

Java ist einfach, zu einfach dass macht die praktische Anwendung zu kompliziert weil man irgendwie versucht produktiv zu sein ohne sich an der Kindersicherung zu stören. Am Ende hat man dann eine relativ einfache Sprache aber beschäftigt sich dafür mit komplexen Design.

Perl ist durchaus brauchbar und sehr mächtig, die Fähigkeit in wenig Code ziemlich viel auszudrücken kommt aber zu dem Preis von schwerer Lesbarkeit wenn man sich nicht zurück hält. Ein weiterer Vorteil ist natürlich dass du für Perl ein gewaltiges Angebot an Bibliotheken für jeden Zweck vorfindest.

Als Sprachen am ansprechendsten finde ich Python und Ruby die beide recht ähnlich sind. Ruby gewinnt momentan im KDE Umfeld an Beliebtheit und die Anbindung für Qt erlässt die Python Variante lächerlich erscheinen, die durch ihre Ähnlichkeit zur C++ Variante nur damit glänzen kann dass man auf die C++ Doku zurückgreifen kann. Du wirst aber auf deinem System schon jetzt eher eine Reihe von Python Anwendungen finden als Ruby Anwendungen, wenn du überhaupt eine hast. Daher ist Python meiner Meinung nach deutlich attraktiver.

Ob Python, Ruby oder Perl muss dir aber klar sein dass aufgrund der dynamischen Natur der Sprachen eine IDE dir nicht sonderlich hilft. Du solltest deinen Fokus auf einen guten Editor legen den du so anpassen kannst dass er zu deinen Gewohnheiten passt. Allein für Refactoring und Debugging braucht du keine IDE, wobei es für mich ein Rätsel darstellt wofür man zumindest bei Python einen Debugger braucht.

Cheetah schrieb:

Was gibts da für passende Sprachen? Java? Perl? Python? Weitere? Was ist empfehlenswert?

Wenn ich mich zwischen den deien entscheiden müsste würde ich Java nutzen. Sehr einfach zu erlernen und es gibt sehr viel Material für Einsteiger. Netbeans und Eclipse sind hervorragende Entwicklungsumgebungen die einem viel Arbeit abnehmen. Python ist zwar auch sehr cool da man verglichen zu Java sehr viel Zeilen Code spart aber ich finde es Später nicht mehr so Leserlich.

Aber unterm Strich ist halt immer die Frage was du machen willst. Wenn du viele kleine Dinge machen willst ist Python sicher besser.

DasIch schrieb:

... die Anbindung für Qt erlässt die Python Variante lächerlich erscheinen, die durch ihre Ähnlichkeit zur C++ Variante nur damit glänzen kann dass man auf die C++ Doku zurückgreifen kann.

Was genau spricht denn gegen eine Ähnlichkeit? Stören Dich etwa die Methoden-/ Klassen-Namen? Oder was monierst Du sonst daran? Ich muss gestehen, dass ich Ruby sowie dessen Qt Wrapping nicht kenne, aber ich finde PyQt sehr angenehm und imho gliedert es sich gut in Python ein.

Allein für Refactoring und Debugging braucht du keine IDE, wobei es für mich ein Rätsel darstellt wofür man zumindest bei Python einen Debugger braucht.

Man kann damit z.B. zur Laufzeit prüfen, welcher Typ an welchen Namen gebunden wird. DuckTyping hin oder her ist es eben oftmals doch hilfreich zu wissen, was wann genau passiert. Aber sagen wir es mal so: Oft habe ich auch nicht darauf zurückgegriffen bisher. Aber besser ein Kondom haben, und keines brauchen oder so ähnlich

Generell gilt aber für sicherlich alle Sprachen: Bevor man sich in die GUI-Programmierung stürzt, sollte man sehr gut mit der Sprache vertraut sein. Ansonsten geht das in jeder Sprache schief.

Perl ist durchaus brauchbar und sehr mächtig, die Fähigkeit in wenig Code ziemlich viel auszudrücken kommt aber zu dem Preis von schwerer Lesbarkeit wenn man sich nicht zurück hält.

Naja 15 Jahre alte Sprüche lassen sich nicht unbedingt auf die Heutige zeit anwenden. Der Spruch das Perl Kompakt ist kommt aus der Anfangszeit aus Perl. Zu einer Zeit als C und C++ vorgerherscht hat oder das Shell Skripting. Und verglichen zu diesen Sprachen mag es wirklich kompakt sein (Zu Java mag es sicherlich auch noch stimmen). Verglichen allerdiengs mit Python oder Ruby oder manchen anderen neueren Vertretern stimmt die Aussage nicht mehr. Ein Ruby oder Python ist wohl genauso kompakt, in manchen fällen mag es sogar kompakter sein. Wenn ich OOP in Perl ohne Module mache wird es sogar ziemlich schnell aufgebläht.

Ansonsten das es deswegen gleich unlesbar wird, ist wiederrum ein blödsinn der durch ein Voruteil durch die kombination von einen alten Spruch entsteht. Die heutige realität trifft es nicht mehr wirklich.

Ansonsten ist kompakter Code generell ein Vorteil, generell in jeder Programmiersprache. Je weniger Codezeilen du brauchst um ein Problem zu beschreiben desto leichter und überblickender wird es für den lesenden. Je weniger Code du brauchst um etwas zu schreiben, desto weniger Fehler macht man. Und je weniger Code du brauchst wird es in der Regel auch einfacher sein.

Wenn man in Plain Perl für eine Klasse 100 zeilen bräuchte, und für das gleiche in Python oder Ruby nur 1/4 der Codezeilen bräuchte, dann würde sofort jeder Python/Ruby Programmierer sagen das es übersichtlicher ist, leicht verständlicher ist etc. und nicht das es schwerer lesbar wird weil man weniger Code zeilen gebraucht hat. Generell würde man sagen das die gleiche Aufgabe einfacher ist, und nicht komplizierter, den man hat ja nur 1/4 des aufwandes benötigt.

Ich persönlich mag ja noch immer Tcl.

12 simple Regeln für Syntax und Semantik:

http://www.tcl.tk/man/tcl8.5/TclCmd/Tcl.htm

Unbekannt ist die Sprache sicherlich nicht, aber im Web-2.0-Zeitalter andererseits auch sehr weit entfernt von großer Popularität. Aber im hauseigenen Wiki und in der Newsgroup findet man eigentlich immer Hilfe. Eine exzellente Dokumentation für GUI-Programmierung mit Tcl und Tk (auch für Ruby, Perl und Python) findet man hier: TkDocs.

Nicht zu vergessen ist, dass es 1994 den Ritterschlag durch Richard Stallman gab: The Tcl War.

DasIch schrieb:

Ruby gewinnt momentan im KDE Umfeld an Beliebtheit und die Anbindung für Qt erlässt die Python Variante lächerlich erscheinen, die durch ihre Ähnlichkeit zur C++ Variante nur damit glänzen kann dass man auf die C++ Doku zurückgreifen kann.

Quelle.

@arima teppei: Tcl ist nur eine bessere Shell-Sprache, die nicht mal vernünftige Datentypen besitzt. Tk hat seine besten Zeiten ebenfalls hinter sich.

Lunar schrieb:

Tcl ist nur eine bessere Shell-Sprache, die nicht mal vernünftige Datentypen besitzt.

Ja, denn die völlige Absenz von Datentypen -- in der Diktion von Tcl: "Alles ist ein String" -- ist eine der fundamentalen Grundideen hinter Tcl. So what?

Wenn Du schon Erfahrung mit C++ hast, würde ich dir Qt empfehlen.

Lysander schrieb:

DasIch schrieb:

... die Anbindung für Qt erlässt die Python Variante lächerlich erscheinen, die durch ihre Ähnlichkeit zur C++ Variante nur damit glänzen kann dass man auf die C++ Doku zurückgreifen kann.

Was genau spricht denn gegen eine Ähnlichkeit? Stören Dich etwa die Methoden-/ Klassen-Namen? Oder was monierst Du sonst daran?

PyQt4 hat weder properties noch hält es sich an PEP 8. Man kann froh sein sich nicht mehr mit den C++ Signaturen beschäftigen zu müssen. Qt ist gut gemacht und ich halte es durchaus für die beste Lösung im Python Umfeld, dass sagt aber mehr über meine Meinung zu den anderen Toolkits aus. Ich hoffe nur dass mit PySide eine pythonische Lösung kommt.

Lunar schrieb:

DasIch schrieb:

Ruby gewinnt momentan im KDE Umfeld an Beliebtheit und die Anbindung für Qt erlässt die Python Variante lächerlich erscheinen, die durch ihre Ähnlichkeit zur C++ Variante nur damit glänzen kann dass man auf die C++ Doku zurückgreifen kann.

Quelle.

Soweit ich dass sehe steigt die Anzahl der Posts zu Ruby in der kde-bindings Mailinglist und auf identi.ca taucht der Name Ruby auch immer öfter auf.

Kritikpunkte an PyQt4 dürftest du selber genug kennen.

PySide hält sich allerdings auch nicht an PEP 8, wenn ich mir so die Funktionsnamen in der Doku ansehe...

@DasIch: Namensgebung und Eigenschaften?! Das sind Deine einzigen Kritikpunkte? Mein Gott … als ob es keine dringenderen Probleme gäbe.

Zu Eigenschaften ist folgendes zu sagen: Qt4 hat faktisch getrennte Namensräume für Qt-Eigenschaften und C++-Methoden. Deswegen ist es möglich, dass der Getter einer Eigenschaft den selben Namen trägt wie die Eigenschaft selbst. Folgendes ist in Qt4 möglich:

1
2
3
4
5
6
7
8

class QDummy: public QObject {
    Q_OBJECT
    Q_PROPERTY(QString foo READ foo WRITE setFoo)

public slots:
    QString foo(bool some_flag=true);
    QString setFoo(const QString &foo);
};

Der Name foo bezeichnet also eine Eigenschaft und zwei Methoden. Python legt Eigenschaften und Methoden nun im selben Namensraum ab, nämlich dem der Klasse. Würde PyQt4 Qt-Eigenschaften als Python-Eigenschaften implementieren, so wäre QString foo(bool) aus Python heraus nicht erreichbar. Innerhalb einer Klasse kann eine Methode in Python nicht den gleichen Namen tragen wie eine Eigenschaft. Die Entscheidung, auf Eigenschaften zu verzichten, ist eine bewusste Entscheidung angesichts der Unterschiede zwischen Qt4-C++ und Python. Allerdings gibt es seit PyQt 4.6 bei Qt-Objekten die Möglichkeit, Eigenschaften über Schlüsselwortargumente im Konstruktor zu setzen. Auf gleichem Weg können auch Signale verbunden werden. Die gleiche Funktionalität wird auch von QObject.pyqtConfigure() zur Verfügung gestellt.

Über die Namensgebung möchte ich nicht streiten, das ist vor allem eine Sache des persönlichen Geschmacks. Ich persönlich heiße diese Entscheidung jedenfalls gut, bzw. habe keine Probleme damit, dass eine Bibliothek von PEP 8 abweicht, wenn es dafür gute Gründe gibt. PEP 8 erhebt schließlich keinen Anspruch auf die alleinige Wahrheit und Allgemeingültigkeit, sondern zeigt seine eigenen Grenze gleich am Anfang deutlich auf.

Dein eigenes Urteil zu fällen, steht Dir frei. Falls aber KDE Techbase einen einigermaßen aktuellen Stand von QtRuby wiedergibt, halte ich es für reichlich gewagt, PyQt4 im Vergleich zu QtRuby als "lächerlich" zu bezeichnen. Bei der Lektüre dieses Dokuments komme ich zu dem Schluss, dass Namensgebung und Eigenschaften das einzige sind, was QtRuby PyQt4 voraus hat. Auf beides bin ich bereits eingegangen.

Dem entgegen stehen andere Dinge, die QtRuby weniger elegant löst. call-by-reference ist in QtRuby immer noch call-by-reference mit speziellen veränderbaren Typen, während PyQt4 einfach mehrere Werte zurück gibt. Zudem sind C++-Signaturen offenbar erforderlich, um Signale nutzen zu können. Interessant zu wissen, aber im Dokument nicht erwähnt, wäre zudem noch, in wie weit implizite Typumwandlungen bei Basistypen wie QString, QDate, QTime und vor allem QVariant umgesetzt sind. Ohne solch implizite Typumwandlungen ist beispielsweise die QSettings-API relativ unschön.