Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Разрабатывать легко на языках с "иерархически-ортогональной" структурой, где простые конструкции можно удобно комбинировать в сложные, и они не порождают ненужных зависимостей между собой. В C++ такое развитие наметилось в 80-х, но потом его поломали, и выправлять ситуацию, судя по всему, не собираются.

хз, смотря с чем сравнивать...

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

Т.е., плюсы, ИМХО, наоборот, провоцируют на разбиение решения на большее кол-во задействованных типов/сущностей в процессе декомпозиции задачи и композиции затем решения.

Кстате, из-за многих удобных новых ср-в в шарпе вокруг value types, unmanaged-ограничений/параметров генериков, чисто-стековых типов и неплохого современного оптимизатора в JIT и AOT, похожий подход всё более использую и там, потому что дробление иерархий должно сопровождаться zero penalty, иначе теряется смысл в такой декомпозиции.

Т.е., не смотря даже на текущее состояние прикладных или каких-то там еще библиотек в плюсах, само это кач-во языка уже является killer feature, хотя, у самих плюсовиков оно воспринимается как должное и потому порой недооценённое. ))

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Разрабатывать легко на языках с "иерархически-ортогональной" структурой, где простые конструкции можно удобно комбинировать в сложные, и они не порождают ненужных зависимостей между собой. В C++ такое развитие наметилось в 80-х, но потом его поломали, и выправлять ситуацию, судя по всему, не собираются.

Хз, смотря с чем сравнивать...

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

Т.е., плюсы, ИМХО, наоборот, провоцируют на разбиение решения на большее кол-во задействованных типов/сущностей в процессе декомпозиции задачи и композиции затем решения.

Кстате, из-за многих удобных новых ср-в в шарпе вокруг value types, unmanaged-ограничений/параметров генериков, чисто-стековых типов и неплохого современного оптимизатора в JIT и AOT, похожий подход всё более использую и там, потому что дробление иерархий должно сопровождаться zero penalty, иначе теряется смысл в такой декомпозиции.

Т.е., не смотря даже на текущее состояние прикладных или каких-то там еще библиотек в плюсах, само это кач-во языка уже является killer feature, хотя, у самих плюсовиков оно воспринимается как должное и потому порой недооценённое. ))