Чем быстрее космический корабль удаляется от Земли, тем медленнее будет течь время для его пассажиров. Это явление называется замедлением времени.
следует это:
Но для любых инопланетян, проносящихся по нашему небу, она была бы значительно больше из-за путешествия к Земле и обратно из отдалённой звёздной системы на неизбежно более высокой скорости. Они вернулись бы домой на планету, гораздо более старую, чем та, которую покинули — возможно, на столетие или даже больше.
Во-первых, время замедляется, а не идёт вспять. Во-вторых, время-то замедляется для тех кто летит. А значит, когда они вернутся на Землю, то на Земле уже будет далёкое будущее. А вот сами возвращенцы будут себя чувствовать на ней динозаврами.
Это если не копать дальше десятки-двадцатки самых распространённых языков с богатой библиотекой текстов, то какая-то революция есть, согласен. А возьми язык, для которого книг кот наплакал, то приплыли - ИИ генерит дичь довольно часто даже на простых предложениях. И я не говорю о языках, где носителей единицы. Есть языки с миллионами говорящих(например, некоторые языки индейцев: гуарани - ~7 миллионов носителей, кечуа - ~14 миллионов носителей итп) и просьба ИИ перевести на этот язык с английского уже рулетка. Я пробовал. Когда хорошо, а когда и бред.
Поэтому идея хранить какую-то дополнительную информацию о строке в самой строке, в принципе верна и перспективна
Мне тоже так показалось поначалу, но вот стал думать и пришёл к таким двум проблемам. Обе не критичные, но всё-таки они есть. Первая: учёные изучают языки аборигенов(или вымершие языки) и иногда находят что-то новое, начинают описывать новый язык/диалект, которые до этого нигде особо не светился. Кто будет и как быстро этим всем языкам давать новые коды? Вторая: писатели нередко придумывают языки, а фанаты иногда их возводят в ранг "настоящих" и начинают создавать словари общаться на этих языках (примеры: клингон, квенья итп). Фанаты из разных стран, при использовании латиницы, будут выставлять признак языка какой попало: у французов будет стоять французский, у британцев - английский. Что с этим делать? Дополнительный вопрос: что насчёт диалектов? Им тоже будут давать разные коды? Те же британский и американский английский.
По новой спецификации тоже не всё прозрачно. Да, можно отослать к референсной реализации, но описание должно быть тоже однозначным, ибо прыгать туда-сюда, да ещё и искать где же это в реализации не у всех желание есть. Вопросы:
Строка теперь не только начинается с ASCII режима, но и должна заканчиваться в нём
А что если строка вообще не содержит ASCII? Та же "привет". Получается будет внутри в виде "<таблица-кириллицы>привет<таблица ascii>"?
Из рекомендаций:
При конкатенации строки просто соединяются
То есть, если мы будем соединять кучу строк, у нас будет куча лишних маркеров таблиц? Скажем "привет"+"мир" в итоге будет: "<кириллица>привет<ascii><кириллица>мир<ascii>"? Думаю, та же проблема с распуханием памяти будет и в случае форматного создания строк: "sprintf(buffer, "нашли {%d} строк в файле: %s, count, filename)" - каждый "%" будет обрамлён своими переключателями, как и в случае поиска по строке с заменой. Эдак, после череды правок текста, служебная информация будет занимать большую долю в памяти.
При поиске подстроки лучше декодировать кодовые точки и матчиться по ним
Как это сделать? Преобразовать сначала строку в другой формат и потом искать? Или имеется в виде какой-то другой способ? Скажем, как будет выглядеть поиск "<кириллица>мир<ascii>!" внутри строки "<кириллица>приветмир<ascii>!"?
Edit: ещё вопрос по рекомендациям:
При вырезании подстроки надо добавлять в её начало и конец переключатели режима, если в этих местах режим не равен дефолтному
Как быстро определить, что в конце подстроки дефолтный режим? В общем случае, мы могли скопировать кусок строки, начинающийся с ASCII, а по ходу дела в середине подстроки есть включение кириллицы. Для того, чтобы нам понять это всё, надо проверить подстроку от конца и найти последний переключатель, как я понимаю. Это лишний проход по строке на ровном месте. Тут ещё дополнительный вопрос(хотя он несколько надуманный, но может иметь место быть в реальной жизни): а как в новом формате будет работать "substring(str, 6, 5)" - взять 20 байт с 10-го? И как ни странно, но для выведенной на экран полученной подстроки мы, в общем случае, не можем даже примерно предсказать результат. Более того, он может отличаться от запуска к запуску. Причина: код переключения таблиц. Учитывая, что оригинальная строка могла получится в результате череды конкатенаций и форматирований, то количество и положение переключателей могут отличаться. Упрощённо говоря, `substring("приветмир", 8, 6)` и `substring("привет"+"мир", 8, 6)` выдадут совершенно разные подстроки, потому что между "привет" и "мир" во втором случае у нас вклиниваются лишние маркеры кириллицы и ascii.
Читаю и не понимаю, как в итоге это всё должно работать. Вот две цитаты из текста:
Одним байтом переключились на нужную страницу и далее в рамках этой страницы каждый байт со значением до 128 — один символ
Кстати, да, французам с диактрикой и украинцам с их Ґ мы помочь не сможем — придётся им переключаться между страницами, что в худшем случае выливается в 3 байта на одиноко стоящий такой символ вместо 2 у UTF-8
Вопрос 1: Почему, например, тот же Ґ нельзя добавить в блок "украинский" (да и во французском не так много диакритики)? 128 символов для алфавита выглядит вполне достаточно, чтобы нужные символы впихнуть. Или принципиальная позиция: что сейчас с диакритикой, то тут будет кодироваться 3 байтами? Так для украинского эта буква цельная. Иначе мы можем договориться, что в русском блоке не будет "ё" и "й", потому что это на самом деле "е" и "и" с диакритикой. Как вообще определяется что идёт в основной блок, а что в расширенный?
Вопрос 2: мне так кажется, что в большинстве языков с латиницей диакритика есть, в некоторых её даже очень много. Значит, для этих языков размер итогового "текста" вырастет по сравнению с utf8? Например финский или шведский с их ö/ä и ø.
Мой косяк. Я один словарь посмотрел и не увидел, в других не проверил. Но, я всё равно уверен, что отчеств там нет, как и фамилий. Тот же "Петрович" вряд ли там присутствует.
Только что проверил. Сохранил все 5 PDF, поискал обычное имя "Василий". Только в одном словаре это имя встретилось в примере использования слова "брат" - "Благословлял паству брат Василий". То есть, самого Василия нигде нет.
Edit: даже слова "Волга" я найти не смог, только как в примерах использования других слов. Получается, что слово не словарное и, следовательно, "Волжские следопыты" уже под угрозой.
Проверять код должен тот, кто ставил задачу, тогда не будет формальных код-ревью.
Что если если задачи ставятся продакт/прожект менеджером? Этот человек прекрасно понимает нужды пользователей, куда и как развивать продукт и слушает программистов о рамках их возможностей. Но он совершенно не обязан уметь программировать и что-то там понимать в коде. В итоге, кому задачу поручили, сам уже разобьёт её на более мелкие подзадачи, которые можно сделать быстро и начнёт работать потихоньку. Кто должен ревьювить в таком случае PR для вот этой большой задачи?
С очками: появилась подсказка о термине, перевели взгляд на термин, прочитали, вернулись к разговору.
Пока я не понимаю, как это будет работать. Простой вопрос: как очки поймут какой именно термин из диалога надо подсказать? Прервать беседу и проговорить очкам голосом, что вам было не понятно? Правда, такой путь, на мой взгляд, может испортить всю беседу, если периодически прерывать.
Не думаю, что в Вавилон-5 вдохновлялись Снеговым. Есть ещё книга Бестера "Человек без лица", вышедшая в 1952. Там главный герой для защиты от чтения мыслей просит придумать ему прилипчивую песню, чтобы у него в голове крутилась. Читал лет 20-30 назад, но всё ещё пару строк в голове осталось: "Ах ты, камбала, не вобла" (есть тут в цитатах: https://ru.wikiquote.org/wiki/Человек_без_лица_(Бестер) )
Спасибо за обзор. Может, где-то и язык пошёл бы хорошо, но я далёк от таких областей, поэтому останусь со старыми инструментами. APL выглядит довольно нишевым языком, поэтому и нет широкого применения. Вот скажем, как APL поможет в GameDev? Приложения для телефонов? Базы данных? и ещё куча других областей, где лаконичность написания математических формул погоды не делает.
Некоторые утверждения в статье мне не до конца понятны. Вот возьмём:
2. Edge Computing и IoT Проблема 2025: Устройства с ограниченными ресурсами (датчики, дроны) требуют лаконичного кода ... В 10 раз меньше кода, чем на С
Имеется в в виду, что исходный код в 10 раз меньше, чем сишный? Я думал, что IoT работают с бинарным кодом, и не используют интерпретаторы. В таком случае, сравнение размеров исходников некорректное и бессмысленное. Если это утверждение о том, что бинарник в 10 раз меньше, чем от С, то в это крайне сложно поверить без примеров.
Возможно пропустил, но повторное просматривание текста не помогло. Как в CJON кодируются массивы объектов? В примере видел только вариант "массив однотипных элементов примитивов". Скажем, из примера выше про такси куда/откуда/тариф считается, что тариф один. Но например, цена за километр может отличаться от того, что точка два идёт, к примеру, через платный участок дороги и там к тарифу будет ещё доплата. Как это всё кодировать в CJON? В том же JSON просто можно список объектов прикрутить с опциональными полями: "{ways: [ { from: 1, to: 2}, {from: 1, to: 3, extra_pay: 200}], tarif: 2 }". Или такое предлагается всегда вбивать массив extra, даже если оно надо только одному элементу, а отправитель и получатель должны корректно интерпретировать полученный набор? Правда, в этом случае уже не факт, что CJON всегда будет короче JSON
Edit: про вложенные массивы тоже интересно, как их описывать. Если таковые вообще используются. Хотя, вложенные массивы можно реализовать через одномерные при условии, что клиент и сервер знают об этом. Это опять же сводится тогда к указанию типа сообщения и некторому усложнению кода сервера и клиента.
Насколько помню из старых книжек (либо из журнала типа Квант), шаманы во время танца дождя дождя жгли в костре определённые растения. Исследование показало, что в тех растениях после сжигания образуется достаточно много аэрозольных веществ, например, азотистое серебро, которые могут служить катализатором для сбора воды в атмосфере в кучки дождевых облаков. Не знаю, правда, сколько надо сжечь таких растений, чтобы помогло :-)
Edit: не уверен, что именно азотистое серебро было упомянуто, но оно засело в мозгу, как связанное с эффектом "вызова дождя"
Спасибо за уточнение. Но, претензия была к подаче материала в статье.
Во-первых, в этой статье о LIMO вообще ни слова (Ctrl+F не находит ни одного включения, кроме вашего комментария). Во-вторых, если автор приводит сокращенные описания чего-то, то я ожидаю, что это будет самое важное, чтобы зацепить читателя пойти по ссылке и узнать больше. В данном случае, автор сделал упор на том, что только повысится скорость и меньше данных можно подсовывать для изучения. Это никак не подогревает интерес. Откуда простой читатель (я не слежу за всеми ИИ новостями) может почерпнуть о том, на что вы указали? Поэтому, если оценивать именно статью, то она со своей задачей не справляется и убедить меня в правильности своих предпосылок не может.
Насчёт того, что люди не замечают небольшой прогресс соглашусь. Те же генераторы картинок и видео понемногу продвинулись довольно далеко. Но вот с некоторыми позициями в статье вам меня убедить не удалось. Например раздел "Прорывы в обработке данных" заканчивается так:
Вывод прост: да, нехватка данных — это реальная проблема, но она решаема.
В самом разделе вы только упоминаете новые методы, которые всего лишь, цитата: " метод, позволяющий обучаться быстрее при меньшем количестве данных". То есть, проблема нехватки данных пока не решается вообще никак. Нет новых данных и хоть как ускоряй или урезай существующую выборку, новых достижений от ИИ не будет. Может, кто-то что-то когда-то и придумает, но сейчас, судя по всему, воз и ныне там.
Независимость кода от среды. Где бы код на Honey не запустился, результат всегда будет ожидаемый.
Имеете в виду, что исходники на вашем языке можно будет скомпилировать где угодно и получить в итоге от программы один и тот же результат везде?
А какие у вас будут заложены возможности для написания кроссплатформенного кода в таком случае? Макросов нет, значит будет что-то вроде атрибутов в Rust? Или как?
Не понимаю сию логику. Как из этого:
следует это:
Во-первых, время замедляется, а не идёт вспять. Во-вторых, время-то замедляется для тех кто летит. А значит, когда они вернутся на Землю, то на Земле уже будет далёкое будущее. А вот сами возвращенцы будут себя чувствовать на ней динозаврами.
Это если не копать дальше десятки-двадцатки самых распространённых языков с богатой библиотекой текстов, то какая-то революция есть, согласен. А возьми язык, для которого книг кот наплакал, то приплыли - ИИ генерит дичь довольно часто даже на простых предложениях. И я не говорю о языках, где носителей единицы. Есть языки с миллионами говорящих(например, некоторые языки индейцев: гуарани - ~7 миллионов носителей, кечуа - ~14 миллионов носителей итп) и просьба ИИ перевести на этот язык с английского уже рулетка. Я пробовал. Когда хорошо, а когда и бред.
Мне приглянулся Betterbird - европейский форк Thunderbird. Они старые баги патчат и свои фичи добавляют
Мне тоже так показалось поначалу, но вот стал думать и пришёл к таким двум проблемам. Обе не критичные, но всё-таки они есть. Первая: учёные изучают языки аборигенов(или вымершие языки) и иногда находят что-то новое, начинают описывать новый язык/диалект, которые до этого нигде особо не светился. Кто будет и как быстро этим всем языкам давать новые коды?
Вторая: писатели нередко придумывают языки, а фанаты иногда их возводят в ранг "настоящих" и начинают создавать словари общаться на этих языках (примеры: клингон, квенья итп). Фанаты из разных стран, при использовании латиницы, будут выставлять признак языка какой попало: у французов будет стоять французский, у британцев - английский. Что с этим делать?
Дополнительный вопрос: что насчёт диалектов? Им тоже будут давать разные коды? Те же британский и американский английский.
По новой спецификации тоже не всё прозрачно. Да, можно отослать к референсной реализации, но описание должно быть тоже однозначным, ибо прыгать туда-сюда, да ещё и искать где же это в реализации не у всех желание есть. Вопросы:
А что если строка вообще не содержит ASCII? Та же "привет". Получается будет внутри в виде "<таблица-кириллицы>привет<таблица ascii>"?
Из рекомендаций:
То есть, если мы будем соединять кучу строк, у нас будет куча лишних маркеров таблиц? Скажем "привет"+"мир" в итоге будет: "<кириллица>привет<ascii><кириллица>мир<ascii>"? Думаю, та же проблема с распуханием памяти будет и в случае форматного создания строк: "sprintf(buffer, "нашли {%d} строк в файле: %s, count, filename)" - каждый "%" будет обрамлён своими переключателями, как и в случае поиска по строке с заменой. Эдак, после череды правок текста, служебная информация будет занимать большую долю в памяти.
Как это сделать? Преобразовать сначала строку в другой формат и потом искать? Или имеется в виде какой-то другой способ? Скажем, как будет выглядеть поиск "<кириллица>мир<ascii>!" внутри строки "<кириллица>приветмир<ascii>!"?
Edit: ещё вопрос по рекомендациям:
Как быстро определить, что в конце подстроки дефолтный режим? В общем случае, мы могли скопировать кусок строки, начинающийся с ASCII, а по ходу дела в середине подстроки есть включение кириллицы. Для того, чтобы нам понять это всё, надо проверить подстроку от конца и найти последний переключатель, как я понимаю. Это лишний проход по строке на ровном месте. Тут ещё дополнительный вопрос(хотя он несколько надуманный, но может иметь место быть в реальной жизни): а как в новом формате будет работать "substring(str, 6, 5)" - взять 20 байт с 10-го? И как ни странно, но для выведенной на экран полученной подстроки мы, в общем случае, не можем даже примерно предсказать результат. Более того, он может отличаться от запуска к запуску. Причина: код переключения таблиц. Учитывая, что оригинальная строка могла получится в результате череды конкатенаций и форматирований, то количество и положение переключателей могут отличаться. Упрощённо говоря, `substring("приветмир", 8, 6)` и `substring("привет"+"мир", 8, 6)` выдадут совершенно разные подстроки, потому что между "привет" и "мир" во втором случае у нас вклиниваются лишние маркеры кириллицы и ascii.
Понял, спасибо за разъяснение.
Если точнее, то я не понимаю, как всё будет биться на блоки.
Читаю и не понимаю, как в итоге это всё должно работать. Вот две цитаты из текста:
Вопрос 1: Почему, например, тот же
Ґнельзя добавить в блок "украинский" (да и во французском не так много диакритики)? 128 символов для алфавита выглядит вполне достаточно, чтобы нужные символы впихнуть. Или принципиальная позиция: что сейчас с диакритикой, то тут будет кодироваться 3 байтами? Так для украинского эта буква цельная. Иначе мы можем договориться, что в русском блоке не будет "ё" и "й", потому что это на самом деле "е" и "и" с диакритикой. Как вообще определяется что идёт в основной блок, а что в расширенный?Вопрос 2: мне так кажется, что в большинстве языков с латиницей диакритика есть, в некоторых её даже очень много. Значит, для этих языков размер итогового "текста" вырастет по сравнению с utf8? Например финский или шведский с их ö/ä и ø.
Мой косяк. Я один словарь посмотрел и не увидел, в других не проверил. Но, я всё равно уверен, что отчеств там нет, как и фамилий. Тот же "Петрович" вряд ли там присутствует.
Только что проверил. Сохранил все 5 PDF, поискал обычное имя "Василий". Только в одном словаре это имя встретилось в примере использования слова "брат" - "Благословлял паству брат Василий". То есть, самого Василия нигде нет.
Edit: даже слова "Волга" я найти не смог, только как в примерах использования других слов. Получается, что слово не словарное и, следовательно, "Волжские следопыты" уже под угрозой.
Судя по названию словарей, в них точно отсутствуют имена собственные. Выходит, прощай такие вывески как:
Бар "У Петровича"
Музыкальный магазин "Цой жив!"
Лагерь юных натуралистов "Волжские следопыты"
Патриотический летний лагерь "Заветами Ленина"
Идею понял. Спасибо за разъяснения.
Что если если задачи ставятся продакт/прожект менеджером? Этот человек прекрасно понимает нужды пользователей, куда и как развивать продукт и слушает программистов о рамках их возможностей. Но он совершенно не обязан уметь программировать и что-то там понимать в коде. В итоге, кому задачу поручили, сам уже разобьёт её на более мелкие подзадачи, которые можно сделать быстро и начнёт работать потихоньку. Кто должен ревьювить в таком случае PR для вот этой большой задачи?
Пока я не понимаю, как это будет работать. Простой вопрос: как очки поймут какой именно термин из диалога надо подсказать? Прервать беседу и проговорить очкам голосом, что вам было не понятно? Правда, такой путь, на мой взгляд, может испортить всю беседу, если периодически прерывать.
Не думаю, что в Вавилон-5 вдохновлялись Снеговым. Есть ещё книга Бестера "Человек без лица", вышедшая в 1952. Там главный герой для защиты от чтения мыслей просит придумать ему прилипчивую песню, чтобы у него в голове крутилась. Читал лет 20-30 назад, но всё ещё пару строк в голове осталось: "Ах ты, камбала, не вобла" (есть тут в цитатах: https://ru.wikiquote.org/wiki/Человек_без_лица_(Бестер) )
Спасибо за обзор. Может, где-то и язык пошёл бы хорошо, но я далёк от таких областей, поэтому останусь со старыми инструментами. APL выглядит довольно нишевым языком, поэтому и нет широкого применения. Вот скажем, как APL поможет в GameDev? Приложения для телефонов? Базы данных? и ещё куча других областей, где лаконичность написания математических формул погоды не делает.
Некоторые утверждения в статье мне не до конца понятны. Вот возьмём:
2. Edge Computing и IoTПроблема 2025:
Устройства с ограниченными ресурсами (датчики, дроны) требуют
лаконичного кода...
В 10 раз меньше кода, чем на С
Имеется в в виду, что исходный код в 10 раз меньше, чем сишный? Я думал, что IoT работают с бинарным кодом, и не используют интерпретаторы. В таком случае, сравнение размеров исходников некорректное и бессмысленное. Если это утверждение о том, что бинарник в 10 раз меньше, чем от С, то в это крайне сложно поверить без примеров.
Возможно пропустил, но повторное просматривание текста не помогло. Как в CJON кодируются массивы объектов? В примере видел только вариант "массив однотипных элементов примитивов". Скажем, из примера выше про такси куда/откуда/тариф считается, что тариф один. Но например, цена за километр может отличаться от того, что точка два идёт, к примеру, через платный участок дороги и там к тарифу будет ещё доплата. Как это всё кодировать в CJON? В том же JSON просто можно список объектов прикрутить с опциональными полями: "{ways: [ { from: 1, to: 2}, {from: 1, to: 3, extra_pay: 200}], tarif: 2 }". Или такое предлагается всегда вбивать массив extra, даже если оно надо только одному элементу, а отправитель и получатель должны корректно интерпретировать полученный набор? Правда, в этом случае уже не факт, что CJON всегда будет короче JSON
Edit: про вложенные массивы тоже интересно, как их описывать. Если таковые вообще используются. Хотя, вложенные массивы можно реализовать через одномерные при условии, что клиент и сервер знают об этом. Это опять же сводится тогда к указанию типа сообщения и некторому усложнению кода сервера и клиента.
Насколько помню из старых книжек (либо из журнала типа Квант), шаманы во время танца дождя дождя жгли в костре определённые растения. Исследование показало, что в тех растениях после сжигания образуется достаточно много аэрозольных веществ, например, азотистое серебро, которые могут служить катализатором для сбора воды в атмосфере в кучки дождевых облаков. Не знаю, правда, сколько надо сжечь таких растений, чтобы помогло :-)
Edit: не уверен, что именно азотистое серебро было упомянуто, но оно засело в мозгу, как связанное с эффектом "вызова дождя"
Спасибо за уточнение. Но, претензия была к подаче материала в статье.
Во-первых, в этой статье о LIMO вообще ни слова (Ctrl+F не находит ни одного включения, кроме вашего комментария). Во-вторых, если автор приводит сокращенные описания чего-то, то я ожидаю, что это будет самое важное, чтобы зацепить читателя пойти по ссылке и узнать больше. В данном случае, автор сделал упор на том, что только повысится скорость и меньше данных можно подсовывать для изучения. Это никак не подогревает интерес. Откуда простой читатель (я не слежу за всеми ИИ новостями) может почерпнуть о том, на что вы указали? Поэтому, если оценивать именно статью, то она со своей задачей не справляется и убедить меня в правильности своих предпосылок не может.
Насчёт того, что люди не замечают небольшой прогресс соглашусь. Те же генераторы картинок и видео понемногу продвинулись довольно далеко. Но вот с некоторыми позициями в статье вам меня убедить не удалось. Например раздел "Прорывы в обработке данных" заканчивается так:
В самом разделе вы только упоминаете новые методы, которые всего лишь, цитата: " метод, позволяющий обучаться быстрее при меньшем количестве данных". То есть, проблема нехватки данных пока не решается вообще никак. Нет новых данных и хоть как ускоряй или урезай существующую выборку, новых достижений от ИИ не будет. Может, кто-то что-то когда-то и придумает, но сейчас, судя по всему, воз и ныне там.
Имеете в виду, что исходники на вашем языке можно будет скомпилировать где угодно и получить в итоге от программы один и тот же результат везде?
А какие у вас будут заложены возможности для написания кроссплатформенного кода в таком случае? Макросов нет, значит будет что-то вроде атрибутов в Rust? Или как?