github、RubyとMVCの限界を悟りC#とMVVMに全面移行　／　オープンソース界に激震

ソース
http://www.slideshare.net/Xamarin/git-hub-halp-app-minimizing-platformspecific-code-with-mvvm-by-justin-spahrsummers

ならPythonに移ればおk＾＾

もう全部C#でいい気がしてきた
MS製でさえなければ...

MVVMパターンなんてあんのかー

うそだろw

Microsoftってのを気にしなければ優秀な言語だからね

MVCとMVVMの具体的な違いがわからない

Scala最強伝説

まさかのLinux + mono かよ

安定して動くレベルなのか？

MVC論争はうんこになるのでそっと閉じるに限る

ただでさえウザイruby厨が発狂するなｗ

エホバ製のRuby信者がリアルで殺しに来るぞ

Smalltalkがとうの昔にPluggableMVCから
Morphicに移行したってのに今更かよ

松本発狂

聖戦だ

vimを使おうと思ってプラグインが便利だからって言うから調べたら、
~/vim　にどうこうって書いてあったけど、
まず　~/　ってどこ？

Rubyは速くなった速くなった詐欺だから

>>7
ビューの仮想化

rubyは自分で書くにはいいが、人の書いたのを読むのは最悪

やっと C# 最強に気づいたのか。
おせぇー。

バズワードでっちあげて形式に囚われるから最終的に袋小路に陥る

プログラマ的にはMicrosoftだとなんでだめ？互換性ないとか？開発環境の話？

>>22
宗教

>>22
お金持ちがない
ITドカタはビルメン介護も驚くほど薄給だからな

C#で記述した演算計画を翻訳して実行ファイルを作りたいのですが、
翻訳に使う翻訳機でおすすめなのはどの翻訳機ですか？

コントローラーがビューモデルに変わるのか。

なるほどね

>>16
たぶんその時点でついてくの無理だと思う

プログラミング言語ってなんで統一しないの馬鹿なの

>>16
車を運転して高速に乗ろうとしてるのに、「ブレーキってどこ？」と言ってるレベルやぞそれ

C#楽だもんな

MVVMなんて初めて聞いた

>>22
規格違反しまくりだから
道具というのは必要に応じて取り替えられるようにすべきだが、
MSの道具で作業するとMS専用になって他の道具に変えられない。

ハッキリ言って最強言語はc#だと思うよ
言語仕様、ライブラリ、visua studio、実績、将来性
トータルで見るとc#はずば抜けてる
唯一弱点があるとすればwinodws環境中心のテクノロジーだってこと

とりあえずRubyで作って広まったら他で作りなおすのが流行りだよな

MVVMってなに？

ヘジのライブラリ設計嫌い

MVVMって優れたUI層(XAML)あってこそだから、
他じゃ厳しいんじゃね。

GCCからclangの以降とかもやってんのか？

>>7
mvcというのはウェブのサーバーサイドで使われてる、ロジックとビュー(html)をコントローラから切り離す設計手法
対して、mvvmはguiアプリ(javascriptによるhtml5アプリも含む)で使われる、ビューの部品フォームにロジックを結びつけて部品フォームの表示操作を行う設計手法
と考えておけばほぼok

rubyは役目終わった。さっさと滅ぶべき

>>33
でも>>1の話はMonoだぜ？

>>22
自分たちは選ばれた人間(マカー、リナクサー)なんだって自尊心を持つことで薄給の土方仕事って現実からプライドを守るため

rubyを選んだのが間違い

>>35
ビューを仮想と実体に分ける方法。
HTMLに例えるとデザインを全部外部CSSで書くような感じ。

Rubyはあれだけもてはやされてたのが異常だったよ
韓流に熱中するBBAみたいなキモイのがわさわさ湧き過ぎてた

>>37
JavaScriptのknockout.jsとかクソ便利だよ

MVCなんてお題目は全く使えない
オブジェクト指向よりも宗教的で観念的なお題目だった

もうC#最強確定だな

結局Windowsサーバーがきついだけだからな
適当に運用するならWinはめちゃくちゃ楽
でもひとたび性能問題やソフトウェア障害にであうと悲惨なことになる
中小規模はWin、それ以上ならUnix,Linuxだわ

>>44
よーわからんが、MVCのVがVMになって、VMにVがぶら下がってる感じか？

>>37
xamlほど機能性ないけど、ウェブアプリにもhtml5がある

>>39
全然ちげぇよ
一つのModelを複数のViewとControllerで共有し、
ViewとControllerを再利用する仕組みだ。
|view model controller|
"新しいmodelとviewとcontrollerを生成"
model := CPUSensor sensor.
view := BarChartView view.
controller := ClosingController view: view model: model.

"modelとviewとcontrollerを連結
これ以降modelへの変更がviewに
自動反映されるようになる"
view model: model.
view controller: controller.

"別のviewとcontroller生成"
view := WaveChartView view.
controller := ClosingController view: view model: model.

"既存のmodelと別のviewとcontrollerを
結合する。個々で別のviewとcontrollerを
結合しても、以前に結合した
MVCの関係は維持される"
view model: model.
view controller: controller.

ASP.NETは凄かったがWindows Serverがクソすぎて全部台無しだったのが
Monoの完成度が上がってLinux上で再評価されてる感じだな。

XAMLはうんこだしHTML5が一向に広まらないのもMVVMに問題があるんだろう
UIという宇宙を舐めすぎてる

全てをコールバックで記述するような関数型の方法が本来UIには適してる

ああなんだネイティブアプリのほうかよ
びっくりさすな

>>50
違う
ウェブアプリはhttpの性格上、処理の開始がhttpリクエストを受けるコントローラなんだけど、guiアプリはguiの部品、例えばボタンとかを押すことで処理が開始する
ウェブで考えるなら、mvcはサーバーサイド向け、mvvmはクライアントサイド向けのデザインパターンと考えていい

>>50
WPFは全部C#だから分かりにくいがknockout.jsを見れば分かりやすいと思うよ
。
モデル（DBなど）
コントローラー（サーバーサイド）
ビューモデル（JavaScript）
ビュー（HTML）

あのー
>>1のスライド
github for windows その他の話なんですけど・・・

ruby信者はただちに宣戦布告した

rubyは一人用
この条件を満たすなら悪くない

そろそろG-BASICあたりに回帰しないかな

>>56
.netはhtml上のgui部品とController関連付けできねぇのか、
しょっぼ。
Seasideなんかじゃ10年以上前から実現してるってのに。

C#はsshで入ってCUIで使える統合開発環境があればなぁ
とは思う。

ソリューション単位プロジェクト単位で管理できない単純なテキストでは辛い

松本信者発狂

>>39
それまでサーバでやってたコントローラをjavascriptとかでビューに埋め込むってことなのかな
サーバ側はrestみたいなapiだけ用意しといてクライアントのhtmlから必要に応じてajaxで呼ぶとかそんな

>>62
ASP.NETがそれっぽいのだったな
コンポーネントをVBっぽく配置してwebアプリ作る
いつからかASP.NET MVC推しになって
その後WCFのRESTサービスとか

島根県民大発狂

C#ってIDEとセットじゃなきゃまともに使えないからスクリプト的なお手軽さないのが駄目

WindowsServerはホント扱いにくい
ていうかフットプリントがデカすぎ
2012でRAM 2GB/ストレージ 100GBとかアホか

>>65
見事にそう

使ったことないけどgithubってRubyで実装されてたんだ、知らんかった

サーバーとかrestとか関係ないよ

これ今作っているGithubをC#とMVVMにするって話じゃないだろ
そもそもMVVMってのはクライアント・サーバーのアプリケーションの概念だよ
GithubのスマフォアプリをWPFみたいなもので作るって話だ


でもWPFって残念というか・・・XAMLは複雑怪奇だし、バインディングも普通に作ると変数名を文字列でハードコーティングしないといけないんだぜ・・・

github guiクライアントってrubyだったの？

こスレレベル低すぎるな…

CからVMに変えたのだが、なんでそうするかっていうと
動的なUI部分はビュー-モデル間のバインディングのパターンを多用するからCよりビューモデルよりの
デザインパターン使ったほうが都合いいからってことだろ…

>>65
そう
サーバサイドはmvcで構成する、railsとかaspnet mvcってフレームワークを使う
クライアントサイドはangularjsとかknockoutjsみたいなのでmvvmで構成する
全部のウェブサイトにそんな高機能なのは必要ないけど、高度なウェブアプリサイトの場合、こういう構成が主流になるだろうね

最近の流行りはServiceStackによるドメイン駆動設計

PS4もC#だしな
時代の流れだな

MVCっていうのは別にwebアプリのアーキテクチャじゃないからね

mrubyに密かに期待してたんだけどどうなってるの？

なんか全然わからん。俺はもう現役引退だ

松本信者必死だなｗ

Rubyは作者が仏教か神道に改宗したら使う

Rubのコードの何がわかりにくいのかわからない

instanceof地獄

rubyはーC#はーとしか言えない奴がアホまるだししているスレ

>>39
>>65
>>71
なるほど
ajaxがたくさん使われるようになって、画面が遷移せずにいろいろ動くようになったから
それに対応するようにしただけか

従来のネイティブGUIアプリっていうのはそれ単体でみてもMVCアーキテクチャで作られてる
MVVMっていうのはバインディングを宣言的に記述できるような仕組みを使う時にview-modelの間にvmレイヤーを持つという話で
これはまず単純にview-modelを直接バインドすると色々扱いにくい

>>87はミス

>>39
>>65
>>76
なるほど
webで言うとajaxがたくさん使われるようになって、画面が遷移せずにいろいろ動くようになったから
それに対応するようにしただけか

>>68
それ逆で、スクリプト系の言語のユーザーがIDEが自動的にやってくれる
ことを、自分で目をさらのようにしてやってるんだとおもうわ。

スクリプト系の言語のユーザーは頭がいいから、vimでも楽勝で
C#のコードをかけると思うよ。

MVVMってうまくいくのかね。

いまんとこまともな実装はMSのWPFくらいしかしらんけど、いかんせん
XAMLがクソすぎて触る気もしない。

つうかMVCって一言で言っても色んなパターンがあるしね。
ちなみにRailsみたいにやたらめったらCがでかくなるMVCは糞だと思う。

>>68
スクリプトがお手軽なんじゃなくて、お手軽なプログラムをスクリプトで組んでるだけにすぎない。
そこそこ大規模なプログラムを組もうと思ったらスクリプトでもそれなりの開発環境が必要。

C#は別にいいんだけど、.NET Framework がなあ...
継承したいクラスやメソッドに限って sealed になってたりすることが多くて困る

ruby遅い

asp.netが糞過ぎて
画面はknockout.jsで開発した
本当はangular.js使いたかったけどasp.netと相性が悪かった

>>90
RubyやPythonみたいな汎用言語はそうかもしれんがbashや
smalltalkみたいな純粋なスクリプト言語は、
環境や言語自身のライブラリーによって今書いてるソースを
操作できる。

IDEによる補完に頼るってのは言語的にどうしても無駄な部分というか
いちいち型を書かないといけないとか後付けゆえの文法とかそういうので必要になってるだけなんやな

ついこの前まで仕事でKnockout.jsの開発者向けドキュメント書きまくってたわ。
社内向け資料だが純粋な技術資料だし一般公開してもいいかも、と思った。

>>98
よろしくお願いいたします

>>98
knockoutjsってあんまいい評判聞かないけどいいの?

ベースのJavaScriptは好きな奴はいないのに何故使い続けるのか

>>97
vi主義者もPealとかでマトモな解析補完が欲しいはずなのにホントは。

>>67
島根にパソコンなんかあるわけないだろ

>>102
欲しいはずなのに…っていうか、実際に補完系プラグインは定番になってる

これってEnterprise版使ってるユーザは自動更新になるわけよね

koはコードもライブラリとしての使い勝手もあんまよろしくないと思った

>>100
俺は良いと思ったけど、好みは人それぞれじゃないかな


俺の独断による、Knockout.jsのいいところ
・簡単。初期学習コストが低い。
・部分的、段階的に導入できるので採用リスクが低い

駄目なところ
・ちょっと凝ったことをやろうとすると途端に難しくなる。
・DOM操作が完全に隠蔽されていてパフォーマンスのボトルネックになりやすい。
・欠点とはいえないかめしれんが、ルーティングがない。やりたいならSammy.jsやjQuery mobile等の別のF/Wと併用する必要がある。

>>97
他人の書いたライブラリをその場でヘルプ込みで見れるのは便利だよ。
IDE使わない人は他人のライブラリも全部記憶できてるからいらないんだろうけど。優秀な人はいいですねぇ。

githubがってのはかなりデカいな
貢献しないにせよgithubに関わりもしないとかオワコン扱いの時代だし

誰もスライド読んでない

信仰の自由がない土人国家かよ

>>102
今どきvi主義しゃなんておらんだろ。
みんなvimに移ってプラグイン方式のオムニ保管使ってる。
python.vim当たりは、実行時メタ情報使って補完してくれる。

knockoutjsも含めて、mvvmは近年流行りのsingle page app向けのjsフレームワークでは当たり前の設計になってる

IDEがあればメソッド名を記憶しなくて良くなるんだからこんなに素晴らしいことはないわ

Rubyに嫉妬してる奴多過ぎワロタ

スクリプトって動かすまでスペルミスすら気づかないんだろ？ｗ
こんなんで大規模システムとか頭おかしい

とテストの重要性に気づかないで大規模システム作れると勘違いしてる秋の昼下がりであった

>>7
MVVMはちゃんとしたVMやM（Model）を作っておくと
Mの値を変えるだけで勝手にViewを更新してくれる

例えばロジック部分で　K=K+1とやると
View上でバインドしてあるKの表示も変わる
値だけじゃないくてそれに応じて背景色なども変えることもできる
ｋ>0 で文字色赤色になるとか

>>116
んなこたないよ。xxLintなスクリプトはどのスクリプト言語でも大抵あるし。

なんで>>2で松本に相談しようか？ってレスが付かないんだよ？
もうニュー速終わったな

以外に話をわかっているケンモメンが多くて衝撃
プログラマの俺でも理解半分なのに
MVVMか〜

>>118
MVCだってちゃんとVとMを作っておけばMが変化すればVは勝手に更新されると思うが。
V-VMのデータバインディングは単なる実装方法の詳細。MVVMで無くとも使われる。
どちらもMVVMに限った話ではない。

>>122
単にVとMを直結させるとComputed propertyみたいなものが必須で
それやりだすと複雑になるからもう一枚噛ませようかっつう話やね。

>>116
C#やD言語は実行時エラーすら実行前に分かる

>>122
MVVMの本質は、バインディングというよりも、プレゼンテーション(見た目の)情報をどこに置くかって話だな。
MVC + PMと呼んでもいいけど、バインディングを行うMVC+PMをMVVMと呼ぶ向きもある。

Webアプリは基本的にCSSとJSで装飾を施すから、サーバーサイドはMVCで作ったアプリケーションに対して、更にフロントサイドにもう一つプレゼンテーションレイヤーがある。
だからWebアプリは基本的にMVC + PM(プレゼンテーションモデル)になっていると考えていい。

ただ、クライアント・サーバー系のアプリケーションだと、CSS+JSがないから、プレゼンテーション情報をCに置くかVに置くかっていう問題が出てくる。
だからバインディングなんてものが出てきた。



・・・んだが、WPFもオワコンになってきたし、そもそもMSの公式ライブラリーだと完全なMVVMができねーんだよなあ
イベント駆動式で書いたほうが数倍効率いいのに、なぜかWPFではイベントは使ってはならないみたいな宗教があるのが怖い
やはり時代はWebアプリだよ。C/Sはオワコン。

何度もいうけどwebのアーキテクチャとは関係ないんだよ
まあ「クライアントアプリ」としてもいいけどそれはそのアプリのmodelがリモートでデータアクセスするだけの話だから

>>22
実質的にWin専用だから
マルチプラットフォームで動けとは言わないけどどの環境でも開発できる言語であってほしいわ

>>124
どういう原理(´・ω・`)？

>>105
>>109

え、まさかEnterprise版使ってるのにGitHubサーバーとGitHubクライアントソフトウェアの区別が付いてないのか？

ガラパゴジャップ規格が順調に終わってるようで何よりです

>>127
それ言うならRuby、特にRailsだって実質的にLinux専用じゃない。
そりゃWindowsでも動かないことはないけど、重要なgemが常にコケるし。

小さいWebアプリをWindowsで作ることは可能だけど、大規模開発したり、既にLinuxで動いてるRailsアプリをWindowsで動かすことはほぼ不可能つーか
自力でWindows用にコンパイルしたり、中にはgemをハックしたりしないといけない。

なんだWEBの話じゃなくてクライアントサイドの話なのか

>>130
まぁ一番シェアが多い言語はISO国際標準規格のC/C++/C#/Rubyでも無く企業独自ガラパゴス言語のJavaなんだけどな

まあRubyの影響力が少しずつ削がれていってるのは喜ばしい

Rubyも変態言語だから徐々に使われなくなる

サーバーサイドもNode.jsでフルJavaScriptにならんかな

>>117
こいつ、静的型付けの利点がわからないらしい

>>137
ぬるぽであっさり落ちる静的言語が何か？

>>138
その反論はないわw

Xamarinのステマか？
ライセンス高過ぎ

落ちるだけマシだわｗ
スクリプトは変な挙動で動き続けるからテストしてもバグだと気づかずリリースされる

>>139
静的言語だって動かしてみないと分からない
てことはテスト重要

>>141
そんなザルテストが君の言う大規模開発の現状なんだ
悲しいことだね

　
　　∧＿∧
　 （　・∀・）　 　 |　|　ｶﾞｯ
　と　　　　）　 　 |　|
　　 Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>__∧∩
　 ＿/し'　／／　Ｖ｀Д´）/
　（＿フ彡　　　　　　　　/ ←>>138
　

Backbone.jsみたいなもん？

動的型付け嫌う奴って>>141程度の理解だからアホ扱いされるんだよ

>>118
それただのMVCじゃん
Smalltalkの時と同じだろ

Ｒｕｂｙは個人向けでしかない

>>133
ダウトJavaはTiobeやsoftforgeで一度もシェア1位になった事は無い
どこソースだよ

動的片付けって言い方メッセージ型のオブジェクト指向言語に使われると気持ち悪いな
単に既定の動作がメッセージをオブジェクトが受けとって例外を出すって動作になってるわけで
Perlやらawk、javascriptみたいに実行時に型検査してる訳じゃない

Aが変わるとAだけじゃなくてA,B,C全部調整されるようなことがよくあるわけ
A,B,Cぜんぶ関係してた時に,ABCを個別に変更するなら問題なくても
ABC一気にいじるとめちゃくちゃになったりするわけだよ

だからVとMを自動で関連付けるっていうのは根本的に破綻したアイデア

動的型付け系の実行速度の遅さは異常

>>128
http://ja.wikipedia.org/wiki/%E5%A5%91%E7%B4%84%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
http://monobook.org/wiki/%E5%A5%91%E7%B4%84%E3%81%AB%E3%82%88%E3%82%8B%E8%A8%AD%E8%A8%88

>>151
自動で関連付けるバインディングなんてあるのか？
俺が知っているのは、手動で変数名をハードコーディングさせるやつだが

Backbone.jsでも大仰だと思っちゃうんだけど
もっとシンプルなライブラリないの？

>>138
コードコントラクトを使えばコンパイルエラーに出来る

>>149
https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY-of-Programming-Language

>>154
モデルのAが変わったら自動でビューのAの値が変わるっていうのが破綻したアイデアだとゆってる

>>142
http://search.yahoo.co.jp/search?p=%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B3%E3%83%B3%E3%83%88%E3%83%A9%E3%82%AF%E3%83%88

githubってオープンソースだったん？

>>158
じゃあ自分でビューを更新するのが正しいの？

>>158
更新したくないモデルはビューにバインドしなければいいのではないか？

>>161
もちろんそうよ
ビューの値が変わった時にモデルを書き換えるにしても
書き換えたモデルのストレージへの保存をどのタイミングでするかとか面倒な問題が入ってくるしね
全部手動が正しい

>>12
モルモン教だろ

MSがLinux用のVS作れば何の問題もない気がする

monoで仕事してる家具師おる？

>>163
モデルとビューモデルが分離してるのって保存タイミングを分離するためじゃないの？
モデルとビューを直結するからおかしくなるんじゃないの？

SSHで使えるCUI版MonoDevelopが欲しい。
できればEmacsのキーバインドで

>>166
UnityやPS4なんかを含めると結構いるんじゃね？

>>163
そのためのMVVMだと思うぞ？
MVCでもいいけど。
MVVMならModelとしてのやり方があってViewとしてのやり方があってその仲立ちをしつつView自体のことは知らないVM。
そうすることで個別のViewに対応したゴニョゴニョが出来かつViewは馬鹿で良く、それ故ユニットテストが出来ると。
今の旬はModelやVMのゴニョゴニョをRxでやりつつそれとReactiveUIなどのやり方でBindingにつなげる方法。

rubyは長年保守してるとinstance_ofだらけになって
静的言語でよかったじゃんとなる。

C#はJBossがないので論外。

Java最強

>>142
>>143
どっちが良いのか、って話してるのわからねーの？
よっぽど苦労すれば動的片付けでも不可能ではないに決まってるじゃんｗ
大体、テスト段階でわかっても遅いんだよね。
静的型付けなら実装中ににわかる。
まあ、動的言語でおきる不具合のほとんどはコンパイルの時点で弾かれるんじゃねーかなｗ

まあ、動的言語はこうやっていい加減でも動かせるんだから
プロトタイプを手早く作れるってことだけがメリットだね。
まともに開発したければ静的型付けは必須

>>172
ドロップボックスの中の人が動的なパイソンでも大規模なの作れるよって言ってたけど、そこで言ってるのがいやそれ静的のだったらもっと楽にできんじゃねーかって感じにしか読めなかったからな。

>>172-173
まあ将来どこまでやるかで適材適所だな。
Write once, run away.なら動的言語も悪くない。

Twitter社もPHP？Ruby？からJavaとScalaになってたね(´・ω・｀)
大規模になるときつくなるんかな？

>>172
xUnitとか知らないの？

あぁ、手作業でがんばってテストするレガシーなやり方が君の言う大規模開発の現場なのねｗ

>>176
ユニットテストの記述量の話じゃねーの？ｗ

>>175
大規模というか人の入れ替わりの激しさだな。
大規模はもちろん、小規模でも人材使い捨てな中小ブラック企業だと結構な差がでる。

Rubyは実際に広く使われるようになって色んな問題が露呈してきたから、
今後ちょっと心配だな

>>177
イメージで言えば、静的型付け言語はいわば、動的型付け言語で行われているようなテスト（の一部）を
実装者に強制しているような感じ

まともにテストコードも書けないようなレベルの連中が使うなら、静的型付け言語の方が上記の強制の分だけ
動的型付け言語と比較すれば品質が上のコードができるだろう（比較論なので、良い品質になるかどうかは
別問題）

つまり、動的型付け言語でまともにシステムを作れない連中には、静的型付け言語を与えたからといって
まともなシステムができあがるわけではない、ということ

大規模システム開発と動的型付けプログラミング言語の関係についてはこういう考察もある

「進化的プログラミング言語Common Lisp　ロボカップでの経験を交えて」
bit Vol.30 No.3（１９９８年３月号） pp.21-28
今では脱洗脳ですっかり有名になった苫米地英人先生の記事より抜粋

（中略）
７．　オブジェクト指向とダイナミック言語
（中略）
言語が動的であるということと，オブジェクト指向であるという事は，切り離せない関係にある．
例えば車というクラスのレベルで関数を記述し，
具体的な車種に関わる制約をメソッドとして記述するのがオブジェクト指向の手法であり，
これを具体的に活かすには，ランタイムに実際に車種が決まった時点で，
リアルタイムにバインディングされる必要がある．
これは動的言語でしか出来ない．

こうしてみると，ランタイムの動的束縛の出来ないC++は
オブジェクト指向言語としては本来は失格であり，動的型指定の出来ないJavaにも厳しいものがある．
C++においてはオブジェクト指向性はコンパイル時の最適化とコードの再利用程度の役割しか果たしていない．
Javaが動的型指定を出来ないのは，JavaVMの仕様の問題である．

（長いんで続く）

なにこれマジかよ

MVC終焉なの？

>>181の続き

８．動的オブジェクト指向と進化的プログラミング

Common Lisp のような本格的な動的オブジェクト指向言語が本当に役に立つプログラミングの
ドメインは，学生プログラマが気軽に手を出せるアプレットプログラミングではない．
何百万行というサイズの大規模システムの開発においてである．
それも，滅多に変わらない企業会計システムの開発などにおいてではなく，軍事システムや
銀行でいえばトレーディングシステム，また流通関連など，大規模でありながら，
日々仕様が変わっていくようなシステム向きである．
我々はこういったシステムに要求されるプログラミングを
エボリューショナリープログラミング（進化的プログラミング）と呼んでいる．
システムを止めることなく，プログラムの各部が日々変更されていくようなプログラミングである．

（長いんでもう一回続く）

>>183の続き

もちろん，本来 COBOL などに向いている企業情報システムにおいても，
最近流行の BPR（ビジネス・プロセス・リエンジニアリング）や，ワークフローなどを
導入しつつある，いわゆる戦略的企業情報システムなどへの応用では，リアルタイムに，
あらゆる視点，パラダイム，グルーピング等をダイナミックに変更しながら
仮説を立てなければいけないので，進化的プログラミングが必要である．
また，軍事システムでも，刻一刻と変わる戦況に合わせて，システムそのものを
動的に変更していくということも重要な要素である．
進化的プログラミング言語には，動的オブジェクト指向言語が必要不可欠である．
例えば，湾岸戦争中には，米軍の補給システムにおいて，Common Lisp が活躍したそうである．
戦争しながらリアルタイムで，システムを止めることなく刻一刻と変更することが可能であったのは，
正に Common Lisp が動的オブジェクト指向言語であったからに他ならない．
（後略）

↑
ということで、大規模で変化が激しいシステムほど
動的型付け（オブジェクト指向）言語が適しているという主張もある

>>182
釣りタイ
スライド読めば分かるけどデスクトップアプリケーションの話でGitHubサーバー全然関係無い

>>149
＞JavaはTiobeやsoftforgeで一度もシェア1位になった事は無い

別世界の方ですか？
Javaが一度も1位じゃなかった世界線の話はちょっと分かんないです

http://cpplover.blogspot.jp/2012/05/tiobe-index.html
＞先月から、CがJavaを追い抜いて第一位に返り咲いた。もっとも2004年のJavaの一時的な下落は、Googleの検索アルゴリズムの変更によるものなので、過去10年で初めて一位になったというべきか。

http://developers.slashdot.jp/story/12/04/27/0038248/
＞サーチエンジンの検索結果からプログラミング言語の人気度を評価する TIOBE Index の 4 月分で、C が Java を抜いて 1 位となった (TIOBE Index、本家 /. 記事より) 。

ゲハみたいなノリでプログラミング言語対立しなくていいってのw

Rubyでプロトタイプを作って、静的型付け言語でリリースするってのが
本来の姿だと思うが。

>>180
結局ユニットテストで記述量が増えるなら意味ないじゃん。

さらにコードコントラクト・契約プログラミングに相当する部分もユニットテストで実装する必要があるし、それだとコードレビュー程度ではテスト漏れもわかりにくいんじゃねーの？

>>187
ゲハは全部買っちゃえば全て解決だけど（ガジェオタの俺は全部持ってる）
言語は一生のうちにマスターできるのは数個から十数個だろ？
宗教戦争なるわそりゃ

>>32
確かにC#はC99に準拠していないが、そこはRubyも同じでない？

>>170
何が旬だよ
実現性のない空虚な観念論だからへんちくりんなライブラリ名を連呼して出来るような錯覚にひたれるだけ
テストしたものが正しく動くためにはVMとVがバグの生じることのない機械的な手続きによってつなげられなきゃいけない
それでは複雑な操作も使いやすいUIも作れないんだよ

>>189
意味ないの意味が分からない
コードコントラクトは別に静的型付け言語だけにあるもんでもないし

ちょっと前試した感じ、monoで.NET MVCは若干動作が重くて
同時アクセスキツそうだったけど…

>>180
動的信者は強制と捉えるんだろうね。
静的関数信者の自分にとっては少しでも間違えたらすぐ教えてくれるセーフティネットだわ。
普通の静的のmutableデフォですら拒否感があるのにそれ以上になんでもありな動的は無理ぽ。javascriptでプロトタイプ作ってあり得んと思った。

>>184
進化的にかけるのはイイけどランタイムレベルでそれができるのがいい場合がどれだけあるのかわからん。
上と同じだけど自由は不安定性と表裏一体なので。
エボリューショナリなことしたければそれをできるデータ構造やDSLを作れば言い訳でそうすればサンドボックス的に制限した進化可能システムができる。
想定外の進化は無理だけどそれが必要な場面がどれだけあるか。
人工知能とかで過度の柔軟性が必要ならメタの強力な動的ありだと思うけどね。

>>192
それ出来ないのは分離がうまくできない無能だからだよ(´・ω・｀)

Rxはイベントをより宣言的にかけるようにしただけで本質は一緒。

>>195
＞エボリューショナリなことしたければそれをできるデータ構造やDSLを作れば言い訳で
＞そうすればサンドボックス的に制限した進化可能システムができる。

確かにその通りだよなあ
組込みスクリプトエンジンで拡張性を増す
まあCommon Lisp自体がもともとそういうもんだとも言えるか

最後の「システムを止めずに」ウンヌンは実行中の環境に修正版をREPLで動的に上書きするような運用をイメージしてるんだよな
このへんはデータ構造やDSLによる拡張性とはレイヤが違う

C#様お願いします
JAVAを滅ぼしてください

>>198
なるほど

>>198
だね。レイヤが違うからこそ、各々でできることや向き不向きが違うわけで。

普通の企業システムでその動的実行イメージ切り替えが必要な場面がどんだけあるのかと。
多くは動いてるモジュールのローリングアップデートによる不停止でのシステム入れ替えで足りるしその方が間違いを犯す可能性が少ない。

むしろSmallTalkとかで動的入れ替えとかやってる企業とか、やらかしちまうことないのか聞いてみたい。

次のJavaからラムダ式が入るんだってな
Scalaっぽくなるのか？

>>192
「複雑なVと複雑なMを機械的にバインドするのは難しい」→「だから出来合いのライブラリに頼らずに自前で実装すべきだ」というようなことを言いたいのだろうけど、それは違うぞ。
俺はMVVMはKnockout.jsしか触ったことがないので他は分からないが、Knockout.jsだと標準的なバインディングの仕組みでは実現できないような複雑なMやVの為にバインディングのルールそのものをカスタマイズする仕組みがある。
というかむしろ標準のバインディングだけで出来ることはたかが知れている。何をカスタム・バインディングとして抽出して実装するのがKnockout.jsの肝だといえる。
複雑な問題だから毎回手で実装すべき、なのではなく、複雑な問題だからこそ実装に一定のルールを与えて簡単な問題に分割して考慮するべきなんだよ。

>>184
> 大規模で変化が激しいシステムほど
> 動的型付け（オブジェクト指向）言語が適している

くしくもアラン・ケイも似たようなことを言っていて
重視するところが違うと、静的言語の人と真逆の結論になるのが面白い。

「ソフトウェア工学」は矛盾語法か？ --アラン・ケイ
(もともとSqueakの宣伝のために書かれたエッセイだが、彼なりのSmalltalkの総括とも言える）
http://metatoys.org/oxymoron/oxymoron.html
> 早期結合なシステム(C, C++, Java 等)と比較して、遅延結合を使う事で、
> プロジェクト開発の遅い時期に得られた知見を指数関数的に少ない工数で
> プロジェクトに適用出来る。

もっとも、動的だからってRubyにも同じことが言えるかっていうとそれは間違い。
Lisp・SmalltalkとRubyとでは、同じ動的でも動的性の次元が違うので。

>>199
お願いするべきはmonoだな

MVCってヤツを勉強したいんだけど、なにから手を付ければイイの？

JAVAでSpring MVCとか言うヤツ？　スモールトーク？

>>206
おとなしくphpかrubyのフレームワークやれ

>>206
勉強して身につくものじゃないんだなこれが

いやMVCは勉強しないとダメだろ。

オブジェクト指向型言語を使ってプログラミングしてもオブジェクト指向型になっていると限らないように、
MVCのフレームワークを使っていても、プレゼンテーションロジックとビジネスロジックの分離ができてるとは限らん。
要は綺麗で保守しやすいコードを書く上での方法論だからな。

まあいくら理論的なことは知っていても結局コントローラーにビジネスロジック書いたりしちゃうんだけど。

ココまで読んだが全然意味分からん。
MVCってのは要は良くないってことか？
AndroidとかってMVCだよね？
違ったっけ？
C#は少しだけ分かる。

>>210
良くないわけじゃない
というか、銀の弾丸はないってことさ

>>211
あんたのレスで余計にわからんくなったわw
銀の弾丸ってどういうことさ？
どの言語も一長一短あるってことの意味？

>>210
Androidのフレームワーク自体にはMとVを分離するという考え方は無いよ。

>>210
はっきり言って普遍的な概念ってよりもたまたまその時代のその環境に合わせた書き方に
単にそれらしい名前付けただけだと思うぞ

しかも実際にプログラムするときは理想は理想として実際は厳密にはいかないんッスよーみたいな

emacs派は居る？

このスレで言ってるWeb向けMVCの抜本改善の話、十年以上前に情報システム板のフレームワークスレで説明した覚えがある。その二年後くらいにAJAXが出て、やっと世の中が動き始めた

当時フレームワークスレに来てた一人が、豆蔵創立者の一人だったっけ

情報システム板って、大手ソフトウェア企業板でしょ？　昔はそんなソフトウェアそのものについて語るスレがあったんだ？

結局.NETが10年先を進んでたんだよ
HTMLにJavaScript？なんで一から画面作らないといけないんだ
時間の無駄だわ

>>206
アルゴリズムとかは数学的な勉強法でいけるけど、
MVCは"この様に書け"っていう設計指針だから勉強はしにくいね。
学校とかで使ったこと無い脳みそ使う。
まあ作りながら覚えるものの一つ

>>214
同意。 基本的にはMVCの派生品程度の認識しかないなぁ > MVVM。

VMとは呼んでいなかったけれども外観無しのビューロジックだけを実装したテスタブルな
ビューにXMLで記述したUIデザインをデーダバインディングで貼り付けるなんてのはFlexなんか
では広くやられていたし。

SpringMVC等のウェブ向けのMVCフレームワークにしてもビューロジックの手続き的記述
の殆どは「コントローラー」に集中するけれども、ビジネスロジックをサービスやモデルに
追い出した薄いコントローラーは普通にテストできるよ。

>>218
各社の初期のフレームワークを調べて回ってる連中や、自分みたく研究開発崩れのアーキテクト志望の連中がいろいろ話してた。

JRubyが圧勝すぎる
http://www.infoq.com/jp/news/2013/10/jruby-9k

>>206
作法だからな…
あとそのフレームワークでは「できないこと」を如何に回避するかだな
フレームワーク使うとかえって工数増える気がするわ

MVCモデルの命名規則を厳格化してデータベーステーブル生成を自動化するって発想がどうも馴染めない

スライド全部読んだがどこにもRubyはクソとか書いてない

>>225
Hibernateが肌に合わなかったのならMybatisなんかどうよ？捗るぞ。

>>221
Flexはマイクロソフトが次世代JavaScriptとして開発したもの。
標準化の過程でネットスケープが激怒してポシャった。
あまりにもったいないのでアドビからFlush用の名目でリリースされた。

豆知識

>>228
賢くなったわ

rubyは言語以上にgemがクソ。
C#はnuget便利すぎだがmonoで使えないクソ。

Backbone.jsでの1ページだけのプログラミングがやっててなんか楽しい
RubyRailsってWindowsだと開発できないよな。だからオサレな会社行ったらみんなMacbookAir持ち歩いてるのか
Windowsのインストーラあるから勉強しようと試してみたがまんまと騙された気分

単純に速度の問題だろう

>>203
出来合いのものをカスタマイズして複雑なことを実現するよりも
自分がよく分かっているものだけを使って0から組み立てていくほうが間違いは少なくなるから

STLのアルゴリズム組み合わせるよりもfor文を書いた方が早くて単純で間違いも少なくなる
ミドルウェアは全部同じ問題を抱えてる

時代はDDD

UIはころころ変わるからテスト自動化しづらい

>>233
＞for文を書いた方が早くて単純で間違いも少なくなる
早いっていうのは同意だけど単純さとか間違いの方はどうだろうね
覚えるコストがかかる分だけミスが減るのがライブラリとかフレームワークの良い所じゃない

MVCだ、MVVMだ、と古い概念に縛られるヤツは今や老害。
これからはDDDの時代だ。

その証拠にプログラミングやってたらDDDの総本山stackoverflowを目にしない日はないだろう？

>>236
複雑になれば覚えるコストの方がどんどん高くなるし
だいたいブラックボックスが増えれば増えるほど融通が効かなくなって破綻に近づいていくんだから
ミドルウェアの複雑なカスタマイズ規則を覚えて複雑な機能を実現しよう！　
みたいなことを言い出したらもう妄想に取り憑かれてると思っていいわ

なんにしろそういうつまらない作業はやりたくない

>>216
2000年位にはすでにXMLHttpRequestは存在してた。

>>240
くだらん薀蓄だ。
それ以前から標準ブラウザ環境で
追加アドイン無しでインタラクティブ
なアプリが書かれているし
自分もフレームワーク作ってた。

>>239
1996年当時の最新研究テーマだからなぁ。いまさら面白味があったらこっちがビックリするわ。

その一つ前は、人工衛星で観測したデータや画像をインタラクティブに表示する
地球環境ブラウザ。
Google Earthが出た時、みんな同じテーマやってたんだって感慨深かったなぁ

>>210
guiアプリじゃmvcは不適切でmvvmを使うべきというのがgithubの人が>>1で言ってる事
そもそもmvcってマーティンファウラーの説明なんかでも非常に曖昧で、人によって解釈がバラバラ
guiアプリを作る時はmvcはバッサリ忘れてしまった方がいい
ただし、ウェブのサーバーサイドなら話は別で、ウェブmvcは有効
mvvmを提唱したmsも、ウェブにおいてはaspnet mvcってウェブフレームワークを推奨してるぐらだから

>>243
じゃあ今は何を先取りしてんの? ちょっと教えてよw

学問的な最先端はマルチスレッドとかじゃない完全な並列システム。つまり脳。
工業的な最先端はGPGPU的なやつ。

IBMが出してるねニューロンチップだっけ
日本の大学レベルでやれる事は、
すべて実用化されてモノがあったりする
基礎研究とかならまだしもね

>>58 >>110 >>185 >>226
嫌信にはやたら xamarin 信奉者がいるのかしらんけど
土日にこういうスレ立ててるのがいるな･･･

>>244
knockout.js作者はasp.net mvcの責任者。
豆知識

>>244
情報が古い
ASP.NET MVCはオワコン

今はMVVMなASP.NET SPA

>>246
工業分野ではGPGPUはFPGAにボロ負けして消えそうになってるがな
OpenCLもFPGA対応が最近のトレンドだし。

>>238
DBは難しい問題だ。
ただ少なくともORMは無理があると思うのは確か

>>251
OpenCLは元々CPUにもGPGPUにもFPGAにも対応するように規格作られてるからトレンドじゃなく数年前からの既定路線なんだよな
nVidiaがCUDAで無駄に業界を引っ掻き回しただけ

>>235
それはあるな
UIのテストってみんなどうやってやってるの？

>>231
rubyは互換性がな
Linuxの同じディストリでもマイナーバージョン違いで動かないとかザラだし

動的、静的、コンパイラ、インタプリタ、オブジェクト指向、関数型
そういうのが合体した決定版の言語があればいいのにな(´・ω・｀)

そしたら、簡単に書けていいな〜＾＾、あっ、これこのままだとヤバイんじゃね、別の言語で書き直し！
みたいなことがなくなるのに(´・ω・｀)

>>256
C#5.0

GPU高いスループット
FPGA低いレイテンシ

使い分けじゃない？
計算量が少ないならFPGAのが強そうだが

>>256
C#もC++みたいになってきたな

C#なー。monoがもっとハッテンしてくればいいな。

C#おしてる人はC#じゃなくて.netじゃないの？
純粋にC#の文法が好きなのか？

C#の文法も好きだし
Visual Studioは言わずもがなの最強IDEだし
ザマリンスタジオも悪くないよね

嫌儲でMono推しの人は何者なんだよ

これからcakePHPを勉強しようとしてる俺にとって吉報？凶報？

>>261
殆ど.net=C#だろ
あえてVB.netとかIron〜とか使う必要あるの？

非.NET環境でC#使ってるけど
やっぱりC#はいいよ

.netは完成度は高いけど平凡なライブラリ
別にJavaのライブラリでもいいわけだし

>>264
サーバーサイドの話じゃないからcakePHP使いたいなら使えばええ
>>1のスライドはクライアントソフトをmacで作りたいならどうこういう話。

>>264
会社命令？
違うならCakePHP選ぶ時点でじょうよわだよ？

>>265
少なくとも日本じゃVB6はシェアも大きかったし、その流れでVB.NETもシェアはある程度ある

池沼ruby厨噴死ｗ

何でお前らプログラム系のスレではガチなんだよ

おっしゃあああ！
今年一番の朗報だはw

>>271
単純にプログラマーが多いんだろ

さらっと作るならphpで充分過ぎるだろｗ
なんで敢えてRubyみたいなマイナー言語を使わにゃならんのか理解できんわｗ

そしてC#は最強。なんだかんだいってもMSの開発環境は至高

スレタイ速報だったわ
しかしサーバサイドgithubもruby捨てる方向で動いてくれんかね
php移植でもscala移植でもscheme移植でも良いから
運用コスト糞高いんだよ、あいつさ
小型サーバで動かないとか実験もできん
git環境にしたいのに

>>274
言語までしかわからん奴は理解するの厳しそうだな
ある程度規模のrailsの開発速度は尋常じゃない
言語で言っても文法は芋臭いけど、ruby単体の練られ方はphpの比じゃない

ただ、それも殆どrailsが無理矢理何もかもメモリに載せようとした結果ゴミになってる

>>268
じょうつよは何を選ぶんだよ

まつもと涙目ｗ

スライド適当に見たけどC#に移行なんてどこにある？？

まつもと怒りの引越センター開業

>>277
じょうつよはPHPを卒業するか
Laravelを使うよ

>>256
F#がかなりそれに近い(´・ω・｀)

>>282
動的言語では無いだろ

ググったらOzってのが色々ごちゃ混ぜにした言語っぽいな

ruby信者必死だなｗ

>>277
ServiceStack

土方の俺たちはこうして日頃の鬱憤を晴らしています。

phpの方がマシなレベル

>>63
ほんとこれ

>>69
ほんとこれ

>>276
rubyの言語が練られてて素晴らしいとか言ってるけど、結局自己満の世界で見難いんだろ？
意味ないじゃんｗ

言語なんかどうでもいいけど、「言語としての美しさどうのこうの」とか言い出す言語にロクなもんはないｗ

それにrailsありがてえありがてえとか言ってるけどさ、Webに関しちゃphpの即実用性に敵うもんはないだろ
妙な信者うるさいし。つまり存在自体が邪魔で無用な言語ｗ

rubyの可読性の悪さは異常

>>159
ほんとこれ

railsはクソ
開発環境と実行環境が完全に同じでないとまともに動かない

* 今のRubyを作ったのは、何十人もの開発者ですよ。私は1人目の開発者だったに過ぎません。[1]
* 問題を解くのが好きなだけで、プログラミングは大嫌いです。[2]
* いかにプログラミングを避けるかを考えていたら、コードを再利用するためのツールとしてRubyができました。[3]
* Rubyは、歯ブラシみたいなものですね。毎日使うものですけど、だから何でしょう？誰が歯ブラシの本なんて読みたがります？[4]
* パーサーを書くのは苦手です。本当にダメなんです。今でもね。[5]
* Rubyには「protected属性」も「仮想メソッド」もありますよ。情報学科の教官が「重要だ」っていうやつは何でもね。僕自身は、こんなものどうでもいいと思ってますけど。[6]
* プログラミングを好む人がいるのは知ってますが、全く理解できないですね。[7]
* 僕はホンモノのプログラマではありませんから、やっつけ仕事ですよ。ホンモノのプログラマは、「動いてるように見えるけど、メモリリークだらけじゃないか。直す必要があるかもね」なんて言うでしょう？僕なら、10リクエストごとにApacheを再起動しますね。[8]
* いえ、メモリリークはちゃんと気をつけてますよ。でも、プログラミングってほんとクソだなと思いますね。[9]
* プログラミング言語を作るつもりはありませんでした。どうやって作るのかも知りませんし。論理的に必要だと思われるものを足していっただけなんです。[10]
* 僕の発言に怒ってる人がいるようですね。僕がプログラマとしてひどいのは認めますけど、でも、多分あなたたちよりマシだと思いますよ(笑)。[11]

>>295
これ元ネタはPHPじゃなかったか？

>>292
オナニー言語だからな
自分で書いたものですら半年後には意味不明になってる

>>291
なんで使われるかって言われたから使われた理由言っただけだがな
rubyで書かれたコード読みにくいってのは単に読み慣れてないだけだと思うが
だがそこ以外についてはほぼ同意だな
railsはゴミだし信者はキモいしロクなモンじゃねえ
言語として練られてるって言ってもphpより幾分マシなだけでわざわざ選ぶ程でもない

webでmvcとか悪夢でしかなかったからこの流れは歓迎だな
大体httpで何もかもやろうとするのが間違いでクライアントでスクリプト使えるなら活用するのが当然だは

なんで1日経ってからスレタイに釣られる情弱速報スレになってるの

糞スレ終了

必死なRuby信者を煽って遊ぶスレだからなｗ

rubyはない

LOL

>>69
windows serverってメモリ512mbでも動くよ
起動もすごく速くて、rhelとかubuntuとかの一般的なlinuxより断然速い

Silverlightのmono版のmoonlightって消えた？

>>283
だから、近い って言ってんじゃん