Filozoficzne pytanie
Mam silny background .NET-owy, zdarzyło mi się dłużej programować w Javie. Właściwie od kiedy zacząłem programować bardziej „na serio”, towarzyszyło mi Visual Studio, Eclipse, czy NetBeans. Od zawszę więc myślałem, że dobre środowisko pracy, to podstawa. Bynajmniej, nie twierdzę teraz inaczej – ale czy dobre środowisko oznacza ciężkie, w pełni wyposażone, dopasowane do danego języka IDE? A może „zwykły” edytor tekstu wystarczy?
Rys historyczny
Pierwszą styczność z edytorem tekstu, konkretniej z vim-em zawdzięczam mojemu Wspaniełemu Koledze. Wtedy, szczerze powiedziawszy, nie spodziewałem się, że ktokolwiek tego używa – nie działa backspace, trzeba wcisnąć „i”, żeby pisać i nie da się z niego wyjść? Żartów z niego było co niemiara ;> ale Michał poruszał się w nim całkiem sprawnie. Niedługo i ja musiałem się nieco do niego przekonać, gdyż jest on podstawowym (jedynym) wyposażeniem w części pracowni na mojej zacnej uczelni. Hmm.. przekonać to za dużo powiedziane – wypadałoby to raczej nazwać – powstrzymywaniem nienawiści :)
Sytuacja uległa nieco zmianie, gdy przeczytałem (bardzo dobry moim zdaniem) artykuł Roba Conery’ego właśnie o edytorach tekstu, głównie o vim-ie. Pomyślałem wtedy, że coś w tym musi być! Poszperałem więc w internecie, obejrzałem screencast podlinkowany przez Roba.. i dałem vim-owi drugą szansę. Realizowałem akurat całkiem duży (jak na realia szkolne) uczelniany projekt, więc szansa była. Tym razem miałem w sobie więcej entuzjazmu i po niełatwej przeprawie udało się – dostrzegłem urodę edytorów tekstu!
Bolesna przesiadka
Nie ma co ukrywać, że zmiana IDE na edytor jest bolesna, bardzo bolesna. Zaryzykowałbym stwierdzenie, że większość osób, która nawet próbuje, odpada bardzo szybko. Tak było i w moim przypadku, ale za którymś podejściem się przełamałem. Edytory takie jak vim lub Emacs wprost „z pudełka”, z przydatnych rzeczy, oferują podświetlanie składni dla kilku języków.. i to by było na tyle. Dodajmy do tego, że nawet podstawowa obsługa i nawigacją są skomplikowane i katastrofa gotowa ;)
Obrazek ten jest humorystyczną ilustracją tego o czym mówię :) Co zatem przyciąga licznych wyznawców tekstowych edytorów?
Nieskończone dobro
Oba wspomniane edytory posiadają nieograniczone możliwości konfiguracyjne – skonfigurować można dosłownie wszystko za sprawą specjalnych, charakterystycznych dla danego edytora języków. Jasnym chyba jest, że dzięki temu zaprogramować można w nich wszystko, nawet przejmowanie kontroli nad światem :>
Użytkownicy nie muszą jednak programować wszystkiego sami – istnieją setki, tysiące (miliony?) pluginów zarówno do Emacsa jak i vima. Pomyśl nad najbardziej absurdalną rzeczą, jaka przychodzi Ci do głowy i jaką może mieć edytor (i nie, przeglądarka WWW, gry, organizator czasu to nie są absurdalne rzeczy) – tak Emacs ma ją już napisaną :)
Właśnie za sprawą owych dodatków (własnych, ściągniętych, czy też dostosowanych) dostajemy do edytorów wsparcie do rozmaitych języków programowania (podświetlanie składni, snippety, uzupełnianie, połączenie z debuggerami, integracja z narzędziami do testowania itd. itp.). W ten sposób ujawnia się jedna z największych zalet edytorów – uczymy się narzędzia RAZ i używamy go do wszystkich języków programowania, robiąc tylko odpowiednie dostosowania. W ten sposób zwraca nam się zainwestowany na początku czas – z nawiązką.
Last but not least pamiętajmy, że edytory nastawione są na.. edycję. W związku z tym mają niezwykle bogate możliwości edycji tekstu (a tym przecież jest kod!) i to w sposób łatwy i szybki. Pomyślcie teraz – czy więcej czasu podczas kodzenia spędzacie na pisaniu, czy edycji tego co już powstało? No właśnie :)
Co edytor zrobił dla mnie?
O tym postaram się napisać w przyszłości, prezentując przy okazji używane przeze mnie dodatki. Niestety, nie będą to tutoriale step-by-step, gdyż sam jeszcze jestem lamką :)
Poniżej jeszcze kilka linków do poczytania:
Wpis na blogu Roba Conery’ego podlinkowany wyżej
Bardzo dobry wpis o edycji tesktu w vimie, przedstawiający „filozofię” tego edytora
hehe ciekawy art i muszę się z nim zgodzić. Jednak ja także nie miałem odwagi używać vim’a do trochę wiekszych projektów. Zazwyczaj – krotki kod lub mała edycja – vim,
zaś większe projekty ( składające się z kilkunastu/dziesięciu plików) tworzyłem w code::blocks.
Zawsze się zastanawiam dlaczego VisualStudio zajmuje tak wiele miejsca na dysku twardym. Oczywiście mam świadomość że część z tego to biblioteki .NET itp.
Może cały czas modyfikowana jest kiepska pierwsza wersja, co lawinowo pociąga za sobą straty w wydajności. Bo nikt nie chce się odważyć zbudować VS od nowa.
Hmm.. w sumie rzeczywiście – tego miejsca coraz więcej, a w obecnej chwili już bardzo dużo. Nigdy się, szczerze powiedziawszy, nie zastanawiałem czemu. Może w wolnej chwili jakiś risercz ;)
Muszę powiedzieć, że według mnie nie wolno dopuścić do zaniedbania pewnego zakresu wiedzy, który na pierwszy rzut oka jest niepotrzebny bo obsługuje to za nas IDE. Jeżeli programując wiele lat w C# nigdy nie zajrzysz do csproja, sln albo nie spróbujesz skompilować wszystkiego MSBuildem z plikiem *.build to możesz mieć potem problemy z np. skonfigurowaniem daily buildów, ustawieniem NAnta, Mercuriala, SVN’a i kilku innych – a zawsze może się okazać że TFS’a lub VSS’a zabraknie (nowa firma, inny team).
Trafne spostrzeżenie, które z resztą niejako pokrywa się z opinią, iż „IDE ogłupiają” ;) Po 2 latach programowania w .NET złapałem się na tym, że nie potrafię skompilować programu z commmand line’a, w sytuacji gdy pilnie tego potrzebowałem. Dodatkowo, byłem zadziwiony jakie przydatne flagi kompilatora można ustawić za pomocą przełączników, a na które nie zwracałem uwagi.