![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rЭтот пост скопирован с поста в LJ вручную из-за проблем с автоматическим переносом.
На одном местном форуме очередной гений жаловался на судьбу. Он сделал великолепную программу, а начальство требует, чтобы в ней могли разбираться другие люди. Не гениальные.
Наши специалисты сочувствовали и давали советы. От независимой профессиональной экспертизы и до жалоб в профсоюз. Масса предложений. Полный спектр. И тут являюсь я со своим канделябром...
Короче, опять на меня обиделись смертельно и непримиримо.
Я всегда достаточно скептически относился к своим умственным способностям. Ну, диплом за олимпиаду. Но кто-то занял призовые места или вышел на общесоюзную. Ну, почитал учебник, ответил, получил пять. Но кто-то на самом деле выучил, понял внутренние связи и знает не для галочки, а в полном объёме...
То, что в мире что-то не так, первый раз понял, когда получил на втором (или третьем) курсе экзамен по физике автоматом. За один вопрос. Заданный на лекции. Просто так, в качестве уточнения.
Как сказал лектор, это был единственный раз в его преподавательской деятельности, когда ему пришлось думать и искать ответ в литературе.
Всё это вызвало глубокий когнитивный диссонанс. Для меня вопрос был естественным, напрямую вытекающим из представленной модели. Чуть ли не обязательным для понимания и применения. Но никого, включая лектора, доктора наук и достаточно приличного учёного, это просто не интересовало.
С тех пор я начал замечать, что у меня голова работает по-другому. В той же ситуации я задаю другие вопросы. И из тех же фактов и закономерностей я делаю другие выводы.
Не то, чтобы похожих людей я не встречал. Просто их было ничтожно мало.
Это ни в коем случае не ум. Скорее, структура мышления и подход к решению проблем.
Возраст и опыт сейчас как раз такие, что пора учить молодёжь жизни, писать книжки, выступать с проповедями...
Но то, что люди хотят услышать, мне не интересно. Интересное мне находится как раз в моём кривом мире, по которому провести обычных нормальных специалистов если и можно, то требует неимоверных усилий. Потому как надо не только построить модель в их терминах, не только доказать зависимости в их системе понятий, но и просто объяснить, почему это важно.
Я, в принципе, могу начать проповедовать о том, что agile спасёт индустрию. Могу выступать с проповедями о том, что это диверсия, призванная индустрию погубить. Причём, и то и другое будет в моём исполнении одинаково эффективно, хотя за второе денег будет меньше, ибо не в моде. Но мне это не интересно. Потому что правы и те и другие. Потому что начинать надо с определения аксиом. С выяснения того, что же такое agile и почему разные люди под этим разное понимают. И куда делись те книжки, которые читали те проповедники, которые умные мысли выдают за свои свежие озарения.
Но это не то, чтобы не принесёт денег, просто никому не интересно. Все, даже самые разумные, хотят разделить мир на «мы» и «они».
Мы можем написать крутой софт, а они делают лажу. Мы используем передовые методы, а они застряли в технологиях прошлого века. Мы думаем, они копируют. Мы взвешенно подходим к проблеме, они пытаются взять наскоком. У нас (случайно) получилось (или мы решили, что получилось), они должны делать так же.
ИТ сообщество безнадёжно больно звездизмом.
Нет, я не вижу ничего плохого в том, чтобы в споре или просто так гнать пургу и использовать религиозные аргументы. Но люди-то играют всерьёз...
Закончу наездом на функциональное программирование.
Ну да, прикольно. В тех областях, для которых применение оправдано и выгодно, даже правильно. Как телефонный Эрланг на обработке огромного количества мелких параллельных запросов. Математика - тоже понятно. Но вот с остальным у меня большие сомнения.
Мои критерии слишком отличаются от правильных. И по многим из них функциональщина не проходит. Минимум, в том виде, в каком её дают проповедники.
От языка, концепции и стиля мне нужны графичность, понятность, стабильность и лёгкость загрузки контекста. Всё остальное вторично.
Графичность позволяет понять программу, не читая.
Фигня, конечно, если у нас презентация для новых адептов. Или книжка, где мы на пол странички примера используем главу для построчного объяснения. И критически важно, если вдруг мы вломились в чужой код за ошибкой.
Разбивка по колонкам, баланс белого и чёрного, правильное использование пустого пространства, акценты, общая гармоничность - всё это определяет, очутились ли мы на городском перекрёстке с ясной разметкой и хорошо заметными указателями, или посреди дремучего леса, прекрасного и величественного, но проходимого только проползанием или перелезанием с надеждой не потерять направление, не сорваться с обрыва и не застрять в буреломе.
Понятность - критерий очень скользкий.
За неограниченное время человек неограниченных возможностей разберётся в любом коде. Вот только основной дефицит отрасли - время и мозги. Их вечно не хватает. И не всегда это относится к тем, которые «они».
Писать просто очень сложно. Даже на нормальном языке. Большинство писанины, производимой инженерами или считающими себя таковыми, совершенно не читабельны.
Скажем, для нормального языка есть тул, определяющий Grade Reading Level. Можно взять текст, прогнать, после чего выяснить, совпадает ли сложность с оптимальным уровнем старшеклассника, или любой человек, не защитивший докторскую по филологии, спасует уже на втором абзаце.
Критериев для программирования просто нет. И не потому, что они не нужны. Просто среди «специалистов» действует правило «мне кажется, что я понимаю, а остальное меня не волнует».
Я считаю, что в идеале код должен читаться и пониматься человеком не знающим ни конкретного языка, ни программирования вообще. Естественно, он не должен понимать, как именно это делается, но ему должно быть ясно, что происходит и зачем.
Именно эта информация стандартными программистами просто выбрасывается. Чтобы восстановить мета-уровень, надо влезть в код, построчно понять происходящее, после чего попытаться восстановить контекст.
Давным давно, когда перед Гостиным собирался народ и спорил о политике, на заявление о том, что в экономике может понимать любая кухарка, я просто открыл учебник и показал формулу на пол страницы. После чего оппонент согласился, что кухарка может понимать не всё. В том числе, и экономические зависимости.
То, что я вижу у функциональных проповедников, великолепно подходит для подобных целей. И очень эффективно позволяет отделить быдло от небожителей. Это очень хорошо для звездизма, но совершенно не работает в реальной индустрии.
Стабильность.
Тут всё просто. Когда я вижу очередной шедевр функциональных изысков, я вспоминаю, как на семинаре по функциональному анализу вся группа пол часа выискивала ошибки в написанном на доске.
Преподаватель просто использовал посреди формул прописные эпсилон и кси, не всегда правильно и ясно выписывая хвостики. Или кое-где, при переносе из одного места в другое, загогулинки не заметил.
Уже одна голая скобка в неудачных условиях может привести к нескольким дням жестокого дебаггинга. Простое, но не удачное изменение может породить хитрые ошибки в другом конце программы. Мелкие улучшения поклонника Шивы могут разрушить программу «Hello world!»
Страшно подумать, что произойдёт, когда функциональщина покинет стены башни из слоновой кости.
И я совершенно не представляю, как в эти изящные математические конструкции впишутся имена, типа next_from_cur_verts_hash. Ладно, мои алгоритмы именования не самые удачные и я не очень крут в этом вопросе. Наверно, можно сделать лучше и изящнее. Но это та работа, которая может поглотить любые ресурсы. Кто выбирал имена для детей, меня поймёт.
Лёгкость загрузки контекста для меня важна из-за характера моей работы.
В любой момент я могу получить высокоприоритетное прерывание. И мне надо за минуту - полторы зафиксировать контекст, состояние и направление движения. Чтобы открыв проект на том же месте через час, через день или через год продолжить делать то, что должно быть сделано.
Для этого мне пришлось изменить принципы построения кода и стиль форматирования на отличающийся от того, что приводят в учебниках, а потом повторяют на практике. Не то, чтобы подобное нельзя было повторить для красивых функциональных языков. Но, смотря на код, приводимый в качестве образца для поклонения, мне приходится констатировать, что мы движемся в разных направлениях.
Естественно, всё вышесказанное просто размышления ни о чём. Сотни и сотни адептов функциональной разновидности серебряных пуль навалят горы аргументов, которые, хоть и сводятся в конечном итоге к банальному «я тащусь», но совершенно непробиваемы в любом споре.
Звездизм не победим. Впрочем, я с ним и не собирался бороться.
Если будет время, подниму октябрьский черновичок и допишу грустную историю про стрелочки и прямоугольнички, после чего отложу тему.
На одном местном форуме очередной гений жаловался на судьбу. Он сделал великолепную программу, а начальство требует, чтобы в ней могли разбираться другие люди. Не гениальные.
Наши специалисты сочувствовали и давали советы. От независимой профессиональной экспертизы и до жалоб в профсоюз. Масса предложений. Полный спектр. И тут являюсь я со своим канделябром...
Короче, опять на меня обиделись смертельно и непримиримо.
Про звездизм и функциональное программирование
Я всегда достаточно скептически относился к своим умственным способностям. Ну, диплом за олимпиаду. Но кто-то занял призовые места или вышел на общесоюзную. Ну, почитал учебник, ответил, получил пять. Но кто-то на самом деле выучил, понял внутренние связи и знает не для галочки, а в полном объёме...То, что в мире что-то не так, первый раз понял, когда получил на втором (или третьем) курсе экзамен по физике автоматом. За один вопрос. Заданный на лекции. Просто так, в качестве уточнения.
Как сказал лектор, это был единственный раз в его преподавательской деятельности, когда ему пришлось думать и искать ответ в литературе.
Всё это вызвало глубокий когнитивный диссонанс. Для меня вопрос был естественным, напрямую вытекающим из представленной модели. Чуть ли не обязательным для понимания и применения. Но никого, включая лектора, доктора наук и достаточно приличного учёного, это просто не интересовало.
С тех пор я начал замечать, что у меня голова работает по-другому. В той же ситуации я задаю другие вопросы. И из тех же фактов и закономерностей я делаю другие выводы.
Не то, чтобы похожих людей я не встречал. Просто их было ничтожно мало.
Это ни в коем случае не ум. Скорее, структура мышления и подход к решению проблем.
Возраст и опыт сейчас как раз такие, что пора учить молодёжь жизни, писать книжки, выступать с проповедями...
Но то, что люди хотят услышать, мне не интересно. Интересное мне находится как раз в моём кривом мире, по которому провести обычных нормальных специалистов если и можно, то требует неимоверных усилий. Потому как надо не только построить модель в их терминах, не только доказать зависимости в их системе понятий, но и просто объяснить, почему это важно.
Я, в принципе, могу начать проповедовать о том, что agile спасёт индустрию. Могу выступать с проповедями о том, что это диверсия, призванная индустрию погубить. Причём, и то и другое будет в моём исполнении одинаково эффективно, хотя за второе денег будет меньше, ибо не в моде. Но мне это не интересно. Потому что правы и те и другие. Потому что начинать надо с определения аксиом. С выяснения того, что же такое agile и почему разные люди под этим разное понимают. И куда делись те книжки, которые читали те проповедники, которые умные мысли выдают за свои свежие озарения.
Но это не то, чтобы не принесёт денег, просто никому не интересно. Все, даже самые разумные, хотят разделить мир на «мы» и «они».
Мы можем написать крутой софт, а они делают лажу. Мы используем передовые методы, а они застряли в технологиях прошлого века. Мы думаем, они копируют. Мы взвешенно подходим к проблеме, они пытаются взять наскоком. У нас (случайно) получилось (или мы решили, что получилось), они должны делать так же.
ИТ сообщество безнадёжно больно звездизмом.
Нет, я не вижу ничего плохого в том, чтобы в споре или просто так гнать пургу и использовать религиозные аргументы. Но люди-то играют всерьёз...
Закончу наездом на функциональное программирование.
Ну да, прикольно. В тех областях, для которых применение оправдано и выгодно, даже правильно. Как телефонный Эрланг на обработке огромного количества мелких параллельных запросов. Математика - тоже понятно. Но вот с остальным у меня большие сомнения.
Мои критерии слишком отличаются от правильных. И по многим из них функциональщина не проходит. Минимум, в том виде, в каком её дают проповедники.
От языка, концепции и стиля мне нужны графичность, понятность, стабильность и лёгкость загрузки контекста. Всё остальное вторично.
Графичность позволяет понять программу, не читая.
Фигня, конечно, если у нас презентация для новых адептов. Или книжка, где мы на пол странички примера используем главу для построчного объяснения. И критически важно, если вдруг мы вломились в чужой код за ошибкой.
Разбивка по колонкам, баланс белого и чёрного, правильное использование пустого пространства, акценты, общая гармоничность - всё это определяет, очутились ли мы на городском перекрёстке с ясной разметкой и хорошо заметными указателями, или посреди дремучего леса, прекрасного и величественного, но проходимого только проползанием или перелезанием с надеждой не потерять направление, не сорваться с обрыва и не застрять в буреломе.
Понятность - критерий очень скользкий.
За неограниченное время человек неограниченных возможностей разберётся в любом коде. Вот только основной дефицит отрасли - время и мозги. Их вечно не хватает. И не всегда это относится к тем, которые «они».
Писать просто очень сложно. Даже на нормальном языке. Большинство писанины, производимой инженерами или считающими себя таковыми, совершенно не читабельны.
Скажем, для нормального языка есть тул, определяющий Grade Reading Level. Можно взять текст, прогнать, после чего выяснить, совпадает ли сложность с оптимальным уровнем старшеклассника, или любой человек, не защитивший докторскую по филологии, спасует уже на втором абзаце.
Критериев для программирования просто нет. И не потому, что они не нужны. Просто среди «специалистов» действует правило «мне кажется, что я понимаю, а остальное меня не волнует».
Я считаю, что в идеале код должен читаться и пониматься человеком не знающим ни конкретного языка, ни программирования вообще. Естественно, он не должен понимать, как именно это делается, но ему должно быть ясно, что происходит и зачем.
Именно эта информация стандартными программистами просто выбрасывается. Чтобы восстановить мета-уровень, надо влезть в код, построчно понять происходящее, после чего попытаться восстановить контекст.
Давным давно, когда перед Гостиным собирался народ и спорил о политике, на заявление о том, что в экономике может понимать любая кухарка, я просто открыл учебник и показал формулу на пол страницы. После чего оппонент согласился, что кухарка может понимать не всё. В том числе, и экономические зависимости.
То, что я вижу у функциональных проповедников, великолепно подходит для подобных целей. И очень эффективно позволяет отделить быдло от небожителей. Это очень хорошо для звездизма, но совершенно не работает в реальной индустрии.
Стабильность.
Тут всё просто. Когда я вижу очередной шедевр функциональных изысков, я вспоминаю, как на семинаре по функциональному анализу вся группа пол часа выискивала ошибки в написанном на доске.
Преподаватель просто использовал посреди формул прописные эпсилон и кси, не всегда правильно и ясно выписывая хвостики. Или кое-где, при переносе из одного места в другое, загогулинки не заметил.
Уже одна голая скобка в неудачных условиях может привести к нескольким дням жестокого дебаггинга. Простое, но не удачное изменение может породить хитрые ошибки в другом конце программы. Мелкие улучшения поклонника Шивы могут разрушить программу «Hello world!»
Страшно подумать, что произойдёт, когда функциональщина покинет стены башни из слоновой кости.
И я совершенно не представляю, как в эти изящные математические конструкции впишутся имена, типа next_from_cur_verts_hash. Ладно, мои алгоритмы именования не самые удачные и я не очень крут в этом вопросе. Наверно, можно сделать лучше и изящнее. Но это та работа, которая может поглотить любые ресурсы. Кто выбирал имена для детей, меня поймёт.
Лёгкость загрузки контекста для меня важна из-за характера моей работы.
В любой момент я могу получить высокоприоритетное прерывание. И мне надо за минуту - полторы зафиксировать контекст, состояние и направление движения. Чтобы открыв проект на том же месте через час, через день или через год продолжить делать то, что должно быть сделано.
Для этого мне пришлось изменить принципы построения кода и стиль форматирования на отличающийся от того, что приводят в учебниках, а потом повторяют на практике. Не то, чтобы подобное нельзя было повторить для красивых функциональных языков. Но, смотря на код, приводимый в качестве образца для поклонения, мне приходится констатировать, что мы движемся в разных направлениях.
Естественно, всё вышесказанное просто размышления ни о чём. Сотни и сотни адептов функциональной разновидности серебряных пуль навалят горы аргументов, которые, хоть и сводятся в конечном итоге к банальному «я тащусь», но совершенно непробиваемы в любом споре.
Звездизм не победим. Впрочем, я с ним и не собирался бороться.
Если будет время, подниму октябрьский черновичок и допишу грустную историю про стрелочки и прямоугольнички, после чего отложу тему.
Copyright
(CC BY-NC-ND 3.0) vit_r, 2012
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Перевод на английский запрещён, потому как нефиг портить хорошую вещь.
(frozen) Важные цитыты из комментариев
Date: 2018-12-29 09:20 pm (UTC)...
Задача на одну страницу - это не задача. Да и пузырьковую сортировку нужно делать разные что студентам по заданию.
...
Любое выражение, требующее чтения задом наперёд, чревато.
И никому не нужно объяснять, зачем. Нужно просто, чтоб люди поняли, как оно работает.
Это, пардон, определение религиозного культа.
...
Насчёт же объяснений вспоминается Резерфорд: "Если учёный не может объяснить уборщице, которая убирается у него в лаборатории, смысл своей работы, то он сам не понимает, что он делает."
Насчёт "как" - это во многих случаев ключевое. У нас есть софт под отель на сто комнат. Когда программа работает с триста пятой, вылезают ошибки. Нужно зайти, поменять один параметр и разрешить подниматься максимуму до тысячи. Что там происходит ещё - знать некогда. Да и не надо до того момента, когда задача изменится настолько, что надо будет всё переписывать.
...
Бездумное исправление ошибок приводит к тому, что программа становится плохо поддерживаемой и вместо того, чтобы заниматься новыми проектами, приходится отвлекаться на починку старых.
В идеальном случае всё, что может меняться, выносится в качестве параметров в удобной для пользователя форме.
Когда сами алгоритмы убегают, тут уж делать нечего, приходится лезть внутрь. Но в большинстве случаев для корпоративного софта нужны только мелкие доводки.
...
Современно программирование во многом завязано на проектный принцип: одни делают техзадание, другие рисуют диаграммки с управлением и загрузкой персонала, третьи пишут код, четвёртые это тестируют, пятые собирают...
Результат всех волнует только от и до.
Основная проблема с функциональной парадигмой - её мелкомасштабность. Очень просто понять, что происходит в каждом конкретном случае, но для объяснения общей картины надо из функционального мировоззрения выйти.
Что, как бы, является предательством основ и отходом от устоев.
...
по крайней мере в случае исполнения юнит-тестов из IDE.
методом подключения к внешнему процессу из sbt я не пробовал, анальным сексом я занимаюсь только на работе, а не на бесплатных курсах имени мартина одерски.
Возможно, если бы мне кто дал этим заняться, я бы придумал способ выводить диаграммы потоков данных для отладки (вместо непригодных стек-трейсов и пошаговой отладки), но мне надо прикладной софт писать, а не мир улучшать :)
Насколько понимаю, это тестируется заглушками и сравнением записанных call sequence diagram с заданными. В телефонии всё просто, там CSD - часть стандарта.
...
Я уже много лет не заглядываю в дебаггер, обходясь функциональными тестами и автоматическим выводом диагностики. И всё плотно покрыто проверками в assert,
Правда, мне скорость работы пофиг и важна только правильность.
Смотря на каком этапе проверять.
Если мы обрезаем небольшую подсистему и / или небольшой участок функциональности и проверяем только их, количество вариантов ограничено. Если собрать что-то большое и начать проверять в этот момент, то тут, действительно, получится грустно.
Потом, у меня на входных данных и инвариантах стоят assert. В результате, если одна часть системы ведёт себя неожиданным образом, другая сразу же фиксирует ошибку. (Или же правильное поведение, которое ошибочно было предсказано не так, каким должно быть).
Если по ошибке сразу не видно, в чём причина, то в этом месте вырезается заглушками подсистема или участок функциональности, и см. выше.
...
Канделябром.
Грубо говоря, все программы написаны на английском. С небольшими или большими извращениями.
Я видел код на незнакомом языке, который не составляло труда понять. Гораздо чаще, коненчо, на знакомом языке попадается какой-то мутный бред.
Насчёт же стилей, есть вполне чёткие критерии объективной проверки. Пока результаты (для определённых задач на заданной области применения) меня устраивают, мнение "сторонних наблюдателей" меня не волнуют.
Когда мне вручают документ Coding Standard, делаю как написано. Если там совсем бред, сначала решаю задачу в нормальном стиле, а потом оформляю рюшечки под требования клиента.
...
код - это полное описание для человека, включая комментарии. Во некоторых случаях читать можно просто заголовки, не заглядывая внутрь.
...
Я знаю, почему и зачем я что-то делаю. Причём, знаю не теоретически, а на основе практических полевых испытаний. В некоторых случаях просто переформатирование гениального кода и переназывание всего человеческими именами убирало те заковыристые ошибки, с которыми авторы долго и упорно бодались.
Я видел очень много примеров, очень много стратегий и вполне достаточно стандартов на кодирование, чтобы сделать определённые выводы. То есть, разговор совсем не про уровень "нравится - не нравится" и аргументы "а вот у меня" не принимаются тоже. Потому как их я видел вагон и маленькую тележку. Мало что из этого выдерживало проверку практикой.
В сложном тексте запутаться просто. В ясном и чётком можно только допустить ляпы, но не заплутать.
И это не говорит, что клиенту я буду делать код, который поймёт любой идиот. Не потому, что не могу, а потому что такая задача не стоит, а у меня другие цели. И я знаю, что на банальном английском половина высоких программистов напишет такую муть, что будут не в состоянии сами в ней разобраться через пол года. Просто потому, что не задумывались о том, как и для чего надо писать. Да и не учил их никто.
Ни одной книги на такую тему.
Книг дофига. От того, как писать романы до банальных пособий по business writing.
Базовые принципы применимы ко всему: от именования переменных до техзадания и документации. Другое дело, народ считает, что не царское это дело.
...
На любом языке можно писать понятно и красиво. Разница только в том, сколько усилий надо на это затратить.
Также на любом языке можно писать элитарненько. Чтобы понимание было возможным только после вложения нетривиальных усилий.
...
Это всё тулам ортогонально.
Художник может нарисовать что-то карандашом, а может взять фотошоп. И в том и другом случае результат будет соразмерен умению и таланту, а не мощи технических средств.
Плюс тулы снижают гибкость. А может быть так, что под каждую новую задачу надо вносить изменения.
На больших проектах, конечно, делают инфраструктуру. В основном это касается стабильности. Всё остальное слишком гуманитарные факторы.
...
Получается что субъективизм "творчества" таким образом стоит на пути прогресса.
А с другой стороны, подход как к "искусству" постоянно размывается увеличением области применения и количества участников.
:(
Это не субъективизм. Программирование - гуманитарная дисциплина и к ней применим научный подход. В частности можно сделать правильные измерения и эксперименты.
Другое дело, всё это стоит диких денег, если делать не на студентах (которые докажут любую идею профессора).
Плюс это никому не нужно. Одно дело, когда какие-то мрачные личности бурчат под нос, что две трети так называемых инженеров-разработчиков надо гнать поганой метлой, и совсем другое, когда любому дураку это видно из статистики по результатам чистого научного исследования.
...
Нет "более промышленных" способов думать. Насчёт же производительности кодирования и построения программ, прогресс идёт достаточно быстро. Но в этом деле широкий монитор даёт больше плюс, чем супер-новый тул.
Насчёт нужности - в этом направлении было много хороших идей и начинаний. Все они мирно завяли. Потому что людям нужны волшебные средства, позволяющие одной кнопкой переложить процесс думанья на машину, и совершенно не нужны те, которые выясняют траблы в бортовом компьютере между ушами.
...
Промышленных способов думать нет и не будет. Это вытекает просто из строения и принципов работы мозга.
Есть методы облегчить процесс анализа информации, есть методы разогреть креативность, есть методы проанализировать пути решения проблем и выбрать оптимальные или исправить в имеющихся ошибки и т.п.. Впрочем, это совсем другая тема, которую тут копать не буду.
no subject
Date: 2018-12-30 05:52 am (UTC)Потому что я обеими руками за читабельность, но бывают же еще и люди, которые просто с языком не знакомы.
no subject
Date: 2018-12-30 08:04 am (UTC)no subject
Date: 2018-12-30 11:45 am (UTC)> Для этого мне пришлось изменить принципы построения кода и стиль форматирования на отличающийся от того, что приводят в учебниках, а потом повторяют на практике. Не
> то, чтобы подобное нельзя было повторить для красивых функциональных языков. Но, смотря на код, приводимый в качестве образца для поклонения, мне приходится
> констатировать, что мы движемся в разных направлениях.
А конкретный пример такого _стиля и форматирования_ можно?
no subject
Date: 2018-12-30 01:14 pm (UTC)