閉じた世界での見解をあたかも全てであるかのように発信する。
RubyとJava(WEB限定)でできることに差がないならJavaを選択する
RubyとJava(WEB限定)でできることに差がないならJavaを選択する
よね、というのがその最たるもの。そこに「自分たちの業界では」
という注釈が付くことは稀。
Javaは時間を掛けてかっちり組むのには向くけど、短期間(数日)で
Javaは時間を掛けてかっちり組むのには向くけど、短期間(数日)で
アイデアを形にしてリリース・継続的変更のサイクルを数時間~
数日単位で行っていくのには向かない。Java自体がそもそもコード
量を減らして開発をスピーディに進めることを主眼にした言語では
ないし、EOD(Ease Of Development)、EODとJavaで騒いだところで
対LLではその生産性には埋まらない溝がある。
Javaの親であるSunが何故Rubyに投資しているのか、考えたほうが
Javaの親であるSunが何故Rubyに投資しているのか、考えたほうが
いい。
変化が緩やかな業界では保守性等を考慮してJavaでシステムを組む
変化が緩やかな業界では保守性等を考慮してJavaでシステムを組む
ことに意味があるが、日々急速に変化する業界では今日リリースした
サービスが近日中には陳腐化するので、保守性等を過大評価して生産
性の見劣りする言語で組むことに意味はない。
サービス(顧客にどんなサービスを提供できるか)に軸足をおいた場合、
Javaで開発することに意味はない。そのサービスで何ができるかが
問題であって、そのサービスが何で作られているかには何の意味も
ない。サービスの迅速な提供が重要になるので、サービスを短期間で
サービス(顧客にどんなサービスを提供できるか)に軸足をおいた場合、
Javaで開発することに意味はない。そのサービスで何ができるかが
問題であって、そのサービスが何で作られているかには何の意味も
ない。サービスの迅速な提供が重要になるので、サービスを短期間で
開発できる生産性の高いプログラミング言語が必須となる、
サービスの開発に時間をなるべく掛けないことが求められる。
SI屋の業界では状況が異なる。SI屋はクライアントに提供する
サービスの開発に時間をなるべく掛けないことが求められる。
SI屋の業界では状況が異なる。SI屋はクライアントに提供する
ソフトウェアで何ができるか(そのソフトウェアが顧客にどんなサービス
を提供できるか)ではなく、そのソフトウェアの構築に掛かった時間で
対価を受け取る。SI屋は構築したソフトウェアをクライアントが利用
しなくても別に損はしない。何故なら、仕様についてクライアントと
合意さえできていて、そのソフトウェアに仕様以外の深刻な問題が
なければ、クライアントとの契約を満たしているので、SI屋の構築
したソフトウェアが実用にたえなくても、クライアントは契約に応じた
対価をSI屋に支払わなくてはならないからである。何故支払わなくては
ならないかは自明、顧客と受注時にそのように契約を交わしているだけ。
ちなみにSI屋は変化が緩やかな業界をターゲットに商売をしているケース
ちなみにSI屋は変化が緩やかな業界をターゲットに商売をしているケース
が大半。短期間(数日)でアイデアを形にしてリリース・継続的変更の
サイクルを数時間~数日単位で行っていくことが要求される業界では
上記のようなSI屋のビジネスモデルは成立しない、だから、そのような
業界をSI屋は避けてとおる。
そして、SI屋は自分たちの構築するソフトウェアを高級そうに見せること
そして、SI屋は自分たちの構築するソフトウェアを高級そうに見せること
ができ、その構築により多くの時間を掛けることのできるプログラミング
言語を選択する。何故なら、短時間で構築できては商売にならないから。
そこでJavaの登場、LLとの比較では実行速度や保守性等を引き合いに
そこでJavaの登場、LLとの比較では実行速度や保守性等を引き合いに
出して、クライアントを説得する。生産性よりも保守性・実行速度が
etc大事ですよとクライアントに...。
言語自体の実行速度ならJavaはRubyに勝てるが、Rubyでは実行速度が
言語自体の実行速度ならJavaはRubyに勝てるが、Rubyでは実行速度が
要求される部分はCorC++で組まれて拡張モジュールとして言語に
アドインされるので、トータルとしてみた場合は言語自体の実行速度に
あまり意味はない。
(特定の)クライアントを相手にするせよ、(不特定の)カスタマーを相手に
するにせよ、サービス(顧客にどんなサービスを提供できるか)が大事で
そのサービスを支える技術には意味があるが、そのサービスを提供する
ソフトウェアの構築にどの技術を使うか、その優劣について議論すること
に意味はない。更にいえば、その時々で変化する技術のトレンドについて
本質ではなく、重箱の隅を議論することには何の意味もない。
<蛇足>
Java製フレームワークを作ってRails対抗を打ち出している人種は何故
(特定の)クライアントを相手にするせよ、(不特定の)カスタマーを相手に
するにせよ、サービス(顧客にどんなサービスを提供できるか)が大事で
そのサービスを支える技術には意味があるが、そのサービスを提供する
ソフトウェアの構築にどの技術を使うか、その優劣について議論すること
に意味はない。更にいえば、その時々で変化する技術のトレンドについて
本質ではなく、重箱の隅を議論することには何の意味もない。
<蛇足>
Java製フレームワークを作ってRails対抗を打ち出している人種は何故
そのコードを読む人間が作者界隈にしかいないのかも考えたほうがいい。
そのフレームワークは作者周辺にしかわからない、他の人間は容易には
解読できないようでは...読みやすい、理解し易いコードというのも生産性
そのフレームワークは作者周辺にしかわからない、他の人間は容易には
解読できないようでは...読みやすい、理解し易いコードというのも生産性
の一端。作者界隈にしか解読できないフレームワークは商用プロダクト
と大差ない、OSSはお墨付きではない。タダで使って利用者が社内で付随
コストを負担するか、商用サポートを購入して付随コストを外部に支払う
か、ただ、それだけの違い。だから、学習コストだけで済む枯れた
フレームワークから利用者は中々新しいものに移行しない。
<蛇足>
エンジニアは自分がコミットした技術を他人に押し売りしたがる。
その最たるものが「狛犬もどき」、関東方面では何処にでも出没
して、自分たちのプロダクトはブレイクスルーだと喧伝する、
LL使いからは何処がブレークスルーだと白い目で見られている
模様、かのRuby設計者は「Javaの世界ではブレイクスルーなんだろうね」
のフィーリングで呆れかえっているらしい。
「狛犬もどき」は技術をこねくりまわして喜んでいる集団、それも
技術の本質ではなく重箱の隅を。
「狛犬もどき」が世界に通用しないのは技術の重箱の隅をこねくりまわ
しているから。Rubyが世界に通用した一端は本質的な技術に取り組んだ
<蛇足>
エンジニアは自分がコミットした技術を他人に押し売りしたがる。
その最たるものが「狛犬もどき」、関東方面では何処にでも出没
して、自分たちのプロダクトはブレイクスルーだと喧伝する、
LL使いからは何処がブレークスルーだと白い目で見られている
模様、かのRuby設計者は「Javaの世界ではブレイクスルーなんだろうね」
のフィーリングで呆れかえっているらしい。
「狛犬もどき」は技術をこねくりまわして喜んでいる集団、それも
技術の本質ではなく重箱の隅を。
「狛犬もどき」が世界に通用しないのは技術の重箱の隅をこねくりまわ
しているから。Rubyが世界に通用した一端は本質的な技術に取り組んだ
から。
0 件のコメント:
コメントを投稿