Hi yoahn 개발블로그

#2 프로그래밍 언어 개발의 역사 본문

sswu/프로그래밍언어론

#2 프로그래밍 언어 개발의 역사

hi._.0seon 2020. 6. 8. 21:35
반응형

1. 1950년대: 프로그래밍 언어의 여명기

1) FORTRAN       (FORmula TRANslation)

: 복잡한 수식을 쓰면, 어셈블리어로 자동으로 번역해 주는 것

- John Backus (IBM) -> 포트란 개발, BNF 개발

- 목적: 과학/공학 계산 목적

- 목표: 결과로 나온 기계어 코드의 효율

- 변수 길이 최대 6글자 이하

  why? -> 포트란 개발 당시 IBM 컴퓨터의 메모리 워드 사이즈 = 36bit <- 6bit *6글자

                           인코딩 방식이 EBIDIC으로 한 글자를 6bit로 표현

 

- 성공 1) 효율적인 코드

         2) 처음으로 알려진 고급 프로그래밍 언어

 

->  명령형 패러다임의 시작

2) COBOL       (COmmon Business-Oriented Language)

: 비즈니스 지향 언어

- 설계자: Grace Hopper

- 목적 분야: 관공서, 경영. 행정, 상업분야

- 설계 목표: 높은 인간 판독성 -> 영어 문법과 유사 (영어와 유사할 수록 친근하고 쉽게 느낌)

- 1) 파일 다루는 기능

  2) 자료구조 -> 구조체에 영향

- Bug 개념 처음 사용

 

- 비즈니스 분야 -> 알고리즘 단순, 데이터: 구조체, 빅데이터, 출력 중요

- 과학/공학 분야 -> 알고리즘 복잡, 데이터: 배열 (단순), 출력 형식 상관 x

3) LISP        (LISt Processing)

: List에 특화된 프로그래밍 언어

- John McCarthy

- 대상 분야: 인공지능

- 설계 목표: linkedList 를 쉽게 다루기 위함. 데이터프로그램같은 형식으로 표시

   -> 프로그램과 데이터의 구분이 없음

        리스트로 표현된 데이터와 프로그램을 쉽게 다루고자 하는게 설계 목표

- 단점: 폰노이만 구조인 컴퓨터에서 Lisp 프로그램을 실행시키는 것이 비효율적이다

      -> "LISP Machine"

-> 함수형 패러다임에 해당

 

ex) 리스트의 접합

논리형 패러다임: 원리만 선언하면 됨

명령형 패러다임: 실제 구현 방법을 상세히 기술해야 함

 

* 함수형 패러다임

- 수학의 함수 기반

- HW 기반은 아님

 -> 폰노이만 구조(HW기반)와 궁합이 맞지 않음 -> 비효율적

3-1) 인공지능에서 List의 중요성

- 메모리 차이

   인간 : 데이터 양이 많아지면 데이터를 빨리 끄집어 낼 수 있다

   컴퓨터: 데이터 양이 많아지면 특정 값을 찾는 시간이 오래 걸림

 

- 인간 메모리: 연관 메모리, (해싱, 키에 관련된 데이터 바로 접근)

인공지능: List를 효율적으로 다루는 것이 중요하다.

    -> 프로그램을 데이터처럼 취급해서 가공할 수 있음

     -> 프로그램 스스로 학습할 때 데이터처럼 가공 = 스스로 학습

- Join 연산 -> 컴퓨터는 시간이 오래 걸림, 사람은 간단

            -> 컴퓨터와 사람의 메모리 구조 차이 때문

  사람은 뉴런들이 망 형태로 연결 -> 리스트의 연속으로 데이터가 저장됨 -> Join을 빨리 추출할 수 있다.

 

2. 1960년대: 프로그래밍 언어의 범람

1) Algol60      (ALGOrithmic Language 1960)

- Algol Committee

- 대상 분야: 알고리즘 발표 (논문이나 책에 포함된 알고리즘을 기술하는데 많이 사용)

- 설계 목표: 사람 머릿속에서 나온 알고리즘을 제한없이 기술하는 것

** 재귀를 간결하게 표현 가능 (quicksort)

* Algol60의 장점: 포함되어 있는 매커니즘이 사람의 머릿속에서 나온 알고리즘을 기술하는데 적합

                        사람이 생각하는 것과 추상화 레벨이 비슷함

- 현대 언어의 표준 확립

 2) PL/1         (Programming Language One)

- IBM

  프로그래밍 언어는 하나다.

- 목표 대상: ALL

    맥가이버 칼처럼 모든 언어의 기능/장점을 하나의 언어로 통합

( 언어의 크기가 커짐 -> 컴파일러 커짐 -> 오류 up, 신뢰도 down )

- 설계 목표: 스위스 군용 칼 (fortran 의 대수적 식 표현 + COBOL의 구조체&출력 조정 기능 + Algol60의 구조화된 제어 구조 )

- 다익스트라 comment: 너무 많은 기능은 마스터의 양성이 어렵다

3) Simula67     (SIMUlation Language 1967)

- Kristen Nygard, Ole-Johan Dahl, 노르웨이 컴퓨팅 센터

- 대상 영역: Simulation

- 설계 목표: 클래스를 통해서 실세계의 문제를 추상화

                          -> 객체 지향 언어 ??????????????

- 객체지향의 시조

 

3. 1970년대: 기본으로의 회귀

1) Pascal

- Niklaus Wirth

- target Area: 프로그래밍 교육용

- 설계 목표: 단순성을 통해 기초로 돌아가자

1) 기능이 단순

2) 언어의 크기가 작음 -> 작은 컴파일러 -> 설치 쉬움

교육 -> 초보자를 위한 것

 

** Bootstrapping of its Compiler

- 파스칼 컴파일러(파스칼로 쓰여짐) _ 실행파일 -> 기계어

- 파스칼 언어의 컴파일러를 파스칼로 작성

(모든 언어에는 중복성이 있다. -> 상황마다 적합한 것으로 사용)

- 파스칼에서 중복을 걷어낸 언어

    -> 파스칼의 부분집합에 해당하는 문장으로 된 프로그램이 들어오면 기계어로 변환

              == 파스칼 Subset 컴파일러 (다른 언어로 작성함)

- 파스칼 전체에 해당하는 컴파일러를 Subset 문장만 사용해서 작성함

 -> 파스칼 Subset 컴파일러로 컴파일해서 실행파일을 생성 : 파스칼 컴파일러

=> 컴파일러의 부트스트래핑

 

(파스칼 언어의 부분집합인 언어의 컴파일러는 다른 언어로 작성(이미 컴파일러가 존재하는 언어),

파스칼 subset 언어로 파스칼 컴파일러를 작성, 파스칼 subset  컴파일러로 컴파일해서 실행파일을 생성

-> 파스칼 컴파일러)

 

*PL/1의 접근법

- 추상화된 매커니즘을 다 모음

- 언어의 크기만 커지고 일반성을 획득하지 못함, 마스터하기 어려움

- 실수할 확률 up

- 컴파일러 만들기 힘들다.

-> 최근 이런 접근 방식의 언어들이 등장 (프로그램의 크기가 너무 커져서)

 

* Pascal

- 가장 기본적인 블록만 갖추어두고 자유롭게 결합할 수 있도록 제한을 두지 않으면 어떤 프로그램도 만들 수 있다.

2) C

- Dennis Ritchie

- Target Area: 시스템 프로그래밍

- 설계 목표: 식과 문장을 같은 언어구조로 균일하게 처리하여 단순성 획득

i++ : 식

i += 1 :문 statement

-> 둘다 C에서는 전부다 '식'

 

4. 1980년대: 객체-지향 개념의 부상

- 객체지향의 시조 : Simula67

- 70년대 객체지향 이론화 작업 Alan kay

- 객체지향 언어 설계: 스몰토크

   (너무 철저한 객체지향으로 잘 사용되지 않음)

1) Ada

: 기존의 명령형 틀 + 객체지향 개념의 장점 이용    - 객체 중심 언어

- 국방용 SW 언어

- Jean Ichbiah

- 군사작전에서 호환SW 를 만들어 운용성 Up, 비용 Down

*군사용: 신뢰도 up, bug 적은 언어, 높은 성능, HW 독립성, 병렬, 병행 처리

- Target Area: 임베디드 프로그래밍 & 실시간 시스템

(수많은 무기에 내장된 시스템, embeded(주 목적이 정해진 기계를 제어하기 위한 SW, 무기))

- 설계 목표: 추상 데이터 타입을 통한 신뢰성 향상

2) C++

- C언어 + class

- Target Area: 시스템 프로그래밍

- 설계 목표: C with Classes

- Simula67의 영향

 

5. 1990년대 이후: 웹 환경과 스크립트 언어의 대두

새롭게 나타나는 언어의 수가 감소

- 90년대부터 스크립트언어 경향

- 스크립트: 대본, 다른 프로그램을 부르거나 조합해서 어떤 목적을 달성하는, 그 전체가 하나의 대본

    -> 스크립트가 프로그램이 됨

- 기존 프로그래밍 언어는 한 프로그램에서 다른 프로그래밍 언어로 작성된 프로그램을 불러서 쓰는 것이 어려움

-> 스크립트 언어는 다른 프로그램의 기능을 자유롭게 불러와서 사용 가능

1)  Java

- James Gosling, Sun Microsystems

- Target Area: embeded programming (가전 제품)

->Web programming

- 설계 목표: 객체 지향 & 안정성

 (가전제품: 다양한 플랫폼 -> 모델링 -> 객체지향

   보안이 약하면 -> 가전제품이 오작동, 일반인이 피해)

- 범용 프로그래밍 언어

 

- 기존 웹브라우저에서 Java코드를 해석하지 못함

  -> Java 언어를 보여주기 위한 동적 웹페이지를 이용하기 위해 웹브라우저를 만듦 = HotJava

- HotJava: 자바로 설계, Java가 웹브라우저도 만들 수 있을 정도로 범용 프로그래밍 언어라는 것을 보여줌

(JAVA를 해석하는 웹브라우저도 JAVA: 부트스트래핑)

 

- 컴퓨팅 환경이 웹으로 바뀌면서 메이저 언어에 Java가 포함됨(바뀐 환경에 적합한 기능을 갖추고 들어감)

- 기존 언어로 짜여진 프로그램을 불러서 

 

- 기존 범용프로그래밍 언어는 한 프로그램에서 다른 프로그래밍 언어로 작성된 프로그램을 불러서 쓰는 것이 어려움

- 스크립트 언어는 자유롭게 다른 프로그램의 기능을 불러와서 하나의 프로그램을 완성할 수 있다.

 

2) JavaScript, Python, Ruby, ...php, jsp, asp

 

 

6. 미래에 대한 예측
- 범용 프로그래밍 언어는 보기 힘들어질 것

- 다양한 스크립트 언어 & 특수목적 언어들의 설계는 계속될 것이다.

 

- 새로운 프로그래밍 패러다임(함수형, 논리형) 프로그래밍 언어의 설계는 계속 시도될 것

- 신뢰도를 높이기 위해서는 수학적으로 증명 필요, 증명하기 위해서는 프로그래밍 언어에 대한 명확한 의미가 정의되어 있어야 함

- 함수형, 논리형 패러다임 언어는 프로그램의 의미를 수학적으로 명확히 정의할 수 있고 스펙에 맞춰 돌아가는지 프로그램을 수학적으로 증명 가능하다.

반응형
Comments