단일 언어로 거대 프레임웍 못 짠다.

요즘 글을 쓰면 해당 글을 보고 개뿔 모른다는 식의 말을 우회적으로 하는 지역급 저명인사들이 많다. 우선 서울이라고 해도 전국구는 아니라고 말해주고 싶다. 그리고 수많은 재야의 엔지니어들이 있다. 나 같은 경우 똑같이 가만히 있어도 되지만 굳이 말을 꺼내기 시작한 엔지니어 중 한명일뿐이라는 것을 알아주었으면 한다. IT에 쏟는 국가 예산만 조단 위가 넘고 분기당 수조를 버는 국내 대기업만 해도 IT 인력이 수만 명이다. 중소기업인 수는 대기업 임직원 수의 10배다. 관련 학과 혹은 비전공이지만 관심 있는 학생수는 한국에 40만 명이다. 줄 쳐두고 담에 지워야지.

시스템이 거대해지면 여러 언어가 합쳐진다.

Android만 해도 ASM, C, C++, JAVA 가 합쳐져 있다.

우선 ERROR는 어떤 언어든 못 막는다. 그것이 ERROR의 개념이니까.

JAVA에서 try catch로 Exception을 핸들링한다고 해도 에러난 상황을 완벽하게 복구하지 않는다면, 언젠가는 에러가 난다.

이것이 왜 JVM의 경우 재 실행하는 상황이 오는지에 대한 이유이다. 이클립스를 결국 다시 닫았다가 열어야 하는지 말이다.

SWIFT의 경우 옵셔널이 가장 큰 장애 요소이다. JAVA 던 SWIFT 던 C#이던 개발자가 놓치는 메모리 해제가 수없이 많기 때문에(개인 모듈이 아니라 다 같이 일할 때 잘 나온다) 아예 개발자를 믿지 않는다는 가정에서 출발한 언어들이다. SWIFT도 그렇다. 옵셔널도 그래서 나왔다. 프리미티브 타입에 널을 주려고 하는 게 아니다. 메모리에 없어서 존재하지 않는다는 개념이 null이기 때문이다. 구현은 0인지 아닌지로 한다만...

옵셔널은 결국 눈 앞의 에러를 막아주는 역할을 하지만 모듈이 커지면 그것이 위험인자로 다가온다. 모듈이 커지고 복잡해지면 blackbox testing  밖에는 답이 없다. 시간과 비용이 무한정 주어진다면 코드로만 하겠지만. 

 blackbox testing에서 메모리 할당/해제가 완벽하지 되지 않는 부분이나 Exception이 쌓이고 에러 핸들링 구문이 완벽하지 않아서 단순히 현재성 에러만 막아준 경우 문제가 터지는데 어디서 터지는지 알 수가 없다.

즉, 에러가 날 때는 나줘야 한다는 것이다.

생체 인공지능을 이용한 프로그래밍 언어가 아닌 이상 현존하는 프로그래밍 언어의 모든 개념은 결국 if 시작하고 if로 끝난다. 남자들이 공구와 DIY세트를 좋아하듯, 세부적인 것을 하나하나 바꾸고 싶다면 어려워야 한다. 모든 문제를 완벽하게 풀 수 있는 단일 프로그래밍 언어는 없다.

OLPP 패러다임을 적용하면 목적부터 고려를 해야 하니

SWIFT는 데이터 구조도 다양하게 들어가 있고, 함수형 프로그래밍도 쉽고 새롭도 다양한 개념으로 빠르게 프로그래밍을 할 수 있는 언어임은 분명하다. 이름 그대로 빠르게 프로그래밍할 수 있는 언어이다.

아마 버전 6 전까지는 C/C++을 대체하지는 못할 것이다. coverity라는 강력한 툴이 SWIFT 내부로 들어간다면 판도는 바뀌리라 생각한다.