Два года назад компания, в которой я работал, попросила меня изучить Elm - функциональный интерфейсный язык программирования. Мне показался странным синтаксис и сложная парадигма функционального программирования. В итоге мы перешли на другие интерфейсные фреймворки и в конце концов почти забыли об Elm.
Недавно я провел урок по Redux, и мои ученики немного спросили меня об Elm. Это побудило меня подумать об Эльме и посмотреть, смогу ли я сейчас, спустя два года моей карьеры программиста, встать на свои места, и я смогу это понять.
Процесс обучения
Решил начать с документации. Elm довольно хорошо известен своей документацией, и многие технологии с более высокими барьерами для входа должны это делать, чтобы люди использовали их инструменты. Я начал с нуля с учебника на их веб-сайте и быстро перешел к более стандартным частям языка. Было несколько интересных синтаксических вариантов - например, конвейеры для изменения атрибутов записи. Мне также показалось интересным, что их стандартная коллекция представляет собой связанный список, а не массив. В некотором смысле это имеет смысл с языком интерфейса пользователя; однако это сделало мой последний проект более сложным!
Оттуда я перешел к части учебника «Архитектура вяза». Мне показалось, что в этой части он очень быстро прыгнул с 0 до 100. Я определенно немного заблудился здесь. Однако в целом шаблон проектирования модели, обновления, просмотра и подписок имел смысл. Мне нравится знать, где все находится.
В процессе обучения я постоянно возвращался к образцу кода в elm-architecture-tutorial.
К другим действительно приятным функциям относятся сообщения об ошибках и путешествия во времени. В процессе компиляции Elm следит за тем, чтобы не было ошибок во время выполнения. Этот процесс означает, что перед запуском кода у вас будут действительно четкие и четкие сообщения об ошибках. Мне также очень нравится функция «путешествия во времени», когда вы можете видеть состояние вашего приложения в различных точках. Эти части опыта разработки великолепны, и я могу понять, почему другие инструменты (такие как Redux) построены на этих идеях.
После просмотра части учебника Архитектура Вяза я смог шаг за шагом пройтись по коду, но мне все еще очень трудно было написать свой собственный код Вяза с нуля. В итоге я просмотрел некоторые другие проекты, которые нашел на Github, такие как Flatris и Elm Hanoi. Оттуда я нашел учебник по Elm Tensor Programming, который мне очень помог. Мне очень нравится последовательный стиль обучения, поэтому этот урок был действительно полезен для этого.
Финальный проект
Изначально я хотел построить Towers of Hanoi в Elm, так как это довольно простая для написания игра на JavaScript; тем не менее, я обнаружил, что это все еще немного не в моей лиге в Вязах. Вместо этого я уменьшил масштаб и написал приложение для мелочей, которое все еще было довольно сложным.
В итоге я использовал create-elm-app, который очень похож на create-react-app. Это было очень полезно как для разработки, так и для развертывания. Мне оставалось еще кое-что выяснить в моем коде. Во-первых, проблема связанного списка и массива. В итоге я использовал связанный список и перебирал его, чтобы получить разные вопросы. На других языках я бы сохранил значение индекса и использовал бы его для перехода от вопроса к вопросу. В Elm архитектура программы была немного другой.
Мне также было трудно работать с «возможными вещами». Maybes - это тип данных в Elm, похожий на строку, целое число или список, который может иметь значение «Nothing» - аналогично null или None в других языках - или иметь значение. Чтобы работать с ценностью, если она существует, вы должны убрать ее из «может быть». Это имеет смысл со строго типизированной точки зрения и с функциональной точки зрения, но делает код несколько неуклюжим.
В конце концов, я придумал приложение MVP-викторины, которое задает вопросы, позволяет пользователям нажимать кнопки с разными ответами, а затем отслеживает, на сколько вопросов были даны правильные ответы. Развернуть приложение оказалось довольно просто - мне просто нужно было запустить elm-make и поместить подкаталог сборки в ветку gh-pages моего удаленного репозитория. Код находится здесь, а приложение развертывается здесь.
Что будет дальше
Оказывается, Эльму не стало намного легче за последние несколько лет - Эльм все еще был совершенно другим способом мышления. Несмотря на то, что я создал MVP, добиться его было в 100 раз сложнее, чем если бы я построил его на языке, который мне удобнее. Шаблоны проектирования по-прежнему оставались сложными, и работа с данными казалась намного более сложной, чем следовало бы. Я по-прежнему не стал бы использовать Elm, хотя вижу в нем некоторые преимущества - например, статическую типизацию и сложный отлов ошибок. Если бы мне пришлось использовать функциональное программирование во внешнем интерфейсе, я бы предпочел использовать React и Redux, поскольку они оба все еще находятся в JavaScript. В целом, я думаю, что Elm - хорошая идея, но некоторые синтаксис и реализация все еще немного нестабильны.
