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

да, но зачем привыкать к нему, когда есть другие, более удачные синтаксисы, например си-подобный.

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

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

Почему?

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

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

Именно поэтому бывалых прогеров на сях можно отличить по тому, что они константы в сравнении ставят впереди переменных, чтобы компилятор выдал ошибку в случае опечатки.

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

Миллионы программистов пишут на жаваскрипте, в котором эта проблема применима вообще ко всему, к названиям, параметрам, типам, и ничего, живут как-то.

Исключения это нетипизированная нашлёпка на (возможно) типизированный язык. Это так. Хочешь стабильности - пиши тесты. Возвращаемые ошибки и проверяемые исключения это типизированная обработка ошибок. Всё так. Этим они лучше. Но ты платишь на это бойлерплейтом. И если в случае с основным кодом программы я соглашусь, что типизация того стоит, то в случае с ошибками не соглашусь. Хотя считаю, что можно сделать проверяемые исключения лучше, чем они сделаны в джаве и они будут юзабельны. Но считать я могу что угодно, а по факту в джаве они неудобные а остальные и делать не стали. Возвращаемые ошибки как в го это полное уродство. В расте и, вроде, в новых версиях го, они подлатали это всё синтаксическим сахаром но всё равно лично для меня обычные исключения удобней. Не меняют адекватные либы в публичных API ничего на ровном месте.

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

Предлагаю убить тех, кто бездумно повторяет их ошибки.

во многих языках в if ограничено выражениями только типа bool.

Нужно учить языки…

if (i = 0) { // типа ошиблись и написали = вместо ==
    /*...*/
}
Error(s):
    Cannot implicitly convert type 'int' to 'bool'
fsb4000 ★★★★★
()
Ответ на: комментарий от eagleivg

Потому, что легким движением руки сравнивание превращается в присваивание.

Это проблемы тех языков в которых bool тождественен int и/или оператор присваивания возвращает значение.

error[E0308]: mismatched types
 --> src/main.rs:4:8
  |
4 |     if t = 4 {
  |        ^^^^^
  |        |
  |        expected bool, found ()
  |        help: try comparing for equality: `t == 4`
WatchCat ★★★★★
()
Последнее исправление: WatchCat (всего исправлений: 2)
Ответ на: комментарий от Legioner

Хочешь стабильности - пиши тесты.

Зачем? Пусть за меня это делает компилятор.

и ничего, живут как-то

TypeScript, Reason, PureScript, Elm, …

В расте и, вроде, в новых версиях го

В Go всё по-прежнему убого. И на Rust ни разу не похоже.

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

Просто время компиляции?

Ага, «просто». Ждать 30сек на топовом железе пока syn соберётся такое себе удовольствие.

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

Зачем? Пусть за меня это делает компилятор.

Компилятор знает, что ты хочешь получить 2, а не 11?

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

компилятор не может проверить твои логические факапы при обработке данных на всевозможном (или близко к всевозможному) сете этих днных

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

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

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

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

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

Иди-ка ты в свой загон к своему гуру квадратных уравнений и урановых паровозов. Может, расскажешь ему наконец, как под 64-битные системы что-то компилировать, а то как-то вообще… как вы там, муздюки, говорите… кринжово получается.

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

Может, расскажешь ему наконец, как под 64-битные системы что-то компилировать

Это сейчас бессмысленно.

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

Ну если тебе удавалось избегать syn - молодец. Но по-моему он как грипп, в конце концов добирается до каждого.

Не тащишь в библиотеку - один в поле воин

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

Потому что:

  1. Безальтернативно привязывают автора к определённой рабочей среде, которая может быть тем ещё УГ, а в особо запущенных случаях — ещё и к недоОС, а в самых запущенных — к недоОС на недоархитектуре (привет, метапрог);
  2. Делают кодера беспомощным в гетерогенных средах, когда изначальное кодописание делается в одном месте, а чтение и правку приходится осуществлять уже за пределами уютненькой IDE-шечки;
  3. Предполагают излишнюю многословность на ровном месте, заставляя кодера уповать на автокомплит и, соответственно, усложнять код для последующего восприятия (жаба с сисярпом — ярчайшие примеры);
  4. Своей невыразительностью принуждают прибегать к адовым костылям вроде подсветки синтаксиса.

В современных условиях ЯП надо проектировать так, как будто IDE для него нет и никогда не будет. В противном случае автор даёт себе карт-бланш на абсолютно любую дичь, что мы и наблюдаем в данном случае, как и во многих других.

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

Это сейчас бессмысленно.

А без них как-то беспощадно.

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

Когда ты осилил выйти из vi и считаешь себя гением

Четко вы сейчас любителей IDE опустили.

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

Популярность языков говорит о том, что не надо маргинальными критериями руководствоваться.

Популярность некоторых языков говорит лишь о том, что 95% населения — идиоты, а их руководство почему-то возомнило, что состоит в оставшихся 5%.

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

Безальтернативно привязывают автора к определённой рабочей среде, которая может быть тем ещё УГ, а в особо запущенных случаях — ещё и к недоОС, а в самых запущенных — к недоОС на недоархитектуре (привет, метапрог);

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

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

Почему беспомощным? Я вот пишу на Java. У меня нет никаких проблем хоть в Wordpad код править. Тем более, что небольшие правки, как правило, вообще без разницы где делать. Тут скорей вопрос к системе сборки. Если система сборки не привязана к IDE, проблем быть не должно.

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

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

Но многословность как раз упрощает код для последующего восприятия. createDirectory() это гораздо понятней mkdir. Собственно для того и пишут многословный код: чтобы его было проще читать. Язык моей мечты вообще должен позволять пробелы в идентификаторах. Вот бы я развернулся.

fun сумма пенсионных накоплений(лицо: физическое лицо): double {
    var пенсионные накопления: double = 0.0;
    for (родственник: лицо.родственники) {
        пенсионные накопления := пенсионные накопления + сумма пенсионных накоплений(родственник);
    }
    пенсионные накопления := пенсионные накопления + лицо.пенсионные накопления;
    return пенсионные накопления;
}

эх, код моей мечты.

Своей невыразительностью принуждают прибегать к адовым костылям вроде подсветки синтаксиса.

Субъективно. Мне вообще подсветка синтаксиса не нужна, например. Мне достаточно подсветки лексики.

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

Ну если тебе удавалось избегать syn - молодец.

Удавалось и удаётся. Для большинства либ что его используют есть альтернативы.

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

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

anonymous
()

В целом ближе к D

Автор страдает хернёй. Лучше бы запилил no-GC стандартную библиотеку для D.

no-such-file ★★★★★
()
Ответ на: комментарий от Legioner

Непонятно, что не так с исключениями

С ними всё так, но автор не осилил исключения без GC, или просто не хочет делать C++ 2.0

no-such-file ★★★★★
()
Ответ на: комментарий от Legioner

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

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

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

Почему беспомощным? Я вот пишу на Java. У меня нет никаких проблем хоть в Wordpad код править.

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

Но многословность как раз упрощает код для последующего восприятия. createDirectory() это гораздо понятней mkdir.

Ты не совсем понял, что я под многословностью подразумеваю. Не в идентификаторах дело. Для меня createDirectory и mkdir одинаково понятны. И одинаково полезны… если для их использования не приходится писать какое-нибудь DirectoryCreatorInterfaceFactory и оборачивать всё в классы.

Бич той же жабы — туча бойлерплейта, не несущая никакой полезной нагрузки. Вот к чему у меня претензии.

Мне вообще подсветка синтаксиса не нужна, например. Мне достаточно подсветки лексики.

Опять же, таких, как ты, меньшинство.

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

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

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

Если тебе неудобно управлять busybox vi, выкидываешь себя.

вещает в треде ниасилятор ed

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

В современных условиях ЯП надо проектировать так, как будто IDE для него нет и никогда не будет

Ты какой-то школьник, проектируй ЯП так, что у тебя нет монитора и никогда не будет, только перфокарты.

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

Нужно смотреть в будущее и проектировать новый ЯП так, чтобы его легко было диктовать Алисе или Сири

Впрочем, Метапрог для AR-очков в виде летающих вокруг блок-схем тоже неплохо. Ходить по антикафе, заполненному летающими в воздухе блоками и пальцем рисовать связи

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

Школьники вроде тебя с их кривыми аналогиями (вследствие кривого мозга) никогда с промышленными разработками не сталкивались. Откуда же им знать, в каких условиях людям порой приходится писать и — самое главное — читать код? Но мнение своё имеют, как же.

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

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

А, ясно, компилёж головного мозга и слепая вера в то, что статический типиздец решит все проблемы со входящими данными. Следующий.

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

статический типиздец решит все проблемы со входящими данными

Всех проблем не решит, но позволит удобно описать контракты для входных данных и связать их с реальными типами. Например:

https://github.com/ianstormtaylor/superstruct/blob/master/Readme.md

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