Следующий логичный шаг в развитии e-mail — более полная интеграция с искусственным интеллектом, который сможет не просто сортировать почту, расставлять приоритеты, прибивать спам и маркировать фишинговые сообщения, но и самостоятельно планировать встречи, звонки, мероприятия, опираясь на полученные сообщения.
А что может быть для сортировки почты ИИ? То, что касается спама. Здесь должна быть возможность установления связи с отправителем: во-первых, Вы должны точно знать, от кого Вы получаете почту, и, если Вы не хотите получать почту от определённого отправителя, то Вы просто отписываетесь. Во-вторых, если бы почта оставалась текстовой (в plain text), то всё было бы гораздо проще и безопаснее. Не было бы ссылок, по которым можно было бы получить вирус или сходить на фишинговый сайт. Нужны новые возможности — разрабатывайте новый протокол поверх старого. Далее, если я работаю с каким-то сайтом, то, в идеале, я должен его "установить" себе в системе, и тогда я буду получать письма только от этого сайта. Почему, вместо того, чтобы предложить людям более развитую инфраструктуру, мы модернизируем почту и допускаем опасное использование?
Возможно даже, однажды он догадается поздравить отдельным письмом моего редактора с днем рождения, потому что сам я опять забуду это сделать.
Какой в этом смысл? Получать поздравление от работа? Нужное реальное человеческое участие.
Почта окончательно станет инфраструктурой, которая научится понимать контекст и помогать в принятии решений.
Не станет. Никогда не станет. Можно было бы организовать дело так, что общение с любым интернет магазином будет осуществляться через почту. В каком смысле? Вот я зашёл и просматриваю товары: в почте появляется "снимок" ситуации, фиксирующий положение дел на момент моего прихода в магазин. Затем, я что-то покупаю, и всё оформление корзины также проводится через почту. А в конце ещё и чек высылается. Причём, всё это делается не так, как делается сейчас, кто как хочет, тот так и присылает информацию о заказе, там, статус заказа, а на регулярной основе, и на основе жёсткого протокола, фиксирующего каждый этап/элемент процесса. Потом можно будет документально подтвердить, что дело было так и так. Но! Так, ведь, не сделано. И никто ни когда не сделает.
Вопрос, тем не менее, остаётся. Я думаю, что сейчас можно уже прямо из школы готовить программистов прямо для трудоустройства. Да и нынешние поколения должны быть шибко продвинутыми в этом смысле. (Что и самому в эту область уже не соваться.)
(Сам я заканчивал шлолку тогда, когда информатика только начиналась. Но ещё в кружок успел походить, а там. хотя бы книжку Ахо, Хопкрофта и Ульмана "Построение и анализ вычислительных алгоритмов" открывали и Лиспом интересовались... Ну. это я так, к слову...)
Несмотря на то, что сам я ушел из большого ООП¹ ...
¹ Для занудных буквогрызов: я использую термин ООП не в первородном смысле, в котором его первым употребил Алан Кай, а в том, которое повсеместно распространилось сейчас с легкой руки Гослинга — наследование, инкапсуляция, классы.
Наверное, это случилось потому, что концепция классов/объектов была искусственно привнесена в языки программирования, в которых изначально ничего этого не было. В результате, произошла некоторая подмена понятий. И, вместо того, чтобы реализовывать изначальную концепцию, сделали то, что было всего проще. Это что-то вроде поиска под фонарём.
Кстати, о чём там говорил Алан Кей? Об обмене сообщениями?
... лично мне быстрее, проще и понятнее — реализовывать свои проекты на функциональном эликсире?
Скажите, пожалуйста. Что нужно делать, если кто-то заинтересуется этим самым Элисиром? Как его можно/нужно попробовать? Не означат ли всё это, что в Элисире нет проблемы, о которой Ваша статья?
И вот, наконец, меня озарило. Объектная модель всем хороша в однопоточной среде.
Тут, с очевидностью, возникает два вопроса.
Вопрос первый. Кажется, что многопоточность требует своих специальных средств, а у каждой модели (включая, очевидно, и ООП) есть свои естественные ограничения. Наверное, это должны понимать все специалисты.
Вопрос второй. Ваши рассуждения могут быть вызваны и тем, что Вам могут быть всё ещё неизвестны (на известные другим) способы решения заявленной проблемы. (Идущая ниже беседа может подтвердить или опровергнуть это предположение.)
Есть ещё и третий вопрос. А как можно попробовать многопоточность? Чтобы самому поэкспериментировать и самому почувствовать.
Каким бы эффективным не был парсер, но он загружает ваш процессор и память. Сколько бы у вас не было ядер и планок памяти - они закончатся, когда вы откроете достаточно большой проект.
Это и обуславливает необходимость перехода к другому языку и, вообще, к поиску другого представления программы (проектируемой системы). И это же вскрывает застойное состояние индустрии разработки ПО: вместо того, чтобы создавать специализированные языки программирования (под конкретные задачи), берутся существующие языки и делаются монструозными. Когда всё-равно, на чём писать. Отсюда и проблемы с производительностью.
В спецификациях нашего языка задействовано много элементов форматирования: ключевые слова, скобки, разбиение строк, отступы. Возможно с ними проще читать код, но я уверен, что есть другой способ сделать код читабельным. Гораздо важнее эти элементы при парсинге кода компилятором и другими тулзами.
На сомом деле, это — прямое указание на то, что нужно (с)делать.
Мы хотим иметь дело не только и не столько с исходным кодом, сколько с его представлением, полученным на одном из промежуточных этапов трансляции. Чтобы с ним можно было работать как с визуальными компонентами: "двигать" по "форме". Чтобы их можно было его частично выполнять. Но это значит и то, что язык представления должен быть другой, не исходный. Вот, что важно понять. Мы должны перейти на уровень выше и использовать совершенно другой язык программирования, "исходники" которого уже "заточены" под задачи управления кодом — кодом на этом высокоуровневым языком программирования. А тот язык, который был вначале — это всего лишь одно из возможных конечных представлений/реализаций проектируемой программы. Задача — получить код на оконечном языке. (Таких оконечных языков может быть несколько.) Но сама разработка должна вестись на языке разработки, то есть — на языке модулей, компонентов и зависимостей.
Я упомянул проблемы, с которыми сталкивался лично. Каждый раз мне приходилось тратить время на погружение в особенности файловых систем и поиск обходного пути. И далеко не всегда результат удовлетворял меня, чаще решение представляло собой костыль.
Тут ещё можно было бы "подумать и в сторону" самих сред разработки. Если, Вы, уж, знаете особенности различных файловых систем, то можно же предложить какой-то способ разложения программного кода на составляющие, чтобы обойти известные узкие места.
А еще мы работаем на разных файловых системах, и они предоставляют нам разные функции. Чувствительность к регистру или нет? Жесткие и символические ссылки. Права доступа. Атрибуты. Все эти особенности не имеют отношения к нашему коду, по крайней мере, вы обычно не можете прочитать о них в спецификации вашего языка.
Да. Давно надо было разобраться. Можно было бы предложить специальную файловую систему для хранения кода. Специальный раздел на диске. Для каждой задачи — своя файловая система.
Вот почему возникает потребность в БД: СУБД покрывает все эти проблемы, предлагая хранить все данные, например, в таблицах. (Можно было бы сделать простой SELECT и получить полный код. Например.)
Еще один уровень абстракции между кодом и хранилищем. Зачем нам имена файлов и ограничения с ними связанные? Разве это удобно использовать двухбуквенные расширения для указания используемого языка?
Проблема ещё и в том, что расширения файлов, с одной стороны, могут нам говорить и о том, что файл текстовый (TXT), и том, что файл содержит программу на выбранном языке программирования (C, CPP, PAS, PY, JS, PHP). Да, мы знаем, что это всё — текстовые файлы, но для имён файлов нужно строгое единообразие, а не смешение формата представления и соотнесения с обрабатывающей программой. Здесь напрашивается иерархия: на верхнем уровне у нас имеются каталоги C, CPP, PAS, PY, JS, PHP, а на нижнем — TXT, BIN. А ещё нужен промежуточный уровень, который осуществляет отображение верхнего уровня на нижний.
Но если мы говорим о форматировании, для меня это выглядит странно: почему мы должны заботиться о пустых строках, табуляции или пробелах, ограничениях по длине строк и других несущественных деталях?
Вообще говоря, это пользователь должен определять, как ему удобнее. Внутреннее представление программного кода не должно зависеть от того, как этот код отображается.
Слава всем богам, мы не добавляем информацию о предпочитаемом шрифте и цвете в нашу кодовую базу, я точно не хочу читать код в Comic Sans.
Главное, чтобы шрифт позволял хорошо различать "1". "l" (L) и "I" (i). Например.
К сожалению, мир не смог договориться об одном стандарте, поэтому то и дело приходится сталкиваться с проблемами: испорченные диффы, ошибки в тулзах, проблемы с копированием, нечитаемый текст на фронте.
А в чём проблема? Почему нельзя сделать нечто очень важное и полезное?
Действительное решение задачи заключается в том, чтобы определённым образом упорядочить символы. Например, должен быть единый для всех символ конца строки. Но, тогда, очевидно, возникнет потребность в наличии не только символа начала строки, но и всех других начал и концов. Например, символ, отмечающий начало идентификатора, и символ, отмечающий его конец. Точно такая же разметка (!!) касается и знаков операций, и разного рода литералов. Привычное нам текстовое представление — это результат вот такой невидимой глазу разметки, и мы в редакторе должны иметь дело уже с результатом этой разметки, но сам исходный текст должен содержать и все промежуточные символы.
С точки зрения хранения программного кода, целесообразно хранить тройки: собственно, отдельную инструкцию, комментарий к ней и элемент, описывающий связь данной инструкции с другими. Впрочем, здесь напрашиваются и RDF-тройки, которые описывают предикаты: объект, субъект и функцию.
Это не риторический вопрос. Я знаю, так исторически сложилось, но... почему мы продолжаем использовать текстовые файлы?
Да! Это очень интересный вопрос. Всегда им задавался. Крайне неудобно. Да. Можно посмотреть, прочитать, исправить, дописать и "скормить" компилятору.
Вы можете сказать, что это очень простое решение: что видишь, то оно и есть. Но мы имеем дело с несколькими слоями абстракции, а все абстракции текут. Это приводит к ошибкам, запутанным диффам и проблемам с производительностью.
Тут такое дело. Всегда есть выбор: либо явное описание работы программы в текстовой форме, либо некое промежуточное хранение. Выбор, собственно, в чём? В надёжности! Если промежуточное представление "потечёт", то с программой придётся попрощаться. Если это, например, база данных, то у СУБД может быть механизм восстановления.
Безусловно, БД программного кода очень нужна. Была бы такая БД, не над было бы специально (!!) создавать всевозможные системы управления версиями (включая и Git), БД сама следила бы за всеми версиями.
Давайте углубимся в искусство хранения кода в виде текстовых файлов.
Давайте. Но... позже. Надо ещё статью прочитать и комментарии к ней. А ещё и подумать...
Для начала, надо понять, что существенная часть проблемы — это проблема кодировка. Точнее, отсутствие системного решения этой проблемы. Во времена MS DOS текстовыми файлами считались файлы, не содержащие символов из самого начала таблицы ASCII. Дело в том, что там располагаются всякого рода управляющие символы. Если их нет, то текстовый файл правильно открывается в "хорошем" текстовом редакторе. А "плохие" редакторы норовят вставлять эти управляющие символы в текст, что этот самый текст ломает. При системном решении проблемы кодировок, у нас было бы чёткое разделение на классы символов. И, вообще, была бы весьма обширная классификация символов, в особенности, управляющих.
Ещё. Нам в языках программирования приходится мириться с тем, что некоторые операции требуют нескольких символов. Например "<=", ">=", "===". В нормальной ситуации (при системном решении проблемы кодировок) для каждой такой операции существовал бы отдельный символ. Это, кстати, упростило бы лексический анализ и сделало бы АСД очень хорошим способом промежуточного хранения.
Следует, также, заметить, что нас имеется проблема с понятием текстового файла. Если мы возьмём, скажем, файлHTML или файл JSON. Это, ведь, тоже будет текстовый файл. Но его надо ещё интерпретировать. Никто не мешает сделать так, чтобы был какой-то способ промежуточного хранения, а текст был бы одним из возможных представлений. Но это поднимает вопрос о том, а как следует, вообще, создавать программы. Я могу себе представить реализацию программы на некотором высокоуровневом языке программирования в виде некой мета-программы, выполнение которой приводит к формированию кода уже на низкоуровневом языке программирования. (Что-то вроде рендеринга. Программного кода. По идее LLM со своими кодерами и декодерами как-то воспроизводят эту конструкцию.) При этом, эти два языка могут существенно отличаться по своей концепции. Кроме того, здесь фигурирует ещё и третий язык программирования — язык самой системы, которая производит описываемую здесь трансляцию.
... "написать программу, выигрывающую в шахматы ...
Шахматный движок можно сделать разными способами. Но эти способы не имеют никакого отношения к решению Вашей задачи. Какой способ реализации выбрали, так и его и представили для реализации уже ИИ-автомата. В рамках Вашей задачи было бы уместно обсуждать формат хранения информации о текущих позициях и о последовательности ходов (для оптимального в вычислительном отношении перебора вариантов). Ещё, с точки зрения ИИ, было бы полезно рассмотреть вопрос инвариантов: ведь. понятно, что некоторые шахматные позиции отличаются друг от друга только перестановкой строк и столбцов. Другими словами, здесь нужен переход в конфигурационное пространство, где учитывается только взаимное расположение фигур, а не их абсолютное положение. Думаю, что в профессиональных движках так и сделано.
Как у Вас много всего прямо в коде прописывается. Хотелось бы разделить внутреннюю логику (где есть только числа, координаты) и представление (где есть, например, буквы). А начать хотелось бы с базовой логики, когда есть состояния и есть переходы из одного состояния в другое.
Саму логику шахматной фигуры сделать единой, но через дженерики подставлять разные способы передвижения ...
Зачем Вам "дженерики"? Каждая фигура — это -"конь"; а ещё фигуры отличаются "продолжаемостью": конь, король и пешка просто ходят на , и всё, а слон, ладья и ферзь двигаются до конца доски. То есть: достаточно одного простого класса и двух полей: пара и признак "продолжаемости". При каждой фиксированой позиции автоматически вычисляется набор достижимых полей каждой фигурой. При перемещении фигуры производится пересчёт.
То, что касается ИИ, то он обучается именно тому, как меняется структура полей достижимости при каждом ходе, и пытается оценить каждое такое изменение, при очевидных условиях, что есть некоторые терминальные состояния (мат или пат), когда уже некуда идти.
Но! Если мы говорим об ИИ и о построении какой-либо игровой стратегии, то вопрос реализации самого игрового движка становится несущественным, и его решение ничего нам не даёт в плане реализации стратегии.
А что может быть для сортировки почты ИИ? То, что касается спама. Здесь должна быть возможность установления связи с отправителем: во-первых, Вы должны точно знать, от кого Вы получаете почту, и, если Вы не хотите получать почту от определённого отправителя, то Вы просто отписываетесь. Во-вторых, если бы почта оставалась текстовой (в plain text), то всё было бы гораздо проще и безопаснее. Не было бы ссылок, по которым можно было бы получить вирус или сходить на фишинговый сайт. Нужны новые возможности — разрабатывайте новый протокол поверх старого. Далее, если я работаю с каким-то сайтом, то, в идеале, я должен его "установить" себе в системе, и тогда я буду получать письма только от этого сайта. Почему, вместо того, чтобы предложить людям более развитую инфраструктуру, мы модернизируем почту и допускаем опасное использование?
Какой в этом смысл? Получать поздравление от работа? Нужное реальное человеческое участие.
Не станет. Никогда не станет. Можно было бы организовать дело так, что общение с любым интернет магазином будет осуществляться через почту. В каком смысле? Вот я зашёл и просматриваю товары: в почте появляется "снимок" ситуации, фиксирующий положение дел на момент моего прихода в магазин. Затем, я что-то покупаю, и всё оформление корзины также проводится через почту. А в конце ещё и чек высылается. Причём, всё это делается не так, как делается сейчас, кто как хочет, тот так и присылает информацию о заказе, там, статус заказа, а на регулярной основе, и на основе жёсткого протокола, фиксирующего каждый этап/элемент процесса. Потом можно будет документально подтвердить, что дело было так и так. Но! Так, ведь, не сделано. И никто ни когда не сделает.
Да! Хочется разобраться.
Хотя. Казалось бы! Можно было бы многое чего посчитать и красиво нарисовать.
Вопрос, тем не менее, остаётся. Я думаю, что сейчас можно уже прямо из школы готовить программистов прямо для трудоустройства. Да и нынешние поколения должны быть шибко продвинутыми в этом смысле. (Что и самому в эту область уже не соваться.)
(Сам я заканчивал шлолку тогда, когда информатика только начиналась. Но ещё в кружок успел походить, а там. хотя бы книжку Ахо, Хопкрофта и Ульмана "Построение и анализ вычислительных алгоритмов" открывали и Лиспом интересовались... Ну. это я так, к слову...)
Вот спасибо. Теперь у меня полный план работы на лето. *вдохнул побольше воздуха*
И что бы Вы предложили сделать?
Каких?
А чему учат сейчас на уроках информатики?
Наверное, это случилось потому, что концепция классов/объектов была искусственно привнесена в языки программирования, в которых изначально ничего этого не было. В результате, произошла некоторая подмена понятий. И, вместо того, чтобы реализовывать изначальную концепцию, сделали то, что было всего проще. Это что-то вроде поиска под фонарём.
Кстати, о чём там говорил Алан Кей? Об обмене сообщениями?
Скажите, пожалуйста. Что нужно делать, если кто-то заинтересуется этим самым Элисиром? Как его можно/нужно попробовать? Не означат ли всё это, что в Элисире нет проблемы, о которой Ваша статья?
Тут, с очевидностью, возникает два вопроса.
Вопрос первый. Кажется, что многопоточность требует своих специальных средств, а у каждой модели (включая, очевидно, и ООП) есть свои естественные ограничения. Наверное, это должны понимать все специалисты.
Вопрос второй. Ваши рассуждения могут быть вызваны и тем, что Вам могут быть всё ещё неизвестны (на известные другим) способы решения заявленной проблемы. (Идущая ниже беседа может подтвердить или опровергнуть это предположение.)
Есть ещё и третий вопрос. А как можно попробовать многопоточность? Чтобы самому поэкспериментировать и самому почувствовать.
Это и обуславливает необходимость перехода к другому языку и, вообще, к поиску другого представления программы (проектируемой системы). И это же вскрывает застойное состояние индустрии разработки ПО: вместо того, чтобы создавать специализированные языки программирования (под конкретные задачи), берутся существующие языки и делаются монструозными. Когда всё-равно, на чём писать. Отсюда и проблемы с производительностью.
На сомом деле, это — прямое указание на то, что нужно (с)делать.
Мы хотим иметь дело не только и не столько с исходным кодом, сколько с его представлением, полученным на одном из промежуточных этапов трансляции. Чтобы с ним можно было работать как с визуальными компонентами: "двигать" по "форме". Чтобы их можно было его частично выполнять. Но это значит и то, что язык представления должен быть другой, не исходный. Вот, что важно понять. Мы должны перейти на уровень выше и использовать совершенно другой язык программирования, "исходники" которого уже "заточены" под задачи управления кодом — кодом на этом высокоуровневым языком программирования. А тот язык, который был вначале — это всего лишь одно из возможных конечных представлений/реализаций проектируемой программы. Задача — получить код на оконечном языке. (Таких оконечных языков может быть несколько.) Но сама разработка должна вестись на языке разработки, то есть — на языке модулей, компонентов и зависимостей.
Тут ещё можно было бы "подумать и в сторону" самих сред разработки. Если, Вы, уж, знаете особенности различных файловых систем, то можно же предложить какой-то способ разложения программного кода на составляющие, чтобы обойти известные узкие места.
Да. Давно надо было разобраться. Можно было бы предложить специальную файловую систему для хранения кода. Специальный раздел на диске. Для каждой задачи — своя файловая система.
Вот почему возникает потребность в БД: СУБД покрывает все эти проблемы, предлагая хранить все данные, например, в таблицах. (Можно было бы сделать простой SELECT и получить полный код. Например.)
Проблема ещё и в том, что расширения файлов, с одной стороны, могут нам говорить и о том, что файл текстовый (TXT), и том, что файл содержит программу на выбранном языке программирования (C, CPP, PAS, PY, JS, PHP). Да, мы знаем, что это всё — текстовые файлы, но для имён файлов нужно строгое единообразие, а не смешение формата представления и соотнесения с обрабатывающей программой. Здесь напрашивается иерархия: на верхнем уровне у нас имеются каталоги C, CPP, PAS, PY, JS, PHP, а на нижнем — TXT, BIN. А ещё нужен промежуточный уровень, который осуществляет отображение верхнего уровня на нижний.
Вообще говоря, это пользователь должен определять, как ему удобнее. Внутреннее представление программного кода не должно зависеть от того, как этот код отображается.
Главное, чтобы шрифт позволял хорошо различать "1". "l" (L) и "I" (i). Например.
А в чём проблема? Почему нельзя сделать нечто очень важное и полезное?
Действительное решение задачи заключается в том, чтобы определённым образом упорядочить символы. Например, должен быть единый для всех символ конца строки. Но, тогда, очевидно, возникнет потребность в наличии не только символа начала строки, но и всех других начал и концов. Например, символ, отмечающий начало идентификатора, и символ, отмечающий его конец. Точно такая же разметка (!!) касается и знаков операций, и разного рода литералов. Привычное нам текстовое представление — это результат вот такой невидимой глазу разметки, и мы в редакторе должны иметь дело уже с результатом этой разметки, но сам исходный текст должен содержать и все промежуточные символы.
С точки зрения хранения программного кода, целесообразно хранить тройки: собственно, отдельную инструкцию, комментарий к ней и элемент, описывающий связь данной инструкции с другими. Впрочем, здесь напрашиваются и RDF-тройки, которые описывают предикаты: объект, субъект и функцию.
Да! Это очень интересный вопрос. Всегда им задавался. Крайне неудобно. Да. Можно посмотреть, прочитать, исправить, дописать и "скормить" компилятору.
Тут такое дело. Всегда есть выбор: либо явное описание работы программы в текстовой форме, либо некое промежуточное хранение. Выбор, собственно, в чём? В надёжности! Если промежуточное представление "потечёт", то с программой придётся попрощаться. Если это, например, база данных, то у СУБД может быть механизм восстановления.
Безусловно, БД программного кода очень нужна. Была бы такая БД, не над было бы специально (!!) создавать всевозможные системы управления версиями (включая и Git), БД сама следила бы за всеми версиями.
Давайте. Но... позже. Надо ещё статью прочитать и комментарии к ней. А ещё и подумать...
Для начала, надо понять, что существенная часть проблемы — это проблема кодировка. Точнее, отсутствие системного решения этой проблемы. Во времена MS DOS текстовыми файлами считались файлы, не содержащие символов из самого начала таблицы ASCII. Дело в том, что там располагаются всякого рода управляющие символы. Если их нет, то текстовый файл правильно открывается в "хорошем" текстовом редакторе. А "плохие" редакторы норовят вставлять эти управляющие символы в текст, что этот самый текст ломает. При системном решении проблемы кодировок, у нас было бы чёткое разделение на классы символов. И, вообще, была бы весьма обширная классификация символов, в особенности, управляющих.
Ещё. Нам в языках программирования приходится мириться с тем, что некоторые операции требуют нескольких символов. Например "<=", ">=", "===". В нормальной ситуации (при системном решении проблемы кодировок) для каждой такой операции существовал бы отдельный символ. Это, кстати, упростило бы лексический анализ и сделало бы АСД очень хорошим способом промежуточного хранения.
Следует, также, заметить, что нас имеется проблема с понятием текстового файла. Если мы возьмём, скажем, файлHTML или файл JSON. Это, ведь, тоже будет текстовый файл. Но его надо ещё интерпретировать. Никто не мешает сделать так, чтобы был какой-то способ промежуточного хранения, а текст был бы одним из возможных представлений. Но это поднимает вопрос о том, а как следует, вообще, создавать программы. Я могу себе представить реализацию программы на некотором высокоуровневом языке программирования в виде некой мета-программы, выполнение которой приводит к формированию кода уже на низкоуровневом языке программирования. (Что-то вроде рендеринга. Программного кода. По идее LLM со своими кодерами и декодерами как-то воспроизводят эту конструкцию.) При этом, эти два языка могут существенно отличаться по своей концепции. Кроме того, здесь фигурирует ещё и третий язык программирования — язык самой системы, которая производит описываемую здесь трансляцию.
Шахматный движок можно сделать разными способами. Но эти способы не имеют никакого отношения к решению Вашей задачи. Какой способ реализации выбрали, так и его и представили для реализации уже ИИ-автомата. В рамках Вашей задачи было бы уместно обсуждать формат хранения информации о текущих позициях и о последовательности ходов (для оптимального в вычислительном отношении перебора вариантов). Ещё, с точки зрения ИИ, было бы полезно рассмотреть вопрос инвариантов: ведь. понятно, что некоторые шахматные позиции отличаются друг от друга только перестановкой строк и столбцов. Другими словами, здесь нужен переход в конфигурационное пространство, где учитывается только взаимное расположение фигур, а не их абсолютное положение. Думаю, что в профессиональных движках так и сделано.
Как у Вас много всего прямо в коде прописывается. Хотелось бы разделить внутреннюю логику (где есть только числа, координаты) и представление (где есть, например, буквы). А начать хотелось бы с базовой логики, когда есть состояния и есть переходы из одного состояния в другое.
Зачем Вам "дженерики"? Каждая фигура — это
-"конь"; а ещё фигуры отличаются "продолжаемостью": конь, король и пешка просто ходят на 
, и всё, а слон, ладья и ферзь двигаются до конца доски. То есть: достаточно одного простого класса и двух полей: пара 
и признак "продолжаемости". При каждой фиксированой позиции автоматически вычисляется набор достижимых полей каждой фигурой. При перемещении фигуры производится пересчёт.
То, что касается ИИ, то он обучается именно тому, как меняется структура полей достижимости при каждом ходе, и пытается оценить каждое такое изменение, при очевидных условиях, что есть некоторые терминальные состояния (мат или пат), когда уже некуда идти.
Но! Если мы говорим об ИИ и о построении какой-либо игровой стратегии, то вопрос реализации самого игрового движка становится несущественным, и его решение ничего нам не даёт в плане реализации стратегии.