Для начала — тезис. Я утверждаю, что знание алгоритмов и даже наличие системного образования не делает вас хорошим разработчиком. Можно сказать жестче — для большинства задач вы будете профнепригодны, даже владея теорией графов, зная вычислительные сложности алгоритмов и прочитав всего Кнута.
Все дело в том, что разработка ПО — это не просто алгоритмы или языки.
1. Во-первых, сводить все к знанию только одних алгоритмов — это дохлая затея. Если программист не разбирается, к примеру, в сетевых технологиях, не понимает, как работает операционная система и тд — ему не поможет знание quicksort и всех структур данных.
Так, если программист не владеет пониманием доступных ему в *nix среде готовых инструментов и пишет свой (для запуска джобов — свой крон изобретает, условно) — то это труба. Или человек не понимает устройства сетей, и даже не может предположить, что у него в веб-приложении не грузится определенная часть данных из-за неверно прописанных роутов или лагающего DNS-сервера.
2. Во-вторых, без опыта использования реальных стэков технологий (как ПО, так и осей/железа) программист с крутыми теоретическими знаниями может блистать на топкодере, но залажает примитивнейшую задачу по созданию масштабируемого приложения.
Про нюансы, как ведут себя Java / различные компиляторы/интерпретаторы, можно прочитать десятки тысяч статей.
3. Без глобального мышления, понимания работы приложения в целом на всех уровнях (не только в своей песочнице, но и в рамках оси/железа/сетевой инфраструктуры) программист не может называть себя программистом. Условно говоря, если веб-программист думает только о том, как поставить новую либу на сервер, но вовсе не озадачен тем, как админы потом будут обновлять ее на 200+ серверах (и что будет, если она станет критичной для приложения, а после очередного обновления ОСИ окажется, что она не компиляется вообще).
4. Безопасность. Только с опытом приходит, на лабораторных или олимпиадах этому не натренируют.
5. Архитектура.
Я радостно смотрю, как выходит очередной язык/фреймворк, и тут же толпа бросается его вкручивать себе. Или — еще лучше — брать для своих стартапов.
Не понимая ни как поддерживать потом зоопарки из 5+ технологий (особенно когда их не будут поддерживать — привет GWT и сотням других), ни как масштабировать новомодную хрень на несколько серверов, ни как решать проблемы в отсутствии комьюнити.
Что стоит применять? Зависит от каждого конкретного случая, но нередко инструмент более обкатанный и распространенный предпочтительнее, чем только что появившийся свежий. Могу привести такой немодный язык Pure C, на котором написаны драйвера, системы, Постгрес, и еще миллион других вещей, который людям не нравится в силу негламурности (и сложных указателей, с кучей мест где можно выстрелить себе в ногу, признаем честно — что налагает дополнительные требования к разрабочтику), зато имеющего долгую историю и накопленный опыт использования.
6. Проектирование баз данных и оптимизация запросов. Всякие там нормальные формы проходят все, а опыт выбора СУБД и создания масштабируемой структуры под реальные данные с последующей оптимизацией работы приходит только с практикой. Но мы же не будем называть неполноценным знающего красно-черные деревья и решающего олимпиадные задачи программиста неполноценным просто потому, что он не имеет опыта и понимания, как работает оптимизатор запросов в PostgreSQL, почему лучше поставить такой составной индекс, а не сякой, и почему нужно тонко настроить параметры сервера для текущей нагрузки чтения/записи.
7. Наконец, мы не можем просто не учитывать общего уровня интеллекта людей и soft skills, EQ/эмпатия.
К примеру, если человек умный и обладает здравым смыслом, то он понимает, что язык — это инструмент. И он не будет писать в реальной работе на Джаве то, что отлично пишется на плюсах и работает без тормозов и бубна (а также жирных серверов и дорогих коллег).
При этом он с радостью возьмет Джаву и весь стэк, если там уже есть готовый фреймворк, библиотеки и опен-сорс софтина, которая решает задачи. А навыки общения с руководителем позволят ему проработать требования и выбрать всю инфраструтуру, разработать архитектуру и тд с учетом возможных изменений и требований бизнеса (а не только интересов типа саморазвития или вечного кайфа от ковыряния новых игрушек типа Scala).
Поэтому, уважаемые коллеги, я бы все-таки более осторожно относился к окружающим и с меньшим количеством пафоса и эмоций. Быть может, кто-то забыл когда-то прочитанные базовые алгоритмы или структуры данных, но его компетенции в той же архитектуре или безопасности настолько превосходят ваши, что смотреть свысока он может и на вас.
Желаю нам всем побольшее эмпатии, и чаще делиться с коллегами интересными ссылками (в том числе показывая выгоду от владения новыми знаниями и навыками), нежели чем делить на своих и чужих.
ЗЫ. Если вы почувствовали, что все-таки алгоритмы будут не лишними — отличный курс на Coursera: раз, два
Live long and prosper.
Комментарии (141)
terryP
19.03.2016 19:04+19Мое мнение знать самые основы алгоритмов — нужно: что такое O(n), бинарный поиск, хеш таблицы. Без этого вы не сможете понимать как работает индекс в базе данных или как работает HashMap'а в Java, когда ArrayList лучше LinkedList'a. Это равносильно пользоваться ООП или реляционными базами данными не понимая SQL или полиморфизма. Можно, но будут проблемы с пониманием элементарных вещей и общением с коллегами (если не сможете понять объяснения про O(n) являясь старшим программистом на вас будут смотреть странно). Ну и в конце концов чем же занимались в универе, если грубо говоря высшую математику выучили, а таблицу умножения забыли.
А вот знать наизусть точный алгоритм красно-черного дерева или десяток алгоритмов обхода графой — полезно, но не обязательно. Так как в реальной работе встречается это редко и проще открыть вики (или другой источник) и повторить знания, чем пытаться писать по памяти с риском ошибиться.khim
20.03.2016 17:00+9Точное знание — оно вообще мало где нужно. На практике "знание алгоритмов", по большому счёту, не очень-то и нужно. Что нужно — так это метазнание. То есть знание того какими свойствами обладают алгоритмы.
Простейший пример: поиск подстроки в строке. Есть банальный перебор, есть КМП, есть Бойер-Мур. Так вот фишка — не в том, чтобы уметь их реализовать (это не так-то просто, особенно для последнего), фишка в том, что "тупой перебор" и КМП замедляются при удлинении подстроки (хотя КМП, конечно, замедляется не так сильно), фишка в том, что БМ может ускоряться при удлинении подстроки, которую мы ищем!
Что, как бы, нифига не фокус, но если про алгоритмы не знать вообще ничего — то вначале немного ошарашивает.
Вот как человек, который про это забудет сможет спроектировать правильную архитектуру? И где окажется его коллега, который на это заложится, будет пытаться менять формат в попытке удлинить подстроки и сделать их менее регулярными (это тоже помогает БМу), но забудет (или будет не в состоянии) понять что библиотека, которой он пользуется замедляется при удлинении подстрок, не ускоряется?
К сожалению невозможно получить метазнания не получив знаний. Их можно вызубрить, но не почевствовав алгоритмы, не "поигравшись с ними" вы не научитесь строить правильную архитектуру.
А точные формулировки и описания — это не проблема ни разу, да, для этого литература есть.terryP
20.03.2016 18:40+1но забудет (или будет не в состоянии) понять что библиотека, которой он пользуется замедляется при удлинении подстрок, не ускоряется?
Ну вообще, я бы в любом случае не доверял теории, а написал benchmark'и и протестировал все библиотеки на разных конфигурациях компьютера и разных длинах строк. Дело в том что теория это хорошо, но практика лучше, так как скажем в Java замечательный в теории метод может создавать огромное количество временных объектов. что будет постоянно вызывать сборщик мусора и в результате метод окажется хуже не такого замечательного в теории метода.
Метазнание тоже можно выучить при необходимости, тут главное чтобы было понимание что если задача про графы, а ты про них ничего не знаешь, то нужно потратить пару часов и прочитать разные алгоритмы графов. Учитывая что такие задачи у многих появляются раз в полгода это оправданая трата времени. Хуже когда программист самоуверенно пытается придумать все сам. Тем более что появляются новые алгоритмы и метазнание 3-5 летней выдержки может быть уже не актуальным.khim
20.03.2016 18:57Ну понятно, что если у вас на что-то вся система завязана, то вы и backmark'и напишите и литературу проштудируете. Но невозможно на каждую строчку кода писать benchmark! И как показывает практика угадать где будет "узкое место" далеко не всегда удаётся.
И вот тут… метазнание 3-5 (да даже и 20!)-летней давности — гораздо лучше, чем "изобретение велосипеда" всё равно.
P.S. Хотя как вот тут хорошо заметили метазнание 50-летней давности — всё-таки не годится. Иногда нужно и книжки читать :-)terryP
20.03.2016 19:17+1Тут может быть мы просто о разных языках говорим, в Java "узким местом" будут кривые запросы к базам данным или к сети, но редко конкретная библиотека, к тому же там особенно актуально про зло преждевременной оптимизацим, в 99% случаях важно решить задачу максимально просто и понятно (грубо говоря искать строки исключительно библиотекой самого языка), чем заботиться о производительности. А в оставшемся 1% проблемы решаются анализом готового приложения с профайлером.
В языке C или С++ вопросы оптимизации и алгоритмов, конечно, имеют совсем другое значение.khim
20.03.2016 19:50-4Выбор языка — он ведь тоже от задач зависит. Собственно с него всё начинается.
Если вам нужна максимальная производительность и вы выбрали Java'у — то вы уже проиграли. И никакой "анализ готового приложения с профайлером" вас не спасёт. Приложение будет совершенно точно жрать память в диких количествах и, возможно, тормозить. Причём если со вторым — ещё можно кое-как бороться (хотя и сложно), то первое — исправить невозможно вообще.
С другой стороны Java обменивает возможность писать эффективный код на возможность писать надёжный код: систему, написание и отладка которой на C у вас займёт, условно говоря, 10 лет на Java вы сможете написать за 2-3 года.
Когда вы создаёте дизайн системы — вам с самого начала нужно определиться чего вы хотите, уж извините. А языки — это уже вторичное.terryP
21.03.2016 12:19+1Если вам нужна максимальная производительность и вы выбрали Java'у — то вы уже проиграли
Зависит от того чего нужна максимальная производительность, если числодробилка — да. Если основное узкое место системы запросы в базу данных — нет смысла брать ассемблер, высокоуровневый язык даст намного больше возможностей для оптимизации SQL запросов.
то первое — исправить невозможно вообще
Можно, можно. Вопрос прямых рук, можно организовать переиспользование объектов, ограниченное создание временных объектов и прочее, если память критична. На Java писали даже софт для сим карт, где не было сборщика мусора как факта.
А языки — это уже вторичное.
Конечно, речь шла о важности алгоритмов в повседневном программировании. В Java/C# большинство алгоритмов уже давно реализованы на уровне языка, проверены, много раз отлажены на производительность и нужно просто знать какие функции стоит использовать в том или ином случае. То есть знать возможности языка важнее чем алгоритмы. В более низкоуровневых языках (если в них нет большого количества уже реализованных алгоритмов в качества функций самого языка) наоборот знание алгоритмов важнее.khim
21.03.2016 13:30На Java писали даже софт для сим карт, где не было сборщика мусора как факта.
Да, писали. Я лично писал. А знаете — почему его там не было? А потому то не работает сборщик мусора при нехватке памяти. От слова «совсем». Если у вас памяти 3x от того что требуется — он работает неплохо. Если 2x — отвратитетльно.
И никакие теоретические изыскания [пока?] с этим сделать не могут. Начинали с того, что при меньше чем 2x памяти сборщик мусора переставал работать вообще, современные — работают, но мееедленное-мееедленно.
midday
19.03.2016 19:26+14Ох вы все напутали в этом мире.
1) Есть базис на котором строится программист: логика, алгоритмика, теория вероятностей, векторная алгебра и т.п.
2) Есть технологии
Так вот второе приходит и уходит, а база остается. Всех технологий не освоить, но они вполне легко осваиваются по мере надобности. А если вы освоили базу, то вы прошли профотбор, и с легкостью освоите вторую часть.
SannX
19.03.2016 21:02+2Но что такое база?
1) знание наизусть реализаций конкретных алгоритмов или
2) понимание принципов, на которых строятся эти алгоритмы (например, что такое хэш, индекс в БД и т.п.)?
Если второе, то вы правы. А если первое, то их знание — это лишнее, имхо.sgrey
19.03.2016 21:09+3Написал же человек:
логика, алгоритмика, теория вероятностей, векторная алгебра и т.п.
Есть такая вещь, как теория алгоритмов/вычислений, вот оно и является базой.
tyomitch
20.03.2016 00:15-2Этой теории меньше сотни лет, так что считать её вечной и непреложной — это очень смело.
Может статься, все сегодняшние знания об "основах программирования" лет через пятьдесят будут казаться такими же смехотворно бесполезными, как сегодня — принципы построения и использования арифмометров и табуляторов.sgrey
20.03.2016 00:29+2математике и логике меньше сотни лет? Это вы очень смело. Арифмометров может и нет больше, зато математические операции всё те же
tyomitch
20.03.2016 11:32+1И как математические операции помогут вам найти кратчайший путь в графе?
Алгоритм — это не просто перечень математических операций.sgrey
20.03.2016 15:45+3А ещё и кусок кода? :)
А как вы собираетесь дать определение кратчайшего пути не используя математики? :)tyomitch
20.03.2016 17:42"Сформулировать задачу при помощи математики" — не то же самое, что "решить задачу при помощи математики".
Математика позволяет формулировать в том числе и неразрешимые задачи.sgrey
20.03.2016 22:09+2Чисто из любопытства — как вы будете решать математически сформулированную задачу без помощи математики? Пример можно? Или как вы без математики докажите что задача неразрешима?
tyomitch
21.03.2016 00:51-2Демагогия какая-то. Без письменности я тоже этого доказать не смогу. Вывод: программирование — это письменность. Так, что ли?
sgrey
21.03.2016 01:05Да вот только хотел с вами про демагогию согласиться. Вы хоть в курсе почему вы можете сейчас рассуждать о неразрешимых задачах? И почему они неразрешимы?
khim
20.03.2016 17:06+1Алгоритм — это не просто перечень математических операций.
Алгоритм — это то, для чего Бэббидж создал свою машину.
И произошло это гораздо больше ста лет назад.
Да, формальной наукой это стало позже — когда от этого стали зависить жизни людей (для чего создавали ЭНИАК помним, да?), но способы что-то вычислить побыстрее и попроще — этим люди занимаются столетия.tyomitch
20.03.2016 17:40-2Машина Бэббиджа реализовывала один конкретный алгоритм (вычисляла значение многочлена в точке).
Большое число современных алгоритмов (сортировка, поиск, сжатие данных, парсинг текста и т.п.) не имеют своей целью "что-то вычислить (побыстрее и попроще)".khim
20.03.2016 19:38+1Большое число современных алгоритмов (сортировка, поиск, сжатие данных, парсинг текста и т.п.) не имеют своей целью «что-то вычислить (побыстрее и попроще)».
Да ладно вам. Вот всё то, что вы перечислили — туда и попадает. Просто пока сортировкой занимались библиотекари, а таблицы синусов считали математики — в алгоритмах сортировки прорывов не было (а вот в методах рассчётов — тут да: всякие АГС ещё Лагранж и Гаусс изучали). Но как только оказалось, что это проблема может получить выход в практику — так сразу теорию и подвели.
Хотя где-то вы правы: тот факт, что такой известный математик как Колмогоров, мог выдвинуть аж в 1956м году гипотезу, что умножение быстрее, чем за O(n2) не делается говорит о том, что всё-таки знания 50х годов не будут достаточными, чтобы современные задачи решать. Но вот уже то, что написано в Искусстве программирования — покроет бо?льшую часть поребностей современных разработчиков (а «гипотеза n2» была опровергнута Карацубой гораздо раньше).
Последующие же изыскания хотя иногда и открывают что-то «новое и интересное», но в целом — «картину мира» меняют медленно.
А вообще… Всё познаётся в сравнении. Вот вы тут говорите, что 50 лет назад Quicksort, Heapsort — были ещё не «базой», а «передним краем науки». Что, в общем, правда. Но ведь «новейшими технологиями» тогда были PL/1 и Multics с OS/360! Они были тогдашним Java'ой и Android'ом!
Ну и насколько будут востребованы сегодня люди «владевшие в совершенстве» писком тогдашних технологий? Если у человека, неполохо изучившему тогдашнюю «базу», есть шанс хотя бы понять о чём говорят люди сегодня, когда обсуждают сегодняшнюю «базу», то знания «практика», в общем, мало кому сегодня нужны. Если ему «повезёт» и он изучал OS/360, то, может быть, сможет найти работу по поддержке «глобокого легаси» где-нибудь в банке, а если он сделал ставку на Multics?tyomitch
20.03.2016 20:55-6Большое число современных алгоритмов (сортировка, поиск, сжатие данных, парсинг текста и т.п.) не имеют своей целью «что-то вычислить (побыстрее и попроще)».
Да ладно вам. Вот всё то, что вы перечислили — туда и попадает.
Мы с Ушаковым не считаем действия над текстом "вычислениями":
ВЫ?ЧИСЛИТЬ. Посредством действий над числами найти искомое, высчитать.
ВЫЧИСЛЕ?НИЕ. 1. Действие по гл. вычислить. 2. Результат этого действия, то, что получено посредством этого действия.khim
20.03.2016 21:28+4А причём тут Ушаков, извините? С каких пор он у нас стал авторитетом в области математики?
Задача сортировки — это задача нахождения перестановки, поиск — это нахождение числа с определёнными математическими свойствами и так далее.
Вполне себе математические задачи. Чем вычисление 100500 знаков какого-нибудь числа пи принципиально отличается от разбора текста?
Какой смысл определять "невычислительные задачи" так, чтобы сортировка — в них не попала, а выясление 100500 знаков пи или поиск совершенных чисел — попали?
neit_kas
20.03.2016 23:15+1А что Вы понимаете под технологиями? Многие технологии из того же Multics и UNIX используются до сих пор. Ка по мне, что технологии, что что алгоритмы можно разделить на устаревшие и не устаревшие.
khim
21.03.2016 00:23А что Вы понимаете под технологиями?
Вот это: для запуска джобов — свой крон изобретает, условно.
Многие технологии из того же Multics и UNIX используются до сих пор.
Идеи — может быть. Реализации — нет. Даже вещи из UNIXа (который, к слову, гораздо моложе) уже многие не поддерживаются (не знаю, к примеру, в какой версии Ubuntu пропала полноценная поддержка терминалов без строчных букв, но сейчас проверил — `stty olcuc` ещё работает, а ввод своего имени прописными буквами — уже нет).neit_kas
21.03.2016 00:33+1Тогда получается и алгоритмы устаревают. Медленнее, но устаревают.
sgrey
21.03.2016 00:38Алгоритмы устаревают в том смысле, что находятся более эффективные и замещают менее эффективные. Но это не значит что менее эффективные бесполезны и их стоит забыть.
neit_kas
21.03.2016 00:42+1А с технологиями не тоже самое?
sgrey
21.03.2016 00:50Да получается тоже самое. Технология это тоже своего рода алгоритм )))
neit_kas
21.03.2016 01:06Собственно, это и хотел сказать) Если точнее, технологии основаны на алгоритмах. Если взять шире, то технологии — это результат научных достижений. Как следствие, устаревают достижения — устаревают соответствующие технологии. По сему, мне и показались странными попытки рассмотрения технологий как противовес алгоритмам. Я думаю, незнание теории равносильно незнанию соответствующей ей технологии. Вопрос в том, на сколько глубоко знаешь теоретическую основу и на сколько глубоко её нужно знать, а также какие именно нужно знать технологии и, соответственно, алгоритмы? Ответ, думаю, у каждого свой, который зависит от конкретной необходимости и контекста решаемых задач. Логично, что в вузах/училищах дают, но не все, а те, которые наиболее часто используются. А вот гадать, понадобятся они или нет — равносильно угадыванию выпадения комбинации на игральных кубиках.
В итоге получаем, что сама идея данного холивара довольно бессмысленна.sgrey
21.03.2016 01:14Технлогий множество, а основаны они на алгоритмах и концепциях, которые придумали десятки лет назад. При этом всё множество технологий основано на относительно небольшом количестве концепций. Так что лучше учить? :) А концепции эти чаще не умирают, а эволюционируют и дополняются. Зная концепции — технлогии освоить намного проще.
neit_kas
21.03.2016 01:36Технлогий множество, а основаны они на алгоритмах и концепциях, которые придумали десятки лет назад.
Это утверждение последнее время не очень работает. Скорее новые технологии основаны на сравнительно новых достижениях в теоретической части.
Так что лучше учить?
И то, и то. сначала в базовом варианте, потом в контексте решаемых задач.sgrey
21.03.2016 01:41Это утверждение последнее время не очень работает. Скорее новые технологии основаны на сравнительно новых достижениях в теоретической части.
Например какие? Я не знаю никаких теоретических прорывов за последние 20 лет, котроые бы повсеместно использовались обычными разработчиками, а не в научных кругахneit_kas
21.03.2016 01:57Информационная безопасность (AES например и попытки его взлома); повешение производительности тоже влечёт появление новых технологий (точнее это скорее старые, которые стало возможно реализовать), что, соответственно, результат развития теории; изобретение blockchain. Да много их.
sgrey
21.03.2016 02:10Ну это однозначно технлогические усовершенствования, только ведь из теории в них ничего нового нет… Тот же AES в основе имеет поля Галуа.
neit_kas
21.03.2016 06:51А что у нас не усовершенствование? Супер принципиально новое если и есть, то на этапе: "в идеале, должно работать" (если из IT, то тот же квантовый компьютер).
sgrey
21.03.2016 07:42Я говорю про усовершенствования, которые идут из теории. Например асимметричное шифрование будет таким. А более крутой алгоритм, который использует старые медоты сюда не очень подходит.
Или другой пример — создание системы типов для статической верификации параллельных программ. Такой полноценной системы пока нет
khim
21.03.2016 01:17Логично, что в вузах/училищах дают, но не все, а те, которые наиболее часто используются.
Ответ неверный. Об чём, собственно, и спор.
Это в ПТУ или на трёхмесячных курсах имеет смысл изучать вещи, которые «наиболее часто используются». А в ВУЗах и в школе — нужно изучать вещи с достаточно большим «периодом полураспада», чтобы это обучение имело хоть какой-то смысл.
А вот дальше — у многих возникает вопрос: а оно — вообще нада? Зачем тратить несколько лет жизни на то, что, как бы, напрямую «вам не касается». Увы — касается. Вот в том самом T-shaped специалисте алгоритмы — неизбежно попадут в «ножку», а всё остальное — в «шляпку». Просто потому что иначе — не получится.
Попытка сделать иначе с неизбежностью упрётся в «малый период полураспада». Хотя такой специалист может и выстрелить. Один-два раза за свою жизнь. А потом — всё, «парадигма изменится» и его специализация станет никому не нужной.
Можно, конечно, выбирать специализацию поустойчивее — когда-то это был Кобол, сегодня его место занял язык 1C. Но всё равно это всё достаточно шатко и ненедёжно. Вытеснит кто-то 1C-Бухгалтерию — и куда потом? В дворники?neit_kas
21.03.2016 01:32А в ВУЗах и в школе — нужно изучать вещи с достаточно большим «периодом полураспада», чтобы это обучение имело хоть какой-то смысл.
Для чего? Не для того, чтобы изучить теорию с меньшим "периодом полураспада"? Причём почему она имеет большой период? Собственно, там такая и даётся. Я, например, практически не видел теории в вузе, которая не имела отголосков в современных технологиях. Причём, например в таких дисциплинах, как теория систем и численные методы ещё не успел наступить период полураспада (точнее они довольно молоды для того, чтобы оценить их в этом контексте). Разница в вузе и ПТУ не в самой теории, а в её количестве и углубленности.
Вытеснит кто-то 1C-Бухгалтерию — и куда потом? В дворники?
Для Вас язык — это языческое божество или средство? Для тех, для кого он средство быстренько перейдут на другой. А скорее всего изначально будут знать не только 1C.khim
21.03.2016 02:37Для чего?
Не «для чего», а «почему». Потому что учить теории с короткими переодами полураспада в течение 10 лет смысла не имеет. А более «устойчивые» — имеет. Конечно только в том случае если есть шанс, что они окажутся потом востребованы.
Для Вас язык — это языческое божество или средство?
Для меня — средство. Потому что я знаю их не один десяток (не все, конечно, я знаю хорошо). А вот для «специалиста по 1С» зачастую — это весь их мир. Ничего другого они делать не умеют и не хотят.
Та же самая ситуация в других областях науки и техники, кстати. Отсюда — куча незакрытых вакансий при дикой же безработице.neit_kas
21.03.2016 06:57А как вы определяете, с коротким периодом полураспада или нет?
Для меня — средство...
Меня ещё умиляют холивары на тему: "Какой язык лучше". Так ладно, если противопоставляют языки одной области, так нет, любят сравнить какой-нибудь VB и C++.
khim
21.03.2016 01:03+2Конечно. Нет ничего вечного в этом мире. Вопрос в "периоде полураспада". Как всем известно период полураспада научных знаний — 45 лет.
Так вот когда вы имеете дело с "базой" (теория алгоритмов и прочая) — то вы имеете деле со знаниями, которые существенно устойчивие. Кой-какие вещи из Кнута, безусловно, устарели — но гораздо меньше половины.
А вот когда вы изучаете "технологии" — то должны понимать, что хорошо будет если ваши знания сохранят свою актуальность лет 5-10, а не устрареют раньше.
Что в свою очередь, объясняет почему их почти бессмысленно изучать в школе и/или в ВУЗе: к моменту поступления на работу почти всё — уже устареет.
Хотя есть и некоторое ядро, которое не устаревает, но, к примеру, текстовые редакторы и электронные таблицы не так давно (меньше 10 лет назад!) вдруг раз — и поменяли весь интерфейс. А уж что произошло за это время с другими, менее "устоявшимися" технологиями...neit_kas
21.03.2016 01:19А почему устаревают технологии? Случайно не из-за устаревания каких-либо их теоретических оснований? Каждой технологии соответствует какой-то набор теории, собственно, наоборот тоже работает. Я это всё к чему, меня такие темы всегда удивляли. Такое ощущение, что некоторые считают технологии и теорию двумя противолежащими полюсами, делая выбор, куда пойти. Но это же не так. Изучая технологию всё равно коснёшься теории, при этом знания голой теории без применения (т.е. без технологий) само по себе бессмысленно (если только в знакомых покидаться заумными фразами, показывая свою
тупостькрутость). Вопрос обычно не в том, нужны ли знания технологий/теории, а в том, какая именно область этих знаний нужна или будет потенциально нужна. Логично предположить, что никто не сможет изучить все технологии ровно как и всю теорию. Эта тема очень актуальна для программирования. Один с БД воюет, другой оси пишет, третий интерфейс изобретает, а четвёртый с пятым вообще что-то в науке делают, причём четвёртый пытается моделировать белки, а пятый движения планет.sgrey
21.03.2016 01:24+3Нет, технлогии устаревают не из-за устаревания теории. Технологии устаревают из-за того, что функции, которые они выполняют либо больше не нужны, либо скудны по сравнению с конкурентами. Или из-за удобства — вышло что-то новое, более удобное, и всё. Это не значит что теория изменилась. Изменилась реализация.
neit_kas
21.03.2016 01:49Согласен, но дополнение в теории тоже приводит к изменениям технологии (часто касается обработки данных и информационной безопасности). Опыт я что-то забыл учесть.
sgrey
21.03.2016 01:54Частично да, зависит ещё что за теория. Бывает такая, что нужно много лет чтобы оно увидело свет. А бывает "о, мы можем дополнить Хиндли-Милнера вот так и сделать более сильную типизацию", и оно через несколько месяцев-годик уже на рынке :) Но это всёравно основано на старой теории
neit_kas
21.03.2016 01:58Старую основу я не исключаю и в технологиях. Это спиральная особенность человеческой истории сказывается)
sgrey
21.03.2016 02:19В технологиях чаще опыт учитывают, чем что-либо ещё. Если говорить конкретно о софте, то сколько примеров когда старые проекты переписывались с нуля потому что приходили в негодность из-за допущеных предположений в начале разработке. Не всегда даже с улучшением функционала
khim
21.03.2016 03:00Вот как раз стремление "переписать с нуля" и отличает теорию от технологии. Теорию — бессмысленно "переписывать с нуля". Она либо — верна, либо — неверна. Всё. Можно немного упростить изложение, книжку поудобочитаемей создать, но "переписать с нуля" теорию? Это вообще как?
А технология… в большинстве случаев к тому моменту, когда затевают её переписывание она находится в том состоянии, что нет вообще никого, кто понимал — как она работает и, соответственно, как её чинить!
Потому, собственно, переписывание и затевается обычно.sgrey
21.03.2016 03:06Да я с вами и так согласен :) Куча технлогий — это реализация "старой" теории на разные лады, и всё :)
khim
21.03.2016 02:56А почему устаревают технологии?
Потому что кто-то хочет сделать «такое же, но своё»?
Случайно не из-за устаревания каких-либо их теоретических оснований?
Иногда — да. Но гораздо чаще — просто потому, что старые — уже не модны.
Маркетинг — великое дело.
Один с БД воюет, другой оси пишет, третий интерфейс изобретает, а четвёртый с пятым вообще что-то в науке делают, причём четвёртый пытается моделировать белки, а пятый движения планет.
Проблема в том, что первые три — пытаются решить «на новом уровне» задачи, которые уже давно решены «на старом». И «устаревают» технологии не тогда, когда появляется задача, которую они не могут решить, а когда кто-то придумывает как ещё чуть проще и лучше решить задачу, которую уже сто раз до этого решили.
Вот прямо сейчас Google потихогьку допиливает и подтягивает какой-нибудь Bionic до уровня соответствия POSIX'у. А до этого — туда же подтягивали GLibC. Который реализовывал повторно то, что уже было до этого реализовано в десятках UNIX'ов.
И это — на макроуровне! А сколько подобных «переизобретений велосипеда» в разных других частях!
Про четвёртого и пятого я не уверен (особенно про пятого), но наверняка как миниму половина (а то и больше) из того, что они делают — это повторение того, что уже кто-то где-то сделал (и обанкротился/продался/etc).
Такое ощущение, что некоторые считают технологии и теорию двумя противолежащими полюсами, делая выбор, куда пойти.
Ну дык.
Но это же не так.
Увы, но это так. Теория — это то, что изучается научным методом. Открытые публикации, новое строится на переосмыслении старого, «изобретение велосипеда» (по крайней мере теоретически) — запрещено (хотя на практике, конечно, происходит).
Технология — это что-то, что разрабывается «за закрытыми дверьми» и где «то же самое, но с перламутровыми пуговицами» — нормальное явление. Отсюда и такие маленькие «периоды полураспада».neit_kas
21.03.2016 07:09потому, что старые — уже не модны.
Соглашусь, но ещё солидарен с мнением sgrey'а про повышение юзабилити.
Увы, но это так.
Если в научных кругах, то да. В программировании, если "зарыться" в теорию, то, пожалуй, тоже да. Но я пока не встречал учебников, которые перед рассказом о какой-либо технологии не вдавались хотя бы в краткую теорию.
MacIn
20.03.2016 01:51+5Сколько ей лет — неважно. Научный метод же — пока не опровергли, придумали что-то новое, включающее старое, как частный случай, — используется.
Может статься, все сегодняшние знания
Дальше можно не конкретизировать. Это очень, до боли, напоминает реплики приверженцев альтернативной науки — "мы еще мало знаем, очень может статься, что в будущем мы откроем новое, и закон сохранения энергии не будет работать, и повсюду будут вечные двигатели".
Ветряная мельница: создаем чучело (будто бы кто-то утверждает, что нечто — вечная истина и всегда, отныне и вовек будет верным), а потом смело разоблачаем.tyomitch
20.03.2016 11:23Ветряная мельница: создаем чучело (будто бы кто-то утверждает, что нечто — вечная истина и всегда, отныне и вовек будет верным), а потом смело разоблачаем.
Комментарий, на который я отвечал, именно это и утверждал:Так вот второе приходит и уходит, а база остается.
MacIn
20.03.2016 16:31+1Комментарий, на который я отвечал, именно это и утверждал:
Нет, не утверждал. "остается" не значит "остается навсегда". Речь шла о том, что технологии и связанные с ними практические навыки меняются много чаще и быстрее, чем теория. Остается пока не открыто что-то новое, более точное. Вот вы едете в поезде, он стоит у перрона, за окном — человек. Поезд тронулся, мы говорим, что люди мимо окна проплывают и "уходят" один за одним, а перрон остается. Это не значит, что перрон будет тянуться за окном вечно, это всего лишь сравнение мимолетности появления людей и перрона.
Вы же подменили это контрастное "остается" на
считать её вечной и непреложной — это очень смело.
tyomitch
21.03.2016 00:53Я выше написал, что перрон уйдёт. Вы сейчас написали, что перрон уйдёт. Спрашивается: о чём мы спорим?
MacIn
22.03.2016 05:08Нет. Вы написали "утверждать, что перрон вечен и непреложен (=никогда не уйдет) — это очень смело" как контр-аргумент, будто бы ваш оппонент это утверждал ("утверждать...- очень смело"), тогда как утверждения о вечности с его стороны не было. Это выдуманный абсурдный и разоблаченный аргумент.
За сим откланяюсь — это очень скучная перепалка о словах, не привносящая ничего нового.
midday
20.03.2016 16:05+5Наизусть никто вас не заставляет учить =)
Давайте аналогии приведем.
Есть профессия такая — хирург. Хирург — врач прежде всего. Так вот даллее по аналогии:
В настоящее время все больше и больше людей считает, чтобы хирургом быть не нужно нафиг заканчивать 6 лет в универе, не надо этого ничего… зачем врачебное дело Хирургу? Ему нафиг не нужно знать того что преподают в универе, зачем ему знать как работают вирусы, зачем ему всякое дерьмо в виде химии, цитологии, гистологии, микробиологии, этики, психиатрии, неврологии и еще кучи других… Зачем это все? Выучил анатомии, а можно и кусок анатомии ( тот что по профилю), ну потом научился круто владеть скальпелем… и режешь всех. Работает ведь, спасает жизни… а остальное все — от лукавого
tyomitch
20.03.2016 14:12+1Объясню свою нахватавшую минусов точку зрения подробнее.
Что считалось "основами программирования" 50 лет назад?
Самобалансирующиеся деревья ещё не изобретены.
LR-парсеры ещё не изобретены.
Сжатие LZ ещё не изобретено.
Quicksort и Heapsort — свежайшие изобретения, ещё не попавшие в учебные программы.
Насколько сейчас был бы ценен программист из 1960-х, отлично освоивший тогдашнюю "базу"?
Вот настолько же программист, отлично освоивший нынешнюю "базу", будет ценен через 50 лет.
Kroid
20.03.2016 15:50-5Так вот второе приходит и уходит, а база остается.
Ага, для сферического программиста в вакууме. Дьявол, как известно, кроется в деталях: в некоторых ситуациях может быть справедливо обратное высказывание, вроде «алгоритмы приходят и уходят, а 1С (или какой-нибудь wordpress) остаётся».
Хотя на это есть стандартный ответ-лазейка «по определению»: если в определение программиста включить знание алгоритмов, тогда кто не знает — не программист, потому и в выборке не участвует. Проблема решена, правосудие восторжествовало. :)
Antelle
19.03.2016 19:33+9Ещё забыты кое-какие необходимые навыки:
http://sijinjoseph.com/programmer-competency-matrix/
Хотя и там всё не учтено, например, нет про юзабилити.
idlhero
19.03.2016 20:14+3Очередное откровение о профессиональной компетенции. Работа выполняется качественно, в срок? Дальнейшая модификация и поддержка не представляют сложности? Тогда мне как заказчику всё равно, что оканчивал исполнитель и каков уровень его эрудиции.
tamakio
19.03.2016 22:33+2Вот есть заказчик, который нанимает команду и собирается платить ей $1млн в год.
У него есть 3 команды на примете, с которыми он не работал ранее.
Они все клянутся, что в срок и поддерживать будет легко.
По каким критериям из выбирать?
solver
20.03.2016 00:11+3Это в любом случае будет лотерея.
Знания человека и качество его работы не обязательно связаны.
Знаю не одного, ну можно сказать гениального программиста, которые «себе на уме».
Да, если фазы луны и нептуна совпали, то они напишут отличный код.
Он будет клевый со всех сторон.
Беда только, что эти фазы совпадают не когда надо команде…
т.е. это абсолютно неуправляемые люди, и в общем случае они тащат команду на дно.
Sing
19.03.2016 20:22+3Странно, что такие весьма спорные пункты включены, а, например, о владении навыками написания читаемого/поддерживаемого кода и тестирования, знания структур данных и областей их применения — ни слова.
Есть ещё такой момент, как абстракции. ОС и сетевые технологии изначально созданы для того, чтобы пишущий прикладные приложения мог особо не задумываться о них. Я не к тому, что их знать не надо, я к тому что вы можете стать хорошим разработчиком, не залезая в такие дебри. Тем более, что есть области программирования, не использующие ни сеть, ни операционки.
sgrey
19.03.2016 20:30+10Ни разу не утверждал, что кроме алгоритмов ничего знать не надо. Почему-то все сразу думают об общеизвестных алгоритмах сортировок и обхода графов. Тем менее алгоритмы намного более широкое понятие, чем список известных решений типовых задач. На основе теории вычислений строится всё остальное, и как вы по-настоящему поймёте строение ОС или сети без знания алгоритмов — не совсем понятно.
В сетях например используют множество алгоритмов из теории графов. Как вы разберётесь в STP без затрагивания алгоритма остовного дерева? Как вы будете обсуждать протоколы роутнга без затрагивания Беллмана-Форда? Конечно можно разбираться поверхностно, на уровне "такая ошибка скорее всего показывает проблему там-то", и этого часто достаточно. Но имея более глубокие знания такие вещи будут всёравно очевидны.
Как вы можете узнать принципы работы ОС, не говоря о LRU, FIFO, WSClock, RB-trees и B-Trees? Объясните адресацию памяти в 64-битных система без затрагивания инвертированных таблиц. Новые версии файловых систем всё больше переходят на B-Trees. В ОС вообще множество своих алгоритмов и структур данных. А динамическое программирование используется постоянно.
А безопасность без криптографии? Это разве не алгоритмы?
Говорить об оптимизации и масштабировании, при этом утверждать что это не алгоритмическая задача — вообще смешно, честно говоря. Если понимать как рабоает СУБД, то какие запросы будут работать быстрее, а какие медленнее — вопрос достаточно лёгкий. А разницу между отдельными движками и их настройкой можно узнать в процессе работы довольно быстро.
Все технлогии, какими бы магическими они не казались, основаны на относительно небольшом количестве концепций, многие из которых появились десятки лет назад, и только сейчас начали быть популярными. Зная эти концепции освоить новые технлогии будет намного легче, а также будут очевидны их преимущества и недостатки.
Конечно не всем нужны детальные знания всего этого, и кроме самой теории вычислений нужно знать много другого. Но большинство этих знаний всёравно основывается на той самой теории вычислений — это фундамент всей информатики.
А всякие инструменты и как их использовать можно освоить по ходу работы, и на это как правило не уходит много времени, если есть голова на плечах и багаж знаний :)
Cord
19.03.2016 21:06Спасибо за коммент.
1.Согласен про пользу понимания той же теории графов и тд для работы с сетями. Тут без нее никак, но и без знания теории работы сетей, и практического опыта сама по себе математика не делает вас сразу Developerом с большой буквы
2.Безопасность отнюдь не заключается только в криптографии.
Кстати, для ряда приложений различные алгоритмы шифрования. Я условил и детально разобрал для себя RSA (и ряд других известных), в дальнейшем остались лишь базовые принципы его работы в памяти. Но отнюдь не прошел полный курс, которые преподают шифровальщикам.
Мешало ли мне это в работе? Нисколько.
3.Вот в случае с архитектурой, стэком технологий, базой данных и так далее есть такая злая штука — в реальности они работают сильно сложнее и нередко совсем не так, как мы моделируем в нашем воображении. Иначе бы никаких тестов производительности, всяких A/B проверок архитектуры на устойчивость к нагрузке и прочее не требовалось бы.
Можно здесь вспомнить умную теорему про связь алгоритма, входных данных и предсказуемость результата; можно сказать про ненулевую вероятность ошибок в коде любого продукта, помноженную на сложность и объем современных систем и железа, что дает отличные от теории результаты.
Но я просто отмечу, что помимо теоретических расчетов и выбора тех или иных решений по масштабированию или оптимизации, всегда вылезают какие-нибудь баги кэша ядра FreeBSD и распределенные файловые системы, настроенные как рассчитано, сбоят; внезапно барахлит какая-нибудь мелочь в рейде и Гластер не работает, как ожидалось, или же банально разрекламированный в новой версии языка-не-будем-называть сборщик мусора при превышении определенных пределов устраивает дикие тормоза.
Поэтому знать и уметь основы Computer Science и… (допишите по вкусу) полезно и нужно. Но без практики и реальных боевых проектов, нагрузки, живого использования, развития и тд это сферический конь в вакууме (хотя и сферический конь в вакууме тоже может победить на скачках, как мы помним — только вот в каких)Cord
19.03.2016 21:18+2Кратко — не нужно противопоставлять теорию практике.
База нужна? во многих сферах, где трудятся программисты, без нее не подняться выше определенного уровня
Практический опыт и разный нужен? Да, без него в теории можно делать великие открытия и наука рулит. Но бизнесу нужна практика.
Можно ли неуважать коллег, кто не владеет знаниями/навыками, которые вы считаете мастхэв для тру? Можно, у нас свободная страна. Но это неэффективно для группы в целом, кмк.sgrey
19.03.2016 21:25Наука в computer science вещь вполне практичная кстати. Чтобы написать о производительности или крутости какого-нибудь "открытия", нужно сделать немало опытов и привести доказательства.
Cord
19.03.2016 21:35Да, есть такое дело.
Просто почему еще я про практику написал.
Дело в том, что есть немало тонких материй, которые пока слабо формализованы.
И более того, на деле теоретически верные штуки могут мешать.
Как пример, вспоминаю ООП и паттерны. Первая практика, красивый код, старался — вылизывал. И тут жестокие требования бизнеса вынудили раз переписать, два, три — и совсем по-другому начинаешь смотреть на красивости из классов-классов и более любовно на всякие DRY, KISS, YAGNI, unix way. Потом и как с SOLID готовить понимаешь, и прочие другие вещи.
То есть существуют разные способы сделать архитектуру внутри кода, спроектировать БД, выбрать стэк технологий и так далее. И нередко теоретически правильный и красивый может быть не нужен, а какой нужен, и когда нужно добавить правильности, а когда начисто делать сразу хорошо и идеально — дается только с опытом.sgrey
19.03.2016 21:44+1В этом плане да. В книжках по дизайну много красивых паттернов и воспетие архитектур, а на деле приходится кодить в проекте, написанном по очереди шестью разработчиками независимо друг от друга, которые мало того, что о дизайне не слышали, так ещё и костылей понаделали. А поменять как следует времени нет — сроки и деньги горят. Или ТЗ такое, что никакие паттерны не подойдут, и выкручивайся как хочешь :) Поэтому понимание принципов ООП я ценю обычно больше, чем знание паттернов наизусть. Тем более у меня были примеры, когда человек лепил паттерны куда не попадя, и коверкал ими проект.
sgrey
19.03.2016 21:23Согласен, мы же не разрабатываем продукты в вакууме. В реальности приходится брать во внимание среду, железо, и способы использования продукта пользователями. Плюс не всякие теоритетически крутые штуки будут работать в реальности (кучи Фибоначчи тому пример). И для того чтобы, например, стать хорошим разработчиком сетевых приложений, нужно будет кроме принципов работы сети выучить язык и его интерфейс в сетевой протокол. Но для тех, кто знает как работает сеть это будет намного легче, по сравнению с теми, кто не знает :)
Cord
19.03.2016 21:27+1Согласен.
Я, кстати, за хорошую теоретическую базу, но без фанатизма. T-shaped, так они это называют.
А то мне вот нравится теория игр (и теория вероятностей, куда без нее), всякие там равновесия Нэша, но никогда не скажу человеку, если он не владеет ею, что он — не программист. Разве только спрошу, какая вероятность того, что среди группы из двух футбольных команд и тренеров будут одинаковые дни рождения ))sgrey
19.03.2016 21:37+3Да я тоже за уважение коллег, и если человек пишет код, который идёт в продукцию — буду называть его программистом :) Другое дело что бывают хорошие или плохие профессионалы, и вот тут как раз идёт разделение по знаниям теории.
А есть ещё люди, которые имеют звание программиста на работе, а вот писать код не могут. С такими сложнее — как их называть :)khim
20.03.2016 20:04+3Это да. Проблема в том, что есть куча народу, которые программируют, хотя делать этого — не умеют. Это уникальное явление. Нигде больше, ни в одной профессии — такого не бывает.
А знаете почему? Проблема в том, что программы не ломаются, а компьютеры обладают бесконечным терпением. Подумайте над знаменитым я смотрел лаже в лицо и не боюсь называть её по имени: Если достаточно долго месить чан с перловой кашей, в синтаксическом мусоре можно рано или поздно узреть лик Ларри Уолла.
При разработке железа (или там при изготовлении выпечки) такой подход не годится: одно неверное движение — и вы спалили что-нибудь (микросхему там или пиццу — неважно). Если ваш труд "интеллектуальный", но оценивает его человек (ну там секретарша или бухгалтер) — то тут тоже всё ясно. Но вот именно сама возможность 1000 раз безнаказанно переделывать своё поделие — и рождает вот этот феномен.sgrey
20.03.2016 20:24+2Да я работаю с целой командой таких вот "программистов", которых наша компания держит через фирму оутсорса для поддержки продуктов. Я когда смотрю на таких людей, у меня седые волосы появляются от мысли, что они каким-то образом могут попасть в команду, которая будет писать софт для автомобилей, мед. обородувания, или других устройств, от которых может зависеть жизнь или здоровье. А некоторые из них потом вероятно могут устроится преподавателями… вот уж ужас...
А основная проблема я считаю в том, что ВУЗы выпускают людей, которые не удовлетворяют даже минимальным требованиям. Каким-то образом они проходят из года в год, и даже сдают дипломы. Почему-то проваливать и исключать студентов не принято… Ну и качество самого образования во многих вузах страдает
Mirn
20.03.2016 21:38+5Я когда смотрю на таких людей, у меня седые волосы появляются от мысли, что они каким-то образом могут попасть в команду, которая будет писать софт для автомобилей, мед. обородувания, или других устройств, от которых может зависеть жизнь или здоровье.
ну вообще то там порой люди тоже бывают ...
недавние случаи
- Спрашивали что не так с компактным 100 ватным мед лазером для медицины катастроф. краткий опрос про коллектив и процесс разработку сразу выявил: "а зачем нам беттатестер, схемотехник и технолог всего на 12 программистов? они же в потолок плювать будут — пусть сами всё делают как нибудь". в BOM листе кондёры даже не помечены какие керамика какие тантал или электролиты. хотел ответить: "всё плохо", потом подумал и отказался от аудита (это ещё та распильная тема, сказавшему правду могут как минимум не заплатить). Это не в первый раз. Такое слышал и от производителей кан локеров авто (зачем нам скорость анализировать, пришла команда — авто заблокировалось!), и от разрабов промышленных штук (ардуину запеткивали в систему управления печкой 100кВатт, где то на хабре подобное с груз лифтом видел)
- На одном форуме люди дели умный выключатель света на распебри пи, причём тот функционал который японцы в гостиницах запилили дополнительным третьим проводом и солинойдом, ценой всего в 2 раза выше обычного выключателя света.
- На гиктаймсе один выложил "прикольный способ обеденения ардуин в герлянду", я пытался объяснить что так нельзя делать, что могут быть в ряде случаев глюки и не таких редких, что передатчик и приёмник уарта не связаны по скорости по тем же причинам по каким стоит дифференциал между левым и правым колесом — иначе они в поворот зайдут только один раз. или ось порвёт из за чуток разных скоростей слева и справа — что у них и будет. Никто не понял, вообще, один нашол подобные упоминания и случае но быстро забыл и опять меня стал обвинять и минусовать. Ну ладно.
- Человек писал курс статей как на асме для МК и железа сделать супер-пупер сверхмалый размер прошивки, три статьи к этому вёл, я в каментах взял и реализовал на чистом gcc очевидным способом, без уродования кода при этом размером кода меньше чем на асме в статье и всего за 10 минут. На вопрос "что я делаю не так? и зачем оно нужно" внятного ответа не получил. И вообще каждый десятый разраб железа хочет поиграть в майнкрафт — накопать руды, сделать транзистор, процессор, самому сделать компилятор и тд. Вместо того чтоб не маяться дурью, а уметь хотя-бы нормально кодить на банальном Си. "иначе я не разберусь в этом как надо" — их лозунг. При этом из таких людей часто отвратительные инженера.
Очень много овер и гипер-инжиниринга, часто наблюдаю такое: "когда в руках молоток то всё становиться гвоздями", и тому подобное. Благо большая часть электроники терпит такие издевательства — даже самый хреновый дешовый и подделываемый стабилизатор имеет стопятьсот защит по теплу, овервольтажу, перегрузке, процы могут работать при сильной просадке напруги незаметно…sgrey
20.03.2016 21:47Да это даже мелочи. Было ведь множество серьёзных случаев, когда например рентгеновский аппарат давал десятикратную дозу за раз (или больше, я уже не помню) потому что не проставили ограничение мощности. Или когда шасси самолёта не выдвинулось при посадке из-за сильного ветра, и софт думал что самолёт на высоте летит, а не садится. Список довольно длинный. Только в этих индустриях ввели довольно строгий режим разработки и тестирования теперь.
Только вот 100 ваттным лазером вы меня удивили… в россии было наверно?Mirn
20.03.2016 22:13+6да, всё это у нас в России, часто Москва и Питер.
проблема то ещё в отношении к своим косякам:
часто вместо того чтоб молча исправить хотябы костылями, они в ответку сразу юридически и административно бьют и больно: Были проблемы в крипто и электро безопастности в служебных блоках шахтных пусковых комплексов я доложил куда надо. Они подёргали за ниточки чтоб меня хотели призвать в отвратительную часть, вписали долг в 70тр заводу (при зарплате в 5тр) решение суда получил уже на следующий день (смог апплировать), аннулировали трудовую будто на заводе я и не работал. Выдачу диплома задержали. Вообщем сделали всё чтоб получилось что доклад о проблемах пришол от безработного человека без профильного образования и опыта работы. Ладно без уголовки.
В общем поэтому теперь я не связываюсь с гос сектором особенно с градообразующими предприятиями которые в городе имеют половину всех заведений.
Мне после этого смешно на нытьё рунета что в сбитом самолёте микросхемы флеш-памяти были в гражданских корпусах.
Очень часто всё гораздо хуже, ладно если военка вообще работает.khim
21.03.2016 04:03Увы, тут со времён "позднего СССР" мало что изменилось. Радует (или огорчает — тут не понять): насколько мне известно госучереждения везде одинаковы — в Штатах очень похожий бардак.
Почитайте хотя бы Фейнмана, про то как он катастрофу с Шаттлом расследовал. Между строк там легко увидеть: все рядовые исполнители были в курсе того, что они, в общем, фигню творят — но не хотели, чтобы "доклад о проблемах пришол от безработного человека без профильного образования и опыта работы". Потому когда подвернулся человек, которому "по статусу" можно было "мутить воду" — тут сразу такое вскрылось, такое… а без него никто ничего не замечал, ни-ни. Все — "учёные идиоты", "узкие специалисты" и не при делах.
khim
20.03.2016 21:44Почему-то проваливать и исключать студентов не принято…
Деньги. Независимо от системы: либо выделаемые из бюджета, либо приносимые самим студентами.
Выгнал студента — порезал себе зарплату!
Кто на такое пойдёт? Ясно кто: горсточка ВУЗов, которые «у всех на слуху» и которым нужно «держать марку».
Для остальных это — как серпом по кошельку.
Девальвация высшего образования — это всемирная проблема, Россия не исключение.sgrey
20.03.2016 21:53+2Да, в вузах в других странах похожая проблема тоже. Многие люди получают неплохие оценкци и выпускаются, а при этом знаний почти нет. Но универы в других странах всё же больше заботятся о своей репутации, поэтому критерии приёма и выпуска по жёсче у них. Да и структура классов другая.
sgrey
19.03.2016 21:50+1Ещё большая проблема в разработке — кривая спецификация задания. Часто клиент сам не знает что и как будет, а команда, которая берётся за разработку не заставляет писать детальное ТЗ. Отсюда и получаются эти самые проблемы, когда вылезают непонятные баги из-за среды, в которой используется продукт. Или не все use cases покрыты, и потом нужно делать костыли, когда в конце оказывается что заказчик забыл указать/хочет поменять одну из главный функций
dimview
19.03.2016 21:20+2Необходимо определить, о какой именно разработке идёт речь. Есть CRUD, есть shrinkwrap, есть внутренний софт, одноразовый, микроконтроллеры, научный, игры — у них у всех разные требования.
Переводчику с китайского на французский необязательно знать арабский, а переводчику с арабского — нужно.
Mirn
19.03.2016 22:02+1возьмём программиста и скажем что он НЕ умеет или не использует:
- Базы данных
- Системы контроля версий
- Сложные элементы языка, например для Pure C это уже switch case, обратный do {} while и тд
- XML язык и много много прочих инструментальных включая regexp
- Методологии разработки
- Использование готовых библиотек чуть сложнее STL в с++
- Общие алгоритмы чуть сложнее связанного списка и бинарного дерева.
и т.д.
Ваша реакция: "Да это не программист даже!" да?
Нет такие бывают.
И даже пишут мультиплатформные штуки, такие что работают и в железе и в ПК и на веб сайте, и даже компилируются из одного исходника, и даже плавный граф монохромный интерфейс даже в веб эмуляторе летает, и даже с 1-5% загрузки ЦПУ.
Даже работает с множеством языков, включая китайский.
И даже продаётся, в том числе за рубежом.
И даже продаётся не один год и не пять лет, больше.
Нет, и это не стартап
и не основная работа.
Это просто хобби, карл
Ладно, другой пример, ближе ко мне:
Наш сотрудник на работе разработал кучи прошивок для кучи шлюзов, они работают нормально без глюков, уже не первые 5 лет, и счёт изделий далеко не 4-5 значный.
Но…
недавно я его прошивку компилировал под новым gcc 5.2 для мк арм, и сюрприз: оказалось что библиотечная функция ОС файлового ввода/вывода select и группа констант FD_xxx им была занята на свои нужды (свою функцию селект повесил на сигнал селект SD карты) и естественно компилятор выдал ошибку о занятом имени. Называется человек всю свою жизнь кодил под МК. И плохим программистом назвать его у меня не повернётся язык. Работает же всё, и модифицировать что либо из его кода другие могут, другие же не называли его ни быдлокодером, ни криворучкой. Он отдаёт свой код и претензий нет, вопросов особых тоже. Разве что чисто перфекционистких: что вот это можно было бы переписать чуток получше, но ничего особо это не даст.
Ну и я вот тоже не имею ни опыта, ни теории работы с базами данных, с алгоритмами у меня тоже беда типа хитрого обхода графов. Что теперь я не проф пригоден? Хотя пишу и под МК и под ПК и иногда надо на своём сервере что-то сделать, то и для веба совсем кроху (называется видел и правил javascript, php и тд).
так ли это всё важно?
почему очень много неплохих программистов исходя из всех требований и обсуждаемых штук оказывается за бортом?
и я не только это про алгоритмы.
И вообще они кажутся не программистами после чтения этих всех статей.
Особенно это чувствуется при поиске работы — когда весь твой опыт нивилируется теми тегами что требуют работодатели и по факту только на них и смотрят (бд, аджайл, буст, скуель, гит и тд).
И не важно что твой знакомый кодит с времён ДВК и Z80 — для работодателей и коллег которые его не знают: "ну вроде кодил в закрытом заводе 30 лет, но кодил ли, ой не факт. А по вечерам сделал никому ненужный стопятьсот первый гаджет, от которых всех тошнит уже, и дал в доказательства какие то ссылки на финском, испанском и китайском, вообщем закрыть их".MacIn
19.03.2016 22:34+1так ли это всё важно?
почему очень много неплохих программистов исходя из всех требований и обсуждаемых штук оказывается за бортом?
Во-первых, "пять миров Спольски".
Во-вторых, как мы определим вот это "неплохой"? Каковы формальные критерии?Mirn
19.03.2016 22:39-1как мы определим вот это «неплохой»? Каковы формальные критерии?
я бы предложил взять такой критерий как прибыль с разработчика
работодатели этим интересуются напрямую,
сотрудники и коллеги косвенно: чтобы было у кого поучиться, чтоб мозг не сношал пустиками, чтоб его код не пришлось переделывать и тд,
кадровики и агенства по своему: чтоб как можно быстрее скушал работодатель или подходило как можно ближе квадратно-гнездовым методом (эдакая функция минимального хеммингового растояния).MacIn
20.03.2016 02:00+3я бы предложил взять такой критерий как прибыль с разработчика
Совершенно абстрактно: берем двух людей, один выдает кое-как работающий, нерасширяемый продукт за 1 единицу времени, второй — за 2, но надежный и расширяемый. Зарплата второго выше — выше ведь его квалификация, а вот прибыль выше с первого. Пока выше с первого, потому что его продукт можно уже продать, а ему заплатить пол-копейки. А что будет завтра, когда его продукт будет взломан? Потеряет пользовательские данные?
чтобы было у кого поучиться
Это, конечно, здорово. Но может быть следствием того, что все остальные, кто будут учиться у N — вообще профнепригодные дятлы.
чтоб мозг не сношал пустиками
"Не сношать моз пустяками" как-то не поддается формализации.
чтоб его код не пришлось переделывать
Это уже лучше. Не кажется ли вам, что переделывать чей-то код придется реже, если этот кто-то обладает знаниями и изначально принимает более правильные решения? По применению алгоритмов или структур данных, прости господи, в частности.
Areso
20.03.2016 16:00Иногда лучше выйти на почти пустой рынок с криво написанной программой, чем выдать «на гора» супер приложение на уже сформировавшейся рынок. Даже если потом забьют на обновления и безопасность и будут утечки (да, некая фриланс биржа, я говорю о тебе), но это уже вопрос не к разрабам, а к владельцам/менеджерам.
MacIn
20.03.2016 16:37+1Иногда, без конкретики нет смысла обсуждать. Я привел пример, в котором это неважно — временные отрезки в 1 и 2 единицы равно допустимы.
khim
20.03.2016 17:42Иногда лучше выйти на почти пустой рынок с криво написанной программой, чем выдать «на гора» супер приложение на уже сформировавшейся рынок.
Вот для этого и нужны алгоритмы и некоторая забота о дизайне. Если же вы «забьёте на всё» и сделаете всё возможное для того, чтобы выйти на рынок первым — то вы потом очень быстрое упрётесь в ограничения своей платформы и вам потребуется всё передалать.
Между скоростью выхода на рынок и качеством всегда нужен баланс.
Посмотрите на рынок персоналок, к примеру: Altair, Apple II, Sinclair, Commodore, Acorn — все они «вышли на полупоустой рынок» с «криво созданными системами» — и все проиграли. Почему? А потому что пресловутый IBM 5150 оказался устроен так, что его не пришлось выкидывать и начинать всё с нуля.
А вот уже те, кто пришли на рынок когда он закрылся (NeXTы всякие или BeBox) — да, те уже не имели никаких шансов.
Во всём нужен баланс. Человек, «ушедший в придумывание алгоритмов» и отказывающийся выдавать в премлемые сроки результат столь же плох, как и человек, сотворивший код, который потом придётся выкинуть нафиг.
Хотя бывает и так, что компании удаётся это пережить (в примере выше: Apple, начавшая одной из первых, сменившая одну хромую лошадь на другую, тоже не слишком здоровую, спаслась купив NeXT, который появился слишком поздно для того, чтобы выжить в одиночку), но это — большая редкость.
Mirn
19.03.2016 22:51Во-первых, «пять миров Спольски».
Я знаю людей которые одновременно подпадают и под 3-4 мира спольски и под большую часть моего списка в корневом камменте к данной статье.
Но результаты включая финансовые у них отличные и они точно никогда работать на дядю только из за денег не будут.MacIn
20.03.2016 01:55включая финансовые у них
Это не показатель — мы же о разработке ПО, а не о фондовых рынках или зарабатывании денег.
Про миры я отметил, чтобы напомнить о том, что критерии необходимх навыков зависят от отрасли/подотрасли, где занят человек.
loz
19.03.2016 23:56+2Хорошо написано, да. Порекомендуйте, что почитать / изучить на тему архитектуры и мастшабируемых приложений?
brainick
20.03.2016 02:18+2>>Во-вторых, без опыта использования реальных стэков технологий (как ПО, так и осей/железа) программист с крутыми теоретическими знаниями может блистать на топкодере, но залажает примитивнейшую задачу по созданию масштабируемого приложения.
Дядя Вася — «сильный» шахматист. «Сильный» потому что обыгрывает всех в своём дворе уже лет десять.
Дядя Вася презрительно относится ко всяким книжкам по теории, и считает что его «опыт» и гениальная
шахматная интуиция делает его непревзойденным шахматистом. Объективно дядя Петя играет в силу максимум 3 разряда.
Пионэр Петя недавно записался в шахматный кружок, где усердно изучает основы шахматной игры и даже уже узнал, чем отличается испанская партия от сицилианской защиты.
Иногда дядя Вася играет с Петей несколько партий, натягивает (==обыгрывает) Петю,
отпускает ему шелопет и со словами «Ну вот видишь школота, фигня вся твоя теория» или «Ну что, в твоих книжках не было метода против моего хода» отпускает Петю.
Вот только (как любит выражаться доктор Пилюлькин) через пару-тройку лет, пионэр Петя, поставив себе дебют
и усвоив основы комбинационной и позиционной игры, будет за доской придавать дяде Васе вращательное движение в вертикальной плоскости относительно неподвижной оси, а дядя Вася по-прежнему будет способен обыгрывать только таких же балбесов, как и он сам.
SerCe
20.03.2016 02:26-14. Безопасность. Только с опытом приходит, на лабораторных или олимпиадах этому не натренируют.
А вот с этим тезисом не согласен.
serf
20.03.2016 03:15+1Кстати я бы не хотел себе в команду человека эксперта в алгоритмах, но без опыта работы над реальными проектами и задачами, точнее без опыта успешного запуска и развития проектов. Есть ведь мнение что всякие "лаборанты" рубящие в алгоритамах, ученые всякие, пишут корявый код.
brainick
20.03.2016 03:28+1>>Есть ведь мнение что всякие «лаборанты» рубящие в алгоритамах, ученые всякие, пишут корявый код…
который и ложится в основу какого-нибудь Гугла, Яндекса или Биткойна.
uvelichitel
20.03.2016 12:35+1Можно сказать жестче — для большинства задач вы будете профнепригодны...
и правда жестко. Странное обращение к читателю, своей радикальностью вызывает страх и уважение к автору. Резюмируется призывомвсе-таки более осторожно относился к окружающим
И заканчивается ссылкой на отличные курсы.
Как то текст не по Станиславскому построен.
velvetcat
20.03.2016 14:46-1Просто надо параллельно практике подучивать алгоритмы, желательно те, что используются внутри используемых технологий. Не до, не вместо, а вместе, оставляя приоритет за практикой.
rafuck
20.03.2016 15:48+2Забавный пример проф. деформации. Прочитав фразу «не владеет пониманием доступных ему в *nix среде готовых инструментов и пишет свой (для запуска джобов — свой крон изобретает, условно) — то это труба.», воспринял слово «труба» неправильно, и на полном серьезе пытался осознать сказанное в терминах pipeline.
webhamster
21.03.2016 09:41+4Автор описывает частности и возводит их в ранг знания. Но это ошибка.
Люди, разбирающиеся в алгоритмах, без проблем осваивают частные рабочие технологии "и другие страшные слова".
И я видел много людей, которые не имеют базиса, но разобрались с несколькими частными технологиями. Знания их добыты колоссальным количеством времени или большим опытом — неважно. Важно то, что некоторые из них свою мозаику в голове представляют как идеал. И им сложно смириться с тем, что их знания механистичны по своей природе, и представляют собой только практическую ценность в режиме " чтобы все работало".
MrEsp
21.03.2016 09:53+4Архитектура — очень хорошо. Знание алгоритмов — все таки не один и тот же, хоть и связанный скилл.
Базы данных: есть особый спектр специалистов, они с базами данных не работают вообще и не про какую оптимизацию запросов everyday не слышали и не услышат. (ну, например, среди программистов C++ такие встречаются) Это, однако, не означает, что они не смогут оптимизировать запрос. Потому что решает в конечном счете понимание принципов. В комментариях к этой и изначальным статьям прослеживаются выводы типа "Успех проекта был обусловен знанием пяти команд Unix'а, а не знанием алгоритмов". Это мне напоминает особо интересные собеседования по языкам программирования, где ставятся вопросы из разряда "А какой в методе Y у класса X аргумент номер 2?" Имхо, более толковый специалист — тот, кто НЕ зная этих 5-ти команд или не зная этого метода, сможет предположить их наличие, сможет найти эти объекты и разобраться в них, применить их на практике. Это одна из причин, по которой на некотоых собеседованиях вы не увидите сложных тестов из 40 вопросов на знание языков C++ и C# или на знание стандартной библиотеки. К примеру, иногда приходится собеседовать людей (совсем зеленых на низкие позиции), которые не знают внутренних особенностей STL. Но если они способны продемонстрировать понимание, как самостоятельно реализовать ту или иную вещь в STL — это гораздо важнее.
mpetrunin
21.03.2016 10:00+4Это всё равно, что написать заголовок "Должен ли учёный знать биологию?" и потом долго расписывать на примере математика, что учёный может сколько угодно знать об устройстве тела, о том, как обеспечивать эффективную работу мозга и т.п., но без глубокого знания математических дисциплин (алгебры, геометрии, теории чисел и т.п.) учёный проф. непригоден. (на случай, если моя аналогия непонятна, напомню, что кроме математиков учёными называют ещё биологов, физиков, философов и т.п.)
Программист программисту рознь. Автор, как мне показалось, писал имея в голове равенство программист=веб-программист. И я посмотрю на автора как он без знания алгоритмов, или хотя бы умения их искать, реализует какую-нибудь очень критичную к производительности программу на OpenCL, зависящую, например, от разложения многочлена на множители.khim
21.03.2016 13:53+2К бесу OpenCL. Я ведь тоже — веб-программист. Не сейчас, но в прошлом. И помнится мы лет пять назад решали одну задачку из серии "сетевых технологий": успеем мы прогнать за месяц через имеющиеся у нас каналы данные в базу или дешевле и надёжнее будет всё-таки пропускать через таможню. Задачка простоя, в общем-то: данные подвозились, если мне не изменяет память, на 100 HDD в месяц, на каждом HDD 2TB (это было выгоднее, чем уже существовавшие тогда 4TB)...
Но я другом: если всё это потом, после пересылки, загрузить в SQL-базу, то никакая "оптимизация запросов" не поможет! Нужны свои структуры и нужно весьма много алгоритмов, чтобы со всем этим совладать.
Но вообще — автор прав (я про это уже писал), как ни странно. Подавляющее большинство ПО — делается для конкретного заказчика. И его цена играет решающее значение. Сделать что-то тяп-ляп, без алгоритмов и без архитектуры — зачастую дешевле и проще.
Это-то всё понятно. Непонятно другое: почему вдруг люди, которые всю жизнь работали, грубо говоря, в Макдональдсе и даже испекли там 100500 гамбургеров засунув их в печку вдруг заявляют что они могут приготовить классный обед в ресторане без знания того какие продукты с чем сочетаются и вообще "без изучения теории". Вот это-то откуда берётся?
А с тем, что классный повар — это не просто человек, отлично теоретически изучивший свойства продуктов — никто и не спорит. Глупо и бессмысленно.
scifix
21.03.2016 14:44+2Итак подытожим: знание алгоритмов нужно, технологий тоже нужно, понимание архитектуры и др. основ программирования необходимо, мозг во включенном состоянии нужен обязательно. Все — тему можно закрывать.
vyatsek
21.03.2016 20:26+3Мне кажется программист, как инженер, прежде всего должен понимать для чего создавался инструмент и в каких случаях им целесообразно пользоваться. Для этого он должен уметь разобраться и понять сущность этого инструмента. Алгоритмы еще один обширный инструмент, который немного бы надо знать, для кругозора. Весь говнокод который я видел был поражден плохим руководством, отсутствием взаимодействия в команде и недостаточным уровне IQ для рационального использования той или иной технологии. Даже зная алгоритмы, плохой программист и все равно КРИВО применит, я незнающий прямой, изучит и применит прямо. Неправильные пчелы делают неправильный мед.
У меня сейчас знания по лагоритмам посредственные, я бы сказал просто имею представление, при необходимости буду читать учить и разбираться, ровно как и с другими технологиями. На изучение какой-то технологии уходит больше времени, на какой-то другой меньше, но голова с прямыми руками вероятнее всего со временем будет приближаться к верному результату.
Battle_Hamster
28.03.2016 18:32«что у него в веб-приложении не грузится определенная часть данных из-за неверно прописанных роутов или лагающего DNS-сервера.»
Я звиняюсь, но автор действительно сталкивался с тем, что ЧАСТЬ ДАННЫХ не грузилась из-за трассы роутинга?
Или автор тоже не сильно в курсе сетевых технологий?Cord
28.03.2016 19:34У вас открывается веб-страница, отрабатывают аякс-запросы, уходящие на поддомены.
Часть скриптов грузится с других поддоменов.
Удивительным образом один из поддоменов смотрит на сервак с другой версией кода,
чем тот, который вы тестируете (про дальнейшую цепочку распределения через балансировщики я не пишу).
Допереть, почему код в ответ на аякс запрос, возвращает не то, что нужно, хотя вроде бы работает,
могут далеко не все. Хотя когда знаешь ответ — это очевидно.
Кейс из жизни, если что.
Ну а про неверно прописанные NS-записи и глюки из-за этого думаю, у каждого полно историй из опыта.
amaksr
После этой статьи тему алгоритмов уж точно можно закрывать. Автору плюс.
MacIn
Тема алгоритмов, поднятая (в последний раз, недавно) статей "нужно ли программистам знание алгоритмов" говорит о знании а. как о необходимом условии. Эта же статья:
говорит о том, что знание а. не является достаточным. Это не контр-аргумент и не опровержение.
Весь спор шел как раз о том, необходимо ли знание алгоритмов. А уж "знания теории без практики мало для реальной работы" (данная статья об этом) — просто трюизм.
Cord
Вообще, я имел в виду немного другое. Посылов несколько:
Но что тогда мешает утверждать, что умение работать с указателями/памятью/подставьте сами также является необходимым, чтобы называться программистом с большой буквы.
Это вопрос точки зрения, и IMHO не к одним алгоритмам сводится минимальный набор знаний, навыков и паттернов мышления.
И что эти вещи приходят лишь с практикой, но начинаются с признания, что это тоже нужно изучать. They say, the first step is to admit you have a problem.
MacIn
Никто. Более того, это так и есть, если речь идет о низкоуровневом (условно) программировании. С алгоритмами другая история — их придется использовать и при написании ОС или драйверов, так и при написании какого-нибудь высокоуровневого пакета.
Это то же самое: "не к одним" — отрицание достаточности условия. Об этом речи и не шло.
DrPass
Мне кажется, ваша статья имела бы смысл, если был бы спор, что нужно знать программисту, алгоритмы _или_… что-то другое из вышеперечисленного. Но такого спора вроде бы нигде не было, ибо он сам по себе абсурден и нелогичен. А так, и ежу понятно, что знания алгоритмов не достаточно для того, чтобы быть программистом. Собственно, это никто и не утверждал, ни в той статье, на которую вы ссылаетесь, ни в комментариях к ней.
khim
За что плюс-то? Статья состоит из кучи банальностей и откровенного вброса: Быть может, кто-то забыл когда-то прочитанные базовые алгоритмы или структуры данных, но его компетенции в той же архитектуре или безопасности настолько превосходят ваши, что смотреть свысока он может и на вас.
Один-единственный пример человека, который "забыл когда-то прочитанные базовые алгоритмы или структуры данных", но которому при этом "компетенции в той же архитектуре или безопасности" помогают делать классные вещи — и всё смотрелось бы по другому.
Я знаю приличное количество людей, которые "забыли когда-то прочитанные базовые алгоритмы или структуры данных" и в результате угробили крупные проекты, знаю людей, которые выиграли за счёт знания предметной области (и проекты которых потом пришлось долго и упорно переписывать людям, знакомыми с алгоритмами), но я не знаю ни одного человека, который попал под пафосную фразу, ради которой, как я понял и написана статья.
Приведите пример — будет что обсуждать.