(cache) はてなブックマーク - ソフトウェアの技術革新って必要なのかな？

- 264 users
ソフトウェアの技術革新って必要なのかな？
- テクノロジー
- 2015/04/15 09:24
- はてな匿名ダイアリー
- プログラミング増田あとで読むソフトウェア考え方 programming it
プログラマの間では昔から、この手法は処理が遅いだとか、無駄が多いだとか、再利用を心がけろだったりとか様々なやり方で、ソフトウェアをチューンナップして処理速度を上げるためのやりとりが際限なく繰り返されているけど、だいたいどれ…続きを表示

人気コメント (10)
新着コメント

すべてのブックマーク

megazalrock 将来のハードウェアの革新を待ってたら納期に間に合わないだろ。
リンク2015/04/15 シェアシェア
wwolf 10年前にはすでに富豪プログラミングという言葉があったし、それ以前も処理速度よりも保守性を重視せよって普通に言われてた。
リンク2015/04/15 シェアシェア
ninosan まあ、いわゆる「だったらアセンブラで書けば？」ってやつだよねえ。自身も速度よりもわかりやすいコードに一票。
リンク2015/04/15 シェアシェア
muchonov 10年前ぐらいに増井さんが提唱してた「富豪的プログラミング」ですね http://www.pitecan.com/fugo.html
リンク2015/04/15 シェアシェア
cider_kondo 少なくともシーケンサ(PLC)は最初期の「メモリ節約がすべてに優先する」時代以外、『変更のしやすさ、可読性のよさ、移植性の高さといった所のみを追求していって、速度はハードウェアに依存する形』だとは思う
リンク2015/04/15 シェアシェア
outland_karasu 最近は逆で、ハードウェアの変化にソフトが追いついていない。メニーコア・GPGPU・FPGA・非同期処理といったものを活用するには、プログラム側にパラダイムシフトが必要プログラミング考え方
リンク2015/04/15 シェアシェア
QJV97FCr Windows XPを客先がリプレースしてくれない業務アプリケーションのことも思い出してやってください
リンク2015/04/15 シェアシェア
reachout 今納めたシステムは向こう10年くらいハードウェアもそのままで動いてしまうんだよ、そんなホイホイとハードウェア最新化してくれるような客ばかりなら良いんですがねぇ・・・
リンク2015/04/15 シェアシェア
junglejungle でもCPU性能はほぼ頭打ちだよ。３年ぶりにPCを新調しようとして最近のCPUベンチマーク調べたらたった1.2倍。現行CPUのOCで済ませたわ。一昔前は2倍は固かったのになぁ。
リンク2015/04/15 シェアシェア
damedom 用語の使い方がガバガバなエンジニアのひとって……
リンク2015/04/15 シェアシェア

zakkie 昔からある、才能に欠けた人の言い訳。 programming development
リンク2015/04/15 シェアシェア
shimokiyo エンジニアなのに言葉の定義が適当やなｗｗ　結局ユーザーから見たというどう思うの？ってレベルの話だからね。
リンク2015/04/15 シェアシェア
hatsu_mi 可読性あげると、速度もよくなるし移植もしやすくなるはずって信じてる
リンク2015/04/15 シェアシェア
gabill どこかで苦労したお陰で別のどこがで富豪的手法がとれてる面もあると思う。Chromeがカリカリに高速化してるお陰で「何でもJSでやればいい」というnode.jsのような富豪的な派生物が生まれた。
リンク2015/04/15 シェアシェア
KUROBUCHI アルゴリズムが処理速度にシビアに関わる部分は、チップとしてハードウェアロジックに吸収されたり、ミドルウェアまでのライブラリに吸収されてそう。
リンク2015/04/15 シェアシェア
chintaro3 そこに金を出してくれる人が居ないんだよね。悲しいね。
リンク2015/04/15 シェアシェア
naqtn 職業プログラマの作成したソフトの価値は、その時の市場投入した価値で計られるわけで、今いくらで作れるかは「無駄か？」には関係ない。今コンパイラが無料で手に入るからといって元祖FORTRANの価値は揺るがないプログラマー
リンク2015/04/15 シェアシェア
tzjnx クソなコード組んでると、突発的な要因で処理データ件数が激増した時に指数関数的に速度が落ちたりすることが多いので、HW性能に頼り切らず、それなりにパフォーマンスを意識したコードは組んでおくべきだと思う。
リンク2015/04/15 シェアシェア
nanoha3 HWにもっと金かけろよと思うことは時々ある。
リンク2015/04/15 シェアシェア
nakag0711 ハードウェアを高速化するとその分機能を追加するし、ライバルのソフトも一緒に高速化して相対的順位が変わらないので、あなたのソフトのもっさり感はやはり解消しない
リンク2015/04/15 シェアシェア
oyasumi-zzz パフォーマンスの目標値があってハードウェア+ソフトウェア合わせてそれを達成する。ハードは頻繁に更新できないから今のハードで足りない部分はソフト側で工夫しなきゃいけないわけだろ。
リンク2015/04/15 シェアシェア
hiromo2 本当の事を書いてあげると、遅さはコスト。速さも極端に追求すればコストが嵩む。しかし、後者はスケールメリットで相殺できる。こうしてコスト的に追従が難しいサービスが市場に誕生するのだ。
リンク2015/04/15 シェアシェア
nejipico アプリの高速化を技術革新て言ってしまう増田って。
リンク2015/04/15 シェアシェア
t-murachi 表題の意味がよく分からんのだけれども… パフォーマンスチューンナップ程度のことを技術革新って呼んでるの? それとも JavaScript の JIT コンパイラ採用とかそういうレベルの話? 釣堀
リンク2015/04/15 シェアシェア
lovevoiceryu 増田がどの分野にいるかによってまるで違う話だと思う。プアな仕事をしているなら10年前の技術で十分だし。とてつもない金を使って応答性能を保証しているシステムもあるよ。
リンク2015/04/15 シェアシェア
mini_big_foo アプリ側はどちらかというと肥大化してハードがカバーしてい感じだけど。ソフトウェアへの要求は可用性とか効率的な業務とかだよね。
リンク2015/04/15 シェアシェア
qittu FF3はあの時点ですごかったことに意味があるんだし，そのたった数年他より先にいくってことがすごく大事なことなんだけど
リンク2015/04/15 シェアシェア
nyop アプリの実装レベルでパフォーマンスを上げる方法は普遍的なプログラミング手法とはなり難いので、可読性とかメンテナンス性に注力すべき、という話。結局環境依存のもんだしね、パフォーマンス。 it programming
リンク2015/04/15 シェアシェア
damedom 用語の使い方がガバガバなエンジニアのひとって……
リンク2015/04/15 シェアシェア
ktakeda47 パフォーマンスの話 programming development business
リンク2015/04/15 シェアシェア
shibuyads おっさん // ソフトウェアの技術革新って必要なのかな？
リンク2015/04/15 シェアシェア
deadcatbounce むかしサーバー用メモリが暴落したとき、RDBのチューニングに金かけるよりRAM積まくった方が効率がいいって話になったな。今はDBMSごとオンメモリだっていうからなあ
リンク2015/04/15 シェアシェア
xr0038 例えば http://top-10-algorithms.sl-jp.com/ このあたりとか？/ソフトウェアじゃなくてアルゴリズムで検索すると結構見つかるんじゃないだろうか/増田氏にとっての「ソフトウェア」はどこからどこまでなのだろう増田プログラミングネタ
リンク2015/04/15 シェアシェア
elephant1974 基本的には賛成。しかし夜間バッチが朝までに終わらないと……
リンク2015/04/15 シェアシェア
youhey ミクロでの必要性から僕なんかは何とか飯を食べてるけど、マクロで言ったら無駄なロジックで無駄なソースを量産しているだけなのかも。ソフト／ハードだけでなく、SaaSだったり開発エンジンだったり色んな意味で
リンク2015/04/15 シェアシェア
mint6626 2番じゃダメなんですか？！
リンク2015/04/15 シェアシェア
doseisandesu 全画面FLASHサイト「せやな」
リンク2015/04/15 シェアシェア
oskimura 将棋AIとかに用いられる機械学習は正に技術革新じゃないの？
リンク2015/04/15 シェアシェア
Tesh 「どれもハードウェアの技術革新によって～」お前それ新MacBookの性能見て同じこと言えんの？既に終わってるんだよ、ムーアの法則も富豪的プログラミングも／「レスポンスは1秒以内」とろくせぇ。ミリ秒の世界に来い。技術
リンク2015/04/15 シェアシェア
esper アプリケーションレベルでのパフォーマンスチューニングのことを「ソフトウェアの技術革新」と呼んでいるみたい。
リンク2015/04/15 シェアシェア

raven38
2015/04/15
zakkie 昔からある、才能に欠けた人の言い訳。 programming development
リンク2015/04/15 シェアシェア
miragebrigade
2015/04/15
shimokiyo エンジニアなのに言葉の定義が適当やなｗｗ　結局ユーザーから見たというどう思うの？ってレベルの話だからね。
リンク2015/04/15 シェアシェア
sakapon_jp
2015/04/15
hatsu_mi 可読性あげると、速度もよくなるし移植もしやすくなるはずって信じてる
リンク2015/04/15 シェアシェア
n_pikarin7
2015/04/15
mailpoypoy
2015/04/15
ginga0118 あとで読む
2015/04/15
gabill どこかで苦労したお陰で別のどこがで富豪的手法がとれてる面もあると思う。Chromeがカリカリに高速化してるお陰で「何でもJSでやればいい」というnode.jsのような富豪的な派生物が生まれた。
リンク2015/04/15 シェアシェア
Agatsuma
2015/04/15
soteciki
2015/04/15
KUROBUCHI アルゴリズムが処理速度にシビアに関わる部分は、チップとしてハードウェアロジックに吸収されたり、ミドルウェアまでのライブラリに吸収されてそう。
リンク2015/04/15 シェアシェア
chintaro3 そこに金を出してくれる人が居ないんだよね。悲しいね。
リンク2015/04/15 シェアシェア
ochasuki
2015/04/15
naqtn 職業プログラマの作成したソフトの価値は、その時の市場投入した価値で計られるわけで、今いくらで作れるかは「無駄か？」には関係ない。今コンパイラが無料で手に入るからといって元祖FORTRANの価値は揺るがないプログラマー
リンク2015/04/15 シェアシェア
tzjnx クソなコード組んでると、突発的な要因で処理データ件数が激増した時に指数関数的に速度が落ちたりすることが多いので、HW性能に頼り切らず、それなりにパフォーマンスを意識したコードは組んでおくべきだと思う。
リンク2015/04/15 シェアシェア
takobayashi626
2015/04/15
nanoha3 HWにもっと金かけろよと思うことは時々ある。
リンク2015/04/15 シェアシェア
nakag0711 ハードウェアを高速化するとその分機能を追加するし、ライバルのソフトも一緒に高速化して相対的順位が変わらないので、あなたのソフトのもっさり感はやはり解消しない
リンク2015/04/15 シェアシェア
seo-vip
2015/04/15
oyasumi-zzz パフォーマンスの目標値があってハードウェア+ソフトウェア合わせてそれを達成する。ハードは頻繁に更新できないから今のハードで足りない部分はソフト側で工夫しなきゃいけないわけだろ。
リンク2015/04/15 シェアシェア
hiromo2 本当の事を書いてあげると、遅さはコスト。速さも極端に追求すればコストが嵩む。しかし、後者はスケールメリットで相殺できる。こうしてコスト的に追従が難しいサービスが市場に誕生するのだ。
リンク2015/04/15 シェアシェア
nejipico アプリの高速化を技術革新て言ってしまう増田って。
リンク2015/04/15 シェアシェア
t-murachi 表題の意味がよく分からんのだけれども… パフォーマンスチューンナップ程度のことを技術革新って呼んでるの? それとも JavaScript の JIT コンパイラ採用とかそういうレベルの話? 釣堀
リンク2015/04/15 シェアシェア
komoko-i あとで読む
2015/04/15
taihe
2015/04/15
lovevoiceryu 増田がどの分野にいるかによってまるで違う話だと思う。プアな仕事をしているなら10年前の技術で十分だし。とてつもない金を使って応答性能を保証しているシステムもあるよ。
リンク2015/04/15 シェアシェア
mini_big_foo アプリ側はどちらかというと肥大化してハードがカバーしてい感じだけど。ソフトウェアへの要求は可用性とか効率的な業務とかだよね。
リンク2015/04/15 シェアシェア
qittu FF3はあの時点ですごかったことに意味があるんだし，そのたった数年他より先にいくってことがすごく大事なことなんだけど
リンク2015/04/15 シェアシェア