Vor- und Nachteile diverser Script- und Programmiersprachen



  • net schrieb:

    aber da gibts ja bessere möglichkeiten z.b globale flags, spezielle rückgabewerte usw.

    Was?
    Das ist doch gerade ein Vorteil von Exceptions, dass ich eben nicht mehr auf den
    Rückgabewert prüfen muss!

    net schrieb:

    denn ein script soll immer laufen, egal wieviele fehler drin sind. mach stattdessen lieber ausgaben nach stderr oder eine debug-konsole

    Also ich will nicht, das mein Script immer läuft. Was soll das für einen Vorteil haben? -
    Egal ob jetzt 2 zeiliges Bash Script oder tausend Zeilen Python Projekt.

    Und Ausgeben nach stderr ersetzen bestimmt keine Exceptions, sondern ergänzen sie.



  • icepacker schrieb:

    Das ist doch gerade ein Vorteil von Exceptions, dass ich eben nicht mehr auf den Rückgabewert prüfen muss!

    exceptions sind für besonders schlimme fehler, wenn ein programm nicht mehr weiterlaufen kann weil richtig was kaputt ist. sie reissen das programm aus seinem gewohnten ablauf, wie eine interrupt routine o.ä. für einfache fehler z.b. wenn irgendeine aktion schief läuft, ist es doch einfacher, irgendeinen status abzufragen.

    icepacker schrieb:

    Also ich will nicht, das mein Script immer läuft. Was soll das für einen Vorteil haben?

    dann führt das script den anderen, möglicherweise korrekten, code noch aus. würde ein script bei einem fehler abbrechen wär das nicht mehr der fall.



  • Das mit dem ++ und den Leerzeichen ist doch eine klasse Idee und noch dazu sehr intuitiv anzuwenden, frag mich echt warum derzeit aktuelle Sprachen das nicht bereits anbieten. Es gibt wohl keine bessere Umsetzung für die Definition der Inkrement Operation ("Erhöhung bzw. Verringerung eines numerischen Wertes", http://de.wikipedia.org/wiki/Inkrement) für den Datentyp String. Ich wär generell dafür mal eine Sprache anzubieten, bei der man eigene, zusätzliche Operatoren entwerfen kann:

    a+``#'.-^^b * 3;
    

    Na, habt ihr erraten, was das macht? Sollte eigentlich offensichtlich sein ..

    Ach ja, ich persönlich verwende Exceptions auch nur in besonders schlimmen Fällen, wie zum Beispiel, wenn die Welt untergeht, für alles andere verwend ich klarerweise Return Codes.



  • unkreativ`` schrieb:

    Das mit dem ++ und den Leerzeichen ist doch eine klasse Idee und noch dazu sehr intuitiv anzuwenden, frag mich echt warum derzeit aktuelle Sprachen das nicht bereits anbieten. Es gibt wohl keine bessere Umsetzung für die Definition der Inkrement Operation ("Erhöhung bzw. Verringerung eines numerischen Wertes", http://de.wikipedia.org/wiki/Inkrement) für den Datentyp String. Ich wär generell dafür mal eine Sprache anzubieten, bei der man eigene, zusätzliche Operatoren entwerfen kann:

    a+``#'.-^^b * 3;
    

    Na, habt ihr erraten, was das macht? Sollte eigentlich offensichtlich sein ..

    Ach ja, ich persönlich verwende Exceptions auch nur in besonders schlimmen Fällen, wie zum Beispiel, wenn die Welt untergeht, für alles andere verwend ich klarerweise Return Codes.

    🤡 👍



  • Ich kann zu dem Thema leider nicht viel mehr als meine Meinung zu PHP einbringen, aber vielleicht hilft es ja ein wenig. 🙂

    Ich programmiere jetzt seit ca. 5 Jahren in PHP und habe das Programmieren vorher mit Pascal gelernt. Das Problem bei PHP ist ganz einfach, dass es sehr leicht dazu führen kann, dass man schlechten Code schreibt. Gerade durch die kreuz-und-quer-konvertierungen von Variablen ist imho es extrem unschön und ich versuche davon loszukommen. Wenn man das ganze noch beruflich macht und Deadlines einzuhalten hat, dann kommt man früher oder später in die Situation, dass es irgendwann 'dirty' wird (Meiner Meinung nach).

    Vielleicht macht es einige Dinge einfacher bzw. schneller zu implementieren, aber die Fehlerquote ist doch schon recht hoch.



  • Wobei PHP nun ohnehin auch nicht gerade eine Sprache ist, an der man sich beim Entwurf einer neuen Sprache orientieren sollte.



  • icepacker schrieb:

    nman schrieb:

    Neku schrieb:

    Deswegen erlaube ich ja #! als Kommentar - damit es unter Linux gewohnt verwendet werden kann 😉

    Ui, ganz schlechte Idee. 👎

    Jop echt schlechte Idee.

    @Neku: Nee genau andersrum, '#' muss als Kommentar erlaubt sein, damit man '#!' als
    Shebang benutzen kann!

    '#' ist imo sowieso das beste Kommentarzeichen für einzeilige Kommentare.

    Aber wie ich oben schon geschrieben habe ist '#' leider schon vergeben, weshalb ich das nicht als Kommentar erlauben kann.

    net schrieb:

    Neku schrieb:

    Das mit den Strings finde ich ne sehr komische Idee. Exception halte ich hier für angebracht.

    dann mach es doch so, dass ein ++ auf einen string ein leerzeichen anhängt.

    btw: exceptions sind eine blöde erfindung. gerade bei scriptsprachen nervt sowas nur denn ein script soll immer laufen, egal wieviele fehler drin sind. mach stattdessen lieber ausgaben nach stderr oder eine debug-konsole. natürlich brauchste auch ne möglichkeit zur laufzeit fehler zu erkennen bzw. zu behandeln aber da gibts ja bessere möglichkeiten z.b globale flags, spezielle rückgabewerte usw.

    ++ auf einen String? Das entzieht sich ja jeglicher Logik :p

    Exceptions sind extrem hilfreich und an diversen Stellen auch nötig. Wenn dein Script eine Funktion aufruft, die nicht existiert, dann gibt es eben eine Exception - das kann man nicht einfach so 'übergehen'. Welche Fehler schweben dir denn vor, die man nur auf stderr sehen soll und bei denen das Script aber noch fortgesetzt werden kann?

    mantiz schrieb:

    Ich kann zu dem Thema leider nicht viel mehr als meine Meinung zu PHP einbringen, aber vielleicht hilft es ja ein wenig. 🙂

    Ich programmiere jetzt seit ca. 5 Jahren in PHP und habe das Programmieren vorher mit Pascal gelernt. Das Problem bei PHP ist ganz einfach, dass es sehr leicht dazu führen kann, dass man schlechten Code schreibt. Gerade durch die kreuz-und-quer-konvertierungen von Variablen ist imho es extrem unschön und ich versuche davon loszukommen. Wenn man das ganze noch beruflich macht und Deadlines einzuhalten hat, dann kommt man früher oder später in die Situation, dass es irgendwann 'dirty' wird (Meiner Meinung nach).

    Vielleicht macht es einige Dinge einfacher bzw. schneller zu implementieren, aber die Fehlerquote ist doch schon recht hoch.

    Schlechten Code kann es in jeder Programmiersprache geben - das hängt vor allem von der Person vor dem Monitor ab.
    In PHP kann man kreuz und quer konvertieren, da hast du recht. Manche der Konvertierungen sind gut, andere weniger.

    Besser stelle ich mir das z.B. folgendermaßen vor:

    implizite Konvertierungen:
    Number -> String
    Boolean -> String
    Null -> String (?)
    Array -> Boolean (false, wenn leer)
    String -> Boolean (false, wenn leer)
    Number -> Boolean (false, wenn 0)
    Null -> Boolean (immer false)

    zusätzliche explizite Konvertierungen:
    String -> Number
    * -> Null

    Wer die Liste fortsetzen kann - nur zu 😉

    Über die Konvertierung "Null -> String" müsste man nachdenken, denn immer wenn ich mit LUA programmiere stoße ich auf das Problem, dass ich umständliche ALle Variablen, die ich (z.B: zum Debuggen) ausgeben möchte, auf Null testen muss: "if bla == nil then bla = 'nil'; end".

    "String -> Boolean" ist jetzt leider nicht mehr so intuitiv wie "String -> Number", da man bei der zweiten Konvertierung den Inhalt des Strings in eine Zahl konvertiert, bei der ersten aber testet man nur, ob der String leer ist.

    So nebenbei: Ist der '+'-Operator als String-Konkatenator ausreichend, oder sollte man diesen Operator lieber den Zahlen vorbehalten?



  • Neku schrieb:

    ++ auf einen String? Das entzieht sich ja jeglicher Logik :p

    du hast einfach keine phantasie. anderer vorschalg: man könnte mit ++ jedes zeichen eins strings hochzählen, also wenn worher "VMS" dann nachher "WNT"...

    Neku schrieb:

    Exceptions sind extrem hilfreich und an diversen Stellen auch nötig. Wenn dein Script eine Funktion aufruft, die nicht existiert, dann gibt es eben eine Exception - das kann man nicht einfach so 'übergehen'. Welche Fehler schweben dir denn vor, die man nur auf stderr sehen soll und bei denen das Script aber noch fortgesetzt werden kann?

    alle fehler, selbst division durch 0 oder sowas. natürlich, das ergebnis ist falsch aber das script läuft weiter. also ich finde sowas gut.



  • net schrieb:

    Neku schrieb:

    Exceptions sind extrem hilfreich und an diversen Stellen auch nötig. Wenn dein Script eine Funktion aufruft, die nicht existiert, dann gibt es eben eine Exception - das kann man nicht einfach so 'übergehen'. Welche Fehler schweben dir denn vor, die man nur auf stderr sehen soll und bei denen das Script aber noch fortgesetzt werden kann?

    alle fehler, selbst division durch 0 oder sowas. natürlich, das ergebnis ist falsch aber das script läuft weiter. also ich finde sowas gut.

    Das Ergebnis einer Division durch 0 ist aber undefiniert, folglich kann man auch nicht damit weiterrechnen. Wer unbedingt eine Division durch 0 erlauben möchte (würg!) soll die entsprechende Zahlenklasse ändern :p



  • Neku schrieb:

    Das Ergebnis einer Division durch 0 ist aber undefiniert, folglich kann man auch nicht damit weiterrechnen. Wer unbedingt eine Division durch 0 erlauben möchte (würg!) soll die entsprechende Zahlenklasse ändern :p

    kann ja undefiniert bleiben. wird so'ne rechnung, bei der durch 0 geteilt wird, einer variablen zugewiesen, dann bekommt die den status "not a number". alles was jetzt mit dieser variablen weiterrechnen will ebenfalls. aber andere anweisungen, die nix damit zu tun haben, würden davon nicht betroffen sein. das ist viel benutzerfreundlicher als wenn dein script im fehlerfall mit "unhandled exception at ...." abbrechen würde.



  • net schrieb:

    Neku schrieb:

    Das Ergebnis einer Division durch 0 ist aber undefiniert, folglich kann man auch nicht damit weiterrechnen. Wer unbedingt eine Division durch 0 erlauben möchte (würg!) soll die entsprechende Zahlenklasse ändern :p

    kann ja undefiniert bleiben. wird so'ne rechnung, bei der durch 0 geteilt wird, einer variablen zugewiesen, dann bekommt die den status "not a number". alles was jetzt mit dieser variablen weiterrechnen will ebenfalls. aber andere anweisungen, die nix damit zu tun haben, würden davon nicht betroffen sein. das ist viel benutzerfreundlicher als wenn dein script im fehlerfall mit "unhandled exception at ...." abbrechen würde.

    Darum kann man Exceptions ja auch abfangen! Und wer sich eine Division durch 0 programmiert hat eh schlechten/fehlerhaften Code geschrieben.



  • Neku schrieb:

    Aber wie ich oben schon geschrieben habe ist '#' leider schon vergeben, weshalb ich das nicht als Kommentar erlauben kann.

    Dann lass den Blödsinn mit den She-Bang-Kommentaren ganz weg und rechne nicht damit, dass Unixer sehr begeistert sein werden. Wobei eh fraglich ist, ob die sich Deine Sprache ansehen werden, wenn sie nicht OpenSource ist, wenn es soviele gute OpenSource-Alternativen gibt.



  • Neku schrieb:

    Darum kann man Exceptions ja auch abfangen!

    ja - kann, aber nicht muss. du kannst exceptions ja einbauen aber wenn ein script die nicht abfängt sollte es trotzdem freundlich reagieren.

    Neku schrieb:

    Und wer sich eine Division durch 0 programmiert hat eh schlechten/fehlerhaften Code geschrieben.

    ...und ich finde es doof, wenn sowas mit abbrechen des scripts bestraft werden würde. meiner meinung nach gehört zu einer guten scriptsprache, dass sie so tolerant wie möglich mit fehlern umgehen kann und versucht das beste daraus zu machen.



  • Hm, demnach muss ja der Internet Explorer und HTML ein feuchter Traum für dich sein. So wie XHTML und Alternativbrowser ein schrecklicher Albtraum für dich sein müssen...



  • net schrieb:

    ...und ich finde es doof, wenn sowas mit abbrechen des scripts bestraft werden würde. meiner meinung nach gehört zu einer guten scriptsprache, dass sie so tolerant wie möglich mit fehlern umgehen kann und versucht das beste daraus zu machen.

    Das ist nicht die Aufgabe der Sprache sondern des Programmierers.



  • Wobei PHP nun ohnehin auch nicht gerade eine Sprache ist, an der man sich beim Entwurf einer neuen Sprache orientieren sollte.

    Da muss ich dir recht geben.

    Deine Vorschläge für fehlende Typisierung und das Weglassen der Deklaration halt ich für schwachsinn... Das wäre schonmal der erste grund, weshalb ich mit deiner Sprache nicht programmieren würde.

    Konvertierungen der art:

    Array -> Boolean (false, wenn leer)
    Zahlenwert -> Array
    string -> Array (zumal string ja auch nen "Array" ist)

    usw würde ich auch für schwachsinnig finden...

    Dein Projekt finde ich aber in Punkto Erfahrung usw. sehr gut. Zwar wirst du auf nicht viel Reaktion treffen, wenn du es nicht Opensource machen willst - und selbst dann wird es sehr unwahrscheinlich sein, dass du damit Geld machen wirst... Es gibt einfach schon zu viel gute Alternativen.

    So das war mal ein paar meiner Gedanken dazu



  • nman schrieb:

    Neku schrieb:

    Aber wie ich oben schon geschrieben habe ist '#' leider schon vergeben, weshalb ich das nicht als Kommentar erlauben kann.

    Dann lass den Blödsinn mit den She-Bang-Kommentaren ganz weg und rechne nicht damit, dass Unixer sehr begeistert sein werden. Wobei eh fraglich ist, ob die sich Deine Sprache ansehen werden, wenn sie nicht OpenSource ist, wenn es soviele gute OpenSource-Alternativen gibt.

    Gib mir doch bitte eine Alternative. Soll ich jetzt aus jeder Programmiersprache die Kommentar-Zeichen übernehmen, damit ich keinem auf die Füße trete? Das Rautezeichen ist das ideale Zeichen für Präprozessor-Anweisungen. Alternativ kann ich ja auch #! nur in der ersten Zeile erlauben.

    net schrieb:

    Neku schrieb:

    Darum kann man Exceptions ja auch abfangen!

    ja - kann, aber nicht muss. du kannst exceptions ja einbauen aber wenn ein script die nicht abfängt sollte es trotzdem freundlich reagieren.

    Neku schrieb:

    Und wer sich eine Division durch 0 programmiert hat eh schlechten/fehlerhaften Code geschrieben.

    ...und ich finde es doof, wenn sowas mit abbrechen des scripts bestraft werden würde. meiner meinung nach gehört zu einer guten scriptsprache, dass sie so tolerant wie möglich mit fehlern umgehen kann und versucht das beste daraus zu machen.

    Wenn das Script einen Fehler enthält, der eine Exception erfordert, dann gibt es keinen Grund diesen Fehler zu übergehen. Ansonsten wäre es ja kein Fehler.
    Fehler wie eine Division durch 0 zu ignorieren fördert lediglich schlampige Programmierung und senkt die Qualität des Programms.

    Lyrix schrieb:

    Deine Vorschläge für fehlende Typisierung und das Weglassen der Deklaration halt ich für schwachsinn... Das wäre schonmal der erste grund, weshalb ich mit deiner Sprache nicht programmieren würde.

    Konvertierungen der art:

    Array -> Boolean (false, wenn leer)
    Zahlenwert -> Array
    string -> Array (zumal string ja auch nen "Array" ist)

    usw würde ich auch für schwachsinnig finden...

    Es soll in erster Linie eine Scriptsprache werden, welche es ermöglicht, die verschiedensten Aufgaben möglichst einfach zu realisieren. Wenn ich beispielsweise in C++ programmiere, dann ist die strenge Typisierung zu einem großen Teil dafür verwantwortlich, dass ich zur Realisierung eines Programms wesentlich länger brauche, als in PHP, wo es genau umgekehrt ist. Ich programmiere sowohl in C++ als auch in PHP und LUA inzwischen recht sauber und habe überall ungefähr mit der gleichen Anzahl und Häufigkeit an Fehlern zu kämpfen.
    Von deinen aufgelisteten Konvertierungen würde ich, wie schon geschrieben, höchstens die erste in betracht ziehen, da die anderen schlicht unnötig sind. Ich halte die erste Konvertierung für gut, höre aber trotzdem gerne gute Argumente, welche dagegen sprechen.

    Lyrix schrieb:

    Dein Projekt finde ich aber in Punkto Erfahrung usw. sehr gut. Zwar wirst du auf nicht viel Reaktion treffen, wenn du es nicht Opensource machen willst - und selbst dann wird es sehr unwahrscheinlich sein, dass du damit Geld machen wirst... Es gibt einfach schon zu viel gute Alternativen.

    Vielleicht liegt es ja auch nur daran, dass ich von Natur aus äußerst misstrauisch gegenüber allem und jedem bin 🙄. Sollte ich eine gute Grundlage geschaffen haben und positive Feedbacks erhalten, dann würde ich schon eher in Erwägung ziehen, zu Open Source zu wechseln. Ich habe es ja nicht verbannt 😉


Anmelden zum Antworten