Comments 45
Вывод из статьи - у Питонщиков свой мир (в принципе, подозревал, имея небольшой опыт работы в питонскими "инструментами"). Подключаем ML одной командой, но спотыкаемся и вынуждены придумывать алгоритм, когда нужно сделать ручную сортировку перетаскиванием. Вы всерьёз собирались писать в суппорт по этому поводу? Даже любопытно, сколько рабочих часов было потрачено на эту задачу.
По факту - алгоритмы нужны так же, как нужно в школе изучать математику и русский язык, чтобы быть программистом. Потому что нужно уметь думать, в том числе мыслить технологическими структурными элементами, уметь их в голове легко собирать и пересобирать, понимать, где у чего откуда растут ноги, и с какой стороны подойти к задаче. Да, ничего из этого не пригодится в работе, зато пригодится подвижный мозг, приученный решать определённые задачи. Знание фреймворков, навыки их поиска, выбора и быстрого впитывания документации кладутся наверх базовой алгоритмики, а не вместо неё.
у Питонщиков свой мир
))))))
сколько рабочих часов было потрачено на эту задачу.
Не много, это просто как пример на самом деле. Не нужно искать прям смыслы.
По факту - алгоритмы нужны так же, как нужно в школе изучать математику и русский язык, чтобы быть программистом.
Конечно, я согласен, когда вы изучаете язык. Или в начале пути. Алгоритмизация важный навык программиста.
Дано: миллион одних людей должны деньги миллиону других людей. Множество пересекается. Есть замкнутые цепочки, когда люди должны друг другу в круг. Требуется за секунду (желательно меньше) рассчитать оптимальный с точки зрения суммы набор цепочек для взаимного погашения долгов. Одна из типовых задач в клиринговых центрах. Жду готового решения с "примитивным алгоритмом" или ссылки на библиотеки.
Это однонаправленный граф с весами. Берём либу, ищем лупы. Образно.
Если же задача не абстрактная, то тут думать надо и в алгоритмы.
Добрый день. Много лет назад я делала похожую задачу о взаимозачетах - нужно было погасить максимально возможный долг в сети предприятий. Делала это построением циркуляции минимальной стоимости алгоритмом дефекта. Который сама модифицировала методом фаз Диница. Но за секунду это работать не будет даже на современных компьютерах, только разложение циркуляции на циклы требует времени. Кстати, циклов тоже в худшем случае м.б. экспоненциальное количество, через одну вершину могут проходить разные циклы.
Не могли бы вы назвать алгоритм, которым можно это сделать за секунду? Очень любопытно))
ну если совсем вкратце, то это старый добрый симлекс метод)) где матрица уравнений это сумма долга входящего равна сумме долга исходящего для каждого субъекта. Таким образом, можно отойти от истории с обходами графов, узлов, чего угодно. И решить через систему уравнений. Будет работать доли секунды на современных мощностях
Спасибо за ответ! Интересно, что сама задача до сих пор жива. Я, похоже, отстала от жизни. 20 лет назад, как теперь говорят, "топила" за графовые алгоритмы vs ЛП. Если задача допускает сетевую постановку, то построение потока будет эффективнее супротив более универсальных алгоритмов.
Получается, однако, что автор в чем-то прав. Все алгоритмы на сетях и графах - мало кому нужная роскошь, не говоря уж о их преподавателях))
А можете написать статью с примерами? Очень интересно стало.
Где-то здесь эти «алгоритмы» обсуждались в том разрезе, что есть даже курсы по прохождению собеседования в Гугл. И с этой точки зрения они существуют в системе отбора как классическое экзаменационное испытание, которое не имеет прямой связи с реальными задачами, но которое для рекрутеров перераспределяет ответственность за найм с себя на формальные признаки.
Умение решать задачу на алгоритмы не даёт гарантию, что человек будет хорошо работать. Просто это один из немногих способов, с помощью которого можно хоть-что то узнать о способностях человека за короткое время собеседования.
Поэтому интервьюеры спрашивают задачи на алгоритмы, а соискатели наталкиваются на их решение и в итоге все превращается в безумный фарс и спец олимпиаду.
Имхо, есть две крупных группы тех, кто не любит алгоритмы: те, кто понимает, как устроены алгоритмы, но не знает/забыл/не изучал детали, и те, кто не понимает, и поэтому не знает.
К людям из первой группы особых вопросов нет: если надо, они прочитают описание, поймут принцип работы и напишут сами достаточно хорошо. Например, человек решил не тратить время на то, что ему не интересно, его право.
А вот вторая группа вызывает очень много вопросов: почему человек не может понять принцип работы не очень сложных алгоритмов? С чем это связано? А какие ещё вещи из ИТ он не может понять? Недавно столкнулся с великолепной ситуацией: группа разработчиков не могла понять примерно два дня, что именно делает их код (который они частично написали сами, частично скопировали из разных источников). Верхнеуровнево все понятно, а вот что именно происходит в коде люди не могли понять. И их руководитель краснел от стыда и говорил, что ребята реально не понимают, что делает их код, хотя они же его и собрали.
Конечно же программист, обязан понимать алгоритмы, как минимум простые точно. Написать их в жизни какую-то часть.
Я просто хотел посмотреть немного под другим углом на разработку и как это бывает часто в жизни.
Пример пахнет оверинжинирингом, отдельная боль. Когда накрутят код так, что потом и сами не могут разобрать. Многие задачи можно написать проще, меняя подход.
Другое если тебе свалился чужой код, в нем хочешь не хочешь, а придется копаться.
Тут я согласен, что часто попытка использовать правильный и оптимальный подход может помешать увидеть простое неочевидное решение. Но, что занятно, часто для того, чтобы понять, что простое решение реально можно использовать, требуется большая квалификация, чем для того, чтобы просто использовать типовой подход.
ребята реально не понимают, что делает их код, хотя они же его и собрали.
В большинстве случаев программы, которые мы пишем, берут какие-то данные, компонуют их с другими данными и отправляют куда-то там, после чего анализируют ответ с результатом отправки. Программы - это огромная паутина "проводов" (маршрутов) по которым бегают данные. В узлах этой паутины стоят переключатели "if-then-else". Вот и все алгоритмы. Перефразируя известную поговорку электриков, можно сказать, что в программировании есть всего два вида сбоев: "нужные данные не попадают туда, куда нужно" и "ненужные данные попадают туда, куда не нужно". А задача программиста для начала растянуть эту "паутину", а затем перестраивать её по мере надобности. Любой алгоритм можно запихнуть в библиотечную компоненту и использовать эту компоненту в узлах "сети" (программе), ну а топологию маршрутов движения данных нужно уметь вытаскивать из кода и втискивать в код. Это не сложно, это объёмно.
Мне кажется, стоит банально вспомнить, а что такое "алгоритм"! Это мне кажется логичным, перед там как писать нужны ли они, или когда они нужны. И окажется, что алгоритм - это просто последовательность шагов для решения задачи. И способ мышления, который опирается на представление процессов реального мира (или еще не разработанного приложения) на базовые блоки и способ их выстраивания в виде алгоритма для решения задачи.
И попытка проверить "знание" алгоритмов нужна скорее не для проверки знания алгоритма решения конкретной задачи, а вообще - с целью проверки способности кандидата так мыслить. Понятно, есть и такие, которые могут спросить "знаешь сортировку пузырьком? Нет? - до свидания", но это какое-то маргинальное меншинство и предлагаю их в обсуждении этого вопроса игнорировать
А вот для остальных - алгоритмическая задача, повод посмотреть как кандидат мыслит и как реагирует на изменение вводных или что-то в этом роде. Конечно паралельно можно еще что-то узнать, например понимание того, как работает конкретный механизм внутри ( и вообще, насколько глубого кандидат копал свою область)
----------------------
Понимание
Подход
Алгоритм
И в этом месте хочется спросить? А как вы поняли, если не прибегали к мышлению, основанном у на алгоритмах? Понятно, мыслить можно по разному. Но вот интересно, а как тогда? И стоит ли кандидата, который сначала задачу понимает "как-то", а потом переводит в алгоритм - воспринимать, как адекватного програмиста?
И вот это уже реально вопрос :)
"Если утро, то выпью кофе, если вечер и пятница, то бархатное, если ни чего не подошло, вода."
Боюсь без алгоритмов сложно жить )
Ну давайте не сводить к двух крайностям, которые в реальной жизни никогда не встречаются. Понятно, последовательности действий, логически связанные между собой встречаются повсеместно. Ну, любой кулинарный рецепт, к примеру. И также очевидно, что на некотором базовом уровне такого рода "алгоритмическим" мышлением владеют все.
Вопрос в том, что для программиста базовых требований явно недостаточно, так как даже логика примитивных действий, прописанных в ТЗ/стори уже на уровне кода может трансформироваться в достаточно большую "блок-схему".
Также важно "видеть" во время реализации пограничные ситуации, возможное влияние среды, которое надо учесть в коде.
К примеру, простое действие "зажечь огонь на плите спичкой". Чего там сложного? На бытовом уровне почти все это делали кучу раз (ну кроме тех, у кого электро). А теперь давайте напишем алгоритм действия робота, который делает тоже самое. И я вот думаю, что условная домохозяка такую задачу зафейлит на раз, а к успешному алгоритму придет на 100й, а может и тысячной итерации.
И в этом разница, так как дорого платить плохому программисту за много итераций
Успокойтесь, скоро придёт ии и ничего не будет нужно.
Я вообще думаю вы слишком мягко прошлись по этим алгоритмам. На мой взгляд в принципе все программисты не важны! Зачем они вообще? Чем занимаются? Только плодят баги и доставляют нам трудности! Без них жизнь была бы проще и собеседования легче проходить. Это я вам как QA говорю, мне можно верить.
Согласен, в 99% случаев достаточно этих трех составляющих. Понимание задачи наиболее упускаемый этап. Имею ввиду полное понимание, согласованное с пониманием заказчика. Часто бывает что понимание слабое, типа в процессе разберёмся, я уже делал подобное и т п. Здесь бы и моделирование интерфейса подключать. Отсюда вытекает правильная декомпозиция задач . Ну а алгоритмы они внутри задач сами выстраиваются.
"Программисту не надо знать алгоритмы, можно открыть Эксель и посчитать"
Эмм, а Эксель кто пишет, не программисты?
Можно ещё написать статью: инженерам автомобильной промышленности не надо изобретать автомобили: можно вызвать такси и поехать.
В современном мире, где есть ChatGPT, уже не важно знать наизусть все сложные алгоритмы. Достаточно иметь представление зачем тот или иной алгоритм существует и какие им можно решать задачи. Просто пишите чату "Покажи мне Алгоритм А на языке Б" и всё. Пару раз для успокоения души пройдитесь по коду отладчиком, напишите тестовое покрытие и готово.
Но есть вещи, которые так не решаются. Когда вы например знаете кучу алгоритмов поверхностно но не понимаете, как ими решить кейс. Зреет разработка собственного алгоритма. Но это уже совсем другая история. Не так давно накидавшись кофем, я рекурсивно растянул json дерево в хронологическую линейную последовательность. Олимпиадник я - нет. Знаю ли я алгоритмы супер хорошо - нет. Но оно работает, оно живое и решает наши кейсы, rps всех устраивает.
Как наиболее ценное в кандидатах, мы например, как средняя по размеру компания ценим именно способность творить новое. К пониманию старого относимся поверхностно.
Это все похоже на калькулятор и таблицу умножения. Кто то знает таблицу наизусть и решает задачи на листке бумаге за час. А кто то использует калькулятор и уже забыл таблицу совсем, но решает кейсы за 5 минут. А кто то пошел да и придумал свою математику.
Есть кейс.
Команде нужно написать обвязку к логгеру/рэйтлимитер/миддлварь. Из 10 человек в команде у 7 подход к разработке "алгоритмы не нужны, надо знать фрэймворк". Нужное решение пишется и работает небольшое количество лет. Со временем нагрузка на сервисы увеличивается и следующее поколение разработчиков, занимаясь оптимизацией, попутно выясняет, что около 90% работы приходится на участки кода, написанные вот такими ребятами. В неожиданных местах находится кубическая сложность вместо линейной.
Сейчас кто-нибудь бегло прочитает статью, а потом придёт на собеседование, где ему предложат простую алгоритмическую задачу и спросит: "задачи? Зачем?".
Я согласен с некоторыми моментами. Олимпиадники часто оторваны от реальности. Но нужен какой-то баланс. Разработчик должен уметь не только "numpy go brrr"
Если предыдущее решение, судя по всему, успешно работало несколько лет, то значит оно подходящее. Скорее всего его было легко создать и не заняло много времени и те разработчики освободилась для новых задач.
А сейчас, через несколько лет, нагрузка выросла (и скорее всего и бизнес) и узкие места стали проблемными. Но это нормально, что только сейчас их переписывают более оптимальным способом.
Ребята сделали канализацию, а она зимой замерзла, надо переделывать. Это нормально, она ведь полгода успешно решала задачи бизнеса. И те разработчики освободилась для новых задач.
если вам нужна канализация для частного дома на семью из 4 человек то глупо и расточительно ставить по проекту для микрорайона. Комментатор выше пытается донести до вас что преждевременная оптимизация зло и если в течении нескольких лет этот участок кода не доставлял проблем то значит задлача была решена правильно. как только ситуация изменилась то сразу этот код пошли переписывать
Спасибо, именно это я и имел в виду, что преждевременная оптимизация - корень всех зол.
Одно дело, если бы решение нужно было бы переписывать сразу или же через пару месяцев после них, тогда да, как в примере комментария о трубах - решение не рабочее и не годится.
Но вот если оно работало несколько лет и справлялось со своей задачей - то все нормально. Скорее всего справлялось бы и дальше, если бы не сменились требования.
А надо сразу строить канализацию с подогревом и электростанцию рядышком для этого. Ведь рано или поздно наступит новый ледниковый период и морозы до -70!
Не все задачи сводятся к перетаскиванию элементов ui мышкой. Многие задачи, имея только базовое понимание требуемого результата, эффективно решить невозможно.
Реальный пример: сокращение времени обработки данных с 40 минут до 30 секунд на тех же мощностях исключительно за счёт правильной алгоритмизации.
Если вы считаете, что алгоритмы не нужны, вы решаете слишком простые задачи.
Зависит от того почему так медленно работает. Например для того чтобы понять что выборка/запись из репозитория в цикле - плохое решение, не нужны знания сложных алгоритмов.
Сколько в последнее время делал задач по рефакторингу, обычно всё упирается в простые вещи.
Нужно было написать менее провокационный заголовок. Я хотел другую важную мысль выразить. Но всех тригернуло на алгоритмах.
Кажется тут больше подошло бы "Почему знание реализаций алгоритмов наизусть не важно", это в большей степени вызывает проблемы, по крайней мере у меня. Мозг устроен так, что даже если я 10 раз прочитаю и выучу какой-то специфичный алгоритм, я его забуду, потому что не пишу его каждый день, у меня есть ссылка в голове, я знаю что такой алгоритм есть и смогу быстро освежить память в гугле, но постоянно держать его в голове у меня не получается и так со многими вещами.
Как раз таки, разница между умением решать алгоритмы и решением алгоритмов. Понимание и подход это как раз таки части уменря решать оные, а просто решать можно и по шаблону вообще не вдупляя что происходит. Поэтому именно умение решать и важно, а не решение само по себе
Чтобы библиотека или фремворк работал, а программист при этом не знал алгоритмов, нужен программист, который создаст эту библиотеку или фремворк.
Даже создание физики в играх, например, полет пули. Когда нужно просчитать поведение пули на всей траектории. Просчитать точки, в которых пуля встретит препятствие. Что решается с помощью, например, динамического программирования. Аналогично с решением шахматных задач, где нужно просчитать возможную траекторию ходов ферзя и тех фигур, которые он может забирать.
На практике такие задачи могут решаться готовыми решениями. И все будет работать, пока устраивает это самое готовое решение. А если не устраивает, если нужно создавать свое решение?
Да, есть задачи в которых придется попотеть над алгоритмами. Думаю приведенные примеры это отражают: свои библиотеки, фреймворки, игры, своя ОС, высоконагруженные системы и т.д.
Но так же хочу заметить что очень много задач где особо сложных алгоритмов нет, например: веб разработка, веб приложения.
А вот как это правильно назвать - разработка или администрирование. На той же джанге в питоне, даже можно сам питон не особо знать
Ну это такая невидимая грань. Программисты на Си/С++ скажут что программисты на Python недопрограммисты. Потому что на самом Python даже без Джанго используется много готовых библиотек. Я считаю что разработка на фреймворках это программирование, просто современное программирование. Где рыночек хочет результат побыстрее и где можно программистов заменять и набирать новых на популярный стек. Ничего плохого в этом нет, действительно все начинает походить на какой-то конструктор лего ) Но мы же этого и хотели? Удобно и быстро разрабатывать программные продукты приемлемого качества.
Понимание алгоритмов можно воспринимать как побочный эффект высокого уровня способности логического мышления человека. Но такая способность требует большого количества энергии, затрачиваемого мозгом. Если же принять во внимание принцип Парето (80% результата достигается за 20% усилий), то не всегда высокий уровень логического мышления выдаёт быстрый результат. С другой стороны, парадоксально, что потребители могут чутко различать 80% и 100% качества, например, автомобили ВАЗ и Мерседес.
"высокого уровня способности логического мышления человека"
Моя мысль в другом, то что эта способность может быть бесполезна если человек не понимает бизнес задачу. Он может жестко оверинженирить, писать кучу кода ненужного, и потом кроме него ни кто это не разберет, я с таким встречался. Такие заумные принесут больше вреда чем пользы. Понятно что не все такие, хотелось бы что-то без крайностей, что-то среднее...
На мой взгляд отличное знание сложных алгоритмов в разработке не достаточно, это не делает тебя автоматически хорошим программистом. Наверное это я хотел сказать.
По-моему это подход питонщика. Действительно зачем уметь делать алгоритмы, если есть библиотека, нужно ее подключить и в ней уже есть нужный нам алгоритм :)
Но если мы говорим о других языках, то есть нюансы. Во-первых, этот подход абсолютно правильный для питонщика, потому, что питонщика берут как раз для таких задач, где алгоритмы не нужны.
Во-вторых, если мы будем говорить о с++, то алгоритмы обязательны, а ещё надо знать как именно они работают, потому что основная задача програмиста на скорость и совместимость.
В-третьих, если мы говорим о специалисте по безопасности, то эта статья - чушь собачья, потому что он должен знать об уязвимостях, как их предотвратить и обойти, готовые решения есть, но он должен именно знать как работают их алгоритмы.
В-четвертых, я сам пишу на с# парсеры, спарсить данные не сложно, основное время занимает обход защит и корректировка парсеров при изменениях сайта. Для обхода защит мне нужны алгоритмы, поскольку защиты сделаны именно так, чтобы стандартные библиотеки не работали. А для того чтобы не править парсер при каждом чихе мне нужно использовать xpath и regx технологии. И я бы сказал, что написать хороший xpath выражение на динамически меняющейся странице типа google или yandex, не проще, чем какой нибудь весёлый алгоритм бинарного поиска или т.п. И сложный regx не проще. А ещё бывают задачи по парсингу пару миллионов страниц с отсеивание их на дубликаты и тут надо экономить каждый такт.
Мне жаль что меня не так поняли. И кидают минуса в карму )
Конечно же алгоритмы как таковые часто нужны. Даже программа print(2+2) это алгоритм. Но идея не в этом.
Вот из Вашего примера...
Возможно (это просто теоретически, как пример) донор для парсинга имеет апи или может запартнерится с сервисом и предоставить апи, и тогда не нужно вообще будет писать алгоритм для xpath. Грубо говоря тебе ставят задачу вот спарси от сюда, а зачем, если у них есть апи? И это уже выходит другая задача с более простым подходом.
То есть я хотел сказать, что часто подход к задаче важнее алгоритма.
Ну и про С++ понятно и про Си, но все же.
ps заголовок просто несколько вызывающий
Почему алгоритмы не важны?