가장 좋은 예는 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가 좋은 예임. 다만 고차 타입 기반 라이브러리들은 성능 저하가 심하고, 불필요하게 복잡함
언어와 라이브러리는 서로 배타적이지 않음. 어떤 라이브러리는 사실상 언어처럼 작동하고, 반대로 언어가 특정 라이브러리를 위해 설계되기도 함. 예를 들어 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 유사 프레임워크가 있음. 문제는 커뮤니티가 단순함을 원하지 않는다는 점임
Hacker News 의견들
가장 좋은 예는 Prolog임. 흔히 논리 프로그래밍의 대표 언어로 불리지만, 사실상 여러 알고리즘의 모음에 불과하며, 각 언어의 라이브러리로 구현될 수 있음. Prolog의 문법적 표현만 각 언어의 문법에 맞게 제공하면 충분하다고 생각함
10년 전엔 Scala 팬이었음. 타입 시스템 안에서 DSL을 만들 수 있다는 “Scalable Language” 개념이 매력적이었음. 하지만 커뮤니티가 JVM 위의 Haskell처럼 쓰기 시작하면서 흥미를 잃었음. 요즘은 WASM이나 Graal 같은 기술이 언어 선택의 유연성을 높여줄 것 같아 기대 중임. JS로 충분한 경우가 많지만, 필요할 때 Rust 같은 저수준 언어를 쓸 수 있는 선택지가 생긴 게 좋음
타입이 있는 스크립트 언어로 bash를 대체할 수 있으면 좋겠음. Elixir로 간단한 JSON 파서 스크립트를 만들어봤는데 꽤 괜찮았음
#!/usr/bin/env ocaml로 바로 실행 가능함. 다만 단일 파일에서 외부 의존성을 자동 설치하는 기능은 없음언어와 라이브러리는 서로 배타적이지 않음. 어떤 라이브러리는 사실상 언어처럼 작동하고, 반대로 언어가 특정 라이브러리를 위해 설계되기도 함. 예를 들어 Julia는 성능과 사용성의 균형을 잘 잡은 사례임. 고성능 코드를 Julia로 직접 작성하고, JIT 수준의 타입 특화 컴파일로 최적화된 실행을 얻을 수 있음. 단순한 함수 호출 모델이지만, 내부적으로는 매우 정교하게 동작함
Raku는 여러 하위 언어(slang)를 엮은 구조로 설계되어 있음. 예를 들어 정규식, PEG, quoting 등을 각각의 미니언어로 다루고, Slangify를 이용해 자신만의 DSL을 쉽게 추가할 수 있음
예전에 한 시니어 개발자가 “이력서에 Rails가 보이면 바로 버린다”고 말했음. 언어로 사람을 평가하는 건 얼마나 어리석은 일인지 새삼 느꼈음
언어나 라이브러리는 결국 기계와 사람 모두와의 소통 수단임. 기계는 비트와 전압으로, 사람은 의도와 개념으로 소통함. 따라서 언어나 라이브러리가 사람에게 명확하고 빠른 표현 수단을 제공한다면, 그것이 언어인지 라이브러리인지는 중요하지 않음. Rails든 Stanza든, 목적에 맞고 팀이 이해하기 쉬우면 그게 정답임
나는 “라이브러리가 곧 최종 언어”라고 생각함. 예를 들어 Ruby on Rails는 Ruby를 기반으로 한 훌륭한 웹 서비스 언어임. Ruby와 Rails는 서로를 위해 진화했음. 결국 프로그래밍은 언어의 연속적인 번역 과정이라고 봄
“언어가 강력할수록 라이브러리 사용이 쉬워진다”는 말이 맞음. 예전 Java로는 Express 같은 프레임워크를 만들기 어려웠음
C 언어용 웹 프레임워크라면 PHP가 있지 않겠음? ;)