Page protected with pending changes

프로그래밍 언어

Programming language

프로그래밍 언어컴퓨터 프로그램을 작성하기 위한 표기 체계입니다.[1]

C 프로그래밍 언어로 작성된 간단한 컴퓨터 프로그램의 소스 코드. 회색 선은 자연어로 인간에게 프로그램을 설명하는 데 도움이 되는 코멘트입니다. 컴파일하여 실행하면 "Hello, world!"라는 출력이 나옵니다.

프로그래밍 언어는 일반적으로 구문(형식) 및 의미론(의미) 측면에서 설명됩니다. 이것들은 일반적으로 공식 언어로 정의됩니다.[citation needed]

언어는 일반적으로 컴파일러 또는 인터프리터 형태로 구현되어 언어로 작성된 프로그램을 실행할 수 있습니다.

프로그래밍 언어 이론은 프로그래밍 언어의 설계, 구현, 분석, 특성화 및 분류를 연구하는 컴퓨터 과학의 하위 분야입니다.

정의들

프로그래밍 언어를 구성하는 것을 정의할 때 여러 가지 고려 사항이 있습니다.

컴퓨터 언어 vs 프로그래밍 언어

컴퓨터 언어라는 용어는 프로그래밍 언어와 혼용되어 사용되기도 합니다.[2] 그러나 두 용어의 사용은 각각의 정확한 범위를 포함하여 저자마다 다릅니다. 하나의 용법은 프로그래밍 언어를 컴퓨터 언어의 하위 집합으로 설명합니다.[3] 마찬가지로 컴퓨터 프로그램을 표현하는 것과는 다른 목표를 가진 컴퓨팅에 사용되는 언어는 일반적으로 컴퓨터 언어로 지정됩니다. 예를 들어 마크업 언어는 프로그래밍에 사용할 목적이 아님을 강조하기 위해 컴퓨터 언어로 불리기도 합니다.[4] 컴퓨터 언어를 분류하는 한 가지 방법은 계산 이론에 의해 설명된 바와 같이 표현할 수 있는 계산에 의한 것입니다. 대부분의 실용적인 프로그래밍 언어는 튜링 완전체이며,[5] 모든 튜링 완전체 언어는 동일한 알고리즘 집합을 구현할 수 있습니다. ANSI/ISO SQL-92와 채리티는 튜링이 완전하지 않은 언어의 예이지만 종종 프로그래밍 언어라고 불립니다.[6][7] 그러나 일부 저자는 "프로그래밍 언어"라는 용어를 튜링 완전 언어로 제한합니다.[1][8]

또 다른 용도는 프로그래밍 언어를 추상적 기계를 프로그래밍하기 위한 이론적 구성으로 간주하고 컴퓨터 언어를 유한 하드웨어 자원을 가진 물리적 컴퓨터에서 실행되는 하위 집합으로 간주합니다.[9] 존 C. 레이놀즈공식 사양 언어는 실행을 위해 의도된 언어만큼 프로그래밍 언어라고 강조합니다. 그는 또한 컴퓨터의 동작에 영향을 미치는 텍스트 및 그래픽 입력 형식이 일반적으로 튜링 완전하지 않음에도 불구하고 프로그래밍 언어이며 프로그래밍 언어 개념에 대한 무지가 입력 형식의 많은 결함의 이유라고 주장합니다.[10]

도메인 및 대상

대부분의 실제적인 맥락에서 프로그래밍 언어는 컴퓨터를 포함합니다. 결과적으로 프로그래밍 언어는 일반적으로 이러한 방식으로 정의되고 연구됩니다.[11] 프로그래밍 언어는 자연어와 달리 자연어는 사람 간의 상호 작용에만 사용되는 반면, 프로그래밍 언어는 사람이 기계에 명령어를 전달할 수 있도록 해줍니다.

언어의 영역도 고려할 가치가 있습니다. 구조화된 데이터를 정의하는 XML, HTML 또는 트로프와 같은 마크업 언어는 일반적으로 프로그래밍 언어로 간주되지 않습니다.[12][13][14] 그러나 컴퓨터 시맨틱스가 정의된 경우 프로그래밍 언어는 마크업 언어와 구문을 공유할 수 있습니다. 예를 들어, XSLT는 전적으로 XML 구문을 사용하는 튜링 완전 언어입니다.[15][16][17] 또한 문서를 구조화하는 데 주로 사용되는 LaTeX에는 튜링 완전한 하위 집합도 포함되어 있습니다.[18][19]

추상화

프로그래밍 언어는 일반적으로 데이터 구조를 정의하고 조작하거나 실행 흐름을 제어하기 위한 추상화를 포함합니다. 프로그래밍 언어가 적절한 추상화를 지원해야 한다는 현실적 필요성은 추상화 원리에 의해 표현됩니다.[20] 이 원리는 때때로 프로그래머에게 그러한 추상화를 적절하게 사용하라는 권장 사항으로 공식화됩니다.[21]

역사

초기 개발

Collosus와 같은 초기 컴퓨터는 저장된 프로그램의 도움 없이 회로를 수정하거나 물리적 제어 뱅크를 설정하여 프로그래밍되었습니다.

조금 후에 프로그램은 기계어로 작성될 수 있으며, 여기서 프로그래머는 하드웨어가 직접 실행할 수 있는 숫자 형태로 각 명령어를 작성합니다. 예를 들어, 두 개의 메모리 위치에 값을 추가하는 명령어는 "추가" 작업을 선택하는 "opcode"와 두 개의 메모리 위치의 세 가지 숫자로 구성될 수 있습니다. 프로그램은 10진수 또는 2진수 형태로 천공된 카드, 종이 테이프, 자기 테이프에서 읽히거나 컴퓨터 전면 패널의 스위치에서 토글로 전환되었습니다. 기계 언어는 나중에 1세대 프로그래밍 언어(1GL)라고 불리게 되었습니다.

그 다음 단계는 이른바 2세대 프로그래밍 언어(2GL) 또는 어셈블리 언어의 개발로, 여전히 특정 컴퓨터의 명령 집합 아키텍처와 밀접하게 연결되어 있었습니다. 이것들은 프로그램을 훨씬 더 사람이 읽을 수 있게 만들고 프로그래머가 지루하고 오류가 발생하기 쉬운 주소 계산을 덜어주는 역할을 했습니다.

최초의 고급 프로그래밍 언어, 또는 3세대 프로그래밍 언어(3GL)는 1950년대에 작성되었습니다. 컴퓨터용으로 설계된 초기 고급 프로그래밍 언어는 1943년에서 1945년 사이에 콘라트 주세에 의해 독일 Z3용으로 개발된 플랭크쿨(Plankalkül)입니다. 그러나 1998년과 2000년까지는 시행되지 않았습니다.[22]

1949년에 제안된 존 모츨리짧은 코드전자 컴퓨터를 위해 개발된 최초의 고급 언어 중 하나였습니다.[23] 기계 코드와 달리 쇼트 코드 문은 수학적 표현을 이해할 수 있는 형태로 표현했습니다. 그러나 프로그램이 실행될 때마다 기계 코드로 번역되어야 했기 때문에 동등한 기계 코드를 실행하는 것보다 프로세스가 훨씬 느렸습니다.

맨체스터 대학에서, 앨릭 글렌니는 1950년대 에 오토코드를 개발했습니다. 프로그래밍 언어로서 컴파일러를 사용하여 언어를 자동으로 기계 코드로 변환했습니다. 최초의 코드 및 컴파일러는 1952년 맨체스터 대학의 Mark 1 컴퓨터용으로 개발되었으며, 최초로 컴파일된 고급 프로그래밍 언어로 간주됩니다.[24][25]

두 번째 오토 코드는 1954년 R. A. Brooker에 의해 Mark 1용으로 개발되었으며 "Mark 1 Autocode"라고 불렸습니다. 브루커는 또한 1950년대에 맨체스터 대학과 함께 페란티 머큐리를 위한 자동차 코드를 개발했습니다. EDSAC 2의 버전은 D에 의해 고안되었습니다. 1961년 캠브리지 대학 수학 연구소 F. 하틀리. EDSAC 2 Autocode로 알려진 이 제품은 Mercury Autocode에서 현지 상황에 맞게 개발된 것으로, 당시 발전된 객체 코드 최적화 및 소스 언어 진단으로 유명했습니다. 현대적이지만 별개의 개발 스레드인 Atlas Autocode는 맨체스터 대학교 Atlas 1 기계를 위해 개발되었습니다.

1954년배커스에 의해 IBM에서 포트란이 발명되었습니다. 이것은 단지 종이 위의 디자인이 아니라 기능적인 구현을 가진 최초의 널리 사용되는 고급 범용 프로그래밍 언어였습니다.[26][27] 여전히 고성능 컴퓨팅으로[28] 인기 있는 언어이며 세계에서 가장 빠른 슈퍼컴퓨터를 벤치마킹하고 순위를 매기는 프로그램에 사용됩니다.[29]

FLOW-MATIC이라고 불리는 또 다른 초기 프로그래밍 언어는 미국의 Grace Hopper에 의해 고안되었습니다. 1955년부터 1959년까지 레밍턴 랜드UNIVAC I을 위해 개발되었습니다. Hopper는 비즈니스 데이터 처리 고객들이 수학적 표기법에 불편함을 느낀다는 것을 발견했고, 1955년 초에 그녀와 그녀의 은 영어 프로그래밍 언어에 대한 사양을 작성하고 시제품을 구현했습니다.[30] FLOW-MATIC 컴파일러는 1958년 초에 공개되었으며 1959년에 실질적으로 완성되었습니다.[31] FLOW-MATIC은 코볼의 설계에 큰 영향을 미쳤는데, 당시에는 그것과 그것의 직계 후손인 AIMACO만이 실제 사용되었기 때문입니다.[32]

정교화

고급 언어의 사용 증가는 저급 프로그래밍 언어 또는 시스템 프로그래밍 언어에 대한 요구 사항을 도입했습니다. 이러한 언어는 정도에 따라 어셈블리 언어와 고급 언어 간의 기능을 제공합니다. 하드웨어 설비에 직접 액세스해야 하지만 더 높은 수준의 제어 구조와 오류 검사를 제공하는 작업을 수행하는 데 사용할 수 있습니다.

1960년대부터 1970년대 후반까지의 기간은 현재 사용되고 있는 주요 언어 패러다임의 발전을 가져왔습니다.

  • APL배열 프로그래밍을 도입하고 기능 프로그래밍에 영향을 미쳤습니다.[33]
  • ALGOL구조화된 절차 프로그래밍언어 사양 분야를 모두 개선했습니다. "알고리즘 언어 ALGOL 60에 대한 수정 보고서"는 나중에 언어 사양이 어떻게 작성되었는지에 대한 모델이 되었습니다.
  • 1958년에 구현된 리스프는 동적으로 유형화된 최초의 기능적 프로그래밍 언어였습니다.
  • 1960년대에 Simula는 객체 지향 프로그래밍을 지원하도록 설계된 최초의 언어였고, 1970년대 중반에 Smalltalk는 최초의 "순수하게" 객체 지향 언어로 그 뒤를 이었습니다.
  • C는 1969년에서 1973년 사이에 유닉스 운영 체제를 위한 시스템 프로그래밍 언어로 개발되었으며 현재까지도 대중적으로 사용되고 있습니다.[34]
  • 1972년에 설계된 프롤로그는 최초의 논리 프로그래밍 언어였습니다.
  • 1978년 ML리스프 위에 다형성형 시스템을 구축하여 정적으로 유형화된 기능적 프로그래밍 언어를 개척했습니다.

이 언어들은 각각 후손을 낳았고, 대부분의 현대 프로그래밍 언어들은 그들의 조상 중 적어도 하나를 세고 있습니다.

1960년대와 1970년대는 또한 구조화된 프로그래밍의 장점과 이를 지원하기 위해 프로그래밍 언어가 설계되어야 하는지에 대한 상당한 논쟁을 겪었습니다.[35] 1968년 ACM 커뮤니케이션즈에 발표된 유명한 편지에서 에드거 다이크스트라는 모든 "고급" 프로그래밍 언어에서 고토 문을 제거해야 한다고 주장했습니다.[36]

통합 및 성장

프로그래밍 언어 교재 소수 선택

1980년대는 상대적으로 통합된 해였습니다. C++ 결합 객체 지향 및 시스템 프로그래밍. 미국 정부는 Pascal에서 파생되어 방위산업체가 사용하기 위한 시스템 프로그래밍 언어인 Ada를 표준화했습니다. 일본 등에서는 논리 프로그래밍 구조를 통합한 이른바 "5세대" 언어를 조사하는 데 막대한 비용이 투입되었습니다.[37] ML과 리스프를 표준화하기 위해 기능 언어 커뮤니티가 움직였습니다. 이 모든 운동들은 새로운 패러다임을 발명하기 보다는 지난 수십 년 동안 발명된 아이디어를 정교화했습니다.

1980년대에 대규모 시스템을 프로그래밍하기 위한 언어 설계의 중요한 경향 중 하나는 모듈 또는 대규모 코드 조직 단위의 사용에 대한 증가된 초점이었습니다. Modula-2, Ada, ML 모두 1980년대에 주목할 만한 모듈 시스템을 개발했으며, 이는 종종 일반적인 프로그래밍 구조와 결합되었습니다.[38]

1990년대 중반 인터넷의 급속한 성장은 새로운 언어의 기회를 만들었습니다. 원래 1987년에 처음 출시된 유닉스 스크립팅 도구인 펄은 동적 웹사이트에서 일반화되었습니다. 자바는 서버측 프로그래밍에 사용되기 시작했고, 바이트코드 가상 머신은 "한 번 쓰고, 아무데나 실행하라"는 약속과 함께 상업 환경에서 다시 인기를 끌게 되었습니다. (UCSD Pascal은 1980년대 초 한때 인기가 있었습니다.) 이러한 발전은 근본적으로 새로운 것이 아니라 기존의 많은 언어와 패러다임을 개선한 것이었습니다. (그들의 구문은 종종 프로그래밍 언어의 C 계열에 기반을 두었지만).

프로그래밍 언어의 진화는 산업과 연구 모두에서 계속되고 있습니다. 현재의 방향은 보안 및 신뢰성 검증, 새로운 종류의 모듈화(믹스, 대표단, 양상), 마이크로소프트의 LINQ와 같은 데이터베이스 통합 등입니다.

4세대 프로그래밍 언어(4GL)는 3GL보다 더 높은 수준의 내부 컴퓨터 하드웨어 세부 사항의 추상화를 제공하는 것을 목표로 하는 컴퓨터 프로그래밍 언어입니다. 5세대 프로그래밍 언어(5GL)는 프로그래머가 작성한 알고리즘을 사용하는 것이 아니라 프로그램에 주어진 제약조건을 이용하여 문제를 해결하는 것을 기반으로 하는 프로그래밍 언어입니다.

요소들

모든 프로그래밍 언어에는 데이터 설명과 적용되는 프로세스 또는 변환을 위한 기본 구성 요소가 있습니다(두 개의 숫자를 추가하거나 컬렉션에서 항목을 선택하는 것과 같은). 이러한 프리미티브는 구조와 의미를 각각 설명하는 통사적 규칙과 의미적 규칙에 의해 정의됩니다.

구문

토큰화를 삽입한 Python 코드구문 분석 트리
구문 강조 표시는 프로그래머가 소스 코드의 요소를 인식하는 데 도움을 주기 위해 자주 사용됩니다. 위의 언어는 파이썬입니다.

프로그래밍 언어의 표면 형태를 구문이라고 합니다. 대부분의 프로그래밍 언어는 순수하게 텍스트입니다. 그것들은 쓰여진 자연 언어와 마찬가지로 단어, 숫자, 구두점을 포함한 텍스트 시퀀스를 사용합니다. 반면 일부 프로그래밍 언어는 프로그램을 지정하기 위해 기호 간의 시각적 관계를 사용하여 본질적으로 더 그래픽적입니다.

언어의 구문은 구문적으로 올바른 프로그램을 구성하는 기호의 가능한 조합을 설명합니다. 기호들의 조합에 주어진 의미는 (참고 구현에서 형식적이거나 하드 코딩된) 의미론에 의해 처리됩니다. 대부분의 언어는 텍스트이므로 이 글에서는 텍스트 구문에 대해 논의합니다.

프로그래밍 언어 구문은 일반적으로 정규 표현식( 어휘 구조용)과 백커스-나우어 형식(문법 구조용)의 조합을 사용하여 정의됩니다. 아래는 리스프에 기초한 간단한 문법입니다.

식 ::= 원자 목록 원자 ::= 숫자 기호 번호 ::= [+-]?['0'-9']+ 기호 ::= ['A'-Z'a'-z'].* list ::= '('식*')' 

이 문법은 다음을 지정합니다.

  • 식은 원자 또는 목록입니다.
  • 원자숫자 또는 기호입니다.
  • 숫자는 하나 이상의 10진수로 이루어진 끊기지 않은 순서이며, 선택적으로 플러스 기호 또는 마이너스 기호가 뒤에 오는 것입니다.
  • 기호는 문자 뒤에 0 또는 그 이상의 문자(백자는 제외)가 오는 문자입니다.
  • 목록은 괄호 안에 0개 이상의 식이 있는 일치된 쌍입니다.

이 문법에서 잘 형성된 토큰 시퀀스의 예는 다음과 같습니다. 12345, () 그리고. (a b c232 (1)).

모든 구문론적으로 올바른 프로그램이 의미론적으로 올바른 것은 아닙니다. 그럼에도 불구하고 많은 구문론적으로 올바른 프로그램은 언어의 규칙에 따라 제대로 형성되지 않으며, (언어 사양 및 구현의 건전성에 따라) 번역 또는 실행에 오류가 발생할 수 있습니다. 경우에 따라 이러한 프로그램은 정의되지 않은 동작을 나타낼 수 있습니다. 한 언어 내에서 프로그램이 잘 정의되어 있을 때에도 프로그램을 작성한 사람이 의도하지 않은 의미를 가질 수 있습니다.

자연어를 예로 들면, 문법적으로 정확한 문장에 의미를 부여할 수 없거나 문장이 거짓일 수 있습니다.

  • "무채색의 녹색 아이디어는 격렬하게 잠을 잔다."는 문법적으로는 잘 형성되어 있지만 일반적으로 받아들여지는 의미는 없습니다.
  • "존은 결혼한 총각입니다."는 문법적으로는 형성되어 있지만, 사실일 수 없는 의미를 표현합니다.

다음 C 언어 조각은 구문론적으로 정확하지만 의미론적으로 정의되지 않은 연산을 수행합니다(연산). *p >> 4 복잡한 유형을 가진 값에는 의미가 없습니다. p->im 값이 정의되어 있지 않습니다. p null 포인터):

복잡한 *p = NULL; 복잡한 abs_p = sqrt(*p >> 4 + p->); 

첫 번째 줄의 형식 선언이 생략된 경우, 프로그램은 정의되지 않은 변수에 오류를 트리거할 것입니다. p 편찬 중에 그러나 유형 선언은 의미론적 정보만 제공하기 때문에 프로그램은 구문론적으로 여전히 정확할 것입니다.

프로그래밍 언어를 지정하는 데 필요한 문법은 촘스키 계층에서의 위치에 따라 분류할 수 있습니다. 대부분의 프로그래밍 언어의 구문은 Type-2 문법을 사용하여 지정할 수 있습니다. 즉, 컨텍스트가 없는 문법입니다.[39] Perl과 Lisp를 포함한 일부 언어에는 구문 분석 단계에서 실행할 수 있는 구문이 포함되어 있습니다. 프로그래머가 구문 분석기의 동작을 변경할 수 있는 구조를 가진 언어는 구문 분석을 결정할 수 없는 문제로 만들고 일반적으로 구문 분석과 실행의 구별을 흐립니다.[40] 리스프의 매크로 시스템과 펄의 매크로 시스템과는 대조적으로 BEGIN 일반적인 계산을 포함할 수 있는 블록, C 매크로는 단지 문자열을 대체하는 것일 뿐 코드 실행을 필요로 하지 않습니다.[41]

의미론

의미론이라는 용어는 언어의 형태(합성법)와는 반대로 언어의 의미를 나타냅니다.

정적 의미론

정적 의미론은 표준 구문 형식론에서 표현하기 어렵거나 불가능한 유효한 텍스트 구조에 대한 제한을 정의합니다.[1][failed verification] 컴파일된 언어의 경우 정적 의미론에는 컴파일 시 확인할 수 있는 의미 규칙이 기본적으로 포함됩니다. 예를 들어 모든 식별자가 사용되기 전에(이러한 선언이 필요한 언어로) 선언되었는지 또는 사례 설명의 팔에 있는 레이블이 구별되는지 확인하는 것이 포함됩니다.[42] 식별자가 적절한 컨텍스트에서 사용되는지 확인하거나(예: 함수 이름에 정수를 추가하지 않음), 서브루틴 호출이 적절한 수의 인수와 유형을 가지는지 확인하는 것과 같은 이러한 유형의 많은 중요한 제한은 유형 시스템이라논리에서 규칙으로 정의함으로써 시행될 수 있습니다. 데이터 흐름 분석과 같은 다른 형태의 정적 분석도 정적 의미론의 일부일 수 있습니다. JavaC#과 같은 프로그래밍 언어는 각각의 정적 의미론의 일부로 데이터 흐름 분석의 한 형태인 명확한 할당 분석을 가지고 있습니다.

동역학적 의미론

데이터가 지정되면 기계에 데이터에 대한 작업을 수행하도록 지시해야 합니다. 예를 들어, 시맨틱스는 식을 값으로 평가하는 전략 또는 제어 구조가 조건부로 을 실행하는 방식을 정의할 수 있습니다. 언어의 동적 의미론(실행 의미론이라고도 함)은 언어의 다양한 구성 요소가 프로그램 동작을 생성하는 방법과 시기를 정의합니다. 실행 시맨틱스를 정의하는 방법은 여러 가지가 있습니다. 자연어는 실무에서 일반적으로 사용되는 언어의 실행 의미를 지정하는 데 자주 사용됩니다. 상당한 양의 학술 연구가 프로그래밍 언어의 형식적 의미론에 적용되며, 이를 통해 실행 의미론을 형식적으로 지정할 수 있습니다. 이 연구 분야의 결과는 프로그래밍 언어 설계 및 학계 외부 구현에 제한적으로 적용되었습니다.

유형체계

유형 시스템은 프로그래밍 언어가 값과 표현을 유형으로 분류하는 방법, 해당 유형을 조작할 수 있는 방법 및 상호 작용 방식을 정의합니다. 유형 시스템의 목표는 특정 오동작을 탐지하여 해당 언어로 작성된 프로그램에서 특정 수준의 정확성을 확인하고 일반적으로 적용하는 것입니다. 모든 결정적인 유형의 시스템은 트레이드오프를 수반합니다. 많은 잘못된 프로그램을 거부하지만, 비록 특이하지만 일부 올바른 프로그램을 금지할 수도 있습니다. 이러한 단점을 피하기 위해 여러 언어에는 유형 허점이 있으며 일반적으로 다른 유형 간에 일반적으로 허용되지 않는 작업을 허용하기 위해 프로그래머가 사용할 수 있는 선택되지 않은 캐스트가 있습니다. 대부분의 입력 언어에서 유형 시스템은 검사 프로그램을 입력하는 데만 사용되지만, 일반적으로 기능적인 언어인 다수의 언어가 유형을 추론하여 프로그래머가 유형 주석을 작성할 필요를 덜어줍니다. 유형 시스템의 형식적 설계 및 연구는 유형 이론으로 알려져 있습니다.

입력된 언어와 입력되지 않은 언어

모든 작업의 사양이 작업에 적용할 수 있는 데이터 유형을 정의하는 경우 언어가 입력됩니다.[43] 예를 들어 다음과 같은 데이터가 표시됩니다. "this text between the quotes" 는 문자열이며 많은 프로그래밍 언어에서 숫자를 문자열로 나누는 것은 의미가 없으며 실행되지 않습니다. 프로그램이 컴파일되면("static" type checking") 유효하지 않은 작업이 감지되고 컴파일 오류 메시지와 함께 컴파일러에 의해 거부되거나 프로그램이 실행되는 동안("dynamic" type checking") 프로그램이 감지되어 런타임 예외가 발생할 수 있습니다. 많은 언어에서 예외 처리기라는 함수가 이 예외를 처리할 수 있도록 허용하며, 예를 들어 항상 결과적으로 "-1"을 반환합니다.

입력 언어의 특별한 경우는 단일 입력 언어입니다. 이러한 언어들은 REXX나 SGML과 같은 스크립팅 또는 마크업 언어이며, 하나의 데이터 유형[dubious ](가장 일반적으로 기호 및 숫자 데이터 모두에 사용되는 문자열)만 있습니다.

대조적으로, 대부분어셈블리 언어와 같은 유형화되지 않은 언어는 모든 데이터, 일반적으로 다양한 길이의 비트 시퀀스에 대해 모든 작업을 수행할 수 있습니다.[43] 상위 수준의 비형식 언어에는 BCPL, Tcl 및 일부 Four의 변종이 포함됩니다.

실제로 유형 이론에서 유형화된 것으로 간주되는 언어는 거의 없지만(모든 연산을 검증하거나 거부하는), 대부분의 현대 언어는 어느 정도의 유형화를 제공합니다.[43] 많은 프로덕션 언어는 유형 시스템을 우회하거나 전복할 수 있는 수단을 제공하며, 트레이딩 유형 안전은 프로그램 실행을 보다 세밀하게 제어할 수 있습니다(캐스팅 참조).

정적 vis-a-vis 동적 타이핑

정적 타이핑에서 모든 식은 프로그램이 실행되기 전(일반적으로 컴파일 시)에 유형이 결정됩니다. 예를 들어 1과 (2+2)는 정수 표현식으로 문자열을 기대하는 함수에 전달하거나 날짜를 보유하도록 정의된 변수에 저장할 수 없습니다.[43]

정적으로 입력된 언어는 명시적으로 입력하거나 유형을 추론할 수 있습니다. 첫 번째 경우에는 프로그래머가 특정 텍스트 위치(예: 변수 선언)에서 유형을 명시적으로 작성해야 합니다. 두 번째 경우, 컴파일러는 문맥에 따라 표현 및 선언의 유형을 추론합니다. C++, C#, Java와 같은 대부분의 메인스트림 정적 유형 언어는 명백하게 유형화됩니다. 완전한 유형 추론은 전통적으로 Haskell이나 ML과 같은 기능 언어와 관련이 있습니다.[44] 그러나 많은 명백한 유형 언어는 부분 유형 추론을 지원합니다. 를 들어 C++, JavaC#은 모두 특정 제한된 경우에 유형을 추론합니다.[45] 또한 일부 프로그래밍 언어에서는 일부 유형을 다른 유형으로 자동 변환할 수 있습니다. 예를 들어, 프로그램이 플로팅을 예상하는 곳에서 int를 사용할 수 있습니다.

잠재적 타이핑이라고도 불리는 동적 타이핑은 실행 시간에 작업의 유형 안전성을 결정합니다. 즉, 유형은 텍스트 표현아닌 실행 시간 값과 연관됩니다.[43] 유형 추론 언어와 마찬가지로 동적 유형 언어도 프로그래머가 식에 명시적 유형 주석을 작성할 필요가 없습니다. 무엇보다도 이를 통해 단일 변수가 프로그램 실행의 다른 지점에서 다른 유형의 값을 참조할 수 있습니다. 그러나 코드 조각이 실제로 실행될 때까지 유형 오류를 자동으로 감지할 수 없으므로 디버깅이 더 어려워질 수 있습니다. 리스프, 스몰토크, , 파이썬, 자바스크립트, 루비는 모두 동적으로 유형화된 언어의 예입니다.

약하고 강한 타이핑

약한 타이핑을 사용하면 문자열을 숫자로 처리하는 등 한 유형의 값을 다른 유형으로 처리할 수 있습니다.[43] 이 기능은 때때로 유용할 수 있지만 컴파일 시간이나 실행 시간에 프로그램 오류가 탐지되지 않을 수도 있습니다.

강력한 타이핑은 이러한 프로그램 오류를 방지합니다. 잘못된 유형의 값에 대해 작업을 수행하려고 하면 오류가 발생합니다.[43] 강한 유형의 언어는 종종 유형 안전 또는 안전이라고 불립니다.

"약하게 타이핑된"에 대한 대안적인 정의는 많은 수의 암시적 유형 변환을 허용하는 자바스크립트와 같은 언어를 말합니다. 예를 들어 자바스크립트에서는 다음과 같은 표현이 있습니다. 2 * x 은연중에 전환하는 x 숫자로, 그리고 이 변환은 성공적입니다. x 아. null, undefined, 한 사람 Array, 아니면 편지 줄이. 이러한 암묵적 변환은 종종 유용하지만 프로그래밍 오류를 가릴 수 있습니다. 정적은 현재 일반적으로 직교 개념으로 간주되지만 문헌에서의 용법은 다릅니다. 어떤 사람들은 강하게, 정적으로 입력된 것을 의미하기 위해 강하게 입력된 용어를 사용하거나, 혼란스럽게, 단순히 정적으로 입력된 것을 의미하기 위해 사용합니다. 따라서 C는 강하게 타이핑된 것과 약하게 정적으로 타이핑된 것 모두라고 불립니다.[46][47]

일부 전문 프로그래머들에게는 C가 "약하고 정적으로 타이핑될 수 있다"는 것이 이상해 보일 수 있습니다. 그러나 일반 포인터인 void* 포인터를 사용하면 명시적인 캐스트를 수행할 필요 없이 다른 포인터에 대한 캐스트 포인터를 허용할 수 있습니다. 이것은 다음과 같은 명시적인 캐스트를 사용하지 않고 C의 어떤 종류의 데이터 유형에도 바이트 배열을 캐스트하는 것과 매우 유사합니다. (int) 아니면 (char).

표준 라이브러리 및 런타임 시스템

대부분의 프로그래밍 언어에는 관련 핵심 라이브러리(특히 공개된 언어 표준의 일부로 포함되는 경우 표준 라이브러리)가 있습니다. 코어 라이브러리는 일반적으로 일반적으로 사용되는 알고리즘, 데이터 구조 및 입력 및 출력 메커니즘에 대한 정의를 포함합니다.

언어와 핵심 라이브러리 사이의 선은 언어마다 다릅니다. 경우에 따라 언어 설계자는 라이브러리를 언어와 별개의 개체로 취급할 수 있습니다. 그러나 언어의 핵심 라이브러리는 사용자에 의해 언어의 일부로 취급되는 경우가 많으며 일부 언어 사양에서는 이 라이브러리를 모든 구현에서 사용할 수 있도록 요구하기도 합니다. 실제로 일부 언어는 핵심 라이브러리를 참조하지 않고는 특정 구문 구조의 의미를 설명할 수조차 없도록 설계되었습니다. 예를 들어 자바에서 문자열 리터럴은 다음의 인스턴스로 정의됩니다. java.lang.String 클래스; 마찬가지로 Smalltalk에서는 익명 함수식("블록")이 라이브러리의 인스턴스를 구성합니다. BlockContext 학급. 반대로, 스킴은 나머지 언어를 라이브러리 매크로로 구성하기에 충분한 다수의 일관성 있는 하위 집합을 포함하고 있으므로 언어 설계자는 언어의 어떤 부분이 언어 구성체로 구현되어야 하는지, 그리고 어떤 부분이 라이브러리의 일부로 구현되어야 하는지에 대해 말할 필요도 없습니다.

설계 및 구현

프로그래밍 언어는 의사소통을 위한 매개체로서 목적과 관련된 자연 언어와 속성을 공유하고, 의미론과 별개의 통사적 형태를 가지며, 관련 언어의 언어군을 서로 분기시키는 것을 보여줍니다.[48][49] 그러나 인공 구조물로서 사용을 통해 진화한 언어와는 근본적인 차이도 있습니다. 중요한 차이점은 프로그래밍 언어가 정확하고 유한한 정의를 가지고 있기 때문에 전체적으로 설명하고 연구할 수 있다는 것입니다.[50] 대조적으로, 자연 언어는 다른 커뮤니티에서 사용자에 의해 의미가 변경됩니다. 구성된 언어도 처음부터 특정 목적을 가지고 설계된 인공 언어이지만 프로그래밍 언어가 가지고 있는 정확하고 완전한 의미 정의는 부족합니다.

많은 프로그래밍 언어가 처음부터 설계되고 새로운 요구에 맞게 변경되었으며 다른 언어와 결합되었습니다. 많은 사람들이 결국 사용되지 않게 되었습니다. 모든 목적에 부합하는 하나의 "보편적인" 프로그래밍 언어를 설계하려는 시도가 있었지만, 이들 모두가 이 역할을 수행하는 것으로 일반적으로 받아들여지는 데 실패했습니다.[51] 다양한 프로그래밍 언어의 필요성은 언어가 사용되는 맥락의 다양성에서 비롯됩니다.

  • 프로그램은 개인 취미자가 작성한 작은 스크립트부터 수백 명의 프로그래머가 작성한 거대한 시스템까지 다양합니다.
  • 프로그래머는 무엇보다 단순함이 필요한 초보자부터 상당한 복잡성으로 편안할 수 있는 전문가까지 전문성을 갖추고 있습니다.
  • 프로그램은 마이크로 컨트롤러에서 슈퍼컴퓨터에 이르기까지 다양한 시스템에서 속도, 크기 및 단순성의 균형을 맞춰야 합니다.
  • 프로그램은 한 번 작성되고 세대에 걸쳐 변경되지 않을 수도 있고 지속적으로 수정될 수도 있습니다.
  • 프로그래머들은 단순히 그들의 취향이 다를 수 있습니다: 그들은 문제를 논의하고 특정 언어로 표현하는 데 익숙할 수 있습니다.

프로그래밍 언어의 발전에 있어서 하나의 일반적인 경향은 더 높은 수준의 추상화를 사용하여 문제를 해결하는 능력을 추가하는 것이었습니다. 초기 프로그래밍 언어는 컴퓨터의 기본 하드웨어와 매우 밀접하게 연결되어 있었습니다. 새로운 프로그래밍 언어가 발전함에 따라 프로그래머가 단순 번역에서 더 멀리 떨어진 아이디어를 기반 하드웨어 명령어로 표현할 수 있는 기능이 추가되었습니다. 프로그래머들은 컴퓨터의 복잡성에 덜 얽매이기 때문에, 그들의 프로그램은 프로그래머의 노력을 덜 들여서 더 많은 컴퓨팅을 할 수 있습니다. 이를 통해 시간 단위당 더 많은 기능을 작성할 수 있습니다.[52]

프로그래밍을 위한 전문 언어가 필요하지 않은 방법으로 자연어 프로그래밍이 제안되었습니다. 그러나 이 목표는 여전히 멀고 그 이점은 논쟁의 여지가 있습니다. Edsger W. Dijkstra는 무의미한 작법의 도입을 막기 위해 공식 언어의 사용이 필수적이라는 입장을 취했고, 자연어 프로그래밍은 "어리석음"이라고 일축했습니다.[53] Alan Perlis도 마찬가지로 그 아이디어를 무시했습니다.[54] 구조화된 영어와 SQL에서 하이브리드 접근 방식을 취했습니다.

언어의 설계자와 사용자는 프로그래밍 실습을 관리하고 가능하게 하는 여러 인공물을 구성해야 합니다. 이러한 인공물 중 가장 중요한 것은 언어 사양구현입니다.

사양

프로그래밍 언어의 사양은 언어 사용자구현자소스 코드가 해당 언어에서 유효한 프로그램인지 여부와 동작이 무엇인지에 대해 합의하는 데 사용할 수 있는 인공물입니다.

프로그래밍 언어 사양은 다음과 같은 여러 가지 형식을 취할 수 있습니다.

  • 언어의 구문, 정적 의미론 및 실행 의미론에 대한 명시적인 정의입니다. 구문은 일반적으로 형식 문법을 사용하여 지정되지만 의미론적 정의는 자연어(예: C 언어와 같이) 또는 형식 의미론(예: 표준 ML[55]체계[56] 사양과 같이)으로 작성될 수 있습니다.
  • 언어에 대한 번역기 동작(예: C++ 및 Fortran 사양)에 대한 설명입니다. 이 설명에서 언어의 구문 및 의미론을 추론해야 하며, 이는 자연어 또는 형식 언어로 작성될 수 있습니다.
  • 참조 또는 모델 구현으로, 때때로 지정되는 언어로 작성됩니다(예: Prolog 또는 ANSI REXX[57]). 언어의 구문 및 의미론은 참조 구현의 동작에서 명시적입니다.

실행

프로그래밍 언어의 구현은 해당 언어로 프로그램을 작성하고 하드웨어 및 소프트웨어의 하나 이상의 구성에서 프로그램을 실행하는 방법을 제공합니다. 프로그래밍 언어 구현에는 크게 컴파일과 해석의 두 가지 접근 방식이 있습니다. 일반적으로 두 가지 기술 중 하나를 사용하여 언어를 구현하는 것이 가능합니다.

컴파일러의 출력은 하드웨어 또는 인터프리터라는 프로그램에 의해 실행될 수 있습니다. 인터프리터 접근 방식을 사용하는 일부 구현에서는 컴파일과 인터프리터 사이에 뚜렷한 경계가 없습니다. 예를 들어, BASIC의 일부 구현은 소스를 한 줄씩 컴파일한 다음 실행합니다.

하드웨어에서 직접 실행되는 프로그램은 일반적으로 소프트웨어로 해석되는 프로그램보다 훨씬 빠르게 실행됩니다.[58][better source needed]

해석된 프로그램의 성능을 향상시키기 위한 한 가지 기술은 시간컴파일입니다. 여기서 가상 시스템은 실행 직전에 하드웨어에서 직접 실행하기 위해 기계 코드에 사용될 바이트 코드 블록을 변환합니다.

고유 언어

가장 일반적으로 사용되는 대부분의 프로그래밍 언어는 완전히 개방된 사양과 구현을 가지고 있지만, 많은 프로그래밍 언어는 독점적인 프로그래밍 언어로만 존재하며, 이러한 독점적인 언어는 그들의 지적 재산이라고 주장할 수 있습니다. 독점 프로그래밍 언어는 일반적으로 도메인별 언어 또는 단일 제품의 내부 스크립트 언어입니다. 일부 독점 언어는 공급업체 내에서만 내부적으로 사용되는 반면 다른 언어는 외부 사용자가 사용할 수 있습니다.[citation needed]

일부 프로그래밍 언어는 독점 언어와 개방 언어의 경계에 존재합니다. 예를 들어, 오라클자바 프로그래밍 언어의 일부 측면에 대한 독점적 권리를 주장하며,[59] 시스템 대부분의 부분을 개방형으로 구현하는 마이크로소프트의 C# 프로그래밍 언어도 폐쇄형 환경으로 공통 언어 런타임(CLR)을 가지고 있습니다.[60]

많은 독점 언어들이 독점적인 특성에도 불구하고 널리 사용되고 있습니다. 예를 들어 MATLAB, VBScript, Wolfram Language 등이 있습니다. 일부 언어는 폐쇄형에서 개방형으로 전환할 수 있습니다. 예를 들어, Erlang은 원래 에릭슨의 내부 프로그래밍 언어였습니다.[61]

사용하다

주로 컴퓨팅 분야에서 수천 개의 다양한 프로그래밍 언어가 생성되었습니다.[62] 개별 소프트웨어 프로젝트는 일반적으로 5개 이상의 프로그래밍 언어를 사용합니다.[63]

프로그래밍 언어는 더 높은 수준의 정밀도와 완전성을 필요로 한다는 점에서 대부분의 다른 형태의 인간 표현과 다릅니다. 자연어를 사용하여 다른 사람과 의사소통을 할 때, 인간 저자와 화자는 모호하고 작은 오류를 범할 수 있으며, 여전히 그들의 의도가 이해되기를 기대합니다. 그러나 비유적으로 말해서, 컴퓨터는 "그들이 시키는 대로 정확히 한다"며 프로그래머가 어떤 코드를 작성하려고 했는지 "이해"할 수 없습니다. 언어 정의, 프로그램 및 프로그램 입력의 조합은 해당 프로그램의 제어 영역 내에서 프로그램이 실행될 때 발생하는 외부 동작을 완전히 지정해야 합니다. 반면, 프로그래밍 언어로 작성된 코드와 자연어를 상호 변환하는 의사 코드를 사용함으로써 알고리즘에 대한 아이디어를 실행에 필요한 정밀도 없이 인간에게 전달할 수 있습니다.

프로그래밍 언어는 데이터 조각과 해당 데이터에 대해 자동으로 수행될 수 있는 작업 또는 변환을 정의하기 위한 구조화된 메커니즘을 제공합니다. 프로그래머는 언어에 존재하는 추상화를 사용하여 계산과 관련된 개념을 나타냅니다. 이러한 개념은 사용 가능한 가장 간단한 요소의 모음(원형이라고 함)으로 표현됩니다.[64] 프로그래밍은 프로그래머가 이러한 프리미티브를 결합하여 새로운 프로그램을 구성하거나 기존 프로그램을 새로운 용도나 변화하는 환경에 적응시키는 과정입니다.

컴퓨터에 대한 프로그램은 사람의 상호 작용 없이 일괄 프로세스실행되거나 사용자가 인터프리터대화형 세션에서 명령을 입력할 수 있습니다. 이 경우 "명령어"는 단순히 프로그램으로, 실행이 함께 연결되어 있습니다. 언어가 컴파일하지 않고 인터프리터(예: 유닉스 셸 또는 기타 명령줄 인터페이스)를 통해 명령을 실행할 수 있는 경우 이를 스크립팅 언어라고 합니다.[65]

언어사용량 측정

문맥에 따라 사용 정의가 다르기 때문에 어떤 프로그래밍 언어가 가장 널리 사용되는지 확인하기가 어렵습니다. 한 언어는 더 많은 프로그래머 시간을 차지할 수 있고, 다른 언어는 더 많은 코드 라인을 가지고 있으며, 3분의 1은 가장 많은 CPU 시간을 소비할 수 있습니다. 일부 언어는 특정 종류의 응용 프로그램에 매우 인기가 있습니다. 예를 들어, 코볼은 기업 데이터 센터, 종종 대규모 메인프레임에서,[66][67] 과학 및 엔지니어링 애플리케이션에서 포트란, 항공 우주, 운송, 군사, 실시간 및 임베디드 애플리케이션에서, C는 임베디드 애플리케이션 및 운영 체제에서 여전히 강력합니다. 다른 언어는 다양한 종류의 응용 프로그램을 작성하는 데 정기적으로 사용됩니다.

언어 인기를 측정하는 다양한 방법들이 제안되었으며, 각각 측정된 것에 대해 다른 편향을 가지고 있습니다.

  • [68] 언어를 언급하는 구인 광고의 수를 세는 것
  • [69] 언어를 가르치거나 기술하는 책의 판매수.
  • 언어로 작성된 기존 코드 줄 수 추정치 - 공개 검색에서[70] 자주 발견되지 않는 언어를 과소 평가할 수 있음
  • 웹 검색 엔진을 사용하여 찾은 언어 참조 수(즉, 언어 이름).

stackify.com 은 다양한 인터넷 사이트의 정보를 종합하고 평균화하여 가장 인기 있는 10개의 프로그래밍 언어(전체 인기도에 따라 내림차순)를 보고했습니다. 자바, C, C++, 파이썬, C#, 자바스크립트, VB.NET, R, PHP, MATLAB.[71]

방언, 맛, 구현

프로그래밍 언어 또는 데이터 교환 언어방언은 고유한 특성을 변경하지 않는 언어의 (상대적으로 작은) 변형 또는 확장입니다. SchemeFours와 같은 언어의 경우 표준이 시행자에 의해 불충분하거나 부적절하거나 부적절하다고 간주될 수 있으므로 종종 표준에서 벗어나 새로운 방언을 만듭니다. 다른 경우에는 도메인별 언어, 종종 부분 집합에서 사용하기 위해 방언이 만들어집니다. 리스프 세계에서 기본적인 S 표현 구문과 리스프 유사 의미론을 사용하는 대부분의 언어는 라켓클로쥬르처럼 매우 다양하지만 리스프 방언으로 간주됩니다. 한 언어에 여러 방언이 있는 것이 일반적이기 때문에 경험이 부족한 프로그래머가 올바른 문서를 찾기가 상당히 어려워질 수 있습니다. 기본 언어에는 많은 방언이 있습니다.

분류학

프로그래밍 언어에 대한 포괄적인 분류 체계는 없습니다. 주어진 프로그래밍 언어는 일반적으로 단일 조상 언어를 갖지 않습니다. 언어는 일반적으로 여러 이전 언어의 요소와 당시 유통되고 있는 새로운 아이디어를 결합하여 발생합니다. 한 언어에서 비롯된 아이디어는 관련 언어의 가족 전체에 확산되고 갑자기 가족 격차를 뛰어넘어 완전히 다른 가족에 나타날 것입니다.

이 작업은 언어가 여러 축을 따라 분류될 수 있다는 사실 때문에 더욱 복잡합니다. 예를 들어, Java는 객체 지향 언어(객체 지향 조직을 장려하기 때문에)이면서 동시 언어(여러 스레드를 병렬로 실행하기 위한 내장 구성 요소가 포함되어 있기 때문에)입니다. 파이썬객체 지향 스크립팅 언어입니다.[72]

일반적으로 프로그래밍 언어는 프로그래밍 패러다임사용 목적 도메인에 따라 분류되며, 범용 프로그래밍 언어도메인별 프로그래밍 언어와 구별됩니다. 전통적으로 프로그래밍 언어는 명령문, 즉 명령문의 관점에서 계산을 설명하는 것으로 간주되었습니다. 이러한 언어를 일반적으로 필수 프로그래밍 언어라고 합니다. 프로그래밍 언어의 많은 연구는 일련의 명령어로서의 프로그램과 선언적 프로그래밍의 주요 특징인 원하는 답변에 대한 주장으로서의 프로그램의 구분을 모호하게 하는 것을 목표로 하고 있습니다.[73] 더 세련된 패러다임에는 절차 프로그래밍, 객체 지향 프로그래밍, 기능 프로그래밍논리 프로그래밍이 포함됩니다. 일부 언어는 패러다임의 하이브리드 또는 멀티패러다임입니다. 어셈블리 언어는 기본적인 기계 아키텍처의 직접적인 모델보다는 패러다임이 아닙니다. 목적에 따라 프로그래밍 언어는 범용, 시스템 프로그래밍 언어, 스크립트 언어, 도메인별 언어 또는 동시/분산 언어(또는 이들의 조합)로 간주될 수 있습니다.[74] 일부 범용 언어는 주로 교육 목표를 가지고 설계되었습니다.[75]

프로그래밍 언어는 프로그래밍 패러다임과 관련 없는 요인에 의해 분류될 수도 있습니다. 예를 들어, 대부분의 프로그래밍 언어는 영어 키워드를 사용하지만 소수는 사용하지 않습니다. 다른 언어는 의도적으로 난해하거나 그렇지 않은 것으로 분류될 수 있습니다.

참고 항목

참고문헌

  1. ^ a b c Aaby, Anthony (2004). Introduction to Programming Languages. Archived from the original on 8 November 2012. Retrieved 29 September 2012.
  2. ^ 로버트 에이. Edmunds, Prentice-Hall 표준 용어집, Prentice-Hall, 1985, p.91
  3. ^ Pascal Lando, Anne Lapujade, Gilles Kassel 및 Frédéric Fürst, 2015년 7월 7일 Wayback Machine에서 아카이브된 컴퓨터 프로그램일반적인 온톨로지를 향하여, ICSOFT 2007년 4월 27일 Wayback Machine에서 아카이브됨, pp. 163–170
  4. ^ S.K. Bajpai, 컴퓨터 소개 및 C 프로그래밍, New Age International, 2007, ISBN 81-224-1379-X, 페이지 346
  5. ^ "Turing Completeness". www.cs.odu.edu. Retrieved 5 October 2022.
  6. ^ Digital Equipment Corporation. "Information Technology – Database Language SQL (Proposed revised text of DIS 9075)". ISO/IEC 9075:1992, Database Language SQL. Archived from the original on 21 June 2006. Retrieved 29 June 2006.
  7. ^ The Charity Development Group (December 1996). "The CHARITY Home Page". Archived from the original on 18 July 2006.The Charity Development Group (December 1996). "The CHARITY Home Page". Archived from the original on 18 July 2006."자선은 범주형 프로그래밍 언어입니다...", "모든 자선 계산이 종료됩니다."
  8. ^ 수학적 용어로, 이것은 프로그래밍 언어가 튜링-완전하다는 것을 의미합니다.
  9. ^ R. 나라심한, 프로그래밍 언어와 컴퓨터: 통합된 메타이론, 프란츠 알트, 모리스 루비노프 (편집부) 189-247쪽. 컴퓨터의 발전, 8권, 학술 출판부, 1994, ISBN 0-12-012108-5, p.215: "..." 컴퓨터 언어에 대한 모델은 프로그래밍 언어에 대한 모델 [...]과 두 가지 측면에서만 다릅니다. 컴퓨터 언어에서 이름 또는 레지스터는 유한하게 많은 값 또는 상태만 가정할 수 있으며 이러한 상태는 다른 속성의 관점에서 더 이상 구별되지 않습니다. [저자 각주:] 이것은 사실처럼 들릴지 모르지만 그 의미는 광범위합니다. 예를 들어, 프로그래밍 언어에 대한 모델은 특정 매개 변수나 기능을 수정함으로써 컴퓨터 언어에 대한 모델로 자연스럽게 축소할 수 있어야 한다는 것을 의미합니다."
  10. ^ 존 C. Reynolds, "프로그래밍과 프로그래밍 언어를 가르치는 것에 대한 몇 가지 생각", SIGPLAN Notices, Volume 43, 2008년 11월 11일, p.109
  11. ^ Ben Ari, Mordechai (1996). Understanding Programming Languages. John Wiley and Sons. Programs and languages can be defined as purely formal mathematical objects. However, more people are interested in programs than in other mathematical objects such as groups, precisely because it is possible to use the program—the sequence of symbols—to control the execution of a computer. While we highly recommend the study of the theory of programming, this text will generally limit itself to the study of programs as they are executed on a computer.
  12. ^ 10개 지점의 XML "XML은 프로그래밍 언어가 아닙니다." Wayback Machine W3C에서 2009년 9월 6일 아카이브되었습니다.
  13. ^ Powell, Thomas (2003). HTML & XHTML: the complete reference. McGraw-Hill. p. 25. ISBN 978-0-07-222942-4. HTML is not a programming language.
  14. ^ Dykes, Lucinda; Tittel, Ed (2005). XML For Dummies (4th ed.). Wiley. p. 20. ISBN 978-0-7645-8845-7. ...it's a markup language, not a programming language.
  15. ^ "What kind of language is XSLT?". IBM.com. 20 April 2005. Archived from the original on 11 May 2011.
  16. ^ "XSLT is a Programming Language". Msdn.microsoft.com. Archived from the original on 3 February 2011. Retrieved 3 December 2010.
  17. ^ Scott, Michael (2006). Programming Language Pragmatics. Morgan Kaufmann. p. 802. ISBN 978-0-12-633951-2. XSLT, though highly specialized to the transformation of XML, is a Turing-complete programming language.
  18. ^ Oetiker, Tobias; Partl, Hubert; Hyna, Irene; Schlegl, Elisabeth (20 June 2016). "The Not So Short Introduction to LATEX 2ε" (Version 5.06). tobi.oetiker.ch. pp. 1–157. Archived (PDF) from the original on 14 March 2017.
  19. ^ Syropoulos, Apostolos; Antonis Tsolomitis; Nick Sofroniou (2003). Digital typography using LaTeX. Springer-Verlag. p. 213. ISBN 978-0-387-95217-8. TeX is not only an excellent typesetting engine but also a real programming language.
  20. ^ 데이비드 에이. Schmidt, 타이핑 프로그래밍 언어의 구조, MIT Press, 1994, ISBN 0-262-19349-3, 페이지 32
  21. ^ Pierce, Benjamin (2002). Types and Programming Languages. MIT Press. p. 339. ISBN 978-0-262-16209-8.
  22. ^ 로하스, 라울 등. (2000). "플랑칼ü: 최초의 고급 프로그래밍 언어와 그 구현." Institute für Informatik, Freie Universität Berlin, 기술 보고서 B-3/2000. (전문) Wayback Machine에서 2014년 10월 18일 아카이브
  23. ^ 세베스타, W.S 프로그래밍 언어 개념. 2006; M6 14:18 pp.44. ISBN 0-321-33025-0
  24. ^ Knuth, Donald E.; Pardo, Luis Trabb. "Early development of programming languages". Encyclopedia of Computer Science and Technology. 7: 419–493.
  25. ^ Peter J. Bentley (2012). Digitized: The Science of Computers and how it Shapes Our World. Oxford University Press. p. 87. ISBN 9780199693795. Archived from the original on 29 August 2016.
  26. ^ "Fortran creator John Backus dies – Tech and gadgets". NBC News. 20 March 2007. Retrieved 25 April 2010.
  27. ^ "CSC-302 99S : Class 02: A Brief History of Programming Languages". Math.grin.edu. Archived from the original on 15 July 2010. Retrieved 25 April 2010.
  28. ^ Eugene Loh (18 June 2010). "The Ideal HPC Programming Language". Queue. 8 (6). Archived from the original on 4 March 2016.
  29. ^ "HPL – A Portable Implementation of the High-Performance Linpack Benchmark for Distributed-Memory Computers". Archived from the original on 15 February 2015. Retrieved 21 February 2015.
  30. ^ 호퍼 (1978) 16쪽.
  31. ^ Sammet (1969) p. 316
  32. ^ Sammet (1978) p. 204.
  33. ^ 리처드 L. Wexelblat: 프로그래밍 언어의 역사, 학술 출판, 1981, 제XIV장.
  34. ^ François Labelle. "Programming Language Usage Graph". SourceForge. Archived from the original on 17 June 2006. Retrieved 21 June 2006.François Labelle. "Programming Language Usage Graph". SourceForge. Archived from the original on 17 June 2006. Retrieved 21 June 2006.이 비교는 인기 있는 커뮤니티 프로그래밍 저장소에서 호스팅하는 프로젝트 수의 추세를 분석합니다. 2006년에는 자바가 C를 추월했지만, C/C++의 결합은 여전히 상당한 차이를 보이고 있습니다.
  35. ^ Hayes, Brian (2006). "The Semicolon Wars". American Scientist. 94 (4): 299–303. doi:10.1511/2006.60.299.
  36. ^ Dijkstra, Edsger W. (March 1968). "Go To Statement Considered Harmful" (PDF). Communications of the ACM. 11 (3): 147–148. doi:10.1145/362929.362947. S2CID 17469809. Archived (PDF) from the original on 13 May 2014.
  37. ^ 후지세 테츠로, 치카야마 타카시, 로쿠사와 카즈아키, 나카세 아키히코 (1994년 12월). 1994년 12월 ICOT Tokyo, FGCS'94의 "KLIC: A Portable Implement of KL1" Proc. : CS1 main: 제목 (링크) KLIC는 동시 로직 프로그래밍 언어 KL1의 휴대 가능한 구현입니다.
  38. ^ Jim Bender (15 March 2004). "Mini-Bibliography on Modules for Functional Programming Languages". ReadScheme.org. Archived from the original on 24 September 2006.
  39. ^ Michael Sipser (1996). Introduction to the Theory of Computation. PWS Publishing. ISBN 978-0-534-94728-6. 섹션 2.2: 푸쉬다운 오토마타, 페이지 101–114.
  40. ^ Jeffrey Kegler, "2009년 8월 17일 Wayback Machine에서 PerlUncidability Archive", Perl Review. 논문 2와 3은 각각 Rice의 정리정지 문제에 대한 직접적인 축소를 사용하여 Perl 프로그램의 구문 분석이 일반적으로 결정할 수 없음을 증명합니다.
  41. ^ Marty Hall, 1995, 강의 노트: 매크로는 2013년 8월 6일 웨이백 머신에서 보관, 포스트스크립트 버전은 2000년 8월 17일 웨이백 머신에서 보관
  42. ^ Michael Lee Scott, Programming language pragmatics, Edition 2, Morgan Kaufmann, 2006, ISBN 0-12-633951-1, 페이지 18-19
  43. ^ a b c d e f g Andrew Cooke. "Introduction To Computer Languages". Archived from the original on 15 August 2012. Retrieved 13 July 2012.
  44. ^ Leivant, Daniel (1983). Polymorphic type inference. ACM SIGACT-SIGPLAN symposium on Principles of programming languages. Austin, Texas: ACM Press. pp. 88–98. doi:10.1145/567067.567077. ISBN 978-0-89791-090-3.
  45. ^ 구체적으로, 일반 유형의 인스턴스화는 특정 표현 형식에 대해 추론됩니다. 일반 자바의 유형 추론(Java 1.5의 경계 매개 변수 다형성 확장의 기초를 제공한 연구 언어)은 유형 메일링 목록에서 두 개의 비공식 원고에서 논의됩니다. 일반 자바 유형 추론이 소리가 나지 않습니다. 2007년 1월 29일 웨이백 머신(Alan Jeffrey, 2001년 12월 17일)에서 보관되고 사운드 일반 자바 유형 추론이 2007년 1월 29일 웨이백 머신(Martin Odersky, 2002년 1월 15일)에서 보관됩니다. C#의 유형 시스템은 Java의 유형과 유사하며 유사한 부분 유형 추론 방식을 사용합니다.
  46. ^ "Revised Report on the Algorithmic Language Scheme". 20 February 1998. Archived from the original on 14 July 2006.
  47. ^ Luca Cardelli and Peter Wegner. "On Understanding Types, Data Abstraction, and Polymorphism". Manuscript (1985). Archived from the original on 19 June 2006.
  48. ^ 스티븐 R. Fischer, 언어의 역사, Reaktion Books, 2003, ISBN 1-86189-080-X, 페이지 205
  49. ^ Éric Lévénez (2011). "Computer Languages History". Archived from the original on 7 January 2006.
  50. ^ Jing Huang. "Artificial Language vs. Natural Language". Archived from the original on 3 September 2009.
  51. ^ 예를 들어, 최초로 PL/I를 출판한 IBM은 다소 야심차게 매뉴얼 "The Universal Programming Language PL/I (IBM Library; 1966)"라는 제목을 붙였습니다. 제목은 무제한 서브셋 기능에 대한 IBM의 목표를 반영했습니다: "PL/I는 특정 애플리케이션의 요구사항을 충족하는 서브셋을 분리할 수 있도록 설계되었습니다."()."PL/I". Encyclopedia of Mathematics. Archived from the original on 26 April 2012. Retrieved 29 June 2006. AdaUNCOL은 비슷한 초기 목표를 가지고 있었습니다.
  52. ^ Frederick P. Brooks 주니어: 신화적 인간-월, 애디슨-웨슬리, 1982, 93-94쪽
  53. ^ 데이크스트라, 에드거 W. "자연어 프로그래밍"의 어리석음에 대해. 2008년 1월 20일 Wayback Machine EWD667에 보관되었습니다.
  54. ^ Perlis, Alan (September 1982). "Epigrams on Programming". SIGPLAN Notices Vol. 17, No. 9. pp. 7–13. Archived from the original on 17 January 1999.
  55. ^ Milner, R.; M. Tofte; R. Harper; D. MacQueen (1997). The Definition of Standard ML (Revised). MIT Press. ISBN 978-0-262-63181-5.
  56. ^ Kelsey, Richard; William Clinger; Jonathan Rees (February 1998). "Section 7.2 Formal semantics". Revised5 Report on the Algorithmic Language Scheme. Archived from the original on 6 July 2006.
  57. ^ ANSI – 프로그래밍 언어 Rexx, X3-274.1996
  58. ^ Steve, McConnell (2004). Code complete (Second ed.). Redmond, Washington. pp. 590, 600. ISBN 0735619670. OCLC 54974573.{{cite book}}: CS1 maint: 위치 누락 게시자(링크)
  59. ^ 참조: Oracle America, Inc.Google, Inc.[user-generated source]
  60. ^ "Guide to Programming Languages ComputerScience.org". ComputerScience.org. Retrieved 13 May 2018.
  61. ^ "The basics". ibm.com. 10 May 2011. Retrieved 13 May 2018.
  62. ^ "HOPL: an interactive Roster of Programming Languages". Australia: Murdoch University. Archived from the original on 20 February 2011. Retrieved 1 June 2009. This site lists 8512 languages.
  63. ^ Mayer, Philip; Bauer, Alexander (2015). "An empirical analysis of the utilization of multiple programming languages in open source projects". Proceedings of the 19th International Conference on Evaluation and Assessment in Software Engineering. Proceedings of the 19th International Conference on Evaluation and Assessment in Software Engineering – EASE '15. New York, NY, US: ACM. pp. 4:1–4:10. doi:10.1145/2745802.2745805. ISBN 978-1-4503-3350-4. Results: We found (a) a mean number of 5 languages per project with a clearly dominant main general-purpose language and 5 often-used DSL types, (b) a significant influence of the size, number of commits, and the main language on the number of languages as well as no significant influence of age and number of contributors, and (c) three language ecosystems grouped around XML, Shell/Make, and HTML/CSS. Conclusions: Multi-language programming seems to be common in open-source projects and is a factor that must be dealt with in tooling and when assessing the development and maintenance of such software systems.
  64. ^ Abelson, Sussman, and Sussman. "Structure and Interpretation of Computer Programs". Archived from the original on 26 February 2009. Retrieved 3 March 2009.{{cite web}}: CS1 maint: 다중 이름: 저자 목록 (링크)
  65. ^ Vicki, Brown; Morin, Rich (1999). "Scripting Languages". MacTech. Archived from the original on 2 December 2017.
  66. ^ Georgina Swan (21 September 2009). "COBOL turns 50". Computerworld. Archived from the original on 19 October 2013. Retrieved 19 October 2013.
  67. ^ Ed Airey (3 May 2012). "7 Myths of COBOL Debunked". developer.com. Archived from the original on 19 October 2013. Retrieved 19 October 2013.
  68. ^ Nicholas Enticknap. "SSL/Computer Weekly IT salary survey: finance boom drives IT job growth". Computer Weekly. Archived from the original on 26 October 2011. Retrieved 14 June 2013.
  69. ^ "Counting programming languages by book sales". Radar.oreilly.com. 2 August 2006. Archived from the original on 17 May 2008.
  70. ^ Bieman, J.M., Murdock, V., World Wide Web에서 코드 찾기: 예비 조사, 소스 코드 분석 및 조작에 관한 최초 IEEE 국제 워크숍, 2001
  71. ^ "Most Popular and Influential Programming Languages of 2018". stackify.com. 18 December 2017. Retrieved 29 August 2018.
  72. ^ "Fluent Python 2nd edition". Thoughtworks. Retrieved 11 October 2022.
  73. ^ 칼 A. Gunter, 프로그래밍 언어의 의미론: 구조 기법, MIT 출판, 1992, ISBN 0-262-57095-5, 페이지 1
  74. ^ "TUNES: Programming Languages". Archived from the original on 20 October 2007.
  75. ^ Wirth, Niklaus (1993). "Recollections about the development of Pascal". The second ACM SIGPLAN conference on History of programming languages - HOPL-II. Vol. 28. pp. 333–342. CiteSeerX 10.1.1.475.6989. doi:10.1145/154766.155378. ISBN 978-0-89791-570-0. S2CID 9783524.

더보기