3. Warum wird soviel in Java/C# entwickelt?

Warum wird soviel in Java/C# entwickelt?

  • M

    Welche Sprache die mächtigeren Mittel hat ist im Prinzip zweitrangig. Für die meisten Auftraggeber ist wichtig: schnelle und günstige Entwicklung.

    Das sind beides Argumente die für Java sprechen(C# kenn ich nicht weiter). Für C++ bedarf es einfach mehr Erfahrung um gleiches zu erreichen.

    Die zweite Punkt pro Java sind sicherlich die in Mode geratenen Thin-Clints in Kombination mit J2EE Application Servern.

    asdrubael schrieb:

    Ich frag mich ernsthaft ob den Threadstarter solche Detailfragen interessieren.
    http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.4

    IMHO sind Fragen wie "gibt es für Java eine Visual Studio ähnliche IDE" oder "Was wird aus Java wenn Sun irgendwann pleite geht" wesentlich wichtiger als einzelne Sprachfeatures.

    Zu 1: Eclipse, JDeveloper, JBuilder
    Zu 2: Sun wird IMHO in den nächsten 2 Jahren Java freigeben. Es gibt auch jetzt schon andere Umgebungen für Java.

    <edit>Aussage präzisiert 😉 </edit>

    0
  • M

    Ihr diskutiert bereits wieder auf einer Ebene, die für die Auswahl einer Programmiersprache für ein Projekt eher belanglos ist.

    0
  • A

    Ob eine Sprache "plattformunabhängig" ist oder selbst eine komerzielle und proprietäre Plattform darstellt finde ich nicht so belanglos.

    0
  • M

    Also, zum einen ist die Frage nach Plattformunabhängigkeit in vielen realen Projekten weniger wichtig. Und wie ich bereits erwähnte, muß man auch ein Java-Programm auf jedem OS testen, da oberhalb einer gewissen Abstraktionsebene die Unterschiede im OS einfach vorhanden sind und sich nicht mehr scheinbar übertünchen lassen.

    Aber davon spreche ich ja gar nicht: die Leute hier diskutieren bereits wieder über Templates und Interfaces... das meinte ich eigentlich. Hat jemals einer in einem realen Industrieprojekt davon gehört, daß die Wahl einer Projektsprache davon abhängig gemacht wurde, ob es Templates oder Interfaces gab???

    0
  • R

    Aber davon spreche ich ja gar nicht: die Leute hier diskutieren bereits wieder über Templates und Interfaces... das meinte ich eigentlich. Hat jemals einer in einem realen Industrieprojekt davon gehört, daß die Wahl einer Projektsprache davon abhängig gemacht wurde, ob es Templates oder Interfaces gab???

    Nein, aber darum geht es ja auch in der Diskussion nicht mehr. Natürlich interessiert sich da niemand dafür, welche Sprachfeatures die Sprache hat. Das haben wir ja auch in dem Thread bereits erwähnt, dass Java hier vorallem dadurch "gewinnt", dass Entwicklung von Anwendungen erleichtert wird.

    Man wählt eben die Sprache aus, die am besten für das Projekt geeignet ist. Das hängt natürlich davon ab, wo das Knowhow der Entwickler liegt, welche Tools und welcher Code bereits in der Firma vorhanden ist, welcher Manager mit wem Golf spielt und so weiter.

    Die wenigsten Firmen, die seit 20 Jahren zum Beispiel Embedded Anwendungen in Forth schreiben werden auf einmal Java oder C++ oder GodsOwnFuckingLanguage nehmen, weil das die Erfahrung und Investitionen der letzten 20 Jahre mit einem schlag köpfen würde.

    0
  • M

    Diese beiden Aussagen:

    kingruedi schrieb:

    Man wählt eben die Sprache aus, die am besten für das Projekt geeignet ist.

    kingruedi schrieb:

    Das hängt natürlich davon ab, wo das Knowhow der Entwickler liegt, welche Tools und welcher Code bereits in der Firma vorhanden ist, welcher Manager mit wem Golf spielt und so weiter.

    stehen meiner Meinung nach im Widerspruch zueinander.

    0
  • R

    Vom Sprachtechnischen Standpunkt auf jeden Fall. Aber das ist ja nicht der einzige Punkt, der bei industriellen Projekten wichtig ist, sonst käm es ja wirklich auf Templates oder Interfaces an.

    Du kennst dich damit aber auf jeden Fall besser aus als ich.

    0
  • G

    Magoon schrieb:

    Zu 2: Sun wird wahrscheinlich in den nächsten 2 Jahren Java freigeben.

    Ist zwar OT, aber:

    1. Wo hast du das denn her? Ich halte das ehrlich gesagt für eher unwahrscheinlich.
    2. Was soll der Vorteil davon sein bzw. was soll der Unterschied zum jetzigen Modell sein (theoretisch und praktisch gesehen)?

    0
  • M

    @Gregor: Das mit den 2 Jahren habe ich mal angenommen, da Sun mittlerweile vieles Produkte unter OOS Lizenzen stellt. Konkrete Pläne soll aber wohl schon geben.

    http://www.zdnet.com.au/news/software/0,2000061733,39149502,00.htm

    0
  • O

    das Java 2 SDK ist schon längst open source.

    auf bald
    oenone

    0
  • G

    Magoon schrieb:

    @Gregor: Das mit den 2 Jahren habe ich mal angenommen, da Sun mittlerweile vieles Produkte unter OOS Lizenzen stellt. Konkrete Pläne soll aber wohl schon geben.

    http://www.zdnet.com.au/news/software/0,2000061733,39149502,00.htm

    Ok, danke für den Link. Ist sehr interessant. Ich war bisher der Meinung, dass die Entwicklung diesbezüglich eher in die Richtung "Wie kann man die Community stärker an der Entwicklung usw. von Java beteiligen, ohne es zu OSS zu machen" geht.

    Man sieht diesbezüglich vor allem einen immer transparenteren Entwicklungsprozess, der es interessierten Leuten ermöglicht, sich zu Entwicklungen zu Java zu äußern oder Ideen anzuregen. Im Vergleich zu Java 5.0 gibt es jetzt für Java 6.0 zum Beispiel öffentliche Foren, die sich genau hiermit befassen und man kann auch jederzeit relativ aktuelle "Snapshots" von Java 6.0 als Source oder Binary herunterladen. Auch das JCK (Java Compatibility Kit) ist inzwischen als Code verfügbar, wobei die momentane Lizenz die Nutzung hiervon auf das Lesen des Sourcecodes einschränkt.

    Was man bisher nicht beobachten kann, ist eine Absicht, Java unter eine OS-Lizenz, wie die GPL oder so zu stellen. Deshalb hat mich deine Aussage etwas überrascht. Mal sehen, was da kommt, ich würde diesen zdnet-Artikel diesbezüglich nicht überbewerten. Wie in dem Artikel schon steht, ist der Schritt hin zu einem Open Source Java in der Java Community sehr umstritten und selbstverständlich wird es da auch bei Sun unterschiedliche Sichtweisen geben. Ich denke also nicht, dass das, was der da sagt zu 100% sicher ist.

    0
  • G

    oenone schrieb:

    das Java 2 SDK ist schon längst open source.

    Nein. "Open Source" hat interessanter Weise als Begriff mehr Bedeutung bekommen, als "der Code ist öffentlich verfügbar". Mit dem Begriff "Open Source" sind auch bestimmte Bedingungen an die Lizenzen usw. verbunden.

    0
  • M

    @Gregor: Das dachte ich auch immer. Es gibt wohl auch noch einige Verantwortliche bei SUN die das "compile once, run everywhere" Konzept gefährdet sehen.

    <edit>Ich denke die Lizenz, falls es dazu kommt, wird wohl auch nicht im klassischen Sinne eine OSS Lizenz sein. Ich denke eher, dass der Java Community Process weiterhin das Organ bleibt, welches den Ton angibt.</edit>

    Ich denke das wird in die selbe Richtung gehen wie Solaris. Daher kommt auch meine Vermutung mit den 2 Jahren. 😉 Auch der Druck von IBM auf freigabe des Codes könnte eine Rolle spielen, da IBM zur Zeit stark mit für die Verbreitung von Java verantwortlich ist.

    0
  • ?

    kingruedi schrieb:

    Interfaces (seltsamerweise gibt es ja genug Leute, die 'pure abstract classes' als Workaround benutzen

    Entweder versteh ich Interfaces nicht oder Interfaces sind einfach nur abstrakte Klassen.

    Du verstehst sie bestimmt, aber du übersiehst ne Hässlichkeit von C++. Wenn ich richtig informiert bin, musst du in C++ bei Mehrfach-Ererbung von Methoden dich in der abgeleiteten Klasse für eine der Methoden der Basisklassen entscheiden, sonst ist der Aufruf mehrdeutig - auch wenn nur eine nicht abstrakt ist. Und das suckt.

    0
  • ?

    kingruedi schrieb:

    Korbinian schrieb:

    kingruedi schrieb:

    ...gibt es keine lustigen Sprachfeatures, wie Templates.

    In java 1.5 sind Templates enthalten 🙂 für mich ist Java damit nochmal eine stufe aufgestiegen. nichtdestotrotz sollte man find ich schon genau überlegen, welche sprache man wann einsetzt. jede hat ihre spezifischen vorteile

    Nein! Das sind keine Templates im Sinne von C++.

    Auch das was C# da einführt. Mehr als container<T> kommt da ja eh nicht bei raus und das bezeichne ich nicht als lustiges Sprachfeature *g*

    Jo, die C# Generics sucken sprachtechnisch. 🙂
    In Java kann man feine Sachen machen (die auch in C++ direkt nicht gehen).

    int readSize(Collection<?> x)    // Typparameter beliebig
{
    return x.size();
}

...

readSize(new ArrayList<Integer>());
readSize(new LinkedList<Foo>());

// und sowas ist manchmal auch sehr fein:
int addNumber(Collection<? super Number> x)
{
    x.add(myInt);
    x.add(myDouble);
}

int sumNumbers(Collection<? extends Number> x)   // frisst Collection<Integer>, Collection<Double>, ...   und abgeleitet von Collection natürlich auch.
{
    int sum = 0;

    for( Number n : x )
        sum += n.intValue();

    return sum;
}

    Da sieht man IMHO eines der wesentlichen Unterschiede von Java und C#: C# ist gut geklaut und hat gute eigene Ideen, aber am besten durchdacht ist Java.

    0
  • O

    Selbst wenn man aus beiden Beispielen ganz stumpf templates macht, die alles annehmen, hat man nur in seltenen Fällen Fehler, die über die Compilezeit hinausgehen... das ist jetzt IMHO wirklich Kleinkram 🙂

    0
  • G

    operator void schrieb:

    Selbst wenn man aus beiden Beispielen ganz stumpf templates macht, die alles annehmen, hat man nur in seltenen Fällen Fehler, die über die Compilezeit hinausgehen... das ist jetzt IMHO wirklich Kleinkram 🙂

    Je früher ein Fehler erkannt wird, desto besser, oder? Eine Java-IDE kann dir den Fehler hier schon dann anzeigen, wenn du die Zeile zuende getippt hast. Also weit vor dem Kompiliervorgang. 🙂 Wobei dieses Sprachfeature von Java eigentlich schon vor der Vermeidung von Fehlern interessant wird. Java bietet hier die Möglichkeit, eine bestimmte Art von Informationen formal in der Schnittstelle bekannt zu geben: Die Anforderungen an den Typ. In anderen Sprachen muss man diesbezüglich in der Dokumentation nachsehen oder nichtsprachliche Vereinbarungen, wie zum Beispiel eine bestimmte Namensgebung, einhalten und sich darauf verlassen.

    0
  • A

    Gregor schrieb:

    Eine Java-IDE kann dir den Fehler hier schon dann anzeigen, wenn du die Zeile zuende getippt hast. Also weit vor dem Kompiliervorgang.

    Er kompiliert jedesmal wärend ich was eintippe. Anders kann ich es mir nicht erklären.

    0
  • ?

    Nein, das würde zu lange dauern. Er beschränkt sich dabei bestenfalls auf die aktuelle Übersetzungseinheit und wird keinesfalls Abhängigkeiten zu anderen Klassen testen.
    Ist mir aber nicht ganz klar, was das mit Java direkt zu tun hat. Theoretisch könnte man sowas auch für C++ realisieren (evtl. nur die aktuelle Funktion als Übersetzungsrahmen nehmen). Aber die meisten C++ IDEs sucken einfach hart, lediglich Visual Assist für VS hat mich echt mal zwischenzeitlich begeistert.

    Das muss einfach an der Komplexität der Sprache liegen. Was Java IDEs heute können, ist unglaublich. Man hat manchmal echt das Gefühl, die wissen genau, was du vorhast.

    0
  • S

    Optimizer schrieb:

    Nein, das würde zu lange dauern. Er beschränkt sich dabei bestenfalls auf die aktuelle Übersetzungseinheit und wird keinesfalls Abhängigkeiten zu anderen Klassen testen.
    Ist mir aber nicht ganz klar, was das mit Java direkt zu tun hat. Theoretisch könnte man sowas auch für C++ realisieren (evtl. nur die aktuelle Funktion als Übersetzungsrahmen nehmen). Aber die meisten C++ IDEs sucken einfach hart, lediglich Visual Assist für VS hat mich echt mal zwischenzeitlich begeistert.

    Das muss einfach an der Komplexität der Sprache liegen. Was Java IDEs heute können, ist unglaublich. Man hat manchmal echt das Gefühl, die wissen genau, was du vorhast.

    als c++ progger hat man eher manchmal das gefühl die pfuschen im code rum
    konnt mich noch ned dran gewöhnen

    0
Anmelden zum Antworten