Code Bubbles
2010-03-11
Sensowne.
Jestem ostatnio zmęczony programowaniem przy użyciu Emacsa. Owszem, nie ma żadnego środowiska o porównywalnych możliwościach introspekcji co SLIME w połączeniu z Clojure lub Common Lispem. Z drugiej jednak strony Emacs jest miejscami boleśnie prymitywny, a jego autorzy kurczowo trzymają się koncepcji, które są przeżytkiem lub nigdy nie działały dobrze.
Bardzo, ale to bardzo się staram nie zmęczyć na tyle, żeby zacząć coś tworzyć samemu.
textmate is the answer?
Marek: hmm? A jest SLIME dla TextMate?
Jeśli ktoś nie widział SLIME w akcji, to nie wie co traci. Nie ma nic porównywalnego.
Jak to mówią, Emacs to całkiem dobry system operacyjny, tylko brakuje w nim porządnego edytora tekstu ;)
Common Lisp: warto jeszcze wspomnieć o pluginie do Eclipse - CUSP - http://groups.google.com/group/cusp-development/?pli=1
Szkoda tylko, że projekt wydaje się zamierać powoli - na liście dyskusyjnej nie dzieje się nic od listopada zeszłego roku. Podstawowe możliwości są podobne do Emacs + SLIME (zresztą korzysta ze SLIME), tylko nie trzeba się uczyć skrótów klawiszowych emacsa ;)
No i działa ponoć tylko z SBCLem. Ale chyba niektóre komercyjne platformy (Allegro, Corman Lisp, coś jeszcze?) mają swoje IDE?
Clojure: tu jest jeszcze łatwiej i wsparcie daje nawet Intellij IDEA Community Edition (plugin) czy NetBeans itd.
Z Common Lispem jest nieco łatwiej, bo jest hemlock, którego używa LispWorks. Oni zbudowali na nim całkiem niezłe IDE. Co do Clojure, to muszę znowu spróbować tych rozwiązań — kiedyś próbowałem plugina do Eclipse i nijak się to nie porównywało do SLIME.
No i dodajmy jeszcze, że Emacsa lubię, tzn. gdyby wywalić z niego trochę przestarzałych koncepcji, to byłby bardzo fajny.
... a co do samych code bubbles, to może to trochę prowokacyjne, ale czy jeśli ktoś nie jest w stanie przechować tyle kodu/funkcji w pamięci co tam mieści się na ekranie, to czy na pewno powinien się brać za programowanie ? :)
Może na prezentacji wygląda to fajnie, ale boję się, że w praktyce wyjdzie z tego większy bałagan i robota z otwieraniem/zamykaniem bąbelków niż zysk z oglądania kawałków kodu na raz. IDE jak każda inna aplikacja ma przede wszystkim nie przeszkadzać użytkownikowi.
Tomek: no, nie wiem — mi się podoba odejście od przestarzałej już metafory pliku. Tak naprawdę operujemy na funkcjach i deklaracjach, a pogrupowanie ich w pliki jest w dużej mierze arbitralne. Mój styl pracy w Emacsie ze SLIME już w tej chwili polega na używaniu M-. do skakania do definicji tego co jest pod kursorem, rzadko kiedy otwieram pliki ręcznie. Byłoby mi wygodniej, gdyby M-. otwierało mi definicję „tego czegoś pod kursorem” w okienku obok, zamiast zastępować cały ekran innym plikiem z masą niepotrzebnych mi rzeczy.
Trudno się nie zgodzić z takim przypadkiem użycia, chociaż Lisp ze względu na zwięzłość kodu jest dość specyficzny - np. w Javie na jednym ekranie/ w klasie ledwo mieszczą się rzeczy potrzebne ;)