Delphi am "Ende"?

[mkinzler]

Zitat:

Zitat von holliesoft:
Sicher, es wird nicht sofort aussterben, aber spätestens dann wird Microsoft sagen: Leute, entwickelt für .net. Denn da muss eigentlich nur Microsoft die entsprechende Runtime für die neuen Prozessoren anpassen.
Steht zu befürchten.

das hat ja Microsoft schon lange angekündigt, noch (und auch bei Windows 8, soweit man es schon weis) ist davon aber nichts zu sehen. Selbst die Produkte von MS (ausser vielleichgt Teile des VS) sind bisher großteils nativ.

[divBy0]

Delphi am Ende? Komisches Ende bei der langen Diskussion... :mrgreen:

[Phoenix]

Zitat:

Zitat von mkinzler (Beitrag 1072998)

das hat ja Microsoft schon lange angekündigt, noch (und auch bei Windows 8, soweit man es schon weis) ist davon aber nichts zu sehen. Selbst die Produkte von MS (ausser vielleichgt Teile des VS) sind bisher großteils nativ.

Office lässt sich aber im Gegensatz zu Delphi-Anwendungen auch für einen ARM-Chip kompilieren weil deren C++ Compiler das kann und weil die ganzen neuen .NET Teile in Office eben auch Plattformunabhängig sind. Auf der CES haben sie u.a. Word auf ARM gezeigt.

[p80286]

Zitat:

Zitat von MEissing (Beitrag 1072930)

Jedes Jahr (seit 1995) kam ein Delphi Release auf den Markt.... in den letzten Jahren immer im Herbst. Seit 15 Jahren. Etwas verlässlicheres, absehbareres habe ich nicht in der Softwarebranche erleben dürfen.

wenn ich mir hierzu die Feature-Matrix anschaue....
(Bildschirmkopie im Anhang, hinterherfunktioniert ein Link nicht)

Gruß
K-H

[Assarbad]

Zitat:

Zitat von Phoenix (Beitrag 1073000)

Office lässt sich aber im Gegensatz zu Delphi-Anwendungen auch für einen ARM-Chip kompilieren weil deren C++ Compiler das kann und weil die ganzen neuen .NET Teile in Office eben auch Plattformunabhängig sind. Auf der CES haben sie u.a. Word auf ARM gezeigt.

Das einzige große Hindernis wäre wohl auch bloß wenn keine MMU vorhanden ist oder so :mrgreen:

Zitat:

Zitat von p80286 (Beitrag 1073002)

(Bildschirmkopie im Anhang, hinterherfunktioniert ein Link nicht)

Das Gebaren ist zwar nicht so schmeichelhaft für Emba, aber bloß weil er Mitarbeiter ist, kann er ja auch nicht auf alles Einfluß nehmen. Man sollte ihm also nicht alles vorwerfen aber er sollte auch nicht alles auf sich beziehen ...

[mkinzler]

Er ist ja nur der arme Bote, der uns die Entscheidungen anderer verkaufen muss.
Und ich glaube, dass er persönlich genau weis, dass wir nicht so dumm sind, wie anscheinend manche glauben.

[JamesTKirk]

Zitat:

Zitat von Phoenix (Beitrag 1073000)

Zitat:

Zitat von mkinzler (Beitrag 1072998)

das hat ja Microsoft schon lange angekündigt, noch (und auch bei Windows 8, soweit man es schon weis) ist davon aber nichts zu sehen. Selbst die Produkte von MS (ausser vielleichgt Teile des VS) sind bisher großteils nativ.

Office lässt sich aber im Gegensatz zu Delphi-Anwendungen auch für einen ARM-Chip kompilieren weil deren C++ Compiler das kann und weil die ganzen neuen .NET Teile in Office eben auch Plattformunabhängig sind. Auf der CES haben sie u.a. Word auf ARM gezeigt.

Ich bin mal gespannt, ob Microsoft von Windows 8 ARM auch ne Public Beta machen wird... wenn ja, dann dürfte ein arm-win32 Target für FPC relativ schnell stehen. :mrgreen:

Gruß,
Sven

[Insider2004]

Delphi ist nicht am Ende. Das sieht man implizit an Lazarus. Dort werden jeden Tag hunderte von Sourcen eingecheckt und tausende Downloads gemacht. Die Leute sind wie verrückt nach Pascal. Solange das so ist, wird auch Delphi seine Interessenten haben.

[QuickAndDirty]

Zitat:

Zitat von Phoenix (Beitrag 1072994)

Zitat:

Zitat von QuickAndDirty (Beitrag 1072989)

nur bei Oracle SQL ist es wohl so das die eben jeden Preis verlangen können...und das auch tun.

Du kannst Dich kostenlos im Oracle Developer Network registrieren und kannst darüber dann jede Ora-Version kostenlos zum Entwickeln runterladen: Der Produktiveinsatz kostet Geld, das Entwickeln gegen die DB nicht.

Dann wird das wohl alles an der Uni gelehrt, weil es kostenlos verwendbar ist!!!
Bei Oracle weiß ich nur das die Uni irgendwas was mit der OracleDB zu tun hat über "CA" bezog...in so einer art Abo modell...nur das "CA" den scheiß ausschließlich per Datenträger im Packet aus USA liefert...könnte sich dabei aber auch um ein DB oder ERM Tool gehandelt haben... ist halt etwas her.

Auf Jedenfall scheint es ja für Offene Standards und kostenlose IDEs,Compiler,Sprachen und Frameworks mehr wohlgefallen an UNIS zu geben...
...ich glaube nicht das die 3499€ IDE jemals einen Platz an irgendeiner Hochschule finden wird.

Mal eine andere Sache. Welches ist das größte Englishsprachige Delphi Forum? Ich habe so ein bischen das Gefühl das Delphi der Amiga unter den Programmiersprachen ist...also quasi vor allem in Deutschland und Indien Verwendung findet.

[Insider2004]

Delphi findet Verwendung in

Deutschland
Deutschland
Deutschland
Brasilien
Russland
China

[Namenloser]

Zitat:

Zitat von QuickAndDirty (Beitrag 1073043)

Mal eine andere Sache. Welches ist das größte Englishsprachige Delphi Forum?

Sagen wir's mal so... wird schon seine Gründe haben, dass wir hier in einem deutschen Forum einige nicht-deutschsprachige Mitglieder haben ;)

[Assarbad]

Zitat:

Zitat von NamenLozer (Beitrag 1073048)

Zitat:

Zitat von QuickAndDirty (Beitrag 1073043)

Mal eine andere Sache. Welches ist das größte Englishsprachige Delphi Forum?

Sagen wir's mal so... wird schon seine Gründe haben, dass wir hier in einem deutschen Forum einige nicht-deutschsprachige Mitglieder haben ;)

In Rußland (wurde ja oben schon erwähnt), gab es auch recht große Delphi-Communities. Aber auch die haben sich mittlerweile zu anderen Sprachen "hinentwickelt" ... :cry:

[QuickAndDirty]

Zitat:

Zitat von NamenLozer (Beitrag 1073048)

Zitat:

Zitat von QuickAndDirty (Beitrag 1073043)

Mal eine andere Sache. Welches ist das größte Englishsprachige Delphi Forum?

Sagen wir's mal so... wird schon seine Gründe haben, dass wir hier in einem deutschen Forum einige nicht-deutschsprachige Mitglieder haben ;)

DAS ist der Grund wieso ich auf die Frage komme!

Zitat:

Zitat von Insider2004 (Beitrag 1073046)

Delphi findet Verwendung in

Deutschland
Deutschland
Deutschland
Brasilien
Russland
China

äääähmm....das macht es Praktisch zu dem Comodore Amiga unter den Programmiersprachen. Vielleicht wäre es doch nicht ganz dumm ein Visual Studio Plugin draus zu machen...Denn zur zeit ist es ja ein Produkt das sich GEGEN Microsoft's IDE positioniert... das ist ein nur sehr schwer zu gewinnender Kampf!
Ohne Internationale Beachtung sieht es doch aber sehr schlecht aus oder? So als Visualstudio Plugin würde MS quasi indirekt Delphi und sein Verbreitung fördern! UND Delphi hätte die Möglichkeit immer noch etwas obendrauf zu setzen um besser als die anderen Visualstudio Sprachen zu sein...ist halt die Frage ob MS sowas lange mitmachen würde.
Sonnst gäbe es noch die Möglichkeit einer Existenz als Eclipse plugin....

ODER

man Entwickelt die eigene IDE zu einem Offenen Standard weiter in die man alle möglichen Sprachen per plugin einbringen kann...

[mkinzler]

Zitat:

sehr schwer zu gewinnender Kampf!

Delphi kann m.E. nur mit eigener IDE gewinnen

Zitat:

So als Visualstudio Plugin würde MS quasi indirekt Delphi und sein Verbreitung fördern! UND Delphi hätte die Möglichkeit immer noch etwas obendrauf zu setzen um besser als die anderen Visualstudio Sprachen zu sein...

Delphi würde aber nicht mit Vs ausgeliefert werden, sondern Delphi mit VS-Shell. Und an Delphi.Prism sieht man ja, dass es nicht reicht eine bessere Sprache zu entwickeln. Viele sehen Delphi.Prism eher als Zwischenschritt von Delphi nach c#.
[QUOTE]Sonnst gäbe es noch die Möglichkeit einer Existenz als Eclipse plugin....[QUOTE]Wäre schon besser als Vs-Shell. Aber das Grundproblem wäre das*selbe.

Zitat:

ODER

man Entwickelt die eigene IDE zu einem Offenen Standard weiter in das man alle möglichen Sprachen per plugin einbringen kann...

Da VS-Shell kostenlos ist, wird es schwer sein andere von der IDE zu überzeugen

[QuickAndDirty]

Also siehst du Delphis Zukunft in einer eigenständigen immer weiter hinter MS VS zurück fallenden IDE?
Dann haben wir ja bereits die Zukunft!

[mkinzler]

Das kann man natürlich nur schaffen, wenn man sich mehr um die Weiterentwicklung kümmert.

[Assarbad]

Zitat:

Zitat von mkinzler (Beitrag 1073075)

Das kann man natürlich nur schaffen, wenn man sich mehr um die Weiterentwicklung kümmert.

Ich persönlich finde, daß man sich statt "Weiterentwicklung" (im Sinne von Hinzufügen) erstmal auf die Behebung der bekannten Probleme konzentrieren sollte.

[DeddyH]

Das ist aber ein allgemeines Problem, nicht nur bei Emba. Vielerorts ist man meiner Beobachtung nach einer gewissen "Featuritis" erlegen. Wobei ich zugeben muss, dass die Kunden daran auch eine gewisse Mitschuld tragen.

[p80286]

Zitat:

Zitat von DeddyH (Beitrag 1073108)

Das ist aber ein allgemeines Problem, nicht nur bei Emba. Vielerorts ist man meiner Beobachtung nach einer gewissen "Featuritis" erlegen. Wobei ich zugeben muss, dass die Kunden daran auch eine gewisse Mitschuld tragen.

Die Kunden? Wohl eher die sog. Entscheider, die die jedem wolkigen Wortgeklingel hinter her laufen.
Haupsache chic!

Gruß
K-H

[mschaefer]

Da hat 'Embracadero' doch einiges getan.

Was ich mir doch als neue Funktion vorstellen könnte, wäre so eine Art 'ComponentStore' zentral für Delphi im Web mit Anbindung an die IDE, sodass man eigene Komponenten dort einstellen und von anderen, mit direkter IDE-Installation, abrufen kann.

Grüße in die Runde

[Assarbad]

Zitat:

Zitat von p80286 (Beitrag 1073147)

Zitat:

Zitat von DeddyH (Beitrag 1073108)

Das ist aber ein allgemeines Problem, nicht nur bei Emba. Vielerorts ist man meiner Beobachtung nach einer gewissen "Featuritis" erlegen. Wobei ich zugeben muss, dass die Kunden daran auch eine gewisse Mitschuld tragen.

Die Kunden? Wohl eher die sog. Entscheider, die die jedem wolkigen Wortgeklingel hinter her laufen.
Haupsache chic!

Ich halte es für eine Kombination. Man kann das mit diversen anderen Dingen vergleichen, wo die Mehrheit auch nicht durch die lauteste Gruppe vertreten wird. Wenn aber die lautesten Gehör finden? (Benutzer/Kunden) ... oder die Entscheider sogar aufgrund diverser Buzzwords den Realitätssinn verlieren und sich in die Buzzwords verlieben? (Entscheider)

Ich denke man kann es nicht auf eine Seite schieben, auch wenn man in den Foren bei Emba deutlich sehen kann von wo der Wind weht ("Entscheider"), wenn Leute die gezwungen werden unter Klarnamen zu posten als Trolle diffamiert werden, nur weil sie berechtigte Kritik anbrachten. Wie schon gesagt: so kann man mit seinen Kunden auch umgehen. Nur wie lange, ist die Frage ... womit wir wieder beim Thementitel wären :zwinker:

[littleDave]

Zitat:

Zitat von mschaefer (Beitrag 1073148)

Was ich mir doch als neue Funktion vorstellen könnte, wäre so eine Art 'ComponentStore' zentral für Delphi im Web mit Anbindung an die IDE, sodass man eigene Komponenten dort einstellen und von anderen, mit direkter IDE-Installation, abrufen kann.

Ich finde das an sich eine gute Idee. Jedoch nicht wegen dem 'ComponentStore', sondern eher als Community-Förderung. Die Anzahl der kommerziellen Delphi-Entwickler geht nun mal leider bergab, das ist nicht anfechtbar. Allein schon die Job-Ausschreibungen sind ein gutes Indiz dafür. Ein weiteres Beispiel habe ich direkt bei uns aus der Firma: ein Kunde wollte ein Software-Update für ihre Produktionssteuerung. Das bisherige System war in Delphi geschrieben und das von uns jetzt neu entwickelte System basiert komplett auf .NET - mit allen Vor- und Nachteilen. Es tat mir tief in der Seele weh, dass das ganze Delphi-System (ok, war grausamer Code - ist aber eine andere Baustelle) durch ein .NET-System abgelöst wurde. Ich denke, dass das häufiger vorkommt - und wenn ich ehrlich bin: der wirklich grausame Delphi-Quelltext war auf den ersten Blick kaum schwerer zu verstehen als der gute C#-Code -> Delphi ist halt von Anfang an auf Lesbarkeit abgestimmt, was ein riesen Vorteil z.B. in Code-Wartbarkeit ist.

Eine zentrale, zusammengeschweißte Community würde - meiner Meinung nach - dem Trend entgegenwirken. Wenn ich für .NET Komponenten suche, gibt es keine wirklich gute Seite wie z.B. Torry.net (jedenfalls habe ich noch keine gefunden). Mircosoft hostet zwar z.B. CodePlex - was bei kommerziellen Komponenten schon mal keine Option ist. Durch eine solche Community weiß man wenigstens, dass man nicht alleine ist. Das ganze mit einer sinnvollen und kundenfreundlichen Politik und bei vielen würde das mulmige Gefühl beim Wort "Delphi" im Zusammenhang mit "neues Projekt" schon sehr viel geringer werden - denn man wüsste, dass es eine aktive Community und aktiven Support gibt. Ich weiß, dass es bei Emba das QC und auch einige Komponenten gibt - jedoch wirkt das ganze noch nicht so rund.

Microsoft hat mit .NET wirklich einen großen Wurf gemacht - und Anhand der Update-Zyklen mit den verbundenen Neuerungen kann man sich schon grob vorstellen, was für eine Man-Power Microsoft in .NET steckt -> eine gigantische. Dem kann Emba natürlich nicht entgegen wirken, doch leider ist .NET - wie Delphi auch - auf Rapid-Development ausgelegt und somit eine sehr starke - wenn nicht sogar übermächtige - Konkurrenz. Um wieder etwas mehr mitmischen zu können, muss man erstmal versuchen, Boden unten den Füßen zu bekommen - und zwar am Besten mit dem, was .NET nicht kann: native(!) Anwendungen für Win32, Win64, MacOS, Linux, iOS und Android erstellen zu können. Apple liefert sogar eine steile Vorlage in dem sie sagen, dass auf dem iPhone nur native Anwendungen laufen dürfen. Wenn man dann jedoch mit Sachen wie SubVersion-Integration in die IDE sowie ein paar Bugfixes rumkleckert, dann ist es nicht 5 vor 12 sondern 20 nach 4 (ok, ist jetzt Böse ausgedrückt, aber die Kernaussage stimmt). Und das wichtigste dabei ist: so schnell wie möglich. Man muss den Leuten ja auch die Zeit geben, ihre Komponenten anzupassen. Was bringt einem ein 64-Bit-Compiler, wenn keine externen Komponenten funktionieren und man nur ein-zwei Buttons auf eine Form klatschen kann. Ich weiß, das ganze 64Bit-Gedöns wurde schon im "Delphi heißt jetzt Delphi XE" - Thread schon sehr ausführlich und emotional geführt, jedoch musste ich das jetzt so sagen.

Noch mal kurz zurück zu MS vs. Emba: man könnte auch versuchen, die Man-Power durch "Outsourcing" etwas auszugleichen. Ich meine damit: Emba konzentriert sich komplett auf einen soliden Compiler und eine ausgereifte IDE (man muss ja nicht gleich mit VS2010 gleichziehen - jedoch muss ein Fortschritt sichtbar sein). Datenbank-Componenten jedoch können z.B. an andere abgegeben werden. Und (meiner Meinung nach!) ganz wichtig: endlich von den bescheidenen Altlasten trennen. Im Jahre 2011 hat keiner mehr einen Anspruch darauf, ein Delphi-2-Programm ohne Änderungen neu kompilieren zu können. Und wenn das so wichtig sein sollte und das unbedingt beibehalten werden sollte: dann kann man das noch mit den nächsten 5 oder vielleicht sogar 10 Versionen machen und danach gibt es eh keine neue IDE mehr. Es kommen harte Zeiten auf Emba zu, denn die VCL z.B. ist nicht flexibel genug zum Abdecken aller Plattformen - da braucht es genug Anpassungen bis hin zum neu schreiben. Leider hat Emba nicht die Man-Power gleichzeitig noch neue Features wie Multi-Touch oder die Ribbons-Komponente (die ja, so wie ich das gelesen habe, nicht so der Hammer sein soll) einzubauen - daher meine Idee mit dem "Outsourcing" als letzte Option.

Und noch eine Meinung von mir: ich denke jeder hätte wegen der (mittlerweile ja mit Quellen belegten) Ankündigung eines 64Bit-Compilers im Jahre 2007/2008 nichts gesagt, wenn die Verschiebung (ich hoffe, dass es eine Verschiebung ist) begründet worden wäre; dass das ganze aber heimlich untern Tisch gekehrt wurde und nun sogar die Existenz dieser Meldung angezweifelt wird finde ich wirklich armselig. So geht man nicht mit seinen Kunden um. Auch deswegen gehen ja viele weg von Delphi: keiner kann sich mehr darauf verlassen, wie es weitergeht. Emba! Erarbeitet euch das Vertrauen wieder! Viele geben euch noch eine Chance! Es ist keine Schande zu sagen: wir schaffen es nicht bis zum xx.xx.201x -> wenn ihr wenigstens glaubwürdig darstellt, was bereits fertig ist und wie lange ihr noch brauchen werdet. Und wenn das dann zum neu prognostizierten Termin wirklich eine lauffähige Version mit den angekündigten Features in den Regalen steht, werdet ihr wieder Vertrauen genießen.

Grüße
David

[hanspeter]

Wo der Vorteil von Delphi gegenüber Net liegen soll, ist im Moment schwer zu begründen.
Da gibt es eigentlich nur zwei Begründungen. Einmal riesige Altlasten an vorhandenen Programmcode und zum anderen ein fortgeschrittenes Lebensalter beim Programmierer.
Um mit Delphi wieder neue Projekte anzufangen, müsste sich nach meiner Meinung konzeptionell einiges mehr tun.
Das beginnt bei der nicht threadsicheren VCL, geht über das BPL Konzept, was nur noch ein Klotz am Bein ist und endet nicht zuletzt bei der fehlenden Kompatibilität zu Net.
Wenn wenigstens in der IDE die lästigsten Fehler langsam behoben würden.
Wenn man zumindest aus Delphi heraus ein Assembly aufrufen könnte oder ein Delphiprogramm problemlos in Net einbinden könnte.
Allein schon die Entschärfung der Dll - Hölle durch das Assemblykonzept wäre ein Gewinn.
Prism sehen wir auch nur als Zwischenschritt zu C#. Dazu sind die Sprachelemente zu unterschiedlich.
Auch wenn GUI und Code strikt getrennt sind, kann man nicht einfach die GUI in Net neu schreiben und Delphi-Code über Prism ohne erhebliche Anpassungen weiterverwenden.
Der gleiche VCL - freie Quelltext in Prism und Delphi ist Illusion. Prism hat die moderneren Sprachkonstrukte. Warum diese nicht in Delphi nachziehen?
Multiplattform ist sicherlich interessant, darf aber nicht überbewertet werden.
In unserem Betrieb gibt es unter Java ein Projekt, welches auf Windows, Linux und Mac laufen soll.
Daraus sind inzwischen fast drei Projekte geworden. Eins für Window, eins für Linux ...
Was solche Diskussionen immer wieder aufkommen läßt, ist die mangelhafte Planungssicherheit und Informationspolitik.
Wenn Embacadero endlich mal Butter bei die Fische tut und eine belastbare Roadmap veröffentlicht wäre schon viel gewonnen.
Im Moment sind zu viele Fragezeichen, als das ich mich bei Entscheidungen zu Neuprojekten mit Delphi durchsetzen könnte.

Gruß
Peter

[Luckie]

Zitat:

Zitat von hanspeter (Beitrag 1073173)

Allein schon die Entschärfung der Dll - Hölle durch das Assemblykonzept wäre ein Gewinn.

Dafür hast du jetzt die NET-Framewok Hölle. Wie oft habe ich es schon erlebt, dass ein NET Programm mit dem installierten Framework nicht klar kam, weil es nicht abwärts kompatibel ist. Also einen wirklichen Fortschritt sehe ich da nicht wirklich.

[Phoenix]

Zitat:

Zitat von hanspeter (Beitrag 1073173)

Wo der Vorteil von Delphi gegenüber Net liegen soll, ist im Moment schwer zu begründen.

Das stimmt leider. Man kann (wenn man es kann :) ) auch in .NET eine DB-Oberfläche zusammenklicken wie mit Delphi.

Zitat:

Zitat von hanspeter (Beitrag 1073173)

Da gibt es eigentlich nur zwei Begründungen. Einmal riesige Altlasten an vorhandenen Programmcode und zum anderen ein fortgeschrittenes Lebensalter beim Programmierer.

Zweiteres zählt eigentlich auch nicht mehr. Wer sich von der VCL an das .NET Framework - zumindest mal im Bereich Windows Forms - umgewöhnen möchte kann das sehr schnell tun, denn die Frameworks sind sich zumindest dort sehr ähnlich.

Zitat:

Zitat von hanspeter (Beitrag 1073173)

Um mit Delphi wieder neue Projekte anzufangen, müsste sich nach meiner Meinung konzeptionell einiges mehr tun.
Das beginnt bei der nicht threadsicheren VCL, geht über das BPL Konzept, was nur noch ein Klotz am Bein ist und endet nicht zuletzt bei der fehlenden Kompatibilität zu Net.

Auch in .NET gibt es sehr vieles, was nicht Threadsicher ist. Und manches muss man leider am eigenen Leib erfahren (ich mache viel ASP.NET, da fällt das schneller auf weil da je nach Serverkapazität schonmal etliche hundert Threads gleichzeitig losrattern können).
BPL's: Muss niemand nutzen. Kompatibilität: Wäre für mich hier kein Argument. Mann kann (reverse) P/Invokes machen und gut ist. Und auch hier gibts fertige Tools für - wenn es wirklich notwendig ist.

Zitat:

Zitat von hanspeter (Beitrag 1073173)

Wenn wenigstens in der IDE die lästigsten Fehler langsam behoben würden.

Selbst wenn: Das kommt dann aber dank der Embc.-Politik wieder als 'neue Version' raus und nicht als SP.

Zitat:

Zitat von hanspeter (Beitrag 1073173)

Wenn man zumindest aus Delphi heraus ein Assembly aufrufen könnte oder ein Delphiprogramm problemlos in Net einbinden könnte.

Hydra?

Zitat:

Zitat von hanspeter (Beitrag 1073173)

Allein schon die Entschärfung der Dll - Hölle durch das Assemblykonzept wäre ein Gewinn.
Prism sehen wir auch nur als Zwischenschritt zu C#. Dazu sind die Sprachelemente zu unterschiedlich.

Yikes. Von Prism dann der Rückschritt zu C#?
Wartet nochmal ein halbes Jahr ab, und überlegt Euch dann nochmal ob ihr mit den Features-To-Come wirklich auf Prism verzichten wollt (nein, ich darf nicht verraten welche ich meine) :stupid:

Zitat:

Zitat von hanspeter (Beitrag 1073173)

Auch wenn GUI und Code strikt getrennt sind, kann man nicht einfach die GUI in Net neu schreiben und Delphi-Code über Prism ohne erhebliche Anpassungen weiterverwenden.
Der gleiche VCL - freie Quelltext in Prism und Delphi ist Illusion. Prism hat die moderneren Sprachkonstrukte. Warum diese nicht in Delphi nachziehen?

Weil viele von diesen Sprachkonstrukten auf IL-Internas basieren. Ich rede hier insbesondere von LINQ. Zumal der (neue) Prism-Compiler auch zu 100% managed ist. Das kann man nicht einfach so in einen nativen Compiler nachimplementieren ohne die Rückwärtskompatibilität zu opfern. Und wenn Embc. das macht, dann ist Delphi wirklich tot.

Zitat:

Zitat von hanspeter (Beitrag 1073173)

Multiplattform ist sicherlich interessant, darf aber nicht überbewertet werden.
In unserem Betrieb gibt es unter Java ein Projekt, welches auf Windows, Linux und Mac laufen soll.
Daraus sind inzwischen fast drei Projekte geworden. Eins für Window, eins für Linux ...

Fat clients sind auch kein Multiplatform-Ziel. ;-) Wenn man so eine Anforderung hat, dann sollte man einen Application Server hinstellen der auf (mindestens) einer Platform läuft (die verbreitetste ist ein guter Ansatz, wobei man hier mit .NET bzw. Mono tatsächlich unabhängig sein kann), man packt eine X-Platform Bibliothek hin die den Zugriff auf diesen Application-Server abhandelt und baut für jede Platform einen *nativen* thin-client, der über diese Bibliothek mit dem Server spricht.

Zitat:

Zitat von hanspeter (Beitrag 1073173)

Was solche Diskussionen immer wieder aufkommen läßt, ist die mangelhafte Planungssicherheit und Informationspolitik.
Wenn Embacadero endlich mal Butter bei die Fische tut und eine belastbare Roadmap veröffentlicht wäre schon viel gewonnen.
Im Moment sind zu viele Fragezeichen, als das ich mich bei Entscheidungen zu Neuprojekten mit Delphi durchsetzen könnte.

Wahr. Leider zu wahr.

[Insider2004]

Vorteil Delphi: schneller, schlanker Code (.net ist 15x langsamer) und für Delphi gibt es hunderttausende Komponenten/Code-Beispiele (für .net gibts nix)

[Phoenix]

Zitat:

Zitat von Insider2004 (Beitrag 1073178)

Vorteil Delphi: schneller, schlanker Code (.net ist 15x langsamer)

Das ist ein Gerücht. Und zwar ein schlechtes und unhaltbares. Wir parsen mit .NET einen nicht ganz kleinen Stream der kompletten Handelsdaten an der deutschen Börse (CEF-Feed) mit .NET auf einem IBM Thinkpad - in Echtzeit. Und haben noch Zeit, die Kurse die da kommen zu aggregieren.

Wenn Du das mit Delphi schaffst, dann bist Du *sehr* gut. Und Du brauchst unter Garantie viel mehr Code. Und das System kann man dann nicht einfach mal so von einem Windows auf einen Linux-Server umtopfen wenns Not tut.

Zitat:

Zitat von Insider2004 (Beitrag 1073178)

und für Delphi gibt es hunderttausende Komponenten/Code-Beispiele (für .net gibts nix)

• http://www.telerik.com/products/winforms.aspx
• http://www.devexpress.com/Products/N...rols/WinForms/
• http://www.infragistics.com/dotnet/n....aspx#Overview

Das ist nur Windows forms, von WPF, Silverlight und ASP.NET-Komponenten mal komplett abgesehen.

Codebeispiele?

• http://www.codeproject.com/
• http://www.aspxcode.net/
• http://msdn.microsoft.com/en-us/library/dw70f090.aspx
• http://www.example-code.com/

Nur so als klitzekleine Auswahl. Da gibt es massiv mehr als für Delphi.

[Chemiker]

Hallo,

also der größte Nachteil den ich bei .NET sehe ist es, dass der eigene Quellcode mit relativ wenig Aufwand offen liegt. Dies wurde auf der EKON 14 demonstriert und es gehen Gerüchte um das MS dadurch neue Geschäftsfelder erschließen will.

Bis bald Chemiker

[Insider2004]

Zitat:

Zitat von Chemiker (Beitrag 1073188)

Hallo,

also der größte Nachteil den ich bei .NET sehe ist es, dass der eigene Quellcode mit relativ wenig Aufwand offen liegt. Dies wurde auf der EKON 14 demonstriert und es gehen Gerüchte um das MS dadurch neue Geschäftsfelder erschließen will.

Bis bald Chemiker

.net code wird ja auch erst beim Aufruf übersetzt. Alles liegt offen. Faktisch ist .net wie Java. Für den professionellen Einsatz und überall, wo der Quellcode geheim bleiben muss ist Java oder .net tabu.

[Phoenix]

Zitat:

Zitat von Chemiker (Beitrag 1073188)

also der größte Nachteil den ich bei .NET sehe ist es, dass der eigene Quellcode mit relativ wenig Aufwand offen liegt.

Mit genau so wenig Aufwand kann man den Quellcode aber auch entsprechend schützen. Der kostenlos herunterladbare Oxygene-Compiler von Delphi Prism ist ein .NET Programm. Versuch Dich doch mal mit dem Reflector an dem Teil ;-)

Auch andere Firmen (AutomatedQA z.B.) haben Produkte auf .NET Basis die entsprechend geschützt sind - und das ist eine einzige Zeile im Post-Build-Prozess. Wer das nicht macht ist einfach selber schuld. Ich nenne jetzt keine Namen, aber es gibt einen Hersteller von .NET Entwicklungs-Tools die u.a. die Methode die den Trial-Zeitraum resetted in ihren Assemblies von aussen aufrufbar im Klartext bereithält.

[Chemiker]

Hallo,

Zitat:

Versuch Dich doch mal mit dem Reflector an dem Teil

Es wurden auch verschiede Schutzmaßnahmen vorgestellt, trotzdem war es relativ einfach den Quellcode offen zulegen, Ob Deine dabei waren kann ich zurzeit nicht sagen, weil ich die Aufzeichnungen irgendwie verlegt habe.

Bis bald Chemiker

[hanspeter]

Zitat:

Zitat von Phoenix (Beitrag 1073191)

Weil viele von diesen Sprachkonstrukten auf IL-Internas basieren. Ich rede hier insbesondere von LINQ. Zumal der (neue) Prism-Compiler auch zu 100% managed ist. Das kann man nicht einfach so in einen nativen Compiler nachimplementieren ohne die Rückwärtskompatibilität zu opfern. Und wenn Embc. das macht, dann ist Delphi wirklich tot.

So tief hatte ich eigentlich nicht gedacht.
In Delphi "method" als zusätzliches Schlüsselwort, Case mit String, compatible Generics ...
Einfach eine Klassendeclaration in beiden Systemen parallel verwenden können.
Es geht hier um die Weiterverwendung bestehenden Delphi - Codes.

Zitat von Insider2004:
und für Delphi gibt es hunderttausende Komponenten/Code-Beispiele (für .net gibts nix)

Man darf nicht übersehen, das das Net-Framwork um Größenordnungen vollständiger als die VCL ist.
In der VCL gibt es einige hundert Klassen im Net-Framework einige tausend.
Viele Delphi - Toolhersteller bieten Net Versionen an oder sind gar ganz auf net umgeschwenkt.
Viele unter Delphi erfogreiche Tools stehen auch in Net zur Verfügung. (z.B. Express quantum, Fastreport ...)

Gruß
Peter

[Robotiker]

Zitat:

Zitat von littleDave (Beitrag 1073164)

Um wieder etwas mehr mitmischen zu können, muss man erstmal versuchen, Boden unten den Füßen zu bekommen - und zwar am Besten mit dem, was .NET nicht kann: native(!) Anwendungen für Win32, Win64, MacOS, Linux, iOS und Android erstellen zu können.

Ich habe schon Zweifel, wenn ich hier lese Delphi sei für native Win32 Programmierung das beste Tool ...

Abseits von GUI und Datenbanken tut sich da bei anderen im Moment sehr viel:

Intel hat sein Parallel Studio, Visual C++ 2010 seine Concurrency Runtime
http://msdn.microsoft.com/de-de/library/dd504870.aspx

Mein C++ Builder XE hat TThread und Synchronize. :oops:
Fragen zur Unterstützung von Intels Threading Building Blocks werden im Embi-Forum so beantwortet:
https://forums.codegear.com/message....essageID=42979
(Sinnigerweise ist der Beantworter der Frage inzwischen zu Apple gewechselt.)

Vor lauter Unicode, Win64 und Mac wird da die nächste Entwicklung verschlafen.

[p80286]

Zitat:

Zitat von hanspeter (Beitrag 1073198)

In der VCL gibt es einige hundert Klassen im Net-Framework einige tausend.

Wenn diese Klassen aber die gleiche Qualität wie in VBA haben, und die Vermutung liegt nahe, dann kann ich gut darauf verzichten.

Gruß
K-H

[holliesoft]

Zitat:

Zitat von Insider2004 (Beitrag 1073178)

Vorteil Delphi: schneller, schlanker Code (.net ist 15x langsamer)

Das kann ich nicht bestätigen...

Ich verarbeite auf der Arbeit mit einem .net-Programm z.B. Logdateien, die ich vorher mit einem Delphi-Programm verarbeitet hatte. Das .net Programm ist min. doppelt so schnell!

Gruß
Patrick

[Assarbad]

Zitat:

Zitat von littleDave (Beitrag 1073164)

Ich finde das an sich eine gute Idee. Jedoch nicht wegen dem 'ComponentStore', sondern eher als Community-Förderung. Die Anzahl der kommerziellen Delphi-Entwickler geht nun mal leider bergab, das ist nicht anfechtbar. [...] Es ist keine Schande zu sagen: wir schaffen es nicht bis zum xx.xx.201x -> wenn ihr wenigstens glaubwürdig darstellt, was bereits fertig ist und wie lange ihr noch brauchen werdet. Und wenn das dann zum neu prognostizierten Termin wirklich eine lauffähige Version mit den angekündigten Features in den Regalen steht, werdet ihr wieder Vertrauen genießen.

Wow, ich denke du sprichst einigen anderen hier auch aus dem Herzen.

Zitat:

Zitat von Phoenix (Beitrag 1073177)

Selbst wenn: Das kommt dann aber dank der Embc.-Politik wieder als 'neue Version' raus und nicht als SP.

Klartext! :thumb:

Zitat:

Zitat von Insider2004 (Beitrag 1073178)

Vorteil Delphi: schneller, schlanker Code (.net ist 15x langsamer) und für Delphi gibt es hunderttausende Komponenten/Code-Beispiele (für .net gibts nix)

Huch, geht mein Kalender falsch? Hier steht 2011, hast du noch 2004? :stupid:

Zitat:

Zitat von Phoenix (Beitrag 1073180)

Zitat:

Zitat von Insider2004 (Beitrag 1073178)

Vorteil Delphi: schneller, schlanker Code (.net ist 15x langsamer)

Das ist ein Gerücht. Und zwar ein schlechtes und unhaltbares.

Es ist definitiv kein Gerücht, wie dir ein Profiler schnell beweisen wird. Natürlich reicht es nicht auf die Verhältnisse zu schauen, sondern man muß schon auf die absoluten Zahlen schauen bei sowas. Allerdings hat .NET ja andere Vorteile ... am Ende heißt es einfach (wie so oft): abwägen.

Zitat:

Zitat von Phoenix (Beitrag 1073191)

Mit genau so wenig Aufwand kann man den Quellcode aber auch entsprechend schützen. Der kostenlos herunterladbare Oxygene-Compiler von Delphi Prism ist ein .NET Programm. Versuch Dich doch mal mit dem Reflector an dem Teil ;-)

... und dann versuch's nochmal mit IDA Pro. Auch wenn die richtig bequemen Methoden damit wegfallen, sind die .NET-Primitiven noch deutlich einfacher lesbar als x86-Assembly.

Allerdings ist ohnehin fragwürdig wieviel Schutz notwendig ist usw. ... und im Zweifelsfall implementiert man etwas über nativen Code und bindet per P/Invoke an.

Zitat:

Zitat von Robotiker (Beitrag 1073199)

Ich habe schon Zweifel, wenn ich hier lese Delphi sei für native Win32 Programmierung das beste Tool ...

Echt? Also ich würde da mitgehen, allerdings konkretisieren: das beste RAD-Tool für den Zweck.

Zitat:

Zitat von holliesoft (Beitrag 1073219)

Zitat:

Zitat von Insider2004 (Beitrag 1073178)

Vorteil Delphi: schneller, schlanker Code (.net ist 15x langsamer)

Das kann ich nicht bestätigen...

Ich verarbeite auf der Arbeit mit einem .net-Programm z.B. Logdateien, die ich vorher mit einem Delphi-Programm verarbeitet hatte. Das .net Programm ist min. doppelt so schnell!

Da hätte ich doch gern mal die Rahmendaten. Auch wäre hier ein Vergleich der benutzten Funktionen und eine Überprüfung der Testmethoden angebracht. Wird bspw. nach jedem Testlauf neu gebootet? .NET-Code läuft meiner Erfahrung nach oft ein wenig langsamer, auch wenn ich mich auf das 15fache nicht festlegen wöllte ...

[DSCHUCH]

Zitat:

Zitat von hanspeter (Beitrag 1073173)

geht über das BPL Konzept,

ist zwar etwas OT, aber:
ich höre es des öfteren, dass das bpl konzept nicht gut wäre. wieso eigentlich? ich finde es äußerst praktisch und flexibel und vor allem sehr einfach zu verwenden. globale klassen/variablen über dll's automatisch verteilen, funktionalitäten in großen projekten über alle module gleich halten, was gibt es hier zu bemängeln?

[mirage228]

Zitat:

Zitat von mschaefer (Beitrag 1073148)

Was ich mir doch als neue Funktion vorstellen könnte, wäre so eine Art 'ComponentStore' zentral für Delphi im Web mit Anbindung an die IDE, sodass man eigene Komponenten dort einstellen und von anderen, mit direkter IDE-Installation, abrufen kann.

Finde ich von der Idee her interessant. Wäre eine prima Ergänzung zu den vielen bestehenden Komponentenseiten und den viel zahlreicheren Einzelseiten im Internet. Besonders kurz zum Ausprobieren die angesprochene IDE-Installation bestimmt auch nützlich. Außerdem könnte Embarcadero über Umsatzbeteiligungen an einem dort integrierten e-Payment ggf. neue Gewinnfelder erschließen (muss sich für die ja auch lohnen).

[hanspeter]

Zitat:

Zitat von DSCHUCH (Beitrag 1073317)

ist zwar etwas OT, aber:
ich höre es des öfteren, dass das bpl konzept nicht gut wäre. wieso eigentlich? ich finde es äußerst praktisch und flexibel und vor allem sehr einfach zu verwenden. globale klassen/variablen über dll's automatisch verteilen, funktionalitäten in großen projekten über alle module gleich halten, was gibt es hier zu bemängeln?

Arbeite ich mit bpl muss das gesamte Projekt immer gegen die gleiche Compilerversion und innerhalb der Version meist auch noch das gleiche Release compiliert sein.
Ändere ich in irgendeiner bpl etwas im Interfaceteil, müssen alle Bpl und alle Exe, welche sich auf diese beziehen neu kompiliert werden.
Tut man das nicht, kommt gerne der Fehler ".. wurde mit unterschiedlicher Version compiliert".
Befinden sich aus irgendwelchen Gründen mehrere bpl Versionen im Zugriff des Programms, ist das Chaos perfekt. (< Delphi 7 hat BPL nach Windows/System oder ähnlich kopiert). Also kleine Programmänderung und alle 250 BPL der Umgebung neu mit ausliefern. Das betrifft auch andere Programme, wenn diese auf den gleichen BPL Pool zugreifen. Ohne saubere Versionsverwaltung, tritt der Fehler erst beim Kunden auf.
Assemblys verwenden ,ähnlich wie ein Com-Objekt eine Signierung. Das Programm ist in der Lage im Assembly-Cache die richtige Bibliotheksversion zu finden.

Was auch noch zum Thema passt. Heute ist der neue Tiobe-Index für Januar erschienen. DElphi dümpelte immer auf Platz 10/11. Mal im Vergleich der 10
wichtigsten Sprachen drinnen, dann wieder draußen. Im Januar erstmalig auf Platz 12 abgerutscht.


Gruß
Peter

[Assarbad]

Zitat:

Zitat von hanspeter (Beitrag 1073327)

Was auch noch zum Thema passt. Heute ist der neue Tiobe-Index für Januar erschienen. DElphi dümpelte immer auf Platz 10/11. Mal im Vergleich der 10
wichtigsten Sprachen drinnen, dann wieder draußen. Im Januar erstmalig auf Platz 12 abgerutscht.

... dicht gefolgt von Lisp. Eine gute Wahl, daß ich jetzt angefangen habe Lisp zu lernen :zwinker: