Финальный арт и звуки? Вы бредите. Зачем тогда нужны 3д-шники, 2д-шники и звукачи, если программисты могут сразу делать программерс-арт, который будет финальным?
Так как это делают ребята с демосцены. Они правда еще и в 64кб укладываются при этом, но это уже детали.
Насчет многого согласен, скажу лишь, что я воспринимаю Clojure как не еще одну реализацию LISP, которой он как раз не является, а скорее как самостоятельный язык в семействе Lisp, который вобрал в себя многие лучшие черты и при этом посторался сделать что-то своё, за что мне собственно и понравился.
Насчет ридер макросов в CL знаю что большинство их избегает так как они добавляют сложностей при взаимодействии с чужим кодом и это было основой причиной их отсутствия (ну и то, что у Рича были свои планы на всякие другие символы помимо скобочек).
Кстати про сигналы и систему условий - есть отличная библиотека farolero, реализующая все основные примитивы системы условий из CL. Безусловно, так как она не интегрирована в язык, а тем более в платформу, она не решает всех проблем JVM'ных эксепшенов, но сделана достаточно прозрачно чтобы её можно было интегрировать в проекты или использовать в библиотеках, даже если их пользователь ничего не знает о такой сигнальной модели (а если знает, то может пользоваться)
Не холивара ради, но по абзацу с Clojure у меня возникло несколько вопросов и уточнений.
В частности, в Clojure сильно обрезана система макросов
Интересно было бы подробнее почитать про это. В сравнении с Common Lisp макросами я особых различий не заметил. В схемах, совершенно отдельная система макросов, поэтому с ней сравнивать наверное некорректно. Конечно, я не писал большого количества макросов на CL, так что могу чего-то не знать, но в Clojure (и некоторых других диалектах) с макросами у меня довольно большой опыт, и там макросы это те же самые квазиквоты с анквотами, с манипуляцией теми же самыми списками теми же самыми операциями, с единственным различием в резолвинге имён в квазиквотировании, т.к. он сделан немного иначе. В общем если есть какая-то конкретная литература по различиям, было бы интересно взглянуть!) Про отсутствие ридер макросов знаю, в Clojure их намерено не стали добавлять, но добавили tagged literals, что дает некоторые возмоности довольно близкие к ридер макросам. Не то же самое, конечно, но и цели такой не стояло.
Объектная модель с мультиметодами - тоже уникальная особенность языка, она не использует мета-объектный протокол.
Это не объектная модель и она отнюдь не уникальна. Это обыкновенный рантайм диспатч на основе значения, делается довольно легко в многих других языках. Насчет MOPа, да в Clojure этот протокол не используется, но Clojure вообще спроектирован иначе и не предполагает объектно-ориентированного подхода за пределами взаимодействия с его хост платформой, где MOP так же не используется. Вместо ООП упор делается на функциональную парадигму с чистыми функциями оперирующими неизменяемыми данными. Есть и диспатч на основе протоколов, что очень похоже на generic функции из CL, с той разницей что работает за счет реализации этого хост платформой.
Нет и некоторых вполне дефолтных типов данных.
Например? В Clojure есть всё, что есть в Java, соответственно всё основные типы данных доступные в хост платформе доступны и в Clojure. А сам язык предлагает персистентные варианты для всех основных коллекций - множества, векторы, односвязные списки, консы, ассоциативные словари и рекорды. И для всех свои литералы, что наоборот делает чтение кода более удобным и вовсе не является сахаром, так как такие литералы вычисляются на этапе чтения, а не на этапе исполнения. Т.е. `{:a 1 :b 2}` это не просто сахар для `(hash-map :a 1 :b 2)` - у них разные семанитики построения коллекции.
Пролог, возможно, академичен, видел его всего пару раз во время учебы в университете, но более не прикасался. А вот насчет академичности лиспа не соглашусь)
Считаю, что проблема Лисп (самого чистого и простого функционального языка) и Пролога, в том, что они не алгоритмичны, а академичны.
Лисп не самый чистый и в общем-то не функциональный. Разные диалекты в этом плане могут отличаться, к примеру тот же Clojure делает большую функциональный стиль, а Common Lisp является мультипарадигмным языком, с общирными возможностями как в ООП так и в ФП парадигмах. Scheme больше полагается на функциональный стиль, но при этом обладает и императивными возможностями. А насчет академичности - обыкновенный код, как и на других языках, просто выглядит подругому и исторически имеет более удобные символьные вычисления, чем во многих других языках, так как проектировался с учетом такой потребности.
Они заставляют думать и писать по-другому, то есть простой набор инструкций или цикл, превращается в рекурсию или в написание алгоритмического языка на Лиспе
На самом деле нет. Вы можете писать на лиспе как и на любом другом императивном языке, тут это скорее зависит от идиом и основного фокуса конкретного диалекта.
Про итерацию - Clojure предлагает набор макросов и специальных форм для итерации: loop, for, while, не говоря уже о более функциональных map или reduce. Никакой рекурсии (за исключением, loop, но там это частный случай). Common Lisp имеет свой, довольно уникальный макрос loop, который предлагает очень мощный DSL для выражения итерации любого вида.
Подобное суждение скорее всего связано с тем, что вы видели, что в условном SICP всё решается через рекурсию, что на самом деле является довольно неплохой разминкой для ума, потому и использовано в книге, а в реальном коде рекурсия чаще встречается там, где она нужна, а не везде, где нужна итерация)
Лисп это компилируемый язык, с единицей компиляции форма, а не файл, как в большинстве других языков. Безусловно, есть и чисто интерпретируемые диалекты, но в основном они либо компилятся в байткод и потом JIT компилит это в натив, либо сразу компилятся в натив.
не, ну если в блокноте читать, то понятное дело. Никто же не запрещает использовать Ctags, встроенные в IDE фичи, такие как поиск символа и так далее (мазохизм конечно никто не отменял).
Такой файл как правило читается с верху в низ — если функция что-то вызывает, то оно обязательно определено ниже, так что в целом за один проход от верха до низа можно проследить одну ветвь вполне легко, а уж тем более когда можно просто прыгнуть по тегу. Функции одного уровня определяются рядом, что тоже не вносит беспорядка в файл, так что, мне кажется, эти претензии не обоснованы, просто читать и разбираться в чужом всегда лень, а особенно без комментариев. При этом я понимаю что другой человек никак не может узнать степень выразительности кода, не начав его читать, и понимаю что никто не хочет тратить время на это. Но деньги то получают за работу, значит читать надо.
на одном уровне вложенности
Что не так с одним уровнем вложенности я не понял, вы функции в глобальном пространстве видимости на разных уровнях вложенности пишете? Функции в любом случае будут на одном уровне вложенности (если конечно не определять их в классе, вложенном в класс, в класс, в класс).
Не помню делфи от слова совсем, изучал в рамках институтской программы и бросил взявшись за Си. Но тут скорее вопрос выразительности кода, чем подхода в нем используемоего. Тоесть ваш код может использовать грязные приемы, но при этом быть самодокументируемым даже в таком неприятном месте. Комментарии могут дополнить картину, но опять таки, когда-нибудь они солгут.
Так что «сделано так, потому что другой способ, очевидный, является неправильным или неэффективным» вполне нормальная ситуация если всё написано так что можно понять без комментариев.
На самом деле иногда поражает на сколько люди ленятся читать код без комментариев, даже если он сам себя комментирует через имена его компонентов. Даешь человеку прочитать свой код, чтобы обсудить с ним какую-то его часть — он возвращается с упрёком, мол «где комментарии». Я отвечаю: «а зачем, тут же всё достаточно хорошо расписано, и всё есть в документации», на что обычно я получаю ответ в стиле: «код без комментариев не может быть понятным», хотя на деле это просто человеческая лень, ведь очень демотивирует когда ты видишь исходник на 3 тысячи строк кода (отформатированных по стандарту, определенному проектом, написаным с максимальной выразительностью, и с функциями, тела которых не превышают 20 строк, и обладают единственной ответственностью) без единого комментария. Хотя если приглядеться и начать таки читать, всё читается как текст. Сам читал такой код не раз, сам пишу такой же код на работе.
Комментарий должен отвечать на вопрос «зачем» здесь этот код, какая бизнес-необходимость привела к его написанию. Тогда он не устареет вне зависимости от смены реализации.
Как правило такие комментарии называются документацией. И пишутся соответственно стандарту доументирования, как заведено в языке, например тот же Javadoc, или как заведено стандартами в компании, если имеются. Обычных болтающихся комментариев в коде стоит избегать, так как обычно единственное что можно понять из комментария, так это то, что у автора не получается писать достаточно выразительный код.
Ещё комментарий может говорить о хаках и трюках, которые (зачем то) понадобились.
Справедливое замечание, хоть я и редко встречаю такие хаки в своей практике, но в целом согласен ибо сам пишу некоторые разъяснения, но опять же, обычно, в документации, за редким исключением, когда хак можно описать одним-двумя предложениями. А вот когда натыкаюсь на чужие хаки без комментариев или с бесполезными комментариями из разряда:
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
каждый раз вспоминаю быстрое извлечение обратного квадратного корня из квейка (собственно оттуда и пример).
Комментарии любят лгать. Кто-то потом обязательно изменит часть метода и конечно напрочь забьет на написание обновленного коммента в замен старому. Потом читаешь такие комменты, которые вообще не соответствуют реальности, и дуаешь: "Это ошибка и должно быть так как в комментарии, или комментарий устарел?".
Просто писать надо понятно. Называть метод и его параметры так, чтобы из одной только этой информации было понятно что этот метод делает, как он это делает, и зачем он вообще нужен. А уж если всё-таки придется заглянуть внутрь, то каждая строка метода должна быть самодокументируемой, что опять таки происходит благодаря осмысленным названиям переменных, функций, вызываемых в методе и тд.
Такой код сложно писать (ох как тяжко иногда придумать короткое, понятное и выразительное название методу), он сильно выростает в ширину, но не в высоту, и благодаря этому читается, как обычный текст. Язык программирования на то и язык, чтобы на нем писать, обрекая лексические конструкции в понятный и человеку и машине текст программы.
Вообще рекомендую прочитать книгу "Чистый код: создание, анализ" за авторством Роберта С. Мартина, там очень много полезного написано, в том числе и то что в статье перечислено.
Отправил. Странная у вас система. Ушло то оно ушло, а вот куда ушло что-то не нашел где посмотреть. На почту пришли 2 письма из жири, с номером ищью, но ссылки на него не видно. Оформлял тут vivaldi.com/bugreport
Скажите а что там с глобальным меню в линуксе, в частности в KDE? В хромиуме работает из коробки, при установленом libdbusmenu-glib. В electron-based программах типа того же VS Code или Atom также работает. В вивальди — нет. В макоси, понятное дело, оно поддерживается.
О чем я вообще
Вот это меню в верхней панели над окном:
Для программ которые прячут меню по дефолту (тот же хром) достаточно удобно что через dbus меню доступно прямо из панели и при этом программа выглядит также как задумывалась разработчиками.
Ну я бы не сказал что на GPD линукс проблемно работает. Он работает, достаточно стабильно, без каких либо явных косяков (Не знаю конечно, может убунту и правда проблемно работает. Не пользуюсь). Сна нет разве что, но с ssd он и не особо нужен. Сессии сохраняются, гибернацию тоже можно поднять. С интерфейсами особых проблем тоже нет. В целом я согласен что поддержка линукса на атоме оставляет желать лучшего, но там все не так уж и плохо и пользоваться можно достаточно комфортно.
Телефон (да, да, смартфон, если это так важно) — Nexus 5x. Пишу на сенсорной клаве Hacker's Keyboard в эмуляторе терминала Termux, используя полноценный Neovim.
Так неинтересно, я как-то с кнопочной Нокии через midpssh конфиг Апача в виме правил.
И почему сразу неинтересно? Недостаточно хардкорно? Так мне и не надо чтобы было хардкорно, я вимом пользуюсь потому что это самый удобный редактор на телефоне. В прочем я везде им пользуюсь, так как основной инструмент. Я помню в какой то реализации фара или mc для симбы писал на питоне на кнопочной нокии с т9. Было куда менее удобно чем сейчас в виме.
Да и тут вроде говорили что конфиг вима на планшете им неудобно на сенсорной клаве планшета править, а я по сути говорил о том что тыкаю в ещё более мелкие кнопочки на своих 5ти дюймах, и не то что просто правлю конфиг, а плагин пишу. Если Есть 5ти дюймовый телефон можете вот открыть на весь экран скриншот вима и посмотреть на размер кнопок и текста. Это не самый удобный вариант, конечно, но вполне можно продуктивно использовать:
Neovim на 5 дюймах
Более того, имея GPD Pocket могу сказать что печать в стоячем положежнии на нем лишь слегка превосходит таковую на планшете, так как размер клавы примерно такой же и так же надо большими пальцами печатать, но кнопки физичные и только за счет этого комфортнее. Вот сидя, печатать на планшете ужасно, но и сидеть скрючившись за 7ми дюймовым ноутом тоже не сахар.
Так как это делают ребята с демосцены. Они правда еще и в 64кб укладываются при этом, но это уже детали.
Спасибо за подробный ответ)
Насчет многого согласен, скажу лишь, что я воспринимаю Clojure как не еще одну реализацию LISP, которой он как раз не является, а скорее как самостоятельный язык в семействе Lisp, который вобрал в себя многие лучшие черты и при этом посторался сделать что-то своё, за что мне собственно и понравился.
Насчет ридер макросов в CL знаю что большинство их избегает так как они добавляют сложностей при взаимодействии с чужим кодом и это было основой причиной их отсутствия (ну и то, что у Рича были свои планы на всякие другие символы помимо скобочек).
Кстати про сигналы и систему условий - есть отличная библиотека farolero, реализующая все основные примитивы системы условий из CL. Безусловно, так как она не интегрирована в язык, а тем более в платформу, она не решает всех проблем JVM'ных эксепшенов, но сделана достаточно прозрачно чтобы её можно было интегрировать в проекты или использовать в библиотеках, даже если их пользователь ничего не знает о такой сигнальной модели (а если знает, то может пользоваться)
Не холивара ради, но по абзацу с Clojure у меня возникло несколько вопросов и уточнений.
Интересно было бы подробнее почитать про это. В сравнении с Common Lisp макросами я особых различий не заметил. В схемах, совершенно отдельная система макросов, поэтому с ней сравнивать наверное некорректно. Конечно, я не писал большого количества макросов на CL, так что могу чего-то не знать, но в Clojure (и некоторых других диалектах) с макросами у меня довольно большой опыт, и там макросы это те же самые квазиквоты с анквотами, с манипуляцией теми же самыми списками теми же самыми операциями, с единственным различием в резолвинге имён в квазиквотировании, т.к. он сделан немного иначе. В общем если есть какая-то конкретная литература по различиям, было бы интересно взглянуть!) Про отсутствие ридер макросов знаю, в Clojure их намерено не стали добавлять, но добавили tagged literals, что дает некоторые возмоности довольно близкие к ридер макросам. Не то же самое, конечно, но и цели такой не стояло.
Это не объектная модель и она отнюдь не уникальна. Это обыкновенный рантайм диспатч на основе значения, делается довольно легко в многих других языках. Насчет MOPа, да в Clojure этот протокол не используется, но Clojure вообще спроектирован иначе и не предполагает объектно-ориентированного подхода за пределами взаимодействия с его хост платформой, где MOP так же не используется. Вместо ООП упор делается на функциональную парадигму с чистыми функциями оперирующими неизменяемыми данными. Есть и диспатч на основе протоколов, что очень похоже на generic функции из CL, с той разницей что работает за счет реализации этого хост платформой.
Например? В Clojure есть всё, что есть в Java, соответственно всё основные типы данных доступные в хост платформе доступны и в Clojure. А сам язык предлагает персистентные варианты для всех основных коллекций - множества, векторы, односвязные списки, консы, ассоциативные словари и рекорды. И для всех свои литералы, что наоборот делает чтение кода более удобным и вовсе не является сахаром, так как такие литералы вычисляются на этапе чтения, а не на этапе исполнения. Т.е. `{:a 1 :b 2}` это не просто сахар для `(hash-map :a 1 :b 2)` - у них разные семанитики построения коллекции.
Спасибо за уточнение, но как это относится к комментарию на который я отвечал?)
Пролог, возможно, академичен, видел его всего пару раз во время учебы в университете, но более не прикасался. А вот насчет академичности лиспа не соглашусь)
Лисп не самый чистый и в общем-то не функциональный. Разные диалекты в этом плане могут отличаться, к примеру тот же Clojure делает большую функциональный стиль, а Common Lisp является мультипарадигмным языком, с общирными возможностями как в ООП так и в ФП парадигмах. Scheme больше полагается на функциональный стиль, но при этом обладает и императивными возможностями. А насчет академичности - обыкновенный код, как и на других языках, просто выглядит подругому и исторически имеет более удобные символьные вычисления, чем во многих других языках, так как проектировался с учетом такой потребности.
На самом деле нет. Вы можете писать на лиспе как и на любом другом императивном языке, тут это скорее зависит от идиом и основного фокуса конкретного диалекта.
Про итерацию - Clojure предлагает набор макросов и специальных форм для итерации:
loop,for,while, не говоря уже о более функциональныхmapилиreduce. Никакой рекурсии (за исключением,loop, но там это частный случай). Common Lisp имеет свой, довольно уникальный макросloop, который предлагает очень мощный DSL для выражения итерации любого вида.Подобное суждение скорее всего связано с тем, что вы видели, что в условном SICP всё решается через рекурсию, что на самом деле является довольно неплохой разминкой для ума, потому и использовано в книге, а в реальном коде рекурсия чаще встречается там, где она нужна, а не везде, где нужна итерация)
А что подразумевается под "интерпретируемостью" языка? SBCL компилит common lisp в нативный код:
Лисп это компилируемый язык, с единицей компиляции форма, а не файл, как в большинстве других языков. Безусловно, есть и чисто интерпретируемые диалекты, но в основном они либо компилятся в байткод и потом JIT компилит это в натив, либо сразу компилятся в натив.
Это врядли. Клава то на месте
не, ну если в блокноте читать, то понятное дело. Никто же не запрещает использовать Ctags, встроенные в IDE фичи, такие как поиск символа и так далее (мазохизм конечно никто не отменял).
Такой файл как правило читается с верху в низ — если функция что-то вызывает, то оно обязательно определено ниже, так что в целом за один проход от верха до низа можно проследить одну ветвь вполне легко, а уж тем более когда можно просто прыгнуть по тегу. Функции одного уровня определяются рядом, что тоже не вносит беспорядка в файл, так что, мне кажется, эти претензии не обоснованы, просто читать и разбираться в чужом всегда лень, а особенно без комментариев. При этом я понимаю что другой человек никак не может узнать степень выразительности кода, не начав его читать, и понимаю что никто не хочет тратить время на это. Но деньги то получают за работу, значит читать надо.
Что не так с одним уровнем вложенности я не понял, вы функции в глобальном пространстве видимости на разных уровнях вложенности пишете? Функции в любом случае будут на одном уровне вложенности (если конечно не определять их в классе, вложенном в класс, в класс, в класс).
Так что «сделано так, потому что другой способ, очевидный, является неправильным или неэффективным» вполне нормальная ситуация если всё написано так что можно понять без комментариев.
На самом деле иногда поражает на сколько люди ленятся читать код без комментариев, даже если он сам себя комментирует через имена его компонентов. Даешь человеку прочитать свой код, чтобы обсудить с ним какую-то его часть — он возвращается с упрёком, мол «где комментарии». Я отвечаю: «а зачем, тут же всё достаточно хорошо расписано, и всё есть в документации», на что обычно я получаю ответ в стиле: «код без комментариев не может быть понятным», хотя на деле это просто человеческая лень, ведь очень демотивирует когда ты видишь исходник на 3 тысячи строк кода (отформатированных по стандарту, определенному проектом, написаным с максимальной выразительностью, и с функциями, тела которых не превышают 20 строк, и обладают единственной ответственностью) без единого комментария. Хотя если приглядеться и начать таки читать, всё читается как текст. Сам читал такой код не раз, сам пишу такой же код на работе.
Как правило такие комментарии называются документацией. И пишутся соответственно стандарту доументирования, как заведено в языке, например тот же Javadoc, или как заведено стандартами в компании, если имеются. Обычных болтающихся комментариев в коде стоит избегать, так как обычно единственное что можно понять из комментария, так это то, что у автора не получается писать достаточно выразительный код.
Справедливое замечание, хоть я и редко встречаю такие хаки в своей практике, но в целом согласен ибо сам пишу некоторые разъяснения, но опять же, обычно, в документации, за редким исключением, когда хак можно описать одним-двумя предложениями. А вот когда натыкаюсь на чужие хаки без комментариев или с бесполезными комментариями из разряда:
каждый раз вспоминаю быстрое извлечение обратного квадратного корня из квейка (собственно оттуда и пример).
Комментарии любят лгать. Кто-то потом обязательно изменит часть метода и конечно напрочь забьет на написание обновленного коммента в замен старому. Потом читаешь такие комменты, которые вообще не соответствуют реальности, и дуаешь: "Это ошибка и должно быть так как в комментарии, или комментарий устарел?".
Просто писать надо понятно. Называть метод и его параметры так, чтобы из одной только этой информации было понятно что этот метод делает, как он это делает, и зачем он вообще нужен. А уж если всё-таки придется заглянуть внутрь, то каждая строка метода должна быть самодокументируемой, что опять таки происходит благодаря осмысленным названиям переменных, функций, вызываемых в методе и тд.
Такой код сложно писать (ох как тяжко иногда придумать короткое, понятное и выразительное название методу), он сильно выростает в ширину, но не в высоту, и благодаря этому читается, как обычный текст. Язык программирования на то и язык, чтобы на нем писать, обрекая лексические конструкции в понятный и человеку и машине текст программы.
Вообще рекомендую прочитать книгу "Чистый код: создание, анализ" за авторством Роберта С. Мартина, там очень много полезного написано, в том числе и то что в статье перечислено.
Была бы открытая вероятно было бы меньше дублей. Да и тут возможно меньше однотипных вопросов было кстати. Ладно, всё равно спасибо!
Спасибо.
Скажите а что там с глобальным меню в линуксе, в частности в KDE? В хромиуме работает из коробки, при установленом
libdbusmenu-glib. В electron-based программах типа того же VS Code или Atom также работает. В вивальди — нет. В макоси, понятное дело, оно поддерживается.Вот это меню в верхней панели над окном:
Для программ которые прячут меню по дефолту (тот же хром) достаточно удобно что через dbus меню доступно прямо из панели и при этом программа выглядит также как задумывалась разработчиками.
Ну я бы не сказал что на GPD линукс проблемно работает. Он работает, достаточно стабильно, без каких либо явных косяков (Не знаю конечно, может убунту и правда проблемно работает. Не пользуюсь). Сна нет разве что, но с ssd он и не особо нужен. Сессии сохраняются, гибернацию тоже можно поднять. С интерфейсами особых проблем тоже нет. В целом я согласен что поддержка линукса на атоме оставляет желать лучшего, но там все не так уж и плохо и пользоваться можно достаточно комфортно.
Телефон (да, да, смартфон, если это так важно) — Nexus 5x. Пишу на сенсорной клаве Hacker's Keyboard в эмуляторе терминала Termux, используя полноценный Neovim.
И почему сразу неинтересно? Недостаточно хардкорно? Так мне и не надо чтобы было хардкорно, я вимом пользуюсь потому что это самый удобный редактор на телефоне. В прочем я везде им пользуюсь, так как основной инструмент. Я помню в какой то реализации фара или mc для симбы писал на питоне на кнопочной нокии с т9. Было куда менее удобно чем сейчас в виме.
Да и тут вроде говорили что конфиг вима на планшете им неудобно на сенсорной клаве планшета править, а я по сути говорил о том что тыкаю в ещё более мелкие кнопочки на своих 5ти дюймах, и не то что просто правлю конфиг, а плагин пишу. Если Есть 5ти дюймовый телефон можете вот открыть на весь экран скриншот вима и посмотреть на размер кнопок и текста. Это не самый удобный вариант, конечно, но вполне можно продуктивно использовать:
Более того, имея GPD Pocket могу сказать что печать в стоячем положежнии на нем лишь слегка превосходит таковую на планшете, так как размер клавы примерно такой же и так же надо большими пальцами печатать, но кнопки физичные и только за счет этого комфортнее. Вот сидя, печатать на планшете ужасно, но и сидеть скрючившись за 7ми дюймовым ноутом тоже не сахар.