Сергей Прохоренко писал(а):
... язык программирования и структурный редактор должны заставлять проектировать правильно. Если нет возможности спроектировать неправильно, то никто ею и не воспользуется.
Средства разработки могут помочь в выполнении формальных правил, но заставить проектировать правильно не в их силах. Если бы они [средства] знали, как правильно, то... проектировщики, очевидно, были бы не нужны...
Сергей Прохоренко писал(а):
Илья Ермаков писал(а):
"Вынести" обычные ЯП не получится.
Получится. Аргументов можно привести много:
Хорошо... посмотрим.
Сергей Прохоренко писал(а):
1. Если честно посмотреть на вещи, то сейчас нет по-настоящему универсальных языков программирования. Все они фактически специализированные. Хочешь сделать веб-сервер – используй Erlang. Хочешь веб-интерфейс – не обойтись без JavaScript. Хочешь делать корпоративные приложения – без Java никуда. А если нужна "числодробилка" или драйверы – C/C++. А потребность в универсальном языке есть, что подтверждается появлением новых гибридных языков. Очевидно, что прорыв в этом направлении уже невозможно осуществить на традиционной текстовой основе программного кода – достигнут «потолок» в развитии этой технологии.
Гибридизация языков никак не способствует их же универсальности... и популярности... Кроме того, частота появления новых языков не снижается, что также не способствует появлению "универсальных" языков.
Наконец, текстовая основа просуществует ещё достаточно долго, в силу своих качеств: 1. доступности; 2. распространённости; 3. понятности. Формирование иных не-текстовых образов - процесс достаточно долгий и противоречивый (столкновение множества субъективных точек зрения не порождает объективную (универсальную) точку зрения... и даже не способствует этому... как правило (это можно легко проследить по обсуждениям острых вопросов на форумах, например)).
Сергей Прохоренко писал(а):
2. Ракеты и самолеты продолжают падать по вине управляющих программ. И существование КП по факту никак этому не воспрепятствовало - в этих ракетах и самолетах его просто не применяли.
Это не аргумент...
Сергей Прохоренко писал(а):
3. В программировании еще слишком много шаманства и искусства в противовес науке и инженерии.
Почему одно [наука и инженерия] должно подменять другое [шаманство и искусство]?.. Шаманство и искусство неизбежны при осознании и создании нового. Наука нужна для формализации (осознанного или созданного) нового, инженерия необходима при использовании формализмов, полученных наукой. Если мы формализуем "всё и вся"... то развитие полностью прекратится. С другой стороны, конечно, глупо не пытаться осмыслить новое, то есть глупо отказываться от формализации. То есть, нужен поиск оптимума, а не система противовесов.
Сергей Прохоренко писал(а):
Минимизация языка программирования – тоже не панацея. Для программирования высокоуровневых конструкций на минимальном языке придется использовать изощренные приемы и писать много кода.
Попробую поделится наблюдениями... Если взять всего две базовых конструкции: присваивание и сравнение (как частный случай арифметики), то этого вполне достаточно для написания программ... но трудоёмко. Чтобы снизить трудозатраты, дадим возможность создавать и поименовывать комплексы/агрегаты из этих двух конструкций - макроопределения. Трудозатраты снизятся примерно в 1000 раз при росте многообразия примерно в 100 раз. Введём правила создания макросов, например, правила структурного программирования (описание и построение минимального количества оптимальных/универсальных комплексов)... трудозатраты на разработку программ снизятся ещё в 10...100 раз, а многообразие уменьшится примерно в те же 10...100 раз.
Вообще, вопрос минимизации количества типов элементов является очень интересным с точки зрения семантики систем. И любая(!) большая система (более 4-х уровней), образует ромб, где повышение многообразия сменяется его уменьшением... и всё это происходит не случайно, а вполне закономерно...
Сергей Прохоренко писал(а):
4. Затраты на отладку, внедрение и сопровождение программ просто немыслимые, и во многом вина за это лежит на архитектуре программ, которую диктуют средства программирования.
Средства (любые, а не только разработки программ) могут накладывать ограничения, но диктовать архитектуру... это из области утопий (в том смысле, что архитектор придумал такую архитектуру, которую выстроить с помощью доступных средств/технологий нереально... а-ля, крыша без опоры). Поэтому перекладывание проблем архитектуры на средства разработки - некорректно.
Сергей Прохоренко писал(а):
5. Вытеснение одних языков программирования другими приводит к огромным издержкам по поддержанию или замене унаследованного кода и обучению новым языкам, хотя в своей основе все языки программирования имеют много общего. Зачем изучать новый синтаксис, если графически всё можно изобразить одним способом?
В таком случае, и текстом можно описать одним способом (если графика формализована... а она в данном случае должна быть формальной). С другой стороны, если появится одно графическое средство, то... их тут же станет много... поскольку появится множество желающих продвинуть свой вариант графической нотации. Это всё уже многократно повторялось и в новых языках, и в новых ОС, и в новых СУБД и пр. и пр.
Другими словами, этот аргумент вызывает большие сомнения.