Wer braucht Delphi XE - go back to the roots!

[Bernerbaer]

Das Management von Embarcadero wie zuvor Codegear trifft meines Erachtens merkwürdige und zweifelhafte Entscheidungen über die Zukunft von Delphi.

Cloud Computing:
Ich kann mir (mindestens für Europa) kaum vorstellen, das Kunden Interesse an Applikation haben, die ihre Daten in einer grauen Wolke abspeichern. Möchte Embarcadero ihre Sourcecodes Google anvertrauen oder einem anderen Anbieter eines Cloud Dienstes? Oder können Sie sich vorstellen ihre Offerten, Rechnungen, Sourcecodes oder Kundenlisten extern irgendwo zu lagern? Firmen werden weiterhin auf normale Desktopapplikationen setzen, auch in 5 oder 10 Jahren. Datenschutz wird immer wichtiger und Firmen werden immer sensibler bei Datenschutzfragen und lassen sich durch Zusicherung von Verschlüsselunen nicht einfach beruhigen. Also weshalb soll ich mir eine Programmierumgebung anschaffen, welche ich bei meinen potentiellen Kunden nicht einsetzen kann?

SVN Integration:
Denkt Embarcadero Delphientwickler seien dumm oder fahrlässig? Weshalb eine Integration von SVN in die IDE so wichtig ist, dass entscheidende Erweiterungen zurückgesetzt werden (64Bit Compiler), lässt mich vermuten, dass Embarcadero denkt, wir Delphientwickler würden seit mehr als 10 Jahren unsere Projekte ohne Versionskontrolle entwickeln. Ich denke kaum ein professioneller Delphientwickler hat nicht bereits irgend eine funktionsfähige und professionelle Verwaltung für seine Projekte am laufen.

Multiplattformentwicklung:
Klar tönt es auf den ersten Blick verlockend gleichzeitig Code für Windows, Apple, Linux zu entwickeln, aber trotz Crosscompilern wird dies kaum jemals wirklich funktionieren. Delphientwickler sind seit Delphi 1.0 Windowsentwickler. Windows kennen die meisten Delphientwickler ausgezeichnet, Das Windows API ist ihr tägliches Brot, Kenntnisse der Besonderheiten von Betriebssystem sind die Voraussetzung für das Programmieren von Applikationen und kaum ein Delphientwickler hat genügend Kenntnisse über andere Betriebssysteme. Softwarefirmen suchen spezialisierte Entwickler für die Anpassung ihrer Applikationen für andere Betriebssysteme und diese Entwickler kennen und setzen Programmierumgebungen ein, die zu ihrem Betriebssystem passen und dafür erstellt worden sind. Setzt mal einem Mac-Entwickler Lazarus vor! Er wird die Augen verdrehen und stöhnen aber nicht beginnen zu programmieren. Einzig Hobbyentwickler werden interessiert sein an einem Crosscompiler, doch mit diesen wird Embarcadero kaum überleben können und Hobbyentwickler werden kaum in der Lage sein die teuren Versionen zu kaufen.

Zurück zu den Ursprüngen:
Delphientwickler sind Windowsentwickler. Sie erstellen Windowsapplikationen. Windows gibt es in zwei Grundversionen: 32Bit und 64Bit. Dazu benötigen sie eine schlanke, sichere und schnelle Entwicklungsumgebung basierend auf der modernisierten aber immer noch einmaligen Programmiersprache Pascal. Ich denke die Kombination von der Einfachheit der Sprache Pascal, ihrer Mächtigkeit und der Möglichkeit rasch komplexe GUI Projekte zu erstellen ist die Ursache dafür, dass wir noch Delphientwickler geblieben sind und nicht zu C# oder C++ gewechselt haben. Aber damit wir weiterhin für Windows mit Delphi Software programmieren können, muss uns Embarcadero auch das Werkzeug für 32 Bit und 64 Bit Windowsapplikationen zu erstellen zur Verfügung stellen.

[generic]

Ach bitte nicht noch einen "Delphi ist doof" Bash0r Thread.

Schreib doch David-I oder Mike Rozlog deine Wünsche.
Als Kunde ist das dein gutes Recht.

David ist übrigens auch bei den Delphi-Tagen dabei. Da kann er auch zu solchen Themen gerne interviewed werden.

[Bernerbaer]

Wo steht in meinem Text "Delphi ist doof"? Wenn das so rübergekommen ist, dann war mein Text unklar formuliert. Nein ich behaupte ja das Gegenteil, Delphi ist genial! Aber ich wünsche mir, dass Delphi - Delphi bleibt - ein innovatives und modernes Werkzeug für das ERstellen von Windowsapplikationen. Nicht mehr aber auch nicht weniger. Mehr bringt eine Verzettelung die Niemanden oder nur sehr wenigen einen Nutzen bringt. Weniger schadet der Verbreitung von Delphi.

[himitsu]

Nur noch kurz was zur Multiplattformentwicklung:
- Klar ist es nicht immer optimal den selben (Mischmasch)Quellcode einfach nur für alle Plattformen zu kompilieren,
- Aber es wäre schon schön, wenn man auch für die anderen Plattformen Programme mit unserer schönen Delphisyntax+IDE erstellen könnte.

PS: Win64 und Win32 sind quasi auch nur unterschiedliche Plattformen,
auch wenn sie sich vielleicht ähnlicher sind, als ein Win32 und ein Linux32.



Ob man nun letztendlich die selbe XPlattform-Library für ein Windows- und ein Mac/Linux-Programm nutzt,

oder ob man zwar die selbe IDE, aber dennoch jeweils die zum jeweiligen OS passenden Libs nimmt, ist mir grundsätzlich erstmal egal ... Hauptsache die IDE, CL/VCL und vorallem der Compiler können endlich mal mehr, als nur Win32.

[Bernerbaer]

Zitat:

Zitat von himitsu (Beitrag 1045630)

Nur noch kurz was zur Multiplattformentwicklung:
- Klar ist es nicht immer optimal den selben (Mischmasch)Quellcode einfach nur für alle Plattformen zu kompilieren,
- Aber es wäre schon schön, wenn man auch für die anderen Plattformen Programme mit unserer schönen Delphisyntax+IDE erstellen könnte.

Da bin ich mit dir vollkommen einverstanden. Es wäre wirklich schön.

Ich zweifle einfach an dem Erfolg einer nicht für ein BS optimierten Programmierumgebung. Die Portierung der VCL auf MAC oder Linux wird extrem viel Arbeitsaufwand nach sich ziehen, damit der normale Mac- oder Linuxanwender nicht auf den ersten Blick sieht, dass es nicht eine speziell für seine Plattform programmierte Anwendung ist. Wenn ich mal eine mit Lazarus erstellte Anwendung einem Linuxanwender oder einem Macuser zeige, lacht der mich aus, bezahlt für sowas aber bestimmt kein Geld - Wenn der Look nicht stimmt, kann der Sourcecode und das Programm noch so gut sein, es wird vom Markt nicht akzeptiert.

Also, ist eine jahrelange Entwicklung sinnvoll für ein Produkt, das nur wenige Delphianer gewinnbringend einsetzen werden können und dabei den Ursprung und die Zukunft von Delphi (Windows) zu vernachlässigen?

[edit]Rechtschreibefehler korrigiert[/edit]

[wicht]

Ich möchte einfach nur zum Ausdruck bringen, dass ich mich Bernerbaer voll anschließe.
Dieser ganze komische Firlefanz, das brauche ich nicht. Delphi ist für mich das beste, um schlanke Anwendungen für Windows zu entwickeln. Dabei sollte es auch bleiben, lieber mal aus der IDE die verschiedenen Böcke (ErrorInsight oder wie es heißt z.B.!) raushauen, 64-Bit Unterstützung einbauen und vielleicht die Icons nicht im 16-Farben-Look führen, sowas finde ich auch nicht komplett unwichtig.. :wink:
Windows Anwendungen, klein, schlank und schnell gebaut, auf jedem Windows lauffähig, das ist das, wofür Delphi für mich steht. Ganz ehrlich - ich würde niemals auf die Idee kommen, meine Webseiten mit dem PHP-Delphi zu bauen. Und Delphi Prism... kann sein, dass das schön ist, nie probiert. Aber Kylix ist tot und ich vermute irgendwie, dass es dem PHP-Ding ähnlich ergehen wird. Wer weiß wie es mit Prism aussieht?
Einfach auf Windows konzentrieren, dann bleiben wenigstens die bisherigen Nutzer erhalten...

Hört sich ganz schön schwarzmalerisch an, ich will auch keine Nutzer angreifen vom Delphi-PHP oder von Delphi Prism, aber das ist eben mein Standpunkt.

[Daniel]

:cyclops:

Unterscheidet sich das jetzt inhaltlich noch von den derzeit 633 Beiträgen zum Thema "Delphi XE"?
http://www.delphipraxis.net/153609-d...delphi-xe.html

[Bernerbaer]

Ich kenne jetzt nicht alle 632 andere Threads. Aber ich hoffe dieser Thread ist sachlicher. Es geht hier um den Unterschied zwischen Wünschen und rationalen Entscheidungen. Grundsätzlich ist es doch so, wenn man einen Entwickler fragt, willst du die Integration von SVN, willst du Cloud-Programme erstellen können, willst du für mehrere Plattformen entwickeln können, willst du sowohl für Windows 32 als auch für Windows 64 Software erstellen, wird keiner nein sagen, auch ich nicht!

Wünsche sind jedoch selten Anlass für rationale Entscheidungen im Geschäftsumfeld. Dort geht es ganz sachlich um Aufwand und Ertrag.[edit] Deshalb zweifle ich ja an den Entscheidungen von Embarcadero. Wie sinnvoll ist es sich zu verzetteln und auf aktuelle Schlagwörter wie Cloud Computing zu reagieren und dabei die rationalen Entscheidungen der Kunden zu ignorieren?[/edit]

Kurz gesagt:

Verdiene ich mit integriertem Cloud mehr als ohne?
Verdiene ich mit integriertem SVN mehr also ohne?
Verdiene ich mit Multiplattform mehr als ohne?
Verdiene ich mit 64-Bit mehr als ohne?


Wenn ich die die Antworten für mich gebe, muss ich 3 mal mit Nein antworten und nur einmal mit Ja. D.h. rational gesehen werde ich auf XE und Nachfolgeprodukte verzichten bis 64Bit vorhanden ist.

Zwar scheint es auf den ersten Blick bei Multiplattform auch ein Ja zu sein, doch wenn ich nüchtern rechne und analysiere wie lange ich mich jeweils in das entsprechende Betriebssystem einarbeiten muss, bin ich auf dem Markt mit einem spezialisierten Softwareentwickler für den Mac oder für Linux nicht mehr konkurrenzfähig. Also auch hier mal ein nüchternes Nein. Also werde ich wohl erst eine neue Delphiversion kaufen, wenn ein 64 Bit Compiler integriert ist.

Also wie sehen die Antworten bei Euch aus? Dabei meine ich nicht die Antworten auf die Wünsche, die kenne ich (da sagen alle Ja!) sondern auf die wirtschaftlichen Aspekte.

kauft ihr XE oder ein Nachfolgeprodukt weil es
- Cloud Programme erstellen kann
- SVN in der IDE integriert hat
- Multiplattform fähig ist
- einen 32Bit und einen 64 Bit Compiler aufweist?

[edit]Rechschreibefehler behoben[/edit]

[Dezipaitor]

Laut Pattinson haben die in XE eine Menge Fehler in der neuen Version entfernt (Ist das nun gut oder schlecht?). D.h. sobald mal die neue Version draußen ist, werden die Fehler in der alten 2010er wohl nicht so schnell gefixt. Das macht sich besonders bei den Generics bemerkbar, die zwar besser geworden sind, aber wo sich noch eine menge Leute aufregen. 87 Fehler wurde da in XE gefixt und die Frage stellt sich, ob sie auch noch in D2010 gefixt werden. (Vllt. muss man aber noch ein paar Fehler davon abziehen, weil neue Funktionen hinzukamen und Kompatibilität gebrochen wurde.)
Es gibt immernoch sehr oft Linker- und Compilerfehler, die seit ewigen Zeiten bestehen (z.B. der Linkerfehler, der auftritt, wenn man externe Debugsymbole mit Mapdateien und mehr hinzufügt). Und es gibt wohl einen Bug im Debugger, der den Rückgabewert einer Funktion ändert, wenn man mit F7 (statt F8) versucht zu debuggen.

Und dann sind da VCL Probleme, insbesondere mit 64bit Systemen als 32bit Prozess (z.B. Registryzugriff mit WOW64 funktioniert nicht richtig).
Viele ärgert die schlechte native Unterstützung von transparenten Controls und PNGs für wirklich gutaussehende GUIs. Da kann mir Storm! wohl nur zustimmen :) und gute Beispiele geben.

Weiterhin gibt es noch eine Menge Fehler in der Windows.pas, die bis heute nie gefixt wurden (Quelle: Toolbox 5/2010, Zugriffssteuerung via API und Delphi).

Wenn man auf solche Fehler stößt, dann kann das ganz schön frustrierend sein herauszufinden, dass sie schon eine lange Zeit in Delphi existieren.

Ich glaube eine Menge Programmierer wären viel glücklicher, wenn ihre aktuellen Probleme erstmal reduziert und nicht durch neue Funktionen in den Hintergrund gedrängt werden würden. Das ist meine Meinung und ich bin einer davon.




Wobei man bei SVN sagen muss, dass dies schon lange gewünscht wurde. Das Problem ist nun jedoch, dass alle, die SVN verwenden, eben TortoiseSVN (o.Ä.) verwenden und damit glücklich sind. Das ist natürlich Pech, insbesondere wenn man bedenkt, dass SVN für Delphi schon seit Jahren als Opensource bei Sourceforge existiert und dahindümpelt (wobei die von EMB ja es als Basis nutzen). Jetzt, wo es (fast) schon zu spät ist, da wird es eingebaut. Hätte eigentlich jemand dafür bezahlt, wenn es DelphiSVN kommerziell gegeben hätte?

Was das Cloud angeht, das scheint mir wohl programmiertechnisch schnell umsetzbar gewesen zu sein. Zumindest schneller als 64bit Unterstützung. Irgendeine führende Funktion muss ja das nächste Delphi bekommen, sonst würde es nur als großes Update angesehen werden und alle würden schreien, dass es unverschämt sei ein Update als neue Version rauszubringen.

Und Linux und Mac! Das scheint mir deshalb gemacht worden zu sein, weil iPhone, Android usw. wohl ein attraktiver Markt auch für Delphientwickler zu sein scheint. Ich kann mir schon gut vorstellen, dass EMB da mitmachen will. Wer auf Linux mit Pascal programmieren will (oder muss), der wird Freepascal und die IDE Lazarus verwenden. Wobei ich schon erfahren musste, dass FP von Firmen irgendwie nicht ernst genommen wird (ka warum) und viele den "neuen Syntax" von Delphi in FP vermissen. Auf der anderen Seite muss man denen von FP und Lazarus zugutehalten, dass Bugs relativ schnell gefixt werden (Corpsman wird das bezeugen).

[Hansa]

Zitat:

Zitat von Bernerbaer (Beitrag 1045637)

kauft ihr XE oder ein Nachfolgeprodukt weil es
- Cloud Programme erstellen kann
- SVN in der IDE integriert hat
- Multiplattform fähig ist
- einen 32Bit und einen 64 Bit Compiler aufweist?

Die Fragen sind ja gut, aber : da fehlt das "weil", also :

Kauft jemand mein Programm, weil es :

Zitat:

1. Cloud Programme erstellen kann
2. SVN in der IDE integriert hat
3. Multiplattform fähig ist
4. einen 32Bit und einen 64 Bit Compiler aufweist?

1. glaubs kaum. Eher Nein.
2. definitiv : Nein
3. (fast) definitiv : Nein. z.B.: Es gibt Firmenstandards. Konkreter Fall : es wird Office gefordert. Was nutzt da der Mac, Linux etc.?
4. 64 Bit ? Wers dringend braucht ? Die meisten wohl nicht.

Ich verstehe die ganze Frage nicht so ganz.

4.

[cookie22]

Zitat:

Laut Pattinson haben die in XE eine Menge Fehler in der neuen Version entfernt (Ist das nun gut oder schlecht?). D.h. sobald mal die neue Version draußen ist, werden die Fehler in der alten 2010er wohl nicht so schnell gefixt.

für die delphi 2010 nutzer ist das schlecht. die fehler in der 2010er version werden wohl bleiben.

genau das, ist auch der grund warum soviele leute das vertrauen verlieren. man zahlt für ein produkt und bugfixes kommen nicht mal ein jahr lang. das ist schon mehr als dünn.

Zitat:

Ich glaube eine Menge Programmierer wären viel glücklicher, wenn ihre aktuellen Probleme erstmal reduziert und nicht durch neue Funktionen in den Hintergrund gedrängt werden würden. Das ist meine Meinung und ich bin einer davon.

ich bin ein weiterer. :)

[himitsu]

Jupp, Laut dem Upgradepfad sind dieletzten 3 Versionen Upgradeberechtigt,

also wäre es schön, wenn man mindestens in diesen Versionen auch die bekannten Bugfixxes mit einfließen ließe.
(und schwerwiegende Fehler in allen Versionen, soweit es möglich ist)

Aber sobald hier eine neue Version drausen ist, denkt man wohl nicht mehr viel an die älteren Kunden nach ... außer vielleicht "ihr wollt Bugfixes? dann kauft sie euch doch."



@Chäffe: Notfalls könnte man diesen Thread ja mit drüben dranhängen.

[mkinzler]

4. Viele benötigen es schon und sind deshalb zu anderen Sprachen abgewandert.

[Bernerbaer]

Zitat:

Zitat von Dezipaitor (Beitrag 1045638)

Laut Pattinson haben die in XE eine Menge Fehler in der neuen Version entfernt (Ist das nun gut oder schlecht?). ....

Das ist meines Erachtens ein ganz, ganz schlimmer werbetechnischer Fehler!

Das schreckt doch neue Interessenten ab Delphi zu kaufen! Oder würdet ihr einen Toyota (PW) kaufen, wenn ihr wüsstet, dass da 3000 Fehler gegenüber des alten Toyotas behoben worden sind?
Mit Fehlerbehebung wirbt man nicht! Mit weniger Fehlern holt man keine Kunden!
Als neutraler Interessent, damit meine ich jetzt nicht uns alteingesessene Delphianer, ziehe ich doch Rückschlüsse: Die Entwickler von Delphi sind nicht in der Lage eine stabile Entwicklungsumgebung zu programmieren, also wende ich mich lieber Microsoft zu.

[Robotiker]

Zitat:

Zitat von Bernerbaer (Beitrag 1045698)

Mit weniger Fehlern holt man keine Kunden!

Ganz im Gegenteil. Quality Central und der offensive Umgang mit Fehlern ist ein wichtiger Schritt, um verlorengegangenes Vertrauen wieder herzustellen.

Alle Compiler, alle Bibliotheken haben Fehler, jeder der professionell damit umgeht weiß das.

Im Gegensatz zu Delphi, hat sein Schwesterprodukt ja auch ISO-Standards zu erfüllen, da gibt es auch externe Seiten, wo man nachsehen kann, wo jeder Compiler steht.

z.B.
http://wiki.apache.org/stdcxx/C++0xCompilerSupport
http://www.boost.org/development/tes...r/summary.html

[Bernerbaer]

Zitat:

Zitat von Robotiker (Beitrag 1045721)

Ganz im Gegenteil. Quality Central und der offensive Umgang mit Fehlern ist ein wichtiger Schritt, um verlorengegangenes Vertrauen wieder herzustellen.
...

Damit bin ich nicht ganz einverstanden:

Delphi lebt nur, wenn neue Anwender gefunden werden! Wenn es heisst, in der neuen Version wurden 4200 Fehler der vorherigen Version behoben, dann bedeutet dies für einen Interessenten an Delphi doch, aktuelle Versionen werden nicht gewartet! Klar enthält jede Software Fehler, doch ein potentieller Käufer erwartet, dass Fehler nicht erst in späteren Versionen behoben werden, sondern dann, wenn sie erkannt werden. Wenn ich also zu meinem nicht ganz stimmigen Beispiel aus einem vorherigen Posting zurückgehe, kann Toyota nur neue Autos verkaufen, wenn sie die Fehler in den alten Autos beheben.

Stell dir mal vor, Microsoft würde damit werben, dass Windows Seven mehr als 4200 weniger Fehler als Windows Vista aufweist. Microsoft wird sich hüten das zu tun! Oder Apple würde damit werben, dass im neuen Iphone 3000 weniger Fehler stecken als im alten Iphone. Undenkbar!

Nun zurück zum Ursprungsposting: Deine Aussage unterstützt doch meine Ausgangsthese: "Back to the roots!" Konzentrieren auf eine Entwicklungsumgebung, eine perfekte und spezialisierte Entwicklungsumgebung zur Verfügung stellen, die eine Sache optimal beherrscht: programme für Windows erstellen!

[Der.Kaktus]

"Cloud" Programme... da hat einer nen Begriff erfunden ..frueher hiess es Client Server..man o man..echt krass :roll:

[Robotiker]

Zitat:

Zitat von Bernerbaer (Beitrag 1045725)

Wenn es heisst, in der neuen Version wurden 4200 Fehler der vorherigen Version behoben, dann bedeutet dies für einen Interessenten an Delphi doch, aktuelle Versionen werden nicht gewartet!

Das es mit dem Erscheinen der nächsten Version keine Updates mehr für die vorherige gibt, ist eine Tatsache, die man potentiellen Kunden nicht verschweigen sollte.

Zitat:

Zitat von Bernerbaer (Beitrag 1045725)

Deine Aussage unterstützt doch meine Ausgangsthese: "Back to the roots!" Konzentrieren auf eine Entwicklungsumgebung, eine perfekte und spezialisierte Entwicklungsumgebung zur Verfügung stellen, die eine Sache optimal beherrscht: programme für Windows erstellen!

Auch nach zwei Fehlschlägen, ich habe Kylix 3 für C++ und den C++ Builder X in meiner Sammlung, steht für mich außer Zweifel, dass die Entwicklung bei den IDEs den Änderungen der Hardware folgen muss. Ohne die Möglichkeit sich neuen Plattformen anzupassen, würde Delphi irgendwann zu einer Art Lummerland für Programmierer, die nichts neues mehr lernen wollen.

[Florian Hämmerle]

Ich seh da keine großen Probleme, Crosscompiler zu machen. Aber es muss schnell gehen. ich denke, viele Linxu / Mac-Entwickler, die im Moment mit Lazarus anfangen, würden eine Delphi-IDE für Linux / Mac begrüßen. Die die schon länger mit Lazarus für diese Plattformen entwickeln, bringen auch das nötige know-how mit, um komponenten, etc. für diese plattformen zu erstellen und anderen (Anfängern) zur Verfügung zu stellen.
Bei den alteingesessenen Delphiprogrammierern wird die größte Hürde sein, sich die Arbeit anzutun, etwas neues zu lernen.

mfg Florian

[Bernerbaer]

Zitat:

Zitat von Robotiker (Beitrag 1045732)

Das es mit dem Erscheinen der nächsten Version keine Updates mehr für die vorherige gibt, ist eine Tatsache, die man potentiellen Kunden nicht verschweigen sollte.

Und damit, dass dies eine Tatsache ist, habe ich Probleme und dies schreckt wohl zukünftige Käufer ab. Ein potentieller Interessent denkt doch: Kaufe ich Microsoftprodukte, weiss ich, dass sie gewartet werden. Bei Delphi wird kaum gewartet, dann lass ich es lieber sein.

Zitat:

Zitat von Robotiker (Beitrag 1045732)

... Ohne die Möglichkeit sich neuen Plattformen anzupassen, würde Delphi irgendwann zu einer Art Lummerland für Programmierer, die nichts neues mehr lernen wollen.

Da bin ich wohl zu wenig klar gewesen: Nein Delphi soll nicht ein altbackenes Produkt aus dem letzten Jahrhundert bleiben! Es muss weiterentwickelt werden, Pascal muss und soll sich an die neuen Gegebenheiten anpassen.

Aber wenn ich Programme für PHP entwickeln will, dann nehme ich auch eine IDE die eben spezialisiert ist für PHP, die von Entwicklern hergestellt worden ist, die sich nur mit PHP auseinandersetzen. Wenn ich für das Iphone programmieren will (und meine APP's verkaufen will), dann nehme ich auch die Softwareumgebung die fürs IPhone speziell entwickelt worden ist.

[himitsu]

Zitat:

Zitat von Bernerbaer (Beitrag 1045736)

Aber wenn ich Programme für PHP entwickeln will, dann nehme ich auch eine IDE die eben spezialisiert ist für PHP,

Ich hab vor Kurzem mal Delphi for PHP 2.0 ausprobiert
und im Gegensatz zu anderen IDEs hat es dort endlich mal geklappt, daß ich PHP auch Debuggen kann.
Abgesehn von anderen IDEs, welche sowas (angeblich) auch bieten, hat es hier sofort geklappt ... abgesehn von dem kleinen Problemchen, wo mir z.B. schwerwigende PHP-Parsingfehler nicht angezeigt werden, aber bei den anderen IDEs hat da überhaupt nichts geklappt.

Also selbst ohne die "eigenartige" VCL, welche man aber nicht nutzen muß, ist das eigentlich ein gutes Ergebnis für Delphi.

[Bernerbaer]

Zitat:

Zitat von himitsu (Beitrag 1045737)

Ich hab vor Kurzem mal Delphi for PHP 2.0 ausprobiert
und im Gegensatz zu anderen IDEs hat es dort endlich mal geklappt, daß ich PHP auch Debuggen kann.
Abgesehn von anderen IDEs, welche sowas (angeblich) auch bieten, hat es hier sofort geklappt ... abgesehn von dem kleinen Problemchen, wo mir z.B. schwerwigende PHP-Parsingfehler nicht angezeigt werden, aber bei den anderen IDEs hat da überhaupt nichts geklappt.

Also selbst ohne die "eigenartige" VCL, welche man aber nicht nutzen muß, ist das eigentlich ein gutes Ergebnis für Delphi.

Super, das freut mich. Ich bin ja nicht grundsätzlich gegen die Integration neuer Plattformen und Sprachen, aber ich stelle einfach ein Grundprizip der Wirtschaft zur Diskussion: Ressourcen sind beschränkt und müssen deshalb optimal eingesetzt werden.

D.h. Embarcadero hat beschränkte Ressourcen, wo liegt der optimale Einsatz dieser Resourcen? In der Erschliessung neuer Plattformen oder der Konzentration auf die Ursprungsplattform und die einmalige, geniale Sprache Delphi weiterzuentwickeln?

[Robotiker]

Zitat:

Zitat von Bernerbaer (Beitrag 1045736)

Aber wenn ich Programme für PHP entwickeln will, dann nehme ich auch eine IDE die eben spezialisiert ist für PHP, die von Entwicklern hergestellt worden ist, die sich nur mit PHP auseinandersetzen. Wenn ich für das Iphone programmieren will (und meine APP's verkaufen will), dann nehme ich auch die Softwareumgebung die fürs IPhone speziell entwickelt worden ist.

Mit der abnehmenden Bedeutung klassischer PCs wird der Markt für reine Windows IDEs immer kleiner werden. Keine gute Perspektive für ein Geschäftsmodell, das muss man auch mal sehen. Man ist also gezwungen neue Märkte zu erschliessen.

Aber wer soll diese Cross Platform Produkte kaufen ?

Die meisten C++ler, wie ich, arbeiten mit verschiedenen IDEs (VS, QtCreator, Eclipse CDT, ...). Denen wird man einiges bieten müssen, damit die kaufen.

Bei den Pascal-Programmierern sind wahrscheinlich die für neue Platformen aufgeschlossenen schon mit FP / Lazarus unterwegs. Beim Rest habe ich da gewisse Zweifel ...

Und neue Kunden ?

Manches erinnert an die Zeiten, die C++ Builder Anwender vor ein paar Jahren durchgemacht haben:
http://www.drbob42.com/paul/index.htm

[himitsu]

Gut, Delphi for PHP ist eine andere Sache, vorallem da dort die Delphi-Syntax leider keine Verwendung findet.
Ein Delphi-to-PHP-Converter als "Compiler" getarnt wäre schon witzig.


Aber was das Crossplatform betrifft, da man den Delphi-Compiler und -Debugger sowieso für das Win64 zu großen Teilen überarbeiten sollte/müßte,
ist es dann auch gleich eine gute Chance hier eine Schnittstelle zu schaffen, welche mehrere Compiler/Debugger versteht, bzw. nutzen kann, womit dann auch der Weg für Linux, Mac und Co. geschaffen wäre.

[Florian Hämmerle]

Zitat:

Zitat von himitsu (Beitrag 1045747)

Gut, Delphi for PHP ist eine andere Sache, vorallem da dort die Delphi-Syntax leider keine Verwendung findet.
Ein Delphi-to-PHP-Converter als "Compiler" getarnt wäre schon witzig.

Hab ich mal versucht. Ist gar nicht so leicht. Einfache Skripte hab ich hinbekommen. Aber OOP ist echt nicht leicht. Wollte aber eh mal an dem Projekt weitermachen. Vielleicht wirds ja in nächster Zeit mal wieder soweit, dass ich etwas Zeit finde :)

mfg Florian

[Bernhard Geyer]

Zitat:

Zitat von Bernerbaer (Beitrag 1045743)

..., aber ich stelle einfach ein Grundprizip der Wirtschaft zur Diskussion: Ressourcen sind beschränkt und müssen deshalb optimal eingesetzt werden.

D.h. Embarcadero hat beschränkte Ressourcen, wo liegt der optimale Einsatz dieser Resourcen? In der Erschliessung neuer Plattformen oder der Konzentration auf die Ursprungsplattform und die einmalige, geniale Sprache Delphi weiterzuentwickeln?

Eigentlich muss Codegear beides machen. Wie heist es so schön: "Stärken stärken, Schwächen schwächen".
Als "IDE-Divison" muss man sowohl bestehende Stärken weiterentwicklen (was leiter einige Jahre praktisch nicht der Fall bzw. nach einiger Zeit die Ergebnisse in die Tonne getreten werden mussten (CLX/Kylix/VCL.NET). Aber man kann als "IDE-Divion" sich nicht nur auf den Markt schwindenten Markt der x86-Entwicklung verlassen. Leiter hat man ehemalige gute Plattformneutrale IDE/Entwicklung (JBuilder - Ist glaube ich tod, bzw. am Markt irrelevant geworden) auch Aufgrund von Managerfehlentscheiungen gegen die Wand gefahren.
Also im Bereich Mobile (IPhone, Android, ...) ist Codgear so ziemlich blank (Prism ist ja auch nur ein Lizenzprodukt).

[Florian Hämmerle]

IIRC: Was doch mal interessant wäre, ist doch ein iPhone-Compiler für Windows. Wer für iPhone entwickeln muss, braucht nen Mac...

[Bernhard Geyer]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1045752)

IIRC: Was doch mal interessant wäre, ist doch ein iPhone-Compiler für Windows. Wer für iPhone entwickeln muss, braucht nen Mac...

Delphi.Prism soll sowas bieten. Wobei mir nicht klar ist ob das nach Apple-Monopolpolitik noch erlaubt ist. Aber dieses Problem würde jeder Compiler haben der nicht C/C++/Objective C verwendet und wenn du nicht auf den Apple-Erlaubten Bibliotheken aufsetzt.

[Florian Hämmerle]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1045753)

Zitat:

Zitat von Florian Hämmerle (Beitrag 1045752)

IIRC: Was doch mal interessant wäre, ist doch ein iPhone-Compiler für Windows. Wer für iPhone entwickeln muss, braucht nen Mac...

Delphi.Prism soll sowas bieten. Wobei mir nicht klar ist ob das nach Apple-Monopolpolitik noch erlaubt ist. Aber dieses Problem würde jeder Compiler haben der nicht C/C++/Objective C verwendet und wenn du nicht auf den Apple-Erlaubten Bibliotheken aufsetzt.

Jetzt hast du mich gerade wieder daran erinnert, weshalb ich Apple nicht mag ;)

mfg Florian

[mjustin]

Zitat:

Zitat von Bernerbaer (Beitrag 1045610)

Cloud Computing:
Ich kann mir (mindestens für Europa) kaum vorstellen, das Kunden Interesse an Applikation haben, die ihre Daten in einer grauen Wolke abspeichern.

Wenn das so ist, dann werden bald einige Unternehmen wohl Konkurs anmelden: in der aktuellen iX werden allein schon 12 deutsche Anbieter von Online-Backup Lösungen detailliert vorgestellt und verglichen.

Der Artikel warnt zwar auch "Nutzer sollten Anbieter meiden, die nicht alle ihre Fragen auf zufriedenstellende Weise beantworten", aber insgesamt gesehen ist es für viele wohl wirtschaftlicher und effizienter (und für manche Unternehmen sogar sicherer) als im eigenen Haus zu sichern.

Und wenn die Daten schon im Internet liegen, was spricht dagegen, auch die Anwendungen dort laufen zu lassen? Das hat auch einen weiteren Nebeneffekt: Angreifer kommen wohl eher nicht so leicht in Prozesse, die in einem Rechenzentrum laufen, als in das 'durchschnittlich' geschützte System des Endanwenders.

[mjustin]

Zitat:

Zitat von Robotiker (Beitrag 1045744)

Mit der abnehmenden Bedeutung klassischer PCs wird der Markt für reine Windows IDEs immer kleiner werden. Keine gute Perspektive für ein Geschäftsmodell, das muss man auch mal sehen. Man ist also gezwungen neue Märkte zu erschliessen.

Aber wer soll diese Cross Platform Produkte kaufen ?

Für Unternehmenssoftware sehe ich da grosse Chancen - größere als für den Desktop / 'nativen' GUI Markt, wegen der enormen Herausforderung durch die unterschiedlichen Oberflächenkonzepte und die Vielfalt der Distributionen.

Anwendungen, die z.B. Web Server, Web Services, und ähnliche 'Hintergrundprogramme' bilden, lassen sich mit einer Cross-Platform fähigen Delphi Version für Besitzer anderer Plattformen vermarkten: Unternehmen, die lieber einen High End Mac Server oder eine Linux Serverfarm einsetzen (z.B. aus Lizenzkostengründen), werden eine Windows-Only Software nicht weiter in die engere Auswahl nehmen.

Wenn man im Datenblatt schreiben kann 'Unser neuer Webapplikationsserver X+E 2011 wurde unter Windows, MacOS, Linux und OpenSolaris getestet' macht das einen anderen Eindruck als 'Setzt Windows (32 Bit) voraus'.

Auch für Cloudanwendungen ist es interessant, andere Betriebssysteme zu unterstützen. So ist zum Beispiel Amazons 'Elastic Compute Cloud' (EC2) deutlich preiswerter wenn man die Instanzen unter Linux laufen lässt, als unter Windows.

[Bernerbaer]

Zitat:

Zitat von mjustin (Beitrag 1045788)

Für Unternehmenssoftware sehe ich da grosse Chancen - größere als für den Desktop / 'nativen' GUI Markt, wegen der enormen Herausforderung durch die unterschiedlichen Oberflächenkonzepte und die Vielfalt der Distributionen.

Ein interessanter Artikel dazu, der die Situation in D behandelt findet ihr hier: Perspektive Mittelstand

[Teekeks]

@Bernerbaer: Du hast eine PN...

[webcss]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1045755)

Jetzt hast du mich gerade wieder daran erinnert, weshalb ich Apple nicht mag ;)

mfg Florian

Naja, dafür gibt's ja Pascal compiler für den mac (GNU-Pascal mit XCode-Plugin, FPC mit Pascal Gladiator pascal gladiator
), allerdings ohne visual GUI design.

[Phoenix]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1045753)

Zitat:

Zitat von Florian Hämmerle (Beitrag 1045752)

IIRC: Was doch mal interessant wäre, ist doch ein iPhone-Compiler für Windows. Wer für iPhone entwickeln muss, braucht nen Mac...

Delphi.Prism soll sowas bieten. Wobei mir nicht klar ist ob das nach Apple-Monopolpolitik noch erlaubt ist. Aber dieses Problem würde jeder Compiler haben der nicht C/C++/Objective C verwendet und wenn du nicht auf den Apple-Erlaubten Bibliotheken aufsetzt.

Auch mit Prism brauchst Du einen Mac um fürs iOs zu entwickeln. Du musst ja schließlich (konkreter: MonoTouch muss) gegen die iOS Librarys linken lassen und die gibt's nur im Apple SDK.

Und Apple hat bisher noch keine MonoTouch oder Unity-Anwendung nicht zugelassen. Die sehen das wohl relativ locker, solange kein Flash ankommt.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix (Beitrag 1045848)

Und Apple hat bisher noch keine MonoTouch oder Unity-Anwendung nicht zugelassen. Die sehen das wohl relativ locker, solange kein Flash ankommt.

D.h. man ist auf Gedeih und Verderb auf Apples "übersehen" angewiesen. Ist die Marktmacht von Apple groß genug so fliegt dein Programm von Heute auf Morgen aus dem Shop u.U. fordert Apple alle gezahlten Lizenzzahlungen zurück.

[cookie22]

Zitat:

...u.U. fordert Apple alle gezahlten Lizenzzahlungen zurück...

das können die? immerhin haben sie es ja selbst in den shop gelassen.

[Bernhard Geyer]

Zitat:

Zitat von cookie22 (Beitrag 1045975)

Zitat:

...u.U. fordert Apple alle gezahlten Lizenzzahlungen zurück...

das können die? immerhin haben sie es ja selbst in den shop gelassen.

Ich kenn die AGB's jetzt nicht für jede Zeile. Aber wenn sie behaupten erst jetzt von der Lizenzverletzung bemerkt zu haben und diese Rückzahlung in den Entwickler-AGB's drin seht - wieso nicht?

[himitsu]

Da in den AGB drinsteht daß man das nicht darf, müssen sie doch sowas auch nicht sofort prüfen, wenn eine Software in den Shop aufgenommen werden soll ... schließlich darf man ja nur solche Software dort aufnehmen lassen, welche erlaubt ist.

[generic]

Zitat:

Zitat von Bernerbaer (Beitrag 1045637)

kauft ihr XE oder ein Nachfolgeprodukt weil es
- einen 32Bit und einen 64 Bit Compiler aufweist?

Auf jeden Fall, da meine Anwendungen immer weniger bei meinen Kunden laufen. Viele rüsten jetzt auf 64Bit OSe auf. XP wird großflächig ersetzt. Ergebnis meine Shellextensions funktionieren nicht mehr.

Ich denke es sollte mehr in die Unterstützung von den neuen Betriebssystemen gemacht werden. Auf eine Unterstützung von pre XP OSen kann ich verzichten.