Scriptsprache der Zukunft?

Daaron schrieb:
Du lässt für Feedly also "die Hosen runter"? Wo bleibt da deine Parano... äh dein Sicherheitsbewusstsein? Oder gehst du da nur mit ner LiveCD drauf, mit abgeklemmten Festplatten?

Was die feedly-Javascripts machen, habe ich höchstselbst überprüft. Da bleibt mein Sicherheitsbewusstsein.

Daaron schrieb:
Und auch wenn Content > Design, so sorgen optische Aufheller und Spielereien für einen verbesserten Lesefluss.

Optische Aufheller gehen mit CSS, jegliche Animation lenkt nachweislich vom Inhalt ab.

Daaron schrieb:
Angenommen, du würdest einen Blog über Webentwicklung lesen... wie nützlich soll der Teil über CSS3 sein, wenn er keine Bildergalerie enthält, die das Zeug gleich illustriert?

Schon mal was von Demos gehört? SelfHTML zum Beispiel kommt fast ohne Screenshots aus.

Daaron schrieb:
Und dann sind da noch so Dinge, die die Lesbarkeit wirklich signifikant positiv beeinflussen. Da wäre z.B. Hyphenator zu nennen.

Blödsinn, da:

Daaron schrieb:
Da kaum ein Browser CSS3-Hyphenation kann

Welcher leidlich aktuelle Browser beherrscht (ob mit oder ohne Vendor-Präfix) keine Hyphens? Nach meiner Erfahrung bleiben da nicht viele.

Daaron schrieb:
Zeitungen (v.a. Tageszeitungen) schreiben ihre Artikel doch nicht aus Spaß an der Freude in enge Spalten.

Enge Spalten stören die Lesbarkeit. Jedenfalls für mich.

Daaron schrieb:
Es gibt so etwas wie eine optimale Zeilenlänge, alles darüber belastet den Leser unnötig. Da CSS3-Multicolumns noch nicht wirlich soweit sind -> JS-Fallback.

Das ging schon lange vor CSS3.

Daaron schrieb:
Ich nehm lieber Mootools... und nu?

Unterschied? Riesiges JavaScript, das erst mal geladen und gerendert werden muss.

Daaron schrieb:
Diese Frameworks vereinfachen den Entwicklungsprozess.

Für Leute, die Webseiten lieber zusammenklicken als entwickeln, mag das gut sein. Die Vielzahl an Frameworks ist aber überhaupt erst entstanden, weil Modularität etwas ist, was "die Leute" offenbar überfordert. "Haben ja alle dicke Leitungen heute". Mobilgeräte nicht, aber warum sollte man das auch berücksichtigen?

Nutz' mal deine Mootools zum Beispiel sinnvoll mit Opera Mini (nein, das ist keine Nischen-app). Viel Erfolg.

Daaron schrieb:
CSS3 ist kein ERSATZ für JS

Mit CSS3 kannst du vieles tun, wofür du wahrscheinlich lieber ein weiteres 30-KB-Javascript einfügen würdest, du Usability-Null.

Daaron schrieb:
CSS kann z.B. kein 100% Touch-kompatibles Suckerfish-Menü erzeugen

JavaScript auch nicht, da mobile Browser und JavaScript einander nur bedingt tolerieren (siehe Opera Mini).

Daaron schrieb:
Weil es SCHNELL ist... unter anderem.

Java und schnell halte ich ja für einen naturgegebenen Widerspruch. Alles, wofür erst 'ne fette VM gestartet werden muss, kann danach "schnell" sein - die Initialisierungszeit ist definitiv pfui. Ich habe übrigens noch keine Web-Java-Anwendung gesehen, die in PHP nicht eleganter umsetzbar gewesen wäre.

BWL, Erstsemester, wissenschon.
 
Tuxman schrieb:
Was die feedly-Javascripts machen, habe ich höchstselbst überprüft. Da bleibt mein Sicherheitsbewusstsein.
Du hast überprüft, was sie zum Zeitpunkt X machen! Es ist ja nicht so, dass Feedly keine Entwickler hat, die an dem Projekt arbeiten... Die beiden JavaScript-Dateien von Feedly wurden innerhalb der letzten 24h geändert, die eine aktuell vor 3h und die andere vor 23,5 Stunden.
Da werden bei größeren Projekten wie Feedly täglich mit dem CI-Server automatisiert dutzende Änderungen gepusht, was du irgendwann mal nachgesehen hast, ist nicht von Relevanz.
Für deine Paranoia: Feedly könnte auch gehackt worden sein und liefert jetzt ein Malware verseuchtes JavaScript aus, das wäre nicht das erste mal, also vom Konzept her, das gabs schon in genug Fällen mit eingeschleusten Java Applets.
Aber da deiner Meinung nach die JavaScript-Interpreter so unsicher sind, muss es ja nicht einmal ein Java Applet sein, simples JS reicht ja...

Tuxman schrieb:
Alles, wofür erst 'ne fette VM gestartet werden muss, kann danach "schnell" sein - die Initialisierungszeit ist definitiv pfui.
Die Initialisierungszeit stört ja auch sowas von, wenn ich die VM Monate am Stück laufen lasse... Einmal starten und mit OSGI zur Laufzeit Teile der Anwendung austauschen.
 
ice-breaker schrieb:
Feedly könnte auch gehackt worden sein und liefert jetzt ein Malware verseuchtes JavaScript aus, das wäre nicht das erste mal, also vom Konzept her, das gabs schon in genug Fällen mit eingeschleusten Java Applets.

Ich habe aus genau diesem Grund kein Java in meinem Browser. Schön aber, dass ich nicht der Einzige hier bin, der die Problematik beim Scripting erkennt. Leider ist noch kein ausgereifter Offline-Feedly-Client verfügbar.

ice-breaker schrieb:
Die Initialisierungszeit stört ja auch sowas von, wenn ich die VM Monate am Stück laufen lasse... Einmal starten und mit OSGI zur Laufzeit Teile der Anwendung austauschen.

Schon mal einen Server betrieben?
 
Ich will nur mal anmerken, dass das Lesen in dieser Runde hier Genuss pur ist. :D
Eine bessere Abendlektüre gibt es fast nicht. Weitermachen bitte :P
 
Tuxman schrieb:
Was die feedly-Javascripts machen, habe ich höchstselbst überprüft. Da bleibt mein Sicherheitsbewusstsein.
...bei jedem Mal, wenn du n Cache Refresh machst, weil n neues Release raus is? Sicher nicht...

Optische Aufheller gehen mit CSS, jegliche Animation lenkt nachweislich vom Inhalt ab.
Animationen gehen mit CSS3 recht gut.... Soviel dazu, also.
Und was z.B. an einem Tab, Akkordeon oder einer Lightbox jetzt vom Inhalt ablenkt versteh ich immer noch nicht. Die Dinger helfen, den Inhalt strukturierter wahrzunehmen und ihn performanter zu laden.

Schon mal was von Demos gehört? SelfHTML zum Beispiel kommt fast ohne Screenshots aus.
Was nutzt dir deine Demo, wenn dein Browser den Kram nicht kann? Ich les auch gern mal, was so alles in Nightly Builds möglich ist, oder nur in spezifischen Browsern (v.a. Chrome). Was machst du mit deinem FF, wenn der CSS-Trick aktuell nur in Webkit geht? Na?

Genau dafür gibts Screenshots.
Und SelfHTML ist, genau wie du, ein Relikt der 90er.

Welcher leidlich aktuelle Browser beherrscht (ob mit oder ohne Vendor-Präfix) keine Hyphens? Nach meiner Erfahrung bleiben da nicht viele.
Alle Webkit-Browser, dazu Opera, IE<10, und IE Mobile (also Windows Phone)

*Usage stats: Global
Support: 35.67%

Jegliche Form von CSS Hyphens ist nutzlos.


Enge Spalten stören die Lesbarkeit. Jedenfalls für mich.
Dann bist du ein Sonderfall. Viele viele clevere Wissenschaftler haben erwiesen, dass kürzere Teilen das Textverständnis erleichtern.
http://www.art-of-web-usability.de/Wordpress/wordpress/?p=944

Das ging schon lange vor CSS3.
http://www.w3.org/TR/css3-multicol/

Sabbel nicht. Du machst dich nur noch lächerlicher, als du es bereits getan hast.

Unterschied? Riesiges JavaScript, das erst mal geladen und gerendert werden muss.
Geht schneller, als wegen einem Fitzelchen geändertem Content das gesamte HTML-Dokument neu zu laden. Denn... CACHING!

JavaScript auch nicht, da mobile Browser und JavaScript einander nur bedingt tolerieren (siehe Opera Mini).
Modernizr -> Opera Mini erkannt -> anderes Menü erzeugen...

Java und schnell halte ich ja für einen naturgegebenen Widerspruch. Alles, wofür erst 'ne fette VM gestartet werden muss, kann danach "schnell" sein - die Initialisierungszeit ist definitiv pfui.
Da der entsprechende Dienst nicht 20x in der Minute neu startet... Who cares?
Ein Java Servlet ist verdammt flott. Dass die Initialisierung eben 2-3 Sekunden dauert kümmert gar nicht.
 
Daaron schrieb:
Animationen gehen mit CSS3 recht gut....

Korrekt, und sie stören.

Daaron schrieb:
Was nutzt dir deine Demo, wenn dein Browser den Kram nicht kann?

Webentwickler, die Code basteln, der nicht unter jedem Browser funktioniert, gehören erschossen.

Daaron schrieb:
Und SelfHTML ist, genau wie du, ein Relikt der 90er.

Kannst du eigentlich mal irgendein Argument vorbringen, ohne mein Alter zu kritisieren? (Tatsächlich bin ich etwas älter.) Was im Übrigen falsch daran ist, auf bewährte Technik zu setzen, weiß ich nicht. JavaScript ist auch ein Relikt der 90er.

Daaron schrieb:
Dann bist du ein Sonderfall.

Damit musst du wohl leben.

Daaron schrieb:
Viele viele clevere Wissenschaftler haben erwiesen, dass (bla).

"Amerikanische Forscher haben herausgefunden, dass..."

Daaron schrieb:
http://www.w3.org/TR/css3-multicol/

Sabbel nicht. Du machst dich nur noch lächerlicher, als du es bereits getan hast.

Was genau hat CSS3-Multicol mit den älteren, bestehenden Techniken zu tun?

Den Preis für Lächerlichkeit geb' ich gern zurück. Informiere dich bitte, bevor du versuchst mit Wissen zu glänzen. So funktioniert das nicht.

Daaron schrieb:
Geht schneller, als wegen einem Fitzelchen geändertem Content das gesamte HTML-Dokument neu zu laden. Denn... CACHING!

BROWSERABHÄNGIG! NICHT DEFINIERTE KONSTANTE! ZOMG!!1einself

Nie benutzt, hm?
(Dass Caching dynamischen "content" oft eher stört, sei nebenbei angemerkt.)

Daaron schrieb:
Modernizr -> Opera Mini erkannt -> anderes Menü erzeugen...

Opera Mini wird das trotzdem nicht laden. Bitte verwende eine Software erst mal, bevor du Handlungsempfehlungen auf sie bezogen aussprichst.
 
Tuxman schrieb:
Java und schnell halte ich ja für einen naturgegebenen Widerspruch.

Java fährt immer noch Kreise um Skriptsprachen.

Tuxman schrieb:
die Initialisierungszeit ist definitiv pfui.

Und spielt hier welche Rolle?

Tuxman schrieb:
(Dass Caching dynamischen "content" oft eher stört, sei nebenbei angemerkt.)

JS ist kein dynamischer Content. Und selbst, wenn man wöchentlich was am Code ändert, kann man allen Problemen durch Versionierung im Dateinamen aus dem Weg gehen.
 
Zuletzt bearbeitet:
Tuxman schrieb:
Webentwickler, die Code basteln, der nicht unter jedem Browser funktioniert, gehören erschossen.
Webentwickler, die heute schon lernen, was morgen verfügbar ist, gucken übermorgen nicht wie die Kuh wenns blitzt.

Als die ersten Spezifikationen für CSS Shadows, Rounded Borders, RGBA,... auftauchten... Du hast das Zeug wohl als Hexenwerk gleich verbrannt, hm? Sowas wird frühestens in 20 Jahren Standard. Bis dahin nutzen alle noch schwarze Schrift auf weißem Bildschirm, am besten mit blinkende Cursorzeile oben links....

Was genau hat CSS3-Multicol mit den älteren, bestehenden Techniken zu tun?
Was? <div>-Suppe als Multicolumn? Vielleicht ne YAML-Struktur?
Oh, wenn du verschiedene unabhängige Container sortieren willst ist das gut. Wenn du hingegen einen zusammenhängenden Fließtext (und davon sprach ich) in Spalten teilen willst, dann geht das nur mit der CSS3-Version. Alles andere zerstört den syntaktischen Zusammenhang des Textes und versaut dir damit die Maschinenlesbarkeit.

Gratuliere, du hast soeben etwas gelernt. Darfst diese Information gern behalten....

(Dass Caching dynamischen "content" oft eher stört, sei nebenbei angemerkt.)
Nur bei schlechten Webentwicklern....
 
Daaron schrieb:
Als die ersten Spezifikationen für CSS Shadows, Rounded Borders, RGBA,... auftauchten... Du hast das Zeug wohl als Hexenwerk gleich verbrannt, hm?

Mitnichten, mein WordPress macht reichlich Gebrauch davon. Und ich komme gänzlich ohne extern eingebundenes (= nicht überprüftes) JavaScript aus. Hui! CSS ist halt keine potenzielle Sicherheitslücke, wenn man nicht gerade url() benutzt.

Daaron schrieb:
Bis dahin nutzen alle noch schwarze Schrift auf weißem Bildschirm, am besten mit blinkende Cursorzeile oben links....

Damit ist man gelegentlich deutlich flinker unterwegs als mit Mausschubserei. Frage mich immer noch (ein bisschen neidisch), wieso (und seitens wessen) einige Entwickler heutzutage anscheinend für's Mausschubsen und nicht für's Codeschreiben bezahlt werden.

Daaron schrieb:
Was? <div>-Suppe als Multicolumn?

Was is'n an float mit 'ner anständigen Breitenangabe 'ne "Suppe"?
 
Tuxman schrieb:
Mitnichten, mein WordPress macht reichlich Gebrauch davon. Und ich komme gänzlich ohne extern eingebundenes (= nicht überprüftes) JavaScript aus. Hui! CSS ist halt keine potenzielle Sicherheitslücke, wenn man nicht gerade url() benutzt.
Uuuuuhhh. Wordpress. Die wandelnde Sicherheitslücke. Ein "CMS", dass jedes Quartal mehr kritische Lücken fixen muss, als in den guten CMS in 4-5 Jahren aufgetaucht sind.

Übrigens ist JS auch sicher, wenn man nicht....
Und da CSS3 turing-vollständig ist, kannst du mit CSS3 theoretisch richtig Schindluder treiben.

Was is'n an float mit 'ner anständigen Breitenangabe 'ne "Suppe"?
3 Spalten, 3 Divs? Clever... Was machst du, wenn dein Bildschirm schmaler wird und nur noch 2 Spalten sinnvoll sind? Was machst du bei breiterer Darstellung, wo 4 Spalten sinnig sind?
Und wie sorgst du für den semantischen Zusammenhang?

Du hast schon von Semantik und der Bedeutung eines semantischen Netzes gehört, oder?

Also nach all dem, was ich bisher von dir gelesen hab: Die armen Schweine, die zu deinen Kunden gehören, verdienen unser aller Mitleid.
 
Tuxman schrieb:
ice-breaker schrieb:
Die Initialisierungszeit stört ja auch sowas von, wenn ich die VM Monate am Stück laufen lasse... Einmal starten und mit OSGI zur Laufzeit Teile der Anwendung austauschen.

Schon mal einen Server betrieben?
achso eure Putzfrau zieht bei den Servern täglich den Stecker so dass die Server keine Monate am Stück laufen? Pardon, wusste ich nicht. Selbst dann ist die Startzeit absolut irrelevant...


Und was die nicht belegte Aussage von dcobra angeht, dass Java Kreise um jede der Scriptsprachen zieht:
http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.php
Tada! Du kannst auch gerne die Sprachen dann im Detail vergleichen, es ist ein Fakt.

Java war mal in den 90er unendlich lahm, seitdem hat sich viel getan, so wie mit dem Web. Oh... Ich verstehe... Jetzt wird mir vieles klar... :lol:
 
Daaron schrieb:
Uuuuuhhh. Wordpress. Die wandelnde Sicherheitslücke.

Nenn' mir ein sicheres Blogsystem ohne störenden Portalsumms außenrum und ich werde es nutzen.
(Fangfrage. Es gibt kein sicheres Blogsystem. Wahrscheinlich hat sogar Fefes Blog 'ne Lücke.)

Daaron schrieb:
Und da CSS3 turing-vollständig ist, kannst du mit CSS3 theoretisch richtig Schindluder treiben.

Könnte ich, aber warum sollte ich das auf meinem Server tun wollen?

Daaron schrieb:
Du hast schon von Semantik und der Bedeutung eines semantischen Netzes gehört, oder?

Jö - Totgeburt.

Daaron schrieb:
Also nach all dem, was ich bisher von dir gelesen hab: Die armen Schweine, die zu deinen Kunden gehören, verdienen unser aller Mitleid.

*tätschel*

Meine Kunden waren bisher oft Behörden. Denen muss man nix erklären. Die finden nicht mal den Startknopf.
Ergänzung ()

ice-breaker schrieb:
Und was die nicht belegte Aussage von dcobra angeht, dass Java Kreise um jede der Scriptsprachen zieht:
http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.php
Tada! Du kannst auch gerne die Sprachen dann im Detail vergleichen, es ist ein Fakt.

Wie zu erwarten: Java gerade mal mittelmäßig.

Und nun?

Java ist eben auch so eine Hypesprache, die zu schlechtem Code erzieht. Warum man das wollen sollte, weiß ich nicht (PHP kann auch Bytecode und Caching, huiii, wurde im Test ganz offensichtlich beides nicht eingesetzt) - aber so, wie die Sache aussieht, sind Scala und C wohl die bessere Wahl.
 
Zuletzt bearbeitet:
Tuxman schrieb:
Nenn' mir ein sicheres Blogsystem ohne störenden Portalsumms außenrum und ich werde es nutzen.
(Fangfrage. Es gibt kein sicheres Blogsystem. Wahrscheinlich hat sogar Fefes Blog 'ne Lücke.)
Ich habe nichts von bombensicher gesagt. Sogar ein 100% selbst geschriebenes System wird hackbar sein.
WP ist nur eben BESONDERS löchrig. Also gerade ein Fanatiker wie du sollte das Problem erkennen und Konsequenzen ziehen...

Falsch. Dein vorgeschlagenes Splitten der Inhalte in mehrere <div>s würde die Indizierbarkeit für Suchmaschinen stark verschlechtern.

Und wie nützlich erweiterte Semantik, z.B. per OpenGraph oder Schema.org, ist, konnte ich an einem unserer Shopsysteme aktuell selbst erleben. Die Qualität und Quantität der Suchergebnisse hat sich signifikant verbessert.

Wie zu erwarten: Java gerade mal mittelmäßig.
Java ist deutlich schneller als alle Scriptsprachen. Das war die Behauptung und hier ist der Beweis.

Caching bei PHP bringts übrigens nur, wenn dasselbe Script mehrfach ausgeführt wird, da hier vor allem I/O-Ops wegfallen. Wenn du ein sehr komplexes einzelnes Programm (z.B. die Berechung eines Mandelbrots) ausführst sieht die Sache gaaaanz anders aus. Da bringen Tricks wie APC gar nix. Hier ist es sogar egal, ob du PHP-CLI verwendest oder modPHP.

Java ist signifikant schneller als PHP. Das war dei Aussage, und die ist nun einmal wahr.

aber so, wie die Sache aussieht, sind Scala und C wohl die bessere Wahl.
Wie überraschend. Der vom C-Compiler erzeugte Maschinencode ist die schnellste Lösung. Totale Neuerung... Wenn in der Liste jetzt noch ASM drin gewesen wär, dann würdest du Webseiten mit ASM schreiben, hm?

Es ist EGAL, ob C udn Scala schneller sind. Es geht darum, was praktisch verwendbar ist. Eine C-basierte Webanwendung müsste ihren eigenen HTTP-Server darstellen (außer, du gehst über CGI). Das ist entweder sehr aufwändig oder sehr langsam. So oder so,e s kostet Zeit und Geld. Für Java Servlets gibts mit Tomcat eine standardisierte Fire&Forget - Lösung. Da verhält sich (vereinfacht gesagt) dein Servlet nicht viel anders als ein PHP-Script gegenüber nem Apache oder IIS. Analog dazu kannst du eine C# - Anwendung relativ einfach in einen bestehenden IIS integrieren.

Einfachheit und Portabilität bringen Profit.
 
Daaron schrieb:
WP ist nur eben BESONDERS löchrig.

Kann man mit Plugins absichern. Ist zwar dann ein ziemlicher Flickenteppich, aber hey, das ist Linux auch. :D

Daaron schrieb:
Java ist deutlich schneller als alle Scriptsprachen.

C ist deutlich schneller als Java. Tschüss, Java?

Daaron schrieb:
Wenn du ein sehr komplexes einzelnes Programm (z.B. die Berechung eines Mandelbrots) ausführst sieht die Sache gaaaanz anders aus.

Berechne mal 'n Mandelbrot mit Java. Ist auch alles andere als blitzschnell.

Daaron schrieb:
Wie überraschend. Der vom C-Compiler erzeugte Maschinencode ist die schnellste Lösung. Totale Neuerung... Wenn in der Liste jetzt noch ASM drin gewesen wär, dann würdest du Webseiten mit ASM schreiben, hm?

Nee, zu komplex. Im Gegensatz zu C übrigens.
Java bietet exakt null Vorteile gegenüber C (meinethalben C++). Verstehe Leute nicht, die das nutzen. Aber ist halt gerade im Trend wie damals COBOL.

Daaron schrieb:
Es ist EGAL, ob C udn Scala schneller sind. Es geht darum, was praktisch verwendbar ist. Eine C-basierte Webanwendung müsste ihren eigenen HTTP-Server darstellen (außer, du gehst über CGI).

'n Portlistener ist ja auch furchtbar kompliziert, das machen irgendwelche Klappstühle heutzutage sogar in JavaScript, das ja nun wirklich alles andere als skalierbar ist.

Daaron schrieb:
Für Java Servlets gibts mit Tomcat eine standardisierte Fire&Forget - Lösung.

Eine von mindestens 3 (Tomcat, JBoss, Glassfish). Hui, Standards.
Wo Java portabler sein soll als C, das nun wirklich auf jedem Krüppelsystem läuft, muss mir auch erst mal wer zeigen.
 
Tuxman schrieb:

Ich wollte hier eigentlich nichts mehr schreiben, aber an deinem Post tut alles weh :freak:

Skriptsprachen haben, wenn überhaupt, einen Bytecode-Cache. Bytecode ist das, was bei Java bereits beim Kompilieren hinten rausfällt. Was die JVM aber macht, ist die teilweise Erzeugung und Wiederverwendung von Maschinencode. Das ist eine ganze Ebene weiter. Das kann man bei Skriptsprachen aufgrund der dynamischen Typisierung nun mal nicht, da notwendige Typinformationen erst zur Laufzeit feststehen und sich stets ändern können.

Dann erwähnst du Scala als bessere Alternative, was aber selbst in der JVM läuft, musste gut schmunzeln. Die performancetechnischen Unterschiede zwischen Java und Scala sind marginal und situationsbedingt.

Was denkst du außerdem, warum es JRuby, JPython, IronPython und Co. gibt?

Java erzieht zu schlechtem Code, aber PHP ist in Ordnung?

edit:

Java bietet exakt null Vorteile gegenüber C (meinethalben C++).

:D
 
Zuletzt bearbeitet:
carom schrieb:
Ich wollte hier eigentlich nichts mehr schreiben, aber an deinem Post tut alles weh :freak:

Nicht weinen, Mami ist ja hier.

carom schrieb:
Skriptsprachen haben, wenn überhaupt, einen Bytecode-Cache. Bytecode ist das, was bei Java bereits beim Kompilieren hinten rausfällt. Was Javas Hotspot aber macht, ist die teilweise Erzeugung und Wiederverwendung von Maschinencode.

Och.

carom schrieb:
Dann erwähnst du Scala als bessere Alternative, was aber selbst in der JVM läuft, musste gut schmunzeln.

Technisch gesehen läuft auch PHP in 'ner VM, nur eben nicht in 'ner Sandbox. (Ja, das ist Erbsenzählerei, und nein, eine Nebendiskussion hierzu führt gerade nicht weiter.)
Scala ist deutlich performanter - inklusive der VM.

carom schrieb:
Was denkst du außerdem, warum es JRuby, JPython, IronPython und Co. gibt?

Damit irgendwelche Schlipsträger mehr Geld verdienen?

carom schrieb:
Java erzieht zu schlechtem Code, aber PHP ist in Ordnung?

Javaentwickler: eclipse/IntelliJ/NetBeans - Klickklickklickklick - Boilerplate fertig.
PHP-Entwickler: Texteditor auf.

Hm. Ja?

Ach, und lies mal das hier:
http://blog.fefe.de/?ts=b5546b0c
http://blog.fefe.de/?ts=b555be2c
 
Tuxman schrieb:
C ist deutlich schneller als Java. Tschüss, Java?
Wenn du in C so effektiv Backends für Webanwendungen schreiben kannst wie in Java? Ja. Kann man aber nicht, sonst wäre Tomcat nicht so beliebt.
Und weils mit PHP eben noch leichter (aber eben nicht performanter) geht, ist PHP beliebter als Java.

Berechne mal 'n Mandelbrot mit Java. Ist auch alles andere als blitzschnell.
Aber schneller als Ruby, PHP,... Darum gehts.

Java bietet exakt null Vorteile gegenüber C (meinethalben C++). Verstehe Leute nicht, die das nutzen. Aber ist halt gerade im Trend wie damals COBOL.
Ähm... Java ist JETZT ein Trend?
Komisch... Java wird schon seit über 10 Jahren verbreitet an Unis unterrichtet und großflächig für alles Mögliche eingesetzt. Tatsächlich ist Java auf dem absteigenen Ast, bedingt durch die Lücken in den Browserplugins.

Du hast echt das aktuelle Jahrtausend im Winterschlaf zugebracht, oder?

'n Portlistener ist ja auch furchtbar kompliziert, das machen irgendwelche Klappstühle heutzutage sogar in JavaScript, das ja nun wirklich alles andere als skalierbar ist.
Warum sollte JS (du beziehst dich wohl auf Node.JS) nicht skalieren?
Und es gehört eben mehr dazu als ein Port Listener...
Ergänzung ()

Tuxman schrieb:
Damit irgendwelche Schlipsträger mehr Geld verdienen?

JRuby
Erscheinungsjahr: 2002
...
Lizenz: CPL, GPL und LGPL

Verdammte Schlipsträger mit ihrem GPL-Code...

Javaentwickler: eclipse/IntelliJ/NetBeans - Klickklickklickklick - Boilerplate fertig.
PHP-Entwickler: Texteditor auf.
Ich entwickle PHP in Eclipse... Und nu? Andererseits hab ich auch schon Java in Gedit geschrieben.

Sagt GAR NICHTS aus, außer über dich, deine Vorurteile, deine Unzulänglichkeiten....
 
Daaron schrieb:
Wenn du in C so effektiv Backends für Webanwendungen schreiben kannst wie in Java? Ja. Kann man aber nicht, sonst wäre Tomcat nicht so beliebt.

Effektiv != effizient.

Daaron schrieb:
Und weils mit PHP eben noch leichter (aber eben nicht performanter) geht, ist PHP beliebter als Java.

Zeig' mir mal eine PHP-Anwendung, die spürbar langsamer als 'ne vergleichbare Java-Anwendung läuft, nur weil sie in PHP geschrieben ist.

Daaron schrieb:
Ähm... Java ist JETZT ein Trend?

Ja, immer noch.

Daaron schrieb:
Komisch... Java wird schon seit über 10 Jahren verbreitet an Unis unterrichtet

Meist statt C++, was erschreckend ist.

Daaron schrieb:
Tatsächlich ist Java auf dem absteigenen Ast, bedingt durch die Lücken in den Browserplugins.

Auf dem Desktop ja - zum Glück. (Auch, wenn das die Unis noch nicht gemerkt haben.) Aber guck' mal in Richtung mobile Entwicklung.

Daaron schrieb:
Du hast echt das aktuelle Jahrtausend im Winterschlaf zugebracht, oder?

Nicht, dass ich wüsste. Warum?

Daaron schrieb:
Warum sollte JS (du beziehst dich wohl auf Node.JS) nicht skalieren?

Ah, Erbsenzählerei mal wieder. Jede Sprache skaliert, manche halt nur nicht gut.

Daaron schrieb:
Und es gehört eben mehr dazu als ein Port Listener...

Ja, ein Skript, das dem Portlistener Futter gibt. Komplex!
 
Tuxman schrieb:

Und nun? HipHop verfolgt einen aufwendigen Trace-Ansatz und ist damit sehr viel schneller als die üblichen Caches, aber auch HipHop hat keine Glaskugel, was die Typen zur Laufzeit angeht. Das erzeugte C++ ist nichts lineares, was beim Aufruf der Webseite einfach runterrattert, es sind nach wie vor eine Menge Fallunterscheidungen nötig, die von den erst zur Laufzeit bekannten Typen abhängen. dinge, die bei einer statisch typisierten Sprache gar nicht erst anfallen.

Und davon abgesehen ging es hier um die Natur von Skriptsprachen an sich, und nicht um einen exotischen Ansatz wie HipHop.

Tuxman schrieb:
Technisch gesehen läuft auch PHP in 'ner VM

Das ist nicht anzuzweifeln, aber es ist eben etwas ganz anderes. Die VM einer Skriptsprache liest Text von der Platte, erzeugt zur Laufzeit jedesmal Bytecode, führt den Bytecode aus. Kommt ein Cache zum Einsatz, dann fällt die erneute Erzeugung des Bytecodes weg, trotzdem muss dieser immer noch jedesmal in Maschinensprache übersetzt werden.

Bei Java (und auch C# und Co.) hast du aufgrund der Kompilierung von vornherein Bytecode. Die VM führt den Bytecode aus, kann den erhaltenen Maschinencode aber von nun an wiederverwenden.

Tuxman schrieb:
Scala ist deutlich performanter - inklusive der VM.

So ein Quatsch. Wenn du Scala-Code genau so wie Java-Code schreibst und beides durch die JVM jagst, dann wirst du keine Unterschiede feststellen. Schreibst du jedoch richtigen Scala-Code wie man es sollte, dann ist dieser unter Garantie langsamer als Java, auch wenn er nur ein Viertel so lang ist wie das Java-Äquivalent. Dank dem funktionalen Ansatz mit Higher Order Functions und Immutables an allen Stellen und sowieso der ganzen Scala-Bibliothek wird es dem Garbage Collector nicht langweilig werden.

Wenn ein Scala-Programm schneller läuft, dann nur deswegen, weil man nur ein Bruchteil des Javacodes schreiben muss und die gewonnene Zeit in die Optimierung kritischer Sachen stecken kann. Technische Gründe hat dies keine.


Javaentwickler: eclipse/IntelliJ/NetBeans - Klickklickklickklick - Boilerplate fertig.
PHP-Entwickler: Texteditor auf.

Was hat eine IDE mit der Code-Qualität zu tun? durch Refactoring und Content Assist wird da eher höherwertiges dabei rauskommen, als wenn man einen Editor verwendet. Davon abgesehen kannst du Java genau so in einem Editor schreiben wie du PHP in einer IDE schreiben kannst.
 
Zuletzt bearbeitet:
Zurück
Oben