요약
순수 객체지향 언어 Pharo 14가 개발 도구 개편과 RISC-V JIT 지원을 담아 나왔습니다.
Pharo는 생성자, 타입 선언, 인터페이스 없이 객체와 메시지만으로 이뤄진 언어이자, 프로그램을 실행한 채로 고치는 라이브 개발 환경입니다. Pharo 팀은 10월 26일 이번 판을 발표하면서, 출시 시기를 봄에서 가을로 옮긴 뒤 처음 내는 판이라고 밝혔습니다.
왜 중요한가
- 출시 주기를 봄(3~5월)에서 가을(9~11월)로 옮긴 첫 판이라 이후 판의 일정 기준이 됩니다.
- 명령줄 테스트와 명령줄 디버거가 생겨 그래픽 환경 밖에서도 코드를 시험하고 고칠 수 있게 됐습니다.
- 가상 머신이 RISC-V용 JIT(실행 중에 기계어로 번역하는 컴파일러)를 지원해 돌릴 수 있는 하드웨어가 늘었습니다.
핵심 내용
- Spotter를 대신할 Pulse와 새 도구 Mission Control을 들였습니다.
- 설정 브라우저를 새로 써서 기본으로 삼고, 메서드 브라우저도 다시 만들었습니다.
- 리팩터링 명령을 드라이버 기반 구조로 옮기고 하나의 명령 등록소에서 관리하게 했습니다.
- 가상 머신은 프레임과 스택 관리를 통합하고 가비지 컬렉션 등 메모리 관리를 손봤습니다.
- 이번 판에는 풀 리퀘스트 978개가 들어갔고, Pharo 13 이후 이슈 616개가 닫혔습니다.
HN 반응
- AI 코딩 도구 덕에 언어 선택이 덜 중요해졌다는 의견과, AI가 부족한 라이브러리를 채워 줘 소수 언어를 고르기 쉬워졌다는 의견이 갈렸습니다.
- 이미지(실행 상태를 통째로 저장하는 방식) 기반 환경은 AI 에이전트와 안 맞는다는 지적에, 실행 중인 이미지에서 코드를 돌릴 도구를 주면 된다는 반론이 나왔습니다.
여기 계신 많은 분들처럼 저도 늘 언어 덕후였습니다. 어셈블리, C(++), Java, 여러 Lisp, Prolog, O'Caml/F#/Haskell 등으로 프로그래밍을 했고 Smalltalk 팬이기도 합니다. (Tektronix ST와 Smalltalk-V는 써 봤지만 Pharo는 써 본 적이 없습니다.)
AI 프로그래밍이 바꿔 놓은 것 하나는, 어떤 프로그래밍 언어를 쓰는지가 훨씬 덜 신경 쓰이게 됐다는 점입니다. 조금 아쉽기도 하지만 대체로는 아주 홀가분합니다. 어떤 문제에 사람인 제가 쓰기 더 편한 언어가 무엇인지 따질 필요도 없고, 제가 아끼는 "애정 언어"에 끌려서 더 평범한 이유로 더 잘 맞는 언어를 놔두고 그쪽을 고를 일도 없으니까요.
저한테는 정반대로 작용했어요. 이제야 드디어 제가 원하는 언어를 마음껏 쓸 수 있거든요! 쓰는 언어에 라이브러리가 없다고요? 걱정 마세요, Opus가 써 줄 테니까요!
그래도 AI 워크플로는 Smalltalk 같은 이미지 기반 환경에는 잘 맞지 않는 것 같습니다.
오히려 반대입니다. SaaS 기반 프로그래밍 환경, 이른바 iPaaS를 쓰면 Smalltalk나 Lisp 이미지를 쓰는 느낌이 정말 듭니다.
아주 큰 차이가 하나 있다면, Smalltalk와 Lisp 이미지는 적어도 백업은 할 수 있었다는 점입니다.
실행 중인 이미지에서 임의의 코드를 실행할 수 있는 도구를 쥐여 주면 얘기가 다릅니다.
적어도 Clojure에서는 nREPL을 통해 그게 아주 훌륭하게 동작합니다.
반대로 AI 에이전트 하네스는 이미지 기반 시스템과 좀 비슷하게 동작하기도 합니다. claude --resume을 떠올려 보세요.
저는 "개념 증명용으로 손으로 짜기엔 너무 귀찮은 끔찍한 접착 코드는 LLM이 쓰면 되지" 하는 마음과 "오, 이걸 Fortran 이랑 JavaScript로 만들면 어떨까?" 하는 마음 사이를 오가고 있어요.
암울한 시대죠.
그런 말씀을 들으니 안타깝습니다. 언젠가 프로그래밍의 즐거움을 다시 찾으시길 바랍니다!
컴퓨터가 체스를 더 잘 둔다고 해서 사람이 체스를 그만두지는 않았습니다. 취미로 하는 프로그래밍에도 여전히 의미가 있습니다.
저는 작은 웹 프로젝트에 Smalltalk를 실제 운영 환경에서 썼던 일을 지금도 흐뭇하게 떠올립니다. Squeak에 Seaside 프레임워크를 썼던 것으로 기억합니다. 이미지 기반 워크플로 덕분에 배포가 놀랄 만큼 쉬웠습니다.
제가 초점을 맞추려던 건 "일을 끝내는 것"이었습니다. 순수하게 즐기려고 프로그래밍하는 거라면 지금도 얼마든지 그렇게 할 수 있습니다. 체스를 직업으로 두는 사람도 있지만, 체스를 두는 사람 대부분은 그렇지 않으니까요.
저한테는 오히려 해방감을 줬습니다. 이제는 여가 시간에 어떤 언어를 붙들고 있을지, 그러다 더 실용적인 걸 놓치지는 않을지 고민하지 않아도 되니까요. 예를 들어 저는 Common Lisp를 좋아하지만, 그걸 다시 익히는 데 쓰는 시간은 늘 실용적인 이득이 될 수도 있었을 다른 무언가를 희생해서 얻는 것 같았습니다. 이제는 어떤 의미에서 모든 프로그래밍 언어가 똑같이 쓸모없어졌습니다.
얼마 전에 큰 이사를 하면서 책장을 꽤 과감하게 정리해야 했습니다. 창고로 보내지 않고 남겨 둔 프로그래밍 책은 Common Lisp와 Prolog 책뿐이었습니다. 계산 자체를 바라보는 방식에 직접 영향을 주지 않는 언어를 배우는 데 시간을 쓰는 건 시간 낭비에 더 가까워 보입니다(물론 진짜로 재미로 프로그래밍한다면 어느 쪽이든 상관없어야 하겠죠).
신나는 소식이네요. 전 세계에서 유일한 Pharo 사용자인 Richard Kenneth Eng 님께 "안녕하세요"라고 인사드리고 싶습니다.
새 프로젝트에 Pharo와 Eiffel 중 뭘 고를지 점점 더 어려워지네요 :)
Eiffel의 어떤 점이 매력적인가요? 진지하게 묻는 겁니다.
Eiffel의 흥미로운 점은 계약에 의한 설계(design by contract)를 지원한다는 것이라고 생각합니다. 이 개념은 Eiffel에서 처음 만들어지고 구현됐습니다.
무결성이 중요한 컴퓨팅에 관심이 충분히 있어서, 지금도 개발 환경을 팔며 사업을 이어 가고 있습니다(커뮤니티 에디션도 있습니다).
Eiffel은 객체 지향 언어 중 맨 처음으로 널이 될 수 없는 참조(non-nullable reference)를 도입한 언어이기도 한데, HN의 많은 분들은 이걸 더 유행하는 다른 언어의 공으로 돌릴 게 분명합니다.
ENVY0를 안 써 본 사람이 있군요.
이미지 기반 시스템의 버전 관리와 SCM은 수십 년 전부터 문제가 아니었습니다. 그런데도 역사에서 배우지 못하고, 자기들이 무언가의 해법을 맨 처음 내놓았다고 생각하는 사람들이 계속 나타납니다.
특히 프로그래밍에 대한 이해가 "UNIX가 하는 방식"이 전부인 사람들이 그렇습니다.
제가 아는 Pharo 사용자만 최소 5명이고, 그중 한 명은 그것에 관한 책까지 썼습니다(나머지 4명을 위해서요 :P). 그분들은 대학 연구실 소속이었고 저희 학생들에게 Pharo를 쓰게 했습니다. 좋은 점이 있다는 건 알겠는데, 솔직히 크로스핏이나 Vim 같은 느낌이 들어요. 열광하는 소수의 사용자가 다른 모두에게 이게 얼마나 대단한지 설득하려 드는 거죠. (Oscar 님 등 여러분, 죄송합니다.)
Vim 모션을 익히는 건 정말로 대단하고, Vim 자체를 쓰지 않더라도 들인 노력만큼 값어치가 있습니다.
Lisp 홍보처럼 들리네요. 다만 Lisp의 경우에는 그 말이 실제로 맞습니다.
저는 더 Smalltalk다운 대안으로 Cuis Smalltalk( https://cuis.st )를 추천합니다. 벡터 그래픽 기반 렌더링 엔진 덕분에 보기에도 훨씬 낫습니다.
모프(morph)도 벡터 기반이지 않았나요? Claude의 도움으로 되살린 작은 "게임" 하나가 여기 있습니다.
https://github.com/edragoev1/aquarium-for-squeak
에이전트의 도움을 받는 Smalltalk의 현재 상태를 아시는 분 계신가요? Pharo든 다른 것이든요. 에이전트가 실행 중인 프로그램을 직접 조작할 수 있으니 직관적으로는 천생연분 같은데, 한편으로는 Smalltalk 학습 데이터가 거의 없을 것 같기도 합니다.
저는 에이전트의 도움을 받는 맞춤형 UI 개발을 위해 Glamorous Toolkit[1]을 한동안 탐색해 봤습니다. 작업 중인 인터페이스를 그때그때 고쳐 가는 emacs 방식으로요. 꽤 좋은 경험이었고, 내장된 데이터 탐색 기능은 최고 수준이었습니다.
아이러니하게도 유튜브에서 Glamorous Toolkit 영상을 보고 나니 Geoffrey Litt의 동적 문서 강연[2]이 추천에 떴고, 그 강연 끝에서 bb[3]를 알게 됐는데 GT보다 에이전트 연동이 훨씬 낫습니다. @thelazydogsback 님 말씀처럼 에이전트가 있으면 프로그래밍 언어는 덜 중요해집니다.
[1] https://gtoolkit.com/
[2] https://www.youtube.com/watch?v=MccJdr61xnc
[3] https://getbb.app/
약 1년 전쯤 Tudor Girba 님과 이야기하면서 AI에 대한 의견이 어떤지 물어본 적이 있습니다. 왠지 그분의 세계관과 충돌할 거라고 믿었거든요. 그런데 그분이 LLM이 GT 안을 돌아다니며 도구를 만들고 다듬는 놀라운 데모를 몇 개 보여 주셨습니다. 지금 같은 에이전트형 플러그인 기반 IDE가 나오기 한참 전의 일입니다.
Girba 님의 "언어 = UI = 소프트웨어 = 데이터"라는 정말 멋진 발상은 다른 어디에서도 쓰이지 않는(아마 Chris Granger의 Eve 정도만 예외일) AI 측면의 큰 강점이 있다고 생각합니다. 데이터를 다루면서 그 위에서 실시간으로 만들어 가는 건 BB보다 훨씬 낫습니다.
저도 동의합니다. 원리 면에서는 굉장한 개념이고, Girba 님은 디스코드에서 사람들을 친절하게 맞아 주십니다. GT에서 에이전트와 작업하면 에이전트가 데이터를 그냥 살펴보고 그래픽 프레임워크로 표현할 방법을 알아냅니다.
하지만 실제로는, 적어도 지금은 생태계의 압도적인 규모 덕분에 bb가 이깁니다. 저는 GT 안에서 곧바로 obsidian과 heptabase를 합친 짬뽕 같은 에디터 인터페이스를 만들고 있었습니다. 어느 정도는 동작했어요. 놀라운 점은 모든 것이 단 하나의 표현만 가진다는 겁니다. 텍스트로 표시된 윈도 위치는 같은 데이터이기 때문에 위젯 사이에서 자동으로 양방향 바인딩이 됩니다. 하지만 에이전트가 모든 걸 해 주는데도 두 가지 문제가 슬금슬금 올라옵니다.
첫째, JS/TS에서는 이런 바인딩 문제가 이미 천 배는 더 잘 해결돼 있습니다. 콜백으로 공유 메모리를 흉내 내도 에이전트가 길을 잃지 않습니다. GT에서는 커서를 움직이다가 위젯 표현을 소스 표현으로 언제 바꿀지, 위젯을 언제 되돌릴지 정해야 합니다. 일정 시간 지연 뒤일까요? 줄을 바꾼 뒤일까요? 텍스트에서 벗어난 뒤일까요? 공백 앞일까요, 뒤일까요? npm 어딘가에 이런 질문에 모두 답해 놓은 패키지가 있고, 표도 지원하며, 성능도 좋습니다. GT가 마법 같은 공유 메모리 표현으로 해내는 그 2% 정도는 못 하지만(그래서 TS에서 smalltalk로의 이식도 간단하지 않습니다), 잘 최적화된 코드로 그냥 덮어 버릴 수 있습니다.
둘째, GT는 데이터 구조를 다시 해석하고 다시 렌더링하느라 정말 느려졌습니다. bb가 동적 코드를 다시 불러오는 방식이 아무리 "지저분하다" 해도 런타임이 워낙 잘 최적화돼 있어서, 저는 bb에서 마크다운 노드를 GPU로 가속하고 싶었는데 알고 보니 이미 가속되고 있었습니다.
아이러니하게도 저도 답글을 달던 날 아침에 똑같은 생각을 하고 있었습니다. JS가 런타임에 제공하는 데이터의 양을 생각하면, 라이브 시스템에 정말 Smalltalk가 필요할까 하고요. 전적으로 동의합니다.
제 안의 무언가는 BB가 더 나은 GT가 될 수 있다는 걸 받아들이고 싶지 않은가 봅니다!
bb 생태계를 시작할 때 참고할 만한 출발점이 있을까요? 이를테면 괜찮은 기존 컴포넌트나 관행 같은 것요.
저는 한동안 가끔씩 써 오긴 했는데, 바퀴를 다시 발명하는 걸 싫어하기도 하고(다른 일로 바쁘기도 했고) 본격적인 커스터마이징까지는 못 해 봤습니다. 그런데 지금은 Warp와 Zed의 Delta(아주 멋진 디자인입니다)를 섞은 듯한 걸 찾고 있고, bb로 그걸 얻을 수 있을지도 모르겠습니다.
수정: 플러그인 마켓플레이스는 지난번에 봤을 때보다 훨씬 둘러보기 편해졌네요. 사람들이 자기 설정을 뽐낼 수 있는 갤러리가 있으면 좋겠습니다. 제가 하나 만들어 볼까요...
저는 그냥 입력창에 원하는 기능을 말 그대로 타이핑합니다. 처음에는 "draw.io 통합해 줘" 같은 기능 탐색이었고, 금방 끝났지만 실제로 쓴 적은 한 번도 없습니다.
그다음에는 진짜 쓸모 있는 걸 시켰습니다. PDF 스캔본이 든 이 디렉터리를 찾아서, 파일을 훑어보고 미리 보고 lmstudio 서버에 질의하고, 내용을 바탕으로 PDF 이름을 자동으로 바꿔 주는 인터페이스를 만들어 달라는 식으로요.
또 하나는 특정 파일 구성 구조를 가진 원격 머신에 ssh로 접속해서 미리 보기 갤러리를 보여 달라는 것이었습니다.
복잡한 건 하나도 없지만 직접 만들 엄두는 안 나던 것들입니다. emacs였다면 썼을 만한 것이기도 하지만(미리 보기 기능은 emacs의 dired-preview-mode와 비슷합니다), 그래픽 인터페이스가 성능은 더 낫습니다.
아이러니하게도 발전해 온 과정을 보면 Emacs보다는 Smalltalk/Lisp 머신 쪽에 더 가깝습니다. :)