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

• 프로그래밍 생산성의 핵심은 언어 자체보다 풍부한 라이브러리 생태계에 있음
• 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, 메타 객체 프로토콜 연구 등은 확장 가능한 타입·객체 시스템을 탐구 중
• 궁극적으로 언어는 “어떤 라이브러리를 쓸 수 있고, 쓸 수 없는가”로 구분됨
• 우아한 라이브러리 뒤에는 수십 년의 언어 연구와 설계 노력이 존재함