이 글의 분류에서 하나만 고치자면, Ruby는 Algol 계열이라기보다 명확히 객체지향 언어라고 봄. Smalltalk의 영향이 크고, 표준 라이브러리 이름도 map보다 collect 같은 식으로 그 흔적이 남아 있음. Ruby는 처음부터 끝까지 모든 것이 객체이고, 메서드 호출도 객체에 메시지를 보내는 개념으로 이해하는 쪽이 자연스러움. Python과 자주 비교되지만 진화 경로는 꽤 달랐고, 지금은 비슷한 생태계 지점으로 수렴한 느낌임. 내겐 Ruby가 Python보다 더 포근한 알파카처럼 느껴짐
Python도 new style classes 이후로는 사실상 순수 OOP 언어라고 볼 수 있음. Hello World 수준에선 티가 덜 나도, 기본형까지 전부 객체가 되었음. OOP를 싫어하는 사람들에게 type(42)와 dir(42)를 보여주면 정수조차 객체라는 점을 강조하기 좋음
특정 원형 언어 하나를 객체지향 언어라고 딱 찍는 방식이 오히려 사람들을 헷갈리게 한다고 느낌. OO는 절차형처럼 하나의 프로그래밍 스타일에 가깝지, Python과 C++를 다중 상속이 있다는 이유만으로 같은 종류의 언어라고 묶는 건 무리라고 봄
낙타 비유를 보니, camel은 원래 Perl 쪽 상징 아니었나 싶음
나는 언어 계보에 증명 표현용 언어라는 부류를 하나 더 넣고 싶음. Curry-Howard 대응으로 프로그램이 곧 증명이 되는 계열이며 Lean이 대표적 예시임. 함수형의 하위 분류로 볼 수도 있지만, 주된 목적이 실행보다 검증이라는 점에서 별도 축으로 다룰 가치가 있다고 느낌
내 눈엔 정리 증명과 복잡한 타입은 기존 언어에 얹힌 확장처럼 보임. Agda, Idris는 복잡한 타입이 추가된 함수형이고, Isabelle·Lean은 거기에 상호작용적 증명이 더해진 형태임. Dafny는 명령형에 정리와 힌트를 얹은 쪽이고, ACL2는 theorem/hint가 붙은 Lisp라고 보면 이해가 쉬움. 또 Rust traits에서 보듯 typeclasses는 함수형·명령형 언어 위에서 돌아가는 일종의 로직 프로그래밍처럼 느껴짐
이런 계열은 정의상 튜링 완전성이 없으니 진짜 프로그래밍 언어로 보긴 어렵다고 생각함. 만약 튜링 완전했다면, 종료되지 않는 프로그램으로 거짓 증명을 만들어낼 수도 있기 때문임
나는 이 계열이 결국 ML에서 직접 파생된 흐름이라고 봄
Lean은 분명 Agda, Idris와 가까운 dependently typed ML-family 언어라서 크게 보면 ML 분류 안에 넣을 수 있다고 생각함. 그리고 Lean의 장기 목표가 실행은 부차적이라는 식도 아닌 듯함. Microsoft가 실제 소프트웨어 작성에 관심을 두고 있음. 반대로 “증명을 표현하는 언어”라는 점을 더 강조하면 Prolog도 빠질 수 없어서, Lean을 ML 반, Prolog 반처럼 볼 수도 있음. 이 관점에선 Curry-Howard 대응은 계산 논리를 구현하는 한 가지 방식이라는 느낌임
최근에 언어 비교 프로젝트를 다시 살펴봤는데, 10개 문자에 대한 3,715,891,200개의 signed permutation을 병렬로 순환 분해하는 벤치마크였음. “원형 언어”보다는 각 패러다임의 현대적 구현체 중 연구용 프로그래밍으로 실제 선택할 만한 언어를 찾고 싶었음. 성능뿐 아니라 AI 도움을 받기 쉬운지, 내가 코드를 읽고 사고하기 편한지도 같이 봤고, AI 덕분에 각 언어를 꽤 깊게 최적화해보는 일종의 관광도 가능했음. 결과는 여기에 정리했고, 특히 F#이 맨 위에 나온 건 꽤 놀라웠음
얼핏 보면 의외지만, 디테일이 핵심이라고 생각함. Lean을 빼면 전반적으로 수치 차이가 아주 극적이지 않고, Chez가 C++보다 2.5배 느린 것도 동적 타입 JIT 언어치곤 꽤 선방한 편임. F#이 이런 작업에서 강한 건 .NET Core 위의 병렬 처리 경험이 특히 성숙하고 무난해서일 가능성이 커 보임. 만약 이 수치가 elapsed time이라면 CPU time 분해도 함께 보면 더 흥미로울 듯함. 또 언어별 병렬화 전략이 조금씩 달라서 완전히 같은 조건 비교는 아님. 예를 들어 F#의 단순한 스레드 분기와 Rust의 Rayon 병렬 iterator는 오버헤드 구조가 다를 수 있음. 결국 Rust와 C++는 저수준 OS 동시성 primitive를 세심하게 다루면 더 빨라질 수도 있지만, 그건 또 다른 종류의 비교가 됨. C나 Haskell의 C FFI 활용을 허용할지도 애매하고, 그래서 이런 비교는 본질적으로 정성적 판단이 많이 섞임. 참고로 Chez 코드는 permutation을 fxvector에 담고 fixnum 전용 연산을 쓰면 boxing/unboxing과 할당을 줄여 더 빨라질 여지도 있어 보임. 관련 문서는 Chez Scheme 객체 문서에 있음
나도 비슷한 글을 여기에 쓴 적 있음. Algol, Lisp, Forth, APL, Prolog에는 동의하지만, 혁신적인 함수형 언어로는 ML보다 약간 앞선 SASL을 넣었고, 객체지향 대표로는 Self보다 먼저 나온 Smalltalk를 골랐음. 여기에 Fortran, COBOL, SNOBOL, Prograph까지 각자 다른 방식으로 판을 바꾼 언어라 생각해 함께 포함했음
나는 이 목록이 더 마음에 듦. 특히 SNOBOL이 들어간 점이 반가움. 직접 써본 적은 없지만, 어릴 때 공공도서관 책 세일에서 이름이 재밌어서 관련 책을 집어 들며 처음 알게 된 언어 중 하나였음. 그전엔 BASIC, Logo, 그리고 Atari BASIC 매뉴얼 예제를 따라 BASIC에서 호출해본 정도의 6502 어셈블리만 조금 알았음. 또 혁신적인 언어 목록에 Fortran과 COBOL, 혹은 그 뿌리인 FLOW-MATIC이 빠지는 건 상상하기 어렵다고 느낌. 참고한 책은 Atari BASIC manual 쪽이었음
왜 Self 대신 Smalltalk가 목록에 들어가지 않았는지 이해가 잘 안 됨. Smalltalk가 더 먼저였고, Alan Kay가 “OOP”라는 이름 자체를 만든 인물이기도 함. ML도 계보상 Lisp의 자식으로 보는 편임
나는 이 논의에 의미론적 계열을 더 추가하고 싶음. Verilog, Petri nets, Kahn process networks, dataflow machines, process calculi, reactive, term rewriting, constraint solver/theorem prover 계열, probabilistic programming 같은 것들임. 또 기존 7분류에 딱 맞지 않지만 실제로는 생산 단계에 가까운 Unison, Darklang, temporal dataflow, DBSP 같은 언어도 떠오름. 다소 반칙처럼 보일 수 있지만, 대부분 von Neumann식 기계 모델과 평행한 계산 모델이기 때문임. 나는 한동안 “우리가 아는 모든 계산 방식, von Neumann 너머” 같은 글을 써보고 싶었음
그런 글이 나오면 정말 기쁘게 읽을 것 같음. 그 사이에 Steve Yegge 글 일부를 다시 떠올리게 됨. 요지는 현대 CS 교육의 대부분이 사실상 von Neumann이 만든 틀 위에 있고, 순차 장치를 택한 것도 당시 제조 비용과 속도 현실을 반영한 선택이었다는 점임. 또 우리가 배우는 기계 구조, 분기, 반복, 서브루틴, 디버깅, 수 체계 변환, 문제 모델링 같은 많은 요소가 이미 그의 작업에서 나왔다는 내용이 인상적이었음. 관련 인용은 archive에 있음
term rewriting 얘기를 보니 대학 때 스프레드시트 소프트웨어를 만들며 수식 파서를 맡았던 기억이 남. 처음엔 일주일 내내 막혔는데, 결국 1+1을 ADD(1,1) 같은 형태로 재작성하면 내가 아는 방식으로 파싱할 수 있다는 걸 깨달았음. 게다가 regex 배우기를 괜히 거부해서 코드가 꽤 기묘해졌고, 동료가 “Andy가 된다니까 건드리지 말자”라고 했던 말이 아직도 기억남. 다른 팀 사람은 regex로 내 코드보다 20배쯤 짧게 끝냈음
“실전 준비가 된 신흥 언어”라는 말에 덧붙이자면, 내 기준엔 아직 완전히 production-ready는 아니어도 실제 현업에서 쓰이는 ChatGPT 같은 시스템도 비슷한 범주로 보임. 이것들을 프로그래밍 언어로 볼지는 논쟁적이지만, 사람이 컴퓨터에 뭘 하라고 지시하는 매개라는 점에선 충분히 그렇게 볼 수 있다고 생각함. 비결정적이라는 점도 프로그래밍 언어의 필수 조건은 아니라고 봄
S9 Scheme에서의 logic programming 예제로는 이 자료가 괜찮았음. 책을 꼭 사지 않아도 코드를 바로 받아볼 수 있고, Simply Scheme 같은 입문서로 기초만 익힌 뒤 적용하면 솔버 구조가 꽤 쉽게 읽힘
TU Delft에서 들었던 “Concepts of programming languages”가 내가 컴공에서 제일 좋아한 과목이었음. C, 함수형 쪽으로 Scala, 프로토타입 개념으로 JavaScript를 배웠고, 덕분에 몇 년 뒤 Elixir를 익힐 때 훨씬 수월했음. 또 Unreal Tournament 에이전트를 GOAL이라는 Prolog 기반 언어로 짜는 수업도 있었음. 나는 오랫동안 Prolog를 어디에 써야 할지 감을 못 잡았는데, 결국 LLM이 생성한 형편없는 Papiamentu 문장을 반복적으로 고치게 만드는 spellcheck를 만드는 데 활용하게 되었음
나도 비슷한 수업을 들었고, 교수는 별로였어도 수강한 걸 아주 잘했다고 느낌. 다른 원형 언어들을 아주 얕게라도 알고 있는 것만으로도 시야가 넓어지고, 어셈블리까지 더하면 더욱 그 효과가 큼. 직접 뭔가 생산적으로 쓰진 못해도, 망치만 들고 모든 문제를 못처럼 보는 함정은 피하게 됨
나도 그 수업에 있었음. Unreal Tournament 쪽은 내가 본 것 중 제일 멋진 수업 중 하나였고, 내 다음 해에 없어졌던 걸로 기억함. 지금은 다들 하는 평범한 AI 수업이 된 듯해 아쉬움. 나는 여전히 Prolog의 좋은 활용처를 많이 찾진 못했지만, GOAL 쪽에는 훨씬 더 큰 인상을 받았음. 그리고 최근에서야 그 구조를 더 “보통의” 언어에서도 재현할 수 있고, 그러면 장점도 많다는 걸 깨달아 조금 허탈했음
나는 “서로 다른 부류의 언어를 배워야 한다”는 주장에 동의함. OCaml을 배우고 나서야 함수가 정말 수학적 함수처럼 느껴졌고, Mathematica는 식 자체를 입력으로 바라보는 습관을 길러줬음. PostScript의 역폴란드 표기법은 단순 산술을 넘어 사고방식을 아예 다시 배선한 느낌이었음. 다만 Java, C#, C++, Python, Ruby 중 무엇을 골라도 상관없다는 주장에는 동의하지 않음. 퀵소트 구현 정도가 목표라면 비슷할 수 있어도, 실제로 뭔가를 만들려는 사람에게는 언어 선택이 밤과 낮만큼 큰 차이를 냄. 3D 게임을 만들고 싶은 사람에게 Ruby를, 탐색적 데이터 과학이나 딥러닝을 하려는 사람에게 Java를 먼저 쥐여주면 의욕이 꺾일 수 있음
나도 아마 Rust로 돈 벌 일은 없겠지만, 배운 걸 전혀 후회하지 않음. Rust는 프로그램 안에서 데이터 소유권을 정말 깊게 생각하게 만들어줬음
이 글을 보니 Bruce Tate의 7 languages in 7 weeks가 떠오름. 나도 그 책으로 Erlang을 처음 접했음. 다만 역사적으로 COBOL과 Fortran을 Algol 계열로 넣는 건 조금 무리라고 느껴지고, 그래도 역사는 본래 어느 정도 환원적 정리라는 점을 상기시켜주긴 함
더 거슬러 올라가 원시적인 분류를 잡는 것도 무리라고 봄. 최초의 assembly 언어들도 명령형이었지만, Algol·Fortran·Cobol을 흥미롭게 만든 건 함수와 다른 고수준 기능으로 복잡한 프로그래밍을 가능하게 했다는 점이었음. 후손은 Algol이 가장 많지만, 최초의 명령형 프로그래밍 언어는 Fortran이라고 생각함
Wikipedia만 보면 Fortran과 Algol이 둘 다 1957년 전후에 개발된 듯한데, 실제로는 어느 쪽이 더 빠른지, 그리고 설계 과정에 서로 영향이나 중첩이 있었는지 궁금했음
차라리 COBOL은 살아 있는 화석처럼 보는 편이 맞지 않나 싶음. 그리고 오늘날의 Fortran은 FORTRAN 계열을 바탕으로 Algol 계보의 특징을 수평 전이받은 언어처럼 느껴짐
Hacker News 의견들
Tufts의 PL 수업에서 명령형, Lisp, ML, Smalltalk 앞의 4개 계열 언어를 각각 미니 버전으로 직접 만들어봤고, 그 과정이 이제 교재로도 나와 있어 반가움. 예전에는 Prolog 파트도 있었는데 빠진 점은 아쉬움
이 글의 분류에서 하나만 고치자면, Ruby는 Algol 계열이라기보다 명확히 객체지향 언어라고 봄. Smalltalk의 영향이 크고, 표준 라이브러리 이름도
map보다collect같은 식으로 그 흔적이 남아 있음. Ruby는 처음부터 끝까지 모든 것이 객체이고, 메서드 호출도 객체에 메시지를 보내는 개념으로 이해하는 쪽이 자연스러움. Python과 자주 비교되지만 진화 경로는 꽤 달랐고, 지금은 비슷한 생태계 지점으로 수렴한 느낌임. 내겐 Ruby가 Python보다 더 포근한 알파카처럼 느껴짐Hello World수준에선 티가 덜 나도, 기본형까지 전부 객체가 되었음. OOP를 싫어하는 사람들에게type(42)와dir(42)를 보여주면 정수조차 객체라는 점을 강조하기 좋음나는 언어 계보에 증명 표현용 언어라는 부류를 하나 더 넣고 싶음. Curry-Howard 대응으로 프로그램이 곧 증명이 되는 계열이며 Lean이 대표적 예시임. 함수형의 하위 분류로 볼 수도 있지만, 주된 목적이 실행보다 검증이라는 점에서 별도 축으로 다룰 가치가 있다고 느낌
최근에 언어 비교 프로젝트를 다시 살펴봤는데, 10개 문자에 대한 3,715,891,200개의 signed permutation을 병렬로 순환 분해하는 벤치마크였음. “원형 언어”보다는 각 패러다임의 현대적 구현체 중 연구용 프로그래밍으로 실제 선택할 만한 언어를 찾고 싶었음. 성능뿐 아니라 AI 도움을 받기 쉬운지, 내가 코드를 읽고 사고하기 편한지도 같이 봤고, AI 덕분에 각 언어를 꽤 깊게 최적화해보는 일종의 관광도 가능했음. 결과는 여기에 정리했고, 특히 F#이 맨 위에 나온 건 꽤 놀라웠음
나도 비슷한 글을 여기에 쓴 적 있음. Algol, Lisp, Forth, APL, Prolog에는 동의하지만, 혁신적인 함수형 언어로는 ML보다 약간 앞선 SASL을 넣었고, 객체지향 대표로는 Self보다 먼저 나온 Smalltalk를 골랐음. 여기에 Fortran, COBOL, SNOBOL, Prograph까지 각자 다른 방식으로 판을 바꾼 언어라 생각해 함께 포함했음
나는 이 논의에 의미론적 계열을 더 추가하고 싶음. Verilog, Petri nets, Kahn process networks, dataflow machines, process calculi, reactive, term rewriting, constraint solver/theorem prover 계열, probabilistic programming 같은 것들임. 또 기존 7분류에 딱 맞지 않지만 실제로는 생산 단계에 가까운 Unison, Darklang, temporal dataflow, DBSP 같은 언어도 떠오름. 다소 반칙처럼 보일 수 있지만, 대부분 von Neumann식 기계 모델과 평행한 계산 모델이기 때문임. 나는 한동안 “우리가 아는 모든 계산 방식, von Neumann 너머” 같은 글을 써보고 싶었음
1+1을ADD(1,1)같은 형태로 재작성하면 내가 아는 방식으로 파싱할 수 있다는 걸 깨달았음. 게다가 regex 배우기를 괜히 거부해서 코드가 꽤 기묘해졌고, 동료가 “Andy가 된다니까 건드리지 말자”라고 했던 말이 아직도 기억남. 다른 팀 사람은 regex로 내 코드보다 20배쯤 짧게 끝냈음TU Delft에서 들었던 “Concepts of programming languages”가 내가 컴공에서 제일 좋아한 과목이었음. C, 함수형 쪽으로 Scala, 프로토타입 개념으로 JavaScript를 배웠고, 덕분에 몇 년 뒤 Elixir를 익힐 때 훨씬 수월했음. 또 Unreal Tournament 에이전트를 GOAL이라는 Prolog 기반 언어로 짜는 수업도 있었음. 나는 오랫동안 Prolog를 어디에 써야 할지 감을 못 잡았는데, 결국 LLM이 생성한 형편없는 Papiamentu 문장을 반복적으로 고치게 만드는 spellcheck를 만드는 데 활용하게 되었음
나는 “서로 다른 부류의 언어를 배워야 한다”는 주장에 동의함. OCaml을 배우고 나서야 함수가 정말 수학적 함수처럼 느껴졌고, Mathematica는 식 자체를 입력으로 바라보는 습관을 길러줬음. PostScript의 역폴란드 표기법은 단순 산술을 넘어 사고방식을 아예 다시 배선한 느낌이었음. 다만 Java, C#, C++, Python, Ruby 중 무엇을 골라도 상관없다는 주장에는 동의하지 않음. 퀵소트 구현 정도가 목표라면 비슷할 수 있어도, 실제로 뭔가를 만들려는 사람에게는 언어 선택이 밤과 낮만큼 큰 차이를 냄. 3D 게임을 만들고 싶은 사람에게 Ruby를, 탐색적 데이터 과학이나 딥러닝을 하려는 사람에게 Java를 먼저 쥐여주면 의욕이 꺾일 수 있음
이 글을 보니 Bruce Tate의 7 languages in 7 weeks가 떠오름. 나도 그 책으로 Erlang을 처음 접했음. 다만 역사적으로 COBOL과 Fortran을 Algol 계열로 넣는 건 조금 무리라고 느껴지고, 그래도 역사는 본래 어느 정도 환원적 정리라는 점을 상기시켜주긴 함
관련해서 예전 HN 토론도 있었음. 이전 논의를 같이 보면 맥락 파악에 도움 됨