Delphi: schöne Sprache, aber...

[Jörg Wegener]

Hallo,<BR>
ich programmiere gerne in Delphi, aber mit der Zeit habe ich in anderen Programmiersprachen Möglichkeiten entdeckt, die in Delphi schwerer zu lösen sind. Dabei sind das nur Kleinigkeiten, die einem die tägliche Arbeit erleichtern.<P>

Wie zum Beispiel:<BR>
<UL>
<LI>Inkrementierung von Variablen wie in C++ (und vielen anderen) mit <B>$variable++</B> anstelle von $variable:=$variable+1<BR>
<LI>Anhängen von Strings einer Variable mit <B>$variable+='Zusatz'</B> anstelle von $variable:=$variable+'Zusatz'<BR>
</UL>

Können die "Borländer" das nicht in Delphi implementieren? Was meint Ihr dazu?

[Robert Marquardt]

1. Inc(Variable)

Man muss nicht alles in der Sprache haben. Abgesehen davon das der Compiler Optimierungen vornimmt, gibt es auch Probleme wenn man ein Sprachkonzept in alle Richtungen erweitert. Ada ist damit auf die Schnauze gefallen. C++ ist zu kompliziert um vollstaendig genutzt zu werden.<br>
Du unterliegst auch dem typischen Programmierervorurteil. Schnell Zeilen zu schreiben macht die Entwicklung des Programmes nicht schneller. Die Zeit geht dann in der Fehlersuche wieder weg

[Hagen Reddmann]

Hi

ausserdem gibt es dann solch "schöne" Konstrukte wie diese:

<pre>

for I += 1000 < J-, +J > -I = I++ to J-- do ;

</pre>

Um die Funktionsweise und den Zählrythmus obiger Schleife zu begreifen brauchste garantiert ne Stunde Denkarbeit.

Solche Konstrukte wie A := A + B machen ja gerade PASCAL's Einfachheit und Übersichtlichkeit aus. Jedem der Sprachfeatures wie solche in C oder JAVA haben möchte sollte doch auch diese Sprachen nutzen. PASCAL ist was für "Denkfaule" und "auf Nummer sicher Geher", C ist was für "Tippfaule" und "Kleine Projekte Schreiber" und "mal schnell ein Treiber-Programmierer".

)

Gruß Hage

[Jörg Wegener]

Stimmt, Deine Argument überzeugen mich.<BR>

Mich störte es nur bei der ISAPI Programmierung, dass ich teilw. den HTML-Code umständlich einer Veriable anhängen muss

[Arno Lutz]

für Inkrementieren gibts:
Dec und Inc

Anhängen von Strings an Strings gibts:
Contact(string1,String2); (wird nur sehr wenig angewandt)

Warum sich das Leben schwer machen??

Arn

[Robert Marquardt]

Hagen, dein Beispiel ist weder C noch Pascal und deshalb Unsinn, aber als Beispiel was man in C so anrichten kann durchaus brauchbar.<br>
Ich bin allerdings nicht der Meinung das C nur fuer kleine Projekte geeignet ist. C ist eine pragmatische Sprache mit einigen interessanten Konzepten.<br>
Grosse Projekte beduerfen nur der Disziplin um funktionieren zu koennen. Da ist eine schwierige Sprache manchmal eher hilfreich

[Hagen Reddmann]

Hi Robert

Richtig. Man kann in fast jeder Sprache auch große Projekte abhandeln, siehe KHK Software ist in basic. Aber, wie Du es schon sagtes: es gehört Disziplin dazu. Beim PASCAL wird man aber von vornherein dazu gezwungen. Nun, es geht mir garnicht darum andere Sprachen schlecht zu machen, sondern ich spreche aus Erfahrungen die ich machen musste bei der Analyse diverser Großprojekte. Dabei stellten sich Delphi projekte als am lesbarsten/ wartungsfreundlichsten und C/C++ projekte als die verworensten heraus.

Mein obiges Beispiel ist absichtlich eine "mögliche" Projektion von C Features in ein C like PASCAL.

Gruß Hage

[Gesine Kuhlmann]

Hi,

Da die Unterschiede der Endprodukte bei 'echten' Programmiersprachen heutzutage marginal sind, rückt gerade die Benutzbarkeit immer stärker ins Blickfeld. Dazu ist folgendes festzustellen:

1. Der nervigste Punkt an Delphi sind die dämlichen Semikolons ( 8 von 10 Compiler-Meldungen hängen ursächlich damit zusammen ). Bei der Weiterentwicklung von Sprachen sollte jeder Hersteller doch mal drüber nachdenken, ob ein solchen Anachronismus nicht entfernt werden könnte.

2. Um die Lesbarkeit von Programmen zu erhöhen sollte eine moderne IDE dafür Sorge tragen, dass der Code automatisch formatiert und damit standarisiert wird ( Sowas gab es übrigens schon 1986 als GFA-Basic für den Atari ). Nö, da verdaddelt man auf den heutigen Monsterkisten 10% seiner Codierzeit mit Ein-/ Ausrücken von Codezeilen. Voher hat man schon 15% seiner Projektentwicklungszeit daran verschwendet, eine verbindliche Nomenklatur zu entwickeln/vermitteln. Ausserdem ist jeder Entwickler dann immer noch der Meinung, seine Darstellungsform wäre die leserlichste.

</b>Eine IDE hat sowas unveränderlich vorzuschreiben !!</b>.

3. C schlimmer noch C++ sind diesbezüglich noch viel armseliger als Delphi. Das einzige Feature welches C++ bietet und Delphi nicht, ist Polymorphismus. Nur welcher normale Mensch benutzt dieses, wenn er Wert darauf legt, dass ausser ihm auch noch jemand anderes etwas mit seinem Code anfangen kann ?? Die vielgerühmte Portierbarkeit von C ist soundso n' Witz, den man spätestens dann versteht, wenn man auf einer Plattform versucht hat den C-Code eines Herstellers auf einen anderen zu portieren.

4. Wer mit (V)Basic ein Projekt grösser als 'Hello World' entwickelt, der gehört erschossen ( eigentlich nicht nötig, den dieser erschiesst sich meistens schon selbst oder befindet sich eh' in einer betreuten Wohngruppe )

Gruß
Gesin

[Hagen Reddmann]

Hi Gesine

Mit dem "Source Formatierer" haste recht. Im implementation Abschnitt steht ALLES was ein solcher "intelligenter" Formattierer benötigte. Leider habe ich nie wieder einen so guten wie fürs GFA-Basic gesehen

Gruß Hagen

PS: für'ne ältere Dame in diesem Geschäft kannste aber noch Brüllen wie ein Löwe

[Robert Marquardt]

Gesine, leider muss ich dir ein bischen widersprechen.<br>
1. Semikolons (Statementtrenner oder Statementbeender) sind wichtig.<br>
Wobei ich die C Version des Statementbeenders vorziehe. Bei Pascal ist praktisch immer das if else das Problem.<br>
2. Leider gibt es mehrere inkompatible aber in sich logische Formatierungsvorschriften.<br>
Pascal ist nunmal als formatfreie Sprache entwickelt worden um genau diese Freiheit zu geben. Ansonsten hilft DelForEx weiter.<br>
Nicht zuletzt nutzte ich das Umformatieren fremden Codes von Hand um ihn naeher kennenzulernen. Ein Verstoss gegen die gewaehlte Formatierung zeigt dabei fast sicher einen Fehler an.<br>
Bei einer Zwangsformatierung ist diese Inkonsistenz weg.<br>
3. C++ ist einfach nur schwieriger und die wenigsten "Programmierer" verstehen die Konzepte (ich auch nicht).<br>
Portierbarkeit von C ist eher eine Gesiteshaltung des Programmierers. Dei wird sich fuer Delphi auch noch entwickeln.<br>
4. Da kann ich dir nur zustimmen :-

[Gesine Kuhlmann]

Hi Robert,

1. Das dem Parser mit Statementtrennern auf die Sprünge geholfen werden muss ist sicherlich richtig. Jedoch muss dass keinesfalls mit mistigen manuellen Semikolons ( die auch heute noch aus ALGOL60 übrig geblieben sind ) geschehen, sondern diese können von einer 'intelligenten' IDE automatisch und damit sogar unsichtbar gesetzt werden.

2. Die Intention von Niklaus Wirth bei der Entwicklung von Pascal und seinen Nachfolgern Modula-2 und Oberon war keinesfalls eine formatfreie Sprache zu entwickeln, sondern das Ziel war eine <b>imperative</b> Programmiersprache die <b>strukturierte</b> Programmierung unterstützt, um seinen Studenten das Programmieren leichter vermitteln zu können. Wenn Du Code durch das manuelle Umformatieren zum Kennenlernen einer Programmlogik nutzt, dann wedelt da aber der Schwanz mit dem Hund. Die verfeinerte Methode wäre demzufolge dann die Anaylse des Objekt-codes ?? Wie Du richtig sagst, ist bei einer Zwangsformatierung die Inkonsistenz weg. Damit habe ich mir also schon die Suche danach gespart, da ich von vorneherein weiss, dass keine enthalten sind.

3. Das C/C++ schwieriger ist, liegt nicht etwa an komplexeren und/oder besseren Konzepten, sondern daran, dass man sich um fast jeden Mist selber kümmern muss. Es ist einfach fehlerträchtig, umständlich und <b>überflüssig</b> z.B. Speicher für Stringvariablen dauernd selbst allozieren/freigeben zu müssen. Das war in Zeiten, als dieses Vorgänge noch immanenten Einfluss auf die Systemperformance hatte angebracht. Heute kann man sowas aber ohne weiteres einem Automatismus anvertrauen. So ist C++ heute ein Werkzeug, dem der Werkstoff ausgegangen ist. Die C-Fraktion hat's nur noch nicht begriffen. So wird Sie das gleiche Schicksal erleiden, wie die tattrigen Fortran/Cobol-Entwickler, die im Altersheim über Muster auf Lochkarten sinnieren.

Gruß
Gesin

[Gesine Kuhlmann]

Hi,

Wer's noch nicht wusste..

WER jagt WIE Elefanten

--------------------------------------------------------------------------------

<pre>
INFORMATIKER jagen Elefanten, indem sie Algorithmus A ausführen:
Begin
{
Gehe nach Afrika
Beginne am Kap der guten Hoffnung
Durchkreuze Afrika von Süden nach Norden bidirektional in Ost-West-Richtung
Für jedes Durchkreuzen tue
{
Fange jedes Tier, das Du siehst
Vergleiche jedes gefangene Tier mit einem als Elefant bekannten Tier
Halte an bei Uebereinstimmung
}
}

</pre>
ERFAHRENE PROGRAMMIERER verändern Algorithmus A, indem sie ein als Elefant bekanntes Tier in Kairo plazieren, damit das Programm in jedem Fall korrekt beendet wird.


ASSEMBLER-PROGRAMMIERER bevorzugen die Ausführung von Algorithmus A auf Händen und Knien.


SQL-PROGRAMMIERER verwenden folgenden Ausdruck:
SELECT Elefant FROM Afrika;


NATURAL-PROGRAMMIERER lassen sich von ADABAS einen Elefanten bringen.


LOGO-PROGRAMMIERER reiten durch Afrika auf ihrer Schildkröte.


COBOL-PROGRAMMIERER tun dies auf einem Dinosaurier.


BASIC-PROGRAMMIERER bevorzugen jedoch einen mit Samt ausgepolsterten Einspänner, bei dem die Bremsen ständig angezogen sind.


C-PROGRAMMIERER bestimmen zuerst mit sizeof() die nötige Speichermenge für einen Elefanten, versuchen, diese zu allozieren, vergessen dabei, das Ergebnis abzuprüfen und schiessen dann mit wilden Pointern auf den Elefanten.


C++-PROGRAMMIERER bestehen darauf, dass der Elefant eine Klasse sei, und somit schliesslich seine Fang-Methoden selbst mitzubringen habe. Und wenn der Elefant Afrika verlassen sollte, dann wird ja automatisch sein Destruktor ausgelöst.


PASCAL-PROGRAMMIERER markieren zuerst einen Punkt auf der Landkarte, schreiben dann END davor und träumen davon, dass Nikolaus Wirth von einem Elefanen totgetrampelt wird.


MODULA-PROGRAMMIERER importieren einen Elefanten aus/von einem Zoo.


LISP-PROGRAMMIERER bauen einen Irrgarten aus Klammern und hoffen, dass sich der Elefant darin verirrt.


MATHEMATIKER jagen Elefanten, indem sie nach Afrika gehen, alles entfernen, was nicht Elefant ist, und ein Element der Restmenge fangen.


ERFAHRENE MATHEMATIKER werden zunaechst versuchen, die Existenz mindestens eines Elefanten eindeutig zu beweisen, bevor sie mit Schritt 1 als minderwertiger Uebungsaufgabe fortfahren.


MATHEMATIKPROFESSOREN beweisen die Existenz mindestens eines theoretischen Elefanten eindeutig und ueberlassen dann das Aufspüren und Einfangen eines tatsächlichen Elefanten ihren Studenten.


INGENIEURE jagen Elefanten, indem sie nach Afrika gehen, jedes graue Tier fangen, das ihnen über den Weg läuft und es als Elefant bezeichnen, wenn das Gewicht nicht mehr als 15% von dem eines vorher gefangenen Elefanten abweicht.


WIRTSCHAFTSWISSENSCHAFTLER jagen keine Elefanten. Aber sie sind fest davon überzeugt, dass die Elefanten sich selber stellen würden, wenn man ihnen nur genug zahlt.


STATISTIKER jagen das erste Tier, das sie sehen, n-mal und nennen es Elefant.


UNTERNEHMENSBERATER jagen keine Elefanten. Und viele haben noch niemals ueberhaupt etwas gejagt. Aber man kann sie stundenweise engagieren, um sich gute Ratschlaege geben zu lassen.


SYSTEMANALYTIKER wären theoretisch in der Lage, die Korrelation zwischen Hutgrösse und Trefferquote bei der Elefantenjagd zu bestimmen, wenn ihnen nur endlich jemand sagen würde, was ein Elefant ist.


SAP-SYSTEMINGENIEURE erklären das erstbeste Tier zu einem Elefanten und passen ihre Vorstellungen eines Elefanten an dieses Tier an.


MICROSOFT kauft einen Elefanten aus dem Zoo in Seattle, kopiert ihn massenhaft, redet aller Welt ein, dass jeder einen bräuchte, und dass dieser die ideale Ergänzung zu MS-Office sei und exportiert 14 Mio. Stück nach Afrika.


Gruß
Gesin

[Frank Kneffel]

Eins hast Du noch vergessen:<br>
DELPHI-Programmierer laden sich aus dem Internet eine Komponente TElefant und rufen dann X mal Telefant.create au

[Gesine Kuhlmann]

Hi Hagen,

ältere Dame, ich hör wohl nich' richtig, du Charmeur.

Gruß
Gesin

[Hagen Reddmann]

Hi

Bei dem offentsichtlichen Wissenstand den Du hast, z.B. GFA Basic ist ja nun auch schon par Jährchen alt, musst Du ca. 28-32 Jahre alt sein.
Vielleicht projeziere ich auch nur mein Wissenstand / mein Alter = Dein Wissenstands / X Jahre

War also nicht im geringsten böse gemeint, eher das Gegenteil.

Gruß Hage