Обсуждение

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

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

Да, как примат должен отметить, что квантовые алгоритмы нетривиальны даже для прикладных математиков. А как читатель АБС (того же Понедельника) могу предположить, что к таким вещам большинству - в самом деле реально просто привыкнуть, как к факту существования бытовой техники, нежели понять.

Должен разочаровать: коммерческие (не бета) квантовые сервисы уже доступны с машинами нескольких разных фирм, а удвоение объема кубитов идёт по факту ежегодно. Оптических вычислителей тоже несколько, разных архитектур. Я время от времени об этом пишу. Цель курса в том числе сказать, что всё это уже есть, это настоящее, а не будущее.

Не только математические модели. Любые информационные модели (дальше можно долго рассуждать, являются ли любые модели математическими просто в силу того, что они модели).

Для кодеров - беда. Не оптика, разумеется. Кванты. Тут и обладателям научных степеней впору по второму кругу учиться идти... по программе, которая будет готова лет через двадцать-тридцать... Не тем "кодерам", что вызывают готовые процедуры, разумеется. Тем, кто их пишет. Оптика - всяко проще. Там имеются очевидные решения. Задачи - как всегда - сводятся к уже решённым. Вроде как "если оптический канал связи принципиально невозможно вскрыть незаметно (и тут - кванты проклятые), то нужно просто подчинить комп на любом конце этого канала связи - и получить всё, что можно было бы перехватить из этого канала... и много чего сверх". Кванты... один коллега - лет десять назад описывал вычислительный процесс, основанный на машине времени. Как фантастическую, а не прикладную идею, слава богам. Не удивлюсь, если квантовые вычислительные процессы лучше всего описывать именно в терминах подобной машины. Ну, как вычислимость по Тьюрингу совпадает с вычислимостью по Чёрчу, сколь бы контринтуитивным это ни казалось.

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

Ну да, обычная иллюзия понимания. К примеру, "каждый знает", что квантовый компьютер может практически мгновенно вскрыть серьёзный пароль/ключ шифрования. Вот только каждый кодер понимает... что ничего не понимает. Скажем, если даже у вас есть возможноть невозбранно перебирать пароли в любом количестве, это всё одно будет происходить далеко не мгновенно. Но кто же вам такое позволит-то? На самом деле, после пары-тройки попыток вас если и не начнут блокировать всеми возможными способами, то притормозят на заметный период времени. Т.е. корректный, удобный во всех отношениях критерий останова алгоритма (успеха/провала) должен быть внутренним для алгоритма, не содержать никаких внешних обращений. А ведь даже когда вы ломаете шифр (сугубо внутренний процесс, не требующий интерактивного взаимодействия с тем, кто инфу шифровал), шифрованное сообщение - вполне может дополняться гораздо хуже зашифрованным условно-правдоподобным текстом/звуком/изображением, на котором не страдающий полноценным ИИ алгоритм дешифровки - благополучно и завершится. В целом, уже этот - самый известный - пример силы квантового компьютера должен бы обладать малопрактичным набором граничных условий.

Наверное, надо все-таки более выделить раздел с уже существующими инструментами и примерами, как они помогают думать над тем, над чем раньше самому приходилось. Например, GPT-3 и ее наследники, очевидно, будут замечательно применимы, чтобы налить "воды" в текст. И не всегда это плохо. Текст, над которым мухи от скуки дохнут - тоже не очень хорошо. Он, понятно, будет постоянно устаревать и его придется постоянно обновлять. Но без этого зацепить и заинтересовать получиться меньше народу.

Это да, но не раздел, а примеры должны быть везде. Хотя этих примеров на пару недель хватать будет ))) И нужно таки удержаться и примеры давать не столько инженерии, сколько мышления -- а это всё-таки другое. В учебнике системного мышления примеры проектных ситуаций, где мышление задействовано, и тут нужно не продукты с их архитектурой, а мышление в примерах иметь. Трудно это, вот никто и не делает курс (((

Не увидел формирование требований к информационным системам обеспечения деятельности "директора стадиона" (ИТ-обеспечению). Только в разделе Структуры и базы данных - "системное моделирование как формализация/кодирование/онтологизирование". Адекватное, с пониманием вычислений, формирование требований - необходимое условие результата (процесса), соответсвующего ожиданиям. Кроме того, требования - основа для метрик, позволяющих оценивать трудоемкость и сроки проектов формирования, позволяющих формировать обратную связь на требования. Вспомнилась из прошлой жизни достаточно простая и прямолинейная методология консалтиногового подразедления Oracle, которая на основе количественных параметров моелирования данных и функций (количества сущностей, модулей, форм и т.п.) строила план проекта и оценку необходимых ресурсов и бюджета. Можно было провести интервью ключевых персон и дать предварительную оценку, с обратной связью - что влияет на сложность и цену.

Почему иллюзию? Знание, что вот так тоже можно, и куда дальше копать, если вдруг понадобилось, даёт _очень_ много.

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

По моему мнению в 4, 8, 10 очень важно выводить на инженерный уровень, по опыту вывода в прод BERT модели в использование в мае: 1) стек nvidia, pytorch + hugginface terraform друг с другом не работает - все пилят в свою сторону и использование BERT NLP AI моделей в проде зависит не от команд с инженерами на зарплате, а от индуса поддерживающего и пилящего проект https://simpletransformers.ai/ 2) Вендорские примеры pytorch/transformers NLP pipeline - это пример стабилизации мышления людей которые мыслят в batch, в таком виде это не добавляет пользы бизнесу, нужно разбивать и предрасчитывать, в контексте NLP - tokenization отдельно, инференс отдельно. В 7 ( Распределенные системы) нужно добавить актор модели или каналы (actor model vs process/channels) при этом для обсуждения людей и экзокортекс понятие агентов важно, хоть и имеет совесем другой смысл. Еще хорошо бы дать value from data vs data science - прям по how to measure everything, в данных ценности нет если они не собраны с учетом эксперимента. В 10 еще enterprise governance - как управляются модели если они принимают решения о 10-ках миллионов долларов или влияют на жизни? Я бы структурировал курс по другому: "для принесения пользы бизнесу от AI/Quantum computing/blockchain or digital transformation нужное подчеркнуть надо помнить про - и дальше по списку выше как дереву решений: хочешь AI в организации - надо 1) принимать решения 2) думать о этике, 3) думать о связях (онтологии) 4) мерить решения 5) собирать данные которые помогают принимать решения.

Ну вот я бы в сторону инженерии как раз бы не шёл. Понятия -- да, а конкретные технологии и конкретные практики ("как делать", а не "о чём думать") я бы в курсе не акцентировал.

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

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

1) Для того чтобы курс имел практическую пользу нужны примеры из реальной жизни, а это конкретные технологии и практики и продукты. 2) Даже на уровне понятий, инженерный (интеллект) стек в котором AI причиняет пользу предприятию выглядит по другому - нужны api gateway, dev ops, event driven architecture & governance.

Согласен - у меня про требования сформулировано - как про часть процесса создания системы, конкретно - формирования требований к "корпоративному" софту. Тем не менее, правильная концепция (понятие) требований к ИС должна появиться в словаре "директора стадиона", обучаемого computer science. А с ним - качественное понимание того, как эти требования трансформируются в план и бюджет обсуждаемого проекта. Впрочем, возможно - в Вашей картине мира - это относится к системному мышлению )