Delphi und C++

[Robert_G]

Zitat:

Zitat von Stefan S.

Die Zukunft gehört definitiv den Interpretersprachen.

Ersetze "interpretersprachen"[1] durch VMs und du kommst der Sache näher...
Spätestens wenn CPUs entwickelt werden, die effizienteres Verarbeiteten von einer IL (Java, CLR,..) ermöglichen, haben native Dinge außerhalb von absoluten Highperformance System (Datenbankserver, Treiber,...) ausgedient.
Neben den produktiveren und schöneren APIs egen die man in einer VM entwickelt, dürfte Sicherheit der Hauptgrund werden, sich für eine VM als Plattform zu entscheiden bzw. nur noch Apps in einer VM im Firmennetz zuzulassen. (Siehe CAS bei .Net :) )

Das sind nur meine 2 Cents, aber ich würde es schon heute nicht einsehen, warum ich mir noch natives Gefrickel antun müsste, wenn ich es managed lösen kann.
Native heißt sich mit altem Kram wie Delphi32 oder C++ aufzuhalten. Anstatt das gleiche, schöner, mit halb soviel Code in Chrome oder C# zu lösen.
Ich muss zum Glück weder DB-Server noch Treiber schreiben. :P

[1] Welch böses und falsches Wort an der Stelle. ;)

[Stefan S.]

Zitat:

Zitat von Robert_G

Ersetze "interpretersprachen"[1] durch VMs und du kommst der Sache näher...

Interpretersprachen übersetzen den Code in Bytecode, welcher entsprechend von der VM ausgeführt wird. Das es letztlich auf die Effizienz der VM ankommt un der JIT Kompilierung dürfte jedem einleuchten :) .

Mit "nativen Gefrickel" wäre ich etwas vorsichtiger. Software ist immer an die Hardware gebunden. Es wird sich zeigen wie die Zukunft der Programmiersprachen aussehen wird. Es gibt schließlich noch zahlreiche Anwendungen und Bereiche in denen ohne "nativen Gefrickel" gar nichts geht. Und das wird auch in naher Zukunft so bleiben...

[delphirocks]

Ich denke, daß der größte Vorteil von Delphi die Lesbarkeit des Codes ist. Wenn ich mir den VCL Source ansehe, so kann ich zumindest einigermaßen erahnen, was die Funktion tut - und das meistens auf den ersten Blick. Sieht man sich dagegen den MFC Source an, steht man ziemlich verloren da...
Und mit Java habe ich oft das Gefühl, mit der Kirche ums Kreuz zu fahren...

[w3seek]

Zitat:

Zitat von PierreB

Zitat:

Zitat von w3seek

Zitat:

Zitat von r_kerber

Und warum mit .Net beschäftigen? Weil in den nächsten Windows .Net die Betriebssystem-API ist! Also wird jeder Windows-Entwickler sich früher oder später damit beschäftigen müssen.

Da irrst du dich gewaltig ;)

Wenn du sowas schon schreibst, würde ich eine Erklärung/Erläuterung für sehr sinnvoll halten.

Also, warum irrt er sich ? :gruebel:

.NET baut auf win32/win64 auf. Ohne win32/64 laeuft auch .NET nicht. Zudem muss es auf jeden Fall APIs geben die von nativen Code verwendet werden, irgendwie muss ja die CLR gestartet werden und irgendwie muss sie natuerlich mit dem OS kommunizieren.

Dass Win32/64 noch lange nicht am Ende ist beweist der kontinuierliche Ausbau der APIs, selbst in Vista. Ich moechte allerdings nicht ausschliessen, dass MS irgendwann mal ein .NET subsystem entwickelt, allerdings werden dann keine alten Anwendungen mehr darin laufen koennen. Abwaertskompatibilitaet ist aber unter anderem das, was MS so erfolgreich gemacht hat. Win32/64 wird so schnell nicht auf Eis gelegt, zumindest nicht auf der x86(-64)er Plattform.