XML은 여러 언어에서 제대로 파싱하려면 비용이 많이 드는 포맷임
실제로 표준에 가깝게 구현하려면 libxml2, expat, Xerces 같은 세 가지 오픈소스 구현체에 의존해야 함
SGML 계열 언어의 핵심은 “리스트”를 1급 객체로, 중첩을 2급 객체로 취급한다는 점이며, 태그 이름과 속성이라는 두 축으로 메타데이터를 추가할 수 있음
XML은 DSL로서 여전히 유용하지만, 진짜 XML을 쓰려면 “cheap”이라는 단어는 버려야 함
또, 선언형 DSL을 명령형 수식처럼 보이게 만들 수도 있음. 예를 들어 totalOwed = totalTax - totalPayments 같은 식은 XML DSL과 동일한 의미를 가질 수 있음
METAFONT 같은 언어가 이런 접근을 보여줌 (예시 링크)
XML이 반복해서 같은 실수를 하는 걸 자주 봄 포맷에 기능을 많이 넣을수록 파싱이 어려워진다는 단순한 진리를 잊는 경우가 많음
JSON이 인기 있는 이유는 기능이 적어서 파싱이 쉽기 때문임
반면 XML은 attributes, namespaces, CDATA, DTDs 등 너무 많은 걸 넣었음
SQLite를 교환 포맷으로 쓰자는 논의도 있었지만, 그것도 XML처럼 복잡해질 위험이 있음
CSV가 단순해서 여전히 사랑받는 이유도 여기에 있음
요즘 JSON에 주석이나 타입 정보를 억지로 넣는 시도는 나쁜 XML 속성의 재현임
글쓴이로서 동의함
선언형 명세를 수학식처럼 보이게 만드는 건 가능하지만, 그건 결국 새 언어를 만드는 일임
그렇게 되면 파서를 모든 환경에 이식해야 하는 문제가 생김
연산자 우선순위나 switch 표현 같은 문법적 결정도 직접 해야 하고, 결국 복잡도가 폭증함
그래서 “cheap”이란 단어를 쓴 이유가 바로 여기에 있음 — 이미 모든 환경에 파서와 툴링이 존재하는 포맷을 쓰는 게 비용 절감임
표현력은 줄지만, 소규모 팀에게는 현명한 선택임
엔터프라이즈 Java에서 XML을 많이 써봤는데, 메모리와 CPU 병목의 주범이었음
XML은 절대 cheap하지 않음
SGML의 핵심은 요소의 정규식 기반 콘텐츠 모델임
단순히 리스트 구조만이 아니라, BNF처럼 문법 생산 규칙을 정의할 수 있음
“XML proper”이 아니라 “XML lookalike”라고 한 건 너무 까다로운 표현 같음
모든 XML 기능을 쓰지 않아도 XML은 여전히 XML임
마치 컵홀더가 없다고 스쿨버스를 “버스 흉내”라고 부르는 것과 같음
XML 대신 eDSL을 잘 지원하는 언어를 쓰면 된다고 생각함
Haskell, OCaml, Scala 같은 언어는 applicative나 arrow 같은 개념으로 병렬 계산을 쉽게 표현할 수 있음
JavaScript에서도 .reduce() 대신 sum 같은 추상화를 만들면 됨
XML DSL을 만들면 결국 병렬화, 가독성, 새로운 문법 발명 같은 문제를 다시 풀어야 함
복잡한 도메인에서는 Greenspun의 10번째 법칙에 부딪힐 가능성이 큼
하지만 Haskell 같은 언어는 배우기 어렵다는 문제가 있음
30년 경력의 개발자라도 진입 장벽이 높다고 느낌
Raku도 좋은 선택임
Haskell 기반으로 시작했고, 내장 Grammar와 함수형 스타일을 지원해서 DSL 작성에 유리함
HTML! (농담 섞인 짧은 반응)
Lisp도 가능함
S-expression을 보면 XML이 얼마나 장황하고 무겁게 느껴지는지 바로 알 수 있음
JSON 구조를 좀 더 잘 설계할 수 있음
각 노드를 타입 키 하나와 배열 값으로 구성하면 S-expression처럼 표현 가능함
이렇게 하면 스트리밍 파싱이 가능하고, 타입을 먼저 알 수 있음
대규모 데이터셋에서 유용함
JSON은 XML보다 훨씬 단순하고 파싱 비용이 낮음
XML은 태그 짝 맞추기, 속성 처리 등 상태 관리가 복잡하지만
JSON은 {}, []만 맞추면 됨
이런 단순함이 누적되어 지연 시간 감소로 이어짐
하지만 JSON의 따옴표가 너무 많아서 시각적 노이즈처럼 느껴짐
개인적으로는 Clojure의 EDN이 더 깔끔하다고 생각함
이런 JSON 구조는 미학적으로 퇴화된 형태라고 느낌
태그가 필요한 데이터라면 그에 맞는 표현 방식을 쓰는 게 낫다고 생각함
The Lost Art of XML 글이 더 흥미로웠음
웹 개발 도구의 상당수가 XML이 브라우저 전쟁에서 패배한 결과로 생겨났다는 관점이 인상적이었음
하지만 “XML이 버려진 건 JavaScript가 이겼기 때문”이라는 주장은 동의하기 어려움
브라우저는 원래 XML도 지원했음 (AJAX의 X가 XML임)
단지 개발자들이 XML을 싫어했을 뿐임
XML은 과도한 설계와 복잡성 때문에 외면받았다고 생각함
예전 XML API 시대를 직접 겪어본 입장에서, XML은 정말 고통스러웠음
각 언어마다 인코더/디코더를 따로 만들어야 했고, 유지보수도 힘들었음
JSON은 단순히 배열과 객체로 매핑되어서 언어 간 호환성이 뛰어남
XML 스키마 설계 회의에 시간을 낭비하던 시절을 생각하면, JSON은 Prettier가 탭 vs 스페이스 논쟁을 끝낸 것처럼 API 설계를 단순화했음
결국 “복잡한 걸 배우기 싫다”는 태도에서 출발했지만, 시간이 지나면 다시 기능이 필요해지는 패턴임
폴란드 세무당국은 XML을 사랑함
하지만 그들의 XML은 사람이 읽을 수 없을 정도로 난해함
필드명이 P_19N 같은 식으로 되어 있고, 실제 의미를 알기 위해 스키마를 봐야 함
심지어 법 조항 번호까지 들어감
아이러니하게도 VAT 법안 작성자가 현재 세무 컨설팅을 하고 있음
나는 S-expression 기반 DSL을 직접 사용 중임
WebAssembly 기반 데스크톱 브라우저 런타임에서 HTML과 CSS 역할을 하며,
문서 동기화 문제를 해결하는 자체 마크업 언어에도 재활용함
관련 예시는 CanvasUI 예제 코드와 스타일 파일, 문서화 도구에서 볼 수 있음
S-expression은 파서 구현이 매우 단순해서 인터뷰 문제로도 썼었음
지원자가 직접 간단한 언어를 구현해내는 순간의 반응이 인상적이었음
XML은 DSL이라기보다 일반 파서/렉서 도구임
텍스트를 AST로 변환할 뿐, 실제 DSL은 그 위에 정의하는 명세임
기능이 많고 복잡하지만, 툴링 생태계가 풍부하다는 장점이 있음
수동 작성보다는 생성된 텍스트 처리에 적합함
XSD 스키마 검증이 내장되어 있어서 문서의 정합성을 즉시 확인할 수 있음
자동화 도구를 쓰지 않고 XML이 어렵다고 불평하는 건, 디스어셈블러 없이 바이너리를 다루는 것과 같음
하지만 스키마 검증만으로 내용의 올바름을 보장할 수는 없음
타입 체크가 프로그램의 정확성을 보장하지 않는 것과 같은 이치임
XSD는 유용하지만 복잡하고 제약이 많음
그래서 일부 XML 커뮤니티는 RELAX-NG로 옮겨갔지만 완전히 대체되진 못했음
어떤 작업이 XSD 검증을 꼭 필요로 하는지 궁금함
XML은 마크업 언어로는 괜찮고, 데이터 교환 포맷으로도 쓸 만하지만, 프로그래밍 언어로 쓰면 끔찍함
JSON도 마찬가지로, 데이터 교환에는 좋지만 언어로 쓰면 후회함
Ansible처럼 YAML 기반 언어들이 그 예임
반면 Lisp의 S-expression은 JSON과 비슷한 구조이면서도 훌륭한 언어로 발전했음
XML의 문제는 XML 자체보다 좋은 XML을 생성하기 어려운 점임
표준이 복잡하고, 생산자마다 표현 방식이 달라서 일관성이 떨어짐
JSON은 이 표준편차가 훨씬 작음
금융기관의 XML을 보면 절망감이 들 정도임
XML의 문제는 결국 툴링의 느림과 불완전한 검증기 때문임
데이터 표현의 복잡성보다 도구 품질이 더 큰 병목이었음
사실 문제는 “좋은 XML”보다 “엉망인 XML”을 너무 쉽게 만들 수 있었다는 점임
그래서 커뮤니티는 네임스페이스, 검증, 변환, 시맨틱 웹 등으로 상호운용성을 확보하려고 노력했음
완벽한 합의가 불가능한 환경에서도 일을 진행하기 위한 타협이었음
Hacker News 의견들
XML은 여러 언어에서 제대로 파싱하려면 비용이 많이 드는 포맷임
실제로 표준에 가깝게 구현하려면 libxml2, expat, Xerces 같은 세 가지 오픈소스 구현체에 의존해야 함
SGML 계열 언어의 핵심은 “리스트”를 1급 객체로, 중첩을 2급 객체로 취급한다는 점이며, 태그 이름과 속성이라는 두 축으로 메타데이터를 추가할 수 있음
XML은 DSL로서 여전히 유용하지만, 진짜 XML을 쓰려면 “cheap”이라는 단어는 버려야 함
또, 선언형 DSL을 명령형 수식처럼 보이게 만들 수도 있음. 예를 들어
totalOwed = totalTax - totalPayments같은 식은 XML DSL과 동일한 의미를 가질 수 있음METAFONT 같은 언어가 이런 접근을 보여줌 (예시 링크)
XML이 반복해서 같은 실수를 하는 걸 자주 봄
포맷에 기능을 많이 넣을수록 파싱이 어려워진다는 단순한 진리를 잊는 경우가 많음
JSON이 인기 있는 이유는 기능이 적어서 파싱이 쉽기 때문임
반면 XML은 attributes, namespaces, CDATA, DTDs 등 너무 많은 걸 넣었음
SQLite를 교환 포맷으로 쓰자는 논의도 있었지만, 그것도 XML처럼 복잡해질 위험이 있음
CSV가 단순해서 여전히 사랑받는 이유도 여기에 있음
요즘 JSON에 주석이나 타입 정보를 억지로 넣는 시도는 나쁜 XML 속성의 재현임
글쓴이로서 동의함
선언형 명세를 수학식처럼 보이게 만드는 건 가능하지만, 그건 결국 새 언어를 만드는 일임
그렇게 되면 파서를 모든 환경에 이식해야 하는 문제가 생김
연산자 우선순위나 switch 표현 같은 문법적 결정도 직접 해야 하고, 결국 복잡도가 폭증함
그래서 “cheap”이란 단어를 쓴 이유가 바로 여기에 있음 — 이미 모든 환경에 파서와 툴링이 존재하는 포맷을 쓰는 게 비용 절감임
표현력은 줄지만, 소규모 팀에게는 현명한 선택임
엔터프라이즈 Java에서 XML을 많이 써봤는데, 메모리와 CPU 병목의 주범이었음
XML은 절대 cheap하지 않음
SGML의 핵심은 요소의 정규식 기반 콘텐츠 모델임
단순히 리스트 구조만이 아니라, BNF처럼 문법 생산 규칙을 정의할 수 있음
“XML proper”이 아니라 “XML lookalike”라고 한 건 너무 까다로운 표현 같음
모든 XML 기능을 쓰지 않아도 XML은 여전히 XML임
마치 컵홀더가 없다고 스쿨버스를 “버스 흉내”라고 부르는 것과 같음
XML 대신 eDSL을 잘 지원하는 언어를 쓰면 된다고 생각함
Haskell, OCaml, Scala 같은 언어는 applicative나 arrow 같은 개념으로 병렬 계산을 쉽게 표현할 수 있음
JavaScript에서도
.reduce()대신sum같은 추상화를 만들면 됨XML DSL을 만들면 결국 병렬화, 가독성, 새로운 문법 발명 같은 문제를 다시 풀어야 함
복잡한 도메인에서는 Greenspun의 10번째 법칙에 부딪힐 가능성이 큼
하지만 Haskell 같은 언어는 배우기 어렵다는 문제가 있음
30년 경력의 개발자라도 진입 장벽이 높다고 느낌
Raku도 좋은 선택임
Haskell 기반으로 시작했고, 내장 Grammar와 함수형 스타일을 지원해서 DSL 작성에 유리함
HTML! (농담 섞인 짧은 반응)
Lisp도 가능함
S-expression을 보면 XML이 얼마나 장황하고 무겁게 느껴지는지 바로 알 수 있음
JSON 구조를 좀 더 잘 설계할 수 있음
각 노드를 타입 키 하나와 배열 값으로 구성하면 S-expression처럼 표현 가능함
이렇게 하면 스트리밍 파싱이 가능하고, 타입을 먼저 알 수 있음
대규모 데이터셋에서 유용함
JSON은 XML보다 훨씬 단순하고 파싱 비용이 낮음
XML은 태그 짝 맞추기, 속성 처리 등 상태 관리가 복잡하지만
JSON은
{},[]만 맞추면 됨이런 단순함이 누적되어 지연 시간 감소로 이어짐
하지만 JSON의 따옴표가 너무 많아서 시각적 노이즈처럼 느껴짐
개인적으로는 Clojure의 EDN이 더 깔끔하다고 생각함
이런 JSON 구조는 미학적으로 퇴화된 형태라고 느낌
태그가 필요한 데이터라면 그에 맞는 표현 방식을 쓰는 게 낫다고 생각함
The Lost Art of XML 글이 더 흥미로웠음
웹 개발 도구의 상당수가 XML이 브라우저 전쟁에서 패배한 결과로 생겨났다는 관점이 인상적이었음
하지만 “XML이 버려진 건 JavaScript가 이겼기 때문”이라는 주장은 동의하기 어려움
브라우저는 원래 XML도 지원했음 (AJAX의 X가 XML임)
단지 개발자들이 XML을 싫어했을 뿐임
XML은 과도한 설계와 복잡성 때문에 외면받았다고 생각함
예전 XML API 시대를 직접 겪어본 입장에서, XML은 정말 고통스러웠음
각 언어마다 인코더/디코더를 따로 만들어야 했고, 유지보수도 힘들었음
JSON은 단순히 배열과 객체로 매핑되어서 언어 간 호환성이 뛰어남
XML 스키마 설계 회의에 시간을 낭비하던 시절을 생각하면, JSON은 Prettier가 탭 vs 스페이스 논쟁을 끝낸 것처럼 API 설계를 단순화했음
결국 “복잡한 걸 배우기 싫다”는 태도에서 출발했지만, 시간이 지나면 다시 기능이 필요해지는 패턴임
폴란드 세무당국은 XML을 사랑함
하지만 그들의 XML은 사람이 읽을 수 없을 정도로 난해함
필드명이
P_19N같은 식으로 되어 있고, 실제 의미를 알기 위해 스키마를 봐야 함심지어 법 조항 번호까지 들어감
아이러니하게도 VAT 법안 작성자가 현재 세무 컨설팅을 하고 있음
나는 S-expression 기반 DSL을 직접 사용 중임
WebAssembly 기반 데스크톱 브라우저 런타임에서 HTML과 CSS 역할을 하며,
문서 동기화 문제를 해결하는 자체 마크업 언어에도 재활용함
관련 예시는 CanvasUI 예제 코드와 스타일 파일, 문서화 도구에서 볼 수 있음
지원자가 직접 간단한 언어를 구현해내는 순간의 반응이 인상적이었음
XML은 DSL이라기보다 일반 파서/렉서 도구임
텍스트를 AST로 변환할 뿐, 실제 DSL은 그 위에 정의하는 명세임
기능이 많고 복잡하지만, 툴링 생태계가 풍부하다는 장점이 있음
수동 작성보다는 생성된 텍스트 처리에 적합함
XSD 스키마 검증이 내장되어 있어서 문서의 정합성을 즉시 확인할 수 있음
자동화 도구를 쓰지 않고 XML이 어렵다고 불평하는 건, 디스어셈블러 없이 바이너리를 다루는 것과 같음
하지만 스키마 검증만으로 내용의 올바름을 보장할 수는 없음
타입 체크가 프로그램의 정확성을 보장하지 않는 것과 같은 이치임
XSD는 유용하지만 복잡하고 제약이 많음
그래서 일부 XML 커뮤니티는 RELAX-NG로 옮겨갔지만 완전히 대체되진 못했음
어떤 작업이 XSD 검증을 꼭 필요로 하는지 궁금함
XML은 마크업 언어로는 괜찮고, 데이터 교환 포맷으로도 쓸 만하지만, 프로그래밍 언어로 쓰면 끔찍함
JSON도 마찬가지로, 데이터 교환에는 좋지만 언어로 쓰면 후회함
Ansible처럼 YAML 기반 언어들이 그 예임
반면 Lisp의 S-expression은 JSON과 비슷한 구조이면서도 훌륭한 언어로 발전했음
XML의 문제는 XML 자체보다 좋은 XML을 생성하기 어려운 점임
표준이 복잡하고, 생산자마다 표현 방식이 달라서 일관성이 떨어짐
JSON은 이 표준편차가 훨씬 작음
금융기관의 XML을 보면 절망감이 들 정도임
XML의 문제는 결국 툴링의 느림과 불완전한 검증기 때문임
데이터 표현의 복잡성보다 도구 품질이 더 큰 병목이었음
사실 문제는 “좋은 XML”보다 “엉망인 XML”을 너무 쉽게 만들 수 있었다는 점임
그래서 커뮤니티는 네임스페이스, 검증, 변환, 시맨틱 웹 등으로 상호운용성을 확보하려고 노력했음
완벽한 합의가 불가능한 환경에서도 일을 진행하기 위한 타협이었음