Ist Delphi so Bedeutungslos ?

[CCRDude]

Zitat:

Zitat von schöni (Beitrag 1203302)

Mein Lazarus 0.9.29 läuft auch auf Laufwerk D: ohne Eintragungen im Benutzerverzeichnis auf C:

Zitat:

Zitat von schöni (Beitrag 1203302)

Ich gehöre ausdrücklich NICHT zu den Leuten, die "...die vor x Jahren mal ausprobiert hat und irgendwas nicht funktionierte. ..." sondern nach wie vor Lazarus installiert haben

Hättest Du jetzt nicht so ausführlich geschrieben, hätte ich Dich fast für einen Troll gehalten ;)

Wenn Du eine ca. drei Jahre alte unstable (ungerade Versionsnummer) benutzt (oder handelt es sich sogar um ein nightly build?), solltest Du Dich nicht über Bugs beschweren. Warum keine stable (gerade Versionsummer)? Die unstables würde ich im Produktiveinsatz nie erwägen, und auch dann nicht, wenn ich nicht bereit bin, über deren Bugtracker mitzuwirken.

Die aktuelle stable ist 1.0.6, und ich persönlich zumindest bin erst seit der 1.0 richtig überzeugt, vorher war vermutlich auch viel Wunschdenken dabei. Wobei ich aus Erfahrung mit vielen Versionen davor weiß, dass die stables im 0.9er Bereich auch alle deutlich schmerzfreier waren als die unstables.

[schöni]

Zitat:

Zitat von CCRDude (Beitrag 1203314)

Zitat:

Zitat von schöni (Beitrag 1203302)

Mein Lazarus 0.9.29 läuft auch auf Laufwerk D: ohne Eintragungen im Benutzerverzeichnis auf C:

Zitat:

Zitat von schöni (Beitrag 1203302)

Ich gehöre ausdrücklich NICHT zu den Leuten, die "...die vor x Jahren mal ausprobiert hat und irgendwas nicht funktionierte. ..." sondern nach wie vor Lazarus installiert haben

Hättest Du jetzt nicht so ausführlich geschrieben, hätte ich Dich fast für einen Troll gehalten ;)

Wenn Du eine ca. drei Jahre alte unstable (ungerade Versionsnummer) benutzt (oder handelt es sich sogar um ein nightly build?), solltest Du Dich nicht über Bugs beschweren. Warum keine stable (gerade Versionsummer)? Die unstables würde ich im Produktiveinsatz nie erwägen, und auch dann nicht, wenn ich nicht bereit bin, über deren Bugtracker mitzuwirken.

Die aktuelle stable ist 1.0.6, und ich persönlich zumindest bin erst seit der 1.0 richtig überzeugt, vorher war vermutlich auch viel Wunschdenken dabei. Wobei ich aus Erfahrung mit vielen Versionen davor weiß, dass die stables im 0.9er Bereich auch alle deutlich schmerzfreier waren als die unstables.

Sorry, ich habe meine Testerfahrung gemacht, mit Version 3.1 übrigens von der Pilot logic Seite. Woher soll ich bei der dortigen Auflistung wissen, welches eine stabile und welches eine Entwicklerversion ist?

Ich sage den Programmieren noch mal, denkt auch an die mit langsameren Rechnern. Nicht jeder braucht eine CPU mit 2 GHz Doppelkern noch dazu. Passt Eure Software so an, das sie auch auf schwächeren Rechnern performant läuft. Schließlich wollt Ihr bei OpenSource mindestens AnerKennung und wohl doch auch letztendlich Geld verdienen. Denn auch der Rechner eines Open Source Programmierers muss erst mal gekauft werden, dieser braucht Strom und wohl wegen CVS auch Internet. Essen und Trinken und wohnen muss der OpenSource Programmierer ebenso und all das kriegt der auch nicht gratis, auch die Heizung im Winter kostet Geld....

Ich jedenfalls werde keine Software kaufen, die meinen Rechner überfordert. Diese "Killer Applikation" gibt es einfach nicht, kann es bei heutiger Rechenpower im Heimsegment nicht geben, die die Anschaffung eines Superrechners rechtfertigen würde. Und Computerspiele starte ich höchstens mal nebenbei zur Entspannung, somit auch kein Grund,hierfür in High End Hardware zu investieren nur damit ich ebenieses eine Spiel spielen kann. Es gibt genug andere genügsamere PC Spiele.

Außerdem bleiben auch bei der vermeintlich stabilen Version die happigen Systemanforderungen. Welche Lizenz hat das Ding überhaupt.Bei den Hardwareanforderungen ist es bei meinem Einkommen komplett ausgeschlossen, wieder Open Source Software zu schreiben, die ich dann noch zu verschenken habe, der Rechner der die happigen Harwareanforderungen wirklich erfüllt wird mir nämlich mitnichten geschenkt. Auch die fehlenden Dokus zu den Komponenten bekomme ich auf keinen Fall einfach geschenkt und Lehrgänge dazu kosten so richtig Geld. Tja und wenn da schon die Installation fehlschlägt dann sorry, dann ist das eben nicht das passende Produkt für mich.

OpenSource Software geht, wenn überhaupt ausschließlich auf meiner alten Hardware zu entwickeln. Nicht aber wenn ich mir dazu erst die aktuellen Werkzeuge teuer kaufen muss, sei es auch für CodeTyphon nur ein schnellerer Rechner oder leider eben auch die Dokumentationen zu allen den schönen Komponenten. Das ist dann nicht so frei und gratis verfügbar. Und mit zeitraubendem Quelltextstudium und Versuch Irrtum, wer bezahlt mir dann die Programmierstunden. Spaß macht das Programieren dann nämlich ganz und gar nicht, weil der Erfolg sehr lange auf sich warten lässt. Jemand für den ich aber als Freelancer ein Projekt erstelle, will wissen, wie lange ich dazu brauche, dann wird die Zeit geplant und ich muss zum Termin Liefern. Da dauert das Quelltextstudium anstelle der Doku zur Komponente einfach zu lange. Aber den schnelleren Rechner und die besagten Dokus sind dann nicht mehr gratis oder Open Source oder was auch immer. Da muss ich dann richtig viel Geld hinlegen. Nein, CodeTyphon funktioniert für mich unter den gegebenen Bedingungen nicht, das gute an dieser freien Software ist, ich kann sie bei Nicht gefallen einfach wieder deinstallieren und gut is. Bei Emba hätte ich in so einem Fall jetzt ordentlich Schriftverkehr weil ich in so einem Fall natürlich mein Geld zurück verlangen würde. Eine Open Source Software dagegen lösche ich einfach wieder und damit hat es sich dann, hat dann halt nicht funktioniert für mich. Und Ende.

[JamesTKirk]

Zitat:

Zitat von Meflin (Beitrag 1203240)

Zitat:

Zitat von JamesTKirk (Beitrag 1203234)

wo kann man diese modernen Konzepte wirklich sinnvoll gebrauchen? Also nicht im Sinne von "Hey, Sprache X unterstützt jetzt Y und damit kann man prinzipniell Z machen!", sondern wo man das im normallen Programmieralltag (Stichwort "Brötchen verdienen") gebrauchen kann.

Ja sorry, aber was genau erwartest du darauf jetzt als Antwort? Hauptsächlich erspart mir das alles, Code zu schreiben. Damit kann ich mich auf die wesentlichen Sachen konzentrieren, bin produktiver und kann mehr Brötchen verdienen. Oder wofür braucht man nochmal genau diesen ganzen modernen Kram wie Objekte? Mit Assembler kann ich doch auch alles implementieren (... ist natürlich KEIN ernstgemeintes Argument, soll aber verdeutlichen in welcher Argumentationssituation ich mich da gerade sehe ;) )

Eben genau solche Beispiele. Zum Beispiel was du in Delphi hättest machen müssen, aber durch entsprechende Features (also Traits, Duck Typing, Type Inference, etc.) in einer anderen Sprache übersichtlicher oder einfacher hinbekommen hast.

Hat zwar jetzt nichts mit den oben genannten Features zu tun, aber ich spiele zum Beispiel mit dem Gedanken das Konzept der Class Contracts aus Oxygene für Free Pascal zu übernehmen, da es meiner Meinung nach die Übersicht fördert.

Zitat:

Zitat von Meflin

Welche Werkzeuge bietet mir z.B. Delphi/Free Pascal, um mit Crosscutting Concerns umzugehen? Kein AOP, keine Traits, kein garnix. Oder ist das ein Problem, was man als durchschnittlicher Delphi-Entwickler nicht hat? Oder doch einfach eher nicht kennt, aber durchaus hat.

Ich habe zumindest die oben genannten Punkte (Duck Typing, Type Inference, AOP - Traits lass ich mal außen vor, da ich mich darüber erst informieren müsste) bisher noch nicht vermisste. Mich würden also Beispiele interessieren in welchen konkreten Situationen solche Sprachkonstrukte vermisst werden.

Zitat:

Zitat von cookie22 (Beitrag 1203252)

Zitat:

Zitat von NamenLozer (Beitrag 1203246)

Zitat:

Zitat von cookie22 (Beitrag 1203244)

Lazarus ist mehr oder weniger nicht zu gebrauchen.

Lazarus ist mittlerweile durchaus zu gebrauchen. Das einzige echte Manko ist aus meiner Sicht, dass man Pakete nicht dynamisch laden kann, sondern die IDE jedes mal neu kompilieren muss, wenn man z.B. eigene Komponenten im Designer verwenden will. Wobei schon ziemlich viele Komponenten von Haus aus mitgeliefert werden... Ansonsten ist die Oberfläche vielleicht nicht ganz zeitgemäß, aber deshalb nicht weniger funktional.

Das Problem ist, dass wichtige Dinge für Windows einfach gar nicht oder nur mangelhaft umgesetzt werden. Stichwort "COM". Liegt einfach nicht im Interesse der Open Source X-Platform Community. Man will halt alles X-Platform bedienen können.

Zu der Zeit als du mit COM rumgespielt hast (2009) war die Unterstützung in FPC und Lazarus zugegebenermaßen noch mehr schlecht als recht. Das hat sich im Laufe der Zeit geändert und mit 2.6.0 wurde sogar ein spezieller Modifier für Parameter (

Delphi-Quellcode:

constref

) eingeführt, der es erlaubt

Delphi-Quellcode:

IInterface

auch korrekt für XPCOM zu verwenden. Außerdem wurde ein Tool eingepflegt welches aus einer Typbibliothek eine Pascal Unit erzeugen kann mit einem entsprechenden Dialog für Lazarus.

Zitat:

Zitat von cookie22 (Beitrag 1203252)

Andererseits kann man noch nicht einmal die Toolbars customizen. Die IDE ist halt einfach 15 Jahre hinter der Zeit.

Es gibt die Möglichkeit eine anpassbare Toolbar für den Editor einzubinden. Und warum sollte die IDE 15 Jahre hinter der Zeit sein? Die Priorität der Entwickler liegt eben in anderen Punkten (Multiplattformfähigkeit, Refactoringfunktionen, etc.) und wenn du was geändert willst, dann musst du das schon zum Beispiel auf dem Bugtracker bekannt machen.

Zitat:

Zitat von cookie22

Bist du Lazarus-Entwickler oder warum bist du so unfreundlich?

Ich bitte darum von solchen Verallgemeinerungen Abstand zu nehmen. Die Lazarus Entwickler mit denen ich es bisher auf den Mailinglisten zu tun hatte sind alles Leute, mit denen man gut reden kann, solange man nicht selbst pampig wird.

Zitat:

Zitat von schöni (Beitrag 1203302)

Die meisten der ach so tollen Komponenten sind mangelhaft oder gar nicht dokumentiert.

Das Schreiben von Dokumentation ist leider nicht jedermanns Sache und noch dazu enthält allein Free Pascal eine große Anzahl an zusätzlichen Units...

Zitat:

Zitat von schöni

- Nachladen der Komponente erst in dem Moment, wo ich sie aus der Palette auswähle. Vorher nur Anzeige, das sie verfügbar ist.

-Möglicherweise sollte FPC dazu um Packages im Delphi Stil erweitert werden.

Für deinen ersten Punkt MUSS FPC um entsprechende Packages erweitert werden. Sie stehen ja auch auf unserer ToDo Liste, aber sie sind nicht trivial zu implementieren, zumindest nicht, wenn sie wenigstens unter Windows, Linux und Mac OS X funktionieren sollen...

Zitat:

Zitat von schöni

-Wesentlich kürzere Kompilierzeiten. 2 Minuten und Länger für ein Hello World Programm oder ein leeres Formular sind entschieden zu lang. Dann stimmen noch Unitpfade nicht, Suchen und UNitpfade anpassen, wieder 2 Minuten kompilieren und womöglich fehelen dann andere Units. Nee, so nicht. Funktioniert für mich nicht. Delphi würde ich sofort an Emba zurück schicken und mein Geld zurück verlangen, wenn die sich das erlauben würden.

:shock: Das verwundert mich schon sehr. Ich habe einen Rechner mit 800 MHz, 1GB RAM auf dem Windows 7 läuft und in zwei Minuten schaffe ich es den kompletten Compiler neu bauen zu lassen (aus der IDE raus).

Zitat:

Zitat von schöne

-Oft ärgere ich mich über träge laufende Programme mit immer mehr Zeug drin, das ich nie und nimmer nutze, nur meinen Rechner verlangsamt, weil ich bei Start der Software auch all das ressourcenfressende Zeug mit starte.

- Es ist deshalb an der Zeit, alle heutigen IDEs abzuspecken und dort nur das in den Speicher zu laden, was aktuell gebraucht wird. Festplatten sind groß genug heutzutage, da kann eine Komponente auch gut auf der Festplatte gehalten und nur bei Bedarf geladen werden. Dann würde die IDE viel schneller starten und hätte in einer Liste doch alle Komponenten vorrätig, die dann eben erst wirjklich in den RAM kommen, wenn ich sie anfordere. Warum zum Teufel ist das sooooo schwierig. Dann namlich kämt Ihr Entwickler mit schwächeren Rechnern aus und könntet Eure Software auf diesen langsamen Rechnern ausgiebig auf Tauglichkeit testen. Ich habe in "Was nervt mich heute beim Programmieren besonders auch was dazu geschrieben, was in diese Richtung geht.

Das finde ich jetzt eine sehr interessante Aussage. Die einen regen sich darüber auf, dass Docking nicht standardmäßig aktiviert ist und die anderen regen sich darüber auf, wenn zu viel aktiviert ist... Man kann es eben nicht allen Recht machen.

Gruß,
Sven

[BlackSeven]

Zitat:

Das sollte neben in die Profilinformation. :twisted:

Wie geht's denn so? :-D

:lol:

[CCRDude]

Zitat:

Zitat von schöni (Beitrag 1203326)

Sorry, ich habe meine Testerfahrung gemacht, mit Version 3.1 übrigens von der Pilot logic Seite.

PilotLogics CodeTyphon ist nicht Lazarus, das ist ein Monster, das versucht, Lazarus zur eierlegenden Wollmilchsau zu machen, mit hunderten von Komponenten, die man höchstens zu 10%, besser zu 1%, jemals brauchen wird.

Das eigentliche Lazarus startet bei mir um ein vielfaches schneller als Delphi, und ich kanns auch auf nem 10 Jahre alten Notebook genauso gut nutzen wie auf nem 6 Jahre alten Mac - ohne nervige Verzögerung beim Starten/Benutzen. Letzteres ist glaube ich schon Core Duo, aber unter 2 GHz, und ersteres ist davon meilenweit entfernt.

Zitat:

Zitat von schöni (Beitrag 1203326)

Woher soll ich bei der dortigen Auflistung wissen, welches eine stabile und welches eine Entwicklerversion ist?

Über den Download-Link auf der Lazarus-Webseite wärst Du entweder bei 0.9.28 oder 0.9.30 gelandet. Bei den ungeraden Versionsnummern steht das deutlich dabei, ich zitiere mal von der Daily Builds-Seite (woanders finde ich aktuell gar keine ungeraden Builds):

Zitat:

BEWARE: These snapshots are generated automatically and are untested. The only thing we can say is, that the compiler found the source good enough to compile.
More information about these snapshots can be found on the wiki page about Lazarus snapshots.
These snapshots are provided as a courtesy only. If they don't work, too bad! If they destroy your project files, crash your machine, and eat your disk: Tough luck! (just to say that YOU ARE USING COMPLETELY UNTESTED SOFTWARE)

[mkinzler]

Man kann sich schon über das Ursprungsthema streiten, aber die Unterschiedene zwischen Lazarus und CodeTyphon, MSEGUI o.ä. hat wirklich nichts mehr mit dem Thema zu tun.

[Popov]

Gefühle spielen nur dann eine Rolle, wenn einem etwas wichtig ist. Über Unwichtiges streitet man sich nicht.

[Wunni]

Zitat:

Zitat von cookie22 (Beitrag 1203310)

Zitat:

Zitat von Wunni (Beitrag 1203303)

Zitat:

Zitat von cookie22 (Beitrag 1203298)

Zitat:

Zitat von Wunni (Beitrag 1203278)

jetzt ist mir auch klar, warum Du mit Lazarus nicht klar kommst!

Manchmal sieht man den Wald vor lauter Bäumen nicht. Statt dummer Sprüche hättest du mir auch helfen können. Denn genau dazu ist dieses Forum da. ;)

dann hättest Du Fragen stellen sollen und nicht über ein Projekt herziehen sollen, welches Du scheinbar nicht kennst.

Dann verrat es mir doch oder ist das geheim?

Ich hab Lazarus Jahre lang in einem kommerziellen Projekt eingesetzt und die "BigIde" nie gebraucht und mich nicht damit beschäftigt. Ich benutze einfach die Version die auf Source Forge zum Download gibt.

Bist du Lazarus-Entwickler oder warum bist du so unfreundlich?

Sorry, wenn Du meine Antwort als unfreundlich empfunden hast. Nein, ich habe nichts mit dem Lazarus Projekt zu tun! Ich finde es eben befremdlich, wenn jemand über ein anderes Projekt und somit Personen, die ohne Profit so etwas wie FreePascal und Lazarus entwickeln, ein Urteil fällt. Zitat: "Lazarus ist mehr oder weniger nicht zu gebrauchen". Ich bin mir sicher, dass es die schlechte Qualität von Delphi nicht verbessern wird, wenn hier unwahre Dinge über andere Produkte oder Frameworks verbreitet werden.
Nun noch zum Thema:
Der Thread "Ist Delphi so bedeutungslos" hat aus meiner Sicht seinen Ursprung in der schlechten Qualität von Delphi die mit jeder Version noch zunimmt. Ich kaufe seit Delphi 1 jede Version. Bei der Vorgehensweise des Herstellers bin ich gezwungen, mir jedes Jahr eine neue Version zu kaufen, wenn ich nicht ewig mit den Bugs und halb fertigen Features leben möchte. Es ist nicht so wie bei anderen Produkten und Herstellern, dass auch die vorherige Version noch durch Bugfixes unterstützt wird. Für die aktuelle Version gibt es allerdings "gefühlt" jeden Monat eine Fehlerkorrektur, bei der bedingt durch den untauglichen Installer immer die komplette Version neu installiert werden muss. Ich kann diese Aufwände gegenüber dem Management nicht vertreten, wenn ein mittelgroßes Entwicklerteam sich ständig um Neuinstallation und Umgehungslösungen von Bugs kümmern muss. Nicht selten kommt es vor, dann man "warum auch immer" mal Windows neu aufsetzen muss. Ich habe seit Jahren einen Maintenance Vertrag für Rad Studio Architekt, aber schon nach wenigen Installation darf ich es nicht mehr installieren und muss irgendwo in England anrufen. Sorry, mehr als 1200,00 € pro Kopf im Jahr und man wird nach 20 Jahren Delphi Treue behandelt wie ein Raubkopierer! Ich habe auch MSDN Complete und von Microsoft werde ich als Kunde so nicht behandelt.
Unter all diesen Umständen finde ich es nicht verwunderlich, dass es hier solche Themen gibt und diese immer wieder hochkommen.
Viele Jahre wurde mir auf Konferenzen und Forentreffen in den Vorträgen Delphi .NET als das Framework der Zukunft verkauft. Die selben Personen verteufeln es heute, obwohl die angeführten Gründe schon damals gegeben waren. Die Begeisterung von .NET wurde doch auf diesen Veranstaltungen erst geweckt und nun soll alles falsch gewesen sein, Matthias?
Ich wünsche Delphi nach 20 Jahren das es endlich irgendwann wieder aufwärts geht, aber mir fehlt der Glaube! Visual Studio 2012, Lazarus und XCode sind mehr als Alternativen!
Es ist bei der Fragestellung "Delphi bedeutungslos" auch nicht "off topic", wenn man über Alternativen diskutiert!

[cookie22]

Zitat:

Zitat von Wunni (Beitrag 1203364)

...Ich finde es eben befremdlich, wenn jemand über ein anderes Projekt und somit Personen, die ohne Profit so etwas wie FreePascal und Lazarus entwickeln, ein Urteil fällt. Zitat: "Lazarus ist mehr oder weniger nicht zu gebrauchen". Ich bin mir sicher, dass es die schlechte Qualität von Delphi nicht verbessern wird, wenn hier unwahre Dinge über andere Produkte oder Frameworks verbreitet werden.

Ich habe hier lediglich meine Meinung über Lazarus zu besten gegeben, die ich mir Anhand von eigenen Erfahrungen gebildet habe. Das steht weiter vorne im Thread.

Wie man die "BigIde" compiliert hast du immer noch nicht verraten. :stupid:
Aus der Ide herraus geht es jedenfalls nicht. ;)

[Wunni]

Zitat:

Zitat von cookie22 (Beitrag 1203366)

Zitat:

Zitat von Wunni (Beitrag 1203364)

...Ich finde es eben befremdlich, wenn jemand über ein anderes Projekt und somit Personen, die ohne Profit so etwas wie FreePascal und Lazarus entwickeln, ein Urteil fällt. Zitat: "Lazarus ist mehr oder weniger nicht zu gebrauchen". Ich bin mir sicher, dass es die schlechte Qualität von Delphi nicht verbessern wird, wenn hier unwahre Dinge über andere Produkte oder Frameworks verbreitet werden.

Ich habe hier lediglich meine Meinung über Lazarus zu besten gegeben, die ich mir Anhand von eigenen Erfahrungen gebildet habe. Das steht weiter vorne im Thread.

Wie man die "BigIde" compiliert hast du immer noch nicht verraten. :stupid:
Aus der Ide herraus geht es jedenfalls nicht. ;)

dann musst Du das auch lesen, was dir ibexpert empfohlen hat und codetyphon installieren.
Von mir war der Beitrag und die Empfehlung nicht!
nichts für ungut...

[cookie22]

OT: Bei CodeTyphon flippt Kaspersky aus und findet mehrere Trojaner.

[Phoenix]

Zitat:

Zitat von Wunni (Beitrag 1203364)

Viele Jahre wurde mir auf Konferenzen und Forentreffen in den Vorträgen Delphi .NET als das Framework der Zukunft verkauft. Die selben Personen verteufeln es heute, obwohl die angeführten Gründe schon damals gegeben waren. Die Begeisterung von .NET wurde doch auf diesen Veranstaltungen erst geweckt und nun soll alles falsch gewesen sein, Matthias?
Ich wünsche Delphi nach 20 Jahren das es endlich irgendwann wieder aufwärts geht, aber mir fehlt der Glaube! Visual Studio 2012, Lazarus und XCode sind mehr als Alternativen!
Es ist bei der Fragestellung "Delphi bedeutungslos" auch nicht "off topic", wenn man über Alternativen diskutiert!

Tja. Man hat es selber nicht vernünftig hinbekommen, und sich dann einer Fremdlösung (Chrome alias Oxygene) bedient und die dann unter dem eigenen Label Prism eingeführt, die allerdings vom einem (dann doch unbequemen) Hersteller kommt, der ein direktes Konkurrenzprodukt zum eigenen DataSnap anbietet. Und das in Kombination Delphi Prof. + "Konkurrenz" / "Partner"tool noch billiger ist, als die für DataSnap benötigte Enterprise-Version. Da stellt man sich doch die Frage, warum mal eine so komische noch nicht offizielle Version der EULA kursierte, die den Datenbankzugriff mit der Professional-Edition so massiv eingeschränkt hatte. Natürlich war das nie beabsichtigt, aber das hätte der Kombination hier elegant einen Riegel vorgeschoben.

Und dann erdreistet sich dieser Hersteller auch noch, zum 'echten' .NET Support in Oxygene auch noch echten, nativen Java- / Android und echten, nativen iOS und OS X Support in sein Tool einzubauen, was auf einmal FireMonkey Konkurrenz macht (und nebenbei überall auch so aussieht wie nativ und vor allem Zugriff auf alle nativen Komponenten erlaubt, wie z.B. den Webbrowser unter iOS..). Und das ganze im Bundle zu einem Preis, für den man kein Delphi (mit dem ganzen Affentheater) bekommt.

Natürlich schimpft man dann auf .NET, weil das ist ja böse etc... Natürlich ist das alles Strategisch. Wenn man irgendwann mal Prism abstossen will, will man natürlich vorher möglichst viele davon Überzeugen, das man es gar nicht erst braucht...

[Lemmy]

Hallo Holger,

Zitat:

Zitat von IBExpert (Beitrag 1203042)

Ich finde es immer wieder befremdlich, das Journalisten natürlich jede Sau durchs Dorf treiben, die man irgendwie gefunden hat, unabhängig von der Qualität der Quelle. ...

Was stört es die Eiche, wenn die Sau sich an ihr kratzt ....

vielen herzlichen Dank für diesen Post!!!

[Furtbichler]

Zitat:

Zitat von Phoenix (Beitrag 1203371)

Und dann erdreistet sich dieser Hersteller auch noch..Und das ganze im Bundle zu einem Preis, für den man kein Delphi (mit dem ganzen Affentheater) bekommt.

Echt eine Frechheit. :lol:

[JamesTKirk]

Zitat:

Zitat von cookie22 (Beitrag 1203369)

OT: Bei CodeTyphon flippt Kaspersky aus und findet mehrere Trojaner.

Immer diese Antivirenprogramme... das beste war vor fast zwei Jahren mal AntiVir, als ich in Delphi Testprogramme für class und record helper geschrieben hab, bei denen es mir auf die Syntax ankam und deswegen der "begin ... end" Block des Programms leer war... bei jedem einzelnen dieser Testprogramm hat es mir erneut gemeckert -.-

Um nochmal auf das bigide zurückzukommen. Ich weiß nicht, ob die bei CodeTyphon was geändert haben, aber beim normalen Lazarus ist das ein Target für make, welches die IDE mit sämtlichen (für die aktuelle Plattform mitgelieferten) Packages kompiliert. Aufgerufen wird das in einem Kommandozeilenfenster folgendermaßen:

Code:

cd c:\dein\lazarus\verzeichnis
make bigide

Ich persönliche aktiviere da allerdings lieber jedes Package von Hand, dann kommt nur das in die IDE, was ich wirklich brauch. :)

Gruß,
Sven

[schöni]

Zitat:

Zitat von JamesTKirk

Das verwundert mich schon sehr. Ich habe einen Rechner mit 800 MHz, 1GB RAM auf dem Windows 7 läuft und in zwei Minuten schaffe ich es den kompletten Compiler neu bauen zu lassen (aus der IDE raus).

Diese Aussage betrachte ich als glatte Lüge, Schönmalerei wie sie nur betonköpfige Ideologen fertig bringen, denn ich habe das auf einem 1,7GHz Doppelkernprozessor Intel Atom auf einem Tablet mit 2GByte Ram getestet. CodeTyphon ist so langsam. Altere Lazarus Versionen schneiden hier besser ab, wohl auch,weil nicht so viel Code mitgeschleppt wird. Deswegen sagte ich ja auch Komponenten besser dynamisch laden zu dem Zeitpunkt wo sie wirklich gebraucht werden. In Delphi wäre das wegen der Packages schon heute möglich. FP müsste wohl dazu um diese Packages erweitert werden.

Zitat:

Zitat von JamesTKirk

Das Schreiben von Dokumentation ist leider nicht jedermanns Sache und noch dazu enthält allein Free Pascal eine große Anzahl an zusätzlichen Units...

Mag sein, aber ich kann an dieser Stelle nicht aushelfen, nicht weil ich zu faul bin, sondern weil ich so schlicht und einfach die Komponente(n) nicht verstehe, nicht weiß, wie sie zu verwenden ist/sind. Schade eigentlich um die Arbeit derProgrammierer, die die Komponenten gebaut haben, das sind nämlich wirklich gute dabei, wie eben zB. TODBCConnection, denn warum soll ich zur Einarbeitung in die Datenbankproblematik einen extra Server installierenwo doch ODBC in Windows schon drin ist?

Zitat:

Zitat von JamesTKirk

Das finde ich jetzt eine sehr interessante Aussage. Die einen regen sich darüber auf, dass Docking nicht standardmäßig aktiviert ist und die anderen regen sich darüber auf, wenn zu viel aktiviert ist... Man kann es eben nicht allen Recht machen.

Das liegt nicht am Docking, denn sooo viel Ressourcen düfte diese Funktion nicht fordern, das ligt an überdimensionierten Bibliotheken, deren Code auf jeden Fall mitgeschleppt wird, egal ob ich ihn in meinem konkreten Programm auch wirklich brauche.

Zitat:

Zitat von CCRDUDE

Das eigentliche Lazarus startet bei mir um ein vielfaches schneller als Delphi, und ich kanns auch auf nem 10 Jahre alten Notebook genauso gut nutzen wie auf nem 6 Jahre alten Mac - ohne nervige Verzögerung beim Starten/Benutzen. Letzteres ist glaube ich schon Core Duo, aber unter 2 GHz, und ersteres ist davon meilenweit entfernt.

Das kann ich bestätigen. Ich habe bei mir aktuell Lazarus 0.9.29 am Laufen und bin zufrieden damit.
Das heißt, ich wünsche mir allerdings mehr Dokumentation zu den Komponenten. Hab nach langer Abstinenz
wieder mal gestartet und mir die Datenbankkompos angeschaut. Da sind einige die es in Delphi nicht gibt.
Aber leider ist keine Doku zu finden.

Zitat:

Zitat von CCRDUDE

Über den Download-Link auf der Lazarus-Webseite wärst Du entweder bei 0.9.28 oder 0.9.30 gelandet. Bei den ungeraden Versionsnummern steht das deutlich dabei, ich zitiere mal von der Daily Builds-Seite (woanders finde ich aktuell gar keine ungeraden Builds):

Darauf muss man aber erst mal kommen auf der Lazarus Seite zu schauen, wenn man Code Typhon sucht.
Ich bleibeb nun bei Lazarus 0.9.29. Eine spätere Version muss nicht sein.

Soooo, um nun mal zu eigentlichen Thema des Stranges zu kommen, es macht mich traurig, das Delphi so abseits steht. Ich schaue mir auch oft Stellenangebote an und dasehe ich bei Programmiererjobs nur C++ oder Html, Css und anderes aber kein Delphi. Schade.

Aber wenn ich dann lese, was @Wunni schreibt, dann wundert micht nichts mehr. Für den heutigen Anschaffungspreis würde ich exzellente Qualität erwarten oder das Produkt nicht mehr kaufen. Unsere Arbeitgeber sind mit uns nicht so tolerant. In Tätigkeiten für die man keine spezielle Qualifikation braucht und in Zeitarbeitsfirmen ist das besonders schlimm. Wegen Kleinigkeiten wird man da gefeuert. Da sehe ich überhaupt nicht ein, warum oich dann die Marotten der Großen tolerieren soll.

Schade aber ist es um das Produkt schon. Klasse Idee, das RAD Tool. Wäre alles zur Laufzeit instantiiert wesentlich mehr Arbeit. Ich erinnere mich noch gut an Turbo Pascal und Turbo Vision. Damals gab es als Shareware einen Workshop der ebenso interaktiv Menü, Statuszeile und Dialoge erstellen konnte. Das war aber ein separates Programm. Man musste die Pascal IDE verlassen um Meü, Statuszeile und die Dialoge zu bauen und den Quellcode zu erzeugen, danach den Workshop verlassen und in der IDE dann die Quelltexte in sein Programm einbinden. Wie viel komfortabler ist doch das unser Delphi.

Auch hier sage ich noch mal, wie schon zu Lazarus, ich wünschte mir zur Laufzeit wie eine Datei nachladbare Komponenten exakt dann, wenn ich sie verwenden will. Vorher kann die Kompo auch gut auf der Festplatte bleiben.

Das würde die Systemanforderungen der IDE denke ich,doch merklich reduzieren.

Und dann noch kundenspezifische Auslieferung. Nicht die gewaltige Anzahl Komponenten komplett, sondern abhängig von der Branche des Kunden nur die Komponenten, die später im Programmieralltag auch wirklich verwendet werden.

Für die integrierte Hilfe wären mehr Beispielprogramme zum Hilfethema gut und ich könnte kommentierte Demos gebrauchen. Gut ist aber bei den Demos, das ich seie nacheinander übersetzen und starten kann um dann zu sehen, wie man die Komponente verwendet. Nur deren Quelltext in den Demos könnte kommentiert sein.

[schöni]

Zitat:

Zitat von JamesTKirk (Beitrag 1203376)

Zitat:

Zitat von cookie22 (Beitrag 1203369)

OT: Bei CodeTyphon flippt Kaspersky aus und findet mehrere Trojaner.

Immer diese Antivirenprogramme... das beste war vor fast zwei Jahren mal AntiVir, als ich in Delphi Testprogramme für class und record helper geschrieben hab, bei denen es mir auf die Syntax ankam und deswegen der "begin ... end" Block des Programms leer war... bei jedem einzelnen dieser Testprogramm hat es mir erneut gemeckert -.-

Um nochmal auf das bigide zurückzukommen. Ich weiß nicht, ob die bei CodeTyphon was geändert haben, aber beim normalen Lazarus ist das ein Target für make, welches die IDE mit sämtlichen (für die aktuelle Plattform mitgelieferten) Packages kompiliert. Aufgerufen wird das in einem Kommandozeilenfenster folgendermaßen:

Code:

cd c:\dein\lazarus\verzeichnis
make bigide

Ich persönliche aktiviere da allerdings lieber jedes Package von Hand, dann kommt nur das in die IDE, was ich wirklich brauch. :)

Gruß,
Sven

Ist natürlich eine gute Option. Hatte es aber schon,das die Neuübersetzung der IDE fehlschlug.

[cookie22]

Ich bekomm da 1500 mal syntax error und n paar andere Fehler.

[IBExpert]

Vielleicht noch mal was zur Bemerkung von Sebatian und zur ursprünglichen Thematik:

Was mich in der Anfangszeit an Delphi begeistert hat, war zum Beispiel, das es nur relativ wenige Komponenten von Fremdherstellern gab und man trotzdem so ziemlich alles lösen konnte, hier und da mal ein Ownerdraw und schon sieht der Kram so aus wie ich will. Statt irgendeiner bescheuerten Grafikbibliothek setzt man sich 2-3 tage vor den Rechner und zaubert Dinge nach Wunsch auf den Bildschirm, die am Ende genau so aussehen, wie man das haben wollte.

Leider hat sich das im Laufe der Jahre extrem gewandelt. Mit Delphi 8 begann die Katastrophe, irgendwann war man nur noch im Visual Studio Lookalike Wettbewerb, konnte aber elementare Dinge wie Unicode und 64 Bit relativ spät, aus meiner Sicht schon zu spät und viele andere haben diesen Mangel über jahre belächelt und sind zu anderen Plattformen gewechselt.

Mein größtes Problem: Alle 2-3 Version baut man neue Sachen rein und die alten werden (wenn überhaupt) nur sehr begrenzt am Leben gehalten. Die Geschichte der Reportingengine brauchen wir da gar nicht noch mal durchkauen, ob das im Moment ach so tolle Firemonkeyzeugs nicht in 2-3 Jahren das Schicksal von CLX teilt muß jeder selbst entscheiden, ich sehe darin nur den zweifelhaften Versuch, mit einer ehemaligen Open Source Bibliothek GLScene mal eben schnell was in der IDE zu realisieren, was man im marketing ganz doll verkaufen kann. Vor ein paar jahren waren Gestures der Brüller, angeblich hat ja heute jede einen Touchscreen auf dem Schreibtisch, hat sich aber irgendwie nicht durchgesetzt.

Fastreport, Firemonkey und die Integration von Remobjects Produkten machen eigentlich irgendwie das ganze Delphi Problem deutlich: Was kommt eigentlich noch aus dem Hause des Herstellers, das den Gegenwert des Produktes und der nicht gerade billigen Updates darstellt?

Die XE3 Featurematrix hat 16 Seiten, was soll denn so ein Quatsch ....

Weniger ist mehr, vielleicht schaft ja embarcadero noch mal den Absprung vom hirnlosen Featuritis Konzept und committed sich daruf, das man Dinge, wie Sie Daniel zeigt (steinalter Quellcode läuft immer noch) mal als Maxime einzuführen:

Eine ganz banale Kompatibilität aktueller Komponenten und sonstiger Quelltexte zu allen neuen Versionen wäre ein unglaublicher Fortschritt und das würde ganz viele kommerzielle Softwarehäuser deutlich mehr Argumente liefern, neue Delphi Versionen zu kaufen.

Wenn aber ständig sämtliche etablierte Units, Funktionen und Interfaces mal wieder durch den Wolf gedreht werden und compilerschalter nur bis compiler version x gehen, dann werden viele weiterhin bei den alten Versionen bleiben, weil sich jegliche Neuentwicklung nicht rechnet, da diese sich ggf mit jeder neuen Version wiederholt, die man nur aufgrund der dann wieder nicht anpassbaren Komponenten mit aktuellen Delphi Versionen machen müsste.

Wäre doch mal eine gute und neue Marketingstrategie für Entwicklungstools: Eine 10 Jahres Garantie, das alle Komponenten und Quelltexte, die heute in XE3 kompilierbar und benutzbar sind, garantiert auch in Delphi XE13 im Jahr 2023 laufen (ausgenommen natürlich Dinge wie inlineassembler, native dll einbindung und anderes Zeugs, was nie vorhersehbar ist).
Ggf. beschränkt man die Garantie auch auf eine ganz bestimmte Liste von Units und Klassen, für nicht darunter fallende units kann der compiler ggf Warnings raushauen, dann kann man rechtzeitig alternativen finden. Könnte ja auch die Unterscheidung geben zwischen Smallide und BigIDE, Garantie nur für die SmallIDE oder so ähnlich.

Bei so einer Garantie würde ich eventuell sogar noch über eine IBExpert Portierung von Delphi 5 auf eine neue Version nachdenken, insbesondere wenn dann auch noch die fehlende Portabilität behoben wird (Ein lazarus pfad zieh ich mir als Kopie auf USB Stick und starte das auf einem anderen Rechner, ohne irgendwas zu installieren, warum kann Delphi das nicht ...)

Solange das aber nicht der Fall sein wird (und ganz ernsthaft glaub ich aufgrund der Entwicklungen der letzten 10 Jahre da nicht dran), hat Delphi es nicht ganz einfach, angebliche Vorteile gegenüber anderen Plattformen in bare Münze umzusetzen, zumindest bei uns.

[JamesTKirk]

Zitat:

Zitat von schöni (Beitrag 1203382)

Zitat:

Zitat von JamesTKirk

Das verwundert mich schon sehr. Ich habe einen Rechner mit 800 MHz, 1GB RAM auf dem Windows 7 läuft und in zwei Minuten schaffe ich es den kompletten Compiler neu bauen zu lassen (aus der IDE raus).

Diese Aussage betrachte ich als glatte Lüge, Schönmalerei wie sie nur betonköpfige Ideologen fertig bringen, denn ich habe das auf einem 1,7GHz Doppelkernprozessor Intel Atom auf einem Tablet mit 2GByte Ram getestet.

Hey! Beleidigungen müssen nicht sein.

Ich hab jetzt grade den Test auf besagtem Rechner (800 MHz, 1GB RAM) wiederholt. Lazarus Version 1.1, Compiler Version 2.6.0 (und nur um es klarzustellen: kein CodeTyphon). Kalter Festplattencache (jedoch ne SSD). Von Shift+F9 (komplett neu Bauen) bis "Projekt "ppc386" erfolgreich kompiliert" vergingen 1 Minute und 17 Sekunden.

Könntest du als Test ja auch mal probieren. Den aktuellen Sourcecode von Free Pascal herunterladen, das Projekt compiler/pp.lpi in der IDE öffnen und im Menu "neu kompilieren" wählen (in älteren Versionen war der Menüpunkt noch nicht per Default mit nem Tastaturkürzel verknüpft). Da der Compiler keine GUI Komponenten verwendet ist es eine gute Möglichkeit herauszufinden, wie schnell der Compiler an sich ist.

Zitat:

Zitat von schöni

CodeTyphon ist so langsam. Altere Lazarus Versionen schneiden hier besser ab, wohl auch,weil nicht so viel Code mitgeschleppt wird. Deswegen sagte ich ja auch Komponenten besser dynamisch laden zu dem Zeitpunkt wo sie wirklich gebraucht werden. In Delphi wäre das wegen der Packages schon heute möglich. FP müsste wohl dazu um diese Packages erweitert werden.

Wenn du GUI Anwendungen kompiliert, dann könnte das damit zusammenhängen, dass einfach mehr Pfade als Unitverzeichnisse übergeben werden und damit auch mehr Verzeichnisse nach Units durchsucht werden. Allerdings übergibt Lazarus (und hier schließe ich das von CodeTyphon verwendete Lazarus mit ein) nur die Unitverzeichnisse von Packages, die auch direkt oder indirekt von deinem Projekt verwendet werden.
Desto mehr unterschiedliche Verzeichnisse du bei Delphi angibst, desto langsamer wird es übrigens auch dort. Wir haben das zum Beispiel in der Arbeit: da haben wir recht viele Verzeichnisse und die IDE sitzt erstmal etwa ne halbe Minute rum und sucht die Dateien zusammen bis sie dann anfängt die einzelnen Units zu kompilieren (ist übrigens auch so, wenn man mit dcc32 auf der Kommandozeile kompiliert).

Zitat:

Zitat von schöni

Zitat:

Zitat von JamesTKirk

Das Schreiben von Dokumentation ist leider nicht jedermanns Sache und noch dazu enthält allein Free Pascal eine große Anzahl an zusätzlichen Units...

Mag sein, aber ich kann an dieser Stelle nicht aushelfen, nicht weil ich zu faul bin, sondern weil ich so schlicht und einfach die Komponente(n) nicht verstehe, nicht weiß, wie sie zu verwenden ist/sind. Schade eigentlich um die Arbeit derProgrammierer, die die Komponenten gebaut haben, das sind nämlich wirklich gute dabei, wie eben zB. TODBCConnection, denn warum soll ich zur Einarbeitung in die Datenbankproblematik einen extra Server installierenwo doch ODBC in Windows schon drin ist?

Ich hab übrigens gerade das hier gefunden. Ist zwar keine Dokumentation in dem Sinne, vielleicht hilft es aber trotzdem weiter.

Zitat:

Zitat von schöni

Zitat:

Zitat von CCRDUDE

Über den Download-Link auf der Lazarus-Webseite wärst Du entweder bei 0.9.28 oder 0.9.30 gelandet. Bei den ungeraden Versionsnummern steht das deutlich dabei, ich zitiere mal von der Daily Builds-Seite (woanders finde ich aktuell gar keine ungeraden Builds):

Darauf muss man aber erst mal kommen auf der Lazarus Seite zu schauen, wenn man Code Typhon sucht.
Ich bleibeb nun bei Lazarus 0.9.29. Eine spätere Version muss nicht sein.

Ich würde zumindest schauen auf Lazarus 1.0.6 zu wechseln. 0.9.29 ist doch schon ne Weile her... und wie auf der Seite mit den Snapshots erwähnt wird: "der Compiler hat den Code für gut genug befunden". Stabile Releases (wie 0.9.28, 0.9.30, 1.0, 1.0.2, 1.0.4 und 1.0.6) erfahren umfangreichere Tests als die Entwicklungsversionen.

Zitat:

Zitat von cookie22 (Beitrag 1203387)

Ich bekomm da 1500 mal syntax error und n paar andere Fehler.

Vielleicht ist das ein weiterer Grund, warum ich bigide nicht verwende... da werden nämlich auch Komponenten mitkompiliert, die nur selten verwendet werden.

Gruß,
Sven

[Codehunter]

Wer meine Posts und Fragen in den letzten Wochen verfolgt hat weiß, dass ich mich grade durch XE2 kämpfe (D7 steht nicht ohne Grund noch in meinem Profil). Der ursprüngliche Beweggrund für die Anschaffung war der 64 Bit Compiler. Diese "64" ist irgendwie magisch, alles munkelt und raunt darüber, dass es so ganz viel doll besser ist. Nicht dass mir nicht bewusst gewesen wäre, dass 64 Bit für meine Programme keinerlei Vorteil bringt. Vielmehr ist es so, dass meine Abnehmer zum Teil schon mit leicht gerümpfter Nase die 32 Bit zur Kenntnis nehmen.

Nach allen Erfahrungen die ich bsi jetzt mit XE2 machen durfte kann ich für mich persönlich das "ideale" Delphi recht knapp zusammenfassen: Man nehme den aktuellen Compiler und verpflanze diesen in die D7-IDE. Lediglich die Projektverwaltung und die Toolpalette (letztere aber besser bedienbar als jetzt) würde ich aus der neueren IDE backporten. Alles andere kann in die Tonne - vorallem die jetzige Onlinehilfe.

Dass man irgendwann von der RTF- auf die HTML-basierte Hilfe gewechselt ist kann ich ja noch verstehen. Aber warum musste man die bewährten Linkpfade so über den Haufen werfen? "Embarcadero Technologies verfügt zurzeit über keine zusätzlichen Informationen." scheint wirklich das Leitmotiv der jetzigen Hilfe zu sein.

Das eigentliche Drama ist aber, dass sich bei Emba anscheinend niemand mehr Gedanken um die Bedienbarkeit der IDE macht. Was soll ich mit einem "Struktur"-Fenster, bei dem sämtliche Einträge Full-Expanded sind und diese auch bei jeder erdenklichen Gelegenheit wieder aufklappen, selbst wenn man sie mühsam geschlossen hat. Was soll ich mit einer Toolpalette, die bei jedem Fensterwechsel hin und her zappelt? Und so weiter und so weiter.

Wenn man von D7 auf XE2 umsteigt, dann ist das manchmal wie ein Hieb mit einer Keule. Ich kann mir aber vorstellen, wenn man den ganzen Weg dahin von D8 angefangen mitgemacht hat, dann ist das wie der berühmte Frosch, den man ins kalte Wasser setzt und den Topf auf den heißen Herd stellt.

Meine Meinung: Dephi mag zwar schon seit 18 Jahren sterben aber Emba ist inzwischen schon "toter" als sein Produkt. Die Firma kann es einfach nicht.

[greenmile]

Zitat:

Zitat von Codehunter (Beitrag 1203438)

Meine Meinung: Dephi mag zwar schon seit 18 Jahren sterben aber Emba ist inzwischen schon "toter" als sein Produkt. Die Firma kann es einfach nicht.

Das unterschreibe ich nicht, Borland war da erheblich schlimmer.

Es sind aber grundlegende Dinge, die so nicht funktionieren. Ich kann doch nicht allen ernstes ein Produkt (XE2) damit bewerben, dass ich endlich performante Produkte für iOS/Mac entwickeln kann, wenn die alles andere als performant sind, völlig ab davon völlig instabil laufen.

Dieselben Kunden schreibe ich dann an, weil es mit der nächsten Version (XE3) stabiler und schneller läuft (nicht schnell, aber gegenüber XE2 ist das tatsächlich ein Meilenstein), dafür soll er aber bitte (mal wieder) bezahlen, außer er hat eine SA. Der Kunde muss quasi ein Bugfix bezahlen. Blöderweise funktioniert hier und da etwas nicht mehr, so dass man, obwohl man auf dieselbe Plattform setzt, wieder vieles korrigieren, weil es das in FM2 nicht mehr gibt bzw. anders implementiert ist. Auf der einen Seite habe ich also ein endlich halbwegs performantes Firemonkey, auf der anderen Seite wurde mir aber iOS wieder genommen.

Ich muss also 1 x extra für XE3 bezahlen (damit es halbwegs läuft) + 1 mal MobileStudio (wegen iOS), damit ich das erreiche, was mir in XE2 versprochen wurde. Wie geil ist das bitte? 2 mal zusätzlich zahlen, XE2 hat mich also > 2000-3000 EUR gekostet, wenn ich XE3+MS dazurechne.

Dann kommt zwischendurch ein Update, obwohl das ja regelmäßig kommen soll (Werbung) und ich freue mich wie ein kleines Kind, dass da vielleicht endlich mal (peinliche) Fehler behoben wurden und was kommt? Ein Lacher. Ich war wirklich stinksauer als ich die Fix-List gelesen habe.

@Embar:
Vielleicht liest ja jemand (außer Matthias) mit, aber die User sind fast alle durch die Bank weg sauer. Würde FPC/Lazarus soweit sein, wären die User (und damit auch Euer Umsatz!) weg. Es ist vielleicht an der Zeit, über ein sehr vergünstigtes Update in Sachen MobileStudio nachzudenken, um die User milde zu stimmen.

[Codehunter]

Zitat:

Zitat von greenmile (Beitrag 1203446)

Es ist vielleicht an der Zeit, über ein sehr vergünstigtes Update in Sachen MobileStudio nachzudenken, um die User milde zu stimmen.

Ich finde, das würde zu kurz greifen. Mich z.B. interessiert MobileStudio herzlich wenig obwohl ich mich über die Bugs in der IDE genauso ärgere.

[cookie22]

Zitat:

Zitat von Codehunter (Beitrag 1203438)

...Nach allen Erfahrungen die ich bsi jetzt mit XE2 machen durfte kann ich für mich persönlich das "ideale" Delphi recht knapp zusammenfassen: Man nehme den aktuellen Compiler und verpflanze diesen in die D7-IDE...

Arbeite mal eine gewisse Zeit mit XE2, dann steht Delphi 7 nicht mehr zur Debatte. ;)

[Codehunter]

Zitat:

Zitat von cookie22 (Beitrag 1203474)

Arbeite mal eine gewisse Zeit mit XE2, dann steht Delphi 7 nicht mehr zur Debatte. ;)

Hahahahaaa :-D Ich greife selbst wenn ich mit XE2 arbeite immernoch auf die Hilfe von D7 zurück, einfach weil die schneller zu Potte kommt.

Ich arbeite jetzt schon knapp ein halbes Jahr mit XE2 aber es kommt dabei weder Freude noch ein gleichmäßiger Arbeitsfluss auf.

[greenmile]

.... Was bei mir aber eher an den Änderungen intern liegt. Beispiel: Uppercase mit Umlauten geht nicht 1:1 etc.

[p80286]

Zitat:

Zitat von Codehunter (Beitrag 1203485)

Hahahahaaa :-D Ich greife selbst wenn ich mit XE2 arbeite immernoch auf die Hilfe von D7 zurück, einfach weil die schneller zu Potte kommt.

Und weil es da so etwas wie "siehe auch da" gibt.
Was hab ich von einer Hilfe die mir erklärt, daß ein Eierkocher Eier kochen kann, Aber nicht erwähnt daß Wasser einzufüllen ist, die Eier in den Halter gesteckt/gelegt werden und daß das Gerät eingeschaltet werden muß.
Und wenn dann noch kommt "nicht vergessen, den Stecker in die Steckdose stecken, möglichst vor dem Einschalten", dann ist die Hilfe auf dem Niveau von D7.

Gruß
K-H

[stahli]

Die aktuelle IDE von Delphi finde ich grundsätzlich schon ganz gut.

Mit der Hilfe habt Ihr aber sowas von Recht. Ich fand die von D7 auch noch besser bedienbar aber die eigentliche Katastrophe ist heute der weitestgehend fehlende Inhalt.

[Wunni]

Zitat:

Zitat von stahli (Beitrag 1203495)

Die aktuelle IDE von Delphi finde ich grundsätzlich schon ganz gut.

Mit der Hilfe habt Ihr aber sowas von Recht. Ich fand die von D7 auch noch besser bedienbar aber die eigentliche Katastrophe ist heute der weitestgehend fehlende Inhalt.

die Hilfe ist aber nicht das ganz große Problem, da es im Internet sehr viele Informationen und Tutorials gibt.

Im mobile Bereich gibt es schon so viele Entwicklungsmöglichkeiten, da versteh ich es nicht, dass die Kapazitäten der Entwicklung für ein "Mobile Studio" verschwendet werden! Sollte man nicht erstmal die bereits halbfertig verkauften Produkte rund machen?

Jedes Jahr ein neues, halbfertiges Produkt auszuliefern und die Unterstützung der Vorversion dann sofort einzustellen ist für mich ein Grund, vollständig auf Delphi zu verzichten!

[greenmile]

Zitat:

Zitat von Wunni (Beitrag 1203503)

Im mobile Bereich gibt es schon so viele Entwicklungsmöglichkeiten, da versteh ich es nicht, dass die Kapazitäten der Entwicklung für ein "Mobile Studio" verschwendet werden!

Als da wären? Gibt es eine Norm für iOS, Android, Windows, ...? Also, ich kenne keins oder kein vernünftiges. Und nun bitte kein HTML5/FPC geflame.

Zitat:

Zitat von Wunni (Beitrag 1203503)

Sollte man nicht erstmal die bereits halbfertig verkauften Produkte rund machen?

Ein deutliches JNEIN. Bugfix schon, aber die einzige Zukunft, die Delphi hat, ist in meinen Augen die mobile Welt. Microsoft hat lange genug versucht dass zu ignorieren und ob man nun Windows 8 mag oder nicht, es war mehr als sinnvoll und notwendig. Genauso sieht es in meinen Augen mit Delphi Mobile aus. Desktop Anwendungen sind nett, werden aber in Zukunft vielleicht 60-70% ausmachen. Nicht auf mobile zu setzen ist, sorry, saudumm. Und Mobile (Tab's und co) ist auch kein Hype wie .NET, siehe die aktuellen Verkaufsstatistiken nahezu aller PC Hersteller.

Die VCL ist ausgereift und im Gegensatz zu FM brauche ich dafür auch kaum eine neue Version, geht zu 95% auch mit älteren Versionen. Was nützt mir aber die VCL unter iOS, wenn iOS damit nix anfangen kann? Dann kann ich auch gleich bei Delphi 7 oder sonstwo bleiben. Ich will und brauche Mobile ASAP, um auch morgen noch Geld zu verdienen. Egal ob mir das passt oder nicht, ist leider Realität/Fakt.

[musicman56]

Zitat:

Zitat von greenmile (Beitrag 1203515)

...Ich will und brauche Mobile ASAP, um auch morgen noch Geld zu verdienen. Egal ob mir das passt oder nicht, ist leider Realität/Fakt.

Yepp, so sieht's für viele andere auch aus. Ich persönlich kann nichts anderes als Pascal/Delphi und die nächsten knapp 10 Jahre bis zur Rente wird das wohl so bleiben :oops:

[p80286]

Zitat:

Zitat von Wunni (Beitrag 1203503)

die Hilfe ist aber nicht das ganz große Problem, da es im Internet sehr viele Informationen und Tutorials gibt.

Diese Argumentation kann ich schon nicht mehr hören. Mann stelle sich vor, man kauft sich einen VW/Opel/Daimler/Toyota/Peugeot/.... und auf die Frage "wo ist die Bedienungsanleitung" kommt "Da finden sie im Netz genügend".
Das stimmt für denjenigen, der weiß wonach er suchen muß. Wem das richtige Stichwort fehlt, oder besser Textteil, der wird nie etwas finden.

Gruß
K-H

[Sherlock]

Drollige Diskussion! :D
Ich frag mich immer was die ganzen Bullshit-Bingo-Spieler ;) des OOP noch hier im Delphi-Forum suchen, wenns woanders doch so viel schöner und trendiger ist. also kommt mal allesamt wieder vom hohen Ross runter. Delphi lebt, am Marketing lässt sich aber noch viel verbessern.

Sherlock

[greenmile]

Ich denke es ist die (hoffnungslose) Hoffnung, dass es etwas in den Köpfen bei Embarcadero bewirkt.

[MrSpock]

Zitat:

Zitat von Sherlock (Beitrag 1203558)

Drollige Diskussion! :D
Ich frag mich immer was die ganzen Bullshit-Bingo-Spieler ;) des OOP noch hier im Delphi-Forum suchen, wenns woanders doch so viel schöner und trendiger ist. also kommt mal allesamt wieder vom hohen Ross runter. Delphi lebt, am Marketing lässt sich aber noch viel verbessern.

Sherlock

:thumb:

[sx2008]

An der fehlenden / kaputten Hilfe von Delphi ist übrigens Microsoft nicht ganz unschuldig.
Früher gab es WinHelp (*.hlp) Dateien, danach kam HTML-Help (*.chm).
Im Jahr 2001 began MS die Entwicklung von WinHelp2 und setzte das neue Format für Visual Studio ein.
Anfang 2003 gab Microsoft bekannt, dass WinHelp2 nun doch nicht die neue Hilfeplattform werden soll.

Aber Boland hatte ihr Hilfeformat schon umgestellt (allerdings mehr schlecht als recht).
Vielleicht erinnern sich noch einige an den verbuggten Microsoft Document Eplorer (dexplore.exe),
den man immer per Task Manager abschiesen musste.
Microsoft verwendet inzwischen AP Help 1.x und 2.0; wieder ein anderes Format.
Ach ja, und DotNetHelp gibt es auch noch.

Embacadero bzw Codegear hat so reagiert, dass die Hilfe als Wiki oder auch PDF angeboten wird.
http://docs.codegear.com/products/rad_studio/
Das ist aber kein Ersatz für ein funktionierende, lokale, kontextsensitive Hilfe.

[stahli]

[leichte Ironie]
Eine komplette kontextbezogene Hilfe wäre doch ein super (Ver-)Kaufsargument für XE4! ;-)
[/leichte Ironie]

Ernsthaft würde es Emba (langfristig gesehen) gut tun, endlich mal die ganzen Probleme zu bereinigen und dieses Jahr auf eine neue SuperDuper-Version mit halbgarem bunten Schnickschnack zu verzichten.

Einfach die Basics und das bereits versprochene nachliefern und gut ist...

[Elvis]

Zitat:

Zitat von greenmile (Beitrag 1203515)

Als da wären? Gibt es eine Norm für iOS, Android, Windows, ...? Also, ich kenne keins oder kein vernünftiges. Und nun bitte kein HTML5/FPC geflame.

Mittlerweile fast sowas wie ein defakto Standard für mobiles XPLatform: http://xamarin.com

Eine elegante Sprache/Runtime (also kein Java, kein ObjC), aber trotzdem vollen Zugriff auf alle APIs der jeweiligen Plattform.

[BUG]

Zitat:

Zitat von Elvis (Beitrag 1203584)

Mittlerweile fast sowas wie ein defakto Standard für mobiles XPLatform: http://xamarin.com

Standard: Ich weiß nicht ... wenn ich mobile und cross-plattform höre, fällt mir als erstes Phonegap ein.
Die größere Verbreitung mag aber auch am Preis liegen :stupid: Xamarin sieht ziemlich interessant aus.

Allerdings dürfen dann die native-Fetischisten zwischen C#/mono (Xamarin) und Javascript/HTML (Phonegap) wählen :mrgreen:

[mschaefer]

Unter Delphi gibt es auch noch Möglichkeiten:

Spannend finde das UniGui-Projekt. Mit dem hohem Anteil gleichen Codes für den Webserver, als auch den Dektop zu programmieren, das könnte viel Zeit sparen. Sowohl bei der Programmierung, als auch bei der Einarbeitung von Entwickler und Endanwender.

Grüße in die Runde // Martin