Forum: PC-Programmierung Delphi nicht zukunftsicher?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von heldvomfeld (Gast)


Lesenswert?

Hallo zusammen,

bezugnehmend auf diesen Thread: 
Beitrag "Delphi: For-Schleifen und Timer"

Prinzipiell möchte ich auf die Diskussion am ende zu sprechen kommen.
Ich baue Frequenzumrichter und möchte in naher Zukunft mit Delphi 
Anwendersoftware schreiben, womit man die Umrichter parametrieren kann. 
Jetzt lese ich in dem Thread, dass Delphi nicht zukunftsicher ist. Ist 
da was dran? Ich verstehe den .net Einwand nicht, kann mich da wer 
aufklären?
Warum ist C# besser und was ist der Unterschied zwischen C++ und C#?

Vielen Dank!

von Frank (Gast)


Lesenswert?

.NET: M$ gebunden

Wenn es zukunftssicher sein soll, nimm normales C.

von Chris (Gast)


Lesenswert?

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.

von Poggi (Gast)


Lesenswert?

Guckst du Embacadero RAD Studio XE

von heldvomfeld (Gast)


Lesenswert?

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.

von .... (Gast)


Lesenswert?

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

von eugler (Gast)


Lesenswert?

.... 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.

von Thomas (Gast)


Lesenswert?

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

von Ackermann (Gast)


Lesenswert?

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

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

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Lesenswert?

.... 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, .Net ist nur ein 
Schichtkuchen, der darauf aufsetzt.

von Arc N. (arc)


Lesenswert?

.... schrieb:
> 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.

Langfristig vielleicht, wenn man versucht alles über einen Kamm zu 
scheren und dann in Kauf nimmt in jedem Fall nicht die beste, sondern 
nur eine bestenfalls mittelmäßige Lösung zu erhalten.
Und der Autor übersieht das MS mit Razor schon einen VB/C# + 
HTML-Hybriden hat. Es muss also nicht ausschließlich JavaScript + HTML 
werden.
Des weiteren werden die Gerätehersteller allen voran Apple versuchen 
genau diese Entwicklung zu verhindern. Wenn alle Apps auf allen Geräten 
laufen und gleich aussehen, gäbe es kein Alleinstellungsmerkmal mehr und 
somit keinen Grund mehr dies zu einer Kaufentscheidung zu machen.

>     .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.

Darauf würde ich auch nicht wetten. Warum soll bspw. ein simpler Integer 
erst in Text umgewandelt, dann in XML/JSON, HTTP, TCP/IP und Ethernet 
verpackt, dann auf der anderen Seite entpackt, konvertiert und 
verarbeitet zu werden und die Antwort dann wieder in Text, XML/JSON, 
HTTP, TCP/IP und Ethernet verpackt und beim Client erneut entpackt 
werden um wieder in die Binärdarstellung konvertiert zu werden um dann 
endlich verarbeitet werden zu können. Schwachsinn. Die Server könnten 
dagegen leicht zu "dummen" Datenservern werden ohne den 
XML/JSON/HTTP-Overhead.
Letztlich könnten sogar die Browser eingestampft werden, da sie bei 
entsprechendem App-Angebot nicht mehr benötigt würden (z.Z. sieht man 
viele Apps die nur die Funktionalität einer Webseite nachbilden, warum 
dann noch die Webseite?).
Wie sinnvoll diese Varianten sind, ist eine andere Frage.

>     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."

JavaScript kann wie eine funktionale Sprache verwendet werden (es 
enthält die notwendigen Konstrukte), ist aber geradezu das 
Paradebeispiel dessen, was man nicht als Programmiersprache haben will: 
Es ist (fast) write-only, selbstmodifizierend, extrem stark typisiert 
(nur ein einziger Typ), usw. und genauso wenig/viel 
funktional/objektorientiert wie C#/C++/D/Delphi irgendwas. Hinzu kommen 
bei JS die fehlenden Controls, das fehlende Databinding, die schlechte 
Unterstützung von Threads, der fehlende/nicht standardisierte Zugriff 
auf Geräte
Objektorientierte Programmierung stößt auch nicht bei der 
Parallelisierung an ihre Grenzen, außer der Autor versteht den 
Unterschied zw. den engl. Begriffen Parallelism und Concurrency, wie 
viele andere, nicht.
http://existentialtype.wordpress.com/2011/03/17/parallelism-is-not-concurrency/

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

Danke für den Link, ein FBler mehr den man guten Gewissens seinen 
Konkurrenten empfehlen kann...

Zum Thema: Selbst wenn Borland oder wie auch immer die Firma jetzt heißt 
irgendwann mal den Betrieb einstellt, die Erfahrungen mit einer 
imperativen, objektorientierten Sprache, kann man immer weiterverwenden 
(die meisten anderen Sprachen unterscheiden sich nur durch ihre Syntax, 
der größte Unterschied sind die notwendigen Frameworks/Bibliotheken).
Windows 7 wird von MS noch bis 2020 supported, Windows 8 noch länger 
d.h. läuft die Software, hätte man genügend Zeit sie anzupassen, falls 
es notwendig wird.

p.s. falls sich jemand wundern sollte, warum hier nicht C# angepriesen 
wird: Delphi, die VCL und C#, .NET sind alle maßgeblich von Anders 
Hejlsberg entwickelt worden und sind sich ziemlich ähnlich...

von .... (Gast)


Lesenswert?

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.

von Klaus D. (kolisson)


Lesenswert?

Bascom ist die Zukunft !

Klaus

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Lesenswert?

.... 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. Es ist vollkommen wurscht, wie .Net 
arbeitet, ob das interpretiert wird, ob es eine noch so tolle 
Standardlibrary ist, ob es handgedengelter Assembler oder 
superdupertoller von Hochleistungscompilern übersetzter Maschinencode 
ist -- es kommuniziert mit dem Betriebssystem über die Win32-API. Und 
damit ist es ein Schichtkuchen, der zwischen dem auf .Net aufsetzenden 
Programm und der Win32-API liegt.

Wenn per .Net eine Datei aufgemacht wird, wird irgendwann die 
Win32-Funktion CreateFile aufgerufen. 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).

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.

*) Üblicherweise, weil dieser vergurkte Kram mittlerweile sein komplett 
eigenes Fensterhandling innerhalb echter Windows-Fenster verpackt; 
wenn man sich mal den Aufbau von z.B. Visual Studio 2010 genauer 
ansieht.
(Damit habe ich mich beschäftigt, weil von Hause aus das Scrollrad mit 
diesem Hochleistungsprodukt annähernd komplett unbrauchbar ist, und die 
Hilfsmittel, die bei normalen Programmen das kaputte Scrollradhandling 
von Windows reparieren, an Visual Studio 2010 scheitern. Ich brauche den 
Kram aber für meine Arbeit)

von Klaus W. (mfgkw)


Lesenswert?

.net ist der vorläufige 64-Bit-Höhepunkt der alten Geschichte:

Windows 98
32 bit extensions and a graphical shell for a
16 bit patch to an
8 bit operating system originally coded for a
4 bit microprocessor; written by a
2 bit company that can't stand
1 bit of competition.

von Robert L. (lrlr)


Lesenswert?

wenn dir Delphi gefällt
nimm Lazarus ;-)

(wie auch schon von Thomas (Gast)  vorgeschlagen)


läuft auf linux/osx/win/wince/...

wenn es (auch) auf android/iphone/ laufen soll

wirds schwieriger

dann wird es eher java werden müssen..


wegen der  win32-api vs. .NET diskussion hier (ist ja recht "lustig" )

einfach mal nach MONO suchen..

von Udo S. (urschmitt)


Lesenswert?

Mal ne blöde Zwischenfrage von jemandem der seit geraumer Zeit nicht 
mehr die Windows API programmieren musste :-)
Ist die Win32 API bzw das .net Geraffel eigentlich 64Bit oder noch alles 
32Bit?
Sprich, kann ich mal auf die Schnelle eine sehr große (z.B. 1Gig) große 
XML Datei einlesen und komplett in entsprechende Objekte verpackt im 
Speicher halten wenn ich genug Speicher habe, das heisst mehr als 2 oder 
gar 4 Gigabyte Speicher für eine Anwendung allozieren?
Danke

von Robert L. (lrlr)


Lesenswert?

ja es gibt (seit kurzem) auch ein 64bit windows ;-)

ABER: auch 32bit windows Programme können (natürlich) files größer 
4gbyte bearbeiten..



aber (natürlich) nicht im ganzen im Speicher behalten

ein win32 Programm kann immer nur maximal (theoretisch) 4gbyte Speicher 
allozieren

1gbyte große files im Speicher zu behalten, wäre/ist aber kein Problem..

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Lesenswert?

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.

von Markus M. (mmvisual)


Lesenswert?

Ich schließe mich auch der Lazarus-Empfehlung an.

Hier die Links:
Das Forum:  http://www.lazarusforum.de/
Die neueste Snapshot-Versionen: ftp://ftp.hu.freepascal.org/pub/lazarus/

So kann ein in Lazarus geschriebenes Programm aussehen:
Beitrag "EleLa - Elektronik Lagerverwaltung"

Lazarus funktioniert mindestens genauso gut, wenn nicht sogar besser als 
Delphi XE. Seit Delphi 7 bin ich vor einigen Jahren auf Lazarus 
umgestiegen und verwende seither kein Delphi mehr. (Einmal musste ich 
ein Delphi-7 Projekt auf Delphi-XE hoch ziehen, konnte es leider nicht 
auf Lazarus portieren, daher kenne ich auch die XE Version)

Nahezu gratis gibt es bei Lazarus die Möglichkeit die EXE unter Linux zu 
kompilieren (Besonderheiten von Linux, Pfade usw. berücksichtigen).

C oder C# ist IMMER gebunden an das Betriebssystem. Bzw. um Sourcen auf 
Windows/Linux hinzu bekommen kann man eigentlich nur eine Console-App 
schreiben. (Siehe z.B. OpenOCD)

Das Linux würde ich mir nicht verbauen, denn so wie man hier sieht 
(Anzahl Downloads) wird Linux sehr viel genutzt!
Beitrag "Re: EleLa - Elektronik Lagerverwaltung"

von Udo S. (urschmitt)


Lesenswert?

Robert L. schrieb:
> ABER: auch 32bit windows Programme können (natürlich) files größer
> 4gbyte bearbeiten..

Das ist mir schon klar, wobei die Standard C Funktion fread() zumindest 
früher bei Datein > 2G buggy war.
Von Microsoft wurde mir damals empfohlen die Win32 API zu benutzen (toll 
portabel!)

Robert L. schrieb:
> 1gbyte große files im Speicher zu behalten, wäre/ist aber kein Problem..

Ich rede davon ein komplexes XML komplett incl. etwaiger Indices und 
Hashtabellen als Objektbaum bzw. als Listen von Objekten im Speicher zu 
halten zwecks schnellem Suchen und Filtern der Daten.
Da reichen bei einer physisch 1G großen Datei die max. 2G Speicher ganz 
schnell nicht mehr aus.

von Udo S. (urschmitt)


Lesenswert?

Rufus Τ. Firefly schrieb:
> 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.

Genau das war die Frage: Gibt es ein extra .net64? Wie heisst das und 
was habe ich wenn ich das kostenlose Visual Studio hole.
Bei Office geht ja wohl die Empfehung von MS sogar dahin die 64 Bit 
Version nur dann zu nutzen wenn man es unbedingt braucht, und ansonsten 
weiter auf die 32 Bit Version zu setzen.
Wie verbreitet ist denn die 64 Bit Programmierung schon?

von Robert L. (lrlr)


Lesenswert?

@udo

soll ich es für dich g..

naja egal

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6523

genau so wie es eben auch java für x64 gibt

z.Z: haben 64bit programme unter windows praktisch keine vorteile 
(ausgenommen die typischen "Speicherfresser" Videobearbeitung, 3D CAD 
usw.)


deine XML frage ist nicht zu beantworten..

nachdem objekte im speicher meist binär abgelegt sind
xml dagegen TEXT ist und mit SEHR SEHR viel overhead (jede 
feldbezeichnung ist ja 1000fach identisch vorhanden)
brauch XML files oft viel mehr platz auf der festplatte als im 
speicher...

deine aufgabenstellung würd ich auch eher dahingehend "lösen" die XML 
datei ein eine datenbank einzulesen..

von W.S. (Gast)


Lesenswert?

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.

von Markus M. (mmvisual)


Lesenswert?

C ist gut, aber nur solange man Hardware nah programmieren tut, also 
Mikrocontroller.

Und da es irgend wann einmal Windows gab und darin dann auf einmal 
Fenster, spätestens dann war C (und deren Kinder) nicht mehr wirklich 
eine optimale Programmiersprache. Alleine die Trennung zwischen 
Ressource eines Windows-Fensters und dem Quellcode ist ein Hindernis das 
mindestens 20% Mehrarbeit bedeutet (aber das verstehen die C-Progger 
nicht, da sie noch nie was anderes gesehen haben).

von Sven P. (Gast)


Lesenswert?

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.

von Christian B. (casandro) Flattr this


Lesenswert?

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

Wenn Du C oder C++ wirklich kannst, und nicht nur glaubst dass Du es 
kannst, dann kannst Du das auch machen. Da es aber nur ein paar hundert 
Leute auf der Welt gibt, die das können, ist Lazarus wohl doch die 
bessere Wahl.

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


Falls Du Dir nicht sicher bist, ob Du C(++) kannst, poste hier mal ein 
kleines Programm, welches das 2. Wort eines der Eingabe wieder ausgibt.
Sprich ich gebe "Dies ist ein Testtext" ein, und das Programm gibt "ist" 
aus.

Ich kann auch C(++) nicht vollständig, aber ich kenne die Fehler, die da 
meistens gemacht werden.

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

von Martin S. (mse)


Lesenswert?

Christian Berger schrieb:
> Nimm für GUI-Sachen Lazarus oder TCL/TK.

Eine weitere Alternative zu Delphi ist MSEide+MSEgui:
http://developer.berlios.de/projects/mseide-msegui/

Im Gegensatz zu Lazarus benützt MSEgui keine externe Widget-Bibliothek, 
sondern ruft direkt die Graphik-Schnittstelle des Betriebsystems auf 
(GDI32 auf Windows und X11/xlib auf Linux). In Arbeit ist eine 
MSEgui-Schnittstelle zu OpenGL.
MSEgui Programme können sowohl mit Free Pascal als auch mit Delphi 7 
kompiliert werden.
Mittels MSEide können auch GNU-toolchain basierte C-Projekte entwickelt 
werden. Beispielsweise programmiere ich meine AVR32 Systeme mit MSEide 
und GCC und die PC-gestützten Bediener-Tools mit MSEgui.
Ebenfalls mit Erfolg eingesetzt wird MSEide+MSEgui in 
Datenbank-Projekten, z.B. das soeben erschienene Acosys V4:
http://www.acosys.co.id/

Einige Videos sind hier:
http://www.youtube.com/watch?v=JdcUSg1b4_w&feature=mfu_in_order&list=UL

Das Erscheinungsbild der MSEgui widgets ist in hohem Masse 
parametrierbar, die widgets in den Videos entsprechen wohl dem 
indonesischen Geschmack. ;-)
Durch den Verzicht auf eine zwischengeschaltete externe 
widget-Bibliothek ist das gewählte Aussehen der MSEgui Programme auf 
Linux und Windows falls gewünscht absolut identisch oder kann durch 
Änderung der Parameter angepasst werden.

Martin

von ♪Geist (Gast)


Lesenswert?

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...

von .... (Gast)


Lesenswert?

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?! ;-)).

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Lesenswert?

Und was soll ich jetzt damit anfangen? Erst widersprichst Du mir, dann 
belegst Du genau das, dem Du ein paar Sätze vorher widersprochen hast.

.Net setzt wie Qt, die MFC, wxWidgets, das VCL-Konzept aus der 
Delphi-Ecke, egal was auch immer schlussendlich auf der Win32-API auf.

von Robert L. (lrlr)


Lesenswert?

(es gibt/gab übrigens auch ein delphi .NET für alle die lieber Pascal 
anstelle von C# programmieren ;-)

inzwischen
Delphi Prism XE .. (ist aber glaub ich nur mehr "pascal ähnliche" 
sprache?)

damit könnte man  .NET anwendungen für MacOSX/linux und windows 
schreiben..
(scheinbar auch iPhone?)

ich möchte (diesbezpgich) auch nochmal auf MONO hinweisen (ich weiß 
nicht warum hier so oft behauptet wird, .NET wäre nur für windows...)

von Hans (Gast)


Lesenswert?

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?

von Robert L. (lrlr)


Lesenswert?

ja
lazarus ;-)
das ist optisch noch ziemlich Delphi 3/5/7 like ...

hat auch einen delphi->lazarus "converter"



falls du alte Programme Konvertieren willst:

bis Delphi 2007 sollte es "halbwegs" problemlos gehen Delphi 3 Projekte 
zu compilieren (weil NICHT Unicode)

ab delphi 2009 ist dann unicode..

von Hans (Gast)


Lesenswert?

> ...  Delphi 2007 ...

Danke für deine Informationen.

von Christian B. (casandro) Flattr this


Lesenswert?

Geiler Rant von unserem anonymen Gast.

1. Microsoft hat schon viele Techniken mal einfach so von heute auf 
morgen eingestellt, die sie vorher noch als "Zukunftstechniken" 
gepriesen haben. Und bei .net ist es dann halt vorbei. Das kann ohne 
Microsoft nicht überleben. Warum glaubst Du, dass Microsoft bei den 
wichtigen Anwendungen wie dem Internet Explorer, kein .net verwendet?

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.

von .... (Gast)


Lesenswert?

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.

von Markus M. (mmvisual)


Lesenswert?

>ja
>lazarus ;-)
>das ist optisch noch ziemlich Delphi 3/5/7 like ...

... und das ist auch gut so. Ich finde diese Oberfläche viel 
übersichtlicher.

Die neue Delphi-Oberfläche ist lange nicht so übersichtlich und viel zu 
viele fette Fenster die man braucht und einem den Bildschirm wegnehmen.
Die alte Oberfläche, da konnte man die einzelnen Fenster überlagern.

von .... (Gast)


Lesenswert?

"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."

von Arc N. (arc)


Lesenswert?

.... schrieb:
>> "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

"In January 1999, Anders Hejlsberg formed a team to build a new 
language" und
"C#'s principal designer and lead architect at Microsoft is Anders 
Hejlsberg" 1)
Davor hatte MS intern ein "Simple Managed C" entwickelt 1)
Zusammen mit "...Hewlett-Packard and Intel Corporation co-sponsored the 
submission of specifications ... to the standards organization"
ist die deutsche Wikipedia-Version,
"Microsoft reichte ... zusammen mit Hewlett-Packard und Intel C# bei der 
Normungsorganisation Ecma International zur Normung ein.", freundlich 
gesagt, sinnentstellend formuliert

1) http://en.wikipedia.org/wiki/C_Sharp_(programming_language)

von Georg A. (Gast)


Lesenswert?

.... 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.

von Zwie B. (zwieblum)


Lesenswert?

"Portfolio" ... He ho! Willst du behaupten, dass aus den 
Profi-WIFI-AMS-Kursen keine echten vollständigen Vollprofis rauskommen? 
"In 3 Monaten vom Nubbler zum IT-Profi mit .NET - Ihr Kurs beim AMS" - 
da kommen 99% aller Selbständigen aka Freelancer in Österreich her! Das 
sind waschechte Profis mit MSCE Zertifikat® ... Abgesehen davon, die 
einzig ernstzunehmende Sprache ist LISP!

von .... (Gast)


Lesenswert?

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.

von lrlr (Gast)


Lesenswert?

> 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...

von Robert L. (lrlr)


Lesenswert?

nachtrag:

>sowas gibt es nicht

damit meinte ich: es hat nichts mit der SPRACHE zu tun
sondern WIE man programmiert...
(bzw. macht man ja nicht alles selber, also auch wie die frameworks die 
man verwendet programmiert sind)

jenachdem ist ein TEIL von seinem programm dann 
plattformunabhängig(er)..

von Georg A. (Gast)


Lesenswert?

.... 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.

von .... (Gast)


Lesenswert?

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.

von Zwie B. (zwieblum)


Lesenswert?

> 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.

Aber klar hilft das! Jetzt weiss der TE, wie es ist, wenn einäugige
Hühner um ein Korn kämpfen. Als klar denkender Mensch weiss er jetzt, um
welche Sprachen er besser einen Bogen macht :-)

von Robert L. (lrlr)


Lesenswert?

@....


lass es bitte

a) ist es OT
b) kapiert sowieso keiner mehr (ich zumindest nicht) was du überhaupt 
willst..




ist Word, Exel, MySQL server, ... oder sonst irgend ein MS mayor produkt 
eigentlich mal nach .NET portiert worden ?!?!?

von Robert L. (lrlr)


Lesenswert?

das sollte natürlich MS-SQL heißen....

von .... (Gast)


Lesenswert?

> 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".

:-)

von Robert L. (lrlr)


Lesenswert?

es gibt übrigens (scheinbar) auch einen "aktuellen" beitrag

http://www.heise.de/developer/artikel/Java-versus-NET-962309.html


allerdings wohl nur java vs. .NET

und das geht (erwartungsgemäß) wohl unentschieden aus..

flameware ala amd<>intel, amd<>nvidia, diesel<>benzin... sind ja wohl 
kindergarten..

von Georg A. (Gast)


Lesenswert?

.... 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...

von Arc N. (arc)


Lesenswert?

Georg A. 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.

Wenn schon dann 3 Jahre (HotSpot ab 1999, .Net ab 2002)...Sun hatte die 
Technik dazu (ebenso wie die für HotSpot 1) 2)) mit den 
Strongtalk-Entwicklern eingekauft und dann das bessere System sterben 
lassen.
Die Ideen dazu sind wesentlich älter (1960) und kommen, wie vieles was 
heute als modern verkauft wird, aus dem LISP Umfeld 3).

1) http://en.wikipedia.org/wiki/Strongtalk
2) http://en.wikipedia.org/wiki/HotSpot
3) 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.3985&rep=rep1&type=pdf

> 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.

C# wurde 2000 vorgestellt, intern lief das Projekt (ASP.NET, CLR) seit 
1997, C# wurde erst 1999 "gestartet" 4)
Vorteile hat das Konzept allerdings bis heute weder bei Java noch bei C# 
gezeigt.

4) http://en.wikipedia.org/wiki/C_Sharp_(programming_language)

> 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.
> Es gab ja dann auch relativ schnell auch ein MS-Java, das hatte AFAIR aber
> schon ein paar inkompatible Erweiterungen.

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.

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

und C++ bei mir auch nicht mehr...

Robert L. schrieb:
> ist Word, Exel, MySQL server, ... oder sonst irgend ein MS mayor produkt
> eigentlich mal nach .NET portiert worden ?!?!?

Abgesehen davon, dass auch .NET ein "Major Product" ist, warum sollte 
man mal eben so mehrere 10 Millionen SLOCs portieren?
Beim aktuellen VS wurde dies z.T. gemacht (Oberfläche ist nun WPF) und 
insg. mittlerweile die Hälfte managed ~22 Millionen SLOCs 5).
Andere Software von MS siehe 6)
Und MS hat mit Singularity 7) (und davon abgeleitet Verve 8)) auch 
vollständige Betriebssystem in managed Code... Verve enthält keine 
einzige Zeile C und C++Code und ist vollständig verifiziert.

5) 
http://stackoverflow.com/questions/228024/what-major-applications-does-microsoft-sell-which-use-the-net-framework
bzw.
http://channel9.msdn.com/shows/Going+Deep/Rico-Mariani-Visual-Studio-Today-Tomorrow-and-Beyond/
6) http://blogs.msdn.com/b/danielfe/archive/2005/12/16/504847.aspx
(2005 waren es laut diesem Post min. 16 Millionen SLOCs)
7) 
http://research.microsoft.com/pubs/69431/osr2007_rethinkingsoftwarestack.pdf
8) http://research.microsoft.com/pubs/122884/pldi117-yang.pdf

> es gibt übrigens (scheinbar) auch einen "aktuellen" beitrag
> http://www.heise.de/developer/artikel/Java-versus-...

über die Artikel (auch den oben verlinkten) könnte man noch lange 
diskutieren (div. Fehler, Ungenauigkeiten etc.)

von .... (Gast)


Lesenswert?

@  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.

von Markus G. (Gast)


Lesenswert?

Habt ihr eigentlich noch alle Latten am Zaun???

von Zwie B. (zwieblum)


Lesenswert?

Latten haben die schon noch alle, denn die brauchen sie um ihre Tassen 
im Schrank zu zerdeppern (wenn da noch eine heil ist) :-)

von Markus G. (Gast)


Lesenswert?

@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.

von Georg A. (Gast)


Lesenswert?

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.

von .... (Gast)


Lesenswert?

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.

von Zwie B. (zwieblum)


Lesenswert?

.NET = geht net

(feed the Trolls! - eine Aufforderung des Umweltministeriums)

von franz (Gast)


Lesenswert?

Anmerkung :

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

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

native cross plattformsupport

von Robert L. (lrlr)


Lesenswert?

Anmerkung :

aber nicht mit der VCL

von bob (Gast)


Lesenswert?

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)

von Purzel H. (hacky)


Lesenswert?

Mit einem Web-Tablett kann man aber nicht arbeiten. Und Ja. Ich hab auch 
ein Tablett.

von bob (Gast)


Lesenswert?

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 ;)

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

An beiden Gerätearten kann man ne Maus anschließen. Win8 scheint mir 
aber noch überflüssiger als Vista zu sein.

von bob (Gast)


Lesenswert?

+1

von Windowsentwickler (Gast)


Lesenswert?

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.

von Alfons G. (alibaba55)


Lesenswert?

Hallo,

als ziemlicher Computer- und Programmier-Laie habe ich diverse 
GUI-Programmieroberflächen ausprobiert.

"Lazarus" ("Delphi"-Nachfolger) gefiel mir am besten:
Open-Source, "Frei" und "Cross-Compiling" für Windows und Linux möglich.

Damit gelangen mir am schnellsten recht ordentliche Ergebnisse.

A. Geigenberger

(Falls es jemand interessiert: Google: " MyMemoryDB ")

von Christian B. (casandro) Flattr this


Lesenswert?

Ich hab ja bis vor kurzem in einer Firma gearbeitet in der ich ein 
kleines Softwareprojekt in Lazarus gemacht habe. Man merkt, dass die 
Kunden genau von den Sachen begeistert sind, die von Lazarus her rühren.

Zum Beispiel haben wir da statisch gelinkte Programme. Sprich man hat 
unter Windows eine .exe-Datei und führt die einfach aus. Man muss keine 
.net-Umgebung oder so was nachinstallieren, sondern es geht einfach. Die 
x86-Linux, die Win32 und die MacOSX-Version laufen alle ohne 
Installation und sehen jeweils nativ aus, ohne dass man da groß Code 
ändern hätte müssen. Ach ja und die Windowsversion läuft ab Windows 
2000, unter Win98 läuft die leider nicht mehr, wir haben da nicht groß 
nachgeforscht warum das so ist.

Die Kunden wollen keine große Installationsorgie machen um eine 
Laufzeitumgebung zu installieren. Die wollen einfach nur das Programm 
ausführen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.