Теоретик Антон
В этом посте я буду защищать позицию теоретика, а именно: инструкцию читать всё же иногда надо.
Наверное, каждый программист проходил через этот цикл: скопировал кусок кода со stackoverflow или "hello, world"-туториала, чуть допилил напильником - и заработало. “Ура, я знаю новую технологию!” Это окрыляет, и кажется, что теперь можно всё изучать сразу на практике.
Однако это работает мягко говоря не всегда. Прямо скажем, это ОК только для простых и средне-простых задач. Возьмём, к примеру, Rust, и его заморочки с памятью. При разработке вы сразу столкнетесь с выбором. Что использовать: &T или &mut T? А может, Cell<T>? Box<T>? Rc<Refcell<T>> ? А чем Mutex<T> отличается от Arc<Mutex<T>>? Тысячи их, таких вопросов.
Т.е. на практике это будет выглядеть так: вы пробуете что-то написать, компилятор Rust говорит “ты дебил”. Пробуете другое - компилятор говорит, что всё равно дебил, попробуй еще раз. Stackoverflow поможет очень слабо. Нужно читать Rust Book, без вариантов.
Еще пример. Вы захотели написать свой язык программирования. Где-то слышали, что надо сначала сделать парсер, который преобразует текст в AST-дерево. Попробуйте это сделать интуитивно, без теории. Это совсем непросто. Как описать грамматику? Что такое сканнер (токенайзер)? Как сделать сканнер быстрым? Там огромное количество вопросов, которые придется переизобретать. Гораздо быстрее будет прочесть книжку, например от создателя Dart: https://craftinginterpreters.com/contents.html
Вообще, в сложных задачах есть всего два пути, изобретать самому или пользоваться изобретениями других людей. Изобретать самому интереснее, но в 100 раз дольше.
Иногда нужно знать теорию в смежных областях, не только в самой IT. Взять, например, математическую статистику. Сколько нужно экспериментов, чтобы достоверно сказать, что такой способ размещения рекламы на сайте наиболее выгоден?
Некоторые вещи не столь конкретны, но не менее важны. Например, куча говнокода возникает только из-за того, что человек не удосужился прочесть ни одной книги про качество кода. Ты с ним говоришь как будто на разных языках. Даже очевидные вещи, например, god object или слишком большой и запутанный метод, могут вызывать споры на тему “а надо ли это упрощать”.
В общем, рано, рано еще теорию списывать со счетов. Без теории запросто можно красить кнопки, но вот создать что-то по настоящему сложное или ответственное - увы.
В этом посте я буду защищать позицию теоретика, а именно: инструкцию читать всё же иногда надо.
Наверное, каждый программист проходил через этот цикл: скопировал кусок кода со stackoverflow или "hello, world"-туториала, чуть допилил напильником - и заработало. “Ура, я знаю новую технологию!” Это окрыляет, и кажется, что теперь можно всё изучать сразу на практике.
Однако это работает мягко говоря не всегда. Прямо скажем, это ОК только для простых и средне-простых задач. Возьмём, к примеру, Rust, и его заморочки с памятью. При разработке вы сразу столкнетесь с выбором. Что использовать: &T или &mut T? А может, Cell<T>? Box<T>? Rc<Refcell<T>> ? А чем Mutex<T> отличается от Arc<Mutex<T>>? Тысячи их, таких вопросов.
Т.е. на практике это будет выглядеть так: вы пробуете что-то написать, компилятор Rust говорит “ты дебил”. Пробуете другое - компилятор говорит, что всё равно дебил, попробуй еще раз. Stackoverflow поможет очень слабо. Нужно читать Rust Book, без вариантов.
Еще пример. Вы захотели написать свой язык программирования. Где-то слышали, что надо сначала сделать парсер, который преобразует текст в AST-дерево. Попробуйте это сделать интуитивно, без теории. Это совсем непросто. Как описать грамматику? Что такое сканнер (токенайзер)? Как сделать сканнер быстрым? Там огромное количество вопросов, которые придется переизобретать. Гораздо быстрее будет прочесть книжку, например от создателя Dart: https://craftinginterpreters.com/contents.html
Вообще, в сложных задачах есть всего два пути, изобретать самому или пользоваться изобретениями других людей. Изобретать самому интереснее, но в 100 раз дольше.
Иногда нужно знать теорию в смежных областях, не только в самой IT. Взять, например, математическую статистику. Сколько нужно экспериментов, чтобы достоверно сказать, что такой способ размещения рекламы на сайте наиболее выгоден?
Некоторые вещи не столь конкретны, но не менее важны. Например, куча говнокода возникает только из-за того, что человек не удосужился прочесть ни одной книги про качество кода. Ты с ним говоришь как будто на разных языках. Даже очевидные вещи, например, god object или слишком большой и запутанный метод, могут вызывать споры на тему “а надо ли это упрощать”.
В общем, рано, рано еще теорию списывать со счетов. Без теории запросто можно красить кнопки, но вот создать что-то по настоящему сложное или ответственное - увы.