~cpp
Smalltalk에 대한 몇 가지 이야기
98. 11. 16. 김찬홍
mailto:andrea92@mail.hitel.net
이 글은 Smalltalk라는 프로그래밍 언어에 대한 몇 가지 중요한 이야기를 담고
있습니다. Dolphin Smalltalk 98을 만든 Object Arts라는 회사가 쓴 "Dolphin
Smalltalk White pager"의 내용에 제가 생각한 것을 몇 가지 덧붙여서 Smalltalk
에 대한 이야기를 시작해 보려 합니다.
사실 Smalltalk에 관한 국내의 자료는 매우 빈약한 편입니다. 이상하게도 우리
나라에서는 C/C++이 프로그래밍 언어의 주류를 이루고 있으며, 요즈음은 Delphi
와 Visual Basic도 점점 그 중요도를 더하고 있습니다. 그러나 정작 객체지향 프
로그래밍 언어의 조상이자 완결판이라고 할 수 있는 Smalltalk에 대한 자료는 거
의 찾아보기 어렵습니다. 이는 상용 Smalltalk 시스템의 가격이 만만치 않으며,
Smalltalk를 전산 교육 기관에서 별로 중요하지 않게 여기고 있기 때문이기도 합
니다.
그러나 90년대에 들어서면서부터 훌륭한 공개용 Smalltalk 시스템이 많이 배포되
고 있으며, 필자가 자료실에 올린 Dolphin Smalltalk 역시 그런 훌륭한 개발 환
경에 속합니다.
이제 미약하나마 저는 Smalltalk에 관한 자료를 조금씩 힘닿는 대로 여러분에게
소개시켜 드릴 것입니다. 물론 한 번에 많은 양을 드리지는 못하겠지만, 앞으로
올리는 자료가 여러분이 Smalltalk를 공부하는데 있어서 작으나마 도움이 되었으
면 하는 바램입니다.
먼저 Smalltalk 언어에 대한 기본적인 생각과 철학을 간단히 소개합니다. 흔히들
Smalltalk에 대해 가지기 쉬운 오해들 또한 여기에서 다루도록 하겠습니다. 그래
서 Smalltalk 언어는 배워볼 만한 가치가 있다는 것과 충분히 실제 응용
(application) 프로그램을 만드는데 사용할 수 있다는 것을 알려드리고자 합니
다.
1. 객체지향, 그리고 Smalltalk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
90년대 초에는 머지않아 무른모(software)는 객체(object)와 부품(component)를
사용하여 만들어질 것이라는 이야기가 무성했습니다. 과연 오늘날 많은 무른모들
이 객체와 부품으로 만들어지고 있으며, COM이나 CORBA와 같이 객체와 부품을 중
시하는 여러 가지 기술들이 개발 사용되고 있습니다. 80년대 초반에 등장하여 무
른모 개발에 하나의 커다란 사건이 되어버린 "객체 지향"(Object Oriented) 패러
다임은 오늘날에 와서는 사실상 무른모의 모든 영역에 적용되는 패러다임이 되어
버렸습니다.
이제는 어떻게 하면 질 좋은 무른모를 보다 빨리, 그리고 많이 만들 수 있느냐와
더불어 사용자의 요구에 따라 무른모를 얼마나 쉽게 유지.관리할 수 있느냐가 중
요한 문제로 대두되었으며, 객체지향 패러다임은 이런 문제를 해결할 수 있는 하
나의 대안을 제시해 주었습니다.
오늘날 많이 사용되고 있는 C++, Java, Object Pascal 등은 모두 프로그래밍 언
어에 객체 지향 패러다임을 적용시킨 좋은 예라고 할 수 있곘습니다. 그러나 이
러한 시도들은 기존에 존재하는 패러다임 위에 객체 지향 패러다임을 덧씌운 결
과를 초래하여, 필요 이상으로 복잡한 언어 명세를 만들게 되었으며, 기존의 구
조적 프로그래밍 습관에 익숙한 우리들에게 객체 지향 기법을 구현할 수 있는 생
각의 여유를 허용하지 않았습니다. 사람들은 자신이 이미 알고 있는 방식대로 프
로그래밍을 하고, 따라서 객체지향 언어로 만들어진 프로그램이 전혀 객체지향
답지 안은 프로그램이 되고 만 것입니다. 그래서 저는 순수하게 객체지향적인 관
점에서 문제를 바라보는 것이 어떨까 하고 생각하게 되었으며, 그래서 찾아내게
된 것이 바로 Smalltalk 언어입니다.
1980년대 초반에 처음 모습을 드러낸 Smalltalk 시스템은 당시의 무른모 위원회
(software community)에 의해 매우 중요한 객체지향 프로그래밍 환경으로 여겨
졌고, Smalltalk의 언어 명세는 다른 모든 객체지향 프로그래밍 언어의 잣대가
되었습니다. 또한 Smalltalk 환경에서 사용되는 많은 개념들이 우리가 현재 사용
하고 있는 Delphi나 Visual Basic 등에 적용되고 있는 것으로 볼 때, 이러한 객
체지향적인 환경은 매우 높은 생산성을 가지고 있다는 것을 보여주는 좋은 예라
고 하겠습니다.
그럼에도 불구하고 Smalltalk는 범용 프로그래밍 언어로써 사용되기에는 몇 가지
의 장벽을 가지고 있었습니다. Dolphin Smalltalk는 이러한 장벽들을 뛰어넘어서
마침내 Smalltalk도 하나의 훌륭한 개발환경이 될 수 있다는 것을 보여주고 있습
니다. 이는 비단 Dolphin Smalltalk만이 아니라, 널리 사용되고 있는 VisualAge
for Smalltalk나 Visual Smalltalk 등의 환경에도 똑같이 적용되고 있으며, 따라
서 이러한 장벽들은 분명히 해결될 수 있다는 것을 보여줍니다.
이제 흔히 평가되고 있는 Smalltalk에 대한 장벽들에는 어떤 것이 있는지 알아보
겠습니다. 대부분 Smalltalk에 대한 평가 중에는 오해해서 비롯된 것들이 많으
며, 이것이 Smalltalk가 범용 프로그래밍 언어로써 쓰이는데 하나의 커다란 장벽
이 되었던 것입니다.
2. Smalltalk는 느리다
~~~~~~~~~~~~~~~~~~~~~
1981년 8월에 출시된 "Smalltalk-80"은 첫 번째로 출시된 Smalltalk 시스템으로
써 큰 의미를 가지고 있었습니다. 이 Smalltalk-80이 제대로 돌아가려면 중대형
급 미니컴퓨터 이상의 성능을 가진 시스템이 필요했습니다. 요즘은 아무렇지도
않게 사용되고 있는 점으로 이루어진 그림(bitmap graphic)과 그래픽 사용자 환
경GUI), 모든 것이 객체이며 이 객체들 간에 존재하는 상속성, 그리고 기억 공간
을 효율적으로 관리하기 위한 쓰레기 수집(garbage collection) 등 처음
Smalltalk에서 소개된 이러한 개념을 구현하기 위해서는 그 당시로써는 매우 높
은 사양의 시스템이 필요했던 것입니다. 비록 이러한 기능들이 개인용 컴퓨터
(PC)에서 구현될 수는 있었겠지만, 80년대에 널리 사용되넌 PC에서 돌아가는
Smalltalk를 생각한다면? 아마 명령어 하나를 수행하는데 족히 몇 십초는 걸릴
것이 뻔했을 것입니다.
그러나 지금은 다릅니다. 무른모(hardware)는 눈부신 속도로 발전하여, 현재 우
리가 PC로 쓰고 있는 펜티엄급의 컴퓨터는 과거 80년대에 쓰이던 대형 컴퓨터의
성능을 훨씬 뛰어넘고 있습니다. 또한 무른모 역시 많이 발달하여 같은 시스템일
지라도 보다 효율적인 수행 성능을 보장할 수 있게 되었습니다. 이제 비로소
Smalltalk는 486DX 66 정도의 시스템에서도 충분히 잘 돌아갈 수 있게 되었으며,
흔히 우리들이 사용하고 있는 펜티엄급 컴퓨터에서는 더욱 더 최적의 성능을 발
휘하고 있습니다.
속도에 대해서 이야기할 때 수행 속도(running performance)와 더불어 빠질 수
없는 것으로는 개발 속도가 있습니다. 요즘과 같이 업무 처리 요구가 복잡한 경
우에는 해당 기능을 수행하는 모른모 역시 매우 복잡하게 구성될 수 밖에 없습니
다. 이제는 '쓸만하다'고 생각되는 프로그램을 둘러보면 그 덩치가 어마어마하게
비대해져있음을 볼 수 있습니다. 따라서 이러한 프로그램이 얼만큼 빠르게 실행
되는가도 중요하겠지만, 얼만큼 빨리 이러한 프로그램을 만들 수 있느냐에 대한
것도 상당한 관심의 대상이 되고 있습니다. 여러분은 개발하는데 6개월이 걸리
고, 실행하는데 3분이 걸리는 개발 환경과, 개발하는데 3개월이 걸리고 실행하는
데 6분이 걸리는 개발 환경이 있다면, 어느 쪽을 선택하겠습니까? 아마 대부분의
경우 후자를 선택할 것입니다. 일단 빠른 시간 안에 프로그램의 개발을 끝내 놓
으면, 남는 시간은 프로그램의 수행 속도 향상을 위해 충분히 할예할 수 있기 때
문입니다.
Smalltalk가 바로 그러한 시스템입니다. 분명히 몇 줄 안 되는 반복 수행문
(loop)의 수행 시간을 측정하면 Smalltalk는 널리 쓰이는 다른 언어(C, Object
Pascal 등)들보다 느린 것은 사실입니다. 그러나 이것은 Smalltalk가 제공하는
생산성과 융통성을 생각하면 충분히 희석되어질 수 있다고 생각합니다. Java 언
어 또한 결코 C 언어와 같은 속도를 내기는 어렵습니다. 그러나 Java가 가지고
있는 특성들은 충분히 많은 사람들이 Java에 빠져들도록 만들고 있습니다.
Smalltalk는 큰 시스템을 설계할 때 진가를 발휘합니다. 객체지향 패러다임이라
는 것이 원래는 간단한 문제를 해결하기보다는 큰 시스템을 어떻게 하면 쉽게 설
계하고 만들 수 있는가에 초점을 맞추었기 때문입니다. C에서는 두어 줄로 끝날
프로그램을, C++의 갈래(class)를 사용하여 열 줄로 짰다고 해서, C++ 언어가 C
보다 못하다는 사람은 없을 것입니다. 마찬가지로, Smalltalk 언어는 큰 시스템
을 설계하고 개발하는데 더욱 더 많은 힘을 나타냅니다. 이는 객체지향 패러다임
을 따르는 데서 오는 명확한 설계 때문에 가능한 것입니다.
Dolphin Smalltalk와 Delhi에서 원소수가 200만개인 배열 변수에서 어떤 값을 찾
아내는 실험을 했습니다.
<바탕글 1> 200만개의 배열에서 특정 원소를 찾는 Delphi 프로그램
----------------------------------------------------------
var
Data: array[1 .. 2000000] of Integer;
procedure TForm1.Button1Click(Sender: TObject);
var
i, Key: Integer;
begin
// 배열 초기화하기
for i := 1 to High( Data ) do
Data[i] := i * 2;
Key := 6500000; // 존재하지 않는 값.
for i := 1 to High( Data ) do
begin
if Data[i] = key then
begin
ShowMessage( IntToStr(i) );
Exit;
end;
end;
ShowMessage('못 찾음');
-----------------------------------------------------------
<바탕글 2> 200만개의 배열에서 특정 원소를 찾는 Smalltalk 프로그램
-----------------------------------------------------------
| data key |
"배열 초기화하기"
data := Array new: 2000000.
1 to: data size do: [ :i | data at: i put: i * 2. ].
key := 6500000. "존재하지 않는 값"
1 to: data size do: [ :i |
(data at: i) = key ifTrue: [
^MessageBox notify: i displayString
]
].
MessageBox notify: '못 찾음'.
-----------------------------------------------------------
위의 간단한 벤치마크 실험에서, Object Pascal을 사용하는 Delphi의 경우는 실
행하는데 0.5초도 소요되지 않은데 비해, Smalltalk의 경우는 약 5초의 시간이
경과했습니다. 이와 같이 32비트의 완전한 기계어로 번역되는 번역형 언어와 객
체지향 언어인 Smalltalk와의 단순 반복문 실행 성능은 매우 큰 차이를 보였습니
다. 이 비교를 보고 실망하는 여러분이 계시다면, 여러분이 Smalltalk에 대해서
어느 정도 알아갈 때까지, 그 실망을 잠시 접어두기를 권합니다. 정말,
Smalltalk에는 여러분이 지금까지 생각하지 못했던 순수 객체지향의 원리가 숨쉬
고 있으며, 이것은 여러분의 무른모 개발 주기를 크게 단축시켜 줄 것입니다. 이
단순한 실험 때문에 Smalltalk에 대한 공부를 중단하신다면, 여러분은 큰 것을
얻을 수 있는 기회를 잃는 것이라고, 다시 한 번 말씀 드립니다. (물론 필자도
처음 이 실험을 해 보고 Smalltalk의 느린 속도에 좀 실망을 했지만, Smalltalk
에는 과연 다른 언어가 제공하지 못하는 Smalltalk만의 그 무엇이 숨어있습니다.
분명히!)
아울러, 위의 예와 같이 극단적인 경우는 실제 프로그래밍에서 극히 드문 일이라
는 것을 참고로 말씀 드립니다. Smalltalk의 속도 때문에 실망하실 분이라면
PowerBuilder를 사용하여 위의 예제를 만들어 보시기를 권합니다. 또한 현재
Smalltalk는 실행 속도를 개선하기 위하여 많은 연구가 이루어지고 있다는 것도
참고로 말씀드립니다. 적어도 실행 속도의 문제에 있어서 Smalltalk는 JAVA와 같
은 문제를 안고 있다고 보시면 이해가 빠를 것입니다.
3. Smalltalk는 배우기 어렵다
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
이 말은 틀린 말입니다. Smalltalk의 언어 명세 자체는 그 이름에서 말해주듯이
매우 작으며, 따라서 C++나 Java언어와 같이 언어 명세와 문법이 복잡한 언어에
비해 익힐 것이 극히 적습니다. 이 사실은 별로 놀라울 것이 없는데, Smalltalk
언어를 설계한 Xerox사의 연구원들은 아이들이 쉽게 배워서 사용할 수 있고, 쉽
게 프로그래밍을 짤 수 있는 시스템을 개발을 원래 목표로 삼고 있었기 때문입니
다. 실제로 Smalltalk 언어를 공부한 지 두 달이 되는 초등학교 5학년 학생이 헬
리콥터 시뮬레이터를 제작했다는 사실이 Smalltalk 시스템이 매우 뒵다는 것을
증명해 줍니다(월간 마이크로소프트, 정보시대).
이런 오해는 아마 다음의 두 가지 영역에서 기인한 것으로 생각됩니다.
우선, Smalltalk 언어는 주로 사용되는 언어들에 비해서 매우 다르다는 것입니
다. C++나 Java와 같이 언어 명세와 문법이 매우 복잡하여, 그것을 익히는데 상
당한 시간을 소비했던 사람들은 몇 가지도 안 되는 개념으로 이루어진 Smalltalk
의 간결한 문법에 적응하기가 어려울 수도 있을 것입니다. Smalltalk 언어는 "객
체에게 지시를 내리면, 객체는 그 지시에 따라 반응한다"는 개념을 토대로 문법
을 형성해 나아갑니다. 즉 다른 언어처럼 문법을 규정짓는 것이 아니라, 객체에
게 보내는 지시가 자연히 Smalltalk의 문법을 이루는 것입니다. 이는 흡사 인간
의 언어 체계와 비슷하다고 할 수 있습니다. (문법이 먼저 생긴 것이 아니라 말
을 하다 보니 거기서 문법이 형성된 것입니다.)
더욱이 Smalltalk 언어의 바탕글(source code)을 보면 다른 언어들과 그 모양이
매우 다름을 알 수 있습니다.(<바탕글 1>과 <바탕글 2>를 비교해 보십시오) 그러
나 모양이 다르기 때문에 어렵게 보일 뿐입니다. 실제로 Smalltalk의 몇 가지 개
념을 알고 나면 바탕글을 매우 쉽게 읽을 수 있습니다.
Smalltalk가 어렵다고 느껴지는 이유 중 가장 큰 문제는 Smalltalk가 가지고 있
는 방대하면서도 확장성이 뛰어난 갈래 다발(class library)때문이 아닐까 합니
다. Smalltalk로 쓸만한 프로그램을 만들기 위해서는 필요로 하는 기능이 수백개
가 넘는 방대한 갈래 중에서 도대체 어떤 갈래에 속해 있는지에 대해서 꿰고 있
어야 하는데, 이것이 일반적으로 프로그래밍의 초보자가 정말 넘기 힘든 '장벽'
이 되어버리는 것입니다. Smalltalk를 사용해서 저 유명한 "Hello, world!"를 출
력하는 완전한 프로그램을 만들고 그것을 이해하려면 어느 정도의 시간이 필요합
니다. 그러나 Smalltalk에서 Hello World 프로그램을 만들 수 있다면, 그 다음은
정말 쉽게 쉽게 넘어갈 수 있습니다. C 언어의 경우, Hello World 프로그램을 만
들기는 쉽지만, 이것만 가지고는 C 언어에서 공부해야 할 기능 중에 10%도 안 되
는 내용밖에 알 수 없습니다. Smalltalk에서 Hello World 프로그램을 만들고 그
것을 이해했다면, Smalltalk 언어의 80% 이상을 정복했다고 해도 과언이 아닐 것
입니다.
그런데 갈래 다발을 익히는 것이 어려워서 Smalltalk가 어렵다면, 이는 C++,
Java 그리고 쉽다고 여겨지는 Delphi나 Visual Basic을 공부하는 것 역시 어렵다
고 봐야합니다. Visual C++를 가지고 프로그램을 짜려면 적어도 MFC(Microsoft
Foundation Classes)라는 갈래 다발을 익혀야 하고, Delphi의 경우에는 VCL
(Visual Component Library)을 공부해야 하며, Java의 경우네는 JavaBeans나 여
러 가지의 꾸러미(package)에 대해서 어느 정도의 지식이 필요합니다.
마지막으로, Smalltalk 시스템은 대화식입니다. 예전에 베이식을 공부해 본 분이
라면 대화식 개발 방법이 얼마나 쉬운지를 알 것입니다. Smalltalk에서는 명령어
를 한 줄 단위로 실행시켜볼 수 있으며, 그 결과를 바로 알 수 있습니다. 컴퓨터
와 대화하듯이 어떤 일을 처리할 수 있기 때문에, 익히기가 매우 쉽습니다. 규정
된 문법에 의해 바탕글을 쓰고 그것을 번역(compile)하여 실행해야만 결과를 얻
을 수 있는 언어들에 비해서, Smalltalk의 경우에는 대화식으로 명령어를 수행할
수 있는 언어이기 때문에 특히 초보자들이 배우기가 매우 쉽다고 할 수 있습니
다. 앞서 말씀드렸지만, Smalltalk의 모토는 "어린아이들도 쉽게 프고그램을 짤
수 있는 환경을 만들자"는 것입니다. (물론 그 '어린아이'가 영어권에 익숙해야
한다는 것이 마음이 아픕니다만...)
이런 것들을 공부하면서 동시에 복잡한 언어 명세를 공부하는 것과, 단순한 언어
명세와 대화식 개발를 지원하는 Smalltalk를 공부하는 것 중에, 과연 어떤 것이
더 어려워 보일까요? 그것은 독자 여러분의 판단에 맞깁니다.
4. Smalltalk은 비싸다
~~~~~~~~~~~~~~~~~~~~~
이는 아주 간단하게 예를 들 수 있습니다. 공개용 Smalltalk 시스템이 많이 나와
있으며, Dolphin Smalltalk의 경우에도 상용 제품과 공개용 제품을 같이 내놓고
있습니다. 또한 Dolphin Smalltalk 상용판의 경우는 약 $50 정도의 가격으로 충
분히 구입할 수 있으며, 데이터베이스나 응용 프로그램 배포 등의 기능을 포함한
꾸러미 형태로 판매되는 제품의 경우 $219 정도의 가격이면 충분히 구할 수 있습
니다. Smalltalk가 비쌉니까?
5. Smalltalk는 크다
~~~~~~~~~~~~~~~~~~~
Smalltalk라는 이름 자체가 이 말이 사실이 아님을 증명해 줍니다. Smalltalk는
작은 시스템입니다. 이는 장점이 될 수도 있고 동시에 단점이 될 수도 있습니다.
ANSI X3J20표준에 의해 규정된 갈래 씻줄(class hierarchy)은 흔히 볼 수 있는
다른 객체 지향 언어의 갈래 다발보다 더 많은 것을 담고 있습니다. C++의 경우
ANSI에서 표준화된 갈래 다발은 기본적인 것들 뿐이고 대부분 C++를 만들어 파는
회사마다 독자적인 갈래 다발을 만들어 사용하고 있으며, 따라서 이는 흔히 말하
는 것처럼 호환성 좋은 C++를 자꾸 호환성 없는 언어로 만드는 요인이 되고 있습
니다(Visual C++의 MFC와 Borland C++의 OWL을 생각해 봅시다.) ANSI 표준을 따
르는 Smalltalk의경우는 기본적으로 방대한 양의 갈래 다발을 가지고 있지만, 이
는 이미 표준화 된 것이기 때문에 Smalltalk의 호환성을 높여주는 촉매제가 됩니
다.
이러한 방대한 갈래 다발이 표준화됨으로써 생겨나는 단점으로는 Smalltalk로 프
로그램을 개발할 때, Smalltalk 환경 자체가 방대해질 수 있다는 것을 들 수 있
습니다. 물론 실제 응용 프로그램을 배포할 때에는 개발 단계에서보다는 훨씬 작
은 크기로 배포가 가능하지만, 현재의 Smalltalk 구현 기술로는 아직까지 다른
언어로 만들어진 프로그램들보다는 기억 공간의 소비가 크다는 단점을 가지고 있
습니다.
그러나 Dolphin Smalltalk의 경우는 보통 구현되는 Smalltalk의 특성보다 한 단
계 발전된 기술을 사용함으로써, 실행 파일이 차지하는 기억 공간의 점유율을 매
우 낮게 할 수 있었으며, 이는 Dolphin Smalltalk가 다른 Smalltalk에 비해서 월
등한 성능을 보장할 수 있도록 해 준다고 합니다.
기억공간 소비가 심하다는 평가에 대해서, Delphi나 Visual Basic의 경우와 비교
해 보십시오. 자원 측정기를 켜 놓은 상태에서 Delphi 4.0을 실행할 경우, 약
10% 전후의 자원을 소비하며, 이는 개발 프로그램이 커지면 커질수록 더욱 더 많
이 소비하게 됩니다. (프로젝트에 따라서는 약 30%의 자원을 소비할 때도 있었습
니다.) 그러나 Dolphin Smalltalk의 경우에는 기본적으로 약 3%의 자원을 소비합
니다. 이는 이미 모든 갈래 다발과 객체들이 다 생성된 상태에서 차지하는 기억
공간의 점유율입니다. (보통 배포되는 Dolphin Smalltalk에는 약 540개의 갈래와
45,000여개의 객체가 들어있습니다.)
어찌보면 Smalltalk는 큽니다. 그러나 또한 작습니다. 큰 것이 무조건 단점이 될
수만은 없는 것입니다. 그런데, 정말 Smalltalk가 큽니까? 그런지 그렇지 않은지
는 여러분이 직접 Smalltalk를 곱우해 보면 알 수 있을 것입니다.
6. Smalltalk는 연구용 언어이다
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
아마 이 문제는 Smalltalk 언어가 개발된 곳이 Xerox 연구소이며, 따라서 상용
번역기 개발 회사들이 내놓는 것보다는 낮은 실행 속도 때문에 기인한 것이라고
생각합니다. 흔히 Delphi나 Visual Basic, C++ 등으로 Windows 용의 응용 프로그
램을 만들려고 할 때 매우 높은 시스템 사양이 필요합니다. 그러나 Smalltalk는
그렇지 않다고 앞서도 언급한 바 있습니다. 또한 Smalltalk가 개발될 때 원래부
터 사용자 인터페이스를 생성하는 방법이 마련되어 있었으며, 예전에는
Smalltalk를 운영체계로 쓰는 컴퓨터도 있었습니다. 더욱이 Dolphin Smalltalk의
경우에는 WIN32 API를 90% 이상 지원합니다. 따라서 응용 프로그램을 만드는데도
결코 다른 개발 환경에 비해서 뒤떨어지지 않습니다.
7. 요약
~~~~~~~
Smalltalk, 특히 Dolphin Smalltalk는 다음을 지원합니다.
* Dolphin Smalltalk는 학습이나 실제 응용 프로그램을 개발할 수 있는 공개용
Smalltalk를 배포합니다. 이제는 개발 환경의 구입 가격 때문에 망설이는 일
이 없을 것입니다.
* 상대적으로 작은 Smalltalk의 개발 환경은 낮은 사양의 컴퓨터에서도 충분히
응용 프로그램을 개발할 수 있도록 할 수 있을 것입니다.
* ANSI X3J20에서 Smalltalk의 표준을 정하고 있으며, Smalltalk는 C++와 더불어
산업 표준이 되어가고 있습니다.
* Dolphin Smalltalk에서 제공하는 '3계층 응용 프로그램 모형'(three tiered
application framework)은 프로그램을 매우 융통성있게 만들어 줍니다.
* Dolphin Smalltalk는 Windows 시스템의 모든 자원을 사용할 수 있으며,
Windows 운영 체계의 지원을 받을 수 있습니다. 이는 WIN32 API의 사용을 보
장해주며, 따라서 WIndows 응용 프로그램의 개발을 쉽게 해 줍니다.
이제 Smalltalk를 한 번 공부해 보십시오. 작게는 여러분의 객체지향 패러다임을
익히는 도구로써, 크게는 실제 프로젝트를 개발할 수 있는 도구로써, Smalltalk
는 여러분에게 큰 몫을 할 것입니다. 자료실에 올려진 Dolphin Smalltalk와
Dolphin Education Center를 내리받고 Smalltalk 공부를 시작해 보십시오. 그리
고 우리 함께 공부합시다. 그래서 Smalltalk의 자료가 더 이상 빈약하지 않도록
합시다.
아룰로 필자는 Smalltalk도 하나의 도구로 생각합니다. 저는 Delphi를 주로 사용
하는데, Smalltalk를 공부하면서 델파이를 바라보는 시각이 바뀌었습니다. 좀 더
질서있고, 관리하기 쉬운 코드를 쓸 수 있게 되었습니다. 객체 지향이 무엇인지,
정말 진정한 객체지향의 진수를 맛보고 싶으시다면, Smalltalk를 꼭 권해드립니
다. 같이 공부합시다.