Welche Programiersprache

  • Andreas:
    GENAU SO läuft das beim Recovern eines Files mit TimeBackup auch... und ich hab es auch schon (mehrfach) gebraucht, nur war der Kollege ich selbst... :wallbash:

    Auch nett:
    da ich bisher noch kein lokales GitLab einsetze und den Code nur sporadisch (und nicht alles) in meine BitBucket-Repos speichere, "ersetzt" das so ein bisschen die Versionierung... ist aber nur ein schlechter Ersatz...

    Ich werde mich jetzt mal an das GitLab setzen... :s

    LG, das Zen


  • ... Sobald du auf Libs verzichten willst/musst wird C++ weitaus komplizierter als es für Anfänger geeignete Sprachen wie Python sind.

    also ich verzichte am Arduino auf C++ und programmiere trotz Benutzung von LIBs alles in C so wie ich es mal unter DOS und Atari gelernt hatte.
    OK angefangen hatte ich mit Basic auf dem PET2001, aber wer erst mal etwas programmieren kann, der kann auch etwas Logik und Probleme klar formulieren und aufdröseln, das braucht man nämlich, die Sprache ist davon weitesgehend unabhängig, nur Python mag ich nicht und wenn eine Programmierung an Einrückungen scheitert dann ist es Müll.
    Meine Einrückungen kommen zwischen den Welten schon mal durcheinander, wieso weshalb habe ich noch nicht rausgefunden, aber beim Transport vom PC zum NAS finde ich immer wieder 0D 0D doppelt statt diese beliebte win/DOS Folge 0D 0A das macht es nicht leichter.
    Ohne Hexedit wo ich doppelte 0D Folgen rauswerfe wäre ich verloren, TABs sind auch nicht immer TABs mal /09 mal eine Folge von /32 und das ganze noch in verschiedener Länge, vieleicht benutze ich zu viele Editoren.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Einrückungen sind in egal welcher Sprache nützlich die Übersicht zu behalten.
    Wer gar keine Einrückungen verwenden will sollte sich mal an größere Projekte wagen und nach einem Jahr dann noch mal versuchen zu verstehen was man da gemacht hatte :lol:
    Siehe dazu auch https://de.wikipedia.org/wiki/Einr%C3%BCckungsstil

    Sofern eine Sprache keine Einrückung wirklich benötigt um zu funktionieren, muss man zusammengehörige Blöcke selber als solche zusammenfassen und dabei kann man eben auch Fehler machen wie zB die } am Ende zu vergessen... Inwiefern sich das also von falschen Einrückungen bei Python unterscheidet bzw als Contra-Argument zu werten wäre, ist denk ich trivial.

  • ... nur Python mag ich nicht und wenn eine Programmierung an Einrückungen scheitert dann ist es Müll.


    Ich muss zugeben, dass ich erst spät in meinem Programmiererleben Python kennenlernte (nicht erst mit Raspi) und zuerst ebensolche Antipathien gegen Pythons Art den Blockkennzeichnung hatte. Jeder Profi benutzt Einrückungen um seinen Code leserlich zu machen und dass man in Python gezwungen wird als wäre man ein Novize ist schon sehr unangenehm. Es wundert dass das der Wirth nicht in sein Pascal schon eingebaut hat um die Studenten zu gängeln :D

    Anyhow habe ich Python lieben gelernt trotz seines Einrückungsszwanges und seines nachträglichen Aufstopfens von OO Fähigkeiten in die Pythonsyntax, so dass diese nicht so einfach wie in anderen OO Sprachen zu benutzen ist. Selbst grosse Opensourceprojekte wie z.B. Openstack benutzt fast ausschliesslich Python (Siehe Z.b. hier für Gründe) und stört sich nicht an dem EInrückungsszwang. Python hat eben diverse andere Vorteile :fies:

    Zitat

    Meine Einrückungen kommen zwischen den Welten schon mal durcheinander,

    Liegt sehr sicher an den Editoren und dem Wechsel zwischen der CRLF und LF Welt. Das kann man aber fixen ;)

  • Gerade weil es in vielen Sprachen keine zwanghafte Einrückung gibt, vegetiert da draußen so viel unleserlicher Code. Wenn man mit 4 Zeilen Einrückung nicht klarkommt und das System als "Müll" klassifiziert, habe ich meine Zweifel ob jener Programmierer so viel bessere Algorithmen in anderen Sprachen entwickelt.

    Aber jeder darf gerne seine Meinung dazu haben und äußern :)

    “Don’t comment bad code - rewrite it.”

    Brian Kernighan

  • Mich verwundert die logische Schlussfolgerung aus "ich habe ein Setup bei dem ich mir wahllos Bytes in meinen Quellcode schiesse - Python ist Mist" auch. Seine eigenen Fehler und Missverstaendnisse anderen anzulasten - naja. Sollte mal jemand mit elektronischen Komponenten machen, da gibt's dann Mores vom Herrn jar.

    Man muss Python (oder jeder andere Sprache) nicht moegen. Aber ahnungslos Unsinn ueber sie zu verbreiten - faellt auf einen selbst zurueck...

  • Hallo zusammen,

    vor ein paar Monaten habe ich mir mal Goaldi [von Goal-directed evalutaion] installiert. Diese Sprache ist weitgehend mit der Syntax von Icon und Unicon kompatibel. Allerdings mit einer total bescheuerten Gängelei: Block-einleitende Klammern müssen am Ende der Zeile stehen, in der ein Ausdruck steht, der zu einem Block [Schleife, Verzweigung etc.] führt. Alles andere wird mit Fehlermeldungen bestraft.

    So muss es und nicht anders (Kernighan & Ritchie):

    Code
    while (x == y) {
       something();
       somethingelse();
    }

    Das finde ich total bescheuert, zumal die meisten Programmiersprachen, die ich kenne, da sehr liberal sind. Nicht ohne Grund kennen die besseren Editoren und IDE einen Menüpunkt, mit dem zusammengehörige Blockanfänge und Blockenden angezeigt werden.

    So (Allman)

    Code
    while (x == y)
    {
       something();
       somethingelse();
    }


    oder so (Horstmann)

    Code
    while (x == y)
    {   something();
       somethingelse();
    }

    bin ich's seit 35 Jahren gewohnt - und finde ich es übersichtlinh und sinnvoll. Da sieht man auf einen Blick, wo ein Block beginnt und endet. Die Suche nach öffnenden und schließenden Klammern entfällt. Eine Strukturanalyse ist sehr schnell abgeschlossen etc.


    Noch etwas, was meiner Meinung nach gegen eine Gängelung mit dem Einrücken spricht: Wenn ich eine Anwendung programmiere, dann lege ich schon großen Wert darauf, dass zusammengehörige Blöcke in der gleichen Spaltenposition beginnen. Wenn ich aber aus Testzwecken ein paar Variablen-Ausgaben einsetze, dann stehen die in der Regel in der ersten Spalte (gleichauf mit Funktionen und Prozeduren). Wenn eine Anwendung irgendwann fertig ist, brauche ich bloß alle solchen Ausgabe, die in Spalte 1 stehen zu entfernen, ohne dass dies Einfluss auf den sonstigen Programmlauf haben kann.

    In Python übertragen muss man solche temporären Ausgaben in vorgegebene Spalten setzen. Und später weiß man nicht mehr, ob die Ausgaben jetzt zum Programm gehören oder nur Kontrollausgaben waren. Im Zweifelsfall entfernt man später eine eigentlich benötigte Ausgabezeile.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (13. August 2016 um 15:21)

  • Ich denke, vieles von dem, was hier bisher geschrieben wurde, ist richtig. :thumbs1:

    Aber jeder Entwickler hat seinen eigenen Stil. Und der ist, je nach seiner eigenen Entwicklungsgeschichte, halt unterschiedlich.
    Und so fällt die Akzeptanz bzgl. Python auch unterschiedlich aus. ;)

    Vielleicht bin ich deswegen mit Python (ich bin bekennender Befürworter dieser Sprache!) so schnell klar gekommen und habe diesen "Einrückungszwang" nicht als solchen empfunden, weil ich quasi schon immer so geschrieben habe (Blockeinrückung usw.).

    Außerdem halte ich mich an (für mich) klare Regeln:

    • keine Tabulatoren (nur Leerzeichen, 2/3/4 je nach Tagesform, meist 3)
    • Zeilenende ist immer LF (da ich aus der Unix-Welt komme -- wenn der Kram unter Windows damit nicht klar kommt, einmal kurz im Editor aufrufen und wieder Speichern oder gleich alle Sourcen (vorher unter Linux) konvertieren.
    • Klammer immer hinter der Funktion (Weil der Code damit kompakter wird: Wenn man in großen Projekten unterwegs ist, die mit > 1000-10.000 Zeilen pro Klasse operieren, dann ist man froh, wenn man im sichtbaren Teil des Editors möglichst viel vom Code sieht
      Zum Verständnis: In den Projekten, an denen ich gearbeitet habe, ist neben dem eigentlichen "Wirkcode" oft sehr viel Tracing/Logging Code und eben auch Kommentarzeilen, Methodenbeschreibungen usw. Unter C++ kommen dann noch die #ifdef/#ifndef und #define Zeilen dazu. Da ist man froh, wenn man durch eine kompaktere Schreibweise mit nur wenig scrollen den Wirkcode halbwegs überblicken kann.
    • Klasse == File: Sieht zunächst albern aus, wenn da nur wenige Zeilen stehen, hat allerdings bei großen Projekten enorme Vorteile bzgl. der Übersichtlichkeit.
    • CamelCase-Schreibweise der Variablen / Methode/Funkionen/Klassen
    • "sprechende" Variablennamen: Ja ich weiss, das führt zu langen Zeilen und oft zu umgebrochenen Codezeilen.
      Aber das kann auch von Vorteil sein, da man dann gerade die Aufrufparameter (eingerückt) untereinander schreiben kann und sogar mit Kommentaren versorgen kann.
    • leere "else" - Zweige: (weiche Regel - mache ich auch nicht immer) Verlängert den Code etwas, aber man sieht, dass es eben _keinen_ "else"-Code gibt und er nicht etwa vergessen wurde. Außerdem nistet sich da bei mir gern Trace/Log-Code ein (falls der Ablauf da doch mal reingeht - Warum wohl?)
    • ... gibt noch mehr, aber ich höre erstmal auf... :lol:


    Und für die Sache mit den "temporären" Variablen/Parametern:
    Die beginnen bei mir immer mit "_tmp_" oder "_debug_".
    Eine einfach Suche danach stellt sicher, dass die dann ggf. wieder auskommentiert wurden (In C++ nutze ich "#ifdef test" drumherum... da ist es noch einfacher...).

    Wem das jetzt umständlich vorkommt: wenn man sich daran gewöhnt hat, ist das alles schnell getippt (in IDEs und vernünftigen Editoren kann man sich da auch Tastaturmakros bauen) und eine Code-Konvertierung von z.B. Java nach Python oder C++ läuft etwas "geschmeidiger" ...

    Grüße, das Zen


  • Einrückungen sind in egal welcher Sprache nützlich die Übersicht zu behalten.

    dagegen sagt keiner was!


    Wer gar keine Einrückungen verwenden

    auch das habe ich nirgends geschrieben, willst du es wieder mal mit purer Absicht missverstehen?

    Liegt sehr sicher an den Editoren und dem Wechsel zwischen der CRLF und LF Welt. Das kann man aber fixen ;)

    mache ich ja auch aber ob eingerückt oder nicht ändert am Kompilat in C nix und wirft keine Fehler aus!


    Gerade weil es in vielen Sprachen keine zwanghafte Einrückung gibt, vegetiert da draußen so viel unleserlicher Code. Wenn man mit 4 Zeilen Einrückung nicht klarkommt und das System als "Müll" klassifiziert, habe ich meine Zweifel ob jener Programmierer so viel bessere Algorithmen in anderen Sprachen entwickelt.

    auch das habe ich nicht geschrieben, nur wenn die Einrückung warum auch immer verloren geht, Fehler auszuwerfen zeugt in meinen Augen von keiner guten IDE oder berücksichtigt nicht die verschiedensten Editoren oder CR LF Welten die nun mal real sind!


    Mich verwundert die logische Schlussfolgerung aus "ich habe ein Setup bei dem ich mir wahllos Bytes in meinen Quellcode schiesse - Python ist Mist" auch. Seine eigenen Fehler und Missverstaendnisse anderen anzulasten - naja. Sollte mal jemand mit elektronischen Komponenten machen, da gibt's dann Mores vom Herrn jar.

    Man muss Python (oder jeder andere Sprache) nicht moegen. Aber ahnungslos Unsinn ueber sie zu verbreiten - faellt auf einen selbst zurueck...


    sach mal wer ist ahnungslos?
    Ich habe das CR LF Chaos nicht zu verantworten ich muss damit leben wenn eine "moderne" Sprache damit nicht zurecht kommt zweifel ich ob sie aus der heutigen Zeit passend entwickelt wurde!

    Klar man kann sich jeden Schrott passend schön reden, ich komme in C klar auch seit Jahren, Python nicht mal von 2 nach 3 !

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Einmal editiert, zuletzt von jar (13. August 2016 um 16:30)


  • sach mal wer ist ahnungslos?
    Ich habe das CR LF Chaos nicht zu verantworten ich muss damit leben wenn eine "moderne" Sprache damit nicht zurecht kommt zweifel ich ob sie aus der heutigen Zeit passend entwickelt wurde!

    Klar man kann sich jeden Schrott passend schön reden, ich komme in C klar auch seit Jahren, Python nicht mal von 2 nach 3 !

    Python veraendert keine Quellcode-Dateien. Das tust *du*. Insofern - ja, du bist ahnungslos. Wenn du einfach wild geschweifte Klammern in deinen C-Code streust, kommt der Compiler damit auch nicht mehr klar. Ist dann aber wohl auch kaum die Schuld von C, oder?

    ISO-Layer-8 Problem halt. Wenn du's nicht kannst, lass es sein, aber unterstell anderen nicht, *die* mit Python (oder was auch immer dir so im Leben alles nicht gefaellt) klar kommen, dass sie mit Mist arbeiten.

  • hey du hast nix verstanden, macht aber nichts, es gibt ja nicht nur schlaue Menschen, aber solche Diskusion mit Unterstellungen sind zwecklos!
    Es geht nicht darum ob ich wahllos Klammern einstreue, das tue ich nicht, es geht darum das Formatierungen verloren gehen können und das eine neue Sprache damit nicht zurecht kommt.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Also sry, jar, aber ich kann dir hier nicht mehr ganz folgen... :s


    ... es geht darum das Formatierungen verloren gehen können

    :huh:
    Warum sollte das passieren?
    Ich ahne ja, woher das kommen könnte:
    Wenn in Quellcode Tabs und Spaces fröhlich miteinander gemischt werden, braucht man sich nicht zu wundern, wenn die Source dann in einem anderen Editor (z.V. vi) ziemlich ... wirr aussieht...

    Aber sonst? Formatierungen gehen nicht einfach verloren... da hat dann einer dran gedreht...


    und das eine neue Sprache damit nicht zurecht kommt.

    Das erschließt sich mir jetzt noch weniger... :daumendreh2: :daumendreh2:


  • Also sry, jar, aber ich kann dir hier nicht mehr ganz folgen... :s

    macht nix könnte ich zeigen, mag ich aber nicht!

    Wenn dir noch nie aus CR LF -> CR CR in Dateien geworden sind dann sei glücklich, ich denke mir das nicht aus!

    Hier im Forum liest man öfter das Einrückungen verloren gegangen sind mit C & P alles Schuld der User oder unzureichender SW?

    So einfach kann man sich auch das Leben machen nur den Usern die Schuld zuschieben.

    Das Problem betrifft dann aber Python denn das verweigert, ein C-Quellcode sieht dann zwar schlecht aus ist aber kompilierbar!

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)


  • PEP8 sagt genau das man das nicht machen soll und immer Spaces nehmen soll.

    Ist aber wohl pythonspezifisch und recht unbequem.
    Manche Editoren können Tabs in Spaces wandeln und umgekehrt, das macht es aber nicht bequemer!

    Offensichtlich haben hier einige Verständnisschwierigkeiten was ich meinte,

    Python ist eine junge, moderne Programmiersprache die sich angeblich und vordringlich an Anfänger wendet, da darf es doch verwundern wenn eine verlorene Einrückung zu Fehlermeldungen führt.

    Wer dagegen spricht muss für mich unverständlich blind für Mängel eines Konzepts sein!

    Auch bei verlorenden Einrückungen kann ich ein C Programm lauffähig bekommen, den Compiler interessiert es nicht.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)


  • Ist aber wohl pythonspezifisch und recht unbequem.

    Nein, das hat was damit zu tun, was mit dem Code in Zukunft geschehen soll:
    Wenn Spaces und Tabs wild miteinander vermischt werden (und ich habe so einen Schei** schon zu oft gesehen), dann freut sich der, der den Code aus Wartungsgründen später mal übernehmen soll/muss und vor allem, wenn es um Bugfixing geht, er den ihm unbekannten Code verstehen soll...

    Wenn ein Maurer (nix gegen den Beruf (!)) ein Haus baut (aus Steinen) und alle Wände sind schief und nicht glatt, die Ziegel gucken raus und maßhaltig ist es auch nicht, könnte der jetzt sagen: Was wollt ihr: Steht doch, schützt vor Wind und Wetter und hält warm. Das stört doch nicht, das ist ein Haus!

    Mein Gott:
    Der geschriebene Code ist das Aushängeschild des Entwicklers, seine Arbeitsleistung.
    Wenn das "hingerotzt" aussieht, fragt man sich als Revisor doch: Hat der das aus Genialität gemacht oder war er froh, dass der Code so läuft und er hat sich nicht getraut, da auch nur ein Stück zu ändern, nachdem es lief.
    In vielen Fällen trifft es letztes, die Code-Genies, die ich kenne, liefern alle sauberen Code...


    Manche Editoren können Tabs in Spaces wandeln und umgekehrt, das macht es aber nicht bequemer!

    "Manche" Editoren sind dann halt unbrauchbar...
    Und doch: Das macht es zumindest bequemer, den Code erstmal so hinzustellen (formatieren), damit man ihn überhaupt mit JEDEM Editor vernünftig lesen kann.


    Offensichtlich haben hier einige Verständnisschwierigkeiten was ich meinte,

    In der Tat. :denker:


    Python ist eine junge, moderne Programmiersprache die sich angeblich und vordringlich an Anfänger wendet, da darf es doch verwundern wenn eine verlorene Einrückung zu Fehlermeldungen führt.
    Wer dagegen spricht muss für mich unverständlich blind für Mängel eines Konzepts sein!

    It's not a bug, is a feature!

    Da du offensichtlich nicht bereit bist, das zu akzeptieren, ist damit Python nicht die Sprache, mit der du arbeiten solltest.
    Nicht ist zermürbender, als mit einem Werkzeug (und eine Prog.Sprache ist nur Mittel zum Zwecke) zu arbeiten, das man nicht will!


    Auch bei verlorenden Einrückungen kann ich ein C Programm lauffähig bekommen, den Compiler interessiert es nicht.

    Thema verfehlt (ja, was soll das diskutieren wegen dem Einrücken???)
    Jede Sprache hat ihre Eigenheiten und Spezialitäten. Entweder, du lässt dich darauf ein oder du lässt es.

    (ich persönlich hege Aversionen gegen "perl" (

    • Perl is the only language that looks the same before and after RSA encryption.” (Keith Bostic)
      (Perl ist die einzige Sprache, die vor und nach einer RSA-Verschlüsselung gleich aussieht.)

    ) würde aber nicht so abfällig darüber herziehen (das haben andere gemacht und ist Legende)...

    Nun gut... ich denke, das führt zu nix...

    Jeder sollte die Sprache verwenden, die ihm liegt und mit der er ein anstehendes Problem am effektivsten bewältigen kann.

    Grüße, das Zen


  • Wenn dir noch nie aus CR LF -> CR CR in Dateien geworden sind dann sei glücklich, ich denke mir das nicht aus!

    Hier im Forum liest man öfter das Einrückungen verloren gegangen sind mit C & P alles Schuld der User oder unzureichender SW?

    Das eine hat mit dem anderen nichts zu tun.
    Wenn hier im Forum Einrückungen verschwinden liegt das am Forum, nicht an dem Zeilenumbruchzeichen.
    Schreib etwas mit Leerzeichen in einem CODE-Block in der Schnellantwort, klick dann auf Beitragsvorschau und wunder dich darüber wieso plötzlich ein Leerzeichen (am Anfang) in jeder Zeile fehlt... Wo vorher 2 Leerzeichen waren ist es nur noch 1 Leerzeichen, wo vorher 4 waren sinds nur noch 3, wo voher 6 waren sinds nur noch 5 usw. Den gleichen Effekt kann man beobachten wenn man einen Beitrag mit CODE/PHP bearbeitet und "Zum Editor" wechselt.
    Das hat also nichts mit dem User zu tun oder CR LF => zwei völlig unterschiedliche Dinge die leider von dir in ein Topf geworfen werden.

    Dir hat deets bereits die Erklärung deines CR LF Problems geschildert: Beitrag#51
    Bewusst musst *du* an der Formatierung nichts ändern sodass CR LF zu CR CR o.ä. wird, das geschieht bei Dir anscheint bei der Übertragung der Dateien, oder vielleicht sogar schon beim erstellen. An dem Problem trägt Python keine Schuld.
    Es gibt durch aus auch andere Programmiersprachen die allergisch auf falsche Einrückungen oder Platzierung von Code, reagieren. Die sind deshalb aber kein Müll.

    Einrückungen haben nicht so viel mit Zeilenumbruchzeichen zu tun. Das eine ist am Anfang das andere am Ende einer Zeile. In sofern versteh ich sowieso nicht was das eine mit dem anderen zu tun haben soll bzw wurde hier ursprünglich als Argument gegen Python die Einrückungspflicht genannt...

    Wie hier auch schon erwähnt wurde: Profis nutzen in jeder Programmiersprache Einrückungen, völlig egal ob die Sprache dies benötigt oder nicht.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!