프로그래밍 언어

• 컴퓨터 관련 정보, 언어 관련 정보

1 개요

Programming Language
기계(컴퓨터)에게 명령 또는 연산을 시킬 목적으로 설계되어 기계와 의사소통을 할 수 있게 해주는 언어를 뜻한다. 그 결과, 사람이 원하는 작업을 컴퓨터가 수행할 수 있도록 프로그래밍 언어로 일련의 과정을 작성하여 일을 시킨다. 쉽게 말하면 컴퓨터를 부려먹기 위한 언어. 소프트웨어를 만드는데 기본이 된다.

컴퓨터보다 먼저 등장했다. 시대를 앞서서 에이다 러브레이스 백작부인과 같이 프로그래밍 언어에 대해 연구한 사람들도 일부 있었으나 본격적인 연구는 1930년대 즈음부터 수학자들에 의해 기계적으로 계산 가능한 함수에 대한 연구가 진행된 데에서 비롯되었다. 그 결과 기계가 이해할 수 있는 언어가 탄생했으며, 바로 이 기계가 계산 가능하고 이해 가능한 언어를 실행하는 기계로 언어보다 나중에 발명된 것이 바로 현대적 의미의 컴퓨터다.

2 등장 배경과 역사

역사를 잘 살펴보면 프로그래밍 비스무리한것을 만들고 했던 기인들이 종종 등장하지만, 프로그래밍 언어라는 본격적인 개념은 역시 수학에서 등장하였다. 쿠르트 괴델은 불완전성 정리를 증명하는 과정중에 알고리즘을 추상화시킨 primitive recursive function 개념을 만들고, 이를 이용하여 증명에 성공하였는데, 수학적으로 본다면 이것이 최초의 프로그래밍 언어라 볼 수 있다.(굳이 따지자면 함수형 언어라 할 수 있다.) 그리고, 몇년 후에 컴퓨터의 아버지라 불리는 튜링은 이 primitive recursive function과 동치인 튜링 머신을 발표하고, 역시 이 튜링머신을 이용하여 불완전성 정리를 다시 한번 증명해보인다. 이는 어떤 체계를 통해서 이 체계의 모순성을 증명할 수 있는 방법은 없다와 동치이다. 정지 문제 참조.

그 이후 Computability라는 수학의 분야가 생기면서 기존의 primitive recursive function을 확장한 Lambda calculus라거나 Unlimited register machine(URM), While-programming, SKI 등등 알고리듬을 표현하기 위한 여러가지 체계들이 등장한다. 참고로, Lambda calculus를 고안한 알론조 처치의 경우 혹시나 이것을 이용하면 수학의 완전성을 증명할 수 있지 않을까 해서 시도하지만, 실패한다. 문제는, 상기된 알고리듬 체계들은 모든 알고리즘을 다 표현할 수 있는 체계인가라는 의문인데, 알고리즘이라는것이 수학적으로 정의된 개념이 아니기때문에 그것을 증명하는것은 불가능하였다. 하지만 저 모든 알고리듬 체계들이 표현방식은 다르더라도 수학적으로 볼때는 다 동일하였기때문에 알론조 처치는 저 알고리듬 체계들이 '모든 알고리듬의 집합'과 동치라고 그냥 간주할것을 제안하며, 이것이 그 유명한 Church's thesis이다.

이렇게 수학 쪽에서 프로그래밍 언어에 대한 개념적인 기초가 닦아지는 동안, 역시 수학자인 폰 노이만은 그것들을 이용하여 실제 컴퓨터를 만들기 위한 폰 노이만 구조를 만든다. 그렇게 전자쪽과 결합을 하면서 현대 컴퓨터의 원형이라고 할 수 있는 물건이 만들어졌다. 이러한 전자적인 계산장치는 전기신호를 통해서 제어하였는데, 전기신호를 표현할 수 있는 방법은 신호가 들어왔다(1), 신호가 들어오지 않았다(0) 정도에 불과하였다. 따라서 제어신호는 0과 1만으로 표현하는 라이프니츠식 2진법을 사용할 수 밖에 없었고, 특정한 패턴의 전기신호는 어떠한 동작을 의미한다는 식으로 사람들이 정하고 전자계산장치는 그 신호가 입력되면 정해진 동작을 하는 형태였다.하지만 실제 컴퓨터의 동작에서는 장치가 꺼져서 전기신호가 없는 상태인지 아니면 0을 나타내는 상태인지 구별하기 위하여 0은 기준 레벨(일반적으로 볼트#s-1 단위로 표시한다)이하의 신호일 경우 0으로 본다. 마찬가지로 1 역시 기준 레벨 이상의 신호일 경우 1로 본다.

따라서 뭔가 동작을 시키기 위해서는 이러한 제어신호를 사람이 직접 작성해야 됐는데, 초창기에는 그 0과 1의 제어신호를 사람이 직접 작성하는 형태의 기계어가 사용되었다. 이 기계어는 항목에서 볼 수 있듯이 이쪽 분야에서 가장 원시적인 언어로 기계는 바로 이해할 수 있는데 사람은 도저히 이해하기도 어렵고 알아보기도 힘든 물건이라 결국 사람이 읽기 편하도록 기계어와 특정 기호를 1:1로 대응시키는 어셈블리어가 등장하였다. 과거 기계어를 쓰는 시절보다는 보기가 좀 편해졌지만 여전히 해독하기가 난해하였고, 컴퓨터의 보급과 함께 프로그램의 수요가 늘어나는데 어셈블리어의 생산성은 심히 안습이라서 조금 더 프로그램을 짜기 쉬운 언어들이 등장하기 시작하였다.

초창기에 프로그래밍 언어들은 컴퓨터 성능의 한계로 인해 많은 제약이 따라붙었고, 어셈블리어적인 성격이 어느정도 남아있었다. 그럼에도 어셈블리어에 비하면 읽기가 편했고 이해하기도 훨씬 수월했다. 그리고 컴퓨터의 보급과 성능 발달에 맞물려 그동안 걸려있던 제약조건들도 하나씩 사라지고 보다 사람이 읽기도 쉽고, 이해하기도 쉽고, 작성하기도 쉬운 프로그래밍 언어들이 속속 등장하였다.

다만 어차피 컴퓨터가 이해할 수 있는 언어는 기계어 뿐이기 때문에 사람이 하기에 편해졌다는 것 뿐이지 실제 그 뒤에서 이루어지는 작업은 훨씬 더 복잡해지고 있다.

정리하자면 기계에게 편한 언어는 속도가 빠르지만 사람이 도저히 알아볼 수 있는 물건이 아니라서 생산성이 떨어진다. 반면 사람에게 편한 언어는 속도는 느리지만 이해하기 쉽고 생산성이 높다는 상관관계가 성립한다. 이것도 일종의 중역문제인가
단, 여기에 함정이 있는데 기계어로 짠 발적화 코드와 자바로 짠 최적화 코드의 수행속도를 비교한다면 당연히 자바쪽이 빠르다. 그러니까 기계어를 사용한다 해도 그걸 다루는 프로그래머가 기계의 특성을 훤히 꿰고 있지 않으면 다른 고급언어를 사용한 결과물보다 느려질 수도 있다는 얘기다. 그래서 몇몇 개발관련 서적에서는 최적화나 성능튜닝한답시고 기계어나 어셈블리를 남용하지 말라고 조언한다. 실제로도, 지금은 컴파일러와 어셈블러가 무척 발달되어 있어서 사람이 어설프게 짠 코드보다 기계가 변환한 코드쪽이 더 낫다. 물론 기계가 알고리즘 자체를 개선해주지는 못하므로 컴파일러한테 자신이 의도한 바를 명확하게 전달하는 게 더 중요하다. 예를 들어 "이 배열에 있는 값은 계산 끝날 때까지 중간에 바뀔 일은 절대 없으며 숫자 말고 엉뚱한 건 전혀 없다고 보장하고 하고 싶은 일은 이걸 다 더하는 것이다." 라고 컴파일러에게 명확하게 자신의 의도를 전달하면 컴파일러는 각종 하드웨어 가속과 코드 병렬화 등을 수행해 프로그래머가 의도한 일을 자신이 할 수 있는 가장 빠른 방법으로 구현해낸다. 일반 루프문을 사용한 배열 숫자 덧셈은 컴파일러가 숫자가 중간에 바뀔지 안바뀔지 판단을 못 하는 경우(전역변수의 배열을 더한다거나)가 생길 수 있는데 이런 코드를 만들지 않는 능력이 더 중요하다.

여담으로 난해한 프로그래밍 언어보다는 어셈블리어가 훨씬 읽기 쉽다...

3 구조

프로그래밍 언어론에 따르면 프로그래밍 언어의 표기는 구문(syntax)과 의미론(semantics)의 두 가지 관점에서 이루어진다.
구문이란 것은 언어의 외형적인 표기 방법을 일컬으며, 의미론은 구문이 내포하고 있는 의미, 즉 그 코드가 수행하는 작업을 뜻한다. 구문이 문법에 비유된다면 의미론은 글에 담긴 정보라고나 할까.

더욱 작은 단위로는 문자열(string), 문장(sentence), 어휘항목(lexeme) 등이 있으며 어휘항목의 종류를 통틀어 토큰(token)이라 한다. 어휘항목에 속한 요소에는 식별자(identifier), 리터럴(literal), 연산자(operator), 특수어(special word) 등이 있다.

대부분의 일반적인 프로그래밍 언어는 이런 토큰들이 영어로 되어 있다. 물론, 창조나 씨앗 같은 예외도 있긴 하다.

4 분류

4.1 해석 방식에 따른 분류

크게 인터프리터 언어와 컴파일 언어로 분류할 수 있다. 절대적인 것은 아니어서, 언어 명세가 어느 한 쪽을 완전히 배제한 형태가 아니면 양쪽을 오가는 것도 가능하다. 예를 들면 C 인터프리터도, 펄 컴파일러도 있다. 아래의 구분은 언어가 주로 구현되는 형태를 따른 것이다. 그리고 그 중간적인 성격을 갖는 바이트코드 컴파일러도 있다.

• 컴파일 언어 : C언어, 델파이등이 포함된다. 소스 코드를 미리 기계어로 번역해서 수행하기 때문에 수행 속도가 빠르고 보안성이 높다. 하지만 소스 코드의 극히 일부분을 수정해도 재컴파일이 필요하기 때문에 인터프리터 언어보다는 개발이 신속하지 못하다는 단점이 있다. 단, 컴파일 언어의 컴파일 속도가 느리다는 건 어쩌면 편견일 수도 있다. 같은 컴파일 언어인 Go 프로그래밍 언어(홈페이지)는 언어의 문법 구조를 개선함으로써 컴파일 속도를 엄청나게 개선했다. 사실상 컴파일이 있었다는 사실을 인지하지 못할 정도의 빠르기이다. 그냥 C++언어가 컴파일이 더럽게 느린 언어라고 보는 편이 더 알맞을 듯하다.

• 인터프리터 언어 : 소스 코드를 한 줄 한 줄 읽어 그때그때마다 번역해서 수행한다. BASIC이나 JavaScript같은 언어가 이런 형태이다. 소스 코드를 한 줄씩 읽어서 수행하기 때문에 대체로 컴파일 언어보다 성능이 떨어지지만 소스 코드 수정 후 곧바로 실행이 가능하기 때문에 유연성은 더 높은 편. 예를 들어 프로그램이 자기 자신을 수정해서 수행하는 변태적인 행동도 가능하다. 컴파일 기반 언어는 모듈화를 통해 이걸 흉내낼 수 있지만 아무래도 인터프리터 언어의 그것보다는 융통성이 떨어진다. 이 때문에 컴파일 언어에서 수정이 잦은 부분은 외부 프로그램과 각종 값을 주고받는 API를 짠 뒤 이 외부 프로그램을 인터프리터 언어로 짜서 실행시키는 경우가 많다. 이런 용도로 사용되는 언어를 스크립트 언어라고 부르고, 이 때문에 스크립트 언어는 거의 인터프리터 방식이다. Python, Ruby, Lua 등등 인터프리터 언어 진영에는 수많은 언어들이 포진해있다.

• 바이트코드 언어 : Java와 C##이 이 계열 언어이다. 소스 코드를 컴파일하는 것까지는 컴파일 언어와 같은데 이 결과물이 가상 기계용 기계어 코드 즉 바이트코드형태이며 이걸 가상기계(인터프리터) 실제 기계어로 한줄한줄 번역하며 수행한다. 바이트코드를 번역하는 가상 기계는 매우 고속으로 동작하게 만들 수 있고, 가상 기계만 실제 장비에 맞추어 개발해 놓으면 실제 장비에 상관없이 똑같은 코드를 실행시킬 수 있기 때문에 이 방식을 사용한다. 또한 실행시간에 해석하여 수행하는 것은 인터프리터 언어와 마찬가지이므로 컴파일 언어에 비해 동적인 기능을 수행할 수 있다.

• 저스트 인 타임(JIT Just In Time) 컴파일 : 인터프리터/바이트코드 언어에서 수행속도를 높이기 위해 사용되는 기술. 인터프리터 언어의 소스코드나 바이트코드를 해석하는 가상기계가 현재 실행중인 장비에 맞추어 컴파일 하여 수행한다. 개발은 개발속도가 빠른 인터프리터 언어나 바이트코드 언어로 진행하지만 실제 실행단계에서는 기계어 코드로 변환되어 실행되므로 성능의 향상이 있으며, 경우에 따라선 컴파일 언어보다 빠르다는 주장도 있다. 컴파일 언어는 실행 바이너리가 정적이라 머신이 신형으로 업그레이드돼도 그 신기능을 사용하지 못할 수 있지만 JIT의 경우에는 그 업그레이드된 기능을 반영해서 재컴파일이 가능하다. 또한 프로파일링을 통해 자주 실행되는 코드에 더 강력한 최적화를 적용하거나 메모리 맵 상 배치를 빠른 실행에 유리한 구조로 재배열할 수 있다. 하지만 JIT는 런타임에 컴파일을 수행하는 특성 때문에 짧게 실행되는 코드(0.1초 이하)에서는 그 장점이 발휘될 기회가 없어 컴파일 언어보다 느리다.

• 어헤드 오브 타임(AOT Ahead Of Time) 컴파일: JIT 컴파일 방식이 런타임시 컴파일을 수행하는 특성 때문에 로딩 시간이 오래 걸리는 점을 보완하기 위해 만들어진 컴파일 기술. JIT와 비슷하지만 AOT는 프로그램 실행 전, 즉 설치시 혹은 사용자가 기기를 이용하지 않는 IDLE 상태에 소스코드나 바이트코드를 미리 기계어로 컴파일시켜 놓는다. 컴파일시 걸리는 절대적인 시간 자체를 줄여주진 않으나 사용자가 실행시 컴파일되기까지 기다리지 않아도 되기 때문에 프로그램 실행시 시작되기까지 오래 걸리는 JIT의 문제를 어느 정도 해소하였다. 구글의 안드로이드가 킷캣 버전부터 AOT 방식의 ART 런타임을 지원하기 시작하면서 안드로이드 앱을 미리 컴파일시켜 사용자가 앱을 실행시킬 때 빠르게 실행되도록 동작 속도를 개선하였고, 안드로이드 누가(Nougat) 버전에서는 AOT 방식을 약간 변형해서 앱을 설치시 바로 컴파일하는 것이 아니라 충전시 혹은 사용하지 않는 동안 조금씩 야금야금 컴파일을 진행하도록 해서 사용자가 앱 설치 속도를 개선하였다.

5 정적 타입, 동적 타입

• 정적 타입 언어 : 자료형(Type)이 고정돼 있는 언어. 설명이 어려운데 간단히 얘기하자면 정수형으로 정의한 1은 계속 정수형 1로 남아있다. 이걸 실수형 1.0으로 바꾸려면 명시적인 형변환(Type casting)을 해줘야 한다. 묵시적 형변환이 이루어지는 경우도 있지만 제한적이다.

• 동적 타입 언어 : 자료형이 그것을 처리할 함수(또는 메서드)에 따라 그때그때 바뀌는 언어. 예를 들어 정수형 1을 정의했어도 그걸 처리할 함수가 문자열을 받아들이게 설계돼있다면 자동으로 정수형 1을 문자 1로 바꿔준다.

정적 타입 언어가 별 거 아닌 것처럼 느껴질 수도 있지만 실은 프로그래머들을 짜증나게 하는 주범이 바로 형변환(Type casting)이기 때문에 동적 타입 언어는 이런 점에서 매우 강점을 가진다. 특히 객체 지향 언어에서는 동적 타입 및 그것의 일반화버전이라 할 수 있는 덕 타이핑(Duck typing)이 프로그래머에게 수많은 혜택을 준다. 예를 들어 오리라는 타입과 닭이라는 타입이 있고 둘 다 날아오르는 기능이 있다면 정적 타입 언어에서는 상위 인터페이스를 추출하는 등의 부가 작업이 쩌는데 덕 타이핑을 지원하는 언어에서는 그냥 넣어버리면 알아서 난다. 물론 단점도 있는데 고래 같이 못 나는 타입을 집어넣으면 실행시간 오류(런타임 에러)를 뱉어버린다는거. 정적 타입 언어는 이런 문제가 없다...고 알려져있지만 거짓말이고 정적 타입 언어도 닭은 닭인데 통닭 같이 못 나는 타입을 집어넣는 바람에(기술적으로는 해당 메서드가 구현이 안된 객체) 런타임 에러가 나올 수 있다.

그런데 하스켈(Haskell)은 정적 타입 언어다. 그런데도 하스켈 코드에는 형 변환 연산자가 없다. 이게 어찌된 일이냐 하면 하스켈 언어는 정적 타입 언어이지만 강력한 타입 추론 기능을 내장하고 있어 형변환을 언어 차원에서 자동으로 해 준다. 동적 타입 언어 역시 자동 형변환을 제공하는데 무슨 차이가 있냐면 그 형변환을 런타임에 하느냐 컴파일 타임에 하느냐의 차이다. 즉 버그가 발생하는 시점을 런타임에서 컴파일 타임으로 끌어당긴다. 타입 추론 엔진은 딱히 하스켈 같은 선언형, 함수형 언어에만 도입할 수 있는 건 아니므로 신형 설계가 적용된 언어라면 명령형, 객체 지향 언어라도 타입 추론을 할 수 있다. 단지 정적 타입 언어로 유명한 C나 자바에 타입 추론 엔진이 없을 뿐이지. 여기서 타입 추론은 묵시적 형변환과 동의어가 아니다. 겉으로 보이는 건 묵시적 형변환하고 똑같지만.

5.1 절차적 언어

알고리즘과 로직에 의거하여 단계 단계 밟아가며 문제를 해결하도록 짜는 프로그래밍 언어. 대표적인 언어는 C와 Pascal.
종종 객체지향 언어의 상대적 개념으로 절차지향 언어란 말을 쓰기도 하는데, 이는 객체지향 언어가 등장한 이후에 나타난 것으로 보인다.
애초에 C++이나 JAVA등의 객체지향 언어가 널리 알려지기 전에는 C 나 Pascal을 절차지향 언어라고 부르지는 않았다. 그보다는 구조적 프로그래밍 언어란 말이 C 나 Pascal을 가리키는 말이었다.
C++이나 JAVA같은 객체지향 언어는 객체개념 구현 자체가 프로그램언어 개발의 지향점중 하나였지만, C 나 Pascal등의 언어는 절차지향을 목표로 개발된 언어가 아니다. 따라서, 객체지향을 구현하지 않은 기존 언어를 가리키는 말로 절차지향 언어보다는 절차적 언어가 적합한 용어로 보인다.

5.2 객체 지향 언어

객체 지향 언어는 프로그래밍을 함에 있어서 데이터와 그 데이터를 처리할 메소드를 한데 묶어 객체를 만들고 객체들을 조립하는 것을 목표로 한 언어들을 말한다. 객체 지향 언어의 특징은 추상화, 캡슐화, 상속성, 다형성이 있다. 추상화는 외부 인터페이스만 제공하고 객체 내부를 숨겨서 어떻게 일을 하는지 몰라도 결과를 내보낸다. 캡슐화는 객체 내부에 필요한 데이터등을 묶어서 한번에 관리 할 수 있게 해준다. 상속은 모객체를 상속받아 추가 기능을 더 붙이거나 약간의 수정을 가한 객체를 만들 수 있다. 다형성은 메소드 이름은 같더라도 타입에 따라 다른 메소드가 실행될 수 있다는 것이다.
주석에서 삶의 애환이 느껴진다. 안습

더 자세한것은 OOP 항목을 참조.

5.3 선언형 언어

선언형 언어(Declarative language)는 명령형 언어와 대비되는 개념으로, 함수형 언어와 논리 프로그래밍(Logic programming)등이 여기에 속한다. 현재 학계를 떠나 슬슬 업계 전반으로 확산되고 있다. 특히 신기술의 도입이 빠른 웹 앱 계열에서 선언형 스타일의 프로그램이 선호되고 있는데 JavaScript 코드의 코딩 스타일이 점점 선언형으로 변화하고 있다. 선언형으로 기술하는 가장 유명한 라이브러리로는 제이쿼리(jQuery)가 있으며 앵귤러 JS(AngularJS)는 선언형 언어의 가장 최신 트렌드인 반응형 프로그래밍개념을 도입하고 있다(2-Way binding이라는 이름으로 소개하고 있다).

순수 선언형 언어의 특징으로는 참조 투명성(referential transparency)가 꼽힌다.

또한 선언형 언어에는 '지연 평가(Lazy evaluation)' 이라는 강력한 특징이 있다. 계산을 필요한 그 순간이 올 때까지 미룬다는 개념인데, 이 개념은 선언형 언어에만 있다. 단 선언형 언어 전부가 지연 평가를 지원하는 건 아니다. 이 지연 평가 개념의 강력함은 무한을 다룰 때 나타난다. 예를 들어 입력 데이터로 자연수 전체의 집합을 정의해서 대입하는 게 가능하다! 명령형 언어에서는 무한을 대입하면 말 그대로 무한히 계산을 하기 때문에 프로그램이 무한 루프를 돌며 멈춰 버리지만 지연 평가를 지원하는 언어에서는 만약 계산식의 마지막이 "...해당 리스트의 첫 5개를 출력." 하는 식으로 끝났다면 그 '첫 5개'를 찾아내기 위한 계산만을 수행하고 끝낸다. 예를 들어 "피보나치 수열의 10번째 항부터 30개 항을 출력하라"는 알고리즘을 구현할 때 명령형 언어라면 피보나치 수열을 생성하는 알고리즘 자체에 루프를 멈추는 코드를 삽입해야 하지만 지연 평가가 지원되는 선언형 언어의 경우 피보나치 수열 알고리즘은 "제네레이터"로 만들어 무한수열을 출력하게 하고 필터로 원하는 위치의 리스트를 뽑아주면 된다.

물론 당연히 "피보나치 수열의 마지막 다섯 개를 출력." 하는 식으로 짰다면 지연 평가고 나발이고 이쪽도 무한루프 돌며 프로그램이 멈춰 버린다. 피보나치 수열은 무한수열이기 때문에 "마지막"이 없기 때문.

5.3.1 함수형 언어

왜 함수형 프로그래밍이 좋은데? 도대체 어느 점이 마음에 드는거야?

꼬리재귀.

명령형 언어가 튜링머신에 기반하고 있다면, 함수형 언어는 람다 칼큘러스에 기반하고 있는 언어에 대한 총칭이다. 현업에서 많이 쓰이는 명령형 언어와는 대조적으로 몇가지 특징이 있다.

• 순수 함수형 언어는 변수가 없다.

순수 함수형 언어에는 변수와 변수를 바꾸는 대입 연산자(C 언어를 예로 들면 =)가 없다. 명령형 언어에서 a=3 이 a 에 3 을 대입하라는 명령인 반면, 순수 함수형 언어에서는 a=3 을 수학에서 let a be 3. 같이 a 를 3 으로 '정의'하는것으로 본다. 즉 한번 a를 뭐라고 정의했으면 그 정의는 유효 범위 내에서 값이 바뀌지 않는다! 그 유효 범위 안쪽에서 a를 다시 재정의 할 수도 있지만 내부 유효범위 한해서 'a'의 정의가 바뀌는거지 대입되는게 아니다. 안쪽과 바깥쪽이 서로 다른 의미의 'a'가 되는 것.

이게 불러오는 가장 큰 차이가 명령의 '순서'가 의미없다는점이다. 명령형 언어에서는 맨 윗줄에 a=3 이 있더라도 저 아래에 등장하는 a 가 여전히 3임을 보장할수가 없다. 그렇기때문에 a 값을 다른값으로 업데이트 하기 '전'과 '후'의 결과 자체가 완전히 달라지고 순서가 매우 중요하지만, 순수 함수형 언어에서는 첫줄에 a=3 이 있으면 scope(유효범위) 전체에서 a 는 그대로 3 이다. 그렇다면 굳이 a 를 사용하기 '전'에 미리 정의할 필요가 없고, scope 내의 아무곳에나 정의가 되어있기만 하면 그걸 그냥 갖다 쓰는 방식으로도 아무런 문제가 없다.

이런 특징에서 나오는 장점으로 표현식의 의미가 명료해진다는 것이 있다. 또, 제어 흐름을 생각하지 않고 프로그래밍 할 수 있다는 장점이 있다. 디버깅을 할 때도, 명령형 언어에서 버그를 잡을 때는 변수들의 전후 변화를 생각하면서 머리를 싸맬 때, 함수형 언어는 값의 변환만을 살펴보면 쉽게 디버깅 할 수 있다. 절차형 언어와는 달리 눈에 핏발을 세우고 변수가 어떻게 변화하나 추적할 필요가 없다며 함수형 언어 팬들은 자랑하고는 한다.

• destructive update

두번째로 동반되는 명령형 언어와의 차이점이 destructive update 인데, 예를 들어 일반적인 명령형 언어에서 a=a+1는 a라는 변수에 a를 1만큼 증가시키라는 의미를 가지며 이 명령을 시행하는 시점에서 변수 a의 값이 바뀌게 된다.

하지만 순수 함수형 언어인 하스켈의 경우 a=a+1는 말그대로 a는 자기자신보다 1만큼 더한 수라는 것을 의미하며, a의 값을 구해서 출력하게 하면 a=a+1=(a+1)+1=((a+1)+1)+1=(((a+1)+1)+1)+1=... 이런 식으로 무한 루프에 빠져서 영원히 a의 값을 출력하지 못하고, 이미 a의 다른 정의가 있었다면 컴파일러가 중복 정의가 있다며 에러를 뱉어낸다. 하스켈같은 경우, 아예 a=a 를 ㅗ(논리학에서의 falsum) 로 정의한다.

일반 프로그래머의 상식으로는 도저히 이해가 안 될 결정인데 일부러 난해한 프로그래밍 언어라도 만들 생각으로 만들었을까? 그게 아니고 함수형 언어는 수학의 '함수'를 프로그래밍 언어 설계에 적극적으로 반영한 것이다. 수학의 함수는 정의상 입력이 같으면 출력도 같다. 그러니까 f(x)=x+1 인 함수를 정의했다면 f(1)=2다. 다른 값은 절대 나오지 않는다. 함수형 언어의 함수도 마찬가지로 function boo(1)의 수행 결과가 2였다면 언제 어느때든 boo(1)은 2만 나온다. 하지만 함수형 언어가 아닌 언어에서는 boo(1)이 3도 나올 수 있고 4도 나올 수 있다. 그러니까 C언어로 치면 이런 함수에 해당한다.

int inc(int a) { static int c=0; c=c+a; return c; }

이 함수에 1을 넣어 여러 번 호출하면 1, 2, 3, 4, 5, ...가 나온다. 순수 함수형 언어는 이게 안된다는 얘기다.
이 특징으로 얻는 이득으로 함수형 언어는 '캐싱'이 가능하다. 그 함수를 호출한 파라메터(f(x)에서 x)을 알고 있고 그것을 수행한 결과를 안다면 다음에 호출할 때는 그냥 캐싱한 결과값을 돌려주면 된다. 만약 피보나치 수열의 재귀함수 구현에 메모이제이션을 적용하면 극단적으로 속도가 빨라지는데 아예 [math]O(2^n)[/math]가 [math]O(n)[/math]으로 바뀌어 버리는 마법같은 일이 벌어진다. 물론 절차형 프로그램도 외부 상태에 전혀 의존하지 않는 순수 함수를 구현하면 캐싱이 가능하긴 한데 그게 언어 차원에서 보장이 되느냐 프로그래머가 의도해야 하느냐의 차이가 있다.

두번째로 입력이 같으면 출력이 같다는 게 언어 차원에서 보장되기 때문에 손쉽게 병렬화(멀티스레딩)이 가능하다. 최근에 함수형 언어가 다시 각광받는 이유중에 하나로, 멀티코어 프로세싱이 요구되고 있는 현 상황에서 떠오르는 강력한 장점으로 꼽힌다. 멀티코어 및 클러스터 컴퓨팅에서 병렬화 모델은 크게 공유 메모리 모델과 메시지 전달 모델로 나뉘어지는데 과거에는 공유 메모리 모델이 빨랐으나 현대의 컴퓨터는 메시지 전달 모델이 더 빠르게 작동한다. CPU 자체, 그리고 CPU가 사용하는 프로세서간 통신 채널은 피코초 단위로 동작하지만 메모리 반도체는 캐패시터의 충전 시간 때문에 아직 나노초 단위로 동작하기 때문이다. 문제는 메시지 전달 모델의 경우 각자 사용하는 메모리 공간이 완전히 격리돼있어 상태를 공유하고자 할 경우 그걸 모든 프로세서에 동기화해야 하므로 그곳이 병목지점이 돼버리는데 함수형 프로그래밍 모델에서는 공유할 상태가 없으므로 병목 지점이 사라지고 모든 코어, 모든 컴퓨터가 각자 낼 수 있는 가장 빠른 속도로 동작하게 된다.

물론 공유 상태가 없으므로 메시지 전달 오버헤드는 공유 메모리 모델보다 높지만 바로 윗 문단을 봐라. 속도 자체가 나노초와 피코초(약 1000배)의 차이가 난다. 공유 메모리 모델은 뮤텍스(메모리 쓰기 권한을 얻는 것)관리를 해야 하기 때문에 가장 느린 스레드의 속도에 다른 모든 스레드가 맞춰져 버린다

그리고 함수를 first-class datatype으로 분류하기에 함수를 그냥 보통 변수 다루듯 할 수 있다. 즉 함수를 다른 함수에 인수로 바로 넘겨줄 수도 있고, 함수를 만드는 함수(함수를 반환값으로 가지는 함수)를 정의할 수도 있으며 생산성이 매우 뛰어나다. 코드가 매우 간결해지며 버그가 잘 생기지 않는 견고한 코드가 나오는 경향이 있다.

자료구조 상 destructive update 가 허용되지 않기때문에 효율적인 자료구조와 알고리듬도 명령형 언어에 비해 상당히 달라지게 된다. 일반적으로 저런 destructive update를 사용하는 자료구조를 ephemeral data structure 라 하며, 순수 함수형 언어에서 사용되는 자료구조를 persistent data structure 라 한다.

참고로 객체지향 언어와 함수형 언어는 서로 배타적인 개념이 아니다. 최근 함수형 패러다임이 유명세를 타면서 C++ 이나 파이썬등 명령형 언어들에서 앞다투어 함수형 언어의 기능을 탑재하고 있다. 또, F#, Scala, OCaml같이 OOP와 함수형 프로그래밍을 짬뽕해놓은 멀티패러다임 언어들도 많다. 사실 JavaScript도 함수형 패러다임을 포함한다. 다들 명령형으로 짜서 잘 모를뿐이지 그러니까 굳이 함수형 언어를 안배우더라도 함수형 패러다임과 알고리듬정도는 배워두면 어느정도 도움이 된다.

함수형 언어의 시초는 아주 옛날에 개발된 LISP부터 시작해서 그 방언 스킴(Scheme)등 이 있었고, 그 Scheme의 방언이며 자바가상머신에서 실행되는 클로저(Clojure), 전화교환기용 언어에서 출발한 Erlang, 타입 검증용 언어에서 시작된 ML, 극단적인 언어 디자인으로 유명한 Haskell 등이 있다. 객체지향의 한계가 슬슬 드러나고 있는 현재 함수형 언어의 여러 특징들이 다시 주목받고 있다.

5.3.2 논리 프로그래밍

명령형 언어가 튜링머신에, 함수형 언어가 람다 칼큘러스에 기반하고 있다면, 논리 프로그래밍은 수리논리학의 First order logic(1차언어)를 모델로 사용하는 프로그래밍 언어의 총칭이다. 사실, 이바닥의 알파와 오메가인 Prolog 이 1차언어에 기반하고 있기때문에 이런식의 정의가 많이 쓰이지만, 실제론 Higher order logic, F-logic, linear logic 등 여러가지 다른 논리를 사용하는 언어도 있고, 이것들도 대부분 Prolog 에 기반하고 있는 경우가 많아서 다 논리 프로그래밍 언어라 한다. Clause의 집합이 곧 프로그램이 되며, Clause는 이쪽에서 가장 유명한 Prolog 언어를 예로 들면, Head :- Body 형식으로 정의된다. 이것은 If Body, then Head 즉, To solve Head, solve Body 식으로 해석할 수 있다. 사실 일반 프로그래머 눈에 위의 함수형 언어보다 더더욱 괴악해보이게 마련인데, 그래도 튜링 컴플리트이며, C++ 등과 같은 General purpose 언어이다. 함수형 언어에서 프로그램을 함수들의 집합으로 보고 있다면, 논리 프로그래밍에서는 프로그램을 공리들의 집합으로 보고 있다고 이해하면 된다. 명령형 언어와는 거리가 멀지만, 함수형 언어와는 의외로 가까운편이고 실제 코드도 꽤 비슷한 양상을 띈다. 실제 코딩시의 함수형 언어와 가장 큰 차이라면 아무래도 함수형 언어가 '함수'를 사용할때, 논리 프로그래밍 언어에서는 '관계'(Relation)를 사용한다는 부분이 가장 큰 차이일것이다. 관계를 사용함으로서 연역되는 차이는, 함수의 경우 하나의 인풋에 하나의 출력값만을 보장하게끔 정의가 되어있지만, 관계는 이런 제약이 존재하지 않기때문에 보통 조건을 모두 만족시키는 결과값을 전부 내놓는다. 이런 특징때문에 Constraint programming 에도 많이 쓰이고, 특히 일반적인 프로그래머가 가장 쉽게 접할 수 있는 예시가 데이터베이스 쿼리이다.

다만, Prolog 은 논리 프로그래밍 언어지만, 순수 선언형 언어는 아니다. Mercury 라는 순수 선언형 논리 프로그래밍 언어도 있고, 스페인에서 팍팍 밀어주는 Ciao 도 순수 선언형 서브시스템을 지원한다. 이쪽 언어들은 Prolog 을 제외하면 Prolog 을 기반으로 해서 여러가지 실험적인 확장을 시킨것들이 많기때문에, 유저 매뉴얼이 곧 논문인 경우가 많고, 수리논리학 이론을 잘 모를경우 접근하기 힘든것들이 대부분이다. 하지만, 그렇다고 이론단계에만 머물러 있는 프로그래밍 패러다임은 아니고, Sicstus 같은 상용 컴파일러도 있으며, NASA 같은곳에서도 사용하는등 의외로 쓰이는곳이 있.는.편.이.다.

5.4 특수 목적 언어

일반적이지 않은 환경에서 쓰이는 언어로 데이터베이스용 언어인 SQL, GPU를 제어하는 언어인 CUDA같은 것도 있다. 인공지능 언어인 Prolog, 그래픽스 처리를 위해 고안된 Processing, 공학용 시뮬레이션에 특화된 MATLAB, 웹 사이트를 만드는데 특화된 PHP같은 것도 특수 목적 언어에 속한다.

특수 목적 언어의 특징은 해당 분야에서는 뛰어난 생산성을 보인다는 것이다. 그러나 해당 분야를 벗어나면 개발이 불가능하거나 오히려 더 난해해진다. 물론 프로젝트 하나를 통째로 한 가지 언어로만 개발하라는 법은 없기 때문에 여러 개의 특수 목적 언어와 일반 목적 언어(대부분 C언어)를 조합해서 프로젝트를 진행하는 경우도 많다.

6 프로그래밍 패러다임

6.1 반응형 프로그래밍

Reactive programming. 데이터를 중심으로 사고하는 방식인데 같은 데이터 중심 시각의 OOP와 다른 점은 반응형 프로그래밍은 데이터의 흐름 즉 데이터 플로우(Data flow)에 더 관심을 갖는다. 반응형 프로그래밍 언어 중 가장 쉽게 볼 수 있는 것은 스프레드시트 프로그램인 엑셀이 있다. 프로그래밍 언어는 모름지기 텍스트 편집기로 작성하는 거라고 따지고 싶다면 RxJS라고 하는 게 있다.

반응형 프로그래밍에서는 값의 변화를 추적한다. 사실 반응형 프로그래밍의 기반은 함수형 프로그래밍으로, 함수형 프로그래밍의 '불변식' 개념에 기초한다. 반응형 프로그래밍에서 변수의 값을 바꾸면 해당 변수를 참조하는 모든 식들이 연쇄적으로 재평가되면서 스스로의 값을 갱신한다. 즉 프로그래머가 명시적으로 재계산 명령을 내리지 않는다!

OOP나 함수형, 논리형 프로그래밍과 배척하는 관계는 아니라는 점에 주의. OOP도 세터(Setter)메서드에 적절한 처리를 해 주면 반응형으로 만들 수 있다. 다만 반응형 프로그래밍을 직접 지원하는 언어나 라이브러리는 그런 적절한 처리를 자동으로 해 준다는 차이가 있다.

반응형 프로그램은 정의된 식이 사이클을 형성하지만 않는다면(예를 들어 A = B + 1, B = A + 1 같이 서로가 서로를 참조하는 두 정의가 있으면 사이클이 형성됐다고 한다) 모든 변수는 해당 변수를 정의한 식을 항상 만족한다. 일반적인 명령형 프로그램은 명시적으로 재계산을 수행해줘서 값을 동기화시켜줘야 한다. 따라서 함수에서 특정 값을 갱신하는 작업을 빼먹거나 계산 순서를 실수하면 버그가 발생한다. 함수형 프로그램은 아예 변수라는 개념이 없고.

반응형 프로그램은 외부 상태를 받아들이는 데에도 관대해서 하드웨어 클록을 변수로 받아들이는 등의 작업이 함수형 프로그램보다 쉬운 편이다. 함수형 프로그램은 함수가 자기 자신에 대해 항상 닫혀 있어야 하지만 반응형 프로그래밍 모델에는 그런 제약이 없다. 사실은 반응형 프로그래밍 모델에서의 함수는 함수형 프로그래밍처럼 자기 자신에 대해 닫혀 있지만 외부의 상태가 변하는 것까지 추적해서 자동 재계산을 수행한다.

단점은 언제 변할지 모르는 수많은 변수를 일일이 추적하다보니 컴퓨터 성능을 상당히 잡아먹는다는 것. 예를 들어 여러 개의 값이 한꺼번에 바뀔 때 명령형이나 함수형 모델에서는 세 값이 다 변할 때까지 기다렸다가 한 번 재계산하는 등의 융통성을 발휘할 수 있지만 반응형 모델은 하나 바뀔 때마다 재계산을 해 댄다. 이를 개선하기 위해 지연 평가개념을 적극적으로 적용하고 있긴 하지만 그래도 실성능이 상당히 나쁘게 나오고 있다. 그래서 고속 처리가 요구되는 곳에서는 영 사용할 게 못되고 사용자의 입력에 반응하는 UI로직에나 사용할 만 하다. 물론 UI에만 사용하면 되는 문제이므로 게임 같은 고성능 소프트웨어를 개발할 때 이걸 못 쓰는 건 아니다. 사용자 입력을 처리하는 UI프론트엔드는 아무리 게임이라도 사람의 입력 속도는 컴퓨터 입장에서는 충분히 느리기 때문에 사용할 수 있다. 하지만 AI로직 같은데 사용하기에는 아직 성능상에 문제가 있다.

7 목록

구체적인 언어의 목록은 해당 문서를 참조 바람.

8 코드 예제

해당 문서를 참조 바람.

9 기타

사실 프로그래머들이 아니면 다른 사람들이 볼 일이 없지만 최근에는 진부함을 탈출하려고 하는 몇몇 한국 양판소에서도 쓰인다.
물론 쓰인다고 해서 꼭 양판소라고는 할 수 없다. 라노벨 계열중에서도 알기 쉬운 현대마법같은 작품도 있지만, 수작에 들어가는 편. 하지만 진짜(?) 양판소라면...더 이상의 자세한 설명은 생략한다.

바이오니클, 바이오니클(리부트) 시리즈에서 공통적으로 쓰이는 마토란 언어는 위대한 존재들이 마토란 유니버스의 거의 모든 지적 생명체들을 창조하는 데 사용했던 프로그래밍 언어이다. 그리고 마토란, 투라가, 토아(바이오니클) 등 마토란 유니버스의 거의 모든 지적 생명체들은 이 프로그래밍 언어를 실제 언어처럼 사용하고 있다.

• 난해한 프로그래밍 언어
• PYPL에서 프로그래밍 언어 인기 순위를 볼 수 있다. 2015년 12월 기준 Java가 1위, Python이 2위, PHP가 3위이다.