세미콜론 없는 언어, 과연 좋은 선택일까?

토론에서는 JavaScript의 자동 세미콜론 삽입(Automatic Semicolon Insertion, ASI)이 복잡하고 예측하기 어렵다는 점을 지적한다. 특히, 문법 오류 발생 시 ASI가 의도치 않은 방식으로 동작하여 오류를 은폐(Masking Errors)하는 경우가 많다고 비판한다. MDN 문서(MDN Article)를 인용하며, ASI로 인해 발생하는 문제점과 해결책을 제시하며, 명시적인 세미콜론 사용을 권장한다.

커뮤니티에서는 Haskell이 공백 기반 구문 분석(Whitespace-Sensitive Parsing)을 통해 줄 바꿈을 처리하는 방식을 언급한다. Haskell은 레이아웃 규칙(Layout Rule)을 사용하여 공백을 세미콜론과 중괄호로 변환한다. 이러한 방식은 코드의 가독성을 높이지만, 초보자에게는 학습 장벽(Learning Curve)이 될 수 있다는 의견도 제시된다. Haskell 98 보고서(Haskell 98 Report)를 통해 자세한 규칙을 확인할 수 있다.

토론에서는 Lisp이 S-표현식(S-expressions)을 사용하여 구문 문제를 근본적으로 해결한다고 언급한다. S-표현식은 괄호를 사용하여 코드의 구조를 명확하게 표현하며, 세미콜론은 주석 처리에 사용된다. 이러한 방식은 구문 분석의 단순성(Simplicity of Parsing)을 제공하지만, 괄호의 과도한 사용으로 인해 코드의 가독성이 저하될 수 있다는 의견도 존재한다. Wisp와 같은 Lisp의 다른 구문 방식도 소개된다.

Odin 언어의 설계자가 세미콜론을 선택적으로 사용하도록 한 이유가 언급된다. Odin은 Python과 Go의 접근 방식(Python and Go's Approach)을 혼합하여, 괄호, 중괄호, 대괄호 내에서는 세미콜론 삽입을 하지 않는다. 또한, 특정 코딩 스타일을 강제하기보다는 다양한 스타일을 허용하는 유연성을 제공한다. 이러한 접근 방식은 문법 일관성(Grammar Consistency)을 높이는 데 기여한다.

토론에서는 언어 설계 시 명확하고 단순한 규칙을 정의하는 것이 중요하다고 강조한다. 특히, JavaScript의 ASI와 같이 복잡한 규칙은 피해야 한다고 지적한다. 또한, 오류를 방지하기 위한 툴링(Tooling), 예를 들어 unused value에 대한 경고를 추가하는 것이 중요하다고 언급한다. 이러한 툴링은 개발자가 오류를 조기에 발견(Early Error Detection)하고, 코드의 품질을 향상시키는 데 기여한다.