Длина входной цепочки равна размеру памяти и регистров
И сколько вариантов входных цепочек (язык прям тянет назвать это «состояниями») имеет система ну вот как мой десктоп, с 128 гигабайтами оперативки и 10 терабайтами хардов, даже если забыть про интернет?
при этом все правила грамматики очень локальны
Почему? Правила грамматики — это и есть ваша программа, размер которой равен размеру памяти.
их вполне можно расписать, используя какие-нибудь многоточия вместо неизменной части памяти, как в математике.
А откуда взялась неизменная часть памяти? Кто-то запретил менять хотя бы один из битов вашего компьютера? Естественно, я не говорю о каком-нибудь EEPROM и прочей технической скуке — можете считать, что у меня 127 гигабайт, а не 128.
И это очень важно, потому что в мТ
Так мы обсуждаем мТ или якобы на практике отличающийся от неё в сторону ослабления компьютер?
есть такая семантичная вещь, как исполнительное устройство, которое обращается с лентой по определенным операционным правилам. А в грамматике вообще никакой семантики нет
Грамматика — это почти такой же набор правил для некоторого исполнительного устройства. Собсна, самый широкий класс грамматик по Хомскому (как они там, рекурсивно перечислимые?) распознаются именно машиной Тьюринга, и это точная граница сложности, потому что ими можно описать язык из останавливающихся машин Тьюринга. Следовательно, грамматики в этом смысле неразрешимы. Следовательно, толку с них снова ноль.
но его в вузе не преподают
Скукоживается, скукоживается вузовский кругозор прямо на глазах!
Я успел обновить свой комментарий в ответ на обновление вашего комментария!
Процессор правильнее считать бесконечным и неразрешимым, потому что формальная разрешимость из-за практической конечности числа его состояний (и фундаментальных квантовых пределов на скорость вычислений, мощность и хранилище в данном объёме, и прочие подобные вещи — кстати, вам про них рассказывали? нам нет, откуда я про них знаю?) никак не влияет на практическую разрешимость. Для всех практических применений он неотличим от абстрактной бесконечной неограниченной машины Тьюринга.
Вы, конечно, можете поиграться с определениями и засунуть в грамматику вообще всё, но она станет либо бесконечной, либо неразрешимой, либо оба. И зачем вам такая грамматика?
Конечная, просто очень большая.
Настолько же, насколько машины Тьюринга эквивалентны конечным грамматикам (что бы это ни значило — я не вижу смысла настолько растягивать термины, потому что они теряют описательную силу).
Но грамматики недостаточно ни для (мета)описания поведения программы, ни для выражения свойств программы. Смысл на ней фокусироваться, если её недостаточно на практике?
Вы, конечно, можете поиграться с определениями и засунуть в грамматику вообще всё, но она станет либо бесконечной, либо неразрешимой, либо оба. И зачем вам такая грамматика?
Прямо применимо к фреймворкам без правок высказывания.
не зависимо от предпочитаемых фреймворков
не зависимо от предпочитаемых предметных областей (порядок чего-нибудь в этом вашем спринге не зависит от того, пишете вы сайт банка, блокчейна или гостевую книгу).
Но кто то сидит на вершине, типа фронта и не понимает, зачем ваще в ИТ математика )
Я писал компиляторы, писал тайпчекеры, формально всё это верифицировал, и всё равно не понимаю, зачем в 99% вакансий в ИТ математика. И, более того, никогда не говорю всерьёз, что среднему программисту на самом деле нужна теория типов, теория категорий, матлог, и прочее (даже несмотря на то, что это было нужно мне, и, кстати, в вузе не давалось).
А что там AES и прочие кирпичики — зонную теорию проводимости ведь тоже надо знать программисту, да?
Просто ассоциативный доступ в таких задачах не используется.
Да? У вас есть 100500 действующих ордеров, идентифицируемых по uint32 orderId. Научите вытаскивать параметры ордера по данному orderId, пожалуйста, без ассоциативного доступа?
Я воспитан в понятиях
QED.
что алгоритмы и структуры данных составляют единое целое (у Вирта, помнится, даже книжка такая была) и выражают операционную семантику.
Фокус на операционной семантике напрочь ломает модульное программирование. Какая мне разница, в какой конкретно код собирается данный модуль, покуда он имеет устраивающие меня характеристики?
Я вот лично поклонник бестипового исчисления.
А это неважно, мы ж кругозор обсуждаем.
Типизация имеет свои плюсы, но она замусоривает голову на самом глубинном уровне мнимым различием кода и данных.
Я лично про фундаментальные знания ничего не говорил.
Про них всегда говорится в таких тредах, и мысль о необходимости фундаменталки (и вуза как дающего эту фундаменталку) идёт лейтмотивом через все такие треды.
А обучение инженера заключается в обзоре, систематизации и позиционировании конкретных практик.
…которые на самом деле устаревают достаточно быстро.
Окей, оккам и транспьютеры. Надо ли в вузах на программиста учить cmake? bazel? git? figma?
Но это мелочи. Нужно ли учить perforce? actionscript? silverlight? coldfusion? Я не вижу, чем это бы отличалось от оккама или сборки транспьютеров, и в своё время это было даже популярнее и нужнее, но сейчас где этот сильверлайт и экшнскрипт вообще.
В МФТИ была какая-нибудь другая фишка.
Ноль (зеро, зильч) релевантных работе фишек.
Окей, бакалавр. Что там было хотя бы минимально затрагивающего компьютер? Было четыре семестра программирования (семак плюсов, семак асма, и ещё два семестра не помню чего). Я на них не ходил, потому что задолбал преподшу на первом же занятии указаниями на ошибки на слайде, и она мне дала задание и, мол, чтоб до конца семестра меня не видела (задание очень сложное — отсортировать числа в квадратной матрице std::vector<std::vector<int>>змейкой, как я справился только?). На всех семестрах у меня был отл, и на том же ассемблере спокойно помогал всем, кому надо было, из всех групп на моём курсе.
Был семак параллельного программирования. Мы, кажется, научились умножать матрицы друг на друга через mpi. Только про mpi, openmp и прочие я и до вуза знал, и больше знал, чем нам дали, и вообще.
Был семак баз данных. Учились писать сложные запросы на SQL. Но и про SQL я знал до этого, и приходил на сдачу заданий без какого-либо чтения официальных учебников/методичек/гайдов, и лекции не посещал, и сдавал на отл, включая вопросы по теории.
Был семак сетевых технологий. Я лично знал препа и он мне сказал, что мне туда ходить не надо, и поставил зачёт автоматом.
Был семак прикладного статистического анализа (я на кафедре машинного обучения был). Мы просто учились работать с R, и, сюрприз, я знал про R и до этого курса, и напрочь забыл R вскоре после этого курса, потому что им не пользовался, а синтаксис у него наркоманский.
На других предметах по машинке мы тоже использовали компьютеры (иногда), и там я, наверное, максимум научился матлабу. Знаете, сколько раз я с тех пор использовал матлаб? Ноль. Даже когда работал в машинном обучении.
В магистратуре было аналогично.
Мне вот, например, алгоритм Брезенхема и прочая машинная графика совершенно не пригодились (пока), а для кого-то это очень важно. Но я по крайней мере о нём знаю.
Вы не сможете засунуть в вуз объединение всех когда-либо кому-либо необходимых знаний. Не влезет.
Ну, допустим, я скажу, что в моих задачах 10 лукапов в секунду. Это как-то меняет дело?
Да, это адово мало. В моих задачах миллиарды лукапов в день (можете посмотреть, сколько там сообщений в день на каком-нибудь NYSE, мне лень), поэтому, склонен считать, у меня есть некоторый опыт работы с системами, где перф на самом деле важен.
Я замечу, что если у вас производительность упирается в лукапы хешмапа, то вы, скорее всего, неправильно выбрали структуру данных: мап вам, возможно, и нужен, а хеш – нет.
Почему?
На интерфейс вообще должно быть плевать. Не нравится заданный – напишите свой враппер. Важна логика.
Интерфейс и выражает логику.
Утверждаю, что хэшмапа — это любой тип, для которого реализуем
interface HashMap hm where
type K
type V
insert : K → V → hm → hm
lookup : K → hm → Maybe V
delete : K → hm → hm
плюс законы вроде (почти дословный идрис или агда):
∀ k v hm. lookup k (insert k v hm) ≡ Just v
∀ k hm. lookup k (delete k hm) ≡ Nothing
∀ k₁ k₂. k₁ ≠ k₂ → lookup k₁ (insert k₂ v hm) ≡ lookup k₁ hm
плюс требования по сложности операций, для которых нет общепринятого формального синтаксиса, поэтому я их просто упомяну.
Врапперы тут ни при чём.
Кстати, про сабтайпинг нам действительно не рассказывали, а уж тем более про него как отношение.
И снова широта образования пошла. Действительно, зачем программисту нужны основы теории типов? Лучше заставить людей зазубрить, что хэшмапы — это обязательно list-based collision resolution, и дать попрограммировать на конкретном языке под конкретную железку.
Однако, во-первых, маловероятно самостоятельно заинтересоваться такой вещью.
Почему? Особенно если она плюс-минус связана с вашей прямой работой, поэтому предположительно вы о ней узнаете, просто сёрфая интернет в окрестности ваших рабочих задач?
А во-вторых, что ещё важнее, даже прочтение книжки по языку Оккам не даст практики программирования транспьютера
Ну так правильно, надо не просто книжки читать, надо ещё с ними играться. И в свободное время в свободном режиме это делать проще.
Я к тому говорю, что институт в принудительном порядке даёт широкую базу, из которой заранее непонятно, что именно затем выстрелит.
Широта особенно хорошо заметна в соседнем треде о хэшмапах. Догмат на догмате, на самом деле. Кстати, у вас была философия науки в вузе? Навевает вам это всё воспоминания о куновском концепте парадигм и школ?
Впрочем, это я так, мысли вслух. Интереснее другое: например, у нас в вузе слово «транспьютер» не звучало вообще ни разу. Выходит, МФТИ — плохой вуз?
Кроме того, транспьютер — это фундаментальные знания? Практикум по работе с ними — это то, что понимают под «фундаментальным образованием», которое всем необходимо?
Да, и я не вижу ничего странного в том, что в попадавшихся мне задачах нет разницы между 1 и 30 операциями.
В ваших задачах один лукап на всё время жизни программы?
Для меня хешмап – это конкретное представление структуры данных в памяти.
То есть, open addressing и прочие cuckoo hashing как механизм разрешения коллизий — уже не хэшмапы? Ну это уже видимо вершины высшего образования, мне недоступные (альтернатива: вставьте не-шутку про догматизм сами).
А интерфейс в этом вопросе – дело десятое
Интерфейс — это всё что важно, просто потому что объекты мы определяем по тому, как с ними можно работать.
(кстати, в каком-нибудь джаваскрипте хешмап может иметь интерфейс массива).
Вам в вузе что-нибудь рассказывали про отношение сабтайпинга? Или в жс хэшмапы имеют только интерфейс массива?
Я в институте в курсе параллельных вычислений учился программировать транспьютер. А потом на работе спроектировал другой транспьютер, зная о такой возможности из институтского курса.
Узнавать о вещах кроме как из институтского курса невозможно?
И у нас такого не было, с одной стороны. С другой — почти всё, что я знаю о параллельных вычислениях (и о низкоуровневой оптимизации, и тому подобному), я получил вне вуза и в каком-то смысле вопреки вузу (потому что приходилось выбирать — поспать 7 часов вместо 4-5, или пописать ещё кода для себя).
В итоге мы приходим к ситуации, когда вуз — это как настоящий шотландец. Кому не нужно, он просто учился в неправильных вузах не на те специальности, и фундаментальные знания нужны, но не эти и не те и не в таком объёме, и…
то есть так, как они реализованы в базовых библиотеках большинства современных языков программирования
Это, к слову, не эквивалентные вещи, и второе из первого не следует. Хэшмапа — это структура с определённым интерфейсом и, если хотите, гарантиями сложности. Всё.
Если я вместо std::unordered_map возьму что-нибудь с open addressing в одном массиве, то я не перестану «пользоваться хэшмапами».
приводит к значительным потерям памяти
И? В куче случае перф важнее памяти.
Я не предлагал голый массив как альтернативу хешмапу.
То есть, у вас на практике была сборка транспьютера, но вы говорите, что никакая практика не дала бы вам такой опыт? Вам не кажется, что это, ну, несколько внутренне противоречиво?
И, кстати,
главным конструктором
программист
Ну давайте ещё врачей позовём, спросим у них, что нужно знать программисту, потому что им пригождалось в их врачебной практике.
Это другой вопрос. Я потому и говорю, что в каждом случае нужно решать отдельно.
Нет, вы говорите не только это. Вы говорите, что хэшмапы требуют значимо больше памяти (это не так — не все хэшмапы требуют), и что асимптотическая выгода от них не достигается в вашей многодесятилетней практике (формально нельзя сказать «не так», но это необобщаемый случай).
Чем надо заниматься, чтобы ни разу не уткнуться в большую скорость хэшмап по сравнению с массивами, но зато собирать транспьютеры, я не понимаю, и не уверен, что ваш опыт применим к 99% программистов.
В управлении роботами ещё топология полезна: https://arxiv.org/abs/1707.03899 . Вон, уже в абстракте фибрации попёрли, почти теоркат, обязательно это всё надо спрашивать, ящетаю.
В реальном мире у меня стоят знаки «no parking» там, где парковаться не нужно, бордюры выкрашены красным там, где парковаться не нужно по пожарным причинам, и так далее.
А мы и теорию схем программ проходили, и транспьютер, например, программировали. Хрен бы какая коммерческая практика дала такой опыт.
И как, пригодилось на практике?
Мне бы не пригодилось. А многое из того, что я проходил в личное время — да, пригождалось.
Вы в курсе, что есть хэшмапы, где все данные хранятся в одном массиве, а не по бакетам как в «классическом» случае (кстати, нам это не рассказывали), а в нашей с вами любимой функциональной среде вообще поддерживать упорядоченный массив куда дороже, чем какой-нибудь HAMT (не рассказывали).
в смысле времени выполнения не обгонит до практически значимых величин никогда
Я встречался со случаями, где даже отстойный плюсовый unordered_map (бакеты и это всё ⇒ тормоза) очень быстро начинал обгонять обычный массив с бинарным поиском, и это было на вполне продуктовых наборах данных.
И сколько вариантов входных цепочек (язык прям тянет назвать это «состояниями») имеет система ну вот как мой десктоп, с 128 гигабайтами оперативки и 10 терабайтами хардов, даже если забыть про интернет?
Почему? Правила грамматики — это и есть ваша программа, размер которой равен размеру памяти.
А откуда взялась неизменная часть памяти? Кто-то запретил менять хотя бы один из битов вашего компьютера? Естественно, я не говорю о каком-нибудь EEPROM и прочей технической скуке — можете считать, что у меня 127 гигабайт, а не 128.
Так мы обсуждаем мТ или якобы на практике отличающийся от неё в сторону ослабления компьютер?
Грамматика — это почти такой же набор правил для некоторого исполнительного устройства. Собсна, самый широкий класс грамматик по Хомскому (как они там, рекурсивно перечислимые?) распознаются именно машиной Тьюринга, и это точная граница сложности, потому что ими можно описать язык из останавливающихся машин Тьюринга. Следовательно, грамматики в этом смысле неразрешимы. Следовательно, толку с них снова ноль.
Скукоживается, скукоживается вузовский кругозор прямо на глазах!
Например?
Я успел обновить свой комментарий в ответ на обновление вашего комментария!
Процессор правильнее считать бесконечным и неразрешимым, потому что формальная разрешимость из-за практической конечности числа его состояний (и фундаментальных квантовых пределов на скорость вычислений, мощность и хранилище в данном объёме, и прочие подобные вещи — кстати, вам про них рассказывали? нам нет, откуда я про них знаю?) никак не влияет на практическую разрешимость. Для всех практических применений он неотличим от абстрактной бесконечной неограниченной машины Тьюринга.
А, окей, это второй случай. Повторю его ещё раз:
Настолько же, насколько машины Тьюринга эквивалентны конечным грамматикам (что бы это ни значило — я не вижу смысла настолько растягивать термины, потому что они теряют описательную силу).
Но грамматики недостаточно ни для (мета)описания поведения программы, ни для выражения свойств программы. Смысл на ней фокусироваться, если её недостаточно на практике?
Вы, конечно, можете поиграться с определениями и засунуть в грамматику вообще всё, но она станет либо бесконечной, либо неразрешимой, либо оба. И зачем вам такая грамматика?
Прямо применимо к фреймворкам без правок высказывания.
не зависимо от предпочитаемых предметных областей (порядок чего-нибудь в этом вашем спринге не зависит от того, пишете вы сайт банка, блокчейна или гостевую книгу).
Я писал компиляторы, писал тайпчекеры, формально всё это верифицировал, и всё равно не понимаю, зачем в 99% вакансий в ИТ математика. И, более того, никогда не говорю всерьёз, что среднему программисту на самом деле нужна теория типов, теория категорий, матлог, и прочее (даже несмотря на то, что это было нужно мне, и, кстати, в вузе не давалось).
А что там AES и прочие кирпичики — зонную теорию проводимости ведь тоже надо знать программисту, да?
Слишком медленно. Будет использоваться in-memory-структура с учётом особенностей задачи.
Это, к сожалению, не проверяемая компилятором часть интерфейса.
Можете развернуть мысль, пожалуйста? Вот у меня есть CoC, там есть где-то шесть правил вывода типов. Можете сказать, о каком различии речь?
Формальные грамматики и у нас были, но
они меня не испортилине понимаю, как они могли на что-то повлиять.Да? У вас есть 100500 действующих ордеров, идентифицируемых по uint32 orderId. Научите вытаскивать параметры ордера по данному orderId, пожалуйста, без ассоциативного доступа?
QED.
Фокус на операционной семантике напрочь ломает модульное программирование. Какая мне разница, в какой конкретно код собирается данный модуль, покуда он имеет устраивающие меня характеристики?
А это неважно, мы ж кругозор обсуждаем.
Где там это различие возникает?
fixтипизируем.Про них всегда говорится в таких тредах, и мысль о необходимости фундаменталки (и вуза как дающего эту фундаменталку) идёт лейтмотивом через все такие треды.
…которые на самом деле устаревают достаточно быстро.
Окей, оккам и транспьютеры. Надо ли в вузах на программиста учить cmake? bazel? git? figma?
Но это мелочи. Нужно ли учить perforce? actionscript? silverlight? coldfusion? Я не вижу, чем это бы отличалось от оккама или сборки транспьютеров, и в своё время это было даже популярнее и нужнее, но сейчас где этот сильверлайт и экшнскрипт вообще.
Ноль (зеро, зильч) релевантных работе фишек.
Окей, бакалавр. Что там было хотя бы минимально затрагивающего компьютер? Было четыре семестра программирования (семак плюсов, семак асма, и ещё два семестра не помню чего). Я на них не ходил, потому что задолбал преподшу на первом же занятии указаниями на ошибки на слайде, и она мне дала задание и, мол, чтоб до конца семестра меня не видела (задание очень сложное — отсортировать числа в квадратной матрице
std::vector<std::vector<int>>змейкой, как я справился только?). На всех семестрах у меня был отл, и на том же ассемблере спокойно помогал всем, кому надо было, из всех групп на моём курсе.Был семак параллельного программирования. Мы, кажется, научились умножать матрицы друг на друга через mpi. Только про mpi, openmp и прочие я и до вуза знал, и больше знал, чем нам дали, и вообще.
Был семак баз данных. Учились писать сложные запросы на SQL. Но и про SQL я знал до этого, и приходил на сдачу заданий без какого-либо чтения официальных учебников/методичек/гайдов, и лекции не посещал, и сдавал на отл, включая вопросы по теории.
Был семак сетевых технологий. Я лично знал препа и он мне сказал, что мне туда ходить не надо, и поставил зачёт автоматом.
Был семак прикладного статистического анализа (я на кафедре машинного обучения был). Мы просто учились работать с R, и, сюрприз, я знал про R и до этого курса, и напрочь забыл R вскоре после этого курса, потому что им не пользовался, а синтаксис у него наркоманский.
На других предметах по машинке мы тоже использовали компьютеры (иногда), и там я, наверное, максимум научился матлабу. Знаете, сколько раз я с тех пор использовал матлаб? Ноль. Даже когда работал в машинном обучении.
В магистратуре было аналогично.
Вы не сможете засунуть в вуз объединение всех когда-либо кому-либо необходимых знаний. Не влезет.
Да, это адово мало. В моих задачах миллиарды лукапов в день (можете посмотреть, сколько там сообщений в день на каком-нибудь NYSE, мне лень), поэтому, склонен считать, у меня есть некоторый опыт работы с системами, где перф на самом деле важен.
Почему?
Интерфейс и выражает логику.
Утверждаю, что хэшмапа — это любой тип, для которого реализуем
плюс законы вроде (почти дословный идрис или агда):
плюс требования по сложности операций, для которых нет общепринятого формального синтаксиса, поэтому я их просто упомяну.
Врапперы тут ни при чём.
И снова широта образования пошла. Действительно, зачем программисту нужны основы теории типов? Лучше заставить людей зазубрить, что хэшмапы — это обязательно list-based collision resolution, и дать попрограммировать на конкретном языке под конкретную железку.
Это уровень ПТУ, а не высшего учебного заведения.
Почему? Особенно если она плюс-минус связана с вашей прямой работой, поэтому предположительно вы о ней узнаете, просто сёрфая интернет в окрестности ваших рабочих задач?
Ну так правильно, надо не просто книжки читать, надо ещё с ними играться. И в свободное время в свободном режиме это делать проще.
Широта особенно хорошо заметна в соседнем треде о хэшмапах. Догмат на догмате, на самом деле. Кстати, у вас была философия науки в вузе? Навевает вам это всё воспоминания о куновском концепте парадигм и школ?
Впрочем, это я так, мысли вслух. Интереснее другое: например, у нас в вузе слово «транспьютер» не звучало вообще ни разу. Выходит, МФТИ — плохой вуз?
Кроме того, транспьютер — это фундаментальные знания? Практикум по работе с ними — это то, что понимают под «фундаментальным образованием», которое всем необходимо?
В ваших задачах один лукап на всё время жизни программы?
То есть, open addressing и прочие cuckoo hashing как механизм разрешения коллизий — уже не хэшмапы? Ну это уже видимо вершины высшего образования, мне недоступные (альтернатива: вставьте не-шутку про догматизм сами).
Интерфейс — это всё что важно, просто потому что объекты мы определяем по тому, как с ними можно работать.
Вам в вузе что-нибудь рассказывали про отношение сабтайпинга? Или в жс хэшмапы имеют только интерфейс массива?
Узнавать о вещах кроме как из институтского курса невозможно?
И у нас такого не было, с одной стороны. С другой — почти всё, что я знаю о параллельных вычислениях (и о низкоуровневой оптимизации, и тому подобному), я получил вне вуза и в каком-то смысле вопреки вузу (потому что приходилось выбирать — поспать 7 часов вместо 4-5, или пописать ещё кода для себя).
В итоге мы приходим к ситуации, когда вуз — это как настоящий шотландец. Кому не нужно, он просто учился в неправильных вузах не на те специальности, и фундаментальные знания нужны, но не эти и не те и не в таком объёме, и…
Это, к слову, не эквивалентные вещи, и второе из первого не следует. Хэшмапа — это структура с определённым интерфейсом и, если хотите, гарантиями сложности. Всё.
Если я вместо
std::unordered_mapвозьму что-нибудь с open addressing в одном массиве, то я не перестану «пользоваться хэшмапами».И? В куче случае перф важнее памяти.
Вы говорили о голом отсортированном массиве.
То есть, у вас на практике была сборка транспьютера, но вы говорите, что никакая практика не дала бы вам такой опыт? Вам не кажется, что это, ну, несколько внутренне противоречиво?
И, кстати,
Ну давайте ещё врачей позовём, спросим у них, что нужно знать программисту, потому что им пригождалось в их врачебной практике.
Нет, вы говорите не только это. Вы говорите, что хэшмапы требуют значимо больше памяти (это не так — не все хэшмапы требуют), и что асимптотическая выгода от них не достигается в вашей многодесятилетней практике (формально нельзя сказать «не так», но это необобщаемый случай).
Чем надо заниматься, чтобы ни разу не уткнуться в большую скорость хэшмап по сравнению с массивами, но зато собирать транспьютеры, я не понимаю, и не уверен, что ваш опыт применим к 99% программистов.
Себе по фану или по рабочему проекту?
А теории по факту и нет, к слову, особенно в формате сдачи ПДД в РФ.
В управлении роботами ещё топология полезна: https://arxiv.org/abs/1707.03899 . Вон, уже в абстракте фибрации попёрли, почти теоркат, обязательно это всё надо спрашивать, ящетаю.
В реальном мире у меня стоят знаки «no parking» там, где парковаться не нужно, бордюры выкрашены красным там, где парковаться не нужно по пожарным причинам, и так далее.
И как, пригодилось на практике?
Мне бы не пригодилось. А многое из того, что я проходил в личное время — да, пригождалось.
Вы в курсе, что есть хэшмапы, где все данные хранятся в одном массиве, а не по бакетам как в «классическом» случае (кстати, нам это не рассказывали), а в нашей с вами любимой функциональной среде вообще поддерживать упорядоченный массив куда дороже, чем какой-нибудь HAMT (не рассказывали).
Я встречался со случаями, где даже отстойный плюсовый
unordered_map(бакеты и это всё ⇒ тормоза) очень быстро начинал обгонять обычный массив с бинарным поиском, и это было на вполне продуктовых наборах данных.