파스칼을 사용하는 이유

 (castle-engine.io)
2P by GN⁺ | ★ favorite | 댓글 3개
  • Object Pascal은 읽기 쉬운 현대적 객체지향 언어와 네이티브 성능을 함께 목표로 하며, 여러 플랫폼에서 유지보수 가능한 애플리케이션을 만들기 위한 선택지임
  • 강한 타입, 컴파일 시점 검사, 런타임 검사 덕분에 이름 오타나 타입 불일치 같은 오류가 사용자에게 도달하기 전에 걸러지기 쉬움
  • 필요하면 포인터, OS·CPU별 코드, 어셈블리까지 사용할 수 있지만, Castle Game Engine은 어셈블리 없이도 빠른 코드를 유지하는 쪽을 선택함
  • Windows, Linux, macOS, 모바일, 콘솔, 웹까지 폭넓게 대상으로 삼을 수 있고, Castle Game Engine은 엔진 코드와 게임 코드가 같은 언어로 작성됨
  • FPC, Lazarus, Delphi, VS Code 통합과 다양한 라이브러리 연동이 있어 Pascal 생태계 안에서도 실용적인 개발 흐름을 구성할 수 있음

읽기 쉽고 타입 안전한 Object Pascal

  • Object Pascal은 현대적이고 읽기 쉬우며 빠른 타입 안전 크로스플랫폼 언어로 다뤄짐
  • 다른 객체지향 언어를 알고 있다면 비교적 쉽게 익힐 수 있고, 학습 자료로 Modern Object Pascal Introduction for Programmers를 사용할 수 있음
  • 현대적인 객체지향 언어에서 기대하는 기능을 갖춤
    • 클래스
    • 유닛
    • 프로퍼티
    • 제네릭
    • 인터페이스
    • 리플렉션
    • 클로저
  • 문법은 읽기 쉬운 코드에 초점을 둠
  • 타입 안전성을 위해 boolean, string, char, set, enum, range 같은 별도 타입을 제공함
    • 정수를 float에 대입하는 것처럼 안전한 변환은 쉽게 처리됨
    • 그 외 변환은 명시적으로 수행해야 함

컴파일과 런타임에서 오류를 잡는 방식

  • Object Pascal은 컴파일 시점 검사를 중시함
  • 데이터 구조 재배치 같은 리팩터링을 할 때, 컴파일러가 수정이 필요한 지점을 드러내도록 만들 수 있음
  • 이름 오타나 타입 불일치 같은 명백한 실수는 컴파일을 통과하지 않아 사용자에게 도달하지 않음
  • 추가 런타임 검사도 제공함
    • 배열 범위 검사
    • 정수 오버플로 검사
    • assertion
    • 메모리 누수 검사
  • 런타임 검사는 debug 버전에서 문제를 잡는 데 쓰고, 성능이 중요한 release 버전에서는 끌 수 있음
  • CGE editor로 컴파일할 때는 debug / release 모드가 자동 설정되며, “Run” 메뉴에서 모드를 전환할 수 있음
  • 관련 문서로 What are range and overflow checks (and errors) in Pascal와 Detecting Memory Leaks를 참고할 수 있음

네이티브 성능과 필요한 만큼의 저수준 제어

  • Object Pascal은 네이티브 코드로 컴파일되므로 기본 실행 성능을 확보하기 쉬움
  • 일반 애플리케이션에서는 저수준 최적화까지 내려갈 일이 많지 않음
  • 필요하면 원하는 만큼 저수준 기능을 사용할 수 있음
    • 포인터 사용
    • 포인터 연산
    • OS·CPU별 코드 작성
    • 어셈블리 코드 추가
  • Castle Game Engine은 이식성과 코드 가독성을 높이기 위해 어셈블리 코드가 전혀 없지만 빠른 실행을 목표로 함
  • 컴파일도 빠른 편이며, 새 프로젝트를 처음 열었을 때 데스크톱 빌드는 2.5초, Android 빌드는 10.1초가 걸린 사례가 있음

여러 플랫폼과 Castle Game Engine의 개발 방식

  • Object Pascal은 다양한 플랫폼을 대상으로 사용할 수 있음
    • 데스크톱: Windows, Linux, macOS, Raspberry Pi, FreeBSD, 아마도 모든 Unix
    • 모바일: Android, iOS
    • 콘솔: Nintendo Switch
    • 웹: WebAssembly, pas2js를 사용한 JS
  • Castle Game Engine의 지원 플랫폼은 Castle Game Engine platforms supported에서 확인할 수 있음
  • 전체 가능 대상은 FPC target platforms와 Delphi target platforms를 참고할 수 있음
  • Castle Game Engine에서는 엔진 코드와 게임 코드가 같은 언어로 작성됨
  • 엔진은 오픈소스이며, 필요에 맞게 CGE를 fork해 수정할 수 있음

라이브러리와 개발 도구 생태계

  • Pascal에는 여러 분야의 기존 라이브러리와 유닛이 있음
    • 데이터베이스
    • XML, JSON
    • AI
    • 블록체인
    • 네트워킹
  • C API가 있는 기존 라이브러리와 쉽게 통합하거나 링크할 수 있음
    • 렌더러
    • 사운드 라이브러리
    • 물리 엔진
  • Python libraries in Pascal도 사용할 수 있음
  • 주요 도구 생태계는 다음과 같음
    • FPC: 오픈소스 Free Pascal Compiler
    • Lazarus: FPC 기반 오픈소스 Pascal IDE
    • Delphi: 상용 Pascal 컴파일러와 IDE
    • VS Code: CGE와 Pascal 생태계의 여러 도구가 VS Code 통합을 명시적으로 지원함

함께 보면 좋은 글 β

gmong   [-]

델파이.. 추억돋네요. 볼랜드, 델마당..

답변달기
xguru   [-]

윈도우 개발 하던 시절엔 정말 Object Pascal with Delphi 가 최고였던 것 같습니다.

답변달기
GN⁺   [-]
Hacker News 의견들

  • 예전에 Delphi를 쓰던 사람이라면 Lazarus를 이미 알 가능성이 큼. Lazarus는 사실상 오픈소스 재구현에 가깝고, Raspberry Pi 같은 ARM 보드까지 포함해 거의 어디서나 네이티브로 실행·컴파일됨
    다만 라이브러리 설치가 번거로울 수 있어서 IDE와 모듈, 꽤 흥미로운 애드온 설치를 자동화하려고 FpcUp, 이후 FpcUpDeluxe가 만들어짐
    https://wiki.freepascal.org/fpcupdeluxe
    FpcUpDeluxe에 포함된 무료 위젯으로 급히 만든 계기판 위젯 데모도 있음
    https://ibb.co/9bchx7T
    FpcUpDeluxe는 Alpine Linux에서도 동작하며, 릴리스 페이지에서 musl 버전을 받으면 됨. 그래서 아주 작은 시스템에도 계기판을 넣을 가능성이 열림. 여러 플랫폼에서 코드가 네이티브로 컴파일되고 빠르게 실행되며, 인터프리터나 웹 브라우저가 필요 없음

  • 한때 Delphi/Pascal을 주 언어로 썼고, 지난 10~20년 동안 내게 맞는 언어를 찾아다녔음. Haxe도 꽤 오래 썼지만 결국 “그건 매크로로 하면 된다”는 함정에 빠진 느낌이었음. 매크로는 뭐든 할 수 있지만, 충분히 많아지면 모두가 자기만의 매크로 확장 언어로 프로그래밍하게 됨
    JavaScript는 괜찮은 개선이 생겼고 여전히 더 필요하지만, 지금은 그쪽 작업도 많이 함. 몇 년 전 8비트 AVR 코드를 쓰면서 FreePascal을 다시 써봤는데 정말 즐거웠음. 새 기능들을 써보니 진짜 현대적인 언어처럼 느껴졌고, 작은 공간을 대상으로 코딩하느라 표준 라이브러리를 거의 쓰지 않고 필요한 코드를 직접 만들었던 점도 좋았음
    덕분에 FreePascal이 오랜 세월 쌓아온 하위 호환 네임스페이스 잡음, 예컨대 TList, TFPList, TFPGList, TFPGObjectList 같은 층을 피할 수 있었음. 가장 아쉬웠던 건 FPU나 에뮬레이션이 없는 대상에서 컴파일러가 상수 부동소수점 표현식을 허용하지 않았다는 점임. 컴파일 시점에 계산할 수 있으니 가능했으면 좋았을 듯함
    다른 환경을 써보니 이제는 함수 중간에 변수를 정의하지 못하는 점이 제약처럼 느껴지고, 하위 함수 수준의 범위 지정도 있으면 좋겠음. begin/end와 {} 차이는 별로 신경 쓰이지 않음. 지금은 대소문자를 구분하는 언어가 더 좋고, 타입에 문자 접두사를 붙이지 않는 쪽이 낫다고 봄. 이는 무엇보다 편집기의 발전 때문인 듯함. 구문 강조와 실시간 린팅이 정보를 별도 영역으로 옮겨 텍스트 잡음을 줄여줌
    FreePascal의 후계 언어가 새 출발 방식으로 나온다면 꽤 열광할 것 같음. 최신 기능을 일급 시민으로 쓰는 새 표준 라이브러리가 있으면 좋겠고, 은퇴하면 한번 만들어볼지도 모르겠음

    • begin/end와 {}는 사실 같은 의미가 아님. {}는 지역 범위를 정의하지만 begin/end는 그렇지 않음

  • 90년대에 Delphi를 몇 년간 업무로 썼고 좋아했지만, Borland와 그 뒤의 소유자들이 제품과 언어를 계속 잘못 운영하는 데 지쳤음. Anders Hejlsberg도 Borland를 떠나 Microsoft로 가서 C# 을 만들었고, 개인적으로는 시간을 투자하기에 훨씬 나은 언어와 아키텍처라고 봄

    • C# 데스크톱 앱을 안정적으로 배포하는 건 Delphi/Lazarus가 만드는 단일 exe와 비교하면 완전 악몽에 가까움

  • 요즘은 자원 제약 때문에 재미로 Pascal을 쓰고 있음. 예전 Borland Turbo Pascal 3.00A는 CP/M에서 돌아가며, 편집기·컴파일러·라이브러리를 모두 64KB 안에 제공함
    대화식으로 쓰기에 충분히 빠르고, 저수준 유틸리티나 간단한 게임, 잡다한 해킹을 구현하기에 충분한 코드를 만들어줌. 더 크거나 현대적인 환경에서 Pascal을 써본 적은 없지만, 최근 경험이 꽤 만족스러워서 배제할 생각은 없음

    • Turbo Pascal과 이후 Delphi는 프로그래밍 언어가 처음으로 진짜 와닿았던 순간이었음. 결국 C와 C++ 쪽으로 갔지만, 더 표현력 있는 언어로 돌아가고 싶은 마음은 늘 있었음
      아직도 현대적인 Pascal 구현이 있는 줄 몰랐고, 첫사랑과 다시 친해져야 할지도 모르겠음
    • 아직 안 써봤다면 Free Pascal을 확인해보면 좋음. 많은 플랫폼을 지원함
      CP/M이 필요하다면 사이트에서 지원 여부를 확인할 수 있고, 지원한다고 해도 놀랍지 않음. 텍스트 UI IDE는 Turbo Pascal과 매우 비슷하고 번개처럼 빠름. 언어는 Turbo Pascal보다 훨씬 많은 고급 기능을 갖췄지만, 원하지 않으면 쓰지 않아도 됨
      예전에 Windows에서 간단히 테스트했을 때 생성 바이너리도 C처럼 매우 작았고, 단순 hello world 프로그램이 50~60KB 미만이었음
    • 아, Pascal의 향수여. TRS-80 Model III 시절에 거금 80~100달러를 모아 Pascal 80 패키지, New Classics 버전을 샀음. 사실상 초기 IDE였고 당시 기준으로 꽤 훌륭했음. http://www.trs-80.org/pascal-80/
      M-III BASIC 개발 환경보다 엄청난 발전이었던 기억이 있고, 48KB RAM 안에서도 내가 만든 게임과 유틸리티가 꽤 잘 돌아갔음. Pascal-80 코드베이스가 어떻게 됐는지 궁금함. 복고 하드웨어용 현대 도구보다 나을 리는 없고 아마 훨씬 못하겠지만. “Oh Pascal!”은 내가 이 언어를 배운 책이었고, Pascal이 상업적으로 쓰이기 몇 년 전이라 다른 선택지는 많지 않았을 것 같음

  • 몇 가지 이유에는 동의하기 어려움. Object Pascal은 현대적인 언어가 아님. 1998년에는 그랬을지 몰라도 이후 크게 발전하지 않았고, 마지막 큰 변화도 다른 거의 모든 언어보다 늦게 들어온 제네릭이었음
    FPC가 특별히 빠른 코드를 생성하지도 않고, Object Pascal 객체 특성도 지역성에 유리하지 않음. 스크립트 언어보다는 빠르지만, 가비지 컬렉션이 있는 언어까지 포함해 일반적인 사전 컴파일 언어보다는 대체로 느림
    반면 생태계는 훌륭함. 좋은 라이브러리와 도구가 많고, 가장 주목할 만한 건 Delphi 클론인 Lazarus임. FPC나 Delphi를 쓰는 사람들은 언어 현대화 같은 것에는 별로 신경 쓰지 않고 그냥 일을 끝내는 편이었음. 다만 새 개발자에게 매력적일 것 같지는 않아서 미래가 어떻게 될지는 모르겠음

    • FPC에 제네릭이 들어간 건 17년 전이라 최근 변화와는 거리가 멂. 최근 추가된 큰 변화라면 익명 함수와 함수 참조, 즉 클로저가 더 적절한 후보라고 봄
      실제 성능은 충분하고, 병목을 찾으면 필요한 만큼 최적화할 수도 있음. C++에 비해 “고수준” 클래스를 쓰면 좀 더 귀찮을 수는 있지만 불가능하지는 않음
      최소한의 노력으로 기본 성능을 원한다면 새 LLVM 백엔드도 있음. 런타임 라이브러리와 FCL 등을 모두 LLVM 백엔드로 빌드해야 하므로 컴파일러를 소스에서 빌드해야 하지만 몇 분이면 됨. 대신 컴파일러가 훨씬 느려지고, 개인적으로는 성능 차이가 그만한 가치가 있다고 보지는 않음
    • 너무 낮게 평가한 듯함. 예전에 C++만큼 빠르게 벤치마크된 적도 있었고, 주 용도인 로컬 GUI 앱에서는 C# GUI 앱 등을 포함해 이렇게 즉각적으로 반응하는 걸 본 적이 없음
      그래서 실제보다 50배쯤 느리다고 판단한 벤치마크가 무엇인지 궁금함
    • FPC는 모르겠지만, Delphi 7은 10년 전 경쟁 프로그래밍에서 C++와 비슷한 수준이었고 Java보다 2~3배 빠른 정도였음
      여기서 경쟁 프로그래밍이란 실행당 최대 1~3초의 짧은 CPU 중심 단일 스레드 알고리즘 계산이며, JIT에는 불리하고 기본 컴파일러·런타임 설정, 외부 라이브러리나 튜닝 없이 진행되는 환경을 말함. 당시 상식은 C++/Pascal을 쓰거나, Java로 하다가 “time limit exceeded”가 뜨면 200~300줄짜리 풀이를 C++로 다시 써서 통과시키는 식이었음
    • Pascal과 C++의 가장 큰 차이는 개발자 경험임
      Pascal은 단일 패스 LL(1) 컴파일러를 써서 밀리초 단위 컴파일이 가능함. Edit→Compile→Run을 1초 안에 끝내는 REPL 같은 경험을 줌. 매크로와 느린 컴파일 시간을 가진 C/C++는 개발자 경험이 더 나빴고, 적어도 내가 C 대신 Pascal, C++ 대신 Delphi를 배운 이유였음
    • 생태계가 훌륭하다는 데는 강하게 동의하지 않음. Pascal로 약 10년 일했는데, 현대적인 라이브러리 부족 때문에 자주 답답했고, 결국 직접 해결책을 만들거나 아이디어를 통째로 포기해야 했음

  • 왜 굳이 그래야 하는지 모르겠음. 오래된 언어는 레거시 지원 때문에 남아 있어야 하지만, 그런 현대 기능들을 오래된 언어에 억지로 끼워 넣는 의미는 잘 보이지 않음
    Java를 많이 쓰지만, 솔직히 Java 8 이후의 거의 모든 기능은 추가되지 말았어야 한다고 봄. 예를 들어 람다는 Java에서는 땜질에 가까움
    현대 기능을 원하면 현대 언어를 쓰면 됨. Java 생태계에 머물고 싶다면 Kotlin을 쓰면 됨. Pascal은 말 그대로 수십 년 동안 본 적이 없고 마지막으로 프로그래밍한 게 1980년대라 Java 얘기만 하는 것이지만, Pascal에 그런 기능 목록을 추가하는 건 우스워 보임

    • 람다가 땜질이라고? 정말로 메서드 하나짜리 익명 클래스를 만드는 쪽이 더 낫다고 보는 건가?
    • Java에서는 언어 간 상호 운용이 쉬워서 Kotlin 같은 선택이 더 쉬움. Clojure도 마찬가지임. 하지만 C++를 쓰고 있다면 다른 것으로 쉽게 업그레이드할 경로가 없음
      그래도 현대 기능을 끼워 넣는 가치는 있음. 지금 새 프로젝트를 C++로 시작하지 않고 Rust 같은 현대 언어를 고를 수는 있지만, 이미 작성된 수백만 줄의 C++ 코드는 현대 기능으로 개선될 수 있음. C++11이 판도를 바꾼 걸 보면 됨
    • 그러면 프로그래밍 언어를 훨씬 더 자주 갈아타야 함. 이 과정을 늦추기 위해 이득이 검증된 새 기능을 추가하고 통합하는 건 합리적으로 보임
    • 최근까지 Java는 터무니없이 큰 생태계를 제외하면 15년 전 Delphi보다 나은 점이 적었음. 물론 그 생태계가 모든 걸 이기긴 함
      Java 언어는 언어 기능 대신 라이브러리를 쓰기로 한 결정 때문에 엄청난 양의 상용구 코드를 낳았고, 그 방향이 잘못됐다고 봄. Python, Lisp, Haskell에서 되는 건 Java에서도 다 할 수 있지만, 정의상 brainf*ck에서도 할 수 있음. 실제 Java 해법의 복잡도는 기능이 많은 언어보다 높아지고, 결국 그런 언어 기능들을 약간 망가진 방식으로 재구현하거나 이를 대신하는 의존성을 잔뜩 끌어오게 됨. 어느 쪽이든 배워야 할 API 표면만 더 늘어남
    • 경쟁력 있는 JVM 언어가 생긴 건 최근 몇 년뿐임. Scala는 막다른 길이었고, Clojure는 유행에 가까웠으며, Rhino/JS는 야심이 매우 제한적이었음
      Java의 개선 덕분에 JVM이 계속 관련성을 유지하고 DotNet을 막아낼 수 있었고, Microsoft의 역사를 생각하면 좋은 일이었음

  • 자주 간과되지만, Ada 임베디드 생태계는 정적 분석, 디버깅, 대상 지원의 성숙도에서 장점이 있음

    • Ada는 늘 저평가됐다고 생각했음. 개인적으로는 메모리 안전성, 표준 동시성 모델, 단위·측정 타입 지원, 사전 컴파일 같은 기능을 높게 봄
      Ada의 Pascal 비슷한 문법은 장황해 보이지만 읽기 어렵지는 않음. VHDL도 Ada 문법 기반이라 두 언어를 함께 쓰는 사람에게는 더 쉬울 수 있음
      Swift도 이 중 일부를 만족하고, 클로저·자동 참조 카운팅·타입 추론 같은 편한 기능도 더함. 측정 타입은 잘 모르지만 구현 가능해 보임. 다만 아직 Swift 같은 HDL은 없어 보임
    • Ada가 이제 Android와 iOS 대상을 지원하는지 궁금함. 마지막으로 봤을 때는 NDK용으로 빌드하는 뚜렷한 방법이 없어 보였음
    • macOS에서 시작하기에 가장 친절한 편은 아님

  • Pascal은 실제로 좋고 성능도 괜찮음. 고등학교 때 Basic 다음으로 배운 두 번째 언어였음
    업계가 왜 90년대 후반과 2000년대 초반에 Python, Ruby, Java, JavaScript로 후퇴해야 했는지 이해가 안 됨

    • 최근 이 주제를 다룬 발표를 봤음: https://www.youtube.com/watch?v=Tml94je2edk
      Python, Ruby, JS 같은 동적 타입 언어가 90년대에 인기를 얻은 이유를 설명하는데, 웹사이트를 만들 때 빠른 피드백 루프를 제공했고 IDE나 컴파일러가 필요 없었기 때문이라고 함. 당시 IDE와 컴파일러는 느리고 무료가 아닌 경우도 많았음
      어차피 사용자들이 56k 모뎀으로 접속하던 시절이라, 개발 시간을 성능 향상과 맞바꾸는 게 별로 이득이 아니었음. 발표에는 지난 10~20년 사이 개발 방식이 어떻게 바뀌었는지, 왜 흐름이 다시 정적 타입으로 이동하는지에 대한 흥미로운 포인트도 많음
    • 컴퓨터가 더 빨라지고 메모리도 늘었으니, 그걸 쓸 곳을 만들어야 했던 것임 ;-)
      또한 웹 브라우저가 인기 있는 프로그래밍 플랫폼이 되었고 주로 JavaScript를 썼음. 지금도 브라우저 부분에 더해 웹 브라우저 안에 완전한 운영체제를 욱여넣으려 하고 있고, Chrome은 꽤 가까워지고 있음

  • 대학 1학년 때 첫 프로젝트가 Pascal로 만든 엘리베이터 시뮬레이터였고, 텍스트 그래픽을 썼음. C 계열 언어와 비교하면 Pascal에는 뭔가 우아함이 있어서 즐거웠음
    그래서 요즘 Nim을 즐기고 있는데, 내가 알기로 Nim은 Ada와 Python뿐 아니라 Pascal, Modula-3, Oberon, Delphi 같은 Wirth 계열 언어에서 영향을 받았음

  • Pascal은 그리 나쁘지 않고, 실제로 일부 현대 프로그래밍 언어보다 장점도 있다고 봄. 물론 완벽하지 않고 단점도 있음
    가끔 DOS 프로그래밍에는 Pascal과 BASIC을 쓰는데, 적어도 그 용도에는 Pascal이 괜찮아 보임. C도 DOS 프로그래밍에 쓰이긴 하지만, 특히 리얼 모드에서는 그다지 좋아 보이지 않음
    Linux 프로그래밍에는 대체로 C를 선호하지만 PostScript도 씀. C와 PostScript 모두 일부 현대 언어와 비교해 장점이 있다고 생각함. Pascal은 다른 프로그램에도 쓰일 수 있고, 심지어 TeX도 Pascal로 작성됐음

    • PostScript를 어디에 쓰는지 궁금함. 인쇄 관련 작업 말고 다른 용도로 쓰는 사람들을 보면 흥미로움
답변달기