またWeb検索をしてたら次のような記事を見かけた。
 | これで解決SQL ServerからOracleへの移行ガイド 井上 一也 (株)マイナビ出版 |
ん〜〜。
いや、色々ととんでもない勘違いがある。
そもそも、
> GUIアプリすら作れないし、データベース操作に特化した、C++やJava、Pythonにくらべたらほぼ何もできないに等しい超絶不人気言語。
プログラミング言語とプログラミング言語「じゃない」ブツを比べてもしょーがないだろ、と言う(※1)。
この辺の比較は、平たく言ってしまえば、「プログラミング言語」と(敢えてVBAを使わず)、いわゆる素のExcel(要は表計算プログラム)の「関数」を比べてるようなモンだ。比較対象にならん。
そして、SQL(※2)が「超絶不人気言語」と言う情報をどこから持ってきたのだろうか。ユーザー数が多い、って意味で言うとSQLは全然逆で「超人気言語」だ。
例えば世界最大のSQLのユーザーはGoogleだろうし、間接的に僕らが検索する際にSQLのお世話になっている。Googleの使ってるデータベースは、MariaDBと言うSQLを使ったリレーショナル・データベースだ(※3)。
つまり、「SQLを選択するのは"人の行く裏にある道"」なんかじゃない。むしろ堂々とした表通りだ。"人の行く裏にある道"と言うのは、例えば龍虎氏が現在熱中してるPrologなんかの言語の事を言うんだ(笑)。
繰り返すけど、SQLはドメジャーもメジャーな言語だ。
そこは花の山、なんかではない。言っちゃえばWebプログラマなんかは誰でも使ってるブツだ。
そもそも、いわゆる「プログラミング言語」とSQLには対立構造なんざない。デスクトップアプリケーションのプログラマに対しては必然性は若干落ちるが、一方、Webプログラマにとっては「自ら習得して得意としているプログラミング言語」の他に、SQL及びリレーショナル・データベースの使い方、なんつーのは必須知識となるだろう。
例えば。このgoo blog。仕様は良く知らんが、恐らくMovable Typeをカスタマイズして使ってると思う(※4)。
Movable Typeは例によってリレーショナル・データベースであるMySQLを利用するようになっている。結果、現在は?NTT docomoに所属してるWebプログラマ達にとっては、goo blogをメインテナンスする以上、SQL及びリレーショナル・データベースの知識は必須となる。
また、通常、僕や貴方のアカウントの情報等の管理、あるいはブログのページの管理、なんつーのもSQL搭載のリレーショナル・データベースなしではどうにもならんだろう。
繰り返すが、特にWebプログラミングに於いてはSQLとリレーショナル・データベースの知識は必要不可欠なんだ。
ユーザー数を考えなければ、確かにSQLは「超絶不人気言語」かもしんない。と言うのも構文がヘンテコリンなんだ。
以前もどっかに書いたが、そもそもSQLと言う言語はCOBOLと言うプログラミング言語と合わせて使う事を想定して設計されている。COBOLの文法と違和感がないように設計されてるんだが、平たく言うと、これが間違ってたんだ(笑)。
COBOL(Common Business Oriented Language: 共通事務処理用言語)はその名の通り、オフコンで使う事を想定して作ったプログラミング言語なんだけど、言っちゃえば、事務処理をやるような文系の奴らはプログラミング言語を扱う能力が欠けていると言うとんでもない前提の下に設計された言語なんだ。
従って、バカにも分かりやすいように、と自然言語の英語に極めて近い表現で記述されるように調整されたプログラミング言語なんだな(※5)。ある意味発想は「なでしこ」に近いかもしれんが、Forthに影響を受けただろうパワフルな「なでしこ」と違い、マジで英語を構文解析しよう、なんつーのは洒落にならん程難しい。
結果、「自然な英語表現」とトレードオフになったのは「言語のパワー」だったんだ。
例えばPythonで
age = age + years
とか、Lispで
(setq age (+ age years))
と書けば済むトコをCOBOLでは
ADD YEARS TO AGE.
等と記述する。数式を書くと言うより「英文を記述する」に近いし、前置詞なぞも出まくりなんだ。
この辺はプログラミング言語として考えると「冗長」、つまり「何かする度に記述が長くなる」と言う事を意味するが、SQLはモロにこの影響下になるように設計されてるわけ。
従って、SQLは
INSERT INTO 表名(列名1,列名2) VALUES(値1,値2)
みたいな「前置詞塗れ」で「英語としては自然な」記述を要求するような仕様になってるんだ。
・・・・・・と言うより、「英語での表現の正しさ」に集中した余り、クエリ言語としての自由さを手放したような言語になってしまっている。
もう一つのSQLの「超絶不人気」な理由は、厳密に言うとSQLに完全に準拠したリレーショナル・データベースがこの世に存在しない辺り、だ。
SQLには標準仕様が制定されている。何故に標準仕様が制定されているのか、と言うとA社のデータベースとB社のデータベースで「使い方が違う」となれば困るから、だよな。標準的な「問い合わせ」がどのデータベースでも使える、となればユーザーは混乱しない。
ところが、これがSQLに於いては「単なる理想論」なんだよ。SQLは仕様がデカい事もあり、全リレーショナル・データベースがSQLを完全に実装してる、って事がないんだ。
しかも上に書いた通り、「問い合わせ言語」としては自由度が低い。そこで、データベースを販売している各社が、「プロシージャ」と名乗る問い合わせ言語を各自開発して「不完全なSQL体系」を補完するようにしている。当然各社の「プロシージャ」は同じモノではない。結果、A社のデータベースからB社のデータベースに乗り換えると、当然ユーザーは混乱するわけだよな(笑)。
つまり、リレーショナル・データベースのSQL及びプロシージャには「標準」が事実上存在しないんだ(笑)。往年のBASICみてぇになってやがる(笑)。結果、多かれ少なかれ、プログラマはデータベースの「引っ越し」を避けたがるようになり、囲い込みが成立するわけだ(笑)。
それがSQLやリレーショナル・データベースの「現実」だ。
とは言っても、繰り返すが、まずは特にWebプログラマにとってはSQLやリレーショナル・データベースの知識は必須となる。と言う事は「Webプログラミングも出来るよ」と言ったようなモダンな言語処理系だと、大体のトコ、SQLを利用したデータベースへと「接続する」機能も提供してるわけだ。
データベースを利用したプログラミングでは、いきなりMySQLやMariaDBのような「本格的な」データベースを使うより、ここ十数年では、最初にまずはSqlite3なんかの1ファイルの、簡易で軽いデータベースを用いてモックアップを作って、上手く動く事を確認してから本格的なMySQLやMariaDBなんかに接続する例が多い。
例えばRacketではsqlite3をインストールしたら、このようなコードを書けばsqlite3でのデータベースとやり取りが出来る。
大体のパターンでは、SQLでの命令そのものは文字列として記述してリレーショナル・データベースへと送り込む。
Pythonでは名指しで、それこそsqlite3と言うモジュールが提供されている。
PythonでRacketみたいなコードを書くとこのようになるだろう。
RustにもPythonのsqlite3モジュールのようなrusqliteと言うライブラリ(クレート)が提供されている。もちろんここでは詳細には入らないが、sqlite3だけじゃなく、一般的な他のリレーショナル・データベースへの接続ライブラリにも事欠かない。
いずれにせよ、プログラミング言語とSQLは別に排他的な関係ではない。繰り返すが、「プログラミング言語を利用して」SQL利用のリレーショナル・データベースを利用するのは「あまりにもフツー」の行為だ(※6)。
もっと言うと「プログラミング言語を操れないで」SQL「だけ」知ってる、って人の方が稀だろう。
繰り返す。ユーザー数で言うとSQLは超絶不人気言語でも何でもない。ただし、上で見た通り、「構文がヘンテコリン」なんで、そういう意味では超絶不人気言語ではある。
そして、
> SQLは実務レベルの本がゴロゴロ出ている。
ってのは、単にユーザー数が多い、って事の裏返しだ。そして言ってるレベルは
> Excelは実務レベルの本がゴロゴロ出ている。
と大して変わらん。そりゃユーザー数が多ければ実務レベルの本はゴロゴロ出ざるを得ない。
SQLは「人の行く裏に道あり花の山」でも何でもない、って事だ。
もうちょっと付け足すと、「構文がヘンテコリンなSQLをもうちょっとマシな構文でラップ出来ないか?」と言う試みがある。
例えばPythonだとSqlAlchemyと言う外部ライブラリが有名だ。これはORMと呼ばれる技法を使って、オブジェクト指向プログラミングと相性が良いようにSQLをラップしたモノ、と考えていい。
SqlAlchemyを使って上のPythonのコードと似たようなコードを書くとこうなる。
コード量から言うと明らかに素のSQLを文字列で記述したコードより増えているが(笑)、一方、コードの記述形式は一般的なオブジェクト指向のそれ、になっていて、SQL自体が消えてしまったように見える。
オブジェクト指向に対しての好き嫌いはあるが、オブジェクト指向に慣れてるプログラマにとっては、「Pythonでオブジェクト指向を使ってデータベースを操作出来る」と言うのは魅力的ならしい。
問題は、オブジェクト関係データベースと言う概念がまだまだポピュラーじゃない事、そして細かいトコを言うとSqlAlchemyに関してのマトモな解説書がいまだ日本じゃ登場してない辺りじゃないか。
いくつかKindle版で0円書籍が出てるは出ているが・・・・・・。
いずれにせよ、こういう「試み」は、SQL及びリレーショナル・データベースは「使わなきゃならないから使う」と言う事で、プログラマにとっては愛憎半ば、と言った理由があるからに他ならない。
「もっとマトモなクエリ言語が欲しい」と言う要望が確かにある、と言う意味では「SQLは超絶不人気言語」ではある。
あと、もう一つだけ付け足そう。
> 食っていけなくなるのを恐れて必死になって情報を直隠しにしているバカ共ばかり。
> ググれば良いだのGitHubにソースコードがいくらでも出ているだのウソをつきまくっている。
別に情報を直隠しにしてるわけじゃないと思うが。
単に「知らん事は書けない」だけじゃないか。
アプリケーションソフトの作り方に対する「一般論」に対して記述してる本と言うのは、毎回言ってるが、ANSI Common Lispでしか出ていない。
 | 実用Common Lisp ピーター・ノーヴィグ 翔泳社 |
REPL(Read-Eval-Print Loop)を礎としてソフトウェアを書け、と言う示唆をしてる本はこの本ともう一冊くらいしかなく、プログラミング言語はANSI Common Lispだ(これも「人の行く裏に道あり花の山」な言語だ)。
他の言語の××入門なんつー本はその言語の簡易リファレンス程度の記述しかしていない。よってそういう本を読んでもソフトウェアは書けるようにはならない、と言う事は何度か指摘してる。
そしてググったとしても、「コンピュータサイエンス的なバックグラウンド」を知ってる人が書いた記事は少ない、ってのも事実だ。「コンピュータサイエンス的なバックグラウンド」を知らない(あるいは理解してない)人が書いたコードってのは「場当たり的」になってて参考にならん、ってのは同意しよう。理論的で、美しくて、ってコードを書ける人は少なく、それこそ日本人ではGaucheの作者の川合史朗さんくらいしかいないかもしんない。
ただし、GitHubに「参考に出来る」ソースコードがない、ってのには同意出来ない。GitHubには完動品としてのソフトウェアのソースコードが山ほどある(※7)。ここで「無い」って言っちゃえば一体どこにある、って言うんだろうか?
また、生成AIが辛うじて(ホント辛うじて、だ・笑)プログラムを書ける、と言うのはGitHub辺りをデータベースにしてるから、だ。これらソースコードのWebホスティングサービス辺りが無ければ生成AIが「プログラムを記述する」なんつーのは不可能だろう。
よって「実際に動く」「参考になる」ソースコードが山ほどある、って考えた方が正しい。
となると、単に
- ソースコードが読めない
- あるいはソースコードの読み方を知らない
かどっちか、って事になる。GitHubのせいじゃない、って事だ。
Rubyの作者のまつもとゆきひろ氏がこういう記事を書いている。
こういう記事を参考にすべきだ。
そして「ソースコードは文芸書」じゃない。Webでチンタラ読んでてもそりゃ読めないだろう。
一方、若い世代なら、Visual Studio Codeでも似たような事は出来るだろう。要は必要なのはソースコード内での「検索機能」と「ジャンプ機能」なわけだ。
ブラウザで漫然とソースコードを眺めていてもそりゃ「分からない」だろう。GitHubならgit辺りで手元にソースコードをダウンロードする。そしてVisual Studio Code辺りでソースコードを開いて気になるトコへ「ジャンプして」読むんだ。
取り敢えず「ソースコード読解の為のツール」を使わないとお話にならん、と思う。
以上。
 | Code Reading―オープンソースから学ぶソフトウェア開発技法 トップスタジオ 毎日コミュニケーションズ |
※1: 実の事を言うと、SQLは「チューリング完全」だと言う話ではある。・・・つまり、プログラミング言語としては必要充分な機能を持っている。
言い換えると、やろうと思えば、他のプログラミング言語のように「GUIアプリ」も作れる、って事だ・・・問題はそれが「やりやすい」か「やりづらいか」って辺りではあるが、「理論的」にはそうなる。
※2: SQLはStructured Query Language(構造化問い合わせ言語)の略称で、これも標準化されている。日本ではJIS(日本産業規格)でJISX3005-1:2014とJISX3005-2:2015として制定されている。・・・実は往年では全部で14部前後もある巨大な仕様だったらしい(笑)。現行ではどうなってるのかさだかではないが、SQLはかなり巨大な言語仕様を抱えている。
ISO(国際標準規格)では2021年辺りからSQLの改定に入ってるらしいが、全体で22部くらいある、と言う(笑)、超巨大仕様になっていて、いずれJISもこれに従うのか(笑)。
いずれにせよ、これを見ても分かるだろうが、放ったらかしになってるワケでもない、って辺りでSQLの(実務的な)人気は伺えるだろう。
※3: GoogleはかつてはSun MicrosystemsがスポンサーになってたMySQLと言うオープンソースのデータベースを使用してたが、OracleがSunを買収した事で、プロプライエタリの雄、Oracleを嫌い、MySQLからフォークしたMariaDBへと移行した。
いずれにせよ、世界最大の検索エンジンを抱えたGoogleは最大のSQLユーザーであり、SQLを利用したデータベースが無いと検索がそもそも成り立たない。
※4: Movable Typeはブログを作成するソフトウェアで、CMS(Content Management System)と呼ばれる分類のプロプライエタリ・ソフトウェアだ。日本の大手のブログサービスだとどれもMovable Typeを利用してて、恐らくgoo blogも例外ではないんじゃないか(つまり、見た目が違っても実質中身は同じだ、と言う事になる)。
かつてはMovable TypeのライバルがGoogleに買収されたBloggerで、Googleに買収されて暫くしても、ダウンロード可能となってて、自分の利用してるサーバーにインストールして自分でブログを構築出来た。
後発で、現在、Movable TypeのライバルとなってるのがWordPressで、こちらはMovable Typeと違ってオープンソースのソフトウェアとなる。諸外国では利用例は多いが、日本の大手ブログサービスでの利用例は殆どないだろう。
※5: 別に僕がそう思ってるわけじゃなくって、明らかにCOBOLの設計思想がそうなんだ(笑)。
個人的には実際は、プログラミングこそ文系向きだと思ってる。そこまでプログラミングって理論的じゃねぇよ(笑)。必要なこたぁ「人の手のひらの上で踊る」能力であって、論理性なんざそんなに関係ねぇ(笑)。
しかし、プログラミングは「理工系ジャンル」って事にしたくて、そこで偉ぶりたい人たちがいるんだろ(笑)。
事実はそうでもねぇぞ(笑)。
※6: ニッチな分野・・・とも言えないが、例えばリレーショナル・データベースの利用法の一つとして統計解析がある。統計解析では大量のデータを要する為、Excel等の表計算ソフトの他、もっとデータがデカいとどうしてもリレーショナル・データベースに頼らないとならない。
統計解析専用のオープンソースのプログラミング言語処理系にRと言う処理系がある(R言語、と呼ぶ人もいるが、厳密にはこれは商用のS-PLUSと言う言語のクローンであり、つまり、言語的にはS-PLUS方言だ)。
当然解析対象としてのツールにはリレーショナル・データベースがあり、Rでも自在に各データベースに接続出来るライブラリが提供されている。
(Googleでもデータ解析をする際にはRを用いてる、と言う話を聞いた事がある)
※7: 「完動するソフトウェア」と言っても、コンパイラ型処理系に対しては実行可能ファイルではなく、それこそ「ソースコード」で提供される。インタプリタ型処理系ではその限りではないが、いずれにせよ「実際に使える」ソフトウェアが山程揃ってる以上、「参考に出来る」ソースコードだらけだ、と言う事だ。
なお、いつぞやも書いたが、githubと言うのはソースコードホスティングサービスの一つで最大のサイトになっているが、同種のサイトにSourceForgeなんかがある。
そして、これらのWebホスティングサービスは、バージョン管理システムと密接な関係があり、ローカル(手元のPC)で作ってるソフトウェアを随時「Web上に公開しつつ」「保存」出来るのがその意図、となる。
githubはバージョン管理システムgitを使用する前提のWebホスティングサービスだ。Windowsなら、gitをGUIで扱えるtortoiseGitが有名。これを使うと手元で書いてるアプリケーションソフトを右クリックで簡単にgithubへとアップロード出来たり、あるいはgithubに既にある「他の人が作った」ソフトウェアのソースコードを丸ごとダウンロードする事が可能だ。
また、RacketやPythonでの外部ライブラリモジュールのインストールも、実際はgithubから取ってくるように指定してるモノが多い。
 | 入門git ＴｒａｖｉｓＳｗｉｃｅｇｏｏｄ オーム社 |
