Azazyel und CrimsonKing streiten sich um Editoren und IDEs

[CrimsonKing]

Ich verstehe auch nicht, warum sich manche so vehement gegen IDEs sträuben und an ihrem Texteditor des Vertrauens festhalten. Selbst mit mittelmäßiger Beherrschung der IDE ist man deutlich produktiver als man es mit einem Texteditor jemals sein könnte.

Nein.

Liegt das in diesem Fall nicht eher an deiner jahrelangen Vertrautheit mit Emacs und mangelnden Erfahrung mit PhpStorm?

Ich habe IDEs (Aptana und dergleichen) schon vor Jahren benutzt, Emacs seit Ende 2013. Nein, liegt es nicht. PHPStorm ist einfach unpraktisch.

Es lohnt sich, vim zu lernen. Schau Dir mal vimtutor mal an. Einfach auf der Kommandozeile im Terminal tippen.

Emacs hat ein Tutorial zum Anklicken direkt auf der "Startseite", ein Webbrowser kommt mit 24.4, Plugins sind per eingebautem Plugin"manager" einfachst zu installieren/deinstallieren...

 

[Azazyel]

Nein.

Wenn ich mir anschaue, dass Emacs bei exotischen Programmiersprachen wie Java nicht mal mit Generics umgehen kann (ein Feature von Java 5 anno 2004).
Wie soll man da Emacs als IDE-Alternative ernst nehmen?!

 

[CrimsonKing]

Dein Fehler ist, dass du Java ernst nimmst.

(Ach, richtig, Java-Entwickler: Überfordert, wenn ihnen das IDE mal nicht den halben Code vorgibt.)

 

[Azazyel]

Dein Fehler ist, dass du Java ernst nimmst.

Umgekehrt wird ein Schuh draus: wenn Emacs nicht einmal den Support für die populärste und verbreiteste Programmiersprache hinkriegt, wie sieht es dann erst beim Rest aus?

(Ach, richtig, Java-Entwickler: Überfordert, wenn ihnen das IDE mal nicht den halben Code vorgibt.)

Sprach der Herr, der seine Bastellust an Kundensystemen auslassen möchte.
Gib Bescheid, sobald du mal Software entwickelst, deren kompletter Quellcode nicht mehr in ein 80x25-Terminal passt.

Aber zurück zu ShawnSteins Anliegen: unabhängig davon, welcher Editor jetzt "besser" ist, würde ich allein aufgrund der Omnipräsenz des vi demselbigen den Vorzug geben.

 

[CrimsonKing]

Umgekehrt wird ein Schuh draus: wenn Emacs nicht einmal den Support für die populärste und verbreiteste Programmiersprache hinkriegt

Was hast du am C++-Support auszusetzen?

Gib Bescheid, sobald du mal Software entwickelst, deren kompletter Quellcode nicht mehr in ein 80x25-Terminal passt.

Naja.

 

[Azazyel]

Was hast du am C++-Support auszusetzen?

Das er für C++ ist: C++ FQA
C++ war mal die populärste Programmiersprache, schafft es nur noch auf Platz 5 (Tendenz fallend): PYPL PopularitY of Programming Language index.

Emacs mit CEDET fühlt sich an wie die ersten IDEs: eine Ansammlung von Features ohne vernünftige Integration derselbigen, aber mit den ganzen Nachteilen. Vieles funktioniert nicht gut genug (komplexes Refactoring, Unit Testing, etc.) oder erst nach massiven Customizing.

Mein gefühlt größter Showstopper für große Projekte in Emacs (Stand 2013) ist aber die Performance. Dank der Abwesenheit von Multi-Threading hängt Emacs bei komplexem Code zwischendurch schon mal komplett für 10-20 Sekunden (nicht einmal Texteingabe funktioniert). Das kriegt man zwar durch Tuning der semantic- und semanticdb-Parameter halbwegs in den Griff, dann funktioniert aber die Code Completion nicht mehr richtig.
Das kann selbst CDT besser.

Von den Unzulänglichkeiten von Emacs und JDEE will ich erst gar nicht anfangen...

Naja.

Bevor ich mich jetzt durch deine "pet projects" wühle: was war das größte professionelle Projekt (in Lines of Code), in dem du CEDET je im Einsatz hattest und deiner Meinung nach die Vor- bzw. Nachteile im Vergleich zu IDEs in diesem Kontext?
Dein Erfahrungsbericht würde mich interessieren.

 

[CrimsonKing]

Von den Unzulänglichkeiten von Emacs und JDEE will ich erst gar nicht anfangen...

Emacs ist wenigstens nicht in Java programmiert. Startet also schnell.

Bevor ich mich jetzt durch deine "pet projects" wühle: was war das größte professionelle Projekt (in Lines of Code), in dem du CEDET je im Einsatz hattest und deiner Meinung nach die Vor- bzw. Nachteile im Vergleich zu IDEs in diesem Kontext?

Ich verwende kein CEDET, ist mir zu Bloat. Screenshot von meinem Bürolaptop:



Emacs mit Code (links) und ERC (rechts; irgendwo neulich ist mir da das Encoding flöten gegangen, beizeiten mal korrigieren). Ja, ich verdiene mein Geld mit PHP. Alles Andere mach' ich als Hobby.

 

[Azazyel]

Refactoring, das Code Browsen, die eingebaute Dokumentationsanzeige, die semantische Code Suche (Find Uses) usw. sind noch die Basics aber helfen mir sehr bei der Arbeit.

Das kann ich nur mit ganzem Herzen unterschreiben. Ich war auch viele Jahre ein Verfechter der "klassischen" Texteditoren, musste aber im Laufe der Jahre erkennen, dass man mit einer guten IDE einfach besseren Code in kürzerer Zeit entwickelt.

Wie jedes mächtige Tool braucht auch eine IDE eine gewisse Einarbeitungszeit. Wer aber einmal die Lernkurve hinter sich gebracht hat, blickt reumütig auf seinen Texteditor zurück und fragt sich, wie und warum er all die Jahre ohne IDE gearbeitet hat.

Umso erschreckender ist dann die Erkenntnis, wenn man spaßeshalber mal wieder im Texteditor programmiert - und merkt, wieviel Zeit man dort mit trivialen Tätigkeiten verschwendet, die im Alltag von der IDE erledigt werden.
Wie viele subtile Bugs man im Texteditor produziert (man ist schließlich nur ein Mensch), auf die eine IDE ganz nonchalant sofort hinweist.
Wie viele Refactorings man unterlässt, weil sie im Texteditor viel zu viel Aufwand wären, in der IDE aber nur einen Tastenkombination entfernt sind.
Wie wenig Überblick man über den Code im Texteditor hat, weil die IDE so viel mehr kann als nur Syntax-Highlighting.

 

[CrimsonKing]

dass man mit einer guten IDE einfach besseren Code in kürzerer Zeit entwickelt.

Früher war Codequalität ja noch abhängig vom Programmierer. Mensch, wenn die von OpenSSL nur gewusst hätten, dass sie ein besseres IDE brauchen!

Wer aber einmal die Lernkurve hinter sich gebracht hat, blickt reumütig auf seinen Texteditor zurück und fragt sich, wie und warum er all die Jahre ohne IDE gearbeitet hat.

Seit ich im Studium eclipse nutzen musste, hab ich angefangen, Texteditoren wertzuschätzen.

Wie viele subtile Bugs man im Texteditor produziert (man ist schließlich nur ein Mensch), auf die eine IDE ganz nonchalant sofort hinweist.

Welcher leidlich akzeptable Texteditor entdeckt denn zum Beispiel keine Klammerfehler?

Wie wenig Überblick über den Code im Texteditor man hat, weil die IDE so viel mehr kann als nur Syntax-Highlighting.

Wenn du deinen Code nicht mehr überblickst, ist er scheiße strukturiert.

 

[Azazyel]

Früher war Codequalität ja noch abhängig vom Programmierer. Mensch, wenn die von OpenSSL nur gewusst hätten, dass sie ein besseres IDE brauchen!

Auch mit einer IDE gibt es nach wie vor Bugs, wenn auch weniger als ohne. Jeder Programmierer sollte wissen, dass er Fehler macht, und möglichst viele davon automatisch abfangen (angefangen durch den Einsatz einer IDE über statische Codeanalyse bis hin zu Continuous Integration etc.).

Aber nett, dass du Heartbleed erwähnst: eben jener code smell wäre mit der statischen Codeanalyse einer IDE schon bei der Entwicklung aufgefallen.

Seit ich im Studium eclipse nutzen musste, hab ich angefangen, Texteditoren wertzuschätzen.

Eclipse zähle ich persönlich nicht zu den guten IDEs. Bei den trivialen und überschaubaren Programmen, die man während des Studiums schreibt, kommt man aber auch ohne IDE noch gut hin.

Welcher leidlich akzeptable Texteditor entdeckt denn zum Beispiel keine Klammerfehler?

Fehlende oder überzählige Klammern sind keine subtilen Bugs, sondern simple Syntaxfehler.
Welche Texteditor erkennt sinnlose logische Operationen? Eventuell nicht initialisierte Variablen?

Wenn du deinen Code nicht mehr überblickst, ist er scheiße strukturiert.

In der realen Welt ist es meistens mehr als eine Person, die an einer Codebasis arbeitet. Ab einer gewissen Größe und Komplexität lässt es sich kaum vermeiden, dass der Code zumindest vorübergehend unübersichtlich und unpassend strukturiert ist. Von externen Faktoren wie geänderten Anfordungen mal ganz zu schweigen, die rückblickend dazu führen können, dass man die Codebasis ganz anders strukturiert hätte - hätte man es vorher gewusst.

Viel Spaß, wenn du dich jetzt ohne IDE in ein solches Projekt einarbeiten, geschweige denn Refactorings zur Verbesserung der Struktur machen möchtest. Mit einem Texteditor lassen sich solche Alltagsarbeiten nur mit massivem Aufwand, wenn überhaupt, erledigen.

 

[CrimsonKing]

Auch mit einer IDE gibt es nach wie vor Bugs, wenn auch weniger als ohne.

Das halte ich für vorschnell.

eben jener code smell wäre mit der statischen Codeanalyse einer IDE schon bei der Entwicklung aufgefallen.

Kein OpenSSL-Entwickler nutzt ein IDE? Kein einziger? Sicher?

Klingt eher nach "menschliches Versagen, IDE hilft kein bisschen".

Eclipse zähle ich persönlich nicht zu den guten IDEs.

Ich rechne Eclipse seine Vielseitigkeit hoch an (und so was hier), bevorzuge privat auch IntelliJ und Visual Studio, wenn's denn mal ein IDE sein muss; aber das muss es erfreulicherweise fast nie.

Ab einer gewissen Größe und Komplexität lässt es sich kaum vermeiden, dass der Code zumindest vorübergehend unübersichtlich und unpassend strukturiert ist.

Ab wie vielen LoC ist das denn notwendig, dass man in einem Team auf Modellierung oder wenigstens Besprechung verzichtet? Bei OpenBSD geht das auch: Scheiße formatierter/geschriebener Code kommt gar nicht erst durch die QS.
Aber ist natürlich ein Zwergenprojekt.

Viel Spaß, wenn du dich jetzt ohne IDE in ein solches Projekt einarbeiten, geschweige denn Refactorings zur Verbesserung der Struktur machen möchtest

Ich musste noch nie in dermaßen unorganisierten Teams arbeiten. Fremden Code krieg ich manchmal vorgesetzt, den strukturiere ich aber immer erst sinnvoll, bevor ich da was anderes dran mache.

 

[Azazyel]

Kein OpenSSL-Entwickler nutzt ein IDE? Kein einziger? Sicher?

Das war nicht meine Aussage. Wenn die betroffene Codestelle nur von einer wenigen Personen jemals angeschaut wurde und diese Personen keine IDE (bzw. keine IDE mit vernünftiger statischer Code-Analyse) benutzt haben (oder noch schlimmer, deren Hinweis ignoriert hat), sitzt das Problem vor der Tastatur.
Ein Texteditor gibt aber in keinem Fall einen Hinweis auf etwaige Probleme.

Klingt eher nach "menschliches Versagen, IDE hilft kein bisschen".

Wäre es ein simpler Bug und sonst alles mit dem Projekt in Ordnung, würde das OpenBSD-Team einen Fork starten?

Ab wie vielen LoC ist das denn notwendig, dass man in einem Team auf Modellierung oder wenigstens Besprechung verzichtet?

Selbst mit noch so viel Modellierungsrunden und Besprechungen erreicht man spätestens nach der Implementierung den Punkt, an dem man sich denkt: "Würde ich es jetzt nochmal implementieren müssen, würde ich dieses und jenes anders strukturieren."

Bei OpenBSD geht das auch: Scheiße formatierter/geschriebener Code kommt gar nicht erst durch die QS.

Welcher Anfänger formatiert seinen Code heutzutage noch von Hand? Das macht man per Template.

Der Code kann außerdem noch so gut geschrieben sein und jede QS passieren - wenn man nicht aufpasst, hat man am Schluss einen big ball of mud. Man kann auch mit jeweils hervorragend geschriebenem Code Stück für Stück eine schlechte Architektur erschaffen.

Aber ist natürlich ein Zwergenprojekt.

OpenBSD ist vor allem ein sehr stabiles Projekt, das auf sehr viele Features verzichtet (und von Faktoren wie Deadlines oder Budgets verschont bleibt). Mit einer gut abgehangenen Code-Basis, bei der man auf große Änderungen verzichtet, tut man sich auch mit größeren strukturellen Änderungen sehr leicht - man unterlässt sie einfach.

Ich musste noch nie in dermaßen unorganisierten Teams arbeiten.

Selbst mit hervorragend organisierten Teams erstklassiger Entwickler passiert so etwas ganz natürlich. Schlimm ist nur, wenn man es nicht mitbekommt.

Fremden Code krieg ich manchmal vorgesetzt, den strukturiere ich aber immer erst sinnvoll, bevor ich da was anderes dran mache.

Wie darf ich mir das bei einem Projekt mit einer sechs- oder siebenstelligen Anzahl LoC vorstellen?

 

[CrimsonKing]

Ein Texteditor gibt aber in keinem Fall einen Hinweis auf etwaige Probleme.

Ein IDE offenbar auch nicht. Oder guckt ein IDE auch nur Teile des Codes an?

Wäre es ein simpler Bug und sonst alles mit dem Projekt in Ordnung, würde das OpenBSD-Team einen Fork starten?

Mit vi ist auch alles in Ordnung, trotzdem nutzen Leute lieber Vim.

erreicht man spätestens nach der Implementierung den Punkt, an dem man sich denkt: "Würde ich es jetzt nochmal implementieren müssen, würde ich dieses und jenes anders strukturieren."

Darum plant man das vorher.

Welcher Anfänger formatiert seinen Code heutzutage noch von Hand? Das macht man per Template.

Ich mach' das ja per astyle, aber das ist wahrscheinlich nicht "cool" genug.

Man kann auch mit jeweils hervorragend geschriebenem Code Stück für Stück eine schlechte Architektur erschaffen.

Und ein IDE bietet dabei genau welchen Vorteil?

OpenBSD ist vor allem ein sehr stabiles Projekt, das auf sehr viele Features verzichtet (und von Faktoren wie Deadlines oder Budgets verschont bleibt).

1. Es gibt Deadlines.
2. Natürlich gibt es auch Budgets.

(Oder willst du mir sagen, dass Open-Source-Projekte allesamt keine Rücksicht darauf nehmen müssen, dass Entwickeln halt Geld kostet? Klar, wenn du 'nen Bildschirmschoner oder die viermillionste TIc-Tac-Toe-Anwendung schreibst, brauchste dafür nur einen Uraltrechner und etwas Freizeit neben deinem Beruf. Bei einem Betriebssystem bin ich mir da nicht ganz so sicher.)

Mit einer gut abgehangenen Code-Basis, bei der man auf große Änderungen verzichtet, tut man sich auch mit größeren strukturellen Änderungen sehr leicht - man unterlässt sie einfach.

Ich unterstelle, dass die Codebasis von vornherein einfach sauber geplant wurde.

Wie darf ich mir das bei einem Projekt mit einer sechs- oder siebenstelligen Anzahl LoC vorstellen?

Es geht weniger um die LoC als um die Anzahl an Dateien. Um mal aus meinem aktuell übernommenen Projekt zu "zitieren": Auch zweihundert Zeilen PHP-Code können ziemlich übler Mist sein, wenn er "zweckmäßig" runterprogrammiert und immer wieder nach Tageslaune erweitert wurde. Eine "functions.php" für alles, was sonst nirgends reinpasst, ist prinzipiell schon eine gute Idee, nur nicht, wenn die anderen zwanzig PHP-Dateien in verschiedenen Ordnern ebenfalls allerlei allgemeine Funktionen enthalten. (Undokumentiert obendrein.) Eins meiner anderen Projekte (auf eMule-Basis) hat zwar 'n paar Zeilen/Dateien C++-Code mehr, aber dafür ist da auch alles fein nach Klassen sortiert und wenigstens notdürftig mit Kommentaren versehen. Mehr Code heißt nicht auch mehr Wartungsaufwand, wenn man ihn mal umschreiben will.

 

[Azazyel]

Darum plant man das vorher.

Willkommen im Wasserfall. In der Softwareentwicklung lässt sich nicht alles planen, viele Erkenntnisse kommen erst während der Umsetzung. Deswegen bevorzugt man heute meist agile Softwareentwicklungsmodelle, die aus der Not - man kann nicht alles planen - eine Tugend machen.

Ich mach' das ja per astyle, aber das ist wahrscheinlich nicht "cool" genug.

Das hat doch nichts mit "cool" zu tun; astyle macht doch auch nichts anderes als ein Formatierungstemplate auf den Source Code anzuwenden. Ich hoffe doch, wer bei OpenBSD einen Patch einreicht, kriegt die Formatierung auf die ein oder andere Weise hin.

Und ein IDE bietet dabei genau welchen Vorteil?

Sie weißt dich auf viele Probleme - nicht alle - schon beim Entwickeln hin, wenn z.B. eine Klasse zu viele Abhängigkeiten hat.

Es gibt Deadlines.

Welche Deadlines hat das OpenBSD-Projekt? Die selbstgesetzte "alle 6 Monate ein Release"-Deadline ist keine: deren Nichteinhaltung hätte keine Konsequenzen.

Natürlich gibt es auch Budgets.

Meines Wissens bezahlt die OpenBSD Foundation keine Entwickler. Ansonsten würde der komplette Jahresetat der OpenBSD Foundation gerade mal ausreichen, einen Entwickler für ein Jahr zu bezahlen.

Der mit Abstand teuerste Faktor ist bei einem Softwareprojekt normalerweise die Entwicklerzeit (Ausnahmen bestätigen die Regel). Wenn sich ein OpenBSD-Entwickler ein paar Monate mehr Entwicklungszeit für etwas ausnimmt, kostet das die OpenBSD Foundation keinen Cent.

Oder willst du mir sagen, dass Open-Source-Projekte allesamt keine Rücksicht darauf nehmen müssen, dass Entwickeln halt Geld kostet?

Was ich sagen will: es macht einen riesigen Unterschied, ob in einem Softwareprojekt Entwicklungszeit unmittelbar Geld kostet oder nicht. Begrenzt ist sie in jedem Fall, weswegen man sie auch durch den Einsatz geeigneter Tools möglichst effektiv nutzen sollte.

Bei einem Betriebssystem bin ich mir da nicht ganz so sicher.

Dort braucht man natürlich genug Strom für die Testserver.
Ansonsten kommt es beim Betriebssystem auf den entsprechenden Bereich an. Einen Treiber ohne die entsprechende Hardware zu schreiben dürfte schwierig sein.

Ich unterstelle, dass die Codebasis von vornherein einfach sauber geplant wurde.

Wie planst du in deiner Codebasis Änderungen ein, von denen du heute noch gar nicht weißt, dass sie in 3 Jahren auf dich zukommen?

Mehr Code heißt nicht auch mehr Wartungsaufwand, wenn man ihn mal umschreiben will.

Denk eine Nummer größer. Mit einer IDE siehst du bei einem Refactoring sofort, ob eine Klasse/Methode/etc. von einem Unit Test abgedeckt ist und kannst alle gängigen Refactorings per Shortcut erreichen. Gleichzeitig kannst du dir sicher sein, dass die IDE alle Referenzen beim Refactoring anpasst. Letzteres ist bei kleinen Projekten noch von Hand machbar, wie steigender Projektgröße aber nicht mehr realistisch durchführbar.

Mit einem Texteditor musst du das alles von Hand machen, so dass bei größeren Projekten aus der Arbeit einer Stunde leicht Tage werden können. Die Konsequenz? Im Texteditor findet entweder das Refactoring nicht statt und die Struktur der Codebasis vergammelt weiter, oder das Refactoring wird gemacht und mehrere Tage Entwicklerzeit verschwendet, die man an anderer Stelle sinnvoller einsetzen könnte.


PS: Ansonsten sind wir schon wieder in einer Nebendiskussion angelagt, die eigentlich in ein anderes Forum gehört (Programmieren? Geplauder? OpenBSD?). Weitere Diskussionen gerne dort, bevor sich die Moderatoren genötigt fühlen, diesen Thread hier zu schließen.

 

[CrimsonKing]

Selbst Turbo Pascal für DOS ist ein IDE, insofern ja.

Deswegen bevorzugt man heute meist agile Softwareentwicklungsmodelle, die aus der Not - man kann nicht alles planen - eine Tugend machen.

"Man bevorzugt heute..." ist ja furchtbares BWLer-Sprech von Leuten, die noch nie 'ne Zeile Code verstanden haben, aber natürlich steht es jedem frei, sein Handeln an Trends zu orientieren.

Sie weißt dich auf viele Probleme - nicht alle - schon beim Entwickeln hin, wenn z.B. eine Klasse zu viele Abhängigkeiten hat.

Ein IDE, das Hirn überflüssig macht, also? So dass ein besserer Programmierer, der es wirklich gelernt hat, eigentlich völlig überqualifiziert ist, weil das, was er "mehr" kann als andere, von jedem Hauptschulazubi per Tastendruck ersetzt werden kann? Toll!

Welche Deadlines hat das OpenBSD-Projekt? Die selbstgesetzte "alle 6 Monate ein Release"-Deadline ist keine: deren Nichteinhaltung hätte keine Konsequenzen.

Ich bin mir da nicht so sicher.

Wie planst du in deiner Codebasis Änderungen ein, von denen du heute noch gar nicht weißt, dass sie in 3 Jahren auf dich zukommen?

Erweiterbarkeit und Dokumentation. Ich hab' zeit meines Berufslebens in eigenem Code noch nie irgendwas refactoren müssen. ("Eine Nummer größer denken" ist da auch nur begrenzt sinnvoll.)

 

[Azazyel]

"Man bevorzugt heute..." ist ja furchtbares BWLer-Sprech von Leuten, die noch nie 'ne Zeile Code verstanden haben, aber natürlich steht es jedem frei, sein Handeln an Trends zu orientieren.

Agile Softwareentwicklung wird an nationalen und internationalen Hochschulen gelehrt, ist ein großes Thema bei Konferenzen und in der einschlägigen Fachliteratur:

• HS Augsburg - Fakultät Informatik - Vorlesung Agile Softwareentwicklung
• International Conference of Software Engineering: Processes and Agile Development
• OBJEKTspektrum
• iX Developer: Bessere Software

Abgesehen davon wird es auch im großen Maßstab zur Entwicklung von Software eingesetzt.

Begriffe wie Test Driven Development oder Continuous Integration zur Verbesserung der Softwarequalität, die aus diesem Umfeld stammen, sind dir hoffentlich keine Unbekannten?

Ein IDE, das Hirn überflüssig macht, also? So dass ein besserer Programmierer, der es wirklich gelernt hat, eigentlich völlig überqualifiziert ist, weil das, was er "mehr" kann als andere, von jedem Hauptschulazubi per Tastendruck ersetzt werden kann? Toll!

Was ist dein Ziel? Möchtest du Standesdünkel gegenüber Hauptschülern pflegen oder möglichst gute Software entwickeln?

Erweiterbarkeit und Dokumentation. Ich hab' zeit meines Berufslebens in eigenem Code noch nie irgendwas refactoren müssen. ("Eine Nummer größer denken" ist da auch nur begrenzt sinnvoll.)

Dann mache dich schon mal auf eine Überraschung bei deinem ersten Projekt mit mehr als einem Entwickler, längerer Laufzeit und sich ändernden Anforderungen gefasst. Soviel Erweiterbarkeit kannst du gar nicht vorsehen, dass du nicht an der ein oder anderen Stelle nochmal ran musst.

 

[peterle]

Mal als neugierige Nachfrage - was ist denn eine empfehlenswerte IDE für was?

 

[Azazyel]

Mal als neugierige Nachfrage - was ist denn eine empfehlenswerte IDE für was?

Meiner bescheidenen Meinung nach gibt es momentan im Endeffekt drei hervorragende IDE(-Familien):

• JetBrains IntelliJ IDEA (Java & Co.) sowie deren Derivate für Python, Ruby, PHP, Javascript und Objective-C.
  Eine C++-Variante ist in Arbeit.
  Der Großteil ist leider kommerziell (es gibt jeweils eine 30-Tage-Version zum Ausprobieren). Für Java und Python gibt jeweils eine kostenlose "Community Edition".
• NetBeans: eine Open-Source-IDE mit Support für Java, HTML5, Javascript (sowie anderen JVM-Sprachen, PHP und C/C++). Meine IDE der Wahl für alles im Java- und Webumfeld und trotz der enormen Funktionalität und Mächtigkeit sehr einsteigerfreundlich.
• Visual Studio: man muss Microsoft nicht mögen, aber Visual Studio inzwischen einfach verdammt gut. Es gibt auch eine kostenlose Variante, Visual Studio Express (für C#, Visual Basic, C++), die man aber leider mit noch so viel gutem Zureden nicht unter Unix zum Laufen kriegt. Laut aller professionellen C++-Entwickler, die ich kenne, inzwischen die beste C++-IDE.

Ein paar Demos auf Youtube:

• IntelliJ IDEA
• Netbeans
• Visual Studio (speziell für C++)

Von Eclipse würde ich Abstand nehmen, das hat seine besten Zeiten hinter sich.

 

[CrimsonKing]

Was ist dein Ziel? Möchtest du Standesdünkel gegenüber Hauptschülern pflegen oder möglichst gute Software entwickeln?

Ich möchte Software entwickeln und nicht zusammenklicken oder generieren lassen.

würde ich Abstand nehmen, das hat seine besten Zeiten hinter sich.

Wann soll das denn gewesen sein?

 

[Azazyel]

Ich möchte Software entwickeln und nicht zusammenklicken oder generieren lassen.

Zeig mir die IDE, die Software für mich entwickelt.
Wir reden hier von IDEs und nicht von Microsofts Access, das den Source Code vor dir versteckt.

Du kannst auch in der IDE alles von Hand erstellen und brauchst kein einziges Mal die Maus anfassen, wenn du nicht willst. Du hast aber in vielen Bereich, in denen es Sinn macht, die Möglichkeit, die Fleißarbeit von der IDE machen zu lassen.
Entwicklerzeit sollten meiner Meinung nach mit Entwicklung verbracht werden - dabei unterstützt einen die IDE perfekt - und nicht mit banaler Fleißarbeit, wie man sie im Texteditor zu Fuß erledigen muss.

Wann soll das denn gewesen sein?

Irgendwann im letzten Jahrzehnt, als Eclipse der Einäugige unter den Blinden war und bevor Eclipse seine Kohärenz vollends verloren hat. Primitiv verglichen zu heute, aber immer noch weit effektiver als jeder Texteditor.

 

[CrimsonKing]

Zeig mir die IDE, die Software für mich entwickelt.

Eclipse. Und ja, auch Getter/Setter sind Entwicklung.
(OT im OT: von "die Environment" krieg' ich immer Augenstechen.)

Entwicklerzeit sollten meiner Meinung nach mit Entwicklung verbracht werden - dabei unterstützt einen die IDE perfekt - und nicht mit banaler Fleißarbeit, wie man sie im Texteditor zu Fuß erledigen muss.

Was ist denn genau Fleißarbeit? Beispiele und Abgrenzung bitte.

Primitiv verglichen zu heute, aber immer noch weit effektiver als jeder Texteditor.

Dafür war der eingebaute Codeeditor damals schon Grütze.

 

[Azazyel]

Eclipse. Und ja, auch Getter/Setter sind Entwicklung.

Getter/Setter sind - zumindest bei der initialen Generierung - reine Tipparbeit, die auch ein trainierter Affe machen könnte. Das ist keine Entwicklung, das ist Beschäftigungstherapie. Eine Schwachstelle von Java, die wir aber

Was ist denn genau Fleißarbeit? Beispiele und Abgrenzung bitte.

Du möchtest eine Klasse benutzen, deren Name mit XYZ beginnt, hast aber vergessen, in welchem Package bzw. welcher Bibliothek sie eingebunden ist.

• IDE: Du gibt "XYZ <Ctrl+Space>" ein und kriegst eine komplette Liste alle Klassen im aktuellen Projekt, der eingebundenen Dependencies und im Repository.
• Texteditor: erstmal die Suche anwerfen. Verdammt, kein Treffer. Mal mit "find | xargs grep" schauen, wo du sonst fündig werde - verflucht, nicht lokal da. Doch googlen.

5 Sekunden vs. 5 Minuten.


Du tippst ein "List<String> result = xyz." und überlegst: verdammt, welche Methode von XYZ wollte ich noch gleich ansprechen?

• IDE: Erkennt, dass nur drei Methoden eine Liste zurückgeben, bietet dir die drei an und blendet gleich die Dokumentation dazu ein. Falls es doch keine Liste war, die du wolltest, werden darunter gleich die restlichen Methoden angeboten.
• Texteditor: Hmm, welche Methoden sind überhaupt bei XYZ verfügbar? Doku ansurfen, die drei Methoden raussuchen, die eine Liste zurückgeben. Eine davon übersehen und die falsche nehmen. Ausprobieren, fluchen, nochmal nachgucken, nachbessern.

5 Sekunden vs. 5 Minuten.


Dir fällt auf, dass die Methodensignatur geändert werden müsste, weil der verwendete Typ eigentlich nicht zur Anforderung passt.

• IDE: "Change Methode Parameter" -> alle Referenzen auf die Methode werden automatisch angepasst. Sollte es nicht automatisch funktionieren, bekommst du einen Hinweis, wo es nicht automatisch klappt und kannst entscheiden, ob das Vorgehen so gewollt ist.
• Texteditor: Methodensignatur ändern, kompilieren, verdammt, 103 Compiler-Fehler, verflucht wird die Methode häufig verwendet. 79 Fehler händisch anpassen und beim 80. merken, dass es dort nicht klappt und du einen Denkfehler gemacht hast. Alles rückgängig machen.

10 Sekunden vs. 10 Minuten.


Du merkst, dass die Klasse ABC im aktuellen Package eigentlich falsch aufgehoben ist und in ein anderes Package gehört.

• IDE: "Move", Packagenamen eingeben, fertig.
• Texteditor: Erstmal die Datei händisch verschieben und den Packagenamen im Source anpassen. Compiler anwerfen und schauen, wo die Fehlermeldungen kommen. Von 103 Referenzen noch 20 händisch beheben, weil die RegExp doch nicht alle Vorkommen erwischt hat.

5 Sekunden vs. 5 Minuten. Jedesmal, wennn du merkst, dass eine Klasse in ein anderes Package gehört.


Du merkst, dass du nicht immer die Oberklasse verwendet hast (z.B. ArrayList vs. List) und deine Implementierung generischer sein könnte.

• IDE: "Use Supertype where possible" -> fertig
• Texteditor: Typ an Stelle A anpassen, Compiler anwerfen, hmm, Stelle übersehen. Stelle B anpassen, Compiler anwerfen, zufrieden zurücklehnen. Stelle C übersehen.

5 Sekunden vs. 1 Minute.

 

[CrimsonKing]

Eine Schwachstelle von Java, die wir aber

Noch eine Schwachstelle von Java scheint es zu sein, dass man vergisst, was man schreiben wollte.
(Nein, ich mag Java wirklich nicht.)

Du möchtest eine Klasse benutzen, deren Name mit XYZ beginnt, hast aber vergessen, in welchem Package bzw. welcher Bibliothek sie eingebunden ist.

• IDE: Du gibt "XYZ <Ctrl+Space>" ein und kriegst eine komplette Liste alle Klassen im aktuellen Projekt, der eingebundenen Dependencies und im Repository.
• Texteditor: erstmal die Suche anwerfen. Verdammt, kein Treffer. Mal mit "find | xargs grep" schauen, wo du sonst fündig werde - verflucht, nicht lokal da. Doch googlen.

Eine Liste aller Klassen sagt dir immer noch nicht, in welcher Bibliothek sie sich befinden.

Du tippst ein "List<String> result = xyz." und überlegst: verdammt, welche Methode von XYZ wollte ich noch gleich ansprechen?

• (...)
  
• Texteditor: Hmm, welche Methoden sind überhaupt bei XYZ verfügbar? Doku ansurfen, die drei Methoden raussuchen, die eine Liste zurückgeben. Eine davon übersehen und die falsche nehmen. Ausprobieren, fluchen, nochmal nachgucken, nachbessern.

Dein Texteditor kann kein CTAGS? Nutzst du nano?

(Nachtrag: Selbst das ist keine Ausrede.)

Dir fällt auf, dass die Methodensignatur geändert werden müsste, weil der verwendete Typ eigentlich nicht zur Anforderung passt.

• (...)
  
• Texteditor: Methodensignatur ändern, kompilieren, verdammt, 103 Compiler-Fehler, verflucht wird die Methode häufig verwendet. 79 Fehler händisch anpassen und beim 80. merken, dass es dort nicht klappt und du einen Denkfehler gemacht hast. Alles rückgängig machen.

PEBKAC ist natürlich ein Problem der verwendeten Software, ja. (Möchtest du mir gerade sagen, dass ein IDE von Denkfehlern befreit?)

Nun ja:
http://stackoverflow.com/questions/...etely-messed-up-replacing-arbitrary-character

Du merkst, dass die Klasse ABC im aktuellen Package eigentlich falsch aufgehoben ist und in ein anderes Package gehört.

• (...)
• Texteditor: Erstmal die Datei händisch verschieben und den Packagenamen im Source anpassen. Compiler anwerfen und schauen, wo die Fehlermeldungen kommen. Von 103 Referenzen noch 20 händisch beheben, weil die RegExp doch nicht alle Vorkommen erwischt hat.

Datei verschieben: Ein einfacher Shellbefehl, ist eh' immer offen.

Paketnamen anpassen: Suchen und Ersetzen. (Tipp: sed ist dafür prima geeignet.)

In welcher Programmiersprache ist es eigentlich so unfassbar schwierig, einen PCRE-Ausdruck so zu schreiben, dass er ausschließlich Paketnamen durch andere Paketnamen ersetzt? Brainfuck? Ja, Regex ist mitunter kompliziert, aber nein, nicht in diesem Anwendungsfall. 5 Sekunden? Klar!

Du merkst, dass du nicht immer die Oberklasse verwendet hast (z.B. ArrayList vs. List) und deine Implementierung generischer sein könnte.

Zweckfreie Frickelei IMO; aber bitte: sed -> 5 Sekunden. Höchstens.

Hast du auch überzeugende Beispiele?

 

[Azazyel]

Noch eine Schwachstelle von Java scheint es zu sein, dass man vergisst, was man schreiben wollte.
(Nein, ich mag Java wirklich nicht.)

Kurz nach Mitternacht, da hatte die Verwandlung zum Werwolf schon eingesetzt.

Eine Liste aller Klassen sagt dir immer noch nicht, in welcher Bibliothek sie sich befinden.

Doch, auch das wird eingeblendet.

Dein Texteditor kann kein CTAGS? Nutzst du nano?

CTAGS (selbst in der exuberant-Variante) indiziert leider nur lokalen Content. Bei Programmiersprachen, die zentrale Repositories der verfügbaren Open-Source-Bibliotheken kennen (z.B. MVN Repository oder PyPI), versagt CTAGS.

PEBKAC ist natürlich ein Problem der verwendeten Software, ja. (Möchtest du mir gerade sagen, dass ein IDE von Denkfehlern befreit?)

Jeder Entwickler macht Fehler; vor manchen kann die IDE dich bewahren.

Paketnamen anpassen: Suchen und Ersetzen. (Tipp: sed ist dafür prima geeignet.)

Dann verrate mir doch mal, wie du mit sed eine Klasse aus dem Default-Package (das bekanntlich keinen Namen hat) verschiebst und alle Referenzen anpasst?

In welcher Programmiersprache ist es eigentlich so unfassbar schwierig, einen PCRE-Ausdruck so zu schreiben, dass er ausschließlich Paketnamen durch andere Paketnamen ersetzt? Brainfuck? Ja, Regex ist mitunter kompliziert, aber nein, nicht in diesem Anwendungsfall. 5 Sekunden? Klar!

Du möchtest die Klasse de.alpha.ABC in ein anderes Package verschieben, de.alpha.XYZ aber an Ort und Stelle lassen.
Wie passt du mit einem Ausdruck die Referenz

import de.alpha.*;

in den anderen Klassen an und erwischt auch noch die expliziten Import-Statements?

Falls du auf eine Lösung kommst, wie lange hast du dafür gebraucht? Alles Zeit, die im Alltag von der eigentlichen Entwicklung abgeht.

Zweckfreie Frickelei IMO; aber bitte: sed -> 5 Sekunden. Höchstens.

Typsicherheit und eine möglichst generische Implementierung ist also zweckfreie Frickelei?
Woher weiß sed selbst, welche Oberklasse im aktuellen Kontakt der Methode geeignet ist?

 

[CrimsonKing]

Doch, auch das wird eingeblendet.

Das geht bestimmt auch mit Emacs... (mal ausprobieren bei Gelegenheit und Laune).

CTAGS (selbst in der exuberant-Variante) indiziert leider nur lokalen Content.

Das ist korrekt. Da ich die Bibliotheken, die ich einsetze, allerdings ohnehin lokal installiere, ist das Problem eigentlich gar keines.

Jeder Entwickler macht Fehler; vor manchen kann die IDE dich bewahren.

Nein. Ein IDE kann Wachhund spielen, aber beißen wird es dich trotzdem nicht, wenn du Fehler machst. Auch ein IDE kann man super falsch bedienen (ist also sogar eine zusätzliche Fehlerquelle).

Dann verrate mir doch mal, wie du mit sed eine Klasse aus dem Default-Package (das bekanntlich keinen Namen hat) verschiebst und alle Referenzen anpasst?

Hängt davon ab. Welche Sprache?

Wie passt du mit einem Ausdruck die Referenz

import de.alpha.*;

in den anderen Klassen an und erwischt auch noch die expliziten Import-Statements?

Einfach "import de.<neueklasse>" hinzufügen. Wildcard-Imports sind sowieso in fast allen Fällen "zu viel des Guten"; wenn es also sowieso nicht darauf ankommt, möglichst wenig Overhead zu haben, kann man das auch beibehalten.
(Typisch Java-Entwickler.)

Falls du auf eine Lösung kommst, wie lange hast du dafür gebraucht?

Wenige Sekunden.

Typsicherheit und eine möglichst generische Implementierung ist also zweckfreie Frickelei?

Lass' es mich so ausdrücken: Mit einer Kanone kannst du durchaus einen Spatzen erschießen. Das heißt nicht, dass eine Kanone grundsätzlich das geeignete Werkzeug dafür ist.

Woher weiß sed selbst, welche Oberklasse im aktuellen Kontakt der Methode geeignet ist?

Weiß es nicht, aber du weißt ja wohl selbst, welche Klassen dir nicht generisch genug sind, oder?