Moonmile Solutions Blog

再開とは言っても、大学の頃と新人の頃にちょこっと練習していただけなので25年振りという感じですね。当時も今も、何を弾けるという訳ではないので何か疲労できるわけではないのですが（「東京ブギウギ」とか「アタックNo.1ブルース」とか変なブルースソロだけうまくなっています）、少し自由に楽器が弾けるようになると、プログラムとか電子工作の発想に良いかなと。年男なので48歳の手習いですね。

ちょっと自分のメモ用に書き残しておきます。

再開の発端は Julian Lage から

Julian Lage Workshop (Japanese Subtitles)
https://www.youtube.com/watch?v=pfOWWcQeP3Q

常々、死ぬまでにはカントリーとフラメンコぐらいは弾きたいと思っていたのですが、かといって何か対策をしている訳ではありません。ギターも引っ越した後に押し入れの中に突っ込まれたままでした。

ツイッターで勧めらていた Julian Lage のギター教室の映像なんですけど、彼は5歳からギターを弾いていて、映像現在で23歳です。映像自体が5年前なので、現在は28歳です。暫くジャズ・ギターの曲なんて聴かなかったのですが、これはすごい。演奏もすごいけど、彼の理論的な追及の仕方がすごいです。体系的に音楽理論を語っている訳ではないのですが、スポーツ選手が自分の走り方を科学するように、彼はギターの弾き方を科学しています。「科学する」ってのは、現象があって、それを再現できること、少し変えてみて試すことができることですね。漠然とギタースケールを弾いているのではなくて、次のステップにつなげるようにギターの練習方法を語ります。実に実践的です。

私が参考にしたフレーズ（彼の科白）を抜き出せば、

• ６弦を低音／中音／高音の2本ずつに分けてフレーズを作る。これで、ギターを横に（フレット方向に）使える。
• 横方向に長くスケール練習する。音が出る前は分からないので、音を聞きながら新しい組み合わせを読み取る。そして再現する（再現できないかもしれないけど、耳が覚えている）。
• ギターの弾き方に制限があるけど、それは手で押さえることがぐらい。そして手癖がある。
• ピックを持つ右手は、もっと敏感になれるから、ギター／弦から伝わるピックの圧力をうまく感じればオーケー。

ってな具合です。本当のフレーズは彼のビデオを見ると解ります。この探求の仕方に感動して、立て続けに3回ほど通してみて、2週間ほど練習しています。

服部良一に再会する。

山寺の和尚さん 歌詞と試聴
http://www.worldfolksong.com/songbook/japan/doyo/yamadera.htm

私の場合、基本的にオレオレブルースしか弾けないので、コードが弾けません。高校生の頃にフォークギターで指が痛くって投げたしたあたりからコードが押さえられません。まあ、今だと何となくコツがわかったので、オレオレブルースをやる分には大丈夫なぐらいなのですが、ふと「山寺の和尚さん」の突き当りました。

「カジノロワイヤル」をアマゾンプレミアムで見て、ああ、こういう音楽でもいいなと思いつつ、どうせならば「東京ブギウギ」ぐらいさかのぼってもよいだろうということで、さらに戦前までさかのぼります。大正、昭和ヒトケタまでさかのぼるのは、また別の意味があるのだけど「山寺の和尚さん」が服部良一のデビュー作であることを知りました。なるほど。こっちの路線でもよいわけです。

Julian Lage がエーデルワイスを弾くように、日本人が山寺の和尚さんを弾いてもよいわけで、昔なじみの民謡やおなじみの歌謡曲を jazz アレンジにしても良いですよね。矢野顕子も山下洋輔もやっています。

魔女っ子メグちゃんを弾いてみる

何故、覚えているのかわからないのですが、小学生の頃にリアルタイムで見た覚えがあります。なんか、オープニングの曲だけ印象的でずっと覚えていた曲なのですが、改めて調べてみると 渡辺岳夫 の曲でした。アタックNO.1 もキューティハニーもガンダムも彼の作曲です。

ギタースケールを練習していくと自分の手癖がわかります。弾きやすい運指と弾きにくい運指があります。オレオレソロをやると、どうしても弾きやすい運指に偏りがちですよね。おそらく、アニメの主題歌も作るときに手癖があるのじゃないか、と思ったりするのですが、どうやらあるみたいです。魔女っ娘メグもガンダムも同じ手癖で作られていることがなんとなく分かります。忙しい時期は、3日に1曲ペース（週に3日間スタジオにこもっていたらしい）っぽいので、もう頭の中のフレーズと手癖と好みだけでばりばり作っていく感じじゃないでしょうか。疲労のためか50歳半ばで亡くなっています。

そうやっていくつかの曲を真似てみると、世間的な音楽自体は5,6年という短いペースで流行が変わっていくけど、ひとりの作曲家／演奏家にとっては、当然のことながら3,40年という長いペースで音楽を作っていることがわかりますよね。ひとりの歌手／グループを追うのと同じでもあるし、彼や彼女が作る音楽の変遷というもの（それは学習だったり影響だったりするわけで）が現れてきます。

ウェス・モンゴメリーを改めて聴く

渡辺貞夫の最盛期をよく知らないのですが、サックス奏法がギターに取り入れらて、その逆もあるんでしょうけど、ウェス・モンゴメリー を改めて聴きます。 というか、ジャズ喫茶とかCD買ってたりして聴いていたのだけど、ああ、自分が生まれるより前の音楽なんですね。ってことは、オレオレブルース（B.B.キングの真似っこだったり）も、ずっと歴史をさかのぼっていってもいいのかー、っての分かって、昭和ヒトケタの日本から再開しているところです。

ギターで遊ぶために

ギターはまずコードを押さなければー、みたいな感じがしますが（まあ実際そうなんだけど）、コードをじゃかじゃかやっているだけでも音楽っぽく聴こえるのがよいところです。

GuitarStudio という iPhone のアプリがあってコードを指定してじゃかじゃかできます。本来はこんな音になるんじゃないかなぁ、と楽しむのがよいかと

iPhone Guitar Cover – Losing My Religion – YouTube
https://www.youtube.com/watch?v=yqgEl_Rt2lE&ebc=ANyPxKrVOPJsTWZkSi59VDdnBtRXGSDUjW8ohfoJHYnCy40I5ErwBWNxSLwYc-kc376ljVI2jsI7wN3L0Cw5LcWriz5sQr2ugA

Windows ストアアプリに教本っぽいものがあります。

• 初心者のためのギターレッスン #1 – Microsoft ストアの Windows アプリ
• Guitar Lessons Solo Shred – Windows Apps on Microsoft Store

ギターの練習で困るのは、運指をどうするかのですが、これだとスロー再生もあるので便利です。もちろん、youtube で運指をアップにしてもよいですよね。昔はビデオを買ってスロー再生だったので環境的にはよくなったかな。

「初心者講座」ってことになっていますが、どこまでの初心者ｗを対象にしているかわかりません。程よく弾ける人じゃないとついていけないんじゃないだろうか。けど、「～風」って発想が面白くて繰り返し見ています。

弾いてみよう！カントリー風（アコギ編）【ギター初心者講座】 – YouTube
https://www.youtube.com/watch?v=GKZEV102Ry8
弾いてみよう！フラメンコ風（アコギ編）【ギター初心者講座】 – YouTube
https://www.youtube.com/watch?v=8O1uIAuCcWY
アコースティック ソロギター道場｜メロディ・パートとベース・パート by J-Guitar.com
http://www.j-guitar.com/ha/solo/index.html

リズムを合わせればそれっぽく聴こえるってことの実践ですよね。

そうそう、ぼちぼちタブ譜のほうでもやってみないと。

DLmarket / 【TAB譜】マクロス フロンティア (娘たま♀)15曲＋おまけ4曲セット アコースティックギター伴奏譜 [ダウンロード版]
https://www.dlmarket.jp/products/detail.php?product_id=305177

日本橋で「Turbo C 下さい」って買いに行ったら「X1 Turbo」を出された > RT
https://t.co/XwKNPI7XxL

— Tomoaki Masuda (@moonmile) 2016年2月26日

 

もうちょっと前に書こうと思っていたのですが、Turbo C++ のフリー版があるよ、ということで記事を残しておきます。

Turbo C++ or C for Windows 7, 8, 8.1 and 10 32/64-bit Full Screen Free Download – Home
https://turboc.codeplex.com/

Windows 10 でも動くので、そのままダウンロードしてインストール。起動すれば ok です…が、全画面になってしまうのが困りものなので、起動時に「full screen mode…」のチェックを外します。するとウィンドウモードで動きます。ただし、カーソルが取られてしまうので、Ctrl+Tab で他のウィンドウにフォーカスを移してください。なんか Tab キーが暴走してしまいますが。

かれこれ30年前の C++

私が大阪で大学生をやっていた頃なのでかれこれ30年前のことです。マンデルブローを描きたかった頃（確かCマガジンで特集をやっていたような気が）に N88 BASIC で組むと遅いから C 言語で組むんだということで、日本橋に行って買いました。店頭で「Turbo C++ を下さい」というと、冒頭のように「X1 Turbo」を出されたのは良い思い出ですが、きちんと Turbo C++ も出てきました。確か、2,3万円で買えたと思います。当時、MS-C が高値の華で8万円ぐらいした頃なので以上に「安かた」んですね。LSI-C 試食版があったような時期なんですが、実行サイズに制限があったので買うしかなかったという感じです。いや、正確に言えば、Unix が出てきて、Minix が動いたか動かなかったかで、Linux が出たか出なかったの頃なので gcc はあったような気がします。実際、2年後ぐらいには、研究室で DOS/V 機に Linux を入れてワークステーションにログインさせていました。

当時、貴重な1台しかもっていない PC98 RX に DR-DOS（MS-DOS の互換OSですね）を入れて、ぽちぽちとプログラミングしたり大戦略したりしていました。そうそう、大戦略していた頃の神戸大震災に遭ったのでした。たまたま、午前5頃までゲームともプログラミングともつかない生活をしていたので地震があった当時に起きていたのですが（机が50cmほどずれました）、寝ていたら本棚の下敷きになっていたと思います（まあ下敷きになる程度で死ななかったとは思いますが）。

そんな頃の C++ なのですが、この Turbo C++ はきちんと「統合開発環境」になっています。そうそう、当時「emacs は環境である」というセリフが流行ったのです。emacs の中でプログラミングもできるし、メールも打てるし、シェルも動かせるというやつですね。それと同じように、Turbo C++ には付属のエディタがついてて、この中でコードを書いたりコンパイル＆実行をしたりすることができます。上の画面キャプチャを見るとわかるんですが、コードに色がついています。今の IDE のように候補がでることはありませんでしたが、キーワードには色がつきました。あと、テキストベースのウインドウを重ねることで、複数のソースコードを開くことができました。

当時の Macintosh にはマウスが必須でしたが、MS-DOS(DR-DOS)の時代には、まだマウスはついていませんでした。ついていませんでしたが買って、マウスドライバーを乗せることでテキストベースではありますがマウスカーソルを動かすことができました。

ノスタルジー以上のもの

昔はこうだった…の本が流行っているようですが、感傷（ノスタルジー）以上のものではないので、もう少し前向きな話をしましょう。

見て分かる通り、Turbo C++ の環境には上部にメニューがあります。メニューの位置がウィンドウに張り付いたり、Mac のように上に張り付いたりしますが「メニュー」があるという点では同じです。当時、Windows 3.1 が出た頃に MDI/SDI という概念があってダイナミックメニュー（メニュー自体が切り替わる）という方式が生まれましたね。その頃から DocView パターンがあったし、GoF の原著をみれば MVC パターン自体が相当古いところからある概念だということがわかります。それはともかくとして、

• 上部にメニューがある。
• メニューが階層化されている。
• モーダルダイアログがでる。
• ウィンドウがあって、前面と背面がある。

のような基本的なところは今の Windows でも変わっていません。当然、Visual Studio もその形を踏襲しています。この画面は Turbo C のものですが全体的にこの傾向は変わりません。Linux の X-Window ですら同じスタイルです。

じゃあ、このスタイルが完全であり将来的にもよいもの≒効率のよいものなのか、というとあまりそうとも言えません。ツールバーがついたり、MS-Office にリボンがついたり、スタートボタンがあったりなかったりする時代を考えれば、常に試行錯誤の段階であることは明白です。Windows が最初に出たころ（Macintosh が世間に浸透した頃かもしれません）に、科学的なユーザーインターフェースの指針としてマウスの動きとか、目の動きとかを使って「有利である根拠」を示したものもありました。当時、私もそういうものに気を使っていた時期もあるのですが、今考えれば「対案が出ていない」時点であまり科学的とも言えなかったのでは？と感じています。そう、比較対象がないんですよね。

Squeak のメニューの出し方は独特で、カーソルの周りにメニューアイコンが出ていた…ような気がするんですが、別の言語でしたかね？今だと、ふつうのコンテキストメニューが出てきます。まあ、そこは他のOSとの操作感の兼ね合いでもあり、淘汰でもあるのですが、現在のメニューシステムはキーボードとマウスを中心にして作られているので、スマートフォンやタブレットのように指先を使うとか別の入力デバイスを使うときには別の方法があるはずなんですよね。実際、スマートフォンのスクロールはマウスを使ったスクロール方法とは違うし、指を2本使ったピンチのような拡大縮小はマウスではできない方法です。そういう、新しい入力デバイス（タッチパネル≒指）が出てきたときに初めて、Turbo C++ の開発環境のようなメニューやウィンドウの表現との「決別」ができるのではないかな、と思っていますし期待しています。

じゃあ、VR のように仮想空間でこねこねしながらプログラミングするのがよいのかとか、仮想キーボードを使って仮想ターミナルを開くのがよいのかという模索もありますが（実際、あれは面白いし、なんかそっちの方向に行きそうな気もしています。空中に浮かんでいる複数画面の映像はあの VR 空間で実現できますよね）。

Scratch をはじめとするブロックプログラミング環境にしても、条件分岐の書き方とか非同期動作の書き方とか（実は Scratch はイベントを非同期で発生させられる可能性をもっています。今も非同期で動いている？）まだまだ書き方はたくさんあります。特に if 文が一次元（コードを書く方向≒文章を書く方向）であらわされていますが、多数に分岐させて2次元に遷移図として展開させることは可能ですよね。Unity のスクリプトがそんな感じです。

MDA（モデル ドリブン アーキテクチャ）を再開するならば（私は再開してもよいと思います）、ブロックの内部実装（低レベルの詳細実装≒戦術）と、ブロックを組みあわせる問題解決の層（高レベルの実装≒戦略）とは分けて考えてもいいのではないでしょうか。実際、Azure の機械学習はそれに近い感じになっています。そういうところを考え合わせると、マウス以外の入力デバイス（タッチパネル，VR 空間、その他のアナログな入力デバイス）も併せて、もう少し「過去とは断絶した」開発環境ができるのではないかな、と思ったりしますし、それを作りたいなと。

ふと、ノーム・チョムスキーの生成文法とウンベルト・エーコの記号論を思い出したので、後置型プログラム言語を再考してみる。

たいていのプログラム言語は前置定義型だ

「全ての」と書きたいところなのだが、C# の拡張メソッドや Ruby の後付けメソッド、Javascript のオブジェクトへのメソッドの追加を考えると、後置型とも言えなくもないので「たいていの」にしておく。要は、あらかじめ定義したものを使う、というスタイルでプログラムコードを書いていくのが「前置定義型」だ。

class class A {
public:
  void method() { ... }
};
void main() {
 A a ;
 a.method();
}

な感じでクラスやメソッドを定義する。

記述場所は、main 関数の後からもしれないし、別ファイルかもしれない。ただし「A」として使う時点で、A クラスは定義してあるという前提になる。これは一見、当たり前のように見えるけど、あらかじめ定義されているクラス A がアプリオリであることが前提になる。コードとして記述する、あるいはプログラムが実行される時点で、A から生成される a は、何も A に既定されなければいけない、という法はない。法を作った上で、A を使って a を生成しているというルール的な意味になる。

ただし、コンパイラや補完機能の絡みからすれば、これは便利だ。A から a を生成した時点で、a の型は既定されているので、method というメソッドを持っていることが分かる。あるいは、別のクラス B を使って b を生成したときに、a != b が明確になる。事前に決まっているからこそ曖昧さがなくなり、型推論が可能だし厳密さを保ったところでコードを書けるというメリットを享受できる。

となれば、仮定として「プログラムコードとしての安全性を取り払ったどうなるのか？」という疑問を呈してみよう。厳密に動かすためのプログラムなのに、厳密さを取り除くという考え自体が矛盾しているような感じがするか、思考実験としては妥当だろう。

自然言語的に定義を補完する

例えば、A x としたときに、x の型は決まらないし、A というクラスの内容は定義しない。ただ、A というクラスができて、x というモノ（オブジェクト）ができるという意味だけを取り出してみる。

x is a A;

ってことだ。いわゆるオブジェクト指向の is a だから、A というクラスあるいはカテゴリというものがあることが分かる。かつ。A であるものと A でないものを分離するという役割を担う。しかし、ただそれだけの意味しか持たない。

これをいきなり、A というクラスは func というメソッドを持つということを考えてみよう。その方法は2つ考えられる。

1. class A { func() { … } };
2. x.func( … );

ひとつは、1 のようにクラス定義をして func メソッドがあることを知らせる。x は A クラスなので、x が A クラスであるという三段論法から x は func というメソッドを持つことが分かる。これは普通のプログラミングのスタイルだ。

もうひとつ、2 のようにいきなり、func というメソッドを使う方法がある。通常は A クラスは定義されていないのだから、func というメソッドを持つかどうかわからないのだが、いやいや、それ狭いコードの範囲しかみていなくて、コード制作者（コード自身の外の世界）の意図としては、すでに A には func というメソッドがあることを知っているので、コードだけの世界にいきなり func を持ってきても不思議ではない、というスタイルだ。つまりは、コードの外部にあるコード制作者が常に正しとしてコードを書くというスタイルをとる。

しかし、実行時には、func というメソッドがコードという世界で定義されていたら動きようがないので、それは「何事もなく動く」のでもよいし「実行時例外を発生する」方法でもよい。コードの厳密性を探るのであれば「実行時例外」が正しいように見えるが、コード制作者が常に正しいという視点に立ては「何事もなく動」いてもいいような気がする。ただし、コードを実行する世界では、func メソッドの動作は定義されていないので、「何事もなく動く」ということはイコール「何も動かない」ということに等しい。この何も動かないということは例外さえも動かないということだ。

A a ;
a.func();

そう、後置定義型を許せば、上の2行はそのまま動く≒何も動かない、ということになる。

コード外のアプリオリを追加する

もう少し具体的に考えみよう。なんとく変数 a に名前をつけておいて、プリントアウトすることを考える。

A a("masuda");
a.print();

これだけで十分だ。プリントアウトするという意味っぽい print というメソッドを使うだけ、名前を付けるという意味で “masuda” を引数として定義するだけで完成する。本当のとこは、名前付けがコンストラクタの指定なのか、（あるかもしれない）Name プロパティへの指定なのかはどうでもいいことだ。コードを書いた人は、コードの世界よりもすべてを知っているので、コードが動作する枠を超えていても構わない。プリントアウトするという print メソッドは習慣的にプリントアウトするという動作を定義するだけで、それが画面なのか紙なのか3Dディスプレイなのか、それとも他のプロセスへの通知をプリントアウトするのかはわからない。脳内にプリントアウトしたってかまわないはずだ。それらの動きを既定するのはコードの世界なので、それはコード内の世界の「アプリオリな」ライブラリに寄るという答えになる。

ここで、コードを書く人とコードを動かす人（実行環境）とのずれが発生する。一般的なコミュニケーションの伝達の問題であって、プログラムコードではそれらを「厳密さ」で補おうとするけど、人とのコミュニケーションであればそれらの厳密さあまりあてにならない。文化の違いもあれば育ちもあれば宗教的な違いや政治的な違いがある。勿論、学問としてひとつのルール（閉鎖的なルール）で議論することも可能なのだが、日常生活においてはあまり厳密に伝えることは少ない。例えば、居酒屋にて「とりあえずビール」と言ったときに、ビンなのか生なのかピッチャーなのかは問わない場合もあれば問う場合もあれば、盆に注がれたりどんぶりだったり氷入りだったりコーラを一緒に持って来たりといパターンも考えられるけど、まあ大体において「とりあえずビール」で通じることが多い。常連であればなおさらだ。

ならば、コード制作者がコードに対して、いちいち厳密に説明することはすくなくて「とりあえずビール」感覚で「とりあえずプリントアウト」でもいいですよね、って感覚でコードを書くこともできるのではないだろうか。実際、Outlook でメールを印刷しようとすると「とりあえずメモ形式で印刷しますよ」みたいな感じになる。

じゃあ、プリントアウトする用紙を A4横にしたいときは、こんな感じで補完する。

A a("masuda");
a.print()
print() is A4横.

いきなり自然文法になってしまうが、 こんな感じで後付け書く。「プリントアウトしておいて、ええと、A4横でね」みたいな感覚だ。英語文法/文章法でいうところの、結論を先に書いて後から詳細を足す感覚で書けばいい。普段は「A4縦」で印刷するのだから、普通のデフォルトは print だけでいいのだが、ちょっと変わったことをしたいときは後から追加する。

A a("masuda");
a.paper = "A4横"
a.print()

普通のプログラム言語であれば、こんな風に print の前に書く。なぜかというと、print する時点でプリントアウト自体が実行されてしまうので、後から「ちょっと待った」ができないからだ。 インタープリタだったら、逐一実行するためにこう書かないと駄目なのだ。あらかじめ「これは A4横 で印刷するんだぞ」と初心者的にオーダーするわけだ。だが、コンパイラ言語であって、コードを解析するときとコードを実行するときでは時間的なずれがあるのだから、ほどよく プリントアウトに対する設定変更が終わったころにおもむろにプリントアウトを実行する熟練者がいても不思議ではないはずだ。

また、print 自体の動作も、印刷する先は実行時に決まってもよい。実際、コードを動かして Windows で動かすのか、Linux で動かすのか、何かの組み込みデバイスで動かすのか（小さな液晶に出すのか）という違いが出てくる。それでも、print というコード制作者の意図が達成されれば、それでよいし、逆に実行する環境で print という実行メソッドがなければ「何もしない」ことを実行すればよい。そのあたりの、コード外の実行環境は、コード外のアプリオリとして存在するのであって、コード制作者は未来のコード実行環境を想像しながら作るしかない。逆に、想像するしかないから大ざっぱにプリントアウトするという動作だけ決めてしまう。

記号論と生成文法を加味する

厳密に生成文法を使うかどうかは別として、記号論／現象論的な、シニフィエ／シニフィアンの問題を取り扱ってみる。実際の print の動作は、実行環境のアプリオリなライブラリ（ひらたく言えば既存のライブラリ）により実行されるが、先のコードに、コード制作者の意図を加えてもよいだろう。

A a("masuda");
a.print()

print() is "A4横"
print() {
	name <- name.upper()
}

こんな風に、プリントアウトするときに name プロパティを大文字にすることを考えてみよう。print メソッドの中身は print メソッドを使う時点ではなく、実行時に決まるので、コードの記述上 print メソッドの中身はいつでも変えられる。この場合は、”masuda” が指定されたら “MASUDA” のように大文字に変換すること示している（当然、upper 自体が「大文字にする」という動作がになっていれば、という限定がある）。

つまり、print というメソッドは、記号としての意味しかなくて、それはコード制作時と実行時の意味をつなげるという意味しか持たない。解釈する順序は、現実的な時間制約として、

1. アプリオリな print メソッドが存在する
2. コード制作者が print メソッドを使う
3. 場合によっては、コード制作者が print メソッドを補足する
4. 実行時に print メソッドが実行される。

の順序しかない。場合によっては、1 のアプリオリな print メソッドのライブラリがない場合もある。コード制作者の頭にしかない print メソッドを、なんとなくコード制作者が 3 で補足して、コードを実行する段階において（コード制作者とは異なる） print メソッドが実行される。コード制作者の「print」と、コード実行時の「print」とは確実に異なる。異なるので「同じ動作をする」という保証はない。保証はないが「だいたい同じ動作をする」という現実的な解を持つという訳だ。

このコードには「厳密さ」はないし、厳密に書くことは不可能だ。コード制作者は、あくまで過去においてコードを制作するので、未来において実行される実行コードを制御はできない。大体、想像して作るだけだし、そこにはとある「約束」や「ルール」があるだけだ。

そういう緩い結合で「後置型プログラム言語」を実装できないかな、と思考実験してみる。文法的に英語の自然言語っぽい形で書ければ（しかし、決して自然言語ではない）なんとなく動くというスタイル。