Интересно, но возникают вопросы.
1.
Ссылается на статью, в которой производится сравнение скорости разработки 30 лет и назад и сейчас, говорит, что сравнение идёт не в пользу нынешнего времени. Но в самой статье речь идёт о том, что само программирование изменилось. Теперь нужно больше использовать готовые компоненты и нельзя везде отказаться от них, как можно было раньше, потому что системы были компактней и проще, а, заодно, и могли меньше. С этой точки зрения, наоборот, современное сборочное программирование выигрывает по времени, хотя и не такое шустрое, как хотелось бы из-за мутных составляющих.
2.
Говорит, что у ООП парадигмы столько вариантов, что между ними нет ничего общего кроме названия. Это всё равно что сказать, что у животных столько вариантов, что между ними нет ничего общего кроме названия. Словно не знает, что такое определяющие признаки. И зачем-то приводит пример языка Elegant Objects, хотя это просто неработоспособный
мусор3.
Говорит о проблеме разрозненности систем и иронизирует над созданием многоплатформенных решений так, как-будто действительно возможно, чтобы люди объединились бы и перестали создавать разрозненные системы. Собственно, Вир - это пример ещё одной разрозненной системы и хотя она подразумевает объединение, это никак не спасёт от создания других плохо совместимых объединяющих
систем.
Направление - правильное, а цель -
нет.
4. Допускает удивительную как для компиляторщика
неточность про разные синтаксисы для одного языка, хотя сам и говорит, что разница на уровне лексического, а не синтаксического анализа. Споры о синтаксисе далеко не всегда сводятся лишь к противостоянию скобочек и ключевых слов, поэтому одним лишь лексическим анализом не обойтись. Бой идёт на уровне разных понятий, которые требуют
разного синтаксиса и, соответственно, разной семантики, которую нельзя так просто взять и объединить в одну систему.
5. Фактически,
говорит, что сборочное программирование - это сборка, а сборка - это не программирование. Сборочное программирование - это не программирование. В его терминологии, создание программ - это не программирование, но включает его.
Я, напротив, считаю, что удивительно много процессов, обычно понимаемых как разные - это программирование во всём его многообразии. Всем - по куче
ПОЯ,
алгоритмически полным и неполным, интерактивным и пакетным, текстовым и пиктографическим, визуальным и аудиальным, для машин и для людей, и т.д.
6. Объясняя,
почему не Компонентый Паскаль, говорит о том, что ББ - это framework, из-за чего его компоненты не переносимы, поэтому надо идти другим путём. Но не объясняет, почему Вир - это не framework со всеми вытекающими. Если Алексей решил проблему переносимости компонентов Вира за пределы Вира или обеспечил невесомость каркаса, обеспечивающего работоспособность всей системы Вира, то об этом было бы интересно узнать.
7. Вот тут и неясно, почему
явная схема - это не программа, а создание схемы - это не программирование. Программа, как по мне, это тоже явная схема, на скриптовом ли она языке написана, на обычном ли, или даже на языке явных схем.
8.
Защита от взлома. Интересно, как защищено от распространения уже докачанной после регистрации программы, например, в виртуальной машине?
9.
Легко поддерживать за счёт явной схемы. Это интересно, ведь со стороны непонятно, что даёт такой прирост по сравнению с программой - "явной схемой" на обычном языке программирования. Звучит как серебряная пуля, осталось воспроизвести этот эффект на стороне.
10. "
Язык интересует в последнюю очередь, поэтому делаем новый язык". По-моему, здесь Алексей попал в свою терминологическую ловушку, требующей утверждения, что явная схема программы - это не программа, а язык схемы - это не язык программирования. Я бы назвал его подход к ЯП как многоуровневое определение языка(модульное, если хотите), где каждый из уровней - это отдельный не обязательно алгоритмически полный язык программирования, являющийся составной частью уже алгоритмически полного. Такое разбиение на уровни предъявляет определённые требования к составным языкам, в том числе и языку 0-го уровня. Это одна из причин, почему другие языки не подходят, и нужно писать ещё один, хотя он, как утвеждается, и второстепенный. И это же одна из причин, почему другие языки не впишутся в Вир и идея о великом объединении не может сработать.
Неудивительно, также, что язык A0 был безтиповым. Это не просто "так получилось", а вполне закономерно. Из-за того, что связывание совершалось исключительно на уровне языка явных схем, а на представленном этапе его проектирования он не включал пользовательские типы, то и на уровне A0 им неоткуда было взяться. Набор предопределённых типов всё равно ничего бы не решал, особенно на том уровне проектирование компонент, где предопределённые типы встречаются, в основном, как составляющие пользовательских, а не напрямую.
Модульность в определении языка считаю правильным подходом.