ComputerProgrammingwithGNUSmalltalk:1.2: Difference between revisions
Onionmixer (talk | contribs) mNo edit summary |
Onionmixer (talk | contribs) mNo edit summary |
||
Line 38: | Line 38: | ||
의미심장한 격언으로 이번 주제를 끝마칠까 합니다. ‘더 고수준의 언어가 더 나은 언어를 의미하는 것은 아니다.’ 오늘날엔 일반적으로 어셈블리 또한 사용하고 있습니다. 그 이유는 하드웨어에 가장 가깝고, 하드웨어를 제어하는 데에 더욱 강력하기 때문입니다. 따라서 하드웨어 프로그래밍 기반을 갖추려 한다면, 아마도 어셈블리가 가장 좋은 선택이 될 것입니다. 또한 저수준의 언어라도, 여러분이 사용하는 고수준 언어에서 더 빠른 프로그램으로 만들기 위한 최적화 코드를 만들기 위해 사용하기도 합니다. 물론, 성능향상을 위해 어셈블리로 오피스 프로그램 같은 프로그램 전체를 만들겠다는 것은 어리석은 이야기입니다. 결과가 나올 때까지, 일반 고수준 언어로 개발하는 것보다 수백배에 달하는, 어마어마한 개발 시간과 엄청난 복잡도, 읽을 수 없는 소스코드들을 생각해보면 왜 고수준 언어로 관리를 해야하는지 알 수 있습니다. 따라서 여러분들은 현재 프로젝트에 대한 프로그래밍 언어를 선택하기 전에 프로젝트의 성격과 조건을 고려해봐야 합니다. 이는 다른 프로젝트에 다른 언어를 사용할 필요가 있다는 것을 의미합니다. | 의미심장한 격언으로 이번 주제를 끝마칠까 합니다. ‘더 고수준의 언어가 더 나은 언어를 의미하는 것은 아니다.’ 오늘날엔 일반적으로 어셈블리 또한 사용하고 있습니다. 그 이유는 하드웨어에 가장 가깝고, 하드웨어를 제어하는 데에 더욱 강력하기 때문입니다. 따라서 하드웨어 프로그래밍 기반을 갖추려 한다면, 아마도 어셈블리가 가장 좋은 선택이 될 것입니다. 또한 저수준의 언어라도, 여러분이 사용하는 고수준 언어에서 더 빠른 프로그램으로 만들기 위한 최적화 코드를 만들기 위해 사용하기도 합니다. 물론, 성능향상을 위해 어셈블리로 오피스 프로그램 같은 프로그램 전체를 만들겠다는 것은 어리석은 이야기입니다. 결과가 나올 때까지, 일반 고수준 언어로 개발하는 것보다 수백배에 달하는, 어마어마한 개발 시간과 엄청난 복잡도, 읽을 수 없는 소스코드들을 생각해보면 왜 고수준 언어로 관리를 해야하는지 알 수 있습니다. 따라서 여러분들은 현재 프로젝트에 대한 프로그래밍 언어를 선택하기 전에 프로젝트의 성격과 조건을 고려해봐야 합니다. 이는 다른 프로젝트에 다른 언어를 사용할 필요가 있다는 것을 의미합니다. | ||
[[image:chapter01_01.png|none|640px| | [[image:chapter01_01.png|none|640px|chapter01_01]] | ||
Line 51: | Line 51: | ||
(컴파일 결과나 인터프리테이션 과정의 결과가 아닌) 프로그래밍 언어로 쓴 코드를 소스코드라고 부릅니다. | (컴파일 결과나 인터프리테이션 과정의 결과가 아닌) 프로그래밍 언어로 쓴 코드를 소스코드라고 부릅니다. | ||
[[image:chapter01_02.png|none|640px| | [[image:chapter01_02.png|none|640px|chapter01_02]] | ||
위 그림은 컴파일 한 프로그램과 인터프리터 프로그램의 실행 과정 차이를 보여주고 있습니다. 사용자는 프로그램을 전달 받을 때, 컴파일 언어로 이용한 경우, 컴퓨터 메모리에 바로 기계어로 올릴 수 있는 프로그램을 받을 수 있지만, 인터프리터 언어로 작성한 경우, 소스코드만을 받아볼 수 있습니다. 인터프리터 언어로 만든 프로그램을 실행 할 때, 시스템은 소스코드 파일 형식을 인식하고, 기계어로 번역하기 위해 소스코드를 인터프리터로 전달합니다. 가끔은 시스템이 파일 형식을 인식하지 못하여서, 사용자가 직접 인터프리터에 파일을 전달해야 할 때가 있습니다. 알려주려는 점은, 인터프리터 언어는 실행할 때마다 추가 단계를 거쳐야 하며, 실행 시간이 느리다는 것입니다. | 위 그림은 컴파일 한 프로그램과 인터프리터 프로그램의 실행 과정 차이를 보여주고 있습니다. 사용자는 프로그램을 전달 받을 때, 컴파일 언어로 이용한 경우, 컴퓨터 메모리에 바로 기계어로 올릴 수 있는 프로그램을 받을 수 있지만, 인터프리터 언어로 작성한 경우, 소스코드만을 받아볼 수 있습니다. 인터프리터 언어로 만든 프로그램을 실행 할 때, 시스템은 소스코드 파일 형식을 인식하고, 기계어로 번역하기 위해 소스코드를 인터프리터로 전달합니다. 가끔은 시스템이 파일 형식을 인식하지 못하여서, 사용자가 직접 인터프리터에 파일을 전달해야 할 때가 있습니다. 알려주려는 점은, 인터프리터 언어는 실행할 때마다 추가 단계를 거쳐야 하며, 실행 시간이 느리다는 것입니다. |
Revision as of 11:00, 18 September 2012
프로그래밍 언어 형식
프로그래밍 언어는 다양한 속성에 따라 분류합니다. 몇 가지 속성에 대해 이야기해보겠습니다.
고수준 그리고 저수준 프로그래밍 언어
앞에서 먼저 말한 것처럼, 기계어는 인간이 이해하기 힘듭니다. 따라서 오늘날 인간이 사용하는 언어와 비슷한 언어를 만들었습니다. 이러한 언어는 얼마나 인간의 언어와 가까운가에 따라 분류할 수 있습니다. 기계어에 가까울수록, 저수준 프로그래밍 언어라 합니다. 반대로 인간의 언어에 가까울 수록 고수준 언어라고 합니다.
다음의 기계어를 보십시오.
011010111010001011000101
여러분은 이것이 무엇을 의미하는지 상상조차 할 수 있겠습니까? 이제 어셈블리라고 불리는 언어로 어떻게 표현하는지 봅시다.
MOVE d’3’, W
ADD d’4
이 코드가 무엇인지 여러분이 추측할 수 있는지는 모르겠습니다만, 기계 코드보다는 더 읽기 쉽다는 것은 명백합니다. 어셈블리 언어는 기계어보다는 더 고수준의 언어라고 말할 수 있겠습니다. 위의 두 줄의 코드가 무엇을 하는 것인지 궁금하십니까? 이 코드는 단순히 두 숫자를 더하는 내용입니다.
이제 GNU 스몰토크라고 불리는, 프로그래밍 언어로 쓰여진 같은 내용의 코드를 봅시다.(여태까지 이런 내용을 작성해 본 적이 없지만 말이죠.)
3 + 4
이 코드가 무슨 역할을 하는지 이미 알고 있다면, 굳이 여러분에게 물어보고 싶지는 않습니다. 만약 여러분이 모르겠다고 말씀하신다면, 이보다 더 명확하게 위의 코드가 무슨 역할을 하는지 설명할 수 있는 방법은 없습니다. 그러므로 기계어와 어셈블리, GNU 스몰토크를 비교해봤을 때, 가장 고수준의 언어는 GNU 스몰토크라고 할 수 있습니다.
예제가 아주 간단하고 명료해서, GNU 스몰토크가 진짜 영어같다고 기대하지는 마십시오. 최근에 자주 사용하는 다른 프로그래밍 언어와 비교하여 아주 고수준의 언어라는 평판을 가지고 있지만, 때때로 어셈블리로 혼동될 때도 있습니다.
의미심장한 격언으로 이번 주제를 끝마칠까 합니다. ‘더 고수준의 언어가 더 나은 언어를 의미하는 것은 아니다.’ 오늘날엔 일반적으로 어셈블리 또한 사용하고 있습니다. 그 이유는 하드웨어에 가장 가깝고, 하드웨어를 제어하는 데에 더욱 강력하기 때문입니다. 따라서 하드웨어 프로그래밍 기반을 갖추려 한다면, 아마도 어셈블리가 가장 좋은 선택이 될 것입니다. 또한 저수준의 언어라도, 여러분이 사용하는 고수준 언어에서 더 빠른 프로그램으로 만들기 위한 최적화 코드를 만들기 위해 사용하기도 합니다. 물론, 성능향상을 위해 어셈블리로 오피스 프로그램 같은 프로그램 전체를 만들겠다는 것은 어리석은 이야기입니다. 결과가 나올 때까지, 일반 고수준 언어로 개발하는 것보다 수백배에 달하는, 어마어마한 개발 시간과 엄청난 복잡도, 읽을 수 없는 소스코드들을 생각해보면 왜 고수준 언어로 관리를 해야하는지 알 수 있습니다. 따라서 여러분들은 현재 프로젝트에 대한 프로그래밍 언어를 선택하기 전에 프로젝트의 성격과 조건을 고려해봐야 합니다. 이는 다른 프로젝트에 다른 언어를 사용할 필요가 있다는 것을 의미합니다.
컴파일 언어, 인터프리터 언어
프로그래밍 언어로 프로그램을 작성한다는 것은 설명했었고, 이번엔 우리가 작성한 프로그램을 사람이 읽을 수 있는 프로그램에서 컴퓨터가 이해할 수 있는 형식으로 변환하는 단계에 대해 설명하겠습니다. 만약 전체 프로그램을 한 번에 기계어로 변환하면, 이 과정을 컴파일(원문에는 Compilation, 사전적 의미로 편집, 편찬)이라고 부르며, 이 결과물 형태로 컴퓨터 메모리에 유지합니다. 소프트웨어를 작성할 때, 실행하기 전에 컴파일 해야 하는 프로그래밍 언어로 작성되었다면, 이 언어는 컴파일 언어로 부릅니다. 이러한 컴파일 과정을 진행하는 소프트웨어를 컴파일러라고 부릅니다.
만약 프로그램을 우리가 쓴 대로 바로 변환한다면, 즉 한 줄, 한 줄씩, 더 정확하게는 명령문 하나씩을 바로 변환한다면, 이 과정을 인터프리테이션(Interpretation)이라고 하며, 그러한 언어들을 인터프리터 언어라고 합니다. 인터프리터 언어로 작성한 소프트웨어는 우리가 작성한 방식으로 유지하며, 매 회 실행할 때마다 기계어로 다시 번역하여 실행합니다. 이 과정을 실행하는 소프트웨어를 인터프리터라고 부릅니다.
(컴파일 결과나 인터프리테이션 과정의 결과가 아닌) 프로그래밍 언어로 쓴 코드를 소스코드라고 부릅니다.
위 그림은 컴파일 한 프로그램과 인터프리터 프로그램의 실행 과정 차이를 보여주고 있습니다. 사용자는 프로그램을 전달 받을 때, 컴파일 언어로 이용한 경우, 컴퓨터 메모리에 바로 기계어로 올릴 수 있는 프로그램을 받을 수 있지만, 인터프리터 언어로 작성한 경우, 소스코드만을 받아볼 수 있습니다. 인터프리터 언어로 만든 프로그램을 실행 할 때, 시스템은 소스코드 파일 형식을 인식하고, 기계어로 번역하기 위해 소스코드를 인터프리터로 전달합니다. 가끔은 시스템이 파일 형식을 인식하지 못하여서, 사용자가 직접 인터프리터에 파일을 전달해야 할 때가 있습니다. 알려주려는 점은, 인터프리터 언어는 실행할 때마다 추가 단계를 거쳐야 하며, 실행 시간이 느리다는 것입니다.
실제로 구조가 같은 언어에 대해서 컴파일러도, 인터프리터도 있을 수 있지만, 대부분의 언어는 은연중에 이 중 한 가지 언어로 설계합니다. 따라서 언어의 컴파일러 버전과 인터프리터 버전간에 차이가 있을 수 있습니다.
비록 프로그래밍 언어의 두 형태가 가장 인기있다 하더라도, 두 페러다임 외의 다른 형태의 언어 또한 있습니다. 이 페러다임은 소스코드를 인간이나 컴퓨터 모두 이해할 수 없는 중간 수준의 언어로 컴파일합니다. 이러한 수준의 변환을 보통 바이트코드 컴파일이라고 부릅니다. 이 과정은 하드웨어에 더 가까운 수준으로 소스코드를 변환하여, 하드웨어에서 사용하려 할 때, 기계어로 더 빠르게 변환할 수 있도록 만드는 것만으로 끝납니다. 바이트코드에서 기계어로 변환하는 과정은 가상머신이라고 불리는 프로그램이 수행합니다. 가상머신이 하는 일은 사용자가 프로그램을 실행할 때 바이트코드를 기계어로 인터프리팅하는 것입니다.
왜 이런 제 3의 언어가 존재하느냐 하면, 인터프리터 언어가 컴파일 언어에 비해 실행면에선 느린 반면 크로스 플랫폼의 잇점이 있기 때문입니다. 크로스 플랫폼이란 다른 OS나 프로세서 같은, 구조가 다른 컴퓨터상에서도 소프트웨어를 실행할 수 있다는 것을 의미합니다. 따라서 여러분이 작업하는 컴퓨터 시스템 안에 같은 인터프리터 언어가 있다면, 인터프리터 언어로 작성한 프로그램은 어떤 시스템에서나 실행할 수 있습니다. 어떤 하드웨어인지, OS인지 상관하지 않습니다. 만약 컴파일 언어로 소프트웨어를 컴파일한다면, 컴파일 했던 시스템과 같은 환경의 프로세서, OS에서만 실행할 수 있습니다. 컴파일 언어는 컴파일 한 후, 실행속도가 빠르다는 장점이 있지만, 소스코드에서 수정한 사항이 있을 때마다, 그리고 소프트웨어를 다른 플랫폼으로 옮길 때마다 다시 컴파일해야 한다는 단점이 있습니다. 바이트코드로 프로그램을 컴파일 한다는 것은 이러한 인터프리터 과정을 더 빠르게 만들고, 인터프리터 언어의 장점도 가지고 있다는 것을 의미합니다.
비록 GNU 스몰토크 함수가 인터프리터에 더 가까워도, 스몰토크는 가상 머신을 사용하는 언어로 설계하였습니다. 이런 형태의 언어로서 (또한, 가장 성공한 언어의 예로서) Java 프로그래밍 언어가 있습니다.
절차언어, 함수형 언어, 객체 지향 언어
또 다른 프로그래밍 언어의 범주는 언어의 페러다임에 따른 것입니다. 프로그래밍 페러다임이란, 문제 해결을 위해 프로그래밍 언어가 문제를 어떻게 바라보냐는 것입니다. 주로 세 가지의 프로그래밍 페러다임이 유명한데, 절차언어, 함수형 언어, 객체 지향 언어가 그것입니다. 간단하게 설명하기 위해, 그리고 여러분이 아직 모르는 용어에 대한 혼동을 피하기 위해 스몰토크의 핵심인 객체 지향 언어에 대한 설명만 하기로 하겠습니다.
객체지향 언어는 다른 객체들의 조합으로 ‘세계’라는 하나의 객체를 바라보는 방법입니다. 이 페러다임에 따르면 모든 것은 객체로 생각할 수 있습니다. 예를 들어, 컴퓨터, 텔레비전, 책 등은 모든 것이 객체입니다. 또한 이 객체의 모든 것은 다른 객체들의 조합입니다. 예를들어, 컴퓨터는 메인보드, 그래픽 카드, 하드디스크, 그리고 다른 하드웨어로, 이 모든 것 또한 객체이고, 이 객체들로 이루어져 있는 것입니다.
객체지향 프로그래밍은 일반적으로 인간의 사고와 가장 근접한 프로그래밍 페러다임으로 여깁니다. 따라서 여러분이 객체지향 프로그램을 작성할 때에는 더욱 편안함을 느끼고, 프로그래밍 구조나 역할 등을 걱정하는 대신 문제 해결에 집중할 수 있습니다.
프로그래밍 언어가 한가지 페러다임에만 한정되어 있을 의무는 없으며, 언어 구현 또한 그렇습니다. 실제로 개발자들이 프로그래밍을 하는 동안, 하나 이상의 페러다임으로 구현할 수 있는 언어를 멀티 페러다임 프로그래밍 언어라고 합니다. 프로그래머가 한가지 페러다임 만을 사용하여 프로그래밍 하도록 만든 언어를 싱글 페러다임 프로그래밍 언어라고 합니다.
스몰토크는 1세대 객체 지향 언어 중 하나이며, 순수한 객체 지향 프로그래밍 언어입니다. 즉, 싱글 페러다임 프로그래밍 언어이며, 객체로서 모든 것을 바라보고 개발해야 합니다.