Я нахожу просто удивительным невозмутимость, с которой мировое сообщество программистов восприняло этого монстра нотаций.
( Н.
Вирт ).
Представьте, что такой вид деятельности, как программирование, получил официальный статус.
"Искусство" .
Сегодня, работая над очередной прикладной программой или веб-порталом, программист не решает тех задач, которые он решил бы 5-10 лет назад. Очевидно? Факт? С повсеместным появлением доступных кроссплатформенных технологий, производительных вычислительных ресурсов и высокоскоростных электронных компьютерных сетей в профессиональных кругах наступило повсеместное расслабление.
Существует много литературы, посвященной проблеме оценки программного кода, различным методам сокращения и единицам измерения качества.
Хочу остановиться на почти незаметном, почти незаметном – красоте программного кода.
Задача
Мы легко можем выделить красивую вещь, обратить внимание на элегантную страницу в Интернете или оценить очарование нового спортивного автомобиля.Занимаясь групповой разработкой программного обеспечения, часто можно отличить «хорошего программиста» от «школьника-домохозяйки».
По каким критериям будет оцениваться красота программного кода? Можно ли попытаться систематизировать наши представления в этой области, несмотря на то, что большая их часть находится на стороне эмоций и чувств?
Тезис
Оценка красоты любого объекта, на мой взгляд, должна осуществляться систематически, а именно путем рассмотрения не только самого объекта и сравнения его с неким идеалом (оптимумом, как принято в теории оптимизации), но и рядом вещей, связанных с ним.Для программного кода можно выделить: проблема, которую нужно решить алгоритм решения средства и инструменты для реализации реализация (сам код) все возможные взаимодействия перечисленных элементов.
Рассмотрением первых двух аспектов в данной статье мы пренебрегаем, оставляя постановку задачи заказчикам и аналитикам, а выбор алгоритмов решения теоретикам, физикам-ядерщикам.
В свою очередь предлагаю сосредоточить основное внимание на рассмотрении и выборе средств и инструментов реализации любезно составленных для нас алгоритмов.
Вот тут-то и начинается веселье.
Допустим, нас никто не ограничивает в выборе любимого языка, IDE, библиотек, чего угодно, даже платформа будет настроена под наше ПО, но что дальше? Большинство разработчиков — узкие специалисты и мы им за это благодарны, но все же, приходя к решению той или иной задачи, нужно полагаться на остроту своих средств, а не на свои убеждения.
«Практически невозможно научить хорошему программированию студентов, ранее изучавших BASIC. Как потенциальные программисты, они пережили необратимую умственную деградацию».
- сказал Дийкстра и, наверное, был прав, не знаю, мне не приходилось преподавать программирование, но его фраза ярко раскрывает тему несоответствия языка и задачи обучения.
Да блин, надо ли уметь копать вилами, когда есть лопата? А если рядом бульдозер, зачем пачкать руки?
Причины, цели, концепции
Я верю, что все созданное имеет причину.Создавая такой сложный механизм, как язык программирования, авторы, будь то люди или роботы, опираются на причины, побудившие их взяться за это весьма трудоемкое дело.
Отсюда задача разработчика, на мой взгляд, уметь оценивать существующие продукты, понимать причины их создания и осознавать свои задачи и сопоставлять эти самые задачи с причинами, ради которых авторы языков сделали свои события.
Нет и не будет универсального языка программирования, нет и не будет универсального программиста.
Красота реализации кода, как и в любом языке (я имею в виду естественные), достигается постоянной практикой; никакого секрета здесь нет. Искусство состоит в том, чтобы написать картину маслом кистью, уметь это сделать и, главное, правильно оформить ее в подходящем месте.
Представьте себе шикарную клумбу с живыми цветами, правда, красиво? А если эта клумба расположена в неблагополучном районе где-нибудь на окраине мегаполиса, рабочего квартала, темноты, грязи, разбитых дорог и пьяных бомжей? Выходит, что программирование (в узком смысле — кодирование) — это ни в коем случае не самоцель.
Рассматривая решение проблемы как комплекс, можно увидеть красоту или ее отсутствие.
Заключение
Мне кажется, люди должны понимать, что красота элемента никогда не может сравниться с красотой композиции, и только системный анализ может хоть немного приблизить нас к объективности.Никлаус Вирт, обсуждая конструкции языка Си, решил проблему парсера; вряд ли автор песен оценит созданный самим Виртом Паскаль (почитаемый мной как лучший язык обучения).
Теги: #программирование #языки программирования #философия #Чулан
-
Нейман, Джон Фон
19 Oct, 24 -
Использование Раскадровки
19 Oct, 24 -
Будущее Уже Здесь
19 Oct, 24
