Warum ist Delphi/(Pascal) bei uns so beliebt? (und wie erklären wir das den Neuen?)

[uligerhardt]

Zitat:

Zitat von jaenicke (Beitrag 1346770)

Zitat:

Zitat von uligerhardt (Beitrag 1346769)

Und das macht ja z.B. für Sin/Cos etc. nicht so viel Sinn.

TMath.Sin usw. als Klassenmethoden macht schon Sinn, weil man dann das ganze so thematisch unterteilt und nicht mehr einfache Prozeduren herumfliegen hat.

Denn ansonsten fehlt dir z.B. die Syntaxergänzung oder du schreibst den ganzen Unitnamen ab.
So schreibst du einfach TMath. und siehst die verfügbaren Methoden ohne tausend weitere globale Prozeduren zu sehen.

Da macht das Formelschreiben Spaß. Und Sin krieg ich ohne Syntaxvervollständigung hin. :mrgreen:

[OlafSt]

Das mag bei simplen bzw. oft genutzten Dingen wie mathematische Funktionen noch unsinnig erscheinen.

Doch wie ist das z.B. mit TFormatSettings ? Da kenne ich bei weitem nicht alle Elemente, die sich dahinter verbergen. Ähnlich ist es in .NET mit der statischen Math-Klasse, der Converter-Klasse (die nahezu alles in alles Konvertieren kann und weit über IntToStr oder TStringList.DelimitedText='bla' hinausgeht), der BitConverter-Klasse und so weiter.

Gerade am Anfang, wenn man noch neu in .NET ist, ist das eine unschätzbare Hilfestellung. Ein Delphi-Neuling muß lernen, das man einen Int per "IntToStr" in einen String verwandelt. Und das es noch FloatToStr und FormatDateTime usw. usf. gibt... Dem .NET-Neuling sagt man "schau in die Convert-Klasse" und er findet von selbst den Weg zu all diesen Konvertierungen.

So unsinnig ist das ganze also nicht ;)

[Sherlock]

Zitat:

Zitat von Mikkey (Beitrag 1346743)

Zitat:

Zitat von Tango (Beitrag 1346690)

Ich entwickle z.B. mit Net Framework 3.5 oder sogar noch älter, dann ist der Kunde gezwungen(Kunde kann ich auch sein) dieses zu nachinstallieren.

Sorry, aber da bist Du auf dem Holzweg. Eine .NET-Anwendung, die für die Version 3.5 geschrieben wurde, läuft unter dieser und unter allen späteren Versionen.

Aha, das ist dann wohl auch der Grund, warum man auf einem frischen Win10 kein Delphi Berlin installiert bekommt, ohne das beschickerte 3.5 nachzuinstallieren. .net ist Krätze. (<- Punkt)
Die angebliche Plattformübergreifung ist erst durch Linux-Enthusiasten mit Mono halbwegs Realität geworden. Unter Windows gibt es nunmal nur eine Plattform (von Mobile mal abgesehen, aber für derart winzige Nischen entwickelt ja keiner), das sieht man daran, daß zB eine Delphi-Exe unter jeder Windows-Version klaglos läuft. Microsoft hat mit .net zum einen zwar ein hübsches c# gebracht, zum andern aber lediglich die MFC durch .net Libs ausgetauscht. Aber das rennt grad wieder Richtung OT.

Sherlock

[uligerhardt]

Zitat:

Zitat von OlafSt (Beitrag 1346772)

Das mag bei simplen bzw. oft genutzten Dingen wie mathematische Funktionen noch unsinnig erscheinen.

Ich sag ja auch nicht, dass Namespaces oder Klassen überflüssig sind. Überflüssig ist hingegen, alles andere verbieten zu wollen, selbst wenn es sinnvoll sein kann. :wall:

Zitat:

Zitat von OlafSt (Beitrag 1346772)

Ein Delphi-Neuling muß lernen, das man einen Int per "IntToStr" in einen String verwandelt. Und das es noch FloatToStr und FormatDateTime usw. usf. gibt... Dem .NET-Neuling sagt man "schau in die Convert-Klasse" und er findet von selbst den Weg zu all diesen Konvertierungen.

Naja, aber suche ich IntToStr jetzt in der String-, Integer- oder einer Pseudo-Namespace-Converter-Klasse? Ohne gute Doku etc. kommt man da eh nicht aus.

[mkinzler]

InToToStr -> Integer.toString
StrToInt -> String.toInteger/asInteger

[uligerhardt]

Zitat:

Zitat von mkinzler (Beitrag 1346775)

InToToStr -> Integer.toString
StrToInt -> String.toInteger/asInteger

OK, OK... :mrgreen:

[OrNEC]

Bei mir ist das einfach "die erste Liebe". Bin zwar von Delphi zu Lazarus gewandert, aber letztendlich ist das alles Pascal.

[frapo]

Zitat:

Zitat von Sherlock (Beitrag 1346773)

Zitat:

Zitat von Mikkey (Beitrag 1346743)

Zitat:

Zitat von Tango (Beitrag 1346690)

Ich entwickle z.B. mit Net Framework 3.5 oder sogar noch älter, dann ist der Kunde gezwungen(Kunde kann ich auch sein) dieses zu nachinstallieren.

Sorry, aber da bist Du auf dem Holzweg. Eine .NET-Anwendung, die für die Version 3.5 geschrieben wurde, läuft unter dieser und unter allen späteren Versionen.

Aha, das ist dann wohl auch der Grund, warum man auf einem frischen Win10 kein Delphi Berlin installiert bekommt, ohne das beschickerte 3.5 nachzuinstallieren. .net ist Krätze. (<- Punkt)

Um mal in deinem Sprachgebrauch zu bleiben: "beschickert" dürfte eher sein, dass im Delphi-Setup auf .NET 3.5 bestanden wird, statt auch höhere .NET Versionen zu akzeptieren. Das diese abwärtskompatibel sind, weiß man ja eigentlich.

So richtig "beschickert" ist ja aber eher noch, dass Delphi überhaupt .NET braucht!

[bra]

Zitat:

Zitat von frapo (Beitrag 1346786)

Um mal in deinem Sprachgebrauch zu bleiben: "beschickert" dürfte eher sein, dass im Delphi-Setup auf .NET 3.5 bestanden wird, statt auch höhere .NET Versionen zu akzeptieren. Das diese abwärtskompatibel sind, weiß man ja eigentlich.

So richtig "beschickert" ist ja aber eher noch, dass Delphi überhaupt .NET braucht!

.NET ist eben nicht komplett abwärtskompatibel. Für Anwendungen, die für 1.1, 2.0, 3.5 und 4.x+ geschrieben wurden, braucht man i.d.R. die entsprechende .NET-Version. Die sind jeweils nur zu einigen Vorversionen kompatibel.

[himitsu]

Wenn du das als Static-Class-Methods deklariert hast, dann kannst du auch ein

Delphi-Quellcode:

with TMath(nil) do

vor deine Berechnung schreiben und schon ist der "Namespace" weg. :stupid:

Aber man kann das inzwischen auch schön als Record-Helper an Single/Double/Integer/usw. hängen, dann schreibst du eben satt

Delphi-Quellcode:

Sin(x)

ein

Delphi-Quellcode:

x.Sin

.