Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Язык Bosque — новый язык программирования от Microsoft

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

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

Вот, например, статейка про этот язык на хабре — habr.com/ru/post/448814 .
Официальный репозиторий — github.com/Microsoft/BosqueLanguage

Судя по тому, что компилятор этого языка написан на TypeScript он, как мне думается, тоже наверное будет компилироваться в JS (правда в отличие от тайпскрипта, в боск наверное преобладает функциональная парадигма, судя по синтаксису).

Кто-то смотрел его? Как впечатления?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

родила царица в ночь не то сына, не то дочь...

Босх насправді був Бош, а це скоріше Боске, як маркіз Вісенте дель Боске ;-)

Або Боск, якщо французською)

Це іспанською, означає «ліс»

Ржака виходить — маркіз Сеня з Лісу))

Ну, що воно означає то окрема тема. З Бетховеном тут важко змагатися — великий класичний композитор Людвіг з-Бурякового-Городу, з-Бурячків ;-)

А мы наоборот, портер из C# в С++ сделали: www.csporter.com

Да я как то спец по статтям :-) Попрошу ребят, может кто то напишет. А нужно?

В языке нет циклов for, while и т.д. Вообще никаких нет. Вместо этого есть коллекции и пайплайны. Другими словами, вместо циклов нужно использовать более высокоуровневые штуки типа map, filter и т.д.

Кто-то может объяснить, как можно реализовать циклы без циклов (в логике)?

Например, через map в Python:
list(map(lambda x:print(x), range(10)))

Там же так и сказано: «вместо циклов нужно использовать более высокоуровневые штуки типа map, filter и т.д.»

Ну и еще заставили усложнить код и запутать его

Чушь собачья, ничего подобного.

Ну вместо того что будет:
val service = EntityProvider fromContext serviceContext
val entities = (FutureOption sequence ids map { _.asJson } map { service.get[FutureOption] }) map {_.as[Entity]}

Писать простыни нечитаемого неподдерживаемого балшито-говнокода на притрушенных defective-by-design императивных языках без намёка на синтаксический сахар:

Task compositeTask;
JSONRPCConnectionPool connectionPool = NULL;
try {
Vector tasks = new Vector(ids.length);
JSONRPCConnectionPool connectionPool = connetionManager.openPool(connectionContext);
if(conectionPool.checkConnectionStatus == ConnectionStatus.OK) {
for (int i = 0; i < ids.length; i ++)
{
try {
if(ids[i] != NULL) {
JsonObject json = Json.emptyObject();
json.add(FieldKeys.entityByIdQueryIdKey, ids[i].toString());
json.add(FieldKeys.Id, i.toString());
ScheduledRequest req = connectionPool.scheduleRequest(
JsonRequest.GetBuisnessRequestBuilder.complete(json)
);
tasks[i] = new Task([req]() => req.awaitResponse());
}
else {
throw new BigBuisnessErrorException("we have null item");
}
}
catch (SomethingBadWithSchedule ex) {
//TODO: retry
}
}
Task compositeTask = Task.fromVector(tasks)
}
}
catch (ConnectionException ex){
//log bulshit
}
catch(BigBuisnessErrorException ex){
//do smth
}
fianly {
if(connectionPool != NULL && connectionPool.status != Status.Closed )
connectionPool.close();
}
Vector results;
if(compositeTask != NULL) {

Vector res = compositeTask.awaitVectorResult();
results = new Vector(res;)
for(int i = 0; i < res.length(); i++)
try {
Entity entity = EntityDecoder.decodeEntity(rest.getResult);
results[i] = entity;
}
catch(Exception ex){
TaskFailure f = res[i].getError();
Logger.log(Error)
}
}
return results;

Семантика вот этой длинной простыни(а такие и в проде бывают на всяких цпп или джявах 7 ее) и того, что в начале — ровно одна и таже. Но простыню невозможно читать и писать, а про правильную работу стоит совсем забыть.

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

В фп тоже есть паттерны но они строятся не вокруг абстракций, а вокруг функций. Эксепшины тоже есть в фп, классика же с точки зрения паттернов — either монада. vimeo.com/97344498
С точки зрения засорения бизнесс логики всяким шумов фп будет на порядок, а то и два читаемей и чище любого ооп языка, благодаря куда более развитой системе типов, отсутсвию побочных эффектов( expressions over statements), декларативности, функциональным паттернам.

Тут нечего срач вести — просто это факт. И ты этим пользуешься или морочишся с недетерминизмом императивных программ с побочными эффектами и тратишь кучу времени на ооп дизайн — толку от этого не много, чем более громоздкий ооп тем более сложно с ним работать, а nullreference ошибки и прочего недетерминизма только больше будет с ростом количества классов.
За последние лет 10 все императивные языки заимствуют свой функционал только у ФП и стараються быть похожими на ФП, вся это кухня с классами и statement based programing и ооп паттернами дизайна ничего нового не предложили и только выгребают критику со стороны community — вот вам тренды. Другое дело, что императивные языки никогда не станут ФП, как максимум будут устранять ошибки раннего дизайна.

Неправда. Як і інше є перебільшенням. ООП розвивається, інтерфейси зняли завязку на реалізацію, депенденсі інджекшин зняв каплінг класів.

Вот один из известных авторов, кто 10 лет назад рассказывал всем как Dependency injection было здорово, перекинулся в функциональный лагерь и начал рассказывать про Dependency rejection, топить за прямые входы, композицию
blog.ploeh.dk/...​-to-dependency-rejection

Ну и куда мы дальше развиваемся?

Найкращий з таких кейсів Edsger Wybe Dijkstra з його ставленням до Haskell як першої мови для студентів

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

До ООП була процидурщина яка хорошо аж ніяк не працювало. Потім прийшов ООП і це була революція. З того часу ООП є основою програмування і активно розвивається. Тепер зявилося потужне залізо що дозволяє реалізувати ідеї ФП.

когда появился ФП?

та это как с выборами просто.

75% впадлу развивать мозг, вот они и тянут языки попроще для айкю.

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

оставшееся 5% можна смоделировать стейт монадой.

Полностью согласен.

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

Усилием воли можно себя заставить делать рациональные решения(в этом собственно, и состоит работа математиков). Кроме того, некоторые рациональные решение уже сделаны на некотором уровне абстракции (ныне разработанные теории). Пользуясь этими рациональными решениями можно обезопасить себя от неприятностей, которые привносят нерациональные решения. ФП на самом деле про это — про рациональные решения и про переход от (рационального)общего к (очевидно)частному.

І за 60 років існування, ще жодна фп мова так і не попала в топ 10 мов

А ви беріть якийсь більш релевантний індекс, наприклад stackowerflow " Top Paying Technologies":

insights.stackoverflow.com/...​9#top-paying-technologies

У топ 10 там є CLojure, F#, Scala, Elixir, Rust, Erlang

Rust імперативний з ФП фішками, запозиченими з Ocaml-а

Вакансий действительно очень мало, но стоит вам погуглить вакансии senior scala(haskell) developer или выше в USA, там будут весьма приличные рейты.

так і не попала в топ 10 мов(тіобе індекс до прикладу)

до речі, а який критерій попадання в tiobe індекс?

до речі, а який критерій попадання в tiobe індекс?

Вони по гугл трендам якось орієнтуються та по пошуковим запитам. Щоби вони почали розглядати мову до свого індексу — необхідно >10к запитів у гуглі по цій мові.

С точки зрения засорения бизнесс логики всяким шумов фп будет на порядок, а то и два читаемей и чище любого ооп языка,

Небудет. Если задача посложнее хелловорлда.

Ок. Давай 2-3 примера и выбранные способы решения на фп и ооп языке.

В функціональщині є rail-way oriented підхід, тобто воно там не валиться, а котиться

Простой тупой пример повседневной задачи, которая есть в любом почти приложении — валидация данных. В ооп непрошаренные юзеры пользуются ифналзенэлсами и ифкондишн зен тров ексепшн/трайкетч файнали. Как видно из той простыни которую я откопал, понять что там происходит с полпинка понять в принципе невозможно, и очень легко что-то сломать. А некоторые уникумы, в этот кот начинают внедрять какую-нибуть логику которая не относится к валидации, потому что понимания у них нет, и потом иди и ищи кто куда чего всунул. Прошаренные товарищи будут юзать какой-нибуть фреймворк/приблуду спринга/ещё какого фрейма которая работает на рефлексии/темной магии, и в которую тоже надо долго въезжать. При том, что каждый такой фреймворк работает по разному, и въезжать надо каждый раз.

В фп для этих целей придумана всего одна абстракция — аппликативный функтор, писать трехметровую простыню не буду, потому что она уже написана: typelevel.org/...​/datatypes/validated.html — Validated это его реализация которая умеет собирать много разных объектов с аккумуляцией ошибок.

Почему Validated лучше в этом случае? Потому что тут люди подумали прежде чем ломится решать конкретную проблему, как это принято у недальновидных императивщиков.

Validated — капля в море функциональных плюшек.

Не бачив такого з часів переходу на фреймворки. Є валідатор, вбиваєш правила. І все.

Ну вот эти фреймворки сделаны на концепциях AOP, который имеет куда более общего с ФП, нежели с ООП.

для начала надо перестать писать всякую фигню.

Именно, потому что AOP это очень плохая реализация тайпклассов через задницу.

Я называю парадигму не подходящей для быстрого написания надёжных, простых и понятных приложений.

Прошаренные товарищи будут юзать какой-нибуть фреймворк/приблуду спринга/ещё какого фрейма которая работает на рефлексии/темной магии, и в которую тоже надо долго въезжать

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

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

Чем это лучше 5 обычных функций? Тем что выглядит нестандартно и загадочно?

Это не способ заменить 5 функций, это способ организовать эти же 5 функций. Это лучше тем что у нас под этим есть абстракция из математики — аппликативный функтор. Тем что мы можем комбинировать валидацию типа A и типа B который составлен из типа А единообразным образом, а что ещё лучше — у нас для этого есть mapN. С функциями так не прокатит.

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

— Концепты
— Дженерики — это недо-темплейты

і той повертає 500 помилку юзеру.

Є таке, іноді ще й з мессаджем «спробуйте пізніше». Дуже корисно.

А ви навмисно зробили, щоб у вас був можливий стан, коли
Succeed = true, і є Warning та Failure messages ?

У функціональщині невалідний стан робиться неможливим. Щоб небуло 500 з «request succeed». Наприклад так (F#):

type Risult<'a> =
    | OK of 'a
    | Warning of string seq
    | Error of string seq

let check a = 
    match a with
    | x when x > 10 -> OK a
    | x when x > 0 -> Warning ["фигня якась"]
    | _ -> Error ["повна лажа"]
І вже на цьому можна отаке реілвей реалізувати.

Тут нет ничего общего с railway программированием. контракт плох с точки зрения sepparation of concerns(дальше с этим обьектом ничего не сделаешь кроме как закинуть в ответ куда-то этот текст — ни сериализации, ни локализации на нем не сделаешь) и type sefty тоже никакой (никакой информации об ошибке за пределами той функциии где этот обьект создан) — null как дефолтные значения для public полей — привет вызывающему коду и девелоперам, что потом будут выгребать в самых неожиданных местах nullreference exceptions, потому что компилятор тут вам не поможет. А решение для псевдо immutability говорит сам за себя(завернутые в аннонимные типы свойства, где все равно осталась семантика сравнения по ссылкам(List< string >), а не значениям) — бажные костыли — вот вам и вся сила ООП ориентированных языков. В ФП рабочие алгебраические типы так работают из коробки, без необходимости писать все это.

railway нормально на C# не сделаешь — там нет pipelining, композиции, каррирования фукнций вшитого в компилятор, нормального pattern matching и юнион типов.

В фп слайді я теж не побачив ніякої інформації в помилці окрім тексту. Може не зрозумів.

В примере, что я скинул выше на ФП, делается discriminated union со всеми возможными кейсам, сериализация выносится в отдельную фукцию, в которой к слову компилятор будет выдавать warnings если не обработан какой-то из union кейсов(привет ООП наследование со всеми возможными неизвестными или exceptions, которые вообще пойди угадай какие прилетят из вызываемого кода).

Так і ООП патерни в фп не зробити.

ООП паттерны в ФП и не нужны, а вот полная поддержка всего, что умеет ООП языки в ФП есть уже давно.
ООП паттерны не нужны для написания логики, они нужны что бы избавляться от всякого негатива в ООП языках типа дубликатов кода, позволять делать reuse и расширяемость обеспечивать в условиях, когда код кроме pure behavior содержит и side effects, что делают работу программ непредсказуемой и небезопасной. В Фп для этого вместо десятков паттернов, обходятся простыми техниками типа композиции, параметризации и простыми идеями типа иммутабельности, тотальности, детерминизма.

Те що я далеко не ідеально написав реалізацію своєї ідеї, до ООП відношення не має.

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

А як, скажімо, ефективно файл прочитати, не програмуя контроллер напряму, ви уявляєете ?

А що у вас ноди забули у двомірному массиві?

Опишіть структури данних як вони є, і питання зразу відпадуть. Для F#, можна так:

type Tree<'a> =
    | Empty
    | Node of 'a * neighbors: Tree<'a> seq

let neighbors a =
    match a with
    | Empty -> Seq.empty
    | Node (a, b) -> b

Akka Streams, лопатил лично ими гигабайты текстовых данных.

Дак итераторы же — изи. Заворачиваешь массив свой в стрим и делаешь что хочешь, туда же можно индексы подбросить если очень надо.

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

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

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

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

А вы из своего невежества — не знали про интервальное исчисление. Математика исследует устойчивость/неустойчивость тех или иных алгоритмов, не прогерство, и алгоритмы с минимальным накоплением ошибки/ исследование того сколько там будет правильных знаков в мантиссе и что для этого нужно — тоже исследует математика, а конкретнее численные методы. Здесь математика первична, а кодирование — вторично и есть строгой реализацией того что написано в численных методах. Численно диффуры в частных производных решал, знаю что там к чему.

хорошо описаны математикой
не прогерство
Здесь математика первична

xkcd.com/435

кодирование

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

Да, существует, но немного видоизменённая(этому человеку теперь ещё нужно и правильно подбирать эти блоксхемы и хорошо знать их свойства, уметь их комбинировать и т.д.) — человек который въедет во всю ту дичь которую учённые понавыдумывали и закодит. Хорошо оплачиваемая, кстати, позиция, на западе часто при разных универах держат специально обученых гребцов для инжиниринга (обычно с магистратурой по CS и PHD по смежной области (опционально)), чтобы быстренько делать профит из науки.

Так или иначе, решение задач в этих областях разбивается на 2 части — построение той самой блок схемы и пруф(что часто требует гораздо больше времени и усилий чем непосредственно реализация), что ваша блок-схема не верблюд, и непосредственно реализация.

Мне по работе довелось лазить в С++ код, и кто то вот так(почти так) побольшому ходил в другой сервис. Как раз лазил в дуэт из C++ и Go кода, и не сказать что там всё прям таки просто, прозрачно и радужно.

Но вот тому, кто читать будет уже будет сложно понять, что код делает.

Читающего в школу; через месяц он это будет понимать быстрее чем стандартную лапшу из вложенных циклов.

Ну тогда уж можно сказать, что и goto никуда не ушли, их просто спрятали в циклы.

Точнее именно goto редко нужны.

break и contiunue, в том или ином виде существующие практически во всех языках, — это замаскированные goto.

через рекурсію. В чистому ФП не використовують цикли

С рекурсиями тоже не всё гладко.

6) рекурсия считается злом, которое может усложнить программу, поэтому рекурсивные фунции надо помечать словом rec.
С рекурсиями тоже не всё гладко.
6) рекурсия считается злом, которое может усложнить программу

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

1. Сложно писать и отлаживать.

Чисто дело привычки. Надрючившись можно писать быстро и эфиктовно, а вместо отлаживания — юнит тесты.

2. В разных языках могут быть проблемы со стеком, если стека нет, то и проблемы нет

Хвостовая рекурсия. Все фп языки — умеют. Слышал, даже в этот ваш цепепе обещали.

3. Сложности для конвейеров CPU. С циклами им проще.

Программировать конвееры ЦПУ на фп языке, это как забивать гвоздь микроспом — задача не соотвецтвует инструменту.

А, точно. Просто плюем на реальный мир, на каких устройствах исполняется код.

перечитайте мой пост еще раз, на всякий.

Третий пункт смысла не имеет. Конвейер не программируется. Код либо хорошо на него ложится либо нет.
Так понятнее?

А, вы про эти конвееры. признаю, тут меня бес попутал.

Тогда ответ был гдето высше, хвостовая рекурсия преобразовуеться компилятором в тотоже цикл — никаих проблем там нет.

абсофакин лютли.

Точно также как под капотом любого цыкла исполняеться готу.

да, без готу никак.

непонятно ток чего программеры так его не любят.

Нелюбовь к goto происходит из тех лохматых времён, когда им бездумно пользовались для перескакивания между частями кода. По-моему, уже во времена структурного программирования необходимость в использовании goto возникала крайне редко, и то, в основном, в языках первых поколений, куда не завезли более кошерные control flow операторы наподобие тех же break и continue.

А, ну и программы на древних диалектах Бейсика были рассадником goto просто потому, что по тем временам в Бейсик не завезли ни while, ни switch / case, ни нормальных процедур / функций

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

Аналогичная нелюбовь наблюдаеться сейчас от ФПшников к циклам, когда в них все бездумно мутируеться.

По-моему, уже во времена структурного программирования необходимость в использовании goto возникала крайне редко, и то, в основном, в языках первых поколений, куда не завезли более кошерные control flow операторы наподобие тех же break и continue.

Агалагично — необходимость чето там мутировать внутри цикла нынче на самом деле возникает крайне редко (с поправкой на задачу), а необходимость использовать циклы возникает в языках предедущих поколений, куда не завезли функции первого порядка, хвоствую рекурсию, и паттерн матчинг.

А, ну и программы на древних диалектах Бейсика

Программы на древних диалектах С — рассадники фор лупов :-D

Аналогичная нелюбовь наблюдаеться сейчас от ФПшников к циклам, когда в них все бездумно мутируеться.

а всякого рода filter, map, each и т.п. считаются поводом для нелюбви? :)

Уж их-то, в том или ином виде, завезли в большинство современных императивных языков, поэтому даже там необходимость использовать явные for loops возникает очень нечасто.

Поэтому, да, согласен — писать императивные конструкции «в лоб» там, где можно обойтись более выразительными и декларативными средствами языка, в 2019 году так же некомильфо, как и использовать goto без крайней необходимости.

Программы на древних диалектах С — рассадники фор лупов :-D

Вполне вероятно :) Я на чистом C в последний раз писал наверное году в 1992-1993м (да-да, ещё школотой я осилил C сразу после Бейсика, после чего Паскаль в лицее уже казался «семечками»).

В принципе, никто не мешал даже в C реализовать подобие each, map и filter: указатели на функции, по-моему, были канонизированы ещё в книге K&R. Но этого не делали не столько из любви к императивщине, сколько потому, что в те времена каждый такт процессора был на счету, и зачастую косвенные вызовы оказывались непозволительной роскошью.

Там где используется С такты и сейчас часто на счету.

хвостовая норм.

Помечать надо для компилятора

Да, тоже про бейсик вспомнил вначале. :)

Если он ещё и будет в js компилироватся и там работать то это будет «не списывай полностью». У нас уже есть такой и не один, который компилируется в JVM.

первое впечатление какой то недо Ocaml, может выстрелить у хипстеров.

Чем хипстерам окалм непонравился ?

Не может, потому что у хипстеров есть ReasonML

Код на лиспе же — тотальное насилование мозга скобочками.

не нужно делать перенос строки перед закрывающей скобочкой

(абзац (, (ну (понял я тебя) ) (на самом деле (удобно (и (так (писать)) (так (думать))))))) (был (у меня) (с (диплом) (с (тулзой) (таким (синтаксисом))))))

Интересно было бы посмотреть как написанная мысль выглядела на плюсах или джаве)

(абзац (, (ну (понял я тебя) )
	  (на самом деле
	      (удобно (и
		       (так (писать))
		       (так (думать)))))))
(был (у меня)
     (с (диплом)
	(с (тулзой)
	   (таким (синтаксисом))))))

разметка немного все таки поехала

Код на bosque взрывает mosque.

Масука вызывает Лагуэрту

Уверен что мелкомягкие скорее съедят галстук Саакашвили, чем что-либо выложат в опенсорс без куска говна в лицензии, означающего что вы его нарушили едва начав использовать в другом опенсорсе. Таких патентных тролей как Мелкософт ещё поискать. Даже если куска дерьма нет сейчас — оно появится позже, других вариантов просто нет.

Ну... у тайпскрипта вроде норм лицензия (как по мне)... Как будет с Bosque — хз.

Ради интереса посмотрел первые 2 страницы их репозиториев...
.NET, PowerShell, WinForms, WPF, ML.NET, Mono — MIT;
Roslyn, TS — Apache 2.0;

Одни миты и апачи. Все четко.

Просто похоже Пение застрял в 2000-х

Друже, вылазь из бункера :) Так было при Баллмере, с приходом Наделлы всё очень сильно поменялось в лучшую сторону. Сейчас MS открывают очень много кода под MIT и Apache лицензиями.

Підписатись на коментарі