- (diskuse)

[Bedňa]

Java RULEZ! Na 1.3GHZ čo robí procesor miliardu operácií za sekundu, bežne hocijaký Java program dokázal vytuhnúť na viac ako 5minút, pýtam sa čo robil pri kliknutí na ikonu, pre výber menu?

[tomm]

Na P3@800 s 512 MiB RAM jsem napsal v Jave hromadu semestralek vcetne OCR pres neuronove site. A nasledne diplomku na P3 mobile oscilujici mezi 700 a 1000 MHz (take 512 MiB RAM). Tehda NetBenas 3.6 a vse slapalo v pohode. Pravda, ta neuronova sit se trenovala asi 2 minuty, ale to nakonec na 1 GHz UltraSparcu na Solarisu 9 v laborkach taky

[Bedňa]

Konkrétne NetBeans na tom stroji bežne tuhol na celé sekundy, ale boli aj lepšie, fakt nechápem čo môhlo taký procák zamestnať na minútu a viac.

[rADOn]

To je spis problem GUI knihoven nez JVM. IMO jsou swing/awt v ramci javovske manie napsane take v jave misto aby pouzivaly vykonejsi nativni knihovny. Javovske apliakce jsou jedine u kterych bezne pozoruju jak prekresluji okno… udalostni smycka evidentne neni typ ulohy kterou by vm umel dobre zoptimalizovat

BTW aplikace v pythonu pouzivajici PyQt slapou na mem hw jako vino, ackoliv je vm cpythonu mnohem pomalejsi nez jvm.

[vulgární Nick]

To je spis problem GUI knihoven nez JVM.

Já to vidím na nějakej problém programu nebo dat. Ale takhle to nejde moc dobře posoudit. Když řeknu, že se mi na pár minut seknul BASH, taky nepůjdeme hned hledat problém do kompilátoru C...

IMO jsou swing/awt v ramci javovske manie napsane take v jave misto aby pouzivaly vykonejsi nativni knihovny.

Hodně, hodně obecně a nepřesně řečeno: Swing je "jenom v Javě", AWT je "nativní".

BTW aplikace v pythonu pouzivajici PyQt slapou na mem hw jako vino, ackoliv je vm cpythonu mnohem pomalejsi nez jvm.

Osobně jsem nikdy nepozoroval, že by Swing byl pomalejší než GTK, Qt nebo cokoli jinýho.

[rADOn]

Beru zpet, "pomalejsi" neni uplne spravne slovo. Na nezatizenem systemu to neni moc videt, ale kdyz dam treba neco kompilovat (s nice a ionice!), gui aplikace v jave zacnou byt neskutecne liny, nereaguji na udalosti, nestihaji prekreslovat, obecne jsou velmi nepohodlne na praci. Qt aplikace se s tim poperou daleko lip, netrpi prekreslovacimi artefakty a hlavne stihaji zpracovavat udalosti, takze i kdyz program nestiha makat, nechova se jako mrtvola.

Ergo provozujice desktopove gentoo je pro me zatizeny system normalni stav a java nepouzitelna

Hodně, hodně obecně a nepřesně řečeno: Swing je "jenom v Javě", AWT je "nativní".

Ano, AWT se chova kapku lepe, ale "nativni" bych ho radeji nenazyval

[tomm]

To bych videl na problem jinde, to neni obvykle chovani. Nemohl to byt nejaky IOwait? Neodswapovavalo to hodne?

[Bedňa]

To bol celkovo problém java GUI aplikácií. NetBeans, nejaké dva p2p clienti, nejaký inštalátor hier hier, proste hocijaké klikátko, raz za čas som dal nejakej jAplikácií šancu a vždy to skončilo rovnakým sklamaním. Je pravda, že keď mám teraz dvojjadro, tak to nieje poznať, ale už podvedome vnímam ako mi požiera procesor :) Keď tak lovím v pamäti, jeden p2p bol asi jMule (alebo aMule) ten sa spúštal hádam 5minút a vždy, toto nech niekto objasní, čo robil :) Ten druhý zas štartoval v poho, ale čo klik to čakanie, fakt si tie názvy nepamätám, lebo každý išiel hneď do ...

Nechápem to, pretože Python klikátka som nerozpoznal od Céčkových aplikácií, najskôr to ma na svedomí časť kódu, čo sa stará o vykreslovanie, ale čo robí je mi záhadou a ani som po tom nepátral.

[tomm]

Myslim, ze Python ma jenom binding na nativni knihovny.

Ten Javovy klient byl na BT klient Azureus a bylo to v SWT, cili binding na nativni knihovny ... *Mule neznam

Ja mam aktualne spusteny Eclipse, STS, muCommander, Jetty v devel modu, Rachotu a honim tu preklady Mavenem a nejak vsechno slape ... Samozrejme k tomu jeste obvykle appky.

[Bedňa]

Zostava asi nebude tá čo píšem :) na dvojjadre aj mne behajú v pohode, hoci s nimi trávim málo času, ale novému NetBeans dám určite ešte šancu.

[tomm]

MBP 17, model 2009.

Bottleneck je 5400 disk, ale kdyz clovek dela jenom jednu diskove narocnou vec, neni to znat. A to ticho ...

[Bedňa]

Tak som NetBeans dal šancu, trochu papá pamäť, ale je to použiteľné a zatiaľ príjemné prekvapenie.

[tomm]

Verze 7? Ja jeste nestihl ozkouset

[loki]

Nech si kecy na koledu. Na 1.4GHz Celeronu jsem na tom fungoval nekolik let a bez problemu. Treba existuji lepsi ide, ale java je proste sexy. :-P

[Bubak]

Hm, nevim, jak u tebe, ale netbeans 6.9 bo nejak tak na c2d 2.2G neni zrovna blesk (c a c++ projekty - jasne, nebudu rozebirat to, ze jsem linej rozbihat jina prostredi na Slackovi 12, protoze chteji kdovijake vypiceniny, ktere jsem linej rozbihat, protoze chteji kdovijake vypiceniny atd.)

[Xerces]

Souhlas s Bedňou JAVA apps je co se týče GUI sra.ka. Osobně se JAVA apps zásadně vyhýbám a to i za cenu nižší funkcionality. Ono i bez toho GUI je to běs. Javu vnímám spíš jako rapid development a podle toho to taky vypadá. Né že by to nešlo použít, ale je to jako Linux na Desktopu.

[Luboš Doležel (Doli)]

Až bude žrát tak polovinu paměti, tak bude teprve použitelný. Doteď vzpomínám na Visual Studio 6, které docela slušně fungovalo i na Windows 95 s 16 MB RAM (opravdu se nepletu) a upřímně mi připadalo jako lepší IDE než NetBeans.

Jakmile bude KDevelop pro KDE 4 použitelné (při pohled na míru destabilizace ostatních KDE aplikací to odhaduju na 5 let), tak od toho zase uteču...

[vulgární Nick]

Neříkám, že je použitelný, ale použitelnější než dřív. :) (A taky ze všech nejpoužitelnější.)

[jarin]

Žravost paměti dost závisí na pluginech. Např. Java SE + ME verze se bez problémů vejde do 100 MB (otevřené 2 projekty každý cca. 10 000 řádků). V případě Java EE je to horší, ale zase to vynahradí to obrovské množství funkcí. Pokud je nechci a chci rychlost, tak nepoužívám IDE. Srovnávat Netbeans s VS je hodně odvážné. Naposledy jsem používal VS 2008 a funkčně bylo hodně pozadu oproti libovolnému java IDE (NB, eclipse nebo Idea). Nepoužívám NB na C/C++ takže v téhle oblasti nemůžu soudit.

[Luboš Doležel (Doli)]

NB je na C++ docela na nic. Takový lepší vim + gdb... Oproti tomu VS je špička.

[User682]

zdravim,

ja fakt nevim, co chcete ?

tak nevzpominejte. Proste si kupte dalsi pamet. Tech par stovek snad mate.

Nebo zacnete pouzivat Visual Studio. Klidne 6-kovou radu s WIN 95. Bude to zrat mene pameti a bude to rychlejsi.

To ALL: lidi proberte se s nazory na Javu ci jine technologie. Je rok 2011. IDE se zpravidla meri tim, co umi a jak mi setri cas. Ne kolik zere RAM. Vetsina lidi si nezaslouzi s temito nazory vice nez disketovou mechaniku a konsoli na veskerou praci.

gf

[Luboš Doležel (Doli)]

Jenže koupit novou RAM nejde bez vyhození počítače. Protože už teď mám 4 GB RAM a víc ta základka nevezme. A kvůli Javě (protože nic jiného tolik paměti nechce) takové investice dělat nebudu.

NetBeans mi nešetří čas vůbec, protože to swapování je extrémní. Jediný důvod, proč ten křáp používám, je, že KDevelop teď není moc dobře použitelný. Kdyby pro Linux bylo Visual Studio 6, věřte, že bych ho rád používal, protože to bylo velmi dobré IDE s dobrým debuggerem.

[xkucf03]

4 GB jsou až až, normálně na tom pracuji, včetně těch Netbeans. V předchozím notebooku jsem měl 256 MB RAM a stařičkého Athlona a taky jsem tam používal Netbeans a normálně se v tom pracovat dalo. Je pravda, že to tehdy byla nějaká verze 3 nebo 4, už je to pár let, ale i tak.

[Luboš Doležel (Doli)]

Právě, že na těch 256 MB RAM mi to taky chodilo...

[User682]

zdravim,

zalezi, co v tech NeatBeans-ech delate. Co vlastne delate ? Jen vyvijite ? Nebo je to jen nejaka na pamet narocna aplikace ?

Co se tyce java IDE, tak se da omezit velikost uzivane pameti na vse mozne vcetne startu. Aktualizovat. Resit to v bugzillach. Moznosti je mraky. Zalezi na uloze. Jen to jen o tom si vybrat, zda budu nadavat na "strasnou Javu" anebo na to "ze to jeste neumim".

Proste to neni nic, co by clovek cislo 1. (nebo podobne cislo) okolo abclinuxu a technologii na abicku s cim by si nemel umet poradit.

Co se tyce pridani pameti, tak to je jen vec kalkulace. Sice jsem to 6-jadro s 8GB RAM nemusel kupovat, ale cas to setri a dost. I kdyz to stejne tu pamet moc nevyuzije. Pokud se to na stroji s 8GB chova normalne, tak bych uz objednaval. Pokud je to chyba aplikace/IDE, tak to resim.

Co se tyce zejmena novejsiho Visual Studia, tak moje kratsi nekolikalete zkusenosti jsou takove, ze je to hezka vec s mnoha nedotazenymi vecmi a chybami. Nebudu ted konkretni. Delam v Eclipse a nechapu proc mam delat o 1/3 pomaleji a 10x vice byt vytoceny, ze zase neco nejde a ze to trva. Radeji mene funkcionality a vice funkcnosti.

Muzu Vas uklidnit, ze "rozsypany Eclipse" a podobne veci jsem take zazil. Ale vyhody prevazuji a lepsi v soucasnosti neznam.

gf

[Luboš Doležel (Doli)]

Jen vyvíjím. Pluginy jsou omezené na minimum. A přesto to hned po startu žere víc než všechny služby na mém domácím serveru dohromady (a že je toho tam požehnaně).

A s parametry VM jsem si už hrál. Jediné, čeho jsem dosáhl, byla úspora 100 MB za cenu neustálého volání GC, což totálně odrovnalo výkon.

Nový hardware nebudu kupovat jen kvůli neschopným vývojářům jedné aplikace. Ostatní aplikace se naštěstí chovají normálně.

[Miloslav Ponkrác]

Já osobně nepoznám rychlost Javy od nativní aplikace a to ani v GUI.

Pravda, začalo se mi to dít až když jsem si před dvěma lety pořídit 4jádro na 3,2 GHz.

Nicméně jestli něco funguje opravdu pomalu a špatně, tak je to Firefox. Jsem s ním asi 15 let (to se tehdy ještě jmenoval jinak) a vždy nejvíc zatěžoval počítač a nejvíc zdržoval. Už několikrát jsem zvyšoval výkon kompu kvůli Firefoxu aby se dal rozumně používat.

Dnes už si myslím, že Firefox je zkrátka špatně naprogramován a blbě využívá multithreading, pokud vůbec.

Celkem chápu, proč třeba na Windows začíná podíl Firefoxu postupně klesat a zase získávají na rozšířenosti jiné browsery, mimo jiné i IE.

Ohledně Javy nemám sebemenší problém. Java aspoň umí využít výkon počítače. S výkonnějším počítačem je prostě svižnější. Jediný problém je, že GUI občas má drobné chybky – a že na Windows GUI prvky dělají třetinu toho co dělají nativní prvky.

[podlesh]

Ještě je zde možnost koupit SSD disk. Ale pozor, je to návykové (a to i bez Javy)!

[Miloslav Ponkrác]

Od 24 GB RAM není rozdíl v rychlosti SSD a HDD.

SSD navíc je nespolehlivý a s krátkou životností. Nehledě na to, že na SSD technologii stále ještě nejsou operační systémy vůbec připraveny.

Například Linux počítá s tím, že disk je lineární random access pole bloků – což platí pro magnetický disk, ale rozhodně to není dobrý model pro flash disky.

Díky tomu SSD emuluje chování, které mu není vlastní. A jeho parametry i životnost jde tím pádem prudce dolů.

Navíc magnetický disk má digitální zápis, dnešní SSD mají většinou analogový zápis (MLC) – a spolehlivost uložení dat je pak stejná jako spolehlivost veškeré analogové techniky.

Osobně považuji za lepší ve stolním počítači investovat do vysoké hodnoty RAM, pak není rozdíl mezi HDD a SDD v rychlosti – a změní se mnohem více parametrů počítače k lepšímu.

SDD technologie bohužel začala s katováním kostů dříve, než se stačila pořádně dokončit. Zatím to není vyzrálá technologie.

[alkoholik]

Dnes uz velikost RAM ovlivnuje rychlost disku?
Kam na to ten Ponkrac chodi..

[j AM]

Z hvězd to vyčetl.

[Michal]

Tak já nevím - to, že je rok 2011 znamená, že se může plýtvat výpočetním výkonem? Tenhle názor nezastávám, protože pak to vypadá tak, jak to dnes vypadá. Počítače jsou 200x výkonnější než před 20 lety, ale rychlost práce je stále podobná, protože se stále čeká na software, který o mnoho dokonalejší není.

Také měřím kvalitu IDE podle toho, jak mi šetří čas a právě z toho důvodu už Netbeans nechci vidět. Když už musím dělat v Javě, tak raději v Eclipse. Ale co člověk, to názor a odlišné potřeby, takže samozřejmě tento názor je nutné také respektovat.

[pht]

Tak já nevím - to, že je rok 2011 znamená, že se může plýtvat výpočetním výkonem? Tenhle názor nezastávám, protože pak to vypadá tak, jak to dnes vypadá. Počítače jsou 200x výkonnější než před 20 lety, ale rychlost práce je stále podobná, protože se stále čeká na software, který o mnoho dokonalejší není.

To je dost povrchní pozorování. Před 20 lety by se Vám ani nezobrazil desktop v tom rozlišení jaké máte teď, nemluvě o přehrávání nějakých mp3 (vzpomínáte, že na přehrání mp3 bylo potřeba aspoň pentium?). Práce kterou počítač vykonává je nepoměrně větší.

Pak si myslím že se nejedná o plýtvání ale prostě o nějakou ekonomickou rovnováhu. Větší práce znamená složitější programy. Složitější program můžete buď napsat složitě a pak zaplatíte brutální částku za jeho údržbu a nebo ho můžete napsat jednoduše a budete mít režii na výkonu, který lze ale poměrně levně koupit.

[vulgární Nick]

To je dost povrchní pozorování. Před 20 lety by se Vám ani nezobrazil desktop v tom rozlišení jaké máte teď, nemluvě o přehrávání nějakých mp3 (vzpomínáte, že na přehrání mp3 bylo potřeba aspoň pentium?). Práce kterou počítač vykonává je nepoměrně větší.

Máte pravdu. "Problém" je v tom, že počítače jsou využívaný zároveň k mnoha činnostem, ale jen jejich zlomek je považovanej za "produktivní práci". Některý lidi maj tendenci vidět zvýšenej výkon počítačů, ale stále jen tu "produktivní práci", ne už zbytek, kterej ale taky žere výkon (třeba to přehrávání hudby, který může bejt provozovaný souběžně s "prací").

[Luboš Doležel (Doli)]

Však já nic nevyčítám desktopům jako celku. Já kritizuju software, co ještě ani nic nedělá a už sežere paměti jako 5 IDE psaných v snad jakémkoli jiném jazyce dohromady.

Navíc nejsem názoru, že víc nabízených funkcí musí znamenat víc sežrané RAM.

[Michal]

Kromě poznámky s rozlišením (považuji za irelevantní - grafické "adaptéry" mají dnes tisícinásobný výkon a bez ovladačů jsme zpět v době před 20 lety) s Vámi souhlasím. Uvědomuji si tu ekonomickou stránku věci, i když s ní tak nějak vnitřně nesouhlasím. Sám se v některých případech přikloním k Javě, když vidím riziko nestihnutí termínů. Uvědomuji si, že dnes si mohu dovolit mít puštěnou hudbu, IDE a ještě editovat 90MB obrázek zároveň a dopad na výkon bude neznatelný, což by před 20 lety bylo nemyslitelné. Ale tohle jsem záměrně v úvahu nebral.

Právě software jako jsou kodeky považuji za kvalitní software, který neplýtvá.

Měl jsem na mysli spíše výpočetně nenáročné aplikace, které už z podstaty spíše čekají na vstup od uživatele než na dokončení vnitřních výpočtů. Například IDE nebo nějaké textové procesory atd. Jak to, že například takový Word 97 si vystačil s řádově 10x slabším strojem než Word 2010? Přitom funkcionalita je takřka stejná. A takhle je to dnes s většinou software a to mi vadí. Vám to nevadí, že byste si měl pro zachování rychlosti práce kupovat co 2 roky nový počítač, přičemž komfort práce zůstává už 10 let stejný (silnější HW, ale nenažranější SW, který toho o mnoho více nenabízí)?

Ale rozumím tomu, že se s tím v komerční sféře nedá moc nadělat, protože je HW zkrátka levnější než pracovní síla programátorů.

[pht]

Uvědomuji si, že dnes si mohu dovolit mít puštěnou hudbu, IDE a ještě editovat 90MB obrázek zároveň a dopad na výkon bude neznatelný, což by před 20 lety bylo nemyslitelné. Ale tohle jsem záměrně v úvahu nebral.

Asi jsem se úplně nevyjádřil přesně: přehrávání mp3 je prostě jeden z příkladů, kde narostla práce kterou dělá počítač - dříve šlo přehrát jen nekomprimovaný zvuk. Pokud byste pracoval se zvukem tak byste nemohl říct že na 100x výkonnějším stroji dnes děláte totéž jako dřív. Přehrávání hudby při práci je samozřejmě zcela jiný, ale rovněž platný případ.

Měl jsem na mysli spíše výpočetně nenáročné aplikace, které už z podstaty spíše čekají na vstup od uživatele než na dokončení vnitřních výpočtů.

Ani Word ani IDE nežerou moc výkonu když *čekají*, ale žerou ho když se dočkají. Spell check při psaní, vyhledávání všech volání metody, nahrazování bloků kódu, to vše musí fungovat tak, aby se toho uživatel dočkal (nebo "on the fly"), a to samozřejmě žere příslušný výkon počítače.

A takhle je to dnes s většinou software a to mi vadí.

Mně taky vadí když je SW nepoužitelný ale tomu se vyhýbám. Řekl bych že tak smýšlí většina lidí, a proto je jednou z hlavních deviz dnešního SW rychlost a použitelnost. Funguje to skvěle v dobře vyvinutém konkurenčním prostředí - prohlížeče, IDE, dejme tomu i office programy. Nefunguje to tam kde tlak konkurence není - průmyslové aplikace a bohužel i spousta free SW (KDE, ...)

Vám to nevadí, že byste si měl pro zachování rychlosti práce kupovat co 2 roky nový počítač, přičemž komfort práce zůstává už 10 let stejný (silnější HW, ale nenažranější SW, který toho o mnoho více nenabízí)?

Já vidím že každé 2 roky dělám s novým HW a SW o spoustu věcí navíc, o kterých se mi předtím ani nesnilo, takže ten komfort je úplně někde jinde. Před rokem koupený počítač na vývoj s 8G paměti je dnes tak tak a vím že za 1-2 roky už bude za zenitem. A upřímně mi to nevadí, protože kdyby se zastavil vývoj HW, tak by se zastavil i vývoj SW.

Ale rozumím tomu, že se s tím v komerční sféře nedá moc nadělat, protože je HW zkrátka levnější než pracovní síla programátorů.

To je jedna věc a navíc v mnoha případech ani nelze takovou pracovní sílu pořídit. Problémy pro lidi musí zůstávat více méně stejně složité, zbytek musí řešit počítač.

[Michal]

Já vidím že každé 2 roky dělám s novým HW a SW o spoustu věcí navíc, o kterých se mi předtím ani nesnilo, takže ten komfort je úplně někde jinde. Před rokem koupený počítač na vývoj s 8G paměti je dnes tak tak a vím že za 1-2 roky už bude za zenitem.

Evidentně máme oba jiné požadavky na počítač. Můj způsob využití počítače se v čase příliš nemění, proto bych si vystačil s jedním počítačem léta, pokud by se nové verze SW chovaly slušně. Největší skok byl, když jsem začal virtualizovat kvůli testování. To mě prostě donutilo upgradovat a zde jsou nároky opodstatněné. Ale globálně mě prostě nikdo nevymluví, že ty nároky běžných programů jsou opodstatněné, protože na starším počítači je nový SW prostě pomalejší i když nevyužívám ty super nové funkce

[AHAHA]

Můj způsob využití počítače se v čase příliš nemění, proto bych si vystačil s jedním počítačem léta, pokud by se nové verze SW chovaly slušně.

V tom pripade neugradujete software.

Ale globálně mě prostě nikdo nevymluví, že ty nároky běžných programů jsou opodstatněné, protože na starším počítači je nový SW prostě pomalejší i když nevyužívám ty super nové funkce

Jak roste program a jeho programova vybava, roste jeho komplexnost - neni to tak, ze vyvojar vzdy jen prilepuje featury k jiz existujici funkcionalite a tak by se teoreticky nemelo stat, ze by existujici featury mely byt stejne rychle. Vetsinou je potreba hrabat jiz do existujiciho kodu, refaktorovat, zobecnovat, vytvaret nove abstraktnejsi vrstvy, misto znovuvynalezani kola se pouzije obecnejsi (a mene rychla) knihovna, to vse prispiva k vetsi prehlednosti kodu, mensi nachylnosti k chybam, ale software je pak o neco pomalejsi. Samozrejme, existuji i vyvojari a jejich software, kteri skutecne jen prilepuji kod k existujicimu software, z toho se ale casem stane neudrzovatelny bordel a ten pak (vetsinou) umre.

[mirec]

KDevelop je na C++ celkom katastrofa, ale Qt Creator je pekný (hoc nenažraný).

[Bubak]

VS 6 mam doted na W2k ve virtualu, kdyz potrebuju prelozit neco do woken

[Leinad]

Zkoušel jsem Eclipse a bylo hrozně neintuitivní ovládání a pro PHP mnohonásobně složitější instalace debuggeru. NetBeans se mi zdá jako poměrně dobré vývojové prostředí, teda alespoň pro PHP.

Ještě mi chybí mi skládat (folding) všechen kód ve složených závorkách, nejen skládání kódu funkcí, metod a tříd.

[Ladicek]

Zalamování řádek je pakárna, která nemá v IDE co dělat.

[vulgární Nick]

A smí podle vás v IDE vůbec bejt editor? Nebo se tam kód může jen prohlížet a psát se má někde vedle ve vimu? :)

Jaký jsou vaše důvody pro to, aby se řádky zalamovaly skutečně, fyzicky ve zdrojáku? Nebo je nezalamujete a jen používáte horizontální posuvník, abyste ten kód "víc vpravo" viděl?

[Ladicek]

A smíte vůbec přispívat na abclinuxu?

Jaký jsou vaše důvody pro to, aby byly řádky delší než nějakých 100, 150 znaků?

[sdfgsdfg]

chces rict 80, ne?

[Ladicek]

Masochisti se můžou omezit na 80

[Michal Vyskočil]

80 znaků na java kód plný šíleněDlouhýchNázvůMetodATříd, nebo různých delegátů nestačí prakticky nikdy. Třeba jenom prosté čtení ze souboru sebere 97 znaků

BufferedInputStream bufferedInput = new BufferedInputStream(new FileInputStream("filename.txt"));

[vulgární Nick]

Přesně. A přesto jsou lidi, co to tak maj. :)

[vulgární Nick]

Jak se stane, že mám řádek, kterej je delší než x znaků? Jednoduše. Kód strukturuju podle logiky programu, ne podle jeho zobrazení v editoru. Občas volám na řádku víc funkcí (vynechme diskuzi, jestli to je dle jakejchsi pravidel správný - já mám svý důvody to dělat a vyhovuje mi to), který maj dlouhý názvy, nebo může jít i o řádkovej komentář...

Já nedělám řádky záměrně dlouhý, ale když už nějakej občas je delší než těch x znaků, proč ho zalamovat ručně nebo proč ho nevidět na obrazovce celej?

Většinou mám v editoru na šířku hodně místa, ale někdy se stane, že je editor jen v malinký oblasti (řekněme 60 znaků). Kdybych zalamoval fyzicky po 100, 150 znacích, nebylo by to moc přehledný.

[:::]

Jaký jsou vaše důvody pro to, aby se řádky zalamovaly skutečně, fyzicky ve zdrojáku? Nebo je nezalamujete a jen používáte horizontální posuvník, abyste ten kód "víc vpravo" viděl?

duvod je jednoduchej - kdyz se v tom programu chces vyznat tak nestaci to zalomit kdekoliv, potrebujes to zalomit na spravnym miste a na dalsim radku vhodne odsadit. A to za tebe zadnej edior spravne neudela...

automaticky zalamovanej program logicky bude jedna velka prasarna ve ktery se nikdo nevyzna...

[vulgární Nick]

Je dost možný, že jste mi nerozuměl. Virtuálním zalamováním myslím to, že editor dlouhý řádky zobrazí jako zalomený v místě, kde by přesáhly jeho šířku. Takže to není zalomený zcela "kdekoli", ale na jasně daným místě. A navíc to vůbec neovlivní fyzickej soubor - týká se to jen jeho zobrazení. Automatický formátování taky nemám rád a radši sám zalamuju na "správným místě".

Pokud jste mi rozuměl, tak jsem asi já vám nerozuměl, takže to prosím vysvětlete znova, jestli chcete. :)

[:::]

jo to jsem pochopil ale takovej soubor kdyz otevres tak vypada pokazdy jinak (podle sirky okna) a na 99% je to "spatne"

podle me je lepsi tomu venovat trochu casu a rucne to zalamat aby to trochu vypadalo...

potom se samozrejme objevi problem "na kolik". 80 znaku je podle me nesmyslne malo. Ja se obvykle snazim nepresahovat 128, ale kdyz si myslim ze delsi radek bude citelnejsi nez zalomeny tak klidne necham delsi...

[mirec]

A potom to nám, ktorí máme šírku 83 všetko rozsype horšie než keby nejaký riadok sem-tam vyčnieval.

[Bedňa]

+1

[sidik]

Pročpak ne? Ať tam klidně je. Těm, co píší krátké řádky, je to jedno. A ten zbytek se absencí vizuálního zalamování stejně nenaučí psát kratší řádky kódu. :)

[Espinosa]

Virtuální zalamování řádků (line wrapping) neni idealni pro zdrojaky. Proto verim ze to v IDE neni bezna funkce. Jeste se tak hodi pro obecne textove editory, jako Kate, na cteni logu. Pro zdrojaky potrebujete inteligentni zalamovani, podle charakteru jazyka. Pokud se vhodne nastavi, a ze v Eclipse jde nastavit do nejmensich podrobnosti, ma to i dalsi vyhody - opravu indentace, procisteni whitespace, ruzne zrudnosti jako mix mezer a tabu. Definici formatovani lze exportovat a sdilet v teamu, na vetsine projektu se to dokonce vyzaduje. Oni se vzdycky najdou cunata, co napisou pul implementace do jedne nudle. Autoformat je neco jako uklizecka zdarma.

[loki]

Co preferujete? Netbeans? Eclipse? Idea? Vim? Podelte se prosim o zkusenosti. Zatim pouzivam nb, ale rad prejdu na neco lepsiho.

[xkucf03]

Nebeans. I když Někdy dělám i s eclipse (více méně z donucení), ale NB jasně vedou. Zkoušel jsem i IDEu, když jsem dostal nějakou školní licenci zadarmo, ale nezaujalo mě to. A Vim? Maximálně tak na editaci nějakých konfiguráků, na programování fakt ne. Občas ho ještě použiji na prohlížení, protože má v konsoli bezkonkurenční zvýrazňování syntaxe (lepší než mcedit).

[vulgární Nick]

Mám to úúúplně stejně.

NetBeans je jednoznačně nejmíň na hovno a je mi tak nějak nejblíž. Eclipse používám, když mě k tomu nutěj, jinak se mi jako systém moc nelíbí. IDEA se nejvíc chlubí věcma, který mě zrovna moc nezajímaj. A vim je príma zvýraznění syntaxe, ale tím to tak hasne.

[vulgární Nick]

Ale na druhou stranu musím říct, že třeba vývoj IDEA moc nesleduju, takže to dneska může bejt jinak, než když jsem to zkoušel.

[Radek Miček]

Jednou z výhod Vimu je, že v něm lze bez problémů pracovat i s většími soubory.

[Miloslav Ponkrác]

ha ha ha

Jako člověk, který má vim otevřený fakticky od rána do večera uvažuji, že si raději nějaký editor zbastlím sám.

Při editaci třeba 300 MB sql skriptu už vim používám jen opravdu v nouzi. Protože opravdu ale opravdu to nemá lagy (ironie).

Nemluvě o tom, že vim nezvládá Unicode, a navíc už se sype. Na Windows například gvim není schopen vytisknout UTF-8 text a můžete mu nastavit encoding jaký chcete. Už mě přestává bavit neustále otvírat Word, nebo notepad jenom proto, abych do něj zkopíroval text z vimu a vytiskl ho.

[vice]

ha ha ha Při editaci třeba 300 MB sql skriptu už vim používám jen opravdu v nouzi. Protože opravdu ale opravdu to nemá lagy (ironie).

Zkuste ":syntax off", zvýrazňování syntaxe je ve vimu skutečně bída. Pokud Vám to dělá i bez zvýraznění syntaxe, tak mě udivujete. Ale SQL bez syntaxe ... to jsem o deset let zpátky Nicméně když toto opomenu, neznám nic lepšího (univerzálního).

[m-a]

IDEA.

[pht]

Co preferujete? Netbeans? Eclipse? Idea? Vim? Podelte se prosim o zkusenosti. Zatim pouzivam nb, ale rad prejdu na neco lepsiho.

IntelliJ IDEA, osobně oceňuji spoustu věcí, např:

• Rychlost - při tom všem co to umí to dělá všechno brutálně rychle oproti ostatním IDE
• Prostě to funguje (tm) - žádné chyby, workaroundy, systém "nelze", zkoušení milionu pluginů, chození po fórech
• Opravdu hodně dobré doplňování, které z nula nebo jednoho napsaného písmenka dovodí správné pokračování
• Inteligentní pochopení toho co píšete, když do stringu napíšete regexp/SQL/XML/HTML/jakýkoliv jazyk..., tak se k tomu chová jako k regexpu nebo SQL, se vším všudy - automaticky to rozezná tam kde to má být (např. Pattern.compile) nebo lze libovolně měnit ručně
• Podpora známých technologií (zejména v placené verzi) - Hibernate, Spring, tuna dalšího - rozumí XML deskriptorům, má na to nástroje, funguje tam doplňování, refactorování, ...
• Dobrá podpora Gitu a skvělá podpora Maven - tohle byl myslím poslední hřebík do rakve těm co u nás dlouho vydržovali Eclipse
• Hromada automatických refactorování kódu - tohle je pro mě hodně důležité, spousta složitějších úprav se dá udělat bezbolestně a rychle, dál pak s tím souvisí code intentions - stačí říct přehoď if podmínku, rozviň výraz, atd, místo zuřivého psaní
• Hromada inspekcí kódu, často s možností automatické opravy
• Vynikající debugger, analyzátor toku dat (z proměnné do proměnné), závislostí modulů, duplicit kódu...
• ... a spousta dalšího, přičemž pokud výše uvedené nestačí, tak IntelliJ má i velmi dobrou podporu pro bash skripty :)

[msk]

Roky som robil na NetBeans, teraz pol roka z donutenia na Eclipse/RAD ( a bohuzial windows ). Momentalne sa nachadzam v stave, ked si netbeans az tak velmi nepamatam a eclipse este poriadne nepoznam. Kazdy ma nieco do seba, na eclipse ma sere nespolupraca s maven, neuveritelna pomalost ( moze byt sposobene zaostalym OS / filesystemom ), neuveritelna zravost pamati, nepouzitelny profiler, co to by sa este naslo ...

[kozzi]

NetBeans a Eclipse stridave pouzivam a v praci a muzu rict ze ani jedno neni zrovna idealni, rychlostne me nejvice vyhovovalo kdevelop, ale to zase melo dalsi chyby a neprijemnosti, takz ebylo nepouzitelne. Netbeans mi bralo menen pameti nez eclipse ale zase bylo mirne pomalejsi v doplnovani a celkove rekace mi prisli oproti eclipse horsi. Nove eclipse indigo mi ted celekm svizne frci, ale to zrani RAMky je opravdu neprijemne, ale pokud jsem si nainstaloval 32bit system tak to bylo v pohode, to pak NetBeans i Eclipse brali do 400MB, na 64bit si vezmou klidne pres 1GB

[Bedňa]

Hmm a na čo ju použije, kua tá Java má samé killer features.

[________________]

ja som na PHP a Javu používal NetBeans nakoniec som ale prešiel na Notepad++ neni to síce IDE ale rýchlo to štartuje(nemám náladu čakať 15 sekúnd na spustenie) a nerobí mi to rôzne haluze v kóde, ono NetBeans je ajtak mizerné IDE refactoring nie vždy funguje takže ho vpohode zastúpi aj editor. V Jave už neprogramujem a na .NETové jazyky(C# a F#) mám Visual Studio na Ruby on Rails používam tiež Visual Studio, na Python používam tiež Visual Studio, na JS a CoffeeScript si vystačím s Notepad++ a k tomu správca Javascriptových projektov ktorý som si napísal sám.