인터프리터방식의 장점..

gyxor의 이미지

컴파일러의 단점이 인터프리터의 장점이 될까요?
프로그래밍 언어론에 나온.. 인터프리터 방식의 장점은

"많은 원시 프로그램 수준의 디버깅 연산을 쉽게 구현할 수
있는 장점을 갖는다. 이것은 모든 실행 시간 오류 메시지가 원시 수준 단위를 참조할 수 있기 때문이다. 예를 들면, 배열 인덱스가 범위를 벗어났다는 것이 발견되면, 오류 메시지는 원시 프로그램의 행과 배열 이름을 쉽게 나타낼 수 있다. "

라고 나와있습니다...하지만 이것은 컴파일러방식에서도 가능한 것 아닌가요?
인터넷을 검색해보니
:프로그램이 될 때까지 원시 언어의 형태를 유지하기 때문에 기억 장소는 추가로 필요하지 않음.
이렇게 나와있습니다.
즉,컴파일러방식의 경우 실행파일의 크기가 원시소스보다 매우 클 수 있는데..이러한 실행파일을 수행을 위한 input으로 본다면.. 인터프리터방식의 경우 작은 input을 가질 수 있다는 장점이 있는것으로 생각됩니다.
이외에..
컴파일러 방식이 갖지 못하는 인터프리터방식의 장점이 뭐가 있을지 궁금합니다.
답변부탁드립니다.

익명 사용자의 이미지

gyxor wrote:
컴파일러의 단점이 인터프리터의 장점이 될까요?
프로그래밍 언어론에 나온.. 인터프리터 방식의 장점은

"많은 원시 프로그램 수준의 디버깅 연산을 쉽게 구현할 수
있는 장점을 갖는다. 이것은 모든 실행 시간 오류 메시지가 원시 수준 단위를 참조할 수 있기 때문이다. 예를 들면, 배열 인덱스가 범위를 벗어났다는 것이 발견되면, 오류 메시지는 원시 프로그램의 행과 배열 이름을 쉽게 나타낼 수 있다. "

라고 나와있습니다...하지만 이것은 컴파일러방식에서도 가능한 것 아닌가요?

Quote:

컴파일러 방식에서는 불가능하죠. 컴파일된 프로그램을 실행시켰는데 배열 인덱스가 범위를 벗어났다는 것이 발견되면 Segmentation Fault 내지는 Access Violation 이 발생하면서 해당 기계어 코드를 보여줍니다. 무슨 배열인지, 소스코드의 몇행을 참조했는지까지 알려면 디버거를 사용하거나, 컴파일시 디버깅 심볼을 함께 링크하거나 해야하고.. 또 수정한 후에는 다시 컴파일해야 하고.. 뭐 이런 절차적인 문제가 인터프리터에는 필요 없다는거겠죠.

gyxor wrote:
인터넷을 검색해보니
:프로그램이 될 때까지 원시 언어의 형태를 유지하기 때문에 기억 장소는 추가로 필요하지 않음.
이렇게 나와있습니다.
즉,컴파일러방식의 경우 실행파일의 크기가 원시소스보다 매우 클 수 있는데..이러한 실행파일을 수행을 위한 input으로 본다면.. 인터프리터방식의 경우 작은 input을 가질 수 있다는 장점이 있는것으로 생각됩니다.
이외에..
컴파일러 방식이 갖지 못하는 인터프리터방식의 장점이 뭐가 있을지 궁금합니다.
답변부탁드립니다.

프로그램 자체를 하나의 input 으로 볼 경우, 컴파일된 실행파일보다 소스코드가 더 작으므로 적은 input 을 가질 수 있다..는게 장점이 될 수 있나요? 굳이 따지자면 장점일 수 있겠습니다만 사실 좀 억지인듯한 느낌이 강하게 드네요.

제가 생각하는 인터프리터의 가장 큰 장점은 역시 간편하다는겁니다. 컴파일 링크 과정이 필요 없이, 소스코드만으로 실행시킬 수 있고 결과를 확인할 수 있으니.. 어떤 프로그램을 만들기 전에 미리 결과를 보고싶다거나 테스트해보고 싶다면 메인 언어가 아니라 인터프리터로 먼저 짜보곤 하죠.

그리고.. 소스코드 수준에서 기종간 이식성이 보장된다는 점도 큰 장점이겠죠. 리눅스에서 짜여진 PHP 코드가 윈도우에서 수정없이 돌아갈 수 있고(물론 윈도우용 PHP 인터프리터가 있어야).. 특히 Perl 같이 특정 분야에서 극도의 편리함을 보여주는 언어들은 이런 장점이 크게 부각되더군요.

익명 사용자의 이미지

gyxor wrote:
컴파일러의 단점이 인터프리터의 장점이 될까요?
프로그래밍 언어론에 나온.. 인터프리터 방식의 장점은

"많은 원시 프로그램 수준의 디버깅 연산을 쉽게 구현할 수
있는 장점을 갖는다. 이것은 모든 실행 시간 오류 메시지가 원시 수준 단위를 참조할 수 있기 때문이다. 예를 들면, 배열 인덱스가 범위를 벗어났다는 것이 발견되면, 오류 메시지는 원시 프로그램의 행과 배열 이름을 쉽게 나타낼 수 있다. "

라고 나와있습니다...하지만 이것은 컴파일러방식에서도 가능한 것 아닌가요?

컴파일러 방식에서는 불가능하죠. 컴파일된 프로그램을 실행시켰는데 배열 인덱스가 범위를 벗어났다는 것이 발견되면 Segmentation Fault 내지는 Access Violation 이 발생하면서 해당 기계어 코드를 보여줍니다. 무슨 배열인지, 소스코드의 몇행을 참조했는지까지 알려면 디버거를 사용하거나, 컴파일시 디버깅 심볼을 함께 링크하거나 해야하고.. 또 수정한 후에는 다시 컴파일해야 하고.. 뭐 이런 절차적인 문제가 인터프리터에는 필요 없다는거겠죠.

gyxor wrote:
인터넷을 검색해보니
:프로그램이 될 때까지 원시 언어의 형태를 유지하기 때문에 기억 장소는 추가로 필요하지 않음.
이렇게 나와있습니다.
즉,컴파일러방식의 경우 실행파일의 크기가 원시소스보다 매우 클 수 있는데..이러한 실행파일을 수행을 위한 input으로 본다면.. 인터프리터방식의 경우 작은 input을 가질 수 있다는 장점이 있는것으로 생각됩니다.
이외에..
컴파일러 방식이 갖지 못하는 인터프리터방식의 장점이 뭐가 있을지 궁금합니다.
답변부탁드립니다.

프로그램 자체를 하나의 input 으로 볼 경우, 컴파일된 실행파일보다 소스코드가 더 작으므로 적은 input 을 가질 수 있다..는게 장점이 될 수 있나요? 굳이 따지자면 장점일 수 있겠습니다만 사실 좀 억지인듯한 느낌이 강하게 드네요.

제가 생각하는 인터프리터의 가장 큰 장점은 역시 간편하다는겁니다. 컴파일 링크 과정이 필요 없이, 소스코드만으로 실행시킬 수 있고 결과를 확인할 수 있으니.. 어떤 프로그램을 만들기 전에 미리 결과를 보고싶다거나 테스트해보고 싶다면 메인 언어가 아니라 인터프리터로 먼저 짜보곤 하죠.

그리고.. 소스코드 수준에서 기종간 이식성이 보장된다는 점도 큰 장점이겠죠. 리눅스에서 짜여진 PHP 코드가 윈도우에서 수정없이 돌아갈 수 있고(물론 윈도우용 PHP 인터프리터가 있어야).. 특히 Perl 같이 특정 분야에서 극도의 편리함을 보여주는 언어들은 이런 장점이 크게 부각되더군요.

ps) 아 죄송합니다. 위에꺼 테그가 틀렸는데 로그인하지 않아서 지우질 못하네요.;;

지리즈의 이미지

한가지 예를 들어 보겠습니다.

실행하다, 오류가 발생했습니다.
(배열 범위가 벗어났다던, 아니면 그외 여러 가지..)

그럼, 인터프리터 방식은 그 위치에서 브레이크가 발생하면서
디버깅모드로 돌입합니다.
그럼 프로그램이 실행중 잠시 중단시키고, 소스를 수정한 후,
속행해서 실행할 수 있습니다.

심지어면, 디버그 중간에,
그 오류를 발생하는 부분을 삭제해버릴 수도 있고,
선언안 된 변수를 위해 메모리를 할당할 수 있습니다.
그리고, 프로그램을 다시 시작하지 않고,
수정하면서 속행할 수 있지요.

물론 위의 여러가지는 개발툴이 이것을 지원해야겠지만요.

그외 떠오르는 다른 한가지는
플랫폼 인디펜던스하다는 점입니다.

There is no spoon. Neo from the Matrix 1999.

지리즈의 이미지

인터프리터 방식의 장점! 한마디로 대화형 작업이 가능하다!!!

There is no spoon. Neo from the Matrix 1999.

gyxor의 이미지

인터프리터를 사용하면..이기종간에 이식성이 보장될 수 있고,
단계가 한단계로 이뤄지므로 간편하다는 장점은 잘 알겠습니다..

Quote:

컴파일러 방식에서는 불가능하죠. 컴파일된 프로그램을 실행시켰는데 배열 인덱스가 범위를 벗어났다는 것이 발견되면 Segmentation Fault 내지는 Access Violation 이 발생하면서 해당 기계어 코드를 보여줍니다. 무슨 배열인지, 소스코드의 몇행을 참조했는지까지 알려면 디버거를 사용하거나, 컴파일시 디버깅 심볼을 함께 링크하거나 해야하고..

하지만 이 내용이 이해가 안됩니다..
구체적으로 예를 들어서
int i[5]={1,2,3,4,5};
이런 size=5인 int 형 배열이 있을때 i[20] 을 참조하면 ...
컴파일 과정에서도 충분히 오류라고 처리를 할 수 있는데요..
물론 실제 C,C++에선 오류로 처리하지 않고 있지만 말이죠..
불가능한게 아닌데요.. 당연히 소스코드에서의 해당라인과 위치까지도
충분히 알 수 있는데요.. 컴파일러를 좀더 잘 정성들여서 짜면 틀린 부분에
색깔도 넣을 수 있을텐데요..
이런특징이 왜 인터프리터에서만 가능하다는것인지 모르겠습니다.
그리고 디버그 라는것은 이러한 오류를 잡는게 아니라 로직에러를 잡는데 쓰이는것 아닌가요?? 한라인씩 실행시키면서 레지스터와 메모리 상태를 볼 수 있게 해주는 프로그램으로 컴파일러와는 좀 별개로 생각해야 되는것 아닌가요?
(디버그 모드로 가려면 코드자체에는 오류가 없어야 하는데요..)

이번학기에 과제로 [컴파일러],[어셈블러],[가상머신]
을 만들었습니다.
제작을 하면서 컴파일러와 인터프리터의 개념을 잡게 됐는데요..
혹시 제가 생각하는게 틀린가요?

컴파일러는 번역의 개념으로 원시소스 등의 input이 들어오고 output은
다른 소스코드(ex.어셈소스코드,기계어(실행코드)) 등이 될 수 있고...
인터프리터는 input은 동일한데 output은 또다른 코드를 내놓지 않고 곧바로
실행해서 실행결과를 얻는..
이런 개념으로 알고 있습니다.

즉 [컴파일러]와 [어셈블러]는 모두 컴파일러로 볼 수 있고
만약
[컴파일러]와 [어셈블러]와 [가상머신]을 합쳐서
실행버튼을 누르면
컴파일러->어셈블러->가상머신->결과 가 자동으로 나오도록 프로그램을
합쳐놓으면 이들을 묶어서 인터프리터로 볼 수 있는것 아닌가요?

이렇게 개념적인 차이로 인해서 발생하는 장단점이 궁금했습니다.

정리하면..
오류가 발생했을때 원시소스코드의 잘못된 위치를 쉽게 찾을 수 있는것은
컴파일 방식!!!,인터프리터 방식!!!의 차이에서 오는게 아니라 툴을 얼마나 정성들여서 만드냐에 따라서 좌우되는 문제 아닌가요?
마찬가지로 오류가 발생했을때 이어서 실행을 할 수 있다는 인터프리터방식의 장점도.. 컴파일러 툴을 어떻게 만드느냐에 따라서 컴파일 방식에서도 충분히 가능하리라 생각됩니다.
답변부탁드립니다.

superwtk의 이미지

쉘스크립트로

{가수} {앨범} - {트랙번호}. {곡명} 이렇게 된 파일 제목을
{가수} - {곡명} 이렇게 바꿔주는 스크립트를 작성했는데

그걸 컴파일 해서 사용해야 한다면... 귀찮죠-_-ㅋ

pool007의 이미지

gyxor wrote:

컴파일러를 좀더 잘 정성들여서 짜면 틀린 부분에
색깔도 넣을 수 있을텐데요..
...
컴파일러는 번역의 개념으로 원시소스 등의 input이 들어오고 output은
다른 소스코드(ex.어셈소스코드,기계어(실행코드)) 등이 될 수 있고...
인터프리터는 input은 동일한데 output은 또다른 코드를 내놓지 않고 곧바로
실행해서 실행결과를 얻는..
이런 개념으로 알고 있습니다.

정리하면..
오류가 발생했을때 원시소스코드의 잘못된 위치를 쉽게 찾을 수 있는것은
컴파일 방식!!!,인터프리터 방식!!!의 차이에서 오는게 아니라 툴을 얼마나 정성들여서 만드냐에 따라서 좌우되는 문제 아닌가요?

(1) 컴파일러에서 에러잡기

인터프리터를 작성해보셨으면 아시겠지만, 어디서 에러 잡는게 쉬운문제가 아닐텐데요.. 아마 컴파일러를 만드셨으면 컴파일러의 공룡책도 보셨겠죠? 그리고 거기서 보면 에러를 잡을 수 있는 다수의 방법이 소개되고 있고, 에러가 어디서 발생했는지 그대로 해보면 실제로는 잘 안된다는 것을 아실겁니다.. 정성 들이고 안들이고의 문제가 아닐걸요. 아직도 C에서는 '에러가 발생한 라인이 곧 에러의 원인이 아닐수도 있다'라는게 상식이잖아요?

(2) 컴파일러 vs 인터프리터

둘다 사실상 중간언어를 만들어내고, 그 중간언어가 하드웨어가 알아듣는 기계어인가 혹은 인터프리터가 알아듣는 기계어인가의 차이만 있을뿐입니다. 그리고 어셈블러는 컴파일러의 아웃풋을 받아 정말 머신코드로 바꿔주죠. lex/yacc을 쓰셨다면 인터프리터를 만들실때, yacc의 rule에서 곧바로 처리를 해주신듯 한데요.. 사실 그렇게 안하고 중간언어를 만든다음 중간언어에 대한 처리기를 다시 만들게 됩니다. 그렇게 하는 optimize할 찬스를 높히니까요.

(3) 정성들여 만들면 에러를 다 잡을 수 있다.

이게 되면 자연어 처리가 되는것 역시 문제가 아니겠죠.. 어떤 랭귀지 형태를 쓰셨는지 모르지만 분명 CFG일 가능성이 높을 것으로 생각되는데요. CFG에서 컨텍스트란게 없죠. 즉 semantic도 없죠. 그런 상태에서 어떻게 모든 에러를 다 잡나요. 컨텍스트가 없는데.. 튜링 computable 하게 만들려면 unrestricted grammar나 적어도 CSL 로 문법을 짜야할텐데, 그것도 쉬운게 아니죠.. 그리고 우리에겐 튜링 머신에게는 있는 무한의 테이프도 없죠;; 그래서 이런 랭귀지(오토마타의 측면에서의 랭귀지를 의미)를 만드는 것도 active research area에 해당합니다.

문제를 쉽게 생각해보죠.. 간단하게, 모든 경우를 다 따진다고 해보죠. 분기문이 n개가 있습니다. 이 경우 모든 경우를 다 따져보려면 2^n 이 되버립니다. 즉 NP가 되버려서 컴퓨터로 해결을 못하죠.. 역시나 컴파일러를 만들어보셨으니까 아시겠지만 CFG 자체만해도 무식하게 하면 N^3에 컴파일가능하고, 그나마도 문법을 제한하면서까지 - simmple grammar던가. 명칭을 잊었네요 - 해서 O(n)으로 떨어뜨리고 있는 상태인데 여기서 다시 O(2^n)으로 높히는건 안되죠. 컴파일러는 지금도 충분히 느린데요.

더구나 만약 실행경로가 사용자의 입력에 좌우된다면? 그런 경우 정말로 모든 경우 - NP - 를 다 테스트해야하는데 이걸 컴파일러에서 컴파일 단계에서 미리 해결할 수 있을까요? 그래서 결국 실시간 에러 잡기는 인터프리터의 손으로 가게되는 것입니다....

--
Passion is like genius; a miracle.

hiseob의 이미지

디버그 할때 한과정이 줄어들거 같은데요
컴파일 오류발생 -> 코드 수정 -> 컴파일 -> 실행후 확인
인터프리트 오류발생 -> 코드 수정 -> 실행후 확인

개발할떄의 장점은 이렇지만 쓰는 사람 입장에서는 또 이게...
컴파일 된것 -> 실행하면 됨
인터프리트 언어로 된것 -> 인터프리터 설치 -> 실행

컴으로 인터넷 ~ 게임 하는 정도의 사람에겐 좀 다른세계 이야기 일지도 모르죠.

속도도 java 가 c 에 비해서 빠르다거나 하진 않으니까요.

unipro의 이미지

gyxor wrote:

하지만 이 내용이 이해가 안됩니다..
구체적으로 예를 들어서
int i[5]={1,2,3,4,5};
이런 size=5인 int 형 배열이 있을때 i[20] 을 참조하면 ...
컴파일 과정에서도 충분히 오류라고 처리를 할 수 있는데요..
물론 실제 C,C++에선 오류로 처리하지 않고 있지만 말이죠..
불가능한게 아닌데요.. 당연히 소스코드에서의 해당라인과 위치까지도
충분히 알 수 있는데요.. 컴파일러를 좀더 잘 정성들여서 짜면 틀린 부분에
색깔도 넣을 수 있을텐데요..
이런특징이 왜 인터프리터에서만 가능하다는것인지 모르겠습니다.

int i[5]={1,2,3,4,5};
int idx = foo();
i[idx] = bar();
이런 부분은 컴파일 과정에서 처리할 수 없지 않을까요?

내 블로그: http://unipro.tistory.com

gyxor의 이미지

결국 핵심은 오류수정이....
[컴파일방식]처럼 컴파일타임에만 국한되느냐
[인터프리터방식]처럼 컴파일타임과 실행타임까지
관여하느냐의 차이에서 오는 것이었군요..
이제야..
"인터프리터 방식의 장점::
원시 프로그램 수준의 디버깅 연산을 쉽게 구현할 수 있는 장점을 갖는다.
이것은 모든 실행 시간 오류 메시지가 원시 수준 단위를 참조할 수 있기 때문이다.
예를 들면, 배열 인덱스가 범위를 벗어났다는 것이 발견되면,
오류 메시지는 원시 프로그램의 행과 배열 이름을 쉽게 나타낼 수 있다. "
이 내용이 이해가 됩니다..
정말 감사합니다.^^

lifthrasiir의 이미지

hiseob wrote:
개발할ㅤㄸㅒㅤ의 장점은 이렇지만 쓰는 사람 입장에서는 또 이게...
컴파일 된것 -> 실행하면 됨
인터프리트 언어로 된것 -> 인터프리터 설치 -> 실행

여러 인터프리팅 언어들(파이썬, 루비 등)에는 실행 파일을 만들어 주는 라이브러리가 있습니다. 물론 컴파일 수준은 아니고 dll을 붙인다거나 바이트코드 인터프리터 구현을 붙인다거나 하는 것이지만요.

- 토끼군

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.