Python IDE Roundup zum Jahresbeginn..

[sma]

Noch was zu dem Hinweis auf Bespin und Vim per SSH. Ich glaube, es ging nicht darum, Remote auf einem anderen Rechner zu arbeiten, sondern dadurch, dass mein Programm parallel zur IDE (als Server) läuft, kann diese (als Client) Informationen zur Laufzeit über das Objektmodell erfragen und so z.B. eine korrekte Code-Completion bieten. Und das kann Vim, Pico oder welcher Editor auch immer eben gerade nicht. Das von mir erwähnte WebVelocity für Seaside oder aber auch die Squeak-basierte IDE für Gemstone kann gerade eben dies und wie ich gehört habe, will Gemstone diese Form der Entwicklung dann auf im Rahmen von Maglev für Ruby anbieten. Bespin hilft in dieser Beziehung auch nicht wirklich weiter, weil es eben nur ein Editor ist, dessen Textdokument einfach auf einem Server gespeichert wird, nicht aber eine IDE, die Zugang zu einem laufenden System hat.

Stefan

[burli]

Bedank dich bei Java und bete, dass keiner auf die Idee kommt, ein OS in Java zu schreiben. Dann brauchste erst richtig Speicher

Das ist einfach Blödsinn. Java-Programme verbrauchen auch nicht mehr Speicher als äquivalente Programme in anderen Sprachen, wenn diese ebenfalls Garbage Collection und einen vergleichbaren Funktionsumfang haben.

Naja, Eclipse braucht bei mir gerade 280MB RAM. Und mir ist ehrlich gesagt noch kein Java Programm untergekommen, das gemessen an seiner Funktion, "wenig" verbraucht. Vergleichbare Programme in anderen Sprachen (C#, Python) brauchen erheblich weniger.

Ob das an Java oder an der kollektiven Unfähigkeit der Java Programmierer liegt weiß ich nicht. Aber für meinen Geschmack war bisher jedes Java Programm zu groß

[sma]

Schon Einstein "lernte" uns ja: Alles ist relativ. 280MB ist für mich wenig. Das sind 7% meines Hauptspeichers. Finde ich nicht schlimm im Vergleich zu den Funktionen (für die Java-Entwicklung).

Was man bei Java immer bedenken muss: Der JVM muss im Gegensatz zu den meisten anderen Sprachen und virtuellen Maschinen immer mitgeteilt werden, wie viel RAM sie maximal nutzen darf und das ist dann auch das RAM, was sie wirklich benutzt bevor sich der GC mal bequemt, aufzuräumen. Damit man da keine Probleme hat, wird dieser Bereich gerne von Java-Entwicklern großzügig bemessen, denn er muss ja so groß sein, dass er auch in Extremfällen reicht. Leider hat das zur Folge, dass diese Extremfälle die Norm werden und Java eben immer diese Menge an RAM verbraucht. Das ist die "kollektive Unfähigkeit". Durch die Art, wie die JVM funktioniert, sind sie Unfähig, Programmen nur wenig Speicher zuzuweisen und gleichzeitig auch für Extremfälle viel Speicher in Reserve zu haben.

Stefan

[Leonidas]

Was man bei Java immer bedenken muss: Der JVM muss im Gegensatz zu den meisten anderen Sprachen und virtuellen Maschinen immer mitgeteilt werden, wie viel RAM sie maximal nutzen darf und das ist dann auch das RAM, was sie wirklich benutzt bevor sich der GC mal bequemt, aufzuräumen.

Das ist IMHO gerade für Desktopapplikationen der schlechteste Weg den man überhaupt nehmen kann.

[burli]

Was man bei Java immer bedenken muss: Der JVM muss im Gegensatz zu den meisten anderen Sprachen und virtuellen Maschinen immer mitgeteilt werden, wie viel RAM sie maximal nutzen darf und das ist dann auch das RAM, was sie wirklich benutzt bevor sich der GC mal bequemt, aufzuräumen.

Das ist IMHO gerade für Desktopapplikationen der schlechteste Weg den man überhaupt nehmen kann.

Und nicht jeder hat 4GB RAM und mehr. Von meinen 4GB RAM sind immerhin 40% belegt, was zum Teil aber an 64 Bit liegt. Aber den mit Abstand größten Happen frisst Eclipse.

[/me]

Und nicht jeder hat 4GB RAM und mehr. Von meinen 4GB RAM sind immerhin 40% belegt, was zum Teil aber an 64 Bit liegt. Aber den mit Abstand größten Happen frisst Eclipse.

Ich entwickele häufig an meinem Laptop mit 1GB RAM. Da merkt man langsam die Grenzen.

[Hyperion]

Deshalb kann man aber imho Eclipse nicht schlecht machen - wenn ich keinen Ersatzakku habe, ist das Arbeiten mit einem Akkuschrauber auch nicht komfortabel, sobald der Akku leer ist. Da muss man eben durchaus auch nach seiner eigenen Infrastruktur entscheiden, welches Werkzeug geeignet ist.

Ohne Eclipse würde ich bei der Java Programmierung jedenfalls ******! (Es mag da auch andere gute IDEs geben!) Für meine Python Programme brauchte ich bisher noch keine IDE; bei Java ist man ohne imho aufgeschmissen.

[burli]

Ich sage ja nicht, dass Eclipse schlecht ist. Ich bin nur der Meinung, dass Java eine schlechte Wahl ist, egal für was.

Eclipse komplett in C++ programmiert wäre doppelt so schnell und würde nur halb so viel Speicher brauchen. Und richtig programmiert wäre es genauso portabel

[Hyperion]

Ich sage ja nicht, dass Eclipse schlecht ist. Ich bin nur der Meinung, dass Java eine schlechte Wahl ist, egal für was.

Das kann man sicher nicht pauschalisieren - wir haben hier im Institut Programme, bei denen es (leider) nur Schnittstellen für Java gibt. Da ist dann logischer Weise Java eine gute Wahl, wenn ich diese nutzen muss - denn da noch einen Wrapper zwischen zu setzen schafft mehr Probleme, als es lösen würde...

Es kommt imho durchaus auf die Rahmenbedingungen an. (Auch wenn ich Java auch nicht so wirklich leiden kann - aber ich mochte Bio in der Schule auch nie )

Eclipse komplett in C++ programmiert wäre doppelt so schnell und würde nur halb so viel Speicher brauchen. Und richtig programmiert wäre es genauso portabel

Hm... auch da käme es sicherlich auf verschiedene Dinge an (Framework / GUI-Toolkit, usw.) Und Java ist ja bei weitem nicht mehr so langsam wie es mal war durch JIT usw.)

Die Betonung muss aber nun einmal auf dem "wäre" und "würde", ergo dem Konjunktiv liegen! Es ist nun einmal nicht in C++ geschrieben

[cofi]

Die Betonung muss aber nun einmal auf dem "wäre" und "würde", ergo dem Konjunktiv liegen! Es ist nun einmal nicht in C++ geschrieben

Dazu kommt noch, dass C++ nur _theoretisch_ schneller ist, auch in Java lassen sich effiziente Algorithmen schreiben, vor allem aber laesst sich auch unperformanter C++-Code schreiben (von der Fehleranfaelligkeit will ich gar nicht erst anfangen).

[Leonidas]

Uh, was war nochmal das Thema?

[BlackJack]

Na ganz offensichtlich "Java ist doof, langsam, und ein Speicherfresser."

[cofi]

Na ganz offensichtlich "Java ist doof, langsam, und ein Speicherfresser."

Na aber doch erst "Eclipse ist langsam und ein ressourcenschwein" , aber vielleicht sollte man wirklich mal aufraeumen.

[Leonidas]

vielleicht sollte man wirklich mal aufraeumen.

Ooch, ich glaub die Diskussion ist verlaufen, wie wir es erwartet haben. Erstmal ein paar Aufrufe dass IDEs nicht so schlecht sind, dann ein wenig Diskussion über Tab-Completion und schließlich ein Flame über andere Programmiersprachen. Na dann auf ein Neues, 2011!

[mkesper]

Um nochmal auf einen interessanteren Aspekt zurückzukommen: Es gibt die Möglichkeit, Emacs als Client und Server zu benutzen. Das wäre unter Umständen noch pfiffiger als die gvim-screen-Variante.

[jens]

Und noch was anderes: Ich benutzte NX um von Windows aus auf den Linux Rechner zu gelangen und programmiere dann in Eclipse... Das geht lokal und auch übers Netz.

[sma]

Das ist IMHO gerade für Desktopapplikationen der schlechteste Weg den man überhaupt nehmen kann.

Der konstante Speicherbedarf ist zugegeben suboptimal, doch wenn er jetzt beliebig wachsen würde (wie z.B. bei Python, Ruby, .NET, usw.), würden sich die Leute wahrscheinlich auch wieder beschweren. Und es macht den GC-Algorithmus einfacher (und damit schneller). Dennoch würde auch ich mir wünschen, es gäbe einen Client-Modus, wo ich Java einfach so viel RAM holt, wie es eben braucht, ohne einen OutOfMemoryError zu werfen, wenn das Betriebssystem noch RAM hat.

Von meinen 4GB RAM sind immerhin 40% belegt

Wenn ich 4GB RAM habe, dann will ich auch, dass sie alle belegt sind. Was nützen 60% brach liegender Hauptspeicher? Somit kann ich nicht nachvollziehen, wieso dann ein Eclipse, welches nur einen Teil der benutzen 1.6 GB belegt, irgendwie stört.

Eclipse komplett in C++ programmiert wäre doppelt so schnell und würde nur halb so viel Speicher brauchen. Und richtig programmiert wäre es genauso portabel

Das ist eine IMHO unhaltbare weil komplett unbewiesene Behauptung. Als Eclipse vor 8 Jahren noch relativ neu war, habe ich mich recht intensiv mit der Implementierung auseinander gesetzt und da sind mir keine Datenstrukturen aufgefallen, die nun ineffizient oder extra verschwenderisch gewesen wären. Und Java-Objekte verbrauchen (im Gegensatz zu z.B. Python-Objekten) nicht mehr Hauptspeicher als das selbe Objekt in C++, wenn man dort ebenfalls GC einsetzt. Die JVM hat einen Overhead, in dem sie den Bytecode für alle Java-Klassen vorhalten muss und eben selbst auch Platz im RAM verbraucht. Das mögen einige MB sein, doch wenn man in C++ z.B. Qt benutzen würde, käme auch hier eine nicht unerhebliche Menge RAM-Bedarf hinzu. Da Java und C++ auch von der Geschwindigkeit in der selben Größenordnung liegen, halte ich die Behauptung, dass ein Programm dann doppelt so schnell ablaufen würde, einfach nur für falsch.

Meine Behauptung wäre eher, dass das ganze in C++ deutlich schwerer gewesen wäre (man muss ja bedenken, dass Eclipse vornehmlich in Eclipse entwickelt wurde und das Anfang 2000 die beste und fortschrittlichste Java-IDE war und diese auch definitiv besser als alle C++-Editoren zu diesem Zeitpunkt war) und die große Gefahr da gewesen wäre, nie das Projekt abzuschließen und etwas zu "delivern".

Aber vielleicht beruhigt ja alle, zu wissen, dass der Parser-Generator, mit dem der Kern für den Java-Compiler von Eclipse gebaut wurde, ein C++-Programm war (vielleicht sogar immer noch ist). Das war großer Mist, denn so konnte man das JDT nicht direkt aus Eclipse heraus komplett neu bauen, sondern es war immer ein mühsam irgendwo auf IBMs Alphaworks-Seiten verstecktes komisches Prorgamm zu benutzen, wenn man den Parser hätte ändern wollen. Da hatte auch ein Researcher die Idee, C++ wäre eine gute Wahl.

Ich stimme Hyperion zu, bei Java ist die Entwicklung ohne eine IDE mit den funktionen von Eclipse bzw. dem JDT in Eclipse undenkbar. Das war damals ein Meilenstein, was die Unterstüzung angeht und der Abschied von einem Editor, aus dem man einfach Compiler und/oder Debugger heraus aufrufen kann zu einer Sprachmodell-getriebenen Code-Unterstützung (nicht dass es nicht sowas auch schon früher gegeben hätte - z.B. für Lisp - aber nix davon war Mainstream). Eines der Killer-Feature (die auch weder Netbeans noch IntelliJ aufgegriffen haben) ist und war, dass Eclipse inkrementell kompiliert. Eclipse war damals fast so bequem wie Smalltalk... seufz ;)

Noch ein Punkt zu dem IDE-Thema und der Client/Server-Diskussion, die IMHO immer noch nicht darum geht, ob man nun per X, NX oder VNC auf ein entferntes GUI zugreifen kann, sondern ob man sich an einen als Server laufendes Laufzeitsystem anflanschen kann und so während der Entwicklung auf (Typ-)Informationen aus dem laufenden Programm zugreifen kann: Das beste und vielleicht älteste Beispiel dafür ist natürlich der Emacs mit seinem Lisp-Mode. Ich weiß nicht genau, wie lange es SLIME schon gibt, aber damit ist genau dies möglich: Ich verbinde mich mit einem laufenden Lisp-System und kann dort interaktiv Codeschnipsel ausführen, habe dort Informationen, die für Code-Completion benutzt werden können und habe noch am ehesten das Gefühl, in einen lebenden System wie damals in Smalltalk zu arbeiten. Ich meine die zur selben Zeit wie Smalltalk erhältlichen Lisp-Maschinen arbeiteten genauso.

Irgendwann, vielleicht mit dem aufkommen von TurboPascal, hat sich dann die Idee festgesetzt, das beste, was man haben kann, ist ein Texteditor, aus dem man vielleicht einen Compiler aufrufen kann. Später kam dann als "Innovation" noch Syntaxhighlighting dazu. Eigentlich schade.

Stefan

[Hyperion]

Na dann auf ein Neues, 2011!

Du glaubst also, dass sich das ändern wird? Optimist!

[cofi]

Na dann auf ein Neues, 2011!

Du glaubst also, dass sich das ändern wird? Optimist!

Der Optimist bist du. Ich habe das Gegenteil daraus gelesen

Weil wir gerade bei Eclipse sind, moechte ich mal Eclim einwerfen, mit dem man Vim in Eclipse bzw Eclipse in Vim nutzen kann, da ich atm in Java arbeiten muss und Vim nicht missen will ist das eine recht gute Mischung.

[mpathy]

Na dann auf ein Neues, 2011!

Du glaubst also, dass sich das ändern wird? Optimist!

Der Optimist bist du. Ich habe das Gegenteil daraus gelesen

Weil wir gerade bei Eclipse sind, moechte ich mal Eclim einwerfen, mit dem man Vim in Eclipse bzw Eclipse in Vim nutzen kann, da ich atm in Java arbeiten muss und Vim nicht missen will ist das eine recht gute Mischung.

Tja ja. Ich finde sogar, der Thread hat sich erstaunlich lange ohne Flames und Totschlagargumente gehalten.

Vim Plugins gibts inzwischen bei allen ernstzunehmenden IDEs denke ich.

Für Netbeans z.B.:

http://jvi.sourceforge.net/
oder
http://viex.sourceforge.net/

Auch Komodo Edit, das ich gerade nutze, bietet sowas in der Art:
http://docs.activestate.com/komodo/5.2/vikeybind.html

Die Umgewöhnung wird einem also leicht gemacht.

Wobei es ja nicht um Umgewöhnung geht, eher darum seinen Horizont ab und zu mal über die Vim-Nußschale hinaus zu erweitern und ggf. ein neues Werkzeug (PS: Ist auf das Wort "Werkzeug" jetzt schon ein TM drau, mitsuhiko? *g*) in seinen Werkzeugkoffer aufzunehmen.