warum eigentlich Java, wenn Du schnell willst?

Wenn ich mich schon mit Java rumärgern muß, dann bitte doch in einem Tempo, daß annehmbar ist. Ich muß Java verwenden, die Entscheidung liegt in dem Falle nicht bei mir. Deswegen. Also, wo kriege ich denn jiks her?

Carsten

Thomas Baum schrieb:

hallo carsten,

...

... Ich muß Java verwenden...

wenn ich nur immer java verwenden dürfte/könnte!! hast du schonmal was in c(++) programmiert/gedebuggt und mal im vergleich dazu ein ordentlichen oo-design in java? - wenn das ganze noch mit der mfc verbunden ist geht die welt unter! (gut für kleinere sachen (hacks) ist perl/php.. nicht so verkehrt)

das java nun so langsam in der gui ist stimmt auch nicht, es gibt mittlerweile viele native-libs die einen richtig flotte gui machen. eine variante einer java-ide ist 'eclipse', die verwendet swt, die ganze ide ist sehr komfortabel bzgl. package-erstellung, refactoring, junti-tests uvm... (http://eclipse.org)

Ich arbeite zur Zeit mit Eclipse und mich ödet es an "Jahrhunderte" zu warten, bis der Krempel geladen hat.

Andre Schulze schrieb:

Sehr gut ist auch IntelliJ IDEA, kostet aber Geld. Da das aber eine tschechische Firma ist, sind die Kosten verglichen mit was anderem überschaubar. Gut ist auch NetBeans, aber die Performance ist eher mau, aber auf einem aktuellen Rechner ist das echt Wurst, ich weis ja nicht, was du für einen Rechner dein eigen nennst. Alles was sich in der Athlon Klasse bewegt und ordentlich RAM besitzt, sollte reichen.

Ich habe hier nur 128MB RAM. Davon gehen noch 8MB für Shared Memory der Grafikkarte weg. Macht also 120MB. Und des is' dann nich mehr ganz so schnell.

...

Ich arbeite zur Zeit mit Eclipse und mich ödet es an "Jahrhunderte" zu warten, bis der Krempel geladen hat.

Wie oft am Tag startest du eigentlich deine IDE? Startzeiten sind bei professionellen Anwendungen weit weniger bedeutsam als bei kleinen Helfern wie Editoren usw. Ich würde mal behaupten, daß du die Wartezeit beim Start mehrfach durch effektiveres Arbeiten mit der IDE wieder raus holst (z.B. mit refactoring, wie Thomas anmerkte).

Nee, ich bin ja nicht mehrere Stunden am Stück in der IDE, und nebenher Programme laufen zu lassen, ist schlichtweg quälend. Und auch das Arbeiten mit Eclipse gestaltet sich recht zäh. Unter Windows gibt's beispielsweise JCreator. Das ist in C++ geschrieben und schön fix. Warum gibt's sowas nicht für Linux?

Carsten

On Mon, 2003-07-07 at 22:55, Martin Pitt wrote:

...Was erwartet Ihr von einer Programmiersprachen-IDE..

überzeugendes an ide's (bsp eclipse) - views verschiedener programmteile(module/packete) - vereinfachte navigation im code - code-formatierung und dokumentation - versionsmanagement in der ide - wizards zum erstellen von klassen, interfaces, methoden usw.. - integrierte debugger, compilerfehler direkt in den editor - nützliche hinweise, just-beim-tippen-compiler (hat mich vorallem bei eclipse überzeugt) - integrierung beliebiger externer tools / bsp ant, junit mit netten oberflächen - refactoring / code-"optimierer" bsp. import's .. sicherlich habe ich nicht alles von der liste der features erwischt, diese fand ich immer ganz nett.. aber die ide's sind mittlerweile so mächtig das wohl für jeden etwas dabei sein sollte.

zwecks eingewöhnung: ein kontext-sensitives "maus" menü hilft meist, wenn dahinter dann noch shortcuts stehen wirds noch netter.

geschwindigkeit: ab 512ram und entsprechend schnellem gerät geht's besser, und übrigens für java-ides ist das miniweich-fensters geeigneter (auch wenn ich immernoch keins auf meinem rechner habe)

[snip] alltag / das laden einer ide ist für hacks sicher nicht so toll, für perl mache ich aus "alter gewohnheit" im mcedit (ist halt dos-nc ähnlich) , komplexeres im Xemacs.

gruss thomas

hi pitti,

...

überzeugendes an ide's (bsp eclipse)

• views verschiedener programmteile(module/packete)

Okay, die Klassen- und Funktionsbäume sind evtl. recht nett zum schnellen Navigieren.

das war damit garnicht gemeint, sondern nur bestimmte komponenten anzuzeigen, bsp eine view mit source, forms, xml-daten, bildern.. (was auch immer logisch zusammen gehören könnte)

...

• vereinfachte navigation im code

Inwiefern? Nur durch die Klassenbäume oder gibt es auch spezielle Tastenkürzel wie beim vim? Ich möchte möglichst wenig mit der Maus arbeiten, weil das IMHO hochgradig ineffizient ist.

ich weiss das diese bedienung uneff. ist, jedoch sind die recht kryptischen kürzel die z.b beim emacs zu finden sind nicht für jeden eingängig, geschweigedenn die vom vim. (nichts destotrotz, mag ich auch 2/3-fach kombis des emacs...)

...

• code-formatierung und dokumentation

Das macht vim auch.

nicht in der 'brutalen' art wie eclipse, es wird global eingestellt wie, und wo abstände sein sollen, dann wird alles auf den standart 'zerdroschen'. ( vielleicht sollte mann nach einem externe code-formater suchen der das kann )

...

• versionsmanagement in der ide

Inwiefern vereinfacht die IDE das direkte Arbeiten mit cvs / subversion?

ja ich nehme auch den cvs com -m "abc" befehl, jedoch ist es nett die datei anzuwählen und einfach die diffs zu irgend welchen versionen zu zeigen, ggf diese dann wieder in die aktuelle einbringen zu können..

...

• wizards zum erstellen von klassen, interfaces, methoden usw..

Naja, irgendwie muss ich dem Rechner doch sagen, was ich programmieren will, Prosa wird er ja nicht verstehen. Spart sowas wirklich Zeit?

enorm, ein bsp, du möchtest ein interface erweitern, die ide bekommt das mit (entweder durch den wizard oder später "just-beim-tippen") und zeigt dir nun alle klassen bei denen diese änderung bedacht werden muss (abstract / implementieren einer methode...).

diese wizards sind bsp bei der mfc (visual-studio) garnicht wegzudenken. (pro java: man erstelle seine objekte, verknüpfe alle komponenten - fertig ist das design - aber nicht bei mfc!)

leider ist es meist so das eine ide doch mehr auf eine sprache beschränkt ist, jedoch die meissten opensource ides lassen sich mit plugins erweitern. (man programmiere das man programmieren kann..)

...

• nützliche hinweise, just-beim-tippen-compiler (hat mich vorallem bei

eclipse überzeugt)

• integrierung beliebiger externer tools / bsp ant, junit mit netten

oberflächen

Gut, das sind Punkte, über die sich nachdenken mal lohnt. Allerdings kann ich auch im vim beliebige externe Tools einbinden, aber wahrscheinlich ist vim auch eher als generische IDE für alles als einfach nur als Editor anzusehen.

bei dem 'intelligenten' ergänzen und korrigieren gibts aber auch probleme - grosse projekte mit zu wenig ram, da ist es manchmal schneller von hand eingegeben! (kommt beim ms-visual studio gelegentlich vor)

...

• refactoring / code-"optimierer" bsp. import's

Was ist Refactoring?

refactoring bsp: dir kommt in den sinn das die vererbungsstrukturen deiner exception-klassen doch anders organisiert sein sollen.. und nun alle dateien anfassen?! nein - die ide wird dir vorschlagen die entsprechenden dateien für dich zu ändern... das ganze funktioniert wirklich erstaunlich gut. (ja sicher kann man vorher ein ordentliches design auf dem papier machen ...aber man kann!)

...

geschwindigkeit: ab 512ram und entsprechend schnellem gerät geht's besser, und übrigens für java-ides ist das miniweich-fensters geeigneter (auch wenn ich immernoch keins auf meinem rechner habe)

Ähm - 300 MHz mit 128 RAM ist da also für mich als Geringe-Latenz-Fanatiker (deshalb vim auf Konsole und fvwm) wohl eher nichts?

leider ja, aber die computerwelt geht nun mal immer der klicki-bunti-welt nach .. (auch wenn es nicht grün-blau, mit wiese ist)

...

alltag / das laden einer ide ist für hacks sicher nicht so toll, für perl mache ich aus "alter gewohnheit" im mcedit (ist halt dos-nc ähnlich) , komplexeres im Xemacs.

Deshalb habe ich es halt gern, für C, C++, java, perl, php, html, xml, LaTeX, eMail, ASCII, Konfigurationsdateien und allem anderen halt ein und denselben Editor zu verwenden. Ich komme irgendwie immer durcheinander, wenn ich dann im mcedit "ESC dap" drücke, und anstatt den Absatz zu löschen, dann eine Dialogbox erscheint ;-)

jeder den editor den er mag ok? ... der vim ist nun einfach schrecklich kryptisch mit seinen verschiedenen zuständen.. auf dem schreibtisch liegt ein ganz nettes buch 'vi-editor' von o'reillys nur umstellen.. naja vieleicht später... emacs würde ich im gegensatz dazu mehr verwenden, da die erweiterungen andere formate betreffen (xml/jde.....) doch schon recht überzeugen. leider haben die ganzen erweiterungen den nachteil: es wird wieder langsam beim laden!

gibts erweiterungen für den vim: xml,perl,bash,php? dann lese ich mal die 30 seiten buch..

gruss thomas

Martin Pitt martin@piware.de writes:

Ist vielleicht zu OT, aber ich frage trotzdem mal, insbesondere die Programmierer unter Euch: Was erwartet Ihr von einer Programmiersprachen-IDE, i. e. was soll sie tun, was ein normaler Editor und ein paar kleine Tools wie make und diff nicht können?

Das einzige, was ich immer nützlich an solchen IDEs fand, war, wenn sie am laufenden Band Metainfos zu allen möglichen Symbolen, Variablen, Klassen usw. bereitstellen. Manche machen das mit Tooltips, andere in kleinen Nachbarfenstern.

Ich fühlte mich damit durchaus immer rundum gut informiert, wenn ich mit Maus und Cursor über die Zeilen geglitten bin.

How auch ever, irgendwie brauch ich das momentan auch nicht mehr. Ein eingespielter, weil immer gleicher Editor ist mir wichtiger.

GreetinX Steffen

On Sunday 06 July 2003 18:35, Thomas Baum wrote:

wenn ich nur immer java verwenden dürfte/könnte!! hast du schonmal was in c(++) programmiert/gedebuggt und mal im vergleich dazu ein ordentlichen oo-design in java?

Entschuldige, aber "ordentliches OO-Design" und "Java" gehören nicht in den selben Satz! Das ist ein Widerspruch in sich. Ich kenne bisher nur eine RICHTIGE OO-Sprache (Smalltalk) und einige gut gemeinte Ansätze, die es aber nicht ganz schaffen (Java Reflection, Qt).

Abgesehen davon kann man in C++ genauso gutes Design machen wie in Java (es sei denn man wird zu MFC gezwungen), mit Qt sogar wesentlich besser.

Konrad

On Sunday 06 July 2003 20:02, Torsten Werner wrote:

Apropos, kennt sich jemand mit 'subjektorientierter Programmierung' aus? Zumindest der Begriff klingt cool.

Als ob man mit "aspektorientierter Programmierung" nicht schon genug Buzzwords in letzter Zeit gehört hätte... :)

Josef

Am Sun den 06 Jul 2003 um 08:02:27PM +0200 schrieb Torsten Werner:

mfc). Wieso in Java alles (sogar sowas wie exp, abs, sin) in das OO-Korsett gepresst wird, find ich sehr seltsam und keineswegs als Vorteil.

Andere Leute finden es wieder als Stilbruch, daß es primitive Daten- typen wie int usw. gibt, man kann es eben nicht jedem Recht machen.

Apropos, kennt sich jemand mit 'subjektorientierter Programmierung' aus? Zumindest der Begriff klingt cool.

Klingt irgendwie nach Agententechnologie, wo Softwarehäppchen mehr oder weniger autonom und zielorientiert agieren (sollen).

Tschau,

andre

Am Mon den 07 Jul 2003 um 04:35:20PM +0200 schrieb Torsten Werner:

Am 07. Juli 2003 schrieb Andre Schulze:

...

Andere Leute finden es wieder als Stilbruch, daß es primitive Daten- typen wie int usw. gibt, man kann es eben nicht jedem Recht machen.

Auf mich wirkt sowas nur albern. Gibt es Referenzen von bekannten Leuten, die sowas wirklich wollen und auch in der Lage sind, praktisch verwendbare Software zu schreiben?

Es war ein Bekannter(TM), der das doof fand. Persönlich halte ich das für recht opportun, da es der Performance zuträglich ist.

...

Klingt irgendwie nach Agententechnologie, wo Softwarehäppchen mehr oder weniger autonom und zielorientiert agieren (sollen).

Was für mich wiederum nur viele aneinandergereihte Worthülsen sind. Gibt es Beispiele, so wie für OO mit Kapselung, Vererbung und Polymorphismus?

Mit der Theorie habe ich mich selber nicht beschäftigt, bei uns am Lehr- stuhl haben schon verschiedene Leute mit dieser Technologie herumgespielt. Die haben dafür das aglets Framework von IBM benutzt.

Dort findest du sicher mehr Informationen. Ein wichtiger Aspekt von Agenten ist, daß sie von Node zu Node "wandern" können und dort ihre Aufgaben erledigen können. Dies ist dann sinnvoll, wenn es schlauer ist, den Code zu den Daten, als die Daten zum Code kommen zu lassen. Auch kann man das Strategie Pattern benutzen, um verschiedene Variationen von Agenten mit einer "Aufgabe" zu beauftragen und das beste Ergebnis hinterher auswählen. Solche Agenten übernehmen meist nebenläufige Aufgaben, wie das Überwachen von irgendwelchen Ereignissen und so weiter. Letztendlich sind die natürlich auch nur objektorierntierte Software, mir sind keine wichtigen Merkmale bekannt, die das enger Charakterisieren, wie das z.B. mit Polyphormismus bei OO der Fall wäre, sorry.

Tschüß,

andre

Hallo Dresdner,

Apropos objektorientierte Programmierung: Solange die Daten am Schluss in einer relationalen Datenbank landen, kann die Anwendung nicht wirklich objektorientiert sein.

Und da sind wir bei meinem Lieblingsthema: Python. Dafür gibt es eine sehr leistungsfähige Objektdatenbank (ZODB).

Meine Einführung habe ich übringes vor kurzem um ein paar Beispiele ergänzt: http://www.thomas-guettler.de/vortraege/python/einfuehrung.html

Gruß, Thomas

PS: Wenn Max so ausdauernd laufen wird, wie er gerade schreit, wird er mich bestimmt bald überholen.

On Tue Jul 08, 2003 at 08:57:20PM +0200, Konrad Rosenbaum wrote: Content-Description: signed data

On Monday 07 July 2003 21:43, Thomas Guettler wrote:

...

Apropos objektorientierte Programmierung: Solange die Daten am Schluss in einer relationalen Datenbank landen, kann die Anwendung nicht wirklich objektorientiert sein.

<flame> Solange es lineare Speichermodelle, Dateien, flache Kommunikationsstreams, etc.pp. gibt kann es nicht 100% OO sein! </flame>

Dumme Frage: Worin zeichnet sich denn _echte_ OOP aus? Also was ist richtige OOP und was falsche? Gibt es nicht auch in vielen Programmieraufgaben einen "sanften" Übergang von funktionaler zu OO Programmierung?

Tschüss,

Friedrich

Am 08. Juli 2003 schrieb Josef Spillner:

P.S. Ich durfte gestern für jemanden eine Aufgabe aus einer Fakultät lösen, welche nicht die Informatik ist, und die ging in etwa so: "Entwerfen Sie in C++ ein strukturiertes Programm mit Unterprogrammen..."

Für jemanden, der bisher gar nicht programmieren kann, ist der Ansatz nicht völlig falsch. Schließlich muss er erstmal begreifen, was Prozeduren und Variablen sind, bevor er mit Klassenmethoden und -member umzugehen lernt. Und gleich C++ statt plain C zu nehmen ist durchaus praktikabel.

Und 'einfache' Funktionen wie abs, exp, exit etc. in ein objektorientiertes Korsett zu stecken halte ich sowieso für Unsinn.

Torsten

Hallo Stefan,

Am 09. Juli 2003 schrieb Stefan Lagotzki:

Was spricht denn gegen Math.abs() oder Math.exp() ? Die Klasse Math kann doch alle diese einfachen Methoden enthalten. Der Name ist jetzt frei aus der Luft gegriffen...

Welche Daten kapselt die Klasse Math? Keine. Nutzt Math Vererbung und Polymorphismus? Nein. Es ist nicht objektorientiert und sollte dann auch nicht so aussehen. Allein der Vorschlag abs und exp in dieselbe Klasse zu packen, widerspricht doch gerade der objektorientierten Logik.

Ich bin gegen objektorientierten Fundamentalismus! ;-)

Torsten

Hi!

Am 2003-07-09 9:34 +0200 schrieb Torsten Werner:

Hallo Stefan,

Am 09. Juli 2003 schrieb Stefan Lagotzki:

...

Was spricht denn gegen Math.abs() oder Math.exp() ? Die Klasse Math kann doch alle diese einfachen Methoden enthalten. Der Name ist jetzt frei aus der Luft gegriffen...

Welche Daten kapselt die Klasse Math? Keine. Nutzt Math Vererbung und Polymorphismus? Nein. Es ist nicht objektorientiert und sollte dann auch nicht so aussehen. Allein der Vorschlag abs und exp in dieselbe Klasse zu packen, widerspricht doch gerade der objektorientierten Logik.

Ich bin gegen objektorientierten Fundamentalismus! ;-)

Full ack. Math.XXX() erinnert dann eher an einen Namespace als an eine Klasse. Mathematische Abbildungen lassen sich nun mal nicht in das Konzept einer Klasse quetschen, weil eine Abbildung kein "Objekt" im philosophischen Sinne, sondern eine Vorschrift ist. Wenn man es versucht, wo soll das dann aufhören? Darf ich dann nicht mehr 3 + 4 schreiben, sondern muss 3.add( 4 ) aufrufen? Wenn das zur reinen Lehre der OOP gehört, dann bleib ich doch lieber bei Perl, C++ und Prolog. ;-)

Just my $0.02,

Pitti

Martin Pitt martin@piware.de writes:

wo soll das dann aufhören? Darf ich dann nicht mehr 3 + 4 schreiben, sondern muss 3.add( 4 ) aufrufen?

Willkommen bei Java. :-)

Steffen

Hallo!

Am 2003-07-12 18:41 +0200 schrieb Jens Lehmann:

Wenn alle statischen Methoden keiner Klasse zugeordnet sind, sparst Du vielleicht ein wenig Tipparbeit, aber bei den riesigen Frameworks wird es dann doch sehr schnell unübersichtlich und uneindeutig. Meiner Meinung nach spricht nichts dagegen solche Methoden in einer sinnvoll benannten Klasse unterzubringen.

Aber dazu gibt es doch Namespaces, die IMHO besser für diesen Zweck sind, als zwanghaft irgendwelchen Konzepten eine Klasse überzustülpen.

...

Darf ich dann nicht mehr 3 + 4 schreiben, sondern muss 3.add( 4 ) aufrufen? Wenn das zur reinen Lehre der OOP gehört, dann bleib ich doch lieber bei Perl, C++ und Prolog. ;-)

3 ist bestimmt kein zulässiger Variablenname.

Aber in einer reinen OOP-Sprache wie SmallTalk oder Ruby ein richtiges Objekt. In Ruby _kann_ man Methoden von Zahlen aufrufen, die einfach ein Objekt der Klasse Integer sind.

Java weicht bei einfachen Operatoren wie "+" und einfachen Datentypen bereits von der Objektorientierung ab, um es dem Programmierer einfacher zu machen.

Das hoffe ich ja auch, man sollte es nicht übertreiben, sondern pragmatisch bleiben.

Vielleicht wäre es sogar sinnvoller, wenn es einfache Datentypen wie int, float, double etc. nicht geben würde (stattdessen Integer, Float, Double).

S. o, ich finde die pragmatische Lösung besser. Wegen einem int (was der Prozessor prima vollständig in HW unterstützt) gleich ein ganzes Objekt anzulegen ist IMHO overkill. Zumindest dann, wenn es auch wirklich so gemacht wird (und nicht vom Compiler wegoptimiert wird).

Gute Nacht!

Pitti

On Tuesday 08 July 2003 21:13, Friedrich Hagedorn wrote:

Dumme Frage: Worin zeichnet sich denn _echte_ OOP aus? Also was ist richtige OOP und was falsche? Gibt es nicht auch in vielen Programmieraufgaben einen "sanften" Übergang von funktionaler zu OO Programmierung?

Theorie: *Encapsulation ich verpacke Daten (Eigenschaften) und Funktionen (Methoden) in eine Struktur (Objekt), es gibt nur noch Objekte. Die Beschreibung eines Objektes nennt man Klasse (da es nur Objekte gibt sind Klassen folgerichtig auch Objekte und haben selbst eine Klasse(*)).

*Information Hiding Ich brauche nicht zu wissen, wie ein Objekt intern funktioniert, solange ich weiss wie ich es benutze.

*Polymorphism Die Funktion einer Methode passt sich dynamisch den Objekten an mit denen sie aufgerufen wird (jedenfalls solange der Programmierer das vorgesehen hat).

*Inheritance Ich kann eine Klasse erweitern, indem ich davon ableite.

(*) Solange man keinen Java oder Smalltalk Compiler bauen will sollte man vermeiden darüber nachzudenken.

Verstöße von Java: *Encapsulation: Es gibt den Sonderfall "static void main(String[])". Klassen sind Objekte zweiter Klasse, ich kann sie nicht ohne weiteres Ad-Hoc ändern. Es gibt Basistypen, die keine Objekte sind (int, bool).

*Information Hiding: ich kann Daten public machen.

*Polymorphism: Methoden verlangen den Typ der Argumente zur Compilezeit.

*Inheritance: Basistypen - man kann nicht von int ableiten.

Übertrieben: wenn man die Philosophie von OO konsequent weiterführt dürfte es keine "flachen" Strukturen mehr geben. Also müssten Dateien immer als persistente Objekte und Sockets als Remote Calls dargestellt werden. Wenn man sich einige Einschränkungen auferlegt und an einigen Stellen ein Auge zudrückt geht das auch mit Java (serialisation und RMI).

Sehr realistisch ist es aber nicht.

Konrad

On Tue, Jul 08, 2003 at 08:57:20PM +0200, Konrad Rosenbaum wrote: Content-Description: signed data

On Monday 07 July 2003 21:43, Thomas Guettler wrote:

...

Apropos objektorientierte Programmierung: Solange die Daten am Schluss in einer relationalen Datenbank landen, kann die Anwendung nicht wirklich objektorientiert sein.

<flame> Solange es lineare Speichermodelle, Dateien, flache Kommunikationsstreams, etc.pp. gibt kann es nicht 100% OO sein! </flame>

Was für eine Alternative zu RAM (Random Access Memory) siehst du?

Was für eine Alternative zu einem Byte-Stream siehst du für Kommunikation?

thomas

On Tue, Jul 15, 2003 at 12:55:08PM +0200, Konrad Rosenbaum wrote: Content-Description: signed data

On Tuesday 08 July 2003 21:48, Thomas Guettler wrote:

...

On Tue, Jul 08, 2003 at 08:57:20PM +0200, Konrad Rosenbaum wrote:

...

On Monday 07 July 2003 21:43, Thomas Guettler wrote:

...

Apropos objektorientierte Programmierung: Solange die Daten am Schluss in einer relationalen Datenbank landen, kann die Anwendung nicht wirklich objektorientiert sein.

<flame> Solange es lineare Speichermodelle, Dateien, flache Kommunikationsstreams, etc.pp. gibt kann es nicht 100% OO sein! </flame>

Was für eine Alternative zu RAM (Random Access Memory) siehst du?

Einen gut versteckten RAM. Was der Nutzer/Programmierer sieht sind Objekte, die irgendwo angelegt werden. Wo sollte ihm egal sein (solange der Speicher reicht).

...

Was für eine Alternative zu einem Byte-Stream siehst du für Kommunikation?

Gut versteckte Streams. Eine gute OO Sprache sollte in der Lage sein Objekte automatisch auf einen Stream zu mappen. Oder noch radikaler: das Netzwerk so gut verstecken, dass es keinen Bruch zwischen dem Speicherraum zweier Rechner mehr gibt.

...Zukunftsmusik.... :-(

Von wegen Zukunftsmusik. Schau die mal ZEO an. ZEO ist eine verteilte objektorientierte Datenbank. Der Einsatz lohnt sich wenn Lese-Zugriffe einiges häufiger als Schreibzugriffe sind, da Schreibzugriffe eine Invalidation-Nachricht an alle Clients schicken müssen. Als Datenbank wird ZODB verwendet.

Gruß, Thomas

On Tue, Jul 08, 2003 at 11:06:59PM +0200, Torsten Werner wrote:

Am 07. Juli 2003 schrieb Thomas Guettler:

...

Apropos objektorientierte Programmierung: Solange die Daten am Schluss in einer relationalen Datenbank landen, kann die Anwendung nicht wirklich objektorientiert sein.

Aha und wenn die Datenbank plain SQL oder plain files sind, dann kann nach der Theorie die Anwendung auch gar nicht prozedural sein, weil sich keine Prozeduren in der Datenbank speichern lassen?

In einer objektorientierten Datenbank lassen sich in der Regel auch keine Methoden speichern. Die stehen weiterhin im Quelltext.

Deine Aussage erscheint mir recht unsinnig.

Dito

Gruß, Thomas

On Wed, Jul 09, 2003 at 09:39:04AM +0200, Torsten Werner wrote:

Am 09. Juli 2003 schrieb Thomas Guettler:

...

In einer objektorientierten Datenbank lassen sich in der Regel auch keine Methoden speichern. Die stehen weiterhin im Quelltext.

Es gibt zumindest Sprachen, die in der Lage sind, Objekte einzufrieren, auf andere Rechner zu kopieren oder verschieben (inklusive Methoden) und dort wieder zu starten. Wenn das mit Python nicht geht, wäre das nach deiner harschen Forderung auch nicht objektorientiert.

...

...

Deine Aussage erscheint mir recht unsinnig.

Erklärung:

Ich denke, dass du Datenverarbeitung und -speicherung miteinander verwechselst.

Eben genau das verwechsel ich nicht. Ich finde Methoden sollten im Quelltext, also in ASCII-Dateien stehen. Es sicherlich möglich die Methoden zu serialisieren und zu speichern, doch wie will man den Code verändern?

Da man die Daten verarbeitet, die man auch irgendwo speichert, kann man, aus meiner Sicht, von der Speicherung auf die Anwendung rückschließen. Ich bin auf jeden Fall froh zur Zeit nicht mit relationalen Datenbanken arbeiten zu müssen.

Der Vorteil von relationalen Datenbanken ist, dass sie sprachunabhängig sind. Man kann mit jeder beliebigen Programmiersprache zugreifen. Das ist bei objektorientierten Datenbanken meist nicht der Fall.

Auch wenn du Python nicht leiden kannst Torsten, hast du in comp.lang.perl.* schon mal jemanden gesehen, der erzählt wie froh er ist von Python zu Perl zu wechseln? In comp.lang.python gibt es solche Postings (Perl-->Python) alle 2-3 Tage.

Gruß, Thomas

Thomas Guettler wrote:

Apropos objektorientierte Programmierung: Solange die Daten am Schluss in einer relationalen Datenbank landen, kann die Anwendung nicht wirklich objektorientiert sein.

Lassen wir das mal so stehen. Aber wenn eine objekt- orientierte Programmiersprache Klassen fuer den Zugriff auf eine SQL-Datenbank bereitstellt, dann programmiert man meiner Meinung nach trotzdem objektorientiert.

Die Datenbank steht doch nicht im luftleeren Raum. Es gibt doch i.d.R. viele andere Clients, die ebenfalls auf Daten zugreifen muessen und das nur per SQL tun koennen. Der Datenbankserver muss doch allen gerecht werden.

Stefan

.

Am 12. Juli 2003 schrieb Jens Lehmann:

In Java wird nicht alles ins "objektorientierte Korsett" gepresst

Okay, ich bin etwas übers Ziel hinaus geschossen. Es sollte "vieles" oder "zu viel" anstelle "alles" heißen.

Es ist ja auch nicht so schwer ein "Math." vor Deine gewünschte Funktion zu schreiben. Die Alternative wäre eine Funktionssammlung losgelöst von allen anderen Klassen zu haben, was imho nicht sehr erstrebenswert ist.

Wenn du es etwa so wie Andre meinst, bin ich gar nicht dagegen. Aber es gibt Leute, die behaupten von anderen Sprachen, dass diese schlecht oder nicht OO sind, bloss weil man kein Math. vor sin oder exp schreiben. Nur solche Argumente halte ich für Unsinn -- dazu zählt aber auch Thomas' merkwürdige Ansichten über relationale vs. objektorientierte Datenbanken.

Torsten