Несмотря на моё ворчание в опыте настоящего программирования я не могу не восхищаться объемом работы, проделанной ребятами из Мармелада.
Особенно потому, что эта работа «сизифова» — попытка сделать некое достаточно общее пересечение нескольких расползающихся сущностей. Как правило, построенное пересечение оказывается слишком мало для практических задач, и приходится быстро бежать хотя бы для того, чтобы остаться на месте.
Очевидная и принципиальная ошибка в подходе Мармелада заключается в том, что разработка, которая должна быть основой – фундаментом, делается сверху – как крыша. Дом, перевернутый вверх ногами, не очень устойчив.
Вторая проблема, которая наглядно видна из приведенного примера, это проблема не Мармелада, а всего современного программирования – это то, что мы считаем, что мы программируем на языках программирования. Это давно уже не так, программируем мы, большей частью, на библиотеках, фреймворках, билд системах, но почему-то до сих пор уделяем языкам программирование особое внимание.
На мой взгляд, язык программирования должен быть всего лишь:
- Инструментом для создания компонент нижнего уровня
- Средством для сборки компонент в компоненту более высокого уровня (и так до приложения).
При этом во время сборки должно быть не существенно, на каком языке написана компонента – на том, на котором удобнее (быстрее, производительней) написать эту компоненту. Для сборки важны разъемы, а не внутреннее устройство.
Для того, чтобы перейти к сборочному программированию нужны не языки, а «лексикон» программирования, состоящий из компонент и способов их соединения (стандартов, протоколов, разъемов, инструментов сборки и верификации).
Собственно, в своих ворчалках, я пытаюсь продвинутся в сторону «лексикона», начиная с простейших уровней.
Постоянная ссылка
«мы считаем, что мы программируем на языках программирования. Это давно уже не так, программируем мы, большей частью, на библиотеках, фреймворках, билд системах, но почему-то до сих пор уделяем языкам программирование особое внимание»
Уделяем потому, что библиотеки, фреймворки и билд системы обусловлены языками. Продолжая аналогию с постройкой дома, Вы пытаетесь объединить блоки из кирпича, соломы и мрамора, говоря что с нашего уровня абстракции это не важно. Здесь для удобства можно соломку постелить, а здесь поставить гигантские колонны из цельных кусков мрамора. В действительности же, несмотря на то, что с высоты построенной башни, может быть не видно фундамента, он во многом и определяет что мы сможем построить и что не сможем, что сможем объединить, а что — нет.
Постоянная ссылка
А кто против того, чтобы уделять внимание фундаменту?
Только это не языки программирования, языки — это пена.
Если мы взглянем с высоты, то увидим, что есть около десятка «парадигм» и сотни языков, воплощающих каждый со своей кривизной ту или иную (или несколько) парадигм.
Надо уделять внимание парадигме, а не языкам — это первый уровень.
Солома/бетон — нужно и то и то. Какие-то компоненты всегда будут несовместимы по сути, но сейчас это дико осложнено тем, что большинство компонент (или групп компонент) — даже те, что по сути должны быть совместимы, являются несовместимыми из-за мусора, косметики, семантического «сахара» и т.д.
Постоянная ссылка
Язык и есть парадигма. Объединение парадигм порождает другую парадигму-язык — синтезированную. Большинство используемых на практике языков в этом отношении синтетические.
Если устранить несовместимости языков из-за мусора, косметики и семантического сахара, то, фактически, прийдём к новому языку. И от программирования на языке никуда не деться, просто это будет другой язык. Отличия в терминалах или нетекстовых представлениях не так существенны.
Материал будет напрямую влиять на то, что строится. Если разработчик захочет строить гигантское строение из соломы, это будет что-то вроде пирамиды. Из бетона можно построить что-то более серьёзное. А выбирать материал прийдётся исходя из того, что есть. Вот и делают всякие мармелады такими, какими они могут быть, а не такими, какими могли бы быть, если бы все друг с другом договорились об устранении мусора несовместимости.
Постоянная ссылка
«Язык и есть парадигма» — дальше читать нет смысла.
А вам стоит начать с самообразования.
Желательно с основ, например:
https://ru.wikipedia.org/wiki/Парадигма_программирования
Постоянная ссылка
Я некорректно выразился. Правильней было бы сказать «парадигма — это и есть ЯП». Это можно было бы понять из той части сообщения, которую «дальше можно не читать». Подумаете над этим или нужно объяснять?
Постоянная ссылка
Упорство в своих заблуждениях – наверно, это хорошо. Это же полезно быть упорным?
Ладно, ликбез…
Возьмем пару языков, например, C++ и Java, чтобы глубоко не лезть. И посмотрим на них на самом верхнем уровне, чтобы определить парадигму, то есть «совокупность идеи и понятий».
Для чего? Мы же не теорией занимаемся?
Для того чтобы разделить языки на группы, для каждой группы выделить семантическое ядро. А потом подумать о том, как же можно все это богатство использовать на пользу и не дублировать то, что уже написано.
А для этого, надо языки одной группы еще больше сблизить, чтобы не было проблемы взаимодействия, а для взаимодействия между разными группами создать/определить «переходники».
Итак, надо выделить основное и выявить проблемы взаимодействия.
Естественно, что при этом не надо лезть в детали, не надо смотреть на синтаксис, на то, какие есть описания, операторы, операции и все остальное. Вообще нет смысла смотреть на текст программ, надо смотреть на исполнение программ.
Смотрим:
1) Вид языка: С++ — императивный, Java – императивный
2) Поддержка компонент: С++ — отсутствует, Java – отсутствует (или очень невнятная)
3) Поддержка объектов: C++ — ужасный CLOP, Java – просто CLOP
4) Вид кода: С++ — native, Java – bytecode
5) Управление памятью: С++ — ручное (no GC), Java – GC
Этого уже достаточно, мы обнаружили, что эти языки по двум существенным признакам относятся к разным парадигмам (семантическим ядрам) – это вид кода и управление памятью.
Постоянная ссылка
Уточняю на всякий случай…
Предыдущее замечание — это небольшая иллюстрация, показывающая отличие парадигмы от языка программирования.