Ist Delphi so Bedeutungslos ?

[cookie22]

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

[Phoenix]

Zitat von Wunni:

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 von IBExpert:

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 von Phoenix:

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.

[JamesTKirk]

Zitat von cookie22:

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 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 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 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 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 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 von JamesTKirk:

Zitat von cookie22:

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 von schöni:

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 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 von schöni:

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 von schöni:

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 von cookie22:

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