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

vsb>LINQ — недо-SQL, недо-ORM в языке. Не нужно.

Одна из лучших фич языка. Удобство работы с объектами гигантское.
Может и как замена SQL — но это не главное его использование.

vsb>вместо двух строчек. Не нужно.

Нужно. Отличная читаемость кода.


vsb>Вот в Java хорошо. Никаких новых фич. switch 10 лет расширяют тривиальными улучшениями

Да-да, и дженерики не нужны. Когда выбирал на какой язык перейти — именно из-за этого послал Джаву. Смотрелась говном мамонта еще в конце 00-х.

vsb> то вот потоки зелёные делают, в стандартную библиотеку какие-то методы новые потихоньку добавляют

Трудноюзабельное говно, на которое жалуются джависты, вкусившие сшарп.

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



_>Тот кому надо быстро наговнятькать — возьмет питон или php, то что будет тормозить на питоне перепишет на го. Тот кому нужен ынтерпрайз возьмет java/kotlin где либов просто ворох всяких разных и коммьюнити очень большое.

Java просто убога по сравнению с C# и отставала от него на лет 10. Котлин — как попытка как раз симбиоза между джава и шарпами.

_> Разве что только альтернатива джава/котлин?

Любой тырпрайз. Не говоря уже о том, что средний прогер на C# стоит дешевле, при этом экосистемы и тулинг продвинутые.

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

C>

C>DoSomething(new(something, new(somethingElse)), new(wtfIsThat))
C>

C>Особенно весело, когда там перегруженные методы и опциональные параметры. Вот и сиди чеши репу, пытаясь понять, что там за параметры.

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

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

IT>Даже C# был переписан через 10 лет его существования с нуля

Однако ж. Я о таком не знал. А чего они тогда его нормальным не сделали, если уж с нуля переписали?

Нормальным в том смысле, о котором на этом форуме уже 20 лет говорят всякие сторонники ФП.

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

vsb>Вот в Java хорошо. Никаких новых фич. switch 10 лет расширяют тривиальными улучшениями (по-мне тоже не нужно, но видимо у дизайнера джавы детская травма, связанная с ADT, поэтому он их потихоньку и тянет в язык). А так все улучшения тупо на уровне JVM, то GC новый придумают, то вот потоки зелёные делают, в стандартную библиотеку какие-то методы новые потихоньку добавляют, по сути последнее фундаментальное обновление языка было в 5 версии 20 лет назад.

Может я чего не знаю, но меня удивляет, что для явы есть коммерческие GC, более высокопроизводительные, чем стандартный. А для .CLR нету.

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

IT>Да я уже понял. 300 строк — максимальный размер твоего проекта.

Не совсем в тему, но тут у меня проект есть, 40 мегабайт исходников, ~3300 файлов .cs

И вот как выглядит один из них

        public AccountManagementBO()
        {
            AccountTypeConfigurationBo = (AccountTypeConfigurationBO)BusinessObjectFactory.GetBusinessObject(typeof(AccountTypeConfigurationBO));
            AccountManagementDao = (AccountManagementDAO)DataAccessObjectFactory.GetDataAccessObject(typeof(AccountManagementDAO));
            accesManagerDao = (AccessManagerDao)DataAccessObjectFactory.GetDataAccessObject(typeof(AccessManagerDao));

Это у них вместо DI-контейнера. А если вдруг ты напишешь GetBusinessObject для получения DataAccessObject, то оно скомпилируется, но упадёт в рантайме.

Зря этим людям IDE дали, по-моему. Без IDE oни бы столько кубокилометров мусора не понаписали.

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

FLY>>AddItem(new("foo", 123, false));
·>Это осложняет жизнь разработчикам библиотек и пользователям. Допустим, есть CoolLib v1.0 с таким методом void AddItem(SimpleItem item). Уже становится невозможно просто добавить void AddItem(SpecialItem item) в CoolLib v1.1 не сломав совместимость.
·>Т.е. overloading стал неюзабельным.

Вот правильно в Rust этот overloading вообще запретили.

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

ET>ну так есть команда, ей же надо что-то делать,чтобы народ видел фичи новые идут.

Могли бы, например, добавить объявление классов прямо внутри метода.

Зачем это нужно: иногда надо внутри одного класса передавать не-примитивные данные между методами. То есть, не Task<int>, а Task<XXX>, где у XXX имеется несколько именованных полей. Да, можно написать Task<(string, int, string)>, можно ещё чего-нибудь такое же изобрести. Но внутри метода можно написать:

var r = new 
{
    Name = "",
    Amount = 148.8,
    IsVerified = false
}

А вот return r уже нельзя. Хорошо бы иметь возможность написать что-то в духе var r = newclass classname(public|internal|private).

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

IT>>Да я уже понял. 300 строк — максимальный размер твоего проекта.
ET>вещи которые автор написал усложняют чтение кода.

Те же самые вещи:

Dictionary<(int code,string value, List<MyCodeValueContainerBlaBlaBla>)> dic = new Dictionary<(int code,string value, List<MyCodeValueContainerBlaBlaBla>)>();

vs

Dictionary<(int code,string value, List<MyCodeValueContainerBlaBlaBla>)> dic = new();

Тут явно есть некоторая разница. Не находишь?

ET>Зависеть от IDE так себе идея, часто они глючат, не говоря уже про подсказки в них.

Это не идея. Это правда жизни. У меня один товарищ пользует Ryder, потому что он очень шустро работает с проектом в 700k строк и в там очень шутсрая навигация. Но в тоже самое время он пользует студию, потому что там лучше отладчик и поддержка WPF. Варианта notepad из-за глюков райдера и студии он не рассматривает.

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

IT>>Даже C# был переписан через 10 лет его существования с нуля
С>Однако ж. Я о таком не знал.

Пообщайся с нашими MVP-шниками: AVK, Sinclair, golumn, IB. Они тебе многое расскажут.

С>А чего они тогда его нормальным не сделали, если уж с нуля переписали?

Потому что люди решают те задачи, до которых они доросли на тот момент, когда перед ними встают конкретные и понятные им проблемы. Если ты не понимаешь будущих проблем и не можешь их предсказать, то для тебя они не существуют и закладки для их решения в архитектуру не закладываются. А потом уже поздно. К сожалению архитектура — это то, что в будущем практически невозможно поменять.

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

С>Это у них вместо DI-контейнера.
С>Зря этим людям IDE дали, по-моему. Без IDE oни бы столько кубокилометров мусора не понаписали.

IoС контейнер — это очень злобное решение само по себе. Корень зла здесь в том, что программист отказывается от тех проверок, которые компилятор (внимение! компилятор, а не IDE) выполняет автоматически. IDE тут вообще ни при чём. Наоборот, продвинутые IDE пытаются в таких ситуациях подсказывать и выполнять работу компилятора, но это либо у них не очень получается, либо тупо игнорируется. Ведь некоторые программисты умнее и компилятора и IDE, поэтому пихают IoC контейнеры везде, где только можно только потому, что могут.

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

С>>Это у них вместо DI-контейнера.
С>>Зря этим людям IDE дали, по-моему. Без IDE oни бы столько кубокилометров мусора не понаписали.

IT>IoС контейнер — это очень злобное решение само по себе. Корень зла здесь в том, что программист отказывается от тех проверок, которые компилятор (внимение! компилятор, а не IDE) выполняет автоматически. IDE тут вообще ни при чём. Наоборот, продвинутые IDE пытаются в таких ситуациях подсказывать и выполнять работу компилятора, но это либо у них не очень получается, либо тупо игнорируется. Ведь некоторые программисты умнее и компилятора и IDE, поэтому пихают IoC контейнеры везде, где только можно только потому, что могут.

Я не совсем понимаю ваши возражения. Как раз в приведённом мной участке кода проверка компилятора отсутствует. В случае IoC тут на вход прилетали бы нужные интерфейсы, безо всякого приведения типов. Как раз с контролем компилятора.

И работоспособность всего дерева зависимостей в IoC можно проверить одним тестом.

Наконец, в случае наличия тут IoC, этот код было бы гораздо проще улучшать. Например, сейчас там сервис(1) при отработке запроса обращается к самому себе, но в другом экземпляре(2), через WCF, оттуда запрос идёт по REST в ещё некоторые сервисы, и по MQ в неизвестные сервисы, и из них уже запрос, его часть, может прилететь обратно в(1), через MQ. Ко всему этому счастью надо бы добавить correlation id, чтобы понимать, где что падает (а оно падает). Для этого в IoC можно было бы просто добавить один интерфейс на уровне scope, для каждого отдельного запроса, и прозрачно пробросить этот id до самых вызовов внешних сервисов. А в имеющемся рукопашном коде такого сделать просто нельзя, только вручную. Для ручного прокидывания придётся править сигнатуры примерно 5000 методов.

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

IT>Здравствуйте, e.thrash, Вы писали:

IT>>>Да я уже понял. 300 строк — максимальный размер твоего проекта.
ET>>вещи которые автор написал усложняют чтение кода.

IT>Те же самые вещи:

IT>

IT>Dictionary<(int code,string value, List<MyCodeValueContainerBlaBlaBla>)> dic = new Dictionary<(int code,string value, List<MyCodeValueContainerBlaBlaBla>)>();
IT>

IT>vs

IT>

IT>Dictionary<(int code,string value, List<MyCodeValueContainerBlaBlaBla>)> dic = new();
IT>

IT>Тут явно есть некоторая разница. Не находишь?

тут лаконичнее, да, но ведь есть var если надо короче писать.

ET>>Зависеть от IDE так себе идея, часто они глючат, не говоря уже про подсказки в них.

IT>Это не идея. Это правда жизни. У меня один товарищ пользует Ryder, потому что он очень шустро работает с проектом в 700k строк и в там очень шутсрая навигация. Но в тоже самое время он пользует студию, потому что там лучше отладчик и поддержка WPF. Варианта notepad из-за глюков райдера и студии он не рассматривает.

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

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

C>Здравствуйте, _NN_, Вы писали:

_NN>>Новый синтаксис позволяет создавать Span без аллокаций чего нельзя было бы сделать используя new Span<int>(new int{] {...}).

C>Расшифруй.

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

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

https://devblogs.microsoft.com/dotnet/refactor-your-code-with-collection-expressions/

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-12.0/collection-expressions#motivation



_NN>>А как надо было бы ?
_NN>>Вон в Java есть аналогичная возможность и вроде не жалуются.

C>Не знаю, как там в Яве. Расскажи.

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

vsb>>Вот в Java хорошо. Никаких новых фич. switch 10 лет расширяют тривиальными улучшениями (по-мне тоже не нужно, но видимо у дизайнера джавы детская травма, связанная с ADT, поэтому он их потихоньку и тянет в язык). А так все улучшения тупо на уровне JVM, то GC новый придумают, то вот потоки зелёные делают, в стандартную библиотеку какие-то методы новые потихоньку добавляют, по сути последнее фундаментальное обновление языка было в 5 версии 20 лет назад.
С>Может я чего не знаю, но меня удивляет, что для явы есть коммерческие GC, более высокопроизводительные, чем стандартный.
Нет такого абстрактного самого высокопроизовдительного. Есть заточенные под определённые условия использования.

С>А для .CLR нету.
Потому что серьёзный софт для него не пишут, а для типичных ниш вроде веба или гуи, где на производительность пофиг — это нафиг не впёрлось.

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

FLY>>>AddItem(new("foo", 123, false));
С>·>Это осложняет жизнь разработчикам библиотек и пользователям. Допустим, есть CoolLib v1.0 с таким методом void AddItem(SimpleItem item). Уже становится невозможно просто добавить void AddItem(SpecialItem item) в CoolLib v1.1 не сломав совместимость.
С>·>Т.е. overloading стал неюзабельным.
С>Вот правильно в Rust этот overloading вообще запретили.
Ты решил посравнивать тёплое с мягким? В Rust и new запретили, зато есть traits, макросы и ещё чего я не знаю для замены overloading.

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

IT>Те же самые вещи:

IT>

IT>Dictionary<(int code,string value, List<MyCodeValueContainerBlaBlaBla>)> dic = new Dictionary<(int code,string value, List<MyCodeValueContainerBlaBlaBla>)>();
IT>

IT>vs

IT>

IT>Dictionary<(int code,string value, List<MyCodeValueContainerBlaBlaBla>)> dic = new();
IT>

IT>Тут явно есть некоторая разница. Не находишь?
Так надо телегу за лошадью ставить, тогда всё просто:

var dic = new Dictionary<(int code,string value, List<MyCodeValueContainerBlaBlaBla>)>();

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

C>Тяп-ляп, заплатка на заплатку, никакой продуманности, никакой целостности дизайна.

Лучше если бы полностью переделывали всё? Целостность дизайна того стоит?

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

wl.>а чужой код вообще не читаешь?
wl.>Кстати, оффтопом, я считал, что Python простой язык, но посмотрел, как параметры функций объявляются, и понял, что даже там всё не просто:

wl.>def func(*args):
wl.>def func(**kwargs):
wl.>def func(a, b, /, c):
wl.>def func(a, b=5):

Серъезно? Вот это вот сложно?

Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, wl., Вы писали:

wl.>>а чужой код вообще не читаешь?
wl.>>Кстати, оффтопом, я считал, что Python простой язык, но посмотрел, как параметры функций объявляются, и понял, что даже там всё не просто:

wl.>>def func(*args):
wl.>>def func(**kwargs):
wl.>>def func(a, b, /, c):
wl.>>def func(a, b=5):

КБ>Серъезно? Вот это вот сложно?

кроме 4-го варианта, который встречается в том же C++, понять, что означает третий вариант без подсказки из зала (от chatgpt) сходу не получилось