この記事では，私が何らかの意味で違和感を持ったコンピューター用語をテキトーに並べてみる。
違和感にもいろいろあって，「この用語は適切でないので言い換えるべき」と思うものもあれば，「あれぇ？と最初は思ったけど妥当だと分かった」ものもあるし，用語自体に文句はなくて，単に表記が気に入らないだけのものもある。
なお，この記事では表記に文句を付けているもの以外は，表記に頓着しない。「server」「binary」の類は「サーバー」「バイナリー」のように末尾に長音符を付けて書くが，単にそう書きたかっただけである。
よく知らない分野についても書いているので，ツッコミやご指摘を歓迎します。
とくにコンパイラーとか関数型言語とかの世界はよく知らないので，いろいろ勘違いがあるかもしれない。
可変長引数
関数やメソッドなどが取る引数が可変個である場合に，その引数を「可変長引数」という。
え？ 引数に「長さ」は無いでしょ。個数でしょ。
「引数リスト」のような概念を考えるなら，それが「可変長」だというのは分かる。でも引数が可変長だなんて。
「可変長引数」は「可変長配列」からの類推で作られたのだろうか？ 配列には長さがあるので，こちらは違和感が無い。
「可変個引数」でいこうよ。
文字クラス（正規表現の）
正規表現の基本的なものの一つで，何らかの文字の集合を考え，それらの文字のいずれか，という検索パターンを表すものを「文字クラス」と呼ぶ。
まあ文字クラスでもいいんだけどさ，どちらかというと「文字集合」か「文字セット」のほうが分かりやすかった気がするな。
バイナリー
「バイナリー」は計算機用語に限っても多義語で，さまざまに使われる。
計算機用語になる前の binary も多義語で，「二つの物からなる」といった意味もあるが，計算機用語の元になった語義は名詞の「2 進法」と形容詞の「2 進法の」だけ。
計算機用語では，まず「バイナリーデータ」などという場合の「バイナリー」がある。これは「テキストデータ」などの「テキスト」と対概念になっていて，要するにテキストでないものがバイナリーということになる。
しかし，だよ？ テキストデータだってビット列で表されているわけであって，なんでテキスト以外を「2 進法の」と呼ぶのか，ワケがわからない。
いや，実を言うと，ちょっぴり分かるような気もしている。
テキストデータは文字どおり文字で出来ているので，その文字の並びとして印刷したり画面に表示したりできる。
しかし，バイナリーデータを可視化するには，ビット列をどうにかして文字か記号の並びとするしかない。
ふつうにはビット列を 2 進法による数字列と捉えて
0010 0111 1010 1000 0101 0010 1010 1011
のように表すか，これを 2 進法と相性の良い 16 進法に変換して
27 A8 52 AB
のように表すことになる。
2 進ぽく表す（しかない）から「バイナリー」と呼びたくなる，と。
そういうことなのではないか（計算機用語の歴史を知らないので，あくまで推測）。
この場合，「16 進法のほうはバイナリーじゃねえじゃん」というツッコミは野暮ということにしておきたい。
で，ここまでは許容したとしても，「バイナリー」はさらに先へゆくのである。
コンパイルしたやつ
いわく，コンパイラーの文脈で，ソースコードに対して，コンパイル後のものを「バイナリーコード」などと呼ぶことになる。
よく知らないけど，バイナリーコードにも，そのまま実行できるものもあれば，リンカーというもので複数のバイナリーコードをくっつけて初めて実行可能ファイルが出来るものもある。
いや，確かにソースコードはテキストだし，コンパイル後のものはテキストではない。つまりバイナリーである。
しかし，コンパイラーの話をしているときに「バイナリー」というと，画像データなどのバイナリーは含まず，たいがい「コンパイルによって出来たアレ」のことを指す。
実行ファイル
「バイナリー」はさらに先へ進む。
「実行ファイル」の意味で「バイナリー」が使われるようだ。コンパイルして出来たアレのなかでも，実行できるものだけを「バイナリー」と呼ぶ場合が，どうもあるらしい。
私がこれを知って衝撃を受けたのは Rust の勉強をしているとき。
Rust ではプログラムの配布可能な単位として，「クレート」（crate）というものがある。
クレートには二種類ある。
一つは，他のクレートから利用するライブラリーとなるクレート。「ライブラリークレート」と呼ぶ。これはコンパイルしても実行ファイルは出来ない。
もう一つは，コンパイルすると実行ファイルが出来るクレート。これを「バイナリークレート」と呼ぶらしい。
ここでは，もはや 2 進数がなんたらということは全く関係なく，たんに実行可能かどうかに着目したネーミングとなっている。
連想配列・ハッシュ・辞書
このデータ構造にはさまざまな呼び方がある。見出しに挙げた他にも「マップ」とか「連想リスト」とかいろいろ。
連想配列
英語では associative array というらしいので，それの訳語として作られたのかな，と思う。（確実なことを知っている方は教えてください）
associative というのは，確かに「連想による」という意味もあるけれど，このデータ構造としては，あるデータに他のデータが関連付けられている，というニュアンスであるのだろう。
日本語の「連想」というのは，何かに関連して他のものを思い浮かべること。
「鬼」と聞いて，具体的なある怖い先生や，桃太郎のお話や，閻魔大王や，鬼瓦といったものが浮かぶ，そういうことだ。
連想配列における「データの関連付け」は，似ていなくもないけれど，連想という精神の働きとはかなりかけ離れていると私は思う。
連想配列では，一つのキーに結びつく値はただ一つのデータであるのに対し，人間の連想は次々といろいろなものが浮かぶ。
連想配列では，キーと値の結びつきは完全に恣意的だが，人間の連想では何かしら共通性があったり，関係性のあったりするものが浮かぶ。
「連想」より「連関」とかのほうがよかったのではあるまいか？
もう一つ気になるのが「配列」（array）という用語が使われていること。
こうなった理由は想像に難くない。アクセスの仕方が配列そっくりだからだろう（あくまで推測）。
違いは，配列では整数によって要素を特定するのに対し，連想配列ではその制約が無いということ。
しかし，「配列」にせよ「array」にせよ，〈並んでいる〉というところに本質がある。
それに対して連想配列には要素の順序が無い。連想配列の要素を順に取り出すとき，どんな順で取り出されるかは一般には不可知である。要するに並んでいないのだ。こんなもの「配列」ではない。
ただし，Ruby のそれ（「ハッシュ」と呼ぶ）は，順序を保存するけれど（そのため使いやすい）。
Ruby のハッシュも元は順序不定だったが，Ruby 1.9 のときに順序を保存するよう改変された。
ハッシュ
Ruby などいくつかの言語では連想配列を「ハッシュ」と呼ぶ。
計算機用語の「ハッシュ」にはもう一つの意味がある。というか，そっちが本家。
本家の「ハッシュ」は，データからハッシュ関数と呼ばれるものを使って作られる数値のこと（で合ってるかな？？？）。
紛らわしさを避けて（？），とくに「ハッシュ値」とも呼ぶ。
で，連想配列の実装方法として，このハッシュ値をうまく利用した「ハッシュテーブル」というものがある（知らんけど）。
連想配列を「ハッシュ」と呼ぶのは，きっと「ハッシュテーブル」から来ているのだろう。
でもさ，ちょっと飛躍が過ぎない？
しかもさ，Ruby には Object#hash なんていう，ハッシュ値を得るメソッドなんかもあって，二つの異なる「ハッシュ」が用語として並立しているわけよ。むー。
辞書・ディクショナリー
Python とか，古くは PostScript，もっと遡って FORTH なんかでは連想配列を「辞書」とか英語の「dictionary」をそのまま日本語にした「ディクショナリー」と呼ぶ（知らんけど）。
初めて見たときは「？？？」と思った。
いや，確かにコトバのジテンの「辞書」には見出し語があり，一つの見出し語に一つの「語釈等」がぶら下がっている。（「語釈等」と書いたのは，語釈の他に品詞だの変化形だの用例だのも含めたカタマリを言いたかったので）
そういう意味で辞書は連想配列に似ている。
しかし，辞書も排列（並び方）に意味があり，見出し語と「語釈等」の関係に恣意性は無い。
アナロジーとしてあまりピンとこなかった。
ベクター
計算機用語としての「ベクター」の用例を見ていると，どうも微妙に違ういろいろな意味で使われているように思う。よく分からない。
が，大雑把にはいずれも（1 次元の）配列みたいなものを指しているようだ。え？ じゃあ「配列」でよくね？
（グラフィックスの表現形式のベクターはここでは除外）
このベクターはやはり数学のベクトル（より詳しく言えば数ベクトル）に由来するのだろう。
ここで強烈な違和感を禁じえない。
数学のベクトルは，線型空間（ベクトル空間とも言う）の元である。
本質的に重要なのは，同じ線型空間に属するベクトル同士の間に〈和〉という演算が定義されていることと，ベクトルの〈スカラー倍〉という演算が定義されていることだ。
ベクトル計算機の「ベクトル」はまさに数ベクトルとしての演算を実行することからの命名なので，これはいい。
しかし，〈和〉や〈スカラー倍〉の無いものをベクターと呼ぶのはどうなのか。
よく知らないけど，C++ や Rust の「ベクター」は要するに可変長配列のことらしい（違ってたら教えて）。
ということは，要素が文字であるようなベクターもあるわけで，スカラー倍どころか和も想定しえない。可変長だから次元すら変えうる！
もはや数学のベクトルとはほとんど何の関係もないではないか。
余談だが，「ベクトル計算機」は「ベクター計算機」とはあまり言わず，C++ の「ベクター」は「ベクトル」とはあまり言わない。「ベクトル」と「ベクター」は，直接的にはドイツ語経由，英語経由という違いがあるにせよ，同一語に由来する。語形によってゆるやかに意味の棲み分けができているわけで，こういう語の組を「二重語（doublet）」という。
火のしゴテの「アイロン」とゴルフに使う「アイアン」のようなもの（英語 iron より）。
ビジネスロジック
この言葉は私にはうまく説明できないので，語釈は略す。
ひっかかっているのは「ビジネス」というところ。
もともと業務系ソフトウエアの世界で使われていた用語が，分野に関わらず使われるようになったのだと思う。
Ruby on Rails で「ビジネスロジックはモデルクラスに云々」という記述を見るたび，「ビジネス（業務・事業・商売）と関係ないんだがな」と口の端を持ち上げてしまう。
ガード節
この用語自体に文句は無い。
いわゆる「早期 return」との絡みで出てくる。
ともかく，「ガード」だの「ガード節」だのというのは，関数型プログラミング言語とか論理プログラミング言語の世界の用語なのだろう（どちらの世界もよく知らない）。
そっちの世界では適切な用語なのだろうけど，Ruby の世界では馴染みがないうえ，Ruby 用語の「節」はそっちの「節」とはたぶん全然違うものなので，Ruby の記事で「『早期 return』でなく『ガード節』と呼ぶべき」という主張を目にすると，「そ，そうなんスか？」としか思えない。
三項演算子
単項演算子は -x とかにおける - のように，一つの項を持つ演算子。
二項演算子は x - y とかにおける - のように，二つの項を持つ演算子。
どちらもいろいろなものがあり，それぞれの総称となっている。
対して，いわゆる三項演算子は，Ruby を例に取ると
cond ? eq1 : eq2
という形で使う，文字通り三つの項を持つ演算子であって，式 cond の値が真であれば式 eq1 を評価し，偽であれば eq2 を評価し，その値が演算結果となるもの。
三つの項を持つ演算子の総称ではない。
これを「三項演算子」と呼ぶことについては Qiita 上でも過去何度も議論されている。
反対派は，「三項演算子というだけでは中身が分からない」「他にも三項の演算子があったら（できたら）どうするんだ」というのが論拠のようだ。
有力な代替案は「条件演算子」であるようだ。
これについての私の意見は揺れていて，いまだに定まっていないのでここには書かないことにする。ただ，「選択演算子」とか「択一演算子」とかはどうなのかな，と考えたことはある。
インタープリターとコンパイラー
はるか昔，中学生のとき，雑誌で「インタープリター」「コンパイラー」という概念を知った。
かみ砕いて，「一行ずつ解釈して実行するか，まとめて機械語に翻訳して実行するかの違い」というような説明だったと思う。
少し経って，英和辞典で interpreter とか compiler などを引いてみて，「ぁあ？」と思った。
interpreter は「通訳者」である。ちょっとピンとこない。通訳するんだったら，むしろコンパイラーがやっていること（機械語に翻訳）のほうが近いのではないの？
まあ，いま思うには，通訳者というのは話者が話す短い単位ごとに訳すわけで，これが一行ずつ解釈というところにつながるのかな，と。
これはまあいい。
対して compiler は「編集者・編纂者」である。えっ，翻訳者じゃないの？ 翻訳者という意味はない。ええ〜？
未だにピンとこない。
モデル（MVC における）
アプリケーションソフトの構成で，Model-View-Controller という概念があって，ビューとコントローラーは何となく分かるが，データとそれに関する手続きの部分（という表現で合っているのか？）をなぜ「モデル」と呼ぶのかさっぱり分からない。
日本語の「モデル」にしても英語の「model」にしても，「模型」「ひな形」「模範」「手本」「型式」など，どれも当てはまる気がしない。
これは単に私が無知なだけだが，なんで「モデル」なの？
Vanilla JS
Vue.js だの jQuery だのといったライブラリーを使わないで書く JavaScript コードを「Vanilla JS」と呼ぶらしい。
初めてこの言葉を見たときは「はぁ，また新しい JavaScript の何かが作られたのか」と勘違いしたが，そうではなく安心したのを覚えている。
この「vanilla」というのはバニラアイスクリームの「バニラ」だ。
要するにラズベリーアイスでもチョコアイスでもないアレのことを言っている。
しかし，しかしだよ，バニラアイスは風味付けに何も入れていないアイスクリームのことではない！ バニラという植物から得られるバニラエッセンスで風味付けられたアイスクリームのことだ。
（いや実は私も長い間，バニラアイスは何も入ってないアイスと勘違いしていた）
Vanilla JS の vanilla は，日本語なら「素（す）の」といった感じだろうか。
納得がいかなかったが，Wikipedia の「バニラ (ソフトウェア)」とか英和辞典とかを見たところ，こういう「vanilla」の用法は JavaScript 以前からあり，日常語でも「平凡な」という意味で使われ，計算機用語でも「拡張機能無しの」とか「カスタマイズしていない」などといった意味で広く使われてきたようだ。
ふーん，そうなんだー。
一級市民
「JavaScript では関数は一級市民である」というように使う（たぶん）。
Ruby では，メソッドやブロックは一級市民ではない（が，それぞれをオブジェクト化した「Mathod オブジェクト」「Proc オブジェクト」というものはあって，それらは一級市民）。
これは，もともと計算機とは関係なく first-class citizen という概念が英語圏にあって，それを借りてオブジェクト指向の世界で使われるようになったようだ（？）
元の first-class citizen という概念に馴染みがないので，ピンとこない。
それにしても，元の言葉はあからさまに人間を差別する嫌な言葉だと思う。
特異メソッド（Ruby の）
Ruby では一つのオブジェクトだけに定義されたメソッドを「特異メソッド」と呼ぶ。これについての違和感は以下の記事に書いた。
なお，タイトルは「誤訳か」となっているが，投稿した後で誤訳ではないことが分かったので，このタイトルは良くなかった。
クレートとトレイト
これは単に表記だけの問題。
Rust には crate と trait という概念がある。
これの訳語をどう表記するかだが，ウェブサイト The Rust Programming Language の和訳「プログラミング言語 Rust, 2nd Edition」でも，書籍『Programming Rust』の和訳本『プログラミングRust』でも，それぞれ「クレート」「トレイト」という訳語になっている。
ブログなどでもそういう表記が普通のようだ。
ただ発音はそれぞれ [kreɪt], [treɪt] で，最初の子音しか違わない。一方が「エー」で他方を「エイ」とする必然性が感じられない。
ガベージコレクション
garbage collection の garbage は「ゴミ」というような意味で，それはどうでもいいんだけど，日本語の表記は圧倒的に「ガベージ」が使われている（要出典）。たぶん発音もそのように行われているのだろう。
Qiita で記事数を検索すると，以下のように「ガベージ」の圧勝。
「ガベージコレクション」292 件
「ガベージ」31 件
「ガーベジコレクション」40 件
「ガーベジ」8 件
「ガーベッジコレクション」20 件
「ガーベッジ」3 件
「ガーベージコレクション」30 件
「ガーベージ」2 件
さて，garbage の発音は [ɡɑ́ːrbɪdʒ]。第一音節にアクセントがあって長めに発音する。「ガベージ」は分が悪いように思いますけどね。
私は最初に「ガベージ」の語形で覚えたけど，現在は「ガーベジ」と書いている。
この手の，「表記以前に，そもそも日本語（外来語）としてどう発音すべき？」という話は挙げるとキリがないので，この記事ではもうやめとく。以下の記事もご参考に。
IT業界で横行する恥ずかしい英語発音 - Qiita
タイトルや記事本文に侮蔑的と取れる表現があるのが残念だけれど，それはそれとして，なかなか参考になる。コメントも興味深いものが多数あった。
番外編
プログラミング用語ではない計算機用語も少々。
RAM と ROM と PROM
ものすごく大雑把な話（つまり不正確な話）で，半導体メモリーには，書き換えができる「RAM」と書き換えできない「ROM」がある（「あった」と言ったほうがよいかもしれない）。
ROM は Read Only Memory なので文句はないが，RAM は Random Access Memory であって，磁気テープのようなシーケンシャルアクセスではないアクセス方法，というところからのネーミングとなっている。
これは歴史的な事情によるもので，「もはやしょーがねーな」という感じがしていた。
しかし，1990 年代に DVD-RAM が現れたときは驚いた。
これは要するに，読み出し専用ではない（記録ができる）DVD として作られ，命名されたものだ。
ここではもはや RAM が何の略かということは完全に無視され，ROM＝書き換え不可メモリー，RAM＝書き換え可メモリー，という図式から命名されている。
このとき知人の米国技術誌編集者から「DVD-RAM とはどういうことなのか，DVD ならシーケンシャルアクセスではないのか？」と問われ，苦手な英語で上記の事情を説明した覚えがある。
（DVD などの光ディスクはトラックをポンポン飛べるという意味ではランダムアクセス性を持っているので，「シーケンシャルアクセスの媒体」と括ってよいのかは知らんが，それはまた別の話）
さて，ROM のほうだが，ROM なので当然ながら書き込みはできなかった。
ところが，サラの状態で出荷し，ユーザーが一回だけ書き込みできる PROM（Programmable ROM）なるものが現れた。
read only なのに書き込みができる？？？
そのあと，書き込んだデータを消去することで何回でも書き込みできるタイプも現れた。こちらはとくに EPROM（Erasable PROM）と呼ぶ。
PROM と言った場合，EPROM を含む場合と，EPROM 以前のものに限って使う場合とがある。
こうなってくると，もう「どこが read only やねん！」と突っ込みたくなる。
コンソールとターミナル
console は（よく知らんけど）もともと大型計算機の操作卓・操作盤みたいなものを指していた。
おぼろげな記憶では，ゴツイ机みたいのが物理的に存在していて，そこにモニターやらキーボードみたいのやスイッチみたいのが付いた写真を見たような気がする。
しかし，ブラウザーの開発ツールについてくるアレは何だ。一種の REPL だよな。アレがコンソールに見えないのは私の想像力が足りなのかな。
ターミナルというやつも，元々は大型計算機から伸びた通信回線の端っこに設置された装置だから「端末＝terminal」だったわけで。
当時を知らない人にはなぜ〈黒い画面〉を「ターミナル」（交通機関の発着場？）と呼ぶのか，ワケ分からんのではないだろうか。
おわりに
新しい概念を表す適当な言葉が見当たらないとき，既存の語彙の中からかなり大胆に借用する，ということは，それぞれの言語の歴史の中で繰り返し行われてきたこと。
最初は誤用でしかないように見えても，定着して多くの人がおかしいと感じなくなることも少なくない。それはそれでいいのかもしれない。
ところで，記事のネタとしては他にも「代入」「関数」「実引数／仮引数」などいくつか考えていたが，力尽きたのでこのへんで。