Seite 1 von 2

Verfasst: Freitag 11. Mai 2007, 15:04
von joost
Wenn ich mit 'Dir' gemeint sein sollte (bin ja nicht Eröffner dieses Threads): Vielen Dank ! :)
Sql selbst ist sehr mächtig, es gibt Programmierer, die aus Spass mal OOP damit implementiert haben, die Objekte waren dabei Tabellen. Ich habe mal für ein Statistik-Modul ein System programmiert, worin Sql verwendet wurde, um Sql-Abfragen erst zu erzeugen (wir wollten das von außen anpassbar an Kundenwünsche halten und hätten so - allerdings dann doch ziemlich eng begrenzt - neue Statistik-Abfragen aus einer Datenbank heraus erzeugen können, ohne am Programmcode etwas ändern zu müssen).
Auf den ersten Blick halte ich - frech und brutal gesagt - SqlAlchemy für überflüssig und wieder etwas, dass Performance zugunsten von Programmier-Bequemlichkeit kostet. Anpassungen an unterschiedliche Datenbanken könnte man teilweise wahrscheinlich wirklich in Datenbankbeschreibungstabellen legen.

Verfasst: Freitag 11. Mai 2007, 15:17
von mitsuhiko
joost hat geschrieben:Auf den ersten Blick halte ich - frech und brutal gesagt - SqlAlchemy für überflüssig und wieder etwas, dass Performance zugunsten von Programmier-Bequemlichkeit kostet.
Der Overhead von SQLAlchemy ist nicht messbar. Ich kann es mir mittlerweile auch nicht mehr vorstellen ohne SQLAlchemy auf Datenbanken zugreifen zu müssen.

Verfasst: Freitag 11. Mai 2007, 15:21
von Leonidas
joost hat geschrieben:Auf den ersten Blick halte ich - frech und brutal gesagt - SqlAlchemy für überflüssig und wieder etwas, dass Performance zugunsten von Programmier-Bequemlichkeit kostet.
Husch husch, zurück zu Assembler. Dort gibt es keine Klassen, die ja nur Performance zugunsten von Programmierer-Bequemlichkeit verschwenden. Wie Python übrigens auch. :twisted:

Verfasst: Freitag 11. Mai 2007, 15:26
von joost
Der Overhead von SQLAlchemy ist nicht messbar. Ich kann es mir mittlerweile auch nicht mehr vorstellen ohne SQLAlchemy auf Datenbanken zugreifen zu müssen.
Klingt gut - nehm ich mir erstmal zu Herzen. Ein dickes 'Sorry' an alle SqlAlchemy-Entwickler.
Husch husch, zurück zu Assembler. Dort gibt es keine Klassen, die ja nur Performance zugunsten von Programmierer-Bequemlichkeit verschwenden. Wie Python übrigens auch.
Ja leider. Nicht nur ich vermisse einen echten Compiler - das tun viele Leute.

Verfasst: Freitag 11. Mai 2007, 15:27
von jens
joost hat geschrieben:
Husch husch, zurück zu Assembler.
Ja leider. Nicht nur ich vermisse einen echten Compiler - das tun viele Leute.
Du kannst dir ja mal PyPy und RPython ansehen ;)

Verfasst: Freitag 11. Mai 2007, 15:36
von BlackJack
Was ist ein echter Compiler? CPython hat einen Compiler. Der ist echt. Keine Einbildung.

Verfasst: Freitag 11. Mai 2007, 15:38
von jens
Gemeint ist wohl, echte EXE Dateien backen...

Verfasst: Freitag 11. Mai 2007, 15:41
von Leonidas
jens hat geschrieben:Gemeint ist wohl, echte EXE Dateien backen...
Das konnte Visual Basic auch lange nicht (P-Code), .NET kann sowas immer noch nicht und das so berühmte Java benennt seine Executables gar ``.class``.

Verfasst: Freitag 11. Mai 2007, 15:43
von joost
Java und .net wollen das gar nicht. Ich meine etwas, das reinen Maschinencode (vor allem erst einmal für i386-CPUs) produziert. Für mich ist das die Bedeutung des Wortes 'Compiler'.:cry:

@Jens: In diesem Sinne fand ich PyPy bisher nicht wirklich interessant. Da Du Dir die Mühe gemacht hast, dies zu schreiben, hab ich aber noch einmal auf deren Seite gesehen. Da scheint doch wirklich etwas Interessantes los zu sein, auch wenn am Ende vielleicht wieder "nur" ByteCode-Interpreter herauskommen.

Verfasst: Freitag 11. Mai 2007, 15:57
von BlackJack
Beim CPython-Compiler kommt reiner Maschinencode raus. Für eine Python-VM. Du willst Maschinencode für eine andere VM. Also ist der Begriff Compiler in beiden Fällen der passende, selbst wenn man ihn unnötig auf "Maschinencode für eine VM" einschränkt.

Verfasst: Freitag 11. Mai 2007, 15:59
von mitsuhiko
joost hat geschrieben:Java und .net wollen das gar nicht. Ich meine etwas, das reinen Maschinencode (vor allem erst einmal für i386-CPUs) produziert. Für mich ist das die Bedeutung des Wortes 'Compiler'.:cry:
Ist aber die falsche Bedeutung. Und warum zum Henker brauchst du "reinen Maschinencode"? Ich seh da nur Nachteile...

Verfasst: Freitag 11. Mai 2007, 16:01
von joost
Eine VM ist Software. Und aus meiner Sicht ist 90% aller Software Schrott. Ich will möglichst wenig Software zwischen mir und der CPU.

Verfasst: Freitag 11. Mai 2007, 16:06
von mitsuhiko
joost hat geschrieben:Eine VM ist Software. Und aus meiner Sicht ist 90% aller Software Schrott. Ich will möglichst wenig Software zwischen mir und der CPU.
><o(((°>, mehr fällt mir jetzt nicht ein.

Verfasst: Freitag 11. Mai 2007, 16:10
von BlackJack
@joost: Dann schreib Deine Programme in Assembler. Viel Spass.

Und wie Dir vielleicht aufgefallen ist, habe ich geschrieben dass Du nur Maschinencode für eine andere *VM* haben willst. Auf fast keinem modernen Prozessor läuft x86-Maschinencode. Da läuft für gewöhnlich ein "Compiler" im Prozessor der den x86-Code intern in einen RISC-Befehlssatz übersetzt un optimiert, der dann letztendlich auf der Hardware läuft. Die Grenzen zwischen Hardware, VM, Bytecode und "echtem" Maschinencode sind fliessend.

Also vergiss meinen Vorschlag und programmiere gleich in Microcode. ;-)

Auf jeden Fall bist Du bei Python sowohl was die technische, als auch die philosphische Seite angeht, bei der falschen Sprache gelandet.

Und viel Software ist vielleicht auch deswegen Schrott, weil die Leute viel zu nah an der Hardware und weniger nah am Problem programmieren.

Verfasst: Freitag 11. Mai 2007, 16:12
von Leonidas
joost hat geschrieben:Eine VM ist Software.
Wie siehts mit Lisp-Maschinen aus? Eine "VM" muss gar nicht Software sein.