Compiler & Co.

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

Freitag 11. Mai 2007, 15:04

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.
[color=green][size=75]Never use idle.pyw, if you need sys.stdin[/size][/color]
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Freitag 11. Mai 2007, 15:17

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.
TUFKAB – the user formerly known as blackbird
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 11. Mai 2007, 15:21

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:
My god, it's full of CARs! | Leonidasvoice vs Modvoice
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

Freitag 11. Mai 2007, 15:26

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.
[color=green][size=75]Never use idle.pyw, if you need sys.stdin[/size][/color]
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 11. Mai 2007, 15:27

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 ;)

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Freitag 11. Mai 2007, 15:36

Was ist ein echter Compiler? CPython hat einen Compiler. Der ist echt. Keine Einbildung.
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 11. Mai 2007, 15:38

Gemeint ist wohl, echte EXE Dateien backen...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 11. Mai 2007, 15:41

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``.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

Freitag 11. Mai 2007, 15:43

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.
[color=green][size=75]Never use idle.pyw, if you need sys.stdin[/size][/color]
BlackJack

Freitag 11. Mai 2007, 15:57

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.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Freitag 11. Mai 2007, 15:59

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...
TUFKAB – the user formerly known as blackbird
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

Freitag 11. Mai 2007, 16:01

Eine VM ist Software. Und aus meiner Sicht ist 90% aller Software Schrott. Ich will möglichst wenig Software zwischen mir und der CPU.
[color=green][size=75]Never use idle.pyw, if you need sys.stdin[/size][/color]
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Freitag 11. Mai 2007, 16:06

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.
TUFKAB – the user formerly known as blackbird
BlackJack

Freitag 11. Mai 2007, 16:10

@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.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 11. Mai 2007, 16:12

joost hat geschrieben:Eine VM ist Software.
Wie siehts mit Lisp-Maschinen aus? Eine "VM" muss gar nicht Software sein.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Antworten