Warum ist hier soooo wenig los?
-
Hallo,
warum ist hier eigentlich so wenig los? Ist die Sprache und Aufbau der Libraries so einfach, dass sich nur so wenig Probleme ergeben oder programmieren echt so wenig Leute C#? Auch wenn die Sprache einige Nachteile hat, könnte ich mir vorstellen das sie trotzdem viele benutzen. Aber das scheint mir hier leider doch nicht so?
-
C++ ist immer noch Standard und wird es auch noch eine ganze Weile lang bleiben...
Bis alle auf C# umgestiegen sind wirst du wohl noch paar Jahre warten müssen
-
Das klingt ja so, als würde C# C++ ablösen?
Nana..., wer sagt denn, dass überhaupt alle c/c++-Programmierer auf C# umsteigen werden und sollten?Schliesslich steht es in den Sternen, ob Microsoft es überhaupt schafft und wirklich will, dass alles nur noch "managed" Net-Code wird. Und für all die Native-Codes, die sich übrigens im NET-Framework dann auch als unmanaged Code widerfinden, ist nach MS's eigener Aussage NUR NOCH "C/C++" die Sprache der Wahl!
Mir fallen viele Beispiele ein, für die man nativen Code benötigt bzw. wo man CLR-Managed Code nicht verwenden kann.
-
C# hat noch viele Probleme. Einerseits beitet dotNET noch nicht die Features an, die versprochen wurden, wie Platform richtige unabhängigkeit (Mono untersützt noch keine Winforms etc.).
Dann fehlt es noch an Standardisierung und guten Informationsquellen sind immer noch selten.
Zusatz Libs sind auch noch nicht so verbreitet.
Viele Leute überlegen wahrscheinlich ob es Sinn macht von Java nach C# umsteigen, wenn man vor ein paar Jahren erst so viel Geld für die Java integration ausgegeben hat.
Und die Leute die kein Interesse an Java haben, kann man wahrscheinlich auch nicht unbedingt mit dotNET locken.
Naja und Bill Gates selber musste gestehen, dass dotNET zZ. noch nicht Fussgefasst hat.
-
Original erstellt von kingruedi:
**C# hat noch viele Probleme. Einerseits beitet dotNET noch nicht die Features an, die versprochen wurden, wie Platform richtige unabhängigkeit (Mono untersützt noch keine Winforms etc.).
**Ich glaub es ist auch die Unsicherheit ob es überhaupt jemals zu der erhoften Unabhängigkeit kommen wird.
Will MS in dem Bereich räubern wo heute schon J2EE etabliert ist braucht es mehr als eine kommerzielle Plattform die auf Win-Servern läuft.
Zwar gibt es Open-Source Projekte die .NET, mehr oder weniger, auf *nix-Systemen portieren, aber man solte nicht unterschätzen das sich Entscheider erst wohl fühlen wenn sie einige tausend Euro für eine Plattform bezahlen und bei Bedarf ein paar Herren in Nadelstreifen auf der Matte stehen und für die Software gradestehen, zumal es hier um Produktivsysteme geht.
Vielleicht braucht es auch einfach sowas wie ein Community Process, wie es bei Java oder J2EE der Fall ist, wo alle wichtigen Firmen oder auch Open-Source Organisationen sich an den kommenden Spezifikationen beteiligen. Das Vertrauen in einer Technologie die nur von einer Firma vorangetrieben wird und sie zudem den Namen Microsoft trägt läßt sich nicht so einfach erkaufen.
Den Einsatz einer Technologie wie .NET die schwerpunktmäßig für den Einsatz als Serversystem konzipiert wurde mit der Bedingung eines Win-OS zu verknüpfen behindert die Verbreitung. Sollte sich daran nix änderen (was den Anschein hat) wird das ganze System auf "just another Visual Basic" hinauslaufen.
O'Dog
-
Hi,
also ich möchte für professionelle Seite sprechen:
Die meisten Unternehmen haben noch nicht auf .NET umgestellt weil:
- Die Plattform vom Funktionsumfang noch nicht ganz ausgereift ist.
- Ebenso wie die Plattformunabhängigkeit, so dass Java weiterhin vorzuziehen ist.
- Die Umstrukturierung im Betrieb ist mit Kosten und Zeit verbunden, die die Mitarbeiter erst einmal zu ihren Tagesgeschäft aufbingen müssen.
- Die Alternativen zu einzelen Funktionen von .Net wie
a)f. ASP.net wie PHP, Perl, JSP etc
b)f. VB.net wie Delphi, Krylix u.a.
c)f. C++.net wie C++
d)f. C# wie C++, Java und VB
e)f. ADO.net klassische Remote-Prozesse und Komponeten-Architektur wir COM+,CORBA,RMI,EJB etc
f)f.XML und SOAP ist ehe standardisiert auch in anderen Frameworks.
...
rechtfertigen eine Umstellung nicht.D.h. es gibt noch kein zwingenden Grund auf .NET umzusteigen, außer der Kunde verlangt es, und 1,5 -3,5 k€ p.Ap. für eine IDE-Lizenz auzugeben.
Wir haben Zeit ...
cu
P84
-
Ich verstehe nicht, was man dafür umstellen muss, um .NET zu nutzen. Man installiert sich einfach das .NET-Framework, fertig!
Um Java zu nutzen muss ich ja auch nicht gleich MS Office unter Java haben...?naja, jetzt sollte man aber auch nicht zu stark daran zweifeln, ob sich .NET durchsetzt (auch wenn ich kein Freund davon bin - windows sucks
ABER:
Wenn man mal von der "Platform(un)abhängigkeit" absieht, gibt es auch genügend Gründe, die dafür sprechen, dass sich dotNET durchsetzt:1. Irgendwann gehört es eh zu Windows dazu
2. Die Vorteil für Entwickler-Firmen liegt darin, mehrere Sprachen auf einfachste Weise zu koppeln, nix mehr mit Problemen, dass ein VB-Programm eine C++ Klasse nicht ansprechen kann, ohne dass der C++-Code kompliziert in ein COM-Objekt verpackt wird, etc.
Also einfachste Integration verschiedener Sprachen, was wohl auch das wichtigste Merkmal ist.
3. Alle neuen M$-Compiler, ob VisualFox, VisualBasic, VisualC++, ... werden in Zukunft NUR NOCH dotNET Code erzeugen, mit der Ausnahme von VC++, welcher auch weiterhin noch nativen Code erzeugen können soll.Ich denke mal, dass das die wichtigsten Grüde sind, die dafür sprechen, dass sich .NET leider doch durchsetzen wird, zumindestens unter Windows zum Quasi-Standard wird.
Spricht was dagegen? Wenn ja, bitte Posten, bin immer auf der Suche nach Argumenten gegen .NET
-
Original erstellt von wischmop2:
Ich verstehe nicht, was man dafür umstellen muss, um .NET zu nutzen. Man installiert sich einfach das .NET-Framework, fertig!Ach ,das ist ja leicht. Wenn man das Teil also installiert beherschen gleich alle Mitarbeiter die Technologie und laufende bzw. besthende Projekte werden sozusagen automatisch migriert!?
Original erstellt von wischmop2:
1. Irgendwann gehört es eh zu Windows dazu
[/QB]Na ja, das kann man vielleicht so sehen wenn man davon ausgeht das das .NET-Framework zum zusammenklicken von GUI/Client-Anwendungen entwickelt wurde. MS wollte IMHO eher auch ein Stück von dem lukrativen Markt der App-Server (J2EE) abhaben. Ein Markt der viele Jahre lang von MS ignoriert wurde und andere Firmen wie IBM, Bea oder Oracle Geld geschaufelt haben. Und meines wissen ist das .NET-Framework weder auf SUN noch auf irgendwelche IBM-Kisten vorinstalliert noch läßt es sich da installieren. Wäre ja schade wenn so ein großes Framwork nur zum bauen von GUIs entwickelt worden wäre, sicher nicht im Sinne des Erfinders.
Original erstellt von wischmop2:
2. Die Vorteil für Entwickler-Firmen liegt darin, mehrere Sprachen auf einfachste Weise zu koppeln, nix mehr mit Problemen, dass ein VB-Programm eine C++ Klasse nicht ansprechen kann, ohne dass der C++-Code kompliziert in ein COM-Objekt verpackt wird, etc.
Also einfachste Integration verschiedener Sprachen, was wohl auch das wichtigste Merkmal ist.
[/QB]Also realistisch gesehen muß man sagen das C# die Standardsprache von .NET sein wird. Das man bei einem Projekt jeden Entwickler überlässt sich 'ne Sprache auszusuchen und die ganze Suppe dann zu einem Projekt zusammenfasst ist unwahrscheinlich (Wartung). Der Vorteil der "Sprachenunabhängigkeit" ist völlig überbewertet. Jahrelange VB-Entwickler versuchens eher mit C# da VB.NET sich dermaßen geändert hat das man gleich zu C# wechseln kann, was C++-Entwickler von Managed C++ halten kannst'e ja bei 'Rund um die Programmierung' nachfragen.
Original erstellt von wischmop2:
3. Alle neuen M$-Compiler, ob VisualFox, VisualBasic, VisualC++, ... werden in Zukunft NUR NOCH dotNET Code erzeugen, mit der Ausnahme von VC++, welcher auch weiterhin noch nativen Code erzeugen können soll.
[/QB]Scheint mir ja sehr MS-lastig, da hätte'se ja zumindest noch Borland erwähnen können
Original erstellt von wischmop2:
...zumindestens unter Windows zum Quasi-Standard wird.
...Spricht was dagegen?
[/QB]Eben, wie du bereits sagtes: unter Win.
bis dänn,O'Dog
-
@O'Dog: Ich kann Dir zwar in dem Punkt zustimmen, dass Microsoft das NET-Framework sicherlich auch für den Markt der App-Server entwickelt hat, aber sicherlich nicht aussliesslich. Dann hätte demnach Sun und eben nicht Bea etc. das meiste Geld darin verdienen müssen - ist aber nicht so.
Und was dann noch übrig bleibt, ist u.a. das migrieren verschiedener Sprachen. Wozu gibt es denn COM? IMHO dazu, dass meherere Programme (vobei hier die Sprache ja unabhängig ist)
1. Daten austauschen können
2. sich gegenseitig aufrufen können. (und halt auch nicht nur für GUI's )
Schliesslich gibt es bestimmt auch DCOM deshalb, weil MS auch hier sein eigenes Süppchen kochen und beherrschen wollte und sich keinen Standard wie CORBA von anderen vorschreiben lassen will!Warum will Mircosoft jetzt COM/DCOM mit NET abschaffen? Ich denke mal, weil das doch nicht ein zu vernachlässigbares Merkmal von .Net ist. Und gerade dafür ist doch MS auch bekannt, alles so einfach wie möglich halten und .NET kann einem in dieser Hinsicht das Leben wirklich einfacher machen. Schon mal probiert ein Java-Programm mit einem C++-Programm zu kombinieren (ich meine dabei nicht nur ein paar native-methods zu integrieren)? Ich hab's schon öfters gemacht, geht recht umständlich, wobei ich das Konzept dabei trotzdem sauberer finde. Aber nichts desto trotz "soll man angeblich" bei .NET die verschiedenen Programmstrücke der verschiedensten Sprachen einfach gegeneinander Linken können.
Was ich damit nur sagen wollte, die Welt besteht für's .NET Frameform bestimmt zu einem gewissen Teil aus AppServern, aber auch nur zum Teil und ist nicht ausschliesslich dafür geschaffen worden .
Unterm Strich gibt es eben die EINEN, die vielleicht mal (hoffentlich nie
) .NET-Komponenten auf ihren "BEA für dotNET" - Servern warten müssen (und dort sind Investitionen nötig, Schulungen, etc.)
aber auch die ANDEREN :p , die einfach nur weiterhin Programme benutzen, und das sind deutlich mehr. Ob das Programm nun unter der CLR läuft oder nicht, das weiss der Benutzer nicht und dafür muss er auch nicht geschult werden.
Ist halt wie bei Java, es gibt "Java 2 Standard Edition" (und da ziehe ich eben meinen Vergleich her) und Java 2 Enterprise Edition (und da siehst Du wohl den Grund, dass MS ein eigenes "Java" entwickelt hat, wenn ich Dich richtig verstanden habe).Im übrigen gibt es noch andere Märkte, die jetzt gerade erst wachsten und wo MS auch .NET sieht, als da wäre mobile entertainment (multimedia handys und so...). Auch wenn sich da Java mit der KJM schon einiger massen etabliert hat, darf man hier gespannt sein, ob es MS nicht schafft den Spiess dort umzudrehen. Ich bin davon überzeugt, dass sich in naher Zukunft die integrierten PDA's mit Handy immer mehr durchsetzen. Und auf diesen Geräten wird sich dann (wieder meine Meinung
) das sog. Mobile Entertainment abspielen. Und zur Zeit setzen sich aber bei diesen Geräten die Windows CE getriebenen durch... Naja und dann 1+1 = ?
Aber ist halt nur meine ganz persönliche Zukunftsprognose!
-
Original erstellt von wischmop2:
Schon mal probiert ein Java-Programm mit einem C++-Programm zu kombinieren (ich meine dabei nicht nur ein paar native-methods zu integrieren)?Schon mal probiert ein C++ Programm mit einem .NET Programm zu kombinieren?
Ich nicht, ich habs auch nicht vor, aber jetzt sag mal, was daran soviel einfacher sein soll als Java und C++!
Achja: Managed C++ != C++
Managed C++, VB.NET, etc sind ja keine ernst zu nehmenden Sprachen. .NET Programmiert man mit C#!
-
Original erstellt von Shade Of Mine:
**Schon mal probiert ein C++ Programm mit einem .NET Programm zu kombinieren?
**Hmmm, damit hast Du vielleicht den Nagel auf den Kopf getroffen! Genau dieses Problem habe ich momentan, siehe [url] NET-Komponenten in native Programme einbinden [/url].
**... Ich nicht, ich habs auch nicht vor, aber jetzt sag mal, was daran soviel einfacher sein soll als Java und C++!
Achja: Managed C++ != C++
Managed C++, VB.NET, etc sind ja keine ernst zu nehmenden Sprachen. .NET Programmiert man mit C#!**Ok, Managed C++ (heisst das so?) ist nicht C++. Und da liegt vielleicht auch schon die "Lösung" drin!
(Vorweg: all das habe ich noch nicht selber ausbrobiert, aber so soll es angeblich gehen...)
Man kann in VC++ dieses Managed und Unmanged C++ kombinieren. Wenn man eine Managed-C++ KLasse programmiert, dann soll man diese Klasse auch direkt in z.B. C# verwenden können. Ob das auch für Unmanged C++ gilt (also echtes C++) weiss ich nicht, wenn nicht wäre dieses Managed C++ als Wrapper nützlich, in dem man evtl. einfach ohne weitere Implementierung von der echten C++ Klasse ableitet.So, oder so ähnlich soll es wohl gehen. In 3-4 Wochen werde ich mich damit beschäftigen müssen, dann kann ich mehr dazu sagen.
Momentan haben wir nämlich in unserer Firma das Problem, dass wir mit einer anderen Firma fusionieren. Dazu sollen auch 2 Programme nun zu einem gemacht werden. Das Problem: Unseres ist in C++ (speziell Borland C++ Builder), das von denen ist in APL programmiert. Wir müssen auf Programmteile von denen zurückgreifen, die auf unsere. Unseren Code können wir zwar auch als DLL zur Verfügung stellen, die ihren aber nicht, die können nicht mal eine Adresse einer ihrer Funktionen bestimmen, ist halt APL, ne interpretierte Sprache.
Und deren Vorschlag war, dass wir gemeinsam auf NET umsteigen. Die können wohl in NET-Code übersetzen... Naja, und dann soll das angeblich wie oben beschrieben funktionieren.Finde ich zwar voll "ätzend", aber wenn's wirklich damit "so einfach" funktioniert (bin aber auch noch etwas Skeptisch), dann hat für mich .NET schon einen gewaltigen Pluspunkt. Zumindestens finde ich dann das Konzept "theoretisch" genial (nein, ich hasse M$ trotzdem
). Das man dafür gleich alles nach .NET portieren muss und evtl. auf solche Ömmelsprachen wir ManagedC++ als Hilfsmittel zurückgreifen muss, gefällt mir nicht.
Deshalb wäre mir ein externes Einbinden von NET-Programmen durch ein instantiieren einer CLR schon deutlich lieber. Aber wie schon gesagt, in 3-4 Wochen muss ich mich wahrscheinlich damit beschäftigen
, momentan suche ich nach Argumenten, mit denen ich den restlichen Entwicklern dieses Vorgehen ausreden kann bzw. die mich auch davon überzeugen, dass der Weg völlig falsch ist.So, aber nun ist hier doch gar nicht mehr soooo wenig los, oder
(auch wenn's inzwischen in "Rund um die Programmierung gehört")
-
Original erstellt von wischmop2:
Man kann in VC++ dieses Managed und Unmanged C++ kombinieren. Wenn man eine Managed-C++ KLasse programmiert, dann soll man diese Klasse auch direkt in z.B. C# verwenden können.Das wage ich zu bezweifeln. Denn dann koennte diese Klasse ja ein template sein. Und damit ist es nicht mehr .NET kompatibel. Oder man koennte in dem Unmanaged C++ andere Grenzen von .NET ueberschreiten... Auf jedenfall duerfte Unmanaged C++ Code nicht .NET kompatibel sein.
-
@wischmop2
Tja, ich würde jetzt sagen:
Deine bisherige Argumentationskette war ein Knieschuss ...
-
Original erstellt von wischmop2:
**@O'Dog: Ich kann Dir zwar in dem Punkt zustimmen, dass Microsoft das NET-Framework sicherlich auch für den Markt der App-Server entwickelt hat, aber sicherlich nicht aussliesslich. Dann hätte demnach Sun und eben nicht Bea etc. das meiste Geld darin verdienen müssen - ist aber nicht so.
**Na ja, SUN verkauft natürlich auch seine J2EE-Produkte (iPlanet-Server). Das Problem ist das sämtliche Spezifikationen seien es APIs für J2EE oder J2SE offen sind, d.h. das jeder Hersteller der diese Umsetzen will das auch tun kann.
Etwas zu spezifizieren und etwas zu implementieren sind zwei paar Schuhe wie wohl SUN erfahren musste. So sind die Lösungen von IBM und Bea in dem Bereich Marktführer.
Andererseits würde SUN ohne dieses Vorgehen keine industrieweite Unterstützung für die Java-Technologie haben, so wird auch der ganze Prozess der Spezifikation nicht allein von SUN getragen sondern im sogenannten Community Prozess entwickelt, wodran sich viele Firmen und Organisationen beteiligen.
Das .NET-Framework ist nur teilweise offengelegt und ist zudem mit Patenten überhäuft was es für andere Unternehmen nicht sehr attraktiv
macht. Siehe auch:http://www.microsoft.com/germany/ms/windowsnetserver/
Wie Ballmer doch sagte:
"Das größte Wachstumspotenzial liegt nach Ballmers Einschätzung im Serverbereich. .NET, die neue Microsoft-Plattform für XML-Webdienste, die Informationen, Geräte und Anwender in einer einheitlichen und personalisierten Weise miteinander verbindet, beschreibt der Microsoft-Chef als Seele der derzeitigen Geschäftsaktivitäten"MS hat mitlerweile auch das Internet entdeckt
und sieht für die nächsten Jahre eine vernetzte Welt mit einem .NET-Server als Mittelpunkt der zukünftigen Entwicklung. Alles drumherum seien es Mobile-Anwendungen oder andersartige Client bauen darauf auf.O'Dog
-
Ach so, fast vergessen
Original erstellt von wischmop2:
**Naja und dann 1+1 = ?
**2
O'Dog
-
Original erstellt von wischmop2:
Man kann in VC++ dieses Managed und Unmanged C++ kombinieren. Wenn man eine Managed-C++ KLasse programmiert, dann soll man diese Klasse auch direkt in z.B. C# verwenden können. Ob das auch für Unmanged C++ gilt (also echtes C++) weiss ich nicht, wenn nicht wäre dieses Managed C++ als Wrapper nützlich, in dem man evtl. einfach ohne weitere Implementierung von der echten C++ Klasse ableitet.Da sieht man ja wie leicht das geht
dotNET hat zu viele Fehler und mängel. Vieles existiert/funktioniert nut auf den lustigen Werbezetteln von Microsoft.
dotNET not yet
-
Hab mich nun mal ein wenig mehr in die Praxis von dotNET eingelesen. Wie's aussieht scheint das wohl doch nicht so einfach zu gehen, managed und unmanaged code zu vermischen, es hat mich zu beginn immer iritiert, dass die Beispiele die Endung "cpp" hatten, obwohl es dann doch Managed C++ war!
Zumindest demnach, was ich recherschiert habe, benötigt man dafür ähnliche Mechanismen, wie auch bei JAVA, nur das es sich hierbei um den bereits schon bekannten Ansatz von COM-Objekten handelt. Um Managed Code von einem Unmanaged Code aufzurufen, muss man wohl die mscoree.dll laden, in dieser dann mit der Funktion DllGetClassObject sich eine Referenz auf das Objekt geben lassen, etc.Also doch nicht so einfach mit dem Kombinieren! Ich hab's nur so gehört und das wurde mir auch so als das revolutionäre an dotNET verkauft. Nun bin ich ja froh, dass es wirklich "nix anderes" wie Java ist.
Also: Wenn's sich nicht so einfach kombinieren lässt, und danach sieht es ja aus, dann nehme ich alles zurück und schliesse mich der allgemeinen Meinung an: ".NET ist Sch***** !"
-
Original erstellt von wischmop2:
dann nehme ich alles zurück und schliesse mich der allgemeinen Meinung an: ".NET ist Sch*** !"**Ne, also das wuerde ich nicht sagen. Ich bin da eher Kingruedis Meinung: .NET ist noch nicht reif!
-
dotNET hat zu viele Fehler und mängel. Vieles existiert/funktioniert nut auf den lustigen Werbezetteln von Microsoft.
z.B ?
[ Dieser Beitrag wurde am 05.08.2002 um 10:56 Uhr von CMatt editiert. ]
-
- Portabilität
- Standardisierung
- Verbreitung/Popularität
- Sprach übergreifend (okay das funktioniert, aber auch nur mit anderen dotNET sprache, aber bald sollen ja COBOL usw. Compiler hinzukommen, mal schauen ob das auch krüppel Versionen der standardisierten Sprache sind)