Wie viel "R" steckt noch in RAD Studio XE5?

[Mavarik]

Hallo Zusammen...

Zu meiner Wochenend Gaming-Rechner Konfiguration.

AMD 64 Dual Core 4200+ 2.20 Ghz / 4GB RAM / Win 7/64 (Index 4,5)
Festplatte 5,7 / Grafik 5,9...

Start XE5 34 sec... OK

Dann ein David I Welcome-Button := '42!' Testprogramm für den vorinstallieren Android Emulator.

Compile Zeit 20sec!
Install Zeit bei 37sec!
Start Zeit bei 1:37 Min!
Module werden geladen bei 1:50 Min.

Nach 5Min habe ich angefangen diese Nachricht zu tippen...

Seit meinen <F9> sind jetzt 12:44 Min vergangen. Das Modul-geladen Fenster ist weg und ich warte auf den Emulator. So lange hat die Festplatte wie wild rumgerödelt... Keine Ahnung was da alles passiert ist...

16 Min... Ich fahre jetzt mal einkaufen vielleicht ist der Emulator ja da, wenn ich in einer Stunde wieder da bin...

Das nenne ich nicht wirklich "Rapid"

Grüsse Mavarik

PS.: Da waren die 899,- EUR für Update & Maintanance inkl. Mobile Erweiterung doch gut angelegt. Ich kann nur hoffen das ist nicht normal, sonder das bei mir etwas etwas falsch installiert ist... (18 Min)

[Der schöne Günther]

Keine SSD? Ich sehe es nur auf meiner privaten (ziemlich alten) Kiste mit klassischer Festplatte, da dauert alles wirklich eine Weile. Uffe Schicht mit einer SSD ist das RAD Studio in weniger als vier, fünf Sekunden einsatzbereit.

Wenn ich das richtig verstehe, war das jetzt der erste Startvorgang, oder? Beim ersten mal sicher etwas holprig. Ich bin gespannt auf den zweiten Startvorgang :wink:

[vagtler]

Zitat:

Zitat von Mavarik (Beitrag 1228457)

[...] Ich kann nur hoffen das ist nicht normal, sonder das bei mir etwas etwas falsch installiert ist... (18 Min)

Ich befürchte, es wird bei der Hoffnung bleiben.

Unter einem potenten i7 mit 16GB RAM sowie ein oder besser zwei schnellen SSDs (herkömmliche HDs gehen gar nicht) braucht man sich mit der Thematik gar nicht näher zu beschäftigen, wenn man denn produktiv sein möchte.

Ich bin mir nur nicht sicher, ob das unter Dein Verständnis von "falsch installiert" fällt... :stupid:

[Union]

Das kannst Du aber nicht dem RAD-Studio anlasten sondern dem Emulator. Schließe ein echtes Gerät an und alles wird gut. Obwohl ich auch im Emulator arbeite und es noch erträglich finde. Bei mir sieht es so aus:

Intel I7-3770 3.5 Ghz
16 GB
Windows 8 64 bit Index 5.9 (Liegt aber an der lahmen HD)

Startzeit IDE: 53 s (1 Aufruf) 11 s (nach Beenden und erneutem Aufruf)
Startzeit Emulator-Device (bis zur Anzeige Sperrbildschirm Android): 75 s

1. Compilezeit HelloWorld: 1 s
2. Linkzeit: 1 s
3. Deployment: 90 s
4. Startzeit (bis Bildschirmaufbau): 40 s

Auf einem echten Device werden 3 und 4 schneller.

Es hilft im Übrigen die Release-Notes und den Android Teil in der Wiki auch mal zu lesen. Stichwort "Emulation Options"->"Use Host GPU".

[Daniel]

Mache doch mal die Gegenprobe. Schnappe Dir Eclipse, erstelle eine Trivial-App und starte diese im Emulator. Danach kannst Du mit Bestimmtheit sagen, wo die Zeit flöten geht.

[Union]

Zitat:

Zitat von Daniel (Beitrag 1228465)

Mache doch mal die Gegenprobe. Schnappe Dir Eclipse, erstelle eine Trivial-App und starte diese im Emulator. Danach kannst Du mit Bestimmtheit sagen, wo die Zeit flöten geht.

Offensichtlich liegt es am Deployment (Größe 250kb <> 20MB) und an der Geschwindigkeit der Delphi-App:

Code:

[2013-09-14 15:14:37 - HelloWorld] Android Launch!
[2013-09-14 15:14:37 - HelloWorld] adb is running normally.
[2013-09-14 15:14:37 - HelloWorld] Performing lu.softwareunion.helloworld.HelloActivity activity launch
[2013-09-14 15:14:37 - HelloWorld] Automatic Target Mode: Preferred AVD 'Host_Nexus_4_1' is available on emulator 'emulator-5554'
[2013-09-14 15:14:37 - HelloWorld] Uploading HelloWorld.apk onto device 'emulator-5554'
[2013-09-14 15:14:41 - HelloWorld] Installing HelloWorld.apk...
[2013-09-14 15:14:45 - HelloWorld] Success!
[2013-09-14 15:14:45 - HelloWorld] Starting activity lu.softwareunion.helloworld.HelloActivity on device emulator-5554
[2013-09-14 15:14:46 - HelloWorld] ActivityManager: Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=lu.softwareunion.helloworld/.HelloActivity }
[2013-09-14 15:14:47 - HelloWorld] Attempting to connect debugger to 'lu.softwareunion.helloworld' on port 8620

[Daniel]

Ja, das war ein Bereich, wo eine Verzögerung zu erwarten war. Streng genommen wollte ich mit meinem Beitrag auch Maverik fragen, denn eine Viertelstunde Differenz scheint mir doch stark auf ein Konfigurations-Problem hinzudeuten.

[arnof]

Also ich mache es in der gleichen VM wie XE4 für iOS, das Deloy auf dem Gerät ist ungefähr gleich schnell. Für Android habe ich den Emulator gleich weggelassen, da dieser recht lam ist und erst Bootet wie ein normales Gerät ....

[Union]

Zitat:

Zitat von Daniel (Beitrag 1228485)

Ja, das war ein Bereich, wo eine Verzögerung zu erwarten war. Streng genommen wollte ich mit meinem Beitrag auch Maverik fragen, denn eine Viertelstunde Differenz scheint mir doch stark auf ein Konfigurations-Problem hinzudeuten.

Ich bin mir sicher dass er die Grafik-Option im AVD niht angekreuzt hat. Dann allerdings sollte der Emulator auch die Inaktivität der App erkennen und einem Cancel/Wait offerieren, und/oder die Delphi IDE erfeut einen mit SIGINT(11) Messages.

Letztendlich liegt die Monstergröße an Firemonkey. Aber anstatt die lib aufzusplitten wird alles in eine .so gelinkt. Warum wird keine firemonkey.so deployed, die sich nie ändert und die App-Spezifischen Dinge in einer separaten lib<ProjektName>.so, die dann wahrscheinlich klein ist? So könnte das Deploy diese Basis-Lib nur dann neu installieren wenn sie sich ändert.

[Namenloser]

Der Android-Emulator ist sehr träge. Ich weiß nicht, ob Delphi-Apps vielleicht noch zusätzlichen Overhead gegenüber z.B. mit Java geschriebenen Apps haben und es deshalb noch langsamer ist oder ob bei dir ein anderes Problem vorliegt, aber auch bei mir mit Java hat das Neustarten einer praktisch leeren App aus der Erinnerung geschätzt/gefühlt (ich habe den nicht lange verwendet) mal gut eine halbe Minute gebraucht. Aber nur zur Sicherheit, um es noch mal klarzustellen, komm bloß nicht auf die Idee, den Emulator nach einer Debug-Session zu schließen! Das Hochfahren dauert nämlich noch viel länger.

Auf jeden Fall möchte man mit dem Emulator nicht dauerhaft arbeiten, würde ich behaupten. Also wenn du schon 900€ für die Mobile-Erweiterung ausgegeben hast, dann wären vielleicht 100€ für ein Billig-Droid eine gute Investition – wenn du ernsthaft Apps entwickeln willst.

Wobei ich mich meine zu erinnern, vor einigen Monaten gelesen zu haben, dass Intel einen schnelleren Emulator basierend auf Intels x86-Port von Android entwickelt haben will. Weiß nicht, was da der aktuelle Stand ist...

[Jonas Shinaniganz]

Zitat:

dann wären vielleicht 100€ für ein Billig-Droid eine gute Investition – wenn du ernsthaft Apps entwickeln willst.

Das sagen auch die Leute von Embarcadero und es ist völlig richtig. Du entwickelst ja auch nicht für Windows und emulierst dann ein Windows um die App zu testen... Der Emulator hat eigentlich keine Berechtigung.

[Union]

Zitat:

Zitat von NamenLozer (Beitrag 1228489)

Wobei ich mich meine zu erinnern, vor einigen Monaten gelesen zu haben, dass Intel einen schnelleren Emulator basierend auf Intels x86-Port von Android entwickelt haben will. Weiß nicht, was da der aktuelle Stand ist...

Der HAXM ist für X86. Delphi erzeugt aber ARM32 Code.

Zitat:

Zitat von Jonas Shinaniganz (Beitrag 1228491)

Zitat:

dann wären vielleicht 100€ für ein Billig-Droid eine gute Investition – wenn du ernsthaft Apps entwickeln willst.

Das sagen auch die Leute von Embarcadero und es ist völlig richtig. Du entwickelst ja auch nicht für Windows und emulierst dann ein Windows um die App zu testen... Der Emulator hat eigentlich keine Berechtigung.

Aber vorher sicherstellen, dass so ein Gerät dann auch kompatibel ist, sowohl von der Android-Version als auch vom Prozesser. Es muss ein ARM32 Neon sein, Tegra2 geht nicht.

Wer früher über Microsoft und Apple geschimpft hat, kannte Android noch nicht.

[arnof]

Zitat:

Tegra2 geht nicht

warum soll der nicht gehen ? Der ist ARM basierend :wink:

[Union]

Ist eben so definiert

[mjustin]

Zitat:

Zitat von Union (Beitrag 1228493)

Aber vorher sicherstellen, dass so ein Gerät dann auch kompatibel ist, sowohl von der Android-Version als auch vom Prozesser. Es muss ein ARM32 Neon sein, Tegra2 geht nicht.

Wer früher über Microsoft und Apple geschimpft hat, kannte Android noch nicht.

Niemand schimpft ernsthaft darüber, dass Android auf verschiedenen Prozessorarchitekturen läuft ... :gruebel:

[Namenloser]

Zitat:

Zitat von Union (Beitrag 1228493)

Zitat:

Zitat von NamenLozer (Beitrag 1228489)

Wobei ich mich meine zu erinnern, vor einigen Monaten gelesen zu haben, dass Intel einen schnelleren Emulator basierend auf Intels x86-Port von Android entwickelt haben will. Weiß nicht, was da der aktuelle Stand ist...

Der HAXM ist für X86. Delphi erzeugt aber ARM32 Code.

Ich dachte der erzeugt Java-Bytecode?

[ConstantGardener]

...das verwechselst Du mit Oxygene.

Delphi erzeugt "true nativ" Maschinencode für ARM7 mit NEON.

[Union]

dccaarm.exe erzeugt .so und die ist gegen das NDK gelinkt. Im apk ist eine Art Java Loader enthalten, der die MainActivity startet.

Zur Deploy-Geschwindigkeit: Die Transferrate die adb push ausgibt sind 135 kb/s beim Emulator. Da die .so mit FMX immer >= 15 MB sind (Plus APK >= 5 MB) kann man sich einfach ausrechnen.

Tip: Während des Transfers auf dem Emulator rumklicken vervierfacht die Transfergeschwindigkeit. Soviel dazu.

[Namenloser]

Zitat:

Zitat von ConstantGardener (Beitrag 1228498)

...das verwechselst Du mit Oxygene.

Delphi erzeugt "true nativ" Maschinencode für ARM7 mit NEON.

Ah ok, war mir neu. Ich habe mich nicht genauer damit beschäftigt, da ich es sowieso nie einsetzen werde. Ich ging einfach davon aus, dass Java-Bytecode erzeugt würde (glaube freepascal macht es auch so), zumal es von Google ja offiziell „discouraged“ ist, das NDK zu verwenden, wenn es nicht unbedingt nötig ist.

[zeras]

Zitat:

Zitat von mjustin (Beitrag 1228496)

Niemand schimpft ernsthaft darüber, dass Android auf verschiedenen Prozessorarchitekturen läuft ... :gruebel:

Doch ich. Ich habe nämlich ein Motorola Razr i und kann Mobile Studio nicht nehmen, weil dort ein Intel drin ist.
Nun muss ich mir was anderes einfallen lassen, wenn ich unter Android Apps erstellen will, wobei ich schon einige Hinweise von euch bekommen habe. Im Endeffekt wollte ich aber Delphi nehmen, um meine Apps zu erstellen.

[Mavarik]

Also...

Compile -> Link -> Deinstall/Install (2. Start) -> Start auf ein Nexus 10

1:06 Min

Das klingt schon besser...

Emulator hab ich dann abgebroch...

Grüsse Mavarik

[Medium]

Ach Leute. Es war doch (fast) abzusehen, dass hier ein nicht ganz fertig gebrütetes Ei um die Ecke fliegt. EMB demonstriert doch seit seiner Übernahme von Delphi solche Vorgänge, warum sollte es nun auf einmal richtig gemacht worden sein? Vor allem weil das kranke Kind FMX damit verheiratet ist. Ich bin ja ungerne der, der ins Horn der Miesepeter mitbläst - nicht zuletzt weil ich mit Delphi meine Brötchen verdiene, und Pascal toll finde. Aber ich nutze nach wie vor (und das mit 31 Jahren als durchaus als jung zu bezeichnender Delphianer) D2007, und habe mich dankend ablehnend um jeden weiteren günstigen Upgrade-Deal gedrückt. Aus eben diesem Grund: Setzt man die neusten Versionen ein, kann man fast sicher sein seit EMB prächtig zahlender Alpha-Tester zu sein, und meine Version bietet mir alles, was ich zum davon leben benötige. Und wenn ich Mobile-Apps bauen muss, dann nehme ich eben die Tools, die dafür gedacht und etabliert sind.
Fast jede Abstraktion von Mobile krankt an unterschiedlichen Ecken. Manche mögen für einzelne Zwecke okay sein, oder die Nachteile sind bei der Zielgruppe vernachlässigbar, aber am Ende ist man bei iOS und Android einfach mit den hauseigenen Werkzeugen besser bedient. Und et tut ja nu auch nich weh, ab und an mal eine neue Sprache zu lernen. Vor allem wenn sie die Konzepte der Zielplattform so viel besser reflektiert, und nicht ein zwanghaftes Einpressen von "fremden" Gewohnheiten mit teuren Tricks und "malpractices" ist.
Natürlich wünschte ich mir auch eine Ein-Code-Basis für alle Plattformen, sie werden ja auch in recht großer Zahl beworben und funktionieren weitestgehend (mit schwankendem Grad an voll teilbarem Code). Aber man muss sich einfach darüber im Klaren sein, dass man - was immer man nimmt (Xamarin, PhoneGap, Delphi Mobile, was auch immer) - sich den Komfort erkaufen muss. Sei es in Euros, Entwicklungskomfort, Doku, Feature-Support, Community Support oder auch Langzeitgewissheit bzgl. des Bestehens der Firmen. Wer sich freiwillig eine Krücke in die Hand nimmt, kann einfach nicht erwarten damit den 100m Lauf zu gewinnen.

[jaenicke]

Zitat:

Zitat von Medium (Beitrag 1228518)

Ach Leute. Es war doch (fast) abzusehen, dass hier ein nicht ganz fertig gebrütetes Ei um die Ecke fliegt.

Naja, was am längsten dauert ist das Deinstallieren und Reinstallieren der App. Darauf dürfte Embarcadero so ca. Null Einfluss haben...
Zumal das auf dem Gerät selbst auch gerne mal ne Weile dauert, auch wenn ich den Play Store nehme.
Und der Simulator ist aus Eclipse genauso schnarchlangsam, dafür können sie erst Recht nichts.

Dass es auch noch Fehler bei manchen Apps gibt, ist allerdings Embarcaderos Sache, und so etwas wie paclient gab Fehlercode 1 zurück, ist auch keine sonderlich schöne Fehlerbeschreibung...
Das ist aber eine andere Sache. Rein von der Geschwindigkeit her ist das jedenfalls soweit ich das sehe nicht Embarcaderos Schuld.

[CHackbart]

Ach naja es ist schon einiges besser geworden und ich finde den Gedanken gut größere Projekte nicht nur für Windows, sondern auch für andere Plattformen entwickeln zu können - ohne gleich die Sprache und/oder IDE wechseln zu müssen. Was ich allerdings zugeben muss, die Preise für das RAD Studio stehen in keinem Verhältnis zu dem was an Neuerungen mitgeliefert wird. Für einen Hobbyprogrammierer ist das nahezu unerschwinglich und ein Upgrade lohnt sich m.M.n. nur über einen Wartungsvertrag bzw. ein Softwareprojekt welches damit geplant ist. In unserem Fall ein Androidprojekt, bei dem XE5 als Kostenfaktor keine große Rolle spielt. Hat man mehrere Megabyte an Delphicode der plattformunabhängig gestaltet ist, mag man ungern auf Java umschwenken und dort ggf. Wochen mit einer Portierung des Codes verbringen wollen.
Zugegeben in XE5 wirkt Android etwas unausgegoren, aber ich erinnere mich an iOS in XE2. Das war quasi auch "nur" ein Technologiedemo auf Freepascal Basis ;)
Ich finde es dennoch außerordentlich praktisch für OSX und iOS innerhalb weniger Sekunden mit Ctrl+F9 mein Projekt zu kompilieren und halbwegs ordentlich debuggen zu können. Die Geschwindigkeit von Firemonkey ist mittlerweile akzeptabel - sofern man sich auf eine Hand voll Buttons und Check/Combo/Listboxen beschränkt. Allerdings nutzen wir bei unserem OSX Produkt, da es letztenendes Consumertauglich sein muss, TMS für native Anzeigen und reines OpenGL für den Rest.

[fgsoftware]

Zitat:

AW: Wie viel "R" steckt noch in RAD Studio XE5?

Embarcadero hat "R" in RAD neu definiert.
Rapid bedeutet, alle 6 Monate gibt es jetzt ein neues Upgrade.

Zitat:

Für einen Hobbyprogrammierer ist das nahezu unerschwinglich...

Ich glaube auch, dass Embarcadero die Hobbyprogrammierer als Zielgruppe aus den Augen verloren hat.
Die Preise, die Emparcadero für seine Alpha-Versionen verlangt, empfinde ich erblich gesagt, als Frechheit.

Was die Entwicklung für iOS und OS X angeht, ist Xcode wohl immer noch die bessere Wahl. Und das bekomme ich kostenlos.

Und für die Windows Geschichten gibt es ja das Visual Studio, in der Express-Edition ebenfalls kostenlos.

Ich mag nach wie vor die Sprache Object Pascal.
Embarcadero wird seine Strategie so weiter fahren und irgendwann wird es auch möglich sein, auf einer Waschmaschine eine mit dem RAD-Studio entwickelte App zum laufen zu bringen.
Die kann dann aber nur Handwäsche, für den Rest ist gibt es dann noch was von TMS.

[hstreicher]

hier mal meine alten Rechnungen durchgewühlt
Professional Upgrade
xe 427 Euro Incl UST
XE3 569
xe5 618

Die Preiserhöhung ist deutlich über der Inflationsrate,
und das für fast nix weil Mobile kostet ja extra

da steht das R wohl für "Richtig Teuer"

[Union]

Zitat:

Zitat von hstreicher (Beitrag 1228549)

hier mal meine alten Rechnungen durchgewühlt
Professional Upgrade
xe 427 Euro Incl UST
XE3 569
xe5 618

Die Preiserhöhung ist deutlich über der Inflationsrate,
und das für fast nix weil Mobile kostet ja extra

da steht das R wohl für "Richtig Teuer"

Aber dem gegenüber kostet ein S/A für Enterprise (in dem Mobil enthalten ist) ca. 650 inklusive der Garantie, dass es pro Jahr nicht mehr als 5 % Teuerung gibt.

[jaenicke]

Aufgrund dieser Preise käme für uns etwas anderes als ein Wartungsvertrag auch nicht in Frage. Einzelne Upgrades lohnen nur, wenn man nur jede dritte Version mitmacht, XE4 nicht mitgezählt...

Und man kann ein Upgrade von Professional auf Enterprise machen, da immer eine Edition niedriger reicht.

// EDIT:
Und für Professional + Mobile Addon sind es 300 + 150 Euro + MwSt. Das ist also immer noch billiger als ein Neukauf des Upgrades für Professional...

[stahli]

Delphi-Quellcode:

function BestDelphiKindSolution: TDelphiKind;
begin
  Result := 'dkUnknown';
  if a and b and c and d and not e and f or e or f and x or y and not z then
    Result := dkDelphiXE3Prof
  else
  if a and not b or c and d and not n and not f or e or f and x or y and not z then
    Result := dkDelphiXE3ProfAndMobilePack
  ...
end;

Habe jetzt keine Zeit, die Formel fertig zu stellen. :|

Daniel hat ja angekündigt, dass ein hochrangiger Delphi-Vertreter nach Leipzig kommt und man das Problem ansprechen sollte (ich kann aber kaum englisch).

Mit einem Wartungsvertrag weiß man halt nicht was man bekommt und für Hobby- und semiprofessionelle Programmierer wird der kaum erschwinglich sein.

[CHackbart]

Viele andere Firmen haben Hobbylizenzen für Entwickler die Nicht-Kommerzielle Lösungen schreiben. Quasi so etwas wie Turbo Delphi damals - auf diese Weise kann man Einsteiger wesentlich leichter an seine Produkte binden. Wer mehr will kommt um den Kauf einer Lizenz sowieso nicht drumherum. Mein erstes Turbo Pascal lag einem Buch bei und wenn ich dafür als Teenager Geld ausgegeben hätte, wäre ich damals nicht bei Pascal gelandet ;)

[jaenicke]

Zitat:

Zitat von CHackbart (Beitrag 1228565)

Viele andere Firmen haben Hobbylizenzen für Entwickler die Nicht-Kommerzielle Lösungen schreiben. [...] Mein erstes Turbo Pascal lag einem Buch bei und wenn ich dafür als Teenager Geld ausgegeben hätte, wäre ich damals nicht bei Pascal gelandet ;)

Solche Firmen denken und planen aber auch langfristig und wollen auf viele Jahre hinaus am Markt Erfolg haben.

Embarcadero ist hingegen auf Firmen und wenige Jahre im Voraus ausgerichtet (nach dem Motto: nach mir die Sintflut, dann bin ich als Manager vermutlich eh nicht mehr dabei).

[Der.Kaktus]

Zitat:

Zitat von jaenicke (Beitrag 1228568)

Zitat:

Zitat von CHackbart (Beitrag 1228565)

Viele andere Firmen haben Hobbylizenzen für Entwickler die Nicht-Kommerzielle Lösungen schreiben. [...] Mein erstes Turbo Pascal lag einem Buch bei und wenn ich dafür als Teenager Geld ausgegeben hätte, wäre ich damals nicht bei Pascal gelandet ;)

Solche Firmen denken und planen aber auch langfristig und wollen auf viele Jahre hinaus am Markt Erfolg haben.

Embarcadero ist hingegen auf Firmen und wenige Jahre im Voraus ausgerichtet (nach dem Motto: nach mir die Sintflut, dann bin ich als Manager vermutlich eh nicht mehr dabei).

daraus lese ich..Damals!!!! "BORLAND"..da war noch Harmonie..so sehe ich es auch!!!:thumb:

[Namenloser]

Wobei sie inzwischen den Zeitpunkt eh verpasst haben. Wenn jetzt noch eine kostenlose Hobbyversion käme, wäre das sowieso nicht mehr glaubwürdig – bei Turbo Delphi hieß es, da solle regelmäßig eine neue Version kommen. Es gab genau eine, und das war vor 7 Jahren. Delphi gilt ohnehin schon als Exot, die meisten Schüler und Studenten dürften es heutzutage wahrscheinlich nicht mal kennen. Wenn man dann noch nicht mal darauf verlassen kann, dass die Hobbyversion konsequent weitergeführt wird, wer will das schon einsetzen...

Das Schicksal von Delphi ist besiegelt.

[jaenicke]

Zitat:

Zitat von NamenLozer (Beitrag 1228573)

Delphi gilt ohnehin schon als Exot, die meisten Schüler und Studenten dürften es heutzutage wahrscheinlich nicht mal kennen.

Gebräuchlich war es ja noch nie wirklich, wird aber in Schulen durchaus noch benutzt.

Zitat:

Zitat von NamenLozer (Beitrag 1228573)

Das Schicksal von Delphi ist besiegelt.

Das wird seit mehr als 10 Jahren von Delphi gesagt. ;-)

[Namenloser]

Zitat:

Zitat von jaenicke (Beitrag 1228577)

Zitat:

Zitat von NamenLozer (Beitrag 1228573)

Delphi gilt ohnehin schon als Exot, die meisten Schüler und Studenten dürften es heutzutage wahrscheinlich nicht mal kennen.

Gebräuchlich war es ja noch nie wirklich, wird aber in Schulen durchaus noch benutzt.

Ja, aber inzwischen auch selten, und wenn dann uralte Versionen, die höchstens abschrecken ;)

Zitat:

Zitat von jaenicke (Beitrag 1228577)

Zitat:

Zitat von NamenLozer (Beitrag 1228573)

Das Schicksal von Delphi ist besiegelt.

Das wird seit mehr als 10 Jahren von Delphi gesagt. ;-)

Kommt natürlich immer darauf an, was man damit meint. Dass es C++ oder Java das Wasser abgreifen würde, habe ich sowieso nie erwartet, aber bis vor ein paar Jahren hatte ich noch die Hoffnung, dass es als Nische eine Zukunft haben könnte.

[jaenicke]

Zitat:

Zitat von NamenLozer (Beitrag 1228578)

Ja, aber inzwischen auch selten, und wenn dann uralte Versionen, die höchstens abschrecken ;)

Naja, ich habe in ein paar Fällen dann Turbo Delphi vorgeschlagen... denn das gibt es für Schulen wohl auch immer noch kostenlos. Leider war in den meisten Fällen schlicht die Hardware zu schlecht dafür...
Hier in Berlin sieht die im Vergleich dank cids ja echt gut aus, aber ich höre auch von woanders immer wieder von Pentium II mit 233 MHz usw., da ist dann Delphi 5, das da relativ häufig anzutreffen ist, gar nicht schlecht...

Zitat:

Zitat von NamenLozer (Beitrag 1228578)

aber bis vor ein paar Jahren hatte ich noch die Hoffnung, dass es als Nische eine Zukunft haben könnte.

Die habe ich jetzt eher als noch zu Zeiten von Codegear trotz Einstellung der Turbos...
Denn es hat sich seither extrem viel an Features und der IDE verbessert. Da ist zwar weiter Luft nach oben, aber im professionellen Umfeld sehe ich da schon eine gute Zukunft. Allerdings nicht wegen des Marketings und der Qualität sondern trotz... und das liegt an der Weiterentwicklung in den letzten Jahren.

Und das R steht nicht für die Compilergeschwindigkeit. ;-)

[Sir Rufo]

@jaenicke :thumb:

... und auch nicht für Emulatorgeschwindigkeit

sondern für das schnelle Draufklatschen von Komponenten

[Furtbichler]

Zitat:

Zitat von Sir Rufo (Beitrag 1228597)

sondern für das schnelle Draufklatschen von Komponenten

...und parametrieren und Entwicklungsiteration (d.h. Kompilieren, starten, stoppen, coden, compilieren...). Ich arbeite ja nun seit Jahren fast ausschließlich mit VS, aber o.g. Features (vor allen Dingen das Komponentenschubsen/draufklatschen) ist bei Delphi immer noch viel besser.

Das Einzige, was jetzt noch fehlt, wäre die Möglichkeit, Code während des Debuggens zu verändern und den aktuellen Schritt nach vorne zu verschieben (wie VS das vormacht).

[Codehunter]

Ich reibe mir gerade verwundert die Augen wegen der beklagten Startzeiten von XE5. Sind die denn im Vergleich zu XE4 so viel schlechter geworden? Mein XE4 Pro steht beim ersten Start innerhalb von 7 Sekunden Gewehr bei Fuß, inklusive CnPack und UniDAC. Eine Höllenmaschine habe ich auch nicht: Intel Core i7 4770K mit 8 GB RAM und einer 180 GB Intel-SSD als Boot- und Softwareplatte.

Ehrlich gesagt habe ich mich sogar gewundert, dass XE4 effektiv schneller startet als das parallel installierte D7 Pro. Allerdings muss ich dazu sagen, dass das Windows nicht mehr Standard ist sondern einiges optimiert wurde für die SSD (Indexing, Prefetch und Superfetch aus etc.). Daher erlaube ich mir zu orakeln, dass Windows von Haus aus die größte Performancebremse ist.

[stahli]

[OT]

Zitat:

Zitat von Furtbichler (Beitrag 1228604)

Das Einzige, was jetzt noch fehlt, wäre die Möglichkeit, Code während des Debuggens zu verändern und den aktuellen Schritt nach vorne zu verschieben (wie VS das vormacht).

Ich habe in Erinnerung, dass es mal ein Tool für 15T€ oder so gab, mit dem man in die Tiefe debugen und auch wieder an frühere Positionen springen und debugen konnte. (Ahh, hab´s gefunden: http://www.delphipraxis.net/1112990-post47.html)
Meinst Du so was. Gibt es das sonst in einem Video zu sehen?

[/OT]