![]() |
Re: Nativer Programmcode
Hallo,
die Frage ist doch: Warum Delphi? 1. Nur ein Programm, das ggfls. auch ohne Installation auskommt. 2. Mit Delphi kann man extrem schnell Programmieren. Eine Datenbankanwendung kann da schon mal in 'ner halben Stunde fertig sein. 3. Delphi enthält für vielfältige Aufgaben Komponenten, die man einfach benutzen kann. 4. Für Delphi gibt es eine Unmenge freier Zusatzkomponenten, die man ebenfalls einfach nutzen kann. 5. Die Entwicklungsumgebung verfügt über eine gute Hilfe. 6. Die Programme, die man erstellt, sind schnell. 7. Die Einarbeitung in die Entwicklungsumgebung ist kurz (auch dank der IDE, die einem schon beim Programmieren sagt, wie's richtig geht oder ob was falsch ist
Delphi-Quellcode:
dauert keine Sekunde und keinen Kompilerlauf...
([Pascal Fehler] xxx.pas(1): Die Programmierhilfe kann nicht aufgerufen werden, da der Quelltext Fehler enthält)
8. Die Entwicklungsumgebung läßt sich "gnadenlos" um eigene Werkzeuge (Experten) ergänzen. 9. Die Anderen können heute teilweise erst das, was Delphi schon vor 10 Jahren konnte, die Entwicklungsumgebung ist den anderen Entwicklungsumgebungen in der Regel um einiges voraus. 10. In der CT war vor einiger Zeit ein Vergleich von C++, Java und Delphi. Java und Delphi waren danach in der Ausführung schneller als C++, bei Java mit der Einschränkung, dass der Vergleich nur für Serverapplikationen (ohne GUI) zutraf. 11. Wer mit Google umgehen kann, findet auch zu ausgefallenen Problemen in den diversen Foren kompetente Hilfe. 12. Keine Abhängigkeit von "Drittanbietern", die eventuell benutze Komponenten, DLL's, OCX's... durch Updates (anderer Software) inkompatibel machen. 13. Keine Abhängigkeit von Laufzeitumgebungen, die gepflegt werden müssen (Updates, Bugfixing...) 14. Delphianwendungen laufen auch auf nicht ganz so leistungsfähiger Hardware mit ordentlichem Tempo. 15. Die Programmiersprache lässt nicht soviel Unfug zu, der zu Sicherheitslöchern werden kann (Typsicherheit, wenn nicht, wird man darüber informiert). nochwas? Stephan PS: Ein Beispiel aus meiner Erfahrung zu Delphi und C++: Vor Jahren wurde für einen Kunden eine Software mit C++ (MS) erstellt. Leider ist es den Entwicklern innerhalb eines halben Jahres nicht gelungen, allen Anforderungen des Kunden gerecht zu werden Oberflächendesign, Bedienbarkeit..). Also was tuen: Zum Kunden gehen und sagen: "tut uns leid, können wir nicht" oder neumachen. Entscheidung war neumachen. Der Kunde ist vierzehn Tage später pünktlich zum vorgesehenen Termin mit der Software in Produktion gegangen, hat den Wechsel der Entwicklungsumgebung nicht bemerkt und fand die "neue" Software deutlich schöner und besser Bedienbar. |
Re: Nativer Programmcode
IMHO sind C, ASM und Fortran nicht objektorientiert. Bitte korrigiert mich, wenns doch anders ist.
|
Re: Nativer Programmcode
@nahpets:
Ich hab zwar noch keine kommerzielle Software mit C# programmiert, aber ich behaupte mal, dass viele dieser Punkte auch auf C# zutreffend sind. z.B. ist das msdn für c# vergleichbar mit der delphi hilfe und die .net Komponenten sind auch reltiv vielseitig. Zitat:
Was ich damit sagen will, ist nicht dass Delphi doof ist. Das hätte ich auch in 3 Wörtern sagen können. Aber es ist einfach falsch zu sagen dass Delphi am besten ist und alle anderen Dreck. (gilt genauso für jede andere Sprache, kommt imer auf den Einsatzzweck an ...) Falls isch deinen Post falsch interpretiert hab, tut mir leid, aber der Klingt irgendwie sehr einseitig ;) (Andererseits verlangt der Threadposter eine einseitige Argumentation ... :gruebel: ) |
Re: Nativer Programmcode
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
|
Re: Nativer Programmcode
Hallo,
Zitat:
Ein Kollege von mir kämpft gerade mit einer Oberfläche für Java, abhängig von der Bildschirmgröße ändert sich die Darstellung der Markierungsbalken in den Listviews, sprich: Kleine Größe, dann passt der Balken, große Größe, dann sitzt er irgendwie so ein paar Pixel zu hoch. Der Kollege sucht jetzt schon 'ne Weile, wo denn die Ursache ist. Das sind halt Probleme, die ich von Delphi nicht kenne. Oder ein Problem der letzten Tage: Doppelklick auf ein Formular löst gewünschtes Ereignis aus, aber leider wirkt der Doppelklick auch noch in der anschließend aktuallisierten Anzeige, so dass dort zuweilen eine weitere, aber diesmal unerwünschte Aktion ausgeführt wird. Okay, C# ist deutlich neuer als alle Anderen, der "Chefentwickler" ist der gleiche wie ursprünglich bei Delphi und Microsoft hat dafür wohl auch viel Geld bezahlt (nicht nur für den Entwickler, sondern auch für die Patente). Meine praktische Erfahrung ist halt, dass ich mit Delphi vieles schneller und aus Anwendersicht besser mache, als Kollegen mit anderen Entwicklungsumgebungen. Das heißt nicht, dass ich besser bin und die Anderen schlechter. Zumindest für meine Art zu arbeiten scheint Delphi die beste (bessere?) Lösung zu sein, das muss für niemanden sonst auf der Welt gelten. Und mir liegt die Sprache Pascal einfach besser als C++ und Co.. Mit diesen Sprachen habe ich einfach Probleme, kommt mir vor wie "Rückwärtsdenken", gilt auch nur für mich und muss nicht für irgendsonstwen gelten. Ich halte es aber für okay, wenn ich gegenüber wem auch immer begründen muss, warum "Dies" und nicht "Das", dass ich hier ein bisserl subjektiv bin (ist in der Werbung so üblich). Jeder stellt die Vorteile seines "Werkzeuges" heraus, was auch okay ist, man muss ja schließlich damit arbeiten und wird an den Ergebnissen gemessen. @Bernhard Prinzipiell kannst Du jedes meiner Argumente ad absurdum führen (ist auch okay) aber gegenüber "Entscheidungsträgern" darf und muss man schonmal ein bisserl Dick auftragen, sonst wird immer dass genommen, was die gerade für Hip halten und nicht das, was für das spezielle Projekt am Besten ist. (Ich kenne Delphi nur bis Version 7, über neuere Versionen kann ich mich nicht auslassen.) Fremdkomponenten nutze ich nur, wenn ich den Quelltext habe, auf schwarze Löscher lasse ich mich nicht ein. Für mich fühlen sich GUI's mit Delphi immernoch schneller und besser bedienbar an, als die mit Java, natürlich ist das subjektiv und jeder darf das anders sehen. Woran es liegt weiß ich nicht, aber mir fällt regelmäßig bei Programmen auf: Hui, die könnten in Delphi geschrieben sein und wenn ich dann nachschaue, ist das auch so. Keine Ahnung, woran das liegt und keine Ahnung, ob ich das bei jedem mit Delphi geschriebenen Programm merke. Wenn ich mir anschau, wie schön schnell Delphi 7 auf meinem 750 Penti II mit 512 MB läuft, ob da Eclipse auch noch bedienbar ist? Zitat:
Bisher habe ich ausser der Exe noch nichts an den Kunden gegeben, so dass der Kunde nicht durch Fehler in der VCL... direkt betroffen ist, da muss ich das Programm neu ausliefern. Ich meinte eigentlich damit, dass Programme anderer Anbieter durchaus mal mit ihrer Installation in System32 die eine oder andere DLL austauschen und dies Nebenwirkungen hat. Die VCL ist nicht fehlerfrei, da hab' ich schon selbst Fehler rausgemacht um strubbeliges Verhaltem im Programm zu vermeiden. Bei Delphi wird auch nur mit Wasser gekocht, aber muss ich das jemandem, den ich überzeugen möchte, direkt auf die Nase binden? Stephan |
Re: Nativer Programmcode
@Bernhard: Warum arbeitest du dann in Delphi, wenn Delphi so scheisse ist?
Java und C# sind definitiv nicht nativ! |
Re: Nativer Programmcode
Zitat:
|
Re: Nativer Programmcode
Zitat:
Zitat:
Zitat:
Zitat:
Und ich kenne (noch) kein GUI-Framework was nicht irgendwelche Macken hätte. Schön ist ebenfalls was anderes. Zitat:
Zitat:
Zitat:
Alle anderen Punkte: FullAck |
Re: Nativer Programmcode
C# und dem Visual Studio gehört eh die Zukunft. Aber das war sowieso nicht die Frage. Die Frage war, welche IDE für OOP gibt es, die direkt ausführbaren Code produzieren.
|
Re: Nativer Programmcode
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:18 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 by Thomas Breitkreuz