Я люблю C#. После университета моим первым настоящим проектом по программированию была игра, написанная на Unity. И я сразу же влюбился в этот язык: он казался таким свежим. И был похож на Java… если бы в Oracle по-настоящему заботились о Java, это вернуло бы короткий золотой век Java. Слышал, что с тех пор они перешли на цикл ещё быстрее, так что всё могло измениться.
Я по-прежнему люблю этот язык. Может, он и не самый модный, но всё равно способен делать что угодно. Пример — многопоточность. Думаете, это сложно? Тогда попробуйте в Dart поиграть с Isolate и поймёте, как хорошо иметь C#.
В последние несколько лет меня стала очень беспокоить судьба языка. Я поделился своими мыслями в комментарии здесь. И раз уж комментарий привлёк так много внимания — решил конкретизировать его идеи.
Из-за чего весь сыр-бор?
В комментарии я написал:
«C# умирает, Microsoft убивает его, добавляя случайные штуки, о которых никто не просил. Это смерть от расползания функциональности».
Довольно ясно и понятно. И абсолютно никакой необходимости в написании статьи. Но всё-таки я её написал.
Я не знаю более эффективного способа, чем расползание функциональности, чтобы уничтожить язык программирования. Разве что бомбардировками. Эта перифраз цитаты из серии «Фрикономики»:
«Я не знаю более эффективного способа, чем регулирование арендной платы, чтобы уничтожить город. Разве что бомбардировки».
Я оставил слово бомбардировки — не нашёл подходящего эквивалента для языка программирования. Но бомбардировки не подходят: можно разбомбить штаб-квартиру компании, но нельзя этим уничтожить язык, можно только остановить его разработку. Надеюсь, меня не оштрафуют за такие слова.
Чем же чревато расползание функциональности? Оно затрудняет изучение и освоение языка. Хотите пример? Посмотрите интервью с создателем C++ Бьёрном Страуструпом. Оно забавное, хотя и ненастоящее.
1 января 1998 года Бьёрн Страуструп дал интервью журналу IEEE Computer.
1 января 1998 года Бьёрн Страуструп дал интервью журналу IEEE Computer. Естественно, редакторы ожидали от него ретроспективный обзор семи лет объектно-ориентированного проектирования, использующего созданный Страуструпом язык.
К концу интервью они получили даже больше, чем рассчитывали, и впоследствии решили скрыть его содержание «на благо отрасли». Но, как и бывает в таких случаях, произошла утечка.
Вот полный текст того, что было сказано во время интервью. Оно не отредактировано и не было подготовлено заранее, поэтому не такое складное, какими бывают запланированные интервью.
— Каково это — быть тем, кто изменил мир проектирования программного обеспечения? Прошло уже несколько лет с тех пор. Что можете сказать, оглядываясь назад?
— Вообще-то перед самым интервью я думал о том времени. Помните, все писали на С? Проблема была в том, что они чертовски хорошо это делали. И в университетах тоже очень хорошо этому учили. Настолько хорошо, что там с феноменальной скоростью подготавливали компетентных — я подчёркиваю, "компетентных" — выпускников. Это и привело к проблеме.
— К проблеме?
— Да, к проблеме. Помните, все писали на COBOL?
— Конечно. И я тоже.
— Вначале эти парни были как полубоги. У них была высокая зарплата, и с ними обращались как с членами королевской семьи.
— Вот было время!
— Да. Но что произошло? IBM это надоело, и они стали вкладывать миллионы в обучение программистов, пока тех не стало как собак нерезаных.
— Я поэтому и ушёл. Зарплата за год упала так, что выгоднее стало работать журналистом.
— Точно. То же самое произошло с программистами на С.
— Да? Ну и что?
— Однажды мне в голову пришла небольшая схема, которая немного восстановила бы равновесие. Я подумал: «Интересно: а что, если бы существовал язык настолько сложный, настолько трудный для изучения, что никто и никогда не смог бы наводнить рынок программистами?» На самом деле некоторые идеи я взял из X10, т. е. X-Windows. Это была такая плохая графическая система, что работала только на этих штуках Sun 3/60! Там были все нужные мне ингредиенты: смехотворно сложный синтаксис, непонятные функции и псевдообъектно-ориентированная структура. Даже сейчас никто не пишет сырой код на X-Windows. Почему? Это единственный путь, если вы хотите сохранить душевное здоровье.
— Вы шутите?
— Нисколько. На самом деле была ещё одна проблема. Unix писался на С, то есть любой программист на С очень легко мог стать системным программистом. Помните, сколько зарабатывал программист мейнфрейм-систем?
— Ну ещё бы! Я же им работал.
— Так вот этот новый язык должен был отделиться от Unix, скрыв все системные вызовы, которые так хорошо связывали их вместе. Это позволило бы неплохо зарабатывать и тем парням, которые знают только DOS.
— Не верю, что вы это произнесли…
— Прошло ведь уже достаточно времени. Думаю, большинство людей сами поняли, что C++ — это пустая трата времени. Только пришли они к этому намного позже, чем я надеялся.
— И как именно вы это сделали?
— Это должно было быть всего лишь шуткой. Никогда не думал, что люди воспримут книгу всерьёз. Любой, у кого ещё есть мозги, понимает: объектно-ориентированное программирование не является интуитивно понятным, оно нелогично и неэффективно.
— Что?
— А повторно используемый код? Вы когда-нибудь слышали, что какая-нибудь компания повторно использует свой код?
— Никогда не слышал, но…
— Вот видите. Правда, некоторые пытались на первых порах. Была эта компания из Орегона (кажется, Mentor Graphics), которая сильно простудилась, пытаясь переписать всё на C++ в 1990 или 1991 году. Мне, правда, было очень жаль их, но я думал, что они будут учиться на своих ошибках.
— Очевидно, ошибки их не научили?
— Нисколько. Проблема в том, что большинство компаний замалчивают все свои основные грубые ошибки, ведь нелегко объяснить акционерам убытки в 30 миллионов долларов. Однако, отдадим им должное, в конце концов у них всё получилось.
— Получилось? Вот видите: это доказывает, что объектно-ориентированное программирование работает.
— Ну, почти. Исполняемый файл был настолько огромным, что для загрузки на рабочую станцию HP со 128 Мб оперативной памяти потребовалось пять минут. А затем он очень медленно выполнялся. Я думал, это станет большой проблемой и за мной придут в течение недели, но никого это не волновало. В Sun и HP были только рады продать невероятно мощные коробки с огромными ресурсами, годившимися лишь для запуска простейших программ. Знаете, когда у нас в AT&T появился первый компилятор C++, я скомпилировал «Hello World» и не мог поверить в то, что размер исполняемого файла был 2,1 Мб.
— Да? Но с тех пор компиляторы далеко продвинулись.
— Неужели? Попробуйте последнюю версию g++ — вы не получите больших изменений от половины мегабайта. Кроме того, есть несколько совсем недавних примеров со всего мира. У British Telecom была крупная авария, к счастью, им удалось выбросить всё это и начать сначала. Им повезло больше, чем Australian Telecom. Теперь я слышу, что Siemens создаёт динозавра, и мне всё тревожнее, ведь размер аппаратного обеспечения под исполняемые файлы растёт. Что уж говорить о множественном наследовании…
— Да, но C++ — в принципе надёжный язык.
— Вы правда в это верите? Вы когда-нибудь работали над проектом на C++? Вот что происходит: во-первых, я заложил достаточно подводных камней, чтобы только самые простые проекты работали с первого раза. Возьмите перегрузку операторов. В конце проекта она есть почти в каждом модуле, потому что ребятам кажется, что так и должно быть, ведь так было в их учебном курсе. Один и тот же оператор значит что-то совершенно другое в каждом модуле. Попробуйте собрать всё это вместе, когда у вас примерно сотня модулей. А сокрытие данных… Боже мой, иногда не могу удержаться от смеха, когда слышу о проблемах компаний, заставляющих свои модули разговаривать друг с другом. Думаю, слово «синергетический» специально придумали, чтобы добавить мучений руководителю проекта.
— Должен сказать, всё это весьма шокирует. Вы говорите, что сделали это, чтобы повысить зарплату программистам? Это отвратительно.
— Ну что Вы?! У каждого есть выбор. Я не ожидал, что всё так выйдет из-под контроля. В любом случае я, в принципе, добился своего: C++ умирает, но ведь программисты получают высокие зарплаты. Особенно те бедолаги, которым приходится поддерживать всю эту околесицу. Понятно же, что невозможно поддерживать большой программный модуль на C++, если вы его не писали?
— Как это?
— А Вы не знаете? Помните typedef?
— Да, конечно.
— Помните, сколько времени уходило на прощупывание заголовочных файлов, а потом обнаруживалось, что RoofRaised — это число двойной точности? А представьте, сколько времени требуется, чтобы найти все неявно определённые типы во всех классах в крупном проекте.
— И как вы поняли, что достигли своего?
— Помните продолжительность среднего по размеру проекта на С? Около полугода. Недостаточно долго, чтобы обеспечить жене и детям достойный уровень жизни. А возьмите тот же проект и разрабатывайте его на C++. Что вы получите? Я Вам скажу. Один-два года. Разве не здорово? И это гарантированное рабочее место — всего лишь из-за одной ошибки в суждениях. И ещё кое-что. В университетах так давно не преподавали С, что сейчас не хватает приличных программистов на С. Особенно тех, кто что-нибудь знает о программировании систем Unix. Многие ли знают, что делать с malloc, когда все эти годы они использовали new и никогда не удосуживались проверить код возврата? На самом деле большинство программистов на C++ выбрасывают код возврата. А что случилось со старым добрым –1? По крайней мере вы знали, что у вас ошибка, не увязнув во всех этих throw, catch и try.
— Но ведь наследование помогает сэкономить много времени.
— Действительно? Вы когда-нибудь замечали разницу между планом проекта на C и на C++? Стадия планирования проекта на C++ в три раза длиннее именно для того, чтобы то, что должно наследоваться, наследовалось, а что не должно — нет. И потом, его до сих пор неправильно понимают. Кто-нибудь слышал об утечках памяти в программе на С? Теперь их поиск — целая индустрия. Большинство компаний сдаются и отправляют продукт на сторону (зная, что он протекает, как решето), просто чтобы избежать затрат на отслеживание утечек.
— Есть инструменты…
— Большинство из которых написаны на C++.
— Если мы опубликуем это, вас могут линчевать, вы это понимаете?
— Сомневаюсь. Как я уже сказал, C++ давно прошёл свой пик, и ни в одной компании, будучи в здравом уме, не начнут проект на C++ без пилотного испытания. Оно должно убедить их, что это путь к катастрофе. Если нет, то они заслуживают всего того, что получат. Знаете, я пытался убедить Денниса Ричи переписать Unix на C++.
— Боже мой! Что он сказал?
— К счастью, у него хорошее чувство юмора. Думаю, что и он, и Брайан понимали тогда, что я делаю, просто не подавали виду. Он сказал, что поможет мне написать версию DOS на C++, если мне будет интересно.
— И что Вы?
Страуструп: Вообще-то я написал DOS на C++, я дам вам демоверсию по окончании интервью. У меня она запускается на Sparc 20 в компьютерном зале. На четырёх ядрах работает, как ракета, и занимает всего 70 Мб на диске.
— А как на компьютере?
— А теперь Вы шутите. Вы что, никогда не видели Windows 95? Я считаю это своим самым большим успехом: она произвела эффект разорвавшейся бомбы прежде, чем я был к этому готов.
— Вы знаете, эта идея с Unix++ заставила меня задуматься. Кто-то ведь попробует это сделать.
Страуструп: Да, но не после прочтения этого интервью.
— Простите, но я не думаю, что мы опубликуем что-либо из этого.
— Но это история века. Я лишь хочу, чтобы мои коллеги-программисты запомнили меня за то, что я для них сделал. Вы же знаете, сколько сейчас можно получать на C++?
— Насколько я знаю, лучшие получают 70–80 долларов в час.
— Видите? И он этого полностью заслуживает. Нелёгкая работа — отслеживать все те подводные камни, которые я заложил в C++. И, как я уже говорил, каждый программист на C++ чувствует себя связанным каким-то мистическим обещанием использовать каждый элемент языка в каждом проекте. На самом деле меня это иногда очень раздражает. Спустя столько лет мне почти нравится этот язык.
— То есть раньше он Вам не нравился?
— Я его ненавидел. Он даже выглядит неуклюже, не находите? Но когда начали поступать гонорары от книги… Ну, Вы понимаете.
— Минуточку. А как насчёт ссылок? Вы должны признать, что улучшили указатели "С".
— Хм… Я всегда задавался этим вопросом. Сначала я думал, что улучшил. Но однажды я обсуждал это кое с кем, кто с самого начала писал на C++. Он сказал, что не запоминает, были ли его переменные ссылочными или разыменованными, поэтому всегда использует указатели. Он сказал, что маленькая звёздочка всегда напоминала ему…
— На этом месте я обычно говорю «большое спасибо», но сейчас это вряд ли уместно.
— Обещайте, что опубликуете это. Совесть не даёт мне покоя.
— Я дам вам знать. Но, кажется, знаю, что скажет мой редактор.
— Да и кто в это поверит? Хотя… пришлите мне копию этой записи.
— Это можно.
Очевидно, оно ненастоящее. Или всё-таки?.. Нет, ненастоящее.
Но это интервью стало вирусным, и понятно почему: оно могло быть правдой. Ведь все мы любим пошутить над тем, какое раздутое месиво этот C++. По этой причине его больше и не используют.
То есть, конечно, его обычно ещё используют, потому что единственная альтернатива в работе над чем-то низкоуровневым, — это C. Хотя Rust набирает популярность. Но когда вы в последний раз видели фреймворк высокого уровня, использующий C++?
Как это происходит с C#
Не хочется, чтобы та же участь постигла C#. Но, к сожалению, так и происходит. Я начал подозревать это, когда увидел новые выражения switch в C# 8. Фактически (из документации по C# 8) switch теперь можно определить так:
public static RGBColor FromRainbow(Rainbow colorBand) =>
colorBand switch
{
Rainbow.Red => new RGBColor(0xFF, 0x00, 0x00),
Rainbow.Orange => new RGBColor(0xFF, 0x7F, 0x00),
Rainbow.Yellow => new RGBColor(0xFF, 0xFF, 0x00),
Rainbow.Green => new RGBColor(0x00, 0xFF, 0x00),
Rainbow.Blue => new RGBColor(0x00, 0x00, 0xFF),
Rainbow.Indigo => new RGBColor(0x4B, 0x00, 0x82),
Rainbow.Violet => new RGBColor(0x94, 0x00, 0xD3),
_ => throw new ArgumentException(message: "invalid enum value", paramName: nameof(colorBand)),
};Но что было не так с обычным оператором switch? Может быть, есть какое-то обоснование, почему это лучше в очень специфических обстоятельствах. Тогда как насчёт этого: в C# 9 можно опустить тип вот так:
private List<WeatherObservation> _observations = new();Но ключевое слово var уже достаточно спорно. Зачем второе?
В C# 10 вы можете создать свойство для свойства. Это называется поля C#. Хорошо, сделано это для автоматических свойств. Но я не знаю, почему бы просто не использовать обычное свойство. Ведь свойства должны облегчать нам жизнь, а не усложнять её.
А жизнь будет только ухудшаться
Потому что у C# должна быть каждый год новая версия. Не знаю, почему все переходят на быстрые циклы выпуска. Как будто я год использовал бета-версию Firefox 4 и был совершенно доволен ей. А сейчас? У нас Firefox 91. Да, 91. Потому что, по-видимому, каждый браузер должен обновляться в течение 4-недельного цикла выпуска.
C# выпускается за год, а Java — за 6 месяцев. Не знаю, зачем. Ведь языки программирования не устаревают так быстро.
На самом деле я вроде как знаю ответ, почему это происходит с Java: подозреваю, что это связано с OpenJDK. Старые версии OpenJDK не получают никаких обновлений, поэтому, если хотите использовать 5-летнюю версию Java, как наверняка делает большинство компаний, нужно доплатить. Это довольно изобретательно.
Прямо сейчас C#, может быть, не так уж и плох. Но подождите несколько лет, и скоро расползание функциональности станет всеобъемлющим.
Аргумент: просто не используйте эти особенности языка
На эту часть моих доводов поступило самое большое количество жалоб. Я вроде бы и согласен. Поэтому не писал об этом раньше. Но знаете: неиспользование функций работает сейчас. Что, если этот темп расползания функций продолжится? Словами вымышленного интервью:
И, как я уже говорил, каждый программист на C++ чувствует себя связанным каким-то мистическим обещанием использовать каждый элемент языка в каждом проекте.
Что, если во всех руководствах по C# начнут пользоваться непонятным синтаксисом? Что тогда? Думаю, когда это случится, многие перестанут использовать C#.
Я любил С#
Проблема с C# была в том, что он всегда был слишком многословным. Это у него от Java. Настолько, что я часто в шутку называл его Java#.
Так что было бы разумно, если бы C# добавлял функции, чтобы сократить эту многословность, и они это делают. Но похоже на то, что они просто добавляют хакерское исправление вместо решения основной проблемы.
Такие языки, как Dart, спрашивают: «Как мы можем сделать это проще?» в то время как такие языки, как C#, спрашивают: «Как мы можем делать в точности то, что делали раньше, просто с меньшим количеством кода?»
И, конечно же, они приходят к ответу: «Просто бросьте в это макрос».
Конечно, иногда они думают о том, чтобы добавить что-то действительно полезное. Но чаще всего это оплошности. Познавательная работа. Конечно, они решили проблему необходимости печатать слишком много. Но основная проблема, связанная со сложностью, только усугубляется.
Уже есть сообщения о том, что люди отказываются от C#. Тенденции Stack Overflow показывают резкое снижение количества вопросов с середины 2009 года, а их ежегодные опросы (за исключением 2017–2018 годов) показывают медленное и постепенное снижение популярности языка.
И если уровень раздувания будет расти, я подозреваю, что уйдёт ещё больше.
А если вы по-прежнему любите C# и C++, то можете обратить внимание на наши курсы, чтобы прокачать свои навыки:
Также вы можете перейти на страницу пакета курсов по кодингу, чтобы узнать, как мы готовим специалистов в программировании.
Согласны ли вы с автором статьи? Проголосуйте или поделитесь мнением в комментариях.
Профессии и курсы
Data Science и Machine Learning
Python, веб-разработка
Мобильная разработка
Java и C#
От основ — в глубину
А также:
Комментарии (170)
dimaaannn
27.10.2021 23:00+48медленное и постепенное снижение популярности языка.
Ну да, майки подвезли .net core, развивают xamarin, ASP.Net, бизнес хочет ещё сотрудников, по всем направлениям, а популярность шарпа умирает.
Даже геймдев на юнити и мобилках хочет заманить побольше людей на свою галеркуОх уж эти умирающие языки.
chernish2
27.10.2021 23:09+33Тенденции переполнения стека показывают резкое снижение количества вопросов с середины 2009 года
Вы это серьёзно? Совсем перевод не вычитывали перед публикацией?
MFilonen2
27.10.2021 23:19+3В примерах я вижу сброс C и Java-подобного балласта. Да, времена меняются, и писать каждый раз break в операторе switch это просто странно, учитывая то, насколько его редко надо не писать, а необходимость добавлять закрытую переменную для свойства просто удваивает объем кода.
Конечно, это все синтаксический сахар, только вот этот сахар будет использован тысячи раз и сократит сотни тысяч строк кода, а еще уберет много болезненных ошибок.
Делать что-то лучше? Так это еще более усложнит язык. Посмотрите на раст, как раз язык где абстракция максимальна. По факту это 3 языка (сам раст, макросы, процедурные макросы), наслоенные друг на друга. Ну или там хаскель.
Насчет дарта удивился. Даже банальная конвертация JSON в объект это боль по сравнению со Swift, где просто приписываешь: Codable к названию объекта и готово. В свифте это зашито в компилятор и нельзя самому создать протокол, который генерит код? Плохо, да, но и пофигу, основные юзкейсы-то покрыты.
Как раз самые популярные языки и есть сплошное наслоение синтаксического сахара, потому что абстракция в коде далеко не равна повышению абстракции в задаче, а вот ментальная модель кода усложняется куда там. Вот и получается, что языки типа Rust, Scala, C++ или Haskell со всей их абстрактностью не являются “мейнстримными”.khim
28.10.2021 01:37+6Вот и получается, что языки типа Rust, Scala, C++ или Haskell со всей их абстрактностью не являются “мейнстримными”.
Ну ладно: Haskell, Scala, Rust… но C++? Те же самые 77000 предложений, что и для C#.
Вы, вообще, по каким критериям “мэйнстриймовость” определяете?
MFilonen2
28.10.2021 11:09+2Это, конечно, умозрительно, но вакансий по поддержке легаси очень много на плюсах. Все-таки на этом языке раньше писали практически всё, не удивительно, что надо это кому-то поддерживать.
Но зачем выбирать плюсы сегодня? Наверное, если есть подходящая библиотека, ради производительности в высоконагруженных задачах, ну и еще есть UE и Qt.
На C# есть, конечно, и поддержка старых Windows-приложений, но в основном, думаю, это бекенд, Unity и немного Xamarin. И соотношение новых и старых проектов там сравнимо с другими языками.khim
28.10.2021 12:26+3Но зачем выбирать плюсы сегодня?
Не “зачем”, а “почему”. Потому что C++ можно использовать там, где все эти новомодные C#, JavaScript и прочие “пожиратели ресурсов” использовать нельзя.
Сейчас в любом автомобиле куча чипов (именно поэтому их нехватка так сильно бьёт по автопроизводителям), в любой кофеварке чип (а то и не один) и так далее и тому подобное.
И это, на сегодня, C++, вариантов нету: есть ещё Rust, конечно, но он пока ещё молод, если он C++ и вытеснит, так это лет через 10 будет.
На C# есть, конечно, и поддержка старых Windows-приложений, но в основном, думаю, это бекенд, Unity и немного Xamarin. И соотношение новых и старых проектов там сравнимо с другими языками.
C# это не только старые, но и новые Windows приложения. Всякие аддоны для Visual Studio можно только на C#, по большому счёту, писать. И да, это — это большой такой “континент”.
Java живёт за счёт “сурового Enterprise” и мобильной разработки (однако менее популярна среди разрабочиков на Linkedin).
JavaScript — это огромный Web-“континент”.
Однако вы не напишите операционку и не запрограммируете робота ни на C#, ни на Haskell. И на JavaScript — тоже.
Нет, разово, для себя, можно на чём угодно, даже на Python.
Но как только вам станет небезразличен BOM — вы снова вернётесь к C++. Потому C++ — это океан, где все эти континенты расположены.
И потому C++ — никуда не денется в ближайшее время.
Вытеснить его может, разве что, Rust, которые тоже, теоретически тоже может для сего этого использоваться.
Теоретически мог бы ещё Swift, то там политика вмешалась: Apple жёстко контролирует развитие Swift и меняет его так и тогда, когда это нужно для увеличения продаж iPhone, так что вряд ли его кто-то, кроме Apple, будет активно использовать.
P.S. Собственно это всё прямо на LinkedIn можно увидитеть: если смотреть чуть шире и посмотреть не на разработчиков C++/C#/Python/Java, а на вакансии, где требуется и что-то ещё, то тут уже C# окажется далеко позади, Python, Java, JavaScript уйдут вперёд, C++ слегка отстанет (но всё равно будет втрое более популярен, чем C#).
yurec_bond
29.10.2021 12:46На счет -"в любом автомобиле куча чипов" потому нужны c++ програмисты.
Слышал что с++ програмеров которые могут програмировать микроконтроллеры мало они дорогие.
по этому производители начинают использовать в своих продуктах более мошьные чипи которые могут запускать Linux и програмеров под линукс проще найти.
Короче компании выгоднее ставить немного более дорогой чип но при этом экономить на софте.
Слышал байки про то как такое простое устройство как контроллер сидения в автомобиле работает на линуксе, и это только один из многих контроллеков в машине.
0xd34df00d
30.10.2021 22:44+2Однако вы не напишите операционку [...] на Haskell
Ну как минимум есть hos. Ассемблер и сишка для memory management и RTS, остальное на хаскеле. Оно сдохло, конечно, но как proof of concept — вполне.
А учитывая, что в хаскеле теперь легко запиливать инлайн-ассемблер, отдельной сишки и ассемблера на самом деле нужно ещё меньше.
На голых плюсах без асмовставок, кстати, вы ОС тоже не напишете, как и на голом С.
А, совсем забыл: можно же взять какой-нибудь eDSL на том же хаскеле и писать вообще бареметал (пусть он там где-то в кишках компилируется в C).
Nihiroz
28.10.2021 11:12В котлине конвертация в JSON сделана ещё лучше. Ставишь в виде зависимости препроцессор-кодогенератор, помечаешь класс аннотацией и кодогенератор сам пишет конвертацию. То есть и язык не захламляет, и всегда есть возможность подобную штуку самому сделать
Lofer
27.10.2021 23:35+4Конечно, это все синтаксический сахар, только вот этот сахар будет использован тысячи раз и сократит сотни тысяч строк кода, а еще уберет много болезненных ошибок.
Этот "синтаксический сахар" начинает подбешивать потихоньку. Подается как "самое новое и крутое". Смотришь в IL - а там все тоже самое, что и было раньше, только "новое" и если ты раньше это делал руками или snippets себе наделал, то сейчас это генерирует компилятор. Если бы можно было самому делать такой "синтаксический сахар" без черезмерных усилий - было куда полезнее...
doctorw
27.10.2021 23:51+22Смотришь в IL — а там все тоже самое, что и было раньше
Это вроде бы и есть часть определения «синтаксический сахар», нет?
beskaravaev
28.10.2021 11:35Завезли кодогерацию год назад, а с новым релизом в ноябре работу с ней ещё улучшат. Так что уже можно писать свой сахар:)
rinac
28.10.2021 13:10+7Подается как "самое новое и крутое". Смотришь в дезассимблированный код - а там все тоже самое, что и было раньше, только "новое" и если ты раньше руками управляющие байты вбивал или перфоркарт себе наделал, то сейчас это генерирует компилятор.
rinac
28.10.2021 13:10Подается как "самое новое и крутое". Смотришь в дезассимблированный код - а там все тоже самое, что и было раньше, только "новое" и если ты раньше руками управляющие байты вбивал или перфоркарт себе наделал, то сейчас это генерирует компилятор.
mrbaranovskyi
28.10.2021 17:26+5Этот "синтаксический сахар" начинает подбешивать потихоньку.
Это к психотерапевту.
Подается как "самое новое и крутое"
Ничто,никому не подается. Не хочешь - не используй. Самое новое и крутое, обычно, происходит в рантайме, а не в языке. У инженера должна быть возможность писать качественный софт и возможность его оперативно поддерживать, а не радоваться новому свитчу.
Смотришь в IL - а там все тоже самое, что и было раньше,
Это и есть синтаксический сахар.
Если бы можно было самому делать такой "синтаксический сахар" без черезмерных усилий
Есть Розлин - вперёд. Пусть только все ИДЕшки научатся это поддерживать. Я не вижу в этом особой полезности.
Lofer
01.11.2021 01:19Это к психотерапевту.
Спасибо за заботу.
Есть банальная логика - запоминать одну базову вещь, заложенную на уровне стандарта, или еще пачку наворотов с их нюансами, придуманными за тебя "тем парнем" ? или иметь возможность самому, на уровне исходного кода внутри проекта делать что тебе удобно ?
мой приоритет - иметь как можно больше контроля в своих руках, и как можно меньше полагаться на "магию".
Я бы с удовольствием бы использовал механизм вроде #define из C++
mrbaranovskyi
01.11.2021 11:03-1Спасибо за заботу.
Всегда на страже.
мой приоритет - иметь как можно больше контроля в своих руках
.net по сути, уже позволяет писать практически на ассемблере. Есть интристикс апи, которым мы иногда даже пользуемся. Есть конструкции которые позволяют не покидать стек. Есть возможность работать, практически, с нулевой актиностью GC. По сути, (кроме граничных случаев) я не вижу смысла писать на тех же плюсах. Выигрыш в производительности в большинстве случаев, будет минимальный. При том, что я упускаю вопрос - а нужна ли вам такая производительность. Какой контроль еще Вам нужен, я не понимаю.
Я бы с удовольствием бы использовал механизм вроде #define из C++
ух... мне кажется, Вас сейчас здесь забьют :) Я лично такого дерьма насмотрелся с этим препроцессором... с этим пунктом я точно не соглашусь.
ol_x
28.10.2021 00:02+1пока язык хорошо выполняет свои задачи, на нем будут писать, но ничто не вечно под луной ????
Ascar
28.10.2021 00:59switch изначально дурацкая конструкция, надо туда сюда его прокручивать. Вместо него лучше использовать словарь. Новый синтаксис улучшает его читаемость и он компактнее.
var позволяет не выяснять тип и избегать возможных неявных приведений типа.
Упрощенный вызов конструктора тоже уместен если тип уже известен.
eugeneyp
28.10.2021 10:04+1switch это конструкция унаследованная от С. В С можно использовать только int или приводимые к ним переменные. С вариант switch хорошо ложиться в команды процессора, гораздо лучше чем каскад if else. Насчет лучшей генерации bytecode для языков на подобии Java/C# и т.п. не уверен.
Ascar
28.10.2021 17:53Да даже с if else может быть удобнее: переменная на виду.
KislyFan
28.10.2021 20:34У switch case есть одно большое преимущество, с ростом количества возможных переходов у нас появляется выигрыш перформанса по сравнению с аналогичной консрукцией из if else. Другое дело, что если у нас switch разросся до таких размеров, то это явная архитектурная ошибка.
MagDen
28.10.2021 01:17+2Думаю, нужно использовать deprecated для устаревших конструкций. Да, это по сути форкнуть язык, но расползание синтаксиса тоже ни к чему хорошему не приведет
lek
28.10.2021 02:33+23Новый свитч - это паттерн матчинг. Зачем новый new? Полагаю, чтобы не повторять два раза длинные типы, там где var нельзя использовать. private var _field = new длинный_длинный_тип_с_джинериками() сделать нельзя, или я не прав? Я, кстати, на C# не программирую, но для чего эти изменения были сделаны очевидно. Собствнно, как я не програмиирую на С#, так и вы, скорее всего не слишком далеко заглядывали за границы императивных языков. До того, как критиковать нечто, можно для начала ознакомиться с "течением мировой мысли по поводу", так сказать. Например, хотя бы с тем, что такое pattern matching и зачем он нужен.
Politura
28.10.2021 02:34+33Автор - какая-то истеричка.
Switch expression - очень удобная штука позволяющая писать более компактный код не теряя его читабельности.
private List<WeatherObservation> _observations = new();Также очень удобная штука место которой исключительно в объявлении приватных членов класса с созданием дефолтных значений. Уж куда лучше так писать, чем по-старинке:
private List<WeatherObservation> _observations = new List<WeatherObservation>();Очевидно, что пихать его в сами функции рядом с var нет никакого смысла.
В C# 10 вы можете создать свойство для свойства. Это называется поля C#. Хорошо, сделано это для автоматических свойств. Но я не знаю, почему бы просто не использовать обычное свойство.
Ах вот оно в чем дело, просто автор какой-то подросток который еще не до конца разобрался с языком. Поля были добавленны не в 10-й версии, а с самой первой. Чтоб узнать в чем их отличие и почему они не заменяют проперти, можно сходить в документацию. В 10-ке просто добавили сахара позволяющего работать с полями лаконичнее, делая код более компатным без ущерба читабельности. По мне так отлично, ибо каждый раз когда вынужден использовать поля в паре с пропертями испытываешь негатив от многословности сего действия.
Помню времена, когда linq добавили, тоже было море плача от подобных товарищей.
13_beta2
28.10.2021 05:12+21Помню времена, когда linq добавили, тоже было море плача от подобных товарищей.
Честно говоря, не знаю был ли linq в конечном виде оригинальной идеей или таки повторением за кем-то, но так органично встроить функциональный стиль в мейнстримовый язык, строго имхо, идея на грани гениальности. И, опять же на мой взгляд, одно из полезнейших и удобнейших изменений из случившихся с .net после запуска.
Evengard
28.10.2021 08:22+22Честно, мне после Linq-а все остальные языки без подобного кажутся неполноценными.
PowerMetall
28.10.2021 09:05+7Прямо дико удваиваю.
С года два назад потребовалось "вот прямо сейчас в моменте и быстро" набросать какую-то мелочь на java (никаких фреймворков, просто консольное микроприложение API со встроенным вебсервером и субд на SQLite). "Ну ерунда вопрос" - подумал я, - "подумаешь, на Java ни раз в жизни не писал, всего то консольное приложение, синтаксис похож, да и гугл под рукой".
В целом написал, но в процессе был СИЛЬНО удивлен отсутствию LINQ (или даже хотя бы чему то похожему на него), настолько оно казалось мне органичным и логичным в С#
Phanto_m
28.10.2021 09:35+2Java Streams
marshinov
28.10.2021 14:57Только для памяти. Никаких вам деревьев выражений.
eugeneyp
29.10.2021 11:07Нету деревьев выражений как элемента языка(платформы) или ORM его не поддерживают?
Первое давно есть основано на механизме classloader+bycode изменений в runtime.
Например в Java достаточно @Asynchronous, не нужны изменения языка за счет добавления await/async
Насчет второго скорее всего все привыкли пользоваться QL или вообще на автогенерацию SpringJDBC полагаться. Будет нужно допилят.
marshinov
29.10.2021 11:35А можете дать ссылку на @asynchronous?Я не представляю как аннотацией синхронный IO на асинхронный изменить. Project Loom вроде собирается такое делать, но это ж сколько байткода переписывать… Касательно «привыкли»: привыкли же не значит, что это хорошее решение, просто за неимением альтернатив. Не подумайте, некоторые вещи в Java мне нравятся больше, чем в .NET, но работа с бд в этот список не входит.
eugeneyp
29.10.2021 11:54Смотрите документацию на javax.ejb.Asynchronous было доступно в древнем JBoss.
На самом деле там не так сложно, на хабре была статья как устроен async/await внутри. В Java для давно доступен не блокирующий NIO.Java Web/ORM/AOP всегда использовали внедрение кода для расширения функциональности. Даже code coverage библиотеки внедряют вызовы touch("filename",lineNumber). Т.е. технология очень популярная и востребованная.
marshinov
29.10.2021 14:50Я знаю как устроен async/await внутри. Я о том, что без переписывания байткода в CPS будет две модели программирования: синхронна и асинхронная и придется держать в голове 100500 операторов Rx. В случае с await все это уезжает за кулисы, а код выглядит синхронным.
Если @Asynchronous - это оно, то Future же придется писать через .then.then.then в promise-стиле. async/await завезли ровно, чтобы этого избежать.
Reformat
28.10.2021 10:27-1Вам сразу стоило взять Kotlin. Там все это есть и даже больше
marshinov
28.10.2021 14:57+5И все еще нет деревьев выражений...
ldss
29.10.2021 21:52вот мне интересно, насколько широко они используются
потому что если в видеvar expr: (Int)->Int = x -> when (x) { 1 -> 0 0 -> 1 else -1 }так такое и в котлине есть
Причем вот как раз там лямбды сделаны сильно лучше:)marshinov
29.10.2021 22:19Я про C#
ldss
29.10.2021 22:23+1я к тому, что сишарп прекрасен, и в свое время был ваще самым прогрессивным и офигенным языком (да и сейчас, их имплементация женериков до сих пор на голову выше многих конкурентов)
Но вот эти новые фичи, на которые жалуются - они не новые, на самом деле, и уже б-м давно присутствуют в других языках. И сишарп в данный момент, увы, в позиции догоняющего
marshinov
30.10.2021 09:40+1Если сравнивать с Kotlin, то здесь работает тот же принцип, что помог C# стать лучше Java: когда язык проектировали не было легаси и можно было спокойно скопировать удачные решения Java, а неудачные - исправить. Сейчас те же nullable reference types пришлось костылить потому что нельзя просто так исправить всю систему типов. + фичей в языке уже так много, что приходится очень аккуратно выбирать, что добавить, а что нет. Вообще будет забавно, если в какой-то момент C# устареет как Java и появится Kotlin от CLR, но пока вот не видно, чтобы Kotlin совсем уж Java похоронил. Многие считают, что Java 17 даже предпочтительнее Kotlin. Так что поживем - увидим.
ldss
01.11.2021 18:26Если сравнивать с Kotlin, то здесь работает тот же принцип, что помог C# стать лучше Java: когда язык проектировали не было легаси и можно было спокойно скопировать удачные решения Java, а неудачные - исправить.
Котлин - java compliant language, т.е., из него генерится ровно тот же байткод, что и из жавы. Т.е., женерики там - такое же г:(
Сейчас те же nullable reference types пришлось костылить потому что нельзя просто так исправить всю систему типов
Это да
Но в К. масса других полезных вещей. Давеча коллега опять присел на c#, так с удивлением спрашивал - как это в обьявлении класса нельзя конструктор с пропертями обьявить?!:)
Многие считают, что Java 17 даже предпочтительнее Kotlin
свят-свят
Вообще будет забавно, если в какой-то момент C# устареет как Java
нууу, это сомнительно. Все-таки у сишарпа основной разработчик один, а не эта рыхлая масса как в жаве
marshinov
01.11.2021 18:45Котлин - java compliant language
Еще и в JS, а там стирающиеся дженерики - самое то. Ну и inline reified T все-таки никто не отменял. Костыли конечно, но работает же:)
Конструкторы с пропертями можно для рекордов. Думаю, через пару версий втащат и в классы (ну глядя на C#10: как там акуратненько рекорды для структур всунули).
ldss
01.11.2021 19:28+1Конструкторы с пропертями можно для рекордов. Думаю, через пару версий втащат и в классы (ну глядя на C#10: как там акуратненько рекорды для структур всунули).
ну дай-то бог
а то мне в свое время переход на жаву тяжело дался, а потом появился котлин, и настало щастье
А потом я опять немного пересел на шарп, и возникли, знаете ли, вопросы
ldss
01.11.2021 19:52+1Если уж совсем в дебри углубляться,
C++->C#->Java->Kotlin->Kotlin+C#+JavaИз них именно переход на чистую жаву был самый травмирующий:))
marshinov
01.11.2021 19:56У меня там не стрелка, а "меньше" было:) Я имел в виду, что вам C# нравится больше, чем Java, а Kotlin больше чем C#, верно?
Из них именно переход на чистую жаву был самый травмирующий:))
Не так страшна Java как Spring...
ldss
01.11.2021 20:20+1У меня там не стрелка, а "меньше" было:) Я имел в виду, что вам C# нравится больше, чем Java, а Kotlin больше чем C#, верно?
да, именно так. Хотя сишарп не сказать чтоб не нравится, просто К. чуть удобнее, да и привык
marshinov
01.11.2021 20:27А что больнее всего было в Java? Я сейчас тоже по долгу службы сравниваю C#, Kotlin и Java. И если по поводу первых двух во многом дело вкуса, то Spring для меня просто тихий ужас по сравнению с ASP.NET Core
ldss
01.11.2021 20:37+1на первом месте - многословность и просто адское количество boilerplate code. У меня постоянно было ощущение, что я что-то обьясняю умственно отсталому человеку - очень подробно, со всеми мелкими деталями и т.п., каждый раз повторяя одно и то же. Сюда же отсутствие лямбд, linq и проч. Хотя в 11 жаве это уже все есть в полный рост, но оно все равно крайне многословное
Второе - женерики. После дотнета это был прям-таки удар!!!:) Они в жаве не более чем syntax sugar
третье - очень странная имплементация интефейсов (после сишарпа). Не могу сказать, что плохая, но странная
то Spring для меня просто тихий ужас
бог миловал:)
SShtole
28.10.2021 10:23+1Честно, мне после Linq-а все остальные языки без подобного кажутся неполноценными.
Такая же фигня. Самым первым делом после возвращения на плюсы я задал вопрос: что из имеющегося больше всего похоже на LINQ? Понятно, что это как перевод: не надо по словам, надо, чтобы смысл сохранился.
А вообще, розовая мечта: найти порт FCL.
Enfriz
28.10.2021 16:27+4Тоже теперь такие мысли (перешел с Java на C#). Не понимаю, как люди пишут на языках, где нет мощных средств работы с коллекциями и перечислениями. Особенно на Go, это ж пипец.
Ну и смешно как JavaScript пытается эмулировать это, и поэтому в коде у разработчиков полно конструкций
array.map(...).filter(...)которые просто несколько раз проходят по коллекции от начала до конца.Evengard
28.10.2021 19:04+3Вот про Go удваиваю, особенно сильно прочувствовал именно когда познакомился именно с ним.
eugeneyp
28.10.2021 09:55+1Linq выглядит как развитие Embedded SQL, но может применяться не только для запросов но и простых коллекций. Так что идея не новая, но реализация дает большой плюс.
Java поддерживает лямбдs и stream коллекции, тот-же Linq только нету sql синтаксиса.
Phanto_m
28.10.2021 12:23+3Java поддерживает лямбдs и stream коллекции, тот-же Linq только нету sql синтаксиса.
А кто то в шарпе юзает sql-like синтаксис?eugeneyp
28.10.2021 14:55Как ни странно то что я видел для работы с БД через EntityFramework используют sql like нотацию. а для in memory преобразований в основном через функции.
Evengard
28.10.2021 19:06+1Джойны удобней писать на sql-like-е, особенно left join-ы всякие. Можно конечно и без него, но реально удобней.
mvv-rus
28.10.2021 20:48Вот пример использования (правда, задача там тестовая, но получается очень функционально).
Причем, обратите внимание, то что переменные после from там имеют тип, который даже не реализует IEnumerable — такое тоже возможно.
kefirr
28.10.2021 13:45+5Java streams - бледное подобие LINQ.
Гибкость и удобство намного ниже из-за отсутствия extension methods.
Нет Expression Trees (https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/), что ограничивает применение в ORM и рантайм кодогенерации.
eugeneyp
28.10.2021 15:10А чем указатели на функцию плохи? IMHO extension methods часто доставляют много неудобств, т.к. не понятно как их перегружать. какую сбоку подключить чтобы заработало и т.д.
В Java отсутствует перегрузка операторов это мешает использовать разный синтаксический сахар. В Java ORM(и не только) давно используют изменение bytecode для достижения разных целей еще со времен Java 2. Hibernate для примера использует Byte Buddy. Т.е. в Java не нужен синтаксический сахар для формирование дерева функций, можно готовый код разобрать и менять как хочется или преобразовать в SQL. Вообще механизм classloader весьма сильный и позволяет делать то что в C# и не снилось, но при этом синтаксис самого языка очень отстает.
Phanto_m
28.10.2021 19:24+1Вот и джависты подъехали.
Какие указатели на функции?
Как не понятно как их перегружать? Так же, как и другие любые методы, и сам объект неявно передается. Что, куда подключить? Если речь про сборки, то
IDE подсказывает
Документация
Точно так же, если бы не были методами расширения
eugeneyp
29.10.2021 10:36-2Можно пример перегрузки, когда для двух переменных одного типа вызываются разные функции если одна переменная была создана для потомка?
Например для IDictionary одно поведение, а для ConcurrentDictionary другое.
IDictionary dir1=new SortedDictionary();
IDictionary dir2=new ConcurrentDictionary();Еще вопрос как вы Mock делаете для extension methods?
Также все плюсы Singleton становятся минусами для extension methods, т.к. сводят ООП к процедурному программированию.
Phanto_m
29.10.2021 10:47+1Методы расширения ничем не отличаются от обычных статических методов, их можно вызывать так же, как и обычный метод, передав нужный объект.
agoncharov
28.10.2021 13:09+3Я не могу понять почему в сообществе хабра считается нормой начинать комментарий к статье с оскорбления автора
KislyFan
28.10.2021 20:15+2В данном случае, на это две причины:
автор безапелляционно заявляет о скорой смерти языка, а на поверку в статье банальное непонимание новых фич, и прочее "раньше было лучше"
в комментах как всегда отметились "те кто знает как лучше"
Проанализировав эти два пункта, можно сделать вывод, что это банальный байт на комменты, чтобы пользователи пролистали до комментов, увидели рекламу и возможно перешли по ссылке.
agoncharov
29.10.2021 07:51-1Это очень плохие причины для того чтобы писать такое. Я думал Хабр выше этого
KislyFan
28.10.2021 20:22Позволю себе вас перефразировать) new() добавляет языку лаконичности. var нужен когда мы не знаем, какой тип будет в левой части присваивания, а new() нужен когда мы наоборот знаем.
petuhov_k
01.11.2021 20:28Автор не подросток, автор - "программист" на Unity. Да простят меня разработчики на Unity, если есть среди вас толковые ребята, но я лично не встречал. Сколько ни собеседовал их на должность .Net разработчика, ни один не прошёл. Ни .Net они не знают, ни c# толком, а некоторых я бы и программистами не назвал.
Atreides07
28.10.2021 07:34+15С тех пор как появился var а потом и Linq регулярно слышу от коллег как Microsoft хоронит C# такими плюшками. Уже в год появления Linq слышал кучу возмущений от коллег по поводу Linq и насколько это все ненужный мусор, а сейчас без Linq трудно представить C#.
Некоторые даже возмущались по поводу async/await - а сейчас async/await перекочевал из C# во многие языки.
И так КАЖДЫЙ год с КАЖДОЙ новой версией C# очередная волна хоронителей C# дает о себе знать.
Возьмите тот же Kotlin, в нем от рождения плюшек намного больше чем в C# и там где инертность была маленькая (мобильная разработка) Kotlin очень быстро вытеснил Java и фактически стал дефолтным языком разработки. А там где была большая инертность (корпоративная серверная разработка на Java порой обладают очень большим объемам легаса кода) как только Kotlin начал вытеснять и серверную разработку, Java начала активно тырить фичи из Kotlin и быстро развиваться, хотя до этого годами спорили надо ли вводить var или нет.
Если когда-нибудь писали на функциональных языка типа F# и другие, то поймете насколько все плохо в C# и что C# крайне плохо подходит для моделирования сложной предметной области. Тот же pattern matching не довезли нормально (безумно удобно когда компилятор сразу подсказывает что у тебя пропущены некоторые кейсы). Очень не хватает Union Type. Безумно не хватает тех же val как в kotlin-е. Те же Record-ы должны были появиться гораздо раньше, так как после других языков жутко бесило писать все время {get; set;} бесконечно количество раз. Кодогенерация должна была появиться намного раньше, так как писать раскрытый вариант {get; set; } Для каждого свойства в MVVM тоже очень раздражает (Fody спасал, но о нем знало и использовало очень мало людей). Отставание от современных языков как раз и губит C#.
А вот популярность C# как раз таки начала падать при Балмере, когда он забил на C#, .NET и C# вообще перестал развиваться и Microsoft активно рекламировал и призывал использовать тот же JS при разработке в WinRT. Даже покрытие API Winrt под .NET было меньше чем покрытие API Winrt JS-ом. И наоборот, при Наделла популярность C# снова начала расти, так как при нем активно стали развивать .net core
Как показывает практика, обычно все наоборот:
1. Язык губит как раз таки остановка развития языка (примерно как Kotlin вытеснил почти полностью Java на Android, как только появилась альтернатива Java).
2. А еще язык губит непродуманная политика Microsoft, когда на C# хоронят один за другим платформы (как писали выше - Silverlight, WinRT, UWP, WP, WebForms). Тот же Xamarin/Maui на очереди к моему большому сожалению, так как Microsoft забивает на мнение комьюнити и развивает тот же Maui с тем же подходом что и Xamarin (Я перешел с Xamarin на Flutter и оказалось что Flutter + ASP.NET Core значительно удобнее и быстрее для разработки, чем Xamarin/MAUI + ASP.NET Core).
На практике плюшки дают выбор, а не убивают язык, а с тем, что бы команда писала не в разнобой, в одинаковом стиле, писала наиболее компактный идентичный код, сегодня вполне успешно справляются инструменты вроде Resharper и Rider, которые умеют одним хоткеем преобразовать код из одного вида в другой и могут рекомендовать конкретный стиль/плюшки для использования. (и да, для больших команд в 10-20 человек правила можно настраивать и при желании можно вообще запретить использовать конкретные плюшки и не давать компилироваться и мержится с выбранными (новым или старым) стилем кода).
granit1986
28.10.2021 10:08+2А вот популярность C# как раз таки начала падать при Балмере, когда он забил на C#, .NET и C# вообще перестал развиваться и Microsoft активно рекламировал и призывал использовать тот же JS при разработке в WinRT. Даже покрытие API Winrt под .NET было меньше чем покрытие API Winrt JS-ом. И наоборот, при Наделла популярность C# снова начала расти, так как при нем активно стали развивать .net core
Могу ошибиться, но, кажется, примерно в это время Microsoft активно пилила Roslyn и как раз из-за него забила на всё остальное. Они там лет пять кроме него ничего особо не делали
PerseforeComplete
28.10.2021 10:58-2А зачем появились record, какую проблему они решают? Ну в них Equals и == генерируются, да. Это было настолько важно, что ради этого целое ключевое слово и поддержку компилятора завезли?
kasthack_phoenix
28.10.2021 12:09+3какую проблему они решают
Boilerplate. Аналог(типы с иммутабельностью, конструкторами, копированием с модификацией, etc) на шарпе без них требует экран-другой кода.
Atreides07
28.10.2021 13:46+1Да, после других языков могу уверенно сказать что это дико важно. Кто-то может сказать что equals и так можно было негенерить легко resharper-ом. Если у тебя небольшой проект, то это правда. Но когда у тебя в проекте сотни сущностей и тебе регулярно надо рефакторить, необходимость следить за всеми эти Equals дико утомляет. Беда equals в том что само его существование в коде требует от тебя написания тестов на equals. В команде из 5 человек кто-то обязательно забудет исправить equals, забудет исправить тест на equals, хотя можно было бы писать намного более компактный вариант класса + не писать абсолютно не нужные тесты, так как record гарантирует идентичность кодогенерации сравнения на выходе.
После других языков меня и бесконечный {get; set;} бесят (да даже после того же F#) стал жутко раздражать. И после других языков вроде kotlin вообще не понимаешь, какого черта надо это все руками делать сегодня, когда за тебя все это может и должен делать компилятор.marshinov
28.10.2021 15:03+2Может завезут короткие конструкторы из рекордов в обычные классы и тогда get; set; тоже можно будет опускать. В Kotlin же справились с этой задачей. Вообще будет прикольно, если C# начнет тырить фичи из Kotlin - языка, который изначально тырил фичи в т.ч. из C#.
ksbes
28.10.2021 11:21+1На практике плюшки дают выбор...
Знаю я один язык где выбор почти безграничен. Perl. Такое будущее у С#?
а с тем, что бы команда писала не в разнобой, в одинаковом стиле, писала наиболее компактный идентичный код, сегодня вполне успешно справляются инструменты вроде Resharper и Rider ...
Знаю я одну технологию/инструмент в JS. Babel. Она работает. Да. Но разве к такому C# стремится?
Atreides07
28.10.2021 13:36+1Языки стремятся к удобству, без него язык можно считать мертвым:
я писал SPA приложения на JS до того как это стало мейнстримом, до появления Angular, React, Vue, backbone, knokout под IE6 и могу сказать что без Babel писать на ТОЙ старой версии языка JS без Babel - дикий ад, мне до сих пор в кошмарах снится работа с часовыми поясами в офлайне на JS той версии).
Тот же TypeScript появился как будущее развитие JS и фактически вытеснил JS в средних и больших проектах, так как JS очень медленно развивался из-за того что каждое нововведение требовало обсуждения консорциума W3C и поддержки всеми браузерами.
Так что если выбирать между JS старой версии и JS с Babel - я ногами и руками за последнее. Как и в выборе между C# 2 и C# 10. До Kotlin я предпочитал писать на C# под Android. Сейчас более богатый на плюшки kotlin удобнее чем C#. А вместо Xamarin Native можно писать на KMM.
marshinov
28.10.2021 15:00Да не плохо. Из прям нужного осталось стырить abstract sealed и enum classes из Котлина, чтобы можно было паттерн-метчить DU и норм будет.
AquariusStar
28.10.2021 09:54+3Новая реализация switch в 8-й версии C# на самом деле удобна. У меня в одном проекте это самая частая конструкция, которая состоит только из одного switch в теле метода. Словари, конечно, можно использовать (почитав в комментариях), но не всегда они подходят под некоторые задачи.
Убивает язык не добавление новых возможностей, а политика компании. Если она хочет развивать NET как кроссплатформенный язык, то не только базовая часть должна поддерживать все операционные системы, но и графическая часть (GUI). Здесь Майкрософт, как всегда, отличилась — новый MAUI завязывает, в основном, на Windows-платформу. А также Android, iOS и Mac OS как дополнительная опция. А Linux оставила за бортом. Дескать, они сами разберутся. Вот и сидишь в раздумье, а не использовать ли мне уже Avalonia. Так как программирую практически на WPF, и XAML-синтаксис мне уже привычен. Да и метание Майкрософта по платформам не добавляет доверия к каждой новой платформе, которая тут же заворачивается на Windows. Ведь QT и GTK просто планомерно развивают свою платформу.
ksbes
28.10.2021 11:27Я для кроссплатформенного десктопа на C# использовал GTK-обёртку. На винде правда пришлось "тянуть" не один мегабайт дллек. Но зато один код (даже больше - один бинарник) - работает везде. А с WSL, наверное (я не знаю), такое будёт провернуть ещё проще?
AquariusStar
28.10.2021 11:36Это который GTK#?
ksbes
28.10.2021 11:37Да, он. По моему мнению - изврат, но для того проекта, за те сроки, изврат оправданный.
ldss
29.10.2021 22:01-1Новая реализация switch в 8-й версии C# на самом деле удобна
да это ж котлин!
fun fromRainbow(colorBand: Rainbow): RGBColor = when (colorBand) { Rainbow.Red -> RGBColor(0xFF, 0x00, 0x00) Rainbow.Orange -> RGBColor(0xFF, 0x7F, 0x00) Rainbow.Yellow -> RGBColor(0xFF, 0xFF, 0x00) Rainbow.Green -> RGBColor(0x00, 0xFF, 0x00) Rainbow.Blue -> RGBColor(0x00, 0x00, 0xFF) Rainbow.Indigo -> RGBColor(0x4B, 0x00, 0x82) Rainbow.Violet -> RGBColor(0x94, 0x00, 0xD3) else -> throw ArgumentException(message: "invalid enum value", paramName: nameof(colorBand)), };AquariusStar
29.10.2021 22:20+1Да. Я видел такую конструкцию ранее у Котлина. Насколько помню, именно на него ссылались, когда появилась в C#. На мой взгляд, такая необходимость в данной конструкции для C# давно назрела. Потому что такие конструкции у меня не редкость.
ldss
01.11.2021 18:32оно очень удобно и легко читается - поле зрения не засоряется всякими {} и break;
я же говорю, надо тех, кто жалуется на syntax sugar посадить на 7-8 жаву, с ее дикой многословностью и boilerplate, тогда будут ценить усилия разработчиков по созданию более лаконичных конструкций:)
EfimKR
28.10.2021 10:24+3Статья похожа на бухтение старого деда...
В последних версиях есть как и очень полезные вещи (оптимизация использования памяти с помощью Span и Memory), так и немного странные (по моим субъективным ощущениям) виды синтаксического сахара (новый switch, record). Но раз их добавляют, значит они нужны пользователям, пусть для меня они и не имеют большой ценности.
На сколько я знаю, разработка C# открыта для общественности, можно предлагать свои идеи, и, возможно, они будут включены в язык.
С++ стал нишевой технологией. Он используется или для вещей где нужна высокая производительность (базы данных) или для вещей, которые не могут быть сделаны с помощью более высокоуровневых языков (операционная система). На нем не будут разрабатывать десктопные приложения или софт для сервера, так как в этом случае на разработку тратится значительно больше времени и разработка стоит дороже.
PS Сложилось такое ощущение, что статья написана только для привлечения внимания к очередным курсам. Особенно порадовало то, что С# обучат за 12 месяцев, а C++ - за 8,5.
Chaos_Optima
28.10.2021 12:42На нем не будут разрабатывать десктопные приложения или софт для сервера
Ну да ну да, ведь там нигде не нужна высокая производительность, и пофиг что большая часть десктопных приложений на текущий момент использует в большинстве своём С++ в том или ином виде.
EfimKR
28.10.2021 12:56-1Есть специализированные приложения, которым нужна очень высокая производительность. Но в большинстве приложений этого не нужно. Если только не идет речь о производительности ради самой производительности.
В большинстве случаев оптимально использовать более мощную машину, чем разрабатывать на С++ вместо C#.
А по поводу:
большая часть десктопных приложений на текущий момент использует в большинстве своём С++ в том или ином виде.
Так почему не пойти дальше: любое приложение запускается на операционной системе, которая написана на С или С++ (а можно еще и на ассемблере), значит каждое приложение использует эти языки. Значит все разработчики, независимо от языка, должны знать С++.
Chaos_Optima
28.10.2021 15:47Есть специализированные приложения, которым нужна очень высокая производительность. Но в большинстве приложений этого не нужно.
Сомнительное утверждение, я бы сказал что большенству приложений нужна высокая производительность, браузеры, графические редакторы, текстовые редакторы, аудио редакторы, игры (это приложения которые используются постоянно). Почти в каждой сфере приложения в той или иной мере требуют высокой производительности. Разве что только этерпрайз приложения не особо парятся о производительности и то не всегда.
Значит все разработчики, независимо от языка, должны знать С++.
Я не утверждал что каждый разраб должен знать С++, я лишь осариваю ваше утверждение что С++ это нишевый язык и что на нём нет смысла разрабатывать приложения для десктопа или сервера. Впрочем я в основном утверждаю это с прозиции программиста граффики, где практически всё написано на С++ и требуется производительность. Но в других сферах как мне кажется ситуация не сильно другая. Буду рад услышать контр примеры.
KAW
28.10.2021 11:19+2Я тоже так думал, пока не провел небольшой опрос джунов. Оказалось, что для них вообще не проблема разобраться как работать с этими "новомодными" конструкциями! От слова ВООБЩЕ!
А вот у кого есть проблема, так это у "вечных мидлов".Давайте оттолнемся от этой аксиомы и попробуем сделать вывод:
В будущем в C# будет меньше "вечных мидлов"
Раз будет меньше "вечных мидлов", значит средняя зп станет выше
Раз средняя зп станет выше, больше людей будут "идти в C#"
???
PROFIT
ksbes
28.10.2021 11:31+1По п.2. не понял. Если будет меньше "вечных мидлов", но больше джунов, "для которых вообще не проблема разобраться как работать с этими "новомодными" конструкциями", то зарплата же наоборот упадёт?
KAW
28.10.2021 13:25+1Джуны достаточно быстро становятся мидлаим, а потом и сеньерами. А раз они такие активные, то в ловушку "вечных мидлов" не попадут
andlom
28.10.2021 11:53+1Пожалуй, одним из самых спорных нововведений языка стали так называемые Top-Level Statements в C# 9. Для меня C# был всегда довольно строгим и лаконичным языком, но вот это как-то ломает всю логику. Не использую их и до сих пор не понятно, кому это нужно.
Вообще, если писать достаточно много кода, весь этот синтаксический сахар довольно быстро усваивается. Во всех (почти) новых конструкциях есть своя логика. Порой очень неудобно развивать legacy-проект, если был опыт с новыми версиями .NET и C#.
orthoxerox
28.10.2021 14:54+1Ну так он и становится более лаконичным. В C# 10 Hello World состоит теперь из одной строки, что должно привлекать зумеров (или кто там за ними следует, альфачи?), выбирающих себе ЯП для изучения.
usrsse2
28.10.2021 15:39Это может быть нужно, например:
1) студентам, которые решают какие-нибудь алгоритмические задачи, для которых не нужны классы;
2) разработчикам самого Roslyn и статических анализаторов для написания более коротких тестов (в этом случае тест – это небольшая программа на C#, часто состоящая из одной функции, которая подается на вход компилятору или анализатору).
mvv-rus
28.10.2021 21:41+3Пожалуй, одним из самых спорных нововведений языка стали так называемые Top-Level Statements в C# 9.
Это в C# они новые, а в FORTRAN или ALGOL они были изначально (а вот необходимсть использовать ключевые слова program и end (обязательно — с точкой) в Pascal после этих языков, наоборот, поначалу вызывало неудобство).
playermet
29.10.2021 18:21Не использую их и до сих пор не понятно, кому это нужно.
Очень удобно, если нужно быстро проверить какое-то предположение, сделать набросок, и т.д.. Открыл вкладку в редакторе, написал, запустил, посмотрел, понял, удалил.
andlom
30.10.2021 00:12Всё равно кажется лишним, учитывая существование C# Interactive. Мне больше непонятно, почему вдруг стало так трудно написать определение одного класса и единственного метода в нём. Даже если это разовая задача, это не стоит ничего.
marshinov
30.10.2021 09:57Ну вы IL гляньте. Будет ваш любимый main, а мне на парах очень удобно: проектор не резиновый и эти два сэкономленные отступа очень помогают. Interactive мне не подходит, потому что нужно смотреть IL.
playermet
30.10.2021 11:42Встречный вопрос. А в чем профит объявлять класс и метод для кода одностраничника или даже однострочника?
C# Interactive не пробовал, но как я понимаю это REPL, а это уже немного другое. Когда нужно много раз редактировать что-то в коде и перезапускать, файл намного удобнее.
andlom
30.10.2021 13:04+1Я говорю не про профит и даже не про удобно/неудобно. Я говорю про модель, логику программных конструкций. Возможно, я немного неправильно выражаю свою мысль, попробую объяснить.
С одной стороны, метод вроде Main в компилируемых языках не просто ещё один метод, а точка входа в программу. По моему личному мнению, полезно осознавать, что среда выполнения вызывает этот метод для запуска программы. С другой стороны, по вышеизложенной же причине, Main — регулярный метод, его название это просто конвенция, по аналогии из C/C++. Короче говоря, упаковка логики в методы проста и логична и согласуется с опытом в других языках.
Ещё одна причина такого мнения — Microsoft сама привнесла дополнительное правило в свой язык, отказавшись от «свободных» функций/методов. Все методы должны быть в классах, и на мой взгляд, это придавало дополнительную «строгость» языку, если можно так сказать. Уже не будет той вакханалии как в C/C++ из смеси макросов/свободных/дружественных функций с определениями где-то там.
Я не спорю, что для многих это полезно, просто утверждаю, что для кого-то, в том числе и для меня, Top-Level Statements довольно сомнительное нововведение. Заметил это в отзывах в официальном блоге .NET.
D3ad5h0t
28.10.2021 13:07+4Очень спорная статья, мягко говоря. Язык развивается, преобразовывается, адаптируется к новым реалиям. Не вижу в этом ничего плохого. Обычно стагнация ведет к деградации и забвению. Опять же, технологии использующие в основе своей C#, набирают обороты из года в год, а кол-во вакансий с требованием знания c# множатся каждый день.
beeptec
28.10.2021 13:08А еще Инженеры от такого щебета нервно снимают шляпу перед G, который во времена MAC собирался на С++
Yarikz
28.10.2021 13:08+4C#, как и любой другой язык программирования, это инструмент, который должен развиваться в месте со средой, где он применяется. По аналогии, вам никто не мешает использовать костяной скребок для разделки мяса, но человечество придумало более совершенные инструменты.
Более того, все новые фичи активно предлагаются и обсуждаются сообществом. Сначала в репозитории C# Language Design, а затем на внутренних митингах в Microsoft, протоколы которых регулярно выкладываются там же. Из чего делаем вывод, что все новые "штуки" не случайные, и исходят не только от Microsoft.
Но что было не так с обычным оператором
switch?Такой сокращенный синтаксис с оператором
=>начал проникать в язык еще с С# 3.0, где блок кода для делегата, состоящего из одного выражения, можно было заменить однострочником, избежав церемонии с фигурными скобками,returnв случае функции, и ключевым словомdelegate. Упрощение блока switch -- это логическое продолжение этой идеи. Так же как и expression-bodied members.Но ключевое слово
varуже достаточно спорно. Зачем второе?Никогда не понимал этой претензии. Во-первых, ключевое слово
varнеобходимо для работы с анонимными типами. Во-вторых, оно позволяет избежать дублирования типа в случае, когда тип очевиден исходя из выражения. Подобные конструкции уже есть в Java и C++.Сокращенный оператор
newбез указания типа уже существовал для анонимных типов. Теперь его расширили для случаев, когда тип создаваемого объекта можно вывести однозначно, тем самым избежав дублирования, симметрично уже существующемуvar. Что особенно полезно для полей, где ключевое словоvarне применимо.В C# 10 вы можете создать свойство для свойства. Это называется поля C#.
Опять же, как и в других фичах, конкретно эта -- развитие идеи автоматических свойств. Теперь у вас есть прямой доступ к полю, что позволяет прописать дополнительную логику в
getилиsetблоках (например, вызов событияPropertyChanged), не объявляя при этом поле в явном виде. Так как поле недоступно извне этих блоков, никто не сможет его поменять в обход свойства, что в большинстве случаев полезно.Как видите, все новые фичи -- это в той или иной мере развитие идей, заложенных в язык изначально.
Phanto_m
28.10.2021 15:06У меня такое ощущение, что в комментах не поняли, что это перевод
MaksTR
01.11.2021 09:09Думаю, почти все это поняли, но если кто-то решил потратить время на перевод, да и еще опубликовал его - значит с содержанием статьи он согласен. Ладно если бы этот перевод сделал обычный юзер, но его ведь публикует контора, которая занимается обучением программированию. Если они публикуют переводы статей, в которых автор явно с темой знаком довольно поверхностно, то уже возникают вопросы о том, каков же уровень знаний у самих ребят из SkillFactory
Phanto_m
01.11.2021 09:11Там в тегах указано "юмор", автор мог просто посчитать забавным и перевести
MaksTR
01.11.2021 09:38+1Хм, действительно, есть в тегах "юмор" и "юмор?". Лично мне как-то сложно оценить статью как "забавная". А теги не могли добавить уже после того как пошла критика в комментариях и статья ушла в минус? Но даже если перевод сделан из-за того, что переводчик посчитал статью забавной, все равно публикация подобной статьи в блоге школы программирования очень сомнительна. Сколько людей после прочтения статьи смотрят еще и в список тегов? Я, например, обратил на него внимание впервые за многие годы и только после Вашего комментария. В итоге ряд людей, прочитавших статью, на ее основании могут составить себе неверную картину.
KvanTTT
28.10.2021 20:14Статья не понравилась, автор либо хайпожор (видимо как и те, кто его перевел), либо дурачок. Собственно, на медиуме большинство комментариев вида: "жаль, что здесь нельзя минусовать", "я только что потратил N минут на чтение этого недоразумения".
mvv-rus
28.10.2021 21:38+1В статье (и в оригинале тоже) имеется откровенная чушь, свидетельствующая просто о незнании предмета (и, похоже, вообще ООП):
В C# 10 вы можете создать свойство для свойства. Это называется поля C#.
Поля — это не свойства. Это данные, являющиеся частью объекта, хранящиеся в нем. Они есть во многих объектно-ориентированных языках, в том числе — и в тех, в которых нет концепции свойства (к примеру C++ поля были изначально). А в C# 10 просто добавляется синтаксический сахар для работы с анонимными полями (до того для программиста невидимыми), поддерживающими автоматически реализуемые свойства — т.е. автоматически реализуемыми можно будет сделать больше свойств.
И вот после таких ошибок читать статью уже не хочется. Хотя опасения ее автора мне понятны: я помню такой язык PL/1 и немало работал с ним. И для того времени он был просто перегружен разноообразными возможностями, в том числе — специфичными для платформы IBM mainframe, к примеру — поддержкой наборов данных с индексно-последовательным метода доступа прямо в языке (помнит ли кто сейчас о таком?). А потому за пределы мейнфреймов он пракстически так и не смог выйти, а мне пришлось учить C (что, правда, было совсем не сложно).
Вот и автор опасается такой судьбы для C# из-за его перегрузки возможностями. Ну, не знаю, не знаю — без большинства новоых возможностей, конечно, обойтись можно (как обходились без них предыдущие годы), но вот платформенно-зависимых, действительно опасных для развития языка, среди новых возможностей как-то не наблюдается.
FreddyFox
29.10.2021 03:08+2Язык развивается, добавляются, более удобные и приятные вещи == язык умирает.
Мда, лютая дичь.
ReaderReader
29.10.2021 14:55+1Крайне странная аргументация. Основной посыл автора: если в C# что-то уже можно сделать имеющимися средствами, не надо вводить более удобные альтернативы, т.к. это усложняет язык. При этом как и большинство адептов такой позиции он устанавливает планку "сложности", "удобства", "достаточности" и т.п., используя в качестве аргументации "этого уже достаточно". Например:
Я начал подозревать это, когда увидел новые выражения switch в C# 8
Эммм… Простите, какой еще switch? Ведь его можно выкинуть и все сделать через if / else. Почему автор не предлагает выкинуть switch, ведь по его логике это упростит язык? А где преложение выкинуть операторы цикла, когда у нас есть if и goto? Автор совершенно произвольно устанавливает планку "достаточности", а потом недоуменно вопрошает, почему остальные не хотят с этой планкой согласиться.
Ну и на закуску прекрасное
Ведь все мы любим пошутить над тем, какое раздутое месиво этот C++. По этой причине его больше и не используют.
C++ более не используют? В какой альтернативной вселенной находится автор?
https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/
Ilya81
29.10.2021 16:41Проблема с C# была в том, что он всегда был слишком многословным. Это у него от Java. Настолько, что я часто в шутку называл его Java#.
Нечто вне моего понимания, могу сказать, что ещё за многословность, это вообще о чём? Разве что намёк на C++ может что-то подсказать, но я выбрал не его по другим причинам - прежде была слабая типизация (точно не знаю, но слышал, что эту проблему решили) и я полагал, что он своё отжил, но всякий раз оказывалось нет так, разве что Rust может ещё станет заменой. Хотя, мысль интересная тем, не в этом ли причина нынешнего доминирования Python и JavaScript. Но мне совсем непонятно, например, зачем `#pragma warning disable` заменять на какое-то синтаксическое извращение, по мне совсем напротив, в C# вместо полезных функций добавляют всё новые синтаксические извращения. А уж у Java проблемы всяко не в синтаксисе, по мне с синтаксисом у него всё хорошо.
Кстати, в Swift с синтаксисом пришли к тому, что теперь полноценный компилятор с осмысленными сообщениями об ошибках сделать никак не могут, и, видимо, не смогут когда-либо, все выражения приходится проверять вручную, компилятор подсказать ничего не может.
ksbes
29.10.2021 17:03Java больше многословен из-за соглашения об именовании (в т.ч. классов и методов стандартной библиотеки). Всё-таки это грамматичеcки одно и то же:
1) A a = new A();
2) МойОченьКрутойКласс переменнаяМоегоОченьКрутогоКласса = new МойОченьКрутойКласс();
Ilya81
03.11.2021 22:04Не знаю, кому как, а мне часто бывает очень сложно понять, что делает какая-то функция, названная одной буквой, особенно если переменные внутри и вызываемые там функции тоже названы одной буквой.
ldss
29.10.2021 18:42+2Могу дать совет - попишите на жаве 8 (да или даже 11). После чего будете с дикой радостью приветствовать все эти новые фишки с#:)
Они отличные все, и жалобы мне напоминают стенания по поводу лямбд в свое время - все точно так же кричали, зачем это нужно, это непонятный бред а не нормальный язык!
Меня тогда, помню, вовсю на работе полоскали - какого хрена я втыкаю эти непонятные конструкции
SergeyProtector
29.10.2021 19:59Я до сих пор пишу на С (да, да на оригинальном С) и С++, активно использую С#. Каждый язык имеет свою нишу. А если люди используют что попроще, то это не значит, что язык мёртв. Автор не прав.
moroz69off
30.10.2021 04:57+3Дорогие Друзья!
Уважаемые коллеги!
Посмотрите на количество и пёструю тематику статей в блоге автора. За октябрь.
У меня всё.
А! Нет, не всё: skillfactory, переведите уже что-нибудь полезное... Спасибо.
LARII
31.10.2021 18:15+1Но когда вы в последний раз видели фреймворк высокого уровня, использующий C++?
Вчера, и каждый день. Этот фреймворк высокого уровня - 1С, который использует native внешние компоненты на C++.
Areso
Окей, вот мои 5 центов:
1) я пытался использовать C# для WP платформы, но они умерли (7,5, 8, 10)
2) я пытался использовать C# для UWP, но они превратились в ходячих мертвецов
3) C# использовал для Desktop-приложений, но потом Microsoft, сообразив на двоих Google, фактически убил запуск неподписанного кода для домохозяек. Сорян, платить 250 баксов в год за воздух, точнее сертификат, которым Мейлру подписывает свой Мейлру бар, я не вижу смысла. А, и еще разрешает подписывать (разрешал, окей) им любой код "партнёров". Но у Мейлру это безопасно (потому что подписано), а у меня нет.
Так, я полностью ушёл с платформы (т.е. дропнул Windows, MS SQL Server, VS, C#). Теперь винда нужна только для запуска игрушек, которые не заводятся в Valve Proton/WINE.
P.S.: бывший MCSA, владелец аккаунта-разработчика для WP/UWP.
lek
Подпишусь под этим комментарием. Новый new - самая последняя проблема с майкрософтовским стеком. После дропа всей этой байды и перехода на Linux качество жизни улучшается, а ваши волосы становятся длинными и шелковистыми.
NickKolok
Причём и в бороде тоже :-)
yozshujar
Да даже в бровях.. xD
NurGeo
Как же неудобно сказать про это…
oblogood
Морально-этическое обязательство откомментироваться под этим гениальным материалом не скатившись до амплуа соображающего, о чём идёт речь посреди прекрасных комментариев к этому материалу, приводит к появлению этих слов, перегружающих этот оператор указания на проблему .chm from hh.exe в чудесной виндовской файлопомойке гигабайтного реестра. Фактически ваша песенка спета и карта бита. Иное дело, что за покерфэйсом имеется и другая жизнь, и жизнь эту хотелось бы вести, а не объектить клоуном за баланду на галере. Следовательно: Джобс, Гейтс, Торвальдс. Таковы три хардера, сломавшие дешёвый сахарный хайп цукербринов имени Павлика Морозова, диктатуру вахтёр-модераторов. Всё остальное время идёт просто исключительно в сортировку противостоящих сил, как после Второй Мировой англо-американцы с Европой и половиной Германии напали на СС в одной упряжке с коммунистическим Китаем в пространстве Восточной Европы незаконченного разговора Первой Мировой. Решить это без предварительного морально-этического плебисцита убийства цифрового неравенства ретроградное не сможет, а сюжеты разговоров там превращаются вообще в другое, а не в глупейшее обсуждение "жо или жё"? ЖЫ.
SlimShaggy
Вы случайно родились не на улице Герцена?
oblogood
Любите Эллочку Людоедку, парниша?
vladshulkevich
В основном только в бороде
noize
Выскажу немного неочевидную вещь для тех, кто всю жизнь использовал Windows для работы/программирования: писать код под Linux/MacOS гораздо проще, приятнее и понятнее что-ли.
Десктопные приложения под Linux может быть и менее удобно делать, но вот всё, что касается серверной разработки - это просто песня.
max_mustermann
А кто у нас на серверах? Да вот Java например.
И что, писать серверный код на Java для Linux/MacOS проще, приятнее и понятнее чем для Windows, правда?
Да, это довольно неожиданный вывод.
Areso
Java живёт в JVM.
Давайте смотреть на язык без своей виртуальной машины.
На Питоне (или PHP) действительно под Linux писать действительно приятнее. Вплоть до того, что за совместимость с Windows я беру доп.деньги с заказчика.
SlimShaggy
Ага, или .net core :)
lek
Да, даже с самого начала, просто в части "установить все это добро/настроить среду". Линукс в разы проще в этом плане. Особенно для всяких С++ библиотек, когда на линукс ты вводишь пару команд, а на виндоуз часами сражаешься с инсталлерами и билд системами. То, что твоя среда оказывается максимально близкой к продакшену, тоже весьма существенный плюс. Ну и полный контроль над системой без назойливых апдейтов, рекламы и очередного Раджеша Кутрапали с той стороны, который знает, что для тебя лучше и пытается впихнуть это лучше тебе в глотку.
oxx
в оригинале было "мягкими и шелковистыми"
FakeOctopus
Теперь домохозяйки поставят Linux?
Areso
Несмотря на то, что это похоже на подкол или шутку, отвечу серьезно.
Нет. Теперь моим домохозяйкам вообще ставить ничего не надо - все крутится в вебе, нередко даже без бэкэнда.
А для веб разработки я даже тогда выбирал PHP, сейчас правда на Питон съехал. По экономичности ресурсов и нетребовательности к окружению, они были, да наверное и есть гораздо более выгодный вариант, что важно в хоббийной разработке и разработке на фрилансе.
infund
Всё же нет. Если речь о предлагаемой миграции на Windows App SDK, то...
Отсюда
Enfriz
Кажется, есть в этом всём что-то от синдрома утёнка. Те, кто зашёл в C# давно ещё на Microsoft-стеке для дектопов, не могут отделаться от некоторых старых штампов даже в собственном использовании языка.
Я вот зашёл в C# три года назад сразу в .NET Core. Я никогда не пользовался MSSQL и Visual Studio, а на серверах у меня бессменно стоит Ubuntu. Сразу пишу кроссплатформенный веб на ASPNET Core, уже есть несколько проектов на Blazor. Пришёл в шарп прямиком с Java, и моё качество жизни сильно улучшилось. Java очень многословна и консервативна, но значимых преимуществ по возможностям и скорости по сравнению с шарпом не имеет. При этом никакого негативного опыта и боли со всякими WP/UWP у меня нет, и поэтому мне хорошо.
Areso
1) Согласен
2) .NET Core - не пробовал, его место было уже занято (у меня)
3) Вас еще не кидал платформодержатель, да :)
lek
C#, возможно, приятнее Java, это да. Но вы просто подождите. До следующего вайпа. Майки обязательно что-нить дропнут и сольют годы вашего опыта в унитаз.
Enfriz
У меня были годы опыта на Flash, и рынок его убил. Потом были годы опыта на PHP, но с появлением новых более совершенных языков я сам с него ушёл. Технологии отмирают, это нормально. А каждый специалист по jQuery в своё время должен был переучиться на React или отойти от дел.
lek
Когда технологии умирают, это нормально. Когда их убивают - не очень. В мире открытого кода таких ситуаций гораздо меньше, плюс всегда можно взять и скомпилировать библиотеку для более новых ос, если официальной поддержки нет. Как правило, это не слишком сложная задача. Но в случае с проприетарными закрытыми продуктами это невозможно.
Krey
net core на гитхабе лежит и там же и развивается
KReal
а ушли куда?
Areso
1) для домохозяек - Web-apps (JS, PHP/Python если нужен бэк).
2) для души - Python в Linux-окружении, как правило, даже без морды, просто консоль.
3) для веб-серверов я ASP.NET никогда и не рассматривал (хотя и админил/дебажил совсем немного), так что тут PHP/Python/совсем недавно Go - все в Linux окружении
Carburn
Для Win32 приложений подпись не нужна.
Areso
А что, если мы сначала выгрузим Win32 приложение в Интернет
А потом скачаем на другом ПК и попробуем запустить?)
"SmartScreen has blocked bla-bla"
Elsajalee
Про 3: мне кажется, про "250 баксов" вы одну вещь забыли: не напомните, сколько минимально стоил VS для выпуска коммерческого приложения до Community 2015?
Areso
Подписывать требуется любые exe файлы, а не только из VS Enterprise
У меня в разные года была пиратка (до 2007), студенческая (с 2008), ну и на моей работе была лицуха (начиная с 2011, до того перебивался разными вариантами в т.ч. с крякнутыми лицензиями Delphi и VS у работодателей или пользованием своей лицензии студенческой в коммерческих целях).
Elsajalee
Естественно, любые и VS тут ни при чём. Только я про то, что коммерческий релиз ПО под Windows формально (без ваших способов обмана) всегда стоил денег. И стал стоить куда меньших денег, начиная с 2015 года. А если не брать в расчёт домохозяек, то вообще - бесплатно. Поэтому жаловаться на целых 250 баксов, конечно, можно, только у многих это "всего-навсего 250 баксов".
Areso
Сейчас я работаю в большой компании в городе, из которого ехать только зарубеж; и даже на таких вводных на свое хобби трачу меньше, а это хостинг, доменное имя, платная электронная почта и вот это все; а тогда, когда началась эта фигня, после универа, жил и работал в родном городе на окраине вселенной. И тогда 250 баксов были сопоставимы с ценой новенькой mid range видеокарты. По сегодняшнему курсу видеокарт - 60 тысяч ;). Доллара - 20 косарей.
Elsajalee
Если вы изначально планируете заработать на приложении на одну видеокарту, то ок, аргумент принят.
Areso
Я на этих приложениях не планировал зарабатывать совсем. Это хобби.
Для заработка я хожу на работу, там мне выдают ноутбук, доступ к виртуализации и Intellij IDEA.
И мне абсолютно всё равно, сколько стоит ноутбук, виртуализация и лицензия Intellij IDEA.