Warum Delphi: Nicks' Gründe ;-)

[mkinzler]

Hauptsache die Werbeabteilung arbeitet :mrgreen:
http://blogs.codegear.com/nickhodges...006/12/21.aspx

[Daniel]

Naja, ist halt sein Job. ;-)

[Bernhard Geyer]

zu 1: Ist für uns auch ein Grund aktuell noch mit Delphi zu entwickeln. Mal schauen was in 5 Jahren ist.

zu 2: Für Win32 gibts nichts besseres

zu 3: Win64 wäre toll, für .NET ist der VCL-Ansatz systembedingt mit Problemen verbunden und für Vista wird es hoffentlich von meinen Komponentenhersteller bald auch ein paar Controls geben.

zu 4: Die Java-Gemeinde ist größer und ich denke mittlerweile ist auch die .NET-Gemeinde größer.

zu 5: Nach D8 und D2005 und den Anfangsproblemen bei D6 sollte er diesen Punkt nicht so hervorkehren. Hier hat CodeGear einiges wieder gut zu machen.

[mkinzler]

Zitat:

zu 3: Win64 wäre toll, für .NET ist der VCL-Ansatz systembedingt mit Problemen verbunden und für Vista wird es hoffentlich von meinen Komponentenhersteller bald auch ein paar Controls geben.

Ich hoffe er meint damit die versprochene Implementierung der VCL auf .Net (WCF)

[Phoenix]

Wenn dann WPF und nicht WCF ;-)

Aber um ehrlich zu sein: Ich glaube das erst, wenn ich es sehe.
Wenn es eine WPF-VCL ohne P/Invokes gibt, dann ist Delphi wirklich Zukunftssicher. Ansonsten sehe ich da echt schwarz.

[Daniel G]

Immerhin haben wir es jetzt schwarz grün auf weiß, dass Skype mit Delphi entwickelt wurde... :mrgreen:

[Neutral General]

Zitat:

Zitat von Daniel G

Immerhin haben wir es jetzt schwarz grün auf weiß, dass Skype mit Delphi entwickelt wurde... :mrgreen:

Hehe das hab ich auch gesehn letztens als ich Skype beende und auf einmal eine AV kam:

Zitat:

EAccessViolation... bla bla

und danach irgendwas wie:

Zitat:

H:\Irgendwas\..\Irgendeinname.pas konnte nicht gefunden werden

aber auf Englisch halt :mrgreen:

Gruß
Neutral General

[hanspeter]

Zitat:

Zitat von Phoenix

Aber um ehrlich zu sein: Ich glaube das erst, wenn ich es sehe.
Wenn es eine WPF-VCL ohne P/Invokes gibt, dann ist Delphi wirklich Zukunftssicher. Ansonsten sehe ich da echt schwarz.

Die haben Kylix nicht hinbekommen. VCL unter Net ist ein Flop. Warum soll mit verminderten Resourcen jetzt in absehbarer Zeit
ein WPF funktionieren?

Ich meine die VCL ist inzwischen so altbacken, dass sie für Moderne Lösungen keine Grundlage mehr bietet.

Gruß Peter

[mkinzler]

Zitat:

Ich meine die VCL ist inzwischen so altbacken, dass sie für Moderne Lösungen keine Grundlage mehr bietet.

Imho ist die Implementierung vielleicht altbacken, aber nicht das Konzept ansich.

Zitat:

VCL unter Net ist ein Flop.

Da sie unerkläricherweise gemeint haben, daß sie den einfacheren Weg gewählt hätten.

Zitat:

Warum soll mit verminderten Resourcen jetzt in absehbarer Zeit ein WPF funktionieren?

Das kommt darauf an, wie weit sie damit sind, schließlich wurde daran (zumindest offiziell) schon vor der Auslagerung gearbeitet.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler

Zitat:

Ich meine die VCL ist inzwischen so altbacken, dass sie für Moderne Lösungen keine Grundlage mehr bietet.

Imho ist die Implementierung vielleicht altbacken, aber nicht das Konzept ansich.

Deshalb gibt es ja viele parallen von der FCL im Bereich WinForms und Visual CLX. Man erinnert sich an Aussagen eines bekannten Delphi-Vaters und jetzt .NET-"Vaters" der die VCL nicht gerade als verkorkst bezeichnet hat ...

Zitat:

Zitat von mkinzler

Zitat:

VCL unter Net ist ein Flop.

Da sie unerkläricherweise gemeint haben, daß sie den einfacheren Weg gewählt hätten.

Es war nicht der einfachere Weg (Verglichen mit dem was MS mit den VB-Jüngern gemacht hat. Es hat sich letztendlich als der Weg mit vielen Problemen für die Zukunft herausgestellt: 64-Bit, Compact Framework, Sicherheitsaspekte, ...

[mkinzler]

Zitat:

Es war nicht der einfachere Weg...

So sehe ich das auch, aber sie (Borland) dachten es.

[Heffalump]

Zitat:

Zitat von hanspeter

Die haben Kylix nicht hinbekommen. VCL unter Net ist ein Flop. Warum soll mit verminderten Resourcen jetzt in absehbarer Zeit ein WPF funktionieren?

Ich meine die VCL ist inzwischen so altbacken, dass sie für Moderne Lösungen keine Grundlage mehr bietet.

Gruß Peter

Die VCL war und ist für Win32 das Mittel der Wahl. Für .Net sollten hier der alte Zopf abgeschnitten werden und Delphi.Net wieder kongurenzfähig zu den anderen Sprachen/Produkten gemacht werden. Nach meiner Ansicht gehört dazu auch nur noch Support für Win32 liefern und neue Entwicklung/Erweiterung streichen.

Da hier kurz Kylix angesprochen wurde. Das Thema Linux für Clients hält bei Firmen und Behörden immer mehr Einzug. Entwickler, welche in der Lage sind, sowohl für Windows als auch Linux Anwendungen zur Verfügung zu stellen, werden nach meiner Meinung zukünftig mehr gefragt sein. Und hier ist der Zug den Codegear aufgreifen sollte. Eine offizielle Unterstützung, sowohl für das Framework von Microsoft als auch Mono von "Novell" wird zukünftig auch ein Kauf-/Lizensierungsargument für eine Entwicklungsumgebung sein.

[mkinzler]

Zitat:

Nach meiner Ansicht gehört dazu auch nur noch Support für Win32 liefern und neue Entwicklung/Erweiterung streichen.

Welche weitere Entwicklung meinst du?

[Heffalump]

Was auch immer, Spracherweiterungen, 64 Bit Support, VCL Erweiterungen usw. Sie haben es bis heute nicht geschafft. Wer den 64 Bit Support benötigt hat zum größten Teil sich wo anders umgesehen. Ich bin der Auffassung, dass sich Codegear voll auf .Net konzentrieren muss. Da besteht die Notwendigkeit, den Vorsprung anderer Produkte aufzuholen.

Ich selbst habe die Erfahrung gemacht, das ich .Net immer vor mir her geschoben und die gleichen Argument verwendet habe wie sie hier in den Delphipraxisforen verwendet werden.

• Wozu .Net Win32 wird es noch lange geben
• Zu langsam
• Insgeheim, warum mit etwas neuem beschäftigen (da muss ich mich ja umgewöhnen). Offiziell sagt man dann dass man keine Zeit dafür hat und der Aufwand nicht lohnt
• ...

Beruflich war ich gezwungen mich mit .Net zu beschäftigen. Heute bin ich froh darüber. Ich habe die Erfahrung gemacht, welche Möglichkeiten überhaupt bestehen, wie einfach es ist damit zu arbeiten. Das unter bestimmten Voraussetzungen die Anwendungen sowohl unter Windows als auch unter Linux laufen. Wenn ich heute ein Projekt beginne, stellt sich für mich nicht mehr die Frage ob Win32 oder .Net. Nicht seit ich weis wie .Net funktioniert.

Ich glaube das geht vielen so, die mittlerweile mit .Net arbeiten (abgesehen von einigen wenigen).

[Heffalump]

Nimmt man sich den Artikel mal genauer zu Gemüte, dann kann man erkennen wohin der Zug geht. Hochgelobt sei Win32 und bitte baut darauf auf. .Net hat nicht jeder daher nicht zwingend notwendig damit zu arbeiten, hochgelobt sei Win32. Wir jede Menge Geld und deshalb portieren wir die VCL nach .Net und bauen sie weiter aus. Es mag richtig gewesen sein, dass die VCL für Win32 die Basis für Delphi bildet. Aber warum auch für .Net? Da gibt es bereits entsprechende Komponenten und mit diesen lässt sich wunderbar arbeiten. In kaum einem Forum lese ich, das die Delphientwicklergemeinde froh ist, das es die VCL auch für .Net gibt. Fast durch die Bank weg wird dazu geraten auf WinForm Basis zu arbeiten. Nur die Codegear Mädels und Burschen wollen es nicht verstehen. Der nette Verweis auf bekannte Produkte zur Unterstützung der Win32 Strategie hilft auch nicht.

Ich werde das Gefühl nicht los, das die Entwickler von Delphi sich nicht eingestehen wollen, das die Richtung die vor langer Zeit eingeschlagen wurde die falsche Richtung ist. Ich habe den Eindruck, das sie denken, der einzige Fehler war, das nicht genügen Ressourcen zur Verfügung gestellt wurden. Auch wenn der Vergleich der ein oder andere nicht gerade gut gewählt finden wird, erst wenn der Süchtige weis und akzeptiert hat das er süchtig ist, dann ist er in Lage etwas dagegen zu tun.

Der Artikel von Nick sagt mir, sie wissen es aber sie akzeptieren es noch nicht.

[Daniel G]

Das tolle an der .NET - Geschichte ist ja, dass man kein "alter Hase" sein muss, um mitzudiskutieren.

Zitat:

Zitat von Heffalump

Ich selbst habe die Erfahrung gemacht, das ich .Net immer vor mir her geschoben und die gleichen Argument verwendet habe wie sie hier in den Delphipraxisforen verwendet werden.

So geht's mir auch immer noch. Als Delphi 8 auf den Markt kam, habe ich überlegt, mich in .NET einzuarbeiten. Ich muss gestehen, mir verging irgendwann die Lust. Vor allem, weil Delphi 8 auf mich wie schnell - Entschuldigung - "dahingerotzt" gewirkt hat.

Zitat:

Zitat von Heffalump

• Wozu .Net Win32 wird es noch lange geben

Genau das habe ich mir dann auch gedacht: "Verdammt, du hast dich 2 Jahre in Win32 eingearbeitet (inkl. Einarbeitungszeit in Delphi Language). Win32 wird ja nicht von heute auf morgen aussterben." Ich denke, inzwischen sind wir irgendwo um Mitternacht herum...

Zitat:

Zitat von Heffalump

• Zu langsam

Das konnte ich eigentlich nicht feststellen. Gibt's da konkrete Beispiele?

Zitat:

Zitat von Heffalump

• Insgeheim, warum mit etwas neuem beschäftigen (da muss ich mich ja umgewöhnen). Offiziell sagt man dann dass man keine Zeit dafür hat und der Aufwand nicht lohnt

Siehe zwei Argumente vorher.

Außerdem war es damals so, dass ich noch mit meinem 56k - Modem durch die Gegend gedüst gekrochen bin. Da dachte ich dann auch: "Ok, du entwickelst primär in deiner Freizeit Programme, die max. 1 MB in ihrer Dateigröße betragen. Und dann soll dein "Kunde" sich erst das .NET - Framework herunterladen müssen? No way..."

Inzwischen sehe ich das anders. Codegear muss sehen, dass sie im .NET - Bereich nicht noch mehr an Boden verlieren. Vielleicht sollte man auch endlich mal etwas innovatives auf den Markt bringen. Ich denke da an die Umfrage, die vor einiger Zeit gemacht wurde, wo Entwickler gefragt wurden, was sie sich für die neue Delphi - Version alles wünschen. Ja, 64bit - Support klingt lecker, aber ich habe lieber nur ein neues Feature, das dafür vernünftig implementiert ist, als fünf schlampige Implementationen.

Es wäre schade um Delphi. Immerhin ist es eine schöne IDE und die Delphi Language ist in Verbindung mit Datenbanken immer noch unschlagbar.

Zitat:

Zitat von Heffalump

erst wenn der Süchtige weis und akzeptiert hat das er süchtig ist, dann ist er in Lage etwas dagegen zu tun.

Eine schöne Metapher, die leider auch nicht immer zutrifft....

[Hansa]

Für das Thema wirds echt langsam Zeit. 8) Na denn : .NET ist eventuell allerdings ein Rohrkrepierer.

[mkinzler]

Zitat:

.NET ist eventuell allerdings ein Rohrkrepierer.

Danach sieht es aber nicht aus, höchstens du meinst die VCL.Net-Implementierung

[Hansa]

.NET alleine ist vielleicht nicht das richtige Beispiel. Das kann M$ den Usern noch als "Framework" unterjubeln und die merken nicht viel davon. Es geht eher um Vista. Da sehe ich ein extrem hohes Akzeptanzproblem für MickySoft. Die sind zu spät an. Meine Beobachtung ist eine Unterteilung der Computer-Nutzer in 3 Gruppen. Fangen wir mal hier in der DP an.

1. relativ fachkundige User, die zumindest ungefähr wissen, um was es geht. Die Vielzahl der "nonVCL"-Threads zeigt aber auch, dass dadurch selbst hier ein gewaltiges Akzeptanz-Problem entstanden ist. Letztere brauchen schlicht kein .NET.
2. technisch interessierte User, aber ohne grundlegendes Know-How. Die interessieren sich schon für die Hintergründe, aber selbst wenn sie es einigermaßen verstanden haben, es wird nur genutzt, was besser ist als vorher.
3. die breite Masse. Auch DAUs genannt. :mrgreen: Die haben sich eine Regel zu eigen gemacht, die eigentlich nicht für sie bestimmt war : "Never change a running system". Das Beharrungsvermögen bei denen ist fast unglaublich. :shock: Vista wird da nur im absoluten Notfall eingesetzt werden. Würde mich nicht wundern, wenn in absehbarer Zeit einige mit neuem Aldi-Rechner auftauchen und darauf bestehen, dass ihr funktionierendes W2000 da drauf kommt.

Mein Fazit : prophylaktisch Finger weg von WinAPI und zwar sofort. Compiler-Warnungen in Richtung "unsafe Code" nicht ignorieren und sukzessive ausmerzen. Entwicklung genau beobachten.

P.S.: hier steht irgendwo, die WinForms seien schon überholt. Wieso das ? :zwinker:

[Daniel G]

Zitat:

Zitat von Hansa

[...]M$[...]MickySoft.

Es sind immer dieselben Indikatoren, die dazu führen, dass ich einen Beitrag nicht weiterlese. Schade eigentlich...

[Phoenix]

Zitat:

Zitat von Hansa

P.S.: hier steht irgendwo, die WinForms seien schon überholt. Wieso das ? :zwinker:

Kurz: WPF: Windows Presentation Foundation.
Die ist mit den Windows Forms inkompatibel und stellt lt. Microsoft die neue Art dar, Oberflächen zu machen.

Kurze Anlogie:
Im Prinzip beschreibt WPF in XML-Dateien (XML-Dialekt XAML - Extensible Application Markup Language) das, was wir aus den DFM's schon kennen.

Ich bin der Meinung, dass es ohne weiteres möglich sein [b]sollte[/s], auch unter Linux/andere Plattformen ein WPF-Subsystem zu bauen dass aus dem XML die Controls entsprechend rendert. Das ist IMHO genau das, was .NET Desktop-Applikationen wirklich Plattformunabhängig machen kann.

Deswegen auch meine Meinung: Wenn es CodeGear schafft, die VCL auf WPF zu heben ohne dabei noch P/Invokes zu benötigen (und das erscheint mir tatsächlich irgendwie realistisch, wenn es auch einen massigen Aufwand bedeutet), dann dürfte alles das, was auf VCL basiert und KEINE OwnerDraws verwendet, mit berechenbaren Aufwand auch wirklich auf Plattformunabhängiges .NET portierbar sein.

Das sind viele Wenns, aber es ist imho die letzte Chance die VCL in die Zukunft zu retten.

[mkinzler]

Zitat:

Letztere brauchen schlicht kein .NET.

Wenn die Win32 mal tot ist schon.

Zitat:

Vista wird da nur im absoluten Notfall eingesetzt werden

Aber nicht bei den DAUs. Diese kaufen Rechner, auf denen Vsita schon drauf ist und finden die schöne bunte unnütze ressourcenhungrige neue Oberfläche sicherlich geil.

[Phoenix]

Zitat:

Zitat von Daniel G

Zitat:

Zitat von Hansa

[...]M$[...]MickySoft.

Es sind immer dieselben Indikatoren, die dazu führen, dass ich einen Beitrag nicht weiterlese. Schade eigentlich...

Auch wenns Offtopic ist:
Ich finde, das ist meistens Neid. Microsoft verdient mit der Software massigst Geld. Geld, das wir alle zugegebenermassen gerne hätten. Deswegen M$. Ich find's auch Scheisse, aber nungut.

Es sei aber bedacht: Jeder verdient immer nur das Geld, das andere bereit sind, diesem jemanden auch zu geben. Das bedeutet, die Jungs in Redmond haben es einfach nur richtig gemacht. Und ja, auf den Erfolg kann man sehr neidisch sein.

Wenn jemand deren Software nicht gut findet, dann braucht er sie nicht einzusetzen.

Ich für meinen Teil bin Happy, dass es Microsoft gibt, denn ohne diese Firma hätte ich nicht die Plattform auf der ich momenten meine Kenntnisse vermarkte.

Um ehrlich zu sein: 90% der kommerziellen Entwickler hier hätten ihren Job wahrscheinlich nicht, wenn es Microsoft nicht gäbe.

An alle, die hier Microsoft Verunglimpfen: Fragt Euch bitte ehrlich: WO würdet ihr heute stehen, wenn es diese Firma nicht gäbe?

[mkinzler]

Zitat:

An alle, die hier Microsoft Verunglimpfen: Fragt Euch bitte ehrlich: WO würdet ihr heute stehen, wenn es diese Firma nicht gäbe?

Dann gäbe es vielleicht ein anderes, vielleicht besseres System. Konkurrierende Ansätze gie KickStart/GEM/MacOS gab(gibt) es ja. Aber alle die hier schimpfen, arbeiten ja mehr oder weniger auf/mit Produkten von Billy's Gnaden :mrgreen:

[shubbi]

Ich vermisse bei Delphi am meisten einen vollen Unicode-Support in der ganzen VCL.
.NET würde ich sowieso nur mit C# oder so machen. Für Linux kommt bei mir nur C++ (mit wxWidgets, wenns auch noch unter Windows laufen soll) in Frage.

[Balu der Bär]

Zitat:

.NET würde ich sowieso nur mit C# oder so machen.

Wieso?

Wenn Borland demnächst .Net2 oder gar .Net3 unterstützt sehe ich keine Notwendigkeit des Greifens zum VS, oder?

[Phoenix]

Zitat:

Zitat von Balu der Bär

Zitat:

.NET würde ich sowieso nur mit C# oder so machen.

Wieso?
Wenn Borland demnächst .Net2 oder gar .Net3 unterstützt sehe ich keine Notwendigkeit des Greifens zum VS, oder?

Hrm. C# geht auch mit dem aktuellen BDS, da muss man nicht zwangsläufig zum VS greifen. Aber das gilt freilich auch nur, wenn wenigstens angekündigt wird, das auch für das CodeGear Developer Studio baldmöglichst ein WPF-Designer nachgereicht wird.

[Heffalump]

Zitat:

Zitat von Phoenix

Zitat:

Zitat von Hansa

P.S.: hier steht irgendwo, die WinForms seien schon überholt. Wieso das ? :zwinker:

Kurz: WPF: Windows Presentation Foundation.
Die ist mit den Windows Forms inkompatibel und stellt lt. Microsoft die neue Art dar, Oberflächen zu machen.

Kurze Anlogie:
Im Prinzip beschreibt WPF in XML-Dateien (XML-Dialekt XAML - Extensible Application Markup Language) das, was wir aus den DFM's schon kennen.

Ich bin der Meinung, dass es ohne weiteres möglich sein [b]sollte[/s], auch unter Linux/andere Plattformen ein WPF-Subsystem zu bauen dass aus dem XML die Controls entsprechend rendert. Das ist IMHO genau das, was .NET Desktop-Applikationen wirklich Plattformunabhängig machen kann.

Deswegen auch meine Meinung: Wenn es CodeGear schafft, die VCL auf WPF zu heben ohne dabei noch P/Invokes zu benötigen (und das erscheint mir tatsächlich irgendwie realistisch, wenn es auch einen massigen Aufwand bedeutet), dann dürfte alles das, was auf VCL basiert und KEINE OwnerDraws verwendet, mit berechenbaren Aufwand auch wirklich auf Plattformunabhängiges .NET portierbar sein.

Das sind viele Wenns, aber es ist imho die letzte Chance die VCL in die Zukunft zu retten.

Wozu VCL.Net? Nachbauen, was schon existiert? Das ist Verschwendung. Im Übrigen gibt es vom Monoproject eine "Straßenkarte" aus der hervorgeht, das WPF und die mit .Net 3 gekommenen Komponenten Einzug halten werden. Also noch mal die Frage: Wozu VCL.Net? Und wer glaubt hier wirklich, das die Codegear Entwickler jetzt noch mehr Geld zum entwickeln haben, da sie sich jetzt auch noch um das ganze Thema Personalverwaltung/Finanzen/Marketing etc. kümmern müssen. Die Tatsache dass der Nick in seinem Beitrag so auf die Win32 verweist bedeutet nichts Gutes für die weitere Entwicklung.

Noch einmal. Die VCL war für Win32 das beste Framework zur Kapselung der Win32. Jetzt gibt es dafür .Net. Und das nicht nur für Win32. Da wären noch diese niedlichen kleinen PDA´s und seit kurzem ist die X-Box auch dabei. Man stelle sich das mal vor! Wer für die X-Box programmieren möchte kann das mit .Net machen (kürzlich im Entwickler gelesen). Codegear wird es niemals schaffen mit der VCL.Net mitzukommen. Wer jetzt auf die Idee kommt zu sagen "Na ja die hingen schon immer etwas hinterher", der hat nicht festgestellt, das sich die Welt verändert hat und das es zur VCL mittlerweile eine Alternative gibt. Und diese Alternative ist vom Umfang, Qualität und Verfügbarkeit (Plattform) der VCL.Net um Längen überlegen.

[hanspeter]

Zitat:

Zitat von Heffalump

Wozu VCL.Net? Nachbauen, was schon existiert? Das ist Verschwendung. Im Übrigen gibt es vom Monoproject eine "Straßenkarte" aus der hervorgeht, das WPF und die mit .Net 3 gekommenen Komponenten Einzug halten werden. Also noch mal die Frage: Wozu VCL.Net?Wer jetzt auf die Idee kommt zu sagen "Na ja die hingen schon immer etwas hinterher", der hat nicht festgestellt, das sich die Welt verändert hat und das es zur VCL mittlerweile eine Alternative gibt. Und diese Alternative ist vom Umfang, Qualität und Verfügbarkeit (Plattform) der VCL.Net um Längen überlegen.

Das deckt sich mit meiner Meinung und ich meine das bringt die ganze Delphi-Problematik auf den Punkt.

VCL und Win32 hat unbestritten die Krone. Da gab und gibt es nichts besseres.
Die Beschreibung der Oberfläche in einer externen Resource (WPF) das hatte Delphi mit der dfm schon lange.
Das Problem ist wirklich, das Codegear die VCL nach Net retten will und hier am Bedarf vorbei entwickelt.
Dem Net Framework sieht man die VCL als Vergangenheit an, beide haben schließlich den gleichen Vater.
Am Netframework wird bei MS mit wesentlich mehr Mannpower gearbeitet. Hier wird Borland immer hinterherlaufen.
Vor allen dann, wenn wie angekündigt, neue API nur als Framworkklassen kommen.
Die VCL als Wrapper für das Netframework wozu?
Codegear hat nur Chancen, wenn sie sich auf eine Nische konzentrieren und ihre begrenzten Resourcen hier einsetzen.
Borland/Codegear kann nur überleben, wenn ein neuer Kundenkreis erschlossen werden kann.
Als Entscheider welches Argument zieht, wenn ich mich für eine Investition in Delphi entscheiden soll.
Nein Borland hat sich zulange auf seinen Erfolgen ausgeruht und das bessere ist des guten Feind.
Der Lösungsansatz der VCL und der IDE von Delphi standen Pate bei der Entwicklung von VC2005 und Net und wir haben jetzt halt ein
besseres Framework.
Wer sich auf dem freien Projektmarkt orientieren muss, da gibt es kaum noch Angebote für Delphientwickler aber Unmengen von
Angeboten für Net Entwickler. Hinterfragt man dann solche Angebote so kommen diese meist aus einem VB,Java oder C++ Umfeld.
Und hier zu sagen ok ich bin fit in Net, aber mit Delphi. Dann kommt die Frage "Was bitte ist Delphi?"

Ein schönes Weihnachtsfest und viele Grüße
Peter

[Hansa]

Zitat:

Zitat von Daniel G

Zitat:

Zitat von Hansa

[...]M$[...]MickySoft.

Es sind immer dieselben Indikatoren, die dazu führen, dass ich einen Beitrag nicht weiterlese. Schade eigentlich...

Dann lasse es eben sein. M$-hörig oder was ? Wie die Firma bezeichnet wird, das ist doch wohl egal. Das $ ist nicht für Neid gemacht, sondern lediglich für die venachlässigten Programmierer. :mrgreen:

Zitat:

Zitat von Phoenix

Ich für meinen Teil bin Happy, dass es Microsoft gibt...

Ein Monopolist hat noch nie was positives bewirkt. Die Rechnungsabteilung bleibt davon ausdrücklich ausgenommen.

[Meta777]

Zitat:

Zitat von Hansa

...
3. die breite Masse. Auch DAUs genannt. :mrgreen: Die haben sich eine Regel zu eigen gemacht, die eigentlich nicht für sie bestimmt war : "Never change a running system". Das Beharrungsvermögen bei denen ist fast unglaublich. :shock: Vista wird da nur im absoluten Notfall eingesetzt werden. Würde mich nicht wundern, wenn in absehbarer Zeit einige mit neuem Aldi-Rechner auftauchen und darauf bestehen, dass ihr funktionierendes W2000 da drauf kommt.

Hm, ich weiß ja nicht was ihr so alles macht, aber meiner einer hat z.B. das Glück, dass ich ich "Spezial"-Software schreiben darf, die für ein spezielles Kundencliente gedacht ist. Und um da konkurrenzfähig zu sein heißt es sich an den gegebenen Situationen anzupassen, was wiederrum bedeutet das die beim Kunden vorhandene Hardware vom PI bis zum DualCore reichen kann. Auch hat unsere Kundschaft die Anforderung dass die Software schnell laufen soll, wenn MS Vista auf einem PIII mit 500MHz 15 Minuten zum hochfahren brauch ist auch dem unerfahrensten DAU-Kunden klar das Vista nicht schneller sein kann als das was er bereits hat...
Mit dieser Situation können wir auch schonmal sagen "Wir wollen W2k"... Wobei aber auch viele Kunden ihre Arbeitsgewohnheiten nicht wegen Spielereien wie bunte 3D Effekte usw. änderen werden.

Zitat:

Zitat von Hansa

Mein Fazit : prophylaktisch Finger weg von WinAPI und zwar sofort. Compiler-Warnungen in Richtung "unsafe Code" nicht ignorieren und sukzessive ausmerzen. Entwicklung genau beobachten.

Da ist es doch gut dass ich eben nicht für den "Home-Consumer" (oder wie auch immer) Software schreiben :stupid:

...my Senf dazu


Shalom und God bless ya all

[Elvis]

Zitat:

Zitat von Phoenix

Zitat:

Zitat von Hansa

P.S.: hier steht irgendwo, die WinForms seien schon überholt. Wieso das ? :zwinker:

Kurz: WPF: Windows Presentation Foundation.
Die ist mit den Windows Forms inkompatibel und stellt lt. Microsoft die neue Art dar, Oberflächen zu machen.

Nicht wirklich, du kannst ein SWF Control auf eine WPF Surface werfen und es wird sich so verhalten wie du es erwartest.

Zitat:

Ich bin der Meinung, dass es ohne weiteres möglich sein [b]sollte[/s], auch unter Linux/andere Plattformen ein WPF-Subsystem zu bauen dass aus dem XML die Controls entsprechend rendert. Das ist IMHO genau das, was .NET Desktop-Applikationen wirklich Plattformunabhängig machen kann.

Jupp, ich denke wir werden schneller ein komplettes Mono-WPF als ein komplettes Mono-SWF sehen. :)

Zitat:

Das sind viele Wenns, aber es ist imho die letzte Chance die VCL in die Zukunft zu retten.

Nur lohnt sich das?
non-Visual VCL Wrapper gibt's zum Beispiel in Form von ShineOn, welches auch gegen Mono getestet wird.
Und bei visuellen Krams muss man sich doch ernsthaft an den Kopf fassen, ob man das wirklich nicht einfach für .Net neu macht.
Codegear könnte seine Zeit sinnvoller verschwenden, zum Beispiel mit einer Win64 compiler preview, mehr RTTI in native Delphi inkl. Reflection, Attribute, gaaaanz lange Liste an deren Ende irgendwann mal visueller VCL.Net Krams steht.
Sogar mit "VB stinkt" bedrucktes Klopapier wäre sinnvoller als Ressourcen mit einer zu kompletten VCL.Net zu verschwenden, IMHO. ;)

[Luckie]

Ach ihr mit euren .NET, WinForms, VCL und was weiß ich noch alles. Mit der reinen WinAPI weiß man wenigstens noch, was man macht und was dahintersteckt und hat Einblick in die Mechanismen. Wenn ich eine WinForm aufrufe, weiß ich ja gar nicht mehr, was da alles im Hintergrund passiert. :mrgreen:

[Hansa]

Tja, eben nichts bzw. .NET :mrgreen:

[Heffalump]

Zitat:

Zitat von Luckie

Wenn ich eine WinForm aufrufe, weiß ich ja gar nicht mehr, was da alles im Hintergrund passiert. :mrgreen:

Aber doch auch nur, weil Du Dich noch intensiv damit auseinandergesetzt hast. Lade Dir mal das Tool vom Roeder runter und schau mal in das ein oder andere Assembly von MS rein. Da kannst Du sehen, wie das ganze funktioniert.

Ich hatte genau das gleiche Thema. Ich kannte das nicht und war nur Win32 API gewohnt (Bsp. LDAP über API, ACLs usw...). Meine Erfahrungen und Erkenntnisse und damit verbundenen Möglichkeiten habe ich erhalten, als ich beruflich gezwungen wurde mich mit .Net zu beschäftigen. Wir haben ein Managementsystem bekommen, welches auf der Basis von .Net arbeitet. Seit dem ich weis das, unter bestimmten Bedingungen, diese Anwendungen auch u. a. unter Linux laufen, bin ich für reine Win32 Programmierung nicht mehr zu haben. NUR WENN ES KEINE ANDERE MÖGLICHKEIT GIBT.

[mkinzler]

Neue (vage) Infos zur kommenden Turbo-Produkten in Nicks's Blog

[Olli]

Zitat:

Zitat von shubbi

Ich vermisse bei Delphi am meisten einen vollen Unicode-Support in der ganzen VCL.

Bingo :roll:

... auch im neuen Blogeintrag keine Erwaehnung von Unicode. Borland schlaeft also weiter ... :|

[Heffalump]

Zitat:

Newsletter von Borland/CodeGear
... Laut den letzten Umfragen unter Delphi-Entwicklern arbeiten noch über 90 % der Community mit der Win32 Plattform. ...

Die 90 Prozent hören sich beim ersten Lesen gut an, oder? Alles im grünen Bereich, möchte man meinen. Aber warum arbeiten weniger als 10 % nicht mit Win32 sondern z. Bsp. mit .Net. Doch nur weil die meinsten Delphianer, welche auf .Net Basis arbeiten, mittlerweile die IDE gewechselt haben.

Ich verstehe nach wie vor nicht, warum bei CodeGear nicht der .Net Zug bei allen Signalen grün bekommt. Ist es nicht wichtig, den Schwund an Delphientwicklern von Delphi zu VS zu stoppen und endlich eine .Net Unterstützung zur Verfügung zu stellen, mit der man arbeiten kann? Scheinbar nicht, Win32 und damit die VCL stehen nach wie vor an vorderster Front.

Was anderes war aber nach dem Beitrag von Nick nicht zu erwarten. Ich glaube die Umfage diente in erster Linie dazu die eigene Strategie zu bestätigen.

Schade, schade, schade.

[Phoenix]

Frag doch mal Jason Vokes und DavidI an den Delphi-Tagen persönlich :)

[Ghostwalker]

Zuerstmal ein bischen OT:

Vista erinnert mich irgendwie an die Einführung von Win95.......

Ok..back to Topic.

Ob .NET oder Win32 ist für mich keine generelle Frage. Es ist doch letzendlich eine Frage, was der Kunde will, und welche Voraussetzungen beim Kunden herschen. Hier entscheidet es sich, ob man .NET einsetzen kann oder nicht. Meiner Erfahrung nach gibt es noch sehr viele Firmen-PC's die Win98 am laufen haben (es gibt sogar noch Win 3.1 PC's !!!!). Da erübrigt sich die Frage nach .NET .

Für Kunden sind 3 Punkte wichtig. Das sind die Kosten, die ein Projekt verursacht, die Zeit die für ein Projekt gebraucht wird und das Ergebnis. Ob dabei .NET genutzt wird, Win32 oder was ganz anderes ist dem Kunden in den meisten Fällen egal.

Letzendlich sollte es für den Entwickler egal sein, ob er .NET entwickelt, Win32 oder sonstwas.

Was letztendlich Codegear/Borland machen wird, wird sich zeigen. Und...tot gesagt hat man Borland schon sehr häufig...komisch..sie existieren noch immer.