Pull to refresh

Comments 56

«пусть назовут мне другой язык с подобными возможностями, который можно использовать в программе в качестве скриптового языка и у которого компилятор и/или виртуальная машина занимает меньше 150 КБ.»

Я могу ошибаться, но как на счет Lua?
Тем более, что синтаксис Lua прост до минимализма, а интерпретатор занимает 50 кб.
Я так понимаю gentee ещё и windows-only. Так что не преимущества языка крайне сомнительны.
Lua?

Import — это возможность выбраться за пределы песочницы. Для встраиваемого языка не всегда допустимо.

Есть ли возможность работать со структурами? Можно ли задавать семантику владения параметров функций?
Хорошо, если кто-нибудь конкретно указал размер интерпретатора у Lua. Я лично сомневаюсь, что он уложится в указанные размеры.

>Import — это возможность выбраться за пределы песочницы. Для встраиваемого языка не всегда допустимо.

Из постановки задачи нужна была возможноcть использовать все системные возможности Windows. Этот язык не аналог JavaScript и цели у него другие. Никто не мешает программе самой генерировать код на основе введенных параметров — в этом случае пользователь вообще не будет что используется какой-то язык.

>Есть ли возможность работать со структурами?

Есть базовые числовые типы, все остальные типы и есть структуры — как в С.

>Можно ли задавать семантику владения параметров функций?

Можно по-подробнее объяснить?
Lua укладывается в 150-200KB.

> Можно по-подробнее объяснить?

Функция readdir возвращает указатель на статическую структуру. Её можно только читать.
Функция malloc возвращает указатель на аллоцированную структуру. Её обязательно потом освобождать (free).

Как эти функции задать с помощью import?
Когда мы используем импорт мы знаем какого типа параметры должны передаваться импортируемой функции и что она возвращает. Если у нас обе функции возвращают указатели, то возвращаемое значение будет описаваться одинаково как uint. Ответственность за корректность работы с полученными данными остается на программисте.
Если мы вызвали где-то импортируемый malloc, то должны вызвать соответствующий free. Другое дело, что можно ввести, например, новый тип «память» и который использует malloc и free. В этом случае переменная будет автоматически освобождать память.
uint? Даже в C адресная арифметика безопаснее. Там нельзя сложить два указателя.

Странно для встраиваемого языка. Обычно встраивают язык из-за слабой выразительности host-языка. Тут же какой-то интерпретируемый ассемблер.
Адресная арифметика по определению не безопасна. Что сложить два указателя, что добавить к указателю какое-нибудь произвольное число — чревато примерно одинаковыми последствиями. Если программист работает с адресной арифметикой, то он должен четко представлять себе, что он делает.
Если уж вы делаете строго типизированный язык, то могли бы обособить указатели в отдельный тип с соответствующими ограничениями. Типизацию нужно использовать по-максимуму.

Ну и подтипы для указателей не помешали бы. Что-то вроде такого:

Import {
subtype DIR pointer;
subtype dirent pointer;

DIR opendir(str);
dirent readdir(DIR);
closedir(DIR);
}

Указатель полученный от opendir нельзя подставить никуда кроме readdir, closedir.
> пусть назовут мне другой язык с подобными возможностями, который можно использовать в программе в качестве скриптового языка и у которого компилятор и/или виртуальная машина занимает меньше 150 КБ.

Jim.
В качестве дополнительного преисущества — отсутствие C-подобного синтаксиса.
ИМХО отсутствие С-подобного синтаксиса — это недостаток, и серьезный.
Расскажите это питону, синтаксис которого в разы превосходит си-подобный по простоте и удобству.
Извините, но это спорно — мне чтобы изучать код на Python требуется сильно напрягаться — непонятно где начинаются/кончаются блоки/методы, особенно если он не влезает на экран по вертикали. Постоянно приходится скроллить, считать отступы (глазами выделить фигурные скобки гораздо легче).
Может это, конечно, дело привычки, но нельзя утверждать так категорично.
Очень понятно, я работаю с си-подобным синтаксисом, но в питоне прекрасно ориентируюсь. При первом взгляде это не так очевидно, но он реально крут. Естественно это мое мнение, но это мнение человека который работает именно с си-подобным синтаксисом.
Вот что-то, а отступы ни разу не приходилось считать. Плюс правило «код функции не должен превышать размера экрана» помогает, даже если ему не следовать буквально, а привести к «уменьшение вложенности должно происходить в том же экране где увеличение». А при большой вложенности коротких операторов код получается короче в разы и на экране помещается больше.
Как длина строк соотносится с размером кода по вертикали?
(Я всегда буду внимательнее читать комментарии.)

Тогда мне ваша проблема не понятна вовсе, можно скриншот или фрагмент кода?
А что, есть такой ЯП, говнокод на котором оказывается легкочитаемым?
Например отсутствием скобочек =) Это избавляет от как минимум от холливара «как ставить фигурные скобки» =)
Как раз это для меня непреемлемо — зависимость от пробелов и табуляций, нарушение принципа «свободного синтаксиса» (или как там это называется, когда пробелы не влияют ни на что и используются только как разделители).
Знаете, я как-то столкнулся с тем что в какой-то makefile поставил пробел не туда, из-за этого получил кучу ошибок. Долго пытался понять в чем дело, и долго плевался когда понял.
Еще пример из той же оперы — в гугловском Go жестко зафиксировали, что открывающая скобка блока должна быть на той же строке что и блок. Еще 40 лет назад это можно было бы понять, но сейчас это смотрится дико.
Ну и кроме того — С-подобный синтаксис это стандарт де-факто. C, C++, C#, Java, ObjectiveC, скриптовые языки для веба… Думаю все вместе около 95% рынка будет. Это как математическая нотация. Она тоже может быть далеко не оптимальна, но вы предложите математику отказаться от значков корней и интегралов и перейти на что-то другое:)
Питон кстати тоже близкий к си-подобным, хотя и своеобразный.

Поставить в makefile/bash-скрипт пробел не туда и получить кучу проблем — происходит постоянно. Поставить в python пробел не туда и получить кучу проблем — у меня такого еще не случалось.
Ввиду того, что последняя новость датируется 2010 годом, можно сделать вывод, что проект более мертв, чем жив.
Тем не менее язык делают свою работу и делает ее хорошо. В язык не нужно добавлять новые плюшечки каждый месяц. IDE, утилиты, документация, библиотеки — это да — требует регулярного обновления.
Этот пост и писался, чтобы посмотреть на критические замечания и понять, что делать дальше.
Мне нравилось программировать на С, но мне всегда не нравилось то, что я не могу просто определить в локальных переменных строку типа str, работать с ней и не думать об ее удалении при выходе из функции.
То есть как это? В C / C++ есть локальные переменные, и память для них автоматически освобождается при выходе из области видимости.

string a = "hello"; // удалится
string *a = new string(); // останется

Если в вашем языке используется только первый метод, как вернуть созданный объект из функции? Он не уничтожится?
Даже более того:
void myfunc()
{
    const char *mystr = "This is a string";
    printf("%s", mystr);
}

mystr нет необходимости удалять в С/C++, этот метод не ведет к утечке
ну так вродеж mystr и сдержимое в стеке будет жить. потому и неутечет ничего.
const char *myfunc()
{
    return "This is a string";
}

printf("%s", myfunc());


пфф, так тоже не утечет, эта строка лежит, как правило, в text секции бинарника, поэтому память под нее выделяется единожды при запуске
Если нужно возвратить любой объект есть атрибут result в описании функции
func str myarr()
{
result = "This is a string"
}
Угловые скобки выкусились

Если нужно возвратить любой объект есть атрибут result в описании функции
func str mystr<result>()
{
result = «This is a string»
}

Пример со строками — это частный случай.
Мм… Какой интересный pascal-style возвращения результата…
Извините, но в чем смысл дублирования информации — вы указываете и <result>, и возвращаемый тип str — разве второй не гарантирует автоматически первое?
Так как язык строгой типизации, то мы решили, что должен быть явно указан тип возвращаемого значения. Если тип не указан, то функция ничего не возвращает.
Например в случае
func str myfunc( str s1, str s2 )
{
return s1 += s2
}

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

Вся .net-платформа (для скриптов хорошо идет, скажем, boo). И подождите мне говорить про то, сколько весит фреймворк: никто же не предлагает использовать эти скрипты за пределами .net-приложений.

Так что оверхед на этот скриптовый язык — нулевой.
> но даже сейчас Gentee является очень удобным языком для использования в других приложениях и в качестве подручного инструмента для быстрого создания небольших утилит

Ну если есть другие приложения — они уже на чем-то написаны, зачем добавлять еще один язык в существующущ систему?

А что касается быстрого написания утилит — опять же, для существующего приложения архитектура обычно и определяет, на чем писать утилиты. А для быстрого «набросать на коленке» вполне тот же bash или perl подойдут.

Или сегодня день такой, или я что-то не понимаю… Сначала статья про Настройка OS Inferno, как-то пинг в никуда, теперь это…
Такие языки, обычно, добавляют для обеспечения возможности писать сценарии. Не такая уж и плохая это возможность. Это просто мы с вами unix'оиды и привыкли внешним образом объединять приложения, но в Windows или просто в некоторых немодульных проектах совсем другая философия. И для них подобные языки — благо. Взять ту же Lua (она, кстати, отличается нетимизированностью, а тут предлагают строгие типы).

Что же до UNIX, то на Bash набрасывать — это то ещё удовольствие (специфичный синтаксис и ограниченные возможности по структурированию; хотя, конечно, активно использую Bash). Вот какой-нибудь более продвинутый в языковом плане Shell очень бы не помешал в повседневной работе. Однако, всё продвинутое в этой области слишком сложно в сравнении с Bash, больше проблем огребёшь, чем удобства. Так что, вопрос открыт до сих пор. Про Perl не знаю, но это точно не shell.
Кроме размера вопрос еще в том, чтобы уложить ВМ и байт-код только в один .exe файл как можно меньшего размера. Мы в свое время смотрели разные языки, но такого, который удовлетворял всем условиям так и не нашли. Может плохо смотрели.
Как раз задача для Форта. Минимальный транслятор несколько килобайт буквально. Программа компилируется по мере ввода. exe-файл — дамп памяти по сути.

Правда для человека, считающего Си-подобный синтаксисом хорошим для скриптовых языков, будет сложновато разобраться с синтаксисом (одна обратная бесскобочная запись выражений чего стоит)Фортом.
Форт — это, конечно, хардкор… если не сбалансируешь скобки, забанит компилятор, если не сбалансируешь стек — компилятор пропустит…
> если не сбалансируешь стек — компилятор пропустит
Это из-за бестиповости. В стековом Cat строгая типизация с выводом типов и там компилятор не пропустит некорректное выражение.
В Факторе стековые диаграммы обязательны и все слова проверяются компилятором.
Да и вроде некоторые форт-компилеры проверяли слова, основываясь на стековой диаграмме слова.
Интересно, только вот примеров маловато (ссылка на сайте не работает)
Совсем не понятно — чем новый ЯП лучше C/C++.
Про вопрос в конце статьи — ответ однозначен: Lua
Тут все про Lua. Я не много о другом. Что касается «delete и init» в объектах. Названия методов режут глаза. Правильней будет так:

create <-> delete
add/insert <-> remove
init <-> finit/finalize (? так и не смог для себя найти подходящий антоним).

Нужно всегда это помнить и стараться не миксовать. Спасибо за статью!

Помню очень давно разбирался Gentee, весьма интересный язык, но весь пакет для сборки и компиляции нужно до ума доводить.
P.S. Я им с переводом на украинский помогал, они мне бесплатный инстальник (всмысле, билдер инстальников) подарили :)
Что такое ТСО?
Сброки мусора нет. Типизация статическая.
Такой оптимизации нет. Есть оптимизация, когда байт-код замешается, где это возможно, на машинный код. Также есть оптимизация по размеру — выкидываются неиспользуемые функции, переменные, типы и т.д.
Only those users with full accounts are able to leave comments. Log in, please.