Visicalc

Предположим, я заказываю буррито для двоих друзей и хочу рассчитать общую стоимость заказа:



Поток данных в этой таблице немного сложно проследить, поэтому вот эквивалентная диаграмма, которая представляет таблицу в виде графа:



Округляем стоимость буррито El Farolito super vegi до 8 долларов, поэтому при доставке стоимостью 2 доллара общая сумма составит 20 долларов.

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



Эта простая стратегия пересчета всего документа может показаться расточительной, но на самом деле она уже лучше, чем было в VisiCalc, первых электронных таблицах в истории, и первом так называемом убойному приложению, благодаря которому стали популярными компьютеры Apple II. VisiCalc многократно пересчитывал ячейки слева направо и сверху вниз, сканируя их снова и снова, хотя ни одна из них не менялась. Несмотря на такой интересный алгоритм, VisiCalc оставался доминирующим программным обеспечением для электронных таблиц в течение четырёх лет. Его правление закончилось в 1983 году, когда Lotus 1-2-3 захватил рынок пересчётом в естественном порядке (natural-order recalculation). Вот как его описывал Трейси Робнетт Ликлайдер в журнале Byte:

Lotus 1-2-3 использовал пересчёт в естественном порядке, хотя также поддерживал построчный и поколончатый режимы VisiCalc. Пересчёт в естественном порядке поддерживал список зависимостей ячеек и пересчитывал ячейки с учётом зависимостей.

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

Но что насчёт цены буррито с доставкой

Действительно. В моём примере с тремя буррито нет причин пересчитывать цену одного буррито с доставкой, потому что изменение количества буррито в заказе не может повлиять на цену буррито. В 1989 году один из конкурентов Lotus понял это и создал SuperCalc5, предположительно назвав его в честь теории супер буррито, лежащей в основе этого алгоритма. SuperCalc5 пересчитывал только ячейки, зависящие от изменённых ячеек, так что обновление количества буррито становилось примерно таким:



Обновляя ячейку только при изменении входных данных, мы можем избежать пересчёта цены буррито с доставкой. В этом случае мы сэкономим всего одно сложение, но в больших электронных таблицах экономия может оказаться гораздо более существенной! К сожалению, сейчас у нас другая проблема. Скажем, мои друзья теперь хотят мясные буррито, которые на доллар дороже, а закусочная El Farolito добавляет 2 доллара к заказу независимо количества буррито. Прежде чем что-то пересчитать, посмотрим на граф:



Поскольку здесь обновляются две ячейки, у нас проблема. Следует сначала пересчитать цену одного буррито или общую? В идеале мы сначала вычисляем цену буррито, замечаем изменение, затем пересчитываем цену буррито с доставкой и, наконец, пересчитываем Total. Однако, если мы вместо этого сначала пересчитаем общую сумму, нам придётся пересчитать ее во второй раз, как только новая цена буррито 9 долларов распространится вниз по ячейкам. Если мы не вычисляем ячейки в правильном порядке, этот алгоритм не лучше, чем пересчёт всего документа. В некоторых случаях такой же медленный, как VisiCalc!

Очевидно, нам важно определить правильный порядок обновления ячеек. В общем, есть два решения этой проблемы: загрязнение ячеек (dirty marking) и топологическая сортировка.

Первое решение включает в себя маркировку всех ячеек вниз по потоку от обновлённой ячейки. Они помечаются как грязные. Например, когда мы обновляем цену буррито, то помечаем нижестоящие ячейки Burrito Price w Ship и Total, прежде чем делать какой-либо пересчёт:



Затем в цикле находим грязную ячейку без грязных входов и пересчитываем её. Когда грязных ячеек не останется, мы закончили! Это решает нашу проблему с зависимостями. Однако есть один недостаток если ячейка пересчитана и мы обнаружили, что новый результат совпадает с предыдущим, мы всё равно пересчитаем нижестоящие ячейки! Немного дополнительной логики поможет избежать проблемы, но, к сожалению, мы всё равно тратим время на маркировку ячеек и снятие маркировки.

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



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

Это намного лучше первого решения: ни одна ячейка не маркируется грязной, если одна из входящих ячеек действительно не изменится. Однако это требует сохранять ячейки в отсортированном порядке в ожидании пересчёта. При использовании кучи это приводит к замедлению O(n log n), что в худшем случае асимптотически медленнее, чем стратегия Lotus 1-2-3 по пересчёту всего.

Современный Excel применяет сочетание загрязнения и топологической сортировки, подробнее см. в их документации.

Ленивые вычисления

Теперь мы более или менее достигли алгоритмов пересчёта в современных электронных таблицах. Подозреваю, что в принципе нет никаких бизнес-обоснований для дальнейших их улучшений, к сожалению. Люди уже написали достаточно формул Excel, чтобы миграция на любую другую платформу стала невозможной. К счастью, я не разбираюсь в бизнесе, поэтому мы всё равно рассмотрим дальнейшие улучшения.

Кроме кэширования, один из интересных аспектов вычислительного графа в стиле электронных таблиц заключается в том, что мы можем вычислять только те ячейки, которые нас интересуют. Это иногда называют ленивыми вычислениями или demand-driven computation. В качестве более конкретного примера приведём немного расширенный график электронной таблицы с буррито. Пример такой же, как и раньше, но мы добавили то, что лучше всего описать как расчёт сальсы. Каждый буррито содержит 40 граммов сальсы, и мы выполняем быстрое умножение, чтобы узнать, сколько сальсы во всём заказе. Поскольку в нашем заказе три буррито, всего будет 120 граммов сальсы.



Конечно, проницательные читатели уже заметили проблему: общий вес сальсы в заказе довольно бесполезная метрика. Кого волнует, что это 120 грамм? Что мне делать с этой информацией? К сожалению, обычная электронная таблица потратит циклы на расчёт сальсы, даже если большую часть времени нам эти расчёты не нужны.

Именно здесь может помочь ленивый перерасчёт. Если каким-то образом указать, что нас интересует только результат Total, можно было бы пересчитать эту ячейку, её зависимости и не трогать сальсу. Давайте назовём Total наблюдаемой ячейкой, поскольку мы пытаемся посмотреть на её результат. Мы также можем назвать Total и три её зависимости необходимыми ячейками, поскольку они необходимы для вычисления некоторой наблюдаемой ячейки. Salsa In Order и Salsa Per Burrito назовём ненужными (unnecessary).

Для решения этой проблемы некоторые товарищи из команды Rust создали фреймворк Salsa, явно назвав его в честь ненужных вычислений сальсы, на которые тратились циклы их компьютеров. Наверняка они могут лучше меня объяснить, как он работает. Очень грубо, фреймворк использует номера ревизий для отслеживания того, нуждается ли ячейка в пересчёте. Любая мутация в формуле или входных данных увеличивает глобальный номер ревизии, и каждая ячейка отслеживает две ревизии: verified_at для ревизии, результат которой был обновлён, и changed_at для ревизии, результат которой был фактически изменён.



Когда пользователь указывает, что ему нужно новое значение Total, мы сначала рекурсивно пересчитываем все ячейки, необходимые для Total, пропуская ячейки, в которых ревизия last_updated равна глобальной ревизии. Как только зависимости Total обновлены, мы повторно запускаем фактическую формулу Total только в том случае, если либо у Burrito Price w Ship, либо у Num Burrito ревизия changed_at больше, чем проверенная ревизия Total. Это отлично подходит для Salsa в rust-analyzer, где важна простота, а вычисление каждой ячейки требует значительного времени. Однако в графике с буррито выше можно заметить и недостатки если Salsa Per Burrito постоянно меняется, то наш глобальный номер ревизии будет часто повышаться. В результате каждое наблюдение Total потребует прохода трёх ячеек, даже если ни одна из них не изменилась. Никакие формулы не будут пересчитаны, но если график большой, многократное прохождение всех зависимостей ячейки может оказаться дорогостоящим.

Более быстрые варианты ленивых вычислений

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

Сначала посмотрим на маркировку. Как и раньше, когда мы меняем формулу ячейки, то помечаем все нижестоящие ячейки как грязные. Поэтому при обновлении Salsa Per Burrito это будет выглядеть примерно так:



Но вместо того, чтобы немедленно пересчитать все грязные ячейки, мы ждём, пока пользователь не пронаблюдает ячейку. Затем запускаем на ней алгоритм Salsa, но вместо того, чтобы перепроверять зависимости с устаревшими номерами версий verified_at, мы перепроверяем только ячейки, помеченные как грязные. Такую технику использует Adapton. В такой ситуации наблюдение ячейки Total обнаруживает, что она не грязная, и поэтому мы можем пропустить проход по графу, который бы выполнила Salsa!

Если же пронаблюдать Salsa In Order, то она помечена как грязная, и поэтому мы перепроверим и пересчитаем и Salsa Per Burrito, и Salsa In Order. Даже здесь есть преимущества по сравнению с использованием только номеров ревизий, поскольку мы сможем пропустить рекурсивный проход по всё ещё чистой ячейке Num Burritos.

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

Кроме грязной маркировки, мы можем адаптировать для ленивых вычислений и топологическую сортировку. Это метод использует библиотека Incremental от Джейн Стрит, и для правильной работы требуется ряд серьёзных трюков. Прежде чем реализовать ленивые вычисления, наш алгоритм топологической сортировки использовал кучу, чтобы определить, какая ячейка будет пересчитана следующей. Но сейчас мы хотим пересчитывать только те ячейки, которые необходимы. Как? Мы не хотим ходить по всему дереву из наблюдаемых ячеек, как Adapton, поскольку полный проход по дереву разрушает всю цель топологической сортировки и даст нам характеристики производительности, аналогичные Adapton.

Вместо этого Incremental поддерживает набор ячеек, которые пользователь отметил наблюдаемыми, а также набор ячеек, необходимых для любой наблюдаемой ячейки. Всякий раз, когда ячейка помечена как наблюдаемая или ненаблюдаемая, Incremental ходит по зависимостям этой ячейки, чтобы убедиться, что необходимые метки применены правильно. Затем мы добавляем ячейки в кучу пересчёта только в том случае, если они помечены как необходимые. В нашем графе буррито, если только Total является частью наблюдаемого множества, изменение Salsa in Order не приведёт ни к какому проходу по графу, так как пересчитываются только необходимые ячейки:



Это решает нашу проблему без нетерпеливого хождения по графику, чтобы пометить ячейки как грязные! Мы всё ещё должны помнить, что ячейка Salsa per Burrito является грязной, чтобы пересчитать её позже, если это станет необходимым. Но в отличие от алгоритма Adapton, нам не нужно проталкивать эту единственную грязную метку вниз по всему графу.

Anchors, гибридное решение

И Adapton, и Incremental проходят граф, даже если не пересчитывают ячейки. Incremental ходит по графу вверх, когда изменяется набор наблюдаемых ячеек, а Adapton ходит по графу вниз, когда изменяется формула. С маленькими графами может быть не сразу очевидной высокая цена этих проходов. Но если граф большой и ячейки относительно дёшево вычисляются часто так происходит с электронными таблицами вы обнаружите, что большая часть вычислений уходит на ненужное хождение по графу! Когда ячейки дёшевы, маркировка бита на ячейке может стоить примерно столько же, сколько просто пересчёт ячейки с нуля. Поэтому в идеале, если мы хотим, чтобы наш алгоритм был существенно быстрее, чем простое вычисление, следует избегать ненужного хождения по графу, насколько это возможно.

Чем больше я думал об этой проблеме, тем больше понимал, что они тратят время на проход графа в примерно противоположных ситуациях. В нашем графе буррито давайте представим, что формулы ячеек редко меняются, но мы быстро переключаемся, сначала наблюдая Total, а затем Salsa in Order.



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

В противоположном случае давайте представим граф, где наши формулы быстро меняются, но мы не меняем список наблюдаемых ячеек. Например, мы могли бы представить, что наблюдаем Total, быстро меняя цену буррито с 4+4 на 2*4.



Как и в предыдущем примере, мы на самом деле не пересчитываем много ячеек: 4+4 и 2*4 равно 8, поэтому в идеале мы пересчитываем только это арифметическое действие, когда пользователь делает это изменение. Но в отличие от предыдущего примера, Incremental теперь избегает хождения по дереву. С помощью Incremental мы кэшировали тот факт, что цена буррито является необходимой ячейкой, и поэтому, когда она меняется, мы можем пересчитать её, не проходя по графу. С помощью Adapton мы тратим время на маркировку Burrito Price w Ship и Total как грязной, даже если результат Burrito Price не изменяется.

Учитывая, что каждый алгоритм хорошо работает в вырожденных случаях другого, почему бы в идеале просто не обнаруживать эти вырожденные случаи и не переключаться на более быстрый алгоритм? Это то, что я попытался реализовать в моей собственной библиотеке Anchors. Она запускает оба алгоритма одновременно на одном и том же графе! Если это звучит дико, ненужно и слишком сложно, то вероятно потому, что так оно и есть.

Во многих случаях Anchors точно следуют алгоритму Incremental, что позволяет избежать вырожденного случая Adapton выше. Но когда ячейки помечены как ненаблюдаемые, их поведение немного расходится. Давайте посмотрим, что происходит. Начнём с пометки Total как наблюдаемой ячейки:



Если затем пометить Total как ненаблюдаемую ячейку, а Salsa in Order как наблюдаемую, традиционный алгоритм Incremental изменит граф, пройдя в процессе через все ячейки:



Anchors для этого изменения тоже обходит все ячейки, но создаёт другой граф:



Обратите внимание на флаги чистых ячеек! Когда ячейка больше не нужна, мы помечаем ее как чистую. Давайте посмотрим, что происходит, когда мы переходим от наблюдения Salsa in Order к Total:



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

Похоже, в закусочной El Farolito объявили скидку! Давайте снизим цену буррито на доллар. Как Anchors узнает, что нужно пересчитать сумму? До какого-либо пересчёта давайте посмотрим, как Anchors видит граф сразу после изменения цены буррито:



Если у ячейки чистый флаг, мы запускаем на ней традиционный алгоритм Adapton, охотно помечая нижестоящие ячейки как грязные. Когда мы позже запустим алгоритм Incremental, мы можем быстро сказать, что есть наблюдаемая ячейка, помеченная как грязная, и знаем, что нужно пересчитать её зависимости. Окончательный граф будет выглядеть следующим образом:



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



На необходимых ячейках запускаем алгоритм топологической сортировки Incremental. На остальных запускаем алгоритм Adapton.

Синтаксис буррито

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



Поскольку традиционные электронные таблицы не являются ленивыми, мы можем вычислять B1, B2 и B3 в любом порядке, а потом вычислить ячейку IF. Однако в ленивом мире, если мы сначала можем вычислить значение B1, то можем посмотреть результат, чтобы узнать, какое значение нужно пересчитать B2 или B3. К сожалению, в традиционных электронных таблицах IF не может выразить это!

Проблема: B2 одновременно ссылается на ячейку B2 и извлекает её значение. Большинство упомянутых в статье ленивых библиотек вместо этого явно различают ссылку на ячейку и акт извлечения её фактического значения. В Anchors мы называем эту ссылку на ячейку якорем (anchor). Подобно тому, как в реальной жизни буррито обёртывает кучу ингредиентов вместе, тип Anchor<T> обёртывает T. Таким образом, я полагаю, наша ячейка с веганским буррито становится Anchor<Burrito>, своего рода нелепым буррито из буррито. Функции могут передавать наши Anchor<Burrito> столько, сколько им захочется. Но когда они на самом деле разворачивают буррито, чтобы получить доступ к Burrito внутри, мы создаём в нашем графе ребро зависимости, указывая алгоритму перерасчёта, что ячейка может быть необходима и нуждается в пересчёте.

Подход, принятый Salsa и Adapton, состоит в том, чтобы использовать вызовы функций и нормальный поток управления как способ развернуть эти значения. Например, в Adapton мы могли бы записать ячейку Буррито для клиента примерно так:

let burrito_for_customer = cell!({    if get!(is_vegetarian) {        get!(vegi_burrito)    } else {        get!(meat_burrito)    }});

Различая ссылку на ячейку (здесь vegi_burrito) и акт развёртывания её значения (get!), Adapton может работать поверх операторов потока управления Rust, таких как if. Это отличное решение! Однако нужно немного магического глобального состояния для правильного подключения вызовов get! к ячейкам cell!, когда меняется is_vegetarian. Библиотека Anchors под влиянием Incremental использует менее магический подход. Подобно pre-async / await Future, Anchors позволяет запускать на Anchor<T> такие операции, как map и then. Так, приведённый выше пример будет выглядеть примерно так:

let burrito_for_customer: Anchor<Burrito> = is_vegetarian.then(|is_vegetarian: bool| -> Anchor<Burrito> {  if is_vegetarian {      vegi_burrito  } else {      meat_burrito  }});

Дальнейшее чтение

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

• Семь реализаций Incremental, отличный углубленный взгляд на внутренние компоненты Incremental, а также куча оптимизаций, таких как постоянное увеличение высоты, о которых у меня не было времени говорить, плюс умные способы обработки ячеек, изменяющих зависимости. Также стоит почитать у Рона Мински: Разбор FRP.
  
• Видео с объяснениями, как работает Salsa.
  
• Это тикет Salsa, где Мэтью Хаммер, создатель Adapton, терпеливо объясняет отсечки какому-то случайному прохожему (мне), который никак не поймёт, как они работают.
  
• В выступлении Рафа Левиена на Rustlab есть несколько действительно интересных вещей на эту тему в контексте графических интерфейсов. Для этой статьи он сказал, что Как работает автотрекинг и Автотрекинг: элегантный DX через ультрасовременный CS это отличные ресурсы.
  
• Должен признать, что на самом деле не понимаю Дифференциальный поток данных, но это основа базы данных Materialize. Планирование запросов в целом кажется возможным решением больших проблем с отсутствием кэша, от которых страдают многие из этих фреймворков. В ней нет встроенных ленивых вычислений, но Джейми Брэндон (спасибо!) любезно указал мне на сообщение в их блоге Латеральные соединения и ленивые запросы, которое объясняет, как добавить ленивые вычисления в качестве входных данных. Также стоит упоминания проект Noira от Массачусетского технологического института.
  
• Документация Adapton очень обширна.
  
• Оказывается, этот способ мышления применим и к системам сборки. Это одна из первых научных статей о сходствах между системами сборки и электронными таблицами.
  
• Slightly Incremental Ray Tracing слегка инкрементный трассировщик лучей, написанный на Ocaml.
  
• Только что посмотрел Частичное состояние в материализованных представлениях на основе потока данных, и оно кажется актуальным.
  
• Skip и Imp тоже выглядят очень интересно.

И конечно, вы всегда можете посмотреть мой фреймворк Anchors.

Примечание: статья была написана в 2019 году, а в этом Microsoft Excel отмечает уже 35-летний юбилей.

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

2015: Я люблю тебя
2016: Я люблю тебя
2017: Я люблю тебя
2018: Я люблю тебя
2019: Я люблю тебя

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

Год в Excel

Как это часто бывает в отношениях, мы с Excel уже были знакомы какое-то время. Но гром грянул только в 2015 году. Я часто шучу, что это был год электронных таблиц настолько много времени я тогда провел за ними.

Я работал бизнес-аналитиком и проводил расчеты для списка Fortune 500. Очень хорошо помню, как в первый рабочий день кто-то сказал мне: обрати внимание, наши опытные сотрудники не притрагиваются к мыши, работая с таблицами. Привычка использовать сочетания ctrl+[клавиша] вошла в их мышечную память. Совсем скоро я стал одним из них.

Ранее мне казалось, что способность построить график тренда по нескольким точкам это чуть ли не вершина мастерства. И только потом я познал настоящую мощь Excel. С его помощью мы строили сложные модели для предсказания чего угодно от цен на нефть до уровня каннибализации в сфере недвижимости. И со всей сложностью и многогранностью нашей работы справлялась одна единственная программа.

Я проработал там 11 месяцев. Думаю, примерно 1500 часов из них я провел только за таблицами. Для сравнения всего за тот период я наработал чуть меньше 6000 часов и это с учетом времени на сон, еду и всякое прочее, не связанное с Excel. Да-да, можете быть уверены, эти подсчеты я тоже произвел с помощью таблицы. Хочу, чтобы вы понимали: я не жалею ни об одной минуте и просто хочу немного порефлексировать.

Сейчас, как только какая-то технология становится неотъемлемой частью нашей жизни, мы тут же бросаемся прославлять её создателей. Новым гаджетам и SaaS-компаниям пророчат, что они изменят ход истории. А венчурные капиталисты тем временем ищут, в кого бы еще вложить свои миллионы. Посмотрите сами: Маск, Цукерберг, Пейдж и Безос стали так же известны, как звезды шоу-бизнеса.

Но мне хотелось бы рассказать вам о Дэниеле Бриклине и Даге Кландере. И о программе, которая была изобретена более 30 лет назад, но до сих пор живет на сотнях миллионов персональных компьютеров. Десятилетия спустя я хочу поговорить об Excel.

Разговор о вездесущем

Excel это один из самых успешных продуктов в истории программного обеспечения. Энди Ли, Partner Software Development Engineer at Excel

Любите вы Excel или нет, глупо спорить с тем, что он уже много лет является жизненно важным инструментом для многих современных компаний. Что касается глубины проникновения на рынок, Microsoft заявляет, что Excel пользуется каждый пятый совершеннолетний человек на земле. Даже несмотря на успехи своих конкурентов (например, Google Sheets), на данный момент актуально около 1,2 миллиардов лицензий на Microsoft Office. И, чтобы вы до конца поняли ситуацию: в 2016 году MS Office заработал 13,8 млрд долларов, а GSuite 1,3 млрд.

Но забавнее всего мы сейчас говорим о ПО, которое было изобретено больше 30 лет назад. И несмотря на кучу обновлений и базу из 476 функций, оригинальная концепция Excel и даже некоторые кусочки оригинального кода дожили до современных релизов к этому мы еще вернемся.

Думаете, там не осталось кода 15-20-30-летней давности? Его там полно! Энди Ли, Partner Software Development Engineer at Excel

Казалось бы, старичку давно пора на покой, но вместо этого он процветает! Поиск по ключевому слову Excel в Udemy выдает около 10000 результатов. Для сравнения, по Javascript находится около 7000 (примечание: сейчас цифры немного изменились, но Excel все равно выигрывает с небольшим перевесом). К тому же один из самых популярных навыков в вакансиях требование знать Excel присутствует в каждой третьей. И если вспомнить суть электронных таблиц и относиться к ним как к самостоятельным программам, получится, что Excel это еще и самая популярная среда разработки в мире.

Microsoft Excel это самое привычное, гибкое и распространенное бизнес-приложение в мире. Это стало возможным благодаря его умению адаптироваться к любому бизнес-процессу. История Microsoft Excel.

Сумасшедшая обратная совместимость (30+ лет!), плавная кривая обучения и практически идеальная внедряемость сделали Excel безоговорочным лидером рынка. Многие компании не могут даже мечтать о таком превосходстве над конкурентами. А еще Excel можно пользоваться прямо из коробки: ни зависимостей, ни настройки. Он просто работает.
И несмотря на то, что со дня появления Excel Microsoft выпустила сотни других приложений, CEO Сатья Наделла считает его экстраординарным явлением:

Представьте себе мир без Excel. Лично я не могу этого сделать. Сатья Наделла

Изменяя ход истории

Вполне можно сказать, что Microsoft Excel внес тектонические изменения как в жизни людей, так и в работу многих компаний. Лично я всё делаю в таблицах. Слежу за своей жизнью, строю списки, планирую расходы и многое другое. Прелесть электронных таблиц состоит как раз в том, что им можно найти десятки различных применений.

Я не знаю, как именно люди работают с Excel потому что его можно использовать огромным количеством разных способов Терренс Хуан, Partner Development Manager at Excel

YouTube-канал Excel is Fun

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

Excel действительно изменил работу многих компаний, упростив процесс построения графиков, принятия решений и выполнения сложных вычислений. Дерек Бёрни, Corp VP Data and BI, VP Data and Business Intelligence

И хотя Excel сам по себе не изобретал формат электронной таблицы об этом мы тоже поговорим чуть позже он стал локомотивом, который сделал динамические вычисления мейнстримом. Цукерберг не изобретал социальные сети, Маск не был первым, кто предложил устраивать частные полеты в космос. Их заслуга в том, что они взяли эти идеи и раздвинули их до неизведанных границ, точно так же как Excel смог принести в большой мир концепцию электронных таблиц.

Появление MS Excel определило эпоху он создал тысячи стартапов и стимулировал миллионы увольнений. Благодаря этой программе появлялись совершенно новые отрасли промышленности. Только посмотрите, какое количество новых должностей появилось в мире бизнес-аналитики даже та, на которой я проработал большую часть 2015-го. Этих профессий не существовало, пока Excel не подарил нам возможность обрабатывать и визуализировать данные играть в что будет, если.

На серверах корпораций и организаций хранится много различных данных. Необходимо иметь возможность просматривать эти данные, изменять их, анализировать разными способами, чтобы в конечном итоге получить пользу. Excel играет огромную роль в мире бизнес-аналитики, потому что это программа для людей. Они её по-настоящему понимают. Дерек Бёрни, Corp VP Data and BI, VP Data and Business Intelligence

Целые компании выстроены на могучих плечах Excel. А там, где Excel не является жизненно необходимым компонентом, он просто важен и нужен. Но невероятнее всего то, что в 2019 году находятся компании, чьим главным конкурентом является Excel.



Появляется куча новых технологий. Компании зарабатывают на них миллионы, однако люди все еще тянутся к Excel. По данным Gartner от 2015 года, более половины IT-компаний полностью или преимущественно пользуются электронными таблицами для аналитики. Это доказывает, что [по крайней мере, тогда] Excel де-факто конкурирует с целой индустрией анализа данных, но при этом не ограничивает своих пользователей только одной сферой применения. Можно строить списки задач, вести учет тренировок, записывать покупки Excel использовался своими собственными разработчиками для того, чтобы составить список гостей 30-летнего юбилея программы.

Таблицы используются для всего, от легковесных баз данных до личных расписаний. От сбора информации до её анализа. Даже для сложных бизнес-процессов. Это только основные примеры, далеко не полный список того, для чего используются электронные таблицы. Хьялмар Гисласон

Представим себе мир без Excel

Я как-то летел на самолете и разговорился с попутчиком. Внезапно он схватил меня за футболку: Так ты работаешь в Excel? Я без ума от Excel! Джон ДеВаан, [ex] Sr. VP Windows Development

Люди вроде меня не просто работают в Excel. Они его действительн любят. Когда я собирал материалы для этой статьи, мне не давал покоя один вопрос: а чем бы мы пользовались, если бы Excel взял и исчез?

Конечно, базовым его функциям можно найти замену. Но что делать с его эксклюзивными возможностями, альтернатив которым запросто может не найтись? Мне правда интересно, сколько компаний по всему миру будут вынуждены сделать паузу, если одним прекрасным утром Наделла проснется и решит зарезать Excel. Сколько компаний не смогут нормально работать?

Существуют финансовые компании, которые используют Excel для обработки огромных объемов данных. Они проводят в нем симуляции, чтобы предсказать события в мире. Они не просто используют Excel в качестве инструмента для написания формул. Они фактически строят собственные решения поверх Excel. И многие из этих надстроек работают уже 10-15 лет. Терренс Хуан, Partner Development Manager at Excel

Когда Хайтен Ша спросил у пользователей Twitter, без какого приложения или продукта они не смогут жить, старина Excel на голову опередил по количеству лайков стильный молодняк вроде Zoom, Slack, Notion, 1Pass и Webflow.

История Excel

34 года волшебства

История Excel мне нравится ничуть не меньше, чем сам продукт. Если вернуться на 34 года назад, окажется, что весь мир с тех пор сильно изменился. Но только не фундаментальные принципы этой программы.

Прежде чем вы начнете кидать в меня тапками, я хочу сказать: компания Microsoft НЕ изобретала электронные таблицы. А кто же тогда это сделал? Скажем за них спасибо Дэну Бриклину и Бобу Фрэнкстону.

Дэна часто называют отцом электронных таблиц. Именно он вместе с Бобом Фрэнкстоном в 1979 году разработал первое подобное приложение: VisiCalc Visible Calculator. Дэн первым привнес концепцию таблицы-сетки, которая до сих пор в неизменном виде присутствует во всех подобных приложениях. Если же забить в Google Кто сделал Excel?, вы увидите имя Дэна, хотя он ни дня не работал на Microsoft.

Я представлял себе волшебную школьную доску, на которой, если стереть одно число и вписать другое, все пересчитается само собой. Дэн Бриклин, TEDxBeaconStreet 2016

Изобретение электронных таблиц дало толчок всей индустрии персональных компьютеров. Стив Джобс однажды говорил, что именно VisiCalcу Apple II обязан своим успехом.

На самом деле, было два реальных взрыва, которые толкнули вперед всю индустрию. Первый произошел в 1977, и это были электронные таблицы Стив Джобс

Это стало началом WYSIWYG, хотя мы давно привыкли принимать это как должное. Работа Бриклина и Фрэнкстона была замечена другой компанией, Lotus Software, которая в дальнейшем была куплена IBM. Новый продукт, основанный на идее VisiCalc, получил название Lotus 1-2-3 и вышел на рынок в 1983-м.

В то же самое время Microsoft уже разрабатывали предшественника Excel, программу Multiplan (под кодовым названием Electronic Paper). Ей пришлось как следует побороться с Lotus 1-2-3 за место на рынке. Джон ДеВаан, один из разработчиков Excel 1.0, вспоминал, что в 1984 году рынок электронных таблиц был на 100% занят Lotus 1-2-3, работавшим под MS-DOS.

Пересчитывай или умри

Microsoft решила вложиться в разработку нового продукта под кодовым именем Odyssey. Зная современное положение Microsoft, сложно представить себе её в роли аутсайдера, чей проект имел все шансы на провал. Команда, разрабатывавшая Excel, состояла всего из четырех человек: Майк Косс, Джейб Блюменталь, Даг Кландер и Джон ДеВаан. Также в команду входили Стив Хазлериг, Эд Рингнесс, Чарльз Симони и Джон Хоппер. Чтобы еще лучше понять дух той эпохи, подумайте вот о чем: с момента создания Microsoft Mouse прошло всего два года.

Поскольку (какая ирония!) Lotus 1-2-3 переиграл Microsoft на их же собственном поле MS-DOS, скрепя сердце, Microsoft решила разрабатывать продукт для Mac. Там Lotusа еще не было, а сама платформа обладала необходимыми мощностями. Решение было не из легких. Когда оно было окончательно принято, из команды ушел Даг Кландер.

Представьте себе: единственный человек, который имеет полное представление об одном из компонентов продукта, просто уходит. Ради того, чтобы работать на ферме [...]. Джейб Блюменталь

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

К счастью для нас всех, вскоре Даг одумался и вернулся со скудных салатных полей обратно в офис, чтобы создать один из самых важных компонентов Excel 1.0. Даг часто говорит Excel как о своем дитя. По его подсчетам, он устроился в Microsoft где-то в промежутке между 45-м и 65-м сотрудником.

Я буквально жил в офисе, спал пару часов и сразу же возвращался за код. Помню, как сильно по ночам дуло из окна в офисе Даг Кландер

Возможно, одной из самых важных вещей в Excel 1.0 была возможность автоматического пересчета значений. Именно её и разработал Кландер. Неофициальным девизом команды после того, как Кландер внедрил свой умный пересчет стала фраза пересчитывай или умри. Вместо того, чтобы после каждого изменения заново считать весь лист, алгоритм Кландера затрагивал только нужные ячейки. В те времена это круто увеличило производительность, и продукт Microsoft на голову опередил конкурентов.

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

Excel 1.0 вышел 30 сентября 1985 года и с первого дня стал лидером рынка. В последующие годы Excel привнес в мир электронных таблиц еще много прорывных нововведений: возможность настраивать внешний вид таблицы, автозамену и интеллектуальное копирование ячеек.

Несмотря на то, что название Excel сейчас кажется нам идеальным, были и другие варианты: например, Master Plan и Mr. Spreadsheet. Можете себе представить оду Мистеру Табличкину?

Не забывайте: это были времена, когда Microsoft еще не вышла на IPO, и ко многим продуктам лично прикладывал руку Билл Гейтс. Я думаю, что Excel стал лидером во многом благодаря командному духу и идеалам, которых придерживались Билл и разработчики Excel. Например, Кландер говорит, что идею умного пересчета ему подал сам Билл. Гейтс возражает и утверждает, что Кландер сделал вовсе не то, что он имел в виду.

Билл Гейтс был великолепным технарем. Он понимал Variants и COM-объекты, и IDispatch, и чем Automation отличается от vtables, и почему это могло привести к двойному интерфейсу. Он беспокоился о функциях для работы с датами. Он не вмешивался в разработку, если доверял тем, кто пишет программу. Но провести его не было никакой возможности: он был программист. Настоящий, реальный программист. My First BillG Review

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


Microsoft Excel 1.5 для Mac (1985)

Когда задумываешься о долгожительстве Excel, дух захватывает. У нас было ощущение, что мы делаем нечто очень нужное и полезное. Вероятно, поэтому Excel до сих пор живет и развивается. Джон ДеВаан, [ex] Sr. VP Windows Development

Конечно, много функций с тех пор добавилось. Но основа, сам принцип электронной таблицы, остался неизменным. И я все еще пользуюсь таблицами, которые я сделал 25-30 лет назад. Даг Кландер

Кто на новенького?

В эпоху, когда софт пожирает мир, мы должны спросить у себя: чему может научить нас история Excel? Я не могу выразить этой статьей ни силу своей любви к Excel, ни сколько денег Microsoft на нем зарабатывает. Но я смог показать, как сильно электронные таблицы влияют на доступ к информации.

На тот момент это действительно было очень важно: делать программы, понятные обычным пользователям, а не докторские диссертации с пользовательским интерфейсом. Джон ДеВаан, [ex] Sr. VP Windows Development

Концепция простого доступа [к чему либо, в т.ч., к информации] часто воспринимается пользователями как нечто обыкновенное. На самом деле ученые и программисты взращивали её десятилетиями. Да, Excel не был первопроходцем электронных таблиц. Но не нужно быть пионером, чтобы построить для всех мостик доступности, который снимет с пользователей ограничения. В идеале техническим путем, как Кландер, научивший даже маломощные компьютеры производить сложные вычисления.
Чтобы вы лучше понимали меня, приведу несколько современных примеров.

• Компании вроде Webflow WordPress или Squarespace существенно упрощают создание сайтов.
• Ghost, с помощью которого был создан этот сайт [блог автора статьи], позволяет в считанные минуты развернуть отличный блог.
• Stripe дает продавцам-частникам возможность работать онлайн, точно так же, как Shopify позволяет любому человеку, даже в возрасте, легко начать бизнес в eCommerce.

Эти инструменты уже получили свою порцию славы в современном мире благодаря новым возможностям, которые они открывают. Без них только небольшая горстка избранных могла бы выйти на этот рынок. Теперь он доступен всему миру.

В разгар революции под девизом без кода Excel можно рассматривать в качестве отличного примера с похожей концепцией: построить мост доступности к чему-то ценному. Закономерно возникают вопросы. А что прямо сейчас находится в области, доступной только нескольким экспертам? Что может принести пользу более широкой аудитории? И что можно создать для этих людей? Это наша работа увидеть что-то ценное, но недоступное для большинства людей, и сделать его доступным. Живи долго и процветай, Excel!

Примечание: к оригинальной статье есть комментарий от читателя с несколько иной точкой зрения, и мы не могли его проигнорировать.

Билл Джелен: Спасибо за публикацию отличной статьи, но Excel не победил 30 сентября 1985. Он был процентов на 400 медленнее Lotus 1-2-3, и всё это вылилось в тяжелую борьбу (у обоих продуктов были крутые новые фичи), продолжавшуюся до 1995 года.