Интервью по языку Форт [Чарльз X. Мур] (pdf) читать постранично, страница - 12

впоследствии. Чем
изощрённее язык, тем более сложным, изобилующим ошибками и непригодным для
работы оказывается компилятор. Но простой компилятор для простого языка важный инструмент, хотя бы для документации. Редактор важнее компилятора.
Большое разнообразие редакторов позволяет каждому программисту выбрать какой-то
свой, что мешает успешному сотрудничеству. На этой основе процветает
производство доморощенных трансляторов из одного формата в другой. Другая беда
авторов компиляторов - стремление использовать все специальные символы,
имеющиеся на клавиатуре. Так клавиатуры никогда не станут проще и меньше. А
исходный код становится непостижимым. Но мастерство программиста не зависит от
этих инструментов. Он может быстро освоиться со всеми их недостатками и начать
писать хороший код.
Какой должна быть программная документация?
Чак: Я меньше придаю значения комментариям, чем это обычно принято.
Причины:
• Краткие комментарии обычно малопонятны. Приходится догадываться об их смысле.
• Пространные комментарии забивают код, в который помещены для пояснения.
Бывает трудно найти код, связанный с комментарием.
• Часто комментарии плохо написаны. Программисты обычно не отличаются
литературным талантом, особенно если английский не является для них родным
языком. Жаргон и грамматические ошибки часто делают комментарии нечитаемыми.
• Самое главное, комментарии часто оказываются неточными. Код может измениться,
а в комментариях это не отражается. Комментарии реже подвергаются критическому
анализу, чем код. Неточные комментарии чреваты большими неприятностями, чем их
отсутствие. Читателю приходится самому выяснять, где правда - в коде или в
комментариях. Комментарии часто бывают не по делу. Они должны пояснять цель
кода, а не сам код. Излагать код другими словами бесполезно. А если ещё и
неточно, то это просто вводит в заблуждение. Комментарии должны рассказывать,
для чего нужен этот код, что он должен делать и какими приёмами это
достигается.
В colorForth комментарии выделяются в затенённый блок. Это отделяет их от кода
и облегчает чтение. В то же время они легко доступны для чтения и обновления.
Кроме того, размер комментариев при этом ограничивается размерами кода.
Комментарии не заменяют настоящую документацию. Для каждого модуля кода нужно
написать поясняющий его текстовый документ. Он должен быть значительно
подробнее комментариев и давать грамотное и полное объяснение.
Конечно, это делается редко, и не всегда для этого есть возможности, да и
потерять документ, который отделён от кода, достаточно легко.
Цитирую по http://www.colorforth.com/HOPL.html
.
Патенты на программы и сейчас вызывают споры. Осталось ли прежним ваше мнение о
патентах?
Чак: Я никогда не
патентование мыслей.
может стать удачным
его распространение,

был сторонником патентов на программы. Это похоже на
А патентование языка/протокола особенно сомнительно. Язык
только тогда, когда им пользуются. Всё, что ограничивает
- глупость.

Вы считаете, что
распространение?

патентование

технологии

сдерживает

или

ограничивает

её

Чак: Торговать программами трудно, потому что их легко копировать. Компании
изовсех сил стараются защищать свои продукты, в результате чего они иногда
делаются непригодными для работы. Я считаю, что продавать нужно , а
программы отдавать бесплатно. Аппаратную часть трудно копировать, а с
разработанным для неё программным обеспечением она становится дороже.
Патенты - один из способов решения этих проблем. Они доказали свою
плодотворность для развития инноваций. Но необходимо соблюдать тонкую меру,
отвергая необоснованные патенты и поддерживая преемственность с прежними
методами/патентами. Кроме того, выдача патентов и их реализация сопряжены с
огромными
расходами.
Недавние
предложения
по
реформированию
патентного
законодательства несут в себе угрозу подавить личное изобретательство, отдав
предпочтение большим компаниям. Это стало бы трагедией.