Umka: новый статически типизированный скриптовый язык


    Только что вышла первая версия разработанного мной статически типизированного встраиваемого скриптового языка Umka. Он призван сочетать гибкость привычных скриптовых языков с защитой от ошибок типов на этапе компиляции в байт-код. Основная идея языка — Explicit is better than implicit — позаимствована из «дзена Python», однако должна приобрести здесь несколько иной и более очевидный смысл.

    Сколь бы частными и субъективными ни были впечатления, побудившие меня взяться за разработку языка, я надеюсь, что замысел оказался не наивным. Под катом я кратко расскажу о возможностях языка и мотивах его создания.

    Мотивы


    Первым достоинством динамической типизации обычно называют сокращение цикла разработки/отладки и экономию времени программиста. Рискуя вызвать неудовольствие публики, должен признаться, что мой собственный опыт этого никак не подтверждает. Всякий раз после ничтожного исправления своего скрипта обучения нейросети на Python я вынужден дожидаться загрузки Python, NumPy, PyTorch, чтения большого массива данных из файлов, передачи его в GPU, начала обработки — и лишь тогда обнаруживать, что PyTorch ожидал тензор размера (1, 1, m, n, 3) вместо (1, m, n, 3).

    Я охотно признаю, что многие предпочитают динамически типизированные языки по своим личным причинам. Возможно даже, что склонность или неприязнь к динамической типизации — явление того же порядка, что и отношение к оливкам и томатному соку. Попытки объективного исследования этого вопроса приводят, видимо, к неубедительным результатам.

    В то же время популярность TypeScript, введение аннотаций типов в Python, горячие дискуссии на Reddit и Хабре заставляют думать, что фактическое отождествление скриптовых языков с динамически типизированными вовсе не догма, а стечение обстоятельств, и статически типизированный скриптовый язык имеет полное право существовать.

    Так появился язык, названный в честь кота, названного в честь медведя.

    Язык


    Синтаксис языка в целом был навеян Go. С примерами синтаксических конструкций можно познакомиться на странице проекта. При объявлении переменных может использоваться сокращённая запись с выводом типов. Заслуживает внимания отступление от правил Go, сделанное в синтаксисе указателей. Создатели Go сетовали, что буквальное следование примеру C обернулось здесь излишним усложнением синтаксиса и что разумнее было бы ввести постфиксный оператор разыменования указателей вроде паскалевского p^ вместо *p. Именно так и сделано в Umka.

    Транслятор Umka компилирует в байт-код, который затем исполняется стековой виртуальной машиной. Все проверки типов делаются на этапе компиляции. Данные в стеке уже не несут никакой информации о типах. Транслятор поставляется в виде динамической библиотеки со своим API и небольшой «обёртки» — исполняемого файла. Исходный код написан на C99 и переносим на разные платформы. Сейчас выпущены сборки для процессора x86-64 (Windows и Linux).

    Управление памятью пока сделано на основе счётчиков ссылок. Если язык вызовет какой-то интерес и будут попытки его использовать, появится смысл устроить более совершенный сборщик мусора. Язык поддерживает классические составные типы данных (массивы и структуры), размещаемые на стеке, и динамические массивы, размещаемые в куче. Любой классический массив или структуру можно разместить и в куче явным вызовом new().

    Полиморфизм обеспечивается интерфейсами в стиле Go. Понятий класса, объекта и наследования нет.

    Многозадачность построена на понятии «волокон» (fibers) — упрощённых потоков, запускаемых в пределах одной виртуальной машины и явно вызывающих друг друга. По сути это синонимично понятию сопрограмм (coroutines). Поскольку логика применения этих сопрограмм немного отступает от традиции Go и становится ближе к Lua и Wren, есть смысл привести образец кода:

    fn childFunc(parent: std.Fiber, buf: ^int) {
        for i := 0; i < 5; i++ {
            std.println("Child : i=" + std.itoa(i) + " buf=" + std.itoa(buf^))
            buf^ = i * 3
            fibercall(parent)
        }
    }
    
    fn parentFunc() {
        a := 0
        child := fiberspawn(childFunc, &a)    
        for i := 0; i < 10; i++ {
            std.println("Parent: i=" + std.itoa(i) + " buf=" + std.itoa(a))
            a = i * 7
            if fiberalive(child) {
                fibercall(child)
            }
        }    
        fiberfree(child)
    }
    

    Примеры


    В качестве основного примера, демонстрирующего возможности языка, рекомендую посмотреть программу рендеринга трёхмерных сцен на основе обратной трассировки лучей. Здесь весьма органично используются рекурсия, интерфейсы, динамические массивы; несколько более искусственно — многозадачность.

    Примером встраивания транслятора Umka в проект на C может послужить исходный код исполняемой «обёртки» самого транслятора. Там же есть и образец расширения языка Umka внешними функциями на C.

    image
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 97

      +1
      Описание довольно куцее, но как я понял у вас ВМ просто ради ВМ, и всю её можно было бы перевести на clang для нативной компиляции.
        0
        Видимо, вы имеете в виду перенос под LLVM. Вероятно, можно, но зачем? Я хотел иметь маленький и необременительный встраиваемый язык. Go уже и так существует (с весьма громоздким runtime'ом, зашитым в исполняемый файл).
        +2

        Как на счёт Дженериков? Или допустили ту же ошибку, что и авторы Го?

          0
          Будет спрос — к версии 1.0 будут и generic'и. Или было бы интереснее опередить в этом Go 2?
            0
            vlang.io. зачем гнаться за go…
              0
              Коллега уже спрашивал в этом обсуждении, смотрел ли я в сторону V. Повторю свой ответ:
              Смотрел, и очень пристально. Потом понял, что мне просто врут. И про управление памятью, и про быстроту компиляции, и про портирование Doom. Ещё в январе я обнаружил, что управление памятью попросту отсутствует — с катастрофическими последствиями. Никакого прогресса или хотя бы внятной реакции разработчиков я с тех пор не наблюдал.

              Ну и в конце концов, V претендует на нишу Go и Rust, так что у него нет никаких пересечений с Umka, кроме как в синтаксисе, да и то лишь потому, что и Медведников, и я черпали вдохновение в Go.
          +4
          вот объясните мне одну вещь. на текущий момент развития сферы программирования, зачем создавать новый ЯП? вы что хотите чтоб было как в JavaScript-e?
          По моим убеждениям что новый ЯП всегда должен внести в себе абстракцию которая помогает упросить разработку, а не быть штукатуркой под текущий язык.
            +4
            Не очень понял, какой язык я штукатурю. Go? Но ниша совершенно другая, другие и ценности. Я полагаю, статическая типизация полезна во всём, кроме программ в 10 строчек, и её отсутствие практически во всех скриптовых языках удивляет. Дискуссии, на которые я ссылаюсь, заставляют думать, что не меня первого посетило это удивление.
              0

              Вроде же для Go есть приблуда, которая, за счет его быстрой компиляции, позволяет использовать его как скриптовый язык.

                0
                И даёт «Hello World» на 2 Мб? Не всегда это приемлемо. Да и вообще, не замечал какой-то особой быстроты компиляции в Go — ни на своей машине, ни в plagyround'е.
              +1

              Just for fun?

                0
                Интересно изучить реакцию общественности на статическую типизацию в скриптовом языке. Может быть, сделать из этого что-то полезное. Ну и for fun, конечно — без этого не следовало бы и начинать.
                  +1

                  ActionScript 3 был статически нетипизируемым? Или там не было мувиклипов. Файберы близко не валялись.

              –8

              Во первых не статически типизированный, а strong типизированный.
              А во вторых, чем вам lua не угодил? Синтаксисом?

                +9
                Не понял вас. Из Википедии:
                This checking can happen statically (at compile time), dynamically (at run time)
                Так что Umka именно статически типизированный язык, в отличие от Lua. Именно этим Lua мне и не угодил: он откладывает проверку типов до начала исполнения программы.
                  –1

                  А чем тогда не угодил python + mypy + обязательное указание типов на уровне pylint?

                    +10
                    Для той частной задачи, о которой я говорил в посте, это, может быть, и подошло бы. Но во-первых, не находите ли вы странным, что элементарная задача проверки типов решается в итоге такой внушительной связкой инструментов? Там, где по характеру задач уже нужен другой язык (вероятно, статически типизированный), мы продолжаем загромождать Python свойствами, ему совершенно чуждыми.
                    А во-вторых, Umka всё же претендует скорее на нишу Lua и Wren, нежели Python. В качестве встраиваемого языка Python слишком тяжёл.

                      +7
                      Очень круто что защищаете свой продукт, используя весомые аргументы — тащусь от такого подхода. Пишите тоже хорошо, подписался чтобы следить за апдейтами вашей разработки :)
                        0
                        Из минусов это изучение нового ЯП, его синтаксиса, что не так легко
                        Для тех, кто знает питон, думаю выбор очевиден
                          +1
                          Синтаксис, как я уже говорил, на 90 % позаимствован из Go, а тот, в свою очередь, на 50 % из C, так что вряд ли это создаст препятствия. В смысле синтаксиса Python как раз весьма экстравагантен — он чуть ли не единственный из первой десятки языков, полностью порвавший с традицией C.

                          Ну и затем (как я тоже уже говорил) Umka скорее относится к нише Lua, нежели Python.
                            0
                            Так речь же не только про тех разработчиков, которые думают поменять Python на что-то другое. Есть огромное количество разрабов на других ЯП, которые посматривают на Python как на второй ЯП для узких нужд.
                    0
                    Насколько Umka быстр по сравнению с Luajit?
                      0
                      Медленнее. Сейчас это просто интерпретатор, без JIT. Уместнее сравнивать с Python.
                        0
                        А если в сравнении с чистым Lua?
                          0
                          Пока не замерял. Думаю, тоже сколько-то проиграет (Lua вроде бы быстрее Python'а).
                            0
                            Любопытно, что в обработке многомерных массивов Umka обошёл Wren, который считается в среднем чуть ли не быстрее Lua. Но похоже, циклы for и массивы в Wren хромают.
                              0
                              Это серьезный аргумент для дальнейшего развития ЯП!
                            0

                            Кажется, что вашему языку очень подойдет https://github.com/vnmakarov/mir
                            Учитывая степень типизированности байткода

                            +2
                            Перед LuaJIT в плане производительности спасовал даже автор Wren:
                            LuaJIT… is much faster than all of the other languages benchmarked, including Wren, because Mike Pall is a robot from the future.
                            0
                            Теперь, когда есть основа, добавьте еще что-нибудь поинтереснее, например полноценные грамматики в стиле Перл6 или генераторы в стиле Icon. На скриптовых языках очень часто приходится разбирать всякий мусор вроде логов, такие вещи там не повредят.

                            А то просто еще один мелкий скриптовый язык, только теперь со статикой.
                              +4
                              Согласен. По сути, версия 0.1 — это проверка жизнеспособности идеи статической типизации в скриптовом языке. Настало время собирать камни отзывы и думать, чем его расширять. Пока чаще всего меня спрашивали о быстродействии.
                              Кстати, о логах. Удивительно, как люди мирятся с неудобством чтения двоичных логов в языках без статической типизации и классических структур в стиле C. В Umka структуры введены в основном именно ради двоичных логов.
                                +2

                                Я как‐то парсил двоичные журналы размером порядка 100—10 000 МБ, используя не сильно оптимизированный код на Python (struct использовал, но на этом всё). Получил времена исполнения порядка 10 минут на запуск и костыли вида «распарсить журнал, сериализовать результат pickle (чтобы при изменении следующего шага не парсить журнал ещё раз), потом уже что‐то сделать с журналом (со сбросом промежуточных данных на диск, чтобы опять же не повторять шаги)». В итоге плюнул и переписал на так же не особо оптимизированный Rust, время исполнения уменьшилось где‐то на два порядка.


                                Я, правда, сейчас думаю, что если бы я сначала попытался на Python применить некоторые вещи, которые я использовал с самого начала на Rust*, то, возможно, я выиграл бы порядок и на нём, но вряд ли два. Кроме того, я эти вещи использовал с самого начала, потому что попытка на Rust сделать «как на Python» выглядело бы неестественно. Дополнительно, Rust не позволяет мне забывать обработать варианты enum, а это была частая причина перезапуска, когда я писал на Python.


                                Я это к чему: имеющаяся типизация в Rust для меня не только сократила количество перезапусков обработчика журналов, но и сделала более оптимальный код более естественным. Я думаю, подобный результат получился бы на любом языке, на котором есть ADT и классические структуры, просто именно Rust был на слуху, и я на нём уже что‐то для пробы писал.


                                * А именно, не пытаться загнать все журналы в память, чтобы их вместе отсортировать по временной метке, а читать из журналов в правильном порядке, храня в памяти только одну запись из одного журнала и состояние.

                                  –1
                                  Что-то я не понял, чем тут, собственно, помогла типизация. Надо было в Питоне читать буфер и разбирать побайтно, как в Расте и делается, очевидно.
                                    0

                                    Та часть, которая собственно занимается разбором одной записи из одного журнала, в Python и Rust по сути не сильно отличается — придумать какой‐то особенный способ разбора бинарных журналов сложно. Статическая типизация сильно помогала с разбором записей вида «время, тип, данные», где данные зависят от типа — скриптом на LabVIEW я делал из LabVIEW’шного enum Rust’овый enum (до этого — Python’овский), потом Rust не давал мне забыть обработать какой‐то вариант. Данные запихивались в другой enum (который уже ADT, а не просто набор именованных целых чисел) и при создании функции для отладочной печати оного Rust опять не давал мне забыть о том, что в этом enum есть какой‐то вариант, или о том, что этот вариант содержит какое‐то значение.


                                    Ну и плюс в том, что вариант «загнать все данные из всех журналов в один большой список и отсортировать» мне почему‐то показался неестественным. Я не помню точно, о чём именно я думал в то время, но мне либо не пришли в голову варианты реализации на Rust, либо я уже подумывал о таком решении для Python, но решил не заморачиваться, т.к. при использовании CPython в случае отсутствия большого списка я выиграл бы на выделении памяти под него и на его сортировке. А проблемы вида «доступ к любым данным осуществляется только через несколько прыжков по указателям» и «для создания записи нужно выделить память под каждое из полей записи» никуда бы не делись. И эти проблемы в языке с динамической типизацией решить сложно. Возможно, помог бы PyPy с его JIT, но PyPy всё равно не стал бы давать по рукам за забытый вариант enum.

                                  0
                                  По сути, версия 0.1 — это проверка жизнеспособности идеи статической типизации в скриптовом языке.

                                  Конечно жизнеспособно! Уже давно можно написать в начале файла #! env runghc и дальше писать на статически сильно типизированном языке.

                                    +1
                                    Я помню ваши предпочтения :) Но согласитесь, программист на Lua не пересядет на Haskell. Никогда.
                                      0
                                      А почему, интересно? Я просто по себе вижу, что занимался долго теорией типов (как математик), а программировать предпочитаю на Lua, если есть возможность. Haskell при том совсем не возбуждает. Программисты, кажется, в обратную сторону ползут.
                                        0

                                        Пересесть с хаскеля на идрис я бы понял, но на lua — имхо странно. Ну да ладно, у всех свои задачи.

                                        0

                                        Но и в обратную сторону это не факт что происходит.

                                          +1
                                          Насколько я помню, Lua создавался даже не для программистов (не говоря уж о математиках), так что автор побоялся вводить индексацию массивов с нуля и сделал её с единицы, чтобы инженеры-нефтяники не пугались. Думаю, изначально Lua мыслился как Basic новой эпохи.
                                            0
                                            Насколько знаю, он создавался как просто несколько более гибкий конфиг файл.
                                            С того времени как он создавался очень уж много в нём чего поменялось. Никаких метатаблиц изначально и близко не было.
                                            И у математиков-то индексация как раз с 1 идет: Wolfram, R, MATLAB, Julia,…

                                            Это только из-за использования массивов как указателей и арифметики с ними. Когда нет указателей к которым можно напрямую привести массивы — 0-индексация не нужна, точнее ничем не лучше и не хуже чем индексация с 1.
                                      +1
                                      Настало время собирать камни отзывы и думать, чем его расширять
                                      Если вы захотели делать типобезопасный скриптовый ЯП, то может стоит усилить его и с других сторон? Например: добавить элементы ФП, паттерн-матчинг, метапрограммирование и т.д. Но при этом, чтобы он был прост в освоении, быстр и продуктивен.
                                        0
                                        Не спорю. Вопрос лишь в ограниченности ресурсов.
                                          0
                                          Просто стоит предусмотреть эти приятные, но трудоемкие вещи, чтобы потом, при необходимости их воплощения, они выглядели приятно консистентно.
                                          Что-то я кэпом становлюсь…
                                        0
                                        Удивительно, как люди мирятся с неудобством чтения двоичных логов в языках без статической типизации

                                        Согласен, в этой задачи без явной типизации результат не очевиден, но немного спасает ctypes
                                        docs.python.org/3/library/ctypes.html#bit-fields-in-structures-and-unions
                                      0
                                      Круто, буду следить. Автор, не рассматривали добавление механизма расширения записей (структур) в стиле Oberon? Для некоторых задач оно кажется может быть удобнее интерфейсов, и эффективнее технически.
                                        +1
                                        Насколько я понимаю, расширение записей в Обероне — то же самое, что безымянные вложенные структуры в Go. В таком случае, интерфейсы не отменяют, а дополняют вложение структур. Пока этого в Umka нет, но в скором будущем допускается. Если бы я отказался от интерфейсов, меня бы сразу спросили, где виртуальные функции (кажется, спрашивали и Вирта, и ему было неловко).
                                          0
                                          Не, я не против интерфейсов. И вложение структур это немного другое имхо. С вложениями все равно используются интерфейсы. А мне хочется например чтобы в том же Go было простое расширение записей. Пример:
                                          type Node = ^struct {}

                                          type Stmt = ^struct(Node) {
                                          ...
                                          }

                                          type Decl = ^struct(Node) {
                                          ...
                                          }

                                          fn Foo(n: Node) {
                                          ...
                                          }

                                          s := Stmt{}
                                          Foo(s)

                                          Когда структуры данных отражают реальную иерархию, с расширением записей это просто выражается наиболее естественно. С интерфейсами то же самое делать либо не очень удобно: github.com/golang/go/blob/master/src/go/ast/ast.go#L524
                                          либо просто неэффективно в силу того что эта абстракция не бесплатна.
                                          И, кстати, расширение записей не обязательно делать с наследованием реализации и виртуальными методами. Можно просто требовать этой реализации от программиста на этапе компиляции при наследовании.
                                          ps Ну это все так, мысли в слух. Умка просто сильно похож идейно на то, что я сам хотел сделать )
                                            0
                                            Да, кажется, такой трюк с вложенными структурами в Go не проходит: cannot use &s (type *struct { struct {} }) as type *struct {} in argument to Foo
                                        0
                                        Не хватает документации. Или смотреть в Go?
                                          0
                                          По синтаксису — смотреть в Go, с теми небольшими отличиями, которые видны в примерах и в A Tour of Umka на странице проекта. По семантике (например, «волокон») документации действительно не хватает. Буду работать над этим. Кстати, необходима ли полная и строгая спецификация языка — или достаточно чего-то вроде руководства с разбором языка на примерах?
                                          +1
                                          Раз статическая типизация, то что скажете об AngelScript?
                                            0
                                            На практике не использовал, знаю скорее понаслышке и из обзоров. Вроде бы весьма основательный проект, но как-то не видно, чтобы им много пользовались.
                                            0
                                            А вот язык Cat — статически типизированный функциональный Форт!
                                            github.com/cdiggins/cat-language
                                              0
                                              Это прекрасно! Но уже на грани эзотерики.
                                              +1
                                              Смотрели в сторону V Lang? Тоже статически типизированный, быстро компилируеся, по синтаксису похож на Go, можно графику рисовать, и т.д. И есть дженерики :)
                                                +2

                                                Медведников, перелогиньтесь.

                                                  0
                                                  у меня только один аккаунт :)
                                                  0
                                                  Смотрел, и очень пристально. Потом понял, что мне просто врут. И про управление памятью, и про быстроту компиляции, и про портирование Doom. Ещё в январе я обнаружил, что управление памятью попросту отсутствует — с катастрофическими последствиями. Никакого прогресса или хотя бы внятной реакции разработчиков я с тех пор не наблюдал.

                                                  Ну и в конце концов, V претендует на нишу Go и Rust, так что у него нет никаких пересечений с Umka, кроме как в синтаксисе, да и то лишь потому, что и Медведников, и я черпали вдохновение в Go.
                                                    0
                                                    > Потом понял, что мне просто врут.
                                                    > про быстроту компиляции

                                                    time v -o v cmd/v 0.9s
                                                    time v -x64 1mil.v 1.2s


                                                    > Никакого прогресса
                                                    vlib теперь leak free, a в самом компиляторе на 25% меньше. в этом месяце будет 100%.

                                                    > про портирование Doom
                                                    github.com/vlang/doom/blob/master/p_enemy.v
                                                    компилится в p_enemy.o, который можно заменить в си проекте, и всё будет работать

                                                    зачем врать?
                                                      +1
                                                      Про быстроту компиляции: для пользователей время компиляции измеряется от начала разбора исходника до получения исполняемого файла. Если V компилирует только в C, то для пользователей он в принципе не может быть быстрее GCC/MSVC. Пример по-настоящему быстрой компиляции (со своей ценой, разумеется) — это старые версии Delphi.

                                                      Про управление памятью: пока локальные массивы выделяются в куче и вообще никак и никогда не освобождаются — я не могу говорить о прогрессе.

                                                      Про портирование Doom: насколько я вижу, из всех файлов исходников Doom выбирается ровно один (где 3/4 занимают объявления структур и перечислений), конвертируется из C в V, а затем, при компиляции — из V в C. Этим портирование исчерпывается.
                                                        0
                                                        vlib теперь leak free, a в самом компиляторе на 25% меньше. в этом месяце будет 100%.
                                                        Это глубокая альфа. Про сторонние программы тут ни слова.
                                                    0
                                                    if fiberalive(child) {
                                                    fibercall(child)
                                                    }

                                                    А что произойдёт, если волокно уже померло?

                                                      0
                                                      Если вы проверяете, живо ли оно (как в примере), то просто продолжится исполнение вызывающей функции. Если не проверяете — получите сообщение об ошибке и аварийный останов всей виртуальной машины.
                                                      0
                                                      Очень далек от написания компиляторов, почти никогда этим не занимался. Поэтому у меня есть одна мечта, которая никак не может переплюнуть другие по важности.
                                                      Очень хочется встраиваемый скриптовый язык, который гарантирует что все чистые функции выполнятся в нём абсолютно одинаково на всех машинах.
                                                      Пока только пытался начать хотя бы с малого: взял движок Javascript, немного разобрался в его коде, и попытался выпилить оттуда полностью вычисления на float и заменить их на fixed-point. А что дальше потребуется для достижения такой цели, даже пока не представляю.

                                                      Не уверен что применений у такого языка найдется очень много, но для deterministic lockstep стратегий очень хорошо зашло бы.
                                                        0
                                                        Я так понимаю, что для ваших вещественных чисел с фиксированной точкой вы фиксируете и некие «стандартные» алгоритмы вычисления трансцендентных функций, т. е., например, количество членов разложения в ряд — и эти алгоритмы становятся неотъемлемой частью языка.

                                                        Для меня утрата плавающей точки лишает язык половины его ценности. В моём первом игрушечном компиляторе была фиксированная точка, и я с ней намучился. Фильтр Калмана написать так и не смог (хотя суровые инженеры из 60-х и такое, наверное, могли). Точно ли нужна такая жертва? Нельзя ли и тут просто зафиксировать базовые математические алгоритмы? (Не знаю, фиксирует ли их стандарт IEEE; видимо, нет).

                                                        А вот зафиксировать количество бит в целых числах придётся точно.
                                                        +1
                                                        Годнота-то какая!

                                                        Отдельное спасибо за двоеточие в определениях типов. Такая вроде бы мелочь, а решительно улучшает читаемость по сравнению с Го.
                                                          0
                                                          Comment deteted
                                                            0
                                                            А вы рассматривали Nim и возможность писать скрипты на нём?
                                                              0
                                                              Про скрипты увидел впервые. Надо будет почитать повнимательнее.
                                                              0
                                                              Сами по себе программы на golang собираются достаточно быстро, так же существует repl для него. Сборка с некоторыми библиотеками может получится медленнее.

                                                              Существуют и другие (Terra) статически типизированные, встраиваемые, интерпретируемые языки. Возможно кто-то приведёт ещё несколько. Тот же Groovy, можно встраивать в jvm языки.

                                                              Кроме вопросов производительности ещё важным вопросом является наличие пакетов для выполнения распространённых задач, таких как работа с базами данных и так далее, иначе использовать его как независимый язык будет проблематично, кроме основной задачи придётся постоянно переизобретать колесо.

                                                              Что с системой типов, она так же уныла как в go? Например АДТ есть?

                                                              И пожалуй главный вопрос, зачем нужен столь низкоуровневый язык с указателями и размером массивов при инициализации, в то время как уже существует tcc?
                                                                0
                                                                Существуют и другие (Terra)
                                                                Уже нет.
                                                                  0
                                                                  Уже существующие наработки не испаряются от того, что автор его перестал развивать, и его по прежнему можно форкнуть, что будет гораздо логичнее переизобретения велосипеда.
                                                                    0
                                                                    А в чем смысл такого форка? Все равно компилятор придется с нуля писать.
                                                                      0
                                                                      Все равно компилятор придется с нуля писать.
                                                                      Компилятор чего? Автор terra уже что-то написал и это что-то работает. Автор umka(нужно ли это склонять?) в любом случае будет писать код для тех же целей.
                                                                        0
                                                                        Если ТС считает, что Terra (нужно ли это склонять?)) можно форкнуть — то почему бы и нет? Но, кмк, для этого ему много чего в ней должно понравиться.
                                                                +1

                                                                Основные проблемы у всех новых языков, какими бы они хорошими ни были бы — это:


                                                                • Отсутствие библиотек
                                                                • Отсутствие тулинга и инфраструктуры
                                                                • Миллионы строк legacy на других языках и инертность разработчиков

                                                                Конечно, все эти проблемы были есть и будут, кто-то их преодолевает, а кто-то остаётся на задворках индустрии и маргинализуется.


                                                                Взять хоть тот же Rust. Имеет огромный потенциал, и его популярность действительно растёт, но язык до сих пор используется гораздо менее широко чем мог бы. Основные разработчики и сообщество вкладывают огромное количество ресурсов в развитие языка, крейтов, экосистемы, инфраструктуры и тулинга и всё равно, количество вакансий на Rust мизерное по сравнению с другими языками.


                                                                С golang вышло иначе, изначально довольно спорный язык прочно занял свою нишу и выбить его оттуда теперь сложно. Вероятно, тут сложились несколько факторов: простота языка, массированный пиар со стороны Google и усилия по его продвижению, и изначально довольно качественная стандартная библиотека.


                                                                О пиаре go :)

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

                                                                  0
                                                                  Спасибо! В целом согласен с вами, и конечно, мои амбиции и наглость не простираются так далеко, как у создателей V.
                                                                  0
                                                                  Скажу сразу, я не программист, но программированием увлекался с детства. Я специалист в компьютерной графике и иногда использую Python лдя автоматизации процессов. Также когда то немного изучал php для сайтостроения, в школе учил Pascal, в универе Delphi и Assembler. Однажды решил прочитать код C++ по работе, но понял что это уже перебор и точно не мое.
                                                                  Считаю Python самым красивым языком из всех что видел. Одно только отсутствие {} в телах циклов, процедур и т.д. уже считаю гениальным достижением и движением на встречу людям более художественного склада ума. Решение делать блоки табуляцией — прекрасное. Ну и много других приятностей. Кстати, именно синтаксический сахар пайтона считаю гравной причиной его популярности и как следствие он оброс кучей годных библиотек.
                                                                  Но я как дизайнер, всегда хотел пойти дальше на пути к синтаксическому раю и давно мечтал о появлении графического языка, который бы выглядел не как текст а как блок схемы, те самые которые мы изучали на уроках информатики. Еще тогда не понимал, почему если так удобно описывать алгоритм блок схемами не сделать это в самом программировании.
                                                                  И каково же было мое удивление когда я начал изучать игровой движок Unreal Engine и увидел что там реализована моя давняя мечта (Blueprints) и что можно сделать полноценную игру не написав не единой строчки кода! Считаю это большим достижением Епиков и собственно пользуюсь этими плодами, пытаясь создать свою игру.
                                                                  Так вот, я приветствую разработку новых языков, хорошо когда есть конкуренция, но мое пожелание делать язык проще и красивее предшественников и тогда у него будут большие шансы обойти тот же Пайтон. Извините, если лезу не в свое дело. Понимаю что моя компетенция в среде программистов низкая, но я думаю будет полезен взгляд со стороны! Успехов! :)
                                                                    0
                                                                    Одно только отсутствие {} в телах циклов, процедур и т.д. уже считаю гениальным достижением и движением на встречу людям более художественного склада ума. Решение делать блоки табуляцией — прекрасное.
                                                                    Как и во всяком вопросе вкуса, здесь много и сторонников, и противников. Мне понятна мысль сторонников: если мы всё равно используем отступы, то почему бы не сделать их синтаксически значимыми? Однако мне этот метод не по душе. Во-первых, не всегда такое форматирование выглядит самым читабельным — иногда удобнее написать как-то иначе, а синтаксис не позволяет. Во-вторых, возникает путаница со способом отступов: табуляция или пробелы? Эквивалентен ли один символ табуляции четырём пробелам? А двум? В-третьих, появляется довольно бессмысленный оператор pass.
                                                                    Кстати, именно синтаксический сахар пайтона считаю гравной причиной его популярности
                                                                    Я думаю, дело в первую очередь в наличии высокоуровневых конструкций, которых нет в C и т. п. — списков, множеств, словарей и прочего. На одном сахаре далеко не уехать.
                                                                    Но я как дизайнер, всегда хотел пойти дальше на пути к синтаксическому раю и давно мечтал о появлении графического языка, который бы выглядел не как текст а как блок схемы, те самые которые мы изучали на уроках информатики.
                                                                    Таких попыток предпринималось много, но довольно безуспешно. Из относительно живых языков вспоминается только LabView и Simulink. Одно из самых распространённых нареканий к ним — огромная трудность нахождения различий в файлах, а следовательно, и работа систем контроля версий типа Git. Кстати, вы могли заметить, что сейчас наблюдается повсеместный уход от блок-схем к псевдокоду. Не уверен насчёт школьной информатики, но в публикациях эта тенденция очевидна. Может быть, большинству не-художников в принципе легче писать, чем рисовать.
                                                                      0
                                                                      Здесь может быть важно сразу правильно спозиционировать язык. Это «первый» ЯП в работе программиста или «второй» у него же, или «единственный» у не-программиста. Идеальные настройки будут разные…
                                                                        0

                                                                        Вменяемый diff сделать в моём понимании не так уж сложно. В простейшем случае вы просто пишете в текстовом файле в абсолютно разные места сортированные по местонахождению список узлов (буквально ID и тип узла), список логических соединений между узлами, список «логических» расположений (актуально для LabVIEW, где есть вещи вида case structure, внутри которых находится что‐то ещё), список «физических» расположений (т.е. координат), остальные метаданные. При правильно выбранных идентификаторах по простому текстовому diff уже можно будет понять, что поменялось. Не‐текстовое представление немного сложнее, но просто две панели с подсветкой вида «этого узла/проводника нет на другой панели» (плюс «внутри этой структуры есть подсветка») должны сойти в большинстве случаев.


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


                                                                        И все эти проблемы возникают не столько оттого, что в графических языках в принципе нельзя выполнить сравнение/слияние/рефакторинг/кодогенерацию/…, а в том, что, чтобы пользователь мог нормально пользоваться результатом разработчику нужно потратить слишком много усилий. А сами языки ориентированы не на профессиональных программистов, которые такие усилия оценят больше.

                                                                          0
                                                                          И зачем нужно переводить картинки в текст, чтобы потом ещё раз переводить в картинки? Инструмент удобный для непрофессионалов не будет удобен для тех кто пользуется им профессионально.
                                                                            0

                                                                            Где я написал про «перевод текста обратно в картинки»? У меня в первом абзаце две идеи «как бы я сделал формат графического файла так, чтобы простой diff можно понять» и «как бы я делал diff в графическом интерфейсе». Картинку, описанную в последнем предложении первого абзаца, из diff’а и двух сравниваемых файлов получить можно, но, действительно, зачем? Я такого не писал.


                                                                            И, кстати, «непрофессионалы» от такой организации представления данных ничего не потеряют, кроме увеличения объёма файлов.

                                                                              0
                                                                              У меня в первом абзаце две идеи «как бы я сделал формат графического файла так, чтобы простой diff можно понять» и «как бы я делал diff в графическом интерфейсе»

                                                                              Получается, что картинки(на экране) переводятся в текст(исходный код), который обрабатывается diff. Это и есть перевод туда обратно.
                                                                                0

                                                                                И? Я не писал про перевод diff обратно в картинки.


                                                                                А с тем, что картинки будут переведены во что‐то ещё вы ничего не сделаете. И лучше чтобы «что‐то ещё» было именно текстом, из которого получается более‐менее понятный diff, иначе работать с любыми VCS к интерфейсу которого вы не приляпали свой графический diff (кстати, из графических языков кто‐то так вообще сделал? Я максимум что видел — возможность вызвать этот графический diff из того же tortoisehg.) попросту неудобно.

                                                                        0
                                                                        Кстати, именно синтаксический сахар пайтона считаю гравной причиной его популярности и как следствие он оброс кучей годных библиотек.
                                                                        В плане выразительности его обгоняет perl или lisp. Другое дело в том, что незнакомому с программированием человеку будет очень сложно читать выразительный код, поскольку любую выразительность нужно понимать, а разбираться в коде, когда половина файла непонятна — невозможно.

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

                                                                              Самое компактное представление кода, это нечто среднее между записью в всего в одну строку, как это можно сделать например в ruby, когда можно соединить filter, map, reduce, так и в lisp, когда открывающая и закрывающая скобка ставиться на строке с кодом. Python обходится без скобок, так что поставить его можно на это место. K&R тратит кучу строк на закрывающие скобки, другие стили тратят место ещё и на открывающие.

                                                                              Большая часть этого чертежа это либо пустое место, либо провода, самого текста здесь не видно. Я очень сомневаюсь, что даже после рефакторинга это будет так же компактно, как и обычный код.
                                                                              и кстати поиск в блюпринтах прекрасно работает

                                                                              Поиск чего? В обычном исходном коде я могу искать хоть через ide, хоть через grep. Если часто нужно искать что-то специфическое, то можно какой-то скрипт написать.
                                                                                –1
                                                                                Вы во многом правы, но я, знающий Пайтон(на среднем уровне) и любящий этот язык, просто кайфую делая логику игры в блюпринтах. Вы можете, конечно, убеждать меня, что это неудобно и направильно, но факт в том что это удобно и правильно для меня. И вы можете просто принять к сведению этот факт а можете его оспаривать, дело конечно Ваше :)
                                                                                  0
                                                                                  Я очень сомневаюсь, что даже после рефакторинга это будет так же компактно, как и обычный код.
                                                                                  Так цель же не сделать компактно, а сделать удобно для не-программиста.
                                                                                0
                                                                                В плане выразительности его обгоняет perl или lisp
                                                                                Чем выразительнее ЯП, тем труднее его освоить.
                                                                              0
                                                                              Вместе с выпуском 0.2 появился более или менее реалистичный пример встраивания интерпретатора Umka в программу на C.
                                                                                0
                                                                                в вебчик бы его.
                                                                                  0
                                                                                  А что вы с ним хотите сделать? Расскажите.
                                                                                    0

                                                                                    Я вообще сайтики на рнр пишу. Было б круто попробовать на умке http обработать, в базу слазить, json'ом ответить

                                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                Самое читаемое