[linux-l] Re: Programmiersprachen - Lösung in Python (kurze Version)

[Olaf Radicke]

Am Freitag, 15. September 2006 21:34 schrieb Oliver Bandel:
> On Mon, Sep 11, 2006 at 09:33:03PM +1000, Peter Ross wrote:
> > Hi Olaf,
> >
> > On Mon, 11 Sep 2006, Olaf Radicke wrote:
> > > Schon klar. Ich denke nur, man muss sich genau ansehen an welcher
> > > Schraube man drehen sollte. Es mag erst mal nahe liegend erscheinen,
> > > die Entwickler im eigenen Haus auf das Problem an zu setzen. Aber ich
> > > habe das Gefühl, das dabei das Pferd von der falschen Seite bestiegen
> > > wird.
> > >
> > > Eine Software auf eine VM zu optimieren scheint mir der falsche Weg.
> > > Ich würde geeignete Leute suchen, die mir die VM so aufboren, das sie
> > > das tut, was ich von ihr erwarte.
> >
> > Das halte ich fuer unrealistisch.
>
> [...]
>
>
> malloc-&free- Do-it-yourself-GC als Ersatz für Plug-and-Play-GC
> umgeht aber die Probleme?!


Ich glaube er hatte mich oder das Problem missverstanden.

> > Java-Entwickler sind keine JDK-Entwickler (wie ein
> > Anwendungsprogrammierer kein Kernelprogrammierer ist),
> >
> > und desweiteren ist das Letzte, was man will, ein "hausgestricktes" Java,
> > von dem man schwer loskommt.
>
> Also hausgetrickste myself-GC-Ersatz-Sourcen?

Zur Ergänzung:

Wenn ich ein Workaround in Java für eine bestimmte VM (denn es gibt mehrere 
Anbieter und Versionen) mache bin ich auf die VM festgenagelt. Wenn diese 
*eine* VM nicht für andere Hardware, Distributionen, oder Betriebssysteme 
gibt, oder gepflegt wird, sitze ich auf einen totem Gaul.

Wenn ich die VM aufbore, könnte es mir passieren, das ich ungewollte 
Nebeneffekte bekomme. Um diese zu begegnen darf ich darauf natürlich _nicht_ 
den Java-Code ändern, sondern _weiter_ die VM, bis sie das tut und so tut wie 
ich es will. 

Nachteil - Wenn die Code-Basis, der ursprüngliche VM weiter entwickelt wird, 
hab ich das Problem des mergeing. Also währe es genialer, Entwickler direkt 
in das VM-Entwickler-Team abzustellen (dann haben auch alle was davon).  

Aber selbst wenn man sein eigenes VM-Süppchen kocht. Der eigentliche Java-Code 
ist weiter kompatibel. Wenn die eigene VM sich als Schrott herausstellt, oder 
die Original VM das Problem selber behoben hat, oder es eine geniale neue VM 
von jemand ganz anderem gibt, zieht man mit seinem Java-Code um. 

Das würde nicht gehen, wenn man am Java-Code rum fummelt und anfängt dreckige 
Trickserein zu machen, an den sich die anderen VM verschlucken. 

> [...]
>
> > Java ist dafuer gedacht, portabel zu laufen, indem es eine VM anbietet.
> > Das heisst aber auch, das man bei der Abstraktion Funktionalitaet des
> > drunterliegenden Betriebssystems verliert. Das ist ein designbedingter
> > Nachteil.
>
> Welche verliert man?
> Welche verliert man, die Du vermisst?!

Ich vermute, er spielte wieder auf Speicherverwaltung an. Aber das kann man 
nicht für alle VM verallgemeinern. .NET & Mono bietet z.B. die Möglichkeit am 
GC vorbei Zeiger zu verwenden und die Umgebung (bzw. Modifizierer) heißt 
nicht ohne Grund "unsafe". Da wird dann wieder "ohne Sattel geritten" 
(Umschreibung in der Homo-Szene für ungeschützten Geschlechtsverkehr).

MfG
Olaf