java vs .NET (ernsthaft) ;-)

[Shade Of Mine]

kingruedi schrieb:

Im Endeffekt ist das sicher nicht so ein Killer Feature.

Ich sehe den Vorteil darin, dass man einen größeren Technologiekreis unterstützt. Denn mit .NET macht man bald mal etwas. und sei es nur die Delphi Anwendung nach Delphi.NET zu portieren - und schwupps schon hat man zugang zu dieser Technologie.

Das ist denke ich bei der Migration nach .NET auf jedenfall sehr sehr wertvoll.

Allerdings denke ich, wenn Plattformunabhängigkeit einmal wichtig werden könnte, ist Java klar im Vorteil. Die Frage ist halt: wie wichtig ist die Windows integration zB per COM? Denn da hat .NET logischerweise die Nase sehr weit vorne.

MONO muss sich IMHO auch erstmal beweisen, momentan ist es nur eine spielerei - aber vielleicht wird ja etwas daraus. meinen business plan würde ich darauf aber nicht aufbauen

Die Frage die sich stellt ist also IMHO:
Was ist wichtiger? Windows Integration oder potentielle Plattformunabhängigkeit?

Der Know-How Vorteil in Java ist eher gering, weil C# ja nun wirklich nicht viel anders als Java ist. Auf ASP.NET würde ich aber eher nicht umsteigen.

[kartoffelsack]

Der Know-How Vorteil in Java ist eher gering, weil C# ja nun wirklich nicht viel anders als Java ist. Auf ASP.NET würde ich aber eher nicht umsteigen.

was ist das Problem mit ASP.NET? Bzw. heißt dass dass Du .NET für Web-Technologie ablehnst? Warum?

@jkbjkbjkb Dass es auch andere Sprachen für die jvm gibt, ist schon klar. Nur: welche davon sind so ausgereift, dass man wirklich im professionellen Umfeld einsetzen kann.

[Shade Of Mine]

kartoffelsack schrieb:

was ist das Problem mit ASP.NET? Bzw. heißt dass dass Du .NET für Web-Technologie ablehnst? Warum?

Naja, man bindet sich an windows server

aber ich denke eher so: ihr habt schon viel mit Java gemacht - welchen vorteil hätte hier der Umstieg auf .NET? da man sowieso kaum direkt zwischen web und standalone anwendung kommuniziert (da man ja meistens über ein protokoll, HTTP, SAOP, etc kommuniziert) sehe ich hier keinen großen vorteil.

Subjektiv: Java im Web und für Intranet Lösungen wirkt auf mich eine Macht, da muss ASP.NET erstmal zeigen was es wirklich kann. da man stark eingeschränkt ist mit der verfügbarkeit von windows servern sehe ich nicht so den markt. (im vergleich zu java)

[Gast]

Shade Of Mine schrieb:

Ich sehe den Vorteil darin, dass man einen größeren Technologiekreis unterstützt. Denn mit .NET macht man bald mal etwas. und sei es nur die Delphi Anwendung nach Delphi.NET zu portieren - und schwupps schon hat man zugang zu dieser Technologie.

Das ist denke ich bei der Migration nach .NET auf jedenfall sehr sehr wertvoll.

Ich sehe das mit gemischten Gefühlen. Es sind durchaus einige Einschränkungen vorhanden, die in den einzelnen Sprachen/Sprachmitteln gemacht wurden, damit sie alle auf .Net laufen.

Beispielsweise gibt es keine Referenzen der Form List<? extends Foo>, wahrscheinlich, weil man das einem Visual Basic Programmierer einfach nicht zumuten kann.
Dann darfst du (auch in C# und C++ nicht) zwei Methoden

void foo();
void Foo();

haben, denn das ist nicht mehr CLS-Compliant. Natürlich kannst es machen, aber dann ist die Sprachunabhängigkeit hin.

Dann musst du für IEnumerable<T> auch IEnumerable implementieren, damit auch Programmiersprachen ohne Generics die Elemente deiner Collection aufzählen können. Du musst:

IEnumerable<T> : IEnumerable

Das sieht dann, wenn dich die anderen Sprachen nicht scheren, hässlich aus:

/// <summary>
		/// Erlaubt das sequentielle durchiterieren durch die Liste.
		/// </summary>
		public IEnumerator<NavNode> GetEnumerator()
		{
			return list.GetEnumerator();
		}

		// TODO: Microsoft sollte das fixen!
		System.Collections.IEnumerator
			System.Collections.IEnumerable.GetEnumerator()
		{return null;}

Damit könnte ich endlos weitermachen. Ich war anfangs begeistert von der Idee, aber inzwischen sehe ich in der Sprachunabhängigkeit zuviele Nachteile.

btw. finde ich schon, dass C# ziemlich anders ist als Java. Die Ähnlichkeiten springen jemanden natürlich ins Auge, wenn man von C++ kommt, aber wenn man mit beiden Sprachen mehr gearbeitet hat, entwickelt man für beide irgendwie schon ne eigene Vorgehensweise. Zumindest für mich kann ich mal sprechen.

[C#-Fan]

Optimizer schrieb:

void foo();
void Foo();

haben, denn das ist nicht mehr CLS-Compliant. Natürlich kannst es machen, aber dann ist die Sprachunabhängigkeit hin.

Gibt doch Mittel und Wege sicher zu stellen, dass
die Assembly in keiner einzigen Sprache Probleme
macht.

[assembly: CLSCompliant(true)]

// ...

// 1 Fehler:
// Identifier 'Xxx.foo()' differing only in case is not CLS-compliant

Beziehungsweise solange Foo nicht public ist,
ist es sowieso egal.

Optimizer schrieb:

Das sieht dann, wenn dich die anderen Sprachen nicht scheren, hässlich aus:

/// <summary>
        /// Erlaubt das sequentielle durchiterieren durch die Liste.
        /// </summary>
        public IEnumerator<NavNode> GetEnumerator()
        {
            return list.GetEnumerator();
        }

        // TODO: Microsoft sollte das fixen!
        System.Collections.IEnumerator
            System.Collections.IEnumerable.GetEnumerator()
        {return null;}

1. Kann man die explizite Implementierung von IEnumerable weglassen,
   IEnumerable<T> implementiert ja IEnumerable ..
2. Sind dann bei deinem Beispiel sowieso wieder die Leute angeschmiert, die
   eine Dreckssprache verwenden. Warum willst es denn nicht über IEnumerable
   zugänglich machen ?

[jkbjkbjkb]

kartoffelsack schrieb:

@jkbjkbjkb Dass es auch andere Sprachen für die jvm gibt, ist schon klar. Nur: welche davon sind so ausgereift, dass man wirklich im professionellen Umfeld einsetzen kann.

Sicherlich sind da viele Sprachen dabei, die man als Experimente werten kann. Aber es sind auch diverse ernstzunehmende und ausgereifte Sprechen dabei. Schau dir zum Beispiel Groovy an. Das ist eine Sprache, die von Sun kommt, um einen bestimmten Zweck für die Java Plattform zu erfüllen. Diese Sprache hat sicherlich einen Nutzen. Ansonsten habe ich zugegebenermaßen keine Erfahrung mit den dort aufgelisteten Sprachen, aber man sollte zumindest, wenn man mal ein anderes Programmierparadigma benötigt, die entsprechenden Implementationen von meinetwegen Lisp oder Prolog für die Java Plattform evaluieren, bevor man die Plattform grundsätzlich ablehnt.

[Gast]

C#-Fan schrieb:

Gibt doch Mittel und Wege sicher zu stellen, dass
die Assembly in keiner einzigen Sprache Probleme
macht.

Das ist nicht falsch, war aber auch überhaupt nicht der Punkt. Es ist ne Einschränkung, die man mit Standard C++ nicht hat. Oder C#. Oder Java. Oder J#. Und sie kommt mit der angestrebten Sprachunabhängigkeit. Das war der Punkt.

Kann man die explizite Implementierung von IEnumerable weglassen,
IEnumerable<T> implementiert ja IEnumerable ..

Nein, kannst du nicht. IEnumerable<T> kann auch schlecht was implementieren, es ist ja selber nur ein Interface. Du musst beide Methoden und Enumeratoren, generisch und nicht-generisch implementieren. Und weil die Methoden sich auch nur anhand des Rückgabetyps unterscheiden, musst du auch noch den Namen mit dem Interface voll qualifizieren. Ich glaub, schöner als oben kann man es nicht machen.

Sind dann bei deinem Beispiel sowieso wieder die Leute angeschmiert, die
eine Dreckssprache verwenden. Warum willst es denn nicht über IEnumerable
zugänglich machen ?

Weiß nicht was für dich jetzt ne "Dreckssprache" ist. Wenn du nicht grad wie ich return null machst sondern eben nen gescheiten Enumerator, funktioniert das in jeder Sprache. Warum ich nicht IEnumerable verwende? Weil ich mit den Generics arbeiten will natürlich... und werd von dem CLS-Müll dazu gezwungen, es auch nicht-generisch aufzählbar zu machen, selbst wenn es mir egal wäre, ob man das Teil in VB nutzen kann.

[;-)]

@kartoffelsack: Wollt ihr später auch Anwendugen im Browser laufen lassen, oder über RMI/WebServices verfügbar machen? Wenn ja, dann ganz klar Java.

Möchtest ihr Eure Anwendungen nur unter Windows Clients laufen lassen, dann seit wahrscheinlich mit C# besser bedient.

Wollt ihr plattformunabhängiger sein, dann müsst ihr sowieso große Teile neu schreiben. Dann bietet sich natürlich Java an. Ich würde heute nicht mehr einfach nur die Augen zu drücken. Mac ist wieder stark im kommen.

kartoffelsack schrieb:

Wir möchten bestehende Komponenten nicht grundlos auf die neue Platform portieren. D.h. die bestehenden Programme bleiben, wie sie jetzt sind. Neue werden jedoch mit der entsprechenden neuen Technologie entwickelt. Bei größeren Weiterentwicklungen muss jeweils entschieden werden, ob portiert werden soll.

Was spricht eigentlich gegen C++ mit Qt, wx, GTK?

[C#-Fan]

Optimizer schrieb:

Nein, kannst du nicht. IEnumerable<T> kann auch schlecht was implementieren, es ist ja selber nur ein Interface. Du musst beide Methoden und Enumeratoren, generisch und nicht-generisch implementieren. Und weil die Methoden sich auch nur anhand des Rückgabetyps unterscheiden, musst du auch noch den Namen mit dem Interface voll qualifizieren. Ich glaub, schöner als oben kann man es nicht machen.

Gut, also ich sag mal rein "technisch", hast du recht. Hab mich im
vorigen Posting geirrt. Allerdings hab ich auch grad gesehen, dass
IEnumerable<T> nicht auch IEnumerable erweitert (zumindestens laut
MSDN-Doku). Du kannst also die nicht generische Scheiße auch gerne
ignorieren ..

Optimizer schrieb:

Weiß nicht was für dich jetzt ne "Dreckssprache" ist.

Naja, ich wusste nicht welche Sprache jetzt konkret Generics nicht anbietet,
darum hab ich jetzt einfach den Oberbegriff "Dreckssprache" eingeführt, die
ein Element der Menge nicht generischer Sprachen darstellen soll

Optimizer schrieb:

Wenn du nicht grad wie ich return null machst sondern eben nen gescheiten Enumerator, funktioniert das in jeder Sprache. Warum ich nicht IEnumerable verwende? Weil ich mit den Generics arbeiten will natürlich... und werd von dem CLS-Müll dazu gezwungen, es auch nicht-generisch aufzählbar zu machen, selbst wenn es mir egal wäre, ob man das Teil in VB nutzen kann.

Warum du nicht IEnumerable verwendest ist klar, ich meinte eh, die Leute
die IEnumerable verwenden müssen (weil sie ne Dreckssprache benutzen)
beissen sich ziemlich in den Hintern, da sie nicht über deine Collection
iterieren können.

Aber is eh egal, das artet sonst noch zu OT aus, im
Zweifelsfall hast halt du gewonnen, egal ob du überhaupt
gewinnen willst :p

[Gast]

C#-Fan schrieb:

Allerdings hab ich auch grad gesehen, dass
IEnumerable<T> nicht auch IEnumerable erweitert (zumindestens laut
MSDN-Doku). Du kannst also die nicht generische Scheiße auch gerne
ignorieren ..

Das wurde geändert, die Doku ist wohl nicht aktuell. Ich hab ne Version vom Februar und es ist seit Oktober leider so.

Weiß nicht was für dich jetzt ne "Dreckssprache" ist.Naja, ich wusste nicht welche Sprache jetzt konkret Generics nicht anbietet,
darum hab ich jetzt einfach den Oberbegriff "Dreckssprache" eingeführt, die
ein Element der Menge nicht generischer Sprachen darstellen soll

rofl.

Optimizer schrieb:

Warum du nicht IEnumerable verwendest ist klar, ich meinte eh, die Leute
die IEnumerable verwenden müssen (weil sie ne Dreckssprache benutzen)
beissen sich ziemlich in den Hintern, da sie nicht über deine Collection
iterieren können.

Aber is eh egal, das artet sonst noch zu OT aus, im
Zweifelsfall hast halt du gewonnen, egal ob du überhaupt
gewinnen willst :p

Naja durch die Vererbung ist eben das Problem gegeben, dass ich nicht einfach sagen kann "mich interessiert nur der generische Teil". Das wär ok. Aber du hast es ja gerade erst anders (veraltet) gelesen, deshalb ist das jetzt wahrscheinlich schon klar.
Ob's was zum Gewinnen gibt, weiß ich nicht.

[BloodLord]

Nun ja, schließlich wollte Microsoft mit .NET (und vor allem C#) Java Konkurrenz machen. Ich denke, beide Technologien haben ihre Vor- und Nachteile. Java ist gut um GUIs zu programmieren, die auf jedem System laufen - mit .NET habe ich nicht wirklich Erfahrung ;), aber da die Technologie immer stärker in Windows implementiert wird, ist sie wohl besser dafür.

Ich denke Microsoft will Java mit .NET stärker aus Windows verdrängen.

[;-)]

BloodLord schrieb:

Java ist gut um GUIs zu programmieren,

Java ist vor allem für Enterprise Anwendungen ideal.

[C#-Fan]

Shade Of Mine schrieb:

kartoffelsack schrieb:

was ist das Problem mit ASP.NET? Bzw. heißt dass dass Du .NET für Web-Technologie ablehnst? Warum?

Naja, man bindet sich an windows server

Soweit ich weiß funktioniert ASP.NET aber auch mit einem Apache Server
und mod_mono. Ausprobiert hab ichs selbst aber nicht.

Zur Zeit ist die Verwendung des .NET Frameworks für mich eher ne Glaubensfrage.
Ich glaube dran, dass Bill Gates mal den richtigen Fingerschnipp macht und
.NET so richtig aus dem Zaun lässt. Sprich alles standardisiert, und somit
der Plattformunabhängigkeit den Weg geebnet. Für mich persönlich wäre dann die
Entscheidung klar, was aber eher ne subjektive Meinung wär.

[offtopic]
Ich fänds sowieso am besten, wenn ich mit C# programmieren könnte, als
Framework hätte ich ne Art J2EE zur Verfügung. Nur mit dem Unterschied,
dass mal alle veraltete Klassen rausgeworfen werden, im Prinzip halt
simple Aufräumarbeiten, etc ..
[/offtopic]

[oizio]

Optimizer schrieb:

IEnumerable<T> : IEnumerable

Wofür steht da eigentlich das I? Soll das anzeigen, dass es sich um ein Interface handelt? Geht das also schon wieder in Richtung ungarische Notation oder zumindest in Richtung CMyClass?

[nbxcvmn]

C#-Fan schrieb:

Ich glaube dran, dass Bill Gates mal den richtigen Fingerschnipp macht und
.NET so richtig aus dem Zaun lässt. Sprich alles standardisiert, und somit
der Plattformunabhängigkeit den Weg geebnet.

Wow. Durch was wurde dieser Glaube denn verursacht? Mir erscheint das (sachlich ausgedrückt) erstmal unrealistisch. Darf man da von einer starken ideologischen Prägung deinerseits ausgehen?

[JBeni]

C#-Fan schrieb:

... Nur mit dem Unterschied,
dass mal alle veraltete Klassen rausgeworfen werden...

Und alle paar Monate fragst du dich, wieso deine alten Programme nicht mehr laufen?

P.S. ein Vorteil von Java ist die Rückwärtskompatibilität, zumindest haben die Sun-Leute das jetzt jahrelang durchgezogen, die Chancen, dass sich das plötzlich ändert sind klein (im Gegensatz zu .NET und C#, die von eine [Glaubenskrieg]Standard-boikitierenden Firma[/Glaubenskrieg] kommt. )

[Shade Of Mine]

JBeni schrieb:

P.S. ein Vorteil von Java ist die Rückwärtskompatibilität

Ist aber gleichzeitig eine große schwäche.

[Helium]

ICh finde zwar, das Optimizer einige sinnlose Punkte aufzählt (wie oft hat man bitte 'Foo' und 'foo' in der öffentlichen Schnittstelle?), aber .Net hat auf jeden Fall seine schwächen. Die Generics hätten von Anfang an da sein müssen. Jetzt wird versucht die irgendwie da reinzuwurschteln, was aber nicht immer gelingt. Vor allem gibt es dadurch jetzt vieles unnötigerweise doppelt.

[Gast]

Es muss nicht public sein. Ich könnte ne protected Variable (ja ich weiß, hässlich, böse, lame) haben und dafür noch nen public getter.

abstract class Base
{
    public string Foo    {get{ return foo; }}    

    protected string foo = "oöusgdföklugsa";
}

class Derived : Base
{
    public bool containsCharacter(char x)
    {
        return foo.IndexOf(x) != -1;	// Hmmmm, VB.
    }
}

Für C# wäre dieser Code völlig in Ordnung.

Es ist auch nicht abwegig, Membervariablen und korrespondierende Getter so zu benennen. Ich mache das so. Meine Variablen sind natürlich nicht protected, trotzdem finde ich das Beispiel nicht völlig abwegig (hmmm könnt ja auch ne Methode/Proberty mit Rückgabewert wiederum sein). Wenn man für mehrere Sprachen compilieren will, muss man auf so was achten.

An sich aber wirklich kein großer Punkt, es gibt schlimmere Dinge, wie das mit den Generics. Kapierst du eigentlich, warum man nicht bei Sprachen ohne Generics einfach Queue<Object> intern verwendet, anstatt eine
System.Collections.Queue und eine System.Collections.Generics.Queue zu machen? Find ich sehr hässlich. In Java kann ich GenericClass<T> auch ohne Typparameter (implizit Object) verwenden.

EDIT: Das soll natürlich nicht heißen, dass ich das für C# will. Aber man müsste es doch ermöglichen können, dass die CLR nicht-generischen Bytecode so interpretieren kann, dass sie intern Object einsetzt.