(감상문) Edgar Dijkstra : Go To Statement Considered Harmful

0.

고수 프로그래머들은 Go To statement를 지양한다.

 

 

1.

Yet, one the program has been made, the "making" of the corresponding process is delegated to the machine

 

프로그래머는 잘 돌아가는 correct program만 만들면 끝난다.

그는 특정 상황에서 desired effect를 만족하는 specific한 동작을 하는 프로세스를 만들어

machine에게 이 프로세스를 위임한 것이다.

 

2.

우리 컴퓨터공학자들의 intellectual power는 이러한 static relation을 분석하고 만들어내는 쪽으로 발달했고

반면에 dynamic한 process를 발전시켜나가는 과정 자체를 시각화하는(*파악하는?) 능력은 부족한 상황이다.

그래서, 우리는 dynamic process와 static program 사이의 conceptual gap을 줄여서 

서로가 최대한 correspondent하게 만들어야 한다.

 

 

3.

우리는 if A then B 와 if B then A와 같은 작업을

하나의 작업인 Procedure로 나타낼 수 있으며

Dynamic Indexing을 통해서 반복할 수도 있다.

 

Sequential 한 Text와 Dynamic Index 를 사용하면

procedure call과 같이 반복적으로 작접을 수행할 수 있다.

 

 

4.

또한 Dynamic Indexing의 과정은 프로그래머의 컨트롤 범위 밖의 문제이다.

프로그램에 저장된 값이나 프로세스에 의해 바뀐 값을 사용하기 때문이다.

Independent한 cooridinate를 무시하고 goto로 변수값을 바꿔버리면

이러한 process의 progress를 무시하고, 프로세스가 meaningful set of cooridate에 대해

가지는 의미를 무시하고  프로세스를 진행하는 것이다.

 

5.

goto는 너무 원시적이고 프로그램을 지저분하게 만든다.

Program은 Dynamic Structure의 Process를 잘 mirror해야한다.

그래야지 시스템이 잘 표현되고 유지보수 될 수 있기 때문이다.

 

 

----

 

후기 : 논리적인 흐름을 나타낸 프로세스에

무작정 goto를 사용하면 논리적인 흐름을 무시하고 논리적인 흐름을 꼬아버린다.

실제 static한 program과 dynamic한 process의 간극을 줄여야지

이후의 유지보수와 개발을 원활히 수행할 수 있다.가 이 글의 골자이다.

 

물론 로우레벨로 갈수록 goto의 중요성은 커진다.

기본적으로 튜링머신이나 푸시다운 오토마타의 구조도

결국 상태머신이고, 각각의 상태가 변화하는 과정 자체가 goto에 가깝기 때문이다.

 

거대하고 추상적인 논리의 세계를 중시하느냐

실제 구현의 단계에서 미래 다팔아먹고 악마와 계약해서 최적화+구현을 중시하느냐에 따라서

goto를 쓰느냐 마느냐가 갈리는 듯하다.

 

논문에서도 goto를 여러가지 상황을 고려해서 조심해서 쓰라고 하고 있다.