Emacs i „samowzmacniająca się wydajność”

Krótko mówiąc, moje pytanie do was, hardkorowych użytkowników Emacsa, brzmi: czy osiągnęliście tę „ samowzmacniającą się wydajność”, o której mówi Steve Yegge ?

Emacs jest samowystarczalny: pisanie w nim rzeczy sprawia, że ​​samo środowisko jest silniejsze. To pętla sprzężenia zwrotnego: rekurencyjny, samowzmacniający się, multiplikatywny efekt, który ma miejsce, ponieważ poprawiasz środowisko, którego używasz do tworzenia ulepszeń.

Czy naprawdę uważasz, że ulepszenie Emacsa w końcu spowodowało, że stałeś się 10-krotnie bardziej produktywny , a Twoja produktywność rośnie wykładniczo i tak dalej?
Czy masz jakieś przykłady / doświadczenia, którymi możesz się podzielić?

Jeśli chodzi o mnie, używałem zarówno Emacsa, jak i Vima do programowania (obecnie trzymam się Vima), moje .emacsi .vimrcoba są dość skonfigurowane, aby odpowiadać moim potrzebom i doceniam moc obu tych edytorów. Ale nie doświadczyłem „samowzmacniającej się pętli” tego Emacsa, ani nie spotkałem kogoś, kto to zrobił (oczywiście może to być spowodowane tym, że nie jestem naprawdę hardkorowym Emacserem i nie spotkałem jeszcze tylu Emacserów).

Na przykład na Facebooku facet obok mnie używał Vima, a facet obok niego używał Emacsa. Obaj byli szybcy i produktywni jak diabli, i przypisuję to nie redaktorowi, którego używali, ale ich własnej inteligencji i postawie.

Ale i tak chętnie zobaczę zdumiewające przykłady zwolenników Emacsa, które zawrócą mnie z powrotem do Kościoła Emacsa.

10 X bardziej produktywny ? Raczej nie. Myślę, że mnożniki są bardziej podobne do 1.1, co po pewnym czasie się sumuje.

To, o czym mówi Steve Yegge, jest refleksją na temat bycia ekspertem od Emacsa, a te są bardzo rzadkie. Ludzie, którzy osiągają ten multiplikatywny efekt, aktywnie dostosowują swoje doświadczenia Emacsa, pisząc elisp, aby dostosować Emacsa do swoich konkretnych potrzeb. Na przykład Yegge napisał ejacs . Interpretacja cytatu Yegge oznacza, że ​​dostosowujesz Emacsa, aby ułatwić dostosowanie / rozszerzenie Emacsa.

Oto, w jaki sposób podzieliłem różne poziomy wiedzy specjalistycznej dotyczące Emacsa:

• Początkujący wie jak uruchomić Emacs, przesuwać kursor, wprowadzić pewne zmiany, wyjścia Emacs.
• Początkujący zaawansowany wie jak umieścić kilka podstawowych dostosowań w ich .emacslub całkowicie skopiowane fragmenty cudzych .emacsdo nich. Wiedzą, jak tworzyć globalne powiązania klawiszy, requirewbudowane pakiety, włączać pomniejsze tryby.
• Kompetentni użytkownicy Emacsa mają duże .emacspliki, prawdopodobnie podzielone na wiele plików. Pobierają i używają niestandardowych pakietów, wiedzą, jak znaleźć dokumentację poleceń, trybów, przeglądają istniejące powiązania klawiszy, znają różnice między trybami mniejszymi i większymi. Kompetentni użytkownicy zazwyczaj utrzymują jedną instancję Emacsa działającą przez kilka dni / tygodni, pisząc, kompilując, uruchamiając i debugując programy z Emacsa.
• Biegli użytkownicy są wygodni w pisaniu emacs lisp, tworząc własne interaktywne polecenia, i swobodnie piszą mniejsze tryby. Biegli użytkownicy patrzą na kod emacs lisp, aby lepiej zrozumieć tryby, z których korzystają, używają debugera elisp i często używają gorszych procesów (powłoki, procesy lisp, ...).
• Użytkownicy Expert Emacs piszą nowe główne tryby od zera, szukają i modyfikują kod C dla Emacsa, wiedzą, czym jest edycja rekurencyjna i używają jej, używają komunikacji między procesami w celu zintegrowania Emacsa z narzędziami zewnętrznymi. Przeczytali również listę mailingową emacs-devel .

A ponieważ prosisz o osobiste doświadczenie, oto przykłady tego, co osobiście zrobiłem, dzięki czemu czuję, że jestem bardziej produktywny. Uwaga: Zdarza się, że pracuję w firmie, w której nie jesteśmy blisko najnowocześniejszych środowisk programistycznych, na przykład nadal używamy CVS.

• Zintegrowałem Emacsa z narzędziem do śledzenia błędów: kiedy dokonuję zatwierdzeń, loguje nazwę pliku i wersję w polach błędu, a z Emacsa mogę przeglądać moje błędy, przypisywać je, usuwać itp.
• Napisałem pomost łączący mój produkt (dzienną pracę) z Emacsem, skutecznie czyniąc mój produkt gorszym procesem - umożliwiając mi dokonywanie zmian w kodzie źródłowym na bieżąco.
• Rozszerzyłem obsługę TAGS o find-file-in-tags, który zapewnia szereg skrótów, które pasują do mojego środowiska programistycznego.
• Napisałem tryb, który pobiera wyniki regresji i pozwala mi przeskakiwać do awarii, sprawdzać pliki dziennika, ponownie uruchamiać jeden lub więcej testów lub wchodzić w debugowanie przy minimalnym naciśnięciu klawisza.
• Mój cotygodniowy raport o stanie (tak, używam Emacsa do poczty e-mail) jest generowany automatycznie przy użyciu zatwierdzeń dokonanych przez cały tydzień.

Są to zmiany, które wprowadziłem, aby dostosować Emacsa do mojego środowiska i przepływu pracy.

Czy jestem 10 razy bardziej wydajny niż inni wokół mnie? Nie.

Jednak w mojej codziennej pracy jest wiele zadań, które mogę wykonać kilkoma naciśnięciami klawiszy, które inni spędzają znacznie dłużej w swoim niestandardowym środowisku i które zazwyczaj wymagają przełączania między edytorem a przeglądarką internetową lub powłoką .

Czy są to zdumiewające przykłady? Nie. Jestem pewien, że wiele z tego, co zrobiłem, jest już dostępnych w Visual Studio . Czy mój artykuł skieruje cię z powrotem do Kościoła Emacsa? Prawdopodobnie nie.

Jeśli jednak widzisz wzór zachowania w swoim środowisku programistycznym i odczuwasz swędzenie, które mówi: „Naprawdę nie powinienem musiałem robić X / Y / Z w kółko, gdybym tylko mógł ...” Polecam spróbować użyć Emacsa do podrapania tego świądu. Ta rysa może być pierwszym krokiem w dół tej „samowzmacniającej” ścieżki, o której mówi Steve Yegge.

Drobna uwaga: nie wiem, czy wielu (w ogóle?) Naprawdę doświadczonych użytkowników Emacsa aktywnie korzysta z witryn z przepełnieniem stosu, a przynajmniej nie odpowiada na pytania związane z Emacsem. Mówię to na podstawie najlepszych użytkowników tagów emacs i elisp w przypadku przepełnienia stosu.

Dowody te są oczywiście anegdotyczne, ale twoje pytanie wyraźnie wymaga anegdotycznych dowodów.

Jestem studentem prowadzącym badania w laboratorium akademickim, które obejmują zarówno obliczenia naukowe, jak i pisanie. W takim środowisku (pomyśl: python, SQL, akademickie narzędzia wiersza polecenia specjalnego, pliki tekstowe, LaTeX / BibTeX), uczenie się emacsa z grubsza odróżnia pacy ręcznej od koparki. Po roku emacsa (po którym oceniłbym siebie jako solidnego kompetentnego z palcem zanurzającym się w Proficient), Chętnie radzę sobie z problemami, których obawiają się moi koledzy z pracy. Nie dlatego, że są leniwi, a ja jestem sumienny, ale dlatego, że fajnie jest zburzyć góry koparką i uciążliwe jest drapanie się w górach za pomocą pacy. Co najmniej dwa razy mój zespół zaczął spierać się o wprowadzenie skomplikowanych zmian w formacie raportu, ale okazało się, że zadanie to zostało już ukończone, zanim jeszcze skończyły się kłótnie na temat tego, kto musiał to zrobić. Regexp zamień + osadzony elisp.

Więc w sensie pierwszego rzędu, tak, emacs sprawił, że jestem znacznie bardziej produktywny.

Wygląda na to, że pytasz o zyski z produktywności w sensie drugiego rzędu: czy moje zwroty z emacsa się łączą? Chociaż nie oceniłbym siebie całkowicie biegle , nie mówiąc już o Yegge , myślę, że zaczynam widzieć stopę wykładniczej krzywej, a moje użycie emacsa sprawia, że ​​dalsze emacowanie jest jeszcze bardziej produktywne. Kilka krótkich, anegdotycznych statystyk z repozytorium w celu kwantyfikacji:

• W 7-osobowym zespole byłem odpowiedzialny za ponad połowę zobowiązań. Dostosowując się do stażu pracy, wciąż popełniam prawie dwa razy częściej. Nie dlatego, że jestem prawie dwa razy bardziej niesamowity, ale dlatego, że emacs praktycznie wszystko obsługuje kontrolę wersji. Ponieważ mogę bezboleśnie zatwierdzać, aktualizować i scalać, melduję się za pomocą mniejszych oddzielnych porcji, jak wszyscy powinniśmy robić. Ale to oznacza, że ​​czuję się swobodniej podejmować „większe ryzyko” (muszę wspomnieć, że piszemy eksperymentalny kod do badań naukowych, a nie do produkcji), co oznacza, że ​​uczę się więcej o programowaniu i moim temacie.

• W ostatnim raporcie, który napisaliśmy, svn blame mówi mi, że byłem odpowiedzialny za więcej linii niż trzykrotność pozostałych dwóch autorów łącznie . (Nie chodzi tylko o to, że miałem ostatnie zatwierdzenie. Przez jakiś czas byłem tym ciekawy, więc zacząłem go śledzić, a wyniki były dość stabilne w całej historii wersji.) Ponieważ jestem 6 razy szybszym pisarzem? Nie: ponieważ emacs to piła łańcuchowa do tekstu. Oznacza to, że mogę wykonać operacje LaTeX, których nigdy wcześniej nie próbowałbym. Co oznacza, że ​​lepiej rozumiem LaTeX, co czyni mnie jeszcze bardziej produktywnym w przyszłości.

• 100% dokumentacji (zarówno dla kodu, jak i wewnętrznych notatek z badań) jest moja. Ponieważ moi koledzy z pracy nie dbają o dokumentację? Cóż, tak naprawdę nie przejmowałem się tym, zanim znalazłem tryb org. Podczas gdy jestem typowo uber-typ-B w tych sprawach, tryb org zmienił się w łagodne uzależnienie. Natychmiastowy eksport Org-mode do ładnie wyglądającego html i LaTeX usunął wszystkie bariery odpowiedzialnej dokumentacji i zmienił ją w rodzaj gry. Więc teraz to robię. Gdyby tak nie było, nie zrobiłbym tego, a przynajmniej bałem się tego, odkładałem i pozwalałem mu wysysać energię mentalną.

Inni komentatorzy sugerują, że związek przyczynowy może być dokładnie odwrotny: być może emacs nagradza wysoce produktywne, co podważyłoby pewność z hipotezy, że użytkownik mediany prawdopodobnie odniesie jakiekolwiek korzyści. Mogę również zasugerować coś w rodzaju samospełniającego się efektu placebo: czy emacs uczynił mnie bardziej produktywnym (i oczywiście nigdy się nie dowiemy, ponieważ nie mam identycznego bliźniaka, który nie nauczyłby się emacsa), mam z pewnością doświadczyłem objawienia w moim związku z tekstem ustrukturyzowanym. Jestem podekscytowany używaniem emacsa, co oznacza, że ​​używam go częściej, co oznacza, że ​​dowiaduję się więcej na ten temat, jestem bardziej podekscytowany, i c. Kiedy odkryłem tryb BibTeX, pamiętam, jakbym właśnie zaprosił dziewczynę na pierwszą randkę.

Na wypadek, gdybyś tego nie zauważył: emacs wprawił mnie w zakłopotanie na myśl o edycji baz bibliograficznych. Myślę, że w mojej pracy coś jest warte.

Na przykład na Facebooku facet obok mnie używał Vima, a facet obok niego używał Emacsa. Obaj byli szybcy i produktywni jak diabli, i przypisuję to nie redaktorowi, którego używali, ale ich własnej inteligencji i postawie.

Ta uwaga brzmi bardzo prawdziwie i ma zastosowanie w odniesieniu do każdego rodzaju wskazówek dotyczących wydajności.

Ludzie, którzy są zainteresowani zwiększaniem / optymalizowaniem swojej wydajności, wydają się być bardziej produktywni ze względu na swoje skupienie lub zachowanie w życiu, niezależnie od wydajności samej końcówki produktywności.

Można to podsumować następująco: „Nie jesteś lepszym programistą, ponieważ używasz Emacsa lub Vima, ale ludzie, którzy są wystarczająco oddani do opanowania tych narzędzi, są zwykle dobrymi programistami” [1].

1. To okropne uogólnienie, więc nie jest to absolutna prawda i tak czy inaczej niewiele znaczy (co to jest dobry / zły deweloper? Itp.)

Jestem użytkownikiem Emacsa od około 20 lat i muszę powiedzieć, że nie, nie osiągnąłem tego punktu.

Aby dostać się do „emacsvany”, o której mówi, naprawdę musisz stać się ekspertem elisp . Zrobiłem trochę, ale tak naprawdę moje umiejętności kończą się na poziomie konfiguracji nowego trybu, który napisał ktoś inny. Próba debugowania (lub Boże, nie naprawiaj) czyichś elips jest trochę poza mną, a pisanie własnego od zera nawet nie myśli.

To pochodzi od osoby, która faktycznie używała wcześniej lisp i ma ponad 20-letnie doświadczenie w tworzeniu oprogramowania.

Być może jestem po prostu dziwakiem czy coś takiego, ale podejrzewam, że bardzo niewielu użytkowników Emacsa doszło do punktu, o którym mówi.

Naprawdę nie ma w tym nic złego. Wiem, jak tworzyć makra, co samo w sobie sprawia, że ​​ładuję się bardziej wydajnie z Emacsem niż z jakimkolwiek innym edytorem tekstu. Czasami znacznie więcej niż 10 razy więcej produktywności. Nie czyni mnie to jednak lepszym niż ktoś, kto zna vi równie dobrze (ponieważ potrafi także robić makra).

Nie, nie wiedziałem i nigdy nie słyszałem o nikim, kto ma. Nie sądzę, żeby to się stało. Myślę, że Steve Yegge robi to, co robią popularni blogerzy: wygłasza kontrowersyjne, przesadzone oświadczenie, aby przekazać swoją opinię i być bardziej widocznym. Nie sądzę, żeby miał to na myśli. To, co prawdopodobnie zamierza przekazać:

Gdyby to powiedział, nie byłbyś zdezorientowany i nie miałby o połowę mniej czytelników.

Spójrz na to w ten sposób: Emacs i Vim specjalizują się w operacjach tekstowych i automatyzacji powtarzających się naciśnięć klawiszy, nie wspominając już o nawigacji dużych fragmentów tekstu. O tym mówi Yegge, choć w bardziej kaznodziejski sposób.

Jeśli masz plik 10000 linii, w którym musisz dodać numer linii na początku każdej linii, równie dobrze możesz spędzić pół dnia, robiąc to ręcznie w Notatniku.

Lub odpal makro lub użyj wbudowanej funkcji Emacsa do tego typu rzeczy. Następnie oszczędzasz pół dnia pracy i jesteś ponad 10 razy wydajniejszy.

Chodzi o wykrywanie powtórzeń i ich eliminowanie. Wymaga to inteligencji, doświadczenia, praktyki i umiejętności, więc nie każdy, kto korzysta z Emacsa, zauważy korzyści w zakresie wydajności.

Nie wiem o „N razy szybciej”, ale pewne staranne dodanie funkcji narzędziowych może sprawić, że Emacs będzie całkiem dobry w wypełnianiu szablonów. Połącz to z odrobiną świadomości języka docelowego i możesz robić rzeczy takie jak „powiedz emacsowi, że chcesz stworzyć funkcję, powiedz mu argumenty wejściowe (typy, jeśli język wymaga informacji o typie) i zwróć wartość, emacs utworzy szkielet dla dalszych Wypełniając".