Комментарии 8
К сожалению, большинство новых языков создаются под копирку си-подобных, сохраняя довольно примитивную систему типов: многословную, невыразительную, неудобную настолько, что динамически типизированные языки заняли значительную нишу. Даже сейчас, когда заходит речь либо про новый язык, либо про добавление типизации к существующему - берётся всё тот же подход.
В то же время, существует семейство ML-подобных языков - статически строго типизированных типобезопасных функциональных языков, с следующими наиболее известными примерами: Ocaml, StandardML, Haskell, F#. Так же можно вспомнить Rust - язык вобравший в себя много хороших решений из ML-подобных, но сохранивший си-подобный синтаксис. Эти языки, за исключением двух последних, появились примерно в то же время, что и довольно известные Java, JavaScript, Python, и раньше модно-молодёжных Go, TypeScript и Kotlin, однако почему-то оказались обделены вниманием. Полагаю, причина в том, что за ними не стояла мощная корпорация, рекламирующая их из каждого утюга.
Возможности ML позволяют: опускать определение типов для значений, вплоть до того, что система типов выводит тип аргументов и возвращаемого значения у всех функции и локальных переменных, описание сложных типов типа JSON средствами самого языка. И если семантика json общеизвестна, возможно описать семантику языка программирования, и имея на руках только типы распарсеного кода можно узнать, в каких случаях использует оператор расширения, без длительного чтения документации этого языка. Или можно различать на уровне типов данных изменяемы и неизменяемые коллекции. Это делает код во-первых самодокументируемым, во-вторых делает множество некорректных состояний невозможными, что значительно упрощает как ознакомление с чужим кодом, так и написание собственного, в-третьих позволяет писать типобезопасный код без разных компромиссов, с которыми придётся столкнуться в Go, C#, TypeScript, например, без понижающего преобразования. Скомпилировалось - значит работает, данное выражение возникло как раз благодаря тому, что если программа прошла проверку типов, то не придётся несколько дней потратить на отладку даже после большого рефакторинга. Проверка на ошибки становится явной, благодаря чему забыть проверить результат на наличие ошибки не получится.
Семейство ML-подобных языков достаточно велико, в частности существует Gluon - статически типизированный, встраиваемый язык, вдохновлённый Lua, Haskell и Ocaml.
let io = import! std.io
let array = import! std.array
let int = import! std.int
let { Result, ? } = import! std.result
array.functor.map (\i ->
io.print (match int.parse i with
| Ok v -> show (v + 1)
| Err _ -> "Expected number")) [ "123", "text" ]
Не совсем понял, к чему здесь столь многословная реклама ML. Я думаю, при желании вы могли бы написать об этом отдельный пост. Если вам интересно моё мнение, отчего функциональные языки "обделены вниманием", то дело тут не в корпорациях, а в человеческой психологии. Функциональные языки предполагают совсем иной взгляд на то, что такое программа и программирование, нежели языки императивные. Видимо, большинству людей легче мыслить в понятиях "последовательности указаний", чем в понятиях "вычисления композиции функций". Однако всё это не имеет никакого отношения к теме моей статьи, поэтому вряд ли мне хотелось бы пускаться в пространные дискуссии.
Согласно статье, преимущество Umka перед Lua - возможность находить ошибки во время компиляции, а не во время выполнения. Хорошо, может ли Umka гарантировать, что Null Pointer Exception(либо его местный аналог), не возникнет из-за забывчивости программиста, без добавления проверок в каждую строку? Проверить, что перечисление исчерпывающее, и не забыт ни один вариант? Гарантировать инварианты у сложных состояний, например, что у пользователя есть номер телефона или электронная почта, но не оба сразу? Типизированные коллекции? Или просто упадёт, как и динамически типизированный язык?
А выводы почему ML-подобные языки не столь популярны очень просты. Потому что читать код написанный на ML-подобных языках трудно. И это очень часто решающая причина
Выглядит хорошо. А не думали сделать какой-нибудь отложенный способ освобождения памяти при выходе из некоторой области видимости по аналогии с defer в odin/jai/zig или как флаг autorelease у v?
Маловато документации по multivalue return. Оно работает также как и в Go?
Сообщения об ошибках и ворнинги не выглядят достаточно полезными.
Error /playground.um (2, 16): Unterminated stringWarning /placeholders.um (24, 1): Module th is not used
Warning /tophat_main.um (6, 1): Module window is not usedС одной стороны показывается локация, с другой стороны не очень понятно про что речь. Было б замечательно указывать на конкретные ошибочные символы (по аналогии как Rust делает).
А есть ли (планируется ли) LSP или TreeSitter для языка?
Нужны ли компиляторы чтобы писать приложения на Umka или можно как-то статически всё это дело скомпоновать имея только рантайм умки?
Аналогичный вопрос про кросскомпиляцию с одной системы на другую.
Multitasking based on fibers
А асинхронная обработка будет? Или пока только самому крафтить?
Я так понимаю есть возможность вкладывать типы, но не увидел как такие типы используются. Или это просто множественное определение нескольких типов
type (
DynArr = [][5]int // Dynamic array
String = str // String
MyMap = map[str]real // Map
Quat = struct { // Structure
q: [4]real
normalized: bool
}
Printable = interface { // Interface
print(): int
}
ErrFn = fn(code: int) // Function
)
Есть ли Union типы как в C?
А не думали сделать какой-нибудь отложенный способ освобождения памяти при выходе из некоторой области видимости
Управление памятью в Umka сделано на подсчёте ссылок. Чем не "отложенный способ"? Если на кусок памяти ссылается только одна переменная, то этот кусок будет освобождён как раз при выходе из области видимости переменной. Если ссылок больше -- то память освободится при обрывании последней из них. Метод классический и весьма надёжный. Уж точно лучше того, что было в V, когда я ещё пытался всерьёз воспринимать этот проект.
Маловато документации по multivalue return. Оно работает также как и в Go?
Возврат нескольких значений из функции? Да, как в Go. Но есть тонкости, когда нужно сделать функцию с реализацией на C, которая бы возвращала несколько значений.
А есть ли (планируется ли) LSP или TreeSitter для языка?
Задача большая. Планируется только в Umka 2.
Нужны ли компиляторы чтобы писать приложения на Umka или можно как-то статически всё это дело скомпоновать имея только рантайм умки?
Umka -- интерпретируемый язык, в отличие от Go. Для запуска программы (*.um) нужен интерпретатор (*.exe). Если вы хотите использовать Umka именно как встроенный язык, то интерпретатор может стать частью вашего собственного *.exe. Для этого можно откомпилировать исходники Umka на C вместе с вашими (как это сделано для Tophat), можно носить с собой интерпретатор Umka как *.dll.
А асинхронная обработка будет? Или пока только самому крафтить?
Есть такая задача. Но она тоже, вероятно, уедет на Umka 2.
Я так понимаю есть возможность вкладывать типы, но не увидел как такие типы используются. Или это просто множественное определение нескольких типов
Это просто множественное определение типов. Синтаксис такой же, как в Go.
Есть ли Union типы как в C?
Нет, и неспроста. Если делать объединения именно как в C, то они становятся опасными, поскольку позволяют, например, вручную перезаписать значение указателя. Можно было бы сделать объединения "защищёнными", то есть всегда хранящими и проверяющими описание конкретного типа данных, который в данный момент туда уложен. Но это уже очень похоже на интерфейсы, которые и так в Umka есть.
Возможно я невнимательно читал, однако не заметил чтоб была опубликована ссылка на какое-либо сообщество пользователей umka или tophat. Может есть какой-то чат в telegram?
На сайте tophat в документации не нашел как компилировать проект во что-то отличное от wasm. Я же правильно понимаю, что tophat позволяет создавать кроссплатформенные апки? Как в этом случае сделать билд, например, под android?
Существует ли плагин подсветки синтаксиса и автокомлита для какой-либо IDE или редактора типа VSC, Geany, Kate и/или других?
"Висит" вопрос для кого это. Понятно что ответы типа "альтернатива Lua и Love2D" напрашиваются сами-собой. Однако, для кого? Для чего? Tophat чтоб пошалить на джемах или все же он готов к коммерческим проектам? К публикациям на таких площадках как poki, crazy games, yandex games, google play, app gallery, rustore и других?
Нужна ли проектам поддержка? Голова с руками или донаты?
Пробавали внедрять поодержку Умки в существующие игровые движки? Например в Defold. На мой взгляд для популяризации Umka это идеальный вариант.
Возможно я невнимательно читал, однако не заметил чтоб была опубликована ссылка на какое-либо сообщество пользователей umka или tophat. Может есть какой-то чат в telegram?
Была опубликована ссылка на Discord.
Как в этом случае сделать билд, например, под android?
Компиляция под Android пока ещё в разработке. Сейчас собираем под Windows, Linux, WASM.
Существует ли плагин подсветки синтаксиса и автокомлита для какой-либо IDE или редактора типа VSC, Geany, Kate и/или других?
В дистрибутиве Umka есть подсветка под Sublime Text. Существует также подсветка под Vim и VS Code, но она пока сыровата (можете поинтересоваться в канале Discord). Полноценный Language Server -- отдельная большая задача.
Однако, для кого? Для чего? Tophat чтоб пошалить на джемах или все же он готов к коммерческим проектам? К публикациям на таких площадках как poki, crazy games, yandex games, google play, app gallery, rustore и других?
По меньшей мере, для тех, кого не устраивает Lua. А в остальном -- предлагаю посмотреть и поэкспериментировать самостоятельно. Мы будем только рады замечаниям и по языку, и по фреймворку. Разумеется, степень готовности Tophat меньше, чем Love2D.
Нужна ли проектам поддержка? Голова с руками или донаты?
Голова с руками нужна всегда -- милости просим! Донатами пока не интересовались.
Пробавали внедрять поодержку Умки в существующие игровые движки?
Пока нет.
Публикации
Язык Umka 1.0 и игровой фреймворк Tophat