• Лисп или хаскел?

    Начнём с того, что Лисп не функциональный. Тем, кто приходит в Лисп из мира императивных языков может так казаться, но я пришел в Лисп после Хаскела и я тебе точно говорю, Лисп - не функциональный.
    Теперь по теме - оба языка крайне интересны и способны взорвать мозг, но Хаскел вставляет сильнее, он действительно заумный и изобилует супер-дупер новыми изощренными технологиями программирования (Аппликативные функторы, комбинаторы, монады, ленивые вычисления), но что тебе действительно взорвёт мозг - это чистота языка (нельзя совершать побочные эффекты т.е. не напишешь в консоль где хочешь, не присвоишь значение переменной), отсутствие циклов и декларативность (ты не пишешь "как", а пишешь "что" представляет из себя задача). Но это только в начале. Когда освоишься, оказывается, что Хаскел очень выразителен и краток. Но есть у него и минусы - он очень сложен, ОЧЕНЬ. Серьезно, даже через пол года, у тебя по-прежнему будут проблемы. Уверен, 95% хаскелистов не объяснят в подробности, как работает Hello world на хаскеле, который выглядит так:
    main::IO ()
    main = do
    putStrLn "Hello world!"

    выглядит не сложно, но вот что скрывается под водой: все вычисления происходят в монаде IO т.к. только в ней разрешены побочные эффекты. Побочный эффект (действие ввода-вывода) выполняется только тогда, когда вернётся в main т.к. побочные эффекты разрешены только в main (поэтому и только в монаде IO т.к. main возвращает IO () ). Что такое IO ()? Это как бы список действий, которые туда запихиваются и объединяются в цепочку, чтобы быть последовательными (вне монады порядок выполнения твоих инструкций не определён, счастливого дебага). Эти действия на самом деле не выполняются сразу, а представляют из себя "обещание" сделать это действие, которое реализуется как только что-то уже действующее не затребует результат, в нашем случае это консоль... в общем и это только верхушка айсберга, я еще про типы не говорил, про извлечение и упаковку в монаду, про отображения множеств, карринг и тд.
    В общем хаскел это интересно, но очень сложно. Даже если не пообломаешь зубы, у тебя очень долго будут проблемы с дебагом, с пониманием всяких астральных техник, которые плодятся день и ночь, вроде стрелок или линз. Да и понять чужой код на хаскеле часто очень сложно, потому что каждый считает, что просто обязан применить все заумные штуки, которые он знает, ведь разве не для этого он учил хаскел? А ведь потом люди будут читать это...
    Теперь пара слов о Лиспе - тут у меня меньше опыта, но идея такая - это программируемый язык программирования. Кроме того, что в нём есть макросы - специальные инструменты, чтобы писать программу которая напишет программу, так и сам язык представляет из себя синтаксическое дерево в своём первозданном виде, что открывает безграничные возможности в метапрограммировании. В общем идея такая - этот язык в умелых руках становится абсолютно чем захочешь. Нравится хаскел и ФП? Отлично, сейчас реализуем. Хочешь ленивые вычисления? На! Хочешь классы? Вот! Хочешь логическое программирование? Держи! При всём этом язык крайне прост, может даже проще Си.
    Так, что я тебе посоветую? Наверное, начинай с Хаскела - он тащит за собой огромную теоретическую базу и целый арсенал таких приёмов программирования, которые тебе и не снились. Выучишь, освоишься - подумай о лиспе. Но! Тебе в любом случае нужно будет ставить Emacs - это самая лучшая среда для этих обоих языков, а Emacs конфигурируется на Emacs Lisp, так что у тебя будет возможность на него посмотреть. Посмотри видео по емаксу https://www.youtube.com/playlist?list=PLECBtie1W1t... (там и про Emacs Lisp есть глава), потом качаешь "Хаскел во имя добра" и "О хаскел по-человечески" и читаешь их параллельно - в первой хорошее мягкое введение, а во второй практика - она нужна сразу, чтобы хотябы знать, как создать проект с помощью cabal и собрать его, а то Липовача пол книги в интерпретаторе сидит.
    Ответ написан
    1 комментарий
  • Почему у React.js такая ужасная модель управления DOM? Как с этим уживаться?

    miraage
    @miraage
    Старый прогер
    refs, EventEmitter - говорят о том, что у Вас проблема с построением архитектуры приложения и непонимание dataflow в redux в целом.

    Посмотрите на одну из реализаций аудиоплееров, возможно подчерпнете что-то.

    https://github.com/andrewngu/sound-redux
    Ответ написан
    Комментировать
  • Как научиться верстать без проблем?

    za4me
    @za4me
    Человек
    Совет один. Больше практики.
    Ответ написан
    Комментировать
  • Где надо подключать connect(mapStateToProps, mapDispatchToProps)(App) для каждого компонента?

    @vsuhachev
    connect нужен для того чтобы подписать компонент на события редуцера и дать доступ к данным редуцера. А роутинг он вообще в стороне от redux (хотя, конечно, есть роутеры, работающие через redux).

    Я обычно придерживаюсь следующего: connect применяю к компонентам-контейнерам верхнего уровня, которыми управляет роутер(в вашем случае это Component-1, Component-2). Во все остальные простые (dumb) компоненты, находящиеся в контейнере, данные получают в параметрах (через props) от контейнера.

    Если вложенные компоненты должны как-то взаимодействовать с redux: для этого в компоненте-контейнере определяются функции, которые видят редуцеры и dispatch. Дальше эти функции отдаются dumb-компонентам через props и они их могут вызвать по какому-то своему событию.

    Теоретически вы можете делать connect к любому компоненту, но во первых это более накладно по ресурсам и во вторых это убивает инкапсуляцию. Прелесть т.н. "тупых" компонентов в том что они простые и зависят только от явных параметров (props) и следовательно легко переносимы. Добавляя к ним connect мы прибиваем их гвоздями к модели данных конкретного приложения.
    Ответ написан
    2 комментария