Elm 프로그래밍 언어 시작하기

매우 흥미롭고 혁신적인 프로젝트의 수석 개발자가 AngularJS에서 Elm으로의 전환을 제안했을 때 내 첫 생각은: 왜?

우리는 이미 견고하게 잘 작성된 AngularJS 애플리케이션을 가지고 있었고, 잘 테스트되었으며 프로덕션 환경에서 입증되었습니다. 그리고 AngularJS에서 가치 있는 업그레이드인 Angular 4는 재작성을 위한 자연스러운 선택일 수 있었습니다. 따라서 React나 Vue도 마찬가지입니다. 느릅나무는 사람들이 거의 들어본 적이 없는 이상한 도메인 특정 언어처럼 보였습니다.

글쎄, 그것은 내가 Elm에 대해 아무것도 알기 전이었습니다. 이제, 특히 AngularJS에서 AngularJS로 전환한 후 약간의 경험을 통해 "이유"에 대한 답을 줄 수 있을 것 같습니다.

이 기사에서는 Elm의 장단점과 Elm의 이국적인 개념 중 일부가 프론트엔드 웹 개발자의 요구에 완벽하게 부합하는 방법을 살펴보겠습니다. 좀 더 튜토리얼 같은 Elm 언어 기사를 보려면 이 블로그 게시물을 살펴보세요.

Elm: 순전히 기능적인 프로그래밍 언어

Java 또는 JavaScript로 프로그래밍하는 데 익숙하고 이것이 코드 작성의 자연스러운 방법이라고 느낀다면 Elm을 배우는 것은 토끼굴에 빠지는 것과 같을 수 있습니다.

가장 먼저 눈에 띄는 것은 이상한 구문입니다. 중괄호가 없고 많은 화살표와 삼각형이 있습니다.

중괄호 없이 사는 법을 배울 수 있지만 코드 블록을 어떻게 정의하고 중첩합니까? 또는 그 문제에 대한 for 루프 또는 다른 루프는 어디에 있습니까? 명시적 범위는 let 블록으로 정의할 수 있지만 고전적인 의미에서 블록이 없고 루프가 전혀 없습니다.

Elm은 순전히 기능적이고 강력한 유형의 반응형 이벤트 기반 웹 클라이언트 언어입니다.

이런 식으로 프로그래밍이 가능한지 궁금할 수도 있습니다.

실제로 이러한 자질은 프로그래밍 및 좋은 소프트웨어 개발의 놀라운 패러다임을 제공하기 위해 합산됩니다.

순수한 기능

최신 버전의 Java 또는 ECMAScript 6을 사용하여 함수형 프로그래밍을 수행할 수 있다고 생각할 수 있습니다. 그러나 그것은 단지 표면적일 뿐입니다.

이러한 프로그래밍 언어에서는 여전히 언어 구성의 무기고에 액세스할 수 있으며 기능하지 않는 부분에 의존하려는 유혹이 있습니다. 차이점을 실제로 알아차리는 경우는 함수형 프로그래밍 외에는 아무것도 할 수 없을 때입니다. 그 지점에서 결국 함수형 프로그래밍이 얼마나 자연스러운지 느끼기 시작합니다.

Elm에서는 거의 모든 것이 함수입니다. 레코드 이름은 함수이고 공용체 유형 값은 함수입니다. 모든 함수는 인수에 부분적으로 적용된 함수로 구성됩니다. 더하기(+), 빼기(-) 같은 연산자도 함수입니다.

프로그래밍 언어를 순전히 기능적인 것으로 선언하려면 그러한 구성의 존재보다 다른 모든 것이 없는 것이 가장 중요합니다. 그래야만 순전히 기능적인 방식으로 사고를 시작할 수 있습니다.

Elm은 함수형 프로그래밍의 성숙한 개념을 모델로 하며 Haskell 및 OCaml과 같은 다른 함수형 언어와 유사합니다.

강력한 형식

Java 또는 TypeScript로 프로그래밍하는 경우 이것이 무엇을 의미하는지 알 것입니다. 모든 변수에는 정확히 하나의 유형이 있어야 합니다.

물론 약간의 차이점은 존재합니다. TypeScript와 마찬가지로 유형 선언은 선택 사항입니다. 존재하지 않으면 유추됩니다. 그러나 "아무" 유형은 없습니다.

Java는 일반 유형을 지원하지만 더 나은 방법입니다. Java의 제네릭은 나중에 추가되었으므로 달리 지정하지 않는 한 유형은 제네릭이 아닙니다. 그리고 그것들을 사용하려면 못생긴 <> 구문이 필요합니다.

Elm에서 유형은 달리 지정되지 않는 한 제네릭입니다. 예를 들어 보겠습니다. 특정 유형의 목록을 가져와 숫자를 반환하는 메서드가 필요하다고 가정합니다. Java에서는 다음과 같습니다.

 public static <T> int numFromList(List<T> list){ return list.size(); }

그리고 Elm 언어로:

 numFromList list = List.length list

선택 사항이지만 항상 유형 선언을 추가하는 것이 좋습니다. Elm 컴파일러는 잘못된 유형에 대한 작업을 허용하지 않습니다. 인간의 경우, 특히 언어를 배우는 동안 그러한 실수를 하는 것이 훨씬 쉽습니다. 따라서 유형 주석이 있는 위의 프로그램은 다음과 같습니다.

 numFromList: List a -> Int numFromList list = List.length list

별도의 줄에 유형을 선언하는 것이 처음에는 이상하게 보일 수 있지만 시간이 지나면 자연스럽게 보이기 시작합니다.

웹 클라이언트 언어

이것이 의미하는 바는 Elm이 JavaScript로 컴파일되어 브라우저가 웹 페이지에서 실행할 수 있다는 것입니다.

이를 감안할 때 Node.js가 포함된 Java 또는 JavaScript와 같은 범용 언어가 아니라 웹 애플리케이션의 클라이언트 부분을 작성하기 위한 도메인 특정 언어입니다. 게다가 Elm에는 비즈니스 로직(JavaScript가 하는 일)과 프레젠테이션 부분(HTML이 하는 일)을 모두 하나의 기능 언어로 작성하는 것이 포함되어 있습니다.

이 모든 것은 Elm Architecture라고 하는 매우 특정한 프레임워크와 같은 방식으로 수행됩니다.

반응성

Elm Architecture는 반응형 웹 프레임워크입니다. 모델의 모든 변경 사항은 명시적인 DOM 조작 없이 페이지에서 즉시 렌더링됩니다.

그런 면에서 Angular나 React와 비슷합니다. 그러나 Elm은 자체 방식으로도 수행합니다. 기본을 이해하는 열쇠는 view 및 update 함수의 서명에 있습니다.

 view : Model -> Html Msg update : Msg -> Model -> Model

Elm 보기는 모델의 HTML 보기가 아닙니다. Msg 종류의 메시지를 생성할 수 있는 HTML입니다. 여기서 Msg 는 사용자가 정의한 정확한 공용체 유형입니다.

모든 표준 페이지 이벤트는 메시지를 생성할 수 있습니다. 그리고 메시지가 생성되면 Elm은 해당 메시지로 내부적으로 업데이트 함수를 호출하고, 이 함수는 메시지와 현재 모델을 기반으로 모델을 업데이트하고 업데이트된 모델은 다시 내부적으로 뷰에 렌더링됩니다.

이벤트 기반

JavaScript와 마찬가지로 Elm은 이벤트 기반입니다. 그러나 예를 들어 비동기 작업에 개별 콜백이 제공되는 Node.js와 달리 Elm 이벤트는 하나의 메시지 유형으로 정의된 개별 메시지 세트로 그룹화됩니다. 그리고 모든 공용체 유형과 마찬가지로 별도의 유형 값이 전달하는 정보는 무엇이든 될 수 있습니다.

메시지를 생성할 수 있는 이벤트의 세 가지 소스가 있습니다. Html 보기의 사용자 작업, 명령 실행 및 구독한 외부 이벤트입니다. 이것이 Html , Cmd 및 Sub 의 세 가지 유형 모두가 msg 를 인수로 포함하는 이유입니다. 그리고 일반 msg 유형은 모든 메시지 처리가 중앙 집중화되는 업데이트 기능(이전 예에서는 대문자 M이 있는 Msg 유형)에 제공된 것과 동일한 세 가지 정의에서 모두 동일해야 합니다.

실제 예제의 소스 코드

이 GitHub 리포지토리에서 전체 Elm 웹 애플리케이션 예제를 찾을 수 있습니다. 단순하지만 일상적인 클라이언트 프로그래밍에서 사용되는 대부분의 기능을 보여줍니다. REST 끝점에서 데이터 검색, JSON 데이터 디코딩 및 인코딩, 보기, 메시지 및 기타 구조 사용, JavaScript와 통신, 컴파일 및 패키지에 필요한 모든 것 Webpack을 사용한 느릅나무 코드.

응용 프로그램은 서버에서 검색된 사용자 목록을 표시합니다.

더 쉬운 설정/데모 프로세스를 위해 Webpack의 개발 서버는 Elm을 포함한 모든 것을 패키징하고 사용자 목록을 제공하는 데 사용됩니다.

일부 기능은 Elm에 있고 일부는 JavaScript에 있습니다. 이것은 한 가지 중요한 이유 때문에 의도적으로 수행됩니다. 상호 운용성을 보여주기 위함입니다. Elm을 시작하거나 점진적으로 기존 JavaScript 코드를 Elm으로 전환하거나 Elm 언어에 새로운 기능을 추가하려고 할 수 있습니다. 상호 운용성을 통해 앱은 Elm 및 JavaScript 코드 모두에서 계속 작동합니다. 이것은 Elm에서 전체 앱을 처음부터 시작하는 것보다 아마도 더 나은 접근 방식일 것입니다.

예제 코드의 Elm 부분은 먼저 JavaScript의 구성 데이터로 초기화된 다음 사용자 목록이 검색되어 Elm 언어로 표시됩니다. JavaScript로 이미 구현된 사용자 작업이 있다고 가정해 보겠습니다. 따라서 Elm에서 사용자 작업을 호출하면 호출이 다시 전달됩니다.

이 코드는 또한 다음 섹션에서 설명하는 몇 가지 개념과 기술을 사용합니다.

느릅나무 개념의 적용

실제 시나리오에서 Elm 프로그래밍 언어의 이국적인 개념을 살펴보겠습니다.

유니온 타입

이것은 느릅나무 언어의 순금입니다. 동일한 알고리즘으로 구조적으로 다른 데이터를 사용해야 했던 모든 상황을 기억하십니까? 이러한 상황을 모델링하는 것은 항상 어렵습니다.

다음은 예입니다. 목록에 대한 페이지 매김을 생성한다고 상상해 보십시오. 각 페이지의 끝에는 이전, 다음 및 모든 페이지에 대한 링크가 번호별로 있어야 합니다. 사용자가 클릭한 링크의 정보를 보유하도록 구성하는 방법은 무엇입니까?

이전, 다음 및 페이지 번호 클릭에 대해 여러 콜백을 사용하거나 하나 또는 두 개의 부울 필드를 사용하여 클릭된 항목을 나타내거나 음수, 0 등과 같은 특정 정수 값에 특별한 의미를 부여할 수 있습니다. 이러한 솔루션은 이러한 종류의 사용자 이벤트를 정확히 모델링할 수 있습니다.

Elm에서는 매우 간단합니다. 우리는 공용체 유형을 정의할 것입니다:

 type NextPage = Prev | Next | ExactPage Int

그리고 우리는 그것을 메시지 중 하나에 대한 매개변수로 사용합니다:

 type Msg = ... | ChangePage NextPage

마지막으로 nextPage 유형을 확인하는 case 를 갖도록 함수를 업데이트합니다.

 update msg model = case msg of ChangePage nextPage -> case nextPage of Prev -> ... Next -> ... ExactPage newPage -> ...

그것은 물건을 매우 우아하게 만듭니다.

<| 를 사용하여 여러 맵 함수 만들기

많은 모듈에는 다양한 인수에 적용할 여러 변형이 있는 map 기능이 포함되어 있습니다. 예를 들어 List 에는 map , map2 , … , 최대 map5 가 있습니다. 그러나 6개의 인수를 취하는 함수가 있다면 어떻게 될까요? 지도6이 map6 . 그러나 그것을 극복하는 기술이 있습니다. <| 매개변수로 기능하고 일부 인수가 중간 결과로 적용된 부분 기능.

간단하게 하기 위해 List 에 map 과 map2 만 있다고 가정하고 3개의 목록에 3개의 인수를 취하는 함수를 적용하려고 합니다.

구현 방식은 다음과 같습니다.

 map3 foo list1 list2 list3 = let partialResult = List.map2 foo list1 list2 in List.map2 (<|) partialResult list3

다음과 같이 정의된 숫자 인수를 곱하는 foo 를 사용한다고 가정합니다.

 foo abc = a * b * c

따라서 map3 foo [1,2,3,4,5] [1,2,3,4,5] [1,2,3,4,5] 의 결과는 [1,8,27,64,125] : List number .

여기서 무슨 일이 일어나고 있는지 분해해 봅시다.

먼저 partialResult = List.map2 foo list1 list2 에서 foo 는 list1 과 list2 의 모든 쌍에 부분적으로 적용됩니다. 결과는 [foo 1 1, foo 2 2, foo 3 3, foo 4 4, foo 5 5] 이며, 하나의 매개변수(처음 두 개는 이미 적용됨)를 취하고 숫자를 반환하는 함수 목록입니다.

다음 List.map2 (<|) partialResult list3 에서 실제로 List.map2 (<|) [foo 1 1, foo 2 2, foo 3 3, foo 4 4, foo 5 5] list3 입니다. 이 두 목록의 모든 쌍에 대해 (<|) 함수를 호출합니다. 예를 들어, 첫 번째 쌍의 경우 foo 1 1 <| 1 과 동일한 (<|) (foo 1 1) 1 입니다. foo 1 1 <| 1 을 생성하는 foo 1 1 1 1 동일합니다. 두 번째 경우에는 (<|) (foo 2 2) 2 , foo 2 2 2 , 8 로 평가되는 식입니다.

이 메서드는 map8 Json.Decode 제공하므로 많은 필드가 있는 JSON 객체를 디코딩하기 위한 mapN 함수에서 특히 유용할 수 있습니다.

아마도 목록에서 모든 없음 값 제거

Maybe 값 목록이 있고 이 목록이 있는 요소에서 값만 추출하려고 한다고 가정해 보겠습니다. 예를 들어 목록은 다음과 같습니다.

 list : List (Maybe Int) list = [ Just 1, Nothing, Just 3, Nothing, Nothing, Just 6, Just 7 ]

그리고 [1,3,6,7] : List Int 를 얻고 싶습니다. 해결책은 다음과 같은 한 줄 표현식입니다.

 List.filterMap identity list

이것이 작동하는 이유를 살펴보겠습니다.

List.filterMap 은 첫 번째 인수가 함수 (a -> Maybe b) 일 것으로 예상하고, 이는 제공된 목록의 요소(두 번째 인수)에 적용되며 결과 목록은 모든 Nothing 값을 생략하도록 필터링된 다음 실제 값은 Maybe s에서 추출됩니다.

우리의 경우에는 identity 를 제공했기 때문에 결과 목록은 다시 [ Just 1, Nothing, Just 3, Nothing, Nothing, Just 6, Just 7 ] 입니다. 필터링한 후 [ Just 1, Just 3, Just 6, Just 7 ] 을 얻고, 값 추출 후 원하는 대로 [1,3,6,7] 입니다.

커스텀 JSON 디코딩

JSON 디코딩(또는 역직렬화)에 대한 요구 사항이 Json.Decode 모듈에 노출된 것보다 많아지기 시작하면 새로운 이국적인 디코더를 만드는 데 문제가 발생할 수 있습니다. 이는 이러한 디코더가 디코딩 프로세스의 중간(예: Http 메서드 내)에서 호출되고 특히 제공된 JSON에 많은 필드가 있는 경우 입력 및 출력이 무엇인지 항상 명확하지 않기 때문입니다.

다음은 그러한 경우를 처리하는 방법을 보여주는 두 가지 예입니다.

첫 번째 필드에는 수신 JSON에 직사각형 영역의 측면을 나타내는 a 및 b 라는 두 개의 필드가 있습니다. 그러나 Elm 개체에서는 해당 영역만 저장하려고 합니다.

 import Json.Decode exposing (..) areaDecoder = map2 (*) (field "a" int) (field "b" int) result = decodeString areaDecoder """{ "a":7,"b":4 }""" -- Ok 28 : Result.Result String Int

필드는 field int 디코더로 개별적으로 디코딩된 다음 두 값 모두 map2 에서 제공된 함수에 제공됩니다. 곱셈( * )도 함수이고 두 개의 매개변수를 취하므로 그대로 사용할 수 있습니다. 결과 areaDecoder 는 적용될 때 함수의 결과를 반환하는 디코더입니다(이 경우 a*b ).

두 번째 예에서는 null이거나 비어 있는 모든 문자열이 될 수 있는 지저분한 상태 필드를 가져오지만 "OK"인 경우에만 작업이 성공했음을 알 수 있습니다. 이 경우 True 로 저장하고 다른 모든 경우에는 False 로 저장하려고 합니다. 디코더는 다음과 같습니다.

 okDecoder = nullable string |> andThen (\ms -> case ms of Nothing -> succeed False Just s -> if s == "OK" then succeed True else succeed False )

일부 JSON에 적용해 보겠습니다.

 decodeString (field "status" okDecoder) """{ "a":7, "status":"OK" }""" -- Ok True decodeString (field "status" okDecoder) """{ "a":7, "status":"NOK" }""" -- Ok False decodeString (field "status" okDecoder) """{ "a":7, "status":null }""" -- Ok False

여기서 핵심은 andThen 에 제공된 함수에 있습니다. 이 함수는 이전의 nullable 문자열 디코더( Maybe String )의 결과를 가져와 우리가 필요로 하는 모든 것으로 변환하고 succeed 의 도움으로 디코더로 결과를 반환합니다.

주요 요점

이러한 예에서 볼 수 있듯이 기능적 방식으로 프로그래밍하는 것은 Java 및 JavaScript 개발자에게 매우 직관적이지 않을 수 있습니다. 많은 시행착오를 거쳐 익숙해지려면 시간이 좀 걸립니다. 이해를 돕기 위해 elm-repl 을 사용하여 표현식의 반환 유형을 연습하고 확인할 수 있습니다.

이 기사의 앞부분에 링크된 예제 프로젝트에는 이해하는 데 도움이 될 수 있는 사용자 지정 디코더 및 인코더의 몇 가지 추가 예제가 포함되어 있습니다.

그럼에도 불구하고 왜 느릅 나무를 선택합니까?

다른 클라이언트 프레임워크와 매우 다르기 때문에 Elm 언어는 확실히 "또 다른 JavaScript 라이브러리"가 아닙니다. 이처럼, 그것에 비해 긍정적 또는 부정적으로 간주될 수 있는 많은 특성을 가지고 있습니다.

먼저 긍정적인 측면부터 시작하겠습니다.

HTML과 JavaScript를 사용하지 않는 클라이언트 프로그래밍

마지막으로, 모든 것을 할 수 있는 언어가 있습니다. 더 이상 분리가 없고 어색한 조합이 혼합됩니다. JavaScript에서 HTML을 생성하지 않으며 일부 제거된 논리 규칙이 있는 사용자 정의 템플릿 언어가 없습니다.

Elm을 사용하면 단 하나의 구문과 하나의 언어를 완벽하게 사용할 수 있습니다.

일률

거의 모든 개념이 기능과 몇 가지 구조를 기반으로 하기 때문에 구문이 매우 간결합니다. 어떤 메서드가 인스턴스나 클래스 수준에서 정의되어 있는지, 아니면 그냥 함수인지 걱정할 필요가 없습니다. 그것들은 모두 모듈 수준에서 정의된 기능입니다. 그리고 목록을 반복하는 방법은 수백 가지가 아닙니다.

대부분의 언어에는 코드가 언어 방식으로 작성되었는지 여부에 대한 논쟁이 항상 있습니다. 많은 관용구를 숙달해야 합니다.

Elm에서 컴파일되면 아마도 "Elm" 방식일 것입니다. 그렇지 않다면 확실히 그렇지 않습니다.

표현력

Elm 구문은 간결하지만 표현력이 뛰어납니다.

이것은 주로 공용체 유형, 형식적 유형 선언 및 기능적 스타일을 사용하여 달성됩니다. 이 모든 것이 더 작은 기능을 사용하도록 영감을 줍니다. 결국 거의 자체 문서화되는 코드를 얻게 됩니다.

Null 없음

Java 또는 JavaScript를 아주 오랫동안 사용하면 null 이 프로그래밍에서 피할 수 없는 부분인 완전히 자연스러운 것이 됩니다. 그리고 NullPointerException 및 다양한 TypeError 를 지속적으로 보고 있지만 실제 문제는 null 의 존재라고 생각하지 않습니다. 너무 자연스럽 습니다.

느릅나무와 함께 시간이 지나면 금세 명확해집니다. null 이 없으면 런타임 null 참조 오류를 계속해서 볼 수 있을 뿐만 아니라 실제 값이 없을 수 있는 모든 상황을 명확하게 정의하고 처리하여 더 나은 코드를 작성하는 데 도움이 됩니다. 따라서 null 을 연기하지 않음으로써 기술적 부채를 줄일 수 있습니다. 고장날 때까지 처리합니다.

작동할 것이라는 확신

구문적으로 올바른 JavaScript 프로그램을 매우 빠르게 만들 수 있습니다. 하지만 실제로 효과가 있을까요? 자, 페이지를 새로고침하고 철저히 테스트한 후 봅시다.

Elm은 그 반대입니다. 정적 유형 검사와 강제 null 검사를 사용하면 특히 초보자가 프로그램을 작성할 때 컴파일하는 데 약간의 시간이 필요합니다. 그러나 일단 컴파일되면 올바르게 작동할 가능성이 높습니다.

빠른

이것은 클라이언트 프레임워크를 선택할 때 중요한 요소가 될 수 있습니다. 광범위한 웹 앱의 응답성은 종종 사용자 경험과 전체 제품의 성공에 매우 중요합니다. 그리고 테스트에서 알 수 있듯이 Elm은 매우 빠릅니다.

Elm과 기존 프레임워크의 장점

대부분의 기존 웹 프레임워크는 웹 앱 생성을 위한 강력한 도구를 제공합니다. 그러나 그 힘에는 대가가 따릅니다. 즉, 사용 방법과 시기에 대한 다양한 개념과 규칙이 있는 지나치게 복잡한 아키텍처입니다. 모든 것을 마스터하려면 많은 시간이 걸립니다. 컨트롤러, 구성 요소 및 지시문이 있습니다. 그런 다음 컴파일 및 구성 단계와 실행 단계가 있습니다. 그리고 제공된 지시문에 사용되는 서비스, 팩토리 및 모든 사용자 정의 템플릿 언어가 있습니다. 페이지를 새로 고치기 위해 $scope.$apply() 를 직접 호출해야 하는 모든 상황 등이 있습니다.

JavaScript로 Elm을 컴파일하는 것도 확실히 매우 복잡하지만 개발자는 모든 기본 사항을 알 필요가 없습니다. Elm을 작성하고 컴파일러가 작업을 수행하도록 하십시오.

그리고 왜 느릅나무를 선택하지 않습니까?

느릅나무 찬양으로 충분합니다. 이제 그다지 좋지 않은 측면을 살펴보겠습니다.

선적 서류 비치

이것은 정말 중요한 문제입니다. Elm 언어에는 자세한 설명서가 없습니다.

공식 튜토리얼은 언어를 훑어보고 답이 없는 질문을 많이 남깁니다.

공식 API 참조는 훨씬 더 나쁩니다. 많은 기능이 설명이나 예제가 부족합니다. 그리고 다음과 같은 문장이 있는 것이 있습니다. “이것이 혼란스럽다면 Elm Architecture Tutorial을 통해 작업하십시오. 정말 도움이 됩니다!” 공식 API 문서에서 보고 싶은 가장 큰 줄이 아닙니다.

바라건대 이것은 곧 바뀔 것입니다.

나는 Elm이 그러한 열악한 문서, 특히 그러한 개념과 기능이 전혀 직관적이지 않은 Java 또는 JavaScript에서 온 사람들에게 널리 채택될 수 있다고 생각하지 않습니다. 그것들을 이해하려면 많은 예제가 포함된 훨씬 더 나은 문서가 필요합니다.

형식 및 공백

중괄호나 괄호를 없애고 들여쓰기에 공백을 사용하면 보기 좋을 수 있습니다. 예를 들어, Python 코드는 매우 깔끔해 보입니다. 그러나 elm-format 의 제작자에게는 충분하지 않았습니다.

모든 이중 행 공간과 표현식 및 할당이 여러 행으로 분할되므로 Elm 코드는 수평보다 수직으로 보입니다. 오래된 C에서 한 줄짜리가 Elm 언어에서는 두 개 이상의 화면으로 쉽게 확장될 수 있습니다.

작성된 코드 줄로 비용을 지불하는 경우 좋은 소리가 들릴 수 있습니다. 그러나 150줄 더 일찍 시작된 표현식으로 무언가를 정렬하려면 올바른 들여쓰기를 찾는 행운을 빕니다.

기록 처리

그들과 함께 일하는 것은 어렵습니다. 레코드의 필드를 수정하는 구문은 보기 흉합니다. 중첩된 필드를 수정하거나 임의로 필드를 이름으로 참조하는 쉬운 방법은 없습니다. 그리고 일반적인 방식으로 접근자 기능을 사용하는 경우 올바른 입력에 많은 문제가 있습니다.

JavaScript에서 레코드 또는 객체는 다양한 방식으로 구성, 액세스 및 수정할 수 있는 중심 구조입니다. JSON조차도 일련의 레코드 버전일 뿐입니다. 개발자는 웹 프로그래밍에서 레코드 작업에 익숙하므로 Elm에서 레코드를 처리하는 데 어려움이 있으면 기본 데이터 구조로 사용하는 경우 눈에 띄게 될 수 있습니다.

더 많은 타이핑

Elm은 JavaScript보다 더 많은 코드를 작성해야 합니다.

문자열 및 숫자 연산에 대한 암시적 유형 변환이 없으므로 많은 int-float 변환, 특히 toString 호출이 필요하며, 올바른 인수 수와 일치하려면 괄호 또는 함수 응용 프로그램 기호가 필요합니다. 또한 Html.text 함수에는 문자열이 인수로 필요합니다. 모든 Maybe s, Results , 유형 등에 대해 많은 경우 식이 필요합니다.

이에 대한 주된 이유는 엄격한 유형 시스템이며 이는 지불해야 하는 공정한 가격일 수 있습니다.

JSON 디코더 및 인코더

더 많은 입력이 실제로 눈에 띄는 한 영역은 JSON 처리입니다. JavaScript에서 단순히 JSON.parse() 호출은 Elm 언어에서 수백 줄에 걸쳐 있을 수 있습니다.

물론 JSON과 Elm 구조 간에 일종의 매핑이 필요합니다. 그러나 동일한 JSON 조각에 대해 디코더와 인코더를 모두 작성해야 하는 필요성은 심각한 문제입니다. REST API가 수백 개의 필드가 있는 개체를 전송하는 경우 많은 작업이 필요합니다.

마무리

우리는 Elm에 대해 보았고 프로그래밍 언어 자체만큼이나 오래된 잘 알려진 질문에 답할 때입니다. 경쟁 제품보다 낫습니까? 우리 프로젝트에서 사용해야합니까?

모든 도구가 망치가 아니고 모든 것이 못이 아니기 때문에 첫 번째 질문에 대한 대답은 주관적일 수 있습니다. Elm은 많은 경우 다른 웹 클라이언트 프레임워크보다 빛나고 더 나은 선택이 될 수 있지만 다른 경우에는 부족합니다. 그러나 웹 프런트 엔드 개발을 다른 대안보다 훨씬 안전하고 쉽게 만들 수 있는 정말 독특한 가치를 제공합니다.

두 번째 질문에 대해 오래된 "그것은 다릅니다"로 대답하는 것을 피하기 위해 간단한 대답은 다음과 같습니다. 예. 언급된 모든 단점에도 불구하고 Elm이 프로그램이 정확하다는 확신만으로도 Elm을 사용할 이유가 충분합니다.

Elm으로 코딩하는 것도 재미있습니다. "전통적인" 웹 프로그래밍 패러다임에 익숙한 사람에게는 완전히 새로운 관점입니다.

실제 사용에서는 전체 앱을 즉시 Elm으로 전환하거나 새 앱을 완전히 시작할 필요가 없습니다. Elm 언어로 작성된 인터페이스 또는 일부 기능으로 시작하여 JavaScript와의 상호 운용성을 활용하여 시도해 볼 수 있습니다. 귀하의 요구 사항에 맞는지 빠르게 확인한 다음 사용 범위를 넓히거나 그대로 두십시오. 그리고 기능적 웹 프로그래밍의 세계와 사랑에 빠질 수도 있습니다.