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

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

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

Но чтобы композиционностью было удобно пользоваться, я придерживаюсь следующих принципов в дизайне самого языка:
Все интерфейсы должны быть открытыми
Я не считаю инженеров детьми, от которых нужно скрывать детали реализации. Они способны находить применение и выворачивать всё наизнанку - так пускай так и делают, попутно находя новые решения, там где их не видел первоначальный создатель. Вы скрываете детали, потому что зачастую они невероятно уродливы и в них крайне тяжело разобраться (иначе бы их не называли "кишками").
Абсолютно всё можно изменить
С помощью естественных преобразований можно изменить любые объекты/эффекты/примитивы. Можно повлиять на вход/выход функций/атрибутов, изменять область видимости состояния, трансформировать одни структуры данных в другие, разъединять/объединять эффекты между собой.
Избегать слов любой ценой
Каждое слово несёт за собой множество смыслов и длинный шлейф ассоциаций. Поэтому сами слова нужно использовать по-минимуму и они должны иметь как можно чёткие определения. Скажем, я хочу написать функцию remove
, которая удаляет определенный элемент из списка. Должна ли она обойти весь список и удалить все совпадения с образцом или же остановится на первом сопоставлении? Тогда чем она отличается от filter
? Что если я хочу, чтобы сопоставление с образцом было более умудрённым? Удалить первые 4 элемента, соответствующих определенному условию. Или чтобы я за условиями обращался куда-нибудь во внешний мир. Как только таких простых функций недостаточно, приходится писать новые.

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

По сути, Я - это eDSL в Haskell
. Он содержит в себе чистую корневую библиотеку (без зависимостей, даже нет base
); другие библиотеки (работа с консолью, ASCII-символы); и специальный шрифт, который преобразовывает определенную последовательность символов в лигатуры (тестировалось в Visal Studio Code).
На данный момент я больше всего сфокусирован на том, чтобы самому набить руку и сделать так, чтобы писать программы в Я было быстрее и удобнее, чем в Python. Я подбираю примеры из различных предметных областей, и постепенно добавляю новые фичи - но так чтобы сложность росла линейно.
Я оставлю несколько ссылок ниже, если у вас есть вопросы (кроме того, зачем нужен ещё один язык программирования) - не стесняйтесь задавать.
В следующий раз напишу больше о том, как естественные преобразования отвечают за весь порядок вычисления в языке, как лемма Йонеды помогает с синтаксисом и как я использую копределы в качестве паттерн-матчинга.
Документация | Пробное видео с Hello, Word! | Репозиторий с примерами | Твиттер
Автор: iokasimov