エラー発見を素朴に人力だけに頼るのは無茶だ。俺が言うんだから間違いない(藁ま、エラーに限らず計算機畑の事柄ならば「なんでも」、まず「これは自動化(とか)できんべか?」と考えてみる、のが重要かと。Perl作者氏に手取り足取り教えて頂くまでもなく、技術者は怠惰で「ないとならん」だろう。自分の身を防御するため(笑)に。いちいち人力でやってたら、心身ともに磨り減っちまう。いつかは過労死とかするんだろうよ。3x歳で定年になったりもするんだろうよ。そんなの馬鹿馬鹿しい。当然だが「ほげ自動化のパラドックス」は存在する(^^;それを乗り越えて、皆が出来る限り楽になるためには、これはもう情報の開示と共有と享受しかないわけで。多くなければならない。万事もっとOpenにしようぜ、という話>某ITという言葉は、もっとかっこいい言葉であるはずだ。「情報」を扱って、より楽になるための、技術だ。その中の(重要な)1カテゴリとして「自動化」があるのだと思う。その中の1カテゴリにProgrammingが。「お客様は神様だ」なんて暢気な事を(客も業者も第三者も)言うから、バグが減らないのだと思う。神の名に値しない要求仕様(不完全だったり有矛盾だったり)を寄越すくせに神と名乗るのは、詐欺だ。客との対話について、礼儀とかは正直いってどうでもいいと俺は思うが、問題なのは、礼儀と技術的問題とを「区別できない」人が多い、という点なんじゃないかな。いうレベルの事柄は、小学校で学んできて欲しいもんだと思うのだが、義務教育の過程には入ってないのかな?馬鹿に基準をあわせたら、出来るはずだったprogramが出来なくなった、というのでは本末転倒に過ぎるだろ。以上、なんか今日(もう昨日か)は愉快(?)なことがあったらしい。替えないとならなくなったりする。卑近なところで「...で」と「...まで」の違いとか。Lispみたいにそういう問題を「吸収」しやすい言語を使う、という「防衛策」も現状では必要だろうが、なんか本質的じゃないな。論理記述に常用される言語」と日本語との、インピーダンスミスマッチがきつい、というだけのことなんじゃないだろうか?つまり書き方が違うぞというだけの話。いうわけで、「で」と「まで」とを、日本語と同じノリで(^^;書き分けられるような計算機言語って、出来るんだろか?上の自問(?)の答えとして、例えばLoopというものを抽象化しろ、という答えがあったような気がする。それは多分その通りなんだろうが、じゃあ「Loopじゃなく再帰」がその実現手段なのか?ってーと、それだけとは限らないような気が。021214土曜(本来休み)だけど仕事(T_T)。巨大なfloppyを見て唖然。らないと死んでしまう(ぉところで、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という結果になる。Operatorってのが有ったような。多態「する」のは能動者なのか受動者なのか。まあ実際(=実装=微視的)には多態の要は受動者がしか持ち得ないのだが。Lispではパラダイム"は"シフトしてないわけか>Rubyのmatz氏021211Lispが羨ましい。この際Javaでも許す。比較対象がCだっていう時点で終わってるんだけど(藁)。その言語で「アプリ」を書かされるのが回避できるなら、こんな悩みは最初から無い...データの「並び」かたを楽々操作できるかどうか、が決定的に違うよね。個人的経験からの印象に過ぎないが、業務(^^;アプリでは、例えばrubyでいうArray#flattenの逆演算みたいな処理が結構頻繁に出番が有る。潰した配列を再び起こすためには、起こすための条件を指定する手段(を与える手段)が必要になる。その関数に別の"ヒント"データを与えないとならないことも多かろう。おっとClosureの出番か?で、そうなると、関数もデータ構造(全部void*で押し通すのは御免なので)も実行時に作れないような言語は、マヂ辛い。関数はGlobal領域に作らないとならないく、インラインでちょちょいと関数を書くことも出来ないので、うざい。RTTIが無いので、配列を再帰的に積み上げたような構造では、何段目がLeafなのかの管理をいちいちコーディングしてあげないとならない。関数やデータ構造を「作る」こと自体は訳無く出来る。問題は最近流行(笑)の"仕様変更"だ。本当の変更も有るが、ソフトを起こす際の当事者(間)の思慮不足で実装仕様を二転三転するハメになることも有る。この理由による仕様変更は、たぶん変更速度が最も速(くならざるを得な)い。出来たばかりのプログラムを客が初めて見た瞬間に変更要求が出るから(藁ビジネス(笑)をやっとる連中は自分らが扱うべきデータのカタチとかにきちんと頓着してない事がしばしば有るようなので(T_T)あ。べつにそれ以外の理由でもいいんだけどさ...Loopを回す順番とか、構造のネストの順番とか、を入れ替える必要に、頻繁に迫られる。ゆーとき、そういう点の変更がめんどくさい言語だと、マヂ辛いのだ。ある悩ましい問題(^^;について、それをパターンやイディオムとして書けるけど、パターンやイディオムでしか書けない言語、はサゲということ。あと、業務アプリみたいなレイヤ(?)では、使用済みメモリ(リソース)管理は自動化...GC...に頼りたいもんだ。データの構造とかが結構ややこしい...というか、当初想像してたよりもややこしく仕様変更しちゃうこと(笑)が多いような...なので、参照係数のみの半熟GCだと、ちょっとアレだそういう意味ではC++のBoost:share_ptr(だっけ)だけだと辛い、という話に。単体アプリなら良いのだが、Frameworkの中だと自分で好きなメモリ管理手段を導入する自由が持てないことが。導入したい管理仕組がFrameworkの管理ポリシーと衝突し、かつ肝心のFramework側の管理が貧弱だと(^^;、ほんと泣かされる。Shiroうひょ(^^;;;;要するに、プログラムに必要な仕掛のうちどれだけ多くの部分を、言語(などのFramework側)の仕掛に任せられるか?って話ですね。言語はFrameworkの一種ですよね...。例によって判ってないので山勘ですが、構造に対する柔軟性を不得手とするデータ型(RubyのString)に、「連結」という構造操作くささ(^^;の有る処理を頻繁(非局所的)にやらせちゃ駄目よって事でしょか。LispはList型が南京玉簾として機能してる感じっすかね。いや俺もRubyのString型は別に大して羨ましくありません。そりゃCのよりは良いですが、Basicの(笑)とは大差無いわけで。FrameWork逆噴射現象(今考えた造語)とRubyのStringの関係については、どうなんでしょうね...ちょっと考えようっと。ruby界隈でも以前話がありましたが、DesignPatternをPatternじゃなくLibraryに閉じ込め可能な言語のほうが、たぶん嬉しいっす。02120118歳の時の興味っすか?作曲と絵かな。どれも我流だし下手だしですが。音楽は印象派が好きだったな。昔から今に至るまで「作る」ことが好きな様子。ジャンルが拡散しやすいなあ。古い友人には「お前は逃げ道が多いのが問題だ」と言われたことが。おかげ(?)で大学ではサークルを選べなかった。サークル(特に音楽系)は大抵どこも「特定のジャンル」を愛好するんだよね。俺はその時々で興味があるジャンルを(自ら作曲するという方向性で)アクセスしたかったわけで...計算機は、小学校のときに稚内青少年科学館(^^;のマイコン教室に通ったのを除けば(何故除くかというと、当時はProgrammingを全く「理解」してなかったから)、大学の学部に上がって初めて経験したので、18の頃は異世界でした。やってる友人が居たので、その隣で「じゃあHogehogeは出来るの?」ってな質問を繰り返していた記憶なら(笑)あとは楽器かな。いっても何がデキタわけでもないけど。ギター風形状のアナログシンセ(Interface)を作ろうかと思って買った角材(しかも24*8本の溝を掘った)が、先日の大掃除で発見されて目出度く廃棄処分になった(藁ギターをゴミ捨て場で拾ってきてフレット抜いた...のも18頃だったかなあ?電子ピアノを買って(自力じゃないが)色々。生ピアノに触るチャンスがめっきり減ったのも丁度この頃か。後に計算機を覚えて、楽器とリンクしていくことになる。残滓(藁)の多くは今も俺サイトに転がってます。18歳というよりも「18歳以降」が1つの単位だな。計算機がAddOnされたことを除けば、本質的に変わってないと思う。