Tady bude asi dlouha diskuze. Na linuxu je skvely, ze mam moznost volby. Ja osobne mam rad, kdyz jeden program dela jen jednu vec a dela ji dobre, cili vim. :)
Ale Emacs přeci dělá dobře jednu věc: Je výborně rozšiřitelný v jazyku kladoucím minimum omezení. Kam vede skutečnost, že z něj lidé udělali tucet editorů a jiných programů, to už je úplně jiný problém. ;-)
<justanopinion>Podotýkám, že si osobně myslím, že by bylo nejlepší přepsat Emacs do Scheme a dát mu jako default vimovské editační keybindingy. ;-) </justanopinion>
Eclipse je jeden z najhorsich IDE v ktorom som kedy robil. Zla koncepcia este horsie prevedenie. Alebo inak povedane. Cele tie perspektivy su sice pekne z logickeho pohladu, z uzivatelskeho su to len polena pod nohami. Okrem toho skoro ziadny refaktoring a ten ktory je, nefunguje. Zla az skoro ziadna navigacia po projekte. A tak je to z vela vecami. Ak to tam je, tak treba klikat jak hluchy a este byt rad, ked to nahodou funguje bez chyb. fuj.
Prestante uz s tema blabolama co akorat kazi diskuze a tim nemyslim jen toho komu odpovidam, ale cely thread az ke koreni. Napriklad ta autokompilace jde velice snadno vypnout a ten refactoring je solidni v porovnani treba s netbeans. Priste az zacenete zase flamovat zkuste to takhle:
* "Emacs je spatny, protoze jsem se v nem za 5 minut nenaucil to, co jsem se predtim rok ucil ve vimu."
* "Mam radsi vim, protoze v nem umim zapnout vysvicenou syntaxi a v emacsu ne."
* "Asi jsem blbej, ale nepochopil jsem, jak mi autokompilace pomuze ve vyvoji."
* "Mam radsi XXX protoze ma lepsi refaktorizaci javy nez eclipse, ktere jsou zkousel 5 minut a zatim jsem si neudelal cas, kouknout se, zda se "nehodou" neco za ty 2 roky nezmenilo"
Vzdy kdyz neco kategoricky odsoudite, premyslejte, zda nahodou neodsuzujete vlastni neznalost. Chlubit se vlastni hlouposti mi totiz nikdy neprislo jako dobry napad.
V eclipse robim uz docela dlho kazdy den. Za ten cas ho uz mam docela zmaknuty a viem sa jeho zradam vyhybat. A ano aj tym vypnutim autokompilacie. Lenze to nie je uplne dobry napad, pretoze ono kompilovat zasa obcas treba a tak to musim robit rucne. A eclipse je na tom kompilovani bytostne zavisly. Spatne bez toho doplnuje napriklad.
ale mozem pridat k dobru dalej
automimport v istych stavoch vobec nefunguje - aj ked funguje, funguje znacne nesikovne
subor musi byt ulozeny aby ukazoval chyby
xml editor je uplny shit
ked zmenim rucne xml deployment descriptor, tak gui depl. desc. editor je out of sync.
zakomentovavanie (CTRL+/) neposuva o riadok nizsie - prudi ked chce clovek rychlo zakomentovat par riadkov - treba oselektit....
undo nezmeni subor do nezmeneneho stavu (obsah je ten isty, ale uz ma novy timestamp) - zasa sa treba tym zbytocne zaoberat pri commitovani
kruhove zavislosti - je krasne, ze na to upozorni, lenze ked clovek robi na projekte, ktory obsahuje desiatky subprojektov, rucne dohladavanie toho cyklu je skutocna radost
kontextove menu funguje zle - ani sa mi to nechce vysvetlovat lebo ma poleje..
rename EJB projektu robim rucne v total commanderi, pretoze eclipse to zvykne uplne rozbit
...
...
...
a mohol by som...
je to vyrus tento software, co napadol mysle chudakov programatorov..
a tie perspektivy.... panecku, ja chcem mat vsetko po ruke, nechcem furt cosi prepinat
ako ono by to nebol az taky zly nastroj, keby neexistovalo nieco uplne z inej ligy..
naproti tomu mozem postavit nieco, co pozna okrem javy aj xml napriklad, vie doplnovat podla xsd, pozna spring konfiguracne subory, doplna v nich rovno triedy, metody..., rovnako ako v jave, pozna kompletne html, css, web.xml... doplna a navrhuje inteligentne, neotravuje nutnostou zbytocnych klikov, umoznuje mat zdrojak na celej obrazovke a nie to co u cloveka robiaceho v eclipse vidno velmi casto - v pravo hore akesi male okienko zo zdrojakom v ktorom si skroluje - eclipse zasiel az tak daleko, ze tejto anomalii aj prisposobil defaultne formatovanie kodu.. - ano da sa povedat, ze staci dblclick a je to na celej obrazovke, lenze da sa to aj bez toho...
Hned v úvodu píšeš že: "V eclipse robim uz docela dlho kazdy den.", a v zápětí vyjmenuješ množství chyb. Jen by mě zajímalo, proč tedy to Eclipse používáš, když je tak zabugované (podle tebe). Kup si slavnou IntelliJ IDEA (za pouhých $249 osobní licence) a můžeš se rozplývat nad ní.
"Priste az zacenete zase flamovat zkuste to takhle:
* Emacs je spatny, protoze jsem se v nem za 5 minut nenaucil to, co jsem se predtim rok ucil ve vimu."
To ne, ja bych spis napsal:
"Emacs je spatny, protoze se v nem nenaucim za hodinu to, co jsem se naucil za hodinu ve vimu, tedy ze prikazy v normal modu jsou vytvoreny logicky, napr. "W" pro skok na zacatek dalsiho slova, "0" na skok na zacatek radku, ale spoustu dalsich, kdezto v Emacsu jsou to kombinace CTRL-neco + CTRL-neco, a navic se tohle mapovani meni s kazdym typem dokumentu".
Neboli, kdyz uz prekousnu pocatecni napor CTRL-?? CTRL-?? a naucim se to, tak kdyz otevru napr. TeX soubor, tak mam dalsi CTRL-?? CTRL-?? zkratky. Tohle ve vimu myslim neni, porad tam jsou 3-4 mody a porad maji stejne chovani (pokud si nenahraju nejaky moduly nebo nepredefinuju ovladani). Tim me Emacs odradil, kdyz jsem se rozhodoval, co se naucim.
Presne tak. Ja jsem taky zacal v emacsu, ucil jsem se ho nekolik tydnu, ale blbe se mi na ty zkratky zvykalo. Pak jsem zkusil vim a za par dnu jsem se dostal dal, nez v emacsu. Tak uz jsem u vimu zustal.
Z toho samozrejme neplyne, ktery program je lepsi, ale plyne z toho, ktery je lepsi pro mne. A rekl bych, ze nejsem zdaleka sam.
Vim temer vubec neovladam, takze nemohu porovnavat. Chtel bych ale vyvratit nazor, ze mapovani klaves pro pohyb po dokumentu v emacsu jsou vymysleny nejak nahodile nebo ze jsou neintuitivni. Je to proste: pro pohyb doleva, tedy "zpet" se pouziva Ctrl-b (dale jen C-b) od slova Back. Doprava, neboli dopredu, to je C-f od slova Forward. Na dalsi (next) radku se dostanete C-n a na predchozi (previous) C-p.
Pokud se chcete zpet nebo dopredu posunout o slovo, vymenite Ctrl za Alt, tedy Alt-b a Alt-f (z historickych duvodu obvykle psano M-b a M-f). Kdyz programujete, muzete Ctr a Alt stisknout naraz a emacs bude skakat po odpovidajicich zavorkach. Stale se k nim macka stejne b a f, to je preci jednoduche ne? Navic toto se snad v zadnem modu, alespon ne v editovacim, nemeni. Minimalne si ted na zadny nevzpominam. Vse je provazano, napriklad prikazy (mappingy) M-f a M-b se skvele doplnuji treba s M-u (upcase-word), M-c (capitalize-word), M-l (downcase-word), M-Backspace (backward-kill-word), M-t (transpose-words) a dalsimi, proste Alt se pouziva na praci se slovy.
A nebo jiny priklad, kde se veci trochu v modech lisi, ale je to jenom dobre. Snad v kazdem modu je prikaz pro skok na zacatek radku C-a (coz je dukaz, ze autor screenu emacs nepouzival :-) a na konec radku C-e. V modech, kde se pracuje s klasickym textem, M-a a M-e skace na zacatek, resp. konec vety. Kdyz programujete, tak tyto prikazy skacou na zacatek nebo konec statementu. Navic potom C-M-a C-M-e premisti kurzor na zacatek ci konec funkce.
To, ze kazdy mod pridava dalsi prikazy, je preci samozrejme a moc bych se divil, kdyby to vim nedelal take (nebo snad neumi napriklad zaindtentovat region dle syntaxe daneho programovaciho jazyka?). Nic vas ale nenuti je pouzivat, pokud chcete treba v bibtexu vsechny veci rucne, prosim. Kazdy uzivatel si samozrejme pamatuje pouze nektere zkratky, dle sve chuti a schopnosti se ucit a setrit si cas. Navic snad kazdy si pridava zkratky svoje. A nakonec, samozrejme funkce lze zadavat jmenem, zvlast pokud je nepouzivame casto. Neni treba se na vsechno ucit klavesove zkratky.
Jestli vam vyhovuje vim a naucili jste se jej rychleji, proc ne. Mapovani prikazu na klavesy v emacsu je i presto velmi prakticke, intuitivni a vyborne pouzitelne.
Eclipse je výborné IDE, akorát mi tam nesedí ten koncept workspace/projekt, více se mi líbí, jak má tohle Netbeans (rovnou projekty). Teď používám víc Netbeans, ale každé má svoje :-)
Mně se líbí jeho kompaktnější jádro a taky skutečnost, že ho nesvazuje ANSI norma. Ta sice zvyšuje "průmyslovou uplatnitelnost" (která je pro mě bezcenná, protože nejsem managor a použiju nástroj kvůli jeho technickým kvalitám bez ohledu na PR a marketing), ale zase taky může zapříčinit, že Lisp (resp. jeho "Common" větev) se už jako standard nehne z místa. Ona sice je pravda, že ten jazyk je rozšiřitelný a historické nedostatky se dají překlenout knihovnami, ale pořád zůstává dosti barokní - takových deset-dvacet apendixů. ;-) A peklo pro implementátora. Vyzkoušej si Gauche Scheme a uvidíš. :-) Myslím, že PKGBUILD je v AURu, snad jen by potřeboval bumnout na další verzi. R5RS má padesát stránek - to zběžně přelouskáš za víkend. No...snad kapitolku o kontinuacích bych ale odložil. :-)
Má Erlang specifikaci (ukecanou a rozvláčnou, co do objemu plynulého textu) na pár desítek stránek? Prošel třiceti lety ořezávání do mrtě? Je homoikonický? (Pro mě dost důležité...) Spíš mám pocit, že Erlang je "mocný" asi tak, jako je "mocné" C++, ale opravdový král poměru moc/složitost je právě Scheme. Ale každému, co jeho jest. ;-) Erlang je samozřejmě fajn, ale rád bych ho viděl třebs naimplementovaný v pár kilobajtech (Ve Scheme to jde...)
erlang.org
napr. Getting started se da precist za vikend.
O Erlangu vic info i zde. Za prectecni stoji hlavne doktorandska prace Joe Armstronga.
"...že Erlang je "mocný" asi tak, jako je "mocné" C++..."
Tomu moc nerozumim. Proc by tomu tak melo byt, klidne i v pocitove rovine?
Homoikonicky nevim, co je, a pusobi to na me tak straslive moc cize, ze ani nemam moc chut to hledat (ve stardictovych slovnicich to nemam) :-)
Jinak tady nechci moc bojovat za jakysi Erlang. Jenom jsem si vsiml, ze kolem tohoto jazyka v soucasnosti je rozruch (a v budoucnosti bude jeste vetsi, nebot Pragmatic Programmers chystaji o Erlangu knizku a ti maji cuch na zajimave technologie), tak me zajimaji nazory zkusenejsich borcu, nez jsem ja.
no nevim, ale pripadny erlang kult (ErlangCult, ErlyCult?) by, jak to tak na webu zatim pozoruji, byl asi docela uzavrenou zalezitosti. Pritom jazyk je to jednoduchy... Ale blog jsem cetl a navnadil me, vedle jinych zdroju.
Delate v Erlangu neco, nebo si s nim jen tak hrajete, smim-li se ptat?
Zatím si jen hraji, přesněji benchmarkuji a srovnávám. Prozatímní výsledky jsou mírně řečeno omračující. Jediné, kde erlang trochu kulhá jsou sekvenční operace nad velkými datovými objemy. Jakmile se ale má něco udělat distribuovaně, paralelně a pod, tak se nic nechytá. Velmi rád bych v erlangu něco dělal v souvislosti s REST architekturou a zcela vážně.
tak to ja si porad hraji a vzdelavam se, nicmene citim, ze se ted deje neco velkeho a budoucnost bude mozna trochu jinsi, nez je ted (sama Java a PHP, ktere me ale intelektualne neuspokojuje), takze vaham, na co se zamerit. Zatim mi vychazi, ze onou Big Thing bude Erlang a na strane klienta (a mozna nejen tam) novy ECMAScript. A Ruby jako general-purpose skriptovaci jazyk... No uvidime.
Myslím, že si to maluješ příliš optimisticky aspoň co se týká Erlangu. Spíš bych to viděl na nějaký takový Termit nad Haskelem. Erlang i přes své impresivní výkonnostní charakteristiky prostě není dost cool. Jenže než dospěje Termit (Scheme) nebo něco podobného pod Haskelem na úroveň dnešního Erlangu/OTP, tak to uteče ještě hodně vody :-( Jenže general purpose erlang rozhodně není. V úlohách kde Erlang nedostačuje prostě dnes musíš sáhnout po portech a to je v rozporu s general purpose jazykem. Tady má Haskel i Scheme větší šance.
Da sa v Erlangu/Haskelli nejak "imitovat" prologovske parsovanie vyrazov? Napr:
p(A+B) :- p(A),p(B).
p(A*B) :- p(A),p(B).
...
Viem, ze Erlang ma parser yecc (a Haskell ma tusim tiez nejaky), ale na taketo jednoduche vyrazy (zatvorky, unarne, binarne operatory a atomy) je to dost kanon na vrabce.
Poznam Erlang celkom dobre, pracoval som s nim komercne v jednej Bratislavskej firme. Neviem ci sa este niekde v Cechach/Slovensku pouziva komercne. Je to zaujimavy jazyk... doporucujem pozriet veci ako Yaws (rychly web server) alebo Mnesia (replikacna databaza).
Dokonca som v nom nakodil distribuovanu neuronovu siet ako zadanie do skoly... je pravda je bola asi 10x pomalsia ako keby bola kodena nedistribuovano, ale to nieje problem jazyka ale distribucie algoritmov vo vseobecnosti...
Momentalne pouzivam Common Lisp (SBCL), REPL je REPL... pisem v nom diplomovku (somariny okolo UI). Erlan je fajn, ale to ze vlastne nema premenne, na kazde udrzanie stavu treba genserver a podobne... to mi na nom trosku vadi (alebo narabanie s maticami a pod. -> hroza)
To ma byt jako pokus o diskreditaci? Upozornuji, ze inteligentni lide vedi, ze pokusy o diskreditaci indikuji argumentacni nedostacivost pokusitele (a nejen to), atd. ...,receno jednoduse, k diskreditaci se uchyluji pouze hlupaci, ale stejne jim je to houby platne, protoze mohou 'uspet' pouze docasne, u ostatnich hlupaku.
Nahodou jsem jednou na zive.cz cetl krasnou flame, kde se jeden vydaval za druheho ... vznikla z toho tak krasna schizofrenni zalezitost, ze jsem se malem uplacal smichy. Nevim tedy, jak se smal ten, za nehoz nekdo posilal uplne debilni prispevky, asi se nesmal. Nicmene skoda, ze to vase "alter ego" nedotahlo do konce jako tenkrat. :-)
scheme je fakt hodne minimalisticky narozdil od lispu a opravdu jde precist specifikace za jeden vikend a za druhy napsat plnohodnotny interpretr. rozdil o proti clispu je v rozsahu knihoven, protoze r5rs specifikuje jenom "par zakladnich funkci" a taky v rychlosti kodu... z lispu ten surovy vykon jde vytahnout lip nez ze schemu, na drouhou stranu co jsem zkousel mzscheme s jit prekladem, tak to davalo taky rozumne vysledky...
Ackoliv je to dost kacirska myslenka, tak bych s ni souhlasil. Emacs si spoustu veci resi posvem a z toho plynou problemy s clipboardem, lokalizaci, fonty, ...
Hrozne by se mi libilo, kdyby bylo mozne spustit emacs jako embeded editor uvnitr nejakeho IDE(Vim, ze existuje emacsserver, ale to neni ono).
Emacs v posledni dobe prestava stihat a prostredi jako Eclipse a nebo Visual studio ho rychle dohaneji a na mnoha frontach ho uz predbehly o cele delky. Lisp uz bohuzel neni tak popularni jak byval a spousta veci by stala za prepsani. Treba editacni mody nevznijakaji od zacatku, ale zkopirovanim nejakeho podobneho a jeho naslednou upravou, treba:
C->C++->Java C++->C#, anebo ADA->Pascal->PL/SQL. Vysledkem je, ze emacs vlastne ma podporu
pro PL/SQL, ale cele je to nejake nedotazene a chova se to divne. Zatimco nastroj od Oracle
ktery umi "jenom" PL/SQL je nakonec mnohem pouzitelnejsi. Emacsu chybi kvalitni podpora pro
orientaci ve velkych projektech - TAGS, speedbar jsou nepouzitelne. Emacs krituzuju proto, ze ho hodne pouzivam, zatim jsem nenasel lepsi editor.
Jenže v minulém flamewaru ve článku o VIMu, právě jeho příznivci psali o tom, jak je universální a že se v něm dá dělat úplně všechno. Takže jak to tedy je? :-)
Taky mám raději více specializovaných programů než jeden universální. Mít v textovém editoru klienta jabberu nepovažuji za žádný přínos, spíše naopak. Snad leda kdyby se ten editor dal opravdu nabootovat a používat místo OS :-D
Pouzivam ERC zmineny v clanku. Hledal jsem nejaky textovy IRC klient s vice "okny" a nechtelo se mi ucit se dalsi klavesove zkratky na manipulaci s nimi. Takhle pouzivam ty, ktere uz umim. Emacs zde tedy plni ulohu jakehosi lepsiho screenu, ale navic se v tom IRC i skvele pise a IRC klient lze konfigurovat a prizpusobovat stejnym emacs-lispem, jako vse ostatni v emacsu.
Takze jestli tomu dobre rozumim, tak treba spellchecker poustite samostatne, nikoliv v ramci vimu? To, co plati pro sed, grep a sort jeste nemusi platit pro (interaktivni) aplikaci, ve ktere pisu maily nebo nedejboze zdrojaky.
(BTW, jen jednu vec, co se psani tyce, dela vyborne treba cat :-)