Entwicklungsgeschwindigkeit mit verschiedenen Sprachen



  • Ist die Programmiersprache dann nicht besser für die Aufgabe, wenn man mit weniger Tools die gleiche Geschwindigkeit erreicht?

    In deinem Beispiel dürfte ein Python, Ruby, Scheme, Lisp, Perl, APL etc. Programmierer mit einem einfachen Texteditor schneller sein, als jemand mit einer wer weiß wie großen IDE, Refactoringtools, Sourcecodeverwaltung, UML-Planungstool, J2EE-Libraries und pipapo.



  • Shade Of Mine schrieb:

    und hört bitte auf mit vergleichen wo jemand zu dumm zum atmen ist. weil wenn jemand einfach ein kompletter total ausfall ist, dann ist eh alles egal dann muss man den nur schnell zur konkurrenz schicken alles andere ist nicht tragbar.

    Ich vermute mal, zumindest zum Teil, war es auch auf meinen Post bezogen.
    Das Beispiel sollte lediglich aussagen nicht alles ist so einfach wie es scheint. Und mit "zu dumm" hat das wenig zu tun.
    Ich denke jeder hatte schon mal beim Programmieren oder im Alltag ein Erlebnis, bei dem er sich hinterher gefragt hat, warum man da überhaupt etwas auf diese Art gemacht hat; später ist einem dann klar es war total dumm.

    Und mit Sicherheit wird es Situationen bzw. Leute geben die mit Assembler schneller, effektiver arbeiten als mit einer Hochsprache.
    Es kommt drauf an *wer* *was* macht.
    Vielleicht sagen wir beide das gleiche. Ich hatte nur in deinen Posts rausgelesen, dass ein bestimmtes Tool generell schlecht sei. Und das es im großen und ganzen fast nur auf die Tools ankommt.
    Es gibt Leute die Programmieren schon seit Jahrzehnten prozedual. Die tun sich, nicht alle, aber viele, schwer mit der "Objekt-Welt". Nicht nur mit einer Programmiersprache, sondern auch mit entsprechenden neuen Tools.



  • rüdiger schrieb:

    Ist die Programmiersprache dann nicht besser für die Aufgabe, wenn man mit weniger Tools die gleiche Geschwindigkeit erreicht?

    eine sprache ist nur ein tool von vielen. die komplette tool kette muss passen.

    c++ ist für eine server anwendung sicher erstmal gut geeignet, aber wenn mir auf der plattform zB ein debugger fehlt, dann ist man uU mit einer sprache die schlechter geeignet ist besser bedient, wenn diese eben zB gute debugger anbietet.

    deshalb: eine sprache ist nur ein tool von vielen.

    objective-c ist zB eine super idee wenn man eine anwendung unter mac os x entwickeln will - gutes cocoa bindung, viele resouren. wenn ich die anwendung aber unter windows entwickeln will ist .net uU besser geeignet. wobei .net vielleicht bei cross plattform systemen (mit mono) vermutlich wieder schlechter abschneidet.

    deshalb: die sprache ist nicht alles. c# ist super unter windows, für linux anwendungen aber nicht unbedingt geeignet. das alleine zeigt schon, dass sprachen nicht das non plus ultra entscheidungskriterium ist - man muss alle verfügbaren tools bedenken.

    die filemaker script sprache ist zB furchtbar. aber dennoch ist filemaker für viele situationen einfach die richtige wahl - eben weil die toolchain einen bestimmten bereich super abdeckt.

    deshalb nochmal:
    eine sprache ist ein tool.

    und es kommt auf die tools an wenn man annimmt dass die programmierer etwa gleichwertig sind.

    oder mal ehrlich:
    wird irgendjemand auf die idee kommen eine csv datei in eine sql datenbank per assembler und notepad zu integrieren oder werden wir lieber 5 zeilen ruby/python/php/... schreiben?



  • rüdiger schrieb:

    In deinem Beispiel dürfte ein Python, Ruby, Scheme, Lisp, Perl, APL etc. Programmierer mit einem einfachen Texteditor schneller sein, als [...].

    Dennoch wäre dein erstes Team produktiver würden Sie statt komplett nur mit z.B. nano oder Vergleichbarem doch vielleicht mit einem geeigneterem Editor, einem Versionskontrollsystem etc. arbeiten. Falls ich das Richtig gelesen habe hat Shade nur gesagt, das alle Tools sinnvoll gewählt werden sollten, nicht nur eines der verwendeten (die Sprache).



  • ihoernchen schrieb:

    Das Wichtige ist die Kombination. Der Programmierer muss seine Tools kennen. Man kann nicht sagen Tool (Programmiersprache) A ist besser/schneller als B.
    Da kann jemand ein komplexes Problem mit Assembler + Notepad vielleicht besser lösen, als jemand der Tools benutzt die er nicht oder kaum kennt.
    Ein Tool kann auch nur so gut sein wie derjenige der es benutzt.

    Erinnert mich an VI, bei dem man erst 5 min das Handbuch durchlesen muss, nur um VI beenden zu koennen.

    Aber hier ist wirlich eine eigenartige Diskussion. Wenn ich ein Bild aufhaengen will, dann nehme ich einen Hammer und einen Nagel. Wenn es eine Betonwand ist, ist der Hammer und Nagel aber sinnlos, hier sind Bohrer, Duebel und Schraube gefragt.

    Wieso also die Diskussion ob man mit passenden Werkzeugen eine Aufgabe schneller erledigen kann als ohne?

    Klar kann man in Assebler alles Programmieren was eine moderne Sprache wie C++, Java, Python, Ruby, etc. ausmacht. Aber in der Zeit in der du in Assebler Verberung, Polymorphie, usw. hinschreibst, habe ich inzwischen das Projekt abgeschlossen. Und wieso sollten diese 08/15 Dinge nicht vom Computer selbst uebernommen werden?

    Deswegen haben wir doch Computer erfunden, sie sollen uns 08/15 Dinge abnehmen, damit wir an den richtigen Problemen arbeiten koennen. Somit abstrahieren wir immer weiter, bis die Informationsdichte in einer Codezeile maximal ist. Mit einer Maximierung der Informationsdichte pro Codezeile erreichen wir nunmal schnellere Entwicklungszeit und weniger Fehler.

    Dabei unterstuetzt uns eine IDE noch weiter als die Sprache. Die IDE automatisiert das erstellen der Codezeile, warnt vor Fehlern, macht den Code noch mehr leserlich und ueberprueft den Code.

    Mit einer IDE minimierst du den Aufwand eine Codezeile hinzuschreiben und du minimierst weiter die Fehleranfaelligkeit. Dies fuehrt zu einer weiteren Reduzierung der Entwicklungszeit und der Fehler im Projekt.



  • DEvent schrieb:

    Erinnert mich an VI, bei dem man erst 5 min das Handbuch durchlesen muss, nur um VI beenden zu koennen.

    mag sein, aber wenn man sich am vi Editor gewöhnt hat, dann ist es praktisch nicht mehr wwegzudenken. Vi und ihre Nachfolger sind nie mit der Idee entwickelt worden, dass man sofort von 0 auf 100 mit dem Editor arbeiten kann, sondern ein Werzeug zu erstellen, welches viele mächtige Features besitzt, die einem das Leben erleichten können.

    DEvent schrieb:

    Klar kann man in Assebler alles Programmieren was eine moderne Sprache wie C++, Java, Python, Ruby, etc. ausmacht. Aber in der Zeit in der du in Assebler Verberung, Polymorphie, usw. hinschreibst, habe ich inzwischen das Projekt abgeschlossen. Und wieso sollten diese 08/15 Dinge nicht vom Computer selbst uebernommen werden?

    In einem Punkt muss ich euch klar Regen: die Sprache ist nur ein Tool und die gesamte Kette muss stimmen.

    Ich finde die Frage falsch gestellt. Es gibt so viele Arten von Programmieraufgaben und "08/15" Software ist nicht das einzige was es gibt auf der Welt. Ich arbeite schon über 1 1/2 Jahre als Entwickler und hab bis jetzt noch nie eine GUI geschrieben geschweige dann eine schreibe müssen. Für meine Arbeit reichen mir im wesentlichen 3 Dinge: vim, valgrind und eine Konsole wo ich meine Bibliotheken testen kann. Hab einmal versucht meine Sachen mit IDEs wie Ajunta und KDevelop zu entwickeln, es hat mir aber nie einen Vorteil gebracht. Und ich schätze mich als ein Entwickler, der relativ schnell ist. Noch nie mussten Projekte "meinetwegen" verschoeben werden oder so.

    Zurück zur ursprünglichen Frage: ich denke, es hat a priori mehr mit dem Programmier zu tun. Wer nur halbherzig arbeitet (selbst mit der für das Projekt besten Toolkette), wird ewig brauchen, um etwas vernünftiges zu schreiben.



  • DEvent schrieb:

    Mit einer Maximierung der Informationsdichte pro Codezeile erreichen wir nunmal schnellere Entwicklungszeit und weniger Fehler.

    Hast du dir das selber ausgedacht oder gibts dafür (wissenschaftliche) Quellen?



  • Es gibt so viele Totschlagargumente, die für eine IDE sprechen:

    - Code Assist / Code Generierung
    - on the fly Compiler
    - Refactoring
    - umfangreiche Suchfunktionen
    - Integration der wichtigsten Tools (Debugger, Versionskontrolle, Profiler, Unittest-Tools, Servertools, DB-Tools, XML-Tools, GUI-Builder, ...)

    KA wie man freiwillig darauf verzichten kann. 😕 Aber ist vielleicht auch abhängig vom Projekt. Wenn man nur ne Handvoll Dateien zu bearbeiten hat, wo man primär Algorithmen implementiert, dann reicht bestimmt auch ein Editor + Debugger.
    Im meinem derzeitigen Projekt (ca. 5000 Klassen) würde ich alleine schon ohne die umfangreichen Suchfunktionen einer IDE ewig brauchen, um mich zurecht zu finden. 🤡



  • supertux schrieb:

    mag sein, aber wenn man sich am vi Editor gewöhnt hat, dann ist es praktisch nicht mehr wwegzudenken. Vi und ihre Nachfolger sind nie mit der Idee entwickelt worden, dass man sofort von 0 auf 100 mit dem Editor arbeiten kann, sondern ein Werzeug zu erstellen, welches viele mächtige Features besitzt, die einem das Leben erleichten können.

    Was für mächtige Features hat vi denn?

    supertux schrieb:

    Hab einmal versucht meine Sachen mit IDEs wie Ajunta und KDevelop zu entwickeln, es hat mir aber nie einen Vorteil gebracht. Und ich schätze mich als ein Entwickler, der relativ schnell ist. Noch nie mussten Projekte "meinetwegen" verschoeben werden oder so.

    Ich finde KDevelop ist auch nicht wirklich brauchbar. Man kann von einer schlechten IDE nicht gleich auf alle IDEs schließen. Ajunta hab ich nie benutzt.
    Aber hier trifft im Prinzip auch das zu was du oben gesagt hast. Du wirst mit einer IDE auch nicht sofort von 0 auf 100 viel produktiver sein. Als ich das erste mal Eclipse benutzt habe, habe ich mich auch sehr schwer damit getan und war sogar langsamer wie wenn ich einen normalen Text-Editor benutzt hätte. Mittlerweile will ich die ganzen Features aber nicht mehr missen.



  • supertux schrieb:

    Für meine Arbeit reichen mir im wesentlichen 3 Dinge: vim, valgrind und eine Konsole wo ich meine Bibliotheken testen kann.

    solche abwechslungsarmen jobs gibts noch?
    ich wäre ausserdem sehr verzweifelt, wenn ich vim benutzen "müsste". letzens war ich etwas unter linux unterwegs und da hab ich meinen geliebten nedit genommen.

    supertux schrieb:

    Hab einmal versucht meine Sachen mit IDEs wie Ajunta und KDevelop zu entwickeln, es hat mir aber nie einen Vorteil gebracht.

    ich hab' anjuta mal ausprobiert. in meinem speziellen fall hats zwar nichts gebracht, aber es machte 'nen guten eindruck. wenn ich auf ner unix-box usermode-programme bauen würde, dann würde ich anjuta nehmen. ist schon praktisch, wenn man einfach auf einen 'run' butten klicken kann, als hintereinander die schritte speichern,make,./a.out aufrufen von hand machen muss. ausserdem nimmt einem 'ne IDE das erstellen von makefiles ab und mann kann beim debuggen durch den code steppen, usw. vieles wird automatisiert. das finde ich gut.
    🙂



  • nep schrieb:

    Was für mächtige Features hat vi denn?

    schon einige, die werde ich hier nicht beschreiben. Dafür gibt es etliche Websiten (Google hilft) und auch gute ViM Bücher. Was mir persönlich von vim gefällt sind z.b. solche Sachen wie

    • mehrere Dateien gleichzeitig editieren, kann sie nebeneinander, aufeinander, versteck, usw. halten und ein einfaches Ctrl+W+Pfeiltaste reicht, um die Fenster zu wechseln
    • ctags: mit Alt+] kann ich zwischen Funktionen springen
    • Visual Modus kann schon sehr schick sein
    • mehrere Buffer fürs copy&paste
    • Suche/Ersetzung mit regex
    • usw

    Klar, viele Features sind auch in anderen Editoren (emcas hat bestimmt auch alle), aber ich benötige nie eine Maus, um etwas zu machen.

    Lassen wir aber nicht diesen Thread in einem vim-bashing-thread ausarten, wenn du mehr darüber wissen willst, benutze google.

    nep schrieb:

    Ich finde KDevelop ist auch nicht wirklich brauchbar. Man kann von einer schlechten IDE nicht gleich auf alle IDEs schließen.

    ich habe nie gesagt, dass ich IDEs schlecht finde. Ich denke, ich kann mich anpassen und eine IDE benutzen, wenn es Sinn macht. Für meine jetzige Arbeit komme ich auch ohne eine IDE bestens klar. So Sachen wie

    Debugger, Versionskontrolle, Profiler, Unittest-Tools, Servertools, DB-Tools, XML-Tools, GUI-Builder

    brauche ich nicht (gut debuger schon, gdb tuts auch) in meinen Editor intergriert zu haben. Versionskontrolle, naja ein svn up/ci auf der Konsole (wo vim breits läuft) geht auch schnell, usw.

    Wie ich schon gesagt habe, es gibt auch Programmierer, die etwas anders als "08/15" Software und GUIs zu schreiben haben, wo man sowas wie ein Codegenerator nutzlos ist.

    fricky schrieb:

    supertux schrieb:

    solche abwechslungsarmen jobs gibts noch?

    stimmt schon, dass ich "nur" eine Bibliothek zu pflegen hab, aber abwechslungsarm würde ich es nicht bezeichnen. Ich muss schon oft neue Geräte in die Bibliothek einbauen, neue Features einbauen, hier und da testen. Langweilig ist es bestimmt nicht. Und mir genügt es zu wissen, dass unsere Anlagen laufen. Bei uns gibt es andere, die die schönen GUIs schreiben (hab zum Glück damit nichts zu tun).

    fricky schrieb:

    ich wäre ausserdem sehr verzweifelt, wenn ich vim benutzen "müsste". letzens war ich etwas unter linux unterwegs und da hab ich meinen geliebten nedit genommen.

    ich bin sehr verzweifelt, wenn ich kein vim auf ein System finde und mit nano Dateien editieren müsste. Jeder hat seine Vorlieben.

    fricky schrieb:

    ist schon praktisch, wenn man einfach auf einen 'run' butten klicken kann, als hintereinander die schritte speichern,make,./a.out aufrufen von hand machen muss.

    ich finde es einfacher ':make' in vim einzugeben und in der Konsole nebenan (die erreiche unter Fluxbox mit 'Alt+x') tippe ich !. ein. Ich muss nicht einmal meine Hand in Richtung Maus bewegen 😉 [btw: wieso ./a.out? schon mal die -o Option von gcc/linker benutzt?]

    fricky schrieb:

    ausserdem nimmt einem 'ne IDE das erstellen von makefiles ab

    das erledigt 'automake' (und manchmal cmake) für mich. Und für meine Testprogramme habe ich eine fertige makefile. Ein cp Befehl auf der Konsole reicht.

    fricky schrieb:

    und mann kann beim debuggen durch den code steppen,
    🙂

    das kann gdb auch. Aber es stimmt, auf einer IDE ist es schon angenehmer.



  • supertux schrieb:

    ich habe nie gesagt, dass ich IDEs schlecht finde. Ich denke, ich kann mich anpassen und eine IDE benutzen, wenn es Sinn macht. Für meine jetzige Arbeit komme ich auch ohne eine IDE bestens klar. So Sachen wie

    Debugger, Versionskontrolle, Profiler, Unittest-Tools, Servertools, DB-Tools, XML-Tools, GUI-Builder

    brauche ich nicht (gut debuger schon, gdb tuts auch) in meinen Editor intergriert zu haben. Versionskontrolle, naja ein svn up/ci auf der Konsole (wo vim breits läuft) geht auch schnell, usw.

    Mergen musst Du also nie oder machst Du das auch per Konsole? 😕 Wie Refactorst Du Deinen Code? Mit Suchen/Ersetzen? Unittests schreibst Du auch keine? Debugging ohne Maus kommt mir auch umständlich vor, aber hängt wohl davon ab, was der Debugger alles kann. Für mich klingt das zumindest alles ziemlich altbacken. 🤡

    Wie ich schon gesagt habe, es gibt auch Programmierer, die etwas anders als "08/15" Software und GUIs zu schreiben haben, wo man sowas wie ein Codegenerator nutzlos ist.

    Was bringt Dich zu der Meinung, dass Codegeneration nur für GUI-Builder Sinn macht? Code-Assist, Code-Completion, Erzeugung ganzer Codefragmente - sei es beim Erzeugen neuer Variablen, Methoden, Klassen oder frameworkspezifischer Konstrukte - das sind Features, die Du in jedem Kontext benutzt. Dazu kommt die Intregration von Dokumentation in der IDE und und und ...

    Für mich ist eher 0815, wenn man diese Features nicht braucht. 🤡



  • supertux schrieb:

    nep schrieb:

    Was für mächtige Features hat vi denn?

    schon einige, die werde ich hier nicht beschreiben. Dafür gibt es etliche Websiten (Google hilft) und auch gute ViM Bücher. Was mir persönlich von vim gefällt sind z.b. solche Sachen wie

    • mehrere Dateien gleichzeitig editieren, kann sie nebeneinander, aufeinander, versteck, usw. halten und ein einfaches Ctrl+W+Pfeiltaste reicht, um die Fenster zu wechseln
    • ctags: mit Alt+] kann ich zwischen Funktionen springen
    • Visual Modus kann schon sehr schick sein
    • mehrere Buffer fürs copy&paste
    • Suche/Ersetzung mit regex
    • usw

    Klar, viele Features sind auch in anderen Editoren (emcas hat bestimmt auch alle), aber ich benötige nie eine Maus, um etwas zu machen.

    Lassen wir aber nicht diesen Thread in einem vim-bashing-thread ausarten, wenn du mehr darüber wissen willst, benutze google.

    Naja per google findet man aber nicht (unbedingt sofort) sowas wie "Was bietet mir vi an mächtigen Features für die Programmierung". Ist ja nicht so, dass ich vi(m) noch nie benutzt hätte. Die von dir aufgezählten Sachen sind ja nun wirklich nichts was es nur in vi gibt; bietet dir eigentlich jede IDE mehr oder weniger auch. Kannst auch in vielen IDEs sehr gut ohne Maus leben (nur mit dem Unterschied dass man sie trotzdem benutzen kann, was auch manchmal schneller zum Ziel führt). Das einzige was ich hier als wirklich "mächtig" ansehe ist das, dass man eben auch eine gute Integration mit der Unix-Shell bzw. auch sowas wie Regex's hat (wobei ich es zumindest mal hinterfrage, ob ich mit herkömmlichen Suchen/Ersetzen nicht genauso schnell ans Ziel komme, bevor ich mir einen exakt passenden Regex zusammengefrickelt habe...).

    Ich will auch gar nicht vi runtermachen. Mich hätte nur mal tatsächlich interessiert, was daran denn so wahnsinnig toll ist, wie manche immer behaupten...aber wenn man dann nach konkreten Dingen fragt kommen auch meistens nur Dinge raus, die es bei anderen Editoren auch schon gibt...
    Bzw. wird es ja auch seinen Grund haben, warum in der Softwareindustrie überwiegend IDEs wie Visual Studio und Eclipse eingesetzt wird.

    Also versteh mich nicht falsch. Ich denke auch, jeder soll damit arbeiten was ihm am liebsten ist. Und es gibt sicherlich Fälle wo man auch gut ohne das ganze Birmborium auskommt. Aber gerade bei richtig größeren anspruchsvollen Projekten, wird wohl niemand ernsthaft hergehen und das mit vi zusammenfrickeln...

    supertux schrieb:

    Debugger, Versionskontrolle, Profiler, Unittest-Tools, Servertools, DB-Tools, XML-Tools, GUI-Builder

    ...
    Wie ich schon gesagt habe, es gibt auch Programmierer, die etwas anders als "08/15" Software und GUIs zu schreiben haben, wo man sowas wie ein Codegenerator nutzlos ist.

    Gerade die oben genannten Dinge, werden ganz sicher nicht (oder zumindest ausschließlich) bei 08/15 Software verwendet...



  • byto schrieb:

    Für mich ist eher 0815, wenn man diese Features nicht braucht. 🤡

    Meine Rede 👍

    byto schrieb:

    Für mich klingt das zumindest alles ziemlich altbacken. 🤡

    Naja gibt hier ja auch Leute, die lieber alles selbst zusammenfrickeln als was vorgefertigtes zu benutzen. Das nenne ich dann eher altbacken 🙂



  • supertux schrieb:

    brauche ich nicht (gut debuger schon, gdb tuts auch) in meinen Editor intergriert zu haben. Versionskontrolle, naja ein svn up/ci auf der Konsole (wo vim breits läuft) geht auch schnell, usw.

    und das ist eben der grund warum ides so wertvoll sind.

    weil sie alles integrieren. ich mache zB nie ein explizites commit/checkout - das macht meine ide für mich. und das bei jedem speichern wenn ich so will - oder nur bei jedem build oder nur jedem erfolgreichem build...

    debugger springt direkt an wenn ich die anwendung teste.

    dazu eben refactoring, automatisierte tests, etc. alles in der ide integriert.

    nichts davon ist nur mit ide machbar - aber wenn ich mit vim refactoren will, muss ich ne regex hernehmen. wenn ich ein commit machen will, muss ich commit sagen (meine ide commitet beim beenden automatisch (sofern ich das will)).

    das alles zu sammen macht eine ide einfach besser. das problem ist, dass eine ide nicht gemacht wurde dass man sofort 100% produktiv ist 😉 das hat nichts mit vi-bashing zu tun, sondern vi ist eben ein editor und eine ide hat einen editor dabei.



  • byto schrieb:

    Mergen musst Du also nie oder machst Du das auch per Konsole? 😕 Wie Refactorst Du Deinen Code? Mit Suchen/Ersetzen?

    Mergen muss ich zum Glück nicht oft. Und refactoring, muss ehrlich sagen, sowas habe ich nie gemacht.

    byto schrieb:

    Debugging ohne Maus kommt mir auch umständlich vor, aber hängt wohl davon ab, was der Debugger alles kann. Für mich klingt das zumindest alles ziemlich altbacken. 🤡

    gdb hat sicher graphische Frontends, ich verwende keins.

    byto schrieb:

    Was bringt Dich zu der Meinung, dass Codegeneration nur für GUI-Builder Sinn macht?

    Nicht nur, aber was ich von manchen IDEs kenne (oder früher war es so), hat man beim Erstellen eines neuen graphischen Projkets bereits ein Grundgerüst bekommen. Dasselbe galt, wenn man z.b. ein neues Fenster hinzufügt oder so.

    Bei meiner Arbeit benötige ich jedoch sowas nicht (unter anderem, weil ich keine Klassen habe oder so).

    nep schrieb:

    Naja per google findet man aber nicht (unbedingt sofort) sowas wie "Was bietet mir vi an mächtigen Features für die Programmierung". Ist ja nicht so, dass ich vi(m) noch nie benutzt hätte. Die von dir aufgezählten Sachen sind ja nun wirklich nichts was es nur in vi gibt; bietet dir eigentlich jede IDE mehr oder weniger auch.

    das habe ich auch gesagt. Aber es geht auch darum, wie das Feature angeboten wird. Selbst das Windows Notepad bietet dir eine Such/Ersetzen Funktion. Nur im Notepad muss ich zuerst die Maus bewegen, klicken, warten bis Fenster erscheint, Muster eingeben, mögliche Checkboxes anklicken, OK clicken (also eine reine Klickorgie). In vim genügt es "<ESC>:%s/muster/neu/g", also bin ich mit der Ersetzung in "2" Sekunden fertig.

    Aber gerade bei richtig größeren anspruchsvollen Projekten, wird wohl niemand ernsthaft hergehen und das mit vi zusammenfrickeln...

    Ich weiß es nicht, vielleicht hast du Recht, aber ich kenn trotzdem manche Fälle (z.B. am Frauenhofer Inst.) wo Leute auch nur vim verwenden, egal wie groß das Projekt ist. Hey, ich will auf keinen Fall sagen, dass eine IDE nutzlos ist. Vor Jahren, als ich noch mit Visual Basic gespielt habe, habe ich diese IDE geliebt. Aber in meiner jetzigen Arbeit sehe ich z.b. keinen Grund, warum ich eine IDE verwenden sollte. Es könnte sein, dass das sich später ändert, wenn ich andere Projekte übernehme. Ich will nur sagen, es geht auch ohne und auch effizient.



  • supertux schrieb:

    das habe ich auch gesagt. Aber es geht auch darum, wie das Feature angeboten wird. Selbst das Windows Notepad bietet dir eine Such/Ersetzen Funktion. Nur im Notepad muss ich zuerst die Maus bewegen, klicken, warten bis Fenster erscheint, Muster eingeben, mögliche Checkboxes anklicken, OK clicken (also eine reine Klickorgie). In vim genügt es "<ESC>:%s/muster/neu/g", also bin ich mit der Ersetzung in "2" Sekunden fertig.

    notepad schlägt ja auch niemand vor.

    visual studio zB:

    strg+shift+r
    such-regex eingeben
    tab
    replace string eingeben
    enter

    sind sogar weniger zeichen als im vi 😉



  • In einer guten IDE kannst Du auch alles per Tastenkommando machen.

    Drückst Du z.B. in Eclipse STRG + SHIFT + L, dann öffnet unten links ein kleines Panel mit allen Tastaturkommandos. Du kannst sie natürlich beliebig anpassen, falls gewünscht.

    Wenn ich z.B. eine Klasse geschrieben habe, die an x Stellen in y Klassen genutzt wird. Nun möchte ich nachträglich die Schnittstelle der Klasse extrahieren und überall im Code nach der Schnitstelle programmieren.
    In Eclipse markiere ich den Klassennamen und drücke ALT + SHIFT + T. Es öffnet sich das Refactoring-Popup-Fenster. Ich wähle mit den Pfeiltasten "Extract Interface", gebe im Dialog kurz den Namen der Schnittstelle an und welche Methodensignaturen in die Schnittstelle sollen. Fertig - den Rest macht die IDE.
    Wie machst Du sowas mit dem Editor? Wir könnten ja mal die Zeit stoppen. 😉



  • supertux schrieb:

    Aber es geht auch darum, wie das Feature angeboten wird. Selbst das Windows Notepad bietet dir eine Such/Ersetzen Funktion. Nur im Notepad muss ich zuerst die Maus bewegen, klicken, warten bis Fenster erscheint, Muster eingeben, mögliche Checkboxes anklicken, OK clicken (also eine reine Klickorgie).

    Immer diese Consolentypen die keine Ahnung haben, dass man jedes Menü mit Tasten öffnen kann und jeden Button genauso.



  • byto schrieb:

    In einer guten IDE kannst Du auch alles per Tastenkommando machen.

    Drückst Du z.B. in Eclipse STRG + SHIFT + L, dann öffnet unten links ein kleines Panel mit allen Tastaturkommandos. Du kannst sie natürlich beliebig anpassen, falls gewünscht.

    Wenn ich z.B. eine Klasse geschrieben habe, die an x Stellen in y Klassen genutzt wird. Nun möchte ich nachträglich die Schnittstelle der Klasse extrahieren und überall im Code nach der Schnitstelle programmieren.
    In Eclipse markiere ich den Klassennamen und drücke ALT + SHIFT + T. Es öffnet sich das Refactoring-Popup-Fenster. Ich wähle mit den Pfeiltasten "Extract Interface", gebe im Dialog kurz den Namen der Schnittstelle an und welche Methodensignaturen in die Schnittstelle sollen. Fertig - den Rest macht die IDE.
    Wie machst Du sowas mit dem Editor? Wir könnten ja mal die Zeit stoppen. 😉

    glaub dir schon, dass du mit eclipse schneller bist, als wenn ich alles per Hand machen muss. Das ist mir klar. Ich muss aber keine Klassen schreiben (bin C Entwickler), also habe ich solche Probleme auch gar nicht 😉

    Shade Of Mine schrieb:

    wenn ich ein commit machen will, muss ich commit sagen (meine ide commitet beim beenden automatisch (sofern ich das will)).

    ich kann sicher auch mein vim auch so einstellen, dass beim Verlassen ein commit gemacht wird. Um ehrlich zu sein, ich tue grundsätzlich immer 'svn st' und 'svn diff | vimpager', bevor ich ein commit mache, also sehe ich das nicht wirklich als Vorteil (dass die IDE beim Schließen commitet).

    Shade Of Mine schrieb:

    das alles zu sammen macht eine ide einfach besser. das problem ist, dass eine ide nicht gemacht wurde dass man sofort 100% produktiv ist 😉 das hat nichts mit vi-bashing zu tun, sondern vi ist eben ein editor und eine ide hat einen editor dabei.

    gut, darauf können wir uns einigen.


Anmelden zum Antworten