📝 "Закон Вайнберга-Брукса: От действий менеджеров, основанных на неправильных моделях системы, пострадало больше проектов, чем от всех остальных причин вместе взятых.

Weinberg-Brooks' Law: More software projects have gone awry from management's taking action based on incorrect system models than for all other causes combined."

Термин “искусственный интеллект” впервые появился в заявке на проведение семинара в Дартмутском колледже в Хановере (штат Нью-Гэмпшир). Семинар состоялся в 1956 году.

Мак-Каллок и Питтс доказали, что нейронная сеть может выполнять числовые и логические операции. Кроме того, они предположили, что сети с особенной архитектурой способны обучаться. В 1943 году учёные опубликовали свои результаты в статье “Логическое исчисление идей, присущих нервной деятельности” (A Logical Calculus of Ideas Immanent in Nervous Activity).

В 1957 году Фрэнк Розенблатт смоделировал работу нейронной сети в виде программы для универсального компьютера IBM 704. Годом позже учёный сконструировал первый нейрокомпьютер под названием Mark I Perceptron. Mark I представлял собой однослойную нейронную сеть. Она работала по тому же принципу, что и отдельный перцептрон. Компьютер состоял только из аналоговых компонентов. Входное изображение поступало на матрицу из фотодетекторов размером 20x20. Сигналы с неё передавались на электромеханические устройства, которые моделировали отдельные нейроны. Чтобы регулировать веса входных сигналов, применялись потенциометры. В процессе обучения их настройки менялись автоматически с помощью электромоторов.

В системе Advice Taker знания и механизм рассуждений чётко разделялись. Знания хранились в виде правил на некотором формальном языке. Эти правила помещались в списки. В результате их стало проще редактировать. Теперь с этой задачей мог справиться оператор без навыков программирования.

Для логического вывода Advice Taker выполнял поиск по спискам. Джон Маккарти искал способ вынести алгоритм поиска из кода самой системы. Учёный решил сделать поиск одним из механизмов языка программирования. Тогда на таком языке стало бы значительно проще и быстрее создавать новые специализированные интеллектуальные системы.

Джон Маккарти начал работать над новым языком программирования. Он рассматривал это как первый шаг для реализации Advice Taker. Так появился язык LISt Processing более известный как Lisp. Учёный описал Lisp в статье для журнала Communications of the ACM в 1960 году. Первый работающий интерпретатор языка появился в 1958 году для компьютера IBM 704.

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

Главный механизм Lisp — это операции над списками. В отличие от других языков Lisp не различает данные и код программы. Вся программа записывается в виде списков, заключенных в круглые скобки.
Такие структуры в терминологии языка называются S-выражениями (s-expressions).

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

Система Advice Taker так никогда и не была реализована. Когда Джон Маккарти довел язык Lisp до стабильного состояния, она уже потеряла актуальность. Тем не менее Advice Taker оказалась полезна как модель типичной интеллектуальной системы.
Она помогла учёному лучше понять нужды разработчиков. Благодаря этому, Джон Маккарти создал язык, который стал основным инструментом для исследователей ИИ на протяжении десятилетий.

"Искусственный интеллект в стратегических играх" Илья Шпигорь
https://leanpub.com/ai-in-strategy-games

В начале 1990-х годов шведский психолог Андерс Эрикссон и его коллеги изучали роль практики в получении экспертных навыков. В 1993 году они изложили результаты своей работы в статье “Роль целенаправленной практики для достижения уровня эксперта” (The Role of Deliberate Practice in the Acquisition of Expert Performance).

Учёные проверяли распространённое мнение о роли таланта в профессиональной деятельности. Для этого они провели исследование с участием студентов скрипачей из Академии музыки в Берлине.
Уровень студентов различался. В зависимости от успеваемости, учащихся разделили на три группы:

1. Потенциальные звёзды мирового класса.
2. Перспективные исполнители.
3. Посредственные исполнители.

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

Андерс Эрикссон и его коллеги выяснили, что к 20 годам музыканты из первой группы потратили в сумме около 10000 часов на занятия музыкой.
Студенты из второй группы за тот же период времени занимались порядка 7500 часов, а в третьей группе—только 5000 часов. Из этих наблюдений учёные сделали вывод, что регулярная практика имеет решающее значение для приобретения экспертных навыков. Именно она определяет успешность исполнителя, а не врождённый талант или ранний возраст начала обучения. В то же время Андерс Эрикссон признаёт, что индивидуальные когнитивные и физиологические различия влияют на эффективность практики.

В 2008 году канадский журналист Малкольм Гладуэлл популяризовал выводы Андерса Эрикссона в книге “Гении и аутсайдеры” (Outliers: The Story of Success). Автор книги утверждает, что для достижения мастерства в какой-либо области нужно около 10000 часов практики. Это примерно 6 лет упражнений по 5 часов в день. Закономерность получила широкую известность как правило 10000 часов. К сожалению, это правило упускает некоторые важные тонкости первоначального научного исследования.

В статье Андерс Эрикссон утверждает, что для практики важно не количество, а качество.
Чтобы подчеркнуть эту мысль, учёный ввёл специальный термин. Преднамеренная практика (deliberate practice) — это целенаправленная и систематическая работа эксперта, направленная на улучшение своей производительности.
У преднамеренной практики есть ряд особенностей.

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

Во-вторых, преднамеренная практика нацелена на расширение текущих возможностей эксперта. Исходя из этих возможностей выбираются конкретные упражнения. Часто это не тренировка сильных сторон, а работа над ошибками и слабыми сторонами.

В-третьих, для преднамеренной практики крайне важна обратная связь. Эксперт должен немедленно получать оценку своих действий. В этом ему помогает тренер или учитель. Благодаря обратной связи, эксперт распознаёт свои ошибки и может работать над их исправлением.
Андерс Эрикссон также указывает на то, что преднамеренная практика неприятна по своей сути. Она требует тяжёлой физической или умственной работы, дискомфорта от признания своих ошибок и настойчивости. Часто эксперту приходится повторять одни и те же упражнения снова и снова, пока не будет достигнута поставленная цель.

-- "Искусственный интеллект в стратегических играх" Илья Шпигорь
https://leanpub.com/ai-in-strategy-games

"В успехе только 5% таланта, а остальное - это пот и трудолюбие. Поэтому нужно захотеть стать чемпионом и не бояться преодолевать трудности. Самое главное - сделать первый шаг, не бояться наступать на леность, трусость и самовосприятие. Нужно встать с дивана, поднять сначала свою "тушу", а потом тело соперника на ковре..."
—Александр Карелин

For example, it’s not sufficient to be a good communicator and a good technologist. You have to be a good technical communicator, making complex topics approachable without dumbing them down. You have to remain engaging without drifting completely into storytelling–your job is to highlight critical technical decisions and trade-offs.

Good technical leaders are role models, understand and value their team’s skills, or find ways to simplify designs (naturally, without micromanaging). If managers are accountable for performance evaluations and can’t judge technical skills, teams will quickly learn that they can get by with sounding smart instead of actually knowing their stuff.

A good technical leader is a force multiplier for the teams: it makes them more productive, better decision makers, and happier. And you need to have some idea what you are managing.