MFC -> tod
-
AndreasW schrieb:
Wenn jeder sich nur an offene Standards halten würde und komerzverseute Lösungen, auch wen sie noch so reizvoll sind, ignoriert, ist sowas möglich. Womit wir wieder bei der Grundidee von Unix sind. Das Problem bei der Umsetzung ist nicht Microsoft sondern WIR, die Entwickler.
Schlechtes Wochenende gehabt?
Zum einen sieht man doch sehr schön am Beispiel von C++, das die ISO-Standards nicht viel taugen. Bis der nächste Standard kommt, sind schon zwei weitere OS-Generationen ins Land gezogen, und der Standard wird immer noch von einer sequentiellen Bandmaschine mit Streaming ausgehen... wenn's gut läuft ist Multithreading im Standard enthalten, aber von Dingen wie Datenbank, XML oder GUI darf man weiterhin träumen.
Ist doch kein Wunder, daß jeder dann seine eigene Suppe kochen muß.
Aber die Entwickler sind wirklich ein Problem, wie man an den vielen Flamewars seit Anbeginn der Zeit sehen kann... das alte Lied: echte Programmierer schreiben auf jeder Plattform schlechte Programme.
-
TheBigW schrieb:
In einer perfekten Welt bräuchten wir keine Konkurenz, da das nur Resourcen verschwendet und jeder Monopolist würde dafür sorgen aus purer Vernunft (trotz seiner überragenden Stellung) die beste Lösung zu erstellen.
Sehe ich nicht.
In einer perfekten Welt wäre es höchstens so, daß gute Lösungen auch honoriert werden, aber Konkurrenz würde es erst recht geben - denn nur Konkurrenz treibt zu neuen Ideen und Weiterentwicklungen. Wenn sich alle einige sind, daß etwas gut ist, wo bleibt da der Antrieb zur Weiterentwicklung? Erst wenn die Konkurrenz die Meßlatte höher legt, setzt sich das Entwicklungsteam wieder in Bewegung und denkt neu nach.
Vorbild ist doch die Evolution - eigentlich doch sicherlich Resourcenverschwendung, wenn es soviele auch funktionierende Lebewesen gibt. Aber die Parallelentwicklung nutzt jeweils für sich ihre zugeteilten knappen Resourcen effizient - oder scheitert. Oder überholt andere. Dadurch gibt es immer wieder Entwicklungssprünge. Wenn das keine Effizienz ist...
-
AndreasW schrieb:
So Quasi eine ISO-API? Ein standardisiertes Funktionsset an API-Calls dies ermöglichen das Programm überall zu compilieren? Davon träum ich schon lange (o;
genau das meine ich. Letzendlich ist jeder Anbieter einer Plattform auf die Entwickler der Programme auf den Plattformen angewiesen.
Jo, von sowas träum ich wirklich schon lange. Hab mir das auch mal überlegt.. ne ISO-API, alle kämpfen mit gleichlangen speeren, die Plattformen sind beliebig austauschbar. (ähnlich OpenGL) Ein echter Traum. Das Problem ist allerdings die langsamere Entwicklung (würde ich mal so vom Schiff aus behaupten: Je mehr Leute die mitlabern, desto länger wird parliert.)...
AndreasW schrieb:
Wenn sich die Entwickler (als wir) zusammenreißen würden, könnten wir bestimmen wo der Hase lang läuft. Dann würde man eine solche API einfordern. Du wirst jetzt sagen: "träum weiter 'Fantast'".
Nein, nicht Fantast. Das Problem sind so hirnrissige Firmendirektiven wie "Wir benutzen ausschliesslich MSVC weil das OS ja auch aus dem Hause kommt und weils ein Standard auf dem Markt ist" Solchen Käse musste ich mir anhören, als ich versuchte meine C++Builder zu kriegen in der Firma. Dummerweise entscheiden Manager über derlei Direktiven und die Entwickler haben nur beschränkten Einfluss.
Und etwas muss man klar sehen: manager entscheiden weniger nach technischer richtigkeit (Können auch die wenigsten) sondern eher nach (böse gesagt) "Werbung".
AndreasW schrieb:
Ich sage dir, dass dass aber nicht soweit ausgeholt ist. Wenn jeder sich nur an offene Standards halten würde und komerzverseute Lösungen, auch wen sie noch so reizvoll sind, ignoriert, ist sowas möglich.
...tja...wenn... siehe Oben. So einfach ist das doch nicht.
AndreasW schrieb:
Wenn es keine Programme für MS gibt, gibt es auch kein MS. Soviel ist sicher. Wenn man Standards haben möchte kann man diese gemeindschaftlich auch bekommen. Leider sind Menschen von Natur aus träge und faul arbeit auf sich zu laden und für Ideale zu kämpfen.
Klar. Das Problem ist: MS hat seit Jahren den Fuss in der Tür. Neue Technologien, die nicht von MS promoted werden, habens entsprechend schwerer. Siehe C++ Builder... obwohls ein grossartiges Tool - gerade für Betriebsmittel-Software - wäre, verwenden viele MSVC "Weil hald Standard".
-junix
-
Marc++us schrieb:
Schlechtes Wochenende gehabt?
ich hatte eigentlich ein gutes ruhiges Wochenende. Danke der Nachfrage.
Marc++us schrieb:
Zum einen sieht man doch sehr schön am Beispiel von C++, das die ISO-Standards nicht viel taugen. Bis der nächste Standard kommt, sind schon zwei weitere OS-Generationen ins Land gezogen, und der Standard wird immer noch von einer sequentiellen Bandmaschine mit Streaming ausgehen... wenn's gut läuft ist Multithreading im Standard enthalten, aber von Dingen wie Datenbank, XML oder GUI darf man weiterhin träumen.
Ist doch kein Wunder, daß jeder dann seine eigene Suppe kochen muß.
Sicherlich erfordert eine standardisierte Plattform auch ein umdenken in der Entwicklung. Der Vergleich mit dem C++- Standard hinkt aber ein wenig. Seit wann ist C++ abhängig vom OS. So ist es ziemlich egal, was welche OS-Generationen machen. Das die Entwicklung von Standards schleppend vorangeht ist ja nicht die Folge von der rasenden Entwicklung des IT- Marktes sondern die Splittung der Entwickler.
Wenn jeder an der selben Suppe mitrühren würde, wäre die Suppe auch viel besser, allgemeinverträglich und schneller fertig. Wen jeder ein paar Zutaten mitbringt ist die Suppe dann auch noch günstig.
Wobei man aber auch berücksichtigen sollte, das viele Köche den Brei auch verderben können.Aber das ist eine Sache der Koordination.
[EDIT]Zitate eingefügt, da inzwischen mehrere gepostet hatten [/EDIT]
-
AndreasW schrieb:
Aber das ist eine Sache der Koordination.
Und das ist ein nicht gerade kleines Problem. So alles erschlagende Standards sind eben schwer beherrschbar.
Ich seheh das gerade bei DICOM. Das ganze entstand als Standard um die medizinische IT - Kommunikation zu vereinheitlichen (wird sich wohl auch durchsetzen). Über Jahre ist das genze dann gewachsen, da man es ja jeder medizinischen Sparte recht machen wollte. Herausgekommen ist am Ende ein riesen Standard-Monster. Die Ursprüngliche Idee war Geld und Zeit zu Sparen, bei der Anpassung herstellerspeziefischer Geräteschnittstellen ob man das damit erreicht hat....Thema DICOM : http://medical.nema.org/
@Marc++us
Der Vergleich mit der Evolution ist gar nicht schlecht. Bleibt nur zu sagen: "Möge der bessere gewinnen".
Wahrscheinlich liegt unsere Entwicklerverantwortung da, für eine gesunde evolutionäre Entwicklung zu sorgen :).
-
Marc++us schrieb:
simon.phoenix schrieb:
Wie bereits gesagt, das richtet sich sehr oft danach, was der Kunde einsetzt, und das wird noch eine ganze Weile Windows sein.
Der normale Kunde merkt doch gar nicht, ob sein Programm .NET verwendet oder nicht.
Vielleicht an der Geschwindigkeit?
Es war auch ein bisschen auf Plattformunabhängigkeit bezogen, die zwar nützlich, aber so lange Windows derartig den Client-Bereich abdeckt, imho eher zweitrangig ist.
-
Für eine typische Anwendung glaube ich das kaum.
Eine Datenbankabfrage dauert mit .NET genauso lange wie mit einem nativen C++-Programm, denn der Flaschenhals ist dort eine Netzwerkverbindung sowie irgendwo ein Server+Festplatte.
Ähnlich sieht es mit der GUI aus - wenn man ein Fenster mit 600 x 300 Pixeln voller Inhalten zeichnet, ist der Flaschenhals nicht das Füllen der Struktur gewesen, wo die Inhalte drin stehen - sondern das Zeichnen der Rahmen, das Schreiben der Fonts mit Antialiasing, usw.
Das macht sich erst bei Sachen wie Grafikanwendungen mit Rechenoperationen an Bitmaps etc bemerkbar.
-
Speicherbedarf?
-
also es ist fakt MFC ist schon bereits tod :p
da .net
-
Ihhhh - ich programmiere mit einer Leiche ...
-
maty schrieb:
Ihhhh - ich programmiere mit einer Leiche ...und macht es spass ??
-
Wie siehts eigendlich mit der Win16-Unterstützung in Longhorn aus?
-
naja bis jetzt gehts so ... scheint wohl noch nicht ganz tot zu sein ...
-
Laut diesem Interview http://www.codeproject.com/interview/whidbey_cpp.asp wird auch C++ in Zukunft WinFX unterstützen! Soviel zum Thema das C++ irgendwann bei Longhorn keine Rolle mehr spielen soll.
Warum sollte MS auch die C++ler aussperren?
-
da hab ich ja noch mal Glück gehabt
-
Wirklich tolle Idee das Monopol von der End-Software auf die
Entwickler auszuweiten. Damit kann man 2 Bereiche auf einmal
kontrollieren. Versteht mich net falsch, ich verteufle .Net nicht
(zumindest nicht grundsätzlich ;)). Aber die Art wie es "seinen Platz"
einnimmt gefällt mir nicht.
Kann es sein dass sich der Programmier-Mark im Moment noch wesentlich schneller
verändert als der Hardware-Mark?
Ich meine was ist denn bisher passiert:
Das Ablösen von C durch C++ hat relativ lange gedauert
und heute schießt jeden 2. Tag eine Programmiersprache aus dem
Boden die behauptet die einzig wahre zu sein (Java, C#, Ruby, Phyton etc)
Jeder schreit sofort "Der neue Standard!!" "C++ ist tot!". Aber was ist wirklich
passiert?
Man schaue sich die Office-Anwendungen an. Zuerst haben sie im Java-Wahn
alles auf Suns neue Sprache portiert um nacher mangelns Performance wieder
auf C++ zurück zukommen.
Davon hört man wenig, aber Java ist die Zukunft
(Das soll keine Java vs. C++ Diskussion werden. Beherrscht euch! :D)
-
Kane -> schlechte Erfahrungen gemacht ?!?!?
-
stimme kane zu
das ist mir auch schon aufgefallen
bei meinen recherchen fand ich heraus das es bereits 1995 um die 1000 programmiersprachen gab
und ich schaetze heute wird das bei weitem schlimmer seinjede 2te sprache ist das ULTIMUM
es gibt nichts besseres - so ein blödsinn
-
schlechte Erfahrungen gemacht ?!?!?
Was die absolutistische Auffassung von MS was Standards angeht: JA!
Was das Verhalten von MS gegen über .Net "Immitaten" (.Gnu, Mono) angeht: JA!
-
Mono und den EMCA Standard duldet MS ja eh nur, damit es keine Monopol Probleme gibt. Wobei der EMCA Standard wohl eh hinter dem wirklichen dotNET hinter her hängt (geschweige davon, dass wichtige Kernfeatures gar nicht standardisiert wurden)