[Diskussion] Java vs. C#

[Wildcard]

Ein guter C/C++-Entwickler kennt Zeiger, VMTs, Templates, Inlcudes, Headers, Precompiler und und und........

Aber dieses Wissen alleine wird ihn nicht zum guten Entwickler machen.
Mal ehrlich, die Syntax and Mechanik einer Sprache sind doch Kinderkacke, die Technologien sind das interessante.

 

[happy_robot]

Und Linux... Ich halte es für Zeitverschwendung, auch nur eine Minute darüber nachzudenken. Ohne Ubuntu & Co ist es reine Konsole - da kann man sich auch die alten MS-DOS, oder sogar DR-DOS - Teile raussuchen...

Ich kann nicht nachvollziehen das man Dinge die man nicht versteht sinnfrei als Zeitverschwendung darstellt.
Anders ist diese Aussage wohl kaum zu verstehen.

Die "Konsole" ist übrigens einer der schnellsten, stabilsten und sichersten Kernel die es gibt. Und das umsonst.
Auch sehr beliebt für Server......hab ich mal irgendwo gehört :roll:

 

[happy_robot]

Ein guter C/C++-Entwickler kennt Zeiger, VMTs, Templates, Inlcudes, Headers, Precompiler und und und........

Aber dieses Wissen alleine wird ihn nicht zum guten Entwickler machen.
Mal ehrlich, die Syntax and Mechanik einer Sprache sind doch Kinderkacke, die Technologien sind das interessante.

Seh ich auch anders. Für einen Entwickler sind Methodiken das wichtigste und ein Instrument (Sprache) um dieses elegant und performant und transparent umsetzen zu können. Technologien sehe ich hier als Summe dessen.
Jemand der in einer Sprache entwickelt die er nicht wirklich kennt baut in der Regel nur Mist den andere dann ausbügeln müssen. Das ist übrigens ein persönlicher Erfahrungswert :lol:

 

[Wildcard]

Bei den Methodiken gebe ich dir recht, die bleiben (solange man in einer Sprachfamilie bleibt [OOP, funktionale/prozedurale Programmierung, ...]) bestehen und kennzeichnen den guten Entwickler.
Die Sprache selbst ist für mich eher handwerkszeug. Für den Programmierer unverzichtbar, für den Entwickler nicht notwendigerweise.
Allerdings finde ich (subjektive Meinung) das ein Entwickler der etwas auf sich hält auch in mindestens einer Programmiersprache ein sehr guter Programmierer sein sollte.

 

[happy_robot]

Bei den Methodiken gebe ich dir recht, die bleiben (solange man in einer Sprachfamilie bleibt [OOP, funktionale/prozedurale Programmierung, ...]) bestehen und kennzeichnen den guten Entwickler.
Die Sprache selbst ist für mich eher handwerkszeug. Für den Programmierer unverzichtbar, für den Entwickler nicht notwendigerweise.
Allerdings finde ich (subjektive Meinung) das ein Entwickler der etwas auf sich hält auch in mindestens einer Programmiersprache ein sehr guter Programmierer sein sollte.

Ok..da sind wir ziemlich gleicher ansicht. allerdings denke ich bei der kenntnis einer sprache für einen entwickler etwas restriktiver. ich denke er MUSS eine sprache beherrschen, egal was er von sich hält.
wenn du mal tage damit verbracht hast ein ganzes projekt zu durchforsten weil es laufend aus dem Speicher läuft und du dann feststellen musst daß derjenige der es gemacht hat nicht wusste was "static" bedeutet und laufend alles in eine static collection gestopft hat siehst du das vielleicht auch so.
es kostet einfach nur zeit und nerven.

ich würde von jedem der als programmierer oder entwickler arbeitet diese kenntnis erwarten und einfordern.

 

[Wildcard]

Sollte ein Entwickler die Zielsprache nicht aus dem FF beherrschen, darf er natürlich nicht den Projektcode verunstalten :lol:
Ich will damit nur sagen, es gibt auch Entwicklertätigkeiten jenseits der reinen kodierung. Design, Architektur, Teamleitung, ...
Dazu muss man (theoretisch) keine Programmiersprache beherrschen.
Ein hochbezahlter Softwarearchitekt fasst häufig auch keinen Code mehr an und wenn er schon ein paar Dekaden dabei ist, hat mit der aktuellen Zielsprache vielleicht noch gar nicht selbst programmiert. Trotzdem kann er ein hervorragender Entwickler sein (aber eben ungeeignet als Programmierer für das betreffende Projekt).

 

[ms]

Wildcard, ich hoffe niemals in einem Projekt zu arbeiten wo ein hochbezahlter Architekt im Team ist der die Zielsprache nicht kennt. Das wäre einerseits ein Horror für die Entwicklung und andererseits frustrierend wegen der Bezahlung.
Schließlich gibt der Architekt Vorgaben für die Implementierung vor. Ich war schon in so einer ähnlichen Situation als Entwickler. Es war zwar nicht ganz so schlimm (der Architekt hatte teilweise Ahnung) aber gewisse Vorgaben mussten von den Entwicklern akzeptiert werden.

ms

 

[SnooP]

Meist sind die architekturbestimmtenden Technologien doch sehr abhängig von der einzusetzenden Programmiersprache. Bestimmte Dinge sind konzeptionell halt einfach anders in Java zu realisieren, als in C++ oder C#. C# und Java sind da noch am ehesten in einem Architekturguss zu erledigen... - bei Architektur würde ich aber immer auch so Dinge wie 3-Tier, Application-Server, verwendete Technologien, ESB oder was auch immer dazu zählen... und da sind die Produkte im Bereich .Net nu mal andere als bei Java oder C++ oder Cobol
Ich erwarte von einem Architekt demnach schon, dass er sich in der Zielsprache auskennt. Er muss nicht zich Zeilen Code geschrieben haben... aber zumindest sollte er ungefähr wissen, was Sache ist und auf was man im Einzelnen achten sollte...

die Behauptung: Informatik hat nichts mit Programmierung zu tun stimmt zwar i.W. - aber wenn ich nicht Programmieren kann, kann ich auch nicht wirklich Software entwickeln oder irgendwas anderes Informatikbezogenes aus dem Hut zaubern... - wenn ich schon sowas triviales wie das Programmieren nicht kann - wie soll ich dann die wirklich komplexen Probleme lösen können

oder aber man wird Consultant - dann muss man gar nichts können

 

[Wildcard]

Ein Architekt muss nicht derjenige sein der euch bunte UML Diagramme hinklatscht und dann mit einem Prügel bewaffnet hinter euch und eurer Tastatur steht um den Fortschritt zu überwachen.
Bei komplexen Softwarelandschaften ist eine wichtige Aufgabe zB die Kommunikation zwischen den einzelnen Anwendungen festzulegen, oder auch die Auswahl der Kerntechnologien zu treffen.
Man muss nicht 12 verschiedene Programmiersprachen sprechen um Funktionalitäten in einzelne Anwendungen aufzuteilen und zu regeln wie diese Module über eine Middleware zu kommunizieren haben.

 

[happy_robot]

ich glaube daß es auch für einen architekten sehr wichtig ist zu wissen welche möglichkeiten die sprache bietet mit der es umgesetzt wird.
nur so kann er auch evtl technische fallstricke erkennen und sie schon in der architektur berücksichtigen oder auch nur darauf hinweisen.

ausserdem würde ich einem architekten, der mich aufgrund fehlenden know-hows nicht bei der umsetzung unterstützen kann, wohl nur sehr wenig respekt entgegenbringen wollen.
er würde es wohl ja nicht mal merken wenn das was umgesetzt worden ist nicht seiner architektur entspricht.

@wildcard: eine überwachung des fortschritts setzt als basis wohl die erkenntnis des selbigen voraus

 

[ms]

Ein Architekt muss nicht derjenige sein der euch bunte UML Diagramme hinklatscht und dann mit einem Prügel bewaffnet hinter euch und eurer Tastatur steht um den Fortschritt zu überwachen.

Könntest du das bitte denjenigen Leuten erzählen, die die Architekten ernennen.
Ist zwar in meinem Fall schon zu spät aber man weiß ja nie was die Zukunft bringt.
Als Entwickler hast du da keine Chance und keinen Einfluss.
Du kannst es nur ausbaden.

Architektur ist ein sehr weitläufiger Begriff. Es kommt natürlich auch auf den Kontext an.
Heterogene Softwarelandschaften wären - so wie du es gesagt hast - so ein Kontext.
Da gebe ich dir auch recht, aber es gibt ja auch reine Java- bzw. C#-Projekte, da gibt es auch Architekturanforderungen.
Architektur beginnt ja schon bei einfachen Programmen. ZB. die Entscheidung ob und welche Patterns ich verwende.
Ist eben ein anderer Kontext als der von dir genannte.

ms

 

[byte]

IMO ist es extrem wichtig, dass der Architekt auch fundierte Programmierkenntnisse in der Projektsprache hat. Ich gehe mal vom Bereich Enterprise Applications aus. Da stellt sich zu Beginn der Entwicklung erstmal die essentielle Frage, welche Archtitektur eingesetzt werden soll (z.B. 3-Schicht) und dann muss man überlegen, welche Plattform oder welches Framework dafür genutzt werden soll (z.B. EJB oder Spring). Dann kommen weitere Fragen auf, z.B. welches Persistenzframework eingesetzt werden soll (z.B. Hibernate, TopLink, iBatis oder reines JDBC) und nicht zuletzt wie das Frontend aussehen soll (z.B. Web in Form von JSF, Struts, JSP und Co. oder Rich Client in Form von Swing, SWT, Eclipse RCP, ...). Dann gibt es häufig noch Anbindungen an Drittsysteme. Es muss also entschieden werden, wie der Datenaustausch stattfinden kann (z.B. Webservices, ...).

Welcher Architekt kann bitte eine solche Entscheidungen ruhigen Gewissens treffen, wenn er selbst keine fundierten Kenntnisse in diesen Technologien hat? Und diese Kenntnisse bekommt man eben nur durchs Programmieren bzw. Entwickeln mit eben diesen Libraries / Frameworks / Plattformen / Technologien.
Da reicht es doch bei weitem nicht aus, ein paar Diagramme zu malen oder ein paar Interfaces zu schreiben.

 

[Wildcard]

Architektur beginnt ja schon bei einfachen Programmen. ZB. die Entscheidung ob und welche Patterns ich verwende.
Ist eben ein anderer Kontext als der von dir genannte.

Ich komme aus einem anderen Kontext. Auf dieser Ebene ist bei uns der Programmierer sein eigener Architekt. Diese Design Entscheidungen müssen lediglich vor dem eigenen Team gerechtfertigt werden können.
Bei größeren Projekten ist die Architektur meistens selbst eine Teamarbeit.

 

[Wildcard]

Welcher Architekt kann bitte eine solche Entscheidungen ruhigen Gewissens treffen, wenn er selbst keine fundierten Kenntnisse in diesen Technologien hat? Und diese Kenntnisse bekommt man eben nur durchs Programmieren bzw. Entwickeln mit eben diesen Libraries / Frameworks / Plattformen / Technologien.
Da reicht es doch bei weitem nicht aus, ein paar Diagramme zu malen oder ein paar Interfaces zu schreiben.

Genau das sage ich ja, man muss die Technologien kennen, das ist auch der wichtige Teil. Aber muss man wirklich eine zB Hibernate Anwendung selbst kodiert haben, nur um dessen Vorteile zu kennen?
Ich denke nicht. Technologien beurteilen zu können, sie zu verstehen und die Vor- und Nachteile zu kennen, geht nicht zwangsläufig damit einher auch der Star-Programmierer in diesen Bereichen zu sein (es ist allerdings ein großes Plus :wink: ).

 

[happy_robot]

... man muss die Technologien kennen, das ist auch der wichtige Teil. Aber muss man wirklich eine zB Hibernate Anwendung selbst kodiert haben, nur um dessen Vorteile zu kennen?
Ich denke nicht.

ich denke schon. und es ist unabdingbar um auch die nachteile zu erkennen welche man nur dann herausfindet wenn sie einem selber probleme bereiten.

Technologien beurteilen zu können, sie zu verstehen und die Vor- und Nachteile zu kennen, geht nicht zwangsläufig damit einher auch der Star-Programmierer in diesen Bereichen zu sein (es ist allerdings ein großes Plus :wink: ).

es gibt viel zu viele leute die meinen daß sie dieses und jenes beurteilen können. die glaubwürdigkeit und die verlässlichkeit solcher urteile steigt immens wenn man genau weiß das derjenige sie ausspricht sie auch angewendet hat.

 

[ARadauer]

Die Vor und Nachteile? Woher kennt man die? Aus einem oberflächlichen Buch oder der Hibernate Homepage?

Ich denk nicht, das jemand wirklich die Vorteile von zb Hibernate oder Spring versteht, wenn er nicht damit gearbeitet hat.

Ok Hibernate vielleicht schon, aber bei etwas komplexeren wie Spring, JSF oder Struts sicher nicht.. man muss damit gearbeitet haben, um wirklich fundierte Technologie Entscheidungen zu treffen.

Meine Meinung

 

[ms]

Aber muss man wirklich eine zB Hibernate Anwendung selbst kodiert haben, nur um dessen Vorteile zu kennen?

Eine LazyInitialisationException auf dem Remoteclient ist in meinen Augen ein klarer Architekturfehler.

ms

 

[byte]

Aber muss man wirklich eine zB Hibernate Anwendung selbst kodiert haben, nur um dessen Vorteile zu kennen?

Eine LazyInitialisationException auf dem Remoteclient ist in meinen Augen ein klarer Architekturfehler.

Ganz genau! Gerade Hibernate ist ein so mächtiges Werkzeug, dass man schon genau kennen sollte, wenn man eine Anwendung damit entwickeln will.
Man stößt nämlich unabdingbar auf die Design-Entscheidung, ob man Hibernate-Objekte aus dem Transaktionskontext nach draußen gibt oder ob man stattdessen nur DTOs weiterreicht. Diese Entscheidung kann man gar nicht treffen, ohne fundierte Kenntnisse über Hibernate zu haben.
Ähnlich verhält es sich mit dem Spring Framework und noch viel stärker, wenn die Technologie nicht nur eine Library oder ein Framework ist, sondern eine ganze Plattform mitliefert, wie es z.B. bei EJB der Fall ist.

Die Vor- und Nachteile dieser Technologien kann ich mir innerhalb eines Vormittags zusammenlesen. Ein paar Beispieltutorials programmiert man sich in einer Woche zusammen. Aber um damit komplexe Anwendungen zu konzipieren, braucht man einfach richtiges Knowhow, dass man nur in jahrelanger Projekterfahrung erlangen kann.

 

[Wildcard]

Was ihr mir damit also sagen wollt ist folgendes:
Ihr (oder betreffender Architekt in euren Unternehmen) kennt nicht nur jede im Einsatz befindliche Technologie aus dem FF und hat jahrelange Praxiserfahrung, sondern auch alle möglichen alternativen in allen möglichen Sprachen?
Nicht schlecht, müssen gut bezahlte Leute sein :wink:
Irgendwann muss auch mal eine Entscheidung getroffen werden und dazu braucht man Leute die einem bei der Informationsbeschaffung und im Prototyping gut zuarbeiten können.
James Gosling ist eigentlich ein Vollblutprogrammierer, aber trotzdem kann ich mir nicht vorstellen, das er nach all den Jahren immer noch den Daumen auf jeder Entscheidung hat.
Für mich ist es eine wichtige Fähigkeit sich selbst soweit wie möglich und nötig über Technologien zu informieren,
aber ab einem gewissen Level muss man auch in Lage sein an die Leute zu delegieren, die das Zeug später implementieren müssen und die Lösung anschließend im Dialog erarbeiten.

Beispiel aus meiner eigenen Erfahrung:
Vor ein paar Jahren wurde beschlossen eine unserer Applikationen auf Eclipse umzuziehen.
Nach eurer Meinung hätte diese Entscheidung von jemandem getroffen werden müssen der Eclipse Experte ist und seit Jahren PlugIns programmiert.
In der Realität funktioniert es aber nicht so. Man hat eine Idee, man beschafft sich Informationen, man diskutiert, wertet aus, man experimentiert.
Aber irgendwann muss dann einfach der Sprung ins kalte Wasser passieren. Wie soll es sonst vorwärts gehen?

 

[ms]

Ich hab es oben schon geschrieben.
Es kommt auf den Projektkontext an.
Innerhalb eines (Teil-)Projektteams kann es jemanden geben der Architekturaufgaben hat und (Teil-)Projektübergreifend kann es jemand anderen geben.
Es verlangt niemand und es ist auch gar nicht möglich, dass alles von einer Person sowohl im Detail als auch Technologieübergreifend beherrscht wird.
Bis zu einem gewissen Tiefengrad muss aber der Architekt schon bescheid wissen.
Ich glaube allerdings nicht dass man das Big Picture beherrschen kann ohne zumindest einmal in die Tiefe bis zum Grund gegangen zu sein.

Und was die Entscheidung betrifft, dass ist doch nur Sache des Budgets. Je mehr Architekten idealerweise mit unterschiedlicher Erfahrungen aufeinander treffen und je mehr Zeit diese haben um eine Entscheidung zu treffen desto besser wird in der Regel die Entscheidung sein und das Risiko einer Fehlentscheidung verringert.

ms

 

[Wildcard]

Dein Posting trifft es IMO ziemlich. Es gibt den Projekt- und den Produkt-Scope. Beide haben unterschiedliche Sichten, Anforderungen und Detailierungsstufen.

Ich glaube allerdings nicht dass man das Big Picture beherrschen kann ohne zumindest einmal in die Tiefe bis zum Grund gegangen zu sein.

Ich glaube es ehrlich gesagt auch nicht, aber ich will diese Fähigkeit auch niemandem absprechen, das wäre vermessen.

 

[byte]

Vor ein paar Jahren wurde beschlossen eine unserer Applikationen auf Eclipse umzuziehen.
Nach eurer Meinung hätte diese Entscheidung von jemandem getroffen werden müssen der Eclipse Experte ist und seit Jahren PlugIns programmiert.
In der Realität funktioniert es aber nicht so. Man hat eine Idee, man beschafft sich Informationen, man diskutiert, wertet aus, man experimentiert.

Es kommt halt darauf an, wie mutig der Projektleiter ist und wieviel er zu verlieren hat. Jeder muss sich halt selbst überlegen, ob er das Risiko eingehen will, eine Technologie einzusetzen, die er nicht beherrscht.
Natürlich muss man auch mal ins Kalte Wasser springen. Die Frage ist halt, ob man das im Zweifelsfall rechtfertigen will und kann, wenn man Deadlines nicht einhalten kann aufgrund von auftretenden Problemen, die vorher nicht absehbar waren. Es gibt Projekte, da herrscht wenig Termindruck. Es gibt aber auch andere Projekte.
Meiner Erfahrung nach sind Entscheidungsträger eher konservativ und vorsichtig, wenn es darum geht, etwas einzusetzen, das man noch nicht kennt. Und das halte ich auch für richtig, auch wenn ich natürlich selbst zu denjenigen gehöre, die gerne neue Wege gehen. Aber das Projekt muss halt den Spielraum dafür bieten.

Wenn ich eine Software entwickeln soll, die am besten gestern fertiggestellt sein muss, dann gehe ich lieber kein Risiko ein und setze auf das, was ich kenne und zeitlich einschätzen kann.
Wenn ich eine Software entwickeln soll, die extreme Performanceanforderungen an die Datenbank stellt, und ich habe vorher nie einen OR-Mapper produktiv eingesetzt, dann lasse ich lieber die Hände von Hibernate und Co.

 

[Guest]

...
Wenn ich eine Software entwickeln soll, die extreme Performanceanforderungen an die Datenbank stellt, und ich habe vorher nie einen OR-Mapper produktiv eingesetzt, dann lasse ich lieber die Hände von Hibernate und Co.

Wenn du es kennst, erst recht. :lol:

 

[nEp]

So dann will ich auch mal meinen Senf zum Thema geben, irgendwie wurde ja soo viel nicht auf die eigentliche Sprache(n) bisher eingegangen:

Also erst mal sind C# und Java schon sehr ähnlich, und verfolgen quasi die gleichen Konzepte. Von demher würde ich beide Sprachen als "gleich" ansehen, und mich je nach Plattform entscheiden. C# ist bestimmt die bessere Wahl, wenn man hauptsächlich für Windows entwickelt. Auch die neusten Erweiterungen von .NET tragen dazu bei (WPF, WCF). Das kommt halt alles aus einem Guss und ist gut zu benutzen. Ansonsten, wenn ich auf wirkliche plattformunabhängigkeit abziele, würde ich eher Java benutzen.

C# ist nicht mehr nur als Java-Abklatsch zu sehen, das ist richtig. Es ist aber definitiv vieles von Java abgekupfert, schließlich wollte Microsoft ja C# auch als Gegenüber zu Java positionieren. Ein Vorteil den C# dabei hat, ist der, dass man hier schon aus SUNs Fehler gelernt hat, und manche Dinge gleich besser gemacht und nicht so viele Altlasten wie SUN mitschleppt (gibt ja einige Dinge in der API vom JDK die nur noch aus Abwärtskompatibilität da sind; Beispiele hierfür gibts genug). Andererseits ist es aber auch so, dass Microsoft auch neue Dinge eingeführt hat, die dann wiederrum von SUN auch in Java übernommen wurden (das genannte Beispiel Generics z.B.). Der Wettbewerb wurde sozusagen belebt, was so schlecht ja nicht ist.

Ansonsten bietet C# ein paar zusätzliche nette zusätzliche Sprachfeatures, die zwar nicht unbedingt vonnöten sind, aber doch ganz brauchbar sind. Beispiele:
- Schlüsselwort partial um große Klassen besser zu managen
- using-Direktive in Kombination mit IDisposable
- Strukturen um einfache Value-Typen zu repräsentieren, wo eine Klasse evtl. oversized wäre
- ....

Was mir dabei aber auch missfällt ist, das, dass darunter IMHO auch tatsächlich die Einfachheit der Sprache etwas leidet. Es gibt mehr Schlüsselwörter und Möglichkeiten. Bestes Beispiel wären hier wieder z.B. die Strukturen, hiuerfür gelten nämlich andere Regeln als für Klassen, was auch zur Verwirrung führen kann. Ansonsten gibts auch noch paar mehr Schlüsselwörter, wodurch man einfach mehr "aufpassen" muss. Da finde ich, dass Java eine weitaus klarere Linie verfolgt. Gefällt mir persönlich besser und führt IMHO zu sauberem Code im Gegensatz zu C#(nicht wie von jemand anderem hier behauptet). Ich finde Microsoft hats hier ein kleines bisschen zu gut gemeint, aber letztendlich spielt das keine so große Rolle.
Was mir an C# im Gegensatz zu Java ein bisschen missfällt ist folgendes:
- Cloning: Das ist in Java auch schon nicht unbedingt optimal gelöst, ist aber in C# IMHO noch beschissener gelöst.
- Exception-Handling: C# ist hier wie C++: Man ist NICHT gezwungen irgendwelche Exceptions zu handeln, und man kann auch keine throws-Direktiven bei Methoden angeben. Das heißt, unter Umständen weiß man nicht mal welche Exceptions von einer Methode geworfen werden können. Man ist auf die reine Code-Dokumentation angewiesen, und das die nicht immer vollständig ist, ist bekannt. Da finde ich den Java-Ansatz besser: Man ist sich immer bewusst welche Exceptions gerade fliegen können, auch wenn man dazu evtl gezwungen ist, etwas mehr Exception-Handling zu betreiben.

 

[bronks]

... Ein Vorteil den C# dabei hat, ist der, dass man hier schon aus SUNs Fehler gelernt hat, und manche Dinge gleich besser gemacht und nicht so viele Altlasten wie SUN mitschleppt (gibt ja einige Dinge in der API vom JDK die nur noch aus Abwärtskompatibilität da sind; Beispiele hierfür gibts genug) ...

Dazu ist anzumerken, daß .NET1-Programme nur mit .NET1 laufen, .NET2-Programme nur mit .NET2 laufen, aber sie laufen. Wenn man dagegen ein altes JavaProgramm auf einer aktuellen VM laufen lässt, dann riskiert man teilweise echt seinen Hals, wenn man derjenige ist, der dafür die Freigabegegeben hat, weil plötzlich Überraschungen auftreten können, mit denen niemals jemand gerechnet hätte.

 

[Jango]

Also erst mal sind C# und Java schon sehr ähnlich, und verfolgen quasi die gleichen Konzepte. Von demher würde ich beide Sprachen als "gleich" ansehen...
...
C# ist nicht mehr nur als Java-Abklatsch zu sehen, das ist richtig. Es ist aber definitiv vieles von Java abgekupfert, schließlich wollte Microsoft ja C# auch als Gegenüber zu Java positionieren....

Da muss ich passen, dümmer kann selbst ich nicht labern...

 

[tuxedo]

Da muss ich passen, dümmer kann selbst ich nicht labern...

Na was sind das denn für Umgangstöne? Das hebt keinesfalls das Niveau des Threads.

 

[Guest]

Also erst mal sind C# und Java schon sehr ähnlich, und verfolgen quasi die gleichen Konzepte. Von demher würde ich beide Sprachen als "gleich" ansehen...
...
C# ist nicht mehr nur als Java-Abklatsch zu sehen, das ist richtig. Es ist aber definitiv vieles von Java abgekupfert, schließlich wollte Microsoft ja C# auch als Gegenüber zu Java positionieren....

Da muss ich passen, dümmer kann selbst ich nicht labern...

Klär mich bitte auf.

 

[AlArenal]

Manch einer bekommt eben die Unterscheidung zwischen reiner Sprache, Plattform und dem Drumrum nicht hin...

 

[nEp]

Meinst du damit mich?
Mir ist der Unterschied sehr wohl bewusst (dass z.B. das JDK nicht zur Sprache ebensowenig wie das .NET Framework zur Sprache gehört). Es macht für mich hier aber keinen Sinn, dass haarklein zu unterscheiden, da das in der Praxis keine Rolle spielt.
Genauso ist mir bewusst, dass .NET mehr ist, als nur ein Counterpart zum JDK (man kann das ja auch von anderen Sprachen nutzen z.B.), aber das spielt doch hier in der Diskussion ebenfalls keine Rolle.

Ich weiß jetzt immer noch nicht was ich soo dummes gelabert haben soll?

 

[AlArenal]

Nein, du warst nicht gemeint.

 

[ms]

Dazu ist anzumerken, daß .NET1-Programme nur mit .NET1 laufen, .NET2-Programme nur mit .NET2 laufen, aber sie laufen. Wenn man dagegen ein altes JavaProgramm auf einer aktuellen VM laufen lässt, dann riskiert man teilweise echt seinen Hals, wenn man derjenige ist, der dafür die Freigabegegeben hat, weil plötzlich Überraschungen auftreten können, mit denen niemals jemand gerechnet hätte.

Bist du sicher?
Gerade bei Java hat man ja immer versucht abwärtskompatibel zu sein.
Und ich finde, dass das auch in der Regel gegeben ist. (Ausnahmen bestätigen natürlich die Regel).
Der Vergleich dagegen zu .NET, dass es dort läuft ist ja kein Vorteil, wenn man eine "ältere" Version nehmen "muss".
Kannst ja bei Java genauso eine 1.1er VM für dein 1.1er Programm nehmen.

ms

 

[ARadauer]

ich kenne keine situation in der ein altes java programm in einer neuen jvm nicht das macht was es vorher gemacht hat.


(ausser irgendwas mit calender, aber das war ein bug)

 

[bronks]

... Bist du sicher?
Gerade bei Java hat man ja immer versucht abwärtskompatibel zu sein.
Und ich finde, dass das auch in der Regel gegeben ist. (Ausnahmen bestätigen natürlich die Regel).

Bin mir sicher und leider hat es bei Java mit der Abwärtskompatibilität nicht ganz geklappt. Dadurch daß eine gute Kompatibilität in der Regel gegeben ist, hat man bei einem Update der VM einen extremen Testaufwand, weil man auch den unbedeutendsten Blödsinn berücksichtigen muß.

... Der Vergleich dagegen zu .NET, dass es dort läuft ist ja kein Vorteil, wenn man eine "ältere" Version nehmen "muss".
Kannst ja bei Java genauso eine 1.1er VM für dein 1.1er Programm nehmen.

Ich kann selbstverständlich eine 1.1er JVM verwenden. Aber wenn jemand auf einem Computer diese 1.1er VM braucht und dann noch die 1.3.1er und noch die 1.5er, dann sind fast alle User damit überfordert das ganze funktionierend zu Konfigurieren.

Ich habe gerade .NET1.1, .NET2.0 und .NET3.5 installiert. Ein .NET-Programm weiß von alleine auf welcher Version es zu laufen hat.

 

[Wildcard]

ich kenne keine situation in der ein altes java programm in einer neuen jvm nicht das macht was es vorher gemacht hat.

Beispiel aus meinem aktuellen Projekt:
kompiliert für 1.4, läuft aber nur auf 1.5 ab update 11.
Das ganze sieht dann so aus (wie gesagt, kompiliert mit 1.4)

<1.5u11 läuft nicht

1.5u11 läuft
1.5u12 läuft
1.5u13 läuft
1.5u14 läuft nicht
1.5.u15 läuft nicht

1.6 läuft nicht

 

[tuxedo]

Wie äußert sich denn das "läuft nicht"? Hatte sowas bisher noch nicht.

- Alex

 

[Wildcard]

Primär sind die Probleme auf das Fokus Subsystem zurückzuführen, das anscheinend ständig umgebastelt wird und je nach aktueller Ausführung Deadlocks produziert, oder (in besagtem Projekt) schlicht nicht funktioniert.
Java 6 macht Probleme, da JaxB in die API aufgenommen wurde und damit nicht mehr kompatibel ist.
Ausserdem ist mit Java 6 QName dazu gekommen, was ebenfalls Probleme bereitet.

 

[nEp]

@Jango: Ich hätte immer noch gerne gewusst, was ich jetzt so dummes gelabert haben soll? (ernst gemeint)

 

[an.nEp]

AlArenal
"Schwarze Löcher haben keine Haare." John A. Wheeler
BeitragVerfasst am: 29. 05. 2008, 20:26 Titel: Zitieren
Druckversion downloaden (dieser Post)
Nein, du warst nicht gemeint.

 

[Jango]

@Jango: Ich hätte immer noch gerne gewusst, was ich jetzt so dummes gelabert haben soll? (ernst gemeint)

Okay, weil du es bist:

Mal abgesehen davon, dass du deine 'Weisheiten' sicher nur vom Hören-Sagen kennst (denn bevor man sowas äußert, sollte man sich schon sicher sein, was man da ablässt), wurden diese nichtssagenden Sätze schon mehr als einmal in diesem Beitrag erwähnt, befürwortet und widerlegt.
Das wäre in etwa, wenn dir 10 Leute erzählen, nachts ist es dunkel - und du sagst hinterher den selben Leuten 'nachts ist es dunkel'. Das nenne ich dummes Gelaber.

Aufgeklärt?

 

[nEp]

Kannst du auch mal wirklich konkret Stellung nehmen, außer mit leeren Phrasen um dich zu schmeißen?
Welche "Weisheiten" meinst du denn? Da ich sowohl mit Java als auch C# schon einige Projekte mittlerweile erledigt habe, kommt das ganz sicher nicht nur vom Hörensagen.
Oder beziehst du dich darauf, dass C# bzw. allgemein CLR von MS als Gegenstück zu Java bzw. JVM positioniert ist? Dass das so ist, ist Fakt. Da bräuchte man nicht mal irgendwelche Quellen, sondern müsste sich einfach nur mal die Sprachkonstrukte und Konzepte anschauen.

 

[Guest]

Ein Nachteil von Java ist, dass sämtliche Anwendungen über den gleichen Launcher gestartet werden. Möchte man nur bestimmten
Java-Anwendungen unter Windows den Zugang zum Internet erlauben, stellt sich das Problem, dass die Anwendung eigentlich
javaw.exe ist. Bei native übersetzten Sprachen hat man das Problem nicht.
OK, man kann sich einen eigenen Launcher schreiben, dies wird aber von JDK nicht direkt unterstützt.

 

[AlArenal]

Das Problem bringt Windows doch schon selbst mit. Ich sag nur "svchost.exe".

 

[Gast]

ich versuche aktuell java zu lernen, hab mich vorher intensiv mit c# beschäftigt. nach meiner erfahrung ist es so: wer c# kann, kann auch einen java code lesen und umgekehrt. also geht euch net gegenseitig an den hals sondern vertragt euch. wer java beherscht soll sich c# angucken und wer c# kann soll sich mal java angucken. ich bin sicher das selbst derjenige der seine sprache extrem gut beherscht in der anderen sprache sachen findet die auf eine art einfacher bzw interessanter gelöst sind.

Mein Vorschlag: Ein OpenSource-Projekt das eine Symbiose aus C# und Java darstellt

MFG aus Dresden

 

[Jango]

wer c# kann, kann auch einen java code lesen...

Richtig!

...und umgekehrt.

Falsch! Ein Java-Entwickler ist allergisch gegen alles was mit 'C' beginnt...
Und außerdem gibt es Dinge in C#, die - wenn nicht schon geklaut und von allen gutgeheißen wurde - ein Java-Mensch von Grund auf hasst und bombardiert - wie gesagt, wenn es nicht schon von java kopiert wurde und alleine aus dem Grund für gut befunden wurde.

Die ganze Diskussion ist krank und kaputt! Seit Anfang an. Ich fass mal kurz zusammen: .NET (darin auch C# enthalten) ist auf dem Hinweg - Java auf dem Rückweg. Und komm mir keiner mit irgendeiner Statistik! Die sind käuflich...

 

[bronks]

... Falsch! Ein Java-Entwickler ist allergisch gegen alles was mit 'C' beginnt...
Und außerdem gibt es Dinge in C#, die - wenn nicht schon geklaut und von allen gutgeheißen wurde - ein Java-Mensch von Grund auf hasst und bombardiert - wie gesagt, wenn es nicht schon von java kopiert wurde und alleine aus dem Grund für gut befunden wurde ...

Generics, JSP und JSF z.B.? Haben die Javaleuts alles von MS abgeschaut und teilweise echt mieß umgesetzt.

 

[byte]

Generics, JSP und JSF z.B.? Haben die Javaleuts alles von MS abgeschaut und teilweise echt mieß umgesetzt.

Falsch.

 

[Wildcard]

Ich fass mal kurz zusammen: .NET (darin auch C# enthalten) ist auf dem Hinweg - Java auf dem Rückweg. Und komm mir keiner mit irgendeiner Statistik! Die sind käuflich...

Dann wäre der Market Share des Microsoft Produkts aber deutlich größer :lol:

 

[SnooP]

Die ganze Diskussion ist krank und kaputt! Seit Anfang an. Ich fass mal kurz zusammen: .NET (darin auch C# enthalten) ist auf dem Hinweg - Java auf dem Rückweg. Und komm mir keiner mit irgendeiner Statistik! Die sind käuflich...

1. Warum ist die Diskussion krank und kaputt? Ich find sowas immer sehr lustig

2. Woher kommst du dann auf die Annahme, dass Java auf dem Rückweg ist und .Net auf dem Hinweg wenn nicht aus einer Statistik - Glaskugel? Auftragslage bei euch? Eigenes Empfinden?

Im Falle von letzterem: wundert mich ja nu nich

Generics waren in Java schon entwickelt als sie in .Net eingeführt wurden - das Konzept ist aber an sich nicht neu - daher haben sich da beide nichts gegenseitig abgeguckt. Generics sind auch nicht mit C-Templates vergleichbar - sonst hätte man in .Net (C#) ja einfach Templates einführen können...

JSP: nunja... von was wurde denn JSP abgeguckt? JSPs sind entstanden, als MS noch ASP (ich nenne es mal 1.0 der Einfachheit halber) mit VBScript vertrieb.

JSF: war in der Spezifikationsphase lange vor ASP.Net - die haben sich da nur unheimlich lange Zeit für genommen und am Ende kam auch nichts so dolles raus... erst ab 1.2 ist JSF nutzbar... die Ansätze sind hier sicher ähnlich bei ASP.Net und JSF - aber abgeguckt hat sich da auch wieder niemand was - dafür sind die Teile dann beim näheren Hingucken doch wieder zu unterschiedlich. Und alleine den Komponentenansatz abzugucken - darauf kann man sicher kein Patent anmelden ... auf die Idee sollte eigentlich jeder irgendwann kommen, der auch schonmal Rich-Clients programmiert hat.

Ich bin übrigens nicht allergisch gegen alles was mit C anfängt... obwohl.. Cobol fängt ja auch mit C an... hmmmm

C# als Sprache an sich fand ich sehr sinnvoll (z.B. das explizite definieren von virtuellen Methoden,...) - aber was teilweise an neuen Sprachkonzepten in zukünftigen C# Versionen geplant ist, kann ich nicht unbedingt gutheißen... diverse Dinge in C# kann man mögen, muss man aber auch nicht... ich vermisse in Java zumindest nix.

Aber letztlich: Jeder so wie er am liebsten mag ... trotzdem sind solche Diskussionen doch immer spannend...

 

[AlArenal]

Aber letztlich: Jeder so wie er am liebsten mag ... trotzdem sind solche Diskussionen doch immer spannend...

Wobei es ziemlich nervig ist, wenn hier Leute, die nur zum Zeitvertreib proggen, mit Pseudo-Argumenten kommen, Statistiken generell ablehnen und meinen, nur ihr Kaffeesatz allein enthalte die reine Wahrheit. Die sollten vielleicht mal weniger von dem Gebräu zu sich nehmen..