ИМХО такие вакансии надо помечать "нам реально надо, повтори кишки". Следить за тем не поменялись ли реализации стандартной библиотеки от версии к версии платформы - развлечение на любителя.
Че так все по этому сборщику с ума сошли? Реально, что-ли на собесах это спрашивают? Что за больные люди? Или там не детали спрашивают, а просто "расскажите что такое gc и опишите принципы его работы" и народ такой вопрос считает "ненужной фигней"?
Там немного другая история. Async в f# - это computation expression (ближе к корутинам в Kotlin, но немного другая штука). В c# ввели именнно ключевые слова в язык, которые копипастнули в is и python. Ну и f# все же не mainstream-язык. Можно по этой логике добавить, что IO в хаскеле вообще с прошлого века
Да, про Last без Where загнался, вы правы. Я имел в виду именно вариант, когда предикат записан отдельным Where, чтобы на выходе IEnumerable был
.Where(predicate).Last();
Я по этому поводу согласен с @lair, что можно словить нежданчик. Может имело смысл сделать отдельную перегрузку для IList, чтобы такие вещи были более явными.
Но там внутрях уже разная реализация через апкасты! Например, array.Count() не будет перечислять массив, а просто вернёт Length.
Пока вы не добавили предикат
Кстати, реализация First и Last нарушать LSP не может в принципе, потому что LSP — требование к иерархии типов, а не к внешним операциям над ними.
Это терминологическая демагогия. Каким термином вы предлагаете кратко описывать ситуацию, когда метод работает с одним специализированным типом из иерархии, но не работает с другим?
Мне было проще: когда я учил 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.
ИМХО такие вакансии надо помечать "нам реально надо, повтори кишки". Следить за тем не поменялись ли реализации стандартной библиотеки от версии к версии платформы - развлечение на любителя.
Че так все по этому сборщику с ума сошли? Реально, что-ли на собесах это спрашивают? Что за больные люди? Или там не детали спрашивают, а просто "расскажите что такое gc и опишите принципы его работы" и народ такой вопрос считает "ненужной фигней"?
Там немного другая история. Async в f# - это computation expression (ближе к корутинам в Kotlin, но немного другая штука). В c# ввели именнно ключевые слова в язык, которые копипастнули в is и python. Ну и f# все же не mainstream-язык. Можно по этой логике добавить, что IO в хаскеле вообще с прошлого века
Да, про Last без Where загнался, вы правы. Я имел в виду именно вариант, когда предикат записан отдельным Where, чтобы на выходе IEnumerable был
Я по этому поводу согласен с @lair, что можно словить нежданчик. Может имело смысл сделать отдельную перегрузку для IList, чтобы такие вещи были более явными.
Пока вы не добавили предикат
Это терминологическая демагогия. Каким термином вы предлагаете кратко описывать ситуацию, когда метод работает с одним специализированным типом из иерархии, но не работает с другим?
Мне было проще: когда я учил 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#