프로그래밍을 하다 느끼게 되는 것 2 프로그래밍

원래  theidiots님 원 글에 딴지 걸려고 프로그래밍을 하다 느끼게 되는 것을 쓴 것이 아니라 곁가지로 농담으로 글이었습니다만,  딴지를 건다는 느낌을 주지 않았나? 하는생각에 추가 잡설을 올립니다.

개인적으로 프로그래밍은 일반 공학이라기보다, 일종의 사회적 규약과 약속을 기반으로 돌아가는 사회, 문화적 속성이 더 강하다고 생각합니다.
최근 프로그래밍 언어나 환경을 고려한다면 이런 특성이 더 부각됩니다.
이런 사회, 문화적 속성은 보편적이지 않습니다.
물론 가장 하단은 ic chip, 전기 법칙들과 수학을 기반으로 하고 있습니다만, 일반적인 프로그래밍 환경 아래에선  상대방이 동의한다면 심지어 1 + 1 == 2가 아닌 1 + 1 == 3이라는 규칙(언어)을 임의로 정할 수도 있고, 얼마전 까지 선호하던 방법론도 현재는 절대 쓰지 말아야 할 방식으로 배척받기도 합니다.

하루가 멀다하고 바뀌고 있는 IT쪽 환경에선 절대 선이나 절대 악은 없습니다.
단지 문맥(context)에 맞게 잘 쓰느냐가 중요하죠.
  
원 글의 "goto를 쓰면 편하다" 문구 역시 맞는 말입니다.
"잘쓰면 약, 과하면 독"이라는 말처럼 잘쓰면 꽤 편리합니다.
심지어 잘 쓴 goto문은 source의 가독성과 code 길이를 줄여주기도 합니다.
저도 error 처리 용으로 종종 쓰기도 합니다.

간혹 살아가다 보면 아주 특출나게 잘난 것도 아님에도, 상대방보다 조금 안다는 이유로 잘난체하거나, 가르치려하는 경우를 종종보게 됩니다.
그렇다고 잘난체 하는 사람이 말이 다 맞는 것도 아닙니다. 그 사람보다 더 잘 난 사람이 보기에 도토리 키재기하는 것으로 보이겠죠.
저 역시 살아가며 종종 이런 모습을 보여왔고, 지금 생각해보면 치기로 치부하기에도 챙피하죠.

나이가 들어가며 절실하게 느끼는 것 하나 "정답은 없다."


프로그래밍을 하다 느끼게 되는 것 프로그래밍

프로그래밍을 하다 느끼게 되는 것을 읽다 생각나서 ...

이쪽 계통은 상황에 따라 답안이 달라지는 경우가 워낙 많아서 원 글과 다른 결론이 나는 경우에 대해 써봅니다.
진지하면 골룸~~~

1. 프로그램이 직관적이고 쉬워 보일수록 구현하기가 어렵다.
  -  직관적이고 단순한 만큼 구현하기 쉽다.(예: 윈도우 메모장)

2. 프로그램 명세를 가장 처음 봤을때 생각나는 귀찮고 하기싫은 방법이 바로 올바른 구현 방법이다.
  - 가장 처음 봤을때 생각나는 단순하고, 구현이 쉬운 방법이 바로 올바른 구현 방법이다.
  - sort를 상황에 맞게 개선 해보겠다고 며칠 뻘짓하다 결국 채택하는 것은 selection sort나 c lib quick sort 

3. 프로그램의 메인로직이 어려운 경우는 많지 않다. 대신 메인 로직을 구성하는데 필요한 수 많은 작은 로직들이 귀찮다.
  - 프로그램의 메인로직만 어려운 경우가 많다. 대신 메인 로직을 구성하는데 필요한 수 많은 작은 로직들은 별 의미가 없는 경우가 흔하다.
  - 프로그램 단가를 결정하는 주 요인은 특정 로직을 구현할 수 있는가에 달려있는 경우가 많다. 

4. 프로그램은 10퍼센트의 업무로직과 90퍼센트의 에러처리로 이루어진다.
  - 에러처리 로직이 지저분할 수록 프로젝트의 실패율이 높아진다.
  - 프로그램 개발에서 에러 처리를 쉽게 처리할 수있는 능력이 있을수록 개발자와 설계자의 봉급이 올라간다.

5. 프로그래밍에서 두번째로 어려운건 함수의 이름을 정하는 것이고, 첫 번째로 어려운건 변수의 이름을 정하는 것이다.
   - 프로그래밍에서 두번째로 쉬운 것은 함수의 이름을 정하는 것이고, 첫 번째로 쉬운 것이 변수의 이름을 정하는 것이다.
   - naming 규칙을 적절하고 일관성 있게 사용하는 것은 세월이 해결해 준다.
   - 숙련도가 높아질 수록 명명 규칙은 무의식 영역에 속한다.

6. 컴퓨터는 내가 걱정해주는것보다 항상 빠르다. 복잡도 같은건 전공 서적에서나 찾을 수 있는 이야기일 뿐이다.
   - 컴퓨터는 내가 생각했던 것보다 항상 느리다.
   - 해결 방법을 찾을 수록 월급이 올라간다.
   - 최신 intel 4core PC를 사용하다가, atom이나 pentium PC를 사용하면 배우는 것은 느림의 미학과 인내심뿐이다.
   - 개발자에게 구닥다리 pc를 던져주고 개발 시간 단축을 원한다면 진지하게 이직에 대해 고민할 필요가 있다.
7. GOTO문은 편하다.
  - goto 횟수가 많을 수록, debugging 지옥 체험 시간은 기하 급수적으로 늘어난다.
  - goto 없는 언어를 사용하다보면, goto 지원 언어에서 조차 사용법을 까먹거나 불편함을 느낀다.


8. 학교 과제에서는 메모리 관리가 필요없다.
  - 학교 과제에서도 간혹 메모리 관리가 필요할 수도 있다. 
  - 최소한 조교나 교수 컴퓨터에서 과제 test할 때 메모리 부족 error가 뜨지 않도록 구현할 필요가 있다.

9. 조금만 더하면 완성이라고 느낄때는 실제로는 50%정도 정도 완성된 것이다.
  - 조금만 더하면 완성이라고 느낄때는 실제로는 5%이거나 95%정도 완성된 것이다.
  - 5% 일 때, 남은 건 debugging 지옥
  - 95% 일 때, 쓸때 없는 부가 기능(사족)은 불필요, 멈출 때를 아는 것도 능력

10. 아무리 설계를 잘해도 70%쯤 완성되면, 그중 30%가량은 최소한 한번 이상 수정해야 하는 일이 생긴다.
  - 아무리 설계를 잘해도 70%쯤 완성되면, 첫 prototype의 흔적은 남지 않거나, 아직 prototype 완성 단계도 아니다.
  - 흔적이 남지 않을 정도로 넝마 조각이 되있거나,  90% 정도 완성되야 prototype으로서 test가 가능하다.

11. 버그의 출현 빈도는 제출시한이 다가올수록 늘어난다.
  - 버그의 출현 빈도가 프로젝트 막바지에 이르도록 줄어들지 않는다면, 이미 프로젝트는 막장이다.

12. 컴퓨터는 잘못이 없다. 오로지 개발자의 잘못 뿐이다.
  - 컴퓨터에 문제가 있는데요. 제가 할 때는 잘됬는데요.(컴퓨터(platform, 환경)나, operator, 설계자 탓을 하는 개발자)

13. 되면 된다.
  - 안되는 것은 안되는 것이다.
  - 안되는 것을 군발이 정신으로 구현하면 결국 초래되는 것은 사고다.
  - 안되는 것을 된다고 뻥쳐도 남는 것은 원전 폭발같은 대형 사고다.
  - 되도록 만든 것처럼 보이도록 할 수있는 것은, 철야와 야근 뿐이며, 남는 것은 병원비 영수증 뿐이다.
  - 아주 극히 예외적으로 불가능을 가능으로 만든 경우는 극히 예외적인 천재가 손 봤을 경우다.

14. 완성된 프로그램은 일정기간 동안 내 컴퓨터에서만 동작한다.
  - ms에서 개발한 모든 프로그램은 일정 기간 동안만 동작한다.
  - ms windows 환경에서 동작하는 프로그램은 일정 기간 동안만 동작한다.
  - 내 컴퓨터에서만 동작할 수록, 학점이 낮아지거나 봉급이 삭감되거나, 조기 퇴직 비율이 높아진다. 

15. 내가 구현한 프로그램이라고 해도 다시 봤을때 이해한다는 보장은 없다.
  - 내가 구현한 프로그램을 알아 볼 수 없다면,  음주 코딩은 자제하거나, 건망증이 심해지는 나이에 이르렀음을 겸허히 받아들이고, 담배 한대 피운다.

16. 영문과 학생은 영어를 잘한다. 수학과 학생은 수학을 잘한다. 컴퓨터과 학생은 컴퓨터를 못한다.
  - 컴퓨터과 학생은 대체로 컴퓨터 수리를 잘한다. (주변 인물들이 들고 오는 컴퓨터의 댓수(선입관과 압력)와 수리 능력은 비례한다.)
  - 모든 컴퓨터과 교수는 컴퓨터 수리 능력이 전무하다.
 

puts ('λ')

네코 카테고리 개설 기념 고양이 쉽게 그리는 법 을 읽다 무심코 든 쓸데없는 망상

네코 개발자는  λ (lambda)가지고 낙서하다가 무심코 그린 고양이에서 아이디어를 얻지 않았을까?

lambda(λ) function - functional language에서 자주 애용되는 만능도구 


<code ruby>

puts ('λ')

</code>



왜 iphone 4.0에 대해 개발자들이 분노하는가? 프로그래밍

iphone 4.0 발표에 대해 국내 반응을 보면 꽤 호의적입니다.
그러나 국외에선 우려와 분노하는 꽤 강도높은 반응이 나오기 시작하고 있습니다.
단 그 목소리의 주체가 개발자들과 그들의 community라 아직 외부적으로 크게 반향을 일으키고 있지는 않습니다.

그러면 개발자들이 단지 우려하는 단계를 넘어 분노까지 하게 된 이유는 뭘까요?
바로 iPhone Developer Program License Agreement의 3.3.1 항목의 개정에 있습니다.

기존
3.3.1 Applications may only use Published APIs in the manner prescribed by Apple and must not use or call any unpublished or private APIs.
 
변경
3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

이 개정은 iPhone App목록에 등록하려면 Object-C,  C++, JavaScript(WebKit engine내 javascript만 인정)로만 무조건 개발하라는 의미입니다.
이렇게 무리하게 개정한 이유는 물론 Adobe flash입니다.
safari web browser의 plugin 형태의 flash player는 web browser의 안정성을 해칠 수 있다는 명목으로 허용을 하지 않았습니다만, 얼마전 발표한 최신 flash platform을 사용하면 plugin형태가 아닌 단독 app형태로 개발, 결과물은 native code로 변환하는 형태를 취하고 있어 기존 개발 라이센스 내용으로 딱히 제제할 방법이 없어 iphone 4.0 발표와 함께 은근 슬쩍 내용을 바꿔버렸습니다.

그러면 Adobe 소속이 아닌 다른 개발자들까지 왜 분노할까요?

이유는 개발 언어의 제한입니다.
더우기 원천 개발 언어를 제한함으로써, 어떤 형태의 언어 변환도 허용하지 않기 때문입니다.
즉 pyhon, lisp, java, C#등 다른 언어로 개발 후, Object-C등으로 변환하는 것 조차 허용하지 않습니다.

지금 스티브 잡스와 애플이 보여주는 모습은 마치 IBM-PC에 대해 오만한 자세를 견지하다 순식간에 몰락했던 과거 모습을 상기시키고 있습니다.
개발자 community와 생태계를 스스로 붕괴시키는 모습은 마치 현명한 리더가 독재자로 변신했을 때 망해가는 모습을 떠오르게 합니다.

더 이상의 iphone 프로그램 개발을 포기하는 개발자의 심정을 알려주는 글
Scheme is also dead on thi iPhone
(이 분은 lisp언어 일종인 scheme으로 개발 후 portable c로 변환하는 형태를 취했습니다.)

ps)
License 변경으로 Flash의 iPhone 진입 원천 봉쇄

추가로 다음 내용은 또 다른 라이센스 항목으로, 애플이 아닌 그 누구도 Iphone으로 비즈니스를 하지말라는 내용으로 Google이 target으로 보입니다.
New iPhone Developer Agreement Bans the Use of Third-Party Analytics and Services


GUI, WYSIWYG, WYSIAYG 프로그래밍

GUI

장점 - WYSIWYG (what you see is what you get)
단점 - WYSIAYG (what you see is all you get)

- programtic programmer에서 발췌


1 2 3