KP>Ну... а если запихать в ETS-таблицу к которой обращается единственный GenServer?
Это для того, чтобы сильно проиграть в производительности относительно других решений? Мы недавно исследовали 6 разных вариантов, и private ETS далеко не самый быстрый вариант хранения. Не в последнюю очередь из-за более дорогих операций аллокации (ets allocator вместо eheap). Плюс фрагментация, плюс (сюрприз!) locking, плюс если еще и ETS использовать по имени, а не по рефернсу.
KP> Я к тому, что состояние всяко хранить приходится даже в функциональных языках,
Состояние процесса следует хранить в его состоянии А не в базе данных (ETS изначально предполагались быть БД, и, собственно, это в некотором роде так и есть).
KP> а если язык реализует концепт let it crash, то вопрос надежного сохранения состояния как никогда важен.
Стоит изучить очень важную тему — supervision, и там как раз есть все необходимое для понимания, какое состояние нужно сохранять, и как.
KP> Или речь про давайте класть всё в ETS-таблицу и отовсюду в неё лазить за данными?
...но ты прав, речь чаще всего именно про это !!! С этим больше всего бороться приходится.
KP>Самый ад с синглтонами в C++
О если бы. Ответы, которые можно нагуглить, — уровень от силы миддл-левел.
G>Но наверно тяжело делать это в ходе интеревью, не так ли?
Поэтому я и спрашиваю: в чем смысл задавать такой вопрос на интервью? Если ответ легко нагуглить вне интервью, его нет смысла задавать на интервью, потому что когда человек с таким вопросом встретится, он просто нагуглит ответ.
G>А ответ лично я ожидал бы такой:
$>Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить.
Проблема не в том, что "неумение готовить", а в том, что об этом вообще нужно задумываться. Это показатель неэффективности инструмента (с точки зрения промышленной разработки софта).
Здравствуйте, $$, Вы писали:
>> Ты натянул сову на глобус. Понятно, что ООП это плохо, а ФП хорошо. Но ты и другие отметившиеся тут топите, что паттерны знать вредно при ООП.
Ух как копнул! Да само по себе ООП в классическом виде (классы + наследование) вредно И паттерны из ООП лишь утяжеляют код. Посмотри на практически любое Java приложение – оно тормозит что ппц. И ведь совсем не потому что JVM тормозная, а потому что правильный Java разработчик жизни себе без паттернов не мыслит.
>> При этом вспоминаешь про ФП. При этом, если чел действительно мыслит категориями ФП, то проблемы написать через рекурсию или развернуть хвостовую рекурсию, у него не должно возникнуть. Как например, и отсортировать массив.
Да, я могу так же Go без всякой функциональщины взять в качестве примера и сказать тоже самое – синглтоны зло! Ну да рекурсию любой дурак напишет, чего ж там писать-то?
>> Как и написать топологическую сортировку на доске (что лежит в основе корректной инициализации DI).
Кхм, ну вот я единственный раз писал топологическую сортировку когда задачки на ЛитКоде решал и сейчас крайне смутно помню как она там устроена. Само собой человек не задрачивавшийся на тестовые задачки из ФАНГ сольется на таком и подумает что у собеседующего крыша потекла (если, конечно, собеседование не в ФАНГ).
KP>Да и DI ваше тоже говно, зависимости надо передавать явно.
О!
Еще одни золотые слова.
Я смотрю, уровень участников RSDN довольно заметно растет, и к тому же коррелирует с освоением новых более мощных языков и инструментов. Глядишь, уже скоро дойдет до обсуждения действительно сложных вещей, large scale, concurrency, distribution, property-based testing, и т.п.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, $$, Вы писали:
>>> Ты натянул сову на глобус. Понятно, что ООП это плохо, а ФП хорошо. Но ты и другие отметившиеся тут топите, что паттерны знать вредно при ООП.
KP>Ух как копнул! Да само по себе ООП в классическом виде (классы + наследование) вредно И паттерны из ООП лишь утяжеляют код. Посмотри на практически любое Java приложение – оно тормозит что ппц. И ведь совсем не потому что JVM тормозная, а потому что правильный Java разработчик жизни себе без паттернов не мыслит.
Да ладно. Как это так объясни?
Ну некоторые, конечно, пишут класс для инкремента. Но как это влияет на производительность настолько?
Здравствуйте, SkyDance, Вы писали:
SD>$>Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить.
SD>Проблема не в том, что "неумение готовить", а в том, что об этом вообще нужно задумываться.
Ты задумываешься про ETS. Тоже неэффективный инструмент?
Мой пойнт, что паттерн Синглтон- это просто паттерн для хранения единственного экземпляра. То, что какие-то сиплюсники или жависты его используют не по назначению, это следствие их незнания паттернов проектирования.
$>Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить.
$>Корректный порядок инициализации гарантирует DI. И по устройству DI (какие алгоритмы и структуры данных там применяются) можно поспрашивать. Но много народа слов таких не слышало.
Тёма, ты только что доказал, что не работал с мало-мальски сложными проектами с историей на плюсах. Поэтому между тобой и людьми, которые на этом собаку съели, такая пропасть, что им после вопроса про синглтон банально не о чем дальше с тобой разговаривать.
Ты даже не понял, что за проблему KP упомянул.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Да ладно. Как это так объясни?
Объясняю. Вместо классов и наследования в понимании ООП, есть два куда более удачный подхода: чистые функции или, если писать на функциональном языке никак, то интерфейсы (Go или Rust, не Java или C++). Эти концепции позволяют значительно лучше разделить данные с кодом и обеспечить более просто тестирование системы.
CAF>Ну некоторые, конечно, пишут класс для инкремента. Но как это влияет на производительность настолько?
Паттерны вводят довольно большое количество вспомогательных сущностей, зачастую для замены одного простого if/else. Фабрика для одного/двух объектов? Даа! Мы же на Java пишем, вдруг потом (говорить с придыханием) мы захотим расширить систему? И когда такое "вдруг" начинает пронизывать всю систему, она, почему-то, начинает медленно работать
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Да ладно. Как это так объясни?
KP>Объясняю. Вместо классов и наследования в понимании ООП, есть два куда более удачный подхода: чистые функции или, если писать на функциональном языке никак, то интерфейсы (Go или Rust, не Java или C++). Эти концепции позволяют значительно лучше разделить данные с кодом и обеспечить более просто тестирование системы.
Это не про скорость. CAF>>Ну некоторые, конечно, пишут класс для инкремента. Но как это влияет на производительность настолько?
KP>Паттерны вводят довольно большое количество вспомогательных сущностей, зачастую для замены одного простого if/else. Фабрика для одного/двух объектов? Даа! Мы же на Java пишем, вдруг потом (говорить с придыханием) мы захотим расширить систему? И когда такое "вдруг" начинает пронизывать всю систему, она, почему-то, начинает медленно работать
А если перебора такого нет. То как влияет? Можно пример?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Gradiens, Вы писали:
G>>И вопрос (ну просто один из вопросов который приведен навскидку для того, чтобы проиллюстировать мой субъективный подход) был в том, что произойдет если исключение будет выброшено из Dispose и что изменится если исключение будет выброшено из финализатора.
S>Если искл. в финализаторе, то срубит приложение. Если Dispose, то смотря какой поток будет его вызывать.
Ну вот, хороший лаконичный ответ. Можно, понятное дело, копать глубже, но я бы на месте интервьювера перешел к другим вопросам.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>А если перебора такого нет. То как влияет? Можно пример?
KP>Нет? Это как нет? Должно быть как-то так.
А где оценка производительности? Выглядит плохо, но как влияет?
Ну выполняется там в глубине критический кол, оптимизированный jit а почему расходы большие?
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>А где оценка производительности? Выглядит плохо, но как влияет? CAF>Ну выполняется там в глубине критический кол, оптимизированный jit а почему расходы большие?
Да вроде это очевидно. В Java практически всё (или вообще всё? не уверен) является объектом. Весь этот громадный стек ни что иное как нагромождение разных объектов. И каждый объект где-то лежит, его создали, его время жизни отслеживается. Всё это не бесплатно, и расходует память и процессорное время. Ты пытаешься сказать что это не имеет знание?
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>А где оценка производительности? Выглядит плохо, но как влияет? CAF>>Ну выполняется там в глубине критический кол, оптимизированный jit а почему расходы большие?
KP>Да вроде это очевидно. В Java практически всё (или вообще всё? не уверен) является объектом. Весь этот громадный стек ни что иное как нагромождение разных объектов. И каждый объект где-то лежит, его создали, его время жизни отслеживается. Всё это не бесплатно, и расходует память и процессорное время. Ты пытаешься сказать что это не имеет знание?
Хорший вопрос. А в этом дело? Вызовы инлайнятся. Или io или ждут на мониторе?
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Хорший вопрос. А в этом дело? Вызовы инлайнятся. Или io или ждут на мониторе? CAF>>Может пишут тяп-ляп просто?
KP>Не, так скучно. Ты прав, никакой разницы, всем насрать
А разница большая ...
S>>Если не ошибаюсь, то финализатор вызывет Dispose, если он есть, есть ли нет -- то деструктор ~MyClass{} A>~MyClass{} — это и есть финализатор, деструкторов в c# нет. dispose никто сам ниоткуда не вызывает, ты должен делать это руками (если нужно, а нужно не всегда).
Здравствуйте, SkyDance, Вы писали:
G>>Но наверно тяжело делать это в ходе интеревью, не так ли? SD>Поэтому я и спрашиваю: в чем смысл задавать такой вопрос на интервью? Если ответ легко нагуглить вне интервью, его нет смысла задавать на интервью, потому что когда человек с таким вопросом встретится, он просто нагуглит ответ.
Вопрос, впринципе, нормальный, чтобы понять как человек глубоко копал не сколько даже практику, а теорию. Если не ответит, значит нужно попроще, иначе -- посложнее.
А не в базе данных (ETS изначально предполагались быть БД, и, собственно, это в некотором роде так и есть).
И паттерны из ООП лишь утяжеляют код. Посмотри на практически любое Java приложение – оно тормозит что ппц. И ведь совсем не потому что JVM тормозная, а потому что правильный Java разработчик жизни себе без паттернов не мыслит.
