Комментарии 74
Есть разный уровень решения задач. Если задача сводится к применению уже известных алгоритмов в виде готовых библиотек, то внутренности алгоритмов не обязательно знать.
Но если Вы решаете неформализованную задачу, то ее решение начинается с разработки алгоритма , а в более сложных случаях еще и с выбора методов решения.
Например, Вам надо разработать программу управления экскаватором в реальном масштабе времени при ограниченном объеме памяти управляющего микроконтроллера.
Сразу начнете писать программу?
Или начнете разрабатывать алгоритм?
Есть разный уровень решения задач. Если задача сводится к применению
уже известных алгоритмов в виде готовых библиотек, то внутренности
алгоритмов не обязательно знать.
Если вам нужно хранить уникальные неповторяющиеся значения и доступ к ним осуществляется только итерацией по коллекции, то какую страндартную структуру вы выберете?
Вы по теме статьи спрашиваете?
Структуру чего Вы хотите выбрать и из какого стандарта?
Сферическую в вакууме, как и сам вопрос.
В реальной жизни этот вопрос обычно идет последним, имеет околонулевое значение и над ним никто реально не задумывается, выбирая автоматом. Первыми же идут такие вопросы: как хранить коллекцию? Как выбирать коллекцию из хранилища? Кэшировать, или не кэшировать коллекцию? Если да, то этот кэш надо пошарить между разными инстансами, или нет? Как сериализовать и передавать коллекцию? Как обновлять коллекцию? И тд, еще может быть 100500 реальных вопросов, после которых окажется, что выигрыш каких-то наносекунд от использования конкретной структуры намного меньше на 8 порядков меньше, чем среднее время отклика. А еще потом окажется, что из этой же коллекции удобно достать пару элементов по условию, но т.к. в ней все равно не больше 30 элементов, то... А о чем был вопрос?
И тд, еще может быть 100500 реальных вопросов
Я не очень верю, что человек который не представляет как базовые коллекции устроенны внутри и как работают алгоритмы оптимально ответит на все эти вопросы.
Да можно заучить основные операции с коллекцией, но всегда есть нюансы.
Можно данные в HashSet со сложностью O(n) вставлять. Но это редкость.
Чаще я видел вставку в начало ArrayList.
Человек, который вообще не представляет, как устроены базовые коллекции, скорее всего вообще не программист.
Но вы подменили вопрос. Не представлять, как устроены коллекции - это одно, а создавать в 99% случаев List даже не задумываясь, потому что это экономит время разработки и не влияет никаким значительным образом на результат - это другое. Наверное статья не очень хорошо очерчивает предметную область, потому что похоже каждый спорит о своем.
Спорное решение - тратить время на изучение способов обхода графа, или там бинарного дерева (которые ты учил когда-то в вузе, или не в вузе, но забыл за ненадобностью за 20 лет разработки) в ущерб времени на изучение Mass Transit или Wolverine, сложность работы с которыми точно не в алгоритмах, а знание тонкостей и деталей требуется здесь и сейчас, т.к. непосредственно и очень сильно влияет на результат и сроки.
Современное приложение представляет из себя чудовищный зоопарк технологий и фреймворков, и знание того, как с этим зоопарком работать, что из этого зоопарка можно или нужно поменять, как заставить его работать друг с другом, и работать эффективно - это основная задача и сложность. При этом все это требует знать об алгоритмах лишь то, что они существуют в принципе. И да, само-собой, необходимо иметь даже не базовые, а глубокие знания как все устроено под капотом. И не только (и не столько) коллекции. В том числе и для того, чтобы определять, на что сейчас стоит тратить время и усилия, а на что нет - как на выбор коллекции тут, или там.
решение неформализованной задачи начинается с допроса с пристрастием всех к ней причастных и никак иначе
У меня на пред-предыдущей работе человек, который имеет кандидата наук в вычислительной алгебре, и человек, который после чтения каждой строки из постгреса закрывал соединение и открывал снова, просто чтобы было удобно что весь код БД в одном месте - это один и тот же человек.
Математиков к коду вообще лучше не подпускать - с них сыпятся сферичские вакуумные кони.
Какая разница, быстрее там по алгоритму HashMap или TreeMap, если в вышем языке один из них, например, потокобезопасен а другой нет?
Всё зависит от уровня решаемых задач, как упоминали выше. Я вот, так уж вышло, обычно работал в мелких фирмах, где гораздо выгоднее было для проекта внедрить багтрекер, оптимизировать CI пайплайны, отладить общие процессы разработки, оптимизировать сущности в БД, замутить дистрибутед трейсинг, чтобы быстрее определять возможные проблемы в микросервисной инфраструктуре, изучить возможности k8s, чтобы добавить надежности/удобства в рамках развертывания веб-приложения, следить за поддерживаемостью кода, чтобы не офигевать через какое-то время от того, что мы там понаписали.
У меня никогда не было такой проблемы, чтобы мы упирались именно в незнание алгоритмов и не смогли бы локализовать это незнание и изучить при необходимости предметную область.
Странно. Кубер и MSA актуальны на проектах с ощутимым набором данных: по нескольку тысяч строк в десятке таблиц, как минимум. Логика, которую нужно разбивать по микросервисам, поскольку только одна доменная область может иметь очень много кода, и обслуживать его в монолите - тот ещë мазохизм.
Однако, тенденция уже много лет остаëтся неизменной: стоимость ресурсов железа гораздо меньше стоимости часа программиста. И это - основная причина того, что в мелких проектах применяют зоопарк решений: кубер, MSA, кафка, и т.д.. И это - основная причина того, почему на собесе у человека могут не спрашивать про алгоритмы и структуры данных. Докупить ресурс в облаке или на сервере будет дешевле.
И, всë-таки, когда объëм данных превышает определëнную отметку, за которой время выполнения алгоритмов начинает расти (а это происходит в любом случае, если бизнес не закрывается раньше), компания, как-правило, заменяет своих специалистов на тех людей, кто может произвести оптимизацию. При этом, рост зарплаты на рынке для специалистов, которые не могут понять причины неэффективности алгоритмов, идëт медленнее инфляции. На коротком промежутке времени (года в 2 - 2,5) это не критично. Наверное, даже 5 лет не будут достаточно критичной величиной. Зарплата немного растëт при переходе в другую компанию, уровень жизни остаëтся +- прежним. Может, даже немного улучшается. А вот перспектива буста в 2 раза и более - уже сомнительная. Поскольку, тут уже на собесах спросят и про алгоритмы, и про блокировки в параллельных вычислениях, и про индексы в БД, и ещë может повезти попасть на архитектурную секцию с проработкой интересных паттернов взаимодействия различных сервисов и слоëв.
Интересное наблюдение: за 9 лет мой заработок вырос примерно в 6 раз. Уровень жизни вырос, но не скажу, что значительно. Но он вырос.
Так что, в краткосрочной перспективе алгоритмы, возможно, и не нужны. Но, если человек хочет достичь определëнных высот, они обязательны к изучению и пониманию. Как и математика, как и теория операционных систем, теория реляционных систем данных и т.д..
Задача провести оптимизацию сводится к нахождению узкого места и масштабированию оного, либо за счет более эффективного алгоритма, либо путем вычленения его в отдельный сервис и масштабированию его вертикально. Подобрать эффективный алгоритм сегодня может любой джун, который умеет задавать вопросы ИИ. Выделить функциональность в отдельный сервис тоже, хотя тут уже желателен опыт, будет заметная разница в скорости. Особенно если нужно организовать какую-то сагу или типа того.
Настоящая сложность современных задач программиста намного, намного больше давным-давно всем известных алгоритмов, по сути справочной информации. Никому не нужны живые справочники, особенно в современном мире ии.
Да вы правы, справочная информация не нужна. Но как и описано в статье, работодатель в "идеальном мире" должен не спрашивать: "знаешь ли ты этот алгоритм?", а спрашивать: "а можно ли этот алгоритм применить вот в этой задаче". Тут уже половина начинает сыпаться, т.к. не могут применить справочную информацию к нестандартной ситуации
Работодатель не должен такого спрашивать, есть миллион и один куда более важный вопрос в современном мире программирования. Вопросы по непосредственно алгоритмам имеет смысл задавать только на крайне узкоспециализированные позиции. Например, разработчика компилятора, или движка субд. Это настолько ничтожный процент от современного айти, что как-то генерализировать важность знания алгоритмов не представляется возможным.
"Иделального мира" не существует, на то он и идеальный. Если 30 лет назад программистам особо нечего было знать, кроме алгоритмов, то сегодня одна позиция программиста отличается от другой, как профессия плотника, отличается от профессии бухгалтера. Как-то обобщить знания первых и вторых, чтобы нанять универсального работника - не представляется возможным
Вопрос более обширный и слово "алгоритмы" выбрано как "один из". Работадатель должен спрашивать в глубь чего-либо. Да хоть структуры данных, хоть фреймворк. Даже про интерфейс Map можно говорить всёсобеседование. Основная реализация, потокобезопасноть, использование Map другими структурами и т.д. Это показывает насколько человек готов погружаться в то, чем он сейчас занимается, на сколько это ему интересно. Для работодателя - это, грубо говоря, ресурс, который он может с сотрудника получить. А обязан или не обязан это, конечно, дело каждого. Вопрос про сложности найма тоже достаточно обширный, данная статья, к сожалению, не раскрыла эту тему. Может в следующей напишу
Знание возможностей фреймворка, или технологии - это не про алгоритмы. Это знание, какие задачи можно решить при помощи того, или иного инструмента. К примеру, знание того, как реализовать систему авторизации и ролей на основании JWT токенов не подразумевает знание каких-либо алгоритмов. Или знание каких-то ОРМ систем, их достоинств и недостатков, способов оптимизации работы с базой данных. Или распределенного кэша. И тд и тп.
Да, если очень и очень "в общем" то все это можно назвать алгоритмами, но тогда теряется смысл статьи, потому что "алгоритмы" от "алгоритмов" могут отличаться, как сказки братьев Гримм от Бхагват-Гиты. Паттерн "сага" для микросервисной архитектуры - это алгоритм, или нет? В какой-то мере да. Об этом статья? Нет.
Статья об алгоритмах из задачек с литкода, что-то типа того. Которые ИИ щелкает как семечки, выдавая рабочее решение на любом языке за секунды, не уступая лучшим специалистам. Тогда как опыт работы с конкретными технологиями (то, что реально дает бизнес-велью, ускоряя получение результата), так просто не получить, даже с помощью ИИ. Сходу и не узнаешь что спрашивать, не понимая устройства приложений подобного типа и не зная способов решения определенного рода задач. Каждый подводный камень (а их в процессе решения реальной задачи вылезет тысяча и один) будет вызывать серьезную задержку и обширный инвестигейт, куча чтива, эксперименты. А у человека с нужным опытом и знаниями это время сокращается в разы. Он уже читал, сталкивался, знает, решал, наступал на грабли. Он куда полезнее. Знание реализации сортировки пузырьком, или эффективного обхода конем шахматной доски - не даст ничего. Это за 3 минуты можно узнать.
С одной стороны я с вами согласен, с другой под конец статьи речь скатывается к пониманию принципа работы бинарного поиска и хешмапы а это уже элементарные вещи, и хороший программист должен уметь придумать такой алгоритм если не знает его. У людей которые этого не могут начинают встречаться методы с кубической а то и экспоненциальной сложностью там, где вполне можно было получить квадратичную или логарифмическую. Я такое видел и метод со сложностью по экспоненте может заставить тормозить самое современное железо на очень смешной задаче, но человек этого в момент написания не поймет т.к. оценивать сложность алгоритмов скорее всего не умеет (и так сказать насмотренности нет) а тестировать будет на небольшом наборе данных. И никакой ИИ который поможет потому, что чтобы он помог нужно осознать что проблема есть, а она либо проявит себя на ревью когда код написан либо в проде.
Вы так много говорите про современный мир ИИ. Но, по сути, если в вашем сообщении заменить "ИИ" на "Google", то, Во-первых, смысл не изменится. А во-вторых, текст с Google был бы применим и 9 лет назад.
Так что, не знаю о каком "современном мире ии" вы говорите. По сравнению с 2015 годом у нас, по сути, поменялся только поисковый движок.
В чем-то вы правы. Вы даже можете заменить "гугл" на "справочник", мой посыл от этого не изменится по большому счету. Никогда и ни от кого не требуется знать справочную информацию и помнить всю теорию.
Дискуссия же о том, чем современный ИИ отличается от Гугла уже выходит за рамки обсуждения предмета статьи. Но я все же отвечу, раз вы подняли эту тему. По сравнению с 2015м годом у нас все поменялось радикальнейшим, катастрофическим образом, не будет большим преувеличением сказать, что мы ушли за горизонт событий с того времени.
Расскажу забавный случай. Когда был молод - увлекался математикой. Пока сверстники мечтали стать порноактерами и бандитами (не помню уже кем там обычно мечтают стать школьники), я всерьез хотел стать математиком. Выигрывал олимпиады по всем точным наукам, ботанил в общем. Конец 90х. Но неблагополучное детство и необходимость на что-то кушать привели меня в айти, где я практически сходу неплохо устроился в начале нулевых. Тогда еще у меня оставалась тяга к фундаментальным вещам, и я очень долгое время любил решать алгоритмические задачки. Однако т.к. математика программисту не нужна, я ее благополучно забыл со временем. Решать задачки забесплатно, с возрастом тоже перестал. Очень давно. Взрослая жизнь, дети, все такое. И вот вдруг, недавно, на собеседовании, мне дают задачку с литкода на бэктрекинг. Представляете? С ума сойти. Я думал, что рассказы о подобном на собеседованиях - сказки Венского леса. Лонг стори шорт: на втором мониторе скормил задачку ГПТ и он выдал готовое рабочее решение с пояснениями. Во-первых, мне лень тратить калории на собеседовании, во-вторых было просто любопытно выйдет или нет. Вышло. Гугл так не умеет. Гугл не позволяет половину кода писать кнопкой таб. Гугл не ответит развернуто на сложный вопрос.
Вот пример. "Вероятность успешного эксперимента определяется как частное количества успешных экспериментов к общему их количеству. Сколько экспериментов мне нужно провести, чтобы вычислить вероятность успешного с погрешностью ниже 5%?". Это интересная математическая проблема и если вы о ней знаете - замечательно. Я вот не знал, а мне понадобился ответ. Конечно, я мог бы найти ответ и через Гугл. Это заняло бы какое-то время, я долежен был бы вспомнить теорвер, почитать материал. ГПТ ответил точно, быстро и максимально развернуто, а главное - правильно. Он позволил мне одновременно и найти ответ за минуту, и освежить необходимые знания. Может у вас и не поменялось ничего с 2015го года. У меня поменялось точно.
В конце 90-х - нулевых годах Google был точно таким же "рывком". До него были каталоги сайтов. Однако, развитие копипастинга, как способа решения проблем в программировании, связано с наполнением баз StackOverflow и Habr. А как способа прохождения интервью - только с развитием схем удалённого трудоустройства. В 10-х годах, чтобы устроиться в Web-студию, приходилось писать код на листочке, а решение можно было спросить, максимум, у голубя, сидящего за окном.
С одной стороны, может показаться, что поменялось многое: можно устраиваться на работу по скайпу, можно давать примеры нейросети, и она будет находить правильные ответы...
А с другой стороны, ничего не поменялось: программирование как было научной деятельностью, так и осталось. Раньше были Web-мастера, которые собирали сайты мышкой, сейчас есть кодеры, которые работают методом копипасты. Но они не осуществляют научную деятельность в рамках своей работы. Они собирают простые средства автоматизации.
Есть человек, который жарит котлеты во "Вкусно и Точка", есть человек, который готовит блюда в мишленовском ресторане. Они решают похожие задачи, но не эквивалентные. Хотя, казалось бы, техпроцесс приготовления бургеров шагнул далеко вперёд, чтобы заменить собой традиционную готовку вычурных блюд. И, всё-таки, приготовление бургеров - это достаточно автоматизированная деятельность. Она хорошо оптимизируется, и она оплачивается гораздо скромнее, чем деятельность шеф-повара в ресторане. Исчез ли спрос на шеф-поваров? Нет.
Бургер - это идеальная метафора для интеграции. Повар жарит котлету, готовит соус, режет салат, помидоры и сыр. Потом, собирает всё в единую конструкцию и отдаёт клиенту. По сути, деятельность похожа на то, что делают кодеры, пользующиеся StackOverflow или ChatGPT. Получить готовый кусочек кода, интегрировать в готовый продукт, продать клиенту.
Осталось найти ответ на простой вопрос: является ли должность повара во "Вкусно и Точка" пределом ожиданий выпускника кулинарных техникумов и академий? И является ли копипастинг посредством любых поисковых систем или лингвистических моделей пределом ожиданий человека, который идёт писать программы?
Программирование как не было никогда научной деятельностью, так и не стало ею. И никогда не станет. У науки есть вполне внятное и четкое определение, под которое деятельность программистов не попадала и не попадает. Наука - это деятельность, направленная на познание. Программирование - это ремесло. Как и медицина, например.
ИИ - это инструмент. Когда-то писали программы с помощью перфокарт, потом появились удобные редакторы, в современных ИДЕ давно есть системы интеллисенса, подсказок и дописок позволяют писать еще быстрее. ИИ - следующий шаг, он не просто дописывает список параметров, или имя методов, он выполняет еще больше рутинной работы. А большая часть работы программиста - рутина. Самое первое, что должен сделать любой программист получая задачу - поиск готового решения. ИИ ускоряет этот поиск в разы, более того, он может выдать адаптированное решение типовой задачи сам, без всякого поиска. Не пользоваться этим, только потому что ты и сам способен написать это, пусть медленнее? Или потому что можно пользоваться гуглом? А смысл? Наоборот, я лучше уделю больше внимания архитектуре разного уровня, займусь наиболее интересной творческой частью. Чем я собственно, как техлид и занимаюсь.
Шеф-повар, если он готовит еду, а не просто командует другими поварами, точно так же пользуется передовыми инструментами и технологиями своей профессии. И если ему нужно взбить майонез, то он будет его взбивать также точно, как и поваренок-подмастерье. В целом же аналогии обычно только уводят в сторону. С таким же успехом можно сравнить эффективность туда рикши и таксиста, здесь будет очевидным преимущество использования технологических средств. Люди давным-давно создают технические средства, чтобы расширить свои возможности. Почему-то когда дело касалось только физических возможностей, ни у кого антагонизма не возникало и в голову не приходило, заявить, что реактивный двигатель - это вдруг не большой скачок вперед. А когда появился инструмент, действительно расширяющий возможности интеллектуальные, тут же появился снобизм, дескать надо пользоваться только своим биологическим интеллектом и привлекать искусственный для решения каких бы то ни было задач - моветон и вообще означает какую-то ущербность.
Те, кто водит автомобиль, не разучатся ходить. Но всегда будут быстрее тех, кто полагается только на свои две ноги. ИИ - это гиганский скачок вперед, и он действительно все поменял радикальнейшим образом. Изменилось все. Кто этого не поймет, в ближайшей перспективе может оказаться в неприятной ситуации.
А вот ГОСТ 19781—90 определяет программирование, как научную деятельность. Кому или чему мне верить? Стандарту, или случайному человеку в Интернете?
Толковому словарю. Нау́ка (праслав. *na- + *učiti – учить, выкнуть) — деятельность, направленная на выработку и систематизацию объективных знаний о действительности.
В госте определено программирование, как "научная и практическая деятельность по созданию программ". Это в прямом смысле означает, что если вы занимаетесь компьютерными науками, то согласно этому госту вашу деятельность можно отнести к программированию. А не что любое программирование - это научная деятельность. Семантика. Но оставя за кадром для кого и зачем этот гост написан, а также что делать, если я живу в США и у меня подобных гостов нет, остается простой вопрос: вы занимаетесь компьютерными науками? Если занимаетесь, тогда вам безусловно понадобится математика и знания алгоритмов. Большинство, все же, под программированием понимают практическую деятельность, а не научную.
Даже если вы занимаетесь именно наукой, все равно неясен снобизм в отношении ИИ. Ученые сейчас используют ИИ очень широко. Уже были открыты новые лекарства с помощью ИИ (например абауцин - новый антибиотик), ИИ расшифровывает древние тексты и даже целые языки (например аккадский), а снимки с Уэбба сейчас тоже анализируются в первую очередь ИИ. В компьютерных науках наверняка тоже можно найти ему применение. Хотя вам виднее, я-то научной деятельностью не занимаюсь.
Вы не ответили на вопрос: кому или чему мне верить? Стандарту, или случайному человеку в Интернете?
Я что, предлагал кому-то верить? К чему эта демагогия? Что не так с гостом я ответил достаточно подробно. Нечего ответить, не хотите отвечать, не устраивает аргументация - не отвечайте. Эта дискуссия ни к чему не обязывает ни вас, ни меня.
То есть, ответа у вас нет. И к чему тогда вся эта демагогия?
Вы свели дискуссию к ложной дихотомии вопросом "кому верить из двух". Ложная дихотомия - прием демагогии. Не единственный в ваших постах, и я могу легко это показать. В моих постах демагогии нет, вы что-то напутали.
Наука - это все что использует научный метод. Программист по десять раз на дню выдвигает гипотезу что его код работает, после чего пытается ее опровергнуть при помощи тестов. Так что программирование - это чистейшая наука.
В таком случае я недавно занимался наукой, когда блины пек. Эмпирические гипотезы пытался подтверждать экспериментально. Как ученый ученому: все прошло хорошо.
Я дал определение слову наука. Это определение общепринято. В такой же, либо схожей форме, присутствует во всех словарях на любых языках. Система знаний об устройстве мира и деятельность, направленная на их приобретение.
Программирование же это деятельность по созданию и модификации программного обеспечения. Какой бы ни была наукоемкой отрасль, будь-то медицина, или инженерия - это не наука. Если цель деятельности состит не в объяснении картины мира - это не наука. Любое объяснение не годится, конечно же. Религия вроде тоже что-то объяснить пытается, но она тоже не наука. Как бы некоторым не хотелось. Теологам, например... Действительно, необходимо использовать научный метод. Но метод называется научным, потому что сформирован в рамках науки, а не наука называется наукой из-за метода.
Могу только добавить, что можно заниматься наукой, используя для познания (например, для обработки данных приборов) любыми методами программирования: запросом данных через API или запросами SQL, обработкой этих данных любыми алгоритмами (начиная от сортировки пузырьком или бинарным поиском), преобразованием этих данных (тут тоже куча алгоритмов), моделированием процессов и выводом результатов в виде графиков/таблиц/отчётов/карт/сайтов в любых форматах.
Обычно для всего этого даже пишутся какие-то программы/скрипты/библиотеки.
Но, занимаясь наукой в этом смысле (не computer science), исследователь и не назовёт себя программистом. Хотя (как бывает), не каждый умеет реализовать этот цикл полностью, а если умеет, то коллеги будут уважительно называть его «программистом», хотя это имеет слабое отношение к реальности.
Как мне кажется, верно и обратное: перекладывать json'ы — не научная деятельность.
Мы стараемся проводить рефакторинг кода каждые полгода, и всегда видим случайно или специально допущенные "алгоритмические" ошибки. Тут квадрат лишний, тут вообще всю коллекцию перебираем со вложенными сущностями (декартово произведение). И статья про то, что мы могли их и не увидеть. И в силу юного возраста, я просто надеюсь, что глаз начнет сразу замечать такие вещи
В этом прелесть работы человека: мы не машины - мы ошибаемся. Дело не в знании или незнании алгоритма. Как ни странно, мы можем не увидеть такие ошибки не потому, что не знаем теорию алгоритмов, а потому, что банально устали в тот день, когда это писалось.
Однако, я согласен с тезисами статьи. За 12 лет работы в IT, 9 из которых - в области коммерческой разработки, я пришëл к тому, что знания нужны. Знания различных теорий, связанных с IT, знание математики. Потому, что с этими знаниями уровень разработки совсем другой. В нëм минимизирован элемент случайности. Ты смотришь на коллег, которые не обладают базой, и видишь, что они не выбирают правильные пути решения задачи. В то время, как у коллег с базой выбор подхода идентичен тому, что выбрал бы ты. Это радует: так, хотя бы, можно понять, что не сошëл с ума.
Потому, что вокруг тебя целая куча программистов, которые сошли. Один носится с какой-нибудь дикой теорией, что код надо писать только так, как он учит. При этом, никто до сих пор не может начать писать так, как пишет он, поскольку он выбирает стиль и алгоритмы рандомно. Другой кричит, что ему, как сеньор-джуну математика не нужна, и он готов писать статьи на эту тему. И вообще, он много лет работает на одном месте, и работодатель им доволен.
Нет, всë-таки, базу нужно знать. Хотя бы, ради возможности общаться на одном уровне с нормальными инженерами, которые пишут одинаково лаконичный и качественный код. Потому, что в наш век Искусственного Интеллекта, очень трудно найти интеллект. Он заявлен, но его нет. Ни искусственного, ни естественного. Есть только море дезинформации и продвинутые боты типа Chat GPT или Copilot. В этот век не трудно закинуть в сеть какой-нибудь фэйковый материал про алгоритмы, а потом наблюдать, как у этого материала появляются адепты, и как работодатели включают в собесы пункты вопросов, чтобы отсеивать этих адептов.
И, я думаю, всë к этому идëт: скоро многие идеи мира IT превратятся в религиозные догмы. У Лю Цисина псевдонаучная организация "Грани Науки" продвинула идею того, что "физики не существует". Современные авторы хабра пишут, что "математика не нужна". То, о чëм вы говорите - алгоритмы, математика, различные теории, которые входят в минимум для айтишника - они нужны не для того, чтобы вы не совершали ошибок в коде. Вы их, так или иначе, будете совершать. Всë это нужно потому, что программирование - это научный процесс, и все эти базовые вещи - это база научного процесса. Они нужны затем, чтобы вы не занимались лженаукой. Чтобы шли только по пути доказанных теорем. А это, в свою очередь, нужно для того, чтобы ваша деятельность имела положительный результат, была продуктивной и снижала процент случайностей.
и все эти базовые вещи - это база научного процесса
Базовые означает, что без них задачу сделать нельзя, или это будет сложнее. Приведите пожалуйста конкретные примеры того, что вы называете базой, и задач, которые она помогла вам решить. А то может быть так, что все под базой понимают разное, что-то действительно нужно знать, а что-то нет.
Вот вы пристали со своими примерами. Ещë с вашего поста о том, что математика не нужна. Раздел математики, определяющий большинство процессов в современном IT, называется "Дискретная математика". Код, который вы пишете на языке программирования, подчиняется правилам логических высказываний.
Пример здесь - любой программный код. Ваши инструкции либо имеют логическое обоснование, либо не имеют.
Графы имеют непосредственное отношение к БД, поскольку ими реализована часть индексов. Вот, например, какой индекс вы будете использовать при поиске по дате в таблице последовательного лога событий? Почему? Каким индексом можно реализовать полнотекстовый поиск, не прибегая к использованию сторонних поисковых движков? Почему индексация в эластике проходит долго и как это исправить? Всë это - логические шарады, которые, так или иначе, решаются дискретной математикой. Вы можете еë не знать, но вы еë применяете каждый день. Просто, если вы еë знаете, то вы применяете еë эффективнее.
Сложность алгоритма - это, по сути, нахождение в уме производной и процесс дифференцирования функции, поскольку именно производная является мерилом любых изменений, а дифференциал показывает как меняется функция при прогнозируемом изменении аргумента (да поправят меня математики). Вы можете не знать всего этого, но вы используете это каждый день, и если вы знаете базу, то вы используете это эффективнее.
Например, можете ли вы доказать, что логарифмическая сложность алгоритма лучше, чем квадратичная? Насколько лучше? Допустим, вы видите, что при постоянном приращении числа заказов в бд на 100 в день, через месяц ваш алгоритм, использующий эти записи для отчëта, будет обрабатывать их в сумме на 10 секунд дольше. Откуда вы это видите? Как вы это посчитали? Ну, хорошо, посчитали и посчитали. Теперь, вы идëте к заказчику и говорите: "Насяльника, алгоритм совсем медленный будет, да! Согласуй доработку на 40 часов"! А он вам говорит: "Обоснуйте-ка, Мишель89, оплату вам 40 часов". И, опять, чтобы обосновать выгоду оплаты 40 часов для снижения сложности алгоритма, вам понадобится математика.
Вот вы пристали со своими примерами.
Естественно, потому что много разговоров о том, что эти знания много где нужны, но примеры почему-то привести никто не может.
Вот для нахождения производной таблица умножения это база, без умножения правильно ее посчитать нельзя, потому что степень переменной умножается на коэффициент.
Просто, если вы еë знаете, то вы применяете еë эффективнее.
Очередное утверждение без доказательств, в котором непонятно, что вы подразумеваете, для чего я и прошу примеры.
Ещë с вашего поста о том, что математика не нужна
Например, можете ли вы доказать, что логарифмическая сложность алгоритма лучше, чем квадратичная?
В моем посте я написал про математику алгоритмов отдельно, где сказал, что она нужна на базовом уровне.
Пример здесь - любой программный код. Ваши инструкции либо имеют логическое обоснование, либо не имеют.
Подмена понятий. Логическое обоснование состоит из фактов и логики, но не любые факты и логика связаны с алгоритмами. Если брать любой программный код, то ваше утверждение неверно, в написании большинства кода дискретная математика не помогает.
Графы имеют непосредственное отношение к БД, поскольку ими реализована часть индексов.
Подмена понятий. Мы говорим не о том, что используется в БД, а о том, что об этом нужно знать программисту. По вашей логике получается, что квантовая физика имеет непосредственное отношение к чайнику, поскольку чайник реализован элементарными частицами, а значит надо знать квантовую физику, чтобы вскипятить чайник.
Вот, например, какой индекс вы будете использовать при поиске по дате в таблице последовательного лога событий? Почему? Каким индексом можно реализовать полнотекстовый поиск, не прибегая к использованию сторонних поисковых движков?
Это всё практические знания инструментов, а не знания алгоритмов. Да, внутри принципы одинаковые, но это не даст вам знания о том, как сделать поиск по тексту в конкретной СУБД. Вы откроете документацию и прочитаете, какие индексы там есть. А то может для полнотекстового поиска там вообще ничего нет.
Например, можете ли вы доказать, что логарифмическая сложность алгоритма лучше, чем квадратичная?
Нет, и именно доказательство этого для ответов на дальнейшие вопросы не нужно. Достаточно знать, что она лучше.
Допустим, вы видите, что при постоянном приращении числа заказов в бд на 100 в день, через месяц ваш алгоритм, использующий эти записи для отчëта, будет обрабатывать их в сумме на 10 секунд дольше.
На практике такого никогда не бывает. Заказы из БД выбираются запросом, и по ним идет одинарный цикл с линейной сложностью. Либо делается группировка средствами БД, и нужно знать средства оптимизации самой БД. Вот поэтому и нужны практические примеры, а не гипотетические.
чтобы обосновать выгоду оплаты 40 часов для снижения сложности алгоритма, вам понадобится математика.
На практике начальник скорее всего скажет "Есть более важные задачи, давай через месяц посмотрим, если будет тормозить, оптимизируем".
Привет. Больше 15 лет назад, я так же рассуждал. Зачем мне математика? Мне казалось, что я разбирался лучше преподавателей в некоторых областях. В итоге я бросил учебу. А сейчас, решая действительно сложные задачи - я чувствую, что мне просто не хватает знаний. И очень хочу снова пойти учиться, но появляются новые и новые проблемы. Вывод очевидный: если есть возможность учиться - надо учиться и учиться, чтобы потом разбираться во всем и лучше всех.
Расскажите пожалуйста, в какой области и какие знания математики вам нужны.
"Математику нужно учить уже только потому, что она ум в порядок приводит". Программист, имеющий вышку с хорошей математической базой, просто инстинктивно, на глубинном уровне, проверяет свои выражения на правильность. Упрощает выражения ВЕЗДЕ и ВСЕГДА, добиваясь абсолютной ясности. Математика - это упрощение выражений. Математика - это вывод сути из горы формул и выражений. Программист с вышкой добивается "математической" правильности программы. Без костылей, без велосипедов. Работающей всегда, при любых входных данных (естественно, с защитой от неправильных данных).
Программист без вышки полагает, что высшая доблесть программиста - наворотить гору кода за день.
Программист с вышкой полагает, что высшая доблесть программиста - написать минимум кода.
В жизни не нужны знания математики. В жизни нужны УМЕНИЯ математики.
Сейчас делаю игру в качестве пет-проекта. Для расчёта баланса нужно самостоятельно прописывать формулы, использовать статистику, аналитику.
Не согласен с тем, что углублённые знания математики нужны всем и каждому, но лично я немного жалею, что в некоторых местах халявил в универе.
Я баланс в играх не делал, но кажется для статистики и аналитики не такие уж сложные формулы. В крайнем случае можно неделю посидеть порешать примеры на интегралы и среднеквадратичные отклонения. О том и речь, что обычно открываешь документацию и изучаешь, исключений не так уж много. Сложность алгоритмов одно из них, но и тут достаточно иметь представление об основных концепциях, на что обратить внимание и т.д., а не знать наизусть сложность всех методов сортировки в лучшем, худшем и среднем случаях.
Ну в противовес, программист должен понимать принципы работы алгоритмов и методы работы со стандартными структурами, т.к. это база.
Вообще программиста я считаю определяет понимание работы механизмов, чтобы для него было как можно меньше черных ящиков в разработке (магии).
Иначе порой получаем абсолютно бредовые вещи на выходе.
А инструменты и языки за десятилетие меняются порой кардинально 2-3 раза и знания по ним становятся попросту не нужны.
А вот знание под капотом как все работает, пригодятся регулярно.
Знать или не знать алгоритмы - вопрос не в знании. Знание в чистом виде в современном мире не стоит почти ничего, так как почти любая инфа лежит под ногами. Ну реально.
Вопрос в том, сможет ли человек:
1) Понять вообще, что он применяет. Это важно когда случается "ничего не рабоатет", а ответ часто где-то "внутри" фреймворка. Либо решение "валит" прод под нагрузкой либо в кластере. Понятно, долгое время можно "говнокодить", если задача вообще не критична по нефункциональным требованиям - это будет сходить с рук. Вывод: важно знать, как реализовывать ннефункциональные требования, так как их выполнение отделяет хороший код от плохого.
2) Понять, что вообще надо принять во внимание. Огромное число девелоперов реально вообще не осознают, что их код может быть запущен в более чем одном экземпляре. У них то на машине все ок, так как он один. Если вы в теме, что надо, к примеру, маскировать sensitive данные во время сохранения - то хотя бы поинтересуетесь, надо ли это делать вам в коде, ти если да - какой алгоритм взять/посоветовать
Т.е. обобщая, важно, сколько разработчки знает "половинок вопроса", чтобы задать их себе перед началом работы над таской (в хорошем вопросе содержится половина ответа). Знать же в конкретный момент вторую половинку ответа - это просто вопрос опыта / умения гуглить либо спросить ChatGPT
В разговорах со своими коллегами я очень часто слышал фразу «алгоритмы программистам не нужны», «алгоритмы никогда не используются в работе» и т. п.
аж ЖЫР потек
Проходят десятилетия но все еще остаются люди что рассуждают нужны ли алгоритмы и нужна ли математика. Если бы вы посмотрели на название "Алгоритмы и СТРУКТУРЫ ДАННЫХ" то заметили бы, что там еще есть какие-то "структуры данных". Я работаю уже более 15 лет и до сих пор вижу даже среди больших ентерпрайз проектов код который вместо использования пресловутой структуры Map использует например поиск на каждый элемент, например добавить к 1000 записям поле из другого массива в 1000. Т.е. с Map это делается за один проход по обеим массивам в 2000 чтений. Без Map это может занять 1000*1000 чтений. Благодаря таким "решениям" тормозит все вокруг, все ваши телефоны, сайты, сервера. Никто не требует знания всех алгоритмов сортировок. Но знание основных структур данных, применимость и оценивать сложность алгоритмов по памяти/скорости должен любой инженер. Ребята, да простому инженеру хватит 2-3 недели на освоение базы по алгоритмам что бы проходить собесы и не писать тормозную дичь.
Хватит, а потом скажут примени тут алгоритм N. А он никогда такого не делал, только книжку читал
Книга Кормена, конечно, топчик. Но вот с чем не соглашусь - 2-3 недель не хватит. Алгоритмы являются непреодолимым барьером практических для всех программистов на всех собесах. А что такое вдруг?! Ведь каждый знает, что это этап собеса, но вот ненавидят этот этап и все тут! Прочитать пару сотен страниц кормена - мелочь какая по сравнению с книгами по всем фреймворкам собеса. Всего лишь 5% от общего объёма требуемых знаний. Тогда почему не уделять эти 2-3 недели? А все просто. 2-3 недели недостаточно. Любой фреймворк усваивается со скоростью чтения или просмотра Ютуб. А алгоритмы - не справочная информация, необходимо в голове формировать сложные связи и абстракции. Проще говоря, думать надо, а это уже злит испытуемого.
Ты ходишь по очень тонкому льду)) тебя тупо захейтят, заодно и меня. В 2024м алгоритмы уже давно под запретом. Тенденция продолжалась десяток лет и достигла апогея. Вообще надо скрывать свои знания, чтобы тебя не спалили и не накинулись токсики. Как вообще алгоритм может пригодиться, если о его существовании даже не знают?! Более того, зачастую фреймворковые программисты даже не способны идентифицировать проблему, чтобы начать хотя бы гуглить "как решить ХХХ".
ЗЫ провел опрос, алгоритмы ни разу не пригодились ни сантехнику, ни электрику, ни уборщику.
ЗЫ ЗЫ сейчас понапишут якобы частные истории, доказывающие, что алгоритмы зло, а ещё хуже люди, знающие их)))
Самый худший из людей - это сказочник-злодей, преподаватель алгоритмов.
Да, да, да. Выше уже один написал, что делал баланс в игре - математика и алгоритмы ему не пригодились. Если бы кто-то сказал, что реализовывал программу для выполнения преобразований Фурье, они бы ответили, что писали такой код, но математика им для этого не потребовалась.
Слово "баланс" выше встречается в 2 комментариях, ни в одном из них не написано "делал, но математика и алгоритмы не пригодились".
Про преобразования Фурье хороший пример. Если мне нужно будет сделать преобразование Фурье, я почитаю документацию 2-3 дня, поищу примеры кода, потом напишу сам или выберу библиотеку, которая это делает. Так же, как сделал бы это при изучении в университете. Само преобразование Фурье мне заранее знать не нужно.
В очередной раз указываю на то, что вы неправильно понимаете, что люди подразумевают под словами "надо знать математику и алгоритмы". Как и автор статьи. Грубо говоря, под этим подразумевается, что вы можете описать, как делается преобразование Фурье, определенная сортировка или обход графа сразу на собеседовании.
Выглядит так, как будто вы считаете, что в университете есть какой-то магический источник знаний, и люди там изучают материал как-то по-другому) Что ж, не буду разрушать ваши фантазии.
Выглядит так, будто вы ничего не знаете, но везде лезете.
Если бы люди были способны эффективно учиться самому, то университетов бы не существовало ввиду ненужности. А в беднейших странах нигеры были бы такие-же образованные и грамотные, как представители физической школы в Австро-Венгрии начала прошлого века. Вы серьезно думаете, что учеба в университетах не лучше качеством, чем самоучкой? Что-ж, не буду разрушать ваши фантазии.
Разговор не об учебе в целом, а об изучении отдельного вопроса, который сводится к умению применить несколько формул. В этом отношении разницы нет, вы ищете материал и изучаете. Разница есть в том, что университет дает много знаний в разных областях, но об этом разговора нет.
то университетов бы не существовало ввиду ненужности
Роль университетов не сводится только к тому, знает ли отдельный человек какую-то информацию. Это проверка его знаний сторонними специалистами и документ с подтверждением. Также раньше университет хранил книги, которые были мало распространены. Только это не имеет отношения к ситуации "Надо сделать рабочую задачу с преобразованием Фурье".
А в беднейших странах нигеры были бы такие-же образованные и грамотные
Если они хотят учиться и есть доступ к информации, то да, они будут такие-же образованные, в тех областях, которые изучили. Если не хотят, то не будут, только с обсуждаемым вопросом это опять же не связано.
Для начала стоит узнать, зачем эти преобразования Фурье вообще нужны. И нужны ли они вообще для Вашей задачи. И какие там есть нюансы.
А так конечно, даже 2–3 дня лишние. Гугл вам за пару минут подскажет про FFTW. Но без знания теории очень тяжело будет понять, что именно возвращают функции из подобных библиотек.
Вот именно для того, чтобы понять теорию для того, что Гугл подсказал за пару минут, и нужны 2-3 дня. Я же написал "2-3 дня почитаю документацию", а не "2-3 дня поищу библиотеку".
Судя по оценкам окружающих комментариев, некоторые люди не верят, что это возможно, поэтому расскажу личный пример. В университете мы изучали симплекс-метод, нужно было написать программу для расчета. Из лекций было ничего непонятно, поэтому я нашел в интернете PDF с подробным объяснением, поразбирался неделю, разобрался и написал. Я делал это на практике, поэтому я знаю о чем говорю. Если бы была лабораторная по преобразованию Фурье, я бы сделал точно так же.
В очередной раз указываю на то, что спор "надо ли знать X" не о том, надо ли знать о существовании X, и школьный курс математики с интегралами и производными, а о том, достаточно ли знать только это на собеседовании или до начала выполнения задачи.
Алгоритмы, структуры и паттерны проектирования + хорошая насмотренность в рамках рабочего и смежных стеков нужны и важны, в первую очередь, для того чтобы инженер имел инструментальную базу. Оная база позволяет опытному инженеру предложить не одно, а несколько решений задачи по разному весу в треугольнике "деньги-время-качество", отсеяв из них то не что подходит под область определения данной задачи.
Давать литкод-задачки, спрашивать основы фреймворка/языка, проверять количество запомненных дезигн-шаблонов на собесе бесполезно с уровня миддл+, это я вам как человек проводивший много собесов могу сказать. Все это хорошо для недавнего выпускника вуза у которого нет реального опыта, или для чуваков у которых он сильно однообразен. В первую голову мы матчим человека с проектом куда он пойдет и пытаемся определить справится ли он, во вторую насколько мы с ним сработаемся.
"Не терять форму" проходя собесы хорошо для собесов и вообще никак для работы. Встречал экстремально анекдотичных персонажей обоих сторон - и тех кто которые отшлифовали собес-скиллы и абсолютно непригодны для работы и тех кто вносят серьезный вклад в сложные проекты, но на собесах никакие. Сам в некоторые периоды жизни бывал во второй роли, фиксится это заплывом по этим самым собесам после любого перерыва.
Ну и - собесы не скатились. Собеседуют люди, люди все разные, опыт в найме это отдельный скилл. Чекнуть именно этот скилл - практически невозможно. Задачи набрать разработчиков умеющих подбирать других разработчиков никогда не стоит. В итоге техсобесы в подавляющем большинстве случаев проводят буквально дилетанты.
Вот вам и вся история с наймом и алгоритмами. Это не параллельные вселенные, но пересекаются они единожды.
Но как я пойму, что его тут вообще можно применить? Как я пойму, что он тут улучшит работу?
Потому что вы знаете, что есть такой бинарный поиск, и он лучше перебора.
но и прожжённые опытом программисты не всегда понимают каким образом бинарный поиск лучше линейного, или из-за какой структуры данных индекс вообще ускоряет работу.
Потому что они знают, что "могут вспомнить что это такое посидев в интернете пару минут".
как такой работник сможет предложить использовать другой, более продуктивный вариант функции
Никак, берем и замеряем все варианты. Это нужно делать в любом случае.
Цикл по двумерному массиву можно реализовать 2 способами, сначала по x или сначала по y, их логическая сложность одинаковая, но один вариант немного медленнее из-за кеша в процессоре.
а второй просто знает, что зачастую HashSet работает быстрее, чем TreeSet
Вот дело как раз в том, что в большинстве случаев это ни на что не влияет. Если кому-то нужно выбрать, он прочитает в интернете описания для конкретной версии конкретного языка, а то вдруг там баг в какой-то версии, или они для многопоточности не подходят.
Индексы вдруг начинают работать дольше потому, что никто не знает, что они замедляют операции вставки
Это как раз практические знания возможностей инструментов, а не знание алгоритмов.
я знаю, что такой алгоритм существует, что он применим в той или иной задаче
Это не то, что подразумевается в словах "знать алгоритмы". Знание алгоритмов как раз этому противопоставляется. Считается, что недостаточно знать только то, что вы написали, об этом и есть весь спор.
В разговорах со своими коллегами я очень часто слышал фразу «алгоритмы программистам не нужны», «алгоритмы никогда не используются в работе» и т.п.
Т.е. коллеги решают поставленные им вопросы, тем же методом, что и обезьяны пишут "войну и мир"? Вообще, пока решение любой задачи алгоритмизируется. И без этого никак. Ну, может быть, вышеназванным методом... Но это маловероятно...
Другое дело, что для решения конкретной задачи не нужно все множество алгоритмов, а самые востребованные алгоритмы давно существуют в виде библиотек.
Отсюда главный вопрос - а что спрашивает данная статья? Должен ли программист знать ВСЕ МНОЖЕСТВО АЛГОРИТМОВ, созданных до него и им самим? Очевидно нет. В отдельных случаях надо знать ГДЕ посмотреть тот или иной алгоритм. Должен ли программист уметь составлять и реализовывать алгоритмы? Очевидно да, ибо это и есть его основная работа. Должен ли программист использовать алгоритмы из библиотек, вместо создания своих собственных - это реально вопрос. Но он точно не имеет однозначного ответа, и действительно тут все зависит только от задачи. В общем случае, если МОЖНО использовать готовое, то НУЖНО использовать готовое. В остальных случаях ПРИДЕТСЯ делать самому.
Алгоритмы для программиста - это примерно как огнетушитель в бардачке машины. Обычно огнетушитель не нужен от слова совсем. Но вот когда не дай Бог пожар - без огнетушителя вообще никак.
Алгоритмы по сути исходят из концепции того, что если человек умеет решать алгоритмы, то он имеет неплохую мат базу и способен решать другие задачи
Однако под этим лозунгом на собесах слишком их пропушивают уж слишком много. По итогу мы имеем олимпиадников, которые знают только яп, и они решают такие задачи, и реального разраба, имеющего за плечами годы прохождения и огня, и воды, но не способного решить и medium задачи с литкода. Кого вы возьмёте на работу?
Весь смысл - понимать почему какой-то алгоритм быстрее другого, чтобы в какой-то неординарной ситуации применить другой алгоритм вместо стандартного. А чтобы это знать нужно знать сам алгоритм.
Думаю, начинать надо с принципа работы полевого транзистора. Это же основа всего, на чем, в основном, крутятся ваши/наши программы!
Проблема в том, что задачи на алгоритмы решают одну и только одну задачу: отсеять тех, кто не потратил 100-500 часов на эти алгоритмы. В 99,9% случаев фронтендеру не понадобятся графовые алгоритмы, а бэкендеру не придется merge sort реализовывать.
Думаю, начинать надо с принципа работы полевого транзистора. Это же основа всего, на чем, в основном, крутятся ваши/наши программы!
Я тут общался с коллегами которые занимаются железом узнал много нового как измерять потребление ресурсов на многоядерном процессоре. Между транзисторами и программой тоже много чего происходит.
Проблема в том, что задачи на алгоритмы решают одну и только одну задачу: отсеять тех, кто не потратил 100-500 часов на эти алгоритмы.
Они находят людей которые увлечены или готовы тратить время для достижения цели. Когда у тебя очередь из кандидатов такой отбор вполне неплох.
Для 99% это даже вредно, важнее изучать клиникод и практики промышленного программирования. На поделки алгоритмистов и олимпиадников можно посмотреть на примере любой sdk от Яндекса, и понять насколько это зло упарываться в алгоритмы. Можно просто сравнить их поделки с любой sdk от международного вендора, где люди в первую очередь думают сначала головой и то как люди будут использовать их продукт, а во вторую очередь уже про алгоритмы и оптимизации.
Технические вопросы на собесах позволяют оценить уровень технической интеллигентности собеседуемого.
На мой взгляд знание алгоритмов и непосредственно сам опыт написание программ, это все таки несколько разные вещи, которые развиваются параллельно друг другу. Главное, чтобы одно другому не мешало, а то может возникнуть ситуация, когда какой-нибудь олимпиадник с кучей золотых медалей, который знает все самые сложные алгоритмы и высшую математику с трудом может написать программу сложнее чем Hello world:)
Поделюсь своими соображениями.
Основные сложности с алгоритмами - непонимание самого термина "алгоритм". Под этим термином скрывается целый ряд связанных, но разных понятий.
Так, есть понятие алгоритма как некой задачи. Что-то отсортировать, найти и тд. Например, задача Флавия или поиск путей коммевояжера.
Есть понятие алгоритма как некого приёма решения задач, паттерна. Сортировки, поиски, динамическое программирование, реккрсии, метод двух указателей и тд.
Одну и туже задачу можно решить разными способами. Например, кучей if/else, циклами и кучей временных переменных. Что может работать хорошо или плохо.
Туже задачу можно решить с помощью метода рекурсии. При этом решение может быть (и скорее всего будет лаконичнее). Но при этом может быть дольше.
Я так и не понял в сколько проектах автор успел поработать за 4 года
Проблема не в том, нужны или не нужны алгоритмы, а в том, что в России нет развитой айтишной школы, как в США. Нет того уровня образования (как в Калтехе, к примеру). То, что есть сейчас - это прям скажем, беда. Натягивание советской школы на новые реалии. Настолько, что Яндекс даже создает свои учебные заведения, чтобы получить хоть каких-то вменяемых специалистов.
А точно ли программистам не нужны алгоритмы?