Ideální IDE

13.3.2009 12:39 | Přečteno: 5527× | Programování | poslední úprava: 13.3.2009 12:40

Krátká úvaha nad vývojovými prostředími.

Jakožto webdeveloper jsem dlouho sháněl nějaký editor nebo IDE pro vývoj webů. Hodně se mi zpočátku zamlouvalo Geany, které mám i dnes velmi rád, ale nenabízí mi správu projektů takovou, jako jiné editory. Nicméně i přes to, jak rychle startuje, pracuje a co všechno obsahuje, používám Geany pro rychlou úpravu zdrojáků, konfiguračních souborů apod.

Když nás letos začal učit nový profesor na IVT PHPko objektově (docela sranda :) ), měl Komodo Edit 5. Tenhle editor mě dost uchvátil. Kvalitní správa projektů, go to odkazy v kódech, načítání komentářových nápověd ke všem funkcím a spousta dalších vychytávek. I rychlost mě překvapila, přestože nepatří mezi nejrychlejší. Ale vzhledem k tomu, co to umí, jsem se s tím smířil. Na editaci PHP a vůbec webových kódů naprosto ideální.

Problém nastal tehdy, když jsem chtěl udělat něco v C/C++. Ne, že by Komodo nezvládalo, v možnostech vytvoření nového souboru je možnost vytvořit Cčkovský soubor, ale tím to tak končí. Zvýrazňování syntaxe je velmi chabé a neexistuje tady žádná možnost okamžité kompilace s následným spuštěním pro test. Toto zvládalo i Geany. Komodo tedy jen pro web.

Fajn, jenže v čem mám dělat Cčko? Začal jsem zase u Geany, ale tam není tak pěkná nápověda jako v Komodu. Holt jsem se nchal zhýčkat pěknou nápovědou k PHP. Vzpomněl jsem si ale na dva velikány ohledně IDE. Jen jsem o nich většinou zaslechl nebo slyšel něco málo víc, ale nikdy jsem je nějak moc nezkoušel. Především asi proto, že nedělám v Javě. Jedná se o Eclipse a Netbeans.

Bez kontroly podpory jsem v Synapticu oba programy nainstaloval. Po spuštění Eclipse na mě vypadlo celkem příjemně vypadající prostředí, ale bylo nějak zpomalené. I start byl relativně dlouhý. Když jsem zkusil otevřít simple.c soubor, otevřel se mi geditu. Takže podpora leda pluginem. Vzhledem k tomu, že se mi moc nelíbí od začátku jsem ho rovnou zavrhl.

Když jsem spouštěl NetBeans, opět jsem si chvilku počkal, ale už jsem s tím i doc ela počítal. Složitější programy chtějí zkrátka víc času. Po asi minutě rozhlížení mi přišlo všechno jednoduché a intuitivní. Nainstaloval jsem updaty, plugin pro C/C++ a restartoval. Zkusil jsem vytvořit projekt, soubor.c a kompilace. Chyba. Soubor není v projektu. Jak je tohle možný, když jsem ten soubor v rámci projektu vytvářel, to nevím. Zřejmě to není plně intuitivní. Zjistil jsem i, že NetBeans podporují PHPko, takže jsem i trošku zajásal, že bych mohl používat jedno IDE pro všechno. Když se dostanu i na vysokou, kde učí Javu, tak mám jedno IDE na 3 jazyky. Prostě paráda.

Jenže moje verze nějak nemám možnost nainstalování pluginu pro PHP. To mě trošku usadilo. Koukám, že na oficiálních stránkách mají už verzi 6.5 a Ubuntu mi nabízejí jen 6.1. Ve výsledku tedy nevím, pro co se mám rozhodnout. NetBeans zatím vypadají nejlépe, ale startují dlouho a nejsou tak intuitivní jak jsem myslel. Nebo jsou a já jsem hrozná lama :)

Pokud jste to dočetli a nezhnusil jsem vás, napište do diskuze vaše doporučení. Rád bych měl něco kvalitního a jednoduchého. Určitě uvítám i vymlouvání mých názorů, pokud jsou špatné. Zkrátka vás prosím, poraďte mi.

       

Komentáře

[Miloslav Ponkrác]

MS Visual Studio C/C++

Vím, že to není pro Linux, ale Linuxu skutečně kvalitní IDE chybí.

Stejně tak, když 90% seriálů o programování pro Linux pro začátečníky uvádí make + gdb, tak je jasné, že Linux na profesionální programování moc zařízen není. Ne, že by make byl špatný program, sám ho moc a moc používám, jeho princip, univerzálnost, a nebál bych se tvrdit přímo nadčasovost je geniální. Přímé používání gdb ovšem nechápu vůbec, tento program není schopen nabídnout vůbec nic navíc, a to ještě s nesrovnatelně horším komfortem, co dobré grafické debuggery v dobrých IDE.

Sám bych rád věděl o kvalitním IDE pro Linux, nesmírně by mi to ulehčilo práci.

 

[steky]

A poběží mi MS Visual Studio pod Wine?

[Luk]

Starší verze možná ano. Ale i ty starší verze jsou pořád lepší než libovolné IDE pod Linuxem.

[pheeror]

I na vyvoj multiplatformniho kodu (tzn. s vyuzitim autotools/cmake, gtk/qt, atd. )? (just curious)

[Deleted [8409]]

cmake

[frEon]

s/just curious/ze zvědavosti/

[jan]

Schvalne si zkuste ve VS pracovat s projektem, ktery ma vice nez 100MB kodu - naprosto nepouzitelne.

[Michal]

Zkoušel jsem. V pohodě. Zřejmě jste nějak nešikovně vytvořil strukturu projektu (případně nevytvořil vůbec).

[jan]

Vyvijime par vlastnich veci oproti linuxovemu jadru, zkusil jsem ho do VS naimportovat a moc to teda nefungovalo.

[Saljack]

VS studio je snad ještě horší než java aplikace (teď si zase něco přečtu), neskutečně pomalé. Ať mi někdo tvrdí, že má rád VS tak je asi blázen.

[thingie]

Já teda nikdy ve VS neměl nic většího, vlastně jsem ho ani nezkoušel více jak pár odpolední, a už to jsou dva nebo tři roky, ale v porovnání s Eclipse to bylo nedobré. Eclipse je sice pomalé, ale relativně stabilně pomalé, věština akcí trvala předvídatelně pomalu, zatímco VS povětšinou šlo docela rychle, ale příliš často se rozhodlo něco udělat, co trvalo dlouho (nebo něco co jsem já přímo chtěl udělat trvalo dlouho) a během té doby se nedalo rozumným způsobem dělat nic jiného. S Eclipse se pracovalo příjemněji.

[thingie]

Banální příklad, neúmyslné zavedení syntaktické chyby jako nepárová uvozovka nebo něco takového. Eclipse nemá problém, VS se na tom příliš často mělo tendenci na chvilku kousnout, což je (pro mne) nepřijatelné.

[mich]

Já na programování C projektů používám Eclipse. Dlouho jsem hledal něco vhodnějšího, nicméně jsem nenašel. Eclipse si mě získal hlavně skvělou nápovědou při psaní kódu. Zatím jsem si nezvykl na jeho buildovací systém a používám make nebo scons. Debugger je řekl bych použitelný (vnitřně používá gdb). Zkoušel jsem anjutu a kdevelop, ale u těch jsem nezaznamenal nápovědu (doplňování) při psaní. Netbeans se mi zdál pomalejší, měl horší doplňování kódu a žádnou nadstavbu nad gdb.

Zajímalo by mě, co Visual Studio má, a Eclipse ne (To nemá být nějaká provokace nebo pokus o flame, chtěl bych znát váš názor).

[Luk]

Visual Studio především funguje spolehlivě, kdežto s Eclipsem jsem se pral. Když vynechám to podivné tuhnutí, problémy byly právě se zmiňovanou nápovědou kódu - často nepredikovatelně selhávala a blbnul debugging (debugované programy padaly, gdb odpadával od Eclipsu a zůstával viset, nezobrazovaly se proměnné apod.). Je pravda, že naposledy jsem Eclipse zkoušel před skoro 2 roky, takže třeba už jsou ty problémy vyřešené. Někdy ho zase zkusím.

Jinak Netbeans samozřejmě funguje jako nadstavba nad gdb. Může sice využívat i sunovský dbx (se sunovskými nástroji se bundluje do podoby Sun Studia), ale standardně používá právě gdb a pracuje s ním slušně, i když už jsem také párkrát narazil na potíže. Zatím nepřekonaný (na GNU/Linuxu) na debugging je starý dobrý ddd, i když jeho ovladatelnost je poněkud těžkopádná.

[stativ]

Zatím nepřekonaný (na GNU/Linuxu) na debugging je starý dobrý ddd, i když jeho ovladatelnost je poněkud těžkopádná.

Páni, teď jsem se konečně odhodlal na ddd mrknout a je to fakt luxus. Perfektně* se ovládá a prostě je to super kúl. Nádherně intuitivní. Další superlativy mě momentálně nenapadají, ale kdyby mě napadli, tak ho tak určitě popíšu.

---

Doteď jsem na debugging používal čistě gdb. gdbtui se mi občas rozhází a na debugovací vlastnosti Eclipse jsem si nemohl zvyknout. Pak jsem ještě zkoušel třeba kdbg, ale přišlo mi to dost špatně ovladatelné a příliš klikací

[Miloslav Ponkrác]

Zajímalo by mě, co Visual Studio má, a Eclipse ne

Základním problémem Eclipse je univerzálnost a jeho původní zaměření na Javu. Ať chcete, nebo ne, jakýkoli univerzální nástroj nemůže být tak dobře spjat s určitým jazykem jako nástroj šitý C/C++ na míru. Zejména C++ je velmi jedinečný a nesmírně bohatý jazyk s řadou originálním konceptů bránícím se dost úspěšně zkrocení na míru.

Visual Studio C/C++ je psáno přímo na míru C++, takže dokonale rozumí jeho standardní knihovně. Například při ladění zobrazuje std::string jako řetězec, std::vector jako pole, apod.. Rozumí kontextu C++ při psaní i ladění, a to dokonale i do hodně tvrdých specialit C++.

Druhý problém, byť překonatelný, s Eclipse je jeho nezvyklost. K VS jsem si sedl, a bez jakékoli nápovědy jsem do půlhodinky před léty pracoval. Když jsem si před časem sedl k Eclipse, tak jsem na to koukal jako sůva z jara, a marně jsem hledal, co tím autor chtěl říct. Je to hodně excentricky pojaté IDE, byť těm, co jsou na to zvyklí to asi nepřijde. Ale tohle není, co by Eclipse nějak diskvalifikovalo.

Velkou výhodou VS je jeho obrovská integrovanost. Rozdíl mezi Eclise a VS je úplně stejný jako když se Linus hádá o jeho konceptu jádra a mikrokernelu. VS je monolit vše v jednom, dokonale sešitý s daným programovacím jazykem (VS jich podporuje několik), systémem i kompilátorem. Se všemi výhodami z toho plynoucími včetně vzájemných nápověd a integrace MSDN. Eclipse je takový opatchovaný pluginový systém – výsledkem je dost moloch, který trochu abstrahuje od konkrétních detailů jazyka, systému, či kompilátoru. A já bych právě řekl, že v IDE to je dosti mínus.

No a hw náročnost Eclipse a VS se také nedá moc porovnávat.

[mirec]

No ja namiesto IDE používam vim (a plne mi to vyhovuje).

gdb mi ako debugger plne vyhovuje (musím ale povedať, že od debuggeru nevyžadujem nič okrem backtrace, aj to využijem veľmi zriedkavo keďže mi moje programy väčšinou padajú v dôsledku chyby knižníc s ktorými pracujem alebo ovládača grafickej karty).

Makefile sú užitočná vec, ale nie cross platformová (rozhodne radšej generovať Makefile než vytvárať ručne). Makefile generujem pomocou CMake (fakt odporúčam pozrieť tento nástroj, pre jednoduchšie projekty stačí väčšinou pár riadkov). CMake vie okrem Makefile vygenerovať projekty pre rôzne IDE (napr. aj visual studio).

[Martin Mareš]

Make rozhodně není vrchol elegance, ale zrovna cross-platformnost bych si mu vytýkat netroufal: Znáte nějaký OS, na kterém by make neběžel?

CMake je zajímavý, ale zatím z něj mám ten pocit, že popsat v něm nějaký složitý projekt bude práce pro vraha. SCons má syntaxi o něco hezčí, ale zase je už na středně velké projekty velice nepříjemně pomalý.

[mirec]

K make, samotný program síce multiplatformový je, ale Makefile nie, musí tam byť kód ktorý podľa platformy nájde nástroje a správne vytvorí Makefile. Práve preto používam CMake (to je práve ten program ktorý vie vygenerovať Makefile, alebo iné veci).

CMake používa napr. KDE a nemyslím, si, že by to nebolo vhodné na veľké projekty, skôr práve naopak. Odporúčam pozrieť ako je napísaný CMakeLists.txt napr. v projekte fatrat.

[Martin Mareš]

Právě že generování makefilů mi přijde jako naprostý nesmysl. Když už vytvářím sofistikovaný nástroj, proč by měl složitě generovat Makefile, místo aby programy spouštěl přímo?

[mirec]

Pretože je jednoduchšie napísať:

add_executable(program subor1.cpp subor2.cpp main.cpp)

než

CXX=g++

program: subor1.o subor2.o main.cpp
    g++ $? -o 

subor1.o: subor1.cpp subor1.h nejakysubor.h dalsisubor.h kopadalsichincludovanychsuborov.h
    g++ $< -o $a


subor2.o: subor2.cpp subor2.h kopadalsichincludovanychsuborov.h
    g++ $< -o $a


main.o: main.cpp subor1.h subor2.h
    g++ $< -o $a

Pretože nemám chuť prepisovať v makefiloch kompilátor vždy keď chcem použiť niečo iné než gcc, pretože nemám chuť písať do makefile cesty k všetkým knižniciam, includom .. ktoré používam, pretože nechcem riešiť rozdiely medzi platformami (/ vs. \), pretože mám rád kompiláciu mimo zdrojových kódov...

[Martin Mareš]

Právě proto, že je jednodušší napsat onen jeden řádek, je lepší, aby program, který tomu řádku rozumí, rovnou spouštěl kompilátor, místo aby generoval složitý Makefile a používal make jen jako primitivní shell.

[mirec]

Nechápem prečo by mal spúšťať piamo kompilátor? Podľa mňa je lepšie napísať 1 riadok, z toho 1 riadku buď vygenerovať jednoduchý Makefile, alebo súbory projektu pre rôzne IDE (to by nebolo možné ak by to spúšťalo len kompilátor). Keď cez CMake vygenerujem Makefile potom mi už stačí len jednoducho po zmenách rekompilovať pomocou make (väčšinou mimo adresára so zdrojovými kódmi, teda mám adresáre program-src program-build, program-win-build .., podľa toho v ktorom adresári napíšem make mi vytvorí binárky pre rôzne platformy). Pritom CMake je pomerne malý nástroj (vzhľadom na to, že o spúšťanie kompilátora, závislosti a pod. sa stará Makefile). Zato CMake je silný nástroj na vyhľadávanie externých nástrojov / knižníc.

[Martin Mareš]

A kdo Vám Makefile automaticky opravuje, kdykoliv se změní nějaká závislost? Nebo spouštíte CMake po přidání každého #include?

[mirec]

Pri spustení make sa kontroluje ktoré súbory sa zmenili (to robí samotný make), ten mimochodom kontroluje aj či sa zmenil CMakeLists.txt a v prípade potreby spustí cmake aby sa vygenerovali nové závislosti. Celý proces je celkom efektívny (kontroluje sa len to čo sa kontrolovať musí). Vygenerované makefile súbory sú stále výrazne menšie než tie, ktoré generujú autotools.

[Martin Mareš]

Když srovnáváte obludnost Makefile s tím vygenerovaným autotools, tak to je jiná... to je jako říkat, že venku neprší, a argumentovat biblickou Potopou světa

Ale ještě jste mi pořád nevysvětlil, jaký má smysl udržovat ve hře make.

[stativ]

Osobně bych tipl, že je to u CMake jakýsi princip. Tzn, že nic nespouští, ale ze zadaného CMakeLists.txt je schopen vygenerovat sadu v podstatě libovolných texťáků, které můžou být docela dobře Makefiles, Eclipse project a já nevím co ještě. Prostě řečeno je to spíš jen takový preprocesor (a sakra dobrý ).

[mirec]

No odporúčam pozrieť si tento článok, je to už síce trochu staršie a niektoré veci sa dajú zapísať jednoduchšie, ale na ilustráciu toho čo vlastne CMake robí snáď postačí. No a v podstate s tými texťákmi je to pravda i keď na to aby to vedelo vygenerovať akékoľvek treba napísať vlastný "plugin". Pri celkom slušnom množstve podporovaných formátov ale nevidím problém vybrať si obľúbený.

[mirec]

Tak v prvom rade je to filozofia linuxu (alebo aspoň kedysi bola). Teda v linuxe som zvyknutý na to, že programy sú relatívne malé a robia to na čo sú určené. Implementovať do CMake funkcionalitu GNU Make by bola duplicitná práca, CMake by bolo zbytočne veľké a náchylné na chyby. Nevidím dôvod prečo by CMake nemalo používať odladený a výkonný nástroj GNU Make. Prinieslo by to vôbec nejaké výhody? Aký zmysel by malo povedzme namiesto: cmake cesta_k_zdrojakom && make písať povedzme cmake -configure cesta_k_zdrojakom && cmake -make?

[Martin Mareš]

Trik je v tom, že CMake z make využívá jen maličkatou část a ten obrovský zbytek zatížený mnoha lety dost spletitého vývoje a mající tomu odpovídající sémantiku spíš překáží. A o výkonu a odladěnosti bohužel také nemůže být řeč, makefily velkých projektů běžně obsahují obezličky na vyrovnání se s bugy a misfeaturami GNU make. Jsou okamžiky, kdy je lepší přestat být pyšný na dědictví starých Unixů a raději postavit vše znovu.

Psát cmake -configure cesta_k_zdrojakom && cmake -make samozřejmě smysl nemá, mělo by stačit spustit cmake bez parametrů a on by měl sám zařídit vše potřebné. Testovat featurky systému (configure) nemusíte ručně (leda když chcete explicitně říci "otestuj vše znovu, změnil se mi systém"), naopak se hodí, aby když připíšete do zdrojáku nový test, aby se při další kompilaci automaticky provedl a výsledky ostatních testů se použily z minula.

I takový systém může fungovat jako sada jednoduchých nástrojů, jen rozdělených trochu jinak než tradiční configure a make. Například může mít minimální jádro, které se stará o závislosti (i testy na featurky jsou vlastně závislosti), a samostatné modulky, které se starají o kompilaci v různých jazycích, o jednotlivé testy atd.

Zkoušíme s Michalem Vanerem už nějaký čas něco podobného vymyslet, nechte se za pár měsíců překvapit.

[pheeror]

kdevelop - a jako bonus nebude cely tvuj projekt zamceny naporad v MSVC a windows .

IMHO kdyz od zacatku pouzivas jen "profesionalni IDE" tak je pouzivas spis na bastleni nez na profesionalni programovani, kdezto kdyz se ucis na textovyeditor+make+gcc+gdb a pak prepnes na poradny IDE, tak te to k bastleni nesvadi a dokazes to fakt vyuzit.

[Let_Me_Be]

Samotne MSVS neni tak skvele, nicmene s pluginem VisualAssistX se tomu opravdu nic nevyrovna.

Pro Linux je momentalne nejlepsi Eclipse CDT, po vydani nove verze Kdevelopu myslim budeme mit nove super IDE pro C++.

[stativ]

On QtCreator je taky pěkný, ale bohužel se mi do něho nepodařilo nacpat vlastní nápovědu.

[Josef Kufner]

Linux nepotřebuje kvalitní IDE, protože už sám systém je kvalitním IDE.

[Filip Jirsák]

V tom případě asi nevím, co znamená to I ve zkratce IDE.

[freshmouse]

Mně se z těch mološských IDE nejvíc líbí uspořádání NetBeans, jenže je pomalé (zkoušel jsem 6.1), že bych za to někoho kopnul. Jinak mi přijde takové přehlednější a útulnější než Eclipse (které teď používám), i když třeba na zásuvné moduly je podle mě chudé (např. tam není modul pro Bazaar). Taky nevím, jaký má editor. Ten v Eclipse je dost na pendrek (naštěstí jsem nedávno objevil něco na zalamování řádků, ale ještě jsem to nevyzkoušel).

[freshmouse]

Abych upřesnil, mluvím o IDE pro Javu (EE).

[Leoš Literák]

A co Intellij IDEA? Funkcne je na tom vyborne, problem je v pametove a CPU narocnosti. Treba verze 8 mi pripomnela doby 486 procesoru a to na novem nablystenem notebooku se silnym procesorem. Ted si trosku hraju na prtavem projektiku s 8.1 a ta uz vypada vykonnostne lip, ale casy Idey 3 jsou davno pryc.

[freshmouse]

No, licence Personal za 225 euráčů, licence Commercial 540... To by to muselo být fakt extra dobré... A já pro mé účely nepotřebuju ani moc funkcí (dokonce třeba ani ladicí nástroje většinou ne), spíš přehlednost, "srozumitelnost" a tak...

[Leoš Literák]

No, dokud byly licence v eurech, bylo to lepsi Nicmene maji i academic/open source licence.

[Ladicek]

To by to muselo být fakt extra dobré...

Extra dobré zdaleka nevyjadřuje, jak dobrá IDEA je

[podlesh]

Verze 8 je náhodou výrazně rychlejší než verze 5 a 6 (ta byla strašná). V podstatě hlavní důvod proč verzi 8 kupovat je právě rychlost a náročnost, protože jinak tam přidali vesměs ptákoviny (jak pro koho, samozřejmě).

[moira]

Muzu se zeptat, co ti v editoru Eclipse chybi? (no flame, jen me to zajima, trebas se dozvim nejakou vychytavku).

[srigi]

Odporucam vyhnut sa pri Netbeans aj Eclipse instalacii z repozitara. V pripade Netbeans doporucujem stiahnut z ofiko stranok poslednu verejnu verziu (dnes v6.7M5 tusim) a mainstalovat si ho do uzivatelskeho adresara (teda najlepsie niekam do /home/USER/bin). Zapodievat sa starinami v6.1 je nezmyselne.

V pripade Eclipse odporucam nieco podobne s malym tweakom - siahnut po PDT (pre PHP) a pre C/C++ sa pokusit doinstalovat podporu (to ostatne plati aj pre Netbeans).

[Luk]

Zatím nejlepší IDE, jaké jsem kdy používal, bylo Microsoft Visual Studio, z těch nemicrosoftích potom NetBeans. Kdysi jsem používal Eclipse, ale byly s ním problémy (zakusování), navíc mi některé věci přišly dost neintuitivní a špatně použitelné. Dále jsem zkoušel i Anjutu, KDevelop a některé další, ale nebyly nic moc. Uvažuji vyzkoušet také Qt Creator, vypadá slibně.

[Fluttershy, yay!]

Ve škole bohužel VS používat musím... Proč "bohužel"? Nesnáším věci, které si myslí, že jsou chytřejší než já. Například přeformátovávání textu (a následné automatické přesuny kurzoru) nebo nechtěné doplňování příkazů.

Jinak doporučuji naučit se s Vimem.

[Luk]

Můj názor na Vim (ani po 4 letech se na něm nic nezměnilo, i když už umím Vim ukončovat)

[mirec]

A kedy to budu tie úžasné grafické editory tak efektívne ako vim?

[Luk]

U mě Vim nebude nikdy tak efektivní jako cokoliv jiného.

[mirec]

Ale to nie je problem vimu. Vim má moderné a jednoduché ovládanie (kiež by to platilo aj o iných editoroch) ktoré nie každému sadne. Nehovorím, že ovládanie príkazmi je perfektné (radšej preferujem ctrl + s namiesto :w, alebo ctrl + q namiesto :q, po stlačení ctrl + q ak nemám uložené zmeny tak mám rád, že sa editor spýta či to chcem skutočne urobiť .. ale u vimu mám tú výhodu, že si to dokážem nastaviť a pritom to nastavenie je tak jednoduché, že si to užívatelia grafických editorov ani nevedia predstaviť).

[Martin]

Mě fascinuje nejenom to, že je ten zápisek i po těch letech ještě stále k přečtení, ale že máš odvahu na něj ještě sám zpětně upozorňovat. Sebemrskačství? :-P

[Luk]

ten zápisek i po těch letech ještě stále k přečtení

Poděkování patří týmu, který udržuje abíčko v provozu.

že máš odvahu na něj ještě sám zpětně upozorňovat. Sebemrskačství?

Narozdíl od některých lidí se stále hlásím k tomu, co jsem vyřkl dříve (a často na své dřívější texty odkazuji)

[Leoš Literák]

Seznam IDE pro Linux

[freshmouse]

> Když jsem zkusil otevřít simple.c soubor, otevřel se mi geditu.

Tak to máš asi nějak blbě nastavené. Jak jsi postupoval?

> Koukám, že na oficiálních stránkách mají už verzi 6.5 a Ubuntu mi nabízejí jen 6.1.

6.5 vyšlo někdy v listopadu nebo prosinci...

> ale startují dlouho

Co furt máte s tím startem? I kdyby se to spouštělo pět minut, tak je mi to jedno. Hlavní je rychlost při práci...

[steky]

Nic jsem si nenastavoval, akorát jsem dal otevřít soubor a tam jsem si zvolil. A ejhle, ono se to otevřelo v nečem jiném.

Fajn, a to mezi 6.1 a 6.5 neudělali žádnou meziverzi? Něco jako teď Firefox místo 3.1 bude 3.5?

K tomu startu, jsem asi moc navyklej na to Geany, který se zobrazí sotva kliknu na spouštěč. Ale je fakt, že rychlost při práci je důležitější. Bohužel i tam to mám pomalejší :/ nějak se to zakousává a potvrzování nebo kliknutí na nějaký tlačítko či záložku to zaregistruje tak minimálně 2 vteřiny po kliknutí. A to mám notebook starej asi rok a půl. (C2D T5500, 1GB RAM)

[moira]

Predpokladam, byl v tom Eclipse plugin pro vyvoj v C/C++?

[steky]

Spíš ne. Akorát jsem to nainstaloval a zkoušel otevírat soubory. Ten plugin mě napadnul až později. Zase si ale říkám, jestli by neměl každý editor umět jakýkoli soubor alespoň otevřít. Vždyť se jedná vlastně je o prostý text, kdy se akorát mění koncovka souboru. I kdyby mi to vůbec nezvýraznilo syntax, tak by to mohlo ten soubor alespoň načíst jako prostej texťák ne?

[rADOn]

IMO je nejlepsi zacit s necim jednoduchym. Klikaci prostredi pro blbecky vedou k tomu, ze clovek je ve vysledku polovzdelany. Me treba netbeans nechaly vesele bastlit servlety, aniz bych mel paru jak kontejnery funguji, k cemu jsou vsechny ty zahadne xml konfiguraky etc. Tehdy jsem byl stastny ze mam min prace, dnes vim ze to byla chyba. Jeste hur jsou na tom lidi kteri neumi pouzivat verzovaci systemy, protoze bez sveho klikatka neudelaji ani checkout.

Nerikam ze chytry IDE jsou spatny - pokud se vyznas a vis co chces, pak usetri spoustu casu. Pokud ne, pak z tebe snadno udelaji outsourcovatelneho opisovace kontextove napovedy.

Moje odpoved na otazku - Javovsky IDE jsou pomaly a nenazrany mrchy. Gnomacky veci nepouzivam. Na webovy veci mi vyhovuje Quanta, KDevelop je hezkej, ale az moc klikaci na muj vkus. Mam v planu si na nej posvitit az se poradne naucim s vimem. A s tim jsem jeste ani poradne nezacal takze se zatim drzim Kate. Na C a python mi vyhovuje - nehraje si na IDE, ale je to zatracene dobrej editor a to je vsechno co chci. Co se IDE tyce, lepsi nez vsechny klikatka je pro me dobre nastaveny inputrc.

Kdyz se rozhlidnu okolo sebe, lidi o nichz mam nejlepsi mineni jsou schopny psat v cemkoliv, a pouzivaji vim/emacs a gdb. Petikorunovy bastliri, pseudochytry konzultanti a podobna verbez nejsou schopny fungovat vez visual studia. Nahoda ? Nahoda. Urcite jen nahoda.

[dad]

Nerikam ze chytry IDE jsou spatny - pokud se vyznas a vis co chces, pak usetri spoustu casu

Dukaz tvrzenim ? Ale nyni vazne, pro takova tvrzeni neexituje zadna studie, ktera by to potvrzovala. Vasi vetu chapu jako takovy typicky komunikacni prvek vhodny k snize konfliktniho potencialu - v diskuzi casto vhodne, ale ve vysledku kontraproduktivni. Po zkusenostech zastavam nyni nazor 'nechodit kolem horke kase'.

Kdyz se rozhlidnu okolo sebe, lidi o nichz mam nejlepsi mineni jsou schopny psat v cemkoliv, a pouzivaji vim/emacs a gdb. Petikorunovy bastliri, pseudochytry konzultanti a podobna verbez nejsou schopny fungovat vez visual studia. Nahoda ? Nahoda. Urcite jen nahoda.

I zde je mozno lehce dokazat, proc tomu tak je. Jiz v onech 10 zasadnich bodech o filozofii unixu od M. Ganzcara je GUI charakterizovana jako limitujici. Samozrejme limitujici pouze pro jednotlivce, kteri na limit mohou vubec dosahnout.

[rADOn]

Dukaz tvrzenim ? Ale nyni vazne, pro takova tvrzeni neexituje zadna studie…

Nikoliv dukaz, jen tvrzeni zalozene na zkusenosti. Dal by se napsat elaborat o tom jak chytry IDE pridavaji dalsi uroven abstrakce nad jiz existujici a kdy to je a neni kontraproduktivni, kdy je to prinosny ale zeslozituje to pochopeni zacatecnikum, kdy to slouzi jako berle zacatecnikum a zkusenejsim to prekazi. Dalo by se spekulovat kolik cudliku a checkboxu jde nejvice narvat do libovolneho GUI aby zustalo prehledny, a kolik jich tam musi byt nejmene aby se to jeste dalo povazovat ze pouzitelny. Zkratka dalo by se zvanit a zvanit, ale v tyhle zvraceny dobe kdy vsechny zajima jen "executive summary" jsem si to dovolil shrnout do vyse uvedene vety. Kdybych to mel aspon trochu rozvest, byl oby to neco ve smyslu - dokud je IDE nastroj na usetreni prace kterou znam a vim ze mi zbytecne zabira cas, je to pomocnik. Kdyz je to magicka krabicka, ze ktere leze nejaky vysledek procesem me neznamym, tak se budu nejdriv snazit tomu procesu priblizit a pochopit ho, ne se od nej oddelit nejakou dalsi urovni abstrakce.

[dad]

muj kolega delal disertaci v roce 1985 - tema ergonomie GUI. Tenkrat sice nebyly windows, tykalo se to ale velinu velkych plynarenskych spolecnosti, ty uz tenkrat mely graficke prostredi. V 90. letech se pak hodne zjistovalo, jak definovat ergonomicka pravidla pro GUI, ale nejak to zhaslo - typuji , ze M$ zaloboval. To jsou me informace a pode techto je soucasne prostredi absolutne neproduktivni. Narustaji navic naklady na bryle a lekarske naklady na lecbu problemu s pateri.

Predstava, ze produktivita vyroby software se zlepsi tim, ze slozka, ktera se na zhotovovani podili 10% bude optimalizovana o 10 % je uchylna - a nikdy by neprosla, kdyby softwarovy gigant nepotreboval protlacit na trh sve chore vymysly. A konkurence se toho chytla.

Ja uz programuju 25 let. Snad prvni dva roky jsem trochu vice psal, od te doby jenom kopiruji a upravuji. Vsechny ty udelatka, o kterych se zde mluvi v tom nepomouho vubec, jen zdrzuji. Kdyz musim naprogramovat nejakou funcionalitu, tak se nad tim zamyslim tyden, protoze pak musi 10 let fungovat, napsane je to pak za 2 hodiny. Abch u toho usetril 5 minut (o cemz navic silen pochybuji) je uplna hovadina.

Ale co, ze si mladi serou na nohy je jejich vec. Tim samozrejme neyslim Vas, s Vasim prispevkem se ztotoznuji.

[Luk]

To jsou me informace a pode techto je soucasne prostredi absolutne neproduktivni.

Podobně byl jako velmi nevhodný ovládací prvek (pro řízení auta) vyhodnocen volant

Narustaji navic naklady na bryle

Nenarůstají. Je vědecky prokázáno, že takto si oči poškodit nelze.

[thingie]

Hlavně, že ta automobilová přirovnání máme, žejo. Ale tohle není tak nepřípadné. Dopravní prostředek s volantem by v každém normálním světě byla zcela stejně absurdní představa jako jaderná bomba s červeným čudlíkem na odpálení přidělaným na jejím těle.

[Luk]

Dopravní prostředek s volantem by v každém normálním světě byla zcela stejně absurdní představa jako jaderná bomba s červeným čudlíkem na odpálení přidělaným na jejím těle.

No, pokud by na tom čudlíku bylo napsáno الله أكبر, tak bych to jako moc absurdní neviděl

[Miloslav Ponkrác]

Klikaci prostredi pro blbecky vedou k tomu, ze clovek je ve vysledku polovzdelany

Já jsem před dvaceti lety začínal a léta dělal pouze s IDE, a to naprosto vše. A dneska bych to jako začátek doporučil jako nejlepší cestu.

Ale k čemu se hlásím je, že Javisté by měli začínat bez Eclipse, a podobných věcí. A první programy udělat z příkazové řádky, či z jednoduchých plain text editorů. Java je totiž unikátní v tom, že je to tak očesaný jazyk, že IDE často generují a automatizují tak neuvěřitelně moc věcí (aby se vůbec Java dala efektivně vývojářsky používat), že opravdu je možné leccos u začátečníka. Ale u jiných jazyků to fakticky moc nehrozí, tam je mnohem lépe začínat s IDE.

Jinak já třeba nejčastěji používám kombinaci MS Visual Studio a vim. Ve vimu píšu i české texty (mám v něm i kontrolu pravopisu).

Kdyz se rozhlidnu okolo sebe, lidi o nichz mam nejlepsi mineni jsou schopny psat v cemkoliv, a pouzivaji vim/emacs a gdb. Petikorunovy bastliri, pseudochytry konzultanti a podobna verbez nejsou schopny fungovat vez visual studia. Nahoda ? Nahoda. Urcite jen nahoda.

Já bych spíš řekl, že máte špatný statistický soubor. Ti největší machři produkující skutečné programy většinou bez dobrého IDE nejedou. Sem tam jsou výjimky, ale pokud mají vykazovat rozumné výsledky v rozumném čase, pak hackeřina ála gdb není zrovna vždy efektivní.

vim se s IDE nevylučuje, například vim jde částečně do Visual Studia integrovat.

Ale přiznám se, že také přemýšlím o jiném plain text editoru, než je vim, protože vim už se snaží být až moc chytrý. Napsal jsem si vlastní českou klávesnici do Windows, tedy úplně klasickou plus přidal na volná místa typografické znaky, a všude to funguje, ve všech programech, jenom ve vimu ne. Vim se snaží emulovat snad i klávesnici a mrtvé znaky. Je to dost na houby. Když jsem si tedy nadefinoval tutéž klávesnici i do vimu, pak jsem zase zjistil, že když píšu UTF-8 text, tak funguje, ale v jiném kódování zase ne.

Jinak stále nechápu, proč někdo gdb vůbec používá. Já jsem neobjevil jedinou jeho výhodu. Tedy kromě jeho značné historické hodnoty a značného množství manuálů, ale tím bych tak s výhodami skončil.

 

 

[Martin Mareš]

Ad největší machři: myslím, že u Linuse byste s nějakým IDE sotva pochodil...

Ad gdb: výhod je spousta. Dvě hned z kraje: máte k dispozici historii provedených příkazů a můžete pohodlně volat funkce z laděného programu a nechat je, ať vám vypisují výstup (ideální prostředek na zkoumání stavu datových struktur).

[Miloslav Ponkrác]

Ale Linus není machr na nic jiného, než linux kernel – a tohle low level programování je dosti jiné, než 99,9% věcí, co se programuje. Linus totálně shořel jak zapálený papír při pokusu pochopit, či naučit se C++, nemá prostě na to. Stejně tak pravděpodobně nebude Linus dobrým kandidátem na programování informačního systému, či náročné databázové aplikace. Stejně bych Linusovi příliš nevěřil při návrhu ergonomického GUI pro běžné lidi, apod.. Ani jsem si nevšiml, že by třeba Linus byl zkušený v enterprise aplikacích a Javě, třeba.

V zásadě Linus – a tím nijak nesnižuji jeho znalosti kernelu a schopnosti – by při většině běžných pracech musel ještě ve znalostech a zkušenostech dohánět určitý čas běžné programátory, kdyby se k tomu dostal. A zcela jistě by začal pak používat i IDE, protože by sám viděl, jak moc efektivní to je a jak moc to efektivitu zvyšuje.

Ad gdb a výhody: Totéž dokáže i běžný GUI debugger a těmito schopnostmi disponuje též, akorát v efektivnějším balení.

 

[Martin Mareš]

Myslím, že svou schopnost vytvořit program s ergonomickým ovládáním Linus jasně dokázal tím, že napsal Git. Nástroj, který svou efektivitou strčí do kapsy všechny VCS vyvíjené předchozích 30 let. Na Linusovi se velmi vážím právě jeho nesvázanosti konvencemi, včetně té Vaší o předurčenosti C++ ke spáse světa

[Miloslav Ponkrác]

A jéje, sáhnul jsem Vám na Boha, sorry Ale ten nadživotní obraz Linuse v pokoji opravdu nemusíte sundávat

[Miloslav Ponkrác]

Jinak git nenapsal, ale naprasil. Právě tam jsem s konečnou platností pochopil, že Linus není dobrý programátor. Linus sice vytvořil dobrý koncept (přesněji řečeno, opsal a syntetizoval z konceptů jiných vcs, které byly předtím používámy), ale implementace je opravdu strašná. Pokoušel jsem se to doma na WIndows/Linux používat, a je to opravdu bastl.

Ono to bude tak, že git je dobrý koncept, ale daleko lépe a kvalitněji ho implementují a dají dohromady jiní, než Linus.

[Martin Mareš]

A co že je na implementaci Gitu konkrétně špatně?

[mirec]

Do doby kedy som skúsil git som netušil čo je to rýchle a stabilné vcs. Neviem čo je na git strašné, ale po istom čas používania SVN a CVS bol git úplne iná úroveň komfortu, jednoduchosti, rýchlosti a stability.

[thingie]

Vaše schopnost napsat učeně a odborně vypadající komentář s naprosto dokonale nulovým množstvím skutečné informace a argumentů je až fascinující.

[Josef Kufner]

Tady aspoň vidíš, jak vypadá opravdový programátor.

Na zprasenosti částí nezáleží. Podstatná je kvalita celku. To jsou dvě naprosto různé a zcela nesouvisející věci i přesto, že se vyskytují v těsné blízkosti.

[stativ]

…praví hackeři debugger nepotřebují.

[Vojtěch Vysloužil]

Já doporučuji Code::Blocks.

[Jardík]

+1

[Radek Hladik]

Upřímě řečeno, já nejvíc jsem spokojen s Delphi, ale to je jen pro pascal a Windows (kylix nepovažuju za vůbec použitelný projekt). Pro Linux jsem zatím neobjevil žádné ideální prostředí. Na něco mi fungovala anjuta, jinak jedit, ale komplexní prostředí se vším všudy jsem nenašel. Souhlasím, že make je super věc. Gdb je možná skvělé, ale bez nějakého frontendu nepoužitelné.

Shrnul bych to tak, že jsem si zvyknul používat kombinaci různých nástrojů a docela to stačí. Anjuta jako frontend pro debugger (gdb), jedit jako editor, make na překlady, ...

[Fluttershy, yay!]

Pro Pascal Lazarus.

[Radek Hladik]

Lazarus jsem kdysi zkoušel, a poměrně mi zlobil. Editor byl skoro nepoužitelný, překlad složitějších věcí padal atd... Nevím, jestli se to zlepšilo, ale on stejně Pascal pod linuxem není úplně vhodný jazyk (ikdyž freepascal je velmi dobrý projekt). Delphi jsem uváděl spíš jako IDE, které mi připadá velmi dobré.

[Deleted [8409]]

Pro Windows Visual Studio a pro Linux Eclipse nebo KDevelop.

Osobně mám nejradši Visual Studio a v linuxu jsem nejvíc zvyklý na KDevelop (akorát toho moc nenabízí, no).

[Michal Fecko]

Vim

[KS]

Jak se ve Vimu ladí?

[fakenickname]

:make debug

[KS]

Tohle neznám. To mi nastaví breakpoint a zobrazí obsah proměnných?

[fakenickname]

j

[KS]

j?

[fakenickname]

pane ano pane

[KS]

Jak? (myslel jsem ze vimari komunikuji jenom zkratkama)

[Michal Fecko]

:q!

[fakenickname]

a coz takhle vimar co dela perl a pracuje na unixu

[Martin Mareš]

A proč bych měl ladit ve Vimu? Od toho je přeci debugger

[KS]

No bavíme se tady o IDE a on tady zmiňuje "obyčejný" textový editor, tak mě to zajímalo.

[Martin Mareš]

Otázka je, jestli se bavíme o IDE nebo obecněji o pohodlném prostředí pro programování.

Pro mne to druhé znamená naprosto jednoznačně mít po ruce kvalitní textový editor, čímž v podstatě všechna IDE vypadnou ze hry hned na začátku.

[stanger]

Na c/c++ se mi docela libilo Eclipse s CDT.

Jinak pracuju v J2EE a tam u me vladne NetBeans (pokud clovek prekousne tu rychlost a je potreba nainstalovat prvni varku akrualizaci po kazdym vydani) :)

Dneska uz bych NetBeans pouzil na c++ a php.

Visual studio, jsem si zkusil, ale vubec se mi v nem nepracoval dobre, ovladani a nastaveni mi prislo hodne krkolomny a jeste navic se prekladac VS  nesmiril s nekteryma navykama, ktery mam s gcc :)

[Messa]

K čemu IDE na cokoliv kromě Javy? Kvůli nápovědě? Po týdnu programování znám příkazy nazpaměť, a pokud jednou za čas použiju nějakou neznámou knihovnu, prostě se podívám do její dokumentace. Stejně nějaké napovídání nebo doplňování v C nebo v Pythonu není uspokojivě funkční nikde, ani ve Visual Studiu (tam je perfektní C#, ne C++). Možná je na tom ale PHP s touto podporou lépe než třeba Python, to nevím. Mě osobně stačí základní editační schopnosti KDevelopu, v nouzi vimu. Pro zkompilování se přepnu do terminálu vedle a spustím make. Mimochodem, kolegové používají emacs.

Tolik můj názor k IDE. Chtěl jsem tím říct, že raději týden programovat v aspoň něčem než týden jen hledat ten správný editor. I nastavení vlastních barviček písma a pozadí považuji za důležitější, než jestli editor umí projekty a kompilovat

[Radek Hladik]

IDE nabízí spoustu funkcí, které zrychlují práci. Například zobrazení definice funkce, atd... Já osobně si nepamatuju všechny funkce, se kterými pracuji, jejich prototypy, atd... Provázání překladu (hlavně chyb a warningů)  s editorem může být poměrně pohodlné - a zatím všechno co jsem viděl mimo IDE bylo maximálně skok na řádek, kde je chyba a její vypsání.. Jinak samozřejmě třeba ladění/krokování může být velmi užitečné a další funkce IDE můžou být užitečné, ale proti gustu žádný dišputát...

[Martin Mareš]

Například na zobrazování definice funkce vůbec nepotřebujete IDE, na to úplně stačí ctags a editor, který umí skákat podle tagů.

[Radek Hladik]

Přesně tak, nepotřebuju IDE, stačí projekt, který nabízí funkcionalitu v IDE běžnou. Na IDE mi právě vyhovuje to, že sjednocuje spoustu takovýchto funkcí do jednoho celku...

[Josef Kufner]

Do jednoho omezeného celku. Kombinováním specializovaných nastrojů lze získat daleko víc. Proto pojem IDE nemá v Linuxu smysl.

[Ladicek]

Co prosím? Občas mám pocit, že někteří lidi slovo IDE příšerně a snad i záměrně démonizují, i když jeho význam je prostý: integrované vývojové prostředí. To znamená, že všechno, co potřebujete pro vývoj, máte v jednom. První IDE, které si pamatuju, je Turbo Pascal blahé paměti – a v zásadě nevidím rozdíl mezi ním a vimkem, ze kterého jednou klávesovou zkratkou poušíte překlad, druhou debugger a třetí hledání výskytů identifikátorů přes ctags či kýho výra. Stejně tak spuštěný smalltalkovský image je IDE.

IDE není od toho, aby vám poskytlo bash, ve kterém si namlátíte kolonu grepů, sedů a dalších bazmeků, kterou upravíte haldu zdrojáků nějakým šíleným způsobem (a ono to pak možná půjde přeložit a možná to dokonce bude i fungovat), ale od toho, aby usnadnilo typické, často se opakující úkony. Čehož se právě dosahuje integrací všeličeho užitečného. A časté opakování stejných úkonů se vyskytuje při programování libovolným stylem v libovolném jazyce.

Osobně při programování kombinuju IDE (velká většina času) i shell (podstatně méně často, ale zase ne úplně výjimečně), protože každé má svoje výhody. A proto má pojem IDE smysl i v Linuxu, vzdor zděšeným staromilcům.

[Leoš Literák]

Delal jsi nekdy nejaky refactoring v projketu o vice nez par souborech?

[Messa]

Hm, nevím, občas něco někde zpřeházím, ale asi moc ne, nedělal.

S trochou nadsázky, čekám, až na nějakém zážitkovém webu vedle zážitků jako "čokoládová koupel", "na jeden den bagristou" bude i nabídka "vývoj a refaktoring Java EE projektu s miliony řádků v přední vývojářské firmě". Pak se teprve budu cítit programátorem.

[Leoš Literák]

Juu, to by se nasemu managementu libilo, aby programatori firme platili za moznost pracovat Kolik nabizis?

[Miloslav Ponkrác]

Dám sto tisíc a zároveň vezmu milión jako úplatek od konkurenční firmy, že Vaši položím efektivně do krachu.

[Martin Mareš]

Dělal a nemálo ... ale obvykle mi při něm daleko více než IDE posloužil sed, perl či nástroj typu Coccinelle.

[Miloslav Ponkrác]

Zkuste si tyhle věcí zrefaktorovat v C++ V pořádném zdrojáku s milióny řádků nabitý mnoha namespacy a šablonami. Každý z Vámi zmiňovaných nástrojů tam selže, nebo jejich použití a nastavení je pro tento případ tak složité, že je to k ničemu. Pro IDE ovšem žádný problém.

[Martin Mareš]

To možná vypovídá spíš o intuitivnosti syntaxe C++

Jinak nástroj typu Coccinelle by samozřejmě mohl s C++ fungovat výborně.

[Miloslav Ponkrác]

Intuitivnost syntaxe ničemu nevadí, spíše to vypovídá o tom, jak moc jsou regulární výrazy a jeho deriváty a snahu jít tímto směrem velmi nešikovné, dřevěné, nepraktické ve srovnání s běžnými specializovanými refaktorovacími nástroji obsaženými v IDE. Jsem si na 100% jist, že jakoukoli složitější a rozsáhlejší refaktorovací akci byste s Vaším Coccinelle dělal několikanásobek času co v běžném IDE. A to nemusíme ani mluvit o tom C++.

[Martin Mareš]

Vaši jistotu Vám neberu, nicméně ani nesdílím, alespoň pokud není podložena solidnějšími argumenty než "jsem si jist"

Naopak nevidím důvod, proč by Coccinelle a spol. nemohly být specializovanější a efektivnější než refaktorovátko zabudované v nějakém IDE.

[Miloslav Ponkrác]

Jednoduše proto, že Coccinelle nerozumí ani C++, ani Javě, ani řadě jazyků, zatímco IDE jim rozumějí. Už pro tisíce dalších features mají rozpársovaný projekt nejenom syntakticky, ale i s dalšími vazbami, a tudíž pro ně je velmi přirozené nad těmito informacemi provést refaktoraci.

Jinak Vy též nemáte žádné solidní argumenty, tedy kromě nenávisti k IDE. Na rozdíl od Vás jsem používal mnoho jak  IDE, tak i bez něho, zatímco u Vás velmi pochybuji, že máte nějaké větší zkušenosti s většími projekty nad IDE.

[Martin Mareš]

Já nehovořil o implementaci Coccinelle jako takové, nýbrž o principu, který je bez problémů aplikovatelný na většinu programovacích jazyků.

Jinak vůči IDE žádnou nenávist nechovám, pouze mám po létech experimentování se všemi možnými editory i IDE prakticky ověřeno, že v obyčejném Vimu s pár nástroji okolo pracuji daleko efektivněji. Důvod je prostý: daleko víc než refaktorizační nástroje potřebuji při programování solidní prostředky pro editaci textu a těmi jaksi IDE nevládnou.

(Na okraj: místo kritizování cizích zkušeností se raději chlubte svými; již dlouho pouze tlučete hubou, ale ještě jste nepředvedl jediný svůj program.)

[Filip Jirsák]

Důvod je prostý: daleko víc než refaktorizační nástroje potřebuji při programování solidní prostředky pro editaci textu a těmi jaksi IDE nevládnou.

Můžu se zeptat, které jsou ty „solidní prostředky pro editaci textu“? Já když si píšu v čistém textu poznámky (třeba z přednášky), potřebuju těch prostředků na editaci textu daleko víc, než při programování. Při programování si z „prostředků na editaci textu“ vystačím s kopírováním do schránky, přesouváním a kopírováním bloku, zakomentováním/odkomentováním bloku kódu a automatickým formátováním kódu. Všechno ostatní už jsou prostředky pro editaci zdrojového kódu, kde je užitečné, když editor „rozumí“ kódu (např. doplňování kódu, vyhledávání, šablony…).

[Martin Mareš]

Nejsou to žádné "killer features", spíš spousta užitečných drobností, o kterých si člověk uvědomí, jak moc mu usnadňují práci, až v okamžiku, kdy si po dlouhé době sedne k editoru, který je neumí.

Namátkově (žádný systematický seznam, spíš vzpomínám, co jsem včera při programování použil): smazání všeho až do párové závorky nebo až do nejbližšího výskytu daného znaku, přefiltrování kusu textu externím programem, skákání po mezerou oddělených slovech (vedle skákání po slovech oddělených nealfanumerickými znaky), formátování odstavců v komentářích, skoky na zapamatované značky, zvýrazňování mezer na konci řádků, makra. A samozřejmě perfektní ovladatelnost všeho z klávesnice (přehmatávání na myš je prostě moc pomalé).

Nejspíš pro každou takovou featurku najdete IDE, které ji má, ale zatím nevím o žádném, které by je mělo všechny najednou, nebo aspoň většinu.

Mimi to, velmi si na Vimu pochvaluji, že není vázaný na žádný konkrétní jazyk, takže mohu pohodlně najednou editovat zdrojáky v několika různých programovacích jazycích, dokumentaci napsanou v TeXu a maily. Zdrojákům samozřejmě také do jisté míry "rozumí", takže automatické odsazování rovněž funguje velice dobře, a co je hlavní, dá se zkonfigurovat tak, aby odsazovalo podle mých představ.

[Filip Jirsák]

Kdybych neznal historii téhle diskuze, nepoznal bych z toho výčtu, že je řeč o programování Hledání výskytu nejbližšího znaku, skákání po mezerou oddělených slovech – to používám při editaci běžného textu, ale při programování ne. Při programování jsou jednotlivé znaky na můj vkus příliš nízkoúrovňová záležitost, pro pohyb používám syntaktické jednotky jazyka (další výskyt stejného identifikátoru, skok na metodu, na implementaci v předkovi atd.). Když ve vimu mažu vše až do výskytu daného znaku, obvykle zjistím, že „daný znak“ se v textu mezi pozicí kurzoru a požadovaným místem nachází ještě několikrát, a musím pak hlídat, jestli ještě mazat nebo už to bylo správně. A to mi nějak nevyhovuje. Zapamatované značky většinou IDE umí jen postupně procházet, neumožňují jim přiřadit zkratku – což třeba mně vůbec nevadí, protože já IDE by si ty zkratky možná pamatovalo, ale já ne…

Pro mne je důležité, aby mi editor při psaní zdrojáku nabízel možnosti, které můžu v daném kontextu použít – názvy metod, proměnné dostupné v daném kontextu, názvy XML tagů podle schématu atd. Dál abych se mohl pohybovat po objektech daného jazyka – zobrazit seznam metod objektu a přejít na konkrétní metodu, vyhledat všechny výskyty použití metody, skok na předka nebo implementaci, procházení všech výskytů dané proměnné apod. Editace různých jazyků nebo přizpůsobení formátování považuju za samozřejmost, stejně jako ovladatelnost z klávesnice.

Když se to takhle popíše, vypadá to, jako by rozdíl byl v tom, že vy se hodně zabýváte jednou malou částí kódu, kdežto já se potřebuju ve velkém projektu rychle dostat z jedné části kódu na nějakou úplně jinou. Jenže takovéhle vysvětlení mi moc nesedí, protože třeba správci distribučních balíčků se evidentně taky potřebují rychle zorientovat ve velkém projektu a navíc v neznámém kódu, a nezdá se, že by preferovali IDE před vimem a grepem…

[Martin Mareš]

Já mám vyzkoušené, že většinu času trávím buďto přemýšlením (nejlépe s tužkou a papírem), nebo naopak poměrně lokálním editováním textu – jednou nějaké místo ve zdrojáku najdu a pak strávím několik minut tím, že ho edituji. Takže dokud nalezení příslušného místa trvá řádově kratší (byť ne optimální) dobu, dává smysl optimalizovat hlavně rychlost lokální editace.

Pro globální orientaci po zdrojáku daleko radši používám specializované nástroje pro statickou analýzu kódu (pro Céčko třeba cscope, cspot a sparse) a staré dobré ctags. Ale pokud nehackuji nějaký obří projekt, u kterého neplánuji zůstat dlouho, tak stejně vždy začínám tím, že si zběžně prolistuji všechny zdrojáky, abych měl základní přehled o tom, co jak funguje a kde to hledat.

Kontextové doplňování sice ve Vimu nemám (byť jsem svého času potkal i nějaký plugin, který se o něj stará), ale vlastně mi nijak nechybí. Všechno, co chci doplňovat, je stejně buďto v tag filu nebo v některém ze souborů, které mám zrovna v editoru otevřené, takže mi to Vim zvládne doplnit. Neumím si tak sice odpovědět na otázku "jaké metody má objekt, který mám zrovna pod kurzorem", ale to nepotřebuji nijak často. Spíš se mi hodí napsat začátek jména a nechat si ho doplnit – tam mi sice Vim zamíchá i jiné identifikátory, ale těch je obvykle natolik málo, že výrazně nepřekáží. Zde je občasné mírné nepohodlí bohatě vyváženo tím, že Vim reaguje na všechny příkazy naprosto bleskově.

Jak už jsem psal, genialita programovacího prostředí nespočívá v tom, jaké sofistikované featurky umí – každé prostředí umí +/- všechno, jen s jinou mírou drobné otravnosti. Mně se na Vimu líbí právě to, že pro mé účely má celkovou míru otravnosti velice nízkou.

Kde leží optimum, nejspíš také hodně záleží na tom, v jakých jazycích píšete. Jinak je to v Céčku, které má poměrně placatý prostor identifikátorů, jinak v jazycích, v nichž je zvykem každé jméno přetěžovat milionkrát, takže významy identifikátorů jsou zběsile zavislé na kontextu (tam se velmi hodí mít kontextové doplňování), ještě jinak v dynamicky typovaných jazycích (tam editor málokdy může kontext určit). Já jsem si zvykl pracovat buďto v Céčku (1. typ) nebo naopak v jazycích značně vyšších (třeba Perl a Haskell – 3. typ), o složitější projekt v C++ nebo Javě nezavadím moc často.

[Filip Jirsák]

Já se zase setkávám spíš s těmi projekty v Javě, kde "psaní kódu" znamená spíš výběr vhodných komponent a jejich funkcí a jejich správné poskládání. Na tom se moc editace neužije, tam je potřeba rychle vidět, jaké mám v tomto kontextu možnosti. Druhá věc je pak třeba sledování volání z mé aplikace přes knihovnu a přes framework až do JDK, kdy hlavně potřebuju dostat se hned na to správné místo a neprohledávat stovky zdrojáky na jméno metody, která se vyskytuje všude možně v kódu i v komentářích. V tomhle případě nemusí IDE ani moc fungovat jako editor, spíš ho používám jako takový hypertextový prohlížeč zdrojáků -- a v tomhle případě naopak zdržuje, pokud musí člověk i druhou rukou přehmatávat z myši na klávesnici. Dělat to metodou textového hledání v souborech jde taky, ale trvá to podstatně déle. A pokud už je potřeba opravdu vymyslet něco "nového", nejlepší editor je tužka a papír

[moira]

potřebuji při programování solidní prostředky pro editaci textu

Ja tedy vim skoro neznam a delam v Jave, ale co mas konkretne na mysli? Nemam ted pocit, ze by mi neco v editoru Eclipse chybelo, ale mozna mi to nechybi jen protoze o tom nevim... Jinak existuje i vim plugin pro Eclipse: http://vimplugin.org/

[rADOn]

Delal jsi nekdy nejaky refactoring v projketu o vice nez par souborech v jinem jazyce nez v jave?

[Jan Drábek]

Anjuta, Monodevelop

Se správnými pluginy pak Eclipse nebo Netbeans - u těchto programů se mi vyplatilo instalovat verze ze stránek, nikoliv distribučních repozitářů, to se pak objevovali zajímavé chyby, chovalo se to pomalu apod.

[pheeror]

da se to geany prekecat aby tam fungovala podpora auto-completion pro python?!

[YYY]

Ja pouzivam nur vim

[Daniel Kvasnička ml.]

U Eclipse a NetBeans plati ohledne Linuxu jedno zakladni pravidlo: obloukem se vyhni repozitarum distribuci (vsemozne "konfigurovane" ci v nekterych pripadech jeste mozna zkompilovane nejakym tim obskurnim JDKckem typu GNU Classpath...) a stahuj je rozvnou z oficialnich webu. Jinak plugin pro Eclipse na C/C++ je a to primo mezi oficialnimi zakladnimi komponentami.

[YYY]

Je Eclipse pro C/C++ rozumne pouzitelne?

[Jardík]

Ne. Je to v javě a je to pomalej šmejd, jako všechny GUI programy v javě.

[Daniel Kvasnička ml.]

Ja jsem v tom delal jen velmi kratce v C, takze moc radit nemuzu. Bylo to spis proto, ze jinak s Eclipsem delam v podstate od rana do vecera (JEE, PHP, web obecne) a nechtelo se mi resit nic dalsiho, kdyz jsem vedel, ze je to jen velmi vyjimecny exkurs do Ccka...

[Miloslav Ponkrác]

Eclipse používají javisté. Pokud jsou javisté občas nuceni sáhnout do C++, většinou za každou cenu chtějí používat Eclipse, protože jsou na něho zvyklí.

Profesionála v C++ jsem zatím nikde na světě Eclipse neviděl používat. Není to zřejmě příliš praktické.

[stativ]

Osobně používám jEdit a Eclipse*. jEdit používám na vlastní projekty (čti, vím jak jsou napsané a co kde hledat). Eclipse naopak používám pro vývoj větších aplikací které jsem nenapsal (čti hugin a občas enblend), kvůli pohodlnému vyhledávání dekladrací funkcí a na Javu, páč tu máme ve škole povinně a já ji jaksi neovládám natolik, abych znal všechny funkce, které potřebuji.

Oba dva programy jsou perfektně rozšiřitelné pomocí různých pluginů. Proto zde udělám menší výčet těch, které osobně považuji za nejužitečnější.

jEdit:

• Buffer tabs
• Console
• CSS editor
• Editor scheme selector (používám vlastní barvičky založené na zvýrazňování co bylo (je?) v PSPadu)
• LaTeX tools
• PHPParserPlugin
• Project Viewer

Eclipse

• CDT – samozřejmost
• Eclipsedocs – C++ reference
• CMake Editor
• Autotools plugin – na to, co je na linuxtools jsem nekoukal, používám verzi co jsem stáhnul z cvs odkazovaného z http://sourceware.org/eclipse/autotools/ (které nyní linkuje na linuxtools)

[BlackShark]

Já osobně používám už nějakou dobu NetBeans. Od verze 6.1 na Javu a C/C++ a od verze 6.5 i na PHP a Python. Start je sice delší, ale po doinstalovani pluginu module manager jdou nějaké věci povypínat a start je o dost rychlejší. Co se týče intuitivního ovládání přijde mi to naprosto v pořádku (třeba předevčírem jsem dělal chvíli ve VS a přišlo mi to takove všechno přes ruku, takže to je očividně pouze otázka zvyku).