1 — ответ в стиле одной известной IT компании: «Такого функционала нет — значит оно вам не нужно и держите наши продукты правильно» =)
Согласен с вами о необходимости использовать технологии, соответствующие задаче (если вы это имели ввиду), но кажется вы немного утрируете. Например, кому-то удобно ездить в автомобиле домой с работы (если он работает далеко от дома) а кто-то пытается убедить, что «вы из своего автомобильного мирка не видите прелести поездки на велосипеде», работаю в четырех кварталах. Пример натянутый, но суть постарался передать: «программируйте с использованием языка» (с).
В ООП, реализованном через классовое наследование не нужно думать? Очень спорное утверждение.
А если (по вашим словам) в ООП, реализованном через прототипное наследование, нужно думать намного больше, то м.б. действительно лучше рассмотреть другие альтернативы? Я имею ввиду нормальных во всех отношениях разработчиков. На брейнфаке, к примеру, нужно думать достаточно.
Наследование обязано уменьшить сложность. А думать нужно всегда (мы же с вами на ИТ портале, где люди обычно думают).
Вы совершенно правы по поводу отличий в подходе к наследованию, но любая модель наследования, в любом случае, позволяет создавать уровни абстракции. И они могут «протекать» независимо от используемого подхода.
Во вторых, почему вы думаете, что разработчики не могут освоить прототипное наследование? Думаю, для многих классовое наследование может быть просто удобнее и привычнее. Работа с привычными инструментами влечет ускорение разработки.
Я согласен с тем, что использование классового наследования в JavaScript не имеет большого смысла, но мы же говорим уже о совершенно другом языке, который транслируется в JS.
Да, но вы назвали пост олипмиадным программированием и поместили его в блог «Алгоритмы». У вас получилась хорошая статья, но я за то, чтобы вещи назывались своими именами.
Просто сейчас похоже больше на набор примеров из базового курса аналитической геометрии. Где тут вычислительная геометрия и программирование? В чём сложность и «олимпиадность»? Где выбор оптимальных решений?
Большинство подобных задач решаются чисто аналитически.
Я так понимаю, как часть другой задачи? Обычно в статьях про олимпиадное программирование приводятся оптимальные решения (алгоритмы) какой-либо задачи или класса задач. Может быть вы можете привести пример какой-нибудь реальной олимпиадной/конкурсной задачи?
Мне, да и многим другим, скорее всего, было бы интересно.
Никак (обсуждается немного выше), но это больше касается фриланса и другой работы «на один раз». Согласитесь, что в серьезной компании с вами, при приеме на работу, будет общаться специалист, который хочет получить в команду грамотного/обучаемого/и тд. сотрудника.
Иди вы про другое?
Поддерживаю. Особенно странно в таком контексте выглядят непризнанные гении, не сумевшие получить высшее образование, но при этом с таким неоправданно завышенным эго, что кажется, что от них сияние исходит… Эффект Даннинга — Крюгера
Поддерживаю автора с небольшим замечанием.
Явление «казуализации» и низкого профессионализма множества современных разработчиков повышает рыночную стоимость настоящих профессионалов. Это нужно понимать, особенно начинающим.
Вот сейчас набегут фанаты прототипного наследования и объяснят, кто тут не прав :)
Согласен с вами о необходимости использовать технологии, соответствующие задаче (если вы это имели ввиду), но кажется вы немного утрируете. Например, кому-то удобно ездить в автомобиле домой с работы (если он работает далеко от дома) а кто-то пытается убедить, что «вы из своего автомобильного мирка не видите прелести поездки на велосипеде», работаю в четырех кварталах. Пример натянутый, но суть постарался передать: «программируйте с использованием языка» (с).
Повторюсь, речь о другом ЯП, транслируемом в JS.
А если (по вашим словам) в ООП, реализованном через прототипное наследование, нужно думать намного больше, то м.б. действительно лучше рассмотреть другие альтернативы? Я имею ввиду нормальных во всех отношениях разработчиков. На брейнфаке, к примеру, нужно думать достаточно.
Наследование обязано уменьшить сложность. А думать нужно всегда (мы же с вами на ИТ портале, где люди обычно думают).
Во вторых, почему вы думаете, что разработчики не могут освоить прототипное наследование? Думаю, для многих классовое наследование может быть просто удобнее и привычнее. Работа с привычными инструментами влечет ускорение разработки.
Я согласен с тем, что использование классового наследования в JavaScript не имеет большого смысла, но мы же говорим уже о совершенно другом языке, который транслируется в JS.
А вы не думаете что любые знания изменяют человека, даже если он ими не пользутся в повседневной жизни? Да тот же кругозор человека.
Про снайпера забавно)
Да, смысл иногда есть, например получить приблеженную оценку, но как правило численное решение уступает в скорости аналитическому.
Большинство подобных задач решаются чисто аналитически.
Мне, да и многим другим, скорее всего, было бы интересно.
Иди вы про другое?
Про фриланс конечно да…
Эффект Даннинга — Крюгера
Явление «казуализации» и низкого профессионализма множества современных разработчиков повышает рыночную стоимость настоящих профессионалов. Это нужно понимать, особенно начинающим.