span.fullpost {display:none;} span.fullpost {display:inline;}

вторник, 3 января 2012 г.

Классические формальные методы разработки программ

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

Эта ситуация была уже 40-50 лет назад. С этого времени профессия программиста в этом плане сильно не изменилась. А тем не менее рутинная, механическая, работа осталась. Если у программиста в голове есть правильное понимание того, что должна делать программа, то пусть компьютер сам пишет программы, подчиняясь идеям программиста. Т.е. хотелось бы иметь "программирующую программу" нового поколения, которая по некому более высокоуровневому описанию, нежели теперешние широкоиспользуемые языки программирования, предлагала реализации, возможно ценой потери эффективности, но с бОльшими возможностями по поддержке программ в более высокоуровневом представлении.

В мечтах это представлялось следующим образом: подходит программист к доске, чертит на ней какие-то непонятные символы (это он кратко, но точно, описывает концепции, логику поведения, которая должна быть в программе. Затем, оформив это в виде файла, запускает некий "спец.транслятор", выдающий исходные тексты программы, выполняющие заданную программистом логику. Программист занимается человеческим делом, он думает о самой задаче (а ведь сейчас, согласитесь, задачи решаются сложные: попробуйте хотя бы представить объемы требований!). А рутинную работу человек уже не делает. Красиво, не правда ли!

А теперь вопрос, почему мы до сих пор так не программируем ?

2 комментария:

  1. Сейчас куда ни плюнь, по-моему - везде эта проблема, причем в разных областях... И в комп. лингвистике я о ней слышал, и в тестировании я о ней слышал, и где я только не слышал о ней (да даже диплом у меня в какой-то мере должен касаться этого вопроса - наверное).

    Чаще всего, по-моему, предлагают какие-то "супершаблоны", сильно зависящие от конкретной предметной области, но какой-то общей теории шаблонизации, из которой последовала бы и возможность подобной трансляции "с доски" в код, я пока что не видел.

    Самое близкое, наверное, что сейчас возможно реализовать в применении к обычному программированию - некий мифический автоматизатор, который каким-то образом самостоятельно умеет применять настраиваемые архитектуры, паттерны и алгоритмы. Распространенных однообразных подзадач, которые в него можно было бы встроить, действительно хватает.

    P.s. в "несерьезном" игрострое к этой идее пришли очень давно - много лет назад я баловался с разными средами, в которых достаточно было графически настроить связь между объектами - и на выходе получалась готовая игра. Конечно, эти среды были весьма ограничены в возможностях, но с поставленной задачей справлялись на удивление прилично.

    ОтветитьУдалить
  2. Заметьте, что в любом случае придется придумывать способы задания (описания) связей, объектов, свойств, идей того, чего хочется. Т.е. нужен будет язык спецификации (естественно, формальной спецификации). Он бы выполнял ту же функцию, какую сейчас выполняют языки программирования. И вполне очевидно, что придуманные сейчас языки (методы) спецификации для этой цели не годятся. Ни алгебры, ни пред- и пост- условия. Т.е. не то, что нет "программирующих программ", но даже языков еще удобных не придумано!

    ОтветитьУдалить