Thursday
Mar112010
Code Bubbles
2010-03-11 10:43 
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.
7 komentarze | Podziel się | Permalink | Kategorie: Programowanie, Technologie | Tagi: clojure, emacs, java, lisp 
View Printer Friendly Version
Email Article to Friend
Reader Comments (7)
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 ;)