Jump to content

Computer programming

This is a fully translated article. Click here for more information.
From DawoumWiki, the free Mathematics self-learning

컴퓨터 프로그래밍은 보통 실행 가능한 컴퓨터 프로그램을 설계하고 구축함으로써 특정 계산을 수행하는 (또는 보다 일반적으로, 특정 계산 결과를 달성하는) 과정입니다. 프로그래밍은 분석, 알고리듬 생성, 알고리듬의 정확도와 자원 소비 프로파일링, 및 알고리듬 구현 (공통적으로 코딩으로 참조됨, 보통 선택된 프로그래밍 언어에서 구현)과 같은 임무를 포함합니다.[1][2] 프로그램의 소스 코드중앙 처리 장치에 의해 직접 실행되는 기계 코드가 아니라 프로그래머가 이해할 수 있는 하나 이상의 언어로 작성됩니다. 프로그래밍의 목적은 종종 주어진 문제를 해결하기 위해 컴퓨터에서 임무 (운영 시스템만큼 복잡할 수 있음)의 수행을 자동화하려는 일련의 명령을 찾는 것입니다. 능숙한 프로그래밍은 따라서 보통 응용 프로그램 영역, 특수 알고리듬, 및 형식적 논리에 대한 지식을 포함하여 여러 다른 주제에 전문 지식을 필요로 합니다.

프로그래밍과 관련된 임무는 테스팅, 디버깅, 소스 코드 유지 관리, 빌드 시스템의 구현, 및 컴퓨터 프로그램의 기계어 코드와 같은 파생 아티팩트의 관리를 포함합니다. 이것들은 프로그래밍 과정의 일부로 고려될 수 있지만, 종종 소프트웨어 개발이라는 용어는 실제 코드 작성을 위해 예약된 프로그래밍, 구현, 또는 코딩이라는 용어와 함께 이러한 더 큰 과정에 사용됩니다. 소프트웨어 공학공학 기술과 소프트웨어 개발 실무를 결합합니다. 역 공학은 설계자, 분석가, 및 프로그래머에 의해 기존 프로그램을 이해하고 그것의 기능을 재구현하기 위해 사용되는 관련된 과정입니다.[3]

History

Ada Lovelace, whose notes added to the end of Luigi Menabrea's paper included the first algorithm designed for processing by an Analytical Engine. She is often recognized as history's first computer programmer.

프로그래밍 가능한 장치는 수세기 동안 존재해 왔습니다. 이미 9세기에 프로그래밍 가능한 음악 시퀀서는 페르시아의 Banu Musa 형제에 의해 발명되었으며, 그는 Book of Ingenious Devices에서 자동화된 기계식 플루트 연주자를 설명했습니다.[4][5] 1206년에 아랍 엔지니어 Al-Jazari는 못과 을 통해 다양한 리듬과 드럼 패턴을 연주하도록 음악 기계를 만들 수 있는 프로그래밍 가능한 드럼 머신을 발명했습니다.[6][7] 1801년에, Jacquard loom는 구멍이 뚫린 일련의 판지 카드인 "프로그램"을 변경함으로써 완전히 다른 직조물을 생산할 수 있었습니다.

코드-해독(Code-breaking) 알고리듬도 수세기 동안 존재해 왔습니다. 9세기에, 아랍 수학자 Al-KindiA Manuscript on Deciphering Cryptographic Messages에서 암호화된 코드를 해독하기 위한 암호화 알고리듬을 설명했습니다. 그는 최초의 암호 해독 알고리듬인 빈도 해석(frequency analysis)에 의한 암호 분석에 대한 첫 번째 설명을 제공했습니다.[8]

최초의 컴퓨터 프로그램은 일반적으로 수학자 Ada LovelaceCharles Babbage해석적 엔진(Analytical Engine)에 의해 수행되도록 의도된 베르누이 숫자의 수열을 계산하기 위한 알고리듬(algorithm)을 발표한 1843년으로 거슬러 올라갑니다.[9]

1880년대에 Herman Hollerith는 기계가 읽을 수 있는 형식으로 데이터(data)를 저장하는 개념을 발명했습니다.[10] 나중에 그의 1906년 Type I Tabulator에 추가된 제어 패널 (플러그 보드)은 다른 작업을 위해 프로그래밍할 수 있게 했었고, 1940년대 후반에는 IBM 602IBM 604와 같은 단위 기록 장비가 최초의 전자 컴퓨터와 마찬가지로 유사한 방법에서 제어 패널에 의해 프로그래밍되었습니다. 어쨌든, 1949년에 도입된 프로그램-저장 컴퓨터의 개념과 함께, 프로그램과 데이터는 모두 컴퓨터 메모리에 같은 방법으로 저장되고 조작됩니다.[11]

Data and instructions were once stored on external punched cards, which were kept in order and arranged in program decks.

Machine language

기계 코드는 종종 이진 표기법(binary notation)으로 특정 기계의 명령어 집합으로 작성된 초기 프로그램의 언어였습니다. 프로그래머가 명령을 텍스트 형식 (예를 들어, ADD X, TOTAL)으로 지정할 수 있도록 하는 어셈블리 언어가 곧 개발되었으며, 각 연산 코드에 대한 약어와 주소를 지정하기 위한 의미 있는 이름을 가졌습니다. 어쨌든, 어셈블리 언어는 기계어에 대한 다른 표기법에 불과하기 때문에, 다른 명령어 집합을 갖는 두 기계는 다른 어셈블리 언어를 가집니다.

Wired control panel for an IBM 402 Accounting Machine. Wires connect pulse streams from the card reader to counters and other internal logic and ultimately to the printer.

Compiler languages

고급 언어는 프로그램 개발 과정을 더 단순하고 이해하기 쉽게 만들었고, 놓여있는 하드웨어에 덜 구속되었습니다. 최초의 컴파일러 관련 도구, A-0 시스템은 1952년[12] '컴파일러'라는 용어를 만든 Grace Hopper에 의해 개발되었습니다.[13][14] 기능 구현을 위해 널리 사용되는 최초의 고급 언어, FORTRAN이 1957년에 나왔고,[15] 많은 다른 언어가 곧 개발되었습니다. 특히 상업용 데이터 처리를 목표로 하는 COBOL과 컴퓨터 연구를 위한 Lisp이 개발되었습니다.

이들 컴파일된 언어는 프로그래머에게 구문적으로 더 풍부하고, 코드를 추상화할 수 있는 능력을 갖는 용어로 프로그램을 작성하는 것을 허용하여, 컴파일 선언과 휴리스틱을 통해 다양한 기계 명령어 집합을 쉽게 대상으로 지정할 수 있습니다. 컴파일러는 프로그래머가 중위 표기법을 사용하여 공식을 입력하여 계산을 지정할 수 있게 함으로써 프로그래밍을 더 쉽게 만들기 위해 컴퓨터의 능력을 활용했습니다.[15]

Source code entry

프로그램은 주로 천공 카드나 종이 테이프를 사용하여 입력되었습니다. 1960년대 후반에는, 데이터 저장 장치와 컴퓨터 터미널이 컴퓨터에 직접 입력함으로써 프로그램을 만들 수 있을 정도로 저렴해졌습니다. 펀치 카드보다 훨씬 쉽게 변경과 수정을 수행할 수 있는 텍스트 편집기가 역시 개발되었습니다.

Modern programming

Quality requirements

개발에 대한 접근 방식이 무엇이든, 최종 프로그램은 몇 가지 기본 속성을 만족시켜야 합니다. 다음 속성이 여러 속성 중에서 가장 중요합니다:[16][17]

  • 신뢰성(Reliability): 프로그램의 결과가 얼마나 자주 정확한가. 이것은 자원 관리의 실수 (예를 들어, 버퍼 오버플로경쟁 조건) 및 논리 오류 (예를 들어, 영에 의한 나눗셈 또는 off-by-one errors)와 같은 프로그래밍 실수의 최소화와 알고리듬의 개념적 정확성에 달려 있습니다.
  • 견고성(Robustness): 프로그램이 오류 (버그가 아님)로 인한 문제를 얼마나 잘 예측하는지. 이것은 부정확, 부적절 또는 손상된 데이터, 메모리, 운영 시스템 서비스와 네트워크 연결과 같은 필요한 자원의 사용 불가능, 사용자 오류, 및 예기치 않은 정전과 같은 상황을 포함합니다.
  • 사용성(Usability): 프로그램의 인체 공학(ergonomics): 의도된 목적 또는 일부 경우에서 예상치 못한 목적을 위해 프로그램을 사용할 수 있는 사람이 갖는 용이성. 그러한 문제는 다른 문제와 상관없이 성공 여부를 결정할 수 있습니다. 여기에는 프로그램 사용자 인터페이스의 명확성, 직관성, 응집력, 및 완전성을 향상시키는 광범위한 텍스트, 그래픽 및 때로는 하드웨어 요소를 포함합니다.
  • 이식성(Portability): 프로그램의 소스 코드를 컴파일/해석하고 실행할 수 있는 컴퓨터 하드웨어와 운영 시스템 플랫폼의 범위. 이것은 하드웨어와 운영 시스템 자원, 하드웨어와 운영 시스템의 예상 동작, 및 소스 코드 언어에 대한 플랫폼별 컴파일러 (때로는 라이브러리)의 가용성을 포함하여 다양한 플랫폼에서 제공하는 프로그래밍 기능의 차이에 따라 다릅니다.
  • 유지관리성(Maintainability): 개선을 수행하거나 버그와 보안 허점을 수정하거나 새로운 환경에 적응시키기 위해 현재 또는 미래의 개발자가 프로그램을 수정할 수 있는 용이성. 초기 개발 중 모범 사례는 이와 관련하여 차이를 만듭니다.[18] 이 품질은 최종 사용자에게 직접적으로 나타나지 않을 수 있지만 장기적으로 프로그램의 운명에 상당한 영향을 미칠 수 있습니다.
  • 효율성(Efficiency)/성능(performance): 프로그램이 소비하는 시스템 자원의 측정값 (프로세서 시간, 메모리 공간, 디스크와 같은 느린 장치, 네트워크 대역폭 및 어느 정도는 사용자 상호 작용까지 포함): 적을수록 좋습니다. 여기에는 임시 파일 정리와 메모리 누수 제거와 같은 자원의 세심한 관리도 포함됩니다. 이것은 종종 선택된 프로그래밍 언어의 그늘 아래서 논의됩니다. 언어가 성능에 확실히 영향을 미치지만 Python과 같은 느린 언어도 인간의 관점에서 즉시 프로그램을 실행할 수 있습니다. 속도, 자원 사용, 및 성능은 시스템 병목 현상을 일으키는 프로그램에 중요하지만 프로그래머 시간의 효율적인 사용도 중요하며 비용과 관련이 있습니다: 더 좋은 하드웨어가 더 저렴할 수 있습니다.

Readability of source code

컴퓨터 프로그래밍에서, 가독성은 인간 독자가 소스 코드의 목적, 제어 흐름, 및 작동을 이해할 수 있는 용이성을 의미합니다. 그것은 휴대성, 사용성, 및 가장 중요한 유지 관리성을 포함하여 위의 품질 측면에 영향을 미칩니다.

프로그래머는 새로운 소스 코드를 작성하는 것보다 기존 소스 코드를 읽고 이해하려고 시도하고 재사용하고 수정하기 위해 대부분의 시간을 보내기 때문에 가독성이 중요합니다. 읽을 수 없는 코드는 종종 버그, 비효율성, 및 중복 코드로 이어집니다. 연구에 따르면 몇 가지 간단한 가독성 변환으로 코드가 더 짧아지고 코드를 이해하는 시간이 크게 단축되었습니다.[19]

일관된 프로그래밍 스타일을 따르면 종종 가독성에 도움이 됩니다. 어쨌든, 가독성은 프로그래밍 스타일 그 이상입니다. 코드를 효율적으로 컴파일하고 실행하는 컴퓨터의 능력과 거의 또는 전혀 관련이 없는 많은 요소가 가독성에 기여합니다.[20] 이러한 요인 중 일부는 다음을 포함합니다:

이것의 프레젠테이션 측면 (예를 들어, 들여쓰기, 줄 바꿈, 색상 강조 표시, 등)은 종종 소스 코드 편집기에서 처리되지만 내용 측면은 프로그래머의 재능과 기술을 반영합니다.

코드 구조와 표시에 대한 비-전통적인 접근 방식을 채택함으로써 가독성 문제를 해결하기 위해 다양한 시각적 프로그래밍 언어도 개발되어 왔습니다. 통합 개발 환경(IDE)은 모든 그러한 도움말을 통합하는 것을 목표로 합니다. 코드 리팩토링과 같은 기술은 가독성을 향상하게 시킬 수 있습니다.

Algorithmic complexity

학문 분야와 컴퓨터 프로그래밍의 공학 실무는 둘 다 주어진 문제 클래스에 대해 가장 효율적인 알고리듬을 발견하고 구현하는 데 주로 관심이 있습니다. 이를 위해, 알고리듬은 실행 시간이나 메모리 사용량 등의 자원 사용량을 입력의 크기로 표현하는 이른바 Big O 표기법을 사용하여 순서(orders)로 분류됩니다. 전문 프로그래머는 잘 정립된 다양한 알고리듬과 각각의 복잡성에 익숙하고 이 지식을 사용하여 상황에 가장 적합한 알고리듬을 선택합니다.

Chess algorithms as an example

"Programming a Computer for Playing Chess"는 알고리듬 복잡성의 역사의 일부인 "minimax" 알고리듬을 평가한 1950년 논문이었습니다; IBM의 Deep Blue (체스 컴퓨터) 과정은 스탠포드 대학교의 컴퓨터 과학 교육 과정의 일부입니다.[21]

Methodologies

대부분의 공식 소프트웨어 개발 프로세스의 첫 번째 단계는 요구 사항 분석이며, 그 다음에는 가치 모델링, 구현, 및 오류 제거 (디버깅)를 결정하기 위한 테스트를 수행합니다. 각 임무에는 다양한 접근 방식이 있습니다. 요구 사항 분석에 널리 사용되는 한 가지 접근 방식은 사용 사례(Use Case) 분석입니다. 많은 프로그래머는 공식 소프트웨어 개발의 다양한 단계가 몇 년이 아닌 몇 주가 걸리는 짧은 사이클로 함께 통합되는 애자일 소프트웨어 개발 형태를 사용합니다. 소프트웨어 개발 과정에는 여러 가지 접근 방식이 있습니다.

인기 있는 모델링 기술에는 객체 지향 분석 및 설계 (OOAD) 및 모델 기반 아키텍처(MDA)를 포함합니다. 통합된 모델링 언어(Unified Modeling Language, 줄여서 UML)은 OOAD와 MDA 모두에 사용되는 표기법입니다.

데이터베이스 설계에 사용되는 유사한 기술은 엔터디-관계 모델링(Entity-Relationship Modeling, 줄여서 ER Modeling)입니다.

구현 기술에는 명령형 언어 (객체 지향 또는 절차), 함수형 언어, 및 논리 언어를 포함합니다.

Measuring language usage

가장 인기 있는 현대 프로그래밍 언어가 무엇인지 결정하는 것은 매우 어렵습니다. 프로그래밍 언어 인기도를 측정하는 방법은 다음과 같습니다: 해당 언어를 언급하는 구인 광고의 수,[22] 판매된 책의 수와 해당 언어를 가르치는 과정 (이는 새로운 언어의 중요성을 과대평가함), 및 기존 줄 수 추정 언어로 작성된 코드의 수 (이는 COBOL과 같은 비즈니스 언어 사용자 수를 과소평가함).

일부 언어는 특정 종류의 응용 프로그램에 매우 널리 사용되는 반면 일부 언어는 다양한 종류의 응용 프로그램을 작성하는 데 정기적으로 사용됩니다. 예를 들어 COBOL은 대규모 메인프레임 컴퓨터의 기업 데이터 센터,[23] Fortran은 공학 응용 프로그램, 스크립팅 언어(scripting languages)는 웹 개발, 및 C는 임베디드 소프트웨어에서 여전히 강력합니다. 많은 응용 프로그램은 구성과 사용에 여러 언어를 혼합하여 사용합니다. 새로운 언어는 일반적으로 새로운 기능이 추가된 이전 언어의 구문을 중심으로 설계됩니다. 예를 들어 C++는 C에 객체-지향을 추가하고 Java는 C++에 메모리 관리와 바이트코드를 추가하지만, 결과적으로 효율성과 낮은-레벨 조작에 대해 능력을 잃었습니다).

Debugging

The first known actual bug causing a problem in a computer was a moth, trapped inside a Harvard mainframe, recorded in a log book entry dated September 9, 1947.[24] "Bug" was already a common term for a software defect when this insect was found.

디버깅은 소프트웨어 개발 프로세스에서 매우 중요한 임무인데 왜냐하면 프로그램에 결함이 있으면 사용자에게 심각한 결과를 초래할 수 있기 때문입니다. 일부 언어는 사양에 따라 컴파일러가 다른 언어만큼 많은 검사를 수행할 필요가 없기 때문에 일부 종류의 오류가 발생하기 쉽습니다. 정적 코드 분석 도구를 사용하면 몇 가지 가능한 문제를 감지하는 데 도움이 될 수 있습니다. 전형적으로 디버깅의 첫 번째 단계는 문제를 재현하려고 시도하는 것입니다. 이것은 예를 들어 병렬 프로세스 또는 일부 비정상적인 소프트웨어 버그와 같이 사소하지 않은 임무가 될 수 있습니다. 역시, 특정 사용자 환경과 사용 이력으로 인해 문제의 재현이 어려울 수 있습니다.

버그가 재현된 후, 디버그하기 쉽게 만들기 위해 프로그램 입력을 단순화해야 할 수 있습니다. 예를 들어, 컴파일러에서 버그는 일부 큰 소스 파일을 구문 분석할 때 충돌을 만들 수 있으며, 원래 소스 파일에서 몇 줄만 생성하는 테스트 사례를 단순화하면 같은 충돌을 재현하기에 충분할 수 있습니다. 시행-과-착오/분할-과-정복이 필요됩니다: 프로그래머는 원래 테스트 케이스의 일부를 제거하려고 시도하고 문제가 여전히 존재하는지 확인합니다. GUI에서 문제를 디버깅할 때, 프로그래머는 원래 문제 설명에서 일부 사용자 상호 작용을 건너뛰고 나머지 작업이 버그가 표시되기에 충분한지 확인할 수 있습니다. 스크립팅과 중단점 지정도 이 프로세스의 일부입니다.

디버깅은 종종 IDE로 수행됩니다. GDB와 같은 독립형 디버거도 사용되고, 이것들은 보통 명령-줄을 사용하여 종종 시각적 환경을 덜 제공합니다. Emacs와 같은 일부 텍스트 편집기는 시각적 환경을 제공하기 위해 그것들을 통해 GDB를 호출할 수 있습니다.

Programming languages

서로 다른 프로그래밍 언어는 서로 다른 스타일의 프로그래밍을 지원합니다 (프로그래밍 패러다임(programming paradigms)이라고 불립니다). 사용되는 언어 선택은 회사 정책, 임무에 대한 적합성, 타사 패키지의 사용 가능성, 또는 개인의 선호도와 같은 많은 고려 사항에 따라 달라집니다. 이상적으로, 당면한 임무에 가장 적합한 프로그래밍 언어가 선택될 것입니다. 이러한 이상과의 상충 관계에는 팀을 구성할 언어를 알고 있는 충분한 프로그래머를 찾는 것, 해당 언어에 대한 컴파일러의 사용 가능성, 및 주어진 언어로 작성된 프로그램이 실행되는 효율성을 포함합니다. 언어는 "낮은 수준"에서 "높은 수준"까지 대략적인 스펙트럼을 형성합니다; "낮은 수준" 언어는 전형적으로 더 기계-지향적이고 실행 속도가 빠른 반면, "높은 수준" 언어는 더 추상적이고 사용하기 쉽지만 실행 속도는 떨어집니다. 보통 "낮은 수준" 언어보다 "높은 수준" 언어로 코딩하는 것이 더 쉽습니다. 프로그래밍 언어는 소프트웨어 개발에 필수적입니다. 가장 단순한 응용 프로그램에서 가장 정교한 응용 프로그램에 이르기까지 모든 소프트웨어의 빌딩 블록입니다.

Allen Downey은, 그의 책 How To Think Like A Computer Scientist에서, 다음이라고 썼습니다:

세부 사항은 언어마다 다르게 보이지만, 거의 모든 언어로 몇 가지 기본 지침이 나타납니다:
  • 입력: 키보드, 파일, 또는 기타 장치에서 데이터를 수집합니다.
  • 출력: 화면에 데이터를 표시하거나 파일이나 다른 장치로 데이터를 보냅니다.
  • 산술: 덧셈 및 곱셈과 같은 기본 산술 연산을 수행합니다.
  • 조건부 실행: 특정 조건을 확인하고 적절한 순서의 명령문을 실행합니다.
  • 반복: 보통 약간의 변형을 가하여 일부 행동을 반복적으로 수행합니다.

많은 컴퓨터 언어는 공유 라이브러리에 의해 제공되는 함수를 호출하는 메커니즘을 제공합니다. 라이브러리의 함수가 적절한 런타임 규칙 (예를 들어, 인수 전달 방법)을 따르면, 이들 함수는 다른 언어로 작성될 수 있습니다.

Programmers

컴퓨터 프로그래머는 컴퓨터 소프트웨어를 작성하는 사람입니다. 그들의 직무는 보통 다음을 포함합니다:

비록 미디어에서 프로그래밍이 다소 수학적 주제로 소개되어 왔지만, 일부 연구에 따르면 우수한 프로그래머는 자연어에 대한 강력한 기술을 보유하고 있고, 코딩을 배우는 것은 외국어를 배우는 것과 유사합니다.[25]

See also

References

  1. ^ Bebbington, Shaun (2014). "What is coding". Tumblr. Archived from the original on 2020-04-29. Retrieved 2014-03-03.
  2. ^ Bebbington, Shaun (2014). "What is programming". Tumblr. Archived from the original on 2020-04-29. Retrieved 2014-03-03.
  3. ^ Eliam, Eldad (2005). Reversing: Secrets of Reverse Engineering. Wiley. p. 3. ISBN 978-0-7645-7481-8.
  4. ^ Koetsier, Teun (2001), "On the prehistory of programmable machines: musical automata, looms, calculators", Mechanism and Machine Theory, 36 (5), Elsevier: 589–603, doi:10.1016/S0094-114X(01)00005-2.
  5. ^ Kapur, Ajay; Carnegie, Dale; Murphy, Jim; Long, Jason (2017). "Loudspeakers Optional: A history of non-loudspeaker-based electroacoustic music". Organised Sound. 22 (2). Cambridge University Press: 195–205. doi:10.1017/S1355771817000103. ISSN 1355-7718.
  6. ^ Fowler, Charles B. (October 1967). "The Museum of Music: A History of Mechanical Instruments". Music Educators Journal. 54 (2): 45–49. doi:10.2307/3391092. JSTOR 3391092. S2CID 190524140.
  7. ^ Noel Sharkey (2007), A 13th Century Programmable Robot, University of Sheffield
  8. ^ Dooley, John F. (2013). A Brief History of Cryptology and Cryptographic Algorithms. Springer Science & Business Media. pp. 12–3. ISBN 9783319016283.
  9. ^ Fuegi, J.; Francis, J. (2003). "Lovelace & Babbage and the Creation of the 1843 'notes'". IEEE Annals of the History of Computing. 25 (4): 16. doi:10.1109/MAHC.2003.1253887.
  10. ^ da Cruz, Frank (2020-03-10). "Columbia University Computing History – Herman Hollerith". Columbia University. Columbia.edu. Archived from the original on 2020-04-29. Retrieved 2010-04-25.
  11. ^ "Memory & Storage | Timeline of Computer History | Computer History Museum". www.computerhistory.org. Retrieved 3 June 2021.
  12. ^ Ridgway, Richard (1952). "Compiling routines". Proceeding ACM '52 Proceedings of the 1952 ACM National Meeting (Toronto). ACM '52: 1–5. doi:10.1145/800259.808980. ISBN 9781450379250. S2CID 14878552.
  13. ^ Maurice V. Wilkes. 1968. Computers Then and Now. Journal of the Association for Computing Machinery, 15(1):1–7, January. p. 3 (a comment in brackets added by editor), "(I do not think that the term compiler was then [1953] in general use, although it had in fact been introduced by Grace Hopper.)"
  14. ^ [1] The World's First COBOL Compilers Archived 13 October 2011 at the Wayback Machine
  15. ^ a b Bergstein, Brian (2007-03-20). "Fortran creator John Backus dies". NBC News. Archived from the original on 2020-04-29. Retrieved 2010-04-25.
  16. ^ "NIST To Develop Cloud Roadmap". InformationWeek. November 5, 2010. Computing initiative seeks to remove barriers to cloud adoption in security, interoperability, portability and reliability.
  17. ^ "What is it based on". ComputerWorld. April 9, 1984. p. 13. Is it based on ... Reliability Portability. Compatibility
  18. ^ "Programming 101: Tips to become a good programmer - Wisdom Geek". Wisdom Geek. May 19, 2016. Retrieved 2016-05-23.
  19. ^ Elshoff, James L.; Marcotty, Michael (1982). "Improving computer program readability to aid modification". Communications of the ACM. 25 (8): 512–521. doi:10.1145/358589.358596. S2CID 30026641.
  20. ^ Multiple (wiki). "Readability". Docforge. Archived from the original on 2020-04-29. Retrieved 2010-01-30.
  21. ^ Piech, Chris. "Deep Blue". In 1950, Claude Shannon published ... "Programming a Computer for Playing Chess", ... "minimax" algorithm
  22. ^ Enticknap, Nicholas (11 September 2007). "SSL/Computer Weekly IT salary survey: finance boom drives IT job growth".
  23. ^ Mitchell, Robert (2012-05-21). "The Cobol Brain Drain". Computer World. Retrieved 9 May 2015.
  24. ^ "Photograph courtesy Naval Surface Warfare Center, Dahlgren, Virginia, from National Geographic Sept. 1947". July 15, 2020.
  25. ^ Prat, Chantel S.; Madhyastha, Tara M.; Mottarella, Malayka J.; Kuo, Chu-Hsuan (2020-03-02). "Relating Natural Language Aptitude to Individual Differences in Learning Programming Languages". Scientific Reports. 10 (1): 3817. Bibcode:2020NatSR..10.3817P. doi:10.1038/s41598-020-60661-8. ISSN 2045-2322. PMC 7051953. PMID 32123206.

Sources

Further reading

  • A.K. Hartmann, Practical Guide to Computer Simulations, Singapore: World Scientific (2009)
  • A. Hunt, D. Thomas, and W. Cunningham, The Pragmatic Programmer. From Journeyman to Master, Amsterdam: Addison-Wesley Longman (1999)
  • Brian W. Kernighan, The Practice of Programming, Pearson (1999)
  • Weinberg, Gerald M., The Psychology of Computer Programming, New York: Van Nostrand Reinhold (1971)
  • Edsger W. Dijkstra, A Discipline of Programming, Prentice-Hall (1976)
  • O.-J. Dahl, E.W.Dijkstra, C.A.R. Hoare, Structured Programming, Academic Press (1972)
  • David Gries, The Science of Programming, Springer-Verlag (1981)

External links