On Tue, Dec 23, 2008 at 08:07:33PM +0100, Peter Vitt wrote: > In .NET muss der Programmierer nicht wirklich dafür sorgen. Dank Mono > ist nahezu alles bis .NET 2.0 auch auf Linux (und anderen Unixen, die > mir gearde entfallen sind) nutzbar.
Du meinst so wie bei Java? Vorraussetzung ist und bleibt das der
Programmierer portabilität das als ziel hat und konsequent umsetzt -
Pfadtrenner zum beispiel - Windows "\" - Unixe "/" - MacOS ":" - Fragen?
Es gibt triviale dinge die mit einem mal nicht mehr funktionieren.
Und die liste von nicht implementierten win apis in mono sollte man auch
nicht nutzen sonst ists schon wieder essig auf != Windows.
> > Warum muss das in C# sein? Warum den ganzen overhead einer virtual
> > machine und der garbage collection?
> >
> Virtual machine??? Ich als janglähriger C#-Entwickler war bis heute
> davon überzeugt, dass C#-Code in einer speziellen Intermediate Language
> vorliegt und zur Laufzeit compiliert und ausgeführt Und das Garbawird.
> Von einer VM war mir bisher nichts bekannt. Und das garbage collection
> overhead ist, ist mir bisher auch nicht wirklich bekannt (die paar
> Millisekunden, die der GC abknapst, wenn er denn überhaupt einmal läuft,
> fallen nicht messbar ins Gewicht). Ich denke, du solltest dich erst
> einmal mit C# auseinander setzen, bevor du solche unbegründeten
> Kommentare abgibst.
2 Moeglichkeiten - Virtual Machine - Oder Just in Time compiler - Wann
findet nochmal das "Just in time" statt? Ach ja - Zur Laufzeit.
Und das mit dem Garbage Collection ist nunmal unnoetiger overhead. Ja -
der faule programmierer muss sich nicht drum kuemmern weil der GC ja
einfach den gesamten prozess addressraum durchsucht nach irgendwelchen
pointern die moeglicherweise noch eine reference darstellen.
Warum kann der programmierer nicht explizit den speicher freigeben wenn
er nicht mehr benoetig wird? Ach ja - ich vergass - uebersicht verloren
... schlechte doku ... undefinierte lifecycles ...
> Geht auch in C#. Teilweise sogar schneller... Und die Programmierung
> dieser Anwendungen in einer höheren Sprache als C (C ist ja nicht mehr
> als etwas versteckter Assembler) ist auch um einiges schneller. Das sage
> ich als langjähriger C-Entwickler. Aber wie gesagt, bitte erst einmal
> schlau machen und dann Hasstieraden loslassen.
Ich lasse keine Hasstiraden los sondern es geht um Performance und als
erstes wird C# erwaehnt - und ich frage mich warum performancekritische
applikationen nicht in C# oder Java programmiert sind - libc, kernel
oder gleich der CPU microcode?
Wenn ich performanten code schreibe dann vermeide ich schon ein malloc
und greife auf einen slab allocator zurueck - und hier wird performanter
code im zusammenhang mit virtual machines, jit, intermediate code etc
erwaehnt. Da sind mindestens 2-3 abstraktionsebenen dazwischen die ihr
häppchen cpu cycles brauchen.
> > Aber vermutlich wird ausser Java und C# in der Informatikvorlesung
> > nichts mehr gemacht oder?
>
> Da kann ich nur noch mit dem Kopf schütteln. Ist das hier eine
> konstruktive Mailingliste oder fühlen sich hier Leute angegriffen, weil
> andere evtl. jüngere Leute, die andere Sprachen programmieren können,
> mit neuen Ideen kommen und was bewegen wollen?
Es geht mir auf den zwirn staendig applikationen in Java und C#
vorgesetzt zu bekommen die erstmal sich die haelfte des speichers
schnappen, 10 Minuten fuer den Startup brauchen und dann von den
Entwicklern als performant verkauft werden.
Wenn ich nur Java und C# hoere dann stecken dahinter allzuoft
Programmierer die voellig den Kontakt zu der eigentlich ausfuehrenden
Einheit - der CPU - verloren haben. Wie aus der einen C# anweisung dann
400 instructions mit 600 cycles wurde kann dann keiner mehr erklaeren.
Dann wird noch ein wenig portabilitaetsgefasel vom Stapel gelassen das
ja unbedingt Java erfordert um dann gleich im naechsten halbsatz zu
erwaehnen welches patchlevel welcher exakten jre auf welchem
Betriebssystem man jetzt braucht damit es auch wirklich funktioniert.
Ist ja auch egal - Die naechste CPU generation mit der doppelten
Frequenz und dem doppelten 2nd level cache steht ja schon vor der Tuer.
Es mag sein das C# und Java die Einstiegshürde ins Programmieren senkt,
aber sie machen es zu einfach sich in den Fuss zu schiessen. Ja - man
kann sich mit vielen Sprachen in den Fuss schiessen aber je high-level
desto einfach.
Flo
--
Florian Lohoff f...@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
signature.asc
Description: Digital signature
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
