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

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

知ってた

俺みたいな底辺IT土方はMVCで十分です

良く分からないから
コスモスストライカーに喩えて教えて

MVVMはMVVMで地獄だぞ
MVPVMでもまだまだ酷い

つまりLinuxみたいなもんだろ？

日本語でおk

C#なら俺でも書ける。

IT業界離れた暫く経つが
言語の種類全く聞いたことすら無くてワロタｗｗｗ

オリバーソースが関東にないと知って激震する大阪から出張した人

Silverlight最強伝説

そりゃ、ボランティアで1から書き直す奴はなかなかいないだろって

よくワカランが、データバインディングを自動でやってくれるから
開発が楽になるよ、ってことでOK？

MacとiOSのアプリなのにC#なのか

WPFそんなにいいのか

PythonならRubyの限界を突破できると思うぜ

>>16
やだよあんな変態言語

>>15
MonoだからWPFではない
対応していないし

>>14
Objective-Cは高純度のクソ

Rubyとか何の役に立つんだw
とっとと滅びろw

Ruby始まる前に死亡でワロタ

>>13
MVVMは途中参加した人が理解しやすい。
ずっと同じメンバーで自分の担当分だけやってるなら関係ないどころか面倒なだけどね。

で、数年後に、MSに梯子を外されて途方に暮れる (wwwwwwwww
標準規格化が進んだところで、金玉握っているのはMSだからな

プリミティブな部分はともかく、一見便利な、ライブラリ群、コンポーネントを調子こいて使うと泣きを見る

時代はJavaだろ
C#もいいけどJavaだ

LISPの時間だあああああああああああ

Microsoft嫌いだからJava一択

++++って、そんなにいいか？

>>23
Monoだろ。外される梯子なんてない。

GitHubのユーザーが増えて
rubyでは負荷に耐えられんのでは
twitterとかもそうじゃなかったかな

正直Rubyはないわ

RubyやるのならPHPやるわ

LL系言語での開発はDBを骨にして成り立っていると思うんだよね。
スキーマを離れると途端に難しいことができなくなる。
やっぱりscalaとかだよな。

Linux + Monoって結構いけるもんなのか？
安定性とか謎すぎる

まつもとゆきひろの性格が悪すぎるからかな

>>19
食わず嫌い

>>31
Railsやれ

そもそもGitHubが何なのかわからんけど

つーかクライアントアプリ側の話しじゃねーかよ
相変わらずニュー速は自称プログラマしかいねーな。

>>37
おめーrubyだのC#だの言う資格ねーよ

>>31>>37
ワロタ

そもそもJavaてなんですか
僕はコーヒー少し呑むていどなんですが

GitHubって日本語あったっけ？
よく日本製のRuby使ってたな

>>26
C# の開発者http://en.wikipedia.org/wiki/Anders_Hejlsbergはかつてはコンパイラ2強の一つであったBorlandのエンジニアでTurboPascal/Delphiを生み出した異才そのセンスのよさはJavaの比ではない

PHPの記述の仕様がすき、
RubyきらいRailsやる以前の問題だ

PHPもJavaもCの記述真似してるだけ。
そこに哲学なんて無いんだけど？

MVVMっていうけど、結局CをVMって呼んでみましたーぐらいのことだよな

新たな産廃豚がこうして創り出される訳よね

c java php ruby python 一通りやってきたけど
やっぱcが一番いいわ

最近githubちょいちょい落ちるしな

チームでやる分には便利そうなんだけど
これ趣味で一人で開発する分には
なんかメリットあんの？<- GitHub

WPFじゃなくてもMVVM生きるのか
ASP.NETとか対応してんの？

>>51
JavaScriptのknockout.jsが熱い
モデルとコントローラーはサーバーサイドで言語不問、ビューモデルはJavaScript、ビューはHTML

VB4.0のころからVB一筋な俺には全く縁のない世界だなｗ

>>46
その違いは、MVC => MVP => MVVMの流れを理解すれば分かる
>>50
個人でGitを使う利点は「戻せる」、GitHubを使う利点は「Prj管理できる」じゃないかなぁ…
まぁ極小規模だったらどっちも要らないが、ある程度の規模ならあればあった方が楽。
>>51
パターンだからライブラリがなんであれ無理ではない。
制限は大きいが一応WinFormでもMVVMは可能。ASPはシラネ

>>52
jsでコントロールするからVMっていうけったいな呼び名になるのか

>>50
趣味でプログラム書くやつなんておらへんやろ

>>52
おー　これ凄いね

Document View ってのもあったなー

>>56
んな事ないだろｗｗｗ
俺趣味でやってるぞ
本職はプログラマじゃないけどな

ツイッター社の、サーバーのプログラム言語は何なの？
ギーク気取りのえろいひと答えろ

ってかKnockout.js ってマジ凄くね？
これ何覚えればいいんだ？
WEB系全くやった事ないから想像つかん
WEB関係者教えてたもれ

>>54
うわー俺MVCで頭止まってるわorz

男は黙ってアセンブラ

>>50
GitHubはオープンソースプロジェクトのように他人にコードを見せる必要がある場合は個人開発でもメリットはある
クローズドソースならGitHubを使う意味は全くない。普通にGit使えばいいだけ

>>60
Scala

>>63
そこはマシン語だろ

趣味で必要な部分はPowershellで済ませる俺はゆとり

>>50
githubはfacebookやtwitterと同じソーシャルサイト。
唯一の違いはソースコードのコメントで語り合う点。

SNSって考えた方がいいか
自分のやってるマイナー言語で困った事とかググったりすると
２ｃｈよりこのサイトがヒットする事が増えた
日本語になるともっと便利なんだけどな

まずwpfがもうない

何で何種類も言語が必要なんだ？
出来上がるマシン語はそんなにかわらないだろ

>>71
そりゃ自慢したいからに決まってるじゃん

>>71
用途、書き味

FacebookはPHPをCに変換するライブラリーを自作

TwitterはRubyから分散処理に強いscalaにのせかえRubyというよりRailsのオーバーヘッドが大きいと思われる

>>68
サンクス
github自体は何の言語なんだろうね

githubは分散型構成管理だよね、++++にそんな芸当あると思えないけど違うのかな

>>71
保守運用からの答え

>>71
俺の場合はメジャー言語は
どれも肌に合わなかった
職業でやる分にはどれか覚えなきゃならないんだろうけど
趣味でやる分には肌にあったマイナー言語がしっくりきたわｗｗｗ

YHVHスレか

どうせ大人の事情で「限界だー！」とか理由をつけて変えただけなんだろ

お前らが何語ってるんだかサッパリ分からなくてワロタ
IT業界の人間って凄いんだな

C++でWTL使ってフレームワーク作ってMVVMやってる。

>>77
マイナー言語ってライブラリはどうすんの？

初戦はささやかなレッテル貼りの情報工作戦の積もりなのです

>>82
作るんだよ

オープンソースなんだからべつに言語なんかなんでもいいだろ
別にRubyでのソースを今後使っちゃいかんわけでもあるまい
Rubyを使いたい奴がいれば別のPJでRubyでの開発すればいいだけだ

>>84
そこが一番重要な点だろ…
ライブラリを自力で作るとかどれだけの手間がかかるんだ
例えばHTTP通信のライブラリとかRFC読むところから始めなきゃならんし

>>86
そういうのがしたいなら
そういうのが得意な言語でやればいい
今やってる言語はそういうのは得意で無いっぽいから
knockout.js見た時に素直に面白いなと思った

モルモン教を捨てたか

>>86
趣味でやってるヤツには何を言っても無駄だよ…
そのライブラリをつくる苦労も楽しみだといわれると返す言葉はない。
プログラミング自体が趣味といわれると工学的な話をしても意味ないしね。

C/C++, C#, Java, アセンブリ, JavaScript
はやった。

今後需要のありそうな（儲かりそうな）言語は何かな。

みんなでVVVVVVやろうぜ

>>91
昔ながらのホームページ（）はそんな感じだな

たぶん職業でプログラムやる人は
お金貰わなきゃならないから顧客に対して魅せる（見せる）必要があると思うんだ
だから顧客の要求に合わせて組んでいく　ある意味
辞書の逆引きみたいな感じでライブラリ充実した言語が良いんだと思うんだけど
趣味でやる分には　自分がやりたい事に対して
どう組んでいくか考えるから　あんまり辞書の逆引きみたいな事は必要ないっつーか
まぁ充実したライブラリ見て、インスピレーションを得るみたいなのはあるかもだけどね

>>93
色々な言語やライブラリ知ってるのは大事だよ。
目的に対して遠回りしてる事にも気付かないでしょ。
時間も無限じゃないからコスパ発揮しないとさ。

>>74
facebookってずっとpythonだと思ってたが何か勘違いしてたのかな
つーかphpをcにって笑えるｗ

>>94
意外と「他人に見せてゴニョゴニョする（させる）」
ってのをすっぱり切れば
そんなに遠回りにならないと思う

>>94
趣味に遠回りもコスパも関係ないさ。
遠回りもまた楽しみでございます。

ruby最高だろ
JAVAとCしかやったことなかったから、便利なメソッド多さに驚いたわ

CとJava+SQLとC#+WPFとshell script/batの４つがあれば基本的に足りる。

俺はCOBOLでこれからも頑張る

最近Qtに興味あるんだけどどうなの？

趣味でも一応作りたいものがあるわけじゃん。
文字列処理の弱いCでwebアプリを作るとか狂気の沙汰だけど
Cしか知らん人は、PHPやRailsとかの選択肢が出てこないんでしょ。

好きな言語でメシが食えたら
プログラマとしてこれ以上の幸せは無いんじゃなかろうか？
俺はとっくに諦めたけど
あんなにCが好きな奴が居るとは思えない
だからこそLL言語に人気出るんだろうし

>>103
俺はC++大好きだしC++で食ってる。
たまにCだけで書かなきゃいけないときは苦痛。

>>102
過程を楽しむんだから結果はどうでもいいんじゃないの？
山登りで苦しいルートを踏破するみたいな達成感もあるしさ。

CもWEBアプリも（今の所）興味無いから
あまりピンとこないな
プログラマでは無いけど仕事で自分の仕事を他人にやらせるツールとして
Knockout.jsは使えそうだなとは思った

オープンソース信者のプログラマって何で生きるつもりだったの？

>>93
>たぶん職業でプログラムやる人は
>お金貰わなきゃならないから顧客に対して魅せる（見せる）必要があると思うんだ
全然違う
その発想は、お前がフリーソフトに求めているもので、顧客のほとんどは法人でサラリーマンが仕事で使う
だから魅せる必要なんてまったくなくて結果の出力だけが求められる
仕事でソフトを操作「させられる」人はソフトを操作する時間が少ないほど喜ぶ（なるべく見たくも触りたくもない）
導入を決定する経営者に対しては、目的を達成するために掛かる金額の安さが響く
開発側は安くしたくないから機能を盛って金額を上げようとする
儲けるには素早く作る必要があるから、同じことを少ない手間で作れるものを選択する
どう作れば効率よく完成させられるかを真剣に考える

shell script,C,phpこの組み合わせが最強

はあ、ヤバいな、時代についていけてない…
未だにMFCとC++だと時代に取り残されてしまう

モデルの分離を実現したいなら言語側に一つのクラスのうちどのモデルに共有させるメンバーかを
宣言するためのキーワードや、モデルレイヤーでグローバルかローカルかの指定ができたり
しないと、現状のまま個人個人が設計をきちんとやりましょうっていう提唱で終わる

>>104
過程を楽しむのもいいんだけど、成果物がないと
一人でパズル解いてるみたいになっちゃう

>>106
jsのフレームワークてwebのフロントエンドで使うもんじゃないのか

>>108
結果の出力だけが欲しいなら
まさに俺が趣味でやってるのと同じじゃん？
でもGUIなんて作らないよ
めんどくさいから
でも他人が操作する分には作らざるを得ないでしょ
そーいう事

>>108
まあそうだけど、納期に間に合って動けば勝ちだよね。
中身がスパゲティだろうが汚いソースだろうが非効率だろうが。

>>93の言う「見せる」は動いてるところを「見せる」なんでないの？

MVVMってなんやねん

MVCとかMVVMとかこうやってどんどん新しい開発手法出してくんのやめてくれない、マジで

>>115
Model View ViewModel

>>115
MSとXamarinの戯言
VB6のほうがマシだろ

>>113
お前がめんどくさいように、使うやつもめんどくさいんだよ
ソフトに対してポジティブじゃなくて、基本ネガティブなの
でっかいウィンドウにでっかいボタン並べただけの画面で各機能１クリックでいい
魅せる要素なんて一切皆無
ショートカットで実現できるならデスクトップに作成すればGUIすら求められない

>>119
それで顧客って納得するのかな？
俺の作ってるのって君が言ってるように
まさにボタン一つ押すと勝手にお金を稼いでくれるプログラムなんだが
こんなのに需要あると思う？　聞いただけでただの詐欺だろって思うだろ

>>119
レス見てるとなんかソフトに対する愛情が薄い
ソフトだからできる付加価値とか考えたことなさそう

>>119
お前向いてないわ。
基本ネガティブなメーカーの電気製品使いたい奴なんかいない。
自分で思い込みという罠から逃れられないだけ。

>>114
>納期に間に合って動けば勝ちだよね。
短期的にはそうね
ただ客も導入時の出費は覚悟してくれるけど機能追加時の出費は渋るからね
その後の利益率維持を考えるときちんと作れるようにせんとね・・・

あー営業さんか。

プログラムって入門書一冊やった後何すれば良いかわからん
独学で仕事で使えるレベルになるのは無理なのか

そもそもJavaScriptなんてプログラミング言語とは言わんだろ
ましてやhtml書いてコーディングとかこいてるやつとかもうアホかと

>>126
JavaScriptは舐められてるけど大した言語だよ
最近は大分見直されてるけど

>>125
こういうの見ると
プログラミングのソムリエみたいなの
居ても良いなと思うんだが
聞いた事無いよな

>>123
それはもちろん効率的にきれいにつくれたほうがいいんだけど
なかなかその余裕はないからさ。

最近はリファクタリングってな便利な言葉ができたから、ぼつぼつ
きれいにしていくってのもありな世の中になってきたよね。
（金出してもらえるかはいろいろだろうけど）
でも動いているものをいじってテストしなおしってのもそれはそれで
めんどくさいとは思う。

やっぱ最初からきっちりやれるといいよねー。
総合テストとかやってると全部最初からやりなおしたくなる。
でもその時その時はせいいっぱいやれることをやってるんだから
それはそれで仕方ないかなと思ってる。

>>125-126
ﾊﾞｶがやる仕事だから
ﾊﾞｶでもﾁｮﾝでもできるようにしないといけない

ﾎﾝﾄ、ﾊﾞｶだなｵﾏｴﾗ

>>125
むしろ独学が望ましい。
仕事でやり始めた奴は、好きでやってないから大成しない。

とりあえずwebアプリでもゲームでも作れば？

>>120
動かすだけで儲かるソフトなら売る必要なんかないんだよ
転がすだけで儲かりますっていうものを売る必要があある時点で矛盾してる

>>122,123
毎日やりなれた仕事の手順を変えるように迫られるのは誰でも嫌がる
法人向けだと経営者がレポートなどの情報ほしさに日々の売り上げを
紙伝票からPCに打ち込みもするように追加作業を従業員に課す
そのソフトの学習で残業し、これからやらなければいけない仕事も増えるから嫌がる
業務効率化を狙ったものでも最初は使い慣れなかったりして最初は抵抗される
それのおかげで仕事が早く終わるようになれば次第に受け入れられていくもの
電気製品は民生品だから法人向けのように使いのが義務じゃないからポジティブなもの

>>120
書き込みを見るに
他人に議論ふっかけるにはちょっと背伸びし過ぎだと思う。

>>132
儲かるじゃないけど対会社なんかだと
コストが減りますってのがあるだろ
ボタン一つで１００人の人足が要らなくなりますって言うソフト作ったとして
それ売れると思う？
そのソフトの採用担当が１００人の中に要るだけでアウトだと思うが

>>132
業務を変えない努力も結構だけどさ
業務を楽にしてやろうて所まで踏み込むべきじゃないかな。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
ｵﾍﾟﾗでも楽天にﾛｸﾞｲﾝ出来るようになるいう事やな

>>133
別にふっかけて無いよ
俺は職業プログラマじゃないから
彼らが何をやってるのかマジで知らんし
ただ、想像はつくからそれが背伸びと見えるのかもしれないが

>>124
俺は趣味でも仕事でもプログラム漬けの開発者だぞ
vectorでフリーソフトもいくつか公開してるしな
昔はプログラムを高速化したりするのが楽しかったが
いまは設計レベルでいかに効率よく美しい構造にできるか
そういうほうに楽しさを感じるようになったね

>>119
いやいや、オペレーターは決裁権なんか無いからどうでもいい。
偉い人がビックリするような他社にない機能が無いと売れない。
グラフがフニョニョニョってアニメしながら表示されたり、
iPadとかで今風のインターフェースで操作できたりとか。

>>135
貴社にはそういう前向きの提案を期待しております（ｷﾘｯ!）

>>137
職業じゃないから以前の問題なのよ。
職業でやってるかどうかと技術力は関係ないしね。

>>138
アントニーホーアが
ソフトウェアを設計するには2通りの方法がある。
1つはとてもシンプルに設計して、明らかに欠陥がないようにすること。
もう1つは、とても複雑に設計して明らかな欠陥がないようにすることだ。前者の方がはるかに困難である。

こんな事言ってるけど効率よく美しい設計ってムズい？

>>135
業務を変えない努力なんて必要ないよ
より効率よく楽に出来るならその方向に変えていけばいい
経営者にはそういう方向でアピールするけど、経営者はソフトには触らない
実際に触るのは変化を嫌う労働者
だからソフトは変化を嫌がる労働者目線で作るからなるべくシンプルにする

>>141
それはあるんじゃないかな
趣味でやってる分には
技術力なんて他人に評価されないからな
自分が納得すればそれで良いわけだし

普段他人に評価され無いからといって
２ｃｈで議論ふっかけるなってのも
おこがましいと思うぜ？

>>143
そうなんだけどさ、最近思うんだよ。
それで実際の利用者目線ばかりでやってると進歩しないし、ほんとに詳細な機能をつけるのに
苦労するってことになる。パッケージにあわせるなんてもってのほか。
そんなことをいつまでも続けてていいのかなって。

>>143
正しい
業務アプリにとっては、一画面一目的のシンプルなUIが最も重要

業務を変えるなんてのは、システム全体でやることで、アプリケーションの
画面をいじることで達成することじゃない。

他人に評価？そんなの日本人だけだろ
アメリカ人なんか自由にコードかいてるぞ（笑）

>>144
最終的には自分の好きな言語でやっていければ良いと思うよ
JavaだのVBだの下らねー言語やってるのも、流行ってるから仕方なくだしねえ

同じプログラマでも
>>1こういう変化を歓迎してる奴と
変化を歓迎しない奴に分かれてて面白いなと思う

>>132
＞毎日やりなれた仕事の手順を変えるように迫られるのは誰でも嫌がる
嫌がるよね。そこを助けるためにやる仕事じゃないの？
帳票出れば利用者は助かるよね。
操作方法だって打ち合わせで現場から吸い上げたものなら黙って使ってくれるよ。
自分たちのワークスキームをエンジニアリングできてないだけだと思うけど。

匿名の書き込み同士だからいたわる書き方してないけどね。

>>144
見当違いのことばかり書いてて議論の相手と話が噛み合ってないからだよ。
レスされる方にとって時間の無駄って感じがする。

>>125
まず小道具でもいいから作って『完成』させることをお勧めする。
重要なのは、完成。つまり分からない部分や問題を迂回せずに、全て真っ正面から解決すること。
後は徐々に大規模で複雑な物、やったことのない技術、座学で学んだ手法を取り入れたものを作っていく。

プログラミングを「学習と教育、成長」と考える人がいるが、それは一面として正しい。
多くの問題を解決して技法や考え方を理解することで、それらを応用しよりよいコードを書くようになる。

画面とロジックを分離する（ﾄﾞﾔｯ）　から始まったんだろうけど、
アホみたいに分離しやがって
どんだけソース読むのがめんどくさくなってるか
わかってんのかアホが
set/getが大量にあるだけのソースとか見るだけで吐き気がする

>>151
それは君がスル―すればいいだけじゃね？
あと君はエスパーですか？と問いたい
他人が何を思ってるかなんて当人しかわからんだろ

>>150
わ、わ、ワークスキームをエンジニアリング???
なんとなく意味はわかる気がするけどまたすげえオトナ語に見える。
なんかかっちょいい。今度使ってみよう。

デザイナがView作れるようにするって言ってる環境で
ただのデザイナがデザインできる環境を知らない。
結局プログラムもある程度知らないとViewも作れん。

>>153
あ、それあるよね。
汎用性汎用性と言い過ぎていらんもんたくさんつくる人。
Javaの初期にたくさんいたよ…
いらんもんだけならともかくSQLでそれを徹底されると
1つのSQLですむとこsetが列数分で列数分のSQL発行してて
古いオッサンの俺はめまいがしたことがある。

>>142
目指すのは当然前者
関数がシンプルでどこでも使えるものなら便利なように
アプリケーションの機能レベルでもそうなっていることがいい
MVCにしたってシンプルにしようと試行錯誤した結果だし
それを知る前から多くのプログラマーが似たようなものは作ってた
仕事ではMVCやMVVMでやるけど、趣味ではより自分で工夫したやり方を考えてソフト作ってるよ
綺麗に作れたときには脳汁でるよｗ

>>157
オブジェクト指向丸呑みにしちゃうとそうなるのかねえ
ゲッターセッターとか意味判って言ってるのかて思う

>>90
言語自体で儲かるとか有るの？
何を作ってどう売るかじゃね？

請負だったら単純に発注状況調査すればいいだけじゃね？
他の人の調査結果を鵜呑みにしたら本当はニーズが殆ど無いかも知れないんだが

>>154
気づいてなさそうだから教えてあげようと思って。
余計なお世話だったら申し訳ない。

>>160
もちろん何を作るかが最重要だけど、
例えば今N88-BASICの知識があったって職はないだろ？

データバインディングの列挙がめんどい
仕様書書いたら、データバインディングのコードまで書いて。

もちろん仕様書修正したら、即反映してね。

ジョジョで例えて

>>158
おっ　ム板では同じスレに要る気がしてきた

まともなMVVM実装ってWPFくらいなもんだけどXAMLを何とかして欲しい
XAMLの可読性も低い上にXAML側にロジックが入りまくりでダサい。

>>153
MVVMの動機はソレ。目的は自動テスト導入やデザイン/コーディングの分離。

VMは画面を抽象化したモデルであり、画面の構造や挙動を表している。
複雑な画面ならget/setが多いのは仕方ないかもしれない。
逆に表示項目に対してget/setが多いなら作り方を間違えている可能性もある。

あと、トータルで得か損かが問題。MVVMでUTが楽などの恩恵がないならやった奴はタダのアホ

ORマッピングもそうだけどさ
インピーダンスミスマッチの解消にどんだけ時間割いてるんだよ
椅子の座りがちょっと悪いくらいの事だろ
こんなもの放っておいて世の中の役に立つ研究しろや

>>162
だからアプリ作成の請負だったら市場調査すればいいだけじゃねってこと

作ったアプリをどう売るかとかどうサービスするかを考えたら
それらの制約で選択肢が限定されたり
逆にどれでも良かったりする

>>164
日本出身の空条承太郎とスタープラチナに限界を感じ
アメリカの犬であるイギーとザ・フールを採用した

C、C++、C#、Delphi、
どれが一番実行速度が速いの？

>>171
CとC++

>>157
あまりにつきつめすぎるとそうなるみたい。

オッサンな俺は性能ってのを第一に考えるんでオブジェクト指向とぶつかるとこも多い。
CPUのコアは増えるしメモリも増えるって考えると、そういうことを意識しないのが
今風で美しいし理想かなとは思うけどどっちも無限ではないからさ。
後でチューニングしろって呼ばれてもどうしようもないことも多いんだよね。

C#ってMacで動くようになったのか

>>168
ORMなんて死ねばいいんだよ。
こいつのために全テーブルに主キー列としてidを儲けるなんて愚の骨頂
クソすぎる。

>>164 ストレイツォが人間の限界、DIOへの憧れから吸血鬼になった

>>173,157
必要なのは汎用性ではなくDRYや疎結合なんだけどねぇ
そういう人は手段と目的が逆になって、
オブジェクト指向で遊ぶことに夢中になっている。

Microsoft Visual Cが
Microsoft Visual Virtual Machine
に変わっただけだろ

大した違いはない

結局モジュールの使い勝手と生き残り度見ると
JavaとCが残るんだよなって気がしてた

正直
アップルとマイクロソフトとアドビとぐぐるの闘いとかホントうんざり

>>157
汎用性の追求と依存性の排除の原理主義者になるとそうなりやすい
最終目的は少ない手間で理解しやすく修正がしやすいものであればいいからね
JAVAはガチガチな言語だからJAVA専門プログラマーなんかは陥りやすいと思う
そういう人にJavaScriptやらせると、カプセル化しようと必死になってJSのいい部分を殺すね

>>173
要件の変更に対応したりするのに時間やコストがかかったら仕事取れないかも知れない
性能が要件なら仕方ないけど

アップルはObjective-Cやめて

>>153
ﾊｹﾞﾄﾞｳすぎて吹いた。

XCodeとInterfaceBuilderも超めんどくさい。
うちにはデザイナーなんていないんです。
俺一人なんです。

>>173
工数かけて性能求めるより、サーバーの性能上げるほうが
安かったりするからな。

>>156
ある意味で言えば、デザイナがViewしか作れないから食っていける人が多いってことだろ。
本当にちょっとした改造だけでﾄﾞﾔｯと金を取る寸法。
まあしょうがないけど。

>>173
俺はパフォーマンスも構造的な美しさも二次的なもので、
デバッグ時の分かりやすさが第一だと思ってるよ。

必要の無いところでは凝った処理をしないで、
普通の人が普通に思いつくような書き方になるよう心がける。

>>183
ただ、コアとメモリで解決する問題ばっかじゃなかったりするんですわ、これが。

画面もコントロールもロジックも分けまくった挙句、
なんかモッサりしたＷebシステムが出来上がって。
結局、誰も幸せにならない。

>>156
幻想だわそれは

しかしいつも思うんだがシステム屋ってのはほんとこだわりのある人種だよな。
こんな人間を集めて統一して標準化とかいってやっていくのはたいへん…でもないか。
実際はみんな大人だから自分の主義主張はともかく言われたことは言われたように
やっていくもんか。（腹の中では、バカじゃねーの、この設計とか思いながら）

>>185
そう
ｵﾏｴは
strutsのﾊﾟﾝﾁｬｰだ

>>189
意外と声の大きな体育会系上がりのボスのが
上手くまとめたりしてなｗ
1例だけどそういうのは知ってる

>>179
JavaScriptでカプセル化するのが、当然の時代に、何言ってるのかと。

ドラゴンボールで例えて

俺はC＃とXYVYXを愛用

お前らみたいなポンコツは特定の言語1つしか使えなくて大変そうだね
俺みたいなエキスパートはどんな言語、如何なる環境でも使いこなすから何一つ困らないよ

>>175
あまえこそ、主キーを理解してない。
主キーなんて、最終のインデックスでしかないから1つで十分。
すべてのテーブルにサロゲートで連番を振ればORMに対応できるのでやるべき。

>>196
じゃあ全部KeyValueｽﾄｱでやれよ
おまえみたいなのはISAMで十分だだろ

>>197
keyvalueストアの主キーはDBとは全く違う。
kvストアを理解してない。

>>198
いや、主キーとBlobの組のﾃｰﾌﾞﾙだけで実現すれば
それはKeyValueｽﾄｱだ

>>158
モジュール化して公開してくれよ

>>199
その場合は意味のある主キーだし、前方検索に対応するように決めないといけないから、DB主キーとは違う。

>>196
アホすぎる

レベル低過ぎて引くわ
お前ら学生だろ？な？

>>199
MySQLがそんな感じだな。

>>202
アホはお前だw
少しDBの勉強してこいよ。
オブジェクト指向原理主義者の
アホのせいでDB屋がどれだけ
苦労してるか。
マシン性能向上でカバーできる?
どこの桃源郷の話だよ。
あ、ボラクルは儲かってウハウハ
かもしれないが。

速度と主キーは関係ないだろ。
関係あるのはインデックスだろ。

>>206
もおｵﾏｴな、主キーとかいってる時点でﾀﾞﾒ
UNIQUE NOT NULL
がついてるｶﾗﾑならどのｶﾗﾑでも主ｷｰの機能としてつかえる
単にｶﾗﾑに制約条件がついてるだけだ

これが主ｷｰを特別視してる池沼

>>205
オブジェクト指向の理想にDBが（ハードウェアも）ついてこれてないんだよ、という
言い方はされたことありますな。

>>206
それも一理はありますわな。正規化をきっちりやっても適切なインデックスを
はれば性能の問題はないと、ITmediaの小説にも書いてましたわ。

まあ立場により意見はいろいろあるってこってす…

>>206
Oracle由来のDBは主キーだけ異常は速い仕様だよ。
インデックスは気持ち速い程度

>>208
＞正規化をきっちりやっても適切なインデックスをはれば性能の問題はない

このｽﾚはこんな当り前のことができない池沼が集まってるわけか
これが特別なことだと思ってる

道理で話がかみあわないわけだ

>>210
ニュー速でなにいきがってんの?

値をぜんぶvectorとかmapにいれる屑
死んで来い

>>210
これを当たり前ということは…
あんた実際にDBの苦労はしたことないってことだと思うよ、きっと。
今のDBとハードウェアはまだまだ理想にはほど遠いんだ…
もしくはたいしたデータ量じゃないシステムしかやったことないでしょう。

>>209
オラクルの主キーは
インデックスとNOT NULL制約で
実装されてるんじゃなかったかな。
あと外部参照も
基本的に主キーは絶対変更されない
かつ
必ず一意になる値で作るんだよ。
メールアドレスとかで作ってる
システムみると倒れそうになるぞw
嘘だとおもうだろ?
実際あるんだぞww

>>207
複合主キーをやめろと言ってるだけ。

>>213
速度で問題でるときはな
DBMSやﾊｰﾄﾞｳｪｱの問題より
ほとんどの場合DBを設計やつに
概ね問題がある

ﾊﾞｶが造れば何度でもﾊﾞｶなもん作る
同じことの繰り返しだ

DBMSやﾊｰﾄﾞは進化しても
ﾊﾞｶは進化しないからな

MVCの限界ってMVVMもMVCの一種だろ

>>52
あちゃーこんなのあったんか見逃してたわﾔﾍﾞｰ
確かに熱いなこれは
ﾃﾝｷｭｰ！

複合主キーつかう奴を増やした原因はMSが悪いと思う。
バカがクリックして複合主キーを作る
。

>>205
レスする相手間違えてね？

Javaだってオラクル次第だろ

>>219
正規化勉強したら？マジで。

>>221
そう、今はそうなってしまったのですよ。
別の言語にしたほうがいいのかもしれないね。
ロバ面は誰よりも強欲だ。

java 最新版だと、セキュリティメッセージが省略できなくなって
困ってる企業がたくさんありそうだ

Accessの連番振る機能にバクがあったのも、複合主キー増やした原因。

関数従属性なんて言葉は聞いたこともない連中ばっかがDBMSいじってるかと思うと
恐ろしいな。

このスレ見てると自信が湧いてくるわ
プロとアマの差なんて無いってね

客から見えるとこに主キーを置くな！

やべぇ、わからん単語出てきた、>>5 とか完全に暗号

たまには勉強せにゃ……

>>229
ああそれね
って話だよ、Delphiあたりいじってた人間には当然の概念

要はバグを放置するMicrosoftは市ね。
いまでは、すっかりApple、google
派。

MFC弄った経験があればMVCには触れてる訳か
で、その発展形の話の訳ね、そっちはまだ個人的には未タッチだな

どこにもスレタイと同じ内容書かれてなかったけど、お前ら英語読めないのに分かったふりしてるの？

１万件くらいのテーブルでJOINx3くらいすると速度出すの難しくなってくるなあ

どうやったらそんなダサい設計ができるのか知りたい

>>234
たかだか1万レコード程度でｗｗｗｗｗｗ
業務では毎日数千万レコード増えるテーブルあるわ！ｗｗｗｗｗｗ
所詮、お前らみたいな低能はその程度

>>236
だってそんな良いサーバーでもないしさ
中小のシステムの面倒見てたらこんなもんよ？

MongoDBじゃイカんのか？
10年後にはSQLなくなってる気がする

>>238
KVMはブログとか個々のデータが独立してる分にはスケールするけど
ECみたいにデータが絡み合ってる系とは相性悪いんじゃないかと思ってる

KVMて切り替え装置かKVSだった

やられた見事なスレタイ速報、悔しいのでネコおいてきますね

ttp://image.slidesharecdn.com/githubhalpapp-minimizingplatform-specificcodewithmvvmbyjustinspahr-summers-130509112442-phpapp02/95/slide-2-638.jpg?1369256660

>>110
C#でWindowsアプリ組んでたら意外とWin32APIの知識が重宝がられる。

>>240
最近はKernel-based Virtual MachineってのもKVMだからねえ。ややこしいよね。

>>238
完全にパーティションできるならいいんだよね、>>239の言う通り。
大量ログはもうMongoさんでないてやってらんないって気がする。
金持ちは高速RDB使うんだろうけどさ。ExaだのNetezzaだのって。

>>239
http://blog.livedoor.jp/sasata299/archives/51429383.html

そろそろ追いつくじゃね？

なんでＭＶＣの話がＤＢの話になってんのこのスレｗ

業務アプリ界隈では切っても切れない縁なのDB

>>238
無理だな。
業務用SSDの登場で今後10年は安泰になってしまった。

>>231
Apple製品を本気で使ってたらそんなこと絶対に言えない。
Mac OS Xメジャーアップデート時のcocoaの意図的なバグとか殺意が沸くレベル。

>>227
プロほど他人が読めるように平凡なコードを書くからな。
新入社員だって現場にくる可能性があるから。

逆に素人ほどトリッキーなコードを好む。
俺スゲーの自己満足のために。

>>249
コードゴルフみたいなやつ？

>>227
プロってのは逃げないでてめえのケツ拭くことだよ

>>238
逆だろ
過渡期の存在だよ

どうでもいいから、誰かオラクルを倒してくれないかな

>>157
javaでSQLのset羅列って有り得ないと思うんだけどｗ

>>ITmediaの小説にも書いてましたわ。

こう書いている人が

>>もしくはたいしたデータ量じゃないシステムしかやったことないでしょう。

とかすごく怪しい。

Herokuってどうよ？

何いってんのか分からん。
それよりborland c++builder5探してんだけど、どこかに売ってないかな？

>>43
Delphiの生産性って未だに色褪せない気がするんだけどなんでこんな事になってんだろう
まぁ俺も使わせてもらえてないけど自分用にチョコチョコやるならDelphi以上はないわ
業務でも十分使えると思うんだけどねぇ

>>257
http://monobook.org/wiki/C_Sharp#.E7.94.9F.E3.81.84.E7.AB.8B.E3.81.A1

>>220
あ、ほんとだ。申し訳ない。。
面白いDB談義ができそうだけど
スレチなのでまたいつかどこかで。
すまんかった。

CとかってWebでも使える言語なの？

>>260
CGIの仕組みで
標準出力にﾃﾞｰﾀを履くだけで
それでWebｱﾌﾟﾘｹｰｼｮﾝは簡単に完成だ
返却するﾘｿｰｽももちろんHTMLでもいい

勿論Cでも標準出力に出力することが
あたりまえのようにできるんだから
その質問自体が無意味

HTTPのﾌﾟﾛﾄｺﾙ自体
単純なﾘｸｴｽﾄと
それの単純なﾚｽﾎﾟﾝｽしかないからな

Chrome + NaCL でガンガレ。

>>253
SI業界から抜け出せば問題ない

>>226
ウチはお偉いさん自身がデータ作りたがる都合で
関数従属性どころかOracle上の全てのテーブルに
外部参照制約すら無いよ

10年もリレーショナル要素を否定して
RDBMSを使ってる筋金入りの阿呆共は
見てて清々しいこともあるよ

ﾊﾞﾝﾊﾞﾝﾊﾞﾝﾊﾞﾝﾊﾞﾝﾊﾞﾝﾊﾞﾝﾊﾞﾝﾊﾞﾝﾊﾞﾝ
ﾊﾞﾝ　　　　　　　ﾊﾞﾝﾊﾞﾝﾊﾞﾝﾞﾝ ﾊﾞﾝﾊﾞﾝ
ﾊﾞﾝ（∩`･ω･）　　ﾊﾞﾝﾊﾞﾝﾊﾞﾝﾊﾞﾝﾞﾝ
　＿/_ﾐつ/￣￣￣/
　　　 ＼/＿＿＿/￣



ﾊｯ！
　”
。。（`･ω･）　　･･･mullぽ
　＿/_ﾐつ/￣￣￣/
　　　 ＼/＿＿＿/￣

GitHubがJavaでなくC#を採用したのは正解だね
個人的にはPythonを推すけど

土方の俺たちはこうして日頃の鬱憤を晴らしています。
だから議論も喧嘩腰になります。

>>266
Pythonを推すとは分かってらっしゃる

でもそれならGit止めてMercurialに移行する流れになってほしい

/*
　 　〈＼＿／ /
'´￣ ,z≧D≦　＼
　 /´⌒/|　 /'⌒ l
　 |　/Tﾒ|　/ヘヾﾊ
　 |/　l!　∨　l!　|｀ﾄ
　 |　､＿　　､＿,�Y
　 |///r─‐┐//〉|
＼|、＿V⌒Ｖ イヽ|
　ﾄ､＿＿了 ／j　
　＼　 　/／r'´
*/

Mercurialhubはよ

>>270
絶対流行んないよ
名前て大事だね

>>10
いや売ってるスーパーあるから

>>257
同意。
言語としては C# でいいと思うが、ネイティブじゃないから配布するのが面倒なんだよね。
結局 C++ で開発することに...
Windows XP が終了したら C# でいいと思うが。

Lazarusの日本語環境がもう少しまともになればなあ

ruby gemsは環境依存が酷すぎて全体的にphpの方がマシなレベル

HGhubはよ

>>90
考えるまでもないだろ
obj-cか、javaだよ
売れるアプリ作れるかどうかは、言語に対する知識とは全く関係ないけど

>>236
今時ノートでももう少し性能良いですけど

>>237
億単位のレコード数のテーブルが数十個あるDBの面倒見てるけど、ちゃんとチューニングしてやればかなりの速度が出るぞ。
前任者がめくらでただひたすらにデータ物故んでいくだけのDBにしてたんだがリプレースから引き継いで正規化からやり直した。
数百万行のInsertに3時間くらいかかってたのが十数分まで短縮。

メモリだけは多めに積ませてもらったがあと5年は余裕でもつわ。
5年後もディスクベイは余らせてるからディスク追加のみでさらに5年は行ける予定。

ちなみに中小の一般企業でござるよ。

RoRはもうその役目を終えたなあ
後続のフレームワークを生み出すための原動力になったというだけでも
一応意味は有った
少なくともStruts1系よりは良かった。

>>280
せっかく今勉強してるのにそんなこと言われても困るんだが

>>279
フロントの商品検索だから、INSERTは別に遅くても構わないんだよ。
商品データだけなら良いけど、そこにカラー、サイズ、在庫が絡んできてきつい。
商品データの検索条件も揺れるし。

C++の漏れには関係ないな

>>282
検索も高速化できたよ。
諸事情により正規化と言っても一番重要なリレーションは弄れなかったんでInsertほど劇的変化はなかったが・・・
それでもIndex見直しとデータ型の変更で五分の一程度に短縮できた。
一番大きかったのはバックグラウンドプロセスが動く部分を徹底チューニングしたとこかな。
検索だけ、InsertやUpdateだけって絞り方のチューニングだとそこまで行かないことが多い。
よほどシビアな運用を既にやっちゃってるDBじゃない限り、「そこはあんまり重要じゃないんだけどなー」と思っても弄ってみると波及効果で改善してくことはあり得る。

>>284
＞バックグラウンドプロセスが動く部分
実行計画を主に見てたんだけど
設定パラメータとかも注意してみたほうがいいのかな？

Rubyは趣味で作った言語っぽくてイマイチだな。
JAVAもなんか肌に合わない。
という事でやっぱC#か、ううむ。

>>285
うん。
Oracleなら起動パラメータのチューニング。SGAとかPGA周り、後はI/Oだね。
I/Oっていうと更新系の処理以外はあまり弄らない人多いけど、読み出し速度がかなり変わる。
実ファイル→メモリキャッシュの流れを早くしてあげると検索も相当早くなるよ。
あと、無駄なjobの停止。
実行計画は大事だけど、その実行計画が採用されるまでにオプティマイザやらが動くとこに集中してリソース配分してやればさらに早くできる。

お前らRuby書き直せばいいやん、優秀なんだからできるさ

>>287
MySQL5.1なんだよな
MySQL(Linux)のキャッシュ機構はLinuxのファイルキャッシュに相乗りしていて
ファイルキャッシュがメモリに乗ってる限りは大丈夫らしい。
まあでも設定回りをもう一度確認してみます。

>>286
Javaが肌に合わないのにC#とかあり得ないぞ。
Javaに余計なお荷物を使いもしないのに持たせてるのがC#と考えていいと思う。

Javaはムカつくよ。
クラスひとつにつき１ファイル作らせるところが。

オススメはしないけどファイル名のクラス以外に別のクラス書けるよ

>>215
自然キーだと必然的に複合キーになるだろ
代理キーvs自然キーは一言で結論の出るテーマではない
お前はニワカ

>>209
同じだろ

JavaとC#は似てるがC#の方がC++に近いから好きだな
業務で大容量のDBを使用するならORACLEかDB2にならざるを得ない
ただし可用性、パフォーマンス、信頼性をそれほど求めないオープンソースで十分だけどね

RoRの登場はStrutsで苦労していた俺には衝撃的だった
要件が単純だと問題ないが複雑だと結構面倒だけどね
新しいフレームワークを考えるきっかけになった意義は大きい

↑（訂正）
ただし可用性、パフォーマンス、信頼性をそれほど求めないオープンソースで十分だけどね
→ただし可用性、パフォーマンス、信頼性をそれほど求めないならオープンソースで十分だけどね

オープンソーでやるのって自分で全部引き受ける覚悟が必要だよね。
SIerってそれをやらないんだよね。リスク回避リスク回避っていって
自分自身でやりきらない。
だから高いOracleとかすすめるんだよなー。

もっともそれはいわゆる大企業のお客さんも同じで、どーせローテの
都合でいるだけの情シスでそんな覚悟はしょいたくないから全部丸投げ。
こんなことしてると高くつくのはしょうがないよな。
SIerに保険屋もやらせてるようなもんだから。

>>297
他の機能なら不具合あっても回避しつつ改修とかできるけど、データベースの不具合はデータ壊すこともあるから、そのリスクは負いたくないわな。

>>297
わかりすぎるわ。

会社に一匹はいるんだよね。システムの大先生（）でいち早くOSSだのクラウドだのを導入したがる馬鹿。
OSS使ってもベンダに面倒見させりゃ中間マージンは削れないし、新規バグ踏んだ時の対応はメンテナが対応してくれるまではどうしょもない。
クラウド使ってもDevOpsもわかってないから密林だのGoogleが何とかしてくれる→保守ベンダが何とかしてくれる→いや、仕様だし。で詰む。

結局自分の手を動かさない口先番長なんだよね。
英語の資料読み込めるほどの英語力もないし、Google先生に手伝ってもらって解読するような根性もない。
ちっちゃいプロトタイプ作って動かせば十分発見できるレベルの不整合を数百万の金かけてベンダにテストさせて確認するの。

本人はシステムの大先生（）だから他の奴らにはバレてないって思ってるらしいけど、上役でちょっと目端の利く人は見抜いてるんだよな。

>>299
> ちっちゃいプロトタイプ作って動かせば十分発見できるレベルの不整合を数百万の金かけてベンダにテストさせて確認するの。
> 上役でちょっと目端の利く人は見抜いてるんだよな。

要するに、その上役は数百万の損失を見過ごしてるボンクラと言うことか。
どうせ作り話するなら、もう少し頑張りや (w

c# なんていう偏差値が１０ぐらいの精薄が書いても、とりあえず動いてしまう言語
だと使えないバカが増えて、こちらの無駄仕事が増えるだけだから止めてくれ

フレームワークって
アフォでも作れるシステムってのが目指す方向の一つでもあるんだけどなあ

>>290
JavaとJavascriptを混同してるやつじゃね

>>301
日本語が不自由すぎるw 大丈夫かお前w

>>290
Javaが肌に合わなくてC#って別に普通だと思うけど?
C#は元々Delphiだし。

javascriptでゲーム作ろうと思うんですが
お勧めのライブラリがあれば教えて欲しい

C#とJavaは一見似たような感じだけど
ちゃんとやりこめば全然別モノだと気が付く

Javaってやっぱ停滞してるよな

おい、そんなことよりだれかSQLとかいうオブジェクティブじゃないクソ言語を終わらせてくれよ・・・

まぁ、ぶっちゃけ、MVVMって衆愚政治だよねｗ
Linuxって衆愚に陥りやすいからあんま好きじゃないんだよね。

どうせ5年10年後に軌道修正して元鞘に納まるし

>>308
それこそＯＲマッピングでいいじゃん…

>>308
行と列からなるテーブルを扱うのにSQLは最適な言語
お前がパーなだけ。

SQLって英語的にDBを扱うことに特化した言語だよね。
オブジェクト言語でいえばVB1.0みたいな存在。
早くC#とかJavaみたいなの出せよ。

MVVM絡みで

最近流行りのフロントエンドは全部Javascriptで、サーバーはRESTでデータ返すだけ
ってスタイルで突き進むなら、既存のブラウザじゃない、この形態のアプリ専用のプラットフォームを
作ったほうがいいと思うよ。マジで。
今はブラウザをブラウザとして使用しないためのバッドノウハウてんこ盛りだもん。

ぶっちゃけ、MVVMはスマホタブレットタッチスクリーン向けのバカチョンモデルだからねー。
この流れが変わって、キネクトになった時に1から覚え直しか失業するからねー。
MVCしらんバカは。

>>313
アプリ専用プラットフォーム作るコストがもったいないからブラウザにやらせてるんだよね。
まぁ、ブラウザプラグインでAPI再構築するだけでも違う気がするがねー。
誰かやれよｗ

>>313
リッチクライアントは絶望的じゃないの
まあ、このままHTML5で突き進むにしても
もうちょっと洗練されてほしいけどなあ

いや例えばiPhoneアプリって中身HTML+Javascriptだけど、うまいことブラウザの匂いを消して
アプリの顔してるじゃん?
ああいうこと

ただのHTMLレンダラ+Javascript実行環境だけのブラウザってことだな。

このスレ見てるとやっぱりお前らできる子だったんだな

>>315
リッチクライアントで培われたものがHTML5アプリに上手く継承されてないのが見ててもやもやする。

各種フレームワークの機能見ても、車輪の再発明どころか再再再発明やってるのが現状だしな。
そこは他の連中が20年前に通った道だろう、みたいな話をgithubあたりで延々と議論してる。

意外とnodejsの話がない
使い慣れたjavascriptで何でもできるけど

何でもできるは何にもできない
その理屈ならCだけあれば何もいらないはず

>>318
まー、全てHTML5に盛り込めるとは思えねーな。
クライアントが巨大になりすぎて遅くなると思うし、
その負担を1アプリが賄いきれるとは思わないね。
バグは収集不能になるだろうし、品質も安定しなくなる。
そろそろブラウザも飽和状態だし。
更新や機能拡張が殆ど止まってるじゃない。
最近はセキュリティーアップデートと見た目の変更ばっか。

>>318
末端のアプリの作り方が置いてけぼりになるくらい
全体が徐々にネットワークにシフトしてきてる感じがする
この流れには逆らえないんだと思う

今後のおおまかな方向性はFirefoxOSのように
端末のネイティブ層は薄く、デバイスの機能を提供するだけで
ソフトはJavaScriptで書くのが主流になるんだろう
元々ネイティブアプリは繋ぎでしかなかったんだし。

もしリッチクライアントで作って良くてリッチクライアント向きのアプリなら
迷わずリッチクライアントで作るよ。
その必要もないのにブラウザ全てをサポートなんてしたくないし。

こないだRubyの会議でGitHubのエンジニアが壇上で
「Ruby遅いんじゃ！特にGC！」
ってキレてたなぁ…
後でmatzが
「Ruby2.1で世代別GCにします！」
って宣言してたが、待ちきれなかったか…

そもそもRubyのGCに影響を受けるシステムって何？
意味わかないんだけど・・・

Railsを取り上げられてもプログラムが書ける人って全Rubyプログラマ中
何%くらいなんだろうなw

要するに、Ruby使いこなせるだけの人が居ないから、
バカチョンで使えるC#とかJSでGUIコンテナー弄ったり
ゴリゴリ手続きお手軽スクリプトで誤魔化そうって話でそｗ

んで、パラダイムシフトでそういう使えないのは引退する訳だが。使い捨てだよね。

>>326
そりゃバックエンドで動きっぱのRubyアプリは全部影響うけるでしょうよw

LLはある程度の規模以上には使えねーべ？
型なりDBスキーマなりの縛りが無いまま作ってたら、すぐにぐしゃっとなる

Perlで動くどでかいシステムなんて腐るほどあるっしょ

そーでもないなよな。

むしろLLの方が構文が単純でバグが少なく作り込める。
本当に巨大になってくると、むしろLLの方が有用になる。
もちろん、注意して使えるレベルの奴じゃないとダメな訳だが。
破綻させてるのは言語というより人のレベル。
間口が広いから有象無象が居るというだけ。
それが根本的な敗因。
言語の本質的な問題ではないと思う。

>>332
単にRubyが古いGCアルゴリズムを使い続けたのが
一番の問題だわな。
Ruby自体はいい言語。

しかし、パフォーマンスを理由にTwitterに逃げられ、
GitHubにも逃げられてようやくモダンなGCを採用する
というのは言語開発としてどうかと思うが。

たとえば速度の問題が解決されたとして、rubyでゲームとか作れるかね？
インテリセンスもなければ型チェックもない
プログラムが大きくなればなるほど、クラスやデータの把握が難しくなるんでは？
作り方の問題て言っても、データフォーマットまでは把握できないだろ。

何が？誰に対して激震なのかわからんな

>>334
まぁ、大概、コンパイラの型チェックとかに頼ってバグ探しするレベルのプログラマなら、
とんでもないエラー組み込むだろうな。
基本的に型が問題になることは無いね。
むしろ型が邪魔とすら言える。

速度にしても、ハードウェアの投資の問題であって、まぁ、ビジネスでは重要な問題だろうけど、
時間と金が解決する問題で、わざわざ手続き臭いPerlに置き換えるだけのメリットも感じられないな。
Ｃ感覚で書けるのがPerlの唯一のメリットだし。
逆に言えば、無駄なコードとめんどくささが付きまとう。

>>336
とんでもないエラーを組み込まないための
型チェックじゃないの？
それに型がないのも裏では型変換をやっているでしょ？

>>337
まあ、あれだ
>>336は入力ﾐｽを犯さないﾛﾎﾞｯﾄがｺｰﾄﾞを書いてるとか思ってる池沼だ

そりゃrubyのMVCは何も考えずに形だけだからな。
Rubyはすぐ限界が来るよ。

>>320
あらゆる言語が実装はCだから、
ほとんど出来ないことないよなCは

>>340
void*最強説

片山さんに意見を聞きたい
警察は直ぐに釈放しろ

日本のC＃やってきたやつのレベルは低い

JAVAもなー

どっかが潰しに来てんじゃね？

あとまぁrubyでゲームは普通に作れるよ
ちゃんとわかってる奴ならどの部分が重いか知ってるから
そこだけ丁寧に速度重視で書いたりC++でかけばいいだけで
○○言語だから、○○は作れない。なんてものは存在しない
dxrubyなんかだとライブラリが当たり判定の処理をC++でかいたメソッドを提供してるから結構速い

かたちぇｃｋとか、エラーがー、ってのは同意
動的言語でゲーム作るのはC++で作るよりも難易度高いのは確実だな
テトリスとかーボードゲームとかー、ソースコードが全体で2000〜3000行もいかないようなやつなら
動的言語のほうがさっさと作れるから楽
テトリスだったらカスみたいなソースでやっても100行未満だからな

お前らruby使え

へー

プロトタイプ作成にはいいと思う

個人的にはpythonのほうが好きだけど3Kがなかなか普及しないんだよなあ
あれから何年たってんだか

やっぱCなんだなあ

結局プログラミング言語なんてシェアで採択される
要は仕組みを作った言語が勝つ
一般的に言われている言語自体の優劣なんて書き方の作法がそいつにとって面倒であるかどうかくらいだろ

LLは型がないから大規模開発は無理って誰の理屈?

LLは変数宣言がない、名前空間がないから大規模開発が無理ってのは
よく槍玉に挙げられてたけど、最近は改善されてるしね。

knockout.jsとかはjQueryと比べて何がメリット？
てかknockout.jsて何？

>>351
公式見て分からなければ、今はまだ知らなくていいことだと思う。

Rubyはステマ…

教祖様が２ｃｈで持ち上げまくってたからね

ぶっちゃけRubyじゃなくてRoRがすごかっただけなんで

>>352
JSONでデータ送ったら
htmlのDOM要件にデータをバインドして表示したり逆にデータ受け取ったりしてくれる
バインドを維持していればCSSとかで表現を変えても影響しない
こんな感じ？

手続き言語でコンパイラ方式ではCが最高
LL系ならRubyよりPythonが有望かな
バックにGoogleがついているからね
JavaとC#は中途半端で、C++は複雑過ぎる

バックにgoogleがついてるgoをよろしく