業務アプリケーションの開発をしていると、エクセルで、ひとつのセルを全角一文字分の小さな正方形にした、いわゆる方眼紙スタイルで書かれたドキュメントにお世話になることがある。
第一のメリットは、どんな内容でも、縦や横をそろえて見た目をきれいにできること。
箇条書きをインデントして書くのも楽だし、ドキュメントの一部に小さな表とか画面イメージとか、罫線使って簡易な図形表現が手軽にできるのもメリット。
図の貼り付けの位置合わせとかも、他の部分ときっちりそろえることができて超便利。
日本語の組版の基本は「全角」「半角」に象徴される「等幅」の文字を並べること。
日本語のドキュメントを作るときエクセル方眼紙は、理に適っている。
パソコン普及前は、薄い青線の入った方眼紙に文章と図を手書きしてコピーするのが当たり前だったらしい。
エクセル方眼紙は、この電子版というわけだ。
「エクセルの本来の使い方ではない」という意見もあるようだけど、エクセル方眼紙も、ひとつの使いかたでしょう。
エクセル方眼紙は、個別の行や列を意味は持たせないところがポイント。
固定サイズのセルの集合という、均質で高度に抽象化(簡略化)したモデル。だから、どんなドキュメント作成にも使える。
加筆や変更がしたい時も、行や列に意味を持たせていないから、つまらない副作用を心配しなくて良い。
A列、B列、C列が大中小の分類で、D列が説明で、E列が重要度のマーク、...
1行目が見出し、2行目はそれを分割したサブの見出し、サブの見出しが無い列はセル連結で大きなセルとして見せる、...
とかやりだすと、
× 行や列の意味を考えながら、高さや幅を細かく設定・調整しないときれいにならない。
× 行の高さや列の幅を個別に設定してしまうと、後からドキュメントの一部に、違う高さや幅の内容を挿入するのがとてもたいへん。
行ごと列ごとに個別の意味を持たせるから、プログラミング的に言えば独自の「型」を宣言するから、こういうめんどくささが起きてしまう。
セルは全角一文字サイズの正方形。
方眼紙は、均一サイズのセルの二次元の配列。
エクセル方眼紙のメリットは、こういう徹底した抽象化・単純化により実現できているわけだ。
抽象化・単純化は、プログラミングの極意でもるある。
関数型プログラミングは、まさにエクセル方眼紙と同じ発想で、多くのメリットを生み出す。
オブジェクト指向のプログラミングは、なんでもかんでも、独自の「型(クラス)」を宣言していくスタイル。こういうスタイルが有効なシーンもあるだろうけど、ほとんどのプログラムは、入力データを出力データにマッピングする「関数」として単純化して考えたほうが手っ取り早いことも多い。
データの意味とか入り組んだ構造とかは捨て去って、思い切って抽象化・単純化したデータの集合としてしまえば、ほとんどのプログラムは驚くほど簡単にかける。
UML でドメインモデリング、Java でデータとロジックを「意味のある」型として宣言、それぞれの独自の型の意味を適切に表現する「名前」を一生懸命考える。
このやり方では、生産性があがらないし、部品、特にロジックの再利用がすすまない。
独自の型宣言しまくった後に、何か変更しようとするとコンパイラ型の言語だとコンパイラがいろいろ文句いうし、動的な言語だと、わけのわからない副作用に悩むことになる。
プログラミングの世界に現実世界の意味や構造をマッピングしようという発想がまちがいの元。
プログラミングのコツもエクセル方眼紙ですよ。
データ(行や列)に意味づけ(独自の型宣言)しちゃいかんのです。
全角一文字を表現した「セル」という単純で美しくさえある基本ユニットと、どの基本ユニットも [x,y] だけで参照する構造の明快さ。
この明快さ、美しさが、関数型プログラミングの基本だし大きなメリットを生む。
コンピュータのプログラミングって、ようするにバイト(ビットのかたまり)を、どう操作するかという仕組み。
バイトは固定の順番で配置され「アドレス」というシンプルな方式でのみ参照可能。
情報の意味や構造を考えようとか、独自の型を宣言して意味のある名前を付けようなんてことは無意味な世界。
データは整数のリスト。文字データも整数のリスト。
だから、整数のリストを扱いやすいプログラミング言語でデータを扱うのが、もっとも自然。開発も楽。どんなデータや要求に出くわしても、整数レベルまで抽象化、単純化しておけば、同じロジックとテクニックであらゆるデータを簡単に操作できる。
関数という部品を、あちこちで手軽に使いまわすことができる。
※ あちこちで安全に使いまわすために、関数型プログラミングでは、データを破壊しない(変更しない)ことは、とても大切な原則。手続き型はデータを変更しまくるけど、関数型では破壊的代入は、ご法度。
Hadoop とか、ビックデータを並列的に効率よく処理できるのは、CPUとメモリの劇的なコスト低下と、関数型プログラミングの考え方や仕組みがうまくマッチして実践できているから。
データとはようするに整数の集合。
関数型プログラミングは、そういう数学的な感覚で扱えるレベルまで徹底的に「情報」を抽象化・単純化するところに成立する。
世の中の多くのデータ処理は、この単純化感覚で対処すれば、それで十分。
やってみて、結果が思わしくなければ、関数をちょこっと書き変えるか、別の関数を前後に追加してやれば、だいたい解決する。
ドメインの意味を深く理解するために、言葉にこだわって分析・モデリングする。
そのドメインのモデルを独自の型として設計・実装して、独自の名前づけにこだわる。
そんな手間暇かけるから、プログラム開発に時間がかかる。
しかも、結果は、独自の型だらけ。開発した本人すら意味がよくわからないコードのかたまり。変更しようとしても、どこで何がおきるか予想できない。
そんな回り道するより、データは「整数のリスト」「文字のリスト」という単純化・抽象化によって、さっさと関数型でプログラミングしたほうが、圧倒的な生産性を生み出すことができる。
エクセル方眼紙の発想ですよ。
エクセル方眼紙も、関数型プログラミングも「単純な美しさ」を追及すれば、おのずとこうなるはず。
「美しい」だけでなく、作るの簡単、直すの簡単、再利用が簡単、という現実のメリットにあふれたプログラミングのやり方が関数型プログラミングの世界。
現実世界の情報の意味をあれこれ考えたり、名前づけに苦しんだり、独自の型を宣言しまくって、何がなんだかわからないプログラムと格闘するオブジェクト指向スタイルから抜け出したかったら
余計なことは一切無視して整数重視の汎用的なデータ構造にすること
につきる。
コンピュータやデータ通信は、情報を「ビット」まで徹底的に抽象化・単純化したことで成立している世界。
プログラムだって、そっちの世界の住人。だからそういう単純な世界に振り切りにいくのが、プログラマとしてあるべき姿。
均一なセルがきれいに並んだエクセル方眼紙。うっとりするほど美しい。
整数のリスト操作のコンパクトな関数表現。とってもエレガント。
世の中、エクセル方眼紙と関数表現だけになれば、もっとすっきりするのに。
。。。
はあー、やだやだ。
エクセル方眼紙
第一のメリットは、どんな内容でも、縦や横をそろえて見た目をきれいにできること。
箇条書きをインデントして書くのも楽だし、ドキュメントの一部に小さな表とか画面イメージとか、罫線使って簡易な図形表現が手軽にできるのもメリット。
図の貼り付けの位置合わせとかも、他の部分ときっちりそろえることができて超便利。
日本語の組版の基本は「全角」「半角」に象徴される「等幅」の文字を並べること。
日本語のドキュメントを作るときエクセル方眼紙は、理に適っている。
パソコン普及前は、薄い青線の入った方眼紙に文章と図を手書きしてコピーするのが当たり前だったらしい。
エクセル方眼紙は、この電子版というわけだ。
「エクセルの本来の使い方ではない」という意見もあるようだけど、エクセル方眼紙も、ひとつの使いかたでしょう。
エクセル方眼紙は、個別の行や列を意味は持たせないところがポイント。
固定サイズのセルの集合という、均質で高度に抽象化(簡略化)したモデル。だから、どんなドキュメント作成にも使える。
加筆や変更がしたい時も、行や列に意味を持たせていないから、つまらない副作用を心配しなくて良い。
A列、B列、C列が大中小の分類で、D列が説明で、E列が重要度のマーク、...
1行目が見出し、2行目はそれを分割したサブの見出し、サブの見出しが無い列はセル連結で大きなセルとして見せる、...
とかやりだすと、
× 行や列の意味を考えながら、高さや幅を細かく設定・調整しないときれいにならない。
× 行の高さや列の幅を個別に設定してしまうと、後からドキュメントの一部に、違う高さや幅の内容を挿入するのがとてもたいへん。
行ごと列ごとに個別の意味を持たせるから、プログラミング的に言えば独自の「型」を宣言するから、こういうめんどくささが起きてしまう。
セルは全角一文字サイズの正方形。
方眼紙は、均一サイズのセルの二次元の配列。
エクセル方眼紙のメリットは、こういう徹底した抽象化・単純化により実現できているわけだ。
抽象化・単純化は、プログラミングの極意でもるある。
関数型プログラミング
関数型プログラミングは、まさにエクセル方眼紙と同じ発想で、多くのメリットを生み出す。
オブジェクト指向のプログラミングは、なんでもかんでも、独自の「型(クラス)」を宣言していくスタイル。こういうスタイルが有効なシーンもあるだろうけど、ほとんどのプログラムは、入力データを出力データにマッピングする「関数」として単純化して考えたほうが手っ取り早いことも多い。
データの意味とか入り組んだ構造とかは捨て去って、思い切って抽象化・単純化したデータの集合としてしまえば、ほとんどのプログラムは驚くほど簡単にかける。
UML でドメインモデリング、Java でデータとロジックを「意味のある」型として宣言、それぞれの独自の型の意味を適切に表現する「名前」を一生懸命考える。
このやり方では、生産性があがらないし、部品、特にロジックの再利用がすすまない。
独自の型宣言しまくった後に、何か変更しようとするとコンパイラ型の言語だとコンパイラがいろいろ文句いうし、動的な言語だと、わけのわからない副作用に悩むことになる。
プログラミングの世界に現実世界の意味や構造をマッピングしようという発想がまちがいの元。
プログラミングのコツもエクセル方眼紙ですよ。
データ(行や列)に意味づけ(独自の型宣言)しちゃいかんのです。
全角一文字を表現した「セル」という単純で美しくさえある基本ユニットと、どの基本ユニットも [x,y] だけで参照する構造の明快さ。
この明快さ、美しさが、関数型プログラミングの基本だし大きなメリットを生む。
コンピュータのプログラミングって、ようするにバイト(ビットのかたまり)を、どう操作するかという仕組み。
バイトは固定の順番で配置され「アドレス」というシンプルな方式でのみ参照可能。
情報の意味や構造を考えようとか、独自の型を宣言して意味のある名前を付けようなんてことは無意味な世界。
データは整数のリスト。文字データも整数のリスト。
だから、整数のリストを扱いやすいプログラミング言語でデータを扱うのが、もっとも自然。開発も楽。どんなデータや要求に出くわしても、整数レベルまで抽象化、単純化しておけば、同じロジックとテクニックであらゆるデータを簡単に操作できる。
関数という部品を、あちこちで手軽に使いまわすことができる。
※ あちこちで安全に使いまわすために、関数型プログラミングでは、データを破壊しない(変更しない)ことは、とても大切な原則。手続き型はデータを変更しまくるけど、関数型では破壊的代入は、ご法度。
Hadoop とか、ビックデータを並列的に効率よく処理できるのは、CPUとメモリの劇的なコスト低下と、関数型プログラミングの考え方や仕組みがうまくマッチして実践できているから。
データとはようするに整数の集合。
関数型プログラミングは、そういう数学的な感覚で扱えるレベルまで徹底的に「情報」を抽象化・単純化するところに成立する。
世の中の多くのデータ処理は、この単純化感覚で対処すれば、それで十分。
やってみて、結果が思わしくなければ、関数をちょこっと書き変えるか、別の関数を前後に追加してやれば、だいたい解決する。
ドメインの意味を深く理解するために、言葉にこだわって分析・モデリングする。
そのドメインのモデルを独自の型として設計・実装して、独自の名前づけにこだわる。
そんな手間暇かけるから、プログラム開発に時間がかかる。
しかも、結果は、独自の型だらけ。開発した本人すら意味がよくわからないコードのかたまり。変更しようとしても、どこで何がおきるか予想できない。
そんな回り道するより、データは「整数のリスト」「文字のリスト」という単純化・抽象化によって、さっさと関数型でプログラミングしたほうが、圧倒的な生産性を生み出すことができる。
エクセル方眼紙の発想ですよ。
エクセル方眼紙も、関数型プログラミングも「単純な美しさ」を追及すれば、おのずとこうなるはず。
「美しい」だけでなく、作るの簡単、直すの簡単、再利用が簡単、という現実のメリットにあふれたプログラミングのやり方が関数型プログラミングの世界。
現実世界の情報の意味をあれこれ考えたり、名前づけに苦しんだり、独自の型を宣言しまくって、何がなんだかわからないプログラムと格闘するオブジェクト指向スタイルから抜け出したかったら
余計なことは一切無視して整数重視の汎用的なデータ構造にすること
につきる。
コンピュータやデータ通信は、情報を「ビット」まで徹底的に抽象化・単純化したことで成立している世界。
プログラムだって、そっちの世界の住人。だからそういう単純な世界に振り切りにいくのが、プログラマとしてあるべき姿。
均一なセルがきれいに並んだエクセル方眼紙。うっとりするほど美しい。
整数のリスト操作のコンパクトな関数表現。とってもエレガント。
世の中、エクセル方眼紙と関数表現だけになれば、もっとすっきりするのに。
。。。
はあー、やだやだ。