- 과거 Ada 개발 환경에서는 코드 포매팅 문제를 이미 해결한 경험이 있음
- 개발자들은 DIANA 중간 표현(IR) 형태로 코드를 다뤘고, 각자가 원하는 프리티프린팅 설정으로 뷰잉을 했음
- 현대에도 linter나 포매팅 정책 등으로 반복되는 비효율과 논쟁이 존재함
- 당시 Rational R1000 워크스테이션은 혁신적인 개발 환경과 기능을 제공함
- Coding 포매팅 문제에서 한 세대 전 방식을 참고해 오늘의 개발 관행 변화를 위한 아이디어를 제안함
코드 포매팅 논쟁 – 1980년대의 해결책
- 필자는 고등학교 시절 Ada 컴파일러 작업에 참여했던 컴퓨터 사이언스 교사, Mr. Paige와의 경험을 언급함
- 2016년에 linter 툴 세팅에 불편을 호소하며 “이런 문제를 왜 여전히 겪어야 하냐”고 질문했을 때, 이미 40여 년 전에 이 문제가 해결된 경험을 소개받음
Ada와 DIANA의 등장
- Ada 개발자들은 텍스트 소스코드를 저장하는 대신, DIANA(Descriptive Intermediate Attributed Notation for Ada) 라는 중간 표현을 이용함
- 각 개발자는 자신만의 프리티프린팅 설정으로 소스를 원하는 방식으로 조회할 수 있었음
- 포매팅 논쟁이나 linter 이슈가 존재하지 않았으며, 에디터에서는 프로그램 트리를 직접 수정할 수 있었음(현대의 projectional editing과 유사함)
Rational R1000 – 선구적 개발 환경
-
Rational R1000 워크스테이션은 증분 컴파일, 정적 분석, 버전 관리, 디버깅 등 다양한 고급 기능을 내장함
- DoD 등 정부 프로젝트, 국제우주정거장(ISS), F-22 전투기 등 중요한 SW 개발에 활용되었으며 UML의 탄생에도 이바지함
- Grady Booch에 따르면, R1000은 DIANA 기반의 머신으로 소스코드를 저장하지 않고 DIANA 트리의 프리티프린팅만을 사용함
DIANA 기반 개발의 이점
- 포매팅 논쟁이나 linter 세팅, 에디터 환경 통일이 필요 없었음
- 하드웨어 가속으로 증분 컴파일, 손쉬운 리팩토링(용어 미정), 빠른 통합 등 혁신적 개발 경험 제공
- 개발 효율과 대형 시스템 작업에 중요한 영향을 끼쳤음
오늘날의 시사점
- 하드웨어 가속 컴파일은 덜 중요하지만, 포매팅 문제 해결은 여전히 미흡한 상황임
- 주류 방식이 projectional editing이나 라이브 환경은 아니지만, 과거의 접근법처럼 더 효율적이고 논쟁이 적은 개발 관행의 도입을 고민할 시점임
참고 자료
- 필자는 이 주제를 조사하며 R1000 관련 다양한 문서와 기술 보고서를 인용함