일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- DBMS
- 네트워크
- 42seoul
- 다이어리
- swift
- MySQL
- Spring
- springboot
- 티스토리챌린지
- 프로그래밍언어론
- libasm
- sql
- JPA
- 리눅스
- CI
- 스프링
- 스프링부트
- jenkins
- 인공지능
- 아이패드다이어리
- Xcode
- javascript
- 오블완
- 스프링부트 웹 소켓
- 소켓
- 데이터베이스
- AI
- CD
- IOS
- 오라클
- Today
- Total
Hi yoahn 개발블로그
#2 프로그래밍 언어 개발의 역사 본문
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. 미래에 대한 예측
- 범용 프로그래밍 언어는 보기 힘들어질 것
- 다양한 스크립트 언어 & 특수목적 언어들의 설계는 계속될 것이다.
- 새로운 프로그래밍 패러다임(함수형, 논리형) 프로그래밍 언어의 설계는 계속 시도될 것
- 신뢰도를 높이기 위해서는 수학적으로 증명 필요, 증명하기 위해서는 프로그래밍 언어에 대한 명확한 의미가 정의되어 있어야 함
- 함수형, 논리형 패러다임 언어는 프로그램의 의미를 수학적으로 명확히 정의할 수 있고 스펙에 맞춰 돌아가는지 프로그램을 수학적으로 증명 가능하다.
'sswu > 프로그래밍언어론' 카테고리의 다른 글
#4 데이터 타입과 제어 구조 (0) | 2020.06.29 |
---|---|
#3 프로그래밍 언어 설계의 원칙, 구문 정의, 기초 의미론 (0) | 2020.06.29 |
#1 프로그래밍언어론 - 추상화 (0) | 2020.05.24 |