Сама постановка такого вопроса в корне не верна. Количество специальностей в индустрии растёт постоянно, и человек, который пишет сайты на .net будет заниматься совсем другими вещами, нежели человек, пишущий драйвера для сенсоров на ARM архитектуре под экзотической ОС. Давайте прежде всего определим, что же такое алгоритм. Неформально Кормен определяет алгоритм как строго определённую процедуру, которая принимает одно или несколько значений как ввод, и возвращает одно или несколько значений как результат. Формально алгоритм определяется в разных моделях вычислений: операции, которые можно выполнить на машине Тьюринга или с помощью лямбда-исчислений. Таким образом фактически любой код, который что-то делает, является алгоритмом. Получается, что вопрос «нужны ли программисту алгоритмы» можно перевести как «нужно ли программисту уметь писать код». Правильно такой вопрос должен звучать что-то вроде: «нужно ли программисту в отрасли Х знать продвинутые алгоритмы и детали теории вычислений».
Если посмотреть на все эти статьи, то можно заметить, что люди, которые их пишут, фактически обижены на университеты за то, что их заставили учить много сложного материала — в виде алгоритмического анализа, сложных алгоритмов и структур данных — который им вроде бы не пригодился. По сути, авторы статей обижены на университеты из-за того, что там не смогли предсказать будущую область работы авторов и дать им только минимально нужный набор навыков. Ведь действительно, чтобы писать простенькие сайты и скрипты, не нужно особого знания алгоритмов и структур данных. Или всё-таки нужно?
Давайте подумаем, что же нужно учить программисту в университете, для того чтобы приобрести необходимые навыки для успешной карьеры. Библиотеки? Фреймворки? Они устаревают, интерфейсы к ним меняются, все они написаны чаще всего под один язык, который студенты могут и не использовать никогда в индустрии. Всех учить писать сайты? Или всех учить писать ОС? Образование должно охватывать как можно большую аудиторию и давать максимально возможный набор навыков. Программист в первую очередь должен уметь анализировать и решать проблемы – это основной навык, которым должны обзавестись выпускники факультетов информатики. Написание кода – это просто необходимый инструмент, который используется для решения задач. Кто может знать какие навыки вам понадобятся в будущем? Таким образом учить теорию – это наиболее оптимально с точки зрения образования. Полученные навыки можно применить в любой области, а выучить библиотеку или фреймворк имея хорошую базу знаний не составит большого труда. Парадоксально то, что люди задающие вопросы про нужность алгоритмов, как правило имеют какие-то знания в этой области. Я не помню ни одного человека, который не имел знаний в области теории вычислений, и с гордостью кричал об этом, утверждая, что ему они не нужны.
Итак, вы абстрактный программист в вакууме, работаете десять с лишним лет клепая сайты и решая простые однотипные задачи клиентов/компании. Вам хорошо и уютно в вашей нише, и только мучительно больно за бесцельно потраченное время в классе по теории вычислений и алгоритмическому анализу, который вам ничего не дал. По утрам закуривая сигарету за чашкой кофе, в глубине философских размышлений о бренности бытия вы задумываетесь: зачем же программистам, не решающим сложных задач, знать алгоритмы и основы анализа. Короткий ответ: чтобы быть квалифицированным специалистом и эффективно использовать доступные инструменты, включая язык, на котором вы пишите. Теория алгоритмов и анализа учит не только экзотические алгоритмы и структуры данных в виде АВЛ и красно-чёрных деревьев. Она также даёт представления о том, как эффективно организовать данные, как писать код с максимальной производительностью, где в системе возможно бутылочное горлышко и как с ним бороться. Вас ознакамливают с готовыми решениями, чтобы вы не писали велосипедов, и не бежали в гугл каждый раз, когда нужно сделать что-то нетривиальное.
Знания теории анализа и алгоритмов применяются всеми программистами на самом деле каждый день, просто мы привыкли к этим вещам настолько, что даже не задумываемся над этим. Какую бы задачу вы не решали – будь то простой сайт с выборкой данных из БД, или баш скрипт на сервере, вы будете использовать какие-то структуры данных. Как минимум примитивный массив, а скорее всего и что-то посложнее. Языки дают нам множество различных структур, многие из которых взаимозаменяемы. Часто мы имеем несколько вариаций одного абстрактного типа с разными реализациями. Например, в С++ есть структуры данных vector и list. Чем они отличаются, и какие будут преимущества и недостатки использования одного или другого? Как в С++ реализована map, и чем она отличается от multimap? Как реализован list в Python – через массив или связным списком и как лучше всего с ним работать? Почему в C# нежелательно использовать ArrayList, а вместо него использовать List? Как реализован SortedDictionary и как он повлияет на исполнение программы если будет использован вместо Dictionary? Как работает continuation, когда её нужно использовать, и будут ли какие-то побочные эффекты при её использовании? Когда вы в последний раз использовали каррированные функции, которые есть почти в каждом языке? Если вы думаете, что map в С++ реализована как хэш-таблица, вы ошибаетесь. Она реализована на красно-чёрных деревьях, а хэш-таблицей реализована unordered_map. Отдельно стоит упомянуть динамическое программирование. Понимание что это такое, как можно оптимально переписать рекурсивные функции и что такое мемоизация, часто поможет избежать выстрела себе в ногу. Таким образом просто чтобы полноценно и эффективно использовать язык, на котором вы пишите, уже нужно иметь хотя бы поверхностные знания о структурах данных, что они из себя представляют, и как могут повлиять на исполнение вашей программы.
А как же библиотеки? Ведь они решают столько задач! Чтобы рационально использовать библиотеки, их тоже нужно понимать. Во-первых, функции в библиотеки могут иметь побочные эффекты или поведение, которые вы не будете знать без понимания алгоритмов. Получив баг в таком случае можно долго и упорно пытаться его поймать и решить, когда можно было избежать. Во-вторых, различные инструменты и библиотеки часто нужно «настраивать» — говорить им какие алгоритмы, структуры данных и технологии использовать внутри. Без элементарных знаний вам придётся либо идти читать маны, либо выбирать наугад. В-третьих – есть множество задач, которые нельзя решить простым вызовом API библиотеки или фреймворка. Что вы будете делать в таком случае? Тратить часы на поиски возможных решений и просить помощи у друга? В-четвёртых – множество задач решается очень просто несколькими строчками кода или встроенными средствами языка. Если для решения каждого чиха вы будете тянуть библиотеку, то ваши программы будут гигантскими монстрами, занимая по сотни мегабайт и больше на диске, отжирая всю память на сервере, и при том имея довольно скудный функционал. Кроме того, наличие кучи подключенных библиотек влечёт за собой проблемы совместимости, и программа может падать случайным образом из-за странного поведения нескольких библиотек в одном проекте. Бездумное использование библиотек может привести к довольно плачевным последствиям, и разработчики, которые умеют только использовать библиотеки, но не способны решить даже простую проблему самостоятельно, никогда не будут ценится, потому что их решения будут неконкурентоспособны.
Со мной работал один программист со стажем больше десяти лет. Однажды нам понадобилась функция, которую использованная нами библиотека на тот момент не поддерживала: примитивный text-wrap в одном из визуальных компонентов. Этот «программист» посмотрел, что стандартными средствами это сделать нельзя, и сразу заявил, что реализация такой функции невозможна. Задачу решил интерн-третьекурсник с аналитическим мозгом, который за два часа написал простой алгоритм и внедрил его в нужный компонент. Другой проект в виде сайта на .net мне достался по наследству. Главная страничка представляла собой несколько маленьких графиков, и загружалась почти 10 секунд. Оказалось, что человек, который изначально делал этот проект, нагородил кучу ужасных конструкций из тройных вложенных циклов, которые долго и печально забирали данные из БД, и потом привязывали их к графикам. После небольшого рефакторинга страница стала грузится почти мгновенно.
Может ли программист обойтись без знаний алгоритмов и теории анализа? Может, и таких «программистов» очень много. Только назвать их программистами можно разве что с большой натяжкой. Ко мне на собеседование приходит очень много программистов, со стажем десять-пятнадцать лет, и толком не понимающих что же они делают и почему. У них своя ниша, они ходят от компании к компании, не задерживаясь в них больше года. Как правило, у них есть небольшой набор задач, которые они могут решать, и если сделать шаг в сторону, то человек теряется и ему нужно обучить себя новым навыкам. Таких людей приглашают на проект, и от них избавляются как можно быстрее, потому что они теряют кучу времени, изобретая велосипеды и читая маны чтобы узнать то, что уже должны были знать из университета. У них как правило нет особо никакой карьеры и нестабильный заработок.
В итоге, для чего нужно знать алгоритмы и теорию анализа, если можно выполнять работу и без этих знаний? Чтобы быть квалифицированным специалистом в своей профессии, иметь карьерный рост и уважение коллег. Чтобы эффективно решать поставленные задачи и не изобретать велосипедов. Чтобы не писать монстров с огромным количеством сторонних библиотек, которые занимают сотни мегабайт на диске от отжирают кучу памяти на сервере и регулярно падают по случайной причине в зависимости от фазы луны. Чтобы эффективно и с максимальными возможностями использовать язык, на которым вы пишете. Чтобы принимать информированные и осмысленные решения по выбору библиотеки и технологии для решения проблемы. Если же ваша работа заключается в написание SQL запроса и вбивание команды в консоль, то хочу вас огорчить: вы не программист, вы – пользователь, вам действительно не нужны алгоритмы и иже с ним, и вы зря потратили время в университете потому что для такой работы достаточно закончить курсы или прочитать пару вводных книжек самостоятельно.
Комментарии (150)
xwild
16.03.2016 18:19+12На практике я бы сказал что нужно не само глубокое знание большого числа алгоритмов, а базовое понимание и знание что он существует, чтобы можно было его найти и реализовать.
Это кстати относится вообще ко всей области программирования, она стала слишком велика чтобы "знать всё".
К сайтам и SQL вы погорячились, мне например недавно понадобилась комбинаторика (сочетания) для обычного интернет магазина, не бог весть что, но все таки, а от некоторых SQL запросов мозг сносит, sql-ex.ru объяснит что SQL бывает суровым.sgrey
16.03.2016 21:42Глубокое знание может и не нужно, но общее понимание и знание что делает конкретный алгоритм, для чего можно использовать конкретную структуру данных — нужны. А если придётся реализовать что-то конкретное для своих целей, то всегда можно посмотреть литературу для деталей.
Вообще я не утверждал что-либо про SQL. Да и запрос запросу рознь. Можно писать запросы в пару строк из двух-трёх таблиц, а можно создавать SSIS пакеты, которые будет собирать и фильтровать данные из трёх разных баз данных на разных движках. У меня на работе SQL запрос на 6 экранов — норма, и они запускаются по ночам только, ибо исполняются по несколько часов. Да и чтобы знать конкретный движок БД хорошо — надо приложить усилия.
А как вам понадобилась комбинаторика для интернет-магазина?xwild
17.03.2016 05:16+1В этом магазине почти все товары сгруппированы, например есть трубы, 10 видов, у них 5 атрибутов: материал, длина, диаметр, толщина стенки и т.д.
Покупатель сначала видит просто товар "Трубы" и 5 select'ов которыми он выбирает нужный вариант, при выборе первого атрибута остальные соответственно фильтруются, чтобы показать возможные оставшиеся варианты.
Заказчик захотел, чтобы у некоторых товаров выбор стал минимальным, то есть например: материал, длина и толщина стенки однозначно определяют все 10 вариантов труб, значит выбирать диаметр не нужно и можно просто убрать этот select и вместо него показывать значение.
Чтобы найти этот набор атрибутов нужно перебрать все сочетания из n по k, вариантов может быть несколько и тут еще нужен вес атрибута, чтобы оставить для выбора более важные атрибуты (наибольший суммарный вес набора атрибутов).
Я кстати был очень рад что в python есть itertools.combinations, чтобы не писать алгоритм сочетаний самому :)
leremin
16.03.2016 18:19+4Немного не по теме. Скажу за математику/физику и т.д. в предметной области. Вы предпочтете пользоваться программой написанной экспертом в предметной области (глючной, неудобной, медленной) или написанной программистом, который написал ее, консультируясь с предметниками, но которая удобная и понятная? С программами первого рода я сталкиваюсь постоянно — пользоваться ими невозможно: абсолютно интуитивно-непонятный интерфейс, какие-то баги, полная непродуманность функционала и т.д… А уж по их коду можно проводить лекции "Как не нужно писать". Только не надо писать про уникумов, который и там, и тут поспели — их мало.
А со статьей — согласен. И пускай лучше программист безупречно разбирается в этом, а третий закон Ньютона можно и у физика спросить.
lair
16.03.2016 18:30+3В большей части виденных мной случаев своим удобством программа обязана не программистам (эти как раз обычно порождают неочевидные для всех остальных интерфейсы) — это достижение либо предметников, либо аналитиков, либо, если повезло, UX-дизайнера. То же относится и к функциональности — как раз эксперту в предметной области виднее, какая функциональность нужна, нежели аналитику.
Так что странный у вас пример.leremin
16.03.2016 18:58+1как раз эксперту в предметной области виднее, какая функциональность нужна, нежели аналитику
Да, а потом 90% функций никогда не используются. Мы оба какие-то свои частные случаи рассматриваем, поэтому спор бессмыслен.lair
16.03.2016 19:00Я, на самом деле, ошибся во фразе, на которую вы отвечаете. Правильно так: "эксперту виднее [...], чем программисту, а еще лучше использовать для этих целей аналитика".
sgrey
16.03.2016 21:46Я думаю понимаю о чём вы говорите. Есть много инструментов, которые создаются учёными в процессе исследований, и они частенько утекают в таком виде без изменений в общий доступ. Такие программы действительно неудобны, но не потому что те кто их написал — плохие программисты, а потому что писали они имея в голове модель эксперта в качестве пользователя. Плюс удобство установки на разные ОС тоже не предусматривалась. А если человек работал в индустрии, то он больше ориентирован на пользователей, и вопросы удобства использования программы у него на уровне инстниктов.
neit_kas
16.03.2016 22:33Также добавлю, что если изначально не предполагается утекание программы, дружелюбный интерфейс намеренно могут не городить из-за экономии времени.
amaksr
16.03.2016 18:32+2Программирование еще пока не имеет формальных градаций, в отличие от других профессий. Например, у врачей и учителей есть категории, у слесарей есть разряды, и т.п. Программирование же молодо, поэтому стандартов нет, и поэтому каждый придумывает свои критерии оценки, кто во что горазд. Кто-то на собеседованиях спрашивает про форму люков, кто-то про бинарные деревья, а кто-то заставляет гуглить и писать на заведомо незнакомом языке (ну типа оценить как быстро кандидат может находить информацию). Но если смотреть на тех же слесарей, например, то на заводе слесарь 1-го разряда делает свою работу, а 6-го — свою. Так же и в программировании: есть 90% рутинных простых работ, для которых достаточно программиста 1..4-го разряда, а есть 10% нетривиальных задач, где понадобятся совместные усилия программиста 6 разряда, архитектора, бизнес-аналитика и прочих начальников. Для задач уровня 1-го разряда знание алгоритмов не обязательно, а 6-го — обязательно, но не достаточно.
sgrey
16.03.2016 21:54Узнать уровень соискателя на собеседовании довольно нетривиальная задача. Вопросы про теорию можно зазубрить не понимая, часто задаваемые вопросы тоже можно нагуглить. У меня были соискатели, которые вроде бы отвечали на вопросы неплохо, имели опыт, а как за дело браться — понимания ноль, и по малейшему чиху — в гугл. Простейший проект пишется месяцами, и по завершению случайным образом постоянно падает.
Обычно я смотрю что соискатель делал на предыдущем месте работы, и задаю вопросы на понимание того, что он делал, какие технологии использовал, какую роль играл в проэкте. Если человек не путается, то можно углубится в теорию.neit_kas
16.03.2016 22:36А если соискателем является студент?
sgrey
16.03.2016 22:41+3У нас контракт с местными университетами и мы часто принимаем студентов на прохождение интернатуры. Студентов я опрашиваю в зависимости от курса и от указанных в резюме навыков. Их больше по теории гоняю, ибо практики мало. Но тоже акцент больше на понимание теории, чем на зубрение деталей. Часто студенты делают интересные проекты в университете или для удовольствия, тогда спрашиваю детали про них.
samo-delkin
20.03.2016 04:04Часто студенты делают интересные проекты в университете или для удовольствия
Кстати, Gimp — как раз такой проект. Если сравнивать с фотошопом, очень бросается в глаза разница. Фотошоп делали, чтобы он продавался. Джимп (гимп) делали, чтобы он был удобным и максимально функциональным. Вот у меня фотошопа нет, потому что я всё рисую в Gimp'е (картинки для приложений).sgrey
20.03.2016 04:29+2Gimp конечно классная вещь, если ничего другого не иметь, но фотошоп давно ушёл далеко вперёд и по функционалу и удобству. Особенно в плане удобства open source к сожалению чаще отстаёт от коммерческого софта, хотя свои проблемы есть везде
khim
20.03.2016 16:12+3GIMP — это вообще классический антипример.
Во-первых те два чувака, которые начали пилить его в Универе его бросили.
Во-вторых по удобству он очень сильно отстаёт от Photoshop'а. Пример, который, насколько я знаю до сих пор актуален: когда я хочу "подправить" слой, чтобы он точнее попал в другой я делаю его полупрозрачным и после этого изменяю — перспектива или сдвиг — и вот именно в этот момент в GIMP'е полупрозрачность исчезает.
И, наконец, в-третьих (тесно связанное с "во-вторых"): хотя пользователей у GIMPа довольно много пилят его до сих пор два с половиной разработчика. Ибо большинство пользователей не умеют программировать (они ж художники, а не программисты)! В результате описанная мною проблема до сих пор актуальна. Заметим что последняя (на момент появления GIMP'а) версия Photoshop'а тоже так не умела — чтобы такие трюки поддержвать требуется довольно нехилый редизайн внутренней архитектуры. Photoshop его проделал, если мне не изменяет память, в версии 6.0 (2000й год), GIMP… GIMP всё ещё "в процессе".
В мире, который воображал себе Столлман (где все или почти все пользователи компьютеров — программисты), свободное ПО, конечно, "всех поборет". Но в нашем мире подавляющий процент пользователей о программировании понятия не имеет и не собирается иметь!
Zealint
16.03.2016 18:43+22Я во многом согласился бы с автором, точнее, мне хочется согласиться, но моё согласие будет не совсем честным и предвзятым, потому что здесь, как и в других подобных статьях, допускается та же самая неточность. Слово "программист" уже много лет назад потеряло свой первоначальный смысл. Когда я учился в школе, в младших классах, этим словом у нас называли математиков, владеющих программированием. Да, там предполагалось, что программист в первую очередь математик.
Сейчас ситуация иная. Спрашивать, должен ли программист изучать алгоритмы это всё равно что спрашивать, должен ли автолюбитель уметь управлять троллейбусом или автопоездом, когда он ездит только на своей легковушке. Общий принцип, да, он знать худо бедно должен (нужно крутить руль, есть какие-то педали), но уметь управлять — это ему не нужно. Программисты бывают разные, направлений очень много и нужно всегда конкретно уточнять, каких именно программистов мы имеем в виду. Спортивный программист обязан знать от полусотни (в моё время) до полутора сотен (сейчас) различных алгоритмов (понятно, что какие-то из них будут для одной и той же задачи), но даже ему зачастую не нужны строгие доказательства их работы. Разработчику библиотек и низкоуровневых функций вроде меня нужно обязательно знать не только весь классический репертуар алгоритмов, но и все математические основы, в них лежащие, ещё мы обязаны иногда уметь сочинять свои методы и доказательства. Программисту на html (в прошлом) или на php (сейчас) нужно великолепно знать сам язык, его возможности и особенности всех функций и библиотек для разных случаев. Это тоже немалый труд — всё это изучить и правильно использовать. Минимальная культура, которая не позволит такому программисту написать, как вы сказали, тройной цикл, конечно должна быть, я не спорю. Но знать алгоритмы длинной арифметики ему нафиг не надо. И это правильно.
Таким образом, я против подобных вопросов вообще. Не нужно спрашивать, нужны ли алгоритмы программисту. Нужно в каждом конкретном случае спрашивать конкретные задачи, связанные с теми, что ему придётся решать на работе. Великолепный программист на php, знающий при этом perl, Pуthon что-нибудь такое, но не могущий реализовать heapsort, будет гораздо востребованнее, скажем, меня, кто с "закрытыми глазами" пишет венгерский метод или декартово дерево, но совершенно не рубит, как оптимально написать что-то на PHP, чтобы сайт не тормозил. Понимаете? Каждому своё.
Есть круг задач, человек либо решает задачи из этого круга и подходит под условия работодателя и каких-то реалий, либо нет. Но проводить демаркационную линию по принципу "знает алгоритмы" / "не знает алгоритмы" — это бесполезная трата времени как с теоретической, так и с практической точки зрения. Эта линия ни о чём не говорит.
Хотя я, конечно, хотел бы, чтобы для повышения общей культуры все программисты (в том числе кодеры) знали некий минимальный набор алгоритмов, просто чтобы хотя бы понимать друг друга, работая в команде с теми, кто реализует эти самые boost, stl, gmp и т. д. Ну а алгоритмисты вроде меня должны тоже приблизительно знать методологии и инструменты IT-сферы. Скажем, простенький сайт на PHP я напишу, но если нужно будет что-то серьёзное, я всегда посоветуюсь с профессионалом. Мало ли, какие подводные камни есть. И он, профессионал, пойдёт в первую очередь ко мне, когда ему понадобится отлавливать баги в плавающей арифметики на PHP.khim
16.03.2016 19:07+5И он, профессионал, пойдёт в первую очередь ко мне, когда ему понадобится отлавливать баги в плавающей арифметики на PHP.
В том-то и дело, что не пойдёт. Замена циклов на один SQL-запрос — это впечатляющий пример, но я сталкивался с ещё более впечатляющим: с заменой SQL запроса на тройной вложенный цикл — и получением при этом многократного ускорения! На PHP, да.
Не буду сейчас вдаваться в подробности, но SQL-запрос отрабатывал ~10секунд потому, что в системе была куча хитрых связей между таблицами. Я же заметил, что во всех этих таблицах суммарно лежал мегабайт данных — и просто «забрал» его себе. Тупо. Через три «select *»а. Потом просто прошёлся по таблицам в памяти и выбрал нужные мне данные. А «профессионалы», работающие на PHP и «оптимизаторы SQL» даже не задумывались над тем, что это возможно. Они «планы запросов» изучали. И понять, что там запросов просто тупо много — им оказалось не дано.
Вот именно в этом объёме и нужно знать «алгоритмы», даже если вы всю жизнь собрались провести клепая сайты на PHP. Не для того, чтобы постоянно что-то самому делать — а чтобы понимать когда это делать стоит, а когда — не стоит.
И оказывается что для этого нужно знать алгоритмы на довольно-таки приличном уровне. Даже если вы их сами никогда и не будете реализовывать.Zealint
16.03.2016 19:55-4Примеры, о которых Вы говорите — это не совсем то. Ошибка начинается не в том месте, где кодер начал пытаться придумывать алгоритм, а в том, что в проекте (в спецификации) изначально не было объяснено, что делать. Кодер — исполнитель, он должен первоклассно исполнять. А каков алгоритм — это за него должен был придумать разработчик спецификации, по которой делается проект, точнее даже не он, а математик, продумывающий глубокие схемы взаимодействия всех элементов. Если нет спецификации, то значит сам по себе проект проектируется неправильно. То есть ошибка в распределении ролей и вообще в подходе к проектированию. Алгоритмы должны придумывать и писать профессионалы в этой области. Уверен, что при таком подходе программа летала бы ещё быстрее. Короче, каждый должен заниматься своим делом. В ответственном проекте к разработке алгоритма я не допустил бы ни того кодера, который не понимает алгоритмы, ни того, который их хорошо понимает. Почему?
Потому что всё равно он их понимает хуже, чем профессионал в области разработки алгоритмов. Поэтому без разницы, знает человек алгоритмы или нет — это не критерий чего бы то ни было. Хотя мне всегда хочется, чтобы знал. Просто обычно есть корреляция между качеством кода и пониманием алгоритмов, но корреляция не означает прямую зависимость.khim
16.03.2016 21:49+4Ошибка начинается не в том месте, где кодер начал пытаться придумывать алгоритм, а в том, что в проекте (в спецификации) изначально не было объяснено, что делать. Кодер — исполнитель, он должен первоклассно исполнять. А каков алгоритм — это за него должен был придумать разработчик спецификации, по которой делается проект, точнее даже не он, а математик, продумывающий глубокие схемы взаимодействия всех элементов. Если нет спецификации, то значит сам по себе проект проектируется неправильно.
Мне кажется вы сейчас о каком-то другом мире говорите.
Если вы о внутреннем/консультационном ПО, то да, в принципе я готов с вами согласиться. С тем только отличием, что тут вообще знание алгоритмов никому нафиг не нужно в 99% случаев — проблемы возникают только тогда, когда их незнание приводит к тому, что созданная вами система не работает вообще.
Если вы про мир ширпотреба — то я не знаю ни одной разработки, которая была бы сделана подобным способом от начала и конца — и при этом попала бы не в учебники истории, а на столы к пользователям. Просто потому что для того, чтобы «выдать кому-то» алгоритмические проблемы они должны быть известны заранее — а понять где они случатся даже в не очень большой программе на пару миллионов строк очень тяжело (а если у вас программа меньше — то где вы найдёте денег на построение всей вашей цепочки с аналитиками и кодерами?).neit_kas
16.03.2016 23:11Тут опять таки возвращаемся к вопросу о том, какие алгоритмы. Например:
- Расчёт траектории нейтрона в хитропеременном магнитном поле
- Сортировка
- Вызов процедур в необходимом порядке
Для каждого пункта требуется какой-то алгоритм, но что касается первого — это задача явно не программиста. Второй пункт — я бы сказал, рекомендовано, но не обязательно, т.к. есть готовые функции во многих языках. Третий — само собой разумеется.khim
16.03.2016 23:35+1Для каждого пункта требуется какой-то алгоритм, но что касается первого — это задача явно не программиста.
Какой нафиг «алгоритм расчёт траектории нейтрона»? Тут физика нужна. А вот когда у вас уже есть программа, которая что-то там как-то рассчитывает в малых масштабах — тут уже потребуются и работа программиста. Причём алгоритмы там будут самые банальные, но когда вы обрабатываете сотни петабайт, то… нет, скриптиком для PHP не обойтись.neit_kas
16.03.2016 23:47Собственно об этом и говорил. С физикой может пример не удачный (плюс косяк с нейтроном). Хотел сказать, что есть алгоритмы, которые действительно лучше напишет профессионал в конкретной области, отличной от программирования. А есть довольно обыденные, которые как раз являются задачей программиста.
khim
17.03.2016 00:08+1Хотел сказать, что есть алгоритмы, которые действительно лучше напишет профессионал в конкретной области, отличной от программирования.
Не бывает так, извините.
Задача «профессионала в конкретной области» — описать решение задачи. Когда в виде формул, когда на словах, когда и в виде программы. По разному бывает. Но то, что он сделает будет «ужасом летящим на крыльях ночи» в 10 случаях из 10.
Дальше — вопрос простой: можно этим чудом вообще пользоваться или нет? Если оно отрабывается за 10 минут и запускается раз в сутки — то так важно ли, что после переписывания его со знанием алгоритмов и структур данных, оно станет работать полсекунды или нет?
Если «такого» больше ни у кого нет или такое больше никому не нужно — то на этом, собственно, и всё. А если у вас есть конкуренты — то придётся-таки привлекать программистов, ничего не поделать.
Но вот беда: если у вас есть конкуренты, то у вас не полутся всё сделать «правильно». Иначе выйдет у вас Windows Phone. Которая по многим показателям лучше, чем Android и iOS (есть кое-какие косяки в интерфейсе, но на уровне системы — она гораздо правильнее спроектирована и сделана), но… труп. Причём давно уже труп. Уже в 2010м она была полутрупом, а в 2012м её уже можно было хоронить без всяких обсуждений. Просто потому что не была готова. Именно потому что её делали по описанной схеме — а значит просто банально делали дольше. Да, в ней нет многих косяков (к примеру изначально у программ нет простого дуступа к системным библиотекам, что в iOS решили постылём в виде AppStore'а, а Android'е Google теперь выдавливает «по капле») — но какая, нафиг, разница есть «пациент мёртв»?neit_kas
17.03.2016 00:30Ну, возразить мне нечего. Единственное, получается пришли к забавному выводу: программирование — это та редкая область, где конкуренция убивает продукт.
khim
17.03.2016 00:51+1Вывод неверный. Про принцип "Le mieux est Геппепи du bien" (лучшее — врах хорошего) Вольтер ещё четыре сотни лет назад писал. И Закон Парето не вчера придумали.
Но, заметьте, там где конкуренции нет — продукт не лучше! Отнюдь! Если коммерчески успешные продукты — это всегда "ужас", то продукты, созданые в отсутсвие конкуренции — это просто "ужас-ужас-ужас". Вот именно там и тогда, когда вам качество продукта неважно вообще (главное чтобы оно оказалось достаточным для того, чтобы заказчик контракт не разорвал) — и работает подавляющее большинство программистов! Которые искренне уверены, что им знание теории алгоритмов нафиг не нужно — и правы при этом!
А конкуренция — тут важно не только сделать продукт, но и соблюсти баланс между скоростью разработки и качеством результата. Отсюда и возникает потребность в программистах-универсалах, знающих алгоритмы и умеющих кодировать.
Вариант же, когда нужно что-то сделать максимально качественно — он вообще исчезающе редок: в основном там, где что-то худшее просто не работает. Космос, к примеру иногда подобное требует. Но разрабатывать в таком режиме всё? Не получится.neit_kas
17.03.2016 01:04Касательно конкуренции, получается идеальный вариант при умеренной конкуренции. Т.к. при сильной конкуренции опираются на время, а за короткие сроки явно ничего качественного не выйдет (описанный Вами случай в прошлом комментарии), а при слабой проявляются особенности, описанные в учебниках по экономики. Да уж, программирование своеобразная область: баланс наше всё.
Касательно качества, кроме космоса думаю ещё можно встретить в микроконтроллерах, встраиваемых системах и системах на производстве (кстати, там зачастую даже Windows и Linux не доверяют: лично видел современный ЧПУ станок на мебельной фабрике, который работает под DOS).
Mrrl
17.03.2016 09:49+2то так важно ли, что после переписывания его со знанием алгоритмов и структур данных, оно станет работать полсекунды или нет?
И бозон Хиггса будет ловиться не 2 года, а 2000 лет? Да они сами безо всякой конкуренции захотят и с алгоритмистами, и с программистами сотрудничать в лучшем виде.khim
17.03.2016 17:43-1На один ЦЕРН, где ловят бозон, приходится 100500 контор, которых вполне устроит изделие, открывающее свои окошки по 5-10 минут. Можно подумать вы никогда не наблюдали как работают все эти системы. Что на приёме у врача, что в банке. Могли бы работать миллисекунды, а работают минуты — и всем пофиг: девочка-оператор быстро учится запускать программу до начала разговора с клиентом и всё. Делов-то.
neit_kas
18.03.2016 19:15Честно говоря, обхожу стороной такие программы. Я думаю и девочке-оператору не пофиг (по крайней мере, всем моим знакомым, далёким от IT, не пофиг), просто в уши надули, что это нормально, что оборудование старое. По незнанию она и поверила. Но в любом случае, тормозящая программа выводит. Поэтому до сих пор пользуюсь древними IDE. Я понимаю, что это не есть нормально, и что при трудоустройстве в какую-либо контору, придётся пересесть на что-то современное, но я очень надеюсь этим современным будет mingw, clang или что-то подобное с легковесной и шустрой IDE.
khim
18.03.2016 22:55"Всем" — это всем тем, кто заведует распределением денежных потоков в данном случае.
Оттого, что "девушка оператор" ждёт и нервничает затрат особо больше не становится: она могла бы выполнять свою задачу за минуту вместо пяти, но если замедление работы не настолько значительно, чтобы создавать очереди, то экономии от более грамотно написанной программы не будет.
А вот затраты на то, чтобы взять более качественного программиста и дать ему больше времени — вот они, легко считаются.
И с тормозящими IDE то же самое: я предпочитаю работать в мнее мощных, но более быстрых IDE, но я прекрасно понимаю почему современные монстры так популярны: они, опять-таки, позволяют взять более дешёвых программистов, а стало быть — приводят к прямой экономии.
Увы, но это не только ПО касается.neit_kas
19.03.2016 03:19Всё же, например, сравнивая отделение Сбербанка и отделение Почты России, прихожу к выводу, что более солидные компании заказывают/покупают более солидное ПО и технику (в т.ч. менее тормозящее).
Mrrl
17.03.2016 09:28Сначала физика. Потом анализ задачи численными методами. Потом возвращаемся к физику, выясняем возможные инварианты, гладкость поля в пространстве и времени… Потом выбираем несколько численных моделей. Идём к программисту, спрашиваем, что он про них думает — в смысле эффективности, памяти, реализуемости вообще. Возможно, потребуется несколько итераций. После чего программист, зная повадки машины, превращает алгоритм в программу, и наконец, вычисляет эту траекторию.
ewgRa
16.03.2016 21:35+3А потом система ушла в продакшн, данных стало не мегабайт а под сотню, и вдруг сетка чего-то стала загружена, и вдруг памяти стало не хватать. И приходит другой программист, смотрит на ваше решение и вы икаете.
Я не верю что три таблицы суммарно мегабайт весом нельзя взять запросом, да еще и чтобы построить какой-то график. Как бы там запросы тоже по собой имеют по сути все те же алгоритмы.khim
16.03.2016 21:56+1Я не верю что три таблицы суммарно мегабайт весом нельзя взять запросом, да еще и чтобы построить какой-то график.
Это была сложная иерархическая система, описывающая хранение книг в разных подразделениях. С кучей дополнительной информации. А реализована она была в виде списка (то ещё решение, конечно — но уж как было, так было): в записи про книгу была ссылка на ID следующей за ней книги.
А потом система ушла в продакшн, данных стало не мегабайт а под сотню, и вдруг сетка чего-то стала загружена, и вдруг памяти стало не хватать.
А вот тут — уже нужно знание предметной области. Да, можно себе представить что вместо 10'000 позиций на складе появится 100'000. Легко. А вот больше — маловероятно. Куда они их складывать-то будут?
P.S. Только не надо рассказывать про то, что данные о книгах так в базах данных не хранят. Я знаю. А вот те, кто создали эту базу, похоже, не догадавались. На 100 книгах на тестах оно отлично работало.
sgrey
16.03.2016 22:02По-моему вы как-то пропустили суть статьи.
Вообще-то раньше программирования как дисциплины не существало, а писали код не только математики, но и инженеры. Слово программист означает тех, кто зарабатывает на жизнь написанием программ. Другого обозначения этой категории людей как-бы и нет.
RouR
16.03.2016 22:35Вы уже несколько раз отвечаете на комментарии в духе "вы не поняли/не читали статью".
Корень разногласия, на мой взгляд, в вашей фразе«нужны ли программисту алгоритмы» можно перевести как «нужно ли программисту уметь писать код»
Может быть вы лично так и понимаете эту фразу. Большинство же понимает, что вопрос важен лишь как "надо ли спрашивать на собеседовании про алгоритмы" и отвечают вам про "(наизусть) знать не надо, надо будет — погуглю".sgrey
16.03.2016 22:43Вполне вероятно что многие это так и понимают, но ведь статья-то не об этом. А комментирую я этим вопросом когда мне кажется что автор комментария не понял того, что я хотел сказать в статье.
Zealint
17.03.2016 08:45+4Я очень хорошо понял суть этой статьи и ещё десятка подобных ей. И мой общий вывод — демаркация по признаку знания алгоритмов не имеет смысла.
Не важно, существовала раньше дисциплина или нет, это формальность, важно знать, кто назывался программистом раньше и кто называется этим словом сейчас. И станет понятным корень вопроса этой статьи и правильный ответ на него. Правильный ответ такой: постановка вопроса не верна в корне. Максимум, что можно сказать: любой уважающий себя программист должен максимально повышать свою культуру настолько, чтобы успешно и качественно решать свои задачи, задачи из его области и желательно из непосредственно смежных с ней.
Мне встречались люди, которые не знали алгоритмов, но они могли их изобретать. Как-то раз один из них заново изобрёл венгерский метод, не зная о нём раньше. Затем, естественно, он всё-таки научился читать учебники, но его исходное состояние не знающего алгоритмы человека не делало его непригодным к работе. А встречались люди, напичканные алгоритмами (спортивные программисты), которые не могли решить практически полезную задачу лучше, чем вот этот изобретатель велосипедов. Всё относительно, нужно делать упор на другие качества программиста, хотя, повторюсь, между знанием алгоритмов и другими хорошими качествами есть корреляция.sgrey
17.03.2016 14:31Я не считаю что "кто назывался программистом ранее, а кто — сейчас" вообще уместно спрашивать. Мы живём сейчас, и надо адресовывать то, что люди понимают сейчас под этим словам.
Умение думать и решать проблемы — основной навык программиста, и алгоритмы как раз учат правильно подходить к решению проблем. А знание известных алгоритмов помогает умным людям не придумывать заного венгерские методы, а на их основе строить более сложные и продвинутые решения :)Zealint
17.03.2016 14:42Данный вопрос про "раньше/сейчас" был поднят как раз для того, чтобы указать на один из корней вопроса, поднимаемого автором статьи. Именно для того, чтобы показать, что мы живём сейчас и сейчас всё иначе. Я показываю, что этот вопрос имел смысл раньше. А сейчас не имеет. Вот и все.
sgrey
17.03.2016 15:31+1Теория вычислений — это основа программирования. Как можно утверждать, что программисту не нужно знать фундамент своей профессии?
Я теперь уверен что вы вообще не читали написанного
khim
17.03.2016 18:20+1Примеры отдельных "уникумов" могут говорить о многом, да. И есть есть — как таких, которые делают гениальные вещи не зная алгоритмов (а изобретая их "на лету"), так и наоборот — знающих алгоритмы, но неспособных написать реальный код.
Но общая статистика проста и незатейлива: люди, имеющием понятие о теории алгоритмов в среднем порождают заметно более качественный код, но дело даже не в этом. Главное: они гораздо реже пишут код, который ставит всю систему "раком" при изменении исходных условий.
Ну а дальше — всё просто: если минута простоя у вас стоит как зарплата прораммиста за год — вам нужны только люди со знанием алгоритмов, если неделю простоя ваша компания может прожить "с бумажкой и ручкой" — то вложения в подобного рода программистов не окупятся...Zealint
17.03.2016 19:24Да, всё верно. Я в целом о том же и говорю. Более того, человек, который умеет изобретать велосипед и часто делает это из-за незнания классической литературы, быстрее переучивается в специалиста высокого класса, нежели напичканный алгоритмами олимпиадник. По крайней мере, в моём опыте такова "незатейливая" статистика. Вот только специалисты такого уровня не шибко-то востребованы. Обычный тяп-ляп-кодер зачатую гораздо быстрее найдёт себе работу. Причины мне неизвестны, но подозреваю, что специалист высокого уровня будет пытаться искать работу себе по уровню и требовать для себя больше благ. Наверно поэтому. Про себя говорить не буду, моя история очень своеобразна.
arielf
17.03.2016 01:14-4оптимально написать что-то на PHP, чтобы сайт не тормози
А это вообще реально?
michael_vostrikov
16.03.2016 19:06чтобы писать простенькие сайты и скрипты, не нужно особого знания алгоритмов и структур данных
А если не простенькие сайты и скрипты? Учетные системы какие-нибудь? Или загрузчик ОС? Или драйвер для FAT или NTFS для этого загрузчика?
Итак, вы абстрактный программист в вакууме, только вам мучительно больно за бесцельно потраченное время в классе по теории вычислений и алгоритмическому анализу, который вам ничего не дал.
Вот давайте не передергивать, уж от программиста-коллеги я бы такого не ожидал. Меня вот не учили алгоритмическому анализу, и до недавнего времени я был не в курсе, что такое O-нотация. Да, вот так, представляете? Такой вот у нас был университет. Да, мы делали реализации списков и деревьев. И я даже сам потом их делал для лабораторных, потому что меня немного пугали километровые объявления шаблонов из STL.
включая язык, на котором вы пишите.
Это вообще прекрасно, я даже не буду это комментировать)
(и это не опечатка, так как 2 раза встречается в тексте статьи)
и не бежали в гугл каждый раз, когда нужно сделать что-то нетривиальное.
Так о том и речь, что нетривиальное в большинстве случаев не требуется.
Какую бы задачу вы не решали – будь то простой сайт с выборкой данных из БД, или баш скрипт на сервере, вы будете использовать какие-то структуры данных.
При этом мне не надо знать, как они работают. Мне надо уметь ими пользоваться.
Почему в C# нежелательно использовать ArrayList, а вместо него использовать List?
Вот если я буду использовать List или ArrayList, и у меня вдруг все будет тормозить, я возьму и поищу информацию об этом. А в задачи, где это надо на этапе проектирования, я не лезу. Да и новичков в компании к таким задачам обычно не подпускают.
В-третьих – есть множество задач, которые нельзя решить простым вызовом API библиотеки или фреймворка. Что вы будете делать в таком случае?
Я, представьте себе, поищу информацию о том, как такие задачи решаются. А если в описании мне будет что-то непонятно, я поищу информацию и об этом.
Если же ваша работа заключается в написание SQL запроса и вбивание команды в консоль, то хочу вас огорчить: вы не программист
Позволю себе дать ссылку на свой же коммент: https://habrahabr.ru/post/279093/#comment_8803823
Вы считаете, что описанные там задачи не требуют навыков программирования?sgrey
16.03.2016 22:12-4Когда человек начинает придираться к опечаткам, это значит что у него нет аргументов для возражения :)
MacIn
16.03.2016 22:23+3Взять из пары десятков строк комментария одну, где речь идет об описке, заострить внимание на ней и отбросить остальное — вот где настоящее мастерство.
sgrey
16.03.2016 22:34На все остальные вопросы ответы в статье
MacIn
16.03.2016 22:42+2Да да, именно поэтому человек написал комментарий-возражение к статье.
sgrey
17.03.2016 02:16-1С удовольствием бы ответил на конструктивную критику, если бы не было продемонстрировано полное непонимание сказанного и вырывание фраз из контекста.
MacIn
17.03.2016 03:37+2Как раз ваш подход не особо конструктивен: "все есть в статье, кто не понял, тот дурак. А все возражения — тоже дурацкие, появились от непонимания статьи".
Некоторые аргументы michael_vostrikov действительно странные, но вовсе не потому, что "ответы уже есть в статье".
Взять например
Так о том и речь, что нетривиальное в большинстве случаев не требуется.
или
Вот если я буду использовать List или ArrayList, и у меня вдруг все будет тормозить, я возьму и поищу информацию об этом. А в задачи, где это надо на этапе проектирования, я не лезу. Да и новичков в компании к таким задачам обычно не подпускают.
Здесь налицо эффект Даннинга-Крюгера/blub paradox, но этого в статье нет.sgrey
17.03.2016 04:02Вся статья как раз о том, зачем нужно знать алгоритмы тем, кому нетривиальное не требуется. Если вам нужно задать этот вопрос, вы меня не поняли :( Вот мой комментарий ниже https://habrahabr.ru/post/279453/#comment_8808393 где я написал краткую суть
На второй вопрос я не ответил потому что не хотел писать то, что написали вы :) Прямого ответа может и нет, но косвенно вопрос о ценности такого специалиста я тоже задел
michael_vostrikov
17.03.2016 07:57+2Для начала надо определиться с терминологией. Под знанием алгоритмов я понимаю знание алгоритмов обработки стандартных структур данных и умение оценивать их сложность в O-нотации — обходы графов, сложность различных сортировок и т.д. Примерно такой же смысл вкладывается авторами статей на эту тему. Насколько я понял, вы в своей статье называете это "детали теории вычислений".
Вся статья как раз о том, зачем нужно знать алгоритмы тем, кому нетривиальное не требуется.
Я говорю о том, что доказательства, приведенные в статье, ничего не доказывают — неправильно объясняют причины и не доказывают необходимость знания алгоритмов для выполнения любых задач.
Вырвал из контекста я те фразы, на основе которых в статье идет дальнейшее доказательство.
бесцельно потраченное время в классе по теории вычислений и алгоритмическому анализу
У вас эта мысль высказывается несколько раз. Я допускаю, что кто-то может быть обижен, но чтобы все "абстрактные программисты"? Поэтому и назвал передергиванием.
Программист в первую очередь должен уметь анализировать и решать проблемы – это основной навык, которым должны обзавестись выпускники факультетов информатики. Написание кода – это просто необходимый инструмент, который используется для решения задач. Таким образом учить теорию – это наиболее оптимально с точки зрения образования.
С первым предложением согласен, но не понимаю здесь логическую цепочку. "Анализировать и решать проблемы" это практический навык, причем в работе тесно связанный с написанием хорошего кода. А проблемы и методы их решения бывают разные, связанные с теорией алгоритмов и не связанные. Например, правильное применение ООП и паттернов проектирования.
В-третьих – есть множество задач, которые нельзя решить простым вызовом API библиотеки или фреймворка. Что вы будете делать в таком случае? Тратить часы на поиски возможных решений и просить помощи у друга?
Я наверно неправильно сформулировал ответ по этому пункту. Есть выбор — тратить часы сейчас, читая о любых алгоритмах и решениях, которые попадутся под руку, или тратить часы по мере возникновения задач, читая о решениях, которые требуются именно для этой задачи. Мне кажется, в большинстве случаев правильнее второй вариант, так как и времени уйдет меньше, и можно проверить решение на практике.
примитивный text-wrap в одном из визуальных компонентов
Здесь надо уметь представлять задачу и возможные пути решения, знание алгоритмов здесь не нужно. Что вы и сами подтверждаете, упоминая интерна-третьекурсника с аналитическим мозгом.
Оказалось, что человек, который изначально делал этот проект, нагородил кучу ужасных конструкций из тройных вложенных циклов, которые долго и печально забирали данные из БД, и потом привязывали их к графикам. После небольшого рефакторинга страница стала грузится почти мгновенно.
У меня похожий случай был. И я тоже сделал рефакторинг, хоть и не специалист в алгоритмах. А уж про оценку сложности я тогда и не слышал. Зачем здесь знание алгоритмов?
В свою очередь я вам привел другие примеры с таким же вопросом, ответить на которые вы не захотели.
понимание того, что происходит внутрях полезно знать всем
Понимание принципов работы и знание алгоритмов это не одно и то же.
Собственно, зачем я это все пишу. Я хочу сказать, что факт незнания программистом алгоритмов означает только то, что он не знает алгоритмы. Он ничего не говорит ни о знаниях и навыках в другой области, ни о сложности решаемых задач, ни даже об умении разобраться в алгоритмах в дальнейшем.sgrey
17.03.2016 14:55Для начала надо определиться с терминологией. Под знанием алгоритмов я понимаю знание алгоритмов обработки стандартных структур данных и умение оценивать их сложность в O-нотации — обходы графов, сложность различных сортировок и т.д.
Я привёл три определения алгоритма, два из которых — формальные :) Но статья больше о понимании алгоритмов и их анализа
Я говорю о том, что доказательства, приведенные в статье, ничего не доказывают — неправильно объясняют причины и не доказывают необходимость знания алгоритмов для выполнения любых задач.
Вырвал из контекста я те фразы, на основе которых в статье идет дальнейшее доказательство.
Можно ли этот вопрос вообще доказать или опровергнуть? Я вообще не утверждал что незнание алгоритмов не даст найти работу. Очень много людей не имеют понятия о них, и при этом работают как-то. Только качество такой работы — отвратительное как правило...
С первым предложением согласен, но не понимаю здесь логическую цепочку. «Анализировать и решать проблемы» это практический навык, причем в работе тесно связанный с написанием хорошего кода. А проблемы и методы их решения бывают разные, связанные с теорией алгоритмов и не связанные. Например, правильное применение ООП и паттернов проектирования.
Изучение алгоритмов как раз и даёт навык "анализировать и решать проблемы" :) Как лучше всего выделять память для динамического массива, чтобы эффективно её использовать? Вполне себе алгоритмический вопрос.
А так называемые паттерны ООП появились в результате того, что много умных людей применяли схожие алгоритмические решения, и их потом вывели в паттерны :) Да я и не утверждал нигде что кроме алгоритмов — ничего не нужно
Я наверно неправильно сформулировал ответ по этому пункту. Есть выбор — тратить часы сейчас, читая о любых алгоритмах и решениях, которые попадутся под руку, или тратить часы по мере возникновения задач, читая о решениях, которые требуются именно для этой задачи. Мне кажется, в большинстве случаев правильнее второй вариант, так как и времени уйдет меньше, и можно проверить решение на практике.
Вы прям из крайности в крайность бросаетесь. Я же не призывал никого всё бросить и бежать изучать все возможные алгоритмы :) Когда вы столкнётесь с проблемой, и не имеете определённых знаний, то вы вероятно даже не будете знать что гуглить, чтобы решить пролему. Работал с такими с людьми: из-за них проект тормозит потому что они непрерывно гуглят всё подряд, доверие к ним падает постоянно и на работе они не задерживаются как правило. Иметь пробелы в знаниях — нормально, если они в деталях и их можно восполнить за несколько минут. А если пробелы требуют семестра в универе или прочтения нескольких книг, то это просто некомпетентность.
Здесь надо уметь представлять задачу и возможные пути решения, знание алгоритмов здесь не нужно. Что вы и сами подтверждаете, упоминая интерна-третьекурсника с аналитическим мозгом.
Это пример, когда человек имея пробел в знаниях умеет решать проблемы. Изобрёл алгоритм переноса строки на месте за пару часов. А если бы его знал — потратил бы пол часа.
У меня похожий случай был. И я тоже сделал рефакторинг, хоть и не специалист в алгоритмах. А уж про оценку сложности я тогда и не слышал. Зачем здесь знание алгоритмов?
Я думаю что человек, который написал этот код тоже думал "зачем ему знать алгоритмы" :) Вы опять спрашиваете вопрос, о котором написана вся статья :)
Понимание принципов работы и знание алгоритмов это не одно и то же.
Принцип работы — само по себе является алгоритмом :)
Собственно, зачем я это все пишу. Я хочу сказать, что факт незнания программистом алгоритмов означает только то, что он не знает алгоритмы. Он ничего не говорит ни о знаниях и навыках в другой области, ни о сложности решаемых задач, ни даже об умении разобраться в алгоритмах в дальнейшем.
Опять таки вы меня не поняли. Простое знание о существовании алгоритмов конечно не даёт никакой пользы. А вот понимание подхода к решению задач — совсем другое дело. Изучение алгоритмов в первую очеред даёт навыки для решения проблем. Именно поэтому идёт акцент на "разделяй и властвуй", "жадные алгоритмы" и т.п. Не нужно знать как написать алгоритм дайкстры чтобы понимать принцип жадных алгоритмов, не нужно знать как реализовать merge sort чтобы понимать "разделяй и властвуй", но понимание этих концептов позволяет писать эффективные решения и узнавать схожие проблемы, где решение от одной проблемы, можно применить к другой.
neit_kas
16.03.2016 23:28+2Касательно университета, мы даже в рамках лабораторных деревья и списки не реализовывали. Нас с ними только познакомили, а реализацию оставили по желанию. ТАУ и операционные системы пробежали галопом по Европе (что касается ТАУ, даже не совсем понял, о чём предмет). Зато есть экология, метрология, природопользование и теоретическая физкультура.
MacIn
17.03.2016 03:40Странно.
Нам давали как метрологию, экологию (например, мы, программисты, расчитывали фабричную трубу для определенной розы ветров и типа выбросов, безопасную зону расположение домов и пр), так и профильные предметы. И АВЛ реализовывали, ЕМНИП, на 2м курсе. Списки так вообще в первом или втором семестре.neit_kas
18.03.2016 19:28Списки тоже давали на 2 семестре, но лаб по ним не было. Сказали, что по желанию можно в курсаче использовать. Мне было интересно поработать с памятью, я использовал. М.б. кто-то ещё использовал, но большинство послали это куда подальше. В третьем семестре не помню, возвращались к ним или нет, но многие из группы до сих пор (3 курс) обходит их стороной. Про деревья я вообще молчу: АВЛ и ЕМНИП — эти понятия я узнал только что от Вас (стоит отметить, ЕМНИП с ходу нагуглить не смог). Бинарных деревьев где-то как-то касался, но явно не в рамках универа. Каких-то расчётов по экологии вообще не было. Вынесли мозги организациями ко контролю за окружающей средой и школьной программой по географии и экологии, приняли зачёт и на этом экология закончилась. В конечном итоге, делаю вывод, что при специалитете было дольше, но качественнее.
Кстати, ещё один примечательный момент: нам говорили (на информационных системах правда), что шифр Виженера криптостойкий)chersanya
18.03.2016 21:19+2ЕМНИП это не деревья, а просто аббревиатура :)
http://lurkmore.to/%D0%95%D0%9C%D0%9D%D0%98%D0%9Fneit_kas
18.03.2016 21:59Ясно) Именно это и нагуглил, но думал, что аббревиатуры схожи.
П.с.: с каких пор лурк в блокировке? Что-то не слышал об этом.
mephistopheies
16.03.2016 19:36+5Если посмотреть на все эти статьи, то можно заметить, что люди, которые их пишут, фактически обижены на университеты за то, что их заставили учить много сложного материала — в виде алгоритмического анализа, сложных алгоритмов и структур данных — который им вроде бы не пригодился. По сути, авторы статей обижены на университеты из-за того, что там не смогли предсказать будущую область работы авторов и дать им только минимально нужный набор навыков. Ведь действительно, чтобы писать простенькие сайты и скрипты, не нужно особого знания алгоритмов и структур данных. Или всё-таки нужно?
боюсь обижены они на то, что мозгов не хватило освоить все это; соответственно они это и не используют; sad but truearielf
17.03.2016 01:19У меня немного иная статья О высшем образовании.
mephistopheies
17.03.2016 01:21-2вот и продолжайте писать на мегамозг, сюда с таким не стоит соваться
TimsTims
17.03.2016 10:48Хорошая статья, и не важно, что она на соседнем ресурсе.
mephistopheies
17.03.2016 11:04очевидно, что высшее образование необходимо, если ты не низкоквалифицированный персонал, а тот, кто называет себя программистом, тут нечего спорить и писать статьи; кто не согласен, тот просто ошибся профессией (да да бывают исключения, везде, но вероятность что ты /вы/ктотоеще бил гейтс ничтожна, это на столько очевидно, что тоже не стоит писать об этом, ну только если на ресурсе типа мм или гт)
Kroid
18.03.2016 22:32Я так понимаю, что определять, кто ошибся профессией, а кто нет — будете именно вы?
khim
18.03.2016 23:01Нет, почему же. Работодатель. Тут есть много рассуждений на тему, что "есть 100500 контор, готовых платить многозначную сумму в евро за общую адекватность, интуицию, широкий кругозор и способность делать поддерживаемый продукт на банальном пэхэпэ или руби" и которые при этом не требуют знания алгоритмов — но я как-то с такими не сталкивался. Если под "многозначной суммой в евро" понимается не годовая зарплата в 10000€, а хотя бы что-нибудь позволяющее претендовать на голубую карту, конечно.
Kroid
19.03.2016 00:59Увы, в России практически все 100500 контор платят в рублях, а не в евро, независимо от того, есть ли у работника вышка. Если пересчитать и округлить, то примерно 10к евро и выходит. Так что в принципе, большой разницы нет.
VladVR
16.03.2016 19:42+1У меня примерно такое же мнение. Даже если сам того не замечаешь, на подобные задачи наталкиваешься постоянно. А замечать начинаешь, когда другой, менее подготовленный разработчик пишет квадратичный алгоритм там, где легко пишется линейный, а потом тебе дают оптимизировать это.
Да и сам, бывало, "попадался", чего уж греха таить. Понимал, что что-то пошло не так только на реальных данных, где не 5-10 сущностей, а пару сотен.
Но я все же предпочитаю сначала в гугл, чтобы найти там, например из последнего пригодившегося, алгоритм Tarjan-а. И только потом, если готового нет, то пытаюсь придумать алгоритм самостоятельно.
Idot
16.03.2016 19:48+1Знать и понимать — не одно и то же. Алгоритмы важно — ПОНИМАТЬ, а заучивание наизусть без понимания — малополезно. Это как в советской школе — учили наизусть стихи на английском, но мало кто после этого заговорил по-английски.
Я уже приводил в предыдущей теме сравнение алгоритмов с типовыми велосипедами. Хорошему инженеру не обязательно помнить наизусть все конструкции типовых велосипедов, но он должен ПОНИМАТЬ как и почему работает типовой велосипед. Точно так же, программист не обязан помнить все типовые алгоритмы, но он должен быть в состоянии ПОНЯТЬ и разобраться в любом типовом велосипеде. Если он даже типовой «велосипед» не понимает и не может в нём разобраться, то — плохи его дела.sgrey
16.03.2016 22:15+2Вы делаете разделение в семантике там, где его нет. В контексте "знать" именно означает "понимать", ибо просто знать о существовании алгоритма — бессмысленно.
Kroid
16.03.2016 20:25+10Из статьи в статью пишется и переписывается одна и та же мысль:
«Любой человек должен уметь менять пеленки, планировать вторжения, резать свиней, конструировать здания, управлять кораблями, писать сонеты, вести бухгалтерию, возводить стены, вправлять кости, облегчать смерть, исполнять приказы, отдавать приказы, сотрудничать, действовать самостоятельно, решать уравнения, анализировать новые проблемы, бросать навоз, программировать компьютеры, вкусно готовить, хорошо сражаться, достойно умирать. Специализация — удел насекомых».
Не надоело еще?
Хорошо, когда ты и чтец, и жрец, и на дуде дудец. В реальном мире — увы. Если ты крутой прогер, который и на ассемблере, и на руби, и во все новые фреймворки умеешь — ты выходишь на улицу раз в две недели — хлеба купить. А если еще и в реальном мире живешь — значит, спишь раз в полгода. Прямо сап-теорема какая-то.
Когда алгоритмист-олимпиадник, умеющий написать семь видов сортировки, но не умеющий писать простой понятный код, который потом другим поддерживать надо, начинает прикладному фронтендщику засирать мозг — аж бесит. Наоборот — тоже бесит.
Что программисту действительно надо — составлять индексы и уметь гуглить. Я без понятия, как писать сортировку пузырьком, никогда это не надо было делать. Но я знаю, что такая штука существует. Понадобится — залезу в википедию и уже через час смогу написать сам. Внешняя память — великое изобретение человечества, нужно лишь индекс время от времени актуализировать.sgrey
16.03.2016 22:16+2Простите, а вы вообще читали статью или её не поняли?
Kroid
16.03.2016 22:59+1По-диагонали. Это уже третья статья на подобную тему за эти дни на хабре. Если что-то не так, не стесняйтесь, ткните носом.
sgrey
16.03.2016 23:26+2Да просто я ничего подобного не утвеждал. Суть статьи в том, что понимание того, что происходит внутрях полезно знать всем, в независимости от того, реализуешь все эти алгоритмы на практики или нет. Просто используя язык, вы уже сталкиваетесь с выбором какой алгоритм использовать и какую структуру данных выбрать для хранения. Понимание последствий такого выбора важно для того, как будет работать программа
brainick
16.03.2016 20:26-2Теория алгоритмов
Читаем определения, потом строчим на Хабре.
«Тео?рия алгори?тмов — наука, находящаяся на стыке математики и информатики, изучающая общие свойства и закономерности алгоритмов и разнообразные формальные модели их представления. К задачам теории алгоритмов относятся формальное доказательство алгоритмической неразрешимости задач, асимптотический анализ сложности алгоритмов, классификация алгоритмов в соответствии с классами сложности, разработка критериев сравнительной оценки качества алгоритмов и т. п. Вместе с математической логикой теория алгоритмов образует теоретическую основу вычислительных наук.»
А автор пишет об алгоритмах и структурах данных.sgrey
16.03.2016 22:27+2Простите, а вы когда видели разделение алгоритмов и структур данных?
brainick
16.03.2016 22:50Для особо одарённых — теория алгоритмов это раздел математической логики. Она не изучает построение конкретных алгоритмов вроде обхода в глубину или ширину, а изучает вещи вроде машины Тьюринга, лямбда-исчисления, NP — полноту.
sgrey
16.03.2016 23:07+1Вы хотите обсудить рекурсию в машинах Тьюринга и отличие нетипизированных и типизированных лямбда-исчсилений, а также какую роль играет Y-комбинатор в проблеме остановки? А затем мы может дойдём до того факта, что логические формулы могут быть эквивалентны типам данных :)
khim
16.03.2016 23:40+2А особо супермегаодарённым рекомендуется прочитать свой собственный комментарий: асимптотический анализ сложности алгоритмов, классификация алгоритмов в соответствии с классами сложности, разработка критериев сравнительной оценки качества алгоритмов...
brainick
16.03.2016 23:54И это тоже. Не стал полностью комментарий второй раз копировать. Но, в любом случае, конкретными алгоритмами, которые используют в программировании (даже очень сложными) теория алгоритмов не занимается. Если уж автор делает наброс на вентилятор, то сначала нужно научиться правильно термины употреблять.
khim
17.03.2016 00:19+2Но, в любом случае, конкретными алгоритмами, которые используют в программировании (даже очень сложными) теория алгоритмов не занимается.
Вот прямо даже так? Вы вообще список литературы из той статьи, откуда это определения стащили видели? «Дональд Кнут. Искусство программирования.» — не припомнаете, нет? Никакой конкретики? Вот прямо совсем? MIX, MMIX и всё такое?
Если уж автор делает наброс на вентилятор, то сначала нужно научиться правильно термины употреблять.
С больной головы…
P.S. Да, есть в теории алгоритмов вещи, которые в практической деятельности не очень нужны. Но какая-нибудь проблема остановки — вещь черезвычайно практическая: если вы выясняете что какой-то компонент, который, чёрт побери, всё никак не удаётся отладить, на самом деле пытается решить подобную задачу, то вы можете со спокойной душой идти к заказчику и обсуждать изменения условий: в таком варианте — оно не полетит. Никогда. А уж вещи, о которых Кнут (один из классиков теории алгоритмов, в общем-то) пишет — более чем практичны (хотя вот прямо самого Кнута я бы читать не советовал — слишком он глубоко копает). Даже не смотря на то, что пресловутые «ленты» сейчас в датацентрах разве что для резервного копирования используют.
Lau
16.03.2016 21:55Чтоб быть ремесленником достаточно базовых знаний и фрагментированной картины мира, все остальное будет постигаться в процессе путем проб о ошибок (правда решения будут находится уровня "вот здесь проволочкой изолентой и будет на века"), таких "инженеров" видел немало, не могу ничего сказать про них плохое, обычно это очень умные и быстро обучаемые люди, но с фатальными пробелами в знаниях которые являются основой нашей профессии.
Если человек готовы выходить за рамки своей зоны комфорта и лезть все глубже и глубже вплоть до железа и законов физики в целом а так же термодинамики в частности то без знаний алгоритмов, без знаний структур данных, без понимания базовых принципов работы современной вычислительной техники не обойтись абсолютно.
Если человек хочет создать что-то новое нужно сначала понять старое, пропустить через себя, проанализировать и внести свой фундаментальный вклад.
Если резюмировать
- набор базовых знаний плюс ситуативное обучение для достижения результата = ремесленник с ограниченным спектром возможностей.
- понимание основ, перво причин, знание истории своей отрасли и смежных дисциплин = профессионал способный на многое.
sgrey
16.03.2016 22:30Есть много умных людей, которые не получали формального образования в информатике, но научились многому. Проблема в том, что теория вычислений не самая простая наука, и изучить её самому как следует может быть проблематично даже умному человеку
Lau
17.03.2016 00:45Да, они научились многому, но когда возникает проблема входящая в их слепое пятно (коих множество ибо они учились адресно исходя из текущих проблем) они даже не догадываются о возможных путях и решениях, т.е. они не понимают и не осознают глубину провала в знаниях.
А так как люди не глупые и уже многое преодолели верят в себя и основываясь на слепой вере применяют старую "изоленту и проволоку", когда нужно читать теорию графов и дискретную математику.sgrey
17.03.2016 02:19Да вобщем-то так и есть. Очень часто из-за недостатка образования возникает непонимание. У меня с командой оутсорса регулярно стычки из-за этого.
MacIn
16.03.2016 22:25+2Нужно ли знать алгоритмы?
Ха три раза. Лично знал программиста, который не знал, что есть переменные. И писал программы, храня данные в полях скрытых компонентов окна.
Viacheslav01
17.03.2016 00:38+6Когда то давно, уже почти окончив университет, сам изобрел бинарное дерево поиска :)
Это был последний курс университета, я не был в общем то примерным студентом и больше работал, чем ходил на лекции, но материал изучал, по долгу сдачи сессии, чему учили? Многому учили, но вот теории алгоритмов вообще и конкретных алгоритмов в частности, не было. Так же как и не было, литературы в библиотеке нормальной по теме, а вожделенный трехтомник Кнута стоил полугодовой зарплаты.
С удовольствием бы поменял такой расклад, на университет где принуждали учить не нужную теорию алгоритмов и классические алгоритмы!
Это бы сэкономило, мне годы, годы потерянные на осознание того, что я в общем то ничего не знаю!
fox_anthony
17.03.2016 02:10Обычно на собеседовании даю решать задачки (помимо технических вопросов на понимание конкретной области). Я не использую задачи на знания "специализированных" алгоритмов (сортировка, бинарный поиск, графы, деревья и т. п.). Алгоритмы знаю (достаточное количество).
Задачи вовсе необязательно должны отвечать на вопрос "а где это применяется на практике?". Цель задач не в этом. Цель такого род задач оценить насколько хорошо кандидат умеет мыслить, каким образом кандидат пытается подойти к решению, насколько хороши навыки владения тем или иным языком программирования, как кандидат проверяет правильность своего решения. Удобство задач в том, что они миниатюрны (одно предложение в большинстве случаев).
Если взглянуть на набор задач, которые обычно предлагают на собеседовании то можно заметить, что эти задачи в основном нацелены на то, чтобы проверить знает ли кандидат о существовании того или иного алгоритма и правильно ли он его может применить (вызвав, например, библиотечную функцию).
Важно также помнить, что интервью — это именно оценка кандидата, т. е. реальное положение вещей может несоответствовать оценке. Но за час беседы с человеком эту оценку нужно дать.
Со статьей согласен (хотя может, наверное, показаться обратное). Имел проект (на C#), который достался "в наследство" и вроде бы и люди не глупые его делали и давно уже не студенты (не в обиду студентам), но когда внутри цикла foreach по одной коллекции проверяется принадлежность к другой при помощи метода Contains. Только этот метод является методом-расширением для интерфейса IEnumerable, становится как-то невесело, нерадужно и печально.sgrey
17.03.2016 02:29Насколько способность решать задачки на собеседовании кореллирует с эффективностью соискателя на практике — интересный вопрос сам по себе. Например я знаю человека, который задачки решал неплохо, но вот работать в команде не умел от слова "совсем". Считал всех идиотами и никого не слушал. Да и его решения и дизайн были под вопросом. И зачем он такой нужен? Да и человек сидит под стрессом, мало ли как он с задачками справится. Я людей гоняю по понимаю конкретной технологии больше, с которой они будут работать. Большинство отсеевается на этом этапе сразу.
Лично я предпочту взять человека, который меньше знает, но признается в этом честно и пойдёт и выучит вопрос. Такого легко обучить и он будет расти.fox_anthony
17.03.2016 02:49Насчет стресса — я это понимаю — пытаюсь подбодрить, подсказать в конце концов, не дать сдаться сразу. Как на интервью оценить умение работать в команде, я, честно говоря, не знаю. По технологии я тоже гоняю в первую очередь. Предпочту взять человека, который пускай чего-то не знает по технологиям, но делает правильные шаги к решению. Критический случай — когда не знает ничего по технологии, но такое бывает редко. Впрочем, как правило, и на задаче такие ничего предложить не могут.
Стресс обычно бывает только на первых интервью, с каждым новым интервью стресса меньше и меньше. Первые интервью в жизни как правило провальные. Дальше — лучше.sgrey
17.03.2016 03:17Я считаю что умение решать задачи — это основной навык программиста. Я тоже предпочитаю людей, которые имеют пробелы в знаниях по технлогиям, но могут думать и анализировать ситуацию. Просто ситуация, когда люди не имеют достаточно знаний чтобы просто сделать анализ проблемы, к сожалению не редка.
А оценку работы в команде можно сделать по многим критериям. Например по поведению человека — если он ведёт себя как пуп земли на собеседовании, то шанс что он не уживётся в команде велик. Ещё можно спросить про его предыдущее место работы и посмотреть как он будет отзываться о коллегах и начальниках. У меня например был человек, который прям на собеседовании был готов слить секретную коммерческую информацию своего работодателя, от которого он уходил.fox_anthony
17.03.2016 21:14Кстати, припоминаю сейчас парочку кандидатов которые вели себя именно как пуп земли. К счастью, я их не взял. За мысль спросить про предыдущее место работы и отзывы о коллегах и начальниках спасибо! Будем спрашивать.
Daniyar94
17.03.2016 07:22+2Может хватит уже мусолить эту тему.
Хотите быть прогером можете не учить алгоритмы.
Хотите быть Software Developer'ом учите.
Помните без алгоритмов Microsoft, Google, Facebook, IBM вы нахер не нужны.
Серьёзные кажется люди на хабре сидят, а мусолят уже эту тему две недели. Пора бы уже забыть. Лень учить, не учите. Все просто
BalinTomsk
17.03.2016 07:28+2Good vs Great Programmer
https://www.quora.com/Can-I-become-a-good-programmer-without-math-and-algorithms-knowledge/answers/9851010?srid=kGmi&share=f47ae0f3#
VladVR
17.03.2016 09:09Странно, что еще никто не откомментировал. List и ArrayList это одно и то же. Видимо подразумевался LinkedList
mayorovp
17.03.2016 09:52+1Ну, это не совсем одно и то же. Но да, алгоритмы там внутри одни и те же.
VladVR
17.03.2016 14:20Отличие лишь в том, что ArrayList не генериковый, и в контексте статьи, т.е. в контексте сложности алгоритмов, он таки идентичен абсолютно. И нет вообще ни одного кейса, который бы ускорился от замены List на ArrayList.
А в обратную сторону единственный кейс — боксинг, что опять же, со сложностью алгоритмов не пересекается никак.sgrey
17.03.2016 15:10Я говорю не только об алгоритмах, но и структурах данных. Хоть там и нет прямой алгоритмической разницы, использование одной коллекции против другой влияет на поведение программы.
dgstudio
17.03.2016 10:04-5Дорогой автор! Любое новое знание, вкладываемое в голову, должно быть экономически оправдано. У вас в статье про это — ни слова.
Если среднестатический разработчик, работая в офисе 8 часов в день, внезапно вложит себе в бошку волшебное средство, которое ускорит его работу в два раза, это не значит что он будет зарабатывать в два раза больше денег. Это значит, что он будет пахать в два раза больше за то же время, потому что никто не оставит простаивающим дорогостоящий человекоресурс. Безусловно — круто для работодателя, но вот надо ли оно разработчику?
Я сам трепетно отношусь к алгоритмам и паттернам, продвигаемым IBM и Amazon. Я могу читать лекции о lock-free и темпоральных структурах данных и потоковых вычислениях. Но они не дают мне возможности пинком открывать дверь в отдел кадров любой конторы на рынке, и требовать тройное увеличение оклада. Потому что чем больше инструментов ты знаешь, тем меньше работодателей, где все эти инструменты востребованы одновременно.
В итоге специалист, отрастивший себе набор ускоспециализированных скиллов, оказывается тупо привязан к месту работы, потому что ну нет, блин, нет на рынке 100500 контор с необходимостью использовать красно-чёрные деревья или ручками писать сортировку пузырьком. Зато есть 100500 контор, готовых платить многозначную сумму в евро за общую адекватность, интуицию, широкий кругозор и способность делать поддерживаемый продукт на банальном пэхэпэ или руби.
Это рынок, чувак.lair
17.03.2016 11:28+4Любое новое знание, вкладываемое в голову, должно быть экономически оправдано.
SRSLY? Вам контрпримеров привести, или вы сам поправитесь?dgstudio
17.03.2016 15:31-4Приводите сколько хотите.
Но если мой сотрудник, в оплаченное мной рабочее время, занимается вложением себе в бошку каких-то знаний, эти знания должны быть экономически выгодны моему проекту в долгосрочной перспективе. Потому что иначе он работает мне в убыток, а себе в пользу.
Вся эта широко обсуждаемая байда о том, что программист должен всегда учиться, эгоцентрично ориентирована программистами на самих себя.
Программы пишутся не для того, чтобы они отрабатывали за сколько-то там миллисекунд или ради прочей ерунды. Программы пишутся для того, чтобы доходы от них были выше совокупных расходов. С этого надо начинать, а не с мерянияпиписькамиалгоритмами.lair
17.03.2016 15:32+3Но если мой сотрудник, в оплаченное мной рабочее время, занимается вложением себе в бошку каких-то знаний
А с чего вы взяли, что речь идет об обучении в оплаченное вами рабочее время?
Программы пишутся для того, чтобы доходы от них были выше совокупных расходов.
Это тоже для общего случая неверно.
Viacheslav01
17.03.2016 15:11Зацепился взглядом, за метод пузырька, да его пришлось писать самому, т.к. его нет в стандартной библиотеке используемого языка, просто по тому, что зная природу своих данных, я предположил и проверил, что он работает гораздо быстрее в среднем лучших для среднего случая из библиотеки.
Kroid
18.03.2016 22:39Заминусовали беднягу. Если знания не должны быть экономически оправданы, как тогда выбирать, что именно из бесконечного множества вещей узнать прямо сейчас, а что отложить на потом? Очевидно, что либо у тебя, юзернейм, есть функция полезности для сравнения вариантов, либо одно из двух.
lair
18.03.2016 22:53+3А что, функция "полезности" только экономической оправданностью определяется?
Kroid
19.03.2016 01:02Функция "полезности" или, по другому, оптимизирующая функция — это и есть экономическая оправданность. Или для вас экономика — это только деньги и их производные?
lair
19.03.2016 01:42+1Или для вас экономика — это только деньги и их производные?
"Эконо?мика [...] — хозяйственная деятельность общества, а также совокупность отношений, складывающихся в системе производства, распределения, обмена и потребления."
Не все, чем я руководствуюсь при выборе между тем, что сейчас изучать, попадает под это определение.Kroid
19.03.2016 10:18Как насчет поискать определение для термина "экономически оправданная деятельность"?
Чуть выше вы хотели привести примеры. Я бы хотел их услышать, потому что не могу представить ни одного.lair
19.03.2016 12:12Как насчет поискать определение для термина «экономически оправданная деятельность»?
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 века. Или, скажем, музеи — только за последнюю поездку: лыжи, полярные исследования, корабли викингов, Кон-Тики и просто морской флот (я даже не беру в расчет художественные, чтобы не обсуждать, знание ли это).
Все это — знание, которое я получаю. Ничто из этого не связано ни с моей работой, ни с любой другой деятельностью, которую я веду ради получения дохода, ни даже с деятельностью, которую я веду, чтобы снизить свои расходы; проще говоря, ни с какой моей хозяйственной деятельностью.Kroid
19.03.2016 16:33Я вас понял. Действительно, если руководствоваться определением из словаря/википедии, вы правы. Эти хобби действительно не связаны с хозяйственной деятельностью.
Временами я читал подобные споры с вашим участием в других темах хабра и могу представить, чем может закончиться этот. Жаль, не сразу догадался. Спорить со словарем желания нет, увы.
И да, мне действительно понравилось, как ссылкой на яндекс вы показали процесс поиска. Не знаю, дословно ли вы восприняли мой комментарий или просто пошутили таким образом, но это было забавно.lair
19.03.2016 17:32Действительно, если руководствоваться определением из словаря/википедии, вы правы.
А чем еще вы предлагаете пользоваться? Какое другое определение экономической оправданности вы можете предложить, чтобы оно при этом не было идентично полезности (а оба они отличались от удовольствия)?Kroid
19.03.2016 21:08В контексте этого обсуждения для меня термин экономической оправданности идентичен термину оптимизируещей функции. Полезность или удовольствие — просто значения, которые можно оптимизировать за счет других, говоря другими словами — цели.
Если бы я мог переписать свое первое сообщение, я бы написал что-то вроде такого:
Знания должны быть полезными. Всех знаний получить за ограниченое несколькими годами время нельзя, потому приходится отказываться от одних в пользу других. Кроме того, есть еще неопределенность в будущем. И если человек отказывается от изучения некоторых алгоритмов в пользу изучения какого-нибудь фреймворка, это не всегда означает, что он идиот. Возможно, у него другие цели. Возможно, у него есть некоторые свидетельства, которых нет у вас. Возможно, у него есть особые ограничения, о которых вы не подумали. Но господа минусующие не задумались об этом. Не уверен, о чем именно они подумали, но одна из догадок: "Как можно говорить об оправданности, ведь знания священны! Каков наглец, и ты еще смеешь называть себя программистом?"lair
19.03.2016 21:15+2В контексте этого обсуждения для меня термин экономической оправданности идентичен термину оптимизируещей функции.
А вот для человека, комментарий которого заминусовали — явно нет. И именно за это его и заминусовали.
Но господа минусующие не задумались об этом. Не уверен, о чем именно они подумали, но одна из догадок:
Ну вот лично я — а мой минус там тоже есть — подумал именно то, что написал: знания не обязаны быть экономически оправданы, у меня (и у других людей) могут быть и любые другие критерии выбора кроме "заплатят ли мне за это деньги".
ahalaymahalay
17.03.2016 13:37Просьба к разработчикам, иметь возможность уменьшить контакт лист и добавить функцию Ctrl + R(аналог пунто-свитчера для выделенного фрагмента или всего сообщения) и Ctrl+T(перевод слов в транслейт) из квипа.
PavelMSTU
17.03.2016 18:08-1Коллеги, предлагаю отказаться от слова программист,
подобно тому, как через 100 лет после Ньютона отказались от слова "натуральная философия".
Если бы вы Ньютона назвали физиком, он бы удивился, т.к. в его эпоху его область знаний называли "натуральной философией". Свой основной труд он так и назвал: "Математические основы натуральной философии".
Я думаю, что слово программист лет через 30 станет неадекватным словом…
Я серьезно...
Короче. Спорящие люди — просто по разному понимают слово программист.
Моя теща вообще всех, кто может браузер установить считает программистоми.
Дайте ей инвайт и тут такое начнется...
QtRoS
18.03.2016 17:57+1фактически обижены на университеты за то, что их заставили учить много сложного материала
А я обижен за то, что дали так мало =\
questor
ПТУ — вот где должен был обучаться подобный человек, а не университет. Многие идут в институт лишь за корочкой, высшее образование — большой фетиш, а вот по правде: если ты собирался всю жизнь клепать типовые задачи — не нужен тебе университет.
Хотя многие ли адекватно оценивают, кем они хотят стать в жизни?
Мне правда непонятно: как можно в такой быстроизменяющейся отрасли пытаться создавать ПТУ?
Oxoron
Да без проблем.
Студентов учат двум-трем языкам (Pascal\Delphi, C\C++\C#, php), рассказывают про html\css\js, показывают офисный набор, показывают немного БД. Потом требуют сделать небольшой сайт, обычно онлайн-магазин. Плюс гуманитарные и околоайтишные предметы, всякую теорию (рефакторинг, ООП, циклы разработки). Возможна "экзотика" типа асма, или Go, или Arduino — если преподаватель заинтересуется.
В итоге базовые конструкции (условия, циклы, массивы, таблицы, JOIN-ы) студентам знакомы, а дальше только практика. На выходе процентов 10-30 студентов можно смело порекомендовать как джунов.
neit_kas
А как по мне, программа в ПТУ гораздо быстрее меняется, нежели в университете, где, честно говоря, хватает устаревшей информации.
khim
А она и должна быстрее меняться. Это совершенно логично: обучение короче, а значит менее глубокое. Нафига нужно менее глубокое и притом настолько же оторванное от нужд "производства" обучение?
ВУЗ берёт глубиной знаний, ПТУ — близостью к "производству". Непонятно почему программирование тут должно отличаться от других областей.
neit_kas
Просто в конечном итоге получается, что окончивший ПТУ более подготовлен к реальным задачам, нежели окончивший ВУЗ.
khim
И? В других отраслях так же. Токаря можно сразу отправлять точить детали (пусть простенькие), а будущему авиаконструктору предстоит ещё многому обучиться у мастера.
А уж полы мыть можно вообще почти без обучения… Не вижу никакой отраслевой специфики. Вот честно.
MacIn
Где иначе? Хочешь побыстрее чисто практические навыки — получаешь начальное и/или средне-специальное образование.
Хочешь понимать "глубины глубин", разрабатывать новые методы (например, внезапно, алгоритмы) — добро пожаловать в высшее профессиональное.
neit_kas
Проблема в том, что как раз ПТУ в последнее время даёт больше этих самых глубин, нежели ВУЗы. Я считаю, что эта проблема возникла с переходом на бакалавриат, где пытаются выучить "в общем", оставляя подробности (в том числе и алгоритмы) на работодателей.
MacIn
Не имею такой статистики, возможно, вы сумеете развернуть подробнее.
neit_kas
Конкретной статистики, увы, не имею. Просто смотрел по своим знакомым. Статистику всё же самому было бы интересно узнать.
sgrey
Вообще есть разнообразные курсы, где за несколько недель обучают той или иной технологии. Они обычно стоят довольно круглую сумму, и по выходу в теории человек выходит мастером, и они ещё помогают устроится на работу. Результат как правило получается такой, что человек лишается круглой суммы денег, приобретает базовое понимание одной технологии, и всё. Ещё проблема в том, чтобы давать актуальные навыки, т.е. нужны люди, которые работают в индустрии и не против преподавать.
Я вижу определённое применение для подобных людей: когда нужно накодить прототип быстро, но старших товарщей пока не получается оторвать от дел. Т.е. только для проэктов, которые либо краткосрочны (сделал и забыл), либо для создания proof of concept, которые потом будут выбрасываться и переделываться более опытными коллегами.
А так у меня довольно плачевный опыт даже в "вот тебе дизайн, иди его реализуй". Человек просто не понимает что от него хотят.
MacIn
Ну, вот профтех — это и есть такие "пере" курсы с дипломом.
sgrey
Только люди, закончившие эти курсы и не имеющие другого образования, почти ничего не знают и не умеют. Я бы их нанял максимум на позицию, эквивалентную интернам.
chuck
ПТУ – это еще полбеды. Меня больше пугают курсы "Стань программистом с нами за 3 месяца, изучив HTML/CSS/JS".
DennyRolling
Самый легкий способ выучить С++ за три недели: http://abstrusegoose.com/249