Вот если посмотреть популярные ЯП — то это дофига работы команд. Годы работы, годы доработок. Т.е. идея может быть вдохновлена одним человеком (на самом деле он эту идею где-то подсмотрел, как правило), а вот разработка языка — это уже только команда.
Получается хороший новый язык не может создать один человек и это всегда годы работы. Т.е. неожиданно новый ЯП возникнуть не может, в отличие от JS-фреймворка типа Vue.
Но бывают и исключения. Вот же наши как-то смогли создать тот же Nemerle вообще без особых затрат, силами энтузиастов. Как так?
S>Получается хороший новый язык не может создать один человек и это всегда годы работы.
Один человек и вправду не может, потому что одной голове нужно все-таки в помощь еще несколько — проверять гениальные идеи. Ибо даже очень правильным идеям требуется, так сказать, "рамка". Обоснование, проверка.
Далее, язык программирования в современном понимании — не только синтаксис ключевых слов, но также runtime (зачастую в форме виртуальной машины), стандартная библиотека, менеджер зависимостей и прочие на первый взгляд не относящиеся к языку вещи. Но без них язык никому не нужен. Поэтому, да, придумать-то очередной язык — самое что ни на есть простое действо. А вот сделать чтоб он был кому-то нужен — это совсем другая история, вот там-то команда и нужна.
Здравствуйте, Shmj, Вы писали:
S>Вот если посмотреть популярные ЯП — то это дофига работы команд
В принципе — да, работы там навалом. Но сильно зависит от возможностей самого языка. Чем проще грамматика и возможности, тем быстрее его сделать даже одному.
Но сам язык — он нафик не нужóн без библиотек — ВОТ ТАМ кроется чёрт. Если сделаешь прозрачную интеграцию с Си (или .NET) — сразу бонусом экономишь десять лет разработки!
Здравствуйте, Shmj, Вы писали:
S>Но бывают и исключения. Вот же наши как-то смогли создать тот же Nemerle вообще без особых затрат, силами энтузиастов. Как так?
Придумать свой язык вообще можно за пару минут, написать для него компилятор, особенно имея ЛЛВМ — можно за несколько человеко-месяцев, даже с инструментарием.
А вот создать сообщество из миллионов кодеров, которые будут для него расширять кодобазу — нереально.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Shmj, Вы писали:
S>Вот если посмотреть популярные ЯП — то это дофига работы команд. Годы работы, годы доработок. Т.е. идея может быть вдохновлена одним человеком (на самом деле он эту идею где-то подсмотрел, как правило), а вот разработка языка — это уже только команда.
S>Получается хороший новый язык не может создать один человек и это всегда годы работы. Т.е. неожиданно новый ЯП возникнуть не может, в отличие от JS-фреймворка типа Vue.
S>Но бывают и исключения. Вот же наши как-то смогли создать тот же Nemerle вообще без особых затрат, силами энтузиастов. Как так?
Прочитайте историю языка. Создание Nemerle оплачено грантом MS. На разработку ядра потрачено около года, если не ошибаюсь, работы около 3-х человек, уровня кандитат наук.
В любом случае ЯП развиваются не с нуля. Взять два моих любимых ЯП. F# — прямой потомок OCaml, clojure — прямой потомок Common Lisp. Последний точно известно создан в одного за два года.
За сто тысяч долларов создам ЯП. Вообще не вижу большой проблемы. Лексер, парсер, это всё уже давно автоматизировано. Хочешь быструю компиляцию — генерируешь llvm байткод, а дальше уже llvm всё скомпилирует в лучшем виде, до С может не дотянешь, но будет близко, если ты дизайн языка под скорость адекватно заточил. Хочешь виртуальную машину — бери Java, там тоже всё будет быстро. Сейчас ещё появляется опция с webassembly, там свои плюсы.
По сути рисуешь грамматику на каком-нибудь antlr, он тебе даёт на выходе AST. Дальше по этому AST надо проверить типы, вот тут я автоматизацию не знаю, вероятно тут основной код и будет сидеть. Возможно сгенерить ещё какие-нибудь AST (если есть макросы). И потом сдампить всё это дело в конечный байткод, который и скормить бэкэнду.
S>Вот если посмотреть популярные ЯП — то это дофига работы команд. Годы работы, годы доработок. Т.е. идея может быть вдохновлена одним человеком (на самом деле он эту идею где-то подсмотрел, как правило), а вот разработка языка — это уже только команда.
Популярными яп стали именно после многолетней работы команд.
Как правило, в фирмах.
Где был С++ до 90-х ?
C# вообще понятно — фирма продвигает свою продукцию.
За Go мощная спина google. Да и авторы имя имеют
Даже паскаль двигала фирма S>Получается хороший новый язык не может создать один человек и это всегда годы работы. Т.е. неожиданно новый ЯП возникнуть не может, в отличие от JS-фреймворка типа Vue.
Может.
Написать язык (по крайней мере первую версию) и компилятор-интерпретатор в одиночку — почти как два байта переслать.
А вот стандартную библиотеку в одиночку никак не поднять.
Где был бы Python без своих многочисленных библиотек ? S>Но бывают и исключения. Вот же наши как-то смогли создать тот же Nemerle вообще без особых затрат, силами энтузиастов. Как так?
Так он и не популярный.
Аналогично Оберону
Два мужика. В свободное от работы время.
Создали язык, написали компилятор, и на нем — операционную систему.
За 2.5 года.
Но без поддержки фирм проект не стал популярным.
Хотя Go стал непосредственным потомком Оберона.
И он стал популярным.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Хотя Go стал непосредственным потомком Оберона.
Как? Еще один?
Мало было камланий секты свидетелей священного Оберона о том, что падший Гослинг все украл в свою Java, так теперь Оберон еще и предтечей Go объявляют. Куда катится этот мир?!!!
LVV>>Хотя Go стал непосредственным потомком Оберона. S>Как? Еще один?
Почему еще ?
Я только его и знаю.
Причем, это не я придумал.
Это написали Керниган и Донован в своей книге
Там обозначено 3 ветки, от которых насследовал ГО:
1. От алгола-60 через виртовские язывки до Оберона-2
2. Си
3. От CSP до Alef
S>Мало было камланий секты свидетелей священного Оберона о том, что падший Гослинг все украл в свою Java, так теперь Оберон еще и предтечей Go объявляют. Куда катится этот мир?!!!
Про Java ничего не знаю.
Но диссер Майкла Франка, который потом реализовали в компиляторе Компонентного паскаля — читал.
С ББ знаком — система уникальная.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
S>>Мало было камланий секты свидетелей священного Оберона о том, что падший Гослинг все украл в свою Java, так теперь Оберон еще и предтечей Go объявляют. Куда катится этот мир?!!! LVV>Про Java ничего не знаю. LVV>Но диссер Майкла Франка, который потом реализовали в компиляторе Компонентного паскаля — читал. LVV>С ББ знаком — система уникальная.
Т.е. вы пропустили обвинения в сторону Java, которые около 20 лет назад любители Паскаля/Оберона выдвигали в сторону Java? Мол, разработчики Java внимательно изучали опыт Oberon-а и Component Pascal, даже кто-то к кому-то ездил в гости (уже не помню кто и куда), а потом бах! Выходит Java с байт-кодом , скомунизженным из Component Pascal, и ни одного благодарственного слова!
S>Т.е. вы пропустили обвинения в сторону Java, которые около 20 лет назад любители Паскаля/Оберона выдвигали в сторону Java? Мол, разработчики Java внимательно изучали опыт Oberon-а и Component Pascal, даже кто-то к кому-то ездил в гости (уже не помню кто и куда), а потом бах! Выходит Java с байт-кодом , скомунизженным из Component Pascal, и ни одного благодарственного слова!
Ну, я их слыхал, но пропустил мимо ушей, как не заслуживающие внимания...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Shmj, Вы писали:
S>Получается хороший новый язык не может создать один человек и это всегда годы работы.
Сколько Kotlin запускали по времени и сколько народу там работало? Потом их поддержал Google и всё завертелось.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Baiker, Вы писали:
B>>Где-то сейчас скулит один Влад — то ли от смеха, то ли от досады...
C>Влад очень радуется, что все заслуги приписали ему.
LVV>>1. От алгола-60 через виртовские язывки до Оберона-2 C>От оно как. То есть это не Алгол-60 важен, а оберон, который сделан на слямзенных из Алгола идеях.
"Огласите весь список, пожалуйста"(с)
Список идей, которые слямзены из Алгола-60.
Вы хотя бы сообщение об Алголе 60 читали ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Вы хотя бы сообщение об Алголе 60 читали ? C>О том, что оберон-прародитель важнее всего, включая те языки, из которых растут ноги самого оберона?
То есть не читал но осуждаешь.
Книжки надо читать, родной.
Тогда сойдешь за умного.
Я читал сообщение еще до твоего рождения.
Алгол-60 — первый язык, синтаксис которого был описан грамматиками Хомского.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, SkyDance, Вы писали:
SD>Далее, язык программирования в современном понимании — не только синтаксис ключевых слов, но также runtime (зачастую в форме виртуальной машины), стандартная библиотека, менеджер зависимостей и прочие на первый взгляд не относящиеся к языку вещи. Но без них язык никому не нужен.
Для нового языка необязательно всё лисапедить с нуля, можно пристроиться к любой существующей инфраструктуре.
Например именно так развивался C++ (он компилировался в C).
Да и сейчас есть много примеров, например Hy — Lisp построенный на рантайме Python.
Создать новый язык в одно рыло вполне возможно меньше чем за месяц, но имеет это смысл только для специализированных задач, так что скорей всего это будет DSL. И при грамотном подходе такой язык вполне может обходить другие языки по целевым метрикам, именно за счёт специализации.
LVV>>Я читал сообщение еще до твоего рождения. C>Не надо так раздуваться, а то лопнешь.
То есть, про Алгол-60 сказать нечего...
И поэтому нечего возразить Кернигану и Доновану, которые проводят генеалогию Go от Алгола-60 до Оберона-2 напрямую
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, so5team, Вы писали:
s> Т.е. вы пропустили обвинения в сторону Java, которые около 20 лет назад любители Паскаля/Оберона выдвигали в сторону Java? Мол, разработчики Java внимательно изучали опыт Oberon-а и Component Pascal, даже кто-то к кому-то ездил в гости (уже не помню кто и куда), а потом бах! Выходит Java с байт-кодом , скомунизженным из Component Pascal, и ни одного благодарственного слова!
Это были не то чтобы обвинения, просто констатация факта, что жаба черпала идеи переносимого байт-кода в pascal-p (не обероне вовсе). Целая статья была на эту тему.
Здравствуйте, LaptevVV, Вы писали:
LVV>И поэтому нечего возразить Кернигану и Доновану, которые проводят генеалогию Go от Алгола-60 до Оберона-2 напрямую
То есть ровно то, что я и сказал. Оберон — промежуточное звено, а не родоначальник.
LVV>>И поэтому нечего возразить Кернигану и Доновану, которые проводят генеалогию Go от Алгола-60 до Оберона-2 напрямую C>То есть ровно то, что я и сказал. Оберон — промежуточное звено, а не родоначальник.
Ты так и не ответил, что Оберон слямзил у Алгола-60.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>>>И поэтому нечего возразить Кернигану и Доновану, которые проводят генеалогию Go от Алгола-60 до Оберона-2 напрямую C>>То есть ровно то, что я и сказал. Оберон — промежуточное звено, а не родоначальник. LVV>Ты так и не ответил, что Оберон слямзил у Алгола-60.
Оберон разве не "улучшенный" Паскаль, которому пришлось дать новое имя из-за отсутствия совместимости? А Паскаль прямой наследник Алгола-60. Немного "незаконнорожденный" потому как у папы слишком тяжелое отношение к законному ребенку — Алголу-68. И он родил вот такого вечного ребенка с названием Паскаль.
Здравствуйте, Shmj, Вы писали:
S>Вот если посмотреть популярные ЯП — то это дофига работы команд. Годы работы, годы доработок. Т.е. идея может быть вдохновлена одним человеком (на самом деле он эту идею где-то подсмотрел, как правило), а вот разработка языка — это уже только команда.
S>Получается хороший новый язык не может создать один человек и это всегда годы работы. Т.е. неожиданно новый ЯП возникнуть не может, в отличие от JS-фреймворка типа Vue.
S>Но бывают и исключения. Вот же наши как-то смогли создать тот же Nemerle вообще без особых затрат, силами энтузиастов. Как так?
В одиночку разработать свой ЯП я считаю возможным. Но трудности возникают когда приходится принять то или иное решение.
Это может быть и касательно синтаксиса, и касательно реализации, или установки неких ограничений.
Совместными усилиями, как мне кажется, результата можно добиться быстрее.
PHP изначально сделал Расмус. Классов там не было, их добавили позднее (в 5-ой версии), когда появилась команда разработчиков. Енумы там появились вообще относительно недавно (версия 8.1). Кстати имена переменных в PHP начинаются с символа $
Квадратные скобки там служат не только для обращения к элементу по индексу, но и для создания массива. Все массивы в PHP ассоциативны (как ключ допустимо и целое число и строка текста).
Я думаю многие задумывались поменять что-то в уже существующих ЯП, с которыми они работали, или что-то туда добавить. А не лучше ли вообще сделать своё? — Примерно такая идея у меня возникла ещё когда я учился в Колледже. Вам же это знакомо?
Я действительно хочу учавствовать в разработке нового ЯП!
Си++ хорош, но слишком переусложнён. Его стандартники делают с ним, то что хотят они — и это не всегда чего хотим мы.
Когда методы определяются внутри самого класса, то класс постепенно разрастается и превращается в монстра великана.
Мне кажется более наглядным, когда в программе данные определяются отдельно от действий над ними.
Я предлагаю создать свой язык вместе. У меня есть идеи, чтобы их обсудить.
Фичи языка:
*- Ячейка — это может быть: локальная переменная, параметр функции, свойство модуля, и т.д.
*- Возможность работать с типом, как со значением. Тип такой ячейки будет $type
*- Имена системных типов начинаются к примеру с символа $ (но это можно указать в конфиге, как и другие начальные символы).
Таким образом добавление системных типов не будет конфликтовать с уже написанным пользовательским кодом.
Тип может быть ключом ассоциативного массива, ведь его можно сравнивать с другим типом как просто значение.
t1 = $int
t2 = $float
t1 <> t2
*- Императивный кусок кода помещается в фигурные скобки и имеет тип $seq (sequence).
do = {
/* expression-list here */
}
Значение типа $seq можно передавать в функцию, присваивать в ячейку, и даже использовать как ключ в ассоциативном массиве.
Это позволит определять языковые конструкции как обычные функции.
Сами по себе фигурные скобки — действий внутри не выполняют без определённой команды. Это называется вычисление по требованию.
* По сути sequence — это как лямбда без параметров.
if_each!
[
{ a == b } : { /* действие 1 */ }
{ /* условие 2 */ } : { /* действие 2 */ }
]
if_first!
[
{ a == b } : { /* действие 1 */ }
{ /* условие 2 */ } : { /* действие 2 */ }
$bool.true : { /* действие иначе */ }
]
Квадратные скобки — массив/мапа. Двоеточие — разделитель в паре ключ-значение.
hint: думаю нужно отделить типы $map от $array
Символ восклицательный знак после ячейки с функцией — применить её к последующему выражению (просто чтобы не писать круглые скобки if_first([])).
if_first — выполняет sequence каждого условия до тех пор, пока не встретит первое правдивое, и тогда выполнит sequence действие из значения пары.
if_each — будет проверять все условия, даже после того как встретит правдивое.
Такая штука ведь нагляднее, чем городить огород из if else if else ?
Функцию вывода на консоль или в файл можно сделать чтобы она принимала sequence. Так она итератором будет вычислять элементы $seq — выражения, и выводить их результат, пока не они не закончатся, или не возникнет ощибка вывода / исключение, при которой оставшиеся выражения не будут вычислены.
@main
do = {
/* c-style function call */
@std.write( {sinus(a), " ", cosine(b)} )
/* Smarty style function call */
{sin(a), " ", cos(b)} |write@std
}
Собачка — начало имени модуля. Файл программы начинается с указания модуля. Далее следуют ячейки модуля — его свойства.
Это декларативная часть. Императивная часть находится внутри фигурных скобок.
При запуске программы выполнится sequence из ячеки do модуля @main
Запятая — разделитель опциональный.
Вертикальная палка перед ячейкой с функцией — применить функцию как метод к результату предшествующего выражения.
Так можно вызывать функции по цепочке слева-направо. Эта идея подсмотрена в PHP библиотеке шаблонов Smarty
a |sinus |write@std(to: file)
/* аналог: */
write@std(sinus(a), to: file)
-- line-comment
a |sinus => x |write_line@std(to: file)
write_line@std( x = sinus(a), to: file )
Оператор "присвоить вправо" => в общем то под вопросом.
Определение структур как типов: команда #struct
Команда #fn определяет функцию
Строчка: pos_2& |scale(0.5) передать яцейку pos_2 как link на ячейку (функция сможет её изменить)
Строчка: pos_1 |scale(2) запись в ячейку #ret в этом случае не изменит ячейку pos_1
Тут будут изменены свойства (x y) у координат в pos_1
Ведь структуры передаются по указателю, как и прочие значения системной категории _compound
Все категории типов (значение $cat) произрастают из базовой _any, включённой во все типы по-умолчанию.
Категория — это просто категория, она не хранит в себе данных. Каждый тип может принадлежать своему набору категорий.
В программе можно проверить их принадлежность. Это может быть полезно при динамической типизации.
При строгой типизации $cat можно использовать как ограничение (например ограничить тип параметра функции).
@sample
squared = #fn(_plain_number: n) { #ret = n*n }
do = {
i = 2 |squared
f = 1.5 |squared
}
@global
/* exposition only */
#cat (
_any /* base category */
_compound /* values of _compound types are passed by pointer */
_plain /* values of _plain types are passed by-value */
_number
_plain_number #includes( _plain _number )
)
_plain_number #refers_to ($int $float)
@lib
complex = #struct( re im )
complex #refers( _number )
Категории можно использовать как обычные значения в программе, их сравнивать, использовать как ключ в $map.
Ведь тип $cat пренадлежит категории _map_key
Естественно пользователь сможет определять и свои категории типов.
( _null / _undefined ) — пример для пустых значений при динамической типизации, возможно это системные категории.
Атрибуты
Например у всех типов есть атрибут initial — это начальное значение ячейки, которое будет использовано при неуказании инициализации.
Доступ к атрибутам происходит через оператор стрелка ->
range = #struct [$type: value_type] ( value_type: from, to )
range->initial(from: 0, to: value_type->max)
/* или */
range->initial.from = value_type->zero
range->initial.to = value_type->max
Что это? Да это же шаблон структуры. Параметр шаблона под именем value_type — тип.
А могло быть и число #struct [$type: Type, $int: N] ()
А мог быть и тип с ограничением $type_refers[_number]
А могла быть и категория с ограничением $cat_includes[_plain]
Собственно нужны ли категории и шаблоны в языке — под вопросом.
Про типизацию и название языка
Мне нравится название ksi-lang (и строгая и динамическая типизация)
ksi-script (только динамическая типизация)
ksi-pl (только строгая типизация)
Я долгое время пилю интерпретатор для ksi-script
Дело в том, что я по разным причинам откладывал разработку и возвращался к ней снова.
В одиночку непросто это.
Назначение языка — для любых целей. Хотя кси скрипт скорее всего для web, и как скриптовый движок в game-dev
p/s
Вопрос: синглтон или набор статик свойств
Ответ: вид значений #nest (это команда определиния типа)
colors = #nest (
red = 0h_ff0000
black = 0
)
/* colors.red |write */
Попытка создания значения типа, который nest only, приводит к получению этого же типа.
К струткуре можно добавить статик свойства командой #add_nest
@sample
color = #struct ( r g b a )
color->initial.a = 255
color #add_nest (
from_code = #fn($int: code) { /* вычисления */ }
red_color = color.from_code(colors.red)
)
Перечисления — они для чёткого набора состояний ячейки.
У элемента перечисления я думаю можно добавить атрибут data, чтобы там что-то хранить.
Атрибут data для каждого элемента перечисления привязан к этому элементу. Сами элементы передаются по значению-номеру (их data не копируется при этом).
align_h = #enum (left center right)
align_h.left->data = /* да тут что угодно, хоть даже структура */
do = {
a = align_h.center
a->data = /* what? can we change it? */
a->name |write_line@std
/* align_h.center->name */
}
Можно сделать атрибуты ->name ->index ->next_wrap (обсуждаемо)
А сомому енуму атрибут align_h->elements
В нюансах все прелести и сложности. Как делать захват локальных ячеек в sequence, который внутри sequence ? Всё ли захватывать, или указывать конкретные, или автоматом по необходимости (как в javascript).
Нужна ли языку константность (read_only ячейки)
$int: (c# = 5, x = 4, y# = c + x)
c += 1 /* ошибка */
Т.е при первом присвоении в имени ячейки окончание — спецсимвол из конфига.
В использовании имени в дальнейшем ридонли символ уже не указывается (чтобы не пришлось переписывать все места вручную, привет ide).
private public protected / friend — отдельная тема. Но я бы не тянул геттеры и сеттеры из си шарп
Наследование — сомнительно, но можно сделать команду #insert_struct
coords = #struct( x y )
game_object = #struct (
name
#insert_struct( coords )
type
)
Это позволит при интроспекции обходить свойства структуры именно в заданной последовательности. (В отличии от наследования, где сперва идёт база)
Доступ к под-объекту — как вариант в индексе [] тип
#cat ( _yes )
range = #options (
_any:
from
to
$cat_exact[_yes]:
exact_from
exact_to
)
r = range(to: 5, exact_to: _yes)
Оно хранит только заданные опции. Чтение из незаданных — вопрос. (или _null / _absent; либо ошибка/exception)
В отличии от $map — имена допустимых ключей явно заданы в определении.
Способ хранения данных — implementation defined
(наверно для $cat_exact можно по битам опции разложить, или придумать свой #bit_set / #flags)
Для системных функций я бы ещё сделал префикс &
&if_first &each &loop &write &switch &catch &throw
Так мы освобождаем имя модуля @std для прочих штук.
--
Для исключений (если да) — атрибуты: e->source.line e->source.column e->source.file
Получится собрать команду разработчиков нового языка программирования в этом году?
Какие идеи вам приглянулись?
pp/s Хотел сперва вкратце написать про ksi, чтож
Даже идею про #actions (аналог интерфейсам не показал)
do = {
c = 0h_e3d7f5 !as[color]
}
color = #struct ($integer_unsigned[8]: r g b)
color #allow_actions( conversion_from[_integer] )
conversion_from = #actions [$hint: from_type] (
as = #fn_params [$type: to_type] (from_type: this) : to_type
)
conversion_from[$int].as[color] = #fn (_integer: this) : color {
[#ret.r #ret.g #ret.b] = (this !make_byte_array: [3 2 1])
}
Ещё можно придумать команду #allow_actions_only, исключающую применение повторябельной #allow_actions
$hint = #variant( $type, $cat ) -- или как ещё это лучше сделать?? Чтобы оно могло принимать и тип, и категорию
Для GC я написал на плюсах optr (он учитывает цикличные линки), но пока его не тестировал сильно (версия-прототип)
И это не GC)
Здравствуйте, Sm0ke, Вы писали:
S>Я действительно хочу учавствовать в разработке нового ЯП!
Тогда давай начнёшь с определения целей.
1. Общая направленность — системный, прикладной на какой-то класс задач.
2. Процедурный, функциональный, что-то посредине.
3. Управление памятью: ручное (как в C, C++), автоматическое полностью (как в Java, C#), на владении ссылками (Rust), смешанное.
4. Уровень фиксации типизации — статическая, динамическая.
5. Уровень жёсткости типизации. Например, насколько разрешён integral promotion и по каким правилам.
Ответы желательно развёрнуто. Это только для разгона, после этого можно будет выходить на второй круг.
S>Си++ хорош, но слишком переусложнён. Его стандартники делают с ним, то что хотят они — и это не всегда чего хотим мы. S>Когда методы определяются внутри самого класса, то класс постепенно разрастается и превращается в монстра великана. S>Мне кажется более наглядным, когда в программе данные определяются отдельно от действий над ними.
Для большинства это менее наглядно, но пусть. Что-то похожее есть в Rust с его impl-ами для типа. Смотрел это? Какие впечатления?
S>Я предлагаю создать свой язык вместе. У меня есть идеи, чтобы их обсудить. S>Фичи языка: S>*- Ячейка — это может быть: локальная переменная, параметр функции, свойство модуля, и т.д.
Смущает термин "ячейка", но пусть.
S>*- Возможность работать с типом, как со значением. Тип такой ячейки будет $type S>*- Имена системных типов начинаются к примеру с символа $ (но это можно указать в конфиге, как и другие начальные символы).
Неееет!!!! Это однозначный путь к бардаку. Хватит нам и споров snake_case/CamelCase/mixedCase. Ты представляешь себе, что будет, если ты будешь подключать файл из одного такого режима к проекту с другим режимом?
Разрабатывая язык, сразу рассчитывай на то, что на нём будут писать что-то на миллион строк и половина авторов будут условными индусами, которым похер на всё, кроме зарплаты.
Подобные элементы синтаксиса обязаны быть жёсткими и безальтернативными!
S>Таким образом добавление системных типов не будет конфликтовать с уже написанным пользовательским кодом.
Для такого давно придумали пространства имён. Но редкие конфликты с автоматической переделкой — не проблема.
S>*- Императивный кусок кода помещается в фигурные скобки и имеет тип $seq (sequence).
Тогда надо сразу сказать, что будет в неимперативных кусках.
S>* По сути sequence — это как лямбда без параметров.
Только с автозахватом из внешнего контекста? Уточни.
S>Символ восклицательный знак после ячейки с функцией — применить её к последующему выражению (просто чтобы не писать круглые скобки if_first([])).
А зачем его вообще писать, ты ведь уже назвал "ячейку"?
S>if_first — выполняет sequence каждого условия до тех пор, пока не встретит первое правдивое, и тогда выполнит sequence действие из значения пары. S>if_each — будет проверять все условия, даже после того как встретит правдивое.
S>Такая штука ведь нагляднее, чем городить огород из if else if else ?
Да. Но сравнимо с тем, если будет явное elif.
S>Функцию вывода на консоль или в файл можно сделать чтобы она принимала sequence. Так она итератором будет вычислять элементы $seq — выражения, и выводить их результат, пока не они не закончатся, или не возникнет ощибка вывода / исключение, при которой оставшиеся выражения не будут вычислены.
Пока что вижу закос под пачку современных языков — что-то среднее между Zig и Ruby.
S>Запятая — разделитель опциональный.
Вместо LF или вообще? Надо уточнить.
S>coords = #struct ( x y )
Я бы делал, что есть набор слов, которые по умолчанию опознаются как ключевые (например if, while, func), а если нужно их сделать идентификаторами, то поставить, например, $ впереди.
S>Ячейка результата вызова функции #ret
По-моему, этот подход в основном признан менее удачным, чем явное return как оператор.
S>Ведь структуры передаются по указателю, как и прочие значения системной категории _compound
Это плохо. Например, математики тебя побьют. struct complex { float real, imag; } — во многих ABI передаётся в двух регистрах. Это эффективно. А ты предлагаешь откатиться обратно.
S>Все категории типов (значение $cat) произрастают из базовой _any, включённой во все типы по-умолчанию. S>Категория — это просто категория, она не хранит в себе данных. Каждый тип может принадлежать своему набору категорий. S>В программе можно проверить их принадлежность. Это может быть полезно при динамической типизации.
Интерфейсы или типажи (traits)? Есть причина вводить новое слово для того же?
S>Категории можно использовать как обычные значения в программе, их сравнивать, использовать как ключ в $map. S>Ведь тип $cat пренадлежит категории _map_key
Вообще обычно говорят более математически — hashable или linearly orderable.
S>Собственно нужны ли категории и шаблоны в языке — под вопросом.
Нужны. Только продумать надо.
Итого
У тебя нет killer feature. Без неё это не выйдет за пределы одного условного диссера.
Здравствуйте, netch80, Вы писали:
N>Тогда давай начнёшь с определения целей.
N>1. Общая направленность — системный, прикладной на какой-то класс задач.
Назначение языка — для любых задач.
И для gui, и для научных расчётов, и как встроенный скриптовый движок приложений/игр.
N>2. Процедурный, функциональный, что-то посредине.
Наверно это микс.
Структура файла:
* Имя модуля
* Декларативная часть (определение ячеек модуля, то есть свойств модуля)
Элемент декларативной части начинается с имени ячейки, или с разрешённой для декларативной части команды.
Ячейка может содержать что угодно. И тип, и функцию, и последовательность выражений (sequence), и просто значение
Таким образом не нужно писать как в си++ using type_alias = int;
А просто type_alias = $int
Аналогично для функций:
fn_alias = other_fn
S>>*- Императивный кусок кода помещается в фигурные скобки и имеет тип $seq (sequence). N>Тогда надо сразу сказать, что будет в неимперативных кусках.
В декларативной части можно:
имя_ячейки = ( /* expression */ )
имя_ячейки = /* команда опеделения */
имя_ячейки = { /* последовательность выражений, тут императивная часть */ }
имя_ячейки /* команда-модификатор */
Вот некоторые команды для создания новых определений: (список не полный)
#struct
#enum
#fn
#nest
#actions // интерфейс, набор методов
N>3. Управление памятью: ручное (как в C, C++), автоматическое полностью (как в Java, C#), на владении ссылками (Rust), смешанное.
Этот нюанс хорошо бы обсудить отдельно.
Для динамических объектов я думаю, что по умолчанию будет реализация optr (автоматическое освобождение ресурсов)
Вообще неплохо-бы предусмотреть способ указания (в самой программе на кси) для желаемого поведения при конкретном случае (для low level штук).
Например чтобы не происходило автоосвобождение большого колличества мелких объектов по отдельности, а пачкой
(ещё когда при закрытии приложении ОС сама освобождает выделенную память)
N>4. Уровень фиксации типизации — статическая, динамическая.
Все Три вида типизации: ~ по трём отдельным обработчикам
Можно сказать — три диалекта языка.
Каждый обработчик может быть как компилятор, так и интерпретатор. А может быть два в одном.
Это уже нюанс реализации обработчика.
N>5. Уровень жёсткости типизации. Например, насколько разрешён integral promotion и по каким правилам.
СИ-шных ошибок в проектировании языка желательно избежать!
Есть шаблонный метод x !as[type] , который вызывается в программе-скрипте явно для преобразования типов.
В квадратных скобках указывается параметр шаблона — тип результата преобразования.
Методы в кси вызываются не через точку (а через воскл.знак перед методом).
Точка служит для обращения к элементам (свойствам).
А методы задаются отдельно в так называемом интерфейсе (команда #actions)
conversion_from = #actions [Source_type] (
as = #fn_params [Target_type] (Source_type: src) : Target_type
implicit_as = #fn_params [Target_type] (Source_type: src) : Target_type
/* implicit_as = as */
/* same params of function */
)
Рассмотрим на примере. Если мы хотим преобразование явного вида из $int в $float тогда в декларативной части:
$float #allow_actions( conversion_from[$int] )
conversion_from[$int].as[$float] = #fn ($int: number) : $float
{ #ret = /* какая-то системная функция */ }
do = {
i = 5
f = (i !as[$float])
}
Если действие implicit_as не задано, то неявное преобразование запрещено обработчиком.
Но мы можем при желании его задать одной строчкой:
Короче сделать алиас из уже написанной функции implicit_as = as
В этом случае будет работать неявное преобразование. Программист это может контролировать сам в том числе и для своих типов.
N>Ответы желательно развёрнуто. Это только для разгона, после этого можно будет выходить на второй круг.
S>>Мне кажется более наглядным, когда в программе данные определяются отдельно от действий над ними. N>Для большинства это менее наглядно, но пусть. Что-то похожее есть в Rust с его impl-ами для типа. Смотрел это? Какие впечатления?
Надо будет посмотреть как там impl в Rust
S>>*- Имена системных типов начинаются к примеру с символа $ (но это можно указать в конфиге, как и другие начальные символы).
N>Неееет!!!! Это однозначный путь к бардаку. Хватит нам и споров snake_case/CamelCase/mixedCase. Ты представляешь себе, что будет, если ты будешь подключать файл из одного такого режима к проекту с другим режимом?
N>Подобные элементы синтаксиса обязаны быть жёсткими и безальтернативными!
Согласен с этим утверждением. Я не точно сформулировал мысль.
Начальные символы для системных штук указываются в конфиге обработчика, а не пользовательского проекта.
Или жестко заданы внутри компилятора (это нюанс реализации, да)
S>>coords = #struct ( x y )
N>Я бы делал, что есть набор слов, которые по умолчанию опознаются как ключевые (например if, while, func), а если нужно их сделать идентификаторами, то поставить, например, $ впереди.
#struct — это системная команда.
Какой начальный символ для команд, а какой для системных типов лучше подобрать?
Я предлагаю для команд #
Для типов $
Для функций &
Это просто строчки в конфиге обоаботчика. С другой стороны нужен общепринятый формат)
Ключевые слова? keywords — нужны ли они вообще в кси? Если да, то какие?
Можно сделать bitwise методы для integer types (выглядят как именованные операторы bit_xor, bit_and, bit_shift +1 -1)
S>>Таким образом добавление системных типов не будет конфликтовать с уже написанным пользовательским кодом.
N>Для такого давно придумали пространства имён. Но редкие конфликты с автоматической переделкой — не проблема.
В кси — модули. Хотя пространства имён возможно тоже понадобятся (или нет). Есть #nest для nested штук. @sys.int просто $int писать не так длинно @sys.write_line или &write_line
S>>* По сути sequence — это как лямбда без параметров. N>Только с автозахватом из внешнего контекста? Уточни.
Да, с автозахватом (closure)
Мб добавить возможность задания seq без захвата локального внешнего контекста через конструкцию #{ } ?
S>>Символ восклицательный знак после ячейки с функцией — применить её к последующему выражению (просто чтобы не писать круглые скобки if_first([])).
N>А зачем его вообще писать, ты ведь уже назвал "ячейку"?
Но тут нюанс с !else пока не решён)
S>>Запятая — разделитель опциональный. N>Вместо LF или вообще? Надо уточнить.
LF и запятая — опциональные разделители, хотя LF оно как WHITEPSACE
А запятая с проверкой в парсере.
S>>Ячейка результата вызова функции #ret N>По-моему, этот подход в основном признан менее удачным, чем явное return как оператор.
Добавить команду #return не проблема)
S>>Ведь структуры передаются по указателю, как и прочие значения системной категории _compound
N>Это плохо. Например, математики тебя побьют. struct complex { float real, imag; } — во многих ABI передаётся в двух регистрах. Это эффективно. А ты предлагаешь откатиться обратно.
Значит нужна возможность задать для структуры как она передаётся ( _by_value или _by_pointer )
Например через категории типов.
@math
complex = #struct ( $float: real imag )
complex #refers ( _by_value ) // привязали категорию для типа
S>>Все категории типов (значение $cat) произрастают из базовой _any, включённой во все типы по-умолчанию. S>>Категория — это просто категория, она не хранит в себе данных. Каждый тип может принадлежать своему набору категорий. S>>В программе можно проверить их принадлежность. Это может быть полезно при динамической типизации.
N>Интерфейсы или типажи (traits)? Есть причина вводить новое слово для того же?
Нет, это не интерфейсы. Про интерфейсы я ответил выше как #actions
Категории ещё могут быть абстрактными (с запретом к привязки для типов)
Для специальных значений, или сигналов об ошибке.
S>>Собственно нужны ли категории и шаблоны в языке — под вопросом. N>Нужны. Только продумать надо.
S>>Категории можно использовать как обычные значения в программе, их сравнивать, использовать как ключ в $map. S>>Ведь тип $cat пренадлежит категории _map_key
N>Вообще обычно говорят более математически — hashable или linearly orderable.
Это похоже на набор методов для работы с данными.
Стандыртные наборы действий (интерфейсы) для системных типов необходимо определить.
Желательно совместными усилиями, а не в одиночку.
N>Итого N>У тебя нет killer feature. Без неё это не выйдет за пределы одного условного диссера.
А как-же работа с типами как с обычными значениями?
Вместо плюсовых <type_traits> std::is_same_v<> и using type =
А как же встроенная система атрибутов. Позволяющая в том числе и рефлексию (интроспекцию).
Работать со списком/мапой элементов перечисления, как с обычным массивом.
Так-же со списком свойств структуры / неста.
Атрибут type->name текстовая строка.
Возможность добавлять пользовательские конструкции над seq как функции.
--
Постораюсь ответить на вопросы, которые ещё остались неотвечены.
То что я написал — моё приблизительное представление.
На основе этого можно же сделать better language, как бы он не назывался
Здравствуйте, Sm0ke, Вы писали:
N>>1. Общая направленность — системный, прикладной на какой-то класс задач. S>Назначение языка — для любых задач.
Уже не бывает. Надо определиться.
S>И для gui, и для научных расчётов, и как встроенный скриптовый движок приложений/игр.
N>>2. Процедурный, функциональный, что-то посредине.
S>Наверно это микс.
S>Структура файла: S>* Имя модуля S>* Декларативная часть (определение ячеек модуля, то есть свойств модуля)
S>Элемент декларативной части начинается с имени ячейки, или с разрешённой для декларативной части команды. S>Ячейка может содержать что угодно. И тип, и функцию, и последовательность выражений (sequence), и просто значение
S>Таким образом не нужно писать как в си++ using type_alias = int; S>А просто type_alias = $int S>Аналогично для функций: S>
S>fn_alias = other_fn
S>
Ничего из этого пока что не даёт функциональный язык. Вижу процедурщину в чистом виде. Это не плохо, но это характерно.
S>>>*- Императивный кусок кода помещается в фигурные скобки и имеет тип $seq (sequence). N>>Тогда надо сразу сказать, что будет в неимперативных кусках.
S>В декларативной части можно: S>
S>имя_ячейки = ( /* expression */ )
S>имя_ячейки = /* команда опеделения */
S>имя_ячейки = { /* последовательность выражений, тут императивная часть */ }
S>имя_ячейки /* команда-модификатор */
S>
Это просто вынесенная вперёд часть инициализаций, ничего пока особенного.
N>>3. Управление памятью: ручное (как в C, C++), автоматическое полностью (как в Java, C#), на владении ссылками (Rust), смешанное.
S>Этот нюанс хорошо бы обсудить отдельно.
Не "отдельно", а с него надо начинать.
Потому что если язык вообще позволяет произвольные игры с указателями, типа сохранить после удаления объекта, то нет смысла и запрещать их произвольное создание.
Язык с ManMM это переносимый ассемблер (даже если это C++). Язык с AMM это то, что требует как минимум unsafe-слоя для реализации и связи с нижними слоями.
Попытка их совместить — см. про коня и лань.
S>Вообще неплохо-бы предусмотреть способ указания (в самой программе на кси) для желаемого поведения при конкретном случае (для low level штук). S>Например чтобы не происходило автоосвобождение большого колличества мелких объектов по отдельности, а пачкой
Это речь про GC. Разные стили GC могут выбираться по реализации, но в этом нет ничего нового.
S>(ещё когда при закрытии приложении ОС сама освобождает выделенную память)
N>>4. Уровень фиксации типизации — статическая, динамическая.
S>Все Три вида типизации: ~ по трём отдельным обработчикам S>Можно сказать — три диалекта языка.
S> Динамическая типизация ~ ksi-script S> Строгая типизация ~ ksi-pl S> динамическая + строгая ~ ksi-lang
Почему это динамическая+строгая?
S>Каждый обработчик может быть как компилятор, так и интерпретатор. А может быть два в одном. S>Это уже нюанс реализации обработчика.
N>>5. Уровень жёсткости типизации. Например, насколько разрешён integral promotion и по каким правилам.
S>СИ-шных ошибок в проектировании языка желательно избежать!
Только вначале разобраться, что там ошибки, что — последствия ограничений реализации, а что — полезные фишки, облегчающие (обычно) жизнь программисту.
S>Есть шаблонный метод x !as[type] , который вызывается в программе-скрипте явно для преобразования типов.
Всегда? Безопасные (без изменения характера типа и без потери точности) расширения вообще не допускаются?
S>Рассмотрим на примере. Если мы хотим преобразование явного вида из $int в $float тогда в декларативной части: S>
S>$float #allow_actions( conversion_from[$int] )
S>conversion_from[$int].as[$float] = #fn ($int: number) : $float
S>{ #ret = /* какая-то системная функция */ }
S>do = {
S> i = 5
S> f = (i !as[$float])
S>}
S>
Я не понял, к чему '!' впереди "!as". В остальном — понятно на локальном уровне. Но мне кажется, что безусловный запрет расширяющих конверсий это диверсия.
Если нужно, их следует запрещать для определённых контекстов. Но я думаю, это будет редко использоваться.
Кстати, int->float для стандартных int32 и binfloat32 это не расширяющая конверсия, возможна потеря точности.
N>>Подобные элементы синтаксиса обязаны быть жёсткими и безальтернативными!
S>Согласен с этим утверждением. Я не точно сформулировал мысль. S>Начальные символы для системных штук указываются в конфиге обработчика, а не пользовательского проекта. S>Или жестко заданы внутри компилятора (это нюанс реализации, да)
Скорее жёстко, тут нечего конфигурировать.
S>#struct — это системная команда. S>Какой начальный символ для команд, а какой для системных типов лучше подобрать? S>Я предлагаю для команд # S>Для типов $ S>Для функций &
А зачем выделять типы и функции? Это необычно.
S>Это просто строчки в конфиге обоаботчика. С другой стороны нужен общепринятый формат) S>Ключевые слова? keywords — нужны ли они вообще в кси? Если да, то какие?
У меня такое впечатление, что вы их называете командами.
S>Можно сделать bitwise методы для integer types (выглядят как именованные операторы bit_xor, bit_and, bit_shift +1 -1)
Можно.
S>>>Таким образом добавление системных типов не будет конфликтовать с уже написанным пользовательским кодом.
N>>Для такого давно придумали пространства имён. Но редкие конфликты с автоматической переделкой — не проблема.
S>В кси — модули. Хотя пространства имён возможно тоже понадобятся (или нет).
Если хочется чего-то выше уровня песочницы — понадобятся, иерархические.
S>>>* По сути sequence — это как лямбда без параметров. N>>Только с автозахватом из внешнего контекста? Уточни. S>Да, с автозахватом (closure)
Если не регулируется — могут жаловаться.
S>Мб добавить возможность задания seq без захвата локального внешнего контекста через конструкцию #{ } ?
Тогда в ней можно и думать писать явный список для захвата.
S>Ключевых слов в кси стараюсь вообще избегать.
Совсем избежать не получится.
Префиксовать все — возможно, есть такие стили, но обычно пользователи жалуются.
S>К примеру можно определить системную функцию &do_while цикл с пост-условием
Есть такие стили, да. Можно посмотреть на Common LISP как образчик. Там макрами транслируется часть конструкций в другой код.
S>Значит нужна возможность задать для структуры как она передаётся ( _by_value или _by_pointer )
Да. И умолчание скорее by value.
N>>Интерфейсы или типажи (traits)? Есть причина вводить новое слово для того же?
S>Нет, это не интерфейсы. Про интерфейсы я ответил выше как #actions S>Категории ещё могут быть абстрактными (с запретом к привязки для типов) S>Для специальных значений, или сигналов об ошибке.
Ближе к типажам, наверно.
N>>Вообще обычно говорят более математически — hashable или linearly orderable. S>Это похоже на набор методов для работы с данными. S>
Ну да, дальше определяется, что например hashable должен поддерживать hash(), а linearly orderable — сравнение как минимум на "меньше" (и полезно на "равно", судя по <=> в новом C++).
S>Стандыртные наборы действий (интерфейсы) для системных типов необходимо определить. S>Желательно совместными усилиями, а не в одиночку.
N>>Итого N>>У тебя нет killer feature. Без неё это не выйдет за пределы одного условного диссера.
S>А как-же работа с типами как с обычными значениями? S>Вместо плюсовых <type_traits> std::is_same_v<> и using type =
По сравнению с плюсами — может быть. По сравнению с более новыми языками — нет.
S>А как же встроенная система атрибутов. Позволяющая в том числе и рефлексию (интроспекцию).
Аналогично.
Глубоко изучи для начала Rust.
S>Возможность добавлять пользовательские конструкции над seq как функции.
S>--
S>Постораюсь ответить на вопросы, которые ещё остались неотвечены.
S>То что я написал — моё приблизительное представление. S>На основе этого можно же сделать better language, как бы он не назывался
Можно. Но без хорошей теоретической подготовки шансы около нуля.
Создать — это лишь меньшая часть дела. При этом не умаляю сложности, объемности и дороговизны этой задачи.
Но дальше в силу вступает несколько факторов, чтобы этот язык имел популярность: PR/маркетинг, спрос на язык (то есть ниша) и удача. Все!
Посмотри на свежие популярные языки: за всеми стоят гиганты. А это, соотвественно, деньги и пиар. Конечно люди начнут пользоваться. И техническая составляющая тут будет вторична. Go, Swift, Dart, Flutter, не говоря уже про C# и Джаву. Да тот же Котлин.
То есть ЯП — тот же продукт. Впаривают его и пипл хавает.
К системной категории _any относятся все типы.
А системная _struct назначена только на типы, которые сформированы командой #struct
Ячейка с функцией other_fn в примере выше может принимать только структурные значения как параметр.
Как будет фактически работать у ячейки ограничение по категориии — это уже вопрос реализации
Это может быть специальная динамическая run-time обёртка,
Или некий compile-time аналог шаблонов c++
— case 2 —
Режим ksi-script не допускает накладывать ограничения на тип ячейки
some_fn = #fn (x y factor) {}
Динамическая типизация в нём позволяет устанавливать для ячейки значения любых типов
Эти типы могут быть отличны от типа начального значения, конечно же
— case 0 —
И наконец режим ksi-lang — это микс из (script + pl)
Тип ячейки можно указывать
Но если не указать, то ограничение типа ячейки будет по категории _any
Надо бы решить какой case реализовать приоритетнее в первую очередь.
Что перед этим ещё надо сделать.
Это были три режима обработчика
Хотя по необходимости можно сделать и отделные, более компактные, обработчики для некоторых case -ов
Вид обработки может быть: интерпретация, компиляция, трансляция
Думаю стоит начать с чего-то одного
о парсере
Парсер неплохо бы сделать через общую библиотеку, которая не зависит от режима обработчика
Я начал писать свой парсер таким образом, чтобы правила разбора писались в самом си++ декларативно
Для AST нодов я сделал свой pool, который освобождает ноды пачками сразу. Ноды аст с тривиальными деструкторами.
В этом пуле Нет возможности ноды возвращать по одному в пул как свободные, ведь это бы усложнило код в либе пула.
Думаю не так важно привязан нод к дереву, или нет. Главное чтобы деструктор пула был вызван после деструктора всего AST
--
Я пробовал разобраться в ANTLR, который вроде был кодогенератором на java
Есть моменты, что мне не понравились:
— придётся тратить время на изучения структур, которые оно генерит, как обходить их аст, как они там устроены
— при написании термов придётся тратить время на тесты и исправления недочётов, исходя из особенностей синтаксиса описания АНТЛР термов
— зависить от изменений в новых версиях внешней чужой тулзы, не особо охота
Направленность
1. Общая направленность — системный, прикладной на какой-то класс задач.
Назначение языка — для любых задач.
Уже не бывает. Надо определиться.
Хорошо, вот примерные цели применения (таргеты)
В зависимости от режима
ksi-script:
web аналог php
скриптовый игровой движок
простенькие desktop проги
maybe ~ для ui разметки
ksi-pl:
компиляция
научные расчёты
maybe ~ аналог си плюс плюс
--
Ещё немного инфы про обработчик.
Вот в интерпретаторе php есть расширения (extensions)
Они добавляют системные функции, системные типы, константы, интерфейсы, и пр.
Некоторые примеры расширений php:
для работы с СУБД mySQL
для работы с изображениями GD
для работы с http запросами CURL
Неплохо бы в обработчик ksi добавить систему расширений.
На чём писать эти расширения — на плюсах, или даже на самом кси
Почему бы не помечтать
Какие именно понадобятся расширения обработчика — отдельный вопрос
Я не призываю как либо повторять путь php
Здравствуйте, DiPaolo, Вы писали: DP>Посмотри на свежие популярные языки: за всеми стоят гиганты. А это, соотвественно, деньги и пиар. Конечно люди начнут пользоваться. И техническая составляющая тут будет вторична. Go, Swift, Dart, Flutter, не говоря уже про C# и Джаву. Да тот же Котлин.
Так есть же исключения
php к примеру
Мне кажется, что первоочередное — это качество продукта. Тут по аналогии магазина)
Когда в магазине вкусные и красивые фрукты на полках, то покупатель доволен. И он вернётся к вам снова. И может даже друзей приведёт.
А если на полках всё лежит и лежит, и мало кто это покупает, то может стоит задуматься о смене поставщика?
Или даже воскресить производство товаров, на которых был больше спрос?
o_o
Дорогой директор супермаркета, спроси у аналитиков конкретно скажем про "сушилку одежды" от такой то фирмы:
Как давно была покупка вот этого товара? Сколько было таких продаж за прошлый месяц? А за год?
Сделайте ка мне выборку: каких товаров продано меньше N за последние пол года!
Маркетологи скажут: вложись в рекламу чувак, мы тебе поднимем оборот! Это пару раз сработает, а дальше?
Позиция: бери что дают, всё равно аналогов нет — немного адочек...
Я не хочу покупать десять фруктов, у которых меньше себестоимость с точки зрения рынка, когда они невкусные.
Я лучше куплю один фрукт, и получу удовольствие. Но вернусь к вам за новой порцией, чтобы угостить маму.
Возвращаясь к теме про ЯП:
сделать на своём яп крутую приложуху, чтобы её раскрутить
её фрагмент показать исходным кодом
выложить документацию в открытый доступ
определиться с чего монетки — казалось бы сперва, да?
Здравствуйте, Sm0ke, Вы писали:
DP>>Посмотри на свежие популярные языки: за всеми стоят гиганты. А это, соотвественно, деньги и пиар. Конечно люди начнут пользоваться. И техническая составляющая тут будет вторична. Go, Swift, Dart, Flutter, не говоря уже про C# и Джаву. Да тот же Котлин.
S>Так есть же исключения S>php к примеру
Именно что исключение, подтверждающее правило (существование и принцип).
Много ты сейчас найдёшь неоткрытых ниш?
S>Мне кажется, что первоочередное — это качество продукта. Тут по аналогии магазина)
Особенно смешно это про PHP (ну, условно, до 7-й версии).
Конечно, спасибо за то, что это дерьмо времён 4.x-5.1-5.2 стало главной причиной развития высококачественной контейнеризации, но это было больно.
S>Я лучше куплю один фрукт, и получу удовольствие. Но вернусь к вам за новой порцией, чтобы угостить маму.
Ну вот есть фрукт, а есть овощ, а есть мясо, а есть приправы.
Обобщить их в одном продукте на все случаи — как-то нереально.
S>p/s S>самая востребованная приложуха — это...
Здравствуйте, vsb, Вы писали:
vsb>По сути рисуешь грамматику на каком-нибудь antlr, он тебе даёт на выходе AST. Дальше по этому AST надо проверить типы, вот тут я автоматизацию не знаю, вероятно тут основной код и будет сидеть. Возможно сгенерить ещё какие-нибудь AST (если есть макросы). И потом сдампить всё это дело в конечный байткод, который и скормить бэкэнду.
все так. а вот если скажем запрашиваемый синтаксис языка будет изобиловать контекстно зависимыми выражениями ? здается прогулка может оказаться не такой легкой.
Здравствуйте, ребусоид, Вы писали:
Р> все так. а вот если скажем запрашиваемый синтаксис языка будет изобиловать контекстно зависимыми выражениями ? здается прогулка может оказаться не такой легкой.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, ребусоид, Вы писали:
Р>> все так. а вот если скажем запрашиваемый синтаксис языка будет изобиловать контекстно зависимыми выражениями ? здается прогулка может оказаться не такой легкой.
N>А вот этого надо избегать до последнего.
Ага, это вы скажете заказчику. Причем, вероятно, что требование избегать бэктрекинга прозвучит также ))
Посмотри на свежие популярные языки: за всеми стоят гиганты. А это, соотвественно, деньги и пиар.
by: me
Так есть же исключения
php к примеру
Вы писали: N>Особенно смешно это про PHP (ну, условно, до 7-й версии).
Я php упомянул в том плане, что за ним не стоят корпорации, которые его пиарят.
Он нишу свою занял, до сих пор пользуется спросом.
И продолжает развиваться (хоть неспешно, так как видимо уже довольно самодостаточен для своих задач)
-- N>Много ты сейчас найдёшь неоткрытых ниш?
Не обязательно находить новые ниши. Можно же упростить разработку в уже имеющихся нишах. И в тех, которые появились недавно, где делаются первые шаги.
by: me
p/s
самая востребованная приложуха — это...
N>Ну?
. Операционная система .
это же очевидно
Возможно сперва придётся обкатать синтаксис языка на прикладных задачах, отполировать, чтобы потом разработать в нём low-level режим.
И попутно монетку бы сколлекционировать)
change topic: -- Продуктовый магазин --
by: me
Я лучше куплю один фрукт, и получу удовольствие.
(без подтекста, без параллелей, без аналогий)
А десять невкусных с сомнительной формой — лучше бы вообще не клали на прилавки (И даже не привозили на склады).
Думаю лучше не стоит поднимать урожайность овощей/фруктов непроверенными удобрениями в ущерб интересов конечного покупателя.
Выращивайте так, чтобы вы сами хотели вкусить)
N>Ну вот есть фрукт, а есть овощ, а есть мясо, а есть приправы. N>Обобщить их в одном продукте на все случаи — как-то нереально.
Я же не предлагаю их обобщать. Я бы даже сузил случай именно фрукта до яблок.
Помню в 2016-м были офигенные с сортом роял гала. Где такие сейчас найдёшь в моём городе, а? Сейчас они не такие, увы ;( хотя сорт указан тот-же
Здравствуйте, Sm0ke, Вы писали:
S>Вы писали: N>>Особенно смешно это про PHP (ну, условно, до 7-й версии). S>Я php упомянул в том плане, что за ним не стоят корпорации, которые его пиарят.
Вы это серьёзно???
Zend — с 1998.
Facebook — с основания и до сейчас! У них серверная сторона на PHP. Сильно компилированном, но на нём.
И да, пиара от Facebook для него достаточно.
S>Он нишу свою занял, до сих пор пользуется спросом.
Он её сформировал. Это более существенно. И да, таки пользуется спросом, мягко говоря.
S>Не обязательно находить новые ниши. Можно же упростить разработку в уже имеющихся нишах. И в тех, которые появились недавно, где делаются первые шаги.
Это должно быть суперупрощение. Или очень мягкий совместимый переход.
S>by: me S>
S>p/s
S>самая востребованная приложуха — это...
N>>Ну?
S>. Операционная система . S>это же очевидно
Нет, если считать по количеству человеко-времени потраченного на разработку.
Сейчас 60-70% это веб во всех видах.
А что там стоит внутри за доступным API, знают только фрики вроде нас, которые ещё помнят, сколько бит в байте.
N>>Ну вот есть фрукт, а есть овощ, а есть мясо, а есть приправы. N>>Обобщить их в одном продукте на все случаи — как-то нереально.
S>Я же не предлагаю их обобщать. Я бы даже сузил случай именно фрукта до яблок.
Это, наверно, чрезмерно.
А обобщать вы таки предлагали. Один и тот же язык и для системного уровня (где можно лезть в регистры внешних устройств и писать напрямую обработчики прерываний) и для скриптов это как-то странно.
S>Помню в 2016-м были офигенные с сортом роял гала. Где такие сейчас найдёшь в моём городе, а? Сейчас они не такие, увы ;( хотя сорт указан тот-же
Такого не видел, просто Гала у нас на каждом углу.
S>>Я php упомянул в том плане, что за ним не стоят корпорации, которые его пиарят.
N>Вы это серьёзно??? N>Zend — с 1998. N>Facebook — с основания и до сейчас! У них серверная сторона на PHP. Сильно компилированном, но на нём.
N>И да, пиара от Facebook для него достаточно.
Выходит, что я сделал ошибочное суждение за недостатком просвящённости по историческим событиям ...
чтож
--
S>>. Операционная система .
N>Нет, если считать по количеству человеко-времени потраченного на разработку. N>Сейчас 60-70% это веб во всех видах.
Это вы с поизции разработки правы.
Но с позиции пользователей — первоочередное — это OS.
Независимо от устройств (мобльники, пк, консоли, ноуты, планшеты)
N>А обобщать вы таки предлагали.
Да по lang, Нет — по продуктам) N>Один и тот же язык и для системного уровня (где можно лезть в регистры внешних устройств и писать напрямую обработчики прерываний) и для скриптов это как-то странно.
Для меня lang — это синтаксис в первую очередь, чтобы на нём писать. На данный момент по краней мере.
Чтобы для кода OS её исходник, написанный на каком_бы_то_ни_было языке, превратить в исполняемые электроникой байты — нужен что? Компилятор, так?
* Значит для нового языка делается соответствующий extension компилятора, который добавляет специальные встроенные типы и функции, по работе в low level режиме.
* Без включения этого -OS режима я бы хотел, чтобы новый ЯП был полностью safe и вообще без UB.
(даже без raw pointers / или с некоторым целочисленным представлением для raw pointers без возможности по ним лезть в память)
* Для -OS режима может появится модуль анализатора кода.
Здравствуйте, netch80
Наконец появилась "минутка", чтобы ответить по вопросу namespace
| В си++ можно в разных местах открыть начало пространства имён, что-то в нём определить, а потом закрыть.
| И так несколько раз для того-же имени namespace -а можно повторно открывать в разных файлах.
В кси всё лежит в ячейках. У ячейки есть имя, и принадлежность.
К примеру ячейка модуля принадлежит модулю
Имя модуля начинается с собачки
| На примере ui либы это может выглядить так:
В модуле @main ячейка нэймспэйса с именем ui
-- file: ui-colors.ksi
@main
ui = #nest (
colors
)
ui.colors = #nest (
red = 0h_ff_00_00
white = 0h_ff_ff_ff
)
do = {
&write_line( ui.colors.red )
}
Команда #nest формирует и возвращает новый тип, со статическими свойствами.
Это можно использовать как пространство имён.
Вы писали:
Если хочется чего-то выше уровня песочницы — понадобятся, иерархические.
Конечно они могут быть вложенными.
Вначале был указан список ячеек в нэсте ui
В этом списке пока только colors
Который тоже nest
Начальное значение для colors вынесено отделньно за скобку
Но могло быть и внутри, как у ячейки ui.colors.red
--
Добавим в nest ui ещё типы: coords, color
Через команду #add_nest
-- file: ui-types.ksi
@main
ui #add_nest (
coords
color
)
ui.coords = #struct ( x y )
ui.color = #struct ( r g b )
-- usage:
test_types = {
pos = ui.coords(2, 2)
clr = ui.color(200, 200, 200)
}
В том-же файле, или в отдельном — не так важно.
--
Через #add_nest можно статики добавлять и к структуре тоже
Метод to_code для типа ui.color в этом примере не определён.
Синтаксис для добавления методов — в отдельном reply запланирован)
вы спрашивали
Я не понял, к чему '!' впереди "!as".
Через восклицательный знак — это вызов метода cell !method cell !method(params)
Через точку — доступ к свойству cell.property
Через стрелочку — доступ к атрибуту cell->attr
так имена у метода, свойства и атрибута могут совпадать, и не возникнет ambiguity
--
Попытка через круглые скобки создать экземпляр из типа, который сформирован командой #nest, вернёт тот-же тип.
do {
-- attempt to make nest instance:
var = ui.colors()
-- type of nest instance:
type = var$
-- ... and nest itself
( type == ui.colors ) #then { &write("same") }
-- is the same thing
-- but type of nest:
ui.colors$ == $type -- ui.colors is type
-- is $type
}
Тут var$ — это способ узнать тип
--
На случай если разработчик кси библиотеки захочет запретить добавлять в свой nest дополнительные статик свойства через #add_nest,
то можно ввести команду #nest_once (или как её лучше назвать?)
@some_lib
my_nest = #nest_once ( a b c )
my_nest #add_nest () -- ошибка!
Но может быть вы предложите вообще запретить через #add_nest добавлять статики именно в #nest ?
Чтобы весь перечень статик ячеек был всегда в одном месте ... И не пришлось бы их искать по разным файлам
Как считаете, добавлять статики в структуру, в перечисление, и даже в функцию — хорошая идея?
* всё той-же командой #add_nest
Это применение метода (действия) к результату предыдущего выражения.
Но сперва я бы хотел пояснить про вызовы обычных функций.
# fn call
В кси есть два способа вызова функции:
Обычный, и по цепочке
angle = math.pi
// обычный вызов функции
x = math.sinus(angle)
// chain call
x = (angle |math.sinus)
пояснение
Вертикальная палка означает: применить функцию к значению слева.
Идея повзаимствована из библиотеки шаблонов Smarty.
Я думаю, что на уровне парсера надо проверять, чтобы после | не было пробела при chain-call.
Так можно вместо вложенных скобок писать вызовы слева-направо.
param = "size"// обычный вызов функции
x = math.sinus( config.get_value(param) )
// chain call
x = (param |config.get_value |math.sinus)
* Предполагается, что функции math.sinus и config.get_value где-то определены.
# Способы передачи параметров
--
При обычном fn-call и когда функция принимет один параметр — круглые скобки можно не писать, заменив их спец-символом:
// альтернативный способ передать первый параметр
std.loop! { /* тело цикла */ }
// простой способ
param = { /* тело цикла */ }
std.loop(param)
Символ восклицательный знак ! после функции (без пробела между ними) — означает вызови функцию, а как первый параметр возьми результат последующего выражения.
Может быть есть более походящий для этого символ, чтобы задать его в парсере?
Функция std.loop — это вечный цикл. Она принимает один параметр — sequence.
Где именно она определена? Может быть в библиотеке, а может и системная — вопрос не решённый.
Пока рассказываю про синтаксис вызова и передачи параметров.
С набором стандартных/системных функций ещё предстоит определиться.
Выбрать им имена)
--
При chain-call для функции с двумя параметрами — этот второй параметр тоже можно по разному пассить.
Символ двоеточие для второго параметра при chain-call тоже задаётся в парсере.
Меня немного смущает, что смысл символа зависит от контекста.
Выписать бы контексто-зависимые символы отдельно.
Пример с циклами:
{
/* pre condition */
} |std.while_do: {
/* loop body */
}
{
/* loop body */
} |std.do_while: {
/* post condition */
}
# методы (actions)
Напомню, что ! перед именем (без пробелов между ними) — это вызов метода.
Для поиска методов — у обработчика свои правила разрешения имён, отличные от случая с функцией.
Про методы у типов напишу немного позднее / возможно / И про шаблоны тоже.
Но мне кажется интерес других программистов на RSDN к разработке нового ЯП поугас.
Однако я замечаю, что есть нюансы, по которым ругают Си++.
Так вот бы создать новый better language и сделать как мы хотим
Касательно темы функций — вопрос открыт про variadic параметры, нужны ли они ? Или взять fixed size массив / sequence
И про передачу параметров по имени. В php это есть, в других яп тоже. Но я бы предложил через отдельную команду #options ()
