Dotaz: Jaké prostředí pro JAVU pod Linuxem ?

[TomasABC32]

Zdravím, jaké prostředí mi doporučíte pro programování v JAVA pod Linuxem ? Klasicky Eclipse jako ve windows ??

Díky ?

---

---

Odpovědi

[Josef Kufner]

Ano. A nebo jakékoliv jiné, neboť snad všechny jsou napsané v Javě a va Linuxu běží také.

[Kit]

Vim.

[Matlák]

Teda já na programování v Javě vim používám, ale že bych to doporučil někomu kdo se tu ptá jako začátečník....

faktem je že výkonné IDE jako je Eclipse/Netbeans/IntelliJ je nebezpečné i pro uživatele-programátora, tím že ho naučí bezmyšlenkovitě kombinovat automaticky generované bloky kódu a číst a refaktorovat to pak po něm je fakt hnus.

Na druhou stranu bez IDE to začátečníka který Javě vůbec nerozumí bude z počátku fakt bolet. Ono holt už dnes není moc zvykem prostudovat si dokumentaci, znát návrhové vzory nebo alespoň příklady, uvědomovat si kritické situace... dneska se programuje stylem koukání se na instruktážní video, doplňování a doporučování postupů by-IDE a různým stylem zvýrazňování méně a více závažných chyb v kódu... řekl bych že většina těch kancelářských programátorů co používají IDE by bez podtrhávání a žároviček napovídajících jak to napsat "správně" trpěla..

[Kit]

Mně tedy Vim v Javě napovídá docela dobře, stejně jako v ostatních jazycích. Bloky kódu (stuby) mi také generuje podle odkazu na interface.

Bohužel dnešní IDE vyvolávají iluzi, že napsaný kód je v pořádku. Automaticky generované testy dělají jen to nejnutnější, aby se vlk nažral, někdy ani to ne. IDE ve své podstatě napáchají více škody než užitku, protože navádějí začátečníka k neobjektovému kódu - když ty gettery/settery se tak hezky generují...

Ano, práce ve Vimu vyžaduje naučit se pracovat nejen s jeho prostředím, ale hlavně s Javou jako jazykem a objektovým programováním jako paradigmatem. To však za nás žádné IDE neudělá.

[Matlák]

Doplňování se nebráním, ani generování hlaviček podle interface, i když i to může zjednodušit některé nepříliš čisté postupy.

Ale jsem rád, že mi vim neudělá žárovičku vedle volání co vyhazuje kontrolovanou výjimku a nenapoví mi že umí na jedno kliknutí vygenerovat try..catch se zalogováním pomocí generického loggeru, bez ohledu na kontext - ano i takový polodementní kód jsem nedávno opravoval... těžko říct jestli po příslušném programátorovi nebo po tom "chytrém" IDE..

[Kit]

Oznámení o kontrolované výjimce mi napíše kompilátor přímo ve Vimu a není problém tu výjimku zapracovat. Generování try..catch mi Vim také udělá, když mu to naznačím - stejně jako ostatní běžné řídicí struktury. Kdo si má furt pamatovat, jestli se ve switchi píše otherwise, else nebo default? Raději si to nechám generovat, i když takové větve stejně skoro vždy smažu.

Je lepší, když je v catch defaultně generováno logování, než aby tam nebylo nic. Vždycky se to dá opravit na něco smysluplného nebo na komentář "tady výjimečně neošetřuji výjimku, protože se mi to nehodí".

[dustin]

IDE ti to napíše hned po napsání metody, kompilaci samozřejmě vůbec spouštět nemusíš.

[Kit]

IDE si to zjistí pomocí kompilátoru stejně jako Vim. Rychlost je stejná.

[Filip Jirsák]

Tuhle argumentaci, že Vim je možné přestavěn na IDE, vůbec nechápu. Není lepší rovnou používat IDE?

[Kit]

Nesnažím se z Vimu udělat IDE. Pouze jsem si ho nakonfiguroval tak, aby vyhovoval mým potřebám. Pluginy na reflexi knihoven různých jazyků byly poměrně jednoduché a žádné IDE jich nemá tolik pohromadě, abych mohl mít v jednom panelu Javu, ve druhém Haml, ve třetím Fortran a ve čtvrtém Lisp.

[Fluttershy, yay!]

V IDE zase není textový editor…

[Filip Jirsák]

Což nevadí, protože v IDE se vyvíjí programy, nepíší se v něm texty.

[Fluttershy, yay!]

Pokud se za poslední dva dny něco radikálně nezměnilo, zdrojový kód a dokumentace programů (tím spíš v Javě) je pořád text, jehož části, které opravdu dělají něco užitečného (čehož je, pravda, v Javě malý podíl), se píší (potažmo přepisují).

[Filip Jirsák]

Jenže to psaní je ta z méně podstatných částí vývoje.

[dustin]

Možná by sis nějaké IDE měl otevřít. Rozhodně to není tak, že by IDE parsovalo chybové výstupy kompilátory. Zrovna nedávno o AST psal p. Tišňovský http://www.root.cz/clanky/analyza-a-transformace-kodu-psaneho-v-jave-s-vyuzitim-knihovny-spoon/

Před chvilkou jsem cca na 4 klávesy doplnil anotaci @Deprecated k přetížené metodě ve všech potomcích třídy (cca 10). Triviální věc, která se dělá běžně. Stejně jako velice užitečné anotace @Nullable/@Nonnull - prošíření se dělá takřka pořád, protože je legacy kód potřeba průběžně o tyto anotace doplňovat. Samozřejmě by na to nefungoval regulární výraz - stejný název metod se vyskytuje i u jiných tříd, které nejsou potomky.

Teď se dozvím, že při správném objektovém návrhu bych to nepotřeboval

Stejně tak jako jsem nedávno snadno editoval ve vimu několika GB sql dump s využitím pluginu LargeFile. Vše má své využití.

[Kit]

Tyto anotace mám na 2 klávesách.

Popis IDE je o kousek níže. Tady se probírá Vim.

[dustin]

Nemluvím o přidání anotací k metodě, ale k přetíženým/implementujícím metodám v potomcích/implementacích.

Vim místo IDE tady tazateli navrhuješ ty, ostatní to rozporují.

[Kit]

To přece vyjde nastejno.

Proč mi všichni rozporují Vim? Já tady jen odpovídám na vaše všetečné otázky a nesnažím se do vašich IDE rýpat. Však si používejte svá IDE, když vám vyhovují. Vim vám nevnucuji.

[dustin]

Jak nastejno? Přidám @Nullable do interfacu/kamkoliv a za sekundu je to prošířené i v deseti dalších souborech na správných místech (předci i potomci), připravené ke komitu. Pokud máš takové skripty pro vim (samozřejmě ne regulárními výrazy), klobouk dolů.

Dávám argumenty, proč si nemyslím, že je pro tazatele vim vhodné vývojové prostředí pro javu, tedy na co se ptal.

[Kit]

Regulárními výrazy se to jaksi dělat nedá...

[dustin]

Takže máš pro vim naimplementované AST? Jinak si nedovedu představit, čím jiným bys to mohl dělat. A nebo to jednoduše neděláš a zaprášený kód necháš být, jak je.

[Kit]

Pokud to potřebuješ tak nutně vědět, tak takové prasárny prostě nedělám.

[dustin]

Aha

[Kit]

Proč bych měl používat @Nullable a k tomu takovým způsobem? Spouštíš před commitem testy nebo se spoléháš, že "to nějak vyjde"?

[Filip Jirsák]

Posmívat se oponentovi má jisté riziko, když se ukáže, že nechápete, o čem se diskutuje – jako se to právě stalo vám. Anotace @Nullable a @NotNull/@Nonnull rozšiřují statický typový systém a určují, zda při daném použití typu může nebo nemůže být hodnota null. Některé jazyky tohle rozlišují přímo v typovém systému. Ostatně Java 8 z tohohle důvodu přišla s typem Optional, který tenhle problém řeší bez změny typového systému – a v ideálním případě by všechny @Nullable typy měly být nahrazeny Optional (což je s ohledem na zpětnou kompatibilitu nereálné). S testy to nemá nic společného, stejně jako statický typový systém nenahrazuje testy.

Představte si, že píšete nějakou knihovnu. Když nějaká metoda může vracet null hodnotu, oanotujete (pokud má být knihovna kompatibilní i s Javou 7) ji právě anotací @Nonnull. To, co označuje ta anotace, byste musel otestovat v kódu, který tu knihovnu používá (tam musí být ošetřen případ, kdy se vrátí null). Takže vaše otázka ve skutečnosti zněla – spouštíš před commitem do knihovny testy ve všech projektech, které knihovnu používají? To jste se ale zeptal pěkně hloupě, že?

[Kit]

Vím, co dělá @Nullable.

[Filip Jirsák]

Tak proč na to reagujete komentářem o testech?

[Kit]

Koukni se o pár řádek výše.

Přidám @Nullable do interfacu/kamkoliv a za sekundu je to prošířené i v deseti dalších souborech na správných místech (předci i potomci), připravené ke komitu.

Takto upravený text není připraven k commitu.

[Filip Jirsák]

Jenže tady se nediskutuje o tom, jestli tohle je nebo dostatečná příprava před commitem, diskutuje se o tom, jak snadné je takovou úpravu udělat a udělat ji správně.

A ani s tím commitem a testováním jste to netrefil správně, a to hned ze dvou důvodů. Za prvé, existuje jistá hierarchie kontrol správnosti kódu – začíná online statickou kontrolou při psaní, pokračuje statickou kontrolou ex-post (v prvním kroku kompilátor, v dalších krocích případné další statické analýzy kódu neintegrované v kompilátoru), dále dynamická kontrola kódu (jednotkové testy), integrační testy, funkční testy. Každé posunutí kontroly do vyššího patra znamená, že se na případnou chybu přijde později, bude náročnější ji opravit, každý takový posun znamená ústupek a vlastně volbu náhradního řešení. Třeba dynamické testy zkontrolují jenom ty části programu, které jsou testy pokryté a které se v testu vykonají, navíc dynamický test může být snadno ovlivněn vnějším prostředím (takže vývojáři test prochází, ale v jiném prostředí neprojde). Zrovna to zacházení s null hodnotami je výborný příklad – pokud programátor předpokládá, že nějaká hodnota nemůže být null, bude to samé předpokládat i u testů a nenapíše test, který by tohle kontroloval. Daleko lepší je, když se nullabilita kontroluje v rámci statické analýzy, kdy se zkontroluje veškerý kód bez ohledu na to,jakým způsobem se bude provádět. A ještě lepší samozřejmě je, když programátor už během psaní jasně ví, zda daná hodnota může nebo nemůže být null – protože na tom nezávisí jenom kód (který kontroluje kompilátor nebo jednotkové testy), ale také algoritmus. A když teprve dodatečně zjistí, že tam vlastně může být i null hodnota, může se stát, že opraví kód, ale neopraví program.

Za druhé, spouštění testů je v té hierarchii čím dál nákladnější, ale zároveň je potřeba, aby všechny ty testy proběhly před tím, než se kód dostane někam dál. Proto se spouští různé testy automaticky před nebo po commitu a na různých repository. Takže nezmiňovat testy před commitem není nic špatného, protože to závisí na pravidlech daného projektu a s commitem to přímo nesouvisí. Integrační a funkční testy se obvykle spouští až po commitu nad nějakým centrálním repository, takže není vůbec neobvyklé, že testy proběhnou až po commitu. A i spouštění jednotkových testů může být s commitem nějak svázané, např. že se testy spustí automaticky před commitem – a pak je zbytečné spouštět je předtím ještě jednou ručně, je to jen ztráta času.

[Kit]

Stačilo napsat, že IDE spouští jednotkové testy automaticky před každým commitem.

[Filip Jirsák]

Může. A nemusí. Podstatné je ale to, že to s diskusí nijak nesouvisí.

[Kit]

Tak proč se k tomu vyjadřuješ, když to s diskuzí nijak nesouvisi? Tvé argumenty jsou prostě irelevantní.

[dustin]

Tyhle anotace samy o sobě nedělají vůbec nic. Je to ale velice užitečný hint pro API a hlavně pro IDE, které pak vývojáře rovnou upozorňuje, zda je použití korektní. Typicky chybějící/či naopak zbytečná kontrola na null. Samozřejmě to umí jen v jednodušších případech, takže se na to nedá spoléhat, ale i tak se již při psaní ušetří spoustu času. Hlavním přínosem je upřesnění definice API pro vývojáře.

Nicméně původně nešlo jen o tyto anotace, ale o všechny, které je potřeba prošířit v rámci stromu dědičnosti - @Override, @Deprecated, atd.

Pro mě je prasárnou tyto anotace nepoužívat v novém a postupně při každé příležitosti nepřidávat do legacy kódu.

[Kit]

Pro mne je prasárnou takové anotace přidávat hromadně.

[dustin]

Prasárna je nedat je tam vůbec. Samozřejmě u Nullable/Nonnull před přidáním vím, co jednotliví potomci dělají a zda anotaci dodržují. Mimochodem v IDE to zjistím daleko rychleji, než ve vimu, protože skáču rovnou na implementace v potomcích.

U Override/Deprecated to vůbec nemusím řešit a jsou úplně stejně důležité.

[Filip Jirsák]

To „hromadné“ přidání spočívá v tom, že IDE analyzuje kód a navrhne – když je ta anotace tady, měla by být i na těchto dalších místech. Programátor se na ten seznam podívá, vyloučí případné návrhy, kam anotace nepatří, a které ošetří jinak, a nechá změnu aplikovat. Co přesně je na tom špatně? Jak jinak byste to chtěl dělat? Hledat ty související místa ručně a doufat, že na něco nezapomenete? V čem přesně by to ruční hledání bylo lepší, než když to na základě analýzy kódu udělá IDE?

[Kit]

Vim má tyto nástroje k dispozici také a umí ta související místa najít a automatizovaně modifikovat. Jen takové nástroje používám s rozmyslem.

[Filip Jirsák]

Takže jediný rozdíl je v tom, že do Vimu si ten nástroj musím najít a doplnit, případně integrovat s ostatními nástroji, v IDE už to mám hotové (ostatně proto je to IDE a ne DE). Používat to s rozmyslem je nutné vždy, v tom se IDE a Vim nijak neliší.

[Filip Jirsák]

Pořád tu ale nepadla odpověď na tu základní otázku: Proč bych se měl pracně pokoušet udělat z Vimu nedokonalé IDE, když můžu použít nějaké již existující IDE?

[Kit]

Ale já ti Vim nevnucuji. Nemusíš to dělat.

[Filip Jirsák]

Tazatel se ptal na programování v Javě. A k tomu je Vim dost nevhodný nástroj. Vim se dá v nouzi použít pro psaní kódu. Vim se spoustou doplňků může někdo použít pro programování v Javě, ale bude to jen vzdálené přibližování se vlastnostem, které má každé hloupé IDE. Někdo to tak může z nějakého důvodu používat, já mu to neberu, ale měl by být natolik soudný, aby věděl, že je nesmyslné něco takového doporučovat na dotaz na programování v Javě. Lidé dělají různé šílenosti, jezdí s Trabantem po Africe, na kole z Prahy do Bombaje nebo programují Javu ve Vimu, ale když se někdo zeptá, jak má cestovat po Africe, jak se má z Prahy dostat do Bombaje nebo v čem má programovat Javu, jsou Trabant, kolo a Vim nesmyslné odpovědi.

[Kit]

Tazateli jsem odpověděl, že jednou z možností je Vim.

[Filip Jirsák]

Jenže tazatel se obvykle neptá na možnosti, těch si nejspíš sám dokáže vymyslet milion. Obvykle se spíš ptá na doporučení, na to, jaké nástroje jsou vhodné – a Vim mezi obecně vhodné nástroje pro programování v Javě nepatří. To, že někdo programuje Javu ve Vimu a někdo jiný zase v Notepadu je fakt, proč to tak dělají je jejich problém, ale doporučovat to někomu jinému a tvářit se, že je to vhodný nátsroj, je jen hloupá póza.

[Fluttershy, yay!]

Uh.

[Kit]

To je jen tvé tvrzení, že Vim mezi vhodné nástroje nepatří. Nehraj si na cenzora.

[Filip Jirsák]

Na jakého cenzora?

Že Vim mezi vhodné nástroje pro vývoj v Javě nepatří je zatím jediný výstup z téhle diskuse. Výhody Vimu oproti IDE při vývoji v Javě tu nenapsal nikdo žádné, na příklady toho, co IDE umí, je naopak častou reakcí to, že by to Vim umět také mohl nebo že to umí, když se něco doinstaluje a dodělá. Což je pro mne nevýhoda, protože od programátora chci, aby vyvíjel program, ne sháněl pluginy do Vimu.

[Kit]

No a proč se v tomto tématu angažuješ, když ve Vimu dělat neumíš?

[Filip Jirsák]

Já ve Vimu dělat umím a používám ho. Ale na věci, na které je Vim vhodný. Na to, abych věděl, že je Vim nevhodný na programování v Javě, mi stačí tvrzení lidí, kteří takhle Vim používají, jako vy – kteří z fleku vyjmenují spoustu nevýhod a výhodu ani jedinou. Nebo vás snad někdo do toho jmenování nevýhod tlačil a neměl jste příležitost napsat jedinou výhodu? Tak to napravte a nějakou výhodu Vimu napište.

[Kit]

Výhod Vimu jsem už vyjmenoval dost. Stačí si je jen přečíst.

Za jednu z hlavních považuji, že na veškeré programování mohu používat jediný editor, na který jsem zvyklý a který používám od doby, kdy tady ještě IDE nebyla. Má všechno, co ke své práci potřebuji. Propojení Vimu s kompilátorem či interpretrem mu dává podobné schopnosti jako uváděná IDE. Jen se s nimi pracuje jinak.

Vim má vlastní makrojazyk, který je 10. nejrozšířenějším jazykem a který je objektový. Je v něm napsána celá konfigurace pro asi 500 programovacích a jiných jazyků. Konfigurace se dá snadno verzovat a distribuovat.

Spuštění Vimu je řádově rychlejší, než spouštění IDE. Typicky se jedná o zlomky sekundy. Pro mnohé programátory nepodstatné, ale pro mne důležité.

Důležité je i propojení Vimu s operačním systémem. Pokud tedy potřebuji provést nějaký netriviální úkol, např. konvertovat HAML do XML, XML do HTML či JSON, zavolám si přímo v editoru externí službu, která mi to provede na definovaných řádcích. Stejně jednoduchý je import výsledku databázového či http dotazu.

Silnou zbraní Vimu jsou regulární výrazy, které jsou jinými uživateli obvykle podceňovány.

Považuji za důležité, že Vim nemá kolem sebe žádná tlačítka ani nějaké pull-down menu. Vše je soustředěno do jednoho příkazového a jednoho stavového řádku. To přispívá k hygieně při práci.

[Filip Jirsák]

Předpokládal jsem, že je jasné, že se ptám na výhody Vimu při použití místo IDE – aby to opravňovalo doporučovat Vim místo IDE. Ptal jsem se a něco, co by vyvracelo mé tvrzení, že Vim obecně na vývoj v Javě vhodný není.

Za jednu z hlavních považuji, že na veškeré programování mohu používat jediný editor, na který jsem zvyklý a který používám od doby, kdy tady ještě IDE nebyla.

To, že jste na Vim zvyklý, je subjektivní věc, rozhodně to není platné všeobecně.

Má všechno, co ke své práci potřebuji.

Opět subjektivní tvrzení, které navíc nejspíš platí proto, že toho nepotřebujete mnoho.

Propojení Vimu s kompilátorem či interpretrem mu dává podobné schopnosti jako uváděná IDE.

No, ta podoba je velmi velmi vzdálená. Navíc aby to opravňovalo doporučovat Vim místo IDE, ty schopnosti by musely být alespoň srovnatelné, ne-li lepší.

Vim má vlastní makrojazyk, který je 10. nejrozšířenějším jazykem a který je objektový.

Pluginy do Idey, NetBeans i Eclipse se píšou v Javě, tedy přesně v tom jazyce, o kterém se tu bavíme. Takže se nemusím učit druhý jazyk.

Je v něm napsána celá konfigurace pro asi 500 programovacích a jiných jazyků.

Nějak nevidím tu výhodu, že kromě jazyka, o kterém je řeč, podporuje ještě 499 jiných jazyků.

Konfigurace se dá snadno verzovat a distribuovat.

Konfigurace Idey a NetBeans jsou XML soubory, konfiguraci Eclipse myslím properties soubory. Také se dají snadno verzovat a distribuovat. A mimochodem se to i využívá. Viděl jste nějaký Java projekt, který by měl sdílenou konfiguraci Vimu? Nebo je to spíš tak, že Vim používají jednotlivci, používají ho po svém a každá taková instalace Vimu vypadá úplně jinak?

Spuštění Vimu je řádově rychlejší, než spouštění IDE. Typicky se jedná o zlomky sekundy. Pro mnohé programátory nepodstatné, ale pro mne důležité.

Tady jste to rovnou sám napsal, že je to vaše subjektivní hodnocení, které pro ostatní není důležité. Mimochodem, během toho zlomku sekundy Vim stihne udělat i analýzu kódu a vše zaindexovat, takže vám dokáže okamžitě po spuštění třeba napovídat názvy metod a parametry? Možná kdybyste používal nějaký vhodnější nástroj, nemusel byste ho tak často ukončovat a pak by vás nezajímalo, jak dlouho startuje…

Pokud tedy potřebuji provést nějaký netriviální úkol, např. konvertovat HAML do XML, XML do HTML či JSON, zavolám si přímo v editoru externí službu, která mi to provede na definovaných řádcích. Stejně jednoduchý je import výsledku databázového či http dotazu.

Ve zdrojácích Javy, které jsem viděl, se naštěstí kusy HAML, HTML, XML nebo JSON přímo v Java kódu vyskytují minimálně, a naneštěstí tam bývají obalené Java kódem, takže použít rovnou řádky ze souboru je nemožné (protože to nebude třeba XML, ale XML s uvozovkami, středníky a plusy navíc). Takže zavolat přímo tu externí službu by bylo k ničemu. A když už bych něco takového potřeboval provést, mám k dispozici schránku. Spíš se ale v takových projektech vyskytují samostatné HAML, HTML, XML nebo JSON soubory, a s těmi mohu zase v IDE normálně pracovat stejně jako s Javou. A samozřejmě na nich mohu zavolat i externí služby. Chápu, že pro vás je to velká výhoda Vimu, protože bez toho by to byl jenom dobrý editor a vývojové prostředí by z toho udělat nešlo. Ale porovnávat to s IDE je směšné – vždy IDE jsou právě od toho, abych externí nástroje používat nemusel a měl vše, co potřebuji k práci, integrované v jednom programu. Tak, abych to mohl používat všechno stejně, abych to mělo snadno dostupné.

Silnou zbraní Vimu jsou regulární výrazy, které jsou jinými uživateli obvykle podceňovány.

Což ovšem nijak neodlišuje Vim od IDE. Čím se naopak IDE liší, je to, že ty regulární výrazy můžu použít i kontextově – třeba hledat ve všech změněných souborech nebo ve všech souborech testů, které mají příponu .java, a můžu hledat třeba jenom v komentářích nebo ve stringových literálech (nebo naopak mimo ně).

Považuji za důležité, že Vim nemá kolem sebe žádná tlačítka ani nějaké pull-down menu. Vše je soustředěno do jednoho příkazového a jednoho stavového řádku. To přispívá k hygieně při práci.

Opět nic, čím by se Vim odlišoval. Naopak, IDE těch režimů práce podporují víc a umožňují mezi nimi snadno přepínat – od toho vašeho módu, kdy mám fullscreen textový editor a nic kolem, až po editor zarámovaný ze všech stran různými panely, které klidně můžu vzít a přetáhnout na vedlejší monitor.

Jinak Vim je skvělý editor třeba když potřebuju oeditovat nějaký konfigurák vzdáleně na serveru. Ale myslím, že mu dělají medvědí službu ti, kteří jej doporučují jako vývojové prostředí pro běžné jazyky, které jsou podporované IDE – a kteří, když mají napsat, jaká je výhoda Vimu při takovém použití, vyjmenují pár subjektivních výhod a pak několik věcí, ve kterých je Vim stejný nebo horší než IDE.

[Kit]

Zrovna ten HAML používám k tomu, abych napsal XML konfiguraci. Originální soubor mě pak už nezajímá, proto ho ani nevytvářím. Takže přímo do XML napíši kus v jazyku HAML a ten kus on-line zkonvertuji do XML. Tím se z toho opět stane monolitický XML. Podobným způsobem píši XSLT v Lispu - originál mě pak už nezajímá, podstatný je ten XSLT.

Zdrojáky na serveru edituji poměrně často, takže i na to se mi Vim hodí.

[dustin]

Líp bych to nenapsal :)

[ttt]

Disclaimer: na Javu používám Eclipse, na ostatní vim

Používat vim na všechno má své výhody. Ale doporučovat ho někomu, kdo se zeptá na IDE, je hloupost. Nikdo nezačne s vimem tak, že ho nainstaluje a nakonfiguruje tak, aby se dal rozumně používat pro Javu - je tam příliš velká vstupní bariéra. Navrhnout ho bez dalšího komentáře... působí to na mě jako snaha všem oznámit, že Kit používá vim. A jsem vegan, jen tak mimochodem.

Jako výhody vimu vidím:

• Jeden editor na všechno. Mám ho pak lépe nakonfigurovaný než IDE, pokud píšu v Javě, v Ruby, sem tam něco v C nebo pythonu. Ovládání editoru - v IDE typicky jde nastavit vim-mapping, ale dokonalé to není. Ale dost dobré na to, aby se to dalo používat, ano.
• Možnost vytvořit/změnit jednoduché skripty/pluginy. Když něco funguje jinak než se mi líbí, dokážu to upravit. Upravování pluginů do IDE taky jde, ale není to (aspoň pro mě) tak přímočaré. Např. v eclipse mě irituje searchpattern pro otevírání souborů - používá camelcase matching, což mi nevyhovuje, raději mám "Approximate string matching. Ale změnit to v eclipse mi přijde natolik složité, že se to toho nepustím. I když Javu oproti VimScriptu považuju za výhodu...
• Vybrané příkazy/pluginy souvisejících s psaním textu
• Rychlost

Z druhé strany - proč bych měl používat IDE a ne vim? Většinu času trávím tím, že píšu nebo upravuju kód. Tedy potřebuju, aby se mi dobře psalo, informace od kompilátoru, automatické doplňování, refactoring, přeskakovat mezi soubory, pár dalších věcí. Pokud tohle dokáže vim srovnatelně s IDE, pak pro mě začnou být důležité věci psané výše a zvažuju, jestli další výhody, které IDE poskytuje, vyváží výhody "domácího prostředí". Většinu z toho, co IDE poskytuje, nevyužiju a může být důležitější, že se mi pohodlně píše text/kód.

Pro C/C++ (když jsem to zkoumal, dlouho tomu jest) jsem nenašel IDE, které by v reálném čase (bez kompilace) pracovalo s AST. Výstup kompilátoru se většinou jen vypsal místo do terminálu do nějakého okna, podpora pro refaktorování omezená nebo žádná. Našeptávat uměl vim stejně dobře. Pro dynamické jazyky podobně, i když tam už se možná situace změnila díky IntelliJ. U javy to bylo složitější, IDE mají refactoring na dobré úrovni, doplňování, statická analýza kódu, do vimu jsem to na srovnatelné úrovni nedostal. Nejblíž byl eclimd (eclipse server, kterému vim posílá dotazy), ale byl příliš pomalý na používání. Tedy používám IDE.

Můj ideál by bylo IDE, které by podporovalo vše, co používám ve vimu. Takové ale bohužel není, proto musím volit kompromis. Dokážu pochopit, že pro někoho jsou výhody vimu větší než to, co poskytne IDE. Ale doporučovat vim jako IDE mi přijde mimo.

[Filip Jirsák]

Tohle bych klidně podepsal.

Jenom bych upřesnil tu práci s AST bez kompilace – ono je nejlepší, když AST vytváří právě cílový kompilátor. Eclipse k tomu dříve používalo svůj vlastní kompilátor (nevím, zda dnes už pro to umí používat i implementaci od Oracle, kterou používá javac), což způsobovalo komplikace u některých složitějších konstrukcí s generikami. ejc je dokázal přeložit, ale javac hlásil, že některé typy nedokáže odvodit.

Jinak JetBrains má nové IDE pro C a C++ – CLion. Pokud JetBrains udržel úroveň, na jakou jsme zvyklí z jiných jejich IDE, mohlo by to být zajímavé.

[Kit]

Díky za tento koment.

[Filip Jirsák]

Jestli to chápu dobře, kód vygenerovaný IDE je špatně, ale ten samý kód vygenerovaný skriptem ve vimu je v pořádku?

[Kit]

Kvůli generování kódu nepotřebuji natahovat složité IDE, což v mnoha případech (na pomalé lince) ani nejde. Pokud IDE dokáže generovat kód stejně jako Vim, je to jedině dobře.

[Filip Jirsák]

Ne, IDE dokáže generovat kód daleko lépe, než Vim. Nevidím jediný důvod, proč programovat přes pomalou linku – na celém programování je nejdražší čas programátora, takže všechno ostatní přizpůsobím tomu, abych tím časem neplýtval. Navíc nevím, co si mám představit pod tím „natahovat IDE po pomalé lince“ – to IDE je nainstalováno vzdáleně a já ho spouštím lokálně, takže se musí přenést spustitelné soubory? Na tohle bude Vim samotný menší, jenže vy k němu potřebujete přenést ještě kompilátor, linker, spoustu pluginů…

[Kit]

Vim, kompilátor, linker a pluginy spouštím také vzdáleně. Na terminálu nemám skoro nic, jen klienta SSH.

[Filip Jirsák]

Takže start IDE pomalá linka nijak neovlivní. Problém bude s GUI, a ten bude u IDE úplně stejný, jako u Vimu, protože se pořád musí přes síť nějak přenést ty obrázky. Textový Vim neuvažuji, protože ten nedokáže zobrazit ty samé informace, jako IDE.

[Kit]

Jaké obrázky? Používám textový Vim. Jinak bych psal o GVimu.

[Matlák]

Problém je že chytré IDE (a ano i "vytuněný" vim se za takové IDE dá považovat) člověku možňuje psát kód bez soustředění. Když si člověk neuvědomuje kontext a sází úpravy podle nápověd IDE dokud se mu kód nerozběhne je nebezpečný sobě i ostatním.

U vimu člověk nějak předpokládá že si tímhle prošel a ví co se dělat nedá, na druhou stranu moderní IDE člověk bez zkušeností snadno nainstaluje, otevře zdroják a pak už jen může klikat... a dělat spoušť. Ať už jsou to hromadné úpravy nad velkým množstvím souborů (se kterými současně pracuje někdo z lokálního nebo vzdáleného týmu), nebo automaticky doplněné kusy kódu které "spraví" kód pro kompilátor a pro jednoduchý test, ale tím jen vytvářejí časované bomby z složitějších situací, kterých by si IMHO člověk při ručním studiu situace měl všimnout hned (například když ten kód hned na následujícím řádku nebo (horší situace) o něco později spadne na úplně jiný problém když vlákno tu výjimku zaloguje a s klidem pokračuje v nedefinovaném stavu).

[Kit]

Ve větvi catch si nechávám vygenerovat výpis zásobníku, aby tam bylo alespoň něco. Kdybych na to zapomněl, tak mě na to test hned upozorní. Horší by bylo, kdybych tu větev nechal prázdnou. Ještě by se tam dalo vygenerovat TODO, ale to by se při běhu neprojevilo a test by nemusel spadnout.

[Filip Jirsák]

To, že se člověk nemusí soustředit na práci s editorem, a místo toho se může soustředit na kód, je výhoda IDE. Povídačky o tom, jak nějaké IDE samo opravuje kód, aby šel zkompilovat nebo prošel jednoduchým testem, a programátor vůbec netuší, co se děje, jsou prostě jenom povídačky. Pokud někde jsou testy pokrývající jednoduché možnosti ale ne krajní případy, je to problém těch testů, ne používání IDE. IDE naopak umožňuje programátorovi používat různé pohledy na program, podle toho, jaký zrovna potřebuje pro vyřešení daného problému. Ostatně, z programování bez zkušeností, s vytvářením časovaných bomb a bez porozumění toho, co člověk dělá, jste naopak sám usvědčil uživatele Vimu – protože jste za to nejdůležitější (jediné, co má smysl zmínit) označil psaní kódu. Což je přitom na programování ta nepříliš podstatná část. Podstatné je pochopit, co program dělá a co by měl dělat – i takové čtení kódu je důležitější, než jeho psaní.

[Matlák]

i takové čtení kódu je důležitější, než jeho psaní.

Samozřejmě že čtení kódu je důležitější. Ale když IDE člověku vygeneruje co je třeba, stačí přitom klikat na žárovičky a podtržená slova a mačkat dokola dve-tři zkratky, hrozí že právě ten kód číst nebude. Neříkám že je to jen o IDE, ale faktem je že jsem takový kód (po člověku co je klikačem v IDE) opravoval a stačilo se na to podívat z vyšší perspektivy než kterou to IDE nabízelo (a teď opravdu mluvím o přehledu se zelenými fajfkami a o vyskakujících nápovědách přímo v kódu) a hned se ukázalo že ten kód byl naprosto špatně. A myslím si (ale v tom se možná mýlím) že dotyčnému by stačilo mu tyhle obezličky vypnout a donutit ho tím aby přestal zběsile "psát" (klikat) a začal konečně kód číst a chápat, protože by mu nic jiného nezbývalo.

[Filip Jirsák]

stačí přitom klikat na žárovičky a podtržená slova a mačkat dokola dve-tři zkratky

Nestačí. To je pouze nesmyslný argument, který si vymysleli lidé, kteří IDE nepoužívají. V reálném světě nic takového použít nejde.

stačilo se na to podívat z vyšší perspektivy než kterou to IDE nabízelo

Ano, je vidět, že IDE nepoužíváte.

A myslím si (ale v tom se možná mýlím) že dotyčnému by stačilo mu tyhle obezličky vypnout a donutit ho tím aby přestal zběsile "psát" (klikat) a začal konečně kód číst a chápat, protože by mu nic jiného nezbývalo.

Ano, v tom se mýlíte, protože s IDE nemáte žádné zkušenosti. Mimochodem, ty nápovědy se pořád aspoň týkají kódu, takže nutí dotyčného přemýšlet o tom kódu. Což je pořád lepší, než když se dotyčný musí soustředit hlavně na to, jak má Vim vůbec ovládat, a samotný program je někde na okraji jeho zájmu.

[Matlák]

Sorry ale v tomhle případě to vyjde nastejno. Pokud kódu rozumím, nemusím číst nápovědy co mi říkají jak řešit nějakou chybu při kompilaci. Pak jsou mi ty nápovědy na nic. Naopak, pokud nějaký ten pátek používám vim, nemusím přemýšlet o tom jak se ovládá.

A máte pravdu, IDE se vyhýbám a programy dělám "postaru" (čtu dokumentaci, čtu cizí kód, pak píšu svůj). A opravdu jsem se setkal s kódem psaným začátečníkem ve výkonném IDE, a věřím že většinu těch složitých a nepřehledných konstrukcí v něm (a prázdných hlaviček s komentáři How to change generated methods... meh) by ten člověk bez IDE nenapsal. Možná by ten kód byl potom přehlednější. A nebo by možná nebyl vůbec. Pořád lepší než ten hnus co jsem opravoval celé dny.

[Filip Jirsák]

Pouze znovu dokazujete, že s IDE nemáte zkušenosti. Takže vaše dohady o tom, co mohlo nebo nemohlo způsobit použití IDE, jsou jen ničím nepodložené dohady.

nemusím číst nápovědy co mi říkají jak řešit nějakou chybu při kompilaci

Nápovědy, jak řešit nějakou chybu při kompilaci, vám dává i gcc – a čím lepší nápověda, tím lepší kompilátor. Podstatou nápověd IDE ale nejsou chyby při kompilaci (nepamatuji si, že by mi IDE v takové situaci dávalo jinou nápovědu, než kompilátor), nýbrž upozorňování na nestandardní věci v kódu (na což upozorňují varování kompilátoru) a případně návrhy na změny v kódu.

A nebo by možná nebyl vůbec.

Ano, to je velice pravděpodobné.

Pořád lepší než ten hnus co jsem opravoval celé dny.

To je ale čistě vaše chyba, nesvádějte to na IDE. Začátečník se nejprve musí naučit programovat, vy jste to také neuměl od narození. Když ten kód opravíte za něj, nic se nenaučí. Máte mu vysvětlit, co je na kódu špatně a jak to má opravit, a nechat ho, ať to opraví sám. Tak se to naučí nejlépe. Stejně tak ho máte odkázat na někoho, kdo ho naučí, jak si nakonfigurovat IDE (pokud pro to není projektový standard). Ty komentáře „How to change generated methods“ totiž svědčí o jediném – že to IDE nemá nakonfigurované. Není se čemu divit, když ho má vést někdo, kdo s IDE nemá zkušenosti.

[Matlák]

Není se čemu divit, když ho má vést někdo, kdo s IDE nemá zkušenosti.

K tomu jen dodám, že já jsem ho nevedl. Vedl ho jiný IDE maniak-manažer který sice své IDE nějak nakonfigurované a přizpůsobené má (ty komentáře "How to..." mu to generuje ale on je maže ručně kupříkladu), ale jemu to nějak zapomněl říct. Ten začátečník pak odešel (asi z frustrace) a já po něm přebral "rozdělané" věci...

Jinak uznávám že nenakonfigurovaný a nepřizpůsobený vim je určitě těžší překážka pro typického začátečníka (typu používá Windows a Javu viděl ve škole) než nenakonfigurované a nepřizpůsobené IDE. A za nebezpečné považuju spíš ty návrhy na změny v kódu než chyby kompilátoru které si bez ohledu na to jaké prostředí používám stejně přečtu. Protože IDE nemůže logicky vědět co po tom programu chce programátor, ať si je sebechytřejší. Možná jednou takové IDE vznikne ale pak už nebude třeba programátor

[Filip Jirsák]

Kdybyste znal nějaké IDE, tak byste věděl, že ty návrhy jsou odstupňované, je to mnohem víc stupňů, než jenom chyba či varování, které dává kompilátor. Některé návrhy jsou typu „tenhle kód je legální a může to být správně, ale většinou je to chyba“ – takovým návrhům by měl programátor vždy věnovat pozornost a něco s nimi udělat. Většinou je to opravdu chyba (typu přiřazení místo porovnání v ifu, pokud to daný jazyk umožňuje), a pokud není, měl by kód upravit tak, aby bylo jasné, že jde o záměr (čímž obvykle zmizí i to upozornění IDE). Ta úprava se nedělá kvůli IDE, ale kvůli programátorům, kteří ten kód budou číst později, a viděli by tam stejný problém, jako to IDE. Další stupeň návrhů jsou návrhy, jak ten kód napsat alternativním způsobem ale ekvivalentně ke stávajícímu. Třeba otočit podmínku ifu a prohodit větve if a else, přepsat for cyklus na for-each apod. To už není nic, co by programátor měl nějak řešit, prostě je to jenom nápověda, že se to dá napsat i jinak, a když budu chtít, tak to můžu použít. Pokud by programátor pracoval vámi popsaným způsobem, tak se u těchhle návrhů zacyklí, protože když nechá předělat for na for-each, IDE mu nabídne, že by se to dalo udělat i pomocí foru a nabídne reverzní změnu. To, že se takhle žádný programátor nezacyklil, je dobrý protipříklad k vaší představě, že uživatelé IDE jsou takoví matláci, kteří klikají na všechny návrhy IDE, dokud to jde. No a poslední návrhy jsou návrhy na významové změny kódu. Třeba někdo napíše if, dovnitř dá dvacet řádek významového kódu, a za ifem nebo v else je jednořádkové ošetření nestandardní situace vrácením defaultní hodnoty. Čitelnosti programu prospěje, když se podmínka otočí, rovnou se vrátí defaultní hodnota, a pak kód na nejvyšší úrovni pokračuje těmi dvaceti řádky významového kódu. Otočit tu podmínku samozřejmě můžu ručně, abych si procvičil booleovské operace a zkrácené vyhodnocování, a nebo to můžu nechat na dva stisky kláves udělat IDE. Opět, pokud takovéhle návrhy IDE programátor bez přemýšlení aplikuje, má nadosmrti co dělat, navíc bude měnit význam kódu.

Protože IDE nemůže logicky vědět co po tom programu chce programátor, ať si je sebechytřejší.

Co po tom programu chce programátor má být právě napsané v tom kódu. Když je to napsané tak srozumitelně, že to chápe i IDE, je docela slušná šance, že to budou chápat i ostatní programátoři, že to bude za půl roku chápat sám autor, a že v tom kódu je napsané opravdu to, co si autor myslí, že tam napsal. Moje zkušenost je taková, že když IDE napovídalo divně a vypadalo to, že nepochopilo, co programátor chce, velice často to bylo tak, že programátor napsal něco jiného, než co napsat chtěl.

[Kit]

Kdybys znal vim, zjistil bys, že píšeš o ptákovinách.

Umí třeba IDE eliminovat všechna "else"? Ve Vimu to není žádný problém.

Vždy vím přesně, kdy mám použít for a kdy for-each. Do toho mi IDE nemusí kecat.

[Filip Jirsák]

Umí třeba IDE eliminovat všechna "else"? Ve Vimu to není žádný problém.

Samozřejmě, že to umí. A doporučuji nevytahovat tady všech pět kontrol a návrhů, které Vim umí, protože IntelliJ Idea jich umí stovky. Takže když vytáhnete jednu a zeptáte se, zda to IDE umí, uživatele IDE takový dotaz rozesměje a nejprve nepochopí, že ten dotaz myslíte vážně. Protože uživatel IDE má lepší věci na práci, než procházet konfiguraci IDE a učit se nazpaměť ty stovky kontrol a návrhů, které IDE nabízí.

[Matlák]

BTW ta nedávná ošklivá srážka s nesoustředěným programátorem ozbrojeným výkonným IDE byla ostatně jediný (asi dost iracionální) důvod proč jsem Kitův trollí příspěvek nakrmil.

[Andrej]

Říkám si: Ale ouha! Pod takovým trollovským příspěvkem o pseudoeditoru určeném pro roboty bude určitě nejdelší a nejméně konstruktivní diskusní vlákno.

A taky že jo. Jak jinak.

Sorry, ale vim prostě nic neumí. Možná umí prudit uživatele tím, jak jde naschvál proti intuici a jak je navržený kolem memorování nesourodých shluků písmen. Ve srovnání s Eclipse nebo IntelliJ (kam asi tazatel mířil) je vim prostě k hovnu. Proto mi nějak nedochází, jaký má takové doporučení vlastně smysl.

Mimochodem, jak ve Vimu zapnu auto-completion, která zná typy, balíčky a třídy a která zobrazuje JavaDoc (nebo jiný Doc, podle jazyka)? Fakt by mě to upřímně zajímalo. Asi je jasné, že různých poměrně podstatných featur, na které se vim z principu nezmůže, budou mít IDE desítky.

[Andrej]

Totéž řečeno jinak: Tazatel se ptal na prostředí, ne na editor.

Zařídit, aby taby v Eclipse vypadaly a fungovaly jako vim (fujtajbl, ale proti gustu žádný dišputát) se dá velmi snadno, kdyby to někdo chtěl. Tab v Eclipse je asi tak to spektrum nasazení, na které se vim zmůže a ke kterému je určený. Je to editor, nikoliv vývojové prostředí.

[Josef Kufner]

Vim je velmi efektivní a mocný editor, ale trvá, než se s ním člověk naučí. Při používání Vimu se předpokládá, že celý operační systém je IDE. Tedy že se používá mnoho různých specializovaných nástrojů pro různé úkoly (např. DDD na ladění). Pro C to funguje docela dobře.

Doplňování, které rozumí kódu se řeší externím nástrojem, který Vimu předá data pro doplňování. Nijak podrobně jsem to nikdy nezkoumal, ale jde to. Navíc Vim umí doplňovat názvy souborů a celé řádky (což je až překvapivě užitečné).

[Kit]

Tohle je velmi užitečný postřeh. Ano, při práci s Vimem využívám schopnosti celého operačního systému. Doplňování kódu, názvu souborů i celých řádků běžně používám. Některé nativně, jiné jsem si dopsal na několika řádcích.

Odpor proti Vimu je z části způsoben jeho grafickou verzí GVim, která je kupodivu omezena a stírá některé výhody textového Vimu - jako je právě těsná vazba na operační systém nebo vzdálené editování.

[ZAH]

Osobně preferuji Eclipse. Jinak hodně záleží co budeš programovat.

Ona všechna ta komplexní vývojová prostředí jsou trochu nenažrané potvory, jak co se týče HW, tak co se týče znalostí programátora.

Jesli jsi programoval v Eclipse na oknech není důvod to měnit.

[TomasABC32]

No já bych to asi uzavřel...Pravda že každý má své důvody. Jelikož jsem v JAVA začátečník, půjdu cestou IDE a tak tedy volím Eclipse. Koukám jen pro linux-Ubuntu poslední verze je 3.8 ?

[ZAH]

Určitě ne na Centosu mám aktuálně.

Version: Mars.2 Release (4.5.2)
Build id: 20160218-0600

Použij instalaci z www.eclipse.org ke stažení je už i verze Neon.

[Jendа]

Mně nějak líp sedlo NetBeans, ale jak můžeme vědět, jaké preference máš ty? Prostě to musíš zkusit…

[Pavel Stárek]

IntelliJ Idea, NetBeans, Eclipse.

[Pavel Stárek]

Intellij Idea Community verze, příp. si přikoupit licenci, pokud tě to živí a využiješ placené featury.