제가 모든 언어를 포괄해서 설명하는건 경제적이지 않으니까

일단 제가 한창 작업중인 C++ 위주로 먼저 설명하는게 옳을 것 같습니다.

C++ 언어는 다른 언어에 비해 설명이 많이 필요한 언어기도 하니까요.

C 언어의 발생 시점에서도 그랬지만,

좋은 책이 나오지 않았으면 AT&T 의 역사속에서 묻힐 수 밖에 없는 언어였습니다.

익히 아는분들도 많을 이야기지만, C 언어는 크리스마스 장난처럼 만들어진 언어입니다.

게임을 만들려니 어셈블리가 불편했고, 그래서 PASCAL, B, BCPL 을 베껴 뚝딱 만든게 C 언어,

그 게임이 돌아가도록 운영체제가 필요했고, 그래서 AT&T 에서 말아먹고 있던 프로젝트인 MULTICS 에서

복잡한 부분을 빼서 정리한게 Unix 란 운영체제 입니다.

개발 동기에 대해 여러가지로 희화한 버전이 있지만 이정도로 알아두셔도 됩니다.

컴퓨터의 역사에서 초창기에 만들어진 모든 것들은 사실 그다지 복잡하지 않습니다.

오히려 간결하기 때문에 처음엔 어렵게 여겨질 수 있는 정도지요.

앞서 include 없이 printf 구현하기란 글에서 언급했지만,

C 언어의 문법 그 자체는 램 말고는 하드웨어를 건드릴 수 있는 여지가 없습니다.

따라서, 표준 라이브러리를 통해 운영체제가 제공해주는 API ( Application Programming Interface ) 를 사용해야만

화면에 무언가를 찍을 수 있고, 키보드나 마우스로 부터 무언가를 입력받을 수 있습니다.

더 더 lowlevel 로 내려가서 본인이 직접 구현할 수 있습니다.

BIOS 를 직접 제어하든, 심지어 CPU를 직접 설계할 수도 있죠. ( FPGA 같은걸 통해서 손쉽고 저렴하게 )

하지만 그게 실용적인 목적을 가지고 있지 않다면 지속하기는 힘든 작업이겠죠?

API 는 운영체제를 개발하는 개발사에서 만들고 손보게 됩니다.

표준 라이브러리는 컴파일러를 개발하는 개발툴 제작사에서 만들고 손보게 됩니다.

그 말은, 새로운 하드웨어가 등장하고 스펙이 변화되면, 그 변화를 다른사람들이 책임지고 손봐서 적용해 준다는 이야기죠.

그래서 바퀴를 재발명 하지말라는 이야기가 있습니다.

가끔은 바퀴를 리뉴얼 할 필요가 있긴 하지만요 :)

즉, 본인이 하드웨어의 변경점 마다 모든걸 다시 개발할 의지가 없다면, 있는걸 잘 써주는게 필요합니다.

있는게 자기의 요구사항을 충족시켜 줄 경우 말이죠.

그래서 API와 표준 라이브러리는 잘 알고 써먹을 수 있으면 좋은 것입니다.

그러면 STL 은 왜 배워야 할까요?

이것도 표준 라이브러리기 때문입니다.

초창기 STL은 아주 열악한 성능과 버그에 의해서 응용개발자들의 큰 호응을 끌어낼 수 없었습니다.

지금은 다른 개발 도구들의 성능이 좋아지면서, 좀 더 품질 좋은 컴파일러를 만들어낼 수 있게 되었고,

상호 상승작용을 거쳐 꽤 쓸만한 라이브러리로 바뀌었죠.

STL 이 없는 C/C++ 언어는 알고리즘에 관해 거의 문외한 수준이어서

qsort 나 binary_search 를 들들 볶아

자기 용도에 맞게 바꾸는 작업이 꽤 불편하고,

한 가지 타입에 종속적이어서 매 프로젝트마다 새롭게 구현해 줘야 하는 경우가 많았거든요.

template 라는걸 통해서 한 가지 타입에 특정되지 않고, 여러 타입에 일반적인 문법을 사용할 수 있게 된데다,

STL 을 통해서 타입 / 컨테이너 / 알고리즘을 분리시켜 하나씩만 구현해도 여러 조합의 경우를 포괄할 수 있는

언어가 된거죠.

지금의 C++ 언어는 언어 자체를 변경하는 부분의 부담을 덜기위해

STL 을 통해 확장하는 형식으로 발전하고 있습니다.

그래서 STL을 배워야 하는 것이죠.