Точно если бы рассмотрели ФП (Хаскель) и к примеру хотя бы Эрланг, то и сабж позможно бы и не родился

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

Так я это к тому, что, в общем, только *сравнительно* не сложные ЯП могут иметь шанс стать этаким стандартом «де факто» (это конечно не считая «исторических» ЯП вроде С/С++) Остальные умрут. Ничего личного - просто статистика.

Я уже жду неджождусь когда отомрут всякие бентли и феррари и остануться лады калины и ланосы.

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

Или ты действительно не видишь проблемы в своей логике?

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

Но как же крупные фирмы и проекты111!!!! -скажут товарищи функциональщики. А здесь можно заметить что доля функциональщины там весьма мала. Почему? Во-первых и крупным компаниям, и Open Source сообществу нужны инструменты быстрого входа, но имеющие серьезные возможности для расширения. В то же время фирмам и омпаниям нужна большая инфраструктура вокруг языка, а если такой нет: да это может быть будет интересно на поиграться нашему R&D отделу.

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

Это узкое мышление, диктат императивщины в образовании!-могут нам ответить функциональные теоретики и практики. Однако здесь можно заметить что императивный язык программирования просто отображает принцип инструкций и четких последовательностей действий, который хорошо известен людям даже неквалифицированным в CS. И вот они видят весьма знакомый принципы мышления,а потому при желании они вполне осваиваются. А на этом фоне появляются функциональщики, которые не имеют столь наглядных аналогий IRL, за то напротив для многих своих концепций предполагают хорошую математ. базу,при чем ВУЗ+, которая к прикладной математике имеет слабое отношение. Прямой применимости вне языка она иметь не будет для инженера, биолога,etc, прикладника в этих сферах. И вот вопрос зачем им функциональщина? А это вопрос важный, так как именно эти кадры львиная доля рыка труда ИТ.

В-третьих как уже я отмечал выше сам компьютер в явном сговоре с императивными злодеями, а не с функциональщиками. Предлагают сменить всю аппаратную платформу(!) довольно радикальные головы, а уж тогда ... Но простите задачи то уже тут и решаются сейчас, наработана целая культура мысли вокруг подхода Фон Неймана. И все это выбросить на помойку? Уже вижу как в едином порыве это делают Intel,MS,Google,Apple,ARM,facebook,AMD и т.д. Вся это разношерстная жестко связана с Фон. Мы то от x86 все никак не отойдем. Допустим что не нужно так все круто менять, но тогда чем ФП, которое сидить на рекурсиях и других довольно затратных операциях лучше императивщины на текущей архитектуре? Пока такого вобще не видно. Далее вспомним что заложили основы программирования как практики математики,физики и родственные. Логики подтянулись потом. То есть и культуру использования инструмента создали не функциональщики, а теперь они кричат, а мы вот!!

В-четвертых сейчас больший акцент решаемых проблем в области проектирования и унификации, а на этом уровне ФП оперирует все теми же модулями и классами

Можно было бы сказать: ФП в топку ! Нет! То что ФП маргинально это не только минус, но и +, так как дает куда большую гибкость проб и ошибок, но многие функциональщики этого просто не ценят. Те же кто понимают работают над совершенствованием теории и практики, отшибают нехилые гранты. ФП это пионер в неизведанное, который может часто заходить в тупик, ошибаться, а может наоборот выстреливать. Так пусть таким и будет. Точки роста всегда должны быть

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

Мой поинт был в том что с чего он взял что то - чем не пользуется большинство - должно умереть? Машинками типа мазерати тоже большинство не пользуется - цена отталкивает. И что - они умерли что-ле? С чего вы взяли что язык должен быть таким чтобы им могло пользоваться среднестатистическое большинство?

Во-вторых люди привыкли мыслить императивно в программировании

Мои им соболезнования. Опять будем жарить яичницу на хаскеле?:)

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

Люди не программировавшие до универа первый раз увидев X := X + 1 из ступора выходят неделями. А если это еще и не «прирожденныё программисты» - так им еще и до года требуется чтобы смириться ужасом вида x = x->next.

А на этом фоне появляются функциональщики, которые не имеют столь наглядных аналогий IRL,

Вообщето IRL все декларативно. Работа с «динамическими списками» для неокрепшего мозга - психическая травма.

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

Опять будем жарить яичницу на хаскеле?

И вот вопрос зачем им функциональщина? А это вопрос важный, так как именно эти кадры львиная доля рыка труда ИТ.

Я понимаю что ты оправдываешь что возюканье мышей в делфи - пойдет для «львиных кадров», я даже возможно гдето с єтим согласен. Я не понимаю как вы с анонимусом не видите что для того чтобы львные кадры вазюкали мышей в делфи - это делфи должны написать совсем не львиные кадры, которые знают принципы разработки компиляторов, принципы статического анализа полиморфных типов, и т.д. Или компилятор в делфи ты тоже в делфи мышей навозюкать предлагаешь?:)

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

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

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

Опять будем жарить яичницу на хаскеле?:)

Далее вспомним что заложили основы программирования как практики математики,физики и родственные.

И от конструкции вида X:=X+1 они до сих пор в охренении.

а на этом уровне ФП оперирует все теми же модулями и классами

А ФП никак не противоречит модулям и классам.

Мой поинт был в том что с чего он взял что то - чем не пользуется большинство - должно умереть? Машинками типа мазерати тоже большинство не пользуется - цена отталкивает. И что - они умерли что-ле? С чего вы взяли что язык должен быть таким чтобы им могло пользоваться среднестатистическое большинство?

Ну анонимус конечно слишком сильно утверждвает когда говорит о смерти ФП, что кстати в последней части своего поста я и отметил. Однако сравнение некорректное с мозерати и etc. Это во многом предмет роскоши, язык программирования банальный инструмент. Поэтому получается примерно следующее: логарифмическая линейка-дорога в светлое будущее, калькуляторы нас не сомнут! Логарифмическая линейка сейчас полезна в двух случаях: ничего другого нет, гимнастика ума. Та же картина с ФП-интересная штука откуда можно утянуть что-нибудь и для императивщиков.

Мои им соболезнования. Опять будем жарить яичницу на хаскеле?:)

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

Вообщето IRL все декларативно. Работа с «динамическими списками» для неокрепшего мозга - психическая травма.

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

Люди не программировавшие до универа первый раз увидев X := X + 1 из ступора выходят неделями. А если это еще и не «прирожденныё программисты» - так им еще и до года требуется чтобы смириться ужасом вида x = x->next.

Когда нормально излагается, закрепляется примерами никакого ужаса от := не видел, когда излагают коряво, то да сплошь и рядом. относительно списковых структур да посложнее, но вполне осваивают, если видят в них необходимость

Опять будем жарить яичницу на хаскеле?

Да что же за отношения с яичницей у вас или у хаскелля такие жесткие воздействия на тепловыделения процессора и К. Так зачем прикладникам все эти теории выведения типов. морфизмов и Co ?

Опять будем жарить яичницу на хаскеле?

Я понимаю что ты оправдываешь что возюканье мышей в делфи - пойдет для «львиных кадров», я даже возможно гдето с єтим согласен. Я не понимаю как вы с анонимусом не видите что для того чтобы львные кадры вазюкали мышей в делфи - это делфи должны написать совсем не львиные кадры, которые знают принципы разработки компиляторов, принципы статического анализа полиморфных типов, и т.д. Или компилятор в делфи ты тоже в делфи мышей навозюкать предлагаешь?:)

Так и запишем что Дейкстра, Вирт, Кормен и К, Кнут, которые предложили кучу классических алгоритмов-жалкие мышевозы дельфийцы. Хотя относительно последних уже приходится признать что ФП им сто лет в обед? Кстати а в чем же так сильна связь ФП с компиляторами, если мы не имеем ФП-специфичных систем вывода типов? Вот с теорией алгоритмов,лексического анализа, оптимизации вижу, а вот с ФП нет, особенно учитывая эквивалентность императивных программ и функциональных. Что показал Черч

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

Ну так одно надстраивается над другим, еще не забудем про стек при работе с ассемблером. А так алгебра же опирается на арифметику и ничего.

Опять будем жарить яичницу на хаскеле?:)

Что ж странные связи,к чему такое постоянство?

И от конструкции вида X:=X+1 они до сих пор в охренении.

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

А ФП никак не противоречит модулям и классам.

Правильно, я это и не отрицаю, ничего не предлагая нового.

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

Так зачем прикладникам все эти теории выведения типов. морфизмов и Co ?

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

Без статической типизации ФП - не ФП? Если я не знаю ничего о выводе типов, не имею понятия, зачем нужны монады, а слово «стрелка» для меня - это всего лишь «→», то мне так и суждено вечно писать циклы?

А что в циклах негативного кроме того что это сайд-эффекты и не рекурсия, которая все равно разворачивается компилятором? Пока ничего плохого в них невидно кроме того что неилитарно. А собственно этим хелоувордом хорошо было показано, что это повод попонтоваться или что для вас вернее, взглянуть за мейнстрим и это правильно, но как только мы посмотрим на это с утилитарной точки зрения, то циклы оказываются удобней на многих задачах, но не на всех. Опять же программирование не как исследовательский полигон просто берет то что ему удобней. Так что вопрос в силе.

А что в циклах негативного кроме того что это сайд-эффекты и не рекурсия, которая все равно разворачивается компилятором?

Очевидно, тем, что это менее декларативное и реюзабельное решение, нежели православные map и reduce. Иначе и циклы не нужны, коли есть goto - все равно　же все разворачивается в...

Пока ничего плохого в них невидно кроме того что неилитарно.

Какая элитарность, о чем речь? Элитарно - это какие-нибудь Хейльсберг, Одерски и два человека, которые когда-нибудь наконец-то напишут мегабыстрый мегараспараллеливающий мегакомпилятор хаскелла. А для того, чтобы иметь профит с ФП достаточно быть простым быдлокодером со здравым смыслом . Придумывается-то это все ради облегчения жизни, а не для усложнения - сами концепции в конечном счете простые.

Так что вопрос в силе.

Точно. Какое отношение вывод типов, морфизмы и Co имеют к ФП? Как выходит, что постоянно появляется какая-то новая тру-ФП космическая технология, которую простые люди никогда не поймут, и без которой ФП - не ФП?

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

Дело не в банальности/элитарности а в параметре «недоступность». Причины недоступности несущественны. Вывод о том что если что-то недоступно большинству - оно должно умереть - ошибочен.

Не вижу поводов, математика то же активно опирается на имп. подход,

Ни в коем случае,

численные методы как хороший пример

И чем же он хорош? Ты не путаешь слова «итеративный» и «императивный»?

А яичницу обычно на сковородке жарят,хотя да можно конечно извращаться.

Вышел 2-й выпуск журнала «Практика функционального программирования» (комментарий)

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

Тема раскрыта по линку:)

Когда нормально излагается, закрепляется примерами никакого ужаса от := не видел,

То есть десять лет тебя в школе учили что y=x^2, а тут ты пришел и увидел x=x^2 - и тебя не вштырило такое уравнение?:)

Так зачем прикладникам все эти теории выведения типов. морфизмов и Co ?

Тем прикладникам которые хотят понимать что происходит когда в C# пишешь:

var x = 1;
int y = 2 + x;

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

Так и запишем что Дейкстра, Вирт, Кормен и К, Кнут, которые предложили кучу классических алгоритмов-жалкие мышевозы дельфийцы.

Все вышеперечисленные свои основные работы написали когда для объяснения что такое X := X+1 было существенным понимание что есть такая область памяти где лежит значение X и обновляется оно где-то в памяти там. А рекурсия это такое зло потому что стек и его нужно избегать. Ты считаешь что для современных рубипитоножабоСишарпов это актуальное объяснение?

Кстати а в чем же так сильна связь ФП с компиляторами, если мы не имеем ФП-специфичных систем вывода типов?

Тем что человек обладающий достаточными знаниями чтобы создать компилятор статического языка с полиморфными типами не имеет никаких проблем чтобы осилить хаскель. Кто занимается полиморфными типами C#? Дон Сайм - автор F#. Кто создал первый комплятор генериков жабы? Мартин Одерский, автор Скалы. Почему-то в МС Ресерч занимаются развитием «прикладного» C# люди типа Луки Карделли.

Ну так одно надстраивается над другим

Ага да?

Студенты, которые попали на ИТ по ошибке да охреневают,

Поинт в твоей заметке об «естественности» императивности в RL.

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

А ниче что я на этом испытательном полигоне высоконагруженные сервисы пишу и всякий прочий охренительно здоровый софт?

Так зачем прикладникам все эти теории выведения типов.

Вот к стати только что попал на типичный пример. Заходим в википедию синтаксис сишарпа linq, и видим там:

What differs from SQL is that the from-statement comes first and not last as in SQL. This is because it seems more natural writing like this in C# and supports Intellisense.

Лицоладонь полный.

В толке по этому поводу выдвинута другая теория - «так больше понятно сяшным программистам».

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

К стати хороший пример - разовьем его дальше - переходим в статью по LINQ - и что мы там видим в первых же строках?

Architecture of LINQ in the .NET Framework:
Standard Query Operators
Select
Further information: Map (higher-order function)

.....функции высших порядков, гомоморфизм в первых строках.

Where
Further information: Filter (higher-order function)

SelectMany
Further information: Bind (higher-order function)

...ссылка ведет на....монады!

Aggregate
Further information: Fold (higher-order function)

...свертки рекурсивных структур, комбинирование функций, катаморфизмы и анаморфизмы прямо с первых строк.

Весь текст просто пестрит лямбдами, предикатами, implicitly typed variables, type inference.

Ты продолжаешь утверждать что все это никому не нужная теоретическая фигня - полигон для развлекухи? Я реально ен понимаю программистов на C# которые пользуются своим инструментом не понимая в принципе как оно работает и что собственно они делают.

Весь текст просто пестрит лямбдами, предикатами, implicitly typed variables, type inference.

Всё это добро одинаково применимо как для ФП, так и для ИП.

Всё это добро одинаково применимо как для ФП, так и для ИП.

Клиент упомянул мол «нафиг эти все сложности прикладникам».

Как «строго типизированный» сочетается с Parrot? Да и кривой он чрезмерно, не взлетит никогда.

Отвечу цитатой

"...what's wrong with the for loop: it conflates (at least) three separate kinds of operations, and focuses on a minor detail: walking over a series of (index) values."

http://notes-on-haskell.blogspot.com/2007/02/whats-wrong-with-for-loop.html

Отвечу цитатой

"...what's wrong with the for loop: it conflates (at least) three separate kinds of operations, and focuses on a minor detail: walking over a series of (index) values."

http://notes-on-haskell.blogspot.com/2007/02/whats-wrong-with-for-loop.html

Пока неясно что же эта цитата доказывает кроме того что pure функциональщина стремится всему придать свой особый смысл. Цикл while требует проведение всех трех этапов цикла совершенно отдельно, цикл for хотя их и объединяет, но опять же это надо быть весьма невнимательным, чтобы не заметить разницу трех блоков for, если брать же форму for in, то она просто решает широко распостраненную задачу обхода последовательности . А чтобы было меньше сюрпризов том же python, например, переменная обхода не меняет саму последовательность. И где же путаница и маскировки? Далее сама последовательность этапов for, если изучать внимательно то же все расставляет по полочкам и показывает правильную последовательность действий.

Моё время дороже, чем машинное.

Дело не в банальности/элитарности а в параметре «недоступность». Причины недоступности несущественны. Вывод о том что если что-то недоступно большинству - оно должно умереть - ошибочен.

А кто говорит что умереть или быть исследовательским инструментом это сразу смерть? Более того я еще ранее оговорил что не согласен с тем аноном что это будет смерть языку\инструменту. Пример суперкомпьютеров подсказывает, что не смотря на малую распространенность относительно всех типов ЭВМ умирать они не собираются, наоборот все больше укрепляются в нише, создают вокруг себя мощную экосистему. В частности за счет того что не орут: мы лучше, расово правильней,корректней ПК 1!!11!! Другое дело что в основном и ФП ведет себя примерно подобным образом, иногда балуясь выступлениями в Спецолимпиаде, но этим все балуются, императивщина не лучше в этом смысле.

И чем же он хорош? Ты не путаешь слова «итеративный» и «императивный»?

И где же путаница, рассматривая любой алгоритм численных методов в конечном итоге (для ЭВМ, вычислителя в более старые времена) видим набор условий и шагов ЧТО СДЕЛАТЬ, а НЕ МНЕ НУЖНО ЭТО . Сам же процесс вывода и доказательство корректности вобще неалгоритмичен. Ну конечно элементы алгоритмичности там есть, но пока идет установление что с чем связано, как сформулировать задачу мы вобще вне алгоритмической сферы по большей части.

Вышел 2-й выпуск журнала «Практика функционального программирования» (комментарий)

Пример сферического коня в вакууме. Далее если даже посмотреть на него, то это всего лишь описание абстракций ДЕЙСТВИЙ, а не того что я там хочу. И тут просто весьма неэлементарные действия приняты как абстракции базового уровня, с таким подходом можно и операции на человеке лихо делать, только вот загвоздка почему-то так не делают. Более того там далее по треду заметили это если подрихтовать человеческим языком нам все изложено, а мозг обладает довольно нехилыми возможностями ворочать контекстами инструкций и контекстами контекстов,у ЭВМ нет таких возможностей. Действительно хорошо декларативная парадигма ложится на выборку данных от SQL до QBE,RegExp. Но если посмотреть под них, то там жуткая императивщина и проектировались они так чтобы учитывать потребности императивного подхода. Алгоритмы строкового анализа, парсеры вполне себе росли в колыбели злостных императившиков. (опять все те же Вирт, Кнут и К) . Потом пришли на это дело функционалщики и построили свои методы на базе этих. Пришли декларативщики и построили свои на базе этих. Декларативное программирование хорошая штука, которая фактически описывает опять же императтивным алгоритмам, а какие данные ворочать и зачем. Только это ничуть не легче чем описать действия и ничуть непривычнее человеку. Правильно отобрать данные, а даже точнее правильно настроить условия фильтра отбора и поиска человеку куда тяжелее сейчас, особенно если требуют четких правил отбора. И если область слабоформализована или противоречива, то денкларативное это как маяк, который помогает проложиить путь поиска. То есть опять выходит исследовательский инструмент с широчайшими возможностями и узко-прикладной инструмент, который призван решать очень узкие задачи, но действительно весьма часто ключевые в неформализованных областях.

Тема раскрыта по линку:)

Сферического коня увидел, раскрытия нет.

Все вышеперечисленные свои основные работы написали когда для объяснения что такое X := X+1 было существенным понимание что есть такая область памяти где лежит значение X и обновляется оно где-то в памяти там. А рекурсия это такое зло потому что стек и его нужно избегать. Ты считаешь что для современных рубипитоножабоСишарпов это актуальное объяснение?

А почему же нет? Вполне актуально или переменные по небу летают? Далее а чем же оно не подходит и программисту , та самая аналогия ящика вполне сохраняет актуальность. Оно и сейчас не менее актуально, если оно вполне хорошее+понимание что тип переменной=что можем хранить и с этим делать убирает множество ошибок. Насчет рекурсии ну почему сразу зло? Удобный инструмент, который требует некоторой подготовки для овладения+осмотрительности в использовании+понимания тех самых операций со стеком, чтобы понять что узкие места возможны.

Тем что человек обладающий достаточными знаниями чтобы создать компилятор статического языка с полиморфными типами не имеет никаких проблем чтобы осилить хаскель. Кто занимается полиморфными типами C#? Дон Сайм - автор F#. Кто создал первый комплятор генериков жабы? Мартин Одерский, автор Скалы. Почему-то в МС Ресерч занимаются развитием «прикладного» C# люди типа Луки Карделли.

Ну начнем с того что не во всех языках это поддерживается и считается нужным, хотя активно проникает и не сказать что это плохо. Можно признать что да связь есть. Признаю что связь значима. Однако обратим внимание что MS своей практикой кадровой и показала: исследования в ФП-> развитие императивных языков. Что нисколько не противоречит моему утвердждению о исследовательском характере ФП.

То есть десять лет тебя в школе учили что y=x^2, а тут ты пришел и увидел x=x^2 - и тебя не вштырило такое уравнение?:)

Неа, привык внимательно читать у учебников введение и первую главу. Потом в самой концепции переменной «по старинке» нет ничего сакрального.

Поинт в твоей заметке об «естественности» императивности в RL.

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

Ага да?

Ага. Надстройка вобще свойственна природе.

Тем прикладникам которые хотят понимать что происходит когда в C# пишешь: var x = 1;
int y = 2 + x;

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

А ниче что я на этом испытательном полигоне высоконагруженные сервисы пишу и всякий прочий охренительно здоровый софт?

Здоровый...хм.... а это разве хорошо? Да и кто сказал что в ходе исследований должны быть только программы-сикилявки,сами же активно уроминаете компиляторы. Я не отрицаю что большие программы на каком нибудь Haskell невозможно, вопрос насколько это рационально. А так о же преподнесу вам яичницу. История доносит до нас забавный случай: один пастух был полностью уверен что кроме его стада овец и его луга нет иных сходных вещей в мире. Однажды стадо его потерялось, как же он был изумлен, проходя по окрестностям....

Насчет LINQ, а где сей инструмент есть кроме MS VS насколько он потеснил SQL?

Она показывает, что идентификатор несет в себе 3 _разные_ смысловые нагрузки. Я соглашусь, что программисты уже привыкли к такой смысловой нагрузке, но как вы сами сказали: «надо быть весьма невнимательным, чтобы не заметить разницу трех блоков for,» --- можно быть очень внимательным, но уставшим, и не правильно использовать индексы, а потом отлавливать ошибки в этом блоке кода. Когда одно имя означает только одну сущность, то ошибки в оперировании сущностями искать легче.

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

Анонимус за которого ты подписался:)

И где же путаница, рассматривая любой алгоритм численных методов в конечном итоге (для ЭВМ, вычислителя в более старые времена) видим набор условий и шагов ЧТО СДЕЛАТЬ, а НЕ МНЕ НУЖНО ЭТО .

В любом случае численныё методы - это чрезвычайно маленький раздел математики и весьма нетипичный. Даже квадратное уравнение - декларативно.

Пример сферического коня в вакууме.

Не коня а демонстрация сходности реальности с декларативом.

Далее если даже посмотреть на него, то это всего лишь описание абстракций ДЕЙСТВИЙ, а не того что я там хочу.

Каких действий? Там свертка дерева.

только вот загвоздка почему-то так не делают.

Именно так делают в реальности:) Что-то - для чего-то. А не модифицируют окружающий мир чтобы в последней строке понять для чего это было:)

Но если посмотреть под них, то там жуткая императивщина

ТАм единицы и нули - сигналы на шинах а еще глубже транзисторы. Даже ассемблер - ахренительная абстракция от того «что там внизу». И что же дальше?

Алгоритмы строкового анализа, парсеры вполне себе росли в колыбели злостных императившиков. (опять все те же Вирт, Кнут и К) .

Безразборный malloc в долгоживущих приложениях ведет к фрагментации памяти. Ты предлагаешь это специально учитывать потому что оно так есть в каждой программе вмето того чтобы от этого абстрагироваться? Абстрактный комбайн который копает картошку в конце концов где-то там внутри имеет хитроспрятанную фоннеймановскую лопату - следовательно комбайн не нужен все лопаты в руки и на поле?

Потом пришли на это дело функционалщики и построили свои методы на базе этих.

Ага. Когда Черч жил? Твой мир полон иллюзий.

Правильно отобрать данные, а даже точнее правильно настроить условия фильтра отбора и поиска человеку куда тяжелее сейчас, особенно если требуют четких правил отбора

Я надеюсь когда ты приходишь в магазин ты запускаешь foreach по всем доступным товарам беря в руки каждый и сравниваешь оно-неоно, и только перебрав все товары или сделав break по причине наполнености корзины идешь на кассу. А не приходишь в магазин с уже настроенным оптимальным фильтром:)

Сферического коня увидел, раскрытия нет.

Читай внимательнее.

А почему же нет? Вполне актуально или переменные по небу летают?

Именно там они и летают. Управляемые GC. Лвиный человек который пишет программу на современном высокоуровневом языке в основном даже представления не имеет что происходит когда он пишет X:=X+1. Начнем например с того что это все транслируется в стековую машину в жабонете. А процессоры железные - регистровые. Я жду что ты тут будешь последователен и скажешь что стековые виртуальные машины не нужны - потому что там внизу злобный фоннеймановский регистровый процессор на которые стековые машины не натягиваются. Дальше ты с не меньшим цинизмом вырежешь регистровый далвик и паррот как регистровые машины с любым количеством регистров, в то время как на железном процессоре количество регистров строго ограничено. После этого доберешься до всех прочих виртуальных машин, как абстрагирующих от злого железного процессора все включая вызовы фунций через всякие там VMT - которых процессор не поддерживает, и все это высосанная из пальца абстракция. Будем продолжать?

Оно и сейчас не менее актуально, если оно вполне хорошее+понимание что тип переменной=что можем хранить и с этим делать убирает множество ошибок.

Оно порождает огромное количество ошибок. Типичный императивный код в наш век полного SMP имеет тенденцию быть полностью нерабочим без специальных адаптаций.

Ну начнем с того что не во всех языках это поддерживается и считается нужным,

Не вожно. Я говорю об уровне квалификации. Львиные программисты компилятор арифметических выражений не осилят.

Однако обратим внимание что MS своей практикой кадровой и показала: исследования в ФП-> развитие императивных языков.

Если я начну зоопарк держать с шимпанзе - это будет обозщначать что я «развиваю шимпанзе», или просто что я стригу бабло с «львиного рынка» и мне совершенно наплевать даже если там будет процветать темное средневековье и культ магии, абы деньги шли мне?

Неа, привык внимательно читать у учебников введение и первую главу.

При чем тут введение и первая глава? Если во введении и первой главе будет написано что перед написанием программы надо вознести молитву аллаху - ты тоже будешь утверждать что нет тут ничего необычного - главное делать все по мануалу?

Ага. Надстройка вобще свойственна природе.

То есть когда какую нить хрень типа vmt надстраивают над фоннеймановски зубастым регистровым процессором - ты тут не видишь ничего удивительного, а когда туда надстраивают катаморфи^Hfold - ты говоришь что это противоестественно?:)

В случае простых типов и не слишком новороченного кода это будет работать хорошо

В случае приведенного тупого кода может и будет - а на жабских вайлдкардах почему-то львиные программисты в основном затыкаются. И что самое загадочне - почитать книжку для разклина не хотят - вместо этого ноют «нипанятна - верни нам бейсик».

Вы не находите странным что предлагаете знать потраха компилятора для написания фреймворков

Я предлагаю знать принципы типизации языка программирования на котором ты пишешь.

Здоровый...хм.... а это разве хорошо

Маленький конечно лучше большого - но боюсь грузоподъемность не потянет.

Насчет LINQ, а где сей инструмент есть кроме MS VS насколько он потеснил SQL?

Поинт в том что львиныё программисты которым «не надо» чем дальше тем больше напоминают блондинку в автомобиле. Что для блондинок простительно - но для профессионалов называющих себя программистами - нет.

Далее сама последовательность этапов for, если изучать внимательно то же все расставляет по полочкам и показывает правильную последовательность действий.

Последовательность действий - это метод. Она как цель никому не нужна. Если тебе нужно купить атон - ты идешь и покупаешь его в магазин. А не составляешь план последовательсти шагов левой и правой ногой, if ступенька then шаг вниз.

Начнем с последнего вашего тезиса: метод не цель, конечно! Как и само программирование не является целью, сам язык не является целью это обрамление для решаемой задачи. И поэтому никаких мегаволшебных преимуществ с точки зрения подхода от целей у ФП нет. В мышлении все подходы смешаны, то что не является для задачи центральным, невидно в его развитии и не требует быть увиденным в его развитии воспринимается именно императивно: шаг 1 -> шаг 2 -> .... шаг N. А вот то что в задаче центрально действительно может быть не императивно в виду того что задача еще недостаточно проста, не имеет наработанных алгоритмов решения, эвристических приемов. В конце концов NP-полная задача останется NP-полной вне зависимости от того как мы к этому подходим: императивно или в стиле ФП. А все потому что в конечном счете мы пытаемся по разному назвать одно и то же: набор шагов и правил, принимающих решения какой шаг сделать. И если мы будем отталкиваться от этого, то:

а) Есть те области, где получены четкие последовательности действий,условия их протекания, а потому мы просто выбираем уже описанную ситуацию, алгоритм действия под нее и ожидаем четкого результата. Если мы ищем подстроку, то нам нужен четкий ответ на то где она и есть ли она. Если работаем с БД аналогично, длительные поиски движения по скрытым от нас траекториям и т.д. нас не устроят. И здесь смесь приемов ФП на ИП очень хорошо себя показывает, а пуризм сливает при чем очень сильно.

б) А есть такие задачи, где мы имеем некоторые базовые довольно универсальные алгоритмы поиска, которые настраивают под себя данные. Особенность таких задач, что данные требуют для своего анализа много условий и их сочетаний. Человеку описать их все будет очень сложно, очень легко ошибиться. Однако если он правильно опишет исходные факты и правила вывода, то все эти условия будут выведены сами. И действительно в таком случае знать человеку детально все шаги ОБЫЧНО не нужно, но при отладке инструментов деклар. прогр. или особо запутанных случаев-полезно. Но этот тип задач тот который недостаточно хорошо поддается формализации или полная пошаговая формализация его трудоемка.

Относительно же батона: конечно я не думаю в стиле сделай шаг влево иначе... Но думаем мы опять неслишком то декларативно, скорее в духе динамического программирования: конечная задача-купить хлеб, а для этого нужно решить такие подзадачи, а для них нужно такие-то. А вот столь скурпулезные вещи как влево, вправо берет на себя очень низкий для данного контекста уровень-вегетативная нервная система и «низкоуровневые» отделы ЦНС, оторые услужливо от нас скрывают все счетчики, правда когда происходит инсульт, etc, этот нижний уровень нас не спасает, вот тогда начинается столько счетчиков... и и недекларативщины. Так что RL нам демонстрирует то что ей ближе нестолько декларативность, сколько подход: абстрагируй как можно большеи и объединяй как можно больше. Ведь ходьба объединяет в себе столько действий,однако в мозге эти зоны объединяются и на уровне внутреннего архитектурного решения, а уж на уровне интерфейсов тем паче.

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

Что это вообще за хрень «мегаволшебные преймущества»?

Возьмем указанный пример с циклом. В общем и целом указанный пример с циклами зупускается для того чтобы входные данные (список) - преобразовать в некие выходные данные. То есть у программиста есть вход - ему нужен результат. Теперь расмотрим пример:

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

Что я пишу фпешно?

правильно

filter(isOdd, InputList)

напишем по русски

отфильтруй(нечетные, вход_список).

Что я пишу на матером форе?

List OutputList // ого!

for (i /*что это за херня*/; i < length(InnutList) /*ну тупая - конец списка сама не найдет*/); i++ /*ого какой закат солнца в ручную?*/) {
      if (isOdd(InputList[i]) /*нихрена се мешанина концепций - обращение по индексу, ручной вызов придеката для каждого элемента, и ручная проверка возвращаемого значения*/
        Outtput += InputList[i] /*шо опять индексы? Еще и ручное конструирование результата?*/
}

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

Вот и я хочу чтобы всю трансляцию высокоуровневых требований «что сделать» в фоннеймана делала вегетативная нервная система - среда программирования. Чтобы она была максимально умной и училась понимать мои абстракции. Мне приятнее вести диалог называемый 'программирование' с умным человеком, а не тратить основное свое время собирая слюни за идиотом.

primes=[]
for i in xrange(1,101):
   if IsOdd(i):
      primes+=[i]
      

или

primes=[]
for i in xrange(1,101):
   if IsOdd(i):
      primes.append(i)
      

А если последовательность ленивая, то «Ой!», тебе придется вычислить каждый элемент... Явное пренебрежение инкапсуляцией.

изменилось мало - только индексная переменная исчезла.