Главная страница проекта ИНФОРМАТИКА-21

Наука Школе

О дисциплине программирования.
Почему в Обероне/Компонентном Паскале ограничена «свобода творчества» программиста

«... я ничего обидного про свободное искусство открытого общества сказать не хочу, я к нему со всей душой. Поэтому извиняюсь, если нижеследующая метафора покажется обидной:

 

'Функция всех структур — сохранять форму и служить опорой — требует, по определению, в известной мере пожертвовать свободой. Можно привести такой пример: червяк может согнуть свое тело в любом месте, где пожелает, в то время как мы, люди, можем совершать движения только в суставах. Но мы можем выпрямиться, встать на ноги - а червяк не может' (Конрад Лоренц).

Зато червяк может саму способность встать на ноги объявить несерьезным делом и дорогой к рабству. ...»

Владимир Шинкарев. «Митьковские пляски.
Краткое руководство для хореографических кружков художественной самодеятельности»
- СПб.: Красный матрос, 2005, 90 с. ISBN 5-7187-0529-1

Особенность Оберона/Компонентного Паскаля — безусловный приоритет, отдаваемый безопасности программ, в том числе защите как пользователей, так и самого программиста от его же собственных случайных ошибок.
С этой целью из языка и системы программирования просто-напросто исключен ряд средств и опций, обычно имеющихся в «профессиональных» системах. Прежде всего бросается в глаза:

Что может быть движущим мотивом для широкого принятия такой дисциплины программирования?
По-видимому, единственный механизм — через конкуренцию и конкурентные преимущества, которые она дает: ощутимый рост производительности программистских коллективов и повышение надежности программ (измеряемое
не процентами, а разами).
Главное свидетельство в пользу этого наблюдения — уже обсуждавшийся дрейф мировой индустрии программирования в направлении «стандартной парадигмы»:
  • Сначала корпорация Sun для борьбы с гегемонией Microsoft прибегла к передовым идеям, использовав их (пусть не полностью) в Яве.
  • Технические достоинства этих идей (как бы неполно ни были они реализованы в Яве, являющейся в этом отношении лишь тенью Оберона) при мощной маркетинговой поддержке обеспечили им успех у массы программистов.
  • Этот успех заставил Майкрософт обратить на них серьезнейшее внимание и предложить их альтернативную, причем более систематическую реализацию (система .NET и язык C#).
  • Анализируя эту битву титанов и ссылаясь на нее, мы можем отделить определяющие технические идеи от мифологии, с тем чтобы положить эти идеи в очищенном виде в основу серьезного обучения программированию.

Разумеется, обсуждаемая эволюция информационной индустрии коснулась прежде всего более простой, внешней стороны дисциплины программирования, выраженной в языковых средствах: научиться обходиться без GOTO проще, чем научиться выводить алгоритм из постусловий, не полагаясь на пошаговый отладчик.
Глубинные аспекты дисциплины программировария требуют освоения логического аппарата и, соответственно, более серьезных усилий.

Такая суровая дисциплина на первый взгляд кажется чрезмерной и ставит в тупик неподготовленного программиста. Но на самом деле упомянутые выше средства (как и некоторые другие из числа более новых; см., например, Сообщение...) — всего лишь тупики полувекового поиска наиболее эффективных технологий программирования.
Не всякое выдуманное за 50 лет средство полезно и эффективно, но понимание этого в каждом конкретном случае приходит только с опытом.
Как правило создатели новых языков и систем программирования не могут не продемонстрировать миру свою изощренность, включая в них новомодные прибамбасы. А программисты не могут не доказать начальству и коллегам свое остроумие в немедленном и всевозможном использовании новинок. Проблема в том, что все бывшие новинки — раз уж они были включены в языки и системы программирования — сохраняются в дальнейшем, даже если практика указывает на их порочность. Сохраняются в силу необходимости обеспечивать совместимость с наследием прошлого:

Что касается GOTO и проч., то, с одной стороны, доказано, что отказ от упомянутых средств не ограничивает создаваемые программы ни в плане алгоритмических возможностей, ни в плане эффективности (скорее даже наоборот).
С другой стороны, такой отказ гарантирует, что получившаяся программа будет иметь ряд чрезвычайно желательных свойств — четкую структуру, верифицируемость и повышенную надежность. Ни один настоящий профессионал не позволит себе пренебречь этими свойствами, даже если это потребует от него определенной интеллектуальной дисциплины.

Главная проблема в том, что надлежащая дисциплина программирования не может возникнуть сама по себе: она требует целенаправленного обучения. (Попробуйте, например, освоить грамотный горнолыжный поворот — т.наз. угловинтовое движение: без квалифицированного тренера получится только поворот «броском зада». Разве грамотное программирование проще?)

Возвращаясь к списку средств, исключенных из Оберона/Компонентного Паскаля: более подробно каждое из них обсуждается на отдельных страничках. Там же содержатся и дальнейшие аргументы в пользу «сурового» дизайна средств программирования:

История оператора GOTO

Почему нельзя отключать проверки на выход индексов за границы массивов

Почему порочно «наивное» программирование с пошаговым отладчиком

 

 

Главная страница проекта ИНФОРМАТИКА-21

Наука Школе