▲

언어 설계를 멈추고, 대신 라이브러리를 작성하라

 (lbstanza.org)
1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 프로그래밍 생산성의 핵심은 언어 자체보다 풍부한 라이브러리 생태계에 있음
  • Ruby on Rails처럼 언어의 고급 기능을 활용한 프레임워크가 비전문가에게도 높은 생산성을 제공
  • 그러나 언어의 구조적 한계 때문에 Rails 수준의 프레임워크를 Java나 C로는 구현하기 어려움
  • 언어 설계는 작성 가능한 라이브러리의 형태와 복잡도를 직접 결정하며, 이는 언어 발전의 본질적 목적
  • Stanza 언어는 이러한 관점에서, 강력하고 사용하기 쉬운 라이브러리 생성을 가능하게 하는 언어 설계의 중요성을 보여줌

프로그래밍 언어와 라이브러리의 관계

  • 대부분의 프로그래밍 언어는 변수, 배열, 반복문, 함수 등 유사한 기본 요소를 가짐
    • 일부 언어는 일급 함수나 코루틴 같은 고급 기능을 제공하지만, 비전문가들은 이를 잘 사용하지 않음
  • 많은 개발자에게 생산성을 높이는 요인은 언어보다 라이브러리임
    • 예로, Ruby on Rails는 데이터베이스 기반 웹 애플리케이션을 손쉽게 구축할 수 있게 함
    • Rails 덕분에 Ruby 언어 자체보다 프레임워크에 대한 선호가 높음

Ruby on Rails와 언어 기능의 상호작용

  • Rails는 Ruby의 메타프로그래밍, 런타임 평가, 일급 함수, 가비지 컬렉션 등 다양한 기능을 활용
    • 예: ActiveRecords는 메타프로그래밍을, 템플릿 시스템은 런타임 평가를 사용
    • 이벤트 처리는 일급 함수를 콜백으로 전달하는 방식으로 구현
  • Java나 C에서는 이러한 기능이 부족해 Rails 수준의 프레임워크 구현이 불가능
    • Java의 메타프로그래밍은 ActiveRecords를 구현할 만큼 강력하지 않음
  • 따라서 Rails는 Ruby 언어의 구조 덕분에 가능하며, 언어 설계가 라이브러리 가능성을 결정

언어 설계가 라이브러리 형태를 결정

  • C 언어는 함수 선언과 호출만으로 재사용을 지원하므로, 대부분의 C 라이브러리는 함수 집합 형태
  • Ruby는 일급 함수를 지원해 “버튼 클릭 시 실행할 동작”을 간결하게 표현 가능
    • 반면 Java에서는 핸들러 클래스를 정의해야 하므로 코드가 복잡해짐
  • 언어의 표현력은 라이브러리의 구조와 사용성을 직접적으로 규정

상호작용형 소프트웨어와 확장 가능한 프레임워크의 등장

  • 1970년대의 배치형 컴퓨팅에서는 함수 중심의 라이브러리로 충분했음
  • 현대의 상호작용형 소프트웨어에서는 확장 가능한 라이브러리가 필요
    • GUI나 이벤트 기반 시스템에서 “사용자 클릭 시 내 코드를 실행”하는 구조 요구
  • Java와 C++은 상속과 메서드 오버라이딩으로 확장을 지원하며, 이러한 구조가 프레임워크로 발전

Stanza 설계의 배경과 언어 한계

  • Stanza의 설계 동기는 Java에서 사용하기 쉬운 게임 프로그래밍 라이브러리 작성의 어려움에서 출발
    • Java에서는 동시성을 상태 기계(state machine)로 표현해야 했음
    • Scheme은 continuation을 지원해 더 직관적인 구현 가능
  • 그러나 Scheme은 정적 타입 검사를 지원하지 않아 디버깅 효율이 낮음
    • 현재 대부분의 언어는 타입 시스템을 라이브러리로 확장할 수 없음
  • Stanza는 선택적 타입 시스템, 가비지 컬렉션, 멀티메서드 기반 객체 시스템을 제공
    • 하지만 사용자 정의 객체 시스템을 새로 작성할 수는 없음

언어의 목적과 연구 방향

  • 범용 프로그래밍 언어의 목적은 강력하고 사용하기 쉬운 라이브러리 생성 지원
    • 언어가 강력할수록 라이브러리 사용이 간결해짐
  • 코드가 잘 설계된 라이브러리를 사용할 때는 동료에게 지시하는 문장처럼 읽히는 자연스러움을 가짐
  • Racket, Shen, 메타 객체 프로토콜 연구 등은 확장 가능한 타입·객체 시스템을 탐구 중
  • 궁극적으로 언어는 “어떤 라이브러리를 쓸 수 있고, 쓸 수 없는가”로 구분됨
  • 우아한 라이브러리 뒤에는 수십 년의 언어 연구와 설계 노력이 존재함
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 가장 좋은 예는 Prolog임. 흔히 논리 프로그래밍의 대표 언어로 불리지만, 사실상 여러 알고리즘의 모음에 불과하며, 각 언어의 라이브러리로 구현될 수 있음. Prolog의 문법적 표현만 각 언어의 문법에 맞게 제공하면 충분하다고 생각함

    • Prolog의 핵심은 알고리즘이 아니라 논리 규칙을 선언적으로 표현하는 방식임. 예를 들어 “조부모는 부모의 부모”라는 규칙을 정의하면, 이를 통해 조부모를 찾거나 역으로 부모 관계를 추론할 수도 있음. 이런 양방향 추론이 Prolog의 매력임. 물론 일반 언어로 이런 기능을 흉내 내려면 부작용 없는 코드와 제한된 DSL이 필요함. CUDA를 Python에서 돌리는 PyTorch나 TensorFlow처럼 언어 간 호출도 가능하니, 언어에 종속되지 않는 구조도 충분히 가능하다고 봄
    • Prolog의 문법은 1차 논리(First Order Logic) 의 부분집합으로, 변수는 값이 할당되지 않고 가능한 값의 집합 위에서 조건을 만족할 때까지 탐색함. Prolog 엔진은 단순한 라이브러리 호출 이상의 일을 함 — 예를 들어 해 공간 압축 표현, 병렬 실행, 자동 가지치기 등이 있음. 그래서 보통은 Prolog를 백엔드 서비스로 두거나 코드 생성 방식으로 통합함. Prolog는 계획, 제약 해결, 정리 증명, 조합 테스트, 가격 모델링 등에서 특히 강력함. 그래서 Prolog를 단순히 “라이브러리로 충분한 언어”라 보기엔 무리가 있다고 생각함
    • 같은 논리로 보면, 객체지향 기능도 클로저로 흉내낼 수 있으니 언어에 굳이 필요 없다고 할 수도 있음. 하지만 명확한 문법이 주는 표현력이 주는 장점이 있음
    • Prolog 같은 관계형 프로그래밍을 라이브러리로 구현하려면 언어가 심볼과 변수 조작을 일급 객체로 지원해야 함. Lisp류 언어가 그나마 가능하지만, 일반 언어에서는 사용성이 크게 떨어짐. Bob Harper와 얘기했을 때 그는 “그냥 새 언어를 만들어라”라고 했는데, 그 말이 꽤 설득력 있었음
    • Prolog를 배우고 싶은데, 입문 튜토리얼과 고급 예제 사이의 중간 수준 자료를 찾기 어려움. Sudoku 변형 퍼즐을 Prolog로 풀어보려 하는데, 기존 예제는 너무 최적화되어 있어서 일반화된 관계 정의를 배우기 힘듦. 특히 일부 규칙이 틀릴 수도 있는 상황을 모델링하는 법이 궁금함. 참고로 SWI-Prolog의 Sudoku 예제를 보고 있음

  • 10년 전엔 Scala 팬이었음. 타입 시스템 안에서 DSL을 만들 수 있다는 “Scalable Language” 개념이 매력적이었음. 하지만 커뮤니티가 JVM 위의 Haskell처럼 쓰기 시작하면서 흥미를 잃었음. 요즘은 WASM이나 Graal 같은 기술이 언어 선택의 유연성을 높여줄 것 같아 기대 중임. JS로 충분한 경우가 많지만, 필요할 때 Rust 같은 저수준 언어를 쓸 수 있는 선택지가 생긴 게 좋음

    • 나도 Scala의 가장 큰 문제는 DSL 남용이라고 생각함. 언어 자체뿐 아니라 테스트 프레임워크 등에서 또 다른 언어를 배워야 하는 느낌임. 물론 Hadoop MapReduce를 한 줄로 표현할 수 있는 건 인상적이었지만, 대부분의 업무엔 과함. 게다가 Scala 개발자들은 “지루한 코드”를 쓰기 싫어함. 멋을 부리려다 유지보수 지옥을 남기고 떠나는 경우를 많이 봤음
    • Scala 커뮤니티 전체가 Haskell 지향적인 건 아님. 일부 타입 마법사들이 그런 경향을 보일 뿐임. Scala는 단순히 “더 나은 Java”로 써도 충분히 훌륭함. 함수형의 장점을 부담 없이 누릴 수 있음
    • Haskell은 원래 DSL 제작용 언어로 자주 쓰임. Meta의 Haxl이나 음악용 DSL인 TidalCycles가 좋은 예임. 다만 고차 타입 기반 라이브러리들은 성능 저하가 심하고, 불필요하게 복잡함
    • 혹시 Clojure(Script) 를 써봤는지? Lisp 계열답게 문제에 맞춰 언어를 확장하는 bottom-up 프로그래밍이 가능함. Paul Graham의 On Lisp에서도 이런 접근을 강조함. 관련 강연 Bottom Up vs Top Down Design in Clojure도 추천함
    • 나는 최근 Scala를 배우기 시작했는데, 함수형 프로그래밍 측면에서도 정말 마음에 듦. DSL 제작 외에도 다양한 방식으로 쓸 수 있을 만큼 범용적이라 생각함. 혹시 Scala에 부족한 점이 있다고 느끼는지 궁금함

  • 타입이 있는 스크립트 언어로 bash를 대체할 수 있으면 좋겠음. Elixir로 간단한 JSON 파서 스크립트를 만들어봤는데 꽤 괜찮았음

    • Nushell을 써봤는지? 예전엔 “진짜 언어”를 써야 했던 작업을 한 줄로 처리할 수 있음. 예를 들어 파일 목록을 정렬하고 JSON으로 출력하는 파이프라인을 간단히 작성할 수 있음
    • 사실 shebang을 이용하면 여러 언어로 스크립트를 작성할 수 있음. 예를 들어 C#, Java, Go 모두 가능함. Scriptisto를 쓰면 거의 모든 언어로 shebang 스크립트를 만들 수 있음
    • OCaml도 스크립트처럼 쓸 수 있음. #!/usr/bin/env ocaml로 바로 실행 가능함. 다만 단일 파일에서 외부 의존성을 자동 설치하는 기능은 없음
    • Go에서도 shebang을 흉내내는 트릭이 있음. 관련 토론은 여기 참고
    • 일상 스크립팅엔 Python이나 PowerShell도 좋은 선택임

  • 언어와 라이브러리는 서로 배타적이지 않음. 어떤 라이브러리는 사실상 언어처럼 작동하고, 반대로 언어가 특정 라이브러리를 위해 설계되기도 함. 예를 들어 Julia는 성능과 사용성의 균형을 잘 잡은 사례임. 고성능 코드를 Julia로 직접 작성하고, JIT 수준의 타입 특화 컴파일로 최적화된 실행을 얻을 수 있음. 단순한 함수 호출 모델이지만, 내부적으로는 매우 정교하게 동작함

    • 맞음, 결국 언어와 라이브러리 둘 다 필요하다는 게 핵심 요지였음

  • Raku는 여러 하위 언어(slang)를 엮은 구조로 설계되어 있음. 예를 들어 정규식, PEG, quoting 등을 각각의 미니언어로 다루고, Slangify를 이용해 자신만의 DSL을 쉽게 추가할 수 있음

    • 하지만 개인적으로는 타입이 변수 이름 뒤에 오는 문법이 마음에 들지 않아 Raku는 선호하지 않음

  • 예전에 한 시니어 개발자가 “이력서에 Rails가 보이면 바로 버린다”고 말했음. 언어로 사람을 평가하는 건 얼마나 어리석은 일인지 새삼 느꼈음

    • Rails의 부상과 J2EE의 쇠퇴가 동시에 일어난 건 우연이 아님. Rails는 단순하고 의견이 명확한 백엔드 코드를 보여줬고, 그 영향으로 DropWizard, Javalin, Spring Boot 같은 Java 프레임워크들이 등장했음
    • 그 시니어의 기술 스택이 궁금함
    • 그런 동료의 쓰레기통을 내가 수거하고 싶을 정도임. 좋은 Rails 개발자는 찾기 힘듦. 나도 RoR 경험이 있고 여전히 좋아함
    • 물론 Java 개발자를 찾는 입장이라면 Rails 이력서를 거르는 게 효율적일 수도 있음
    • 사람을 평가하는 기준은 결국 조직의 문화적 적합성과 협업 스타일에 따라 달라짐. 완벽한 필터링 방법은 없음

  • 언어나 라이브러리는 결국 기계와 사람 모두와의 소통 수단임. 기계는 비트와 전압으로, 사람은 의도와 개념으로 소통함. 따라서 언어나 라이브러리가 사람에게 명확하고 빠른 표현 수단을 제공한다면, 그것이 언어인지 라이브러리인지는 중요하지 않음. Rails든 Stanza든, 목적에 맞고 팀이 이해하기 쉬우면 그게 정답임

  • 나는 “라이브러리가 곧 최종 언어”라고 생각함. 예를 들어 Ruby on Rails는 Ruby를 기반으로 한 훌륭한 웹 서비스 언어임. Ruby와 Rails는 서로를 위해 진화했음. 결국 프로그래밍은 언어의 연속적인 번역 과정이라고 봄

    • C#과 ASP.NET Core도 비슷하게 함께 발전했음. 사용자 친화적 문법과 시스템 수준의 최적화가 동시에 이루어졌음

  • “언어가 강력할수록 라이브러리 사용이 쉬워진다”는 말이 맞음. 예전 Java로는 Express 같은 프레임워크를 만들기 어려웠음

    • Express가 뭔지 모르겠지만, Java는 라이브러리 활용성 덕분에 기업용 언어로 자리 잡았다고 생각함
    • C#의 ASP.NET Core minimal API는 Express를 거의 그대로 구현한 사례임. 언어와 프레임워크가 함께 발전해야 가능함
    • Java에서도 Javalin 같은 Express 유사 프레임워크가 있음. 문제는 커뮤니티가 단순함을 원하지 않는다는 점임

  • C 언어용 웹 프레임워크라면 PHP가 있지 않겠음? ;)

    • 그건 라이브러리 개념을 너무 확장한 농담 같음
답변달기