Здравствуйте, landerhigh, Вы писали:
L>Тёма, ты только что доказал, что не работал с мало-мальски сложными проектами с историей на плюсах. Поэтому между тобой и людьми, которые на этом собаку съели, такая пропасть, что им после вопроса про синглтон банально не о чем дальше с тобой разговаривать. L>Ты даже не понял, что за проблему KP упомянул.
Ты так гордишься, что булькаешься в "проектах с историей на плюсах".
На самом деле конечно, есть проекты где на плюсах и с паттернами всё нормально. Просто ты в такие компании с твоим отношением к этой тематике не пройдешь.
Здравствуйте, kaa.python, Вы писали:
CAF>>А где оценка производительности? Выглядит плохо, но как влияет? CAF>>Ну выполняется там в глубине критический кол, оптимизированный jit а почему расходы большие?
KP>Да вроде это очевидно. В Java практически всё (или вообще всё? не уверен) является объектом. Весь этот громадный стек ни что иное как нагромождение разных объектов. И каждый объект где-то лежит, его создали, его время жизни отслеживается. Всё это не бесплатно, и расходует память и процессорное время. Ты пытаешься сказать что это не имеет знание?
Ну и что? Что, в C++ нет обьектов? Или в C нет обьектов? Спринг конечно зло, но это не повод винить паттерны проектирования. Избыток абстракций, может быть более подходящие паттерны решили бы проблему лучше. Подход Clojure как раз подкупает, что изящное решение там, где на ооп со спрингом ад. Но причём тут паттерны? Те, что GoF, так это костыли для OOP чтобы изобразить то, что на FP из коробки.
Тут в треде собралось несколько OOP прогеров с претензией "паттерны зло. а зачем их вообще знать". Да, и сортировку знать не надо- пузырек сойдет Так и получается, что весь код тормозит, неважно написали его на непремиальной жаве, ультра быстром (в эротических фантазиях фанатов) сипипи, или хипстерском эрланге (когда он лезет в лок на каждый чих).
Здравствуйте, landerhigh, Вы писали:
L>Немногие оставшиеся продуктовые компании Австралии строят из себя девочек. Каждые "рога и копыта" мнят себя гуглем с наса в одном флаконе с ковырнадцатью раундами интервью. Потому пока еще типа могут, но то, что в них уже Артемкам поручают нанимать людей, уже само по себе показатель.
Артёмка вроде грамотный программист. С чего такая ненависть?
Здравствуйте, kaa.python, Вы писали:
KP>>>Да и DI ваше тоже говно, зависимости надо передавать явно.
S>>А можно развернуть, что тут не так?
KP>Ну даже не знаю... Может быть то, что мы говорим про DI?
Dependency injection is one form of the broader technique of inversion of control.
В настоящее время, когда говорят IoC, подразумевают инжектор. Но суть в том, что DI Framework "автомагически" инициализирует зависимости-сервисы в правильной последовательности. Эти сервисы создаются в единствененом экземпляре на инжектор, т.е. это синглтон в пределах экземпляра инжектора.
Чувакам с C++, налепившим пачку синглтонов в пределах процесса, и не знакомых с DI, лучше открыть для себя этот самый DI.
Здравствуйте, SkyDance, Вы писали:
L>>А ты сам-то знаешь, как? (С прищуром) SD>(с еще большим прищуром) а ты? SD>Я несколько лет назад думал, что знаю, а вот сейчас, научившись, уже... не уверен.
Мне вот всегда было интересно когда такое спрашивают про синглтоны — что именно ожидают в ответ? Простое "закрыть локом" ведь не проканает же? Например, я вбил это в гугл — получил ответы про яву, где никаких локов нет, потому что оии где то внутри классов явы зарыты.
$>В настоящее время, когда говорят IoC, подразумевают инжектор. Но суть в том, что DI Framework "автомагически" инициализирует зависимости-сервисы в правильной последовательности. Эти сервисы создаются в единствененом экземпляре на инжектор, т.е. это синглтон в пределах экземпляра инжектора.
$>Чувакам с C++, налепившим пачку синглтонов в пределах процесса, и не знакомых с DI, лучше открыть для себя этот самый DI.
Мне без разницы. Все зависимости надо определять и передавать явно.
А кому-то стоит сменить ник на нормальный, чтобы цитирование нормально выглядело.
Здравствуйте, aik, Вы писали:
aik>Мне вот всегда было интересно когда такое спрашивают про синглтоны — что именно ожидают в ответ? Простое "закрыть локом" ведь не проканает же? Например, я вбил это в гугл — получил ответы про яву, где никаких локов нет, потому что оии где то внутри классов явы зарыты.
Насколько помню, в C++11 и выше можно ограничиться обычной статической переменной так как гарантируется её атомарная инициализация. Компилятор барьеры напихает в код всё будет пучком.
SD>>Эти слова бы, да всем ФП-разработчикам на лбу высечь, дабы отучились "а мы сейчас это в ETS-таблицу сложим и будет вам shared state". S>Это имеет право на жизнь если в таблицу пишет только один процесс, а читают многие (protected ETS) или в каждый ключ пишет свой процесс.
И как это решает всю ту кучу проблем, которую имеет shared state? Как это поможет от отсутствия garbage в этой таблице? Как это помешает одним процессам разгромить state других? Насколько хорошо это будет работать с concurrency? А что будет, если все планировщики будут одновременно исполнять процессы, читающие эту таблицу, в NUMA-архитектуре? (ответ: огромное количество minor page faults).
В общем, shared state — это всегда shared state, и нужно понимать все implications.
$>Ты так гордишься, что булькаешься в "проектах с историей на плюсах".
Не знаю, что такое "булькаешься".
Но так уж выходит, что за "проекты с историей" сейчас очень неплохо платят
$>На самом деле конечно, есть проекты где на плюсах и с паттернами всё нормально. Просто ты в такие компании с твоим отношением к этой тематике не пройдешь.
S>Вопрос, впринципе, нормальный, чтобы понять как человек глубоко копал не сколько даже практику, а теорию. Если не ответит, значит нужно попроще, иначе -- посложнее.
Это не "попроще" и "посложнее". Это просто показывает, делал ли человек что-то с этим связанное относительно недавно (так что еще не успел забыть). Для программиста это не главное. А главное то, что программист может такую информацию найти на короткое время. Именно это и следует смотреть на собеседовании. Не то, что программист недавно делал (и потому помнит), а то, как он способен разобраться в задаче, которую он еще не делал.
Поэтому я считаю задачу "найти и исправить проблемы в говнокоде" — жизненной. Ибо это как бы не 90% реальности, данной нам в офисе.
Здравствуйте, SkyDance, Вы писали:
S>>Вопрос, впринципе, нормальный, чтобы понять как человек глубоко копал не сколько даже практику, а теорию. Если не ответит, значит нужно попроще, иначе -- посложнее. SD>Это не "попроще" и "посложнее". Это просто показывает, делал ли человек что-то с этим связанное относительно недавно (так что еще не успел забыть). Для программиста это не главное.
Не соглашусь. Быть может ищут действительно сильного программиста, которые такие детали должен знать. Ну вот нужен сильный программист .net. И если человек
такие вещи не знает, то это уже звонок. Сложная кодовая база, нужно писать новый функционал и т.д. Такие люди иногда нужны.
SD> А главное то, что программист может такую информацию найти на короткое время. Именно это и следует смотреть на собеседовании. Не то, что программист недавно делал (и потому помнит), а то, как он способен разобраться в задаче, которую он еще не делал.
Ну знаете ли, с таким подходмо навыки программирования вообще не нужны. Нагуглит. Глваное, чтобы умел искать инф-ию.
SD>Поэтому я считаю задачу "найти и исправить проблемы в говнокоде" — жизненной. Ибо это как бы не 90% реальности, данной нам в офисе.
Увы, похоже это так. Но код разный бывает. Бывает сложная кодовая база, где используется много продвинутых вещей, знать которые необходимо,
чтобы править и читать.
Здравствуйте, kaa.python, Вы писали:
KP>Мне без разницы. Все зависимости надо определять и передавать явно.
Это в FP ты можешь передать функцию с замыканием. А в OOP нужно работать на его принципах, но паттены OOP спасают.
KP>А кому-то стоит сменить ник на нормальный, чтобы цитирование нормально выглядело.
Так это баг в цитировании.
S>Не соглашусь. Быть может ищут действительно сильного программиста, которые такие детали должен знать. Ну вот нужен сильный программист .net. И если человек S>такие вещи не знает, то это уже звонок. Сложная кодовая база, нужно писать новый функционал и т.д. Такие люди иногда нужны.
Нет, нет, нет и еще раз нет. Сильный программист — это не тот, который *прямо сейчас* помнит эти детали. А тот, который:
1. Не будет делать того, что он не понимает.
2. Может быстро разобраться и понять.
3. Сделает то, что действительно нужно, и так, чтобы в будущем не наступать на эти же грабли снова.
Иными словами, сильный программист — это не тот, кто помнит мантру "если в деструкторе вылетает исключение, программа terminate-ится", а тот, кто понимает, как устроен современный софт, как устроена обработка ошибок/исключений, как работает система типов и тому подобные фундаментальные вещи.
Тем и отличается сильный программист от слабого. Фуднаментом. Который является мультипликатором продуктивности. Современные императивные платформы, будь то Java, .NET, C++ или что угодно еще, имеют по сути один фундамент. Еще один — это функциональщина, там надо вывернуть мозги набекрень (не у всех удается, и лучше делать в молодом возрасте). И с багажом знаний — двумя фундаментами, елси угодно, плюс профильным образованием — вот это уже действительно сильный программист, что может двигать мир. Такие есть, пусть и немного их.
S>Ну знаете ли, с таким подходмо навыки программирования вообще не нужны. Нагуглит. Глваное, чтобы умел искать инф-ию.
Добро пожаловать в Гугл, Фейсбук, Амазон, и подавляющее большинство ИТ (и не только ИТ) контор. Более того, добро пожаловать в современный мир. Правильно, immediate knowledge не нужно, ибо прикладные знания легко доступны. В отличие от фундаментальных. Которые не имеют однозначного вопрос-ответа.
S>Увы, похоже это так. Но код разный бывает. Бывает сложная кодовая база, где используется много продвинутых вещей, знать которые необходимо, S>чтобы править и читать.
Под такие задачи чаще всего или уже есть нужный человек (тот, что писал именно ту "продвинутую вещь"), либо нужен действительно редкий и сильный программист. Но задач таких, надо отметить, очень и очень мало.
Здравствуйте, kaa.python, Вы писали:
aik>>Мне вот всегда было интересно когда такое спрашивают про синглтоны — что именно ожидают в ответ? Простое "закрыть локом" ведь не проканает же? Например, я вбил это в гугл — получил ответы про яву, где никаких локов нет, потому что оии где то внутри классов явы зарыты. KP>Насколько помню, в C++11 и выше можно ограничиться обычной статической переменной так как гарантируется её атомарная инициализация. Компилятор барьеры напихает в код всё будет пучком.
Вот что то сомневаюсь что этот ответ активный зачтёт как правильный. Как барьеры помогут если 2 потока одновременно пытаются инициализировать одну переменную?
Здравствуйте, aik, Вы писали:
KP>>Насколько помню, в C++11 и выше можно ограничиться обычной статической переменной так как гарантируется её атомарная инициализация. Компилятор барьеры напихает в код всё будет пучком.
aik>Вот что то сомневаюсь что этот ответ активный зачтёт как правильный. Как барьеры помогут если 2 потока одновременно пытаются инициализировать одну переменную?
https://en.m.wikipedia.org/wiki/Double-checked_locking
У C++ 11 появилась фича. У Oracle JVM неофициально похожая техника (основанная на гарантии атомарности загрузки Class-а) работает, но например у андроида не работала.
Здравствуйте, aik, Вы писали:
aik>Вот что то сомневаюсь что этот ответ активный зачтёт как правильный. Как барьеры помогут если 2 потока одновременно пытаются инициализировать одну переменную?
Без понятия. Но вот стандарт:
such a variable is initialized the first time control passes through its declaration; such a variable is considered initialized upon the completion of its initialization. [...] If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.
Здравствуйте, $$, Вы писали:
aik>>Вот что то сомневаюсь что этот ответ активный зачтёт как правильный. Как барьеры помогут если 2 потока одновременно пытаются инициализировать одну переменную?
$>https://en.m.wikipedia.org/wiki/Double-checked_locking
$>У C++ 11 появилась фича. У Oracle JVM неофициально похожая техника (основанная на гарантии атомарности загрузки Class-а) работает, но например у андроида не работала.
