go(graphicalObjects)を作る前に各種基礎機能を作りこんでおこう、と思い、今日までdataCartを作っていて、その構造を再確認するためにルーズリーフに手書きでイメージを書き込んでいる時に、俺は気がついた。
いつのまにか宗旨が変わっている、と。
goって言うのは、文字を使ってプログラミングするJavaScriptをグラフィカルな物にするための物、って言う物だ（本当は最初からそう考えていた訳じゃ無いし、それだけを行うための物にするつもりは無いが）。
それなのに、JavaScriptの上に複数の基礎機能を備えたベース層を作り、ベースの上にgoを作ろうとはナンセンス。
goはjsと直接対話して双方向翻訳を行う仲介役……ちゅーか、全ての層に対する仲介役。もちろんjsとも対話するけど、jsの上に作られたオブジェクトとも対話するために、相手によって話し方を切り替える機能を備えるつもり。
goのユーザーはマウスやキーボードを使って視覚的な情報を作成し、goは作成されたイメージがどの層の中に作られた物かを判別して使用する言語を切り替え、対象となる層に然るべき手段で情報を送る。情報を送った事に対してリターンがあった場合、ユーザーがリターンの通知を許可しているか求めている場合にそれを通知するとか。
goは特定の作業を行うために最適化された物では無い。
データをメディアに保存するとか、読み込むとか、配列や文字列や数値を操るとか、そういう事は全く出来ない。
出来る事は、「特定の作業を行うために最適化された物」に対して「それが用意している窓口を利用して、ユーザーからの指示をそれに伝える」と言う事。それだけ。
そしてgoがユーザに対して用意する窓口は、グラフィカルな物になっている。そういう事。
てな訳で、何を作るよりまず先にgoを作らなきゃいけなかったと言う事を思い出した。
dataCartは確かに、イメージの情報を保存するために必要だが、それはユーザが指示するまで実行するべきでは無い。
それと、JavaScriptでのプログラミングを行うための層は常に最下層になるが、その層で作ったオブジェクトの上下関係はどのように構成するか、って言うのもやっぱりユーザが決めるべき事だ。
メディアに触れるからdataCartは常にJavaScript層の一つ上、なんて考え方はおかしいと思った。
だから俺は、全ての操作の基本となる部分を担うgoを作る。これから。
とは言え……難しい。果てしなく。
概念が抽象的すぎる。
しかも縛りがキツい。どこまでも拡張を続けられるようにしながらプログラミングするって言う制約は自分で作ったんだが、これを維持しながら何か作るって言うとどうしても基礎プログラムを全力で作り直しながらやらなきゃならんくなる。いつまで経っても基礎工事を抜けられず、イメージが見える状態になるまですんごく時間がかかって飽きる。
基礎プログラムって言う物は、一番最初に作る必要があるくせに、実際に使用されるのは開発工程の後ろの方だったりするので、かかる労力の割りに成果が見えない性質があると思う。
しかしそういう物があるのはある程度仕方が無い事だとも思う。
例えば、料理を始める前には材料が揃っているか確認する必要があるし、足りない物があるなら買いに行く必要があるが、その前に財布の中身を確認する必要があるし、財布の中身も足りないようなら銀行に行く必要がある。
金や材料を揃えておくって言うのが基礎工程にあたり、料理するのがメイン処理工程になる。
材料も金も確認する前に料理を始めると色んな所でつまづいて、思考ルートが枝分かれして集中して考えるのが難しくなるので、俺はなるべくストレートに走れる道を見つけてから走り出す事にしている。
実際の料理と違って、パソコンの上でのプログラミングなら料理を行うプログラムを途中まで書いた状態にしといて、財布の残高を確認したり買い物に行くプログラムを書く事は可能だが、そういう事をするとどのプログラムがどこまで完成しているのかをそれぞれ覚えておかなきゃいけなくなるのであまり好きじゃない。
ふと、思ったんだが、事前の準備をほとんど必要としないプログラムの書き方って無いのだろうか。
処理を行ううえで必要になった物を、必要になったタイミングで書いて、それを書き終わったらまたメインの処理に戻れるような書き方。
具体的に考えてみると、プログラムで何かしらの処理を行い、その結果とか設定情報とかをメディアに保存したい、っていう需要が出来た段階で、保存用プログラムを書いてしまうと言うやり方。
保存するにしても適した形式のデータを保存用メソッドに投げてやる必要があるので、必要に応じてデータを変換したり、最初から適した形式でデータを作り上げていくやり方があるが、変換と言うのは情報を削ったり歪めたりする可能性がある行為だからあまりやりたく無い。しかし、最初から適した形式でデータを作り上げるようにするためにはまず保存用メソッドを作ってそれがどんなデータを受け付けるのかを把握しながらメインプログラムを書く必要があるので開発工程がマルチスレッドみたいな状態になってややこしくなるし、規模が膨らめば膨らむほど個々のプログラムの開発速度が落ちてしまい、ハンパじゃない労力がかかるようになる。
なんかこう、スマートじゃ無い。
こうしたらどうかな、って言う案は出るんだけど、それを否定する条件がすぐに浮かんでくる。
プログラムが立体的に膨らんでいってしまうのは困る。
俺の体の性能は、残念ながら低い。多重化する開発工程をキッチリ管理しとおす事ははっきり言って無理だ。
しかし個々のプログラムを一つづつ作っていくってのも、飽きてしまう。
かけた労力に対する成果がもっと確実に見えればもうちょっとはやる気も持続するかもしれない。
とか、結局やる気の問題なんだけど。
まぁ、とりあえず───材料が無ければ作業を続けられない料理から学んで、材料の有無に関わらずスタートしたらラストまで駆け抜けられるようなプログラムを書いてみようかなと思った。
材料の準備状況に配慮しないプログラムを書くと、想定外の状況に置かれた時にエラーが出て処理が止まってしまい、フラストレーションが溜まるし、止まった箇所より後ろに潜むエラーの存在が見えなくなるから修正が必要な箇所の全体数が把握できなくて面倒、と言うか終わりが見えないのはキツいし。
想定内のエラーが出たら処理継続 & エラーログ追記って感じで。
エラーログってのも作るの割と面倒臭いけどな。
やたらif文増えてプログラムが見づらくなるし、出力されるログがあまりにも膨大な量になるなら階層化するとかして整理しないとワケ解らなくなるし。
でも、やっぱりgraphicalObjectsは欲しいから作る。
あったら絶対楽しいと思う。きっと。
いつのまにか宗旨が変わっている、と。
goって言うのは、文字を使ってプログラミングするJavaScriptをグラフィカルな物にするための物、って言う物だ（本当は最初からそう考えていた訳じゃ無いし、それだけを行うための物にするつもりは無いが）。
それなのに、JavaScriptの上に複数の基礎機能を備えたベース層を作り、ベースの上にgoを作ろうとはナンセンス。
goはjsと直接対話して双方向翻訳を行う仲介役……ちゅーか、全ての層に対する仲介役。もちろんjsとも対話するけど、jsの上に作られたオブジェクトとも対話するために、相手によって話し方を切り替える機能を備えるつもり。
goのユーザーはマウスやキーボードを使って視覚的な情報を作成し、goは作成されたイメージがどの層の中に作られた物かを判別して使用する言語を切り替え、対象となる層に然るべき手段で情報を送る。情報を送った事に対してリターンがあった場合、ユーザーがリターンの通知を許可しているか求めている場合にそれを通知するとか。
goは特定の作業を行うために最適化された物では無い。
データをメディアに保存するとか、読み込むとか、配列や文字列や数値を操るとか、そういう事は全く出来ない。
出来る事は、「特定の作業を行うために最適化された物」に対して「それが用意している窓口を利用して、ユーザーからの指示をそれに伝える」と言う事。それだけ。
そしてgoがユーザに対して用意する窓口は、グラフィカルな物になっている。そういう事。
てな訳で、何を作るよりまず先にgoを作らなきゃいけなかったと言う事を思い出した。
dataCartは確かに、イメージの情報を保存するために必要だが、それはユーザが指示するまで実行するべきでは無い。
それと、JavaScriptでのプログラミングを行うための層は常に最下層になるが、その層で作ったオブジェクトの上下関係はどのように構成するか、って言うのもやっぱりユーザが決めるべき事だ。
メディアに触れるからdataCartは常にJavaScript層の一つ上、なんて考え方はおかしいと思った。
だから俺は、全ての操作の基本となる部分を担うgoを作る。これから。
とは言え……難しい。果てしなく。
概念が抽象的すぎる。
しかも縛りがキツい。どこまでも拡張を続けられるようにしながらプログラミングするって言う制約は自分で作ったんだが、これを維持しながら何か作るって言うとどうしても基礎プログラムを全力で作り直しながらやらなきゃならんくなる。いつまで経っても基礎工事を抜けられず、イメージが見える状態になるまですんごく時間がかかって飽きる。
基礎プログラムって言う物は、一番最初に作る必要があるくせに、実際に使用されるのは開発工程の後ろの方だったりするので、かかる労力の割りに成果が見えない性質があると思う。
しかしそういう物があるのはある程度仕方が無い事だとも思う。
例えば、料理を始める前には材料が揃っているか確認する必要があるし、足りない物があるなら買いに行く必要があるが、その前に財布の中身を確認する必要があるし、財布の中身も足りないようなら銀行に行く必要がある。
金や材料を揃えておくって言うのが基礎工程にあたり、料理するのがメイン処理工程になる。
材料も金も確認する前に料理を始めると色んな所でつまづいて、思考ルートが枝分かれして集中して考えるのが難しくなるので、俺はなるべくストレートに走れる道を見つけてから走り出す事にしている。
実際の料理と違って、パソコンの上でのプログラミングなら料理を行うプログラムを途中まで書いた状態にしといて、財布の残高を確認したり買い物に行くプログラムを書く事は可能だが、そういう事をするとどのプログラムがどこまで完成しているのかをそれぞれ覚えておかなきゃいけなくなるのであまり好きじゃない。
ふと、思ったんだが、事前の準備をほとんど必要としないプログラムの書き方って無いのだろうか。
処理を行ううえで必要になった物を、必要になったタイミングで書いて、それを書き終わったらまたメインの処理に戻れるような書き方。
具体的に考えてみると、プログラムで何かしらの処理を行い、その結果とか設定情報とかをメディアに保存したい、っていう需要が出来た段階で、保存用プログラムを書いてしまうと言うやり方。
保存するにしても適した形式のデータを保存用メソッドに投げてやる必要があるので、必要に応じてデータを変換したり、最初から適した形式でデータを作り上げていくやり方があるが、変換と言うのは情報を削ったり歪めたりする可能性がある行為だからあまりやりたく無い。しかし、最初から適した形式でデータを作り上げるようにするためにはまず保存用メソッドを作ってそれがどんなデータを受け付けるのかを把握しながらメインプログラムを書く必要があるので開発工程がマルチスレッドみたいな状態になってややこしくなるし、規模が膨らめば膨らむほど個々のプログラムの開発速度が落ちてしまい、ハンパじゃない労力がかかるようになる。
なんかこう、スマートじゃ無い。
こうしたらどうかな、って言う案は出るんだけど、それを否定する条件がすぐに浮かんでくる。
プログラムが立体的に膨らんでいってしまうのは困る。
俺の体の性能は、残念ながら低い。多重化する開発工程をキッチリ管理しとおす事ははっきり言って無理だ。
しかし個々のプログラムを一つづつ作っていくってのも、飽きてしまう。
かけた労力に対する成果がもっと確実に見えればもうちょっとはやる気も持続するかもしれない。
とか、結局やる気の問題なんだけど。
まぁ、とりあえず───材料が無ければ作業を続けられない料理から学んで、材料の有無に関わらずスタートしたらラストまで駆け抜けられるようなプログラムを書いてみようかなと思った。
材料の準備状況に配慮しないプログラムを書くと、想定外の状況に置かれた時にエラーが出て処理が止まってしまい、フラストレーションが溜まるし、止まった箇所より後ろに潜むエラーの存在が見えなくなるから修正が必要な箇所の全体数が把握できなくて面倒、と言うか終わりが見えないのはキツいし。
想定内のエラーが出たら処理継続 & エラーログ追記って感じで。
エラーログってのも作るの割と面倒臭いけどな。
やたらif文増えてプログラムが見づらくなるし、出力されるログがあまりにも膨大な量になるなら階層化するとかして整理しないとワケ解らなくなるし。
でも、やっぱりgraphicalObjectsは欲しいから作る。
あったら絶対楽しいと思う。きっと。