Swift VS Python 으로 카테고리 변경

1.

카테고리를 변경했다. 앞으로의 내용도 비교 위주로 적을 예정이다. 단일 내용이야 다른 블로그에도 많으니 특색이 없어 바꿨다.

Xcode & PyCharm 카테고리 삭제하며 해당 카테고리의 게시글도 모두 옮겼다.

2.

코드는 github 외 공유 하는 것이 아닌 것 같다는 생각이 어제 들어서 오늘 바꾸게 되었다. 블로그에는 고찰 같은 것을 적는게 맞아 보인다.

유닉스 창시자가 creat 로 만들고 후회했다고 했다. 줄여서... create 가 맞기 때문에 수 십년 뒤에 가장 바꾸고 싶다는 인터뷰를 봤었다. func, def 도 같은 문제점이 있는 것 같다.  function 이던 method 던 명시하는 것은 좋은데 func던, def 던 둘 다 틀렸다고 보인다. 이미 C처럼 없애던지, JAVA 처럼 접근 제한자 자리를 두던지. 아니면 말을 줄이지 말던지. -1 : -1

{}냐 :와 indent 냐 하는 것은 python 의 :로 승리로 보는 사람이 있다. 어차피 코드 정리를 해야 하기 때문이다. 그러나 auto format 기능을 쓸 때 자동 정렬되고 회사마다 다른 formatting rule 이 있는데 그 룰을 리팩토링 툴에 적용하는 것을 볼 때 {}가 차라리 유용하다는 생각도 들 하다. Xcode에서 {의 경우 더블클릭 하면 어디까지가 block 인지 알 수 있다. 그리고 go to matches로 블럭 끝으로 이동 가능하다. PyCharm에서는 더블 클릭도 없고 matches도 없으나 expend/collapse 기능이다. Folding 메뉴가 있으므로 폴딩하며 볼 수 있는데 이 방법 밖에 없어서 오히려 기능을 매우 자주 쓰게 된다. 단일 책임의 원칙을 적용하던 뭐던, 프로그램 내용이 깊어지면 점점 복잡해지니... pythonic 하게 짠다면 그렇게 긴 코드가 필요 없다고 볼 때 python 이 나아 보일 수도 있다. assembly 도 자주 접할 수 밖에 없었던 나는 python style이 낫다. -1 : 0 

for 문에서는 아무래도 swift가 더 직관적이다.  for x in 0..<y 일 때 for x in range(0, y) 인데 <= 인지, < 인지 swift는 명확하게 명시하고 있기 때문이다. range(4) 경우 0, 1, 2, 3으로 해당 숫자가 포함되지 않는데 ..< 가 더 직관적이다. 0:0

뭐, 이런 것들을 적으려고 한다. 생각날 때마다.