maytonА тут? Как ткнуть носом доказательство? Этож не теорема мать ево Пифагора. Просто best practices.
Или так называемые философии программинга. Всякие Киссы. Солиды и Ягни. Попробуй их докажи
когда математики нет. Это не тождество что слева там нолик и справа доказано что нолик.

Вот именно про это я и говорил в предыдущем топике, все эти SOLID и тд - лишь костыли, призванные улучшить изначально корявую философию ООП

Не совсем согласен насчет "проблем". Я соглашусь, что можно не знать текста самой задачи и попросить ее переформуоировать в треминах межпроцессного взаимодействия, но как их решить то вы просто обязаны знать.
Проблема парикмахера(как правильно шарить состояние между процессами\потоками) - на знание мьютексов, чтобы программа работала надо синхронизироваться на состоянии и допускать в критические блоки только один процесс
Проблема философов(доступ к одним и тем же ресурсам из нескольких потоков\процессов) - на знание как избежать дэдлок(брать ресурсы в определенном порядке + таймаут).

Ну и в принципе - если вы заявляете что обладаете знаниями многопоточного программирования, то странновато не знать классику

mini.weblabandreykaTДа. к любому собесу в принципе неплохо бы подготовиться. просто с филосовскими вопросами можно не сойтись в некоторых аспектах с собеседующим. и если он малоадекватный, то ты в его глазах еще и дураком будешь впрочем, он в твоих будет самодуром как минимум.

это к теме лисковых и строгих убеждений. разве не лучше для обеих сторон это выяснить быстро и сразу, на собеседовании ?
Выяснить что?

mini.weblabmayton,
ну вот смотри,
человека спрашивают про разницу между объектами, созданными методо1 и методом2, а он начинает че-то гнать насчет женитьбы и философии.
100500 неадекват же!

Человека спрашивают про то как правильно создать объект в приложении, а он начинает задвигать про какие-то фабрики, синглтоны. HR, какого вы укурков опять допускаете?

mini.weblabзабыл ник,
выяснить насколько комфортно будет вместь работаться, и сработаетесь ли вообще
В больших компаниях в основном собеседуют те кто свободен или есть желание\опыт по конкретным технологиям. Иногда набирают в новую команду и т.д, личностные качества должны проверяться HR, это вообще не предмет собеседоания. Конечно если собеседуемый ведет себя странновато я скажу об этом HR, но это никак не должно влиять на оценки

maytonзабыл никПроблема философов(доступ к одним и тем же ресурсам из нескольких потоков\процессов) - на знание как избежать дэдлок(брать ресурсы в определенном порядке + таймаут).

Это как раз про то что "дефолтный порядок" породил дедлок.
Или я не понял тебя, или не дефолтный порядок породит дэдлок еще быстрее, поэтому я и говорю нужен порядок + таймаауты, одного недостаточно

mini.weblabзабыл никЧеловека спрашивают про то как правильно создать объект в приложении, а он начинает задвигать про какие-то фабрики, синглтоны. HR, какого вы укурков опять допускаете? необязательно, может человека спрашивают, что будет если создать объект неправильно
про синглтоны и фабрики вообще до вас никто не упоминал (это на тему укурков)
Ну судя по тому что вы пока с трудом умеете проводить аналогии и вычленять абстракции, предположу что ваш уровень где-то между джуниором и мидл. На таком уровне, вопросы типо как создать объект правильно допустимы и имеют смысл. С точки зрения сеньора и выше, одним упоминанием принципа из SOLID\паттерна\"проблемы философа" он просто смывает пласт вопросов и малозначительных деталей для обьяснения, что позволяет сразу перейти к следующей теме. Все эти принципы для того и придуманы чтобы коммуникация между девелоперами была быстрее и эффективнее, и если вы "тонете" в этом то есть два возможных обьяснения - либо неопытность либо нежелание учиться. Первый случай это вполне нормально для определенных позиций, но выведывая детали собеседующий потратит кучу времени и на остальные важные темы просто не хватит времени. И это прямым образом повлияет на отзыв о вас в первую очередь, потому что если не уверен лучше не бери(с)

andreykaTзабыл никНе совсем согласен насчет "проблем". Я соглашусь, что можно не знать текста самой задачи и попросить ее переформуоировать в треминах межпроцессного взаимодействия, но как их решить то вы просто обязаны знать.
Проблема парикмахера(как правильно шарить состояние между процессами\потоками) - на знание мьютексов, чтобы программа работала надо синхронизироваться на состоянии и допускать в критические блоки только один процесс
Проблема философов(доступ к одним и тем же ресурсам из нескольких потоков\процессов) - на знание как избежать дэдлок(брать ресурсы в определенном порядке + таймаут).

Ну и в принципе - если вы заявляете что обладаете знаниями многопоточного программирования, то странновато не знать классику
вот ты в двух словах всю интригу этих задачек объяснил и всё стало понятно.
я думаю многие понимают и как работает дедлок и как его избежать и для чего нужны мьютексы в шейред ресурсах. а вот всё остальное - это демагогия и обертка. скажи проще и всё будет проще понимать.

Согласен, я просто часто собеседую потому в курсе,\но когда не знаю что-то или вылетело из головы - то правильный ответ такой - "Извините, я уже немного устал, я точно слышал об этой проблеме и наверняка знаю как ее решать, но не помню точного описания. Будьте добры сформулируйте в терминах экзекьютор\поток бла-бла и скорее всего я скажу вам как ее решить". Если собеседующий сам не сведущ, то это еще и некислый троллинг получится.
Ну и да, знать все нельзя, это очевидно. Иногда я спрашиваю веши напрямую не относящиеся к задаче, и не жду особо ответа, но если вдруг человек ответил, то это просто огромный плюс, значит он обучается\интересуется

mini.weblabзабыл ник,

и как же ответить на вопрос изначально заданный ТС ??!
(для человека претендующего на джуниора-мидла)

Давайте, определимся, надо отвечать на вопрос ТС или на вопрос, который ему задавали на собеседовании? Вопрос ТС практически бессмысленен, он о форме, а не о содержании. Черт его знает что его там спрашивали и как он это понял. Вся тема суть попытка понять что он хотел узнать:) На собеседовании явно вопрос звучал не так.

Что могли спросить на собеседовании так это - что такое полиморфизм и приведи пример на Java. Джун и мидл по идее ответили бы что-то типо - ну это когда наследуешься и переопределяешь методы и по одной ссылке можно вызвать разные методы. Подкованный школяр сказал бы что полиморфизм — это способность обьекта использовать методы производного класса, который не существует на момент создания базового. Если бы спрашивали меня - я бы спросил в ответ а какой полиморфизм интересует - subtyping, parametric или ad-hoc? Думаю на этом бы тема полиморфизма закончилась.
ТС же скорее всего промямлил что-то невразумительное и собеседующие не поленились и стали вытягивать из него информацию, чтобы понять, понимает ли он полиморфизм хотя бы на уроне code monkey, привели пример, сделали сабклассы и начали задавать вопросы в стиле - а что вот тут вернется, а что если тут ссылку сделать на базовый класс. Вот и все

andreykaTзабыл никпропущено...

а какой полиморфизм интересует - subtyping, parametric или ad-hoc? Думаю на этом бы тема полиморфизма закончилась.

эх. еще бы это еще как то явно использовалось в реальных приложениях.
в скала как раз-таки все 3 и можно увидеть) Именно пересев на скалу я и понял чем они отличаются:)

andreykaTя помню как то брал курс на юдеми про многопоточку и там как раз чел рассказывал про эти две задачки. если честно, то бJльшей мудоты я не видал. но наверное это зависит и от рассказчика. вроде еще в канкарренс ин практиз эту тему поднимали (не уверен)
Да, это скорее всего рассказчик такой. Ну или на тот момент не в коня корм был. Иногда перечитываю чкнижки казавшиеся пару лет назад сложными и удивляюсь какие тривиальные вещи тут написаны.

maytonandreykaTпропущено...

а можно десятки лет проработать и не заниматься конкурирующим ПО в принципе. ну или на грани - делаем всё иммутабельным и идите вы в пень со своими локами и шаред ресурсами.
Можно акторы кодить 10 лет. Нормальный кейс? Да.

Кодить можно. Если ты что то не используешь - это не твоя вина, но твоя проблема. Другие используют и имеют конкурентное преимущество, вот и все. Глупо обижаться на препода за то что он спрашивает то о чем ты не знаешь:)

andreykaTmaytonпропущено...

Кстати да. Типизация тоже в Java существует но не так ярко выражена. Нет такой математичной строгости
как в Scala или Haskell.
для меня игры с тайпами в скале пока ограничиваются только алиасами.
глянул эту дичь с тем, как они расширили функционал дженериков - мне стало дурно и я всё закрыл. думаю, через полгодика еще раз открою и перечитаю. ))

кстати по дженерикам,
как сказал гослинг на маракане: есть два типа людей: одни не знают как обращаться с генериками, другие думают что знают.

в каких то базовых комбинациях я с этим всем еще дружу, как копнуть глубже - всё, приехали. в джаве я даж активно писал код на дженериках. в скале вот пока толи задач не было толи мозга не хватило. там где надо было хотел впилить в джава-стиле и обломился.

по тайпклассам курил вот это:

https://scalac.io/typeclasses-in-scala/

кстати там как раз и ссылаются на адхок подлиморфизм.

Дженерики мне тоже тяжело заходили, из-за контраваринатности. Пока не разжевал сам себе пример с Function[-A, +B] и вдруг все стало ясно, понятно и очевидно. И кстати намного более интуитивнее чем в Java.

Ad-hoc и typeclasses это отдельный огромный пласт, без которого имплементацию ФП в скале просто не понять. Понятие идет иреративно, я пару раз думал что понял их, а потом мне открывался более глубинный смысл, примерно как с монадами. Но теперь если смотреть с позиции опыта - ничего там нету страшного и тяжелого. Typeclass - в классическом понимании описание capabilities которыми обладает класс, допустим нам надо ввести понятие эквивалентности
1) Мы делаем интерфейс\trait Equal[A] с методом equals(a1:A, a2:A):Bollean
2) Допустим нам в тесте надо проверять объекты на эквивалентность, мы пишем метод isSame[A:Equal](a1:A, a2:A):Boolean = a1.equal(a2) -------- этот код компилируется только если мы вызовем isSame на объектах, которые имеют capability Equal
3) допустим у нас есть case class User(name), в Java нам надо было бы делать так class User extends Equal, или вводить метод equals в класс Object с тайпклассами мы можем сделать пункт 4
4) implicit val userEquals = new Equal[User]{ def equals(u1:User, u2:User) = u1.name == u2.name}
5) теперь isSame(User("a"), User("b")) скопилируется а isSame(Profile(a), Profile(b)) --- нет
6) Таким образом мы расширили функционал, не притрагиваясь к изначальному коду User и не засирая его методами, ортогональными к понятию User.
7) А теперь представь сколько багов можно было словить во время компиляцияя если бы методы equals hashcode и тд не были бы обьявлены в Object

maytonзабыл никпропущено...


Кодить можно. Если ты что то не используешь - это не твоя вина, но твоя проблема. Другие используют и имеют конкурентное преимущество, вот и все. Глупо обижаться на препода за то что он спрашивает то о чем ты не знаешь:)
Если мы имеем в виду задачу о философах - то это задача на "десерт". Или на сладкое.
Серъезно если собеседовать человека на проект? Нужно ли вообще его про это спрашивать.
Можно спросить в конце. Но не делать это фактором который определяет проф-пригодность
специалиста вообще.

P.S. - Карла Маркса знаете?
- Знаю. Дальше.

Ну тут конечно согласен. Такую задачу в принципе спрашивать не стоит, если только не собеседование в крутую контору помешанную на многопоточности. Но вот если кандидат скажет - а ну тут надо решать как в классическом решении задачи о философах - это ему огромный плюс в карму и следующий вопрос скорее всего снимается