Наука — Школе |
|
«... я ничего обидного про свободное искусство открытого общества сказать не хочу, я к нему со всей душой. Поэтому извиняюсь, если нижеследующая метафора покажется обидной: |
|
|
'Функция всех структур — сохранять форму и служить опорой — требует, по определению, в известной мере пожертвовать свободой. Можно привести такой пример: червяк может согнуть свое тело в любом месте, где пожелает, в то время как мы, люди, можем совершать движения только в суставах. Но мы можем выпрямиться, встать на ноги - а червяк не может' (Конрад Лоренц). |
|
|
Зато червяк может саму способность встать на ноги объявить несерьезным делом и дорогой к рабству. ...» Владимир Шинкарев. «Митьковские
пляски. |
|
Особенность Оберона/Компонентного Паскаля — безусловный приоритет,
отдаваемый безопасности программ, в том числе защите как пользователей, так и
самого программиста от его же собственных случайных ошибок.
С этой целью из
языка и системы программирования просто-напросто исключен ряд средств и опций,
обычно имеющихся в «профессиональных» системах. Прежде всего
бросается в глаза:
Отсутствие оператора безусловного перехода GOTO.
Невозможность отключить проверки индексов на предмет выхода за границы массивов.
Отсутствие пошагового отладчика.
| Что может быть движущим мотивом для
широкого принятия такой дисциплины программирования? По-видимому, единственный механизм — через конкуренцию и конкурентные преимущества, которые она дает: ощутимый рост производительности программистских коллективов и повышение надежности программ (измеряемое не процентами, а разами). Главное свидетельство в пользу этого наблюдения — уже обсуждавшийся дрейф мировой индустрии программирования в направлении «стандартной парадигмы»:
Разумеется, обсуждаемая эволюция информационной индустрии коснулась прежде
всего более простой, внешней стороны дисциплины программирования, выраженной в
языковых средствах: научиться обходиться без GOTO
проще, чем научиться выводить алгоритм из постусловий, не полагаясь
на пошаговый
отладчик. |
Такая суровая дисциплина на первый взгляд кажется чрезмерной и ставит в тупик неподготовленного программиста.
Но на самом деле упомянутые выше средства (как и некоторые другие
из числа более новых; см., например,
Сообщение...) — всего лишь
тупики полувекового поиска наиболее эффективных технологий программирования.
Не всякое выдуманное за 50 лет средство полезно и эффективно, но понимание этого
в каждом конкретном случае приходит только с опытом.
Как правило создатели новых языков и систем программирования не могут не
продемонстрировать миру свою изощренность, включая в них новомодные прибамбасы.
А программисты не могут не доказать начальству и коллегам свое остроумие в
немедленном и всевозможном использовании новинок. Проблема в том, что все бывшие
новинки — раз уж они были включены в языки и системы программирования —
сохраняются в дальнейшем, даже если практика указывает на их порочность.
Сохраняются в силу необходимости обеспечивать совместимость с наследием прошлого:
программным наследием — горами уже написанных программ, от которых оказывается нелегко избавиться;
человеческим капиталом — заслуженными программистами, переучить которых также трудно, как и переписать старые программы.
Что касается GOTO и проч.,
то, с одной стороны, доказано, что отказ от упомянутых средств
не ограничивает создаваемые программы ни в плане алгоритмических
возможностей, ни в плане эффективности (скорее даже наоборот).
С другой стороны, такой отказ гарантирует, что получившаяся
программа будет иметь ряд чрезвычайно желательных свойств — четкую структуру,
верифицируемость и повышенную надежность. Ни один настоящий профессионал не
позволит себе пренебречь этими свойствами, даже если это потребует от него
определенной интеллектуальной дисциплины.
Главная проблема в том, что надлежащая дисциплина программирования не может возникнуть сама по себе: она требует целенаправленного обучения. (Попробуйте, например, освоить грамотный горнолыжный поворот — т.наз. угловинтовое движение: без квалифицированного тренера получится только поворот «броском зада». Разве грамотное программирование проще?)
Возвращаясь к списку средств, исключенных из Оберона/Компонентного Паскаля: более подробно каждое из них обсуждается на отдельных страничках. Там же содержатся и дальнейшие аргументы в пользу «сурового» дизайна средств программирования:
Почему нельзя отключать проверки на выход индексов за границы массивов
Почему порочно «наивное» программирование с пошаговым отладчиком
Наука — Школе |