Hallo! Ok, ich muss sagen, ich von Visual Studio und Co. verwöhnt und durfte erst jetzt zum Ersten mal Bekanntschaft mit gdb und valgrind machen. Valgrind ist ganz in Ordnung, aber gdb? Gibt es wirklich Leute, die damit produktiv größere Programme debuggen können? Also auf der Kommandozeile? Ich bin auf jeden Fall sehr dankbar für grafische Debugger.
Meistens bietet die IDE eine grafische Oberfläche für gdb, sieh QtCreator und Eclipse.
H. K. schrieb: > Gibt es wirklich Leute, die damit produktiv größere Programme debuggen > können? Also auf der Kommandozeile? Ja, hab ich schonmal gemacht, mit nem 20000-Zeilen-Programm, das sich selten und kaum reproduzierbar mit nem Segfault verabschiedete. War schon recht vertrackt, den Fehler zu finden, aber mit GDB ging es ganz gut.
Wie deElf schon geschrieben hat, bieten zum einen die IDEs eine grafische Oberfläche für gdb und zum anderen kann man unter Unix/Linux schon seit Jahrzehnten komfortabel aus den Standard-Editoren Emacs und vi/vim heraus compilieren und debuggen. Das geht nur mit der Tastatur, ohne Maus, sehr effizient. Aber jedem das seine...
Es gibt sogar für Visual Studio eine gdb-Integration, das ganze hat den naheliegenden Namen "Visual Gdb".
derElf schrieb: > Meistens bietet die IDE eine grafische Oberfläche für gdb, sieh > QtCreator und Eclipse. Das schöne ist, dass man dann immer noch an die GDB-Eingabe rankommt. Dort kann man dann auch sowas eintippen wie:
1 | print *(struct mydata*)((struct list*)0x423124)->next->next->next->next->data |
Wenn man stattdessen nur eine GUI hat, welches keine Idee hat, dass man gelegentlich mal die Daten auf Adresse 0x423124 als verkettete Liste interpretieren möchte, bei dem man den Datenbereich des sechsten Listenelements jetzt als "struct mydata" darstellen müsste, dann fängt man an, sich stattdessen manuell durch ein Fenster mit dem Speicherinhalt zu hangeln. Alexander S. schrieb: > kann man unter Unix/Linux > schon seit Jahrzehnten komfortabel aus den Standard-Editoren > Emacs und vi/vim heraus compilieren und debuggen. Mittlerweile auch so komfortabel, dass sich das kaum von dem unterscheidet, was "richtige" IDEs so an Features bieten, also parallel mitlaufender Registerdump im separaten Fenster etc.
H. K. schrieb: > Ok, ich muss sagen, ich von Visual Studio und Co. verwöhnt und durfte > erst jetzt zum Ersten mal Bekanntschaft mit gdb und valgrind machen. > Valgrind ist ganz in Ordnung, aber gdb? gdb ist ebenfalls sehr in Ordnung, auch auf der Kommandozeile. > Gibt es wirklich Leute, die damit produktiv größere Programme debuggen > können? Also auf der Kommandozeile? Ja, gibt es. > Ich bin auf jeden Fall sehr dankbar für grafische Debugger. Die meisten meiner Programme laufen auf Maschinen ohne grafische Oberfläche. Da machen GUI-Debugger wenig Spaß.
H. K. schrieb: > Ich bin auf jeden Fall sehr dankbar für grafische Debugger. Der einzige grafische Debugger, den ich kenne, ist der bereits genannte DDD, der als Frontend für GDB, JDB, PyDB und noch eine ganze Reihe weiterer textbasierter Debugger dient: http://www.gnu.org/software/ddd/all.png http://www.gnu.org/software/ddd/plots.png Bei den Debuggern der gängigen IDEs sind allenfalls die Icons grafisch. Das Schöne an GDB ist, dass er sehr viele unterschiedliche Architekturen unterstützt, Remote-Debugging auf Embedded-Systemen ermöglicht und in viele IDEs und Editoren integriert werden kann. Ähnlich wie beim GCC hat man damit ein Tool, in das man sich einmal einarbeitet und anschließend in nahezu jeder Lebenslage verwenden kann. Sollte mal aus irgendeinem Grund kein grafisches Ausgabegerät zur Verfügung stehen, hat man als Fallback-Lösung immer noch die Komandzeileninteraktion, die immer noch besser ist, als komplett aufs Debuggen verzichten zu müssen.
gdb ist halt nichts für Anzug- und Krawattenträger die sich als Programmierer ausgeben.
Hallo, gdb wird auch vom eclipse Debugger benutzt, den es auch als Standalone-Programm gibt, und der aktiv weiterentwickelt wird: https://www.infoq.com/presentations/best-practices-cdt-debugger Gruß, Bernhard
Jörg W. schrieb: > Wenn man stattdessen nur eine GUI hat, Sogar das verpönte MS Visual Studio kennt schon seit Äonen die Möglichkeit, einen Watch-Ausdruck (oder Quickwatch) auf solch eine Art und Weise zusammenzustellen - mit der Tastatur. Da gibt es nämlich eine Eingabezeile. Man muss also nicht in der Teletype-Steinzeit von vi verharren.
> Man muss also nicht in der Teletype-Steinzeit von vi verharren.
Man muss nicht aber kann, namhafte Firmen in der Logistik Branche
verwenden ausschliesslich vi.
Rufus Τ. F. schrieb: > Man muss also nicht in der Teletype-Steinzeit von vi verharren. Keiner startet schneller ;-) Nett ist vi eigentlich nur für "mal eben eine Konfigurationsdatei ändern". Zu gdb: Wir (bzw. ich) arbeiten seit dem Studium mit gdb - viel vermisst habe ich bisher nicht. Hier läuft er unter Eclipse oder in letzter Zeit vermehrt unter Geany. Also: ja, produktiv (zumindest meistens ;-) und wir verdienen damit unser Brot.
Mark schrieb: > gdb ist halt nichts für Anzug- und Krawattenträger die sich als > Programmierer ausgeben. you made my day :-) Wer einmal auf einer alten Siemens BS-2000 Maschine ein 1000 Dateien Programm gedebuggt hat, der freut sich über gdb. Und der Kollege am Nebentisch würde sich noch viel mehr freuen, wenn er sein 800 Seiten IBM-MVS Dump durchblättert.
H. K. schrieb: > Gibt es wirklich Leute, die damit produktiv größere Programme debuggen > können? Also auf der Kommandozeile? Ja, hier!
Rufus Τ. F. schrieb: > Man muss also nicht in der Teletype-Steinzeit von vi verharren. Naja, ich entwickle mit vi und debugge mit gdb. Das müsste natürlich nicht mehr sein, nur habe ich mir das jetzt 27 Jahre lang so angewöhnt. Entwickle ich mit Eclipse, mosert der Compiler immer bei den vielen :w ;-) Ich schätze dabei sehr, dass die beiden Tools ohne grafisches Frontend klar kommen. Auch wenn man praktisch immer ein X11 hat, es kommt vor, wo einem das nicht zur Verfügung steht und genau dann ist man froh darum. Grüsse, René
Die hardcore-gdb'ler sind halt auf Unixoiden unterwegs, da gibt es die Alternative Visual irgendwas nicht. Wer unter Windows professionell Software für Windows mit Microsoft-Tools erstellt, wird eher selten mit gdb arbeiten. Oliver
Oliver S. schrieb: > Die hardcore-gdb'ler sind halt auf Unixoiden unterwegs, da gibt es die > Alternative Visual irgendwas nicht. Sagen wir mal so: ich hab den Visual-Krams in der VM. Ich bin aber froh, wenn ich ihn nicht benutzen muss.
René H. schrieb: > Rufus Τ. F. schrieb: >> Man muss also nicht in der Teletype-Steinzeit von vi verharren. > > Naja, ich entwickle mit vi und debugge mit gdb. Das müsste natürlich > nicht mehr sein, nur habe ich mir das jetzt 27 Jahre lang so angewöhnt. > Entwickle ich mit Eclipse, mosert der Compiler immer bei den vielen :w > ;-) > Du nennst dich also Entwickler bis aber seit vielen Jahren nicht in der Lage dich selbst weiter zu entwickeln. Solltest du dich da nicht besser Software-Restaurator oder -Archäologe nennen?
Ich verwende kate als Editor statt einer überladenen IDE die ewig zum starten braucht, und gdb zum Debuggen, immer auf der Konsole. Ich käme zwar auch ohne Kate und GUI zurecht, bin aber mehr der Bequeme Typ und bevorzuge nano über vi, weil simpler. Was gdb angeht, ich finde es einfacher "break Funktionsnahme" zu schreiben, statt zuerst den Tab mit der Datei in einer IDE zu suchen, zur Funktion zu scrollen, einen breakpoint zu setzen, und dann noch den Knopf zum weiter Debuggen zu suchen. Ausserdem finde ich noch ganz cool, dass ich mit gdb auch Funktionen aufrufen kann und variablen manipulieren während ich Debugge. Und ein Stacktrace ist auch einfach nur ein Kommando eingeben, und hat auf der Konsole immer platz. Ein anderer Vorteil ist, dass ich mich nicht mit irgendwelchen neuen IDEs auseinandersetzen muss, nur weil ich mal etwas unter einem anderen OS oder einem anderen Projekt Debuggen muss. Ich muss nur schauen, das gdb die Sourcen finden kann.
Eclipse und C ist wirklich stark grauslig, aber MS VC2010 sowie 2015 sind wirklich sehr gute, brauchbare Entwicklungsumgebungen. Den Luxus, den die bieten, merkt man erst, wenn man auf ner anderen Platform unterwegs ist. Wollte mit eclipse ein Projekt, welches aus einem Haufen Libs und einer Exe besteht, zum compilieren bringen (Linux portierung einer bestehenden Anwendung). Standardproblem. Hat nicht geklappt, hab dann per Hand selbst die makefiles (main - makefile und Abstieg in makefiles der Libs) für Linux geschrieben :-( Von einer so professionellen IDE wie Eclipse erwarte ich eig., dass sie standardprobleme löst. Stattdessen bekomme ich (Kontext-)Menus, wo ich auf einem 4k Monitor noch scrollen muss ..... Das "Problem" zieht sich aber durch die ganze gnu Welt: Man braucht Zeit zum Einarbeiten. Früher auf dem AVR war ich noch mit notepad und avrgcc, PonyProg und printf unterwegs, heute auf ARM Cortex möchte ich MDK-ARM/ULINKpro mit den ganzen Debug- und Trace- Möglichkeiten sowie grafischer Darstellung von Variablen etc. keinesfalls mehr missen. Dieses ganze gnu Zeugs ist klasse, weil kostenlos. Man muss aber Zeit mitbringen. Jemand, der nicht alle vi und gdb Kommandos auswendig kennt, braucht erstmal ne Weile. Ich verwende vi zur Konfiguration von Linux Systemen. Zur produktiven Softwareenticklung alleine oder in einer Gruppe ziehe ich professionelle Tools vor.
:
Bearbeitet durch User
Volle schrieb: > Du nennst dich also Entwickler > bis aber seit vielen Jahren nicht in der Lage dich selbst weiter zu > entwickeln. Warum sollte ich eine IDE verwenden, die mehr Bugs als Vorteile hat? Eclipse mit CDT kann nicht mehr, was ich mit vi nicht auch könnte. Bloss weil etwas viele bunte Knöpfe hat, bedeutet es nicht, dass es ein Fortschritt darstellt. Zumindest nicht für mich. Es tut mir leid, bloss weil Eclipse die einzige halb vernünftige IDE unter Unix ist (Solaris, AIX und Linux) ist sie für C++ nicht brauchbar. Mit JAVA unter Unix ist es zweifelsohne die IDE.
Random .. schrieb: > Das "Problem" zieht sich aber durch die ganze gnu Welt: Man braucht Zeit > zum Einarbeiten. Fallen wir jetzt hier in den „Jeder-basht-das-was-er-nicht-kennt“-Modus? Da kann ich mithalten. Aber vielleicht lassen wir ja diese Kindereien lieber? Möge doch jeder bitte die IDE benutzen, die er gut findet und gut bedienen kann. Die Frage des TE dürfte ja ohnehin hinreichend beantwortet worden sein: ja, es gibt genügend Leute, die einen GDB produktiv benutzen, von der puren Kommandozeile hin bis zur Integration in allerlei IDEs.
René H. schrieb: > Mit JAVA unter Unix ist es zweifelsohne die IDE Nicht nur unter Unix. Oliver S. schrieb: > Wer unter Windows professionell Software für Windows mit Microsoft-Tools > erstellt, wird eher selten mit gdb arbeiten. Und bleibt auf seiner einsamen langsam immer kleiner werdenden Insel. Professionelle Software wird schon lange mehr und mehr für Server gemacht und läuft oft genug nicht mehr auf Windows Rechnern, und selbst wenn, dann betriebssystemunabhängig in Application Servern wie Tomcat, Websphere, etc. und mit einem Web Frontend.
Die ganzen vi-Steinzeitler sollten sich unbedingt mal Vim angucken. Das aber nur als Tipp am Rande.
Vim schrieb: > Die ganzen vi-Steinzeitler sollten sich unbedingt mal Vim angucken. Vielleicht benutzen sie ihn ja einfach, statt dafür zu evangelisieren?
Random .. schrieb: > Das "Problem" zieht sich aber durch die ganze gnu Welt: Man braucht Zeit > zum Einarbeiten. > Früher auf dem AVR war ich noch mit notepad und avrgcc, PonyProg und > printf unterwegs, heute auf ARM Cortex möchte ich MDK-ARM/ULINKpro mit > den ganzen Debug- und Trace- Möglichkeiten sowie grafischer Darstellung > von Variablen etc. keinesfalls mehr missen. Dafür kann GCC auch nicht-antike Sprachstandards. Bei sinnvoller Verwendung von C++14 findet der Compiler bereits eine Menge Fehler von alleine, sodass man gar nicht mehr so viel Zeit mit den tollen Debuggern verbringen muss...
Jörg W. schrieb: > Vim schrieb: >> Die ganzen vi-Steinzeitler sollten sich unbedingt mal Vim angucken. > > Vielleicht benutzen sie ihn ja einfach, statt dafür zu evangelisieren? yymd :wq (ups, sry)
Volle schrieb: > René H. schrieb: >> Rufus Τ. F. schrieb: >>> Man muss also nicht in der Teletype-Steinzeit von vi verharren. >> >> Naja, ich entwickle mit vi und debugge mit gdb. Das müsste natürlich >> nicht mehr sein, nur habe ich mir das jetzt 27 Jahre lang so angewöhnt. >> Entwickle ich mit Eclipse, mosert der Compiler immer bei den vielen :w >> ;-) >> > > Du nennst dich also Entwickler > bis aber seit vielen Jahren nicht in der Lage dich selbst weiter zu > entwickeln. > > Solltest du dich da nicht besser Software-Restaurator oder -Archäologe > nennen? Das ist der - mit DICKEM Abstand - dämlichste Post, den ich in den letzten Jahren gelesen habe. Entwickle erst mal 27 Jahre Software. Dann schauen wir mal, mit was DU arbeitest. Zumindest wirst Du dann wissen WAS es alles gibt und insbesondere mit welcher SW. (Manche Rookies haben Vorstellungen von der SW Branche, da bekomme ich Angst^^) /regards
René H. schrieb: > Eclipse mit CDT kann nicht mehr, was ich mit vi nicht auch könnte. * Aufrufbaum? * Aufruferbaum? * Unzutreffende ifdef ausgrauen? * go-to-declaration/implementation? * Kontext- und Scope-sensitives Autocomplete? * Outline? * Call-Tips? * Scope-sensitives Bezeichner umbenennen? * Statische Codeanalyse Bevor Du antwortest: Alle oben genannten Funktionen sollen selbstverständlich auf Basis des präprozessierten Codes geschehen, unter Berücksichtigung aller für die gewählte Konfiguration gültigen defines und bedingten includes, nach Auflösung aller Makros (also auch generierten Code einbeziehen), nicht auf Basis der rohen C-Dateien. Weiter gehts: * Source-Level Debugging? - auch im generierten Assembler-Code? * Breakpoints? - auch im Assembler code? * Watches, Register-, Peripherie-, Memory-Browser? * Direkt benutzbare Plugins für alle gängigen Debug-Adapter? IDEs die das alles können kann man an einer Hand abzählen, vi(m) ist nicht dabei. Vim ist nämlich ein Texteditor. Für simple Textdateien. Nicht für Projekte mit vielen Dateien und hochkomplexen verschachtelten Zusammenhängen. Eclipse ist zwar scheißträge auf schwachen Rechnern und teilweise schwer und absolut unintuitiv zu konfigurieren aber trotzdem ist es (oder vergleichbare IDEs) absolut alternativlos wenn man mehr als ein Hello-World Projekt unter der Fuchtel hat und sich halbwegs schnell und zielsicher in riesigen Codemengen bewegen und dort in absehbarer Zeit was bewirken will. Da kannst Du mit deinem Konsoleneditor für einzelne kleine Dateien zuhause bleiben. Vim benutzt man um mal eben ne schnelle Änderung in ner einzelnen Datei zu machen oder mal ne commit-message schreiben, alles was überschaubar, klein und kurz ist oder wenn auf Teufel komm raus irgendwo keine graphische Oberfläche mit nem vernünftigen Editor gestartet werden kann. Das wars dann auch schon an sinnvollen Anwendungsfällen.
:
Bearbeitet durch User
Arbeite mal mit Eclipse direkt übers Internet auf den Servern beim Kunden, mit vi werden sicher viel größere und komplexere Aufgaben umgesetzt wie mit Eclipse. Alles hat seine Vor- und Nachteile, aber nur weil man mit vi nicht umgehen kann muss vi deswegen nicht schlecht sein. Ich persönlich arbeite auch lieber mit Eclipse als wie mit dem Emacs weil ich sehr viele Dateien in sehr vielen Unterordner habe und ich mir diese Strucktur auswendig nicht merke und daher der Verzeichnisbaum von Eclipse sehr praktisch ist, das ist aber das einzige was ich beim Emacs vermisst habe.
Hans schrieb: > Arbeite mal mit Eclipse direkt übers Internet auf den Servern beim > Kunden Warum sollte man sowas bescheuertes machen? Was haben meine Quelltexte beim Kunden verloren? Und selbst wenn er ne Kopie der Quellen bekommt hab ich immer noch ne ausgecheckte Arbeitskopie des ganzen Projekts samt funktionierender Buildumgebung und allem Pipapo auf meinem Arbeitsplatzrechner oder Laptop.
:
Bearbeitet durch User
Angehängte Dateien:
-
snapshot1.png
31 KB
Bernd K. schrieb: > Eclipse ist zwar scheißträge auf schwachen Rechnern und teilweise schwer > und absolut unintuitiv zu konfigurieren aber trotzdem ist es (oder > vergleichbare IDEs) absolut alternativlos wenn man mehr als ein > Hello-World Projekt unter der Fuchtel hat und sich halbwegs schnell und > zielsicher in riesigen Codemengen bewegen und dort in absehbarer Zeit > was bewirken will. Da kannst Du mit deinem Konsoleneditor für einzelne > kleine Dateien zuhause bleiben. Das sehe ich anders. Es ist vollkommen egal, ob man eclipse nimmt, oder einen Texteditor, direkt auf die Festplatte schreibt, oder Schmetterlinge nutzt[1]. Eclipse mag viele praktische Funktionen haben, aber nur deshalb muss sie ja nicht jeder benötigen, auch nicht bei grossen Projekten. Wie oft benennt man den schon das halbe Projekt um? Warum sollte ich das nicht auch mit sed tun können? Warum sollte ich nicht so oder so wissen, welche defines gesetzt sind, und welcher Code ausgeführt wird? Warum muss ich warten, bis die IDE gestartet ist? Ich muss nicht, es ist meine eigene Entscheidung! (sofern das nicht von der Firma festgelegt wird...) > Vim benutzt man um mal eben ne schnelle Änderung in ner einzelnen Datei > zu machen oder mal ne commit-message schreiben, alles was überschaubar, > klein und kurz ist oder wenn auf Teufel komm raus irgendwo keine > graphische Oberfläche mit nem vernünftigen Editor gestartet werden kann. > Das wars dann auch schon an sinnvollen Anwendungsfällen. Nur weil du dafür keine sinnvolle Anwendung dafür hast, heisst das doch nicht das diese sonst keiner hat. Man kann mit vi & co. alles machen, nur eben auf andere weise. [1] https://xkcd.com/378/
Daniel A. schrieb: > Wie oft benennt man den schon das halbe Projekt um? Jeden Tag bin ich am Editieren, mal erweitere ich es um Neues, mal ändere ich Bestehendes. Da wird auch schon öfter mal ein bescheuert benamster Bezeichner in was endgültiges umbenannt, einer der an zwölf anderen Stellen noch vorkommt, und das tu ich gerne mit zwei Tastendrücken ohne mir mit nem Texteditor 10 Minuten lang einen abzubrechen weil Suchen und Ersetzen ein dutzend false positives bringen würde. Was Du jedoch mit "halbes Projekt umbenennen" meinst ist liegt im Dunkeln. > Warum sollte ich das nicht auch mit sed tun können? Weil das mit sed nicht geht, vielleicht? > Warum sollte ich > nicht so oder so wissen, welche defines gesetzt sind, und welcher Code > ausgeführt wird? Ja klar, warum sollte man eigentlich überhaupt noch in die Dateien reinschauen müssen wenn man doch so oder so schon wissen sollte welcher Code wann wo ausgeführt wird. > Warum muss ich warten, bis die IDE gestartet ist? Warum muss ich jeden morgen warten bis der Kaffee durchgelaufen ist, ich könnte doch Wasser trinken? Warum muss ich 3 Minuten warten bis mein Rechner gebootet ist, ich könnte doch im Kopf rechnen und Mails per Post verschicken? Und warum muß ich den Rechner eigentlich abends wieder runterfahren?
Daniel A. schrieb: > Man kann mit vi & co. alles > machen, nur eben auf andere weise. Das ist Nonsens. Oben hab ich einiges aufgezählt was damit definitiv nicht geht. Auch nicht auf andere Weise, höchstens wenn man unvollständig oder fehlerhaft zu "andere Weise" umdefiniert. Und das war auch der einzige Punkt der zu argumentieren war und nicht irgendein nachträglich angebrachter lächerlicher Ablenkungsschachzug im Stil von "ich selbst brauch dieses oder jenes Feature nicht also wer sonst könnte es dann schon brauchen". Wenn jemand schreibt "vim kann alles was CTD kann" und ich frage dann "kann es dieses oder jenes etwa auch?" dann sind "ich brauch das nicht" oder "wer braucht das schon" keine gültigen Antworten im Sinne der Fragestellung.
Bernd K. schrieb: > Da wird auch schon öfter mal ein bescheuert benamster Bezeichner in was > endgültiges umbenannt Vielleicht benennen andere Leute die Bezeichner gar nicht erst bescheuert, weil sie besser planen? Ich habe jedenfalls auch in IDEs, die solch eine Funktion haben (qtcreator zum Bleistift) diese bislang noch nie benötigt. Autocompletion schon eher mal, gerade in Qt, da kenne ich noch nicht das ganze System auswendig wie bei anderen Dingen. Hör doch einfach auf, Dinge schlechtzureden, von denen du offenbar keine Ahnung hast. Im Gegenzug darfst du dann erwarten, dass andere dir deine Lieblings-IDE nicht schlechtreden.
Jörg W. schrieb: > Ich habe jedenfalls auch in > IDEs, die solch eine Funktion haben (qtcreator zum Bleistift) diese > bislang noch nie benötigt Thema verfehlt. Jemand hat behauptet das (und anderes) geht in Vim und ich habe darauf einige Punkte nachgefragt. Also hör doch einfach auf Fragen umzudefinieren oder den Fragesteller zu diskreditieren nur weil Du persönlich nicht in die Situation kommst jemals Berge von alten Code zu refactorn. > Hör doch einfach auf, Dinge schlechtzureden, von denen du offenbar > keine Ahnung hast. Persönliche Angriffe wenn die Argumente ausgehen? Und übrigens niemand redet Vim schlecht. Wenn ich darauf hinweise daß ein Hammer nicht das geeignete Werkzeug ist um Schrauben zu versenken (obwohl es irgendie schon geht, nur "auf andere Weise") dann hab ich nicht den Hammer schlechtgeredet.
Jörg W. schrieb: > Vielleicht benennen andere Leute die Bezeichner gar nicht erst > bescheuert Doch das tun sie. Ich habs gesehen. Und Du hasts auch schon gesehen, also erzähl keine Geschichten.
:
Bearbeitet durch User
Bernd K. schrieb: > Und Du hasts auch schon gesehen OK, wenn du schon weißt, was ich gesehen habe, dann brauchen wir hier nicht weiterzudiskutieren. Du lieferst dir ja dann sowohl Argumente als auch Gegenargumente gleich selbst, das passt natürlich dann immer.
>> Arbeite mal mit Eclipse direkt übers Internet auf den Servern beim >> Kunden >Warum sollte man sowas bescheuertes machen? Was haben meine Quelltexte >beim Kunden verloren? Und selbst wenn er ne Kopie der Quellen bekommt >hab ich immer noch ne ausgecheckte Arbeitskopie des ganzen Projekts samt >funktionierender Buildumgebung und allem Pipapo auf meinem >Arbeitsplatzrechner oder Laptop. Du hast keine Ahnung und deine Projekte sind wahrscheinlich Peanuts. Vi fängt dort an wo du aufhörst und AIX ist mit dabei. Von Lagersteuerungen für Kommisionierungs Anlagen hast du noch nie was gehört, Datenbanken das ist für dich ein Fremdwort, aber nur weil du es nicht kennst musst du nicht soviel Blödsinn daherlabern.
Hans schrieb: > Du hast keine Ahnung Nun verfällst du auch schon in den Modus, wo du weißt, was Bernd alles schon gesehen hat und was noch nicht …
Bernd K. schrieb: > Daniel A. schrieb: >> Man kann mit vi & co. alles >> machen, nur eben auf andere weise. > > Das ist Nonsens. Oben hab ich einiges aufgezählt was damit definitiv > nicht geht. Es geht mir hier um das Tun von Dingen, nicht das wie, nicht um spezifische Funktionen. Dinge Scope bezogen in vielen Dateien umbenenen ist eine sehr spezifische Funktionalität, die nicht jede IDE mitbringt. Dinge umbenennen ist eine einfache Aufgabe, die mit jeder IDE und jedem Editor gemacht werden kann. Mit letzterem kann ich ersteres machen, es geht somit einfach auf andere weise, in diesem Fall halt manuell. Deshalb kann man mit einem Editor alles machen, also jede Aufgabe erledigen. Das ein anderes Programm andere Funktionen hat, stelle ich nicht in frage.
Daniel A. schrieb: > Warum sollte ich > nicht so oder so wissen, welche defines gesetzt sind Zum Beispiel weil Du gerade das Projekt eines Kollegen übernimmst, der die Firma verläßt. Oder umgedreht, weil Du gerade in der Firma neu angefangen hast und die Codebasis nicht kennst. Jörg W. schrieb: > Vielleicht benennen andere Leute die Bezeichner gar nicht erst > bescheuert, weil sie besser planen? Wenn man Refactoring macht oder Anforderungen sich ändern, dann ändert sich auch Code, und oftmals ändert sich dann auch die Bedeutung von Variablen oder Funktionen. Das ist jedenfalls der Grund, wieso ich welche umbenenne, weil der alte Name nicht mehr paßt.
Jörg W. schrieb: > Vielleicht benennen andere Leute die Bezeichner gar nicht erst > bescheuert, weil sie besser planen? Ich habe jedenfalls auch in IDEs, > die solch eine Funktion haben (qtcreator zum Bleistift) diese bislang > noch nie benötigt. Das ist ein etwas seltsames Argument. Genausogut könnte man argumentieren: "Debugger sind fürn Popo weil man nur besser planen muss um einfach keine Bugs zu programmieren". Es stimmt schon: mit vi und co. geht alles, irgendwie. Aber wenn dann Features genannt werden die vi nicht hat und dessen Fehlen man mit " brauch ich nicht" quitiert nachdem man vollmundig getönt hat was vi alles kann... Nunja, weniger Missionierungseifer würde jedem gut zu Gesicht stehn ;-) Auch dem Jörg, vom dem ich ein bischen über sein seltsames Argument überrascht bin.
Benji schrieb: > Aber wenn dann Features genannt werden die vi nicht hat und dessen > Fehlen man mit " brauch ich nicht" quitiert nachdem man vollmundig > getönt hat was vi alles kann... Schauen wir mal, was da drann ist: Daniel A. schrieb: > Man kann mit vi & co. alles > machen, nur eben auf andere weise. Hier ist die aussage, das man, also eine Person, mit vi alles machen kann, nicht dass vi alles machen kann. René H. schrieb: > Eclipse mit CDT kann nicht mehr, was ich mit vi nicht auch könnte. Hier das selbe. Er könnte es mit vi auch, nicht vi könnte es auch. Der Teufel liegt im Detail.
Benji schrieb: > mt schon: mit vi und co. geht alles, irgendwie. > Aber wenn dann Features genannt werden die vi nicht hat und dessen > Fehlen man mit " brauch ich nicht" quitiert nachdem man vollmundig > getönt hat was vi alles kann... Man war ich, nicht Jörg. Und ich habe mitnichten missioniert. Und ja, dass meiste was Bernd aufgezählt hat, kann vim nicht. Ein paar Dinge allerdings schon. Natürlich nicht nativ, aber mit Plugins. Kann man jetzt das müssige Thema vim vs Emacs vs Eclipse vs sonst IDE lassen? Das war nicht mal im Ansatz die Frage des TOs. Grüsse, René
Benji schrieb: > Nunja, weniger Missionierungseifer würde jedem gut zu Gesicht stehn ;-) Ja, sag das mal denen, die hier unbedingt „ihre“ Lieblings-IDE missionieren müssen. Ich benutze selbst den vi eher selten, aber es liegt mir fern, jemandem, für den das das wesentliche Arbeitsmittel ist, einreden zu wollen, dass dieses Arbeitsmittel eigentlich ja gar nicht für die Suppe taugt, wie Bernd das hier versucht hat (zumindest indirekt, indem er einen Haufen Krams gepostet hat, wie toll seine Lieblings-IDE so ist). > Genausogut könnte man argumentieren: "Debugger sind fürn Popo weil man > nur besser planen muss um einfach keine Bugs zu programmieren". Nein. Ich habe damit argumentiert, dass ich trotz einer IDE, die sowas kann (qtcreator) bislang noch nie Bedarf für genau so ein Feature hatte. Das Werkzeug war also da, aber es suchte eine sinnvolle Anwendung.
> Autor: Alexander S. (alesi) >Datum: 06.12.2016 19:11 >Das geht nur mit der Tastatur, ohne Maus, sehr effizient. Aber >jedem das seine... Jedem das seine .... Vorsicht mit solchen Sprüchen, man sollte um deren historische Bedeutung wissen: https://de.wikipedia.org/wiki/Jedem_das_Seine
Um dieser vi vs Eclipse Diskussion mal ein Ende zu setzen, will ich Emacs ins Spiel bringen ;) Emacs kann nämlich wirklich alles was Eclipse auch kann, womit dann Bernds Argumentation hinfällig ist.
Nicht vi aber emacs schrieb: > Um dieser vi vs Eclipse Diskussion mal ein Ende zu setzen, will ich > Emacs ins Spiel bringen ;) > Emacs kann nämlich wirklich alles was Eclipse auch kann, womit dann > Bernds Argumentation hinfällig ist. Emacs ist auch kein Editor sondern ein Betriebssystem :)) Grüsse, René
René H. schrieb: > Emacs ist auch kein Editor sondern ein Betriebssystem :)) "Emacs is a great operating system – it lacks a good editor, though." So, der darf in so einem Thread nicht fehlen ;-) Jörg W. schrieb: > Nein. Ich habe damit argumentiert, dass ich trotz einer IDE, die > sowas kann (qtcreator) bislang noch nie Bedarf für genau so ein > Feature hatte. Das Werkzeug war also da, aber es suchte eine sinnvolle > Anwendung. Das las sich eher so als wäre dieses Feature überflüssig weil einem guten Programmierer ja solche Fehler (Variablen unpassend benannt) eh nicht passieren können. Aber wir wollen jetzt nicht kleinlich sein. Daniel A. schrieb: > Hier ist die aussage, das man, also eine Person, mit vi alles machen > kann, nicht dass vi alles machen kann. Daniel A. schrieb: > Hier das selbe. Er könnte es mit vi auch, nicht vi könnte es auch. > > Der Teufel liegt im Detail. Letzendlich kann auch der notepad.exe alles. Imho gibts da sogar Suchen & Ersetzen, also sogar Komfort-Features!! Aber es ist halt so: alles was die IDE nicht per Feature mitbringt muss man halt irgendwie zu Fuss machen (siehe Variablen-Umbenennen). Wenn man das Feature natürlich nicht braucht ists nicht so tragisch. Ich denke es bestreitet keiner dass man mit vi alles machen kann. Objektiv gesehen hat aber der Eclipse mehr Features. Das muss man nicht ausdiskutieren, das kann man nachzählen. Disclaimer: Eclipse ist nicht mein Lieblingseditor.
Alexander S. schrieb: > Wie deElf schon geschrieben hat, bieten zum einen die IDEs eine > grafische Oberfläche für gdb und zum anderen kann man unter Unix/Linux > schon seit Jahrzehnten komfortabel aus den Standard-Editoren > Emacs und vi/vim heraus compilieren und debuggen. Auauauau. VI. :-( Warum, verdammt noch mal, sollte ausgerechnet DAS erstrebenswert sein? Funfact: Wie treibt man Linux-Anfänger in den Wahnsinn? man muss nur sagen: Tipp mal VI ein. Oder MAN VI. Ein Lehrling bei uns hat aus Verzweiflung den Stecker des PC gezogen, weil er aus VI nicht herauskam. Ein kleines Beispiel für eine GDB-taugliche IDE wäre Code:Blocks mit GCC. Nett für kleiner Projekte, und um deutlich besser als das zickige DEVC++.
Jetzt wo Vi vs. EMACS durch ist, könnten wir bitte bei Elm vs. Mutt weitermachen? Vielen Dank!
Oherrje schrieb: > Funfact: > Wie treibt man Linux-Anfänger in den Wahnsinn? man muss nur sagen: Tipp > mal VI ein. Mach ich mal. Da kommt dann direkt auf den Screen: ~ ~ VIM - verbesserter Vi ~ ~ Version 7.4.629 ~ von Bram Moolenaar und Anderen ~ Verändert von <bugzilla@redhat.com> ~ Vim ist Open Source und kann frei weitergegeben werden ~ ~ Helfen Sie armen Kindern in Uganda! ~ Tippe :help iccf<Enter> für Informationen darüber ~ ~ Tippe :q<Enter> zum Beenden ~ Tippe :help<Enter> oder <F1> für Online Hilfe ~ Tippe :help version7<Enter> für Versions-Informationen Der lesende Teil der Menschheit gibt dann einfach mal <F1> ein und findet dann (u.A.) den Punkt "~ |tutor| 30 minutes training course for beginners". Wo liegt jetzt das Problem? Anyway. Ihr verzankt Euch gerade in eine uralte & völlig überflüssige "Wer-hat-den-Längsten" Diskussion über Editoren & IDEs. WEM ist damit wie geholfen? Ich nehm eigentlich immer das, was gerade sinnvoll ist. Ob vi/gcc/gdb, Eclipse, Keil oder LWW ist mir eigentlich egal. Ich habe da sowieso meist nicht die Option der großen Auswahl (und auch weder Zeit noch Nerv dafür). Aber ich will Euch ja nicht die Zankerei vergrätzen. Darum: Wie gut geht z.B. Eclipse mit z.B. Ada oder Verilog? (und ja, die Sprachen werden eingesetzt) /regards
Andreas H. schrieb: > Der lesende Teil der Menschheit gibt dann einfach mal <F1> ein und > findet dann (u.A.) den Punkt "~ |tutor| 30 minutes training course > for beginners". Nützlicher wäre es doch gewesen, gleich das Kürzel für "Beenden" im Prolog mit anzugeben. Nun gut, so findet man wenigstens den Tutor und ist nach 30min in der Lage, das Programm zu verlassen ;-) Andreas H. schrieb: > Wie gut geht z.B. Eclipse mit z.B. Ada KA, es gibt ein offizielles Plugin dafür, ADT. Taugt das nicht? Ich habs nie benutzt. Du schon?
Le X. schrieb: > Nützlicher wäre es doch gewesen, gleich das Kürzel für "Beenden" im > Prolog mit anzugeben. Andreas H. schrieb: > ~ > ~ Tippe :q<Enter> zum Beenden ... was uns wieder zum lesenden Teil der Menschheit bringt ... ;-) Le X. schrieb: >> Wie gut geht z.B. Eclipse mit z.B. Ada > > KA, es gibt ein offizielles Plugin dafür, ADT. > Taugt das nicht? > Ich habs nie benutzt. Du schon? Wozu? Gibt doch http://www.adacore.com/gnatpro/toolsuite/gps/ /regards
Oliver S. schrieb: > Die hardcore-gdb'ler sind halt auf Unixoiden unterwegs, da gibt es die > Alternative Visual irgendwas nicht. Das gibt es sehr wohl, aber es ist keine Alternative. ;-) https://www.heise.de/developer/meldung/Build-2015-Microsoft-stellt-Visual-Studio-fuer-OS-X-und-Linux-vor-2629280.html
Random .. schrieb: > Wollte mit eclipse ein Projekt, welches aus einem Haufen Libs und einer > Exe besteht, zum compilieren bringen (Linux portierung einer bestehenden > Anwendung). Standardproblem. Hat nicht geklappt, hab dann per Hand > selbst die makefiles (main - makefile und Abstieg in makefiles der Libs) > für Linux geschrieben :-( > > Von einer so professionellen IDE wie Eclipse erwarte ich eig., dass sie > standardprobleme löst. Stattdessen bekomme ich (Kontext-)Menus, wo ich > auf einem 4k Monitor noch scrollen muss ..... > [...] > Dieses ganze gnu Zeugs ist klasse, weil kostenlos. Das Zeug ist vor allem deswegen klasse, weil es extrem leistungsfähig, flexibel, und nahezu beliebig kombinierbar ist. > Man muss aber Zeit mitbringen. Jemand, der nicht alle vi und gdb > Kommandos auswendig kennt, braucht erstmal ne Weile. Dasselbe gilt für jede IDE, egal, ob sie Visual XY, Eclipse, oder anders heißt. Da muß man sich auch einarbeiten und die Menüs kennenlernen; eine Erfahrung, die Du ja selbst schon gemacht und oben beschrieben hast. Du scheinst gar nicht zu merken, wie Du Dir selbst widersprichst. > Ich verwende vi zur Konfiguration von Linux > Systemen. Zur produktiven Softwareenticklung alleine oder in einer > Gruppe ziehe ich professionelle Tools vor. Als Deine GUI-Werkzeuge noch nicht einmal erfunden waren, sind gdb und vi schon längst professionelle Tools gewesen, und seitdem haben sie sich natürlich nicht zurück-, sondern weiterentwickelt, und selbstverständlich auch nichts von ihrer Professionalität eingebüßt. Und daß Deine Werkzeuge ein GUI haben, macht sie weder professioneller, noch produktiver -- viele Aufgaben haben vi- und Emacs-User schon gelöst, bevor Deine grafische IDE überhaupt erst gestartet und initialisiert ist. Immer wenn ich darauf hinweise, daß man zum Entwickeln nicht unbedingt eine IDE braucht, poppen kompetente Fachleute auf und erklären mir, daß Funktion XY doch extrem hilfreich sei und man damit so viel Zeit sparen würde. Lustigerweise werden dann jedesmal Funktionen genannt, die mein Emacs schon gehabt hat, als diese "Fachleute" noch nicht geboren waren.
Bernd K. schrieb: > René H. schrieb: >> Eclipse mit CDT kann nicht mehr, was ich mit vi nicht auch könnte. > > * Aufrufbaum? > * [...] > * Statische Codeanalyse > [...] > Weiter gehts: > * Source-Level Debugging? > - auch im generierten Assembler-Code? > * Breakpoints? > - auch im Assembler code? > * Watches, Register-, Peripherie-, Memory-Browser? > * Direkt benutzbare Plugins für alle gängigen Debug-Adapter? Ja, und? > IDEs die das alles können kann man an einer Hand abzählen, vi(m) ist > nicht dabei. Vim ist nämlich ein Texteditor. Für simple Textdateien. Man kann damit auch riesengroße und sehr komplizierte Textdateien be- und verarbeiten, bei denen Deine IDE schon beim Laden verreckt. Ansonsten kann man mit einer entsprechenden Umgebung, von der ein vi oder Emacs natürlich nur eine Komponente ist, natürlich alles machen, was Du oben aufgerufen hast. Und zwar nicht nur für eine oder zwei Sprachen, sondern für etliche, was bedeutet: man muß nicht für jede Sprache neue Werkzeuge erlernen, sondern kann das einmal erworbene Wissen immer wieder in unterschiedlichen Kontexten weiter- und wiedernutzen. Letztlich stellt Dein Einwurf auf die Frage ab, ob man einen Monolithen haben will, der verschiedene Werkzeuge integriert, (manchmal sogar einen für die betreffende Sprache leidlich brauchbaren Texteditor) mit dem man in der Regel nur für genau eine einzige Sprache entwickeln kann. Oder ob man lieber einen Werkzeugkasten von vielen voneinander unabhängigen, frei kombinierbaren Werkzeugen haben will, von denen jedes nur eine einzige Aufgabe, die aber besonders gut beherrscht, mit denen man für etliche Sprachen, auf etlichen Plattformen und für eine Vielzahl von Aufgaben entwickeln kann. Das ist aber keine technische, sondern eine philosophische Frage.
Bernd K. schrieb: > Daniel A. schrieb: >> Wie oft benennt man den schon das halbe Projekt um? > > Jeden Tag bin ich am Editieren, mal erweitere ich es um Neues, mal > ändere ich Bestehendes. Da wird auch schon öfter mal ein bescheuert > benamster Bezeichner in was endgültiges umbenannt, einer der an zwölf > anderen Stellen noch vorkommt, und das tu ich gerne mit zwei > Tastendrücken ohne mir mit nem Texteditor 10 Minuten lang einen > abzubrechen weil Suchen und Ersetzen ein dutzend false positives bringen > würde. Jetzt komm' mal wieder 'runter, Bernd, so viel Unfug auf einmal habe ich von Dir noch nie gelesen. Schau, vi hat da die Funktion %s/src/dst/gc, und diese fragt für jedes Vorkommen von "src" nach, ob sie durch "dst" ersetzt werden soll. Dieselbe Funktion bietet Emacs mit query-replace.
:
Bearbeitet durch User
Gustl B. schrieb: > Jetzt wo Vi vs. EMACS durch ist, könnten wir bitte bei Elm vs. Mutt > weitermachen? Och menno, ich hatte mich schon auf MySQL vs. PostgreSQL gefreut. Aber bei Elm vs. Mutt werfe ich mal Alpine ein.
Le X. schrieb: > Andreas H. schrieb: >> Der lesende Teil der Menschheit gibt dann einfach mal <F1> ein und >> findet dann (u.A.) den Punkt "~ |tutor| 30 minutes training course >> for beginners". > > Nützlicher wäre es doch gewesen, gleich das Kürzel für "Beenden" im > Prolog mit anzugeben. > > Nun gut, so findet man wenigstens den Tutor und ist nach 30min in der > Lage, das Programm zu verlassen ;-) Bitte sag: welchen Teil von >> ~ Tippe :q<Enter> zum Beenden hast Du denn nicht verstanden?
Sheeva P. schrieb: > Bernd, so viel Unfug auf einmal habe ich > von Dir noch nie gelesen. Schau, vi hat da die Funktion %s/src/dst/gc, > und diese fragt für jedes Vorkommen von "src" nach, ob sie durch "dst" > ersetzt werden soll. Dieselbe Funktion bietet Emacs mit query-replace. Richtig, und das will man nicht, weil Zeitverschwendung jedes einzelne Vorkommen manuell bewerten zu müssen, vor allem wenn es über mehrere Files hinweg geht. In solchen Fällen bin ich vermutlich mit Rechtsklick, Refactor->Rename des Resharpers zügiger unterwegs. Oh wei, jetzt habe ich mich geoutet mit C#/.NET zu entwickeln...
D. I. schrieb: > Richtig, und das will man nicht, weil Zeitverschwendung jedes einzelne > Vorkommen manuell bewerten zu müssen, vor allem wenn es über mehrere > Files hinweg geht. Dann lass das c weg und du musst nichts bewerten.
S. R. schrieb: >> vor allem wenn es über mehrere >> Files hinweg geht. > > Dann lass das c weg und du musst nichts bewerten. Und wer bewertet es dann? Irgendjemand oder etwas muss es tun.
Nur mal so zur Info, weil hier gerade die Möglichkeit des Umbenennens von Bezeichnern so hochkocht (auch wenn dies mit dem GDB überhaupt nichts zu tun hat): Es gibt unter den Extra-Clang-Tools das Tool clang-rename, das genau für diesen Zweck gemacht ist: http://clang.llvm.org/extra/clang-rename.html Dieses Tool lässt sich sowohl stand-alone nutzen als auch in jeden erweiterbaren Texteditor einbauen (entweder als Executable oder als Bibliotheksfunktion aus libclang). Es gibt entsprechende Plugins für Vim und Emacs, die aber kaum jemand installiert hat, weil man die Funktionen eher selten braucht. Da clang-rename denselben C/C++-Parser wie im Clang-Compiler nutzt und dieselben Kommandozeilenoptionen unterstützt werden, sollte das Ergebnis mindestens so gut sein wie in Eclipse.
Sheeva P. schrieb: > Als Deine GUI-Werkzeuge noch nicht einmal erfunden waren, sind gdb und > vi schon längst professionelle Tools gewesen, und seitdem haben sie sich > natürlich nicht zurück- Jaja, so wie tar - gelle? Also, du übertreibst heftig. Der Mensch ist ein "Augentier" - jedenfalls die meisten von uns. Eben deshalb hat sich ein visuelle Interface (GUI) zwischen Mensch und Maschine auf allerbreitester Front durchgesetzt. Das was du da grad gelobt hast, ist Technik von vor-vorgestern. Es hat durchaus funktioniert, war und ist jedoch eine Zumutung. Damals ging das nicht anders, wegen Beschränktheit der Hardware, aber heutzutage ist das Nostalgie. Jetzt lobe mir sowas wie vi nicht, ich kenne noch die Vorgänger, nämlich Editieren am Teletype, wo man die auf Paralleldrucker herausge"rotzte" Übersetzungsliste daneben liegen haben mußte, um per Kommando Zeile 117 anzuwählen, dann ausdrucken, korrekturschreiben und speichern. Kannst mir glauben, daß heutige Editoren mit GUI um Größenordnungen besser sind als solche Steinzeit. Falls ich mal in die Verlegenheit kommen sollte, per dediziertem Debugger mal was debuggen zu müssen, dann will ich auf gar keinen Fall sowas per Kommandozeile tun müssen. OK - ehe man verreckt tut man sich sowas auch an, aber NICHT FREIWILLIG. W.S.
W.S. schrieb: > Sheeva P. schrieb: >> Als Deine GUI-Werkzeuge noch nicht einmal erfunden waren, sind gdb und >> vi schon längst professionelle Tools gewesen, und seitdem haben sie sich >> natürlich nicht zurück- > > Jaja, so wie tar - gelle? Ja, auch. > Also, du übertreibst heftig. Der Mensch ist ein "Augentier" - jedenfalls > die meisten von uns. Eben deshalb hat sich ein visuelle Interface (GUI) > zwischen Mensch und Maschine auf allerbreitester Front durchgesetzt. Das > was du da grad gelobt hast, ist Technik von vor-vorgestern. Es hat > durchaus funktioniert, war und ist jedoch eine Zumutung. Damals ging das > nicht anders, wegen Beschränktheit der Hardware, aber heutzutage ist das > Nostalgie. Gerade von Dir hätte ich nicht gedacht, daß Du so ein Klickibunti-Fänboi bist. Aber ein Texteditor ist ein Texteditor bleibt ein Texteditor, und damit -- Überraschung, wer hätte das gedacht! -- editiert man Text. Und weil sich die grafischen Programmierumgebungen trotz des vierzigjährigen Hypes darum immer noch nicht durchgesetzt haben, besteht die Arbeit der meisten Programmierer im Wesentlichen daraus, Texte zu editieren. Deswegen ist so ein Texteditor bis heute die wesentlichste und wichtigste Kernkomponente jeder Programmierumgebung, und auch in IDEs immer noch die zentrale Komponente, mit der die meisten Arbeit gemacht wird, auch von den "Augentieren". Ob der Quelltext nun in einem winzigen Texteditor-Fenster in einer IDE angezeigt wird, zwischen der Projekt- und Verzeichnisansicht links, den Eigenschaften rechts, dem Terminalfenster unten und zwei bis fünf Zeilen Icons oben: es ist und bleibt ein Textfenster, gleichgültig, ob die IDE nun Delphi, Visual Dingsbums, Code::Blocks, Eclipse, QtCreator, KDevelop oder Klausdieter heißt. Insofern reduziert sich die Frage nun darauf, ob man ein spezialisiertes GUI haben will, das um einen beschränkten Texteditor herum noch diverse andere Werkzeuge integriert, oder ob man einen besonders leistungsfähigen, flexiblen und universellen Editor haben will, in den man dann dieselben diversen anderen Werkzeuge wahlweise integriert oder sie extern nutzen möchte. Das ist aber eine Frage des persönlichen Geschmacks und, wie oben angedeutet, eine philosophische Frage, ob man lieber Monolithen oder einen Werkzeugkasten voller unabhängiger, universeller und frei kombinierbarer Werkzeuge haben will, von denen jedes einzelne nur eine Aufgabe, die aber besonders gut und umfassend beherrscht. > Jetzt lobe mir sowas wie vi nicht, ich kenne noch die Vorgänger, Du bist ja ein richtiger kleiner Held! Obwohl: ich kenne die Vorgänger auch noch, da sind wir jetzt wohl beide kleine Helden. ;-) > Kannst mir glauben, daß heutige Editoren mit GUI um Größenordnungen > besser sind als solche Steinzeit. Das brauche ich nicht zu glauben, weil ich es selbst noch erlebt habe. Aber mit modernen Versionen von vi(m) und Emacs hat Dein Schwelgen in nostalgischen Erinnerungen natürlich nicht das Geringste zu tun, und -- vermutlich ist es Dir entfallen, in unserem Alter ist das Gedächtnis ja manchmal nicht mehr so gut -- auch für vi und Emacs gibt es schon seit langer Zeit sehr leistungsfähige GUIs, ebenso natürlich für den gdb. Trotzdem haben vi, Emacs und gdb natürlich einen gewaltigen Vorteil: man kann sie mit oder ohne grafisches UI benutzen, auf dem Desktop mit oder auf einer headless-Kiste eben auch ohne, mit denselben Funktionen und weitestgehend auch demselben Komfort, mit Ausnahme der Klickerei. Die mag zwar für die "Augentiere" wichtig sein, damit sie sich durch Menüs klicken können statt die Befehle ihres Werkzeugs zu erlernen. Aber Leute, die ihr Werkzeug kennen, vermeiden wenn möglich jeden Griff zur Maus und arbeiten auch bei GUI-Programmen lieber mit Tastatur-Shortcuts. Das geht nämlich einfach viel effizienter und schneller als die blöde Klickerei. > Falls ich mal in die Verlegenheit kommen sollte, per dediziertem > Debugger mal was debuggen zu müssen, dann will ich auf gar keinen Fall > sowas per Kommandozeile tun müssen. OK - ehe man verreckt tut man sich > sowas auch an, aber NICHT FREIWILLIG. Tja, ich nutze den gdb freiwillig ohne GUI. Die Arbeit mit dem gdb ist weitestgehend Textarbeit, und ob ich "break main.c:17" von Hand eingebe oder die Datei "main.c" anwähle, zu Zeile 17 scrolle, diese anklicke und im aufpoppenden Kontext-Menü "Set Breakpoint" auswähle, um dann wieder zu der Stelle zurückzukehren, an der ich ursprünglich gewesen bin... da ist meine Steuerung per Texteingabe, nicht zuletzt auch dank Tab-Completion und readline, sogar schneller. Aber im Gegensatz zu Euch GUI-Fetischisten mag ich nicht missionieren. Wenn Du mit Klickibunti besser klarkommst, dann mach' das doch. Aber versuch nicht, mir zu verklickern, was bei mir und für mich am Besten funktioniert. Denn wenn ich eines mit absoluter Sicherheit wesentlich besser weiß als Du, dann, welche Werkzeuge für mich funktionieren.
Sheeva P. schrieb: > Tja, ich nutze den gdb freiwillig ohne GUI. Die Arbeit mit dem gdb ist > weitestgehend Textarbeit, und ob ich "break main.c:17" von Hand eingebe > oder die Datei "main.c" anwähle, zu Zeile 17 scrolle, Aber woher weißt du dass du bei main.c:17 anhalten willst? Auswendig? Oder weil du vorher in einem Editor deiner Wahl rumgescrollt hast bist du die interessante Zeile identifiziert hast? Meine Variablen kenn ich auch nicht auswendig. Klar, die häufig benötigten schon. Mit Pfade verhält es sich ähnlich. Klar gibt es die Tab-Taste, aber wenn man nicht gerade ständig in der selben Verzeichnisstruktur unterwegs ist und annähernd weiß, wo man hinmöchte finde ich einen graphischen Verzeichnisbaum schon eleganter. Aber vielleicht hab ich auch nur eine weniger innige Beziehung zu meinem Quellcode.
Le X. schrieb: > Aber vielleicht hab ich auch nur eine weniger innige Beziehung zu meinem > Quellcode. Naja wenn du nur mit Miniprogrämmchen im Rahmen 1000-5000LOC hast, was bei Mikrokontrolleuren wohl die Regel ist, ist das kein Problem alles im Kopf zu behalten und jedes Byte persönlich zu kennen, vor allem wenn man der einzige Entwickler dran ist. Ist man in einem 50-Mann Projekt unterwegs mit 2 Größenordnungen mehr an LOC, sieht die Sache halt weng anders aus, vor allem wenn man mal in Fremdkomponenten mit denen man nicht tagtäglich zu tun abtauchen muss. Kommt halt auf den Scope an. Daher für jedes Problem das richtige Werkzeug. Auch hier wird niemandem verboten sich mit dem Editor seiner wahl zu plagen, solange am Ende der Build grün ist, ist es egal wie man dahin gekommen ist. Natürlich müssen die Coding-Guidelines eingehalten werden, die halt praktischer Weise per Resharper-Regeln implementiert sind, so dass man die Einhaltung bei Nutzung desselbigen geschenkt bekommt.
Sheeva P. schrieb: > und ob ich "break main.c:17" von Hand eingebe > oder die Datei "main.c" anwähle, zu Zeile 17 scrolle, diese anklicke und > im aufpoppenden Kontext-Menü "Set Breakpoint" auswähle, Ein konstruiertes Beispiel, fern jeder Realität. Ihr Vim-Verfechter macht euch mindestens der selben Realitätsverzerrung bei der Argumentation schuldig wie ihr es anderen vorwerft. > um dann wieder > zu der Stelle zurückzukehren Jaja, ich setz einen Breakpoint in der main und dann kehre ich wieder zu dem Tab mit den Kochrezepten zurück weil mich das ja gar nicht interessiert was da passiert beim Debuggen in der Main. Schon klar. Erstens: Woher willst Du wissen daß die Zeile an der Du den Breakpoint haben willst die Nummer 17 hat ohne die Datei zuvor an der gewünschten Stelle zu besichtigen? Auch der Vim-User setzt keine Breakpoints blind auf gut Glück in zufälligen Zeilen in irgendwelchen anderen Dateien, er setzt Breakpoints genau an den Stellen an denen er gerade zugange ist. Zweitens: Wie kommst Du auf das schmale Brett man müsse für alles die Maus benutzen sobald eine solche auf dem Tisch liegt? Einen Breakpoint setzt man in Eclipse mit Ctrl+Shift B. Drittens: Warum behauptest Du ohne das jemals selbst gesehen zu haben daß man bei irgendeiner der üblichen C/C++ IDEs (und auch anderer) jemals gezwungen war die rechte Maustatste und das Kontextmenü zu bemühen anstatt einfach an der entsprechenden Stelle einmal auf die Breakpoint-Leiste zu klicken (und nochmal um ihn wieder zu entfernen)? ... Also wenn Du schon konkrete Use-Cases vergleichen willst dann vergleich sie fair und realistisch und phantasiere keine extra-umständlichen Arbeitsabläufe auf der gegnerischen Platform daher die dort gar nicht existieren.
:
Bearbeitet durch User
Le X. schrieb: > Sheeva P. schrieb: >> Tja, ich nutze den gdb freiwillig ohne GUI. Die Arbeit mit dem gdb ist >> weitestgehend Textarbeit, und ob ich "break main.c:17" von Hand eingebe >> oder die Datei "main.c" anwähle, zu Zeile 17 scrolle, > > Aber woher weißt du dass du bei main.c:17 anhalten willst? Auswendig? Entweder das, oder aus der vorhergehenden Fehlermeldung, oder aus der Ausgabe des gdb, oder... > Oder weil du vorher in einem Editor deiner Wahl rumgescrollt hast bist > du die interessante Zeile identifiziert hast? Der Editor meiner Wahl heißt Emacs und ja, mit dem kann man auch scrollen, Zeilen- und Spaltennummern ablesen, und wenn ich will, kann ich natürlich auch den gdb-Modus benutzen, der dann ziemlich genau so funktioniert, wie Du es aus Deiner IDE kennst. > Mit Pfade verhält es sich ähnlich. Klar gibt es die Tab-Taste, aber wenn > man nicht gerade ständig in der selben Verzeichnisstruktur unterwegs ist > und annähernd weiß, wo man hinmöchte finde ich einen graphischen > Verzeichnisbaum schon eleganter. Dazu hat mein Emacs eine Liste der geöffneten Dateien und Verzeichnisse, die ich sofort anspringen kann; durch Verzeichnisse kann ich dabei auch komfortabel navigieren. Ansonsten hat die Bash mit pushd, popd und dirs feine Komfortfunktionen, um sich Verzeichnisse zu merken und zwischen ihnen hin und her zu springen. Das Werkzeug "tree" bietet zudem die Möglichkeit, Verzeichnisbäume sauber eingerückt und hübsch koloriert anzuzeigen, auf Wunsch auch angereichert mit Besitzer, Gruppe, Größe, Zeitstempel und Inode, anhand von Mustern, und auf Wunsch auch im JSON- oder XML-Format zur Weiterverarbeitung mit den anderen Werkzeugen, die moderne Linux-/UNIX-Werkzeugkästen bieten. Und dann habe ich noch einen Vorteil: meine Werkzeuge laufen überall, auf Linux, AIX, Solaris, OS/X, und sogar unter Windows, ohne daß ich mich umstellen muß. Davon abgesehen bedeutet die Tatsache, daß ich für die meisten Aufgaben leistungsfähige Kommandozeilenwerkzeuge kenne und bevorzuge, nicht, daß ich deswegen keine grafischen Werkzeuge hätte oder diese nicht benutzen könnte, wenn ich wollte. Für einige Aufgaben benutze ich sogar welche. > Aber vielleicht hab ich auch nur eine weniger innige Beziehung zu meinem > Quellcode. Meine Beziehung zu Quellcode ist nicht sehr innig, aber mein Editor und die Kommandozeile bieten mir effiziente Möglichkeiten, damit umzugehen.
D. I. schrieb: > Naja wenn du nur mit Miniprogrämmchen im Rahmen 1000-5000LOC hast, was > bei Mikrokontrolleuren wohl die Regel ist, ist das kein Problem alles im > Kopf zu behalten und jedes Byte persönlich zu kennen, vor allem wenn man > der einzige Entwickler dran ist. Wir sind hier doch in einem Mikrocontroller-Forum, oder? Und ausgerechnet hier wollen mir Menschen, die demzufolge doch meistens "Miniprogrämmchen" schreiben, daß das nur mit einer IDE und einem grafischen Debugger gehe? Das erscheint mir einigermaßen merkwürdig, da ich ausgesprochen selten an "Miniprogrämmchen" arbeite. Im Realen Leben entwickeln meine Kollegen und ich eine Realtime Stream Processing Engine, die zur Betrugserkennung bei Banken und Versicherungen eingesetzt wird und einige 100k LOC hat, sowie Webfrontends zur Fallbearbeitung und einen Fat Client zur Bearbeitung der Regelwerke, die nochmals deutlich umfassenreicher sind. Trotzdem IDEs und grafische Debugger für die Herren "Miniprogrämmchen"-Autoren unverzichtbar zu sein scheinen, komme ich wunderbar ohne diese aus.
Bernd K. schrieb: > Sheeva P. schrieb: >> und ob ich "break main.c:17" von Hand eingebe >> oder die Datei "main.c" anwähle, zu Zeile 17 scrolle, diese anklicke und >> im aufpoppenden Kontext-Menü "Set Breakpoint" auswähle, > > Ein konstruiertes Beispiel, fern jeder Realität. Das Setzen eines Breakpoints in einem Debugger ist "ein konstruiertes Beispiel, fern jeder Realität"? Ah ja. > Ihr Vim-Verfechter Zum Glück kannst Du mich damit nicht meinen, denn ich gehöre der Emacs-Fraktion an. > Jaja, ich setz einen Breakpoint in der main und dann kehre ich wieder zu > dem Tab mit den Kochrezepten zurück weil mich das ja gar nicht > interessiert was da passiert beim Debuggen in der Main. Schon klar. Also mein Debugger läßt das Programm bis zum Breakpoint durchlaufen und stoppt dann. Nicht selten hat das Programm vorher einige Gigabyte an Daten eingelesen oder eine Datenbank durchgerödelt, und währenddessen lese ich auch gerne ein paar Kochrezepte, Forenbeiträge, oder andere interessante Dinge. > Erstens: Woher willst Du wissen daß die Zeile an der Du den Breakpoint > haben willst die Nummer 17 hat ohne die Datei zuvor an der gewünschten > Stelle zu besichtigen? Auch der Vim-User setzt keine Breakpoints blind > auf gut Glück in zufälligen Zeilen in irgendwelchen anderen Dateien, er > setzt Breakpoints genau an den Stellen an denen er gerade zugange ist. Also kann der Vim-User jetzt doch Breakpoints setzen? Oben hattest Du noch behauptet, der könne das gar nicht. Allerdings -- Du wirst lachen -- kann mein Emacs auch Text anzeigen, zwischen verschiedenen Codestellen, Dateien und Verzeichnissen navigieren, und so weiter -- wenn ich also nicht weiß, wo ich meinen Break setzen will, dann schaue ich es mir einfach vorher an, genau so, wie Du das in Deiner Wunder-IDE auch tust. Und wenn ich einen ganz, ganz langsamen Tag habe, starte ich den gdb-Modus des Emacs und kann meine Breakpoints genauso mit der Maus setzen, wie Du in Deiner IDE. > Zweitens: Wie kommst Du auf das schmale Brett man müsse für alles die > Maus benutzen sobald eine solche auf dem Tisch liegt? Einen Breakpoint > setzt man in Eclipse mit Ctrl+Shift B. Du meinst, man muß dazu die entsprechenden Shortcuts lernen? Also genau so, wie ich die Befehle des gdb gelernt habe? Welchen Vorteil soll denn die grafische Benutzeroberfläche denn dann noch haben? > Drittens: Warum behauptest Du ohne das jemals selbst gesehen zu haben > daß man bei irgendeiner der üblichen C/C++ IDEs (und auch anderer) > jemals gezwungen war die rechte Maustatste und das Kontextmenü zu > bemühen anstatt einfach an der entsprechenden Stelle einmal auf die > Breakpoint-Leiste zu klicken (und nochmal um ihn wieder zu entfernen)? Oh, bei uns nutzen die meisten meiner Kollegen Eclipse, ich habe das also durchaus schon etliche Male selbst gesehen. Du hast Recht, zum Setzen und Löschen von Breakpoints braucht man keine rechte Maustaste, genausowenig übrigens wie im gdb-Modus des Emacs. Aber es gibt genug andere Aufgaben, für die in Eclipse die rechte Maustaste benutzt wird. > Also wenn Du schon konkrete Use-Cases vergleichen willst dann vergleich > sie fair und realistisch und phantasiere keine extra-umständlichen > Arbeitsabläufe auf der gegnerischen Platform daher die dort gar nicht > existieren. Entschuldige, aber dieses Kompliment gebe ich gerne zurück. Und, am Rande bemerkt, auch Deine Unterstellung, daß ich noch kein Eclipse von Nahem gesehen hätte. In Wirklichkeit scheint es nämlich genau andersherum zu sein: während ich etliche IDEs ausprobiert habe (als ich noch dachte, daß an diesen Dingern etwas Besonders sein müsse, wenn so viele Leute darauf schwören) und fast täglich sehe, wie die Kollegen mit Eclipse und Visual Studio arbeiten, scheinst Du noch keinen Emacs und keinen vi von Nahem gesehen oder einen Kenner bei der Arbeit damit beobachtet zu haben. Die konnten nämlich alles, von dem Du behauptest, daß man dazu zwingend eine IDE bräuchte, schon zu einer Zeit, als Dein Eclipse noch Visual Age for Java hieß und ausschließlich für OS/2 verfügbar war. Wie gesagt: im Gegensatz zu Dir und den anderen IDE-Fänbois will ich hier nicht missionieren. Aber wenn Du behauptest, daß vim und Emacs Funktionen fehlen würden, welche ich bereits seit dreißig Jahren regelmäßig benutze, dann wirst Du mit meinem Widerspruch leben müssen.
Sheeva P. schrieb: > Aber wenn Du behauptest, daß vim und Emacs > Funktionen fehlen würden, welche ich bereits seit dreißig Jahren > regelmäßig benutze Ich habe nicht gesagt daß die Funktionen fehlen die Du benutzt. Ich habe gesagt daß die Funktionen fehlen die ich gestern aufgezählt habe und die Du (deshalb) nicht benutzt.
Bernd K. schrieb: > Ich habe gesagt daß die Funktionen fehlen die ich gestern aufgezählt > habe und die Du (deshalb) nicht benutzt. Da sind wir wieder bei meinem Beitrag vom 9.12., 00:32 Uhr, wo ich die Frage stellte, ob eine Entwicklungsumgebung unbedingt integriert sein muß, oder ob sie auch modular aufgebaut sein kann. Für mich wäre eine integrierte Entwicklungsumgebung ein Rückschritt, schon deswegen, weil ich neben C und C++, Java, Python und Bash-Code auch HTML, XML, JSON, JavaScript, LaTeX, Markdown, SQL und CSV und noch ein paar andere Dinge mit meinem Editor mache und weder Lust dazu habe, noch eine Veranlassung dafür sehe, von meiner ganz bewußt desintegriert gehaltenen, modularen Entwicklungsumgebung abzurücken, die ich weitestgehend nun schon seit über dreißig Jahren und auf jedem System, das mir in meinem Leben über den Weg gelaufen ist, benutzen konnte. Dabei kann es sogar sein, daß Dein Eclipse ein oder zwei Funktion hat, die ich nicht direkt in meinen Editor integriert habe (oder integrieren will), aber, wie gesagt, ein Editor ist zwar der zentrale, aber letztendlich eben doch nur ein Teil einer Entwicklungsumgebung. Das bedeutet aber weder, daß es meiner bewußt und gezielt desintegriert gehaltenen und damit besonders flexiblen Entwicklungsumgebung an Funktionalität, an Professionalität, an Effizienz oder gar an Produktivität mangeln würde. Die Funktionen, die Du gestern aufgezählt hast, könnte ich meinem Editor jedenfalls nachrüsten oder nötigenfalls sogar selbst beibringen -- für derartige Belange haben Emacs und vim sogar eigene Skriptsprachen dabei, nämlich Emacs-LISP und Vimscript. Aber das will ich doch gar nicht, wozu denn? Damit ich am Ende auch so ein langsames, überfrachtetes Funktionsmonster habe wie zum Beispiel ein Eclipse, das schon ohne Plugins fünfzehnmal so lange zum Starten braucht und, ohne auch nur eine Datei geladen zu haben, schon zehnmal mehr von meinem kostbaren Arbeitsspeicher frißt als Emacs? Und dann kann das Monsterding auch noch nur eine Sprache, und ich kann es nicht einmal auf einer Headless-Maschine oder über eine schmalbrüstige SSH-Verbindung benutzen -- was mit Emacs alles gar kein Problem ist. Am Ende sind wir wieder bei der Frage "Monolith vs. Modular". Du hast Dich den Monolithen entschieden, ich mich für die modulare, flexiblere Lösung. Ich habe mit Deiner Entscheidung kein Problem und frage mich langsam ganz ernsthaft, warum Du eins mit meiner zu haben scheinst.
Sheeva P. schrieb: > Und dann kann das Monsterding auch noch nur eine Sprache, und ich kann > es nicht einmal auf einer Headless-Maschine oder über eine > schmalbrüstige SSH-Verbindung benutzen Es kann schon noch ein paar Sprachen mehr. Und für das andere (entwickeln über ssh) fällt mir grad hat echt kein use case ein. Echt nicht. Über ssh mach ich höchstens irgendwelche Konfigurationsarbeit. Dafür ist vim ok. Zum Entwickeln hab ich nen eigenen Rechner unter dem Tisch stehen, soviel Luxus muss sein. Wenn der Code läuft darf er meinen Rechner verlassen, vorher nicht. Und an der Startzeit hab ich auch nichts auszusetzen. Solange die Kaffeemaschine morgens nach dem Booten der langsamste Teil der Ausrüstung ist fallen die 5 Sekunden Eclipse-Start einmal am Tag nicht auf.
:
Bearbeitet durch User
Dieser Streit ist doch wieder ein Generationenproblem. Die 'Alten' sind mit vi, emacs und Co aufgewachsen und haben sich in jahrelanger / jahrzehnterlanger Übung jedes Tastenkürzel eingeprägt. Die 'Jungen' sind mit Klicki-Bunti aufgewachsen und können dort jedes Menü und jedes Tastenkürzel. Die 'Alten' haben jetzt natürlich jahrelang auf die 'Jungen' mehr oder weniger gnädig herabgelächelt. Zuzugeben, dass die modernen IDEs irgendetwas besser können als die altbewährte Toolchain, gar zuzugeben, dass die neuen IDEs in der Summe produktiver sind, würde dann eine massive kognitive Dissonanz auslösen. Am Ende wäre die eigene jahrzehnte alte Erfahrnung nichts mehr wert und man müsste zu Beginn der Einarbeitung in die neue IDE, die zuvor belächelte Jugend noch um Rat fragen! Also werden krude Einzelbeispiele herangezogen um die Werkzeuge der 'Alten' zu rechtfertigen. Irgendwelche Kundenmaschinen auf denen entwickelt und gebaut werden muss, die aber anscheinend nicht genug Leistung haben um darauf einen Desktop mit RDP Teamviewer XServer ... laufen zu lassen (womit man auch mit Eclipse super remote arbeiten kann). Das trifft, wenn überhaupt, wirklich nur einen verschwindend kleinen Teil der Entwickler. Startzeiten sind natürlich ein absurdes Argument. Ich starte meine IDEs genau einmal pro Woche, Montags während ich meinen Tee aufsetze. Und mein Arbeitgeber stellt mir auch Entwicklungsmaschinen zur Verfügung auf denen ich arbeiten kann, ohne die Größe der IDEs zu spüren. Eine Größe die übrigens nicht aus dem nichts kommt, sondern aus durch die vielen kleinen und großen Helfer entsteht die im Hintergrund die Arbeit erleichtern. Wenn natürlich den belächelten Jungen Kollegen nur mal kurz herablassend über die Schulter schaut, wird man natürlich diese Vorteile nicht erkennen wollen. Wenn hier dann noch jemand erzählt er würde dateiübergreifendes Refactoring mit Suchen / Ersetzten machen, erklärt mir das auch warum viele 'Alte' die ich kenne überhaupt kein Refactoring machen. Man lernt halt auswendig, dass die globale Variable 'c' die Datenbankverbindung enthält - man hat doch die Befehle von vi auch auswendig gelernt. Das zu ändern macht doch viel zu viel Arbeit - man müsste alle relevanten Dateien raussuchen, dort jedes passende 'c' finden und durch einen besseren Namen, gar eine vernünftige Kapselung ersetzen.
Sheeva P. schrieb: > Für mich wäre eine > integrierte Entwicklungsumgebung ein Rückschritt, schon deswegen, weil > ich neben C und C++, Java, Python und Bash-Code auch HTML, XML, JSON, > JavaScript, LaTeX, Markdown, SQL und CSV und noch ein paar andere Dinge > mit meinem Editor mache und weder Lust dazu habe Das kann jede ernstzunehmende IDE. Auszeichnungssprachen (die nun merheitlich in deiner Aufzählung vorhanden sind) darstellen und angenehm bearbeiten gehört zur GRUNDausstattung. Womit du recht hast ist, dass du mit deinem Toolset flexibler bist, ist halt ein Schweizer Taschenmesser, kann vieles, man kommt damit zum Ziel (auch in unwirtlichen Umgebungen), aber das wirklich Wahre, ... naja. Auf Arbeit bin ich unter Microsoft unterwegs mit .NET und bis vim/emacs auf das Produktivitätslevel hinkommt, welches ich mit Visual Studio + Resharper habe, hackt man erstmal 3 Jahre Plugins. Zuhause im Hobby Webentwicklung nutze ich Rubymine, weil es alles bietet was ich für Webentwicklung mit Ruby brauche. (Und Auszeichnungskram habe ich in beiden Domänen, ...) Klar ist es einfacher einmal das Schweizer Taschenmesser bedienen zu lernen und dann alles halbwegs gut oder weniger gut damit bearbeiten zu können, und ich spreche dir auch nicht ab, dass du damit super unterwegs sein wirst, aber ich tu mich nicht schwer für verschiedene Umgebungen das dafür zugeschnittene Tool zu erlernen und einzusetzen. Ist wohl die geistige Flexibilität der Jugend :P Außerdem bin ich nicht gezwungen (weder auf Arbeit noch Zuhause) remote über SSH entwickeln zu müssen, sondern auf ordentlichen Rechnern mit i7, ausreichend RAM und SSDs.
Mal abgesehen davon: Der konfigurierte Emacs mit seinen Plugins hat mit dem eigentlichen Threadthema (gdb) soviel zu tun wie Eclipse... Nämlich wenig. So ein Emacs stellt für sich ja auch schon eine IDE dar, auch wenn sich manche an dem Begriff "integriert" stören werden. Letzlich verstecken die Scripte/Plugins/Tools ja den gdb, so wie bei Eclipse auch. (Jaja, es gibt sicher einen Modus wo direkt gdb-Befehle gehackt werden können). Wir erinnern uns: das Thema war gdb, nicht vim/emacs vs Eclipse. Und jemanden der einen nackten gdb ohnr Toollandschaft benutzt gibts hier immer noch nicht, oder?
Scelumbro schrieb: > Dieser Streit ist doch wieder ein Generationenproblem. > Die 'Alten' sind mit vi, emacs und Co aufgewachsen und haben sich in > jahrelanger / jahrzehnterlanger Übung jedes Tastenkürzel eingeprägt. > Die 'Jungen' sind mit Klicki-Bunti aufgewachsen und können dort jedes > Menü und jedes Tastenkürzel. Ich mag keine IDEs und verwende gerne vi, nano und co. Musst du mich wirklich daran erinnern, wie alt ich mit 20 schon bin? Le X. schrieb: > Wir erinnern uns: das Thema war gdb, nicht vim/emacs vs Eclipse. > Und jemanden der einen nackten gdb ohnr Toollandschaft benutzt gibts > hier immer noch nicht, oder? Mich! Daniel A. schrieb: > und gdb zum Debuggen, immer auf der Konsole.
Daniel A. schrieb: >> Wir erinnern uns: das Thema war gdb, nicht vim/emacs vs Eclipse. >> Und jemanden der einen nackten gdb ohnr Toollandschaft benutzt gibts >> hier immer noch nicht, oder? > > Mich! Dito!
Daniel A. schrieb: > Mich! > > Daniel A. schrieb: >> und gdb zum Debuggen, immer auf der Konsole. Ah ok. Rein aus Interesse: wie machst du das mit dem breakpoint? Weißt du aus dem Gedächtnis dass du "break myFunnySourceFile:1234" machen musst? Oder öffnest du die Sourcen vorher in einem Editor deiner Wahl an und identifizierst interessante Stellen, wechselst dann zum gdb und debuggst die entsprechende Zeile?
Le X. schrieb: > Daniel A. schrieb: >> Mich! >> >> Daniel A. schrieb: >>> und gdb zum Debuggen, immer auf der Konsole. > > Ah ok. > Rein aus Interesse: wie machst du das mit dem breakpoint? > Weißt du aus dem Gedächtnis dass du "break myFunnySourceFile:1234" > machen musst? > Oder öffnest du die Sourcen vorher in einem Editor deiner Wahl an und > identifizierst interessante Stellen, wechselst dann zum gdb und debuggst > die entsprechende Zeile? Überraschung! GDB kann dir den Quellcode auch anzeigen. Normalerweise weiß man, wie die entsprechende Funktion heißt. Dann reicht ein
1 | list main |
Und man kann den Breakpoint an gewünschter Stelle setzten. Oder alternativ:
1 | b main |
Und zur gewünschten Stelle steppen. Kann es sein, dass manche Kritiker hier überhaupt keine Ahnung haben, wie man den GDB bedient? Zur Info: bin 22 Jahre alt und habe den GDB eine Weile genutzt, weil ich zu faul war, den arm-none-eabi-gdb in QtCreator zu integrieren. So viel zum Thema :P
Le X. schrieb: > Und jemanden der einen nackten gdb ohnr Toollandschaft benutzt gibts > hier immer noch nicht, oder? Auch, wenn ich überwiegend den Emacs im IDE-Modus benutze: um mal schnell was zu debuggen, benutzen ich den GDB auch „nackt“. Allein die Tatsache, dass diese Kombination mich seit dem Motorola 88000 kontinuierlich begleitet, und ich damit vom Debuggen der normalen Anwendungen (auf OS-Ebene) über FreeBSD-Kerneldebugging (mittels Remote-Verbindung auf zweitem Computer) bis hin zu diversen Controllern alles erledigen konnte, macht mir das viel effizienter, als wenn ich mich hätte für jede dieser Umgebungen in eine neue IDE einarbeiten müssen. Aber man muss das nicht als Dogma handhaben: wie ich schon schrieb, benutze ich für Qt meistens den qtcreator. Das liegt vor allem daran, dass ich in dieser Umgebung vergleichsweise selten zugange bin, mich daher wenig auskenne, sodass die Vorteile der Qt-Integration die Nachteile einer teils anderen Bedienung aufwiegen. Man muss aber zugeben, dass sie es ganz gut geschafft haben, das sinnvoll zu integrieren: copy&paste funktionieren beispielsweise X11-typisch, man muss also nicht jedesmal auf der Tastatur irgendwas mit Ctrl-C und Ctrl-V herumhacken. Ganz nebenbei wurde ja schon erwähnt, dass auch da einfach nur ein GDB untendrunter ist.
:
Bearbeitet durch Moderator
Krypto Cheffe schrieb: > Kann es sein, dass manche Kritiker hier überhaupt keine Ahnung haben, > wie man den GDB bedient? Ich bin kein Kritiker, für sowas wie Dogmen und Fanatismus hab ich keine Zeit. Aber mich interessiert wirklich, wie so ein Workflow aussieht. Ich weiß dass gdb Sourcen listen kann, ich hab das auch schon mal gemacht. Trotzdem kann ich mir nicht vorstellen dass das effektiver als ein Doppelklick auf den Quellcode ist. Deswegen frag ich nach. Auch ein graphischer Verzeichnisbaum wo man auf/zuklappen kann ist zum Navigieren schon sehr mächtig, vor allem in unbekannten Strukturen. Am liebsten wär mir ja mal ein Screenshot wie bei Daniel A. so eine Debugsession aussieht, welche Fenster/Konsolen er geöffnet hat. Wenn ich mehrere Konsolen offen habe wird das früher oder später immer ein Kuddelmuddel. Das würd mich echt freuen. Krypto Cheffe schrieb: > Überraschung Spar dir das, das ist wenig Produktiv. Ich geh da recht neutral und schmerzfrei an die Sache ran.
Le X. schrieb: > Am liebsten wär mir ja mal ein Screenshot wie bei Daniel A. so eine > Debugsession aussieht, welche Fenster/Konsolen er geöffnet hat. > Wenn ich mehrere Konsolen offen habe wird das früher oder später immer > ein Kuddelmuddel. > Das würd mich echt freuen. https://www.twitch.tv/directory/game/Creative/programming Vielleicht findest du dort jemanden der so einen Workflow hat.
Bernd K. schrieb: [...] > Und für das andere (entwickeln über ssh) fällt mir grad hat echt kein > use case ein. Echt nicht. Und genau das ist dein Problem. Du gehst von deiner Arbeitssituation (Entwicklung von Code bei dir) als einzig möglichem Modell aus und kannst deshalb nicht nachvollziehen, welche Anforderungen Leute haben, die z.B. remote auf Kundensystemen entwickeln (müssen). Ja, solche Szenarien gibt es auch, wenn man nicht als Verkäufer einer Lösung auftritt, sondern eben als Dienstleister, der im Auftrag des Kunden an und auf dessen Systemen arbeitet. Solange dir bewußt ist, daß du nur einen Teil der real existierenden Szenarien kennst und deshalb auch nur diesen Teil beurteilen kannst, und akzeptierst, daß andere Leute über andere Szenarien evtl. deutlich mehr wissen als du, ist das auch OK.
Sheeva P. schrieb: > Du meinst, man muß dazu die entsprechenden Shortcuts lernen? Also genau > so, wie ich die Befehle des gdb gelernt habe? Welchen Vorteil soll denn > die grafische Benutzeroberfläche denn dann noch haben? GUIs haben im Normalfall AUCH Tastenkürzel. Jedesmal, wenn man über das Menü eine Funktion aufruft, liest man nebenbei auch, mit welcher Tastenkombination das gegangen wäre. Für die häufig gebrauchten Sachen prägt man sich das dann ein und ist genauso schnell wie die nicht-GUI-Fraktion, weil es in beiden Fällen Tastenkombinationen sind. Für die weniger oft gebrauchten Sachen liest man sich aber nicht erst durch zwei Megabyte schlecht strukturierter manpages durch, sondern hat die über das Menü logisch angeordnet. OK, man KANN sie im Menü auch idiotisch anordnen, aber niemand bestreitet, daß man auch schlechte GUIs machen kann. Microsoft hat da ein besonders "glückliches" Händchen. GUI allein macht halt noch keine Usability. An Editoren werfe ich übrigens mal meinen Lieblings-Editor Notepad++ in die Runde. :-) Die für mich wichtigen Funktionen sind Syntaxhighlight, Suchen oder Suchen/Ersetzen auch in einem ganzen Verzeichnis mitsamt Unterverzeichnissen (wahlweise mit Dateimaskenfilter). Das ist bei fremdem Sourcetext ein Segen, speziell wenn er nicht so gut strukturiert ist. Wenn ich auf ein Wort doppelklicke, werden auch alle weiteren Treffer im Dokument hervorgehoben (wo kommt diese Variable noch gleich vor?). Wenn ich mit dem Cursor auf eine Klammer gehe (egal, ob rund, eckig oder geschweift), wird die zugehörige Endklammer hervorgehoben, und bei {}-Blöcken links eine rote vertikale Linie bis zum Blockende angezeigt. Ach ja, Tabs kann ich durch eine auswählbare Zahl von Leerzeichen automatisch ersetzen lassen, auch das nutze ich sehr gerne. Die Einrückung macht er bei einem Blockanfang auch gleich automatisch. Ich kann auch mehrere Zeilen selektieren und dann mit TAB bzw. SHIFT-TAB die Einrückung erhöhen oder verringern. Manchmal möchte ich auch zwischen automatischem Zeilenumbruch (in der Anzeige) und kein Zeilenumbruch wechseln. Zeitgesteuertes Autosave ist auch mit an Bord, das hat mir bei Stromausfall schon manche Kopfschmerzen erspart. Was ich absolut nicht abkann, ist Autovervollständigung, das irritiert mich einfach. Ist mit das Erste, was ich abgeschaltet habe. Und automatisch schließende Klammern setzen mag ich auch nicht. Einziger Kritikpunkt - Blöcke mit #if/#ifdef werden nicht automatisch ausgegraut, wenn das #if/#ifdef nicht gesetzt ist. Außerdem könnte gerne noch ein source code beautifier drin sein.
Ich benutze Eclipse seit 15 Jahren, angefangen mit Java, dann VHDL, jetzt C++. Zwischendurch habe ich mal einen Ausflug zu Vim gemacht und wollte es ernsthaft als IDE einsetzen. Bin davon aber wieder abgekommen und zu Eclipse zurückgekehrt. Ich benutze Vim zwar täglich im Job, aber ausschließlich um Config-Dateien zu editieren. Da ich im embedded-Bereich arbeite ist es schon toll, wenn man auf dem Controller ein Vim laufen hat. Als IDE würde ich vim aber nicht verwenden wollen, da ist Eclipse für mich (!) einfach um Längen komfortabler und produktiver. Allein den Befehls- und Editiermodus finde ich in Vim lästig und die Buchstaben für die Befehle finde ich teilweise willkürlich definiert. Alle Befehle müssen dort über die Buchstaben erfolgen, selbst die Pfeiltasten sind ja unter Vim verpönt. Da arbeite ich lieber mit meinem Eclipse, kann fast alles mit den Tasten Strg, Alt, Shift und Pfeiltasten erledigen. Gerne benutze ich auch Strg+D um die aktuelle Zeile zu löschen. Für all die Sachen braucht man nur eine Hand. Gerne benutze ich auch die schnelle Suche nach Dateien im gesamten Workspace mittels Shift+Ctrl+R.
:
Bearbeitet durch User
Le X. schrieb: > Am liebsten wär mir ja mal ein Screenshot wie bei Daniel A. so eine > Debugsession aussieht, welche Fenster/Konsolen er geöffnet hat. Ich Arbeit meistens unter Linux mit 4 Virtuellen Desktops, und manchmal noch mit ein paar virtuelle Konsolen. Bei den virtuellen Konsolen nutze ich gerne noch fbterm, um die Schriftart & Grösse anzupassen und ein Hintergrundbild zu setzen. Wenn ich über SSH auf anderen Servern arbeite, nutze ich häufig screen, und verbinde mich später von Zuhause, von der Arbeit und manchmal sogar vom Smartphone aus, jenachdem was ich darauf mache. Bei den Virtuellen Desktops habe ich meistens zuerst ein Browser oder Terminal, dann ein Terminal, danach den Kate oder Emacs oder ein Terminal mit nano oder vi editor, und dann noch ein Terminal. Immer jeweils Fullscreen, ein Fenster pro Desktop, ausser wenn ich mal 2 Terminals nebeneinander habe. Das Mailprogramm lasse ich minimiert laufen, gibt ja Notifications wenn eine Mail kommt. Egal auf welchem Desktop ich bin, ich bin immer nur einen Tastendruck von den Terminals entfernt. Meistens mache ich Dinge wie umbenennen von Dateien, sowie das Commiten von änderungen mit git oder svn im zweiten terminal. Debugging und beobachten von Logfiles im ersten terminal. Ich habe also quasi den Editor vor mir, wechsle nach Rechts um Dinge zu Commiten, tests durchlaufen zu lassen usw. und wechsle vom Editor aus nach Rechts um das Projekt zu builden, zu debuggen, logfiles zu beobachten, etc. Ein bisschen Chaotisch wird es nur, wenn ich mich auf mehrere meiner >10 LXC Container einlogge, bei denen habe ich zwar für den Namen am Anfang andere Schriftfarben gesetzt, aber das falsche Terminal hat man trotzdem schnell erwischt. Sobald ich ein Fenster nicht mehr brauche schliesse ich es, und sollte ich es doch wieder brauchen starte ich das Programm einfach neu. Das ist im moment mein Arbeitsablauf. Allerdings habe ich Zuhause einen Server herumstehen, mit 64GB Ram und <1% Prozessorauslastung. Eventuell verlagere ich meinen Desktop mal auf VMs oder LXC Container auf dem Server, damit ich bei den PCs, TVs, etc. einfach zwischen den Desktops umschalten kann, btw. diese als Bildschirme zu den VMs hinzufügen... Das müsste mit DLNA für die TVs, einer Funktastatur und einer PXE Boot, BusyBox und VNC Viewer Kombination für die PCs machbar sein... Aber das sind momentan noch Zukunftsträume.
Gustavo F. schrieb: > Ich benutze Eclipse seit 15 Jahren Du hast jetzt nur eins vergessen: was hat das mit GDB zu tun? ;-)
Bernd K. schrieb: > Und für das andere (entwickeln über ssh) fällt mir grad hat echt kein > use case ein. Nur weil Dir kein Anwendungsfall einfällt -- wobei ich mir nicht ganz sicher bin, ob Du Dir wirklich Mühe gegeben hast -- heißt das ja noch nicht, daß es keinen gibt. Im meinem Umfeld gibt es eine Vielzahl von Fällen, wo erst mal ein paar dutzend oder hundert Gigabyte in den Arbeitsspeicher geladen, ein paar zehntausend dicke SQL-Queries ausgeführt, ein paar Millionen komplexe Operationen ausgeführt werden müssen, bevor ich mit dem Debugging anfangen kann. Dabei geht es oft um Profiling- und Performancethemen, um Locking und Congestion, bei denen auf meinem Desktop alles sauber funktioniert und erst unter realen Volllast-Bedingungen etwas passiert. > Über ssh mach ich höchstens irgendwelche Konfigurationsarbeit. Genau: Du. Du bist aber leider nicht der exklusive Inhaber des einzig wahren Entwicklungsanwendungsfalls der Welt, sorry.
Auch Eclipse unterstützt tatsächlich auch Remote Debugging /Development - auch über SSH. Dank der richtigen Plugins braucht man auch dann nicht auf seine IDE verzichten, wenn die Ziel nur über SSH erreichbar ist.
Über so ein schmalbandiges Benutzerinterface zu arbeiten und den Überblick über riesige komplexe Strukturen zu erlangen und zu behalten ist ein bisschen wie Blindschach. Es geht durchaus wenn man lange genug übt, es trainiert auch die grauen Zellen und es ist zweifellos eine sportliche Herausforderung, und das Streben nach der Meisterschaft in dieser Disziplin ist vielleicht auch Futter für die Eitelkeit, aber die Chancen gegen einen starken Gegner der mit allen unerlaubten Mitteln und harten Bandagen kämpft (das Problem und die Deadline) zu gewinnen erhöht so eine selbstauferlegte Einschränkung garantiert nicht.
Bernd K. schrieb: > eine selbstauferlegte Einschränkung Du hast einfach nur eins nicht verstanden: das ist keine freiwillige Wahl desjenigen, der das tut, sondern es gibt einfach Umgebungen, in denen geht's nur so. Dass du bislang noch nicht in so einer arbeiten musstest, ist das eine, dass du jegliche derartige Fälle als „selbstausgesuchtes Schicksal“ deklarierst, ist einfach nur arrogant.
Sheeva P. schrieb: > Dabei geht es oft um > Profiling- und Performancethemen, um Locking und Congestion, bei denen > auf meinem Desktop alles sauber funktioniert und erst unter realen > Volllast-Bedingungen etwas passiert. Und dann installierst Du die ganze Buildumgebung samt aller Abhängigkeiten und Emacs oder Vim mit 42 Plugins auf der Produktionsmaschine und kopierst alle Deine Quellen dorthin und entwickelst dann dort weiter?
Scelumbro schrieb: > Dieser Streit ist doch wieder ein Generationenproblem. Du machst Dir die Sache zu einfach. > Die 'Alten' haben jetzt natürlich jahrelang auf die 'Jungen' mehr oder > weniger gnädig herabgelächelt. Da kann ich nur für mich sprechen: ich lächele auf niemanden herab, schon gar nicht gnädig, und wüßte auch keinen Grund dazu, das zu tun. > Zuzugeben, dass die modernen IDEs > irgendetwas besser können als die altbewährte Toolchain, gar zuzugeben, > dass die neuen IDEs in der Summe produktiver sind, würde dann eine > massive kognitive Dissonanz auslösen. De facto gibt es bei uns im Unternehmen sowohl Entwickler, die auf IDEs schwören, als auch andere, die desintegrierte Entwicklungsumgebungen (DDEs) bevorzugen, unabhängig von Alter, Geschlecht, Religion, Haar- und Augenfarbe. Wenn es dabei einen nennenswerten Produktivitätsunterschied gäbe, hätten wir längst einen Standard festgelegt. Es gibt aber keinen. De facto bieten IDEs, anders als ihre Verfechter uns hier weismachen wollen, keine höhere Produktivität, meist liegen die Nutzer von DDEs um maximal drei Prozent vorne. Dieser minimale Unterschied, der zudem einer gewissen Meßunsicherheit unterliegt, stellt für uns keinen ausreichenden Grund dar, irgendjemanden zu veranlassen, seine gewohnte Arbeitsumgebung aufzugeben und ihn stattdessen in eine neue einzuarbeiten. Die Unterschiede sind so gering, daß sich eine Umstellung schlicht nicht lohnt. Diese Angaben und Schlußfolgerungen gelten natürlich nur für unsere recht speziellen Anwendungsfälle. Letztlich bleiben die IDE-Freunde den Beweis für ihre Behauptung einer höheren Produktivität schuldig, und nein, der Beweis läßt sich sicher nicht über die Aufzählungen von tollen Features der einen oder anderen Umgebungsfamilie führen. Insofern schlage ich vor, daß die IDE-Freunde ihre letztendlich lächerlichen Missionierungsversuche unterlassen und sich damit abfinden, daß DDEs nicht weniger produktiv und auch nicht weniger professionell, sondern nur anders sind als IDEs. Danke.
Le X. schrieb: > Und jemanden der einen nackten gdb ohnr Toollandschaft benutzt gibts > hier immer noch nicht, oder? Ich benutze regelmäßig einen splitterfasernackten GDB, aber natürlich mit einer ziemlich umfangreichen Landschaft an Werkzeugen.
Le X. schrieb: > Aber mich interessiert wirklich, wie so ein Workflow aussieht. > Ich weiß dass gdb Sourcen listen kann, ich hab das auch schon mal > gemacht. > [...] > Auch ein graphischer Verzeichnisbaum wo man auf/zuklappen kann ist zum > Navigieren schon sehr mächtig, vor allem in unbekannten Strukturen. Ja, natürlich. Aber es ist ja nicht so, als ob wir keinen Verzeichnisbaum hätten. Richtig ist, daß er von einem anderen Werkzeug dargestellt wird -- das, je nach Präferenz, wahlweise ein grafisches, oder natürlich auch ein Kommandozeilenwerkzeug sein kann. Wir sind da einfach flexibel und können sogar mehrere Werkzeuge gleichzeitig benutzen, von klassischen UNIX-Tools wie find(1), grep(1), ls(1) und Co., über pseudo-grafische Werkzeuge wie tree(1) und mc(1) bis hin zu den üblichen GUI-Tools.
Nop schrieb: > GUIs haben im Normalfall AUCH Tastenkürzel. Jedesmal, wenn man über das > Menü eine Funktion aufruft, liest man nebenbei auch, mit welcher > Tastenkombination das gegangen wäre. Für die häufig gebrauchten Sachen > prägt man sich das dann ein und ist genauso schnell wie die > nicht-GUI-Fraktion, weil es in beiden Fällen Tastenkombinationen sind. Du wirst lachen, aber ich habe schon ein paar GUIs gesehen und sogar schon einige entwickelt. Aber Deine Ausführungen gehen leider an der vorherigen Argumentationskette vorbei. Diese zielte nämlich zuerst darauf ab, daß IDEs wegen der Menüs schneller erlernbar seien und darum einen Produktivitätsvorteil hätten. Auf meinen Hinweis, daß ich meine Editorbefehle schneller eingebe als IDE-Nutzer zur Maus greifen und sich durch ihre Menüstrukturen klicken kann und ich mit meinen Editorbefehlen deswegen einen dauerhaften Produktivitätsvorteil hätte, wurde mir geantwortet, daß es ja schließlich Shortcuts gäbe. Das wiederum hat mich zu der Rückfrage inspiriert, ob man diese nicht lernen muß und damit der vorher angepriesene Vorteil einer höheren Produktivität durch geringere Lernaufwände zunichte gemacht wird. Kurz gesagt: ob man Menüs plus Shortcuts oder Editorbefehle lernt, ist bezüglich des Lernaufwandes, und damit auch bei der Produktivität, kein nenneswerter Unterschied. Wenn man nur die Menüs lernt, ist bereits der Griff zur Maus im Vergleich zur Befehlseingabe eine ziemlich ineffiziente Angelegenheit und macht mittelfristig den geringeren Lernaufwand zunichte. Oder, noch kürzer: wer sein Werkzeug dauerhaft effizient beherrschen will, muß es erlernen, und das gilt für alle Werkzeuge. > Für die weniger oft gebrauchten Sachen liest man sich aber nicht erst > durch zwei Megabyte schlecht strukturierter manpages durch, sondern hat > die über das Menü logisch angeordnet. Auch das ist zum Beispiel beim Emacs der Fall.
Le X. schrieb: > Und jemanden der einen nackten gdb ohnr Toollandschaft benutzt gibts > hier immer noch nicht, oder? Ich benutze den gdb sehr oft "nackt", da ich Software für Microcontroller schreibe. Es passiert z. B. häufig dass die Software auf dem Target mit einem SegFault abstürzt und ich dann den coredump mit gdb analysiere. Im gdb gebe ich dann einfach bt für backtrace ein und finde sofort die Stelle, welche den SegFault verursacht hat. Achja: Als IDE verwende ich ausschließlich Eclipse CDT unter Linux.
Bernd K. schrieb: > so eine selbstauferlegte Einschränkung garantiert nicht. Es ist erstens nicht selbst auferlegt, und zweitens keine Einschränkung. Das versuche ich Dir seit etlichen Beiträgen klarzumachen, vor allem daß es eben keine Einschränkung ist -- im Gegenteil ist es eine große Erweiterung meiner Möglichkeiten, für jede Aufgabe ein passendes Werkzeug entweder schon dabei zu haben, oder es aus den vorhandenen Werkzeugen zusammensetzen zu können.
Sheeva P. schrieb: > für jede Aufgabe ein passendes > Werkzeug entweder schon dabei zu haben, oder es aus den vorhandenen > Werkzeugen zusammensetzen zu können Das ist ja ein Teil der Linux-Philosophie. Obwohl ich Eclipse verwende, benutze ich auch häufig (ack-)grep, tree, wc, sed, find etc. Das eine muss ja das andere nicht ausschließen. ;-) Ich verstehe auch nicht, warum das jetzt für Vim sprechen sollte.
Mein Worklow sieht z. B. so aus, dass ich Eclipse für die Editierung verwende, aber das Kompilieren in einer Konsole auf meinem zweiten Bildschirm ausführe. Finde ich einfach übersichtlicher und man kann den Kompilierungsvorgang besser beeinflussen und ggf. Ausgaben filtern.
:
Bearbeitet durch User
Bernd K. schrieb: > Sheeva P. schrieb: >> Dabei geht es oft um >> Profiling- und Performancethemen, um Locking und Congestion, bei denen >> auf meinem Desktop alles sauber funktioniert und erst unter realen >> Volllast-Bedingungen etwas passiert. > > Und dann installierst Du die ganze Buildumgebung samt aller > Abhängigkeiten und Emacs oder Vim mit 42 Plugins auf der > Produktionsmaschine und kopierst alle Deine Quellen dorthin und > entwickelst dann dort weiter? Wer redet denn von Produktionsmaschinen? In einigen Fällen mache ich das allerdings wirklich so, wobei die Sache jedoch viel einfacher ist, als denkst. Meine Arbeitsumgebung, also mein Homedirectory inklusive Emacs-Konfiguration und -Plugins, wird auf alle unsere Systeme automatisch via Puppet und / oder Ansible verteilt. Die Buildumgebung befindet sich ohnehin im VCS, da kostet mich das also nur einen Checkout. In anderen Fällen entwickle ich die Software lokal, und deploye sie dann automatisiert auf die Zielmaschine.
Gustavo F. schrieb: > Sheeva P. schrieb: >> für jede Aufgabe ein passendes >> Werkzeug entweder schon dabei zu haben, oder es aus den vorhandenen >> Werkzeugen zusammensetzen zu können > > Das ist ja ein Teil der Linux-Philosophie. Naja, der UNIX-Philosophie, aber wir wollen nicht kleinlich sein. ;-) > Obwohl ich Eclipse verwende, > benutze ich auch häufig (ack-)grep, tree, wc, sed, find etc. Das eine > muss ja das andere nicht ausschließen. ;-) Ich verstehe auch nicht, > warum das jetzt für Vim sprechen sollte. Das spricht nicht für oder gegen vim, sondern für oder gegen Eclipse. Der wesentliche Produktivitätsvorteil, den die IDE-Freunde hier anführen, ist doch, daß sie nur ein Werkzeug haben und kennen müssen. Du hingegen kommst mir jetzt damit, daß Du neben Deiner IDE noch eine Reihe anderer Werkzeuge benutzt, was Dich letztlich vor noch größere Herausforderungen hinsichtlich des Lernaufwandes stellt und obendrein die Behauptung invalidiert, daß man außer einer IDE keine anderen Werkzeuge benötigen würde und erlernen müsse, und IDEs deswegen einen signifikanten Produktivitätsvorteil böten.
Sheeva P. schrieb: > Du > hingegen kommst mir jetzt damit, daß Du neben Deiner IDE noch eine Reihe > anderer Werkzeuge benutzt, was Dich letztlich vor noch größere > Herausforderungen hinsichtlich des Lernaufwandes stellt und obendrein > die Behauptung invalidiert, daß man außer einer IDE keine anderen > Werkzeuge benötigen würde und erlernen müsse, und IDEs deswegen einen > signifikanten Produktivitätsvorteil böten. Sorry, das siehst du aber zu verbissen. Das liest sich ja so, dass nur weil ich eine IDE verwende, ich keine Linux-Tools verwenden darf/kann. Wie gesagt: Ich arbeite gerne und viel auf der Konsole. Für mein Projekt, an dem ein halbes Dutzend Kollegen mit dran arbeitet und entsprechend viele LOC besitzt, finde ich Eclipse einfach produktiver. Und nochmal zum Geschwindigkeitsvorteil: Ich hatte vor drei Jahren Vim mit einer Reihe Standard-Plugins installiert, wo mir gesagt wurde, die bräuchte man um damit vernünftig C++ entwickeln zu können. Ergebnis war: Eclipse hat mit derselben Codebase schneller reagiert als Vim. Aber wahrscheinlich habe ich nur etwas falsch gemacht. ;-)
:
Bearbeitet durch User
Sheeva P. schrieb: > Diese zielte nämlich zuerst darauf ab, daß IDEs wegen der Menüs > schneller erlernbar seien und darum einen Produktivitätsvorteil hätten. Nein, denn das ist Bullshit. Ich behaupte der Produktivitätsvorteil ergibt sich aus den Funktionen die geboten werden, aber auch das ist von der gegebenen Aufgabenstellung abhängig, ob die dann notwendig sind. Vermutlich könnte ich mir 10 Aufgaben aus dem Finger saugen, die mit Vim+Co. nur bedingt Vergnügen bereiten, ebenso 10 Stück für die "Mausschubser". Verwendet ihr darüberhinaus irgendwelche Analyse-Tools (proprietäre?)? Statische Codeanalyse? Auch alles kommandozeilenorientiert? Also ich würde z.B. die Klocwork-Integration ins Studio nicht missen wollen, auch wenn das nur ein GUI-Wrapper für die Kommandozeilentools von Klocwork ist.
Sheeva P. schrieb: > und zweitens keine Einschränkung. Eine Einschränkung der Bandbreite an Informationen die das Benutzerinterface transportieren kann empfinden die meisten Leute als Einschränkung.
Sheeva P. schrieb: > Der wesentliche Produktivitätsvorteil, den die IDE-Freunde hier > anführen, ist doch, daß sie nur ein Werkzeug haben und kennen müssen. Nein, das hat hier noch keiner behauptet. Dieses angebliche gegnerische Argument hast Du Dir eben gerade in Echtzeit ausgedacht um es dann angreifen zu können. So eine Argumentation läuft aber ins Leere.
:
Bearbeitet durch User
Sheeva P. schrieb: > Auf meinen Hinweis, daß ich meine Editorbefehle schneller eingebe als > IDE-Nutzer zur Maus greifen und sich durch ihre Menüstrukturen klicken > kann Aber wehe Du hast mal einen Shortcut vergessen, dann musst Du ebenfalls zur Maus greifen und danach googlen oder Deinen Spickzettel öffnen und dort danach suchen. In der Zeit hab ich in einer Anwendung mit menübasierter Oberfläche den Befehl aus dem Menü geholt, angewendet UND mir den zugehörigen Shortcut gemerkt und noch obendrein anschließend einen Schluck Kaffee getrunken.
:
Bearbeitet durch User
Gustavo F. schrieb: > Sorry, das siehst du aber zu verbissen. Das liest sich ja so, dass nur > weil ich eine IDE verwende, ich keine Linux-Tools verwenden darf/kann. Äh, eigentlich bin ich da völlig unkompliziert. Natürlich darfst Du gerne alle Tools benutzen, die Du magst. Mach' ich ja auch. ;-) > Ergebnis war: Eclipse hat mit derselben Codebase schneller reagiert als > Vim. Das wundert mich zwar, aber da Du Dich ja ohnehin für Eclipse entschieden hast und offensichtlich gut damit (und den andern Tools) zurecht kommst, dürfte sich die Erforschung der genauen Ursachen wohl nicht lohnen. Davon abgesehen bin ich für vim ja eh der flashce Ansprechpartner.
D. I. schrieb: > Nein, denn das ist Bullshit. Ich behaupte der Produktivitätsvorteil > ergibt sich aus den Funktionen die geboten werden, aber auch das ist von > der gegebenen Aufgabenstellung abhängig, ob die dann notwendig sind. Dieselben Funktionen sind auch ohne IDE nutzbar. > Vermutlich könnte ich mir 10 Aufgaben aus dem Finger saugen, die mit > Vim+Co. nur bedingt Vergnügen bereiten, ebenso 10 Stück für die > "Mausschubser". Nenn' mich einen Träumer, aber die wichtigsten Schlüssel zur Steigerung der Entwicklerproduktivität sind die Auswahl und die Beherrschung der gewählten Sprache, das Wissen um die zu lösenden Aufgaben, und erst in allerletzter Linie die verwendeten Werkzeuge. > Verwendet ihr darüberhinaus irgendwelche Analyse-Tools (proprietäre?)? > Statische Codeanalyse? Auch alles kommandozeilenorientiert? Ja, sowas nutzen wir vornehmlich in CI und Testing, und deswegen sind die meisten davon tatsächlich kommandozeilenorientiert.
Bernd K. schrieb: > Eine Einschränkung der Bandbreite an Informationen die das > Benutzerinterface transportieren kann empfinden die meisten Leute als > Einschränkung. Nein, im Gegenteil: ich konzentriere mich gerne auf das Wesentliche, und das ist und bleiben zuerst mein Quellcode und dann die Ausgaben von Compiler, Programm, Debugger, und Profiler.
Bernd K. schrieb: > und noch obendrein anschließend einen Schluck Kaffee getrunken. Da haben wir es: der vermehrte Gebrauch von IDEs ist gesundheitsgefährdend! ;) Zum Glück kann ich bei meinem emacs bleiben.
Bernd K. schrieb: > Aber wehe Du hast mal einen Shortcut vergessen, dann musst Du ebenfalls > zur Maus greifen und danach googlen oder Deinen Spickzettel öffnen und > dort danach suchen. In der Zeit hab ich in einer Anwendung mit > menübasierter Oberfläche den Befehl aus dem Menü geholt, angewendet UND > mir den zugehörigen Shortcut gemerkt Das ist absoluter Unsinn, mit den richtigen Einstellungen braucht man weder die Maus noch Google oder Spickzettel. Helm schlägt dir die passenden Funktionen wesentlich besser vor als irgendwelche unlogischen GUI-Menüs, die Dokumentation zu jeder Funktion ist wesentlich besser (oder überhaupt vorhanden) verglichen mit Eclipse. Schau dir mal Spacemacs an, da findest du recht schnell und einfach heraus, was alles geht, wie einfach es ist, und was dein Eclipse alles nicht kann. GUIs lohnen sich bis zu einem gewissen Grad an Professionalität sicherlich, aber ab einem bestimmten Punkt lohnt die höhere Einstiegshürde als Investition in die Zukunft allemal. Wenn es aber nicht sein tägliches Brot ist, in der IDE/dem Editor zu hängen, zahlt sich diese letztendlich nicht aus.
Bernd K. schrieb: > Sheeva P. schrieb: >> Der wesentliche Produktivitätsvorteil, den die IDE-Freunde hier >> anführen, ist doch, daß sie nur ein Werkzeug haben und kennen müssen. > > Nein, das hat hier noch keiner behauptet. Dieses angebliche gegnerische > Argument hast Du Dir eben gerade in Echtzeit ausgedacht Vielleicht solltest Du den Thread und nicht zuletzt auch Deine eigenen Beiträge darin noch einmal lesen. Am 7.12. um 18:53 Uhr hast Du eine (mehr oder weniger beeindruckende) Liste von Funktionen gepostet, die nach Deiner Ansicht bei einer IDE unerläßlich seien, und behauptet, daß Dein Liebling wegen der Integration dieser Funktionen "absolut alternativlos" sei, wenn man etwas Größeres als "ein Hello-World Projekt unter der Fuchtel hat und sich halbwegs schnell und zielsicher in riesigen Codemengen bewegen und dort in absehbarer Zeit was bewirken will". Wer also nicht mit Deinem Lieblingswerkzeug arbeitet, kann nicht produktiv sein, weil nur Dein Lieblingsspielzeug alle der von Dir genannten Funktionen integriert, und eine Integration all dieser Funktionen für eine produktive Entwicklungsarbeit unerläßlich ("alternativlos") sei. Oder, verkürzt: wer eine andere Entwicklungsumgebung benutzt als Du, insbesondere eine nicht integrierte, kann nur unproduktiv sein. Das von mir oben Geschriebene ist lediglich der Umkehrschluß zu Deinen herablassenden Ausführungen. Kannst Du Deinen Kreuzzug gegen Andersdenkende und -arbeitende jetzt bitte beenden und wieder der vernünftige, kluge und erfahrene Bernd werden, als den ich Dich in Erinnerung hatte? Danke.
Scelumbro schrieb: > Dieser Streit ist doch wieder ein Generationenproblem. > Die 'Alten' sind mit vi, emacs und Co aufgewachsen und haben sich in > jahrelanger / jahrzehnterlanger Übung jedes Tastenkürzel eingeprägt. > Die 'Jungen' sind mit Klicki-Bunti aufgewachsen und können dort jedes > Menü und jedes Tastenkürzel. Es gibt genug "Alte" die sowohl emacs/vi als auch reine GUI Tools benutzen. Und es gibt auch genug "Junge" die das genauso machen. Man kann sich vermeintliche "Generationenprobleme" auch zusammendichten^^ /regards
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.