В моей 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 проблематично.
Благодаря текстовым интерфейсам, каждая команда должна знать как форматировать и это увеличение опций умножается на количество команд.
В powershell, благодаря объектной модели, команды более ортогональны. Отформатировать можно одними и теми же способами выхлопы разных команд.
# вывести процессы отсортированные по ID в грид
ps | sort id | ogv
# вывести все сервисы в названии которых есть SQL сгруппированные по статусу и отформатировать как таблицу с автоматическим размером колонок
gsv *sql* | sort status | group status | ft -au
нам не нужно расшаривать состояние между двумя вкладками одного ии того же приложения.
Я бы уточнил — нужно, но мы обычно это делаем внутри процесса, а не по сети.
Ага, так понятно. А нельзя было как-то более удобно это сделать без всех этих текстовых констант и кейзов? Чтобы оно сраружи выглядело как 2 way binding а внутри была бы вся эта иммутабельность и прочее. Свитчи под капотом, редюсеры знают только про свою часть состояния и так далее.
А вот не может ли кто-нибудь мне, человеку далекому от веба, объяснить зачем нужны фреймворки управления состоянием и желательно дать концептуальный анализ почему они нужны в вебе и не нужны на десктопе, или менее распространены (например в каком-нибудь WPF).
С моей точки зрения вот это вот практически полностью не очень хорошо спроектированный бойлерплейт:
const LoginComponent = (state = initialState, action) => {
switch (action.type) {
// This reducer handles any action with type "LOGIN"
case "LOGIN":
return state.map(user => {
if (user.username !== action.username) {
return user;
}
if (user.password == action.password) {
return {
...user,
login_status: "LOGGED IN"
}
}
});
default:
return state;
}
};
И в высокоуровневом коде такое не желательно — хотелось бы как-то связать View с моделью, но при этом не думать об управлении состоянием, причем, в терминах текстовых констант. Типа как в WPF + MVVM.
Если вы им не пользуетесь это не значит что его нет. Я посмотрел — оно умеет как-то определять тип в рантайме.
Кстати, определите до конца термин "рантайм метка" он не отражает метка чего именно.
А что у вас за 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 проблематично.
Достаточно сделать адаптер. В powershell если в pipe встроить обычную программу, она будет потреблять текст. Т.е. количество костылей уменьшается.
Благодаря текстовым интерфейсам, каждая команда должна знать как форматировать и это увеличение опций умножается на количество команд.
В powershell, благодаря объектной модели, команды более ортогональны. Отформатировать можно одними и теми же способами выхлопы разных команд.
Я бы уточнил — нужно, но мы обычно это делаем внутри процесса, а не по сети.
Ага, так понятно. А нельзя было как-то более удобно это сделать без всех этих текстовых констант и кейзов? Чтобы оно сраружи выглядело как 2 way binding а внутри была бы вся эта иммутабельность и прочее. Свитчи под капотом, редюсеры знают только про свою часть состояния и так далее.
Или я чего-то не понимаю?
А вот не может ли кто-нибудь мне, человеку далекому от веба, объяснить зачем нужны фреймворки управления состоянием и желательно дать концептуальный анализ почему они нужны в вебе и не нужны на десктопе, или менее распространены (например в каком-нибудь WPF).
С моей точки зрения вот это вот практически полностью не очень хорошо спроектированный бойлерплейт:
И в высокоуровневом коде такое не желательно — хотелось бы как-то связать View с моделью, но при этом не думать об управлении состоянием, причем, в терминах текстовых констант. Типа как в WPF + MVVM.