hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
東京湾 呼称の歴史
中世では、この湾全体は単に（武蔵相模上総下総の）内海、あるいは裏海のように呼ばれていた。その後の幕末や明治初期の記録文献類に登場する現在の東京湾に相当する湾の名称もほとんどが「内海」となっている。なお、近世の東京湾を指すとされる「江戸湾」という語は近年になって造られた語（造語）であり、明治時代以前にあった言葉ではない。
江戸時代には「江戸前」や「江戸前海」などの言葉もあったが、江戸前とは漁場を示す言葉であり、主に佃沖の漁場、あるいは品川沖から葛西沖あたりまでの漁場を包括的に指すための言葉で、東京湾のほんの一部を漁場として指すための言葉であった。「江戸前海」も、「房総沖」などと並ぶ、かなり限定された海域のことだった。
東京湾 呼称の歴史
明治時代の初期でもこの湾は主に「内海」と表記されていたことは上で説明したが、明治中期以降にこの湾の呼称に「東京」が入るようになったのは明治維新で江戸が「東京」となったことが関係しているものの、地形図では「東京湾」、海図では「東京海湾」となっていて、1974年（昭和49年）の『東京湾史』にようやく、最近「東京湾」に統一された、と書かれた。
なお明治初期まで使われた「内海」という言葉は江戸時代以前に北東の下総常陸国境付近に存在していた「香取海」に対しても用いられ紛らわしいので、昨今では区別のため、古代以前の東京湾のことを「古東京湾」や「奥東京湾」、中世から近世までの湾を「江戸湾」「江戸内海」などと呼ぶことが多い。
東京湾 歴史
12万年前は現在より海水面が高く（下末吉海進）、房総半島は島であった。この頃の湾を「古東京湾」と呼ぶ。
旧石器時代は最終氷期にあたり、氷河が発達していたため海面が現在より著しく低く、浦賀水道付近以北は陸地だった。渡良瀬川と利根川とが現在の大宮台地を挟んで東西側を南流し、現在の内湾の中央付近で合流した後、太平洋への河口へ向けて流れた。これらの河川は大規模な峡谷を作った。
6000年前には縄文海進による海水面の上昇があり、関東地方の海水準は現在より3-4 mほど高かった。東京湾は北へ湾入し、渡良瀬川河道では群馬県邑楽郡板倉町付近まで、利根川河道では埼玉県川越市付近まで湾入したことが貝塚分布から裏付けられる。この頃の東京湾を指して「奥東京湾」と呼ぶ。
3000年前から縄文海退が始まり、渡良瀬川・利根川が沖積層を作り湾入部・峡谷を埋めていった。
その頃より、利根川は流路を変え、大宮大地の東の渡良瀬川河道の地帯を流れるようになり、東京湾へ注ぐこの河道の一帯は広大な氾濫域・低湿地となった。
かつては武蔵国と下総国とが接する境界は広大な低湿地帯であり両国間は通行に適さなかった。したがって古代の交通路は相模国三浦半島と上総国房総半島との間の東京湾を渡っている。鎌倉時代にも交通路として利用されていた資料が残る。
東京湾 歴史
中世には湾内で海賊衆も活動し、戦国時代には後北条氏と里見氏の水軍の争いの舞台にもなった。
江戸時代には徳川家康以降、幕府によって沿岸の埋め立てが進み、菱垣廻船や樽廻船などの和船による水運が行われ、後期には外国船来航に対する湾岸防備のために品川沖に台場が築かれている。
長らく鎖国状態にあったが、黒船来航の後に日米修好通商条約が結ばれた結果、横浜港が開港。
その後、軍事的側面から明治時代から大正時代にかけて、湾内に人工島（砲台）である海堡（第一海堡から第三海堡）が建設された。
1945年（昭和20年）9月2日には、東京湾に停泊中のアメリカ海軍戦艦「ミズーリ」甲板上で連合国各国代表が見守る中、日本政府代表が降伏文書に署名して第二次世界大戦が終結している。
昭和30年代には、産業計画会議による「東京湾2億坪埋立についての勧告 NEO TOKYO PLAN」や、丹下健三による「東京計画1960」など湾を大規模に利用する計画があった。
1962年（昭和37年）11月18日、京浜運河の沖合でタンカー『第一宗像丸』とノルウェー船が衝突、炎上。41人が死亡する事故が発生。
東京湾 生物と環境保全
東京湾（江戸湾）は多種・大量な魚介類を産し、利根川東遷事業による生態系や環境面における東京湾への影響は明らかになっていないものの、江戸時代までは世界最大の人口を誇った大都市・江戸の人々の胃袋を満たしてきた。
しかし、とくに明治時代以降、沿岸や流入河川の流域では都市化・工業化が進み、埋立地拡大に伴う干潟など自然海岸や浅瀬の減少、水質悪化が深刻になった。特に1970年代に環境汚染はピークを迎え、海の生き物は激減、一時は「死の海」とまで呼ばれる状態にあった。
1980年代以降環境保全の取り組みが進み、水質の改善がみられ。様々な生き物が戻り、少しずつではあるが生態系を取り戻しつつある。アカエイの生息数は国内の沿岸域でも有数であるが、人間への危険性を持ち、お台場や葛西臨海公園や隅田川や荒川などの人間の生活圏にも多く生息するために注意が必要である。上述の通り、東京湾海底谷ではメガマウスやミツクリザメやダイオウイカなどの貴重な深海性の生物が発見されることもある。2005年に川崎区で発見されたホオジロザメは、オスとしては世界最大級の記録だった。ムギワラエビのように希少な固有種も見られる。
東京湾 生物と環境保全
外海に面している浦賀水道の水質は比較的に良く、ジンベイザメやマンタ、マンボウなどの大型回遊魚類が館山方面で見られることがある。加えて水温が比較的に高い黒潮の影響を受けるため、南方系の魚やサンゴも生息している。特に、夏には沖縄近海で見られるような魚（死滅回遊魚）の姿を見ることも出来る。また、東京湾沿岸は、アカウミガメの産卵分布としてはほぼ北限であるとされる。
一方、夏場には常態的に貧酸素水塊が発生するなど、まだ取り組むべき課題はある。水質改善により、東京湾には多くの種類の生き物が戻ってきたが、個体数はそこまで増えていないと考えられている。実際に東京湾の漁獲量は、2000年に入っても環境汚染のピークだった1960年代・1970年代から増えておらず、横ばいが続いている。たとえば、ハマグリなども依然として生息数が大幅に減少しており、ウミガメや鳥類や魚類など多くの生物にとって重要な生息地である干潟や藻場や自然の砂浜や浅瀬なども著しく減少した。
東京湾 生物と環境保全
後述の通り、本来はニホンアシカや鯨類が豊富に生息していたが、現在ではニホンアシカは絶滅種に認定され、全体的に鯨類自体の出現も限られている。また、セミクジラやコククジラと言った絶滅危惧種の混獲が相次ぎ、本湾におけるスナメリの地方個体群は激減したなど、現在では危機的な状況に置かれている。しかし、ザトウクジラは将来的な東京湾への出現が増加することが予想され、マッコウクジラは現在でも浦賀水道や館山湾や三浦半島など湾口の周辺に来遊する事がある。また、小型のイルカ類や上記のスナメリも少数ではあるが湾内に生息しており、時には大規模なイルカの群れが現れたり、シャチの目撃例も存在する。
上記の通り、現在の東京湾の生態系は、マクロ・ミクロ問わずに様々な生物種が激減したり欠落した状態である。とくにメガファウナに関しては、現在では本来の生態系から喪失した部分が大きい。
東京湾 生物と環境保全
明治時代まではアシカ島など湾内では絶滅種であるニホンアシカが繁殖し、数多くの鯨類も見られた。古式捕鯨の主対象であったセミクジラやザトウクジラやコククジラを中心とした沿岸性が強いヒゲクジラ類が湾内に回遊していた可能性が高く、三浦浄心も『慶長見聞集』にて「江戸浦」を遊泳するクジラに言及しており、袖ヶ浦や浦安沖から湾奥部などでよく見られた「クジラまわし」と呼ばれる光景は、冬の風物詩の一つとされた。また、シロナガスクジラの可能性がある記録（寛政の鯨）も存在する。後述の通り、ツチクジラも浦賀水道から鋸南町の一帯に多数が回遊していた。
しかし、明治40年頃にはニホンアシカは乱獲によって関東の一帯から姿を消した。また、（外国船による日本近海の主だった捕鯨が展開されるよりも前である）文禄期に東京湾と相模湾の周辺でのクジラの多さが起因して、三浦半島を皮切りに東日本では珍しく組織的な捕鯨が展開され、瞬く間に「関東諸浦」に拡大した。東京湾一帯では、三浦半島における操業および鋸南町の浮島での醍醐新兵衛が率いる鯨組によるツチクジラを主対象とした組織的な捕鯨が発達した。しかし三浦浄心が憂慮するほど乱獲が進行し、江戸時代から明治時代を境に東京湾や三浦半島への大型鯨類の安定した回遊は消滅したと思わしい。
東京湾 生物と環境保全
哺乳類ではないが、ヒゲクジラ類と食性等に類似性が強いウバザメも、1970年代までの乱獲の結果、太平洋全体で絶滅危惧種となり、東京湾一帯だけでなく日本列島や東アジア全体でも以降の確認は非常に少ない。
多摩川、鶴見川、荒川、隅田川、江戸川、小櫃川などが注いでいるが、湾口が狭く外海との海水の交換は行われにくい。そのためプランクトンの異常発生である赤潮が度々発生してきた。
1960年代から1970年代の東京湾沿岸部の埋め立ての際、埋め立て土砂を海底から採取したために、流れの悪い浚渫窪地ができた。ここに貧酸素水塊と栄養塩が溜まり、嫌気性細菌により大量の硫化水素が発生する。このことが青潮の発生源の一つとなっている。現在の東京湾では約1億立方メートルの浚渫窪地が存在する。
江戸時代から現代にかけて、沿岸や浅瀬が相次ぎ埋め立てられた。これにより湾内には明治・大正期に造られた海堡を始め、70を超える人工島がある。対して、自然島は現在横須賀市沖の猿島および鋸南町沖の浮島等がある。
沿岸の埋め立てに伴い干潟面積は大きく減少しているが、海水の浄化作用があること、海生生物や野鳥の生息に欠かせない自然環境であることから、残された天然の干潟に対する保護運動が起きている。現在、東京湾に残る干潟は以下の通り。
干潟は東京湾に生息するスズキやタイ、貝類など日本固有種を含む漁業価値の高い魚介類の稚魚の生息地となっており、これを保護・拡張することは環境面のみならず東京湾の漁業や観光（釣り）などの事業価値を高めることにもつながるため、その価値は大変高いものである。
東京都港区のお台場では、1990年代以降砂を運んで人工の干潟を作る試みが行われている。この人工干潟では、アサリを始めとする生き物が戻りつつある。
雨水も生活排水などの下水も、下水道を通じて下水処理場まで運んでいる場合、大量の雨水が下水道に流れ込んでしまい、下水道管で受け止めきれなかった一定量については、汚水未処理のまま河川の公共水域に放流せざるを得ない状況が発生しており、大雨時には放流海域での大腸菌数の増加など、環境影響が発生している。
化学的酸素要求量（COD）の上昇などで示される東京湾の水質汚濁は、富栄養化の原因物質である窒素、リンともに約7割が家庭排水によるものであり、その主たるものは糞尿である。
対策として、合併浄化槽の整備や下水処理場の高度化、合流式下水道の改善などが行われている。
東京湾内の浮遊ゴミおよび浮遊油を回収する目的で、清掃兼油回収船「べいくりん」が国土交通省関東地方整備局・千葉港湾事務所により運用されている。
GIMP
GIMP（ギンプ、ジンプ、GNU Image Manipulation Program）は、GNU GPL の下で配布されているビットマップ画像編集・加工ソフトウェア（ペイントソフト）。
GIMP 概要
GIMPは1995年に Spencer Kimball と Peter Mattis が開発を始めた。
レイヤー、トーンカーブ、ヒストグラム、画像の形状からの切り抜き、ブラシエディタ、パスの編集、多種多様なプラグインなどに加え、モザイク編集や、アニメーション合成（GIFアニメーション）を行うなどといったフィルタ機能も数多く備えており、これ一つで、コンピュータ上のほとんどの画像編集は行える。しかし多機能性を外部プラグインやスクリプトなどに頼っているため起動時の読み込み量が多く、時間がかかる。
もともとウェブ用のグラフィック編集を想定して開発されたソフトウェアであるため、CMYKカラーをネイティブサポートしていないなど、本格的な印刷業務には向いていないという面もある。
基本的には、パレット上のツールボックスから機能を選択して画像の編集を行うというオーソドックスなソフトウェアだが、SDIで、かつ、いくつもボックスを持つなど、長らくインターフェイスに癖があった。しかし、2.6からはユーティリティウィンドウが実装され、今までのツールボックス等のウィンドウを、一つの親ウィンドウで管理できるようになり、2.8からはすべてを一つのウインドウに統合する「シングルウインドウモード」が実装された。
GIMP 概要
対話的な使い方の他にもSchemeを使った「Script-Fu」を用いてスクリプトを作り自動化することができる。なお、Script-Fuの名はカンフー (Kung-fu) からきている。現在ではPerl、Python、Tcl、Rubyなどの言語でスクリプトを書く環境もある。このスクリプト処理は完全に非対話的な自動処理も書ける。ImageMagickの方が簡単にすばやく自動化処理を行えるが、GIMPの方がはるかに強力な画像編集機能を使える。
カラーマネジメント対応については、バージョン2.4より作業中の画像に対してカラープロファイルの割り当て（埋め込み）が可能になったほか、プロファイルが埋め込まれた画像のカラーを適切に画面上で確認するための仕組みが整備された。同様に、CMYK出力時の色味をシミュレートするソフトプルーフの機能も提供されている。カラープロファイルが埋め込まれた画像ファイルの読み込み・保存は、各形式に対応するプラグインの実装に依存しており、従来よりJPEG、TIFF、PNG形式でサポートされていた。バージョン2.4以降はカラーマネジメント関連機能の整備に伴い、ネイティブ形式である XCF形式でもサポートされるようになった。
GIMP 概要
GIMPはX Window System向けに制作され、多くのデスクトップ向けUnix系OS上ではデフォルトで同梱されている。現在はWindows版やmacOS版も利用可能である。macOS版はバージョン2.8.2からmacOSにネイティブ対応し、X11環境が不要になった。
GTKは本来はGIMPのために制作されたライブラリでありGIMPの一部だったが、ここから派生して現在では広く使われるGUI向けのライブラリになっている。
gettextの仕組みを使って多言語対応している。
GIMP ファイル形式
GIMP は以下のファイル形式を開いたり保存したりすることができる。
GIMP は以下の形式をインポートできる（開けるが保存できない）:
GIMP は以下の形式をエクスポートできる（保存できるが開けない）:
GIMP マスコット
「ウィルバー (Wilber)」がGIMPのマスコットである。
GIMP 派生品
GIMP をベースにしたいくつかの派生バージョンやカスタマイズパッケージが存在する。
GIMPshop
Adobe Photoshop とメニューの並び順を同じにしている。
Seashore
macOS向けにシンプル化したもの。
1659年
1659年（1659 ねん）は、西暦（グレゴリオ暦）による、水曜日から始まる平年。
ラムダ計算
ラムダ計算（ラムダけいさん、英語: lambda calculus）は、計算模型のひとつで、計算の実行を関数への引数の評価（英語: evaluation）と適用（英語: application）としてモデル化・抽象化した計算体系である。ラムダ算法とも言う。関数を表現する式に文字ラムダ (λ) を使うという慣習からその名がある。アロンゾ・チャーチとスティーヴン・コール・クリーネによって1930年代に考案された。1936年にチャーチはラムダ計算を用いて一階述語論理の決定可能性問題を（否定的に）解いた。ラムダ計算は「計算可能な関数」とはなにかを定義するために用いられることもある。計算の意味論や型理論など、計算機科学のいろいろなところで使われており、特にLISP、ML、Haskellといった関数型プログラミング言語の理論的基盤として、その誕生に大きな役割を果たした。
ラムダ計算
ラムダ計算は1つの変換規則（変数置換）と1つの関数定義規則のみを持つ、最小の（ユニバーサルな）プログラミング言語であるということもできる。ここでいう「ユニバーサルな」とは、全ての計算可能な関数が表現でき正しく評価されるという意味である。これは、ラムダ計算がチューリングマシンと等価な数理モデルであることを意味している。チューリングマシンがハードウェア的なモデル化であるのに対し、ラムダ計算はよりソフトウェア的なアプローチをとっている。
この記事ではチャーチが提唱した元来のいわゆる「型無しラムダ計算」について述べている。その後これを元にして「型付きラムダ計算」という体系も提唱されている。
ラムダ計算 歴史
元々チャーチは、数学の基礎となり得るような完全な形式体系を構築しようとしていた。彼の体系がラッセルのパラドックスの類型に影響を受けやすい（例えば論理記号として含意 → を含むなら、λx.(x→α) にYコンビネータを適用してカリーのパラドックスを再現できる）ということが判明した際に、彼はそこからラムダ計算を分離し、計算可能性理論の研究のために用い始めた。この研究からチャーチは一階述語論理の決定可能性問題を否定的に解くことに成功した。
ラムダ計算 非形式的な概説
例えば、ある数に 2 を加える関数 f を考える。これは通常の書き方では f(x) = x + 2 と書くことができるだろう。この関数 f は、ラムダ計算の式（ラムダ式という）では λx. x + 2 と書かれる。変数 x の名前は重要ではなく、 λy. y + 2 と書いても同じである。同様に、この関数に 3 を適用した結果の数 f(3) は (λx. x + 2) 3 と書かれる。関数の適用は左結合である。つまり、 f x y = (f x) y である。今度は、引数（関数の入力）に関数をとりそれに 3 を適用する関数を考えてみよう。これはラムダ式では λf. f 3 となる。この関数に、先ほど作った 2 を加える関数を適用すると、 (λf. f 3) (λx. x + 2) となる。ここで、
(λf. f 3) (λx. x + 2)    と    (λx. x + 2) 3    と    3 + 2
の3つの表現はいずれも同値である。
ラムダ計算では、関数の引数は常に1つである。引数を2つとる関数は、1つの引数をとり、1つの引数をとる関数を返す関数として表現される（カリー化）。例えば、関数 f(x, y) = x − y は λx. (λy. x − y) となる。この式は慣例で  λxy. x − yと省略して書かれることが多い。以下の3つの式
ラムダ計算 非形式的な概説
(λxy. x − y) 7 2    と   　(λy. 7 − y) 2    と    7 − 2
は全て同値となる。
ラムダ計算そのものには上で用いた整数や加算などは存在しないが、算術演算や整数は特定のラムダ式の省略であると定義することによってエンコードできる。その具体的な定義については改めて後に述べる。
ラムダ式は自由変数（ λ によって束縛されていない変数）を含むこともできる。例えば、入力に関係なく常に y を返す関数を表す式 λx. y において、変数 y は自由変数である。このようなときに変数名の付け替えが必要になることがある。つまり、式 (λxy. y x) (λx. y) は λy. y (λx. y) ではなく、 λz.z (λx. y) と同値である。
ラムダ計算 定義
ここではラムダ計算の形式的な定義を述べる。まず、記号 (identifier) の可算無限集合  {a, b, c,…, x, y, z,…} を導入する。全てのラムダ式の集合は、BNFで書かれた以下の文脈自由文法によって定義される。
最初の2つの規則は関数の定義を表しており、3つめの規則は関数に引数を適用することを表している。規則2のことをラムダ抽象（英: lambda abstraction）といい、規則3のことを関数適用（英: application）という。関数適用は左結合であることと、ラムダ抽象はその後ろに続く全ての式を束縛することの2点をもってあいまいさが排除される場合は、括弧を省略してもよい。例えば、 ((λx. ((x x) x)) (λy. y)) はより簡単に (λx. x x x) λy. y と書ける。また、非形式的な説明で述べたようにMをラムダ式としたとき、λx. (λy. M)をλxy. Mと略記する。
ラムダ抽象によって束縛されていない変数を自由変数（英: free variable）という。式 λx. (x y) において、 y は自由変数である。ある変数の出現が自由出現であるかどうかは、より正確には以下のように帰納的に定義されている。
ラムダ計算 定義
ラムダ式の集合の上での同値関係（ここでは == と書くことにする）は、直感的には、2つのラムダ式が同じ関数を表していることである。この同値関係は以下で述べるα-変換とβ-簡約によって定義される。第3の規則としてη-変換と呼ばれる規則が導入されることもある。
アルファ変換の基本的なアイデアは、束縛変数の名前は重要ではない、ということにある。例えば、 λx. x と λy. y は同じ関数を表している。しかし、ことはそう単純ではない。ある束縛変数の名前を置換してもよいかどうかには、いくつかの規則が絡んでくる。例えば、ラムダ式 λx. λy. x 中の変数 x を y に置き換えると、 λy. λy. y となるが、これは最初の式とはまったく異なるものを表すことになる。そこでまず準備として、変数 V, W と式 E に対して、 E 中の V の全ての自由出現を W に置き換えたものを
E[V := W]
と書くことにする。この元で、アルファ変換は
λV. E   →α   λW. E[V := W]
である。ただし、 E に W が自由出現しておらず、かつ V を置換することにより E 中で新たに W が束縛されることがないときに限る。この規則によれば、式 λx. (λx. x) x が λy. (λx. x) y に変換されることがわかる。
ラムダ計算 定義
ベータ簡約（ベータ変換とも）の基本的なアイデアは、関数の適用である。ベータ簡約は以下の変換である。
((λV. E) E′)   →β   E[V := E′]
ただし、 E′ の代入によって E′ 中の自由変数が新たに束縛されることがないときに限る。
関係 == は、上の2つの規則を含む最小の同値関係(同値閉包)である。
ベータ簡約は、（同値関係ではなく）左辺から右辺への一方的な変換であると見ることもできる。ベータ簡約の余地のないラムダ式、つまり、 ((λV. E) E′) の形(β-redex)をどこにも持っていないラムダ式を正規形（英: normal form）であるという。
上に挙げた2つの規則の他に、第3の規則としてイータ変換が導入されることがある。イータ変換の基本的なアイデアは、関数の外延性である。ここでいう外延性とは、2つの関数が全ての引数に対して常に同じ値を返すようなとき、互いに同値であるとみなすという概念である。イータ変換は以下の変換である。
ラムダ計算 定義
λV. E V   →η   E
ただし、 E に V が自由出現しないときに限る。
この同値性は関数の外延性という概念によって以下のように示される。
もし全てのラムダ式 a に対して f a == g a であるならば、 a として f にも g にも自由出現しない変数 x をとることによって f x == g x であり、 λx. f x == λx. g x である。この等式にイータ変換をほどこすことによって f == g が得られる。これより、イータ変換を認めるならば関数の外延性が正当であることが示される。
逆に、関数の外延性を認めるとする。まず、全ての y に対してラムダ式 (λx. f x) y はベータ変換でき、 (λx. f x) y == f y となる。この同値関係は全ての y について成り立っているので、関数の外延性より λx. f x == f である。以上によって、関数の外延性を認めたときのイータ変換の正当性が示される。
ラムダ計算 諸概念のラムダ式での表現
上で述べたように、ラムダ計算は計算可能な全ての関数を表現することができる。また、上では 2 + 3 のような算術をラムダ式の一部として用いた。 2 + 3 などは計算可能であるから、もちろんラムダ計算による表現が可能である。もちろん、 2 + 3 以外にも計算可能な全ての関数の表現が可能である。ここではそれらのうちの主なものを紹介する。
自然数をラムダ式で表現する方法はいくつか異なる手法が知られているが、その中でもっとも一般的なのはチャーチ数（英: Church numerals）と呼ばれるもので、以下のように定義されている。
0 := λf x. x
1 := λf x. f x
2 := λf x. f (f x)
3 := λf x. f (f (f x))
以下同様である。直感的には、数 n はラムダ式では f という関数をもらってそれを n 回適用したものを返す関数である。つまり、チャーチ数は1引数関数を受け取り、1引数関数を返す高階関数である。（チャーチの提唱した元々のラムダ計算は、ラムダ式の引数が少なくとも一回は関数の本体に出現していなくてはならないことになっていた。そのため、その体系では上に挙げた 0 の定義は不可能である。）
ラムダ計算 諸概念のラムダ式での表現
上のチャーチ数の定義のもとで、後続（後者）を計算する関数、すなわち n を受け取って n + 1 を返す関数を定義することができる。それは以下のようになる。
SUCC := λn f x. f (n f x)
また、加算は以下のように定義できる。
PLUS := λm n f x. m f (n f x)
または単にSUCCを用いて、以下のように定義してもよい。
PLUS := λm n. m SUCC n
PLUS は2つの自然数をとり1つの自然数を返す関数である。この理解のためには例えば、 PLUS 2 3 == 5 であることを確認してみるとよいだろう。また、乗算は以下のように定義される。
MULT := λm n. m (PLUS n) 0
この定義は、 m と n の乗算は、 0 に n を m回加えることと等しい、ということを利用して作られている。もう少し短く、以下のように定義することもできる。
MULT := λm n f. m (n f)
正の整数 n  の先行（前者）を計算する関数 PRED n = n − 1 は簡単ではなく、
PRED := λn f x. n (λg h. h (g f)) (λu. x) (λu. u)
もしくは
PRED := λn. n (λg k. (g 1) (λu. PLUS (g k) 1) k) (λv. 0) 0
ラムダ計算 諸概念のラムダ式での表現
と定義される。上の部分式 (g 1) (λu. PLUS (g k) 1) k は、 g(1) がゼロとなるとき k に評価され、そうでないときは g(k) + 1 に評価されることに注意せよ。
TRUE や FALSE といった真理値は慣習的に以下のように定義されることが多い。これらはチャーチ真理値（英: Church booleans）とよばれている。
TRUE := λx y. x
FALSE := λx y. y
（この FALSE は前述のチャーチ数のゼロと同じ定義であることに注意せよ）
これらの真理値に対して論理記号を定義することができる。たとえば、以下のようなものがある。
AND := λp q. p q FALSE
OR := λp q. p TRUE q
NOT := λp. p FALSE TRUE
IFTHENELSE := λp x y. p x y
これらの記号を使った計算の例を挙げる。
AND TRUE FALSE
= (λp q. p q FALSE) TRUE FALSE →β TRUE FALSE FALSE
= (λx y. x) FALSE FALSE →β FALSE
以上より、 AND TRUE FALSE が FALSE と等しいことがわかる。
ラムダ計算 諸概念のラムダ式での表現
「述語」とは、真理値を返す関数のことである。計算論において最も基本的な述語は ISZERO で、これは引数がチャーチ数の 0であった場合には TRUE を、そうでなければ FALSE を返す関数であり、以下のように定義できる。
ISZERO := λn. n (λx. FALSE) TRUE
（2つ組の）順序対のデータ型は、 TRUE および FALSE を用いて定義することができる。これらはチャーチ対（英: Church pairs）とよばれている。
CONS := λs b f. f s b
CAR := λp. p TRUE
CDR := λp. p FALSE
リンク型のリスト構造は、空リストのために特定の予約された値（例えば FALSE ）を用い、リストをその先頭要素と後続リストの CONS 対として表現することによって実現できる。
再帰とは自分自身を関数として使用することで、ラムダ計算では表面上は再帰操作は許されていないように見える。しかし少し工夫することによってラムダ計算でも再帰を実現できる。例として階乗を計算する関数 f(n) を考えてみよう。この関数は再帰的に以下のように定義できる。
f(n) := 1, if n = 0; and n × f(n − 1), if n > 0
ラムダ計算 諸概念のラムダ式での表現
ラムダ計算では自分自身を含む関数は定義できない。この問題を解決するためにまず、 f を引数にとり n を引数にとる関数を返すg という関数を考える。
g := λf n. (1, if n = 0; and n × f(n − 1), if n > 0)
関数 g は 1 か n × f(n − 1) を返すような関数を返す。上述の ISZERO や算術、論理記号の定義を用いれば、この関数 g はラムダ式で定義することができる。
しかし、これでは g 自身はまだ再帰的ではない。 g を用いて再帰的な階乗関数を作り出すためには、 g に対して引数 f として渡されている関数が、ある性質を持つ必要がある。すなわち、この f を展開すると関数 g がある一つの引数を伴った形になり、さらにその g への引数は先ほどf として渡された関数に再びなる必要がある。
ラムダ計算 諸概念のラムダ式での表現
この性質は言い換えると、 f は g ( f )に展開される必要があるということだ。この g の呼び出しは先ほどの階乗関数に展開され、再帰の段階を一段降りる計算をしている。この展開において、関数 f が再度出現する。そして、この関数 f は再度 g ( f )に展開され、再帰が続いていく。この f  =  g ( f )となるような関数は、 g の不動点と呼ばれる。そして、この不動点は不動点コンビネータとして知られるものによってラムダ計算で表現することが出来る。この不動点コンビネータは Y と表される -- Yコンビネータ:
Y = λg. (λx. g (x x)) (λx. g (x x))
ラムダ計算では、 Y g は g の不動点となる。つまり、 g (Y g) == Y g となる。このもとで、 n の階乗を計算するには単に g (Y g) n を呼び出せばよい。ここで、 n は上述したチャーチ数である。
n = 5 として、評価の例を見てみよう。
(λn.(1, if n = 0; and n·((Y g)(n − 1)), if n > 0)) 5
1, if 5 = 0; and 5·(g(Y g)(5 − 1)), if 5 > 0
5·(g(Y g) 4)
5·(λn. (1, if n = 0; and n·((Y g)(n − 1)), if n > 0) 4)
5·(1, if 4 = 0; and 4·(g(Y g)(4 − 1)), if 4 > 0)
5·(4·(g(Y g) 3))
5·(4·(λ n. (1, if n = 0; and n·((Y g)(n− 1)), if n > 0) 3))
5·(4·(1, if 3 = 0; and 3·(g(Y g)(3 − 1)), if 3 > 0))
5·(4·(3·(g(Y g) 2)))
...
アルゴリズムの構造が再帰的に評価されているのがわかるだろう。再帰的に定義される関数は全て他の適当な関数の不動点となっているため、 Y を用いることで全ての再帰的な関数をラムダ式で表現することができる。たとえば、自然数に対する除算、乗算や比較述語を再帰を用いてよりきれいに定義することができる。
ラムダ計算 計算可能性とラムダ計算
自然数から自然数への関数 F: N → N が計算可能であるということは、全ての自然数の対 X, Y に対して F(X) = Y と f x == y が同値となるようなラムダ式 f が存在すること、と定義することができる。ここで、 x, y はそれぞれ X, Y に対応するチャーチ数によるラムダ式である。この定義は、計算可能性を定義する多くの方法のうちのひとつである。より詳しくは、チャーチ-チューリングの提唱の項を見よ。
ラムダ計算 同値性の決定不可能性
2つのラムダ式を入力とし、それらが同値であるかどうかを判定するアルゴリズムは存在しない。これは決定不可能性が示された歴史的に最初の問題である。ここで使われる「アルゴリズム」という言葉も、もちろんきちんと定義されなければならない。チャーチは自身の証明の中で帰納的関数をその定義に用いたが、現在ではこれは適切なその他のアルゴリズムの定義と等価であることが知られている。
チャーチの証明ではこの問題を、あたえられたラムダ式に正規形が存在するかどうかという問題に帰している。正規形とは、それ以上簡約のできない同値なラムダ式のことである。チャーチの証明ではまず、この問題が決定可能である、つまり、ラムダ式で表現可能であると仮定する。クリーネによる結果とゲーデル数のラムダ式表現を用いることによってチャーチは、対角線論法によりパラドキシカルなラムダ式 e を構成した。この e を、それ自身を表すゲーデル数に適用すると矛盾が導かれる。
ラムダ計算 同値性の決定不可能性
詳しくいえば次のようである。まず  を正規形の存在性を判定するラムダ式とする。 を2つのラムダ式のゲーデル数から、それらを適用してできるラムダ式を計算する関数を表すラムダ式、 を自然数からそれを表すラムダ式の表現のゲーデル数を求める関数を表すラムダ式とする。すなわち、
が成り立つ。ここで  はラムダ式  のゲーデル数を表すラムダ式の表現である。
いま、ラムダ式  を
と定める。ここで  は正規形を持たないラムダ式  である。自己適用  を計算すると次のようになる。
もし  が正規形を持つならば、 は  にベータ簡約される。するとチャーチ・ロッサーの定理より、 は  と共通のラムダ式にベータ簡約できるから、 は正規形を持つ。これは矛盾。したがって  は正規形を持たない。すると  は  にベータ簡約されることになる。ラムダ式  は正規形であるので、やはり矛盾。したがって  のようなラムダ式は存在しない。
ラムダ計算 チャーチ・ロッサー性
一般にラムダ式の中にβ-変換できる部分式が複数ある場合、どこから評価を行うかによって評価の経過は複数存在する。それらの複数の経過からさらに評価することによって、同じラムダ式を得られる性質をチャーチ・ロッサー性、もしくは合流性と呼ぶ（チャーチ・ロッサーの定理）。また、あるラムダ式から一回のβ-簡約によって得られた二つのラムダ式が、同じラムダ式にβ-変換されるという性質は弱チャーチ・ロッサー性と呼ばれる。チャーチ・ロッサー性を持つ体系は弱チャーチ・ロッサー性も持つが、逆は必ずしもなりたたない。
チャーチ・ロッサー性は本稿で取り扱っている型無しラムダ計算の体系では成立することが知られている。しかしその他の体系、例えば型を付けて拡張されたラムダ計算の体系などに関しては、必ずしも成り立つとは限らない。
ラムダ計算 停止性
β-変換は停止しない（無限ループに陥る）場合がある。例えば次の式を適用する場合には停止しない。
(λx. x x) (λx. x x) →β (λx. x x) (λx. x x) →β …
ある種のラムダ計算の体系では、任意のラムダ式に対してβ-変換の停止性が保証されていることがある。どのような順序でβ-変換を行ったとしてもβ-変換が停止する性質を強正規化性といい、β-変換の順序を上手く選んだ場合にβ-変換が停止する性質を弱正規化性という。チャーチ・ロッサー性を満たし、かつ停止性を持つラムダ計算の体系では、ラムダ式をどのような順序で評価しても必ず同じ結果になることがわかる。
強正規化的であり、かつ弱チャーチ・ロッサー性を持つラムダ計算の体系はチャーチ・ロッサー性を持つ（ニューマンの補題）。
型無しラムダ計算の体系では、ある式の停止性を判断する事は決定不能であることが証明されている。
ラムダ計算 ラムダ計算とプログラミング言語
ピーター・ランディンは1965年に発表したA Correspondence between ALGOL 60 and Church's Lambda-notationにおいて、ラムダ計算が手続的な抽象化と手続き（サブプログラム）の適用のしくみを提供しているがために、多くのプログラミング言語がラムダ計算にその基礎を置いているとみることができるとしている。
ラムダ計算をコンピュータ上に実装するには、関数を第一級オブジェクトとして取り扱う必要があり、これはスタック・ベースのプログラミング言語においては問題となってくる。これはFunarg問題として知られている。
ラムダ計算と最も密接な関係をもつプログラミング言語は関数型言語と呼ばれる諸言語で、本質的にはいくつかの定数とデータ型を用いてラムダ計算を実装している。Lispでは関数の定義にラムダ記法の一変形を用いており、さらに、純Lispと呼ばれるLispのサブセットはラムダ計算と真に等価になっている。
ラムダ計算 ラムダ計算とプログラミング言語
関数を第一級オブジェクトとして扱えるのは関数型言語だけというわけではない。Pascalなど、多くの命令型言語ではある関数を他の関数の引数として与える操作が許されている。CやC++では関数を指すポインタやクラス型関数オブジェクトを用いて同じことが実現できる。このような機能はサブ関数が明示的に書かれている場合にのみ用いることができ、したがってこの機能がそのまま高階関数をサポートしていることにはならない。いくつかの手続的なオブジェクト指向言語では関数を任意の階数に書くことができる。Smalltalkや、より最近の言語ではEiffel（エージェント）やC#（デリゲート）などで用意されている機能がそれである。例えば、Eiffelのインライン・エージェントの機能を用いた以下のコード
はラムダ式 λx. x * x （値呼び出し）に相当するオブジェクトを表している。このオブジェクトは他のあらゆるオブジェクトと同様に、変数に代入したり関数に渡したりすることができる。変数 square の値が上のエージェントのオブジェクトであるとすれば、 square に値 a を適用した結果（β-簡約）は square.item([a]) と書ける。ただしここでの引数はタプルであるとみなされる。
ラムダ計算 並行性
ラムダ計算のチャーチ・ロッサー性は、評価（β-簡約）をどの順序で行っても、さらには同時に（並行に）行ってもよいことを意味している。（より詳しくいえば、ラムダ計算は参照透過である。）このため、ラムダ計算を用いて種々の非決定的評価戦略をモデル化することができる。並列性や並行性をモデル化するためのより強力な手法として、Communicating Sequential Processes（CSP）、w:calculus of communicating systems（CCS）、パイ計算、アンビエント計算などのプロセス計算がある。
ラムダ計算 参考資料
この記事は2008年11月1日以前にFree On-line Dictionary of Computingから取得した項目の資料を元に、GFDL バージョン1.3以降の「RELICENSING」(再ライセンス) 条件に基づいて組み込まれている。
1767年
1767年（1767 ねん）は、西暦（グレゴリオ暦）による、木曜日から始まる平年。
X Window System
X Window System（エックスウィンドウシステム、別称：「X11」・「X」など→名称については後述）とは、ビットマップディスプレイ上でウィンドウシステムを提供する表示プロトコルである。リファレンス実装として X.Org Server があり、標準ツールキットとプロトコルを提供し、Unix系オペレーティングシステム (OS) やOpenVMSなどでのグラフィカルユーザインタフェース (GUI) を構築するのに使われる。他の多くの汎用OSにも移植されている。
X Window System 概要
Xは1984年、マサチューセッツ工科大学が開発した。現在のバージョンであるX11は1987年9月に登場した。現在はX.Org FoundationがXプロジェクトを主導している。リファレンス実装であるversion 11 release 7.3（2007年9月6日）は自由ソフトウェアとしてMIT Licenseおよび類似のライセンスで提供している。
Xは、GUI環境構築のための基本フレームワークやプリミティブを提供する。ウィンドウを画面上に描画したり、移動させたり、マウスやキーボードを使ってやり取りする。Xはユーザインタフェースを規定しない。それは、個々のクライアントプログラムの管理下にある。そのため、Xに基づいた環境の見た目は様々である。プログラムごとにインタフェースは異なる。XはOSの中核 (kernel) には含まれない。アプリケーション層構築の基盤となっている。
X Window System 概要
それ以前の表示プロトコルとは異なり、Xは表示機器に付属した（あるいは統合された）システムではない。ネットワークコネクションを通して使うことを意図して設計している。X の特徴は、Xプロトコルという、画面表示や入出力時に利用するプロトコルがネットワーク透過だということである。そのため、手元のマシンの表示と遠隔のマシンとの表示で表示方法に差がない。このことは、ネットワークを利用したUNIXワークステーション群でGUI表示を行うのに便利であり、UNIXマシンの普及と共にXも普及していった。
X Window System アーキテクチャ
Xはクライアントサーバモデルに基づき、Xサーバが各種「クライアント」プログラムと通信する。サーバはグラフィカルな出力要求を受け付け、（マウス、キーボード、タッチパネルなどからの）ユーザー入力をクライアントに送信する。Xプロトコル自身はハードウェア環境に依存しない。そのため、X Window Systemが動作するマシンはUNIXマシンだけとは限らない。Windows上でXサーバを動作させる、通称PC Xサーバというソフトウェアや、ハードウェア（ファームウエア）でXプロトコルを処理する、通称X端末も存在する。特にX端末は、UNIXマシンが非常に高価な時代に、GUIだけを安価に表示、処理できる機器として良く利用された。
このクライアントサーバという用語（ユーザーの端末、サーバ、クライアントであるアプリケーション）は、しばしば新規のXユーザーを混乱させる。なぜなら用語が逆に使われているように見えるからである。しかしXはエンドユーザーではなく、むしろアプリケーションからみた考え方をしている。XはディスプレイやI/Oサービスをアプリケーションに提供している。そのためサーバである。アプリケーションはこれらのサービスを利用している。そのためアプリケーションはクライアントである。
X Window System アーキテクチャ
サーバとクライアント間の通信プロトコルは、ネットワーク透過性を備える。クライアントとサーバは同じマシン上でも動作するし、別々のマシン上でも動作する。双方のアーキテクチャやOSが違っていても構わない。クライアントとサーバ間の通信は、インターネット上でもトンネリングによって安全に行うことができる。
Xクライアント自体がXサーバを内包し、複数のクライアントに対してサーバとして動作する構成も可能である。これを「Xネスティング」と呼ぶ。XnestやXephyrは、Xネスティングをサポートしたオープンソースのクライアントである。
リモートのクライアントプログラムをローカルなサーバで表示するには、端末エミュレータのウィンドウを開き、telnetあるいはsshでリモートのクライアントアプリケーション（あるいはシェル）を起動し、入出力先をローカルに指定してクライアントを起動する（すなわち、export DISPLAY=[ユーザーのマシン]:0 をリモートのマシン上で設定する）。クライアントアプリケーションはローカルサーバと接続され、ローカルマシンのディスプレイと入力機器を使って動作する。またローカルマシンは、リモートマシンに接続しクライアントアプリケーションを起動する小さなプログラムを実行することもできる。
リモートクライアントの実用的な利用例として、次のようなものがある。
X Window System 設計思想
1984年、Bob ScheiflerとJim GettysはXの基本原則を以下のように定めた。
先頭の原則は、X11の設計時に「具体的アプリケーションがそれを必要としていることを知っている場合に限って、新たな機能を追加せよ」に修正された。
Xはだいたいにおいてこれらの原則に従ってきた。参考実装は拡張性と改良を視野に入れて開発されており、1987年当時のプロトコルとほぼ完全な互換性を維持している。
X Window System ユーザインタフェース
Xは意図的にアプリケーションのユーザインタフェースの仕様を含まないようにしている。ボタン、メニュー、ウィンドウのタイトルバーなどである。代わりに、ウィンドウマネージャ、GUIウィジェット・ツールキット、デスクトップ環境、アプリケーション固有のグラフィカルユーザインタフェースなどがそのような詳細を定義し提供している。そのため、典型的なXのインタフェースを示すことは不可能である。
ウィンドウマネージャは、アプリケーションのウィンドウの位置と見た目を制御する。そのインタフェースはWindowsやMacintoshと似ているものもあるし（GNOMEのMetacity、KDEのKWin、XfceのXfwmなど）、全く異なるものもある。実用本位のウィンドウマネージャもあれば（twmなど）、デスクトップ環境に近い機能を持つものもある（Enlightenmentなど）。
多くのユーザーはデスクトップ環境を通してXを利用している。デスクトップ環境にはウィンドウマネージャ、各種アプリケーションなどが一貫したインタフェースで含まれている。GNOME、KDE、Xfceなどが主なデスクトップ環境である。freedesktop.orgはデスクトップ環境間の相互運用性を高めることを目的としている。
X Window System ユーザインタフェース
Xサーバは、グラフィカルなデスクトップでのキーボードとマウス操作を管理している。そのため、一部のショートカットキーはXサーバと結び付けられている。Control-Alt-Backspaceは通常、現在動作しているXセッションを終了させる。Control-Altとファンクションキーの組合せは、一般に仮想コンソールに連携している。ただし、これは個々のXサーバの実装の詳細であり、常に同じとは限らない。例えば、WindowsやMacintoshで動作するXサーバでは、そのようなショートカットキーは提供されない。
X Window System 実装
X.Org Serverは、リファレンス実装としてX Window Systemの正式な実装として扱われる。自由ソフトウェア、プロプライエタリソフトウェアの実装が複数存在する。商用UNIXベンダーはリファレンス実装を採用し、それを自身のハードウェアに合わせて修正し、独自の拡張を様々に凝らすことが多い。
2004年まで、XFree86がフリーなUnix系システムでのX実装の事実上の標準だった。XFree86はXを80386搭載のパーソナルコンピュータ (PC) 上に移植することから始まり、1990年代末ごろにはXのデファクトスタンダードの地位を得ていた。しかし、2004年にX.Org ServerがXFree86のライセンスの変更を期にして派生し、こちらが主流となっていった。
XとUNIXの組合せはよく知られているが、Xサーバは他のグラフィカル環境用にも存在している。
WindowsやmacOSなどの他のウィンドウシステム上でXサーバを動作させる場合、統合のさせ方がソフトウェアによって色々あり、X.Org ServerではWindowsとmacOSでは以下の方式の最初の3つをサポートしている。Unix系ではフルスクリーンだが、それ以外はXnestによりサポートしている。
X Window System 実装
HPEおよびVSIのOpenVMSにはXとCDE (DECwindows) が標準のデスクトップ環境として含まれている。
OS-9にもかつてメーカー純正のXサーバがあった。マイクロウェア・システムズ(株)がX Window Version 11 Release 4をOS-9に移植し、X開発ライブラリとXクライアント制御管理プログラム、Xクライアントプログラム、OS-9/UNIX互換関数ライブラリから成る "Client Development Pak" を40万円で発売した。
X.Org ServerはmacOSでの動作をサポートしており、XQuartz (X11.app) として公開されている。Mac OS X v10.5~v10.7では標準搭載されていた。
Mac OS X v10.3では、XFree86 4.3とX11R6.6に基づいたXQuartzがMac OS Xに統合されていた。10.5以降はXFree86ではなく、X.Org Serverになった。古いMac OS 7などにもサードパーティー製のXサーバがある。
X Window System 実装
X.Org ServerはCygwin併用の形でWindowsでの動作をサポートしており、Cygwin/X (Xwin) として公開されている。
それ以外にも、他のグループによる各種実装が存在する。X.Org Serverから派生した物もあれば、1から実装されている物もある。自由ソフトウェアとしては、WeirdMind、WeirdX などがある。プロプライエタリソフトウェアとしては、ASTEC-X、Exceed、ReflectionX、WiredX、Xmanager、X-Deep/32、Xming、X-Win32、XVision Eclipse などがある。かつては、Xoftware/32（ネットマネージ製）、DynaWinX、PC-Xware（NCD製、数社が取り扱い）、Super-X（Frontier Technologies製、コンテック扱い）、eXodus for Windows（White Pine Software製、DIT扱い）という商品もあった。これらは通常、リモートのXクライアントを表示・制御するのに使われる。
X Window System 実装
MeeGo、Maemo、Tizen、Ubuntu Touchなど各種Linuxスマートフォン・タブレットでもX Window System (X.Org Server) が使われている。
X端末は、Xサーバを実行するシンクライアントである。これはUNIXワークステーションが高価だったころ、大きめのサーバを複数人で共有し、各人がグラフィカルな環境を使えるようにする安価の手段として人気となった。また、これはMITのプロジェクトが本来想定していた方向性でもある。
X端末は、ネットワーク上で X Display Manager Control Protocol (XDMCP) を使って利用可能なホスト（クライアントを実行できるマシン）を探す。まず最初のホストでXディスプレイマネージャを起動する必要がある。
専用ハードウェアとしてのX端末はその後少なくなり、より安価なXサーバ用端末としてPCや新たなシンクライアントが使われるようになっている。
X Window System Xの限界と非難
UNIX-HATERS Handbook（1994年）は、1つの章を割いてXの問題を論じている。Why X Is Not Our Ideal Window System（1990年、Gajewska, Manasse, McCormack）は、Xプロトコルの問題を詳細に論じ、改善の方法を示唆している。
Xはユーザインタフェースの仕様やアプリケーション間通信の仕様を意図的に含まないようにしている。このためそれぞれ全く異なったインタフェースが生まれ、アプリケーション間の連携を阻む原因ともなっている。ICCCMはクライアントの相互運用に関する仕様だが、正しく実装するのが困難なことで有名である。MotifとCDEも標準化の試みだったが、解決策とはならなかった。この問題は、プログラマやユーザーを長い間悩ませてきた。2007年現在、アプリケーションのルック・アンド・フィールとアプリケーション間通信の一貫性を保つためには、特定のデスクトップ環境あるいは特定のウィジェット・ツールキットを採用してプログラムを作成するのが一般的である。
X Window System Xの限界と非難
Xプロトコルは音声を全く扱わない。そのため、サウンドカードの制御も含めた部分はOSやOSSやALSAなどのオーディオシステムが分担している。多くのプログラマはOS固有のサウンドAPIを使っている。クライアントサーバ型のサウンドシステムとしては、古くはrplayやNetwork Audio Systemがあった。その後、EsounD (GNOME)、aRts (KDE) などが開発された。2001年、X.Orgはこの問題に対処するためMedia Application Server (MAS) の開発を発表した。しかし、これらはいずれも根本的な解決策とはなっていない。
XクライアントをあるXサーバからデタッチし、別のXサーバに再アタッチすることはできない。しかしXとは別の遠隔操作方法であるVirtual Network Computing (VNC) ではそれが可能であり、一部のアプリケーションやツールキットではそのような機能を提供している。
XサーバとリモートのXクライアントの間の通信トラフィックは、デフォルトでは暗号化されていない。そのため悪意ある者がLANアナライザを使えば、それを覗き見ることができるので注意が必要である。
X Window System Xの限界と非難
Xの設計では、クライアントとサーバはそれぞれ独立して動作する。ハードウェアからの独立性やクライアントとサーバの分離などのオーバーヘッドは、OS内にグラフィックス機能が統合されているシステム（WindowsやMac OS）にはないものである。Xが適切な性能を発揮するには、4MBから8MBのRAMを必要とすると言われている。これは1990年代中ごろまではWindowsやMac OSに比較すると大きかった。
Windows Vista/Windows Server 2008以降のWindowsに搭載されているWDDMやOS XのQuartzはXのようなクライアントとサーバの分離を行えるようになっている。オーバーヘッドの大半は、ネットワーク上のラウンドトリップタイムによるものである（つまりプロトコル自体の問題ではなく、レイテンシである）。性能問題を解決するにはそのレイテンシを考慮したアプリケーション設計をする必要がある。Xのネットワーク機能が過度に複雑であるために、ローカルで使っても性能に悪影響があるという誤解を持つ人が多いが、現在のXの実装ではローカルな接続では単にソケットと共有メモリを使うので、X固有のオーバーヘッドはほとんどない。
ディスプレイサーバー本体やディスプレイドライバの実装は安定しているが、Windows系システムとは異なり、ディスプレイドライバがクラッシュした場合、直前までの表示内容は失われ、Xサーバー本体とXクライアントアプリケーションを手動で再起動しなければならない。
そのため、監視システムやインフラ制御システムなどのミッションクリティカルなGUIアプリケーションの利用には注意を要する。