Delphi nicht zukunftsicher?

.NET: M$ gebunden

Wenn es zukunftssicher sein soll, nimm normales C.

Der Thread ist von 2008 und Delphi wird immer noch weiterentwickelt. 
Frage beantwortet? :-)

Über die Zukunft von .NET wird zur Zeit viel spekuliert:
http://www.heise.de/developer/meldung/Nur-noch-HTML-und-JavaScript-Windows-8-verunsichert-NET-Entwickler-1255775.html
http://www.heise.de/developer/artikel/Windows-8-HTML5-und-die-Folgen-fuer-NET-1267153.html

Letztendlich ist doch alles geeignet womit Du dein Ziel erreichst und 
was nicht heute schon offensichtlich das tote Pferd von morgen ist.

Guckst du Embacadero RAD Studio XE

danke für die schnellen Antworten und die links.
Ja, ich habe mich schon mit dem Embacadero RAD Studio XE auseinander 
gesetzt und wollte es bestellen. Mit Delphi lässt sich auf jeden fall 
recht einfach und mit wenig Zeit für die Einarbeitung genau das 
realisieren, was ich brauche. War halt dennoch etwas verunsichert als 
ich den Thread gelesen hatte.

Chris (Gast) schrieb:

...

> Über die Zukunft von .NET wird zur Zeit viel spekuliert:

Leute könnt ihr eigentlich alle nicht mal richtig lesen, statt immer die 
beiden gleichen Links hier sinnentlehrt zu kommentieren? .NET ist und 
bleibt ein zentraler Bestandteil des Windows OS und der Ausbau einer 
Skriptsprache kann das nicht ersetzen, es sei denn, Windows schrumpft 
irgendwann zu einem Web-Tablett-ichKlickMalWasAn-OS. Solange man aber 
Applikationen auf Windows entwickelt UM DAMIT AUCH ZU ARBEITEN (und 
nicht nur zu surfen wie auf Tabletts) wird und muss es ein gut 
ausgebautes API geben und die alte Win32-API ist nun mal überholt und 
Museumsreif. Und schon aus Rückwärtskompatibilitätsgründen muss .NET 
weiter gepflegt werden. Der Rest ergibt sich auch den gerne zitierten 
Links wenn ihr mal mehr als nur die Überschrift lest, nämlich die 
Zusammenfassung.

"JavaScript und .NET?

Nimmt man nun all die genannten Faktoren zusammen, ergibt sich ein 
relativ überschauberes Bild:

    HTML5 und JavaScript werden mittel- bis langfristig XAML und C# als 
Sprache für die UI-Logik ablösen. UI-Techiken wie Windows Forms, WPF und 
Silverlight werden im Hinblick auf plattform- und geräteunabhängige 
Entwicklung zu Bürgern zweiter Klasse.
    .NET und C# werden die Grundlage für ein serviceorientiertes und 
damit statusloses Backend bilden, das mit HTTP, REST und XML oder JSON 
auf Basis von AJAX und WebSockets angebunden wird.
    IIS Express, SQL Server CE und Azure bilden die Grundlage für das 
Hosting dieses Backends und stellen zugleich sicher, eine Desktop- zu 
einer Web- oder einer mobilen Anwendung zu migrieren.
    Parallelisierung von Code ist das wesentliche Werkzeug, um die 
zukünftige Skalierbarkeit einer Anwendung zu gewährleisten. C# 5.0 wird 
vermutlich die Async CTP integrieren und hierfür neue Werkzeuge und 
Schlüsselwörter zur Verfügung stellen.
    JavaScript wird als funktionale Sprache eine wichtige Ergänzung zu 
C# werden, speziell auch im Bereich der Parallelisierung, da die 
objektorientierte Programmierung hierbei an ihre Grenzen stößt."

Quelle: 
http://www.heise.de/developer/artikel/Windows-8-HTML5-und-die-Folgen-fuer-NET-1267153.html?artikelseite=4

.... schrieb:
> Leute könnt ihr eigentlich alle nicht mal richtig lesen, statt immer die
> beiden gleichen Links hier sinnentlehrt zu kommentieren? .NET ist und
> ...

Dies ist eine objektive Einschätzung der Zukunft von .NET, die ich mir 
eigentlich von Heise gewünscht hätte. Vielen Dank und Respekt an den 
Autor.

Wenn du erst einsteigst nimm evtl. Lazarus + FreePascal. Delphi ist ja 
nicht gerade billig.

>Der Thread ist von 2008 und Delphi wird immer noch weiterentwickelt.
>Frage beantwortet? :-)

Griechenland ist pleite und wird immer noch weiterentwickelt.
Frage beantwortet?

Rufus Τ. Firefly (rufus) (Moderator) schrieb:

.... schrieb:
>> muss es ein gut ausgebautes API geben und die alte Win32-API ist
>> nun mal überholt und Museumsreif.

> Die Win32-API ist die native Schnittstelle zum OS,

Ja.

> .Net ist nur ein
> Schichtkuchen, der darauf aufsetzt.

NEIN, EBEN NICHT! (ein oft gemachter Denkfehler!) .NET setzt nicht 
"einfach nur" auf der Win32-API auf. NET bringt vielmehr seine eigene 
UMFASSENDE STANDARDBIBLIOTHEK mit, die BCL (Base Class Library), die 
selbst bereits als Managed Code vorliegt und die ist (inzwischen) sehr 
umfassend. Der Prozessor unabhängige IL-Code (eine stack-orientierte 
Assemblersprache) wird anders als bei JAVA zudem NICHT INTERPRETIERT, 
sondern stückweise DIREKT vom extrem schnellen JIT-Compiler in 
MASCHINENCODE übersetzt, dabei aber zusätzlich während der Ausführung 
von der CLR (der Laufzeitumgebung) auf Korrektheit und Integrität 
überprüft (eben gemanaged). Der so vom VES (Virtual Execution System) 
aus dem IL-Code übersetzte Maschinencode wird NATIV ausgeführt (deswegen 
ist die Gegenüberstellung in C++ = nativ und C# = "nicht nativ" sprich 
irgendwie "lahm" schlicht FALSCH. Der Unterschied hierbei zu Compilaten 
wie deren von C++ ist nur das die Übersetzung sowohl VOR als auch 
WÄHREND der Programmausführung erfolgen kann. Zusammen mit der 
Überwachung durch das CLR besteht damit (je nach dem in der Auswirkung) 
ein kleiner Nachteil in der Ausführungsgeschwindigkeit gegenüber dem 
Compilat eines C++ Programms. Dafür gewinnt man deutlich mehr Sicherheit 
und die geht halt wie immer im Leben auf Kosten der Geschwindigkeit. 
Wenn du alle möglichen Sicherheitsabfragen in dein C/C++/Delphi Programm 
einbaust (d.h. Rückgabewerte konsequent immer überprüfst) ist es u.U. 
auch spürbar langsamer als das gleiche Programm ohne diese Prüfung. 
Wobei .NET unabhängig von der Programmiersprache natürlich auch mit 
Delphi, F#, Eiffel oder sonst was anprogrammiert werden kann (habe als 
Beispiel halt mal willkürlich die Platzhirsche C++ vs. C# gewählt). .NET 
untersützt also beliebige Programmiersprachen im Unterschied zu JAVA. MS 
hat mit der Einführung von C#/.NET das bisherige Komponentenmodell 
COM/COM+ abgelöst, natürlich besteht letzteres aber noch.

Und wie Arc Net (arc) (jetzt muss ich aufpassen, der Nick klingt wie 
eine weitere Programmiersprache ;)) geschrieben hat läuft der Support 
für Windows 7 bis 2020. Solange wird es also minimum .NET geben und so 
schwierig ist es auch nicht wenn man in C#/.NET mal fitt ist sich auch 
in was anderes wie JAVA/C++ oder sonstwas objektorientiertem 
reinzufinden.

Naja, um etwas Salz in die Wunde zu streuen, sag ich es mal so: Es war 
vor vielen Jahren ein Fehler, überhaupt mit C anzufangen. Natürlich 
haben viele Leute es gepriesen, daß sie mit C solche Dinge wie eine 
recht strikte Typunterscheidung, relativ viele Buchstaben bei den 
Schlüsselwörtern und die tunliche Vermeidung von Seiteneffekten endlich 
losgeworden sind. Endlich die große Freiheit, beim Programmeschreiben 
die Sau rauslassen zu können.

C ist das Karnickel. Wenn ich dran denke, was es alles schon an 
Verbesserungsversuchen gegeben hat, C, Ansi-C, C++, Java, C#, vielleicht 
demnächst ein neues C** oder C$$ ?

Nun, C und seine Kinder sind etabliert und seine Geburtsfehler sind 
nicht mehr zurückzudrehen. Man muß damit leben oder sich eben Mühe 
geben, solche Dinge wie Delphi, Freepascal, Lazarus, MSeide nicht 
untergehen zu lassen.

Es kommt auf uns an. So herum wird ein Schuh draus.

W.S.

Rufus Τ. Firefly schrieb:
> Udo Schmitt schrieb:
>> Ist die Win32 API bzw das .net Geraffel eigentlich 64Bit oder noch alles
>> 32Bit?
>
> Hängt vom verwendeten Windows ab. Unter 32-Bit-Windows gibt es nur die
> 32-Bit-Ausführung, unter 64-Bit-Windows gibt es für 32-Bit-Programme die
> 32-Bit-Ausführung, und für 64-Bit-Programme eine 64-Bit-Ausführung.
Es gibt (gab) sie sogar dann noch in dreifacher Ausführen, einmal ANSI, 
einmal Unicode und einmal 'automatisch'...

C ist garnicht verkehrt. Viele meinen aber, wegen einiger Schwächen 
gleich eine neue Sprache konstruieren zu müssen. DAS ist der Knackpunkt.

Delphi war auch vor 10 Jahren nicht zukunftsicher. Es ist so, an den 
UNIs wurde früher nicht C/C++ gelehrt, sondern Pascal. Aus dem Grund 
gibt es in der E-Technik Branche immer noch viele Delphi Fans. Wenn man 
es richtig machen sollte, muss man mindestens 3 gängige 
Programmiersprachen beherschen. C gehört auf jeden Fall dazu. Wenn man 
gewisse Vorkentnisse hat, kann man jede andere "gängige" Sprache leicht 
erlernen. So war es für mich leicht dank C PHP zu erlernen, dank MySQL 
LINQ unter C# und dank C# Java zu programmieren...

Eigentlich wollte ich mich bei soviel Voreingenommenheit hier nicht mehr 
zur Sache äußern, aber manche Postings fordern das ja geradezu heraus.

Christian Berger (casandro) schrieb:

> Nimm für GUI-Sachen Lazarus oder TCL/TK.

Für Windows keine gute Wahl.

> Wenn Du C oder C++ wirklich kannst ...

Der TE hat gefragt, wo der Unterschied zwischen C# und C++ ist und da 
schreibst du er solle C++ nehmen? Das ist für mich keine angemessene 
Antwort.

> Bei C(++) hast du halt das Problem, dass es keine gute
> Standardbibliothek gibt.

Für C# gibt es diese.

> C# hat hingegen keine Zukunft. Das ist ein Standard der nur unter
> Windows so wirklich funktioniert. Im Prinzip so wie Delphi.

Meine Güte, tut mir leid, aber das ist ein so hirnloser Satz. Deine 
ganze "Hilfe" hier geht mal wieder (wie so oft) davon aus, der 
Fragesteller hätte mit Windows so rein gar nichts zu tun. Woher willst 
du das eigentlich wissen? Was ist denn Zukunft für DICH? Glaubst du 
deine Empfehlung für TCL/TK hat überhaupt die Lebenszeit, die ein .NET 
Framework noch für Minimum die nächsten 10 eher 20 Jahre aufbringt? Ist 
dir eigentlich bewusst, das der Marktanteil von Windows alle Zukunft für 
sich bereits inne hat? Glaubst du die vielen Linux-Distributionen die es 
gibt würden in 10 Jahren so noch bestehen wie augenblicklich? Woher 
nimmst du die Gewissheit, dass es ein QT in 5 Jahren noch gibt und 
dieses auch noch weiter geflegt wird? Diese Gewissheit gibt es nicht. 
Wenn überhaupt, dann hat .NET noch die besten Chancen recht alt zu 
werden auf dem PC, ganz einfach, weil die Win32-API auch bereits seit 
Urzeiten existiert und MS nicht so leicht bestehende Zöpfe kappt, 
sondern immer etwas neues hinzustrickt.

Rufus Τ. Firefly (rufus) (Moderator) schrieb:

.... schrieb:
>>> .Net ist nur ein
>>> Schichtkuchen, der darauf aufsetzt.
>>
>> NEIN, EBEN NICHT! (ein oft gemachter Denkfehler!) .NET setzt nicht
>> "einfach nur" auf der Win32-API auf. NET bringt vielmehr seine eigene
>> UMFASSENDE STANDARDBIBLIOTHEK mit, die BCL (Base Class Library), die
>> selbst bereits als Managed Code vorliegt ...

> Da hast Du was falsch verstanden.

Nein habe ich nicht. Was ich schrieb kannst du in der iX Spezial 1/03 
von 2003 nachlesen vom Autor Michael Stal, der u.A. damals Chefredakteur 
der Zeitschrift Java Spektrum war. Ein sehr guter und ausführlicher 
Bericht.

> Es ist vollkommen wurscht, wie .Net
> arbeitet,

Wer glaubt dies sei "WURSCHT" schreibt höchstens "KÄSE".

> ob das interpretiert wird,

Es ist ein RIESEN Unterschied, ob "nur" interpretiert oder aber nativer 
Code just in Time compiliert und dann sofort ausgeführt wird. Als jemand 
der Ahnung von der Materie hat solltest du das wissen.

> ob es eine noch so tolle
> Standardlibrary ist,

Gerade DIE macht den großen Unterschied zur Win32-API. Die hat nämlich 
sehr viel mehr (nennen wir es) Anwenderfunktionen (besser 
Anwenderklassen) zu bieten, als die alte Win32-API hat.

> ob es handgedengelter Assembler oder
> superdupertoller von Hochleistungscompilern übersetzter Maschinencode
> ist -- es kommuniziert mit dem Betriebssystem über die Win32-API.

Dort wo die Funktionen vorhanden sind werden sie genutzt. Da ist nichts 
verwerfliches dran. Die Win32-API sind bei Kernfunktionen bereits 
geladene DLLs und .NET besteht ebenfalls aus DLLs. Sowohl .NET kann die 
API aufrufen als auch umgekehrt. Das ist keine Einbahnstrasse, das ist 
ein sehr ausgefuchstes System, was sich MS da Anfang Millenium 
ausgedacht hat. Auch ein Framework wie QT hat nicht die Windows-API 
nachgestrickt, sondern bedient sich derer.

> Und
> damit ist es ein Schichtkuchen, der zwischen dem auf .Net aufsetzenden
> Programm und der Win32-API liegt.

Es existiert mit, auf und neben der API. API-Funktionen können von .NET 
aus auch direkt aufgerufen werden, wenn es einen Bedarf dafür gibt (oder 
man das möchte).

"Microsoft Win32 to Microsoft .NET Framework API Map"
http://msdn.microsoft.com/en-us/library/aa302340.aspx

> Wenn per .Net eine Datei aufgemacht wird, wird irgendwann die
> Win32-Funktion CreateFile aufgerufen.

Ja das stimmt. Du wirst es nicht glauben, ich hab mir mal den Spass 
erlaubt mit dem OllyDbg die C# Methode FileMode.Create zu tracen (die 
Express-Version von C# bei mir gibt das selber leider nicht her, ich 
muss wohl aufstocken ;)). Hat mich sehr viel Zeit gekostet, da sich der 
Debugger (noch) keine Breakpoints (beim Restart) merkt (oder ich ihn 
nicht gescheit bedienen kann, weil eher selten benutzt). Nachdem der 
mein ca. 10 Zeilen C# Programm zum Erstellen einer Datei hat durch alle 
möglichen DLLs hüpfen lassen (springt dabei immer wieder mal ins Modul 
der CLR) landete der letzte und entscheidene CALL in der mscorlib_ni 
(gehört zu .NET) von wo aus dann der Aufruf KERNEL32.CreateFileW 
geschieht. Die DLL braucht nicht geladen zu werden, ist sowieso geladen. 
Man sieht sehr schön den Filenamen, das Setzen der Zugriffsrechte usw. 
Ich hab das aber auch nicht anders erwartet.

Inzwischen hab ich rausbekommen, dass auch die Sourcen von .NET frei 
downloadbar sind unter
http://referencesource.microsoft.com/netframework.aspx
so dass man das wohl auch etwas bequemer hätte haben können, wohl aber 
nicht mit der C# Express-Version.

> Wenn per .Net ein Fenster
> geöffnet wird, wird üblicherweise* die Win32-Funktion CreateWindow
> aufgerufen. Und so zieht sich das Grundkonzept durch die gesamte
> .Net-Schicht. Geht auch nicht anders, solange das Betriebssystem nicht
> selbst durch was anderes ersetzt wird, muss mit dem Betriebssystem
> kommuniziert werden, und das geschieht nunmal durch die native API, die
> das Betriebssystem Anwendungsprogrammen zur Verfügung stellt. Und das
> ist auch unter Windows 7 die Win32-API (resp. die auf 64 Bit aufgebohrte
> Variante davon).

Du weißt genau, dass Windows niemals so einfach die bestehende API 
hinwegfegen könnte, ohne die berühmte Rückwärtskompatibilität über den 
Haufen zu werfen. Die API hat auch noch obsolete Win16 Funktionen, ist 
also ein Hort der zeitlichen Constanz wenn man so will. Deswegen läuft 
ja auch noch so viel von der alten Software unter Windows (mit 
Ausnahmen).

> Das Schichtkuchen-Konzept trifft auf echte C++-Klassenbibliotheken wie
> Qt, wxWidgets und die MFC exakt genauso zu, ein Differenzierungsgrad ist
> die Schichtstärke, die bei der MFC am dünnsten ist, gefolgt von
> wxWidgets und dann Qt.

Auf .NET bezogen ist die Zeit die mit dem Verwalten d.h. Prüfen des 
Codes verbracht wird viel länger, als ein (bloßer) Aufruf einer 
Win32-Funktion. Beim tracen aus dem Beispiel oben ist mir das 
aufgefallen wie oft in die CLR eingeteten und wieder ausgetreten wird. 
Aber selbst das spielt für eine Funktion wie der Dateierstellung mit 
Sicherheit keine Rolle, weil die sowieso nicht ein paar Millionen mal 
pro Sekunde aufgerufen wird. Die Flaschenhälse die es da bestimmt auch 
gibt liegen woanders (auch nicht in der Fensterverwaltung, von der auch 
ein Teil auf der Grafikhardware geschieht). Für den Anwender - hier 
speziell dem Programmierer - spielt das alles erst mal eine völlig 
untergeordnete Rolle. Für den ist viel wichtiger, dass er möglichst ohne 
zuviel Gehirnakrobatik und Hintergrundwissen sein Programm um graphische 
Elemente aufpeppen kann, sprich Windows-Konform hinbekommt. Dem 
Threadersteller ging es um Umrichter und nicht um den Wettbewerb "wie 
schaffe ich die messbar schnellste GUI im Land". Was glaubst du denn 
warum immer mehr Skriptsprachen auf dem Desktop sich breitmachen? Aus 
reinen Performancegründen bestimmt nicht. Da dürfte es das ganze XML 
Zeugs ja gar nicht geben.

Proprietär ist nicht nur immer eine Lizenzfrage, Proprietär war in der 
Vergangenheit auch meist Binär dateicodiert (bestes Beispiel ist das 
Cadsoft-Dateiformat). Nicht-proprietär setzt hingegen auf Text-codierte 
Dateien und Skriptverarbeitung in XML und sonstwas. Da wird auch bewusst 
immer öfter Performance (Möglichkeit) aufgegeben, um Offenheit und 
Umgänglichkeit für Jedermann zu erreichen (neben anderen Vorteilen). Wo 
soll da noch der Nachteil bei .NET sein? Der Zug geht nunmal in diese 
Richtung und die Anwendungen wo es mal wirklich auf extreme Performance 
ankommt sind doch eh die Ausnahme. Das meiste was der Rechner noch immer 
macht ist warten, warten und nichts als warten (kommt ja auch der 
Stromrechnung zu gute, nicht wahr?! ;-)).

Bis Delphi 3 habe ich noch die Umgebungen gekauft. Da ich eventuell 
wieder einsteigen möchte ist die Frage: gibt es heute überhaupt noch ein 
Äquivalent zu den damaligen Umgebungen?

> ...  Delphi 2007 ...

Danke für deine Informationen.

Christian Berger (casandro) schrieb:

> Geiler Rant von unserem anonymen Gast.

Und was hat das mit dem Inhalt meines Postings zu tun?

> 1. Microsoft hat schon viele Techniken mal einfach so von heute auf
> morgen eingestellt, die sie vorher noch als "Zukunftstechniken"
> gepriesen haben.

Tja, ist eben eine innovative Firma und keine Schnarchnase. Schließlich 
hat MS auch c# erfunden und zum ECMA Standard verholfen und c# ist eine 
ideale Programmiersprache für das .NET Framework. Es passt also alles 
schön zusammen. Herz was willst du mehr?!

> Und bei .net ist es dann halt vorbei.

Was soll da vorbei sein? .NET gibt es jetzt seit bald 10 Jahren.

> Das kann ohne
> Microsoft nicht überleben.

Mach dir mal nix draus, aber MS lebt noch lange genug, da kannst du 
drauf wetten. Ganz abgesehen davon, gibt es .NET Techniken auch für 
andere Plattformen, auch wenn dir das ein Dorn im Auge ist. Damit hast 
du dich abzufinden.

> Warum glaubst Du, dass Microsoft bei den
> wichtigen Anwendungen wie dem Internet Explorer, kein .net verwendet?

Könnten sie sicher machen, aber warum glaubst du sollte MS jetzt 
plötzlich schon lange bestehende BS-Teile "ummodeln"? Dazu besteht doch 
gar kein Grund oder Anlass. .NET ist leistungsfähig genug für so 
ziemlich jede Anwendung und dort wo es vielleicht mal einen Performance 
Engpass gibt lässt man sich eben was einfallen.

> 2. TCL/TK gibts seit 1988 und wird heute immer noch entwickelt und
> benutzt. Damals gab es unter Windows gerade mal Windows 2. Neuestes
> Feature: Überlappende Fenster.

Dann denke mal darüber nach warum eine "so tolle und leistungsfähige 
App" es nicht geschafft hat für sich den Markt zu erobern. Genau 
genommen winken selbst die meisten Linuxer ab und wenden sich lieber QT 
zu.

"Schließlich
hat MS auch c# erfunden und zum ECMA Standard verholfen"

Genauer gesagt war Hewlett-Packard und Intel auch beteiligt.

Auszug aus Wikipedia http://de.wikipedia.org/wiki/C-Sharp

"C# greift Konzepte der Programmiersprachen Java, C++, Haskell, C sowie 
Delphi auf. C# zählt zu den objektorientierten Programmiersprachen und 
unterstützt sowohl die Entwicklung von sprachunabhängigen 
.NET-Komponenten als auch COM-Komponenten für den Gebrauch mit 
Win32-Applikationen."

.... schrieb:
> Der Prozessor unabhängige IL-Code (eine stack-orientierte
> Assemblersprache) wird anders als bei JAVA zudem NICHT INTERPRETIERT,
> sondern stückweise DIREKT vom extrem schnellen JIT-Compiler in
> MASCHINENCODE übersetzt, dabei aber zusätzlich während der Ausführung
> von der CLR (der Laufzeitumgebung) auf Korrektheit und Integrität
> überprüft (eben gemanaged).

und

> Es ist ein RIESEN Unterschied, ob "nur" interpretiert oder aber nativer
> Code just in Time compiliert und dann sofort ausgeführt wird. Als jemand
> der Ahnung von der Materie hat solltest du das wissen.

Tja, das hast du auch die letzten 10 Jahre Java-Entwicklung verschlafen. 
Reine Interpretierung gibts beim normalen Java-System auch nicht mehr. 
Dein so toller JIT-Compiler existierte zuerst für Java. Gerade Java hat 
das ganze Forschungsgebiet der Binary Translation ziemlich gepusht und 
eine Menge an neuen Konzepten aufgebracht. Laufzeitchecks sind da 
übrigens auch drin und "normal". MS hat das ganze System einfach nur gut 
kopiert und ein paar Dinge verbessert, einzigartig ist das Konzept der 
CLR aber nicht. Ebensowenig wie das Konzept der virtuellen Maschine von 
Java/C# erfunden wurde.


BTW: Ich finde diese Sprach-(Flame)wars immer sehr spassig. 
Typischerweise sind die mit der "nur X taugt was, alles andere ist 
Bullshit"-Haltung diejenigen, gar keinen Überblick haben und ihre eigene 
Weltsicht übers Brett vorm Kopf hinaus extrapolieren. Gute Programmierer 
erkennt man IMO daran, dass sie ein "Portfolio" von verschiedenen 
Sprachen mit verschiedenen Konzepten (und damit Anwendungsgebieten) 
haben und die jeweils passende dann einsetzen. Klar kann es Lieblinge 
geben, aber genau eine (egal wie gut beherrscht und penetrant vertreten) 
ist armselig.

Georg A. (Gast) schrieb:

> Tja, das hast du auch die letzten 10 Jahre Java-Entwicklung verschlafen. > Reine 
Interpretierung gibts beim normalen Java-System auch nicht mehr.

Ich bezog mich auf einen Artikel aus dem Jahre 2003 der Zeitschrift iX. 
Das es seit dem inzwischen eine enorme Weiterentwicklungen gibt ist 
klar, betrifft aber auch C#/.NET (ist auch nicht mehr bei v1.0). Es war 
auch nicht meine Absicht mich hier groß über Java auszulassen. Im Kern 
ging es um eventuelle Geschwindigkeitsvorteile von rein nativen 
Frameworks wie QT (primär C++) gegenüber einem (wie ich es ausdrücken 
würde) gemischt- teil- oder (weil gemanaged) bedingt-nativem Framework 
wie .NET (multible Programmiersprachen, vorzugsweise C#). Java hat 
längst einen nicht zu vernachlässigenden Marktanteil erreicht, was aus 
der Sicht von Performancegründen eher ein Argument für als gegen .NET 
ist, da JAVA wohl kaum als sonderlich performanter gilt als 
.NET-Compilate und schon gar nicht als C++ via QT-Compilate.

> Dein so toller JIT-Compiler existierte zuerst für Java. Gerade Java hat
> das ganze Forschungsgebiet der Binary Translation ziemlich gepusht und
> eine Menge an neuen Konzepten aufgebracht. Laufzeitchecks sind da
> übrigens auch drin und "normal".

Gewiss, MS hat sich meines Wissens auch stark mit dem Thema JAVA 
auseinandergesetzt, hatte aber wohl für sich gute Gründe entdeckt, warum 
man nicht mit auf den Java-Zug aufspringt (auch firmenpolitische, 
marktstrategische Gründe).

> MS hat das ganze System einfach nur gut
> kopiert und ein paar Dinge verbessert,

Warum sagst du nicht gleich, sie hätten alles abgekupfert? Kannst du dir 
eigentlich überhaupt vorstellen was in einem komplexen Framework wie 
.NET und dem Erfinden einer Sprache wie C# für gewaltige Ressourcen 
drinstecken? Glaubst du das hat ein Frickler über nacht auf die Beine 
gestellt?!

> einzigartig ist das Konzept der
> CLR aber nicht. Ebensowenig wie das Konzept der virtuellen Maschine von
> Java/C# erfunden wurde.

Du kannst bei Wikipedia nachlesen, dass C# sich schlauerweise die 
positiven Aspekte bestimmter Sprachen wie JAVA, C++ etc. zu eigen 
gemacht hat und bestimmte Bestandteile bewusst (aus Gründen der 
Sicherheit respektive Fehleranfälligkeit) weggelassen hat. Ich sehe da 
nichts verwerfliches dran, im Gegenteil, es ist gut und vernünftig aus 
dem Fehlerpotential bestehender Dialekte zu lernen.

> BTW: Ich finde diese Sprach-(Flame)wars immer sehr spassig.

Ich finde was ganz anderes. Ich finde es völllig daneben und lächerlich 
grundsätzlich alles was im Zusammenhang mit MS steht abzubashen und 
gleichzeitig alles was MS nicht zuzurechnen ist völlig kritikfrei zu 
sehen. Das ist weder ehrlich, noch klug, noch hilft es jemandem wie dem 
TE bei der Entscheidungsfindung - das ist einfach nur ideologisch und 
als solches meistens auch leicht zu entkräften.

> Typischerweise sind die mit der "nur X taugt was, alles andere ist
> Bullshit"-Haltung diejenigen, gar keinen Überblick haben und ihre eigene
> Weltsicht übers Brett vorm Kopf hinaus extrapolieren.

Und was meinst du was Leute machen, wenn sie Sätze raushauen wie ".NET 
hat keine Zukunft" oder "MS hat alles nur abgekupfert" oder "ist nicht 
plattformunabhängig, dann taugt es nicht" etc machen? Solche Äußerungen 
bedienen genau dieses (DEIN) Argument. Oder hast du irgendwo von mir 
gelesen, dass nur .NET was taugen würde? Wohl kaum.

> Gute Programmierer
> erkennt man IMO daran ...

Es ging hier nicht darum wer gut programmieren kann und wer nicht. Das 
ist völlig irrelevant. Hier ging es um die Wahl der Mittel (des 
Werkzeugs). Im übrigen ist DIE RICHTIGE Programmiersprache immer die, 
die man selber am besten kann (das muss längst nicht die sein, die für 
ein Problem am besten geeignet ist). Jeder darf seine Vorlieben 
ausleben. Wer noch keine hat, dem darf man Tipps geben sich für das ein- 
oder andere zu entscheiden. Es muss noch nicht mal ein entweder-oder 
geben, es kann auch ein sowohl als auch geben. Viele Unterschiede liegen 
sowieso eher im Detail als im großen Gegensatz. Manche mögen dasjeilige 
Detail jedoch als großen Unterschied zu empfinden. Jeder wie er mag.

Wenn wir das alles ein wenig berücksichtigen sind wir schon weiter und 
können uns ganz entspannt über solche Themen (im positivsten) Sinn des 
Wortes streiten. Einen "Flamewar" braucht es dazu nicht. Ein paar 
knackscharf formulierte Worte können aber dann und wann (wie ich finde) 
hilfreich sein. Bewusstes Bashen ist jedoch ein no go.

> Im übrigen ist DIE RICHTIGE Programmiersprache immer die,
>die man selber am besten kann (das muss längst nicht die sein, die für
>ein Problem am besten geeignet ist)

scherz oder ?

da fehlt wohl ein ;-)



(ich hab zwar den Faden verloren, wer jetzt für und gegen .Net ist..)

aber, wie weiter oben schon steht, wer programmieren KANN, hat sowieso 
keine problem sich innerhalb ein paar tagen/wochen auf eine andere 
programmiesprache einzulernen,
und wir dies auch tun (müssen)



noch was zum thema plattformunabhängigkeit..

sowas gibt es nicht

sieht man schön an den JAVA apps für android (die ja alle 1:1 am iphone 
laufen ;-)... oder am PC ...

(teilweise) laufen ja nicht mal die Telefon -Apps auf den Tablet mit 
"selben" betriebssystem...

.... schrieb:

> Ich bezog mich auf einen Artikel aus dem Jahre 2003 der Zeitschrift iX.
> Das es seit dem inzwischen eine enorme Weiterentwicklungen gibt ist...

Zu dem Zeitpunkt gab es JITs für Java schon ca. 6 Jahre. Das 
HotSpot-Konzept, das dynamisch zwischen Interpretierung und JIT 
umschaltet, wurde von Sun schon 1999 vorgestellt. Öffentlich war da von 
.NET oder der CLR AFAIR noch gar nichts bekannt.

> Warum sagst du nicht gleich, sie hätten alles abgekupfert? Kannst du dir
> eigentlich überhaupt vorstellen was in einem komplexen Framework wie
> .NET und dem Erfinden einer Sprache wie C# für gewaltige Ressourcen
> drinstecken?

Ja, kann ich durchaus. Allerdings war der Kraftaufwand für MS auch 
bitter notwendig, nachdem sie der Java-Hype so um '97 rum eiskalt 
erwischt hat. Sie waren vermutlich der Überzeugung, dass die JVM 
längerfristig auch Windows als OS überflüssig macht. Es gab ja dann auch 
relativ schnell auch ein MS-Java, das hatte AFAIR aber schon ein paar 
inkompatible Erweiterungen. Die riesige .NET-Infrastruktur hat ja dann 
noch ein Weilchen gedauert.

> Glaubst du das hat ein Frickler über nacht auf die Beine gestellt?!

Was ich glaube, tut hier nichts zur Sache. Es geht hier nur darum, dass 
deine Aussagen zu .NET (vs. Java) wenig mit der Realität zu tun haben.

> Ich sehe da nichts verwerfliches dran, im Gegenteil, es ist gut und
> vernünftig aus dem Fehlerpotential bestehender Dialekte zu lernen.

Ich sehe da auch nichts verwerfliches, aber man wird doch auch mal sagen 
dürfen, dass hier keiner im luftleeren Raum arbeitet und MS erst recht 
nicht. Java hat zB. viel von C++ und Objective-C übernommen, die JVM hat 
viele Anleihen beim p-code genommen.

BTW: Weder C# noch Java gehören zu meinen Lieblingssprachen.

Georg A. (Gast) schrieb:

.... schrieb:

>> Ich bezog mich auf einen Artikel aus dem Jahre 2003 der Zeitschrift iX.
>> Das es seit dem inzwischen eine enorme Weiterentwicklungen gibt ist...

> Zu dem Zeitpunkt gab es JITs für Java schon ca. 6 Jahre. Das
> HotSpot-Konzept, das dynamisch zwischen Interpretierung und JIT
> umschaltet, wurde von Sun schon 1999 vorgestellt. Öffentlich war da von
> .NET oder der CLR AFAIR noch gar nichts bekannt.

Ja und? Es ist überall nachzulesen, dass JAVA bei der Entwicklung von 
C#/.NET eine beachtliche Rolle gespielt hat. Dein Einwand hier ist ein 
Werfen von Nebelkerzen.

>> Warum sagst du nicht gleich, sie hätten alles abgekupfert? Kannst du dir
>> eigentlich überhaupt vorstellen was in einem komplexen Framework wie
>> .NET und dem Erfinden einer Sprache wie C# für gewaltige Ressourcen
>> drinstecken?

> Ja, kann ich durchaus.

Deswegen gebe ich auch auf deine Einlassung hier nichts. Sie ist nur von 
Neid und Missgunst motiviert.

> Allerdings war der Kraftaufwand für MS auch
> bitter notwendig, nachdem sie der Java-Hype so um '97 rum eiskalt
> erwischt hat.

Man wächst an seinen Gegnern.

> Sie waren vermutlich der Überzeugung, dass die JVM
> längerfristig auch Windows als OS überflüssig macht.

Absolut dummes Zeug.

> .. Die riesige .NET-Infrastruktur hat ja dann
> noch ein Weilchen gedauert.

Siehst du, daran kannst du ablesen wie komplex es ist ein solch großen 
FW wie .NET aus dem Boden zu stampfen.

>> Glaubst du das hat ein Frickler über nacht auf die Beine gestellt?!

> Was ich glaube, tut hier nichts zur Sache.

Doch das tut es, denn deinen Glauben zur Sachlage hast du hier ja 
bereits geäußert.

> Es geht hier nur darum, dass
> deine Aussagen zu .NET (vs. Java) wenig mit der Realität zu tun haben.

Na im Vergleich zu deinem missgönnenden Geschwurbel hier braucht sich 
mein wirklich Schriftgut nicht zu verstecken.

>> Ich sehe da nichts verwerfliches dran, im Gegenteil, es ist gut und
>> vernünftig aus dem Fehlerpotential bestehender Dialekte zu lernen.

> Ich sehe da auch nichts verwerfliches, aber man wird doch auch mal sagen
> dürfen, dass hier keiner im luftleeren Raum arbeitet und MS erst recht
> nicht.

Hättest du nur das gesagt, hätte auch keiner was dagegen geschrieben. 
Deine Sätze waren aber ganz anderer Natur.

> Java hat zB. viel von C++ und Objective-C übernommen, die JVM hat
> viele Anleihen beim p-code genommen.

Siehst du, deswegen brauchst du JAVA nicht über den Klee zu loben und 
C++ hat die Objektorientiertheit auch nicht erfunden.

> BTW: Weder C# noch Java gehören zu meinen Lieblingssprachen.

Das darfst du halten wie du möchtest.

BTW: Das alles führt zu nichts und um den TE geht es Leuten die hier 
gerne immer wieder alle möglichen historischen Entwicklungen ins Spiel 
bringen, um ein FW in Misskredit zu zerren, schon lange nicht mehr. 
Diese überflüssigen ideologischen Grabenkämpfe helfen niemanden bei der 
Orientierung in der Frage mit welcher Programmierumgebung man sich mal 
ein wenig näher beschäftigt.

> b) kapiert sowieso keiner mehr (ich zumindest nicht) was du überhaupt
> willst..

Richte deinen Appell an den Poster Georg A. (Gast), der unbedingt meint 
hier einen Grabenkrieg vom Zaun brechen zu müssen.

> Als klar denkender Mensch weiss er jetzt, um
> welche Sprachen er besser einen Bogen macht :-)

Dass wären dann die Sprachen JAVA, C# und C++. Gerade die 
erfolgreichsten Programmiersprachen um die man einen Bogen machen soll. 
Sehr "sinnig".

:-)

.... schrieb:
> Deswegen gebe ich auch auf deine Einlassung hier nichts. Sie
> ist nur von Neid und Missgunst motiviert.

Nö, ich bin einfach nur über das Alter hinaus, in dem man von irgendwas 
"100%-Fan" sein und jeden Hype mitmachen muss.

> Richte deinen Appell an den Poster Georg A. (Gast), der unbedingt meint
> hier einen Grabenkrieg vom Zaun brechen zu müssen.

Grabenkrieg? Ich fahr hier grad mit'm Ballon in 100m über den Gräben und 
knabber Popcorn...

Du (....) erzählst einfach technischen Mist, und den wollte ich 
richtigstellen. Du hast rumgeschwurbelt, wie toll JITs bei .NET sind, im 
Gegensatz zum interpretierten Java. Dass das schon schon zu Einführung 
von .NET auch bei Java kein Thema mehr war, wusstest du ja 
offensichtlich nicht. Das kommt davon, wenn man selber im Graben sitzt 
und nicht mal den Kopf rausstreckt ;)

Ich habe den starken Verdacht, dass du die Zeit, wo Java und die JITs 
aufgekommen sind, noch gar nicht so bewusst mitbekommen hast...

@  Robert L. (lrlr)

Tja siehst du, der Poster gibt keine Ruhe. Was will man da machen?

Georg A. (Gast) schrieb:

> Nö, ich bin einfach nur über das Alter hinaus, in dem man von irgendwas
> "100%-Fan" sein und jeden Hype mitmachen muss.

So alt bisst du gar nicht, sonst würdest du hier diese Kinderei nicht 
abziehen.

> Grabenkrieg? Ich fahr hier grad mit'm Ballon in 100m über den Gräben und
> knabber Popcorn...

Leute die Popkorn knabbernd dauernd andere Leute am Rechner anmachen 
erfüllen die Definition eines Trolls perfekt.

> Du (....) erzählst einfach technischen Mist, und den wollte ich
> richtigstellen.

Wenn der Herr meinen.

> .. schon zu Einführung von .NET auch bei Java ..

Du hast einfach noch nicht mitbekommen, dass ich mich hier gar nicht 
großartig zu Java geäußert habe, bis auch den Vergleich aus der iX aus 
dem Jahre 2003 den ich hier einbrachte. Es ging um etwas ganz anderes. 
Nochmal damit auch du Schnarchnase es endlich mal kapierst: ICH VERWENDE 
KEIN JAVA! PUNKT.

Mir ist Java sowas von egal, da kannst du dich noch weitere 10 Postings 
dran hochziehen und JAVA verteidigen was du nicht mal selber 
verwendenst. Das ist totale Idiotie.

BITTE DEN THREAD HIER ENDLICH SCHLIEßEN!

Begündung: Die Deppenposter nehmen hier einfach überhand.

Habt ihr eigentlich noch alle Latten am Zaun???

@Zwie Blum:

Glückwunsch, das war der erste vernünftige Beitrag zu diesem Thema. Auf 
ARD läuft jetzt gleich noch der Hitchcock-Klassiker "Psycho". Kann man 
glatt vergessen gegen dem, was hier so abläuft.

Arc Net schrieb:

>> Zu dem Zeitpunkt gab es JITs für Java schon ca. 6 Jahre.
>
> Wenn schon dann 3 Jahre (HotSpot ab 1999, .Net ab 2002)...Sun hatte die

Hot Spot!=JIT. Hot Spot war die Antwort auf das Problem der "normalen" 
JITs, dass sie auch für nur einmal angesprungende Methoden den ganzen 
Übersetzungsaufwand haben. Gerade beim Startup und für GUIs war das eher 
lästig. Schon JDK1.2 (98 oder so) hatte einen JIT, ich hatte damals 
jedenfalls schon Benchmarks mit JIT vs. ohne gemacht. Inoffizielle JITs 
für Java gabs aber schon 96-97 (zB. Cacao, IBM hatte doch auch 
irgendwas, AFAIR sogar vor Sun).

> Visual Studio 97 gab's wie der Name schon sagt ab 1997 und unterstützte
> Java (Visual J++ 1.1). Wenn sie kalt erwischt worden wären, hätten sie
> zu dem Zeitpunkt keine IDE und inkompatible Erweiterungen gehabt.

Dass MS Trends schnell adaptieren und in 0,nix viel Code aus dem Boden 
stampfen kann, ist bekannt. Hat ja mit dem IE schon gut funktioniert ;) 
Ich denke aber nicht, dass das VM-Thema in dem Ausmass (oder überhaupt) 
in der strategischen Planung vorkam. Dass sie mit ihrem "eigenem" Java 
auch noch am Lizenz-Tropf (samt Patenten) von Sun hingen und sich Sun da 
auch nicht gerade nett aufgeführt hat, hat den Zwang für was eigenes nur 
noch verstärkt.

.... schrieb:

> Mir ist Java sowas von egal, da kannst du dich noch weitere 10 Postings
> dran hochziehen und JAVA verteidigen was du nicht mal selber
> verwendenst. Das ist totale Idiotie.

Wenn pubertierende Fanboys Mist erzählen, finde ich eine kleine 
Korrektur durchaus angemessen. Sonst glaubts glatt noch jemand. Und ob 
ich jetzt Java verwende oder nicht, ändert daran nichts.

Georg A. (Gast) schrieb:

.... schrieb:
>> Mir ist Java sowas von egal, da kannst du dich noch weitere 10 Postings
>> dran hochziehen und JAVA verteidigen was du nicht mal selber
>> verwendenst. Das ist totale Idiotie.

> Wenn pubertierende Fanboys Mist erzählen, finde ich eine kleine
> Korrektur durchaus angemessen. Sonst glaubts glatt noch jemand. Und ob
> ich jetzt Java verwende oder nicht, ändert daran nichts.

Jeder hat seine Vorlieben, die Linux Fanboys haben die ihren und ich die 
meinen. Daran ist nichts verwerfliches. Ich habe niemandem etwas 
aufgezwängt. Ich hab mich hier überhauot nur zu Wort gemeldet, weil der 
.NET-Artikel von heise Developer ein einigen Schergen missbraucht wird 
um .NET als überholt darzustellen, was eine bewusste Falschdarstellung 
des Inhaltes ist. Mit der "Pupertät" muss ich dich leider enttäuschen, 
das ist lange her (länger als bei dir). Davon abgesehen hast DU hier 
diesen Kindergartenstreit vom Zaun gebrochen und noch dazu mit falschen 
Behauptungen gefüllt. Meine Aussagen kann jeder in der Quelle die ich 
angab nachlesen und die Quelle ist SEHR GUT. Das es zwischenzeitlich 
auch Entwicklung gegeben hat hab ich ebenfalls hier hinzugeschrieben. 
Insofern lügst DU hier anderen etwas vor, indem du meine Aussage bewusst 
in ein falsches Licht rückst, was ich als bösartig und hinterlistig 
empfinde.

Es ist schon lustig mitzulesen, wie verzweifelt die Ideologen versuchen 
gegen C#/.NET, aber vor allem auch gegen Mono anzuschreiben und zwar 
wider jedes gute Argument, wie z.B. hier

http://www.heise.de/open/news/foren/S-Re-Welchen-Grund-gibt-es-eigentlich-fuer-Mono-C/forum-161618/msg-16985455/read/
http://www.heise.de/open/news/foren/S-Re-Welchen-Grund-gibt-es-eigentlich-fuer-Mono-C/forum-161618/msg-16986889/read/

Aber es ist schon klar aus welcher Ecke das alles kommt. Wenn ein 
Debian-Sprecher bekannt gibt Mono nicht in die Standardinstallation mit 
aufzunehmen, aus Angst (siehe einige Kommentare), Mono könnte vielleicht 
beliebt werden und dem komplizierten C++ den Rang ablaufen, dann ist 
schon klar, dass gebasht und diffarmiert wird, von gewissen Agitatoren 
der Szene, was das Zeug hält. Wenn ich schon lese, Mono die wortwörtlich 
"umstrittene Programmierumgebung". Das ist genau so lächerlich wie dein 
Versuch hier .NET kleinzureden und als Abkupferrei darzustellen. Zum 
Glück aber bleibt das nicht unwiedersprochen wie man sieht.

So jetzt hab' ich mich doch noch mal verleiten lassen. Mein Aufruf den 
Thread zu schließen bleibt bestehen.

Anmerkung :

DELPHI XE2 :  win 32 und Win 64, iOS, ....

DELPHI XE3 (2012)  : incl LINUX....

native cross plattformsupport

Haha, wie immer und lustich, die Zeit holt alles ein:

Ironie in Reinstform:

> Autor: .... (Gast)
> Datum: 18.07.2011 17:50
> Chris (Gast) schrieb:
>> ...
>> Über die Zukunft von .NET wird zur Zeit viel spekuliert:
>> ...
> Skriptsprache kann das nicht ersetzen, es sei denn, Windows schrumpft
 irgendwann zu einem Web-Tablett-ichKlickMalWasAn-OS.
> Solange man aber Applikationen auf Windows entwickelt UM DAMIT AUCH ZU ARBEITEN
> (und nicht nur zu surfen wie auf Tabletts) wird und muss es ein gut ...

..und dann kam Win8 ...
Wie sich sowas entwickeln kann. ;)

(Hab den Beitrag eben erst durch Zufall entdeckt, und konnte mir nicht 
verkneifen, einen piep von mir zu geben)

Keine Frage - mit einem Web-Tablett-ichKlickMalWasAn-*OS* auf einem 
Desktop-PC, welcher nach Möglichkeit noch nen Touchmonitor haben sollte 
aber auch nicht - und das wollte ich eigentlich damit ausdrücken ;)

+1

Jeder Windowsentwickler weiss wie langsam .net ist. Mal eine xaml 
MessageBox aus einer MFC Applikation gestartet? Das dauert, bis die 
angezeigt ist. Schlimm!

Aber MS ist noch viel schlimmer: Microsoft Shamepoint.
Da lernt man erst mal wie langsam Webseiten sein können. ASP.NET!! Was 
da an unnötigem Ballast über die Leitung geht. Stromverschwendung! Da 
die Kunden alle mit der Geschwindigkeit ihres Intranets (Shamepoint!) 
unzufrieden sind, muss Microsoft etwas tun. Und was? Die Kunden bekommen 
eine Server Farm. Dafür müssen sie extra Lizenzen kaufen. Toller Trick, 
oder? Produkt ist schlecht. Kunde muss aufrüsten und noch mehr Geld 
ausgeben.

Aus Scheisse Gold machen! Wer das kann, wird Milliardär.