Softwareentwicklung und Softwaretechnologie [Archiv]

(del)

2009-10-03, 17:17:46

Hi

Interessante Studie. Mit heute gängigen Methoden brauchen 6 Mathematiker und Programmierer ungefähr 5 Jahre, um ggbf. einem 7500 Zeilen (Kode) seL4 microkernel eine Bugfreiheit zu attestieren.

Allgemein sollte man annehmen, daß bei "reasonably engineered software" pro 1000 Zeilen 10 Bugs vorhanden sind. Bei HQ Entwicklungen sollte man noch von 3 Bugs ausgehen.

Linux/Windows haben ungefähr 50 Mio. Zeilen :freak: Irgendwie kommen einem dann die heute eingesetzten Entwicklungsmethoden/Testmethoden urarchaisch vor.

50 mio. Zeilen :rolleyes: Da braucht man sich garnicht fragen, ob MS und andere mit heutigen Methoden je Herr der Lage sein können. Für XPsp3 könnte man bestimmt auch 2030 noch Monat für Monat Patchdays machen :ucatch: (seit sp3 sind schon wieder mehr als 100 klare Fehler wie auch "security issues" behoben worden).

Mit jedem neuen OS spielt man sich also Tausende Fehler auf. Irgendwie will ich das mittlerweile nicht mehr einfach so als "es ist nunmal zwangsläufig so" akzeptieren. Komputersysteme sind mittlerweile auch daheim essentieller Bestandteil des Lebens.

http://www.physorg.com/news173086905.html

Spasstiger

2009-10-03, 17:24:29

Nach der Softwaretechnik-Vorlesung, die ich besucht habe, sind die meisten Unternehmen tatsächlich auf der untersten Stufe in einem Ranking, das Unternehmen nach dem Grad und der Aktualität an eingesetzten Softwaretechnikmethoden bewertet.
Die aktuellste Methode, die uns vorgestellt wurde, sind Softwareagenten. Dabei legt der Programmierer nicht mehr fest, wie das Programm in jeder Situation ablaufen soll, sondern es werden Ziele festgelegt, die autonome Softwareagenten unter Verwendung von zur Verfügung gestellten Methoden und Schnittstellen erreichen sollen.
In der Forschung macht man sich also durchaus Gedanken drüber, wie man Softwareentwicklung effizienter gestalten kann.

(del)

2009-10-03, 17:38:11

Die Industrie entwickelt/sponsort nur was Geld bringt. "Effizienz" legt hier eher fest wieviel Zeit man für etwas braucht und wieviele Leute damit beschäftigt sind.

Anschliessend sind Features die Verkaufsargumente.

Fehler sind vorerst nur dann relevant, wenn sie wiederholt von dem Benutzer nachvollziehbar werden können. Oder vom Hacker.

Wieviel Softagenten zur Reduzierung der gesamten Fehleranzahl beitragen können wird sich noch zeigen müßen. Erstmal müßen sie und die bereitgestellten Methoden selbst stark fehlerreduziert sein...

Ich halte die momentane Situation langsam für nicht mehr wirklich akzeptabel.

Was schätzen die verehrten Kollegen hier bitte wieviele Fehler im total tollen Win7 enthalten sind? Oder, um nicht allzueinseitig rüberzukommen, noch in KDE 4.3?

Bis dann mal.

Demirug

2009-10-03, 18:01:16

Monger

2009-10-03, 19:08:16

Die aktuellste Methode, die uns vorgestellt wurde, sind Softwareagenten.
...

Auch agentenorientierte Programmierung (die übrigens auch schon seit mindestens mal sieben Jahren durch die Universitäten spukt) wird nicht das Problem lösen, dass Software nunmal nur genau das tut was man von ihr verlangt - und man also wissen muss was man will.

Die allermeisten Bugs heute sind ja eben keine Leichtsinnsfehler, sondern Definitionslücken. Das Systempflichtenheft unseres letzten Projektes umfasste viele tausend Seiten - als wir fertig waren, ist davon praktisch jede Zeile geändert worden.

Natürlich hilft es, bessere Werkzeuge in der Hand zu haben. Aber wesentlich wichtiger ist es imho, den eigentlichen Entwicklungsprozess in den Griff zu kriegen. Das ist ein organisatorisches Problem, nicht so sehr ein technisches.

][immy

2009-10-03, 20:11:49

Irgendwie scheint man hier mal wieder die Daten der alten IBM Studie verwendet zu haben. „High Quality Code“ war nach dieser Code der durch eine von den eigentlichen Entwicklern unabhängige QA Abteilung überprüft wurde. Etwas was heute eigentlich bei jeder größeren kommerziellen Software gemacht wird. Was in der kurzen Zusammenfassung auch unterschlagen wird ist das nur etwa ~10% dieser Fehler kritisch sind. Die restlichen 90% sind Tippfehler, minimale Abweichungen im UI Layout und ähnliches.

genau das ist auch meine erfahrung.

Allerdings muss ich besonders bei Firmensoftware sagen, UI-Fehler werden von Benutzern häufig als Kritische Fehler angesehen, weil die Anwender hier halt x-mal drüber stolpern.

Aber software komplett testen zu können, von diesem Luxus kann man sich eigentlich verabschieden. Software wird heutzutage für einen gewissen zweck geschrieben und für diesen Zweck (und vielleicht noch für ein paar extremfälle) getestet. ansonsten würde das ganze einfach zu teuer werden.

ich kann erhlichgesagt nicht verstehen, wie man heutzutage noch so viel anwedersoftware in c, c++ oder z.b. delphi schreiben kann. der aufwandt der betrieben werden muss ist zumindest um einiges größer als mit java /.net.
zugegeben, letztere eigenen sich nicht unbedingt für jedes projekt, aber je größer ein projekt desto mehr vorteile bieten diese framewoks. vor allem wenn es um die aufwärtskompabilität (z.B. 64-bit) und spätere wartung geht, sind sie eindeutig im vorteil.

Viele fehler können so auch vermieden werden, wie z.B. Speicherlecks (wobei man zwar nach wie vor drauf achten muss, aber nicht mehr so extrem). außerdem sind bei java/.net schon große fertige und vor allem getestete codeteile (methode, klassen) bereits vorhanden die wiederverwendet werden können. wobei diese auch bei weitem nicht fehlerfrei sind, aber eben meistens das richtige ergebnis liefern.

Es ist zwar so das der Resourcenbedarf grundsätzlich etwas höher ausfällt, schon allein dadurch, das man eine weitere schicht hat (z.B. IL) aber in zeiten wo man CPU-Power und Speicher im überfluss hat sollte das nicht mehr das problem sein.

Coda

2009-10-03, 21:56:41

[immy;7573530']ich kann erhlichgesagt nicht verstehen, wie man heutzutage noch so viel anwedersoftware in c, c++ oder z.b. delphi schreiben kann. der aufwandt der betrieben werden muss ist zumindest um einiges größer als mit java /.net.
zugegeben, letztere eigenen sich nicht unbedingt für jedes projekt, aber je größer ein projekt desto mehr vorteile bieten diese framewoks. vor allem wenn es um die aufwärtskompabilität (z.B. 64-bit) und spätere wartung geht, sind sie eindeutig im vorteil.
Ich finde nach wie vor das wird überbewertet. Es kommt drauf an wie man seinen C++-Code schreibt. Mit Standardcontainern und Smart-Pointern kann man eigentlich so gut wie alle Speicherlecks und Pufferüberläufe vermeiden.

Das Problem ist, dass Java/.NET tatsächlich schneller beherrschbar sind.

Exxtreme

2009-10-03, 22:03:15

[immy;7573530']ich kann erhlichgesagt nicht verstehen, wie man heutzutage noch so viel anwedersoftware in c, c++ oder z.b. delphi schreiben kann. der aufwandt der betrieben werden muss ist zumindest um einiges größer als mit java /.net.
zugegeben, letztere eigenen sich nicht unbedingt für jedes projekt, aber je größer ein projekt desto mehr vorteile bieten diese framewoks. vor allem wenn es um die aufwärtskompabilität (z.B. 64-bit) und spätere wartung geht, sind sie eindeutig im vorteil.

Es gibt idR. nach wie vor recht viele "Sachzwänge", die einen Umstieg verhindern.

Demirug

2009-10-03, 22:06:59

Ich finde nach wie vor das wird überbewertet. Es kommt drauf an wie man seinen C++-Code schreibt. Mit Standardcontainern und Smart-Pointern kann man eigentlich so gut wie alle Speicherlecks und Pufferüberläufe vermeiden.

Aber wenn du mal einen Heap Fehler am Hals hast wird es lustig. Aus meiner Erfahrung hast du sowas in einem großen Projekt etwa alle 3 Monate. Und einen bösen Wildpointer suchst du im schlimmsten Fall auch mal eine Woche. Der Vorteil von .net ist hier nicht wirklich der GC sondern der vollständig typisierte Heap.

Coda

2009-10-03, 22:11:37

Hm ja, das stimmt natürlich. Aber dagegen helfen ja Dinge wie valgrind oder bei Windows die Global Flags.

HunterXXL

2009-10-03, 23:33:38

Es sollte nicht vergessen werden das nicht alles was source code ist auch wirklich anfällig für Fehler ist. Daher müssten auch nicht alle zeilen von win7 geprüft werden, etc.

Zu C++ und warum das noch verwnedet wird?
Ich denke das hängt sicherlich stark mit der Software zusammen. Spiele kann ich mir momentan nicht vorstellen in einer anderen Sprache zu entwickeln. Wobei Datenbank, GUI, etc, sicherlich mit moderneren Lösungen stark vereinfacht werden kann.

Monger

2009-10-03, 23:39:17

[immy;7573530']
ich kann erhlichgesagt nicht verstehen, wie man heutzutage noch so viel anwedersoftware in c, c++ oder z.b. delphi schreiben kann. der aufwandt der betrieben werden muss ist zumindest um einiges größer als mit java /.net.

Das Problem ist, dass ja nicht nur die gesamte Toolkette inklusive Bibliotheken etc. umziehen muss, sondern auch das Know-How. Viele Entwickler sind 30 Jahre lang mit C++ aufgewachsen, die schulst du nicht einfach mal so um.

Aber zumindest bei mir in der Firma ist die Bewegung Richtung .NET und Java schon gewaltig, und das obwohl wir eigentlich ziemlich konservative Kunden haben.

Demirug

2009-10-03, 23:47:44

Hm ja, das stimmt natürlich. Aber dagegen helfen ja Dinge wie valgrind oder bei Windows die Global Flags.

Wir haben auch mit BounceChecker gearbeitet. In der Theorie findet es wirklich alle solche Fehler in der Praxis scheiter es aber häufig daran das solche Tools einen sehr negativen Einfluss auf das Laufzeitverhalten haben. Bei .Net hat man den Vorteil das man jederzeit einen Dump ziehen kann und den genauen Aufbau des Heaps bekommt. Richtige Wildpointer (was die schlimmsten Fehler in C++ sind) kann es in managed Umgebungen ja systembedingt nicht geben.

Ich denke das hängt sicherlich stark mit der Software zusammen. Spiele kann ich mir momentan nicht vorstellen in einer anderen Sprache zu entwickeln.

Der größte Teil des Codes in einem Spiel ist nicht zeitkritisch. Da werden sogar Lua oder Actionscript benutzt. Der einzige Grund warum bei Spielen immer noch C++ vorherrscht sind fehlenden Alternativen auf den Konsolen.

Das Problem ist, dass ja nicht nur die gesamte Toolkette inklusive Bibliotheken etc. umziehen muss, sondern auch das Know-How. Viele Entwickler sind 30 Jahre lang mit C++ aufgewachsen, die schulst du nicht einfach mal so um.

So schwer ist der Umstieg eigentlich nicht. Ich würde da dann eher auf Unwillen tippen.

Monger

2009-10-03, 23:55:35

Der größte Teil des Codes in einem Spiel ist nicht zeitkritisch. Da werden sogar Lua oder Actionscript benutzt. Der einzige Grund warum bei Spielen immer noch C++ vorherrscht sind fehlenden Alternativen auf den Konsolen.

Darf ich mal fragen, wie es da bei EA eigentlich aussieht? Weißt du von irgendwelchen Projekten wo z.B. .NET tatsächlich eine Rolle spielt?

Weil wie du ja schonmal hier im Forum gesagt hast: in der Spieleentwicklung scheint man in dem Bereich doch sehr konservativ zu sein.

Demirug

2009-10-04, 00:18:21

Darf ich mal fragen, wie es da bei EA eigentlich aussieht? Weißt du von irgendwelchen Projekten wo z.B. .NET tatsächlich eine Rolle spielt?

Im Tollchain Bereich wird sehr viel C# genutzt. Bei den eigentlichen Spielen scheitert es ja bisher an der fehlenden Unterstützung auf den Konsolen. Da nun fast jedes Team sich zu mindestens die Option auf Multiplattform offen halten will sieht es bei den Spielen selbst momentan noch eher schlecht aus. Ich weiß allerdings das bei den SIMs C# für das Skript System benutzt wird. Ebenso weiß ich das unsere Server in C# programmiert sind. Andere Teams haben Java für die Server benutzt.

Zusammengefasst kann man sagen dass dort wo es technisch möglich ist immer häufiger auf Alternativen zu C++ gesetzt wird. Was zukünftige Planungen angeht darf ich wie üblich nichts sagen solange nichts offiziell angekündigt ist.

][immy

2009-10-04, 01:07:15

So schwer ist der Umstieg eigentlich nicht. Ich würde da dann eher auf Unwillen tippen.

jep, unwillen ist wohl das größte problem.
ich kenne da aus meinem arbeitsumfeld ein paar beispiele ....

es ist zwar klar, das es immer bereiche geben wird, wo man einfach nicht drum herum kommt (z.B. treiber), aber in vielen anderen bereichen sorgt es für eine wesentlich schnellere entwicklung

wovor vermutlich auch viele angst haben ist, das der code mit java oder .net aus einer assembly wiederhergestellt werden kann, wodurch mehr oder minder jeder algorythmus offen für jedermann ist. da helfen auch keine tools die den source-code einmal durch nen mixer ziehen, damit es nicht mehr lesbar aussieht.

was die wiederverwendung von alten nicht .net/java komponenten angeht, da hat man eigentlich keine nachteile. man kann sie wiederverwenden, ist dann halt nur darauf angewiesen, das man sich um das aufräumen kümmert und darauf achtet, das man dann nur noch in 32- oder 64-bit arbeiten kann. aufrufen kann man nach wie vor alles.

was spiele angeht, dort ist das zeitraubenste ja die content-erstellung und nicht die pure programmierung. aber wenn es darum geht bugs zu verhindern, code hinterher auch gut warten zu können, zu erweitern, und sicherzustellen das er auch zukünftig (auch auf anderer hardware) noch funktioniert, ist managed code ziemlich im vorteil.

HunterXXL

2009-10-04, 01:24:43

[immy;7574047']was spiele angeht, dort ist das zeitraubenste ja die content-erstellung und nicht die pure programmierung.
Sicherlich hast du damit nicht unrecht. Aber ich denke der Betrachtungswinkel ist nicht ganz korrekt.
Jeder Bereich muss getrennt betrachtet werden. Auch wenn andere Bereiche mehr Zeit benötigen (könnten), sollte jeder Bereich für sich bestmöglichst optimiert werden.

[immy;7574047']aber wenn es darum geht bugs zu verhindern, code hinterher auch gut warten zu können, zu erweitern, und sicherzustellen das er auch zukünftig (auch auf anderer hardware) noch funktioniert, ist managed code ziemlich im vorteil.
Aber damit dann der "managed code" auf all den aktuellen platformen läuft (PC, console, handheld) ist meiner meinung nach C/C++ der größte gemeinsame nenner und daher kann nicht darauf verzichtet werden.
Und ich wüsste auch nicht durch was es einmal abgelöst werden sollte.

][immy

2009-10-04, 02:08:25

Aber damit dann der "managed code" auf all den aktuellen platformen läuft (PC, console, handheld) ist meiner meinung nach C/C++ der größte gemeinsame nenner und daher kann nicht darauf verzichtet werden.
Und ich wüsste auch nicht durch was es einmal abgelöst werden sollte.

die produktionskosten werden die entwickler früher oder später in diese richtung scheuchen, denn die projekte werden einfach zu komplex.
wobei man noch erwähnen muss das auch bei multi-konsolen-titlen ein nicht unerheblicher teil muss trotzdem auf die entsprechende konsole zugeschnitten werden.
zudem geht es in zukunft wohl eher dazu hin, das man bei sich zu hause kein hardware-monster mehr stehen hat, sondern einfach nur eine kleine box die nur streamed. es gibt zwar da noch probleme, aber irgendwann wird man auch diese probleme in den griff bekommen haben. dann sind "konsolen" nicht mehr an feste hardwarekomponenten gebunden und die hersteller können sich völlig frei entscheiden, wie sie ein spiel entwickeln.

(del)

2009-10-04, 11:25:47

Irgendwie scheint man hier mal wieder die Daten der alten IBM Studie verwendet zu haben.Wie alt ist diese Studie? Wenn sie sehr alt ist, ist das schlecht. DOS 6.22 hatte wieviele Fehler gegenüber NT4rtm? Turrican2 hatte wieviele Fehler gegenüber Gothic1 1.0?

Wenn sie neuer ist, kann ich daraus noch keine direkten Schlüsse ziehen. Die Anzahl der Fehler in W2kRTM und VistaRTM (nicht nur Sicherheitslücken) hält sich wohl eher in Waage. XPrtm stützte sich sehr auf W2k, Win7rtm auf Vista. Meinst du das sieht zwischen den beiden anders aus?

Was in der kurzen Zusammenfassung auch unterschlagen wird ist das nur etwa ~10% dieser Fehler kritisch sind. Die restlichen 90% sind Tippfehler, minimale Abweichungen im UI Layout und ähnliches.Ist mit "kritisch" gemeint, wenn ein Kernel/Anwendung anhält oder sich gleich langlegt?
Oder ist kritisch in dieser Studie auch, wenn z.B. eine bestimtme gemsichte Benutzung von Funktion-B und Funktion-C anschliessend nicht immer korrekt funktioniert, wenn der Benutzer nach Funktion-A die Aktion-XY ausführt?

@]ich kann erhlichgesagt nicht verstehen, wie man heutzutage noch so viel anwedersoftware in c, c++ oder z.b. delphi schreiben kann. der aufwandt der betrieben werden muss ist zumindest um einiges größer als mit java /.net.
zugegeben, letztere eigenen sich nicht unbedingt für jedes projekt, aber je größer ein projekt desto mehr vorteile bieten diese framewoks. vor allem wenn es um die aufwärtskompabilität (z.B. 64-bit) und spätere wartung geht, sind sie eindeutig im vorteil.[/quote]Aus welcher Sicht? Wenn du dich mit diesen Technologien auskennst, wirst du bestimmt mitbekommen haben wieviele - und welcher Art - Updates (nicht upgrades!) es bis jetzt für NET und JAVA gab. Mit NET schiebst du [i]die Verantwortung von dir auf MS. Ob das die Lage wirklich entspannt... Die aktuelle "updatehistorys" von den NETs überzeugen mich diesbezüglich noch nicht so wirklich.

Um eine bessere Ausrede beim Kunden ging es mir nicht. Davon ab war der Trend mit NET/JAVA bis jetzt eher gefährlicher als ohne. Ausgesprochen viele Fixes beheben hier sicherheitsrelevante Probleme die das gesamte System betreffen. Ich nehme wenn schon dann eher lieber irgendwelche Funktionalitätsfehler in deiner Software in Kauf, als deine aus Kundensicht fast perfekte Soft die auf einem Fundament aufbaut der ständig etliche systemrelevanten Sicherheitsprobleme aufweist.

zudem geht es in zukunft wohl eher dazu hin, das man bei sich zu hause kein hardware-monster mehr stehen hat, sondern einfach nur eine kleine box die nur streamed. es gibt zwar da noch probleme, aber irgendwann wird man auch diese probleme in den griff bekommen haben. dann sind "konsolen" nicht mehr an feste hardwarekomponenten gebunden und die hersteller können sich völlig frei entscheiden, wie sie ein spiel entwickeln.Das ist auch der Traum der .... nach IBMs "Denkfehler". Den Menschen ihre mächtigen Rechenmaschinen vom Zuhause wieder wegzunehmen und sie mit von außen kontrollierbaren Terminals auszustatten. Dann ist auch jeder Klick und jeder Tastenschlag auf dem CloudServer einsehbar.
In der Zeit wo für 90% der Anwendungsfälle für ein Haushalt ausreichend potente Technik klar unter 400€ zu bekommen ist, kann ich nur jedem dazu raten die Kunde unters Volk zu bringen, daß solche Versuche Teufelszeug sind und man sie wie dieser Weihwasser meiden sollte.

Demirug

2009-10-04, 12:22:42

Wie alt ist diese Studie? Wenn sie sehr alt ist, ist das schlecht. DOS 6.22 hatte wieviele Fehler gegenüber NT4rtm? Turrican2 hatte wieviele Fehler gegenüber Gothic1 1.0?

Wenn sie neuer ist, kann ich daraus noch keine direkten Schlüsse ziehen. Die Anzahl der Fehler in W2kRTM und VistaRTM (nicht nur Sicherheitslücken) hält sich wohl eher in Waage. XPrtm stützte sich sehr auf W2k, Win7rtm auf Vista. Meinst du das sieht zwischen den beiden anders aus?

Wenn ich mich recht entsinne wurde die Studie während der Entwicklung von Windows 2000 erstellt. Entsprechend bezog sie sich auf NT 4. Im Bezug auf Größe kam man zu der durchaus interessanten Erkenntnis das mit steigender Projektgröße die Anzahl der Fehler zwar zunimmt aber die Anzahl der Fehler pro 1000 Zeilen dabei immer geringer wird.

Ist mit "kritisch" gemeint, wenn ein Kernel/Anwendung anhält oder sich gleich langlegt?
Oder ist kritisch in dieser Studie auch, wenn z.B. eine bestimtme gemsichte Benutzung von Funktion-B und Funktion-C anschliessend nicht immer korrekt funktioniert, wenn der Benutzer nach Funktion-A die Aktion-XY ausführt?

Kritisch war bei IBM immer recht klar mit „Lost of Data“ definiert.

][immy

2009-10-04, 14:17:59

@]und welcher Art[/B] - Updates (nicht upgrades!) es bis jetzt für NET und JAVA gab. Mit NET schiebst du [i]die Verantwortung von dir auf MS. Ob das die Lage wirklich entspannt... Die aktuelle "updatehistorys" von den NETs überzeugen mich diesbezüglich noch nicht so wirklich.
Um eine bessere Ausrede beim Kunden ging es mir nicht. Davon ab war der Trend mit NET/JAVA bis jetzt eher gefährlicher als ohne. Ausgesprochen viele Fixes beheben hier sicherheitsrelevante Probleme die das gesamte System betreffen. Ich nehme wenn schon dann eher lieber irgendwelche Funktionalitätsfehler in deiner Software in Kauf, als deine aus Kundensicht fast perfekte Soft die auf einem Fundament aufbaut der ständig etliche systemrelevanten Sicherheitsprobleme aufweist.

es geht dabei nicht um eine ausrede. sondern darum das getesteter code wiederverwendet werden kann, den man ansonsten extrem zeitaufwändig nachbilden muss. es macht heutzutage einfach keinen sinn ein problem zum xten mal neu zu lösen.
siehe das ganze mal wie in der "normalen" industrie. nur weil du autos herstellst, heißt es noch lange nicht das du auch reifen oder gar schrauben selbst baust.
das ganze kann man natürlich auch per zukauf von fremdframeworks erreichen aber dann kaufst du dir eine weitere unsicherheit dazu. denn wenn die firma die dahinter steckt mal pleite geht, hast du auch keinen support mehr. dabei gehe jetzt einfach mal davon aus, das microsoft oder sun so schnell nicht pleite gehen werden. man hat also 2 standarts die man nutzen kann um software mit erheblich weniger aufwand zu erstellen. zudem kann man die software direkt aufwärtskompatibel und maschinenunabhängig erstellen.

(del)

2009-10-04, 15:41:56

Wenn ich mich recht entsinne wurde die Studie während der Entwicklung von Windows 2000 erstellt. Entsprechend bezog sie sich auf NT 4. Im Bezug auf Größe kam man zu der durchaus interessanten Erkenntnis das mit steigender Projektgröße die Anzahl der Fehler zwar zunimmt aber die Anzahl der Fehler pro 1000 Zeilen dabei immer geringer wird.Das ist auch keinen Physikgesetzen zu verdanken ;) sondern der Projektierung. Hängt halt davon ab, wieviele Leute man auf das Projekt ansetzt. Was von den Vorstellungen bzw. Erfahrungswerten der Projektleitung abhängt und wie gut die Leute sind. Und was dann auch noch je nach Wichtigkeit des Moduls variert.
Eine Gesetzmäßigkeit kann man davon also nicht ableiten. Vista ist ein gutes Beispiel dafür, daß man schon gehörige Portion Erfahrung haben und das Kind trotzdem ersaufen kann. (was RTMs angeht)

Kritisch war bei IBM immer recht klar mit „Lost of Data“ definiert.Dann siehts nicht gut aus. 10 derartige kritische Fehler auf 1000 Zeilen ist sowieso schon der Hammer.
Für mich selbst ist aber auch sowas ein kritischer Fehler, wenn z.B. ein Office nicht so den Text um die Grafik schmiegt wie er vorgibt es zu können. Und das aber nur ab der fünften vollen Seite, wenn zwwischendurch "Symbol" benutz wird. Nur so als Beispiel. Zwischen lost of data und irgendwelchen schiefen GUI-Masken gibt es also ein ausreichend riesiges Feld, welches aus der Sicht des Benutzers nicht minder kritisch ist.

@][immy
Abwärtskompatibel? Das bedeutet für mich aktuell, daß ich mir dafür schon das vierte (?) NET-Framework ins System knallen müßte.
Davon ab erkenne ich nicht, daß du wirklich so auf die Passage eingegangen bist wie großzügig du sie gequotet hast.
Davon ab, daß 3.5er fast schon so fett ist wie W2k selbst ohne Treiber :uup:

siehe das ganze mal wie in der "normalen" industrie. nur weil du autos herstellst, heißt es noch lange nicht das du auch reifen oder gar schrauben selbst baust.Meinst du das jetzt so, daß Adobe beim Photoshop3 keine einzige Zeile vom Photoshop2 verwenden konnte?

][immy

2009-10-04, 20:23:59

Das ist auch keinen Physikgesetzen zu verdanken ;) sondern der Projektierung. Hängt halt davon ab, wieviele Leute man auf das Projekt ansetzt. Was von den Vorstellungen bzw. Erfahrungswerten der Projektleitung abhängt und wie gut die Leute sind. Und was dann auch noch je nach Wichtigkeit des Moduls variert.
Eine Gesetzmäßigkeit kann man davon also nicht ableiten. Vista ist ein gutes Beispiel dafür, daß man schon gehörige Portion Erfahrung haben und das Kind trotzdem ersaufen kann. (was RTMs angeht)

Dann siehts nicht gut aus. 10 derartige kritische Fehler auf 1000 Zeilen ist sowieso schon der Hammer.
Für mich selbst ist aber auch sowas ein kritischer Fehler, wenn z.B. ein Office nicht so den Text um die Grafik schmiegt wie er vorgibt es zu können. Und das aber nur ab der fünften vollen Seite, wenn zwwischendurch "Symbol" benutz wird. Nur so als Beispiel. Zwischen lost of data und irgendwelchen schiefen GUI-Masken gibt es also ein ausreichend riesiges Feld, welches aus der Sicht des Benutzers nicht minder kritisch ist.

@][immy
Abwärtskompatibel? Das bedeutet für mich aktuell, daß ich mir dafür schon das vierte (?) NET-Framework ins System knallen müßte.
Davon ab erkenne ich nicht, daß du wirklich so auf die Passage eingegangen bist wie großzügig du sie gequotet hast.
Davon ab, daß 3.5er fast schon so fett ist wie W2k selbst ohne Treiber :uup:
Bitte lesen, Aufwärtskompatibel, nicht abwärtskompatibel. Das soll heißen, auch auf zukünftiger Hardware oder einem zukünftigen betriebssystem wird noch alles so funktionieren wie 5 jahre zuvor.
zu der größe von .net 3.5 kann ich nur sagen, es beinhaltet auch verflucht viel. dafür kann ich dann auch x programme schreiben die nur 1 MB groß sind, aber einen gigantischen funktionsumfang aufweisen ;)
der vorteil ist einfach, diese Frameworks sind standartisiert, laufen auch in x jahren noch und werden von tausenden anderen entwicklern immer wieder getestet. wirklich schwerwiegende fehler beinhaltete das .net framework bisher nicht und die meisten anderen fehler kann man umgehen. allerdings musst du schon wirklich sehr tief in die materie gehen um wirklich fehler zu finden.
Aber wenn du willst kann du ja auch nur die basic von .net/java nehmen und alles selbst nachprogrammieren. ist ja auch kein problem. erfordert aber einiges an entwicklungszeit.

Meinst du das jetzt so, daß Adobe beim Photoshop3 keine einzige Zeile vom Photoshop2 verwenden konnte?
nein, das meine ich nicht.
es war darauf bezogen, das du meinst, das man mit solchen frameworks die schuld von sich selbst schiebt. das stimmt so nicht. ein autohersteller wird auch erstmal testen ob die reifen und schrauben halten, aber er wird sie nicht selbst herstellen.

wenn ich jetzt fies wäre, würde ich ja behaupten, das c und c++ selbst auch nur frameworks sind die auf den entsprechenden assemblercode aufsetzen und würde dich fragen warum wir wohl heute sogut wie nichts mehr in assembler-code machen. Mit deiner antwort hast du dann auch sofort deine antwort warum es häufig sinnvoller ist, mit frameworks wie .net oder java zu arbeiten, als das rad neu zu erfinden.

PS:
ich quote meistens mehr als ich müsste ;)

(del)

2009-10-05, 01:40:48

[immy;7575576']der vorteil ist einfach, diese Frameworks sind standartisiert, laufen auch in x jahren noch und werden von tausenden anderen entwicklern immer wieder getestet.Alleine "Tausende" von Programmen fehlen irgendwie. Das einzig wirklich fette was ich kenne ist Paint.NET. Dann kommt noch CDBurnerXP und die GUI von XPize =)

Wobei so ein Gespräch wiedermal gerne auf NET gelenkt wurde, obwohl es mir im Startbeitrag garnicht so darum ging. Bzw. wie man schonmal gleich an Paint.NET und CDburnerXP sehen kann, ist man mit einem Framework noch Lichtjahre von einer überdurchschnittlich niedrigen Fehleranzahl entfernt.

Solche Vorteile wie daß man sich mit weniger Leuten als sonst an größere Projekte trauen kann oder mit gleicher Anzahl schneller fertig wird bedeutet nicht, daß auch die Fehleranzahl in 1.0 sinkt. Und darum ging es mir.

Die Industrie oder wer auch immer werden ihre Vorteile aus diesen Technologie schöpfen. Wieviel davon am Kunden ankommen (Preise/Bugs) steht noch sehr wohl in den Sternen.

mapel110

2009-10-05, 02:24:24

.net wird mittlerweile von vielen kleinen Firmen verwendet. Es gibt nicht nur die Internet-User-Welt da draußen, sondern eben auch jede Menge Firmen, die für ihr Pfurzproblem eine Speziallösung wollen. Beispielsweise für RFID-Chips und dazugehörige portable Geräte entwickelt auch ein Kollege von mir in .net.
Das geht sehr komfortabel in Visual Studio.

Gast

2009-10-05, 04:37:07

Tja, die Welt wäre besser wenn die Programmierer alle auf D setzen würden.

Gast

2009-10-05, 04:59:08

Was interessieren hier Pfurzprobleme von irgendwelchen Firmen?

Coda

2009-10-05, 05:14:16

Tja, die Welt wäre besser wenn die Programmierer alle auf D setzen würden.
Könntest du das evtl. auch begründen?

Fehler macht man auch in D und gegen Heap-Korruption oder wilde Pointer kann die Sprache genauso wenig tun.

Gast

2009-10-05, 05:21:54

Könntest du das evtl. auch begründen?

Fehler macht man auch in D und gegen Heap-Korruption oder wilde Pointer kann die Sprache genauso wenig tun.

Ja, kann ich.

D ist wesentlich schlanker als C++, daher auch leichter zu lernen und damit auch zu beherrschen.

Oder anders gesagt, wieviele Jahre brauchst du, damit du sagen kannst, daß du C++ wirklich beherrschst?
Unter 10 Jahre wird's definitiv nix, unter 20 ist nur was für Masochisten und bei unter 30 Jahren wird's dann so langsam ehrlich, aber dieses Personal geht dann meist auch schon in Rente.

Bei C kann ich dir jedenfalls sagen, daß 3 Jahre genügen, aber C fehlen eben auch die Vorteile von D.
Daher ist D die ideale Wahl, denn die Probleme von Java und C# sind ja bekannt, ne fette VM in die man selbst keinen Einblick hat. (Halbwegs native Compiler die in der Regel nicht alle Features der Klassenbibliothek mehr oder weniger schlecht einbinden mal ausgenommen)

D läuft wenigstens nativ und bietet auch 2 schlanke Standardbibliotheken auf die man aber nicht unbedingt aufsetzen muß.
Das sind alles klare Vorteile von D.

Gast

2009-10-05, 05:23:54

http://en.wikipedia.org/wiki/D_(programming_language)

Gast

2009-10-05, 05:24:45

Jetzt sollte der link gehen:
http://en.wikipedia.org/wiki/D_(programming_language)

Exxtreme

2009-10-05, 09:47:10

Oder anders gesagt, wieviele Jahre brauchst du, damit du sagen kannst, daß du C++ wirklich beherrschst?
Es ist nicht das Problem die Sprache zu beherrschen. Geht auch mit C++ recht schnell. Das grössere Problem sind die Bibliotheken. Diese zu "beherrschen" macht weit mehr Aufwand als die Programmiersprache selbst.

Und gegen umfangreiche Klassenbibliotheken ist auch D nicht gefeilt. Es gibt sie in D vielleicht zur Zeit nicht und deshalb erscheint D schlank.

Aquaschaf

2009-10-05, 10:14:22

Es ist nicht das Problem die Sprache zu beherrschen. Geht auch mit C++ recht schnell.

Wenn man mit 'beherrschen' meint alle Eigenheiten der Sprache zu verstehen, dann geht das bei C++ nicht schnell. Aber man muss natürlich bei weitem nicht alles kennen um mit der Sprache produktiv arbeiten zu können.

Das sind alles klare Vorteile von D.

Das "Problem" sind die ganzen Libraries die in C++ geschrieben sind. Da man die nicht ohne weiteres verwenden kann ist D erst einmal unattraktiv.

ScottManDeath

2009-10-05, 10:37:02

Und gegen umfangreiche Klassenbibliotheken ist auch D nicht gefeilt. Es gibt sie in D vielleicht zur Zeit nicht und deshalb erscheint D schlank.

D hat doch schon 2 inkompatible Standardbibliotheken :rolleyes:

Exxtreme

2009-10-05, 11:06:05

Wenn man mit 'beherrschen' meint alle Eigenheiten der Sprache zu verstehen, dann geht das bei C++ nicht schnell. Aber man muss natürlich bei weitem nicht alles kennen um mit der Sprache produktiv arbeiten zu können.

Beherrschen ist sowieso so eine Sache wenn es verschiedene Compiler mit verschiedenen Eigenschaften gibt.

The_Invisible

2009-10-05, 13:14:39

meiner meinung nach kommt es auch auf die frameworks an, zb das qt-toolkit für c++ ist ein paradebeispiel, mit entsprechender ide hat man in handumdrehen eine entsprechende gui gebastelt. der code bleibt auch schön sauber und lesbar, den "mist" muss man auch nur selten selber aufräumen solange man im qt-framework bleibt.

zudem gibts eben die meisten libs nativ zuerst/nur für c/c++, wenn man sich nen wrapper bastelt kommt wieder eine fehlerquelle hinzu.

ich sehe es zudem nicht ein zusätzlich ressourcen zu verschwenden, nur weil wir es heute eh "haben". naja, werden wahrscheinlich ein paar kommen das man gleich win-api/mfc nehmen kann, aber bisschen komfort will ich ja auch noch haben, zudem gibts nicht nur windows. :D

mfg

Gast

2009-10-05, 18:11:04

D hat doch schon 2 inkompatible Standardbibliotheken :rolleyes:

Das wird mit D 2.0 gelöst sein, die Erfinder von D und der zweiten Standardbibliothek arbeiten daran, so daß beide Standardbibliotheken parallel verwendbar sind.

Gast

2009-10-05, 18:12:08

Das "Problem" sind die ganzen Libraries die in C++ geschrieben sind. Da man die nicht ohne weiteres verwenden kann ist D erst einmal unattraktiv.

Würde ich nicht sagen.
Denn die wichtigsten Bibliotheken sind sowieso in C geschrieben und die kann man von D aus ohne Wrapper nutzen.

Coda

2009-10-05, 18:14:24

Unter 10 Jahre wird's definitiv nix, unter 20 ist nur was für Masochisten und bei unter 30 Jahren wird's dann so langsam ehrlich, aber dieses Personal geht dann meist auch schon in Rente.
Da hast du leider so ziemlich recht damit...

Gast

2009-10-05, 21:15:43

Es ist nicht das Problem die Sprache zu beherrschen. Geht auch mit C++ recht schnell. Das grössere Problem sind die Bibliotheken. Diese zu "beherrschen" macht weit mehr Aufwand als die Programmiersprache selbst.

Das sehe ich anders.

Vergleiche einfach mal ein gutes Anfängerbuch für C und eines für C++.

Das für C++ ist mindestens doppelt so dick und liegt in der umfangreichen Funktionsvielfalt und Komplexität der Sprache begründet.
Mit Bibliotheken hat man da meist noch gar nicht angefangen. (Die STD & vielleicht auch STL mal ausgenommen)

Tiamat

2009-10-05, 23:12:19

Joa ich denk mir trotzdem, dass selbst bei Sprachen wie Java, C# oder nehmen wir D hinzu, Fehler nicht ausbleiben. Menschen machen Fehler, Maschinen führen nur die Befehle der Menschen aus, also auch ihre Fehler.

Ich denke, dass wird sich auch mit jeder noch so weiterentwickelten Sprachen weiter vollziehen. Selbst Webseiten mit PHP sind nicht perkekt.

Die Sprache kann also kein alleiniges Indiz dafür sein, fehlerfreie Software zu schreiben, selbst wenn sie noch so komfortabel ist.

Man wird es meiner Meinung erst dann schaffen, nahezu fehlerfreie Software zu entwickeln, wenn man Compiler hat, die semantische Fehler entdecken, so dass selbst nur der Hobbyprogrammierer zuhause darauf hingewiesen wird, dass er er den und den Sachverhalt gerade übersehen hat.

Und solche Compiler wird es noch lange lange Zeit nicht geben.
Bis sowas mal anständig funktioniert, vergehen Jahrzehnte.
Vielleicht sind die Agenten sogar ein erster Schritt auf dem Weg.

(del)

2009-10-06, 00:37:31

Und solche Compiler wird es noch lange lange Zeit nicht geben.
Bis sowas mal anständig funktioniert, vergehen Jahrzehnte.
Vielleicht sind die Agenten sogar ein erster Schritt auf dem Weg.Das ist eigentlich der Clou. Seit zig Jahren besserst sich auf dem Gebiet kaum etwas und die ersten halbwegs brauchbaren Lösungen prophezeihst du in zig Jahren =)
Ich wollte mit dem Thread irgendwie drauf aufmerksam machen, daß man jetzt langsam auch als Benutzer über sowas reden und meckern sollte, damit sich da endlich etwas tut. Algol ist so um 1968 rausgekommen und C dürfte bald auch 40 Jahre alt sein.

Da tat sich bis jetzt fast garnichts. Der Kunde macht keinen Druck. Es ist immernoch normal, daß man in einem neuen OS oder neuem Office (egal von wem und ob Kommerz oder Freeware) Tausende Bugs erwarten kann. Und das mit 100%er Sicherheit auch so ist.

Man verspricht zwar meist alle entdeckten Fehler in einem bestimmten Zeitraum zu beheben, aber wie und wann ist nie definiert. Bei XP z.B. ist man damit immernoch nicht fertig und wird damit mit dem endgültigen EOL 2014 auch noch lange nicht fertig sein.
Dabei wird XP auch auf längere Sicht durch seine extrem lange Lebensdauer das fehlerfreieste OS schlechthin sein. Ich schätze mal nach 13 Jahren "bug hunting" bleibt es bei nur noch paar Hundert Fehlern.
Mittlerweile kommt mir sowas wahnwitzig vor.

Spätestens seit der festverdrahteten Virtualisierung müßen sich Test- und Debuggumgebungen bauen lassen die massiv effektiver dem Programmierer unter die arme Greifen als aktuelle Lösungen.
Das ist auch mit den bis jetzt recht dürftig-leistungsfähigen Frameworks nicht erschlagen, denn im Gegensatz zu den Behauptungen von ][immy liest sich bei z.B. NET die Liste der gepatchten Probleme mit einzelnen Updates wie auch ganzen Servicepacks alles andere als entspannt.

eod

Gast

2009-10-06, 01:35:30

Ich denke, dass wird sich auch mit jeder noch so weiterentwickelten Sprachen weiter vollziehen. Selbst Webseiten mit PHP sind nicht perkekt.

PHP ist ja auch Müll.

Beispiel:
Mach ne Variable und weise ihr nen Wert zu, z.B:

$knallfutter = value;

Und dann nutze sie:
$knallfutter = $knalflutter + 4;

Der Code geht, aber er liefert das falsche Ergebnis.
Und das liegt darin begründet, daß die Variable $knalflutter nicht die Variable ist, mit der man eigentlich rechnen wollte und dabei auch noch undefinierte Werte enthält.

Bei richtigen Programmiersprachen passiert dir so ein Fehler nicht,
da ausnahmslos ALLE Variablen vor der Verwendung deklariert werden müssen.

string knallfutter;

Und wenn du das nicht machst oder folgendes schreibst:

knallfutter = knalflutter + 4;

dann schmeißt dir der Compiler ne Fehlermeldung um die Ohren inklusive und das ist das tolle, dem Hinweis in welcher Zeile sich der Fehler befindet und was der Fehler überhaupt ist.
Also in etwa so:
Undefined value in line 3: knalflutter not defined

In PHP habe ich wegen obigem Mist jedenfalls schonmal in einem größeren Programm 5 Stunden mit der Fehlermeldung verschwendet.
Und genau aus diesem Grund verwende ich bei PHP zum Programmieren nur noch Editoren, die mir alle verwendeten Variablen in einem extra Fenster auflisten. So entdeckt man wenigstens die Verschreiber leichter, das ist aber auch die einzige Umgehungshilfe.
Ein Fehler der Sprache ist es IMO dennoch.

Die Sprache kann also kein alleiniges Indiz dafür sein, fehlerfreie Software zu schreiben, selbst wenn sie noch so komfortabel ist.

Eine gute Sprache spart schonmal nicht an ausführlichen Fehlermeldungen und nutzt eine strenge Typisierung.

Man wird es meiner Meinung erst dann schaffen, nahezu fehlerfreie Software zu entwickeln, wenn man Compiler hat, die semantische Fehler entdecken, so dass selbst nur der Hobbyprogrammierer zuhause darauf hingewiesen wird, dass er er den und den Sachverhalt gerade übersehen hat.

Schlimm ist es doch, wenn nichtmal Syntaxfehler entdeckt werden oder diese geradezu heraufbeschworen werden, wie man am PHP Beispiel sehen kann.

Gast

2009-10-06, 01:43:19

Da tat sich bis jetzt fast garnichts. Der Kunde macht keinen Druck.

Der Kunde mag keine relativ modernen Sprachen wie Java, weil's nicht so aussieht wie der native Deskop oder weil es unmengen an Resourcen frißt.

Auch ist der Kunde nicht bereit die eigentlich notwendige qualitativ hochwertige Softwareentwicklung zu bezahlen, denn billig soll es sein und die Entwicklung schnell abgeschlossen sein.

Man verspricht zwar meist alle entdecken Fehler in einem bestimmten Zeitraum zu beheben, aber wie und wann ist nie definiert.

Das wird man auch nicht tun, da es einige wenige Fehler gibt, die neue Fehler in anderen Bereichen verursachen wenn sie gefixt werden würden.
Gerade Betriebssysteme und Bibliotheken sind davon betroffen.

Dabei wird XP auch auf längere Sicht durch seine extrem lange Lebensdauer das fehlerfreiesete OS bleiben.

Nö, das fehlerfreieste ist das mit dem qualitativ hochwertigsten Code Audit und ständigen Bugfixes.

Ich würde da z.B. in die OpenBSD Ecke schauen.

Das ist auch mit den bis jetzt recht dürftig-leistungsfähigen Frameworks nicht erschlagen, denn im Gegensatz zu den Behauptungen von ][immy liest sich bei z.B. NET die Liste der gepatchten Probleme mit einzelenen Updates wie auch ganzen Servicepacks alles andere als entspannt.

Ja, siehe oben, es gibt Fehler die man eigentlich gar nicht beheben will, weil es neue Probleme verursachen würde.
Also wartet man bis zum nächsten Major Release oder harten Schnitt.

Von .net 3.0 auf .net 4.0 kann man z.B. so etwas machen, innerhalb von 3.x geht das nicht so ohne weiteres.

(del)

2009-10-06, 02:23:51

p.s.:

Ja stimmt schon. Ich meinte aus Redmond ;)
Auch ist der Kunde nicht bereit die eigentlich notwendige qualitativ hochwertige Softwareentwicklung zu bezahlen, denn billig soll es sein und die Entwicklung schnell abgeschlossen sein.Wer wäre denn bitte z.B. angesichts von Gothic3 1.0 nicht bereit noch ein halbes Jahr zu warten? ;) Diese Frage stellt sich aber auch nicht, weil mein Thema war ja, daß für qualitativ hochwertige Produkte noch so ein immenser Aufwand betrieben werden muß. Es ging mir eher um die Werkzeuge und Methoden. Da wird nüchtern betrachtet seit zig Jahrehn nur Kosmetik betrieben.

Alles dreht sich immer schneller und wird immer besser, nur die Entwicklung der Entwicklung steht fast still.

Eine gute Sprache spart schonmal nicht an ausführlichen Fehlermeldungen und nutzt eine strenge Typisierung.C ist imho ganz festgefahren dank den hier erwähnten Quasi-Rentner.

Das ganze kam hier zustande, weil ich die Tage einige Sachen gebastelt habe und mich da vorfand wo ich schonmal 1995 war.

Ich hab auch vor 1000 Jahren ;) kleinwenig in Fortran rumkritzeln müßen und da scheint man das nicht so starr zu handeln. Es wird erweitert und standardisiert was nötig erscheint. Womit sich die Art zu schreiben und entwickeln verändert und vielerorts auch bessert. Irgendjemand investiert hier Geld und Zeit, weil es kommerz-wissenschaftlich genutzt wird (auch wenn Fortran2008 noch lange keine Perle ist).

Ansi-C/C++ hat dagegen keine Patenonkel und wirkt mittlerweile wie Latein. Eine mächtige tote Sprache...
Und GCC/Kompiler - so nebenbei - ist sowieso eine ewige wilde Baustelle (jedenfalls für x86). Ich kompilierte mal als Test einen RIPEMD Kode mit verschiedenen Versionen (gleiche cflags) und bekam Ergebnisse die bei Durschnittlichen 110 MB/s um ~35MB/s hin und her schwankten. Und man sollte ja nicht glauben, daß je neuer der GCC, desto besser das Ergebnis.

Wenn ich mir das ganze Zeug in seiner Gesamtheit und auch selbst samt VC2008 ansehe, dann wirkt das auf mich - mit genügend Abstand betrachtet :| - völlig unprofessionell und total urarchaisch. Hej Leute wir schreiben bald 2010.

Da kann man zwar meckern, aber über sehr große Projekte die mit 1.0 Tausende Fehler enthalten braucht man sich echt nicht wundern. Die C-Jünger und -Gurus schmorren im eigenen Saft und trauen sich nichtmal die C-Greisen auch nur anzuschauen. Wie in der Politik. Zum Kotzen :mad:

Boah jetzt ist aber genug ;) Ich glaub ich zieh mir im Winter Oberon-2 rein :tongue:

Coda

2009-10-06, 02:39:35

Das sehe ich anders.
Ich auch. Die meisten bringen ja noch nichtmal const correctness zusammen ;)

Aber: Ich mag D nicht. Aus irgend einen Grund halte ich das für den falschen Weg. Leute die die Mächtigkeit von C++ nicht beherrschen brauchen auch keine Pointer anfassen X-D

Eine gute Sprache spart schonmal nicht an ausführlichen Fehlermeldungen und nutzt eine strenge Typisierung.
Jetzt lehnst du dich aber weit aus dem Fenster. Strenge Typisierung ist eine Sache die gut und schlecht sein kann. Deklarationen sollte man aber wirklich drin haben.

Nö, das fehlerfreieste ist das mit dem qualitativ hochwertigsten Code Audit und ständigen Bugfixes.

Ich würde da z.B. in die OpenBSD Ecke schauen.
Du unterschätzt Microsoft gewaltig in der Hinsicht. Die haben nach dem XP-Debakel gewaltig in diese Richtung investiert. Es gibt keinen Code mehr der dort nicht auf Sicherheit geprüft wird.

Der Hypervisor den sie zur Zeit schreiben beweisen sie im Moment auch komplett mathematisch durch.

Gast2

2009-10-06, 02:54:29

Du unterschätzt Microsoft gewaltig in der Hinsicht. Die haben nach dem XP-Debakel gewaltig in diese Richtung investiert. Es gibt keinen Code mehr der dort nicht auf Sicherheit geprüft wird.War das nicht schon bei XPSP2 so? Oder bei XPSP3? Oder meinst du das jetzt weil es keine Sicherheitsfixes für Vista gab? Oder meinst du es wird keine für Win7 geben?

Gast

2009-10-06, 02:57:35

Es hat auch niemand gesagt daß Redmond den Code seit einiger Zeit nicht nach Möglichkeit sorgfältig prüft. Relevant ist letztendlich aber nur das Ergebnis dessen.

Coda

2009-10-06, 03:00:47

So viel Lücken wie in XP gab's in Vista ja auch lange nicht.

Das größte war soweit ich weiß der SMB2-Exploit neulich.

Gast

2009-10-06, 04:27:27

Dem Thema entsprechend hat das Vista2007 aber nicht davor bewahrt gleichviele Funktionsfehler wie XP2001 zu enthalten ;)

Tiamat

2009-10-06, 08:10:37

Aquaschaf

2009-10-06, 08:22:07

Semantische Fehler im Allgemeinen zu erkennen ist unmöglich.

Gast

2009-10-06, 12:37:08

So viel Lücken wie in XP gab's in Vista ja auch lange nicht.

Das größte war soweit ich weiß der SMB2-Exploit neulich.Was bedeutet groß? Wenn MS sich bemüht etwas mit einem Sicherheitshotfixzu patchen, dann ist das groß. Egal welche Stufe MS dem Patch zuspricht.

Das meiste liegt eh nur an den zum Zeitpunkt bekannten Ideen und Methoden. Mal gucken wann die ersten aktuell sehr populären NULL pointer dereference (Funktionspointer) Löcher in Vista und Win7 (in XP sowieso) auftauchen und ob die erstgenannten am Ende weniger davon haben als XPsp3.

The_Invisible

2009-10-06, 12:57:35

PHP ist ja auch Müll.

Beispiel:
Mach ne Variable und weise ihr nen Wert zu, z.B:

$knallfutter = value;

Und dann nutze sie:
$knallfutter = $knalflutter + 4;

Der Code geht, aber er liefert das falsche Ergebnis.
Und das liegt darin begründet, daß die Variable $knalflutter nicht die Variable ist, mit der man eigentlich rechnen wollte und dabei auch noch undefinierte Werte enthält.

Bei richtigen Programmiersprachen passiert dir so ein Fehler nicht,
da ausnahmslos ALLE Variablen vor der Verwendung deklariert werden müssen.

string knallfutter;

Und wenn du das nicht machst oder folgendes schreibst:

knallfutter = knalflutter + 4;

dann schmeißt dir der Compiler ne Fehlermeldung um die Ohren inklusive und das ist das tolle, dem Hinweis in welcher Zeile sich der Fehler befindet und was der Fehler überhaupt ist.
Also in etwa so:
Undefined value in line 3: knalflutter not defined

In PHP habe ich wegen obigem Mist jedenfalls schonmal in einem größeren Programm 5 Stunden mit der Fehlermeldung verschwendet.
Und genau aus diesem Grund verwende ich bei PHP zum Programmieren nur noch Editoren, die mir alle verwendeten Variablen in einem extra Fenster auflisten. So entdeckt man wenigstens die Verschreiber leichter, das ist aber auch die einzige Umgehungshilfe.
Ein Fehler der Sprache ist es IMO dennoch.

Eine gute Sprache spart schonmal nicht an ausführlichen Fehlermeldungen und nutzt eine strenge Typisierung.

Schlimm ist es doch, wenn nichtmal Syntaxfehler entdeckt werden oder diese geradezu heraufbeschworen werden, wie man am PHP Beispiel sehen kann.

also ich habe noch nie 5 stunden (!) für eine fehlermeldung bei php gebraucht um den fehler zu finden, das seit 10 jahren und selbst bei zigtausenden zeilen umfassenden projekten. ka was du da verbrochen hast. die fehlermeldungen sind zwar nicht immer logisch, zeigen aber zumindest immer ungefähr die stelle wo es probleme gibt.

php seit version 5 ist zudem nicht mehr so schlecht wie immer getan wird. hält natürlich keinem ab spaghetticode zu schreiben wie in C++ auch, aber es ist schön strukturierter quellcode möglich. wenn man aus anderen sprachen kommt dürfte das initialisieren eh schon in fleisch und blut übergegangen sein, außerdem kann man die notices eh so weit hochdrehen das bei uninitialisierte variablen gemeckert wird.

mfg

Exxtreme

2009-10-06, 13:25:02

Das sehe ich anders.

Vergleiche einfach mal ein gutes Anfängerbuch für C und eines für C++.

Das für C++ ist mindestens doppelt so dick und liegt in der umfangreichen Funktionsvielfalt und Komplexität der Sprache begründet.
Mit Bibliotheken hat man da meist noch gar nicht angefangen. (Die STD & vielleicht auch STL mal ausgenommen)
Wenn man bedenkt, daß C zu C++ gehört sollte man sich nicht wundern, daß C++ dicker ist. ;)

Wie dem auch sei, daß C++ komplexer ist bezweifle ich nicht. Ich denke aber nicht, daß man wirklich Jahrzehnte braucht um das zu beherrschen. Die Sprache an sich ist nur Syntax + die Konzepte + paar Schlüsselwörter. Und das ist in C++ kein echtes Hexenwerk.

Der Rest sind Klassenbibliotheken.

Krishty

2009-10-06, 16:05:50

Es auf die Sprachen zu schieben ist doch naiv. Die Programmiersprache, das Framework, die Code-Analyse – all das sind nur Werkzeuge. Die Entscheidungen trifft immernoch der Software-Engineer, und der trifft eben auch falsche. Werkzeuge können ihn darauf aufmerksam machen – ein Debugger, der zum Knackpunkt führt, ein Compiler, der das Programm syntaktisch verifiziert, oder eine Programmiersprache, die fehleranfällige Dinge wie Zeiger von vornherein ausschließt.

Aber auch das beste Werkzeug nützt nichts, wenn der anwendende Entwickler eine Niete ist. Egal, wie fortgeschritten das Framework ist und wie einfach die Sprache zu erlernen ist, es bringt doch alles nichts, wenn dort ein Depp am Werk ist, der Exceptions als Rückgabewerte benutzt und Objekte aus hilflos zusammengekratzten Eigenschaften voneinander erben lässt. Umgekehrt kann ein Experte immernoch ein beweisbar korrektes Programm in C schreiben.

Dass es auf dem Gebiet keine Durchbrüche gibt (sondern nur kleine, aber stetige Fortschritte) liegt daran, dass Entwickler heute nicht soviel besser ausgebildet sind, wie sie es für die gewachsene Vielfalt im Beruf sein müssten, sondern dass vor allem ihre Arbeitsumgebung ständig verbessert wurde/wird (Software ist eben formbarer als die menschliche Hardware).

Außerdem mag der Bedarf an Software exponentiell steigen, aber Nerds werden wir immer gleich viele haben ;)

––––––––

Wie kann man behaupten, dass die Fehler in Software nicht weniger würden und dass dieser Zustand nicht mehr haltbar sei?

Erinnert ihr euch noch an die späten 90er-Jahre? Schmiert euer Firefox mit Vista wirklich so oft ab, wie der Internet Explorer unter Windows 98 allgemeine Schutzverletzungen produziert hat? Zumal heute zig Mal soviel Funktionalität verfügbar ist wie damals? Wird eure Maschine immernoch alle zwei Tage von einem neuen Schadprogramm befallen? Vernichtet euer Office immernoch mehrmals am Tag eure Dokumente?

Bevor mir jemand Statistiken vorlegen kann, die das (für etwas anderes als die Spieleindustrie) beweisen, glaube ich es nicht (zumal Statistiken für XP/Vista/7, wie schon erwähnt wurde, das Gegenteil vermuten lassen). Mit diesen Aufrufen, so könne es nicht weitergehen und die Kunden müssten sich endlich mal wehren, verleihen doch nur Leute ihrer Wut Ausdruck, die sich mal wieder ein Spiel gekauft haben, das nicht vor dem zweiten Patch lauffähig ist … dabei ist doch genau das der Beweis dafür, dass sich etwas getan hat:

PC-Spiele sind – von Handys beiliegender Synchronisationssoftware abgesehen ;) – immernoch die Software-Sparte, in der am wenigsten Wert auf Robustheit und Code-Qualität gesetzt wird, weil sie im Gegensatz zu OS, Browser und Office-Programm nie missionskritisch sind. Intensive Qualitätssicherung erfahren die meisten doch überhaupt nur durch Zwang, wenn sie für Konsolen portiert werden. Es stimmt, dass Spiele vor 15 Jahren kaum oder keine Patches gebraucht haben – aber sie waren auch nicht fehlerfrei und extrapoliert man ihre Fehlerraten entsprechend dem Wachstum an Content und Spielfreiheit sowie Fortschritten wie Multi-Threading oder der Bedienung einer größeren Hardware-Vielfalt, dürfte man ungefähr zur Qualität heutiger Games kommen.

Oder kurz: Wenn man heute mehr Patches für seine Spiele braucht als für Windows, merkt man, wo wir gelandet wären, wenn sich nichts verbessert hätte.

––––––––

Springt ein bisschen aus dem Rahmen der Diskussion, aber ist mein Senf dazu :)

Gruß, Ky

Coda

2009-10-06, 17:19:49

Was bedeutet groß?
Remote Exploit.

Ich denke aber nicht, daß man wirklich Jahrzehnte braucht um das zu beherrschen.
Meiner Erfahrung nach: Doch, tut man.

oliht

2009-10-06, 18:18:02

So viel Lücken wie in XP gab's in Vista ja auch lange nicht.

Das größte war soweit ich weiß der SMB2-Exploit neulich.

Also Microsoft tut inzwischen schon ne ganze Menge zur Windows Stabilität. Was die mit SLAM bzw. Static Driver Verifier auf die Beine gestellt haben ist schon wirklich beachtenswert.

Benutzt jemand in der Unix Welt so etwas (Apple)?

oliht

2009-10-06, 18:22:07

Aber auch das beste Werkzeug nützt nichts, wenn der anwendende Entwickler eine Niete ist. Egal, wie fortgeschritten das Framework ist und wie einfach die Sprache zu erlernen ist, es bringt doch alles nichts, wenn dort ein Depp am Werk ist, der Exceptions als Rückgabewerte benutzt und Objekte aus hilflos zusammengekratzten Eigenschaften voneinander erben lässt. Umgekehrt kann ein Experte immernoch ein beweisbar korrektes Programm in C schreiben.

Der Programmierer muss gar keine Niete sein. Wenn das Projekt groß genug ist knallt es immer an falsch verstandenen Spezifikationen, solange man die nicht formal beschreibt (oder eher beschreiben kann).

Monger

2009-10-06, 19:01:04

Das ist eigentlich der Clou. Seit zig Jahren besserst sich auf dem Gebiet kaum etwas und die ersten halbwegs brauchbaren Lösungen prophezeihst du in zig Jahren =)
Ich wollte mit dem Thread irgendwie drauf aufmerksam machen, daß man jetzt langsam auch als Benutzer über sowas reden und meckern sollte, damit sich da endlich etwas tut. Algol ist so um 1968 rausgekommen und C dürfte bald auch 40 Jahre alt sein.

Da tat sich bis jetzt fast garnichts. Der Kunde macht keinen Druck.

Ich glaube, du unterschätzst völlig, was das zentrale Problem hier ist.

Ein Programm ist an und für sich erstmal sinnlos - erst der Mensch ist sinnstiftend. Aus Sicht des Computers ist es überhaupt kein Problem, wenn der kleine Button mit der Schere den Text löscht, statt ihn auszuschneiden.

Syntaktische Fehler kriegt der Compiler mittlerweile hin. Er kann sogar ein bißchen kontextbasiert arbeiten, und z.B. einen warnen, wenn Variablen nur geschrieben aber nie gelesen werden o.ä.

Aber die Festlegung, was denn die Software zum Schluss wirklich tun soll, das kann nur der Mensch. Und daran hapert es.
In dem Feld hat man durchaus einiges in den letzten Jahrzehnten probiert. Vor zehn Jahren hat man schon proklamiert, dass man irgendwann nur noch ein UML Diagramm hinzimmern muss, und danach kommt lauffähiger Code raus. Das wird mittlerweile auch ganz gern für rapid Prototyping eingesetzt - aber das eigentliche Problem, nämlich dir die Arbeit zu ersparen dir sehr genau darüber im klaren zu sein was du eigentlich haben willst, hat auch dieser Ansatz nicht geschafft.

Es gibt mittlerweile Code-Analyse Tools, die eine Ansammlung an "Best Practices" prüfen können. Das hilft natürlich. Was Debugging und Codeprüfung angeht, haben wir in den letzten zehn Jahren imho schon Fortschritte gemacht.
Aber was du hier forderst - nämlich so etwas wie eine Computerintelligenz die besser über die Entwicklungsanforderungen bescheid weiß als der Entwickler selbst - darauf kannst du lange warten.

Coda

2009-10-06, 19:15:19

oliht

2009-10-06, 19:59:01

Es gibt auch Code Theorem Provers. Das heißt man gibt in Funktionsannotationen an was die Funktion genau machen soll und der Theorem Prover überprüft es.

Naja zumindest in der Theorie funktioniert das. Außer für Ansi-C kenne ich keine Tools, wo man Programmcode direkt benutzen kann.

Gast

2009-10-07, 04:39:52

Monger es geht nicht um Entwicklungsanforderungen. Eigentlich geht es auch nicht um das Programmieren selbst, wenn man das Kernthema stark fokusiert.

Denn das primäre Problem bei großen bis sehr großen Projekten, die mit wenigen Ausnahmen größtenteils dem kommerziellen Umfeld entstammen, ist die Tatsache, daß die meisten QS-Projektmanager durch den Druck von oben zu Schlampen mutieren. Und mit der Zeit auch stark abstumpfen. Das überträgt sich dann mit der Zeit auf die Programmierer in solchen Teams.

Erst bei mittleren bis kleineren gratis Projekten die aus wenigen Programmierer bis zu one man show gehen, kann man über die Schlampigkeit und Unvermögen des Programmierers selbst sprechen.

Nicht bei jedem Fehler packt sich der versiertere Benutzer gleich am Kopf und schärft den Messer. Manchmal verursachen sogar an sich weniger folgereiche Fehler mehr Emotionen als grobe Fehlfunktionen.
Wenn du die Taskleiste nach oben verlegst und WMP beim jeden zweiten Aufspringen die top bar seines Fensters UNTER die Taskleiste schiebt, und das testweise jahrelang, dann fragt man sich wirklich was solche Clowns in Teilen des Systems veranstalten, die du auf keine Weise überprüfen kannst.

Die allgemeine Fehlerhaftigkeit der Programme ist einfach schlecht. Ob es an den IDEs, der Lehre des Debuggins oder dem unvermögen des Programmieres selbst liegt ist zweitrangig.
Irgendeine Software besteht aus Milionen Zeilen Kode. Eine CPU aus Milionen Transistorschaltungen. Die Fehlerhaftigkeit selbst der ersten rtm masken von AMD und Intel wäre für zb. Microsofts neuem BS ein Traumergebnis.
Solche Komplexität ist also annehmbar beherrschbar.

Aquaschaf

2009-10-07, 08:25:42

Ich glaube du unterschätzt wie viele Fehler Hardware hat ;) Wobei es bei GPUs z.B. viel schlimmer ist als bei CPUs wegen den kürzeren Lebenszyklen der Architekturen.

Expandable

2009-10-07, 08:48:23

Es gibt auch Code Theorem Provers. Das heißt man gibt in Funktionsannotationen an was die Funktion genau machen soll und der Theorem Prover überprüft es.

Damit kann man dann gewährleisten dass Spezifikationen eingehalten werden - ob die dann richtig sind steht nochmal auf einem anderen Blatt.

Gibt es zwar, das Problem ist aber im Allgemeinen unentscheidbar und die verwendeten Algorithmen sind dann meist auch noch NP-vollständig :freak:

Monger

2009-10-07, 09:13:27

Denn das primäre Problem bei großen bis sehr großen Projekten, die mit wenigen Ausnahmen größtenteils dem kommerziellen Umfeld entstammen, ist die Tatsache, daß die meisten QS-Projektmanager durch den Druck von oben zu Schlampen mutieren.

Da hast du natürlich ein Stück weit recht. Es hat sich immer noch nicht herumgesprochen, dass überzogene Terminanforderungen das Projekt wesentlich später fertig werden lassen als realistische Zielsetzungen. Das kommt daher, dass im industriellen Bereich da gerne die selben Verfahrensweisen angewendet werden wie bei der Fließbandarbeit. Da bringt es nämlich tatsächlich was, die Peitsche zu schwingen.
Trotzdem: selbst mit einer guten Arbeitsmoral und ausreichend Zeit gehen viele Projekte trotzdem in die Hose.

Erst bei mittleren bis kleineren gratis Projekten die aus wenigen Programmierer bis zu one man show gehen, kann man über die Schlampigkeit und Unvermögen des Programmierers selbst sprechen.

Mir geht es nicht um den Programmierer. Der ist in gewisser Weise nur die "Tippse", und setzt halt die Anforderungen aus dem Pflichtenheft um. Was ihren Bereich angeht, sind auch die Programmierer hier alle Spitze. Nur: der Chefdesigner, bzw. der Softwarearchitekt müssen klar formuliert haben was sie eigentlich haben wollen. Das funktioniert in der Realität einfach nicht.

Irgendeine Software besteht aus Milionen Zeilen Kode. Eine CPU aus Milionen Transistorschaltungen. Die Fehlerhaftigkeit selbst der ersten rtm masken von AMD und Intel wäre für zb. Microsofts neuem BS ein Traumergebnis.
Solche Komplexität ist also annehmbar beherrschbar.
Der Vergleich ist unfair, denn eine CPU ist aus logischer Sicht nicht besonders komplex. Der Befehlssatz von x86 umfasst ein paar hundert Instruktionen - wenn die einmal umgesetzt sind, werden die "nur noch" vervielfältigt. An der API hat sich seit einigen Jahrzehnten nichts geändert. Die Theorie hinter solcher Transistorlogik ist mitunter einige hundert Jahre alt... booleesche Logik war schon lange gut erforscht, bevor sie praktisch brauchbar wurde.

An der Funktionalität von CPUs wird mittlerweile herzlich wenig geändert - nur an der Performance wird regelmäßig gearbeitet. Deshalb sind die x86 CPUs auch seit gut 20 Jahren ziemlich bugfrei.

Für andere Hardware gilt das bei weitem nicht. Wenn ich da an die Firmware unserer speicherprogrammierbaren Steuerungen denke... ;)

Ganon

2009-10-07, 09:27:38

Da hast du natürlich ein Stück weit recht. Es hat sich immer noch nicht herumgesprochen, dass überzogene Terminanforderungen das Projekt wesentlich später fertig werden lassen als realistische Zielsetzungen.

Jup, aber da kann meist der Kunde und der Hersteller nicht viel. Das ist schlicht der Markt. Wenn du an den Verhandlungstisch gehst und realistisch bist, dann kriegst du den Auftrag garantiert nicht, da du a) zu lange brauchst und b) zu teuer bist.

Der Kunde weiß es schlicht nicht besser. Für den ist Programmierung so etwas wie "zusammenklicken" eines Bildes.

Und es zeigt sich auch, dass der Kunde nach der Auftragserteilung manchmal gar nicht so sehr am Zeitplan hängt. Der will dann lieber, dass man noch irgend eine "vergessene" Anforderung schnell mal zwischen schiebt.

An der Funktionalität von CPUs wird mittlerweile herzlich wenig geändert - nur an der Performance wird regelmäßig gearbeitet. Deshalb sind die x86 CPUs auch seit gut 20 Jahren ziemlich bugfrei.

Nunja, dafür ist das Erratum einer modernen CPU aber ziemlich lang ;)

MuLuNGuS

2009-10-07, 10:52:07

Im Tollchain Bereich wird sehr viel C# genutzt. Bei den eigentlichen Spielen scheitert es ja bisher an der fehlenden Unterstützung auf den Konsolen. Da nun fast jedes Team sich zu mindestens die Option auf Multiplattform offen halten will sieht es bei den Spielen selbst momentan noch eher schlecht aus. Ich weiß allerdings das bei den SIMs C# für das Skript System benutzt wird. Ebenso weiß ich das unsere Server in C# programmiert sind. Andere Teams haben Java für die Server benutzt.

Zusammengefasst kann man sagen dass dort wo es technisch möglich ist immer häufiger auf Alternativen zu C++ gesetzt wird. Was zukünftige Planungen angeht darf ich wie üblich nichts sagen solange nichts offiziell angekündigt ist.

hmm..finde ich aber schon beachtlich das die server in C# geschrieben sind, man hätte sicher auch bei locker bei C++ bleiben können.

Ganon

2009-10-07, 10:57:34

hmm..finde ich aber schon beachtlich das die server in C# geschrieben sind, man hätte sicher auch bei locker bei C++ bleiben können.

Bei C# kriegt man den Bufferoverflow-Schutz kostenlos dazu und die Programmierung ist auch deutlich einfacher. Vor allem in der Wartung.

Demirug

2009-10-07, 12:03:20

hmm..finde ich aber schon beachtlich das die server in C# geschrieben sind, man hätte sicher auch bei locker bei C++ bleiben können.

Für C++ gab es keinen guten Grund.

Gast

2009-10-07, 12:16:40

An der Funktionalität von CPUs wird mittlerweile herzlich wenig geändert - nur an der Performance wird regelmäßig gearbeitet. Deshalb sind die x86 CPUs auch seit gut 20 Jahren ziemlich bugfrei.Nein nicht wirklich. Die Umsetzung der API ist seit 20 Jahren bugfrei. So "ziemlich bugfrei" läßt sich von keiner CPU behaupten.

MuLuNGuS

2009-10-07, 14:43:20

Bei C# kriegt man den Bufferoverflow-Schutz kostenlos dazu und die Programmierung ist auch deutlich einfacher. Vor allem in der Wartung.

dessen bin ich mir bewußt, dennoch wird deshalb nicht immer gleich auf C# gesetzt.

Für C++ gab es keinen guten Grund.

gibt's den eigentlich auch ambitionen/gedanken mal einen komplette große engine in C# zu schreiben?

bisher beschränkt man sich ja eher auf tools usw., immerhin ist auch der Frostbite Editor in C# geschrieben.

laut Miguel de Icaza (Mono) wird der trend dahin gehen nur noch den kern der engine in C++ zu schreiben(der vielleicht auch direkt auf der grafikkarte ausgeführt wird) und das restliche logikzeugs in z.b. C#.

Ganon

2009-10-07, 14:48:57

dessen bin ich mir bewußt, dennoch wird deshalb nicht immer gleich auf C# gesetzt.

Er hat doch C# oder Java geschrieben. Welche anderen großen Managed-Sprachen mit C(++) Ähnlichkeit kennst du noch?

gibt's den eigentlich auch ambitionen/gedanken mal einen komplette große engine in C# zu schreiben?

Er hat doch schon geschrieben, dass es nicht gemacht wird, weil man auf den Konsolen meist nur mit C++ arbeiten kann.

MuLuNGuS

2009-10-07, 14:59:11

Er hat doch C# oder Java geschrieben. Welche anderen großen Managed-Sprachen mit C(++) Ähnlichkeit kennst du noch?

keine ahnung was du jetzt meinst, wollte nur zum ausdruck bringen dass es halt noch nicht selbstverständlich ist C# zu nutzen auch wenn keine grafik zum einsatz kommt.

vielleicht erbarmt sich ja doch einer des PCs.

wie ist es denn mit dem offiziellen Xbox360 devkit..nur c++ und C# nur für XNA?

Demirug

2009-10-07, 15:21:30

keine ahnung was du jetzt meinst, wollte nur zum ausdruck bringen dass es halt noch nicht selbstverständlich ist C# zu nutzen auch wenn keine grafik zum einsatz kommt.

vielleicht erbarmt sich ja doch einer des PCs.

Arenawars ist vollständig in C# programmiert.

wie ist es denn mit dem offiziellen Xbox360 devkit..nur c++ und C# nur für XNA?

XNA ist die Brandmark die alles umfast.

Die C# Sache ist das XNA Game Studio. Derzeit kann man damit nur Spiele für das Downloadportal entwickeln. Für boxed Products ist es nicht freigegeben.

Shink

2009-10-07, 16:04:17

Irgendwie scheint mir der ganze Thread etwas seltsam. Naja, vielleicht wohne ich auf einer Insel der Seligen; so abseits der Spiele- und Betriebssystementwicklung im J2EE-Bereich.

Bezüglich Anzahl Programme die in Java/C# entwickelt wurden:
Laut einer Studie gab es 2005 mehr Java Swing-Entwickler als WinForms-Entwickler:
http://weblogs.java.net/blog/hansmuller/archive/2005/10/official_swing.html

Stellt sich für viele sicher die Frage: WTF?
Ganz einfach: Individualentwicklungen werden üblicherweise nicht in C++ geschrieben. Und davon gibt es nunmal mehr als man als Home-User zu Gesicht bekommt.

Bezüglich Fehler:
Test-First-Programming + Integration Tests + Acceptance Tests -> was schiefgeht ist entweder niemandem aufgefallen, es sieht niemand als Fehler an oder der Kunde ist selbst schuld dass er den Fehler nicht meldet. Oder es wird behoben. Regressionen sind kein Thema da man ja die bestehende Testbasis dahinter hat.
Für mich fällt das unter das Thema "heutige Methoden".

Bezüglich böse Standard-Libraries:
- Niemand wird gezwungen sie zu nutzen. In keiner Programmiersprache. Ich benötige z.B. eigentlich nichts aus den Java-Libraries um turing complete zu sein.
- Wer etwas bastelt das besser getestet ist als das bekommt einen Keks.
- Wer einen Fehler entdeckt darf ihn ausbessern. Naja, bei Java zumindest.

Expandable

2009-10-08, 09:28:27

Ich benötige z.B. eigentlich nichts aus den Java-Libraries um turing complete zu sein.

Turing-complete sind alle vernünftigen Programmiersprachen (C++ beinhaltet gar gleich 3 turing-vollständige Sprachen ;)). Mit Ausnahme von Sql. Das wird nur durch vendor-specific Erweiterungen turing-vollständig :freak:

Shink

2009-10-08, 09:57:41

(C++ beinhaltet gar gleich 3 turing-vollständige Sprachen ;)).
In der J2EE-Welt hat man das leider auch schon doppelt und dreifach sobald man z.B. eine Rules-Engine verwendet.
So toll find ich das eigentlich nicht.

Neomi

2009-10-08, 10:40:24

Turing-complete sind alle vernünftigen Programmiersprachen [...]. Mit Ausnahme von Sql.

SQL ist keine Ausnahme im bereich der "vernünftigen Programmiersprachen", weil es nichtmal eine Programmiersprache ist. Es ist bloß eine Datenabfrage- und Datenmanipulationssprache.

Misda

2009-10-08, 12:25:35

mekakic

2009-10-09, 13:39:39

Bei .Net hat man den Vorteil das man jederzeit einen Dump ziehen kann und den genauen Aufbau des Heaps bekommt. Wie muß ich mir sowas vorstellen? Gibt es irgendwelche bildlichen Beschreibungen, wie ich den Dump eines typisierten .NET Heaps zum Debuggen verwenden kann? Wie sieht so eine Heap Analyse denn aus?

ESAD

2009-10-09, 15:07:40

wegen bugfixes bei java. es ist auch für .net möglich bugs zu melden und man erhält dann eigentlich recht schnell rückmeldungen und hilfen von ms, auch als kleiner entwickler. bei größeren firmen wird schonmal ein meeting mit ms entwicklern abgehalten (da fliegt man dann hald in die usa, reger mailverkehr und telefonate inbegriffen) etc. um über das problem zu reden und es zu lösen.

Shink

2009-10-09, 15:12:41

ESAD

2009-10-09, 15:45:02

TheGamer

2009-10-09, 16:50:15

][immy

2009-10-09, 19:02:29

Ja, um die Qualität der .NET-Library mach ich mir auch relativ wenig Sorgen. Das schöne bei Java ist eben dass man im Sourcecode nachsehen oder auch nur einfach rumfummeln darf. Das macht es natürlich leichter ein Problem einzugrenzen/zu verstehen o.ä.

Oder gibt es den .NET-Sourcecode irgendwo für Normalsterbliche "zum anschaun"?

jep die möglichkeit gibt es

Ja man kann sogar wenn man es konfiguriert hat beim Debuggen in den .NET Code reinsteppen um etwas vielleicht einfacher zu verstehen. Aber aendern kann man den nicht (sind nur die Symbol Files)

wobei man erwähnen sollte, das mit mit einem tool wie Reflector den SourceCode jeder .net DLL anschauen kann, wenn auch etwas unlesbarer als das original. Das geht sogar soweit das man den code auch on the fly in andere .net Programmiersprachen übersetzen kann und als Projekt abspeichern.

Das ist vermutlich auch ein Grund warum viele .net & java verabscheuen. Man entwickelt quasi immer open-source.

Der große vorteil daran, wenn man eine Fremd-komponente nutzt und diese einen fehler wirft, kann man den fehler auch selbst finden, melden und vermeiden. Oder gar selbst korregieren, weil man ja sehen kann was vielleicht noch zusätzlich benötigt wird.

Gast

2009-10-10, 01:06:57

Das größte war soweit ich weiß der SMB2-Exploit neulich.Für Win7 erscheint der erste security patch noch vor seinem Erscheinen
http://www.computerbase.de/news/software/betriebssysteme/windows/windows_7/2009/oktober/erste_sicherheitsupdates_windows_7/

Kleine Sicherheitslücke, große, größte. Was ist das? Wir brauchen uns nichts selbst einreden. Win7 wird nicht weniger Lücken und Fehler haben als es zwischen XPsp2 und XPsp3 gab. Und als Vista bis jetzt hatte.

Es ist zwar schön daß sie ab XPsp2 das Geld in wichtige Schwerpunkte investieren, wirklich überblicken können sie es aber nicht. Was jetzt nicht heißen soll daß ein Solaris10 da besser wegkommt.

Es sind eben die Methoden.