현재 위치

홈 ›› Forums ›› 재미 ›› 자유 게시판

왜 인터프리터 언어들은 컴파일러를 만들지 않죠?

rubydoc의 이미지
글쓴이: rubydoc / 작성시간: 토, 2011/05/21 - 11:45오후

안녕하세요 프로그래밍을 한참 공부중인 대학생입니다.

제 지식이 미약하여 질문을 드립니다.

왜 루비와 같은 인터프리터 언어는 컴파일러를 따로 만들어 컴파일버전을 만들 수 없나요?

제 생각에는 루비와 같은 인터프리터 언어들의 단점 중 하나는 한 줄씩 컴파일하기 때문에 느리다는 점인데

그러면 컴파일러를 만들어서 컴파일하면 된다고 생각하는데 그렇게 하지 않는 이유가 뭔가요?

혹시 루비의 동적 타이핑이나 메타프로그래밍 같은 것들 때문인가요?

지식이 짧아 부끄럽지만 질문드립니다!

Forums: 
자유 게시판
익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/05/22 - 12:00오전

인터프리터로 쓰려고 만들었으니까요

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/05/22 - 12:03오전

컴파일은 빠른대신 ㅈㄴ 번거럽고 귀찮다는..

rubydoc의 이미지

글쓴이: rubydoc / 작성시간: 일, 2011/05/22 - 12:07오전

하지만 퍼포먼스가 중요한 부분은

외부 C 코드를 삽입하여도 좋지만

자바와 같은 가상머신 위에서 돌아가는 언어들이 C언어와 속도차이가 거의 나지 않는 것(1:1.6 정도라고 들었습니다.) 보면

루비와 같은 언어도 일정부분 미리 컴파일을 하면 성능 최적화를 쉽게 할 수 있지 않을까요?

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/05/22 - 12:44오전

루비도 vm 에서 돌아갑니다.
http://en.wikipedia.org/wiki/YARV
http://en.wikipedia.org/wiki/Jruby

.pyc(http://docs.python.org/release/1.5.1p1/tut/node43.html) 처럼 .rbc 이런거 만들어내면 좀 빨라질 듯.

neocoin의 이미지

글쓴이: neocoin / 작성시간: 일, 2011/05/22 - 12:54오전

vm 기반?

llvm을 jvm과 비교하기는 좀 애매하지만, rubinius 가 차세대 ruby 구현체의 자리를 차지하게 되리라 기대합니다.

snowall의 이미지

글쓴이: snowall / 작성시간: 일, 2011/05/22 - 12:06오전

만들어도 됩니다.

그리고 질문은 질문 게시판에...

피할 수 있을때 즐겨라! http://melotopia.net/b

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/05/22 - 3:55오전

안녕하세요 프로그래밍을 한참 공부중인 여학생입니다.

라고 보였네요.

술 먹고 정신줄을 놓은 듯

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 수, 2011/05/25 - 1:54오후

아깝네요. 잘못보신게 아니었으면 좋았을텐데..

handrake의 이미지

글쓴이: handrake / 작성시간: 일, 2011/05/22 - 5:33오전

그런 것 아닌가요. 가능은 하지만 JVM처럼 Runtime을 따로 받지 않고도 돌아가게 만들기는 상당히 어렵고요. 특히나 Ruby와 같은 Dynamic Language 같은 경우에는 Type Inference도 한계가 있는 편이 사실인데 그경우 Runtime을 만들자니 속도가 안나오고 안만들자니 컴파일러 구현이 너무 어려워지고 그런 난관에 봉착하게 됩니다. 파이썬도 비슷한 이유로 컴파일러가 잘 안나오고 있죠. 실험적인 Python->C++나 Python->C 등은 나왔지만 실제로 쓰기엔 제약이 많다는 사실.

planetarium의 이미지

글쓴이: planetarium / 작성시간: 월, 2011/05/23 - 12:16오전

GNU의 gcj 나, basic 툴들의 exe 파일 생성 기능 같은 것들은 어떤가요?

handrake의 이미지

글쓴이: handrake / 작성시간: 월, 2011/05/23 - 5:31오전

정적 타입의 언어입니다. Basic은 기능의 한계상 동적 타입이긴 하나 polymorphism등을 적극적으로 사용한다고 할 수 없어 컴파일러 제작이 비교적 용이할듯 하네요.

yielding의 이미지

글쓴이: yielding / 작성시간: 일, 2011/05/22 - 11:32오후

MacRuby는 그냥 인터프리터로 사용할 수 있지만 컴파일도 지원합니다. macrubyc가 있죠. 그냥 인터프리터 환경도 속도가 상당히 빠릅니다.

Extending, Embedding그리고 native compilation이 다 잘 지원되지요. 게다가 Mac App store에 MacRuby로 만든 프로그램을 등록할 수 있게 됩니다.

단점이라면 지금은 OS X에서만 사용할 수 있다는 이지요. 코드를 들여다 보면 다른 플랫폼에서 포팅이 안될 이유가 없어 보입니다.

Life rushes on, we are distracted

winner의 이미지

글쓴이: winner / 작성시간: 일, 2011/05/22 - 11:53오후

http://kldp.org/node/105142

lain07의 이미지

글쓴이: lain07 / 작성시간: 월, 2011/05/23 - 1:03오전

결론부터 말씀드리면 가능합니다.
단, 규칙을 좀 더 추가해야 할 것 같군요.


___________________________
I like Small Linux.

태훈의 이미지

글쓴이: 태훈 / 작성시간: 월, 2011/05/23 - 6:03오전

llvm-py(http://code.google.com/p/llvm-py/)로 파이썬 컴파일러 프로젝트 같이 하실분?

Just do it!

drinkme의 이미지

글쓴이: drinkme / 작성시간: 화, 2011/05/24 - 1:35오후

80년대도 아니고
요즘같은 세상에 컴파일/인터프리팅으로 언어 구분하는게
의미가 있나요?

dwlee의 이미지

글쓴이: dwlee / 작성시간: 수, 2011/05/25 - 1:37오후

하이퍼포먼스 컴퓨팅에서는 중요한 요소가 될 수 있지요 :)
아무리 최적화를 해도 인터프리팅 언어에는 한계가 있을 수 있거든요.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 수, 2011/05/25 - 1:51오후

커널마져도 인터프리터로 개발 가능한 시대가 오면 모를까 :)

rubydoc의 이미지

글쓴이: rubydoc / 작성시간: 수, 2011/05/25 - 6:52오후

저는 컴공과생은 아니어서 컴파일러 과목을 수강하지 않았습니다.(지식이 미약하여 죄송합니다;;)

이번에 컴파일러쪽 공부에 흥미가 생기면서

루비 컴파일러와 루비로 짠 php컴파일러 중 어떤 것을 해볼까 고민하는 중이었습니다.

여러분의 조언 감사합니다!

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2011/05/26 - 12:08오전

php 컴파일러로는 페이스북에서 공개한 hippop for php 도 있습니다.
참고해 볼만한 것 같습니다.

https://github.com/facebook/hiphop-php/wiki/

rubydoc의 이미지

글쓴이: rubydoc / 작성시간: 목, 2011/05/26 - 10:09오전

감..감사합니다!!

둘러보기