Комментарии 171
Окей, вот мои 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.
Подпишусь под этим комментарием. Новый new - самая последняя проблема с майкрософтовским стеком. После дропа всей этой байды и перехода на Linux качество жизни улучшается, а ваши волосы становятся длинными и шелковистыми.
Причём и в бороде тоже :-)
Да даже в бровях.. xD
Морально-этическое обязательство откомментироваться под этим гениальным материалом не скатившись до амплуа соображающего, о чём идёт речь посреди прекрасных комментариев к этому материалу, приводит к появлению этих слов, перегружающих этот оператор указания на проблему .chm from hh.exe в чудесной виндовской файлопомойке гигабайтного реестра. Фактически ваша песенка спета и карта бита. Иное дело, что за покерфэйсом имеется и другая жизнь, и жизнь эту хотелось бы вести, а не объектить клоуном за баланду на галере. Следовательно: Джобс, Гейтс, Торвальдс. Таковы три хардера, сломавшие дешёвый сахарный хайп цукербринов имени Павлика Морозова, диктатуру вахтёр-модераторов. Всё остальное время идёт просто исключительно в сортировку противостоящих сил, как после Второй Мировой англо-американцы с Европой и половиной Германии напали на СС в одной упряжке с коммунистическим Китаем в пространстве Восточной Европы незаконченного разговора Первой Мировой. Решить это без предварительного морально-этического плебисцита убийства цифрового неравенства ретроградное не сможет, а сюжеты разговоров там превращаются вообще в другое, а не в глупейшее обсуждение "жо или жё"? ЖЫ.
В основном только в бороде
Выскажу немного неочевидную вещь для тех, кто всю жизнь использовал Windows для работы/программирования: писать код под Linux/MacOS гораздо проще, приятнее и понятнее что-ли.
Десктопные приложения под Linux может быть и менее удобно делать, но вот всё, что касается серверной разработки - это просто песня.
А кто у нас на серверах? Да вот Java например.
И что, писать серверный код на Java для Linux/MacOS проще, приятнее и понятнее чем для Windows, правда?
Да, это довольно неожиданный вывод.
Да, даже с самого начала, просто в части "установить все это добро/настроить среду". Линукс в разы проще в этом плане. Особенно для всяких С++ библиотек, когда на линукс ты вводишь пару команд, а на виндоуз часами сражаешься с инсталлерами и билд системами. То, что твоя среда оказывается максимально близкой к продакшену, тоже весьма существенный плюс. Ну и полный контроль над системой без назойливых апдейтов, рекламы и очередного Раджеша Кутрапали с той стороны, который знает, что для тебя лучше и пытается впихнуть это лучше тебе в глотку.
в оригинале было "мягкими и шелковистыми"
Теперь домохозяйки поставят Linux?
Несмотря на то, что это похоже на подкол или шутку, отвечу серьезно.
Нет. Теперь моим домохозяйкам вообще ставить ничего не надо - все крутится в вебе, нередко даже без бэкэнда.
А для веб разработки я даже тогда выбирал PHP, сейчас правда на Питон съехал. По экономичности ресурсов и нетребовательности к окружению, они были, да наверное и есть гораздо более выгодный вариант, что важно в хоббийной разработке и разработке на фрилансе.
2) я пытался использовать C# для UWP, но они превратились в ходячих мертвецов
Всё же нет. Если речь о предлагаемой миграции на Windows App SDK, то...
For developers using the Universal Windows Platform (UWP) project types, if you are happy with your current functionality in UWP, there is no need to migrate your project type. WinUI 2.x and the Windows SDK will continue to support UWP project types, including bug, reliability, and security fixes.
Кажется, есть в этом всём что-то от синдрома утёнка. Те, кто зашёл в C# давно ещё на Microsoft-стеке для дектопов, не могут отделаться от некоторых старых штампов даже в собственном использовании языка.
Я вот зашёл в C# три года назад сразу в .NET Core. Я никогда не пользовался MSSQL и Visual Studio, а на серверах у меня бессменно стоит Ubuntu. Сразу пишу кроссплатформенный веб на ASPNET Core, уже есть несколько проектов на Blazor. Пришёл в шарп прямиком с Java, и моё качество жизни сильно улучшилось. Java очень многословна и консервативна, но значимых преимуществ по возможностям и скорости по сравнению с шарпом не имеет. При этом никакого негативного опыта и боли со всякими WP/UWP у меня нет, и поэтому мне хорошо.
1) Согласен
2) .NET Core - не пробовал, его место было уже занято (у меня)
3) Вас еще не кидал платформодержатель, да :)
C#, возможно, приятнее Java, это да. Но вы просто подождите. До следующего вайпа. Майки обязательно что-нить дропнут и сольют годы вашего опыта в унитаз.
У меня были годы опыта на Flash, и рынок его убил. Потом были годы опыта на PHP, но с появлением новых более совершенных языков я сам с него ушёл. Технологии отмирают, это нормально. А каждый специалист по jQuery в своё время должен был переучиться на React или отойти от дел.
Когда технологии умирают, это нормально. Когда их убивают - не очень. В мире открытого кода таких ситуаций гораздо меньше, плюс всегда можно взять и скомпилировать библиотеку для более новых ос, если официальной поддержки нет. Как правило, это не слишком сложная задача. Но в случае с проприетарными закрытыми продуктами это невозможно.
1) для домохозяек - Web-apps (JS, PHP/Python если нужен бэк).
2) для души - Python в Linux-окружении, как правило, даже без морды, просто консоль.
3) для веб-серверов я ASP.NET никогда и не рассматривал (хотя и админил/дебажил совсем немного), так что тут PHP/Python/совсем недавно Go - все в Linux окружении
Для Win32 приложений подпись не нужна.
Про 3: мне кажется, про "250 баксов" вы одну вещь забыли: не напомните, сколько минимально стоил VS для выпуска коммерческого приложения до Community 2015?
Подписывать требуется любые exe файлы, а не только из VS Enterprise
У меня в разные года была пиратка (до 2007), студенческая (с 2008), ну и на моей работе была лицуха (начиная с 2011, до того перебивался разными вариантами в т.ч. с крякнутыми лицензиями Delphi и VS у работодателей или пользованием своей лицензии студенческой в коммерческих целях).
Естественно, любые и VS тут ни при чём. Только я про то, что коммерческий релиз ПО под Windows формально (без ваших способов обмана) всегда стоил денег. И стал стоить куда меньших денег, начиная с 2015 года. А если не брать в расчёт домохозяек, то вообще - бесплатно. Поэтому жаловаться на целых 250 баксов, конечно, можно, только у многих это "всего-навсего 250 баксов".
Сейчас я работаю в большой компании в городе, из которого ехать только зарубеж; и даже на таких вводных на свое хобби трачу меньше, а это хостинг, доменное имя, платная электронная почта и вот это все; а тогда, когда началась эта фигня, после универа, жил и работал в родном городе на окраине вселенной. И тогда 250 баксов были сопоставимы с ценой новенькой mid range видеокарты. По сегодняшнему курсу видеокарт - 60 тысяч ;). Доллара - 20 косарей.
медленное и постепенное снижение популярности языка.
Ну да, майки подвезли .net core, развивают xamarin, ASP.Net, бизнес хочет ещё сотрудников, по всем направлениям, а популярность шарпа умирает.
Даже геймдев на юнити и мобилках хочет заманить побольше людей на свою галерку
Ох уж эти умирающие языки.
Тенденции переполнения стека показывают резкое снижение количества вопросов с середины 2009 года
Вы это серьёзно? Совсем перевод не вычитывали перед публикацией?
В примерах я вижу сброс C и Java-подобного балласта. Да, времена меняются, и писать каждый раз break в операторе switch это просто странно, учитывая то, насколько его редко надо не писать, а необходимость добавлять закрытую переменную для свойства просто удваивает объем кода.
Конечно, это все синтаксический сахар, только вот этот сахар будет использован тысячи раз и сократит сотни тысяч строк кода, а еще уберет много болезненных ошибок.
Делать что-то лучше? Так это еще более усложнит язык. Посмотрите на раст, как раз язык где абстракция максимальна. По факту это 3 языка (сам раст, макросы, процедурные макросы), наслоенные друг на друга. Ну или там хаскель.
Насчет дарта удивился. Даже банальная конвертация JSON в объект это боль по сравнению со Swift, где просто приписываешь: Codable к названию объекта и готово. В свифте это зашито в компилятор и нельзя самому создать протокол, который генерит код? Плохо, да, но и пофигу, основные юзкейсы-то покрыты.
Как раз самые популярные языки и есть сплошное наслоение синтаксического сахара, потому что абстракция в коде далеко не равна повышению абстракции в задаче, а вот ментальная модель кода усложняется куда там. Вот и получается, что языки типа Rust, Scala, C++ или Haskell со всей их абстрактностью не являются “мейнстримными”.
Вот и получается, что языки типа Rust, Scala, C++ или Haskell со всей их абстрактностью не являются “мейнстримными”.
Ну ладно: Haskell, Scala, Rust… но C++? Те же самые 77000 предложений, что и для C#.
Вы, вообще, по каким критериям “мэйнстриймовость” определяете?
Это, конечно, умозрительно, но вакансий по поддержке легаси очень много на плюсах. Все-таки на этом языке раньше писали практически всё, не удивительно, что надо это кому-то поддерживать.
Но зачем выбирать плюсы сегодня? Наверное, если есть подходящая библиотека, ради производительности в высоконагруженных задачах, ну и еще есть UE и Qt.
На C# есть, конечно, и поддержка старых Windows-приложений, но в основном, думаю, это бекенд, Unity и немного Xamarin. И соотношение новых и старых проектов там сравнимо с другими языками.
И проектов много новых на плюсах.
Но зачем выбирать плюсы сегодня?
Не “зачем”, а “почему”. Потому что 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#).
На счет -"в любом автомобиле куча чипов" потому нужны c++ програмисты.
Слышал что с++ програмеров которые могут програмировать микроконтроллеры мало они дорогие.
по этому производители начинают использовать в своих продуктах более мошьные чипи которые могут запускать Linux и програмеров под линукс проще найти.
Короче компании выгоднее ставить немного более дорогой чип но при этом экономить на софте.
Слышал байки про то как такое простое устройство как контроллер сидения в автомобиле работает на линуксе, и это только один из многих контроллеков в машине.
В котлине конвертация в JSON сделана ещё лучше. Ставишь в виде зависимости препроцессор-кодогенератор, помечаешь класс аннотацией и кодогенератор сам пишет конвертацию. То есть и язык не захламляет, и всегда есть возможность подобную штуку самому сделать
Конечно, это все синтаксический сахар, только вот этот сахар будет использован тысячи раз и сократит сотни тысяч строк кода, а еще уберет много болезненных ошибок.
Этот "синтаксический сахар" начинает подбешивать потихоньку. Подается как "самое новое и крутое". Смотришь в IL - а там все тоже самое, что и было раньше, только "новое" и если ты раньше это делал руками или snippets себе наделал, то сейчас это генерирует компилятор. Если бы можно было самому делать такой "синтаксический сахар" без черезмерных усилий - было куда полезнее...
Смотришь в IL — а там все тоже самое, что и было раньше
Это вроде бы и есть часть определения «синтаксический сахар», нет?
Код .Net открыт )
Есть Nemerle
Подается как "самое новое и крутое". Смотришь в дезассимблированный код - а там все тоже самое, что и было раньше, только "новое" и если ты раньше руками управляющие байты вбивал или перфоркарт себе наделал, то сейчас это генерирует компилятор.
Подается как "самое новое и крутое". Смотришь в дезассимблированный код - а там все тоже самое, что и было раньше, только "новое" и если ты раньше руками управляющие байты вбивал или перфоркарт себе наделал, то сейчас это генерирует компилятор.
Этот "синтаксический сахар" начинает подбешивать потихоньку.
Это к психотерапевту.
Подается как "самое новое и крутое"
Ничто,никому не подается. Не хочешь - не используй. Самое новое и крутое, обычно, происходит в рантайме, а не в языке. У инженера должна быть возможность писать качественный софт и возможность его оперативно поддерживать, а не радоваться новому свитчу.
Смотришь в IL - а там все тоже самое, что и было раньше,
Это и есть синтаксический сахар.
Если бы можно было самому делать такой "синтаксический сахар" без черезмерных усилий
Есть Розлин - вперёд. Пусть только все ИДЕшки научатся это поддерживать. Я не вижу в этом особой полезности.
Это к психотерапевту.
Спасибо за заботу.
Есть банальная логика - запоминать одну базову вещь, заложенную на уровне стандарта, или еще пачку наворотов с их нюансами, придуманными за тебя "тем парнем" ? или иметь возможность самому, на уровне исходного кода внутри проекта делать что тебе удобно ?
мой приоритет - иметь как можно больше контроля в своих руках, и как можно меньше полагаться на "магию".
Я бы с удовольствием бы использовал механизм вроде #define из C++
Спасибо за заботу.
Всегда на страже.
мой приоритет - иметь как можно больше контроля в своих руках
.net по сути, уже позволяет писать практически на ассемблере. Есть интристикс апи, которым мы иногда даже пользуемся. Есть конструкции которые позволяют не покидать стек. Есть возможность работать, практически, с нулевой актиностью GC. По сути, (кроме граничных случаев) я не вижу смысла писать на тех же плюсах. Выигрыш в производительности в большинстве случаев, будет минимальный. При том, что я упускаю вопрос - а нужна ли вам такая производительность. Какой контроль еще Вам нужен, я не понимаю.
Я бы с удовольствием бы использовал механизм вроде #define из C++
ух... мне кажется, Вас сейчас здесь забьют :) Я лично такого дерьма насмотрелся с этим препроцессором... с этим пунктом я точно не соглашусь.
пока язык хорошо выполняет свои задачи, на нем будут писать, но ничто не вечно под луной 😂
switch изначально дурацкая конструкция, надо туда сюда его прокручивать. Вместо него лучше использовать словарь. Новый синтаксис улучшает его читаемость и он компактнее.
var позволяет не выяснять тип и избегать возможных неявных приведений типа.
Упрощенный вызов конструктора тоже уместен если тип уже известен.
switch это конструкция унаследованная от С. В С можно использовать только int или приводимые к ним переменные. С вариант switch хорошо ложиться в команды процессора, гораздо лучше чем каскад if else. Насчет лучшей генерации bytecode для языков на подобии Java/C# и т.п. не уверен.
Думаю, нужно использовать deprecated для устаревших конструкций. Да, это по сути форкнуть язык, но расползание синтаксиса тоже ни к чему хорошему не приведет
Новый свитч - это паттерн матчинг. Зачем новый new? Полагаю, чтобы не повторять два раза длинные типы, там где var нельзя использовать. private var _field = new длинный_длинный_тип_с_джинериками() сделать нельзя, или я не прав? Я, кстати, на C# не программирую, но для чего эти изменения были сделаны очевидно. Собствнно, как я не програмиирую на С#, так и вы, скорее всего не слишком далеко заглядывали за границы императивных языков. До того, как критиковать нечто, можно для начала ознакомиться с "течением мировой мысли по поводу", так сказать. Например, хотя бы с тем, что такое pattern matching и зачем он нужен.
Автор - какая-то истеричка.
Switch expression - очень удобная штука позволяющая писать более компактный код не теряя его читабельности.
private List<WeatherObservation> _observations = new();Также очень удобная штука место которой исключительно в объявлении приватных членов класса с созданием дефолтных значений. Уж куда лучше так писать, чем по-старинке:
private List<WeatherObservation> _observations = new List<WeatherObservation>();Очевидно, что пихать его в сами функции рядом с var нет никакого смысла.
В C# 10 вы можете создать свойство для свойства. Это называется поля C#. Хорошо, сделано это для автоматических свойств. Но я не знаю, почему бы просто не использовать обычное свойство.
Ах вот оно в чем дело, просто автор какой-то подросток который еще не до конца разобрался с языком. Поля были добавленны не в 10-й версии, а с самой первой. Чтоб узнать в чем их отличие и почему они не заменяют проперти, можно сходить в документацию. В 10-ке просто добавили сахара позволяющего работать с полями лаконичнее, делая код более компатным без ущерба читабельности. По мне так отлично, ибо каждый раз когда вынужден использовать поля в паре с пропертями испытываешь негатив от многословности сего действия.
Помню времена, когда linq добавили, тоже было море плача от подобных товарищей.
Помню времена, когда linq добавили, тоже было море плача от подобных товарищей.
Честно говоря, не знаю был ли linq в конечном виде оригинальной идеей или таки повторением за кем-то, но так органично встроить функциональный стиль в мейнстримовый язык, строго имхо, идея на грани гениальности. И, опять же на мой взгляд, одно из полезнейших и удобнейших изменений из случившихся с .net после запуска.
Честно, мне после Linq-а все остальные языки без подобного кажутся неполноценными.
Прямо дико удваиваю.
С года два назад потребовалось "вот прямо сейчас в моменте и быстро" набросать какую-то мелочь на java (никаких фреймворков, просто консольное микроприложение API со встроенным вебсервером и субд на SQLite). "Ну ерунда вопрос" - подумал я, - "подумаешь, на Java ни раз в жизни не писал, всего то консольное приложение, синтаксис похож, да и гугл под рукой".
В целом написал, но в процессе был СИЛЬНО удивлен отсутствию LINQ (или даже хотя бы чему то похожему на него), настолько оно казалось мне органичным и логичным в С#
Java Streams
Только для памяти. Никаких вам деревьев выражений.
Что насчет Speedment? https://github.com/speedment/speedment
Нету деревьев выражений как элемента языка(платформы) или ORM его не поддерживают?
Первое давно есть основано на механизме classloader+bycode изменений в runtime.
Например в Java достаточно @Asynchronous, не нужны изменения языка за счет добавления await/async
Насчет второго скорее всего все привыкли пользоваться QL или вообще на автогенерацию SpringJDBC полагаться. Будет нужно допилят.
А можете дать ссылку на @asynchronous?Я не представляю как аннотацией синхронный IO на асинхронный изменить. Project Loom вроде собирается такое делать, но это ж сколько байткода переписывать… Касательно «привыкли»: привыкли же не значит, что это хорошее решение, просто за неимением альтернатив. Не подумайте, некоторые вещи в Java мне нравятся больше, чем в .NET, но работа с бд в этот список не входит.
Смотрите документацию на javax.ejb.Asynchronous было доступно в древнем JBoss.
На самом деле там не так сложно, на хабре была статья как устроен async/await внутри. В Java для давно доступен не блокирующий NIO.
Java Web/ORM/AOP всегда использовали внедрение кода для расширения функциональности. Даже code coverage библиотеки внедряют вызовы touch("filename",lineNumber). Т.е. технология очень популярная и востребованная.
Я знаю как устроен async/await внутри. Я о том, что без переписывания байткода в CPS будет две модели программирования: синхронна и асинхронная и придется держать в голове 100500 операторов Rx. В случае с await все это уезжает за кулисы, а код выглядит синхронным.
Если @Asynchronous - это оно, то Future же придется писать через .then.then.then в promise-стиле. async/await завезли ровно, чтобы этого избежать.
Вам сразу стоило взять Kotlin. Там все это есть и даже больше
И все еще нет деревьев выражений...
вот мне интересно, насколько широко они используются
потому что если в виде
var expr: (Int)->Int = x -> when (x)
{
1 -> 0
0 -> 1
else -1
}так такое и в котлине есть
Причем вот как раз там лямбды сделаны сильно лучше:)
Я про C#
я к тому, что сишарп прекрасен, и в свое время был ваще самым прогрессивным и офигенным языком (да и сейчас, их имплементация женериков до сих пор на голову выше многих конкурентов)
Но вот эти новые фичи, на которые жалуются - они не новые, на самом деле, и уже б-м давно присутствуют в других языках. И сишарп в данный момент, увы, в позиции догоняющего
Если сравнивать с Kotlin, то здесь работает тот же принцип, что помог C# стать лучше Java: когда язык проектировали не было легаси и можно было спокойно скопировать удачные решения Java, а неудачные - исправить. Сейчас те же nullable reference types пришлось костылить потому что нельзя просто так исправить всю систему типов. + фичей в языке уже так много, что приходится очень аккуратно выбирать, что добавить, а что нет. Вообще будет забавно, если в какой-то момент C# устареет как Java и появится Kotlin от CLR, но пока вот не видно, чтобы Kotlin совсем уж Java похоронил. Многие считают, что Java 17 даже предпочтительнее Kotlin. Так что поживем - увидим.
Если сравнивать с Kotlin, то здесь работает тот же принцип, что помог C# стать лучше Java: когда язык проектировали не было легаси и можно было спокойно скопировать удачные решения Java, а неудачные - исправить.
Котлин - java compliant language, т.е., из него генерится ровно тот же байткод, что и из жавы. Т.е., женерики там - такое же г:(
Сейчас те же nullable reference types пришлось костылить потому что нельзя просто так исправить всю систему типов
Это да
Но в К. масса других полезных вещей. Давеча коллега опять присел на c#, так с удивлением спрашивал - как это в обьявлении класса нельзя конструктор с пропертями обьявить?!:)
Многие считают, что Java 17 даже предпочтительнее Kotlin
свят-свят
Вообще будет забавно, если в какой-то момент C# устареет как Java
нууу, это сомнительно. Все-таки у сишарпа основной разработчик один, а не эта рыхлая масса как в жаве
Котлин - java compliant language
Еще и в JS, а там стирающиеся дженерики - самое то. Ну и inline reified T все-таки никто не отменял. Костыли конечно, но работает же:)
Конструкторы с пропертями можно для рекордов. Думаю, через пару версий втащат и в классы (ну глядя на C#10: как там акуратненько рекорды для структур всунули).
Конструкторы с пропертями можно для рекордов. Думаю, через пару версий втащат и в классы (ну глядя на C#10: как там акуратненько рекорды для структур всунули).
ну дай-то бог
а то мне в свое время переход на жаву тяжело дался, а потом появился котлин, и настало щастье
А потом я опять немного пересел на шарп, и возникли, знаете ли, вопросы
Имеете в виду Java < C# < Kotlin?
Если уж совсем в дебри углубляться,
C++->C#->Java->Kotlin->Kotlin+C#+Java
Из них именно переход на чистую жаву был самый травмирующий:))
У меня там не стрелка, а "меньше" было:) Я имел в виду, что вам C# нравится больше, чем Java, а Kotlin больше чем C#, верно?
Из них именно переход на чистую жаву был самый травмирующий:))
Не так страшна Java как Spring...
У меня там не стрелка, а "меньше" было:) Я имел в виду, что вам C# нравится больше, чем Java, а Kotlin больше чем C#, верно?
да, именно так. Хотя сишарп не сказать чтоб не нравится, просто К. чуть удобнее, да и привык
А что больнее всего было в Java? Я сейчас тоже по долгу службы сравниваю C#, Kotlin и Java. И если по поводу первых двух во многом дело вкуса, то Spring для меня просто тихий ужас по сравнению с ASP.NET Core
на первом месте - многословность и просто адское количество boilerplate code. У меня постоянно было ощущение, что я что-то обьясняю умственно отсталому человеку - очень подробно, со всеми мелкими деталями и т.п., каждый раз повторяя одно и то же. Сюда же отсутствие лямбд, linq и проч. Хотя в 11 жаве это уже все есть в полный рост, но оно все равно крайне многословное
Второе - женерики. После дотнета это был прям-таки удар!!!:) Они в жаве не более чем syntax sugar
третье - очень странная имплементация интефейсов (после сишарпа). Не могу сказать, что плохая, но странная
то Spring для меня просто тихий ужас
бог миловал:)
Честно, мне после Linq-а все остальные языки без подобного кажутся неполноценными.
Такая же фигня. Самым первым делом после возвращения на плюсы я задал вопрос: что из имеющегося больше всего похоже на LINQ? Понятно, что это как перевод: не надо по словам, надо, чтобы смысл сохранился.
А вообще, розовая мечта: найти порт FCL.
Тоже теперь такие мысли (перешел с Java на C#). Не понимаю, как люди пишут на языках, где нет мощных средств работы с коллекциями и перечислениями. Особенно на Go, это ж пипец.
Ну и смешно как JavaScript пытается эмулировать это, и поэтому в коде у разработчиков полно конструкций array.map(...).filter(...) которые просто несколько раз проходят по коллекции от начала до конца.
Вот про Go удваиваю, особенно сильно прочувствовал именно когда познакомился именно с ним.
В чем проблема использовать сторонние библиотеки?
Потому что Роб Пайк сказал, что ненужно.
Linq выглядит как развитие Embedded SQL, но может применяться не только для запросов но и простых коллекций. Так что идея не новая, но реализация дает большой плюс.
Java поддерживает лямбдs и stream коллекции, тот-же Linq только нету sql синтаксиса.
Java поддерживает лямбдs и stream коллекции, тот-же Linq только нету sql синтаксиса.
А кто то в шарпе юзает sql-like синтаксис?
Как ни странно то что я видел для работы с БД через EntityFramework используют sql like нотацию. а для in memory преобразований в основном через функции.
Джойны удобней писать на sql-like-е, особенно left join-ы всякие. Можно конечно и без него, но реально удобней.
Причем, обратите внимание, то что переменные после from там имеют тип, который даже не реализует IEnumerable — такое тоже возможно.
Java streams - бледное подобие LINQ.
Гибкость и удобство намного ниже из-за отсутствия extension methods.
Нет Expression Trees (https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/), что ограничивает применение в ORM и рантайм кодогенерации.
А чем указатели на функцию плохи? IMHO extension methods часто доставляют много неудобств, т.к. не понятно как их перегружать. какую сбоку подключить чтобы заработало и т.д.
В Java отсутствует перегрузка операторов это мешает использовать разный синтаксический сахар. В Java ORM(и не только) давно используют изменение bytecode для достижения разных целей еще со времен Java 2. Hibernate для примера использует Byte Buddy. Т.е. в Java не нужен синтаксический сахар для формирование дерева функций, можно готовый код разобрать и менять как хочется или преобразовать в SQL. Вообще механизм classloader весьма сильный и позволяет делать то что в C# и не снилось, но при этом синтаксис самого языка очень отстает.
Вот и джависты подъехали.
Какие указатели на функции?
Как не понятно как их перегружать? Так же, как и другие любые методы, и сам объект неявно передается. Что, куда подключить? Если речь про сборки, то
IDE подсказывает
Документация
Точно так же, если бы не были методами расширения
Можно пример перегрузки, когда для двух переменных одного типа вызываются разные функции если одна переменная была создана для потомка?
Например для IDictionary одно поведение, а для ConcurrentDictionary другое.
IDictionary dir1=new SortedDictionary();
IDictionary dir2=new ConcurrentDictionary();
Еще вопрос как вы Mock делаете для extension methods?
Также все плюсы Singleton становятся минусами для extension methods, т.к. сводят ООП к процедурному программированию.
Чем Java Stream ORM Speedment плоха?
Я не могу понять почему в сообществе хабра считается нормой начинать комментарий к статье с оскорбления автора
В данном случае, на это две причины:
автор безапелляционно заявляет о скорой смерти языка, а на поверку в статье банальное непонимание новых фич, и прочее "раньше было лучше"
в комментах как всегда отметились "те кто знает как лучше"
Проанализировав эти два пункта, можно сделать вывод, что это банальный байт на комменты, чтобы пользователи пролистали до комментов, увидели рекламу и возможно перешли по ссылке.
Позволю себе вас перефразировать) new() добавляет языку лаконичности. var нужен когда мы не знаем, какой тип будет в левой части присваивания, а new() нужен когда мы наоборот знаем.
Автор не подросток, автор - "программист" на Unity. Да простят меня разработчики на Unity, если есть среди вас толковые ребята, но я лично не встречал. Сколько ни собеседовал их на должность .Net разработчика, ни один не прошёл. Ни .Net они не знают, ни c# толком, а некоторых я бы и программистами не назвал.
С тех пор как появился 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 человек правила можно настраивать и при желании можно вообще запретить использовать конкретные плюшки и не давать компилироваться и мержится с выбранными (новым или старым) стилем кода).
А вот популярность C# как раз таки начала падать при Балмере, когда он забил на C#, .NET и C# вообще перестал развиваться и Microsoft активно рекламировал и призывал использовать тот же JS при разработке в WinRT. Даже покрытие API Winrt под .NET было меньше чем покрытие API Winrt JS-ом. И наоборот, при Наделла популярность C# снова начала расти, так как при нем активно стали развивать .net core
Могу ошибиться, но, кажется, примерно в это время Microsoft активно пилила Roslyn и как раз из-за него забила на всё остальное. Они там лет пять кроме него ничего особо не делали
А зачем появились record, какую проблему они решают? Ну в них Equals и == генерируются, да. Это было настолько важно, что ради этого целое ключевое слово и поддержку компилятора завезли?
какую проблему они решают
Boilerplate. Аналог(типы с иммутабельностью, конструкторами, копированием с модификацией, etc) на шарпе без них требует экран-другой кода.
Да, после других языков могу уверенно сказать что это дико важно. Кто-то может сказать что equals и так можно было негенерить легко resharper-ом. Если у тебя небольшой проект, то это правда. Но когда у тебя в проекте сотни сущностей и тебе регулярно надо рефакторить, необходимость следить за всеми эти Equals дико утомляет. Беда equals в том что само его существование в коде требует от тебя написания тестов на equals. В команде из 5 человек кто-то обязательно забудет исправить equals, забудет исправить тест на equals, хотя можно было бы писать намного более компактный вариант класса + не писать абсолютно не нужные тесты, так как record гарантирует идентичность кодогенерации сравнения на выходе.
После других языков меня и бесконечный {get; set;} бесят (да даже после того же F#) стал жутко раздражать. И после других языков вроде kotlin вообще не понимаешь, какого черта надо это все руками делать сегодня, когда за тебя все это может и должен делать компилятор.
На практике плюшки дают выбор...
Знаю я один язык где выбор почти безграничен. Perl. Такое будущее у С#?
а с тем, что бы команда писала не в разнобой, в одинаковом стиле, писала наиболее компактный идентичный код, сегодня вполне успешно справляются инструменты вроде Resharper и Rider ...
Знаю я одну технологию/инструмент в JS. Babel. Она работает. Да. Но разве к такому C# стремится?
Языки стремятся к удобству, без него язык можно считать мертвым:
я писал 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.
Да не плохо. Из прям нужного осталось стырить abstract sealed и enum classes из Котлина, чтобы можно было паттерн-метчить DU и норм будет.
Новая реализация switch в 8-й версии C# на самом деле удобна. У меня в одном проекте это самая частая конструкция, которая состоит только из одного switch в теле метода. Словари, конечно, можно использовать (почитав в комментариях), но не всегда они подходят под некоторые задачи.
Убивает язык не добавление новых возможностей, а политика компании. Если она хочет развивать NET как кроссплатформенный язык, то не только базовая часть должна поддерживать все операционные системы, но и графическая часть (GUI). Здесь Майкрософт, как всегда, отличилась — новый MAUI завязывает, в основном, на Windows-платформу. А также Android, iOS и Mac OS как дополнительная опция. А Linux оставила за бортом. Дескать, они сами разберутся. Вот и сидишь в раздумье, а не использовать ли мне уже Avalonia. Так как программирую практически на WPF, и XAML-синтаксис мне уже привычен. Да и метание Майкрософта по платформам не добавляет доверия к каждой новой платформе, которая тут же заворачивается на Windows. Ведь QT и GTK просто планомерно развивают свою платформу.
Я для кроссплатформенного десктопа на C# использовал GTK-обёртку. На винде правда пришлось "тянуть" не один мегабайт дллек. Но зато один код (даже больше - один бинарник) - работает везде. А с WSL, наверное (я не знаю), такое будёт провернуть ещё проще?
Новая реализация 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)),
};
Статья похожа на бухтение старого деда...
В последних версиях есть как и очень полезные вещи (оптимизация использования памяти с помощью Span и Memory), так и немного странные (по моим субъективным ощущениям) виды синтаксического сахара (новый switch, record). Но раз их добавляют, значит они нужны пользователям, пусть для меня они и не имеют большой ценности.
На сколько я знаю, разработка C# открыта для общественности, можно предлагать свои идеи, и, возможно, они будут включены в язык.
С++ стал нишевой технологией. Он используется или для вещей где нужна высокая производительность (базы данных) или для вещей, которые не могут быть сделаны с помощью более высокоуровневых языков (операционная система). На нем не будут разрабатывать десктопные приложения или софт для сервера, так как в этом случае на разработку тратится значительно больше времени и разработка стоит дороже.
PS Сложилось такое ощущение, что статья написана только для привлечения внимания к очередным курсам. Особенно порадовало то, что С# обучат за 12 месяцев, а C++ - за 8,5.
Ну хоть не за 21 день
На нем не будут разрабатывать десктопные приложения или софт для сервера
Ну да ну да, ведь там нигде не нужна высокая производительность, и пофиг что большая часть десктопных приложений на текущий момент использует в большинстве своём С++ в том или ином виде.
Есть специализированные приложения, которым нужна очень высокая производительность. Но в большинстве приложений этого не нужно. Если только не идет речь о производительности ради самой производительности.
В большинстве случаев оптимально использовать более мощную машину, чем разрабатывать на С++ вместо C#.
А по поводу:
большая часть десктопных приложений на текущий момент использует в большинстве своём С++ в том или ином виде.
Так почему не пойти дальше: любое приложение запускается на операционной системе, которая написана на С или С++ (а можно еще и на ассемблере), значит каждое приложение использует эти языки. Значит все разработчики, независимо от языка, должны знать С++.
Есть специализированные приложения, которым нужна очень высокая производительность. Но в большинстве приложений этого не нужно.
Сомнительное утверждение, я бы сказал что большенству приложений нужна высокая производительность, браузеры, графические редакторы, текстовые редакторы, аудио редакторы, игры (это приложения которые используются постоянно). Почти в каждой сфере приложения в той или иной мере требуют высокой производительности. Разве что только этерпрайз приложения не особо парятся о производительности и то не всегда.
Значит все разработчики, независимо от языка, должны знать С++.
Я не утверждал что каждый разраб должен знать С++, я лишь осариваю ваше утверждение что С++ это нишевый язык и что на нём нет смысла разрабатывать приложения для десктопа или сервера. Впрочем я в основном утверждаю это с прозиции программиста граффики, где практически всё написано на С++ и требуется производительность. Но в других сферах как мне кажется ситуация не сильно другая. Буду рад услышать контр примеры.
Я тоже так думал, пока не провел небольшой опрос джунов. Оказалось, что для них вообще не проблема разобраться как работать с этими "новомодными" конструкциями! От слова ВООБЩЕ!
А вот у кого есть проблема, так это у "вечных мидлов".
Давайте оттолнемся от этой аксиомы и попробуем сделать вывод:
В будущем в C# будет меньше "вечных мидлов"
Раз будет меньше "вечных мидлов", значит средняя зп станет выше
Раз средняя зп станет выше, больше людей будут "идти в C#"
???
PROFIT
Вообще, если писать достаточно много кода, весь этот синтаксический сахар довольно быстро усваивается. Во всех (почти) новых конструкциях есть своя логика. Порой очень неудобно развивать legacy-проект, если был опыт с новыми версиями .NET и C#.
Ну так он и становится более лаконичным. В C# 10 Hello World состоит теперь из одной строки, что должно привлекать зумеров (или кто там за ними следует, альфачи?), выбирающих себе ЯП для изучения.
Это может быть нужно, например:
1) студентам, которые решают какие-нибудь алгоритмические задачи, для которых не нужны классы;
2) разработчикам самого Roslyn и статических анализаторов для написания более коротких тестов (в этом случае тест – это небольшая программа на C#, часто состоящая из одной функции, которая подается на вход компилятору или анализатору).
Пожалуй, одним из самых спорных нововведений языка стали так называемые Top-Level Statements в C# 9.
Это в C# они новые, а в FORTRAN или ALGOL они были изначально (а вот необходимсть использовать ключевые слова program и end (обязательно — с точкой) в Pascal после этих языков, наоборот, поначалу вызывало неудобство).
Не использую их и до сих пор не понятно, кому это нужно.
Очень удобно, если нужно быстро проверить какое-то предположение, сделать набросок, и т.д.. Открыл вкладку в редакторе, написал, запустил, посмотрел, понял, удалил.
Ну вы IL гляньте. Будет ваш любимый main, а мне на парах очень удобно: проектор не резиновый и эти два сэкономленные отступа очень помогают. Interactive мне не подходит, потому что нужно смотреть IL.
Встречный вопрос. А в чем профит объявлять класс и метод для кода одностраничника или даже однострочника?
C# Interactive не пробовал, но как я понимаю это REPL, а это уже немного другое. Когда нужно много раз редактировать что-то в коде и перезапускать, файл намного удобнее.
С одной стороны, метод вроде Main в компилируемых языках не просто ещё один метод, а точка входа в программу. По моему личному мнению, полезно осознавать, что среда выполнения вызывает этот метод для запуска программы. С другой стороны, по вышеизложенной же причине, Main — регулярный метод, его название это просто конвенция, по аналогии из C/C++. Короче говоря, упаковка логики в методы проста и логична и согласуется с опытом в других языках.
Ещё одна причина такого мнения — Microsoft сама привнесла дополнительное правило в свой язык, отказавшись от «свободных» функций/методов. Все методы должны быть в классах, и на мой взгляд, это придавало дополнительную «строгость» языку, если можно так сказать. Уже не будет той вакханалии как в C/C++ из смеси макросов/свободных/дружественных функций с определениями где-то там.
Я не спорю, что для многих это полезно, просто утверждаю, что для кого-то, в том числе и для меня, Top-Level Statements довольно сомнительное нововведение. Заметил это в отзывах в официальном блоге .NET.
Очень спорная статья, мягко говоря. Язык развивается, преобразовывается, адаптируется к новым реалиям. Не вижу в этом ничего плохого. Обычно стагнация ведет к деградации и забвению. Опять же, технологии использующие в основе своей C#, набирают обороты из года в год, а кол-во вакансий с требованием знания c# множатся каждый день.
C#, как и любой другой язык программирования, это инструмент, который должен развиваться в месте со средой, где он применяется. По аналогии, вам никто не мешает использовать костяной скребок для разделки мяса, но человечество придумало более совершенные инструменты.
Более того, все новые фичи активно предлагаются и обсуждаются сообществом. Сначала в репозитории 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), не объявляя при этом поле в явном виде. Так как поле недоступно извне этих блоков, никто не сможет его поменять в обход свойства, что в большинстве случаев полезно.
Как видите, все новые фичи -- это в той или иной мере развитие идей, заложенных в язык изначально.
У меня такое ощущение, что в комментах не поняли, что это перевод
Думаю, почти все это поняли, но если кто-то решил потратить время на перевод, да и еще опубликовал его - значит с содержанием статьи он согласен. Ладно если бы этот перевод сделал обычный юзер, но его ведь публикует контора, которая занимается обучением программированию. Если они публикуют переводы статей, в которых автор явно с темой знаком довольно поверхностно, то уже возникают вопросы о том, каков же уровень знаний у самих ребят из SkillFactory
Там в тегах указано "юмор", автор мог просто посчитать забавным и перевести
Хм, действительно, есть в тегах "юмор" и "юмор?". Лично мне как-то сложно оценить статью как "забавная". А теги не могли добавить уже после того как пошла критика в комментариях и статья ушла в минус? Но даже если перевод сделан из-за того, что переводчик посчитал статью забавной, все равно публикация подобной статьи в блоге школы программирования очень сомнительна. Сколько людей после прочтения статьи смотрят еще и в список тегов? Я, например, обратил на него внимание впервые за многие годы и только после Вашего комментария. В итоге ряд людей, прочитавших статью, на ее основании могут составить себе неверную картину.
Статья не понравилась, автор либо хайпожор (видимо как и те, кто его перевел), либо дурачок. Собственно, на медиуме большинство комментариев вида: "жаль, что здесь нельзя минусовать", "я только что потратил N минут на чтение этого недоразумения".
В C# 10 вы можете создать свойство для свойства. Это называется поля C#.
Поля — это не свойства. Это данные, являющиеся частью объекта, хранящиеся в нем. Они есть во многих объектно-ориентированных языках, в том числе — и в тех, в которых нет концепции свойства (к примеру C++ поля были изначально). А в C# 10 просто добавляется синтаксический сахар для работы с анонимными полями (до того для программиста невидимыми), поддерживающими автоматически реализуемые свойства — т.е. автоматически реализуемыми можно будет сделать больше свойств.
И вот после таких ошибок читать статью уже не хочется. Хотя опасения ее автора мне понятны: я помню такой язык PL/1 и немало работал с ним. И для того времени он был просто перегружен разноообразными возможностями, в том числе — специфичными для платформы IBM mainframe, к примеру — поддержкой наборов данных с индексно-последовательным метода доступа прямо в языке (помнит ли кто сейчас о таком?). А потому за пределы мейнфреймов он пракстически так и не смог выйти, а мне пришлось учить C (что, правда, было совсем не сложно).
Вот и автор опасается такой судьбы для C# из-за его перегрузки возможностями. Ну, не знаю, не знаю — без большинства новоых возможностей, конечно, обойтись можно (как обходились без них предыдущие годы), но вот платформенно-зависимых, действительно опасных для развития языка, среди новых возможностей как-то не наблюдается.
Язык развивается, добавляются, более удобные и приятные вещи == язык умирает.
Мда, лютая дичь.
Это просто вборс г..на на вентилятор для рекламы курсов.
Крайне странная аргументация. Основной посыл автора: если в C# что-то уже можно сделать имеющимися средствами, не надо вводить более удобные альтернативы, т.к. это усложняет язык. При этом как и большинство адептов такой позиции он устанавливает планку "сложности", "удобства", "достаточности" и т.п., используя в качестве аргументации "этого уже достаточно". Например:
Я начал подозревать это, когда увидел новые выражения switch в C# 8
Эммм… Простите, какой еще switch? Ведь его можно выкинуть и все сделать через if / else. Почему автор не предлагает выкинуть switch, ведь по его логике это упростит язык? А где преложение выкинуть операторы цикла, когда у нас есть if и goto? Автор совершенно произвольно устанавливает планку "достаточности", а потом недоуменно вопрошает, почему остальные не хотят с этой планкой согласиться.
Ну и на закуску прекрасное
Ведь все мы любим пошутить над тем, какое раздутое месиво этот C++. По этой причине его больше и не используют.
C++ более не используют? В какой альтернативной вселенной находится автор?
https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/
Проблема с C# была в том, что он всегда был слишком многословным. Это у него от Java. Настолько, что я часто в шутку называл его Java#.
Нечто вне моего понимания, могу сказать, что ещё за многословность, это вообще о чём? Разве что намёк на C++ может что-то подсказать, но я выбрал не его по другим причинам - прежде была слабая типизация (точно не знаю, но слышал, что эту проблему решили) и я полагал, что он своё отжил, но всякий раз оказывалось нет так, разве что Rust может ещё станет заменой. Хотя, мысль интересная тем, не в этом ли причина нынешнего доминирования Python и JavaScript. Но мне совсем непонятно, например, зачем `#pragma warning disable` заменять на какое-то синтаксическое извращение, по мне совсем напротив, в C# вместо полезных функций добавляют всё новые синтаксические извращения. А уж у Java проблемы всяко не в синтаксисе, по мне с синтаксисом у него всё хорошо.
Кстати, в Swift с синтаксисом пришли к тому, что теперь полноценный компилятор с осмысленными сообщениями об ошибках сделать никак не могут, и, видимо, не смогут когда-либо, все выражения приходится проверять вручную, компилятор подсказать ничего не может.
Могу дать совет - попишите на жаве 8 (да или даже 11). После чего будете с дикой радостью приветствовать все эти новые фишки с#:)
Они отличные все, и жалобы мне напоминают стенания по поводу лямбд в свое время - все точно так же кричали, зачем это нужно, это непонятный бред а не нормальный язык!
Меня тогда, помню, вовсю на работе полоскали - какого хрена я втыкаю эти непонятные конструкции
Я до сих пор пишу на С (да, да на оригинальном С) и С++, активно использую С#. Каждый язык имеет свою нишу. А если люди используют что попроще, то это не значит, что язык мёртв. Автор не прав.
Дорогие Друзья!
Уважаемые коллеги!
Посмотрите на количество и пёструю тематику статей в блоге автора. За октябрь.
У меня всё.
А! Нет, не всё: skillfactory, переведите уже что-нибудь полезное... Спасибо.
Но когда вы в последний раз видели фреймворк высокого уровня, использующий C++?
Вчера, и каждый день. Этот фреймворк высокого уровня - 1С, который использует native внешние компоненты на C++.
"И был похож на Java… если бы в Oracle по-настоящему заботились о Java, это вернуло бы короткий золотой век Java." - о друг поверь мне Oracle отлично заботится о Java, намного лучше чем микромягкие о своем С#, по этому золотой век Java, как начался так и не заканчивается, по моему мнению до сих пор. Каждую версию языка, радуюсь нововведениям. Конечно я считаю излишне каждый пол года выпускать новую версию, но в общем как язык развивается, это отличный пример дял всех. Java как захватил огромный рынок веб приложений и интерпрайза, где важна безопасность, произвлдительность и поддерживаемость так и не отпускает. С# конечно то же пытался, но он недает никаких приемуществ по сравнению с Java ни по скорости, ни по поддерживаемости и кросплатформенности, ни по понятности кода (по мне так синтаксис С# немного менее поняен по сравнению с Java), но так и остался в песочнице винды.
Что будет с C#, и при чём здесь Страуструп?