Hallo,
da ich sehr gute Erfahrungen mit Mono unter Linux (PC) gemacht habe,
wollte ich mal Fragen ob Mono schon mal jemand auf'ner dBox versucht
hat und ob das überhaupt möglich ist.
Gruss
Vapo
Mono (.NET) auf dBox ????
-
Vapo
- Neugieriger
- Beiträge: 5
- Registriert: Dienstag 27. Januar 2004, 12:45
-
Vapo
- Neugieriger
- Beiträge: 5
- Registriert: Dienstag 27. Januar 2004, 12:45
-
rasc
- Senior Member
- Beiträge: 5071
- Registriert: Dienstag 18. September 2001, 00:00
-
Vapo
- Neugieriger
- Beiträge: 5
- Registriert: Dienstag 27. Januar 2004, 12:45
-
Npq
- Senior Member
- Beiträge: 1339
- Registriert: Donnerstag 24. April 2003, 12:12
-
rasc
- Senior Member
- Beiträge: 5071
- Registriert: Dienstag 18. September 2001, 00:00
Autsch...
c# ist ein verunglimpftes C++/Java
und VB auf der dbox?
naja, ich ja nix gegen VB (ich kenne es zu genuege....)
Aber VB erzeugt eigentlich ziemlich Overhead und brauchen tut man es in einer embedded Umgebung nicht wirklich, weil alleine eine .net klassen-Library wuerde den Flash der dbox2 schon zumuellen, das nix mehr anderes reinpasst. (...IMO)
eigentlich versucht man in einer embedded Umgebung wie die dbox2, alles so klein wie möglich zu halten und jede Art on Ballast zu entfernen.
VB und .net ist da eher das Gegenteil.
Beispiele?
Guck dir mal die Ausstattung eines Palm-Pilot an und die eine WinCE-Rechner (ich habe beides hier). Der Palm kommt wesentlich performanter und schneller mit weniger Speicher und CPU aus....
c# ist ein verunglimpftes C++/Java
und VB auf der dbox?
naja, ich ja nix gegen VB (ich kenne es zu genuege....)
Aber VB erzeugt eigentlich ziemlich Overhead und brauchen tut man es in einer embedded Umgebung nicht wirklich, weil alleine eine .net klassen-Library wuerde den Flash der dbox2 schon zumuellen, das nix mehr anderes reinpasst. (...IMO)
eigentlich versucht man in einer embedded Umgebung wie die dbox2, alles so klein wie möglich zu halten und jede Art on Ballast zu entfernen.
VB und .net ist da eher das Gegenteil.
Beispiele?
Guck dir mal die Ausstattung eines Palm-Pilot an und die eine WinCE-Rechner (ich habe beides hier). Der Palm kommt wesentlich performanter und schneller mit weniger Speicher und CPU aus....
-
Vapo
- Neugieriger
- Beiträge: 5
- Registriert: Dienstag 27. Januar 2004, 12:45
Also das Letzte was ich wollte, ist wieder eine der nutzlosen Diskussionen über Sinn oder Unsinn von Sprachen, Systemen und Plattformen anzetteln.
Ich glaube auch das, wie Npq schon meint, das rein Ressourcen-technisch schon ein Problem wird.
Interessant wär's aber allemal.
@rasc
VB war nur ein Beispiel. Du weißt sicher auch, das die Sprache bei Dot.NET (beinah) keine Rolle spielt und das VB.NET nahezu nichts mehr mit VB zu tun hat. Und Nein, ich habe schon seit 15 Jahren kein Basic mehr angefasst.
Ob nun C# ein "verunglimpftes C++/Java" ist oder nicht, lasse ich mal unkommentiert, sonst hätten wir genau das, was ich eingangs abgelehnt habe.
Gruss
Vapo
Ich glaube auch das, wie Npq schon meint, das rein Ressourcen-technisch schon ein Problem wird.
Interessant wär's aber allemal.
@rasc
VB war nur ein Beispiel. Du weißt sicher auch, das die Sprache bei Dot.NET (beinah) keine Rolle spielt und das VB.NET nahezu nichts mehr mit VB zu tun hat. Und Nein, ich habe schon seit 15 Jahren kein Basic mehr angefasst.
Ob nun C# ein "verunglimpftes C++/Java" ist oder nicht, lasse ich mal unkommentiert, sonst hätten wir genau das, was ich eingangs abgelehnt habe.
Gruss
Vapo
-
tmbinc
- Developer
- Beiträge: 821
- Registriert: Freitag 20. Juli 2001, 00:00
Ich persönlich recht viel von "modernen" Sprachen wie Java, C#, und zu guter letzt prinzipiell auch Vb.net (vom alten VB selbst halt ich nichts, und wer mit VB.net klarkommt sollte auch mit C# klarkommen, und ich finde die c-styled syntax um einiges besser als basic-styled...)
Was alle diese Sprachen gemeinsam haben, ist dass man, ein ordentliches Framework vorrausgesetzt, nur noch das schreiben muss, was man will, und nicht mehr code schreiben muss für etwas was man nicht will (beispiel: Speicherverwaltung).
Das erkauft man sich allerdings mit einem sehr großen Overhead, den auch JIT oder sonstige techniken nicht mehr ausbügeln können, weil sie einfach in der Art und weise begründet sind, wie man code schreibt. Von daher glaube ich nicht daran, dass Java mal so performant sein wird, dass man es für alltägliche applikationen nutzen will. Wenn man aber z.b. ein Backend in einer normalen Sprache (C++, C, ..) schreibt, und ein Frontend in Java/.., dann kann das durchaus Sinn machen und könnte vieles vereinfachen, im Endeffekt zu einfacherem und vielleicht sogar schnellerem Code führen.
Ein herrausragendes Beispiel z.b. für Java finde ich den Hiptop (dieses "Smartphone" von Danger, in .de verkauft von Eplus). Das Teil hat einen ARM7 Prozessor mit 40Mhz, und benutzt als Frontendsprache Java, und man merkt es *wirklich* nicht. Die Bedienung ist absolut flüssig, brauchbar und - wenn man sich mal die Progamme dafür anschaut, einige sind im Rahmen des SDKs im Source verfügbar, andere muss man halt decompilieren *duck* - dann sind die so dermaßen simpel geschrieben, das finde ich sehr beeindruckend.
Um so ein System zu verwirklichen, und nicht bei einer Betanova zu landen, muss man aber schon SEHR genau wissen, wie Java funktioniert - und das traue ich dem Durchschnittlichen "Web" Programmierer, der Java als erste Programmiersprache gelernt hat, nicht zu. Auf dem Hiptop z.b. werden Java-Applikationen zur Compile-Zeit "gelinkt", und Verweise z.b. auf Parent-Klassen durch absolute Pointer dargsestellt. Da wird wirklich nur noch dort mit Strings gearbeitet, wo es nötig ist. In einer klassischen Java-Umgebung dagegen wird überall mit Strings gearbeitet, die Teilweise sogar in Java implementiert sind - das *kann* dann doch nicht schnell sein.
Und JNI ist ja wohl die Hölle.
Was ich eigentlich nur sagen will: Wer weiss, wie man mit Java umgehen kann, der wird damit auch auf kleinen Systemen eine Freude haben, darf dann aber nicht erwarten, dass er von den Java-"Vorteilen" wie Plattformunabhängigkeit (durch ein in Java implementiertes GUI Toolkit) viel profitiert. Genau diese "Features" machen Java langsam, nicht die VM.
Was alle diese Sprachen gemeinsam haben, ist dass man, ein ordentliches Framework vorrausgesetzt, nur noch das schreiben muss, was man will, und nicht mehr code schreiben muss für etwas was man nicht will (beispiel: Speicherverwaltung).
Das erkauft man sich allerdings mit einem sehr großen Overhead, den auch JIT oder sonstige techniken nicht mehr ausbügeln können, weil sie einfach in der Art und weise begründet sind, wie man code schreibt. Von daher glaube ich nicht daran, dass Java mal so performant sein wird, dass man es für alltägliche applikationen nutzen will. Wenn man aber z.b. ein Backend in einer normalen Sprache (C++, C, ..) schreibt, und ein Frontend in Java/.., dann kann das durchaus Sinn machen und könnte vieles vereinfachen, im Endeffekt zu einfacherem und vielleicht sogar schnellerem Code führen.
Ein herrausragendes Beispiel z.b. für Java finde ich den Hiptop (dieses "Smartphone" von Danger, in .de verkauft von Eplus). Das Teil hat einen ARM7 Prozessor mit 40Mhz, und benutzt als Frontendsprache Java, und man merkt es *wirklich* nicht. Die Bedienung ist absolut flüssig, brauchbar und - wenn man sich mal die Progamme dafür anschaut, einige sind im Rahmen des SDKs im Source verfügbar, andere muss man halt decompilieren *duck* - dann sind die so dermaßen simpel geschrieben, das finde ich sehr beeindruckend.
Um so ein System zu verwirklichen, und nicht bei einer Betanova zu landen, muss man aber schon SEHR genau wissen, wie Java funktioniert - und das traue ich dem Durchschnittlichen "Web" Programmierer, der Java als erste Programmiersprache gelernt hat, nicht zu. Auf dem Hiptop z.b. werden Java-Applikationen zur Compile-Zeit "gelinkt", und Verweise z.b. auf Parent-Klassen durch absolute Pointer dargsestellt. Da wird wirklich nur noch dort mit Strings gearbeitet, wo es nötig ist. In einer klassischen Java-Umgebung dagegen wird überall mit Strings gearbeitet, die Teilweise sogar in Java implementiert sind - das *kann* dann doch nicht schnell sein.
Und JNI ist ja wohl die Hölle.
Was ich eigentlich nur sagen will: Wer weiss, wie man mit Java umgehen kann, der wird damit auch auf kleinen Systemen eine Freude haben, darf dann aber nicht erwarten, dass er von den Java-"Vorteilen" wie Plattformunabhängigkeit (durch ein in Java implementiertes GUI Toolkit) viel profitiert. Genau diese "Features" machen Java langsam, nicht die VM.