▲

GN⁺: Enlightenmentware - 나를 일깨워주는 소프트웨어들

 (mmapped.blog)
16P by neo 6달전 | favorite | 댓글 5개
  • UNIX, Git, Emacs, Boost.Graph, Bazel
  • 프로그래머로서 매일 소프트웨어 도구와 상호작용하는데, 대부분의 도구는 그저 작업을 겨우 수행하는데만 쓰임
  • 때로는 단순한 유용성을 넘어서 상상력을 자극하고 새로운 가능성을 열어주며 시스템 설계 방식에 영향을 미치는 소프트웨어를 발견함
  • 이런 소프트웨어를 ‘깨달음 소프트웨어’(Enlightenmentware)라고 부름
  • 프로그래머에게 가장 흔한 깨달음의 원천은 사용하는 프로그래밍 언어임. 취미로 배우는 언어 포함
  • MASM, C, Prolog, Idris와 같은 프로그래밍 언어를 다루면서 많은 깨달음을 경험했음
  • 언어 학습이 사고력 확장에 미치는 영향은 이미 오래전부터 알려진 사실이기 때문에 이글에서는 언어에 초점을 맞추기 보다는 깨달음을 주는 소프트웨어에만 집중하기로 함

UNIX

unix는 사용자 친화적임—단지 친구를 가리는 것뿐임.

익명, "Art of unix Programming" by Eric S. Raymond

  • 2008년, 대학에서 공부하면서 첫 프로그래밍 직업을 찾기 시작함.
  • 대부분의 구인 공고에서 UNIX와 _socket_에 대한 지식을 요구했음.
  • 대학 커리큘럼에 unix나 운영체제에 대한 강의가 없어서 독학으로 공부하기로 결심함.
  • Andrey Robachevsky 등의 "The unix Operating System" 책을 통해 unix의 세계에 입문함.
  • Mandriva Linux를 설치하면서 unix 환경을 탐험하게 됨.
  • 이후로 unix는 모든 삶의 단계에서 함께 했음.
  • 대부분의 소프트웨어가 unix 환경에서 작동하며, 여전히 "Advanced Programming in the unix Environment" 책을 참고함.

Git

git으로 발을 쏘는 것은 쉽지만, 이전 발로 되돌아가 현재 다리와 봉합(merge)하는 것도 쉬움.

Jack William Bell

  • 2009년 초, Rational ClearCase를 사용하여 버전 관리 시스템을 처음 접함.
  • ClearCase는 매우 혼란스러웠고, 최소한의 요구 사항만 처리함.
  • 이후 Subversion을 사용하게 되었고, "Version Control with Subversion" 책을 통해 학습함.
  • Subversion은 이해하기 쉽고 사용하기 쉬웠지만, 개인 프로젝트에는 불편했음.
  • 그 후 Git을 발견함.
  • Git은 학습 곡선이 가파르고 혼란스러웠지만, ClearCase와는 다른 종류의 혼란이었음.
  • Git은 버전 관리를 사용하는 마찰을 제거하여 모든 가치 있는 것을 버전 관리할 수 있게 함.
  • Git의 설계는 분산 시스템, 비순환 그래프, 콘텐츠 주소 지정 저장소의 우아한 혼합으로 매력적이었음.
  • Git의 내부를 학습하는 것이 재미있어서 다른 버전 관리 시스템에도 관심을 가지게 됨.
  • Git의 주요 단점은 스냅샷 지향 접근 방식으로 인해 병합을 이해하기 어렵게 만드는 것임.

Emacs

어떤 텍스트 편집기도 파일을 저장할 수 있지만, Emacs만이 영혼을 구할 수 있음.

Per Abrahamsen

  • Turbo Pascal 7.0의 친근한 파란색 창에서 첫 프로그램을 편집함.
  • 대학에서는 Pascal을 사용하여 프로그래밍을 배웠고, 이후 C++와 Java를 사용함.
  • 첫 프로그래밍 직장에서 NEdit를 사용했지만, Vim과 Emacs에 관심을 가지게 됨.
  • Vim은 음악 악기를 연주하는 것처럼 도전적이지만 재미있었음.
  • Emacs는 Lisp 기계로서 텍스트 편집과 창 관리 기능을 제공함.
  • Emacs의 내부 구조는 깨끗하고 잘 조직되어 있으며, 문서화도 잘 되어 있음.
  • Emacs Lisp을 사용하여 확장하는 것이 다른 편집기보다 훨씬 쉬움.

Boost.Graph

나는 재사용 가능한 코드에 대한 유행에 강한 편견을 가지고 있음. "재편집 가능한 코드"가 블랙박스나 툴킷보다 훨씬 낫다고 생각함.

Donald Knuth, Andrew Binstock과의 인터뷰

  • 2013년 새해 전야에 Boost Graph Library를 읽음.
  • 대부분의 알고리즘 라이브러리는 특정 데이터 표현에 의존하여 기존 프로젝트에 통합하기 어렵게 만듦.
  • Boost.Graph 라이브러리는 제네릭 프로그래밍을 사용하여 이 문제를 해결함.
  • 라이브러리를 실제로 사용한 적은 없지만, 설계는 STL 디자인과 제네릭 프로그래밍에 대한 이해를 깊게 해줌.

Bazel

make가 기대한 대로 작동하지 않는다면, makefile이 잘못되었을 가능성이 큼.

Adam de Boor, "PMake—A Tutorial"

  • 2009년, 연구 프로젝트를 위해 첫 Makefile을 작성함.
  • make의 복잡성 때문에 더 나은 도구를 갈망하게 됨.
  • 다양한 빌드 시스템을 시도했지만, 모두 불만족스러웠음.
  • 2016년, Google에 입사하여 blaze를 사용하게 됨.
  • Bazel은 빌드 시스템의 마지막 퍼즐 조각이었음.
  • Bazel은 빠르고, 정확하며, 사용하기 쉽고, 언어에 구애받지 않음.

결론

  • 좋은 enlightenmentware의 공통점:
    • 깊은 문제를 해결하며, 일상적으로 직면하는 문제를 다룸.
    • 작은 표면적에 많은 볼륨을 담고 있음.
    • 내부를 탐험하도록 초대하고 격려함.

GN⁺의 의견

  • UNIX의 중요성: UNIX는 많은 프로그래밍 환경에서 기본적인 운영체제로 사용되며, 시스템 프로그래밍의 기초를 이해하는 데 필수적임.
  • Git의 학습 곡선: Git은 처음에는 어렵지만, 버전 관리의 강력한 도구로서 필수적임. 특히 분산 시스템과 협업 환경에서 유용함.
  • Emacs의 유연성: Emacs는 텍스트 편집기 이상의 기능을 제공하며, 특히 Lisp 프로그래밍에 관심이 있는 사람들에게 추천할 만함.
  • Boost.Graph의 제네릭 프로그래밍: Boost.Graph는 제네릭 프로그래밍의 강력한 예시로, 복잡한 알고리즘을 효율적으로 구현하는 방법을 배울 수 있음.
  • Bazel의 효율성: Bazel은 대규모 프로젝트에서 빌드 시스템의 효율성을 극대화할 수 있는 도구로, 특히 Google과 같은 대기업에서 유용함.
▲
zihado 6달전  [-]

윈도우에서는 everything이 아닐지 ㅎㅎ

답변달기
▲
bus710 6달전  [-]

Magit이 얼마나 좋길래 이렇게 명작 소프트웨어 대열에 이름을 올리는걸까요? 이맥스를 안 쓰니 알 수가 없네요.
Nvim에서는 Neogit가 Magit으로부터 영향을 받았다고 하는데, 그거라도 써봐야할지...

답변달기
▲
bbulbum 6달전  [-]

lazygit 도 추천드립니다 ㅎㅎ

답변달기
▲
bus710 6달전  [-]

감사합니다.
주말에 superfile과 lazygit을 설치해서 구경 좀 해봐야겠어요.

답변달기
▲
neo 6달전  [-]
Hacker News 의견

해커뉴스 댓글 모음 요약

  • Compiler Explorer:

    • Compiler Explorer는 컴파일러와 성능 최적화에 대한 논의를 크게 변화시켰음.
    • 포럼에서의 논의 품질에 긍정적인 영향을 미침.
    • Bold한 주장들을 링크를 통해 빠르게 검증할 수 있음.
    • llvm-mca와 uiCA 같은 도구도 유용함.

  • Windows 사용에 대한 의견:

    • Windows에 대해 균형 잡힌 시각을 제시함.
    • NT 계열의 Windows는 훌륭한 운영 체제임.
    • 게임을 위해 Windows를 설치해둠.

  • Docker:

    • Docker는 컨설팅 경력 동안 많은 시간을 절약해줌.
    • 오래된 프로젝트를 빠르게 실행할 수 있게 해줌.
    • 여러 데이터베이스 서버를 설치할 필요가 없어짐.
    • Python 환경을 재현 가능하고 병렬로 실행할 수 있게 해줌.

  • Spring Framework:

    • Spring Framework는 의존성 주입 개념을 이해하는 데 방해가 됨.
    • 많은 Java 개발자들이 복잡한 프레임워크가 필요하다고 생각하게 만듦.
    • Spring 자체는 유용하지만, 소프트웨어를 더 복잡하고 덜 이식 가능하게 만들 수 있음.

  • Nix:

    • Nix와 Nixpkgs로 많은 복잡한 작업을 수행할 수 있음.
    • Rust 바이너리의 정적 빌드 등을 쉽게 할 수 있음.
    • 다양한 빌드 옵션과 캐싱 기능을 제공함.
    • Nix는 매우 유용하지만, NixOS는 신중하게 접근해야 함.

  • Emacs:

    • Emacs는 버그 수정 작업을 기술 연습으로 바꿔줌.
    • 지루한 작업을 재미있게 만들어줌.

  • 'Round' 개념:

    • 'Round' 개념은 최소한의 핵심 볼륨으로 최대한의 인터페이스 영역을 제공함.
    • Emacs와 Git의 핵심은 작고 단순하지만 강력함.

  • Magit:

    • Magit은 단순함, 효과성, 발견 가능성의 교과서적인 예임.
    • Git의 기능을 더 잘 노출시켜줌.
    • 자체 용어와 워크플로우를 도입하지 않음.

  • SVN과 Git 비교:

    • SVN 사용 경험은 매우 부정적이었음.
    • Git은 훨씬 더 직관적이고 이해하기 쉬웠음.
    • Git을 사용하면서 작업 흐름이 더 나아짐.

  • Linux, Emacs, Bazel, Magit 사용 경험:

    • Linux에서 Emacs와 Bazel을 사용하여 작업을 수행함.
    • 블로그를 찾아보고, Emacs에서 작업을 저장하고, Magit을 사용하여 커밋 메시지를 작성함.
    • Git 저장소에 푸시함.
답변달기