プログラミング（）とは、コンピュータのプログラムを作成することである。
概説 通常、プログラムを設計し、それをプログラミング言語によって記述し、期待どおりに動くかテストを行い、誤り（バグ）を発見し、プログラムの修正を行うことまで含めていう。
高水準のプログラミング言語が作られる以前は全て、バイナリ（2進数）の機械語で書いたり、あるいは命令を数文字のアルファベットで表記したニーモニックで書いてそれを手作業でバイナリに変換するということが行われていた。現在では機械語やニーモニックでプログラミングが行われることは減ったが、ハードウェア寄りの部分（そして性能に大きく影響するきわめて重要な部分）では機械語やニーモニックでプログラミングが行われている。
プログラミング関連のタスクを、アルゴリズムの作成、アルゴリズムの正確さやリソースの消費量の評価、選択したプログラミング言語でのアルゴリズムの実装などと捉える方法がある（これは一般にコーディング（英語:coding）と呼ばれる）。
ハードウェア開発と対比してソフトウェア開発とも呼ばれる。
プログラミング関連の作業には、テスト、デバッグ、ソースコードのメンテナンス、ビルドシステムの構築、生成されたアーティファクト（機械語コードなど）の管理などがある。これらの作業も広義のプログラミングの一部と考えられる。
プログラミングを行う人をプログラマやソフトウェア開発者という。
歴史 前史 1801年に開発されたジャカード織機がプログラマブルな機械の起源とされることが多い。この機械は、穴を開けた一連の厚紙（パンチカードの原型）を使った。穴の配列が布を織る際ののパターンに対応している。従って、カードを入れ替えることで全く異なる模様の布を織ることができた。ジャカード織機は次に述べる解析機関のヒントを与えたという点で、プログラマブルな「計算機」の起源を遡った所にあると言える。
なお"最古のプログラマブルな機械"と呼んでよいかも知れないものは、1206年にアル＝ジャザリが作った二足歩行ロボットとも言われている。アル・ジャザリのロボットは、ボートに4体の演奏人形が乗ったもので、宮廷のパーティで池に浮かべて音楽を演奏したと言われている。プログラムはカムにあり、それによって小さなてこを押して、打楽器を演奏する。カムは実際には円筒にペグが突き刺された形であり、このペグの配置でプログラミングし、演奏パターンを変更したA 13th Century Programmable Robot. University of Sheffield.。
解析機関とアルゴリズム ジャカード織機とパンチカードが広まったことが、計算機を進化させる上で大きなヒントになった。 1830年ごろには、チャールズ・バベッジがパンチカードを使った解析機関を考案した。 は解析機関についての解説を刊行し、エイダ・ラブレスはその翻訳にあたり膨大な注を付けた。その中には、解析機関での処理のために設計された最初のアルゴリズムについて書かれたメモもあり、彼女は "史上初のコンピュータプログラマ" と考えられている。
プラグボード式 このような先駆者の発明をさらに発展させたのがハーマン・ホレリスであり、1896年にタビュレイティング・マシン・カンパニー（、後のIBM） を設立した。彼はホレリス式パンチカード、タビュレーティングマシン、キーパンチ機などを発明した。これらの発明が情報処理産業の基礎となったのである。
1906年には、タビュレーティングマシンにプラグボードを追加することで、配線を組み替えて様々な仕事ができるようになった。これがプログラミングへの第一歩となった。1940年代には、プラグボードで配線を変更することで動作を変更できる電子的装置が登場し、初期のコンピュータにもプラグボードで動作を決めるものがあった。日本において、一種のインタプリタをプラグボード上の配線で実装した、という「ハック」が伝えられているhttps://museum.ipsj.or.jp/guide/pdf/article/IPSJ-MGN240314.pdf に言及がある「島内武彦の万能計算盤」。。
プログラム内蔵方式 1944年8月にジョン・モークリーとジョン・プレスパー・エッカートが、（当時開発中のENIACの設計を参考にしつつも）新たに高速な遅延記憶装置を使うコンピュータの開発を提案。これは記憶装置を持ちプログラムを記憶できプログラミングが可能なコンピュータで、これが大きな転換点となった。1946年4月に弾道研究所と開発契約が締結され名前はEDVACに決まった。命令語長が44 ビット。命令部（オペコード部）は最初の 4 ビットで、どの操作（加算、減算、乗算など）を実行するかを指定する。残りの 40 ビットはアドレス部で、4つのアドレスを表現するフィールドに割り当てられている（各アドレス 10 ビットずつ）。オペコードの種類としては、基本は加算、減算、乗算、除算、比較、抽出、浮動小数点操作で、ほかにHALT（停止）に割り当てられる未使用命令もあり、最大で16種のオペコードが使える設計で、実際には12種が使われた。EDVACのプログラミングは紙とペンで行われた。紙の上で綿密に命令を設計し、それをバイナリコード（2進数）として記述。入力はそのバイナリコードのパンチカードを作成し読み込ませた。なお、モークリーやエッカートが発明したプログラミング可能なこのアーキテクチャを、そのプロジェクトにコンサルタントとして参加していたフォン・ノイマンがアカデミックな書式の文書にまとめ自分の名（ばかり）を署名して流布させた結果、本当の発明者2人の名が陰に入ってしまい、文書をまとめた人物のほうの名が広まりプログラム内蔵方式のコンピュータは "ノイマン型" と呼ばれるようになった。
紙とペンを使い2進数機械語のコードを並べて行い、入力方法としては穿孔カードや鑽孔テープが利用された他、スイッチなどで直接入力したが、機械語の命令は0と1が大量に並び、人間には直感的には意味が不明で、かなり扱いづらく、書き写しのミスも発生しがちでストレスが大きい。
EDSACの order EDVACの組み立てがもたつき1951年までかかる間に、EDSACの組み立てがEDVACを追い抜き1949年に完成した。EDSACではモーリス・ウィルクスらが機械語（バイナリ）の代わりにアルファベット1文字を使い表現することをやり始め、バイナリより理解しやすくなった（正確には、命令を表す（現在で言う）オペコードを、紙テープ上のアルファベットの文字コードに一致させることで、例えば文字Aなら加算、文字Sなら減算、といったようにわかりやすく設計した。またアドレスの指定も紙テープ上では十進法で文字として入力される詳細は EDSAC initial orders などと検索すること。）。これがニーモニックやアセンブリ言語の起源となった。なお以下は単なる用語の問題だが、彼らはその命令（現在で言う instruction）を order と呼んだ。
ニーモニックとアセンブラによるプログラミングの源流 1951年の前半にナサニエル・ロチェスター（Nathaniel Rochester）がIBM 701用に、アルファベット数文字で略記した命令の一式を作成し、それを機械語に変換するためのプログラムも作成した。これのおかげで、略語表記の命令と数値やアドレスを並べてコンピュータのプログラミングができるようになった。これがアセンブラの源流であり、ロチェスターは "世界初のアセンブラを設計・実装した人物" とされている。 IBM 701のニーモニックは次のようなものだったとされる。ニーモニック、ニーモニックのもとの英語表現、説明の順に示す。 STOP （Stop） - プロセッサを停止し、以降の命令は実行しない。 TR （Transfer） - プログラムカウンタ（PC）を、有効アドレス（EA）に設定（無条件ジャンプ） TR OV （Transfer on Overflow） - オーバーフローが発生していればプログラムカウンタ（PC）← EA。有効アドレスの値をプログラムカウンタに入れる。すなわち条件ジャンプ。 TR + （Transfer Positive） - アキュムレータ（AC）が正（>0）のとき、PC←EA。 TR 0 （Transfer Zero） - ACが0のとき、PC ← EA。 SUB （Subtract） - AC ← AC -メモリ値。ACからメモリ値を引き、ACに入れる。普通の減法。 R SUB （Reset Subtract） - ACを一旦0にリセットし、その後、AC ← -メモリ値。メモリ値の符号を反転してACに入れる。 SUB AB （Subtract Absolute） - AC ← AC-|メモリ値|。メモリの値が正でも負でも、その絶対値を使って減算。 上はニーモニックの一部。IBM 701は設計上、32種（後期には33種）の機械語命令を持っていたので、ニーモニックも30種前後用意したと言われている。そして何度か改良され、時期により若干異なるとされる。IBM 701のニーモニックの多くが、その後のニーモニックの原型になった。
ニーモニックによるプログラミングの定着 おおむね次のようなニーモニックが定着することになった。ニーモニック、ニーモニックのもとの英語表現、説明の順に示す。 LDA （Load Accumulator） - 指定アドレスからレジスタへデータを読み込む STA （Store Accumulator） - レジスタの内容を指定アドレスに格納（せよ） ADD （Add） - 加算（せよ） SUB (Subtract） - 減算（せよ） MPY （Multiply） - 乗算（せよ） DIV （Divide） - 除算（せよ） JMP （Jump） - （条件なしで）ジャンプせよ JAZ （Jump if Accumulator Zero） - ACCがゼロならジャンプ（せよ） HLT （Halt） - プログラムを停止せよ そして例えば次のように書かれた。
ニーモニックによるアセンブリ言語のおかげで、プログラマは、難読ながらも慣れれば一応意味が理解できる形で記述できるようになり、ニーモニックなら編集するのも書き写すのもかなり容易になった。ただし、機械語が異なる新しいコンピュータを開発した場合、最初はアセンブラが存在しないので、アセンブリ言語でプログラミングをしてもコンピュータに入力する直前の段階で、ニーモニック→バイナリの対照表を使って、手作業で紙とペンを使いバイナリへと変換しなければならなかった。
最初の高水準言語 FORTRANによるプログラミング ニーモニックでの開発はバイナリで開発するよりはマシになったものの、まだまだ効率が悪かった。普通の人々が使う数式とはかけ離れた命令を羅列しなければならなく、効率が悪かった。当時、コンピュータで科学技術（物理、工学、核研究など）の計算を大量に行う必要があったが、ニーモニックでのプログラミングは効率が悪く、人件費や開発期間が膨大で、プログラマのストレスも大きかった。IBMのエンジニアたちは、「もっと人間にとって分かりやすい効率的な言語が必要だ」「普段使っている数式（formula）で命令を書きたい」「人間が普段使う言葉（英単語）で命令を記述したい」と考えるようになった。そして1957年にIBMのジョン・バッカス（John Backus）率いるチームによりFORTRANが開発された。FORTRANの名称は「FORmula TRANslation」（" 数式 変換 "）の略で、この名称に彼らの最大の目的がはっきりと表明されている。FORTRANが作られた主要な目的は下記のようなものだった。 数学的な式をそのまま書けるようにする 自然言語に近い表現（英単語）を使う 機械語同等のプログラムを自動生成させる（コンパイラ） それにより同時に次のことも実現する。 プログラミングの生産性向上 プログラムの移植性・保守性の向上 FORTRANではたとえばA, B, Cという3つの数の平均を求める式は次のように書けるようになった。
「(A + B + C) / 3.0」と普通の数式で記述できることが革命的だった。 FORTRANでは変数の型名に続けて変数名を書けば変数を宣言できるようになった。REALは実数を意味する英単語で、「REAL A, B, C, AVG」と書けば実数型の変数 A, B, C, AVG 計4つの宣言。 変数に値を入れることは、=（イコール）で表現し、右辺の計算結果の値を左辺の変数に入れる命令と定めた。
1978年にリリースされたFORTRAN 77ではIF文が導入され、if...then ○○○（もし....なら○○○せよ）と、ますます英語風に書けるようになった。たとえば任意の数を入力させ正、負、ゼロを判定するプログラムは次のように書ける。
高水準言語によるプログラミングの一般化 FORTRANの初版が1957年にリリースされた数年後の1959年ころには、アメリカ国防総省やCODASYL（コーダシル）が主導する形で会計計算を得意とするCOBOLが開発され、その後もさまざまな言語が開発されてゆくことになった。FORTRANのプログラムの記述（あるいは「ソース」）はコンパイラと呼ばれる特別なプログラムで機械語に変換されるが、プログラムの入力は依然としてパンチカードやさん孔テープで行われていた。
1960年前後から1970年にかけて、学界ではALGOLが議論・策定された。ALGOLではこんにちに繋がる多くの事項が議論の対象となった。
1960年代後半、記憶装置や端末の価格が低下してきたことにより、キーボードから直接コンピュータにプログラムを入力できるようになってきた。また同じ頃、コンピュータによる処理対象のデータとしての文書についてもコンピュータを利用して編集されるようになりこれは、タイムシェアリングシステムの発達とも関連する。最初はラインエディタ、続いてスクリーンエディタといった、テキストエディタが開発され、それらによってソースコードがコンピュータ上で編集されるようになった。
対話方式 ところで1958年のLISPの初期版や1964年のダートマスBASICなど、対話方式で、つまりプログラムを入力した環境で即実行できる処理系も増えていった。インタプリタが多いが、ダートマスBASICは即座に高速なコンパイルが行われ実行される環境であった。
ミニコンピュータ メインフレームの時代の次にミニコンピュータの時代が来た。コンピュータの使い方は（次のマイクロコンピュータほどでないにしろ）ここで大きく変わり、UNIXが生まれC言語が生まれた。
マイクロコンピュータでのプログラミング 初期のマイクロコンピュータ（パーソナルコンピュータ）、マイクロプロセッサをCPUとして使い個人でも所有できるようになったばかりのコンピュータの場合、1974年に登場したAltair 8800は最初は、（アセンブラすらなかったので）Intel 8080の機械語でプログラミングし、つまり紙とペンでニーモニック（アセンブリ言語）を書いて、それをニーモニック→機械語（バイナリコード）の対照表を使って自分の目と手で変換（ハンド・アセンブル）し、端末やテープリーダ（大型コンピュータの中古品）を接続して入力した。基本セットではインタフェースカードすらなく端末も接続できず、前面パネルのトグルスイッチのオン/オフで2進数を入力してプログラミングしなければならなかった。翌年にはオプションでアセンブラやAltair BASICが用意され、アセンブリ言語やBASICでプログラミングできるようになった。 1976年のApple Iはかなり安価なのに最初からキーボードやテレビが接続できそれらで入出力できたことが画期的で、はじめユーザはウォズニアックが書いたモニタプログラムを使い、MOS 6502の機械語のプログラムを16進数で1バイトづつRAMに書き込んで使っていたが、1976~77年ころにはウォズニアックが書いたInteger BASICがリリースされBASICで対話方式でプログラミングしカセットテープのレコーダをデータレコーダとして使いプログラムを保存できるようになった。日本で1970年代後半にNECから発売されたTK-80では8080互換CPUの機械語で、TK-80 BS/COMPではBASICで、MZ-80でもZ80の機械語やBASICでプログラミングしプログラムをデータレコーダに保存した。1970年代のマイクロコンピュータは、機械語やBASICでプログラミングすることが主流だった。
こうして目的ごとに、あるいは大型コンピュータやマイクロコンピュータなどコンピュータの種類ごとに、さまざまな工夫をほどこされたコンピュータ言語が多数開発され、コンピュータ言語の種類は数十、数百、数千と増えてゆき、それぞれの路線で発展していった。ひとつの路線は、より抽象化されたプログラミングを可能にする言語であった。抽象化レベルの高い言語はオーバーヘッドも大きいが、コンピュータのハードウェア性能の向上の速度も大きかったので、多少オーバーヘッドが増えても同等あるいはむしろ高性能な動作が実現された。このような抽象化レベルの高い言語の利点は、習得が容易であることと、プログラム作成時間が短縮されること。プログラムというのは、プログラミングに数日や数ヶ月を要するのに、その実行は数分や数時間でしかない、というものが多い。つまり抽象度の高い言語のおかげで、一番ボトルネックになっているプログラミング作業の時間（人による作業時間）を減らし、人件費を減らすことができた。そして、バッファオーバフローなどの危険性を孕んだプログラムを書くことを防止できるようにもなった。一方、プログラムがコンパクトであることやコンピュータのハードウェア寄りの作業（メモリアドレスを指定して直接的にRAMにアクセスし操作することなど）が求められる分野では高水準言語の中では最も機械語寄りのC言語が好まれ、高速な3D描画が求められる分野ではC++がメイン、プログラミングの入門教育の分野では1970年代や80年代にはBASICが好まれ、2000年代には（速度は速くないのだが）タブによる段組みを使いカッコの多用を回避して記述が直感的に分かりやすいPythonやRubyが好まれるなど、分野ごとに使い分けがされている。
プログラミングの過程 まず、そのプログラムの目的、さらには「本当に解決したい問題は何なのか」ということについて十分な検討が必要である（ワインバーグの著書などを参考のこと）。プログラミングの過程は文書化され、将来の拡張に利用できるため、これは非常に重要なことである。
続いて、全体のスタイルをおおまかに2つに分けると「トップダウン設計」と「ボトムアップ実装」http://catb.org/jargon/html/B/bottom-up-implementation.htmlになる。「なんとかの設計と実装」といったようなタイトルの本が多くあるように、どちらも重要だが、一般に対象についてよくわかっているものについてのプログラミングでは前者のスタイル、よくわかっていない場合は後者のスタイルとする。「設計された通りに実装することは不可能」といった場合に開発体勢の問題などから正しい対処がされないまま、設計と実装がちぐはぐになったプロダクトは悲惨である。また反復型開発では、あまりに大きなプログラムを一方通行のプロセスで書くことは最初から避けるものとされる。
目的のプログラムを書き始める前に、まずテストを書く、というスタイルもある（これを、「テストファースト」という。詳しくは、テスト駆動開発を参照）。あるいは対象が有限オートマトンやプロセス計算など、形式手法的な方法でモデル化できるのであれば、まずはそのようにすべきである（本来はモデル主導というのはそのような意味のはずである）。
最初の段階として、トップダウン設計では軽量プログラミング言語や、非形式的な記述が適している場合には擬似言語（擬似コード）などで全体設計を検討する。ボトムアップ実装では、階層構造の「葉」にあたるサブルーチンの実装を検討するたとえば、アクションゲームで1フレーム中に行わなければならない計算が可能かどうかが、開発の最後までわからなかったりしては困るだろう。。なお、流れ図（フローチャート）はコンピュータの黎明期である1940年代後半に、当時のプログラムは機械語ないし極く単純なアセンブリ言語で読むのも書くのも難しかったことから、補助のために使われその当時には有用性が高く（:en:Herman Goldstine#The First Draftに当時の流れ図がある）、MIXという機械語を使っている教科書『The Art of Computer Programming』などでは使われているが、現代のプログラミング言語でも有用と信じられていることもあるようである。
プログラミングの過程で、ソースコードを記述することを特に指してコーディングという。元々は機械語が符号であること、またはアセンブリ言語のニモニックがまるで暗号みたいである（正確には「コード」は暗号の1分類。コード (暗号) を参照）というところからコンピュータプログラムに「コード」という語が使われ、それを書く作業というきわめて限定された意味の語Planning and Coding of. Problems for an Electronic Computing Instrument という初期の文献がある。だったが、近年はHTMLを書くという意味にも使われるなど濫用され気味である（なお、デモシーンでは機械語のテクニックを駆使して高効率のプログラムを書く、というような本来の意味に近い意味で使われている）。
可能な限り避けたいものではあるが、プログラムにはバグ (bug) の混入が避けられない。場合によっては仕様にバグがあることもある（もっとひどい場合には標準規格のようなものでもバグがある）。デバッグ (debug) とはバグを取る作業であり、プログラミングの過程に必要なものとして見積りなどでは含めておかなければならないただし、デバッグがあることをあてにしてルーズにプログラムを書くことは厳に戒められねばならない。バグにも種類があり、たとえば、インタプリタでも最初の構文解析で検出されるような簡単なものなら問題ないが、突き止めるのが極めて困難な部類のバグ（特異なバグを参照）はできる限り早い時点で回避されるに越したことはない。。
一旦の完成の後も、ある程度の期間使われるプログラムでは、使用しているうちに、プログラムの性能や機能に新しい要求が発生したり、プログラムの設定を変更する必要がでてきたり、テストにより発見できなかったバグが見つかることがある。このような事態に対応するため、プログラムを保守していく作業が必要になる。
プログラマ
プログラミングをする人をプログラマという。プログラミングを行うには一般に、コンピュータ科学を中心としたプログラミングそれ自体についての能力や知識と、書こうとするプログラムが対象とする問題領域などについての能力や知識の両方が必要である。
職業としてのプログラマ プログラマの仕事 要求分析 ソフトウェア設計 プログラム仕様 ソフトウェアアーキテクチャ コーディング コンパイル ソフトウェアテスト ソフトウェアドキュメンテーション ソフトウェア保守
この他、プログラムが、作者以外の人によって利用される場合には、プログラムの利用方法や機能について質問を受けることがある。プログラムを、意図したとおり稼働させてゆくためには、これらの問い合わせに対応する必要もある。
一般に、職業としてプログラミングを行う場合、これらの作業が工程として含まれる。大規模なプログラミングでは、これらの作業を分業することも多い。
このような業務は、ソフトウェア工学という学問のソフトウェア開発工程の分野として扱われる。
20世紀後半を通して、先進国ではプログラマが魅力的な職業の1つとされたが、1995年以降にインターネットが爆発的に普及すると、インドなど発展途上国でありながら数字やプログラミングに強く安い賃金で働く人々を、インターネット経由でプログラミングに利用する傾向が強まり、先進国のプログラマにとっては、仕事でインドの労働力と競争しなければならなくなり、給料が上がりづらい状況になった。さらに2020年代にchatGPTが登場し、高速にプログラミングを行ってくれるようになった。
人工知能によるプログラミングが発達すれば、プログラミング・スキルは不要になると誤解している人もいるかもしれないが、2023年の体系的な文献分析によれば、人工知能の台頭後は、プログラミング・スキルはむしろそれ以上に重要になる、という希望的な分析も2023年にはあった。
だが、2025年にはすでに、（chatGPT登場の前と比較して）新卒を対象としたテック系の求人は25%減少したというデータが現れ始めている。つまり、入社数ヶ月から数年程度のスキルでできるような簡単な水準のプログラミングは生成AIにまかせてタダで済ませれば会社としては利益が大きくなるのでそうして、経験10年以上など長い経験が必要なプログラミングだけは経験豊富な人にまかせる、という分化が起きている。
プログラミング言語
プログラミング言語が異なれば、プログラミングのスタイル（プログラミングパラダイム）も異なる。どの言語を使うかの判断には、企業としてのポリシー、その用途への適合性、サードパーティーのパッケージが使えるか、個人の好みなど様々な要素がある。理想的には、用途に最も適した言語を選ぶべきである。しかし、その言語を使えるプログラマが十分揃えられないとか、その言語の処理系に問題があるとか、実行時の効率が悪いといった問題から、最適な言語を選べないこともある。
アレン・ダウニー () は、著書『計算機科学者のように考える方法』() で次のように書いている。
プログラミングパラダイム
今日までに、プログラミングの進歩に貢献したパラダイムとして、次があげられる：
プログラムの実行制御の仕組みとして、命令から命令へと直接移動する代わりに、論理的な順接・反復構造を用いてロジックの抽象化を目指した構造化プログラミング 変数の使用による副作用の発生を排除しようとした関数型プログラミング 宣言型プログラミングを可能にした論理プログラミング データと手続きの直交化を押し進め、人間の概念構成に近い表現を可能にしたオブジェクト指向プログラミング プログラミングには、文字による言語で記述する方法ばかりではなく、視覚言語や図形言語で記述する方法であるビジュアルプログラミングという方法もある。
現代のプログラミング 1990年代から2020年ころのプログラミング
品質 ソフトウェア開発手法がどうであれ、最終的にはプログラムは基本的な属性を満たさなければならない。プログラミングにおいてそれを気にかけておくことで、デバッグやその後の開発およびユーザーサポートにかかる時間とコストを削減できる。ソフトウェア品質を確保する方法は様々だが、以下の5つの属性が最も重要である。
効率性: リソース使用量（プロセッサ、メモリ、デバイス、ネットワークその他）は可能な限り少ない方がよい。 信頼性: プログラムは正しく動作しなければならない。それは単にソースコードが正しく実装されているというだけでなく、誤差の伝播を少なくするとか、典型的な値の範囲に関するエラー（オーバーフロー、アンダーフロー、ゼロ除算など）を防ぐという観点も含まれる。 頑健性: データ型の間違いなど実行時エラーによるプログラム停止を誘発するような事態に対処できなければならない。これは、特にユーザーとのやり取りの場面や、エラーメッセージの処理などで重要となる。 移植性: 再プログラミングしなくとも、任意のソフトウェア環境やハードウェア環境で動作すべきである。 可読性: 後の保守をコーディングした人が行うとは限らないため、命名規則やコメントなどをわかりやすくしておく。
方法論