wer programmiert eigentlich noch Konsolenanwendungen


  • Mod

    Anfänger_2 schrieb:

    Wie würdest du die Ausgabe lösen, wenn du einen BubbleSort Algorithmus schreiben sollst (der Logikteil) und dann jeden Schritt des Algorithmus auf der Konsole ausgeben sollst.

    Schlechtes Beispiel, Wenn die Anforderung ist, eine Visualisierung von irgendetwas zu schreiben, dann wird da auch irgendwo konkreter Visualisierungscode drin sein.



  • Mach auch noch in Konsole.
    Wenns q+d sein soll oder es nicht jeder Vollpfosten bdienen können soll.



  • Anfänger_2 schrieb:

    Okay, einfache Frage.

    Wie würdest du die Ausgabe lösen, wenn du einen BubbleSort Algorithmus schreiben sollst (der Logikteil) und dann jeden Schritt des Algorithmus auf der Konsole ausgeben sollst.

    Dann hast du ein Visualisierungsobjekt dem du in den jeweiligen Schritten des Algorithmus die jeweiligen Daten uebergibst und der macht dann damit seine Black Magic. Ob er es in OpenGL plottet oder einfach nur in eine Textdatei schreibt bleibt ihm ueberlassen.

    Wo packst du deine cout Sachen hin, oder besser, printf wenn es in C nicht objektorientiert sein soll?

    Man kann auch ohne OOP abstrahieren.



  • Nur ist es nicht mehr ganz so trivial bei langlaufenden Aktionen wie z.B. der Schach-KI die 30 Sekunden rechnet. In der Console kein Problem, eine blockierende GUI will aber niemand.
    Also startet die GUI-Variante einen Thread und stößt die Berechnung an. Dazu muss die langlaufende Methode aber wenigstens Statusupdates per Event feuern und regelmäßig prüfen ob sie sich per Kommando von außen beenden soll. Eben per Objekt das man zusätzlich übergibt und diese Funktionalität anbietet.

    Alles kein Hexenwerk. Aber man muss ein paar Kleinigkeiten berücksichtigen, weil sich eventbasierte GUI-Anwendungen anders verhalten als Consoleprogramme oder rein schleifengesteuerte OpenGL-Programme.

    Außerdem wird hier der Aufwand für eine gute GUI unterschätzt. Die klatscht man nicht mal eben dran, wenn sie nach mehr als Win95 aussehen soll und eine gute Bedienbarkeit bietet. Nö, ich mag GUI-Programmierung auch nicht, aber sie ist nicht die reine Nebensächligkeit, als die sie gerne dargestellt wird.



  • µ schrieb:

    Außerdem wird hier der Aufwand für eine gute GUI unterschätzt. Die klatscht man nicht mal eben dran, wenn sie nach mehr als Win95 aussehen soll und eine gute Bedienbarkeit bietet. Nö, ich mag GUI-Programmierung auch nicht, aber sie ist nicht die reine Nebensächligkeit, als die sie gerne dargestellt wird.

    GUIs zu implementieren sind absolut trivial.
    Der Aufwand ist das GUI Design.



  • Shade Of Mine schrieb:

    GUIs zu implementieren sind absolut trivial.
    Der Aufwand ist das GUI Design.

    Hör doch auf Blech zu reden.
    GUIs sind nichts hochkomplexes aber sie pauschal als absolut trivial zu bezeichnen ist Unsinn.



  • Es ist immer gewisser Aufwand, eine GUI hinzubekommen, die nicht nur aus Standardcontrols besteht. Und dann muss es nicht mal langweilig sein. Was ich überhaupt nicht mag, sind Standardsachen. Wenn ich zu einem Projekt noch zusätzlich irgendein Fenster zusammenbauen muss, um zig Parameter einzustellen, finde ich das natürlich einfach nur lästig. Aber wenn man eine komplexere Oberfläche braucht, z.B. um Daten zu visualisieren, und das dann auch so aufbaut, dass es flexibel und performant ist usw., dann kanns durchaus auch Spass machen.
    Und ja, man muss manchmal auch den Kern anpassen, damit er der GUI passt, das lässt sich leider nicht immer vermeiden. Trotzdem muss man das so machen, dass es flexibel bleibt und immer noch "Sinn macht", und nicht damit man gleich auf den ersten Blick erkennt, diese Extrafunktionalität ist jetzt nur in die API aufgenommen worden, damit man in dem einen Fenster da noch was sortieren kann.



  • GUIs sind so wahnsinnig komplex, dass man die meisten GUI Anwendungen zusammenklicken kann.



  • Kein ernst zunehmender Programmierer klickt die GUI zusammen. Das machen nur Anfänger. Oder mal kurz für Tools die unter einer Woche in der Entwicklung benötigen.



  • Shade Of Mine schrieb:

    µ schrieb:

    Außerdem wird hier der Aufwand für eine gute GUI unterschätzt. Die klatscht man nicht mal eben dran, wenn sie nach mehr als Win95 aussehen soll und eine gute Bedienbarkeit bietet. Nö, ich mag GUI-Programmierung auch nicht, aber sie ist nicht die reine Nebensächligkeit, als die sie gerne dargestellt wird.

    GUIs zu implementieren sind absolut trivial.
    Der Aufwand ist das GUI Design.

    Dann schreib mal eine ohne Verwendung eines GUI Toolkit.



  • Was diskutiert ihr hier eigentlich?

    Der Anwender wünscht Benutzerkomfort mit Visualisierung, also GUI-Anwendungen.
    Frameworks und APIs stellen für GUI-Anwendungen hervorragende Hilfen für die Realisierung bereit.
    Erforderliche Berechnungen erfolgen am besten getrennt von den GUI-Teilen in eigenständigen
    Funktionen oder Klassen.

    Mir sind Konsolenanwendungen seit langem ein Graus geworden. Auch für kleine Testprogramme und
    zum Testen aufwendiger Algorithmen wähle ich immer eine GUI, die schnell zusammengeklickt ist.



  • Die meisten Unit-Tests sind Consolenanwendungen.



  • knivil schrieb:

    Die meisten Unit-Tests sind Consolenanwendungen.

    Bei Anwendungen mit dem Ziel einer Veröffentlichung oder eines Verkaufs bin ich mir da nicht sicher. Bleibt aber jedem selbst überlassen, wie er Unit-Tests macht.



  • berniebutt schrieb:

    knivil schrieb:

    Die meisten Unit-Tests sind Consolenanwendungen.

    Bei Anwendungen mit dem Ziel einer Veröffentlichung oder eines Verkaufs bin ich mir da nicht sicher. Bleibt aber jedem selbst überlassen, wie er Unit-Tests macht.

    Nix für ungut, aber praktisch alle Unit Test Frameworks geben in der Konsole aus. Da gibt es nichts zu diskutieren, das ist einfach ein Fakt.



  • @berniebutt
    z.B. alles was sinnvoll scriptbar sein soll, sollte bitte eine Konsolenanwendung sein. Das wird dann oft übersehen, mit dem Ergebnis dass Tolles Tool X (tm) eben nicht skriptbar ist. Was dann dazu führt dass Genervter Mitarbeiter Y (tm) genervt bleibt, weil er weiterhin alles mit Hand machen muss.

    => Das ganze "alles muss GUI" ist eine Seuche.



  • Nix für ungut, aber praktisch alle Unit Test Frameworks geben in der Konsole aus.

    Ja, aber grad der Stub für die EXE und die Ausgaben werden oft vom Unitest-Frameworks "kontrolliert". Man koennte also nur durch Änderung des Frameworks statt ner Konsolen Anwendung eine Klicki buntu Anwendung mit Log-Konsole... err Fenster machen.
    Ob Sinvoll oder nicht sei dahingestellt ^^
    Aber spaetestens wenn die Tests in ner ordentlichen Umgebung laufen, intressieren nur File logs und Rueckgabewerte ... da waer ne "aufhübschung" der GUI echt fehl am platz ^^ Zumindest in den Bereichen die ich kenne ... Aber mittlerweile gibts ja alles ^^

    Ciao ...



  • Auf der Arbeit schreibe ich fast nur Software ohne GUI.
    Und jenachdem, für was ich andere Software gerade benutze, bin ich froh wenn sie ein gutes CLI hat. Automatisieren geht dann oft wesentlich einfacher als wenn ich AutoHotkey-Scripts schreiben muss. 😉
    Bei anderen Sachen freue ich mich über hübsches Klickibunti.


Anmelden zum Antworten