今のプログラミング言語は，アルゴリズム （計算手順） を書き下す （だけの） ものなんですよね．

なので，初心者にプログラミングを教える際 「どうやってアルゴリズムを作れば良いのか ?」「熟練者は，どのように発想しているのか ?」 ということを教える際には，向きません．これがプログラミング教育の本質的な難しさです．

アルゴリズムを作るための方法論と，それを表現できるプログラミング言語が無いから，結局はたくさん本読ませて，問題解かせて，自分で勉強してがんばってね，数こなせば自然とわかってくるから，という前時代的な教育しかできないのです．これでは脱落者がたくさん出てしまっても無理はありません．

amachang さんががんばってます．執筆中のマインドマップを引用するってのは，ちょっと申し訳ない気もするのですが，面白い一文を発見．

IT 戦記 2008-07-15 プログラミング未経験者が JavaScript でプログラミングをするために必要なこと
僕はプログラミングというものをこういう風に思っています。

「状態と機能をたくさん持ったモノ」（例えば、パソコン）に、「こうだったら（状態）、こうする（機能）」という「ルール」を書いていって「便利なモノ」（例えば、ゲーム）を作る作業がプログラミングである。

これは全くその通りなのだと思いますけど，現在のプログラミング言語は，こういう人間の自然な思考（？）を素直に書き下すようにはできてないんですよね．

我田引水ですけど，僕は北大の一般教養で，今 TA やってます （問題解決プログラミング/人工知能プログラミングの両クラス合同演習）．

# 人工知能とか大仰な講義名ですけど，学部一年レベルの講義なので，ようするに，ちょっと高度なアルゴリズムのことです．全学共通科目なので，工学部や情報系以外の学生もウェルカムな講義ですし （まぁ，ほぼ全員が理系だと思いますけど）

プログラミングどころか，パソコンのタッチタイプすらおぼつかない大学新入生相手に，いきなり ET という変なプログラミング言語を使って，アルゴリズムの作り方 （発想法） を教えています．

よくある「プログラミング」を教える講義，すなわち，アルゴリズムの書き下し方 （コーディング） を教えるのではありません．アルゴリズムの作り方，考えるための方法論を教えている (つもりの，ことを目指している) 講義です．

それは，例えばプログラミング言語 Ruby は，（いろいろ理由があると思いますが）学生が学習しやすい，とかいうレベルの話ではありません．

ET 言語は，ルールベースなので，通常のアルゴリズムを書き下す言語とは，根本的に異なるのです （もちろん，普通に，アルゴリズムを書き下すこともできますが．それは清書用で，むしろどうやって考えるか，考えるための道具の方が重要）

ルールというのは，amachang の定義を借りれば，

状態，｛条件} --> こうする．

という，まさしく自然な発想をそのまま書き下すような表記になっています．

そして，具体例をたくさん書き並べていくだけで，それもある種のプログラムとして実行可能です (算術演算アトムの記法が，Lisp というか，S 式ライクで微妙ですが… まぁ，全くの初心者の場合，こう書くんだよ，と言うと，案外素直に覚えてくれるものです．逆に，脳が C とか VB とかに汚染されている子（笑）の場合は，ちょっと戸惑ったり苦労しているみたいです)．

(factrial 0 *x) --> (= *x 1).
(factrial 1 *x) --> (:= *x (x 1 1)).
(factrial 2 *x) --> (:= *x (x 2 (x 1 1))).
(factrial 3 *x) --> (:= *x (x 3 (x 2 (x 1 1)))).

いろいろルールを書いていくうちに，何らかの法則性が見えてきたら，より一般的なルールを書くと．

(factrial *n *x) --> (:= *n1 (- *n 1)), (factrial *n1 *x1), (:= *x (x *n *x1)).

# ちょっとトリビアルすぎる例ですが… 実際の講義では，非常に簡単で具体的な例題 （長さ 3 のリストの 2 番目を取り出すルールを書け，とか） から，徐々に一般的で複雑な例題に (任意の長さの整数リストの各要素の値を n 倍したリストを作るルールを書け，のように) 発展していきます．

実際には，D ルールには優先順位がある （同じ状態と条件に対して適用可能なルールが複数存在する場合，先に定義されたルールが，後に定義されたルールよりも優先的に採用される） のですが，条件を順序に依存しないようにちゃんと書けば，順番さえ任意です．

ルールベースのプログラミング言語は，条件を工夫したり，効率化するためのルールを追加していくことで，試行錯誤しながら，自然とルールを積み上げ，アルゴリズムを構築していくことが可能な枠組みになってます．

---

今年は，運営の方から微妙に関わらせていただき （ほんとに何も協力できませんでしたが…），スタッフも微妙にやったりやらなかったりしました．あと，セミナー発表の機会もいただきました．
いろいろあったけど，終わってしまったら一瞬だったなぁ，ってのが素直な感想です．
大変良い思い出になりました．みなさまお疲れ様でした！

セミナー資料は，OSC 事務局に PDF 形式で送れば公開してくれるらしいのですが，OSC 事務局のメールアドレスがよくわからないという…

しかも，slideshare に，何回投稿しても失敗してしまいます…

Sorry, your file failed to convert. Here's how to solve this:

- There's a big chance this is just a temporary/random glitch with our servers; just retry after 5 minutes and see if works.
- If your file is password protected, encrypted or contains macros, you might get an OOPs; remove the blocker and try again
- Sometimes uploading the PDF instead of the original ppt/odp file (or vice-versa) helps to overcome the OOPs

Read our FAQ to know more details about conversion failures and how to avoid them.

しかたが無いので，とりあえずテキトーに odp から ppt に変換して Google Docs の方に上げておきました (odp には未対応らしい…)．かなり崩れてしまってます… いろいろ切れてるし，インデントとかがグチャグチャ （OSC 側での PDF 公開を前提に，PDF に最適化して作って，Acrobat reader で発表した）



今回，やっと念願の OSASK 川合さんのサインを 30 日 OS 本にもらうことができました （笑）




例年，午前中のセッションは動員数が少ないので，起爆剤として川合さんの OSASK を一発目の頭に持ってきたわけですが… やっぱり，午前1は客数が伸びずに，せっかく自費で来ていただいたのになぁともうしわけない気分になったりもしました．何よりも非常に面白いセッションだったのに，ustream 中継の準備も，協力も得られず，もったいなかったなぁと．

内容的には，第二世代 OSASK の変態的 4 ビットを基本にした画期的な実行ファイルフォーマットにより，hello, world が 27 バイトで書けるようになった！とか，コードゴルファー垂涎のネタが多数 （笑） ustream してたら，絶対 shinh さんとかすごい喜んだろうになぁ… と歯がゆい気持ちながら，楽しませていただきました．

次は，タイムキーパーとして，NTT データさんの hinemos のセクションを．当初は，hinemos のことは全然知らなかったので，特に興味も無く，単なるスタッフの仕事として聞き始めたわけですが．運用管理の OSS ってほとんど聞きませんし，かなり便利そうだったので大変興味深く聞くことができて，掘り出し物的なセッションでした （失礼）

あと，日本 Ruby の会の高橋会長にも，ようやく名刺をいただきました (2 年越しぐらいの念願叶い．毎回切らされていた感じだったので w)

---

会場設営の後，さっきまで前夜祭やってました．みんな前日なのに飛ばしすぎでうけました．確かに，準備終わっただけでも満足してしまう気持ちもわかりますが，本番は明日ですからね （笑）

当日のタイムテーブル

自分が発表する GCC Hacks が， 6/28 16:00-16:45 に，RubyKaigi でも大活躍だった Ruby Sapporo 様により配信予定です．

http://ruby-sapporo.org/live

自分のテーブルの人たちがみんな酔っ払いまくりだったので，僕も油断してご機嫌になってたんですが，実は明日発表あるスタッフが，僕以外に誰もいないテーブルだったという TRAP of 孔明にも負けずにがんばってきます （笑） ウコンの力 3 袋飲んだし，大丈夫だろう．風邪と頭痛対策に葛根湯も．ビタミン B 群をビール酵母で摂取．ジャック・ハンマーばりのドーピングでがんばります．「今日発表が上手くいくならば，明日はいらない」という覚悟で．筋肉痛が怖い．プロテインほしー

明日は朝 8:45 からずっと OSASK と自分のセミナー発表の時以外は，スタッフとしてバタバタしているはずです．人手が足りなかったため，うちの彼女も昼過ぎごろからスタッフとして応援にかけつけてくれる予定になってます．

（2:16）

---

soutaroにっき 2008-05-30 ■セマンティクス
ひげぽん OSとか作っちゃうかMona- 2008/05/30 セマンティクスって？

セマンティクスを議論するためには，計算モデルを決めないといけません．

計算モデルが決まれば，状態の表現方法が決まり，「計算」という概念が決まります．

計算というのは，状態変化の列のことです．

計算が決まれば，計算とプログラムの対応関係を決定することができます．

その，対応関係のことが 「意味論 (semantics)」だと思います．

任意のプログラム空間 P 内のプログラム p ∈ P と，任意の計算空間 C 内の計算（状態の変化列） c ∈ C の組 ＜p, c＞ が意味論という気がします （いや，メチャクチャテキトーで，個人的なイメージですけど）

ここらへんを真面目に考えているのは，たぶん等価変換計算モデル(Equivalent Transformation Computation Model) だけで，他の計算モデルは，一つに決め打ちされた，ET 計算モデルという枠組みの具体例の一つ（インスタンス）に過ぎない（と考えられるかもしれない）．

個人的には，構文論(syntax) ってのは，「プログラムが文字列の形で書かれる」 ことに由来するもので，本質では無いと考えています．

プログラムと，計算という構造のマッピングである，意味論こそが本丸であると．プログラムの見た目などどうでも良いのです (意味論さえ明確ならば)．

操作的意味論ってのは，まぁ定式化にはいろんなスタイルがあるわけですけど，TAPL とかでは，状態を項(term)で表現して，それを書き変える推論規則の集合で意味論（プログラムと計算の対応）が定義されるのかなと．推論規則が，term を値にするものか，term から term にするものかの違いで，big step とか small step とかスタイルがあるそうです．

表示的意味論ってのは，文字列（プログラム）と数学的オブジェクトの対応関係を定義することで，意味論を与えるものだと思います．soutaro さんが，別のプログラムに変換する規則を与えることで，意味論を与える方法があるとか書いてますけど，ある意味でこれは，プログラムを数学というプログラミング言語に変換することによって，意味論を与えているのと同じこと（かもしれません）．

公理的意味論は，論理プログラミングという，証明=計算というパラダイムと強く結びついているので，わりとそのまんまです．プログラムは公理であり，そこから演繹できる全ての項が意味であると．んで，与えられたクエリ項が，その中に含まれていれば真．いなければ偽という，単純明快．

等価変換計算モデルにおいては，確定節で仕様が記述され，そこから任意有限回の変換で得られるアトムの集合で仕様の意味が与えられます．公理的意味論とかなり似てますが，論理式の証明というパラダイムに依存しない，より一般的で包括的な計算モデルになってます （論理・制約プログラミングやCHR も，ET モデルの具体例の一つであることが証明されています．たぶん，命令型プログラミングやオブジェクト指向プログラミングや関数プログラミングなども）．例えば，論理プログラミングにおける単一化は，特殊化というより一般的な概念のインスタンスです．データ構造も，論理式（一階の項）に限らない，豊富なものを特殊化システムという枠組みによって扱うことができます．同じ意味を得られる変換列（= 計算）は，同じ意味を持つ計算と定義されるので，豊富なプログラムの空間の中から，最適なプログラムを自動探索することが可能になります （詳しくはFormalization of the Equivalent Transformation Computation Modelあたりを）．

形式意味論が無い言語の場合は，人間の頭の中に計算の舞台が存在して，その舞台の変化を頭の中でシミュレートすることで，個人の脳内でソースコードに対して意味論を与えていることになるわけですね．これでは，もちろん自動検証できませんし，何の客観性も無いわけで，正確なコミュニケーションは不可能です （これが，どれだけ正確さを心がけて，アセンブラやプログラミング言語 C などでのプログラミングを人に教えようとしても，どうしても誤解が発生してしまう，本質的原因だと思います）

形式意味論が無い言語は，何が正しいのか，という議論ができません．そんな言語を教えている時点で，大学の計算機科学の講義なんて，ちっとも科学と呼べるような代物では無いよな，と個人的には思ってます．

---

中村正三郎の HOT CORNER : Erlang, Oz/Mozart, Prolog, 単一化 ― 2008年01月02日 10時05分40秒

Prologの入門として、今回発見したのが、
http://www.fujita.soft.iwate-pu.ac.jp/prof_dir/kure/Lecture/Prolog/
岩手県立大学の平成１４年度「知能システム学」Prolog編という講義資料。
　岩手県立大学は、できて２、３年のときにお邪魔したことがある。非常にきれいなキャンパスだった。
　これを書いた槫松(くれまつ)先生の講義のページ
http://www.fujita.soft.iwate-pu.ac.jp/prof_dir/kure/lectures.html
をみると、過去の資料扱いになっているから、もう、直接はPrologは教えてな
いかもしれないね。でも、ちゃんと
http://www.fujita.soft.iwate-pu.ac.jp/prof_dir/kure/Lecture/Lisp/lisptop.html
に、Lispもある。
　関数型Lispと論理型Prologの両方を教えている！　これがまっとうなカリキュラムだよ。＼(^O^)／
　いまは自然言語処理のほうの授業に力を入れているようだが、そういう方面をやると、LispやProlog的なものはやらざるを得ないから、その過程で独習させているのかもしれない。

僕は，平成 14 年 (2002 年) に入学した，岩手県立大学の第 5 期生なんですよね．

# 高校生当時はもちろんそんな用語は知らなかったのですが，今で言う所の，セマンティックウェブやテキストマイニング的な知的システムを作りたくて，自己推薦 （AO）入試で合格しました．中学高校と全然勉強してなかった上に，物理を取ってなかったので，事実上 AI の研究をしたかったら，他に選択肢があまりなかった，というのもあります (通常の国公立大学の工学部の知能 (知識) 情報系ってのは，物理必修がほとんど)

そして，最初に配属されたのが，まさしく ↑サイトの執筆者である槫松先生がいる藤田1研でした （岩手県立大学は，学部1年から研究室に配属され，1人1台 SUN の SPARC WS が割り当てられる (当時)）

その後，同じ知能コースのゴウタム研 (旧藤田2研) に進んで，自然言語処理の研究をするなどしようと思ったわけですが，プログラミング方法論や言語の貧弱さに限界を感じ，より基本的な方面の研究を行うために，修士からは北海道大学の現在の研究室に進学し，現在に至るわけです．

# ちなみに，昨日，無事修士を終了することができました．4 月からは博士課程に進みます．

思いっきり脱線しましたが，学部 3 年の時，コース科目の 「知能機械と自然言語処理」 で，槫松先生にはいろいろお世話になりました．簡単な自然言語の文法パーザ （要するに，曖昧性を含み，パース結果の構文木が一意に定まらないような文法） を作るという課題の時，言語は問わないということだったので，C とかでバックトラックから実装するのはしんどすぎるということで，全く未知の言語であった Prolog に挑戦しました （ゆとり教育の波で，僕の世代は大幅にカリキュラムが削られ，共通演習では C しか習いませんでした．その後，各コースの特性に合わせて，いろいろな言語を独習していくことになります）その時は，m.hiroi さんの Prolog Programming が参考になりました．

正三郎さんも言っているように，関数プログラミングはある程度市民権を得た感じですが，それだけでは片手落ちだと思いますね．例えば onLisp なんかも，Prolog のインタプリタを作るという入門以前のところで終わりなわけですが，Prolog の技芸とかを読むと， Prolog の長い歴史で培われてきた豊かな世界を垣間見ることができると思います．昔の Prolog ブームの時には，他にも大量の日本語の本が出たわけですが，軒並み絶版になってるが惜しいところですね．Prolog の技芸の日本語版は版が古い上に絶版ですが，原著の The Art of Prologはまだあります．

Prolog が寂れた理由については，AI バブルの反動とか，計算モデル自体の限界とかいろいろ非本質的/本質的両面の理由があるのですが．関数プログラミングの方が低水準 (汎用的，基本的) な理論なので，現在でも生き残ってるわけです (Prolog が遅い遅い言われるのは，Prolog が悪いのではなく，むしろ簡単にウルトラハイレベルなコードを書ける，というその特性によるものも多いと思います．同じことを C とか Java とか Lisp とかでやろうと思ったら，やっぱり同じくらい非効率なコードを書くしかなくなります．なので遅いこと自体が悪いのではなく，そこからのチューニングのための手段に乏しいことが悪い)．

そんなこんなで，論理プログラミングから入り，その限界を感じ，現在はそれを根本から克服するための研究をしているので，Prolog に対しては愛憎両面の複雑な感情を持っています．

ヒビルテ : λ. Kowalskiの講演をまた聞き逃す
あろはさんなどはよく論理プログラムをDISってるけどw、論理プログラミングにも面白い話はまだまだ沢山あるように思う。

もちろん論理プログラミングや関数プログラミングという枠組みでも，まだまだ面白い研究はできると思います．しかし，もうそういう狭いパラダイムの区別や慣習自体が古いんじゃないかなぁと．まだ黎明期には，他の研究分野との区別のための意味があったとはいえ，「論理」プログラミングや「関数」プログラミングという，歴史に由来する名前自体が重荷や偏見の原因になりつつあると思います．そろそろ，そういう過去にとらわれず，分野に分かれた研究成果を統合し，より高いレベルの知的プログラミングのための枠組みが必要なのではないかと思います．

---