FlauschiBoy schrieb am 19. August 2014 16:04
> also eigentlich hab ich keinen bock darauf zu antworten.
> und finde diese forenrumgetrolle ziemlich dämlich.
> aber irgendwie will ich das dann doch nicht auf mir sitzen lassen.
Ich habe nur meine Erfahrungen/Ansichten geschildert. Traurig, dass
du nicht die nötige Souveränität besitzt damit angemessen umzugehen
und stattdessen persönlich wirst. Auch habe ich dich nicht persönlich
angehen wollen - es gibt nichts, was du aus meinem letzten Beitrag
auf dir sitzen lassen müsstest.
> > Komisch... das macht es bei mir eigentlich nicht. Naja... so
> > 250-300MB RAM (im momentanen Projekt) brauchts bei mir schon, aber
> > VS13 brauchte bei meinem letzten Projekt 400-500MB. Beides unter
>
> also punkt 1.
> meine frisch gestartete instanz von VS2013 hat 39MB im RAM.
>
> die neuste version Eclise LUNA hat frisch gestartet 261MB,
> zusätzlich noch die JAVA.exe mit nochmal 250MB.
So... jetzt mal so prinzipiell zurr Prozesstruktur von Eclipse. Wenn
du die Eclipse.exe startest, startest du ein Mini-Winz-Programm,
welches nichts anderes kann als eine JVM mit dem eigentlichen Eclipse
zu initialisieren. Eclipse.exe braucht selbst kaum mehr als 1MB im
RAM. Die Java.exe braucht mehr. So 250 sind durchaus korrekt. Kanns
sein, dass du irgendeinen Taskmanager verwendest, dessen Ausgaben du
falsch interpretierst? Dass dir z.B. bei eclipse.exe der
Speicherbedarf der Java.exe draufgeschlagen wird (Prozesshierarchie)?
VS2013 benötigt bei mir (OHNE GELADENES PROJEKT) 150 MB. Ich habe
zwar noch Resharper mit drinnen, aber so viel kann der doch auch
nicht zusätzlich fressen. Deine 40MB sind für mich daher absolut
nicht nachvollziehbar.
Und wie gesagt: Wenn ich meine jeweiligen Projekte lade
(vergleichbarer Umfang) komme ich auf die Werte, die ich zuerst
geschrieben habe. Ich arbeite nämlich nicht mit IDEs in denen keine
Projekte geladen sind.
> Aber das wäre jetzt gar nicht mal so schlimm, würdest du
> jetzt nicht JavaFX als das Original und WPF/Xaml als
> die schlechte Kopie verkaufen wollen^^.
Habe ich nie behauptet. Ich habe nur behauptet, dass es vor WPF/XAML
schon andere Technologien gab bei denen die Beschreibung der
Oberfläche von funktionalen Code getrennt wurde.
> JavaFX ist die Antwort auf WPF/Xaml.
> Kaum zu glauben was, ist aber so.
Wie du meinst. Ich würde zwar eher meinen, es war mal Zeit
nachzuziehen für die Java Jungs, weils mittlerweile eine ganze Reihe
an Frameworks gibt, bei denen das so läuft wie bei JavaFX oder
WPF/XAML. Auf jeden Fall haben sie dass ganz akzeptabel hinbekommen.
Auch wenn manches derzeit noch unvollständig ist.
> Und ich hab mir auch auch die Versuche von Oracle angeguckt
> da aus JavaFX noch was zu machen. Bleibt bei Versuchen.
> Aber sie kommen der Sache langsam näher.
Wie du meinst. Ich habe sowohl WPF als auch JavaFX schon
umfangreicher benutzt. Mir gefällt JavaFX besser. Das fängt schon
beim Wysiwyg-Editor an. Der Editor in VS13 ist vieles. Bei VS13 tippe
ich die GUI eigentlich immer direkt in XAML und orientiere mich dabei
etwas an der "Voransicht". Beim JavaFX Scenebuilder gibt es gar keine
Option den XML-Code zu sehen/zu bearbeiten. Braucht man auch nicht.
Funktioniert halt (ok... Version 1.1 war unvollständig und 2.0 lang
im Beta-Status in das zu recht).
> Also ich weiß nicht was das Problem ist.
> Ich arbeite mit beiden Umgebungen.
> Und die Autovervollständigung von VS funktioniert
> sauber und schnell.
Dann frage ich mich in welchem umfang du diese Nutzt. Bzw. bis zu
welchen umfang du dich bei Eclipse damit auseinander gesetzt hast.
> Bei Eclipse geht sie oft gar nicht auf oder blendet sich
> einfach aus.
Ja. Das hatte ich auch schon ein paar wenige Male. Liegt halt oft an
irgendwelchen Plugins von Drittanbietern. Von denen es für Eclipse
unzählige gibt.
> Wie oben schon beschrieben, absoluter Schwachsinn,
> zuerst gab es WPF/Xaml dann JavaFX als schlechte Antwort.
> Guck dir doch die Erscheinungsdaten an.
Was die Erscheinungsdaten angeht, so habe ich niemals etwas
gegenteiliges behauptet. Ansonsten habe ich eigentlich wenig Lust
hier zu Diskutieren wie mit einem radikalen Islamisten über
Religionsfreiheit.
> Die Entwicklung von WPF begann übrigens im Jahr 2000/2001.
> Noch bevor Windows.Forms entwickelt wurde.
>
> Der Quellcode ist OpenSource, da sieht man auch das Datum
> der Quelldateien. Veröffentlichung war 2006.
Der Quellcode zu WPF ist OpenSource?!
> Das Ziel von WPF ist übrigens saubere Trennung von Logik und View.
> Was da jetzt nicht funktioniert weiß ich nicht genau.
Das habe ich doch bereits geschrieben. Muss ich mich wirklich
wiederholen?
VisualStudion erzeugt zu einer XAML-Datei immer auch gleich eine
Quellcode-Datei in der diese geladen wird. Wenn ich die XAML jetzt
aber anders laden will - um das ganze dynamischer zu gestalten muss
ich übelst frickeln: Besonders auf Windows-Phone wo ich eigentlich
auf die Dateistrukturen meines Programmes nicht beliebig einfluss
nehmen kann beginnt dann eine wahre Schlammschlacht. Oder man bleibt
halt einfach innerhalb der Grenzen über welche MS eben auch nicht
hinaus gedacht hat.
> Von der Krücke Java will ich gar nicht erst anfangen,
> denn darauf hab ich nun absolut keinen Bock mehr,
> na gut, nur ein paar Stichpunkte,
Und dann tut ers doch...
> -> Linq, falls du das schon mal gehört hast,
Wie gesagt: Ich kenne beide Welten. Linq kenne ich, habe ich benutzt
und finds ok.
> -> Lambda, seit Java 1.8 enthalten^^ 2014^^ 8 Jahre hat es
> gedauert^^ muss ich dazu noch was sagen
Ja hat lang gedauert. Ist aber meiner Ansicht nach auch was recht
brauchbares dabei rausgekommen. Die Entwicklung der Sprache wird bei
Java halt sehr konservativ betrieben um die maximale
abwärtskompatibilität zu behalten. Das bremst leider oft den
Fortschritt.
> -> unmanaged code^^ wird im leben nicht passieren
? Wofür? JNA? JNI? Warum sollte man unmanaged Code direkt in Java
schreiben wollen?
> achja Checked Exceptions^^ -> Ich möchte bestimmen wo meine
> Exceptions abgefangen werden und sie nicht noch ewig nach oben
> werfen müssen,
ja. Hier scheiden sich die Geister. Ich find das hat zwar durchaus
vorteile, kann man aber auch anders sehen.
Aber zum Thema Exceptions: Hast du schonmal den StackTrace einer
Exception in Java mit dem StackTrace einer Exception in .net
verglichen. Die Informationslage bei .net ist in dem Punkt einfach
nur als "traurig" zu bezeichnen. Das regt mich da immer wahnsinnig
auf.
> -> return ... und danach kommt noch Code, oh gott, das lässt Eclipse
> nicht zu, nicht mal um eine Funktion zu testen,
> könnte ja vergessen werden,
Hat nur glaube ich in dem Fall nichts mit Eclipse zu tun. Sondern mit
dem Java-Compiler. Der mag sowas halt nicht. Kannst aber
"if(true)return;" verwenden. Ist nicht optimal. Ich fänds auch besser
wenn das optional an/abschaltbar wäre, wie das behandelt wird.
> also man kann echt viel behaupten, aber ich rede im gegensatz zu
> vielen anderen in diesem forum nur von dingen, von denen ich mir
> zutraue ahnung zu haben.
Ja selbstverständlich. Du hast die Weisheit in dir. Die Insel der
Erleuchtung.
> vergleiche hier übrigens mit C#
Jap. Ich auch.
> also eigentlich hab ich keinen bock darauf zu antworten.
> und finde diese forenrumgetrolle ziemlich dämlich.
> aber irgendwie will ich das dann doch nicht auf mir sitzen lassen.
Ich habe nur meine Erfahrungen/Ansichten geschildert. Traurig, dass
du nicht die nötige Souveränität besitzt damit angemessen umzugehen
und stattdessen persönlich wirst. Auch habe ich dich nicht persönlich
angehen wollen - es gibt nichts, was du aus meinem letzten Beitrag
auf dir sitzen lassen müsstest.
> > Komisch... das macht es bei mir eigentlich nicht. Naja... so
> > 250-300MB RAM (im momentanen Projekt) brauchts bei mir schon, aber
> > VS13 brauchte bei meinem letzten Projekt 400-500MB. Beides unter
>
> also punkt 1.
> meine frisch gestartete instanz von VS2013 hat 39MB im RAM.
>
> die neuste version Eclise LUNA hat frisch gestartet 261MB,
> zusätzlich noch die JAVA.exe mit nochmal 250MB.
So... jetzt mal so prinzipiell zurr Prozesstruktur von Eclipse. Wenn
du die Eclipse.exe startest, startest du ein Mini-Winz-Programm,
welches nichts anderes kann als eine JVM mit dem eigentlichen Eclipse
zu initialisieren. Eclipse.exe braucht selbst kaum mehr als 1MB im
RAM. Die Java.exe braucht mehr. So 250 sind durchaus korrekt. Kanns
sein, dass du irgendeinen Taskmanager verwendest, dessen Ausgaben du
falsch interpretierst? Dass dir z.B. bei eclipse.exe der
Speicherbedarf der Java.exe draufgeschlagen wird (Prozesshierarchie)?
VS2013 benötigt bei mir (OHNE GELADENES PROJEKT) 150 MB. Ich habe
zwar noch Resharper mit drinnen, aber so viel kann der doch auch
nicht zusätzlich fressen. Deine 40MB sind für mich daher absolut
nicht nachvollziehbar.
Und wie gesagt: Wenn ich meine jeweiligen Projekte lade
(vergleichbarer Umfang) komme ich auf die Werte, die ich zuerst
geschrieben habe. Ich arbeite nämlich nicht mit IDEs in denen keine
Projekte geladen sind.
> Aber das wäre jetzt gar nicht mal so schlimm, würdest du
> jetzt nicht JavaFX als das Original und WPF/Xaml als
> die schlechte Kopie verkaufen wollen^^.
Habe ich nie behauptet. Ich habe nur behauptet, dass es vor WPF/XAML
schon andere Technologien gab bei denen die Beschreibung der
Oberfläche von funktionalen Code getrennt wurde.
> JavaFX ist die Antwort auf WPF/Xaml.
> Kaum zu glauben was, ist aber so.
Wie du meinst. Ich würde zwar eher meinen, es war mal Zeit
nachzuziehen für die Java Jungs, weils mittlerweile eine ganze Reihe
an Frameworks gibt, bei denen das so läuft wie bei JavaFX oder
WPF/XAML. Auf jeden Fall haben sie dass ganz akzeptabel hinbekommen.
Auch wenn manches derzeit noch unvollständig ist.
> Und ich hab mir auch auch die Versuche von Oracle angeguckt
> da aus JavaFX noch was zu machen. Bleibt bei Versuchen.
> Aber sie kommen der Sache langsam näher.
Wie du meinst. Ich habe sowohl WPF als auch JavaFX schon
umfangreicher benutzt. Mir gefällt JavaFX besser. Das fängt schon
beim Wysiwyg-Editor an. Der Editor in VS13 ist vieles. Bei VS13 tippe
ich die GUI eigentlich immer direkt in XAML und orientiere mich dabei
etwas an der "Voransicht". Beim JavaFX Scenebuilder gibt es gar keine
Option den XML-Code zu sehen/zu bearbeiten. Braucht man auch nicht.
Funktioniert halt (ok... Version 1.1 war unvollständig und 2.0 lang
im Beta-Status in das zu recht).
> Also ich weiß nicht was das Problem ist.
> Ich arbeite mit beiden Umgebungen.
> Und die Autovervollständigung von VS funktioniert
> sauber und schnell.
Dann frage ich mich in welchem umfang du diese Nutzt. Bzw. bis zu
welchen umfang du dich bei Eclipse damit auseinander gesetzt hast.
> Bei Eclipse geht sie oft gar nicht auf oder blendet sich
> einfach aus.
Ja. Das hatte ich auch schon ein paar wenige Male. Liegt halt oft an
irgendwelchen Plugins von Drittanbietern. Von denen es für Eclipse
unzählige gibt.
> Wie oben schon beschrieben, absoluter Schwachsinn,
> zuerst gab es WPF/Xaml dann JavaFX als schlechte Antwort.
> Guck dir doch die Erscheinungsdaten an.
Was die Erscheinungsdaten angeht, so habe ich niemals etwas
gegenteiliges behauptet. Ansonsten habe ich eigentlich wenig Lust
hier zu Diskutieren wie mit einem radikalen Islamisten über
Religionsfreiheit.
> Die Entwicklung von WPF begann übrigens im Jahr 2000/2001.
> Noch bevor Windows.Forms entwickelt wurde.
>
> Der Quellcode ist OpenSource, da sieht man auch das Datum
> der Quelldateien. Veröffentlichung war 2006.
Der Quellcode zu WPF ist OpenSource?!
> Das Ziel von WPF ist übrigens saubere Trennung von Logik und View.
> Was da jetzt nicht funktioniert weiß ich nicht genau.
Das habe ich doch bereits geschrieben. Muss ich mich wirklich
wiederholen?
VisualStudion erzeugt zu einer XAML-Datei immer auch gleich eine
Quellcode-Datei in der diese geladen wird. Wenn ich die XAML jetzt
aber anders laden will - um das ganze dynamischer zu gestalten muss
ich übelst frickeln: Besonders auf Windows-Phone wo ich eigentlich
auf die Dateistrukturen meines Programmes nicht beliebig einfluss
nehmen kann beginnt dann eine wahre Schlammschlacht. Oder man bleibt
halt einfach innerhalb der Grenzen über welche MS eben auch nicht
hinaus gedacht hat.
> Von der Krücke Java will ich gar nicht erst anfangen,
> denn darauf hab ich nun absolut keinen Bock mehr,
> na gut, nur ein paar Stichpunkte,
Und dann tut ers doch...
> -> Linq, falls du das schon mal gehört hast,
Wie gesagt: Ich kenne beide Welten. Linq kenne ich, habe ich benutzt
und finds ok.
> -> Lambda, seit Java 1.8 enthalten^^ 2014^^ 8 Jahre hat es
> gedauert^^ muss ich dazu noch was sagen
Ja hat lang gedauert. Ist aber meiner Ansicht nach auch was recht
brauchbares dabei rausgekommen. Die Entwicklung der Sprache wird bei
Java halt sehr konservativ betrieben um die maximale
abwärtskompatibilität zu behalten. Das bremst leider oft den
Fortschritt.
> -> unmanaged code^^ wird im leben nicht passieren
? Wofür? JNA? JNI? Warum sollte man unmanaged Code direkt in Java
schreiben wollen?
> achja Checked Exceptions^^ -> Ich möchte bestimmen wo meine
> Exceptions abgefangen werden und sie nicht noch ewig nach oben
> werfen müssen,
ja. Hier scheiden sich die Geister. Ich find das hat zwar durchaus
vorteile, kann man aber auch anders sehen.
Aber zum Thema Exceptions: Hast du schonmal den StackTrace einer
Exception in Java mit dem StackTrace einer Exception in .net
verglichen. Die Informationslage bei .net ist in dem Punkt einfach
nur als "traurig" zu bezeichnen. Das regt mich da immer wahnsinnig
auf.
> -> return ... und danach kommt noch Code, oh gott, das lässt Eclipse
> nicht zu, nicht mal um eine Funktion zu testen,
> könnte ja vergessen werden,
Hat nur glaube ich in dem Fall nichts mit Eclipse zu tun. Sondern mit
dem Java-Compiler. Der mag sowas halt nicht. Kannst aber
"if(true)return;" verwenden. Ist nicht optimal. Ich fänds auch besser
wenn das optional an/abschaltbar wäre, wie das behandelt wird.
> also man kann echt viel behaupten, aber ich rede im gegensatz zu
> vielen anderen in diesem forum nur von dingen, von denen ich mir
> zutraue ahnung zu haben.
Ja selbstverständlich. Du hast die Weisheit in dir. Die Insel der
Erleuchtung.
> vergleiche hier übrigens mit C#
Jap. Ich auch.