Поколения Языков Программирования с точки зрения Инструментов Сознания

[c8ne]

Этот пост является продолжением поста про инструменты сознания.

Можно рассмотреть развитие языков программирования в соответствии с внедрением инструментов сознания в области программирования.

Comments

[maksiq]

Тут реально интересно попробовать разобраться отдельно со структурами данных их сложностью и отдельно с алгоритмами и их сложностью. Собственно, говоря про LISP Вы разноуровневость по этим осям подметили. А по структурам данных где-то по-моему должен возникнуть SQL. Или это будет третья ветка? Хотя в linq на C# объектные типы с SQL вроде как объединили. В приниципе, наверное, можно говорить о структурах данных, что сложные вложенные структуры - это иерархии и правила, а вот sql и linq - это объекты и метаправила. А может, современный C# с linq, лямбдами и другими мультипарадигмальными конструкциями - это уже следующий, системный уровень, просто его еще не освоили по полной, используют парадигмы по-отдельности? Потому что лямбды, в которую инкорпорированны локальные переменные или члены класса - это больше, чем лямбды в функциональных языках.

А вот с алгоритмикой мне лично менее понятно. То есть простые уровни - структурные операторы, циклы и подпрограммы - это все ясно. Рекурсия - она, наверное, там же. А в чем сложность дальше? Виртуальные уровни и generic-классы?

И, кстати, про начальные уровни. Вот здесь http://ailev.livejournal.com/1022791.html Левенчук пишет про свой опыт обучения алгоритмике сына, выделяя уровни сложности. Там интересная конструкция, не похожая на развитие языков (и именно из-за ее отсутствия обучение алгоритмики считалось возможным от 7 класса). Было бы интересно Ваше восприятие этих ступенек с точки зрения теории сложности - потому что Вы ей на некотором уровне владеете, а я - нет.

[c8ne]

Про обучение, я немного попозже отвечу, так как там достаточно много информации. Про SQL тоже отвечу отдельно.

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

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

Кстати, этот шаблон обычно появлялся в системах, которые были фактически OOP или FP (например GUI библиотека), но написаны на языке предыдущего уровня. И в них всегда было очень тяжело без сборки мусора.

[maksiq]

Про функциональное программирование - не понимаю. Понятие ссылки на функцию появилось в C, а в С++ помимо этого появились виртуальные функции и генерики. При чем тут указатель на void?

И какие понятия/объекты языка соответствуют моделям и метаправилам в смысле алгоритмики в LISP или в Схеме или в F#?

SQL

[c8ne]

Отнесение SQL к какому либо уровню достаточно сложно, так как SQL не проектировался, как полноценный язык программирования. Это DSL для работы с данными.

В языке запросов SQL можно увидеть неполное освоение уровня иерархий и правил. Декомпозиция на под-запросы поддержана очень плохо. Переиспользуемые (в том числе и в других запросах) параметризованные запросы до сих пор плохо стандартизованы, а где есть, требуют некоторых специальных усилий. Также SQL очень плохо обрабатывает иерархические структуры данных, даже с последними расширениями. В этом отношении интересен Datalog, который является языком уровня иерархий и правил с самого начала, хотя и с существенными ограничениями.

На уровне определения данных, схожие проблемы. SQL базы данных плохо поддерживают рекурсивные структуры. Эти структуры определяются через отношения, и их создание обработка выглядят несколько противоестественными. И даже определяемые пользователем типы данных, еще не везде внедрены, и они ограничиваются только набором полей. Нельзя сделать из такой структуры ссылку на таблицу (не в одной базе, которую я смотрел, нельзя даже определить foreign key из структуры).

То есть, на текущем уровне SQL это скорее 2+, уровень сочетаний и рецептов с некоторыми фичами следующих уровней, но которые не встроены полноценно в язык. Это как указатели на функции в С. Вроде есть, но пользоваться очень сложно и нужны многочисленные дополнительные приседания.

Я думаю, что эти проблемы вызваны отношением к SQL как к DSL. Если мы хотим расширить круг пользователей, DSL должен быть где-то на уровень ниже основного языка, что бы упростить использование.

Проблемы с SQL хорошо видны на кривой возрастания сложности. SQL запрос на 90 строчек - это просто ужас-ужас-ужас. Тогда как для C программы это нормально, а на Java очень редкие программы меньше. Это все связанно с использованием инструментов сознания для организации кода, чем ниже уровень инструмента, тем меньше кода он может организовать с приемлемой сложностью.

В OODB попытались сделать уровень 4 (модели), но там возникли другие проблемы, связанные выбранной технологией интеграции с языками программирования. Так же уровень мета-правил (FP) не поддерживался в тех реализациях, с которыми я знаком.

ИМХО задачу обработки и хранения данных уже пора решать с помощью полноценного и полного языка программирования, а не в виде DSL. Некоторые NoSQL базы в этом направлении движутся, но как-то очень робко.

Re: SQL

[maksiq]

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

А как раз возможность воспринимать длинные линейные конструкции - наоборот, свидетельство низкой сложности языка, ты пишешь на нем простые линейные тексты, которые хорошо читаются, и что?

Что касается ООDB, то там как раз никаких уровней сложности нет, это просто хранилка к ОО-структурам данных - сложность которых не слишком велика. иерархия и все. А вот настоящий синтез возникает в C# с linq - который инкорпорировал сложность и многообразие SQL в смысле организации данных в не менее сложный OO-язык.

Re: SQL

[c8ne]

Я все-таки дозрел написал про SQL.