Мне было проще: когда я учил C# LINQ'а не было:) Поэтому, когда он появился, то прочитал release notes. Кажется, там про ленивую природу было много написано.
Предлагаю автору ещё заменить linq на plinq и в следующей статье раскрыть тайну, почему без interlocked там то 7, то 8, то 9. Если уж стрелять себе в ноги, то до конца:)
Не точно выразился. Вы такие побочные эффекты захватываете, чтобы потом по последовательности несколько раз проитерироваться или вы один раз что-то захватываете и ничего не мутируете / проходите строго один раз по IEnumerable?
Не сделают, посмотрите интерфейсы IEnunerable и IEnumerator. First и Ladt объявлены именно для IEnumerable. Разная реализация через апкасты нарушит LSP. Не сказать, что IQueryable не нарушает LSP, но это был общий, а не частный случай и осознанный выбор, который оказался верным. Не говоря уже о бесконечных последовательностях.
Я не понимаю почему вы говорите про "медленное" и "быстрое" сравнение, если там ещё и multiple enumeration. Вообще пример очень неудачный, потому что в реальности его попросят переписать и "неожиданности" из статьи не будут актуальны
На сколько я помню, в asp.net все лямбды захватывают только immutable-переменные, поэтому поведения из статьи в asp.net не наблюдается. Поправьте, если не прав.
Докину 5 копеек. В C# быстрее всего поняли, что постоянно трактовая частота расти не будет и завезли async/await, который затем победоносно завезли в JS и Python почти один в один. Плюс у .NET'а сразу был мощный интероп, unsafe и value type. А с появлением .NET 6 с pgo и кучей оптимизаций asp.net вообще ворвался в топ самых быстрых фреймворков по версии tech empower. И все это с дженериками, орм, исключением и возможностью писать коротко. Так что аргумент go моложе, там по-умолчанию все круче, чем в старших собратьях - ну такое:)
Ну в c# получилось (почти) для новых проектов (хотя для value и reference сделано по разному), а в Java получился Kotlin. Стало получше. Но в общем случае вы правы, надо вообще к херам систему типов ломать, чтобы совсем null победить
Ну все-таки начиная с появления ключевого слова class это "почти привычное ООП". Конструкторы ведут себя иначе, это нужно учитывать (потому что прототипы), static-члены весьма спорные, ибо можно просто сделать export func из модуля (как, кстати, обычно и делают). bind'ы тоже останутся много где. Так что same-same but different.
Вытащили труп SOAP из холодильника, GraphQL, обладающий +/- всеми преимуществами сильной типизации, но лишённый тяжёлого XML упомянули, но рассказывать про него не стали
Ну тогда этот человек на уточняющий вопрос "а почему нет инкапсуляции" моментально ответит, что "здесь оно не надо". Я про то что "знал, но забыл" - это брехня. Не знал никогда
Да, это азы и это надо знать. Если кандидат не знает, что это такое, то ему не по пути с ООП.
Кандидат знает что такое инкапсуляция, но во время лайвкодинга "забыл" ее применить. Скажем, сделал все поля класса публичными и не стал создавать конструктор. Ему указали на эту проблему.
Кандидат может возразить, что лайвкодинг - это стрессовая ситуация, предполагающая быстрое решение здесь и сейчас. Поэтому он(а) решил(а) пренебречь инкапсуляцией в пользу скорости выполнения задания. На работе он(а) конечно же бы так не поступал(а). Или это вообще был DTO и там инкапсуляция и инварианты не нужны и интервьюер уже попутал(а).
Мне было проще: когда я учил C# LINQ'а не было:) Поэтому, когда он появился, то прочитал release notes. Кажется, там про ленивую природу было много написано.
Убедили, был не прав)
Предлагаю автору ещё заменить linq на plinq и в следующей статье раскрыть тайну, почему без interlocked там то 7, то 8, то 9. Если уж стрелять себе в ноги, то до конца:)
Плохо, что новички не знают. Все есть в спеке. На крайняк это очень легко дебажится.
Не точно выразился. Вы такие побочные эффекты захватываете, чтобы потом по последовательности несколько раз проитерироваться или вы один раз что-то захватываете и ничего не мутируете / проходите строго один раз по IEnumerable?
Не сделают, посмотрите интерфейсы IEnunerable и IEnumerator. First и Ladt объявлены именно для IEnumerable. Разная реализация через апкасты нарушит LSP. Не сказать, что IQueryable не нарушает LSP, но это был общий, а не частный случай и осознанный выбор, который оказался верным. Не говоря уже о бесконечных последовательностях.
Я не понимаю почему вы говорите про "медленное" и "быстрое" сравнение, если там ещё и multiple enumeration. Вообще пример очень неудачный, потому что в реальности его попросят переписать и "неожиданности" из статьи не будут актуальны
На сколько я помню, в asp.net все лямбды захватывают только immutable-переменные, поэтому поведения из статьи в asp.net не наблюдается. Поправьте, если не прав.
Ну вот зачем захватывать что-то в лябмду? Прям иногда это бывает нужно, но очень редко.
Вы их не распробовали:) они норм
Починить, поломав обратную совместимость :)
Докину 5 копеек. В C# быстрее всего поняли, что постоянно трактовая частота расти не будет и завезли async/await, который затем победоносно завезли в JS и Python почти один в один. Плюс у .NET'а сразу был мощный интероп, unsafe и value type. А с появлением .NET 6 с pgo и кучей оптимизаций asp.net вообще ворвался в топ самых быстрых фреймворков по версии tech empower. И все это с дженериками, орм, исключением и возможностью писать коротко. Так что аргумент go моложе, там по-умолчанию все круче, чем в старших собратьях - ну такое:)
Ну в c# получилось (почти) для новых проектов (хотя для value и reference сделано по разному), а в Java получился Kotlin. Стало получше. Но в общем случае вы правы, надо вообще к херам систему типов ломать, чтобы совсем null победить
Ну все-таки начиная с появления ключевого слова class это "почти привычное ООП". Конструкторы ведут себя иначе, это нужно учитывать (потому что прототипы), static-члены весьма спорные, ибо можно просто сделать export func из модуля (как, кстати, обычно и делают). bind'ы тоже останутся много где. Так что same-same but different.
Но это весьма спорные возможности:) не просто так же все новые версии es и typescript делают из JavaScript подобие Java/C#
Вытащили труп SOAP из холодильника, GraphQL, обладающий +/- всеми преимуществами сильной типизации, но лишённый тяжёлого XML упомянули, но рассказывать про него не стали
Ну все-таки не совсем "точно такое же". Прототипы там, extends - это expression и справа можно вызов функции поставить. Вот это вот все
Ну тогда этот человек на уточняющий вопрос "а почему нет инкапсуляции" моментально ответит, что "здесь оно не надо". Я про то что "знал, но забыл" - это брехня. Не знал никогда
Нет. Если человек не может дать определение, он не до конца (или вовсе) не понимает, что он делает. И пример с хешмапой это только подтверждает.
Представьте две гипотетические ситуации:
Да, это азы и это надо знать. Если кандидат не знает, что это такое, то ему не по пути с ООП.
Кандидат может возразить, что лайвкодинг - это стрессовая ситуация, предполагающая быстрое решение здесь и сейчас. Поэтому он(а) решил(а) пренебречь инкапсуляцией в пользу скорости выполнения задания. На работе он(а) конечно же бы так не поступал(а). Или это вообще был DTO и там инкапсуляция и инварианты не нужны и интервьюер уже попутал(а).