hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
C言語 規格
C11はUnicode文字列（UTF-32、UTF-16、UTF-8の各符号化方式）に標準で対応している。そのほか、type-generic式、C++と同様の無名構造体・無名共用体、排他的アクセスによるファイルオープン方法、quick_exitなどのいくつかの標準関数などを追加した。
また、_Noreturn関数指示子を追加した。_Noreturnは従来処理系ごとに独自に付加していた属性情報（たとえばgccでは__attribute__((__noreturn__))）を標準化したもので、「呼び出し元に戻ることがない」という特殊な関数についてその特性を示すためにある。return文を持たない関数という意味ではなく（規格ではreturn文を持たなくとも、関数の最後の文の実行が終われば制御は呼び出し元に戻る）、_exitやexecveを実行したり、例外、longjmpによる大域ジャンプなどのために、制御が呼び出し元に戻らないことを明示するためにある。そのような関数は、スタックに戻りアドレスを積む通常の呼び出しではなく、スタックを消費しないジャンプによって実行できる。
C11規格では一部の機能を省略可能とした。即ちコンパイラがC11に合致していても、一部機能は提供しないことがある。コンパイラがどの機能を提供しているかは、テスト用のマクロで判別できる。アラインメント機能や_Atomic型、C言語ネイティブの原始的なスレッド機能などが、C11では省略可能な機能として追加された。また、複素数型と可変長配列はC99では必須機能であったが、C11では省略可能である。
gets関数が廃止された。
2018年にISO/IEC 9899:2018（通称・C17またはC18）として改訂された。仕様の欠陥修正がメインのマイナーアップデートである。
C言語 主なC言語処理系
大抵の処理系はC言語とC++双方をサポートしている。C言語とC++の共通部分を明確にし、2つの言語の違いに矛盾が生じないようにすることが課題になっている。
C++ Builder
Windows/macOS/iOS/Android対応のC/C++コンパイラBCCを含む、RADツール。以前はWindowsおよびx86のみがメインターゲットだったが、Clang/LLVMをベースに再設計され、多数のプラットフォームやアーキテクチャをサポートするようになった。前身はDOS/Windows用のBorland C/C++。さらに前身としてTurbo C/C++がある。
Clang
LLVMをバックエンドとして用いるオープンソースのC/C++・Objective-Cコンパイラ。多数のCPUに対応。
GNUコンパイラコレクション（GCC）
C/C++以外の言語もサポートし、多数のCPUやオペレーティングシステムに対応、組み込み向けも含む多様な開発に広く使われるオープンソースのコンパイラ。独自拡張機能も多い。
GCC 4.5で実質的にC99を完全サポートした。
GCC 4.9で実質的にC11を完全サポートした。
Microsoft Visual C++（MSVC）
C言語 主なC言語処理系
Windows系プラットフォーム用のC/C++コンパイラ。ANSI C準拠（バージョン2013にてC99ライブラリをほぼ実装したが、言語機能など規格自体はサポートされていない）。x86・x64が主だが、Xbox 360、Windows CE等向けにPowerPC、ARM、MIPS、Itanium等に対応した版もある。前身としてMS-DOS・Windows用のMicrosoft C Compilerがある。またその廉価版としてQuick Cがあった。
Intel C++ Compiler（ICL/ICC）
インテル製のIA-32（x86）およびIntel 64（x64）用のC/C++コンパイラ。Windows/Linux/macOS/Android向けがある。gcc互換。
バージョン11.1まではIA-64（Itanium）をサポートするが、バージョン12.0以降ではサポートされない。
C99とC11の対応リストが公開されている。バージョン18.0でC11にほぼ対応している。
Open Watcom C/C++
Windows・Linux・OS/2・MS-DOS・DOSエクステンダを対象とするx86用C言語・C++コンパイラ。商用だったWatcom C/C++がオープンソース化したもの。
Portable C Compiler
C言語 主なC言語処理系
gccが普及する以前のUNIXにおける標準的C言語コンパイラ。現在はオープンソース。
Digital Mars C/C++
Windows・MS-DOS・DOSエクステンダを対象とするx86用のC言語・C++コンパイラ。無料版もある。ウォルター・ブライト作でDatalight C、Zorland C、Zortech C/C++、Symantec C/C++と変遷している。
Green Hills Software C/C++
組み込み向けのC言語・C++コンパイラ。 Windows用・Solaris用・Linux用があり、HP/UX用がver4ではあった。
CodeWarrior C/C++
組み込み向けやゲーム機開発向けのC言語・C++コンパイラ。Classic Mac OS用として発祥、かってはWindows用・BeOS用・Palm用もあった。
ARM C/C++
ARM CPU用C言語・C++コンパイラ。
IAR C/C++
新旧の組み込み向けCPU各種を広くカバーしていた。後に統合開発環境EW・SWに移行。使用には付属のドングルが必要だった。ARM CPU用C言語・C++コンパイラが著名。ARMをコアにした各社のCPUに対応している。
High C
C言語 主なC言語処理系
元はx86向けでPC/AT互換機用だが80386のネイティブモードに対応したためFM TOWNSでも標準開発環境、「High C 386」として使用された。後に各社RISC向けとなる。
BDS-C
CP/M（8080・Z80）用のサブセット（整数のみ）のK&R系のC言語コンパイラ。現在はパブリックドメインソフトウェア。
Hitech-C
Z80、PICなど。
Lattice C
1980年代に、日本で高い普及率を見せたコンパイラ。解説書も多く出版されていた。日本での発売はライフボート。初期版はマイクロソフトCコンパイラ1.0として発売された。商用利用のできない個人向けの「personal」版も販売されており、これの価格は19,800円であった
LSI C
8080・Z80用のLSI C-80（セルフ版・クロス版。現在はクロス版のみ）と、8086用のLSI C-86がある。8086では機能限定（スモールモデルのプログラムしか開発できず、デバッガがない）の「試食版」がフリーソフトで公開され、広く使われた。
micro-C
8ビット・マイクロプロセッサMC6809用C言語サブセット・コンパイラ。
Small-C
元は8080向けの小型のC言語コンパイラだが派生版のクロスコンパイラとしてcc65（MOS6502用）や、z88dkなどがある。
SDCC
各種8ビット・マイクロプロセッサ向けのフリーソフトウェア（GPL）のC言語クロスコンパイラ。
ドナルド・クヌース
ドナルド・アーヴィン・クヌース（Donald Ervin Knuth [kəˈnuːθ],  1938年1月10日 -）は、数学者・計算機科学者。スタンフォード大学名誉教授。漢字名は高徳納（高德纳）。
クヌースによるアルゴリズムに関する著作 The Art of Computer Programming のシリーズはプログラミングに携わるものの間では有名である。アルゴリズム解析と呼ばれる分野を開拓し、計算理論の発展に多大な貢献をしている。その過程で漸近記法で計算量を表すことを一般化させた。
計算機科学への貢献とは別に、コンピュータによる組版システム TeX とフォント設計システム METAFONT の開発者でもあり、Computer Modern という書体ファミリも開発した。
作家であり学者であるクヌースは、文芸的プログラミングのコンセプトを生み出し、そのためのプログラミングシステム WEB / CWEB を開発。また、MIX / MMIX 命令セットアーキテクチャを設計。
ドナルド・クヌース 生い立ち
ウィスコンシン州ミルウォーキー生まれ。父は小さな印刷会社を経営し、近くの高校で簿記の講師をしており、父親が教えているその高校にクヌースは進学した。高校2年生のとき、"Ziegler's Giant Bar" という文字列から文字を取り出して組み合わせ、どれだけ意味のある単語を作れるかというコンテストが行われた。審査員が事前に用意した回答例は2500語だったが、クヌースは4500語も見つけ出すという才能を発揮し優勝した。賞品として学校にテレビ受像機（当時は高価であった）が贈られ、クラス全員にキャンディバーが配られた。
ドナルド・クヌース 大学教育と初期の職歴
大学進学にあたって、音楽と物理学のどちらを選ぶかで悩んだ末、ケース工科大学（現在はケース・ウェスタン・リザーブ大学）で物理学を学ぶことにした。ケース工科大学で物理学を学んでいた頃、初期のコンピュータの一つである IBM 650 と出会う。そのマニュアルを読んだクヌースは、自分ならもっとうまくできると信じ、アセンブラとコンパイラのコードを書き換えることを決心した。1958年、大学のバスケットボールのチームがリーグ優勝するのを助けるため、クヌースは各選手の能力に基づいたプログラムを構築した。これは当時あまりにも画期的だったため、ニューズウィーク誌に記事が掲載され、CBSイブニングニュースでウォルター・クロンカイトも取り上げた。Engineering and Science Review という技術専門誌の立ち上げに編集者として参加しており、同誌は1959年に技術誌の国家的な賞を受賞している。その頃物理学から数学に転向し、1960年には、ずば抜けた成果により学士号と修士号を同時に与えられた。
ドナルド・クヌース 大学教育と初期の職歴
1963年、カリフォルニア工科大学で数学の博士号を取得し、同大学で准教授として働き始め、そこで The Art of Computer Programming の執筆を開始した。実は元々はコンパイラに関する本の執筆を依頼され、当初1冊で内容を完結させる予定だったのだが The Art of Computer Programming という大作になってしまった。6部作となってしまい、さらに7部作へと構想が膨らんでいった。第1巻を出版する直前の1968年、プリンストン大学キャンパスにあった Institute for Defense Analyses (IDA) の通信研究部門を通してアメリカ国家安全保障局 (NSA) の仕事を請け負う職に就いた。しかし、その仕事はクヌースの政治信条には合わなかったようで、間もなくスタンフォード大学に移った。
ドナルド・クヌース 執筆
TAoCP あるいは ACP と略されることがある。コンピュータプログラミングの「Art」について集積した大著である。クヌース自身がここで意図している「Art」がどのようなものであるかは、本書の公刊という業績によって第3巻を刊行後の1974年にチューリング賞を受賞した際に、受賞講演の冒頭で詳細に述べている。
人類のコミュニケーション方法で最良のものは、ストーリーを通したそれだ。 — ドナルド・クヌース
本書を企図した当時、計算機科学は第一歩を恐る恐る踏み出したばかりで、クヌースは「それは正体不明の全く新しい領域だった」と述べている。さらに「入手可能な出版物の水準はあまり高いとは言えなかった。次々と書かれる論文の内容がはっきり言えば間違っている、というような状況だった。（中略）だから、ひどい形で語られてしまっていたストーリーを直したいと私は思ったんだ。」と述べている。
ドナルド・クヌース 執筆
その後1976年に、2巻の第2版の準備中にその版面の仕上がりに不満を持ち、TeX と METAFONT を自ら開発し始めてしまい、4巻への着手は多少後ろ倒しとなった。結果として、コンパイラの技法についても続刊の内容として2020年の時点でも予告には含まれているが、それらの分野については既に多くの書籍がある。一方で既刊部分に含まれる、徹底したサーベイと実践に基づき書かれた内容は、しばしば参照される、貴重な記録と言えるものも多い。
2012年現在、最初の3巻と第4巻の第1部が出版済みである。
他に『超現実数』(Surreal Numbers) という本も執筆している。ジョン・ホートン・コンウェイの集合論に基づいて代替の数体系を構築するという数学的小説である。この本は単に主題をそのまま説明するのではなく、数学の発展過程を示すことに努めている。クヌースはこの本を読んだ学生がオリジナルの創造的研究を行うことを望んでいる。
クヌースの他の著作として 3:16 Bible Texts Illuminated がある。これは聖書に層化抽出法を適用するという試みをしたもので、それぞれの書の3章16節を抜き出して解析している（3章16節を選んだのは「ヨハネによる福音書3章16節」の存在からであるが、他の書の3章16節には基本的に特別な意味は無い）。それぞれの節を美しく効果的に見せるため、ヘルマン・ツァップの指揮でカリグラファー達が協力した。クヌースはルター派である。
ドナルド・クヌース Computer Musings
名誉教授となった今も、年に数回スタンフォード大学で非公式の講義を行っている。彼はこれを Computer Musings と呼ぶ。また、オックスフォード大学コンピュータ研究所の客員教授であり、同大学モードリン・カレッジの名誉フェローでもある。
ドナルド・クヌース クヌースのユーモア
クヌースはプログラマとしても有名で、専門的ユーモアでも知られている。
彼は自身の著作の間違いやタイポに対して 2.56ドルを支払うとしている。この金額は256ペニーが1（16進数）ドルになるということで決められた。また、「価値ある示唆」に対しては0.32ドルを支払う。なお、3:16 Bible Texts Illuminated の間違いに関しては 3.16ドルを支払うことになっている。MIT の Technology Review によれば、これらの賞金の小切手は「コンピュータ界の最高の栄誉」だという。ただし2008年、実際の小切手を送ることは止め、架空の銀行「サンセリフ銀行」の預金証明書を送ることにした。
クヌースは1957年、"Potrzebie System of Weights and Measures"（度量衡のPotrzebieシステム）というタイトルで学内雑誌に科学論文を発表した。その中で長さの基本単位を MAD誌（アメリカのユーモア雑誌）の26号の厚さとし、力の基本単位を "whatmeworry" とした。MAD誌はこの記事を買い取り、1957年6月号 (#33) に掲載した。
ドナルド・クヌース クヌースのユーモア
The Art of Computer Programming 第3巻の索引には "Royalties, use of, 405" という行がある。しかし405ページを見ても著作権使用料 (Royalty) に関する記述はなく、図2として "organ-pipe arrangement"（オルガン-パイプ配置）の図がある。彼の自宅のパイプオルガンは同書の著作権使用料で購入したのであった。
ドナルド・クヌース 受賞歴と栄誉
クヌースの計算機科学への貢献に敬意を表し、1990年、彼は「プログラミング技法の教授; Professor of the Art of Computer Programming」という唯一の称号を与えられた（現在では「名誉教授」に変更されている）。
1992年、クヌースはフランスの科学アカデミーの準会員となった。同年教授職を引退し、The Art of Computer Programming の完成に専念するようになった。2003年、イギリスの王立協会の外国人会員に選ばれた。
2009年、アメリカ応用数理学会 (SIAM) の特別フェローに選ばれた。Norwegian Academy of Science and Letters の会員でもある。
ドナルド・クヌース 私生活
1961年6月24日にナンシー・ジル・カーター（Nancy Jill Carter）と結婚。子をふたり授かる（John Martin KnuthおよびJennifer Sierra Knuth）。
健康
2006年、前立腺癌を患っている。同年12月に手術を受け、放射線療法を受けているが予後はかなり良好だと動画にて報告している。
ドナルド・クヌース 著作
主な著作を以下に示す。完全な一覧は スタンフォード大学ウェブサイトの"Books" にある。
Selected Papers on Computer Languages (Stanford, California: Center for the Study of Language and Information — CSLI Lecture Notes, no. 139) 2003. ISBN 1-57586-381-2 (cloth) ISBN 1-57586-382-0 (paperback)
Selected Papers on Discrete Mathematics (Stanford, California: Center for the Study of Language and Information — CSLI Lecture Notes, no. 106) 2003. ISBN 1-57586-249-2 (cloth) ISBN 1-57586-248-4 (paperback)
ドナルド・クヌース 著作
Selected Papers on Design of Algorithms (Stanford, California: Center for the Study of Language and Information — CSLI Lecture Notes, no. 191) 2010. ISBN 1-57586-583-1 (cloth) ISBN 1-57586-582-3 (paperback)
Selected Papers on Fun and Games (Stanford, California: Center for the Study of Language and Information — CSLI Lecture Notes, no. 192) 2011. ISBN 978-1-57586-585-0 (cloth) ISBN 978-1-57586-584-3 (paperback)
ドナルド・クヌース 著作
Companion to the Papers of Donald Knuth (Stanford, California: Center for the Study of Language and Information — CSLI Lecture Notes, no. 202) 2011. ISBN 978-1-57586-635-2 (cloth) ISBN 978-1-57586-634-5 (paperback)
Graham, Ronald L.; ドナルド・クヌース; Patashnik, Oren (1994). Concrete Mathematics: A foundation for computer science (Second ed.). Reading, MA: Addison-Wesley Publishing Company. pp. xiv+657. ISBN 0-201-55802-5. MR1397498
Surreal Numbers: How Two Ex-Students Turned on to Pure Mathematics and Found Total Happiness. 1974, ISBN 0-201-03812-9.
『超現実数 数学小説』好田順治訳 海鳴社 1978年
『至福の超現実数 純粋数学に魅せられた男と女の物語』松浦俊輔訳 柏書房 2004年
Things a Computer Scientist Rarely Talks About (Center for the Study of Language and Information — CSLI Lecture Notes no 136) 2001. ISBN 1-57586-326-X
『コンピュータ科学者がめったに語らないこと』滝沢徹、牧野祐子、富澤昇訳 エスアイビー・アクセス 2003年
Ruby
Ruby（ルビー）は、まつもとゆきひろ（通称: Matz）により開発された、簡潔な文法が特徴的なオブジェクト指向スクリプト言語。
日本で開発されたプログラミング言語としては初めて国際電気標準会議（IEC）で国際規格に認証された事例となった。
Ruby 概要
Rubyは、1993年2月24日に生まれ、1995年12月にfj上で発表された。6月の誕生石Pearl（真珠）と同じ発音をするプログラミング言語 Perlに続くという意味で、7月の誕生石Ruby（ルビー）から名付けられた。
文字列・数値等すべてのデータをオブジェクトとして扱うオブジェクト指向プログラミング言語である。
クラス、ガベージコレクション、例外処理、Mixin、正規表現等の基本機能に、別途機能をRubyGemsで追加することが可能である。
2011年3月22日に、JIS規格「JIS X 3017」が制定され、その後2012年4月1日に、日本発のプログラミング言語では初めて、ISO/IEC規格「ISO/IEC 30170」に承認された。
2025年9月現在、言語仕様は明文化されていない。
バージョン1.9.3以降、BSDとのデュアルライセンスで頒布されている。
Ruby 設計思想
Matzは「Rubyの言語仕様策定において最も重視しているのはストレスなくプログラミングを楽しむことである (enjoy programming)」と述べている。
Ruby には Perl や Python とは決定的に違う点があり、それこそが Ruby の存在価値なのです。それは「楽しさ」です。私の知る限り、Ruby ほど「楽しさ」について焦点を当てている言語は他にありません。Ruby は純粋に楽しみのために設計され、言語を作る人、使う人、学ぶ人すべてが楽しめることを目的としています。しかし、ただ単に楽しいだけではありません。Ruby は実用性も十分です。実用性がなければ楽しめないではありませんか。 — まつもとゆきひろ、Ruby プログラミング入門 まえがき 監修者よりのページ
Matzは、開発理由を次のように述べている。
「なぜRubyを開発したのか」。そのように問われるときに、もっとも適切な答えは、Linux開発者であるリーナス・トーバルズの言葉と同じではないかと思います。
『それがぼくには楽しかったから』
Ruby 設計思想
クラス名はアルファベットの大文字から始めるという制約があり、日本語などの非ASCII文字のみでクラス名を定義する方法がない。この件についてMatzは以下のように語っており、英語を共通言語として使うべきであるという立場を表明している。
2文字目以降は自由なので、もしどうしても日本語が使いたいのであれば、少々不自然にも見えますが、先頭だけ大文字の接頭辞をつけるのはどうでしょうか。しかし、私個人としては、日本語の変数名などを使うことは、そのプログラムを読む人の範囲を日本語が読める人に限定してしまうことになるので、ひどくもったいないのではないかと感じています。そこで、この点を積極的に改善する気にはなれないのです。
静的型について、Matzは（基本設計思想である動的型付けを維持し）『静的型付けを導入しない』意思を改めて示した。
Rubyと同様のスクリプト言語（インタープリタ型言語）であるPython、PHP、Perlでは静的型を導入しており、Rubyも型を導入するべきでは、と長年言われてきました。しかしまつもとさんは「Rubyに型を取り入れたくない（DRYではないから⁠）⁠」⁠、「⁠型宣言することはコンピュータに使われているような気になる」と述べ、Rubyでは静的型は導入しない方針を示しました。
Ruby 設計思想
その代わり、静的解析を導入し、型チェックを行えるようにすることを明らかにしました。（中略）静的解析に期待してほしい、とまつもとさんは述べました。
静的解析は、Ruby 3.0.0から実装された。
MINASWAN「Matzがniceだから俺らもniceでいよう」
そしてRuby（中略）コミュニティを表現した標語に"MINASWAN"というものがあると紹介しました。これは"Matz is nice so we are nice"の略で、もめごとがあっても「matzがniceだから俺らもniceでいよう」と、なだめることが海外のメーリングリストではよく見られるそうです。（中略）今ではスローガンにまで昇華しています。（中略）日本のRubyコミュニティにこの特質を逆輸入したいと考え、講演の最初に取り上げたと述べました。
Ruby 実装
MRI（Matz Ruby Interpreter）あるいは、CRuby（C言語で書かれていることに由来する）と呼ばれる。Matzが開発を始めた実装であり最も広く使われている。（狭義として）#YARVに更新される以前（1.8.x以前）のバージョンを指すこともある。
YARVは、1.9で採用された#MRIのevalをバイトコードで実行するタイプに置き換えたもの。（狭義の）MRIはソースコードを構文木にコンパイルした後、構文木を解釈する仮想機械であるevalで実行するインタプリタであるが、YARVはソースコードをバイトコードにコンパイルした後、バイトコードを解釈する仮想機械であるevalで実行するインタプリタである。Javaなどのバイトコードとは違い、このバイトコードはファイルとしては生成されない（ファイルとして静的に外部化することを考慮した設計では基本的になく、シンボルを多用するなどしている）。なお「YARV」は、もともとは開発中におけるその仮想機械の名前だった。
Ruby 実装
JRubyは、JavaによるRuby実装である（プラットフォーム非依存の利用が可能）。ほとんどのRubyクラスが組み込みで提供されている。インタプリタ・実行時コンパイラ・事前コンパイラの3種類が用意されている。事前コンパイラでは、Javaバイトコードへ変換しJRubyが無くても他のJavaプラットフォーム上で動作させることが可能となる。
IronRubyは、.NET FrameworkによるRuby実装であり、.NET Frameworkのライブラリと連携させることができる。JIT方式のバイトコードインタプリタ。共通言語基盤に準拠した実装（Monoなど）で動作するため、プラットフォーム非依存の利用も可能（ただし、ソースコードが.NET Frameworkのライブラリに依存している場合、Monoでの動作は不可能）。
MacRubyは、macOSのRuby実装。Cocoaを含む様々なフレームワークとの連携が可能。RubyCocoaの問題点を解決するために開発されている。
Rubiniusは、仮想機械でRubyを実行するJIT方式のバイトコードインタプリタ。大部分がRubyで実装されている。
MagLevは、Smalltalk 仮想機械のRuby実装 。
mrubyは、組み込みシステム向けの軽量版。家電製品の他、スマートフォン、コンピュータゲームなどでの使用を想定している。
Parrotで動作させるための実装なども開発されている。
Ruby コード例
ここでは、実用途に即したコード例を中心に記載します。
クロスプラットフォームでの使用を考慮していますが、Unix系コマンドを利用できない環境では正常に動作しないことがあります。
なお、ウィキブックスには、より多くの基本的なコード例が記載されています。
文字列・数値等すべてのデータがオブジェクト
ヘッダ情報の付与
1行目：シバン行。使用するインタプリタを記述（Windows系実装では無視される）。
2行目：使用する文字コードを記述。ここではutf-8を指定。
小文字 または '_' で始まる識別子は ローカル変数
'$' で始まる識別子は グローバル変数
アルファベット大文字 [A-Z]で始まる識別子は 定数
コレクションに関する例
配列の作成と使用法
ハッシュの作成と使用法
ほかの言語でもよくみられるような制御構造を用いることができる。
ブロックは { ... } または do ... end によって囲まれたコード列である。
一行で収まるときは { ... }、複数行にまたがるときは do ... end が使用される。
テキストファイルと異なるメソッド等
http経由でテキストデータを読み込む例（#例外処理、#gsub() の罠も参照のこと）
クロージャとなるようなブロックの引数渡し
メソッドからクロージャを返す例
正規表現による検索例
Ruby コード例
次のコードはPersonという名前のクラスである。その中、まずinitializeはオブジェクトを初期化するコンストラクタである。ほかに2つのメソッドがあり、1つは比較演算子である<=>をオーバーライドしておりArray#sortによりプロパティageでソートすることができる。もう1つのオーバーライド箇所のto_sメソッドは Kernel#puts での表示の形式を整える。attr_readerは Ruby におけるメタプログラミングの例であり、attr はインスタンス変数の入出力を司る、いわゆる値を取得する getter メソッドや値を設定する setter メソッド（アクセサ）を定義する。attr_readerは getter メソッドのみの定義である。なおメソッド中では最後に評価された式が返り値となり、明示的なreturnは省略できる。
結果は3つの名前が年の大きい順に表示される。
想定外のエラーが発生したとき、エラーを分別して実行を継続します。
例外なし
例外は raise ... でも発火できる。
例外あり raise "エラー"
例外あり raise ArgumentError, "Argument エラー"
ベンチマークテストで使用される以下のようなコードを実行したとき、処理速度が著しく低下することがある。
Ruby コード例
Ruby on Railsが有名になったため、Rubyを書いたことがない人は「Rubyは敷居が高い」と敬遠するかもしれないが、それは誤解である。Rubyは「小さなことを少しの努力／Doing small things with little effort」で実装できる言語の一つであり、ちょっとしたプロトタイピング開発やシェルスクリプトの代替に向いている。
「少ない労力でより多くの成果を／Do more with less」
以下、外部コマンド等（コマンド、実行ファイル、スクリプト言語）のうち、Unix系コマンドを利用したコード例を記す。
(例1) 実行／成功可否(true, false)を取得
falseコマンドを実行
(例2) 実行／結果を取得
echoコマンドを実行
実行中のRubyスクリプトのソースコード各行に連番を付与
(参考) Rubyのみで実装
ホームディレクトリの隠しファイルを再帰抽出し、ディレクトリとファイルを配列にする例
(参考) Rubyのみで実装
Parallel gem で並列処理する例
出力結果は「処理が完了する順序で異なる」ことに注意してください。
配列による実装例
ヒアドキュメントによる実装例
(参考) Rubyスクリプトを動的に評価／実行するときは eval で実装
以下はフィボナッチ数を求める例である。適正なアルゴリズムを使用することで処理速度が改善される事例は多い。
Ruby Rubyを組み込んだアプリケーション
RPGツクールXP・RPGツクールVX
株式会社エンターブレインから発売されているRPG制作ソフトシリーズのうち、RPGツクールXPとRPGツクールVXでは、Ruby をツクール専用にカスタマイズした RGSSを搭載している。同シリーズの従来ソフトではあらかじめ用意された機能しか使えなかったが、RGSSにより戦闘などのシステムを一から構築する事が出来るようになった。
RPGツクールMVからは開発言語がJavaScriptに変更になった。
Ruby エピソード
Ruby ではブロック構造を end で終える構文が採用されているが、Matzは他の構文が採用される可能性があったことを述べている。当時、Emacs 上で end で終える構文をオートインデントさせた例はあまりなく、Ruby 言語用の編集モードにオートインデント機能を持たせられるかどうかが問題になっていたためである。実際には数日の試行でオートインデント可能であることがわかり、現在の構文になった。C言語のような{ ... }を使った構文も検討されていたが、結局これは採用されなかった。
Rubyは日本の国産言語として知られており、特にRubyとゆかりのある次の地域は "Rubyの聖地" と呼ばれている。
当初は当然、Matzが書いたコードばかりだったが、2010年前後に主要開発者の立場からは外れ、10年ほど経過した2020年9月8日現在では、RubyのCコード509,802行のうち、Matzがコミットしたのは36,437行で1割以下という状況になっていた。Matzは「意外と多いなという印象です」と語った。一方、Matzがプログラマーとして関わっているmrubyについて同様の方法で測定したところ、67,068行中、25,049行で、しかもmrubyでは他に代理コミットしてもらったものもあるので、「それを加えると32,653行で、約半分ってところですかね」とのことであった。
Ruby 言語間競争とRuby
Python に満足していれば Ruby は生まれなかった
（1993年頃）PerlやPython(0.9x?)は、Matzが理想とするオブジェクト指向モデルを実現するに至っていなかった。
「matzがPythonに満足していればRubyは生まれなかったであろう」。
Ruby on Rails が Python ではなく Ruby で作られた理由 - 開発者のハンソンがRubyに恋をしたから
デイヴィッド・ハイネマイヤー・ハンソンが（2004年頃）Ruby on Railsを構築するのにPython(2.x?)を選ばなかった理由として「私の場合は、恋に落ちたのがRubyなのです。私はRubyに恋をしていますし、もう14年間もそうなのです。（中略）『最適なツール』などというものは存在しないのです。あなたの脳をちょうどいい具合に刺激するパズルがあるだけなのです。今日では、ほぼなんでも作ることができます。そして、それを使って、さらに何でも作れてしまうのです。これは素晴らしいことです。表現や言語、そして思考の多様性に乾杯しましょう！」と質問サイトのQuoraで本人が回答している。
Ruby 言語間競争とRuby
「Rubyは死んだ」のか? 検索ワード頻度では分からない Ruby の生産性やビジネス上の価値
「Ruby Business Users Conference 2018 Winter」(2018年12月14日)より抜粋。
Ruby 言語間競争とRuby
RubyとかRuby on Railsだと、簡単なWebアプリケーションをすぐ作ったり、あるいは、さまざまなジャンルで実際の適用例があるので、なにか困ったとき同じ問題に直面した人を探せたり、あるいはその問題を解決するRubyGemsを見つけられる。そういう点でいうと、トータルの生産性はかなり高いことがあるんですね。
なので、テクノロジーとしては、2010年代にどんどん新しく出てきた言語が持ってるあの機能がないとかこの機能がないとか、そういうカタログスペック上の欠点があるように思えても、トータルの生産性あるいは効率のよさを考えると、Ruby on Railsのビジネス上の価値は、実はそんなに下がっていないと思うんです。
先ほどのTIOBE Indexみたいなランキングは、技術者が新しいことを学ぶときに探すところで順位がついているので、ホットなトピックというんですか、新しく出てきて話題になっているものが上に来がちなんですよね。
だから、実際に仕事として、あるいは自分のプロダクトを作るときに、どんな言語を選択してどういうふうに開発したらいいのかを考えると、Rubyの持っているビジネス上の価値はそんなに下がっていないと思います。たとえ順位が下がって、表面上Rubyの人気が凋落したように見えても、ある意味「まだまだ大丈夫」が1つの見識だと思います。
どのプログラミング言語が最もよく使われているかを判断することは難しい。
TeX
TeX（テフまたはテック、読みについては#名称についてで詳述する）は、ドナルド・クヌース (Donald E. Knuth) が開発し、広く有志による拡張などが続けられている組版処理システムである。
TeX 概要
TeXは以下のようなメリットがある：
スタンフォード大学のドナルド・クヌース教授（現在は退職）が、1976年に自身の著書 The Art of Computer Programming の改訂版の準備中に、鉛版により組版された (en:Hot metal typesetting) 旧版の職人仕事による美しさが、改訂版の当時の写植では再現できていないことに憤慨し、自分自身が心ゆくまで組版を制御するために開発を決意した。
クヌースはまず、伝統的な組版およびその関連技術に対する広範囲にわたる調査を行い、その調査結果を取り入れることで、商業品質の組版ができる、柔軟で強力な組版システムを開発した。それは技術と同時に芸術をも意味するギリシア語の言葉である、τέχνη（テクネ）から採られ“TeX”と名付けられた。
当初の開発は本業である研究や教育の合間での作業であったが、クヌースには1978年に1年間のサバティカルがあったことから、その期間に集中して完成させる見込みであった。しかし実際には、同年に初版をリリースした後も改訂を続けることとなった。最終的に、「完成版」とされた系列であるバージョン3の最初のリリースは、実に1989年のことである。
TeX 概要
TeXを他人が改造したり拡張したりした場合について、それを直接配布することをクヌースは許しておらず、change file というメカニズムを利用して差分を添付する、という形で行わなければならない（これは当時まだ diff と patch が一般的に広く使われていなかったことから、これもクヌースが開発したものである）。この制限はいわゆる「バザールモデル」であるとは多少言い難い所があるが、「オープンソースの定義」では（そのような制限との妥協の産物である）第4項により、差分等を添付した再配布を許しているならば、派生物の配布にそのような制限があってもよい、ということになっているため「オープンソースの定義」には合致している。
TeX 概要
前述した開発期間の長さの理由の一つに、クヌースが徹底的にバグを探して潰していたから、ということも挙げられる。どのようなバグを修正したか、ということも記録しており、ある時期までのものについて解説と一覧が『文芸的プログラミング』の第10章と第11章に収録されている。そのため、残っているバグは少ないだろうとして、ジョーク好きのクヌースが、バグ発見者に対しては前回のバグ発見者の2倍の懸賞金を掛けている。この賞金は小切手（クヌース賞金小切手）で払われるが、貰っても記念に取っておくばかりなので、結局クヌースの出費はほとんどないという（とはいえやはりジョークかもしれないが、やめておけば良かった、というように取れることも書いている）。
クヌースは TeX のバージョン 3 を開発した際に、これ以上の機能拡張はしないことを宣言した。その後は不具合の修正のみがなされ、バージョン番号は 3.14, 3.141, 3.1415, … というように付けられている。これは更新の度に値が円周率に近づいていくようになっていて、クヌースの死の時点をもってバージョン π として、バージョンアップを打ち切るとのことである。
TeX 概要
クヌースは TeX の開発と同時に、TeX で利用するフォントを作成するためのシステムである METAFONT も開発した。こちらのバージョン番号は 2.71, 2.718, 2.7182, … というように、更新の度に値がネイピア数に近づいていくようになっている。さらにクヌースは METAFONT を使って、欧文フォント Computer Modern も設計（デザイン）した。Computer Modern（cmと略されることもある）にはクヌース自身の欧文フォントに対する美的感覚が反映され、全くのプレーンな TeX ではデフォルトのフォントであるが、現在の多くの利用者は Times など伝統的な定番フォントを使うよう設定していることも多い。
TeX および METAFONT はまた、同様にクヌース自身が提唱する文芸的プログラミング (Literate Programming) の「ドキュメンテーションを主とし、コードはそれに付随する」スタイルによる大規模なプロジェクトの一例でもある。やはりクヌースによる文芸的プログラミングのためのシステム WEB の tangle により、そのようにして書かれている文芸的な「プログラム」の中から Pascal で書かれているコード部分が取り出され、コンパイルできるように編集し直されて何らかの Pascal の実装により処理される（大規模なコードのため、多くの Pascal 実装において1個以上のバグを見つけている、ともいわれる）。同様にして WEB の weave を通して得られるドキュメントを書籍にしたものが TeXbook と METAFONTbook である。Pascal が使われているのは開発にとりかかったのが古く、C言語が広く一般的になるより前だったこともあるが、近年ではC言語をターゲットとした WEB である WEB2C が使われることも多い。
（注）LaTeXとの違いはLaTeX参照。LaTeXにはTeXより便利な機能が多いため、TeXを使用しているといってもLaTeXを利用している、という場合がある。
TeX 名称について
製作者のドナルド・クヌースにより以下のように要請されている。
は ギリシア語: τέχνη「技術、芸術」に由来し、ギリシア文字の Τ（タウ）- Ε（イプシロン）- Χ（カイ）である。E を少し下げて、字間を詰めて書く。プレーンテキストなどそれができない場合には “TeX” と表記する（“TEX”や“Tex”と表記するのは誤り）。
前述のようにTeXの語はギリシャ文字に由来するため、X(χ)はギリシア語風に無声軟口蓋摩擦音 [x]（日本語には無いが、ハやフの子音に近い）と発音するのが本来である。TeXbook（TeXブック） でクヌースは、「コンピュータに向かって、息を吐きかけるように正しく発音すれば、端末は少しばかり曇るかもしれない。」と、はく息の伴う発音であることを面白く書き表している。TeXのこの本来の読みをカタカナで表そうとすれば、テフやテッハのようになる。
TeX 名称について
英語においては、[ˈtɛk]（テクまたはテック）と読まれる。これは、（多くの方言で）音素 /x/も音声[x]も存在せず、代わりに [k] が使われ、τέχνη に由来する英語: technical が [ˈtɛk.nɪk.əl] と読むためである。
TeXbookの邦訳出版など日本における TeX の普及に大きく関与したアスキー編集者鈴木嘉平によれば、クヌース自身も、英語による講演の中でテックと発音していたとされる。（もちろんこのことは、本来の発音についてのクヌースによる記述と矛盾するわけではない。）
日本語では、テフまたはテックと読まれる。テフは本来のギリシア語読みから、テックは英語読みからそれぞれ来ている。TeXのXの読みについては、元々特殊な表記であることや、クヌースの発音が[k]に聞こえること、アスキー編集者鈴木嘉平がそれを元にブログ記事「TeXはテック」を書いたことなどから、混乱があった。鈴木は当該記事において、当時「実際の発音はテックである。テフではない。Knuthは明瞭にテックと発音している。」とテフの読みを否定までもする編集部注を付けたとしながら、「これが正しかったのかどうか、今でも疑問を感じる。どうすればよかったのだろう？」と振り返っている。
TeX 機能
TeX はマークアップ言語のスタイルをとっている。すなわち、文章そのもの（テキスト）と文章の構造を指定する命令（コントロールシーケンス）が記述されたテキストファイルを読み込み、そこに書かれた命令により文章を組版し、組版結果を DVI 形式のファイルに書き出す。DVI 形式とは、装置に依存しない (device-independent) 中間形式のことである。処理系は多機能で、チューリング完全である。
DVIファイルには紙面のどの位置にどの文字を配置するかといった情報が書き込まれている。実際に紙に印刷したりディスプレイ上に表示したりするためには、DVI ファイルを解釈する別のソフトウェアが用いられる。DVI ファイルを扱うソフトウェアとして、各種のビューワや PostScript など他のページ記述言語へのトランスレータ、プリンタドライバなどが利用されている。
組版処理については、行分割およびページ分割位置の判別、ハイフネーション、リガチャ、およびカーニングなどを自動で処理でき、その自動処理の内容も種々のパラメータを変更することによりカスタマイズできる。数式組版についても、多くの機能が盛り込まれている。TeX が文字などを配置する分解能は 25.4/(72.27 × 216) mm（約 5.363 nm、4,736,286.72 dpi）である。
TeX 機能
TeX の扱う命令文の中には、組版に直接係わる命令文の他に、新しい命令文を定義するための命令文もある。こうした命令文はマクロと呼ばれ、TeX ユーザー独自の改良により、種々のマクロパッケージが配布されている。マクロパッケージを用いない環境やクヌースが予め定義したマクロのみを用いる使い方は、飾りのない純粋な TeX の意で plain TeXと呼ばれている。
比較的よく知られている TeX 上のマクロパッケージには、数学的文書用の AmS-TeX や楽譜用の MusiXTeX などがある。
このほか、TeX を土台として機能を拡張したソフトウェアとして LaTeX がある。一般的には、TeX を直接使うよりも、TeX や LaTeXに何らかのマクロパッケージを読み込ませたものを使うことの方が多い。マクロパッケージも LaTeX 用の物が一般的であり充実している。
TeX とそれに関連するプログラム、TeX や LaTeX のマクロパッケージなどは CTAN（Comprehensive TeX Archive Network、包括 TeX アーカイブネットワーク）からダウンロードできる。
TeX 数式の表示例
たとえば
は以下のように表示される。
また、
は以下のように表示される。
TeX ユニコード対応の多言語拡張版
2024年現在、国際的に統一された文字符号化方式であるUnicodeの文字列を直接読み込めるようにした拡張版が開発され、主流になってきている。
日本語文書に関しては、日本語用であるpTeXを元とした upTeX や ε-upTeX が実用的とされている。ただし、国際的な多言語対応への需要や、技術的により新しい機能が搭載された国際的に主流の TeX 処理系へと移行しようとする欲求から、XǝTeX, LuaTeX へと移行しようとする流れがあり、XǝTeX, LuaTeX 共に日本語組版処理用のパッケージが開発されつつある。
TeX ユニコード対応以前の日本語組版用 TeX
日本語組版処理のできる日本語版の TeX および LaTeX には、アスキーによる pTeX および pLaTeX と、NTT の斉藤康己による NTT JTeXおよび磯崎秀樹による NTT JLaTeX などがある。
TeX ユニコード対応以前の日本語組版用 TeX
TeX の日本語対応において技術的に最も大きな課題は、マルチバイト文字への対応である。pTeX（および前身の日本語 TeX）は、JIS X 0208 を文字集合とした文字コード（ISO-2022-JP、EUC-JP、および Shift_JIS）を直接扱う。DVI フォーマットは元々16ビット以上の文字コードを格納できる仕様が含まれていた。しかしオリジナルの英語版では使われていなかったため、既存プログラムの多くは pTeX が出力する DVI ファイルを処理できない。またフォントに関係するファイルフォーマットが拡張されている。これに対して NTT JTeX は、複数の1バイト文字セットに分割することで対応している。たとえば、ひらがなとカタカナは内部的には別々の1バイト文字セットとして扱われる。このためにオリジナルの英語版からの変更が小さく、移植も比較的容易である。ファイルフォーマットが同じなので英語版のプログラムで DVI ファイル等を処理することもできる。しかし後述するフォントのマッピングの問題があるため、実際には多くの使用者が NTT JTeX 用に拡張されたプログラムを使っている。
使用する日本語用フォントについては pTeX が写研フォントの使用を、NTT JTeX が大日本印刷フォントの使用を前提としており、それぞれフォントメトリック情報（フォントの文字寸法の情報）をバンドルして配布している。しかし有償であるこれらのフォントのグリフ情報を持っていなくても、画面表示や印刷の際に使用者が利用できる他の日本語用フォントで代用することができる。つまり写研フォントや大日本印刷フォントのフォントメトリック情報を用いて文字の位置を固定し、画面表示や個人ユースの安価なプリンタによるプレビュー印刷には他の日本語用フォントを用い、業者などによる最終的な出力では商用フォントを使用して目的の仕上がりを得る、といったことも可能である。このため日本語化された TeX 関係プログラムのほとんどは、画面表示や印刷で実際に使うフォントを選択できるように、フォントのマッピング（対応付け）を定義する機能を持っている。
歴史的には、アスキーが日本語 TeX の PC-9800 シリーズ対応版を販売したために個人の使用者を中心に普及した。一方、NTT JTeX は元の英語版プログラムからの変更が比較的小さいという利点を受けて、Unix系OSを使う大学や研究機関の関係者を中心に普及した。
しかし次に挙げる理由から、日本語用 TeX の中では pTeX が選ばれることが多かった。
TeX TeX による組版の作業工程
TeX による組版の作業工程は、通常次のようになる。
DVI 命令文を解するソフトウェア（DVI ウェア）を用いて組版結果を表示し、確認する。
DVI ウェアには xdvi / xdvik や dvioutなどの DVI ヴューア、Dvips(k) や dvipdfm / DVIPDFMx などのファイル形式変換ソフトウェアなどがある。
DVI ファイルを DVI ビューアで画面表示または印刷する、あるいは PDF や PostScript に変換して画面表示または印刷することで、組版結果を確認する。
修正の必要があれば、ソースファイルを修正して再度DVIファイルを作成、確認する。
この間、作業工程が変わるたびにそれぞれのプログラムを切り替えたり、扱う文書が大きいと章ごとにソースファイルを分割して管理したりと、比較的煩雑な作業を伴う。そのため、この工程に係わる各種のプログラムやソースファイルの管理を一元的に行う TeX 用の統合環境（TeXworks や TeXShop など）がいくつか作成されている。
GUI は PC の普及に一役買ったが、それとともに TeX などのコマンドラインインタプリタに不慣れな PC 利用者が増加した。そのために、GUI に特化した TeX 用統合環境が LyXなどいくつか作成されている。
TeX コミュニティ
有名な TeX コミュニティの一つは TeX Users Group (TUG) であり、TUGboatや The PracTeX Journal(TPJ) を出版している。Deutschsprachige Anwendervereinigung TeXはドイツの大きなユーザーグループである。tex.stackexchange.comは TeX ユーザーのための質問・回答サイトである。
TeX ユーザの集いは、日本で2009年以降毎年開かれている TeX の研究集会であり、TeX や組版・出版など関する知見の共有や、TeX ユーザーの相互交流を目的としている。ただし2013年は、TUG 2013 が東京で開催され、TeX ユーザの集いは開催されなかった。
暗号
暗号（あんごう）とは、セキュア通信の手法の種類で、第三者が通信文を見ても特別な知識なしでは読めないように変換する、というような手法をおおまかには指す。いわゆる「通信」（telecommunications）に限らず、記録媒体への保存などにも適用できる。
暗号 概要
秘匿通信を行う上で最も単純な方法は「木を隠すなら森」という諺のごとく、通信文そのものの所在を隠してしまうことである。歴史上実際に行われたものとしては、通信文を丸めて飲み込んだり、ベルトの内側に書き普通の被服のように身につけたり、新聞の文字に印（文字横に穴を開ける等）をつけて文章を作る、頭を剃りあげて頭皮に通信文を刺青し、再び頭髪が生えそろうことで隠す、意図的に広い帯域に信号を分散させるスペクトラム拡散などもあったようである。「暗号らしい手法」としては「ステガノグラフィー」といい、「それとはわからないような形で」記録する、というものである。画像などに情報を埋め込む「電子透かし」にも同じ技術を利用するが、電子透かしではその画像の著作権情報などといった関係のある情報を埋め込むのが目的であるのに対し、ステガノグラフィーは全く無関係な情報を秘密のうちに紛れ込ませる、という点が異なる。またいわゆる縦読みなども一見して普通の文章の中に見えるためステガノグラフィーの一種と言えなくもない。
暗号 概要
広義では以上のような方法も暗号に含まれるし暗号学が探求する対象であるが、狭義では、その見た目が「なんだかわからない」という、難読であると明確なものを指して特に暗号に分類する（なお、暗号化された通信文（暗号文）については理論上、他からの「それが暗号である」という情報が無ければ、ただのデタラメと全く区別が不可能であるのが理想である）。
狭義の暗号は、古典的には主要な分類に、以下の2つがある。
通信文内の、単語やフレーズといったある程度意味のある塊の単位で、あらかじめ取り決めてある記号と交換する。
通信文に対し、意味とは関係なく、文字毎の（最小の）単位で、あらかじめ取り決めてある置換や転置を掛ける。
暗号 概要
「コード」は一般に、軍の運用に必要なものなど、ある程度の（あるいは膨大な）語彙について秘密の記号群を決めておくものであるが、「討ち入り」「開戦」などといった特定の重要な件のみについて、「○◇△といえば、～のこと」等と事前に取り決めておくことで秘匿することも行われた。個人間で行うものから組合やギルド等の特定のグループ内で行うものがある。事前の取り決めではなく、特定の人達だけが知る事項などを元に、意味は同じままで、言い方を変えることで秘匿することもある。秘匿したい特定の単語だけ置き換えることも、コードブックと呼ばれる辞書を作成して全ての単語を置き換えることもあり、歴史的な例としては、前者は「スコットランド女王メアリーの暗号」、後者は「ルイ14世の大暗号」や「ナポレオンの小暗号」などが知られている。
「サイファー」は、機械化以前は一般に作業手数が大きいといった欠点があったが、機械化以後はサイファーが主流の暗号である。機械化に次いで、暗号のコンピュータ化（あるいは、コンピュータの暗号化）の時代となったが、それらの暗号も、だいたいサイファーに分類するのが妥当であろう。
また以上のようなセキュア通信のための狭義の暗号に限らず、相手の身元を確認する認証や改竄の検出、貨幣の偽造防止技術、電子署名、認証、ハッシュ関数、電子マネーその他、情報セキュリティの多くの局面で、暗号はキーテクノロジとなっている。
なお、暗号化の逆の操作を表す語は「復号(英語: decryption)」であり、本来符号化に対するそれ(英語: decode)同様「～化」とはしないが、「復号化」という誤用はかなり広く定着している。