Neue IDE

[BlackJack]

@burli: Wenn man sich umschaut wo man ein Rahmenwerk für eine IDE herbekommt, das schon alles nötige für Projektverwaltung, Versionskontrolle, usw. mitbringt, man also möglichst wenig selber implementieren muss und schon möglichst viel fertig vorfindet, landet man halt bei so etwas wie Eclipse.

Wenn man die Funktionalität, die es dort schon gibt, selber implementieren wollte, bräuchte man sicher ein paar Jahre um etwas zu bekommen, das annähernd auf dem Stand ist. Auf dem Stand von heute wohlgemerkt.

@Francesco: Ich bin jetzt kein übertriebener Java-Fan, aber es ist auf jeden Fall besser als C++. Ich hatte jedenfalls noch nie das Gefühl das ich Java-Quelltext oder Fehlermeldungen vom Compiler gesehen habe und gedacht habe, das verstehe ich nie. C++ mit Templates und den ganzen Fallen bei der Speicherverwaltung und "exception safety" ist viel schlimmer. Und die Java-Syntax ist einfacher als C++-Syntax. Das ein Semikolon im Anschluss an einem zig Zeilen langen Konstrukt entscheidet ob das nun eine Definition oder eine Deklaration ist, gibt's bei Java nicht.

Und das mit dem "interpretiert werden" ist ein Scheinargument. Letztlich wird alles interpretiert, ob nun von einem Hardwareprozessor oder einer VM. Wobei Java-Implementierungen mit JIT-Compilern arbeiten, also oft auch den Prozessor direkt ansprechen.

[sma]

Scintilla kann schon einiges und ist auch erweiterbar. IMHO eine brauchbare Grundlage.

Vielleicht. Als ich mir Scintilla mal angesehen hatte (und die Dokumentation richtig schlecht fand) sah ich keinen guten Weg, ein eigenes semantisches Highlighting (in Python) einzubauen. Ich meine, man konnte nur aus einer fest verdrahteten Anzahl von Scannern wählen, die im Prinzip nur Schlüsselwörter und Strings nach fest definierten Regeln einfärben konnten.

Was mich bei den ganzen "Python" IDEs am meisten stört ist, dass viele davon in Java programmiert sind, was ich absolut nicht nachvollziehen kann

Eclipse, Netbeans und IntelliJIDEA haben alle als Java-IDEs angefangen und wurden konsequenterweise in Java entwickelt. Die Abneigung von Java und die Präferenz von C++ teile ich auch überhaupt nicht. Ich denke, Java war für Eclipse eine sehr gute Wahl. Und die zehnjährige Erfolgsgeschichte des Projekts gibt mir glaube ich recht.

Stefan

[Francesco]

Ich verstehe nur nicht, wieso man sowas nicht mal in Python schreibt. Dann hätte man als Python Entwickler auch mal bessere Chancen, Erweiterungen dafür zu schreiben.

Eric, spe, ulipad, drpython, pida, editra, boa constructor, active grid... noch nicht genug in python? Ist das alles zu schlecht?

[Francesco]

Scintilla kann schon einiges und ist auch erweiterbar. IMHO eine brauchbare Grundlage.

Vielleicht. Als ich mir Scintilla mal angesehen hatte (und die Dokumentation richtig schlecht fand) sah ich keinen guten Weg, ein eigenes semantisches Highlighting (in Python) einzubauen. Ich meine, man konnte nur aus einer fest verdrahteten Anzahl von Scannern wählen, die im Prinzip nur Schlüsselwörter und Strings nach fest definierten Regeln einfärben konnten.

Gut, dann musst du einen eigenen Lexer implementieren. Ist vielleicht nicht leicht, sollte aber auch nicht unmöglich sein. Man braucht sich "nur" den scintilla code anschauen, wie die bisherigen Lexer implementiert sind. Und die (cxx) files waren kürzer als gedacht.

[BlackJack]

@Francesco: Ich denke das was sma meint ist mit einem Lexer für die Syntax nicht getan. Er möchte gerne semantische Informationen unterbringen. Also zum Beispiel auch das Properties speziell gekennzeichnet werden können, und dazu müsste man analysieren worauf `property()` angewendet wird. Das ist mit einem einfachen Syntax-Highlighter nicht getan.

[Francesco]

Ich weiß nicht, was eine Projektverwaltung genau sein soll. Geht es um die Anbindung einer Versionsverwaltung?

Ich glaube mehr so eine Projektverwaltung wie zb in CodeBlocks, in der die makefiles, directories und ihre Files einfach zu verwalten bzw. zugegriffen werden kann.

Auch der Begriff IDE ist relativ unscharf.

Dem stimme ich zu, jeder versteht da ein bisschen etwas anderes darunter. Die einen wollen viele whistles und bells, die anderen spartanische Sachen, um den Überblick nicht zu verlieren.

Im Prinzip geht es ja darum, alle Werkzeuge zur Entwicklung in einem Werkzeug zu integrieren. Ein wichtiger Aspekt aus meiner Sicht ist aber außerdem, dass die Werkzeuge einen gewissen Standard nicht unterschreiten.

Da wäre vielleicht auch eine gute Hilfe Integration nicht schlecht. Boa Constructor hat das sehr schön integriert.

das automatische Ausführen von Tests, Funktionen zur automatischen Umstrukturierung, einen Debugger, die Anbindung der schon erwähnten Versionsverwaltung und Zugriff auf die API-Dokumentation. Ach, ein Profiler, ein Codecoverage-Werkzeug und ein Bündel von Überprüfungen und Metriken, was Code-Qualität angeht, darf auch gerne vorhanden sein.

Gut, das sind dann schon gehobene Ansprüche. Das ist eine Grundsatzfrage, ob ich alles in der IDE haben muss, oder daneben eine Konsole offen habe. Komfortabler wird das natürlich sein, das drin zu haben. Dann kann ich vielleicht direkt im Editor die Zeile anspringen lassen zb.

Kernkomponente einer IDE ist und bleibt wahrscheinlich der Texteditor.

Da stimme ich 100% überein. Da verzichte ich lieber auf Extras uzugunsten eines Editors, in dem ich viele Funktionen habe, und nach belieben auf shortcuts oder Context menu zuweisen kann.

[Francesco]

@Francesco: Ich denke das was sma meint ist mit einem Lexer für die Syntax nicht getan. Er möchte gerne semantische Informationen unterbringen. Also zum Beispiel auch das Properties speziell gekennzeichnet werden können, und dazu müsste man analysieren worauf `property()` angewendet wird. Das ist mit einem einfachen Syntax-Highlighter nicht getan.

Aha, ok, ja das ist mit einem Syntax Highlighter nicht getan.

[DasIch]

Scintilla kann schon einiges und ist auch erweiterbar. IMHO eine brauchbare Grundlage.

Kommt darauf an was du unter Grundlage verstehst.

Eine brauchbare Editor Basis sollte mehrere write handles von Usern unterstützen. Außerdem sollte es möglich sein ein Fehler toleranten Parser zu verwenden der einen persistenten AST vorhält der für Highlighting usw. genutzt wird. States für unterschiedliche Arten von Eingabe, Ersetzung, Auswahl etc. sollten ebenfalls drin sein um Emacs/Vim ähnliche Bedienung zu ermöglichen.

[Francesco]

Eine brauchbare Editor Basis sollte mehrere write handles von Usern unterstützen

Das habe ich nicht ganz verstanden, was verstehst du unter mehreren "write handles"?

[Francesco]

@Francesco: Ich bin jetzt kein übertriebener Java-Fan, aber es ist auf jeden Fall besser als C++. Ich hatte jedenfalls noch nie das Gefühl das ich Java-Quelltext oder Fehlermeldungen vom Compiler gesehen habe und gedacht habe, das verstehe ich nie. C++ mit Templates und den ganzen Fallen bei der Speicherverwaltung und "exception safety" ist viel schlimmer. Und die Java-Syntax ist einfacher als C++-Syntax. Das ein Semikolon im Anschluss an einem zig Zeilen langen Konstrukt entscheidet ob das nun eine Definition oder eine Deklaration ist, gibt's bei Java nicht.

Und das mit dem "interpretiert werden" ist ein Scheinargument. Letztlich wird alles interpretiert, ob nun von einem Hardwareprozessor oder einer VM. Wobei Java-Implementierungen mit JIT-Compilern arbeiten, also oft auch den Prozessor direkt ansprechen.

C++ mit Templates und STL, ... syntaktisch widerwärtiger geht das ja kaum. Ich erinnere mich noch an VC++, wo wir schon fast jedes file mit einem pragma ignore 4786 oder so ausgestattet haben, weil da template warnings seiteweise den Bildschirm füllten.

Hmm, vielleicht habe ich mit Java noch zu wenig zu tun gehabt. Bei C und C++ ist es (besonders in der Vergangenheit), dass da kaum ein Weg vorbeiführte, hat man nicht Delphi oder Visual Basic, ... programmiert. Ich habe zwei Java Bücher durchgeackert, und da ist es mir jedenfalls schon gründlich vergangen. Der Byte Compile Prozess hat lange gedauert, der Programmstart ebenso. Gut, das war vor zig Jahren, da war wahrscheinlich Java noch zu stark für damalige Rechner.

[DasIch]

Eine brauchbare Editor Basis sollte mehrere write handles von Usern unterstützen

Das habe ich nicht ganz verstanden, was verstehst du unter mehreren "write handles"?

Man sollte in der Lage sein mehrere Handles auf denselben Buffer zu bekommen um gleichzeitig schreibend darauf zuzugreifen, z.B. von unterschiedlichen Prozessen aus oder über ein Netzwerk so dass mehrere Leute gleichzeitig an einer Datei arbeiten können.

[Francesco]

Eine brauchbare Editor Basis sollte mehrere write handles von Usern unterstützen

Das habe ich nicht ganz verstanden, was verstehst du unter mehreren "write handles"?

Man sollte in der Lage sein mehrere Handles auf denselben Buffer zu bekommen um gleichzeitig schreibend darauf zuzugreifen, z.B. von unterschiedlichen Prozessen aus oder über ein Netzwerk so dass mehrere Leute gleichzeitig an einer Datei arbeiten können.

Aha. Ja, m. E. schon sehr spezielle Sachen. Ist die Frage, ob man so etwas nicht spezialisierten Programmen überlassen sollte, als die eierlegende ... eh schon wissen, erfinden soll. Ich bin da entschieden der Meinung, so etwas braucht es nicht. Für Debuggen starte ich eine debugger, Text Editor (von mir aus mit der Projektverwaltung) statt Ide, GUI Designer statt IDE, svn Programm statt integrierter Sache. Dann hat man eventuell ein paar Programme nebeneinander offen, aber was macht das schon. Wichtig ist mir jedoch schon, dass ich make aufrufen kann bzw. das Projekt gleich starten kann und aufgrund des tracebacks/compilerfehlers direkt mit Doppelklick oder Hotkey im Editor das File mit der Zeilennummer aufmacht.

[DasIch]

Das Problem ist ja gerade dass es für sowas spezielle Editoren gibt, die können dass dann zwar auch ganz toll aber sonst nichts und wenn doch bin ich zumindest nicht mehr in meiner gewohnten Umgebung. Gerade als vim User stört mich sowas gewaltig da mein Editor schon stark an meine Bedürfnisse angepasst ist und ich bin mir sicher andere vim/emacs User stört sowas ebenfalls.

Ich möchte einfach mal jemanden kurz um Hilfe Fragen oder in der Entwicklung etwas zeigen können ohne meinen Code committen und pushen zu müssen oder es in einen pastebin zu packen.

[BlackJack]

@Francesco: Java ist ohne ordentliche IDE nicht zu gebrauchen. Eclipse zum Beispiel ist zwar recht "gross", da merkt man aber dafür das Kompilieren in Bytecode nicht mehr, weil das von Eclipse inkrementell gemacht wird, schon während man den Quelltext schreibt.

[Leonidas]

Genau das mag ich auch gar nicht, java ist ja noch schlimmer als C++. Etwas was so umständlich in der Syntax ist, was kompiliert wird, um dann doch wieder interpretiert zu werden...

Naja, ich mag Java auch an vielen Stellen nicht (ob ich aber C++ vorziehen würde - keine Ahnung, finde das auch nicht so toll) aber das interpretiert-Argument ist doch Quatsch. Denn so gesehen könnte man das gleiche Argument für Python auch anführen: Python-Code wird transparent (oder auch nicht, wenn man explizit kompiliert) zu Bytecode kompiliert und dieser wieder interpretiert. Schlimmer noch, im Fall von Python wird dieser Code tatsächlich noch interpretiert, wo viele JVMs den JIT-Compiler auspacken. Und im Gegensatz zu Java mit GCJ gibt es auch für Python kein GCC-Frontend, das nativen Code generiert. Python muss ja wohl noch viel schlimmer als Java sein.

Btw, IDEA hat auch mindestens zwei Passes beim Scannen von Code. Das sieht man etwa im Scala-Plugin, das manchmal durcheinanderkommt und das semantische Highlighting abschaltet, so dass nur statisches, Pygments-like Highlighting übrigbleibt.

[burli]

Nungut, lassen wir Eclipse und Java mal außen vor. Eine komplette Neuentwicklung wäre zeitaufwändig. Als Kompromiss könnte man Editra erweitern. So schlecht ist die Basis ja nicht.

Was mir hauptsächlich fehlt ist wie gesagt eine Projektverwaltung. Unter einer Projektverwaltung verstehe ich nicht nur die Verwaltung der Dateien sondern alles, was irgendwie Projekt spezifisch ist. Bei vielen Editoren/IDEs gibt es solche Funktionen wie Versionskontrolle nur als globale Funktion. Für mich gehört das aber in ein Projekt.

Für ein generisches Python Projekt könnte man z.B. Module Tests hinzufügen, für ein PyQt Projekt die Verwaltung der ui Dateien und den Aufruf des Designers integrieren (entsprechendes natürlich auf für GTK, wx oder Tk) und für ein Flask Projekt gehört eine Möglichkeit dazu, ein fertiges Projekt via FTP oder SSH auf einen Server hochzuladen.

Das sind jetzt nur mal so grob zusammengefasst meine Vorstellungen einer Projektverwaltung ohne Anspruch auf Vollständigkeit oder Fehlerfreiheit.

[Francesco]

Für den svn teil könntest du dir workbench ansehen. Es ist wie Editra in wxPython implementiert und so gesehen sollte es nicht allzuschwer sein, ein svn plugin in Editra zu schreiben.

http://pysvn.tigris.org/docs/WorkBench.html

[DasIch]

Für den SVN(wer nutzt das noch?) Teil würde ich mir eher anyvc anschauen, dann hat man auch gleich Git, Mercurial und Bazaar support.

[Francesco]

Für den SVN(wer nutzt das noch?) ...

Ich hake hier immer gern nach. Nicht dass ich so etwas grundsätzlich in frage stellen würde, aber mich interessiert:

a) wie kommt es zu einer solchen verallgemeinernden Aussage
b) was bieten git, mercurial, etc. was svn nicht bietet
c) beinhaltet auch b) warum gehen doch viele Projekte weg vom svn (wie ich auch schon selbst bemerkt habe) Vor ein paar Jahren wanderte ja vieles vom cvs nach svn. Andere Sachen sind anscheinend um einiges langlebiger als die Versionsverwaltung.

[DasIch]

Ein DVCS kann alles was SVN auch kann und erlaubt exakt dasselbe Entwicklungsmodell. Zusätzlich ist man allerdings nicht an einen Server gebunden, merges und damit branches und forks sind absolut kein Problem und unglaublich einfach und schnell zu machen. Austausch von Code untereinander ohne ihn über den Server öffentlich machen zu müssen ist ebenfalls ein großer Vorteil. Zusätzlich ist man in der Lage unterwegs im Bus, Zug, Flugzeug, Taxi oder wo auch immer man sonst gerade keinen Zugriff auf das Repository ohne Probleme weiter zu arbeiten.

Desweiteren kann man andere Entwicklungsmodelle nutzen, die komplett ohne zentralen Server auskommen oder auf einer Hierachie basieren die es ermöglicht Zuständigkeiten besser aufzuteilen. Bei Linux ist es z.B. so dass Torvalds an der Spitze steht und es Maintainer für Subsysteme gibt die jeweils ihr eigenes Repo haben aus denen Torvalds pulled, wer eine Veränderungen an einem Subsystem machen will spricht dann den jeweiligen Maintainer an.

Eine sehr gute Erklärung zu den Vorteilen (speziell von Git/Github lässt sich aber prinzipiell auf andere DVCS ausweiten) findet man in den Slides von Chris Wanstraths Talk auf der Djangocon 2009. Chris ist natürlich als einer der Gründer von Github sicherlich nicht ganz objektiv allerdings tut dass dem ganzen keinen Abbruch.

Ein konkretes Beispiel wäre auch die Entwicklung von Sphinx in diesem Sommer, Sphinx hat für jede größere Version einen Fork, genauso für größere Änderungen. Im Rahmen des GSoC wurde Sphinx auf 3.x portiert, web-support und i18n entwickelt. In dieser Zeit hatten wir immer 6 aktive Forks, 3 für jeden Studenten und weitere 3 zur Review. Zwischenzeitlich kamen wir auf 11 aktive Forks, zusätzlich zu denen für noch supportete Versionen ohne deswegen in Probleme zu geraten.