|
AW: Unbeliebtheit von Delphi
Für alle Schüler und Studenten, die sich hierher verirren, weil sie vielleicht überlegen, doch mit Delphi anzufangen: Ausnahmsweise haben Uwe Raabe und Dummmzeuch mal nicht recht. "Sic" heißt (heute) nicht "so" oder "so isses". Sic hat eine sehr spezifische und etwas unerwartete Bedeutung, die im
 Wikipedia-Eintrag ja auch richtig beschrieben wird. Es steht in aller Regel hinter einem scheinbar falschen oder ungewöhnlichen Wort/Ausdruck und die Bedeutung ist: "Nein, das ist kein Versehen, das ist mir Absicht so". |
AW: Unbeliebtheit von Delphi
Zitat:
Sehr große und sehr erfolgreiche Firmen arbeiten damit, auch manche wo man nicht damit gerechnet hätte. Ich denke Delphis "Schwäche" ist seine Effizienz. Mit diesem Werkzeug kann man in kürzerer Zeit, mit weniger Leuten Projekte realisieren, die mit anderen Tools die Zeit grosser Teams verschlingen würde. Die erzeugten Projekte laufen immer zuverlässig, da keine Runtime Abhängigkeiten bestehen. Und dann gibt es ausgereifte Komponenten, die zur Not auch selber gewartet werden können. Ich finde die Entwicklung von Embarcadero sehr gut, 10.3 Rio ist ausgesprochen stabil. Schade finde ich, dass der Linux Compiler nur in der Enterprise Version enthalten ist, womit es sich nicht loht, dafür Komponenten zu entwickeln. Was wiederum die Attraktivität der Platform reduziert ... |
AW: Unbeliebtheit von Delphi
Delphi und Alt ?
Im Vergleich zu was den ? C++ ? Das wurde 1979 entwickelt (Quelle: Wikipedia), während Object Pascal 1986 durch Borland entwickelt wurde (Quelle Wikipedia). Klar gibts jüngere Programmiersprachen (Phyton z.B.). Aber d.h. nicht unbedingt das sie gut sind. Ich hab einige Jahre als Webentwickler gearbeitet (mit PHP, Javascript und HTML). Einzig PHP kommt hier an die Möglichkeiten von Object Pascal ran. Die Lesbarkeit von Code hängt imho von 2 Faktoren ab: a) Wie lange arbeitet ein Programmier schon mit der Sprache. Je länger du mit einer Syntax arbeitest, desto vertrauter ist sie dir, und desto leicher ließt du den Quelltext. b) Die Syntax an und für sich. Da Object Pascal sehr "ausführlich" ist, fällt es einem leichter Quelltext zu lesen, dafür muss man etwas mehr tippen. Sprachen die sich syntaktisch an C orientieren sind hier natürlich etwas im Nachteil, da C für "Tipfaule" entwickelt wurde und dementsprechend weniger tiparbeit erfordern. |
AW: Unbeliebtheit von Delphi
Wenn es um die Delphi-IDE geht..die kann doch gar nicht unbeliebt sein. Die ist schon seit langem die Beste, die es gibt. Schon mal einer Visual Studio von Microsoft gesehen/verwendet? Absolute Vollkatastophe.
Geht es um die Sprache Object Pascal, dann kann etwas, was keiner kennt, weder beliebt noch unbeliebt sein. Mit keiner meine ich Schüler und Studenten. Denen werden Java, C++, C#, Python usw. reingeprügelt, aber kein Pascal. Das ist der Bereich, wo auch Embarcadero absolut verpennt hat. Mit folgendem Kommentar wurde eigentlich schon alles auf den Punkt gebracht: Zitat:
|
AW: Unbeliebtheit von Delphi
Ich denke man sollte vielleicht sogar den letzten Schritt gehen und alle Entwicklungsumgebungen außer Delphi verbieten. Manchmal muss man die Leute auch vor sich selbst schützen.
|
AW: Unbeliebtheit von Delphi
Zitat:
Zitat:
Und wenn sich der Code flüssig liest, ist die andere Syntax drittrangig ;-) Zitat:
Ich sehe es eher andersherum, zum Beispiel die {} statt begin end sind viel besser für die Lesbarkeit, weil sie weniger vom Wesentlichen ablenken. Auch wenn Strg+Alt+0 nicht so praktisch zu erreichen ist. Zitat:
|
AW: Unbeliebtheit von Delphi
Zitat:
Insbesondere wenn die Leute sich im Team nicht einig sind ob die öffnende Klammer in eine eigene Zeile kommen soll oder nicht. Aber dieses Problem hat man immer, egal welche Synthax. |
AW: Unbeliebtheit von Delphi
Zu den Argumenten eingangs:
Zitat:
Zitat:
Zitat:
Ansonsten verweise ich auf PySide und wxPython ... Zitat:
Zitat:
Was ich auch unpraktisch fand, war die Anforderung C-Header übersetzen zu müssen. Vielleicht - bzw. hoffentlich - gibt's da ja auch seit XE Fortschritte. Kurzum: für eine bestimmte Sorte von Anwendungen ist Delphi aus meiner Sicht noch immer sehr gut geeignet, bei anderen eher nicht. Zitat:
Zitat:
Mittlerweile finden es die Leute ja geil sich mit Opera, Atom, Visual Studio Code, Riot IM, Google Chrome und dem Slack Client (um nur ein paar wenige Vertreter zu nennen) quasi dutzendfach den gleichen Code in ihr Benutzerprofil zu installieren. Vor ein paar Jahren hielt man DLLs als Mittel der Wahl um den gleichen Code aus verschiedenen Anwendungen heraus zu nutzen, noch für das A und O. Die Zeiten ändern sich halt. Allerdings hat Electron eben auch zu Auswüchsen geführt bei denen mittlerweile Systemsoftware mit Systemrechten nen Chromium-Unterbau ausführt. Da kommt mir das kalte Kotzen.Falls du jemals einen kleinen Einblick in das Tagesgeschäft eines Admins bekommen solltest, wird dir die Begeisterung für Anwendungen die sich per Copy&Paste installieren lassen schnell im Halse stecken bleiben. Es hat halt seine Vor- und Nachteile, je nach Einsatzgebiet. Zitat:
Zitat:
Schonmal versucht meinen nonVCL-Code in neueren Delphi-Versionen zu bauen? Viel Erfolg! Andererseits kann ich gemütlich C-Code aus den 1990ern meinem C-Compiler füttern und der spuckt mir dafür sogar Objektcode aus. Gut, Warnungen gibt es dann durchaus hin und wieder ... Zitat:
Zitat:
Die meisten Anwender die Git benutzen sind meiner Erfahrung nach Stümper in Sachen Git (== keine Grundkenntnisse), die nach diesem Schema verfahren, aber es muß dennoch unbedingt Git sein und ja kein anderes VCS.Zitat:
Zitat:
Auch sollte jedem Entwickler klar sein, daß auf die Lebenszeit der Software betrachtet nicht auf die Erstentwicklung sondern für die Langzeitpflege hin optimiert werden sollte. Stichworte: Dokumentation, Tests, Änderungsverwaltung, Trennung von Abstraktionsebenen mit "internen" Schnittstellen ... Zitat:
Ein wenig Distanz zu wahren zu der neuesten Programmiermethoden/-sprachen-Sau die gerade durch's Dorf getrieben wird, ist sicher richtig. Aber der ehemalige Vorgesetzte der auch nach 20 Jahren noch mit dem Compiler von 1996 arbeitete und einen Programmierstil hatte, der mit "Assembler-artig" und "1980er" wohlwollend umschrieben wäre, hat dennoch den Fortschritt in der Codebasis auf ganzer Linie behindert. Wenn ich halt großflächiges Refactoring machen möchte, muß man manche liebgewonnenen Gewohnheiten aus DOS-Zeiten auch mal aufgeben. Hier war es bspw. die Unsitte über Defines und einen zentralen Header zu steuern was eingebunden wird. Zu DOS-Zeiten durchaus sinnvoll um eine damals übliche Größenbeschränkung zu umgehen. Heute eher überkommen und hinderlich. Solche Dinosaurier, die mental ihre Kenntnisse auf ihrem eigenen Fachgebiet nie merklich ausgebaut haben, habe ich schon mehrfach in meiner Karriere kennengelernt. Noch hoffe ich, daß ich frühestens mit Renteneintritt auch in diese Dinosaurierphase eintrete. Ich finde es aber wenig tröstlich, daß Uni-Abgänger eine ähnliche Ignoranz an den Tag legen wie die sprichwörtlichen Dinosaurier. Zitat:
Zitat:
Aber wir leben ohnehin in einer Zeit in der das nächste Quartalsergebnis (manchmal sprichwörtlich, manchmal nicht) wichtiger ist als eine langfristige und nachhaltige Wertschöpfung. Zitat:
Manch einer kann sich das kaum vorstellen, aber Sprachen und Editoren sind überhaupt nicht über Naturgesetze unzertrennlich aneinander gebunden. Und ich verdrehe jedesmal die Augen wenn mein Vorgesetzter sich drüber beschwert daß diese oder jene Funktion des Debuggers in Eclipse nicht funktioniert. Da zücke ich dann Vim, GDB und einen Terminal-Multiplexer und lasse diese nervige Entwicklungsumgebung hinter mir. Zitat:
Selig sind, die da nehmen und nicht zurückgeben! Jupp, vermutlich ist das im Prinzip ganz einfach, wobei du hier auch ein wenig Architekturanalyse und statische Codeanalyse zum Auffinden häufiger Fehler durcheinanderzuwürfeln scheinst.Zitat:
Zitat:
war es Vorreiter.Da spielt dann wohl auch immer persönlicher Geschmack und der Unwille sich mit neuen Themen auseinanderzusetzen eine Rolle. Zitat:
Zitat:
Zitat:
Zitat:
Ich nutze seit über 15 Jahren ausschließlich eine US-Tastatur mit alternativem Layout (sprich, ich kann ohne Probleme ß, ö, ü, ä, æ, å, ø, ł, ð, ć, ę, ż, ý, ą, ©, ®, ™, ï, ᵹ, ń, μ, ℔, ś, ſ, ƿ, é, ¾, ¼, ½, ℅ usw. tippen ... und zwar sowohl auf Linux wie auch auf Windows) und möchte es nicht mehr missen. Probier's mal aus! Das entsprechende Mercurial-Repo ist derzeit offline, da Bitbucket bekanntlich die Unterstützung auslaufen läßt, aber demnächst ist es dann wieder online. Schick mir ne PN, falls Interesse besteht. Was hilft mir begin/end statt {/} wenn ich am Ende in JSON oder YAML oder wo auch immer doch wieder mit geschweiften Klammern konfrontiert bin?! |
AW: Unbeliebtheit von Delphi
Zitat:
|
AW: Unbeliebtheit von Delphi
Zitat:
Wenn solche Preise für eine Firma zu hoch (!) sind, ist mir das etwas suspekt ehrlich gesagt. Also man kann ja nun viel gegen Delphi sagen, unter anderem, dass man Einsteiger lange eher abgeschreckt hat. Und auch, dass die Qualität lange Jahre vernachlässigt wurde. Aber die Preise sind nun wirklich nicht hoch, wenn man nicht gerade mit kostenlosen Open Source Tools vergleicht. An der Stelle sollte man aber eben als Softwareentwickler auch bedenken, dass man ja auch möchte, dass andere die eigene Arbeitsleistung bezahlen. Zitat:
In unseren aktuellen, auch größeren, Projekten läuft die IDE sehr gut und so gut wie ohne merkliche Verzögerungen. Abstürze z.B. beim Debuggen wie sie unter XE6 quasi normal waren gibt es hier quasi gar nicht mehr. Leider kommt Delphi mit Kreuzbeziehungen in den Units, aber auch exotischen Formatierungen und teilweise auch mit manchen Benennungskonventionen nicht gut klar, wenn man Refactoring oder auch nur die Klassenvervollständigung nutzen möchte. Hier lohnt es durchaus den Quelltext zumindest etwas zu modernisieren um dann effizienter arbeiten zu können. // EDIT: Ach ja, ein Bug fällt mir dabei ein: Wenn man etwas markiert hat, dauerte der Wechsel zu anderen Units und zurück recht lange, derweil hing die IDE. Deshalb entferne ich mittlerweile quasi unbewusst automatisch immer eine eventuell gesetzt Markierung ohne darüber nachzudenken. |
AW: Unbeliebtheit von Delphi
Zitat:
Ich hab da übrigens andere Preise in Erinnerung. Vielleicht ist das aber der Unterschied zwischen Delphi Solo vs. "Studio" (also mit C++ Builder)? Und gerade im Vergleich zu einem MSDN Pro Abo mit anschließend erlaubter Weiternutzung der Software, fand ich das Preisniveau der Produkte rund um Delphi nicht angemessen. Insbesondere aufgrund der Probleme die zum Teil über mehrere Versionen hinweg mitgeschleppt wurden. Und wenn ich dann eben noch Klimbim mitbezahle, welchen ich nicht brauche, trägt dies nicht zur Akzeptanz der Preise bei. Die "Lösung" für Embarcadero war dann auf eine Art Abomodell umzuschwenken. Nur einen kleinen Unterschied gibt es zu dem erwähnten MSDN Pro Abo. Die Betriebssysteme und auch Visual Studio daraus wurden/werden auf Jahre hinaus gepflegt. Embarcadero schien etwa mit XE auf ein Modell umzustellen, welches als "Was juckt mich meine Software von gestern" umschrieben werden kann. Mag jetzt etwas überspitzt formuliert sein, aber da ich mir XE tatsächlich noch (als RAD Studio) geleistet hatte, fühlte ich mich doch etwas vor den Kopf gestoßen als Fehlerbehebungen (!) - also nicht etwa neue Features - für die jeweils nicht mehr taufrische Version auf den Sankt-Nimmerleinstag verschoben wurden. Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Achso, eins noch. Ich würde behaupten Delphi erfreut sich in diversen Kreisen nach wie vor großer Beliebtheit. Also bitte nicht meine Kritik als pauschale Klatsche mißinterpretieren. |
AW: Unbeliebtheit von Delphi
Zitat:
Das hat sich aber ja wenigstens mittlerweile geändert. Zitat:
Zitat:
|
AW: Unbeliebtheit von Delphi
Ich würde lügen, wenn ich behauptete ich/wir hätte(n) kein gutes Geld mit Delphi verdient, und unsere Investitionen darin wären bisher verschwendet gewesen. Ein nicht unwichter Aspekt dabei ist jedoch, dass Delphis Einsatz hier zu weit überwiegendem Anteil eine "Legacy-Entscheidung" ist - nichts weiter.
Mein Vater hat in den späten 80ern angefangen, Industrie-Visualisierungen mit Turbo Pascal zu entwickeln. Nebst einer Toolchain für die von seiner Firma selbst entwickelte SPS-Lösung, welche aber seit Einführung von Siemens S7 nicht mehr existiert. Als die Welt in Richtung Windows wanderte, hat er "naturgemäß" versucht den Großteil seiner Bibliotheken via Delphi in diese neue Welt zu überführen, was auch lange Zeit ausreichend war. Insbesondere wegen des damaligen Alleinstellungsmerkmals des extrem mächtigen Formular-Designers. Dann kam ich irgendwann in das Unternehmen. Vater noch einer der ersten Informatik-Absolventen, als es noch größtenteils E-Technik war, kam ich auf einmal mit OOP, SQL und Tonnen an Idealismus daher. Aber man kann ja nicht grad eine über 20 Jahre gewachsene Infrastruktur am Stück modernisieren - also musste dasselbe Werkzeug ran, welches ich von Kind auf, privat, ohnehin schon immer auch mit erlernt hatte. Und von da an Stück für Stück ans Werk. Was aber auch heißt: Auch meine "Legacy" ist in Delphi verfasst. Das hat mich lange Zeit auch überhaupt nicht gejuckt! Gerade in der Industrie ist es eher schon ein Mehrwert "alte" (sprich: bewährte) Dinge einzusetzen, und die gesamte Branche kann man gut als ~10 Jahre "hinterher hinkend" bezeichnen. Das kam, so leid es mit tut, Delphi für uns zu Gute. Wir haben ewig D7 eingesetzt, dann irgendwann D2007, was bis vor ~2 Jahren unser Arbeitspferd war. Beziehungsweise größtenteils noch immer ist! Was traurig ist. Vor rund 2-3 Jahren musste ich mir Gedanken dazu machen, mit welchem Tool es bei uns weiter gehen soll. Ich war damals drauf und dran Delphi den Rücken zu kehren, mit 2-3 Alternativen für die ich ein komplettes Rework unserer gesamten Codebase in Kauf genommen hätte. Wäre da nicht EMB mit FMX und LiveBindings, sowie "weniger als zuvor" schlechten Meldungen bzgl. IDE Stabilität am Start gewesen. Aber hier ist der Knackpunkt: Hätte ich damals gewusst, in welch desolatem Zustand genau diese Dinge waren (und bis heute sind), und wie inakzeptabel die jeweiligen Dokus sind, hätte ich damals den Schwenk Richtung C# bzw. eine seiner Abarten vollzogen. Mit all der Arbeit, die damit verbunden wäre, inklusive des Zurücklassens der 3rd Party Software, die wir nutzen. Da in den letzten Monaten kaum Luft war sich hier erneut Gedanken zu machen, ist es halt noch immer Delphi. 90% Pflege aktiver Produkte mit D2007, und 10% verzweifelte Versuche die gewünschte Funktionalität mit D10.2.3, FMX und LB zu erreichen. Hätte ich die Zeit und Entwicklerkapazität, würde ich Delphi ohne mit der Wimper zu zucken in die Tonne treten und alles komplett mit einem wirklich modernen Toolset von Grund auf neu entwickeln. Subscription-Modell, allgemeine Qualität und die fortwährend schrumpfende Community sind extrem starke Argumente gegen Delphi. Ich bin letztlich noch dabei weil ich muss. Und auch ein wenig, weil ich die Sprache an und für sich gerne mag. Aber letzteres allein rechtfertigt diese Affinität nicht mehr. Das tun derzeit rein geschäftliche Faktoren. Es liegt einfch zu viel im Argen, und so schnell lasse ich mich nicht mehr von aussichtsreichen Features ködern. Da muss im Kern einfach mehr kommen. Gerade für den Preis, gerade weil es ein Nischenprodukt ist. Hier MUSS Exzellenz her, sonst hat es sich mit der Daseinsberechtigung. Dafür können andere mittlerweile einfach zu viel zu gut. Und ganz im Ernst: Ich fühle mich zunehmend unwohl im Tagesgeschäft von Delphi abhängig zu sein. Ich hoffe bald die Luft zu haben, nochmals eine Umstellung in Angriff zu nehmen. Am liebsten natürlich auf eine total geniale super stabile moderne und adäquat supportete Delphi-Inkarnation - aber darauf warte ich nun schon fast 20 Jahre. Hoffnung habe ich nicht mehr. Nur noch Notwendigkeit. Was ich extrem schade finde. |
AW: Unbeliebtheit von Delphi
Mir geht es ähnlich.
Geld habe ich mit Delphi kaum verdient. D4, D7 und XE fand ich super und habe gern dafür bezahlt. Dann habe ich mich total auf XE3 gefreut, wegen FMX und LB. Totaler Reinfall. 1.600 Eu umsonst bezahlt. Ein Ausflug in andere Umgebungen hat mich aber auch ernüchtert. Consolenprogrammierung mit npm usw. kommt für mich nicht in Frage. WPF/Silverlight war mir zu umständlich. WinForms, ASP, MVC gingen vom Ansatz her aber mit Datenbanken kam ich unter VS gar nicht vernünftig klar. Also habe ich mich entschieden, mit meinem XE3 weiter zu arbeiten, bis es jetzt eine CE-Version gab. Die ist m.E. schon sehr gut - wenn man sich die ganzen Probleme und Bugs wegdenkt. Also Delphi in (weitestgehend) fehlerfrei wäre schon richtig gut. Im aktuellen (fehlerbehafteten) Zustand würde ich dafür kein Geld ausgeben - jedenfalls nicht, wenn der Betrag nicht gerade bei mir in der Portokasse rumliegt. |
AW: Unbeliebtheit von Delphi
Zitat:
Ist ja toll für den der keine Probleme hat, für die die Probleme haben aber schon. Zitat:
Die Entwickler bei uns die auch regelmässig VS benutzen, machen das lieber (sofern es sich dann um C# und nicht um C++ handelt) |
AW: Unbeliebtheit von Delphi
Zitat:
Zitat:
Zitat:
|
AW: Unbeliebtheit von Delphi
Ich war mal absoluter Fan von Delphi (das fing mit Delphi 3 an und hielt sich bis ca. Delphi 7). Dann kam die Zeit, wo man den Eindruck hatte, Delphi sei stehengeblieben und alles andere entwickle sich weiter. Das war zwar falsch, wie ich derzeit immer wieder feststelle, wenn ich irgendwas rückwärtskompatibel zu diversen Delphi-Versionen machen will, aber die Entwicklung war relativ langsam und vor allem waren neue Features gerne erstmal extrem fehlerbehaftet. Auch die Weiterentwicklung der IDE ging meiner Ansicht nach einige Zeit den falschen Weg, alles mögliche einzukaufen (auch gerne Tools, die nicht in Delphi geschrieben waren), es dann auf Biegen und Brechen einzubinden und schließlich, die Leute die das Feature kannten und warten/weiterentwickeln konnten, gehen zu lassen oder aktiv loszuwerden. Der Qualität und Stabilität der IDE tat das alles andere als gut. Das scheint sich in letzer Zeit wieder geändert zu haben, auch wenn ich gerade in neueren IDEs wieder Schludrigkeiten feststelle wie falsche Tab-Reihenfolgen, Duplikate bei den Hotkeys, fehlerhafte Platzierung von Dialogen bei nicht-Standard Monitoranordnungen und die allseits beliebten Darstellungsfehler.
Aber worauf ich eigentlich hinaus will: Jedes Mal, wenn ich mir (für Windows-Entwicklung) Alternativen angesehen habe, stellte ich fest, dass diese Alternativen noch schlimmer waren. Ich war von Delphi verwöhnt und hatte keinen Bock, mich mit weniger zu begnügen. Das fing mit Visual Basic (damals Version 6) an und ging über diverse dotNET IDEs/Sprachen hin zu Lazarus (welches gar nicht sooo schlecht ist, aber im Vergleich nicht gegen Delphi anstinken kann) oder Python. Delphi ist also meiner Ansicht nach nicht wirklich ganz toll, nur ist es immernoch besser als alle Alternativen, die ich mir angesehen habe. Aber wohl gemerkt: Immer im Bezug auf Windows-Programmierung, und da speziell GUI, weil das der Bereich ist, in dem ich vorwiegend arbeite. |
AW: Unbeliebtheit von Delphi
Zitat:
Zitat:
1, 2, 3. Das sind nur Beispiele, mit denen ich selber überhaupt nicht mehr weiter kam. Die ganzen Dinge, die mich zusätzlich etliche Stundne und Nerven kosten, die es nicht bis hier in die DP schaffen sind dann der Rest vom Eisberg. Gerade die Doku zu FMX ist extrem oberflächlich, und bietet bei spezifischen Problemen mit einzelnen Eigenschaften oder Vorgehensweisen kaum mehr als einen Stub-Eintrag. Und hast du schon mal versucht, LiveBindings zur Runtime im Code zu verwalten - nicht wie in all den schönen Videos nur im Designer? (Weil man z.B. je nach Situation in einem Grid die eine oder andere Tabelle zeigen will, oder sich einfach nur die Tabelle hinter einer gelinkten ComboBox ändert, LB diese aber partout nicht aktualisiert - auch nicht nach vollständigem Abklemmen und Neuzuweisen der Bindings.) Viel Erfolg. Und all dies in 10.2.3, wo beide Tools bei weitem nicht mehr "Frischlingsschutz" anmelden könnten. (Was bei einer professionell anschickenden und gut bezahlten Software ohnehin so eine Sache ist.) Details dazu wenn unbedingt gewünscht dann aber bitte per PN. Die gehören nicht in diesen Thread hier. |
AW: Unbeliebtheit von Delphi
Es gibt bestimmt Gegenargumente für Delphi. Aber keines der genannten Argumente ist für mich ein Grund Delphi den Rücken zu kehren. Ich habe mit TP angefangen und bin seit Fielddtest 1 (1994) bei Delphi. Mann kann sagen ich "lebe" Delphi.
Ich nenne mal einige Argumente für Delphi 1) Der Compiler/das Compilat: * Delphi kompiliert schnell. Gibt es wirklich etwas, was schneller als Delphi kompiliert? Meine Projekte mit > 1Mio LOC kompiliert so schnell, dass ich es nicht schaffe, mir dabei einen Kaffee zu holen. * Ich kann mich wirklich an keinen Zeitpunkt erinnern, in dem Delphi etwas falsch kompiliert hat. Wenn es Fehler gab, dann lag es immer an mir. Oder an einer der wenigen Komponenten, die ich verwende. 2) Die Sprache: * Viele kommen mit dem Argument, dass die Sprache zweitrangig ist und man sich schnell an eine andere Sprache gewöhnt. Da sage ich Nö. Immer wenn ich einen Ausflug zu einer anderen Sprache gemacht habe, dachte ich mir "Wieso?". PHP..... Variablen on the fly zu generieren ist ein Graus. Typesicherheit ist nicht wirklich gegeben. C++ schon eher. * Aber wie ich schon sagte, ich bin seit 25Jahren bei Delphi. Den Kenntnisstand, den ich in Delphi mit allen seinen Interna habe, denn lernt man bei einer anderen Sprache nicht innerhalb von 3 Wochen. Und bei Delphi lerne ich immer noch dazu. 3) Legacy - Projekte: * Für Auftragsarbeit, die ich innerhalb von zwei Wochen/Monate abwickel, kann ich ggf. mal eben schnell die Sprache wechseln. Aber für lang angesetzte Projekte brauche ich eine Programmierumgebung, mit der ich lange arbeiten kann. Mein ältestes Projekt habe ich vor 25 Jahren angefangen. Dann gibt es noch weitere Projekte, die sind 15-20 Jahre alt. Bei Umstellung auf eine neuere Delphi-Version, hatte ich nie wirklich Probleme. Die Umstellung ging meist innerhalb eines Tages von statten. Einzig die Umstellung auf Unicode hat mich 2 Woche gekostet. Es läuft einfach. Der Code ist einfach wertstabil. Die Microsoft-Dinge, die MS aus dem Boden stampft mögen zwar fancy sein, was bringt mit das, wenn MS dies nach ein paar Jahren wieder einstampft. 4) Delphi ist aus dem Dornröschenschlaf erwacht. * Bis zur Übernahme von Emarcadero/Idera hat sich nicht wirklich viel an Delphi getan. Es wurden zwar immer mal wieder Komponenten zugefügt, die aber in einer späteren Version wieder rausgeflogen sind. Ein Grund, weshalb ich vielleicht 3-4 Externe Komponenten besitze. Den Rest habe ich selber geschrieben. Komponenten haben mich nie wirklich interessiert. Aber die Spracherweiterungen(Unicode, Generics etc.), die es in den letzten 5-10 Jahren gegeben hat, machen die Sprache viel produktiver. Da holt Delphi mächtig auf. Die IDE läuft nicht ganz rund. Aber auch bei der IDE hat sich einiges getan. 5) Multiplattform: * Das Prinzip von FMX finde ich klasse. Bisher hat mir die Zeit gefehlt, größere Dinge damit zu machen. Ausserdem habe ich erst mal abgewartet, damit dich nicht mit den Kinderkrankheiten kämpfen muss. Habe aber einiges von Frank Lauter (Mavarik) gesehen und war immer begeistert, wenn er mal was gezeigt hat. Jetzt ist für mich auch der Zeitpunkt gekommen, dass FMX dauerhafter Bestandteil von Delphi bleibt und ich Projekte realisieren kann, mit denen ich auch Geld verdiene. Zum Schluß: Ja. Delphi (grade die IDE) hat macken. Es gibt bestimmt andere IDE, die stabiler laufen und die auch produktiver sind. Für mich aber (bisher) kein Argument gewesen, eine andere Sprache zu verwenden. Denn auch andere Sprachen/IDE haben macken, die man erst mitbekommt, wenn man sich tiefer in diese (andere) Sprache einarbeitet. Die Zeit spare ich mir einfach. |
AW: Unbeliebtheit von Delphi
Zitat:
0 € für Geschäft, wenn Umsatz < 5,000 USD Darüber €1,699 IM ERSTEN JAHR /€439 pro Jahr Halte ich Angemessen. Zitat:
Und ob das besser für die Komponentenentwickler wird wenn sie es mit statt 2 (relevanten unterschiedlichen) Edition dann mit 20 zu tun haben Zitat:
Wie oft trifft man darauf? Zitat:
|
AW: Unbeliebtheit von Delphi
Zitat:
In einem Fall reichte es schon eine Quelltextformatierung über alle Units laufen zu lassen und schon waren die Probleme weitgehend weg. Es macht halt keinen Sinn sich eine superduper Formatierung einfallen zu lassen, die man dann nur selbst gut lesen kann, sonst aber niemand. Und im Extremfall eben nicht einmal der Backgroundcompiler... Im zweiten Fall genügte es die ganzen Kreuzbeziehungen deutlich zu reduzieren. Alle habe ich so auf die Schnelle nicht rausbekommen, aber es hat schon gereicht, dass die IDE zumindest stabil lief. Die Syntaxergänzung hakte trotzdem noch etwas. Nach dem Erfolg hatte der Betreffende aber "Blut geleckt" und das weitere Refactoring selbst durchgeführt. Und seitdem hat er keine Probleme mehr. Ja, es ist schade, dass Delphi nicht trotzdem sauber läuft. Aber es wurde ja auch schon viel an der Stelle gearbeitet. Und das ändert sich mit 10.4 und LSP ja vielleicht auch endlich. Als Softwareentwickler habe ich aber durchaus Verständnis dafür, dass es nicht so leicht ist ein solches Produkt so stark zu überarbeiten... Und man kann eben auch selbst dazu beitragen, dass Delphi besser läuft, indem man sich eben an Standards hält bei der Formatierung und indem man Spaghettiartige Unitbeziehungen reduziert... |
AW: Unbeliebtheit von Delphi
Dann wiederhole ich mich mal: "Ist ja toll für den der keine Probleme hat, für die die Probleme haben aber schon."
Danke für Deine Hinweise. Code wird bei uns ständig formatiert. Das geht beim Build auch automatisch. Kreuzreferenzen: Da bin ich mir nicht sicher. Wenn bei im implementation Teil kein uses hat, sollte doch gut sein. Es mag weitere Dinge geben die man vermeiden könnte, wenn man es denn wüsste. Wir zahlen seit vielen Jahren für >10 Entwickler Delphi Lizenzen. Zu sagen man solle ein kleines Testprojekt zum reproduzieren machen hilft nichts, wenn die Probleme nur beim komplexen Projekt auftreten. Da könnte von denen doch auch mal einer einen Tag per Fernwartung mal draufschauen denke ich. |
AW: Unbeliebtheit von Delphi
Zitat:
Zitat:
|
AW: Unbeliebtheit von Delphi
[QUOTE=jaenicke;1463353Wir haben ein relativ großes Projekt per Supportticket eingereicht und das wurde dann auch geprüft.[/QUOTE]
Genau dafür sind diese Support-Tickets ja auch gedacht. Vermutlich wird aber die große Mehrheit ihre drei Frei-Tickets pro Subscription-Jahr verfallen lassen. |
AW: Unbeliebtheit von Delphi
Zitat:
Zitat:
|
AW: Unbeliebtheit von Delphi
Zitat:
Zitat:
aber sich niemals beteiligen werden (z.B. Bugfixes zurückmelden oder ähnliches) Zitat:
Ab XE6 konnten wir einiges der selbst definierten WinAPI entsorgen und mit 10.2 haben wir glaube ich gar nix mehr drin. Nur eine Schnittstelle die mehr oder minder nur aus "void <funktion>(void)" besteht. Also "sehr komisch" definiert ist (alles über sehr "flexible" Strukturen" abgebildet wird. |
AW: Unbeliebtheit von Delphi
Ich denke die mangelnde Verbreitung und damit die scheinbare "Unbeliebtheit" in der Fachpresse ist eher eine "Unbekanntheit". Wenn mehr Entwickler (und solche die es werden wollen) davon überhaupt mal was gehört hätten, und es dann vielleicht auch mal ausprobiert hätten, dann würde sicherlich auch mehr Softwareentwickler auch darauf umsteigen. Sie müssen es halt nur erstmal wissen.
|
AW: Unbeliebtheit von Delphi
Zitat:
Während ich bis vor kurzem noch Visual Assist X brauchte um sinnvoll mit C++ zu arbeiten (wobei das auch daran liegt, daß die Integration bei Treiberentwicklung mit DDK/WDK lange Jahre fehlte), kann ich mittlerweile auch gut ohne arbeiten. Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Ich habe auch an JDARTH mitgearbeitet gehabt. Heute würde ich ein Projekt dieser Art ganz anders angehen. Vor allem würde eine Grammatik als Basis dienen und nicht handgeschriebener Code. Zitat:
Das hilft mir aber nix, wenn ich eine Drittanbieterbibliothek nutzen will, bei der Embarcadero das nicht bereits übernommen hat. Zitat:
Zitat:
|
AW: Unbeliebtheit von Delphi
Gut, ich kann Delphi jetzt nicht effektiv mit vielen anderen IDEs/Compilern vergleichen.
Arduino, 100 Zeilen Code gegen tausende Zeilen mit Delphi, da ist Delphi und seine IDE wirklich extrem schnell. (ja, die Arduino IDE kann nicht viel und ist dennoch extrem lahm) Aber ich kenn auch Delphi seit Version 4 und hatte auch schon mit Turbo Pascal und Delphi ein in einer VM mit dem passenden Windows gespielt, dagegen ist es schon extrem langsam geworden. Windows 32 Bit ist ja aktuell noch schnell, aber auch dieses will man irgendwann auf die neue Weise (LLVM) umbauen. Windows 64 Bit dauert schon länger und Android ... nja, schnell ist was Anderes. iOS konnte ich nie aussprobieren, weil ich mir dafür nicht extra ein i-Produkt kaufen wollte (auch wenn das nicht Embas Schuld ist, sondern die Lizenzierung/Beschränkungen seitens des Apfels, denn es wäre möglich auch ohne i-Dinger im Windows kompilieren zu können). Und ja, ich hatte bisher auch nur mit einem Projekt Geld verdient. Und ein paar Euro auf mein eher unbekantes Paypal-Spendenkonto. (vielen Dank an ein paar Leute hier aus'm Forum, welche das entdeckt hatten :thumb:) OK, durch das Hobby bin ich auch noch beruflich mit Delphi in Kontakt gekommen und es ist schon nett, dass der Cheff auch noch zusätzlich für's Hobby etwas zuschießt. (aktuelle die DelphiLizenz und auch sowas wie Delphi-Tage oder andere Schulungen/Konverenzen) |
AW: Unbeliebtheit von Delphi
Zitat:
Zitat:
Zitat:
Als "Zwitter" der x Tools nutzt wird es natürlich schwieriger zu verargumentieren. Wäre evtl. beser mal einige der "Nebenschauplätze" zu beenden und z.B. alles in eine IDE zu entwickeln die man "sonst auch" nutzt. Zitat:
Und hier müsstest du auch noch viele Lizenprüfungen in den Quellcode einbauen, das nicht einer Komponente x kaufen und dann weitergibt. Zitat:
Ich habe auch an JDARTH mitgearbeitet gehabt. Heute würde ich ein Projekt dieser Art ganz anders angehen. Vor allem würde eine Grammatik als Basis dienen und nicht handgeschriebener Code. Zitat:
Zitat:
Ich wundere mich aber ob man das nicht über eine Art "Crosscompile" durch Nutzung des C-Compilers hinbekommen könnte. Aber ich vermute da müsste erst alles auf LLVM laufen bevor das gehen könnte. |
AW: Unbeliebtheit von Delphi
Stimmt. Daran gibt es auch gar nichts zu meckern. Auch wenn diese Editor Facilities aus der Sicht eines Web Editors schon hart, wie man bei euch sagt, auf Kante genäht sind.
Validierung, Syntax Checker usw... Delphi beschleunigt die Produktion von Windows Anwendungen extrem. Zeige mir eine Technologie die jemals auf Dauer darüber hinaus gewachsen wäre als wofür sie zu Beginn geschaffen wäre. Den großen Mainstream Technologien geht es nicht anders die wurden aus dem Grund eigentlich so allumfassend ausgelegt. Auf den Punkt komme ich gleich wieder zurück. Zitat:
Zitat:
Was du beschreibst heißt ASP.net im Visual Studio :wink:. Technisch gibt es für diese Hinwendung mehrere Gründe, aber in dem Zusammenhang ist zu sagen, dass Javascript damals, obwohl es alle zwar nur im Intranet aber doch nahmen, in Verruf kam und in die Delphi Erweiterungen von Devexpress, AtoZed, Marotz usw... externen Content nicht fehlerfrei konnten importieren. Genauer gesagt schafften das die Produkte von Adobe mit viel Augenzudrücken. Damit verblieb der Editor. Wenn ich nur einen Editor brauche resp. nehmen kann, dann bleibe ich gleich auf UNIX. Ein hausgemachte gefehlte Hoffnung war eben, dass es nie wirklich gelang Datamodules so zu konzipieren, dass mit deren Hilfe ein Entwickler in der Lage war, annähernd nur soweit zu kommen wie Webscripting plus Framework (bspw. transparenter Datenbankzugriff), welche damit eigentlich den Schulterschluss mit 4GL schafften und damit mit der Programmierung in der DB (Procedure Languages). Python und PHP sind fast dasselbe, allein hatte Python zuerst die bessere Anbindung zu den Mainstream Datenbanken und bekam hernach die Webframeworks dazu. Bei Python gesellt sich noch das 'Repository' hinzu. Selbst wenn zu Beginn 20 Leute in einem Unternehmen sitzen und nie an einem neuen Produkt würden arbeiten, sitzt am Ende nurmehr einer mit dem Code der ehemaligen Kollegen da. Die Enterprise Liga drüber war/ist von JAVA/JVM und teils .net/C# besetzt. Dahinter steckt am Ende wie diese wie sich rausstellte gescheiterte Idee des Appservers. - Der Webserver und die ihn umringenden Technologien sind deswegen so erfolgreich, da sie nie 3-Tier waren. Es gibt eine im kommerziellen Umfeld verbreitete Technologie die 3-Tier beinahe echt kann und die ist der ABAP Stack von SAP. Wobei dort die RPC Indirektion eigentlich auch durch ein eigenes Protokoll ersetzt wird, genauso wie der HTTP Request des Client auch in die Kategorie fällt. Smalltalk ginge auch noch in die Richtung. Ein Webbrowser mit Debugging ist schon beinahe ein eigenes OS und eine SAPGUI ist auch schon eine sehr eigene Welt, lebt aber stark von der Funktionalität auf der AppTier. Ähnlich wie bei den MobileOS, die App sammelt die Daten für die Clients zur Auswertung bei den Informationsdiensten. :-D Genau dem Irrtum sind auch .net 1.1, Java und z.T. auch J2EE unterlegen, genauso wie Intraweb & Co inkl. aller MIDAS replacements, resp. war der Treiber für deren Einsatz genau dieser Idee. Die GUI verwendet dasselbe Backend wie die Webanwendung. Der Irrtum wurde erkannt und auf einmal war die Melkkuh schlechthin geboren. Es wird etwas nachgebildet, das auf der OS Ebene eigentlich schon gemacht werden kann. Das erinnert etwas an die Fähigkeit mit Delphi etwas von Windows bspw. im Explorer angebotene in der Anwendung nachzubilden (Kontextmenü in der Anwendung unter Delphi 3 bspw.). In dem Sinne wurde ein sich etablierter Trend fortgesetzt und in dessen Kontext wurden wie auch immer geartete Workarounds rund um einen Appserver umgesetzt. Bei einer Native Technologie läuft man sofort auf die nackte Wahrheit auf. Wenn du einen Lazy Load in einem ORM machen willst, dann loope über einen DB Cursor in PL/SQL. Der SELECT * from db_table entspricht in etwa dem öffnen einer Datei. Ein anderer Weg ist den Webserver ins OS integrieren, bekannt (IIS) oder in die Anwendung. - Mal eine ganz andere Frage. Wie kommst du auf die verwegene Idee, dass Delphi jemals in einem Kontext von 'nett' resp. klein aber fein wahrgenommen wurde? Zu dem Begriff 'nett' oder pretty near fielen mir beispielsweise WYSIWYG Web Builder, HTML Validator, Topstyle, WeBuilder resp. HTMLPad oder Rapid PHP Editor ein, resp. Regex Buddy, Regex Magic, EditPadPro ... Deine Aussage stimmt, gäbe es eben nicht die vielen Konzessionen an den Zeitgeist die sich über alle Technologien hinweg soweit in Programmiersprachen, Frameworks und IDEs reinfressen. Bei Klassen und Prozeduren geht es noch so halb, aber schon geflattete Methodenaufrufe wären schon eine Konzession. Generika wirken viel intensiver. Was heißt eine HTML Datei. Eine HTML im Sinne eines Hypertext Documents ist eindeutig abbildbar. Was machen wir mit ASP, die versammelten Variationen von SSI allgemein, ... So eine 'Web Personality' die müsste am Ende der Idee folgen, mit möglichst wenig Javascript bspw. auszukommen. |
AW: Unbeliebtheit von Delphi
Zitat:
- Mit Delphi werden die Apps riesig, dafür kann man sie recht schnell schreiben. - Mit dem Android Studio ist es im Vergleich einfach zäh und unangenehm eine App zu entwickeln (und man kann halt keinen existierenden Code übernehmen), aber wenn sie erst einmal fertig ist, ist sie deutlich kleiner und startet schneller. Zur Laufzeit ist hingegen kaum ein Unterschied in der Performance zu merken, zumindest bei denen, die ich bisher geschrieben habe. Zitat:
Das betraf aber wie geschrieben nur den Backgroundcompiler. Der richtige Compiler hatte damit nie Probleme. Deshalb schalten viele die Fehlermarkierungen ja auch aus. Ich finde sie aber sehr praktisch. Wobei mir ein schöner Bug einfällt. In einer alten Version hatte mich mal jemand um Hilfe gebeten, weil eigentlich alles richtig aussah. Theoretisch war es das auch. Aber er hatte so etwas geschrieben (nur ein Beispiel, ich weiß den konkreten Code nicht mehr):
Delphi-Quellcode:
Das hat er auch relativ oft gemacht, warum auch immer. Jedenfalls hat Delphi daraus leider falschen Assemblercode generiert. Ohne die Klammern war alles in Ordnung. Das hatte mich damals ein paar Stunden Haareraufen gekostet...
a := (b + c);
// sprich einfach nur den ganzen Ausdruck in Klammern |
AW: Unbeliebtheit von Delphi
...Tote leben länger...
Was ich so von den Äußerungen meiner Partnern her sehe ist, dass sich die Masse der Delphi Entwickler räumlich verlagert hat. Hochburgen sollen Latein Amerika/Brasilien, Afrika, Russland und deren Nachbarländer sowie Griechenland sein. Soll man teilweise auch an den Community Entwicklern von Free Pascal, Lazarus und Code Typhoon sehen. Auch wenn Idera wirklich einmal entscheiden sollte Delphi einzustellen, gibt es mögliche Alternativen. Wer eine Network Lizenz hat, hat sowieso seine eigene heile Welt, die unabhängig von Idera/Embarcadero noch für einige Zeit laufen wird. |
AW: Unbeliebtheit von Delphi
Zitat:
Zitat:
Was hilft es mir ne tolle IDE mit nem duften Frontend zum Debugger zu haben, wenn ich aus diversen Gründen dann doch immer wieder gezwungen bin direkt auf dem Terminal zu debuggen? Mal abgesehen davon, daß ich letzteres auch über eine serielle Verbindung oder SSH machen kann und das mit einer IDE dann häufig schon wieder merklich hakelt (auch wenn bspw. gdbserver durchaus unterstützt wird in IDEs). Abgesehen davon habe ich in meiner Karriere an (Windows-)Dateisystemfiltertreibern gearbeitet. Sowohl Legacy als auch Mini. Für Visual Studio konnte ich mir mit meinem DDKWizard und DDKBUILD behelfen und dann die gewohnte IDE benutzen, aber die Toolchain vom WDK. Geht das überhaupt in Delphi? Vielleicht ist's zu lang her. Aber ich meine in XE gab's das noch nicht. Ich habe da mal ein paar ... Prototypen von (Windows-Kernelmode-)Treibern in Delphi gesehen. Erstens hast du dann den ganzen Schmuh mit der Übertragung der Headerdateien nach Delphi nochmal von vorn (andere APIs als im Usermode) und zweitens wird es von Microsoft nicht unterstützt. Und drittens - kann denn der aktuelle 10.x-er PDBs? - kannste Postmortem-Debugging ohne PDBs mal voll in die Tonne kloppen. Da bekomme ich dann nen tollen Minidump oder vollen Dump vom Kunden rein und kann den nicht in WinDbg laden, weil Delphi keine PDBs ausspuckt. Das gilt übrigens analog für eine Menge anderer Werkzeuge und reicht bis in so Dinge wie ETW rein, die extrem nützlich sind. Ach ja und dann hab ich noch Software für und teilweise auf AIX, Solaris, diversen BSDs, diversen Linuxen und macOS (damals noch OSX) entwickelt. Inklusive Kernelerweiterungen/-module. Diese "Nebenschauplätze" wurden zumindest damals nicht von den Werkzeugen rund um Delphi und C++ Builder unterstützt. Hat sich daran etwas geändert? Und jetzt kommst du ... Zitat:
Zitat:
Zitat:
Zitat:
Ganz ehrlich, was mich an dieser Diskussion am meisten nervt ist die Tatsache, daß hier auch eine 90+%-Lösung durchaus reichen würde. Denn die meisten der Handgriffe bei einer solchen Übertragung sind mechanisch. Wenn es dann vereinzelt zu Unstimmigkeiten kommt, könnte ein solches Werkzeug von Embarcadero halt ein Kommentar mit dem ursprünglichen Funktionsprototypen hinterlassen. Dadurch wäre aber so viel Arbeit Leuten abgenommen worden. Zitat:
Zitat:
Das könnten wir uns aber auch nicht leisten, wenn die Rechner nicht entsprechend schneller geworden wären und die vorhandenen Ressourcen (RAM usw.) üppiger. Zitat:
Ich finde ja, daß selbst bei Programmiersprachen gilt, daß sich mit jeder neuen Sprache quasi eine neue Welt auftut. Wenn man also bspw. C/C++ für native Bibliotheken auf Android lernen will, oder eben Java oder Kotlin, dann erweitert das definitiv den Horizont. Zitat:
|
AW: Unbeliebtheit von Delphi
Zitat:
Ob das auch klappt wird sich zeigen. Wenn es klappt und gut läuft, ist die größte Baustelle (oder zumindest eine der größten) was die Qualität der IDE angeht vom Tisch... |
AW: Unbeliebtheit von Delphi
Zitat:
Nja, da über die System.pas/SysInit.pas schon zuviel für den UserMode da drin steckt und das eher mehr als weniger wurde ... neee, mit ist nichts bekannt, dass man da effektiv und ohne Tricks Treiber mit entwickeln kann, vorallem nicht für den Kernel. Da müsste man sich wohl eher eine eigene Personality in der IDE registrieren und dann einen anderen Compiler verwenden. Zitat:
Andersrum geht es ja auch, also im C++Builder kanns du Delphi-Units einbinden. Nja, aktuell man könnte versuchen die C++-Dateien (.c) in eine .obj zu kompilieren und automatisch aus den .h die Delphi-Funktions-Deklarationen generieren. |
AW: Unbeliebtheit von Delphi
Zitat:
Zitat:
Zitat:
Zitat:
|
AW: Unbeliebtheit von Delphi
Du kannst mit einem C++-Compiler deine C++-Quellcodes in eine .OBJ-Kompilieren lassen,
und diese kann man dann im Delphi einbinden.
Delphi-Quellcode:
{$LINK 'xyz.obj'}
http://docwiki.embarcadero.com/RADSt..._file_(Delphi)Beispiele: System.pas (der DeleyedLoadingHelper von Microsoft ... es wäre nicht schwer gewesen das selbst zu machen, aber man hat direkt die Referenzimplementation übernommen) System.ZLib.pas (damals: ZLib.pas) oder IdZLibHeaders.pas Vcl.Imaging.jpeg.pas (damals: jpeg.pas) BDE.pas und MidasLib.pas System.RegularExpressionsAPI.pas (warum selber machen, wenn es das schon gibt, auch wenn es Unicode nicht direkt unterstützt und man nach UTF-8 konvertieren muß) System.Win.Crtl.pas FireDAC.Phys.PGCli.pas und FireDAC.Phys.SQLiteCli.pas = https://www.delphipraxis.net/204147-...-resource.html :stupid: |
AW: Unbeliebtheit von Delphi
Zitat:
|
AW: Unbeliebtheit von Delphi
Hab noch nicht rausgefunden/nachgesehn wie, aber man könnte fast Denken, dass auch andere Anbieter diese Schnittstellen benutzen können, um eigene Compiler integrieren zu können.
Schon in alten Delphis hatten welche ja nur die ToolsAPI genutzt und im Menp oben einen Punkt reingemacht, um manuell/anders den Compiler zu starten, aber das schon "erfolgreich" auch in den uralten 1er-Delphis |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 02:36 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz