#つうか、お客さんにとってはその機能が「プログラムによって実現されているか」どうかさえ本質的には関係ないんだよな。実はネットワークの向こう側では人間が処理してた、というのであっても、所定のコストで機能と性能が満たされてればいいわけで。
#単に「品質が上がるので××言語を使います」というのは空虚なステートメント。所与の具体的な条件を満たすには我々が××言語を使うことが最適だ、という判断が案件ごとにあってしかるべき。
#同意
#自分の陥った経験なんですが、手段が目的化されて、ほげ言語がどうだとかエディタがどうだとか言ってる時って大体は形になってませんよね。冷静に考えると真相は実に単純で、実現したい事があって"たまたま"計算機（or その言語だったり）を使う、じゃないでしょうか。計算機は道具。自分がもしプログラムとか書いてないお客さんだったら、はっきり言って何を使ってどう作られたかなんてどうでもいい。家買うのにいちいちトンカチまで勘定に入れませんよ。そして適切にお金払ってる以上、目的において"品質が良い"なんてのは当たり前の事でしょう。
#プログラマ同士で話してるときに、言語がどうのエディタがどうのってダベるのはいいと思うんですよ。ミュージシャン同士だって自分の楽器のこだわりどころについて語るでしょう。それが内輪での話だって分かってればいい。
#でもステージでお客に楽器の薀蓄を語り始めるミュージシャンはいない、ってことですよね。
#お客さんは自分じゃ実現出来ない（or やりたくない）から"商品"という抽象（ブラックボックス）を選択するわけですからね。もしトミーエマニュエルが楽器の薀蓄を語り始めたら「そんなこといいから早く弾いてくれよ...」とか思っちゃいそう。気になるとしたら、なんでギターの表面剥げてんの？くらいですよ。
#そこいら辺は、プログラマの側に自分が作っているのが「商品」あるいは「ソリューション」だという認識が薄かったりするせいかな、と思ったり。
#どことなく「芸術品」を作ってると勘違いしているきらいがある。
#品質に対する気概としてなら別にいいんですが、そこで自分のこだわりをお客に押しつけるようになるとちょっと違うな、と
#まぁ、過去の自分を振り返ると鼻白むようなこともあるんですが(笑)
#でも、まぁ薀蓄をかたったり、押し付けるラーメン屋さんなら存在します。そういうマーケティングなんでしょうけど。
#いますね。ラーメン屋に限らず、ですが。お客を萎縮させてどうするんだろう、と思うんだけど、お客の側も喜んじゃったりするから不思議ですね。
#ああ、まあ、そういうひとつの体験を売るっていうニッチはあるかもしれない。
#コンサルタントは成果物を収めて客に使わせるわけじゃないから偏屈ラーメン屋商法が使えるかも知れない。いや、ラーメンを客に作らせる商法か。
#おそらく投影の一種だと思います。＞売り物としての蘊蓄。「ああグールドみたいにピアノが弾けたらどんなに気持ち良いことか...」
#うる側と顧客がある種の文化を共有している場合には、そういう方法は通るんだと思います。
#ソフトウェアだとUNIX
#とかは、そんな感じはあるんじゃないかと。
#そうか！ 目指せ偏屈コンサルタント。
#ああでもなあ、ラーメン屋はまずくても客の損失はたかが知れてるけど、コンサルタントはまずいと客の経営が傾く。
#そういえば、廃業コンサルタントって存在するんですかね。ニーズはありそうな気がするけど。ダークサイドの仕事になっちゃうか。
#それはさておき、現実のコンサルタントでも、極論を提示して客にインパクトを与えてそれ以降の主導権を握るみたいな手法を使ってる輩はけっこういそうな気がする。一種の偏屈戦略ですよね。
#なぜか、ねずみ講と新興宗教の商法が頭をよぎった。
#それで成功率が高ければ誰も文句言わないんじゃないかな。
#まさにそれです >ayato
#不合理の上では成り立ちますけど...0to1から演繹される合理の上では結局いつか
#ha
#インパクトのある極論：
#「開発言語をLispにします。全員Franzのセミナーを受けてください」
#え、それって極論?
#単なる正論じゃないかと
#(び)さんはこっち側の人だから…
#ああなるほど
#いやでも、前段がすでに決定事項なら、後段は正論ですよね。
#前段が決定事項なのが極論なのか...
#マズい。素でわからなかったぞ...
#普く陰陽
#を見なくなって僕らは信じるしか無いのだ。
#ところでAllegroGraphってどんな感じなんだろう。誰か使ったことある人居ないかな。
#何が聞きたいですか?
#RDBとおさらばしたくて、GaucheつかってMySQLの上にトリプルのストアを書いてるんで興味があるんです。RDBの代わりになるかな？と。自分の頭の中では代わりになるんですが。実際にやった人は居るかなと。
#「代わりに」というのが機能的な話ならもちろん可能なわけですが、現実のアプリでどうかってことですよね。クエリのパターンによるでしょうねぇ。
#私が言えるのは、insertと単一キーでのquery (range query含む) はすさまじく速いってことで、リアルタイムでばんばんinsertとquery乱れ撃ちするようなアプリは強いみたいです。
#複雑なjoinが必要になった場合にどこまで賢いqueryが走るかって点に関してはよくわかりません。
#Gauche on Railsはどうだったんだろう?>OR mapping
#(よくわからないってのは、比較したことがないから文字通りわからないってことです。)
#なるほど>shiroさん。やっぱり自分で形にしてみないと何とも言えませんね。質問が抽象的すぎた（笑。
#@athos0220: svn trunkでは定数伝搬が強化されてて、(if #t (begin) (foo)) は条件が#tであることがコンパイル時にわかってるので(begin)と同じになります。 http://twitter.com/athos0220/status/17239165393 #もう少し踏み込んだ最適化もやっていて、例えば(define-constant *x* '(1)) としていれば(if (pair? *x*) then else) は条件判断がコンパイル時に計算されて then のみになります。
#@dico_leque: svn trunkでは関数呼び出し時に引数の数がval0レジスタに入るようになってるんで、そのせいかと。http://twitter.com/dico_leque/status/17240314412 #これは、optional/keyword引数をリストにパックせずにcallee側で処理するための布石です。
#ほぉ、なるほど。ありがとうございます。ちなみに、(define (a) (if #t (begin))) として、(a) で a 自身が返ってきていた理由って何なんでしょうか？
#@athos0220: defineは評価後に定義されたシンボルをval0に残すので、それがそのまま引き継がれたんじゃないかと思います。
#上の品質云々の話を見ていてふと思ったのですが、メカニカルなものって、仕組みを詳しく知らなくても、見ていてなんとなく「かっこいい」と思うことがあるじゃないですか。
#あんな感じで、あまり詳しくない人が見ても「かっこいい」と思うプログラムってあるんでしょうか?
#物理的実体がないと厳しいのかな。
#difference engine で動くプログラムだと、歯車の動きから「プログラムのかっこよさ」が分かったりして。
#Form follows functionみたいな? 何らかの方法でプログラムの構造 (静的or動的) がうまく可視化できるなら、良いプログラムはかっこよく見えるってことはあり得るかも。
#ソースコードというのはプログラムの本質的な構造からはちょっと離れてる感じなので (本質的ってなんだ、っていうとよくわからないけど)、ソースを見てどうの、ってのは厳しいでしょうね。
#うーん、それはちょっと悲しいなぁ。
#マンデルブロ集合のかっこよさと美しさに抱く思いと同じメタファ。
#機械みたいに機能を追求した先に機能美が生まれてくるといいな、と思ったり。
#ソースコードが、プログラムを表現する手段として最適ではない、という可能性もある?
#むー、たとえば楽譜は、読めなくてもパッと見の印象ってのは色々ある。けれども、たとえば脚本は、見た目はどれもほとんど同じ。
#とすると必ずしも記述法の最適解において見た目に構造が滲み出るとは限らないのかな。
#ソースコードって脚本よりも楽譜に近いんじゃないかな、とよく知らず思ったり。ソースコードでも構造はにじみ出ているんじゃないかな。
#マンデルブロ集合の美しさだとすると、機能美とはまた別の美しさになりますね。
#LispやPythonだと見た目綺麗なソースってのはありますね。
#そうですね。COBOLとかだと自然言語に近すぎるので、あんまり目立たなくなるのかな。
#独立時計師が作る機械式時計とか。
#だとするとAPLが一番美しい言語になったり。
#数行以上のAPLコードを見たことがないから判断できない
#あーでも、楽譜の美しさっていうのは、「美しい楽譜にする表記法」みたいなものが連綿と研究されてきたっていうのもあると思うな。もちろん見やすさの追求ってのもあったろうから、その意味ではform follows functionなんだろうけど。
#300行以上あるAPLのコード見つけたけど、フォントがなくてよく分からん。(あってもよくわからないけど)
#ということは、見やすさを追求したソースの表記法というのが発展してもいいわけか。Fortressの試みなんかはその1ステップと考えることも出来なくはないかな。
#そう、最初に機械式時計を思ったのですが、「機能と性能」っていってしまうと機械式時計ってクォーツに比べていいとこないと思うんですよね。
#高いし、壊れやすいし。でも、機械式時計って、なんか使っていて楽しい、見ていて楽しい、といった側面があるのです。
#そんな感じで、一応機能は満たした上で、何となく見ていて楽しい、といったプログラムってないのかなって思いました。
#確かにそうだなあ。以前から「道具としてのソフトウェア」と「作品としてのソフトウェア」について考えてることはある。
#arcのソースなんかは見ていてそう思う。全体的に美しいというかなんというか。
#その美しさって、プログラマ以外でも共有できないかなって思います。
#自分がプログラムに対して無知だと仮定して、arcとperl見たらarcを選ぶと思います。多分。
#Smalltalkな人たちってそういう感覚持ってそうな印象が。「ソース」じゃないんだけど。プログラムの部品をわりとフィジカルなイメージでとらえられるような仕組みを作ってるかのような。
#「フィジカル」というのとはちょっと違いますが、多分 Lisp も同じ感覚は持っているんじゃないかな。
#Emacs Lispとかは「テキスト版Smalltalk」という感じがする。汚いけど。
#SqueakとかEtoysのイメージが強いからかなあ。わりとあっちはヴィジュアルなインタラクションに強い気がするけど、Lisperは抽象的なシンボル操作に走ってしまうような印象が
#うーん、SmalltalkってGUIを最初から装備しているので、そう見えるんじゃないでしょうか。GUIフレームワーク込みのLispだと同じような感覚で使えるような気がする。
#.FPGAでLispマシン作るようなもの? http://bit.ly/9lQq0k 組み込み向け「軽量Ruby」と「Rubyチップ」、福岡県が経産省の事業で開発へ - ニュース：ITpro #スタックマシンなんだろうか？
#Javaチップの失敗を繰り返しそうな気がするんですが。大丈夫なのでしょうか？
#ゴールをどこに設定するかによるんじゃないでしょうか。本気で量産して汎用のコントローラチップと競うのは非常にきついと思うけれど、たとえば特有の言語のVM記述からさくっとチップが起こせるような話が確立されたらニッチで需要があったりしない?
#んー、でもRubyならわざわざ専用チップにしないでも普通の汎用アーキテクチャ上に素直にコンパイルすればいいって話になるか。普通のアーキテクチャにうまく乗らない実行モデルを持ってる言語の方が、チップを起こす動機としては良さそうだよね。
#組み込み系はあまりよく知らないけど、MIPSなりARMなりの既存のCPU上でVM動かした方が、作るのは楽だし、性能や消費電力も改善されていくので、自前で作るのは大変じゃないのかな。というか体力が続かないと思う。
#はい、量産してる汎用チップともろに競合するのはまず勝ち目が無いと思います。
#Rubyの役目は流行を作ることなので、これを機にCPU実験キットが一般に安く手に入るようになることに期待。
#なんとなく「家電製品などの開発生産性云々」というところで競合しちゃいそうな気がする。
#.私もARMでいいじゃん、と思います。Javaも動くし。
#CPU実験キットというか、FPGAのキットなら今でも手に入れやすいですよ。
#でもちょっと高いか。
##RAMがほとんど無いのでインタプリタとか載せるのは多分無理だけど。
#16bitCPUなんだ。
#あ、でもLispマシンみたいにハードウェアでGCのサポートとかあると、動的言語で素早くイテレーションを回したいってニッチにははまるかも? ロボットのコントローラとか。
#ルンバとかどうなってるんだろう。
#うーん、ハードウェアGCって、コプロセッサみたいに既存のCPUに専用ハードを追加する形で、作れないのかしらん。
#リードバリアとかライトバリアをハードでサポートしてもらうにはバスを監視して割り込みをかける必要があるんで、キャッシュの内側を覗けた方が嬉しいんじゃない?
#あー、確かにキャッシュがあると面倒ですね。
#Roombaは汎用CPUでしょう。特にリアルタイム性が要求されるわけでもなさそうだし。
#Roombaの場合、たまにGCで固まった方が「考えてる」って感じがしていいかも。
#部屋のマッピングをやってるわけじゃないので、GCで固まるほどメモリ使ってないとは思いますが。不完全な方が愛着が湧くというのはあるかもしれない。
#単に方法を知らないだけです RT: @ikegami__: shiro さんの宣戦布告? :「Haskellでどうやって性能を出したらいいのかわからない」via http://bit.ly/93TotQ #お客さんにとって新しい言語を導入することは、お客さんが持っている既存の環境に、その言語の処理系を入れることになるから（ネイティブコードにコンパイルする場合は別ですが）、そのコストも馬鹿にならないですよね。
#たとえば、.NET Framework 3.5 が必要とかいわれたら、めんどくさい。
#http://amasci.com/amateur/holo1.html この手書きホログラム、立方体みたいな連続的な奥行きの変化があるようなものはどうやって書いてるんでしょうかね。CD-ROM の表面にエッチングみたいな感じでラベルをプリントするプリンタありますけど、あれでかけないかな？ #クラウド最強ってことか。
#>とおる。 奥行き方向はコンパスの開きを変えると変化します。なので半径が自由に変えられないとプリントは難しそう。
#@eyasuyuki: クラウドはデータを外に預けないとならないのがネック (単なるストレージなら暗号化しとけるけど、外で計算させるなら基本的に生じゃないとだめ)。ただ、暗号化したまま計算するって技術もある。まだごく基本的なことしかできないけど。そんでもって計算量は跳ね上がる。ほら、やっぱり性能は重要だ。
#あ、基本的なことしかできないってのは勘違いだった。暗号化したまま(理論的には)任意の計算ができる方法ってのが見つかったんだった。 http://blogs.teamb.com/craigstuntz/2010/03/18/38566/ #理論的には、っていうのは性能の話を抜きにしてってこと。
#ええ、コンパスの開きが奥行きに対応しているのは分かるんですが、それを手で正確にやってるのがすごいなぁと思って。少し開いて、針を少しずらして、弧を描いて、また少し開いて、っていうのを繰り返すわけですよね。
#ああ、手でやってるのはすごいですね。幅が固定できるコンパスを使えとは書いてあるので、同一深度の部分はまとめてやっちゃうんでしょうけれど。奥行き方向にも直線にするのは技術が要りそうだなあ。
Gauche > Archives > 2010/06/28