Все версии, в которых поддерживается скала 2.12.
Спарк 2.2.0 вышел в июле 17 года. 3 года назад! То, что вы используете такие старых версии инструментов — не проблема инструментов или языка. Обновитесь уже на актуальную версию
Да откуда у вас это мнение? Компилятор дотти уже сейчас кросс компилирует библиотеки из скалы 2. Авторы либ уже сейчас начинают переписывать части либ, где используются макросы. К релизу это всё уже будет. Имплиситов никуда не деваются. Всё старое на месте, и будет удаляться потом, через deprecation цикл.
Я открою вам страшный секрет — из одной и той же "архитектуры на листочке" можно сделать программу как в фп стиле, так и в ооп. Никто не проектирует "морфизмами".
А вы случаем не путаете "просто" и "знакомо"? Проектирование систем в фп стиле не означает, что система проектируется с использованием таких штук как "функтор" или "монада". Это проектирование, в котором иммутабельные данные проходят через ряд преобразований внутри функций. А функторы и монады — это уже детали реализации. Фп никаким образом не влияет на возможность людей договориться. Это просто немного другой подход. И, более того, на практике он не сильно отличается от тех же ооп best practices.
Мы используем у себя AirFlow для запуска периодических задач. И с ним постоянно какие-то проблемы. Регулярно видим "ядерный гриб". Сабдаги просто не работают. Старые issue закрываются, новые открываются. Давно уже хотим съехать с AirFlow на какой-то другой сервис. Но вот на какой — непонятно. Может кто-то посоветует?
Я являюсь большим любителем как scala, так и scala.js. Однако считаю, что данная статья — это худшее, что можно было выбрать для перевода. Я думаю, что автор статьи просто попытался как-то привлечь внимание к собственной разработке и выбрал темный путь: засрать популярную в js мире библиотеку, чтобы у огромной аудитории бомбануло и она пошла в комменты. И как побочный эффект — эта аудитория всё-таки узнает о Binding.scala.
Касательно самой статьи уже всё в общем-то написали. Повсеместное манипулирование фактами, умалчивание очевидных вещей и указания на сильные стороны Binding.scala.
Представленные библиотеки и React подходят к изменению DOM с разных сторон.
В реакте при изменении состояния приложения делается новый рендер в память, потом делается дифф со старым рендером, в результате которого получаем некий набор действий, как получить из старого дома новый. И накладываем эти действия на реальный дом.
В реактивных библиотеках совсем другой подход. Там есть реактивные потоки, которые как-то забиндены на некоторые участки дом. Если прилетело новое значение в поток (изменился Var), то элемент дома просто заново отрисуетсяи вставится.
Не охота разводить холивар, но эти подходы очень разные. И на текущий момент react-like библиотек на pure scala просто нет. Единственный вариант — делать обертки над react или react-like библиотеками.
Дело не в scalatags, а в обертке над scalatags с этими ^ < --> символами. Сам scalatags читается очень легко и просто. А вот scalatags в scala-js-react — тот еще адок. Почти все, с кем я общался по поводу scala-js при виде такого синтаксиса приходят в ужас.
Однако, в scala-js-react можно не использовать такой синтаксис, а использовать стандартный scalatags синтаксис. Я бы порекомендовал для вводной статьи использовать именно его, дабы не распугивать людей.
Не скомпилируется. for-comprehension всегда требует что-то возвращать в левую часть стрелки. Если возвращать нечего — то используется запись _ <- blabla
Да, при несовпадении типов дальше по коду можно выловить часть ошибок. Но если функция с сайд эффектом и ничего не возвращает, а нам нужно дождаться этого сайд эффекта, то мы просто получим race condition, если забыли await. В моем примере выше на scala.js даже функция без возвращаемого значения (isUserValidAsync) завернута в for-comprehension и явно видно, что она является частью асинхронного блока.
Если ты засунешь эти три строки в for-comprehension — то да, будет ошибка компиляции.
Насчет TypeScript — в нем нету аналога for-comprehension. То есть там будет такая же ситауция, как и в js.
Но не страшно выполнять синхронный код в асинхронном блоке, это потенциально не приведет к ошибке. Страшнее выполнить асинхронный код в синхронном блоке и забыть await. Поэтому я и утверждаю, что такое разделение — это хорошо.
Если коротко — каждый тест всё делает сам.
Но это ведь всё равно никак не связано с языком, правда? А по оригинальному сообщению прослеживается именно такая мысль.
Все версии, в которых поддерживается скала 2.12.
Спарк 2.2.0 вышел в июле 17 года. 3 года назад! То, что вы используете такие старых версии инструментов — не проблема инструментов или языка. Обновитесь уже на актуальную версию
Спарк уже сейчас работает под дотти.
Да откуда у вас это мнение? Компилятор дотти уже сейчас кросс компилирует библиотеки из скалы 2. Авторы либ уже сейчас начинают переписывать части либ, где используются макросы. К релизу это всё уже будет. Имплиситов никуда не деваются. Всё старое на месте, и будет удаляться потом, через deprecation цикл.
Так обратная совместимость есть. Почти всё, кроме макросов, будет работать.
Точно так же, как и для ооп.
Я открою вам страшный секрет — из одной и той же "архитектуры на листочке" можно сделать программу как в фп стиле, так и в ооп. Никто не проектирует "морфизмами".
А вы случаем не путаете "просто" и "знакомо"? Проектирование систем в фп стиле не означает, что система проектируется с использованием таких штук как "функтор" или "монада". Это проектирование, в котором иммутабельные данные проходят через ряд преобразований внутри функций. А функторы и монады — это уже детали реализации. Фп никаким образом не влияет на возможность людей договориться. Это просто немного другой подход. И, более того, на практике он не сильно отличается от тех же ооп best practices.
Смотрели и на Luigi и на Oozie, но они выглядят почти такими же. Не хочется менять шило на мыло.
Мы используем у себя AirFlow для запуска периодических задач. И с ним постоянно какие-то проблемы. Регулярно видим "ядерный гриб". Сабдаги просто не работают. Старые issue закрываются, новые открываются. Давно уже хотим съехать с AirFlow на какой-то другой сервис. Но вот на какой — непонятно. Может кто-то посоветует?
Я являюсь большим любителем как scala, так и scala.js. Однако считаю, что данная статья — это худшее, что можно было выбрать для перевода. Я думаю, что автор статьи просто попытался как-то привлечь внимание к собственной разработке и выбрал темный путь: засрать популярную в js мире библиотеку, чтобы у огромной аудитории бомбануло и она пошла в комменты. И как побочный эффект — эта аудитория всё-таки узнает о Binding.scala.
Касательно самой статьи уже всё в общем-то написали. Повсеместное манипулирование фактами, умалчивание очевидных вещей и указания на сильные стороны Binding.scala.
Ну ё моё, опять шрифты. После 2016.1 я уж надеялся, что история с шрифтами в линуксе закончена, но нет :)
У меня сломались шрифты в редакторе. Система linux.
Ну да, статья от создателя либы несомненный пруф ;)
Представленные библиотеки и React подходят к изменению DOM с разных сторон.
В реакте при изменении состояния приложения делается новый рендер в память, потом делается дифф со старым рендером, в результате которого получаем некий набор действий, как получить из старого дома новый. И накладываем эти действия на реальный дом.
В реактивных библиотеках совсем другой подход. Там есть реактивные потоки, которые как-то забиндены на некоторые участки дом. Если прилетело новое значение в поток (изменился Var), то элемент дома просто заново отрисуетсяи вставится.
Не охота разводить холивар, но эти подходы очень разные. И на текущий момент react-like библиотек на pure scala просто нет. Единственный вариант — делать обертки над react или react-like библиотеками.
Дело не в scalatags, а в обертке над scalatags с этими ^ < --> символами. Сам scalatags читается очень легко и просто. А вот scalatags в scala-js-react — тот еще адок. Почти все, с кем я общался по поводу scala-js при виде такого синтаксиса приходят в ужас.
Однако, в scala-js-react можно не использовать такой синтаксис, а использовать стандартный scalatags синтаксис. Я бы порекомендовал для вводной статьи использовать именно его, дабы не распугивать людей.
Не скомпилируется. for-comprehension всегда требует что-то возвращать в левую часть стрелки. Если возвращать нечего — то используется запись
_ <- blablaДа, при несовпадении типов дальше по коду можно выловить часть ошибок. Но если функция с сайд эффектом и ничего не возвращает, а нам нужно дождаться этого сайд эффекта, то мы просто получим race condition, если забыли await. В моем примере выше на scala.js даже функция без возвращаемого значения (
isUserValidAsync) завернута в for-comprehension и явно видно, что она является частью асинхронного блока.Если ты засунешь эти три строки в for-comprehension — то да, будет ошибка компиляции.
Насчет TypeScript — в нем нету аналога for-comprehension. То есть там будет такая же ситауция, как и в js.
Можно. Примерно так:
Но не страшно выполнять синхронный код в асинхронном блоке, это потенциально не приведет к ошибке. Страшнее выполнить асинхронный код в синхронном блоке и забыть await. Поэтому я и утверждаю, что такое разделение — это хорошо.