Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 153
Итак, вы абстрактный программист в вакууме, работаете десять с лишним лет клепая сайты и решая простые однотипные задачи клиентов/компании. Вам хорошо и уютно в вашей нише, и только мучительно больно за бесцельно потраченное время в классе по теории вычислений и алгоритмическому анализу, который вам ничего не дал. По утрам закуривая сигарету за чашкой кофе, в глубине философских размышлений о бренности бытия вы задумываетесь: зачем же программистам, не решающим сложных задач, знать алгоритмы и основы анализа.
ПТУ — вот где должен был обучаться подобный человек, а не университет. Многие идут в институт лишь за корочкой, высшее образование — большой фетиш, а вот по правде: если ты собирался всю жизнь клепать типовые задачи — не нужен тебе университет.
Хотя многие ли адекватно оценивают, кем они хотят стать в жизни?
Мне правда непонятно: как можно в такой быстроизменяющейся отрасли пытаться создавать ПТУ?
Мне правда непонятно: как можно в такой быстроизменяющейся отрасли пытаться создавать ПТУ?
Да без проблем.
Студентов учат двум-трем языкам (Pascal\Delphi, C\C++\C#, php), рассказывают про html\css\js, показывают офисный набор, показывают немного БД. Потом требуют сделать небольшой сайт, обычно онлайн-магазин. Плюс гуманитарные и околоайтишные предметы, всякую теорию (рефакторинг, ООП, циклы разработки). Возможна "экзотика" типа асма, или Go, или Arduino — если преподаватель заинтересуется.
В итоге базовые конструкции (условия, циклы, массивы, таблицы, JOIN-ы) студентам знакомы, а дальше только практика. На выходе процентов 10-30 студентов можно смело порекомендовать как джунов.
А как по мне, программа в ПТУ гораздо быстрее меняется, нежели в университете, где, честно говоря, хватает устаревшей информации.
А она и должна быстрее меняться. Это совершенно логично: обучение короче, а значит менее глубокое. Нафига нужно менее глубокое и притом настолько же оторванное от нужд "производства" обучение?
ВУЗ берёт глубиной знаний, ПТУ — близостью к "производству". Непонятно почему программирование тут должно отличаться от других областей.
ВУЗ берёт глубиной знаний, ПТУ — близостью к "производству". Непонятно почему программирование тут должно отличаться от других областей.
Просто в конечном итоге получается, что окончивший ПТУ более подготовлен к реальным задачам, нежели окончивший ВУЗ.
И? В других отраслях так же. Токаря можно сразу отправлять точить детали (пусть простенькие), а будущему авиаконструктору предстоит ещё многому обучиться у мастера.
А уж полы мыть можно вообще почти без обучения… Не вижу никакой отраслевой специфики. Вот честно.
А уж полы мыть можно вообще почти без обучения… Не вижу никакой отраслевой специфики. Вот честно.
Где иначе? Хочешь побыстрее чисто практические навыки — получаешь начальное и/или средне-специальное образование.
Хочешь понимать "глубины глубин", разрабатывать новые методы (например, внезапно, алгоритмы) — добро пожаловать в высшее профессиональное.
Хочешь понимать "глубины глубин", разрабатывать новые методы (например, внезапно, алгоритмы) — добро пожаловать в высшее профессиональное.
Проблема в том, что как раз ПТУ в последнее время даёт больше этих самых глубин, нежели ВУЗы. Я считаю, что эта проблема возникла с переходом на бакалавриат, где пытаются выучить "в общем", оставляя подробности (в том числе и алгоритмы) на работодателей.
Вообще есть разнообразные курсы, где за несколько недель обучают той или иной технологии. Они обычно стоят довольно круглую сумму, и по выходу в теории человек выходит мастером, и они ещё помогают устроится на работу. Результат как правило получается такой, что человек лишается круглой суммы денег, приобретает базовое понимание одной технологии, и всё. Ещё проблема в том, чтобы давать актуальные навыки, т.е. нужны люди, которые работают в индустрии и не против преподавать.
Я вижу определённое применение для подобных людей: когда нужно накодить прототип быстро, но старших товарщей пока не получается оторвать от дел. Т.е. только для проэктов, которые либо краткосрочны (сделал и забыл), либо для создания proof of concept, которые потом будут выбрасываться и переделываться более опытными коллегами.
А так у меня довольно плачевный опыт даже в "вот тебе дизайн, иди его реализуй". Человек просто не понимает что от него хотят.
Я вижу определённое применение для подобных людей: когда нужно накодить прототип быстро, но старших товарщей пока не получается оторвать от дел. Т.е. только для проэктов, которые либо краткосрочны (сделал и забыл), либо для создания proof of concept, которые потом будут выбрасываться и переделываться более опытными коллегами.
А так у меня довольно плачевный опыт даже в "вот тебе дизайн, иди его реализуй". Человек просто не понимает что от него хотят.
ПТУ – это еще полбеды. Меня больше пугают курсы "Стань программистом с нами за 3 месяца, изучив HTML/CSS/JS".
Самый легкий способ выучить С++ за три недели: http://abstrusegoose.com/249
Занялся программированием через 2 месяца после окончания университета, по специальности никогда не работал, а в универ поступал по большей части чтобы получить отсрочку от армии и потому что «не в ПТУ же идти».
Может быть, если бы заранее знал, что когда-нибудь стану программистом (через 6 лет после окончания универа), то стоило бы выбрать ПТУ (сомневаюсь, что у нас в городе есть подходящий) и получить какие-то базовые знания по алгоритмам и шаблонам, чтобы хотя бы понимать всякие «строитель конструирует фабрику через итератор декоратора». Да, я только сейчас решил взяться за книгу по этой теме, но ни один «наглядный» пример, который я встречал в теме шаблонов, так и не донёс до меня, когда и какой именно из них нужно выбрать. Везде какие-то фабрики, производящие мебель разных типов или плотники, строящие дом. А если у меня интернет-магазин, то что из этого дом, а что мебель? Понимания не хватает. А если встречаю ккакой-то конкретный код, то он бывает такой длины, что вместо разъяснений только запутывает.
Может быть, если бы заранее знал, что когда-нибудь стану программистом (через 6 лет после окончания универа), то стоило бы выбрать ПТУ (сомневаюсь, что у нас в городе есть подходящий) и получить какие-то базовые знания по алгоритмам и шаблонам, чтобы хотя бы понимать всякие «строитель конструирует фабрику через итератор декоратора». Да, я только сейчас решил взяться за книгу по этой теме, но ни один «наглядный» пример, который я встречал в теме шаблонов, так и не донёс до меня, когда и какой именно из них нужно выбрать. Везде какие-то фабрики, производящие мебель разных типов или плотники, строящие дом. А если у меня интернет-магазин, то что из этого дом, а что мебель? Понимания не хватает. А если встречаю ккакой-то конкретный код, то он бывает такой длины, что вместо разъяснений только запутывает.
Например, на мерче Яндекс.Практикума так и написано: ПТУ XXI века :)
На практике я бы сказал что нужно не само глубокое знание большого числа алгоритмов, а базовое понимание и знание что он существует, чтобы можно было его найти и реализовать.
Это кстати относится вообще ко всей области программирования, она стала слишком велика чтобы "знать всё".
К сайтам и SQL вы погорячились, мне например недавно понадобилась комбинаторика (сочетания) для обычного интернет магазина, не бог весть что, но все таки, а от некоторых SQL запросов мозг сносит, sql-ex.ru объяснит что SQL бывает суровым.
Это кстати относится вообще ко всей области программирования, она стала слишком велика чтобы "знать всё".
К сайтам и SQL вы погорячились, мне например недавно понадобилась комбинаторика (сочетания) для обычного интернет магазина, не бог весть что, но все таки, а от некоторых SQL запросов мозг сносит, sql-ex.ru объяснит что SQL бывает суровым.
Глубокое знание может и не нужно, но общее понимание и знание что делает конкретный алгоритм, для чего можно использовать конкретную структуру данных — нужны. А если придётся реализовать что-то конкретное для своих целей, то всегда можно посмотреть литературу для деталей.
Вообще я не утверждал что-либо про SQL. Да и запрос запросу рознь. Можно писать запросы в пару строк из двух-трёх таблиц, а можно создавать SSIS пакеты, которые будет собирать и фильтровать данные из трёх разных баз данных на разных движках. У меня на работе SQL запрос на 6 экранов — норма, и они запускаются по ночам только, ибо исполняются по несколько часов. Да и чтобы знать конкретный движок БД хорошо — надо приложить усилия.
А как вам понадобилась комбинаторика для интернет-магазина?
Вообще я не утверждал что-либо про SQL. Да и запрос запросу рознь. Можно писать запросы в пару строк из двух-трёх таблиц, а можно создавать SSIS пакеты, которые будет собирать и фильтровать данные из трёх разных баз данных на разных движках. У меня на работе SQL запрос на 6 экранов — норма, и они запускаются по ночам только, ибо исполняются по несколько часов. Да и чтобы знать конкретный движок БД хорошо — надо приложить усилия.
А как вам понадобилась комбинаторика для интернет-магазина?
В этом магазине почти все товары сгруппированы, например есть трубы, 10 видов, у них 5 атрибутов: материал, длина, диаметр, толщина стенки и т.д.
Покупатель сначала видит просто товар "Трубы" и 5 select'ов которыми он выбирает нужный вариант, при выборе первого атрибута остальные соответственно фильтруются, чтобы показать возможные оставшиеся варианты.
Заказчик захотел, чтобы у некоторых товаров выбор стал минимальным, то есть например: материал, длина и толщина стенки однозначно определяют все 10 вариантов труб, значит выбирать диаметр не нужно и можно просто убрать этот select и вместо него показывать значение.
Чтобы найти этот набор атрибутов нужно перебрать все сочетания из n по k, вариантов может быть несколько и тут еще нужен вес атрибута, чтобы оставить для выбора более важные атрибуты (наибольший суммарный вес набора атрибутов).
Я кстати был очень рад что в python есть itertools.combinations, чтобы не писать алгоритм сочетаний самому :)
Покупатель сначала видит просто товар "Трубы" и 5 select'ов которыми он выбирает нужный вариант, при выборе первого атрибута остальные соответственно фильтруются, чтобы показать возможные оставшиеся варианты.
Заказчик захотел, чтобы у некоторых товаров выбор стал минимальным, то есть например: материал, длина и толщина стенки однозначно определяют все 10 вариантов труб, значит выбирать диаметр не нужно и можно просто убрать этот select и вместо него показывать значение.
Чтобы найти этот набор атрибутов нужно перебрать все сочетания из n по k, вариантов может быть несколько и тут еще нужен вес атрибута, чтобы оставить для выбора более важные атрибуты (наибольший суммарный вес набора атрибутов).
Я кстати был очень рад что в python есть itertools.combinations, чтобы не писать алгоритм сочетаний самому :)
Немного не по теме. Скажу за математику/физику и т.д. в предметной области. Вы предпочтете пользоваться программой написанной экспертом в предметной области (глючной, неудобной, медленной) или написанной программистом, который написал ее, консультируясь с предметниками, но которая удобная и понятная? С программами первого рода я сталкиваюсь постоянно — пользоваться ими невозможно: абсолютно интуитивно-непонятный интерфейс, какие-то баги, полная непродуманность функционала и т.д… А уж по их коду можно проводить лекции "Как не нужно писать". Только не надо писать про уникумов, который и там, и тут поспели — их мало.
А со статьей — согласен. И пускай лучше программист безупречно разбирается в этом, а третий закон Ньютона можно и у физика спросить.
А со статьей — согласен. И пускай лучше программист безупречно разбирается в этом, а третий закон Ньютона можно и у физика спросить.
В большей части виденных мной случаев своим удобством программа обязана не программистам (эти как раз обычно порождают неочевидные для всех остальных интерфейсы) — это достижение либо предметников, либо аналитиков, либо, если повезло, UX-дизайнера. То же относится и к функциональности — как раз эксперту в предметной области виднее, какая функциональность нужна, нежели аналитику.
Так что странный у вас пример.
Так что странный у вас пример.
Я думаю понимаю о чём вы говорите. Есть много инструментов, которые создаются учёными в процессе исследований, и они частенько утекают в таком виде без изменений в общий доступ. Такие программы действительно неудобны, но не потому что те кто их написал — плохие программисты, а потому что писали они имея в голове модель эксперта в качестве пользователя. Плюс удобство установки на разные ОС тоже не предусматривалась. А если человек работал в индустрии, то он больше ориентирован на пользователей, и вопросы удобства использования программы у него на уровне инстниктов.
Программирование еще пока не имеет формальных градаций, в отличие от других профессий. Например, у врачей и учителей есть категории, у слесарей есть разряды, и т.п. Программирование же молодо, поэтому стандартов нет, и поэтому каждый придумывает свои критерии оценки, кто во что горазд. Кто-то на собеседованиях спрашивает про форму люков, кто-то про бинарные деревья, а кто-то заставляет гуглить и писать на заведомо незнакомом языке (ну типа оценить как быстро кандидат может находить информацию). Но если смотреть на тех же слесарей, например, то на заводе слесарь 1-го разряда делает свою работу, а 6-го — свою. Так же и в программировании: есть 90% рутинных простых работ, для которых достаточно программиста 1..4-го разряда, а есть 10% нетривиальных задач, где понадобятся совместные усилия программиста 6 разряда, архитектора, бизнес-аналитика и прочих начальников. Для задач уровня 1-го разряда знание алгоритмов не обязательно, а 6-го — обязательно, но не достаточно.
И еще чтобы строем ходили!
Узнать уровень соискателя на собеседовании довольно нетривиальная задача. Вопросы про теорию можно зазубрить не понимая, часто задаваемые вопросы тоже можно нагуглить. У меня были соискатели, которые вроде бы отвечали на вопросы неплохо, имели опыт, а как за дело браться — понимания ноль, и по малейшему чиху — в гугл. Простейший проект пишется месяцами, и по завершению случайным образом постоянно падает.
Обычно я смотрю что соискатель делал на предыдущем месте работы, и задаю вопросы на понимание того, что он делал, какие технологии использовал, какую роль играл в проэкте. Если человек не путается, то можно углубится в теорию.
Обычно я смотрю что соискатель делал на предыдущем месте работы, и задаю вопросы на понимание того, что он делал, какие технологии использовал, какую роль играл в проэкте. Если человек не путается, то можно углубится в теорию.
А если соискателем является студент?
У нас контракт с местными университетами и мы часто принимаем студентов на прохождение интернатуры. Студентов я опрашиваю в зависимости от курса и от указанных в резюме навыков. Их больше по теории гоняю, ибо практики мало. Но тоже акцент больше на понимание теории, чем на зубрение деталей. Часто студенты делают интересные проекты в университете или для удовольствия, тогда спрашиваю детали про них.
Часто студенты делают интересные проекты в университете или для удовольствия
Кстати, Gimp — как раз такой проект. Если сравнивать с фотошопом, очень бросается в глаза разница. Фотошоп делали, чтобы он продавался. Джимп (гимп) делали, чтобы он был удобным и максимально функциональным. Вот у меня фотошопа нет, потому что я всё рисую в Gimp'е (картинки для приложений).
Gimp конечно классная вещь, если ничего другого не иметь, но фотошоп давно ушёл далеко вперёд и по функционалу и удобству. Особенно в плане удобства open source к сожалению чаще отстаёт от коммерческого софта, хотя свои проблемы есть везде
GIMP — это вообще классический антипример.
Во-первых те два чувака, которые начали пилить его в Универе его бросили.
Во-вторых по удобству он очень сильно отстаёт от Photoshop'а. Пример, который, насколько я знаю до сих пор актуален: когда я хочу "подправить" слой, чтобы он точнее попал в другой я делаю его полупрозрачным и после этого изменяю — перспектива или сдвиг — и вот именно в этот момент в GIMP'е полупрозрачность исчезает.
И, наконец, в-третьих (тесно связанное с "во-вторых"): хотя пользователей у GIMPа довольно много пилят его до сих пор два с половиной разработчика. Ибо большинство пользователей не умеют программировать (они ж художники, а не программисты)! В результате описанная мною проблема до сих пор актуальна. Заметим что последняя (на момент появления GIMP'а) версия Photoshop'а тоже так не умела — чтобы такие трюки поддержвать требуется довольно нехилый редизайн внутренней архитектуры. Photoshop его проделал, если мне не изменяет память, в версии 6.0 (2000й год), GIMP… GIMP всё ещё "в процессе".
В мире, который воображал себе Столлман (где все или почти все пользователи компьютеров — программисты), свободное ПО, конечно, "всех поборет". Но в нашем мире подавляющий процент пользователей о программировании понятия не имеет и не собирается иметь!
Во-первых те два чувака, которые начали пилить его в Универе его бросили.
Во-вторых по удобству он очень сильно отстаёт от Photoshop'а. Пример, который, насколько я знаю до сих пор актуален: когда я хочу "подправить" слой, чтобы он точнее попал в другой я делаю его полупрозрачным и после этого изменяю — перспектива или сдвиг — и вот именно в этот момент в GIMP'е полупрозрачность исчезает.
И, наконец, в-третьих (тесно связанное с "во-вторых"): хотя пользователей у GIMPа довольно много пилят его до сих пор два с половиной разработчика. Ибо большинство пользователей не умеют программировать (они ж художники, а не программисты)! В результате описанная мною проблема до сих пор актуальна. Заметим что последняя (на момент появления GIMP'а) версия Photoshop'а тоже так не умела — чтобы такие трюки поддержвать требуется довольно нехилый редизайн внутренней архитектуры. Photoshop его проделал, если мне не изменяет память, в версии 6.0 (2000й год), GIMP… GIMP всё ещё "в процессе".
В мире, который воображал себе Столлман (где все или почти все пользователи компьютеров — программисты), свободное ПО, конечно, "всех поборет". Но в нашем мире подавляющий процент пользователей о программировании понятия не имеет и не собирается иметь!
Я во многом согласился бы с автором, точнее, мне хочется согласиться, но моё согласие будет не совсем честным и предвзятым, потому что здесь, как и в других подобных статьях, допускается та же самая неточность. Слово "программист" уже много лет назад потеряло свой первоначальный смысл. Когда я учился в школе, в младших классах, этим словом у нас называли математиков, владеющих программированием. Да, там предполагалось, что программист в первую очередь математик.
Сейчас ситуация иная. Спрашивать, должен ли программист изучать алгоритмы это всё равно что спрашивать, должен ли автолюбитель уметь управлять троллейбусом или автопоездом, когда он ездит только на своей легковушке. Общий принцип, да, он знать худо бедно должен (нужно крутить руль, есть какие-то педали), но уметь управлять — это ему не нужно. Программисты бывают разные, направлений очень много и нужно всегда конкретно уточнять, каких именно программистов мы имеем в виду. Спортивный программист обязан знать от полусотни (в моё время) до полутора сотен (сейчас) различных алгоритмов (понятно, что какие-то из них будут для одной и той же задачи), но даже ему зачастую не нужны строгие доказательства их работы. Разработчику библиотек и низкоуровневых функций вроде меня нужно обязательно знать не только весь классический репертуар алгоритмов, но и все математические основы, в них лежащие, ещё мы обязаны иногда уметь сочинять свои методы и доказательства. Программисту на html (в прошлом) или на php (сейчас) нужно великолепно знать сам язык, его возможности и особенности всех функций и библиотек для разных случаев. Это тоже немалый труд — всё это изучить и правильно использовать. Минимальная культура, которая не позволит такому программисту написать, как вы сказали, тройной цикл, конечно должна быть, я не спорю. Но знать алгоритмы длинной арифметики ему нафиг не надо. И это правильно.
Таким образом, я против подобных вопросов вообще. Не нужно спрашивать, нужны ли алгоритмы программисту. Нужно в каждом конкретном случае спрашивать конкретные задачи, связанные с теми, что ему придётся решать на работе. Великолепный программист на php, знающий при этом perl, Pуthon что-нибудь такое, но не могущий реализовать heapsort, будет гораздо востребованнее, скажем, меня, кто с "закрытыми глазами" пишет венгерский метод или декартово дерево, но совершенно не рубит, как оптимально написать что-то на PHP, чтобы сайт не тормозил. Понимаете? Каждому своё.
Есть круг задач, человек либо решает задачи из этого круга и подходит под условия работодателя и каких-то реалий, либо нет. Но проводить демаркационную линию по принципу "знает алгоритмы" / "не знает алгоритмы" — это бесполезная трата времени как с теоретической, так и с практической точки зрения. Эта линия ни о чём не говорит.
Хотя я, конечно, хотел бы, чтобы для повышения общей культуры все программисты (в том числе кодеры) знали некий минимальный набор алгоритмов, просто чтобы хотя бы понимать друг друга, работая в команде с теми, кто реализует эти самые boost, stl, gmp и т. д. Ну а алгоритмисты вроде меня должны тоже приблизительно знать методологии и инструменты IT-сферы. Скажем, простенький сайт на PHP я напишу, но если нужно будет что-то серьёзное, я всегда посоветуюсь с профессионалом. Мало ли, какие подводные камни есть. И он, профессионал, пойдёт в первую очередь ко мне, когда ему понадобится отлавливать баги в плавающей арифметики на PHP.
Сейчас ситуация иная. Спрашивать, должен ли программист изучать алгоритмы это всё равно что спрашивать, должен ли автолюбитель уметь управлять троллейбусом или автопоездом, когда он ездит только на своей легковушке. Общий принцип, да, он знать худо бедно должен (нужно крутить руль, есть какие-то педали), но уметь управлять — это ему не нужно. Программисты бывают разные, направлений очень много и нужно всегда конкретно уточнять, каких именно программистов мы имеем в виду. Спортивный программист обязан знать от полусотни (в моё время) до полутора сотен (сейчас) различных алгоритмов (понятно, что какие-то из них будут для одной и той же задачи), но даже ему зачастую не нужны строгие доказательства их работы. Разработчику библиотек и низкоуровневых функций вроде меня нужно обязательно знать не только весь классический репертуар алгоритмов, но и все математические основы, в них лежащие, ещё мы обязаны иногда уметь сочинять свои методы и доказательства. Программисту на html (в прошлом) или на php (сейчас) нужно великолепно знать сам язык, его возможности и особенности всех функций и библиотек для разных случаев. Это тоже немалый труд — всё это изучить и правильно использовать. Минимальная культура, которая не позволит такому программисту написать, как вы сказали, тройной цикл, конечно должна быть, я не спорю. Но знать алгоритмы длинной арифметики ему нафиг не надо. И это правильно.
Таким образом, я против подобных вопросов вообще. Не нужно спрашивать, нужны ли алгоритмы программисту. Нужно в каждом конкретном случае спрашивать конкретные задачи, связанные с теми, что ему придётся решать на работе. Великолепный программист на php, знающий при этом perl, Pуthon что-нибудь такое, но не могущий реализовать heapsort, будет гораздо востребованнее, скажем, меня, кто с "закрытыми глазами" пишет венгерский метод или декартово дерево, но совершенно не рубит, как оптимально написать что-то на PHP, чтобы сайт не тормозил. Понимаете? Каждому своё.
Есть круг задач, человек либо решает задачи из этого круга и подходит под условия работодателя и каких-то реалий, либо нет. Но проводить демаркационную линию по принципу "знает алгоритмы" / "не знает алгоритмы" — это бесполезная трата времени как с теоретической, так и с практической точки зрения. Эта линия ни о чём не говорит.
Хотя я, конечно, хотел бы, чтобы для повышения общей культуры все программисты (в том числе кодеры) знали некий минимальный набор алгоритмов, просто чтобы хотя бы понимать друг друга, работая в команде с теми, кто реализует эти самые boost, stl, gmp и т. д. Ну а алгоритмисты вроде меня должны тоже приблизительно знать методологии и инструменты IT-сферы. Скажем, простенький сайт на PHP я напишу, но если нужно будет что-то серьёзное, я всегда посоветуюсь с профессионалом. Мало ли, какие подводные камни есть. И он, профессионал, пойдёт в первую очередь ко мне, когда ему понадобится отлавливать баги в плавающей арифметики на PHP.
И он, профессионал, пойдёт в первую очередь ко мне, когда ему понадобится отлавливать баги в плавающей арифметики на PHP.В том-то и дело, что не пойдёт. Замена циклов на один SQL-запрос — это впечатляющий пример, но я сталкивался с ещё более впечатляющим: с заменой SQL запроса на тройной вложенный цикл — и получением при этом многократного ускорения! На PHP, да.
Не буду сейчас вдаваться в подробности, но SQL-запрос отрабатывал ~10секунд потому, что в системе была куча хитрых связей между таблицами. Я же заметил, что во всех этих таблицах суммарно лежал мегабайт данных — и просто «забрал» его себе. Тупо. Через три «select *»а. Потом просто прошёлся по таблицам в памяти и выбрал нужные мне данные. А «профессионалы», работающие на PHP и «оптимизаторы SQL» даже не задумывались над тем, что это возможно. Они «планы запросов» изучали. И понять, что там запросов просто тупо много — им оказалось не дано.
Вот именно в этом объёме и нужно знать «алгоритмы», даже если вы всю жизнь собрались провести клепая сайты на PHP. Не для того, чтобы постоянно что-то самому делать — а чтобы понимать когда это делать стоит, а когда — не стоит.
И оказывается что для этого нужно знать алгоритмы на довольно-таки приличном уровне. Даже если вы их сами никогда и не будете реализовывать.
Примеры, о которых Вы говорите — это не совсем то. Ошибка начинается не в том месте, где кодер начал пытаться придумывать алгоритм, а в том, что в проекте (в спецификации) изначально не было объяснено, что делать. Кодер — исполнитель, он должен первоклассно исполнять. А каков алгоритм — это за него должен был придумать разработчик спецификации, по которой делается проект, точнее даже не он, а математик, продумывающий глубокие схемы взаимодействия всех элементов. Если нет спецификации, то значит сам по себе проект проектируется неправильно. То есть ошибка в распределении ролей и вообще в подходе к проектированию. Алгоритмы должны придумывать и писать профессионалы в этой области. Уверен, что при таком подходе программа летала бы ещё быстрее. Короче, каждый должен заниматься своим делом. В ответственном проекте к разработке алгоритма я не допустил бы ни того кодера, который не понимает алгоритмы, ни того, который их хорошо понимает. Почему?
Потому что всё равно он их понимает хуже, чем профессионал в области разработки алгоритмов. Поэтому без разницы, знает человек алгоритмы или нет — это не критерий чего бы то ни было. Хотя мне всегда хочется, чтобы знал. Просто обычно есть корреляция между качеством кода и пониманием алгоритмов, но корреляция не означает прямую зависимость.
Потому что всё равно он их понимает хуже, чем профессионал в области разработки алгоритмов. Поэтому без разницы, знает человек алгоритмы или нет — это не критерий чего бы то ни было. Хотя мне всегда хочется, чтобы знал. Просто обычно есть корреляция между качеством кода и пониманием алгоритмов, но корреляция не означает прямую зависимость.
Ошибка начинается не в том месте, где кодер начал пытаться придумывать алгоритм, а в том, что в проекте (в спецификации) изначально не было объяснено, что делать. Кодер — исполнитель, он должен первоклассно исполнять. А каков алгоритм — это за него должен был придумать разработчик спецификации, по которой делается проект, точнее даже не он, а математик, продумывающий глубокие схемы взаимодействия всех элементов. Если нет спецификации, то значит сам по себе проект проектируется неправильно.Мне кажется вы сейчас о каком-то другом мире говорите.
Если вы о внутреннем/консультационном ПО, то да, в принципе я готов с вами согласиться. С тем только отличием, что тут вообще знание алгоритмов никому нафиг не нужно в 99% случаев — проблемы возникают только тогда, когда их незнание приводит к тому, что созданная вами система не работает вообще.
Если вы про мир ширпотреба — то я не знаю ни одной разработки, которая была бы сделана подобным способом от начала и конца — и при этом попала бы не в учебники истории, а на столы к пользователям. Просто потому что для того, чтобы «выдать кому-то» алгоритмические проблемы они должны быть известны заранее — а понять где они случатся даже в не очень большой программе на пару миллионов строк очень тяжело (а если у вас программа меньше — то где вы найдёте денег на построение всей вашей цепочки с аналитиками и кодерами?).
Тут опять таки возвращаемся к вопросу о том, какие алгоритмы. Например:
Для каждого пункта требуется какой-то алгоритм, но что касается первого — это задача явно не программиста. Второй пункт — я бы сказал, рекомендовано, но не обязательно, т.к. есть готовые функции во многих языках. Третий — само собой разумеется.
- Расчёт траектории нейтрона в хитропеременном магнитном поле
- Сортировка
- Вызов процедур в необходимом порядке
Для каждого пункта требуется какой-то алгоритм, но что касается первого — это задача явно не программиста. Второй пункт — я бы сказал, рекомендовано, но не обязательно, т.к. есть готовые функции во многих языках. Третий — само собой разумеется.
Для каждого пункта требуется какой-то алгоритм, но что касается первого — это задача явно не программиста.Какой нафиг «алгоритм расчёт траектории нейтрона»? Тут физика нужна. А вот когда у вас уже есть программа, которая что-то там как-то рассчитывает в малых масштабах — тут уже потребуются и работа программиста. Причём алгоритмы там будут самые банальные, но когда вы обрабатываете сотни петабайт, то… нет, скриптиком для PHP не обойтись.
Собственно об этом и говорил. С физикой может пример не удачный (плюс косяк с нейтроном). Хотел сказать, что есть алгоритмы, которые действительно лучше напишет профессионал в конкретной области, отличной от программирования. А есть довольно обыденные, которые как раз являются задачей программиста.
Хотел сказать, что есть алгоритмы, которые действительно лучше напишет профессионал в конкретной области, отличной от программирования.Не бывает так, извините.
Задача «профессионала в конкретной области» — описать решение задачи. Когда в виде формул, когда на словах, когда и в виде программы. По разному бывает. Но то, что он сделает будет «ужасом летящим на крыльях ночи» в 10 случаях из 10.
Дальше — вопрос простой: можно этим чудом вообще пользоваться или нет? Если оно отрабывается за 10 минут и запускается раз в сутки — то так важно ли, что после переписывания его со знанием алгоритмов и структур данных, оно станет работать полсекунды или нет?
Если «такого» больше ни у кого нет или такое больше никому не нужно — то на этом, собственно, и всё. А если у вас есть конкуренты — то придётся-таки привлекать программистов, ничего не поделать.
Но вот беда: если у вас есть конкуренты, то у вас не полутся всё сделать «правильно». Иначе выйдет у вас Windows Phone. Которая по многим показателям лучше, чем Android и iOS (есть кое-какие косяки в интерфейсе, но на уровне системы — она гораздо правильнее спроектирована и сделана), но… труп. Причём давно уже труп. Уже в 2010м она была полутрупом, а в 2012м её уже можно было хоронить без всяких обсуждений. Просто потому что не была готова. Именно потому что её делали по описанной схеме — а значит просто банально делали дольше. Да, в ней нет многих косяков (к примеру изначально у программ нет простого дуступа к системным библиотекам, что в iOS решили постылём в виде AppStore'а, а Android'е Google теперь выдавливает «по капле») — но какая, нафиг, разница есть «пациент мёртв»?
Ну, возразить мне нечего. Единственное, получается пришли к забавному выводу: программирование — это та редкая область, где конкуренция убивает продукт.
Вывод неверный. Про принцип "Le mieux est Геппепи du bien" (лучшее — врах хорошего) Вольтер ещё четыре сотни лет назад писал. И Закон Парето не вчера придумали.
Но, заметьте, там где конкуренции нет — продукт не лучше! Отнюдь! Если коммерчески успешные продукты — это всегда "ужас", то продукты, созданые в отсутсвие конкуренции — это просто "ужас-ужас-ужас". Вот именно там и тогда, когда вам качество продукта неважно вообще (главное чтобы оно оказалось достаточным для того, чтобы заказчик контракт не разорвал) — и работает подавляющее большинство программистов! Которые искренне уверены, что им знание теории алгоритмов нафиг не нужно — и правы при этом!
А конкуренция — тут важно не только сделать продукт, но и соблюсти баланс между скоростью разработки и качеством результата. Отсюда и возникает потребность в программистах-универсалах, знающих алгоритмы и умеющих кодировать.
Вариант же, когда нужно что-то сделать максимально качественно — он вообще исчезающе редок: в основном там, где что-то худшее просто не работает. Космос, к примеру иногда подобное требует. Но разрабатывать в таком режиме всё? Не получится.
Но, заметьте, там где конкуренции нет — продукт не лучше! Отнюдь! Если коммерчески успешные продукты — это всегда "ужас", то продукты, созданые в отсутсвие конкуренции — это просто "ужас-ужас-ужас". Вот именно там и тогда, когда вам качество продукта неважно вообще (главное чтобы оно оказалось достаточным для того, чтобы заказчик контракт не разорвал) — и работает подавляющее большинство программистов! Которые искренне уверены, что им знание теории алгоритмов нафиг не нужно — и правы при этом!
А конкуренция — тут важно не только сделать продукт, но и соблюсти баланс между скоростью разработки и качеством результата. Отсюда и возникает потребность в программистах-универсалах, знающих алгоритмы и умеющих кодировать.
Вариант же, когда нужно что-то сделать максимально качественно — он вообще исчезающе редок: в основном там, где что-то худшее просто не работает. Космос, к примеру иногда подобное требует. Но разрабатывать в таком режиме всё? Не получится.
Касательно конкуренции, получается идеальный вариант при умеренной конкуренции. Т.к. при сильной конкуренции опираются на время, а за короткие сроки явно ничего качественного не выйдет (описанный Вами случай в прошлом комментарии), а при слабой проявляются особенности, описанные в учебниках по экономики. Да уж, программирование своеобразная область: баланс наше всё.
Касательно качества, кроме космоса думаю ещё можно встретить в микроконтроллерах, встраиваемых системах и системах на производстве (кстати, там зачастую даже Windows и Linux не доверяют: лично видел современный ЧПУ станок на мебельной фабрике, который работает под DOS).
Касательно качества, кроме космоса думаю ещё можно встретить в микроконтроллерах, встраиваемых системах и системах на производстве (кстати, там зачастую даже Windows и Linux не доверяют: лично видел современный ЧПУ станок на мебельной фабрике, который работает под DOS).
то так важно ли, что после переписывания его со знанием алгоритмов и структур данных, оно станет работать полсекунды или нет?
И бозон Хиггса будет ловиться не 2 года, а 2000 лет? Да они сами безо всякой конкуренции захотят и с алгоритмистами, и с программистами сотрудничать в лучшем виде.
На один ЦЕРН, где ловят бозон, приходится 100500 контор, которых вполне устроит изделие, открывающее свои окошки по 5-10 минут. Можно подумать вы никогда не наблюдали как работают все эти системы. Что на приёме у врача, что в банке. Могли бы работать миллисекунды, а работают минуты — и всем пофиг: девочка-оператор быстро учится запускать программу до начала разговора с клиентом и всё. Делов-то.
Честно говоря, обхожу стороной такие программы. Я думаю и девочке-оператору не пофиг (по крайней мере, всем моим знакомым, далёким от IT, не пофиг), просто в уши надули, что это нормально, что оборудование старое. По незнанию она и поверила. Но в любом случае, тормозящая программа выводит. Поэтому до сих пор пользуюсь древними IDE. Я понимаю, что это не есть нормально, и что при трудоустройстве в какую-либо контору, придётся пересесть на что-то современное, но я очень надеюсь этим современным будет mingw, clang или что-то подобное с легковесной и шустрой IDE.
"Всем" — это всем тем, кто заведует распределением денежных потоков в данном случае.
Оттого, что "девушка оператор" ждёт и нервничает затрат особо больше не становится: она могла бы выполнять свою задачу за минуту вместо пяти, но если замедление работы не настолько значительно, чтобы создавать очереди, то экономии от более грамотно написанной программы не будет.
А вот затраты на то, чтобы взять более качественного программиста и дать ему больше времени — вот они, легко считаются.
И с тормозящими IDE то же самое: я предпочитаю работать в мнее мощных, но более быстрых IDE, но я прекрасно понимаю почему современные монстры так популярны: они, опять-таки, позволяют взять более дешёвых программистов, а стало быть — приводят к прямой экономии.
Увы, но это не только ПО касается.
Оттого, что "девушка оператор" ждёт и нервничает затрат особо больше не становится: она могла бы выполнять свою задачу за минуту вместо пяти, но если замедление работы не настолько значительно, чтобы создавать очереди, то экономии от более грамотно написанной программы не будет.
А вот затраты на то, чтобы взять более качественного программиста и дать ему больше времени — вот они, легко считаются.
И с тормозящими IDE то же самое: я предпочитаю работать в мнее мощных, но более быстрых IDE, но я прекрасно понимаю почему современные монстры так популярны: они, опять-таки, позволяют взять более дешёвых программистов, а стало быть — приводят к прямой экономии.
Увы, но это не только ПО касается.
Всё же, например, сравнивая отделение Сбербанка и отделение Почты России, прихожу к выводу, что более солидные компании заказывают/покупают более солидное ПО и технику (в т.ч. менее тормозящее).
Мощь и скорость могут и сочетаться — такое бывает, хотя и редко. :-)
И еще: иногда мощная IDE экономит до 80% времени разработки — и тут уже быстрота IDE становится не самым важным фактором, т.к. инструменты более мощной IDE гарантируют (до некоторой степени) корректность многих операций — а это многого стоит.
Сначала физика. Потом анализ задачи численными методами. Потом возвращаемся к физику, выясняем возможные инварианты, гладкость поля в пространстве и времени… Потом выбираем несколько численных моделей. Идём к программисту, спрашиваем, что он про них думает — в смысле эффективности, памяти, реализуемости вообще. Возможно, потребуется несколько итераций. После чего программист, зная повадки машины, превращает алгоритм в программу, и наконец, вычисляет эту траекторию.
А потом система ушла в продакшн, данных стало не мегабайт а под сотню, и вдруг сетка чего-то стала загружена, и вдруг памяти стало не хватать. И приходит другой программист, смотрит на ваше решение и вы икаете.
Я не верю что три таблицы суммарно мегабайт весом нельзя взять запросом, да еще и чтобы построить какой-то график. Как бы там запросы тоже по собой имеют по сути все те же алгоритмы.
Я не верю что три таблицы суммарно мегабайт весом нельзя взять запросом, да еще и чтобы построить какой-то график. Как бы там запросы тоже по собой имеют по сути все те же алгоритмы.
Я не верю что три таблицы суммарно мегабайт весом нельзя взять запросом, да еще и чтобы построить какой-то график.Это была сложная иерархическая система, описывающая хранение книг в разных подразделениях. С кучей дополнительной информации. А реализована она была в виде списка (то ещё решение, конечно — но уж как было, так было): в записи про книгу была ссылка на ID следующей за ней книги.
А потом система ушла в продакшн, данных стало не мегабайт а под сотню, и вдруг сетка чего-то стала загружена, и вдруг памяти стало не хватать.А вот тут — уже нужно знание предметной области. Да, можно себе представить что вместо 10'000 позиций на складе появится 100'000. Легко. А вот больше — маловероятно. Куда они их складывать-то будут?
P.S. Только не надо рассказывать про то, что данные о книгах так в базах данных не хранят. Я знаю. А вот те, кто создали эту базу, похоже, не догадавались. На 100 книгах на тестах оно отлично работало.
По-моему вы как-то пропустили суть статьи.
Вообще-то раньше программирования как дисциплины не существало, а писали код не только математики, но и инженеры. Слово программист означает тех, кто зарабатывает на жизнь написанием программ. Другого обозначения этой категории людей как-бы и нет.
Вообще-то раньше программирования как дисциплины не существало, а писали код не только математики, но и инженеры. Слово программист означает тех, кто зарабатывает на жизнь написанием программ. Другого обозначения этой категории людей как-бы и нет.
Вы уже несколько раз отвечаете на комментарии в духе "вы не поняли/не читали статью".
Корень разногласия, на мой взгляд, в вашей фразе
Может быть вы лично так и понимаете эту фразу. Большинство же понимает, что вопрос важен лишь как "надо ли спрашивать на собеседовании про алгоритмы" и отвечают вам про "(наизусть) знать не надо, надо будет — погуглю".
Корень разногласия, на мой взгляд, в вашей фразе
«нужны ли программисту алгоритмы» можно перевести как «нужно ли программисту уметь писать код»
Может быть вы лично так и понимаете эту фразу. Большинство же понимает, что вопрос важен лишь как "надо ли спрашивать на собеседовании про алгоритмы" и отвечают вам про "(наизусть) знать не надо, надо будет — погуглю".
Я очень хорошо понял суть этой статьи и ещё десятка подобных ей. И мой общий вывод — демаркация по признаку знания алгоритмов не имеет смысла.
Не важно, существовала раньше дисциплина или нет, это формальность, важно знать, кто назывался программистом раньше и кто называется этим словом сейчас. И станет понятным корень вопроса этой статьи и правильный ответ на него. Правильный ответ такой: постановка вопроса не верна в корне. Максимум, что можно сказать: любой уважающий себя программист должен максимально повышать свою культуру настолько, чтобы успешно и качественно решать свои задачи, задачи из его области и желательно из непосредственно смежных с ней.
Мне встречались люди, которые не знали алгоритмов, но они могли их изобретать. Как-то раз один из них заново изобрёл венгерский метод, не зная о нём раньше. Затем, естественно, он всё-таки научился читать учебники, но его исходное состояние не знающего алгоритмы человека не делало его непригодным к работе. А встречались люди, напичканные алгоритмами (спортивные программисты), которые не могли решить практически полезную задачу лучше, чем вот этот изобретатель велосипедов. Всё относительно, нужно делать упор на другие качества программиста, хотя, повторюсь, между знанием алгоритмов и другими хорошими качествами есть корреляция.
Не важно, существовала раньше дисциплина или нет, это формальность, важно знать, кто назывался программистом раньше и кто называется этим словом сейчас. И станет понятным корень вопроса этой статьи и правильный ответ на него. Правильный ответ такой: постановка вопроса не верна в корне. Максимум, что можно сказать: любой уважающий себя программист должен максимально повышать свою культуру настолько, чтобы успешно и качественно решать свои задачи, задачи из его области и желательно из непосредственно смежных с ней.
Мне встречались люди, которые не знали алгоритмов, но они могли их изобретать. Как-то раз один из них заново изобрёл венгерский метод, не зная о нём раньше. Затем, естественно, он всё-таки научился читать учебники, но его исходное состояние не знающего алгоритмы человека не делало его непригодным к работе. А встречались люди, напичканные алгоритмами (спортивные программисты), которые не могли решить практически полезную задачу лучше, чем вот этот изобретатель велосипедов. Всё относительно, нужно делать упор на другие качества программиста, хотя, повторюсь, между знанием алгоритмов и другими хорошими качествами есть корреляция.
Я не считаю что "кто назывался программистом ранее, а кто — сейчас" вообще уместно спрашивать. Мы живём сейчас, и надо адресовывать то, что люди понимают сейчас под этим словам.
Умение думать и решать проблемы — основной навык программиста, и алгоритмы как раз учат правильно подходить к решению проблем. А знание известных алгоритмов помогает умным людям не придумывать заного венгерские методы, а на их основе строить более сложные и продвинутые решения :)
Умение думать и решать проблемы — основной навык программиста, и алгоритмы как раз учат правильно подходить к решению проблем. А знание известных алгоритмов помогает умным людям не придумывать заного венгерские методы, а на их основе строить более сложные и продвинутые решения :)
Примеры отдельных "уникумов" могут говорить о многом, да. И есть есть — как таких, которые делают гениальные вещи не зная алгоритмов (а изобретая их "на лету"), так и наоборот — знающих алгоритмы, но неспособных написать реальный код.
Но общая статистика проста и незатейлива: люди, имеющием понятие о теории алгоритмов в среднем порождают заметно более качественный код, но дело даже не в этом. Главное: они гораздо реже пишут код, который ставит всю систему "раком" при изменении исходных условий.
Ну а дальше — всё просто: если минута простоя у вас стоит как зарплата прораммиста за год — вам нужны только люди со знанием алгоритмов, если неделю простоя ваша компания может прожить "с бумажкой и ручкой" — то вложения в подобного рода программистов не окупятся...
Но общая статистика проста и незатейлива: люди, имеющием понятие о теории алгоритмов в среднем порождают заметно более качественный код, но дело даже не в этом. Главное: они гораздо реже пишут код, который ставит всю систему "раком" при изменении исходных условий.
Ну а дальше — всё просто: если минута простоя у вас стоит как зарплата прораммиста за год — вам нужны только люди со знанием алгоритмов, если неделю простоя ваша компания может прожить "с бумажкой и ручкой" — то вложения в подобного рода программистов не окупятся...
Да, всё верно. Я в целом о том же и говорю. Более того, человек, который умеет изобретать велосипед и часто делает это из-за незнания классической литературы, быстрее переучивается в специалиста высокого класса, нежели напичканный алгоритмами олимпиадник. По крайней мере, в моём опыте такова "незатейливая" статистика. Вот только специалисты такого уровня не шибко-то востребованы. Обычный тяп-ляп-кодер зачатую гораздо быстрее найдёт себе работу. Причины мне неизвестны, но подозреваю, что специалист высокого уровня будет пытаться искать работу себе по уровню и требовать для себя больше благ. Наверно поэтому. Про себя говорить не буду, моя история очень своеобразна.
оптимально написать что-то на PHP, чтобы сайт не тормози
А это вообще реально?
чтобы писать простенькие сайты и скрипты, не нужно особого знания алгоритмов и структур данных
А если не простенькие сайты и скрипты? Учетные системы какие-нибудь? Или загрузчик ОС? Или драйвер для FAT или NTFS для этого загрузчика?
Итак, вы абстрактный программист в вакууме, только вам мучительно больно за бесцельно потраченное время в классе по теории вычислений и алгоритмическому анализу, который вам ничего не дал.
Вот давайте не передергивать, уж от программиста-коллеги я бы такого не ожидал. Меня вот не учили алгоритмическому анализу, и до недавнего времени я был не в курсе, что такое O-нотация. Да, вот так, представляете? Такой вот у нас был университет. Да, мы делали реализации списков и деревьев. И я даже сам потом их делал для лабораторных, потому что меня немного пугали километровые объявления шаблонов из STL.
включая язык, на котором вы пишите.
Это вообще прекрасно, я даже не буду это комментировать)
(и это не опечатка, так как 2 раза встречается в тексте статьи)
и не бежали в гугл каждый раз, когда нужно сделать что-то нетривиальное.
Так о том и речь, что нетривиальное в большинстве случаев не требуется.
Какую бы задачу вы не решали – будь то простой сайт с выборкой данных из БД, или баш скрипт на сервере, вы будете использовать какие-то структуры данных.
При этом мне не надо знать, как они работают. Мне надо уметь ими пользоваться.
Почему в C# нежелательно использовать ArrayList, а вместо него использовать List?
Вот если я буду использовать List или ArrayList, и у меня вдруг все будет тормозить, я возьму и поищу информацию об этом. А в задачи, где это надо на этапе проектирования, я не лезу. Да и новичков в компании к таким задачам обычно не подпускают.
В-третьих – есть множество задач, которые нельзя решить простым вызовом API библиотеки или фреймворка. Что вы будете делать в таком случае?
Я, представьте себе, поищу информацию о том, как такие задачи решаются. А если в описании мне будет что-то непонятно, я поищу информацию и об этом.
Если же ваша работа заключается в написание SQL запроса и вбивание команды в консоль, то хочу вас огорчить: вы не программист
Позволю себе дать ссылку на свой же коммент: https://habrahabr.ru/post/279093/#comment_8803823
Вы считаете, что описанные там задачи не требуют навыков программирования?
Когда человек начинает придираться к опечаткам, это значит что у него нет аргументов для возражения :)
Взять из пары десятков строк комментария одну, где речь идет об описке, заострить внимание на ней и отбросить остальное — вот где настоящее мастерство.
На все остальные вопросы ответы в статье
Да да, именно поэтому человек написал комментарий-возражение к статье.
С удовольствием бы ответил на конструктивную критику, если бы не было продемонстрировано полное непонимание сказанного и вырывание фраз из контекста.
Как раз ваш подход не особо конструктивен: "все есть в статье, кто не понял, тот дурак. А все возражения — тоже дурацкие, появились от непонимания статьи".
Некоторые аргументы michael_vostrikov действительно странные, но вовсе не потому, что "ответы уже есть в статье".
Взять например
или
Здесь налицо эффект Даннинга-Крюгера/blub paradox, но этого в статье нет.
Некоторые аргументы michael_vostrikov действительно странные, но вовсе не потому, что "ответы уже есть в статье".
Взять например
Так о том и речь, что нетривиальное в большинстве случаев не требуется.
или
Вот если я буду использовать List или ArrayList, и у меня вдруг все будет тормозить, я возьму и поищу информацию об этом. А в задачи, где это надо на этапе проектирования, я не лезу. Да и новичков в компании к таким задачам обычно не подпускают.
Здесь налицо эффект Даннинга-Крюгера/blub paradox, но этого в статье нет.
Вся статья как раз о том, зачем нужно знать алгоритмы тем, кому нетривиальное не требуется. Если вам нужно задать этот вопрос, вы меня не поняли :( Вот мой комментарий ниже https://habrahabr.ru/post/279453/#comment_8808393 где я написал краткую суть
На второй вопрос я не ответил потому что не хотел писать то, что написали вы :) Прямого ответа может и нет, но косвенно вопрос о ценности такого специалиста я тоже задел
На второй вопрос я не ответил потому что не хотел писать то, что написали вы :) Прямого ответа может и нет, но косвенно вопрос о ценности такого специалиста я тоже задел
Согласен, кое-где я преувеличил.
Для начала надо определиться с терминологией. Под знанием алгоритмов я понимаю знание алгоритмов обработки стандартных структур данных и умение оценивать их сложность в O-нотации — обходы графов, сложность различных сортировок и т.д. Примерно такой же смысл вкладывается авторами статей на эту тему. Насколько я понял, вы в своей статье называете это "детали теории вычислений".
Я говорю о том, что доказательства, приведенные в статье, ничего не доказывают — неправильно объясняют причины и не доказывают необходимость знания алгоритмов для выполнения любых задач.
Вырвал из контекста я те фразы, на основе которых в статье идет дальнейшее доказательство.
У вас эта мысль высказывается несколько раз. Я допускаю, что кто-то может быть обижен, но чтобы все "абстрактные программисты"? Поэтому и назвал передергиванием.
С первым предложением согласен, но не понимаю здесь логическую цепочку. "Анализировать и решать проблемы" это практический навык, причем в работе тесно связанный с написанием хорошего кода. А проблемы и методы их решения бывают разные, связанные с теорией алгоритмов и не связанные. Например, правильное применение ООП и паттернов проектирования.
Я наверно неправильно сформулировал ответ по этому пункту. Есть выбор — тратить часы сейчас, читая о любых алгоритмах и решениях, которые попадутся под руку, или тратить часы по мере возникновения задач, читая о решениях, которые требуются именно для этой задачи. Мне кажется, в большинстве случаев правильнее второй вариант, так как и времени уйдет меньше, и можно проверить решение на практике.
Здесь надо уметь представлять задачу и возможные пути решения, знание алгоритмов здесь не нужно. Что вы и сами подтверждаете, упоминая интерна-третьекурсника с аналитическим мозгом.
У меня похожий случай был. И я тоже сделал рефакторинг, хоть и не специалист в алгоритмах. А уж про оценку сложности я тогда и не слышал. Зачем здесь знание алгоритмов?
В свою очередь я вам привел другие примеры с таким же вопросом, ответить на которые вы не захотели.
Понимание принципов работы и знание алгоритмов это не одно и то же.
Собственно, зачем я это все пишу. Я хочу сказать, что факт незнания программистом алгоритмов означает только то, что он не знает алгоритмы. Он ничего не говорит ни о знаниях и навыках в другой области, ни о сложности решаемых задач, ни даже об умении разобраться в алгоритмах в дальнейшем.
Вся статья как раз о том, зачем нужно знать алгоритмы тем, кому нетривиальное не требуется.
Я говорю о том, что доказательства, приведенные в статье, ничего не доказывают — неправильно объясняют причины и не доказывают необходимость знания алгоритмов для выполнения любых задач.
Вырвал из контекста я те фразы, на основе которых в статье идет дальнейшее доказательство.
бесцельно потраченное время в классе по теории вычислений и алгоритмическому анализу
У вас эта мысль высказывается несколько раз. Я допускаю, что кто-то может быть обижен, но чтобы все "абстрактные программисты"? Поэтому и назвал передергиванием.
Программист в первую очередь должен уметь анализировать и решать проблемы – это основной навык, которым должны обзавестись выпускники факультетов информатики. Написание кода – это просто необходимый инструмент, который используется для решения задач. Таким образом учить теорию – это наиболее оптимально с точки зрения образования.
С первым предложением согласен, но не понимаю здесь логическую цепочку. "Анализировать и решать проблемы" это практический навык, причем в работе тесно связанный с написанием хорошего кода. А проблемы и методы их решения бывают разные, связанные с теорией алгоритмов и не связанные. Например, правильное применение ООП и паттернов проектирования.
В-третьих – есть множество задач, которые нельзя решить простым вызовом API библиотеки или фреймворка. Что вы будете делать в таком случае? Тратить часы на поиски возможных решений и просить помощи у друга?
Я наверно неправильно сформулировал ответ по этому пункту. Есть выбор — тратить часы сейчас, читая о любых алгоритмах и решениях, которые попадутся под руку, или тратить часы по мере возникновения задач, читая о решениях, которые требуются именно для этой задачи. Мне кажется, в большинстве случаев правильнее второй вариант, так как и времени уйдет меньше, и можно проверить решение на практике.
примитивный text-wrap в одном из визуальных компонентов
Здесь надо уметь представлять задачу и возможные пути решения, знание алгоритмов здесь не нужно. Что вы и сами подтверждаете, упоминая интерна-третьекурсника с аналитическим мозгом.
Оказалось, что человек, который изначально делал этот проект, нагородил кучу ужасных конструкций из тройных вложенных циклов, которые долго и печально забирали данные из БД, и потом привязывали их к графикам. После небольшого рефакторинга страница стала грузится почти мгновенно.
У меня похожий случай был. И я тоже сделал рефакторинг, хоть и не специалист в алгоритмах. А уж про оценку сложности я тогда и не слышал. Зачем здесь знание алгоритмов?
В свою очередь я вам привел другие примеры с таким же вопросом, ответить на которые вы не захотели.
понимание того, что происходит внутрях полезно знать всем
Понимание принципов работы и знание алгоритмов это не одно и то же.
Собственно, зачем я это все пишу. Я хочу сказать, что факт незнания программистом алгоритмов означает только то, что он не знает алгоритмы. Он ничего не говорит ни о знаниях и навыках в другой области, ни о сложности решаемых задач, ни даже об умении разобраться в алгоритмах в дальнейшем.
Для начала надо определиться с терминологией. Под знанием алгоритмов я понимаю знание алгоритмов обработки стандартных структур данных и умение оценивать их сложность в O-нотации — обходы графов, сложность различных сортировок и т.д.
Я привёл три определения алгоритма, два из которых — формальные :) Но статья больше о понимании алгоритмов и их анализа
Я говорю о том, что доказательства, приведенные в статье, ничего не доказывают — неправильно объясняют причины и не доказывают необходимость знания алгоритмов для выполнения любых задач.
Вырвал из контекста я те фразы, на основе которых в статье идет дальнейшее доказательство.
Можно ли этот вопрос вообще доказать или опровергнуть? Я вообще не утверждал что незнание алгоритмов не даст найти работу. Очень много людей не имеют понятия о них, и при этом работают как-то. Только качество такой работы — отвратительное как правило...
С первым предложением согласен, но не понимаю здесь логическую цепочку. «Анализировать и решать проблемы» это практический навык, причем в работе тесно связанный с написанием хорошего кода. А проблемы и методы их решения бывают разные, связанные с теорией алгоритмов и не связанные. Например, правильное применение ООП и паттернов проектирования.
Изучение алгоритмов как раз и даёт навык "анализировать и решать проблемы" :) Как лучше всего выделять память для динамического массива, чтобы эффективно её использовать? Вполне себе алгоритмический вопрос.
А так называемые паттерны ООП появились в результате того, что много умных людей применяли схожие алгоритмические решения, и их потом вывели в паттерны :) Да я и не утверждал нигде что кроме алгоритмов — ничего не нужно
Я наверно неправильно сформулировал ответ по этому пункту. Есть выбор — тратить часы сейчас, читая о любых алгоритмах и решениях, которые попадутся под руку, или тратить часы по мере возникновения задач, читая о решениях, которые требуются именно для этой задачи. Мне кажется, в большинстве случаев правильнее второй вариант, так как и времени уйдет меньше, и можно проверить решение на практике.
Вы прям из крайности в крайность бросаетесь. Я же не призывал никого всё бросить и бежать изучать все возможные алгоритмы :) Когда вы столкнётесь с проблемой, и не имеете определённых знаний, то вы вероятно даже не будете знать что гуглить, чтобы решить пролему. Работал с такими с людьми: из-за них проект тормозит потому что они непрерывно гуглят всё подряд, доверие к ним падает постоянно и на работе они не задерживаются как правило. Иметь пробелы в знаниях — нормально, если они в деталях и их можно восполнить за несколько минут. А если пробелы требуют семестра в универе или прочтения нескольких книг, то это просто некомпетентность.
Здесь надо уметь представлять задачу и возможные пути решения, знание алгоритмов здесь не нужно. Что вы и сами подтверждаете, упоминая интерна-третьекурсника с аналитическим мозгом.
Это пример, когда человек имея пробел в знаниях умеет решать проблемы. Изобрёл алгоритм переноса строки на месте за пару часов. А если бы его знал — потратил бы пол часа.
У меня похожий случай был. И я тоже сделал рефакторинг, хоть и не специалист в алгоритмах. А уж про оценку сложности я тогда и не слышал. Зачем здесь знание алгоритмов?
Я думаю что человек, который написал этот код тоже думал "зачем ему знать алгоритмы" :) Вы опять спрашиваете вопрос, о котором написана вся статья :)
Понимание принципов работы и знание алгоритмов это не одно и то же.
Принцип работы — само по себе является алгоритмом :)
Собственно, зачем я это все пишу. Я хочу сказать, что факт незнания программистом алгоритмов означает только то, что он не знает алгоритмы. Он ничего не говорит ни о знаниях и навыках в другой области, ни о сложности решаемых задач, ни даже об умении разобраться в алгоритмах в дальнейшем.
Опять таки вы меня не поняли. Простое знание о существовании алгоритмов конечно не даёт никакой пользы. А вот понимание подхода к решению задач — совсем другое дело. Изучение алгоритмов в первую очеред даёт навыки для решения проблем. Именно поэтому идёт акцент на "разделяй и властвуй", "жадные алгоритмы" и т.п. Не нужно знать как написать алгоритм дайкстры чтобы понимать принцип жадных алгоритмов, не нужно знать как реализовать merge sort чтобы понимать "разделяй и властвуй", но понимание этих концептов позволяет писать эффективные решения и узнавать схожие проблемы, где решение от одной проблемы, можно применить к другой.
Касательно университета, мы даже в рамках лабораторных деревья и списки не реализовывали. Нас с ними только познакомили, а реализацию оставили по желанию. ТАУ и операционные системы пробежали галопом по Европе (что касается ТАУ, даже не совсем понял, о чём предмет). Зато есть экология, метрология, природопользование и теоретическая физкультура.
Странно.
Нам давали как метрологию, экологию (например, мы, программисты, расчитывали фабричную трубу для определенной розы ветров и типа выбросов, безопасную зону расположение домов и пр), так и профильные предметы. И АВЛ реализовывали, ЕМНИП, на 2м курсе. Списки так вообще в первом или втором семестре.
Нам давали как метрологию, экологию (например, мы, программисты, расчитывали фабричную трубу для определенной розы ветров и типа выбросов, безопасную зону расположение домов и пр), так и профильные предметы. И АВЛ реализовывали, ЕМНИП, на 2м курсе. Списки так вообще в первом или втором семестре.
Списки тоже давали на 2 семестре, но лаб по ним не было. Сказали, что по желанию можно в курсаче использовать. Мне было интересно поработать с памятью, я использовал. М.б. кто-то ещё использовал, но большинство послали это куда подальше. В третьем семестре не помню, возвращались к ним или нет, но многие из группы до сих пор (3 курс) обходит их стороной. Про деревья я вообще молчу: АВЛ и ЕМНИП — эти понятия я узнал только что от Вас (стоит отметить, ЕМНИП с ходу нагуглить не смог). Бинарных деревьев где-то как-то касался, но явно не в рамках универа. Каких-то расчётов по экологии вообще не было. Вынесли мозги организациями ко контролю за окружающей средой и школьной программой по географии и экологии, приняли зачёт и на этом экология закончилась. В конечном итоге, делаю вывод, что при специалитете было дольше, но качественнее.
Кстати, ещё один примечательный момент: нам говорили (на информационных системах правда), что шифр Виженера криптостойкий)
Кстати, ещё один примечательный момент: нам говорили (на информационных системах правда), что шифр Виженера криптостойкий)
«алгоритм как строго определённую процедуру» дальше не стал читать
Если посмотреть на все эти статьи, то можно заметить, что люди, которые их пишут, фактически обижены на университеты за то, что их заставили учить много сложного материала — в виде алгоритмического анализа, сложных алгоритмов и структур данных — который им вроде бы не пригодился. По сути, авторы статей обижены на университеты из-за того, что там не смогли предсказать будущую область работы авторов и дать им только минимально нужный набор навыков. Ведь действительно, чтобы писать простенькие сайты и скрипты, не нужно особого знания алгоритмов и структур данных. Или всё-таки нужно?
боюсь обижены они на то, что мозгов не хватило освоить все это; соответственно они это и не используют; sad but true
У меня немного иная статья О высшем образовании.
вот и продолжайте писать на мегамозг, сюда с таким не стоит соваться
Хорошая статья, и не важно, что она на соседнем ресурсе.
очевидно, что высшее образование необходимо, если ты не низкоквалифицированный персонал, а тот, кто называет себя программистом, тут нечего спорить и писать статьи; кто не согласен, тот просто ошибся профессией (да да бывают исключения, везде, но вероятность что ты /вы/ктотоеще бил гейтс ничтожна, это на столько очевидно, что тоже не стоит писать об этом, ну только если на ресурсе типа мм или гт)
Я так понимаю, что определять, кто ошибся профессией, а кто нет — будете именно вы?
Нет, почему же. Работодатель. Тут есть много рассуждений на тему, что "есть 100500 контор, готовых платить многозначную сумму в евро за общую адекватность, интуицию, широкий кругозор и способность делать поддерживаемый продукт на банальном пэхэпэ или руби" и которые при этом не требуют знания алгоритмов — но я как-то с такими не сталкивался. Если под "многозначной суммой в евро" понимается не годовая зарплата в 10000€, а хотя бы что-нибудь позволяющее претендовать на голубую карту, конечно.
У меня примерно такое же мнение. Даже если сам того не замечаешь, на подобные задачи наталкиваешься постоянно. А замечать начинаешь, когда другой, менее подготовленный разработчик пишет квадратичный алгоритм там, где легко пишется линейный, а потом тебе дают оптимизировать это.
Да и сам, бывало, "попадался", чего уж греха таить. Понимал, что что-то пошло не так только на реальных данных, где не 5-10 сущностей, а пару сотен.
Но я все же предпочитаю сначала в гугл, чтобы найти там, например из последнего пригодившегося, алгоритм Tarjan-а. И только потом, если готового нет, то пытаюсь придумать алгоритм самостоятельно.
Да и сам, бывало, "попадался", чего уж греха таить. Понимал, что что-то пошло не так только на реальных данных, где не 5-10 сущностей, а пару сотен.
Но я все же предпочитаю сначала в гугл, чтобы найти там, например из последнего пригодившегося, алгоритм Tarjan-а. И только потом, если готового нет, то пытаюсь придумать алгоритм самостоятельно.
Знать и понимать — не одно и то же. Алгоритмы важно — ПОНИМАТЬ, а заучивание наизусть без понимания — малополезно. Это как в советской школе — учили наизусть стихи на английском, но мало кто после этого заговорил по-английски.
Я уже приводил в предыдущей теме сравнение алгоритмов с типовыми велосипедами. Хорошему инженеру не обязательно помнить наизусть все конструкции типовых велосипедов, но он должен ПОНИМАТЬ как и почему работает типовой велосипед. Точно так же, программист не обязан помнить все типовые алгоритмы, но он должен быть в состоянии ПОНЯТЬ и разобраться в любом типовом велосипеде. Если он даже типовой «велосипед» не понимает и не может в нём разобраться, то — плохи его дела.
Я уже приводил в предыдущей теме сравнение алгоритмов с типовыми велосипедами. Хорошему инженеру не обязательно помнить наизусть все конструкции типовых велосипедов, но он должен ПОНИМАТЬ как и почему работает типовой велосипед. Точно так же, программист не обязан помнить все типовые алгоритмы, но он должен быть в состоянии ПОНЯТЬ и разобраться в любом типовом велосипеде. Если он даже типовой «велосипед» не понимает и не может в нём разобраться, то — плохи его дела.
Из статьи в статью пишется и переписывается одна и та же мысль:
Хорошо, когда ты и чтец, и жрец, и на дуде дудец. В реальном мире — увы. Если ты крутой прогер, который и на ассемблере, и на руби, и во все новые фреймворки умеешь — ты выходишь на улицу раз в две недели — хлеба купить. А если еще и в реальном мире живешь — значит, спишь раз в полгода. Прямо сап-теорема какая-то.
Когда алгоритмист-олимпиадник, умеющий написать семь видов сортировки, но не умеющий писать простой понятный код, который потом другим поддерживать надо, начинает прикладному фронтендщику засирать мозг — аж бесит. Наоборот — тоже бесит.
Что программисту действительно надо — составлять индексы и уметь гуглить. Я без понятия, как писать сортировку пузырьком, никогда это не надо было делать. Но я знаю, что такая штука существует. Понадобится — залезу в википедию и уже через час смогу написать сам. Внешняя память — великое изобретение человечества, нужно лишь индекс время от времени актуализировать.
«Любой человек должен уметь менять пеленки, планировать вторжения, резать свиней, конструировать здания, управлять кораблями, писать сонеты, вести бухгалтерию, возводить стены, вправлять кости, облегчать смерть, исполнять приказы, отдавать приказы, сотрудничать, действовать самостоятельно, решать уравнения, анализировать новые проблемы, бросать навоз, программировать компьютеры, вкусно готовить, хорошо сражаться, достойно умирать. Специализация — удел насекомых».Не надоело еще?
Хорошо, когда ты и чтец, и жрец, и на дуде дудец. В реальном мире — увы. Если ты крутой прогер, который и на ассемблере, и на руби, и во все новые фреймворки умеешь — ты выходишь на улицу раз в две недели — хлеба купить. А если еще и в реальном мире живешь — значит, спишь раз в полгода. Прямо сап-теорема какая-то.
Когда алгоритмист-олимпиадник, умеющий написать семь видов сортировки, но не умеющий писать простой понятный код, который потом другим поддерживать надо, начинает прикладному фронтендщику засирать мозг — аж бесит. Наоборот — тоже бесит.
Что программисту действительно надо — составлять индексы и уметь гуглить. Я без понятия, как писать сортировку пузырьком, никогда это не надо было делать. Но я знаю, что такая штука существует. Понадобится — залезу в википедию и уже через час смогу написать сам. Внешняя память — великое изобретение человечества, нужно лишь индекс время от времени актуализировать.
Простите, а вы вообще читали статью или её не поняли?
По-диагонали. Это уже третья статья на подобную тему за эти дни на хабре. Если что-то не так, не стесняйтесь, ткните носом.
Да просто я ничего подобного не утвеждал. Суть статьи в том, что понимание того, что происходит внутрях полезно знать всем, в независимости от того, реализуешь все эти алгоритмы на практики или нет. Просто используя язык, вы уже сталкиваетесь с выбором какой алгоритм использовать и какую структуру данных выбрать для хранения. Понимание последствий такого выбора важно для того, как будет работать программа
Простите, а вы когда видели разделение алгоритмов и структур данных?
Вы хотите обсудить рекурсию в машинах Тьюринга и отличие нетипизированных и типизированных лямбда-исчсилений, а также какую роль играет Y-комбинатор в проблеме остановки? А затем мы может дойдём до того факта, что логические формулы могут быть эквивалентны типам данных :)
А особо супермегаодарённым рекомендуется прочитать свой собственный комментарий: асимптотический анализ сложности алгоритмов, классификация алгоритмов в соответствии с классами сложности, разработка критериев сравнительной оценки качества алгоритмов...
Но, в любом случае, конкретными алгоритмами, которые используют в программировании (даже очень сложными) теория алгоритмов не занимается.Вот прямо даже так? Вы вообще список литературы из той статьи, откуда это определения стащили видели? «Дональд Кнут. Искусство программирования.» — не припомнаете, нет? Никакой конкретики? Вот прямо совсем? MIX, MMIX и всё такое?
Если уж автор делает наброс на вентилятор, то сначала нужно научиться правильно термины употреблять.С больной головы…
P.S. Да, есть в теории алгоритмов вещи, которые в практической деятельности не очень нужны. Но какая-нибудь проблема остановки — вещь черезвычайно практическая: если вы выясняете что какой-то компонент, который, чёрт побери, всё никак не удаётся отладить, на самом деле пытается решить подобную задачу, то вы можете со спокойной душой идти к заказчику и обсуждать изменения условий: в таком варианте — оно не полетит. Никогда. А уж вещи, о которых Кнут (один из классиков теории алгоритмов, в общем-то) пишет — более чем практичны (хотя вот прямо самого Кнута я бы читать не советовал — слишком он глубоко копает). Даже не смотря на то, что пресловутые «ленты» сейчас в датацентрах разве что для резервного копирования используют.
Чтоб быть ремесленником достаточно базовых знаний и фрагментированной картины мира, все остальное будет постигаться в процессе путем проб о ошибок (правда решения будут находится уровня "вот здесь проволочкой изолентой и будет на века"), таких "инженеров" видел немало, не могу ничего сказать про них плохое, обычно это очень умные и быстро обучаемые люди, но с фатальными пробелами в знаниях которые являются основой нашей профессии.
Если человек готовы выходить за рамки своей зоны комфорта и лезть все глубже и глубже вплоть до железа и законов физики в целом а так же термодинамики в частности то без знаний алгоритмов, без знаний структур данных, без понимания базовых принципов работы современной вычислительной техники не обойтись абсолютно.
Если человек хочет создать что-то новое нужно сначала понять старое, пропустить через себя, проанализировать и внести свой фундаментальный вклад.
Если резюмировать
Если человек готовы выходить за рамки своей зоны комфорта и лезть все глубже и глубже вплоть до железа и законов физики в целом а так же термодинамики в частности то без знаний алгоритмов, без знаний структур данных, без понимания базовых принципов работы современной вычислительной техники не обойтись абсолютно.
Если человек хочет создать что-то новое нужно сначала понять старое, пропустить через себя, проанализировать и внести свой фундаментальный вклад.
Если резюмировать
- набор базовых знаний плюс ситуативное обучение для достижения результата = ремесленник с ограниченным спектром возможностей.
- понимание основ, перво причин, знание истории своей отрасли и смежных дисциплин = профессионал способный на многое.
Есть много умных людей, которые не получали формального образования в информатике, но научились многому. Проблема в том, что теория вычислений не самая простая наука, и изучить её самому как следует может быть проблематично даже умному человеку
Да, они научились многому, но когда возникает проблема входящая в их слепое пятно (коих множество ибо они учились адресно исходя из текущих проблем) они даже не догадываются о возможных путях и решениях, т.е. они не понимают и не осознают глубину провала в знаниях.
А так как люди не глупые и уже многое преодолели верят в себя и основываясь на слепой вере применяют старую "изоленту и проволоку", когда нужно читать теорию графов и дискретную математику.
А так как люди не глупые и уже многое преодолели верят в себя и основываясь на слепой вере применяют старую "изоленту и проволоку", когда нужно читать теорию графов и дискретную математику.
Нужно ли знать алгоритмы?
Ха три раза. Лично знал программиста, который не знал, что есть переменные. И писал программы, храня данные в полях скрытых компонентов окна.
Ха три раза. Лично знал программиста, который не знал, что есть переменные. И писал программы, храня данные в полях скрытых компонентов окна.
Когда то давно, уже почти окончив университет, сам изобрел бинарное дерево поиска :)
Это был последний курс университета, я не был в общем то примерным студентом и больше работал, чем ходил на лекции, но материал изучал, по долгу сдачи сессии, чему учили? Многому учили, но вот теории алгоритмов вообще и конкретных алгоритмов в частности, не было. Так же как и не было, литературы в библиотеке нормальной по теме, а вожделенный трехтомник Кнута стоил полугодовой зарплаты.
С удовольствием бы поменял такой расклад, на университет где принуждали учить не нужную теорию алгоритмов и классические алгоритмы!
Это бы сэкономило, мне годы, годы потерянные на осознание того, что я в общем то ничего не знаю!
Это был последний курс университета, я не был в общем то примерным студентом и больше работал, чем ходил на лекции, но материал изучал, по долгу сдачи сессии, чему учили? Многому учили, но вот теории алгоритмов вообще и конкретных алгоритмов в частности, не было. Так же как и не было, литературы в библиотеке нормальной по теме, а вожделенный трехтомник Кнута стоил полугодовой зарплаты.
С удовольствием бы поменял такой расклад, на университет где принуждали учить не нужную теорию алгоритмов и классические алгоритмы!
Это бы сэкономило, мне годы, годы потерянные на осознание того, что я в общем то ничего не знаю!
Обычно на собеседовании даю решать задачки (помимо технических вопросов на понимание конкретной области). Я не использую задачи на знания "специализированных" алгоритмов (сортировка, бинарный поиск, графы, деревья и т. п.). Алгоритмы знаю (достаточное количество).
Задачи вовсе необязательно должны отвечать на вопрос "а где это применяется на практике?". Цель задач не в этом. Цель такого род задач оценить насколько хорошо кандидат умеет мыслить, каким образом кандидат пытается подойти к решению, насколько хороши навыки владения тем или иным языком программирования, как кандидат проверяет правильность своего решения. Удобство задач в том, что они миниатюрны (одно предложение в большинстве случаев).
Если взглянуть на набор задач, которые обычно предлагают на собеседовании то можно заметить, что эти задачи в основном нацелены на то, чтобы проверить знает ли кандидат о существовании того или иного алгоритма и правильно ли он его может применить (вызвав, например, библиотечную функцию).
Важно также помнить, что интервью — это именно оценка кандидата, т. е. реальное положение вещей может несоответствовать оценке. Но за час беседы с человеком эту оценку нужно дать.
Со статьей согласен (хотя может, наверное, показаться обратное). Имел проект (на C#), который достался "в наследство" и вроде бы и люди не глупые его делали и давно уже не студенты (не в обиду студентам), но когда внутри цикла foreach по одной коллекции проверяется принадлежность к другой при помощи метода Contains. Только этот метод является методом-расширением для интерфейса IEnumerable, становится как-то невесело, нерадужно и печально.
Задачи вовсе необязательно должны отвечать на вопрос "а где это применяется на практике?". Цель задач не в этом. Цель такого род задач оценить насколько хорошо кандидат умеет мыслить, каким образом кандидат пытается подойти к решению, насколько хороши навыки владения тем или иным языком программирования, как кандидат проверяет правильность своего решения. Удобство задач в том, что они миниатюрны (одно предложение в большинстве случаев).
Если взглянуть на набор задач, которые обычно предлагают на собеседовании то можно заметить, что эти задачи в основном нацелены на то, чтобы проверить знает ли кандидат о существовании того или иного алгоритма и правильно ли он его может применить (вызвав, например, библиотечную функцию).
Важно также помнить, что интервью — это именно оценка кандидата, т. е. реальное положение вещей может несоответствовать оценке. Но за час беседы с человеком эту оценку нужно дать.
Со статьей согласен (хотя может, наверное, показаться обратное). Имел проект (на C#), который достался "в наследство" и вроде бы и люди не глупые его делали и давно уже не студенты (не в обиду студентам), но когда внутри цикла foreach по одной коллекции проверяется принадлежность к другой при помощи метода Contains. Только этот метод является методом-расширением для интерфейса IEnumerable, становится как-то невесело, нерадужно и печально.
Насколько способность решать задачки на собеседовании кореллирует с эффективностью соискателя на практике — интересный вопрос сам по себе. Например я знаю человека, который задачки решал неплохо, но вот работать в команде не умел от слова "совсем". Считал всех идиотами и никого не слушал. Да и его решения и дизайн были под вопросом. И зачем он такой нужен? Да и человек сидит под стрессом, мало ли как он с задачками справится. Я людей гоняю по понимаю конкретной технологии больше, с которой они будут работать. Большинство отсеевается на этом этапе сразу.
Лично я предпочту взять человека, который меньше знает, но признается в этом честно и пойдёт и выучит вопрос. Такого легко обучить и он будет расти.
Лично я предпочту взять человека, который меньше знает, но признается в этом честно и пойдёт и выучит вопрос. Такого легко обучить и он будет расти.
Насчет стресса — я это понимаю — пытаюсь подбодрить, подсказать в конце концов, не дать сдаться сразу. Как на интервью оценить умение работать в команде, я, честно говоря, не знаю. По технологии я тоже гоняю в первую очередь. Предпочту взять человека, который пускай чего-то не знает по технологиям, но делает правильные шаги к решению. Критический случай — когда не знает ничего по технологии, но такое бывает редко. Впрочем, как правило, и на задаче такие ничего предложить не могут.
Стресс обычно бывает только на первых интервью, с каждым новым интервью стресса меньше и меньше. Первые интервью в жизни как правило провальные. Дальше — лучше.
Стресс обычно бывает только на первых интервью, с каждым новым интервью стресса меньше и меньше. Первые интервью в жизни как правило провальные. Дальше — лучше.
Я считаю что умение решать задачи — это основной навык программиста. Я тоже предпочитаю людей, которые имеют пробелы в знаниях по технлогиям, но могут думать и анализировать ситуацию. Просто ситуация, когда люди не имеют достаточно знаний чтобы просто сделать анализ проблемы, к сожалению не редка.
А оценку работы в команде можно сделать по многим критериям. Например по поведению человека — если он ведёт себя как пуп земли на собеседовании, то шанс что он не уживётся в команде велик. Ещё можно спросить про его предыдущее место работы и посмотреть как он будет отзываться о коллегах и начальниках. У меня например был человек, который прям на собеседовании был готов слить секретную коммерческую информацию своего работодателя, от которого он уходил.
А оценку работы в команде можно сделать по многим критериям. Например по поведению человека — если он ведёт себя как пуп земли на собеседовании, то шанс что он не уживётся в команде велик. Ещё можно спросить про его предыдущее место работы и посмотреть как он будет отзываться о коллегах и начальниках. У меня например был человек, который прям на собеседовании был готов слить секретную коммерческую информацию своего работодателя, от которого он уходил.
Может хватит уже мусолить эту тему.
Хотите быть прогером можете не учить алгоритмы.
Хотите быть Software Developer'ом учите.
Помните без алгоритмов Microsoft, Google, Facebook, IBM вы нахер не нужны.
Серьёзные кажется люди на хабре сидят, а мусолят уже эту тему две недели. Пора бы уже забыть. Лень учить, не учите. Все просто
Хотите быть прогером можете не учить алгоритмы.
Хотите быть Software Developer'ом учите.
Помните без алгоритмов Microsoft, Google, Facebook, IBM вы нахер не нужны.
Серьёзные кажется люди на хабре сидят, а мусолят уже эту тему две недели. Пора бы уже забыть. Лень учить, не учите. Все просто
Странно, что еще никто не откомментировал. List и ArrayList это одно и то же. Видимо подразумевался LinkedList
Ну, это не совсем одно и то же. Но да, алгоритмы там внутри одни и те же.
Отличие лишь в том, что ArrayList не генериковый, и в контексте статьи, т.е. в контексте сложности алгоритмов, он таки идентичен абсолютно. И нет вообще ни одного кейса, который бы ускорился от замены List на ArrayList.
А в обратную сторону единственный кейс — боксинг, что опять же, со сложностью алгоритмов не пересекается никак.
А в обратную сторону единственный кейс — боксинг, что опять же, со сложностью алгоритмов не пересекается никак.
Дорогой автор! Любое новое знание, вкладываемое в голову, должно быть экономически оправдано. У вас в статье про это — ни слова.
Если среднестатический разработчик, работая в офисе 8 часов в день, внезапно вложит себе в бошку волшебное средство, которое ускорит его работу в два раза, это не значит что он будет зарабатывать в два раза больше денег. Это значит, что он будет пахать в два раза больше за то же время, потому что никто не оставит простаивающим дорогостоящий человекоресурс. Безусловно — круто для работодателя, но вот надо ли оно разработчику?
Я сам трепетно отношусь к алгоритмам и паттернам, продвигаемым IBM и Amazon. Я могу читать лекции о lock-free и темпоральных структурах данных и потоковых вычислениях. Но они не дают мне возможности пинком открывать дверь в отдел кадров любой конторы на рынке, и требовать тройное увеличение оклада. Потому что чем больше инструментов ты знаешь, тем меньше работодателей, где все эти инструменты востребованы одновременно.
В итоге специалист, отрастивший себе набор ускоспециализированных скиллов, оказывается тупо привязан к месту работы, потому что ну нет, блин, нет на рынке 100500 контор с необходимостью использовать красно-чёрные деревья или ручками писать сортировку пузырьком. Зато есть 100500 контор, готовых платить многозначную сумму в евро за общую адекватность, интуицию, широкий кругозор и способность делать поддерживаемый продукт на банальном пэхэпэ или руби.
Это рынок, чувак.
Если среднестатический разработчик, работая в офисе 8 часов в день, внезапно вложит себе в бошку волшебное средство, которое ускорит его работу в два раза, это не значит что он будет зарабатывать в два раза больше денег. Это значит, что он будет пахать в два раза больше за то же время, потому что никто не оставит простаивающим дорогостоящий человекоресурс. Безусловно — круто для работодателя, но вот надо ли оно разработчику?
Я сам трепетно отношусь к алгоритмам и паттернам, продвигаемым IBM и Amazon. Я могу читать лекции о lock-free и темпоральных структурах данных и потоковых вычислениях. Но они не дают мне возможности пинком открывать дверь в отдел кадров любой конторы на рынке, и требовать тройное увеличение оклада. Потому что чем больше инструментов ты знаешь, тем меньше работодателей, где все эти инструменты востребованы одновременно.
В итоге специалист, отрастивший себе набор ускоспециализированных скиллов, оказывается тупо привязан к месту работы, потому что ну нет, блин, нет на рынке 100500 контор с необходимостью использовать красно-чёрные деревья или ручками писать сортировку пузырьком. Зато есть 100500 контор, готовых платить многозначную сумму в евро за общую адекватность, интуицию, широкий кругозор и способность делать поддерживаемый продукт на банальном пэхэпэ или руби.
Это рынок, чувак.
Любое новое знание, вкладываемое в голову, должно быть экономически оправдано.
SRSLY? Вам контрпримеров привести, или вы сам поправитесь?
Приводите сколько хотите.
Но если мой сотрудник, в оплаченное мной рабочее время, занимается вложением себе в бошку каких-то знаний, эти знания должны быть экономически выгодны моему проекту в долгосрочной перспективе. Потому что иначе он работает мне в убыток, а себе в пользу.
Вся эта широко обсуждаемая байда о том, что программист должен всегда учиться, эгоцентрично ориентирована программистами на самих себя.
Программы пишутся не для того, чтобы они отрабатывали за сколько-то там миллисекунд или ради прочей ерунды. Программы пишутся для того, чтобы доходы от них были выше совокупных расходов. С этого надо начинать, а не с мерянияпиписьками алгоритмами.
Но если мой сотрудник, в оплаченное мной рабочее время, занимается вложением себе в бошку каких-то знаний, эти знания должны быть экономически выгодны моему проекту в долгосрочной перспективе. Потому что иначе он работает мне в убыток, а себе в пользу.
Вся эта широко обсуждаемая байда о том, что программист должен всегда учиться, эгоцентрично ориентирована программистами на самих себя.
Программы пишутся не для того, чтобы они отрабатывали за сколько-то там миллисекунд или ради прочей ерунды. Программы пишутся для того, чтобы доходы от них были выше совокупных расходов. С этого надо начинать, а не с меряния
Зацепился взглядом, за метод пузырька, да его пришлось писать самому, т.к. его нет в стандартной библиотеке используемого языка, просто по тому, что зная природу своих данных, я предположил и проверил, что он работает гораздо быстрее в среднем лучших для среднего случая из библиотеки.
Заминусовали беднягу. Если знания не должны быть экономически оправданы, как тогда выбирать, что именно из бесконечного множества вещей узнать прямо сейчас, а что отложить на потом? Очевидно, что либо у тебя, юзернейм, есть функция полезности для сравнения вариантов, либо одно из двух.
А что, функция "полезности" только экономической оправданностью определяется?
Функция "полезности" или, по другому, оптимизирующая функция — это и есть экономическая оправданность. Или для вас экономика — это только деньги и их производные?
Или для вас экономика — это только деньги и их производные?
"Эконо́мика [...] — хозяйственная деятельность общества, а также совокупность отношений, складывающихся в системе производства, распределения, обмена и потребления."
Не все, чем я руководствуюсь при выборе между тем, что сейчас изучать, попадает под это определение.
Как насчет поискать определение для термина "экономически оправданная деятельность"?
Чуть выше вы хотели привести примеры. Я бы хотел их услышать, потому что не могу представить ни одного.
Чуть выше вы хотели привести примеры. Я бы хотел их услышать, потому что не могу представить ни одного.
Как насчет поискать определение для термина «экономически оправданная деятельность»?
https://yandex.ru/search/?text=%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%20%D0%BE%D0%BF%D1%80%D0%B0%D0%B2%D0%B4%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F%20%D0%B4%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C
Чуть выше вы хотели привести примеры. Я бы хотел их услышать, потому что не могу представить ни одного.
Вот, например, прямо сейчас я прохожу курс Seeing Through Photographs, проводимый MoMA. Или, скажем, в прошлом году мы с женой ходили на лекцию-экскурсию "Певчие птицы Москвы". Или, например, посмотрим в мой книжный шкаф: сначала полка с литературой по истории и теории фотографии, затем книги про английских лучников, танцы Возрождения, до-опусную музыкальную культуру и светский этикет XIX века. Или, скажем, музеи — только за последнюю поездку: лыжи, полярные исследования, корабли викингов, Кон-Тики и просто морской флот (я даже не беру в расчет художественные, чтобы не обсуждать, знание ли это).
Все это — знание, которое я получаю. Ничто из этого не связано ни с моей работой, ни с любой другой деятельностью, которую я веду ради получения дохода, ни даже с деятельностью, которую я веду, чтобы снизить свои расходы; проще говоря, ни с какой моей хозяйственной деятельностью.
Я вас понял. Действительно, если руководствоваться определением из словаря/википедии, вы правы. Эти хобби действительно не связаны с хозяйственной деятельностью.
Временами я читал подобные споры с вашим участием в других темах хабра и могу представить, чем может закончиться этот. Жаль, не сразу догадался. Спорить со словарем желания нет, увы.
И да, мне действительно понравилось, как ссылкой на яндекс вы показали процесс поиска. Не знаю, дословно ли вы восприняли мой комментарий или просто пошутили таким образом, но это было забавно.
Временами я читал подобные споры с вашим участием в других темах хабра и могу представить, чем может закончиться этот. Жаль, не сразу догадался. Спорить со словарем желания нет, увы.
И да, мне действительно понравилось, как ссылкой на яндекс вы показали процесс поиска. Не знаю, дословно ли вы восприняли мой комментарий или просто пошутили таким образом, но это было забавно.
Действительно, если руководствоваться определением из словаря/википедии, вы правы.
А чем еще вы предлагаете пользоваться? Какое другое определение экономической оправданности вы можете предложить, чтобы оно при этом не было идентично полезности (а оба они отличались от удовольствия)?
В контексте этого обсуждения для меня термин экономической оправданности идентичен термину оптимизируещей функции. Полезность или удовольствие — просто значения, которые можно оптимизировать за счет других, говоря другими словами — цели.
Если бы я мог переписать свое первое сообщение, я бы написал что-то вроде такого:
Знания должны быть полезными. Всех знаний получить за ограниченое несколькими годами время нельзя, потому приходится отказываться от одних в пользу других. Кроме того, есть еще неопределенность в будущем. И если человек отказывается от изучения некоторых алгоритмов в пользу изучения какого-нибудь фреймворка, это не всегда означает, что он идиот. Возможно, у него другие цели. Возможно, у него есть некоторые свидетельства, которых нет у вас. Возможно, у него есть особые ограничения, о которых вы не подумали. Но господа минусующие не задумались об этом. Не уверен, о чем именно они подумали, но одна из догадок: "Как можно говорить об оправданности, ведь знания священны! Каков наглец, и ты еще смеешь называть себя программистом?"
Если бы я мог переписать свое первое сообщение, я бы написал что-то вроде такого:
Знания должны быть полезными. Всех знаний получить за ограниченое несколькими годами время нельзя, потому приходится отказываться от одних в пользу других. Кроме того, есть еще неопределенность в будущем. И если человек отказывается от изучения некоторых алгоритмов в пользу изучения какого-нибудь фреймворка, это не всегда означает, что он идиот. Возможно, у него другие цели. Возможно, у него есть некоторые свидетельства, которых нет у вас. Возможно, у него есть особые ограничения, о которых вы не подумали. Но господа минусующие не задумались об этом. Не уверен, о чем именно они подумали, но одна из догадок: "Как можно говорить об оправданности, ведь знания священны! Каков наглец, и ты еще смеешь называть себя программистом?"
В контексте этого обсуждения для меня термин экономической оправданности идентичен термину оптимизируещей функции.
А вот для человека, комментарий которого заминусовали — явно нет. И именно за это его и заминусовали.
Но господа минусующие не задумались об этом. Не уверен, о чем именно они подумали, но одна из догадок:
Ну вот лично я — а мой минус там тоже есть — подумал именно то, что написал: знания не обязаны быть экономически оправданы, у меня (и у других людей) могут быть и любые другие критерии выбора кроме "заплатят ли мне за это деньги".
«Я N лет пишу сайты/скрипты в 1С, и никогда не пользовался алгоритмами или структурами данных.»Странно. Вроде скриптовый язык 1С — это объектно-ориентированный язык… Как можно писать на нём и не иметь дело со структурами данных?
Коллеги, предлагаю отказаться от слова программист,
подобно тому, как через 100 лет после Ньютона отказались от слова "натуральная философия".
Если бы вы Ньютона назвали физиком, он бы удивился, т.к. в его эпоху его область знаний называли "натуральной философией". Свой основной труд он так и назвал: "Математические основы натуральной философии".
Я думаю, что слово программист лет через 30 станет неадекватным словом…
Я серьезно...
Короче. Спорящие люди — просто по разному понимают слово программист.
Моя теща вообще всех, кто может браузер установить считает программистоми.
Дайте ей инвайт и тут такое начнется...
подобно тому, как через 100 лет после Ньютона отказались от слова "натуральная философия".
Если бы вы Ньютона назвали физиком, он бы удивился, т.к. в его эпоху его область знаний называли "натуральной философией". Свой основной труд он так и назвал: "Математические основы натуральной философии".
Я думаю, что слово программист лет через 30 станет неадекватным словом…
Я серьезно...
Короче. Спорящие люди — просто по разному понимают слово программист.
Моя теща вообще всех, кто может браузер установить считает программистоми.
Дайте ей инвайт и тут такое начнется...
фактически обижены на университеты за то, что их заставили учить много сложного материала
А я обижен за то, что дали так мало =\
не решают NP задач
Видимо, имелось в виду «NP-трудных задач». Задачи из NP приходится решать даже программистам на 1C =)
Статья воабще ниочем!
Бред сивой кобылы в сферическом вакууме.
Когда это алгоритм стал строго процедурой? Дальше читать не стал.
Бред сивой кобылы в сферическом вакууме.
Когда это алгоритм стал строго процедурой? Дальше читать не стал.
Если же ваша работа заключается в написание SQL запроса и вбивание команды в консоль, то хочу вас огорчить: вы не программист, вы – пользователь
Очевидно, тут не хватает определения слова «программист», потому что иначе каждый работник более высокой квалификации может называть менее квалифицированных не программистами. Автор отсылается к какому-то образу «настоящего» программиста, но не описывает его, лишь проводит сравнения с ним. Имеет в виду себя?
Полагаю, целью процитированного предложения было унизить, а не заявить о том, что человек действительно не подпадает под определение программиста. И если это так, то это очень странное окончание статьи.
Я предположу, что у автора есть карьерный рост и уважение коллег, но почему он вот так отсеивает других людей, закрывая им дорогу в карьерный рост через «ты не программист, а значит и алгоритмы тебе не нужны, и вообще, ты зря потратил 5 лет жизни»? Всё это лишь потому, что человек делает работу более низкой квалификации? Поэтому ему запрещено расти? Это псевдоэлитарность какая-то, выглядит мерзко.
Я для себя понял, что ответ на заголовок статьи такой: знания алгоритмов нужны для того, чтобы показывать формошлёпам, какой ты перспективный, богатый и со связями (это не моё отношение к алгоритмам, а я так понял посыл статьи).
Казалось бы, статья с подобным заголовком должна поощрять людей к обучению, но нет, «вам это не нужно, вы всего лишь пользователи; это нужно только мне, но я всё это и так знаю, поэтому и пишу статью».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем программисту знать алгоритмы