May 27, 2005 02:27
아래의 글은 저의 블로그를 둘러보신 어떤 분(이름을 밝히지는 않겠습니다)께서 질문을 해 주신 것에 대한 답변입니다. Smalltalk의 여러 가지 특징, 제가 Smalltlak를 역설하는 이유 등을 보실 수 있기 때문에 여기에 올려드립니다.
차례
안녕하십니까? 질문하신 것에 대해서 답을 드리겠습니다.
1. 기계공학이란 무엇인가?
우선, 기계공학에서 어떤 것이 필요한지에 대해서 제가 잘 모르는 관계로 정확하게 대답을 드리기는 힘들 것 같습니다. 제가 이해하고 있는 기계공학은, 하드웨어를 설계하는 것에 대한 제반 사항을 공부하는 것 같은데요.... 꼭 컴퓨터쪽이 아니더라도, 공장 자동화나 로봇 설계 같은 것도 기계 공학에 들어가나요?
만약 그렇다면 프로그래밍의 로직을 공부하시면 도움이 많이 되실 것 같습니다. 나중에 Embeded System Programming에도 도움이 되시겠지요.
2. C언어에 대해서...
기계어와 
어셈블리 언어를 제외하고 기계와 가장 친한 언어는 
C 언어라고 생각합니다. 기계어는 대부분의 마이크로프로세서와 환경에서 돌아가는 컴파일러를 가지고 있을 정도이니 아마 님께서 나중에는 결국 C언어를 필히 공부하셔야 할 때가 올 거라고 봅니다.
3. 그럼 어떤 언어를 선택할 것인가?
하지만 결코 C언어가 '프로그래밍'을 배우기 시작하는 사람에게 적합하다고 생각하지 않습니다. 결국 다른 선택을 하셔야 하는데, 님께서 예로 드신 
C++, 
C#, 
Smalltalk 모두 어찌보면 embeded programing 이라는 분야에서는 적합하지 않을지도 모릅니다.
사실 이런 객체지향 언어들이 RAM과 ROM을 통틀어서 64KB 내외인 작은 시스템에서 제 성능을 내며 돌아가기는 무리거든요. 하지만 기계를 제어하는 쪽이 컴퓨터이고, 컴퓨터와 연결해서 기계를 제어해야 한다면 결국 컴퓨터 쪽에서도 사용할 수 있는 언어를 선택하시는 것이 중요하다고 봅니다.
- C++: Learnning Curve가 가장 가파른 언어입니다. 적어도 객체지향 개념을 공부하실 때에는 선택하지 말아야 하는 언어입니다. 제대로 알고 있으면 C++의 제 성능을 낼 수 있지만, 제대로 알기 까지 너무나 많은 시간이 걸립니다. 언어의 복잡성도 가장 심합니다.
- C#:Java 의 좋은 점을 가지고 온 언어입니다. .NET 프레임워크에서만 돌아가는 제한점은 있지만 MS의 모토는 '모든 기계에서의 .NET'을 표방하므로 앞으로 embeded programming을 지원하는 .NET이 나올지도 모르겠습니다. 비교적 C++보다는 훨씬 객체지향적이지만, Smalltalk의 장점을 잘 생각해 보시고 결정하셔야 할 부분인 듯 합니다. 분명 현재 가장 뜨고 있는 언어인 건 확실하니까요.
- Java : 글에서는 다루고 있지 않으시지만, 사실 전자제품을 위해 탄생한 Java이기 때문에, 님의 경우와 가장 잘 맞아떨어질 거라고 추측해봅니다. 제가 알기로 상당히 작은 장치에서 돌아가는 Java 가상 머신도 있다고 하니, C++ 보다는 차라리 Java쪽의 선택이 나은 것 같기도 합니다.
이들 언어 모두의 장점은 '자료가 풍부하다'는 점일 겁니다. 그러니 훨씬 좋은 지원을 받으실 수도 있겠고요.
- Smalltalk: 이 아래의 내용은 모두 Smalltalk의 장점을 설명하는 내용이므로, 여기서는 일단 단점부터 말씀드립니다
- 자료가 비교적 적습니다. 대부분이 영문 자료이고 한글 자료를 구하기도 어렵습니다.
- 책 역시 국내에서는 찾기가 힘듭니다. (다행이 제가 10권 남짓 되는 PDF 로 된 Smalltalk 책이 있기는 합니다)
- 말씀하신 대로 인지도가 낮습니다. 만약 Team Project를 하셔야 하고, 다른 분이 Smalltalk에 대해서 모르신다면 의사소통에 문제가 생길 수도 있습니다.
- C언어에 비해서 제한적인 환경을 가집니다. 즉 어떤 환경에서는 C언어의 컴파일러가 제공되지만 Smalltalk 환경은 구비되어 있지 않을 수도 있습니다.
- C언어에 비해서 동작 속도가 조금 떨어집니다. 하지만 이는 C#과 Java도 같은 문제에 직면하고 있으므로, Smalltalk 만의 단점이라고 하기는 어렵겠습니다.
자, 그러면 과연 어떤 언어를 선택해야 할까요?
4. 공학 계산 분야
우선 'Smalltalk의 실무 적용성'에 대해서는 조금 뒤에 논의해 보기로하고, 여기서는 님께서 지적하신 다른 사항에 대해서 말씀드리겠습니다.
공학 계산이라면 어떤 종류의 계산이 필요한지 모르겠습니다. 일단 Smalltalk에서 계산이 가능한 범위를 말씀드리겠습니다. 구현(Implementation)마다 약간의 차이는 있지만, 대다수의 Smalltak 시스템은
- 정수 연산: 일반적인 사칙연산 및 최대공약수, 최소공배수 등을 구해줍니다.
- 큰 정수 연산: 20000의 factorial()이나 2의 100000 제곱() 과 같은 아주 큰 정수, 혹은 아주 작은 정수를 다룰 수 있습니다.
- 부동소수점 연산: 다른 언어가 지원하는 각종 삼각함수(sin, cos, tan, atan, log, log10, sqrt) 등의 계산이 가능합니다.
- 고정소수점 연산: 자리수가 무한한 Scaled Decimal 자료형이 있습니다. 이를 이용하면 10만 자리의 원주율 구하기나 황금율 구하기와 같이 아주 큰 자릿수의 계산이 가능합니다. 컴퓨터의 메모리와 성능에 따라 그 한계가 지어질 뿐, 프로그래머는 거의 자기가 표현하고 싶은 자리 만큼의 소수를 사용할 수 있습니다.
- 분수: 다른 언어에는 없는 Smalltalk 만의 특징으로, 기본적으로 나눗셈에서 몫이 나누어 떨어지지 않으면 분수로 변환됩니다. 약분, 통분, 역수 등을 구할 수 있으며, 필요하면 언제라도 부동소수점이나 고정소수점으로 변환할 수 있습니다. 물론 그 역도 가능합니다.
- 복소수(complex): 기본적으로 지원되지는 않지만, 이미 나와 있는 라이브러리를 통해서 C#이나 C++ 등 다른 언어보다 더 쉽게 복소수 연산을 지원받을 수 있습니다.
- 집합 연산이 가능합니다. 합집합, 차집합, 교집합 등을 구할 수 있습니다.
- 2차원 및 3차원 좌표 계산이 가능합니다.
- 2에서 36까지 자유롭게 밑(base)으로 하는 기수법을 쓸 수 있습니다.
2r1101은 10진수 13이고,8r111은 73이며,16rFFFF는 65535 입니다.36r1AXZ는 60839 입니다. (36진법을 쓰셔야 할 때가 언제일지는 잘 모르겠습니다)
대략 이정도입니다. Smalltalk의 계산 능력은 (추가적인 제품이나 라이브러리를 구입하지 않은 상태에서) 다른 언어와 비교 자체가 안 됩니다. 그리고 Smalltalk에 없는 기능은 사용자가 직접 만들어서 사용하면 됩니다. 대부분의 경우 님께서 필요한 공식을 알고 있다면, Smaltlalk에 바로 적용할 수 있을 것입니다. (소수 구하기 등)
이상이 제가 생각할 수 있는 '공학용 계산 분야'입니다. 대부분의 공학용 계산기가 하는 일을 할 수 있습니다.
5. 제어분야와 객체지향
제가 제어분야에 대해서 잘은 모르지만, Smalltalk에서의 가장 큰 특성은 '살아있는 개체와 대화하는 프로그래밍'(live object interactive programming)이라고 할 수 있습니다. 우선 아래의 URL을 소개해 드립니다.
약간 아래쪽을 보시면 TIMO라는 로보트를 Smalltalk로 제어하는 글이 있습니다. 영어이기는 하지만 나름대로 도움이 되실 겁니다. 잘 찾아보시면 프리젠테이션의 원고 PDF 역시 보실 수 있습니다.
만약 어떤 특별한 기계 장치가 있고, 이 기계 장치를 지원하는 device-driver나 라이브러리가 C언어로 작성된 DLL 의 형태로 배포된다고 하면, 제가 사용하는 Dolphin Smalltalk에서는 이 DLL을 직접 매핑할 수 있습니다.
그리고 님이 그 기계에 대해서 충분히 추상화를 하시게 되면 이런 비슷한 코딩이 가능합니다. 아래는 님이 Super Drill 이라는 드릴에 대한 DLL 라이브러리를 가지고 있고, 충분히 추상화 하신 뒤라고 가정하겠습니다.
myDrill := SuperDrill new. myDrill on; rpm: 1000. (myDrill temperature > 100) ifTrue: [ MessageBox warning: 'Dangerous!'. myDrill off.].
즉 님이 어떤 기계가 있다면 그것을 객체로 모델링하기만 하면 바로 그 기계와 대화가 가능합니다. 그러니깐 MS-DOS에서 명령을 내리는 것과 비슷하게 기계를 대화식으로 제어가 가능하다는 말입니다.
만약 GUI가 필요하면 기본적으로 기계를 모델링 한 뒤에 UI를 붙이면 됩니다. 물론 공부를 하셔야 하지만, C++에서 MFC를 공부하시는 경우와 마찬가지로 Smalltalk의 UI 프레임 워크도 공부하셔야 겠지요.
C나 C++, C# 등은 이렇게 대화식으로 기계를 통제하기 어렵고, 따라서 프로그램을 바로 테스트를 하기가 곤란합니다. Smalltalk는 그런 면에서 작은 부분들을 완성하고 바로 바로 테스트 해 볼 수 있기 때문에 훨씬 신뢰성 있게 프로그램을 짤 수 있습니다.
6. Smalltalk의 전망
이는 크게 세 가지 측면에서 생각해 볼 수 있습니다.
1) 대중성
이 측면만을 놓고 보자면 앞으로의 Smalltalk의 미래는 어둡습니다. Java 는 언어가 훌륭해서 뜬 것이 아니라 Sun의 지원 때문이었고, Visual Basic이나 C#, C++, 역시 MS의 지원 때문에 대중적인 언어가 되었습니다.
Smalltalk는 이렇게 뒤에서 든든하게 받쳐줄 Vendor가 없습니다. IBM 역시 Smalltalk에서 손을 뗐습니다. 이는 Smalltalk 언어 자체의 결합이라기 보다는 기본적으로 Smalltalk를 구입한 사람들에게 모든 소스를 공개하는 관례가 있는 Smalltalk에서 충분한 사업 모델을 못 찾아낸 탓이겠지요.
따라서 앞으로도 Smalltalk가, 특히 우리나라와 같이 "뭐가 좋다" 하면 "와~" 하고 천편일률적으로 달려드는 특성이 있는 곳에서는 Smalltalk가 대중화 되기란 거의 불가능에 가깝습니다.
2) 언어 개념의 완성도
제가 약 10년 전에 
Forth라는 프로그래밍 언어를 배운 적이 있습니다. 님이 몸담고 계시는 기계공학에는 Forth만큼 좋은 언어가 없습니다. Forth 언어는 너무나 작고 간단히 구현이 가능해서 8kB의 RAM을 가진 시스템에서도 기본적인 동작이 가능할 정도로 작습니다. Stack-based 언어인 이 Forth 역시 Smalltalk와 몇 가지 닮은 점이 있는데, 우선 확장이 용이하고, 마음에 들지 않으면 쉽게 바꿀 수 있습니다. Stack-based 인 것도 Smalltalk와 유사합니다.
하지만 Forth를 1년 배워보고 저는 포기했습니다. Forth는 다른 언어들과는 너무나 계념이 달랐고, 따라서 다른 곳에서 배운 것을 적용하기도 곤란했습니다. 다른 언어로 된 라이브러리를 불러서 쓰는 것도 곤란했습니다. (물론 가능은 합니다만 어렵습니다)
그래서 96년부터 시작하게 된 게 이 Smalltalk 입니다. 일단 Smalltalk 는 현재 프로그래밍에서 주류로 다루어지는 '객체지향 개념'을 가장 완벽하게 지원하는 언어입니다. 현재 '객체지향 언어'라고 불리는 모든 언어들은 모두 Smalltalk의 영향을 받았다고 감히 말씀드립니다.
그리고 Smalltalk만이 가장 완벽하고 순수하게 객체지향을 지원합니다.
저는 깜짝깜짝 놀랍니다. 디자인 패턴, 익스트림 프로그래밍, 리팩토링, 컴포넌트 기반 개발방법론, C++의 전유물처럼 생각해 왔던 template를 이용한 제너릭 프로그래밍 등등...
이런 것들은 이미 Smalltalk가 구했던 개념들이고, 모두 Smalltalk에서 비롯되었습니다. 결국 Smalltalk를 공부한다는 것은 이렇게 여러 사람들이 이미 사용하고 있는 개념을 나도 같이 배우는 것이 됩니다.
제가 Forth를 배우면서는 나만 완전히 다른 세계에 고립되어 있다는 느낌이 강했는데, Smalltalk를 배우면서는 다른 언어에서 그렇게 어렵게 말하고 구현하려고 헀던 내용들이 여기서는 이렇게 쉬웠구나~ 하는 것입니다. 나중에는 정말 뿌듯~ 해 지더군요.
C#/Java/C+++ 같은 언어에서 100 만큼 노력을 들여야 할 일을 Smalltalk에서는 50 만큼만 들이면 똑같이, 그리고 더 우아하게 할 수 있다는 게 지금도 신기하게 여겨집니다.
Smalltalk를 공부하시게 되면 아시게 되겠지만, Smalltalk 에서는 어떤 일을 할 때 '객체에게 메시지를 보내서' 일을 합니다. 따라서 새로운 개념이 생기면, 그 개념을 잘 지원할 수 있는 객체를 설계하기만 하면 됩니다. 이것은 Smalltalk를 무척 확장성이 뛰어나게 만듭니다.
Smalltalk에 발을 들여놓지 않은 사람들은 느끼지 못하는 '선도자'(파이오니아)적인 느낌... 이건 정말 느껴보지 않으시면 모를 겁니다. 이는 Smalltalk 언어가 그만큼 완성도가 뛰어나다는 것을 방증해 줍니다.
3) 접합성
그런데 아무리 좋은 언어라도 다른 것을 불러다 쓰지 못하고 모든 걸 처음부터 다시 만들어야 한다면 여간 곤란한 게 아닐 겁니다. Forth를 배울 때에는 그랬습니다. 없는 게 너무 많았고, 그래서 제가 모든 걸 다 만들어야 했습니다. 이건 정말 스트래스였습니다. 이미 있는 걸 활용할 수 없다는 건 대가가 아주 큽니다.
Smalltalk는 다릅니다. 제가 사용하고 있는 Dolphin Smalltalk의 경우는 기본적으로 C언어로 만들어진 DLL을 호출할 수 있습니다. 이 말은 Windows API를 완벽하게 다룰 수 있음을 의미합니다. 그래서 Visual Age나 Visual Works 와 같은 다른 Smalltalk 환경들이 Windows 용 프로그램이 아닌 것처럼 동작하지만 Dolphin은 그렇지 않습니다.
만약 기계를 다루는 기능이 Smalltalk에 없다면, C언어로 기본 부분(core)을 만들고 Smalltalk에서 불러서 쓰시면 됩니다. 또한 Dolphin Smalltalk와 Smalltalk MT의 경우는 모두 COM 과 ActiveX를 지원합니다. 만약 님이 쓰시는 기계의 라이브러리가 ActiveX 형태로 지원된다면 쉽게 불러와서 사용하실 수 있습니다. Flash나 Excel 등도 모두 ActiveX 컴포넌트로 싸여있기 때문에 Smalltalk에서 불러서 쓸 수 있다는 말입니다. 반대로 님이 어떤 프로그램을 제작해서 ActiveX 컨트롤로 만들면 다른 사람이 님의 프로그램을 사용할 수도 있다는 말입니다.
만약 님이 Smalltalk 코드를 C 언어로 변환해야 한다면, Squeak 이 있습니다. Squeak는 Smalltalk의 핵심 부분이 C언어로 되어있습니다. 그리고 Smalltalk의 코드를 C언어로 변환해 주는 기능을 가지고 있습니다.
또한, Smalltalk와 Java와의 연계가 가능한 솔류션 들도 속속 개발되고 있으니 Java가 필요하면 Smalltalk와 접합해서 사용하시면 됩니다. 심지어 Little Smalltalk라는 Embeded 용 Smalltalk 솔류션이 개발되어 있기도 하고(정확히 어떤 플랫폼인지는 잘 모르겠습니다.), Palm OS에서 돌아가는 Palm용 Smalltalk도 있습니다.
즉, Smalltalk 언어는 접합성이 강하고 적응력이 뛰어납니다. 필요한 자원들을 Smalltalk에서 그대로 활용하실 수 있다는 말입니다.
지금까지 Smalltalk의 전망에 대해서 말씀드렸지만 저는 '대중성'이라는 점에서는 부정적으로 보지만, 언어의 완성도에서 쏟아지는 수많은 개념들은 결국 지금 현안으로 논의되고 있는 것들이며, 다른 언어나 환경에 쉽게 적응할 수 있는 특징이 있다고 생각합니다.
7. 학습의 용이성
그럼 이런 Smalltalk 언어가 배우기에 얼마나 어려운가가 문제가 될 것 같은데요,
1) 단순한 문법
우선, Smalltalk의 문법은 워낙 간단해서, 대략 이틀 정도면 문법에 익숙해 지실 겁니다. C언어를 공부해 보셨다니 아시겠지만 C언어(그리고 C++이나 다른 언어도 모두)는 상당히 복잡한 문법을 가지고 있습니다.
if, for, while, swich 와 같은 프로그램의 실행 흐름을 제어하는 것도 '문법'이 있는 명령이고 객체를 만들어 내기 위한 것도 문법이 필요한 명령이며 객체를 설계할 때 쓰는 class 역시 문법입니다. 또 프로그램에서 예외 상황을 처리하는 try ~ catch 도 문법이 있는 명령입니다.하지만 Smalltalk의 문법에는 위에서 이야기한 것들, 즉 프로그램의 실행 흐름 제어,, 객체 생성, 객체의 설계, 예외 처리 등이 문법으로 규정되지 않습니다. 프로그래밍을 해 본 분들은 이 말을 듣고 무척 놀랍니다. 그럼 도대체 저런 것들을 Smalltalk에서는 어떻게 하는가.
바로 객체에게 메시지를 보내는 방법으로 합니다. 그래서 결국 Smalltalk 에서는 언어 자체가 중요한 것이 아니라 그 언어를 구성하고 있는 객체의 프레임워크가 중요합니다. C++의 경우는 열심히 언어 문법을 공부한 뒤에는 필히 MFC, motif 같은 객체 모델을 공부해야 합니다. 결국 언어도 배워야 하고 객체 모델도 배워야 하기 때문에 C++ 언어가 어려울 수 밖에 없는 겁니다.
그러면 이렇게 생각하실 지도 모르겠습니다. 결국 Smalltalk에서 아무리 객체 모델을 공부한다 하더라도 C++에 가면 모든 걸 다시 시작해야 하는 게 아니냐고요.
결론은 Yes 입니다.
하지만 Smalltalk를 공부한다는 것은 단순히 '객체 모델' 자체를 외우거나 공부하는 게 아니라 객체 모델이 어떻게 설계되고, 각각의 객체들이 어떻게 서로 메시지를 주고 받는지에 대해서 몸으로 느낄 수 있게 됩니다. 결국 이렇게 모든 것을 객체지향적으로 바라볼 수 있는 '관'이 적립된 후에는 C++의 MFC나 Delphi의 VCL이나, Java의 JavaBeans나 거의 같은 방법으로 채득할 수 있는 것입니다.
그리고 Smalltalk의 collection 라이브러리들은 워낙 강력하고 우아하게 설계되어서 C++의 STL 등 많은 곳에서 그 개념을 그대로 가져와서 사용하고 있습니다. 저도 STL이 얼마나 대단하기에 사람들이 저렇게 감탄하고 또한 어려워하나 하고 보았더니 결국 Smalltalk의 컬렉션 라이브러리를 C++의 템플릿으로 옮긴 것에 불과했습니다.
결국 중요한 것은, 객체지향에 대한 확고한 관을 가지고 있다면 새로운 객체 모델을 공부하는 것에는 그만큼 노력이 덜 든다는 것입니다. 2종 면허를 따 본 사람이라면 1종 면허를 따기도 상대적으로 쉬운 것이죠.
2) 프로그래밍의 기독성... 읽기 쉬움.
그리고 만들어 놓은 코드를 보는데 얼마나 쉬운지에 대해서는 제가 위에서 예로 든 드릴의 예를 다시 보시면 아실 겁니다. 여기에 작은 예를 몇 가지 더 적습니다.
if ( (5 <= x) && (x <= 10) ) transcript->printf("The value is %d\n", x); aString = copyString("I am a good boy.", 7, 10); MessageBox( nil, "프로그램에 문제가 발생할 수 있습니다.", "주의!", MB_ICONWARNNG); aDictionary.AtPut("김길동", "123-4567"); memfill( aByteArray, 0, 100 );
위의 예들을 Smalltalk로 옮깁니다.
( x between: 5 and: 10) ifTrue: [ Transcript print: 'The value is', x printString, '.'; cr. ]. aString := 'I am a good boy' copyFrom: 8 to: 10. MessageBox warning: '프로그램에 문제가 발생할 수 있습니다.' caption: '주의!'. aDictionary at: '김길동' put: '123-4567'. aByteArray atAllPut: 0.
물론 소스코드를 얼마나 읽기 쉽게 짜는가는 프로그래머의 역량에 달린 것이지만 같은 역량을 가진 개발자의 경우 C에서보다 Smalltalk에서 훨씬 유리하게 읽기 쉬운 코드를 만들 수 있습니다. 결국 Smalltalk의 세계에서는 "주석을 달지 말라"는 조언이 있을 정도입니다. (즉, 그만큼 프로그램을 주석을 달지 않아도 읽을 수 있도록 짜라는 말입니다.)
3) 탐색적 프로그래밍
Smalltalk 환경에서 프로그래밍을 해 보시면 아시곘지만, 대부분의 경우 소스가 공개되어 있습니다. Smalltalk는 90% 이상이 Smalltalk로 쓰여져 있습니다. 바로 이것은 '탐색적 프로그래밍'을 가능하게 해 줍니다.
만약 내가 어떤 기능을 하는 객체가 무엇인지 찾고 싶을 때 Smalltalk는 다양한 찾기 기능을 통해서 이 문제를 해결해 줍니다. 또 다른 사람이 만든 소스 코드를 보다가 해당하는 객체의 의미를 모를 때에는 즉석에서 해당하는 객체에 대한 주석과 소스코드를 볼 수 있습니다.
결국 Smaltalk에서는 '문법을 몰라서 헤매는 경우'보다는 '객체 모델의 이해가 부족해서 헤매는 경우'가 더 많습니다. 지금도 객체 모델 공부하랴, 버거운 문법 공부하랴 정말 열심히 하는 C++ 프로그래머들이 존경스럽습니다. 만약 그들이 C++에 쏟는 그런 노력을 Smalltalk 공부하는데 썼다면 훨씬 많은 성과를 냈을텐데말입니다....
상당히 긴 글이었는데요, 이게 '동지'를 만난 것과 같은 기분일까요? 쭉~ 한번 살펴보시고, Smalltalk를 공부하실 생각이 있으시다면 제가 서포트 해 드리겠습니다. 한글로 된 튜토리얼을 쓰는 중이지만, 진도가 잘 나가지를 않습니다. ^^ 영어로 된 자료를 보시는게 크게 어렵지 않으시다면 제가 가지고 있는 자료를 보내드리도록 하겠습니다. 그리고 언제든지 질문하시면 제가 알고있는데 까지 대답해 드리겠습니다.
저는 단언합니다.
Smalltalk는 객체지향의 [관](paradigm)을 가장 합리적으로 적립할 수 있게 하는 언어라고요. Smalltalk에서의 객체지향은 C++에서처럼 '선택사항'이 아니라 '필수'이기 때문이지요. 절차지향적이며 지극히 C 언어적인 생각을 하는 사람들에게 virtual, inline, overload, template, constructor, destructor와 같은 단어는 가히 혼란의 수렁으로 프로그래머를 빠뜨리는 카오스와 같지만, 객체지향적인 관이 굳건한 사람에게 저것들은 다형성과 상속성, 기억공간의 관리라는 객체지향의 특성을 나타내는 하나의 방법에 지나지 않는다는 것을 느끼게 될 것입니다.
저는 C++이나 Java의 소스를 보거나 직접 소스를 작성할 때 저런 부분을 보면 "아, Smalltalk에서는 이렇게 했었지" 하고 떠오르게 됩니다. 제가 Smalltalk를 배우기 전에 짰던 코드와 지금의 코드는 제가 봐도 놀랄 정도니까요. 남들이 쓰지 않는 신기한 언어를 다루며 뿌듯해 하시는 님의 모습을 상상하면서 이만 줄입니다.
p.s.: 이 글을 읽는 다른 분들도 Smalltalk와 프로그래밍 언어에 관심이 있으시면 글 남겨주십시오. 우리 나라에서 Smalltalk를 사용하는 사람들이 많아졌으면 좋겠네요.
프로그래밍 언어로 볼 때 Java는 분명 C#만 못한 언어입니다. 그 이유는
- 연산자 오버로딩이 안 됩니다. 분수나 복소수 같은 클래스를 만들었다고 해서 이것을 기본 자료형(primitive data type)과 똑같이 다룰 수는 없습니다.
- 값 의미(value sementic)와 가리킴(reference) 의미가 혼재되어 있습니다. Java에서 int, long, float... 등등은 값 의미이고, 일반 객체들은 가리킴 의미입니다.
- Smalltalk와 같은 Dynamic typping 언어처럼 변수에 자유롭게 객체를 대입하지도 못하면서 그렇다고 C++에서처럼 template을 지원하지도 않습니다. (다음 버전의 자반에서는 지언하겠다고 하더군요)
Java는 언어가 훌륭한 것이 아니라 지원을 하는 Sun사와 수많은 개발자들, 그리고 개발 환경이 훌륭한 것입니다. 비슷한 예로 C언어도 그렇습니다. C언어 역시 상당히 모자란 언어이지만, 수많은 라이브러리와 개발자들이 C를 살려냈습니다. 분명 C는 절차지향에서, Java는 객체지향 관점에서 보면 덜 진화된 언어입니다.
Jun 27, 2020 04:14