.NET Fest: полная программа конференции на сайте. Присоединяйся к самому большому .NET ивенту
×Закрыть

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

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

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

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

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

LinkedIn

Лучшие комментарии пропустить

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

Допустимые теги: 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), декларативности, функциональным паттернам.

Ну таке, мені не вистачить кваліфікації вести срач. А відео скушне, забагато блабла, краще б стаття була. Поки з досвіду це локальні функції над lists, і так, це економить час і кількість коду стає набагато меншою ніж якби листи обробляв імперативно з циклами і всіма тими речами. Хороша штука. Але щоб чисто на фп пилити, хз, подивлю куди індустрія піде.

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

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

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

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

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

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

Таких кейсів можна на будь що назбирати. Як хтось кудись перейшов і щось вирішив. Колись я читав аргументацію як прихильник static typing перейшов на dynamic і це типу показник що статику кінець, прогрес за динамік. А сьогодні динамік навпаки сам відмерає і в нових мовах статік приходить. Не роби собі кумира, що зветься.

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

This month C++ is back at position 3, swapping places with Python. This is certainly not because Python is in decline: Python is scoring all time highs almost every month. It is just that C++ is also getting more and more popular. C++ is still far away from its popularity in the beginning of this century when it had a market share of more than 15%. The complexity and the delay of releasing the new language definition C++0x pulled the language back at that time. That new language standard, eventually named C++11 after its release in 2011, has made the language much simpler, safer and more expressive at the same time. It took some extra years before the C++11 standard was adopted because the community had to wait for proper compiler support. But now that the C++11, C++14 and C++17 standards are supported by the most important C++ compilers, i.e. Gcc, Clang and Visual Studio, the popularity of C++ is reviving.

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

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

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

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

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

В масовому програмуванні недавно. В експериментальному напевно в 80тих, не знаю.

Серйозно. І за 60 років існування, ще жодна фп мова так і не попала в топ 10 мов(тіобе індекс до прикладу). Шо ж це таке? Хто не дає встати з колін функціональщині?

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

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-а

Той індекс якийсь через задницю. Особливо повеселило вверху — WebAssembly. Скільки тих вакансій — кіт наплакав. Давайте покажіть мені з доу вакансії де фпшникам платять сильно більше ніж джавистам.

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

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

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

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

Не подобається тіобе беріть pypl.

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

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

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

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

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

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

Чим він кращий і як працює? Бажано приземлений приклад

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

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

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

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

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

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

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

Тобто через те що є якісь трейні рівня деви ви називаєте парадигму поганою? Ясно.

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

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

І? Треба тепер все кинути і податися в секту свідків ФП?

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

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

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

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

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

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

И вот приходим к тому, что уже заюзать готовые, сделанные кем-то кирпичики и вызываемые из твоего языка, то ФП хорош.
А если такого нет, то ООП и языки нижнего уровня типа С и С++ юзай.

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

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

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

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

Так, але я хотів побачити порівняння з ООП варіантом. Подивився слайди. Прикольно, мені сподобалося. Щось схоже я зробив у себе на колінці: ibb.co/3ztK9wC

Зробив, коли мені треба було щоб метод який отримує дані на обробку і викликає інший метод, при заваленні іншого не валився сам, але давав в відповіді знати що тут коротше сиксес, але є деякі трабли. Або що ніфіга не сиксес бо в другому були трабли. В залежності від критичності фейла другого методу ерор пишеться або в failureMessages або в warningMessages. Вся суть в ретурні не одного булеан до прикладу, а й щось ще в придачу(ерор меседжів). І вже на цьому можна отаке реілвей реалізувати. Але воно не всюди треба мені в ООП, тому там де крашинг ламає всю обробку просто даю закрашитися і в результаті є 2 варіанта — або зичайний ретурн сиксес з методу, або ексепшин, який уже перехоплюється в Мідлеваре, і той повертає 500 помилку юзеру. Або якщо його щось раніше перехватить і поверне свою помилку чи зробить дію.

п.с. successMessages це коли булеан тру, і треба щось дати знати, як то підтвердити емейл. Опціональне.

і той повертає 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 и юнион типов.

ни локализации

Текст вже локалізованим вставляється використовуючи обєкт локалізатора і ключ до ресурсу.

type sefty тоже никакой (никакой информации об ошибке за пределами той функциии где этот обьект создан)

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

null как дефолтные значения для public полей — привет вызывающему коду и девелоперам, что потом будут выгребать в самых неожиданных местах nullreference exceptions, потому что компилятор тут вам не поможет.

Так, тут я протупив. Дякую. Дефолтом треба пусті листи ставити. Даний пункт критики до ООП не відноситься, лише до мене.

А решение для псевдо immutability говорит сам за себя(завернутые в аннонимные типы свойства, где все равно осталась семантика сравнения по ссылкам(List< string >), а не значениям)

Ага, знову моя помилка. Треба буде переробити,правда я ще не зрозумів як найкраще. Чому імутабіліті псевдо? Бо private set? Додам readonly і проблема пропаде.

бажные костыли — вот вам и вся сила ООП

Те що я далеко не ідеально написав реалізацію своєї ідеї, до ООП відношення не має. Так, у фп є готове, але й в ООП є багато готового. Я звісно про фреймворки. Що тільки не хочеш — все знайдеться.

По іншому поки не можу нічого сказати. Добре, вірю що фп патерн в ООП не зробити. Так і ООП патерни в фп не зробити.

П.с.

дальше с этим обьектом ничего не сделаешь кроме как закинуть в ответ куда-то этот текст

Для цього я його і створював. Мені треба було в контролер дати деяку інформацію додаткову. Це не щось дженерик для всіх випадків. Реалізація під конкретне завдання.

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

В примере, что я скинул выше на ФП, делается 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, лопатил лично ими гигабайты текстовых данных.

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

И получить дикие тормоза. Не итераторы хороши в определенных местах, но не везде (ну и они сильно ограничены).
Я вот тоже люблю юзать стандартные алгоритмы и итераторы, но только там, где им место.
А вот где им не место, там циклы просто необходимы. Но да их можно и через goto делать.

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

И для питона приплюснутые написали numpy на плюсах для числодробления.

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

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

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

Он просто не в курсе всего этого.

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

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

xkcd.com/435

кодирование

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

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

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

Весело, но бредово, особенно простыня на плюсах впечатляет — явно после поллитры писал кто-то.
Ну и нахера тебе здесь С++, если Go хватит — он под подобные задачи заточен, причем и работает быстро в таких задачах.

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

Это уже другой вопрос. С++ не для криворуких. Это большой его минус. А у тебя в примере код одного из таких криворуких писателей.
Джуны в С и С++ и не такое творят. Я всякого насмотрелся.

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

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

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

Не ушли. Точнее именно goto редко нужны. Но в смысле перехода по адресу не ушли. Вот здесь можешь поиграться gcc.godbolt.org.

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

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

А напиши-ка мне умножение матриц на Питоне без использования сторонних либ, написанных на С и С++ (того же numpy).

З.Ы. Но может ты думаешь, что в Питон нумпи боги принесли, а не приплюснутые написали ее.

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

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

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

У каждой методики свой домен задач, например рекурсивная реализация квиксорт проста и понятна, но переписать его итеративно довольно непросто.

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

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

С рекурсией несколько проблем:
1. Сложно писать и отлаживать.
2. В разных языках могут быть проблемы со стеком, если стека нет, то и проблемы нет
3. Сложности для конвейеров CPU. С циклами им проще.

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

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

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

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

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

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

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

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

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

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

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

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

Тобто по суті під капотом виконується той же цикл? Якщо добре памятаю про хвостові.

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

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

То без циклів таки нікуди. Що і треба було доказати ©.

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

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

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

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

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

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

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

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

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

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

Вже знайшли функціональну мову в топ 10? Чи у вас пабеда як у телевізорі в пуйла? Взяли фанерний берлін?

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

а всякого рода 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 лицензиями.

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