А как вы узнаете что им на самом деле нужно? С моей точки зрения так категорично судить о влиянии Инстаграма на жизнь людей можно либо тщательно изучив все прямые и косвенные последствия, либо имея склонность очень уверенно судить о вещах в которых не разбираешься.
Полезность и уникальность это разные вещи. Уникальность зависит от точности сравнения. Может потребителям нравился другой цвет иконки или другое расположение элементов управления.
Доширак не хуже обеда в ресторане, он просто для других целей.
В моей IDE для хаскеля вообще нет рантайм-меток (да, я за всю практику пользовался Typeable в своём коде ровно один раз). Да и дебаггером я там не пользуюсь.
Если вы им не пользуетесь это не значит что его нет. Я посмотрел — оно умеет как-то определять тип в рантайме.
Кстати, определите до конца термин "рантайм метка" он не отражает метка чего именно.
В моей IDE для плюсов их тоже не особо много для рантайм-поведения.
А что у вас за IDE для плюсов? У вас там нет cимволов и RTTI? в окне watch нет колонки type для переменных? Или там написано что-то типа "рантайм метка относящаяся к набору операций которое можно совершать со значением"?
А зря. На мой взгляд, создаёт неправильные ожидания.
Какие и у кого?
Не обязательно. В том же хаскеле в общем случае после того, как вы проверили типы, вы можете их стереть и не иметь вообще ни намёка на них в рантайме.
Я хаскель знаю очень поверхностно. Мне трудно с этим поспорить.
С моей точки зрения, терминология, которую вы предлагаете требует введения разных слов для одного и того же и необщепринята, т.е. никакой выгоды от нее нет.
Если вы говорите что он может говорить, значит он может и не говорить. Как вы определите, говорит он в конкретном случае или нет?
Мое мнение в целом таково:
Я не знаю Java в но в случае C# это может до свидетельствовать об опыте кандидата. Например, если он не знает про Equals и GetHashCode, то он не сможет эффективно использовать стандартные коллекции со своими типами.
Если человек знает про эти методы но не может обобщить разные варианты до ответа на вопрос "зачем нужен метод equals", то, возможно, есть некоторые проблемы с абстрактным мышлением или коммуникацией.
Если он не пытается понять собеседника и все время приписывает ему по умолчанию некомпетентность, то это тоже может свидетельствовать о проблемах с коммуникацией.
И еще: каждый вопрос сам по себе ничего не решает, а только дает свидетельство в пользу того и другого.
Чтобы оценить интервьюера, надо понять, как он использует ответ на вопрос — в какую сторону дальше ведет беседу и так далее.
С моей точки зрения в книжке терминология интересна но неудобна, все говорят "тип" для общего, никто не использует выражения "рантайм метка" а статика тесно связана с динамикой.
А как называются рантайм метки более коротко? И какое название у описания того, что можно делать с некоторой штукой вне зависимости от того, рантайм это или дизайн тайм?
Мне кажется, такой подход к терминологии менее ортогонален.
Тесты не падали. Вы пересмотрели свое отношение к ревью?
К конкретному ревью да — одной причины для того, чтобы быть поторей времени у него меньше. Общее отношение ко всем ревью осталось тем же — в той мере в какой оно дублирует автоматические проверки — это потеря времени (если проверяете стиль, лучше внедрите FxCop). Когда не дублирует их — хорошо (дизайн надежно проверить инструментами нельзя, хотя есть инструменты, которые подскажут куда копать, так что дизайн лучше проверять человеку).
У меня складывается впечатление, что вы мои коментарии читаете читаете в упрощенном виде. Я пишу, что в критических по производительности участках LINQ принято вычищать — вы читаете что я призываю избавиться от всего LINQ, я пишу, кто кодревью потеря времени, если можно проверить автоматически, вы читаете, что все код ревью потеря времени.
в реальной жизни заметить разницу между хорошим подходом и плохим достаточно сложно
У меня такой ход рассуждений:
Если что-то сложно, то с чем-то есть сложность. С чем есть сложность? С тем чтобы заметить разницу между хорошим подходом и плохим. Почему с этим есть сложность? Судя по тому примеру, который вы привели, потому, что измеряется производительность не только рефлексии изолировано, но и некоторой смеси с LINQ, соответственно, роль рефлексии может быть скрыта огромной оверхедом LINQ (вместо рефлексии и LINQ могут быть любые вещи подразумевающие альтернативную реализацию).
Почему с этим сложность?
Потому, что мы сравниваем общую производительность смеси а не по отдельности.
Можно ли как-то измерять производительность компонентов из смеси?
Да, для этого есть специальные инструменты — профайлеры причем используемый фреймворк для бенчмаркинга поддерживает интеграцию c ними.
Можно отправить код на ревью вместо использование профайлера, но:
это тратит время другого человека, а не инструмента
это менее точно (человек может пропустить что-то — инструмент не отвлекается, хотя у него есть свои ограничения)
зато:
человек может что-то подсказать
человек, в отличие от профайлера, может проанализировать не только тот сценарий который используется но и другие
Поэтому логично сначала воспользоваться инструментом, а потом человеком, если останется в этом потребность. На кодревью присылать компилирующийся код, по которому проходят тесты.
Ошибка была найдена достаточно быстро благодаря комментариям.
С моей точки зрения это минус — тратить время человека, если можно пользоваться инструментом.
Посыл и мораль статьи в том, что в реальной жизни заметить разницу между хорошим подходом и плохим достаточно сложно, и эффект от этого может разочаровывать.
Не увидели ли бы вы сразу узкое место, если воспользовались профайлером? Может сложность из-за этого?
А LINQ — это неизбежное зло в бизнес-логике, его просто так не вычистишь.
Его не нужно вычищать весь. Достаточного только узкие места. Я бы скорее отнес ваш код к инфраструктур не ому уровню чем к бизнес логике.
Оптимизировать логику в таких местах можно только после того, как продукт стабилизируется.
Не относится ли это рассуждение к любой оптимизации, в том числе и к замене рефлексии тоже?
Результат генерации рефлекшеном поведения необходимо компилировать в делегаты для ускорения и сокращения выброса мусора
Тут какая-то описка. Если это то о чем я думаю, то зачем вообще нужна статья, что в ней нового сказано?
А я вот читал в книжках, что эту ересь типа LINQ в критичных для производительности участках принято вычищать. Не может ли быть такое что эта ересь у вас реально используется а у других может и не использоваться?
Ещё мне не очень понятно, почему при таких составных бенчмарках не был использован профайлер чтобы посмотреть что именно там является узким местом. Насколько я знаю, в benchmark.net есть даже встроенная возможность собирать трейсы для профайлеров.
P.s. Про производительность на .net есть несколько хороших книжек. Например, dreamwalker написал конкретно про бенчмарки. Возможно, там можно почерпнуть что-то, чтобы изменять корректнее и делать более правильные выводы.
ssh user@s390.server pprocess -p 2
но передавать код по сети — безумие.
Вы про какой код? Тут вроде у вас команды передаются, это не код? Еще вы, скорее всего, набираете это в браузере с неотключенным javascript.
Впрочем, вы совершенно правы, достоинства и недостатки они зависят от того, от чего именно мы хотим абстрагироваться. Если надо абстрагироваться от технологии в целом, то на границах должен быть наиболее простой переносимый интерфейс. Тут текст рулит. При работе внутри одной технологии можно абстрагироваться от деталей реализации конкретных понятий (например, хранится что-то или вычисляется на ходу).
Если вы вызовете ps без параметров он не выдаст COU — т.е. он абстрагирован от того какие именно характеристики нужны потребителю — это решается дальше по пайплайну. Он может не вычислять ничего и автору скрипта не надо думать о том, каким именно образом получается конкретная характеристика.
Теперь у вас есть «текстовые программы» и «нетекстовые». И вам нужно помнить что где, как и когда.
То же самое и с текстовыми командами — надо помнить формат каждой чтобы организовать их взаимодействие. И еще в каждую из них зашито некоторое подмножество нетекстовых. И еще метаформат нестандартизирован, так что организовать intellisense проблематично.
А гэнти гэмбуцу — японцы!
А как вы узнаете что им на самом деле нужно? С моей точки зрения так категорично судить о влиянии Инстаграма на жизнь людей можно либо тщательно изучив все прямые и косвенные последствия, либо имея склонность очень уверенно судить о вещах в которых не разбираешься.
Полезность и уникальность это разные вещи. Уникальность зависит от точности сравнения. Может потребителям нравился другой цвет иконки или другое расположение элементов управления.
Доширак не хуже обеда в ресторане, он просто для других целей.
У кого? Другого бизнеса? Значит есть бизнес который производит птичье молоко?
Если вы им не пользуетесь это не значит что его нет. Я посмотрел — оно умеет как-то определять тип в рантайме.
Кстати, определите до конца термин "рантайм метка" он не отражает метка чего именно.
А что у вас за IDE для плюсов? У вас там нет cимволов и RTTI? в окне watch нет колонки type для переменных? Или там написано что-то типа "рантайм метка относящаяся к набору операций которое можно совершать со значением"?
Какие и у кого?
Я хаскель знаю очень поверхностно. Мне трудно с этим поспорить.
С моей точки зрения, терминология, которую вы предлагаете требует введения разных слов для одного и того же и необщепринята, т.е. никакой выгоды от нее нет.
Почему вы так считаете? Как вы сами проводите интервью?
А почему это плохо? Интервью оно ж в частности для того, чтобы отличить тех чей опыт велик от тех чей невелик.
Почему вы воспринимаете это как оскорбление? Можете расшифровать?
Если вы говорите что он может говорить, значит он может и не говорить. Как вы определите, говорит он в конкретном случае или нет?
Мое мнение в целом таково:
Я не знаю Java в но в случае C# это может до свидетельствовать об опыте кандидата. Например, если он не знает про Equals и GetHashCode, то он не сможет эффективно использовать стандартные коллекции со своими типами.
Если человек знает про эти методы но не может обобщить разные варианты до ответа на вопрос "зачем нужен метод equals", то, возможно, есть некоторые проблемы с абстрактным мышлением или коммуникацией.
Если он не пытается понять собеседника и все время приписывает ему по умолчанию некомпетентность, то это тоже может свидетельствовать о проблемах с коммуникацией.
И еще: каждый вопрос сам по себе ничего не решает, а только дает свидетельство в пользу того и другого.
Чтобы оценить интервьюера, надо понять, как он использует ответ на вопрос — в какую сторону дальше ведет беседу и так далее.
Если вы используете foreach и массив, энумератора вообще не будет. Будет счетчик.
https://stackoverflow.com/questions/11179156/how-is-foreach-implemented-in-c
https://sharplab.io/#v2:C4LglgNgNAJiDUAfAAgJgIwFgBQyAMABMugCwDcOyAzEagQMIEDeOBbRNyJBAsgBQBKZq3aiA9GIIA3AIYAnAjIIBeAgDsApgHcCAGTABnYAB5ieAHxMARDKtQCVgEZWAvhWyjRshUtWadANoAuta29k6uZJ7sItGxngBmAPZyGjIAxgAWfN4EYHlqigLxoiwe0Z7EAJx8YALuFQQu8c3YLkA===
JIT может в каких-то случаях отбросить проверку, когда типы можно вывести статически.
А кем они так называются? Есть ли какая-то реализация которая называет их не типом?
Например, в вашей любимой IDE при отладке тип переменной и тип значения переменной называются по разному? Один тип, другой метка?
Ну вы в обычной речи слово тип не употребляете?
С моей точки зрения в книжке терминология интересна но неудобна, все говорят "тип" для общего, никто не использует выражения "рантайм метка" а статика тесно связана с динамикой.
А как называются рантайм метки более коротко? И какое название у описания того, что можно делать с некоторой штукой вне зависимости от того, рантайм это или дизайн тайм?
Мне кажется, такой подход к терминологии менее ортогонален.
К конкретному ревью да — одной причины для того, чтобы быть поторей времени у него меньше. Общее отношение ко всем ревью осталось тем же — в той мере в какой оно дублирует автоматические проверки — это потеря времени (если проверяете стиль, лучше внедрите FxCop). Когда не дублирует их — хорошо (дизайн надежно проверить инструментами нельзя, хотя есть инструменты, которые подскажут куда копать, так что дизайн лучше проверять человеку).
У меня складывается впечатление, что вы мои коментарии читаете читаете в упрощенном виде. Я пишу, что в критических по производительности участках LINQ принято вычищать — вы читаете что я призываю избавиться от всего LINQ, я пишу, кто кодревью потеря времени, если можно проверить автоматически, вы читаете, что все код ревью потеря времени.
У меня такой ход рассуждений:
Если что-то сложно, то с чем-то есть сложность. С чем есть сложность? С тем чтобы заметить разницу между хорошим подходом и плохим. Почему с этим есть сложность? Судя по тому примеру, который вы привели, потому, что измеряется производительность не только рефлексии изолировано, но и некоторой смеси с LINQ, соответственно, роль рефлексии может быть скрыта огромной оверхедом LINQ (вместо рефлексии и LINQ могут быть любые вещи подразумевающие альтернативную реализацию).
Почему с этим сложность?
Потому, что мы сравниваем общую производительность смеси а не по отдельности.
Можно ли как-то измерять производительность компонентов из смеси?
Да, для этого есть специальные инструменты — профайлеры причем используемый фреймворк для бенчмаркинга поддерживает интеграцию c ними.
Можно отправить код на ревью вместо использование профайлера, но:
зато:
Поэтому логично сначала воспользоваться инструментом, а потом человеком, если останется в этом потребность. На кодревью присылать компилирующийся код, по которому проходят тесты.
Да, если можно пользоваться инструментом. Например на финальное кодревью надо присылать код в котором не падают тесты и так далее.
С моей точки зрения это минус — тратить время человека, если можно пользоваться инструментом.
Не увидели ли бы вы сразу узкое место, если воспользовались профайлером? Может сложность из-за этого?
Его не нужно вычищать весь. Достаточного только узкие места. Я бы скорее отнес ваш код к инфраструктур не ому уровню чем к бизнес логике.
Не относится ли это рассуждение к любой оптимизации, в том числе и к замене рефлексии тоже?
Тут какая-то описка. Если это то о чем я думаю, то зачем вообще нужна статья, что в ней нового сказано?
А я вот читал в книжках, что эту ересь типа LINQ в критичных для производительности участках принято вычищать. Не может ли быть такое что эта ересь у вас реально используется а у других может и не использоваться?
Ещё мне не очень понятно, почему при таких составных бенчмарках не был использован профайлер чтобы посмотреть что именно там является узким местом. Насколько я знаю, в benchmark.net есть даже встроенная возможность собирать трейсы для профайлеров.
P.s. Про производительность на .net есть несколько хороших книжек. Например, dreamwalker написал конкретно про бенчмарки. Возможно, там можно почерпнуть что-то, чтобы изменять корректнее и делать более правильные выводы.
Так это он свободный, а не вы
Вы про какой код? Тут вроде у вас команды передаются, это не код? Еще вы, скорее всего, набираете это в браузере с неотключенным javascript.
Впрочем, вы совершенно правы, достоинства и недостатки они зависят от того, от чего именно мы хотим абстрагироваться. Если надо абстрагироваться от технологии в целом, то на границах должен быть наиболее простой переносимый интерфейс. Тут текст рулит. При работе внутри одной технологии можно абстрагироваться от деталей реализации конкретных понятий (например, хранится что-то или вычисляется на ходу).
Если вы вызовете ps без параметров он не выдаст COU — т.е. он абстрагирован от того какие именно характеристики нужны потребителю — это решается дальше по пайплайну. Он может не вычислять ничего и автору скрипта не надо думать о том, каким именно образом получается конкретная характеристика.
Это обеспечивает абстракцию и модульность.
Тогда вам не надо вызывать чужой код, иначе вы можете пострадать.
Ну это все не относится к концепции объектности.
На 10 месте по loved
То же самое и с текстовыми командами — надо помнить формат каждой чтобы организовать их взаимодействие. И еще в каждую из них зашито некоторое подмножество нетекстовых. И еще метаформат нестандартизирован, так что организовать intellisense проблематично.