1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › OpenProj 1.0 - Freie Alternative zu…
  6. Thema

Java ....

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Gerne doch

    Autor: Chilli 15.01.08 - 19:40

    Hello_World schrieb:
    -------------------------------------------------------

    > Autsch. Von Komplexitätstheorie labern, aber den
    > Unterschied zwischen linear und konstant nicht
    > verstanden haben...
    Uhm, da fehlt ein 'steigend' .... und das 'weniger' sollte eigentlich 'mehr' sein. Was anderes geschrieben als gedacht ....

    > Solche Behauptungen muss man beweisen, wenn man
    > sie in die Welt setzt. Zeig uns Code und ein paar
    > Benchmarks, dann reden wir weiter.

    Ich habe hier mal etwas:
    http://www.spoj.pl/ULM_05/problems/main/
    Ergebnisse des ACM Kontests. Und dann geh bei einer Aufgabe auf best solutions. Und diese Leute sind teilweise absolute freaks und werden nicht umsonst die Sprache wählen die dort allgemein am besten abschneidet. Die Quellcodes lassen sich leider nicht einsehen, sonst könnte man ja die Lösungen für Übungsaufgaben kopieren.

    > Davon abgesehen
    > mag es ja sein, dass C-Anwendungen oft etwas
    > schneller sind. Es geht aber nicht darum, wer am
    > schnellsten ist, sondern darum, wer das beste
    > Gesamtpaket abliefert. In Java können eine Menge
    > Fehler, die in C regelmäßig gemacht werden,
    > einfach nicht vorkommen (Memory Leaks, double
    > frees usw. usf.), und das kommt der Stabilität
    > zugute. In C++ ist das allerdings halbwegs
    > beherrschbar.

    Ich habe auch nicht das Gesamtpaket angeprangert. Ich habe doch im vorherigen Post geschrieben, was ich von Java an sich vorteilhaft finde. Ich würde ein Großprojekt auch kaum in C schreiben. Zumindest mit meiner jetzigen Erfahrung noch nicht.

    > Gut, Java benötigt mehr Speicher als C oder C++. Das gilt aber für jede Sprache mit GC.
    Unzwar deutlich mehr ... und wenn es in den Swap geht dann wirds lustig ....
    Aber eine Frage habe ich: Ist ein GC nicht eben dazu gedacht die Speicherkomplexität zu verringern? Mit GC hab ich mich noch nie wirklich beschäftigt.

    > Bullshit.
    Muss man gleich vulgär werden?

    > Wenn man nicht gerade '\\' anstelle von
    > File.separator verwendet usw., dann ist Java
    > extrem portabel.

    Einfacher Java Code ist extrem portabel. Aber es wird allgemein so getan als hätte man grenzenlose Plattformunabhängigkeit. Was meinst du welches Chaos Swing verursacht hat, als wir ein Projekt von Windows/Linux nach Mac OS X portiert haben ... Hier kann dir eine ganze Gruppe bestätigen, dass das ein Trugschluss ist, also alles andere als - wie du so schön schreibst - 'bullshit'.

    > Es gibt genug Beispiele, die zeigen, dass man mit
    > Java sehr gute Performance erreichen kann, z. B.
    > Jake2.

    Du musst nichtmal konkrete Programme nennen. Zb das Lösen numerischer Probleme läuft in Java schneller als teilweise sogar in C (!), da die Erzeugung von Objekten in der VM wahnsinnig schnell abläuft. Und genau da hat - was Geschwindigkeit angeht - Java zumindest gewisse Stärken. Daher sage ich auch nicht Java sei grundsätzlich langsamer.

    > Aber gerade bei einer Projektmanagementsoftware
    > ist Performance einfach nicht das zentrale
    > Kriterium. Das Teil soll in erster Linie
    > zuverlässig sein.

    Das sicherlich. Die Software mag ja auch ganz ok sein. Aber neben der oben genannten Quelle als recht handfestes Argument spielt einfach - auch wenn es paar nicht wahr haben wollen - das subjektive Empfinden eine tragende Rolle. Und Java Software tendiert so gut wie immer so wahnsinnig Träge zu sein, dass auch die tollste Theorie nicht mehr überzeugt. Und das ist nicht von der Hand zu weisen. Zumindest noch nicht.

    > Dein Ursprungsbeitrag war ja auch einfach nur
    > dämlich und trollig.

    Ansischtsache. Man hat lust ernsthaft zu provozieren wenn man über etwas nicht begeistert ist. Picassos Gemälde werden auch nicht als Trollerei bezeichnet.


  2. Re: Java ....

    Autor: Chilli 15.01.08 - 19:46

    Golubrum schrieb:

    > Das sagst du vermutlich schon seit 10 Jahren - und
    > dementsprechend ist dein Wissensstand über Java
    > auch 10 Jahre alt. Das Programm vermag sicherlich
    > keine Geschwindigkeitsrekorde aufzustellen, man
    > kann damit aber (auf meinem 5 Jahre alten Rechner)
    > sehr angenehm arbeiten und merkt keinen
    > Unterschied zu Programmen vergleichbarer
    > Komplexität, die in C oder C++ geschrieben sind.


    Nicht ganz. Eher seit kurz vor 1.6 und ich habe seitdem nichts mehr in Java gemacht.

    Es gibt zB ein Schriferstellungsprogramm in Java (ich weiß den Namen nicht mehr) und FontForge und die Unterschiede sind eklatant.

    Das Beispiel alleine ist kein Problem. Das Problem ist, dass es eines von vielen ist.

  3. Re: Gerne doch

    Autor: GrinderFX 15.01.08 - 23:44

    Was nutzt es dir, wenn du ein guibasierendes programm hast, wo kaum berechnungen von nöten sind und java dort wahnsinnig langsam im verhältnis zu sprachen wie c/c++ ist?

    Da kannst du weiterhin anpreisen, dass java in berechnungen genauso schnell ist wie c/c++, es machts nur nicht besser.

  4. Re: Ja habe ich

    Autor: DrAgOnTuX 16.01.08 - 00:38

    Chilli schrieb:
    -------------------------------------------------------
    > .. aber ich bin zu faul ;P
    >

    Dann beschwer dich nicht ;)

  5. Re: Gerne doch

    Autor: Hello_World 16.01.08 - 03:14

    Chilli schrieb:
    -------------------------------------------------------
    > Unzwar deutlich mehr ... und wenn es in den Swap
    > geht dann wirds lustig ....
    So what? Speicher ist heute billig. Ich habe zwei GB, von denen laut htop nichtmal 600 MB genutzt werden. Was interessiert's mich da, ob eine Applikation jetzt 50 oder 100 MB belegt?
    > Aber eine Frage habe ich: Ist ein GC nicht eben
    > dazu gedacht die Speicherkomplexität zu
    > verringern? Mit GC hab ich mich noch nie wirklich
    > beschäftigt.
    GC ist in erster Linie dazu da, den Programmierer von der manuellen Speicherverwaltung zu entlasten.
    Dass Programme mit GC idR. mehr Speicher verbrauchen als die ohne, ist aber ganz logisch. Bei Sprachen ohne GC wird der Speicher freigegeben, sobald er nicht mehr benötigt wird. Bei Sprachen mit GC wird er erst dann freigegeben, wenn der GC gerade mal Lust dazu hat, also werden Objekte idR. länger auf dem Heap behalten als nötig. Bei Java kommen dann noch Sachen wie Reflection hinzu.
    > Einfacher Java Code ist extrem portabel. Aber es
    > wird allgemein so getan als hätte man grenzenlose
    > Plattformunabhängigkeit. Was meinst du welches
    > Chaos Swing verursacht hat, als wir ein Projekt
    > von Windows/Linux nach Mac OS X portiert haben ...
    Bitte mal konkrete Beispiele bringen.
    > Das sicherlich. Die Software mag ja auch ganz ok
    > sein. Aber neben der oben genannten Quelle als
    > recht handfestes Argument spielt einfach - auch
    > wenn es paar nicht wahr haben wollen - das
    > subjektive Empfinden eine tragende Rolle. Und Java
    > Software tendiert so gut wie immer so wahnsinnig
    > Träge zu sein, dass auch die tollste Theorie nicht
    > mehr überzeugt. Und das ist nicht von der Hand zu
    > weisen. Zumindest noch nicht.
    Oh doch, ist es. Ich verwende zwar derzeit keine Java-Software (da ich keine Verwendung dafür habe), aber wenn ich mir z. B. die Swing-Demos anschaue (http://java.sun.com/products/jfc/jws/SwingSet2.jnlp), dann erscheinen die mir auf jeden Fall hinreichend performant. Dir nicht?
    > Ansischtsache.
    Nö, nicht wirklich.

  6. Re: Gerne doch

    Autor: Chilli 16.01.08 - 09:07

    Hello_World schrieb:
    -------------------------------------------------------
    > So what? Speicher ist heute billig. Ich habe zwei
    > GB, von denen laut htop nichtmal 600 MB genutzt
    > werden. Was interessiert's mich da, ob eine
    > Applikation jetzt 50 oder 100 MB belegt?

    EEK!
    Sag das einem Numeriker ... der dreht dir den Hals um! Und noch vor nicht all zu langer Zeit war das zB mit meinem ibook G4 mit 256 MB Ram sehr wohl ein Problem ...

    > Dass Programme mit GC idR. mehr Speicher
    > verbrauchen als die ohne, ist aber ganz logisch.
    > Bei Sprachen ohne GC wird der Speicher
    > freigegeben, sobald er nicht mehr benötigt wird.
    > Bei Sprachen mit GC wird er erst dann freigegeben,
    > wenn der GC gerade mal Lust dazu hat, also werden
    > Objekte idR. länger auf dem Heap behalten als
    > nötig. Bei Java kommen dann noch Sachen wie
    > Reflection hinzu.
    ok.

    > Bitte mal konkrete Beispiele bringen.
    Ich weiß dass dich das nicht zufriedenstellen wird, aber für eine Forumsbetrag ist es mir zuviel 25000 Zeilen Javacode, den wir vor Jahren geschrieben haben nach Fehlerursachen zu finden. Und auch das reicht nicht, da ich mein ibook schon ein ganzes Weilchen nicht mehr habe und mir daher die Testumgebung fehlt.
    Probleme bereiteten zB Tabellen die unter Linux/Windows liefen, jedoch unter Mac OS X in der Darstellung komplett kaputt waren. Falls du in Java entwickelst, 1.5 parat hast und irgendwo ein Mac OS X rumläuft, kannst du es gerne versuchen.


    > Oh doch, ist es. Ich verwende zwar derzeit keine
    > Java-Software (da ich keine Verwendung dafür
    > habe), aber wenn ich mir z. B. die Swing-Demos
    > anschaue
    > (http://java.sun.com/products/jfc/jws/SwingSet2.jn
    > lp), dann erscheinen die mir auf jeden Fall
    > hinreichend performant. Dir nicht?

    Ich kenne die schon, aber na ja Demos ... 100 zu 1000 Zeilen machen sich da schon irgendwann sehr wohl bemerkbar. Die Demos an sich sind schöne Swing Beispiele die auch von der Performance her einen guten Eindruck machen. Jedoch standen sie verglichen mit C bzw. C++ Pendants immer nach. Und i.A. stieg der kleine Unterschied mit der Größe des Projekts. Wenn man das damalige Sopra bei dem 31 5er bzw. 6er Gruppen ein Projekt entweder in C++ oder in Java schreiben sollten, als großen Feldversuch betrachtet ist die Aussagekraft nunmal irgendwann unabstreitbar da.

    > Nö, nicht wirklich.
    POV :)

  7. Re: Gerne doch

    Autor: Hello_World 17.01.08 - 03:07

    Chilli schrieb:
    -------------------------------------------------------
    > EEK!
    > Sag das einem Numeriker ... der dreht dir den Hals
    > um!
    Tja, deswegen gibt's für Numerik Fortran :). Es gibt keine Programmiersprache, die für alles ideal ist.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. MEA Service GmbH, Aichach
  2. Hays AG, Coburg
  3. Bundesanstalt für Immobilienaufgaben, Berlin
  4. Hochschule Albstadt-Sigmaringen, Albstadt

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 48,99€
  2. 69,99€
  3. (-62%) 18,99€
  4. (-70%) 2,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Alternatives Android im Test: /e/ will Google ersetzen
Alternatives Android im Test
/e/ will Google ersetzen

Wie Google, nur mit Privatsphäre - /e/ verbindet ein alternatives Android mit Cloudfunktionen und einer Suchmaschine.
Ein Test von Moritz Tremmel


    Coronavirus: Spiele statt Schule
    Coronavirus
    Spiele statt Schule

    Wer wegen des Coronavirus mit Kindern zu Hause ist, braucht einen spannenden Zeitvertreib. Unser Autor - selbst Vater - findet: Computerspiele können ein sinnvolles Angebot sein. Vorausgesetzt, man wählt die richtigen.
    Von Rainer Sigl

    1. CCC "Contact Tracing als Risikotechnologie"
    2. Coronapandemie Robert Koch-Institut sammelt Gesundheitsdaten von Sportuhren
    3. Google Chrome rollt Regeln für Same-Site-Cookies vorerst zurück

    Buglas: Corona-Pandemie zeigt Notwendigkeit der Glasfaser
    Buglas
    Corona-Pandemie zeigt Notwendigkeit der Glasfaser

    Mehr Datenupload und Zunahme der Sprachtelefonie bringe die Netze unter Druck. FTTB/H-Betreiber bleiben gelassen.
    Eine Exklusivmeldung von Achim Sawall

    1. Coronavirus Österreich diskutiert verpflichtendes Tracking
    2. Coronavirus Funktion zur Netflix-Drosselung war längst geplant
    3. Coronakrise China will Elektroautoquote vorübergehend lockern