Я прочитал внимательно. Особенно, статью. Что до вашего комментария, то я отнюдь не повторил ваш. Два ключевых отличия. Во-первых, мои коментарии о недостатках центрального отопления относятся только к рыночному управлению экономикой. А это - не единственная возможная система. Во-вторых, цена на энергоносители никак не связана с эффективностью центрального отопления. При любой их цене централизованное отопление чисто по технологии позволяет использовать их эффективнее.
А ещё я просто не понял, что вы имели в виду под словом "эффективный вариант". Похоже - не то, что я (и многие другие), а чисто какие-то свои мечты, с жизненной необходимостью не связанные. А экономика - она в значительной своей части - про жизненную необходимость.
Вы всё напутали, это не формат файла проекта поменялся,
Нет, поменялся именно формат файла проекта, и именно для системы сборки, каковой является MSBuild. MS называет такие проекты SDK-style project. Точнее, формально формат тот же (XML), но добавлены и, главное, используются новые элементы и атрибуты. В результате базовые настройки сборки импортируются из совсем других мест и предусматривают другие точки расширения для донастройки. Потому на практике старые способы расширения (которые собственно и использовались в реальных проектах) часто не работают. Если вы переносили проект с .NET Framework в .NET(Core), то должны были с этим столкнуться: файл проекта толком не переносится. Когда я это делал, года два назад, у MS вообще была рекомендация создать новый проект и перенести исходные файлы и настройки туда. Были, правда, сторонние средства для конвертации, но они работали через пень колоду (я пробовал). Короче, работа была творческая, благо проект был совсем небольшим.
Ну и работают ли рекомендации из указанной статьи SO (сейчас или вообще) я не проверял.
Формат файла проекта MSBuild со времен .NET Framework поменялся. Новый (SDK-based) для .NET(Core) работает (формально) по тем же правилам, но вот информацию (Properties, Items и пр.) по факту берет из других мест, зачастую переписывая то, что указано в файле проекта. На SO предлагают эти настройки закидывать в Directory.Build.targets и указывать Target через параметры команды msbuild. Якобы, (не проверял) работает и без Visual Studio.
Вряд ли, ничего замечательного в ней не заметил. Но поощрение в виде снятия ранее наложенного взыскания за исправление фактической ошибки автор заслужил IMHO.
А по теме статьи я высказываться не хочу. Ибо обучением программированию я не занимаюсь, а своего релевантного опыта у меня уже давно нет. Изучение языков программирования я начал с Алгол-60, продолжил Фортраном IV, PL/1 и немного Бейсиком (тем, старым, с обязательними номерами строк). Си изучил уже заметно потом - и вообще по справочнику (80 страничек формата A6), где-то за неделю. И так далее. Вся эта история теперь вряд ли кому-нибудь интересна - разве что, как @saipr, мемуары начать писать...
Ну да, отопление нужно только из-за климата. Где-нибудь в Бангладеш отопление не нужно. Но люди живут не только там, а, например, в России. И, скорее всего, там живет большая часть аудитории этого ресурса. Так что обсуждать идею центрального отопдения именно на нем вполне осмысленно.
Что вы там понимаете под эффективностью - для меня загадка. Лично я привык что под эффективностью понимается получение требуемого блага (комфортной температуры в жилище, в данном случае), с наименьшими для существующих условий затратами ресурсов. Но с написанным вами такое понимание явно не стыкуется. В этом плане жить в России вообще, по сравнению с Бангладеш, неэффективно. Про это даже целая книга есть - "Почему Россия не Америка", автор - Александр Петрович Паршев.
Но если жить в России, то центральное отопление - одно из наиболее эффективных решений. Если, конечно, экономическая система позволяет его полноценно реализовать. А с этим сейчас есть сложности, см. мои комментарии выше.
Ну, а система расселения, когда большая часть городского (это важно) населения живет в пригородах - она сама по себе неэффективна (в том сысле, который я привел): требует больше ресурсов для удовлетворения потребностей этого населения из-за существенных расходов на транспорт и неэффективного использования земель (не под с/х, а под жилую застройку низкой плотности). А потому мало где распространена, кроме богатых и деньгами, и территорией, да еще и имеющих сравнительно мягкий климат США.
К вашему сведению, минмальная программа на C# выглядит примерно так же, как и на Python:
Console.WriteLine("Hello, World!");
Возможность писать программу таким образом, без лишней обвязки, называется "top-level statements", появилась она недавно, в .NET 6.0, но она - есть. Более того, она задействована в стандартных шаблонах проектов
Дополнительно. Я в курсе, что в then можно передать нечто синхроннное (и тогда он вернет завершенный promise), а задачу, созданную ContinueWith - наоборот, заставить дождаться завершения запущенной из делегата задачи (если сделать ее дочерней, к примеру). Но все это - те самые дополнительные усложнения, выходящие за рамки статьи.
PS А кому прямо так нужен аналог Promise в C#, то для этого есть TaskCompletionSource. Но это уже другая история.
Просто неудачно выразил мысль - слишком сократил. Если говорить точнее (и длиннее), то в ContinueWith передается делегат, не возвращающий результатата (либо делегат, возвращающий результат задачи, а не задачу, но, в любом случае - выполняющийся синхронно), а в then - функция, возвращающая promise.
С чего бы цепочка then должна быть эквивалентной вложенным ContinueWith? Это во-первых.
Возражение справедливое, хотя IMHO тут начать надо (причем - не комментарий, а саму статью) с того, что метод then в JS семантически не эквивалентен методу ContinueWith в.NET даже когда ои используются внешне одинаково - ровно с одним параметром и даже если проигнорировать для простоты условия продолжения и считать, что все завершается нормально. Потому что через этот параметр передаются сущности разного типа: в then - promise, т.е. задача, а в ContinueWith - делегат, т.е. код который будет выполняться в задаче (а уж ContinueWith обернет его в задачу).
Вообще в данной статье случай рассмотрен простейший: параметр для ContinueWith поменять несложно, т.к. код соответствующих делегатов доступен. А потому я сильно сомневаюсь, что ее вообще стоило переводить. А к чему это приводит и как с этим бороться в разных более сложных случаях, например, когда доступен только Task, а не делегат, который им выполняется - это уже совсем другая история, и в комментарии ее я рассказать не берусь.
PS Поубирал минусы, которые вы тут друг другу понаставили: не по делу они IMHO.
Этот функционал предназначен для взаимодействия с кодом, выполняющимся не под управлением .NET. И находится там же, где всё подобное - в System.InteropServices.
В обычном (управляемом) коде .NET его лучше не использовать - как например и указатели, ровно по тем же причинам: unsafe.
Для корпоративного рынка примерно так. Есть, правда, нюанс - какой софт считаь плохим (по науке это - асимметрия информации), но пока что бог с ним.
Но вот если речь о потребительском рынке, то тут есть ещё один нюанс, про который я не упомянул, хотя он - более важный: производство ПО и услуг для этого рынка оплачивает рекламодатель, естественно - в своих интересах.
Спорить дальше совсем не хочу, только пару вещей отмечу.
Капитализм - это не только рынок, но и частная собственность на средства производства. А это уже не столь универсальная штука. С понятиями африканских племен, к примеру, не сочетается - там делиться надо. И со Средневековьем европейским - тоже очень посредственно: к примеру, право распоряжаться землей там было обставлено кучей условий. А отсюда - и другая психология. К примеру, психология тех же участников Крестовых походов (да и рыцарского сословия вообще - для которого честь была дороже любых денег) нашему современнику далеко не органична. Но это, особенно весь массив связанных с этим знаний - оно опять-таки далеко за пределами тематики Хабра.
Плевать на других получается не всегда. К примеру, при "первобытном коммунизме" (родово-племенном строе) - не получается: на индивида, коли он против понятий пойдет, там наплюют так, что мало не покажется. А в одиночку там не проживешь - съедят или сам с голоду помрешь.
никто не будет правила вырабатывать, капитализм это не выдуманный конструкт, это буквально суть человечества которую немного огородили правилами и законами чтобы люди друг друга не перегрызли
Капитализм - это способ управления общественным производством. На текущий момент - оптимальный, но так было не всегда и не факт что так будет всегда начиная с настоящего момента.
Суть человечества (она же - "природа человека") определяется в занчительной мере совокупностью тех отношений, в которые люди всупают в процессе производства необходимых им благ. В частности, с тем, чтобы люди в одном обществе не перегрызли друг друга, вполне успешно справлялись разные по своему характеру общества и до капитализма. А правила для этого были весьма разные.
Но это все - уже философия (конкретно - материалистическое понимание истории). Не думаю, что на Хабре это можно и нужно всерьез обсуждать.
Одно из первых моих воспоминаний о проблемах вычислительной техники - это когда я, будучи студентом на ЕС-1045, захотел поиграть в Star Trek, и для этого вечерком переключил proclib - подсмотрев, как это делают инженеры и системщики, тоже большие любители погонять клингонов. А обратно - не переключил, в результате вся ночная пачка заданий не выполнилась. Мне повезло - обошлось без телег в деканат, всего лишь лишили на пару месяцев машинного времени. Но в полную изоляцию чего-либо на компьютерах я с тех пор верить опасаюсь.
Микросервисы решают (как кажется) ещё одну серьезную, хоть и не техническую, проблему: разбиение единой организации, ведущей разработку, на практически независимые друг от друга группы. Такое разбиение сильно уменьшает потребность в качестве управления и квалификации управленцев. А хороший управленец для большой организации - товар не менее эксклюзивный, чем хороший разработчик. Именно поэтому, полагаю, микросервисы столь популярны у менеджмента.
Засада тут в том, что часто это действительно только кажется. Если разрабатываемая система имеет сложную внутреннюю логику, то от этой сложности никуда не деться. И если каждый микросервис в рамках такой системы будет простым, то сложность логики перейдет во взаимодействие между микросервисами. И - между командами, их разрабатывающими.
Понимая как реализовано в С++, почти без заглядывания под капот С#, понимаешь как оно там всё устроено.
Не всегда. В C++, насколько я помню, традиционно было плохо с информацией о типах во время выполнения (может, в последних стандартах и улучшили, не знаю, я лично не прошел дальше C++ 2003), а в C# эта информация практически полная. И это позволяет работать с классами, которые не были известны на момент компиляции. Типичный (хотя сейчас и несколько устаревший) пример - Startup-класс в ASP.NET Core web-приложении, сделанном по шаблону Generic Host: этот класс может отыскиваеться кодом библиотеки (заранее скомпилированным) в рантайме по его имени и может даже быть разным для разных окружений (development/staging/production) и не обязан при этом содержать все потенциально вызываемые кодом библиотеки методы (к примеру, ConfigureContainer там бывал нечасто AFAIK, ибо нужен он только при использовании сторонних DI-контейнеров).
То, что в ИТ это возможно - это к счастью для народного хозяйства в целом. Потому что квалифицированные программисты -товар редкий, а потому дорогой. А железо - оно массовое, и постонянно дешевеет, один порядок величины - это всего лет пять развития по закону Мура.
Я прочитал внимательно. Особенно, статью. Что до вашего комментария, то я отнюдь не повторил ваш. Два ключевых отличия. Во-первых, мои коментарии о недостатках центрального отопления относятся только к рыночному управлению экономикой. А это - не единственная возможная система. Во-вторых, цена на энергоносители никак не связана с эффективностью центрального отопления. При любой их цене централизованное отопление чисто по технологии позволяет использовать их эффективнее.
А ещё я просто не понял, что вы имели в виду под словом "эффективный вариант". Похоже - не то, что я (и многие другие), а чисто какие-то свои мечты, с жизненной необходимостью не связанные. А экономика - она в значительной своей части - про жизненную необходимость.
Нет, поменялся именно формат файла проекта, и именно для системы сборки, каковой является MSBuild. MS называет такие проекты SDK-style project. Точнее, формально формат тот же (XML), но добавлены и, главное, используются новые элементы и атрибуты. В результате базовые настройки сборки импортируются из совсем других мест и предусматривают другие точки расширения для донастройки. Потому на практике старые способы расширения (которые собственно и использовались в реальных проектах) часто не работают.
Если вы переносили проект с .NET Framework в .NET(Core), то должны были с этим столкнуться: файл проекта толком не переносится. Когда я это делал, года два назад, у MS вообще была рекомендация создать новый проект и перенести исходные файлы и настройки туда. Были, правда, сторонние средства для конвертации, но они работали через пень колоду (я пробовал). Короче, работа была творческая, благо проект был совсем небольшим.
Ну и работают ли рекомендации из указанной статьи SO (сейчас или вообще) я не проверял.
Формат файла проекта MSBuild со времен .NET Framework поменялся. Новый (SDK-based) для .NET(Core) работает (формально) по тем же правилам, но вот информацию (Properties, Items и пр.) по факту берет из других мест, зачастую переписывая то, что указано в файле проекта. На SO предлагают эти настройки закидывать в
Directory.Build.targetsи указывать Target через параметры команды msbuild. Якобы, (не проверял) работает и без Visual Studio.Вряд ли, ничего замечательного в ней не заметил. Но поощрение в виде снятия ранее наложенного взыскания за исправление фактической ошибки автор заслужил IMHO.
А по теме статьи я высказываться не хочу. Ибо обучением программированию я не занимаюсь, а своего релевантного опыта у меня уже давно нет.
Изучение языков программирования я начал с Алгол-60, продолжил Фортраном IV, PL/1 и немного Бейсиком (тем, старым, с обязательними номерами строк). Си изучил уже заметно потом - и вообще по справочнику (80 страничек формата A6), где-то за неделю. И так далее. Вся эта история теперь вряд ли кому-нибудь интересна - разве что, как @saipr, мемуары начать писать...
Рад, что в статью исправление теперь внесено. Но что сделано, то сделано, и минус отменить нельзя.
Ну да, отопление нужно только из-за климата. Где-нибудь в Бангладеш отопление не нужно. Но люди живут не только там, а, например, в России. И, скорее всего, там живет большая часть аудитории этого ресурса. Так что обсуждать идею центрального отопдения именно на нем вполне осмысленно.
Что вы там понимаете под эффективностью - для меня загадка. Лично я привык что под эффективностью понимается получение требуемого блага (комфортной температуры в жилище, в данном случае), с наименьшими для существующих условий затратами ресурсов. Но с написанным вами такое понимание явно не стыкуется. В этом плане жить в России вообще, по сравнению с Бангладеш, неэффективно. Про это даже целая книга есть - "Почему Россия не Америка", автор - Александр Петрович Паршев.
Но если жить в России, то центральное отопление - одно из наиболее эффективных решений. Если, конечно, экономическая система позволяет его полноценно реализовать. А с этим сейчас есть сложности, см. мои комментарии выше.
Ну, а система расселения, когда большая часть городского (это важно) населения живет в пригородах - она сама по себе неэффективна (в том сысле, который я привел): требует больше ресурсов для удовлетворения потребностей этого населения из-за существенных расходов на транспорт и неэффективного использования земель (не под с/х, а под жилую застройку низкой плотности). А потому мало где распространена, кроме богатых и деньгами, и территорией, да еще и имеющих сравнительно мягкий климат США.
К вашему сведению, минмальная программа на C# выглядит примерно так же, как и на Python:
Возможность писать программу таким образом, без лишней обвязки, называется "top-level statements", появилась она недавно, в .NET 6.0, но она - есть. Более того, она задействована в стандартных шаблонах проектов
Посему за статью, извините - минус.
Дополнительно. Я в курсе, что в then можно передать нечто синхроннное (и тогда он вернет завершенный promise), а задачу, созданную ContinueWith - наоборот, заставить дождаться завершения запущенной из делегата задачи (если сделать ее дочерней, к примеру). Но все это - те самые дополнительные усложнения, выходящие за рамки статьи.
PS А кому прямо так нужен аналог Promise в C#, то для этого есть TaskCompletionSource. Но это уже другая история.
Просто неудачно выразил мысль - слишком сократил. Если говорить точнее (и длиннее), то в ContinueWith передается делегат, не возвращающий результатата (либо делегат, возвращающий результат задачи, а не задачу, но, в любом случае - выполняющийся синхронно), а в then - функция, возвращающая promise.
Против этого возражения будут?
Возражение справедливое, хотя IMHO тут начать надо (причем - не комментарий, а саму статью) с того, что метод then в JS семантически не эквивалентен методу ContinueWith в.NET даже когда ои используются внешне одинаково - ровно с одним параметром и даже если проигнорировать для простоты условия продолжения и считать, что все завершается нормально. Потому что через этот параметр передаются сущности разного типа: в then - promise, т.е. задача, а в ContinueWith - делегат, т.е. код который будет выполняться в задаче (а уж ContinueWith обернет его в задачу).
Вообще в данной статье случай рассмотрен простейший: параметр для ContinueWith поменять несложно, т.к. код соответствующих делегатов доступен. А потому я сильно сомневаюсь, что ее вообще стоило переводить. А к чему это приводит и как с этим бороться в разных более сложных случаях, например, когда доступен только Task, а не делегат, который им выполняется - это уже совсем другая история, и в комментарии ее я рассказать не берусь.
PS Поубирал минусы, которые вы тут друг другу понаставили: не по делу они IMHO.
Причем, возможно - если удалить совсем другой ключ;-). Вы не посмотрели когда туда лазили, не открытая ли адресация там используется?
Этот функционал предназначен для взаимодействия с кодом, выполняющимся не под управлением .NET. И находится там же, где всё подобное - в System.InteropServices.
В обычном (управляемом) коде .NET его лучше не использовать - как например и указатели, ровно по тем же причинам: unsafe.
Для корпоративного рынка примерно так. Есть, правда, нюанс - какой софт считаь плохим (по науке это - асимметрия информации), но пока что бог с ним.
Но вот если речь о потребительском рынке, то тут есть ещё один нюанс, про который я не упомянул, хотя он - более важный: производство ПО и услуг для этого рынка оплачивает рекламодатель, естественно - в своих интересах.
Спорить дальше совсем не хочу, только пару вещей отмечу.
Капитализм - это не только рынок, но и частная собственность на средства производства. А это уже не столь универсальная штука. С понятиями африканских племен, к примеру, не сочетается - там делиться надо. И со Средневековьем европейским - тоже очень посредственно: к примеру, право распоряжаться землей там было обставлено кучей условий. А отсюда - и другая психология. К примеру, психология тех же участников Крестовых походов (да и рыцарского сословия вообще - для которого честь была дороже любых денег) нашему современнику далеко не органична. Но это, особенно весь массив связанных с этим знаний - оно опять-таки далеко за пределами тематики Хабра.
Плевать на других получается не всегда. К примеру, при "первобытном коммунизме" (родово-племенном строе) - не получается: на индивида, коли он против понятий пойдет, там наплюют так, что мало не покажется. А в одиночку там не проживешь - съедят или сам с голоду помрешь.
Капитализм - это способ управления общественным производством. На текущий момент - оптимальный, но так было не всегда и не факт что так будет всегда начиная с настоящего момента.
Суть человечества (она же - "природа человека") определяется в занчительной мере совокупностью тех отношений, в которые люди всупают в процессе производства необходимых им благ. В частности, с тем, чтобы люди в одном обществе не перегрызли друг друга, вполне успешно справлялись разные по своему характеру общества и до капитализма. А правила для этого были весьма разные.
Но это все - уже философия (конкретно - материалистическое понимание истории). Не думаю, что на Хабре это можно и нужно всерьез обсуждать.
IMHO - нет. А пару глав можно написать в следующей статье.
Одно из первых моих воспоминаний о проблемах вычислительной техники - это когда я, будучи студентом на ЕС-1045, захотел поиграть в Star Trek, и для этого вечерком переключил proclib - подсмотрев, как это делают инженеры и системщики, тоже большие любители погонять клингонов. А обратно - не переключил, в результате вся ночная пачка заданий не выполнилась. Мне повезло - обошлось без телег в деканат, всего лишь лишили на пару месяцев машинного времени. Но в полную изоляцию чего-либо на компьютерах я с тех пор верить опасаюсь.
Микросервисы решают (как кажется) ещё одну серьезную, хоть и не техническую, проблему: разбиение единой организации, ведущей разработку, на практически независимые друг от друга группы. Такое разбиение сильно уменьшает потребность в качестве управления и квалификации управленцев. А хороший управленец для большой организации - товар не менее эксклюзивный, чем хороший разработчик. Именно поэтому, полагаю, микросервисы столь популярны у менеджмента.
Засада тут в том, что часто это действительно только кажется. Если разрабатываемая система имеет сложную внутреннюю логику, то от этой сложности никуда не деться. И если каждый микросервис в рамках такой системы будет простым, то сложность логики перейдет во взаимодействие между микросервисами. И - между командами, их разрабатывающими.
Не всегда. В C++, насколько я помню, традиционно было плохо с информацией о типах во время выполнения (может, в последних стандартах и улучшили, не знаю, я лично не прошел дальше C++ 2003), а в C# эта информация практически полная. И это позволяет работать с классами, которые не были известны на момент компиляции.
Типичный (хотя сейчас и несколько устаревший) пример - Startup-класс в ASP.NET Core web-приложении, сделанном по шаблону Generic Host: этот класс может отыскиваеться кодом библиотеки (заранее скомпилированным) в рантайме по его имени и может даже быть разным для разных окружений (development/staging/production) и не обязан при этом содержать все потенциально вызываемые кодом библиотеки методы (к примеру, ConfigureContainer там бывал нечасто AFAIK, ибо нужен он только при использовании сторонних DI-контейнеров).
То, что в ИТ это возможно - это к счастью для народного хозяйства в целом. Потому что квалифицированные программисты -товар редкий, а потому дорогой. А железо - оно массовое, и постонянно дешевеет, один порядок величины - это всего лет пять развития по закону Мура.