Комментарии 26
Дело в том, что сложные инструменты - сложные. А люди любят решать простые проблемы простыми инструментами.
Правда потом, они продолжают использовать простые инструменты для сложных проблем. Зато все всё понимают.
Апл на нейротяге покатит наверное.
Write-only язык, у которого только одна нормальная реализация - коммерческая? Не очень впечатляет.
Связь с математикой тут тоже такая себе. Ну вот как A +.× B соотносится с умножением матриц? По-факту, большинство символов надо будет отдельно запомнить, и они либо не имеют ничего общего с математическими обозначениями, либо будут путаться. Потому что, например, как норма вдруг стала (+/X*2)*0.5 , хотя в математике все ее знают как ||x|| .
Плохие инструменты требуют, чтобы вы думали о них.
По-моему, отлично подходит к АПЛ
Потому что, например, как норма вдруг стала (+/X*2)*0.5 , хотя в математике все ее знают как x .
У вас нотация для произвольной нормы, а у автора описание для Гильбертова пространства.
Да, имеет смысл. Но почему тогда не (A +.× A)*0.5 ? Или √(A +.× A)
Cамо скалярное произведение тоже почему-то не обозначается одним привычным символом (например
), а выражается через композицию.
Ну то есть мой тейк в том, что все равно придется учить особенности языка, потому что нифига оно не соотносится с математикой. Так какая разница, писать человекочитаемые a.dot(b) или a.norm() или странные закорючки, которые иногда есть в математике, иногда нет, а иногда есть в математике, но в APL они означают другое...
При всём моём уважении к APL, эта статья - жуткое LLM-дерьмо с мерзким форматированием и тупейшим повторением "математическая абстракция". Если автор человек, то пусть объяснит, что такое "сортировка матрицы", существование которой он приписывает APL и K.
Прочитав статью , вспомнил фразу из фильма «Адъютант его превосходительства»: « Викентий, что это всё значит. И при чем здесь, Юрий»… Хочется задать эти вопросы автору, изменив, Викентий - на имя автора, а имя Юрий - на математика …
Во-первых, для
Инженерных расчётов (финансы, биоинформатика, физика)
этот язык не подходит вообще никак. Инженерными расчётами занимаются инженеры, а не математики. Вот у меня задача: на входе спектр с несколькими резонансными пиками, на выходе надо получить, сколько пиков, и набор характеристик для каждого пика. Используя NumPy и SciPy, это делается просто и быстро. Алгоритмы подгонки уже под капотом написаны. APL мне чем поможет? Насколько я понимаю, он мне поможет, если я решу, что стандартная норма, которая зашита в функции подгонки (сумма квадратов разностей), меня не устраивает, и я хочу заняться не решением моей инженерной задачи, а поиском нового алгоритма подгонки? Это точно относится к инженерным расчётам? Ни в финансах, ни в физике, ни в биоинформатике никто не использует никаких математических изысков за пределами стандартной матстатистики, которая вся давно записана в библиотеках, и любая функция оттуда вызывается одной командой.
Во-вторых,
Фокус на математической сути, а не языке
Тут вообще этого не видно. Видно, что надо учить совершенно не очевидную нотацию, то есть, язык. Плюс, приведённый вами же пример из теории графов: граф представляется матрицей смежности, с которой проводятся матричные манипуляции - фокус именно на форме представления графа, а не на сути. Чем это отличается от Матлаба, например? Тем, что символов в скрипте получится меньше?
Статья - норм, язык - тупиковая ветвь. Очень неудачная грамматика. Попробуйте почитать Уайтхед А.Н., Рассел Б. Основания математики. Тома 1-3. 2005. Там в 1930-х математика изложена именно этим языком. Выглядит так, читать могут только авторы (алгебраисты) и... компьютер:
Так ведь это даже 1910-е года, а не 1930-е. А эту книгу «переводили» на современный язык? Или она так и издаётся только на «арамейском»?
В нулевых перевели на русский. Я взял книги от сюда:
https://yandex.by/search/?text=библиотека+математика+и+физика+поля
PS Рекомендую эту библиотеку по матфизике, в ней есть ВСЁ.
Фортран вышел в 1957, каким образом в 1962 он не был "широко распространен"? Вики пишет, что в 1963 только трансляторов для него уже существовало 40 разных.
Не люблю статьи с личными открытиями автора без всестороннего изучения вопроса. Они искажают действительность.
Открыл для себя что-то, удивился --- молодец! Но, если хочешь написать про это, то надо стать специалистом в вопросе.
Тут множество недочётов есть. И ещё сравнение удивило:
REPL появился в APL на 20 лет раньше, чем в Python
И чего? В Фокале, на котором я и тысячи советских школьников, студентов, инженеров ещё в 80-е программировали, была среда такая. Фокал появился в 60-е. При чём тут Питон --- вообще не понятно. И APL тут не пионер.
А, почему он забыт --- понятно.
Если есть, например, три инструмента и сто задач,
один из которых идеально подходит для 2 из 100, немного подходит для ещё 10 из 100 и никак не подходит для остальных (типа, APL);
второй хорош для 80, но не подходит для 20 (типа, Паскаль);
а, третий хорош для 30, туда-сюда для 50 и неудобен, но справится, с оставшимися 20 (типа, Си),
то люди будут инвестировать в освоение третьего (условный Си), а не первого --- условный APL.
Что и произошло.
Зачем плохой синтаксис математики тащить в программирование?
В математике можно наблюдать магические буквы (как минимум из греческого и латыни), стрелочки и другие неоднозначные символы. И нельзя просто так сделать обёртку, которую бы все тут же поняли и стали использовать просто подключив ваш пакет.
Математика стала такой неудобной потому что развивалась тысячи лет асинхронно без общих строгих договоренностей, без автокомплита, со слабыми синхронизациями мнений сообщества, без аналитики удобности. Просто вот жуткое легаси.
ЯП не должны наследовать эти ограничения хотя бы потому что они создаются уже при другом уровне развития человечества. Но как DSL этот APL и другие матлабы могут быть хорошим решением, просто это (традиция для DSL) далеко не всем нужно
Зачем плохой синтаксис математики тащить в программирование?
В математике можно наблюдать магические буквы (как минимум из греческого и латыни), стрелочки и другие неоднозначные символы. И нельзя просто так сделать обёртку, которую бы все тут же поняли и стали использовать просто подключив ваш пакет.
Как конкретно вы бы улучшили синтаксис, чтобы получилась обёртка, которую бы все тут же поняли?
Давайте на каком-нибудь примере: либо не самое сложное упражнение
либо кусочек статьи:
Я готов отвечать на уточняющие вопросы произвольно глубоко, насколько вам это нужно (особенно по первому примеру).
В качестве задачи со звёздочкой можно обсудить нотацию для, скажем,
Есть много математических библиотек для многих языков программирования. Там для обертки математических функций в функции программирования используют несколько английских слов, иногда конечно сокращая во что-то непонятное - но это все ещё более понятно чем в математике.
Мне лень придумывать как приведенные вами формулы удобно обернуть в программирование
Но я я могу привести примеры попроще:
int Sum(ArrayInt items);
Все параметры слева и справа, имя метода понятно.
В математике же будет непонятная ∑ и параметра разбросанные сверху, снизу, сбоку.
Вот ещё пример. В программировании можно назвать метод (функцию) так
ArrayInt GaussianBlur (ArrayInt items);
В математике это будет выглядеть уже наверное как так Gσ: ℤⁿ → ℤⁿ
Ну и что такое Gσ не сразу понятно
Мне лень придумывать как приведенные вами формулы удобно обернуть в программирование
Вот так всегда :(
Есть много математических библиотек для многих языков программирования. Там для обертки математических функций в функции программирования используют несколько английских слов, иногда конечно сокращая во что-то непонятное - но это все ещё более понятно чем в математике.
Можете привести примеры таких библиотек для теорката, теории типов, и так далее?
Я вот могу привести что-нибудь из агды, где это есть, и там значочки не сильно лучше, например: https://agda.github.io/agda-categories/Categories.Category.Monoidal.Core.html или https://agda.github.io/agda-stdlib/v2.3/Function.Base.html — тоже значочки-закорючки какие-то непонятные, очень часто — односимвольные.
Все параметры слева и справа
Не все. Их меньше, чем в полной записи Σ, и ваша запись описывает меньше случаев. Например, напишите, как будет выглядеть в вашей записи выражение
имя метода понятно.
А писали бы о произведении — уже было бы непонятно, что то ли произведение, то ли продукт какой-то в предметной области.
В математике же будет непонятная ∑ и параметра разбросанные сверху, снизу, сбоку.
В простейшем случае вроде покрываемого вашим Sum — нет. Я спокойно пишу Σ aᵢ, и из контекста вполне понятно, что это сумма всех элементов данной коллекции. Не нужно писать никакие параметры сверху-снизу.
В программировании можно
Окей, в математике у меня есть запись
Я сразу знаю, что это эпиморфизм (то есть, ∀ φ, ψ. φf = ψf ⇒ φ = ψ), что он действует в какую-то фактор-структуру по некоему отношению эквивалентности, и так как обычно под G понимают группы, то, скорее всего, у меня тут каноническая проекция из группы в фактор-группу по отношению эквивалентности, соответствующему какой-то нормальной подгруппе.
Можете это же записать так же выразительно в программировании, и чтобы глаза не вытекали от оверхеда синтаксиса?
И да и нет. Непонятная сигма, конечно, ничем не отличается от непонятного Sum. Но переписать запись с пределом (и чем угодно) можно. Как мы говорим словами? "Предел по n стремящемся к бесконечности суммы по i от 0 до n значений a с индексом 2i и в степени 2" Расписываем в ast, у каждой операции есть параметры, аргументы, результат. Получаем типа такого (в префиксной нотации)
(Limit (Var n) Infinity (Sum (Var i) 0 (Var n) (Power (VarIndex a (Mult 2 (Var i)) 2))) Изящно? Нет. Читаемо? Смотря кому.
Да и вообще, мы же эти формулы тут не мелом пишем, а в техе набираем - то есть язык то уже есть, осталось транслятор написать.
Но переписать запись с пределом (и чем угодно) можно.
Я не спорю, что можно. Я спорю, что будет непонятнее, и именно поэтому предлагаю моему исходному собеседнику записать что-то нетривиальное.
Как мы говорим словами? "Предел по n стремящемся к бесконечности суммы по i от 0 до n значений a с индексом 2i и в степени 2"
Когда я такое слышу или читаю, то первым делом записываю это на бумажке в виде значочков «с плохим синтаксисом», потому что замапить эту фразу напрямую сразу на математические концепты практически невозможно. Здесь слишком много шума.
Читаемо? Смотря кому.
Парсеру sexpr'ов, разве что.
Да и вообще, мы же эти формулы тут не мелом пишем, а в техе набираем
Где тоже слишком много шума, кстати. Одна из причин, почему я потратил несколько дней на переход с pdflatex на lualatex для моих писулек — последний поддерживает уникод, и я могу писать прямо Σ, а не \sum.
Ну а в какой-нибудь агде сразу так пишут.
А это математика с исчислением на элементарных множествах (ака "алгебраистика"). У неё свой домен, отсюда её нельзя "улучшить". И, в математике это доказано, всё можно исчислить этим аппаратом. Но чтобы сократить объёмы алгоримов и текста, есть доменные аппараты: геометрии (с множеством систем координат, только популярных - ~25 штук), исчисление интегралами, исчисление векторами, исчисление тензорами. Каждый аппарат - имеет свою грамматику. (Я здесь размещал об этом статью.)
Поэтому математические диалекты не "улучшают", а создают. Под класс решаемых на них задач.
А я в ин-те писал на APL ( он был доступен на БЭСМ 6 и ЕС) курсовой по теории надёжности.
Плюсы:
1) очень легко осваивался
2) мануал - тонюсенькая книжечка, но всеобъемлющая
3) легко отлаживать даже в те годы ( интерпретатор vs пакетная обработка)
4) очень легко модифицировать программу под изменившиеся вводдные
5) быстро считал
Минусы:
1) препы не знали его, смотрели на программу как на китайскую грамоту
Похожая дискуссия была некогда здесть на Хабре про язык J (диалект APL), который правда оперирует зубодробительными рядами стандартных символов, а не специальных. И пришли к тем же выводам, что здесь в комментариях.
Спасибо за обзор. Может, где-то и язык пошёл бы хорошо, но я далёк от таких областей, поэтому останусь со старыми инструментами. APL выглядит довольно нишевым языком, поэтому и нет широкого применения. Вот скажем, как APL поможет в GameDev? Приложения для телефонов? Базы данных? и ещё куча других областей, где лаконичность написания математических формул погоды не делает.
Некоторые утверждения в статье мне не до конца понятны. Вот возьмём:
2. Edge Computing и IoT
Проблема 2025:
Устройства с ограниченными ресурсами (датчики, дроны) требуют лаконичного кода
...
В 10 раз меньше кода, чем на С
Имеется в в виду, что исходный код в 10 раз меньше, чем сишный? Я думал, что IoT работают с бинарным кодом, и не используют интерпретаторы. В таком случае, сравнение размеров исходников некорректное и бессмысленное. Если это утверждение о том, что бинарник в 10 раз меньше, чем от С, то в это крайне сложно поверить без примеров.
APL: математика на стероидах, о которой никто не говорит