Вред мощных выразительных ЯП

> Так объясняешь. Аналогия очевидна и дятлу

А... понял, сорри. Пробывал. Не помогло.

Я правда на кал изошёл. И так и эдак. Ну мне кажется, это просто люди такие... непробиваемые.

> пока один тимлид не впал в бешенство и не стал нести ересь вроде «незачем использовать LINQ ради экономии нескольких строк, ведь всё можно циклами сделать!!!111»

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

> Там не «несколько строк», а гораздо больше выходит порою. Дремучий у тебя тимлид. Мои сочувствия.

Ну так я то понимаю, что там не несколько строк. Но как до товарища донести эту мысль? Я писал примеры кода, где на LINQ несколько очевидных строк, я на C#2.0 - овер дофига совсем не очевидных вещей. На что он сказал, мол, «ну да - всего несколько строк»...

> Остальное и так пишу на Scala

Это ты через неделю изучения Scala говоришь? Гигант, чё

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

о найтмарез с gamedev :) Ну трамвай то да но за c# поддержка MS. Курсы, книжки, лекции итд. А коллеги должны осиливать новое иначе они скоро станут профнепргодны. В этом суть программирования. Попробовали бы они не изучить XML.

а ты им про ленивость говори. вон мол и серверов меньше покупать придется :)

> и серверов меньше покупать придется

Так недолго вместо ФП внезапно C++ получить.

наоборт хаскель. там же все лениво до ужаса

Ленивость вообще в теории хороша, так как нужно очень правильно применять, иначе никакого профита. Не говоря уже о overhead

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

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

Это с ленивостью не связано. Просто оптимизиация компилятора. А ленивость - в рантайме

тогда надо уточнять о какой именно ленивости мы говорим. О ленивости вычислений вырежения (что имел ввиду я) или ленивости обработки массивов когда map лишь запоминает адрес функции и а не обрабатывает массив в реальности. Зато обрабатывает отдельные элементы по мере доступа к ним. Тогда профит от Range(0, 100)._map(_sin)._subRange(0, 10) будет в силу того что реально _sin посчитается только для 10 элементов а не для 100

Однако, он - тимлид, а ты никто без палочки. Подумай об этом. Чаще будешь думать, быстрее и сам до тимлида дорастешь.

(= (писат (куча скобок) (не (нужно)))

Почему после применения ФП так и хочется вместо цикла применить хвостовую рекурсию.

Рекурсиоз Головного мозга. На неФП код с ней намного менее читабельный, чем с итерацией, а сборка с -O0 заставит программу еще и съедать стэк.

во-первых, то, что ты написал - катаморфизм, а не свертка.

А разница? Посмотри на катаморфизм для списков. Сравни с обычным fold-ом.

Во-вторых - nat по дефолту не определено как АТД

nat по дефолту вообще не определено. Но определение, которое можно привязать к builtin-ам Агды - такое:

data nat : Set where
  zero : nat
  succ : nat -> nat