Программистское. В развитие темы.
Когда я наблюдаю, как долго грузится на моём компьютере Операционная система или как в очередной раз зависает МТСский модем, я понимаю, что далеко не всё благополучно в программистском королевстве.
Много лет я не занимаюсь программированием и о качестве современных программных продуктов могу судить только по косвенным признакам, тем не менее, рискну высказать своё видение проблемы, и не судите меня строго!
О чём говорит, к примеру, зависание программы? А свидетельствует оно о том, что программист, возможно, в силу объективных причин, не отследил некорректности, имеющие место в его программе и в тех программах, которые он использует в своей работе.
МТСовский модем относится к программам управления и связи, и создавалась эта программа, скорее всего, выстраиванием древовидной системы последовательных проверок входных параметров. Как правило, в процессе работы подобных программ производится анализ некоторого количества ситуаций, представляющих интерес для заказчика. К сожалению, эти ситуации не охватывают всего множества возможных комбинаций входных параметров. В результате, при возникновении нештатной ситуации, при которой на входе появляется непредусмотренная комбинация входных параметров, программа улетает неизвестно куда, портит неизвестно что и - зависает! В процессе отладки программист рано или поздно отлавливает и устраняет некорректную ситуацию, при этом плодит серию новых ошибок, которые необходимо найти, и этот процесс может длиться до бесконечности, ничуть не улучшая устойчивости программы. Что мы, собственно, и наблюдаем!
Помните, как руководитель проекта объяснил гибель Фобоса? Из его комментариев было совершенно ясно, что изменения вносились в программы до последнего момента!
Из этой ситуации можно сделать вывод, что проблема корректного решения задач управления и связи до сих пор не решена, и нужно что-то срочно делать, чтобы дать в руки простым пацанам, которые объявляют себя программистами, простой и предельно формализованный механизм, который позволил бы любому из них в два движения создать хотя бы программу под названием «модем», которая хотя бы не зависала!
Как же отделить мух от котлет, то есть как, в общем-то техническую проблему создания управляющей программы, отделить от разработки логики работы изделия, которым эта программа управляет? Как вообще корректно отобразить эту логику во всей сложности этой проблемы, не зашивая её в те чудовищные деревья, которые, насколько я понимаю, до сих пор рисуют несчастные разработчики управляющих программ?
===
Сделаем отступление и поинтересуемся, какие подходы использовал Создатель при конструировании живых организмов. Рассмотрим частный случай - процессы, происходящие в клетке. (Не будучи ни разу биологом, заранее прошу прощения за упрощенное изложение этих процессов, поскольку они интересуют меня всего лишь с точки зрения программиста).
В клетке, во внутриклеточной жидкости, плавают:
- белковые молекулы, которые представляют собой цепочки аминокислот, и которые необходимо дублировать;
- аминокислоты, которые являются строительным материалом для вновь создаваемых белковых молекул;
- рибосомы, которые, собственно, это дублирование и осуществляют.
Для справки: белковая молекула состоит из аминокислот, полученных в процессе переваривания пищи и проникающих в клетку из кровяного русла. Всего существует 21 разновидность аминокислот, из которых и формируется белковая молекула, для каждого органа - своя. Различаются эти молекулы длиной и последовательностью аминокислот в них. Естественно, структура белковой молекулы содержит полную информацию о работе того органа, к которому она принадлежит. Срок жизни белковой молекулы ограничен, поэтому процесс создания «свежих» дублей является непременным условием существования живого организма.
Рибосома представляет собой двухвходовой механизм, к первому входу которого рано или поздно прицепляется молекула, подлежащая дублированию, при этом второй вход открывается на ловлю определённой аминокислоты, ровно такой же, которая в данный момент висит на первом входе. После того, как соответствующая аминокислота ткнулась во второй вход, она захватывается рибосомой и подцепляется к предыдущей, при этом вся система продвигается на одну позицию, после чего второй вход рибосомы открывается на ловлю очередной, аналогичной висящей на первом входе аминокислоты.
Рибосома является универсальным механизмом дублирования и ей по барабану, дублирует ли она белковую молекулу печени, кожи, мозга и проч. - что подцепилось к первому входу, с тем и работает!
Что в этом процессе представляет интерес для программиста? Здесь много полезных вещей, но главное - общий подход: размещение всей информационной составляющей в белковой молекуле - матрице, с которой работает простейший универсальный механизм - рибосома (впрочем, простейшим он является только с точки зрения программиста, а с точки зрения биолога - это один из самых сложных элементов живого организма.)
===
Прекрасно помню, как, наткнувшись в середине 80-х в русской версии журнала Сайнтифик Америкен на статью, вольный пересказ которой приведён выше, я обрадовалась, потому что увидела в описании внутриклеточных процессов косвенное подтверждение правильности подходов, которые были использованы нами начале 70-х при разработке программ управления спутником.
В те достославные времена мы работали на тихоходных машинах и писали программы в машинных кодах, поскольку управление спутником осуществлялось в «реальном времени», и обработку телеметрии, её анализ и выработку управляющих сигналов необходимо было уместить в определённый временной интервал, то есть успеть управиться до получения следующей партии входных данных. Нам приходилось экономить на каждой команде и просчитывать длительность всех циклов, чтобы не вывалиться из графика.
Были мы тогда абсолютно свободны, как охотники на мамонтов, никакие операционные системы над нами не довлели, и создавали мы свои виртуальные царства-государства как бог нам на душу положит, прекрасно сознавая, что всё зависит только от нас самих, от нашего ума, знаний, упорства и тщательности в работе. Поэтому программы, созданные в то время, были предельно лаконичны, функционально насыщены, легко обозримы и относительно просты в отладке. Именно тогда нам пришла идея всю логику работы космического аппарата описать в виде матрицы, которую по определённому правилу сворачивает матричный дешифратор, использующий всего две команды: логического сложения и логического умножения - простейшая программа в два десятка команд!
Матрица представляла собой прямоугольную таблицу, каждая строка которой «принадлежала» одному из входных параметров, а каждый столбец - одному из выходных параметров. Входные и выходные параметры для работы с матрицей подлежали формализации, в процессе которой представлялись в двоичном виде, то есть, могли принимать значения либо нуля, либо единицы и образовывали, соответственно, входное и выходное слово. Матрицу формировал не программист, но разработчик системы, отмечая в каждом столбце единицей перекрестья с теми строками, которые соответствовали входным параметрам, от которых зависел выходной сигнал, и нулями - перекрестья с теми строками, которые соответствовали входным параметрам, от которых не зависел данный выходной сигнал.
Процесс обработки телеметрии предусматривал: а) формализацию входных данных и формирование входного слова в двоичном виде; б) сворачивание управляющей матрицы, в процессе которого строчки, соответствующие нулевым значениям входных параметров, складывались по правилу логического умножения, а строчки, соответствующие единичным значениям входных параметров, складывались по правилу логического сложения (или наоборот? Не помню!), в результате чего формировалось выходное слово; в) представление выходных сигналов в виде, готовом для передачи на спутник. (Вполне допускаю, что с алгоритмом сворачивания матрицы я могла напутать - прошло сорок лет, и с тех пор я не стала моложе и умнее, да и память не та, но сейчас я говорю об общем подходе к проблеме, который смог бы явиться альтернативой древовидным алгоритмам.)
Описанный подход характерен, скорее, для аппаратного исполнения логических задач, но программное исполнение имеет несомненные преимущества. Прежде всего, это возможность моментального изменения управляющей матрицы в процессе разработки и отладки, а также возможность создания простейшей отладочной программы, которая позволяла разработчику просмотреть абсолютно все 2 в n-й степени комбинации, которые могут принимать n входных параметров, после чего, наконец-то, можно было утверждать, что программа отлажена абсолютно.
В процессе разработки системы мы перешли к многоуровневым матрицам и всерьёз обсуждали вопрос о введении в компьютер дополнительных команд, позволяющих работать с матрицами произвольной ширины.
===
Всё закончилось с появлением быстродействующей элементной базы. Отпала потребность в ювелирно точном исполнении каждой программы, теперь можно было позволить себе не заморачивать голову такими пустяками, как экономия времени исполнения программ. Никого не напрягало, что вычисление 2*2 выливалось в исполнение сотен и тысяч команд - быстродействие позволяло так роскошествовать! Правда, цена подобного подхода велика, поскольку и ежу ясно, что рано или поздно наступит день, когда предел быстродействия элементной базы будет достигнут и система придёт в насыщение. Но ещё до наступления этого знакового события уровень энтропии внутри системы с каждой новой её модификацией будет возрастать и вполне вероятно, что в какой-то момент количество перейдёт в качество и с ней случится тот самый "Чёрный лебедь", о котором совершенно блестяще пишет Талеб, в результате чего система попросту превратиться в кучу хлама.
Что же делать? Каким путём нам идти? Ответ прост: учиться у природы! Приведённый выше пример работы рибосомы подсказывает нам, что мы должны искать такие средства и методы решения задач, которые позволят создавать простые, лаконичные и достаточно унифицированные программы. Категорически отказаться от избыточности, создавать лёгкие, изящные и элегантные изделия. Разрабатывать принципиально иную, отличную от билгейцовской, идеологию организации виртуального пространства.
А что же с программистами, чьи мозги отформатированы для работы с системами Билла Гейца и иже с ним? Это вчерашний день. Они - не интересны. Они - не исправимы. Пусть едут с Цукербергом в Америку, пусть едят вместе с Артёмием Лебедевым чёрную икру, и вообще делают всё, что хотят - не велика потеря. Как-то выживут! В крайнем случае, если не захотят ехать в деревню, пойдут на рынки торговать китайским шмотьём, станут курьерами, гардеробщиками или дворниками - городу требуется много обслуги! Ничего не поделаешь! Такова жизнь программистов. При переходе на следующий технологический уровень они оказываются не у дел, поскольку не могут конкурировать с молодёжью, заточенной под этот новый технологический уровень!
Мы же должны находить головастых ребятишек из глубинки с открытыми и свободными мозгами, селить их на «необитаемом острове», давать им правильное образование, в том числе по биологии, ставить перед ними правильные задачи и оставлять их один на один с голеньким компьютером безо всяких там инородных операционных систем. А будет правильнее, если и компьютеры они сами разработают.
И тогда в обозримом будущем мы и в этой области будем впереди планеты всей!
Много лет я не занимаюсь программированием и о качестве современных программных продуктов могу судить только по косвенным признакам, тем не менее, рискну высказать своё видение проблемы, и не судите меня строго!
О чём говорит, к примеру, зависание программы? А свидетельствует оно о том, что программист, возможно, в силу объективных причин, не отследил некорректности, имеющие место в его программе и в тех программах, которые он использует в своей работе.
МТСовский модем относится к программам управления и связи, и создавалась эта программа, скорее всего, выстраиванием древовидной системы последовательных проверок входных параметров. Как правило, в процессе работы подобных программ производится анализ некоторого количества ситуаций, представляющих интерес для заказчика. К сожалению, эти ситуации не охватывают всего множества возможных комбинаций входных параметров. В результате, при возникновении нештатной ситуации, при которой на входе появляется непредусмотренная комбинация входных параметров, программа улетает неизвестно куда, портит неизвестно что и - зависает! В процессе отладки программист рано или поздно отлавливает и устраняет некорректную ситуацию, при этом плодит серию новых ошибок, которые необходимо найти, и этот процесс может длиться до бесконечности, ничуть не улучшая устойчивости программы. Что мы, собственно, и наблюдаем!
Помните, как руководитель проекта объяснил гибель Фобоса? Из его комментариев было совершенно ясно, что изменения вносились в программы до последнего момента!
Из этой ситуации можно сделать вывод, что проблема корректного решения задач управления и связи до сих пор не решена, и нужно что-то срочно делать, чтобы дать в руки простым пацанам, которые объявляют себя программистами, простой и предельно формализованный механизм, который позволил бы любому из них в два движения создать хотя бы программу под названием «модем», которая хотя бы не зависала!
Как же отделить мух от котлет, то есть как, в общем-то техническую проблему создания управляющей программы, отделить от разработки логики работы изделия, которым эта программа управляет? Как вообще корректно отобразить эту логику во всей сложности этой проблемы, не зашивая её в те чудовищные деревья, которые, насколько я понимаю, до сих пор рисуют несчастные разработчики управляющих программ?
===
Сделаем отступление и поинтересуемся, какие подходы использовал Создатель при конструировании живых организмов. Рассмотрим частный случай - процессы, происходящие в клетке. (Не будучи ни разу биологом, заранее прошу прощения за упрощенное изложение этих процессов, поскольку они интересуют меня всего лишь с точки зрения программиста).
В клетке, во внутриклеточной жидкости, плавают:
- белковые молекулы, которые представляют собой цепочки аминокислот, и которые необходимо дублировать;
- аминокислоты, которые являются строительным материалом для вновь создаваемых белковых молекул;
- рибосомы, которые, собственно, это дублирование и осуществляют.
Для справки: белковая молекула состоит из аминокислот, полученных в процессе переваривания пищи и проникающих в клетку из кровяного русла. Всего существует 21 разновидность аминокислот, из которых и формируется белковая молекула, для каждого органа - своя. Различаются эти молекулы длиной и последовательностью аминокислот в них. Естественно, структура белковой молекулы содержит полную информацию о работе того органа, к которому она принадлежит. Срок жизни белковой молекулы ограничен, поэтому процесс создания «свежих» дублей является непременным условием существования живого организма.
Рибосома представляет собой двухвходовой механизм, к первому входу которого рано или поздно прицепляется молекула, подлежащая дублированию, при этом второй вход открывается на ловлю определённой аминокислоты, ровно такой же, которая в данный момент висит на первом входе. После того, как соответствующая аминокислота ткнулась во второй вход, она захватывается рибосомой и подцепляется к предыдущей, при этом вся система продвигается на одну позицию, после чего второй вход рибосомы открывается на ловлю очередной, аналогичной висящей на первом входе аминокислоты.
Рибосома является универсальным механизмом дублирования и ей по барабану, дублирует ли она белковую молекулу печени, кожи, мозга и проч. - что подцепилось к первому входу, с тем и работает!
Что в этом процессе представляет интерес для программиста? Здесь много полезных вещей, но главное - общий подход: размещение всей информационной составляющей в белковой молекуле - матрице, с которой работает простейший универсальный механизм - рибосома (впрочем, простейшим он является только с точки зрения программиста, а с точки зрения биолога - это один из самых сложных элементов живого организма.)
===
Прекрасно помню, как, наткнувшись в середине 80-х в русской версии журнала Сайнтифик Америкен на статью, вольный пересказ которой приведён выше, я обрадовалась, потому что увидела в описании внутриклеточных процессов косвенное подтверждение правильности подходов, которые были использованы нами начале 70-х при разработке программ управления спутником.
В те достославные времена мы работали на тихоходных машинах и писали программы в машинных кодах, поскольку управление спутником осуществлялось в «реальном времени», и обработку телеметрии, её анализ и выработку управляющих сигналов необходимо было уместить в определённый временной интервал, то есть успеть управиться до получения следующей партии входных данных. Нам приходилось экономить на каждой команде и просчитывать длительность всех циклов, чтобы не вывалиться из графика.
Были мы тогда абсолютно свободны, как охотники на мамонтов, никакие операционные системы над нами не довлели, и создавали мы свои виртуальные царства-государства как бог нам на душу положит, прекрасно сознавая, что всё зависит только от нас самих, от нашего ума, знаний, упорства и тщательности в работе. Поэтому программы, созданные в то время, были предельно лаконичны, функционально насыщены, легко обозримы и относительно просты в отладке. Именно тогда нам пришла идея всю логику работы космического аппарата описать в виде матрицы, которую по определённому правилу сворачивает матричный дешифратор, использующий всего две команды: логического сложения и логического умножения - простейшая программа в два десятка команд!
Матрица представляла собой прямоугольную таблицу, каждая строка которой «принадлежала» одному из входных параметров, а каждый столбец - одному из выходных параметров. Входные и выходные параметры для работы с матрицей подлежали формализации, в процессе которой представлялись в двоичном виде, то есть, могли принимать значения либо нуля, либо единицы и образовывали, соответственно, входное и выходное слово. Матрицу формировал не программист, но разработчик системы, отмечая в каждом столбце единицей перекрестья с теми строками, которые соответствовали входным параметрам, от которых зависел выходной сигнал, и нулями - перекрестья с теми строками, которые соответствовали входным параметрам, от которых не зависел данный выходной сигнал.
Процесс обработки телеметрии предусматривал: а) формализацию входных данных и формирование входного слова в двоичном виде; б) сворачивание управляющей матрицы, в процессе которого строчки, соответствующие нулевым значениям входных параметров, складывались по правилу логического умножения, а строчки, соответствующие единичным значениям входных параметров, складывались по правилу логического сложения (или наоборот? Не помню!), в результате чего формировалось выходное слово; в) представление выходных сигналов в виде, готовом для передачи на спутник. (Вполне допускаю, что с алгоритмом сворачивания матрицы я могла напутать - прошло сорок лет, и с тех пор я не стала моложе и умнее, да и память не та, но сейчас я говорю об общем подходе к проблеме, который смог бы явиться альтернативой древовидным алгоритмам.)
Описанный подход характерен, скорее, для аппаратного исполнения логических задач, но программное исполнение имеет несомненные преимущества. Прежде всего, это возможность моментального изменения управляющей матрицы в процессе разработки и отладки, а также возможность создания простейшей отладочной программы, которая позволяла разработчику просмотреть абсолютно все 2 в n-й степени комбинации, которые могут принимать n входных параметров, после чего, наконец-то, можно было утверждать, что программа отлажена абсолютно.
В процессе разработки системы мы перешли к многоуровневым матрицам и всерьёз обсуждали вопрос о введении в компьютер дополнительных команд, позволяющих работать с матрицами произвольной ширины.
===
Всё закончилось с появлением быстродействующей элементной базы. Отпала потребность в ювелирно точном исполнении каждой программы, теперь можно было позволить себе не заморачивать голову такими пустяками, как экономия времени исполнения программ. Никого не напрягало, что вычисление 2*2 выливалось в исполнение сотен и тысяч команд - быстродействие позволяло так роскошествовать! Правда, цена подобного подхода велика, поскольку и ежу ясно, что рано или поздно наступит день, когда предел быстродействия элементной базы будет достигнут и система придёт в насыщение. Но ещё до наступления этого знакового события уровень энтропии внутри системы с каждой новой её модификацией будет возрастать и вполне вероятно, что в какой-то момент количество перейдёт в качество и с ней случится тот самый "Чёрный лебедь", о котором совершенно блестяще пишет Талеб, в результате чего система попросту превратиться в кучу хлама.
Что же делать? Каким путём нам идти? Ответ прост: учиться у природы! Приведённый выше пример работы рибосомы подсказывает нам, что мы должны искать такие средства и методы решения задач, которые позволят создавать простые, лаконичные и достаточно унифицированные программы. Категорически отказаться от избыточности, создавать лёгкие, изящные и элегантные изделия. Разрабатывать принципиально иную, отличную от билгейцовской, идеологию организации виртуального пространства.
А что же с программистами, чьи мозги отформатированы для работы с системами Билла Гейца и иже с ним? Это вчерашний день. Они - не интересны. Они - не исправимы. Пусть едут с Цукербергом в Америку, пусть едят вместе с Артёмием Лебедевым чёрную икру, и вообще делают всё, что хотят - не велика потеря. Как-то выживут! В крайнем случае, если не захотят ехать в деревню, пойдут на рынки торговать китайским шмотьём, станут курьерами, гардеробщиками или дворниками - городу требуется много обслуги! Ничего не поделаешь! Такова жизнь программистов. При переходе на следующий технологический уровень они оказываются не у дел, поскольку не могут конкурировать с молодёжью, заточенной под этот новый технологический уровень!
Мы же должны находить головастых ребятишек из глубинки с открытыми и свободными мозгами, селить их на «необитаемом острове», давать им правильное образование, в том числе по биологии, ставить перед ними правильные задачи и оставлять их один на один с голеньким компьютером безо всяких там инородных операционных систем. А будет правильнее, если и компьютеры они сами разработают.
И тогда в обозримом будущем мы и в этой области будем впереди планеты всей!