программирование

История программирования в СССР (первая часть, вторая часть). Написано интересно и легко читается. Вот, например, про блок-схемы:

Давным давно, еще в докомпьютерную эру (с двадцатых годов) применялись для изображения последовательных процессов или алгоритмов блок-схемы (flowcharts). На них отдельные элементарные (на данном уровне абстракции) шаги изображались прямоугольничками, последовательность шагов — стрелочками, а ветвления (проверки условий) ромбиками. В самом-самом начале, когда языков программирования еще не было, а программы непосредственно кодировались числовыми кодами или, в лучшем случае, писались в «содержательных обозначениях», как рекомендовал патриарх нашего ремесла Александр Львович Брудно, блок-схемы были важным подспорьем. В таковом качестве во время оно их и застандартизировали.

Прошли десятилетия, то есть минули целые эпохи. А от программистов по-прежнему требовали чертить эти чертовы стрелочки и ромбики. Смысла в этом было аж никакого. Во-первых, теоретически доказано, что любой алгоритм, записанный на языке высокого уровня (на любом языке) имеет эквивалентное графическое представление в виде блок-схемы и почти наоборот, любая правильная блок-схема (фишка тут в слове «правильная») эквивалентна некоторому тексту на том или ином языке программирования. Но текст программы завсегда лучше блок-схемы, хотя бы потому, что последней можно только любоваться, а первый — это реальный кусок программы, который компилируется и выполняется на машине. Есть разница? Во-вторых, блок-схема может показать только синхронный, строго последовательный процесс вычислений, а в жизни такое наблюдается разве что в небольших несложных программах. Реальные же системы — это не однопоточные алгоритмы, а целые искусственные миры, где множество населяющих их объектов-персонажей (как программных, так и аппаратных) взаимодействуют друг с другом, посылая в непредсказуемые моменты времени сигналы и возбуждая прерывания, и где множество потоков вычислений исполняются одновременно и асинхронно, порой еще и на множестве процессоров и машин. Получается, что блок-схемами можно проиллюстрировать только маленькие кирпичики, но никак не всю систему, но зачем дополнительно иллюстрировать то, что и так внятно и понятно (с комментариями) записывается в текстовом виде?

Казалось бы, не нужны, так не пользуйтесь. А действительно не нужны — любой программист, хоть разработчик, хоть представитель заказчика предпочтет посмотреть исходный текст программы, а не эти картинки. Непрограммисту они — тем более до лампочки. И только ГОСТу, в лице его полномочного представителя — нормоконтролера, они нужны. Дороги как произведения изобразительного искусства. Он их проверяет на соответствие требованием оформления — такая-то ширина линий, столько-то миллиметров длина стрелочки, такой-то отступ квадратика от ромбика… Смысл схемы контролеру совершенно недоступен. Можете себе представить, какая халтура там процветала? В нашей конторе (как и в сотнях и тысячах таких же контор по всему Союзу) сидели тетки-чертежницы и тушью на кальках рисовали никому не нужные стрелочки и ромбики. Зато безработицы не было! Уже Союз загибался, но в девяностом году, если не ошибаюсь, успели под занавес выпустить новый ГОСТ все на ту же тему рисования блок-схем. Какая-то навязчивая, неотвратимая мания. Ну да ладно…

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

Я заинтересовался Паскалем еще до того, как мы его начали проходить в школе, потому что это позволило мне кое-что вычислить. Я разобрался в Ассемблере, потому что замена часто выполняемого кода ассемблерными вставками сильно ускоряет программу. А вот разобраться с Си я заставлял себя долго (правда, Си мне приходилось использовать и я бы рано или поздно с ним разобрался).

Я начал программировать на Delphi, потому что это почти что Паскаль :) И еще потому, что на нем легко делать интерфейсы. Но вот делать что-либо в Visual Studio меня не тянет.

Я принялся за изучение PHP, потому что он был на моем хостинге и мне хотелось «оживить» свой сайт. Но браться за Python или Ruby я не вижу смысла.

То же самое и с объектно-ориентированным программированием. Я до сих пор в программах не создаю свои классы (или объекты, как там правильно?). Процедурного программирования пока хватает.

Для меня Java, .NET, MVC, XML, x64 и остальное X — пустой звук. Уж лучше играться с shell-скриптами.

Я давно уже собираюсь выпустить новую версию The Game of Life, 3.6. Внес ряд полезных изменений. Проблема, которую осталось решить, как ни странно, связана с Вистой :)

Кажется, микрософты сделали так, что GDI в Висте эмулируется через DirectX (я не специалист в этом вопросе, точно утверждать не берусь). Из-за этого прорисовка через Canvas.Pixels стала в Висте жутко тормозить (по сравнению с XP). Я прекрасно понимаю, что Canvas.Pixels — сам по себе не очень быстрый способ вывода на экран. Но когда на каждом шаге меняется несколько точек, проще вызвать именно Canvas.Pixels, а не создавать отдельный буфер.

Версию 3.6 я задумал как переходную — в ней я хотел разобраться с графикой, а переписывание алгоритма расчета оставить для следующих версий. Мой приятель, просивший не упоминать его имя, помог с OpenGL. Теперь некритичная к быстродействию часть кода выводит графику через Canvas, а критичная — через OpenGL.

В ходе тестирования выяснилось, что в Висте есть еще одна проблема, которая связана, вероятно, с тем, что Виста запоминает содержимое PaintBox'а. Виста считает себя умнее всех остальных систем, в которых посылается сообщение wmpaint, и без спроса восстанавливает то, что было PaintBox'е, хотя оно уже перезаписано более свежей картинкой.

Логично предположить, что всё дело в Делфи 7. Она вообще не подозревает о существовании Висты :) Вполне возможно, что подобные ошибки уже исправлены в последней версии Делфи. Не долго думая, установил Делфи 2009. После небольших изменений кода программа скомпилировалась, но заработать отказалась из-за непонятной ошибки «Stream read error» при запуске. Более того, похожая ошибка стала возникать и в Делфи 7, правда, сообщение там было другое: «List capacity out of bounds (%d)». Эта же ошибка стала возникать и при запуске ранее скомпилированных экзешников. Я не знаю, что Делфи 2009 сделала с Вистой, что отказались работать экзешники, скомпилированные до ее установки!

Делфи 2009 — какое-то жуткое говно. Она, наконец, научилась понимать картинки PNG. Но вот с альфа-прозрачностью у нее до сих пор проблемы. Алё, Embarcadero, 2009 год на дворе. Как можно не поддерживать альфа-прозрачность? Отладчик по сравнению с седьмой версией сильно не улучшился. В программе возникла ошибка, так покажите, где она! Почему Visual Studio это умеет, а Делфи — нет?

К счастью, после удаления Делфи 2009 проблема с ошибкой «List capacity out of bounds (%d)» исчезла. Баг, связанный с обновлением PaintBox'а, исправлю каким-нибудь другим способом.

Да, и еще. Вот объясните мне, как можно пользоваться последними версиями программных продуктов и технологий, если они настолько кривые?

Добавлено: Обычно я не склонен к поспешным выводам, однако Делфи 2009 произвела на меня совсем уж удручающее впечатление :) По всей видимости, проблема с ошибкой при старте программы не связана с Делфи 2009. И, может быть, в ней можно заставить PNG работать нормально. В общем, нужно еще раз ее поставить, чтобы разобраться до конца.

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

Участки кода в комментариях — удобный прием при отладке. В окончательной версии в комментариях должны оставаться только пояснения.

Как заставить неправильный код выглядеть неправильно. Описывается один из вариантов оформления кода. Даже если вы — опытный программист, статья будет полезна для вас.