Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>>>Да не обязательно CRTP — обычный std::partition_point это уже статический полиморфизм.
EP>>>·>Ну method overloading это тоже статический полиморфизм.
EP>>>Верно.
EP>>>·>Может внутренняя имплементация не так элегантна как в Плюсах, но Arrays.binarySearch внешне выглядит точно так же.
EP>>>Внешне Arrays.binarySearch выглядит как борьба с языком — ибо там ручная перегрузка на каждый тип, при видимо одинаковой реализации.
EP>·>О красоте можно потом поговорить. Так в чём же динамика? Всё ровно то же, что и в Плюсах пока.
EP>Ты сам привёл пример без динамики и теперь спрашиваешь в чём динамика.
Я лишь ответил на твой пример, что мол "обычный std::partition_point это уже статический полиморфизм." И зачем ты мне это рассказал? В java ровно то же.

EP>с большим количеством compile-time проверок проверок.
Да, ок. Кстати, к javac можно annotation processors писать, для большего кол-ва compile-time проверок.

EP>>>Речь про фактический код. Если в одной программе List<Object> и постоянные динамические касты, а в другой List<Derived> и никаких кастов — то первая более динамическая чем вторая. При этом речи о том что такой язык имеет динамическую типизацию не идёт — это всё та же статическая типизация.
EP>·>И к чему это тогда? И на Плюсах можно писать std::vector<void *>.
EP>В первых версиях Java это был единственный вариант, и поэтому использовали такие динамические построения, несмотря на то что в языке по прежнему была статическая типизации. Сейчас добавили, но это лишь один из примеров.
Это какой-то слабый аргумент. А вон в С++ был MFC и прочий ATL.

EP>·>В том то и дело, что даже в этом твоём понимании меняется динамичность конкретного написнного кода, а не самого языка. Формально-то как-то сможешь дать определение? "Динамичность языка — это...?" Можешь ссылку дать.
EP>Повторю то что сказал с самого начала:
Ну всё-таки. Хочется определения. Иначе получается "двуногое без перьев" — и доказывай что хошь.

EP>

EP>>Твой оппонент говорит о том (и с чем я согласен), что в коде на управляемых языках программисты как раз склонны к излишнему динамизму по сравнению с C++ — в котором например статический полиморфизм используется повсеместно.

EP>Возражения на этот тезис есть?
Я возражаю на счёт "склонны". Да, динамика пишется проще на Яве, поэтому её выбирают с более лёгким сердцем, но явно существуют программисты которые "не склонны" — это в основном зависит от самих программистов и решаемых задач, а не от ЯП. Но более "динамичным" язык это не делает. Хотя фиг знает что ты под этим понимаешь. Мне так никто толком значение этого термина не указал.

EP>·>А конкретнее? Вот у нас есть класс "class Person {String name;}". В рантайме мы генерим сериализатор в XML. Какие ошибки будут ловиться|не ловиться?
EP>Я же говорю: "ошибки вида сериализации не реализованных базовых типов". То есть например String может не поддерживаться.
А, понятно. Я под базовым типом почему-то подумал о наследовании. Да, такое не проверяется компилятором из коробки. А как Плюсы проверяют? (только без внешних тулзов и дополнительной разметки, плиз, иначе под явой можно просто запилить небольшой тест, инфраструктурный код или annotation processor, который проверит всё что надо во время билда).

EP>>>Но кодогенерация например на Python вообще проблемой не является, так как подключается элементарно (например CMake автоматом сгенерирует нужные правила что для MSVS, что для make, etc) — это ты пытаешься хоть к чему-нибудь придраться.
EP>·>Ну python на винде например обычно не стоит.
EP>Так он и не факт что на других OS стоит. Но при разработке обычно тот или иной язык скриптов всегда есть
И добавление кодогенерации — ещё один камушек в тяжелось инфраструктуры, когда как в java это тупо часть языка.

EP>·>Инфраструктура java — проще: скачал IDE, скачал исходник (с помошью этой же IDE) — готово. Вот собствено в этом и мой тезис. Неужели не согласен?
EP>Относительно кодогенерации (например на Python) — нет, не согласен — ибо ставится в одну команду package manager. А то что в общем кроссплатформенная инфраструктура со всеми зависимостями сложнее — так я это сам выше написал, буквально в сообщении на которое ты ответил — мне что опять себя цитировать?
Ну вот, это я и пытался доказать. А мне тут кто-то заявлял что java-инфраструктура сложнее и дороже.

EP>>>·>Ах. в этом смысле... Ты говоришь, как будто это что-то хорошее. static_cast даёт UB, и хорошо что нет.
EP>>>Я не говорю что это хорошее или плохое, я говорю что именно dynamic_cast в Java есть.
EP>·>Трудно сказать... Почему он именно dynamic? Там просто cast, и он работает не так как Плюсовый.
EP>В чём по-твоему отличие в контексте дискуссии?
В том-то и дело что нет отличия. И наличие каста не делает яву динамичнее.

EP>·>Неужели только потому, что падает в рантайме сразу, а не делает хз что как в Плюсах?
EP>На C++ в одной из форм вылетает исключение std::bad_cast, в другой nullptr.
Это же dynamic_cast... — опять доказываешь мне динамичность С++?

EP>·>Да, для Плюсов это "The C++ Standard", для джавы — JLS.
EP>>>И почему вообще нужно ограничиваться сферической "частью языка", когда для решения реальных проблем это не имеет значения?
EP>·>Имеет значение для надёжности решения, когда у тебя вдруг всё ВНЕЗАПНО не поломается со следующим минорным релизом компилятора|тулзов|етс.
EP>Я правильно тебя понял что все Maven'ы, IDE, и т.п. на помойку?
IDE — опциональны, можешь в emacs/vi пилить, можешь eclipse, можешь idea. Мавен/gradle — часть проекта (исходник) в котором указаны версии компонент и они сами выкачиваются, а не внешние зависимости, которые должны быть ручками установлены, разные версии в зависимости от операционки, правильной версии с правильными компонентами/етс.

EP>>>x64, x32, arm, pgo, constant propagation, etc, etc — тоже не часть языка, значит C++ "их не умеет"?
EP>>>Ну тогда он и нативный код не умеет — шах и мат
EP>·>Это реализации Стандарта.
EP>x64, x32, arm, pgo, constant propagation, etc, etc — это тоже реализация стандарта. Также как и JIT Cling
Ну, но не стандарт ведь.

EP>·>Притом от хорошей реализации требуется, что некая конструкция языка работает именно так как описано в стандарте, на всех этих платформах.
EP>·>Т.е. если ты пишешь "int i=2+2" — ты обязан получить i==4, иначе это не С++. То же и в Java. Пишешь ClassLoader.defineClass — он должен работать как описано в спеке. Как генерировать код в С++ — да никак, никто ничего в языке не обещает.
EP>Так там и про нативный код ничего нет

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>>>Да не обязательно CRTP — обычный std::partition_point это уже статический полиморфизм.
EP>>>·>Ну method overloading это тоже статический полиморфизм.
EP>>>Верно.
EP>>>·>Может внутренняя имплементация не так элегантна как в Плюсах, но Arrays.binarySearch внешне выглядит точно так же.
EP>>>Внешне Arrays.binarySearch выглядит как борьба с языком — ибо там ручная перегрузка на каждый тип, при видимо одинаковой реализации.
EP>·>О красоте можно потом поговорить. Так в чём же динамика? Всё ровно то же, что и в Плюсах пока.
EP>Ты сам привёл пример без динамики и теперь спрашиваешь в чём динамика.
Я лишь ответил на твой пример, что мол "обычный std::partition_point это уже статический полиморфизм." И зачем ты мне это рассказал? В java ровно то же.

EP>с большим количеством compile-time проверок проверок.
Да, ок. Кстати, к javac можно annotation processors писать, для большего кол-ва compile-time проверок.

EP>>>Речь про фактический код. Если в одной программе List<Object> и постоянные динамические касты, а в другой List<Derived> и никаких кастов — то первая более динамическая чем вторая. При этом речи о том что такой язык имеет динамическую типизацию не идёт — это всё та же статическая типизация.
EP>·>И к чему это тогда? И на Плюсах можно писать std::vector<void *>.
EP>В первых версиях Java это был единственный вариант, и поэтому использовали такие динамические построения, несмотря на то что в языке по прежнему была статическая типизации. Сейчас добавили, но это лишь один из примеров.
Это какой-то слабый аргумент. А вон в С++ был MFC и прочий ATL.

EP>·>В том то и дело, что даже в этом твоём понимании меняется динамичность конкретного написнного кода, а не самого языка. Формально-то как-то сможешь дать определение? "Динамичность языка — это...?" Можешь ссылку дать.
EP>Повторю то что сказал с самого начала:
Ну всё-таки. Хочется определения. Иначе получается "двуногое без перьев" — и доказывай что хошь.

EP>

EP>>Твой оппонент говорит о том (и с чем я согласен), что в коде на управляемых языках программисты как раз склонны к излишнему динамизму по сравнению с C++ — в котором например статический полиморфизм используется повсеместно.

EP>Возражения на этот тезис есть?
Я возражаю на счёт "склонны". Да, динамика пишется проще на Яве, поэтому её выбирают с более лёгким сердцем, но явно существуют программисты которые "не склонны" — это в основном зависит от самих программистов и решаемых задач, а не от ЯП. Но более "динамичным" язык это не делает. Хотя фиг знает что ты под этим понимаешь. Мне так никто толком значение этого термина не указал.

EP>·>А конкретнее? Вот у нас есть класс "class Person {String name;}". В рантайме мы генерим сериализатор в XML. Какие ошибки будут ловиться|не ловиться?
EP>Я же говорю: "ошибки вида сериализации не реализованных базовых типов". То есть например String может не поддерживаться.
А, понятно. Я под базовым типом почему-то подумал о наследовании. Да, такое не проверяется компилятором из коробки. А как Плюсы проверяют? (только без внешних тулзов и дополнительной разметки, плиз, иначе под явой можно просто запилить небольшой тест, инфраструктурный код или annotation processor, который проверит всё что надо во время билда).

EP>>>Но кодогенерация например на Python вообще проблемой не является, так как подключается элементарно (например CMake автоматом сгенерирует нужные правила что для MSVS, что для make, etc) — это ты пытаешься хоть к чему-нибудь придраться.
EP>·>Ну python на винде например обычно не стоит.
EP>Так он и не факт что на других OS стоит. Но при разработке обычно тот или иной язык скриптов всегда есть
И добавление кодогенерации — ещё один камушек в тяжелось инфраструктуры, когда как в java это тупо часть языка.

EP>·>Инфраструктура java — проще: скачал IDE, скачал исходник (с помошью этой же IDE) — готово. Вот собствено в этом и мой тезис. Неужели не согласен?
EP>Относительно кодогенерации (например на Python) — нет, не согласен — ибо ставится в одну команду package manager. А то что в общем кроссплатформенная инфраструктура со всеми зависимостями сложнее — так я это сам выше написал, буквально в сообщении на которое ты ответил — мне что опять себя цитировать?
Ну вот, это я и пытался доказать. А мне тут кто-то заявлял что java-инфраструктура сложнее и дороже.

EP>>>·>Ах. в этом смысле... Ты говоришь, как будто это что-то хорошее. static_cast даёт UB, и хорошо что нет.
EP>>>Я не говорю что это хорошее или плохое, я говорю что именно dynamic_cast в Java есть.
EP>·>Трудно сказать... Почему он именно dynamic? Там просто cast, и он работает не так как Плюсовый.
EP>В чём по-твоему отличие в контексте дискуссии?
В том-то и дело что нет отличия. И наличие каста не делает яву динамичнее.

EP>·>Неужели только потому, что падает в рантайме сразу, а не делает хз что как в Плюсах?
EP>На C++ в одной из форм вылетает исключение std::bad_cast, в другой nullptr.
Это же dynamic_cast... — опять доказываешь мне динамичность С++?

EP>·>Да, для Плюсов это "The C++ Standard", для джавы — JLS.
EP>>>И почему вообще нужно ограничиваться сферической "частью языка", когда для решения реальных проблем это не имеет значения?
EP>·>Имеет значение для надёжности решения, когда у тебя вдруг всё ВНЕЗАПНО не поломается со следующим минорным релизом компилятора|тулзов|етс.
EP>Я правильно тебя понял что все Maven'ы, IDE, и т.п. на помойку?
IDE — опциональны, можешь в emacs/vi пилить, можешь eclipse, можешь idea. Мавен/gradle — часть проекта (исходник) в котором указаны версии компонент и они сами выкачиваются, а не внешние зависимости, которые должны быть ручками установлены, разные версии в зависимости от операционки, правильной версии с правильными компонентами/етс.

EP>>>x64, x32, arm, pgo, constant propagation, etc, etc — тоже не часть языка, значит C++ "их не умеет"?
EP>>>Ну тогда он и нативный код не умеет — шах и мат
EP>·>Это реализации Стандарта.
EP>x64, x32, arm, pgo, constant propagation, etc, etc — это тоже реализация стандарта. Также как и JIT Cling
Ну, но не стандарт ведь.

EP>·>Притом от хорошей реализации требуется, что некая конструкция языка работает именно так как описано в стандарте, на всех этих платформах.
EP>·>Т.е. если ты пишешь "int i=2+2" — ты обязан получить i==4, иначе это не С++. То же и в Java. Пишешь ClassLoader.defineClass — он должен работать как описано в спеке. Как генерировать код в С++ — да никак, никто ничего в языке не обещает.
EP>Так там и про нативный код ничего нет
И, как ни странно, C++ и не обязан в нативный код компиляться. Что не так-то?