Comments 14
Интересная теория.
А от языка зависят текстуры? Наверное, если взять красивый код на языке высокого уровня и тот же код на ассемблере, пусть и транслированный вручную, то ассемблерный м.б. не такой красивый? А псевдокод алгоритмов в публикациях? Или он обычно слишком короткий? Если взять доступные исходные коды Виртовских компиляторов, которые обычно довольно длинные, — там красивые текстуры?
А от языка зависят текстуры? Наверное, если взять красивый код на языке высокого уровня и тот же код на ассемблере, пусть и транслированный вручную, то ассемблерный м.б. не такой красивый? А псевдокод алгоритмов в публикациях? Или он обычно слишком короткий? Если взять доступные исходные коды Виртовских компиляторов, которые обычно довольно длинные, — там красивые текстуры?
Ч. Хоар в своей тьюринговской лекции сказал следующее: «Я пришел к заключению, что существуют два способа составления проекта программного обеспечения: один способ — сделать его таким простым, чтобы было очевидно, что недостатков нет, а другой — сделать его таким сложным, чтобы не было очевидных недостатков».
Визуальная структура программы имеет к этому прямое отношение. Мы бросаем взгляд на простой и регулярный код и сразу же убеждаемся, что понимаем, как он работает.
Вы достаточно абстрактно пишете о «текстурах кода», поэтому подразумевать под ними читатель может разное. Вот несколько примеров.
1. ASCII-графика. Есть программисты, которые не ленятся ставить лишние пробелы c целью создания более таблично-регулярной структуры исходного текста. Другие отказываются от такого подхода, справедливо указывая, что это мешает модификациям/факторизации кода. Конечно же, существуют и настоящие «картины кода»: dgopstein.github.io/articles/ioccc-ascii-art
2. Карты кода в текстовых редакторах, таких, как Sublime. Любопытно, что программист, привыкший пользоваться подобной картой, начинает делать в коде специальные пометки, видимые «с высоты птичьего полета».
3. Искусство, связанное с изображением древнего программного кода. Тут я ничего говорить не буду, просто посмотрите на эти картины: benfry.com/distellamap
4. Средства визуального программирования. Визуальное программирование до сих пор остается достаточно нишевой вещью. Возможно, это связано с тем, что применяется оно, в основном, на нижних уровнях иерархии программных конструкций (присваивания, условия и т.д.). Очень многое можно возложить на IDE: работа на уровне AST-представления, различные визуализации статических/динамических видов анализа (графы вызовов и т.д.). Помните Смолток и его многоколоночную визуализацию классов и методов? До сих пор, кажется, не было сделано в ООП-мире ничего более наглядного. В целом же необходимы мощные средства визуализации на уровне системы, в духе того, как это было в ТРИЗ: www.altshuller.ru/triz/zrts6.asp Ведутся ли разработки в этой области сейчас? Ведутся и ключевое имя здесь — Брет Виктор. Рано или поздно на хабре кто-нибудь опубликует перевод его нового проекта по Dynamicland, а пока я предлагаю ознакомиться с его работами на сайте worrydream.com
Визуальная структура программы имеет к этому прямое отношение. Мы бросаем взгляд на простой и регулярный код и сразу же убеждаемся, что понимаем, как он работает.
Вы достаточно абстрактно пишете о «текстурах кода», поэтому подразумевать под ними читатель может разное. Вот несколько примеров.
1. ASCII-графика. Есть программисты, которые не ленятся ставить лишние пробелы c целью создания более таблично-регулярной структуры исходного текста. Другие отказываются от такого подхода, справедливо указывая, что это мешает модификациям/факторизации кода. Конечно же, существуют и настоящие «картины кода»: dgopstein.github.io/articles/ioccc-ascii-art
2. Карты кода в текстовых редакторах, таких, как Sublime. Любопытно, что программист, привыкший пользоваться подобной картой, начинает делать в коде специальные пометки, видимые «с высоты птичьего полета».
3. Искусство, связанное с изображением древнего программного кода. Тут я ничего говорить не буду, просто посмотрите на эти картины: benfry.com/distellamap
4. Средства визуального программирования. Визуальное программирование до сих пор остается достаточно нишевой вещью. Возможно, это связано с тем, что применяется оно, в основном, на нижних уровнях иерархии программных конструкций (присваивания, условия и т.д.). Очень многое можно возложить на IDE: работа на уровне AST-представления, различные визуализации статических/динамических видов анализа (графы вызовов и т.д.). Помните Смолток и его многоколоночную визуализацию классов и методов? До сих пор, кажется, не было сделано в ООП-мире ничего более наглядного. В целом же необходимы мощные средства визуализации на уровне системы, в духе того, как это было в ТРИЗ: www.altshuller.ru/triz/zrts6.asp Ведутся ли разработки в этой области сейчас? Ведутся и ключевое имя здесь — Брет Виктор. Рано или поздно на хабре кто-нибудь опубликует перевод его нового проекта по Dynamicland, а пока я предлагаю ознакомиться с его работами на сайте worrydream.com
Ваш фундаментальный комментарий фактически является расширением этой статьи. Спасибо!
Процесс ручного программирования это фактически перевод неких мыслительных моделей в код. Я это называю материализацией идей. Эта материализация происходит тем быстрее, чем более высокоуровневый язык программирования используется. Визуальное программирование позволяет материализовывать идеи в модели визуальной а не текстовой природы.
Вроде логично предположить, что UML самый подходящий кандидат на эту роль. Но Executable UML пока не оправдывает надежд.
Процесс ручного программирования это фактически перевод неких мыслительных моделей в код. Я это называю материализацией идей. Эта материализация происходит тем быстрее, чем более высокоуровневый язык программирования используется. Визуальное программирование позволяет материализовывать идеи в модели визуальной а не текстовой природы.
Вроде логично предположить, что UML самый подходящий кандидат на эту роль. Но Executable UML пока не оправдывает надежд.
Да, но определение текстуры кода так и не дано. Что это такое?
Википедия даёт очень расплывчатое определение понятию визуальных текстур. Текстуры очень широко применяются в графических системах и компьютерных играх, но фудндаментального определения похоже пока (насколько мне известно) не найдено.
Задача распознования и классификации — одна из бурно развивающихся областей в Deep Learning: Deep neural networks for texture classification—A theoretical analysis.
Задача распознования и классификации — одна из бурно развивающихся областей в Deep Learning: Deep neural networks for texture classification—A theoretical analysis.
Многое давно покрыто styleguide'ами. Оставшееся — слишком случайно, чтобы говорить про гармоничность. Более того, меня очень удивляет статья без фактических примеров.
«Я увидел такой гармоничный код, что вам не покажу».
«Потом я много раз обращал внимание, что хорошие программисты пишут красивый код, который я вам не покажу».
Гипотеза: автор придумал идею в режиме «научно-фантастического допущения», а никаких реальных примеров не имеет.
«Я увидел такой гармоничный код, что вам не покажу».
«Потом я много раз обращал внимание, что хорошие программисты пишут красивый код, который я вам не покажу».
Гипотеза: автор придумал идею в режиме «научно-фантастического допущения», а никаких реальных примеров не имеет.
Читатель true-grue в предыдущем комментарии любезно взял на себя труд ответить Вам, наверное ещё до того, как Ваш комментарий появился. (Шутка).
Наверное можно было бы собрать примеры плывущего красивого кода в виде динамических GIF- файлов. Но если этот код коммерческий, это уже светло-серая зона с точки зрения соблюдения коммерческой тайны. Но мысль интересная.
Наверное можно было бы собрать примеры плывущего красивого кода в виде динамических GIF- файлов. Но если этот код коммерческий, это уже светло-серая зона с точки зрения соблюдения коммерческой тайны. Но мысль интересная.
Спасибо, отличная заметка!
Есть паттерны, SOLID, Complete Code и т.д. — это технические и относительно измеримые вещи.
Следующий метауровень — это когда код еще и красивый.
Напоминает известный тезис про красивые самолеты.
Позволю вставить свои 50 копеек:
Мне кажется автор говорит о том, что программисты с годами работы формируют свой уникальный стиль, подчерк при написании программ. Бывает, мельком взглянешь на код, сразу понимаешь и кто писал и почему так писал.
В моем мозгу, стиль, это набор практик оформления и построения кода, он влияет на то:
Стиль отражает не только скилл и опыт автора, но контекст решаемой задачи, а также образ мышления автора. Что приводит к необходимости работы над собственным стилем, адаптации под новые условия.
- Мне кажется что автор не о программном коде говорит, но о листинге кода. Код что пошел на обработку может значительно отличаться от своего представления в виде файла/ноды/чего_угодно
- Появление в коде текстур может быть вызвана ограничениями наложенные контекстом (фреймворк, архитектура, требования к задаче), а не по воле инженера
- — не согласен, что элегантность, как характеристика применимая к профессиональному коду. Элегантность субъективна
Мне кажется автор говорит о том, что программисты с годами работы формируют свой уникальный стиль, подчерк при написании программ. Бывает, мельком взглянешь на код, сразу понимаешь и кто писал и почему так писал.
В моем мозгу, стиль, это набор практик оформления и построения кода, он влияет на то:
- как программа будет прочитана
- как она будет работать
- и каким образом программа будет написана
Стиль отражает не только скилл и опыт автора, но контекст решаемой задачи, а также образ мышления автора. Что приводит к необходимости работы над собственным стилем, адаптации под новые условия.
Забыл добавить, что сформированный стиль позволяет сфокусироваться на решении предметной задачи, «автоматизировать» написание кода автором
В своем комментарии вы подчеркиваете влияние аспектов, которые я отношу у так называемого первому уровню структуризации. Мой тезис состоит в том, что на красоту кода большее влияние оказывают всё же структуры второго уровня. Но это моё эмпирическое наблюдение. Статистически это сложно подтвердить или опровергнуть.
Sign up to leave a comment.
Текстуры кода