Ist C# so gut?
-
In Foren mit mehr c#- oder Java-Usern wirst du vermutlich mehr Kritik an C# lesen.
-
SideWinder schrieb:
Die Sprache, ganz ohne Framework und Rundherum, ist wirklich die schönste Mainstream-Sprache die mir jemals untergekommen ist. [...] im Rahmen meines persönlichen Programmierstils so aussagekräftig und selbsterklärend wie noch nie zu programmieren.
Schonmal Haskell probiert?
-
ipsec schrieb:
SideWinder schrieb:
Die Sprache, ganz ohne Framework und Rundherum, ist wirklich die schönste Mainstream-Sprache die mir jemals untergekommen ist. [...] im Rahmen meines persönlichen Programmierstils so aussagekräftig und selbsterklärend wie noch nie zu programmieren.
Schonmal Haskell probiert?
Deswegen musste ich ja Mainstream einsetzen
Aber selbst damit würde ich bei C# bleiben. Denke wohl zu imperativ + unser Prof hat uns nicht gerade mehr Lust auf die Sprache gemacht 
MfG SideWinder
-
C# ist sicher und effizient und es gibt/gab "normierte updates" (.NET 2.0 -> 4.0).
Was will man mehr wenn man nur ein einfaches schnelles Programm mit einer GUI schreiben will?
-
Ist C# so gut?
Jop, C# ist nahezu perfeckt.
-
Ja ist eine geile Sprache und leidenschaftliche Hasser gibt es relativ wenig
Aber ein wenig meckern sollte erlaubt sein:
1. Generics sind zu schwach, verglichen mit Templates. Auf TMP kann ich verzichten aber wenn man wenigstens zu unterstützende Operatoren der Typparameter in den Constraints angeben könnte, wäre schon einiges gewonnen.
2. Man muss bei der Typdefinition angeben ob man Werte- oder Referenzsemantik haben möchte. Also class vs. struct. Andererseits ist das imo genau einer der Punkte, der die relative Einfachheit von C# gegenüber C++ begründet. Sobald die Semantik auf den Zeitpunkt der Objektkreierung verschoben würde, hätte das wohl eine ganze Reihe von fehleranfälligen Spracherweiterungen zur Folge. Evtl. müsste man sich dann Gedanken über Copy-Konstruktoren, Zuweisungsoperatoren u.s.w. machen. Was für Auswüchse das bei der weiteren Sprachentwicklung hat sieht man ja in C++ (RValue-Referenzen, Move-Semantik
). Die Komplexität steigt und steigt ...3. Es gibt zu viele Konzepte der "Gleichheit" von Objekten. Was mir spontan einfällt: ReferenceEquals, Equals, Operator==, IEqualityComparer, IEquatable, IComparer, IComparable ... Was soll das?
Die letzten beiden Punkte hängen eng zusammen und haben mir bei nachträglichen Änderungen schon einiges an Kopfzerbrechen bereitet. Das sind wohl die Punkte, über die ich mich in den letzten Monaten am häufigsten geärgert habe.
-
C# suckt.
Jetzt wo alles gesagt wurde, kann dieser Thread endlich geschlossen werden.
-
obj. Betrachter hat sowas von unrecht das er schon fast wieder recht hat.
-
µ schrieb:
1. Generics sind zu schwach, verglichen mit Templates. Auf TMP kann ich verzichten aber wenn man wenigstens zu unterstützende Operatoren der Typparameter in den Constraints angeben könnte, wäre schon einiges gewonnen.
Grundsätzlich zu deinen Punkten Zustimmung, aber bezogen auf 1.: Kann man nicht eine bestimmtes Interface als Constraint angeben? Das wäre in etwas eingeschränkter Form ja unter C# das übliche um die Operatoren der Typen identisch zu halten (C# hat ja andere Paradigmen als C++, wobei die C++ Templates wohl mit die mächtigsten sind).
-
asc schrieb:
Grundsätzlich zu deinen Punkten Zustimmung, aber bezogen auf 1.: Kann man nicht eine bestimmtes Interface als Constraint angeben?
Ja das geht und ist an anderen Stellen viel wert. Für das genannte Problem ist es aber keine Lösung. Zum einen wäre es mehr als hässlich, auf überladene Operatoren verzichten zu müssen wenn es um mathematische Klassen geht. Statt dessen müssten wir gegen sowas wie IBasicMath mit Methoden wie Add oder Mul programmieren.
Viel gravierender ist aber, dass die Basistypen (float, double, decimal) kein passendes Interface zur Verfügung stellen. Man ist also nicht einmal in der Lage ein class Complex<T> oder class Vector<T> zu entwickeln und sie mit den Basistypen zu instanziieren.
-
Generics habe ich bis jetzt noch nicht oft genug benutzt aber ich stimme dir besonders in Punkt 3 zu.
-
C# erfordert .Net und packt eine weitere Ebene zwischen Betriebssystem und Anwendung für z.B. Typen. Macht durchaus Sinn, wenn unterschiedliche Platformen oder Compiler unterschiedliche Anzahl Bytes für die Typen bereitstellen. Aber C# bietet noch einiges mehr, nur anders als von C oder C++ gewohnt.
-
berniebutt schrieb:
Macht durchaus Sinn, wenn unterschiedliche Platformen oder Compiler unterschiedliche Anzahl Bytes für die Typen bereitstellen.
Das ist doch wirklich nicht der Grund hinter .NET. Defacto ist das was man unter .NET versteht doch nur die Implementierung von Microsoft unter Windows. Also hat es nichts mit unterschiedlichen Plattformen oder Typgrößen zu tun. Natürlich ist das eigentliche .NET plattformunabhängig und es gibt ja zB Mono. Aber viele der Bibliotheken (zB GUI-Zeugs) sind da ja nicht enthalten und es hinkt in der Entwicklung immer der Microsoft Implementierung hinterher. Die meisten .NET-Programme laufen daher sicher nicht unter Mono.
.NET wurde nicht für Plattformunabhängigkeit entwickelt, sondern einfach als neue Programmierumgebung für Windows. Zum einen weil Microsoft damals Angst vor Java hatte und zum anderen, weil sie einen Nachfolger für das angestaubte MFC brauchten.
-
Ich habe mal gehört das .NET es auch erlaubt die IL Sprache abhängig von der Hardware des PC in echt-zeit zu optimieren. Stimmt das?
-
Patrickssj6 schrieb:
Ich habe mal gehört das .NET es auch erlaubt die IL Sprache abhängig von der Hardware des PC in echt-zeit zu optimieren. Stimmt das?
In der Theorie ja, aber Java könntest auch. Praxis, dunno.
-
Patrickssj6 schrieb:
Ich habe mal gehört das .NET es auch erlaubt die IL Sprache abhängig von der Hardware des PC in echt-zeit zu optimieren. Stimmt das?
Ich glaub du meinst den JIT-Compiler («just in time»). Der IL-Code wird auf der Zielplattform vor der Ausführung in nativen, optimierten Maschinencode übersetzt (ich glaube methodenweise on-demand). Echtzeit ist nicht ganz das richtige Wort dafür.
-
@ rüdiger
Meinetwegen ist das mit .Net und C# alles so und alles nur eine vielleicht unnötige Sache von Microsoft. Wer aber für Windows Phone (die kleinen hübschen Telefone mit Internetzugang) entwickelt, kommt weder um .Net noch um C# herum, weil diese Plattform das verlangt. Gut, der Marktanteil von Windows Phone mag gegenüber Android noch gering sein. Wir werden da aber wohl zunehmend mit leben müssen. Es ist nicht alles nur Marktstrategie, wenn auch vieles so erkennbar ist.
-
berniebutt schrieb:
alles nur eine vielleicht unnötige Sache von Microsoft.
Das sag ich doch gar nicht
-
berniebutt schrieb:
.... Wer aber für Windows Phone (die kleinen hübschen Telefone mit Internetzugang) entwickelt, kommt weder um .Net noch um C# herum, weil diese Plattform das verlangt. Gut, der Marktanteil von Windows Phone mag gegenüber Android noch gering sein. Wir werden da aber wohl zunehmen mit leben müssen. Es ist nicht alles nur Marktstrategie, wenn auch vieles so erkennbar ist.
Sehe ich eher als Vorteil, weil es eine elementare .NET Eigenschaft ist, das du in jeder beliebigen .NET Sprache für diese Plattform programmieren kannst. Das sollte sich auch auf den mobilen Plattformen anwenden lasstn - Also nicht nur C# sondern auch Basic oder C++
Das hast du bei Java auf Android und Objective C *würg* auf Apple z.B. nicht. Und bei letzteren sind das noch die harmlosesten Hürden die es zu überwinden geht, um dort überhaupt was entwickeln zu können
-
Cpp_Junky schrieb:
Das sollte sich auch auf den mobilen Plattformen anwenden lasstn - Also nicht nur C# sondern auch Basic oder C++
Kann man inzwischen C++/CLI auf WP7 nutzen?
IIRC war am Anfang nur C# möglich...