기능상의 죄
더 주관적인 영역으로 들어간다면, 소프트웨어 개발에서 쓰이는 도구, 언어 그리고 방법론들은 사실 객관적인 진실이라기 보다는 종교적 섭리의 산물입니다. 소스코드들은 마치 산문과 같습니다. 모든 사람들은 각자 무엇이 선한가에 대한 의견을 가지고 있습니다. 그리고 종종 전달하고자 하는 내용은 전달하는 방법보다 덜 중요해집니다.
최소한 누군가의 눈에는 잘못된 것으로 보일 것이라는 것을 인정하지만, 우리는 어느 한 쪽을 선택하는 죄를 범해야만 합니다. 하지만 우리의 선택에는 적어도 정당화 할 수 있는 많은 근거들이 있습니다.
카르다노를 가능하게 하는 프로토콜은 하스켈로 구현되고 있습니다. 유저 인터페이스는 Daedalus라는 Electron의 포크로 캡슐화 되어 있습니다. 우리는 가능하다면 웹 아키텍쳐 모델을 사용하기로 하였으며, 데이터베이스로는 RocksDB를 활용한 key-value 패러다임을 선택했습니다.
컴포넌트 레벨에서 이 추상화는 유지보수를 더 쉽게하고, 추후 쉽게 더 나은 기술로 교체할 수 있으며, 그리고 우리의 기술 스택이 Github과 Facebook의 개발 노력과 부분적으로 연관되어 있음을 의미합니다.
WebGul을 사용함으로써, 수십만의 자바스크립트 개발자들이 활용하는 도구를 가지고 프론트엔드 기능 개발에 React를 활용할 수 있습니다. 웹 아키텍쳐를 사용한다는 것은 각 컴포넌트들이 서비스로 여겨질 수 있고, 보안 모델이 합리적인 것을 의미합니다.
프로토콜 개발에 하스켈을 선택하기로 한 것은 가장 어려운 결정이였습니다. 함수형 세계에서도 여러가지 다양한 선택이 있었습니다. 좀 더 융통성있고 혼합적인 측면에서는, Clojure, Scala, F#과 같은 언어가 있습니다. 이 언어들은 자바와 .Net의 생태계의 거대한 라이브러리의 혜택을 누리면서, 몇몇 부분에서 함수 프로그래밍의 최상의 면을 유지합니다.
Agda)와 Idris와 같은 학문 지향 언어는 정확성을 강력하게 검증 할 수있는 기술과 관련이 있습니다. 그러나 이 언어들은 괜찮은 라이브러리가 부족하고 개발 경험이 적습니다.
카르다노는 Ocaml과 Haskell을 선택했습니다. Ocaml은 훌륭한 공동체, 훌륭한 도구, 충분한 개발 경험 및 Coq23 를 통한 공식적인 검증 영역에서 훌륭한 유산을 가진 멋진 언어입니다. 그렇다면 왜 우리는 하스켈을 선택했을까요?
23: 이 시점에 더해서, IOHK는 사실 우리가 익명의 Bill White로부터 물려받은 Qeditas라고 불리는 Ocaml에서 구현 된 프로젝트를 가지고 있습니다.