Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 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 копеек:
Мне кажется автор говорит о том, что программисты с годами работы формируют свой уникальный стиль, подчерк при написании программ. Бывает, мельком взглянешь на код, сразу понимаешь и кто писал и почему так писал.
В моем мозгу, стиль, это набор практик оформления и построения кода, он влияет на то:
Стиль отражает не только скилл и опыт автора, но контекст решаемой задачи, а также образ мышления автора. Что приводит к необходимости работы над собственным стилем, адаптации под новые условия.
- Мне кажется что автор не о программном коде говорит, но о листинге кода. Код что пошел на обработку может значительно отличаться от своего представления в виде файла/ноды/чего_угодно
- Появление в коде текстур может быть вызвана ограничениями наложенные контекстом (фреймворк, архитектура, требования к задаче), а не по воле инженера
- — не согласен, что элегантность, как характеристика применимая к профессиональному коду. Элегантность субъективна
Мне кажется автор говорит о том, что программисты с годами работы формируют свой уникальный стиль, подчерк при написании программ. Бывает, мельком взглянешь на код, сразу понимаешь и кто писал и почему так писал.
В моем мозгу, стиль, это набор практик оформления и построения кода, он влияет на то:
- как программа будет прочитана
- как она будет работать
- и каким образом программа будет написана
Стиль отражает не только скилл и опыт автора, но контекст решаемой задачи, а также образ мышления автора. Что приводит к необходимости работы над собственным стилем, адаптации под новые условия.
Забыл добавить, что сформированный стиль позволяет сфокусироваться на решении предметной задачи, «автоматизировать» написание кода автором
В своем комментарии вы подчеркиваете влияние аспектов, которые я отношу у так называемого первому уровню структуризации. Мой тезис состоит в том, что на красоту кода большее влияние оказывают всё же структуры второго уровня. Но это моё эмпирическое наблюдение. Статистически это сложно подтвердить или опровергнуть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Текстуры кода