Umstieg von Visual Basic unter Windows auf ? unter Linux
Karl-Heinz Zimmer
> Ich programmiere seit Jahren einige kleinere Sachen mit Visual Basic
> unter Windows. Hauptsächlich Datenbank-Anwendungen, die auf eine
> ACCESS-Datenbank zugreifen.
>
> Nun würde ich gerne auf PostgreSQL unter Linux umsteigen und auch die
> Frontends unter Linux laufen lassen. Könnt ihr mir eine
> Programmiersprache empfehlen, die dafür besonders gut geeignet ist?
C++
> Sie sollte vor allem einigermaßen zukunftssicher sein.
also C++
> Mit C++ stehe ich etwas auf Kriegsfuß,
Dann schlage ich vor, Du begraebst das Kriegsbeil.
C++ unter Linux ist das reinste Honigschlecken: die meisten Linux-Programme
sind in C++ geschrieben und (da sehr oft unter der GPL stehend) als Sourcen-
Fundgrube fuer eigene Implementierungen nutzbar.
Abgesehen davon, erhaeltst Du mit der (C++) Bibliothek Qt und dem darauf
aufgebauten KDE System und der dazu perfekt geeingeten IDE KDevelop
eine schoene Umgebung und sehr angenehme Werkzeuge zur Programmentwicklung.
> außerdem erscheint mir das als Overkill für meinen Anwendungsfall.
Das mag so scheinen, meines Erachtens ueberwiegen aber - gerade fuer
die Entwicklung von oberflaechenbetonter Software die Vorteile.
> Es geht eben hauptsächlich um das designen von Formularen für
> Benutzereingaben und -ausgaben. In letzter Zeit hört man viel von Python,
> das werde ich mir mal ansehen. Gibt es sonst noch etwas, das optimal dafür
> geeignet wäre?
Optimal?
Klar, wie gesagt: C++, Qt-Bibliothek, KDE und KDevelop. :-)
> Die jetzigen Programme sollen übrigens nicht migriert werden, es geht
> ausschließlich um Neuerstellungen.
Umso besser, dann steht dem Erlernen einer richtigen Sprache ja nichts
im Wege - waere doch schade, wenn Du auf VBasic-Niveau bzw. mit einer
Skript-Sprache weiter so vor Dich hin duempeln wuerdest, bloss weil
Du ein wenig Angst vor C++ hast?
> Ach ja: wenn es eine Gruppe gibt, die besser dafür geeignet ist, bitte
> f'up2. Ja, ich gestehe, ich war zu faul zu suchen.
Kein Problem: F'up-to de.comp.os.unix.programming ist gesetzt.
Viel Spass und Erfolg!
Karl-Heinz
--
Karl-Heinz Zimmer, Senior Software Engineer, Klarälvdalens Datakonsult AB
<mailto:k...@klaralvdalens-datakonsult.se> <mailto:k...@kde.org>
BugCops *** Making Free Software Better *** http://bugcops.org
Karl-Heinz Zimmer, Senior Software Engineer, Klarälvdalens Datakonsult AB
<mailto:k...@klaralvdalens-datakonsult.se> <mailto:k...@kde.org>
BugCops *** Making Free Software Better *** http://bugcops.org
Eckhard Lehmann
> das reinste Honigschlecken: die meisten Linux-Programme sind in C++
ich glaube, dass es mehr Linuxprogramme gibt, die in C geschrieben sind,
als in C++
In allem anderen geb ich dir recht, C++ lässt sich wirklich gut
einsetzen, und wenn einen das Kdevelop zu sehr an Microsoft- IDE's
erinnert, dann tut's auch der Emacs (und zwar sehr gut und
ressourcenschonend)
@Christian:
Mit QT- Programmierung sollte man sich meines Erachtens als Entwickler
unbedingt beschäftigen, denn in Zukunft wird es wohl mehr denn je zählen,
dass man auch plattformübergreifende Anwendungen schreiben kann.
Für spezielle Datenbankanwendungen und Formulare sollte man sich auch mit
mysql, php und Perl auseinandersetzen, das sind ziemlich mächtige
Werkzeuge in der Richtung.
Gruß, Eckhard
Gerhard Häring
>> Dann schlage ich vor, Du begraebst das Kriegsbeil. C++ unter Linux ist
>> das reinste Honigschlecken: die meisten Linux-Programme sind in C++
>> geschrieben [...]
>
>ich glaube, dass es mehr Linuxprogramme gibt, die in C geschrieben sind,
>als in C++
Ja, das ist aber noch kein Argument, dass C für Anwendungsentwicklung
was taugt.
>In allem anderen geb ich dir recht, C++ lässt sich wirklich gut
>einsetzen, und wenn einen das Kdevelop zu sehr an Microsoft- IDE's
>erinnert, dann tut's auch der Emacs (und zwar sehr gut und
>ressourcenschonend)
Ack. C++ ist in Verbindung mit Qt ganz gut zu gebrauchen. Ich würde aber
trotzdem empfehlen, mal einen Blick auf Python zu werfen
(http://www.python.org/). Python ist für RAD sehr gut geeignet (und
daher evtl. für VB-Umsteiger interessant). Es gibt für Python mehrere
gute GUI-Bibliotheken, unter anderem auch ein sehr gutes Qt-Binding,
wobei man dan auch Qt-Designer verwenden kann.
Wenn man C++ wirklich beherrschen will, muss man m. E. ein weit
überdurchschnittlicher Programmierer sein. Die Sprache ist weit
komplexer, als sie aussieht. Python ist dagegen sehr einfach und schnell
zu lernen. Man kann natürlich auch beides kombinieren, wenn man mal (was
selten vorkommt) absolute Performance braucht.
Gerhard, der gerade versucht, PyQt auf Qt-Embedded zum Laufen zu kriegen
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
Gerhard Häring
hier)
On Sat, 13 Oct 2001 10:01:30 +0200, Karl-Heinz Zimmer <k...@kde.org> wrote:
> Ich programmiere seit Jahren einige kleinere Sachen mit Visual Basic
> unter Windows. Hauptsächlich Datenbank-Anwendungen, die auf eine
> ACCESS-Datenbank zugreifen.
>
> Nun würde ich gerne auf PostgreSQL unter Linux umsteigen und auch die
> Frontends unter Linux laufen lassen. Könnt ihr mir eine
> Programmiersprache empfehlen, die dafür besonders gut geeignet ist?
Nochmal ein paar Bemerkungen, warum Python dafür besonders gut geeignet
ist (gilt in ähnlicherweise auch für andere Skriptsprachen):
Datenbankprogrammierung ist mit Python besonders einfach, und es gibt
auch einen Standard für Datenbankschnittstellen (jaja, hat Perl auch),
namens Python DB-API 2.0. Wenn du standard-konforme Module vewendest,
kannst du jederzeit diese und auch die Datenbank austauschen. Die
meisten Module funktionieren auch auf Unix und Windows gleichermaßen.
Speziell für PostgreSQL gibt es mehrere, ich würde pyPgSQL
(http://pypgsql.sf.net) empfehlen, schon allein weil ich das
mitentwickle ;-) Funktioniert unter Windows, Unix, MacOS X.
Wenn ein Web-Frontent praktikabel ist, kannst du dir evtl. auch mal ZOPE
(http://www.zope.org/) anschauen. Das hat einige Features in Richtung
Datenbankanbindung (und vieles anderes). Ist in Python erweiterbar, aber
es gibt auch viele vorgefertigte Module, vom Diskussionsforum bis zur
Versionskontrolle von Dokumenten mit CVS.
Python-Anfänger können hier starten: http://www.python.org/doc/Newbies.html
Gerhard
Felix von Leitner
> Wenn ein Web-Frontent praktikabel ist, kannst du dir evtl. auch mal ZOPE
> (http://www.zope.org/) anschauen.
Gibt es für Zope eigentlich auch Argumente, die die unsägliche
Performance und den immensen Bloat auch nur ansatzweise aufwiegen
können?
Klar, das läßt sich kaum vermeiden, wenn etwas in Python (würg)
implementiert ist... *bg*
Felix
Gerhard Häring
>Thus spake Gerhard Häring (gerhard...@bigfoot.de):
>> Wenn ein Web-Frontent praktikabel ist, kannst du dir evtl. auch mal ZOPE
>> (http://www.zope.org/) anschauen.
>
>Gibt es für Zope eigentlich auch Argumente, die die unsägliche
>Performance und den immensen Bloat auch nur ansatzweise aufwiegen
>können?
Ich verwende es selber (noch) nicht. Es gibt einige gute Argumente gegen
ZOPE, die Schlagworte die du hier anführst gehören nicht dazu.
Bloat ist meistens lediglich ein Totschlagargument von Linux-Fanatikern,
kein Argument für oder gegen Software. Was Bloat ist ist auch sehr
subjektiv und von dem bestimmt, welchen Anteil an der Funktionalität man
nutzt.
Performance ist auch sehr relativ, und über Performance zu reden ohne
Kontext und konkrete Messergebnisse ist anfängerhaft, aber für
Linux-Vim-mutt-Fanatiker [1] typisch (*beg* von mir). Sich über
Performance Gedanken zu machen, wenn die Website kaum benutzt wird, ist
sowieso Blödsinn.
>Klar, das läßt sich kaum vermeiden, wenn etwas in Python (würg)
>implementiert ist... *bg*
Auf so was gehe ich nicht ein.
Gerhard
[1] verwende ich selber alles.
Axel Schwenke
gerhard...@bigfoot.de (Gerhard Häring) writes:
> On Sat, 13 Oct 2001 14:39:10 GMT, Felix von Leitner wrote:
>>
>>Gibt es für Zope eigentlich auch Argumente, die die unsägliche
>>Performance und den immensen Bloat auch nur ansatzweise aufwiegen
>>können?
>
> Ich verwende es selber (noch) nicht. Es gibt einige gute Argumente gegen
> ZOPE, die Schlagworte die du hier anführst gehören nicht dazu.
>
> Bloat ist meistens lediglich ein Totschlagargument von Linux-Fanatikern,
> kein Argument für oder gegen Software. Was Bloat ist ist auch sehr
> subjektiv und von dem bestimmt, welchen Anteil an der Funktionalität man
> nutzt.
Tja schade. Keine Argumente in deinem Posting. Im Moment ärgere ich
mich gerade über den enormen Bloat, den Java-Applicationserver (ganz
speziell: Dynamo von ATG) mit sich rumschleppen. Anscheinend ist Zope
da auch nicht besser.
> Performance ist auch sehr relativ, und über Performance zu reden ohne
> Kontext und konkrete Messergebnisse ist anfängerhaft, aber für
> Linux-Vim-mutt-Fanatiker [1] typisch (*beg* von mir). Sich über
> Performance Gedanken zu machen, wenn die Website kaum benutzt wird, ist
> sowieso Blödsinn.
Wer für eine kaum benutzte Website Zope einsetzt, dem ist ohnehin nicht
mehr zu helfen (da ist PHP wesentlich geeigneter). Ansonsten muß ich
dir leider widersprechen: Performance ist alles! Der Kontext ist dabei
wurscht. Wenn von zwei Lösungen auf der selben Hardware die eine
signifikant schneller ist, läßt sich das für eine konkrete Problem-
stellung direkt in Geld ausdrücken.
XL
--
|-----------------------------------------------------------------------|
| Axel Schwenke, Systemadministrator @ jobpilot AG |
| www.jobpilot.{at,be,ch,cz,de,dk,es,fr,hu,it,net,nl,no,pl,se,co.uk...} |
|_____ Linux is like a Wigwam: no Windows, no Gates, Apache inside _____|
Marian Aldenhoevel
>> über Performance zu reden ohne
>> Kontext und konkrete Messergebnisse ist anfängerhaft
> Ansonsten muß ich dir leider leider widersprechen: Performance ist
> alles! Der Kontext ist dabei wurscht. Wenn von zwei Lösungen auf
> der selben Hardware die eine signifikant schneller ist
Wo ist da der Widerspruch?
"Von zwei Lösungen" und "eine schneller" _bedeutet_ "Kontext" und
"konkrete Messergebnisse".
Einfach zu behaupten "A ist zu langsam" ist Unsinn.
Ciao, MM
--
Marian Aldenhövel, Hainstraße 8, 53121 Bonn
http://www.marian-aldenhoevel.de
"I had to respond to two senior officers,
Colonel Panic and General Protection Fault."
Gerhard Häring
>Tja schade. Keine Argumente in deinem Posting.
Nein, weil ich mich damit zu wenig befasst habe. Ich hab nur was gegen
substanzlose Vorurteile. Bloat ist für mich ein nichtssagender Begriff,
man müsste schon sagen, was man damit genau meint.
>Im Moment ärgere ich mich gerade über den enormen Bloat,
^^^^^
Was genau?
>den Java-Applicationserver (ganz speziell: Dynamo von ATG) mit sich
>rumschleppen. Anscheinend ist Zope da auch nicht besser.
Hast du dich über ZOPE informiert oder es ausprobiert? Wenn nicht, woher
willst du das wissen?
>> Performance ist auch sehr relativ, und über Performance zu reden ohne
>> Kontext und konkrete Messergebnisse ist anfängerhaft, aber für
>> Linux-Vim-mutt-Fanatiker [1] typisch (*beg* von mir). Sich über
>> Performance Gedanken zu machen, wenn die Website kaum benutzt wird, ist
>> sowieso Blödsinn.
>
>Wer für eine kaum benutzte Website Zope einsetzt, dem ist ohnehin nicht
>mehr zu helfen?
Ich dachte an Intranets, bei denen man die maximale Nutzung einigermaßen
abschätzen kann und diese i. d. R. nicht besonders groß ist.
>(da ist PHP wesentlich geeigneter). Ansonsten muß ich dir leider
>widersprechen: Performance ist alles! Der Kontext ist dabei wurscht.
>Wenn von zwei Lösungen auf der selben Hardware die eine signifikant
>schneller ist, läßt sich das für eine konkrete Problem- stellung direkt
>in Geld ausdrücken.
Einspruch. Wenn ich bestimmte Hardware zur Verfügung habe und ich die
maximale Last weiss, die auf mich zukommen wird, gibt es nur ausreichend
Performance und eben nicht ausreichend Performance.
Wenn ich maximal 10 Hits pro Sekunde habe, kann es mir schnurzpiep sein,
ob Applicationserver + Anwendung maximal 20, 50 oder 300 Hits pro
Sekunde verkraften.
Gerhard
Florian Weimer
> Datenbankprogrammierung ist mit Python besonders einfach, und es gibt
> auch einen Standard für Datenbankschnittstellen (jaja, hat Perl auch),
> namens Python DB-API 2.0. Wenn du standard-konforme Module vewendest,
> kannst du jederzeit diese und auch die Datenbank austauschen.
Interessant. Was wird als Abfragesprache verwendet?
> Wenn ein Web-Frontent praktikabel ist, kannst du dir evtl. auch mal ZOPE
> (http://www.zope.org/) anschauen. Das hat einige Features in Richtung
> Datenbankanbindung (und vieles anderes). Ist in Python erweiterbar, aber
> es gibt auch viele vorgefertigte Module, vom Diskussionsforum bis zur
> Versionskontrolle von Dokumenten mit CVS.
Schon vor zwei Jahren war es mir zu komplex. Allerdings weiß ich
mittlerweile, daß Python mir als Programmiersprache doch deutlich
besser als PHP gefällt. :-/
Jörg
Gerhard Häring schrieb:
> Performance ist auch sehr relativ, und über Performance zu reden ohne
> Kontext und konkrete Messergebnisse ist anfängerhaft, aber für
> Linux-Vim-mutt-Fanatiker [1] typisch (*beg* von mir).
JAJA
> Sich über
> Performance Gedanken zu machen, wenn die Website kaum benutzt wird, ist
> sowieso Blödsinn.
Das hat M$ auch gedacht als sie sich DOS kauften. Wer wird es schon
benutzen????
Florian Weimer
> Wenn von zwei Lösungen auf der selben Hardware die eine
> signifikant schneller ist, läßt sich das für eine konkrete Problem-
> stellung direkt in Geld ausdrücken.
Die eine Lösung braucht fünf Leute, um sie zu warten, die andere zwei.
Da Personalkosten die Hardwarekosten sowieso bei weitem übersteigen,
lohnt es sich eher, bei der Hardware zu investieren.
Das Problem in der Praxis ist, daß beide Lösungen fünf Leute brauchen
-- und damit ist es vom Kostengesichtspunkt praktisch egal, was man
nimmt.
Felix von Leitner
> Einfach zu behaupten "A ist zu langsam" ist Unsinn.
Ah, wenn das so ist, verkaufe ich dir gerne ein Auto mit
Höchstgeschwindigkeit 3 km pro Monat.
Felix
Felix von Leitner
> substanzlose Vorurteile. Bloat ist für mich ein nichtssagender Begriff,
> man müsste schon sagen, was man damit genau meint.
Genau das ist mein Problem mit dir. Du hast keine Ahnung, was Bloat
ist, faselst aber dumm herum und bemühst dich vergeblich um eine
Kompetenzsimulation.
> >Im Moment ärgere ich mich gerade über den enormen Bloat,
> ^^^^^
> Was genau?
Sag mal, wieso diskutierst du eigentlich mit uns hier herum, wenn du
sogar zu dämlich bist, selbständig bloat nachzugooglen?
> >den Java-Applicationserver (ganz speziell: Dynamo von ATG) mit sich
> >rumschleppen. Anscheinend ist Zope da auch nicht besser.
> Hast du dich über ZOPE informiert oder es ausprobiert? Wenn nicht, woher
> willst du das wissen?
Von mir z.B.
Oder den Tausenden anderen Opfern von Zope. Denn da herrscht Heulen und
Zähneknirschen.
> Ich dachte an Intranets,
^^^^^^^^^^
Das bestreite ich vehement.
> Einspruch. Wenn ich bestimmte Hardware zur Verfügung habe und ich die
> maximale Last weiss, die auf mich zukommen wird, gibt es nur ausreichend
> Performance und eben nicht ausreichend Performance.
Unfug. Es gibt "wir legen diese zehn Dienste zusammen auf diese eine
Kiste, weil die Dienste alle performant genug sind" oder "wir legen neun
zusammen und packen Zope auf diesen anderen Rechner, weil Zope so
unglaublich scheiße unperformant ist, daß die Magengeschwüre Nachwuchs
kriegen".
Gerhard Häring
>gerhard...@bigfoot.de (Gerhard Häring) writes:
>
>> Datenbankprogrammierung ist mit Python besonders einfach, und es gibt
>> auch einen Standard für Datenbankschnittstellen (jaja, hat Perl auch),
>> namens Python DB-API 2.0. Wenn du standard-konforme Module vewendest,
>> kannst du jederzeit diese und auch die Datenbank austauschen.
>
>Interessant. Was wird als Abfragesprache verwendet?
SQL. Wenn du wirklich portabel sein willst, musst du natürlich die
Untermenge von SQL verwenden, die alle potentiell verwendeten
Datenbanken überreissen. Kurz skizziert, wie das dann aussehen kann:
dbtype = "PostgreSQL"
connection_string = ""
if dbtype == "MySQL":
import MySQLdb as dbmodule
elif dbtype == "PostgreSQL":
import PgSQL as dbmodule
elif dbtype == "Oracle":
import cxOracle as dbmodule
# ...
conn = dbmod.connect(connection_string)
cursor = conn.cursor()
cursor.execute("select id, name * from test")
for (id, name) in cursur.fetchall():
# irgendwas damit machen
dbmodule.close()
Man könnte den ganzen cross-database Schotter noch viel dynamischer
programmieren. Weil ich in der Regel irgendwann doch mal nicht ganz so
portable Konstrukte verwenden will, mache ich dann eine Basisklasse mit
dem portablen SQL und für die jeweilige Datenbank abgeleitete Klassen.
Typischer Anwendungsfall: für MySQL braucht man ziemlich schnell
"last_insert_id".
Die API ist hier beschrieben:
http://www.python.org/topics/database/DatabaseAPI-2.0.html
Einige der Module, welche die API unterstützen (nicht vollständig):
http://www.python.org/topics/database/modules.html
Gerhard Häring
>Thus spake Gerhard Häring (gerhard...@bigfoot.de):
>> Nein, weil ich mich damit zu wenig befasst habe. Ich hab nur was gegen
>> substanzlose Vorurteile. Bloat ist für mich ein nichtssagender Begriff,
>> man müsste schon sagen, was man damit genau meint.
>
>Genau das ist mein Problem mit dir. Du hast keine Ahnung, was Bloat
>ist,
Ich weiss, was damit gemeint ist. Und dass du ein Problem hast ist
offensichtlich. Der Begriff Bloat ist nun mal sehr unscharf und wird i.
d. R. als Totschlagargument verwendet. Ich hab schon gesagt, dass Bloat
davon abhängt, welchen Anteil der angebotenen Features du verwendest.
>faselst aber dumm herum und bemühst dich vergeblich um eine
>Kompetenzsimulation.
Jedenfalls habe ich es nicht nötig, ausfallend zu werden. Du scheinbar
schon.
>[weitere Pöbeleien]
>> Einspruch. Wenn ich bestimmte Hardware zur Verfügung habe und ich die
>> maximale Last weiss, die auf mich zukommen wird, gibt es nur ausreichend
>> Performance und eben nicht ausreichend Performance.
>
>Unfug. Es gibt "wir legen diese zehn Dienste zusammen auf diese eine
>Kiste, weil die Dienste alle performant genug sind" oder "wir legen neun
>zusammen und packen Zope auf diesen anderen Rechner, weil Zope so
>unglaublich scheiße unperformant ist, daß die Magengeschwüre Nachwuchs
>kriegen".
Mag sein, hab ich nicht ausprobiert. Ohne eine Messung von Anwendungen,
die mit dem gleichen Algorithmus auf zwei versch. Applicationservern
laufen (z. B. selbe Anwendung in Python und Java) kann man darüber
nichts sagen. Wenn du den Applicationserver wegen deiner Inkompetenz
falsch konfigurierst oder sonst irgendeinen Blödsinn machst, liegt das
Problem wohl bei dir.
Felix von Leitner
> Der Begriff Bloat ist nun mal sehr unscharf
Nein, überhaupt nicht.
Im Gegenteil.
Vielleicht bequemt der Herr sich jetzt doch mal, eine Suchmaschine
seiner Wahl nach der Definition von Bloat zu befragen? Oder bist du
dafür ernsthaft zu dämlich?
> Mag sein, hab ich nicht ausprobiert.
Was faselst du dann hier rum?
> Ohne eine Messung von Anwendungen, die mit dem gleichen Algorithmus
> auf zwei versch. Applicationservern laufen (z. B. selbe Anwendung in
> Python und Java)
Java ist auch fürchterlich ineffizient und ein leuchtendes Beispiel für
alle Bloat-Opfer, daß es noch viel schlimmer kommen kann als es schon
ist. Das eignet sich jedenfalls genau nicht zur Entlastung von Python
und darauf aufbauender Bloatware.
> Wenn du den Applicationserver wegen deiner Inkompetenz falsch
> konfigurierst oder sonst irgendeinen Blödsinn machst, liegt das
> Problem wohl bei dir.
Hrhrhr, du würdest einen Applikationsserver ja nicht mal erkennen, wenn
er dir in den Hintern treten würde, und maßt dir hier so eine dicke
Lippe an? Wenn du nicht vorher bereits deine geistige Abwesenheit unter
Beweis gestellt hättest, könnte man fast Respekt entwickeln.
Jörg
Felix von Leitner schrieb:
Mein Physiklehrer würde sich im Grab umdrehen. Höchstgeschwindigkeit 3
KM, also wirklich von dir hätte ich mehr erwartet.
Gerhard Häring
>Thus spake Gerhard Häring (gerhard...@bigfoot.de):
>> Ich weiss, was damit gemeint ist.
>[...]
>> Der Begriff Bloat ist nun mal sehr unscharf
>
>Nein, überhaupt nicht.
>Im Gegenteil.
Wir können uns jetzt noch lange darüber streiten, aber zu deiner Info
habe ich die jeweiligen Einträge in ESR's Jargon File gelesen, und bin
derselben Meinung geblieben. Gut, sagen wir besser: der Begriff ist sehr
subjektiv.
>Vielleicht bequemt der Herr sich jetzt doch mal, eine Suchmaschine
>seiner Wahl nach der Definition von Bloat zu befragen? Oder bist du
>dafür ernsthaft zu dämlich?
>
>> Mag sein, hab ich nicht ausprobiert.
>
>Was faselst du dann hier rum?
>
>> Ohne eine Messung von Anwendungen, die mit dem gleichen Algorithmus
>> auf zwei versch. Applicationservern laufen (z. B. selbe Anwendung in
>> Python und Java)
>
>Java ist auch fürchterlich ineffizient und ein leuchtendes Beispiel für
>alle Bloat-Opfer, daß es noch viel schlimmer kommen kann als es schon
>ist. Das eignet sich jedenfalls genau nicht zur Entlastung von Python
>und darauf aufbauender Bloatware.
Wer hier faselt, bist du. Definiere ein Anwendungsbeispiel und führe
Messungen durch. Und zwar einen, wofür man einen Applicationserver bzw.
ein Content-Management-System wie ZOPE braucht. Bis dahin, schwall
besser nicht von Sachen, von denen du zu wenig Ahnung hast.
>> Wenn du den Applicationserver wegen deiner Inkompetenz falsch
>> konfigurierst oder sonst irgendeinen Blödsinn machst, liegt das
>> Problem wohl bei dir.
>
>Hrhrhr, du würdest einen Applikationsserver ja nicht mal erkennen, wenn
>er dir in den Hintern treten würde, und maßt dir hier so eine dicke
>Lippe an? Wenn du nicht vorher bereits deine geistige Abwesenheit unter
>Beweis gestellt hättest, könnte man fast Respekt entwickeln.
Glaub mir, ich weiss sehr gut was ein Applicationserver ist, da ich
selber an einem von einer gewissen Firma in Jena entwickelt habe.
Florian Weimer
>>Interessant. Was wird als Abfragesprache verwendet?
>
> SQL. Wenn du wirklich portabel sein willst, musst du natürlich die
> Untermenge von SQL verwenden, die alle potentiell verwendeten
> Datenbanken überreissen.
Die Schnittmenge ist recht uninteressant (bis auf Dinge wie "SELECT
0;" gibt es nur sehr, sehr wenig). Das fängt ja schon damit an, daß
die Datenbanken Strings in SQL-Statements unterschiedlich darstellen
(mal muß \ durch \\ ersetzt werden, mal nicht).
Aber wenn wenigstens das API einheitlich ist, ergeben sich schon ein
paar Vorteile, klar.
Immo 'FaUl' Wehrenberg
> Ah, wenn das so ist, verkaufe ich dir gerne ein Auto mit
> Höchstgeschwindigkeit 3 km pro Monat.
[X] Send pix
Wie das aussieht wuerde mich dann doch interessieren...
FaUl
end
This article does not support incompatible and broken newsreader.
--
.... der Geschäftskundenvertrieb trägt den Namen
weil er aktiv Geschäftskunden vertreibt .....
Marian Aldenhoevel
> Ah, wenn das so ist, verkaufe ich dir gerne ein Auto mit
> Höchstgeschwindigkeit 3 km pro Monat.
Wenn das schnell genug ist, es meine Bedürfnisse erfüllt, und
der Preis stimmt. Wunderbar.
Marian Aldenhoevel
> Du hast keine Ahnung, was Bloat ist
Es ist ein abwertender Begriff bar jeder faßbaren Substanz.
Ob ein Programm, Verfahren oder eine Mensch fetter und langsamer ist, als
er, sie oder es sein müssten kann man nur im Vergleich feststellen.
Erfüllt ein weniger fettes Programm Deine Bedürfnisse, dann nimm es und
jammere nicht. Findest Du keines schreib' eines. Kannst Du keines
schreiben hat die Behäbigkeit offensichtlich einen Grund.
Christian Litzinger
>> das reinste Honigschlecken: die meisten Linux-Programme sind in C++
>> geschrieben [...]
>
>ich glaube, dass es mehr Linuxprogramme gibt, die in C geschrieben sind,
>als in C++
>
>In allem anderen geb ich dir recht, C++ lässt sich wirklich gut
>einsetzen, und wenn einen das Kdevelop zu sehr an Microsoft- IDE's
>erinnert, dann tut's auch der Emacs (und zwar sehr gut und
>ressourcenschonend)
Ich habe vor ein paar Jahren einige Sachen in C geschrieben (für meine
DOS-Mailbox damals). Dann wollte ich C++ lernen und hab's einfach
nicht gerafft. Vielleicht bin ich jetzt reif dafür. ;-)
Übrigens: Mit KDE will ich *nichts* zu tun haben. :-)
>@Christian:
>Mit QT- Programmierung sollte man sich meines Erachtens als Entwickler
>unbedingt beschäftigen, denn in Zukunft wird es wohl mehr denn je zählen,
>dass man auch plattformübergreifende Anwendungen schreiben kann.
>Für spezielle Datenbankanwendungen und Formulare sollte man sich auch mit
>mysql, php und Perl auseinandersetzen, das sind ziemlich mächtige
>Werkzeuge in der Richtung.
Aha! Wieso ist Qt-Programmierung denn plattformübergreifend? Gibt es
da etwas, was ich (noch) nicht weiß? Aber gut, ich habe mich mit Qt
auch noch nicht beschäftigt. Ist das jetzt eigentlich frei (im Sinne
von 'ohne Lizenzgebühren')?
Mit Perl hatte ich mal ein paar einfache Textmodus-Programme
geschrieben, kann man da auch was für X machen?
Aber ich werde mir auf jeden Fall mal Python anschauen, was ich
bis jetzt darüber gelesen habe, hört sich nicht schlecht an. Meine
Programme sind auch eher unter 'quick and dirty' einzuordnen, da sind C
und Perl eher gefährlich.
Danke euch allen
Christian
Sebastian Ritter
>
>Mit Perl hatte ich mal ein paar einfache Textmodus-Programme
>geschrieben, kann man da auch was für X machen?
Kann man.
Perl hat aber eher andere Stärken, als daß man damit gut GUIs
programmieren könnte.
Jedoch gibt es für Perl z.B. Qt-, GTk- oder auch Tk-Wrapper.
Allerdings sind das natürlich alles "Wrappers around wrappers around
wrappers", so daß das alles nicht so wirklich toll und schnell ist, aber
man kann mal eben quick & dirty etwas damit zusammenflicken.
Such mal mit Google nach CPAN, Tk, Qt, GTk.
Gruß
Sebastian
Felix von Leitner
> Es ist ein abwertender Begriff bar jeder faßbaren Substanz.
Nein. Bloat heißt unnötige Ressourcenbelegung. Fertig.
> Ob ein Programm, Verfahren oder eine Mensch fetter und langsamer ist, als
> er, sie oder es sein müssten kann man nur im Vergleich feststellen.
Nein. Man muß lediglich eine Stelle zeigen können, an der man mit
lediglich einem Quantum weniger Ressourcenverbrauch hätte auskommen
können.
> Erfüllt ein weniger fettes Programm Deine Bedürfnisse, dann nimm es und
> jammere nicht. Findest Du keines schreib' eines. Kannst Du keines
> schreiben hat die Behäbigkeit offensichtlich einen Grund.
Ja, der aber nichts mit Bloat zu tun hat, sondern mit meinen
Fähigkeiten als Programmierer.
Kurz: du hast genau nichts richtiges udn sinnvolles zum Thema zu sagen
gehabt. Geh Weg.
Felix
Felix von Leitner
Nein. Braucht mehr Ressourcen als nötig -> Bloat.
Ganz einfach.
> >Vielleicht bequemt der Herr sich jetzt doch mal, eine Suchmaschine
> >seiner Wahl nach der Definition von Bloat zu befragen? Oder bist du
> >dafür ernsthaft zu dämlich?
> >
> >> Mag sein, hab ich nicht ausprobiert.
> >
> >Was faselst du dann hier rum?
> >
"Konversation" mit dir ist unnötig anstrengend, da du hier
Bloat-Postings von dir gibst. Zu obigen Paragraphen hast du nichts zu
sagen, zitierst sie aber trotzdem mit.
> >Java ist auch fürchterlich ineffizient und ein leuchtendes Beispiel für
> >alle Bloat-Opfer, daß es noch viel schlimmer kommen kann als es schon
> >ist. Das eignet sich jedenfalls genau nicht zur Entlastung von Python
> >und darauf aufbauender Bloatware.
> Wer hier faselt, bist du.
So? Zeige mir bitte ein Problem aus dem realen Leben, das in Java
mit weniger Speicherverbrauch und weniger Laufzeit gelöst werden kann
als in C.
> Definiere ein Anwendungsbeispiel und führe Messungen durch. Und zwar
> einen, wofür man einen Applicationserver bzw. ein
> Content-Management-System wie ZOPE braucht.
Wenn ich einen solchen Anwendungsfall finde, werde ich es dir gerne
mitteilen. Ich kenne keinen. Daraus folgt: Zope ist komplett
überflüssig und damit insgesamt Bloat.
> Bis dahin, schwall besser nicht von Sachen, von denen du zu wenig
> Ahnung hast.
Ich lach mich kaputt.
Du bist wirklich niedlich.
> Glaub mir, ich weiss sehr gut was ein Applicationserver ist, da ich
> selber an einem von einer gewissen Firma in Jena entwickelt habe.
Laß mich raten, die die gerade so gut wie pleite sind und massive
Entlassungen durchführen? Na so ein Zufall.
Felix
Gerhard Häring
>Thus spake Gerhard Häring (gerhard...@bigfoot.de):
>> Gut, sagen wir besser: der Begriff ist sehr subjektiv.
>
>Nein. Braucht mehr Ressourcen als nötig -> Bloat.
>Ganz einfach.
Das ist deine Definition von Bloat? Ok. Jegliche Software die größer als
ein paar Kilobyte ist, ist demnach Bloat, da man sie in handcodiertem
Assembler mit weniger Ressourcenverbrauch schreiben kann. Das ist doch
lächerlich. Du machst es mir wirklich schwierig, dich ernst zu nehmen.
>> >Vielleicht bequemt der Herr sich jetzt doch mal, eine Suchmaschine
>> >seiner Wahl nach der Definition von Bloat zu befragen? Oder bist du
>> >dafür ernsthaft zu dämlich?
>> >
>> >> Mag sein, hab ich nicht ausprobiert.
>> >
>> >Was faselst du dann hier rum?
>> >
>
>http://learn.to/quote
Ach ja, der Besserwisser scheint wieder mal durch.
>"Konversation" mit dir ist unnötig anstrengend, da du hier
>Bloat-Postings von dir gibst. Zu obigen Paragraphen hast du nichts zu
>sagen, zitierst sie aber trotzdem mit.
*Du* bist sehr anstrengend, weil du nicht in der Lage bist zu
diskutieren, ohne in jedem zweiten Satz beleidigend zu werden.
>> >Java ist auch fürchterlich ineffizient und ein leuchtendes Beispiel für
>> >alle Bloat-Opfer, daß es noch viel schlimmer kommen kann als es schon
>> >ist. Das eignet sich jedenfalls genau nicht zur Entlastung von Python
>> >und darauf aufbauender Bloatware.
>> Wer hier faselt, bist du.
>
>So? Zeige mir bitte ein Problem aus dem realen Leben, das in Java
>mit weniger Speicherverbrauch und weniger Laufzeit gelöst werden kann
>als in C.
Das ist hier nicht das Thema.
>> [...]
>> Bis dahin, schwall besser nicht von Sachen, von denen du zu wenig
>> Ahnung hast.
>
>Ich lach mich kaputt.
Ja? Hoffentlich.
>Du bist wirklich niedlich.
Danke für das Kompliment. - Man muss sich nicht überall auskennen. Du
magst evtl. im Embedded-Bereich in Crack sein, aber das heisst noch
lange nicht, dass du von Applicationservern oder großen
Softwareprojekten Dunst hast.
>> Glaub mir, ich weiss sehr gut was ein Applicationserver ist, da ich
>> selber an einem von einer gewissen Firma in Jena entwickelt habe.
>
>Laß mich raten, die die gerade so gut wie pleite sind und massive
>Entlassungen durchführen? Na so ein Zufall.
Richtig geraten. Das hat aber nichts mit der Qualität des Produkts zu
tun. Das ist eben nur ein Punkt unter vielen für den Erfolg eines
Softwareunternehmens.
Axel Schwenke
Jörg <J.Do...@t-online.de> writes:
>
> Felix von Leitner schrieb:
>>
>> Ah, wenn das so ist, verkaufe ich dir gerne ein Auto mit
>> Höchstgeschwindigkeit 3 km pro Monat.
> Mein Physiklehrer würde sich im Grab umdrehen. Höchstgeschwindigkeit 3
> KM, also wirklich von dir hätte ich mehr erwartet.
Das Lesen mußt du noch üben.
D r e i K i l o m e t e r p r o M o n a t.
================
Ax "hätte nicht gedacht, daß ich Fefe (oder Fifi ;-) mal verteidige" EL
Axel Schwenke
Jein. Natürlich gibt es abseits von "ich mach das mit so wenig CPU-
Power wie möglich" auch noch den betriebswirtschaftlichen TCO-Stand-
punkt. Aber ich bin Techniker, kein BWL-er ;-) [1]
Auch glaube ich, daß gute Organisation und Design viel mehr Einfluß
auf die benötigte Manpower haben, als die Auswahl einer spezifischen
Technologie. So durfte ich z.B. letztens beobachten, wie elementare
Designfehler (wir lassen Exceptions unter den Tisch fallen) in explizit
besser geeignetern Programmiersprachen (Java) zu Fehlern geführt haben,
die wir in weniger geeigneten Sprachen (PHP) nie gemacht haben.
Insofern sollte man natürlich immer die Gesamtlösung betrachten.
[1] Und ja: Ich glaube, die Quintessenz jeglicher Ingenieurtätigkeit
liegt darin, eine *optimale* Lösung für ein Problem zu finden.
Die Wichtung der Faktoren ist dann aber wieder subjektiv :-|
Axel Schwenke
C.Lit...@t-online.de (Christian Litzinger) writes:
>
> Ich habe vor ein paar Jahren einige Sachen in C geschrieben (für meine
> DOS-Mailbox damals). Dann wollte ich C++ lernen und hab's einfach
> nicht gerafft. Vielleicht bin ich jetzt reif dafür. ;-)
Vielleicht solltest du C++ erstmal als eine Art "besseres C" verwenden
(z.B. kann man Variablen da deklarieren, wo man sie braucht). Über
einfache Klassen (wie z.B. Complex), Funktionsüberladung und Templates
kommt man dann recht zielstrebig zum interessanten Kern von C++
> Übrigens: Mit KDE will ich *nichts* zu tun haben. :-)
Kann ich verstehen. Geht mir genau so :-)
> Aha! Wieso ist Qt-Programmierung denn plattformübergreifend? Gibt es
> da etwas, was ich (noch) nicht weiß?
Von der Win32-Portierung weißt du? MacOS? Qt embedded?
Btw. Qt ist wirklich nett. KDE entwickelt sich für meinen Geschmack
aber zu sehr in Richtung WinDOS.
> Aber gut, ich habe mich mit Qt
> auch noch nicht beschäftigt. Ist das jetzt eigentlich frei (im Sinne
> von 'ohne Lizenzgebühren')?
Solange du freie Software (im Sinne der QPL) damit schreibst: JA.
> Mit Perl hatte ich mal ein paar einfache Textmodus-Programme
> geschrieben, kann man da auch was für X machen?
PerlQt existiert.
> Aber ich werde mir auf jeden Fall mal Python anschauen, was ich
> bis jetzt darüber gelesen habe, hört sich nicht schlecht an.
Dem kann ich mich anschließen. Alerdings kenne ich Perl recht gut und
habe mittlerweile auch Ruby ins Herz geschlossen. Ich zweifle, daß
Python mir etwas bieten kann...
Axel Schwenke
gerhard...@bigfoot.de (Gerhard Häring) writes:
> On Sat, 13 Oct 2001 17:29:30 +0200, Axel Schwenke <schw...@jobpilot.de> wrote:
>
>>Im Moment ärgere ich mich gerade über den enormen Bloat,
> ^^^^^
> Was genau?
Hmm. Empfehlungen für Kernel-Parameter (unter HP-UX)
max_thread_proc=1024 nkthread=20000 maxfiles=20000
maxfiles_lim=20000 nfile=4096 maxuprc=1000 nproc=4000 ...
lassen (hoffentlich nicht nur) mich schaudern
(nebenher: eine Applicationserver-Instanz soll für 1000 Sessions =
ca. 50-100 concurrent users gut sein)
>>> Sich über
>>> Performance Gedanken zu machen, wenn die Website kaum benutzt wird, ist
>>> sowieso Blödsinn.
>>
>>Wer für eine kaum benutzte Website Zope einsetzt, dem ist ohnehin nicht
>>mehr zu helfen?
>
> Ich dachte an Intranets, bei denen man die maximale Nutzung einigermaßen
> abschätzen kann und diese i. d. R. nicht besonders groß ist.
Zwischen "wo man die maximale Nutzung einigermaßen abschätzen kann" und
"Website die kaum benutzt wird" ist aber schon ein Unterschied.
Genau genommen gehört eine Abschätzung der Nutzung (inkl. eine Angabe
über evtl. Abweichungen) zur Problemstellung.
>>Wenn von zwei Lösungen auf der selben Hardware die eine signifikant
>>schneller ist, läßt sich das für eine konkrete Problem- stellung direkt
>>in Geld ausdrücken.
>
> Einspruch. Wenn ich bestimmte Hardware zur Verfügung habe und ich die
> maximale Last weiss, die auf mich zukommen wird, gibt es nur ausreichend
> Performance und eben nicht ausreichend Performance.
Das ist aber keine praktische Problemstellung. Die Auswahl von Hardware
und Software ist Teil der Lösung.
Aber du hast Recht. Ich kenne Zope praktisch nicht, und will mir
deswegen kein Urteil anmaßen. Vielleicht ist es ja (trotz Python ;-)
dennoch eine Alternative. Schlimmer als der kommerzielle Java-Schrott
wird es ja hoffentlich nicht sein...
Christian Litzinger
>In article <7r2aq9...@david.southpole.ddns.org>,
> C.Lit...@t-online.de (Christian Litzinger) writes:
>>
>> Aha! Wieso ist Qt-Programmierung denn plattformübergreifend? Gibt es
>> da etwas, was ich (noch) nicht weiß?
>
>Von der Win32-Portierung weißt du? MacOS? Qt embedded?
>Btw. Qt ist wirklich nett. KDE entwickelt sich für meinen Geschmack
>aber zu sehr in Richtung WinDOS.
Von Qt embedded hab ich schon gehört. Das es das für Win und Mac gibt,
wusste ich bis jetzt noch nicht.
>> Aber gut, ich habe mich mit Qt
>> auch noch nicht beschäftigt. Ist das jetzt eigentlich frei (im Sinne
>> von 'ohne Lizenzgebühren')?
>
>Solange du freie Software (im Sinne der QPL) damit schreibst: JA.
QPL? Schon wieder was neues? Werde ich mir mal ansehen.
>> Mit Perl hatte ich mal ein paar einfache Textmodus-Programme
>> geschrieben, kann man da auch was für X machen?
>
>PerlQt existiert.
Wusste ich auch noch nicht.
Allerdings hatte ich mit Perl das Problem, dass ich nach 2 Wochen
meine eigenen Programme nicht mehr verstanden habe. Und das bei
vielleicht 100 Zeilen Code. Aber möglicherweise müsste ich das nur mal
vernünftig lernen. ;-)
Christian
Marian Aldenhoevel
> Bloat heißt unnötige Ressourcenbelegung. Fertig.
Dann ist jedes Hochsprachenprogramm schuldig.
> Nein. Man muß lediglich eine Stelle zeigen können, an der man mit
> lediglich einem Quantum weniger Ressourcenverbrauch hätte auskommen
> können.
Du vergleichst das vorliegende Programm mit einer geänderten Fassung. Das
ist ein Vergleich und Du brauchst dazu einen konkreten Anwendungsfall.
> Ja, der aber nichts mit Bloat zu tun hat, sondern mit meinen Fähigkeiten
> als Programmierer.
Du erkennst also Resourcenverbrauch als unnötig, bist aber nicht in der
Lage anzugeben wie man es besser machen hätte können? Das nenne ich
Hellseheherei.
Andreas Ferber
>
> Die Schnittmenge ist recht uninteressant (bis auf Dinge wie "SELECT
> 0;" gibt es nur sehr, sehr wenig). Das fängt ja schon damit an, daß
> die Datenbanken Strings in SQL-Statements unterschiedlich darstellen
> (mal muß \ durch \\ ersetzt werden, mal nicht).
Solche Unterschiede sollten aber von der DB-API entsprechend gekapselt
werden (und zumindest Perl DBI tut das auch, wie es bei Python aussieht,
weiss ich nicht).
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - a...@devcon.net - www.devcon.net
Felix von Leitner
> Dann ist jedes Hochsprachenprogramm schuldig.
Nein.
> > Nein. Man muß lediglich eine Stelle zeigen können, an der man mit
> > lediglich einem Quantum weniger Ressourcenverbrauch hätte auskommen
> > können.
> Du vergleichst das vorliegende Programm mit einer geänderten Fassung. Das
> ist ein Vergleich und Du brauchst dazu einen konkreten Anwendungsfall.
Nein.
$ ls -l /bin/ls ~/bin/ls
-rwxr-xr-x 1 root root 45780 Dec 26 1999 /bin/ls
-rwxr-xr-x 1 leitner users 15732 Jun 18 19:36 /home/leitner/bin/ls
$
> > Ja, der aber nichts mit Bloat zu tun hat, sondern mit meinen Fähigkeiten
> > als Programmierer.
> Du erkennst also Resourcenverbrauch als unnötig, bist aber nicht in
> der Lage anzugeben wie man es besser machen hätte können?
Wer lesen kann ist klar im Vorteil.
Felix
Felix von Leitner
> >Ganz einfach.
> Das ist deine Definition von Bloat?
Bloat ist nicht binär.
> Ok. Jegliche Software die größer als ein paar Kilobyte ist, ist
> demnach Bloat,
Unfug.
> da man sie in handcodiertem Assembler mit weniger Ressourcenverbrauch
> schreiben kann.
Das ist natürlich absoluter und sich selber widerlegender Schwachsinn.
Wenn du jedes Programm größer "ein paar Kilobyte" kleiner abbilden
kannst, dann übergebe ich dir hiermit offiziell Mozilla 0.9.5 und du
wendest diese Wunder-Abbildung einfach solange darauf an, bis du unter
"ein paar Kilobyte" bist. Das Ergebnis mailst du mir dann einfach
nächste Woche zu.
> Das ist doch lächerlich. Du machst es mir wirklich schwierig, dich
> ernst zu nehmen.
Und das aus _deinem_ Munde... das ist harter Tobak.
> >http://learn.to/quote
> Ach ja, der Besserwisser scheint wieder mal durch.
Welchen Teil davon hast du nicht verstanden?
> *Du* bist sehr anstrengend, weil du nicht in der Lage bist zu
> diskutieren, ohne in jedem zweiten Satz beleidigend zu werden.
Wenn du von mir nicht beleidigt werden möchtest, hast du folgende
Optionen:
a. du postest hier einfach nichts mehr
b. du postest ab jetzt nur noch sinnvolle Postings mit sauberer
Rechtschreibung und Grammatik und akzeptablem Quoting-Stil.
a. ist sicher die einfacherer Methode und ich lege sie dir hiermit
nachdrücklich nahe.
> >> >Java ist auch fürchterlich ineffizient und ein leuchtendes Beispiel für
> >> >alle Bloat-Opfer, daß es noch viel schlimmer kommen kann als es schon
> >> >ist. Das eignet sich jedenfalls genau nicht zur Entlastung von Python
> >> >und darauf aufbauender Bloatware.
> >> Wer hier faselt, bist du.
> >So? Zeige mir bitte ein Problem aus dem realen Leben, das in Java
> >mit weniger Speicherverbrauch und weniger Laufzeit gelöst werden kann
> >als in C.
> Das ist hier nicht das Thema.
Liest du eigentlich vor dem "Antworten" durch, was du gequotet hast?
Oder ist das eine rein zufällige Collage von Zeilen, die du gerade so im
Editor hattest?
> Danke für das Kompliment. - Man muss sich nicht überall auskennen. Du
> magst evtl. im Embedded-Bereich in Crack sein, aber das heisst noch
> lange nicht, dass du von Applicationservern oder großen
> Softwareprojekten Dunst hast.
Genau. Keine Ahnung von großen Softwareprojekten. Abgesehen von der
libc, vielleicht. Was bildet der sich bloß ein? Schreibt nen ftp- und
nen http-Server, einen RTP-Stack und portiert ein halbes Dutzend
Programme nach IPv6 und schon hält der sich für einen
Netzwerk-Fachmann?! Was ist das schon im Vergleich zu deiner, äh,
langjährigen "Laufbahn", in der du, äh, ein bißchen Python-Glue um
Postgres und MySQL gehackt hast... *prust*
> >Laß mich raten, die die gerade so gut wie pleite sind und massive
> >Entlassungen durchführen? Na so ein Zufall.
> Richtig geraten. Das hat aber nichts mit der Qualität des Produkts zu
> tun.
Aber klar doch.
Das war ein Fluch von einer bösen Voodoo-Hexe aus Südamerika, die
eigentlich Interfrob verfluchen wollte, aber durch einen Tippfehler...
Tja, wie das Schicksal so spielt.
> Das ist eben nur ein Punkt unter vielen für den Erfolg eines
> Softwareunternehmens.
Sicher doch. Denn mit tollen Mitarbeitern wie dir ist der Erfolg doch
eigentlich vorprogrammiert! Was kann da noch schiefgehen! Und wenn
doch mal was schiefgeht, hat man am Ende immer noch ein paar
Python-Module! *gacker*
Marian Aldenhoevel
> $ ls -l /bin/ls ~/bin/ls
> -rwxr-xr-x 1 root root 45780 Dec 26 1999 /bin/ls
> -rwxr-xr-x 1 leitner users 15732 Jun 18 19:36
> /home/leitner/bin/ls $
Ich bedanke mich für diesen Beweis meiner Aussage: Ohne Vergleich gibt es
keine Definition von Bloat.
Ciao, MM
--
Marian Aldenhövel, Hainstraße 8, 53121 Bonn
http://www.marian-aldenhoevel.de
"Bonner Stadthaus evakuiert: Anthrax-Formulare entdeckt."
Gerhard Häring
>[...]
>> Man muss sich nicht überall auskennen. Du
>> magst evtl. im Embedded-Bereich in Crack sein, aber das heisst noch
>> lange nicht, dass du von Applicationservern oder großen
>> Softwareprojekten Dunst hast.
>
>Genau. Keine Ahnung von großen Softwareprojekten. Abgesehen von der
>libc, vielleicht. Was bildet der sich bloß ein? Schreibt nen ftp- und
>nen http-Server, einen RTP-Stack und portiert ein halbes Dutzend
>Programme nach IPv6 und schon hält der sich für einen
>Netzwerk-Fachmann?!
Hast du auch schon mal in einem Team an einem mittelgroßen
Softwareprojekt gearbeitet? Vielleicht Anwendungsentwicklung, nicht
Embedded-Systeme?
Ich könnte mir vorstellen, dass du dich bisher hauptsächlich im
Embedded-Bereich und Systemsoftware bewegt hast (erwähnst du ja oben).
Die Entwicklungsmethoden und die ganze Prioritätensetzung sind m. E.
"ein wenig" anders, sobald es sich um größere Anwendungssoftware
handelt.
>> >Laß mich raten, die die gerade so gut wie pleite sind und massive
>> >Entlassungen durchführen? Na so ein Zufall.
>> Richtig geraten. Das hat aber nichts mit der Qualität des Produkts zu
>> tun.
>[...]
>> Das ist eben nur ein Punkt unter vielen für den Erfolg eines
>> Softwareunternehmens.
>
>Sicher doch. Denn mit tollen Mitarbeitern wie dir ist der Erfolg doch
>eigentlich vorprogrammiert! [...]
Ich arbeite nicht *für* die. Wer lesen kann, ist klar im Vorteil.
Felix von Leitner
> Softwareprojekt gearbeitet?
Ja.
> Vielleicht Anwendungsentwicklung, nicht Embedded-Systeme?
Ja.
> Ich könnte mir vorstellen,
Und ich könnte mir vorstellen, daß du diesen Thread jetzt verläßt, bevor
es noch peinlicher für dich wird.
Andreas Lobinger
Gerhard Häring schrieb:
> >> Du magst evtl. im Embedded-Bereich in Crack sein, aber das heisst noch
> >> lange nicht, dass du von Applicationservern oder großen
> >> Softwareprojekten Dunst hast.
>
> Die Entwicklungsmethoden und die ganze Prioritätensetzung sind m. E.
> "ein wenig" anders, sobald es sich um größere Anwendungssoftware
> handelt.
Kann mir mal jemand hier (ich muss da leider eine Wissenslücke eingestehen ...)
erklären was Anwendungssoftware bzw. größere Anwendungssoftware ist?
Einen fröhlichen Tag wünschend
LOBI
Gerhard Häring
Es gibt eine Unterscheidung zwischen Systemsoftware und
Anwendungssoftware.
- Systemsoftware: Kernel, grundlegende Bibliotheken wie libc,
Systemdienste, Server
- Anwendungssoftware: Der Rest. z. B. Browser, Office-Programme,
Datenbankoberflächen, Webanwendungen, Application Server
Der Herr von Leitner meinte, den Unterschied zu kennen. Über seinen
"Diskussions"stil kann sich hier ja jeder selbst ein Bild machen.
Meine These war, dass sich die Entwicklung von System- und
Anwendungssoftware unterscheidet. Z. B. bezüglich der verwendeten
Programmiersprachen. Bei Systemsoftware muss man i. d. R. auf low-level
Tools wie kompilierte Sprachen, die ohne Runtime auskommen,
zurückgreifen: üblicherweise C. Bei Anwendungsentwicklung versuchen
schlaue Leute, mit geringstmöglichem Programmieraufwand die
Anforderungen zu erfüllen: man verwendet Programmiersprachen und Tools,
die Performance-Fetischisten als "Bloat" bezeichnen und sich dabei einen
runterholen (oder es zumindest versuchen). Aber ich sagte ja: schlaue
Leute. Manche meinen eben doch, mit ungeeigneten Tools Anwendungen
schreiben zu müssen.
Ein Beispiel ist m. E. nach GNOME, wo sich die Programmierer entschieden
haben, ein Desktop Environment in C zu schreiben.
Gerhard Häring
Mach ich denke ich auch, weil Diskussion mit dir zu nichts führt.
Gerhard Häring
wrote:
> gerhard...@bigfoot.de (Gerhard Häring) bemühte seine Tastatur am
> 16.10.01 um 20:05 zum Thema "Re: Umstieg von Visual Basic unter
> Windows auf? unter Linux":
>
> > Bei Anwendungsentwicklung versuchen schlaue Leute, mit
> > geringstmöglichem Programmieraufwand die Anforderungen zu erfüllen:
> > man verwendet Programmiersprachen und Tools, die
> > Performance-Fetischisten als "Bloat" bezeichnen und sich dabei einen
> > runterholen (oder es zumindest versuchen). Aber ich sagte ja:
> > schlaue Leute. Manche meinen eben doch, mit ungeeigneten Tools
> > Anwendungen schreiben zu müssen.
>
> unter Verwendung einer Programmiersprache wie Lisp/Scheme/ML/Haskell
> schneller, weniger fehlerträchtig und mit weniger Plattenplatzbedarf
> ohne Performanceeinbuße hätte erstellen können, als mit den
> tatsächlich verwendeten Werkzeugen.
Bei Performance und Codegröße wäre ich mir da nicht unbedingt sicher.
Aber um ein paar Prozent mehr oder weniger kommt's mir bei beiden nicht
an. Viel wichtiger ist, dass funktionale Hochsprachen wie diejenigen,
die du oben erwähnst oder objektorientiert wie Python, Smalltalk usw.
die Entwicklungszeit erheblich reduzieren können. Zudem wird die
Codegröße erheblich geringer. Weniger Lines of Code => weniger Bugs.
Noch ein Vorteil von höherer Abstraktion ist, dass man Zeit hat, die
Algorithmen und das Design zu verbessern, was viel mehr bringt als
irgendwelche Mikrooptimierungen. Man kann auch mehrere Ansätze
durchspielen, weil man es sich - verglichen mit C und Konsorten -
leichter leisten kann, einen Ansatz zu verwerfen und einen besseren zu
suchen.
> Ferner glaube ich, daß eine dieser Sprachen als Makrosprache auch für
> den Anwender mit größeren Projekten ein echter Gewinn wäre.
Anstatt eine Sprache als Makrosprache zu verwenden - ugh - ist der
Windows-Ansatz der bessere Weg: es gibt einen Windows-Scripting-Host und
die jeweiligen Interpreter implementieren einfach ein COM-Interface und
schon kann man sie als Makrosprache verwenden. Da gehen neben VBA,
JScript eben auch Python, Perl, u. a., ich glaube sogar Haskell.
Auf Unix habe ich leider noch nichts gesehen, was dem gleich käme. Zwar
einiges, was in die richtige Richtung geht, wie das DCOP-Zeug von KDE,
GNOME hat was Ähnliches und Mozilla wieder was anderes, XPCOM basiertes.
Ich fände es extrem wichtig, dass man sich hier zwischen den versch.
Projekten mal auf ein paar gemeinsame APIs einigt. Und bei der
Gelegenheit auch gleich mal *ein* Komponentenmodell festlegt. Ich habe
es nämlich satt, für jede Library Hochsprachen-Wrapper schreiben zu
müssen. Unter Windows gibt es COM und da kann ich die Bibliotheken
nämlich ohne Umstände direkt verwenden.
Vom ursprünglichen Thema des Threads sind wir schon seit einer Weile
ganz schon weit weg. Drum versuche ich, den Weg zurück zu VB zu finden
;-)
Axel Schwenke
GAS...@focus.ping.de (Ortwin Gasper) writes:
> gerhard...@bigfoot.de (Gerhard Häring) bemühte seine Tastatur
>"Re: Umstieg von Visual Basic unter Windows auf? unter Linux":
>
>> Windows-Ansatz der bessere Weg: es gibt einen Windows-Scripting-Host und
>> die jeweiligen Interpreter implementieren einfach ein COM-Interface und
>> schon kann man sie als Makrosprache verwenden. Da gehen neben VBA,
>> JScript eben auch Python, Perl, u. a., ich glaube sogar Haskell.
Also ich weiß ja nicht. Ein Komponentenframework zur Implementierung
einer Makrosprache zu verwenden, sieht zwar elegant aus, aber hier wäre
die Bezeichnung "Bloat" IMNSHO wirklich angebracht.
> Wie effizient ist das? Ist dann der Aufruf einer Funktion, die die
> Applikation bereitstellt, automatisch mit einem Prozeßwechsel verbunden?
Es ist genauso teuer, wie jede andere Anwendung, die auf einem
verteilten Objektsystem beruht. Eine gewisse Eleganz der Problemlösung
erkauft man sich mit fetten und langsamen Applikationen. Ob es diesen
Preis wert ist, muß jeder selbst entscheiden.
Gerhard Häring
> In article <8B2Nb...@gasper.focus.ping.de>,
> GAS...@focus.ping.de (Ortwin Gasper) writes:
> > gerhard...@bigfoot.de (Gerhard Häring) bemühte seine Tastatur
> > am 17.10.01 um 04:33 zum Thema
> >"Re: Umstieg von Visual Basic unter Windows auf? unter Linux":
> >
> >> Anstatt eine Sprache als Makrosprache zu verwenden - ugh - ist der
> >> Windows-Ansatz der bessere Weg: es gibt einen Windows-Scripting-Host und
> >> die jeweiligen Interpreter implementieren einfach ein COM-Interface und
> >> schon kann man sie als Makrosprache verwenden. Da gehen neben VBA,
> >> JScript eben auch Python, Perl, u. a., ich glaube sogar Haskell.
>
> Also ich weiß ja nicht. Ein Komponentenframework zur Implementierung
> einer Makrosprache zu verwenden, sieht zwar elegant aus, aber hier wäre
> die Bezeichnung "Bloat" IMNSHO wirklich angebracht.
Nein, möchte ich jetzt widersprechen. Man will sich eben nicht auf ein
oder zwei oder drei Makrosprachen festlegen, sondern man definiert ein
Interface, mit dem beliebige Sprachen verwendet werden können. Ohne
Komponentenframework ist das nicht möglich.
Gerhard Häring
> gerhard...@bigfoot.de (Gerhard Häring) bemühte seine Tastatur
> > Windows-Ansatz der bessere Weg: es gibt einen Windows-Scripting-Host und
> > die jeweiligen Interpreter implementieren einfach ein COM-Interface und
> > schon kann man sie als Makrosprache verwenden. Da gehen neben VBA,
> > JScript eben auch Python, Perl, u. a., ich glaube sogar Haskell.
>
> Applikation bereitstellt, automatisch mit einem Prozeßwechsel verbunden?
Das kann ich leider jetzt nicht beantworten. COM funktioniert aber
generell sowohl out-of-process als auch in-process. OmniORB wird in
Version 4 übrigens auch effiziente in-process calls unterstützen. Auch
C++ <-> Python. Leider gibt es aber wieder Dutzende von ORBs und solange
man sich nicht auf einen einigt, bleiben in-process calls wohl die
Ausnahme.
Axel Schwenke
gerhard...@bigfoot.de (Gerhard Häring) writes:
> On Wed, 17 Oct 2001 19:56:19 +0200, Axel Schwenke <schw...@jobpilot.de> wrote:
>> In article <8B2Nb...@gasper.focus.ping.de>,
>>
>> einer Makrosprache zu verwenden, sieht zwar elegant aus, aber hier wäre
>> die Bezeichnung "Bloat" IMNSHO wirklich angebracht.
>
> Nein, möchte ich jetzt widersprechen. Man will sich eben nicht auf ein
> oder zwei oder drei Makrosprachen festlegen, sondern man definiert ein
> Interface, mit dem beliebige Sprachen verwendet werden können.
Ja, *wenn* man dieses Ziel denn hat. "Makrosprache für Applikation" ist
erstmal was anderes. Und die kanonische Antwort ist natürlich :-) auch
klar: Perl (Anselm wird gleich "Tcl" rufen). Die Frage ist eben nur, ob
man das wirklich will. Und zu welchem Preis.
"Beliebige Sprachen" ist aber auch nicht wirklich wahr. Denn wenn man
eine Sprache dann sinnvoll benutzen will, muß man ihr ja irgendwie
erstmal beibringen, das ganze Komponentenzeug auch zu benutzen.
> Ohne
> Komponentenframework ist das nicht möglich.
Sagen wir mal so: Es gibt keinen naheliegenden, besseren Weg.
Felix von Leitner
> > Bei Performance und Codegröße wäre ich mir da nicht unbedingt sicher.
> > Aber um ein paar Prozent mehr oder weniger kommt's mir bei beiden nicht
> > an. Viel wichtiger ist, dass funktionale Hochsprachen wie diejenigen,
> > die du oben erwähnst oder objektorientiert wie Python, Smalltalk usw.
> > die Entwicklungszeit erheblich reduzieren können. Zudem wird die
> > Codegröße erheblich geringer. Weniger Lines of Code => weniger Bugs.
> ganze Klassen von Bugs ausschließt. Funktionen ohne Seiteneffekte
> beispielsweise kann man ohne Rücksicht auf den Kontext debuggen, etwas,
> wovon man üblicherweise in C oder Pascal nur träumen kann.
Meine Herren, das Niveau sinkt ja hier sogar unter das von einschlägigen
LISP-Veranstaltungen!
Lauter Einbeinige diskutieren am Stammtisch über Langstreckenlauf.
> Leider kommen von den Universitäten zwar immer bessere Compiler, die
> Bibliotheksanbindung ist aber im Regelfalle noch so schlecht, daß ein
> großer Anteil der Vorteile dieser Sprachen dadurch aufgebraucht werden,
> daß man Wrapper für irgendwelche Standardbibliotheken basteln muß.
Wenn du nur halb so viel kannst wie dein großspuriges Schwadronieren
hier anzudeuten versucht, dann ist es ja sicher ein leichtes für dich,
das mal eben zu fixen.
> > Anstatt eine Sprache als Makrosprache zu verwenden - ugh - ist der
> > Windows-Ansatz der bessere Weg: es gibt einen Windows-Scripting-Host und
> > die jeweiligen Interpreter implementieren einfach ein COM-Interface und
> > schon kann man sie als Makrosprache verwenden. Da gehen neben VBA,
> > JScript eben auch Python, Perl, u. a., ich glaube sogar Haskell.
> Wie effizient ist das? Ist dann der Aufruf einer Funktion, die die
> Applikation bereitstellt, automatisch mit einem Prozeßwechsel verbunden?
Nein. Wie eine DLL, selber Adressraum.
Wie immer bei Microsoft. Sicherheit wurscht, Hauptsache es performt.
> > Ich fände es extrem wichtig, dass man sich hier zwischen den versch.
> > Projekten mal auf ein paar gemeinsame APIs einigt. Und bei der
> > Gelegenheit auch gleich mal *ein* Komponentenmodell festlegt. Ich habe
> > es nämlich satt, für jede Library Hochsprachen-Wrapper schreiben zu
> > müssen. Unter Windows gibt es COM und da kann ich die Bibliotheken
> > nämlich ohne Umstände direkt verwenden.
> Corba wäre eine Möglichkeit. Obwohl es wohl noch kein Komponentenmodell
> gibt, bei dem man sagen würde 'Das ist es'.
Und welche Erfahrungen hast du mit Komponentenmodellen, die deine
Meinung zum Thema für uns relevant machen würden?
> Die ursprüngliche Frage kann man nicht beantworten. Fast jede Sprache ist
> besser als VB, jedoch dürfte unter Linux keine existieren, die gewisse
> Stärken von VB entsprechend nachbildet.
Oh doch, wenn es einem auf die unsägliche Performance gekoppelt mit
grauenvoller Syntax ankommt, kann man zum Beispiel prima Python oder Tcl
benutzen. Externe Komponenten mit wohldefinierter API werden unter Unix
als Prozesse gehandhabt, und die kann man auch aus Python und Tcl prima
aufrufen.
Felix
Felix von Leitner
> > einer Makrosprache zu verwenden, sieht zwar elegant aus, aber hier wäre
> > die Bezeichnung "Bloat" IMNSHO wirklich angebracht.
> Nein, möchte ich jetzt widersprechen.
Nein, wer hätte _das_ gedacht!
> Man will sich eben nicht auf ein oder zwei oder drei Makrosprachen
> festlegen, sondern man definiert ein Interface, mit dem beliebige
> Sprachen verwendet werden können.
man pipe
man system
man popen
> Ohne Komponentenframework ist das nicht möglich.
Bullshit. Wie wir das von dir ja auch nicht anders gewohnt sind.
Felix
Felix von Leitner
> > Wie effizient ist das? Ist dann der Aufruf einer Funktion, die die
> > Applikation bereitstellt, automatisch mit einem Prozeßwechsel verbunden?
> Es ist genauso teuer, wie jede andere Anwendung, die auf einem
> verteilten Objektsystem beruht.
Es ging um COM. COM ist nicht "verteilt". Außer du meinst, daß sich
der Mageninhalt des Programmierers über dem Boden verteilt, wenn er sich
das genauer anschaut.
> Eine gewisse Eleganz der Problemlösung erkauft man sich mit fetten und
> langsamen Applikationen. Ob es diesen Preis wert ist, muß jeder selbst
> entscheiden.
Was ist elegant daran, mit ein paar Zeilen trivialem Script-Kram anderer
Leute Arbeit zusammenzuknoten und das als "Leistung" zu verkaufen?
Felix
--
36 percent of the American Public believes that boiling radioactive milk
makes it safe to drink.
--results of a survey by Jon Miller at Northern Illinois University
Felix von Leitner
> unterstützen.
Allein, es stellt sich die Frage: wozu?
Komponentenmodelle sind nicht dafür da, jede linked list in eine
Komponente auszugliedern, und dann da tausend Strings reinzutun, auch
jeweils eigene Komponenten, und dann (am besten über ein verteiltes
Komponentenmodell auf einem anderen Rechner) eine Quicksort-Komponente
darauf anzuwenden.
Wer mit Komponentenmodellen Performance-Probleme hat, hat sie schlicht
falsch angewendet.
Und dieser in-process Quark ist genau der gleiche Mist, den Microsoft
mit COM macht. Schon mal was von Separation gehört? Wir will
irgendjemand eine Aussage über die Stabilität von einer Software machen,
wenn jedes der 300 benutzten externen Module da wild im Speicher
herumgepointern haben könnte?!
Felix
Felix von Leitner
> gestalten, nämlich dann, wenn die Komponente nicht als Interpreter mit
> allen damit verbundenen Performanceverlusten sondern als Compiler
> eingesetzt wird.
Soso, wenn die Komponente als Compiler eingesetzt wird...
> Die Applikation lädt dann dynamisch eine Laufzeitumgebung sowie das
> Kompilat des jeweiligen Makros,
Oh, das Kompilat des Makros also.
> wobei es dann ziemlich gleichgültig ist, ob Native Code oder Bytecode
> generiert wird.
Oh, klar, Interpreter sind scheiße, außer sie interpretieren Bytecode.
Ortwin, du hast dich verlaufen. Der Eingang zum Voodoo-Shop ist eine
Tür weiter. Hier unterhalten sich Programmierer, keine Astrologen.
Felix
Gerhard Häring
> [...]
> LISP-Veranstaltungen!
Dann geh doch weg. Das Niveau wird schlagartig steigen.
Nimm mich nicht ernster als ich dich ;-)
> > > Ich fände es extrem wichtig, dass man sich hier zwischen den versch.
> > > Projekten mal auf ein paar gemeinsame APIs einigt. Und bei der
> > > Gelegenheit auch gleich mal *ein* Komponentenmodell festlegt. Ich habe
> > > es nämlich satt, für jede Library Hochsprachen-Wrapper schreiben zu
> > > müssen. Unter Windows gibt es COM und da kann ich die Bibliotheken
> > > nämlich ohne Umstände direkt verwenden.
> > Corba wäre eine Möglichkeit. Obwohl es wohl noch kein Komponentenmodell
> > gibt, bei dem man sagen würde 'Das ist es'.
>
> Und welche Erfahrungen hast du mit Komponentenmodellen, die deine
> Meinung zum Thema für uns relevant machen würden?
Jede Meinung ist *für mich* relevant, solange sie begründet wird. Auch
deine, falls du sie begründest. Nur zu sagen, du bist der große Guru und
kennst dich überall perfekt aus, genügt nicht. *bibber*
> > Die ursprüngliche Frage kann man nicht beantworten. Fast jede Sprache ist
> > besser als VB, jedoch dürfte unter Linux keine existieren, die gewisse
> > Stärken von VB entsprechend nachbildet.
>
> Oh doch, wenn es einem auf die unsägliche Performance gekoppelt mit
> grauenvoller Syntax ankommt, kann man zum Beispiel prima Python oder Tcl
> benutzen.
Programmiersprachen-Flames sind anderswo besser aufgehoben.
> Externe Komponenten mit wohldefinierter API werden unter Unix
> als Prozesse gehandhabt, und die kann man auch aus Python und Tcl prima
> aufrufen.
Oh, ich wusste gar nicht, das ich z. B. XML-Parser (die haben ja wohl
eine wohldefinierte API) unter Unix mit Pipes steuern kann. Du wirst mir
sicher jetzt gleich erklären, wie man da die SAX-Callbacks hinbekommt.
XSLT z. B. geht natürlich einfach.
IOW, die Methode mit externen Prozessen funktioniert nur für einen
relativ kleinen Teil von Programmen, die ich nicht unbedingt
"Komponenten" nennen würde.
Gerhard Häring
> gerhard...@bigfoot.de (Gerhard Häring) bemühte seine Tastatur
> "Re: Umstieg von Visual Basic unter Windows auf? unter Linux":
>
> > generell sowohl out-of-process als auch in-process. OmniORB wird in
> > Version 4 übrigens auch effiziente in-process calls unterstützen. Auch
> > C++ <-> Python. Leider gibt es aber wieder Dutzende von ORBs und solange
> > man sich nicht auf einen einigt, bleiben in-process calls wohl die
> > Ausnahme.
>
Nein. Wäre auch untypisch für Open Source :-(
Für ORBs alleine würde das nix bringen. Die Komponentenmodelle von
StarOffice, KDE, Mozilla, GNOME, GNU irgendwas würden immer noch
inkompatibel bleiben.
Und ich will wirklich nicht unbedingt Wrapper von XPCOM <-> XML-RPC <->
KDE sehen, wo irgendwo noch GNOME hineingepfriemelt wird. Das wäre
wirklich Bloat und völlig ineffizient.
Bin gespannt, ob auch im Jahre 2005 noch Wrapper für alle möglichen
Sprachen geschrieben werden, oder ob da doch noch mal die Vernunft
siegt.