[RANT] Gedanken zu guter Software, KISS und Unixphilosophie

[Athaba]

Hallo,

folgendes wollte ich zuerst in diesen Thread schreiben, allerdings ist das ziemlich OT und ein komplett eigenes Thema. Ich habe das alles sehr generisch geschrieben, weil diese Umstände nicht nur in einem Bereich herrschen. Mir geht es nicht um ein spezielles Problem sondern um grundsätzliche Entwicklungen, die ich beobachtet habe und zu deuten versuche. Auch bilde ich mir keine perfekte (Software)Welt ein. Mir ist durchaus klar, dass die Dinge nie absolut perfekt sein werden. Ich versuche nur das etwas zu abstrahieren um über Ursachen und mögliche Ansätze für Verbesserungen gegenüber der gegenwärtigen Situation nachzudenken.

[Off Topic Rant]Mittlerweile habe ich meine Configs so weit angepasst, dass ich weiß, dass mein altes Setup (wmii/i3 und urxvt) einfacher war. Die XFCE-Konfiguration und vor allem das Anpassen von Scripts ist echt mühsam und mitunter auch ziemlich buggy (ich glaube by design). Da gibt es so viele Workarounds auf die man kennen muss und wer ist auf die abartige Idee gekommen Unix und vor allem GTK-Applikationen mit XML für die Konfiguration auszustatten, wenn normale Key-Value-Files so viel einfacher funktionieren? Toll, dass man alles konfigurieren kann, aber _so_ macht es keinen Spaß. Jede Menge Komplexität ohne irgendeinen Vorteil. Dabei hat das am Anfang alles so schön ausgesehen.[/Off Topic Rant]

Ich frage mich gerade, warum es zu so etwas kommt. Software wird ständig überladener und undurchschaubarer. Es kommen Features hinzu die einfach keine sind, Kompatibilität brechen und der Aufwand für jede kleine Änderung steigt ins unermessliche. Es ist nicht so, dass ich das nicht von mir kenne. Wenn ich etwas programmiere und dabei einfach drauflos hacke, just for fun und ohne eine klare Vorstellungen was dabei raus kommt entsteht genau so etwas. Allerdings habe ich dann weder vor das jemand anderem zuzumuten, noch würde ich mich ernsthaft als Programmierer bezeichnen.

Es ist also eigentlich ungerechtfertigt, wenn ich mich darüber aufrege. Mir geht es aber um's Verständnis. Warum entsteht so etwas? Man muss bedenken, dass man unter Unix ist seit dreißig, vierzig Jahren ganz gut ohne dieses unnötige Übermaß an Komplexität ausgekommen ist. Okay, da gibt es X, aber das ist richtig groß und die ganze Welt hängt dran und muss irgendwie berücksichtigt werden. Ich kann da relativ gut verstehen warum es nicht die perfekte Software ist. Die Interfaces sind allerdings weit besser, als das was man anderswo sieht. In den meisten Fällen kann man außerdem den bewerten Weg gehen, wenn man will und keine allzu komplexen Anwendungen nutzt die unbedingt das neue Zeug brauchen. Außerdem ist das dann nicht mehr wirklich X selbst.

Eine andere Frage, die ich mir stelle ist was aus _simplen_ Standards und Philosophien wird. Warum schaut man sich nicht mehr von Plan 9 ab? Ich rede nicht davon es eins zu eins zu klonen, aber immer wenn es eine gute, einfache Idee gibt heißt es man muss auf die Abwärtskompatibel achten und wenn sie jede Menge Komplexität schafft und vorangegangene und vor allem bewährte zerstört fragt man nicht lange, veröffentlicht das neue (natürlich unfertige) System und sagt, dass man das alte, funktionierende Zeug einfach nicht mehr unterstützt oder behauptet es zwar und ist dabei realitätfern, weil das neue, bessere, weil komplexere dazwischenfunkt. Natürlich gibt es dann noch das Zeug, das einfach ewig lebt und niemand mehr weg bekommt, obwohl es jeder hasst.

Ja, Computer sind komplex, aber es ist ein Unterschied, ob Implementierungen oder Interfaces diese Komplexität aufweisen. Dabei habe ich nichts dagegen, wenn ein Interface vollkommene Macht zum Beispiel in Form von irgendeinem direkten, lowlevel Zugriff hat, aber wenn man eine API hat wo man quasi die Funktionalität selbst programmieren muss warum dann den Aufwand betreiben eine solche Software/Bibliothek/Whatever zu schreiben? Sollten Computer (bzw. die Software, Protokolle und Standards) Dinge nicht einfacher machen?

Auch beobachte ich in letzter Zeit diese "für große, komplexe Projekte"-Mentalität bzw. -Ausrede (ist aber sicherlich austauschbar). Damit wird dann jeder Unsinn gerechtfertigt. Schlechte, komplexe API mit riesigem Aufwand beim Erlernen, Verstehen und Nachvollziehen der Arbeit eines Systems (und das sage ich als Perlfan!) und generell die Tatsache, dass man permanent dazu gezwungen ist mit Kanonen auf Spatzen zu schießen. Da hat man dann irgendein Highlevel-Zeug und denkt sich, dass Assemblycode portabler, wartbarer und vor allem einfacher wäre. Macht man das um künstlich Arbeitsplätze zu schaffen, damit der Programmierer weniger Konkurrenz in seinem Fachgebiet hat, ein Experte sein MUSS und sagen kann dass er solche Unmengen an Code geschrieben hat? Wäre es nicht besser weniger und womöglich langsamer zu tippen und mehr nachzudenken?

Der Gedanke mit den Arbeitsplätzen ist mir kürzlich in einer ähnlichen Diskussion quasi bestätigt worden. Für gewöhnlich werde ich ja früher oder später mit dem "Vorwurf" konfrontiert, dass ich ein Idealist sein. Diesmal war man so nett und hat das begründet. Ich habe keine Ahnung vom Arbeitsmarkt und mit solchen Ansichten kann ich kein Geld verdienen und überleben. Hört sich also so an, als wäre mal wieder das liebe Geld schuld an den Problemen. Ich habe ein wenig darüber nachgedacht und mir fielen einige gute, simple, erfolgreiche Projekte ein - all das was Computer und das Internet erfolgreich gemacht hat. Trotzdem stimmt es wohl. Vieles von diesen Dingen war für den Erfinder oder Entwickler kein kommerzieller Erfolg. Man denke an C, Unix, TCP/IP, HTTP, Xerox, ISC, ...

Klar, viele von denen gelten jetzt als Gurus und können deshalb davon leben, aber eben nicht von ihrer ursprünglichen Leistung. Natürlich musste ich dann recht bald an Open Source denken. Ich will keine konkreten Beispiele nennen, weil vieles einfach Ansichtssache ist, aber jeder kennt doch Projekte, die durch ihre niedrige Komplexität, Portabilität und generell der praktischen Umsetzung der Unixphilosophie bestechen.

Dann frage ich mich ob man als angehender Programmierer einfach lernt schlechte Software zu schreiben. Und was ist dann mit der Software, die einfach das tut was sie tun soll?

Man kann sich ja den Sourcecode ansehen. In diesen Projekten wird nichts sonderlich spezielles gemacht. Jeder Anfänger kann solche Software schreiben. Es ist sogar so, dass ich denke, dass ein Anfänger Software genau so schreiben würde. Ist also ein Übermaß an Erfahrung das Problem? Ich denke nicht, denn viele scheinen sich nach vielen Jahren schlussendlich genau auf dieses Prinzip zu besinnen. Wo kommt also all die unnötige(!) Komplexität ins Spiel und was kann man dagegen tun oder liege ich mit all dem einfach falsch?

Ich bin mir sicher, dass die Meisten von euch wesentlich mehr Ahnung haben. Deshalb würde ich gern eure Meinung zu diesen Dingen lesen.

Gruß,
Athaba

 

[KobRheTilla]

Hinter der Software steht immer ein Mensch (oder einige Menschen). Es gibt keine zwei gleichen Menschen (außer eineiige ...), daher ist die Definition "gute Software" oder auch "einfach zu konfigurieren" für jeden anders.

Das Beispiel mit dem XML als Konfiguration ist sehr gut: Ich persönlich als User finde das auch Scheiße, als Programmierer fallen mir gleich mehrere Vorteile ein: tiefere Strukturen (im Vergleich zu Key-Value) und Validierbarkeit. Dass man dafür aber dann libxml et al braucht oder selbst einen Scanner/Parser baut, um ein Configfile zu lesen ist ein Nachteil, der für mich als Programmierer schon wieder jeden Vorteil auslöscht. Andere denken da anders.

Das Argument mit dem "Assembler für schnellere Programme" ist für mich persönlich keins. Wer seine Software nicht schnell genug bekommt, muss meist hinsichtlich Algorithmen/Datenstrukturen nochmal nachsitzen.

Und hier schließt sich nun auch der Kreis: Gutes Programmieren lernt man nicht einfach so mal schnell im Studium, es zählt die Erfahrung und viel Übung. Ein Großteil der Leute, die OSS "bauen", sind keine sonderlich guten Programmierer, sondern Menschen die ein Problem erkannt haben und eine Lösung suchen.

Rob

 

[Athaba]

Hinter der Software steht immer ein Mensch (oder einige Menschen). Es gibt keine zwei gleichen Menschen (außer eineiige ...), daher ist die Definition "gute Software" oder auch "einfach zu konfigurieren" für jeden anders.

Ja und nein. Ich stimme dir zu, dass man es nicht so einfach und schwarz weiß sehen kann. Aber entweder ein Programm funktioniert und tut das was es tun soll (was dokumentiert ist), ist portabel und schnell genug oder eben nicht. Das ist der Grund warum ich das grundsätzlich und generisch beschrieben habe. Jeder hat andere Vorstellungen. Das sieht man an den vielen Betriebssystemen, Programmiersprachen, etc. die benutzt werden. Das ändert aber nichts daran, dass es Software gibt, die einen Job erledigt und andere die das nicht oder nur mit viel Aufwand tun. Klar sind die Anforderungen nicht immer die Selben, aber wenn eine Software (mehr) Probleme schafft als sie löst ist das Unsinn.

]Das Beispiel mit dem XML als Konfiguration ist sehr gut: Ich persönlich als User finde das auch Scheiße, als Programmierer fallen mir gleich mehrere Vorteile ein: tiefere Strukturen (im Vergleich zu Key-Value) und Validierbarkeit.

Du kannst mit Key-Value auch unendlich tiefe Strukturen abbilden und mit Validierbarkeit meinst du ein Schema?

Dass man dafür aber dann libxml et al braucht oder selbst einen Scanner/Parser baut, um ein Configfile zu lesen ist ein Nachteil, der für mich als Programmierer schon wieder jeden Vorteil auslöscht. Andere denken da anders.

Ich sehe eine lib zu verwenden nicht als Nachteil.

XML hat ein paar lösbare Probleme. Verbosity zum Beispiel. Ein anderer ist das Problem mit den vielen Encodings, was die Portabiltät über verschiedene Anwendungen stark erschweren kann.

Das Argument mit dem "Assembler für schnellere Programme" ist für mich persönlich keins. Wer seine Software nicht schnell genug bekommt, muss meist hinsichtlich Algorithmen/Datenstrukturen nochmal nachsitzen.

Woher hast du das Argument?

Und hier schließt sich nun auch der Kreis: Gutes Programmieren lernt man nicht einfach so mal schnell im Studium, es zählt die Erfahrung und viel Übung. Ein Großteil der Leute, die OSS "bauen", sind keine sonderlich guten Programmierer, sondern Menschen die ein Problem erkannt haben und eine Lösung suchen.

Wenn du das >die OSS "bauen"< wegnimmst stimme ich dir zu. Das Umfeld ist egal und wie ich geschrieben habe sehe ich das nicht als sonderliches Problem, wenn die Dinge entsprechend simpel gehalten werden. Wie schon erwähnt habe ich Perl ganz gern und was die Meisten damit verbinden ist unleserlicher Code. Die Sache ist, dass Perl stark auf Freiheiten setzt und genau hier liegt das Problem. Leute Programmieren in einem ekligen Stil. Das hat unterschiedliche Gründe. Viele kommen von anderen Sprachen und versuchen Perl genau so zu programmieren. In vielen anderen Sprachen ist das wesentlich schwerer, weil alles auf eine bestimmte Art zu Programmieren ausgelegt ist. Wie du oben geschrieben hast sind Leute eben sehr unterschiedlich.

Genau deshalb sind saubere, portable Interfaces wichtig. Die technischen Details sind uninteressant. Ich habe nichts gegen XML, gegen irgendeine Programmiersprache oder eine Philosophie, aber die Dinge müssen zusammenpassen. Die Interfaces, sei es eine GUI, ein API ein Protokoll oder sonst etwas sind in der Praxis essentiell, wenn man mehr als ein einzelnes Stück Software auf einem Computer laufen lässt und abgeschottet ist. Sonst wird es unglaublich schwer weiterzuentwickeln.

Wie gesagt, ich betrachte mich nicht wirklich als Programmierer und deshalb ist das kein Vorwurf sondern einfach nur die Hoffnung, dass man durch den Austausch von Erfahrungen und möglicherweise Ideen Wege findet den gegenwärtigen Zustand bzw. seine eigene Leistung zu verbessern. Ich suche also keine Dogmen, Philosophien oder ähnliches, nur ein paar Ansichten um den Horizont ein kleinwenig zu erweitern.

 

[KobRheTilla]

Das ändert aber nichts daran, dass es Software gibt, die einen Job erledigt und andere die das nicht oder nur mit viel Aufwand tun. Klar sind die Anforderungen nicht immer die Selben, aber wenn eine Software (mehr) Probleme schafft als sie löst ist das Unsinn.

Für den, der die Software gebaut hat, funktioniert sie sicherlich wie gewünscht. Dadrin liegt doch das Problem.

Rob

 

[oenone]

Ich sehe dein Problem nicht... Wenn dir etwas zu bloated ist, nimm doch einfach eine andere kiss-Lösung.

 

[h^2]

Ich verstehe zwar das Grundgefühl, aber ich glaube da mischt sich auch viel "früher war alles besser rein".
Früher hat richtig viel einfach nicht funktioniert. Allein der Hardware-Support ist so unglaublich viel besser geworden. Und warum ist XML für config files schlecht? Mir ist die Syntax eigentlich wumpe, hauptsache ich muss nicht für jedes Programm ne neue Syntax lernen und die Syntax ist parsebar, so dass Klickibuntis front-ends schreiben können, die auch wirklich funktionieren und nicht die Configs kaputtmachen.
Überhaupt ist mangelnde Standardisierung eigentlich das Hauptproblem.
Das war aber früher nicht besser, im Gegenteil. Wenn ich mir überlege, wie wenig Code z.B. KDE und Gnome früher teilten.

Das einzig wirklich negative ist aus meiner Sicht ist, dass viele Projekte, wie die BSDs, aber auch Linux mit anderen Designs mit dem allgemeinen (Ubuntu-)Trend nicht mithalten können, und deswegen von vielen Neuerungen ausgeschlossen sind, bzw. diese teuer erkaufen müssen.

 

[Athaba]

@KobRheTilla: Stimmt grundsätzlich. Es ist nur blöd wenn andere darauf aufbauen müssen.

@oenone: Es wird zunehmend schwerer derartige Alternativen zu finden. Blöd ist es vor allem bei Protokollen, die dann ein ganzes Bündel mit MUST Anforderungen haben, weil die Hauptimplementierung bloated wird. Es ist auch nicht ein Problem, das ich zu lösen versuche, sondern Ansätze die helfen können das zu vermeiden. Ich weiß, es gibt kein allgemeingültiges Prinzip und immer zu forken und zu reimplementieren ist zwar manchmal eine Möglichkeit, aber nicht immer zielführend.

@h^2: Ich weiß nicht wie es früher war, sondern beobachte einen Trend.

Wie gesagt, ich habe nichts gegen XML. Es ist ja gut, weil es vieles vereinheitlicht, was ja das ist was ich will. Nur führt der rigorose und "blinde" Einsatz davon mitunter zu Fehlern. XML ist da ja ein nettes Beispiel. Da sagt man ja, dass es einfach zu parsen ist und wenn mehr als ein Programm darauf zugreift und sich der Programmierer gedacht er baut sich da schnell selbst einen Parser, dann kommt es da schnell mal zu Fehlern, wegen Dingen, wie der Kodierung. Ja, das ist die Schuld des fehlerhaften Parsers, nur ist das in der Praxis gar nicht so selten. Meistens ist es zwar nicht die Kodierung, aber lest euch mal die Security Bulletins durch. Oft sind die Fehler ähnlich banal. Besonders schlimm wird es wenn man XML mit Schemas in verschiedenen und Versionen und XPath hat und dann mal ein wirklich unerwarteter Fehler auftritt. XML ist ja wie der der Name schon sagt erweiterbar und kommt mit einem ganzen Schweif an Spezifikationen. Wenn man die verbindet dann kommt man schnell an einen Punkt wo der Ausnahmefall auftritt, der nicht glatt läuft und an den man nicht gedacht hat. Das führt dann eben zu einem Fall, wo man XML verwendet um die Dinge einfacher zu machen und am Ende ist alles komplexer. Wenn man dann zu spät bemerkt ist es dann auch mal aus mit Kompatibilität oder man muss ein Loch maintainen. Das führt dann zu Forks, Rewrites und man hat neue Software ohne die Erfahrung der alten, die dafür schon viele andere Dinge hat. Seht euch mal DNS, SMTP und HTTP-Server an. Die haben alle einen alten Hasen, der zumindest früher mal einige gravierende Fehler hat und sicherlich Altlasten mit sich schleppt, womöglich auch noch bloated ist, aber bei den Reimplementierungen fehlt dann auch mal was. Das ist aber auch gar nicht das worauf ich hinaus will und XML ist ein sehr schlechtes Beispiel, weil man da so viel beachten kann und muss. Ich dachte mal ich hätte das durchschaut, aber ich glaube nicht, das ich das kann. Deshalb habe ich da eine gewisse Abneigung. Es liegt wohl mehr an mir.

Nehmen wir stattdessen IPC. Da gibt es viele gute Möglichkeiten und Standards. Auswahl ist zwar Toll, aber in diesem Fall ist es einfach viel zu viel. Vor allem wenn es darum geht viele unterschiedliche, eigenständige und simple Programme zu verbinden. Es werden nebenbei auch immer mehr. Selbiges gilt für Markup. Zuerst XML, dann YAML, JSON, etc. Achja und JSON-RPC gibt es mittlerweile auch in einer Reihe von Versionen. Der ganze Sektor der Message-oriented middleware ist undurchschaubar und am Ende kocht jeder sein eigenes Süppchen und findet, das der eigene Ansatz am besten ist. Will man da noch Kompatibilität bewahren muss man selber Bloat erzeugen und es ist aus mit KISS.

 

[Azazyel]

Als Softwareentwickler von Java-Enterprise-Software muss ich meinen Senf dazugeben.

Ich frage mich gerade, warum es zu so etwas kommt. Software wird ständig überladener und undurchschaubarer. Es kommen Features hinzu die einfach keine sind, Kompatibilität brechen und der Aufwand für jede kleine Änderung steigt ins unermessliche.

Hier musst man ganz grob zwei Bereiche unterscheiden:

• Freie Software: Maintenance ist langweilig, die Entwicklung von neuen Sachen interessant. Wenn man das schon in seiner Freizeit macht, muss es Spaß machen.
• Kommerzielle Software: Für "die neue Version ist stabiler und jetzt architektonisch viel sauberer, aber hat keine neuen Features" bewilligt kein Manager beim Kunden ein Upgrade.

Warum entsteht so etwas? Man muss bedenken, dass man unter Unix ist seit dreißig, vierzig Jahren ganz gut ohne dieses unnötige Übermaß an Komplexität ausgekommen ist.

Weil die Anforderungen immer komplexer werden.

Ein Dateisystem wie ZFS mit all seinen fantastischen Features ist nur möglich, wenn man sich auf die damit einhergehende Komplexität einlässt.

In den meisten Fällen kann man außerdem den bewerten Weg gehen, wenn man will und keine allzu komplexen Anwendungen nutzt die unbedingt das neue Zeug brauchen. Außerdem ist das dann nicht mehr wirklich X selbst.

Wenn man einfache Probleme hat, reichen auch einfache Lösungen.
Wenn man aber schwierige Probleme hat, was dann?

Eine andere Frage, die ich mir stelle ist was aus _simplen_ Standards und Philosophien wird. Warum schaut man sich nicht mehr von Plan 9 ab?

Das Gute ist der Feind des Besseren.
Warum viel Aufwand in eine bessere Lösung stecken, wenn die vorhandene Lösung gut genug ist?

Ich rede nicht davon es eins zu eins zu klonen, aber immer wenn es eine gute, einfache Idee gibt heißt es man muss auf die Abwärtskompatibel achten und wenn sie jede Menge Komplexität schafft und vorangegangene und vor allem bewährte zerstört fragt man nicht lange, veröffentlicht das neue (natürlich unfertige) System und sagt, dass man das alte, funktionierende Zeug einfach nicht mehr unterstützt oder behauptet es zwar und ist dabei realitätfern, weil das neue, bessere, weil komplexere dazwischenfunkt.

Jeder Softwareentwickler möchte auf der grünen Wiese anfangen und nicht alten Code pflegen.

Wenn man als Entwickler - wie so oft im Bereich freie Software - keine "richtigen" Kunden hat, wählt man halt im Zweifelsfalle die interessantere Altenative: man schmeißt das alte Zeug weg und fängt neu an.

Ja, Computer sind komplex, aber es ist ein Unterschied, ob Implementierungen oder Interfaces diese Komplexität aufweisen.

An dieser Stelle kann ich nur auf den Klassiker worse is better verweisen.
Es gutes Interface ist wesentlich mehr Arbeit als eine gute Implementierung, erfordert viel Erfahrung und dementsprechend sehen viele Interfaces auch aus.

Frederick Brooks hat schon 1975 (sic!) in seinem Buch The Mythical Man-Month (Pflichtlektüre für jeden Softwareentwickler, der in einem Projekt arbeitet) auf diesen Umstand (und viele andere) hingewiesen.

Sollten Computer (bzw. die Software, Protokolle und Standards) Dinge nicht einfacher machen?

So einfach wie möglich, aber nicht einfacher!

Auch beobachte ich in letzter Zeit diese "für große, komplexe Projekte"-Mentalität bzw. -Ausrede (ist aber sicherlich austauschbar). Damit wird dann jeder Unsinn gerechtfertigt.

In diesem Punkt muss ich dir recht geben, das Overengineering ist in der IT sehr verbreitet.

Da hat man dann irgendein Highlevel-Zeug und denkt sich, dass Assemblycode portabler, wartbarer und vor allem einfacher wäre.

Grundsätzlich gilt: man kann mit jeder Programmiersprache Mist schreiben.
Wenn jemand aber ein Problem nicht einmal mit "Highlevel-Zeug" lösen kann, möchte ich erst recht nicht dessen Assembler-Code sehen.

Wäre es nicht besser weniger und womöglich langsamer zu tippen und mehr nachzudenken?

Was ist besser:

• eine gute Lösung, die etwas mehr Code braucht, nicht so elegant, aber fertig ist
• eine perfekte Lösung, bis zu deren Fertigstellung sich die Anforderungen schon längst geändert haben

Diesmal war man so nett und hat das begründet. Ich habe keine Ahnung vom Arbeitsmarkt und mit solchen Ansichten kann ich kein Geld verdienen und überleben.

Jemand erzählt dir etwas über die Wirkung von Alkohol, hat aber noch nie welchen getrunken.
Jemand erzählt dir etwas über das Autofahren, saß aber noch nie am Steuer.
Jemand erzählt dir etwas über Softwareentwicklung, hat aber noch nie in einem Projekt gearbeitet.

Hört sich also so an, als wäre mal wieder das liebe Geld schuld an den Problemen.

Die wenigsten Kunden können und wollen Perfektionismus bezahlen.

Wenn du noch die üblichen Eigenheiten von kleinen wie großen Projekten (Bürokratie, Politik, etc.) hinzurechnest, ist es manchmal erstaunlich, dass am Ende überhaupt lauffähige Software herauskommt.

Ich habe ein wenig darüber nachgedacht und mir fielen einige gute, simple, erfolgreiche Projekte ein - all das was Computer und das Internet erfolgreich gemacht hat. Trotzdem stimmt es wohl. Vieles von diesen Dingen war für den Erfinder oder Entwickler kein kommerzieller Erfolg. Man denke an C, Unix, TCP/IP, HTTP, Xerox, ISC, ...

Hmm, fast alles wurde an Universitäten oder beim Militär entwickelt. Beides sind Bereiche, in denen man die wichtigste Resource - Zeit - in praktisch unbegrenztem Maße hat und unabhängig vom Erfolg dafür bezahlt wird.

Klar, viele von denen gelten jetzt als Gurus und können deshalb davon leben, aber eben nicht von ihrer ursprünglichen Leistung.

Ein Musiker kann auch ein fantastisches Album hervorbringen, davon leben muss er deswegen noch lange nicht können.

Ich habe auch erst den Praxisschock gebraucht, bis ich realisiert habe, dass die Kommerzialisierung einer tollen Software auch ein verdammt hartes Stück Arbeit ist.
Kunden wollen für ihr Geld nämlich auch noch so Sachen wie Support, Dokumentation, Schulungen und vieles mehr; mit der Software alleine ist es in den wenigsten Fällen getan.
Von Kleinigkeiten wie Buchhaltung, Marketing und vielen anderen Dingen mal ganz abgesehen...

Natürlich musste ich dann recht bald an Open Source denken. Ich will keine konkreten Beispiele nennen, weil vieles einfach Ansichtssache ist, aber jeder kennt doch Projekte, die durch ihre niedrige Komplexität, Portabilität und generell der praktischen Umsetzung der Unixphilosophie bestechen.

Korrekt - nicht jeder ist aber ein Donald Knuth und bekommt mal eben ein Jahr bezahlten Urlaub, um ein Projekt seines persönlichen Interesses zu verfolgen.

Dann frage ich mich ob man als angehender Programmierer einfach lernt schlechte Software zu schreiben.

Softwareentwicklung erfordert (nebst viel Talent) auch viel Erfahrung, die nicht von alleine kommt. Anfänger machen Anfängerfehler.

Und was ist dann mit der Software, die einfach das tut was sie tun soll?

Alle simplen Aufgaben sind schon gelöst.

Was jetzt noch übrig bleibt, sind die komplexen Themen und Aufgaben, die sich nicht mehr mit simplen Programmen lösen lassen. Dabei lässt es sich nicht vermeiden, dass man ab und zu den Überblick verliert, sich verrennt oder eine Lösung sich erst nach der Implementierung als unzulänglich erweist.

Man kann sich ja den Sourcecode ansehen. In diesen Projekten wird nichts sonderlich spezielles gemacht. Jeder Anfänger kann solche Software schreiben. Es ist sogar so, dass ich denke, dass ein Anfänger Software genau so schreiben würde.

Es gibt viele Entwickler freier Software, die mit zuviel Idealismus und Naivität und zuwenig Erfahrung ein Projekt entwickelt haben - und sich in einer einfachen Aufgabe verrannt haben.
Die keinen Gedanken an Kommentare im Quellcode verschwenden, weil sie selbst ja ihren Quellcode verstehen.
Die auch nicht einsehen, dass ihr Quellcode schlecht ist. Mehr möchte sich schon die eigene Unzulänglichkeit eingestehen?

Im "bezahlten" Umfeld gibt es einfach viele Leute, die ohne Interesse an der Materie in dem Job gelandet sind (z.B. beim New-Economy-Boom), und jetzt ohne massive finanzielle Einbußen ihre berufliche Laufbahn nicht mehr ändern können.

Ist also ein Übermaß an Erfahrung das Problem?

Es gibt zwar den second-system effect, den lässt man aber im Normalfall nach ein paar Jahren hinter sich. Viele Entwickler haben auch irgendwann das Lernen aufgehört, aber die entwickeln normalerweise keine freie Software.

Ich denke nicht, denn viele scheinen sich nach vielen Jahren schlussendlich genau auf dieses Prinzip zu besinnen. Wo kommt also all die unnötige(!) Komplexität ins Spiel und was kann man dagegen tun oder liege ich mit all dem einfach falsch?

Man braucht viel Erfahrung und Know-How, um für komplexe Probleme einfache Lösungen zu finden.
Ansonsten ist es wie beim Fußball: mit Bier und Chips vorm Fernseher sieht die Angelegenheit immer ganz einfach aus.

Ich bin mir sicher, dass die Meisten von euch wesentlich mehr Ahnung haben. Deshalb würde ich gern eure Meinung zu diesen Dingen lesen.

Erstmal möchte ich sehr positiv anmerken, dass du deine Gedanken bemerkenswert zurückhaltend für einen "Idealisten" formuliert hast. Manch anderer Zeitgenosse hier im Forum hat noch keine einzige Zeile produktiven Quellcode geschrieben, sieht sich aber schon in einer Riege mit Ken Thompson, Dennis Ritchie und Brian Kernighan.

Ich habe genauso gedacht wie du, bis ich meinen ersten Praxisschock hinter mir hatte.
Wenn also "alte Hasen" idealistischen Vorstellungen widersprechen, wollen sie damit niemanden den Tag verderben.

Aus ihnen spricht einfach die Erfahrung, wie groß der Unterschied zwischen einem pet project und einem Projekt in der realen Welt, in dem man unter teils widrigen Umständen mit begrenzten Mitteln und ständig wechselnden Anforderungen unter Zeitdruck komplexe Probleme löst.

 

[Kamikaze]

Wenn du noch die üblichen Eigenheiten von kleinen wie großen Projekten (Bürokratie, Politik, etc.) hinzurechnest, ist es manchmal erstaunlich, dass am Ende überhaupt lauffähige Software herauskommt.

Über die Hälfte der Softwareprojekte scheitern doch, zumindest war das vor ein paar Jahren so: http://projekte.pentaeder.de/?p=35

 

[Athaba]

Vielen Dank, Azazyel. Vor allem der Lesestoff ist interessant.

Als Softwareentwickler von Java-Enterprise-Software muss ich meinen Senf dazugeben.

Da habe ich ja den richtigen erwischt.

Hier musst man ganz grob zwei Bereiche unterscheiden:

• Freie Software: Maintenance ist langweilig, die Entwicklung von neuen Sachen interessant. Wenn man das schon in seiner Freizeit macht, muss es Spaß machen.
• Kommerzielle Software: Für "die neue Version ist stabiler und jetzt architektonisch viel sauberer, aber hat keine neuen Features" bewilligt kein Manager beim Kunden ein Upgrade.

Aber so wie ich das sehe kann man den Aufwand häufig durch verkleinern von Software, die dann zusammenarbeitet vereinfachen. Ja, ich gebe zu, ich habe mich ein wenig mit Leopold Kohr's Philosophie beschäftigt, aber das auch in der Praxis ausprobiert. Im Grund ist das ja auch das Konzept von objektorientierter Programmierung, zumindest so wie es ursprünglich (und damit meine ich, wie in Smalltalk) gedacht war. Man zerlegt Software in kleine überschaubare Teile. Klar muss man sich dabei auch was denken, sonst bleibt es trotzdem komplex. Aber in Unix ist das ja mit den meisten Befehlen auch so. Die verbindet man dann zum Beispiel mit einer Pipe. Das ist doch ähnlich, wie wenn man Objekte zusammenarbeiten lässt.

Ein Dateisystem wie ZFS mit all seinen fantastischen Features ist nur möglich, wenn man sich auf die damit einhergehende Komplexität einlässt.

Ich war zwar ziemlich früh damit dran von ZFS begeistert zu sein, weil ich über eine Präsentation gestolpert bin, aber ich habe mich schon ewig nicht mehr damit beschäftigt. Aber soweit ich mich erinnre sind die Interfaces nicht komplexer als bei anderen Dateisystemen. Bei Hammer sind sowohl Implementierung und Interfaces glaube ich noch ein wenig Einfacher, dafür gibt es Dinge, die es einfach (noch) nicht kann. Aber ich überschaue keines der beiden Projekte, also nicht hauen wenn ich daneben liege.

Wenn man einfache Probleme hat, reichen auch einfache Lösungen.
Wenn man aber schwierige Probleme hat, was dann?

Die Dinge kleiner machen aka modularisieren. Für mich hat es gut funktioniert, aber mir fehlt eindeutig praktische Erfahrung.

Ich weiß, das kann ein enormes Problem werden, wenn sich das Interface ändert und dann vieles nicht mehr zusammenarbeitet aber das ist ja genau der Grund warum ich die ganze Zeit davon rede sie einfach zu halten.

Das Gute ist der Feind des Besseren.
Warum viel Aufwand in eine bessere Lösung stecken, wenn die vorhandene Lösung gut genug ist?

Vieles ist schon da, wurde lange Zeit getestet und auf Unix portiert, aber teilweise wird das Rad neu erfunden. Gerade weil Open Source (ich kann einfach nicht über den kommerziellen Bereich reden) häufig in der Freizeit entwickelt wird denke ich nicht, dass es sinnvoll ist über die investierte Erfahrung hinwegzusehen. Ich beobachte ja das ja auch an Perl. Das praktisch eine der ersten Skriptsprachen und dementsprechend wurde viel von Python, Ruby und anderen aufgegriffen. Man kann richtig verfolgen, wie die selben Probleme zuerst von Python und dann von Ruby neu gelöst werden mussten. Ich nehme an, dass sie besser gelöst wurden, weil man aus Fehlern anderer lernen kann und weil sich einfach viel geändert hat und häufig neue Methoden zur Verfügung stehen, aber man stolpert immer mal wieder über etwas und man kann ganz eindeutig nachvollziehen das der Grund das Alter der Software ist. Es war einfach mehr Zeit da in der Probleme ausgebügelt werden konnten, aber auch Bibliotheken entstanden sind. Der neuste Hype ist ja Node.js. Die haben den Vorteil, das zum einen JavaScript schon ein gewisses Alter haben und zum Anderen, dass der Einsatzzweck in den allermeisten Fällen Webentwicklung ist. Die haben quasi alles aus der Perl/Python/Ruyb-Welt extrem schnell übernommen und geben in diesem Bereich die Richtung vor. Es ist also keineswegs so, dass ich dafür bin auf altes zu setzen, aber wenn die Dinge modular sind und schöne Interfaces haben dann kann man sie zusammen verwenden und Vorteile aller Systeme genießen. Gerade in der Open Source Welt ist es schade, wenn jemand mit Enthusiasmus etwas komplett neues entwickelt (im kommerziellen Bereich hat man den Nachteil, das andere Kräfte treibend sind und man wohl nicht so risikobereit ist) und dann profitiert niemand davon, weil es ein eigenes, komplexes oder kaum verbreites Interface verwendet.

Das World Wide Web ist da ziemlich gut dran, weil jeder HTTP spricht. Ich frage mich wie sich das mit Websockets noch so entwickelt.

Jeder Softwareentwickler möchte auf der grünen Wiese anfangen und nicht alten Code pflegen.

Aber es ist doch schön auf ausgereifte Bibliotheken zurückgreifen zu können. Wenn man etwas neues programmiert will man sich damit beschäftigen und nicht mit einer Transportschicht oder wie man Konfigurationsdateien ausliest und schreibt.

An dieser Stelle kann ich nur auf den Klassiker worse is better verweisen.
Es gutes Interface ist wesentlich mehr Arbeit als eine gute Implementierung, erfordert viel Erfahrung und dementsprechend sehen viele Interfaces auch aus.

Kenne ich bereits.

Frederick Brooks hat schon 1975 (sic!) in seinem Buch The Mythical Man-Month (Pflichtlektüre für jeden Softwareentwickler, der in einem Projekt arbeitet) auf diesen Umstand (und viele andere) hingewiesen.

Werde ich lesen.

So einfach wie möglich, aber nicht einfacher!

Mir fällt das in der Webentwicklung auf. Zuerst war Rails und dann Sinatra. Häufig sagt man dann Sinatra ist für kleine und Rails für große Projekte. Natürlich gibt es beides auch schon für quasi jede andere Programmiersprache. Viele sind der Meinung ihr Projekt ist groß, obwohl es das nicht ist. In der Perlwelt gibt es dann noch Mojolicious, was den Vorteil hat, dass man fließend von Microframework zum großen Wechseln kann. Das ist nur ein Beispiel, wo man die Dinge falsch einschätzt und wie oben geschrieben mit Kanonen auf Spatzen schießt. Das selbe sehe ich auch im OO-Bereich. Man braucht für ein kleines Script keine drei Objekte, die sich aller Mittel von OO Bedienen. Das erinnert an die Literatur, wo man eine Zeit lang versucht hat in jeden Text so viele rhetorische Figuren zu stecken wie nur möglich. Nur weil man es machen kann heißt es ja nicht das man es muss. Es wird dann ab und an behauptet, dass man das man nicht wissen kann was daraus wird, aber zum einen kann man gut strukturierten Code (und das will man ja mit OO erreichen) einfach in ein Objekt umwandeln und zum Anderen wundert es mich da wie man das überhaupt richtig einsetzen kann, wenn man sich offensichtlich kaum Gedanken dazu gemacht hat. Das sage ich als jemand, der sich stark für Modularisierung ausspricht.

Was ist besser:

• eine gute Lösung, die etwas mehr Code braucht, nicht so elegant, aber fertig ist
• eine perfekte Lösung, bis zu deren Fertigstellung sich die Anforderungen schon längst geändert haben

Ein Lösung, die sich mit der Zeit vom ersten zum Zweiten entwickelt. Es gibt ja auch viele die Prototyping betreiben. Die erste Lösung macht es einfacher die Zweite zu implementieren. Nein ich, will nicht, dass man alles zweimal baut, aber Software entwickelt sich. Ich weiß schon was du meinst, aber wenn es so lange dauert sollte man sich Fragen, ob man das Projekt vielleicht ein wenig modularisieren kann. Klar, das geht nicht überall so einfach und ist nicht immer die grundlegende Ursache. Es kommt aber sehr auf die Umstände an. Klar würde ich mit der ersten Lösung anfangen, aber wenn sich die Anforderungen so stark ändern, dann will man ja wohl ohnehin eine Quick & Dirty Lösung. Ja, ich winde mich, aber mir fällt jetzt auch kein Beispiel ein an dem mir die Frage stellen kann.

Jemand erzählt dir etwas über die Wirkung von Alkohol, hat aber noch nie welchen getrunken.
Jemand erzählt dir etwas über das Autofahren, saß aber noch nie am Steuer.
Jemand erzählt dir etwas über Softwareentwicklung, hat aber noch nie in einem Projekt gearbeitet.

Ist es fies wenn ich sage, dass das ein Java-Programmierer war und ich mir nicht vorstellen kann, dass man das freiwillig nimmt?

Vielleicht hast du recht, aber ich stelle mir häufig die Frage, wie ein Arbeit- oder Auftragsgeber den Unterschied erkennt. Der kann den Aufwand der Arbeit ja häufig wirklich nicht nur an Codezeilen bewerten.

Die wenigsten Kunden können und wollen Perfektionismus bezahlen.

Leider.

Hmm, fast alles wurde an Universitäten oder beim Militär entwickelt. Beides sind Bereiche, in denen man die wichtigste Resource - Zeit - in praktisch unbegrenztem Maße hat und unabhängig vom Erfolg dafür bezahlt wird.

Das Militär hört sich nach einem tollen Arbeitgeber an.

Softwareentwicklung erfordert (nebst viel Talent) auch viel Erfahrung, die nicht von alleine kommt. Anfänger machen Anfängerfehler.

Das ist ja eigentlich nicht schlimm, aber manchmal habe ich das Gefühl, dass Leute darauf gedrillt werden alles auf eine Art zu machen. Tausend Objekte, XML für alles, MySQL ist die einzige andere Form Daten zu speichern, ...

Das hört sich für mich nach einem schönen künstlichen Umfeld für Prüfungen an.

Alle simplen Aufgaben sind schon gelöst.

Aber die wenigsten Aufgaben sind simpel gelöst.

[QUOZE]Was jetzt noch übrig bleibt, sind die komplexen Themen und Aufgaben, die sich nicht mehr mit simplen Programmen lösen lassen. Dabei lässt es sich nicht vermeiden, dass man ab und zu den Überblick verliert, sich verrennt oder eine Lösung sich erst nach der Implementierung als unzulänglich erweist.[/QUOTE]
Aber viele scheinen experimentieren und Fehler eingestehen als falschen Ansatz anzusehen. Hat das was mit dem "die eigene Arbeit verteidigen" zu tun? Ich weiß echt zu wenig darüber, wie Informatiker ausgebildet werden. Ich habe nie wirklich Unterricht in Informatik gehabt, nur eine Art Abschlussprüfung und danach ein nettes, aufschlussreiches Gespräch mit dem Prüfer weil ich mehr darüber wissen wollte.

Es gibt viele Entwickler freier Software, die mit zuviel Idealismus und Naivität und zuwenig Erfahrung ein Projekt entwickelt haben - und sich in einer einfachen Aufgabe verrannt haben.
Die keinen Gedanken an Kommentare im Quellcode verschwenden, weil sie selbst ja ihren Quellcode verstehen.
Die auch nicht einsehen, dass ihr Quellcode schlecht ist. Mehr möchte sich schon die eigene Unzulänglichkeit eingestehen?

Irgendjemand hat mal gesagt, dass man sich selbst verstehen muss um die Welt zu verstehen.

Es gibt zwar den second-system effect, den lässt man aber im Normalfall nach ein paar Jahren hinter sich. Viele Entwickler haben auch irgendwann das Lernen aufgehört, aber die entwickeln normalerweise keine freie Software.

Ich weiß zwar, dass meine Neugierde und mein Enthusiasmus sinkt (deshalb habe ich Zeit Rants zu schreiben ), aber ich wüsste nicht was ich machen würde wenn ich aufhören würde zu lernen. Da würde ich glaube ich Depressionen bekommen.

Man braucht viel Erfahrung und Know-How, um für komplexe Probleme einfache Lösungen zu finden.
Ansonsten ist es wie beim Fußball: mit Bier und Chips vorm Fernseher sieht die Angelegenheit immer ganz einfach aus.

Okay um das zu wissen habe ich wohl genug Erfahrung, aber deshalb der Thread. Ich will Lösungsansätze. Wenn ich mehr weiß und vor allem andere Perspektiven kenne werden die Dinge für gewöhnlich einfacher.

Erstmal möchte ich sehr positiv anmerken, dass du deine Gedanken bemerkenswert zurückhaltend für einen "Idealisten" formuliert hast. Manch anderer Zeitgenosse hier im Forum hat noch keine einzige Zeile produktiven Quellcode geschrieben, sieht sich aber schon in einer Riege mit Ken Thompson, Dennis Ritchie und Brian Kernighan.

Danke.

Aber die meisten in diesem Forum sind auch deutlich mehr Ken Thompson, als ich. Ich baue nur viele kleine Skripte und bin zu feige sie auf GitHub zu laden.

Ich habe genauso gedacht wie du, bis ich meinen ersten Praxisschock hinter mir hatte.
Wenn also "alte Hasen" idealistischen Vorstellungen widersprechen, wollen sie damit niemanden den Tag verderben.

Wenn ich nicht genau das wollen würde würde ich sie für mich behalten. Man tut sich einfach schwerer seine eigenen Fehler zu sehen, als die von Anderen. Aus Kritiken und anderen Perspektiven kann man viel lernen und häufig ist das ein richtiger Motivationsschub, wenn man die Dinge in der Praxis beweisen oder widerlegen will.

Aus ihnen spricht einfach die Erfahrung, wie groß der Unterschied zwischen einem pet project und einem Projekt in der realen Welt, in dem man unter teils widrigen Umständen mit begrenzten Mitteln und ständig wechselnden Anforderungen unter Zeitdruck komplexe Probleme löst.

Aber viele _große_ Sachen haben sich aus Pet Projects entwickelt. Da ist die Motivation (das Video ist genial!) eine ganz andere.

Danke nochmal für die Antwort.

EDIT: Ich bin gerade über ein nettes Zitat von Doug Horton gestolpert.
“The art of simplicity is a puzzle of complexity.”

 

[Azazyel]

Aber so wie ich das sehe kann man den Aufwand häufig durch verkleinern von Software, die dann zusammenarbeitet vereinfachen. Ja, ich gebe zu, ich habe mich ein wenig mit Leopold Kohr's Philosophie beschäftigt, aber das auch in der Praxis ausprobiert.

Ich bin auch ein Freund des "small is beautiful", aber man sollte die Möglichkeiten des Großen nicht unterschätzen.

Im Grund ist das ja auch das Konzept von objektorientierter Programmierung, zumindest so wie es ursprünglich (und damit meine ich, wie in Smalltalk) gedacht war. Man zerlegt Software in kleine überschaubare Teile. Klar muss man sich dabei auch was denken, sonst bleibt es trotzdem komplex.

Wenn ich zu viele kleine und überschaubare Teile habe, verlagere ich die Komplexität in die Kommunikation zwischen diesen Teilen.
Manchmal ist es einfach besser, ein etwas "fetteres" Modul zu erstellen, um im großen Ganzen weniger Komplexität in der Kommunikation zwischen diesen Modulen zu haben.

Ein schöner Vergleich ist die ewige Diskussion um monolithische gegen Mikrokernel. In der Theorie ist der Mikrokernel die bessere Lösung, in der Praxis ist jedes nennenswerte Betriebssystem auf Erden aus gutem Grund monolithisch.

Aber in Unix ist das ja mit den meisten Befehlen auch so. Die verbindet man dann zum Beispiel mit einer Pipe. Das ist doch ähnlich, wie wenn man Objekte zusammenarbeiten lässt.

Das nennt sich in der Softwareentwicklung pipes and filter und wird recht häufig eingesetzt. Es eignet sich aber nur für eine begrenze Menge an Problemen, weil in vielen Fällen das erste Programm der Kette den Output eines der nachfolgenden Programme braucht.

Ich war zwar ziemlich früh damit dran von ZFS begeistert zu sein, weil ich über eine Präsentation gestolpert bin, aber ich habe mich schon ewig nicht mehr damit beschäftigt. Aber soweit ich mich erinnre sind die Interfaces nicht komplexer als bei anderen Dateisystemen.

Für den Anwender ist ZFS sehr einfach.
Unter der Haube ist ZFS eine grobe Verletzung der Schichtenarchitektur, es ist:

1. RAID
2. Volume Manager
3. Dateisystem

in einem. In der Theorie ist es also eine beschissene Lösung, in der Praxis ist es gerade deswegen das Nonplusultra.

Bei Hammer sind sowohl Implementierung und Interfaces glaube ich noch ein wenig Einfacher, dafür gibt es Dinge, die es einfach (noch) nicht kann.

Abwarten und Tee trinken. Gerade bei Dateisystemen hatten wir schon viele Kandidaten, die in der Theorie fantastisch waren, aber bei der Umsetzung in die Praxis sich als untauglich erwiesen haben.

Ich weiß, das kann ein enormes Problem werden, wenn sich das Interface ändert und dann vieles nicht mehr zusammenarbeitet aber das ist ja genau der Grund warum ich die ganze Zeit davon rede sie einfach zu halten.

Man kann Interfaces nicht beliebig einfach halten.

Nimm als Beispiel die Desktop-Integration eines Windows oder Mac OS X (bitte keine Diskussionen über die Notwendigkeit derselbigen). Wenn ich diese Funktionalitäten haben möchte, muss ich auch die Interfaces (API, nicht User) komplizierter machen - und sei es, dass ich mehr Interfaces brauche.
Man ist natürlich trotzdem bestrebt, sie so einfach wie möglich zu machen, aber es gibt einfach Grenzen.

Gerade in der Open Source Welt ist es schade, wenn jemand mit Enthusiasmus etwas komplett neues entwickelt (im kommerziellen Bereich hat man den Nachteil, das andere Kräfte treibend sind und man wohl nicht so risikobereit ist) und dann profitiert niemand davon, weil es ein eigenes, komplexes oder kaum verbreites Interface verwendet.

Open-Source-Entwickler sind auch nur Menschen, die von "ihrem Baby" überzeugt sind und meinen, sie könnten es besser als die anderen.
Das ist auf der einen Seite schade, auf der anderen gäbe es ohne diese Einstellung keinen Fortschritt.

Aber es ist doch schön auf ausgereifte Bibliotheken zurückgreifen zu können. Wenn man etwas neues programmiert will man sich damit beschäftigen und nicht mit einer Transportschicht oder wie man Konfigurationsdateien ausliest und schreibt.

Einer der Gründe für den enormen Erfolg von Java.

Ist es fies wenn ich sage, dass das ein Java-Programmierer war und ich mir nicht vorstellen kann, dass man das freiwillig nimmt?

Java (die Programmiersprache) hat viele hässliche Seiten (von denen ich viel zu viele aus eigener Erfahrung kenne), es gibt wesentlich schönere Sprachen (Python, Ruby, auch C#, etc.).

Java (die Platform) ist momentan die wohl beste Umgebung für Softwareentwicklung für Herausforderungen der realen Welt. Die Nachteile der Sprache (die allesamt bekannt und keine Überraschungen mehr sind) werden durch die enorme Menge an Vorteilen mehr als ausgeglichen.

Es gibt natürlich auch Bereiche, in denen Java nicht das Mittel der Wahl ist (z.B. embedded systems), aber Diskussionen hierzu würde ich in einen eigenen Thread auslagern.

Vielleicht hast du recht, aber ich stelle mir häufig die Frage, wie ein Arbeit- oder Auftragsgeber den Unterschied erkennt. Der kann den Aufwand der Arbeit ja häufig wirklich nicht nur an Codezeilen bewerten.

Dem Auftraggeber ist es im Normalfall vollkommen egal. Der möchte Software haben, die sein Problem zu einem vertretbaren Preis löst. Wie die Lösung unter der Haube aussieht, ist eher sekundär.
Solange ein Auto fährt und keine Zicken macht, ist es den meisten Leuten ja auch egal, wie elegant das Auto konstruiert ist.

Das Militär hört sich nach einem tollen Arbeitgeber an.

Wenn du auf Technik von vor 30 Jahren, unglaublich viel Bürokratie, Politik und Formularkriege stehst, bestimmt.

Das ist ja eigentlich nicht schlimm, aber manchmal habe ich das Gefühl, dass Leute darauf gedrillt werden alles auf eine Art zu machen. Tausend Objekte, XML für alles, MySQL ist die einzige andere Form Daten zu speichern, ...

Warum das Rad neu erfinden und eine Lösung einsetzen, die sich in der Praxis erst bewähren muss?
MySQL und XML sind in vielen Fällen nicht die beste Lösung, aber

• jeder kennt sie
• sie funktionieren gut genug
• es gibt massig Support

Also warum viel Aufwand in Dinge stecken, die mit der eigentlich Problemlösung nichts zu tun haben, wenn ich vorher nicht weiß, ob man es besser kann?

Aber viele scheinen experimentieren und Fehler eingestehen als falschen Ansatz anzusehen. Hat das was mit dem "die eigene Arbeit verteidigen" zu tun?

Keiner möchte als Idiot dastehen, selbst wenn man einer ist.
In vielen Bereichen kommt dazu, dass es sehr negative Konsequenzen haben kann, wenn man "der Schuldige" ist. Wenn ein Projekt scheitert, möchte niemand der Sündenbock sein.

Ich weiß echt zu wenig darüber, wie Informatiker ausgebildet werden. Ich habe nie wirklich Unterricht in Informatik gehabt, nur eine Art Abschlussprüfung und danach ein nettes, aufschlussreiches Gespräch mit dem Prüfer weil ich mehr darüber wissen wollte.

Kommt auf die Ausbildung an.

Informatik (fast reine Mathematik) hat per se mit Softwareentwicklung (eher Handwerk) erstmal wenig zu tun (insbesondere an der Uni). Ein Studium des "Software Engineering" gibt es schon (vor allem im anglo-amerikanischen Raum), ist aber auch extrem theorielastig.
Fachinformatiker für Anwendungsentwicklung (IHK) lernen bestenfalls die Grundlagen. Wenn der Betrieb seine Aufgabe gut macht, kriegt man aber schon einiges mit.
Daneben gibt es noch eine Reihe anderer Ausbildungen, die den Rahmen hier sprengen würden.

Unabhängig von der Ausbildung ist Experimentieren und das Lesen von Büchern, Artikeln und fremden Quellcode das A und O.

Am meisten lernt man aber in der Praxis, wenn man in einem kommerziellen Projekt mitarbeitet und mit realen Problemen konfrontiert ist. Das lässt sich durch nichts ersetzen.

Ich weiß zwar, dass meine Neugierde und mein Enthusiasmus sinkt (deshalb habe ich Zeit Rants zu schreiben ), aber ich wüsste nicht was ich machen würde wenn ich aufhören würde zu lernen. Da würde ich glaube ich Depressionen bekommen.

Dito. Man darf aber vor lauter Enthusiasmus nicht vergessen, dass sich die Theorie an die Praxis anpassen muss, nicht umgekehrt.

Okay um das zu wissen habe ich wohl genug Erfahrung, aber deshalb der Thread. Ich will Lösungsansätze. Wenn ich mehr weiß und vor allem andere Perspektiven kenne werden die Dinge für gewöhnlich einfacher.

Je mehr man weiß, desto besser. Es gibt aber in der Softwareentwicklung keinen Silver Bullet, der unsere Probleme löst - auch wenn viele Firmen mit dem Versprechen desselbigen viel Geld verdienen.

Aus Kritiken und anderen Perspektiven kann man viel lernen und häufig ist das ein richtiger Motivationsschub, wenn man die Dinge in der Praxis beweisen oder widerlegen will.

Deswegen bin ich dazu übergegangen, in der Softwareentwicklung weniger auf die Theoretiker zu geben. Entscheidend sind die Dinge, die in der Praxis funktionieren. Der Rest ist Trockenwichsen.

Aber viele _große_ Sachen haben sich aus Pet Projects entwickelt.

Ich möchte Pet Projects nicht kleinreden, ganz im Gegenteil! Sie sind extrem wichtig, um zu experimentieren, zu lernen, seinen Horizont zu erweitern.
Man darf nur nicht den Fehler machen, die Rahmenbedingungen seiner Pet Projects (eine Person, ein Rechner, kein Geld- oder Zeitdruck, etc.) zu extrapolieren und zu glauben, dass es in der realen Welt genauso funktioniert.

Da ist die Motivation (das Video ist genial!) eine ganz andere.

Das Video kenne ich und kann ich nur bestätigen.

 

[Athaba]

Das nennt sich in der Softwareentwicklung pipes and filter und wird recht häufig eingesetzt. Es eignet sich aber nur für eine begrenze Menge an Problemen, weil in vielen Fällen das erste Programm der Kette den Output eines der nachfolgenden Programme braucht.

Dann verwende ich eben etwas anderes, als eine Pipe. Ein Socket oder ein High Level Protokoll, ist doch egal was. Nur warum man manche Dinge ständig neu erfinden muss verstehe ich nicht.

Für den Anwender ist ZFS sehr einfach.
Unter der Haube ist ZFS eine grobe Verletzung der Schichtenarchitektur, es ist:

1. RAID
2. Volume Manager
3. Dateisystem

in einem. In der Theorie ist es also eine beschissene Lösung, in der Praxis ist es gerade deswegen das Nonplusultra.

Stimmt das? Ist es wirklich die Verletzung die Schichtenarchitektur, die es so zum Nonplusultra macht (für das ich es genauso wenig halte wie jede andere Software)? Ich glaube nicht, dass es allzu lange dauert bis der Filesystemhype von neuem beginnt und jeder sein ZFS ersetzen will. Verstehe mich nicht falsch, ich will nicht sagen das ZFS schlecht ist, ganz im Gegenteil ich bin ein großer Fan davon, aber das was du behauptest sehe ich nicht wirklich als bewiesen an.

Bleibt ZFS nicht trotzdem relativ einfach anzusprechen? Ob du das für die genannten Layers einzeln tust oder ob du was auch immer du tun willst direkt an ZFS übergibst macht ja keinen sonderlich großen Unterschied. Das ist einfach nur eine Anpassung an gegenwärtige Entwicklungen.

Man kann Interfaces nicht beliebig einfach halten.

Das habe ich nicht behauptet.

Nimm als Beispiel die Desktop-Integration eines Windows oder Mac OS X (bitte keine Diskussionen über die Notwendigkeit derselbigen). Wenn ich diese Funktionalitäten haben möchte, muss ich auch die Interfaces (API, nicht User) komplizierter machen - und sei es, dass ich mehr Interfaces brauche.
Man ist natürlich trotzdem bestrebt, sie so einfach wie möglich zu machen, aber es gibt einfach Grenzen.

Ich sehe das ehrlich gesagt auch nicht als sonderlich komplex an. Ich mein klar, es ist nicht die perfekte API, aber ich habe mich selbst schon damit gespielt und ich bin mir nicht sicher worauf du da genau anspielst. In meinem ersten Beitrag habe ich ja deshalb von unnötiger Komplexität geredet, was wohl dem entspricht wenn du sagst "so einfach wie möglich".

Ich habe mich auch in letzter Zeit viel mit dem Web als Plattform beschäftigt. Vielleicht gibt es nur dort diesen Trend. Da werden Layers und Frameworks verwendet die nicht wirklich mehr können, als das was tiefer ohnehin in relativ einfacher Form zur Verfügung steht aber nur buggy oder unfertig ist. Statt einem Fix wird also Zeit mit dem Vertuschen verschwendet. Das ist auch der Grund warum ich meinen Fokus dann wieder auf andere Dinge gerichtet habe. Zuerst Assembly, aber irgendwie sind da die Communities am Aussterben und dann habe ich mir meine Skripte für den Desktop angesehen und geschaut was die verschiedenen Projekte so treiben. Das sieht dann bei den oftmals so aus als würden vor allem bei den Großen die Dinge aneinander vorbeigehen, was interessant ist, weil es die die Leute gibt, die alles aus einem Guss machen wollen und somit auch das Interface quasi einheitlich wird und dann die Standalone-Sachen, die wunderbar zusammenarbeiten.

Das ist ziemlich verwirrend. Die BSDs scheinen die einzigen Projekte zu sein, wo eine Symbiose dieser zwei möglichen Ansätze ohne Gefrickel auf Seiten des Users funktioniert. Ich bin mir noch nicht ganz sicher was alles dazu führt. Vielleicht sind es einfach nur Entwickler mit viel Erfahrung, aber dann verstehe ich nicht ganz warum die alle ausschließlich an BSD werkeln.

Open-Source-Entwickler sind auch nur Menschen, die von "ihrem Baby" überzeugt sind und meinen, sie könnten es besser als die anderen.
Das ist auf der einen Seite schade, auf der anderen gäbe es ohne diese Einstellung keinen Fortschritt.

Was hat das mit dem Problem zu tun, dass man Interfaces braucht mit denen man auch umgehen kann? Wenn es sein eigenes Interface implementiert dann kümmert sich in den allermeisten Fällen kaum jemand darum und der Fortschritt bleibt aus.

Java (die Programmiersprache) hat viele hässliche Seiten (von denen ich viel zu viele aus eigener Erfahrung kenne), es gibt wesentlich schönere Sprachen (Python, Ruby, auch C#, etc.).

Java (die Platform) ist momentan die wohl beste Umgebung für Softwareentwicklung für Herausforderungen der realen Welt. Die Nachteile der Sprache (die allesamt bekannt und keine Überraschungen mehr sind) werden durch die enorme Menge an Vorteilen mehr als ausgeglichen.

Ich hoffe ja schon lange, dass es da mehr Entwicklung gibt. Als alle von Mono geredet haben hat das ja so ausgesehen als würde sich etwas tun. Parrot geht in vielen Bereichen einen anderen Weg. Die Leute dort beweisen einen langen Atem und, dass sie sehr professionell arbeiten. Ich finde es fehlt dem Projekt an Aufmerksamkeit.

Es gibt natürlich auch Bereiche, in denen Java nicht das Mittel der Wahl ist (z.B. embedded systems), aber Diskussionen hierzu würde ich in einen eigenen Thread auslagern.

Ich kenne in dem Feld jemanden. Er ist sich bewusst, dass es nicht dazu geeignet ist, aber es ist nun mal sein Job. Außerdem ist das ein wunderbares Beispiel dafür warum es großer Unfug ist, dass alle immer auf Java gedrillt werden. In dem (großen) Unternehmen scheinen sie da nur drauf zu setzen, weil alle Java können.

Warum das Rad neu erfinden und eine Lösung einsetzen, die sich in der Praxis erst bewähren muss?
MySQL und XML sind in vielen Fällen nicht die beste Lösung, aber

• jeder kennt sie
• sie funktionieren gut genug
• es gibt massig Support

Also warum viel Aufwand in Dinge stecken, die mit der eigentlich Problemlösung nichts zu tun haben, wenn ich vorher nicht weiß, ob man es besser kann?

Ehrgeiz?

Keiner möchte als Idiot dastehen, selbst wenn man einer ist.
In vielen Bereichen kommt dazu, dass es sehr negative Konsequenzen haben kann, wenn man "der Schuldige" ist. Wenn ein Projekt scheitert, möchte niemand der Sündenbock sein.

Ich habe dich mit dem Idealismus gewarnt.

Aber ein Projekt kann doch auch in anderen Fällen scheitern und was mache ich wenn der traditionelle Grund dafür ausschlaggebend ist?

Man darf aber vor lauter Enthusiasmus nicht vergessen, dass sich die Theorie an die Praxis anpassen muss, nicht umgekehrt.

Wie sollte das gehen? Außerdem ist das ja schummeln. Wenn es in der Theorie, aber nicht in der Praxis funktioniert dann ist ein Projekt gescheitert und die Theorie falsch, egal ob nur teilweise oder was die Implementierung betrifft. Dann schaut man sich das Projekt an, findet heraus wo die Fehler waren überlegt sich wie man die korrigieren kann, legt erneut los und stellt fest ob der neue Versuch das zu lösende Problem der Praxis gewachsen ist.

Deswegen bin ich dazu übergegangen, in der Softwareentwicklung weniger auf die Theoretiker zu geben. Entscheidend sind die Dinge, die in der Praxis funktionieren. Der Rest ist Trockenwichsen.

Aber woran sollte ein Theoretiker seinen Erfolg den messen. Die Informatik halte ich ja deshalb für interessant, weil die Ressourcen die für eine praktische Implementierung benötigt werden einfacher (einfacher ist häufig =! einfach) zu erreichen sind, als in anderen Wissenschaften.

 

[Azazyel]

Dann verwende ich eben etwas anderes, als eine Pipe. Ein Socket oder ein High Level Protokoll, ist doch egal was. Nur warum man manche Dinge ständig neu erfinden muss verstehe ich nicht.

Not invented here.

Stimmt das? Ist es wirklich die Verletzung die Schichtenarchitektur, die es so zum Nonplusultra macht (für das ich es genauso wenig halte wie jede andere Software)?

Ich wüsste momentan kein besseres Dateisystem.

Bestimmte Features von ZFS lassen sich nur durch die Verletzung der Schichtenarchitektur erreichen. Wie willst du end-to-end data integrity erreichen, wenn dein Dateisystem nicht eine "Ahnung" von der darunterliegenden Hardware hat?
In der klassischen Schichtentrennung bekommt das Dateisystem beim Lesen eines Blocks null Feedback über die darunterliegenden Strukturen (was ja auch gewollt ist).

Ich glaube nicht, dass es allzu lange dauert bis der Filesystemhype von neuem beginnt und jeder sein ZFS ersetzen will. Verstehe mich nicht falsch, ich will nicht sagen das ZFS schlecht ist, ganz im Gegenteil ich bin ein großer Fan davon, aber das was du behauptest sehe ich nicht wirklich als bewiesen an.

Natürlich ist ZFS nicht das Ende jeglicher Dateisystementwicklung. Es ist nur eine Frage der Zeit, bis jemand etwas Besseres hervorbringt.

Bleibt ZFS nicht trotzdem relativ einfach anzusprechen? Ob du das für die genannten Layers einzeln tust oder ob du was auch immer du tun willst direkt an ZFS übergibst macht ja keinen sonderlich großen Unterschied. Das ist einfach nur eine Anpassung an gegenwärtige Entwicklungen.

Korrekt, ZFS benutzt bzw. implementiert auch nur die jeweiligen Interfaces.

Ich habe mich auch in letzter Zeit viel mit dem Web als Plattform beschäftigt. Vielleicht gibt es nur dort diesen Trend. Da werden Layers und Frameworks verwendet die nicht wirklich mehr können, als das was tiefer ohnehin in relativ einfacher Form zur Verfügung steht aber nur buggy oder unfertig ist. Statt einem Fix wird also Zeit mit dem Vertuschen verschwendet.

Welches Framework meinst du?
Die Frameworks, mit denen ich mich in jüngster Zeit beschäftigt habe (Primefaces und vor allem GWT), bieten mit wenig Aufwand irrwitzig viel Funktionalität und sind wesentlich fehlerfreier, als wenn ich auch nur einen Bruchteil der Funktionalität von Hand implementieren würde.

Wenn man sich noch Apache, Tomcat und Konsorten mit anschaut, bin ich über jeden Layer froh, der mir Arbeit abnimmt. Ich habe zwar auch schon produktionskritische C++-Anwendungen entwickelt, die direkt mit Unix-Sockets arbeiten, aber das möchte ich mir heutzutage nicht mehr antun.

Das ist auch der Grund warum ich meinen Fokus dann wieder auf andere Dinge gerichtet habe. Zuerst Assembly, aber irgendwie sind da die Communities am Aussterben und dann habe ich mir meine Skripte für den Desktop angesehen und geschaut was die verschiedenen Projekte so treiben.

Assembly hat auch nur noch ein paar Nischen (Compiler, ein paar Industrieanwendungen); Scripting findet außerhalb der Systemadministration mangels Mächtigkeit auch kaum noch Einsatz.
Warum etwas von Hand machen, was man mit anderen Mitteln (hier: höheren Sprachen) wesentlich einfacher machen kann?

Das sieht dann bei den oftmals so aus als würden vor allem bei den Großen die Dinge aneinander vorbeigehen, was interessant ist, weil es die die Leute gibt, die alles aus einem Guss machen wollen und somit auch das Interface quasi einheitlich wird und dann die Standalone-Sachen, die wunderbar zusammenarbeiten.

Jeder Ansatz hat seine Vor- und Nachteile. Es hängt immer ganz vom Einzelfall ab, welche Lösung sinnvoller ist.

Das ist ziemlich verwirrend. Die BSDs scheinen die einzigen Projekte zu sein, wo eine Symbiose dieser zwei möglichen Ansätze ohne Gefrickel auf Seiten des Users funktioniert. Ich bin mir noch nicht ganz sicher was alles dazu führt.

Ich verweise an dieser Stelle mal ganz dezent auf die Diskussionen hier im Forum. Wenn das kein Gefrickel ist...

Vielleicht sind es einfach nur Entwickler mit viel Erfahrung, aber dann verstehe ich nicht ganz warum die alle ausschließlich an BSD werkeln.

BSD bietet halt - wie die kommerziellen Unixes - Kernel und Userland-Tools aus einer Hand an und verwendet viel Zeit auf die Pflege des "großen Ganzen". Apple und Microsoft werfen hier natürlich ihre Manpower in den Ring und machen die Integration noch besser. Bei Linux hat man den historisch gewachsenen Wildwuchs mit den bekannten Nachteilen.

Auf der anderen Seite muss man auch der Realität ins Gesicht schauen, BSD ist inzwischen - selbst im Web-Umfeld - recht bedeutungslos geworden und hängt technisch weit hinterher.

Ich hoffe ja schon lange, dass es da mehr Entwicklung gibt. Als alle von Mono geredet haben hat das ja so ausgesehen als würde sich etwas tun.

Wir war nie klar, welches Problem Mono eigentlich lösen möchte.

• Wer .NET braucht, nimmt gleich Windows und lässt seine Anwendungen bestimmt nicht auf Mono laufen.
• Wer .NET nicht braucht, hat bessere Plattformen zur Auswahl.

Parrot geht in vielen Bereichen einen anderen Weg. Die Leute dort beweisen einen langen Atem und, dass sie sehr professionell arbeiten. Ich finde es fehlt dem Projekt an Aufmerksamkeit.

Viele dynamische Sprachen laufen in der Zwischenzeit schon auf der JVM, das hat dem ganzen natürlich etwas Luft genommen. Ich hoffe aber trotzdem, dass sich Parrot noch mausert.

Ich kenne in dem Feld jemanden. Er ist sich bewusst, dass es nicht dazu geeignet ist, aber es ist nun mal sein Job. Außerdem ist das ein wunderbares Beispiel dafür warum es großer Unfug ist, dass alle immer auf Java gedrillt werden. In dem (großen) Unternehmen scheinen sie da nur drauf zu setzen, weil alle Java können.

Für 99% aller Entwicklungen in Unternehmen ist Java (bzw. das artverwandte .NET) schlicht und ergreifend die mit Abstand beste Lösung. Die besten IDEs und Tools, der umfassendeste Support, die ausgereiftesten Bibliotheken, die genialen Application Server, und und und.
Ich wüsste keine Plattform, die Java (bzw. .NET) im Unternehmensumfeld auch nur näherungsweise Konkurrenz bieten könnte. Was würdest du denn als Alternative vorschlagen?

Aber ein Projekt kann doch auch in anderen Fällen scheitern und was mache ich wenn der traditionelle Grund dafür ausschlaggebend ist?

Wenn eine Methode sich bewährt hat, kann sie immer noch für das jeweilige Projekt falsch gewesen sein - aber wenn es in hunderten Projekten funktioniert hat, ist die Wahrscheinlichkeit schon einmal wesentlich geringer.
Das heißt natürlich auch, dass bessere Methoden (z.B. (je nach Projekt) agile Softwareentwicklung) sehr lange brauchen, um sich durchzusetzen.

Gegenfrage: würdest du einem Architekten, der in einem Wolkenkratzer ein neuartiges Material verbauen möchte, das noch vollkommen unerprobt ist, dein OK geben?

Wie sollte das gehen? Außerdem ist das ja schummeln. Wenn es in der Theorie, aber nicht in der Praxis funktioniert dann ist ein Projekt gescheitert und die Theorie falsch, egal ob nur teilweise oder was die Implementierung betrifft.

Ganz so schwarz und weiß ist es in der Realität nicht. Im Zweifelsfalle steht halt der Beweis durch eine korrekte Implementierung noch aus.
Beispielsweise ist formale Verifikation für fast alle Anwendungen ein völlig untaugliches Mittel, die Funktionsfähigkeit einer Software festzustellen - auch wenn die Theorie vollkommen korrekt ist. Die Umsetzbarkeit in die Praxis ist i.d.R. nicht Gegenstand der Forschung.

Dann schaut man sich das Projekt an, findet heraus wo die Fehler waren überlegt sich wie man die korrigieren kann, legt erneut los und stellt fest ob der neue Versuch das zu lösende Problem der Praxis gewachsen ist.

Wenn du aber der Projektverantwortliche für ein Softwareprojekt bist, möchtest du nicht derjenige sein, der das per trial and error herausfindet. Auch ist das mit dem "erneut loslegen" so eine Sache, wenn du soeben 10 Millionen Euro verpulvert hast...

Aber woran sollte ein Theoretiker seinen Erfolg den messen. Die Informatik halte ich ja deshalb für interessant, weil die Ressourcen die für eine praktische Implementierung benötigt werden einfacher (einfacher ist häufig =! einfach) zu erreichen sind, als in anderen Wissenschaften.

Die Informatik bringt zwar die Softwareentwicklung in vielen Bereichen weiter; die größten Probleme in der Softwareentwicklung (das immer noch mehr Handwerk denn Wissenschaft ist) in der realen Welt haben mit reiner Informatik aber sehr wenig bis gar nichts zu tun.

 

[Kamikaze]

Der Bezug war embedded Java:

Ich kenne in dem Feld jemanden. Er ist sich bewusst, dass es nicht dazu geeignet ist, aber es ist nun mal sein Job. Außerdem ist das ein wunderbares Beispiel dafür warum es großer Unfug ist, dass alle immer auf Java gedrillt werden. In dem (großen) Unternehmen scheinen sie da nur drauf zu setzen, weil alle Java können.

Das kann ich auch bestätigen aus Unterhaltungen mit Automobilzulieferern. Die wissen, dass es technisch keinen Sinn macht Java zu verwenden. Embedded Anwendungen sind immer Hardware spezifisch, das heißt man braucht für Java mehr Speicher, mehr Rechenleistung und mehr Energie ohne einen technischen Vorteil (Plattformunabhängigkeit) zu gewinnen.

Trotzdem setzen sie auf Java, weil sie für C keine Leute finden.

 

[Athaba]

Ich habe vorhin eine etwas ausführlichere Antwort auf einer relativ frischen Firefox-Installation verloren. Zu viele gefährliche Shortcuts.

Also nichts wundern, wenn es etwas dauert mit der Antwort.

 

[oenone]

Mir fällt das in der Webentwicklung auf. Zuerst war Rails und dann Sinatra. Häufig sagt man dann Sinatra ist für kleine und Rails für große Projekte. Natürlich gibt es beides auch schon für quasi jede andere Programmiersprache. Viele sind der Meinung ihr Projekt ist groß, obwohl es das nicht ist. In der Perlwelt gibt es dann noch Mojolicious, was den Vorteil hat, dass man fließend von Microframework zum großen Wechseln kann. Das ist nur ein Beispiel, wo man die Dinge falsch einschätzt und wie oben geschrieben mit Kanonen auf Spatzen schießt.

Was wurde wie falsch eingeschätzt?

Das selbe sehe ich auch im OO-Bereich. Man braucht für ein kleines Script keine drei Objekte, die sich aller Mittel von OO Bedienen. Das erinnert an die Literatur, wo man eine Zeit lang versucht hat in jeden Text so viele rhetorische Figuren zu stecken wie nur möglich. Nur weil man es machen kann heißt es ja nicht das man es muss.

Man muss aber auch ausprobieren, was möglich ist. Außerdem will vielleicht jemand etwas schon vorhandenes auf seine eigene Art lösen, mit Techniken, die er gerne nutzen will. Oder auch nur um sagen zu können, dass er es selbst gelöst hat.

 

[Athaba]

Was wurde wie falsch eingeschätzt?

Die technischen Anforderungen eines Projektes. Das ist auch das was man oft in Interviews mit Startups liest. Da nehmen viele lieber mehr und das führt dazu, dass man sich um das mehr auch kümmern muss. Klar, es gibt auch den umgekehrten Fall. Deshalb ist es ja schön wenn man kleine, portable, austauschbare Systeme hat. Dafür sind Layers nämlich wirklich sinnvoll.

 

[Azazyel]

Automobilzulieferer und Java:

Trotzdem setzen sie auf Java, weil sie für C keine Leute finden.

Wird mal wieder die Fachkräftemangel ausgepackt?
Einzig und allein billige Frischlinge mit C-Kenntnissen gibt es inzwischen seltener. Wenn man Java kennt, ist doch der Umstieg zu C (nicht C++) schnell geschafft.

Zumindest hier (Metropolregion) kann man mit erfahrenen C-Entwicklern mit Hardware-Kenntnissen die Straße pflastern. Die sind halt meistens schon 40+ und verlangen entsprechend Gehalt.

 

[Kamikaze]

Die Leute haben Hirnblockade und wollen nicht von Java weg auch wenn sie's könnten.

Wie es mit älteren C-Entwicklern aussieht, weiß ich leider nicht.

 

[Azazyel]

Die Leute haben Hirnblockade und wollen nicht von Java weg auch wenn sie's könnten.

Das halte ich für ein Märchen. Das Gros der heutigen Java-Entwickler hat ja auch mit C/C++/Pascal angefangen und ist dort nicht hängengeblieben.

 

[Kamikaze]

Ich kenne niemanden der mit C/C++ angefangen hat.

Die meisten Leute haben mal in der Schule mit Pascal rumgemurkst, aber C ist Vodoo für die.

 

[Azazyel]

Ich kenne niemanden der mit C/C++ angefangen hat.

Bei meinem Bekannteskreis ist es bei den Softwareentwicklern - je nach Jahrgang - Pi mal Daumen 50:50.

Die meisten Leute haben mal in der Schule mit Pascal rumgemurkst, aber C ist Vodoo für die.

Ich rede ja auch von Fachkräften, nicht von Hobbyprogrammierern.

 

[oenone]

Fachkräftemangel ist ein riesiger Schwindel.

Wenn die Firmen endlich angemessen zahlen würden, hätten sie auch viele willige und kompetente Fachkräfte. Aber für den Hungerlohn will halt niemand.

 

[rudy]

Ich kenne niemanden der mit C/C++ angefangen hat.

Die meisten Leute haben mal in der Schule mit Pascal rumgemurkst, aber C ist Vodoo für die.

Was hast Du an Pascal auszusetzen zum Glück haben viele die Schnauze von C und seiner objektorientierten Variante voll. Mit Grauen muss ich genau an alle meine ehemaligen Dozenten denken, die Hohen Priester und Hardcore Dogmatiker der Sprache C will ich es schnell haben greife ich zu Assembler selbst in Python geht man weg von C und das ist uneingeschränkt zu begrüßen.

Dann was kann C was Pascal nicht kann viel Spass beim Portieren mein Bester sach ich da mal bloß , mach das mal mit C und mach das mal mit Pascal und dann lesen wir uns noch mal....

 

[Kamikaze]

???

Muss man nicht verstehen, oder?