Delphi oder eine andere Sprache lernen

Ich habe hier auf administrator.de nur selten so ein perfektes Posting gelesen.

Die Begründungen sind sehr gut.
Treffen die Sache genau auf den Punkt.
Kein sinnloses Geschwafel über Vor- und Nachteile; knapp gehalten


Alles in allem:

5 Stars.


Lonesome Walker

@lws

Selten so ein überflüssiges Posting gelesen:

- nicht hilfreich
- überflüssiges Geschwafel

Sorry, aber seh' ich so

Deshalb: One Star


@fillipg

Den Tip "TurboPascal" halte ich für sehr gut, allerdings nur deshalb, weil es
zu TP ziemlich viele, gute Bücher gibt.

Die gibt es aber auch zu C/C++, PHP, etc.. Das sind aber auch nur Bücher, die
nichts anderes sind, als "Gebrauchsanleitungen" zu einem Produkt.

Ob einem die Programmierlogik liegt, kann man mit jeder Sprache testen,
selbst mit dem "äffen" Basic, das dem Dos beiliegt.

Will damit sagen, so mal als Beispiel:

Wenn(Variable=wahr) dann... Syntax in Basic, TP

oder

Wenn(Variable== wahr) dann...Syntax in C/C++, PHP

oder

Wenn(Variable) dann... //funkt. bei allen...

Abstrahiert wird doch das Ganze in einem Struktogramm oder in einem
PAP, und da bleibt die Programmiersprache immer außen vor.


Und wenn ich kein Struktogramm erstellen kann oder keinen PAP,
tja, hat sich das Programmieren wohl erledigt?, .

Gruß
Günni

Moin Matthis_1982, filippg, LSW und Günni,
wäre schade, wenn sich in diesem Thread ein weiterer kleiner Glaubenskrieg entzündet um die beste Programmiersprache.

Dazu ist die Frage selbst zu weltfremd... es gibt kein bestes Werkzeug für alle Programmierer.

Es gibt Sprachen, die konzipiert wurden für eher mathematische Probleme, für kaufmännische Fragestellungen, für Universalität, Abstrahierung, Kompatibiltät, für hardwarenahe Programmierung; es gibt Programmier-Ur-Sprachen wie VB oder C , von denen man/frau wenigstens eine halbwegs verstehen sollt in der M$-Welt... sonst ist auch Windows als betriebssystem nicht zu verstehen.

Am besten trifft es IMHO Günni's Aussage:

FULL ACK. Es geht um das grundsätzliche "In-Programmlogik-übersetzen-können", um das Reduzieren-Können der Komplexität des Problems auf das Wesentliche. Um Strukturen und Algorithmen.
Nicht darum, ob eine bestimmte Funktion nun ToUpper() oder Uppercase() oder UCase() oder Gross() heißt oder ob am Ende einer Zeile ein Semikolon stehen muss oder nicht.

Und Sprachblasen aus Tankstellen-PC-Zeitschriften wie
...dass sind halt wirklich nur unreflektierte Zitate aus dubiosen Quellen.*

@Matthias
Es gibt Programmiersprachen, die einem persönlich liegen und andere, mit denen ein einzelner ungern arbeitet.
Probier ein paar aus. Nimm das Werkzeug, das Dir "gut in der Hand liegt" und nicht den Geheimtipp der Computer-Bild.

Gruß
Biber

• Oder "Bullshit", wie wir Bremer sagen.

Dabei lässt du aber ausser Acht, dass es unterschiedliche "Programmierlogiken" bzw Paradigmen gibt. Abgesehen davon, dass ich OOP mit Basic nicht testen kann ist das Vorgehen doch ein sehr anderes. Man kann sich zwar auch bei OOP mit dem prozeduralen Ansatz behelfen, aber das wird dann eben auch nicht die ganz grosse Geburt (und das ist der Grund, weswegen man es sich doch nochmal überlegen sollte mit TP einzusteigen). Und z.B, funktionale Programmierung erfordert dann doch ein komplettes Umdenken (und ganz andere Sprachen).

Dann muss ich aber doch mal ganz blöd fragen, warum sich so viele unterschiedliche Sprachen so weit entwickelt haben. Ausserdem macht Syntax sehr wohl einen unterschied, nämlich den der Verständlichkeit (was zugegebenermassen eine subjektive Frage ist, trotzdem gibt es welche, die ist für Einsteiger eher und welche die ist weniger geeignet).
Gleiches gilt für Struktogramme: hier gibt es alte Methoden, die für alte Sprachen und alte Ansätze entwickelt wurden, und auch eher für diese geeignet sind, und es gibt neue Formen der Modellierung.


Das ist eine ziemlich arrogante Einstellung. Die meisten Leute fangen damit an, einfach zu programmieren, und beschäftigen sich vielleicht später mal mit sowas, wenn sie festgestellt haben, dass ihnen Programmieren grundsätzlich liegt. Die trockene Arbeit einer echten Designphase erwischt einen dann sowieso meist erst bei grösseren Projekten.


"Probier ein paar aus. Nimm das Werkzeug, das Dir "gut in der Hand liegt" und nicht den Geheimtipp der Computer-Bild."
Das ist grundsätzlich richtig. Aber leider auch sehr wenig Hilfe. Wenn man einsteigen möchte wird man wohl kaum Lust haben, erstmal von 20 Sprachen ein Einführungsbuch zu lesen (oder auch nur die ersten beiden Kapitel). Deswegen fragt man ja dann andere nach Empfehlungen, um die Auswahl schonmal einzuschränken. Und wenn man beim Ausprobieren gleich an die ganz falsche Sprache gelangt, dann kann einem das auch gleich ganz die Lust versauen (ich glaube nicht, dass ich heute programmieren könnte, wenn ich mit C/C++ angefangen hätte).

Filipp


EDIT:
Ich finde Lonesomes Post zwar tendentiell auch übertrieben (so gut fand ich meinen Beitrag gar nicht), grundsätzlich ist es aber schon mal schön, nicht immer nur was abzukriegen, wenn man etwas gepostet hat, was den Leuten nicht passt, sondern auch positives Feedback zu geben. In dem Sinne: Vielen Dank!