SQL は高水準言語

当たり前の話ですが、SQLは現在流通している中では、最も人間に近い高水準言語で、それを低水準言語でラップしても意味がない。

ベンチャー社長で技術者で: 白熱（炎上）したのでまとめ。

SQL isn't mentioned around here all that often, so I am glad we can at least remind ourselves from time to time of the most heavily used declarative language out there by posting SQL puzzles and hacks...

Solving a Sudoku with one SQL-statement, Lambda the Ultimate

Lambda the Ultimate 引用の拙訳：

SQL については、この界隈では、全くと言ってよいほど語られない。そのため、 SQL パズルやハックをここで紹介することで、この最も広く使われている宣言型プログラミング言語について、ときどきは思い出すことができる、ということだけでも良いことだと思う。

オブジェクト指向プログラミングもそうかもしれませんけど、プログラミング言語がより抽象化の方向へと向かったとしても、誰でもできるようになる、というものでもないのかもしれませんね。

日本の IT 産業はオープンになれなかった

かなり以前のことだが、日本のあるITコンサルティング会社の経営トップにこう聞かれた。私が答えに窮していると、その経営トップはズバリ言った。「ユーザー企業のレベルが低いからです」

なぜ、日本のIT産業は世界で勝てないのか？ - 記者の眼：ITpro

ユーザ企業のせいにするのは、八つ当たりというものだと思うわけですけど。

オープンシステムで、米国企業が圧倒的な優位に立ち、一方、日本企業がそうなれなかった理由というのは、一言でいえば、文化の違いじゃないですかね。

例えば、こんな話はどうでしょう。

．．．

日本の大手ハードウエア・メーカーから、 PC サーバ機を購入すると、”簡単セットアップ CD” みたいなやつと、日本語で懇切丁寧に書かれたマニュアルが付いてきます。

米国メーカーから購入すると、英語・中国語・日本語兼用の、ペラ一枚の ”Quick Start Guide" だけが付いてきます。

日本メーカーの PC サーバ機のカタログは、写真つき・色つきの豪華なもので、見た目が華やかです。今ですと、「仮想化対応」を高らかに謳っていたりします。が、サーバ筐体の中に、どのデバイス・メーカーのどの製品が使われているか、といった情報はどこにもありません。

米国メーカーのカタログは、白黒で非常にそっけなく、まんまスペック・シートであったりします。そのため、見た目は地味ですが、サーバ筐体の中に、どんなデバイス・メーカーのどの製品、どのチップ・セットが使われているか、事細かに書かれていたりします。

日本メーカーの PC サーバ機には、もちろん、有名海外メーカーのデバイス/チップセットが使われています。 しかし、デバイスのベンダー ID 、デバイス ID を、自社工場で書き換えていたりします。

米国メーカーの PC サーバ機は、供給元のデバイス・メーカーのベンダー ID 、デバイス ID 、そのままになっています。

．．．

こうしたことに気付いたのは、大手日本メーカー製の PC サーバに、自分で Linux OS をインストールしようとしたときでした。 型落ちの PC サーバ機があったので、開発用に使おうとしたのですけどね。で、見事にハマリましたとさ。

思うに、大手日本メーカーは、 PC サーバ機でも、顧客囲いこみで売る戦略なんですよね。メインフレームの売り方で PC サーバを売っているような感じです。

もちろん、これは日本のユーザ企業がそれを求めているからこそ、そうしているのだと思うわけですけど。日本のユーザ企業が、メーカーの「手厚いサポート」を求めているのも確かなわけで。米国メーカーみたいに、売った後は自分でなんとかしてくれ、みたいなのは、あまり好まれないように思います。

とはいえ、オープンシステムの文化というのは、まさに米国メーカーのそれ、 Do it yourself なんですよね。

オブジェクト指向分析設計は万能薬なのか

業務システムにオブジェクト指向は要らん発言とか。

企業の業務システム、といっても色々あるわけですけど、一般にその言葉が指していると思われる、販売管理、在庫管理、会計、といったシステムについて考えるとして。オブジェクト指向というのは、本当にそうした分野にフィットするものなのか、と思うのですよね。

こうした業務システムというのは、もともと企業の中を流通しているデータを扱っているわけで。そうしたデータというのは、それ自体が動作を持つものじゃなく、あくまで人間が解釈して情報として使うためにあるものだと思うわけです。例えば、「商品」、「売上」、「在庫」といったものを、オブジェクト指向のオブジェクトととらえても、それ自体に直感的に動作が付随してこない感じで、今ひとつだと思うわけです。

もともと、オブジェクト指向という概念が、シミュレーション・システムのプログラムに直感的な表現方法を与えるためのものだと考えますと。やはり、フィットする分野とフィットしない分野があるのではないですかね。

例えば、電子回路の設計、およびシミュレーションに使われている、 VHDL みたいなのは、オブジェクト指向に物凄くフィットしそう。電子回路を構成する素子というのは、それ自体が、状態と動作を持ちますから、オブジェクト指向で、直感的に表現できるものだと思うのです。

どんな技術にも、向き不向きというのはある、と思うのですよ。

以下、余談。

オブジェクト指向プログラミング言語については、一定の意味はあると思います。一番大きいのは、変数のスコープを、言語ユーザ自身で定義できるイディオムを手に入れたことじゃないですかね。

Lisp でいうところの、クロージャのような役割ですが、 クロージャと異なるのは、有限回しかスコープをネストできないこと。クロージャは再帰によって無限回ネストできますから。

この有限回しかスコープをネストさせない、というのが、オブジェクト指向プログラミング言語の本質に関わる部分なんじゃないかな。そう考えると、 Java にクロージャを持ち込むことに、 Java 言語のデザイナが頑強に反対している理由がわかるような。

SQL を実行時毎に組み立てなければならないとき

まあ、全くないわけじゃないのですけど。

例えば、アプリに、項目の並び順を、ユーザに指定させるような機能があるときとか。そもそもパラメータが使えない構文要素ですと、どうしようもないわけで。

ただ、検索条件の指定みたいに、SQL の 条件句に入ってくるのは、パラメータを使えば、 SQL の組み立ては、 基本、 1 回で済むはずなのですよね。

例えば、商品（書籍）に対して、以下の条件を使って検索できる機能が、アプリにあるとします。

• タイトル
• 発売日
• 出版社
• 著者名

この場合、以下のように SQL を作ればよいですね。

require 'pg'

SQL_ITEM_SEARCH = <<EOS
select
i_title,
i_pub_date,
i_publisher,
a_fname,
a_lname,
a_mname
from item i
inner join author a
on i.i_a_id = a_id
where
(i_title = $1 or $1::varchar is null)
and (i_pub_date >= $2 or $2::date is null)
and (i_pub_date <= $3 or $3::date is null)
and (i_publisher = $4 or $4::varchar is null)
and (a_fname = $5 or $5::varchar is null)
and (a_lname = $6 or $6::varchar is null)
and (a_mname = $7 or $7::varchar is null)
order by i_pub_date desc, i_title
EOS

conn = PGconn.open(
:dbname => 'dbt1',
:hostaddr => '127.0.0.1',
:user => 'postgres')
conn.set_client_encoding('SJIS')

res = conn.exec(
SQL_ITEM_SEARCH,
[nil, '2000-01-01', nil, nil, nil, nil, nil])

res.each { |t| p t }

初心者向けプログラミング言語

そもそも、この言葉自体、なんか、おかしいですよね。

どんなプログラミング言語を使おうと、それがチューリング完全であれば、計算できることは同じわけでして。

初心者がプログラミングできるようになる言語

というのは、存在しないのですよ。

誰でも英語ができるようになる教材

と同類ではないですかねえ。

本屋にいけば、プログラミングの入門書が平積みになっているのを見ることができるのですけど。これって、英語の入門書が平積みになっているのと同じではないかと。それだけ、入門レベルで挫折する人が多い、ということを示唆しているのではないですかね。

PHP をやって過去の謎が解ける

以下のようなコードの「出身地」は、 PHP ではなかろうか。

if (x == true ) { // do something. }

以前、 Java の Web アプリで、

• 変数がすべて文字列型
• SQL を毎回メソッド呼び出し時に String で構築
• ていうか、なんで PreparedStatement 使わない？

というのを見たことがあるのですけど、これも「 PHP 風」ですね。

PHP には MySQL 関数群というのがあって、これが、

• パラメータ使えない
• クエリ結果を全部文字列の配列で返す

という、かなり変わった特徴があるみたいです。

ただし、PHP 5 からは、 MySQLi ( MySQL Improved Extension ) というのが入ってます。これは、パラメータが使えて、一見 DBI 風。が、クエリ結果は文字列の配列で返すみたい。なんで？

<?php
$a = array(true, false, NULL, 0, 1, '', '0', '1',
  0.0, 1.0, array(), array(1));
var_dump($a);
foreach ($a as $k => $v) {
  echo "$k: ";
  if ($v) { echo "true\n"; }
  if (!$v) { echo "false\n"; }
}

カオスな実行結果:

array(12) {
  [0]=>
  bool(true)
  [1]=>
  bool(false)
  [2]=>
  NULL
  [3]=>
  int(0)
  [4]=>
  int(1)
  [5]=>
  string(0) ""
  [6]=>
  string(1) "0"
  [7]=>
  string(1) "1"
  [8]=>
  float(0)
  [9]=>
  float(1)
  [10]=>
  array(0) {
  }
  [11]=>
  array(1) {
    [0]=>
    int(1)
  }
}
0: true
1: false
2: false
3: false
4: true
5: false
6: false
7: true
8: false
9: true
10: false
11: true