中の人の徒然草340

おはピヨ♪今日も情熱大陸しているインドリです♪
ここ最近、近所に沢山桜が咲いている場所があるから、毎日のように桜見をしていました。
でも、どんどん桜が散ってしまって、もう殆どないですorz
もっと桜観たかったな・・・
今ふと思ったのですが、人の粗ばかり探している人っていますよね。
でも、それって実にくだらない。私はそんなことした事がありません。
そんなことして何が楽しいでしょうか？
私は仕事をするにあたって、人の長所を探すようにしています。
それは、他人に敬意を持つ必要があると考えるからです。
完璧な人なんていませんから、何かの短所を持っているのは当たり前です。
そんな当たり前な事を探してもなんの面白みもありません。
それよりも、その人の長所を探す方が楽しいし、自分のためになります。
酷い人になると、人のあらを偽装する事さえしますが、あれって恥ずかしくないのだろうか？
また、自分の無恥さを他人のあらにする人すらいますが、あれも一体何だろう？
TVをたまに見ると、人の悪口ばっかり。
特に政治家なんて、人の悪口を言う時いきいきとしていますが、仕事をしているふうには見えません。
あんたら法律作るのが仕事だろってよく思います。あれだけ成果を出さずに、言い訳ばかりでまかり通る職業は珍しいでしょうね。普通の職業は、言い訳なんて通用しません。成果だけ求められます。
彼らが口にするのは選挙ばかりだから、永遠に就職活動している学生のようですね。
何時仕事するのだろう・・・
一方報道しているマスメディアも人の悪口ばかり一日中言っています。
報道精神などと偉そうなこと言っておりますが、人の悪口を言う事が報道なのかと疑問に感じます。
これらの例を鑑みるとよくわかると思いますが、人のあらばかり探している人はみっともない。
そんな無駄な事をしている暇があれば、自分を鍛えればいいのです。
だから私は、人のあらさがしはした事がありませんし、人のあら捜しばかりしている人は、取るに足りない人間だと考えて無視する事にしております。
実際問題、人のあら捜しばかりしている人に人間的な魅力は何もないです。
もちろん、技術者として見習うべき点も何もありません。
きっと、人のあらを探す事ばかり時間を費やしているからスキルがないんでしょうね・・・
この春入社した人は、人のあらを探さないで、他人の長所を探して下さい。
そして、他人に敬意を持つ。それをしていれば、きっと仕事がやりやすくなるでしょう。何故ならば、誰も人のあら捜しをしている人は相手にしないからです。
仕事仲間に敬意をもって接していれば、相手も敬意をもって接してくれます。仕事はそうやってするものではないでしょうか？

ネタつつき82ー開発は滝ではなく蜘蛛の巣だ。

システム開発において、ウォーターフォール・モデル開発の弊害とアジャイル開発の必要性が叫ばれて久しいですが、日本では未だにウォーターフォールな考え方が主流なので、その事をネタにして書きます。
私はシステムを提供するシステム屋をしておりますが、やはりアジャイル開発をしています。何故かといいますと、ウォーターフォール開発は弊害が多すぎるし、クリエイティブに活動すると自然とアジャイル開発になるからです。 ウォーターフォール開発を成功させようと思えば、全ての事を見通せる事と、変化がない事が条件となりますが、現実世界でそれはあり得ません。
この問題の本質は、ウォーターモデル開発が階層型である事に起因すると私は考えております。全ての物事が上から下へと流れるのであれば、この開発モデルは適切でしょうが、あいにく全ての情報はリレーショナルに存在します。ですから、思考形態と作業が階層型では上手くいくはずがありません。
その点を考慮すると、既存のアジャイル開発も少し問題が残っております。ですから私は、既存のアジャイル開発を変形して利用しております。システム開発は要求定義・分析・設計・実装・テスト・運用・保守などと一連の流れが縦に展開されるとされています。しかし、実務をすると分かると思いますが、そんな事はなく、実装段階で分析段階の誤りに気付いたり、設計段階で運用段階に弊害が起こる事が予期出来たりします。 すなわち、開発作業に段階はあるものの、必ずしも上から下へ連続して続くのではなく、各段階が複雑に絡み合っているのです。
分かりにくいので例を挙げます。例えば、書籍Effective C++に書かれている事は、オブジェクト指向設計においても重要な事です。では、この事は何時気付いたのでしょうか？ほぼ確実に実装段階です。如何に効率よくシステムを作るのかを考えるには、プログラミングは避けて通れません。実装が出来ない人によい分析や設計が出来る筈がありません。むろんこれは逆も言えます。よい分析が出来ない人にまともな実装は出来る筈がありません。つまり、これらの物事は複雑に絡み合っているのです。
ですから私は、常に全行程をシュミレーションしながら、システム開発を行っております。全ての物事は常に変化するのです。その変化を無視するとシステム開発は成功しません。だからと言って、全ての変化を受け入れては開発が終わりません。常に全行程を考慮しつつ、どの変化を受け入れるべきなのかをよく吟味し、受け入れる時は正確に反映しなくてはなりません。
私が何を言いたいのかといいますと、システム開発をリレーショナルモデルを元に考える必要があるという事です。もっと理想を言えば、オブジェクト・リレーショナルが好ましいのですが、先ずはリレーショナルにしなくてはなりません。より柔軟に変化に対応するべく、リレーショナルな開発モデルが作られる事を私は願っています。

ネタつつき81ー並行処理／並列処理を日常から感じる♪

マルチコア時代に突入し、並行処理／並列処理（面倒だから以後並行処理と書く）はプログラマの必須知識となりました。しかし、意外と並列処理について知らない人が多いようです。そこで今回は、並行処理を学ぶにあたって一番大事な感覚を身につける方法を書きます。
並行処理で一つだけ教えるとすれば、私が挙げるのは・・・1つのオブジェクトを複数のオブジェクトで処理しないです。ここでいうオブジェクトとは、あるクラスのインスタンスやシステム上のあらゆるリソース（ファイル、コンソール、画像、印刷対象・・・）などを指します。これらを並行処理するにはひと工夫必要です。
意外と思われるでしょうが、この鉄則は日常感覚で感じる事が出来ます。例として、卵が大好きな新婚夫婦を考えてみましょう。或る朝、奥様は卵がもうない事に気付きました。卵好き夫婦にとってこれは一大事です！奥さまは当然、卵を買おうと決心します。一方夫も、ふと冷蔵庫を開けると卵がない事に気付きました。新婚でラブラブなので、妻の為に夫は会社の帰りに卵を買う事を決めました。この結果は・・・もうおわかりですね。
この例は、卵なので大した問題ではないと思われるでしょう。しかし、冷蔵庫がもう満杯だとしたらどうでしょうか？余分な卵が腐らせるか、返品する事になります。この問題の原因は、この夫婦が互いに卵を買う事を知らせなかった所にあります。一言でもいいから連絡しておけば、どちらかは卵を買わないで済んだでしょう。ですが、夫は忙しくて早朝から出勤だとします。卵の事で一々妻を起こすのは気がひけます。後からでは、夫は忘れるかもしれません。では、どうすればいいでしょうか？
先ず思いつく簡単な方法は、冷蔵庫に紙を張り付けてメッセージを書く事です。そうすれば、卵以外にも応用できます。しかしこの方法にも問題があります。それはルールです。ちゃんと決めておかないと同じ事が起こります。例えば、買った後に紙に書くとします。それでは、互いに卵がないと考えて買いに行ってしまいます。では、買う前に書くのはどうでしょうか？これでも、卵を買ってくるのを忘れた際に問題が生じます。嗚呼、卵がない！
これがグローバルな変数を並行的に処理してはならない理由です。並列処理では実行順序が決まっておらず、タイミングにより問題が生じる可能性があります。逐次処理では常に一つの処理しかしませんので、グローバル変数を多用しても平気だったかも知れませんが、並行処理の世界ではその考えを改めなくてはなりません。
もう一つ例を挙げます。2人のビジネスマンが一つの黒板に文字列を書く時の事を考えてみましょう。この2人が互いに他者を無視して黒板に文字を書けばどうなるか分かりますね？とてもじゃないけど読めたものではないでしょう。1行ずつ交互に書くと決めたとしても、くしゃみをするなどのふとした瞬間に、もう一人が文字を書いてしまうかもしれません。これでは、本当に判別が不可能です。やはりルールが必要です。
これらのルールに当たる部分が同期処理です。集団生活をする我々からしてみれば、ルールが必要なのは当然ですよね。ですから、並行処理は当たり前の事を言っているにすぎないのです。逐次処理では、複数の人が動いていなかったのでルールは必要ありませんでした。これは不自然です。どちらかといえば、並行処理の方が普通の現象なのであって、何も難しい事ではありません。
じゃあ、具体的にどういうルール（アルゴリズム）があるのか？という所が並行処理の注目するべきポイントです。このポイントが、プログラム言語・ライブラリ・OSなどの特色があります。そういった並行処理のモデルは、1つのオブジェクトを、どのようにして複数のオブジェクトが処理をするのかという共通の問題を解決するべく考えだされています。そう難しい事ではありません。
纏めます。並行処理は一見難しい事のように感じます。しかし、その発想はいたって自然であり、難しい事ではありません。逐次処理の方が不自然だったのです。ですから、自然体で学習しましょう♪

ネタつつき80ー新しい物事を習得する方法。

私は元々フリーの研究家でして、発明を売って生活している時期がありました。現在は商売人として儲からないと判断して止めていますが、研究家として活動する事により、新しい物事を覚える方法を身につけました。その方法は、多くの人の役に立つと思いましたので今回はそれを書きます。
情報処理産業の変化は早く、眩暈を起こしそうな勢いで次々に新しい技術が登場します。しかし、実はたいした事がありません。これらの技術や知識は素早く習得するコツがあります。それは頭がよくなくても出来ます。実際私は自分が頭がいいなんて一度も考えた事がありません。逆に、頭が悪いと考えているからよく学習しております。もし私の頭がいいのであれば、そもそも学ぶ必要はありません。
しかもそのコツは極めて単純です。特別な才能は必要ではありません。誰でも出来る事です。
その方法は、情報処理技術を愛し、情熱を持って素直な気持ちで毎日学び続ける。ただそれだけです。何も難しい事はありません。
簡単すぎて嘘っぽいと感じる人が居るでしょうがそんな事はありません。下手に身構えると、苦痛になって人間の脳は記憶しません。何故ならば、人間の脳には不快な記憶を消す機能があるからです。
皆様は何か趣味や好きな事はありませんか？人間好きな事は凄く覚えているものです。例えば、アニメが好きな人は、事細やかにアニメのストーリーや背景まで覚えています。音楽が好きな人は、何百曲でも歌詞を覚えていたりします。
それらの事に共通するのは、好きだという感情と、覚える作業そのものが苦痛でない所です。人間は誰しも膨大な量の情報を記憶する事が出来ますし、それを習得する作業も好きであれば、苦痛どころか幸福だと感じます。
ですから、情報処理技術だけが特別だという事はなく、情報処理技術を習得する方法もラブ＆パッションなのです。愛していれば、自然と色々な事が身に付きます。
変化が早いから焦るかもしれません。私も焦る時があります。ですが冷静に考えれば、焦る理由なんてない事に気付くはずです。どんなに早く習得しようとしても、世界は広くて既に習得している人が居ます。例えば、新言語を誰よりも早く習得しようとしても、その新言語の開発者には負けます。ですが、別に競う必要はありません。気になった時に習得すればいいのです。今仕事に必要ならば、今日から覚えればいいのです。
また、全てを習得できないと感じるかもしれません。ですが、物事には順序があり、初めから完璧な人なんていません。細部ばかり気にしていたら時間は過ぎてしまいます。気にしている暇があれば、どんどんチャレンジすればいいのです。全てを覚えるにしても、初めの一歩は絶対に必要なのです。
ですから、細部を気にせず全体像から覚えたほうが効率がいいと言えます。細部まで覚えようと専門書を熟読する人もいますが、それでは逆に覚えません。私は初めは速読して全体像を掴み、何度も読む事により脳内の情報を正確にしていきます。何故ならば、1回で覚えようとしても無理ですし、細部にばかり気を取られては迷子になります。それならば、大まかな脳内地図を描く方が効率が良いはずです。
そろそろ纏めに入ります。新しい物事を習得する方法は、その物事を愛して、焦らず細かい事も気にせずに、ただひたすら楽しむだけです。そうすれば、何事も容易に習得できます。身構える必要はありません。ただ、心を自由にして、素直に愛し続ければいいのです。好きだから情報処理技術を学ぶ。それで良いのです。難しい理屈は要りません。

中の人の徒然草339

おはピヨ♪今日もプログラティックなインドリです♪
昨日、並列処理についての書籍を紹介しました。
マルチコア時代の昨今では、当たり前のようになってきた並列本ですが、昔は資料が少なくて苦労したんだよなー。
例えば、Javaだとこの本を頼りにしていました。



でもこの本だけじゃあ心もとないから、OS本を併読していました。
今は結構抽象化されているけど、昔はOSの知識が必要だったんだよね。
まぁ、なくても何とか出来るだろうけど、 OSの知識がないとデバッグが出来ないから、 実務でやるにはOSの知識が必要な感じかな？
でも、今はマルチコア時代。
これからバンバン専門書が出版されることでしょう。

あっ、そういえば、Sleep関数を使うと何故処理効率が1.99倍になるのかと訊かれた事があります。
これはもちろん狙ってやった事ですが、説明すると長くなるんですよね・・・
簡潔に言うと、WindowsOSのスレッドスケジューリングの性質と、Sleep関数の仕様と、OpenMPのメモリモデルなどを加味して、OSに負荷をかけて、OpenMPが生みだすオーバーヘッドと同じ状態にしてしまったから2倍に近くなるというわけです。
これを知り合いに言ったら、「どうしてそんな真似が出来る？」と訊かれました。
どうしてって言われても・・・ミニOSとコンパイラを実装した事があるからかな？
さらに導出過程も訊かれましたが、自然にわき出てくるものだから分かりません。処理効率を1.99倍にしようと思った瞬間に閃いたもので・・・
譬えミニでも実装した経験があればOSが嫌がりそうな（負荷がかかりそうな）処理の検討がつきます。
そうすれば、今回のように処理効率をある程度操作する事が出来ます。
この一件で改めてディープな知識の必要性を感じました。
これからは並列処理がどんどん抽象化されていき、低レイヤを学習しない人がより一層増えるでしょうが、やはり切り札となるのは知識の深さです。
表面的に物事を見て、「抽象化されているから必要ないさ」と考えずに、どんどん低レイヤな技術も学習しましょう！
不景気の荒波に負けないように、知識という名の錨をおろしましょう♪

中の人の徒然草338

こんにちは♪今日も元気溌剌なインドリです♪
昨日は、この本をざっと読みました。



私にとっては既知の情報ばかりだったのですが、それでも為になる事が書いていましたし、要点がまとまっていて中々良い本でした。
この本の著者は並行処理20年を超える凄い人です。
一方私の方は、実務では大概マルチスレッドプログラミングを行っていたので、およそ10年ぐらいになります。
※研究開発やERPはマルチスレッドが当たり前。
そんなスペック1/2以下の私でも分かる範囲だったので、この本は並行処理の入門書と言えるでしょう。
並行処理の初心者はこの本を読むといいと思います。
ただし、ちょっとはマルチスレッドプログラミングをしていないと、この本を理解できないと思います。
ですから、理想的な読者対象は「マルチスレッドプログラミングをちょっとしているプロの人」かな？

著者はまだまだ余力を残していると思われますので続編を希望します。
もっとディープな内容の本を読みたいな♪

中の人の徒然草337

こんばんは♪マックチキンが復活して喜んでいるインドリです♪
うーん、今日は何を書こうかな・・・
突然ですが今ふと思いました。多数の言語を習得し、広範囲な知識を身につけてよかったと。
狭い範囲でしか学んでいないと、今の流れにはついていけていないでしょう。
例えば、関数型言語を学習していたから昨今のプログラム言語についていけていますし、並列処理もかなり昔から視野に入れていたから対応できていますし（省略）
やはり、幅広く学習していると得な場面が多いです。
新人さんはどんどん学習していきましょう。

話しは変わりますが、ガベージコレクション本がまだ届かないorz
早くガベージコレクションを知りたいな♪
この知識がないと、今時のコンパイラを実装出来ないから凄く重要です。
それに、ガベージコレクションを知っておいた方が、よりJavaや.NETを巧みに操れます。
やはり、何時の時代になっても低レイヤな知識は必要です。
私は広範囲の学習は済んだので、今後は深く深く学んでいきます。
何時の日にか、お客様の希望するシステムを、OSレベルから実装出来る職人になりたいです。
それを目指して、今日も精進します。

書籍をつつく138－More Effective C#。要点をついたルーター書。

C++の世界にはEffective C++ 原著第3版 と 新訂版 More Effective C++が聖書としてあげられるピヨ。
そして、Javaの世界ではEffective Java 第2版が聖書と呼ばれているピヨ。
とくれば、C#の世界にもバイブルが欲しいよね♪それが・・・実はあるピヨ。
今回それを紹介するピヨ♪じゃーん♪

【目次】
第1章　ジェネリック
項目1　1.ｘフレームワークAPIのクラスではなく、ジェネリッククラスを使え 
項目2　制約は必要最小限にして十分なものを定義せよ 
項目3　実行時型チェックを使ってジェネリックアルゴリズムを特化せよ 
項目4　ジェネリックを使ってコンパイル時型インターフェイスを強制せよ 
項目5　ジェネリッククラスはIdisposableを実装すつ型のパラメータのサポートを忘れるな 
項目6　型パラメータのメゾット制約の定義にはデリケートを使え 
項目7　基底クラスやインターフェイスのためにジェネリックな特別バージョンを書くな 
項目8　型パラメータがインスタンスフィールドでない限り、ジェネリックメゾットを選べ 
項目9　out、ref引数よりもジェネリックとともに古いインターフェイスも実装せよ 
第2章　C＃におけるマルチスレッド
項目11　スレッドを作らずにスレッドプールを使え 
項目12　スレッド間通信のためにBackgraoundWoｒkerを利用せよ 
項目13　同期のためにまｘずlook（）を使え 
項目14　ロックハンドルのためにはできる限り小さなスコープを使え 
項目15　ロックハンドルされたセクションからは未知のコードを呼び出すな 
項目16　Windows フォームとWPFのスレッド間呼び出しを理解せよ 
第3章　C＃の設計実践
項目17　シーケンスのためには合成でできるAPIを作れ 
項目18　アクション、述語、関数から反復処理を切り離せ 
項目19　シーケンスの要素は要求されたときに生成せよ 
項目20　関数引数を使って結合を緩めよ 
項目21　メゾットグループは明快で完全な定義を優先せよ 
項目22　演算子の多重定義よりもメゾットの定義を優先せよ 
項目23　イベントはオブジェクトを実行時に密結合することを理解せよ 
項目24　イベントはvirtual宣言するな 
項目25　例外はメゾットの約束ごとが守られなかったときに使え 
項目26　プロパティはデータらしくふるまうように作れ 
項目27　継承と合成を区別せよ 
第4章　C＃3.0の新機能
項目28　拡張メゾットでインターフェイスの最小限の約束を補え 
項目29　拡張メゾットでクローズジェネリック型を拡張せよ 
項目30　ローカル変数ではできる限り暗黙の型付けに委ねよ 
項目31　無名型を使って型のスコープを制限せよ 
項目32　外部コンポーネントに対する合成可能APIを作れ 
項目33　束縛変数の変更を避けよ 
項目34　無名型を使ってローカル関数を定義せよ 
項目35　拡張メゾットを多重定義してはならない 
第5章　LINQの操作
項目36　クエリ式からメゾット呼び出しへの変換がどのように行われるかを理解せよ 
項目37　遅延評価クエリーを使うようにせよ 
項目38　メゾットよりもラムダ式を使うようにせよ 
項目39　関数やアクションで例外を投げるな 
項目40　遅延実行と先行実行を区別せよ 
項目41　高価なリソースを抱えこまないようにせよ 
項目42　IenumerableデータソースとIquertableデータソースを区別せよ 
項目43　Single（）とFlash（）を使ってクエリのセマンティックスを指定せよ 
項目44　Func＜＞ではなくExpression＜＞を格納するようにせよ 
第6章　その他
項目45　null許容値のスコープはできるだけ狭くせよ 
項目46　コンストラクタ、ミューテータ、イベントハンドラのために部分クラス、部分メゾットを使え 
項目47　配列引数を使わず、Params配列を使え 
項目48　コンストラクタで仮想関数を呼び出すのを避けよ 
項目49　大規模なオブジェクトでは弱参照を検討せよ 
項目50　ミュータブルでシリアライズできないデータは自動実装プロパティにせよ 

早速ゲットして読んだピヨ♪この本の内容は、C#の効果的な使い方 ピヨ♪この本を読めば、C#1.1以降から追加された言語機能をどのようにして使うのかという事が分かるピヨ。特に ジェネリックに関する説明は役に立つピヨ。他にもマルチコア時代を反映して、マルチスレッドプログラミングについても書かれているし、LINQについても書かれているピヨ。広く学べるピヨ♪
この本は良い本で、C#使いならば絶対に読むべき本だと思うけど、それだけに残念な事があるピヨ。それは、広すぎて個々のトピックが少ない点が気になるピヨぉ。マルチコア時代だから、マルチスレッドを取りあげるのは良いことだし、LINQの知識も必要なのは分かるピヨ。だけどそれが災いして、ボクは物足りないピヨ。
理想的には、マルチスレッドとLINQは別冊にして内容を充実してほしかったピヨ。この本に書かれている事は、間違っていないし、要点は押えていると思うんだけど、いかせんマルチスレッドとLINQを相手にしては分が悪いピヨ。もっと特別に取り扱い（別冊にしてしまって）、C#における設計と言語の機能に注力した方が良かったとボクは思うピヨ。
そろそろ纏めるピヨ。この本はC#使いには必読の書ピヨ。だけど、マルチスレッドとLINQは不十分だから他の本を当たろう。また、オブジェクト指向御設計についても物足りないし、C#の言語機能についても不足しているピヨ。だけど、的確に要点はついているから、この本は各専門書のルーター的存在と言えるピヨ。この本を読んで、さらなる知識を探求しよう！


他の本を知りたい人は書籍レビュー目次を見るといいピヨ。今まで紹介した本を纏めているピヨ。

ネタつつき0401－究極のコンパイラ。

インターネットを飛び回っていたら、ボク凄いコンパイラを発見してしまったピヨ♪
その言語の名前はAprilで、最新の人工知能技術を取り入れた究極のコンパイラなんだ。
パラダイムは基本的に自己推論型で、今時の言語によくあることだけど、命令型・関数型・論理型・並列型・分散型・集合型・オブジェクト指向・エージェント指向などの要素も取り入れているピヨ。
この言語の目玉機能はやはり自己推論機能の一つであるfoo構文ピヨ♪
この構文を使うと、毎度おなじみHelloWorldがたった一行で記述できるピヨッ♪

foo{ "Hello, World！ }

foo構文は｛｝内に命令文をかくと、コンパイラが推測してバイナリを出力するんだ。
ただ、コンパイラ君が間違うかもしれないから、コンパイラをインストールした直後は、文字列の開始記号である"はつける方がいいらしいピヨ。
この時点でも凄いと思うけど、この言語には自己学習能力があって、一度実行したHelloWorldプログラムはもっと短くできるんだ。

foo{ "H }

こうすると、コンパイラ君が「どうせいつものHelloWorldだろ」と考えて、コンパイルせずに直接コンソールが面を立ち上げて「Hello, World」と表示してくれるピヨ。
だけど、注意が必要ピヨ。どんな強力な機能にも落とし穴があるピヨ。もし、Hello, Worldではなくて、Hello, Piyo！を表示したい時問題になるピヨ。具体的に言うと・・・

foo{ "Hello, Piyo }
foo{ "H }

この時コンパイラがどうするべきなのかは実装依存なんだ。だから、Hello,Piyo！と表示されるのか、Hello,World！と表示されるのかは分からないピヨ。でも、このプログラムは直後だから実装依存になるのであって、Hello,Piyo！を表示するプログラムの実行を終えてから、もう一度次のプログラムはコンパイルエラーになるピヨ。

foo{ "H }

【コンパイルエラー】
・ツッコミ１
このプログラムわけわからんわ。
Hello, World？Hello, Piyo？どっちやねん！もっとキー叩けや！
・ツッコミ2
打ち間違ったんちゃうか？

※この言語は人工知能搭載だから、インストール時に設定した出身地と性別に基づいてエラーメッセージが変化するピヨ。

この様にエラーメッセージが表示されるピヨ。これに対処するには、コンパイラが分かるようにPかWまでプログラムを指定すると良いピヨ。
凄い便利な機能ピヨッ！この短いプログラムでは分かりにくいけど、foo構文は何行でも指定できるから生産性が凄くアップするピヨ♪
でも、一つ注意が必要ピヨ。それは、「コンパイラ同士の記憶を共有する必要がある点」ピヨ。
例えば、Aさんはいつも画面にピヨと表示しているかもしれない。だけど、Bさんはいつも画面にfoolと表示しているかもしれない。この言語は自己学習する事が仕様によって決定されているから、チーム開発する場合は、記憶の共有という機能を使う必要があるピヨ。
それを使うと、コンパイラ同士が仕様で定義されているプロトコルに基づいて通信し、推論機能に使用する記憶データーベースを更新する事により自己推論機能の同期とUPを図るピヨ。
でもこの機能にも一つ憂慮するべき点があるピヨ。それは「コンパイラ同士の性格が合わない場合がある事」ピヨ。
この言語は自己推論機能によって、使用者の良きパートナーとなるように設計されている。
だからコンパイラ毎に性格が形成されて、性格が合わない場合は記憶の共有機能でエラーが出る場合があるピヨ。
そういった場合の解決法は、残念ながら実装依存なんだ。仕様書には「話し合いが好ましい」と書かれているピヨ。
強力すぎる機能には落とし穴があるって事だね。
それから、記事が書かれた日にも注意が必要ピヨ。

中の人の徒然草336

おはようございます♪今日も情報処理技術Loveなインドリです♪
昨日、関数型言語の本をペラペラ読みしてみました。




その感想をちょっと書きます。
やはり、if文・for文といった制御構文は関数型言語のように簡略に記述するのが望ましいですね。
if文の様な制御構文は実装的な詳細であって、やりたい事ではありません。
十万行を超えるプログラムを打つとそれが実感できると思いますが、制御構文は意外とノイズとなります。
さらに、百万行を超えるプログラミングをすると、それが非常に鬱陶しく感じてしまいます。
もちろん、悪い時ばかりじゃなくて、実装の詳細があった方が助かる時もあるのですが、プログラミングに慣れてくると当たり前だと感じて、省略したくなるものです。
それから、Clojureのパラメータの書き方には感心しました。
LISPプログラミングをすれば分かりますが、精神状態によっては、括弧ばっかりで見にくいと感じる時もあります。
※気にならない時の方がおおいけどね。
ですから、[]にして視覚的に変化をつけたのは非常に良いアイデアだと思います。
他に気になったのは、やはり並列処理のやり方です。
やはり、副作用がない言語は並列処理に強いですね。
Java、C#、VB、C++といった言語よりも簡潔にかつ安全に記述できます。
簡潔にすればいいってものじゃあないけども、やはり簡潔に記述できるのは嬉しい事です。
プログラミングに慣れてくると、「なんで自明な事ばかりかかないと駄目なのだろうか？」と感じる時が多々あります。
日本は何でも保守性で誤魔化す傾向がありますが、プログラム言語はプロの道具なのですから、プロが便利だと感じる方向性にしてほしいです。
そうしないと、数十万行を日常的に担当している身にとっては、精神的にも肉体的にも非常に疲れます。
その理由は色々あるのですが、スクロールが疲れる、目が疲れる、頭の中のイメージのコードを検索するのに疲れる、納期が迫った際に、if文とかの決まり文句を書いているとイライラする、一瞥できるコードの内容量を増やしたい・・・などといった事が挙げられます。
他にも色々細かい事を感じたのですが、後でじっくり読んで考えをまとめる事にします。

これらの本を読んで考えたのは、理想の言語とは何かという事です。
関数型言語の要素は必要なのは確かです。ですが、命令型言語も捨てたものじゃありません。
また、集合型言語と論理型言語にも魅力があったりします。
ですから、私としては全ての要素を持つ言語が理想的だと考えております。
しかも、情報の抽象化をコントロールできるのが望ましいです。
全て高度に抽象化したらシステムプログラミングが出来ません。
それと、コンパイルのパス数を増やして、静的メタプログラミングを行う能力も欲しいです。
C++のテンプレートメタプログラミングがそれに近いのですが、まだまだ不足しております。
パス数を増やして、コンパイラ側でメタプログラミング専用の段階をちゃんと設ける必要があります。
私が本気でコンパイラ作るのであれば、必ずパス数を増やして、メタプログラミングを積極的にサポートします。
とくれば、当然動的メタプログラミングも必要です。
メタプログラミングは段階が大事です。コンパイル時なのかコンパイル後なのかによって、プログラミング手法は大きく異なり、実現できる事も異なります。
他にはLINQでかなりいいところまで実現されているように、集合型言語の要素も積極的に利用したいです。
私はそれがしたくて、ADOの時代にADO.NET＋LINQと酷似した技術を自作しました。 今ではその秘密の技術が公然に使えるのがうれしいです♪
他にも色々ありますが、これらの事を纏めて考えるに、現在のコンパイラは情報を整理していない部分があります。 この事は言葉では表現し辛いのですが、技術者としての本能がむずむずするんですよね。「もっと良くなるぞ！」ってね。
それを整理すれば、もっとコンパイラは進化します。コンパイラの進化は十分だという人もいますが、そんな事はありません。色々弄りたい部分があります。
もしかしたら、私は元々コンパイラ屋さんではなくて、自分が研究してた事が偶然コンパイラという技術分野と重なる部分があっただけなので、コンパイラ屋さんの感性とは違うかもしれない。
他にも既存の情報処理技術には弄りたい部分が沢山あります。それを実現するには、もっともっと技術力がいります。自分の実装能力のなさが口惜しいです。
だから、もっと自分を鍛えねばなりません。でもそれが楽しいです。
もしかしたら私は、自分というソフトウェアをメタプログラミングによりバージョンアップして、理想のソフトウェアを作りたいのかもしれません。そして、その行為自体が幸せだと感じているのかもしれない。
なにはともあれ、情報処理技術って本当に魅力的ですね。この技術がこの世にあったというだけで、幸せだと感じます。