MFC -> tod
-
AndreasW schrieb:
Davon mal abgesehen. Stellt sich sowieso die Frage, was der Sinn der ganzen Geschichte ist.
Reflektieren wir mal:Man will Plattformunabhängigkeit. Das geht aber aufgrund der unterschiedlichen Struktur der Plattformen von Linux MS Solaris und co nicht. Was macht man also - man erzeugt eine eigenständige Plattform auf der aktuellen Plattform. Für jede Plattform schreibt man also eine Plattform, die auf diese Plattform läuft. Hat da schon mal jemand drüber nachgedacht was für ein Quatsch das eigentlich ist ? Der richtige Ansatz wäre doch alle Plattformen zu eliminieren und nur EINE grundlegende Struktur für Plattformen schaffen, worauf man ansetzt. Dann kann man sich dieses, aus kommerziellen Gründen entstandene, sinnlose Gehampel von Java und .net sparen und wäre zudem noch wesentlich performanter.
Naja, Geld regiert die Welt....
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.
Leider zeigt die Realität, das wir dieses Stadium wohl noch nicht erreicht haben. Ich finde es ganz gut, das da jetzt in vielen Bereichen mal ein bisschen Konkurenz giebt, und sich somit eine Menge tut. Das sieht man ja auch im Hardwaremarkt. Dank der jahrelang übelegenen Stellung von NVIDIA hat sich nach GForce3 nichts mehr geregt. Dann war ATI plötzlich als Mitkonkurent wieder da und schon wird fleißig weiterentwickelt und die Preise fallen.
-
Leider zeigt die Realität, das wir dieses Stadium wohl noch nicht erreicht haben.
Leider. Aber das ist wohl die Natur der Menschen. Dieses Stadium wird die Menschheit auch wohl nicht erlangen da unnütze habgier die Seelen vergiftet. Wenn man das mal global betrachtet sind dei Menschen doch nur eine Seuche und Krankheiten wie Krebs,Aids usw. sind die "Antibiotika" der Natur.
-
AndreasW schrieb:
Der richtige Ansatz wäre doch alle Plattformen zu eliminieren und nur EINE grundlegende Struktur für Plattformen schaffen, worauf man ansetzt.
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;
-junix
-
AndreasW schrieb:
Wenn man das mal global betrachtet sind dei Menschen doch nur eine Seuche und Krankheiten wie Krebs,Aids usw. sind die "Antibiotika" der Natur.
... etwas radikal, der Ansatz, aber gefällt mir. (o: Passt in die einleuchtende Theorie, die mir mal ein wirtschafts-student bei nem Gläschen BaCoSch verklickert hat... Seuchen sind der natürliche Weg der natur die Menschen zu dezimieren (o:
-junix
-
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. 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'". 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. Womit wir wieder bei der Grundidee von Unix sind. Das Problem bei der Umsetzung ist nicht Microsoft sondern WIR, die Entwickler.
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.
Schade.
-
Für mich persönlich (ich denke das geht dem Einen oder Anderen auch so) sprechen an erster Stelle die Perfomance der MFC (im Gegensatz zu .Net) und ansonsten der massig vorhandene Quelltext dafür, dass die MFC (so schnell) nicht aussterben wird. Es soll ja noch Leute geben, die stinknormale Windows-Programme schreiben und diese an Kunden verkaufen, die auch Windows einsetzen.
Wie bereits gesagt, das richtet sich sehr oft danach, was der Kunde einsetzt, und das wird noch eine ganze Weile Windows sein.
-
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.
-
und ansonsten der massig vorhandene Quelltext dafür, dass die MFC (so schnell) nicht aussterben wird
genau das hab ich bezüglich der VCL im BCB auch gedacht.
So kann man sich irren....
-
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?