아래 Asker님과 Albina님께서 프로그래밍 언어에 대한 말씀을 하시길래 프로그래밍 언어에 대해 몇 자 끄젹여 봅니다.


프로그래밍 언어 마켓 리뷰에 의하면 10년에 4개 꼴로 새로운 프로그래밍 언어가 탄생된다고 합니다. 그리고 올해 드디어 python이 Java를 젖히고 1위를 차지했다고 합니다.

20171104_224916.png 



저도 요즘 Python 언어를 주목하고 있는데 이 Python(이하 '파이썬'으로 대체) 언어는 참 독특합니다. 사실, 프로그래밍 언어라는 것은 CPU가 필요한 '1' 또는 '0'을 조합하여 만들어지는 명령어들을 프로그래머가 인식이 편하도록 바꾼 것이라는 공통점이 있습니다. 그런데 프로그래머가 작성한 프로그램을 CPU가 필요한 '1'과 '0'으로 조합된 명령어로 인식하는 것에는 크게 세가지가 있습니다.


첫번째는 Assembler 언어로 작성한 Source Code를 Assembling하는 방법. 두번째는 대부분의 High Level Language에서 Source Code를 Compiling하는 방법, 그리고 한번씩은 예제로 작성해보셨을 Basic 언어의 interpret 방법.


Assembling과 Compiling은 CPU가 필요한 '1'과 '0'으로 변환시켜주는 반면 interpret는 언어를 ASCII Code 자체로 해독해서 실행을 합니다. 따라서 Assembler 언어나 High Level Language와 달리 Basic은 실행 속도가 느립니다.


Basic은 누구나 쉽게 사용할 수 있지만 interpret 방식에 의하여 프로그램이 실행되기 때문에 속도가 느린데 마이크로소프트사는 Basic으로 작성한 Source Code를 Compiling하여 실행시킬 수 있는 방법을 제안합니다. 그래서 많이 쓰게되어진 Visual Basic(흔히 비베).


그런데 Python은 '비베'와는 달리 interpret 방식을 사용합니다. 재미있는 것은 Python은 Basic과는 달리 interpret를 계속 하지 않는다는 것입니다. 스스로 프로그램이 수행되면서 조금씩 compiling을 하여 속도를 높여주는 특이한 방식을 쓴다고 합니다.




프로그래밍 언어가 무엇이 좋은지에 대하여는 논란의 여지가 많습니다. Java가 가장 많이 쓰이고 있지만 실행속도 등 여러 불편한 점들이 지적되고 있으며 각종 프로그래밍 언어 커뮤니티에서는 프로그래밍 언어 황제인 Java가 주로 성토의 대상이 되었습니다. 이제, 그 성토의 대상은 python이 되겠지요.



어떤 프로그래밍을 사용하던지 간에 최근의 프로그래밍 언어에서는 'Object-Oriented'가 키워드입니다. 하다 못해 사무용으로 가장 많이 쓰였으며 가장 오래된 언어인 COBOL에서조차 최근 버젼은 Object-Oriented 탑재되어 있으니까요. 이 것은 거꾸로 Assembler에서도 Object-Oriented 구현이 가능하다는 것을 의미합니다. 당연하지요. 모든 Assembling과 Compiling을 거치는 언어는 궁극적으로 '1'과 '0'으로 변환되는 것이니까요.


Assembler 언어에서 Object-Oriented 구현이 가능하다는 것을 보여주는 책이 있습니다. (링크는 여기를 클릭 Chapter 12 Procedures: Advanced Topics (페이지 629)) 지금 생각해보면 제가 Assembler 언어로 프로그램을 작성했을 때 무의식적으로 Object-Oriented를 염두에 두고 프로그램을 작성했던 것 같습니다. 그런데 Object-Oriented 방식은 상대적으로 CPU Resource를 많이 잡아먹습니다. 뭐, 요즘의 32비트 CPU들은 내장된 Program ROM이나 RAM 크기도 널럴합니다만 1,2바이트 가지고 헤매야 했던 시절, 저의 프로그램은 항상 resource를 많이 요구되어 RAM의 용량이 부족하거나 Program ROM 용량이 부족해 '나는 정말 소프트웨어에 재능이 없나보다'라고 절망을 많이 했으니까요.


맨날 삑사리 내면서 고생한 결과, 획기적으로 Resouce를 줄이는 방법을 고안해냈습니다만 어쨌든 Object-Oriented 방식은 Bug에서 상대적으로 자유로우면 수정, 변경이 용이합니다. Bug 하나 고치면 새로운 Bug가 두 개 발생하는 것에 비해 Object-Oriented 방식은 Bug를 수정(Fix)하는 과정에서 새로운 Bug를 발생시킬 가능성이 상당히 낮으니까요.

지금은 Assembler와 C/C++을 혼용하는 Mixed Language를 사용하는데 source? 그동안 구축해놓은 것을 Platform(CPU가 8비트부터 64비트까지)에 관계없이 drag & drop한 후에 Compiling Option만 살짝 바꾸어주면 되니까요. (그래서 오래 전에 작성해 놓은 것은 제가 작성했음에도 source code를 읽어보면 이해를 못한다는 ^^ )



Python을 주목하고 있는 반면에 Java script 역시 관심을 두고 있습니다. Python은 android 버젼은 없다고 합니다. 아마 그럴 것입니다. 예로, C/C++은 platform indendent이지만 android는 platform dependent이기 때문입니다.( 이 분은 추측으로 정확하지는 않습니다. 어쨌든) 그래서 틈틈히 예제 프로그램들을 짜보면서 언어들의 특장점을 확인해 보고 있는데 hardware 기반의 프로젝트를 한다고 하더라도 조만간 Assembler를 버려야할지도 모르겠습니다. 뭐, 수많은 프로그램들과 라이브러리들이 있는데 CPU 속도가 워낙 빨라진 현재에 Assembler의 특징인 실행속도가 빠르다는 것은 더 이상 큰 장점이 아니고 또한 남이 잘 작성한 프로그램들을 이용하는게 가장 현명한 방법이기 때문이죠.


즉, 프로그램에서도 knowhow 시대가 아니라 knowwhere 시대라는 것입니다. 제가 linux에 손을 대는 이유도 (제 표현입니다만) linux 세계가 Sea of sodtware engineering이기 때문입니다. 그 우수한 소프트웨어 엔지니어들이 'shareware' 정신을 살려 배포한 수많은 좋은 프로그램들을 외면하고 혼자 다 하겠다? No way~ 이기 때문입니다.


환원하면, 남이 작성한 프로그램들을 쉽게 갔다 쓸 수 있는 프로그래밍 언어가 장땡이라는 것이죠. 그게 프로그래밍 언어 선택의 큰 기준이 된다는 이야기죠.




아래는 언어의 역사입니다. (인용처 밑에 링크를 클릭해도 404 Error가 나옵니다.)

20171105_003130.png


이 도표에는 두가지 중요한 언어가 빠져 있습니다. 그 두가지 언어는 바로 C 언어의 전신이 B 언어 그리고 B 언어의 전신인 A 언어.


최초의 UNIX는 Assembler로 작성하게 되어 있었습니다. UNIX 언어가 통일이 되지 않았고 국내에는 아직 C 언어, 그러니까 UNIX 언어가 아직 시기상조였던 시절에 각종 증권회사에서는 제가 학창시절 COBOL로 프로그래밍하는 것이 전부였습니다. 그 때, 한 증권회사와 프로젝트를 하다가 중형컴퓨터를 만져보게 되었죠. 학교 교과과정에서 FORTRAN 학점을 이수했는데 제기랄. 프로그래밍 언어를 작성하는데 제가 콘솔 앞에서 키보드 두들겨가면서 source를 작성하고 compile하여 결과를 보는건 없습니다. 시험지에 프로그램을 작성하면 학생들이 작성한 프로그램을 조교가 거두어다가 일일히 천공을 해서(구경을 해보지 못했으니... 아마 그랬을겁니다...라고 추측합니다만) 그 결과를 보고 점수를 매겼으니까요. 


그러니 중형컴퓨터를 직접 조작하여 source를 작성해서 컴파일해보는 것이 얼마나 신기했겠습니까? 저에게는 신세계죠. 당시에 COBOL이나 UCSD-PASCAL 등의 언어도 IBM-PC 상에서 작성을 해보았는데 직접 UNIX 매뉴얼을 보고 프로그램을 작성해 보았죠. Assembler로. 그 때 그 증권회사 실장이 저에게 '너, 졸업하면 여기로 와라'라고 했을 때 갔어야 했는데... ^^ 저는 그 제안을 농담으로 받아쳤죠.

"꿈많은 청춘에게 와서 키보드질이나 하라고요? 글쎄요"



각설하고,

어쨌든 초기에 어셈블로로 되어 있던 UNIX는 A 언어에 착안하여 B 언어라는 UNIX용 언어가 탄생했고 그 B 언어에 영감을 얻어 C 언어가 탄생이 되었습니다. 그리고 그 C 언어는 다시 UNIX 언어의 모체가 되었고요.


그런데 UNIX 언어를 탄생시킨 A 언어는 프로그래머들 간에 아주 악명이 높았던 프로그램입니다. APL이라는 A Programming Language라는 이름으로 IBM 사에서 발표한 언어인데 이 언어의 source를 입력하기 위하여는 속기사들이 쓰는 키보드처럼 특수한 문자들이 가득차 있었습니다.


20171105_004835.png


그런데 A 언어로 프로그램을 작성하는 것은 무척 어려웠던 모양입니다. 한 엔지니어는 이런 코멘트를 남겼으니 말입니다.


'Tis(=It is:인용자 주) the dream of each programmer
Before his life is done
to write three lines of APL
And make the damn things run

이 것은 모든 프로그래머의 꿈이라네
그의 삶이 다하기 전에
세 줄의 APL 코드를 짜고
이 빌어먹을 코드가 실행되게 하는 것


왠만한 source code들은 수천줄이 넘어가는 것에 비추어본다면 '겨우 세 줄의 source code를 작성하고 그게 실행되는 것이 꿈'이라니 얼마나 난해한지는 미루어 짐작할 수 있습니다. 아마, 프로그래밍 언어 역사 상 가장 욕을 많이 먹은 프로그래밍 언어일 것입니다.


그런데 다른 이유로 소프트웨어 엔지니어들에게 욕을 먹은 사람들이 있습니다. 그 사람은 바로 빌 게이츠.


마이크로소프트사의 Windows들은 인류의 지식을 그 누구나 쉽게 접하고 만들어 새로운 지식을 폭발적으로 만드는데 공헌했습니다. 그 것은 그 누구도 부인하지 못할 것입니다.


그런데 이 Windows에 대하여 우수한 소프트웨어 엔지니어들은 불평을 터뜨리며 현업을 포기하기도 합니다. 그 이유는 바로 다음과 같습니다.


"인류 지성의 산물인 소프트웨어를 노가다 수준으로 끌어내리는데 혁혁한 공을 세운 빌어먹을 빌 게이츠"

(참조로 저도 WIndows XP 이후에 IBM-PC 레벨에서의 프로그램은 포기했었는데 물론 직책/직무 상 병행하기 힘든 이유도 있습니다만 주어지 틀 안에서 소프트웨어를 작성한다는 것이 염증이 나서도 한 이유였을겁니다. MFC에서 최상위 class인 CObject에서 후속 class(child class) tree를 만들어보려다가 GG하고 때려치웠죠.)


아마, 인류에 지대한 공헌을 했음에도 그 반대급부적으로 욕을 많이 먹은 빌 게이츠가 아마 프로그래밍 언어 역사 상 가장 욕을 많이 먹은 사람일 것입니다. 뭐, 빌 게이츠는 스티븐 잡스의 카피캣이라는 또 다른 이유 때문에 욕을 먹고 있기도 합니다만.(그리고 스티브 잡스도 사실 Bell사인가? Xerox사인가? 하여간 그 회사의 카피캣이라는 또다른 비난의 대상이기도 합니다만)



프로그래밍 언어가 어떻게까지 발전될지는 모르겠습니다. 하드웨어 기반의 소프트웨어 엔지니어는 오히려 선택지가 제한되어 있을지 모르겠습니다. 그러나 분명한 것은 'knowhow' 시대가 아닌 'knowwhere' 시대이기 때문에 실적이 가장 많은 그래서 reference source가 가장 많은 프로그래밍 언어가 majority가 되겠지요. 제 생각에 프로그래밍 언어가 어떻게 바뀔지 모르겠지만, 제 생각에 C/C++은 여전히 프로그래밍 언어의 강자로 남아 있을 것이라는 생각을 해봅니다.



끝으로 각종 언어를 비교한 글을 아래에 인용합니다.

Algol: Assembly language is too low-level.

Pascal: Algol doesn't have enough data types.

Modula: Pascal is too wimpy for systems programming.

Simula: Algol isn't good enough at simulations.

Smalltalk: Not everything in Simula is an object.

Fortran: Assembly language is too low-level.

Cobol: Fortran is scary.

PL/1: Fortran doesn't have enough data types.

Ada: Every existing language is missing something.

Basic: Fortran is scary.

APL: Fortran isn't good enough at manipulating arrays.

J: APL requires its own character set.

C: Assembly language is too low-level.

C++: C is too low-level.

Java: C++ is a kludge. And Microsoft is going to crush us.

C#: Java is controlled by Sun. 

Lisp: Turing Machines are an awkward way to describe computation.

Scheme: MacLisp is a kludge.

T: Scheme has no libraries.

Common Lisp: There are too many dialects of Lisp.

Dylan: Scheme has no libraries, and Lisp syntax is scary.

Perl: Shell scripts/awk/sed are not enough like programming languages.

Python: Perl is a kludge.

Ruby: Perl is a kludge, and Lisp syntax is scary.

Prolog: Programming is not enough like logic.



백이숙제는 "以暴易暴"를 남겼고 한그루는 "以"를 남기고 간다.