戯
- 自称(=思い込んでるだけの偽物かも知れない)Object指向オタクだな。
- 計算機プログラムは「走る」(のが本分である)とは言い切れないと思う。
- 日本語にもLispのようにNest可能な括弧を導入すべきだと思う。
- というか、括弧だけじゃまだ不足だと思う。もっと色々なものが欲しい。
- 計算機工学(なのか?)で得られた成果は、もっと自然言語に反映されて欲しい。
- ことば(の違い)は重要だと思う。本題をさておいてでも(笑)正しておく価値が有ることは「非常に」頻繁に有ると感じる。
- むしろ、そういう形式的議論のほうが、他のものの合間に挿入しやすいと思う。
- 「(笑)」と書いてあったら、これが「笑え」という意味(命令)だとは、絶対に思わない(笑)
- 自己矛盾というものの存在が敵か見^味方かすら、判らない(結論が出ない)でいる。
- 人道と理性(ぷ)の敵を、しばしば「ｍ」というシンボルで説明しようと、する(躍起になる(笑))。
- モバイル人生である。
- そのせいで、計算機や電話は携帯できる無線なものしか持ち合わせていない。
- 手書き文字は、捨てた。
- お祭り騒ぎに混じる(乗じる?)のは、好きである。
- 祭りで客と談笑しながらリアルタイムで妙なものを作って客に渡す(売る)のは、心底楽しいと思った。
- Programming(仕事を含めて)も、それと同様にお祭りのようにやれたらイイなぁと思っている。
- 記憶力は、ほぼ無い。
- 自宅(?)のWiki。 TikiGuion。
- 作曲も作文も絵もソフトも(たぶん他の色々も)、等しくHack(のネタ)だと思う。
- 自分で作ってて自分で吹き出すくらいのものでないと、Hack(の成果物)とは呼べない、と思う。#自分はHackerでもないくせに、根拠無くなぜかそう信じてる。
- RMSと岩谷氏は、同じ意味で(ぉ)偉いと思っている。
- ビジネスという単語がどうも嫌いだ。RMSが製品(Product)という言葉を嫌うのと同じ意味で(だと思っている)。つまり、それは誤用だと思うという意味で。
2006/12/26 00:42:08 PST
激しくおひさしぶり。
- (Shiroさん(2006/12/19 05:38:35 PST))
- >仕事が多様化した今
- 仕事の結果は(これだけ世間の製品が多様だから明らかに)多様なんだけど、
仕事場の有りようもまた多様なんでしょうか？
そちらについても「個性」という言葉が崩壊してない、
という観測事実(^^;が有ると良いのですが…
040418
- (明示的には)お久しぶり。
- Omicron:w3m に書いたように AirH"+Venturi+w3m(cygwin)で見れなくなったサイトとしてココ(てゆーかWiLiKi全て？)も含まれてるもんだから、巡回すら不自由な昨今。IEじゃダルイし。原因は何なんだろうな…
- kahuaセミナー覗きたかったなあ。3月からは関東勤務になったので行動の自由度が少々増しそうです。2回目は有るんでしょうか？
- ところで間違えてkafuaとか綴ってしまうとCoffee(元はアラブ語で"力"を意味するKafaという単語だったとか。リポDみたいな捉えられ方だったのかな)に近づいてしまいますね。そうかそうか。「kahua is not Java」ってことだな(^^;
- The Other Road Ahead って、「ばらまきは善」か否かという意味では、オープンソースとは真逆なスタンスですね。開発デバッグ巻き込まれ隊(笑)の数を最大化するか最小化するかの違い。
- あと、JavaのSwingより遅いであろうNetwork越しという超軽量GUIモデル(藁)が何処まで戦えるか。アメリカに行きたいかー？SWTは怖くないかー？
- 「とりあえず使えることは重要」と言われてもねえ。「それで足りる用途にのみ普及する」だけのことで。そういや折りしも世間はリッチクライアント云々で再び騒ぎ始めてる雰囲気。
- まあ、自前Hostで運営してるくせにSecurityやBackupが甘いDQN企業が倒れてくれれば、それもまた世のためだが、その過程で、情報流出で泣きを見る顧客も多いでしょうね。そういや今年は流出大騒ぎ元年かと。
030802
- Omicron:プログラミング に書いた「後回し配列」って、やっぱりLisp的には珍しくもなんともないですよね？(^^;
- 梅雨明けしなくていいです。暑いから。ちなみにクーラー壊れたまんま(藁)。このまま冷夏で推移してくれるといいな。東電も助かるだろし(藁)。タイ米でも俺はたぶん平気。
- あちこちで何度も言ってるが、これだけ普及したBloadBandを、なんで人はシゴトに使わないのかが不思議。札幌から現場にtelnet(ssh)させてくりゃ、俺もわざわざ暑い思いしなくて済むのに。
- 某。あまりにもIT(ジョーホーのギジュツ)に背を向けた要求をするので、驚き呆れた。そんなにMailが嫌いなら自分が読まなきゃいい。Mailが自分らの不都合の原因だと誤解してる(思い込もうとしてる?)辺りが痛すぎ。
- それとも電子メディアを上意下達のため「だけ」に使いたいのかな？なんて傲慢な。
- ITってこういう傲慢を打破するための道具で(も)あると思いたいんだが、道具は逆な立場の奴も使える。道具の善悪は使う人の心に有り。俺は天を仰ぐのみ。
- たった今、炸裂音のような強烈な音と光が。夕立の雷鳴か？近所(埼玉某所)で花火大会なんてやってたっけ？荒川？
030704
- バベルの塔の建築を怒った神は、括弧の際限無しのネストを瞬時に理解する能力を、人間たちから奪った。
その瞬間から殆どの人間たちは、曖昧だったり冗長だったりする不恰好な文法しか使いこなせなくなり、
「より弱い」言語(複数)へ目掛けて四散していった。
030411
- TikiGuion:Object短冊 (ぉ
- Rose(など)を使ってる人は可哀想。作業をする道具としては余りにも鈍重というか使いにくいので。
- てゆーか何年経っても使いにくいねRose。マクロ使えって?それはそれ。
- あと、画面や紙(!)の面積に縛られるってのは酷すぎ(＞Roseに限らず窓系のアプリ一般)。紙の制約を最初から意識させないでくれ。後からトリミングならまだ許せるが。
- JavaServerFacesとJakartaVelocityとは、実は逆向きなのかも。まあどちらも"くそJSPからの逃亡"なんだろうなと推察。
- 道具って、自立(あるいは自律?)性を徹底的に増やすか捨てるか、どっちかをしないと使いにくいと言う事なような気がする。その点JSPは半端。
- 頁遷移と状態遷移(=MVC)を同時にやろうとするからオカシなことになるんだ、という趣旨でwebアプリ全般を批判してみるテスト。
- 世の中にたえて頁遷移のなかりせば…
- 頁遷移「しない」Frameworkが、例えばJSFなんだろうな。同一(見かけ上)頁上でMVCが動く。
- またしてもFrameworkをでっち上げたくなる衝動をグっと堪えて(笑)、JSFとかが成熟するのを期待するテスト。
030315
- ありゃ。なんか色々書いたような気がしてたんだが、Commitせずに終了しちゃったかな？
- Tiki:JavaServerFaces 従来のServlet/Struts(笑)方角とは違い、GUIアプリでお馴染みのイベントハンドラ方角。とりあえず馴染み易いのは確かだろうな。
- というか今までが悪すぎ。考えてみれば、webの素の仕組みがもともと「UI(たくさん)つきアプリ」向きじゃないのを、ラップせずそのままプログラマに押し付けてたようなものだ。
- 「画面にボタンが3つ以上あるアプリは、ボタンにイベントハンドラをbindするモデルで開発するほうが幸せ」とか乱暴に言い切ってみるテスト。
- ちなみにWikiはボタンが3つ未満に収めるのが容易なので…(嘘
- WikiNameはどうよ？Clickするだろが？＜禿しい自己つっこみ
- 訂正。「ボタンがそこにあ(り続け)る」モデルは、「ボタン押したら画面が遷移しちゃう」モデルとは、別世界だ。
- この二者の存在は、他の分野(?)でも見られますね。例えばCUI(?)でも、Filter型ソフトや、選択肢番号を次々入力してく奴は、ボタン(?)が刹那に消えていく世界。対してviやEmacsはボタンが有り続ける世界。
030225
- Jakartaプロジェクトの本(?)を眺めてみる。で、TaglibとやらはLispとかの拡大してない再生産(笑)にしか思えない。
- htmlチックな中に無理矢理突っ込む代物で、かつTagは"関数"としてしか存在できないから、似るのは当然か。おかげでifもiterationも例外捌きも関数(=tag)だ…
- 型も(ぱっと見は)緩いんで、JavaやXMLが威張るみたいな感じ(謎)が影を潜めてるし。
- "="による代入に慣れた身には、setqだろうがsetPropertyだろうが、違和感の程度は同じだ…
- 式言語って、要するにScript言語のサブセットを持ち込んでるだけ。
- DynamicBeanFormも強い型の言語からの逃避。結局メンテ性に優れるのは弱い型のLigithWeight言語だとゆー。
- 3分眺めて思ったこと。Velocityで"普通のScript言語"世界に行くほうが、凡人には幸せかと…
- 同Torqueを羨ましがるべきか否かは、まだよく判らぬ。Object間のRelationをどう扱ってくれるか次第。
- というか(真に一般性のある)Object-Relationalマッピングなんてものには正解は無いと思う。有るのは遠回しな絶望だけだろうな。
- くそ。なんで純粋(?)OODBは、かくも流行らないのだ？OOという語の定義の曖昧さのせいか？＃あながち嘘ではないが。曖昧つーか多様だから実装形態を絞り込めないってのも事実だろう。
- S式(やXML)用のキーボード、というのは有るんだろうか？行指向端末用キーボードに改行キーが有るなら、S式キーボードには括弧とかの開閉キーが有るはずだ。
- ついでにいえばS式用Displayは最早長方形では居られまい。とりあえずTree型Displayって作り得るだろうか？(藁
- Shiro: そこまで極端じゃないけど、
括弧は打ちやすくなってます。
また、同キーボードの最上段中央の3つのキーに関しては
「プレステコントローラーの起源」説がまことしやかに囁かれていますが、
×の無いことがその説の最大の弱点となっています。
- kazuya: ×は左下にありますよ :-)
- RationalRoseのソース(?)はS式と行指向を足して3で割ったような感じだっけ。そういや"javacc rose rational".Goole()すると色々と…
- そもそもUMLって弱すぎ、つーか脆過ぎ。曖昧(笑)なOOのためにガチガチのUML文法を用意するなんて、気は確かか？
- Javaの(Unixと比べての)良さを思えば思うほど、ホストOS(大抵はUnix的な)との微妙な相性の悪さに腹が立つ。CLASSPATHに複数要素を書けるんじゃ元の木阿弥だろうに。
030215
- [Omicron:雑談]に、行指向を"捨てて"括弧指向で行く、という環境についての妄想を書いてみる。既存案であることを祈るが。
- そういやracc256本に、括弧じゃなく式とかの終端記号さえ有ればいいよね的な案があるのに気付く。P91の、開き括弧だけの省略って奴。見た目の問題は括弧以外の適切(?)な記号に交換すれば済むし、タイプの手間は省略の恩恵を受けるかな。ちなみに開き括弧の代わりに事実上同等な情報を提供するのが「,」の有無。
- でも、環境全部が括弧を支援する方向に転がれば、括弧の世界で暮らしてもいいんじゃないのか？
- ちなみにEmacsのインデントは全然納得できない(笑)ので、あれが括弧世界だとは思いたくないです。もっと冗談みたいに見やすくなってくれない限りは。
- Strutsをやらされるらしい。面倒なんで(笑)今まで触れてなく、急だったので世間の資料を見る暇もなく、仕方なく概要を前任者に説明してもらう。ぉぃぉぃ。
- それで面白そうだと思ったのが、ActionのForwardという概念。あるActionオブジェクトの処理が終わったら、次に"行く"べき、ActionまたはJSP(URL?)を指す情報をreturnするものらしい。
- Forward先として、Actionと頁が対等な選択肢として用意されてるってのが面白いと思った。もっと処理したければしてもいいし、Userとの対話(頁表示)をしたければしてもいい、どっちにせよそれらは最終的に一続きの処理となるよ、というわけだ。頁のボタンとかは次のActionを導くから、つまりActionか頁からなる連なりをSessionは遍歴してくわけだ。
- 以前の嫌な記憶がよみがえる(笑)のだが、Actionと頁を同一視するというアイデアには、俺は終に至らなかったなあ。
- ん？継続？
- 次にゆくべきAction or URLは、まあ、継続ですね。
ただ、それが返せるだけでは、トランポリンによる末尾呼び出しにすぎないので
あんまりおもしろくないかも。
もしActionオブジェクトが、「呼び出し側が『そのActionオブジェクトが次に
制御を渡して欲しいと思っている』ポインタ」を受け取ることができれば、
継続渡しになるので何かと便利そうです。
(例えば、どんな画面からでもユーザプレファレンスの変更画面を
サブルーチンコールのように呼びだせて、しかもネスト可能とか)。--Shiro
- “なんでも継続”を読むとよくイメージできますね。完成を心待ちにしています。（とプレッシャー ;-）--SHIMADA
- 完成品を渡されてメンテをやらされてる(笑)だけなんで、ご期待のもの(?)が生成される可能性は低そう。
- コードの修正にいちいちハンコを求められる世界では、リファクタリングなんて遠い話です(T_T)。ハンコは品質を殺す。
- XPが言う勇気って重要ですね。今までのオッカナビックリ方式じゃ品質は上がるまい。ハンコ(=修正への障壁)という権威に縋って維持しようと躍起になってるものは、実は品質でも安心でもなんでもなく、むしろオッカナビックリ状態を無理やり現状維持してるだけ。恐怖政治と同質の無理がありますな。
- ネスト可能というと安易にStackを思い出してしまうところ。ただ何を積んだらいいのかが今の疲弊した脳(風邪)には判らないが…
- gotoの仕組を作るには知恵は不要だがcall/returnの仕組には知恵が必要なのかも。MidiPipeもcall/return(電気楽器用語ではsend/return)の実現で躓いたんだったな…
- “なんでも継続”はまだ出てないのでわ？もちろん超期待してまーす(^^;
030107
- 遅れ馳せながら明後日から労働再開。
- TeXやXMLで楽譜やるのが有りなら、Lispでも有りだろう、と"楽譜 s式 lisp".Googleしてみるテスト。
- 他にも何か書いたような気がするが、w3mが落ちた(近頃よく落ちる)せいで玉稿が消失。
- DNS引き辺りで待たされる(AirHでは頻出(笑))と、なんか落ちるような。詳細(gdbとかで)は追ってないですが。
- gcc3.2のせいかな？それともcygwin環境のUpdateに失敗したか？
- それはそれとして、w3mも、POSTが「成功してから」編集ファイルをrmしてくれりゃ良いのに。
- 忘れてたがvim3。set backupdir=hogehoge。でも効いてないような…？
- Shiro: Lispで音楽関係というと、
CCRMA が有名ですね。
楽譜作りのcmn、音作りのclm、あと作曲支援のCommonMusicとかあります。
あくまで言語指向、つまりマウスでうにゅうにゅやるんではなくて、
言語で「記述」してトップレベルでEvalさせる、ってとこがとってもLispy。
- どもです。そこの Planet CCRMA っていうソフト詰め合わせにビックリしました。市販Closedソフト"ばかり"が支配的である音楽畑の状況に対抗できるといいなぁ…
- デジタル的(Textや定型図による)記述という意味では、古典的MMLでも書けますね。ただMMLは行番号BASICと同様に記述力の限界が低いんで多くを期待出来ない。それで限界が高いLispだとどうなるのかなと思いまして。
030101
- なんか作ってみるテスト。 TikiGuion:六本松/言語案020911 の一番下から現物へLink。
- 今の段階で晒す意味はまるで無いけど、ダチに見せる気になったなら世間に見せろ、という家訓(違)により、無理やり晒す。
- GraphViz使用中。本来ならGraphViz無しでもそれに相当する情報を(しかもinteractiveに)見れる＆いじれる、とするのが野望なわけで、GraphViz使うのは寄り道なんだけど、まぁその…
021228
- Gauche:Gtkとメモリ管理を見て、逆にいえばこういう議論をすることで、隣人(他のGC Engine)に優しいGC Engineを作る秘訣、ってのが見つかったりするんだろうか。するといいなぁ。
- もし見つからないと、ライブラリを作る人は、みんなが同じGC Engineに集まるか、組み合わせても幸せになれないライブラリが増えてしまうか、どっちにせよ不幸な状況になっちゃう(というか今が不幸でありこれ以上幸せになれない)だろうな…
- …という話を何故該当頁に書かないかというと、"きちんと段落分けされた"頁を見ると、お邪魔虫(笑)を何処に書いて良いのだろう？と一瞬躊躇してしまったから(^^;
- プロセスの壁によせGCにせよ…うーんなんとかならんもんなのかこういうのって？(T_T)なんとかするのが今を生きる我々の仕事なんだろけど…
- 前言覆して冬甲子園でも見に行くかな。帰省日(=航空券の予約をやってくれる人からの連絡)が未定状態だけど。
- 未定だと何が一番面倒って、いつ洗濯をするのが良いかが判らないという点かな。
- vim3で021227をCtrl-A(カーソル位置の数字を++)したら、021230になっちゃったのでびっくり。Ctrl-X(--)は021226になるし、021226にC-Aでもきちんと021227になるんだが。余興機能だと思えばまぁいいか。
- octal?
- ん．それが証拠に 0x021229 -> 0x02122a．
021225
- Lisp/Scheme な人へ(もしかして嫌な)質問。
- 「関数」を書くたびに、その関数についての「コメント」を書くことは、Lisp/Schemeにおいてもなお、望ましいことなのでしょうか？
- もちろん、大物関数や難しい関数にはそれなりに欲しいですが、Lispの場合はやたらと小さな関数がたくさん作られるわけですよね？(^^;で、それらに対しても逐一コメント書いたら、ソースが、凄ーいことになるのではないかと思いまして…
→Lisp:コメント
021221
- XPとバザール方式。どっちもエラーの発見を自分以外の何かに任せる手法(が存在してそれを活用しているという点)が肝だ。
- で、どっちの手(あるいはそれ以外の手)でもいいから、なにかしらそういう手法を導入すべきだ。誰もが。ただちに。
- エラー発見を素朴に人力だけに頼るのは無茶だ。
- 俺が言うんだから間違いない(藁
- ま、エラーに限らず計算機畑の事柄ならば「なんでも」、まず「これは自動化(とか)できんべか？」と考えてみる、のが重要かと。
- Perl作者氏に手取り足取り教えて頂くまでもなく、技術者は怠惰で「ないとならん」だろう。自分の身を防御するため(笑)に。
- いちいち人力でやってたら、心身ともに磨り減っちまう。いつかは過労死とかするんだろうよ。3x歳で定年になったりもするんだろうよ。そんなの馬鹿馬鹿しい。
- 当然だが「ほげ自動化のパラドックス」は存在する(^^;
- それを乗り越えて、皆が出来る限り楽になるためには、これはもう情報の開示と共有と享受しかないわけで。
- より良いものを皆が互いに「知る」＆「わかる」＆「わからせる(笑)」チャンスが、もっと^5 多くなければならない。
- だから、万事もっとOpenにしようぜ、という話＞某
- ITという言葉は、もっとかっこいい言葉であるはずだ。
- つまり、「情報」を扱って、より楽になるための、技術だ。
- その中の(重要な)1カテゴリとして「自動化」があるのだと思う。
- そして更にその中の1カテゴリにProgrammingが。
- 「お客様は神様だ」なんて暢気な事を(客も業者も第三者も)言うから、バグが減らないのだと思う。
- とりあえず、神の名に値しない要求仕様(不完全だったり有矛盾だったり)を寄越すくせに神と名乗るのは、詐欺だ。
- 客との対話について、礼儀とかは正直いってどうでもいいと俺は思うが、問題なのは、礼儀と技術的問題とを「区別できない」人が多い、という点なんじゃないかな。
- そういうレベルの事柄は、小学校で学んできて欲しいもんだと思うのだが、義務教育の過程には入ってないのかな？
- 馬鹿に基準をあわせたら、出来るはずだったprogramが出来なくなった、というのでは本末転倒に過ぎるだろ。
- 以上、なんか今日(もう昨日か)は愉快(?)なことがあったらしい。
021218
- Omicron:SNOWに、S式「で」書くWiki、というネタが書かれているように見えるのは、俺の目の錯覚だろうか？(^^;
- 日本語で書かれた仕様書を1文字読み違える(あるいは書き違える(^^;)だけで、対応するプログラムではLoopの回し方を
がらっと替えないとならなくなったりする。卑近なところで「…で」と「…まで」の違いとか。これは辛い。
- Lispみたいにそういう問題を「吸収」しやすい言語を使う、という「防衛策」も現状では必要だろうが、なんか本質的じゃないな。
- ふと思ったんだが、日本語が論理的でないぞと騒ぐ奴がしばしば居るが、それは全然見当違いな話であって実は、「自分が知ってる、
論理記述に常用される言語」と日本語との、インピーダンスミスマッチがきつい、というだけのことなんじゃないだろうか？
- つまり書き方が違うぞというだけの話。
- というわけで、「で」と「まで」とを、日本語と同じノリで(^^;書き分けられるような計算機言語って、出来るんだろか？
- 上の自問(?)の答えとして、例えばLoopというものを抽象化しろ、という答えがあったような気がする。
- それは多分その通りなんだろうが、じゃあ「Loopじゃなく再帰」がその実現手段なのか？ってーと、それだけとは限らないような気が。
021214
- 巨大なfloppyを見て唖然。PCを"自分のメモ用紙として"使っても磔獄門にあうわけか？俺様はPCでメモを取 らないと死んでしまう(ぉ
- ところで、fjで叩かれようとも(藁)こういう場合は容量という語を使うのに抵抗を感じる。sizeofとstrlenを取り違えてるかのような違和感を覚える(ぉ)。
- つーか、いい年(=C言語年齢)こいて混同するな＞某。K&R(笑)に書いてあることを信じず(学ばず)に、そもそもどうやってCを書くというんだ？
- FrameWork逆噴射現象。いや待てよ。RubyはCとは事情が違いそう。Cは武器が無い((C)エクセルサーガ)から駄目なんだけど、RubyはPoorMan用じゃない(笑)イテレータもGCも動的構造もバリバリあり、ユーザに選択権が委ねられた上で、問題が発生するわけだから。
- Python勢が言うように、玉簾一筋に打ち込むことで芸を極めろということですかね。本当に置くの深い芸能を一生涯かけて体得するってゆー。
- 有野氏のアレは、やっぱり良すぎでしょう。曜日間違えという年中行事(違)をあそこまでサスペンスかつファンタジック雰囲気でごり押しできるからには、俺知人(?)の相原氏と同じくらいに物書き(それも小説とか)の素質アリかと。ちなむとその相原氏の現職が何かは正確には知りません(ぉ)。あと俺はその某を見ておりませんのでご安心を。
- あれは反響多くて書いた自分がびっくりです(^^;--有野
- やっぱり(人前で)書きたいので書くが、Hashedはやっぱり良かったとしみじみ思う。あーゆーサイト(Webならば)は年に一回見つかれば幸運。そして同じ幸せは自分や他人に今後も味わわせたいと思ってしまう…
- 仕組面でいえば、Hashedという仕組そのものも良かったし、あと突っ込み機能だよなあ(^^;;;;。ある意味で無名WikiName(自己矛盾語っぽいが)として機能してたというか。
- どこに書くべきか迷ったのでまずここで。案件依存Objectと非依存Object。FPとOOP(^^;。WorkFlow(シゴトの流れ)とWorkData(成果物)。スル奴とサレル奴。これら4つの関係はどれも似ていると思う。状況非依存に自分の都合だけで(何か言われたら受身に動くだけの)Objectがいて、それを色々小突き回す能動的な奴がいて。
- ある関数だかMethodだかを、前者と後者のどっちで実装するか？は、結構重要な問題だ。案件依存関数をObjectのMethodとして直接ぶらさげたら、いつしか数百件の案件(^^;でObject(のClass)はパンク状態になる。案件屋を100個作るべきだったのだ。
- ちなみにもっと重症なのが、受動なWorkDataの既存MethodをOverrideして案件依存Methodを作ってしまう愚。なにせ元々のMethodが使えなくなるのだから、そのDataは半身不随だ。案件をちょっと逸脱した操作(メンテナンスとか)すら立ち行かなくなる。
- ある物がある物に小突かれたからhogehogeという結果になる。能動者と受動者のコラボレーション(藁
- PostScript用語に"Polymorphic" Operatorってのが有ったような。多態「する」のは能動者なのか受動者なのか。まあ実際(=実装=微視的)には多態の要は受動者がしか持ち得ないのだが。
- なるほど。Lispではパラダイム"は"シフトしてないわけか＞Rubyのmatz氏
021211
- Lispが羨ましい。Rubyでもいい。この際Javaでも許す。比較対象がCだっていう時点で終わってるんだけど(藁)。その言語で「アプリ」を書かされるのが回避できるなら、こんな悩みは最初から無い…
- データの「並び」かたを楽々操作できるかどうか、が決定的に違うよね。
- 個人的経験からの印象に過ぎないが、業務(^^;アプリでは、例えばrubyでいうArray#flattenの逆演算みたいな処理が結構頻繁に出番が有る。
- 潰した配列を再び起こすためには、起こすための条件を指定する手段(を与える手段)が必要になる。
- つまり関数ポインタが必要。かつその関数に別の"ヒント"データを与えないとならないことも多かろう。
- おっとClosureの出番か？
- で、そうなると、関数もデータ構造(全部void*で押し通すのは御免なので)も実行時に作れないような言語は、マヂ辛い。
- かつ、関数はGlobal領域に作らないとならないく、インラインでちょちょいと関数を書くことも出来ないので、うざい。
- RTTIが無いので、配列を再帰的に積み上げたような構造では、何段目がLeafなのかの管理をいちいちコーディングしてあげないとならない。
- もちろん関数やデータ構造を「作る」こと自体は訳無く出来る。
- 問題は最近流行(笑)の"仕様変更"だ。
- 勿論本当の変更も有るが、ソフトを起こす際の当事者(間)の思慮不足で実装仕様を二転三転するハメになることも有る。
- この理由による仕様変更は、たぶん変更速度が最も速(くならざるを得な)い。なぜなら、出来たばかりのプログラムを客が初めて見た瞬間に変更要求が出るから(藁
- ビジネス(笑)をやっとる連中は自分らが扱うべきデータのカタチとかにきちんと頓着してない事がしばしば有るようなので(T_T)
- あ。べつにそれ以外の理由でもいいんだけどさ…
- Loopを回す順番とか、構造のネストの順番とか、を入れ替える必要に、頻繁に迫られる。
- そーゆーとき、そういう点の変更がめんどくさい言語だと、マヂ辛いのだ。
- つまり、ある悩ましい問題(^^;について、それをパターンやイディオムとして書けるけど、パターンやイディオムでしか書けない言語、はサゲということ。
- あと、業務アプリみたいなレイヤ(?)では、使用済みメモリ(リソース)管理は自動化…GC…に頼りたいもんだ。
- データの構造とかが結構ややこしい…
- というか、当初想像してたよりもややこしく仕様変更しちゃうこと(笑)が多いような…
- なので、参照係数のみの半熟GCだと、ちょっとアレだ
- そういう意味ではC++のBoost:share_ptr(だっけ)だけだと辛い、という話に。
- 単体アプリなら良いのだが、Frameworkの中だと自分で好きなメモリ管理手段を導入する自由が持てないことが。
- 導入したい管理仕組がFrameworkの管理ポリシーと衝突し、かつ肝心のFramework側の管理が貧弱だと(^^;、ほんと泣かされる。
- そしてLisp:GreenspunsTenthRuleの適用ケースになる… Shiro
- うひょ(^^;;;;
- 要するに、プログラムに必要な仕掛のうちどれだけ多くの部分を、言語(などのFramework側)の仕掛に任せられるか？って話ですね。
- 言語はFrameworkの一種ですよね…。ヤリタイことが言語仕様のせいで却ってやりにくくなることが(結構頻繁に)有り得るという意味で(^^;
- こんな事はどう考えたら良いのでしょう？ http://www.ksky.ne.jp/~sakae/sicp/base64.html (2002/12/13 00:09:26 PST)
- 戯: 例によって判ってないので山勘ですが、構造に対する柔軟性を不得手とするデータ型(RubyのString)に、「連結」という構造操作くささ(^^;の有る処理を頻繁(非局所的)にやらせちゃ駄目よって事でしょか。LispはList型が南京玉簾として機能してる感じっすかね。
- そういや俺もRubyのString型は別に大して羨ましくありません。そりゃCのよりは良いですが、Basicの(笑)とは大差無いわけで。
- 戯: FrameWork逆噴射現象(今考えた造語)とRubyのStringの関係については、どうなんでしょうね…ちょっと考えようっと。
- ruby界隈でも以前話がありましたが、DesignPatternをPatternじゃなくLibraryに閉じ込め可能な言語のほうが、たぶん嬉しいっす。
021201
- 18歳の時の興味っすか？作曲と絵かな。どれも我流だし下手だしですが。
- 音楽は印象派が好きだったな。絵は漫画もどき。
- 昔から今に至るまで「作る」ことが好きな様子。
- ジャンルが拡散しやすいなあ。
- 古い友人には「お前は逃げ道が多いのが問題だ」と言われたことが。
- おかげ(?)で大学ではサークルを選べなかった。サークル(特に音楽系)は大抵どこも「特定のジャンル」を愛好するんだよね。俺はその時々で興味があるジャンルを(自ら作曲するという方向性で)アクセスしたかったわけで…
- 計算機は、小学校のときに稚内青少年科学館(^^;のマイコン教室に通ったのを除けば(何故除くかというと、当時はProgrammingを全く「理解」してなかったから)、大学の学部に上がって初めて経験したので、18の頃は異世界でした。
- やってる友人が居たので、その隣で「じゃあHogehogeは出来るの？」ってな質問を繰り返していた記憶なら(笑)
- あとは楽器かな。といっても何がデキタわけでもないけど。
- ギター風形状のアナログシンセ(Interface)を作ろうかと思って買った角材(しかも24*8本の溝を掘った)が、先日の大掃除で発見されて目出度く廃棄処分になった(藁
- ギターをゴミ捨て場で拾ってきてフレット抜いた…のも18頃だったかなあ?
- 電子ピアノを買って(自力じゃないが)色々。でも生ピアノに触るチャンスがめっきり減ったのも丁度この頃か。
- 後に計算機を覚えて、楽器とリンクしていくことになる。それこそ MIDI? とか。
- 残滓(藁)の多くは今も俺サイトに転がってます。
- 18歳というよりも「18歳以降」が1つの単位だな。計算機がAddOnされたことを除けば、本質的に変わってないと思う。
021129
021030
- 非C的な関数呼び出しってものの「需要」は、世の中では、そんなに少ないものなんだろうか？
021027
- TikiGuionに「OOP/なんでもHash」というDQNなことを書いてみるテスト。
021026
- やりたいことは最後に出現する、の法則。
- やりたいことを実現(実装)するためには、そのことを実現するための道具としての何かを「先立って」実装しないとならないことが多いため、しばしばこうなる。
- 例：あるWikiPageを書きたいがために、それに関連する他のWikiPageを書いてしまう(藁
- Lazyな結合が許される状況では、道具を後から作るという手もあるのだが。
- でも後回しにしたら忘れちゃうし(^^;
- でも後回しにしなかったら、今度は肝心の本題のほうを忘れちゃう罠…
最終更新 : 2013/04/28 22:48:46 UTC