1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › 3D-API fürs Web
  6. Th…

Vielleicht sollte man erst mal JavaScript verbessern...

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2

Neues Thema


  1. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: K.A.I.N. 25.03.09 - 12:27

    CaptainCook schrieb:
    -------------------------------------------------------
    > Ich bezweifle, dass es mehr Leistung kostet.

    In der regel schon. Der vorteil des lokale Kontext steigt mit jeder abgefangen Anfrage an den Lokalen oder Globalen Namensraum.

    > Zur Lesbarkeit: mit 'with' siehst du nicht, ob du
    > globale Variablen definierst oder Member
    > ansprichst:

    Deshalb: Globale Variablen Verbannen und with Reparieren.

    Ein Punkt als Zugriff für den Lokalen Kontext ist eigentlich pflicht.

  2. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: K.A.I.N. 25.03.09 - 12:28

    Hello_World schrieb:
    -------------------------------------------------------
    > Dynamische Typisierung bringt
    > *keinerlei* Vorteile, dafür aber sehr viel
    > schlechtere Performance und höhere
    > Fehleranfälligkeit. Typinferenz, parametrischer
    > Polymorphismus und virtuelle Funktionsaufrufe (und
    > evtl. multiple dispatch) reichen aus, um alle
    > Vorteile zu erreichen, die dynamische Typisierung
    > angeblich bietet.

    Dummes Gewäsch.

  3. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: Hello_World 25.03.09 - 12:35

    Dieser überzeugenden Argumentation habe ich natürlich nichts entgegenzusetzen. Geh sterben...

  4. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: None 25.03.09 - 12:45

    Nicht nur verbessern, sondern durch eine Sprache wie Java oder C# ersetzen.
    Vorteil:
    Code wird native auf Zielplattform kompiliert,
    Code ist normalerweise nicht im Klartext lesbar und manipulierbar,
    Läuft in JEDEM Browser gleich ab.

    Deshalb gehen Flash, Silverlight und JavaFX in die richtige Richtung!
    Da wäre dann auch 3D-Unterstützung kein Problem mehr....

  5. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: ProggerHogger 25.03.09 - 13:02

    Hello_World schrieb:
    -------------------------------------------------------
    > Dummes Gewäsch.

    Dämliche Einleitung für überholte, altbackene, ewig gestrige Behauptungen.

    > Dynamische Typisierung bringt
    > *keinerlei* Vorteile, dafür aber sehr viel
    > schlechtere Performance und

    Diese Aussage wird derzeit durch einige Projekte grundlegend widerlegt: SquirrelFish Extreme, V8 und PyPy weisen eindeutig nach, dass dynamische Typisierung in einer intelligenten Laufzeitumgebung zu keinerlei Performance-Verlusten führen muss. Ist der Laufzeitumgebung der Code nach mehreren Durchgängen und/oder eingehender Prüfung hinreichend bekannt, braucht keine Typenprüfung mehr stattfinden, da viele der verwendeten Variablen auch in dynamisch typisiertem Code ihren Typ nicht ändern. Für den kleinen Rest, bei dem Typenprüfung nötig ist, ergeben sich keine Geschwindigkeitsvorteile für statische Sprachen gegenüber Dynamischen, wobei Dynamische ihren Vorteil in Code-Umfang und um Größenordnungen geringerer Entwicklungszeit ausspielen können.

    > höhere
    > Fehleranfälligkeit.

    Dies ist eine akademische Behauptung, die immer mal wieder angebracht wird, allerdings nicht im geringsten beweisbar ist. Die Realität straft diese Aussage Lügen: Objective-C und auch Python Programme gehören nachweislich zu den stabilsten Programmen der Industrie. Python z.B. wird von Wissenschaftlern sehr gern als Glue-Language in aufwändigen wissenschaftlichen Berechnungen eingesetzt und verkürzt in diesem Anwendungsfall die Entwicklungszeit erheblich, während die Fehlertoleranz und -häufigkeit stark reduziert wird.

    > Typinferenz, parametrischer
    > Polymorphismus und virtuelle Funktionsaufrufe (und
    > evtl. multiple dispatch) reichen aus, um alle
    > Vorteile zu erreichen, die dynamische Typisierung
    > angeblich bietet.

    Die Zukunft wird Laufzeitumgebungen für dynamische Sprachen bringen, die an die Performance von statisch Typisierten heranreicht und diese später auch hinter sich lassen wird. Eine Maschine muss, schon theoretisch, besser sein als ein Mensch im optimieren von Code, was bereits heute von diversen VMs bewiesen wird

  6. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: K.A.I.N. 25.03.09 - 13:08

    Ich hab nur versucht dein Niveau zu halten. Leider komm ich dann doch nicht so Tief, also überlass ich das Parkett doch lieber wieder dir. Mit Zombies vertrag ich mich wohl dich nicht so ganz :-P

  7. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: ProggerHogger 25.03.09 - 13:14

    None schrieb:
    -------------------------------------------------------
    > Nicht nur verbessern, sondern durch eine Sprache
    > wie Java oder C# ersetzen.
    > Vorteil:
    > Code wird native auf Zielplattform kompiliert,

    Das ist kein Vorteil, nur ein Nachteil bei der Entwicklung.

    > Code ist normalerweise nicht im Klartext lesbar
    > und manipulierbar,

    Ist er auch jetzt nicht. Nur weil Code lesbar ist, ist er noch lange nicht manipulierbar. Der wahre Grund ist: Leute wie du schämen sich ihren Code vorzuzeigen, weil er so mies ist, oder sehen selbst in den marginalsten Schnipseln eine überzogene geistige Höhe aus der heraus sie diesen als schützenswert ansehen. ich habe in meinem Leben noch keinen nicht ersetzbaren Code gesehen. Optimaler geht in 99 % immer.

    > Läuft in JEDEM Browser gleich ab.

    Akademische Behauptung, die allein von .NET und Mono bereits zur genüge widerlegt wird.

    > Deshalb gehen Flash, Silverlight und JavaFX in die
    > richtige Richtung!

    Falsch. Alle 3 sind Totgeburten.

    > Da wäre dann auch 3D-Unterstützung kein Problem
    > mehr....

    Das hat rein garnichts mit der verwendeten Laufzeitumgebung zu tun. Guter JS-Code in einer modernen Umgebung kann durchaus schnell sein.

  8. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: godfatehr 25.03.09 - 13:29

    None schrieb:
    -------------------------------------------------------
    > Nicht nur verbessern, sondern durch eine Sprache
    > wie Java oder C# ersetzen.
    > Vorteil:
    > Code wird native auf Zielplattform kompiliert,

    JavaScript wird doch seit neuestem und in Zukunft auch native auf die Zielplattform kompiliert.

    Und von der Sprache selbst sind C# und Java eher unflexibler als das von Grund auf funktionale JavaScript.

  9. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: ProggerHogger 25.03.09 - 13:36

    Vollkommen richtig. Aber von Funktionaler Programmierung sollte man gegenüber C# oder Java Menschen lieber nicht erst anfange. Da kommen dann Sprüche ähnlich: Unsere Sprache ist da bereits weiter, denn sie ist objektorientiert ...

  10. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: Streuner 25.03.09 - 13:40

    Was ist an JavaScript Funktional?

  11. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: ProggerHogger 25.03.09 - 13:43

    http://de.wikipedia.org/wiki/JavaScript#Funktionales_Programmieren

  12. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: Streuner 25.03.09 - 13:51

    Also Schmalspur-Funktional.

  13. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: ProggerHogger 25.03.09 - 13:59

    Es muss nicht die volle "Lispischness“ unterstützt werden, um eine brauchbare Sprache zu erhalten. Allerdings ist JavaScript um Größenordnungen "lispischer", als Java oder C#.

  14. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: meinDönerbud 25.03.09 - 15:38

    > var meineVariable=2;
    > meinVariable=3;
    >
    > Was steht jetzt in meineVariable? Das meine ich
    > mit Tippfehler.

    2

    Nach ca. einem Jahr Gehirnwäsche findest auch du Javascript geil.




  15. Typinterferenz, parametrischer Polytheismus, multiple virtual Patch

    Autor: B!ngo 25.03.09 - 15:56

    Hello_World schrieb:
    -------------------------------------------------------
    > ProggerHogger schrieb:
    > --------------------------------------------------
    > -----
    > > Braucht niemand, nirgendwo in keiner Sprache!
    > Als
    > Option für mehr Performance OK, aber
    > generell eher
    > ein Rückschritt.
    > Dummes Gewäsch. Dynamische Typisierung bringt
    > *keinerlei* Vorteile, dafür aber sehr viel
    > schlechtere Performance und höhere
    > Fehleranfälligkeit. Typinferenz, parametrischer
    > Polymorphismus und virtuelle Funktionsaufrufe (und
    > evtl. multiple dispatch) reichen aus, um alle
    > Vorteile zu erreichen, die dynamische Typisierung
    > angeblich bietet.

    In welchem oberschlauen Javabuch standen diese coolen Buzzwords denn ? Respekt, du bist bestimmt ein echtes Genie.

  16. Re: Typinterferenz, parametrischer Polytheismus, multiple virtual Patch

    Autor: Hello_World 25.03.09 - 17:17

    B!ngo schrieb:
    -------------------------------------------------------
    > In welchem oberschlauen Javabuch standen diese
    > coolen Buzzwords denn ?
    In keinem, da Java weder multiple dispatch noch Typinferenz beherrscht und die Möglichkeiten für parametrischen Polymorphismus in Java extrem eingeschränkt sind.

  17. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: vize 25.03.09 - 17:30

    Sacht mal Jungs, kann das sein dass ich euch kenne? Euer Gewäsch kommt mir so bekannt vor...

    XD

  18. Re: Vielleicht sollte man erst mal JavaScript verbessern...

    Autor: Hello_World 25.03.09 - 20:25

    ProggerHogger schrieb:
    -------------------------------------------------------
    > Diese Aussage wird derzeit durch einige Projekte
    > grundlegend widerlegt: SquirrelFish Extreme, V8
    > und PyPy weisen eindeutig nach, dass dynamische
    > Typisierung in einer intelligenten
    > Laufzeitumgebung zu keinerlei
    > Performance-Verlusten führen muss.
    Ach. Die Benchmarks (hier mal exemplarisch Tracemonkey gegen Java 6) sprechen aber eine andere Sprache.
    http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=tracemonkey&lang2=java&box=1
    Wie man sieht ist auch Tracemonkey noch viele Faktoren langsamer als Java.
    > Dies ist eine akademische Behauptung, die immer
    > mal wieder angebracht wird, allerdings nicht im
    > geringsten beweisbar ist.
    Das ist sogar sehr einfach zu beweisen. Spätestens zur Laufzeit finden die Typüberprüfungen nämlich sowieso statt, unabhängig davon ob die Sprache dynamisch oder statisch typisiert ist. Typfehler können also bei dynamisch typisierten Sprachen zur Laufzeit auftreten und bei statisch typisierten nicht.
    > Die Realität straft
    > diese Aussage Lügen: Objective-C und auch Python
    > Programme gehören nachweislich zu den stabilsten
    > Programmen der Industrie.
    Das ist kein Beweis, denn man kann in jeder Sprache sowohl gute als auch schlechte Software schreiben. Klar, wenn man die Produktivität von Python mit der von Java vergleicht, ist klar dass Java verliert. Aber daraus kann man nicht schließen, dass dynamische Typisierung an sich produktiver ist. Ich wüsste auch keinen Grund dafür, warum das der Fall sein sollte, schließlich muss man sich z. B. bei Python auch über die Typen der Elemente klar sein.
    > Python z.B. wird von
    > Wissenschaftlern sehr gern als Glue-Language in
    > aufwändigen wissenschaftlichen Berechnungen
    > eingesetzt und verkürzt in diesem Anwendungsfall
    > die Entwicklungszeit erheblich,
    Die Entwicklungszeit im Verleich zu was? Ich glaube, Du kennst nur einfach keine guten statisch typisierten Sprachen.
    > während die
    > Fehlertoleranz und -häufigkeit stark reduziert
    > wird.

    > > Typinferenz, parametrischer
    >
    > Polymorphismus und virtuelle Funktionsaufrufe
    > (und
    > evtl. multiple dispatch) reichen aus, um
    > alle
    > Vorteile zu erreichen, die dynamische
    > Typisierung
    > angeblich bietet.
    >
    > Die Zukunft wird Laufzeitumgebungen für dynamische
    > Sprachen bringen, die an die Performance von
    > statisch Typisierten heranreicht und diese später
    > auch hinter sich lassen wird.
    Wie viele VMs hast Du denn schon geschrieben, dass Du das so genau beurteilen kannst? Moderne VMs sind schön und gut, aber zaubern können sie nicht.
    > Eine Maschine muss,
    > schon theoretisch, besser sein als ein Mensch im
    > optimieren von Code,
    Nochmal: auch eine moderne VM kann nicht zaubern. Wenn ich 100 Strings mit einen String statt einem StringBuilder konkateniere, dann kann auch die beste VM nichts ausrichten. Genauso wenig kann eine VM sich ein schlaueres Locking-Protokoll ausdenken.
    > was bereits heute von
    > diversen VMs bewiesen wird
    Ach, und welche sollen das sein? Nenn mir mal eine dynamisch typisierte Sprache, die schnelleren Code als bspw. Fortran erzeugt. Nicht einmal das bekanntlich statisch typisierte Java kommt da mit.



    1 mal bearbeitet, zuletzt am 25.03.09 20:30 durch Hello_World.

  1. Thema
  1. 1
  2. 2

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Team-Leiter:in (w/m/d) für die Informations- und Kommunikationstechnik
    Hochschule Aalen, Aalen
  2. DevOps Software Engineer im Bereich "Software Factory" (m/w / divers)
    Continental AG, Frankfurt
  3. Software Architect - Data Infrastructure (m/f/d)
    Advantest Europe GmbH, Böblingen
  4. SAP Basis Administrator (m/w/x)
    über duerenhoff GmbH, Raum Karlsruhe, Remote

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 106,39€ als Vorbestellung (Vergleichspreis 163,89€, ebenfalls vorbestellbar)
  2. 59€ (Vergleichspreis 72€)
  3. 29,99€ (Preis-Tipp!)
  4. (u. a. Kingston A400 240 GB für 17,50€ und 480 GB für 32€ statt 27,10€/37,97€ im...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Solarenergiespeicher Bluetti EP500 Pro: Wie ich versuchte, autark zu werden
Solarenergiespeicher Bluetti EP500 Pro
Wie ich versuchte, autark zu werden

Ich vermesse per Drohne, schleppe Solarpanels und eine 83-kg-Powerstation, drucke Abstandshalter im 3D-Drucker - und spare Stromkosten. Zudem berechne ich, ob und wann sich die Ausgaben für die Anlage amortisieren.
Ein Erfahrungsbericht von Thomas Ell

  1. Fotovoltaik Solarzellen werden billiger und grüner
  2. Umweltschutz Swiss tankt bald klimaneutrales Kerosin
  3. Saubere Energie Strom aus dem Gewächshaus

Star-Wars-Fandom: Die neue Wertschätzung und die alte Toxizität
Star-Wars-Fandom
Die neue Wertschätzung und die alte Toxizität

Ãœber den toxischen Zustand des Star-Wars-Fandoms wird viel geschrieben, doch wie hat es angefangen? Ende des letzten Jahrtausends und unter medialer Beteiligung.
Von Peter Osteried

  1. James Earl Jones Darth Vader gibt seine Stimme an ukrainisches Unternehmen ab
  2. Andor Folge 1 bis 3 rezensiert Ein bisschen Blade Runner in Star Wars
  3. Macht und Marvel Disney will Spiele mit Star Wars und Superhelden zeigen

Return to Monkey Island angespielt: Schön, mal wieder hier zu sein
Return to Monkey Island angespielt
Schön, mal wieder hier zu sein

Guybrush Threepwood ist zurück - und mit ihm sein Erfinder Ron Gilbert. Aber ist das neue Monkey Island auch so gut wie seine Vorgänger?
Eine Rezension von Daniel Ziegener

  1. Boox Mira im Test Ein Display wie aus Papier