Одно только отсутствие {} в телах циклов, процедур и т.д. уже считаю гениальным достижением и движением на встречу людям более художественного склада ума. Решение делать блоки табуляцией — прекрасное.
Как и во всяком вопросе вкуса, здесь много и сторонников, и противников. Мне понятна мысль сторонников: если мы всё равно используем отступы, то почему бы не сделать их синтаксически значимыми? Однако мне этот метод не по душе. Во-первых, не всегда такое форматирование выглядит самым читабельным — иногда удобнее написать как-то иначе, а синтаксис не позволяет. Во-вторых, возникает путаница со способом отступов: табуляция или пробелы? Эквивалентен ли один символ табуляции четырём пробелам? А двум? В-третьих, появляется довольно бессмысленный оператор pass.
Кстати, именно синтаксический сахар пайтона считаю гравной причиной его популярности
Я думаю, дело в первую очередь в наличии высокоуровневых конструкций, которых нет в C и т. п. — списков, множеств, словарей и прочего. На одном сахаре далеко не уехать.
Но я как дизайнер, всегда хотел пойти дальше на пути к синтаксическому раю и давно мечтал о появлении графического языка, который бы выглядел не как текст а как блок схемы, те самые которые мы изучали на уроках информатики.
Таких попыток предпринималось много, но довольно безуспешно. Из относительно живых языков вспоминается только LabView и Simulink. Одно из самых распространённых нареканий к ним — огромная трудность нахождения различий в файлах, а следовательно, и работа систем контроля версий типа Git. Кстати, вы могли заметить, что сейчас наблюдается повсеместный уход от блок-схем к псевдокоду. Не уверен насчёт школьной информатики, но в публикациях эта тенденция очевидна. Может быть, большинству не-художников в принципе легче писать, чем рисовать.
Синтаксис, как я уже говорил, на 90 % позаимствован из Go, а тот, в свою очередь, на 50 % из C, так что вряд ли это создаст препятствия. В смысле синтаксиса Python как раз весьма экстравагантен — он чуть ли не единственный из первой десятки языков, полностью порвавший с традицией C.
Ну и затем (как я тоже уже говорил) Umka скорее относится к нише Lua, нежели Python.
Коллега уже спрашивал в этом обсуждении, смотрел ли я в сторону V. Повторю свой ответ:
Смотрел, и очень пристально. Потом понял, что мне просто врут. И про управление памятью, и про быстроту компиляции, и про портирование Doom. Ещё в январе я обнаружил, что управление памятью попросту отсутствует — с катастрофическими последствиями. Никакого прогресса или хотя бы внятной реакции разработчиков я с тех пор не наблюдал.
Ну и в конце концов, V претендует на нишу Go и Rust, так что у него нет никаких пересечений с Umka, кроме как в синтаксисе, да и то лишь потому, что и Медведников, и я черпали вдохновение в Go.
Я так понимаю, что для ваших вещественных чисел с фиксированной точкой вы фиксируете и некие «стандартные» алгоритмы вычисления трансцендентных функций, т. е., например, количество членов разложения в ряд — и эти алгоритмы становятся неотъемлемой частью языка.
Для меня утрата плавающей точки лишает язык половины его ценности. В моём первом игрушечном компиляторе была фиксированная точка, и я с ней намучился. Фильтр Калмана написать так и не смог (хотя суровые инженеры из 60-х и такое, наверное, могли). Точно ли нужна такая жертва? Нельзя ли и тут просто зафиксировать базовые математические алгоритмы? (Не знаю, фиксирует ли их стандарт IEEE; видимо, нет).
А вот зафиксировать количество бит в целых числах придётся точно.
Если вы проверяете, живо ли оно (как в примере), то просто продолжится исполнение вызывающей функции. Если не проверяете — получите сообщение об ошибке и аварийный останов всей виртуальной машины.
Смотрел, и очень пристально. Потом понял, что мне просто врут. И про управление памятью, и про быстроту компиляции, и про портирование Doom. Ещё в январе я обнаружил, что управление памятью попросту отсутствует — с катастрофическими последствиями. Никакого прогресса или хотя бы внятной реакции разработчиков я с тех пор не наблюдал.
Ну и в конце концов, V претендует на нишу Go и Rust, так что у него нет никаких пересечений с Umka, кроме как в синтаксисе, да и то лишь потому, что и Медведников, и я черпали вдохновение в Go.
Насколько я помню, Lua создавался даже не для программистов (не говоря уж о математиках), так что автор побоялся вводить индексацию массивов с нуля и сделал её с единицы, чтобы инженеры-нефтяники не пугались. Думаю, изначально Lua мыслился как Basic новой эпохи.
Интересно изучить реакцию общественности на статическую типизацию в скриптовом языке. Может быть, сделать из этого что-то полезное. Ну и for fun, конечно — без этого не следовало бы и начинать.
На практике не использовал, знаю скорее понаслышке и из обзоров. Вроде бы весьма основательный проект, но как-то не видно, чтобы им много пользовались.
Насколько я понимаю, расширение записей в Обероне — то же самое, что безымянные вложенные структуры в Go. В таком случае, интерфейсы не отменяют, а дополняют вложение структур. Пока этого в Umka нет, но в скором будущем допускается. Если бы я отказался от интерфейсов, меня бы сразу спросили, где виртуальные функции (кажется, спрашивали и Вирта, и ему было неловко).
По синтаксису — смотреть в Go, с теми небольшими отличиями, которые видны в примерах и в A Tour of Umka на странице проекта. По семантике (например, «волокон») документации действительно не хватает. Буду работать над этим. Кстати, необходима ли полная и строгая спецификация языка — или достаточно чего-то вроде руководства с разбором языка на примерах?
Согласен. По сути, версия 0.1 — это проверка жизнеспособности идеи статической типизации в скриптовом языке. Настало время собирать камни отзывы и думать, чем его расширять. Пока чаще всего меня спрашивали о быстродействии.
Кстати, о логах. Удивительно, как люди мирятся с неудобством чтения двоичных логов в языках без статической типизации и классических структур в стиле C. В Umka структуры введены в основном именно ради двоичных логов.
pass.Я думаю, дело в первую очередь в наличии высокоуровневых конструкций, которых нет в C и т. п. — списков, множеств, словарей и прочего. На одном сахаре далеко не уехать.
Таких попыток предпринималось много, но довольно безуспешно. Из относительно живых языков вспоминается только LabView и Simulink. Одно из самых распространённых нареканий к ним — огромная трудность нахождения различий в файлах, а следовательно, и работа систем контроля версий типа Git. Кстати, вы могли заметить, что сейчас наблюдается повсеместный уход от блок-схем к псевдокоду. Не уверен насчёт школьной информатики, но в публикациях эта тенденция очевидна. Может быть, большинству не-художников в принципе легче писать, чем рисовать.
Ну и затем (как я тоже уже говорил) Umka скорее относится к нише Lua, нежели Python.
Для меня утрата плавающей точки лишает язык половины его ценности. В моём первом игрушечном компиляторе была фиксированная точка, и я с ней намучился. Фильтр Калмана написать так и не смог (хотя суровые инженеры из 60-х и такое, наверное, могли). Точно ли нужна такая жертва? Нельзя ли и тут просто зафиксировать базовые математические алгоритмы? (Не знаю, фиксирует ли их стандарт IEEE; видимо, нет).
А вот зафиксировать количество бит в целых числах придётся точно.
Ну и в конце концов, V претендует на нишу Go и Rust, так что у него нет никаких пересечений с Umka, кроме как в синтаксисе, да и то лишь потому, что и Медведников, и я черпали вдохновение в Go.
cannot use &s (type *struct { struct {} }) as type *struct {} in argument to Fooкамниотзывы и думать, чем его расширять. Пока чаще всего меня спрашивали о быстродействии.Кстати, о логах. Удивительно, как люди мирятся с неудобством чтения двоичных логов в языках без статической типизации и классических структур в стиле C. В Umka структуры введены в основном именно ради двоичных логов.