«前の日記(2007-09-07) 最新 次の日記(2007-09-09)» 編集

Matzにっき


2007-09-08 [長年日記]

_ [教会] ステーク大会

新見へ。連日の疲れで眠たくなったので 途中、一度休憩した。

特に遅刻することもなく、無事到着。

_ [言語] システム開発生産性が最も高い言語:ITpro

その名はExcel、という話。

が、表計算がうまくはまるような局面では その分野に特化した「言語」の方が生産性的に有利であるのは 間違いないことだから、そのこと自体はさほど驚くことではない。

問題は

  • Excelは「安定」しているのか。 つまり、バージョンの変化によってどれくらい影響を受けるか。
  • Excelは本当に「最も生産性が高い」のか。 つまり、別の言語で同じ生産性を実現する余地があるのかないのか。

であろう。特に後者に関心がある。

Excelが(特定分野で)生産性が高いのであれば、 適切なクラスライブラリを提供することで Ruby(あるいは別の言語)も同等の生産性を提供できるのかどうか。 もしそうであれば、その「適切なクラスライブラリ」とはどのようなものか。

あるいは、Excelは「言語」として特異であって、 汎用の言語に機能を追加したくらいでは、その生産性を実現することは 困難なのか。

_ [言語] 新言語 Xtalを作る日記 - PseudoArray

Xtalにおいて、selectなどがPseudoArrayなるArrayのように振る舞うオブジェクト(その実態はイテレータの上に構築された擬似配列)を返すようになったという話。

Rubyでも同種のことがやりたい(から、LL魂のスライドでもそう書いた)のだが、 なかなか実現できないでいるところを、あっさり実装してしまう このスピード感が素晴らしい。

ちゅーか、なにか、年取って開発のスピードが落ちたということか。 そうか、そうなのかっ!?

_ [Ruby] 「Ruby 1.9は1.8より平均5倍速い」、YARV笹田氏 − @IT

昨日のイベントで裏番組だった未踏発表会のレポート。 5倍とか書いちゃってるよ。 嘘ではない、嘘ではないんだけど。

これがどう出るかは、未知数である。

確かに(マイクロ)ベンチマークを行えば平均5倍速くなるので、 「これは素晴らしい技術だ」と思ってもらえるのか(その場合の賞賛は、ささだくんに行くべき)、 あるいは、実際にアプリを動かしても、実際の速度差は アプリの構成(特にアルゴリズムの選択)やライブラリ実装に依存する以上、 体感5倍は出ないわけだから、「なんだ、言うほど変わらないじゃないか」と 思われちゃうのか。

なんとなく、世の中の流れ的には前者の方が多いような気がするんだけど。

_ News from the Front

ポール・グレアム最新エッセイ。 出身大学と成功には全然関係がない、という話。

裏を返せば、このようなエッセイが書かれるくらい、 アメリカでも出身学校による先入観ってあるんだね、やっぱり。 もちろん日本でも顕著なんだけど。

本日のツッコミ(全20件) [ツッコミを入れる]
_ kwatch (2007-09-18 07:57)

> 特に後者に関心がある<br>Excelは表計算ソフトですが、フォーム作成ソフトとしてもよく使われます。<br>HTMLでいうところの<input>や<select>ですね。<br>経理部にいるExcelに詳しい人が、申請書やアンケートを作成するのによく使ってます。<br>Excelファイルをメールに添付して送付し、記入されたものを送り返してもらって集計します。<br>またグラフ機能も標準でついており、他のアプリのfront endとしても使われます。<br>(VisualBasicやWebアプリだとグラフ機能が弱い。)<br>逆にいえばフォーム以外のことにはそんなに向いていません。<br><br>> 適切なクラスライブラリを提供することで Ruby(あるいは別の言語)も同等の生産性を提供できるのかどうか。<br>Tkより格好よくて使いやすいマルチプラットフォームのGUIライブラリとGUIビルダーがつけば<br>対抗できるかもしれませんが、現実にはHTML+JavaScriptがいちばんの対抗策だと思います。<br>またExcelに対抗することを考える前に、RubyのWindowsサポートを手厚くするのが先かと。

_ Jadawin (2007-09-18 16:59)

ExcelとRubyの違いはその能力ではなくて、UIでしょう。<br>それがExcelのユーザに「できる」を「簡単にできる」<br>に変えているのだと思われます。<br><br>個人的にはHyperCardのHyperTalkをRubyに置き換えた<br>処理系があればと大昔から夢想しているのですが。

_ eklerni (2007-09-18 18:03)

> Excelは本当に「最も生産性が高い」のか<br><br>ここで言うExcelの「生産性」とは、<br>Excel(のパラダイム)がデータフロープログラミング言語<br>であることに起因するのではないかと思います。<br><br>表計算やフォーム作成など、<br>データフローとよくマッチする分野ではExcelが優位になるということです。<br><br>もちろんRubyは汎用言語ですから、<br>データフロープログラミングをすることは可能ですが、<br>それを念頭において設計された言語よりももどかしい思いをすることが多いんじゃないでしょうか。<br><br>ですから、「適切なクラスライブラリ」とはその間を埋めるようなものになるかと。

_ ゆーぼー (2007-09-19 00:02)

Excelはとてつもなく強力な言語だと感じています。<br>会社内で、データの処理をしようとすると、まず思いつくのがExcelVBAです。<br>理由を箇条書きにしてみます。<br> WorkSheetはデータベースのテーブルそのものである。<br>  変数の代わりに、処理結果を別のシートに書き出すと、処理の流れが手に取るように解る<br> 記録マクロがある<br>  あまり理解していない処理をさせる場合も、記録マクロを実行すれば、コードが自動的にジェネレートされる<br> GUIのフォームが簡単にできる<br>  GUI上で部品を並べて、自動生成されたスクリプトの間に必要な処理を書き込むだけ<br> IDEがとても良くできている<br>といったところでしょうか。<br>でも、やっぱりRubyで処理したいという欲望から、ActiveRecordライクなActiveArrayなるクラスを作成してはいるのですが、私の実力不足か、ちょっと荷が重い感じです。<br>Excelライクなクラスとして、関数を始め、列や行のの挿入削除、フィルターやピボットテーブルを簡単に、自由に扱えるものかあればな〜、と感じています。<br>=>そんなの、お前が作れ<br>と言われそうなので、少しずつ実装をしてはいるのですが、終わりが見えません…orz

_ おがわ (2007-09-19 03:00)

一般的な会社内という環境でExcelもしくはOffice VBAを語るとすれば、<br>それはもはやEmacsのような環境であると言うことかと思います。多かれ<br>少なかれたいていのWindowsの端末にMS Officeがインストールされて<br>いることを暗黙の仮定にたてて良い場合が非常に多いからです。<br>ここはなかなか侮れません。<br><br>バージョンの安定度ですが、現状ではまだOffice2000を使用している所は<br>多いと思います。バージョンがMSさんの思惑から外れてなかなか変わらな<br>いので、逆に安定しているとは思います。Excel97時代に作成した10年ほど<br>使用しているマクロがほぼそのまま動かせている(現在はExcel2003)ため、<br>VBAの仕様もあまり変わっていない感覚です。<br><br>慣れ親しんだUIに組み込みやすいのもありますが、定型の出力もVBAに直書き<br>だと美しくないですが、いろいろRangeオブジェクトを使っていくと、スマー<br>トに書式を整えられる→即提出物にしやすいと言うのはあります。<br><br>あとWindowsのCOMオブジェクトだったら何でも呼び出せるというのは大きい<br>と思います。Excelのセルに入りきれなかったらADO経由でAccessをバックで<br>使えばいいし、正規表現が欲しくなったら正規表現オブジェクトを呼び出せば<br>いいですし、文字コードの変換もMSの流儀ですができますし・・・<br>格好いいグラフが欲しければ、RをインストールしてRに書かせればいいですし<br>ということで、何でもありと言うところがやりやすい所かと思います。<br><br>ということで、なんでもかんでもExcelという風潮に対抗すべく、日夜がんばって<br>いるのですが、セルを変数代わりに使うマクロを見ると、やっぱりExcelを<br>好きにはなれません・・・

_ ささだ (2007-09-19 04:04)

今年の夏のプロシンで萩谷先生がこんな発表をやってました。<br>> Excelでプログラムを書く 萩谷昌己(東大)<br><br>(この話のスコープとずれてるけど)

_ ardbeg1958 (2007-09-19 11:27)

Excel の生産性の高さはドメイン記述力の高さに起因していると思います。事務処理は要するに帳簿の操作に過ぎませんから。要求を書き表しやすく、そのまま実装しやすい。要求を出す側と作る側の意思の疎通が行いやすいので、(うまく制御できれば)急速に仕様が収束します。<br>そして「帳簿」のようなドメインモデルに直接マップされるUIの存在も利用しやすい要因の一つですね。<br>まとめると、「成熟したドメインモデル」+「そのドメインモデルを透過的/自然に操作/表現できるUI」のコンボが「生産性」の高さを担保しています。<br>前者はクラスライブラリで何とかなりそうですが、後者をどうするかは課題ですね。そもそもドメインモデルの一部が言語記述ではなくUIの一部に現れているのですからヌエ的とも言えます(笑)。<br>それに、他の方も書かれていましたが、とりあえずどのマシンにも(Windows PC であれば)インストールされているというのが、大きなアドバンテージでしょう。

_ ardbeg1958 (2007-09-19 11:34)

とはいえ元記事にもありますが、「作りやすい言語の害」というものも考えなければなりません。エクセルレガシーという言葉もあるように、思いのままに作り散らかされたプログラムがそこここに散在していて、保守できないという状況は正に悪夢です。<br>保守できない理由は様々ですが、第一に「記述」の各要素の関連が追いにくいということですよね。Excel で書かれた様々な記述の相互関連を Excel の上で追っていく作業は、あとからやらさfれることを考えるとぞっとします。<br>ある記述は表に隠れ、ある記述はVBAにあり、それらが大域変数であるセルを介して自由に結合しているのですから。。。

_ 元職業プログラマ (2007-09-21 00:57)

>会社内で、データの処理をしようとすると、まず思いつくのがExcelVBAです。<br>VBAでデータ処理が間に合う会社が羨ましいです。<br>これは冗談ですが、私はRubyとgccを使って、どうにかこうにか仕事を間に合わせています。<br>また、さらに仕事を間に合わせるために、簡易で特殊な言語を作ったりしていますが、それでも物足りないので、Haskellを勉強しているところです。

_ ゆーぼー (2007-09-22 00:18)

> Excelはとてつもなく強力な言語だと感じています。<br><br>の出だし一行で集中砲火を受けてしまったようです。<br>でも、二次元配列を操作するのに、Excelワークシート関数は、とても便利ですよね。<br>例えば、RubyにVirtualExcelなんてクラスが存在し、ワークシート関数に相当する<br>メソッドが具備されていたら、魅力的だと感じませんでしょうか?<br>社内(当社)でデータを加工するとなると、やっぱりExcelです。<br>VBAは処理が遅いのが難点ですが、ルーチンワークには向いています。<br>前記のVirtualExcelでサクサク処理して、結果をTmailで関係者に自動配信なんて<br>スマートじゃないですか。<br>それと、当社の事情なのですが、社内のPCには、許可した以外のアプリケーション<br>をインストールすることが禁じられました。(規定があります)<br>コンプライアンスによる押しつけ統制は益々厳しくなるばかりです。<br>各個人のPCの中には、インストールされたアプリケーションを中央サーバにチクる<br>やつが居て、昨日はATOKをアンインストールしろとの指示が届きました。<br>泣く泣くATOKを外したのですが、拒否すると、懲戒処分に処せられます。<br>RubyやMySQLも、いずれか外せと言って来ると思います。<br>そこで「Rubyを使えば、Excel処理よりこんなに効率的なんですよ」と<br>言えれば説得力充分だと思って孤軍奮闘しています。<br>なによりも、Rubyの裾野が広がれば嬉しいです。

_ 元職業プログラマ (2007-09-22 09:26)

ゆーぼーさんの会社の事情は分かりました。<br>私の会社も、全体的にこの方向に向かっているのは間違いないので、そうなった時にどうやって仕事を間に合わせるのかという事については、考えておかなければならないと思いました。<br>>例えば、RubyにVirtualExcelなんてクラスが存在し、ワークシート関数に相当する <br>>メソッドが具備されていたら、魅力的だと感じませんでしょうか? <br>の件については、<br>http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/ruby-win32ole/excel-1.html<br>をご参考にして自力で作成され、<br>http://raa.ruby-lang.org/<br>に登録するというのはいかがでしょうか。<br>そうすれば、多くの方が、VBAによる処理の遅さや複雑化を補完するのも簡単になると思います。<br>因みに、私はごく一部の処理で、Rubyを使わず、C言語でCOMクライアントプログラムを作成し、OLEインタフェースを直接呼び出して処理の高速化を計っています。<br>このプログラムを作成出来たのは、Windows版Rubyのwin32ole.cがあったからに他なりません。<br>http://homepage1.nifty.com/markey/ruby/win32ole/index.html

_ 田辺 (2007-09-22 09:36)

Excel の圧倒的な生産性は、UI にあります。<br>一回のドラッグで無数のデータや計算式を作り出せるのですから、<br>これはライブラリを作ったところで、追いつけません。<br><br>言語 と Excel で争うのは、文字で書くのが早いか、<br>絵で描くのが早いか、そんな差異があると思います。<br>前者は、"1から100までの数列を出力" と書く動作となり、<br>後者は、1 から、ビーと引っぱる動作となります。<br>生産性を言語単体で見るのではなく、<br>UI環境も含めて考えるのがよさそうですね。<br>(こう書いてて、Smalltalk のことを思いました)

_ 元職業プログラマ (2007-09-22 10:28)

Haskellだと、"1から100までの数列を出力" は、[1..100]となるのですが、どうなのでしょうか?<br>それと、CUIだとヒストリ機能を使えますよね。<br>私は、仕事を間に合わせる為に、Bashのスクリプトを使って、bashのヒストリ機能を補強しています。

_ 田辺 (2007-09-22 23:01)

強調したかった点は、文字を書くか、絵を描くか、という感覚の相違です。<br>一般的に、表データを扱う際には、CUIのテキストエディタのようなものでなく<br>Excel のような UI がより適していると思います。

_ 元職業プログラマ (2007-09-22 23:31)

田辺さん<br>>一般的に、表データを扱う際には、CUIのテキストエディタのようなものでなく<br>データ量も少なく、大したデータ加工も必要なければ仰るとおりだと思いますが、データ量が多く、高度なデータ加工が必要な場合は、仕事を間に合わせるために、Excelのだけではなく、RubyやVim等のテキストベースのツールを使う必要があると思っています。

_ おがわ (2007-09-23 02:19)

元職業プログラマさん、自分の使いたいツールをインストールできる職場がうらやましいです。もうそんな幻想は自分の世界ではもてなくなりました。<br>僕は職業プログラマではないので、別なツールでデータ処理を行わせるために加工するくらいにしか会社でプログラム書きませんが、上記に書いた理由でVBAに依存しています。<br>Rubyとかで行っているテキスト処理だったら、かなり記法は冗長ですがVBAでも同じようなことはできますし、RDB的な処理をやりたくなったら、Accessなどにデータを投げればいいだけの話ですから、全部テキストベースでやる必要があるのかどうか・・・ あとVBAでデータ構造で無くて困るのはせいぜい困るのはハッシュくらい?です。(僕は処理している途中のデータをいっさいワークシートに置かないので、この辺だけ困る。組み込まれたもしくは定義可能なデータ構造が貧弱もしくはライブラリを書かなければならないのは、不便です。)<br><br>上に既出の話で、グローバル変数と化したセル参照が厳しいと言う話がありましたが、確かにこれをやられると読解不能なものになってしまうので、僕自身が書くマクロは初期設定などの情報は外部のCSVファイルかダイアログボックスで入力、出力する表などの書式はコードに埋め込むと保守不能なくらい読めなくなるので、別のワークシートに雛形を作って、必要な範囲に名前を付けて読み込むように、CSVなどのデータは必ずマクロで全部受けて、Cellを介さず処理を行って、最終的にセルに吐き出すように作成するようにしています。ここまでUIや書式の設定などなどを分離しておかないと、長期に渡る保守は不能ですね・・・ 大分話がExcelだけの話ではないんですが、書式付き出力を簡便にできるというのはかなり便利です。上記のまさーるさんのRubyの記事に大分触発されていますが・・・<br><br>こんな感じで入力するCSVは数10MBであれば今のところ問題なく動いています。(ワークシートに入れなければ、大きさの制約は大分なくなる。) もっと大きなデータになるとExcelやWindowsもおかしくなりそうなので、考える必要はありますが、今のところそんな巨大なデータには遭遇していません。<br><br>あと今のところ一番お絵かきがしやすいのもVBAかなと。僕はExcelで2Dベクトルグラフが書けないので、Shape Objectでお絵かきして書かせていますが、結構簡単に書けます。同じことを他でやれと言われると、社内のどの端末でもできる方法がほとんど思い浮かびません。(手でEPS書くとかくらい。)

_ 田辺 (2007-09-23 07:30)

データを内包的に扱うか、外延的に扱うかの観点でも<br>スクリプトか、Excel かの分かれ目になるかと思います。<br><br>スクリプトは、"1〜100までの数列" という内包的な記法によって<br>簡潔に表現できますが、Excel では、実際に<br>1, 2, 3, 4 , 5, 6, 7, 8 ..... 99, 100 という即値(および即計算式?)<br>を扱うのに向くように思います。<br><br>もっとも、Excel には VBA がありますから、<br>外延的、内包的な両方の側面からデータを扱えます。ニシシ<br><br><br>おがわさん<br><br>> VBAでデータ構造で無くて困るのはせいぜい困るのはハッシュくらい?です。<br><br>VBA の Collection オブジェクトはどうですか。<br>文字列をキーとして、オブジェクトをコレクション化できます。<br><br>それから、ツール->参照設定で、Microsoft Scripting Runtime を取り込んでおけば<br>Scripting.Dictionary が使えるようになりますが、<br>これもハッシュテーブルのようなものです。

_ 元職業プログラマ (2007-09-23 08:30)

おがわさん、田辺さん、ExcelやVBAで仕事が出来ないといっているわけではありません。<br>「仕事を間に合わせるために、Excelのだけではなく、RubyやVim等のテキストベースのツールを使う必要があると思っています。」<br>と述べているだけです。<br>関数型言語には、高階関数やリスト内包表記等、プログラムを簡潔に書けるようにする為に有益な諸概念を多数実装しています。<br>これらの諸概念が、プログラム作成やプログラム保守を行って行く上での時間節約に、非常に役立つと思っているわけです。

_ おがわ (2007-09-23 19:36)

Matzさんの日記を借りて議論するのも気が引けるのですが・・・<br><br>田辺さん、Scripting.Dictionaryの存在は知っていたんですが、なんとなくGenerics導入前のJavaのコレクションクラスのような感じでして、注意して使わないとなあと思って保留になっています。でも確かにそうですね。(一応すべて型宣言は必須にして使用していますので、たぶんちゃんとキャスト(でいいのかな)しないときっとだめだめです。)<br><br>元職業プログラマさん、非常に役立つかどうかと言う視点ではなく、もはや職場でそれしか選択の余地がない状態になっています。僕自身もLispやSchemeでプログラムを書くことはありますので、関数型言語が持っている諸概念もそれなりに理解している(完全に使いこなしているとは言い難いが)つもりです。でもそのような物は選択できない環境なんです。VBA以外の言語もそれなりにかじってきているので、それらの概念がプログラムの保守に役立っていないはずはないです。<br><br>最初の話に戻るとExcelを表面的に使うだけでもExcel VBAはそこそこ便利な存在だと思います。それはデータに紐付いていたり、利用者がとっかかり易いと言う視点はあると思います。あとWindowsに多くインストールされているCOM/DCOMオブジェクトを有機的に組み合わせて使い始めると恐ろしくExcel VBAの使い勝手が上がります。たぶん他の言語でもWindowsで使える物であればできるはずなんですが、その環境を社内のどの端末でも暗黙の前提として使えるもしくは新規にインストールしなくて良いもしくは動作環境も保守しなくて良いと言う点で、Excelは便利な存在だと思います。逆にRubyをVBAに置き換えて使えるようにするには、Windows Updateでインストールできるくらいにならないと、現状の社内の環境では厳しいなと思います。(まつもとさんにがんばってもらうしか・・・)

_ 元職業プログラマ (2007-09-24 09:55)

おがわさん、私が<br>>「仕事を間に合わせるために、Excelのだけではなく、RubyやVim等のテキストベースのツールを使う必要があると思っています。」 <br>といった意味は、先にも述べさせていただきましたが、プログラムの作成効率や保守効率だけではなく、実行効率も重視しているためです。<br>たとえば、Excelを使う場合は、Excelを起動するだけでかなり時間がかかってしまいますし、VBAでCreateObject()を発行する場合も、オブジェクトにもよりますが、かなり時間がかかる場合があります。<br>(処理にもよりますが、特定のデータ処理をExcelで行った場合とMySQLやPostgreSQLとRubyやHaskell等の組み合わせで行った場合の時間を比較すれば面白い結果を得られるかもしれませんね。)<br><br>>まつもとさんにがんばってもらうしか・・・<br>私もそのように思いますが、我々も頑張りましょう。

お名前:
E-mail:
コメント:
[]

«前の日記(2007-09-07) 最新 次の日記(2007-09-09)» 編集

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.