LINUX.ORG.RU

Bosque - очередной убийца C++ от MS

 


1

4

https://github.com/microsoft/BosqueLanguage

Основные фичи:

  • GC в виде счетчика ссылок, ага
  • immutable
  • нет циклов, только функциональщина
  • дженерики, в том числе variadic
  • sum types/adt
  • синтаксически, смесь C++, Rust, Swift и OCaml, но страшнее
  • optional - часть языка, ака оператор ?
  • рекурсия должна быть явно объявлена через ключевое слово recursive
  • трансплитер написан на typescript и выплёвывает C++ (но это не точно)
  • они ещё используют Z3, но не ясно как именно

Пример:

entity Person {
    field name: String; 
}

function foo(arg?: {f: Int, n?: String} | String | Person): String {
    if(arg == none) {
        return "Blank";
    }
    else {
        return switch(arg) {
            type Record => arg.n ?| "Blank"
            type String => arg
            type Person => arg.name
        };
    }
}

foo()                    //"Blank"
foo(none)                //Type error - none not allowed
foo("Bob")               //Bob
foo(Person@{name="Bob"}) //Bob
foo({f=5})               //"Blank"

foo({f=1, n="Bob"})      //"Bob"
foo({g=1, n="Bob"})      //Type error - Missing f property
★★★★★

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

Тут немного про другое. Например в расте проверка границ массива производится при каждом обращении. То есть Си-стайл for будет тупить. С другой стороны, ФП позволяет сделать нужные проверки лишь один раз, так как мы заранее знаем что будет делать код.

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

Вообще-то, при чём здесь С?

Например в расте проверка границ массива производится при каждом обращении. То есть Си-стайл for будет тупить.

Если мы про то, как оно сделано в расте, то посчитайте накладные расходы на реализацию такого подхода, будьте любезны?

С тем и хорош что можно либо вообще не проверять границ, либо разово это делать, либо при каждом обращении. Всё зависит от решаемой задачи. Почему (мне просто интересно) программиста всенепременно нужно считать идиотом и укладывать в прокрустово ложе «только так и не иначе»?

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

Ну да. А что, бывают случаи, когда мы не знаем что будет делать код? =))) Серьёзно? Я понимаю что А. Кларк был прав, но не до такой же степени технологии к магии-то сводить? =)))

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

А. Т.е. если с пониманием использовать for, то всё будет хорошо. А если как придётся - всё будет плохо.

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

Т.е., мы собираемся решать неразрешимую задачу? Странное что-то с программированием творится…

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

Т.е., мы собираемся решать неразрешимую задачу?

В общем случае эта задача алгоритмически не решается.

Странное что-то с программированием творится…

Не было бы «странности», не было бы программистов, яростно спорящих на форумах.

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

В общем случае эта задача алгоритмически не решается.

Да. Про то и речь. Зачем пытаться решать нерешаемую задачу?

программистов

Понятие «программист» уж больно широко толкуется. По-моему, нормальный программист должен понимать что нужно делать, а что нет.

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

Зачем пытаться решать нерешаемую задачу?

Никто/ничто не мешает знать решение для частных (конкретных) случаев, для алгоритмов «без циклов», для неполных по Тьюрингу ЯП.

нормальный программист должен понимать

Есть программисты, которые знают/понимают некоторые алгоритмы, но не знают другие. Какие алгоритмы надо понимать, чтобы быть «нормальным»?

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

Ага..

Внезапно, но в раст - тоже.

Вот только тогда смысл раста ускользает. Типа, «мы на расте, мы не такие как все»? Если в том же С можно писать безопасный код, если следовать рекомендациям CERT Secure Coding for C & C++? Ну и если использовать инструментарий для самоконтроля (тот же splint), например.

Чем же тогда Раст лучше С?

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

Никто/ничто не мешает знать решение для частных (конкретных) случаев, для алгоритмов «без циклов», для неполных по Тьюрингу ЯП.

Конечно ни кто и ни что не мешает.

Есть программисты, которые знают/понимают некоторые алгоритмы, но не знают другие. Какие алгоритмы надо понимать, чтобы быть «нормальным»?

Ровно те, которые позволяют решать ему стоящую перед ним задачу. В данный момент времени.

Но даже на примере нашего с Вами общения. В ответ на простой довод о том, что программист должен всегда понимать что делает его программа, каково её поведение, Вы приволокли мне один случай когда программа не будет иметь алгоритмического решения. Т.е., априорно Вы предполагаете (Вы же приволокли этот случай, не я?) что программа должна вести себя подобным образом.

Следовательно, получается что Вы заранее готовы к тому, что программа уйдёт в бесконечный цикл, например, и там и останется. Или на ub нарвётесь. Ergo, у Вас плохой стиль программирования. Любое поведение программы, не позволяющее достичь желаемого результата, это либо хреновое её проектирование, либо хреновая запись её кода. В принципе, у меня лично есть довольно спорное убеждение (но оно есть) что если у Вас дело дошло до отладчика, то Вы просто не понимаете как работает (должен работать) Ваш код. Значит, Вы не понимаете что по Вашей формальной спецификации на том или ином языке нагенерил компилятор или как её обрабатывает интерпретатор. «Мои поздравления, Шарик, ты балбес». =)))

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

/thread, т.к. я не вижу что тут ещё можно добавить к сказанному.

anonymous
()
Ответ на: Вообще-то, при чём здесь С? от anonymous

С тем и хорош что можно либо вообще не проверять границ, либо разово это делать, либо при каждом обращении.

Никто не запрещает делать так. Стандартный способ обращения по индексу будет осуществлять проверку, но можно использовать unsafe и работать без проверок, используя, например, get_unchecked. Проверки вообще сами по себе редко являются боттлнеком, хотя и такое случается.

А что, бывают случаи, когда мы не знаем что будет делать код?

Да. Мы всегда знаем, что мы хотим от кода, но не всегда знаем, что он на практике будет делать. Особенно, если он (код) писан, как кое-кто оправдывался, вечером и под шум детей.

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

В том-то и дело.

Никто не запрещает делать так.

Поэтому я и задаю вопрос – чем же Раст столь фатально отличается от С в такую наилучшую сторону, что С (С++) нужно вот прямщас надо бежать хоронить?

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

Да. Согласен. Но тут вопрос в уместности. Если мы осуществляем проверку везде, где ни попадя, то мы просто тупо тратим ресурсы вычислительной системы. Мелочи, но тратим. По сути, ни на что. Если мы конкретизируем случай и будем проверять выход за границы в особо ответственных местах (например, при реализации какого-либо сетевого протокола, в точке, где потенциально может быть уязвимость), то в стандартной библиотеке уже есть ф-ции вида strn, которыми просто следует пользоваться в данном случае, плюс, свои проверки, зависящие от реализации. Простое правило «чистых рук», если угодно. «Не доверяй никому и проверяй ввод. Всегда.» Не хочется использовать библиотечные ф-ции, можно написать свою реализацию для данного конкретного случая. Но колесо не всегда нужно изобретать заново. =)

Правила-то не хитрые. И вовсе необязательно городить для их использования новый, безопасный(?) язык.

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

Отсюда и уязвимости. Либо by design, либо в реализации. Тут грамм размышлений экономит килограмм работы. Поэтому я для себя аксиому и вывел – дошло дело до дебаггера, значит мы не понимаем как работает этот код. Кто-то, помнится, сказал про С++ что это язык для тех, кто не понимает что компьютер это машина, основанная на состояниях. Получили непонятное состояние… Ну, дальше очевидно. И та же парадигма ФП по идее, позволяет увернуться от непонятных состояний программы за счёт того, что минимизируются влияния разных частей кода, которые есть в программе на исполняемый в данный момент кусок кода.

Особенно, если он (код) писан, как кое-кто оправдывался, вечером и под шум детей.

=) В военном ВУЗе, на абитуре, ещё до сдачи вступительных экзаменов, у нас был проф-психотбор. Недостаточно стрессоустойчивые лица выявлялись сразу и к сдаче вступительных не допускались. =) Мне лично сложно принять оправдания такого рода. Пусть пишут ночью, когда все разойдутся по своим кроватям. =) Ну либо свой дзен отращивают и шлифуют…=)))

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

Какие алгоритмы надо понимать, чтобы быть «нормальным»?

Ровно те, которые позволяют решать ему стоящую перед ним задачу. В данный момент времени.

Ты знаешь алгоритм работы printf, когда пишешь программу выводящую «Привет, мир!»?

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

ЛОЛШТА?!? =)))

Ты знаешь алгоритм работы printf, когда пишешь программу выводящую «Привет, мир!»?

ШТАПРАСТИТИ?!? =))) Вам расписать что такое сисколлы и как он (сисколл) в данном случае используется? Осветить вопросы кодогенерации, библиотечных функций, роль линкера и компилятора, плавно потрогать использование ассемблера/дизассемблера…

Простите, но лучше бы этими вещами Вам интересоваться в ВУЗе, либо самостоятельно. Ваше (хочется надеяться) послевузовское образование в круг моих интересов не входит. =)))

Где Вы в алгоритме для printf нашли сложности, я и ума не приложу. =)))

anonymous
()
Ответ на: ЛОЛШТА?!? =))) от anonymous

Где Вы в алгоритме для printf нашли сложности, я и ума не приложу.

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

Начни с простого - просто напиши, как работает printf. Вперед!

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

Батенька...

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

Начни с простого - просто напиши, как работает printf. Вперед!

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

Но тут есть проблема. Я прекрасно знаю что с долбо… (ну, Вы меня поняли) спорить не стоит. Ибо они сперва начнут опускать Вас до своего уровня, а потом давить своим мифическим «опытом».

Так что, в качестве завершения дискуссии с Вами лично, я могу только пожелать Вам лично счастливого пути. Дорогу Вы и без меня знаете. Куда Вам нужно добраться. =)))

Точка, пожалуй.

anonymous
()
Ответ на: Батенька... от anonymous

Опять нагенерил набор слов, которые не понимаешь. Ты - генератор бреда. Что там с printf, и кто «нормальный» программист - ты не можешь объяснить уже которое сообщение подряд.

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