Schaut mal hier: https://dilbert.com/strip/2021-01-11 Besser und eindeutiger kann man eines der groessten Probleme heutiger Softwareentwicklung nicht darstellen. Olaf
Besonders wirtschaftlich erfolgreich sind derzeit eben die Techfirmen. Und gute Programmierer interessiert es oft nicht jahrelang am selben Zeug zu arbeiten. Also regelmäßig ändern! Das Management lebt auch gut davon und hat seine Berechtigung. Ich würde das also nicht als "Problem heutiger Softwareentwicklung" bezeichnen, die Ecke ist damit Recht glücklich.
Beitrag #6545780 wurde von einem Moderator gelöscht.
Wenn ihr in einem Software-Unternehmen arbeiten würdet, würdet ihr wissen, dass von den Kunden ständig Wünsche nach neuen Funktionen/Features kommen. Natürlich kann man die nie alle umsetzen, weil die sich oft widersprechen. Damit die Kunden aber nicht zur Konkurrenz davonlaufen, muss man schon einiges davon umsetzen. Früher oder später wird die Software dadurch so komplex, dass sie kaum noch wartbar ist. Dann wird so von Grund auf neu gemacht, mit neuen Technologien und Fehlern die wieder behoben werden müssen, und das Spiel beginnt von vorne. Dazu kommt dass sich die ganze Technologie-Landschaft ständig wandelt, und man sowieso nicht ewig die selbe Software verkaufen kann, und man eben gelegentlich größere Umbauten oder Neu-Implementationen braucht, damit die Software z.B. auf aktuellen OS-Versionen läuft.
Olaf schrieb: > Besser und eindeutiger kann man eines der groessten Probleme > heutiger Softwareentwicklung nicht darstellen. Gähn. Früher war alles besser. Und überhaupt. Oder liegt es vielleicht daran, dass manch einer einfach (geistig) alt und unflexibel geworden ist (oder schon immer war)?
Das ist wie so vieles ein Problem, dessen Ursache darin liegt das der der es baut keiner ist der es je benutzt. Die Programmierer machen es wie sie meinen, aber sie haben ein solches Programm nie 8h täglich verwendet und wissen was man braucht und wie man es am besten bedient. So gut wie jede Maschine ist so, jedes Programm und jedes Gerät.
Wenn eine Firma 2 Programmierer beschäftigt, deren Software von 20000 Kunden genutzt wird, kann man von den Programmierern kaum verlangen, all die kuriosen Usecases und Konstellationen im Voraus zu testen, welche sich die Kunden alle ausdenken. Man ist immer wieder überrascht was für seltsame Geräte und Konfigurationen es so gibt, mit denen das eigene Produkt zusammenspielen soll.
Naja...es gibt halt solche und solche. Manchmal bin ich ehrlich erschrocken darüber, wie unbedarft und naiv manche Firmen ein Projekt angehen und sich auch noch erdreisten, dafür Geld zu nehmen. Und ich reibe mir verwundert die Augen darüber, daß diese Firmen für ihr Scheißprodukt auch noch Geld bekommen. Im Elektronikunterforum wird gerade über IAR hergezogen (anscheinend zu recht), über SAP habe ich noch nie etwas Gutes gehört (ich habs mal gesehen und weiß auch nichts Gutes über diesen Müll zu berichten), eine Verwaltungssoftware namens EasyTek (wurde dort, wo ich es gesehen habe, vollkommen zu Recht EasyDreck genannt), oder gar Teamcenter (das zu meinem Entsetzen auch noch in der Luftfahrt eingesetzt wird - eine Abwertung jeglicher Zertifizierung auf null herab). Alles Beispiele für Firmen/Produkte, die m.M.n. keine Daseinsberechtigung am Markt haben und besser früher als später sterben sollten. Ich habe mal für eine Firma eine etwas umfangreichere Excelanwendung geschrieben und dabei gelernt: Ja, der Benutzer ist grundsätzlich ein Idiot - aber gute Software muß damit umgehen können. Ich war tatsächlich sehr erstaunt als ich mein VBA-Skript mal einem Kollegen zum Testen gegeben habe, dieser damit überhaupt nich klar kam (obwohl das MEINER Meinung nach sehr logisch aufgebaut war), eine Meldung ohne zu Lesen einfach weggeklickt hat und sich in der Bedienung völlig verheddert hat und mein Programm in Zustände gebracht hat, die es nicht mehr beherrscht hat. Ich habe es dann in allerhand Iterationen überarbeitet und als der erste Kollege klarkam, den nächsten da rangesetzt, ohne größere Erklärungen einfach machen lassen und zugesehen. Irgendwann war es dann ziemlich dausicher, dann nur noch eine kurze Präsentation vor versammelter Mannschaft, daß jeder mal gesehen hat daß das jetzt benutzt wird und wie das in etwa geht, und das wars gewesen. Und das Programm wurde sehr gerne angenommen. Software so zu machen daß die Benutzer gut damit klarkommen ist eine Kunst und erfordert viel Nachdenken und Testen und Meinung/Kritik von außen. Am Besten von Fach- oder mindestens projektfremden Personen. Und da investieren viele Firmen meiner Meinung nach viel zu wenig. Das es auch anders geht, zeigen z.B. Programme wie Catia, Netbeans, Embedded Studio oder Altium Designer. Diese Programme sind zwar nicht mehr intuitiv, was aber vor allem der Komplexität der Thematik geschuldet ist. Etwas beschäftigen muß man sich damit, aber diese Programme sind gut zu benutzen. Das Dilbert-Comic...naja. Von außen mag das so aussehen. Schlechte Benutzbarkeit von Software ist m.M.n. aber keine Folge daß zuviel geredet wird (wie beim Dilbert), sondern eher zu wenig. Wenn irgendein C++-Nerd eine Graphikoberfläche macht, dabei nicht allzuviele Gedanken an eine vernünftige Benamsung von Menüs usw. denkt und womöglich auf dem Anwendungsgebiet der Software ein Laie ist, die Oberfläche womöglich noch nach einfacherer Programmierung ausrichtet - da kann man viel erwarten, aber kein Programm das man gerne benutzt.
Programmierer schrieb: > Wenn eine Firma 2 Programmierer beschäftigt, deren Software von 20000 > Kunden genutzt wird, kann man von den Programmierern kaum verlangen, all > die kuriosen Usecases und Konstellationen im Voraus zu testen, welche > sich die Kunden alle ausdenken. Man kann von den Programmierern definitiv verlangen, daß das Programm keine ungewollten Zustände annimmt. Zumindest in sehr weiten Teilen. Eine Eingabe bestimmter Werte kann unsinnig sein? Keine negativen Zeiten? Oder es ist nur ein berenzter Bereich möglich? Dann muß das geprüft und behandelt werden. Eine Eingabe ist zwar durchaus möglich, aber anderweitig problematisch? Dann erkennt und behandelt das. Wer das nicht kann, hat in der Programmiererei nix verloren. Wenn die Programmierer das zwar gerne behandeln würden, aber z.B. die kalkulierte Zeit das nicht hergibt, sind vielleicht nicht die Programmierer, aber dann halt die Projektleitung falsch besetzt - und das Produkt trotzdem immer noch scheiße.
Experte schrieb: > Oder liegt es vielleicht daran, dass manch einer einfach (geistig) alt > und unflexibel geworden ist (oder schon immer war)? Ja, ich weiss. https://www.reichelt.de/index.html?ACTION=446&LA=0&nbc=1&q=buchse%20usb%20mikro 353 Treffer, ja das war frueher wirklich besser, da kamen die Treffer deutlich treffsicherer. Wenn mich das nervt, bin ich halt "(geistig) alt und unflexibel geworden" Anderes Beispiel: Ich suche auf diversen Seiten ein Ersatzteil fuer eine Waschmaschine. Haeufigste Antwort (auf verschiedenen Seite, die sich verdaechtig aehnlich sehen): "Haben wir nicht, aber hier unsere bestselling Ersatzteile". Was muss man rauchen, um sowas zu verzapfen? wendelsberg
Wühlhase schrieb: > Man kann von den Programmierern definitiv verlangen, daß das Programm > keine ungewollten Zustände annimmt. Zumindest in sehr weiten Teilen. > Eine Eingabe bestimmter Werte kann unsinnig sein? Keine negativen > Zeiten? Sehr naive Betrachtungsweise. Eingaben sind nicht immer sowas schön kontrollierbares wie Zahlen. Gerne mal sowas wie: - Das OS beendet die Anwendung unkontrollierbar zufällig - Die Netzwerkverbindung ist teilweise weg, aber "ping 8.8.8.8" klappt - Der WLAN-Router des Kunden lässt das eigene Gerät manchmal nicht ins Netz - Die Hardware erkennt zufällige Touch-Eingaben ohne dass man den Screen berührt hätte - Tief im Treiber der von einem Zulieferer stammt steckt ein Deadlock - Das verwendete Framework/OS war nie für diese Art der Verwendung vorgesehen und man versucht es aus der Anwendung heraus dazu zu bringen das zu tun was man will - Eine externe Datenquelle liefert verkehrt verschachtelte XML-Daten, die man aber trotzdem irgendwie akzeptieren muss Da jeden möglichen Fall auszuprobieren ist unmöglich. Vor allem wenn im Büro immer alles funktioniert und die Fehler grundsätzlich nur beim Kunden auftreten. Selbst die Automobilindustrie schafft es nicht, alle erdenklichen Fälle zu testen, denn auch in der sicherheitskritischen ECU-Software gibt es gelegentlich Fehler.
Beitrag #6546013 wurde von einem Moderator gelöscht.
Beitrag #6546016 wurde von einem Moderator gelöscht.
Beitrag #6546020 wurde von einem Moderator gelöscht.
Programmierer schrieb: > Da jeden möglichen Fall auszuprobieren ist unmöglich. Vor allem wenn im > Büro immer alles funktioniert und die Fehler grundsätzlich nur beim > Kunden auftreten. Selbst die Automobilindustrie schafft es nicht, alle > erdenklichen Fälle zu testen, denn auch in der sicherheitskritischen > ECU-Software gibt es gelegentlich Fehler. Und dann vergessen die Leute gerne wie Softwareentwicklung oft abläuft: du bekommst eine GUI und die Businesslogik und ne Zeitvorgabe. Oft bist du froh wenn du in dieser Zeit das Notwendigste und ein paar Tests hinbekommst. Alle Sonderfälle abfangen? Wann willst du das bitte machen? So lange die Welt weiterhin von BWLern regiert wird, solange wird das nicht besser. Denn Leute, die glauben dass sechs Frauen ein Baby in anderthalb Monaten zur Welt bringen ... was willste da erwarten?
ThomasW schrieb: > So lange die Welt weiterhin von BWLern regiert wird, solange wird das > nicht besser. Das hat nicht unbedingt was mit BWLern zu tun. z.B. in Inhaber-geführte Unternehmen, wo der Inhaber eine Naturwissenschaft wie z.B. Geodäsie oder eine Ingenieurswissenschaft studiert hat, kommen auch gerne mal Anforderungen wie "Bau mal ein smartes per WLAN ans Internet angebundenen Gerät mit Multimedia-Funktionen. Andere smarte Geräte können das ja auch." Dass WLAN und Multimedia Zeug extrem komplexe Themen sind die man auch mithilfe bestehender Frameworks nicht leicht in den Griff bekommt, kriegt man schlecht vermittelt. Dazu kommen dann noch verrückte Probleme bei Kunden, z.B.: "Ihr Gerät geht im Standby alle paar Minuten ins WLAN und wieder raus. Mein Router schickt mir dann jedes mal eine Mail und jetzt ist mein Postfach voll. Bitte beheben!" ... leider wird das WLAN vom OS gesteuert und man kann das überhaupt nicht beeinflussen. Dass es überhaupt Router gibt die sowas machen weiß kein Programmierer. Auf die Idee, dass man für so einen skurrilen Fall vorsorgen muss, kommt keiner. Vor allem weil das Verhalten des OS identisch zu vielen Smartphones ist, die genau die gleichen Probleme machen müssten. Die Welt ist halt kein Elfenbeinturm wo sich Probleme auf numerische Eingaben außerhalb gültiger Bereiche beschränken.
Beitrag #6546188 wurde von einem Moderator gelöscht.
Wühlhase schrieb: > Man kann von den Programmierern definitiv verlangen, daß das Programm > keine ungewollten Zustände annimmt. “Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” ― Rick Cook, The Wizardry Compiled Ab einer bestimmten Komplexität sind fehlerfreie Programme auch nicht mehr möglich – deswegen gibt’s heute für Außenstehende teils obskur wirkende Methoden, Fehler zu jagen. Aber eigentlich zielt der Comic ja auch nicht auf so Fehler ab, sondern auf die (scheinbare) Einstellung mancher Entwickler: „Die Software hat sich nun bewährt, die Leute kommen damit gut klar – lass uns da mal komplett alles umbauen!“ Oft sind solche „Umbauten“ aber auch erzwungen, etwa, weil eine neue Version des verwendeten Toolkits zu Kompromissen zwingt, man aber nicht bei der alten Version bleiben kann, weil die eben EOL ist – das ist mir gerade in der jüngeren Vergangenheit wieder häufiger aufgefallen, als viele Sachen von Gtk2 auf Gtk3 portiert wurden.
:
Bearbeitet durch User
Angehängte Dateien:
-
workflow_2x.png
72 KB
"Every change breaks someones workflow" https://xkcd.com/1172/
Jack V. schrieb: > Aber eigentlich zielt der Comic ja auch nicht auf so Fehler ab, sondern > auf die (scheinbare) Einstellung mancher Entwickler: „Die Software hat > sich nun bewährt, die Leute kommen damit gut klar – lass uns da mal > komplett alles umbauen!“ Sind es denn die Entwickler? Wer ist dafür verantwortlich, dass neue Windowsversionen sich so deutlich unterscheiden? Ich bezweifle, dass die Entwickler das so wollten.
Beitrag #6546838 wurde von einem Moderator gelöscht.
Εrnst B. schrieb: > "Every change breaks someones workflow" > > https://xkcd.com/1172/ Dieser Comic ist so wahr. Changelog: - Die Ansicht in der Software ist jetzt zoombar. 10000 Kunden: - Hurra, mehr Flexibilität 1 Kunde: - Neeiinn, die Zoomstufe der original-Version ist nicht mehr erreichbar, dafür aber 10 andere Zoom-Stufen, macht das sofort rückgängig! Die originale Zoom-Stufe war irgendwie willkürlich gewählt, die neuen 10 Stufen ergeben sich durch technische Notwendigkeit des Zoom-Mechanismus, daher kann man die alte Stufe nicht dazwischen schieben...
Beispiele: - Analog-Synthesizer vs Digital-Synthesizer (Tipptaster nicht sehr groovy) - Linux GUI (Paradox eigentlich, wegen Unix und der Unix-Philosophie) (und den Patentproblemen) - Linuxe und englische Tastatur/Sonderzeichen ;) Es gibt auch gute Beispiele, bzw. eine gelungene Bedienung auf dem Handy: "Calc - Java Calculator for cell-phones and MIDP devices" "Copyright: 2003-2009 Roar Lauritzsen, roarl at users sourceforge net" http://midp-calc.sourceforge.net/Calc.html oder Schach: der große Bruder von einem Spielfreund war ein sehr guter Schachspieler, und der hatte auch einen Schachcomputer. Der kleine Rechner (mit roter Digitalanzeige, wie bei einem Radiowecker) brauchte aber öfter um die 22 Stunden für einen Zug. Abgesehen davon sind die Schachprogramme ganz schön gut geworden. Bei den neueren Windwowsen hängen auch 64-Bit-Technik und UEFI drin. Der Umzug auf höhere Bitbreiten z.B. ist nicht automatisch einfach. Man muss auch zusehen, dass man hinter dem technischen / normativen Wandel hinterherkommt, da wären wir u.a. beim Beispiel Webseiten. Ein anderes Beispiel dazu wäre vielleicht noch AVR vs ARM.
Ich denke es hängt auch oft damit zusammen das versucht wird mit einem Tool alles zu erschlagen, anstelle auf Hochspezialisierung zu gehen. Alles im Anblick eines angeblichen Mehrwerts (und nicht zuletzt Gewinn) aus Zentralisierung und Standardisierung. Das vergleiche ich so als wenn man meint ein Werkzeugkasten braucht man nicht, so mit Schraubendrehern, Schlüsseln, Zangen, etc. Ein Hammer reicht. Aber der Hammer hat in seinem Griff tausend Funktionen die man aktivieren kann, je nach Verwendung. Oder am obigen Beispiel wäre es einen Super-Taschenrechner für alle, egal ob Obstverkäufer oder Bauingenieur den benutzen. Am Ende verstehen nicht mal mehr die Fachleute die Oberflächen und die dahinterliegenden Prozesse.
:
Bearbeitet durch User
Olli Z. schrieb: > Ich denke es hängt auch oft damit zusammen das versucht wird mit > einem > Tool alles zu erschlagen, anstelle auf Hochspezialisierung zu gehen. Viele Softwares sind aber nicht einfach nur "Tools", also Werkzeuge für einen bestimmten Zweck, sondern komplexe Systeme, welche auf alle möglichen Eingaben und Ereignisse reagieren und verschachtelte Prozesse steuern müssen. Viele für ein System relevante Aspekte kann man nicht getrennt betrachten, woraus sich komplizierte Programme ergeben. Ein Beispiel ist das Android Framework, bei dem Paketverwaltung, GUI/Fenster-Verwaltung, Energie-Management, Prozess-Management usw. kompliziert miteinander verwoben sind, um dem User eine konsistente Erfahrung zu bieten. Wenn man z.B. eine Anwendung aktualisiert, soll das Symbol auf dem Homescreen aktualisiert werden, der Prozess beendet und neu gestartet, Berechtigungen geprüft und neu abgefragt, Code-Pfade im System aktualisiert, Notifications entfernt, Standby während des Prozesses blockiert werden usw... Das klappt nur wenn die einzelnen Teile eng verzahnt sind. Mit einem separaten Tool fürs Power-Management, einem für die Fenster-Verwaltung, einem für die Paketverwaltung usw. lässt sich das nicht erreichen. Deswegen kann man beim Erstellen eines eigenen Android-ROM diese Komponenten nicht einzeln deaktivieren/ersetzen, da sie alle voneinander abhängig sind. Olli Z. schrieb: > Am Ende verstehen nicht mal mehr die Fachleute die Oberflächen und die > dahinterliegenden Prozesse. Die Oberfläche des komplexen Android-Frameworks ist so einfach und intuitiv dass praktisch jeder damit umgehen kann. Die klassischen Desktop-OSe sind nicht so gut integriert und können gelegentlich verwirrendes Verhalten aufweisen, weil die einzelnen System-Aspekte nicht miteinander reden.
Programmierer schrieb: > Wenn man z.B. eine Anwendung aktualisiert, soll das > Symbol auf dem Homescreen aktualisiert werden Wie kommst Du darauf? Eine Aktualisierung sollte definitiv das Symbol NICHT aendern. wendelsberg
wendelsberg schrieb: > Wie kommst Du darauf? > Eine Aktualisierung sollte definitiv das Symbol NICHT aendern. Manchmal kommen die Manager von Softwarefirmen auf die Idee, das Corporate Design zu ändern. Dann wird der App ein neues Icon verpasst, und das muss dann auf dem Homescreen angepasst werden, damit es nicht inkonsistent zu anderen Stellen wird, wo das Icon sichtbar ist. Vor ein paar Wochen wurden z.B. die Logos vieler Google-Apps geändert.
Programmierer schrieb: > Wenn ihr in einem Software-Unternehmen arbeiten würdet, würdet ihr > wissen, dass von den Kunden ständig Wünsche nach neuen > Funktionen/Features kommen unterscheide mal bitte "neue Funktionen" von überall neue Anordnungen von Bedienmenüs. Es fing mal sinnvoll mit GEM an ging dann über win Datei open close und Fenster schliessen bis heute neu Kacheln wo man die gewohnten Dinge nicht mehr findet.
:
Bearbeitet durch User
Joachim B. schrieb: > unterscheide mal bitte "neue Funktionen" von überall neue Anordnungen > von Bedienmenüs. Ein sinnvoller strukturiertes Menü kann die Bedienung durchaus vereinfachen, vor allem wenn in der Vergangenheit immer neue Funktionen hinzugekommen sind und die gewachsene Menüstruktur kontinuierlich unübersichtlicher wurde und eine Aufräumen nötig wurde. Joachim B. schrieb: > Es fing mal sinnvoll mit GEM an ging dann über win Datei open close und > Fenster schliessen bis heute neu Kacheln wo man die gewohnten Dinge > nicht mehr findet. Aha. Ich finde das Kachel-Startmenü von Windows 10 super. Mit einem Klick hab ich ein großes Raster der mir wichtigsten Programme (dazu extra selbst angeordnet), die ich dann mit einem zweiten Klick starten kann. Viel übersichtlicher und schneller als das ewig verschachtelte Startmenü von WinXP. Blöd ist nur dass die initiale Implementation unter Win8 technisch mangelhaft war, weshalb sich jetzt alle Nutzer Kacheln=Schlecht eingeprägt haben, obwohl das bei der aktuellen Version überhaupt nicht mehr der Fall ist.
Es gab früher mal ein gutes Buch von Frederic Vester: "Denken, Lernen, Vergessen – Was geht in unserem Kopf vor, wie lernt das Gehirn, und wann läßt es uns im Stich?" Es beschreibt u.a. verschiedene Lerntypen (Wer lernt wie am besten? - und ein paar Beispiele für fundamentale Unterschiede + wer bevorzugt wird, wer diskriminiert wird usw.). Es geht auch um Zusammenhänge zwischen Angst und Lernen. Oft ist es so, dass das Unbekannte Angst macht. Oder das Dunkel oder dies und das. Und die Angst behindert Lernen oder Spaß oder beides zusammen. Die Chaosforschung (und darüberhinaus) lehrt u.a. , dass ein Vertrauensvorschuss von mindestens 50% ganz gut bzw. nötig ist. Das wäre um beim Beispiel oben zu bleiben, nur die halbe Tastatur umgestrickt. In Windows gibt es ja auch die Desktopkachel. In Fedora musste ich mich erst an die Häufigkeitsleiste gewöhnen, habe sie aber im Laufe der Zeit recht lieb gewonnen. In Windows(8) vermisse ich Debug und die 16Bit-Kompatibilität. Aber es ist auch nicht so, dass ich mit meiner Denke auf 16Bit hocken bleiben möchte. Aber könnte ich mit meinem früheren Ich kommunizieren, würde ich schon versuchen, auf "weniger ist mehr" hinzuweisen, bzw. mehr auf Dinge zu achten, die gut gehen, die man im Schlaf kann usw. oder bestimmte Schrittfolgen zu beachten, wie vom Einfachen zum Schweren. Letztlich: nicht alles ist in Stein gemeißelt. Das dachte ich als Kind aber irgendwie schon. Und die anderen 50% (Veränderung, Neues, Inspiration usw.) sind auch nötig, und die Kunst ist halt, DAS irgendwie zu managen. ;)
Programmierer schrieb: > Das klappt nur wenn die einzelnen > Teile eng verzahnt sind. Mit einem separaten Tool fürs Power-Management, > einem für die Fenster-Verwaltung, einem für die Paketverwaltung usw. > lässt sich das nicht erreichen. Doch, das geht. Kann man an Linux sehr gut sehen. Es gibt da mehrere Systeme, die eines Blickes würdig sind: dbus, gconf und X11. Mit dbus & gobject können Anwendungen beliebige Interfaces anbieten, und von anderen Anwendungen Aufrufen. Es ist quasi das Äquivalent zu COM bei Windows. Mit gconf kann man Einstellungen speichern und laden. Es ist quasi das Äquivalent zur Windows Registry. Eine Anwendung kann auch auf Änderungen von Einstellungen live reagieren. Mehrere Anwendungen können auf die selben Einstellungen reagieren. Und dann bei X11. Einerseits gibt es da xembed. Eine Anwendung kann ein Fenster einer anderen Anwendung einbinden. Zudem hat X11 das Designprinzip "Provide mechanism rather than policy". Alle clients können einander beliebige Atoms (das sind globale identifier) definieren, sich Messages senden, und bei ihren Fenstern Properties setzen. So können z.B. die WM, eine Anwendung, etc. eine Property setzen für ich kann X, und die WM, Anwendung, etc. wissen das dann, und können untereinander X verwenden. Bevor du jetzt meinst, das könne nicht gut gehen, jeder würde was anderes machen, in der Realität passiert das nicht, oder Höchstens, wenn die grossen wie Gnome oder Canonical mal wieder meinen es gäbe nur sie selbst, die anderen sind vernünftig und schauen erst mal was es schon gibt. Gute Positivbeispiele sind z.B. _MOTIF_WM_HINTS und XDND. Bei _MOTIF_WM_HINTS hat das motiv Toolkit & wm Flags eingeführt, welche Buttons der Fensterrahmen haben soll, ob es einen rahmen haben soll, usw. Andere brauchten sowas auch, und haben dann die Property einfach auch verwendet, und andere WMs haben die dann auch angefangen zu interpretieren. XDND[1] ist Drag & Drop. Also eine ziemlich komplexe Sache, aber trotzdem hat niemand Probleme damit, trotz der Vielzahl unterschiedlicher Anwendungen, die das unterstützen müssen. Aber warum muss hier nicht alles von allem wissen, und es spiel trotzdem alles gut zusammen? Im Endeffekt läuft es hinaus auf: 1) Interfaces - Mehrere Anwendungen können die selben Sachen implementieren. 2) Conventions - Mehrere Anwendungen können sich einigen, wo dinge liegen, wie was gemacht wird, wie etwas heisst, etc. 3) Notifications & Inversion of Control Der wichtigste punkt dürfte aber Notifications & Inversion of Control sein. Wurden die interfaces und damit der control flow & abhängigkeiten, richtig modelliert, braucht man keine komplexen Programme, um komplexe Interaktionen zu handhaben. Wenn ich eine Datei zum Desktop hinzufüge, muss ich mich nicht darum kümmern, bei der konkreten Anwendung, die die anzeigen soll, zu sagen "Zeig mir jetzt das Symbol an". Nein, ich muss nur die Datei erstellen. Bei anderen Sachen sagt man eventuell noch dem Systembus "Hey, es gibt jetzt noch X" oder "Ich kann X" oder was in die Richtung, aber mehr auch nicht. Eine Anwendung, die das wissen muss, sagt einfach dem System / System Bus Anwendung, ich will alle News zu X kriegen, oder sag mir sobald ein X da ist, usw. Bei Dateiänderungen wäre das INotify, und der Kernel informiert darüber gleich selbst. Die Anwendung fragt dann einfach den Rest, den sie danach noch wissen muss, nach. Mit der Komplexität was was genau machen muss, muss man sich nur herumschlagen, wenn man solchen kram explizit hartkodiert, viel in ein Binary stopft was nichts miteinander zutun hat, die Abhängigkeiten nicht entkoppelt wo nötig, oder diese Abhängigkeiten falsch herum macht. Das ist dann halt aber einfach nur schlechtes Design, auch wenn es stattdessen oft gerne als "Stimmiges Gesamtkonzept" verkauft wird. 1) https://www.freedesktop.org/wiki/Specifications/XDND/
🐧 DPA 🐧 schrieb: > Mit dbus & gobject können Anwendungen beliebige Interfaces anbieten, und > von anderen Anwendungen Aufrufen. Es ist quasi das Äquivalent zu COM bei > Windows. Android hat dafür Binder. Es nutzt aber X11 nicht, weil es eben doch nicht so toll ist. Das Font-Rendering bei X11 ist z.B. ein Chaos. Besonders sicher ist es auch nicht, denn Anwendungen können gegenseitig auf ihre Fenster zugreifen. Bei Android passiert das nicht, da sind die Anwendungen gegeneinander abgeschottet. X11 ist auch kein besonders gutes Beispiel für ein geradliniges "Tool" welches genau eine Sache macht; es ist ein ziemlich komplexes System was diverse Ein/Ausgabe-Geräte unterstützt, alle möglichen Erweiterungen hat, Direct-Rendering anspricht, eine eigene Konfigurationssprache und Netzwerkprotokolle hat, mit Fenstermanagern hantiert usw. Mit der Zeit sind auch immer mehr Features hinzugekommen und an der Architektur wurde herumgebastelt. Ich wüsste nicht, wie das jetzt modularer als das Android GUI-System ist. Dass X11 Funktionalität bietet um Fensterinhalte zu erstellen ist ein überholtes Konzept, und die meisten Anwendungen nutzen das nicht, aber es ist ein Ballast den X11 mit herumschleppt; genau das, was im Thread ursprünglich bemängelt wurde. Daher wurde ja auch Wayland entwickelt.
Programmierer schrieb: > X11 ist auch kein besonders gutes Beispiel für ein geradliniges "Tool" > welches genau eine Sache macht; es ist ein ziemlich komplexes System was > diverse Ein/Ausgabe-Geräte unterstützt, alle möglichen Erweiterungen > hat, Direct-Rendering anspricht, eine eigene Konfigurationssprache und > Netzwerkprotokolle hat, Es abstrahiert den Zugriff auf diverse IO Geräte, nämlich Bildschirme, Tastatur, Maus, usw., so dass diese von mehreren anderen Anwendungen gleichzeitig genutzt werden können, und bietet Mechanismen, damit diese diese steuern/managen können. Das ist die eine Sache, die es macht. X11, insbesondere Xorg, ist sicher nicht perfekt, aber es ging mir ja dort auch eher um deren "Provide mechanism rather than policy" design prinzip gegenüber den Clients, wo die Clients bestimmen können, wie dinge letztendlich funktionieren, und X nur ein paar grundlegende Mechanismen dafür bereitstellt. Dafür gibt es schlicht kein besseres Beispiel. > mit Fenstermanagern hantiert usw. Ein Fenster Manager ist in X11 ein normaler client, wie jede andere Anwendung auch. Ein grosser Vorteil davon ist, dass man sie jederzeit updaten, neu starten, ersetzten, etc. kann, ohne das ich das ganze System und alle GUI Anwendungen neu starten müsste. > Mit der Zeit > sind auch immer mehr Features hinzugekommen und an der Architektur wurde > herumgebastelt. Ja, ein paar Altlasten sind noch für Rückwärtskompatiblität da, aber das passiert doch bei jedem System früher oder später. > Ich wüsste nicht, wie das jetzt modularer als das > Android GUI-System ist. Ich kenne zwar das Android GUI-System nicht, aber so wie ich Android einschätze, kann man da doch sicher gar nichts machen, was nicht explizit vorgesehen wurde? Du selbst sagtest doch: Programmierer schrieb: > Das klappt nur wenn die einzelnen Teile eng verzahnt sind. Kann ich bei Android mal eben das Fenster einer beliebigen Anwendung, z.B. eines Terminal Emulators nehmen, und in meine Anwendung einbauen? Mit X11 kann ich das! Kann ich beim Android GUI System in einer unabhängigen Anwendung mal eben einen komplett neuen Mechanismus implementieren, der nicht vorgesehen war z.B. ein neuartiges Drag & Drop System einführen, eine Anwendung erstellen in der man Fenster als Tabs reinziehen kann, ein neuartiger Touchgesten Manager, oder sonst was ungewöhnliches, das ich mir noch gar nicht vorstellen kann? Bei X11 kann ich das! Selbst wenn Android eine gewisse Modularität hat, es ist in der Hinsicht überhaupt nicht Flexibel. > Dass X11 Funktionalität bietet um Fensterinhalte > zu erstellen ist ein überholtes Konzept, Fonts und Pixmaps, ein paar primitive Zeichenfunktionen hat es. Alles andere, Eingabefelder, GUI Elemente, etc., fehlt aber doch alles? > und die meisten Anwendungen > nutzen das nicht, aber es ist ein Ballast den X11 mit herumschleppt; > genau das, was im Thread ursprünglich bemängelt wurde. Also X hat ja einige unschöne Altlasten, aber die paar Zeichenprimitive stören ja nun wirklich keinen. Ausserdem sollte der Benutzer ja nichts davon merken, ob jetzt da Xorg oder XWayland drunter ist. > Daher wurde ja auch Wayland entwickelt. Irgendwann wird das auch alten Ballast ansetzen, falls sich langfristig das überhaupt durchsetzt. Und den alten Ballast von X wird es auch nicht los, Stichwort XWayland (Momentan die selben Quellen wie XOrg, übrigens). Das einzige, was da zurückgelassen wurde, ist die DDX. Wayland ist in vielerlei Hinsicht vermutlich sogar etwas flexibler und modularer als X, aber es gefällt mir überhaupt nicht. Wenn ich in X11 einen Window Manager machen will, ist das trivial. Ich muss mich eigentlich wirklich nur darum kümmern, die Fensterchen zu Platzieren. Aber in Wayland muss man den ganzen Kompositor schreiben, und all die hunderten Protokolle implementieren, die doch eigentlich keinen interessieren. In XOrg entspräche das der modesetting DDX und dem halben Server. Zum glück ist das in X alles sauber wegabstrahiert, und damit nie notwendig. Eigentlich finde ich beide, X11 und Wayland, scheisse, wenn auch aus anderen gründen. Ich mag Flexibilität, aber das muss doch nicht zwangsläufig auf kosten einer Abstraktion sein, die so dünn ist, dass man sich um jeden scheiss selbst kümmern muss. Die Ideale Abstraktion ist so, dass ich möglichst nicht eingeschränkt werde in meinen Möglichkeiten, aber ich mich wenn ich was machen will ich mich nicht erst mit uninteressanten Implementationsdetails herumärgern muss. Müsste ich einen Display Server schreiben, würde ich in die andere Richtung gehen, und einen Deklarativen statt Funktionalen Ansatz verfolgen, mit höherem Abstraktionsgrad, aber trotzdem mit flexibler & modularer Erweiterbarkeit auf allen Ebenen.
🐧 DPA 🐧 schrieb: > Ich kenne zwar das Android GUI-System nicht, aber so wie ich Android > einschätze, kann man da doch sicher gar nichts machen, was nicht > explizit vorgesehen wurde? Eigene Fenstermanager implementieren o.ä. kann man durchaus. 🐧 DPA 🐧 schrieb: > Kann ich bei Android mal eben das Fenster einer beliebigen Anwendung, > z.B. eines Terminal Emulators nehmen, und in meine Anwendung einbauen? Nicht einfach so, das wäre eine himmelschreiende Sicherheitslücke. Fragmente von kooperationswilligen Anwendungen kann man aber einbinden, ja. 🐧 DPA 🐧 schrieb: > Bei X11 kann ich das! Unter Android kannst du mit Binder auch alle erdenkliche Interprozesskommunikation bauen. 🐧 DPA 🐧 schrieb: > Fonts und Pixmaps, ein paar primitive Zeichenfunktionen hat es. Alles > andere, Eingabefelder, GUI Elemente, etc., fehlt aber doch alles? Es hat z.B. serverseitige Fonts, ein unnötig kompliziertes aber dennoch nicht besonders nützliches Feature, denn damit geht IIRC kein vernünftiges Anti-Aliasing. 🐧 DPA 🐧 schrieb: > Aber in Wayland muss man den ganzen Kompositor schreiben, und all die > hunderten Protokolle implementieren, die doch eigentlich keinen > interessieren. Das ist vermutlich der Preis dafür, dass in Wayland alles "compositing" ist. Das ist aber halt heutzutage ein Feature, das man haben will...
Programmierer schrieb: > 🐧 DPA 🐧 schrieb: >> Fonts und Pixmaps, ein paar primitive Zeichenfunktionen hat es. Alles >> andere, Eingabefelder, GUI Elemente, etc., fehlt aber doch alles? > > Es hat z.B. serverseitige Fonts, ein unnötig kompliziertes aber dennoch > nicht besonders nützliches Feature, denn damit geht IIRC kein > vernünftiges Anti-Aliasing. Das Serverseitige X11 Font System hat noch viel grössere Probleme als das. Keine automatischen Zeilenumbrüche, die gesamte Positionierung muss man manuell machen, ich glaube nicht sichtbare Fensterteile muss man selbst neu zeichnen, wenn es wieder sichtbar wird, Unicode wird nicht voll unterstützt, und all die dinge wie Ligaturen, Worttrennung und dadurch verursachte Zeichenänderungen, und vieles mehr, kann es alles nicht. Aber wenn das alles sauber gehen würde, würde es schon nützlich sein.
Das geile Ergebnis an diesem thread: Die ganzen hier antwortenden Programmierer sehen nicht Mal das Problem sondern erfinden nur tausende von Ausreden.
MaWin schrieb: > Die ganzen hier antwortenden Programmierer sehen nicht Mal das Problem > sondern erfinden nur tausende von Ausreden. Die ganzen Kfz-Mechaniker geben auch immer nur Ausreden, es kann doch nicht so schwierig sein ein fliegendes Auto zu bauen.
Wühlhase schrieb: > Ja, der Benutzer ist grundsätzlich ein Idiot - aber gute Software muß > damit umgehen können. Großartige Einstellung! Ja, genau so denken offensichtlich ganze Heerscharen von Programmierern - und genau so schreiben sie ihre Programme. Ähem.. nein, nicht genau so, sondern nur etwa so - und den Rest soll dann der Debugger erledigen. W.S.
Programmierer schrieb: > Sehr naive Betrachtungsweise. Eingaben sind nicht immer sowas schön > kontrollierbares wie Zahlen. [...] Das sehe ich anders. Die meisten deiner Beispiele beruhen auf genau dem, was ich vorher kritisiert habe, oder auf Hardwarefehlern (und dagegen ist Software weitgehend machtlos, da hilft oft nur eine Fehlermeldung und fertig - dann gehts halt nicht). Der Rest teilt sich auf miserable Vorarbeit und Projektleitung auf, Software wird freilich nicht nur von Programmierern kaputt gemacht. Wenn du völlig kaputte XML-Dateien bekommst, dann gehört den Programmierern ihr Dreck um die Ohren gehauen - wenn auch anderen Programmierern als der armen Sau, die das jetzt irgendwie verarbeiten muß. Und daß übermäßiger Zeitdruck und schlechte Planung ein Produkt normalerweise ebenfalls abwerten, da dürften wir uns einig sein. Das müssen wir nicht weiter vertiefen. Allerdings: Programmierer schrieb: - Die Netzwerkverbindung ist teilweise weg, aber "ping 8.8.8.8" klappt Mit so etwas z.B. muß Software meiner Meinung nach umgehen können. Wenn es deine Anwendung in den Tod reißt wenn die Verbindung zum Server abbricht, muß man sich was einfallen lassen. Auf einem Datenbanksnapshot weiterarbeiten oder die bisherigen Ergebnisse zwischenspeichern und später weitergeben, ... was halt gerade irgendwie geht. Wenn der Kunde den Mehraufwand nicht bezhahlen will...hat er halt Prügel verdient. Unterm Strich bleibe ich jedoch dabei: Es wurde und wird immer noch viel zu oft zuviel Geld für viel zu schlechte Software bezahlt. Und sowas muß vom Markt verschwinden. W.S. schrieb: > Wühlhase schrieb: >> Ja, der Benutzer ist grundsätzlich ein Idiot - aber gute Software muß >> damit umgehen können. > > Großartige Einstellung! > Ja, genau so denken offensichtlich ganze Heerscharen von Programmierern > - und genau so schreiben sie ihre Programme. > > Ähem.. nein, nicht genau so, sondern nur etwa so - und den Rest soll > dann der Debugger erledigen. Ich bin auf deine Ausführungen gespannt was du mit einem Debugger ausrichten willst, wenn der Benutzer mit deiner Software Amok läuft.
Wühlhase schrieb: > (und dagegen > ist Software weitgehend machtlos, da hilft oft nur eine Fehlermeldung > und fertig - dann gehts halt nicht). Der Chef sagt trotzdem "mach dass es funktioniert". Man kann sich behelfen z.B. durch automatische Neustarts, Filtern von Eingaben o.ä. Das macht's natürlich alles noch komplizierter, schlechter wartbar, fehleranfälliger. Wühlhase schrieb: > Wenn > du völlig kaputte XML-Dateien bekommst, dann gehört den Programmierern > ihr Dreck um die Ohren gehauen - wenn auch anderen Programmierern als > der armen Sau, die das jetzt irgendwie verarbeiten muß. Die Firma die die XML-Datenquelle erstellt hat existiert nicht mehr, die Programmierer sind nicht mehr greifbar, Chef sagt "mach dass es funktioniert". Also furchtbare Workarounds basteln welche kaputte Daten einlesen können - mehr Komplexität, Fehleranfälligkeit, ... Wühlhase schrieb: > Und daß übermäßiger Zeitdruck und schlechte Planung ein Produkt > normalerweise ebenfalls abwerten, da dürften wir uns einig sein. Die allermeisten Softwareprobleme kommen aber daher. Außerdem noch Gier und Geheimniskrämerei (z.B. unnötig proprietäre Software oder Spezifikationen). Wühlhase schrieb: > Mit so etwas z.B. muß Software meiner Meinung nach umgehen können. Wenn > es deine Anwendung in den Tod reißt wenn die Verbindung zum Server > abbricht, muß man sich was einfallen lassen. Ja, muss sie. Aber einfach und straight-forward ist das nicht, und außerdem nicht immer einfach zu testen. Wer mit smarten WLAN-fähigen Geräten zu tun hat ist überrascht, wie instabil so WLAN-Heimnetze sind... Wühlhase schrieb: > Wenn der Kunde den Mehraufwand nicht bezhahlen will...hat er halt Prügel > verdient. Kunden wollen grundsätzlich gar nichts bezahlen und beschweren sich lauthals in Foren und Bewertungen über den zu hohen Preis selbst der billigst-möglichen Software. Wühlhase schrieb: > Unterm Strich bleibe ich jedoch dabei: Es wurde und wird immer noch viel > zu oft zuviel Geld für viel zu schlechte Software bezahlt. Das würde ich nicht sagen. Das Geld wird höchstens an der falschen Stelle eingesetzt. Würde man Produkte von Anfang an anständig bezahlen, würde man hinten heraus viel sparen können, aber das machen Kunden nicht. Die Software, die so auf dem Markt ist, ist eben das Beste, was sich mit der gegebenen Zeit, Geld, Expertise und Erfahrung so machen ließ. Niemand entwickelt absichtlich schlechte Software. Erfahrene und gut ausgebildete Programmierer fallen auch nicht vom Himmel sondern sind teuer. Nicht wenige Firmen verfolgen die Strategie, lieber viele unerfahrene Programmierer statt wenige erfahrene einzustellen; denn die sind leichter ersetzbar, leichter zu finden und produzieren Software, die Kollegen auf gleichem Niveau auch verstehen.
Programmierer schrieb: > Niemand entwickelt absichtlich schlechte Software. Das stimmt nicht. Das Geschaeftsmodell einiger ganz Grosser mit 3 Buchstaben beruht genau darauf. Grottige SW, deren Anpassung dann der Kunde mit 4-stelligen Tagessaetzen bezahlen muss. Eine Zeiterfassung z.B., bei der ich um 21:45h anfange und laut Tabelle um 30:05h aufhoere, und nein das sind nicht 8:20h, sondern 8,33h. DAS muss man erstmal erfinden, das geht nicht mit Schlamperei, dazu braucht es Absicht. wendelsberg
wendelsberg schrieb: > Eine Zeiterfassung z.B., bei der ich um 21:45h anfange und laut Tabelle > um 30:05h aufhoere, und nein das sind nicht 8:20h, sondern 8,33h. Das hat durchaus eine innere Logik. Ich glaube nicht, dass die Programmierer unwillens oder unfähig waren, das anders zu machen. Das hat sich irgend jemand als tolles Konzept ausgedacht. Oder es ist für irgendeinen Standard oder Norm so erforderlich. Zeiten als Stunden mit Dezimalbruch darzustellen ist gar nicht so dumm, damit lässt sich leichter rechnen als mit Stunden+Minuten. Nur sollte man sich was schlaues überlegen um ein benutzerfreundlicheres Endergebnis darzustellen.
Programmierer schrieb: > Zeiten als Stunden mit > Dezimalbruch darzustellen ist gar nicht so dumm, damit lässt sich > leichter rechnen als mit Stunden+Minuten. Das ist so allgemein gesagt Unsinn. Natürlich lässt sich für Menschen mit 60 Minuten leichter rechnen. Die Zahl ist hochteilbar. Das ist der Grund, weshalb sie bei Zeiten und z. B. auch bei Winkeln verwendet wird.
Programmierer schrieb: > Wenn ihr in einem Software-Unternehmen arbeiten würdet, würdet ihr > wissen, dass von den Kunden ständig Wünsche nach neuen > Funktionen/Features kommen. Natürlich kann man die nie alle umsetzen, > weil die sich oft widersprechen. Damit die Kunden aber nicht zur > Konkurrenz davonlaufen, muss man schon einiges davon umsetzen. Früher > oder später wird die Software dadurch so komplex, dass sie kaum noch > wartbar ist. Dann wird so von Grund auf neu gemacht, mit neuen > Technologien und Fehlern die wieder behoben werden müssen, und das Spiel > beginnt von vorne. Dazu kommt dass sich die ganze Technologie-Landschaft > ständig wandelt, und man sowieso nicht ewig die selbe Software verkaufen > kann, und man eben gelegentlich größere Umbauten oder > Neu-Implementationen braucht, damit die Software z.B. auf aktuellen > OS-Versionen läuft. Genau. Jeder zweite unbedarfte Otto Normalentwixkler mit Bildungslücken von der Straße reimt sich aus unvollständigen Informationen irgendeinen Schwachsinn zusammen. Wie soll es dem User da besser gehen.
Der User ist eine Gummikuh. Er sieht aus wie Butter Keeaton, fällt auch dauernd um und ist der festen Überzeugung daß er die Bedienung g seines PCs vollständig beherrscht.
Programmierer schrieb: > Der Chef sagt trotzdem "mach dass es funktioniert". Programmierer schrieb: > Chef sagt "mach dass es funktioniert". Es gibt Firmen, die haben nehmen solche Aufträge gar nicht erst an. Weil sie wissen daß das nur Frust und schlechte Produkte nach sich zieht und kaum etwas verdient werden kann weil der Kunde nix bezahlen will. Und es gibt Firmen, die nehmen nur solche Aufträge - warum, das weiß ich nicht. Es gibt Kunden, die wollen und können nix bezahlen. Und es gibt Kunden, die wissen daß vernünftige Arbeit Geld kostet und nehmen das auch in die Hand. Und sehen das eher als Investition von der sie sich einen Vorteil versprechen können. Das gleiche Problem kennt eigentlich jeder Privatmensch auch mit Autowerkstätten, Handwerkern, usw. Programmierer schrieb: > Wühlhase schrieb: >> Und daß übermäßiger Zeitdruck und schlechte Planung ein Produkt >> normalerweise ebenfalls abwerten, da dürften wir uns einig sein. > > Die allermeisten Softwareprobleme kommen aber daher. Außerdem noch Gier > und Geheimniskrämerei (z.B. unnötig proprietäre Software oder > Spezifikationen). Ich sehe aber keinen Grund, sich damit abzufinden und einfach nicht mitzumachen. > Wühlhase schrieb: >> Unterm Strich bleibe ich jedoch dabei: Es wurde und wird immer noch viel >> zu oft zuviel Geld für viel zu schlechte Software bezahlt. > > Das würde ich nicht sagen. Das Geld wird höchstens an der falschen > Stelle eingesetzt. Würde man Produkte von Anfang an anständig bezahlen, > würde man hinten heraus viel sparen können, aber das machen Kunden > nicht. Wie gesagt: Schiebe nicht alles auf den Kunden ab. Es gibt ja auch genug Firmen, die bereit sind, Schrott zu liefern. Und dann haben wir solchen Murks wie De-Mail oder das "Besondere Elektronische Anwaltspostfach". Ein Kommunikationskanal, der hochsensible Daten transportieren soll und löcherig ist wie Edamer - und wo die liefernde Firma überhaupt erst jemand Fachkundigen angeheuert (und man sich anscheinend das erste Mal ernsthaft Gedanken um grundlegene Anforderungen gemacht) hat nachdem es öffentlich zu peinlich wurde. https://de.wikipedia.org/wiki/Besonderes_elektronisches_Anwaltspostfach Ich bleibe dabei: solche Firmen gehören aus dem Markt ausgesondert. Programmierer schrieb: > Die Software, die so auf dem Markt ist, ist eben das Beste, was > sich mit der gegebenen Zeit, Geld, Expertise und Erfahrung so machen > ließ. Niemand entwickelt absichtlich schlechte Software. Erfahrene und > gut ausgebildete Programmierer fallen auch nicht vom Himmel sondern sind > teuer. Wenn es nicht reicht, muß man es halt lassen. Vorher ging es ja auch, oder nicht? Irgendwo habe ich neulich die Tage gelesen, daß die Übermittlung der Coronafälle in Deutschland hautpsächlich mit Fax, Exceltabellen und dem guten alten Telefonbuch bewerkstelligt wird. Es gibt auch Software dafür (muß extra autorisiert werden, die Behörden dürfen da anscheinend nicht einfach irgendwas nehmen was zwar funktionieren würde, aber nicht abgesegnet ist), aber die scheint noch schlechter zu sein.
Wühlhase schrieb: > Es gibt Firmen, die haben nehmen solche Aufträge gar nicht erst an. Solche Probleme treten grundsätzlich erst nach Annahme des Auftrags auf. Oder das Projekt ist eine Eigenentwicklung. Wühlhase schrieb: > Das gleiche Problem kennt eigentlich jeder Privatmensch auch mit > Autowerkstätten, Handwerkern, usw. Gerade Privatpersonen sind unfassbar geizig. Sieht man doch hier im Forum, wo für Hobbyzwecke immer der kleinstmögliche µC genommen werden muss, der im Einzelstück dann 1€ billiger ist als ein größerer, mit dem man sich viel Arbeit sparen könnte (mehr Leistungsreserve usw.). Privatpersonen verstehen insbesondere das Konzept von Entwicklungskosten nicht. Gutes Beispiel ist der J-Link - die Hardware kostet vielleicht 10€ (Mikrocontoller mit Gehäuse und 2 Steckern), aber verkauft wird er für ab 500€ (für kommerzielle Nutzung), weil die Entwicklungskosten für die Firmware erst einmal wieder reingeholt werden müssen. Trotzdem wird gelästert, wie so ein vermeintlich einfaches Gerät so teuer verkauft wird. Wühlhase schrieb: > Ich sehe aber keinen Grund, sich damit abzufinden und einfach nicht > mitzumachen. Man kann daran arbeiten. Viele Projektmanager sind aber uneinsichtig - "das haben wir immer schon so gemacht". Wühlhase schrieb: > und wo die liefernde Firma überhaupt erst > jemand Fachkundigen angeheuert (und man sich anscheinend das erste Mal > ernsthaft Gedanken um grundlegene Anforderungen gemacht) hat nachdem es > öffentlich zu peinlich wurde. Hier ist der springende Punkt - es hat kein Programmierer absichtlich schlecht umgesetzt - die Firma hatte einfach gar nicht erst einen geeigneten Programmierer eingestellt. Wühlhase schrieb: > Wenn es nicht reicht, muß man es halt lassen. Wenn man es lässt, verdient man nix. Wenn man miese Software verkauft, gibt es immer einen der sie kauft. Wühlhase schrieb: > muß extra autorisiert werden, die Behörden dürfen da anscheinend nicht > einfach irgendwas nehmen was zwar funktionieren würde, aber nicht > abgesegnet ist Bei Behörden ist das alles nochmal extra kompliziert, die stecken so tief in ihrem Netz aus Vorschriften dass die überhaupt nicht mehr sinnvoll agieren können. Seit dem 1. Lockdown ist fast 1 Jahr vergangen, und die Bildungsministerien haben immer noch keine Möglichkeit vorgesehen, wie Lehrer Distanz-Unterricht machen können. Daher müssen die auf fragwürdige kommerzielle Lösungen wie Zoom ausweichen. Nachdem Digitalisierung und e-Learning Jahrzehnte blockiert wurden, werden jetzt die Lehrer (die teilweise noch mit Schreibmaschinen arbeiten) plötzlich mit IT-Systemen wie Moodle allein gelassen. Man will gar nicht wissen was da so alles abläuft, da kriegt man graue Haare von. Behörden kann man nicht als Maßstab für effizientes oder wirtschaftliches Handeln nehmen.
🐧 DPA 🐧 schrieb: > Kann ich bei Android mal eben das Fenster einer beliebigen Anwendung, > z.B. eines Terminal Emulators nehmen, und in meine Anwendung einbauen? > Mit X11 kann ich das! > > Kann ich beim Android GUI System in einer unabhängigen Anwendung mal > eben einen komplett neuen Mechanismus implementieren, der nicht > vorgesehen war z.B. ein neuartiges Drag & Drop System einführen, eine > Anwendung erstellen in der man Fenster als Tabs reinziehen kann, ein > neuartiger Touchgesten Manager, oder sonst was ungewöhnliches, das ich > mir noch gar nicht vorstellen kann? > Bei X11 kann ich das! > > Selbst wenn Android eine gewisse Modularität hat, es ist in der Hinsicht > überhaupt nicht Flexibel. Aber erfolgreich.
wendelsberg schrieb: > Programmierer schrieb: >> Niemand entwickelt absichtlich schlechte Software. > > Das stimmt nicht. > Das Geschaeftsmodell einiger ganz Grosser mit 3 Buchstaben beruht genau > darauf. > Grottige SW, deren Anpassung dann der Kunde mit 4-stelligen Tagessaetzen > bezahlen muss. In Bezug darauf ist auch noch das Open Core Businessmodell zu erwähnen. Ein paar Basisfunktionen sind gratis & open source, aber so ziemlich alles andere ist proprietär. Wenn man da dann was hinzufügen will, und es sich verkaufen lässt, kommt es dann nur in die kommerzielle Version. So ist dann sichergestellt, dass die Kommerzielle Version immer besser ist. Es gibt noch Variationen davon, z.B. der Plugin Store darf man nicht mit anderer Software nutzen (als ToS des (proprietären) Store, die Software ist ja "Frei"), und solchen Bullshit. Stellt sicher, dass die eigene Software auch die beste bleibt, und nicht irgend ein Fork beliebter wird. So oder so, wenn die Software richtig brauchbar sein soll, muss der Kunde nochmal drauf zahlen. Und die meisten merken noch nicht einmal, was da abgeht, und sagen dann "Oh, Firma X ist so Fortschrittlich / Nutzerorientiert / Sozial, etc., die veröffentlichen ihre Software sogar OpenSource & OSI Zertifiziert, so Gutherzig!!!", dabei hindern sie ja eigentlich die Entwicklung guter Freier Software...
Programmierer schrieb: > Wühlhase schrieb: >> Es gibt Firmen, die haben nehmen solche Aufträge gar nicht erst an. > > Solche Probleme treten grundsätzlich erst nach Annahme des Auftrags auf. Aber man guckt sich doch den Kunden vorher an...oder nicht? Programmierer schrieb: > Gerade Privatpersonen sind unfassbar geizig. Sieht man doch hier im > Forum, wo für Hobbyzwecke immer der kleinstmögliche µC genommen werden > muss, der im Einzelstück dann 1€ billiger ist als ein größerer, mit dem > man sich viel Arbeit sparen könnte (mehr Leistungsreserve usw.). Ja - und wir sehen hier im Forum auch, wie es dann weitergeht. Siehe hier: Beitrag "Re: Massekabel so teuer" Das man einen möglichst kleinen µC nimmt finde ich sogar noch gut, das finde ich besser als maßlos übertrieben riesige µCs für Trivialaufgaben zu verwenden. Programmierer schrieb: > Man kann daran arbeiten. Viele Projektmanager sind aber uneinsichtig - > "das haben wir immer schon so gemacht". Dann würde ich doch vorschlagen, daß wir - jeder nach seinen Möglichkeiten - daran arbeitet und die Welt NICHT mit schlechter Arbeit noch schlechter macht. Einverstanden?
Wühlhase schrieb: > Aber man guckt sich doch den Kunden vorher an...oder nicht? Was man das später für Datenquellen bekommt weiß man vorher nicht. Wenn man ein Produkt selbst produziert und dann auf dem Markt verkauft weiß man auch nicht genau was die Kunden so für eine IT-Landschaft haben. Wühlhase schrieb: > Das man einen möglichst kleinen µC nimmt finde ich sogar noch gut, das > finde ich besser als maßlos übertrieben riesige µCs für Trivialaufgaben > zu verwenden. Ich find's übertrieben viele Stunden Arbeit in ein Einzelstück zu stecken, wenn man sich das mit einem 1€ teureren µC auch sparen könnte. Wühlhase schrieb: > Dann würde ich doch vorschlagen, daß wir - jeder nach seinen > Möglichkeiten - daran arbeitet und die Welt NICHT mit schlechter Arbeit > noch schlechter macht. Einverstanden? Utopisch! Die Softwarebranche ist getrieben von harter Konkurrenz, Kapitalismus und dem Druck, immer als Erster auf dem Markt zu sein. So lange das so ist, wird die Software so bleiben wie sie ist. Software-Entwicklung ist nunmal Mangelwirtschaft.
Programmierer schrieb: > Software-Entwicklung ist nunmal Mangelwirtschaft. Ist wohl etwas überdramatisch. Allein die Wirtschaftlichen Hintergründe spielen ja auch ihre Rolle, da ist man nicht allein als Programmierer der "Böse". Auf der anderen Seite sehe ich gerade da die Herausforderungen. Also sowas, wie man die Kurve kriegt zu einem qualitativen Produkt, wie man BWLer dazu bringt, etwas mehr Geld (für ein ordentliches Produkt) zu riskieren, oder wie man die Komplexität besser handlen könnte am Beispiel von Open World Games. Es müsste bei solchen Spielen auch möglich sein, zusätzliche Qualität einzukaufen, z.B. Audio, Sprache, Stimme o.ä. Das driftet leicht ins politische - etwas weniger politisch ist der private Anteil also beispielsweise qualitative Produkte einfach deswegen erstellen, weil man es kann, und daran auch Spaß hat. Know How ist einer der fundamentalen Produktiosfaktoren neben Arbeit, Boden und Kapital.
Wühlhase schrieb: > Das sehe ich anders. Die meisten deiner Beispiele beruhen auf genau dem, > was ich vorher kritisiert habe, oder auf Hardwarefehlern (und dagegen > ist Software weitgehend machtlos, da hilft oft nur eine Fehlermeldung > und fertig - dann gehts halt nicht). Ich habe immer mehr den Eindruck, daß viele (dich eingeschlossen) irgendwie unter einer Käseglocke programmieren. Was nicht geht, führt zu einer Fehlermeldung. Mami...es geht nicht..huhuhu. Nein, es geht auch anders. Ganz anders. Ich war früher in der Halbleiterei und bei den dortigen Endmeßautomaten gab es alle nase lang Überschläge, die sämtliche Logik in der Meß- und Sortierperipherie durcheinanderwarfen. Das war normal, denn wenn ein paar nF bei der Sperrspannungsmessung einer faulen 4008 oder so entladen werden, dann ist das so. Ich habe bei der Programmierung dieses Zeugs heftig darauf achten müssen, jeden Furz per Timeout zu überwachen, an jeder Stelle wenn nötig die Peripherie neu aufzusetzen, die betreffenden BE in den Ausschuß zu befördern (an dem Rechner waren mehrere Meßstationen dran) und dann die Arbeit wieder aufzunehmen. Und natürlich Protokollierung. Das nur als illustriertes Beispiel, daß man auch bei völlig unkorreliertem Versagen die Kiste wieder in Gang kriegt. Man muß drauf gefaßt sein und sowas von vornherein richtig einplanen. Also erzähle du nicht hier, daß man da weitgehend machtlos sei. Das stimmt nämlich überhaupt nicht. Es ist nur ein Mangel an Wollen oder Denkfaulheit. Ein Muster-Gegenbeispiel war vor geraumer Zeit hier ein Beitrag, wo jemand bei einem Hardfault als Reaktion nur mittels printf eine Fehlermeldung absetzt - offenbar unter der Annahme, daß sowohl der Stack noch OK ist als auch daß die Heapverwaltung noch funktioniert. Das ist so etwa dein obiger Ansatz. Jeder normale Entwickler würde stattdessen den sicheren System-Wiederanlauf organisieren. > Ich bin auf deine Ausführungen gespannt was du mit einem Debugger > ausrichten willst, wenn der Benutzer mit deiner Software Amok läuft. Ich habe im Prinzip nichts gegen Debugger, auch nichts gegen eine IDE. Aber ich sehe hier zuhauf, daß fast alle Leute, die hier das Wort ergreifen, zu allererst nach einer IDE und einem Debugger rufen. Ganz so, als ob sie ohne dieses keine einzige Zeile richtig zuwege brächten. Also frag nicht mich, sondern zupf dir oder anderen an der Nase. W.S.
W.S. schrieb: > Ich habe bei > der Programmierung dieses Zeugs heftig darauf achten müssen, Toll, oh großer Maestro. Auf einem popeligen Mikrocontroller mit ein paar tausend LoC kann das jeder. Auf einem heutigen Multimedia-System mit 50 MLoC und riesigen Mengen proprietärer extern zugelieferter Software ist es gar nicht so einfach, alle möglichen Sonderfälle in den Griff zu bekommen. W.S. schrieb: > Es ist nur ein Mangel an Wollen oder Denkfaulheit. Schön dass du großer Experte, der nichtmal C im Ansatz beherrscht, so genau weißt was andere Programmierer alles nicht können oder wollen. Und dass sie das hinbekommen sollen ohne dass irgendwie Zeit im Projekt für solche Sonderfälle vorgesehen wurde. W.S. schrieb: > Jeder normale Entwickler würde stattdessen den sicheren > System-Wiederanlauf organisieren. Du warst doch der der davon ausging dass EMI immer brav HardFaults auslöst und nicht subtil einzelne Bits in Registern kippt und daher meint dass das Implementieren von HardFault-Handlern das Programm "sicher" macht, gell? Also halt mal die Füße still.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.