Программирование рассматривается как процесс создания компьютерных программ. Слово процесс в этом определении не лишнее. Обычно рассуждают в духе «посмотрите, какую замечательную структуру данных можно описать на данном языке программирования». Философия программирования подразумевает оглянуться по сторонам, да и в глубь копнуть.

Собственно разделение на кодирование, и создание алгоритмов это уже специфика, сначала идёт жизнь, то есть человек опирается на некую мысль вроде «напишу-ка я фреймворк с такими-то свойствами». И вот это начальное направление это вопрос философии. Проблема в том, что часто жена программиста лучше его самого знает, на философском уровне, что он делает и почему. Элементарные философские категории: мышление, сознание, обусловленность программисту неведомы. И это странно, если сравнить способность программиста мыслить, например, читая статьи по функциональному программированию или алгоритмам поиска, вперемешку со статьями видных русских или европейских философов, окажется, что собственно навык мышления у программистов развит не меньше, а то и больше. Вот только язык программиста очень богат пока он рассуждает о паттерн-матчинге и жалок и органичен когда ему надо выйти из своей песочницы, оторваться от IDE и файлового менеджера.

Введение

Я делала много вещей с компьютерами, но в моих знаниях всегда был пробел: что конкретно происходит при запуске программы на компьютере? Я думала об этом пробеле — у меня было много низкоуровневых знаний, но не было цельной картины. Программы действительно выполняются прямо в центральном процессоре (central processing unit, CPU)? Я использовала системные вызовы (syscalls), но как они работают? Чем они являются на самом деле? Как несколько программ выполняются одновременно?

Наконец, я сломалась и начала это выяснять. Мне пришлось перелопатить тонны ресурсов разного качества и иногда противоречащих друг другу. Несколько недель исследований и почти 40 страниц заметок спустя я решила, что гораздо лучше понимаю, как работают компьютеры от запуска до выполнения программы. Я бы убила за статью, в которой объясняется все, что я узнала, поэтому я решила написать эту статью.

И, как говорится, ты по-настоящему знаешь что-то, только если можешь объяснить это другому.

Более удобный формат статьи.

Так как карьера программиста тесно связана с процессором, неплохо бы знать как он работает.

Что происходит внутри процессора? Сколько времени уходит на исполнение одной инструкции? Что значит, когда новый процессор имеет 12, или 18, или даже 31-уровневый конвейер?

Программы обычно работают с процессором, как с чёрным ящиком. Инструкции входят и выходят из него по порядку, а внутри совершается некая вычислительная магия.

Программисту полезно знать, что происходит внутри этого ящика, особенно, если он будет заниматься оптимизацией программ. Если вы не знаете какие процессы протекают внутри процессора, как вы сможете оптимизировать под него?

Эта статья рассказывает, как устроен вычислительный конвейер x86 процессора.

Этот пост является версией моей же англоязычной статьи "How to avoid gotchas in Go", но слово gotcha не переводится на русский, поэтому я буду использовать это слово как без перевода, так и немного непрямой вариант — "наступать на грабли".

Gotcha — корректная конструкция системы, программы или языка программирования, которая работает, как описано, но, при этом, контринтуитивна и является причиной ошибок, поскольку её легко использовать неверно.

В языке Go есть несколько таких gotchas и есть немало хороших статей, которые их подробно описывают и разъясняют. Я считаю, что эти статьи очень важны, особенно для новичков в Go, поскольку регулярно вижу людей, попадающихся на те же грабли.

Но один вопрос меня мучал долгое время — почему я сам никогда не делал этих ошибок? Серьезно, самые популярные из них, вроде путаницы с nil-интерфейсом или непонятного результата при append()-е слайса — в моей практике никогда не были проблемой. Каким-то образом мне повезло обойти эти подводные камни с первых дней своей работы с Go. Что же мне помогло?

И ответ оказался довольно прост. Я просто очень вовремя прочёл несколько хороших статей о внутреннем устройстве структур данных в Go и прочих деталях реализации. И этого, вполне поверхностного на самом деле, знания было достаточно, чтобы выработать некоторую интуицию и избегать этих подводных камней.

Примечание: первоначально эта статья была написана для сайта Fuel Your Coding back в мае 2010 года. К сожалению, этот сайт сейчас не работает, поэтому я публикую статью здесь, чтобы сохранить её для потомков. Я собирался обновить её, учитывая последние веяния, но решил оставить так, как она была написана. Те части, что подустарели, могут показаться немного смешными, но да ладно. Получайте удовольствие…

Наиболее очевидным способом повысить качество своего программирования является писать больше программ. Каждый знает это. Однако другой способ, который, я уверен, улучшит ваше программирование, — совершенно противоположный. Изложу это так ясно, как смогу.

Если вы желаете резко поднять ваше умение программировать, необходимо… читать код, написанный другими программистами.

Вы можете верить в это, можете не верить. Ваше право. Но если вы готовы рискнуть, то, уверен, вы будете вознаграждены за потраченное время.

В этой статье я хотел бы помочь вам в выборе того, что именно читать, и дать практические советы по такому чтению. Если вы уже и так читаете другие программы, то, может быть, вы найдёте здесь что-нибудь, что позволит получить больше от ваших усилий. Если же вы не читаете коды других разработчиков, то вы просто обязаны заняться этим.

Продолжая тему устройства в FAANG, которую уже мы поднимали в нашем блоге, и специально к старту нового потока нашего курса по алгоритмам сегодня делюсь описанием пути Эско Обонга, старшего инженера-программиста Uber.

Эта история началась в 2015 году, когда стартап, к которому я присоединился как «сотрудник-основатель», закрылся через шесть месяцев после первого раунда инвестиций, и я искал новую работу. Первое моё собеседование было с  Codecademy, где на этапе телефонного разговора меня заверили: «Не волнуйтесь, мы не задаём сумасшедших вопросов об алгоритмах или что-то в этом роде». И я им поверил…

Что такое структура данных?
Проще говоря, структура данных — это контейнер, в котором хранятся данные в определенной компоновке (формате, или способе организации их в памяти). Эта «компоновка» позволяет структуре данных быть эффективной в одних операциях и неэффективной в других. Ваша цель — понять структуры данных, чтобы вы могли выбрать структуру данных, наиболее оптимальную для рассматриваемой проблемы.

Зачем нам нужны структуры данных?
Поскольку структуры данных используются для хранения данных в организованном виде, и поскольку данные являются наиболее важным элементом компьютерной науки, истинная ценность структур данных очевидна.
Независимо от того, какую проблему вы решаете, вам так или иначе приходится иметь дело с данными — будь то зарплата сотрудника, цены на акции, список покупок или даже простой телефонный справочник.
Исходя из разных сценариев, данные должны храниться в определенном формате. У нас есть несколько структур данных, которые покрывают потребность хранить данные в разных форматах.

Введение

В этом посте мы рассмотрим производительность горутин (goroutine). Горутины — это нечто в роде очень дешевых и легковесных потоков. Больше всего, наверное, они похожи на процессы в Erlang.

Согласно документации мы можем использовать сотни тысяч горутин в наших программах. И цель статьи — проверить и конкретизировать это.

Бывает, просыпаешься рано утром, готовишь вкусный кофе, чтобы настроиться на рабочий день. Гладишь своего кота, садишься за стол… и после нескольких часов работы начинаешь чувствовать боль в спине. В результате снижается продуктивность и концентрация на задачах. В статье расскажу, какие методы помогли мне решить эту проблему. Подробности под катом.