Комментарии 63
Один вопрос - зачем? Кому-то мало имеющегося зоопарка ЯП?
Судя по всему ответ в эпилоге
Конечно, вероятность что из новых языков что-то станет популярным очень низкая, но в таких языках вполне можно проводить какие-то эксперименты, которые в случае успеха можно завезти в язык более популярный и востребованный. Кто-то просто созданием языков прокачивает свои личные навыки, кому-то по фану
Есть ли какие-то особенности, которые бы выгодно отличали язык от других "убийц C" - Go, D, Zig, ...? В первую очередь, наверное, интересно сравнение с D, учитывая, что это язык, на котором написан компилятор.
Есть yaml, а нужен ещë yapl - yet another programming language.
Возможно в чем-то ошибаюсь и неверно пониманию, но выскажу свое видение.
Представленный ЯП недалеко ушел от C/C++/D. Он больше похож на обертку, которая в паре мест накладывает свои правила на написание кода. Может быть в этом и была цель.
Но.. как по мне, новый ЯП в сравнении с референсными ЯП должен:
– Не слишком сильно отличаться по синтаксису от референсных ЯП, чтобы не отталкивать тех кто входит в разработку / переходит на ваш стек;
– Заменять шаблонный (boilerplate) код, который был в референсных ЯП, на более простые и очевидные конструкции;
– Давать бОльшую безопасность работы, чем в референсных ЯП;
– Давать бОльшую гибкость в разработке, чем в референсных ЯП.
Каких идиом не хватает как по мне:
– generics взамен или совместно с template подходом;
– обработка исключений / классов исключений вместо кодов ошибок;
– лямбды / замыкания / функции первого порядка;
– атомики / объекты синхрониазции / управление потоками / асинхронные механизмы;
– аннотации / параметры / способы верхнеуровневого программирования, кодогенерации, аспектно-ориентированного программирования
А можно ещё от точки с запятой избавиться?
Ничего с этим не поделать, молодёжь так и будет пытаться изобрести очередной язык и опишет это на Хабре. Надо смириться, похоже :) Ну хоть для них самих это будет полезно в плане развития.
Если ты тоже делаешь свой язык и тоже собираешься написать об этом на Хабре, то будь добр — напиши сразу же в первых предложениях какую проблему призван решать твой язык. Сразу всем станет легче от этого, спасибо.
Попытки сделать "улучшенный Си" мне интересны, и название языка вы классное выбрали, мне нравится (но, кажется, в контексте ЯП оно несколько, ээ, двусмысленное).
Есть несколько вопросов, а поскольку я не нашёл ответов ни в документации на сайте (как-то совсем уж там мало), ни на гитхабе, поэтому поинтересуюсь тут.
void* a; // Переменные автоматически инициализируются в null(можно отключить)
a = itop(void*,0); // Ошибка
int b;
std::scanf("%d",&b);
a = itop(void*,b); // Если b == 0 - runtime ошибка
b = ptoi(a);Конструкции языка itop и ptoi это что за сущности? Выглядят как функции, но itop, например, принимает первым параметром тип, и при этом как-то узнаёт адрес переменной, переданной вторым параметром значению (может, это ссылка)? Или это всё-таки не функции в обычном понимании, а спец. конструкции самого языка?
std::error<int> func => std::error<int>(10,"",0);Я так понимаю, что сущность std::error<> предполагается возвращать всем функциям, предполагающим возможность фейла в процессе выполнения. Это известный подход к выдаче и обработке ошибок, и он мне в целом импонирует, но мне кажется название неудачное выбрано. Может, что-то нейтральное, навроде std::result было бы лучше, ведь предполагается, что ф-я всё-таки не ошибку возвращать должна, а результат (который да, может быть не посчитан из-за ошибки) .
try {
int base = func();
}
// base виден во всей функцииЯ правильно понимаю, что этот случай (блок try) является исключением из правила "переменная объявленная внутри блока, видна только там"? Вообще, обработка ошибок мне не очень понятна, try/catch смущают, наверное: вроде как исключение ловим, но не исключение, дальше уровнем оно не пробрасывается, соответственно, не очень понятно вообще, зачем пытаться быть похожим на обработку исключений, в том числе и ключевые слова копируя. Лично мне наверное зашло бы что-то попроще, в духе:
auto result = func();
if (!result.err) doSomethingWith(result.val);и если бы проверки не было, а result.val использовался, вот тогда бы генерировался runtime error.
"itop"/"ptoi" являются встроенными инструкциями, которые соответствуют тем же инструкциям в LLVM. Для удобства, "itop" принимает первый аргумент в виде типа, чтобы не пришлось лишний раз прописывать "cast(type)".
Как вы верно подметили - try является исключением из правила "переменная объявленная внутри блока, видна только там". В основном, он используется для тех мест, где не так важна пользовательская отладка ошибок - в таком случае, пользователь может поручить компилятору автоматически проверять вызовы таких функций на ошибку.
Сам пользователь может собственноручно проверить, есть ли ошибка при вызове функции через catch:
import <std/error> <std/io>
std::error<int> foo => std::error<int>(0,"Error!\n",100);
void main {
std::error<int> result = foo();
result.catch();
result.catch(void(char* msg, int code) {
std::println(msg,", code: ",code);
});
}То есть, предполагается, что программист должен окружать блоком try любой код, где ошибки не проверяются вручную, если он хочет, чтобы программа завершалась "красиво", c runtime error в месте вызова? Но учитывая, что исключений нет, получается, блоком try вообще все функции закрывать желательно. Почему бы тогда просто не сделать это поведение всегда активным по умолчанию, и добавить спецификатор для функции, которым можно пользоваться, если дефолтные проверки не нужны? Тогда и исключения из правил для блока try не нужно будет, и самого try. Или, как альтернативу, заместо try можно блок а-ля unsafe добавить, который работает строго наоборот. Мне кажется, это как-то более правильно было бы.
"try" нужен для автоматизации ловли ошибок при вызовах функций с возвращаемым типом std::error<type>.
Как вы хотите сделать это по-умолчанию - я, честно сказать, не понимаю. Возможно, вы имели ввиду переход на полноценные исключения.
Я имел в виду что-то вроде такого: компилятор автоматически вставляет ловлю ошибки, если функция возвращает std::error<type>, и при этом компилятор не видит обработки ошибки пользователем перед использованием значения (а также опциональное отключение такого поведения под ответственность программиста).
std::error<int> foo => std::error<int>(0,"Error!\n",100);
void bar()
{
std::error<int> result = foo();
// Здесь нет проверки на ошибку перед использованием результата,
// и компилятор здесь вставил её сам, не требуя от программиста try.
... тут result используется ...
result = foo();
result.catch();
...
// А здесь есть проверка. Компилятор ничего от себя не добавлял.
... тут result используется ...
unsafe
{
result = foo();
// Здесь нет проверки на ошибку перед использованием результата,
// но программист явно указал компилятору не проверять.
... тут result используется ...
}
}Идея в том, что проверка на ошибку, всегда добавляемая по умолчанию, лучше чем отсутствие проверки по умолчанию: программист не забудет добавить try где нужно. Если же программист точно уверен, что никакая проверка не нужна, он указывает это явно.
Эх, название многообещающее. Думал party hard будет, а тут обёртка над C/C++.
Автору рекомендуется расширить свои познания в области языков программирования. Такое впечатление, что кроме С и его друзей он ни о чем больше никогда и не слыхал, и не в состоянии вырваться из узкого туннеля.
У котлина над джавой продоминировать получилось лучше.
мне кажется что яп -ёпла- точно не хватает
Чел харош
Расскажу своё (никому не нужное) мнение о языке.
Знаю много, так как видел своими глазами, как язык рождался и развивался, а также принимал частичное участие в разработке, а также помощи с поиском и исправлением багов.
Сам по себе язык неплохой, несмотря на баги, (хоть серьезные уже давно исправлены), и на безумно малый std. Язык привносит runtime проверки (да да, я упрашивал автора добавить их наверно месяц :D), которые позволяют уменьшить к-во segmentation fault'ов и в целом улучшить жизнь; имеются методы в структурах (что, технически, является syntax sugar - методы во время компиляции выносятся, названия манглятся), которые очень удобны в разработке и вносят хотя бы намек на ООП, имеется ряд syntax sugar'ов, таких как лямбды и => в return, что опять уменьшает количество сурсов и +100 к читаемости. Говорю это все как разработчик на Rave (писал разные библиотеки уже - биндинги, врапперы над биндингами, свои собственные - например парсер json, хотя он и заброшен; программы).
Язык я не считаю прямо нужным - есть целых зоопарк из Go, Rust, D, C++ (и многих других), которые тоже хорошо справляются с задачей general purpose. Автор говорит, что язык хорошо подходит для низкоуровневой работы, и тут я не могу не согласиться, но опять же, есть те же С/C++. Синтаксис конечно приятнее, но тут уже у каждого своё мнение.
Считаю проект хоть отчасти, но перспективным, думаю своих любителей найдет каждый язык.
(Это, к слову, мой первый комментарий, и тем более, я зарегистрировал аккаунт только ради этого комментария :D. Передаю привет Правителю!, бебрарику, плюшевому, зедикловну, не очень сексуальному рабу и всем остальным rave'анутым!)
Смею предложить автору написать "улучшенный Си" для микроконтроллеров. Там есть где развернуться. Например, сделать наконец чтобы язык знал, что вот это прерывание и не надо переменные которые в нем используются выкидывать (см. "Скользкая дорожка для поклонников volatile")
Спасибо за идею, возможно реализую.
Например, сделать наконец чтобы язык знал, что вот это прерывание
Это есть в HolyC. Но увы, там развитие языка остановилось когда автора убили агенты ЦРУ.
Я посмотрел про HolyC и помоему вы ошибаетесь. Где там про прерывания?
Там есть атрибут interrupt для функции, который позволяет ее использовать как обработчик прерывания. Не уверен, как именно хендлятся используемые в них переменные по отношению к вашим проблемам с volatile, но вряд ли выбрасываются, Терри Дэвис не особо заморачивался с такими оптимизациями. Сказано сходить в память, оно сходит в память.
Впрочем, самой полной документацией на HolyC является Библия, так что о поведении программ на нем рассуждать довольно сложно.
Высказываю очень важное и конструктивно объективное мнение касаемо языка программирования раве (Rave), могу сказать от лица ветерана всего этого языка, который был с самого зарождения языка и до самого его релиза. В целом могу сказать то, что язык является полезным и имеет своим применения. Безусловно, кто-то может считать, что это очередной мусорный язык, от которого нету никакого толку - но, если так подумать, почти любой язык является бессмысленным. В-общем, не буду устраивать длиннейшие дискуссии, ибо это может затянуться на очень длительное время, скажу лишь, что у языка есть множество преимуществ над другими, основным из которого, является очень позитивное и дружелюбное сообщество, с которым связано историй больше, чем с самим языком
(Привет всем любителям jamal'ов, и ценителям кода на epl).
Как профессиональный программист, который тратит 90% работы на гугление и копипасту со стаковерфлоу, тем не менее скажу пару замечаний насчет синтаксиса как этого, так и других языков.
Много символьные конструкции из символов: это ужасно.
Допустим, [::] - это 3 нажатия: [shift+;+;]. По сравнению с тем же js - где достаточно одной [.] - это в 3 раза больше. -> в c++ - это [-+shift+.]. К-к-к-омбо! Лямбды в js - [_=>], [()=>{}] тоже громоздкие комбо из символов. Мы скованы историческим расположением и символами кнопок на клавиатуре, но можно же сделать проще? В идеале - 1 семантическая единица - 1 нажатие клавиши. В этом смысле мне очень нравится система типов в Rust, где они максимально сокращены до 1 символа.
Доп. символы не имеющие смысловой нагрузки - это кошмарно.
[;] - в конце строки, какой в этом смысл? в этом плане мне нравится гибкость JS - там это не обязательно, хотя и можно использовать тчк-зпт как разделитель. import <std/io> - кавычки это ужас, когда можно и без них вообще. Перекладывать работу с бездушного и всеядного синтаксического анализатора на разработчика - это отвратительно. Мы тут автоматизируем работу человека или чем занимаемся вообще? Если хочется красоты - для этого есть IDE, можно хоть каждую точку в букет из анимированных роз превратить и каждую букву заставить плясать чечетку.
Язык должен быть лаконичным настолько, насколько это вообще возможно. Благо, в разработке синтетических языков мы можем избежать исторических атавизмов вроде ру или eng, и забить болт на запятые и большие буквы с красной строки, сделав язык удобным для работы. Нужна точка с запятой для устранения неоднозначности? А точно ли она нужна, разве из контекста нельзя определить смысл? Это то, что и должен уметь хороший язык программирования - читать мысли разработчика.
Как-то давно и неправда делал свой язык, и как раз размышлял над лаконичностью. В том числе были несколько идей:
(до Rust) - типы данных в 1 символ, с размерностью числом после. q - бит (question/bool), q64 - 64 бита, 64q - массив из 64. Индексация без []. [.] - любой номер, т.е.
64q a //массив bool 64
a.=1 a3=0 a5.15=0 //все значения 1, кроме как по индексу 3 и от 5 до 15Все кавычки - [], т.к. для них не нужен shift.
Каждый оператор максимум в 1 символ и без нажатия shift.
32q a a.=1 a3=0 a.=+5-a2 q64 b=255В этом конкретном примере, нужен ли разделитель, кроме пробела?
Чтобы доказать, что да - нужно доказать, что есть такая последовательность команд, которая будет неоднозначно воспринята. Какие операторы могут идти после [=]? Допустим, только [a-z/0-1] затем [+,-,*,/] (или наоборот). А может ли другая команда начинаться с этого символа? Если нет - то и разделитель не нужен. И вот этой работой разработчики языков себе голову особо не забивают, а следовало бы. Красивым язык может быть в своем изяществе.
А читабельность можно отдать на откуп IDE, т.к. в блокноте уже давно никто не работает. А уже она раскрасит и подсветит.
По записи напоминает Forth, но наоборот. Такая же белиберда, если не обладаешь сакральным знанием.
Удивительно, не зная языка 你无法理解这段文字. Кто бы мог подумать. Нет бы делать языки чтобы @unclegluk сразу его понимал.
Ты случаем не 1Сник?
Спасибо, что высказали мне свою точку зрения на синтаксис.
Акцент был сделан на то, что эти операторы и конструкции итак находятся в "обороте", и пользователям будет легче принять и использовать новый функционал.
import, как я считаю, не должен давать излишней функциональности. Все, что требуется пользователю - импортирования файлов проекта, файлов библиотек и std. И import с этой задачей справляется. А насчёт кавычек - они были выбраны для той же удобности людям, которые привыкли писать на С/С++.
';' в конце строки находится для отладки компилятором и некоторых... "трюков" в парсинге языка.
Чего мне не хватает в Си?
Было бы здорово, если бы функции можно было указать тип массива и
количество элементов, при попытке подсунуть не массив или массив другой
длины чтобы при компиляции выдавалась ошибка. Кто не хочет пользоваться
таким механизмом - не указывайте кол-во элементов при объявлении
массива-аргумента функции
void f(int a[8]){//в аргументе функции указан массив с определенном количеством элементов
}
int main()
{
int b[4];
f(b); //no error why?
return 0;
}
Если речь идёт в контексте Rave, то массивы по-умолчанию передаются по значению, что автоматически обязывает компилятор проверять типы.
gcc так умеет (-Wstringop-overflow) начиная с 11 версии, но только при передаче массивов фиксированных размеров меньшей длины в функцию, которая ожидает массив большей длины. Но для других случаев при наличии в языке VLA сделать такую проверку в compile time невозможно.
Что с константностью переменных? Есть ли иммутабельность по-умолчанию? (гуглить better deafaults)
```
let x = 3; //не даст измениться
let mut y = 123; // кто-то может это поменять
```
Исправлена ли болезнь Си/Си++ со спиральностью типов. Например, Саттер предлагает сделать униформный порядок в своём суперсете плюсов.
Можно ли на системе макросов сделать самосборку проекта? Чтобы никах симейков не нужно было. Пока что мне известно только про jai Джона Блоу, который может сам себе быть сборочным скриптом.
Компилятор уже Self hosted?
Наличие базовой работы с ООП;
А где примеры? Есть ли интерфейсы? Что с наследованием? Что с перегрузками типов функций?
Наличие улучшенной безопасности работы с указателями и улучшенной обработки ошибок;
Опять же - какие-то примеры было нелпохо увидеть. Значит ли это что по умолчанию везде толстые указатели, хранящие размер типа рядом?
Как устроен ABI между языком и каким-нибудь Си?
Отсутствие многих недостатков С, С++ и прочих языков(вроде того же
препроцессора, хоть помечать его как недостаток довольно спорно), и так
далее.
Препроцессор в сях/плюсах это меньшая из проблем. Оно только усложняет отладку, но в среднем жить с этим можно. А какие ещё проблемы были решены?
P.S. У вас серт на ваш домен остутвует.
По поводу константности - присутствует "const(type)":
const(char)* str = "Hi!";Про самосборку - не весь нужный функционал имеется, но постепенно будем добавлять чего не хватает.
Нет, на данный момент компилятор не self-hosted, но это в ближайших планах.
Примеры есть в данной статье, а также в GitHub-репозитории. На данный момент их там мало, так что я напишу вас интересующие:
struct Bow {
float data;
}
struct Foo {
void method {
data = 0.0;
}
void method(int a) {
data = cast(float)a;
}
}
void main {
Foo foo;
foo.method();
foo.method(10);
}Наследование сейчас реализовано, скажем так, не лучшим образом, но для простого предотвращения копирования элементов структуры в другие структуры множество раз руками вполне сойдёт.
Про отладку ошибок - примеры приведены в статье. Но вкратце - itop/ptoi проверяются на нулевое значение, а std::error<type> позволяет удобно получать результат выполнения функции с возможностью отследить возможные ошибки.
Про ABI - сейчас оно плохо задокументировано, каюсь.
Но в целом, если вам нужно, скажем, импортировать функцию из С-библиотеки, вы можете использовать linkname:
extern(linkname: "foo") void raveFoo();Таким же способом вы можете вручную задавать выходные имена для функций, чтобы улучшить взаимодействие с ними из других языков программирования.
По поводу решения проблем из C/C++ - в данной области до сих пор ведётся активная разработка, так что точно сказать не могу. Но в целом, акцент ведётся на улучшенную безопасность работы с памятью и указателями - тому пример структура SafePtr(которая недавно была переведена в std/memutil):
import <std/memutil>
void main {
auto ptr = SafePtr<int>(10);
int[10] array;
ptr.pointer = &array;
}Работа с SafePtr позволяет частично облегчить отладку ошибок, связанных с попыткой доступа за грани указателя.
P.S. Насчёт сертификата знаю...(
По поводу решения проблем из C/C++
Но какие-то постулаты к которым вы как разработчики стремитесь должны же быть в каком-то виде? Снижение когнитивной нагрузки при чтении кода по идее улучшает безопасность.
А ещё забыл спросить про всякие UB, как то разыменование нулевых указателей, обращение к неинициализированным переменным, вызов унарных операторов в качестве параметров функции и вот это вот всё - в каком-то видео оно обсуждалось/документировалось?
И про время жизни - по-умолчанию везде RAII или есть механизмы управления временем жизни?
И я так понял в примере выше где-то опечатка ибо есть Bow c членом и Foo без них, но с методами, который пытается получить доступ к члену.
Там я так понимаю должно было быть что-то вроде?
struct Foo: Bow { ... }using blabla = name::space::sub::name::space;
blabla::something(); алиасинг пространств имён уже есть в каком-то виде?
Любопытно, почему все так старательно увеличивают число языков там, где и так разнообразия более чем чрезмерно. И обходят стороной то, где оно насущно и востребовано, например альтернативы VHDL и verilog которых крайне не хватает.
Потому что занимаются тем, что интересно. Чтобы ваши чаяния сбылись, необходимо, чтобы кто-то соединил в себе как интерес к языкам программирования, так и интерес к проектированию электроники. Но тут, похоже, этого не дождаться. Либо ждать, когда государство вмешается. Либо ждать китайских товарищей, когда им тоже припечёт.
Я вот тоже сожалею, что дистрибутивов у Linux много, а вот у Windows клон только один.
На Хабре у Юрия Панчула (https://habr.com/ru/post/702186/) прочитал, что в Китае сделали свой аналог VHDL и Verilog. Теперь Вы знаете, у кого спрашивать.
Вот как раз аналогов видеть не хочется.
Хочется принципиально иной подход для описания систем с истинным параллелизмом свободный от тяжелого наследия. С несколькими уровнями абстракции. Причем, в рамках одного языка и одного проекта. Типа как на С++ можно делать и ассемблерные вставки, и линейный код в стиле Си, и работать на уровне объектов и их взаимодействия.
Очередной убийца Си по скобочками, амперсандами и точками с запятой. Как мило.
А что вы думаете о публикации Нюансы разработки парсера для своего языка программирования ?
Перешёл сюда по ссылке из хейтерской статьи. Язык совсем неплох (хотя и не в моём вкусе), не слушайте тех, кто говорит, что нам не нужны новые ЯП.
Спасибо за комментарий.
Сама "хейтерская" статья скорее основана на личной неприязни (около полугода назад я забанил автора этой статьи за постоянное грубое общение, издевательства и оскорбления в мой адрес и адрес других участников моего Discord-сервера).
При этом же, все перечисленные баги (которые действительно являются багами, а не пример с делением на 0 или хэш-функцией) я пофиксил примерно за час, сразу после выхода статьи.
Сам проект, как я неоднократно подчёркивал, является сугубо личным и лишь попыткой создания самодельного компилятора, но спасибо за поддержку.
Сама "хейтерская" статья скорее основана на личной неприязни
За кавычки спасибо, ну а личной неприязни в статье не было. Предыстория такова: на меня с друзьями нашло резкое желание посмотреть, а что там в Рейве новенького. Потом мы 9 часов сидели в войсе и смеялись, находя новые баги, - я пару раз чуть не задохнулся. Ну собственно поэтому статья и вышла. Как статистика показала, баги действительно смешные. Целью было просто показать смешные баги - всё!
постоянное грубое общение, издевательства и оскорбления в мой адрес
Было дело.
и адрес других участников моего Discord-сервера
А это уже скорее ложь. Можно назвать пару случаев, но там два типа ситуаций: либо мы друг с другом просто так общаемся и ни у кого претензий по этому поводу нет, либо ты сам не лучше меня был. :)
Ну и конкретных участников ты, конечно, не назовёшь, и примеры оскорблений не предоставишь, потому что чат-то магически удалился после моего бана.
При этом же, все перечисленные баги (которые действительно являются
багами, а не пример с делением на 0 или хэш-функцией) я пофиксил
примерно за час, сразу после выхода статьи.
Как кое-кто верно подметил:
Пофиксил за час после выхода статьи и за неделю после того как баги эти были ему показаны
Ну а если без шуточек, то почему, например, деление на ноль не баг? fastmath? Не отмажешься, я чат сервера всё ещё вижу, там по этому поводу были разборки - fastmath не виноват (ну либо -noFastMath не работает, что не лучше), но ты этот факт, если мне не изменяет память, просто проигнорировал.
Приколы с парсингом ты просто оправдывать начал, цитирую:
Я бы сказал, что это следствие более "свободного" распознавания тех или иных языковых конструкций
Я пока не проверял, реально ли все баги (точнее всё, что ты решил отнести к багам) исправлены, но что-то мне подсказывает, что были исправлены вот ровно только те баги, которые в статье. Видимо воображение разыгралось. /s
А вот у кого-то точно нет личной неприязни :)
Мой бан можно оправдать, а тут что? Не понравилось, что он со мной общается?
Данный участник неуважительно себя вёл довольно продолжительное время, что можно увидеть по его манере речи как минимум. Я решил, что в ближайшее время перестану терпеть любые подобные выходки, даже если эти люди иногда говорят полезные вещи.
Багом, в данном случае, является то, что не запланировано. Деление на ноль с самого начала должно было приводить к неопределённому поведению.
Я ничего не оправдывал и не оправдываю. Я лишь делаю свой личный проект, не претендующий на значимость в текущей системе. Разумеется, лишь я решаю, как его обновлять.
Мне была показана лишь малая часть багов. Весь язык сейчас находится в постоянном изменении, что можно видеть по коммитам. Ближе к релизу 1.20 постараюсь стабилизировать состояние.
На будущее: не прикрывайся объективной критикой, как ты делал это на Discord-сервере. Я лишь перестал терпеть неуважительное общение со стороны данной группы лиц. Если нужны доказательства - у меня полно доказательств с вашей травлей людей и рейдами серверов.
Данный участник неуважительно себя вёл довольно продолжительное время, что можно увидеть по его манере речи как минимум.
Неуважительная манера речи? Не на "Вы" общался что-ли, или что? Или подшучивал?
Я решил, что в ближайшее время перестану терпеть любые подобные выходки, даже если эти люди иногда говорят полезные вещи.
Переобулся в полёте после моей статьи или что? Просто со стороны забаненного не было никаких необычных действий (особенно в последнее время).
Багом, в данном случае, является то, что не запланировано.
То есть возможность компилятора собирать некорректный код была запланирована? Ну просто к багам ты это причислять не стал.
Деление на ноль с самого начала должно было приводить к неопределённому поведению.
Ну хорошо, а если числа с плавающей точкой? Они не далеко ушли, там 0.0 / 0.0 чудесным образом выдаёт -0.000000000. А хочешь интересный факт? Я прямо сейчас решил проверить, а что выдаст сишный printf. Очевидно - nan. Просто сослался на неопределённое поведение (вообще говоря определённое, см. IEEE754) и всё! Зачем искать баг?
Я ничего не оправдывал и не оправдываю.
Ты прям щас этим занимаешься. Компилятор кривой - это факт. Часть багов исправлена, да. А вот чудеса парсинга у нас не баг! Да любому нормальному человеку очевидно, что так быть не должно. Или у меня какие-то неправильные представления о людях?
Я лишь делаю свой личный проект, не претендующий на значимость в текущей системе.
Дискорд сервер с недвусмысленным Community в названии; перевод правил и прочего read-only на несколько языков на этом сервере; сайт, перечисляющий преимущества языка; сравнение языка с C, C++ и Zig в твоей статье; цитируя ту же статью:
В языке программирования Rave весь синтаксис, в целом, похож на синтаксис языка С. Это было сделано, чтобы С и С++ программисты могли за пару-дней полностью освоить Rave и свободно на нём писать.
Напомню:
личный проект, не претендующий на значимость в текущей системе
Говоря, кстати, о личном:
Хоть это - лишь часть всего, что есть в Rave, я считаю, что этих примеров достаточно, чтобы оценить уровень работы, которую провёл лично я и участники моей команды.
Так команда оказывается есть? Ну точно личный проект! Я-то знаю, что команды нет, но от того ситуация не менее забавная.
Разумеется, лишь я решаю, как его обновлять.
Разумеется, лишь ты решаешь, что стоит признать багом, а что фичей.
Мне была показана лишь малая часть багов.
А самому поискать? Или проект личный, поэтому пофиг на баги? А чё-ж тогда их исправляешь? Или проект слишком личный, чтобы искать баги, но недостаточно личный, чтобы их не исправлять?
Весь язык сейчас находится в постоянном изменении, что можно видеть по
коммитам. Ближе к релизу 1.20 постараюсь стабилизировать состояние.
Очень жду!
На будущее: не прикрывайся объективной критикой, как ты делал это на Discord-сервере.
Я и не прикрывался. Ещё раз я убеждаюсь, что ты не умеешь понимать слова других людей. Критика была, но были и оскорбления. Оскорбления за критику я не выдавал. За здравую оценку твоих когнитивных способностей выдавал, такое было.
Я лишь перестал терпеть неуважительное общение со стороны данной группы лиц.
Да про меня ты много чего наговорить можешь, а другие тебе что сделали? Даже если ты предоставишь весомые аргументы, то им будет больше полугода уж точно. И почему же тогда полгода преступники разгуливали на свободе?!
Если ты реально перестал терпеть, то это подразумевает, что ранее, ты терпел. Ну так покажи оскорбления, я жду. Причём покажи за последние полгода, или сколько там новому чату. Если в новом чате не было ничего такого, то что же ты терпел тогда? Или просто выжидал удачный момент, чтобы забанить?
Если нужны доказательства - у меня полно доказательств с вашей травлей людей и рейдами серверов.
Было дело. Подобные ситуация, правда, делились на два вида: про которые ты не знал, и которые ты поддерживал. Сам-то ты тоже не белый и пушистый. Перед тем, как грозиться выставить чьи-то плохие действия на публику, убедись, что ты сам нигде не оступился.
Обсуждения языка перешло в какие-то личные разборки, поэтому предлагаю перейти в более приватное место. Отвечать тебе в комментариях я больше не буду. Всю контраргументацию прошу скинуть мне в ЛС.
Норм язык. Хорошая попытка хотя бы для повышения мастерства.
Хотелось бы знать Ваши "критики" сами хоть пол-языка, хоть четверть написали?!
По языку
Качнул, посмотрел.
Плюсы: легковесность реализации, маленький объём кода
Минусы: однозначно проект ожидает забвание, ибо получился обычный С++. То есть можно просто взять подмножество (subset) С++ - и будет тот же Rave (с незначительными различиями).
Таким же был язык Mash https://habr.com/ru/articles/508096/ - калька Паскаля. Итог - хоть автор был талант, проект заброшен.
PS По науке делате либо по наитию? Книгу Дракона читали?
PPS У меня в планах сделать VM-ку и реализовать на ней JavaScript "на минималках". Больше пользы и успеха будет. Надумаете - присоединяйтесь.
Привет. Спасибо за комментарий.
Я не читал книги по LLVM, лишь документацию и некоторые презентации.
Насчёт "подмножества С++" - был бы рад услышать ваши возможные идеи по поводу улучшения языка в более лучшую сторону.
Здесь несколько аспектов:
1. Rave улучшить нельзя. Он будет таким как есть: типизированный язык с Си-подобной грамматикой.
Прямые аналоги (и конкуренты, естественно) от монополистов - Java (Оракл) и Go (Гугл). Всё то же самое. Разницы между С++, Java, Go, Rave - вообще не вижу: плюс-минус незначительные различия в синтаксисе на уровне "синтаксического сахара", которые опытный программист схватит "на лету".
2. Поделитесь - какую проблему Вы решаете новым языком либо в чём его новаторство? (отсюда станет ясен его круг пользователей и востребованность)
Например, главное новаторство Java декларировалось в том, что за счёт VM-ки Java должна была стать "кросплатформенной": скомпилировал код один раз - и он работает на любых платформах и устройствах. Правда, жизнь показала, что это никому не нужно т.к. Си "кросплатформенный" и без того: в компиляторе Си достаточно заменить один ассемблер на другой, что достаточно просто, - и вот те же алгоритмы работают уже на любых устройствах.
3. Что до Хабра, то вот замечательная статья Башеева - делает всё по науке: (Си-подобная) грамматика->BNF/EBNF->AST->VM-ка https://habr.com/ru/articles/560356/
4. Сам, являясь "адептом" DSL-Based Development ( https://ru.wikipedia.org/wiki/Языково-ориентированное_программирование ) не вижу смысла описывать грамматику инчае как в BNF/EBNF/PEG и перегонять её в AST специальным инструментом. Вот интересный легковесный вариант, легко портируемый на Си (но я его пока не пробовал).
OmNom.js - Lightweight (Almost) Universal BNF Parser, pure JavaScript, ~300 LOC https://github.com/myfoundation/OmNom.js
Там в репозиториях есть и другие интересные варианты VM-ок и языков. Чего стоить только fe от rxi в 24К кода! https://github.com/myfoundation/fe
Так же вот очень интересный набор инструментов, облегчающий разработку грамматик GOLD Parsing System Multi-Programming Language, Parser http://goldparser.org/
Таким же был язык Mash https://habr.com/ru/articles/508096/ - калька Паскаля. Итог - хоть автор был талант, проект заброшен.
Это прям официально, или просто вывод на основе того, что никаких признаков жизни нет уже 4 года? Не то чтобы разница большая, но мне проект был интересен, поэтому будет обидно услышать, что раработка уже точно не будет продолжена.
Публикации
Язык программирования Rave