GUI-Programmieren lernen (Database)

ABC schrieb:
Aber wenn mir einer Flutter und Dart empfiehlt, fällt es mir schwer noch ernst zu bleiben.
Soso, du willst GUI-Programmierung also lernen (bist offensichtlich also nicht sonderlich erfahren), kannst bei dem Vorschlag aber nicht ernst bleiben.
Wieso genau? Wie passt das zusammen?

Dass bei einer Datenbank-App Python zu langsam sein soll, spricht übrigens dafür, dass du SQL (falls es keine No-SQL-DB ist) bzw Datenbankdesign lernen solltest. Python ist hier definitiv nicht dein Problem.
 
  • Gefällt mir
Reaktionen: IDontWantAName
pseudopseudonym schrieb:
nicht ernst bleiben.
Ich denke, das ist eine (vielleicht etwas zu stark formulierte) Umschreibung dafür, dass er diese Lösung nicht mag. Das ist sein gutes Recht.

Es gibt bei seiner Frage ja nun wirklich kein absolutes "richtig" oder "falsch". Was ist so schwer daran, seine Prämisse einfach mal zu akzeptieren?

Ich warte nur noch darauf, dass man in der Fußgängerzone von Uniformierten angesprochen und befragt wird, wenn man nicht die SED-Einheitsbrille trägt, mit der fast jeder herum läuft, um sich vor einer eigenen Entscheidung zu drücken.
 
Zuletzt bearbeitet:
Hardware-Fan schrieb:
Akzeptiert das doch einfach mal! Das Ergebnis muss ihm hinterher auch gefallen, und mit den begrenzten Möglichkeiten anderer Lösungen muss er hinterher leben können und wollen.
Welche „begrenzten Möglichkeiten“? Die von Lösungen aus dem letzten Jahrtausend? Ja stimmt, die haben durchaus begrenzte Möglichkeiten. Und die Sinnigkeit, sich derart überholte Paradigmen heute noch zum Einstieg anzueignen darf durchaus in Frage gestellt werden.
 
SheepShaver schrieb:
Die von Lösungen aus dem letzten Jahrtausend?

Genau der Quatsch, den ich meinte. Manche sehen nur noch "die eine" SED-Einheitstechnik, mit der ALLE ihre Software zu schreiben haben. Anderenfalls sind sie höchst verdächtig.

Was der TE möchte, spielt schon mal gar keine Rolle. :rolleyes:

Vielleicht hat er gar keine 15.000 PCs, auf die er alle 7 Tage deployen "muss", und deshalb fällt dieses "Ding der Unmöglichkeit" schon mal weg? Nur so 'ne Idee.

Nebenbei gibt es für die ach-so-veralteten "Lösungen aus dem letzten Jahrtausend", die Du nicht beherrschst, immer noch haufenweise Stellenanzeigen. Die Unternehmen haben sie "einfach so" veröffentlicht, ohne dich zu fragen. Ganz schön frech, die kleinen Racker. 😀
 
Zuletzt bearbeitet:
Hardware-Fan schrieb:
Ich denke, das ist eine (vielleicht etwas zu stark formulierte) Umschreibung dafür, dass er diese Lösung nicht mag.
Nee, so schlecht kann man sich gar nicht ausdrücken. Zwischen "iPhones mag ich nicht" und "iPhone-NUTZER kann ich nicht ernst nehmen" besteht z. B. auch ein riesiger Unterschied.
 
Hardware-Fan schrieb:
Nebenbei gibt es für die ach-so-veralteten "Lösungen aus dem letzten Jahrtausend", die Du nicht beherrschst, immer noch haufenweise Stellenanzeigen. Die Unternehmen haben sie "einfach so" veröffentlicht, ohne dich zu fragen. Ganz schön frech, die kleinen Racker. 😀
Wo habe ich impliziert, dass ich diese Methoden nicht beherrsche? :) Ein grosser Bestandteil meiner Diplomarbeit war damals vor laaanger laaanger Zeit, eine Industrieanlagen-Software in C++/Qt.
Sowas hat sicherlich auch heute noch eine Nische und Jobangebote wird es dafuer sicherlich geben. Es gibt auch noch Jobangebote fuer COBOL-Entwickler.

Fuer eine simple Anwendung wie oben beschrieben waere sinnvoller und hier bereits zig mal vorgeschlagen:
  • Eine Webanwendung (React, Vue, Vite, Svelte etc.)
  • Wenn es nativ laufen muss: Flutter, Iced, Qt Quick/QML

Das sind absolut nachvollziehbare Vorschlaege. Diese direkt abzuschmettern oder gar ins Laecherliche zu ziehen ist ganz schlechter Stil.
 
  • Gefällt mir
Reaktionen: pseudopseudonym
Hardware-Fan schrieb:
würde ich mir C++ heutzutage nicht mehr antun.
Modernes C++ (ab C++17/20) ist ziemlich cool. Wenn man eine GUI baut ist das verwendete Framework aber sowieso viel relevanter als die Sprache.
 
Modernes C++ vereinfacht vieles, wobei man trotzdem wissen muss was man tut und prinzipiell das Speichermangement verstanden haben sollte.

Ich würde C/C++ keinem Anfänger empfehlen, wobei hier ja auch noch andere Sachen wie GUI, Datenbank-Abfragen hinzukommen. Ich glaube hier wird schnell eine Überforderung aufkommen.
Und Latex-Kenntnisse helfen hier nun wirklich nicht.

Ich finde hier C# zusammen mit AvaloniaUI oder auch Uno Platform gut. Hiermit kann man moderne, platformunabhängige Desktop-Anwendungen schaffen.
NET bietet hier auch viele gute Frameworks zur Interaktion mit Datenbanken etc.
Die Lernkurve ist auch nicht zu steil und Speichermanagement ist einfacher.

Als IDE bietet sich hier unter Linux JetBrains Rider an (für privat mittlerweile kostenlos) oder unter Windows Visual Studio (privat hier die Community Edition) an.

Wobei mir wirklich nicht erschließt was Bazaar sein soll und ein "hohes Risikiko" von jetbrains rider. Das einzige was ich mit Bazaar verbinde, ist der Paket-Manager von Bazzite Linux, aber es war ja von Debian die Rede.
 
Je nachdem was das programm machen soll, hast du unterschiedliche Auswahlmöglichkeiten:

Java ist durch die JDK oder JRE Betriebsystemunabhängig. Da hast du Swing. Mit dem IDE Eclipse und dem WindowBuilder könntest etwas machen.

Bei Benutzeroberflächen ist man schnell auch bei sachen wie HTML, javaScript, auch wenn es keine sache wie qt oder Swing bei java ist. Bei HTML und JavaScript hättest du deine Benutzeroberfläche gleich im Browser. An dieser stelle Fragt sich wieder, worum es geht. Denn du könntest auch Spring oder Spring Boot benutzen. beides brauchen das JDK (serverseitig). Du könntest hier als Backend auch PHP verwenden.
 
Tronby schrieb:
Java ist betriebsystemunabhängig. Da hast du Swing.
Swing bei java

Die Gleichsetzung Java GUI = Swing ist veraltet. Heute nimmt man (vor allem bei Neuentwicklungen) JavaFX, was man als Komplettpaket (JDK / JRE plus JavaFX) bei verschiedenen Anbietern wie Bellsoft bekommt (als Package „Full JDK“ oder „Full JRE“ wählen). Mit dem SceneBuilder kann man schnell GUIs erstellen.
 
Zuletzt bearbeitet:
Bei aller Begeisterung für all diese "modernen" Tools scheint sich niemand Gedanken über Sicherheit und Wartbarkeit zu machen. Für die private Nutzung mag es ja keine Rolle spielen, aber wenn ich eine Anwendung für einen Kunden entwickele, dann gehört das meiner Meinung nach zu meinen ersten Pflichten diese Dinge zu gewährleisten. In diesem Kontext Bibliotheken oder ganze Frameworks zu verwenden die man nicht im geringsten überblicken kann halte ich für mindestens fahrlässig, wenn nicht gar verantwortungslos.

Mal ein ganz konkretes Beispiel was ich meine, ein zwar sehr krasses aber immerhin ganz reales Beispiel: Der Skandal um die "XZ Utilities", wo mit grosser krimineller Energie in die Open Source Kompressionsbibliothek eine SSH-Backdoor eingebaut wurde, die es erlaubte vollen Zugriff auf ein Linux-System zu bekommen wenn diese Bibliothek benutzt wurde. (Und die nur aufflog weil der Entwickler so frech war, ungeniert die volle CPU-Power für seine Zwecke zu nutzen und nicht unauffällig unter dem Radar zu agieren)

Aber selbst einfache Dinge, wie zB Fehlerbehebung in Bibliotheken ist ein Thema. Es gibt Beispiele genug dass Leute die über die offizelle Möglichkeiten Bugs gemeldet haben ignoriert oder gar gesperrt werden weil der Entwickler sich persönlich angegriffen fühlt.

Was jetzt zB an einem Lazarus so sehr aus dem "letzen Jahrhundert" sein soll, wie hier schon geschrieben wurde erschliesst sich mir nicht. Denn es macht grundsätzlich genau das was auch der angesprochene SceneBuilder für JavaFX macht.

Ich habe zB eine Anwaltskanzlei als Kunden, seit mehr als 20 Jahren. Ich werde die ganz sicher nicht einer wie oben beschriebenen Gefahr aussetzen wenn ich das mit der Auswahl meiner Entwicklungswerkzeuge verhindern kann. Das ist einer der Gründe warum ich lieber was weniger "modernes" nehme, alse dem Zeitgeist hinterherzu laufen. Denn als gewerblicher Anbieter bin ich unter Umständen für Schaden verantwortlich der dann entsteht.
 
@Merlin352 GUI/Frontend war immer schon sehr stark mit Hypes (DevOps auch, nicht ganz so schlimm allerdings). Äußerungen zu sowas sollte man daher mit "A grain of salt" nehmen bzw. nicht 100% ernst.
Ich mache schon eine Weile kein FullStack mehr, aber nachdem ich neben der offiziellen Doku von Elm auch 3 Artikel gelesen habe sah mir das schwer nach "Eine MVC Variante... aber mit einer funktionalen Programmiersprache" aus.

C++ ist auch schon lange tot angeblich und veraltet und überhaupt ganz schlecht... und wird trotzdem jedes Jahr mehr verwendet. Im Internet benutzen auch alle Linux zum entwickeln und Windows ist die Vollkatastrophe. Die Realitäten jenseits von Foren, Reddit und Youtube sieht gerne mal deutlich anders aus.

Erst letztens in meinem Umfeld mitbekommen, wo ein großes Greenfield Projekt mit Avalonia angefangen wurde... und dann nach über einem Jahr gestoppt werden musste und nun mit einer dieser langweiligen Technologien neu ausgerollt wird.

Hier auch noch zwei Beispiele über die ich letztens gestolpert bin: Link (OP und der verlinkte Beitrag; Bazel ist die coole neue Technologie und CMake die alte langweilige). Auf innovative Technologien pusht man tendenziell, wenn man das gerne in seinem Lebenslauf stehen haben will oder weil man noch eher Junior ist und das nicht so gut überblicken kann oder weil man GUI/Frontend Mensch ist und es daher Teil der DNA ist ;P. Wenn ein Projekt erfolgreich sein soll, dann pusht man tendenziell auf langweilige, veraltete Technologien (aka Technologien, zu denen man sehr viele Infos findet, wo alle Ecken und Kanten weggearbeitet wurden oder gut bekannt sind, "battle tested" technologien).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Merlin352 und Hardware-Fan
Merlin352 schrieb:
Was jetzt zB an einem Lazarus so sehr aus dem "letzen Jahrhundert" sein soll,
Die Leute, die sowas schreiben, meinen damit hauptsächlich die Optik, um die viel zu viel Hype gemacht wird.
Gute oder schlechte Oberflächen kann man mit jeder Technologie erstellen, und die Anwender wollen damit arbeiten, nicht spielen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Merlin352
@Hardware-Fan Da stimme ich dir zu.

Wobei bei einem so flexiblen Tool wie Lazarus oder auch Delphi die Optik auf der einen Seite eine Frage des verwendeten Widgetssets ist und auf der anderen Seite der benutzten Grafiken. Man muss sich natürlich damit auseinandersetzen und auch Ideen und Arbeit reinstecken.

Ich hab mir zb für Lazarus eigene Buttons mit Grafiken vom Crystal Project gebaut, das sieht nun sicher nicht "alt" aus. Aber heute wollen ja die meistens alles fertig aus der Konservendose.
 
Nichts für Ungut. Ich bin jetzt auch schon 20 Jahre in der Softwareentwicklung dabei und hab schon so ziemlich alles durch inkl. C/C++, Java, alle üblichen Web-Technologiestacks, Go, Rust etc.
Bin mittlerweile zwar weniger „hands-on“ und mehr mit People-Management beschäftigt, aber sicherlich kann ich beurteilen, was sinnvoll ist und was nicht.
Zudem halte ich es für ein ganz ganz schwaches Argument, dass moderne Technologiestacks nur von jungen unerfahrenen Entwicklern gehyped werden und das „altbewährte“ so viel besser ist.
Solche Leute habe ich in meiner Laufbahn schon zu genüge zu Gesicht bekommen und üblicherweise sind das dann ganz einfach engstirnige Primadonnas, die sich zu schade dafür waren, nach 20 Jahren C# noch was Neues zu lernen.
Auch das Security-Argument zieht nicht. Wir nutzen hippe Web-Techstacks, Rust und Go. Und das, obwohl Sicherheit unser Verkaufsargument ist.
Am Ende entscheiden die Audits und Pentests darüber, wie sicher eine Software ist.

Ach so, wer Elm mit MVC gleichsetzt, der hat sich mit der Thematik ganz offensichtlich überhaupt nicht auseinandergesetzt.
 
  • Gefällt mir
Reaktionen: pseudopseudonym und JumpingCat
Einige der Claims von Elm lassen es mehr wie ein Kuriosum wirken als wie eine coole neue Technologie.

  • "Enforced Semantic Versioning", aber eine ganz eigene, eingeschränkte Interpretation des Begriffes.
  • "No Runtime Exceptions", gemeint ist "One of the guarantees of Elm is that you will not see runtime errors in practice. This is partly because Elm treats errors as data. Rather than crashing, we model the possibility of failure explicitly with custom types." Okay, also 1:1 was Haskell seit 35 Jahren macht und was auch alle anderen Programmiersprachen seit 20 Jahren erlauben.
  • "Fearless refactoring" durch ein besonders cooles testing framework? Nein, "The compiler guides you", ja cool, endlich kann ich mich von compiler fehler zu compiler fehler hangeln, ein Träumchen, endlich geht das mal.
Passend dazu auf HN: https://news.ycombinator.com/item?id=43069475 und generell ist das Projekt/git repos seit ca. 5 Jahren komplett tot. Keine Ahnung, wer überhaupt jemals auf so einen weirden Zug aufgesprungen ist.

Da bin ich nicht so schrecklich zuversichtlich, dass die "Elm Architecture" im starken Kontrast dazu ein Leuchtfeuer moderner Ingenieurskunst ist und bin noch eher geneigt davon auszugehen, dass mein Eindruck dazu schon ganz gut war.

Aber ich lasse mich auch vom Gegenteil überzeugen wenn ich im Unrecht bin. Vielleicht kann ja jemand anhand des Beispieles aus der Iced Readme den revolutionären Charakter erklären. Denn ich sehe ihn da gerade nicht:
Code:
impl Counter {
    pub fn view(&self) -> Column<Message> {
        column![
            button("+").on_press(Message::Increment),
        ]
    }
}

impl Counter {
    pub fn update(&mut self, message: Message) {
        match message {
            Message::Increment => {
                self.value += 1;
            }
        }
    }
}
 
Zuletzt bearbeitet:
Manchmal ist es gut ganz genau zu lesen :

Wir nutzen hippe Web-Techstacks, Rust und Go. Und das, obwohl Sicherheit unser Verkaufsargument ist.

Ich denke da kann sich jeder selbst seine Gedanken zu machen.

Also Hipp vor Sicherheit. Und die Audits und Pentests hätten dir bei dem von mir als Beispiel angeführten kriminellen Umtrieben rund um die XZ Utilities herzlich wenig genützt. Auch 20 Jahre Erfahrung führen nun mal nicht zwangsläufig zu den richtigen Erkenntnissen.
 
  • Gefällt mir
Reaktionen: BeBur
Merlin352 schrieb:
Bei aller Begeisterung für all diese "modernen" Tools scheint sich niemand Gedanken über Sicherheit und Wartbarkeit zu machen.
Ähhh ... doch. Genau das sind die Hauptgründe, warum man nicht mehr den Kram von vor über 20 Jahren nutzt - schon gar nicht in neuen Projekten.


Merlin352 schrieb:
Manchmal ist es gut ganz genau zu lesen :
Wir nutzen hippe Web-Techstacks, Rust und Go. Und das, obwohl Sicherheit unser Verkaufsargument ist.
Ich denke da kann sich jeder selbst seine Gedanken zu machen.
Bei dem, was du hier aus dem Zitat von @SheepShaver interpretierst, gerade im Zusammenhang mit Rust, muss man sich sogar seine Gedanken machen.
 
  • Gefällt mir
Reaktionen: SheepShaver und KitKat::new()
BeBur schrieb:
Da bin ich nicht so schrecklich zuversichtlich, dass die "Elm Architecture" im starken Kontrast dazu ein Leuchtfeuer moderner Ingenieurskunst ist und bin noch eher geneigt davon auszugehen, dass mein Eindruck dazu schon ganz gut war.
Es ist erstaunlich wie inbrünstig du hier zur Schau stellst, dass du dich offensichtlich im letzten Jahrzehnt überhaupt nicht mit den aktuellen Softwaretechnologien beschäftigt hast.
Elm zu belächeln ist einfach Ahnungslosigkeit. Model-View-Update und unidirektionaler Datenfluss sind längst Standard und kein blingbling Randthema. Redux hat das praktisch 1:1 aus Elm übernommen und damit das React-Ökosystem geprägt, Vuex und ähnliche Stores machen exakt dasselbe. Iced baut seine komplette Architektur für native Desktop-UIs in Rust auf Elm-Prinzipien auf. Wer Elm heute noch abwinkt, hat sich schlicht nicht informiert oder hängt gedanklich irgendwo in den 2000ern fest.
 

Ähnliche Themen

S
Antworten
15
Aufrufe
16.945
K
Antworten
4
Aufrufe
1.518
Antworten
23
Aufrufe
16.991
MC BigMac
M
Zurück
Oben