Огромное спасибо, Александр, это очень полезное видео. Что касается создания программ, которые нравились бы людям, расскажите пожалуйста, как добавлять к программам графический интерфейс пользователя, какие библиотеки на Ваш взгляд наиболее простые и удобные для этого.
Очень хорошо для графического интерфейса использовать библиотеку cl-cffi-gtk. Её легче установить, чем CommonQt (эту вообще не весть как запустить), а за одну только документацию авторов можно на руках носить. Там полноценный туториал, практически учебник. Сама библиотека представляет из себя обёртку над GTK-3, если не ошибаюсь. Так что используйте cl-cffi-gtk. Филипп
Я хочу сделать проект - небольшое приложение для запоминания карточек, и попробовать реализовать для неё UI с использованием разных библиотек. И конечно про все расскажу. Наверное начну этот проект ближе к концу июля.
@@regrin спасибо, я уже пытался в Portacle использовать CL-CFFI-GTK, но когда загружал её через quicklisp, появилось сообщение об ошибке типа "библиотека не может быть загружена, не найден файл LIBGLIB-2.0-0.DLL". Хотя если посмотреть папки через проводник Windows, то в папке .../win/glib/bin файл libglib-2.0-0.dll присутствует.
@@free_air_lines1633 Это прискорбно. Хотя, может оказаться так, что для других библиотек GLIB тоже нужна. Внесите жалобу на гитхабе. Я бы рад помочь но у меня Линукс. Хотя могу попробовать установить на компьютер родственников.
Привет. Подсажи, есть ли где-то видео или статьи, раскрывающие силу LISP с точки зрения построения крупных проектов? Т.е. практические примеры того, как понижается сложность восприятия, упрощается работа с проектом. Я подразумеваю случай, когда всего один человек его разрабатывает.
Для меня важны три особенности Lisp ускоряющие разработку: - интерактивность: можно быстро посмотреть что происходит с программой и исправить её (про интерактивность: th-cam.com/video/JklkKkqSg4c/w-d-xo.html) - макросы: можно создавать свои "под языки" и писать программу в терминах бизнес-логики. Код получается более сжатый и эффективность разработки возрастает (пример языка для CI: th-cam.com/video/j2d5hYGVI7M/w-d-xo.html) - CLOS и мультиметоды позволяют очень гибко использовать ООП: gigamonkeys.com/book/object-reorientation-generic-functions.html, ну и в целом рекомендую Practical Common Lisp почитать, я именно с этой книги начал и подсел на Common Lisp)
@@40Ants >интерактивность: можно быстро посмотреть что происходит с программой и исправить её Что-то вроде такой интерактивности дает Jupyter Notebook. Бывает много ситуаций, когда каждый раз целиком какой-то python скрипт перезапускать становится крайне неудобным. Особенно, когда ты с нейронками что-то делаешь. И тогда переходишь на Jupyter, которого как раз достаточно, чтобы "по кусочкам" дальше что-то дописать и смотреть моментально результат, запуская только отдельные ячейки. Очень удобно. Итеративно двигаешься дальше и дальше, дописывая всякую логику, не перезапуская предыдущие этапы обработки данных. > макросы: можно создавать свои "под языки" и писать программу в терминах бизнес-логики. Вот это я пытался в примерах "присмотреть", но что-то все не то... Я макросы еще 20 лет назад любил писать на C, чтобы делать код проще и короче. Сейчас вот пытался увидеть что-то такое вдохновляющее на LISP, но так и не увидел ничего понятного и наглядного, чтобы сразу почувствовать -- ВОТ! Попробовал придумать что-то на своем коде. Даже пооткрывал всякое свое на питоне, пытаясь найти места, где можно было бы что-то реализовать более высокоуровнево. На уровне синтаксиса, а не функций. Я, кстати, и на Nim когда-то тоже открыл про макросы почитать, когда хотел частично и его использовать для некоторых задач. Думал-думал... И тогда тоже не увидел мест, где они бы мне пригодились. :) Сейчас только подходящее место в телеграм-боте вижу, где сначала идут функции-обработчики, а затем внизу целый список последовательного добавления их в диспатчер... Типа вот такого (и так для каждой команды): dispatcher.add_handler(CommandHandler('remove', remove_player)) Вот там -- да, я бы сделал макросом. Я там, конечно, пробовал и в функциональном стиле, кишками наружу, так сказать, применяя map на list команд, но потом переделал обратно. Никак это код не улучшает, так как список приходится поддерживать все равно вручную. Вместо простого объявления функции (и последующего вызова dispatcher.add_handler для каждой) def remove_player(update, context): код функции можно было бы что-то вроде register_handler_for_command 'remove': код функции Чтоб и регистрировала в диспатчере ее сразу, и еще когнитивную нагрузку снимало даже тем, что скрывает и имя функции и шаблонные параметры (одинаковые для всех обработчиков). В общем, не так-то и просто найти место, где будет адекватно вводить новую лишнюю абстракцию, которая упростит код, а не усложнит его.
![40Ants – programming in Common Lisp [EN subs]](http://yt3.ggpht.com/QtZEURPeeaf_Pp-9B2THu4Hqb-PkKUnHT6IbbtvQCoF9M_cHKEsdwSas4n5q9U1Mt1FzMaMpTw=s48-c-k-c0x00ffffff-no-rj)
![What to replace the disgusting YAML with? [EN Subs]](http://i.ytimg.com/vi/j2d5hYGVI7M/mqdefault.jpg)
![What to replace the disgusting YAML with? [EN Subs]](/img/tr.png)
![Real Image-based Approach in Common Lisp [En subs]](http://i.ytimg.com/vi/nsKx40ab9SY/mqdefault.jpg)
Very good, as usual. Thank you for the good-quality tutorials.
Soon I'll make another video about packaging Common Lisp apps for OSX and Homebrew.
Muchas gracias. Maravilloso video
Огромное спасибо, Александр, это очень полезное видео. Что касается создания программ, которые нравились бы людям, расскажите пожалуйста, как добавлять к программам графический интерфейс пользователя, какие библиотеки на Ваш взгляд наиболее простые и удобные для этого.
Очень хорошо для графического интерфейса использовать библиотеку cl-cffi-gtk. Её легче установить, чем CommonQt (эту вообще не весть как запустить), а за одну только документацию авторов можно на руках носить. Там полноценный туториал, практически учебник. Сама библиотека представляет из себя обёртку над GTK-3, если не ошибаюсь. Так что используйте cl-cffi-gtk.
Филипп
Я хочу сделать проект - небольшое приложение для запоминания карточек, и попробовать реализовать для неё UI с использованием разных библиотек. И конечно про все расскажу. Наверное начну этот проект ближе к концу июля.
@@40Ants спасибо! Ждем с нетерпением!
@@regrin спасибо, я уже пытался в Portacle использовать CL-CFFI-GTK, но когда загружал её через quicklisp, появилось сообщение об ошибке типа "библиотека не может быть загружена, не найден файл LIBGLIB-2.0-0.DLL". Хотя если посмотреть папки через проводник Windows, то в папке .../win/glib/bin файл libglib-2.0-0.dll присутствует.
@@free_air_lines1633 Это прискорбно. Хотя, может оказаться так, что для других библиотек GLIB тоже нужна. Внесите жалобу на гитхабе. Я бы рад помочь но у меня Линукс. Хотя могу попробовать установить на компьютер родственников.
En español también funciona la traducción
Привет. Подсажи, есть ли где-то видео или статьи, раскрывающие силу LISP с точки зрения построения крупных проектов? Т.е. практические примеры того, как понижается сложность восприятия, упрощается работа с проектом. Я подразумеваю случай, когда всего один человек его разрабатывает.
Для меня важны три особенности Lisp ускоряющие разработку:
- интерактивность: можно быстро посмотреть что происходит с программой и исправить её (про интерактивность: th-cam.com/video/JklkKkqSg4c/w-d-xo.html)
- макросы: можно создавать свои "под языки" и писать программу в терминах бизнес-логики. Код получается более сжатый и эффективность разработки возрастает (пример языка для CI: th-cam.com/video/j2d5hYGVI7M/w-d-xo.html)
- CLOS и мультиметоды позволяют очень гибко использовать ООП: gigamonkeys.com/book/object-reorientation-generic-functions.html, ну и в целом рекомендую Practical Common Lisp почитать, я именно с этой книги начал и подсел на Common Lisp)
@@40Ants
>интерактивность: можно быстро посмотреть что происходит с программой и исправить её
Что-то вроде такой интерактивности дает Jupyter Notebook. Бывает много ситуаций, когда каждый раз целиком какой-то python скрипт перезапускать становится крайне неудобным. Особенно, когда ты с нейронками что-то делаешь. И тогда переходишь на Jupyter, которого как раз достаточно, чтобы "по кусочкам" дальше что-то дописать и смотреть моментально результат, запуская только отдельные ячейки. Очень удобно. Итеративно двигаешься дальше и дальше, дописывая всякую логику, не перезапуская предыдущие этапы обработки данных.
> макросы: можно создавать свои "под языки" и писать программу в терминах бизнес-логики.
Вот это я пытался в примерах "присмотреть", но что-то все не то... Я макросы еще 20 лет назад любил писать на C, чтобы делать код проще и короче. Сейчас вот пытался увидеть что-то такое вдохновляющее на LISP, но так и не увидел ничего понятного и наглядного, чтобы сразу почувствовать -- ВОТ!
Попробовал придумать что-то на своем коде. Даже пооткрывал всякое свое на питоне, пытаясь найти места, где можно было бы что-то реализовать более высокоуровнево. На уровне синтаксиса, а не функций. Я, кстати, и на Nim когда-то тоже открыл про макросы почитать, когда хотел частично и его использовать для некоторых задач. Думал-думал... И тогда тоже не увидел мест, где они бы мне пригодились. :)
Сейчас только подходящее место в телеграм-боте вижу, где сначала идут функции-обработчики, а затем внизу целый список последовательного добавления их в диспатчер... Типа вот такого (и так для каждой команды):
dispatcher.add_handler(CommandHandler('remove', remove_player))
Вот там -- да, я бы сделал макросом. Я там, конечно, пробовал и в функциональном стиле, кишками наружу, так сказать, применяя map на list команд, но потом переделал обратно. Никак это код не улучшает, так как список приходится поддерживать все равно вручную.
Вместо простого объявления функции (и последующего вызова dispatcher.add_handler для каждой)
def remove_player(update, context):
код функции
можно было бы что-то вроде
register_handler_for_command 'remove':
код функции
Чтоб и регистрировала в диспатчере ее сразу, и еще когнитивную нагрузку снимало даже тем, что скрывает и имя функции и шаблонные параметры (одинаковые для всех обработчиков).
В общем, не так-то и просто найти место, где будет адекватно вводить новую лишнюю абстракцию, которая упростит код, а не усложнит его.