프로그래밍 언어
Programming Language
1. 개요
기계(컴퓨터)에게 명령 또는 연산을 시킬 목적으로 설계되어 기계와 의사소통을 할 수 있게 해주는 언어를 뜻한다. 그 결과, 사람이 원하는 작업을 컴퓨터가 수행할 수 있도록 프로그래밍 언어로 일련의 과정을 작성하여 일을 시킨다. 쉽게 말하면 컴퓨터를 부려먹기 위한 언어. 소프트웨어를 만드는데 기본이 되고, 이 소프트웨어는 논리 연산의 집합이기 때문에 수리 언어의 일종으로 보는 시각도 있다.
컴퓨터보다 먼저 등장하였으며 본격적인 연구는 1930년대 즈음부터 수학자들에 의해 기계적으로 계산 가능한 함수에 대한 연구가 진행된 데에서 비롯되었다. 그 결과 기계가 이해할 수 있는 언어가 탄생했으며, 바로 이 기계가 계산 가능하고 이해 가능한 언어를 실행하는 기계로 언어보다 나중에 발명된 것이 바로 현대적 의미의 컴퓨터이다.
2. 등장 배경과 역사
역사를 잘 살펴보면 프로그래밍 비스무리한 것을 만들고 했던 기인들이 종종 등장하지만, 프로그래밍 언어라는 본격적인 개념은 역시 수학에서 등장하였다. 쿠르트 괴델은 불완전성 정리를 증명하는 과정중에 알고리즘을 추상화시킨 원시 재귀 함수(primitive recursive function) 개념을 만들고, 이를 이용하여 증명에 성공하였는데, 수학적으로 본다면 이것이 최초의 프로그래밍 언어라 볼 수 있다.(굳이 따지자면 함수형 언어라 할 수 있다.) 그리고, 몇년 후에 컴퓨터의 아버지라 불리는 튜링은 불완전성 정리를 보고 "어 이거 내 방식대로 증명해볼 수 있겠는데?"라고 생각하며 연구를 하는데, 여기서 이 원시재귀함수와 동치인 튜링 머신을 발표하고 이 튜링머신을 이용하여 불완전성 정리를 다시 한 번 증명해보인다. 이는 "어떤 체계를 통해서 이 체계의 모순성을 증명할 수 있는 방법은 없다"와 동치이다. 정지 문제 참조.
그 이후 계산가능성이론(Computability Theory)이라는 수학의 분야가 생기면서 기존의 원시재귀함수를 확장한[1] Lambda calculus라거나 Unlimited register machine(URM), While-programming[2], SKI[3] 등등 알고리즘을 표현하기 위한 여러가지 체계들이 등장한다.
참고로, Lambda calculus를 고안한 알론조 처치의 경우 혹시나 이것을 이용하면 수학의 완전성을 증명할 수 있지 않을까 해서 시도하지만, 실패한다. 문제는, 상기된 알고리즘 체계들은 모든 알고리즘을 다 표현할 수 있는 체계인가라는 의문인데, 알고리즘이라는것이 수학적으로 정의된 개념이 아니기때문에 그것을 증명하는것은 불가능하였다. 하지만 저 모든 알고리즘 체계들이 표현방식은 다르더라도 수학적으로 볼때는 다 동일하였기 때문에 알론조 처치는 저 알고리즘 체계들이 '모든 알고리즘의 집합'과 동치라고 그냥 간주할 것을 제안하며, 이것이 그 유명한 처치의 명제(Church's Thesis)[4]이다.
이렇게 수학 쪽에서 프로그래밍 언어에 대한 개념적인 기초가 닦아지는 동안, 역시 수학자인 폰 노이만은 그것들을 이용하여 실제 컴퓨터를 만들기 위한 폰 노이만 구조를 만든다. 그렇게 전자쪽과 결합을 하면서 현대 컴퓨터의 원형이라고 할 수 있는 물건이 만들어졌다. 이러한 전자적인 계산장치는 전기신호를 통해서 제어하였는데, 전기신호를 표현할 수 있는 방법은 신호가 들어왔다(1), 신호가 들어오지 않았다(0) 정도에 불과하였다. 따라서 제어신호는 0과 1만으로 표현하는 라이프니츠[5]식 2진법을 사용할 수 밖에 없었고, 특정한 패턴의 전기신호는 어떠한 동작을 의미한다는 식으로 사람들이 정하고 전자계산장치는 그 신호가 입력되면 정해진 동작을 하는 형태였다.하지만 실제 컴퓨터의 동작에서는 장치가 꺼져서 전기신호가 없는 상태인지 아니면 0을 나타내는 상태인지 구별하기 위하여 0은 기준 레벨(일반적으로 볼트#s-1 단위로 표시한다) 이하의 신호일 경우 0으로 본다. 마찬가지로 1 역시 기준 레벨 이상의 신호일 경우 1로 본다.
따라서 뭔가 동작을 시키기 위해서는 이러한 제어신호를 사람이 직접 작성해야 됐는데, 초창기에는 그 0과 1의 제어신호를 사람이 직접 작성하는 형태의 기계어가 사용되었다. 이 기계어는 항목에서 볼 수 있듯이 이쪽 분야에서 가장 원시적인 언어로 기계는 바로 이해할 수 있는데 사람은 도저히 이해하기도 어렵고 알아보기도 힘든 물건이라 결국 사람이 읽기 편하도록 기계어와 특정 기호를 1:1로 대응시키는 어셈블리어가 등장하였다. 과거 기계어를 쓰는 시절보다는 보기가 좀 편해졌지만 여전히 해독하기가 난해하였고, 컴퓨터의 보급과 함께 프로그램의 수요가 늘어나는데 어셈블리어의 생산성은 심히 안습이라서 조금 더 프로그램을 짜기 쉬운 언어들이 등장하기 시작하였다.
초창기에 프로그래밍 언어들은 컴퓨터 성능의 한계로 인해 많은 제약이 따라붙었고, 어셈블리어적인 성격이 어느정도 남아있었다. 그럼에도 어셈블리어에 비하면 읽기가 편했고 이해하기도 훨씬 수월했다. 그리고 컴퓨터의 보급과 성능 발달에 맞물려 그동안 걸려있던 제약조건들도 하나씩 사라지고 보다 사람이 읽기도 쉽고, 이해하기도 쉽고, 작성하기도 쉬운 프로그래밍 언어들이 속속 등장하였다.
다만 어차피 컴퓨터가 이해할 수 있는 언어는 기계어 뿐이기 때문에 사람이 하기에 편해졌다는 것 뿐이지 실제 그 뒤에서 이루어지는 작업은 훨씬 더 복잡해지고 있다.
정리하자면 기계에게 편한 언어는 속도가 빠르지만 사람이 도저히 알아볼 수 있는 물건이 아니라서 생산성이 떨어진다. 반면 사람에게 편한 언어는 속도는 느리지만 이해하기 쉽고 생산성이 높다는 상관관계가 성립한다. 회화 언어로 치자면 중역의 문제로 볼 수 있다.
단, 여기에 함정이 있는데 기계어로 짠 발적화 코드와 자바로 짠 최적화 코드의 수행속도를 비교한다면 당연히 자바 쪽이 빠르다. 그러니까 기계어를 사용한다 해도 그걸 다루는 프로그래머가 기계의 특성을 훤히 꿰고 있지 않으면 다른 고급언어를 사용한 결과물보다 느려질 수도 있다는 얘기다. 그래서 몇몇 개발관련 서적에서는 최적화나 성능 튜닝한답시고 기계어나 어셈블리어를 남용하지 말라고 조언한다. 실제로도, 지금은 컴파일러와 어셈블러가 무척 발달되어 있어서 사람이 어설프게 짠 코드보다 기계가 변환한 코드 쪽이 더 낫다. 물론 기계가 알고리즘 자체를 개선해주지는 못하므로 컴파일러한테 자신이 의도한 바를 명확하게 전달하는 게 더 중요하다. 예를 들어 "이 배열에 있는 값은 계산 끝날 때까지 중간에 바뀔 일은 절대 없으며 숫자 말고 엉뚱한 건 전혀 없다고 보장하고, 하고 싶은 일은 이걸 다 더하는 것이다." 라고 컴파일러에게 명확하게 자신의 의도를 전달하면 컴파일러는 각종 하드웨어 가속과 코드 병렬화 등을 수행해 프로그래머가 의도한 일을 자신이 할 수 있는 가장 빠른 방법으로 구현해낸다. 일반 루프문을 사용한 배열 숫자 덧셈은 컴파일러가 숫자가 중간에 바뀔지 안바뀔지 판단을 못 하는 경우(전역변수의 배열을 더한다거나)가 생길 수 있는데 애초에 이런 코드를 만들지 않는 능력이 더 중요하다.
여담으로 난해한 프로그래밍 언어보다는 어셈블리어가 훨씬 읽기 쉽다...
3. 구조
프로그래밍 언어의 표기는 구문론(syntax)과 의미론(semantics)의 두 가지 파트로 이루어진다. 구문이란 것은 언어의 외형적인 표기 방법을 일컬으며, 의미론은 구문이 내포하고 있는 의미, 즉 그 코드가 수행하는 작업을 뜻한다. 구문이 문법에 비유된다면 의미론은 글에 담긴 정보라고 볼 수 있다.
더욱 작은 단위로는 문자열(string), 문장(sentence), 어휘항목(lexeme) 등이 있으며 어휘항목의 종류를 통틀어 토큰(token)이라 한다. 어휘항목에 속한 요소에는 식별자(identifier)[6], 리터럴(literal), 연산자(operator), 예약어(reserved keyword)[7] 등이 있다.
대부분의 일반적인 프로그래밍 언어는 이런 토큰들이 영어(정확히는 미국식 영어)로 되어 있다. 물론, 창조나 씨앗 같은 예외도 있긴 하다.
4. 분류
4.1. 해석 방식에 따른 분류
크게 AOT 컴파일 언어, JIT 컴파일 언어, 그리고 인터프리터 언어로 분류할 수 있다. 이 분류는 정확히 말하면 언어의 분류가 아니라 언어 구현체의 분류로, 언어 명세가 어느 한 쪽을 완전히 배제한 형태가 아니거나 다른 특별한 이유가 있지 않는 이상 대부분의 언어는 이론상 어떤 식으로든 구현 가능하다. 더불어, 산업 현장에서 널리 쓰이는 언어는 기본적으로 컴파일되어 실행된다고 보면 된다. 아래의 구분은 언어의 대표 구현체를 따른 것이고, 결코 언어 자체의 분류가 아님에 유의할 것. 예를 들면, C언어라고 항상 AOT 컴파일되는 것이 아니며[8], Java라고 항상 JIT 컴파일 되는 것도 아니며[9], OCaml[10]과 Erlang[11]등의 언어는 아예 기본 구현체에 둘 다 포함시켜서 배포한다.
- AOT 컴파일 언어 : C언어, 파스칼, Haskell 등이 포함된다. 소스 코드를 미리 기계어로 번역[12]해서 실행한다. 세간에 널리 퍼진 인식과는 다르게 어떤 언어의 구현체가 AOT 컴파일러인 것이 결코 빠른 런타임 퍼포먼스를 보장해주지는 않는다.
- JIT 컴파일 언어 : 대부분의 언어가 여기에 속한다. Java 및 JVM 언어[13], JavaScript 및 WebAssembly[14], C\# 및 CLR 언어[15] 등의 언어들은 기본 구현체가 JIT 컴파일러이다. 이 언어들은 대부분 바이트코드를 생성하는 1차 컴파일러, 그리고 1차 컴파일러가 생성한 바이트코드를 실행하는 가상머신(VM)으로 이루어져 있다. 이 가상머신 안에 바이트코드에 대한 인터프리터, 바이트코드를 기계어로 컴파일하는 JIT 컴파일러와 GC를 비롯한 런타임이 포함된다. JVM과 CLR, CPython의 경우에는 1차 컴파일러가 생성한 바이트코드 파일들을 배포에 활용하지만, 모든 언어가 그런 것은 아니다. 또한, JIT 구현체는 동일한 언어의 AOT 구현체에 비해 유연성이 높은 경우가 많다. 예를 들면 Java에서는 JIT 컴파일할 시에는 가능한 동적인 클래스로딩이 SubstrateVM을 통한 AOT 컴파일 시에는 불가능하고, Reflection[16]에 어느정도 제약이 가해진다.
- 인터프리터 언어 : 소스 코드를 한 줄 한 줄 읽어 그때그때마다 번역해서 수행한다. BASIC이나 bash 같은 언어가 이런 형태이다. 소스 코드를 한 줄씩 읽어서 수행하기 때문에 대체로 AOT 컴파일 언어나 JIT 컴파일 언어에 비해 성능이 떨어지는데 2010년대 들어서 인터프리터엔진에도 JIT기법이 도입되었다. Python[17], Ruby[18], PHP[19] 등이 있다. 장점은 구현이 단순하고 구현체의 절대적인 크기가 작다는 것이다. 그 밖에 bash, awk과 같이 구현체가 매우 가볍고 간단할 필요성이 있는 경우, 또는 구현체를 충분히 빠르게 만들도록 노력을 들이지 못한 수많은 마이너 언어들이 인터프리터를 통해 작동한다.
4.2. 메모리 관리 방식에 따른 분류
크게 비관리 언어와 관리 언어로 분류할 수 있다.
- 비관리 언어(Unmanaged Language): 동적 할당된 메모리의 해제가 자동으로 이루어지지 않으며, (주로 포인터를 이용한) 메모리 직접 접근이 가능한 언어이다. Bare Metal Language라고도 하며, 대표적으로는 C, C++ 등이 있다. 수동 기계제어가 가능한 만큼 프로그래머의 최적화 실력에 따라 높은 퍼포먼스를 낼 수 있지만, 반대로 생각하면 그렇기 때문에 메모리 관리를 제대로 하지 않을 시 프로그램이 망가질 가능성이 커서 관리 언어에 비하면 생산성은 떨어진다.
- 관리 언어(Managed Language): 동적 할당된 메모리의 해제가 가비지 컬렉터(Garbage Collector)에 의해 자동으로 이루어지며, 메모리 접근에 대한 부분을 추상화시켜 직접적인 기계제어를 기본적으로 차단한다. 대표적으로는 Java, C\#, Python, Go 등이 있다. 메모리 관리를 언어 차원에서 책임져 주기 때문에 상대적으로 생산성은 높지만, 메모리에 직접 액세스할 수 없으므로 비관리 언어에 비해 성능 면에서 손실이 있다.
4.3. 정적 타입, 동적 타입
- 정적 타입 언어 : 자료형(Type)이 고정돼 있는 언어. 간단히 얘기하자면 정수형으로 정의한 1은 계속 정수형 1로 남아있다. 이걸 실수형 1.0으로 바꾸려면 명시적인 형 변환(Type casting)을 해줘야 한다. 묵시적 형 변환이 이루어지는 경우도 있지만 제한적이다. C, C++, Java, C\# 등이 여기에 해당된다.
- 동적 타입 언어 : 타입이 실행 시간에 결정되는 언어. 실행하기 전까지는 특정 식의 타입을 알 수 없다. 자료형이 그것을 처리할 함수(또는 메서드)에 따라 그때그때 바뀌는 언어. 예를 들어 정수형 1을 정의했어도 그걸 처리할 함수가 문자열을 받아들이게 설계돼있다면 자동으로 정수형 1을 문자 1로 바꿔준다. Python, JavaScript, Ruby 등이 여기에 해당된다.
동적 타입 언어 중에서 자바스크립트는 암시적으로 자료형을 마구 변환해주지만 기능보다는 설계결함으로 간주된다. 정적 타입 언어 중에서는 C가 이런 무분별한 암시적 형변환으로 악명높다. 알아서 변환해준다는게 좋게들릴지 몰라도 막상 써보면 괴로워지는 경우가 더 많다.
정적 타입 언어가 별 거 아닌 것처럼 느껴질 수도 있지만 실은 프로그래머들을 짜증나게 하는 주범이 바로 형 변환(Type casting)이기 때문에 동적 타입 언어는 이런 점에서 매우 강점을 가진다. 특히 객체 지향 언어에서는 동적 타입 및 그것의 일반화버전이라 할 수 있는 덕 타이핑(Duck typing)이 프로그래머에게 수많은 혜택을 준다. 예를 들어 오리라는 타입과 닭이라는 타입이 있고 둘 다 날아오르는 기능이 있다면 정적 타입 언어에서는 상위 인터페이스를 추출하는 등의 부가 작업이 필요한데 덕 타이핑을 지원하는 언어에서는 그냥 넣어버리면 알아서 난다. 물론 단점도 있는데 고래 같이 못 나는 타입을 집어넣으면 실행시간 오류(런타임 에러)를 뱉어버린다는 것. 정적 타입 언어는 이런 문제가 없다...고 알려져 있지만 거짓말이고 정적 타입 언어도 닭은 닭인데 통닭 같이 못 나는 타입을 집어넣는 바람에(기술적으로는 해당 메서드가 구현이 안된 객체) 런타임 에러가 나올 수 있다.
그러나 이건 현실을 전부 고려하지 않은 반쪽짜리 시각이고, 요즘은 정적 타입 언어가 동적 타입 언어보다 훨씬 생산적이고 오류가 날 가능성을 줄여준다는 점이 정설로 굳어지고 있다. 당장 동적 타입 언어로 유명한 파이썬과 자바스크립트[20]가 정적 타입으로 옮겨가려는 움직임을 보이는 것으로 알 수 있지 않을까? 위에 있는 예시는 거의 모두 현실과는 동떨어진 예제와 설명이다. 위에서 든 상위 인터페이스 추출이나 메서드 미구현 문제는 정적 타입의 문제가 아니라 객체지향의 문제로, 정적 타입과 하등 상관없고 오히려 동적 타입으로 객체지향 개발을 하려고 할 때 더 흔히 일어나는 문제들이다. 강하고 안전한 정적 타입 시스템을 지원하는 언어는 대부분의 일상적 프로그래밍 오류를 미연에 방지해준다. 하스켈을 비롯한 강-정적타입 언어 사용자들이 "컴파일이 된다면 버그는 없다"고 하는 말이 빈 말이 아닌 것이다. 단순 사용 편의성 측면을 봐도, 최신 IDE 및 개발 도구들이 제공하는 코드 자동 완성이나 리팩토링, 정의 이동 등의 기능들은 컴파일 타임에 타입을 제대로 추론할 수 없으면 거의 동작하지 못한다. 똑같은 프로젝트[21]를 진행해도 이런 고생산성 기능들을 제대로 활용하느냐 못하느냐에 따라 개발 기간이나 유지보수성이 천지 차이로 벌어진다.
참고로 하스켈(Haskell)은 정적 타입 언어다. 그런데도 하스켈 코드에는 형 변환 연산자가 없다. 이게 어찌된 일이냐 하면 하스켈 언어는 정적 타입 언어이지만 강력한 타입 추론 기능을 내장하고 있어 형변환을 언어 차원에서 자동으로 해 준다. 동적 타입 언어 역시 자동 형변환을 제공하는데 무슨 차이가 있냐면 그 형변환을 런타임에 하느냐 컴파일 타임에 하느냐의 차이다. 즉 버그가 발생하는 시점을 런타임(사용할 때)에서 컴파일 타임(만들 때)으로 끌어당긴다. 타입 추론 엔진은 딱히 하스켈 같은 선언형, 함수형 언어에만 도입할 수 있는 건 아니므로 신형 설계가 적용된 언어라면 명령형, 객체 지향 언어라도 타입 추론을 할 수 있다. 단지 정적 타입 언어로 유명한 C나 자바에 타입 추론 엔진이 없을 뿐이지. 여기서 타입 추론은 묵시적 형 변환과 동의어가 아니다. 겉으로 보이는 건 묵시적 형 변환하고 똑같지만.
하스켈은 형 변환을 하는 게 아니라 형 변환도 타입 선언도 둘 다 필요 없도록 추론을 통해 한 번에 맞는 타입을 부여해준다. 이를 묵시적 형 변환처럼 쓰려고 하는 건 큰 착각인데, 같은 타입으로 볼 수 없는 두 위치에서 같은 변수를 사용하면 묵시적 형 변환이 되는 게 아니라 컴파일 오류를 내뱉는다. 하스켈이나 ML에 쓰인 타입 추론 엔진은 Hindley-Milner 시스템이라 불리는데, 명령형 언어 중에서는 Rust가 이를 적용했었다(현재는 아님).
4.4. 프로그래밍 패러다임
4.4.1. 절차적 언어
알고리즘과 로직에 의거하여 단계 단계 밟아가며 문제를 해결하도록 짜는 프로그래밍 언어. 대표적인 언어는 C와 Pascal. 종종 객체지향 언어의 상대적 개념으로 절차지향 언어란 말을 쓰기도 하는데, 이는 객체지향 언어가 등장한 이후에 나타난 것으로 보인다.
애초에 C++나 Java 등의 객체지향 언어가 널리 알려지기 전에는 C 나 Pascal을 절차지향 언어라고 부르지는 않았다. 그보다는 구조적 프로그래밍 언어란 말이 C나 Pascal을 가리키는 말이었다. C++, Java 같은 객체지향 언어는 객체개념 구현 자체가 프로그램언어 개발의 지향점 중 하나였지만, C 나 Pascal 등의 언어는 절차지향을 목표로 개발된 언어가 아니다. 따라서, 객체지향을 구현하지 않은 기존 언어를 가리키는 말로 절차지향 언어보다는 절차적 언어가 적합한 용어일 것이다.[22][23]
4.4.2. 객체 지향 언어
객체 지향 언어는 프로그래밍을 함에 있어서 데이터와 그 데이터를 처리할 메소드를 한데 묶어 객체를 만들고 객체들을 조립하는 것을 목표로 한 언어들을 말한다. 객체 지향 언어의 특징은 추상화, 캡슐화, 상속성, 다형성이 있다. 추상화는 외부 인터페이스만 제공하고 객체 내부를 숨겨서 어떻게 일을 하는지 몰라도 결과를 내보낸다.[24] 캡슐화는 객체 내부에 필요한 데이터등을 묶어서 한번에 관리 할 수 있게 해준다.[25] 상속은 모객체를 상속받아 추가 기능을 더 붙이거나 약간의 수정을 가한 객체를 만들 수 있다.[26] (서브타입) 다형성은 메소드 이름은 같더라도 매개변수의 유무, 매개변수의 개수, 매개변수의 자료형, 반환하는 값의 자료형에 따라 다른 메소드가 실행될 수 있다는 것이다. 즉, 메소드명이 같아도 실제 행위는 타입에 따라 다를 수 있다는 것이며, 상향 형변환(upcasting) 및 동적 바인딩이라는 개념과 관련이 있는 특성이다.
더 자세한 것은 객체 지향 프로그래밍 항목을 참조.
4.4.3. 선언형 언어
선언형 언어(Declarative language)는 명령형 언어와 대비되는 개념으로, 함수형 언어와 논리 프로그래밍(Logic programming)등이 여기에 속한다. 현재 학계를 떠나 슬슬 업계 전반으로 확산되고 있다. 특히 신기술의 도입이 빠른 웹 앱 계열에서 선언형 스타일의 프로그램이 선호되고 있는데 JavaScript 코드의 코딩 스타일이 점점 선언형으로 변화하고 있다. 선언형으로 기술하는 가장 유명한 라이브러리로는 제이쿼리(jQuery)가 있으며 앵귤러JS(AngularJS)는 선언형 언어의 가장 최신 트렌드인 '''반응형 프로그래밍''' 개념을 도입하고 있다. (2-Way binding이라는 이름으로 소개하고 있다.)
순수 선언형 언어의 특징으로는 참조 투명성(referential transparency)[27]가 꼽힌다.
또한 선언형 언어에는 '지연 평가(Lazy evaluation)' 이라는 강력한 특징이 있다. 계산을 필요한 그 순간이 올 때까지 미룬다는 개념인데, 이 개념은 선언형 언어에만 있다. 단 선언형 언어 전부가 지연 평가를 지원하는 건 아니다. 이 지연 평가 개념의 강력함은 무한을 다룰 때 나타난다. 예를 들어 입력 데이터로 자연수 전체의 집합을 정의해서 대입하는 게 가능하다! 명령형 언어에서는 무한을 대입하면 말 그대로 무한히 계산을 하기 때문에 프로그램이 무한 루프를 돌며 멈춰 버리지만 지연 평가를 지원하는 언어에서는 만약 계산식의 마지막이 "...해당 리스트의 첫 5개를 출력." 하는 식으로 끝났다면 그 '첫 5개'를 찾아내기 위한 계산만을 수행하고 끝낸다. 예를 들어 "피보나치 수열의 10번째 항부터 30개 항을 출력하라"는 알고리즘을 구현할 때 명령형 언어라면 피보나치 수열을 생성하는 알고리즘 자체에 루프를 멈추는 코드를 삽입해야 하지만 지연 평가가 지원되는 선언형 언어의 경우 피보나치 수열 알고리즘은 "제네레이터"로 만들어 무한수열을 출력하게 하고 필터로 원하는 위치의 리스트를 뽑아주면 된다. 물론 당연히 "피보나치 수열의 '''마지막''' 다섯 개를 출력." 하는 식으로 짰다면 지연 평가고 나발이고 이쪽도 무한루프 돌며 프로그램이 멈춰 버린다. 피보나치 수열은 무한수열이기 때문에 "마지막"이 없기 때문.
선언형 언어가 아니어도 지연 평가를 구현하는 방법이 있긴 하다. 더티 플래그(dirty flag) 기법이 대표적. 단지 언어에서 직접 지원하지 않을 뿐이다.
4.4.3.1. 함수형 언어
[image]
명령형 언어가 튜링머신에 기반하고 있다면, 함수형 언어는 람다 칼큘러스에 기반하고 있는 언어에 대한 총칭이다. 현업에서 많이 쓰이는 명령형 언어와는 대조적으로 몇가지 특징이 있다.왜 함수형 프로그래밍이 좋은데? 도대체 어느 점이 마음에 드는거야?
꼬리재귀.
- 순수 함수형 언어는 변수가 없다.
이게 불러오는 가장 큰 차이가 명령의 '순서'가 의미없다는 점이다. 명령형 언어에서는 맨 윗줄에 a=3 이 있더라도 저 아래에 등장하는 a 가 여전히 3임을 보장할 수가 없다. 그렇기 때문에 a 값을 다른 값으로 업데이 하기 '전'과 '후'의 결과 자체가 완전히 달라지고 순서가 매우 중요하지만, 순수 함수형 언어에서는 첫줄에 a=3 이 있으면 scope(유효범위) 전체에서 a 는 그대로 3 이다.[28] 그렇다면 굳이 a 를 사용하기 '전'에 미리 정의할 필요가 없고, scope 내의 아무곳에나 정의가 되어있기만 하면 그걸 그냥 갖다 쓰는 방식으로도 아무런 문제가 없다.
이런 특징에서 나오는 장점으로 표현식의 의미가 명료해진다는 것이 있다. 또, 제어 흐름을 생각하지 않고 프로그래밍 할 수 있다는 장점이 있다. 디버깅을 할 때도, 명령형 언어에서 버그를 잡을 때는 변수들의 전후 변화를 생각하면서 머리를 싸맬 때, 함수형 언어는 scope만 잘 확인하면 쉽게 디버깅 할 수 있다. 절차형 언어와는 달리 눈에 핏발을 세우고 변수가 어떻게 변화하나 추적할 필요가 없다며 함수형 언어 팬들은 자랑하고는 한다.
- destructive update
하지만 순수 함수형 언어인 하스켈의 경우 a=a+1는 a라는 변수를 정의하는 것이 아니라 a라는 함수를 정의한다. 출력하게 하면 a=a+1=(a+1)+1=((a+1)+1)+1=(((a+1)+1)+1)+1=... 이런 식으로 무한 루프에 빠져서 영원히 a의 값을 출력하지 못하다. 이것은 lazy evaluation 때문이 아닌, 함수형 언어의 특징이다. 타 언어에 익숙하다면 저 a가 변수처럼 보일 수 있으나 함수를 정의하는 문법이다. f(x,y) 를 이변수함수로, f(x) 를 일변수함수로 보듯이, a 역시 f(void) 같은 파라메터가 0 개인 함수이다. 함수형 언어에서의 a=3 은 그냥 C 언어에서의 int a(void) { return 3; } 으로 보면 된다. 실제 수학에서도 상수가 따로 있는게 아니라 함수기호와 관계기호만 언어차원에서 정의하고, 함수기호의 파라메터가 0 일경우 이걸 그냥 '상수'로 부르는 경향이 있다. 사실 이런 특징이 일반 프로그래머 기준으로 좀 괴악하기때문에 대중적인 함수형 언어들중에는 순수성을 포기하고 명령형 언어적인 부분을 포함하여 destructive update 를 허용하는 경우도 있다. 이미 a의 다른 정의가 있었다면 컴파일러가 중복 정의가 있다며 에러를 뱉어낸다. 하스켈같은 경우, 아예 a=a 를 ⊥(논리학에서의 falsum) 로 정의한다.[29]
일반 프로그래머의 상식으로는 도저히 이해가 안 될 결정인데 일부러 난해한 프로그래밍 언어라도 만들 생각으로 만들었을까? 그게 아니고 함수형 언어는 수학의 '함수'를 프로그래밍 언어 설계에 적극적으로 반영한 것이다. 수학의 함수는 정의상 입력이 같으면 출력도 같다. 그러니까 f(x)=x+1 인 함수를 정의했다면 f(1)=2다. 다른 값은 절대 나오지 않는다. 함수형 언어의 함수도 마찬가지로 function boo(1)의 수행 결과가 2였다면 언제 어느때든 boo(1)은 2만 나온다. 하지만 함수형 언어가 아닌 언어에서는 boo(1)이 3도 나올 수 있고 4도 나올 수 있다. 그러니까 C언어로 치면 이런 함수에 해당한다.
이 함수에 1을 넣어 여러 번 호출하면 1, 2, 3, 4, 5, ...가 나온다. 순수 함수형 언어는 이게 안된다는 얘기다.int inc(int a) { static int c=0; c=c+a; return c; }
이 특징으로 얻는 이득으로 함수형 언어는 메모이제이션[30]이 가능하다. 그 함수를 호출한 파라메터(f(x)에서 x)을 알고 있고 그것을 수행한 결과를 안다면 다음에 호출할 때는 그냥 메모해둔 결과값을 돌려주면 된다. 만약 피보나치 수열의 재귀함수 구현에 메모이제이션을 적용하면 극단적으로 속도가 빨라지는데 아예 $$O(2^n)$$가 $$O(n)$$으로 바뀌어 버리는 마법같은 일이 벌어진다.[31] 물론 절차형 프로그램도 외부 상태에 전혀 의존하지 않는 순수 함수를 구현하면 캐싱이 가능하긴 한데 그게 언어 차원에서 보장이 되느냐 프로그래머가 의도해야 하느냐의 차이가 있다.
두번째로 입력이 같으면 출력이 같다는 게 언어 차원에서 보장되기 때문에 손쉽게 병렬화가 가능하다. 최근에 함수형 언어가 다시 각광받는 이유중에 하나로, 멀티코어 프로세싱이 요구되고 있는 현 상황에서 떠오르는 강력한 장점으로 꼽힌다. 멀티스레드 프로그래밍에서 버그 발생 원인은 스레드간 공유되는 메모리를 변경하는 것인데, 함수형 언어는 메모리가 불변이기 때문에 언어 차원에서 멀티스레드의 안정성이 보장되기 때문이다. 단 성능상으로는 이점이 없다.[32]
그리고 함수를 first-class datatype[33]으로 분류하기에 함수를 그냥 보통 변수 다루듯 할 수 있다. 즉 함수를 다른 함수에 인수로 바로 넘겨줄 수도 있고, 함수를 만드는 함수(함수를 반환값으로 가지는 함수)를 정의할 수도 있으며 생산성이 매우 뛰어나다. 코드가 매우 간결해지며[34] 버그가 잘 생기지 않는 견고한 코드가 나오는 경향이 있다.
자료구조 상 destructive update[35] 가 허용되지 않기 때문에 효율적인 자료구조와 알고리즘도 명령형 언어에 비해 상당히 달라지게 된다. 일반적으로 저런 destructive update를 사용하는 자료구조를 ephemeral data structure 라 하며, 순수 함수형 언어에서 사용되는 자료구조를 persistent data structure[36] 라 한다.
참고로 객체지향 언어와 함수형 언어는 서로 배타적인 개념이 아니라 얼마든지 섞어 쓸 수 있다. 최근 함수형 패러다임이 유명세를 타면서 C++이나 파이썬 등 명령형 언어들에서 앞다투어 함수형 언어의 기능을 탑재하고 있다. 또, F#, Scala, OCaml 같이 OOP와 함수형 프로그래밍을 짬뽕해놓은 멀티패러다임 언어들도 많다. 사실 JavaScript도 함수형 패러다임을 포함한다. 생산자-소비자 패턴과 같이, 객체 지향 언어에서 함수형 언어의 특징을 살린 패턴도 있다.[37] 그러니까 굳이 함수형 언어를 안 배우더라도 함수형 패러다임과 알고리즘 정도는 배워두면 어느정도 도움이 된다.
함수형 언어의 시초는 아주 옛날에 개발된 LISP부터 시작해서 그 방언 스킴(Scheme)등 이 있었고, 그 Scheme의 방언이며 자바 가상머신에서 실행되는 클로저(Clojure), 전화교환기용 언어에서 출발한 Erlang, 타입 검증용 언어에서 시작된 ML, 극단적인 언어 디자인으로 유명한 Haskell 등이 있다.
다만 함수형 프로그래밍이 완전한 메이저 패러다임이 될 수 있는지에 대해서는 회의적인 의견이 많다. 기본적으로 추상화 단계가 지나치게 높아져서 절대 다수의 개발자들에겐 코드 리딩이 어렵고, 기존의 자료구조를 상당히 들어엎어야 한다는 부담이 있다. 또한 함수형 프로그래밍을 추구하는 Clojure, Haskell 등은 대중성과는 한참 거리가 멀기 때문에 시장이 확대되기에도 무리가 있다.[38] 한 예로 C++만 해도 위에서 함수형 언어의 기능을 탑재하는 중이라고 했지만 여전히 업계에서는 잘 사용되지 않고 있으며, 함수형 언어의 장점인 병렬/분산 프로그래밍 또한 실제로는 기존 명령형 언어들의 기능을 가지고도 충분히 구현 가능한 경우가 대부분이다. 참고
4.4.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)[39]를 사용한다는 부분이 가장 큰 차이일것이다.
관계를 사용함으로서 연역되는 차이는, 함수의 경우 하나의 인풋에 하나의 출력값만을 보장하게끔 정의가 되어있지만, 관계는 이런 제약이 존재하지 않기때문에 보통 조건을 모두 만족시키는 결과값을 전부 내놓는다.
이런 특징때문에 Constraint programming 에도 많이 쓰이고, 특히 일반적인 프로그래머가 가장 쉽게 접할 수 있는 예시가 데이터베이스 쿼리이다.
다만, Prolog 은 논리 프로그래밍 언어지만, 순수 선언형 언어는 아니다.
Mercury 라는 순수 선언형 논리 프로그래밍 언어도 있고, 스페인에서 팍팍 밀어주는 Ciao 도 순수 선언형 서브시스템을 지원한다.
이쪽 언어들은 Prolog 을 제외하면 Prolog 을 기반으로 해서 여러가지 실험적인 확장을 시킨것들이 많기때문에, 유저 매뉴얼이 곧 논문인 경우가 많고, 수리논리학 이론을 잘 모를경우 접근하기 힘든것들이 대부분이다.
하지만, 그렇다고 이론단계에만 머물러 있는 프로그래밍 패러다임은 아니고, Sicstus 같은 상용 컴파일러도 있으며, NASA 같은곳에서도 사용하는등 의외로 쓰이는곳이 있는편이다.
4.4.3.3. 반응형 프로그래밍
Reactive programming. 데이터를 중심으로 사고하는 방식인데 같은 데이터 중심 시각의 OOP와 다른 점은 반응형 프로그래밍은 데이터의 흐름 즉 데이터 플로우(Data flow)에 더 관심을 갖는다. 반응형 프로그래밍 언어 중 가장 쉽게 볼 수 있는 것은 스프레드시트 프로그램인 엑셀이 있다. 프로그래밍 언어는 모름지기 텍스트 편집기로 작성하는 거라고 따지고 싶다면 RxJS라고 하는 게 있다.
반응형 프로그래밍에서는 값의 변화를 추적한다. 사실 반응형 프로그래밍의 기반은 함수형 프로그래밍으로, 함수형 프로그래밍의 '불변식' 개념에 기초한다. 반응형 프로그래밍에서 변수의 값을 바꾸면 해당 변수를 참조하는 모든 식들이 연쇄적으로 재평가되면서 스스로의 값을 갱신한다. 즉 프로그래머가 명시적으로 재계산 명령을 내리지 않는다!
OOP나 함수형, 논리형 프로그래밍과 배척하는 관계는 아니라는 점에 주의. OOP도 세터(Setter)메서드에 적절한 처리를 해 주면 반응형으로 만들 수 있다. 다만 반응형 프로그래밍을 직접 지원하는 언어나 라이브러리는 그런 '''적절한''' 처리를 자동으로 해 준다는 차이가 있다.
반응형 프로그램은 정의된 식이 사이클을 형성하지만 않는다면(예를 들어 A = B + 1, B = A + 1 같이 서로가 서로를 참조하는 두 정의가 있으면 사이클이 형성됐다고 한다) 모든 변수는 해당 변수를 정의한 식을 항상 만족한다. 일반적인 명령형 프로그램은 명시적으로 재계산을 수행해줘서 값을 '''동기화'''시켜줘야 한다. 따라서 함수에서 특정 값을 갱신하는 작업을 빼먹거나 계산 순서를 실수하면 버그가 발생한다.
반응형 프로그램은 외부 상태를 받아들이는 데에도 관대해서 하드웨어 클록을 변수로 받아들이는 등의 작업이 함수형 프로그램보다 쉬운 편이다. 함수형 프로그램은 함수가 자기 자신에 대해 항상 '''닫혀 있어야''' 하지만 반응형 프로그래밍 모델에는 그런 제약이 없다. 사실은 반응형 프로그래밍 모델에서의 함수는 함수형 프로그래밍처럼 자기 자신에 대해 닫혀 있지만 외부의 상태가 변하는 것까지 추적해서 자동 재계산을 수행한다.
단점은 언제 변할지 모르는 수많은 변수를 일일이 추적하다보니 컴퓨터 성능을 상당히 잡아먹는다는 것. 예를 들어 여러 개의 값이 한꺼번에 바뀔 때 명령형이나 함수형 모델에서는 세 값이 다 변할 때까지 기다렸다가 한 번 재계산하는 등의 융통성을 발휘할 수 있지만 반응형 모델은 하나 바뀔 때마다 재계산을 해 댄다. 이를 개선하기 위해 '''지연 평가''' 개념을 적극적으로 적용하고 있긴 하지만 그래도 실성능이 상당히 나쁘게 나오고 있다. 그래서 고속 처리가 요구되는 곳에서는 영 사용할 게 못되고 사용자의 입력에 반응하는 UI로직에나 사용할 만 하다. 물론 UI에만 사용하면 되는 문제이므로 게임 같은 고성능 소프트웨어를 개발할 때 이걸 못 쓰는 건 아니다. 사용자 입력을 처리하는 UI프론트엔드는 아무리 게임이라도 사람의 입력 속도는 컴퓨터 입장에서는 충분히 느리기 때문에 사용할 수 있다. 하지만 AI로직 같은데 사용하기에는 아직 성능상에 문제가 있다.
4.5. 특수 목적 언어
- SQL - 관계형 데이터베이스에서 데이터를 조작하기 위해 사용되는 표준 언어로 여러 DBMS에서 지원한다.
- CUDA - 엔비디아제 GPU를 제어하는 언어.
- Prolog - 인공지능 언어
- Processing - 그래픽스 처리를 위한 언어
- MATLAB - 공학용 시뮬레이션용 언어
- PHP - 웹 사이트를 만드는데 특화된 언어
- Verilog, VHDL - 디지털 하드웨어 설계를 위한 언어로, 반응형 프로그래밍에 속한다.
- Verilog-A - 아날로그 하드웨어 설계를 위한 언어
5. 회화 언어와의 관계
프로그래밍 언어는 '소프트웨어 개발'이라는 특수한 목적으로만 쓰이기에 회화 언어보다는 문법이 엄격하다는 점, 2인칭이 존재하지 않는다는 점[40] 등의 차이가 있지만, 그 외에는 회화 언어와 동등한 위치에 있다. 또한 데이터의 기술을 주요 목적으로 하는 마크업 언어와는 근본적으로 차이가 있지만, 둘 다 정보 처리에 쓰이기에 '기계를 위한 민족어'라는 점에서는 동일하다. 다시 말해, '''프로그래밍 언어와 회화 언어는 큰 차이가 없다'''고 단언할 수 있다. 굳이 차이를 따진다 해도 문법적 차이를 제외하고는 그렇게 드러나는 것도 없다.어떤 언어든지 한국말로 100% 번역할수 있어야 제대로 이해하는 것이다. 그게 인간의 언어이든 컴퓨터의 언어이든 말이다.
무슨 뜬금없는 소리인가 싶기도 하지만, 회화 언어와 프로그래밍 언어 사이의 유사성은 상당히 밀접하다. 단어를 소리 단위로 쪼개는 음운론은 프로그래밍 언어로 치면 토큰 구성 이론과 같으며, 문장을 단어 단위로 쪼개는 통사론은 프로그래밍 코드 형태로 쓰인 텍스트를 토큰 단위로 쪼개는 컴파일러 이론과 온전히 동일하다. 기계 번역도 사실 프로그래밍 쪽에서 컴파일러, 인터프리터 등의 형태로 이미 적용되어 있던 것이 회화 언어로 옮겨간 것 뿐이다. 애초에 프로그래밍 언어 역시 사람이 만들어서 쓰는 말이라는 점에서, 이런 공통점은 당연시 될 수 밖에 없다. 프로그래밍 언어의 문법 대다수는 수학 문법에서 왔는데, 수학 기호 또한 결국 사람이 만든 것이기 때문에 사람과의 대화가 가능하도록 만들어야 하기 때문.
게다가 언어만 익힌다고 끝나는 게 아니라 그것과 관련된 현지 문화, 법규 등을 익혀야 현지에서 원활하게 생활할 수 있듯, 프로그래밍 언어 역시 그 언어에 적용할 수 있는 방법론이나 개발 분야에서의 프로토콜 등을 지속적으로 이해해야 실무에서 살아남을 수 있다. 안 그래도 독학이 어려운 아랍어가 더더욱 어려울 수 밖에 없는 이유가 바로 문화 차이에서 비롯된 것이며, 많은 코더들이 실무경험에서 좌절하는 이유 역시 프로그래밍 언어와 관련된 문화(설계론, 프로토콜 등) 지식 부족에서 비롯된다. 그래서 번역가도 프로그래머도 모두 평생학습을 필요로 하는 직업이다.
실제로 초창기만 해도 존 폰 노이만 처럼 기계어를 외국어 구사하듯 구사하는 사람이 많았었고, 지금도 언어학과에서 프로그래밍 언어를 가르치기도 한다. 요즘이야 컴파일러 성능 등이 좋아져서 그런 걸 굳이 인지할 필요가 줄었다고는 하지만, 반대급부로 기계를 이해하지 못해 발적화를 한다거나 기본적인 디버그 조차 하지 않아 문제가 발생한 사례들을 보자면, 딱히 필요성이 줄었다 보기도 어렵다. 따라서 프로그램의 올바른 개발을 위해서는 결국 회화 언어 구사 능력도 좋은 개발자가 있어야 한다.
코더가 양산되는 이유를 이런 유사성에서 살펴보면 판타지 소설의 필수요소를 포함해 양판소가 비판받는 이유와 매우 유사하다. 다시 말해 프로그래밍은 소설작법과 유사한 측면이 있으며, 소설 작법이든 프로그래밍이든 경험이 실력을 좌지우지하는 일이 많다. 그렇기에 버그가 발생했다는 것은 오역했다는 말과 같다고 볼 수 있으며, 발적화는 회화상에서 아무 말 대잔치를 한 것과 동일하다 볼 수 있다. 그 예로, 특수 케이스를 생각하지 않은 버그는 뉘앙스를 감안하지 않은 오역으로, 의존 라이브러리의 오류는 사전의 오류 또는 문화 차이에서 발생한 오류로 볼 수 있다. MOTHER 2의 문사이드에서 나온 '예'와 '아니오'가 바뀐, 그래서 검은 닌텐도의 일환으로 평가받는 언어활용은 프로그래밍으로 치면 하드웨어 결함으로 발생한 버그와 매우 유사하다. 더욱 섬뜩한 예로, 잘못된 언어 활용으로 발생하는 갈등은 악성코드와 매우 유사하다.
더불어, 알 토네리코 시리즈의 휴므노스어나 Ciel nosurge의 REON-4213 처럼, 프로그래밍 언어와 회화 언어를 접목하는 시도도 있었으며, 로지반 역시 비슷한 노력의 산물이다. 모두 프로그래밍 언어를 회화 언어와 동일하게 놓고 봐야 가능한 것들이다.
6. 프로그래밍 앱
-마이크로소프트 비주얼스튜디오 비주얼 스튜디오 https://visualstudio.microsoft.com/ko/
-파이썬 파이썬 https://www.python.org/
-자바 자바 https://www.oracle.com/java/technologies/
-node.js Node.js https://nodejs.org/en/
-서브라임 텍스트 서브라임 텍스트 https://www.sublimetext.com/
-비주얼스튜디오는 C++, C, C#, visual basic, python, Javascript, F#, TypeScript 등 여러가지 언어를 지원한다.
-node.js는 Javascript를 지원한다.
-서브라임 텍스트는 python용이지만 텍스트 편집기로써 다른 언어의 코드를 작성해서 다른 프로그램으로 복사해서 사용할 수는 있다.
7. 목록
8. 나무위키에 등재된 문법 관련 문서
9. 나무위키에 등재된 프로그래밍 예제
10. 기타
- 난해한 프로그래밍 언어
- 여기서 프로그래밍 언어 인기 순위를 볼 수 있다. 2018년 10월 기준 Python가 1위, Java이 2위, JavaScript가 3위이다.
10.1. 한글 프로그래밍 언어
한국어로 이루어진 프로그래밍 언어에 관한 다양한 관련 정보를 참조 바랍니다.
[1] 괴델이 고안한 primitive recursive function에서는 termination이 가정되어 있다. 즉, 무한 루프와 같은 것이 불가능하다(!). 이는 불완전성 정리에서(그리고 실제 오늘날 수학에서) 모든 증명이 유한한 길이를 갖는 것을 가정하고 있기 때문이다. primitive recursive function에 mu-operator(말 그대로 최소값을 찾아주는 operator이다.)를 더하면 class of recursive functions로 진화하여 무한루프 등의 알고리즘을 다 표현할 수 있다.[2] 오늘날 C나 자바등의 언어에 익숙한 사람들은 이 While-programming이 가장 친숙하게 느껴질 것이다.[3] S, K, I 3개의 함수로 이루어진 언어이다. 튜링-완전 이기 때문에 다른 체제와 마찬가지로 모든 알고리즘을 표현하는 것이 가능하며, I는 S와 K로부터 연역되기 때문에 사실상 함수 2개로 이루어진 가장 간단한 수학적 프로그래밍 언어라 할 수 있다.[4] 증명이 아니기 때문에 theorem 같은 것이 아닌 thesis가 붙는다.[5] 이 사람은 '''수백년을 앞서나간''' 무진장 흠좀무한 인간이다. 당시 기술력만 되었다면 그 시절에 이미 컴퓨터라는 것을 만들었을지도 모른다.[6] 또는 간단하게 이름(name)이라고도 부른다.[7] 특수어(special word)라고도 부른다.[8] Sulong을 통해 JVM 바이트코드로 컴파일되어 JVM에서 실행되던지, Emscripten 등으로 WASM으로 컴파일되어 자바스크립트 VM에서 실행된다[9] 안드로이드의 ART, 또는 SubstrateVM을 통해 AOT 컴파일된다[10] ocamlc와 ocamlopt[11] Erlang과 Erlang HiPE[12] 이 때문에 Native Language라고 불리기도 한다.[13] 대표적인 VM 구현체: HotSpot, OpenJ9[14] 대표적인 VM 구현체: V8, SpiderMonkey[15] 대표적인 VM 구현체: .NET, Mono[16] 실행 시간에 프로그램 자체에 대한 정보를 얻거나 수정하는 것을 뜻함[17] 대표적인 VM 구현체: CPython, Jython, PyPy 등[18] 대표적인 VM 구현체: MRI, JRuby[19] 대표적인 VM 구현체: Zend VM, HHVM[20] 정확히는 TypeScript로 개발하고 별도의 컴파일을 통해 JavaScript로 변환된 코드를 배포하게 되는 케이스. '''컴파일'''이라는 용어를 보면 알겠지만 위의 '해석 방식에 따른 분류' 문단을 모호하게 만드는 예시 중 하나다.[21] 가령 JavaScript로 진행하는 프로젝트 VS TypeScript로 진행하는 프로젝트. 전자의 경우는 값비싼 개발 도구를 사다 쓰는 거랑 그냥 메모장으로 코딩하는 게 사실상 별 차이가 없을 지경으로 답이 없는 개발 환경이다. 물론 무료 개발 도구에서 제공하는 기능들도 TypeScript 쪽이 압도적으로 풍부하다. 이 문단에서도 언급했듯 JavaScript는 뭘 지원해줄래야 할 수가 없는 구조이기 때문.[22] Procedural Language.[23] 참고로 모든 프로그램은 순서대로 진행되어야 하기에 해당 프로그램을 만들었을 '모든 프로그래밍 언어는 절차적이다' 라고 말할 수 있다.[24] 속사정은 상관없이 결과만 나오면 된다.[25] 각자 따로 자생하며 논다.[26] 파생 상품을 비교적 쉽게 만들 수 있다.[27] C의 #define을 상상하면 된다. scope 안에서 '='로 정의된 변수들은 아무생각없이 우항으로 대체하는것이 가능하다. 명령형 언어에서는 다시 대입되어 수정될 수 있기 때문에 불가능하다.[28] 하위 scope 에서 덮어쓰기는 가능하다. 함수형 언어에서는 이것을 shadow 라 표현한다. 명령형 언어에서는 포인터 등을 이용하여 하위 scope 에서 아예 상위 scope 변수 자체의 값을 바꿔버리는것도 가능하지만, 함수형 언어에서는 하위 scope 에서 shadow 된 값은 해당 scope 바깥에 절대 영향이 없다.[29] 물론, 물론, 언어 내의 Boolean type 의 false 가 아닌, 컴퓨팅 모델 자체의 false 값을 의미한다.[30] '''Memoization'''. Memo'''r'''ization이 아닌 것에 주의![31] 이를 동적 계획법(Dynamic Programming)이라고 한다.[32] 메세지 전달 모델은 명령형에서도 똑같이 쓸 수 있다.[33] 다른 데이터와 똑같은 취급을 받는다는 뜻. 대조적으로 자바의 메소드나 C의 함수를 생각해보자. 자바에서 인자로 메소드를 주거나 리턴받는것은 불가능하고, C에서도 포인터가 아니라 함수 자체를 넘겨주는건 불가능하다. 또한 이 개념은 언어 내장 데이터타입(Primitive)와는 다르다. 파이썬같이 분명히 함수형이 아닌 언어에서도 사용하는 경우는 있다.[34] 심지어 하스켈 같은 경우 너무 간결해서 오히려 이해하기가 어려운 것 같다는 불평이 나오기도 할 정도[35] 한번 정의한 변수의 값을 차후에 다른 값으로 업데이트 하는것.[36] 자료구조를 업데이트 할때마다 계속 새로 자료구조를 만드는 모델. 순수 함수형 언어의 경우 한번 정의한 값을 바꿀수가 없어서 이게 선택이 아닌 필연이 된다. fully persistent data structure 에서는 심지어 이전버전의 자료에도 접근할 수 있다.[37] 메시지(생산물)를 통해 메시지를 전달하고, 객체 내부의 변수에 대한 직접 접근을 막는다.[38] 그나마 Scala가 Java의 보조 언어로 쓰이고 있는 정도다.[39] 수학적으로, 함수는 관계의 부분집합이다.[40] 객체지향 언어에는 '1인칭'에 해당하는 키워드(this, me 등)가 존재한다. 하지만 '2인칭'은 존재하지 않기에 어쩔 수 없이 자기 객체를 파라미터로 넘기거나 이벤트에 물리는 식으로 자기 객체를 '3인칭화' 시켜야 한다.