Здравствуйте, CEMb, Вы писали:
CEM>Сила языка должна быть в том, что на нём можно легко и быстро разрабатывать
Разрабатывать легко на языках с "иерархически-ортогональной" структурой, где простые конструкции можно удобно комбинировать в сложные, и они не порождают ненужных зависимостей между собой. В C++ такое развитие наметилось в 80-х, но потом его поломали, и выправлять ситуацию, судя по всему, не собираются.
Здравствуйте, CEMb, Вы писали:
CEM>Ну, имелась ввиду активная позиция языка, а не просто что у нас есть N кода, и все (пока ещё) вынуждены его терпеть использовать
Когда появились Java и C#, то C++ был несколько заброшен, на нём мало начинали новых проектов. По прошествии времени стало понятно, что ни Java, ни C# не достигли тех вершин, что им пророчили и маятник ресурсов снова качнулся в сторону С++. Трудно сказать почему. Может из-за требований к ресурсам, может из-за совместимости с C, а может из-за естественного фильтра в уровне разработчиков. У меня при прочтении исходной статьи вообще сложилось впечатление, что она написана от лица каких-то "обиженок": ой-йой не дали поломать ABI ! Не понимаю: разве кто-то запрещает? Хотите ломать — ломайте, исходники открыты, а мы со стороны посмотрим. Если пойдёт к пользе дела, то и народ потянется... Зачем тут какая-то непонятная "активная позиция языка"?
CEM>На плюсах, на самом деле, тоже легко разрабатывать.
По сравнению с C — да, а вот по сравнению с C# — не уверен.
CEM>Просто получается, что: CEM>1. Часто чуть дольше, чем на той же яве, в общей массе потенциальных проектов. CEM>0. Спецов нету, которые умеют (убедить топов-идиотов что можно) быстро разрабатывать на плюсах CEM>Или я не прав?
Дольше или нет — зависит от уровня разработчиков, организации труда и сложности задачи. C++ не для простых задач.
Спецов нету, поэтому проект выйдет дороже или вообще не выйдет.
CEM>>>в том, сколько на нём сейчас разрабатывается, BFE>>Не разрабатывается, а используется. Есть очень много, чего разрабатывалось, а потом выкидывалось. CEM>А почему?
Деньги кончались раньше, чем продукт становился пригодным к использованию
CEM>>> в большом количестве преимуществ перед другими ЯП. BFE>>И преимущества эти выражаются в наличии стандарта. CEM>Бизнесу пофиг на стандарт, это только технари понимают, а бизнесу надо "как можно быстрее и дешевле".
Для малого бизнеса это так, а вот для большого...
Теоретически стандарт удешевляет разработку, так как не нужно учить диалект языка.
Стандарт позволяет в какой-то мере быть независимым от владельца языка. Тут показательна история с Java, когда штатовский суд запретил Microsoft разрабатывать свою (разумеется несовместимую, но главное свою) версию языка. Так появился C#.
CEM>Ну, мы-то понимаем, что в долгосрочной перспективе плюсы это как раз быстро и дёшево, но кроме нас сложно объяснить кому-то. Ну вот Яндех на плюсах пишет. Хуавей прям поклонники плюсов. Ну и всё, получается?
Я не знаю. Последний и текущий проект на котором я работаю — это изначально было переписывание с C# на C++.
Здравствуйте, vdimas, Вы писали:
V>Не "тем не менее", а "тем временем" появился стандарт С++0x и далее пошло кучно от версии C++11, что перевернуло игру. ))
Википедия говорит, что язык появился в 2001-ом, а Александреску присоединился к разработке в 2007-ом. Так что я бы всё таки настаивал на "тем не менее", потому что 10 лет это немалый срок. Хотя, если смотреть с другой стороны, Erlang тоже не нашёл своей славы, а ведь задумка и реализация были неплохими.
Здравствуйте, cppguard, Вы писали:
C>Википедия говорит, что язык появился в 2001-ом, а Александреску присоединился к разработке в 2007-ом.
А через пару лет заверте...:
С 2009 года велась работа по обновлению предыдущего стандарта. Предварительная версия называлась C++09, в следующем году её переименовали в C++0x.
C>Так что я бы всё таки настаивал на "тем не менее", потому что 10 лет это немалый срок.
Смотря как смотреть.
Если взять жабку и дотнет с кучей прикладных либ в стандартной поставке, то языки были готовы к массовому использованию сразу же изкаробки.
А которые "просто языки/компиляторы" — им требуется время, чтобы отрасль обросла либами, сделав эти языки привлекательными.
C>Хотя, если смотреть с другой стороны, Erlang тоже не нашёл своей славы, а ведь задумка и реализация были неплохими.
Слабая реализация виртуальной машинки.
Т.е. не только в самом языке дело, ведь Erlang — это язык-платформа.
В целом платформа вышла так себе... ))
Здравствуйте, cppguard, Вы писали:
C>Хотя, если смотреть с другой стороны, Erlang тоже не нашёл своей славы, а ведь задумка и реализация были неплохими.
У Erlang свои проблемы: косность core team (как бы она ни звалась), отказ от необходимых изменений (множественные очереди, JIT), который убил огромные потенциальные поля применения, наконец, лень "ширнармасс" делать по науке (его эти знаменитые обновления на ходу — вместо этого всё пакуют в контейнеры и рестартуют их).
Сравнивать с C++ малоосмысленно потому, что он как раз после долгого застоя, но сдвинулся и развивается.
Здравствуйте, Alekzander, Вы писали:
A>Я бы даже так сказал. Когда за развитием языка стояли компиляторщики (реальные инженеры), а не комитеты (дуболомы-астронавты), это была не "кривая реализация плюсов в этом моменте", а золотой век языка.
Я бы не сказал, что NVidia, Google, Bloomberg и Intel представляют дуболомов-астронавтов
Скорее это представители наиболее толстых пользователей (с десятками миллионов строк реальной высокоуровневой кодобазы).
И, естественно, они напрямую работают с авторами компиляторов, которые представлены тоже в комитете.
Чтобы это увидеть, достаточно посмотреть состав комитета, так что вы загнались.
Проблема не в этом, а в том, что эта наиболее влиятельная группа 1) реально представляет из себя лебедя, рака и щуку, так что проходит то, что устраивает всех, наиболее кривым путём, 2) они гоняются за долями процента, обеспечивая эффективность за счёт высокого уровня своих людей и поплёвывая с колокольни на массы тех, кто не способен нанимать высокоуровневый персонал и кому нужно, чтобы язык был более понятен средним "ширнармассам" без PhD.
Здравствуйте, netch80, Вы писали:
N>Сравнивать с C++ малоосмысленно потому, что он как раз после долгого застоя, но сдвинулся и развивается.
Мы тут с D сравниваем Который как раз имеет противоположную тенденцию — когда развивался, а сейчас непонятно, что с ним, и нужен ли он кому-то, когда в С++ уже скоро добавять вычисление вопроса жизни, смерти и всего остального на этапе компиляции.
Здравствуйте, cppguard, Вы писали:
C>Мы тут с D сравниваем Который как раз имеет противоположную тенденцию — когда развивался
Даже когда он развивался, то оказалось, что он мало кому нужен. Тогда мало кого интересовали нативные языки со сборкой мусора, Java и C#, а так же Python с Ruby рулили и педалили во всю. Это чуть позже, когда появился Go и контейнеризация приложений в Docker, внезапно (с) выяснилось, что маленькие нативные бинарники и программки на безопасном языке с GC, которые быстро компилируются -- это хорошо. Но когда это выяснилось, то оказалось, что D не способен в достаточной мере стабилизироваться, уже есть гораздо более простой Go с целым Google за спиной, да и C++ уже 14-го стандарта.
И да, говорю как человек, который всерьез рассматривал возможность съехать с C++ на D.
Так-то D развивается, это и по его ChangeLog-у видно. Просто широким массам он оказался не интересен. По совокупности целого ряда причин.
Здравствуйте, cppguard, Вы писали:
N>>Сравнивать с C++ малоосмысленно потому, что он как раз после долгого застоя, но сдвинулся и развивается. C>Мы тут с D сравниваем Который как раз имеет противоположную тенденцию — когда развивался, а сейчас непонятно, что с ним, и нужен ли он кому-то, когда в С++ уже скоро добавять вычисление вопроса жизни, смерти и всего остального на этапе компиляции.
Всё-таки это другое, и без (™). D просто не набрал ресурсов для запуска толком.
(Витки идеологии не считаю, это в какой-то мере у всех есть.)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Разрабатывать легко на языках с "иерархически-ортогональной" структурой, где простые конструкции можно удобно комбинировать в сложные, и они не порождают ненужных зависимостей между собой. В C++ такое развитие наметилось в 80-х, но потом его поломали, и выправлять ситуацию, судя по всему, не собираются.
Хз, смотря с чем сравнивать...
С нулевых использую шарп и плюсы примерно в равной степени, и как-то само собой так получается, что на плюсах удобней выражать ход мысли в куче небольших независимых типов, из которых потом собирается комбинаторика конечного решения.
Т.е., плюсы, ИМХО, наоборот, провоцируют на разбиение решения на большее кол-во задействованных типов/сущностей в процессе декомпозиции задачи и композиции затем решения.
Кстате, из-за многих удобных новых ср-в в шарпе вокруг value types, unmanaged-ограничений/параметров генериков, чисто-стековых типов и неплохого современного оптимизатора в JIT и AOT, похожий подход всё более использую и там, потому что дробление иерархий должно сопровождаться zero penalty, иначе теряется смысл в такой декомпозиции.
Т.е., не смотря даже на текущее состояние прикладных или каких-то там еще библиотек в плюсах, само это кач-во языка уже является killer feature, хотя, у самих плюсовиков оно воспринимается как должное и потому порой недооценённое. ))