Hlavní navigace

Názor ke článku Když vám vývojář pláče na rameni od Miloslav Ponkrác - [38] "Jsem nuceny jeden program psat na Windowsech...

  • 24. 1. 2009 5:30

    Miloslav Ponkrác (neregistrovaný)

    [38] "Jsem nuceny jeden program psat na Windowsech pomoci Visual Studia. Vadi mi toho dost"

    Ptal jsem se ne co vadí na Visual Studiu (které mimochodem ani zdaleka není jediný vývojářský nástroj na Windows), ale kde jsou ty skvělé vývojové nástroje pro Linux.

    "Neni moc dobra integrace s vimem (pres vimemu jen nektere verze, nic moc), coz me nuti pri psani vic pohybovat rukama."

    Píšu na Windows 99% svých textů ve vimu. Visual Studio je nějak integrované s vimem, ale špatně – není to moc užitečné. Nicméně celkem s vimem není integrované téměř nikde nic – je to samostatný editor.

    "Kdyz na Windows chci pouzit nejakou beznou knihovnu, musim jako nejaka blba sekretarka jit na webovou stranku te knihovny, stahnout si ji, vyextrahovat, jit do Visual Studia, … Na Linuxu clovek napise napr. "sudo apt-get install libcv1; vim Makefile" …"

    Ano, to je tragédie. :-) Zato na Linuxu, když ta knihovna není v depositáři každé distribuce, pak máte problém 100× větší, než na tom Linuxu. Pak Vám nestačí si jí stáhnout, ale ještě jí jako kretén musíte kompilovat, což je asi tam 1000× (a to to značně podceňuji) časově náročnější, než udělat ty kroky, které jste popsal pro Windows.

    Windows je v přístupu ke knihovnám absolutně jednotný. To jest neexistuje milión verzí knihoven, není nutnost jí balit do desítek balíčků pro každou distribuci jinak. Prostě většinou jen stáhnete a jedete. Díky tomu má také vývojář knihovny pod palcem celý proces – a má plně pod kontrolou, zda výsledná binární forma knihovny bude odladěná, nebo chybná. Na Linux, kde se mu do toho prasí ještě balíčkovači, kteří si knihovnu zkompilují, případně upraví mu také mohou vyrobit chybu, které padne na jeho hlavu.

    Já osobně vidím větší výhody v přístupu Windows. Stáhnout 2 soubory jako binární formu knihovny – to jest .lib a dokumentaci, případně pro sdílenou knihovnu 3 soubory – .dll, .lib a dokumentaci mi přijde jako velmi rychlý a optimální postup. Navíc je tu přímý kanál mezi vývojářem knihovny a mnou, a necpou se tam žádné mezičlánky typu balíčkovači distribucí. Navíc vývojář může vyvíjet a ne prosit x distribucí, aby mu zařadili jeho knihovnu do balíčkovacího systému. Čímž dostane také ultimátum, pod jakou licencí musí knihovna být, jinak mu nakopou. Což má také vliv i na rychlejší odbavení v případě nových verzí, či opravách chyb, pokud se o to vývojář stará.

    "To nemluvim o tom, ze programovat v necem jinem nez .Netu se na Windows neda, protoze v C/C++ jsou 4 nekompatibilni microsofti ceckovske runtimy (ruzne verze jsou take nekompatibilni, ale to je jasne), nikdo nikdy u knihoven neuvadi, s jakym runtimem jsou kompilovane distribuovane binarky a i kdyz je to nekompatibilni, tak to bohuzel jde zkompilovat."

    Programuji pro Windows mnoho let a neměl jsem s tímto jediný problém. Ani jeden, a co vím od známých, tak tento problém také nikdo nehlásil.

    Jinak Vás uvedu do problému, C i C++ jsou na každé platformě závislé na tom, kterou verzí kompilátoru jsou zkompilované – což platí stejně, ne-li daleko více pro gcc.

    "Dll hell …"

    Já zase blahořečím Windows vlastnost, že ke každé binárce první hledá sdílené knihovny v adresáři binárky hlavního programu. A velmi se směju, když linuxoví vývojáři jsou vydaní téměř na milost a nemilost tomu jakou globální knihovnu najde systém v hlavních adresářích. A kolik vývojářů na Linuxu řešilo problém, kdy strávili dny i týdny nad hledáním chyby aby přišli na to, že jim někdo v systému změnil .so na jinou verzi. Ne, že by to nebylo řešitelné, ale v Linuxu je to trochu ochcávačka – a tohle je přímo .so hell na druhou.

    "GUI rozhrani Visual Studia je sice hezke, zejmena pro debugovani, ale precijen s mensim propojenim s vimem je i s gdb radost pracovat a navic rozhrani gdb"

    Programuji 20 let, píšu ve vimu, gdb používat umím, přesto nechci používat gdb. Gdb mi nedává nic navíc oproti debuggeru ve VS, kromě pocetu. „že jsem velký hacker, protože si zpomaluji práci těžkopádným gdb“.

    Ke zbytku bych dodal – ani já bych se neodvážil kritizovat něco v čem neumím dokonale dělat. Například nikdy nebudu kritizovat emacs, protože ho neovládám. Vy jste ale při kritice VS daleko odvážnější, a neobáváte se kritizovat něco co nemáte v rukách.

    Jinak abych dodal: Mám Linux rád, a přál bych si, aby byl lepší. Tomu bohužel brání snaha za každou cenu ho malovat na růžovo.

    Umím perfektně dělat s makefile, gdb, vim, a dalšími nástroji – a pracoval jsem tak mnoho let. Dodnes udělám makefile pro projekty, které chci dlouhodobě udržovat. Ovšem přes všechny preference jsou to nástroje nevýkonné (s výjimkou vimu). Na abclinuxu.cz jsem kdysi nabízel soutěž – ať se člověk, který si věří se mnou zasoutěží ve vývoji nějakého rozumně většího projektu. On bude používat make + gdb a command line a já IDE a grafické vývojové prostředí. Garantoval jsem, že vyhraji, když projekt naprogramuji výrazně dříve, než ten s make + gdb, a když bude minimálně stejně spolehlivý, nebo spolehlivější. Nikdy neměl odvahu to zkusit.

    Od té doby považuji řeči o výkonnosti command line nástrojů (make, gdb a další) jenom za lživé kecy. Znovu říkám, mám mnoho let vyzkoušené obě cesty – jak command line cestu, tak IDE grafickou cestu. Cesta pure command line tools je neefektivní. A jeden z naprosto suverénně nejméně efektivnějších nástrojů je gdb.