사용자 도구

사이트 도구


book:ecmascript:interpreter

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

양쪽 이전 판이전 판
다음 판
이전 판
book:ecmascript:interpreter [2021/10/01 14:20] – 바깥 편집 127.0.0.1book:ecmascript:interpreter [2025/04/15 10:05] (현재) – 바깥 편집 127.0.0.1
줄 1: 줄 1:
 +====== ㅇㅣㄴㅌㅓㅍㅡㄹㅣㅌㅓ ======
 +<WRAP center round info 80%>
 +그저 꽃이 피어야 10일이 못 넘긴다고 하지만
 +이 꽃만은 이 꽃만은 날도 없고 봄바람도 필요없다네.
 +</WRAP>
  
 +
 +자바스크립트는 넷스케이프에서 구현하였다. 물론 용도는 좀 더 동적인 웹을 구성하기 위해서이다.
 + 웹의 초창기는 점유율 높은 곳에서 사용하는 것이 표준이 되었던 시기이다. 또한 최초로 제안한 것이 점유율이 높을 가능성이 높다.
 + 이러한 논리는 대부분의 모든 분야에서 동일하겠지만 아무리 목소리 높여서 표준을 만든다고 하여 시장이 따라가는 것은 아닐 것이다.
 + 하지만 누구나 독점은 싫어하며, 독점이 있다면 반대편도 빠르게 생기는 것이 인간의 본성인 듯 하다.
 + 하나의 인간이 모든 전재전능하지 않은 관계로...
 +
 +한 때 브라우저전쟁이 있었다. 물론 현재도 진행형이지만 말이다. 내가 말하는 것은 넷스케이프와 익스플로러간의 싸움이다.
 + 물론 OS를 소유한 마이크로소프트의 승리로 끝이 났다. 그러나 득이 있으면 실이 있다. MS의 욕심이 또한 익스플로러를 없애 버리는 것으로 끝이 났다.
 + 바로 ActiveX의 등장이 그것이다. 사실 모든 것을 가지고 있는 MS에 의해서 말이다.(이 당시는 상업적으로 MS에 대항하는 것이 거의 힘들었다.
 + End-User를 위한 모든 것을 제공한다는 것은 참으로 큰 힘이다. S/W Engineer에게도 말이다.)
 +
 +ActiveX를 처음 접했을 때 이것은 무엇일까? 처음 ActiveX를 보았을 때의 느낌은 와우. 뭐지. 웹페이지로 구현할 수 없는 것을 구현하여 주네.
 + 웹페이지에 나의 프로그램을 구동할 수 있구나. 좋은데. 하지만 그것으로 끝이었다. ActiveX로 멋있는 페이지는 구경하기 드물었고 사용자를 귀찮게하는 프로그램이 더 많이 나왔으니 말이다.
 + 멋있는 것이 아니라 사용자가 느끼지 못 하는 다른 일을 많이 하고 있다. 그것도 내 PC의 OS를 수정하면서 말이다.
 + 아마도 의도는 OS의 좋은 기능을 웹페이지에서도 동일하게 사용하라는 것이었겠지만, 인간의 습성은 엉뚱한 곳으로 흐르기 마련이다.
 +
 +===== 장단점 =====
 + 프로그램 언어의 분류방식이 많이 있을 수 있다.
 + 인터프리터는 누군가에게 도움을 받아야 함을 내포하고있다. 아마도 이것은 프로그램언어 역사에서 처음부터 주류 영역은 아니었다.
 + 입문자를 위한 맛보기 언어에 해당하지 않았을까?
 + 장점이라고 할수있는 것들을 생각해보면 빠른결과확인, 중간처리 과정없이 결과확인가능하다.(컴파일시간은 오래걸린다.)
 +