SKY / ROOTS / LANG /
ABS1

Почему все языки программирования ориентированы на применение в обычных текстовых файлах? Можно предположить, что их разработчикам не хватает ресурсов для того, чтобы помимо разработки синтаксиса и компилятора ещё и разрабатывать среду разработки. Возможно так было когда появлялись первые языки, а позже уже просто следовали традиции?

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

В других корнях уже приводились аргументированные доводы, что все идеальное (мы же хотим разрабатывать и использовать хорошие языки программирования) должно подразумевать непрекращающееся развитие. Представим, что следуя парадигме структурного программирования, мы придумали оператор for для реализации циклов в разрабатываемом языке. Выпустили новый язык в продакшн и на нем множество людей написали программы. К примеру, будем считать что речь идёт о PHP. Однажды, выпуская новую версию, мы решили заменить оператор for амперсандом, чтобы программы писались быстрее, например. Можно оставить поддержку старого синтаксиса в новой версии и добавить новые возможности синтаксиса, но это не есть хорошее решение. Следуя по такому пути мы можем накопить множество дублирующегося функционала, который будет делать реализации языка громоздкими и медленными. Если мы со временем уберём поддержку for (через несколько версий) мы потеряем обратную совместимость и надеяться что старые программы не будут употребимы не хорошо. Мы не можем "видеть на много лет вперёд" но как создать идеальный язык?

Ответ прост: программы уровня абстракции человека (то что мы называем языками программирования) не могут быть простыми текстами. Выше приведён только один аргумент в эту пользу. Но если язык программирования не может быть простым текстом, что должна представлять его реализация? Мы привыкли, что реализация языка это абстрактный синтаксис, для которого есть документация и компилятор и/или интерпретатор, короче программа его исполняющая. Чаще всего в свободном доступе имеются и IDE для работы, но коренным образом не связанные с самим языком. В идеальном случае текст программы это не простой текстовый файл, а файл поддерживаемый IDE, которая поставляется с компилятором языка и коренным образом с ним связанная. Кроме того имеется каскад модулей портирования кода от версии к версии, а сам код программы всегда включает номер версии на которой он был написан и протестирован. В этом случае, мы всегда сможем легко развивать язык лишившись вышеописанных недостатков.

Если язык программирования разрабатывается по вышеуказаной схеме и парсер языка тесно связан с IDE, набрав амперсанд мы можем автоматически получить подсказку, что начинается цикл и для ясности кода не нужно набирать длинное ключевое слово "for each", синтаксис от версии к версии языка может коренным образом меняться без утраты обратной совместимости. Однажды давно написанная программа, может обрести невообразимое улучшение результатов своей работы в последней версии языка. Идеальное развитие и подразумевает коренные изменения. Вначале мы пишем тексты, позже используем визуальное программирование а в самом конце голосом объясняем компьютеру что нужно сделать, т.е. оператор for оказывается вообще не нужен.

Вывод: каноническая абстракция языка программирования человеком не может быть изложена в простых текстовых файлах, как минимум необходим "header" в не текстовой области программ. В нем автоматически будет сохраняться версия языка, на которой написан и протестирован код. В таком случае, при смене версии реализации языка на более новую, каскадный код портирования может сохранить в архиве оригинальный код и преобразовать этот код для новой версии языка автоматически. Разумно поддерживать работоспособным весь код предыдущих версия, но не разумно, чтобы код новых версий работал на старых реализациях языка. Но также разумно, чтобы оригинальный код был сохранен. Итак, делаем поправку: каноническая абстракция языка программирования человеком это не текстовые файлы, а особая совокупность файлов специального формата. Любая законченная программа, будь то рабочей программой или разновидностью библиотеки, кодом самостоятельно не выполняющемся, но предназначенным быть вызванным из других файлов, должен представляться пакетом, который состоит из файла пакета со специальным форматом, который содержит центральную информацию о пакете: также как и файлы кода, версию языка на которой началась разработка пакета кода, данные о наличии оригинального кода в архиве. Заметим все данные в файле пакета генерируются автоматически с помощью IDE, хотя в файл пакета можно поместить и информацию набранную на клавиатуре человеком, например текстовое описание пакета.

Если файл пакета содержит информацию о версии языка, стоит ли версию языка помещать в header каждого файла программы (автоматически с пом. IDE) и вообще отказаться от спец. формата и оставить формат файлов кода чисто текстовым? Да... Если после автоматического портирования кода, текст кода не изменился, его можно не помещать в архив оригинального кода а лишь сделать ссылку, указывающую что при портировании кода на новую версию языка текст программы не модифицировался. Кроме того в header-е файлов кода можно хранить другую полезную информацию, например принадлежность к "точке входа" или "включаемости" данного кода в файле.

Но о  каком версировании идет речь в рассуждениях описанных выше? Речь идет о программах однажды написанных и не изменяющихся в последствии, но способных всегда выполняться на новых версиях языка, версии указывают на версии языка а не кода. А если программист желает улучшить код и изменяет программу в IDE "руками"? В этом случае, должен происходить своеобразный сброс - архив с оригинальным кодом должен очиститься, файлы кода и пакета менять версию кода. Значит после отладки кода, когда получен код готовый для использования, необходимо в IDE нажимать кнопку "сохранить пакет", и только в этот момент будет происходить автоматическое версирование написанного кода. В header-ах должно храниться две версии - версия языка и версия кода.

В современных языках программирования, в коде программ, написанным на них, отсутствует многая необходимая информация, как и присутствует не нужная. Рассмотрим программу на языке C: в каждой программе необходимо определять функцию main() с которой начинается выполнение... Но ведь это в некотором смысле тофтология... Да, писать ненужного текста, в общем-то немного, но это просто неверный подход логически. В IDE все файлы программ "по умолчанию", могут иметь флаг "включаемый файл", а если из этого файла может начинаться выполнение программы, можно просто щелчком мыши, назначить этот файл как файл "точки входа" намного быстрее, кроме того такой подход построения языка имеет другие преимущества. Рассмотрим PHP: многие файлы в типичных проектах на PHP включаемые и потенциально существует опасность взлома кода, если происходит выполнение файла который должен быть включаемым. В SKY Framework, который написан на PHP, декларируется необходимость начинать код включаемых файлов, кодом подобным:

<?php defined('START') or die;

Но ведь этого, можно было бы вообще не делать, если бы гармоничное IDE языка программирования по умолчанию выставляло флаг "включаемый файл" (следуя все тоже принципу - самое частое самое короткое или вообще "по умолчанию").

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

Человечество уже давно перешло от консольных и текстовых абстракций управления компьютером к графическим. Так же и давно пора перейти от текстовых абстракций языков программирования к графическим.
опубликовано ENERGY - 7 Nov 2015 22:58 GMT
последнее редактирование - 9 Nov 2015 06:17 GMT
комментировать