富豪化理論で何ができるか? 25
ストーリー by kazekiri
ニュータイプの欲求は果てしない 部門より
ニュータイプの欲求は果てしない 部門より
argon 曰く,"社会はその活動においてその時々の技術上の制約を受けるが、
コンピューティングに限った場合、記憶容量という制約が大きい。
これまでは如何に少ない資源で結果が得られるかという視点から
論じられてきたのは同意いただけるだろう。
だが、今日の我々は 富豪的プログラミングの概念を手にしている。 そして HDD も Memory もかつてなく価格が下落している。 さて、我々はこの状況に相応しい道具を手にしているだろうか?。 これからの富豪的プログラミングのための、 富豪的プラットフォームはどうあるべきだろうか?"
だが、今日の我々は 富豪的プログラミングの概念を手にしている。 そして HDD も Memory もかつてなく価格が下落している。 さて、我々はこの状況に相応しい道具を手にしているだろうか?。 これからの富豪的プログラミングのための、 富豪的プラットフォームはどうあるべきだろうか?"
富豪的プログラミングは、 ニュータイプの条件に含まれていることを高林氏の 「UNIXにみる世代間の断絶」は示していると言える。 ニュータイプのニューテクノロジーへの欲求は果てしなく、 尽きることがない。それにハードウェアプラットフォームが 付いていけているかは、そのニュータイプの度合いによるだろう。
器用貧乏な自分に乾杯(笑) (スコア:2)
私はニュータイプとキュータイプ(笑)の間くらいにいる気がします。(bashってNewtypeじゃないんか)Emacsも使うしviも使います。何にもできない、またはアレしかできないよりは、おおよそほとんどの技術に対してある程度デキるほうが都合がいいからです。(器用貧乏とも言うが。)
awk、sedの書き方、UNIXパイプの考え方は違和感無く受け入れられたし(OldType)、Pythonのいろいろなモジュールでいろいろ試してみることも楽しいです(Newtype)。
私にとってステなのは、先が見えた技術というか、発展性に乏しい技術、何もしないでいい技術です。
貧民的プログラミング (スコア:2, 参考になる)
最近のソフトは重すぎて使いにくい (スコア:2)
最近 (といっても、DOS から Windows に移行したころ以降だから、ここ5年くらいか) のソフトは、遅すぎて使いにくくて仕方がないです。ボタンを押しても瞬間的に反応してくれないことが多いし、キーを押してもそれが瞬時に画面に現れてくれない。アプリケーションソフトの起動時間だって、1秒以上かかるのが普通です。DOS から Windows に世間が移行した頃、PC の電源を入れてから使えるようになるまで1分もかかってるようじゃ我慢できないと言って AUTOEXEC とか CONFIG とかをいじり倒した経験がある人も多いはず。
そういう、コンピュータの使いやすさに対するユーザのシビアな目が失われたからこそ、「富豪的プログラミング」なんてことが実現可能になったのではないでしょうか。
というか、最近パソコンを使うようになったという人が多いので、そういう人は過去の使いやすいコンピュータを知らないので、特に不満もないので、ソフトウェアを作る側としてはそれほど軽さにこだわらなくてもマーケティング上は問題ないのかもしれませんが。
Re:最近のソフトは重すぎて使いにくい (スコア:2)
ということで、この領域ではユーザーは小さく軽く速く長くを求めるわけで、結局わがままなのは変わらないわけだけど、その方向はもうちょっと「シビアさを追求する」もののような気がします。多分、このあたりが際限ない富豪化には壁になっているのでしょうね。
でも移動体通信が高速になるとどっかにバックアップサーバーがリッチに動いててモバイルはThin端末っぽくなってしまうのかも知れないなあ。
Re:現実問題として (スコア:2, 興味深い)
(それ以前にまず) Object(指向)を使うことが
富豪脱却の1つの道だったりするように思っています(^^;
Objectはそれ自体が自分に必要な情報のキャッシュなわけで。
しかも記述はさほど面倒にならない(のでわざわざ富豪的大食して不健康に太る必要もない)し。
Re:HDDやMemoryのサイズは富豪化したけど (スコア:2)
通信屋というか、NTT様は、デフォルト通信手段が電話なのに問題がある。
# 今日がADSL開通予定日。もちろんNTTとの連絡はまだ。X-P
Re:貧民的プログラミング (スコア:2, 興味深い)
-----
ところで,貧民的プログラミングは,開発者の負担が大きいので,結構ストレスが溜まります.組み込みの仕事が長かった私は,結構うんざりしてました.
で,UNIX で制御するシステム開発に加わってみました.以前と比べれば,すさまじいばかりのCPUパワー,無尽蔵とも思えるメモリ,なによりもセルフ開発の面倒のなさ.余計なことをほとんど考慮せずに,ひたすらシンプルで直接的な実装を追求する....実に,実につまらない!
富豪的プログラミングで楽しいのは,上位のアプリケーションを書くことだと痛感しました.下位のシステムを書くならば,貧民的プログラミングの方が楽しい,かもしれない!?
------
Yoshige
昔も富豪だった (スコア:2, 参考になる)
この気持よくわかります。私も昔長いこと実時間シミュレーションをやってましたから。 精度を考えるならCPUにあまり負担をかけないアルゴリズムにしておいて、 単位時間あたりの計算回数を増やす方向にもっていくのだけど、 凝ったアルゴリズムはその分調整が難しい。 何度調整してもぜんぜん値が合わない状況が何日も続くと、 ある日突然、ちゃぶ台をひっくり返して簡単にしちゃうんだよね。 メモリーの使い方もそうだけど、イベント駆動的な解法を単純な繰り返し計算にするとか。
今、富豪的プログラミングはハード性能がよくなったから可能になったと考えられていますが、 今ほど性能がよくなかった時代でもお金のあった本当に富豪な頃は高価な計算機をじゃんじゃん使っていました。 某原発の隣にある某施設には、たった一つのプログラムを動かすだけの贅沢な計算機があります。 安全解析に使ったモデルをそのまま変更せずに実時間で動かすというのが目的なのですが、 今だったらこんなもったいないことはしないな。
HDDやMemoryのサイズは富豪化したけど (スコア:1)
なんでもあるという状況 (スコア:1)
それから、簡単に使えるようになっていること、かな。
# あと、富豪だから、誰か他の人がやってくれる、というのはだめですか?:-P
-------- SORAMINE Yukino
現実問題として (スコア:1)
現実問題として、確かに「富豪プログラミング」」は有効であるし、私も同じ考え方でプログラミングしているが、実際には、
- 生成の最適化(たとえばオブジェクトなどの生成物はプーリングして再利用)
- アルゴリズムの最適化
- コードサイズの最適化
などの「富豪的でないアプローチ」も必要だと思う。組み込み用途だったりする場合は、まだまだ用件として存在しているし、ますます増える傾向にあるので、そこでは、旧世代的なチューニングの嵐。
#もちろん、そこでも大リソース化の傾向はあるが。
ようは(「富豪的プログラミング」を用いるにしても)最終的にバランスだと思ってたりして。
Re:HDDやMemoryのサイズは富豪化したけど (スコア:1)
(キャリアに限らず、メーカーもね)
これだけプロセッサやメモリは速くなってソフトも安くなって進化してるのに、通信屋さんだけがいろいろな言い訳で逃げている。
猛省を求む > 通信屋さん
メモリを潤沢に使うファイルイステム (スコア:1)
普段の HDD は差分のキャッシュ置き場にします。 HDDは常に差分情報なので、稼動したままバックアップがとれます。
Re:極端 (スコア:1)
そのまま考えなしに作ったらヘボですけど。
Re:最近のソフトは重すぎて使いにくい (スコア:1)
たとえばWinとDosの対比でいえば、
イベント駆動プログラミングであるかどうかの差が有る。これが重い(笑)。
で、イベント駆動自体は腹の足しにならないことが多いけど、
問題はそれが必要とされている理由が「マルチタスク」である、という点だと思います。
マルチタスクは、無いと困るというか、有ることによって
計算機が飛躍的に使いやすくなると、思うんですよね。
正確にいえば、同時に「動ける」かどうかというよりも
同時に「存在できる」かどうか。
エディタと絵ツールとetc...が同時に立ちあがっていることが
出来るかどうか。
富豪が良いとは思えないことが多いですが、昔に戻るといっても、
例えば「DOS時代のような」貧乏さは、もう勘弁して欲しいと思うんです。
DOSのあの、子プロセスが動いている間は(裏技プログラミングをしない限り)
親プロセスに触ることが出来ない、という制約は、
本当に貧乏人の麦な感覚でした。
あの制約がなくなるというただそれだけで、
DOSモバのUnishellやDOSを捨ててPocketBSDに行く
十分な理由になると思います(笑)。
----
アルゴリズムの話については、処理速度のオーダーって奴も重要だと思う。
Re:現実問題として (スコア:1)
なるほど、「オブジェクト指向」は「富豪脱却の1つの道」になる可能性があるという部分は同意です(^^)。しかし、オブジェクト指向で作れば、
に必ずなるとは思いません。(もちろんなる場合もあると思いますが。)やっぱりそのあたり意識する必要があると思います。#オブジェクトがどのように情報を持っているかというのは実装依存だと思いますし...。
printf を使う位なら puts を使え (スコア:1)
っていつの時代なんだって =)。
Mc.N
Re:貧民的プログラミング (スコア:1)
殿様的プログラミング (スコア:1)
Javaを捨ててPerlを使うだけでも結構富豪気分が味わえると思います。 私も昨年ぐらいまでは製品は何でもJavaで書いていましたが、 近頃は、小難しいJavaなんかやめてPerlで書けば十分だと思うようになりました。
ハードウェアの制約がなくなっても、 脳みそとスケジュールの制約は依然として最大の問題ですから、 本来、保守や再利用を十分に考慮して実装したいのはもちろんだけど、 あとでどうなるかを考えるよりも、 今やりたいこと(=何を作って効果を上げるか)を考えることに主に時間を使い、 実装はハッキングで済ませるというのもありだと思います。 あとのことをキレイサッパリ考えないわがままプログラミングなので、 私は、富豪的ならぬ殿様的プログラミングと呼んでいます。
私の仕事はインターネットサービスの開発だから、あとですぐ捨てちゃうことが多いのでまあいいんだけれど、組み込みや制御系ではちょっとね。それとデータベース設計も殿様には無理だ、かといって家来に任せるわけにもいかず…
Re:殿様的プログラミング (スコア:1)
資源は浪費してるのですが、 構造を簡単にすることでモデルの見通しがよいので保守しやすく、
CPU のパワーもあって充分に実用になっているようです。
Re:メモリを潤沢に使うファイルイステム (スコア:1)
あと、お手軽なのはオンメモリで動作するストレージですね。
Re:現実問題として (スコア:1)
ええ。実装依存であり、必ずそうなる保証があるものじゃない、のは確かです。
#OODには「論理」的裏づけが無いですし。
ただ、「面倒じゃなくなる」。
つまり(脱富豪という方向性の)導入障壁を下げる効果は期待できると思います。
手間の数が減ったり、タチの悪い種類の手間が減ったり、はすると思います。
Re:貧民的プログラミング (スコア:1)
楽しいかどうかと問われると、二つのしばしば相反する価値観の間で引き裂かれそう(笑)になります。
つまり、
「なんでこんな面倒な思いをしないとならないんだ!」という価値観と、
「なんでこんな退屈な思いをしないとならないんだ!」という価値観。
ただまぁ、怠惰のためならナンボでも努力する、という諺もありますんで、
アレを「退屈」と呼ぶのは、なんか違和感を覚えるってのも正直な感想です。
特に、OOPみたいに「足し算を掛け算に変える」ような効果がある(はずの)やりかたを
愛するようになると…。
新人が現場から見て。(オフ気味) (スコア:0)
早く帰ろう、楽しようって視点は無いのかな…
#手でやらなくてもイイジャン!イイジャン!
極端 (スコア:0)