사용자 도구

사이트 도구


book:ecmascript:interpreter

ㅇㅣㄴㅌㅓㅍㅡㄹㅣㅌㅓ

그저 꽃이 피어야 10일이 못 넘긴다고 하지만 이 꽃만은 이 꽃만은 날도 없고 봄바람도 필요없다네.

자바스크립트는 넷스케이프에서 구현하였다. 물론 용도는 좀 더 동적인 웹을 구성하기 위해서이다. 웹의 초창기는 점유율 높은 곳에서 사용하는 것이 표준이 되었던 시기이다. 또한 최초로 제안한 것이 점유율이 높을 가능성이 높다. 이러한 논리는 대부분의 모든 분야에서 동일하겠지만 아무리 목소리 높여서 표준을 만든다고 하여 시장이 따라가는 것은 아닐 것이다. 하지만 누구나 독점은 싫어하며, 독점이 있다면 반대편도 빠르게 생기는 것이 인간의 본성인 듯 하다. 하나의 인간이 모든 전재전능하지 않은 관계로…

한 때 브라우저전쟁이 있었다. 물론 현재도 진행형이지만 말이다. 내가 말하는 것은 넷스케이프와 익스플로러간의 싸움이다. 물론 OS를 소유한 마이크로소프트의 승리로 끝이 났다. 그러나 득이 있으면 실이 있다. MS의 욕심이 또한 익스플로러를 없애 버리는 것으로 끝이 났다. 바로 ActiveX의 등장이 그것이다. 사실 모든 것을 가지고 있는 MS에 의해서 말이다.(이 당시는 상업적으로 MS에 대항하는 것이 거의 힘들었다. End-User를 위한 모든 것을 제공한다는 것은 참으로 큰 힘이다. S/W Engineer에게도 말이다.)

ActiveX를 처음 접했을 때 이것은 무엇일까? 처음 ActiveX를 보았을 때의 느낌은 와우. 뭐지. 웹페이지로 구현할 수 없는 것을 구현하여 주네. 웹페이지에 나의 프로그램을 구동할 수 있구나. 좋은데. 하지만 그것으로 끝이었다. ActiveX로 멋있는 페이지는 구경하기 드물었고 사용자를 귀찮게하는 프로그램이 더 많이 나왔으니 말이다. 멋있는 것이 아니라 사용자가 느끼지 못 하는 다른 일을 많이 하고 있다. 그것도 내 PC의 OS를 수정하면서 말이다. 아마도 의도는 OS의 좋은 기능을 웹페이지에서도 동일하게 사용하라는 것이었겠지만, 인간의 습성은 엉뚱한 곳으로 흐르기 마련이다.

장단점

프로그램 언어의 분류방식이 많이 있을 수 있다. 인터프리터는 누군가에게 도움을 받아야 함을 내포하고있다. 아마도 이것은 프로그램언어 역사에서 처음부터 주류 영역은 아니었다. 입문자를 위한 맛보기 언어에 해당하지 않았을까? 장점이라고 할수있는 것들을 생각해보면 빠른결과확인, 중간처리 과정없이 결과확인가능하다.(컴파일시간은 오래걸린다.)

book/ecmascript/interpreter.txt · 마지막으로 수정됨: 2025/04/15 10:05 저자 127.0.0.1