Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi Nativer Programmcode (https://www.delphipraxis.net/120839-nativer-programmcode.html)

S20000 17. Sep 2008 14:41


Nativer Programmcode
 
Hallo zusammen,

mit Delphi erzeuge ich ja exe-Dateien, die ohne Installation
von Laufzeitumgebungen auf verschiedenen Rechnern ausführbar sind.

Meine Frage ist, welche objektorientierten
Programmiersprachen können das noch? Die Frage Zielt
darauf ab, dass ich jemanden begründen soll warum ich DELPHI
für ein Projekt auswähle...

Gruß
Sebastian

Namenloser 17. Sep 2008 14:43

Re: Nativer Programmcode
 
Spontan fällt mir da C++ ein

Bernhard Geyer 17. Sep 2008 14:44

Re: Nativer Programmcode
 
C++, Java (Aufruf mit Java ....).

Der Vorteil von Delphi ist das viele der verfügbaren Komponenten auch keine Registrierung benötigen (im Gegensatz z.B. zu VB6 mit seiner COM-DLL-Hölle).

Weazy 17. Sep 2008 14:51

Re: Nativer Programmcode
 
Java eben nicht, braucht wie .Net eben eine Virtuelle Maschiene. Spontan fallen mir C,C++,VisualBasic (nur die alten Vesionen welche nicht in .Net compilieren) und Assembler (ok, damit wirst du deine apps nicht schreiben wollen...) ein. Jede Sprache hat so seine Vor-und Nachteile, musst du halt auf deinem Können und nach deiner Applikation ausrichten.

MrKnogge 17. Sep 2008 14:54

Re: Nativer Programmcode
 
Neben den genannten noch Fortran und weitere, ich glaube es ist leichter nach Programmiersprachen zu fragen, deren Programme eine Runtime brauchen, da wirst du eindeutig weniger zusammen bekommen...

Bernhard Geyer 17. Sep 2008 14:56

Re: Nativer Programmcode
 
Zitat:

Zitat von Weazy
Java eben nicht, braucht wie .Net eben eine Virtuelle Maschiene.

Java braucht nicht installiert werden und das war doch die Frage!

Zitat:

die ohne Installation von Laufzeitumgebungen auf verschiedenen Rechnern ausführbar sind

Meflin 17. Sep 2008 15:01

Re: Nativer Programmcode
 
Zitat:

Zitat von Weazy
Java eben nicht, braucht wie .Net eben eine Virtuelle Maschiene.

Nicht unbedingt. Es gibt auch Ahead-of-Time-Compiler für Java!

Weazy 17. Sep 2008 15:02

Re: Nativer Programmcode
 
Doch, java läuft auf einer Virtuellen Maschiene=Laufzeitumgebung die installiert werden muss! Da Java sehr beliebt ist ist java oft vorinstalliert. Habe kürzlich einen MSI Wind gekauft mit XP drauf. Da musste ich auch erst die Umgebung installieren das Java Programme überhaupt laufen. Vielleicht meinst du JavaScript? Das muss soviel ich weiss nicht installiert werden, bin mir aber nicht sicher...

Ok, mit den ahead-of-time compilern gebe ich dir recht, aber grundsätzlich braucht java eine Laufzeitumgebung die installiert werden muss...

Phoenix 17. Sep 2008 15:10

Re: Nativer Programmcode
 
Zitat:

Zitat von Weazy
=Laufzeitumgebung die installiert werden muss!

Nein, die Java Runtime muss nicht installiert werden.
Der SQL Developer von Oracle ist z.B. eine Java-Anwendung die einwandfrei ohne installierte VM läuft. Nagut - die 140 MB Runtime liegen halt in einem Ordner unterhalb der Anwendung und wird von dort angezogen - aber es ist eben keine Installation notwendig.

Und genausowenig muss zwingend eine .NET Runtime installiert werden. Wenn die Anwendung auf Mono läuft kann man das genauso einfach so dazulegen und that's it.

Edit: Verklickt.. anstelle von Edit geantwortet :roll:

Bernhard Geyer 17. Sep 2008 15:17

Re: Nativer Programmcode
 
Zitat:

Zitat von Weazy
Doch, java läuft auf einer Virtuellen Maschiene=Laufzeitumgebung die installiert werden muss!

Nein, mußt du nicht. Für eine Java-Anwendugn im Browser wirst du es installieren müssen. Aber bei 0815-Desktopanwendung nicht (nicht umsonsten verwenden wird schon 2-3 Java-Komponenten in unserer App mit JNI und ohne Installation von Java!)

nahpets 17. Sep 2008 15:32

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:
([Pascal Fehler] xxx.pas(1): Die Programmierhilfe kann nicht aufgerufen werden, da der Quelltext Fehler enthält)
dauert keine Sekunde und keinen Kompilerlauf...
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.

Reinhardtinho 17. Sep 2008 15:34

Re: Nativer Programmcode
 
IMHO sind C, ASM und Fortran nicht objektorientiert. Bitte korrigiert mich, wenns doch anders ist.

jfheins 17. Sep 2008 16:12

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:

Die Anderen können heute teilweise erst das, was Delphi schon vor 10 Jahren konnte
Andersherum gibt es diverse Beispiele - aber dazu fällt mir wenig ein ...

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: )

Bernhard Geyer 17. Sep 2008 16:49

Re: Nativer Programmcode
 
Zitat:

Zitat von nahpets
2. Mit Delphi kann man extrem schnell Programmieren. Eine Datenbankanwendung kann da schon mal in 'ner halben Stunde fertig sein.

Bekommst du (mit mehr know how) auch unter .NET und Java hin

Zitat:

Zitat von nahpets
3. Delphi enthält für vielfältige Aufgaben Komponenten, die man einfach benutzen kann.

.NET und Java auch und noch viel mehr. Schon mal eine vollständige SVG-Implementierung in Delphi gesehen?

Zitat:

Zitat von nahpets
4. Für Delphi gibt es eine Unmenge freier Zusatzkomponenten, die man ebenfalls einfach nutzen kann.

Trifft für .NET und Java auch zu. Bei Java wäre z.B. das Apache-Projekt mit all seinen "Ablegern" genannt.

Zitat:

Zitat von nahpets
5. Die Entwicklungsumgebung verfügt über eine gute Hilfe.

Stimmt bis D7 und ab D2009. Bei D8-22006 würde ich eher von "dunklen Mitttelalter" reden

Zitat:

Zitat von nahpets
6. Die Programme, die man erstellt, sind schnell.

Ist Java und .NET auch der Fall.

Zitat:

Zitat von nahpets
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

Würde ich bei vernünfiger .NET oder Java-IDE auch sagen. Bei Java aber nicht 100% so einfach.

Zitat:

Zitat von nahpets
dauert keine Sekunde und keinen Kompilerlauf...

Dauert bei Java und .NET auch nicht viel länger.

Zitat:

Zitat von nahpets
8. Die Entwicklungsumgebung läßt sich "gnadenlos" um eigene Werkzeuge (Experten) ergänzen.

Bei "gnadenlos" fällt mir eclipse ein.

Zitat:

Zitat von nahpets
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.

Seit VS.NET 2002/2003 hinkt Delphi in einigen Bereichen hinterher.

Zitat:

Zitat von nahpets
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.

GUI und Java ist auch kein Problem - Nicht alle GUI-Frameworks unter Java sind langsam. C++ hatte seine Probleme mit Vererbung/Overloading soweit ich noch weis.

Zitat:

Zitat von nahpets
11. Wer mit Google umgehen kann, findet auch zu ausgefallenen Problemen in den diversen Foren kompetente Hilfe.

Für Java und .NET (und PHP und Ruby und ...) genauso.

Zitat:

Zitat von nahpets
12. Keine Abhängigkeit von "Drittanbietern", die eventuell benutze Komponenten, DLL's, OCX's... durch Updates (anderer Software) inkompatibel machen.

Wenn du keine Pascal-Sourcen der Kompos hast bist du bei Delphi noch viel schlechter dran.

Zitat:

Zitat von nahpets
13. Keine Abhängigkeit von Laufzeitumgebungen, die gepflegt werden müssen (Updates, Bugfixing...)

Die Laufzeitumgebung von Delphi (VCL/Base-CLX/RTL) ist wohl Fehlerfrei :gruebel:

Zitat:

Zitat von nahpets
14. Delphianwendungen laufen auch auf nicht ganz so leistungsfähiger Hardware mit ordentlichem Tempo.

Dafür ist es schwerer moderne HW komplett auszulasten.

Zitat:

Zitat von nahpets
15. Die Programmiersprache lässt nicht soviel Unfug zu, der zu Sicherheitslöchern werden kann (Typsicherheit, wenn nicht, wird man darüber informiert).

Java und .NET noch viel weniger das sie managed Laufzeitumgebungen sind.


Zitat:

Zitat von nahpets
PS: Ein Beispiel aus meiner Erfahrung zu Delphi und C++:
Vor Jahren wurde für einen Kunden eine Software mit C++ (MS) erstellt. ...

MFC und ATL halte ich auch für Schrott. Ich hoffe nie mehr damit zu tun zu haben.

nahpets 17. Sep 2008 17:17

Re: Nativer Programmcode
 
Hallo,
Zitat:

(Andererseits verlangt der Threadposter eine einseitige Argumentation ... :gruebel: )
natürlich war meine Argumentation darauf angesetzt, wie soll ich hier bei uns klarmachen, wenn ich sage: Die Anderen können es mindestens genauso gut oder besser :wink: und Sebastian fragte ja auch danach, warum Delphi und nicht warum vielleicht besser doch nicht Delphi :P .

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:

Für Java und .NET (und PHP und Ruby und ...) genauso.
Wenn dem so ist (hab's nicht überprüft), warum wird's dann im Kollegenkreis so wenig genutzt? Da muss ich die wohl mal ein bisserl treten :wink:

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

mkinzler 17. Sep 2008 17:18

Re: Nativer Programmcode
 
@Bernhard: Warum arbeitest du dann in Delphi, wenn Delphi so scheisse ist?
Java und C# sind definitiv nicht nativ!

Die Muhkuh 17. Sep 2008 17:21

Re: Nativer Programmcode
 
Zitat:

Zitat von mkinzler
@Bernhard: Warum arbeitest du dann in Delphi, wenn Delphi so scheisse ist?

Das hat er doch nirgendwo behauptet.

inherited 17. Sep 2008 17:38

Re: Nativer Programmcode
 
Zitat:

Zitat von Bernhard Geyer
Zitat:

Zitat von nahpets
2. Mit Delphi kann man extrem schnell Programmieren. Eine Datenbankanwendung kann da schon mal in 'ner halben Stunde fertig sein.

Bekommst du (mit mehr know how) auch unter .NET und Java hin

Ich behaupte mit mehr LOC
Zitat:

Zitat:

Zitat von nahpets
3. Delphi enthält für vielfältige Aufgaben Komponenten, die man einfach benutzen kann.

.NET und Java auch und noch viel mehr. Schon mal eine vollständige SVG-Implementierung in Delphi gesehen?
Ich kenne keine mit JVCL vergleichbare Komponenten-Library für Java.
Zitat:


Zitat:

Zitat von nahpets
6. Die Programme, die man erstellt, sind schnell.

Ist Java und .NET auch der Fall.
Theoretisch ja, aus erfahrung kann ich sagen, dass Java um einiges Süpeicherhungriger ist. Auf 256mb will NetBeans nicht mal starten. Delphi hingegen stellt kein problem dar.
Zitat:

Zitat:

Zitat von nahpets
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.

GUI und Java ist auch kein Problem - Nicht alle GUI-Frameworks unter Java sind langsam. C++ hatte seine Probleme mit Vererbung/Overloading soweit ich noch weis.
Das Problem ist, das Java eben auf allen Plattformen laufen muss, so stellt auch die Grafikklasse nur Schnittmengen aus allen Window-Systemen bereit.
Und ich kenne (noch) kein GUI-Framework was nicht irgendwelche Macken hätte. Schön ist ebenfalls was anderes.
Zitat:

Zitat:

Zitat von nahpets
11. Wer mit Google umgehen kann, findet auch zu ausgefallenen Problemen in den diversen Foren kompetente Hilfe.

Für Java und .NET (und PHP und Ruby und ...) genauso.
Nicht zu so manchen Hardwarenahen Fragen.
Zitat:

Zitat:

Zitat von nahpets
14. Delphianwendungen laufen auch auf nicht ganz so leistungsfähiger Hardware mit ordentlichem Tempo.

Dafür ist es schwerer moderne HW komplett auszulasten.
Wie meinst du das? :gruebel:
Zitat:

Zitat:

Zitat von nahpets
15. Die Programmiersprache lässt nicht soviel Unfug zu, der zu Sicherheitslöchern werden kann (Typsicherheit, wenn nicht, wird man darüber informiert).

Java und .NET noch viel weniger das sie managed Laufzeitumgebungen sind.
Dafür hat man (meiner Meinung nach, ich mag nunmal Pointer) weniger Möglichkeiten. Je nachdem, was man möchte, kann das also ein Vor- oder Nachteil sein.

Alle anderen Punkte: FullAck

alzaimar 17. Sep 2008 18:06

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.

Meflin 17. Sep 2008 18:18

Re: Nativer Programmcode
 
Zitat:

Zitat von mkinzler
Java und C# sind definitiv nicht nativ!

Bullshit. Es gibt native Compiler für Java!

mkinzler 17. Sep 2008 18:21

Re: Nativer Programmcode
 
Sorry, ich nehm alles was ich je hier gesagt habe zurück.
:wall:

daniel-h 17. Sep 2008 18:39

Re: Nativer Programmcode
 
visual basic fällt mir noch ein,
aber delphi ist bessa :warn:

Die Muhkuh 17. Sep 2008 18:40

Re: Nativer Programmcode
 
Zitat:

Zitat von S20000
die ohne Installation
von Laufzeitumgebungen auf verschiedenen Rechnern ausführbar sind.

Wenn man Windows als Laufzeitumgebung ansieht :stupid:

Namenloser 17. Sep 2008 18:44

Re: Nativer Programmcode
 
Zitat:

Zitat von daniel-h
visual basic fällt mir noch ein,
aber delphi ist bessa :warn:

Wurde bereits gesagt, aber 1. ist VB eben schrott, und 2. sind die neueren versionen .net-basiert.

Ralf Kaiser 17. Sep 2008 18:48

Re: Nativer Programmcode
 
Zitat:

Zitat von nahpets

nochwas?

Für Delphi gibt es eine große Community die einem hilft so manches Problem schnell zu lösen (aber wem erzähl ich das ausgerechnet hier in der DP??...)

Bernhard Geyer 17. Sep 2008 20:41

Re: Nativer Programmcode
 
Zitat:

Zitat:

Zitat von mkinzler
@Bernhard: Warum arbeitest du dann in Delphi, wenn Delphi so scheisse ist?

Das hat er doch nirgendwo behauptet.
Stimmt. Aber mit Delphi hat man auf dem Server (Webbasierte Lösung) wenig Chancen und Linxu/MacOS ist auch nicht so richtig.

Zitat:

Ich behaupte mit mehr LOC
Für einfache RAD mit direkter DB-Anbindung der Sensitiven Controls ist es mit Delphi schneller. Aber sobald es auf Multi-DB-Support geht ist man mit JDBC einfacher dran. Die nativen DB-Zugriffskompos diverser DBs haben unter Delphi eine höhere diversität als unter JDBC.

Zitat:

Ich kenne keine mit JVCL vergleichbare Komponenten-Library für Java.
Dazu müsste ich erst mal wieder schauen wie gut die geschenkten Kompos wirklich zusammenpassen. Zeitweise sind ja monatlich Kompo-Sammlungen dazugekommen die sich teilweise überschnitten haben.

Zitat:

Theoretisch ja, aus erfahrung kann ich sagen, dass Java um einiges Süpeicherhungriger ist. Auf 256mb will NetBeans nicht mal starten. Delphi hingegen stellt kein problem dar.
Schon mal Delphi 2007/2009 gestartet?

Zitat:

Zitat:

Zitat von Bernhard Geyer
Dafür ist es schwerer moderne HW komplett auszulasten.

Wie meinst du das? :gruebel:
Bessere Multithreading-Unterstützung. Load-Balancing bei Server-Anwendungen, ...

Zitat:

Dafür hat man (meiner Meinung nach, ich mag nunmal Pointer) weniger Möglichkeiten. Je nachdem, was man möchte, kann das also ein Vor- oder Nachteil sein.
Wenn man für Manche Lösungen viele Pointerei braucht dann ja. Aber ich vermeide es wo es nur geht mit untypisierten Zeigern zu arbeiten.

inherited 17. Sep 2008 21:16

Re: Nativer Programmcode
 
Wir kommen also im Großen und Ganzen darüber überein, dass es immer darauf ankommt, was man machen möchte. Wirklich neu ist diese Erkenntnis ja nicht.


P.S: Ich bin nicht die dicke Muhkuh :cry:

Bernhard Geyer 17. Sep 2008 21:22

Re: Nativer Programmcode
 
Zitat:

Zitat von inherited
Wir kommen also im Großen und Ganzen darüber überein, dass es immer darauf ankommt, was man machen möchte. Wirklich neu ist diese Erkenntnis ja nicht.

Aber gut das wir mal wieder darüber gesprochen haben :mrgreen:


Zitat:

Zitat von inherited
P.S: Ich bin nicht die dicke Muhkuh :cry:

Mit Laptop und Touchpad passiert das schon mal :oops:

S20000 18. Sep 2008 08:00

Re: Nativer Programmcode
 
Danke für die rege Beteiligung. Ich muss demnächst mein Projekt vorstellen
und habe als Entwicklungsumgebung eben Delphi gewählt. Es geht um die
Erstellung einer GUI, jetzt muss ich begründen warum ich Delphi gewählt habe.

divBy0 18. Sep 2008 08:11

Re: Nativer Programmcode
 
Dann frage ich dich doch einfach mal warum du Delphi gewählt hast?

nahpets 18. Sep 2008 08:50

Re: Nativer Programmcode
 
Hallo,

Zitat:

Zitat von Bernhard Geyer
Für einfache RAD mit direkter DB-Anbindung der Sensitiven Controls ist es mit Delphi schneller. Aber sobald es auf Multi-DB-Support geht ist man mit JDBC einfacher dran. Die nativen DB-Zugriffskompos diverser DBs haben unter Delphi eine höhere diversität als unter JDBC.

Wie meinst Du das?

Ich habe mir vor Jahren angewöhnt bei Datenbankanwendungen alle SQL's in eine Datenbanktabelle zu legen und aus dem Programm nurnoch die SQL's per ID aus dieser Tabelle zu lesen. Alles Andere geht über ADO (ist sicherlich nicht immer das Leistungsfähigste, aber für mich das Unabhängigste - mit der BDE war vieles einfacher, aber das ist halt Schnee von gestern). In einer INI steht der Connectionstring und kann ggfls. über die Applikation geändert werden. Damit bin ich datenbankunabhängig. Wird die Datenbank gewechselt, muss ich den Connectionstring ändern, gibt's dann Inkompabilitäten, weil SQL nicht gleich SQL ist, muss ich die SQL's in der Datenbank anpassen und brauche nicht an das Programm. So kann ein Programm aber auch bei verschiedenen Kunden gegen verschiedene Datenbanken laufen und ich brauche nicht für jeden Kunden eine eigene Programmversion.

Webapplikationen hab' ich (firmenintern) inzwischen eine ganze Reihe, ausschließlich mit Delphi geschriebene ISAPI-Dll's und 'nen eigenen Webserver dank Indy-Komponenten. Das Ganze läuft auf unterschiedlichen Server und auch noch auf den lahmen Büchsen, die man als Admin immer irgendwann irgendwo über hat. Der Webserver passt immer noch zusammen mit seiner Konfigurationsdatei auf eine Diskette und muss nicht mal installiert werden: Doppelklick und läuft. Per USB-Stick kann man damit ggfls. beim Kunden auf einem beliebigen Rechner mal eben eine kleine Webapplikation vorführen. Klar: Für 'nen Webauftritt a la WDR, Google, diversen Zeitungen, eBay, Amazon und sonstwas reicht das nicht.

Zitat:

Zitat von inherited
Wir kommen also im Großen und Ganzen darüber überein, dass es immer darauf ankommt, was man machen möchte. Wirklich neu ist diese Erkenntnis ja nicht.

Ja, natürlich, womit man entwickelt, ist immer Geschmacksache, wie beim Auto, fahren tuen alle aber...

Schön fände ich, wenn die, die sich hier an der Diskussion beteiligen einfach mal schreiben würden:
Zitat:

Ich nehme Delphi weil...
unabhängig davon, ob andere das auch können, etwas besser können oder eventuelle Fehler in Delphi bei bestimmten Sachen dagegensprechen: Sprich, was führte in Summe dazu, sich (weitgehend) für Delphi zu entscheiden?

Stephan

S20000 18. Sep 2008 09:15

Re: Nativer Programmcode
 
@divBy0

Ist ja ne berechtigte Frage. Ich bin/war ein kompletter Neueinsteiger
in der objektorientierten Programmierung und habe davor nur ein wenig
C programmiert. In meiner Abteilung ist Delphi bereits etabliert und
es war auch schon eine Version vorhanden. Außerdem konnte ich
relativ schnell einsteigen, und das hat mir gut gefallen.

Reinhardtinho 18. Sep 2008 09:30

Re: Nativer Programmcode
 
Das sieht doch nach einer schlüssigen Begründung aus.

divBy0 18. Sep 2008 09:34

Re: Nativer Programmcode
 
Darauf wollte ich ja hinaus. Das ist doch die Begründung warum du dich für Delphi entschieden hast. :-D

nahpets 18. Sep 2008 09:35

Re: Nativer Programmcode
 
Zitat:

Zitat von S20000
Ist ja ne berechtigte Frage. Ich bin/war ein kompletter Neueinsteiger
in der objektorientierten Programmierung und habe davor nur ein wenig
C programmiert. In meiner Abteilung ist Delphi bereits etabliert und
es war auch schon eine Version vorhanden. Außerdem konnte ich
relativ schnell einsteigen, und das hat mir gut gefallen.

Und das sind Gründe, die sollte ein guter Chef verstehen und akzeptieren.

Stephan

S20000 18. Sep 2008 10:06

Re: Nativer Programmcode
 
:-) Stimmt schon, das ist ne Begründung. Aber im gleichen Zuge
wollte ich halt ein paar nachvollziehbare Vorteile von
Delphi aufführen.

Bernhard Geyer 18. Sep 2008 10:07

Re: Nativer Programmcode
 
Zitat:

Zitat von nahpets
Wie meinst Du das?

- Z.B. das Username/Passwort einmal als extra Property (mit unterschiedlichen Namen) verfügbar ist, einmal in irgendein ConnectionString codiert werden muss und dann manchmal im Param-Stringliste gespeichert wird
- Param werden nicht immer über Paramliste gehandhabt sondern teilweise über andere Methoden (DeclareVariable bei DOA-Komponenten)
- ...

nahpets 18. Sep 2008 10:20

Re: Nativer Programmcode
 
Zitat:

Zitat von Bernhard Geyer
- Z.B. das Username/Passwort einmal als extra Property (mit unterschiedlichen Namen) verfügbar ist, einmal in irgendein ConnectionString codiert werden muss und dann manchmal im Param-Stringliste gespeichert wird
- Param werden nicht immer über Paramliste gehandhabt sondern teilweise über andere Methoden (DeclareVariable bei DOA-Komponenten)
- ...

Okay, da hab' ich auch schon manche Stunde geflucht bis bei Applikation X die Anmeldung funktionierte, obwohl ich's doch eigentlich genauso gemacht hatte wie bei A, B, C....
Und der Eine ruft die Login-Routine der Komponente auf, der Andere nicht, der Eine benutzt die dort zugewiesenen Werte, der Andere nicht, der Eine will "USERNAME" der Andere "USER NAME"...
Heute kommt die Anmeldung mit in den Connectionstring, der wird dann halt verschlüsselt gespeichert.

Zitat:

Zitat von S20000
Stimmt schon, das ist ne Begründung. Aber im gleichen Zuge
wollte ich halt ein paar nachvollziehbare Vorteile von
Delphi aufführen.

Hoffe, wir haben Dir trotz aller Meinungsverschiedenheiten genügend Stoff zu Chefüberzeugung :wink: geliefert, der muss das hier ja nicht lesen. 8)

Stephan

S20000 18. Sep 2008 12:15

Re: Nativer Programmcode
 
Ja, so eine Diskussion legt ja dann auch
verschiedene Ansichten dar.

VB ist bei uns in der Firma noch vertreten (.NET), das wäre
doch ein Beispiel für eine Laufzeitumgebungs-abhängige Variante oder?

mkinzler 18. Sep 2008 12:16

Re: Nativer Programmcode
 
Ja benötigt entsprechende .Net Laufzeitumgebung


Alle Zeitangaben in WEZ +1. Es ist jetzt 02:14 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