Vistual Studio vs Eclipse

13.4.2009 11:28 | Přečteno: 2828× | Programování | poslední úprava: 13.4.2009 11:28

Jelikož musím teď chvilku na školní projekt používat Visual Studio, sepíšu zde malé srovnání mezi ním a Eclipse které jsem používal dosud.

+Vysouvací taby nástrojů po přejezdu myší
-Mezi taby otevřených souborů se nelze přepínat jinak než myší(v Eclipse stačí Ctrl+PageUp/PageDown)
+/-Řazení tabů(první je ten co se otevřel naposledy)
-Kontextové doplňování + přířazení usingu case sensitive
-Pro using je nutné přejet na poslední písmenko správně case sensitive napsaného textu a klikat tam myší
-Pro using souboru v Solusion je nutné ho ještě zvlášť přidat do referencí;

Z mého pocitu jde o velmi klikací prostředí, které je téměř k ničemu, protože musím každou chvilku brát do ruky myš, takže souvislé psaní kódu pouze na klávesnici je nemožné. Ani tab nejde přepnout pomocí klávesové zkratky. Už se těším až dneska ten projekt dokončím a budu se moct vrátit ke skvělému Eclipse.

       

Komentáře

[xurpha]

VS, Eclipse... není lepší místo takových sraček používat vim :)

[AHAHA]

Zalezi na tom, jestli chces programovat nebo psat 20 radkove skriptiky.

[User682]

spravne kolego, vim je nejlepsi......, protoze:

 

- na co bych pouzival doplnovani kodu u projektu s 10 MB zdrojaku. mam to preci po 90 dnech uz v hlave.

-  na co bych pouzival nabizene opravy

- importy zasadne dopisuji rucne

- vyhledavam pres find a grep

- projekt kompiluji zasadne cely po kazde zmene

- zmeny o velikosti 500kB se merguji ve vim-u uplne uzasne

- graficky navrhar je k nicemu. pisi to zasadne rucne.

- strom s 150 slozkami je ve vim-u nejprehlednejsi

- delam za 10 Kc/hod a nechapu, jak moji kolegove mohou pouzivat to hnusne IDE a delat za 200Kc/hod

- nechapu pojmy editor a IDE. Akorat jsem nekde neco slysel, nikdy jsem s tim nedelal a opakuji bludy jako papousek.

- formatovani zdrojaku je uplne nanic.

- debuguji zasasne pres System.err.println() a vyjimecne pres gdb

 

---------------------------------

No a ted vazne. Radeji mam Eclipse, i kdyz znam oboje. Eclipse umi o par veci mene, ale zda se mi vice pouzitelnejsi.

 

 

[xkucf03]

Skvěle napsané

Já mám nejradši Netbeans.

[moira]

Presne. Docela by zajimalo, zda ti, kdo maji potrebuje okamzite vytahnou vim nekdy zkusili nejake IDE (resp. jestli ho zkouseli dele nez minut).

[qiRzT]

Ale jo:) Dělal jsem v Netbeans a je bez diskuzí, že opravdové IDE má mnoho výhod. Ale v tom seznamu je taky mnoho nepravd. Třeba to doplňování umí i vim. Je vyřešeno jinak a má to svoje výhody a nevýhody. Co je špatného na grepu a findu? Proč bych měl pokaždé znovu kompilovat celý projekt, když používám vim? Jinak vim používám skoro na všechno, můžu ho používat krásně přes ssh.

[Filip Jirsák]

Co je špatného na grepu a findu?

To, že neznají sémantiku jazyka. Takže pokud chci hledat použití metody, najdou mi i použití stejného názvu v komentářích, definici metody i použití jiné metody stejného jména.

[ludo]

cscope.... ale je pravda ze je jenom pro C/C++

[Ivan]

tomu neverte, ani ctags, etags, ... a dalsim. Zadny z techto nastroju si s C++ neporadi. Syntaxe C++ je i bez #define prilis slozita a zadny program nerozumi C++ stejne dobre jako gcc. Jeste dneska neco napisu v Emacsu, ale bohuzel se tehle sw pomalu rozpada. S kazdou dalsi verzi prestane neco fungovat a na moje C++ zdrojaky uz bohuzel Emacs nestaci.

[andree]

nooo, taky kdevelop v poslednych verziach uz napr. zvlada aj c++ templates atd... nedavno (ehm, no mozno to uz bude par mesiacov)  sa o tom pisalo na nejakom blogu na kde.org, autor sa tvaril ze ten ich editor je jeden z najpokrocilejsich ake pre c++ existuju...

[mirec]

Konkrétne to bol na tomto blogu.

[rastos]

jeden z najpokrocilejsich ake pre c++ existuju.

Ale stále nie je release-nutý. :-/

[YYY]

Kazde ma sve pro a proti. Ja osobne preferuju vim na sve soukrome vecicky(projekty do 5000 radku). V praci pouzivame hojne kdevelop+qt-designer. Graficky navrhar je dobry vynalez, psat gui ruzne nevermore.

[YYY]

Jinak VS jsem pouzival za mlada v obstarozni verzi 6.0 (je to mozne?, uz je to pekna radka let) a nepracovalo se v tom vubec spatne. Mozna bych dnes na to mel jine naroky, nevim, ale tenkrat mi to stacilo.

[Salamek]

taky jsems tím za mlada pracoval a byl jsem schopen spáchat multimediální přehrávač oproti kterému byl wmp kus hovinka(funkcemi a jednoduchostí, jinak to moje musela být zdrojákově hrozní prasárna ) , ted jsem rád že napíšu grafické hrabání se v mysql přez c++ a GTK+

[Luk]

VS 6.0 je i dnes pořád docela na výši (kromě některých neduhů - např. neumí doplňovat názvy maker), přestože je na světě už cca 11 let.

[default]

A funguje už kolečko myši? To mi tenkrát před před deseti lety nějak nejelo.

[RapMan]

Funguje, ale musis mit jiny ovladac mysi :) Primo od logitechu, kdyz mas mys od logitechu.

[ludo]

no nic proti ale ten kompilator co tam maji, se snad kompilatorem C++ ka ani neda nazvat

[Luk]

Ten kompilátor C++ z VS 6.0 produkuje kvalitnější (rychlejší) kód, než produkoval GCC 3.3, tedy kompilátor nejméně o 5 let novější. Ano, kompilátor z VS 6.0 se chová mírně nestandardně, což je vcelku logické, vzhledem k tomu, že vznikl dříve, než byl standard pro C++ vydán.

[luky]

Ve zkratce - neovládáš vim ani zbla :)

[microcz]

dovedl bych si predstavit lepsi (o neco prehlednejsi) IDE nez eclipse, ale taky ho pouzivam nejradeji, CDT ma konfigurovatelne autoformatovani kodu, svn commit nebo update mam na jeden klik, relativne pohodlne muzu spravovat build konfigurace a prepinat mezi nimi ...nechci hanit vim, ale pokud si nekdo nevybuduje vlastni system hotkeyu a skriptiku pochybuji ze v nem lze vyse zminene veci nejak jednoduse poresit

[JS]

No, ja se ted ucim Lisp, a rekl bych, ze je lepsi pouzivat Emacs.

(Vim jsem zkousel, a vadi mi na nem 2 veci - neni tam SLIME a protoze delam hodne preklepu, nejsem pri jeho pouzivani vykonnejsi, spis naopak).

[Andrej]

Ne, není. VIM se na programování nehodí. Přesněji, nehodí se vlastně vůbec na nic. Nemá správu projektů a repository. Nemá refactoring. (Jestli mi někdo zase bude tvrdit, že regulární výrazy jsou refactoring, dává tím na jevo, že o tom ví prd.) Nemá auto-completion s podporou typů a s indexováním napříč několika projekty. Neumí ani automaticky vygenerovat Doxygen/Javadoc. Neobsahuje vývojové nástroje pro databáze a jejich vzdálenou správu.

VIM se hodí pouze tehdy, pokud jsem android schopný pamatovat si nějaké blbé shluky písmenek a pokud jsem na systému, kde pořádný editor není.

Dobře. Dejme tomu, že se rozhodnu používat VIM. Popište mi prosím krok po kroku, jak ve VIMu udělám tohle:

1. Checkout projektu z Mercurialu. (No dobře, kdyby ten ubohý VIM náhodou neuměl Mercurial, tak SVN, ať nežeru...)
2. Automatická kompilace celého projektu, zobrazení stromu balíků (třeba v Javě), vyznačení chyb a warningů. (Tohle bych prosil bez jediného stisku klávesy, ano?)
3. Auto-completion se znalostí všech identifikátorů a typů nejen v současném projektu, ale i ve všech ostatních projektech, které mám ve workspace. (VIM samozřejmě umí workspace a ukládání metadat, předpokládám... Když navrhujete jeho použití místo Eclipse, musí to umět, že ano.)
4. Auto-completion mi musí automaticky u všech návrhů ukazovat Javadoc k polím i metodám. A to samozřejmě i tehdy, když od té funkce nemám zdroják! Stačí připojit Javadoc z webu a všechno musí fungovat. Ale bezpochyby, tohle VIM jistě zvládne.
5. Chci změnit název jedné veřejné metody. Název se samozřejmě musí změnit správně nejen v celém projektu, ale i ve všech projektech ve workspace, které tuto metodu volají. A pozor! Metoda s tímto názvem existuje nezávisle u mnoha tříd. Měním ji pouze u jedné. Refactoring se nesmí za žádných okolností splést. Po něm následuje automaticky bezchybná kompilace, samozřejmě. Ale jistě, tohle přece VIM dokáže. Můžu ho klidně použít místo Eclipse!
6. Pak se rozhodnu přeuspořádat několik adresářů ve stromě projektu. Samozřejmě metadata, která souvisí s repository, musí zůstat stoprocentně konzistentní.
7. Commit do repository. Opět (jak jinak) s grafickým znázorněním změněných položek.
8. Chci vygenerovat grafický diff celého obsahu repository, tedy rozdíly oproti minulé revizi (je-li řeč o SVN) nebo zkrátka rozdíly způsobené mým commitem. To přece ve VIMu není žádný problém, že???

Tak se těším na návod, jak přesně tohle udělám ve VIMu! Nemůžu se dočkat, až budu moci ten skvělý editor (díky tomu návodu) konečně naplno využít.

Chápete, kde je v celé té uvaze chyba? VIM, podobně jako kwrite, gedit, mcedit nebo nano, je textový editor. Není to vývojové prostředí. Proto pochopitelně neumí nic z toho, co musí vývojové prostředí zvládnout. To není chyba VIMu (nebo ostatních jmenovaných editorů), ale vlastnost vycházející z toho programu.

Netvrďte tedy, že vývojové prostředí pro programátory z řad lidí lze nahradit konzolovým editorem určeným pro roboty. To prostě není a nebude možné.

Představte si, že by někdo porovnával Word a Writer a vytvořil by v nich náročnější hromadnou koresponedenci se spoustou grafiky a s napojením na databázi. No a pak by přišel křikloun, který by řekl: K čemu jsou takové sračky? Nešlo by tohle všechno udělat pomocí kwrite? Ne, to by nešlo.

[default]

V Emacsu tohle všechno jde. Ten je totiž lepší než vim.

[Algi]

Moment, nepleť dvě věci dohromady: Emacs je operační systém a vim editor

[default]

Pak je zde ovšem otázka, zda umí spustit Eclipse nativně, nebo opět jen dělá klienta k nějakýmu server-side.

[Fluttershy, yay!]

Kvůli té auto-completion a automatickému formátování kódu v VS mi každou středu ve škole málem slezou vlasy z hlavy.

BTW jak se dá ve VS 2005 zapnout číslování řádků? Nikde jsem to tam nenašel a to jsem hledal.

[Luk]

BTW jak se dá ve VS 2005 zapnout číslování řádků? Nikde jsem to tam nenašel a to jsem hledal.

Nevím jak ve VS 2005, ale ve VS 2008 je to Tools -> Options -> Text editor -> (x) -> Display -> Line numbers (kde (x) je buď All Languages nebo konkrétní jazyk, např. C/C++).

[Petr]

http://www.blackwasp.co.uk/TurnOnLineNumbering.aspx

[filo]

Kvůli té auto-completion a automatickému formátování kódu v VS mi každou středu ve škole málem slezou vlasy z hlavy.

Já se naopak k tomu automatickému formátování chovám s respektem (stejně jako k doporučením od MS ohledně syntaxe), dřív jsem taky kopal kolem sebe, že si chci stylizovat kód sám, ale pár multi-person projektů mě přesvědčilo, že disciplína prostě musí bejt. Když na kódu jednoho souboru dělalo 5 lidí a je to na něm vizuálně vidět, tak je to podle mě špatně, nehledě na fakt, že někteří píšou tak, že se v tom ani prase nevyzná. Navíc u mých zaměstnavatelů to bylo zatím vždycky tak, že je buď vynucován standard formátování dodávaný s IDE nebo je vytvořený nějaký vlastní vnitrofiremní.

[Fluttershy, yay!]

Konvence mi ani tak nevadí (ač preferuji jiné a pro školní potřeby je snad důležitější, aby se mi to dobře četlo a tak), ale smolí mne, že něco napíšu a kód někam neočekávaně přeskočí, což tedy moc přemýšlení moc nepodpoří (asi jako flashové reklamy).

[filo]

Pokud máš na mysli autocompletion, tak souhlasím, občas doplní i to co nechci a když si na to nedám majzla (nedívám se zrovna na monitor), tak se pak nestačím divit :)

[podlesh]

Jo, práce v týmu většinou přinese docela jiný pohled na programovací jazyky, konvence, IDE a podobné věci.

[xkucf03]

jj, důležité hlavně je, aby to všichni v týmu psali stejně – jinak totiž dáš alt+shift+F, kód se přeuspořádá a ve verzovacím systému pak máš spoustu změn (jasně, dají se ignorovat bílé znaky, ale formátování je často větší zásah).

[default]

Na bílé znaky mi prosím nesahej.

[xkucf03]

Snad nepíšeš ve whitespacu?

[Josef Kufner]

Ono ale "programovat ve Vimu" neznamená, že je puštěný Vim a nic víc. Vim je opravdu jen Editor, ale je propojený se zbytkem systému a velmi lehce jej lze používat spolu s mnoha dalšími nástroji. Nemusí umět checkout a commit z/do Mercurialu, protože umí spustit jiný nástroj. Nemusí umět kompilovat, protože umí spustit make/ant/cokoliv. Na diffy je úžasný kdiff3 -- nespouštím ho však z Vimu, ale pomocí "git mergetool".

Klasické IDE naopak vytváří svoje prostředí a spolupráce s externími programy je celkem obtížná až nemožná, takže buď funkci má nebo nemá -- nemůžeš jen tak sáhnout po specializovaném nástroji a očekávat bezproblémové používání. To je s Vimem samozřejmostí.

Argumenty, které mají opodstatnění, jsou ty o refactoringu, doplňování kódu a napovídání. Vim je obecný editor a má obecné doplňování. Chová se jinak, ale práci ulehčí také. Doplňování kódu by se dalo brát jako chyba v návrhu jazyka, ale to je na jinou diskusi.

[xkucf03]

Doplňování kódu by se dalo brát jako chyba v návrhu jazyka

V každém jazyce má smysl jen určitá kombinace slov a znaků – ostatní kombinace smysl nemají a nejdou ani zkompilovat. Proto se doplňování kódu hodí vždycky. Smysl by nemělo jen tehdy, kdbys mohl kompilátoru předhodit jakoukoli náhodnou kombinaci bajtů → pak by nebylo co napovádat.

[Filip Jirsák]

Smysl by nemělo jen tehdy, kdbys mohl kompilátoru předhodit jakoukoli náhodnou kombinaci bajtů

Takže Perl?

[Josef Kufner]

Ta formulace je trošku nepovedená (ztratilo se tam pár slov). Myšleno to bylo tak, že jazyk a hlavně jeho syntaxe by měla být dostatečně kompaktní, elegantní a přitom výřečná, aby doplňování nebyla nutnost pro jeho aspoň trochu efektivní používání.

[Filip Jirsák]

Doplňování ale není záležitost syntaxe jazyka. Doplňují se zpravidla názvy uživatelsky definovaných identifikátorů, a pokud uživatelé vytvářejí 20znakové identifikátory, je to jejich „problém“ (ono se to zase pozitivně projeví na čitelnosti kódu). IDE by nemělo programátorovi kecat do toho, jak dlouhé chce mít identifikátory, a pokud je chce mít dlouhé, má mu práci s nimi usnadnit. Navíc doplňování nemá pouze funkci doplňovací, ale zároveň funguje jako rychlá referenční příručka.

[Josef Kufner]

O tomhle nemluvim.

[mirec]

Příloha:

• vim.png (83263 bytů)

Doplňovanie kódu a zobrazovanie dokumentácie bez problémov, kompilácia pomocou externých nástrojov bez problémov, commity bez problémov (externé nástroje), generovanie dokumentácie bez problémov (externé nástroje). Vim nie je IDE ale dá sa používať ako náhrada a ja aj pri väčších projektoch jednoznačne preferujem vim (keďže o veci ako automatická kompilácia, automatické doplňovanie kódu ... fakt nestojím, neznášam nástroje, ktoré sa snažia byť inteligentnejšie ako ja, hlavne keď sa im to aj úspešne darí).

[Andrej]

No, ufff. Proti gustu žádný dišputát.

[mirec]

Takže včera som musel utekať preč .. nestihol som dopísať všetko čo som chcel.

V prvom rade bol by som rád aby užívatelia VIM-u neurážali užívateľov IDE a opačne.

Keď porovnávame VIM a nejaké IDE treba si uvedomiť, že VIM je len editor. Ja ho zvyknem používať namiesto IDE (dokonca ho občas aj tak označujem) i keď neposkytuje takmer žiadne zo služieb IDE. VIM sám o sebe nevie toho moc veľa, ale dokáže veľmi dobre solupracovať s externými nástrojmi. Len si skúste, či Váš editor dokáže označenú časť súboru poslať cez pipe externému nástroju a pôvodný text nahradiť výstupom z externého programu. Alebo skúste spustiť makro pre každý riadok označeného textu.

Aby som sa dostal k samotným otázkam: VIM toto nedokáže, ale externé nástroje áno. Vo VIM-e sa dá ako backend server použiť eclipse, takže všetko od doplňovania kódu, zobrazovania dokumentácie až po refactoring kódu je možné volať piramo z VIM-u (i keď samotný VIM nič z toho nevie).

Možno si teda hovoríte prečo je používanie VIM-u pre mňa lepšie než používanie Eclipse keď VIM Eclipse priamo využíva. Nuž dosť silným argumentom pre VIM je, že som naň zvyknutý (je terminálový, zvyknem často konfigurovať cez ssh, prípadne aj na mojom stroji s vypnutými X). Vzhľadom na to, že nie je grafický (nepoužívam gvim) nepotrebujem dávať ruky dole z klávesnice (mám síce trackpoint, ale zvyknem používať externú ergonomickú klávesnicu, takže je dosť ďaleko). Ovládanie VIM-u mi teda prácu poriadne uľahčuje (stačilo sa naučiť pár príkazov a tie najpoužívanejšie namapovať na klávesové skratky).

[MiCHi]

-Mezi taby otevřených souborů se nelze přepínat jinak než myší(v Eclipse stačí Ctrl+PageUp/PageDown)  zkousels treba standardni zkratku CTRL+TAB nebo CTRL+F6?

-Pro using je nutné přejet na poslední písmenko správně case sensitive napsaného textu a klikat tam myší

tohle nechapu, kdyz napises "using" das prvni pismeno a CTRL+SPACE tak uz pak muzes prolizat sipkama a Enterem, v VS vetsinou na mys nesaham

[Dent]

K tomu poslednímu - asi je myšleno, že pokud nemám použitý using System.IO; a napíšu do kódu např OpenFileDialog ofd = new... atd, tak pro automatické doplnění usingu musím klepnout myší na malé vyjížděcí políčko pod OpenFileDialog a z nabídky zvolit doplnění usingu. Není to moc pohodlné, pokud člověk dělá na notebooku a nemá připojenou myš - blbě se tam trefuje.

[Roger]

A proc teda nepouzije shift+alt+f10?

[Dent]

Asi o tom neví? Já o tom taky nevěděl :))

[Jardík]

Co? Eclipse je zralý do šrotu, je to strašně pomalej šmejd napsanej v javě, který žere 5x tolik, co visual studio a odezva celého IDE eclipse je 5x nižší (pokud nesouhlasíte, tak radši ani nepište. O Opaku mě nepřesvědčíte, protože s tím mám zkušenost). Doplňování ve VS je mnohem lepší než v eclipse a rozhodně při tom klikat nemusíce.

[Filip Jirsák]

Co? VS je zralý do šrotu, je to strašně pomalej šmejd napsanej v .NET, který žere 5x tolik, co Eclipse a odezva celého IDE VS je 5x nižší (pokud nesouhlasíte, tak radši ani nepište. O Opaku mě nepřesvědčíte, protože jsem VS v životě neviděl). Doplňování v Eclipse je mnohem lepší než ve VS a rozhodně při tom klikat nemusíce.

[microcz]

+1

[Pavel]

Hm, az na to, ze devenv.exe je nativni Win32 aplikace........

[Jardík]

A to, že je to napsaný v .NETu jste si vycucal z prstu? Já když na to kouknu, tak je to normální obyčejná non-NET PE binárka.

[Pavel]

jojo, ted je za vola :)

[kralyk z abclinuxu]

Tak teda já nevim, ale když spustim tady u sebe Visual C++ 2008 tak to jednoznačně je .NET binárka.
Vono si totiž Visual Studio loaduje přes COM různý další binárky či pluginy či co a ty by klidně mohly být napsané v .NET

Ať tak nebo tak, mně tu běží VCExpress.exe, který je .NET procesem, takže pozor, aby tu nebyl za vola někdo jiný...

[Pavel]

Tak si otevrete devenv.exe treba v reflectoru no, dostanete:

devenv, Module 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe' does not contain a CLI header. Coz znamena, ze to .NET binarka proste neni.

[Filip Jirsák]

A devenv.exe je to vlastní IDE, není to jen nějaký spouštěč? Ono takové eclipse.exe je taky nativní binárka… Nicméně i kdyby VS bylo vyděrované na štítcích, nic to nemění na tom, že je zvláštní z programovacího jazyka odvozovat vlastnosti výsledného programu.

[default]

je zvláštní z programovacího jazyka odvozovat vlastnosti výsledného programu.

Zvláštní to je. Ale tady nikoli.

[kralyk z abclinuxu]

Příloha:

• scr.png (100693 bytů)

A proč bych si otvíral devenv.exe? To co mi tu běží, není nějakej devenv.exe, ale VCExpress.exe.
Jestli mi nevěříš, mrkni na screenshot, kterej přikládám...

[Filip Jirsák]

Ono je to u toho vašeho komentáře jedno, jestli je to vycucané z prstu nebo je to pravda. Na informační hodnotě komentáře to nezmění vůbec nic.

[User682]

ano, IDE vlastne pouzivame podle toho, jak je rychle a jak rychle startuje a kolik zere pameti. Neco jako Eclipse knihovny a cely framework, pluginy je o nicem.

- o VS Studio 2005 by se dalo rici, ze umi mraky veci, ale chybi tam ty, ktere v Eclipse bezne pouzivate.

- pamet - proc je nutno za pul dne cely pocitac s VS2005, kdyz stejny build trva nejdrive 2s a pak 15s.

Praxe je pro me takova, ze produktivita pri prechodu z Eclipse na VS2005 sla o 1/3-1/2 dolu. Chapu, ze mame VS2008, ale nez si jej firmy nakoupi, tak to bude hodne dlouho trvat.

[Jardík]

Proč koupit? Jaké výhody (kromě MFC) to má oproti zdarma dostupné verzi, ve které lze programovat i komerční uzavřené aplikace?

[depka]

mfc je dneska vyhoda?

[mich]

Máš s tím zkušenosti = tvé programy typu průsečík dvou úseček si psal ve VS? S tvýma zkušenostma opravdu dokážeš objektivně posoudit kvality jednotlivých IDE.

[stativ]

Docela jsem se pobavil.

[Algi]

Tak teď váhám, zda je lepší odpověď tahle, nebo pana Jirsáka Abych pravdu řekl, tak teď nevím, kdo Jardíka víc utřel. Asi by to chtělo nějaký systém bodování komentářů...

[Jardík]

Smůla, ten jsem psal v geditu a překládal přes terminál s gcc.

[kralyk z abclinuxu]

Voba sou to pomalý líný molochy. Qt Creator či Code::Blocks jsou mnohem použitelnější.

[grubber]

Konečně někdo rozumný Za Qt Creator se přimlouvám taky (v Code::Blocks mi mnohdy nefungovalo doplňování, ale to je tak rok dva zpátky, třeba už to opravili ). S VS jsem dělal dřív (když jsem se učil programovat) a docela mi vyhovovalo, ale teď už bych si s ním asi tolik nerozuměl. Z Eclipse mám noční můry ještě doteď, nutili nám ho ve škole na Javu (nelibí se mi ani Java, ani on :-P).

[kralyk z abclinuxu]

v Code::Blocks mi mnohdy nefungovalo doplňování, ale to je tak rok dva zpátky, třeba už to opravili

No funguje tak nějak pofidérně, to je fakt. To je trochu slabá stránka CB...

[...............23]

Qt Creator je fajn IDE, ale zatiaľ mu dosť vecí chýba, mne napríklad hlavne symbol browser, alebo podrobnejšie nastavenie projektu (nie len ručná editácia CFLAGS a LIBS).

[Atom321]

Visual Studio má jednu zásadní vadu - nefunguje pod Linuxem.

[Deleted [8409]]

To ale nikomu nebrani pouzivat ho pod Windows

[default]

No, tak jestli si někdo chce nasednout na rozžhavenou rašpli a drbat se přitom v rozkroku drátěným rejžákem, pak klidně.

[kralyk z abclinuxu]

[Deleted [8409]]

Jste asi velky odbornik :)

[default]

Já jsem velká nula.

[kralyk z abclinuxu]

No třeba se to dá rozběhat přes víno. (ale nevím, nezkoumal jsem, nezajímám se)

[Brumla]

-Pro using je nutné přejet na poslední písmenko správně case sensitive napsaného textu a klikat tam myší
Stačí zmačknout dost nešikovnou magickou klávesovou zkratku Ctrl-Shift-F10.

-Mezi taby otevřených souborů se nelze přepínat jinak než myší(v Eclipse stačí Ctrl+PageUp/PageDown)
Přepínání je přes Ctrl-Tab

 

Už se těším až dneska ten projekt dokončím a budu se moct vrátit ke skvělému Eclipse.

Už se těšim, až bude padla a ten šílenej Eclipse zavřu

 

Osobně považuju VS za vcelku použitelný prostředí, samozřejmě v porovnání s Eclipse je trošku problém v tom, že VS není stavěný tak univerzálně jako Eclipse. Osobně nejsem z používání Eclipse příliš nadšenej, např. update modulů do Eclipse je někdy sázka do loterie a už se mi několikrát stalo, že jsem měl Eclipse ve stavu značně nekonzistentním a tím pádem k ničemu.

 

[nooneanymore]

Koukám, že se tu rozpoutala dost velká hádka... Já osobně bych raději trávil čas učením, jak používat nástroj, který umí "skoro všechno" z mé každodenní činnosti, než studováním jednoho specializovaného programu na programování. Proto používám Emacs. Netvrdím, že umím v něm udělat všechno, ale v nějakém IDE taky ne, takže je to úplně jedno.

Emacs je:

• snadno rozšiřitelný;
• paměťově méně náročný než Eclipse;
• nezávislý na myši;
• schopný pracovat s externími programy;
• a ostatní si vzpomenou, co ještě je...

zvládá úkoly z různých oborů mé činnosti:

• TeX + prohlížení obrázků (což jen tak ledajaké TeX IDE neumí);
• programování v mnoha jazycích:  Fortran, C/C++, Haskell, Python, Perl;
• inteligentné rozpoznává syntaxi konfiguračních souborů (zakomentování vyznačené oblasti, odsazování, barevné zvýraznění);
• spouštění programů v terminálu;
• správa verzí;
• čtení mailů;
• prohlížení webových stránek;
• prohlížení manuálových stránek;
• čtení PDF;
• atd.

A to vše bez toho, abych sáhnul po myši nebo spouštěl jiný program.

Emacs nemá gui pro vytváření gui, ale to já ve škole ani v práci nepotřebuju, protože grafické programy zatím nedělám. (Ani bych nebyl schopen napsat kód tak nepřehledný, jaký obecně mají grafické programy )

Takže pro mě je výhodnější čas investovat do Emacsu, než začít se piplat v Eclipse, který jsem po první půlhodině nebyl schopný používat. V Emacsu aspoň, když nevím, jak to udělat po emacsovsku, můžu skočit do eshellu.

Chápu, že můj pohled je dost omezený a asi ani nepostihuje pravé výhody či nevýhody, ale tak to cítím já. Pokud mě někdo přesvědčí, že učit se Eclipse se vyplatí, pak rád změním názor.

[default]

A ještě to uvaří kafe a připálí pizzu. No neberte to za ty prachy.

[Algi]

Eclipse je taktéž snadno rozšiřitelný a to pomocí správy pluginů (těžko říct, jestli je lepší v NetBeans nebo Eclipse - zas tak moc do toho nevidím). Myš nepoužívám v Eclipse skoro vůbec a to mě můj kolega (upozorňuji, že uživatel Windows) označil za klikače O podpoře TeXu v Eclipse jsem nikde neslyšel (ne, že bych hledal) a proto si myslím, že na takovéto věci asi opravdu nebude Eclipse to nejlepší.

Co se týče podpory ostatních programovacích jazyků, tak tam bych to spíš viděl na NetBeans (můj osobní dojem).

Syntaxe konfiguračních souborů: ty znám jenom jako properties soubory, takže nevím

Programy v terminálu spouštím zásadně z aplikace Terminal

Správu verzí (SVN, CVS) má Eclipse vynikající. Zde bych si troufl říct, že dokonce lepší, než NetBeans. Tam se soustředí hlavně na Mercurial, který prý používají při vývoji (snad nelžu).

Na prohlížení webových stránek je dobrý mít v počítači slušný webový prohlížeč. Manuálové stránky se dají opět prohlížet v Terminalu, přičemž číst PDF v něčem jiném než je Preview (nebo podobné) mi přijde jako velmi exotický nápad

Takže sečteno a podtrženo: Emacs asi bude pro tebe opravdu dobrá volba. Ale v momentě, kdy začneš vyvýjet alespoň trochu větší projekt v Javě jej prokleješ... Zajímavou alternativou k Emacsu bych viděl JEdit, ale ten asi nebude mít takové možnosti, jako již zmiňovaný operační systém (Emacs).

[mirec]

Nebola tu spomenutá jedna zásadná výhoda používania editoru (aspoň na začiatku). Človek nie je závislý od toho čo mu vygeneruje IDE, niekedy je lepšie rozumieť ako samotný proces kompilácie funguje než tváriť sa, že nič také ako Makefile, ant, scons .. neexistuje.

[xkucf03]

To je vždycky o požadované úrovni abstrakce. Abych mohl úspěšně používat počítač, nepotřebuji umět programovat v assembleru a nepotřebuji vědět, co se přesně děje v procesoru a na desce... stejně tak si nemusím psát vlastní makefile nebo build.xml, abych mohl programovat. Pokud jsem spokojený s šablonou, kterou mi IDE poskytne, proč to psát od začátku sám? Líbí se mi přístup Netbeans, ty mi antovský skript vygenerují, ale můžu si do něj dopsat co potřebuji (pokud to potřebuji) -- příklad.

[default]

Líbí se mi přístup Netbeans, ty mi antovský skript vygenerují, ale můžu si do něj dopsat co potřebuji (pokud to potřebuji) -- příklad.

A zkoušel jsi to kompilovat na stroji, kde nejsou NetBeans nainstalováy?

[xkucf03]

Tenhle konkrétně jsem ještě nezkoušel, ale jiné build.xml z Netbeans jsem přeložil i bez nich.

Můžou být potřeba některé knihovny, ale to nesouvisí s Netbeans (to by teoreticky řešil maven, ale ten moc nepoužívám).

[default]

No, co si pamatuji, tak aspoň v NetBeans 5.5 se build-impl.xml odkazoval přes nbbuild/private/private.properties na build.properties uložený v ~/.netbeans/…. To pak způsobovalo, že jaksi nebylo dostupné ANTí rozšíření CopyLibs, JUnit a další srandičky, takže to neudělalo výsledný JAR a vyhučelo to. Ale asi se v tom jen moc hrabu.

Tohle konkrétně částečně řeší NetBeans 6.5, ale tam zas hoši přidali jiný bugy, se kterými teď trávím večery.

[mirec]

Samozrejme všetko záleží na úrovni na akú chceme poznať fungovanie programu / build procesu. Povedzme, že bez poznania fungovania ant-u sa ťažko dá doplniť nejaké veci. No a pri programovaní zvyknem písať dosť nízkoúrovňové veci. Bez toho aby som poznal ako funguje cache, pipelining u superskalárnych procesorov ... (aj keď sú pre programátora transparentné) by som ťažko mohol písať tak efektívny kód ako keď rozumiem fungovaniu hardware. Je fakt, že pri samotnom programovaní nepotrebujem vedieť ako to presne funguje, ale až chcem napísať niečo fakt rýchle, potrebujem vedieť základy fungovania hardwaru.