Читабельность задаётся стереотипами, которые внедряются через образование. А это школа. А в школе — математика.
У, Вы сами себя в угол загнали… см. выше коммент про ФП.
Где императивное программирование, а где математика — это ж 2 диаметрально противоположных мира )))
Вообще, про читабельность я сравнивал (positive? n) и (> n 0)…
(n > 0) и (> n 0) на мой взгляд эквивалентны по читаемости, просто второй вариант непривычен, зато единообразен — функция всегда на первом месте.
Алгоритм один и тот же, но букаф — очень разное к-во.
Ладно, я следаю вид, что не заметил Ваш чит с подменой JS на кофе, т.к. очевидно, что в JS скобок было бы ничуть не меньше, чем в Racket.
И нужно сравнивать экосистемы языков. Ибо вот писать с нуля какую-нить либу — это вот уже боль.
У экосистемы Node.JS leftpad-синдром. При этом даже Вы преподносите число пакетов в N раз превышающее кол-во пакетов под Python как плюс. Вы даже не задумываетесь насколько это жирный минус. Задумайтесь, откуда берётся эта разница? Думаете JS решает в N раз больше задач, как бы не так...
Ну, если у скрипта поменять шабанг — то тоже можно получить очень даже другой язык :)
Да, только тут то язык остался тот же. Так можно сочетать разные концепции в рамках одного языка, не нарушая чистоту концепции. Имхо, для обучения — это прекрасный вариант.
Нет, с точки зрения ФП это равно true, т.к. функция оба раза вызывается с одинаковыми аргументами, точнее вообще без них. Вот и как с таким косяком в stdlib объяснять ФП?
Но если из результата работы процедуры взять и получить результат — то это уже прям меняет парадигму программирования?
:facepalm:
Вы думаете, что процедурном программировании подпрограмма не может вернуть результат? Прочитайте хоть статью на вики, а то ведь реально путаете.
И ну не вижу почему это может мешать функциональному программированию.
В ФП все данные неизменны. Собственно, что данные, что функции трактуются в математическом понимании. Т.е. что однажды попало в память, то так и будет там лежать, пока GC до него не доберётся. Изменить значение в памяти нельзя.
При этом переменные можно переназначать (rebinding), но данные от этого не меняются, просто становятся доступны для GC, если ни одна переменная с ними не связана.
А функция в математическом понимании обязана быть строго определена в зависимости от аргументов. Например, f(x, y) == f(x, y) вне зависимости от того, что такое f и какие значения связаны с x, y.
Т.е. свежие ES6 и ES7, введшие множество фич и синтаксического сахара (движение к питон-стилю синтаксиса) — Вы не рассматриваете как развитие?
Я рассматриваю это как неизбежное заимствование фич и решений под давлением других языков.
Просто хочу либо какой-то конкретики про JS (почему он так уж плох)
В первую очередь слабой динамической типизацией он плох, такую типизацию можно простить только Си для low-level оптимизаций, ни один язык высокого уровня не должен себе такую хрень позволять. Ну и архитектурными просчётами, которые начали потихоньку фиксить, начиная с ES6, но на это ещё хз сколько лет уйдёт.
Ну либо Вы в состоянии показать заведомо идеальный и давно неизменный ЯП?
Нет конечно, на это только Пайк способен, но мало кто с ним согласен )))
Тем не менее, очень немногие языки "развиваются" по сценарию "%lang_name% — говно, давайте его целиком переделаем". Обычно люди как-то более вдумчиво подходят к дизайну языка и не переделывают его кардинально после версии 1.0.
изначально в ТЗ на язык, видать, было так
Да, Вы угадали… изначально идея была в создании языка, который позволил бы писать ПО для управления тысячами устройств, без даунтайма, чтобы при звонках на телефон АТС не отвечала "извините, у нас тут ПО зависло". По совпадению, теперь для обычной разработки нужен именно такой язык. Кто ещё может похвастаться аналогом OTP? Особенно учитывая, что она уже 25 лет в бою под такими нагрузками, которые 99.999% проектов даже не снились, и 20 лет в OpenSource.
На ерланге я знаю целую софтину (ejabberd)
А про Riak или RabbitMQ не слышали? Ну или хотя бы про WhatsApp?
Почему у них так негуст рынок при такой то архитектуре?
Потому что раньше не были востребованы такие навороты в широких кругах. Всего 10 лет назад можно было прямо в php-файл вёрстку закинуть и збс, сайтец готов :-)
кстати, оператор const в других языках никто не отменял
по-моему Вы не очень понимаете, что такое иммутабельность данных, если сравниваете её с const (который вообще к идентификатору относится, а не к данным)
Объём сторонних библиотек и прочей инфы — всё это списать со счетов популярных языков только из-за одной фичи — не вариант.
Вы просто не представляете объём сторонних библиотек и прочей инфы, по языкам, с которыми не знакомы… и их популярность тоже недооцениваете )
У учеников сложится впечатление, что «за ООП — это идти к ЯП1, функциональное — это к ЯП2, а эффективно использовать проц — это к ЯП3»
Ничего страшного. По факту всё так и есть, по-крайней мере на данном этапе развития IT. В мультипарадигмальных языках есть возможность использовать несколько разнородных концепций одновременно, но это в реальности достигается путём уступок и жёстких компромиссов.
А как Вы предлагаете выбирать язык, наиболее подходящий под задачу, если человек освоил только "молоток" и все задачи ему кажутся "гвоздями" xD
это не смайлик, а 6 (ШЕСТЬ!!!) закрывающих скобочек.
И что? Скобки редактор прекрасно расставляет, когда пишешь на лиспе, на них вообще внимание не обращаешь.
И как они там выглядят? функциями «zero?» или «positive?»? — нет, математическим языком оно записывается знаками
Наличие вспомогательных функций не запрещает Вам написать (> n 0). Что читабельнее вопрос спорный.
Читабельность — разница налицо.
Имхо, не в пользу CoffeeScript… freeze above t, beside t, t — вообще нечитаемо. Но вопрос даже не в этом… для JavaScript я не видел библиотек, похожих на стандартную поставку Racket. Там придётся собирать учебный дистрибутив из г**на и палок, ой т.е. из npm-пакетов неизвестного качества.
К слову, ракет — тоже мультипарадигмальный: «объектно-ориентированный, процедурный, рефлективный, функциональный, логический, мета»
Есть такое… Хотя правильнее сказать, что он метаориентированный, а библиотеки для других парадигм — уже как следствие. Это даёт чуть большую чистоту. См. директиву в первой строке. Её можно заменить на другую и получить язык с другим набором концепций, т.е. они не навалены все в одну кучу. Например "#lang typed/racket"
В своё время, изучая питон, я спокойно писал функционально и, грубо говоря, знать не знал оператор «class» и конструктор init.
Вы, видимо, путаете "процедурно" и "функционально". Невольно подтверждая мой тезис о том, что концептуального образования дико не хватает. Даже профессиональные программисты частенько путаются в элементарных вещах.
К примеру, в питоне есть мутабельные данные, этого уже достаточно для невозможности писать в чисто функциональном стиле и использовать стандартную библиотеку одновременно.
Ну или вот яркий пример. Скажите, чему с точки зрения ФП равно
На мой взгляд, развитие — это когда что-то новое появляется (заимствования не в счёт) или хотя бы плохое старое отбрасывается… И это явно не про JavaScript.
Это бессмысленно потому, что «колбасит»? Или почему бессмысленно?
Да, если он и останется, то через 10 лет это будет совсем другой язык.
Но вообще в JavaScript далеко не самая удачная модель асинхронности — всё упирается в центральный однопоточный event-loop. Сравните с Erlang/Elixir, где центральный event-loop отсутствует как класс, а акторы масштабируются на сколько угодно ядер или даже на кластер машин.
В остальном пока театр одного актёра в свободное от гастролей время.
Так я про это изначально и спросил: зачем называть себя самого Эликсир-сообществом?
Сейчас цель — показать русскоязычным ребятам, что Эликсир есть и его уже можно смело взять поработать.
Переводами статей? Для человека, который не знает английский на уровне "читаю без словаря" — безумие браться за Elixir. Все книги, документация — всё на английском.
Статьи могут только привлечь внимание к технологическому стеку. Но для этого они должны быть на интересную тему… А Вы почему то выбрали цикл статей про блог… Что может быть более уныло, чем очередной мануал по написанию блога? Я прекрасно понимаю какой огромный объём работы — переводить такие длинные статьи.
Но зачем? Во-первых, чтобы блог написать хватит и RoR, у Elixir другая область применения. Во-вторых, на хабре уже был цикл из 9 частей "Клон Trello на Phoenix и React", который освещает по большому счёту те же темы, что и ваш цикл статей.
Если есть желание внести свой вклад, буду очень рад — пишите!
Да я и так уже больше года вношу свой вклад в Elixir-community и не только в российское. И искренне не понимаю, что привносит Ваше начинание… Никаких возможностей оно пока не добавляет.
Но с другой стороны можно найти этому логичное объяснение
У многих языков есть несколько режимов компиляции, хотя бы Debug и Release. Что мешает Go при импорте лишних пакетов выдавать warning, а ошибку компиляции оставить только для Release-варианта?
Сделать это элементарно, зато Вы смогли бы во время разработки не отвлекаться на удаление импортов, а потом почистить их единоразово, когда текущая задача уже решена.
Так если оно и существует, то при этом оно абсолютно непрозрачное… Кто в нём участвует (подписчики не в счёт)? Какие цели сообщество ставит перед собой? Если в нём много народа, то почему полезный выхлоп — 1 перевод в месяц? Слишком много вопросов и никаких ответов Ваш сайт на них не даёт.
Пишите в канал otp-russian.herokuapp.com, организуйте митапы, выпускайте полезные пакеты с российской тематикой и не только. Вообще Elixir сообщество вполне себе глобально и чтобы контрибютить никакие посредники не нужны. Локальные сообщества возможно имеют какую-то ценность, но так Вы непонятно даже в каком городе дислоцируетесь.
Forth тоже имеет смысл изучить, особенно учитывая популярность стековых виртуальных машин. Но это уже всё-таки для профессиональных программистов. В рамках школы, имхо, достаточно про ОПЗ рассказать.
А сотни ядер — это уже актуально, и 10 лет ждать незачем :)
Ну я пока на практике видел серваки только с 12 ядрами… Но тем не менее, этот тренд уже действительно очевиден.
Вот и смотрите, как эффективно занять 100 ядер вычислениями и не попасть на race condition? Нужны иммутабельные данные. В каких языках они есть? Erlang, Lisp, Haskell и тому подобное.
Да можно и по-другому, но достаточно сравнить привычную для Java модель с потоками/ мьютексами и модель акторов… и становится очевидно, что Java пора на пенсию. Она конечно сопротивляется, но генерирует больше аргументов в пользу Scala и Clojure, чем за саму себя.
это те, которые, якобы, не тратят время на вычисления?
В смысле? Время всё равно тратиться будет, только меньше :-)
Чистая декларативность, как я понимаю, этого не обеспечивает?
Отчего же… λ-исчисление обладает свойством полноты по Тьюрингу. Т.е. на любом функциональном языке можно написать любую программу.
Вопрос удобства, конечно, остаётся. Пока (с текущей архитектурой компов) у них в этом плане паритет… Для каких-то задач удобнее декларативный подход, для каких-то — императивный. Для квантовых, насколько мне известно, пока только декларативный применяют.
Это Lisp. По факту самый простой синтаксис для освоения. Но зашоренность сознания привычным С-like синтаксисом может мешать восприятию, это да.
К тому же Вы ж сами писали, что получать результат быстро — это круто.
Тут в 5 строках алгоритм отрисовки треугольника Серпинского. А фракталы — это интересно и весело. Теперь прикиньте сколько кода писать на JS пришлось бы для того же результата :-D
Я не могу назвать «кашей» мультипарадигмальный язык.
Смотрите в чём фишка: мультипарадигмальный язык не позволяет вам по факту использовать ни одну парадигму в чистом виде. Для обучения — это, на мой взгляд, самое ужасное. У школьника ещё не выкристаллизовалось понимание концепции, а его заставляют её применять на языке, который эту концепцию не поддерживает даже на 80%.
Для промышленного применения это катит, т.к. можно применять фичи какой-то концепции даже не понимая её… такой "херак-херак и в продакшн". Но тут надо понимать какой вы хотите результат — заложить основу для становления кодеров за еду, в стиле Индии и Китая, или основу для становления профессиональных программистов.
Если есть возможность давать более востребованные знания новым поколениям…
Так я и предлагаю давать более востребованные знания, а не плодить кодеров-индусов из русских )))
Да что тут считать. Берём статистику по языкам на гитхабе и всё видно
Вы делаете прогноз на 10 лет, просто по текущему кол-ву открытых репозиториев на github? Ваше право, конечно, но имхо слабоватая метрика для прогнозов.
JavaScript сейчас колбасит только так. Учить его сейчас, чтобы найти работу в 2017 году — можно. С горизонтом 10 лет — бессмысленно.
А более удобных синтаксисов и так уже навалом.
Это невероятно важно как для меня лично, так и для всего сообщества Эликсира в целом.
Я так понимаю, wunsh.ru — это Ваш личный проект… Почему Вы от лица всего сообщества Эликсира второй раз вещаете? Переводите себе спокойно статьи, к чему эти понты?
То есть — «всё как в жизни». Типа того. А ещё есть иерархия объектов по наследованию — опять таки — как в жизни.
Ага, именно "типа того". А по факту ничего общего с тем, как в жизни :-)
Да ещё и у каждого своё инстинктивное понимание. Некоторые вообще взаимоисключающие. Впрочем не будем про ООП, на Хабре уже есть много холиваров на эту тему, из которых понятно, что ничего не понятно и общепринятых определений нет :-)
Я всегда считал (читал) что «функция высшего порядка» — это «функция возвращающая функцию».
Там 2 критерия в определении:
принимает одну или более функций в качестве аргумента
возвращает функцию в качестве результата
Любого из этих критериев достаточно, чтобы функцию назвать функцией высшего порядка.
Это уж слишком «низкий» подход у вас.
Да нет, просто идеи ФП заимствуют для императивных мейнстрим-языков и они уже не совсем императивные. Те же ФВП теперь где только не встретишь..
1) Получим объект(!) типа Массив элементов.
2) Определим, есть ли «наш элемент» в данном объекте вызвав («дёрнув») метод этого объекта.
Ну если уж про ООП, то надо ещё про паттерн Iterator добавить. А то Вы подменяете реализацию алгоритма на её использование. А использование вообще не сильно отличается:
Если посмотреть на то, что человек, который явно понимает ФП, написал статью, но судя по коментам — не совсем правильно понимает базовые понятия ФП, то становится понятно что функциональное программирование — довольно «путанная штука».
Swift и уж тем более C — не являются функциональным ЯП. Haskell автор не знает на достаточном уровне. Я его и сам не знаю толком, но в статье совсем уж детские грабли в Haskell-коде.
Что до путанности, посмотрите статьи про ООП и вообще офигеете. Абсолютно ни у кого нет чёткого понимания, что входит в это понятие, а что нет. И по каждому ассоциированному термину влёгкую можно начать холивар. ФП в этом плане отлично формализовано, что конечно не страхует от того, что кто-то может что-то напутать. Человеческий фактор не отменить, зато всегда можно глянуть точное определение.
1) Получим массив элементов.
2) Определим, есть ли «наш элемент» в данном массиве?
Это тоже функциональный подход.
Императивный подход:
1) Получим указатель на массив элементов и целевой элемент
2) Определим длину массива
3) В цикле от 0 до длина-1 будем сравнивать i-ый элемент массива с целевым.
4) Если элемент совпал, то return true
5) return false
Это просто вещественная переменная нужной точности.
Поясните… Вероятность — это не просто вещественная переменная. Допустим для 0.5 она означает, что обе ветки и if и else исполняются равновероятно. Булева же логика может исполнить только одну ветку.
Обычно вероятность пытаются эмулировать через random, но это ничего общего с человеческой логикой. Её эмулируют нейросети, но пока на очень-очень базовом уровне.
У, Вы сами себя в угол загнали… см. выше коммент про ФП.
Где императивное программирование, а где математика — это ж 2 диаметрально противоположных мира )))
Вообще, про читабельность я сравнивал (positive? n) и (> n 0)…
(n > 0) и (> n 0) на мой взгляд эквивалентны по читаемости, просто второй вариант непривычен, зато единообразен — функция всегда на первом месте.
Ладно, я следаю вид, что не заметил Ваш чит с подменой JS на кофе, т.к. очевидно, что в JS скобок было бы ничуть не меньше, чем в Racket.
У экосистемы Node.JS leftpad-синдром. При этом даже Вы преподносите число пакетов в N раз превышающее кол-во пакетов под Python как плюс. Вы даже не задумываетесь насколько это жирный минус. Задумайтесь, откуда берётся эта разница? Думаете JS решает в N раз больше задач, как бы не так...
Да, только тут то язык остался тот же. Так можно сочетать разные концепции в рамках одного языка, не нарушая чистоту концепции. Имхо, для обучения — это прекрасный вариант.
Нет, с точки зрения ФП это равно true, т.к. функция оба раза вызывается с одинаковыми аргументами, точнее вообще без них. Вот и как с таким косяком в stdlib объяснять ФП?
:facepalm:
Вы думаете, что процедурном программировании подпрограмма не может вернуть результат? Прочитайте хоть статью на вики, а то ведь реально путаете.
В ФП все данные неизменны. Собственно, что данные, что функции трактуются в математическом понимании. Т.е. что однажды попало в память, то так и будет там лежать, пока GC до него не доберётся. Изменить значение в памяти нельзя.
При этом переменные можно переназначать (rebinding), но данные от этого не меняются, просто становятся доступны для GC, если ни одна переменная с ними не связана.
А функция в математическом понимании обязана быть строго определена в зависимости от аргументов. Например,
f(x, y) == f(x, y)вне зависимости от того, что такое f и какие значения связаны с x, y.Я рассматриваю это как неизбежное заимствование фич и решений под давлением других языков.
В первую очередь слабой динамической типизацией он плох, такую типизацию можно простить только Си для low-level оптимизаций, ни один язык высокого уровня не должен себе такую хрень позволять. Ну и архитектурными просчётами, которые начали потихоньку фиксить, начиная с ES6, но на это ещё хз сколько лет уйдёт.
Нет конечно, на это только Пайк способен, но мало кто с ним согласен )))
Тем не менее, очень немногие языки "развиваются" по сценарию "%lang_name% — говно, давайте его целиком переделаем". Обычно люди как-то более вдумчиво подходят к дизайну языка и не переделывают его кардинально после версии 1.0.
Да, Вы угадали… изначально идея была в создании языка, который позволил бы писать ПО для управления тысячами устройств, без даунтайма, чтобы при звонках на телефон АТС не отвечала "извините, у нас тут ПО зависло". По совпадению, теперь для обычной разработки нужен именно такой язык. Кто ещё может похвастаться аналогом OTP? Особенно учитывая, что она уже 25 лет в бою под такими нагрузками, которые 99.999% проектов даже не снились, и 20 лет в OpenSource.
А про Riak или RabbitMQ не слышали? Ну или хотя бы про WhatsApp?
Потому что раньше не были востребованы такие навороты в широких кругах. Всего 10 лет назад можно было прямо в php-файл вёрстку закинуть и збс, сайтец готов :-)
по-моему Вы не очень понимаете, что такое иммутабельность данных, если сравниваете её с const (который вообще к идентификатору относится, а не к данным)
Вы просто не представляете объём сторонних библиотек и прочей инфы, по языкам, с которыми не знакомы… и их популярность тоже недооцениваете )
Ничего страшного. По факту всё так и есть, по-крайней мере на данном этапе развития IT. В мультипарадигмальных языках есть возможность использовать несколько разнородных концепций одновременно, но это в реальности достигается путём уступок и жёстких компромиссов.
А как Вы предлагаете выбирать язык, наиболее подходящий под задачу, если человек освоил только "молоток" и все задачи ему кажутся "гвоздями" xD
И что? Скобки редактор прекрасно расставляет, когда пишешь на лиспе, на них вообще внимание не обращаешь.
Наличие вспомогательных функций не запрещает Вам написать
(> n 0). Что читабельнее вопрос спорный.Имхо, не в пользу CoffeeScript…
freeze above t, beside t, t— вообще нечитаемо. Но вопрос даже не в этом… для JavaScript я не видел библиотек, похожих на стандартную поставку Racket. Там придётся собирать учебный дистрибутив изг**на и палок, ой т.е. из npm-пакетов неизвестного качества.Есть такое… Хотя правильнее сказать, что он метаориентированный, а библиотеки для других парадигм — уже как следствие. Это даёт чуть большую чистоту. См. директиву в первой строке. Её можно заменить на другую и получить язык с другим набором концепций, т.е. они не навалены все в одну кучу. Например "#lang typed/racket"
Вы, видимо, путаете "процедурно" и "функционально". Невольно подтверждая мой тезис о том, что концептуального образования дико не хватает. Даже профессиональные программисты частенько путаются в элементарных вещах.
К примеру, в питоне есть мутабельные данные, этого уже достаточно для невозможности писать в чисто функциональном стиле и использовать стандартную библиотеку одновременно.
Ну или вот яркий пример. Скажите, чему с точки зрения ФП равно
?
На мой взгляд, развитие — это когда что-то новое появляется (заимствования не в счёт) или хотя бы плохое старое отбрасывается… И это явно не про JavaScript.
Да, если он и останется, то через 10 лет это будет совсем другой язык.
Но вообще в JavaScript далеко не самая удачная модель асинхронности — всё упирается в центральный однопоточный event-loop. Сравните с Erlang/Elixir, где центральный event-loop отсутствует как класс, а акторы масштабируются на сколько угодно ядер или даже на кластер машин.
Так я про это изначально и спросил: зачем называть себя самого Эликсир-сообществом?
Переводами статей? Для человека, который не знает английский на уровне "читаю без словаря" — безумие браться за Elixir. Все книги, документация — всё на английском.
Статьи могут только привлечь внимание к технологическому стеку. Но для этого они должны быть на интересную тему… А Вы почему то выбрали цикл статей про блог… Что может быть более уныло, чем очередной мануал по написанию блога? Я прекрасно понимаю какой огромный объём работы — переводить такие длинные статьи.
Но зачем? Во-первых, чтобы блог написать хватит и RoR, у Elixir другая область применения. Во-вторых, на хабре уже был цикл из 9 частей "Клон Trello на Phoenix и React", который освещает по большому счёту те же темы, что и ваш цикл статей.
Да я и так уже больше года вношу свой вклад в Elixir-community и не только в российское. И искренне не понимаю, что привносит Ваше начинание… Никаких возможностей оно пока не добавляет.
У многих языков есть несколько режимов компиляции, хотя бы Debug и Release. Что мешает Go при импорте лишних пакетов выдавать warning, а ошибку компиляции оставить только для Release-варианта?
Сделать это элементарно, зато Вы смогли бы во время разработки не отвлекаться на удаление импортов, а потом почистить их единоразово, когда текущая задача уже решена.
Так если оно и существует, то при этом оно абсолютно непрозрачное… Кто в нём участвует (подписчики не в счёт)? Какие цели сообщество ставит перед собой? Если в нём много народа, то почему полезный выхлоп — 1 перевод в месяц? Слишком много вопросов и никаких ответов Ваш сайт на них не даёт.
Пишите в канал otp-russian.herokuapp.com, организуйте митапы, выпускайте полезные пакеты с российской тематикой и не только. Вообще Elixir сообщество вполне себе глобально и чтобы контрибютить никакие посредники не нужны. Локальные сообщества возможно имеют какую-то ценность, но так Вы непонятно даже в каком городе дислоцируетесь.
Forth тоже имеет смысл изучить, особенно учитывая популярность стековых виртуальных машин. Но это уже всё-таки для профессиональных программистов. В рамках школы, имхо, достаточно про ОПЗ рассказать.
Кстати, да, тоже вариант для детей помладше.
Ну я пока на практике видел серваки только с 12 ядрами… Но тем не менее, этот тренд уже действительно очевиден.
Вот и смотрите, как эффективно занять 100 ядер вычислениями и не попасть на race condition? Нужны иммутабельные данные. В каких языках они есть? Erlang, Lisp, Haskell и тому подобное.
Да можно и по-другому, но достаточно сравнить привычную для Java модель с потоками/ мьютексами и модель акторов… и становится очевидно, что Java пора на пенсию. Она конечно сопротивляется, но генерирует больше аргументов в пользу Scala и Clojure, чем за саму себя.
В смысле? Время всё равно тратиться будет, только меньше :-)
Отчего же… λ-исчисление обладает свойством полноты по Тьюрингу. Т.е. на любом функциональном языке можно написать любую программу.
Вопрос удобства, конечно, остаётся. Пока (с текущей архитектурой компов) у них в этом плане паритет… Для каких-то задач удобнее декларативный подход, для каких-то — императивный. Для квантовых, насколько мне известно, пока только декларативный применяют.
Нет, это просто наиболее простой способ выполнить ветку алгоритма с какой-то вероятностью, отличной от 0 и 1.
Это Lisp. По факту самый простой синтаксис для освоения. Но зашоренность сознания привычным С-like синтаксисом может мешать восприятию, это да.
К тому же Вы ж сами писали, что получать результат быстро — это круто.
Тут в 5 строках алгоритм отрисовки треугольника Серпинского. А фракталы — это интересно и весело. Теперь прикиньте сколько кода писать на JS пришлось бы для того же результата :-D
Смотрите в чём фишка: мультипарадигмальный язык не позволяет вам по факту использовать ни одну парадигму в чистом виде. Для обучения — это, на мой взгляд, самое ужасное. У школьника ещё не выкристаллизовалось понимание концепции, а его заставляют её применять на языке, который эту концепцию не поддерживает даже на 80%.
Для промышленного применения это катит, т.к. можно применять фичи какой-то концепции даже не понимая её… такой "херак-херак и в продакшн". Но тут надо понимать какой вы хотите результат — заложить основу для становления кодеров за еду, в стиле Индии и Китая, или основу для становления профессиональных программистов.
Так я и предлагаю давать более востребованные знания, а не плодить кодеров-индусов из русских )))
Вы делаете прогноз на 10 лет, просто по текущему кол-ву открытых репозиториев на github? Ваше право, конечно, но имхо слабоватая метрика для прогнозов.
JavaScript сейчас колбасит только так. Учить его сейчас, чтобы найти работу в 2017 году — можно. С горизонтом 10 лет — бессмысленно.
А более удобных синтаксисов и так уже навалом.
Я так понимаю, wunsh.ru — это Ваш личный проект… Почему Вы от лица всего сообщества Эликсира второй раз вещаете? Переводите себе спокойно статьи, к чему эти понты?
Ага, именно "типа того". А по факту ничего общего с тем, как в жизни :-)
Да ещё и у каждого своё инстинктивное понимание. Некоторые вообще взаимоисключающие. Впрочем не будем про ООП, на Хабре уже есть много холиваров на эту тему, из которых понятно, что ничего не понятно и общепринятых определений нет :-)
Там 2 критерия в определении:
Любого из этих критериев достаточно, чтобы функцию назвать функцией высшего порядка.
Да нет, просто идеи ФП заимствуют для императивных мейнстрим-языков и они уже не совсем императивные. Те же ФВП теперь где только не встретишь..
Ну если уж про ООП, то надо ещё про паттерн Iterator добавить. А то Вы подменяете реализацию алгоритма на её использование. А использование вообще не сильно отличается:
Процедурный стиль:
in_array(arr, obj)ООП:
arr.include?(obj)ФП:
Enum.member?(arr, obj)Что до путанности, посмотрите статьи про ООП и вообще офигеете. Абсолютно ни у кого нет чёткого понимания, что входит в это понятие, а что нет. И по каждому ассоциированному термину влёгкую можно начать холивар. ФП в этом плане отлично формализовано, что конечно не страхует от того, что кто-то может что-то напутать. Человеческий фактор не отменить, зато всегда можно глянуть точное определение.
Это тоже функциональный подход.
Императивный подход:
1) Получим указатель на массив элементов и целевой элемент
2) Определим длину массива
3) В цикле от 0 до длина-1 будем сравнивать i-ый элемент массива с целевым.
4) Если элемент совпал, то return true
5) return false
Обычно вероятность пытаются эмулировать через random, но это ничего общего с человеческой логикой. Её эмулируют нейросети, но пока на очень-очень базовом уровне.