LINUX.ORG.RU

beef - новый системный ЯП

 , ,


1

8

https://www.beeflang.org/

Особенности:

  • По заявлению автора, представляет собой смесь C++ и C#, с небольшими вкраплениями Rust.
  • Без GC, JIT и тому подобного.
  • Развивается параллельно с IDE (написана на самом beef и собственном тулките). Дизайн языка развивается с учётом удобства разработки IDE.
  • Автор делает упор на удобную отладку с помощью дебаггера, а не print.
  • Умеет все модные фичи: ADT, pattern matching, лямбды, дженерики, миксины, кортежи, опциональные типы и тд. Но не гарантирует null-safety.
  • Поддерживает рантайм рефлексию.
  • Не использует исключения. Используется тот же подход что и в Rust: Result + panic.
  • Проверяет проблемы с памятью в рантайме в отладочной сборке. В релизной сборке всё как в C/C++.
  • Предоставляет лёгкое взаимодействие с C/C++ кодом (не уверен в каком виде).
  • Основан на ворованном LLVM. Как будто кто-то сомневался.
  • Автор пилит язык последние 5 лет full-time.

Простой пример:

static Result<uint> GetMinusOne(uint i)
{
    if (i == 0)
        return .Err;
    return .Ok(i - 1);  
}

void Use()
{
    /* Handle result via a switch */
    switch (GetMinusOne(i))
    {
        case .Ok(let newVal): Console.WriteLine("Val: {}", newVal);
        case .Err: Console.WriteLine("Failed");
    }

    /* This invokes an implicit conversion operator, which will be fatal at runtime if an error is returned */
    int newVal = GetMinusOne(i);

    /* Result<T> contains a special "ReturnValueDiscarded" method which is invoked to facilitate failing fatally on ignored returned errors here */
    GetMinusOne(i);
}

В целом ближе к D, чем к Rust, так как содержит намного меньше гарантий.

★★★★★

Последнее исправление: RazrFalcon (всего исправлений: 3)
Ответ на: комментарий от anonymous

Нет(utf16, можно сказать, были). Ну и преимуществ перед utf8 совсем никаких

Что значит «были»? В Qt QString/QChar 16-битные. Преимущества по сравнению с UTF-8 заключаются в том, что я, например, знаю, сколько символов содержится в строке.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

В случае C++ это уже не парсер, а компилятор

Нет. Да, я знаю насколько сложно разобрать c++ код - доказано теми самыми самописными парсерами, которые постепенно выкидывают в пользу шланга. Но компилятор - это не только синтаксический анализ

Идея

Загуглил по диагонали, компилятора и отладчика своего у них нет(речь не о java)

anonymous
()
Ответ на: комментарий от Zhbert

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

Ты, наверное, из тех, кто пишет на сишечке в блокноте и яро против любого автокомплита?

Я пишу в nano, я пишу в редакторах с подсветкой, я пишу в IDE. Причем, всё это в рамках одной и той же программы. Чем лучше язык, тем больше он дает возможностей программисту работать с ним, и тем меньше требует дополнительных инструментов для элементарных действий.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Для метапрога кстати дополнительных инструментов вообще не требуется, он сам по себе IDE, и в нем уже встроена СКВ, плюс всякие социальные штуки, типа мессенджера, в котором я уже сижу!

insw
()
Ответ на: комментарий от byko3y

Что значит «были»?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0618r0

UTF-16/UTF-32 строки в плюсах есть

Были

В Qt QString/QChar 16-битные

Qt, конечно, распространённое решение, но к c++ формально не относиться

Преимущества по сравнению с UTF-8 заключаются в том, что я, например, знаю, сколько символов содержится в строке

Неверно. Ибо есть композитные символы(ну если только NFC делать кажный раз, но это лол)

anonymous
()
Ответ на: комментарий от anonymous

Да, я знаю насколько сложно разобрать c++ код - доказано теми самыми самописными парсерами, которые постепенно выкидывают в пользу шланга. Но компилятор - это не только синтаксический анализ

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

Но компилятор - это не только синтаксический анализ

С/C++ нельзя распарсить синтаксическим анализатором.

Загуглил по диагонали, компилятора и отладчика своего у них нет(речь не о java)

CLion оборачивает GDB и LLDB в свои инструменты.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

BTW, с utf16 даже NFC дело не спасает. utf16 - это мультибайт, самый настоящий(не с самого рождения, разумеется, но уже очень давно)

anonymous
()
Ответ на: комментарий от byko3y

Qbs сделали для Qt Creator-а.

О мертвых либо хорошо, либо никак. На этом закончим.

C++ невозможно в общем случае распарсить на машине тьюринга

Да что вы говорите? :-0
И как же совеременные компиляторы его парсят тогда?

trex6 ★★★★★
()
Ответ на: комментарий от WatchCat

Ты предлагаешь убить Ритчи и Страуступа?

Ритчи сдох уже, при невыясненных обстоятельствах.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Из разницы придумывается разве что оптимизация

Ну да, оптимизация(на уровне языка и target-arch), кодогенерация, компоновка, поддержка отладки/профилирования/иного инструментирования. Всего-то ничего

С/C++ нельзя распарсить синтаксическим анализатором

Как скажешь. Смысла это не меняет

CLion оборачивает GDB и LLDB в свои инструменты

Значит ли это, что gdb и lldb разрабатываются в составе CLion?

anonymous
()
Ответ на: комментарий от trex6

Это была эвристика. Формальная сторона вопросов не вызывает

anonymous
()
Ответ на: комментарий от trex6

Прекрасно в курсе. Но кроме конкретно кодировки, unicode предоставляет ещё кучу фич, которые уже работают уровнем выше. Поэтому в Rust есть байты, а есть char.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

Нет нормальных строк нигде, кроме кода, использующего ICU. А для простых случаев wchar_t хватает(а для большинства случаев - и простого char)

anonymous
()
Ответ на: комментарий от byko3y

Преимущества по сравнению с UTF-8 заключаются в том, что я, например, знаю, сколько символов содержится в строке.

Это уже давно устаревшая информация. Для ответа на данный вопрос нужно сначала определится что вы понимаете под символом, ибо вариантов очень много.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Ну вот раст и содержит часть icu. Остальное в доп. либах. Всё как у людей.

А для простых случаев wchar_t хватает(а для большинства случаев - и простого char)

Эдик, залогинся.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от Legioner

Язык моей мечты вообще должен позволять пробелы в идентификаторах.

Это Fortran.

monk ★★★★★
()
Ответ на: комментарий от RazrFalcon

Я не говорил про раст. То, что там есть байты, а есть символы(и это не одно и то же, как в C/C++) - правильно.

Эдик, залогинся

Эдик бы меня на костре сжог, была б его воля(я же utf8 считаю наилучшим вариантом для кодирования произвольного текста)

anonymous
()
Ответ на: комментарий от Legioner

Почему безальтернативно? Никто не мешает написать свою IDE, если она так уж плоха, ещё и денег на этом заработать. Например как это сделали Jetbrains, причём неоднократно

Jetbrains заработали на маркетинговом бюджете погибшего Sun. Это примерно как если бы фольксваген сделал безумно ломучий автомобиль, а потом Вася Петров из Саратова создал фирму Автомозги по ремонту этих фольквагенов, отжав у VAG прибыль.

Но многословность как раз упрощает код для последующего восприятия

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

А выведение типа локальных переменных

Вывод типов нужно не для сокращения размеров кода

и лямбд

у этих вообще типа «как бэ» нет

anonymous
()
Ответ на: комментарий от anonymous

И ты вот считаешь нормальным факт наличия целой касты барыг, нахлебников, паразитов и торговцев воздухом, возникшей на почве ублюдочного дизайна большинства существующих ЯП?

Люди работают.

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

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

Ну я тебя поздравляю, причём искренне. Таких, как ты, меньшинство. Большинство же IDE вообще отучают мыслить.

Да, по опыту общения я склонен считать его хорошим кодером, и больше не пытаюсь троллить его первыми приходящим в голову бредом - самому потом будет стыдно.

byko3y ★★★★
()
Ответ на: комментарий от RazrFalcon

Что именно: про rust или про utf8? )

anonymous
()
Ответ на: комментарий от anonymous

Вывод типов нужно не для сокращения размеров кода

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

bread
()
Ответ на: комментарий от bread

Как побочный эффект сокращается и количество писанины

Да, но только не таким образом, как ты думаешь

Но главная фишка конечно в том, что компилятор помогает кодеру с типизацией

Компилятор помогает кодеру _типизацией_, а не _с типизацией_. И делает он это выдавая ошибки при компиляции

а не кодер компилятору все разжевывает и в клювик кладет как принято (почему-то) в индустрии

Действительно, к чему бы это?

anonymous
()
Ответ на: комментарий от byko3y

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

Есть многословность, а есть бойлерплейт. Бойлерплейт это когда я одно и то же повторяю несколько раз. Например объявляю поле, указываю private (не нужно т.к. подразумевается), указываю тип и название (нужно). Потом объявляю геттер: указываю public (нужно), тип (не нужно тк дубликат), название (не нужно тк идентично названию поля), тело метода (не нужно тк типовое). В сеттере вообще ничего не нужно кроме факта его существования. Такая многословность не нужна.

А когда многословность несет смысл сама по себе, это хорошо.

Впрочем вывод типов локальных переменных штука спорная, тк провоцирует писать плохой код. Например var l = new ArrayList<String>() вместо List<String> l = new ArrayList<>(). В общем я бы рекомендовал использовать её очень выборочно. Когда это действительно убирает дублирование.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

Неверно. Ибо есть композитные символы(ну если только NFC делать кажный раз, но это лол)

Есть особая порнуха, которая позволяет запихивать бесконечное число символов в один символ. Но это не значит, что кто-то будет с таким текстом всерьез работать. Для обычного текста всех народов Земли юникода хватает и композитные символы не нужны.

byko3y ★★★★
()
Ответ на: комментарий от trex6

И как же совеременные компиляторы его парсят тогда?

Они угадывают значение байтиков в исходнике на основе ранее упомянутых символов. По этой причине весь проект нужно компилировать целиком, и только так - отдельный исходник крестов не несёт никакого смысла для парсера/компилятора.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Зачем всех народов, мы русские, с нами бог нам хватит и koi8-r! Нинужны ваши хрюникоды. Всем по байту!

Но вообще utf16 лучше utf8 в том что там более простая обработка ошибочных последовательностей, на этом вроде бы и все.

insw
()
Последнее исправление: insw (всего исправлений: 1)
Ответ на: комментарий от byko3y

позволяет запихивать бесконечное число символов в один символ

Чёт ты сегодня в ударе. Снова мимо.

Для обычного текста всех народов Земли юникода хватает и композитные символы не нужны

Осталось объяснить это пользователям, как-то так например: «если у вас по какой-то причине строки в NFD, вы не нужны» ) А если серьёзно - кто бы сомневался, что юникода хватает. Только композитные символы введены, ВНЕЗАПНО, тем самым юникодом

Но это не значит, что кто-то будет с таким текстом всерьез работать

Хотя есть подозрение, что твой аккаунт угнан Iron_Bug

anonymous
()
Ответ на: комментарий от byko3y

нужно компилировать целиком, и только так - отдельный исходник крестов не несёт никакого смысла для парсера/компилятора

А, я понял - ты потралить решил. Ну не смешно же нифига. Ибо раздельная компиляция есть в крестах с самого рождения(на самом деле намного младше этих крестов)

anonymous
()
Ответ на: комментарий от anonymous

Ну да, оптимизация(на уровне языка и target-arch), кодогенерация, компоновка, поддержка отладки/профилирования/иного инструментирования. Всего-то ничего

Вас (сидящих в этом треде) разбалывали инструментами стоимостью в сотни человеколет, и вы совсем забыли, что компилятор Си пишется за несколько месяцев. А про оптимизацию, как про отличие парсера C/C++ от компилятора, я уже упомянул. В остальном clang точно так же выдает обработанные исходники в виде байткода LLVM или в виде глобального индекса.

Значит ли это, что gdb и lldb разрабатываются в составе CLion?

Нет. В составе CLion разрабатывался только сосбтвенный встроенный отладчик.

byko3y ★★★★
()
Ответ на: комментарий от RazrFalcon

Преимущества по сравнению с UTF-8 заключаются в том, что я, например, знаю, сколько символов содержится в строке.

Это уже давно устаревшая информация. Для ответа на данный вопрос нужно сначала определится что вы понимаете под символом, ибо вариантов очень много

Символ текста - это то, что будет читать и писать прямоходящая макака с целью обмена информацией с сородичами.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

компилятор Си пишется за несколько месяцев

Ты не упомянул, сколько человек будут это делать. Впрочем, с твоими представлениями о компиляторах, фразу как-то так надо понимать: «за несколько месяцев пишется нечто, умеющее хоть как-то компилировать хэлворд под одну архитектуру»

CLion оборачивает GDB и LLDB в свои инструменты.

Значит ли это, что gdb и lldb разрабатываются в составе CLion?

Нет. В составе CLion разрабатывался только сосбтвенный встроенный отладчик.

Т. е. там нет своего отладчика? В общем, как я и говорил - есть только две IDE(по википедии) - msvs и borland

anonymous
()
Ответ на: комментарий от Legioner

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

Есть многословность, а есть бойлерплейт.

У меня очень близкая позиция с аноном, и я не есть он, но я попытаюсь отвечать за него. Он писал:

Предполагают излишнюю многословность на ровном месте, заставляя кодера уповать на автокомплит и, соответственно, усложнять код для последующего восприятия (жаба с сисярпом — ярчайшие примеры)

И здесь имелосся в виду именно бойлерплейт в твоей интерпретации. Можно говорить о том, что у нас троих одинаковая точка зрения - просто мы пользуемся отличающимися определениями. Java by-design провоцирует большое количество boilerplate кода - это так. Потому IDE, потому такое число альтернативных языков для JVM. Поэтому Гослинг признал, что главной ошибкой в проектировании языка Java были классы - фундаментальный и бесполезный boilerplate.

Впрочем вывод типов локальных переменных штука спорная, тк провоцирует писать плохой код. Например var l = new ArrayList<String>() вместо List<String> l = new ArrayList<>().

Здесь я бы склонялся к убогости конкретного жавового вывода типов.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

это ты зря так думаешь, когда во все поля везде эти сраные емодзи и их таки надо уметь

Эмодзи не являются текстом. Нужно уметь - умей. Я пишу только про обработку текста.

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от insw

Но вообще utf16 лучше utf8 в том что там более простая обработка ошибочных последовательностей, на этом вроде бы и все

Давай, придумай мне алгоритм перехода на предыдущий символ в UTF-8 строке.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

Компилятор помогает кодеру типизацией, а не с типизацией. И делает он это выдавая ошибки при компиляции

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

anonymous
()
Ответ на: комментарий от anonymous

Ибо раздельная компиляция есть в крестах с самого рождения(на самом деле намного младше этих крестов)

Это ты про hello world на ренжах из 15 строчек, который компилируется две секунды, потому что компилятор вынужден пропускать через себя 100+ тысяч строк?

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Это я про _все_ проекты на c++ из более чем одной единицы трансляции

anonymous
()
Ответ на: комментарий от anonymous

Вывод помогает формулировать типы там, где ты без поллитры их не аннотируешь

Да, в обобщённом коде. Там их и «с поллитрой» не «аннотируешь». Только это не «помощь с типизацией»

anonymous
()
Ответ на: комментарий от byko3y

Поэтому Гослинг признал, что главной ошибкой в проектировании языка Java были классы - фундаментальный и бесполезный boilerplate.

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

anonymous
()
Ответ на: комментарий от byko3y

Д̹̅ͪ͟͠ӓ̴̛̹͙͎̩͇́̈̏ͩ͂̋̀ ̷̯̎̍̈͆͂ͣ̿ͣ͠ч̸̬̤̳̞̮̝̺ͬͭͤͯ̕͘т̞͓̩̻̬ͦͥ̑̓̍ͪ̊̈́͒о͍̪̰̲̼̖̜̔̐͌ͥ͢ ̥̗̣̀ͨ͋̂в̻͓̱̬̖̬͓̃̓ͭ̅̓̓̑̚͝ы͓͓̭̣̓ͩͤ̐̽ ͎̹̬̹̦̳̦̑͂͆ͭͧ̿ͭͅг̰̤͕͖̫̞̦͕̻̈́̓͗͗ͩ̀̚͠͝о̶̱̥̫͕̟̱̝̒͐ͅв̧̺͍̩̆ͨ̊͝о̛̮͍̹̫̮̓͐̎̅̿̑͗ͩ͘р͓̘̖͔̗͇ͧͣ̏͂ͦͯ̀͢и̣̃̌̿̐͛̈͘͜т̬̖̳̙̩̲̦̹͛͂̑еͩ̆̏͂̃͗̾͊҉҉̙̮̲.̸̷͙͔͖͓̤̺̮̣ͪ͗̿͘

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от byko3y

Эмодзи не являются текстом.

Ничего путнего я от вас не ждал, но всё равно смешно.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от anonymous

компилятор Си пишется за несколько месяцев

Ты не упомянул, сколько человек будут это делать. Впрочем, с твоими представлениями о компиляторах, фразу как-то так надо понимать: «за несколько месяцев пишется нечто, умеющее хоть как-то компилировать хэлворд под одну архитектуру»

Да, ты всё правильно понял. Только вот не понял, что результат разбора кода при помощи clangd находится в единственном шаге от готового машинного кода - просто некоторые еще проводят многоуровневые оптимизации перед генерацией кода. Потому что парсер C/C++ не может просто оперировать абстрактным типом - ему нужно знать полностью семантику всех конструкций. А когда вся семантика разобрана, то осталось только построить машинные коды по ней.

Т. е. там нет своего отладчика? В общем, как я и говорил - есть только две IDE(по википедии) - msvs и borland

Интерфейс CLion не имеет ничего общего с интерфейсом GDB. С таким успехом ты мог бы говорить о том, что GDB и CLion - это близкие проекты, потому что оба работают на линуксе. Да, отладчик CLion использует GDB в своей работе. Они бы с радостью сделали полностью изолированный отладчик, если бы отладка C/C++ не была такой сложной - потому в качестве «бэкэнда» используется GDB/LLDB.

byko3y ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.