Здравствуйте, Pzz, Вы писали:
Pzz>Очень маловероятно, чтобы в новом проекте, не отягощенном наследственностью, в бы выбрал в качестве основного языка C++. Pzz>Так что на мой взгляд, это скорее C++ умер, а не C. Разлагатся он будет, конечно, еще очень долго.
Если посмотреть, то всякие производительные библиотеки постоянно начинают писать на плюсах и нормально пишут. Потом для них пишут обёртки на Питоне и отдают математикам и data scientist'ам. С++ под капотом очень многих современных разработок, которые потом крутятся в том числе и на кластерах под управлением уже упоминавшегося Питона, но не только. И Альтернатив для плюсов тут не видно, никто ни на чём другом их и не пишет. Хотя новые языки разрабатываются под это дело регулярно.
S>> А то, что с непривычки не удобно, так менять мышление надо. CC>И опять напомню про Perl
Вот не надо сравнивать с перлом и регулярными выражениями!
Что тут непонятно? все прекрасно читается!
public int F() =>
(A is B b) && (b.C is C)
? C.D ?? 1
:FalseToNet ;
и солнце б утром не вставало, когда бы не было меня
S>>>Можно всю жизнь программировать на Шарпе и не знать про ключевое слово `yield`. И не просто программировать, а продуктивно. Y>>Только если програмировать в одиночку. А иначе молодые и горячие коллеги непременно ознакомят со всеми новейшими свистками и звночками.
S>Не соглашусь.
S>Это не свисток и не звонок, это языковой функционал, нужный для… как бы его назвать… менее прикладного кода (более системного или более хелперного). Перефразируя старый фильм, в командах может быть два типа людей, мой друг: одни заряжают yield, другие пользуются foreach.
Значит, у нас разный опыт. Я давно уже не сталкивался с теми, кто не использует yield, притом во вполне прикладном коде.
Здравствуйте, yenik, Вы писали:
Y>Значит, у нас разный опыт. Я давно уже не сталкивался с теми, кто не использует yield, притом во вполне прикладном коде.
Как я понимаю, yield тут только в качестве примера. Слово такое.
Могу привести другой пример, правда, ретроградский и из Фортрана. В нем есто несколько типов GOTO: безусловный, вычисляемый, назначаемый. О двух последних я знаю только то, что они существуют. Сам, когда работал на Фортране, их не использовал никогда. В реальном коде видел, может, дважды за всю жизнь.
Подобные редко используемые вещи можно найти в любом языке. В шарпе тоже.
Здравствуйте, mrTwister, Вы писали:
vsb>>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
T>Бери GO
Да, прикольный язык, если бы я сейчас начинал, возможно это был бы хороший совет, а так с 10 лет опыта на жаве уже сложно куда-то дёргаться. Хотя они там тоже шаблоны какие-то прикрутили и вроде как тоже кривовато, в общем подозреваю, что и Go не минет чаша сия, просто он пока слишком молодой.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Serginio1, Вы писали:
S>> Вот не надо сравнивать с перлом и регулярными выражениями! S>> Что тут непонятно? все прекрасно читается!
Ф>Понятно всё, но читается не очень.
Ну что мне сказать стареешь. Элементарные вещи. Это как пришли замыкания в язык. Большинство по первости были категорически против.
Прошло время и все прекрасно их используют.
Но Проще конечно Pattrn matching вместо
public int F() =>
(A is B b) && (b.C is C)
? C.D ?? 1
:FalseToNet ;
напишем так
public int F() =>
A swith
{
B b when b.C is C => C.D ?? 1,
_=>FalseToNet;
};
Здравствуйте, vsb, Вы писали:
vsb>Да, прикольный язык, если бы я сейчас начинал, возможно это был бы хороший совет, а так с 10 лет опыта на жаве уже сложно куда-то дёргаться. Хотя они там тоже шаблоны какие-то прикрутили и вроде как тоже кривовато, в общем подозреваю, что и Go не минет чаша сия, просто он пока слишком молодой.
Go ценен не столько даже самим языком, сколько комьюнити, сформировавшим идиомы языка, в которых простота является основной ценностью. В Go все крутится вокруг простоты: стандартные библиотеки, 3-party библиотеки, и реальный production код. Просто для примера, это код http сервера на го:
В примере нет никаких тебе IoC контейнеров, фабрик, аннотаций, фреймворков. И там весь код такой: простой и прямолинейный. Все задачи принято решать в лоб, ценится максимально простое и прямолинейное решение.
Здравствуйте, vsb, Вы писали:
vsb>Да, прикольный язык, если бы я сейчас начинал, возможно это был бы хороший совет, а так с 10 лет опыта на жаве уже сложно куда-то дёргаться. Хотя они там тоже шаблоны какие-то прикрутили и вроде как тоже кривовато, в общем подозреваю, что и Go не минет чаша сия, просто он пока слишком молодой.
У меня 20 лет основной 1С был. Да немного на Delphi и C# программировал. Бросил 1С перешел на C# и не жалею.
Всегда можно параллельно что то изучать и в итоге сменить ориентацию (не половую)!
и солнце б утром не вставало, когда бы не было меня
Ф>>public int F() =>
Ф>> (A is B b) && (b.C is C)?
Ф>> C.D ?? 1
Ф>> :FalseToNet ;
Ф>>
CC>Один хрен выглядит как perl. CC>Не надо так писать вообще. CC>Если можно написать более просто читаемый код — надо писать более просто читаемо, машине же всё равно.
Ф>>Чтение и правка такого кода порождает ошибки. Поубивал бы! CC>Верно.
Долго думал, откуда у меня странное ощущение, что я одновременно согласен и не согласен.
Потом понял. Мне кажется, рассматривая псевдокод, можно доказать всё, что угодно: и что так нельзя писать, и что можно, и что нужно. Особенно такой, где заглавная A это инстанс, заглавная B — тип, а заглавная C — одновременно тип и свойство.
T>Go ценен не столько даже самим языком, сколько комьюнити, сформировавшим идиомы языка, в которых простота является основной ценностью. В Go все крутится вокруг простоты: стандартные библиотеки, 3-party библиотеки, и реальный production код. Просто для примера, это код http сервера на го: T>
T>В примере нет никаких тебе IoC контейнеров, фабрик, аннотаций, фреймворков. И там весь код такой: простой и прямолинейный. Все задачи принято решать в лоб, ценится максимально простое и прямолинейное решение.
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();
Вроде тоже неплохо, при этом кучу вещей(сертификат, пароль, привязки...) можно задать 3-я способами (env, cli, appsettings.json)
На практике за простотой может скрываться примитивность(т.е. банальное отсутствие кучи возможностей, доступных из коробки в других каркасах и библиотеках).
Здравствуйте, Shtole, Вы писали:
.
S>Долго думал, откуда у меня странное ощущение, что я одновременно согласен и не согласен.
S>Потом понял. Мне кажется, рассматривая псевдокод, можно доказать всё, что угодно: и что так нельзя писать, и что можно, и что нужно. Особенно такой, где заглавная A это инстанс, заглавная B — тип, а заглавная C — одновременно тип и свойство.
Никогда бы не подумал, что этот пример кода вызовёт такую дискуссию
Конечно, не стоит писать в таком стиле как вы заметили
vaa>Вроде тоже неплохо, при этом кучу вещей(сертификат, пароль, привязки...) можно задать 3-я способами (env, cli, appsettings.json) vaa>На практике за простотой может скрываться примитивность(т.е. банальное отсутствие кучи возможностей, доступных из коробки в других каркасах и библиотеках).
А теперь собери это дело в контейнеры. С go можно уложиться в 6-7 Мб, с .net понадобится 100-200.
Слово такое.
Похоже, сейчас слишком много вещей двигается коммюнити. И шота эти коммюнити большей частью как капризные дети.
