-
Ganz schlechte Idee
Autor: zilti 04.05.10 - 15:00
Soweit kommts noch. Da baut man besser eine JVM ein. Da laufen schliesslich deutlich mehr Sprachen drauf.
...Wie? Jemand dagegen? Eben.
Schlussendlich behindert es >IMO< den Wettbewerb, sowas in den Browser einzubauen. Für genau sowas gibt es Plugins. Es wäre besser, die Plugin-Schnittstelle zu überarbeiten, um eine bessere Integration von Plugins in den Browser zu ermöglichen.
Dadurch ist es möglich, neue Technologien schnell und browserunabhängig zu etablieren. -
Re: Ganz schlechte Idee
Autor: Himmerlarschundzwirn 04.05.10 - 15:04
Der FF mutiert aber zusehends zum Deppenbrowser, wie da ein Plugin installiert wird, wissen viele gar nicht. Und die kriegen dann das heulen, wenn da steht "Für diese Webseite brauchst du das Plugin XYZ" Dann lieber hardcoden...
-
Re: Ganz schlechte Idee
Autor: SeveQ - unterwegs 04.05.10 - 15:16
zilti schrieb:
--------------------------------------------------------------------------------
> Soweit kommts noch. Da baut man besser eine JVM ein. Da laufen schliesslich
> deutlich mehr Sprachen drauf.
> ...Wie? Jemand dagegen? Eben.
> Schlussendlich behindert es >IMO< den Wettbewerb, sowas in den Browser
> einzubauen. Für genau sowas gibt es Plugins. Es wäre besser, die
> Plugin-Schnittstelle zu überarbeiten, um eine bessere Integration von
> Plugins in den Browser zu ermöglichen.
> Dadurch ist es möglich, neue Technologien schnell und browserunabhängig zu
> etablieren.
Und weshalb ist es dann eine schlechte Idee, die CLI in Firefox/Chrome zu integrieren? Ich hab manchmal den Eindruck, manche Leute kriegen Schnappatmung, sobald sie nur "Microsoft" oder eines seiner Produkte hören. Dabei tun das auch nur genau die, die noch nie mit C# programmiert haben.
Ich bin der Ansicht, es gibt kaum eine bessere Laufzeitumgebung. Schade, dass sie nur aufgrund ihres als proprietär verschrienen Rufs so schlecht angenommen wird. Dabei ist sie das gar nicht; proprietär. Für vieles außerhalb Windows gibt es Mono, in Windows selbst ist sie integriert.
Die Java Runtime finde ich viel schlimmer. -
Re: Ganz schlechte Idee
Autor: nille02 04.05.10 - 15:39
SeveQ - unterwegs schrieb:
--------------------------------------------------------------------------------
> Ich bin der Ansicht, es gibt kaum eine bessere Laufzeitumgebung. Schade,
> dass sie nur aufgrund ihres als proprietär verschrienen Rufs so schlecht
> angenommen wird. Dabei ist sie das gar nicht; proprietär. Für vieles
> außerhalb Windows gibt es Mono, in Windows selbst ist sie integriert.
>
> Die Java Runtime finde ich viel schlimmer.
So einfach ist das halt nicht. Und wie du selber sagst gehst du auch an diese Sache nicht Unparteiisch ran. Zu jeder Technik gibt es Kritikpunkte und Mono muss halt mit dem Microsoft Stigma leben. -
Re: Ganz schlechte Idee
Autor: zilti 04.05.10 - 16:01
Siehst du, da haben wir genau das, was ich angesprochen habe: Der Eine will dieses, der Andere jenes. Es bremst nun mal den Wettbewerb aus, etwas in den Browser zu integrieren - und bei eigentlichen Desktoptechnologien wie JavaSE, .NET, AIR ist das ein Problem.
Wieso die JRE schlimmer sein sollte sehe ich nicht. Die JRE ist performancetechnisch gesehen afaik ungeschlagen, und alles Andere ist sowieso Sache der Programmiersprache und des Compilers. -
Re: Ganz schlechte Idee
Autor: newschool 04.05.10 - 16:03
zilti schrieb:
--------------------------------------------------------------------------------
> Soweit kommts noch. Da baut man besser eine JVM ein. Da laufen schliesslich
> deutlich mehr Sprachen drauf.
> ...Wie? Jemand dagegen? Eben.
> Schlussendlich behindert es >IMO< den Wettbewerb, sowas in den Browser
> einzubauen. Für genau sowas gibt es Plugins. Es wäre besser, die
> Plugin-Schnittstelle zu überarbeiten, um eine bessere Integration von
> Plugins in den Browser zu ermöglichen.
> Dadurch ist es möglich, neue Technologien schnell und browserunabhängig zu
> etablieren.
Ähm, hab ich da jetzt was falsch verstanden?
JVM (Java Virtual Machine) unterstützt als Sprache, nunja, Java!
.NET bzw. CLI (= CLS + CLR + DLR seit .NET 4) unterstüzt C#, VB, F#, IronPython, IronRuby bzw. eine ganze Litarnei an Sprachen die sich an die CLS halten (siehe http://de.wikipedia.org/wiki/Liste_von_.NET-Sprachen).
Außerdem ist die CLI wie im Artikel erwähnt durch die ECMA standardisiert (genauso wie JavaScript, oft auch als ECMAScript bezeichnet) und offen, was den Wettbewerb keinesfalls irgendwie behindert. Es gibt ja, wie oben schon erwähnt, CLI bzw. NET auch schon für Linux in Form von Mono, das hat nichts mehr mit dem veraltetem Microsoft-Internet-Macht-Gehabe zu tun.
Microsoft hat es nunmal durch seine Erfahrung (jawohl, das haben die zwangsläufig) und auch finanzielle Kraft, welche auch für die Forschung verwendet wird, geschafft eine gute und durchdachte Spezifikation zur Vereinheitlichung von Programmiersprachen und deren Ausführung ins Leben zu rufen, die von JEDEM verwendbar und implementierbar ist.
Ich bin in den wenigsten Hinsichten ein M$-Fan, aber .NET und auch die CLI sind imho einfach nur sehr gut geworden!
Und nun noch mehr Plugins zu entwickeln finde ich eine schlechte Idee, da damit das Versions- und Installationschaos wie aktuell bei Flash und Silverlight nur vergrößert wird und es weiterhin keine Einheitlichkeit bei der Entwicklung fürs Web bzw. den Browser gibt, obwohl eben schon sehr gute Standards und Spezifikationen vorhanden wären.
Einfach das Rad noch sechs-mal erfinden und dann trotzdem mitm Schlitten fahren ;-) -
Re: Ganz schlechte Idee
Autor: BildschirmMensch 04.05.10 - 16:12
Auf der JVM laufen auch einige weitere Sprachen wie Scala und Groovy, ein Python gibt es afair auch. Und in der Tat steht die JVM performancetechnisch oft besser dar. Wenn es nach mir ginge, sollte man nicht versuchen allzuviel SchnickSchnack in das Browserfenster einbauen, nur weil das technisch möglich ist. 3D-Multimedia-Klimbim sollte IMO ausgelagert werden, in eine Form wie sie z.B. Java Webstart bietet.
-
Re: Ganz schlechte Idee
Autor: nille02 04.05.10 - 16:17
Alles nur Theoretisch richtig, aber die die Realität sieht anders aus.
-
Offtopic: Embedding mono
Autor: andres_ich 04.05.10 - 17:24
Hat schonmal jemand versucht Mono in seine Anwendung einzubetten? Weis jemand wie groß die laufzeitumgebung ist, wieviel ram die braucht?
-
Re: Ganz schlechte Idee
Autor: fliegenklatsche 04.05.10 - 18:19
nille02 schrieb:
--------------------------------------------------------------------------------
> So einfach ist das halt nicht. Und wie du selber sagst gehst du auch an
> diese Sache nicht Unparteiisch ran. Zu jeder Technik gibt es Kritikpunkte
> und Mono muss halt mit dem Microsoft Stigma leben.
Ausserdem schwingt über dem Mono Projekt immer noch die dunkle Patentkeule von Microsoft.
Überall brav den Mono-Dreck rein und dann... klatsch -
Re: Ganz schlechte Idee
Autor: Ritter von NI 04.05.10 - 19:03
fliegenklatsche schrieb:
--------------------------------------------------------------------------------
> Ausserdem schwingt über dem Mono Projekt immer noch die dunkle Patentkeule
> von Microsoft.
> Überall brav den Mono-Dreck rein und dann... klatsch
Schwachsinn. Auch wenn man es tausend mal behauptet wird es nicht richtig. Das einzige, was Probleme geben KÖNNTE, ist ADO.Net und ASP.Net. -
Re: Ganz schlechte Idee
Autor: bhdhdhd 04.05.10 - 19:29
ogottogott, die c#-entwickler fangen an zu glauben c# sei nicht proprietär. Gefährliche sache ist das, vorallem im web...
aber rein technisch ne schöne sprache ja. Leider aber nicht zu empfehlen... -
Re: Ganz schlechte Idee
Autor: TheUndeadable 04.05.10 - 19:52
> Hat schonmal jemand versucht Mono in seine Anwendung
> einzubetten? Weis jemand wie groß die laufzeitumgebung ist,
> wieviel ram die braucht?
http://www.mono-project.com/Embedding_Mono
http://www.mono-project.com/Small_footprint
"The most basic mono install currently takes about 3.7 MB of disk space, this includes about 1.7 MB for the JIT and 2 MB for mscorlib.dll.
The runtime memory requirements depend on how complex the target application is. A simple application will be happy with 2 MB of writable memory for the mono process itself and 5 MB of readonly shared memory for the mmapped libraries and assemblies. At this time we suggest that the minimum system memory is 32 MB, though of course mono can be run in less memory, the total depends on the applications that run on the system.
" -
^ LÜGNER ^
Autor: LügnerEntlarver 04.05.10 - 21:07
newschool schrieb:
--------------------------------------------------------------------------------
> ...
> JVM (Java Virtual Machine) unterstützt als Sprache, nunja, Java!
FALSCH!
Jgnat, Jawk, Railo, BlueDragon, CLforJava, Jatha, Gardens Point Component Pascal, Rhino, jLogo, xLogo, Kahlua, Jill, Canterbury Oberon-2 for JVM, OCaml-Java, Canterbury Pascal for JVM, IBM WebSphere sMash PHP (P8), Caucho Quercus, Jython, IBM NetRexx, JRuby, Bigloo, Kawa, SISC, JScheme, Jacl, Alef++, AspectJ, Duby, E programming language, Fantom, Flow Java, Frink, Fortress, Hecl, loke, Jaskell, Join Java, Jelly, Joy, Judoscript, N.A.M.E. Basic, NetLogo, Nice, Noop, ObjectScript, Pizza, Pnuts, CAL, Sleep, V programming language, X10, Yeti
Zudem ist die CLR lächerlich langsam gegen eine Server-Hotspot mit eingeschalteter Runtime-Optimization. Die frisst deine Kinder-CLR zum Frühstück! -
Re: ^ LÜGNER ^
Autor: Der müde Joe 04.05.10 - 22:33
An den LügenEntlarver-Troll: Blöd Behauptungen aufstellen kann jeder das hat wohl nichts mit Entlarven zu tun.
Wenn Du schon große Sprüche in den Raum wirfst dass die CLR lächerlich langsam gegen die JVM sei solltest du das auch belegen können. Und bitte keine Studiumsprojekte (die sind nämlich nicht aussagekräftig, ich hab Bachelor/Master/Dr. ich weiss es, nur zur Info), wenn dann schon Anwendungen mit hoher Last, großem Datenmodell etc etc Anwendungen? Server? Auslastung? Außerdem zeugen solche Pauschalaussagen von wenig Hintergrundwissen zur Thematik.
Genauso juckt es niemand welche Sprachen auf der JVM/CLR laufen wenn es um Performance geht, ist am Ende alles Bytecode (ist klar oder?), für die JVM sind i.A. nur Java, Scala, Groovy und vll JRuby und Clojure interessant, der Rest spielt effektiv keine Rolle, genauso gibt es Dutzende Compiler für die CLR (deren Namen ich nicht aufzähle weil ich sie nicht alle kenne wozu auch wen juckt das?).
Wenn man Java entwickelt und von .NET und z.B. ASP.NET keine Ahnung hat wird natürlich jede Anwendung in Java schneller sein als .NET, der typische Anfängerfehler in ASP.NET ist DataSet im Viewstate etc. etc.
Ich würde mich jederzeit auf eine Wette einlassen dass ich -jede- Anwendung die Du mit J2EE und Konsorten entwickelst (und die tausendmal schneller als die CLR ist) auf der gleichen Hardware in .NET mit gleicher Geschwindigkeit konzipieren würde, wenn man .NET Profi ist weiß man worauf es ankommt (genauso wie J2EE-Leute das bei sich wissen).
Ein .NET Senior Architect -
Re: Ganz schlechte Idee
Autor: SeveQ 04.05.10 - 22:52
bhdhdhd schrieb:
--------------------------------------------------------------------------------
> ogottogott, die c#-entwickler fangen an zu glauben c# sei nicht proprietär.
> Gefährliche sache ist das, vorallem im web...
>
> aber rein technisch ne schöne sprache ja. Leider aber nicht zu empfehlen...
... nämlich weil... ? Was ist denn an einer Programmiersprache wichtiger als die "technische" Seite, die jawohl Les- und Wartbarkeit primär beinhaltet? -
Re: ^ LÜGNER ^
Autor: Java Senior Professor Architekt 05.05.10 - 00:40
Ich bin Java Senior Professor Doktor Architekt Manager Profi und weiß worauf es ankommt. Du schreibst Blödsinn. Solche Leute wie du trauen sich meistens dann sogar noch ihre dümmlichen Performance-Vergleiche auf dem Spielebootloader-OS Windows anzuschleppen, um sich dann vollends als "Profi" zu outen ...
-
Re: Ganz schlechte Idee
Autor: xx xxxxx 05.05.10 - 07:52
Die Frage ist, ob er die CLS oder wirklich die CLI meint. Die CLS ist soweit plattformunabhängig. Bei der CLI ist Windows Forms etc mit drin.. was natürlich nicht frei, offen und propritär ist. Allerdings auch Steve Jobs idiologie verfolgt und damit optimiert für Windows ist.
-
Re: ^ LÜGNER ^
Autor: xxx - xxx 05.05.10 - 07:59
sehr profesionelle Antwort, Respekt !!!
-
Re: ^ LÜGNER ^
Autor: IrgendEinAnderer 05.05.10 - 09:13
Deine Aussagen sind in mehrfacher hinsicht blödsinn.
Zum einen unterstützt die JVM zwar einige weitere Sprache, doch wird das in der PRaxis nicht verwendet - nicht zuletzt deshalb wei die JVM so spezifisch ist, dass eigentlich jede Sprache zu JAVA wird, wenn sie unter der JVM läuft. Das ist beim .NET-Framework nicht so.
Zum zweiten bringt das .NET-Framework einen Ahead-of-Time-Compiler mit (http://en.wikipedia.org/wiki/Native_Image_Generator), dabei dird der CLI-Code in maschinenabhängigen Code compiliert, der jeden JIT-Compiler überlegen ist.



