Як виглядає ваш робочий процес Lisp? [зачинено]

На даний момент я вивчаю Лісп, виходячи з прогресу мови, який є ОСНОВНИМ Локомотивом -> Z80 Assembler -> Pascal -> C -> Perl -> C # -> Ruby. Мій підхід полягає в тому, щоб одночасно:

• написати простий веб-скребок за допомогою SBCL, QuickLisp, closure-html та drakma
• дивіться лекції SICP

Я думаю, що це працює добре; Я розвиваю хороші «окуляри Lisp», завдяки чому тепер можу читати Lisp досить легко. Я також відчуваю, як працює екосистема Lisp, наприклад, Quicklisp для залежностей.

Що мені справді не вистачає, це відчуття того, як насправді працює досвідчений Ліспер .

Коли я кодую .NET, у мене створена Visual Studio з ReSharper і VisualSVN. Я пишу тести, реалізую, рефактор, виконую. Потім, коли мені достатньо для цього, щоб закінчити історію, я пишу кілька AUAT. Тоді я починаю розробку випуску на TeamCity, щоб підштовхнути нову функціональність до клієнта для тестування та, сподіваємось, затвердження. Якщо це програма, якій потрібен інсталятор, я використовую або WiX, або InnoSetup, очевидно будуючи інсталятор через систему CI.

Отже, моє питання: як досвідчений Ліспер, як виглядає ваш робочий процес? Ви працюєте здебільшого в REPL або в редакторі? Як робити одиничні тести? Постійна інтеграція? Упаковка та розгортання? Коли ви сідаєте за свій стіл, розправляючи кухоль кави в один бік і обрамляючи фото Джона Маккарті в інший, що це ви робите ?

В даний час я відчуваю, що я переживаю кодування Lisp, але не розробку Lisp ...

Більшість людей на форумах comp.lang.lisp та Lisp рекомендують комбінувати Emacs та SLIME, припускаючи, що ви не хочете платити за комерційну реалізацію на зразок Allegro або LispWorks. Відео SLIME ілюструє робочий процес. Я використовую Emacs і SLIME для розробки персональних програм в домашніх умовах, і комбінація може бути дуже ефективною.

SLIME надає вам інтеграцію між Emacs та REPL. Зазвичай я завантажую всі свої файли, а потім відкриваю той, над яким працюю в Emacs. Після введення або зміни кожної функції я натискаю C-x C-e, що виконує визначення функції в REPL. Тоді я можу перейти на буфер REPL і спробувати функцію. Вся історія REPL доступна та редагується за допомогою стандартних послідовностей клавіш Emacs, тому легко повторювати функціональні дзвінки з різними параметрами.

Я працюю в першу чергу з Clojure, і ось моя настройка:

1. Eclipse IDE (я використовую це, оскільки я також багато працюю над Java, іноді в тому ж проекті, що і Clojure)
2. Плагін проти годинникової стрілки для Clojure (сюди входить REPL)
3. Створюють залежність та керують побудовою
4. Egit для контролю вихідного коду

Робочий процес під час кодування зазвичай такий:

1. Відкрийте REPL, завантажуючи всі поточні файли-джерела
2. Код і тест в REPL
3. Коли я задоволений деяким кодом, скопіюйте та вставте назад у вихідний файл
4. Іноді перезавантажуйте REPL (коли я безповоротно переплутав простір імен, або просто щоб перевірити, чи все ще працює у вихідних файлах)
5. Також пишіть тести у вихідні файли, які автоматично запускаються кожною збіркою Maven. Іноді неформальні тести, які я щойно робив на REPL, перетворюються прямо на одиничні тести.
6. Здійснення завдань тощо в цьому моменті - це майже регулярний робочий процес розвитку

В цілому він не надто відрізняється від звичайного Java / C # робочого процесу, крім більш інтерактивного використання REPL під час розробки.

Щоб доповнити інші відповіді, я роблю комбінацію стилю "Подумайте над проблемою, потім запишіть рішення" та розробку "Почніть з відбиття і перейдіть програму у форму ітеративно". Його зазвичай посередині. Що я роблю, я починаю із загального уявлення про те, як я хочу, щоб моя програма виглядала, а потім я починаю писати її, намагаючись здобути нові знання про проблемний домен у міру свого перегляду, щоб переглянути свій підхід. На практиці це означає, що я багато експериментую і пишу багато, щоб відкинути код. Я пробую різні підходи, і я можу дуже швидко перемикати напрямок. Lisp добре підходить для такого роду розвитку. Ось чому мені так не подобається TDD, я маю знати, що я хочу зробити перш за все, щоб ефективно TDD.

Ще одна важлива річ, яку я намагаюся зробити, - це більше думати про протокол між різними частинами програми. На відміну від інших мов ОО, In Common Lisp CLOS орієнтований більше на концепцію загальної функції, методи IOW живуть поза класами, і вони є центром розвитку. Іноді я просто починаю з набору GF, що визначає потрібний мені протокол, я записую просту реалізацію і використовую її для розбиття протоколу, перш ніж записати реальну реалізацію. Скажімо, я пишу шар, який зберігає купу публікацій в блозі, у мене може бути набір GF, які визначають, як створюються, редагуються та шукаються повідомлення в блогах, і я б написав просту реалізацію, яка зберігає публікації блогу в списку в пам'яті , і після того, як я задоволений своїм протоколом, я пишу реалізацію, яка зберігає публікації блогу в базі даних або записує їх у файли.

Лісп дозволяє настільки легко змінити напрямок і зробити інший підхід, коли ви знаєте, що ваше поточне рішення є надто оптимальним, що я намагаюся досягти максимальної можливості.

Також важливий момент: Використовуйте своє оточення в повній мірі, дізнайтеся про використання різних параметрів компіляції для складання вашого коду з додатковою інформацією про налагодження, скористайтеся тим, що lisp можна компілювати та інтерпретувати. Використовуйте інтроспективні засоби lisps, такі як MOP, використовуйте функції slimes для пошуку документації, інспектор використовуйте для огляду всередині об'єктів, регулярно консультуйтесь з гіперспектом, обробляйте свою систему більше як ОС, ніж статичний компілятор свого коду, це набагато більше могутній за це.

Для початківця lisp - це не стільки перемога над python, а рубіном, але, коли ви з цим отримуєте більше досвіду, ви отримуєте величезні виграші в менших умовах.

Найголовніше, що ви повинні розважатись і любити цю мову, іноді її просто легко відволікти і перейти на користування популярними в даний час мовами Blub. Якщо ви будете дотримуватися lisp, він вам окупить.

Я прагну працювати в редакторі, який має з'єднання з REPL (як правило, редагування в emacs та використання SLIME як містку до загального середовища Lisp). Я схильний починати як «знизу», так і «вгорі», працюючи до середини, переглядаючи дизайн, як іду.

Що стосується тестування, то я маю відповідь. Я вважаю, що це допомагає тестувати код під час проходження. Іноді я пишу більше формальних тестів або орієнтирів, коли я піду (як правило, колись я перебуваю на етапі оптимізації). Проводьте повільнішу, добре відому реалізацію функціоналу, експериментуйте (у вікні редактора) з кодом для оптимізованої версії, надішліть це до нижнього лежачого коду і перевірте, що він одночасно швидший і повертає ті самі результати, що й повільніше код.

Що стосується упаковки, у мене є якийсь корисний код, який допоможе мені упакувати проекти, встановлені ASDF, ляпати їх у сховище завантажень та обробляти версії.