Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 143
После этой статьи тему алгоритмов уж точно можно закрывать. Автору плюс.
Тема алгоритмов, поднятая (в последний раз, недавно) статей "нужно ли программистам знание алгоритмов" говорит о знании а. как о необходимом условии. Эта же статья:
говорит о том, что знание а. не является достаточным. Это не контр-аргумент и не опровержение.
Весь спор шел как раз о том, необходимо ли знание алгоритмов. А уж "знания теории без практики мало для реальной работы" (данная статья об этом) — просто трюизм.
Я утверждаю, что знание алгоритмов и даже наличие системного образования не делает вас хорошим разработчиком
говорит о том, что знание а. не является достаточным. Это не контр-аргумент и не опровержение.
Весь спор шел как раз о том, необходимо ли знание алгоритмов. А уж "знания теории без практики мало для реальной работы" (данная статья об этом) — просто трюизм.
Вообще, я имел в виду немного другое. Посылов несколько:
- Утверждать, что алгоритмы являются необходимыми, можно.
Но что тогда мешает утверждать, что умение работать с указателями/памятью/подставьте сами также является необходимым, чтобы называться программистом с большой буквы.
Это вопрос точки зрения, и IMHO не к одним алгоритмам сводится минимальный набор знаний, навыков и паттернов мышления.
- Также хотел подчеркнуть, что есть вещи, которыми мало озадачиваются те, кто бросается громкими фразами, по моей нерепрезентативной выборке. Про ту же архитектуру, про безопасность, про учет в разработке еще и как это будет поддерживаться админами хотя бы (аки учет всей стоимости владения автомобилем, а не его цены в салоне).
И что эти вещи приходят лишь с практикой, но начинаются с признания, что это тоже нужно изучать. They say, the first step is to admit you have a problem.
Но что тогда мешает утверждать, что умение работать с указателями/памятью/подставьте сами также является необходимым, чтобы называться программистом с большой буквы.
Никто. Более того, это так и есть, если речь идет о низкоуровневом (условно) программировании. С алгоритмами другая история — их придется использовать и при написании ОС или драйверов, так и при написании какого-нибудь высокоуровневого пакета.
не к одним алгоритмам сводится минимальный набор знаний, навыков и паттернов мышления.
Это то же самое: "не к одним" — отрицание достаточности условия. Об этом речи и не шло.
Мне кажется, ваша статья имела бы смысл, если был бы спор, что нужно знать программисту, алгоритмы _или_… что-то другое из вышеперечисленного. Но такого спора вроде бы нигде не было, ибо он сам по себе абсурден и нелогичен. А так, и ежу понятно, что знания алгоритмов не достаточно для того, чтобы быть программистом. Собственно, это никто и не утверждал, ни в той статье, на которую вы ссылаетесь, ни в комментариях к ней.
За что плюс-то? Статья состоит из кучи банальностей и откровенного вброса: Быть может, кто-то забыл когда-то прочитанные базовые алгоритмы или структуры данных, но его компетенции в той же архитектуре или безопасности настолько превосходят ваши, что смотреть свысока он может и на вас.
Один-единственный пример человека, который "забыл когда-то прочитанные базовые алгоритмы или структуры данных", но которому при этом "компетенции в той же архитектуре или безопасности" помогают делать классные вещи — и всё смотрелось бы по другому.
Я знаю приличное количество людей, которые "забыли когда-то прочитанные базовые алгоритмы или структуры данных" и в результате угробили крупные проекты, знаю людей, которые выиграли за счёт знания предметной области (и проекты которых потом пришлось долго и упорно переписывать людям, знакомыми с алгоритмами), но я не знаю ни одного человека, который попал под пафосную фразу, ради которой, как я понял и написана статья.
Приведите пример — будет что обсуждать.
Один-единственный пример человека, который "забыл когда-то прочитанные базовые алгоритмы или структуры данных", но которому при этом "компетенции в той же архитектуре или безопасности" помогают делать классные вещи — и всё смотрелось бы по другому.
Я знаю приличное количество людей, которые "забыли когда-то прочитанные базовые алгоритмы или структуры данных" и в результате угробили крупные проекты, знаю людей, которые выиграли за счёт знания предметной области (и проекты которых потом пришлось долго и упорно переписывать людям, знакомыми с алгоритмами), но я не знаю ни одного человека, который попал под пафосную фразу, ради которой, как я понял и написана статья.
Приведите пример — будет что обсуждать.
Мое мнение знать самые основы алгоритмов — нужно: что такое O(n), бинарный поиск, хеш таблицы. Без этого вы не сможете понимать как работает индекс в базе данных или как работает HashMap'а в Java, когда ArrayList лучше LinkedList'a. Это равносильно пользоваться ООП или реляционными базами данными не понимая SQL или полиморфизма. Можно, но будут проблемы с пониманием элементарных вещей и общением с коллегами (если не сможете понять объяснения про O(n) являясь старшим программистом на вас будут смотреть странно). Ну и в конце концов чем же занимались в универе, если грубо говоря высшую математику выучили, а таблицу умножения забыли.
А вот знать наизусть точный алгоритм красно-черного дерева или десяток алгоритмов обхода графой — полезно, но не обязательно. Так как в реальной работе встречается это редко и проще открыть вики (или другой источник) и повторить знания, чем пытаться писать по памяти с риском ошибиться.
А вот знать наизусть точный алгоритм красно-черного дерева или десяток алгоритмов обхода графой — полезно, но не обязательно. Так как в реальной работе встречается это редко и проще открыть вики (или другой источник) и повторить знания, чем пытаться писать по памяти с риском ошибиться.
Точное знание — оно вообще мало где нужно. На практике "знание алгоритмов", по большому счёту, не очень-то и нужно. Что нужно — так это метазнание. То есть знание того какими свойствами обладают алгоритмы.
Простейший пример: поиск подстроки в строке. Есть банальный перебор, есть КМП, есть Бойер-Мур. Так вот фишка — не в том, чтобы уметь их реализовать (это не так-то просто, особенно для последнего), фишка в том, что "тупой перебор" и КМП замедляются при удлинении подстроки (хотя КМП, конечно, замедляется не так сильно), фишка в том, что БМ может ускоряться при удлинении подстроки, которую мы ищем!
Что, как бы, нифига не фокус, но если про алгоритмы не знать вообще ничего — то вначале немного ошарашивает.
Вот как человек, который про это забудет сможет спроектировать правильную архитектуру? И где окажется его коллега, который на это заложится, будет пытаться менять формат в попытке удлинить подстроки и сделать их менее регулярными (это тоже помогает БМу), но забудет (или будет не в состоянии) понять что библиотека, которой он пользуется замедляется при удлинении подстрок, не ускоряется?
К сожалению невозможно получить метазнания не получив знаний. Их можно вызубрить, но не почевствовав алгоритмы, не "поигравшись с ними" вы не научитесь строить правильную архитектуру.
А точные формулировки и описания — это не проблема ни разу, да, для этого литература есть.
Простейший пример: поиск подстроки в строке. Есть банальный перебор, есть КМП, есть Бойер-Мур. Так вот фишка — не в том, чтобы уметь их реализовать (это не так-то просто, особенно для последнего), фишка в том, что "тупой перебор" и КМП замедляются при удлинении подстроки (хотя КМП, конечно, замедляется не так сильно), фишка в том, что БМ может ускоряться при удлинении подстроки, которую мы ищем!
Что, как бы, нифига не фокус, но если про алгоритмы не знать вообще ничего — то вначале немного ошарашивает.
Вот как человек, который про это забудет сможет спроектировать правильную архитектуру? И где окажется его коллега, который на это заложится, будет пытаться менять формат в попытке удлинить подстроки и сделать их менее регулярными (это тоже помогает БМу), но забудет (или будет не в состоянии) понять что библиотека, которой он пользуется замедляется при удлинении подстрок, не ускоряется?
К сожалению невозможно получить метазнания не получив знаний. Их можно вызубрить, но не почевствовав алгоритмы, не "поигравшись с ними" вы не научитесь строить правильную архитектуру.
А точные формулировки и описания — это не проблема ни разу, да, для этого литература есть.
но забудет (или будет не в состоянии) понять что библиотека, которой он пользуется замедляется при удлинении подстрок, не ускоряется?
Ну вообще, я бы в любом случае не доверял теории, а написал benchmark'и и протестировал все библиотеки на разных конфигурациях компьютера и разных длинах строк. Дело в том что теория это хорошо, но практика лучше, так как скажем в Java замечательный в теории метод может создавать огромное количество временных объектов. что будет постоянно вызывать сборщик мусора и в результате метод окажется хуже не такого замечательного в теории метода.
Метазнание тоже можно выучить при необходимости, тут главное чтобы было понимание что если задача про графы, а ты про них ничего не знаешь, то нужно потратить пару часов и прочитать разные алгоритмы графов. Учитывая что такие задачи у многих появляются раз в полгода это оправданая трата времени. Хуже когда программист самоуверенно пытается придумать все сам. Тем более что появляются новые алгоритмы и метазнание 3-5 летней выдержки может быть уже не актуальным.
Ну понятно, что если у вас на что-то вся система завязана, то вы и backmark'и напишите и литературу проштудируете. Но невозможно на каждую строчку кода писать benchmark! И как показывает практика угадать где будет "узкое место" далеко не всегда удаётся.
И вот тут… метазнание 3-5 (да даже и 20!)-летней давности — гораздо лучше, чем "изобретение велосипеда" всё равно.
P.S. Хотя как вот тут хорошо заметили метазнание 50-летней давности — всё-таки не годится. Иногда нужно и книжки читать :-)
И вот тут… метазнание 3-5 (да даже и 20!)-летней давности — гораздо лучше, чем "изобретение велосипеда" всё равно.
P.S. Хотя как вот тут хорошо заметили метазнание 50-летней давности — всё-таки не годится. Иногда нужно и книжки читать :-)
Тут может быть мы просто о разных языках говорим, в Java "узким местом" будут кривые запросы к базам данным или к сети, но редко конкретная библиотека, к тому же там особенно актуально про зло преждевременной оптимизацим, в 99% случаях важно решить задачу максимально просто и понятно (грубо говоря искать строки исключительно библиотекой самого языка), чем заботиться о производительности. А в оставшемся 1% проблемы решаются анализом готового приложения с профайлером.
В языке C или С++ вопросы оптимизации и алгоритмов, конечно, имеют совсем другое значение.
В языке C или С++ вопросы оптимизации и алгоритмов, конечно, имеют совсем другое значение.
Выбор языка — он ведь тоже от задач зависит. Собственно с него всё начинается.
Если вам нужна максимальная производительность и вы выбрали Java'у — то вы уже проиграли. И никакой "анализ готового приложения с профайлером" вас не спасёт. Приложение будет совершенно точно жрать память в диких количествах и, возможно, тормозить. Причём если со вторым — ещё можно кое-как бороться (хотя и сложно), то первое — исправить невозможно вообще.
С другой стороны Java обменивает возможность писать эффективный код на возможность писать надёжный код: систему, написание и отладка которой на C у вас займёт, условно говоря, 10 лет на Java вы сможете написать за 2-3 года.
Когда вы создаёте дизайн системы — вам с самого начала нужно определиться чего вы хотите, уж извините. А языки — это уже вторичное.
Если вам нужна максимальная производительность и вы выбрали Java'у — то вы уже проиграли. И никакой "анализ готового приложения с профайлером" вас не спасёт. Приложение будет совершенно точно жрать память в диких количествах и, возможно, тормозить. Причём если со вторым — ещё можно кое-как бороться (хотя и сложно), то первое — исправить невозможно вообще.
С другой стороны Java обменивает возможность писать эффективный код на возможность писать надёжный код: систему, написание и отладка которой на C у вас займёт, условно говоря, 10 лет на Java вы сможете написать за 2-3 года.
Когда вы создаёте дизайн системы — вам с самого начала нужно определиться чего вы хотите, уж извините. А языки — это уже вторичное.
Если вам нужна максимальная производительность и вы выбрали Java'у — то вы уже проиграли
Зависит от того чего нужна максимальная производительность, если числодробилка — да. Если основное узкое место системы запросы в базу данных — нет смысла брать ассемблер, высокоуровневый язык даст намного больше возможностей для оптимизации SQL запросов.
то первое — исправить невозможно вообще
Можно, можно. Вопрос прямых рук, можно организовать переиспользование объектов, ограниченное создание временных объектов и прочее, если память критична. На Java писали даже софт для сим карт, где не было сборщика мусора как факта.
А языки — это уже вторичное.
Конечно, речь шла о важности алгоритмов в повседневном программировании. В Java/C# большинство алгоритмов уже давно реализованы на уровне языка, проверены, много раз отлажены на производительность и нужно просто знать какие функции стоит использовать в том или ином случае. То есть знать возможности языка важнее чем алгоритмы. В более низкоуровневых языках (если в них нет большого количества уже реализованных алгоритмов в качества функций самого языка) наоборот знание алгоритмов важнее.
На Java писали даже софт для сим карт, где не было сборщика мусора как факта.Да, писали. Я лично писал. А знаете — почему его там не было? А потому то не работает сборщик мусора при нехватке памяти. От слова «совсем». Если у вас памяти 3x от того что требуется — он работает неплохо. Если 2x — отвратитетльно.
И никакие теоретические изыскания [пока?] с этим сделать не могут. Начинали с того, что при меньше чем 2x памяти сборщик мусора переставал работать вообще, современные — работают, но мееедленное-мееедленно.
Ох вы все напутали в этом мире.
1) Есть базис на котором строится программист: логика, алгоритмика, теория вероятностей, векторная алгебра и т.п.
2) Есть технологии
Так вот второе приходит и уходит, а база остается. Всех технологий не освоить, но они вполне легко осваиваются по мере надобности. А если вы освоили базу, то вы прошли профотбор, и с легкостью освоите вторую часть.
1) Есть базис на котором строится программист: логика, алгоритмика, теория вероятностей, векторная алгебра и т.п.
2) Есть технологии
Так вот второе приходит и уходит, а база остается. Всех технологий не освоить, но они вполне легко осваиваются по мере надобности. А если вы освоили базу, то вы прошли профотбор, и с легкостью освоите вторую часть.
Но что такое база?
1) знание наизусть реализаций конкретных алгоритмов или
2) понимание принципов, на которых строятся эти алгоритмы (например, что такое хэш, индекс в БД и т.п.)?
Если второе, то вы правы. А если первое, то их знание — это лишнее, имхо.
1) знание наизусть реализаций конкретных алгоритмов или
2) понимание принципов, на которых строятся эти алгоритмы (например, что такое хэш, индекс в БД и т.п.)?
Если второе, то вы правы. А если первое, то их знание — это лишнее, имхо.
Написал же человек:
Есть такая вещь, как теория алгоритмов/вычислений, вот оно и является базой.
логика, алгоритмика, теория вероятностей, векторная алгебра и т.п.
Есть такая вещь, как теория алгоритмов/вычислений, вот оно и является базой.
Этой теории меньше сотни лет, так что считать её вечной и непреложной — это очень смело.
Может статься, все сегодняшние знания об "основах программирования" лет через пятьдесят будут казаться такими же смехотворно бесполезными, как сегодня — принципы построения и использования арифмометров и табуляторов.
Может статься, все сегодняшние знания об "основах программирования" лет через пятьдесят будут казаться такими же смехотворно бесполезными, как сегодня — принципы построения и использования арифмометров и табуляторов.
математике и логике меньше сотни лет? Это вы очень смело. Арифмометров может и нет больше, зато математические операции всё те же
И как математические операции помогут вам найти кратчайший путь в графе?
Алгоритм — это не просто перечень математических операций.
Алгоритм — это не просто перечень математических операций.
А ещё и кусок кода? :)
А как вы собираетесь дать определение кратчайшего пути не используя математики? :)
А как вы собираетесь дать определение кратчайшего пути не используя математики? :)
"Сформулировать задачу при помощи математики" — не то же самое, что "решить задачу при помощи математики".
Математика позволяет формулировать в том числе и неразрешимые задачи.
Математика позволяет формулировать в том числе и неразрешимые задачи.
Алгоритм — это не просто перечень математических операций.Алгоритм — это то, для чего Бэббидж создал свою машину.
И произошло это гораздо больше ста лет назад.
Да, формальной наукой это стало позже — когда от этого стали зависить жизни людей (для чего создавали ЭНИАК помним, да?), но способы что-то вычислить побыстрее и попроще — этим люди занимаются столетия.
Машина Бэббиджа реализовывала один конкретный алгоритм (вычисляла значение многочлена в точке).
Большое число современных алгоритмов (сортировка, поиск, сжатие данных, парсинг текста и т.п.) не имеют своей целью "что-то вычислить (побыстрее и попроще)".
Большое число современных алгоритмов (сортировка, поиск, сжатие данных, парсинг текста и т.п.) не имеют своей целью "что-то вычислить (побыстрее и попроще)".
Большое число современных алгоритмов (сортировка, поиск, сжатие данных, парсинг текста и т.п.) не имеют своей целью «что-то вычислить (побыстрее и попроще)».Да ладно вам. Вот всё то, что вы перечислили — туда и попадает. Просто пока сортировкой занимались библиотекари, а таблицы синусов считали математики — в алгоритмах сортировки прорывов не было (а вот в методах рассчётов — тут да: всякие АГС ещё Лагранж и Гаусс изучали). Но как только оказалось, что это проблема может получить выход в практику — так сразу теорию и подвели.
Хотя где-то вы правы: тот факт, что такой известный математик как Колмогоров, мог выдвинуть аж в 1956м году гипотезу, что умножение быстрее, чем за O(n2) не делается говорит о том, что всё-таки знания 50х годов не будут достаточными, чтобы современные задачи решать. Но вот уже то, что написано в Искусстве программирования — покроет бо́льшую часть поребностей современных разработчиков (а «гипотеза n2» была опровергнута Карацубой гораздо раньше).
Последующие же изыскания хотя иногда и открывают что-то «новое и интересное», но в целом — «картину мира» меняют медленно.
А вообще… Всё познаётся в сравнении. Вот вы тут говорите, что 50 лет назад Quicksort, Heapsort — были ещё не «базой», а «передним краем науки». Что, в общем, правда. Но ведь «новейшими технологиями» тогда были PL/1 и Multics с OS/360! Они были тогдашним Java'ой и Android'ом!
Ну и насколько будут востребованы сегодня люди «владевшие в совершенстве» писком тогдашних технологий? Если у человека, неполохо изучившему тогдашнюю «базу», есть шанс хотя бы понять о чём говорят люди сегодня, когда обсуждают сегодняшнюю «базу», то знания «практика», в общем, мало кому сегодня нужны. Если ему «повезёт» и он изучал OS/360, то, может быть, сможет найти работу по поддержке «глобокого легаси» где-нибудь в банке, а если он сделал ставку на Multics?
Большое число современных алгоритмов (сортировка, поиск, сжатие данных, парсинг текста и т.п.) не имеют своей целью «что-то вычислить (побыстрее и попроще)».
Да ладно вам. Вот всё то, что вы перечислили — туда и попадает.
Мы с Ушаковым не считаем действия над текстом "вычислениями":
ВЫ́ЧИСЛИТЬ. Посредством действий над числами найти искомое, высчитать.
ВЫЧИСЛЕ́НИЕ. 1. Действие по гл. вычислить. 2. Результат этого действия, то, что получено посредством этого действия.
А причём тут Ушаков, извините? С каких пор он у нас стал авторитетом в области математики?
Задача сортировки — это задача нахождения перестановки, поиск — это нахождение числа с определёнными математическими свойствами и так далее.
Вполне себе математические задачи. Чем вычисление 100500 знаков какого-нибудь числа пи принципиально отличается от разбора текста?
Какой смысл определять "невычислительные задачи" так, чтобы сортировка — в них не попала, а выясление 100500 знаков пи или поиск совершенных чисел — попали?
Задача сортировки — это задача нахождения перестановки, поиск — это нахождение числа с определёнными математическими свойствами и так далее.
Вполне себе математические задачи. Чем вычисление 100500 знаков какого-нибудь числа пи принципиально отличается от разбора текста?
Какой смысл определять "невычислительные задачи" так, чтобы сортировка — в них не попала, а выясление 100500 знаков пи или поиск совершенных чисел — попали?
А что Вы понимаете под технологиями? Многие технологии из того же Multics и UNIX используются до сих пор. Ка по мне, что технологии, что что алгоритмы можно разделить на устаревшие и не устаревшие.
А что Вы понимаете под технологиями?
Вот это: для запуска джобов — свой крон изобретает, условно.
Многие технологии из того же Multics и UNIX используются до сих пор.Идеи — может быть. Реализации — нет. Даже вещи из UNIXа (который, к слову, гораздо моложе) уже многие не поддерживаются (не знаю, к примеру, в какой версии Ubuntu пропала полноценная поддержка терминалов без строчных букв, но сейчас проверил — `stty olcuc` ещё работает, а ввод своего имени прописными буквами — уже нет).
Тогда получается и алгоритмы устаревают. Медленнее, но устаревают.
Алгоритмы устаревают в том смысле, что находятся более эффективные и замещают менее эффективные. Но это не значит что менее эффективные бесполезны и их стоит забыть.
А с технологиями не тоже самое?
Да получается тоже самое. Технология это тоже своего рода алгоритм )))
Собственно, это и хотел сказать) Если точнее, технологии основаны на алгоритмах. Если взять шире, то технологии — это результат научных достижений. Как следствие, устаревают достижения — устаревают соответствующие технологии. По сему, мне и показались странными попытки рассмотрения технологий как противовес алгоритмам. Я думаю, незнание теории равносильно незнанию соответствующей ей технологии. Вопрос в том, на сколько глубоко знаешь теоретическую основу и на сколько глубоко её нужно знать, а также какие именно нужно знать технологии и, соответственно, алгоритмы? Ответ, думаю, у каждого свой, который зависит от конкретной необходимости и контекста решаемых задач. Логично, что в вузах/училищах дают, но не все, а те, которые наиболее часто используются. А вот гадать, понадобятся они или нет — равносильно угадыванию выпадения комбинации на игральных кубиках.
В итоге получаем, что сама идея данного холивара довольно бессмысленна.
В итоге получаем, что сама идея данного холивара довольно бессмысленна.
Технлогий множество, а основаны они на алгоритмах и концепциях, которые придумали десятки лет назад. При этом всё множество технологий основано на относительно небольшом количестве концепций. Так что лучше учить? :) А концепции эти чаще не умирают, а эволюционируют и дополняются. Зная концепции — технлогии освоить намного проще.
Технлогий множество, а основаны они на алгоритмах и концепциях, которые придумали десятки лет назад.
Это утверждение последнее время не очень работает. Скорее новые технологии основаны на сравнительно новых достижениях в теоретической части.
Так что лучше учить?
И то, и то. сначала в базовом варианте, потом в контексте решаемых задач.
Это утверждение последнее время не очень работает. Скорее новые технологии основаны на сравнительно новых достижениях в теоретической части.
Например какие? Я не знаю никаких теоретических прорывов за последние 20 лет, котроые бы повсеместно использовались обычными разработчиками, а не в научных кругах
Информационная безопасность (AES например и попытки его взлома); повешение производительности тоже влечёт появление новых технологий (точнее это скорее старые, которые стало возможно реализовать), что, соответственно, результат развития теории; изобретение blockchain. Да много их.
Ну это однозначно технлогические усовершенствования, только ведь из теории в них ничего нового нет… Тот же AES в основе имеет поля Галуа.
А что у нас не усовершенствование? Супер принципиально новое если и есть, то на этапе: "в идеале, должно работать" (если из IT, то тот же квантовый компьютер).
Я говорю про усовершенствования, которые идут из теории. Например асимметричное шифрование будет таким. А более крутой алгоритм, который использует старые медоты сюда не очень подходит.
Или другой пример — создание системы типов для статической верификации параллельных программ. Такой полноценной системы пока нет
Или другой пример — создание системы типов для статической верификации параллельных программ. Такой полноценной системы пока нет
Логично, что в вузах/училищах дают, но не все, а те, которые наиболее часто используются.Ответ неверный. Об чём, собственно, и спор.
Это в ПТУ или на трёхмесячных курсах имеет смысл изучать вещи, которые «наиболее часто используются». А в ВУЗах и в школе — нужно изучать вещи с достаточно большим «периодом полураспада», чтобы это обучение имело хоть какой-то смысл.
А вот дальше — у многих возникает вопрос: а оно — вообще нада? Зачем тратить несколько лет жизни на то, что, как бы, напрямую «вам не касается». Увы — касается. Вот в том самом T-shaped специалисте алгоритмы — неизбежно попадут в «ножку», а всё остальное — в «шляпку». Просто потому что иначе — не получится.
Попытка сделать иначе с неизбежностью упрётся в «малый период полураспада». Хотя такой специалист может и выстрелить. Один-два раза за свою жизнь. А потом — всё, «парадигма изменится» и его специализация станет никому не нужной.
Можно, конечно, выбирать специализацию поустойчивее — когда-то это был Кобол, сегодня его место занял язык 1C. Но всё равно это всё достаточно шатко и ненедёжно. Вытеснит кто-то 1C-Бухгалтерию — и куда потом? В дворники?
А в ВУЗах и в школе — нужно изучать вещи с достаточно большим «периодом полураспада», чтобы это обучение имело хоть какой-то смысл.
Для чего? Не для того, чтобы изучить теорию с меньшим "периодом полураспада"? Причём почему она имеет большой период? Собственно, там такая и даётся. Я, например, практически не видел теории в вузе, которая не имела отголосков в современных технологиях. Причём, например в таких дисциплинах, как теория систем и численные методы ещё не успел наступить период полураспада (точнее они довольно молоды для того, чтобы оценить их в этом контексте). Разница в вузе и ПТУ не в самой теории, а в её количестве и углубленности.
Вытеснит кто-то 1C-Бухгалтерию — и куда потом? В дворники?
Для Вас язык — это языческое божество или средство? Для тех, для кого он средство быстренько перейдут на другой. А скорее всего изначально будут знать не только 1C.
Для чего?Не «для чего», а «почему». Потому что учить теории с короткими переодами полураспада в течение 10 лет смысла не имеет. А более «устойчивые» — имеет. Конечно только в том случае если есть шанс, что они окажутся потом востребованы.
Для Вас язык — это языческое божество или средство?Для меня — средство. Потому что я знаю их не один десяток (не все, конечно, я знаю хорошо). А вот для «специалиста по 1С» зачастую — это весь их мир. Ничего другого они делать не умеют и не хотят.
Та же самая ситуация в других областях науки и техники, кстати. Отсюда — куча незакрытых вакансий при дикой же безработице.
Конечно. Нет ничего вечного в этом мире. Вопрос в "периоде полураспада". Как всем известно период полураспада научных знаний — 45 лет.
Так вот когда вы имеете дело с "базой" (теория алгоритмов и прочая) — то вы имеете деле со знаниями, которые существенно устойчивие. Кой-какие вещи из Кнута, безусловно, устарели — но гораздо меньше половины.
А вот когда вы изучаете "технологии" — то должны понимать, что хорошо будет если ваши знания сохранят свою актуальность лет 5-10, а не устрареют раньше.
Что в свою очередь, объясняет почему их почти бессмысленно изучать в школе и/или в ВУЗе: к моменту поступления на работу почти всё — уже устареет.
Хотя есть и некоторое ядро, которое не устаревает, но, к примеру, текстовые редакторы и электронные таблицы не так давно (меньше 10 лет назад!) вдруг раз — и поменяли весь интерфейс. А уж что произошло за это время с другими, менее "устоявшимися" технологиями...
Так вот когда вы имеете дело с "базой" (теория алгоритмов и прочая) — то вы имеете деле со знаниями, которые существенно устойчивие. Кой-какие вещи из Кнута, безусловно, устарели — но гораздо меньше половины.
А вот когда вы изучаете "технологии" — то должны понимать, что хорошо будет если ваши знания сохранят свою актуальность лет 5-10, а не устрареют раньше.
Что в свою очередь, объясняет почему их почти бессмысленно изучать в школе и/или в ВУЗе: к моменту поступления на работу почти всё — уже устареет.
Хотя есть и некоторое ядро, которое не устаревает, но, к примеру, текстовые редакторы и электронные таблицы не так давно (меньше 10 лет назад!) вдруг раз — и поменяли весь интерфейс. А уж что произошло за это время с другими, менее "устоявшимися" технологиями...
А почему устаревают технологии? Случайно не из-за устаревания каких-либо их теоретических оснований? Каждой технологии соответствует какой-то набор теории, собственно, наоборот тоже работает. Я это всё к чему, меня такие темы всегда удивляли. Такое ощущение, что некоторые считают технологии и теорию двумя противолежащими полюсами, делая выбор, куда пойти. Но это же не так. Изучая технологию всё равно коснёшься теории, при этом знания голой теории без применения (т.е. без технологий) само по себе бессмысленно (если только в знакомых покидаться заумными фразами, показывая свою тупость крутость). Вопрос обычно не в том, нужны ли знания технологий/теории, а в том, какая именно область этих знаний нужна или будет потенциально нужна. Логично предположить, что никто не сможет изучить все технологии ровно как и всю теорию. Эта тема очень актуальна для программирования. Один с БД воюет, другой оси пишет, третий интерфейс изобретает, а четвёртый с пятым вообще что-то в науке делают, причём четвёртый пытается моделировать белки, а пятый движения планет.
Нет, технлогии устаревают не из-за устаревания теории. Технологии устаревают из-за того, что функции, которые они выполняют либо больше не нужны, либо скудны по сравнению с конкурентами. Или из-за удобства — вышло что-то новое, более удобное, и всё. Это не значит что теория изменилась. Изменилась реализация.
Согласен, но дополнение в теории тоже приводит к изменениям технологии (часто касается обработки данных и информационной безопасности). Опыт я что-то забыл учесть.
Частично да, зависит ещё что за теория. Бывает такая, что нужно много лет чтобы оно увидело свет. А бывает "о, мы можем дополнить Хиндли-Милнера вот так и сделать более сильную типизацию", и оно через несколько месяцев-годик уже на рынке :) Но это всёравно основано на старой теории
Старую основу я не исключаю и в технологиях. Это спиральная особенность человеческой истории сказывается)
В технологиях чаще опыт учитывают, чем что-либо ещё. Если говорить конкретно о софте, то сколько примеров когда старые проекты переписывались с нуля потому что приходили в негодность из-за допущеных предположений в начале разработке. Не всегда даже с улучшением функционала
Вот как раз стремление "переписать с нуля" и отличает теорию от технологии. Теорию — бессмысленно "переписывать с нуля". Она либо — верна, либо — неверна. Всё. Можно немного упростить изложение, книжку поудобочитаемей создать, но "переписать с нуля" теорию? Это вообще как?
А технология… в большинстве случаев к тому моменту, когда затевают её переписывание она находится в том состоянии, что нет вообще никого, кто понимал — как она работает и, соответственно, как её чинить!
Потому, собственно, переписывание и затевается обычно.
А технология… в большинстве случаев к тому моменту, когда затевают её переписывание она находится в том состоянии, что нет вообще никого, кто понимал — как она работает и, соответственно, как её чинить!
Потому, собственно, переписывание и затевается обычно.
С этим, пожалуй, соглашусь)
А почему устаревают технологии?Потому что кто-то хочет сделать «такое же, но своё»?
Случайно не из-за устаревания каких-либо их теоретических оснований?Иногда — да. Но гораздо чаще — просто потому, что старые — уже не модны.
Маркетинг — великое дело.
Один с БД воюет, другой оси пишет, третий интерфейс изобретает, а четвёртый с пятым вообще что-то в науке делают, причём четвёртый пытается моделировать белки, а пятый движения планет.Проблема в том, что первые три — пытаются решить «на новом уровне» задачи, которые уже давно решены «на старом». И «устаревают» технологии не тогда, когда появляется задача, которую они не могут решить, а когда кто-то придумывает как ещё чуть проще и лучше решить задачу, которую уже сто раз до этого решили.
Вот прямо сейчас Google потихогьку допиливает и подтягивает какой-нибудь Bionic до уровня соответствия POSIX'у. А до этого — туда же подтягивали GLibC. Который реализовывал повторно то, что уже было до этого реализовано в десятках UNIX'ов.
И это — на макроуровне! А сколько подобных «переизобретений велосипеда» в разных других частях!
Про четвёртого и пятого я не уверен (особенно про пятого), но наверняка как миниму половина (а то и больше) из того, что они делают — это повторение того, что уже кто-то где-то сделал (и обанкротился/продался/etc).
Такое ощущение, что некоторые считают технологии и теорию двумя противолежащими полюсами, делая выбор, куда пойти.Ну дык.
Но это же не так.Увы, но это так. Теория — это то, что изучается научным методом. Открытые публикации, новое строится на переосмыслении старого, «изобретение велосипеда» (по крайней мере теоретически) — запрещено (хотя на практике, конечно, происходит).
Технология — это что-то, что разрабывается «за закрытыми дверьми» и где «то же самое, но с перламутровыми пуговицами» — нормальное явление. Отсюда и такие маленькие «периоды полураспада».
потому, что старые — уже не модны.
Соглашусь, но ещё солидарен с мнением sgrey'а про повышение юзабилити.
Увы, но это так.
Если в научных кругах, то да. В программировании, если "зарыться" в теорию, то, пожалуй, тоже да. Но я пока не встречал учебников, которые перед рассказом о какой-либо технологии не вдавались хотя бы в краткую теорию.
Сколько ей лет — неважно. Научный метод же — пока не опровергли, придумали что-то новое, включающее старое, как частный случай, — используется.
Дальше можно не конкретизировать. Это очень, до боли, напоминает реплики приверженцев альтернативной науки — "мы еще мало знаем, очень может статься, что в будущем мы откроем новое, и закон сохранения энергии не будет работать, и повсюду будут вечные двигатели".
Ветряная мельница: создаем чучело (будто бы кто-то утверждает, что нечто — вечная истина и всегда, отныне и вовек будет верным), а потом смело разоблачаем.
Может статься, все сегодняшние знания
Дальше можно не конкретизировать. Это очень, до боли, напоминает реплики приверженцев альтернативной науки — "мы еще мало знаем, очень может статься, что в будущем мы откроем новое, и закон сохранения энергии не будет работать, и повсюду будут вечные двигатели".
Ветряная мельница: создаем чучело (будто бы кто-то утверждает, что нечто — вечная истина и всегда, отныне и вовек будет верным), а потом смело разоблачаем.
Ветряная мельница: создаем чучело (будто бы кто-то утверждает, что нечто — вечная истина и всегда, отныне и вовек будет верным), а потом смело разоблачаем.Комментарий, на который я отвечал, именно это и утверждал:
Так вот второе приходит и уходит, а база остается.
Комментарий, на который я отвечал, именно это и утверждал:
Нет, не утверждал. "остается" не значит "остается навсегда". Речь шла о том, что технологии и связанные с ними практические навыки меняются много чаще и быстрее, чем теория. Остается пока не открыто что-то новое, более точное. Вот вы едете в поезде, он стоит у перрона, за окном — человек. Поезд тронулся, мы говорим, что люди мимо окна проплывают и "уходят" один за одним, а перрон остается. Это не значит, что перрон будет тянуться за окном вечно, это всего лишь сравнение мимолетности появления людей и перрона.
Вы же подменили это контрастное "остается" на
считать её вечной и непреложной — это очень смело.
Я выше написал, что перрон уйдёт. Вы сейчас написали, что перрон уйдёт. Спрашивается: о чём мы спорим?
Нет. Вы написали "утверждать, что перрон вечен и непреложен (=никогда не уйдет) — это очень смело" как контр-аргумент, будто бы ваш оппонент это утверждал ("утверждать...- очень смело"), тогда как утверждения о вечности с его стороны не было. Это выдуманный абсурдный и разоблаченный аргумент.
За сим откланяюсь — это очень скучная перепалка о словах, не привносящая ничего нового.
За сим откланяюсь — это очень скучная перепалка о словах, не привносящая ничего нового.
Argumentum ad ignorantiam.
Наизусть никто вас не заставляет учить =)
Давайте аналогии приведем.
Есть профессия такая — хирург. Хирург — врач прежде всего. Так вот даллее по аналогии:
В настоящее время все больше и больше людей считает, чтобы хирургом быть не нужно нафиг заканчивать 6 лет в универе, не надо этого ничего… зачем врачебное дело Хирургу? Ему нафиг не нужно знать того что преподают в универе, зачем ему знать как работают вирусы, зачем ему всякое дерьмо в виде химии, цитологии, гистологии, микробиологии, этики, психиатрии, неврологии и еще кучи других… Зачем это все? Выучил анатомии, а можно и кусок анатомии ( тот что по профилю), ну потом научился круто владеть скальпелем… и режешь всех. Работает ведь, спасает жизни… а остальное все — от лукавого
Давайте аналогии приведем.
Есть профессия такая — хирург. Хирург — врач прежде всего. Так вот даллее по аналогии:
В настоящее время все больше и больше людей считает, чтобы хирургом быть не нужно нафиг заканчивать 6 лет в универе, не надо этого ничего… зачем врачебное дело Хирургу? Ему нафиг не нужно знать того что преподают в универе, зачем ему знать как работают вирусы, зачем ему всякое дерьмо в виде химии, цитологии, гистологии, микробиологии, этики, психиатрии, неврологии и еще кучи других… Зачем это все? Выучил анатомии, а можно и кусок анатомии ( тот что по профилю), ну потом научился круто владеть скальпелем… и режешь всех. Работает ведь, спасает жизни… а остальное все — от лукавого
Объясню свою нахватавшую минусов точку зрения подробнее.
Что считалось "основами программирования" 50 лет назад?
Самобалансирующиеся деревья ещё не изобретены.
LR-парсеры ещё не изобретены.
Сжатие LZ ещё не изобретено.
Quicksort и Heapsort — свежайшие изобретения, ещё не попавшие в учебные программы.
Насколько сейчас был бы ценен программист из 1960-х, отлично освоивший тогдашнюю "базу"?
Вот настолько же программист, отлично освоивший нынешнюю "базу", будет ценен через 50 лет.
Что считалось "основами программирования" 50 лет назад?
Самобалансирующиеся деревья ещё не изобретены.
LR-парсеры ещё не изобретены.
Сжатие LZ ещё не изобретено.
Quicksort и Heapsort — свежайшие изобретения, ещё не попавшие в учебные программы.
Насколько сейчас был бы ценен программист из 1960-х, отлично освоивший тогдашнюю "базу"?
Вот настолько же программист, отлично освоивший нынешнюю "базу", будет ценен через 50 лет.
Вы судя по всему не понимаете чем теория алгоритмов отличается от самих алгоритмов. Базой являются не алгоритмы, а модели на которых они основаны.
Внимательно вас слушаю. О каких моделях речь?
О моделях вычислений, куда входит много разных топиков
Так вот второе приходит и уходит, а база остается.Ага, для сферического программиста в вакууме. Дьявол, как известно, кроется в деталях: в некоторых ситуациях может быть справедливо обратное высказывание, вроде «алгоритмы приходят и уходят, а 1С (или какой-нибудь wordpress) остаётся».
Хотя на это есть стандартный ответ-лазейка «по определению»: если в определение программиста включить знание алгоритмов, тогда кто не знает — не программист, потому и в выборке не участвует. Проблема решена, правосудие восторжествовало. :)
Вот есть заказчик, который нанимает команду и собирается платить ей $1млн в год.
У него есть 3 команды на примете, с которыми он не работал ранее.
Они все клянутся, что в срок и поддерживать будет легко.
По каким критериям из выбирать?
У него есть 3 команды на примете, с которыми он не работал ранее.
Они все клянутся, что в срок и поддерживать будет легко.
По каким критериям из выбирать?
По реализованным проектам?
Это в любом случае будет лотерея.
Знания человека и качество его работы не обязательно связаны.
Знаю не одного, ну можно сказать гениального программиста, которые «себе на уме».
Да, если фазы луны и нептуна совпали, то они напишут отличный код.
Он будет клевый со всех сторон.
Беда только, что эти фазы совпадают не когда надо команде…
т.е. это абсолютно неуправляемые люди, и в общем случае они тащат команду на дно.
Знания человека и качество его работы не обязательно связаны.
Знаю не одного, ну можно сказать гениального программиста, которые «себе на уме».
Да, если фазы луны и нептуна совпали, то они напишут отличный код.
Он будет клевый со всех сторон.
Беда только, что эти фазы совпадают не когда надо команде…
т.е. это абсолютно неуправляемые люди, и в общем случае они тащат команду на дно.
Для таких случаев в заднем кармане брюк я всегда ношу монету.
Странно, что такие весьма спорные пункты включены, а, например, о владении навыками написания читаемого/поддерживаемого кода и тестирования, знания структур данных и областей их применения — ни слова.
Есть ещё такой момент, как абстракции. ОС и сетевые технологии изначально созданы для того, чтобы пишущий прикладные приложения мог особо не задумываться о них. Я не к тому, что их знать не надо, я к тому что вы можете стать хорошим разработчиком, не залезая в такие дебри. Тем более, что есть области программирования, не использующие ни сеть, ни операционки.
Есть ещё такой момент, как абстракции. ОС и сетевые технологии изначально созданы для того, чтобы пишущий прикладные приложения мог особо не задумываться о них. Я не к тому, что их знать не надо, я к тому что вы можете стать хорошим разработчиком, не залезая в такие дебри. Тем более, что есть области программирования, не использующие ни сеть, ни операционки.
Ни разу не утверждал, что кроме алгоритмов ничего знать не надо. Почему-то все сразу думают об общеизвестных алгоритмах сортировок и обхода графов. Тем менее алгоритмы намного более широкое понятие, чем список известных решений типовых задач. На основе теории вычислений строится всё остальное, и как вы по-настоящему поймёте строение ОС или сети без знания алгоритмов — не совсем понятно.
В сетях например используют множество алгоритмов из теории графов. Как вы разберётесь в STP без затрагивания алгоритма остовного дерева? Как вы будете обсуждать протоколы роутнга без затрагивания Беллмана-Форда? Конечно можно разбираться поверхностно, на уровне "такая ошибка скорее всего показывает проблему там-то", и этого часто достаточно. Но имея более глубокие знания такие вещи будут всёравно очевидны.
Как вы можете узнать принципы работы ОС, не говоря о LRU, FIFO, WSClock, RB-trees и B-Trees? Объясните адресацию памяти в 64-битных система без затрагивания инвертированных таблиц. Новые версии файловых систем всё больше переходят на B-Trees. В ОС вообще множество своих алгоритмов и структур данных. А динамическое программирование используется постоянно.
А безопасность без криптографии? Это разве не алгоритмы?
Говорить об оптимизации и масштабировании, при этом утверждать что это не алгоритмическая задача — вообще смешно, честно говоря. Если понимать как рабоает СУБД, то какие запросы будут работать быстрее, а какие медленнее — вопрос достаточно лёгкий. А разницу между отдельными движками и их настройкой можно узнать в процессе работы довольно быстро.
Все технлогии, какими бы магическими они не казались, основаны на относительно небольшом количестве концепций, многие из которых появились десятки лет назад, и только сейчас начали быть популярными. Зная эти концепции освоить новые технлогии будет намного легче, а также будут очевидны их преимущества и недостатки.
Конечно не всем нужны детальные знания всего этого, и кроме самой теории вычислений нужно знать много другого. Но большинство этих знаний всёравно основывается на той самой теории вычислений — это фундамент всей информатики.
А всякие инструменты и как их использовать можно освоить по ходу работы, и на это как правило не уходит много времени, если есть голова на плечах и багаж знаний :)
В сетях например используют множество алгоритмов из теории графов. Как вы разберётесь в STP без затрагивания алгоритма остовного дерева? Как вы будете обсуждать протоколы роутнга без затрагивания Беллмана-Форда? Конечно можно разбираться поверхностно, на уровне "такая ошибка скорее всего показывает проблему там-то", и этого часто достаточно. Но имея более глубокие знания такие вещи будут всёравно очевидны.
Как вы можете узнать принципы работы ОС, не говоря о LRU, FIFO, WSClock, RB-trees и B-Trees? Объясните адресацию памяти в 64-битных система без затрагивания инвертированных таблиц. Новые версии файловых систем всё больше переходят на B-Trees. В ОС вообще множество своих алгоритмов и структур данных. А динамическое программирование используется постоянно.
А безопасность без криптографии? Это разве не алгоритмы?
Говорить об оптимизации и масштабировании, при этом утверждать что это не алгоритмическая задача — вообще смешно, честно говоря. Если понимать как рабоает СУБД, то какие запросы будут работать быстрее, а какие медленнее — вопрос достаточно лёгкий. А разницу между отдельными движками и их настройкой можно узнать в процессе работы довольно быстро.
Все технлогии, какими бы магическими они не казались, основаны на относительно небольшом количестве концепций, многие из которых появились десятки лет назад, и только сейчас начали быть популярными. Зная эти концепции освоить новые технлогии будет намного легче, а также будут очевидны их преимущества и недостатки.
Конечно не всем нужны детальные знания всего этого, и кроме самой теории вычислений нужно знать много другого. Но большинство этих знаний всёравно основывается на той самой теории вычислений — это фундамент всей информатики.
А всякие инструменты и как их использовать можно освоить по ходу работы, и на это как правило не уходит много времени, если есть голова на плечах и багаж знаний :)
Спасибо за коммент.
1.Согласен про пользу понимания той же теории графов и тд для работы с сетями. Тут без нее никак, но и без знания теории работы сетей, и практического опыта сама по себе математика не делает вас сразу Developerом с большой буквы
2.Безопасность отнюдь не заключается только в криптографии.
Кстати, для ряда приложений различные алгоритмы шифрования. Я условил и детально разобрал для себя RSA (и ряд других известных), в дальнейшем остались лишь базовые принципы его работы в памяти. Но отнюдь не прошел полный курс, которые преподают шифровальщикам.
Мешало ли мне это в работе? Нисколько.
3.Вот в случае с архитектурой, стэком технологий, базой данных и так далее есть такая злая штука — в реальности они работают сильно сложнее и нередко совсем не так, как мы моделируем в нашем воображении. Иначе бы никаких тестов производительности, всяких A/B проверок архитектуры на устойчивость к нагрузке и прочее не требовалось бы.
Можно здесь вспомнить умную теорему про связь алгоритма, входных данных и предсказуемость результата; можно сказать про ненулевую вероятность ошибок в коде любого продукта, помноженную на сложность и объем современных систем и железа, что дает отличные от теории результаты.
Но я просто отмечу, что помимо теоретических расчетов и выбора тех или иных решений по масштабированию или оптимизации, всегда вылезают какие-нибудь баги кэша ядра FreeBSD и распределенные файловые системы, настроенные как рассчитано, сбоят; внезапно барахлит какая-нибудь мелочь в рейде и Гластер не работает, как ожидалось, или же банально разрекламированный в новой версии языка-не-будем-называть сборщик мусора при превышении определенных пределов устраивает дикие тормоза.
Поэтому знать и уметь основы Computer Science и… (допишите по вкусу) полезно и нужно. Но без практики и реальных боевых проектов, нагрузки, живого использования, развития и тд это сферический конь в вакууме (хотя и сферический конь в вакууме тоже может победить на скачках, как мы помним — только вот в каких)
1.Согласен про пользу понимания той же теории графов и тд для работы с сетями. Тут без нее никак, но и без знания теории работы сетей, и практического опыта сама по себе математика не делает вас сразу Developerом с большой буквы
2.Безопасность отнюдь не заключается только в криптографии.
Кстати, для ряда приложений различные алгоритмы шифрования. Я условил и детально разобрал для себя RSA (и ряд других известных), в дальнейшем остались лишь базовые принципы его работы в памяти. Но отнюдь не прошел полный курс, которые преподают шифровальщикам.
Мешало ли мне это в работе? Нисколько.
3.Вот в случае с архитектурой, стэком технологий, базой данных и так далее есть такая злая штука — в реальности они работают сильно сложнее и нередко совсем не так, как мы моделируем в нашем воображении. Иначе бы никаких тестов производительности, всяких A/B проверок архитектуры на устойчивость к нагрузке и прочее не требовалось бы.
Можно здесь вспомнить умную теорему про связь алгоритма, входных данных и предсказуемость результата; можно сказать про ненулевую вероятность ошибок в коде любого продукта, помноженную на сложность и объем современных систем и железа, что дает отличные от теории результаты.
Но я просто отмечу, что помимо теоретических расчетов и выбора тех или иных решений по масштабированию или оптимизации, всегда вылезают какие-нибудь баги кэша ядра FreeBSD и распределенные файловые системы, настроенные как рассчитано, сбоят; внезапно барахлит какая-нибудь мелочь в рейде и Гластер не работает, как ожидалось, или же банально разрекламированный в новой версии языка-не-будем-называть сборщик мусора при превышении определенных пределов устраивает дикие тормоза.
Поэтому знать и уметь основы Computer Science и… (допишите по вкусу) полезно и нужно. Но без практики и реальных боевых проектов, нагрузки, живого использования, развития и тд это сферический конь в вакууме (хотя и сферический конь в вакууме тоже может победить на скачках, как мы помним — только вот в каких)
Кратко — не нужно противопоставлять теорию практике.
База нужна? во многих сферах, где трудятся программисты, без нее не подняться выше определенного уровня
Практический опыт и разный нужен? Да, без него в теории можно делать великие открытия и наука рулит. Но бизнесу нужна практика.
Можно ли неуважать коллег, кто не владеет знаниями/навыками, которые вы считаете мастхэв для тру? Можно, у нас свободная страна. Но это неэффективно для группы в целом, кмк.
База нужна? во многих сферах, где трудятся программисты, без нее не подняться выше определенного уровня
Практический опыт и разный нужен? Да, без него в теории можно делать великие открытия и наука рулит. Но бизнесу нужна практика.
Можно ли неуважать коллег, кто не владеет знаниями/навыками, которые вы считаете мастхэв для тру? Можно, у нас свободная страна. Но это неэффективно для группы в целом, кмк.
Наука в computer science вещь вполне практичная кстати. Чтобы написать о производительности или крутости какого-нибудь "открытия", нужно сделать немало опытов и привести доказательства.
Да, есть такое дело.
Просто почему еще я про практику написал.
Дело в том, что есть немало тонких материй, которые пока слабо формализованы.
И более того, на деле теоретически верные штуки могут мешать.
Как пример, вспоминаю ООП и паттерны. Первая практика, красивый код, старался — вылизывал. И тут жестокие требования бизнеса вынудили раз переписать, два, три — и совсем по-другому начинаешь смотреть на красивости из классов-классов и более любовно на всякие DRY, KISS, YAGNI, unix way. Потом и как с SOLID готовить понимаешь, и прочие другие вещи.
То есть существуют разные способы сделать архитектуру внутри кода, спроектировать БД, выбрать стэк технологий и так далее. И нередко теоретически правильный и красивый может быть не нужен, а какой нужен, и когда нужно добавить правильности, а когда начисто делать сразу хорошо и идеально — дается только с опытом.
Просто почему еще я про практику написал.
Дело в том, что есть немало тонких материй, которые пока слабо формализованы.
И более того, на деле теоретически верные штуки могут мешать.
Как пример, вспоминаю ООП и паттерны. Первая практика, красивый код, старался — вылизывал. И тут жестокие требования бизнеса вынудили раз переписать, два, три — и совсем по-другому начинаешь смотреть на красивости из классов-классов и более любовно на всякие DRY, KISS, YAGNI, unix way. Потом и как с SOLID готовить понимаешь, и прочие другие вещи.
То есть существуют разные способы сделать архитектуру внутри кода, спроектировать БД, выбрать стэк технологий и так далее. И нередко теоретически правильный и красивый может быть не нужен, а какой нужен, и когда нужно добавить правильности, а когда начисто делать сразу хорошо и идеально — дается только с опытом.
В этом плане да. В книжках по дизайну много красивых паттернов и воспетие архитектур, а на деле приходится кодить в проекте, написанном по очереди шестью разработчиками независимо друг от друга, которые мало того, что о дизайне не слышали, так ещё и костылей понаделали. А поменять как следует времени нет — сроки и деньги горят. Или ТЗ такое, что никакие паттерны не подойдут, и выкручивайся как хочешь :) Поэтому понимание принципов ООП я ценю обычно больше, чем знание паттернов наизусть. Тем более у меня были примеры, когда человек лепил паттерны куда не попадя, и коверкал ими проект.
Согласен, мы же не разрабатываем продукты в вакууме. В реальности приходится брать во внимание среду, железо, и способы использования продукта пользователями. Плюс не всякие теоритетически крутые штуки будут работать в реальности (кучи Фибоначчи тому пример). И для того чтобы, например, стать хорошим разработчиком сетевых приложений, нужно будет кроме принципов работы сети выучить язык и его интерфейс в сетевой протокол. Но для тех, кто знает как работает сеть это будет намного легче, по сравнению с теми, кто не знает :)
Согласен.
Я, кстати, за хорошую теоретическую базу, но без фанатизма. T-shaped, так они это называют.
А то мне вот нравится теория игр (и теория вероятностей, куда без нее), всякие там равновесия Нэша, но никогда не скажу человеку, если он не владеет ею, что он — не программист. Разве только спрошу, какая вероятность того, что среди группы из двух футбольных команд и тренеров будут одинаковые дни рождения ))
Я, кстати, за хорошую теоретическую базу, но без фанатизма. T-shaped, так они это называют.
А то мне вот нравится теория игр (и теория вероятностей, куда без нее), всякие там равновесия Нэша, но никогда не скажу человеку, если он не владеет ею, что он — не программист. Разве только спрошу, какая вероятность того, что среди группы из двух футбольных команд и тренеров будут одинаковые дни рождения ))
Да я тоже за уважение коллег, и если человек пишет код, который идёт в продукцию — буду называть его программистом :) Другое дело что бывают хорошие или плохие профессионалы, и вот тут как раз идёт разделение по знаниям теории.
А есть ещё люди, которые имеют звание программиста на работе, а вот писать код не могут. С такими сложнее — как их называть :)
А есть ещё люди, которые имеют звание программиста на работе, а вот писать код не могут. С такими сложнее — как их называть :)
Это да. Проблема в том, что есть куча народу, которые программируют, хотя делать этого — не умеют. Это уникальное явление. Нигде больше, ни в одной профессии — такого не бывает.
А знаете почему? Проблема в том, что программы не ломаются, а компьютеры обладают бесконечным терпением. Подумайте над знаменитым я смотрел лаже в лицо и не боюсь называть её по имени: Если достаточно долго месить чан с перловой кашей, в синтаксическом мусоре можно рано или поздно узреть лик Ларри Уолла.
При разработке железа (или там при изготовлении выпечки) такой подход не годится: одно неверное движение — и вы спалили что-нибудь (микросхему там или пиццу — неважно). Если ваш труд "интеллектуальный", но оценивает его человек (ну там секретарша или бухгалтер) — то тут тоже всё ясно. Но вот именно сама возможность 1000 раз безнаказанно переделывать своё поделие — и рождает вот этот феномен.
А знаете почему? Проблема в том, что программы не ломаются, а компьютеры обладают бесконечным терпением. Подумайте над знаменитым я смотрел лаже в лицо и не боюсь называть её по имени: Если достаточно долго месить чан с перловой кашей, в синтаксическом мусоре можно рано или поздно узреть лик Ларри Уолла.
При разработке железа (или там при изготовлении выпечки) такой подход не годится: одно неверное движение — и вы спалили что-нибудь (микросхему там или пиццу — неважно). Если ваш труд "интеллектуальный", но оценивает его человек (ну там секретарша или бухгалтер) — то тут тоже всё ясно. Но вот именно сама возможность 1000 раз безнаказанно переделывать своё поделие — и рождает вот этот феномен.
Да я работаю с целой командой таких вот "программистов", которых наша компания держит через фирму оутсорса для поддержки продуктов. Я когда смотрю на таких людей, у меня седые волосы появляются от мысли, что они каким-то образом могут попасть в команду, которая будет писать софт для автомобилей, мед. обородувания, или других устройств, от которых может зависеть жизнь или здоровье. А некоторые из них потом вероятно могут устроится преподавателями… вот уж ужас...
А основная проблема я считаю в том, что ВУЗы выпускают людей, которые не удовлетворяют даже минимальным требованиям. Каким-то образом они проходят из года в год, и даже сдают дипломы. Почему-то проваливать и исключать студентов не принято… Ну и качество самого образования во многих вузах страдает
А основная проблема я считаю в том, что ВУЗы выпускают людей, которые не удовлетворяют даже минимальным требованиям. Каким-то образом они проходят из года в год, и даже сдают дипломы. Почему-то проваливать и исключать студентов не принято… Ну и качество самого образования во многих вузах страдает
Я когда смотрю на таких людей, у меня седые волосы появляются от мысли, что они каким-то образом могут попасть в команду, которая будет писать софт для автомобилей, мед. обородувания, или других устройств, от которых может зависеть жизнь или здоровье.
ну вообще то там порой люди тоже бывают ...
недавние случаи
- Спрашивали что не так с компактным 100 ватным мед лазером для медицины катастроф. краткий опрос про коллектив и процесс разработку сразу выявил: "а зачем нам беттатестер, схемотехник и технолог всего на 12 программистов? они же в потолок плювать будут — пусть сами всё делают как нибудь". в BOM листе кондёры даже не помечены какие керамика какие тантал или электролиты. хотел ответить: "всё плохо", потом подумал и отказался от аудита (это ещё та распильная тема, сказавшему правду могут как минимум не заплатить). Это не в первый раз. Такое слышал и от производителей кан локеров авто (зачем нам скорость анализировать, пришла команда — авто заблокировалось!), и от разрабов промышленных штук (ардуину запеткивали в систему управления печкой 100кВатт, где то на хабре подобное с груз лифтом видел)
- На одном форуме люди дели умный выключатель света на распебри пи, причём тот функционал который японцы в гостиницах запилили дополнительным третьим проводом и солинойдом, ценой всего в 2 раза выше обычного выключателя света.
- На гиктаймсе один выложил "прикольный способ обеденения ардуин в герлянду", я пытался объяснить что так нельзя делать, что могут быть в ряде случаев глюки и не таких редких, что передатчик и приёмник уарта не связаны по скорости по тем же причинам по каким стоит дифференциал между левым и правым колесом — иначе они в поворот зайдут только один раз. или ось порвёт из за чуток разных скоростей слева и справа — что у них и будет. Никто не понял, вообще, один нашол подобные упоминания и случае но быстро забыл и опять меня стал обвинять и минусовать. Ну ладно.
- Человек писал курс статей как на асме для МК и железа сделать супер-пупер сверхмалый размер прошивки, три статьи к этому вёл, я в каментах взял и реализовал на чистом gcc очевидным способом, без уродования кода при этом размером кода меньше чем на асме в статье и всего за 10 минут. На вопрос "что я делаю не так? и зачем оно нужно" внятного ответа не получил. И вообще каждый десятый разраб железа хочет поиграть в майнкрафт — накопать руды, сделать транзистор, процессор, самому сделать компилятор и тд. Вместо того чтоб не маяться дурью, а уметь хотя-бы нормально кодить на банальном Си. "иначе я не разберусь в этом как надо" — их лозунг. При этом из таких людей часто отвратительные инженера.
Очень много овер и гипер-инжиниринга, часто наблюдаю такое: "когда в руках молоток то всё становиться гвоздями", и тому подобное. Благо большая часть электроники терпит такие издевательства — даже самый хреновый дешовый и подделываемый стабилизатор имеет стопятьсот защит по теплу, овервольтажу, перегрузке, процы могут работать при сильной просадке напруги незаметно…
Да это даже мелочи. Было ведь множество серьёзных случаев, когда например рентгеновский аппарат давал десятикратную дозу за раз (или больше, я уже не помню) потому что не проставили ограничение мощности. Или когда шасси самолёта не выдвинулось при посадке из-за сильного ветра, и софт думал что самолёт на высоте летит, а не садится. Список довольно длинный. Только в этих индустриях ввели довольно строгий режим разработки и тестирования теперь.
Только вот 100 ваттным лазером вы меня удивили… в россии было наверно?
Только вот 100 ваттным лазером вы меня удивили… в россии было наверно?
да, всё это у нас в России, часто Москва и Питер.
проблема то ещё в отношении к своим косякам:
часто вместо того чтоб молча исправить хотябы костылями, они в ответку сразу юридически и административно бьют и больно: Были проблемы в крипто и электро безопастности в служебных блоках шахтных пусковых комплексов я доложил куда надо. Они подёргали за ниточки чтоб меня хотели призвать в отвратительную часть, вписали долг в 70тр заводу (при зарплате в 5тр) решение суда получил уже на следующий день (смог апплировать), аннулировали трудовую будто на заводе я и не работал. Выдачу диплома задержали. Вообщем сделали всё чтоб получилось что доклад о проблемах пришол от безработного человека без профильного образования и опыта работы. Ладно без уголовки.
В общем поэтому теперь я не связываюсь с гос сектором особенно с градообразующими предприятиями которые в городе имеют половину всех заведений.
Мне после этого смешно на нытьё рунета что в сбитом самолёте микросхемы флеш-памяти были в гражданских корпусах.
Очень часто всё гораздо хуже, ладно если военка вообще работает.
проблема то ещё в отношении к своим косякам:
часто вместо того чтоб молча исправить хотябы костылями, они в ответку сразу юридически и административно бьют и больно: Были проблемы в крипто и электро безопастности в служебных блоках шахтных пусковых комплексов я доложил куда надо. Они подёргали за ниточки чтоб меня хотели призвать в отвратительную часть, вписали долг в 70тр заводу (при зарплате в 5тр) решение суда получил уже на следующий день (смог апплировать), аннулировали трудовую будто на заводе я и не работал. Выдачу диплома задержали. Вообщем сделали всё чтоб получилось что доклад о проблемах пришол от безработного человека без профильного образования и опыта работы. Ладно без уголовки.
В общем поэтому теперь я не связываюсь с гос сектором особенно с градообразующими предприятиями которые в городе имеют половину всех заведений.
Мне после этого смешно на нытьё рунета что в сбитом самолёте микросхемы флеш-памяти были в гражданских корпусах.
Очень часто всё гораздо хуже, ладно если военка вообще работает.
Увы, тут со времён "позднего СССР" мало что изменилось. Радует (или огорчает — тут не понять): насколько мне известно госучереждения везде одинаковы — в Штатах очень похожий бардак.
Почитайте хотя бы Фейнмана, про то как он катастрофу с Шаттлом расследовал. Между строк там легко увидеть: все рядовые исполнители были в курсе того, что они, в общем, фигню творят — но не хотели, чтобы "доклад о проблемах пришол от безработного человека без профильного образования и опыта работы". Потому когда подвернулся человек, которому "по статусу" можно было "мутить воду" — тут сразу такое вскрылось, такое… а без него никто ничего не замечал, ни-ни. Все — "учёные идиоты", "узкие специалисты" и не при делах.
Почитайте хотя бы Фейнмана, про то как он катастрофу с Шаттлом расследовал. Между строк там легко увидеть: все рядовые исполнители были в курсе того, что они, в общем, фигню творят — но не хотели, чтобы "доклад о проблемах пришол от безработного человека без профильного образования и опыта работы". Потому когда подвернулся человек, которому "по статусу" можно было "мутить воду" — тут сразу такое вскрылось, такое… а без него никто ничего не замечал, ни-ни. Все — "учёные идиоты", "узкие специалисты" и не при делах.
Почему-то проваливать и исключать студентов не принято…Деньги. Независимо от системы: либо выделаемые из бюджета, либо приносимые самим студентами.
Выгнал студента — порезал себе зарплату!
Кто на такое пойдёт? Ясно кто: горсточка ВУЗов, которые «у всех на слуху» и которым нужно «держать марку».
Для остальных это — как серпом по кошельку.
Девальвация высшего образования — это всемирная проблема, Россия не исключение.
Ещё большая проблема в разработке — кривая спецификация задания. Часто клиент сам не знает что и как будет, а команда, которая берётся за разработку не заставляет писать детальное ТЗ. Отсюда и получаются эти самые проблемы, когда вылезают непонятные баги из-за среды, в которой используется продукт. Или не все use cases покрыты, и потом нужно делать костыли, когда в конце оказывается что заказчик забыл указать/хочет поменять одну из главный функций
Необходимо определить, о какой именно разработке идёт речь. Есть CRUD, есть shrinkwrap, есть внутренний софт, одноразовый, микроконтроллеры, научный, игры — у них у всех разные требования.
Переводчику с китайского на французский необязательно знать арабский, а переводчику с арабского — нужно.
Переводчику с китайского на французский необязательно знать арабский, а переводчику с арабского — нужно.
возьмём программиста и скажем что он НЕ умеет или не использует:
Ваша реакция: "Да это не программист даже!" да?
Нет такие бывают.
И даже пишут мультиплатформные штуки, такие что работают и в железе и в ПК и на веб сайте, и даже компилируются из одного исходника, и даже плавный граф монохромный интерфейс даже в веб эмуляторе летает, и даже с 1-5% загрузки ЦПУ.
Даже работает с множеством языков, включая китайский.
И даже продаётся, в том числе за рубежом.
И даже продаётся не один год и не пять лет, больше.
Нет, и это не стартап
и не основная работа.
Это просто хобби, карл
Ладно, другой пример, ближе ко мне:
Наш сотрудник на работе разработал кучи прошивок для кучи шлюзов, они работают нормально без глюков, уже не первые 5 лет, и счёт изделий далеко не 4-5 значный.
Но…
недавно я его прошивку компилировал под новым gcc 5.2 для мк арм, и сюрприз: оказалось что библиотечная функция ОС файлового ввода/вывода select и группа констант FD_xxx им была занята на свои нужды (свою функцию селект повесил на сигнал селект SD карты) и естественно компилятор выдал ошибку о занятом имени. Называется человек всю свою жизнь кодил под МК. И плохим программистом назвать его у меня не повернётся язык. Работает же всё, и модифицировать что либо из его кода другие могут, другие же не называли его ни быдлокодером, ни криворучкой. Он отдаёт свой код и претензий нет, вопросов особых тоже. Разве что чисто перфекционистких: что вот это можно было бы переписать чуток получше, но ничего особо это не даст.
Ну и я вот тоже не имею ни опыта, ни теории работы с базами данных, с алгоритмами у меня тоже беда типа хитрого обхода графов. Что теперь я не проф пригоден? Хотя пишу и под МК и под ПК и иногда надо на своём сервере что-то сделать, то и для веба совсем кроху (называется видел и правил javascript, php и тд).
так ли это всё важно?
почему очень много неплохих программистов исходя из всех требований и обсуждаемых штук оказывается за бортом?
и я не только это про алгоритмы.
И вообще они кажутся не программистами после чтения этих всех статей.
Особенно это чувствуется при поиске работы — когда весь твой опыт нивилируется теми тегами что требуют работодатели и по факту только на них и смотрят (бд, аджайл, буст, скуель, гит и тд).
И не важно что твой знакомый кодит с времён ДВК и Z80 — для работодателей и коллег которые его не знают: "ну вроде кодил в закрытом заводе 30 лет, но кодил ли, ой не факт. А по вечерам сделал никому ненужный стопятьсот первый гаджет, от которых всех тошнит уже, и дал в доказательства какие то ссылки на финском, испанском и китайском, вообщем закрыть их".
- Базы данных
- Системы контроля версий
- Сложные элементы языка, например для 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 лет, но кодил ли, ой не факт. А по вечерам сделал никому ненужный стопятьсот первый гаджет, от которых всех тошнит уже, и дал в доказательства какие то ссылки на финском, испанском и китайском, вообщем закрыть их".
так ли это всё важно?
почему очень много неплохих программистов исходя из всех требований и обсуждаемых штук оказывается за бортом?
Во-первых, "пять миров Спольски".
Во-вторых, как мы определим вот это "неплохой"? Каковы формальные критерии?
как мы определим вот это «неплохой»? Каковы формальные критерии?
я бы предложил взять такой критерий как прибыль с разработчика
работодатели этим интересуются напрямую,
сотрудники и коллеги косвенно: чтобы было у кого поучиться, чтоб мозг не сношал пустиками, чтоб его код не пришлось переделывать и тд,
кадровики и агенства по своему: чтоб как можно быстрее скушал работодатель или подходило как можно ближе квадратно-гнездовым методом (эдакая функция минимального хеммингового растояния).
я бы предложил взять такой критерий как прибыль с разработчика
Совершенно абстрактно: берем двух людей, один выдает кое-как работающий, нерасширяемый продукт за 1 единицу времени, второй — за 2, но надежный и расширяемый. Зарплата второго выше — выше ведь его квалификация, а вот прибыль выше с первого. Пока выше с первого, потому что его продукт можно уже продать, а ему заплатить пол-копейки. А что будет завтра, когда его продукт будет взломан? Потеряет пользовательские данные?
чтобы было у кого поучиться
Это, конечно, здорово. Но может быть следствием того, что все остальные, кто будут учиться у N — вообще профнепригодные дятлы.
чтоб мозг не сношал пустиками
"Не сношать моз пустяками" как-то не поддается формализации.
чтоб его код не пришлось переделывать
Это уже лучше. Не кажется ли вам, что переделывать чей-то код придется реже, если этот кто-то обладает знаниями и изначально принимает более правильные решения? По применению алгоритмов или структур данных, прости господи, в частности.
Иногда лучше выйти на почти пустой рынок с криво написанной программой, чем выдать «на гора» супер приложение на уже сформировавшейся рынок. Даже если потом забьют на обновления и безопасность и будут утечки (да, некая фриланс биржа, я говорю о тебе), но это уже вопрос не к разрабам, а к владельцам/менеджерам.
Иногда, без конкретики нет смысла обсуждать. Я привел пример, в котором это неважно — временные отрезки в 1 и 2 единицы равно допустимы.
Иногда лучше выйти на почти пустой рынок с криво написанной программой, чем выдать «на гора» супер приложение на уже сформировавшейся рынок.
Вот для этого и нужны алгоритмы и некоторая забота о дизайне. Если же вы «забьёте на всё» и сделаете всё возможное для того, чтобы выйти на рынок первым — то вы потом очень быстрое упрётесь в ограничения своей платформы и вам потребуется всё передалать.
Между скоростью выхода на рынок и качеством всегда нужен баланс.
Посмотрите на рынок персоналок, к примеру: Altair, Apple II, Sinclair, Commodore, Acorn — все они «вышли на полупоустой рынок» с «криво созданными системами» — и все проиграли. Почему? А потому что пресловутый IBM 5150 оказался устроен так, что его не пришлось выкидывать и начинать всё с нуля.
А вот уже те, кто пришли на рынок когда он закрылся (NeXTы всякие или BeBox) — да, те уже не имели никаких шансов.
Во всём нужен баланс. Человек, «ушедший в придумывание алгоритмов» и отказывающийся выдавать в премлемые сроки результат столь же плох, как и человек, сотворивший код, который потом придётся выкинуть нафиг.
Хотя бывает и так, что компании удаётся это пережить (в примере выше: Apple, начавшая одной из первых, сменившая одну хромую лошадь на другую, тоже не слишком здоровую, спаслась купив NeXT, который появился слишком поздно для того, чтобы выжить в одиночку), но это — большая редкость.
Во-первых, «пять миров Спольски».
Я знаю людей которые одновременно подпадают и под 3-4 мира спольски и под большую часть моего списка в корневом камменте к данной статье.
Но результаты включая финансовые у них отличные и они точно никогда работать на дядю только из за денег не будут.
Хорошо написано, да. Порекомендуйте, что почитать / изучить на тему архитектуры и мастшабируемых приложений?
4. Безопасность. Только с опытом приходит, на лабораторных или олимпиадах этому не натренируют.
А вот с этим тезисом не согласен.
Кстати я бы не хотел себе в команду человека эксперта в алгоритмах, но без опыта работы над реальными проектами и задачами, точнее без опыта успешного запуска и развития проектов. Есть ведь мнение что всякие "лаборанты" рубящие в алгоритамах, ученые всякие, пишут корявый код.
Что-то в последнее время слишком много разговоров про "ученые и олимпиадники пишут один только кривой код". На самом деле, код разный. Бывает, что и кривой, а бывает, что очень даже неплохой. На олимпиадах тех же самых, как правило вырабатываются кое-какие навыки написания краткого кода, который делает то, что надо. При правильном оборачивании такого кода в набор методов — может получиться правильно организованная библиотека.
"Правильно организованную библиотеку" иногда приходится править/расширять через долгое время (когда организация программы "вылетела" из краткосрочной памяти). Это то, чего с "олимпиадным" кодом не приходится делать никогда.
Другой вопрос, что на практике олимпиадника бывает гораздо проще научить вменяемый код, чем не-олимпиадника. Хороший олимпиадник вполне отдаёт себе отчёт в том, чем он жертвует, когда пытается написать год покороче, у него просто опыта нет.
С олимпиадниками главный вопрос — это в отношении: если он понимает, что его олимпиадные успехи — это хоть и хорошая основа, но всё-таки всего лишь основа (и ему многому нужно научиться если он хочет стать хорошим специалистом), то он очень быстро обучается всему чему нужно, если же он считает, что раз он побеждал в олимпиадах, то у "старых пердунов" ему уже нечему учиться — то может вообще "не вписаться" в профессию.
С учёными же всё гораздо сложнее: они, как бы, и не должны быть хорошими программистами (их ценность в другом), потому заставить их изучать разные программистские премудрости не получится. Но если у них возникает желание — они тоже легко научаются грамотно программировать.
P.S. А вообще чем больше я общаюсь с разными людьми, тем больше убеждаюсь в том, что "таланта не существует". Грубо говоря для того, чтобы освоить ту или иную вещь нужно потратить на её обучение определённое количество часов. Ну пусть 100. И вот "талант" — ломает голову себе над изучаемым предметом днём и ночью, тренируется когда только может — и в результате через неделю-другую показывает "невиданные успехи". А "бездарь" — делает уроки два раза в неделю, причём и на них умудряется не "учиться", а "в облаках витать" — у него на то же самое уходит два года. Но "чистого времени", затраченного на обучение, у них поровну!
Другой вопрос, что на практике олимпиадника бывает гораздо проще научить вменяемый код, чем не-олимпиадника. Хороший олимпиадник вполне отдаёт себе отчёт в том, чем он жертвует, когда пытается написать год покороче, у него просто опыта нет.
С олимпиадниками главный вопрос — это в отношении: если он понимает, что его олимпиадные успехи — это хоть и хорошая основа, но всё-таки всего лишь основа (и ему многому нужно научиться если он хочет стать хорошим специалистом), то он очень быстро обучается всему чему нужно, если же он считает, что раз он побеждал в олимпиадах, то у "старых пердунов" ему уже нечему учиться — то может вообще "не вписаться" в профессию.
С учёными же всё гораздо сложнее: они, как бы, и не должны быть хорошими программистами (их ценность в другом), потому заставить их изучать разные программистские премудрости не получится. Но если у них возникает желание — они тоже легко научаются грамотно программировать.
P.S. А вообще чем больше я общаюсь с разными людьми, тем больше убеждаюсь в том, что "таланта не существует". Грубо говоря для того, чтобы освоить ту или иную вещь нужно потратить на её обучение определённое количество часов. Ну пусть 100. И вот "талант" — ломает голову себе над изучаемым предметом днём и ночью, тренируется когда только может — и в результате через неделю-другую показывает "невиданные успехи". А "бездарь" — делает уроки два раза в неделю, причём и на них умудряется не "учиться", а "в облаках витать" — у него на то же самое уходит два года. Но "чистого времени", затраченного на обучение, у них поровну!
А вообще чем больше я общаюсь с разными людьми, тем больше убеждаюсь в том, что «таланта не существует».
Да, только тогда не понятно, как объяснить, что у людей с вдвое меньшим опытом продуктивность в 2-3 раза выше. Как объяснить то, что одни пишут красивый легко поддерживаемый код, а другие — средний. Итд.
> как объяснить, что у людей с вдвое меньшим опытом продуктивность в 2-3 раза выше
Это-то как раз не феномен, а логичное следствие :) В среднем чем меньше у человека опыт, тем интереснее ему работать.
> Как объяснить то, что одни пишут красивый легко поддерживаемый код, а другие — средний. Итд.
Я не согласен с предыдущем комментатором в том плане, что якобы таланта не существует. Существует, конечно же. Но талант выражается в нестандартных решения и новых идеях, а не в количестве или качестве кода. Количество и качество кода — результат как раз прилежности и аккуратности, а эти свойства не врожденные, а приобретаемые.
Это-то как раз не феномен, а логичное следствие :) В среднем чем меньше у человека опыт, тем интереснее ему работать.
> Как объяснить то, что одни пишут красивый легко поддерживаемый код, а другие — средний. Итд.
Я не согласен с предыдущем комментатором в том плане, что якобы таланта не существует. Существует, конечно же. Но талант выражается в нестандартных решения и новых идеях, а не в количестве или качестве кода. Количество и качество кода — результат как раз прилежности и аккуратности, а эти свойства не врожденные, а приобретаемые.
Это-то как раз не феномен, а логичное следствие :) В среднем чем меньше у человека опыт, тем интереснее ему работать.
Наверное, и такое бывает. Но есть другое объяснение, более простое: одни делают вещи быстрее, чем другие, изначально.
Но талант выражается в нестандартных решения и новых идеях, а не в количестве или качестве кода. Количество и качество кода — результат как раз прилежности и аккуратности, а эти свойства не врожденные, а приобретаемые.
В чем выражается талант — это вопрос. Красивый код писать — это тоже талант. Пишется его не так много. Люди без опыта как правило не могут этого сделать. Но некоторые все-таки могут. Причем, опять же, делают это не хуже, а лучше, чем люди с опытом в 2-3 раза больше. Это врожденная способность понимать красоту. Объяснение вида "у них больше мотивации" не выглядит убедительным. Я полагаю, что у детей из бедных кварталов немало мотивации, но почему-то не все из них становятся Роберто Карлосами. Думаю, аналогия понятна.
Можно сказать жестче — для большинства задач вы будете профнепригодны...и правда жестко. Странное обращение к читателю, своей радикальностью вызывает страх и уважение к автору. Резюмируется призывом
все-таки более осторожно относился к окружающимИ заканчивается ссылкой на отличные курсы.
Как то текст не по Станиславскому построен.
Просто надо параллельно практике подучивать алгоритмы, желательно те, что используются внутри используемых технологий. Не до, не вместо, а вместе, оставляя приоритет за практикой.
Забавный пример проф. деформации. Прочитав фразу «не владеет пониманием доступных ему в *nix среде готовых инструментов и пишет свой (для запуска джобов — свой крон изобретает, условно) — то это труба.», воспринял слово «труба» неправильно, и на полном серьезе пытался осознать сказанное в терминах pipeline.
- Как отличить музыканта от программиста?
- Покажите им C#. Музыкант прочитает "до диез", а программист "си шарп"
У меня друг музыкант-программист. Даже интересно стало...
Си диез же
Си диез — это как-то вообще неясно из какой оперы. Если это ноты — то это однозначно "До", а если не ноты, то откуда диез?
Разве что ответ из разряда "поставить в тупик спрашивающего".
Разве что ответ из разряда "поставить в тупик спрашивающего".
Просто среди моих друзей-программистов, которые увлекаются музыкой, бытует именно такое прочтение C# — мол, оттуда и оттуда взяли что-то. До шарп как-то не звучит
Не хотел никого ставить в тупик.
Не хотел никого ставить в тупик.
До шарп как-то не звучитДо шарп — это уж ни в какие ворота. А сам по себе «шарп» как раз очень даже «звучит».
«Sharp» — это как раз «диез» по английски.
Так что шутка про «до диез» и «си шарп» — это чисто вопрос перевода. У англоязычных и музыкантов и программистов что C#, что C♯ — читается одинаково, никакой разницы :-)
Друга замкнуло, и он меня послал)
Автор описывает частности и возводит их в ранг знания. Но это ошибка.
Люди, разбирающиеся в алгоритмах, без проблем осваивают частные рабочие технологии "и другие страшные слова".
И я видел много людей, которые не имеют базиса, но разобрались с несколькими частными технологиями. Знания их добыты колоссальным количеством времени или большим опытом — неважно. Важно то, что некоторые из них свою мозаику в голове представляют как идеал. И им сложно смириться с тем, что их знания механистичны по своей природе, и представляют собой только практическую ценность в режиме " чтобы все работало".
Люди, разбирающиеся в алгоритмах, без проблем осваивают частные рабочие технологии "и другие страшные слова".
И я видел много людей, которые не имеют базиса, но разобрались с несколькими частными технологиями. Знания их добыты колоссальным количеством времени или большим опытом — неважно. Важно то, что некоторые из них свою мозаику в голове представляют как идеал. И им сложно смириться с тем, что их знания механистичны по своей природе, и представляют собой только практическую ценность в режиме " чтобы все работало".
Архитектура — очень хорошо. Знание алгоритмов — все таки не один и тот же, хоть и связанный скилл.
Базы данных: есть особый спектр специалистов, они с базами данных не работают вообще и не про какую оптимизацию запросов everyday не слышали и не услышат. (ну, например, среди программистов C++ такие встречаются) Это, однако, не означает, что они не смогут оптимизировать запрос. Потому что решает в конечном счете понимание принципов. В комментариях к этой и изначальным статьям прослеживаются выводы типа "Успех проекта был обусловен знанием пяти команд Unix'а, а не знанием алгоритмов". Это мне напоминает особо интересные собеседования по языкам программирования, где ставятся вопросы из разряда "А какой в методе Y у класса X аргумент номер 2?" Имхо, более толковый специалист — тот, кто НЕ зная этих 5-ти команд или не зная этого метода, сможет предположить их наличие, сможет найти эти объекты и разобраться в них, применить их на практике. Это одна из причин, по которой на некотоых собеседованиях вы не увидите сложных тестов из 40 вопросов на знание языков C++ и C# или на знание стандартной библиотеки. К примеру, иногда приходится собеседовать людей (совсем зеленых на низкие позиции), которые не знают внутренних особенностей STL. Но если они способны продемонстрировать понимание, как самостоятельно реализовать ту или иную вещь в STL — это гораздо важнее.
Базы данных: есть особый спектр специалистов, они с базами данных не работают вообще и не про какую оптимизацию запросов everyday не слышали и не услышат. (ну, например, среди программистов C++ такие встречаются) Это, однако, не означает, что они не смогут оптимизировать запрос. Потому что решает в конечном счете понимание принципов. В комментариях к этой и изначальным статьям прослеживаются выводы типа "Успех проекта был обусловен знанием пяти команд Unix'а, а не знанием алгоритмов". Это мне напоминает особо интересные собеседования по языкам программирования, где ставятся вопросы из разряда "А какой в методе Y у класса X аргумент номер 2?" Имхо, более толковый специалист — тот, кто НЕ зная этих 5-ти команд или не зная этого метода, сможет предположить их наличие, сможет найти эти объекты и разобраться в них, применить их на практике. Это одна из причин, по которой на некотоых собеседованиях вы не увидите сложных тестов из 40 вопросов на знание языков C++ и C# или на знание стандартной библиотеки. К примеру, иногда приходится собеседовать людей (совсем зеленых на низкие позиции), которые не знают внутренних особенностей STL. Но если они способны продемонстрировать понимание, как самостоятельно реализовать ту или иную вещь в STL — это гораздо важнее.
Это всё равно, что написать заголовок "Должен ли учёный знать биологию?" и потом долго расписывать на примере математика, что учёный может сколько угодно знать об устройстве тела, о том, как обеспечивать эффективную работу мозга и т.п., но без глубокого знания математических дисциплин (алгебры, геометрии, теории чисел и т.п.) учёный проф. непригоден. (на случай, если моя аналогия непонятна, напомню, что кроме математиков учёными называют ещё биологов, физиков, философов и т.п.)
Программист программисту рознь. Автор, как мне показалось, писал имея в голове равенство программист=веб-программист. И я посмотрю на автора как он без знания алгоритмов, или хотя бы умения их искать, реализует какую-нибудь очень критичную к производительности программу на OpenCL, зависящую, например, от разложения многочлена на множители.
Программист программисту рознь. Автор, как мне показалось, писал имея в голове равенство программист=веб-программист. И я посмотрю на автора как он без знания алгоритмов, или хотя бы умения их искать, реализует какую-нибудь очень критичную к производительности программу на OpenCL, зависящую, например, от разложения многочлена на множители.
К бесу OpenCL. Я ведь тоже — веб-программист. Не сейчас, но в прошлом. И помнится мы лет пять назад решали одну задачку из серии "сетевых технологий": успеем мы прогнать за месяц через имеющиеся у нас каналы данные в базу или дешевле и надёжнее будет всё-таки пропускать через таможню. Задачка простоя, в общем-то: данные подвозились, если мне не изменяет память, на 100 HDD в месяц, на каждом HDD 2TB (это было выгоднее, чем уже существовавшие тогда 4TB)...
Но я другом: если всё это потом, после пересылки, загрузить в SQL-базу, то никакая "оптимизация запросов" не поможет! Нужны свои структуры и нужно весьма много алгоритмов, чтобы со всем этим совладать.
Но вообще — автор прав (я про это уже писал), как ни странно. Подавляющее большинство ПО — делается для конкретного заказчика. И его цена играет решающее значение. Сделать что-то тяп-ляп, без алгоритмов и без архитектуры — зачастую дешевле и проще.
Это-то всё понятно. Непонятно другое: почему вдруг люди, которые всю жизнь работали, грубо говоря, в Макдональдсе и даже испекли там 100500 гамбургеров засунув их в печку вдруг заявляют что они могут приготовить классный обед в ресторане без знания того какие продукты с чем сочетаются и вообще "без изучения теории". Вот это-то откуда берётся?
А с тем, что классный повар — это не просто человек, отлично теоретически изучивший свойства продуктов — никто и не спорит. Глупо и бессмысленно.
Но я другом: если всё это потом, после пересылки, загрузить в SQL-базу, то никакая "оптимизация запросов" не поможет! Нужны свои структуры и нужно весьма много алгоритмов, чтобы со всем этим совладать.
Но вообще — автор прав (я про это уже писал), как ни странно. Подавляющее большинство ПО — делается для конкретного заказчика. И его цена играет решающее значение. Сделать что-то тяп-ляп, без алгоритмов и без архитектуры — зачастую дешевле и проще.
Это-то всё понятно. Непонятно другое: почему вдруг люди, которые всю жизнь работали, грубо говоря, в Макдональдсе и даже испекли там 100500 гамбургеров засунув их в печку вдруг заявляют что они могут приготовить классный обед в ресторане без знания того какие продукты с чем сочетаются и вообще "без изучения теории". Вот это-то откуда берётся?
А с тем, что классный повар — это не просто человек, отлично теоретически изучивший свойства продуктов — никто и не спорит. Глупо и бессмысленно.
Итак подытожим: знание алгоритмов нужно, технологий тоже нужно, понимание архитектуры и др. основ программирования необходимо, мозг во включенном состоянии нужен обязательно. Все — тему можно закрывать.
Мне кажется программист, как инженер, прежде всего должен понимать для чего создавался инструмент и в каких случаях им целесообразно пользоваться. Для этого он должен уметь разобраться и понять сущность этого инструмента. Алгоритмы еще один обширный инструмент, который немного бы надо знать, для кругозора. Весь говнокод который я видел был поражден плохим руководством, отсутствием взаимодействия в команде и недостаточным уровне IQ для рационального использования той или иной технологии. Даже зная алгоритмы, плохой программист и все равно КРИВО применит, я незнающий прямой, изучит и применит прямо. Неправильные пчелы делают неправильный мед.
У меня сейчас знания по лагоритмам посредственные, я бы сказал просто имею представление, при необходимости буду читать учить и разбираться, ровно как и с другими технологиями. На изучение какой-то технологии уходит больше времени, на какой-то другой меньше, но голова с прямыми руками вероятнее всего со временем будет приближаться к верному результату.
У меня сейчас знания по лагоритмам посредственные, я бы сказал просто имею представление, при необходимости буду читать учить и разбираться, ровно как и с другими технологиями. На изучение какой-то технологии уходит больше времени, на какой-то другой меньше, но голова с прямыми руками вероятнее всего со временем будет приближаться к верному результату.
«что у него в веб-приложении не грузится определенная часть данных из-за неверно прописанных роутов или лагающего DNS-сервера.»
Я звиняюсь, но автор действительно сталкивался с тем, что ЧАСТЬ ДАННЫХ не грузилась из-за трассы роутинга?
Или автор тоже не сильно в курсе сетевых технологий?
Я звиняюсь, но автор действительно сталкивался с тем, что ЧАСТЬ ДАННЫХ не грузилась из-за трассы роутинга?
Или автор тоже не сильно в курсе сетевых технологий?
У вас открывается веб-страница, отрабатывают аякс-запросы, уходящие на поддомены.
Часть скриптов грузится с других поддоменов.
Удивительным образом один из поддоменов смотрит на сервак с другой версией кода,
чем тот, который вы тестируете (про дальнейшую цепочку распределения через балансировщики я не пишу).
Допереть, почему код в ответ на аякс запрос, возвращает не то, что нужно, хотя вроде бы работает,
могут далеко не все. Хотя когда знаешь ответ — это очевидно.
Кейс из жизни, если что.
Ну а про неверно прописанные NS-записи и глюки из-за этого думаю, у каждого полно историй из опыта.
Часть скриптов грузится с других поддоменов.
Удивительным образом один из поддоменов смотрит на сервак с другой версией кода,
чем тот, который вы тестируете (про дальнейшую цепочку распределения через балансировщики я не пишу).
Допереть, почему код в ответ на аякс запрос, возвращает не то, что нужно, хотя вроде бы работает,
могут далеко не все. Хотя когда знаешь ответ — это очевидно.
Кейс из жизни, если что.
Ну а про неверно прописанные NS-записи и глюки из-за этого думаю, у каждого полно историй из опыта.
Мне будет над чем подумать, благодарю :)
И звиняюсь за наезд, необоснованно было.
И звиняюсь за наезд, необоснованно было.
Все норм.
А вообще то же умение дебажить — оно пипец как сложно.
Просто чем отличается мышление теоретика vs практика (если до предела упростить)?
Я строю алгоритм в голове/на бумаге, рассчитываю что он будет офигенно работать,
и запускаю… получаю какие-то баги. Работает не так, как задумано.
И если ПИПЕЦ УВЕРЕН что все правильно прикинул, сколько там памяти будет жрать и тд,
то ошибку не найдешь.
А если в голове имеешь опыт построения гипотез и их проверки (последовательно прикидывая возможные точки отказа),
то отладишь гораздо быстрее.
Тут стоит добавить, что есть типа еще BDD/TDD — в идеале и дебажить не нужно, сразу все работает и потом менять проще (сразу видишь по тестам, что поломал),
но в целом ряде областей веб-программирования, highload систем и тд многие вещи тестами
лишь имитируются (иногда через такую жопу, что страшно), либо вообще не воссоздаются в принципе.
В общем, чем больше знаешь и умеешь и в целом мозги круче — тем лучше из тебя программист
А вообще то же умение дебажить — оно пипец как сложно.
Просто чем отличается мышление теоретика vs практика (если до предела упростить)?
Я строю алгоритм в голове/на бумаге, рассчитываю что он будет офигенно работать,
и запускаю… получаю какие-то баги. Работает не так, как задумано.
И если ПИПЕЦ УВЕРЕН что все правильно прикинул, сколько там памяти будет жрать и тд,
то ошибку не найдешь.
А если в голове имеешь опыт построения гипотез и их проверки (последовательно прикидывая возможные точки отказа),
то отладишь гораздо быстрее.
Тут стоит добавить, что есть типа еще BDD/TDD — в идеале и дебажить не нужно, сразу все работает и потом менять проще (сразу видишь по тестам, что поломал),
но в целом ряде областей веб-программирования, highload систем и тд многие вещи тестами
лишь имитируются (иногда через такую жопу, что страшно), либо вообще не воссоздаются в принципе.
В общем, чем больше знаешь и умеешь и в целом мозги круче — тем лучше из тебя программист
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Алгоритмы — это лишь одна из переменных в уравнении