|
Delphi langsam ersetzen
Ich schaue mich zur Zeit um um für meine Aufgaben (VCL, keine gewaltigen Datenbanken ) Ersatz für Delphi zu finden.
Ich hab mich jetzt einige Tage mit C# beschäftigt (Microsoft Visual Studio 2015 Community). Ist sicher machbar auf C# zu wechseln. Neben der viel größeren Unterstützung im Internet, siehe CodeProjeft.com man staunt wieviele fertige Lösungen es gibt, ist das Microsoft Visual Studio 2015 Community kostenlos auch für kommerzielle Anwendungen. Bin ich da auf der richtigen Spur, oder gibt es andere Möglichkeiten? Eure Erfahrungen würde mich sehr interessieren. |
AW: Delphi langsam ersetzen
Hmm, was soll man Dir da raten?
Hängt halt davon ab, was Du machen willst, was Du ausgeben kannst/willst und wie schwer/leicht Du Dich mit einer neuen Entwicklungsumgebung und Sprache zurecht findest. Für VCL bist Du ja mit XE2 längerfristig ganz gut bedient. Warum strebst Du einen Wechsel an? Neukauf würde ich eher vermeiden und auf C# setzen. Für Crossplattformentwicklung müsste man das nochmal explizit entscheiden. |
AW: Delphi langsam ersetzen
C# ist schon mal nicht falsch. Java wäre noch eine Alternative.
|
AW: Delphi langsam ersetzen
Zitat:
|
AW: Delphi langsam ersetzen
Zitat:
Ansonsten kann C# vieles genauso gut wie Delphi oder besser, für uns wäre es aber hauptsächlich wegen Crossplatform nicht geeignet. Außerdem stört mich der fehlende Lowlevel Zugriff zum Debuggen auf Assemblerebene. Aber den brauchen die meisten ohnehin nicht. Unsere bisherigen Erfahrungen mit .net waren allerdings ernüchternd... es gab ständig nur Probleme. Falsch gesetzte Berechtigungen ohne dazu passende Fehlermeldungen, undurchschaubare Fehler (und eben die fehlende Debugmöglichkeit auf unterer Ebene)... Wenn man da nicht genau weiß was man für .net einstellen muss... Ich wünsche dir da mehr Erfolg... |
AW: Delphi langsam ersetzen
Jenseits verschiedener Tellerränder findet man außerdem:
SharpDevelop - m.E. durchaus vergleichbar mit VS, aber ohne Begrenzung bei der kommerziellen Verwendbarkeit. Außerdem Benötigt man dafür kein Microsoft-Konto. Wenn man Cross-Plattform-Entwicklung machen muss und sich mit C++ anfreunden kann: MinGW mit QT. QT ist, soweit ich das verstanden habe, nicht in allen Fällen kostenlos. Java wurde bereits genannt |
AW: Delphi langsam ersetzen
Zitat:
Wenn Crossplatform würde ich als Alternative, insbesondere wenn für Android, Java z.B. mit Netbeans und Android Studio empfehlen. So einfach wie mit Firemonkey ist es zwar nicht, aber dafür bugfreier... Wenn Crossplatform nicht nötig ist, ist C# schon eine sehr gute Alternative, das sehe ich auch so. Allerdings muss man sehr genau wissen was man tut und tun muss, damit alles funktioniert. Wir hatten schon viel Spaß mit .NET Policies usw., bei denen wir allerdings nicht wussten welche eingestellt hätten werden müssen usw. |
AW: Delphi langsam ersetzen
Schau Dir noch Lazarus an -
 http://www.lazarus-ide.org |
AW: Delphi langsam ersetzen
Zitat:
QT ist in der Hinsicht kein Selbstgänger, schon das Aufbauen für die Windows-Plattform ist nicht ganz ohne (z.B. habe ich es mit Visual-Studio Community 2015 nicht hinbekommen. Deshalb verwende ich MinGW und dieses gibt's halt für verschiedene Ziele. |
AW: Delphi langsam ersetzen
Zitat:
|
AW: Delphi langsam ersetzen
Zitat:
Und wenn es darum geht für Windows und Linux zu entwickeln, empfinde ich es sogar äußerst komfortabel, mal so eben auch eine Version für den Raspberry oder Linux-64/32-Bit oder das gleiche als Windows-Version zu erzeugen. Auch vorteilhaft: es liegt alles im Source-Code vor und die Entwicklung schreitet gut voran, nicht zuletzt: es werden gemeldete Bugs auch behoben. Gruß Thomas |
AW: Delphi langsam ersetzen
Zitat:
Zitat:
Und auch die Lazarus-IDE ist besser als ihr Ruf. Sie hat alle modernen Features, die ich brauche. Aber sie leidet, wie viele Open-Source-Programme, an schlechten Default-Einstellungen, weshalb der Eindruck entsteht, dass sie deutlich weniger kann als sie kann. Wenn die Entwickler sich alleine mal durchringen könnten, das Docking-Paket – welches hervorragend funktioniert, ich verstehe nicht, was sie daran auszusetzen haben – standardmäßig zu aktivieren, dann würden sie wahrscheinlich schon dadurch nur noch ein Drittel so viele Nutzer verschrecken. Der erste Eindruck zählt halt. Ist nur ein Beispiel. |
AW: Delphi langsam ersetzen
Für Bestehende Anwendungen die du nur noch Pflegen willst bleib bei deiner aktuellen Delphi-Version.
Selbst mit Delphi 6 kann man noch 32-Bit Apps schreiben die Problemlos unter Win10 laufen. Wie heißt es so schön: Never Change a Running System. Wenn du neu Entwickeln willst solltest du noch 1-2 Schritte zurückgehen und nicht nur eine Welche der IDE/Framework andenken sondern die Lösungen überhaupt hinterfragen: Muss es eine Desktop-App sein? Wäre ein WebApp nicht besser? Muss es native auf iOS/Android (und evtl. unter WinRT) laufen? Muss es für Linux (Server/Desktop) verfügbar sein? Entsprechend den Antworten die du für deine neuen Apps findest ist die Lösung evtl. Java/PHP (wenss unbedingt sein muss) oder .NET oder reicht Delphi auch noch? |
AW: Delphi langsam ersetzen
Zitat:
Aber mittlerweile bin ich ein großer Fan davon, vor allem: ich bin nicht auf eine Platform festgelegt. |
AW: Delphi langsam ersetzen
Wenn man von Delphi weg will, ist Lazarus vielleicht nicht das Richtige.
Mit Java macht man garantiert nichts falsch, vor allen Dingen dann nicht, wenn man plant, seinen Lebensunterhalt mit Softwareentwicklung zu verdienen. Mit Java/C#-Kenntnissen kommt man sehr weit, wohingegen Delphi-Experten tendenziell extrem selten gesucht/benötigt werden. |
AW: Delphi langsam ersetzen
Zitat:
|
AW: Delphi langsam ersetzen
Zitat:
Seitdem habe ich manchmal noch einen Blick auf Lazarus geworfen, und es gab seitdem auch viele Erweiterungen, aber keine, die meine Meinung geändert hätten. In Delphi wäre ich damals mindestens dreimal so schnell zum Ziel gekommen. Aber das muss jeder für sich selbst entscheiden. Mir reicht die Produktivität nicht aus, schon gar nicht für die berufliche Nutzung. |
AW: Delphi langsam ersetzen
Hallo jaenicke,
würdest Du mir bitte einige Beispiele für die Produktivität der neuen Delphiversionen gegenüber D7 (Lazarus) aufzeigen. Würde mir dann leichter fallen eine neue Delphiversion zu erwerben. Danke und viele Grüße Hannes |
AW: Delphi langsam ersetzen
Zitat:
- 64-Bit - Besserer Debugger der auch durch die WinAPI callstacks bereit stellt - Unicode (höhere Aufwand bzw. wenig verfügbare Komponenten) - Eingebaute Theming-Engine (auch wenn es hier immer Debatten gibt das man doch die Vorgaben von Windows verwenden soll - Wenn der Kunde sagt er will grüne Buttons, dann bekommt er Sie auch) - Generics |
AW: Delphi langsam ersetzen
Zitat:
|
AW: Delphi langsam ersetzen
Zitat:
Gruß K-H |
AW: Delphi langsam ersetzen
Mit einer IDE ist es so wie mit Schuhen.
Am Besten sitzen die, mit denen man das Geschäft betreten hat. Die sind eingelaufen, man hat sich aneinander gewöhnt und bestimmte Eigenheiten lieb gewonnen. Bei einer IDE hat amn etwas für sich entdeckt, nutzt dieses ausgiebig im Tagesgeschäft und wenn eine andere IDE nicht genau dieses Feature über den gleichen Weg anbietet, dann wird man langsamer und findet diese IDE "doof" (weil man ja langsamer ist). Dann kommen noch unterschiedliche Sprachkonstrukte (z.B. Namespaces, Generics, etc.) die fehlen oder eben auf einmal da sind und schon muss man seinen gewohnten Pfad wieder verlassen und wird langsamer. Auf "doof". Das passiert manchmal sogar auf dem alten bekannten Weg, wo es auf einmal Unicode gibt und die Welt plötzlich Kopf zu stehen scheint. Und dann wird man plötzlich mit ARC belästigt und nun rotiert die eigene Welt. Oder modale Dialog-Aufrufe sind auf einmal nicht mehr blockierend und ich muss so seltsame Dinge wie Callback-Methoden schreiben. Spätestens jetzt fühlt sich der ein oder andere wie in einer Waschmaschine mit Lagerschaden im Schleudergang. Für einen Wechsel benötigt man eine große Portion Motivation um den alten Weg zu verlassen und sich auf den neuen Weg einzulassen. Zumeist müssen hier einige alte (und im gegenwärtigen Kontext durchaus bewährte) Denkprozesse komplett über Bord geworfen werden. Es ist und bleibt eine persönliche Entscheidung, wie hoch die Motivation sein muss und was eine Motivation überhaupt ist. Ich persönlich fühle mich in der C#/.net Umgebung pudelwohl, hinsichtlich IDE (VS) und Sprachfeatures. Vieles fühlt sich dort (für mich) wesentlich natürlicher an und ich muss weniger über das Wie nachdenken und habe dadurch mehr Zeit für das Was. |
AW: Delphi langsam ersetzen
Hallo,
was mir, bei solchen Diskussionen wie wir sie hier führen, immer zu kurz kommt, ist die Erfahrung die man bisher mit Delphi gesammelt hat, diese Erfahrung würde bei einem Wechsel verloren gehen. Diese könnte sein, mit den Komponenten wie und an welcher Stelle werden sie angewendet, mit der IDE (ich schreibe auch in C++ in VS 2010 Prof. wie oft ich statt der Taste F5 die Taste F9 drücke!), eigene Komponenten, viele selbstgeschrieben Units habe sich in der Zeit angesammelt die man einfach benutzen kann, weil sie ausgetestet sind usw. usw. Mir ist klar, dass viele in diesem Forum die Ansicht vertreten das man, wenn man eine Programmiersprache beherrscht relativ leicht wechseln kann, ich glaube aber, dass es nur bedingt richtig ist. Die Grundlagen einer Sprache wie C#, um mal bei einer konkreten Programmiersprache zu bleiben ist relativ leicht keine Frage, aber um damit eine größere Anwendung zu schreiben braucht man doch schon eine Menge Zeit mehr. Diese Zeit ist es eben, die man wieder zusätzlich investieren muss, um auf den gleichen Stand wie bei Delphi zu kommen. Bis bald Chemiker |
AW: Delphi langsam ersetzen
Richtig, aber wenn Du deinen Horizont erweitern willst (oder einfach, weil Du einen JOB finden willst), solltest Du deine Erfahrungen in einem Gebiet sammeln, das auf dem Arbeitsmarkt gefragt ist.
Was habe ich denn von meinen 20 Jahren Delphi-Erfahrung? N-I-X. |
AW: Delphi langsam ersetzen
Ach Dejan Vue ! Natürlich gibt es Delphi-Projekte, auch Firmen, die nur auf Delphi setzen und damit gar nicht schlecht fahren. Ich "ernähre" mich fast auschließlich seit ca. 20 Jahren von Delphi-Projekten und das ist gar nicht so schlecht. Natürlich sollte man die Augen aufhalten, sich in anderen Dingen (z.B. die verschiedensten DBMS oder andere Sprache) weiterbilden. Aber einen Abgesang auf Delphi sehe ich so nicht. Das wird mir schon seit vielen Jahren immer wieder eingeredet.
|
AW: Delphi langsam ersetzen
Zitat:
|
AW: Delphi langsam ersetzen
Zitat:
|
AW: Delphi langsam ersetzen
Das Argument mit den 20 Jahren Erfahrung sehe ich genauso. Das ist kein Problem mit der Sprache. Im Laufe meiner 24 Jahre Selbständigkeit hatte ich einige Programmierer (und eine Programmiererin) angestellt, die allesamt Delphi als "eine ihrer Sprachen" praktiziert haben. Keiner hatte sich wirklich auf Delphi konzentriert. Über die Ergebnisse zu lästern, erspare ich mir jetzt. Einzige Ausnahme war ein Student der schon in den 90-ern fast ausschließlich TurboPascal-Programme geschrieben hat, und dann sein Pascal-Wissen ab Delphi 1 weiter verwendet und vertieft hat. Heute hat er einen sehr gut dotierten Job als Delphi-Entwickler. Von der Höhe seines monatlichen Einkommens träumen wohl viele nur. Es ist letztendlich das Ergebnis seiner Spezialisierung auf eine einzige Sprache. Er "kann" zwar auch andere Sprachen, aber praktisch arbeiten tut er nur mit Delphi.
Ich selber kann auch nur eine einzige Sprache. Habe mir zwar andere Sprachen angesehen, aber wohl gefühlt habe ich mich mit keiner so richtig. Wir wissen aber alle, dass ein gewisser Wohlfühlfaktor zur erfolgreichen Ausführung seines Jobs ein wichtiger Beitrag ist. Sicher gibt es Situationen, wo mehrere Sprachen gefragt sind. Doch ob sich der Einzelne mit dem ständigen Sprachenwechsel im Job wohl fühlen kann, sollte er für sich selbst entscheiden können und dürfen. Mein Standpunkt ist jedenfalls: Lieber eine einzige Sprache vernünftig angehen, als mehrere nur oberflächlich. Natürlich sollte man das aber auch vom Alter abhängig machen. Wenn ich anstatt jetzt knapp 60 noch 25 wäre, dann würde ich mir sicherlich mehrere Sprachen intensiver rein ziehen, schon aus dem Grund um den vielzitierten Horizont zu erweitern. Dagegen ist überhaupt nichts einzuwenden. Was ich mit allem sagen will: Gute Ratschläge zu erteilen ist in diesem Metier sehr schwierig. Wenn man die persönlichen Vorlieben und Fähigkeiten des Fragenden nicht kennt, könnten sogar gut gemeinte Ratschläge das Gegenteil bewirken. Darum, aufgrund der wenigen Informationen des TE: Wenn ich der TE wäre, würde ich die gewonnene Erfahrung mit Delphi nicht über Bord werfen und mir den Stress antun, auf eine andere Sprache mit neuer IDE zu wechseln. Außer ich wäre noch unter 30..35 (also mit noch etwa 30 Berufsjahren vor mir) und würde mich mit Delphi nicht wohl fühlen. Dann allerdings würde ich C++ mit MS VS empfehlen, denn Delphi ist langfristig gesehen auf einem absteigenden Ast. Dass Delphi mal in die TOP 10 kommt, wird wohl ein Traum bleiben. Microsoft hingegen hat es geschafft, den Markt für Programmiersprachen richtig anzugehen. Vielleicht erinnert sich ja noch jemand daran, als MS mit C noch ein Nobody war, weit abgeschlagen hinter Symantec und Watcom. Die haben ihren Job einfach gut gemacht und für die Zukunft ist mächtig viel Potential (Geld) da, um das erfolgreich fortzusetzen. |
AW: Delphi langsam ersetzen
Zitat:
a) Damit auch wirklich jeder begreift, das es um die spezifischen Erfahrungen mit der Sprache Delphi geht. b) Einfach so. Was meinst Du? Zitat:
Zitat:
Daher reicht es einfach nicht, in seiner Delphi-Blase zu leben und sich alle Unzulänglichkeiten schönzureden. Aber es wird langsam OT. |
AW: Delphi langsam ersetzen
Zitat:
Ob man mit Mobilgeräten Geld verdienen kann lass ich mal im Raume stehen, aber Microsoft hat dafür keinerlei Tools, mit denen ernsthafte Android und iOS Entwickler arbeiten. Das Windows Phone interessiert weiterhin keine Sau, Windows Universal Apps sind ein weiterer Rohrkrepierer, den nur IT Journalisten toll finden. Freunde von mir (pocketfms.com) entwickeln eine Moving Map/Flightmanagement Software für Piloten, die wirklich Multiplattform ist, über die Plattform Marmelade. Wenn man sich da alleine mal anschaut, wie viele Setups für die jeweiligen Plattformen existieren, ist das alleine schon heftig: http://docs.madewithmarmalade.com/di...latform+guidesAngefangen haben die mal von 12 Jahren mit VS und hatten einen Windows CE und einen Windows Client, die sich aber erheblich unterschieden. Alles war mit VS programmiert. Als dann irgendwann die Mobiltelefone und Tablets immer mehr iOS und Android waren und netterweise gleichzeitig Microsoft de facto den Support für Windows CE eingestellt hat, haben die sich entschlossen, eine neue Plattform zu evaluieren. Es hat ca. 2 Jahre gedauert, bis ein brauchbarer Client fertig war, den man auch zeigen konnte und der nicht auf jeder Plattform völlig neue Macken hat. Die neue Basis war also diese Marmelade Lib, eigentlich eine Gaming Engine, passt aber gut zu den Anforderungen. Die waren dadurch nicht die ersten Anbieter im Apple Appstore oder im Android Market und haben dadurch auch diverse Kunden verloren, aber im Moment sind wirklich alle Clients 100% identisch in der Funktionalität. Darunter sind auch native Clients für Windows, Max OS-X, Win8-10 mobile, Android, iOS. Für jede Plattform setzen die aber ein eigenes Compile Setup ein, um die Binaries nativ zu erzeugen. Als Sprache wird C++ benutzt, aber ohne eine ähnliche Multiplattform Bibliothek bringt die die Auswahl der IDE nix. Die 2 Jahre Arbeit an der neuen Version haben auch Spuren an den alten Version hinterlassen, die während dieser zeit kaum verbessert wurde. Wer die alte Software kannte und dann die ersten neuen Prototypen gesehen hat, schaute erst mal recht dämlich, nach der Devise: Das ist alles? kann ja nicht mal 10% von dem was ich kenne ..... Das Argument "aber funktioniert immerhin auf iOS und Android" interessierte erst mal kaum jemand. Mittlerweile ist der Aufwand für die Umstellung auf die neue Plattform abgeschlossen, alle Entwickler haben die neue API mehr oder weniger gut verstanden und man baut regelmäßig neue Features ein, die immer ohne Einschränkung auf allen Plattformen laufen und in allen Appstpres sind. Was aber ganz klar ist zumindest für dieses Unternehmen: Wenn man sich auf die Plattformen beschränkt hätte, die VS unterstützt, wären die schon lange arbeitslos und der Laden Pleite. Chefentwickler Rob ist dabei schon ewig mit C++ unterwegs und musste keine neue Sprache lernen, sondern nur die Marmelade API und die Besonderheiten der anderen Plattformen bei Setup, Distribution etc. Ich hatte mich mit Ihm mal auf einer Luftfahrt Messe über Lazarus unterhalten und ihm ein paar Miniprojekte auf Android und iOS, die damit erzeugt wurden, gezeigt. Einen Quellcode zu schreiben, der über entsprechende Bibliotheken auf allen Plattformen mit der gleichen IDE debuggt werden kann, war ausgesprochen interessant aus seiner Sicht, aber aufgrund der von Ihm bevorzugten C++ Sprache und den bereits endlos vorhandenen Bibliotheken für seine Zwecke keine echte Alternative. So war das von mir aber auch gar nicht gedacht. Sicherlich hätte er sich schnell in die Pascalsprache einarbeiten können, aber er hätte für alles mögliche, was er als Syntax oder unter Nutzung siener Bibliotheken so in C++ runterschreibt, in Pascalsprache auch umsetzen können, aber dann wäre das sicherlich nicht in 2 jahren erledigt gewesen. Mit geht das umgekehrt ziemlich ähnlich. Mittlerweile mehr 20 Jahre Pascalsprache/vcl/lcl in Delphi/Lazarus sorgen dafür, das ich nur in wenigen Fällen irgendein Verfahren suchen muss (meistens hier), um etwas umzusetzen. Schnick Schnack wie grüne Buttons oder sonstigen GUI Kram ersetze ich gerne durch Ownerdraw oder Konstuktionen mit TPanels o.ä., im gesunden Bewusstsein, das ich dieses Verfahren auch noch dann einsetzen kann, wenn irgendein Komponentenhersteller kein Bock mehr hat, weil er kein Geld mehr verdient und deswegen seine Komponenten nicht mehr weiterentwickelt werden. Da eh alles zur Laufzeit kommt, ist mir die Bedienbarkeit im Objektinspektor eh egal. Eine simple MakeButton(....) Funktion unterstützt dabei mittlerweile je nach globaler Config diverse icon libs, drag and drop auf favoriten toolbar, touch Bedienung, resizing, autoalign, u.v.m. Sicherlich gibt es sowohl bei VS als auch für Delphi diverse Komponenten, die das alles besser und einfacher können, brauch ich aber trotzdem nicht, weil ich da einfach auch in 20 jahren zu viel kennengelernt hab, was es schon lange nicht mehr gibt. Mein ganz entscheidener Vorteil ist aber auch, das ich als Chef in unserem Unternehmen selber entscheiden kann, womit wir arbeiten. Wer als Angestellter in seiner aktuellen Position das nehmen muss, was sein Chef sagt, hat da schon eine ganz andere Position. Und wer dazu eh kein Bock hat und sich daher eine neue Stelle sucht, der ist vielleicht mit der Pascalsprache nicht unbedingt extrem gefragt, aber man sollte nicht unterschätzen, das man durch auch bei entsprechender Kompetenz und Erfahrung sehr gute Gehälter fordern kann, denn in vielen Unternehmen erreichen die Delphi Programmierer mittlerweile ein Alter, das nicht merh weit von der Rente entfernt ist. Das sehe ich bei einigen Kunden und diverse Kunden suchen auch mehr oder weniger aktiv Nachfolger für solche Entwickler und würden gerne auch jemanden nehmen, der noch nicht 100% auf der Kappe hat, aber lernfähig ist und sich mit dem, was bereits vorhanden ist, aktiv auseinander setzen möchte, ohne immer nur zu hören, das man das alles besser neu schreiben sollte ..... Wer Delphi nach x Jahren also durch was anderes ersetzen möchte, muss sich immer überlegen, welches Know How man dabei neu lernen möchte. irgendwelche blöden Schleifekonstrukte und Variablen sind dabei noch geringste Problem. Das wahre Vokabular lernst du erst durch konkrete Anwendung. Die Bedienung der IDE gehört dazu. F5 oder F9 lernt man schnell, aber ein Delphi VCL Projekt mit den ganzen Units in eine standardkonforme VS Solution zu übertragen, ist da alleine schon ein wenig mehr Aufwand. Und dadurch hast du noch keinerlei Vorteil, wenn deinen Kunden oder Chef nur die Funktionalität der Executable interessiert und von dir keine Ausreden anhören will, warum du zwar viel Geld kassierst oder zeit verballerst, aber seit 2-4 Jahren an der Portierung arbeitest, ohne das dadurch eine identisch bedienbare Software mit gleichem Funktionsumfang zu erstellen. |
AW: Delphi langsam ersetzen
Zitat:
Zitat:
Übrigens: Wer in seiner Delphiwohlfühlblase mit Delphi klar kommt: Toll. Man kann ja mit Delphi wirklich so ziemlich alles machen. Na ja. Außer: Ein Team zusammenstellen. Aber lassen wir das. Man kann auch mit VB oder mit irgendeiner antiquarischen Sprache sehr viel machen, wenn man sie denn beherrscht. Aber, Holger. Das ist doch kein Argument. Außer vielleicht der letzte Strohalm, bevor man erkennt.... :kopfschuettel: Nochmal: Das Thema lautet.... "Von Delphi weg... aber langsam"... |
AW: Delphi langsam ersetzen
Ohne alles gelesen zu haben. Ich bin an Lazarus und Freepascal gescheitert. Meine einfache Idee: Auf dem Smartphone (Android) einfach nur Dateien löschen. Unter WhatsApp/Images und die Thumbnails.
Ich habe alles so wie in einem Tutorial beschrieben installiert. Ich habe nicht mal eine einfache Form für Android kompiliert bekommen. Sehr ernüchternd und demotivierend. Meine Idee war eine App, wo man per Checkbox einfach anhakt, was wo gelöscht werden soll. Nichts wildes. Drei, vier Checkboxen und einen "Mach es"-Button. Es hat nicht funktioniert.:cry: Ich wäre ja gerne bereit für die neuen Technologie, aber nicht so. Wenn man sich die Entwicklungsumgebung zusammenfricklen muss. |
AW: Delphi langsam ersetzen
Das funktioniert mit Delphi in der Regel problemlos. Sofern der debug Treiber für dein Gerät installiert ist, genügt es wenn du Delphi installierst und dann das Handy anschließt und F9 drückst. Für das Formular kannst Du mit Delphi arbeiten wie sonst auch. Nur dass es eben firemonkey ist, aber das macht bei so einfachen Apps keinen Unterschied.
|
AW: Delphi langsam ersetzen
Ja, Michael wollte es aber gerade mit Alternativen probieren. ;-)
Es wäre aber gut, wenn Ihr wieder sachlich zum Thema kommen würdet. Die üblichen Floskeln der "ehemaligen Delphianer" bezüglich der "Wohlfühlblase" etc. bringen uns nicht weiter und sind nicht weniger enervierend als im vergangenen Jahr. Es ist einfach müßig. |
AW: Delphi langsam ersetzen
In einem Thread, in dem es um Alternativen zu Delphi geht, ist die Wohlfühlblase beim Erscheinen sehr wohl anzumahnen. Genauso, wie der berühmte Tellerrand, über den hier komischerweise noch nicht berichtet wurde.
Im Übrigen hat gerade einer der "ehemaligen Delphianer" das Abweichen vom Thema angemahnt. |
AW: Delphi langsam ersetzen
Zitat:
Sicherlich ist vieles auch durch Open Source zugrunde gegangen, aber Microsoft konnte alle Entwicklungswerkzeuge mit den Erlösen anderer Produkte (Office und Windows) subventionieren. Und einige Sachen (z.B. Foxpro) hat man einfach gekauft und eingestampft. Ob Foxpro gut ist oder nicht lass ich dabei mal jeden selbst entscheiden, dbase im Hause Borland hatte ja ein ähnliches Schicksal. Zitat:
Zitat:
Die IDE und Programmiersprache ist nur ein Baustein für den Erfolg eines Softwareprojektes, Prozesswissen und Softwarearchitektur sind aus meiner Sicht aber wesentlich wichtiger im Wettbewerb. Wenn man kein generelles personenunabhängiges Konzept für eine langlebige Softwarearchitektur hat, wird man mit den vorhandenen Ressourcen eh irgendwann an der Komplexität der Materie scheitern, egal in welcher Programmiersprache und mit welcher IDE. Ich sehe daher auch sehr oft im Kundenauftrag über den eigenen Tellerrand hinaus und diskutier mit Kunden deren Performanceprobleme, meistens im Bereich Datenbanken, aber auch oft in Hinblck auf Softwarearchitektur. Da sind auch Kunden mit Java, VS c++, c# oder eben auch Delphi dabei. Dabei wird oft deutlich, das die keine eigene Softwarearchitektur haben, sondern sich einfach leiten lassen nach der Devise: Ich mal das einfach mal so weil ich das schon immer so gemacht hab und weil es funktioniert. Ob nun Delphi einen dazu verleitet, einfach alles zusammenzuklicken und damit nicht wirklich wartungsfähige Software erstellt, muss jeder selbst entscheiden. Wer ein komplexes Delphi Projekte mit tausenden irgendwo verteilten Datasource/Datasets hat, macht was falsch! Das ist eine Sackgasse. Für kleine Projekte oder wenn man mal eben was zusammenklöppelt, an dem man eh nichts mehr ändern muss, ist das ok. Den gleichen Schrott fangen viele dann aber auch in anderen Programmiersprachen an, weil die es es nicht besser wissen. Delphi langsam ersetzen ist zwar der original Thread aber ich würde jedem vorher empfehlen, eine geeignete Softwarearchitektur zu entwickeln und basierend darauf dann auszuwählen, ob das mit Delphi, VS, java oder als Webapp umgesetzt werden soll. Viele setzen zwar eine Pseudosoftwarearchitektur auf Basis von Delphi Klassen ein, die ist aber oft schon in jede 2. Zeile mit TDataset verheiratet, so das die auf anderen Plattformen so gar nicht mehr implementierbar sind. Das hat auch nichts mit einer Delphi Wohlfühlblase zu tun, wenn du eine Architektur als Backend hast ist, dann ist die Programmiersprache und IDE extrem austauschbar. Ohne Architektur machst du in der nächsten Welt viele Fehler wieder und hast nur den Teufel durch den Belzebub ersetzt. |
AW: Delphi langsam ersetzen
Jupp, so isses.
Wir sind aktuell dabei, nach längerer Vorbereitung der Architektur in Delphi, unser Backend nach Oxygene zu portieren, sodass es auf .Net,Java und iOS läuft. Wenn man die Eigenheiten aller Plattformen beachtet und keine Abhängigkeiten in Delphi erzeugt, klappt das ganz gut. Aktuell lässt sich so einfach viel rüber kopieren und es müssen nur noch die Oxygene-eigenen Sprachmerkmale angepasst werden. Wir haben lange überlegt, ob wir alles in den jeweiligen Sprachen direkt neu schreiben, haben uns aber vorerst dagegen entschieden. |
AW: Delphi langsam ersetzen
Zitat:
Eine Frage habe ich zur praktischen Anwendung der "Softwarearchitektur". Ich habe mich mit dem Thema Systemarchitektur schon oft auseinandergesetzt und kenne zum Beispiel den amerikanischen Verteidigungsstandard DoDAF zur Definition einer Architektur. Mich würde interessieren, wie ihr die Architektur definiert und nach Delphi bzw. Lazarus umgesetzt habt. Nutzt ihr UML, wenn ja, welches Tool und welche Ansichten. Beschränkt sich die Architektur auf Klassendiagramme oder geht sie darüber hinaus? |
AW: Delphi langsam ersetzen
Ich finde es unglücklich, in einem professionellen Umfeld aus Gründen des Monopolboykotts auf ein kleineres Produkt einzusetzen.
Ich fände es logisch, in einem professionellen Umfeld das Produkt einzusetzen, das für die Aufgabe am Besten geeignet ist. Und Delphi ist ja nun nicht gerade ungeeignet. Ja, es ist schade, das Microsoft andere Anbieter verdrängt. Aber ein gutes Produkt verdrängt nun einmal weniger gute. Zitat:
|
AW: Delphi langsam ersetzen
"Delphi langsam ersetzen" was sagt uns denn das ? Da will einer Delphi ersetzen, aber langsam. Toll. Langsam bedeutet dann wohl ungefähr : wasch mich aber mach mich nicht nass. :P Mir stellt sich da die Frage, welchen Vorteil sich der Fragesteller denn erhofft ? Haha, ich habe das komplett anders gemacht. Delphi bzw. Pascal richig gelernt und dann 1986 erstes Programm verkauft. Dürfte so 1984 gewesen sein, dass ich da angefangen habe, das zu programmieren.
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 19:51 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz