Thomas Darimont's Blog

Norbert hats schon wieder in den Fingern gejuckt: Norberts Post

Die Größe einer Community hat nichts mit ihrer Erfahrung zu tun. Die Leute, die in der .NET Community zu finden sind, haben nicht .NET in ihre Windel gelegt bekommen, sondern sind mit C++ etc. groß geworden, oder kommen gar selbst aus der Java-Welt.

In einer großen Community gibts (IMHO) mehr Potential für Alternative Lösungen als in einer kleinen Community wobei natürlich größe mit einem gewissen Rauschen verbunden ist.

Das Thema Software-Architektur ist auch schon ein wenig älter als es .NET oder Java ist. Diese Erfahrungen sind also Technologie unabhängig (wobei es sich dabei bloß um eine Technik handelt, aber so genau wollen wir nun nicht sein).

Genau das hab ich ja auch schon in meinem ersten Blog Eintrag geschreiben Hier sind wir also einer Meinung

Die Marktdurchdringung hat auch nicht unbedingt etwas mit der Community zu tun. Ich denke hier an SAP, Notes/Websphere etc. Hierzu gibt es auch kaum Hilfen. Die Marktdurchdringung ist aber in ihren Bereichen schon ganz gewaltig.

Also gerade für SAP / Notes/websphere gibts IMHO eingentlich genug Hilfen (insbesondere kommerzielle, Bertungshäuser, Bücher). Ich geb zu das man dafür nicht so viel freie verfügbare Hilfen gibt (in der Regel reicht aber die Dokumentation in den Portalen der jeweiligen Hersteller selbst vollkommen aus (wenn man ein wenig Erfahrung mit der Basis hat)). Das hängt aber vor allem damit zusammen, dass diese Produkte doch eher an empfindlichen Stellen in Unternehmen verwendet werden und deshalb das, bei der Lösung von Problemen, erlangte Wissen als Firmengeheimnis angesehen und deshalb nicht weiter kommuniziert wird.

Meiner Meinung nach ist dieses Thema sehr gefährlich, vor allem wenn man die Community nicht kennt, auf die man sich bezieht ...

Nochmal ich habe nur gesagt, dass Java die größere Community hat, das war in keinster Weise abwertend zu verstehen. Des weiteren gilt dein Kommentar auch für dich selbst

Bei mehreren tausend Zeilen für ein XML Schema warte ich bei jedem Schema Editor der mit dem Funktionsumfang daher kommt.
@20-30 Files im Editor: Wie gesagt, das kann ich nicht nachvollziehen, da ich diese Problematik nicht habe. Visual Studio 2005 hat weiß Gott, andere Macken, aber das wäre keine, die mir bis jetzt aufgefallen wäre. Und ich arbeite wohlgemerkt, auf einem Notebook

Na ja, der XML Schemaeditor von Eclipse (WTP) kommt damit aber weitaus besser klar.
Kompiliert man ein Projekt in VS 2005 reagiert die IDE nur noch sehr träge teilweise überhaupt nicht. Manchmal lässt es sogar während der Kompilierung keine Source-Änderungen (an Sourcen in anderen Projekten) mehr zu. Überhaupt ist die Tatsache, dass in VS 2005 bzw. .Net immer keinen incrementellen Compiler mehr gibt schon sehr ärgerlich. In Eclipse ist das weitaus besser gelöst. Eine ganz große Macke ist außerdem noch die das man mit VS 2005 nur stark eingechränkten Support für ältere .Net versionen (1.0/1.1) hat. Es gibt für dieses Problem zwar Workarounds, welche jedoch relativ Umständlich zu benutzen und nicht wirklich Supported sind.

Aber mit SharpDevelop gibt es ja Gott sei dank eine immer besser werdende Open Source Alternative für Visual Studio 2005

Auswahl ist immer gut. Aber warum muss man sich überhaupt eine Auswahl suchen? Idealerweise bietet mein Basis-Framework meiner Wahl diese Funktionalität an. Wenn mir das nicht passt, kann ich eine andere Lösung suchen. Bei .NET kann ich diesen Weg gehen. Bei Java MUSS ich mir einen anderen Weg suchen. Und das spricht nicht für Java.
Was heißt das weiter? Man muss Wissen über zahlreiche Bibliotheken und Frameworks haben, um das Gewünschte zusammenfrickeln zu können. Unter .NET spielt das alles zusammen. Fertig. Der Lernaufwand ist wesentlich geringer bei gleicher Leistung.

Also wie gesagt, ich sehe nichts negatives dabei wenn man sich Alternativen suchen muss / kann. Wobei "suchen" in dem Fall hier eigentlich ein Kinderspiel ist. Sucht man über google nach Java / Workflowengines wird man sofort mit entsprechenden Listen / Vergleichen versorgt über die man dann schnell die passende Workflow Engine aussuchen kann. In .Net hast du eben nur die Wahl das zu verwenden, was von MS kommt oder eben selber was zu schreiben. In seltenen Fällen gibts hier natürlich, wie bereits gesagt auch hochqualitative Open Source Projekte die den Zweck erfüllen, dass ist jedoch im .Net Bereich (leider) die Ausnahme.

Wie bereits gesagt über entsprechende Integrationsframeworks ist die große Framework-/Technologieanzahl absolut kein Problem.


Wobei ich dir zustimme ist, dass der Lernaufwand natürlich um einiges höher ist als bei eine out-Of-The-Box Lösung, jedoch schafft diese Vielfalt Raum für alternative Lösungsstrategien die man sonst nicht sehen würde.

Also WPF hat mit AWT bzw. Swing ja rein gar nichts zu tun. XAML ist rein deklarativ. Soweit ich mich erinnern kann trifft dies weder auf AWT noch auf Swing zu. Eher könnte man diese beiden mit den Windows-Forms vergleichen und selbst da ziehen sie den Kürzeren. 20 Zeilen Code für eine Table versa 3 Zeilen Code unter .NET.

Wie du ja weist ist WPF ja auch nicht nur XAML Man kanns auch programmatisch verwenden. Außerdem sagte ich ja zu Swing / SWT das diese mit entsprechenden Zusatzbilbiotheken an die WPF Funktionalitäten heran kommen (XML basierte UI, Databinding, etc.).

Zu dem Codebeispiel kann ich dann sagen, dass es in Java auch entsprechende Frameworks gibt die einen komfortablen Umgang (Databinding etc.) mit Tabellen erlauben. Man hat hier eben die Wahl und muss nicht gleich die "fetteste" Variante wählen die eventuell zu viel bzw. nicht benötigte Funktionalitäten mitschleppt.

Ja, aber du hast das nicht out of the box. Du musst zahlreiche Bibliotheken dazu installieren, Frameworks kennenlernen, und was weiß ich noch alles. Bei .NET hast du alles fix fertig dabei. Keine 3rd-Party Komponenten bzw. Bibliotheken, die alle ihre eigenen Framework-Richtlinien verfolgen. Bei .NET alles unter einer Haube, die gleichen Richtlinien.
Und wer etwas anderes verwenden möchte, kann dies natürlich tun. Kein Problem.

Also Bibliotheken installieren bedeutet unter Java: jar (eventuell mit source / Dokumentation) aus dem Internet herunterladen, in den Classpath des Projektes aufnehmen, fertig.
Keine Installer, kein Global Assembly Cache etc.
Auch hier kann ich wieder auf die Integrationsframeworks wie Spring verweisen.

Und wieder sage ich: Warum muss ich mich in zusätzliche Bibliotheken einlernen, die alle unterschiedlich aufgebaut sind und ich nicht davon ausgehen kann, dass sie einer einzigen Richtlinie entspringen? Zu umständlich. Sorry.

Hier ist eben das Problem das es in Java noch keine Spezifikation für Standard Workflow Engines gibt. Jedoch haben sich am Markt bereits einige Workflow-Engines als quasi Standard etabliert...
Workflow Engines in Java

Aber es gibt wieder nichts Java-integriertes ... d.h. für den unbedarften Entwickler erst wieder suchen ..

Auch hier liefert dir eine einfache google Suche bereits genug Material um schnell ein geeignetes Framework zu finden. Also kein Problem.

Hab ich dir bereits vor 1 Woche schon mal gesagt:
http://www.artima.com/intv/handcuffs.html

und ich hab dir vor 1 Woche auch schon gesagt, dass einige Punkte da IMHO an den Haaren herbei gezogen sind bzw. unter nüchterner Betrachtung einfach nicht so schwerwiegend sind. Worauf du dann (im übertragenen Sinne) sowas meintest wie "wenn die das sagen wird das schon stimmen"

Ist ja auch ok. Aber es muss dann nicht abwertend sein.

Das ist auch nicht abwertend gemeint Selbst wenns manchmal so rüberkommen sollte. Ich habe großen Respekt vor der .Net Technologie und der dahinterstehenden Community aber sie ist eben nicht allein auf weiter Flur in der großen weiten IT Welt.