Podle me je to proste tim, ze ve velkych korporatech se to tak nejak tlaci, protoze co jineho ze, predsi nebudeme delat projekty tak, aby se dali pouzit i v jinem IDE, ktere pise nejaky nadsenec. No a kdyz uz s tim nekdo dela, tak to pouziva i jinde aby se nemusel nic jineho ucit. Ja s tim taky delat musel a kdyz nemusim tak to nepouzivam. Je to obludne, pomale a nelogicke. Jenze kdyz dostane predpripraveny prjektovy"Solution" (kteryzto nazev je typicky PR blabol protoze to neni zadne reseni ani to samo nic nevyresi) tak pokud chcete pouzit neco jineho musite si to vsechno obstarat sam a na to vam nikdo cas neda. Jeste ze aspon v embedded svete je nejaky vyber, ale je dost mozne, ze za par let uz bude jen sln (stejne jako pred casem doc a xls). O kvalite produktu to podle me nic nevypovida.
Zásadní rozdíl je v tom, že VS Code stáhneš od "výrobce" a už je to v podstatě plnohodnotné IDE pro Javascript, Typescript a vůbec webový vývoj, včetně GIT klienta.
Kdežto VIM z distra se tomuhle neblíží. Musíš začít nastavovat, instalovat atd. než se k něčemu jako IDE pronastavuješ. Další věc je built in podpora extensions store, to je také vlastnost spíš IDE a VIM pokud vím také nic takového built in nemá.
Mno, i halabala link na web muze stacit, pokud odpovi tolik lidi, ze by to byla cela populace, tak uz by ta data z definice byla pro celou populaci :)
(jojo, hranicni pripad kdy pruzkum zabira celou populaci se obvykle neuvazuje, ale muze nastat - treba pruzkum ve skole a na jinych malych populacich)
Zalezi co je cela populace. Jestli je populace programatoru treba 1 milion lidi, ale VSC pouziva 40 000 lidi, a vsichni co pouzivaji VSC hlasovali v odkazovanem pruzkumu, tak je pruzkum zkreslujici klidne o 1000 %, nebo tak nejak.
Coz se vysoce pravdepodobne nestalo, ale for je v tom, ze nevime, jaky vzorek je dostacujici, protoze nevime jakym zpusobem hledali lidi co prispeli do pruzkumu, a nevime co je cela populace. Tudiz nevime, jak moc je pruzkum vypovidajici. Nevime, jestli chyba tech cisel je 1 % nebo 1000 %.
Mimochodem statisticke urady venuji prave tomuhle problemu docela spoustu casu. Aby vybrali dostatecne nahodny vzorek, ktery bude vhodne reprezentovat celou populaci. A na strankach CSU se kdysi dalo docist, ze pro CR (populace 10 M) je rozumny vzorek pro pruzkum neco kolem 3000 lidi, pokud sou ti lide vybrani naprosto nahodne.
U pruzkumu, kde odpoved muze naklikat kazdy kdo jde kolem, je riziko ze se informace o pruzkumu rozsiri mezi uzivateli VSC, ale ti nemluvi s uzivateli emacsu (napr), takze vznikne bias. A vlastne to pisou i na Stackoverflow:
"Since respondents were recruited in this way, highly engaged users on Stack Overflow were more likely to notice the links for the survey and click to begin it." - neboli ti co radeji poskytovali nebo hledali rady, maji v pruzkumu vetsi zastoupeni nez ti co rady nepotrebuji/nedavaji.
Cimz nerikam, ze by pruzkum ze stackoverflow nemel vypovidaci hodnotu. Jen je potreba vedet jak to je.
Mě by spíš zajímalo pro jaký jazyk vscode používají. V pythonu nebo javascriptu/typescriptu se v tom docela dá pracovat, ale pro vývoj v C/C++ mi to přijde dost nepoužitelné. Pokud se člověk smíří s HW nároky a nevadí mu nulová konfigurovatelnost UI, tak je to poměrně dobrý editor/IDE.
HW nároky jsou vyšší třeba v porovnání s eclipse. vscode si klidně vezme 1GB RAM na projekt o velikosti do 10000 řádek kódu.
Nepoužitelné pro C/C++ mi to přijde:
- žádné refaktorizační funkce (nechodí mi spolehlivě ani přejmenování proměnné)
- chybí rozumné UI pro věci jako vypsání použití symbolu (popup, který zmizí při editaci)
- chybí vypsání hierarchie dědičnosti
- chybí integrace unittestů
- outline se nedá přesunout do vlastního panelu, takže bojuje o místo s prohlížečem souborů projektu
atd.
Zkoušel jsem jak C++ plugin, který i přes svou neschopnost vytváří gigabajty metadat i na malých projektech, tak i clangd, který se zdá být v beta verzi, takže ani funkce popsané v dokumentaci nejsou spolehlivé. Používám to na linuxu, nevím jestli to není třeba na windows lepší. Přitom většina těch funkcí v pythonu funguje, i když pro python je jejich implementace složitější.
Nižší? Mno to je dost otázka, protože to záleží na množství aktivních pluginů. Vyšší spotřeba u JetBrains je možná, protože je to vždycky kompromis mezi rychlostí odezvy (cache) a nároky na cpu+paměť. PyCharm i CLion navíc rozumí kódu opravdu dobře. Jejich rafactoring nástroje jsou nejlepší co jsem kdy používal. A to něco stojí.
Nicméně VSC a ostatní na Electronu založené projekty nejsou také zrovna etalon efektivity. Je to přístupem takový moderní Emacs (zobrazovací jádro + pluginy, jen Emacs místo javascriptu používá elisp) a i u toho se mi podařilo se dostat na 1 GiB spotřebované paměti.
Já třeba na C++ a CMake projekty používám QtCreator s povoleným LLVM. Refactoring není moc dobrý (skoro neexistuje), ale je to rychlý použitelný a relativně nenáročný editor.
Electron UI není víc náročné než spuštěný webový prohlížeč. Pluginy často spouští proces na pozadí, ten může být hw náročný, ale to není chyba VSCode.
> Je to přístupem takový moderní Emacs (zobrazovací jádro + pluginy, jen Emacs místo javascriptu používá elisp
právěže neni, pluginy mají přístup jen k dost omezeným funkcionalitám. Uživatelské skripty mimo pluginy pokud vím zatím nepodporuje. Atom v tomto ohledu nabízí víc možností.
> Electron UI není víc náročné než spuštěný webový prohlížeč. Pluginy často spouští proces na pozadí, ten může být hw náročný, ale to není chyba VSCode.
Jenže bez nich není VSCode nic jiného než textový editor (možná.. spousta základních funkcí je poskytována pluginy). Takže pokud porovnáváte plné IDE s VSCode, musíte do toho zahrnout i pluginy pro daný jazyk a prostředí.
Tiez som to pred asi dvoma mesiacmi cvicne skusil pouzit na nejaky moj sukromny projekt, ktory ma cmake / gcc / gdb a par tisic riadkov kodu. Vysledok je ten, ze pre automaticke pouzitie bud s cmake alebo s gdb je potrebne rucne editovat json co si k projektu VSCode spravi, aby vedel co kde a ako. A to aj po nainstalovani prislusnych pluginov.
To som zhodnotil, ze aj KDevelop vedel uz pred 10timi rokmi lepsie a ze vysledok je vlastne rovnaky, ako s vim-om. Vim akurat nezozerie giga ram.
jj. U nás (nejmenovaná CZE výzkumná instituce) se VS code v posledním roce taky neskutečně rozmohlo.
Osobně důvody vidím v:
* multiplatformnost - máme lidi s koncovým zařízením na Linuxu, Mac, Win - a přesto si můžou koukat přes rameno do stejného prostředí
* podpora vzdáleného vývoje - přes SSH se to připojí k HPC systému a člověk si tam naskriptuje build v kontejnerech a jiné libůstky
* cena - Pycharm se stejnými features je znatelně placený
* responsivní support - v týdnu jsem našel bug, nareportoval a přes víkend to fixli..
5. 9. 2019, 17:47 editováno autorem komentáře
Celkem nemám důvod to moc zkoušet. V pořádném IDE mám funkce na refaktorizaci. Najedu kurzorem myši na nějakou hodnotu a zobrazí se mi typ, jedním klikem se můžu dostat na deklaraci. Kód se mi automaticky zobrazuje s anotacemi ohledně historie v GITu. Syntaktická analýza se děla průběžně na pozadí a chybové hlášky jsou viditelné hned a odpovídající místa v kódu jsou automaticky vyznačena. Atd atd. Takže nevím, jaký bych měl mít vlastně důvod se místo toho zabývat Vimem?
No chtěl jsem říci, že leccos z toho Vim taky umí, třeba přes Syntastic. Já plnotučné IDE nepoužívám ani v Pythonu v práci. Když se podívám na https://areweideyet.com/ , je na tom každopádně nejlíp IntelliJ a VS Code. Já třeba Code mám nainstalované doma i v práci, ale prakticky nikdy ho nepouštím, ty věci co umí, jsou tak nějak přes ruku, nepřijde mi to intuitivní. A ta ruční konfigurace mi přijde taky šílená. Od včerejška mám IntelliJ a to se mi líbí podstatně víc (zkouším na něm Rust). Každému, co jeho jest, prostě to mám asi jinak.
Jak jsem právě zjistil, IntelliJ má pokud jde o Rust dost podstatné vady na kráse. Např. v něm doopravdy nefunguje debugger. CLion je na tom líp, jenže ten je za předplatné. Zaplatit za solidní IDE, proti tomu nic nemám, pokud je to jednorázová platba "no ifs and buts". Platit za licence rok co rok, to jednoduše nevedu, bez výjimek. Takže zpátky k VSCode.
Je divné, že by debugování nefungovalo v IntelliJ Idea a fungovalo v CLionu. S výjimkou nástrojů pro .NET jsou všechna IDE JetBrains založená na stejném kódu – IntelliJ Idea je vlastně „vše v jednom“ z těch IDE pro jednotlivé jazyky. Jediný rozdíl by mohl být, jestli jste nezkoušel Community edition, která logicky nemá všechny funkce jako plná verze.
Co se týče roční platby za licence, platíte za aktualizace. Pokud jste spokojen se současnou verzí, můžete koupit roční licenci a po skončení roční podpory vám zůstane licence na poslední verzi, na kterou jste měl nárok v době platnosti té podpory.
Mimochodem, zajímalo by mne, co vlastně programujete. Platit ročně 1 500 Kč za špičkové IDE vám připadá moc? Platit 125 Kč měsíčně za nástroj, který mi pomáhá pracovat efektivně, mi připadá dost málo. Licence pro organizace už jsou dražší, ale ty individuální jsou opravdu hodně levné.
Ne, nepřipadá mi to moc. Klidně bych zaplatil 50 000 Kč, pokud by to bylo formou jednorázové platby za časově neomezenou, bezpodmínečnou, nerevokovatelnou licenci. Licence typu "ransomware", kde se musí platit znova a znova a znova a znova z principu zásadně nekupuji nikdy a u ničeho. Je mi jedno jestli se jedná o 1500 ročně nebo o 1.50 ročně.
Druhý odstavec jste četl?
Připadá vám moc 1 500 Kč za časově neomezenou, nepodmínečnou, nerevokovatelnou licenci? Jak jsem psal, ty opakované platby platíte pouze v případě, že chcete dostávat aktualizace.
Jenom drobnost, v předchozím komentáři jsem napsal nepřesně, na jakou verzi máte nárok – nárok nemáte na poslední verzi, ale na tu, po které jste platil podporu alespoň 12 měsíců. Takže když si zaplatíte jenom tu roční podporu, budete mít nárok na tu hlavní verzi, která byla aktuální na začátku předplatného období, ne na konci. Ale z hlediska principu je to jedno.
7. 9. 2019, 11:53 editováno autorem komentáře
Případně můžete hlasovat zde: Make CLion available as IntelliJ plugin, aby ta rovnost platit začala…
nevím, z jakých informací vychází ta tabulka. Emacs má vestavěnou podporu pro gdb like debuggery a podporu dap přes balík
https://github.com/emacs-lsp/dap-mode#rust
ale souhlasím, že VS Code je dnes lepší jako IDE, sám ho používám
7. 9. 2019, 09:59 editováno autorem komentáře
VSC používám přes dva roky pro GOLang, ECMAScript 2017, GraphQL, Protocol Buffers
a další, nemohu si ho vynachválit. Je nutné ho dobře customizovat a doinstalovat pluginy. Například IntelliSense je úžasné, integrovaný terminál také úžasný, také pluginy pro auto testy super.
Zrovna před chvílí vydal Microsoft plugin pro vývoj v Docker kontejnerech, funguje to naprosto skvěle i na Microsoft Hyper-V
https://code.visualstudio.com/docs/remote/containers
Konečně nemusím řešit složité Docker interstage pro build Go, ale mohu dělat vývoj přímo v přizpůsobeném kontejneru.