алгоритмы (программы) как таковые — это пути перехода между какими-то состояниями
О, Вы мне напомнили ещё одно отличие между императивным и декларативным подходами. Императивный описывает процесс изменения состояния, а декларативный — процесс перехода между состояниями.
Конечно же, это всё мои предпочтения. И всё, что я пытаюсь — это вызвать здравый огонь критики в адрес этого выбора.
Ну как же я могу критиковать CoffeeScript, он же вдохновлён примером Ruby. А на Ruby я программировал аж 8 лет :-)
Разве что злоупотребляете poetry mode..
Уже отсеиваю их за считанные минуты. Зато есть выбор.
Зашёл ради интереса на npmjs поискать клиент для redis и "193 results for ‘redis client’" и при этом даже сортировки по кол-ву звёзд нет… Уже начинаю завидовать Вашей скорости анализа сторонних библиотек.
Было куда хуже, когда программел асинхронность на питоновском твистеде
Да я за питон нигде не агитировал. И даже согласен, что GIL в текущих реалиях уже тоже шоустопер. Впрочем, эвент-луп JS от блокирующих операций пока не защищен и это тоже проблема.
Наверно потому, что быстро делать не то, что нужно, никому не надо…
И почему сравнение некорректное? И то и то будет правильно работать в некоторых случаях.
я ж уже просил пример другого какого языка, на котором можно было бы программить почти на всём мыслимом железе
А на каком языке сейчас нельзя? Упомянутые Вами малинки потянут что угодно из компилируемых ЯП, они даже интерпретируемые типа JavaScript тянут. Вообще идея для всего использовать один язык — это как раз та история про плотника с молотком. Ну можно на JS писать под десктоп (Electron), но это ж тихий ужас… Приложение весит 100+ Mb, и память жрёт не хуже, чем браузер. Не у всех на десктопе по 16 Gb оперативы… тот же C# на десктопе JS уделывает как тузик грелку.
Поэтому чем тут мериться? Тем что "для галочки" везде можно использовать?
Дескать, всё что есть из популярного — всё чисто недопиленные позёрские поделия…
Причём тут позёрство? К примеру, чисто технически невозможно сделать одновременно функциональноориентированный и объектноориентированный язык. Хотя бы потому что в для первого — необходимо передавать состояние функциям, а для второго слать сообщения "состоянию"(объектам).
Можно частично использовать ООП и ФП совместно, но нельзя ориентировать один язык сразу на 2 парадигмы. Всё равно одна будет ведущей, а другие — частично поддерживаемы.
Там по ссылке какая-то жесть… история, биология, геофизика и т.д. — это тоже разделы математики?
ФП — это раздел дискретной математики, там всё понятно.
Императивное программирование же искажает базовые математические понятия — функция, значение, etc.
Да какой чит? Конечно же кофескрипт.
С чего вдруг "конечно же"? Вы недавно про ES6/7 писали… А какая вам вообще печаль, что там в ES творится, если Вы по факту другой язык используете? Да и почему "конечно же кофескрипт"? Почему не TypeScript или не PureScript или не ClojureScript или ещё пара десятков вариантов? Вы свой личный выбор выдаёте за что-то дефолтное.
Но сути это не меняет.
Суть в том, что при выборе каждого пакета, Вам придётся сталкиваться с буридановым выбором.
Т.е. Вы мотивируете отсутствие корректной реализации тем, что она медленнее некорректной?
Давайте по такому же принципу вместо сортировки будем только первые 2 элемента сравнивать, так ведь быстрее.
Как в вашу императивную картину мира вписываются такие факты:
Twitter выбрал Scala, WhatsApp — Erlang, Facebook — написал свой язык.
Сложность проектов и требования к ним растут, текущий мейнстрим — это временное явление, впрочем как всегда.
По-моему Вы боитесь, что люди после школы будут знать больше полезного, чем большинство текущих программистов. Поэтому хотите их учить тому, что наверняка уж устареет и как можно быстрее :-)
Где, кроме суровых железных ограничений, придётся пойти на «жёсткий компромисс» и выбрать моно-язык какой, без того же ООП, а оно в проекте нужно?
Вы не поняли… на компромиссы приходится идти дизайнерам языка, чтобы вписать в него несколько взаимоисключающих парадигм. В итоге ни одна не реализована толком, но какие-то отдельные фичи можно юзать.
Читабельность задаётся стереотипами, которые внедряются через образование. А это школа. А в школе — математика.
У, Вы сами себя в угол загнали… см. выше коммент про ФП.
Где императивное программирование, а где математика — это ж 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, чем за саму себя.
это те, которые, якобы, не тратят время на вычисления?
В смысле? Время всё равно тратиться будет, только меньше :-)
Чистая декларативность, как я понимаю, этого не обеспечивает?
Отчего же… λ-исчисление обладает свойством полноты по Тьюрингу. Т.е. на любом функциональном языке можно написать любую программу.
Вопрос удобства, конечно, остаётся. Пока (с текущей архитектурой компов) у них в этом плане паритет… Для каких-то задач удобнее декларативный подход, для каких-то — императивный. Для квантовых, насколько мне известно, пока только декларативный применяют.
Скорее автомобиль, который приезжал бы в два (далёких друг от друга) пункта назначения одновременно.
О, Вы мне напомнили ещё одно отличие между императивным и декларативным подходами. Императивный описывает процесс изменения состояния, а декларативный — процесс перехода между состояниями.
Ну как же я могу критиковать CoffeeScript, он же вдохновлён примером Ruby. А на Ruby я программировал аж 8 лет :-)
Разве что злоупотребляете poetry mode..
Зашёл ради интереса на npmjs поискать клиент для redis и "193 results for ‘redis client’" и при этом даже сортировки по кол-ву звёзд нет… Уже начинаю завидовать Вашей скорости анализа сторонних библиотек.
Да я за питон нигде не агитировал. И даже согласен, что GIL в текущих реалиях уже тоже шоустопер. Впрочем, эвент-луп JS от блокирующих операций пока не защищен и это тоже проблема.
Наверно потому, что быстро делать не то, что нужно, никому не надо…
И почему сравнение некорректное? И то и то будет правильно работать в некоторых случаях.
Мимо, имелась кодовая база и куча спецов на Ruby.
А помните как переводили кодовую базу? https://github.com/facebookarchive/lex-pass/tree/master
А на каком языке сейчас нельзя? Упомянутые Вами малинки потянут что угодно из компилируемых ЯП, они даже интерпретируемые типа JavaScript тянут. Вообще идея для всего использовать один язык — это как раз та история про плотника с молотком. Ну можно на JS писать под десктоп (Electron), но это ж тихий ужас… Приложение весит 100+ Mb, и память жрёт не хуже, чем браузер. Не у всех на десктопе по 16 Gb оперативы… тот же C# на десктопе JS уделывает как тузик грелку.
Поэтому чем тут мериться? Тем что "для галочки" везде можно использовать?
Причём тут позёрство? К примеру, чисто технически невозможно сделать одновременно функциональноориентированный и объектноориентированный язык. Хотя бы потому что в для первого — необходимо передавать состояние функциям, а для второго слать сообщения "состоянию"(объектам).
Можно частично использовать ООП и ФП совместно, но нельзя ориентировать один язык сразу на 2 парадигмы. Всё равно одна будет ведущей, а другие — частично поддерживаемы.
Там по ссылке какая-то жесть… история, биология, геофизика и т.д. — это тоже разделы математики?
ФП — это раздел дискретной математики, там всё понятно.
Императивное программирование же искажает базовые математические понятия — функция, значение, etc.
С чего вдруг "конечно же"? Вы недавно про ES6/7 писали… А какая вам вообще печаль, что там в ES творится, если Вы по факту другой язык используете? Да и почему "конечно же кофескрипт"? Почему не TypeScript или не PureScript или не ClojureScript или ещё пара десятков вариантов? Вы свой личный выбор выдаёте за что-то дефолтное.
Суть в том, что при выборе каждого пакета, Вам придётся сталкиваться с буридановым выбором.
Т.е. Вы мотивируете отсутствие корректной реализации тем, что она медленнее некорректной?
Давайте по такому же принципу вместо сортировки будем только первые 2 элемента сравнивать, так ведь быстрее.
Как в вашу императивную картину мира вписываются такие факты:
Twitter выбрал Scala, WhatsApp — Erlang, Facebook — написал свой язык.
Сложность проектов и требования к ним растут, текущий мейнстрим — это временное явление, впрочем как всегда.
По-моему Вы боитесь, что люди после школы будут знать больше полезного, чем большинство текущих программистов. Поэтому хотите их учить тому, что наверняка уж устареет и как можно быстрее :-)
Вы не поняли… на компромиссы приходится идти дизайнерам языка, чтобы вписать в него несколько взаимоисключающих парадигм. В итоге ни одна не реализована толком, но какие-то отдельные фичи можно юзать.
У, Вы сами себя в угол загнали… см. выше коммент про ФП.
Где императивное программирование, а где математика — это ж 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.