Java против C# в 2022г.

в аду раю есть отдельный котел пляж для перегружающих операторы.

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

начнем с конца (тм)

Использование перегрузки функций делает фрагменты программы …

нет и не было ни у кого никогда никаких проблем с перегруженными функциями.

Шаблоны и дженерики

дженерики Java и шаблоны C++ внешне похожи только внешне. то, как это реализовано в крестах - расстрелять.

использование функций - зло

сову на глобус

Я как жабокодер соглашусь что это полезная штука, особенно для математики. В kotlin есть перезагрузка операторов, мне нравится этот язык, использую но т.к. в нем я числодробилки не писал то и перезагрузку операторов не встречал.

На Java больше пишут энтерпрайз, а там только перекладывание байтов из одного места в другое с очень простой бизнес логикой. И единственное место где там бы пригодилась перезагрузка операторов это операции с деньгами.

Тык что перезагрузка операторов это круто, но объективно погоды не делает.

А для математики и числодробилок в Java есть более приоритетные вещи которые нужно сделать, например финализация Vector API, и/или какой-нибудь эквивалент ffast-math в сишных компиллерах.

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

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

нет и не было ни у кого никогда никаких проблем с перегруженными функциями.

В том-то и дело, Кэп! Этих проблем нет, не было, и не будет, ровно как и нет, не было и не будет проблем с перегрузкой операторов - концепцией, знакомой даже каждому первокласснику! Можно сомневаться в том, что человек способен правильно назвать функцию, но гораздо сложнее сомневаться в том, что человек будет создавать перегрузку для оператора «+», которая будет делать умножение вместо сложения!

как это реализовано в крестах - расстрелять.

Дело в том, что мы не обсуждаем здесь кресты. Они убогие и масдай, как говорится (говорит вам человек, истративший 15 лет на кресты, далеко и глубоко разобравшийся в этом дерьмище)

Тык что перезагрузка операторов это круто, но объективно погоды не делает.

Ну если не ходить на улицу, то никогда не промокнешь под дождем. А если пишешь код, в котором математические формулы такие длинные и сложные, и ты видишь их в форме

a.minus(b).dot(n).div(n.dot(n))

то хочется блевать. А ведь формулы бывают посложнее.

А для математики и числодробилок в Java есть более приоритетные вещи которые нужно сделать, например финализация Vector API, и/или какой-нибудь эквивалент ffast-math в сишных компиллерах.

Сначала надо сделать эту математику, чтобы ее писать можно было, а если ее не пишут, то зачем им заморачиваться на поддержку вышеуказанных фич? Проблема курицы и яйца. Надо сразу добавить и то, и другое.

Я 10 лет писал энтерпрайз и почти никогда математику с bigdecimal, ну может быть один раз. Это слишком узкий кейс.

не поняли иронию

надо было читать одно сообщение за другим

пардон муа, читал по диагонали, с ч.ю. с утра проблемы

человек будет создавать перегрузку для оператора «+», которая будет делать умножение вместо сложения!

и не такое видеть приходилось. например + строки к соединению с бд выполнял соотв запрос. а если вам вдруг кажется, что это контринтуитивно это неважно, ибо аффтар был уверен в обратном. и такая дребедь повсеместно.

Сначала надо сделать эту математику, чтобы ее писать можно было, а если ее не пишут, то зачем им заморачиваться на поддержку вышеуказанных фич? Проблема курицы и яйца. Надо сразу добавить и то, и другое.

Не согласен. Язык должен меняться в последнюю очередь, потому как любые изменения языка уже не отыграть. А внутреннюю реализацию можно менять как угодно, главное ничего не сломать.

Посмотри как ужасно некрасиво написана работа с SIMD в сях и плюсах, никаких красивостей, все на макросах (Я сужу по коду на computer language benchmark).

формулы бывают посложнее.

для формул есть ЯП Wolfram, выразительный по самые гланды.

Посмотри как ужасно некрасиво написана работа с SIMD в сях и плюсах, никаких красивостей, все на макросах

В сях и плюсах нет SIMD вообще.

Есть лишь проработки, которые неизвестно когда будут в стандарте: https://en.cppreference.com/w/cpp/experimental/simd/simd

Там пользуются лишь встроенными функциями компилятора, которые в общем случае даже разные у разных компиляторов и используются в том числе для реализации стандартной библиотеки языка: https://docs.microsoft.com/en-us/cpp/intrinsics/compiler-intrinsics?view=msvc-170

Как обычно, чем гибче средство, тем больше можно накосячить.

Хороший пример перегрузки это Complex::operator+

Плохой stdin::operotor<<

для формул есть ЯП Wolfram, выразительный по самые гланды.

Ну так и для всякого, которое пишут на Java, есть Пухон, например. Зачем полумеры? Java вообще не нужен. Надо либо трусы надеть, либо крест снять. Нет логики в том, чтобы не добавить перегрузку операторов в Java. Либо тогда есть логика в том, чтобы писать на Cи-4-плюса, он же лучше, и не только потому, что там есть перегрузка операторов. Там есть LINQ, меняющий мировоззрение. Да много чего там нормально устроено, чай не C++, в котором даже reflection не могут осилить который год. Да что уж там, хоть бы enum в строку без простыней сконвертить!

гораздо сложнее сомневаться в том, что человек будет создавать перегрузку для оператора «+», которая будет делать умножение вместо сложения!

Ога, stdout::operator>> что-то не биты двигает, а занимается вводом выводом.

Ога, stdout::operator>> что-то не биты двигает, а занимается вводом выводом.

std это вообще дурдом.

Нет логики в том, чтобы не добавить перегрузку операторов в Java.

без перегрузки операторов жаба живет прекрасно.

облегчатель же написания формул можно вынести в отдельный и особый DSL, реализовать его при помощи Truffel на платформе GraalVM и все дела.

как и любой другой облегчатель написания.

во всяком случае такой подход выглядит более перспективным, чем запихивать в ЯП модификаторы самого ЯП реализуя чрезвычайную гибкость, плавно переходящую в бесформенную аморфность, из которой получается практически все, но по свойствам примерно как из навоза пуля.

Там есть LINQ, меняющий мировоззрение

среди бескрайних просторов java библиотек есть чудный Coolection

Стандартная библиотека с огромным количеством всего что может понадобиться для разработки.

В .NET больше. И нормально сделано, в отличие от(че стоит один только жабовский Date, за использование которого отрезают руки).

Батареек на каждый чих в репозитории больше чем у .NET

Нет. См. nuget

Нормальная кросс-платформенность из коробки, а не убогая MS-style «кросс-платформенность»

Нормальная там кроссплатформенность.

когда, например, GUI только под Windows.

Winforms/WPF? Там технологии Windows используются, внезапно, которые в красноглазии отсутствуют. Впрочем есть кроссплатформенные GUI типа Avalonia.

Высокий уровень з/п, наверное самый высокий из тех языков которые распространнены.

Платят не за язык. Вообще мимо кассы пункт.

Куча enterprise-ready фреймворков, тот же Spring.

1. Spring - говно.

2. В дотнете такого тоже навалом.

В .NET больше. И нормально сделано, в отличие от(че стоит один только жабовский Date, за использование которого отрезают руки).

Ложь. Меньше. И Date с Java 8 (вроде как) выправили.

Нет. См. nuget

Снова ложь:

29,681,686 indexed artifacts
9,647,941 indexed packages

https://mvnrepository.com/repos/central

vs.

4,771,846 package versions
322,280 unique packages

https://www.nuget.org/

Нормальная там кроссплатформенность.

Нет кросс-платформенного GUI в стандартной либе. Значительный минус, убогие хаброподелки вроде Avalonia ситуацию никак не исправляют.

Платят не за язык.

А за стек технологий. И именно для Java вакансий везде больше, чем для C#, а зарплаты всегда жирнее.

Нет кросс-платформенного GUI в стандартной либе.

Есть с 6 версии: https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui

Linux там нет, но может комьюнити что-то пилит, не знаю, код открыт.

В .NET больше. И нормально сделано, в отличие от

Чем csv читать и писать?

убогие хаброподелки вроде Avalonia

поделись своим впечатлением от авалонии

Spring - говно

расскажи в двух словах, почему спринг говно. он менее говно чем ларавель, джанго и т.п.?

Нет кросс-платформенного GUI в стандартной либе

свинг, я слышал, не умеет сам строить форму из XML. нет XML-дизайнера в комплекте самого свинга, следовательно нет возможности совмещать ручное редактирование XML с дизайнером. вроде бы как нет из коробки связывания состояния полей объектов с состоянием контролов. то есть свинг это допотопный тулкит.

И Date с Java 8 (вроде как) выправили.

Оно до сих пор есть ибо обратная совместимость. И активно используется например в ORM.

322,280 unique packages

Надо еще учитывать, что там:

а) Много заброшенных проектов, которые написаны до неткора, не кросплатформенные и на новом дотнете просто не будут работать

б) Много закрытых и платных библиотек. Например для манипуляции pdf все нормальные библиотеки именно такие (остальные - см. пункт а)

Собственно проблема дотнета в том, что как только сходишь с золотого microsoft vendored пути, могут начаться неприятности

у меня было стойкое чувство, что это продукт скрещивания плюсов и жабы

Было так - d 1996 M$ сделал IDE Visual J++ под руководством Хейлсберга (создателя Delphi). Visual J++ 6 была лучшая на тот момент IDE и Run-time для Java. Visual J++ позиционировали как среднее между Visual C++ и Visual Basic - то есть быстрое графическое создание приложений (формошлепство) и создание компонентов на языке более высокого уровня чем VB. Однако M$ по своему тогдашнему обычаю стал натягивать одеяло на себя, плюя на стандарты. M$ добавил в реализацию Visual J++ свою графическую библиотеку WFC (Windows Foundation Classes) как замену AWT/Swing на Windows, а также интегрировал в J++ (java) поддержку COM модели M$. Sun подало на M$ в суд за нарушение стандарта и выиграло дело. Тогда M$ создало на базе наработок VJ++ и Delphi свой продукт - платформу .Net, язык C# для программистов на Java и С++, а для разработчиков на VB - язык Visual Basic.Net, который был намного круче чем VB и в принципе повторял C#, но с синтаксисом Basic.

wait C# is just Microsoft Java

always has been

источник мема