Racket 프로그래밍 언어

 (racket-lang.org)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Racket은 언어 지향 프로그래밍을 중심에 둔 성숙한 언어로, 일반 애플리케이션 개발과 새 언어 제작을 같은 생태계 안에서 다룸
  • 핵심은 매크로와 #lang 이며, 새 구문·도메인 특화 언어·기존 표면 문법을 라이브러리처럼 만들고 모듈 단위로 사용할 수 있음
  • 웹 서버, 데이터베이스, 수학·통계, GUI, 과학 시뮬레이션까지 포함하는 표준 라이브러리와 수천 개 패키지가 일반 목적 개발 범위를 넓힘
  • Typed Racket, 계약, 객체 시스템, DrRacket IDE가 함께 제공되어 함수형 코드와 객체 지향 구성요소, 점진적 타입을 필요에 맞게 조합할 수 있음
  • Racket은 단순한 Lisp 계열 언어가 아니라, 각 문제 영역에 맞는 언어를 만들고 실행·편집·도구 지원까지 연결하려는 개발 환경에 가까움

언어 지향 프로그래밍을 위한 Racket

  • Racket은 “Racket, the Programming Language”와 “Racket, the Language-Oriented Programming Language”를 함께 내세우는 프로그래밍 언어임
  • Racket version 9.2가 사용 가능함
  • 초기부터 Windows, macOS, Linux에서 크로스플랫폼 그래픽 프로그래밍을 지원해 온 성숙한 제품임
  • 기본 개발 기능은 패키지 관리, GUI, 독립 실행 바이너리, 외부 인터페이스까지 포함함

일반 애플리케이션 개발 범위

  • Racket은 웹 서버 애플리케이션부터 수학, 과학 시뮬레이션 소프트웨어까지 다루는 라이브러리 묶음을 갖춤
  • 대표 문서와 라이브러리 범위는 다음과 같음
  • 크로스플랫폼 GUI 툴박스와 웹 서버가 기본 생태계에 포함됨
  • 수천 개 추가 패키지는 단일 명령으로 설치할 수 있음
    • 예시로 3D graphics, Bluetooth socket connector, color maps, data structures, educational software, games, quantum-random number generator, scientific simulations, web script testing 등이 있음
  • #lang racket/gui 예시는 GUI 방언으로 작은 숫자 맞히기 게임을 구현하며, 여러 언어 기능을 함께 사용함

매크로로 확장되는 언어

  • Racket 프로그래머는 매크로로 자체 반복문과 새 구문을 정의할 수 있음
  • 새 구문은 절차, 메서드, 클래스처럼 추가되며, 커스텀 구문을 Racket 표현식이나 정의로 다시 쓰는 규칙을 만들면 됨
  • 작은 매크로는 다른 기능으로 처리하기 어려운 반복 코드 제거에 도움을 줌
    • 작업 실행 시간을 재는 time-it 구문을 정의할 수 있음
    • 반복적인 lambda 사용을 피할 수 있음
    • 매크로는 일반 함수처럼 모듈에서 export됨
  • 전체 매크로 시스템은 여러 매크로가 협력하는 구조도 만들 수 있음
  • Racket은 함수형 언어이지만 처음부터 classes and objects, mixins and traits 하위 언어를 제공함
  • Java와 유사한 클래스 시스템은 매크로 기반 라이브러리로 구현되어, 핵심 언어의 별도 지원 없이 동작함

#lang와 도메인 특화 언어

  • Racket은 프로그래머가 각 모듈을 알맞은 언어로 작성할 수 있도록 언어를 만드는 언어를 지향함
  • #lang typed/racket 예시는 String과 Number의 union type, occurrence typing, 리스트 필터링을 사용함
  • #lang scribble/base 예시는 PDF 또는 HTML 문서를 생성하는 문서 언어를 다룸
  • #lang datalog 예시는 parent와 ancestor 관계를 정의하고 질의하는 Datalog 문법을 사용함
  • 새 언어는 IDE 창에서 만들고 다른 IDE 창에서 해당 언어의 모듈을 실행할 수 있으며, 설정·프로젝트 파일·외부 도구가 필요 없음
  • Racket 사용자는 괄호 문법을 주로 쓰지만, Datalog처럼 쉼표와 중괄호가 필요한 기존 표면 문법도 만들 수 있음
  • parsing packages를 사용하면 임의 문법을 괄호 기반 언어로 매핑하고, Racket 매크로 시스템으로 일반 Racket에 컴파일할 수 있음

DrRacket과 개발 생태계

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Racket이 첫 페이지에 올라와서 반가움. 1982년부터 연구용 프로그래밍에는 주로 Common Lisp를 써왔지만, 요즘은 Racket을 더 자주 찾게 됨
    Racket에서 마음에 안 드는 부분도 있는데, 컴파일러, 패키지 관리 시스템, GUI IDE, Emacs 바인딩, 쓰기 즐거운 언어라는 점을 제외한 거의 전부임
    프로그래밍 언어 연구 쪽 생태계에는 별 관심이 없고, 아마 프로젝트를 이끄는 컴퓨터과학 교수들이 가장 중요하게 여기는 부분일 듯함. 그래도 그들이 잘되길 바람
    그래서 Racket 프로젝트에 무임승차하는 느낌도 있음. 좋아하는 작은 부분만 즐기고 나머지는 무시하며, 기여도 거의 안 하고 있음. 다만 내가 쓴 작은 Racket 책 정도는 예외일 수 있음

    • 이 말에 거의 전부 동의함. 패키지 관리 시스템, 단계별 디버거가 포함된 GUI IDE, Racket 핵심 팀이 직접 관리하는 크로스플랫폼 IDE 작성 능력, 실행 가능한 바이너리를 쉽게 만드는 기능 때문에 Racket은 내가 가장 좋아하는 Lisp임
      이런 기능들은 정말 유용하고 중요함. Lisp를 좋아하지만, 직장에서는 그 일에 가장 적합한 도구일 때만 언어를 씀. 이런 기능들 덕분에 Racket은 내가 실제로 사용을 정당화할 수 있었던 유일한 Lisp였음
      커뮤니티, 도구, 학습 자료 덕분에 Racket은 개인적으로 남에게 추천하기 쉬운 언어임. CL과 Clojure도 많이 써봤고 좋아하는 점이 있지만, 각각 큰 단점이 있어서 남에게 추천하진 않음
      나도 언어의 연구 쪽 부분이나 lang 기능에는 잘 맞지 않고, HtDP도 꽤 싫어하는 편임. 하지만 그건 내가 좋아하는 언어로 만들어진, 관심 없는 프로젝트들일 뿐이지 언어 자체의 단점은 아니라고 봄. 실제로 부딪힐 일이 거의 없기 때문임
    • https://leanpub.com/racket-ai/read
      이 정도면 대단한 기여라고 봐도 됨 :)
    • CL을 일상적으로 쓰고 있고 연구나 프로그래밍 언어 연구 영역은 아님. 아직 Racket은 써본 적이 없는데, CL과 비교해 Racket에서 마음에 안 드는 부분을 더 설명해줄 수 있는지 궁금함
    • 프로그래밍 언어 연구 생태계가 정확히 뭘 뜻하는지 궁금함. Racket 배포판에서 딱 프로그래밍 언어 연구라고 볼 만한 건 Redex 정도밖에 안 보임
      언어 자체에는 메타프로그래밍 기능이 있지만, 현대 언어들은 다 메타프로그래밍을 갖고 있음
      커뮤니티에서의 내 경험은 대체로 실제 문제를 이야기하는 사람들이었음
      Racket이 프로그래밍 언어 연구나 다른 연구에 쓰이니 관련 논문과 학회 발표에서 Racket을 언급하긴 하지만, 논의를 지배하진 않음
      예: https://racket.discourse.group/t/levin-tree-search-with-cont...
    • 대학에서 프로그래밍 언어 생태계 수업에 Racket을 써봤는데, 그 측면은 나도 별로 즐겁지 않았음. 그래도 Racket은 시작하기 쉽고 자기 역할은 확실히 잘함. Lisp에 발을 들인다면 개인적으로는 Racket이 좋은 출발점이라고 봄
      다만 Clojure는 커뮤니티가 더 크고 탄탄한 편임. 대신 JVM을 써서 설정이 조금 더 번거롭고, 미묘하게 신경 쓸 부분도 더 있음

  • Racket은 매우 실용적인 언어임. 학문적인 특이 취향 정도로 보인다면 Bogdan Popa가 Racket으로 뭘 하는지 보면 좋음: https://defn.io/
    개인적으로 네이티브 GUI가 있는 바이너리가 필요하면 Racket을 씀. JSON, XML, 텍스트 파일 형식 같은 것을 파싱하기에도 꽤 좋음
    함께 보는 책인 How to Design Programs, https://htdp.org/2023-8-14/Book/index.html 도 좋음. 정확히 Racket을 가르치는 책은 아니고 Racket으로 구현된 몇 가지 교육용 언어를 쓰지만, 가끔 되새길 만한 가치 있는 아이디어가 있음
    매크로 시스템은 CL 같은 데서 온 사람에게 이상해 보일 수 있지만, 익숙해지고 나니 메타프로그래밍을 하면서도 비교적 제정신을 유지하기 쉬웠음
    유용한 자료 몇 개 더 있음:
    https://www.greghendershott.com/fear-of-macros/
    https://beautifulracket.com/

    • Bogdan 쪽에서 특히 눈에 띄는 게 있나? 대충 훑어봤을 때는 확 와닿는 게 없었음

  • Racket이라는 언어는 정말 좋아하지만, 강요되는 작업 흐름은 받아들이기 어려움. Python으로 코딩할 때는 편집기로 코드를 쓰고 셸에서 실행함
    Racket은 시작 시간이 너무 길어서 그렇게 잘 안 됨. 대신 장기 실행되는 가상 머신과 REPL로 상호작용해야 한다고들 함
    하지만 그러면 작업 중인 코드가 깨끗한 상태에서 시작하지 않고, 그 순간 가상 머신이 가진 상태에서 시작함. Jupyter 노트북 같은 것에는 훌륭한 흐름이지만, 큰 프로그램에는 잘 맞지 않는다고 봄

    • 편집기로 코드를 쓰고 셸에서 실행하는 방식도 Racket에서 완전히 유효함. 내 경험상 시작 시간은 Python과 꽤 비슷함. 느리긴 하지만 치명적이진 않고, 미리 컴파일하면 특히 괜찮음. 지금 당장 작업이 끝난 파일에는 유용함
      racket 대신 racket/base #lang을 쓰는 것도 큰 차이를 만듦. 자세한 내용은 https://docs.racket-lang.org/style/Language_and_Performance....에 있음
      “깨끗한 상태”에서 시작하지 않는다는 건 Racket보다는 Common Lisp식 REPL에 더 가까워 보임. Racket에서는 보통 파일이나 모듈을 다시 불러올 때 Racket을 재시작해야 해서 신선한 환경을 갖게 됨. 사람들은 그걸 불평하지만, 나는 CL보다 Racket의 깨끗한 상태 방식을 선호함
    • “깨끗한 상태”에서 시작하지 않는다는 부분은 문서상 사용자가 백업 파일 저장을 명시적으로 거부할 수 있는 것처럼 보임
      https://docs.racket-lang.org/drracket/drracket-files.html#(p...
      아마 복원 제안도 거절할 수 있을 것임
      “DrRacket이 처음 시작할 때 남아 있는 백업 파일이 있는지 확인하고, 있으면 백업 파일을 복원할지 제안한다”
    • Smalltalk을 한번 써보면 됨 :-))
    • Guile이 흥미로울 수 있음. 특히 디버깅할 때 Racket보다 더 몰입형에 가깝고, Common Lisp(SBCL)와도 더 비슷하다고 봄
    • Smalltalk과 Lisp Machines의 세계에 온 걸 환영함. 현대 IDE도 아직 핫 리로드, 작업 상태 저장, 단일 언어로 개발 스택 전체를 제어하는 기능을 전부 제대로 지원하진 못함

  • University of British Columbia에서 공부할 때, 컴퓨터과학 입문 과목에서 Racket을 가르쳤음. 훌륭한 언어라고 생각했고, 이전 프로그래밍 경험이 있는 학생들도 Lisp를 해본 적은 거의 없어서 모두를 동일한 출발선에 세워줬음
    간단한 게임이나 시각화를 쉽게 만들 수 있게 해주는 라이브러리들도 인상적이었음

    • 나도 UBC에서 그 수업을 들었지만 완전히 다른 인상을 받았음. 끔찍했고, 특히 명령형 언어로 진행되는 이후의 자료구조와 알고리즘 수업을 대비하기에는 입문 학생들을 매우 부실하게 준비시켰다고 봄
      조교를 했을 때 2학년으로 올라온 학생들 중 상당수가 아직 for 루프도 할 줄 몰랐고, 기본 알고리즘에서 크게 뒤처졌음
      함수형 언어에 대한 더 깊은 appreciation은 4학년 계산 이론 수업 이후에야 생겼음

  • Racket의 이 모든 “언어”들을 하나의 애플리케이션에 어떻게 통합해야 하는지 모르겠음. typed/racket, racket/gui, scribble/base 같은 언어가 보이는데, 타입이 있는 코드로 GUI 애플리케이션을 만들면서 PDF도 생성하려면 어떻게 해야 하는지 감이 안 옴
    Racket 튜토리얼을 여러 번 따라 해봤지만, 서로 무관해 보이는 “언어”들을 어떻게 묶어야 하는지 여전히 헷갈림
    개인적으로 튜토리얼의 각 장은 관련 없는 “언어”만 설명하고, 그것들이 함께 동작하는 모습을 한 번도 보여주지 않는 느낌임. 한 장은 웹 서버를 다루지만 클래스 시스템은 안 다루고, 다른 장은 클래스를 지원하는 다른 “언어”를 다루면서 거기서 웹 서버를 작성하진 않음

    • #lang 줄은 해당 파일을 범위로 하는 일종의 컴파일러 지시문으로 생각하면 됨. 실제로는 훨씬 더 많지만 출발점으로는 괜찮음. 애플리케이션에 타입을 추가하고 싶다면 파일 단위로 하나씩 하는 전략이 좋음
      #lang 줄 외에도 require로 라이브러리를 가져올 수 있으니, 하나의 파일에 GUI 코드와 웹 서버 코드를 함께 넣을 수도 있음. #lang도 한 번에 하나의 언어로만 제한되진 않아서, 충돌하지 않으면 그 줄에 더 추가할 수 있음
    • 타당한 질문이라고 봄. 큰 애플리케이션을 개발한다면 거의 모든 코드는 "racket" 언어로 작성하게 될 가능성이 큼. 타입에 관심이 많다면 상당 부분은 "typed/racket"일 수 있음
      모든 언어가 공통 기반을 공유하고 어느 정도 상호 운용된다는 건 맞지만, 프로그램을 다섯 조각으로 똑같이 나눠 각각 다른 언어를 쓰는 식이 될 가능성은 전혀 높지 않음. 문서는 아마 scribble로 쓰게 될 것임
      서로 다른 언어를 쓰면 근본적으로 다른 프로그래밍 모델을 가질 수 있고, Typed Racket 같은 개발이 가능해진 배경이기도 하지만, 시작을 막는 요소가 되어서는 안 됨
      요약하면 그냥 Racket을 쓰면 됨. 정말 다른 기능이나 프로그래밍 스타일이 필요하다고 느끼면, 이미 제공하는 언어가 있는지 그때 찾아보면 됨. 물론 전부 내 의견임
    • 각 모듈마다 그 모듈의 언어를 선택할 수 있게 되어 있는 것으로 알고 있음

  • 이 웹사이트인 Hacker News는 Arc로 작성됐고 Racket 위에서 실행됨: https://en.wikipedia.org/wiki/Arc_(programming_language)

  • Racket의 가장 큰 문제는 언어나 생태계가 아님: https://news.ycombinator.com/item?id=27531508

    • 링크에 언급된 2018년 Racket school 학생이었음. Felleisen과 Butterick을 포함한 모든 강사들은 강의실 안팎에서 정말 도움이 됐고 친절했음
      설령 그 링크를 완전히 액면 그대로 받아들여 Felleisen이 특정 개인적 상호작용에서 Torvalds식으로 못되게 군다고 해도, How To Design Programs를 포함한 그의 작업은 내 삶과 다른 사람들의 삶에 매우 긍정적인 영향을 줬음. 그래서 사람들이 그걸 활용하지 말라고 말하진 않겠음
    • 저건 유명 커뮤니티 구성원들 사이의 매우 개인적인 갈등임. 더 넓은 Racket 커뮤니티는 핵심 팀을 포함해 매우 친절함
    • Felleisen은 참기 힘든 인간이지만 피하기도 쉬움. Racket 자체라기보다는 학계의 병리 현상에 가까운 증상이라고 봄
      커뮤니티에는 강한 의견을 가진 “이상한 너드”들도 있어서 존재감이 더 크게 느껴지는 만큼 더 짜증 날 수 있음. 하지만 돈이 질서를 붙잡아주지 않는 많은 사회적 공간이 대체로 그렇듯, 그냥 그런 것임

  • Racket은 내가 가장 좋아하는 언어임. 빠르고 실용적이며, 탄탄한 기반이 있고 동시성 모델도 매우 좋음. Concurrent ML에서 빌려와 확장한 개념에 기반함
    문서 시스템도 훌륭하고 패키지 생태계와 통합되어 있어, 대부분의 패키지가 상호 참조가 있는 고품질 문서를 가짐. 하위 호환성도 훌륭해서, 현재 본업에서 쓰는 Python보다 훨씬 낫다고 봄
    그래서 Racket이 너무 학문적이거나 실용적이지 않다고 하는 사람들은 충분히 깊게 파고들지 않았거나, 과거에 교육용 언어만 접한 학생들이었을 가능성이 크다고 느낌
    물론 완벽하진 않음. 커뮤니티가 작고, 런타임의 기본 메모리 사용량이 높으며, 병렬 처리를 하려면 시스템 스레드마다 Racket VM을 띄워야 하는 등의 문제가 있음. 그래도 이런 건 시간이 지나며 나아질 것임
    지난 몇 년 동안 Racket으로 만든 것들: 전자상거래 사이트[1], App Store에 올라간 네이티브 macOS/iOS 알림 앱[2, 3, 4], Apache Kafka용 크로스플랫폼 데스크톱 클라이언트[5, 6, 7], Lua용 #lang[8]. 그 외에도[9][10][11] 여러 가지가 있음. 꽤 실용적인 것들이라고 생각함
    [1]: https://defn.io/2019/08/20/racket-ecommerce/
    [2]: https://defn.io/2020/01/02/ann-remember/
    [3]: https://defn.io/2024/04/09/ann-remember-for-ios/
    [4]: https://github.com/bogdanp/remember
    [5]: https://defn.io/2022/11/20/ann-franz/
    [6]: https://defn.io/2023/10/15/ann-franz-for-windows/
    [7]: https://defn.io/2023/08/10/ann-franz-source-available/
    [8]: https://defn.io/2022/11/12/ann-racket-lua/
    [9]: https://docs.racket-lang.org/http-easy/index.html
    [10]: https://docs.racket-lang.org/deta/index.html
    [11]: https://docs.racket-lang.org/gui-easy/index.html

    • Bogdan은 Racket 생태계에서 없어서는 안 될 gui-easy와 http-easy의 작성자이기도 함
      커뮤니티 포럼에서도 매우 적극적이고 도움 되는 답변을 정말 많이 해줌
      이 언어의 숨은 영웅이라고 생각해서 꼭 언급하고 싶었음. 당신의 라이브러리들이 아무것도 모르는 사용자들의 삶을 훨씬 쉽게 만들어주는 코드를 구동하고 있다고 말할 수 있음 :)
      https://docs.racket-lang.org/http-easy/index.html
      https://docs.racket-lang.org/gui-easy/index.html
      https://racket.discourse.group
    • 하위 호환성은 정말 중요한 지점이라고 봄. Python을 몇 년 동안 집중적으로 썼지만, 2/3 전환에서 핵심 개발자와 커뮤니티가 하위 호환성을 얼마나 신경 쓰지 않는지 보고 깊이 실망했고, 이후에도 나아지지 않았음
      Python이 오늘날 주로 쓰이는 분야 때문일 수도 있음. 2000년쯤 있었던 Numeric/Numpy 전환은 완전히 달랐음
      몇 년마다 깨지는 건 유니콘 스타트업이나 빠르게 움직이며, 말 그대로 무언가를 깨뜨리는 회사에는 괜찮을 수 있음. 하지만 성숙한 알고리즘을 몇 년마다 다시 쓸 여유가 없거나 그걸 우선순위로 보지 않는 사람들과 조직에도 가치 있는 프로그램은 많음

  • Racket을 가끔 쓰고 있고 좋아함. 다만 일부 Lisp, 특히 Common Lisp와 아마 Guile도 생각보다 과소평가되어 있다는 걸 알게 됨
    더 잘 아는 사람들에게 묻고 싶음. 처음에는 실용적이거나 관련 있거나 유용해 보이지 않지만, 막상 써보면 프로그래밍에 의외로 유용한 Racket 기능은 무엇이 있을까?

  • 약 20년 전, MzScheme이 PLT Scheme이 되기 전 이를 기반 언어로 쓰는 이메일 보안 상용 소프트웨어를 작업했음. 코드는 Solaris, Linux, HP-UX에서 동작하는 크로스플랫폼이었고, 운영체제별 코드는 C로 약 1천 줄 정도였음
    필터 규칙은 Scheme 자체로 컴파일됐음. 웹 기반 UI까지 포함해 전체 코드는 약 3만 줄이었고 개발자는 5~6명뿐이었음
    나중에 이민 후 비슷하지만 기능은 더 적은 제품을 가진 회사에 들어갔는데, 그 제품은 C++로 수십만 줄이었고 개발자도 더 많았음

답변달기