Programovací nástroje pro Linux

16.8.2008 19:52 | Přečteno: 2865× | poslední úprava: 16.8.2008 21:08

Pokud jste právě přešli z Windows na Linux a jste programátoři jistě hledáte správné nástroje pro programování. Proto jsem dnes vytvořil pro „základní“ programovací jazyky výběr aplikací, které se Vám mohou jistě v Linuxu hodit. Doufám, že Vám toto pomůže při vyhledání vhodného nástroje. Jen malou připomínku na konec tento článek byl přezvat z mého oficiálního blogu http://www.martymcfly.cz

PHP
Pro vývoj PHP projektů se jistě bude hodit skupina následujících kvalitních nástrojů jako BlueFish, NetBeans 6.5 beta PHP, gPHPedit, Zend IDE, Screem či Quanta+. Pomocí těchto nástrojů můžete plnohodnotně pracovat. Zvýrazňování syntaxí, doplňování, označování řádků či kvalitní nápověda atd. Je základním vybavením těchto editorů. Navzájem se, ale liší svým pracovním rozhraním či možnostmi.

ASP.NET
Pro vývojáře APS.NET existuje i v Linuxu dobré vývojové rozhraní. Jmenuje se MonoDevelop. V této aplikaci můžete programovat v jazyce C, C# (ASP.NET), CPP a VBNet. Celé rozhraní vám jistě bude připomínat SharpDevelop, který možná znáte z Windows. Proto ovládání jistě nebude dělat nikomu problémy.

C/C++
Pokud programujete v jazyce C tak v Linuxu Vám mohu doporučit IDE Kdevelop nebo Anjuntu. Ovšem znalci použiji pro vývoj své aplikace v C klidně i editor Vim či Emacs. Jako překladač použijí jistě gcc (ten je běžnou součástí téměř každé distribuce). K ladění jistě dobře polouží gdb,ddd či valgrind. Další zástupci jsou například KDE Studio, VisKProg, VKDBuilder.

Pascal
Příznivci jazyka Pascal ocení jistě následujíc IDE Lazarus, Borland’s Kylix Open Editon či RHIDE. Ovšem Lazarus jistě bude ve většině distribucí asi nejdostupnější.

PERL a Python
Tyto dva jazyky jsou spíše situované pro Linux, ale dle mě je nutnost je zmínit. Pro Perl jistě oceníte wxPerl nebo PerlComposer. Pro Python Boa-Constructor či Cooledit, Jext nebo SPE.

Java
Programátoři v jazyce Java mají snad největší výběr nástrojů. Ovšem zmíním asi nejlepší NetBeans a další možnosti jsou jedi, JOODA, Sun One Studio 4, Exlixir, Amy či Anyl.Na základě komentáře doplním ještě Eclipse (díky za tip).        

Komentáře

[akomano]

Rád by som len doplnil Eclipse pre Javu. Aj keď je to vec osobného názoru, dovolím si tvrdiť, že eclipsa je v mnohom lepšia ako NetBeans a minimálne za zmienku stojí. Samozrejme, záleží od typu použitia, na klikanie GUI budú NetBeans šikovnejšie. Ešte malý detail, máš preklep v Python.

[multi]

nechapen jak mohl na eclipse zapomennout (osobne me NetBeans vubec nesedly), navic v ni delam i C/C++ a kamarad i PHP

[Joseph]

a pre python by som rozhodne nazabudol na eric3/4.

[zdenek-hbr]

netbeans je pro php fakt super. nejakej cas jsem pouzival eclipse, ale IMO netbeans je lepsi jeste kdyby tak existoval nejakej plugin pro AVR do netbeans...

[zdenek-hbr]

ztratila se mi tecka. sry

[anicka]

No kdyz uz bych nekdy psala seznam programu, ktere pouziva kazdy, tak bych u debugovani cecka nezapomnela ma valgrind :-P Windowsarum se jiste bude hodit i neco jako ddd, gdb byva zezacatku ponekud nepratelske.

[wasabi1]

Seznam je to relativně dost dlouhý. Jsem si vědom, že jsem něco mohl opomenout. Tak každopádně děkuju za tvoji připomínku jistě to doplním.

[Bluebear]

gdb byva zezacatku ponekud nepratelske

Kdyby jen ze začátku (Anebo jsem poněkud natvrdlý...)

[Luboš Doležel (Doli)]

gdb je hlavně pekelně zabugované.

[Deleted [8409]]

K ladění jistě dobře polouží gdb :)

[Michal Fecko]

...alebo 3 hladnych testerov =]

[AraxoN]

Mne sa celkom osvedčilo Geany - nie je príliš vyzložitené, ovláda syntax snáď všetkých bežne používaných jazykov (C/C++, Java, Perl, Ruby, Python, Pascal, shell, PHP, HTML, CSS, SQL, ...) a je aj inak nápomocný - zoznam funkcií, dopĺňanie názvov funkcií či premenných, buildovanie... A dá sa každému súboru nastaviť znaková sada, čo zvlášť ocenia webdeveloperi.

[toms]

K jave este bluej

[manasekp]

to je jenom orezana verze netbeans ne ?

[marbu]

To vazne nee. Ale existuje nejaky hybrid mezi nima.

[martin]

pro python: WingIDE, KomodoIDE, EasyEclipse for python.

[Daniel Kvasnička ml.]

Pro Python je IMHO zralejsi PyDev.

[RapMan]

Z windows pouzivam pouze Visual Studio (ano, jsem lama), proto bych chtel v linuxu neco podobneho. Nejvice se tomu podoba MonoDevelop, ale bez integrovaneho debuggeru je to pro me nepouzitelne (podruhe - ano, jsem lama).

[zdenek-hbr]

visual studio je kurevsky dobrej kus software. urcite to nepis tak jako ze jses lama protoze delas ve VS

[wasabi1]

Osobně jsem pracoval ve Visual Studio a myslím si, že pro C# atd. se jedná o opravdu velmi dobré IDE. Alternative k Visual Studiu je SharpDevelp, ale nemá dle mě takové kvality ovšem pro začátečníky stačí.

[RapMan]

ano, sam bych to lip nenapsal, VS je kurevsky dobrej kus software, proto v nem dokaze delat takova lama jako jsem ja (mysleno v dobrem smyslu). Vytvoreni aplikace s vyuzitim (i bez) OOP je pak otazkou chvilky, naklikani grafickeho rozhrani, debugovani, kompilace je hracka. Naproti tomu jsem v eclipse nedokazal udelat ani "hello world" podle dodaneho tutorialu pri prvnim spusteni.

[Luk]

VS je lepší než kterékoliv IDE běžící pod Linuxem. Bohužel je to tak. Z hlediska efektivity práce je to hodně znát. U VS mohu věnovat cca 99 % času skutečné práci, kdežto u Eclipse+CDT a Sun Studia (nebo NetBeans) tak 80-90 %, u Anjuty a KDevelopu 60-70 %, u ostatních IDE ještě méně (pokud je vůbec zprovozním).

[Radek Hladik]

Bohužel je to tak. Potřeboval jsem dělat na jednom projektu v C pod linuxem a marně jsem vzpomínal na moje oblíbené Delphi (a to nemyslím jazyk). Jsou to sice "drobnosti", ale je jich hodně. Potřebuju poměrně málo. Editor kódu se zvýrazněním syntaxe, doplňováním proměnných/fcí, překlad, zobrazení chyb/warningů a debugování.

Zatím nejlepší se mi jeví Anjuta. Editor docela funguje, překlad/linkování taky. Doplňování známých objektů vcelku taky, ale některé věci prostě nenabízí, i když jsou v .h, které je přímo inkludováno. Ale na čem jsem nejvíc narazil, je debugger. A co od něj chci? Přímo v editoru možnost nastavit breakpoint, krokovat řádek po řádku, zobrazovat hodnoty proměnných (a možná je i občas změnit). Například když nějaký program zavolá knihovnu, na které pracuju, tak bych rád ověřil, že všechno nastavil tak, jak měl.

Ano, gdb je možná pěkný, ale přímo ho používat, to je tak z minulého století. DDD jako jeho grafická nástavba vypadá hrozně, ač se už asi používat dá. Naštěstí je gdb do anjuty vcelku zaintegrované, takže to funguje jako součást IDE. Opět až na pár drobností. Zobrazené hodnoty proměnných se nedají hodit do schránky (nebo dokonce vytisknout), vyhodnocování výrazů funguje všelijak, takže najetí myší nad problematický výraz občas/většinou nefunguje, atd... Navíc by bylo fajn, kdyby mě prostředí alespoň upozornilo, že pokud se použije nějaké -O2, tak debugování sice funguje, akorát jsou pomíchaná čísla řádků - debugger pak po funkci bez jediného cyklu skáče v pořadí řádek 1,3,2 a ještě je to celé o dvě řádky posunuté nahoru a člověk se diví, zda blouzní on nebo počítač...

Když to srovnám s Delphi verze 1, ke kterým jsem před víc jak 10 lety poprvé sednul v labu na MatFyzu a místo půlky přednášky jsem vyrobil kompletní GUI aplikaci (převody jednotek)...

[Deleted [8409]]

Já jsem to vyřešil tak, že multiplatformní věci v C++ vyvíjím pod Windows (VS) a když potřebuju vyvíjet v linuxu tak mám rád KDevelop. Integrovaný debugger tam právě šlape přesně jak potřebuju a fungoje i výpis těch všech možných proměnných, stack frame, atd:)

Anjutu jsem zkoušel dřív, ale nenadchla mě.

PS: Ještě předtím než jsem znal linux bylo moje poslední IDE Borland C++ Builder a taky jsem si nemohl zvyknout na nic jiného:) Dokonce mám doma ještě originálku Borlandu pro DOS a Win3.1, to byla doba

[Vinicius]

Pro "Borlandovce" je tu prostredi RHIDE, jen by mu sluselo vice stability, otazka je jestli je na vine samotne RHIDE, nebo port knihoven Turbo Vision.

[anicka]

Ja budu za kacire, ale sama jsem presvedcena, ze jedine, na cem zalezi, je zpusob prace, na ktery je clovek zvykly. Ja "odjakziva" pisu cecko ve vimu, bugy lovim pomoci gdb a valgrindu a jsem tim padem presvedcena, ze nejlepsi IDE na svete je bash. Jsem na to zvykla, debugovanim se tak nejak zivim a jde mi to docela od ruky... rozhodne lip, nez s tim slovutnym kramem od Microsoftu.

Ve skole jsme to meli povinne a fakt jsem se cely semestr poctive snazila se s tim naucit, na cviceni chodila, dokonce jsem i extra do windowsiho labu obcas zasla ve volnem case... marne... nebyt toho, ze me nakonec zkousejici benevolentne nechal delat test pomoci vyse uvedenych nastroju, asi jsem sla dalsi rok znovu Myslim, ze i ke konci jsem tak 60 procent casu travila tim, ze jsem hledala, kde se vlastne sakrys co dela (mohlo mi jit vsechno, pravda, trochu rychleji, kdybych aspon s pomoci nekoho, kdo s tim umi, byla schopna zjistit, jak zvetsit pismenka, abych na to videla). Prvnich deset minut jsem obvykle venovala proste vyrobe noveho obycejneho ceckoveho projektu

Ale ja se nijak netajim tim, ze nejslozitejsi GUI, ktere jsem schopna ovladat, je webovy prohlizec a v nem internetove bankovnictvi

[Josef Kufner]

+1   !

[alblaho]

No já jsem před lety začínal na Delphi a Visualku (a souhlasím, že je to výborný soft), Javu jsem dělával v Eclipse.

Skončil jsem u geditu (Python, C) a gdb. A bash je slušné IDE

[happy barney]

jo, to som si dlho myslel aj ja ... a potom som objavil emacs (s emuláciou vi)

[Miloslav Ponkrác]

Ja budu za kacire, ale sama jsem presvedcena, ze jedine, na cem zalezi, je zpusob prace, na ktery je clovek zvykly.

Já budu za kacíře, ale dovolím si jako člověk, který se intenzívně pomocí C/C++ přes deset let živil, že to tak není. Výkonnost člověka při dobrém IDE (zdůrazňuji dobrém!!!) naroste tak neuvěřitelně, že byste mi nestíhala ani tehdy, pokud bychom se dohodli, že za týden Vaší práce ve vim/valgrind/gdb/bash mi dáte den na to, abychom naprogramoval stejně kvalitní a funkční kód jako Vy. A to myslím naprosto vážně.

Programoval jsem v několika operačních systémech a tvrzením, že bez dobrého IDE to jde lépe se obvykle výhýbám komentovat.

[springer]

v software inzenyrstvi se bezne uvazuje, ze v projektech je vykon tak 10 radku kodu za den. Tento udaj postaci rozumnemu cloveku na to, aby si uvedomil, ze to co rikate je totalni nesmysl.

IDE je vymysl softwarovach firem, ktere chteji prodavat produkty. S vykonosti v projektech to nema vubec nic spolecneho.

[Radek Hladik]

Můžu poprosit o nějaký odkaz? SW inženýrstvý jsem při studiu trochu nakousl, ale takovouto informaci si nevybavuju.

A tvrzení, že IDE je výmysl SW firem, které ho chtějí prodávat. Většina produktů je přece výmysl nějaké firmy a většina firem chce své produkty prodávat. Ale k tomu je potřeba, aby je i někdo kupoval. A že nemají nic společného s výkoností v projektech? To se asi pohybujeme v totálně rozdílných projektech. Samozřejmě, pokud se jedná o projekty, kde jde o super vymakané algoritmy, složité výpočty a podobně, tak beru i těch 10 řádek/den. Ale pokud se jedná o projekty, kde jde o "relativně jednodušší" funkcionalitu ve větším množství, tak IDE opravdu hodně zvyšuje efektivitu práce.

[Luk]

v software inzenyrstvi se bezne uvazuje, ze v projektech je vykon tak 10 radku kodu za den.

Pokud mě paměť neklame, tak při metodě COCOMO se jako základní údaj považovalo 50 řádků denně. Ale nic to nemění na faktu, že napsat (při rozdílně kvalitním IDE) průměrně 8 nebo 10 řádků (resp. 40 nebo 50) je rozdíl - může to být přesně takový rozdíl, který způsobí, že dá zákazník přednost konkurenci, protože bude (jinak při všech parametrech shodných) o tyto peníze levnější.

IDE je vymysl softwarovach firem, ktere chteji prodavat produkty. S vykonosti v projektech to nema vubec nic spolecneho.

Nesmysl. IDE je velmi dobrá věc, která umožňuje člověku nezabývat se zbytečnou otrockou prací a soustředit se na samotný vývoj. Proč by měl vývojář pokaždé řešit, jak napsat Makefile (nebo jiný podobný soubor), když ho to v podstatě vůbec nezajímá - většinou jde jen o nastavení pár důležitých parametrů, a ty se právě nastaví v IDE. O zbytek už se IDE postará. A takových věcí je tam spousta.

[anicka]

Proč by měl vývojář pokaždé řešit, jak napsat Makefile (nebo jiný podobný soubor), když ho to v podstatě vůbec nezajímá - většinou jde jen o nastavení pár důležitých parametrů, a ty se právě nastaví v IDE.

To je fakt. Proč psát slušný Makefile, když se může o kompilaci na mé mašině krásně postarat IDE. Jen ať několikanásobek toho času, co bych vyráběl Makefile, zabije někdo jiný, až se to bude snažit kompilovat na nějaké zcela jiné platformě.

(Netvrdím, že to tak musí být se vším, ale zrovna tohle je například z pohledu distribučního maintainera dost nešťastný příklad. Počítám, že takový Michal Vyskočil by to řekl ještě trochu jinak...)

[Luk]

To je fakt. Proč psát slušný Makefile, když se může o kompilaci na mé mašině krásně postarat IDE. Jen ať několikanásobek toho času, co bych vyráběl Makefile, zabije někdo jiný, až se to bude snažit kompilovat na nějaké zcela jiné platformě.

Jenže problém není v tom, že se používá IDE. IDE může také (přímo nebo třeba prostřednictvím autotools) ten Makefile vytvořit také, a to kvalitní. Jde o to, že ten Makefile se od aplikace k aplikaci většinou moc neliší. Jenže vrtat se v něm ručně, je (přinejmenším pro některé lidi, třeba pro mě) zdlouhavé a IDE to může vyřešit rychle a pohodlně.

[MJ]

Autotools a kvalitní makefile? V jedné větě? V jedné pozitivní větě???

Trochu vážněji: Pro malý projekt vám to stačí (ale tam vám stačí i za 5 minut napsat triviální makefile), v něčem větším obvykle potřebujete spoustu podmíněných překladů (program se dá překládat v hromadě konfigurací na hromadě různých OS) a zatím jsem neviděl GUI, ve kterém by se takové věci daly naklikat.

[Luk]

Autotools a kvalitní makefile? V jedné větě? V jedné pozitivní větě???

Proč by se z autotools nedal získat kvalitní makefile? Pokud nemusím autotools krotit ručně...

v něčem větším obvykle potřebujete spoustu podmíněných překladů

Není pravda. Přítomnost spousty podmíněných překladů svědčí obvykle o špatné koncepci vývoje. Dobrou zásadou je specifické věci vytěsňovat stranou a co nejvíc toho mít plně přenositelného. Někdy to příliš nejde, ale většinou ano.

[MJ]

Proč by se z autotools nedal získat kvalitní makefile?

Proti autoconfu nic nemám, ale viděl jste někdy makefile vygenerovaný automakem? Kdyby nic jiného, tak je naprosto nečitelný, a tím pádem také nedebugovatelný.

Není pravda. Přítomnost spousty podmíněných překladů svědčí obvykle o špatné koncepci vývoje. Dobrou zásadou je specifické věci vytěsňovat stranou a co nejvíc toho mít plně přenositelného.

S vytěsňováním specifických věcí stranou nelze než souhlasit, ale jaksi i o ty vytěsněné specifické věci se musí nějaká forma podmíněné kompilace starat.

[Luk]

viděl jste někdy makefile vygenerovaný automakem? Kdyby nic jiného, tak je naprosto nečitelný, a tím pádem také nedebugovatelný.

Viděl jsem ho mockrát, je odporný

i o ty vytěsněné specifické věci se musí nějaká forma podmíněné kompilace starat

To ano, ale už to nemusí být spousta podmíněného překladu, nýbrž poměrně málo. Tím spíš, že přímo v aplikacích se většinou takové platformově specifické záležitosti neřeší, je vhodnější to mít v knihovnách.

[Michal Vyskočil]

Počítám, že takový Michal Vyskočil by to řekl ještě trochu jinak...)

Teď nevím, co bych měl říct. Netbeans vytváří poměrně použitelný build.xml sám od sebe a Eclipse se k tomu taky dá dožduchat. S projektem z Intelli Idea jsem se tuším ještě nepotkal. Ale dokud mi někdo nepodstrkuje mavení skripty, tak si nemám na co stěžovat

[Deleted [8409]]

10 řádků za den ?

Toto bych chtěl vysvětlit, takto bych za celý život nenapsal ani blog

[rastos]

10 řádků za den ?

Nejde len o to, aby si napísal 10 riadkov kódu, ale o to, aby tie riadky boli dobré a nemusel si sa k nim vracať. Mám kolegu, ktorý robí v Delphi a spláca dohromady aplikáciu behom pár dní. Ale potom sa v tej aplikácii ešte hrabe roky a často prepisuje nezanedbateľný objem kódu.

Je pravdou, že IDE odľahčuje programátora od niektorých činností a preto prispieva k rýchlemu vytvoreniu prototypu. Na druhej strane ten, kto robí bez IDE programuje tak, že si veci najprv sakra premyslí, pretože vie, že meniť koncept po napísaní dvoch tretín kódu ho riadne zdrží. Takže ten, kto robí bez IDE, tak produkuje premyslenejší kód. A je z toho klasická dilema medzi kvantitou a kvalitou.

Ďalším problémom IDE (hovorím teraz prevažne o MSVC), je naviazanie na nejaký systém práce. Použijete nejakého wizarda, ten podmieni použitie nejakého toolkitu, a ten podmieni použitie nejakej platformy, ... -- Cheap, fast, good. Pick two.

[Josef Kufner]

Jo, taky jsem na to koukal celkem nedůvěřivě, ale když k tomu připrůměruješ čas strávený laděním, hledáním chyb, testováním a to že je občas potřeba něco přepsat, tak už to není až mimo. Taky záleží na fázi ve které projekt je. Zezačátku přibývají řádky rychle ale skoro nic to nedělá. Později přibývají řádky pomalu, ale zato rychle přibývají funkce a trávíš víc času dolaďováním detailů...

[podlesh]

Navíc se projekty neust8le udržují, opravují se bugy, doplňují se nové feature a tak dále, zákazník si stále něco vymýšlí. U většího projektu pak 10 řádek nemusí být zas tak málo - i u takové drobné změny je nutné ověřit, že nebude mít žádné nežádoucí následky.

Samozřejmě, právě v takových případech (udržování historického kódu, vesměs cizího) je IDE nejužitečnější, takže dad je jako obvykle mimo.

[JS]

To pravidlo s temi radky je legracni. Poprve jsem o nem cetl v knizce Bity do bytu, kde bylo jako 20 radek za den, vcetne ladeni, a to v assembleru. Me osobne se 10 radek zda malo, ale napriklad u me je to silne individualni. Pokud nevim, co chci (a treba premyslim prilis nad designem, coz mi jde spatne), tak se dostanu asymptoticky i pod 1 radek za den. Pokud ale vim presne, co a jak chci naprogramovat, a mam pohodovou naladu a chut do prace, jsem schopen udelat i 100 radek za den v assembleru (vcetne ladeni, bez komentaru).

Navic je otazka, jak to souvisi s jazykem. U vyssich jazyku jedna radka dela vic, ale zase muze byt slozitejsi na pochopeni. A taky nemusi.

Ale urcite plati, ze zmenit velky program je tezsi (pomalejsi) nez psat program cely znovu. Take dost zalezi na tom, kolik toho programu clovek momentalne drzi v hlave.

Navic treba u nas ve firme to neni jenom napsat ten kod, ale musim ho jeste otestovat (vymyslet, napsat a popsat testy), a napsat dokumentaci. A to zabere casto vic prace nez napsat ten samotny kod.

[anicka]

Jojo, a největší lež je statistika... Že by to vycházelo vždycky stejně, ať zaměstnáváme elitní programátory nebo opičky? Ať píšou kód v Haskellu nebo v Javě? Ať píšou GUI dělající triviální práci, nebo nový filesystém?

Osobně odmítám věřit byť jen půl dalšího slova komukoliv, kdo se podobnými obecnými odhady zaštiťuje

[JS]

No nejlepsi je, ze ti nahore takove odhady chteji! Ted nam s kolegou (spoluzak z jaderky, take zacatecnik v oboru jako ja) dali za ukol, protoze nemame poradne co na praci (aspon dokud se neco neschvali), abychom neco takoveho odhadli (aby se to mohlo schvalit). Byli jsme z toho oba dost nestastni, protoze jsme meli pocit, ze by vyslo rychleji, kdybychom to proste rovnou pri te analyze zmenili. A nejdriv nam vyslo (podle tech tabulek, kolik kdo napise radku za den), ze by nam to trvalo strasne dlouho, tak jsme to stejne pak museli delat nejak jinak.

No ja to zatim vyresil salamounsky - neco jsem si u toho vesteni programoval jen tak pro sebe, a to tak intenzivne, az me zasahla nemoc a poslala domu. Bohuzel me nejak doktori nechteji zatim poslat zpet do prace.

[Filip Jirsák]

Asi je rozdíl v tom, zda člověk pracuje stále na několika málo projektech, kde si může projekt a IDE sobě navzájem přizpůsobit – a pak v tom projektu píše hodně kódu. V takovém případě je IDE asi neocenitelné. Pokud na druhou stranu člověk potřebuje tu upravit 10 řádků v jednom programu, tu zakomentovat 3 řádky v jiném (a v jiném jazyce), musí pracovat s nejrůznějšími VCS, nejrůznějšími způsoby patchování atd., pak je asi používání sady řádkových nástrojů a vimu nebo emacsu rychlejší.

[anicka]

Výkonnost člověka při dobrém IDE (zdůrazňuji dobrém!!!) naroste tak neuvěřitelně, že byste mi nestíhala ani tehdy, pokud bychom se dohodli, že za týden Vaší práce ve vim/valgrind/gdb/bash mi dáte den na to, abychom naprogramoval stejně kvalitní a funkční kód jako Vy. A to myslím naprosto vážně.

Pokud budete rychlejší, věřím tomu, že to bude proto, že prostě umíte líp programovat a nebude to mít nic společného s IDE. Čemuž jsem klidně ochotná věřit, já toho kódu zatím až tak moc nenapsala, já jen uklízím po jiných. Deset let zkušeností s intenzivním hackováním asi nedám, kdyby ano, bylo by na tom něco špatně

Ovšem jsem ochotná vsadit pytel čaje v hodnotě celodenní výplaty, že ani se svým IDE nebudete s céčkem stačit dejme tomu Pavlovi Machkovi, Honzovi Károvi nebo MJovi, i kdybyste se rozkrájel na kousíčky a každým kousíčkem hackoval paralelně. Nepřijde mi jako náhoda, že všichni nejlepší programátoři, které znám, jsou s vimem rychlejší než téměř každý s čímkoliv chce a nemyslím, že Vy budete výjimka. Ne, s bandou kernelových hackerů v zádech Vám neuvěřím, že existuje "dobré" IDE, které udělá z kohokoliv lepšího programátora

Ale chápu, že pokud tu zkušenost nemáte, tak mi možná nevěříte. Pokud je tomu tak, klidně se pokusím ten duel zorganizovat, MJ by do toho za kilo nového Formosa oolongu téměř určitě šel

[Ladicek]

Jako člověku odkojenému na různých IDE (od Turbo Pascalu a Delphi po IntelliJ IDEA) mi jde vždycky hlava kolem, když začnu přemýšlet, jak asi ti kerneloví hackeři dokážou se zmíněnými prostředky pracovat s takovou hromadou kódu. Jak hledají všechna použití dané funkce a jak ji hromadně nahrazují… s ledasčím možná pomohou ctags, ale stejně: jak to dělají? Nebo je to jenom v tom, že jsou prostě lepší než my, normální lidi, a dokážou to i s grepem a sedem?

[MJ]

Ctags, občas také cscope nebo cspot. Ale často opravdu grep a sed, mimo jiné proto, že v kódu tak moc prolezlém makry a podmíněnými překlady se stejně nástroje, které se snaží rozumět syntaxi, orientují dost špatně.

Ono na tom vlastně moc nezáleží – když se snažím odhadovat, kolik času spotřebuji na nahrazování volání nějaké funkce, vychází mi něco jako jedno procento. To nemá valný smysl optimalizovat.

Nalezení definice funkce je samozřejmě jiná písnička, to používám velice často, jenže na to úplně stačí staré dobré ctags.

[Luk]

mi jde vždycky hlava kolem, když začnu přemýšlet, jak asi ti kerneloví hackeři dokážou se zmíněnými prostředky pracovat s takovou hromadou kódu

Ono je to do značné míry tím, jak člověk myslí, jaké má myšlenkové pochody. Pro někoho není problém naučit se a bez problémů používat obrovské množství klávesových zkratek (a proto preferuje například vim), někdo jiný (včetně mě) velmi ocení, když pracuje v prostředí, které poskytuje jiné prostředky pro přístup k funkcím.

Nebo je to jenom v tom, že jsou prostě lepší než my, normální lidi, a dokážou to i s grepem a sedem?

Nejsou lepší, jsou jiní. Dokáží pracovat s low-level nástroji, ale mnohdy jim zase uniká mnoho aspektů toho, co vyvíjejí. To je mimochodem jeden z velkých problémů mnohého svobodného SW - že ho vytvářejí právě lidé, kteří jsou hodně "hardcore" a například se často nedokáží na program podívat pohledem BFU.

[MJ]

To je mimochodem jeden z velkých problémů mnohého svobodného SW - že ho vytvářejí právě lidé, kteří jsou hodně "hardcore" a například se často nedokáží na program podívat pohledem BFU.

Mnozí to bez problémů dokáží, ale povězte mi, proč by se tak vlastně měli na program dívat? Málokdo považuje za smysl svého života psát programy pro BFU, lidé pro radost spíš programují věci, které se hodí jim samým.

Proto také mezi free softwarem najdete nejvíc nástrojů pro programátory a adminstrátory, a pak také spoustu her, zato balíků pro kancelářské myši je pomálu (tedy mimo solitéru, to je beztak nejdůležitější kancelářská aplikace, a tam Linux jasně vede ).

(Fortunka o tom říká: "Píšete-li program tak, aby ho mohli používat i blbci, riskujete, že ho budou používat jenom blbci.")

[Luk]

proč by se tak vlastně měli na program dívat? Málokdo považuje za smysl svého života psát programy pro BFU, lidé pro radost spíš programují věci, které se hodí jim samým.

Nechť si každý tvoří programy, pro koho chce. Ale pak se nemůže divit, že lidé dají raději přednost proprietárnímu programu, třeba od Microsoftu

(Fortunka o tom říká: "Píšete-li program tak, aby ho mohli používat i blbci, riskujete, že ho budou používat jenom blbci.")

Platí toto také třeba o Firefoxu?

[MJ]

Ale pak se nemůže divit, že lidé dají raději přednost proprietárnímu programu, třeba od Microsoftu

Já jim to také nikterak nemám za zlé. Pokud nalézají své štěstí tam, proč ne. Tedy když dokáží pochopit, že to není jediný svět a že posílat mailem wordovské dokumenty nic netušícím obětem je čuňačina.

Platí toto také třeba o Firefoxu?

Žel zrovna Firefox k tomu v poslední době povážlivě konverguje...

[JS]

Mnozí to bez problémů dokáží, ale povězte mi, proč by se tak vlastně měli na program dívat? Málokdo považuje za smysl svého života psát programy pro BFU, lidé pro radost spíš programují věci, které se hodí jim samým.

Ja si myslim, ze tento problem ma reseni. Oddelit navrh GUI od aplikace natolik, aby se GUI dalo navrhovat v nejakem GUI a nevyzadovalo takrka zadne znalosti programovani (a linkovalo se k aplikaci dynamicky). Pak by si BFU vyhrali s GUI v GUI a programatori by si mohli vesele dal programovat sve operacni systemy a podobne veci. Jiste jsou zde problemy, jako custom widgety pro graficky program a podobne, ale to by s trochou snahy slo poresit. Neco podobneho uz de facto mame u webovych aplikaci - HTML/CSS definuje GUI a aplikacni logika na serveru definuje ten program samotny.

[Kvakor]

To opravdu nejlepsi metoda - zaprve se ustavenim rozhrani vyresi dost problemu, na ktere by se jinak prislo pozde, zadruhe je metoda frontend/backend vyhodna v tom, ze se mohou kombinovat zcela rozdilne jazyky - napr. u GUI je zcela nepodstatne, je-li v interpretovanem jazyce, protoze se stejne vetsinu casu ceka na uzivatele nabo na vykresleni prislusneym toolkitem.

[trekker.dk]

napr. u GUI je zcela nepodstatne, je-li v interpretovanem jazyce, protoze se stejne vetsinu casu ceka na uzivatele nabo na vykresleni prislusneym toolkitem.

Pokud ovšem ten interpretovaný jazyk není tak pomalý, že vykreslení GUI trvá půl dne.

[JS]

Kdyz ja bych prave nechtel, aby ten jazyk pro GUI byl Turingovsky uplny. Spis si predstavuji neco jako HTML/CSS + sablonovaci system. Turingovska uplnost by totiz ty BFU, co si to budou kreslit v tom editoru, svadela na scesti (no spis tim chci rict, ze by bylo tezke udelat pro to rozumny GUI editor).

[trekker.dk]

Spis si predstavuji neco jako HTML/CSS + sablonovaci system.

Jo, to je přesně příklad jazyka, kde se všechno bude vykreslovat půl dne.

[JS]

No, takhle, ja bych nebyl proti tomu kompilovat a dynamicky linkovat to GUI s tou aplikaci. Jde mi spis o to, co bude vystupem z toho GUI editoru jako mezifaze. Proste jazyk, kde budu moci definovat veci typu "tady v teto kolonce je cislo od 1 do 100 a kdyz ho uzivatel zada, ma se zavolat takova a takova funkce".

[happy barney]

Y windows ?
nad niečím podobným vo voľnom čase premýšľam, základná myšlienka je však len v tom, aby som mal na toolkite nezávislý popis, runtime linkovaný s užívateľom definovaným toolkitom

[JS]

Ano, ta zakladni myslenka je jednoducha, ja take nikde netvrdim, ze jsem vynalezl neco prevratneho. Y Windows je trochu ambicioznejsi, protoze Y Windows navic resi sitovou transparenci, a to ja nechci, alespon v prvni fazi ne (to prinasi dalsi problemy - synchronizace, rychlost, bezpecnost). Ja bych si predstavoval rozhrani na urovni posilani signalu (neco jako connect v Qt) a sdileni datovych struktur standardizovanych pro nektere slozitejsi widgety (treba pro RichText nebo graficky editor), a typovou kontrolu, mozna i nejakou jednoduchou validaci. Dulezita soucast toho projektu by ovsem melo byt to GUI, kde by bylo mozne navrhovat (bez programovani) ta GUI pro konkretni aplikace.

Ja se tim nechci ovsem zabyvat, protoze je to slozite a mam jine zajmy; akorat bych to proste rad videl.

Rad bych ale upozornil na zajimavy paper o necem podobnem.

[Filip Jirsák]

Problém je, že pokud chcete udělat opravdu dobré interaktivní GUI, dříve či později narazíte na potřebu pro nějakou komponentu definovat nějaké speciální chování. Buď se můžete pokusit všechna taková použití předvídat a udělat strašně složitý popis toho GUI (a stejně nepostihnete vše), a nebo dostanete GUI na úrovni současných AJAX aplikací, které má dost daleko k tomu, jak dnes vypadá desktopová aplikace s pohodlným ovládáním (a běžně je trumfne i kdejaká TurboVision aplikace blahé paměti).

[JS]

Takhle, ja si myslim, ze ten standard by mel samozrejme zahrnovat definici specialnich komponent specifickych jen pro ten urcity program. Ty by pak samozrejme menitelne nebyly ani v ramci toho GUI editoru. Ale 99% veci uz je dnes v GUI standardizovanych a ty by mozna menitelne byly. Proste, kdyz se divam do dokumentace Qt, tak spousta signalu a slotu je navzajem propojitelnych bez jakekoli nutnosti prevadet data mezi nimi, a maji standardni druhy parametru, ktere dostavaji/vydavaji. A prave takove signaly/sloty by bylo mozne navzajem propojovat v tom editoru.

[Deleted [8409]]

Tak si pomocí takové metody zkuste něco udělat:)

Já nevím, ale lidi by se občas měli podívat do dokumentace Qt a Gtk, aby zjistili, že toto nejsou žádné lehké gui toolkity. Integrace a snadnost použití různých věcí žene kvalitu výsledých programů dopředu. V Qt máte taky model-view architekturu, to je přesně o čem mluvíte, ne ? Akorát to máte všechno pohromadě a hezky integrované:)

Kdybych odbočil, tak úplně triviální příklad je .net, sjednotit runtime různých jazyků - to je ta integrace. Snadná schopnost použít jiný kód, který někdo napsal v jiném jazyce, ...

[Deleted [8409]]

Ale vaše řešení přece ve světě webu funguje

Ale nevím nevím, radši si pomocí dědičosti udělám svůj widget v toolkitu, než abych ladil HTML+CSS+skriptování. Jako by těch problémů nebylo málo, že :)

[JS]

No vzdyt ja prave davam svet webu tak trosku za vzor desktopovym aplikacim. Ne ve vsem, samozrejme - HTML/CSS a spol. nebyly puvodne vubec navrzene pro aplikace, a nejsou na ne nijak zvlast vhodne. Ale to oddeleni logiky od prezentace je udelane pomerne hezky, i kdyz pro desktop je to stale prilis jednoduche, a tak se to obchazi Javascriptem.

Me by se proste libilo, kdyby widgety jako takove byly samostatne linkovatelne objekty, ktere by si definoval uzivatel v nejakem GUI. A pak by v tom GUI propojil tyto objekty s funkcemi, ktere poskytuje aplikace. Takze napriklad misto toho, abyste si vy v aplikaci zdedil dejme tomu QTextEdit, a predefinoval si metody, ktere potrebujete, tak byste mel v aplikaci tridu, ktera by pracovala s textem v pameti podle nejakeho definovaneho rozhrani, ale nestarala by se nijak o vykreslovani a interakci s uzivatelem. Stejne tak i ten GUI editor by pouzival zase jinou tridu, ktera by pristupovala k te stejne sdilene pameti (podle operaci, ktere by si uzivatel definoval v tom GUI editoru). A pres tu sdilenou pamet by se to pak propojilo. Vtip by byl v tom, ze usporadani te sdilene pameti by bylo standardizovane (podobne jako je castecne standardizovane, jakym zpusobem se predavaji parametry formularu), takze by ten GUI editor mohl vytvaret widgety pro libovolny toolkit. Take by bylo mozne vzit GUI z aplikace, editovat ho (zmenit treba polozky v menu, klavesove zkratky a i divocejsi veci), a pak s nim tu aplikaci dynamicky linkovat.

Porad by to vyzadovalo urcitou komunikaci navrhare GUI s programatorem (custom widgety napriklad), ale tim, ze by se tyhle 2 role uplne oddelily, by programatori nemuseli GUI resit skoro vubec a naopak lide, kteri neumi programovat, ale chteji si GUI vice zmenit by meli tu moznost. Take by to umoznilo mnohem vetsi miru experimentovani s tim, jak ma GUI vlastne vypadat.

[jkb]

myslim, za na linuxsoftu vyjde pristi mesic serie clanku o linuxovych frameworkach a jedna cast se bude prave zabyvat nejakym takovym podobnym klientem. To, co jste ve Vasich prispevcich zde na nekolika mistech nadhodil je skutecne realizovano.

[Deleted [8409]]

Jenže tady jde hlavně o rychlost vývoje. Když dělám nějaké GUI tak narážím na to, že potřebuju vlastní widgety a čím bude komplikovanější tyto widgety udělat, tím bude popularita daného frameworku nižší.

Proto jak jsem psal, vždy vyhraje framework, který integruje mnoho věcí a hlavně je jednoduchý. Váše myšlenka zní sice jednoduše, ale kdyby jste se tímto problémem začal zabívat, zjistíte, že se jedná o velmi komplikovanou věc, kterou nejste schopen udělat (nic proti vaši schopnosti, já bych to taky nedokázal:) ).

Mám ale pocit, že někdy jde lidem spíš o to, jaký použít toolkit pro zobrazení GUI, a toto je podle mě největší utopie:)

[JS]

Ja s tim nesouhlasim. Ze je neco jednoduche jeste neznamena, ze je to z hlediska navrhu dobry napad. Navic si nemyslim, ze by custom widgety byly o tolik tezsi - slo by spis o to rozmyslet si, ktere casti jsou soucast GUI (treba poloha tlacitek, zda je urcita funkce v tom custom widgetu dostupna pres prave menu nebo pres tlacitko v tom widgetu a podobne) a ktere jsou casti toho widgetu jako takoveho (pokud existuje udalost posun widget vpravo o tolik a tolik, co se ma v nem ukazat). Ty prvni by sly naklikat a zmenit v tom GUI editoru, ty druhe ne; a proto by ty prvni nemely byt v aplikaci natvrdo, a ty druhe ano.

Komplikovany problem to mozna obecne je, ale to neznamena, ze ho nelze v prvnim priblizeni na 80-90% vyresit. Prave proto, ze lidem tolik zalezi na toolkitu a na finalnim vzhledu si myslim, ze by bylo velmi vhodne, kdyby si i neprogramator mohl GUI z velke casti "naklikat", misto aby nekdo zacal prepisovat aplikaci v jinem frameworku, jak se to deje dnes.

[Josef Kufner]

Klucí, napište o tom samostatný zápisek, tohle si zaslouží trošku víc prostoru...

[wasabi1]

Souhlasím, takhle problematika je dost zajímavá

[Deleted [8409]]

Už mlčím

[Josef Kufner]

To nemělo být abys mlčel, ale abys kecal víc

[Deleted [8409]]

Nepochopil,

jednoduchý pro mě neznamená, že je jednoduše udělaný, ale že se jednoduše používá (to je pro mě třeba Qt).

[springer]

...Pokud je tomu tak, klidně se pokusím ten duel zorganizovat, ...

rad bych mladsi kolegy, kteri jeste hledaji svou roli v partnerskem vztahu upozornil na jednu exemplarni zenskou vlastnost, kterou prave anicka dokumentovala:

at uz jde v zivote o cokoliv, zensky to zacnou organizovat ...

[Dalibor Smolík]

at uz jde v zivote o cokoliv, zensky to zacnou organizovat ...
Svatá pravda

[MJ]

No, je to zajímavé IDE, ale jaksi mu chybí slušný editor. Snažil jsem se s různými podobnými potvorami nějaký čas vycházet v dobrém a naučit se je ovládat, ale pak jsem si uvědomil, že ve Vimu se dá psát daleko efektivněji.

A s debuggerem je to podobné – GDB na první pohled vypadá odtažitě, ale jakmile potřebujete ladit něco netriviálního, tak se jeho schopnosti (třeba breakpointy na změnu dat) proklatě hodí. Krokovat a sledovat přitom kurzor skákající po zdrojáku opravdu nepotřebuji – jednak si to snadno představím i bez debuggeru, jednak se spousta bugů stejně projeví po několika miliardách průchodů nějakým cyklem, na což je krokování nanic.

[Radek Hladik]

Pokud je někdo zvyklý psát ve vimu (což já nejsem), tak chápu, že mu na tvorbu kódu vyhovuje. Ale debugování se "skákáním po zdrojáku" je opravdu věc, která není na nic ani u složitých projektů. Už podle názvu se debugování používá v případě, že něco nefunguje jak má. A především, pokud spolupracuje víc lidí, je potřeba chybu nejprve najít. Pakliže mám fci:

x=ziskejvstup();
x=provedvypocetA(x);
y=provedvypocetB(y);
if (x>y) z=x*provedvypocetC(y); else z=provedvypocetD(x);
vypis(z);

a tato fce vrací něco jiného, než co by měla, tak je velice snadné na první řádku hodit breakpoint, spustit jeden krok, najet myší nad x a zkontrolovat hodnotu, další krok, zase zkontrolovat x,...

Nebo píšete plugin do něčeho složitějšího a v dokumentaci je napsáno něco jako "vaše fce jako parametr obrdží proměnné in a out. V in budou data, vy provedete požadovanou operaci a výsledek umístíte do out". Když zjišťujete, proč to nechodí, tak zjistíte, že nějakým nedopatřením data dorazila v proměnné out místo in. Pak se skákání po kódu s rychlou kontorolou hodnot opravdu hodně hodí, pokud chcete projet celý cizí kód až do místa, kde vás volá a zjistit, kde se stala chybka...

A breakpointy na změnu dat považuju za naprosto samozřejmou věc, to má každé slušné IDE

[Josef Kufner]

a tato fce vrací něco jiného, než co by měla, tak je velice snadné na první řádku hodit breakpoint, spustit jeden krok, najet myší nad x a zkontrolovat hodnotu, další krok, zase zkontrolovat x,...

Což při tisícovce iterací je velmi zábavné a tato zábava vydrží vélmi dlouho

[Radek Hladik]

Koneckonců člověk musí zapojit svojí inteligenci, že

Většina debugerů umí kus kódu přeskočit, takže je možno otestovat výsledek až po té tisícovce iterací. A pokud se ukáže, že před vstupem do cyklu bylo vše OK, a po něm je něco špatně, tak je pravděpodobné, že chyba je právě v tom cyklu. A hlavně, často se chyba (nebo alespoň její náznak) projeví při několika prvních iteracích...

Každopádně to se netýká toho, co jsem říkal. Já jsem tvrdil, že integrovaný debuger do editoru značně zrychlí a zpřehlední vlastní debugovaní. To že jsou situace, kdy to nestačí je snad jasné - koneckonců ani ten nejlepší debuger mi neposeče trávu na zahradě...

[happy barney]

prečo musí byť integrovaný debuger v editore? prečo nepostačuje schopnosť editora komunikovať s externým debugerom ?

[Josef Kufner]

Nemusí být integrovaný. Stejně dobrý je externí, který ten kód ukáže, třeba DDD. Nevýhodou externího je, že pak v tom editoru si musíš odpovídající kus kódu najít, ale to není nijak hrozné -- stačí naťukat číslo řádku a případně kus jména souboru. Výhodou je, že UI debugeru nezaclání v editoru a můžeš mít UI optimalizované pro oba dva "režimy" práce současně.

[happy barney]

he? vravím komunikovať, nie spúšťať ... za príklad dávam emacs, ale aj vim to zvládne minimálne na rovnakej úrovni, a bez množstva dekorácii

[Radek Hladik]

Nemusí být integrovaný v editoru. Stačí, když se na pozadí používá třeba to gdb. Podstatné pro mě je, aby se veškerá moje komunikace s debugerem dělala přes editor a IDE. Pustit si jinde DDD a přeskakovat z něj do jiného editoru je sice o kus lepší, ale pořád to není dostatečně komfortní...

[MJ]

To, co jste popsal, je krásná ukázka případu, kdy se krokování vůbec nehodí. Daleko lepší je přidat si do programu průběžné vypisování hodnoty x, program spustit a pak si pohodlně přečíst, jak se hodnota vyvíjela.

[JS]

Souhlas. Ja osobne debugger pouzivam malokdy (ladici vypisy jsou obvykle rychlejsi cesta k vysledku, nez dostat program v debuggeru do stavu, kde ho chci mit), i kdyz ted co programuji v assembleru ho obcas pouzivam na ruzne zahady (prepisujici se pamet apod.). Ale i tak je ten overhead casto vetsi, nez to nechat proste spadnout na vhodnem miste a podivat se do dumpu.

[podlesh]

Také jsem tak dělával, když jsem ještě psal převážně v C. Docela dobře to funguje, dokud je kód psán velmi defensivně, udržován čistý a průběžně pečlivě testován.

Problém nastává hlavně když je projekt větší a dělá na něm více lidí. Tam už je pak docela problém udržet disciplínu.

[JS]

Tak jsem nad tim jeste premyslel, a zda se, ze s debuggerem je hlavni problem, trefit se pred to misto, nez dochazi k te samotne chybe. Pokud se totiz netrefite a skoncite az za ni, musite to pustit cele od zacatku, protoze v debuggeru se divate jen na jeden stav a navic nemuzete zpet. Naopak u ladicich vypisu muze clovek behat tam a zpet, pulit interval apod., takze muze nektere chyby skutecne odhalit rychleji.

Mozna by pomohly reverzibilni debuggery nebo debuggery co by si byly schopne zapamatovat urcity stav, a provadet treba puleni intervalu. Ale to je zatim asi hudba budoucnosti.

Tak me napada, cetl jsem ted jistou Feynmanovu knizku o pocitacich, a ma tam i reverzibilni pocitace. Myslim, ze tam dokazuje, ze abychom mohli provadet vypocet pozpatku (treba krokovat zpatky v debuggeru), tak nam staci akorat 2x tolik pameti nez pro puvodni program. Akorat by mozna byl problem s vecmi jako sitova komunikace, ta by se asi musela ukladat nejak zvlast.

[Filip Jirsák]

Mozna by pomohly reverzibilni debuggery nebo debuggery co by si byly schopne zapamatovat urcity stav, a provadet treba puleni intervalu. Ale to je zatim asi hudba budoucnosti.

Debugging Backwards in Time – odkaz vede na Google Video.

[JS]

Jo diky. Myslim ale, ze o tomto konkretne jsem uz slysel. Ukladat stav celeho programu muze byt ale dost silene; rad bych proto take videl debugger zalozeny na principech reverzibilniho pocitani.

[MJ]

Myslim, ze tam dokazuje, ze abychom mohli provadet vypocet pozpatku (treba krokovat zpatky v debuggeru), tak nam staci akorat 2x tolik pameti nez pro puvodni program. Akorat by mozna byl problem s vecmi jako sitova komunikace, ta by se asi musela ukladat nejak zvlast.

Moc si tuhle redukci nepamatuji, ale není to náhodou tak, že se lineárního prostoru dá dosáhnout jen za cenu značného prodloužení výpočtu?

(Jinak používat na reverzibilní debugování překladač do reverzibilního kódu je velmi pěkný nápad, jen asi v praxi nepříliš použítelný, protože reverzibilní syscally ještě kernel neumí.)

[JS]

Takhle, ja tu knizku jeste nedocetl (akorat mam pocit, ze to tam dokazuje), ale nevidim duvod, proc by to melo zabrat vyrazne vic casu. Akorat proste nekam musime ulozit tu informaci, kterou jsme mohli ztratit pri tech nevratnych operacich. Pokud z teto informace dokazeme zrekonstruovat tu predchozi informaci pro kazdy krok, tak uz to pak svedeme pro vsechny kroky.

Jinak mas pravdu - takovy debugger by musel asi emulovat cely hardware, jinak si to nedovedu predstavit.

[MJ]

Kdybyste jednoduše ukládal změny, pak by spotřeba paměti reverzibilního programu nebyla násobkem paměťové složitosti původního programu, ale časové… Takhle jednoduše to bohužel nejde.

[JS]

Ja vim, ale mam za to, ze on ty zmeny prave uklada nejak chytre. Asi jsem se ale pustil na tenky led, kdyz jsem to tvrdil, ted presne nevim, jak to dela (nemam tady sebou tu knizku a jeste jsem ji necetl, akorat mi to z ni utkvelo v pameti, takze jsem mozna dost mimo). Ale myslenka je, ze pouziva reverzibilni operatory a ma dve pametove banky. V jedne je na zacatku vstup vypoctu a v druhe je 0. A pouziva operace, ktere jsou sice reverzibilni na obou bankach dohromady, ale na te prvni nejsou, a tim mu na konci vypoctu vypadne vysledek v prvni bance a v te druhe bance nejake smeti. A protoze ty operace byly na obou bankach reverzibilni, tak je z toho vysledku a smeti mozne vypocitat zpatky vstup a nulu (zname-li navic poradi operaci). Neco podobneho se pouziva i v kvantovych pocitacich IMHO, kde jsou vlastne vsechny operace reverzibilni.

Ale je mozne, ze to casove narocnejsi bude, pokud prepocitat novy stav te druhe banky zabere nejak nepomerne vic casu. To by me tedy zklamalo.

[MJ]

Pokud to dočtete, dejte vědět, také by mne to zajímalo.

Mimochodem, krátké povídání o reverzibilních výpočtech spolu s pár příklady jsem před lety napsal jako seriál úloh do MO-P. Zkuste zalovit v archivu olympiády, je to 52. ročník.

[Radek Hladik]

Tak jsem nad tim jeste premyslel, a zda se, ze s debuggerem je hlavni problem, trefit se pred to misto, nez dochazi k te samotne chybe. Pokud se totiz netrefite a skoncite az za ni, musite to pustit cele od zacatku, protoze v debuggeru se divate jen na jeden stav a navic nemuzete zpet. Naopak u ladicich vypisu muze clovek behat tam a zpet, pulit interval apod., takze muze nektere chyby skutecne odhalit rychleji.

To je problém i u ladících výpisů. Buď jich musíte nasekat do kódu nehorázné množství nebo použít třeba to půlení intervalů. Tzn. dát si jich několik, pak to spustit, přidat další výpisy podle toho, kde něco nesedí, znovu spustit,... A to se dá snadno použít i s debugerem. Dojedu tam, kde vím, že už je něco špatně, podívám se na stack trace, odhadnu, kde se tak chyba asi může začít objevovat, dám si tam breakpoint, znovu spustím a půlím intervaly. Výhodou je, že při půlení "po směru" běhu programu můžu breakpointy přidávat bez problému. A protože můžu spouštět celé funkce jako jeden skok, tak je to někdy velmi rychlé...

A pokud mi debuger umožňuje měnit hodnoty proměnných tak dokonce v některých případech můžu chybu "opravit" a koukat, zda dál je všechno v pořádku...

[MJ]

U slušně napsaného kódu jich často to nehorázné množství je už předtím, než začnete ladit, a stačí je pouze povolit. Navykl jsem si programovat tak, že z toho, co program vypisuje, je dobře vidět, jak se výpočet vyvíjí, a už mi to ušetřilo spoustu práce. Vlastně mám v přehledné podobě (byť s méně detaily, ale většinou to stačí) přesně to, co by mi uměl ukázat reverzibilní debugger.

[JS]

On ten reverzibilni debugger by mel jeste jednu vyhodu, totiz ze by bylo mozne opravit nektere chyby okamzite pri tom debugovani. Neco ve stylu - v debuggeru najdu misto chyby, vratim se kus pred ni, reloadnu prislusny program s opravenou chybou, a pokracuji ve vypoctu. Idealne by se to take propojilo s temi asserty. Selhal assert - program se zastavil a jeho stavil ulozil. Vratime se kus zpatky, opravime chybu a pokracujeme (bez nutnosti restartu vypoctu).

Aah, vzdycky, kdyz nad temihle vecmi premyslim, rikam si, jake uzasne nastroje budou mit programatori za takovych 50-100 let. O tom se nam ani nezda.

[Michal Vyskočil]

Aah, vzdycky, kdyz nad temihle vecmi premyslim, rikam si, jake uzasne nastroje budou mit programatori za takovych 50-100 let. O tom se nam ani nezda.

Za 50-100 let? Pokud se nepletu, tak tohle všechno umí Smalltalk.

[Radek Hladik]

Vypisování hodnot se také hodí, ale krokování zdaleka nenahradí. Představte si, že v mém příkladu jsou x,y a z nějaké pointery na složité struktury (nejlépe ještě pointery na pointery, jak v Cčku oblíbeným zvykem)... Proto je pro mě pohodlnejsi si to v GUI prolízt než plodit výpisy typu printf ("%i",&x->bflm) a pak zjistit, že tam mám o jeden & víc....

Navíc člověk musí přesně vědět, která část kódu dělá ten problém, aby tam mohl přidat výpisy. Pokud to zjistím až v prostřed debugování, tak přidat výpisy, znovu přeložit, znovu spustit, znovu dostat do původního stavu... Už jsem takhle hodně programů odladil, když nebyl k dispozici debuger a občas mě to přivádí k šílenství.

[MJ]

On je ostatně velký rozdíl v tom, jaký typ programu debugujete. Já často píši spíš věci, které dlouhé hodiny počítají, a tam je krokování opravdu nepoužitelné. Spíš se hodí programovat defensivně a připravit si už předem smečku assertů a u každé datové struktury jako první implementovat vypisovátko

[happy barney]

u každé datové struktury jako první implementovat vypisovátko

tak toto je miesto, kde mi do práce skočilo XSLT (pozitívne)

[Radek Hladik]

Tak to jednoznačně. Spousta assertů je důležitá. Stejně jako různá testovací udělátka. Pokaždé se hodí něco jiného. Ale pokud dělám jen část kódu, tak dodělávat si vypisovátka na všechny možné struktury, které můžu potkat (a to ještě nejlépe různě zpointerované, zřetězené a to nejlépe cyklicky), to si radši debugerem dojedu na to dané místo a pak se tou strukturou prokoušu přesně k tomu, co potřebuju...

[Martin Böhm]

Teď zrovna vypracovávám zápočťák na Programování II, který většina lidí musí udělat v C#, takže mám nějaké ty zkušenosti s VS. Musím uznat, že jeho napovídání je velmi silný prostředek, jak něco napsat rychleji, obzvlášť pracujete-li se spoustou TřídSDlouhýmNázvem (což je určitě případ .NETu, ale třeba GTK nebo Qt to má podobně).

Ve vimu (můj obvyklý editor v jůnixech) mi právě chybí takovéto agresivní doplňování. Rozumně agresivní indentaci céčkového kódu zvládne vim v pohodě (cindent), ale standardní Vimovské doplňování je jednak dostupné až po zkratce (Ctrl-X Ctrl-N či co to bylo, vpravdě Emacsovské kombo) a navíc ne tak promakané. (Přiznávám, nesnažil jsem se zas tak moc, pokud někdo víte, jak na to, rád se přiučím.)

Je pravda, že za to určitě může fakt, že VS je na "své" jazyky velmi dobře připravené, zatímco Vim je univerzálnější. Ale i tak, nějaký pěkný konzolový merge obou přístupů by se mi líbil. Já totiž docela rád, když počítač myslí na mne, pokud myslí jako já :o)

[Martin Böhm]

když počítač myslí na mne

Za mne. No jo, nenapověděl mi :o)

[MJ]

Kompletace je velmi příjemná věc, ale mně funguje velice pěkně i ve Vimu. Úplně stačí obyčejné Ctrl-N (když si nastavíš proměnnou complete a tím si vybereš, které typy kompletace mají být zapnuté).

[saly]

Pro PHP Eclipse s PDT(PHP Development Toolz - přímo od Zendu)!

[pools]

Vim

[Přemek Vyhnal]

..na vsechno.

presne tak ;)

[Dalibor Smolík]

nebo taky pico

[Luk]

To tedy rozhodně ne!

[Přemek Vyhnal]

blbost...

;)

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

Pre C/C++ jedine Code::Blocks (najlepšie nejaký súčasný svn build, sú dosť stabilné...), pár vecí tomu síce k dokonalosti chýba, ale v mnohom lepšie než v blogu spomínané ide (kdevelop je v niečom lepší, ale zas nebeží vo windows)...

[Rezza]

Ja nakonec stejne vzdy skoncim s Kate :)

[kotz]

Netbeans umi i C/C++ a Python. Staci jenom doinstalovat modul. Mimochodem, NB maji narozdil od Eclipse hezky vyresenou spravu modulu.

[springer]

pise se v diskuzi, ze VS je kurevsky dobry software, ekonomicky se s tim da dobre vyvijet a gdb je z minuleho stoleti.

Ptal jsem se nedavno u zakaznika mistra na dilne, proc jeste nechaji pilovat ucedniky v prvnim roce hodiny u sveraku ty ocelove kusy, aby to bylo do vinglu. Vzdyt to dnes udelaji CNC stroje mnohem presneji. Usmal se a odpovedel, ze jedine tak se kluci nauci mit vztah k tomu materialu, namlatit do CNC stroje nejake souradnice se nauci kazdy blbec.

[Luk]

To je pravda. Ale jestliže se má efektivně vyrábět, tak se zvolí takový způsob výroby, který to bude splňovat nejlépe. Proto je dnes například lepší (pro stavební firmu, o amatérském staviteli nemluvě) koupit omítkovou směs hotovou, jen ji smíchat s vodou (případně použít už dokonce směs plně připravenou od výrobce), než kupovat písek, prosívat ho, míchat s vápnem, cementem a vodou. Vyjde to levněji, práce postupuje rychleji. A těmi IDE je to úplně totéž - samozřejmě neuškodí, když člověk zná všecho "od píky", ale pro efektivní vývoj je dobré si zvolit to, v čem se pracuje nejproduktivněji.

[Josef Kufner]

A přesně proto si vyberu vim+bash, páč mi to nehází klacky, ehm, ikonky pod nohy a dělá to něco užitečnýho aniž by mě to otravovalo s každou blbostí...

[miro]

Proti gustu ziaden disputat.

Ale debuggovat v gdb je o zivot. Zlaty krasny stary borlandi debugger, alebo aj spominany microsofti.

Sam pouzivam pre pisanie v C++ eclipse+CDT, debuggovanie je ale nejake nedotiahnute (pada to, nezobrazuje spravne watches...). Az to raz bude fungovat tak ako v pripade javy, potom bude parada.

[Josef Kufner]

Debuger obvykle nepoužívám a když už, tak DDD. To sice grafické je, ale je to jednoúčelový nástroj, který se nesnaží dělat úplně všecko.

Raději píšu kód bez chyb, než abych je pak musel lovit

[anicka]

Raději píšu kód bez chyb, než abych je pak musel lovit

Kdyz jsem se jednou hrabala v nejakem prastenem driveru, dala jsem si predsevzeti, ze se naucim psat bez chyb a debugovat bez debuggeru - ted jsi mi pripomnel, ze bych pomalu mela zacit.

Problem je, ze aby se k tomu clovek donutil, musi asi vazne hackovat do kernelu

[MJ]

Nebo programovat Sherlocka Ještě teď si pamatuji na drsné začátky, kdy jsem se potkal s chybou, která se projevovala mírně špatným výstupem programu a odmítala se ukázat na menším než stogigovém vstupu. Krokování nepoužitelné, metoda pokus-omyl taktéž, neb omyl stál další dva dny, než program znovu doběhl. Pak už nezbývá než se naučit chybu zastřelit od boku

[MJ]

Nebo programovat Sherlocka Ještě teď si pamatuji na drsné začátky, kdy jsem se potkal s chybou, která se projevovala mírně špatným výstupem programu a odmítala se ukázat na menším než stogigovém vstupu. Krokování nepoužitelné, metoda pokus-omyl taktéž, neb omyl stál další dva dny, než program znovu doběhl. Pak už nezbývá, než se naučit chybu zastřelit od boku

[MJ]

Eh, pardon, jsem teď připojený (s trochou nadsázky, ale nevelkou) po kusu mokrého špagátu (nebo LANa?) a neudržel jsem se nereloadnout.

[anicka]

No, nevim. Mam jednoho kolegu, ktery nema rad gdb tak moc, ze pouziva nejaky komercni linuxovy debugger, ktery se podle vseho znacne podoba tomu, co je k videni u VS (i kdyz ja to z vyse zminenych duvodu doopravdy nejsem schopna posoudit). Tak jsem si jednou stahla trial verzi a zkusila to pouzivat... a pripadala jsem si jako bez rukou. Kdyz neco neumim v gdb, tak si tam snadno prectu, jak se to dela a pak je to dost logicke na to, aby se mi to pouzivalo prijemne. Kdyz neco neumim v jakekoliv z tech obludek, jsem ztracena... nevim jak to zjistit, a kdyz to nakonec nejak uhodnu nebo mi to nekdo ukaze, nedokazu si to zapamatovat.

Takze jak pro koho. Pro me je o zivot debugovat v cemkoliv vizualne slozitejsim nez prosty shell. Ale ja jsem holt takova neklikaci lama

[miro]

Ako som pisal, proti gustu ziaden disputat.

My klikacie lamy zase cakame na (konecne dobru) integraciu gdb do eclipsu.

[wasabi1]

Každopádně každý používá co mu vyhovuje. Existuje mnoho možností a nástrojů, které lze pro vývoj použít. Osobně bych memohl programovat např. ve VIM. Proto jsem si vybral pro programování v PHP - BlueFish, Pascal - Lazaru atd. Jsem naprosto spokojený programátor.
Jak se tady ještě diskutovalo o Visual Studiu. Osobně jsem programoval v c# spíše se jen učil a poznával. Dle mě je IDE VS velmi mocné, přehledné a lze v něm velmi efektivně programovat. Musím uznat, že se opravdu povedlo ovšem tím nechci snižovat kvalitu jiných nástrojů. 

[springer]

...Jak se tady ještě diskutovalo o Visual Studiu. Osobně jsem programoval v c# spíše se jen učil a poznával. Dle mě je IDE VS velmi mocné, přehledné a lze v něm velmi efektivně programovat. Musím uznat, že se opravdu povedlo ovšem tím nechci snižovat kvalitu jiných nástrojů. ...

Jestli pracujete v IT, tak to jste se minul povolanim. Jdete do parlamentu.

[wasabi1]

Do parlamentu nemusím a ani nechci... Jen tady prezentuji svůj názor a zkušenost, kterou jsem měl. Pracoval jste nebo aspoň viděl IDE VS?

[Luk]

Pracoval jste nebo aspoň viděl IDE VS?

Zjevně ne. Několik let jsem s VS pracoval denně, v posledních 2 letech pak zhruba 5-20 hodin týdně (různé verze od VS 6 po VS 2008). Hodně jsem se napracoval též s různými IDE v Linuxu (hlavně Eclipse+CDT, NetBeans, Anjuta, KDevelop) a dost jsem toho vyvinul i s pouhou kombinací editoru (ne, vim to nebyl ) a konzolových nástrojů. A zcela jednoznačně říkám, že VS mělo vždy výrazně navrch, byť jsem někdy nadával na některé jeho neduhy.

[rastos]

V zozname pre C chýba kdbg - je to len taká tenká šupka nad GDB. DDD mi oproti nemu pripadá trocha ťažkopádny (ale možno len preto, že DDD som už roky neupdatoval).

V kdbg aj kdevelop mi chýba zobrazenie hodnoty premennej v nejakom tooltipe, keď urobím hover¹ nad premennou. Druhá vec, ktorá mi chýba je drag&drop premennej do watch okna.

¹ len dať kurzor myši nad premennú, bez klikania či popup-menu

[Joseph]

btw je tu niekto kto pouziva aktivne applovsky xcode. Ak ano aky nam mate nazor, kde su plusy a minusy? Vdaka.

[anicka]

Zkoušela jsem. Samotné IDE bohužel jaksi neumím zhodnotit (byť můžu říct, že to má to o hodně přátelštější GUI než všechno ostatní, co jsem kdy viděla - vyrobit v tom macosí balíček jsem zvládla i já), ale varuju před používáním buildu gcc od Applu, který je schován pod xcodem. Často to při překladu segfaultuje, a když pošlete Applům bugreport s minimálním test casem, tak se ani neobtěžují ho sami vyzkoušet A to je pak celé milé IDE dost k ničemu...

[Joseph]

hmm. som si i myslel. mna prave zaujalo (este v davnych dobach g3) to GUI, som si teda povedal ze mozno je cas trochu sa stat modernym a vytiahnut nejake IDE. ale je to strach a hruza. viac lovim v GUI ako nieco robim.

[default]

Já bych ještě doplnil kategorii SQL a PL/SQL. Tam bych zařadil Oracle SQL Developer.

Pak bych ještě zvážil kategorii CASE nástrojů. Tak například ArgoUML.

Dále k vývoji software neodmyslitelně patří SCM klienti. Ano, různá IDE mají podporu, ale občas je třeba udělat něco víc. Bohužel žádnou obdobu svnX pro Linux neznám.

[Andrej]

Na základě komentáře byl doplněn Eclipse...? No nevím nevím, já ho na důležitých místech pořád ještě nevidím.

Eclipse citelně chybí u PHP. Jde o jeden z nejpokročilejších zdarma dostupných nástrojů pro psaní PHP pod Linuxem.

U C a C++ taktéž nevidím jedinou zmínku o Eclipse. KDevelop mu nesahá ani po kotníky. Anjuta zase nesahá ani po kotníky KDevelopu. Eclipse se svou podporou několika debuggerů a několika kompilátorů a s mimořádně inteligentní code-completion, fungující rozumně i v tak nepřesně typovaném jazyce, jako je C, je mezi volně dostupnými prostředími opravdu špička.

V případě Javy by měl Eclipse IMHO zaujímat první místo, pak by měla být obrovská černočerná propast a teprve potom všechno ostatní, NetBeans počínaje. Jednu dobu jsem něco psal střídavě v NetBeans a Eclipse, ale source-level debugging a code completion byly v Eclipse o tolik pokročilejší, že u mě nakonec zvítězil. (A to i přes velkou spoustu vlastností, které má NetBeans oproti Eclipse navíc.)

[Luk]

Po tom, jaké příšerné problémy jsem zažíval s Eclipsem, letěl z počítače, až se prášilo. A hodně dlouho mi do něj nesmí. Nejméně tak dlouho, než prokáže, že se umí chovat slušně (pomíjím žravost, ta není až tak důležitá).

[Andrej]

Zásadní otázka, bez níž diskuse na toto téma nemá smysl: Kolik bugů jsi ohlásil?

Eclipse používá denně veklá spousta uživatelů, včetně hodně velkých firem. Pokud někomu nefunguje, problém může být třeba v distribučním balíčku nebo mezi židlí a klávesnicí. Například ArchLinux měl asi půl roku v repository vadný balíček, který byl prakticky nepoužitelný. To ale ještě nemusí znamenat, že jde o chybu Eclipse.

[default]

Zásadní otázka, bez níž diskuse na toto téma nemá smysl: Kolik bugů jsi ohlásil?

Špatně. Nic hlásit nemusí. Když si stáhneš trialku Photoshopu a program ti nesedí, také to nehlásíš jako chyby. Prostě trialku odinstaluješ a Photoshop nekoupíš.

Jemu "zkušební" verze Eclipse nevyhovovala, tak ji smazal. S úspěchem používá jiný produkt, který mu víc vyhovuje.

Eclipse používá denně veklá spousta uživatelů, včetně hodně velkých firem.

Protože v době, kdy IBM uvolnilo Eclipse platform, nic jiného zadarmo nebylo. Tenkrát měl Eclipse víc funkcí než měla konkurence, tak jej uživatelé začali používat (volba menšího zla). V dnešní době se používá jen kvůli tomu, že vývojáři jsou líní zmigrovat nezmigrovatelné do jiného IDE.

Mimochodem: znáš tu historku o tom, proč IBM Eclipse uvolnilo?

[Andrej]

Zaprvé, Photoshop je placený software určený ke zcela jinému účelu a nelze ho tedy srovnávat s Eclipse. Zadruhé, Eclipse je momentálně open-source projekt. Je každému zdarma dostupný. Pokud tedy mám pocit, že obsahuje chyby, nahlásím je. A učiním tak dřív, než začnu tento produkt jakkoliv pomlouvat. Jistě, nic hlásit nemusí. Pak je ovšem rozumné vyvarovat se jakýchkoliv hodnotících soudů ohledně toho software.

Nechť mi někdo ukáže jediné IDE pro Javu, které předčí Eclipse. Jistě, několik (velmi draze) placených kousků software tohoto druhu jsem už někde viděl, ale v seznamu features jsem nenašel nic, co by Eclipse neměl. Výroky o tom, že někdo zvolil nejmenší zlo, jsou poněkud směšné. Na tomto IDE nic zlého nevidím. Pravdou je, že pokud je zlo jediné a nemá konkurenci, pak je zároveň největší i nejmenší.

Historku o IBM a Eclipse neznám. Eclipse mi funguje bezproblémově a o detaily kolem jeho vzniku se příliš nezajímám. Spousta lidí samozřejmě dává přednost jiným IDE a je to jejich svobodná volba. Jediné, co jsem v původním příspvěvku chtěl zdůraznit, je fakt, že u C, C++, Javy a PHP chybí zmínka o Eclipse. V žádném případě netvrdím, že každému musí Eclipse vyhovovat. Mně nevyhovují desítky různých programů, které prostě nepoužívám. Nikdy mě ale nenapadlo označovat je veřejně za nepoužitelné. Zvlášť když vím, že spousta lidí je má v oblibě.

[Josef Kufner]

Zaprvé, Photoshop je placený software určený ke zcela jinému účelu a nelze ho tedy srovnávat s Eclipse.

Všechno jde, když se chce, jen malé děti se musí učit chodit.

K jakému účelu jsou jmenované programy určené je zde naprosto bezpředmětné. Srovnávat lze naprosto cokoliv s čímkoliv, protože nikdy nesrovnáváš věci, ale jejich vlastnosti nebo jejich vztahy k okolí. Otázkou je, které z vlastností tě v konkrétním srovnání zajímají. Proto můžeš srovnávat jabka s hruškama, abys zjistil, že je obojí zelené, nebo Eclipse s Photoshopem, abys zjistil, že ani jeden ti nevyhovuje.

[MJ]

To je s prominutím naprostá hloupost.

Jistě, je slušné ohlásit chyby, když nějaké najdu. Ovšem legitimita mého názoru na to, že dotyčný program je mizerný, zůstává stále stejná. Ta totiž závisí na stavu programu, nikoliv na množství bugů v něčí bugzille. Časem tím možná mohu pomoci tomu, aby program mizerný nebyl, ovšem jsou programy, u nichž je to evidentně marné (teď nenarážím na Eclipse).

[Luk]

Kolik bugů jsi ohlásil?

Nějaké ano. Ale pak jsem přešel na NetBeans a byl jsem spokojen. Možná Eclipse zase někdy vyzkouším.

problém může být třeba v distribučním balíčku nebo mezi židlí a klávesnicí

Některé z těch bugů byly potvrzeny jako bugy v Eclipse, některé jako bugy v pluginu CDT.

[Andrej]

Konkrétně ArchLinux nedávno přiznal, že balíček v repository byl špatný. Nejen že pořádně nefungovalo CDT, ale dokonce docházelo k naprosto bezdůvodným pádům a Eclipse se vůbec nespustil bez optionu -clean. Takže nepříjemné zážitky s nestabilitou, nefunkčností automatických aktualizací nebo zasekáváním celého IDE velmi dobře znám a je mi jasné, že pokud někdo třeba vidí Eclipse poprvé a stane se mu něco takového, prostě s tím sekne. Já jsem ovšem zažil už několik verzí tohoto prostředí a musím konstatovat, že až na rozbitou Europu fungoval Eclipse vždy obstojně.

NetBeans je taky fine, ale když jsem ho naposledy zkoušel, ještě tam nebyl tak pokročilý source-level debugging. V Eclipse už tehdy byly vyznačené předem všechny případné warningy a chyby, včetně sémantických. NetBeans dokázal většinou odhalit pouze syntaktické a gramatické chyby, sémantiku moc neovládal. (Ani refactoring tam nebyl příliš dobrý.) Ale to byla verze 5. Možná už je to ve verzi 6 zase lepší, že jo. V mém případě ovšem NetBeans rozhodně nemusel z počítače pryč. Když vydají novou verzi a mám chvíli času, většinou si ji prohlédnu. Jestli mi něco na NetBeans hodně vadí, je to Swing. Není pomalý, to je fáma. Zato je takový ... zkostnatělý. SWT (a tedy Eclipse) například respektuje styly pro GTK. Pokud mi ovšem nevyhovuje vzhled swingových widgetů, nenadělám s tím vůbec nic.

[Luk]

Konkrétně ArchLinux nedávno přiznal, že balíček v repository byl špatný. Nejen že pořádně nefungovalo CDT, ale dokonce docházelo k naprosto bezdůvodným pádům a Eclipse se vůbec nespustil bez optionu -clean.

Archlinux nepoužívám, Eclipse a pluginy jsem vždy instaloval přímo ze základních balíků stažených z webu Eclipse.

je mi jasné, že pokud někdo třeba vidí Eclipse poprvé a stane se mu něco takového, prostě s tím sekne

Já jsem prací s Eclipsem (různých verzí, jak pod Linuxem, tak po Windows) strávil nejméně 1000 hodin. Starší verze problematické nebyly, potíže začaly až někde okolo verze 3.0.

V mém případě ovšem NetBeans rozhodně nemusel z počítače pryč.

Já mám jednu takovou vlastnost, že když pohár trpělivosti přeteče, pak reaguji velmi emotivně - tedy v případě programu ho odstraním a nemohu ho delší dobu ani vidět

Pokud mi ovšem nevyhovuje vzhled swingových widgetů, nenadělám s tím vůbec nic.

To samozřejmě není pravda. Na swingové widgety lze aplikovat Look and feel a přizpůsobit si je podle potřeby. Takhle mám například u jEditu ve Windows nastavený windowsový vzhled.