Ist es mit delphi aus?

[Elvis]

Zitat von Hisoka:

Das Aber auch nur im Bereich von Mono. Sonst gibt es genug andere RAD IDEs.
z.B. Netbeans(Matisse),Code::Blocks(C++ & wxGTK),KdevelopDesigner,...
Diese sind auch nicht unbedingt umständlicher zu bedienen und teilweise sogar einfacher.

IMO ist keiner davon wirklich einfacher, aber Matisse ist schon ziemlich cool und da die neuere Swing-Version nicht mehr so verflucht hässlich und lahm ist, wäre das auch der einzige 2. Rang im Sinne von RAD IDE + moderne Bibliotheken.
KDevelop fliegt raus, da es nur der QT Designer ist, und QT macht nur für KDE Sinn, welches ich rein dumm-ideologisch einfach nicht mag.
Ich würde einen wirklichen wx Designer lieben, den mit wx.Net + einem brauchbaren wx Designer würde man schnieke XPlattform GUIs bauen können. (wx benutzt Cocoa unter OS X, QT-Apps fühlen sich unter OS X falsch an)
Dummerweise gibt es keinen vernünftigen ws-Designer...
Also in dem Vergleich machen IMO nur Netbeans und MonoDevelop Sinn. Netbeans hat den Vorteil, dass die Apps auch auf anderen Plattformen laufen. Auch wenn man sich an die letzte JVM-Version von Apple halten muss um OS X-kompatibel zu bleiben, dafür sorgt die Apple-JVM für ein natives Look & Feel und Rendering-Performance.

[Hisoka]

Also der in Code::Blocks integrierte Designer ist eigentlich nicht schlecht. Der Designer nennt sich wxSmith.(Ich empfehle für die Nutzung von Codeblocks die svn Version, die stabile Version ist unbrauchbar)

Die RAD IDE für RealBasic(Plattform unabhängige Basic Variante) ist auch sehr gut. Die kann es ohne Probleme mit Delphi aufnehmen.

[hanspeter]

Tip zum Lesen
Computerwoche

Gruß Peter

[bernau]

Zitat von hanspeter:

Tip zum Lesen
Computerwoche
Gruß Peter

Totgesagte leben länger.

Erst mal ist die Frage, aus welchem Bereich die Leute entlassen werden. Es steht auf jeden Fall nichts davon drin, daß bei CodeGear entlassen wird.

Und zum Satz "Schwierigkeiten gibt es besonders in der neu geformten CodeGear-Division für Entwicklungswerkzeuge, die im dritten Kalenderquartal 2007 nur auf einen Umsatz von 12,5 Millionen Dollar kam." kann ich nur sagen, daß mit diesen 12.5 Millionen Dollar Umsatz die entsprechenden Gewinne eingespielt wurden. Die einzige Sparte bei Borland, die Gewinne gemacht hatte. So war's zumindest zu lesen und Stand bei den DSDT-News.


Gerd

[mkinzler]

Aber Borland erwartet wohl, dass ihre Cashcow weiter schwächelt und bereiten die Schlachtung vor.

[hanspeter]

Zitat von bernau:

Und zum Satz "Schwierigkeiten gibt es besonders in der neu geformten CodeGear-Division für Entwicklungswerkzeuge, die im dritten Kalenderquartal 2007 nur auf einen Umsatz von 12,5 Millionen Dollar kam." kann ich nur sagen, daß mit diesen 12.5 Millionen Dollar Umsatz die entsprechenden Gewinne eingespielt wurden. Die einzige Sparte bei Borland, die Gewinne gemacht hatte. So war's zumindest zu lesen und Stand bei den DSDT-News.
Gerd

In dem Quartal erschienen die neuen Delphiversionen und Delphi für PHP. Das sollte also schon eine Spitze sein.

Peter

[Bernhard Geyer]

Zitat von hanspeter:

In dem Quartal erschienen die neuen Delphiversionen und Delphi für PHP. Das sollte also schon eine Spitze sein.

Kann nicht sein. Das erste Update von Delphi 2007 habe ich am 11.06 heruntergeladen. AFAIK ist entweder C++-Builder oder das komplette RAD herausgekommen.
Und ob Delphi for PHP viel ausmacht ...

[cware]

nach dem ganzen hin- und her und einmischen von Lazarus-Fetischisten will ich jetzt auch mal meinen Senf dazu geben...

ich denke persönlich nicht, dass es mit Delphi aus ist... dafür war das Produkt (bis D7) einfach zu gut...
selbst heute findet man noch Leute, die mit D5, D6 oder D7 arbeiten, weil sie damit vollkommen zufrieden sind...
so, wie es zur zeit aussieht, ist .NET heutzutage noch nicht das Maß aller Dinge - kaum irgendeine produktive Software benutzt heutzutage schon .NET - Systemsoftware ist damit tlw. garnicht umsetzbar, da .NET in meinem Verständnis vor allem für Standard-Software konzipiert ist...

bisher sehe ich .NET lediglich als Framework - ein Konstrukt, auf das man zurückgreifen kann, wenn man vereinfacht Software schreiben will - vereinfacht heißt hier: viel Standard-Zeugs frei-haus geliefert bekommen möchte...
Ich sage nicht, dass .NET-Programmierung wirklich einfacher ist - ich denke da z.B. an Compare-Klassen (ich frag' mich, welcher depp bei m$ der meinung war, den sch*** von Java klauen zu müssen - so, wie alles andere)...
Ebenso, wie man ohne VCL programmieren kann (nonVCL war mal ein Thema), kann man auch heute noch problemlos ohne .NET programmieren...

kommen wir zu den Delphi-Alternativen:
1.) Java
sorry junx, aber Java ist keine Alternative...
Java ist vielleicht plattform-unabbhängig, aber das erkauft man sich dadurch, dass man sogut wie keinen Systemzugriff hat - alles, was mit dem System interagiert muss nämlich von Sun in die Virtual Machine reinprogrammiert werden...
deswegen sieht es in solchen Bereichen ziemlich mau aus...
Kleines Beispiel: ich habe letztens versucht, eine wirklich kleine hierarchische DB-Engine von Delphi nach Java zu portieren...
nach ein paar Wochen hatte ich keine Lust mehr, weil ich wirklich jeden Speicherkram per Hand erledigen musste (irgendwie musste der Speicher ja als verschiedene Typen interpretiert werden) - bei Delphi waren das ein paar Zeilen, bei Java eine echte Herausforderung...

2.) Lazarus
ich weiß nicht, wie im letzten Jahr die Entwicklung in dem Gebiet fortgeschritten ist, aber als ich Anfang '07 ein Programm, dass Message Handler benötigt hatte, von Delphi nach Lazarus portieren wollte, bin ich frontal gegen eine Wand gerannt...
es ließ sich wunderbar kompilieren - funktionierte aber nicht... fragt mich nicht warum, die Messages wurden einfach nicht behandelt...
zurück unter Delphi funktionierte alles wieder problemlos...
zudem ist das ganze doch noch seeehr user-unfreundlich... die kompilier-zeiten sind der horror, selbst, wenn nichts (!) geändert wurde und man das programm nochmal startet, wird erneut kompiliert... die damals verfügbare komponenten-palette war lachhaft klein und die Strukturierung des FPC-eigenen Quelltextes einfach nur katastrophal...
Wie kann man heutzutage großteile des Quelltextes bitte in *.INC-dateien auslagern? absolut gruselig...
als ob wir in den 80ern wären und das maximum der unit-größe erreicht hätten...

3.) (C#/VB.NET/....NET)
irgendwo auf den vorhergehenden seiten meinte jemand, dass der visuelle designer von Delphi um längen besser als MFC wäre und nichts besseres kennen würde (aber sich VS.net noch nicht angeguckt hat)... jemand anderes meinte darauf, dass er das mal tun sollte...
die frage ist: wozu? der visual designer von VS.net reicht bei weitem nicht an den von Delphi heran...
natürlich ist die einfachste möglichkeit, auf M$-sprachen überzugehen - und sich dann darüber zu freuen, dass m$ tatsächlich versucht hat, ihren neuen dialekt an einen an c++ angelehnten dialekt anlehnen zu lassen... zu kompliziert? bei c# wurde mehr von java geklaut als irgendwas anderes...
der große vorteil der m$-sprachen ist natürlich, dass sie state-of-the-art sind... die unterstützen die neuste framework-version und sie sehen anderen sprachen zum verwechseln ähnlich... man kann sofort anfangen...
nunja... das problem wird nur, das ganze wieder nach delphi zu portieren, wenn folgendes passiert... (see below)
(btw.: ich hoffe, jeder weiß, dass man .NET-assemblies problemlos nach c#/vb.net deassemblieren kann)

wie man schon mehrfach in der geschichte gesehen hat, ist Delphi nicht totzukriegen...
Borland hat schon einmal den Fehler gemacht, sich von Delphi zu entfernen und hat sich (damals unter dem namen Inprise) vor allem um Middleware-Lösungen etc. gekümmert... auch damals sind die einnahmen stark zurück gegangen...
zumindest, bis sich Borland dann wieder auf Delphi konzentriert hatte, was dem produkt dann sehr zuträglich war...

anscheinend ist Borland, nachdem sie sich die letzten jahre vor allem auf software-life-cycling konzentriert haben, klar geworden, dass es so mit Delphi nicht mehr weitergehen kann... nachdem keiner Delphi kaufen wollte und das ganze jetzt in CodeGear aufgegangen ist, ist es durchaus möglich, dass wieder vermehrt an der Qualität und am Umfang von Delphi gearbeitet wird...
Delphi 2007 (Win32) war ein schritt in die richtige richtung... es ist durchaus möglich, dass eine .NET-variante aus einem guten Grund zurückgehalten wurde... vielleicht ist dem Entwicklerteam selber klar geworden, dass der .NET-support in Delphi, so, wie er in BDS'06 war, weder akzeptabel, noch produktiv einsetzbar war...

ich denke, wir werden noch einiges von Delphi hören... vielleicht ist es irgendwann möglich, dass Delphi.NET im .NET-umfeld das wird, was Delphi im Win32-umfeld seit jeher war - eine zuverlässige, schnelle IDE, die den entwickler dabei unterstützt, schnell die gestellten anforderungen zu erfüllen...


cheers...

[mkinzler]

Zitat:

Delphi 2007 (Win32) war ein schritt in die richtige richtung...

Eigentlich ja schon D2006

Zitat:

es ist durchaus möglich, dass eine .NET-variante aus einem guten Grund zurückgehalten wurde...

Was wurde zurückgehalten?

Zitat:

vielleicht ist dem Entwicklerteam selber klar geworden, dass der .NET-support in Delphi, so, wie er in BDS'06 war, weder akzeptabel, noch produktiv einsetzbar war...

Und haben ihn deshalb in der neuen Version noch weiter zurückgeschraubt?

[Bernhard Geyer]

Zitat von cware:

nsorry junx, aber Java ist keine Alternative...
Java ist vielleicht plattform-unabbhängig, aber das erkauft man sich dadurch, dass man sogut wie keinen Systemzugriff hat - alles, was mit dem System interagiert muss nämlich von Sun in die Virtual Machine reinprogrammiert werden...

Mittels JNI ist doch das "kein" Problem. Machen den umgekehrten Weg: Verwenden diverse (teilweise Apache-Projekte) in unserer Win32-Anwendung, liefern die JRE als Verzeichnis mit und haben immer noch eine XCopy-Installation

Zitat von cware:

es ist durchaus möglich, dass eine .NET-variante aus einem guten Grund zurückgehalten wurde... vielleicht ist dem Entwicklerteam selber klar geworden,

Primär hat man es endlich geschafft alle Win32-IDE's auf einer Codebasis zu bringen und nicht wie zu alten Delphi/C++-Builder immer unteschiedliche VCL-Versionen hatte. Und damit man nicht alles fertig haben musste released man die IDE-Personalities nach und nach so das die letzte (C++-Builder) schon viele Fixes erhalten hat.