5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

静的型付け言語の潜在開発生産性は今の100倍

1 :デフォルトの名無しさん:2013/03/03(日) 18:17:29.51
人間がやっていたことを、コンピュータにやらせる。
これが生産性を上げる最大の方法。
コンピュータは間違わない、同じ事を何度も高速に行える。

その為に、コンピュータがコードの意味を正確に
認識できる方法が必要。実行しないとわからないことは
コンピュータは認識できない。

すなわち静的型付け言語であれば、実行しなくてもわかるので
コンピュータが理解できる。そうすれば様々な
コンピュータの高度な情報支援が得られる。

コンピュータのバックアップを受け、人間の生産性は
限りなく向上する。

391 :デフォルトの名無しさん:2013/03/17(日) 19:24:04.05
>>388
よくわからんが、成功組と
失敗組がはっきりしたのか?

392 :デフォルトの名無しさん:2013/03/17(日) 19:36:24.11
>>389
じゃやり方示してみな。できるもんならなlol

393 :デフォルトの名無しさん:2013/03/17(日) 19:37:56.88
>>390
関係ないよ。単にMVCを簡潔に書けるかどうかっつう話しだし。

394 :デフォルトの名無しさん:2013/03/17(日) 19:55:48.80
コードジェネレーター作ればいいだけなので
Javaでも簡潔に書ける。

395 :デフォルトの名無しさん:2013/03/17(日) 19:57:39.64
JLabelとかJTextFieldはViewの実装の詳細であってMCとの通信とは何の関係もないわな。
MVC持ち出す時点でなんか勘違いしているか時代遅れの筋の悪い作法しか知らないのでは。

396 :デフォルトの名無しさん:2013/03/17(日) 20:01:18.86
MVCは継承しないと出来ないって
Rubyの神様が言ってたんだとさ

397 :デフォルトの名無しさん:2013/03/17(日) 20:01:57.24
古かろうがなんだろうが作る作れるよな。(最新はMorphicだが)
古いものすら作れないの?
結局Duck Typeが使える言語なら簡単にできる古典的様式が
Java単体じゃ簡単にできない事が判明したわけだ。

398 :デフォルトの名無しさん:2013/03/17(日) 20:17:31.17
>>394
Javaなど人間が読み書きするに値しない
機械的にコードを生成するレベルの低級言語ってことですね、わかります

399 :デフォルトの名無しさん:2013/03/17(日) 20:26:55.88
>>394
アセンブリ言語でもいいんじゃね

400 :デフォルトの名無しさん:2013/03/17(日) 20:30:19.91
>>397
作れるし実際に広く使われているよ。
MVCするのにJLabelとJTextFieldを名寄せしたりDuckTypingが必要なケースがそもそも謎。
VとMCの通信はVの実装の詳細とは独立に定義するものだが普通。

401 :デフォルトの名無しさん:2013/03/17(日) 20:42:45.87
>>400
御託はいいから早くやれよ

402 :デフォルトの名無しさん:2013/03/17(日) 20:50:01.34
         ,-、            ,.-、
        ./:::::\          /::::::ヽ
       /::::::::::::;ゝ--──-- 、._/::::::::::::::|
       /,.-‐''"´          \:::::::::::|
     /                ヽ、::::|
    /                   ヽ|
     l                         l
    .|    ●                |    んーとね・・
     l  , , ,           ●     l
    ` 、      (_人__丿    、、、   /
      `ー 、__               /
         /`'''ー‐‐──‐‐‐┬'''""´

         ,-、             ,.-、
        ./:::::\          /::::::ヽ
       /::::::::::::;ゝ--──-- 、._/::::::::::::::|
       /,.-‐''"´          \:::::::::::|   つ
     /                ヽ、::::|   っ
    /     ノ             ヽ|
     l              ヽ         l
    .|    ●             u  |    んーっとね・・・・・・・・・
     l  , , ,           ●     l    やればできるもんっ!!
    ` 、 u    (_人__丿    、、、   /    
      `ー 、__               /
         /`'''ー‐‐──‐‐‐┬'''""´

403 :デフォルトの名無しさん:2013/03/17(日) 21:14:09.95
>>401
ご託は良いからMVCにGUIコンポーネントの名寄せやDuckTypingが必要なケースを(ry

JavaでMVCやるときのViewの設計のパターンの一つはViewのインターフェイスをViewの
実装とは無関係に定義する方法。これを実装したViewをControllerなりFacadeに差し込む。

public interface FruitListView{
 void showFruitItems(List<Fruit> fruitList);
 ...
}

次にある瞬間Viewの画面に表示するデータを保持するコンテナ、大抵はViewModelと
呼ばれるものを定義してインスタンスを注入する方法。もちろんViewModelもViewの
実装の詳細とは無関係。DIコンテナを使うWeb系のフレームワークにはこれが多い。

public class FruitListViewModel{
 List<Fruit> fruitList;
}

public interface FruitListView{
 void setViewModel(FruitListViewModel viewModel);
}

MC間とより複雑なインタラクションが必要となるGUIの場合、ViewModelではなくクラス
階層を持ったNotificationとして、Notificationとして受けておいてViewの中でRTTIで
Notificationの型を見て必要なデータと処理内容を得るのがPureMVCなんかのパターン。

最後にこれはフレームワークの支援が必要だけれども、テンプレート言語を使って書かれた
viewにViewModelをバインディングする方法。

何れにしても今日的なMVCフレームワークではViewの外面にJLabelとかいったViewの詳細
が立ち現れることはまず無い。

404 :デフォルトの名無しさん:2013/03/17(日) 21:16:18.13
「名寄せ」だってw

405 :デフォルトの名無しさん:2013/03/17(日) 21:44:19.13
>>403
JLabelとJTextFieldってさ、setTextは共有してるのに
インターフェースを共有してないから、setTextを呼び出すコードを
JLabelとJTextFieldで別々に容易しなきゃダメって話じゃないの?

そもそも実装の話なんて誰もしてなくて、structual subtypingの観点で同じコードを
重複して実装する非効率さを問題にしてたと思うんだけど、
そういうインターフェースの設計ミスが無い前提で話をしてない?

406 :デフォルトの名無しさん:2013/03/17(日) 21:57:01.88
>>405
さあ?
>>387がJavaでMVCするにはそれ(メソッド名の名寄せ)をするしかないと書いているから
んなわけね〜と書いたまでだけど。

あとさ、JLabelとJTextFieldでメソッドを分けなければいけないって、当然それらのクラスの
インスタンスを引数として受けるメソッドの事だと思うけど、具体的にどんなケースにそんな
メソッドが必要になるだろう?具体的に。

407 :デフォルトの名無しさん:2013/03/17(日) 22:00:21.14
>>403
だれもViewModelのなんてやれっつってねぇよ。
純粋なMVCやれ、別にPluggableMVCでもいいぞ。

てか、ViewModel型のMVCやるだけでもそんだけ面倒くさくなるんだな。
しかもJLabelとJTextFieldの2通りも必要とは。
そんな事してる間にDuck Typeが使える言語ならModel内部の作成に入っとるわ。

408 :デフォルトの名無しさん:2013/03/17(日) 22:15:57.59
>>407
は? 純粋なMVCだが。どこが不純か詳しく。

Viewのインターフェース定義もViewModelの導入も、VへのメッセージをVの実装とは
独立して定義する実装パターンのひとつにすぎないが。

> てか、ViewModel型のMVCやるだけでもそんだけ面倒くさくなるんだな。
>しかもJLabelとJTextFieldの2通りも必要とは。

何のためのViewModelか全く理解していないのがまるわかり。

409 :デフォルトの名無しさん:2013/03/17(日) 22:17:32.31
現実的にRhinoで実装すっとこんな感じか。
Javaより格段無駄がなくてすっきりするな。

var TextModel = function()
{
  this = new java.beans.PropertyChangeSupport( this );
  var text = "";

  this.getText = function(){ retrun text; }
  this.setText = function( value )
  {
    var old = text;
    text = value;
    this.firePropertyChange( "text", old, text );
  }
}

var modelDependencyAdapter = function( textView, model )
{
 var dependency = {};
 dependency.propertyChange = function( event ) { textView.setText( model.getText() ); };
 return dependency;
}

var model = new TextModel();
text = new JTextField();
model.addPropertyChangeListener( "text", modelDependencyAdapter( text, model ) );
label = new JLabel();
model.addPropertyChangeListener( "text", modelDependencyAdapter( label, model ) );

410 :デフォルトの名無しさん:2013/03/17(日) 22:19:51.01
>>407
あとMVCにJLabelなどのメソッド名の名寄せが必要なパターンはよ。
どうせMやCにViewのロジックが食い込んだ汚い例しか出てこないと思うが。

411 :デフォルトの名無しさん:2013/03/17(日) 22:26:29.98
>>408
http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html
この辺りを見てお勉強しなおしたらいいんじゃないかなぁ?
MVCっつうのは、複数のViewで1つのModelを映し出し、
かつそこからControllerを分離した方式の事だよ。
Modelを複数のViewで投影できないなら意味がない。

412 :デフォルトの名無しさん:2013/03/17(日) 22:29:32.34
>>410
FruitListViewが、JLabelとJTextFieldに対応するにはどうしたらいいんですかねぇ〜

413 :デフォルトの名無しさん:2013/03/17(日) 22:30:49.29
>>409
テキストをポリゴン表示するど派手なラベル部品を使いたいんだが、テキスト表示するメソッド名
がrenderTextだったらど〜する。

adapterがViewの実装に依存している点で30点。

414 :デフォルトの名無しさん:2013/03/17(日) 22:36:39.17
>>411
出来るが。これは典型的なViewがModelへの参照を持たないパターンだが何を見ているの?
ViewModelについても何か勘違いしてない?
>>412
それはViewの実装の詳細。心配せんでもJLabelとJTextFieldで別メソッドを用意せんと
いけないような場面はViewの実装では殆どないよ。あるなら>>406にレスしてくれ。

415 :デフォルトの名無しさん:2013/03/17(日) 22:45:25.91
Contoroller忘れてたのと重要なとこ忘れてたんで修正
var TextModel = function()
{
  this = new java.beans.PropertyChangeSupport( this );
  var text = "";

  this.getText = function(){ retrun text; }
  this.setText = function( value )
  {
    var old = text;
    text = value;
    this.firePropertyChange( "text", old, text );
  }
}

var modelDependencyAdapter = function( textView, model, key ) // keyはSmalltalkならSymbol、C++ならtemplateで対応する
{
 var dependency = {};
 dependency.propertyChange = function( event ) { textView[key]( model.getText() ); };
 return dependency;
}

var model = new TextModel();
text = new JTextField();
model.addPropertyChangeListener( "text", modelDependencyAdapter( text, model, "text" ) );
label = new JLabel();
model.addPropertyChangeListener( "text", modelDependencyAdapter( label, model, "text" ) );
JButton button = new JButton();
button.addActionListener( function() { model.setText( "hello"); } );

>>413
adapterはViewの一部に決まってんじゃん。Javaじゃなかったら要らねぇし。なに初歩的な事言ってんの?

416 :デフォルトの名無しさん:2013/03/17(日) 22:48:22.31
>>414
具体的にどう書くか聞いてんだよ。
JLabelとJTextが問題になってたんだから、
JLabelとJText無しで出来ますじゃ意味ないだろ。

417 :デフォルトの名無しさん:2013/03/17(日) 22:51:03.06
間違えたんで細部修正
var TextModel = function()
{
  this = new java.beans.PropertyChangeSupport( this );
  var text = "";

  this.getText = function(){ retrun text; }
  this.setText = function( value )
  {
    var old = text;
    text = value;
    this.firePropertyChange( "text", old, text );
  }
}

var modelDependencyAdapter = function( textView, model, key ) // keyはSmalltalkならSymbol、C++ならtemplateで対応する
{
 var dependency = {};
 dependency.propertyChange = function( event ) { textView.setText( model[key]() ); };
 return dependency;
}

var model = new TextModel();
text = new JTextField();
model.addPropertyChangeListener( "text", modelDependencyAdapter( text, model, "getText" ) );
label = new JLabel();
model.addPropertyChangeListener( "text", modelDependencyAdapter( label, model, "getText" ) );
JButton button = new JButton();
button.addActionListener( function() { model.setText( "hello"); } );

418 :デフォルトの名無しさん:2013/03/17(日) 23:01:55.51
ところで、標準ライブラリのOutputStreamとDataOutputの関係はどうなの?
こんな感じのコードを別々に書くことに合理性はあるの?

void example1(OutputStream out, List<byte[]> data) throws IOException {
    for (byte[] b : data) {
        out.write(b);
    }
}
void example2(DataOutput out, List<byte[]> data) throws IOException {
    for (byte[] b : data) {
        out.write(b);
    }
}

419 :デフォルトの名無しさん:2013/03/17(日) 23:25:34.95
>>414
>出来るが。これは典型的なViewがModelへの参照を持たないパターンだが何を見ているの?
出来るなら具体的にそのコードを書いてくれ

420 :デフォルトの名無しさん:2013/03/17(日) 23:46:27.06
>>419
View定義
public interface FruitView{
 void displayFruit(Fruit fruit);
}

本当はイベント配送はフレームワークに管理させるべきところだけど>>409もリスナーとして
直接ViewをModelに貼り付けているのでコードの簡略のためmodelにViewの参照を持たせる。

public model FruitModel{
 List<FruitView> views;
 public void addView(FruitView view){this.views.add(view);}
 public Fruit getFruit(){...}
 public void setFruit(Fruit fruit){this.fruit = fruit; for(FruitView view: views) view.displayFruit(fruit);}
}

Viewの実装例
public class FruitViewImpl1 extends JPanel implements FruitView{
 JLabel name; JTextField quantity;
 public FruitViewImpl1(){ /* 子コンポーネントの生成とレイアウト */ }
 void displayFruit(Fruit fruit){
  this.name.setText(fruit.getText());
  this.quantity.setText(fruit.getQuantity());
 }
}

FruitModel model = new FruitModel();
FruitView view = new FruitViewImpl1();
model.addView(view);
model.setFruit(aFruit);

名寄せ? DuckTyping? 要らないよ。ちゃんとViewが実装の詳細と独立に抽象化されていれば。

421 :デフォルトの名無しさん:2013/03/18(月) 00:01:23.38
全然本題と関係ないコード貼って何がしたいんだ……これがアスペか

422 :デフォルトの名無しさん:2013/03/18(月) 00:14:29.92
>>421
modelを複数のviewに投影することが出来る例だが、本題って何だっけ。

423 :デフォルトの名無しさん:2013/03/18(月) 02:24:53.23
事の始まりはDuckTypingできないJavaってゴミだねって話から

424 :デフォルトの名無しさん:2013/03/18(月) 02:29:23.18
どのJavaにこてんぱんにされてるw

型がきっちりしてる分、
抽象化能力が鍛えられてるんだよな。

型がないととりあえず作って
問題があったら、型調べて適当にディスパッチで
対応とかしてるから、何と何が共通の機能であるとかが適当になってる。

425 :デフォルトの名無しさん:2013/03/18(月) 02:31:20.52
>>424
>>418に答えてあげなよ。Javaだよ

426 :デフォルトの名無しさん:2013/03/18(月) 02:37:08.62
>>418
> ところで、標準ライブラリのOutputStreamとDataOutputの関係はどうなの?
別に問題ない。抽象化することで拡張性が得られている。

> こんな感じのコードを別々に書くことに合理性はあるの?
”書くこと” ではなく ”書けること” に合理性はある。

面倒であれば、別々に書かなくていいライブラリを使うか
自分で作れば良い

427 :デフォルトの名無しさん:2013/03/18(月) 02:43:45.32
>>423
とりあえずMVCに関してはDuckTyping別に必須じゃないねと言うことでFAだな。
静的型でも全然普通に出来る。

428 :デフォルトの名無しさん:2013/03/18(月) 02:46:41.70
>>426
つまり、標準ライブラリの設計が失敗してゴミで
共通の処理をまとめたくてもまとめられないウンコだから
別のライブラリ探すか自作するかしろ(標準ライブラリ使ったコードとは混ぜられないけどな)ってことですね。
分かりました!ありがとうJavaの人!

429 :デフォルトの名無しさん:2013/03/18(月) 02:48:40.03
>>428
自分に力がないのを言語のせいにするな
初心者の頃に習わなかったか?

430 :デフォルトの名無しさん:2013/03/18(月) 02:52:59.27
>>428
実際のところ>>418のようなのを両方書く必要があるケースって殆ど無いから。

431 :デフォルトの名無しさん:2013/03/18(月) 07:13:08.74
>>420
Javaになってないんですけどー
あと、あんたがしきりに言ってるフレームワークって具体的に何。

432 :デフォルトの名無しさん:2013/03/18(月) 07:16:48.58
>>420
JLabelだけを実行時に取り外せんぞ
なんつってMVCじゃねぇか。
Smalltalkなんかは、実行時にModelとViewの関係を
組み直せるメリットからMVC開発が進んだのに退化してるじゃねぇか。

433 :デフォルトの名無しさん:2013/03/18(月) 07:23:07.75
>>420
ViewをJLabelからJTextFieldに差し替えるコードを書いてくれ

434 :デフォルトの名無しさん:2013/03/18(月) 08:09:46.09
>>431
フレームワークが扱うべきなのはこの例の範囲で言うならMV間のオブザーバーパターンの実装。
これは全てのModelで共有すべき実装であって具象Modelの実装に立ち現れるのは良くない。
抽象クラスで実装するなり別のオブジェクトに委譲すべきだし、それはJavaでも簡単。

>>432
FruitViewの取り外しや追加、別実装への差し替えは常に可能だが。
Viewって何のこと言っている? JLabelやJTextFieldといった個別のGUI部品がViewだとでも?
そういう扱いも可能かもしれんが現実問題として個別のGUI部品をModelのオブザーバーとして
実装する例なんてそうそう見ないしそんなことをした日にはViewのロジックはどこに噛ますの?
沢山のGUI部品を含むViewを丸ごとごそっと差し替えるのはどうやるの?
普通はViewのロジックも含めた交換可能な単位としてViewは部品化するもんでないかい?

Modelに直接GUI部品を関連づける>>417で正直ゲゲッと思ったけれども、GUI開発でこんな
不作法がまかりとおる業界は一体どちら様方面なのか参考までに教えてくれ。

>>433
以下同文。FruitViewを継承したViewをJTextField使って実装して差し替えれば?

435 :デフォルトの名無しさん:2013/03/18(月) 08:37:13.31
>>430
OutputStreamWriterとRandomAccessFile(のサブクラス)両対応の出力コードを書くとき

436 :デフォルトの名無しさん:2013/03/18(月) 08:48:48.78
>>435
何を出力するコードさ?

437 :デフォルトの名無しさん:2013/03/18(月) 17:50:24.43
言葉よりもコードが雄弁に語ってるね
Javaが冗長でオワコンだと

こんな言語で書いてたら、そりゃIDEの補完機能に異常に拘るわけだよ
まあ、補完できようが可読性は最悪だし、
なにより動的言語でも補完できちゃうんだけどねw

438 :デフォルトの名無しさん:2013/03/18(月) 18:54:10.72
潜在的に100倍の冗長さがあり、それを生産性と勘違いした。
というところか。

439 :デフォルトの名無しさん:2013/03/18(月) 21:02:54.47
>>434
具体的にフレームワークの名前を挙げろと言ったんですけど。
ああ、結局自作しないと無いんですね。生産効率わるぅ

440 :デフォルトの名無しさん:2013/03/18(月) 21:05:47.92
>以下同文。FruitViewを継承したViewをJTextField使って実装して差し替えれば?
結局JLabel用のViewとJTextField用のViewを作るのか

441 :デフォルトの名無しさん:2013/03/18(月) 22:06:47.75
お前らいつまで書く時の話ばっかり見てるんだ?
コードは書くより読むほうが何倍も多いんだぞ。

だから生産性が高い言語使ってるはずなのに
開発期間が短くならないんだよ。

442 :デフォルトの名無しさん:2013/03/18(月) 22:11:51.17
なんかMVCパターンわかってない奴がいるみたいだね。

基本パターンは、Modelに対してViewが自分自身を登録し、
Viewがイベントを受け取るんだよ。

Modelが直接ViewのsetTextとかを呼んだりしない。
ModelはViewが持っているメソッドを意識しない。

ここまでわかっているなら、JLabelとJTextFieldの
継承関係がどうなっていようと関係ないってわかるはずだが。

繰り返すがMVCパターンの話な。MVCパターンが
面倒くさいという話ならそれは言語関係ない。

443 :デフォルトの名無しさん:2013/03/18(月) 22:14:58.38
なんかもうそろそろなんで
MVCパターンなんか使うの?
面倒くさいだけじゃんって
言う奴が出てきそうだなw

444 :デフォルトの名無しさん:2013/03/18(月) 22:16:39.55
それよりもWeb系の偽MVCと
GUI系の本物のMVCをごっちゃにしている奴がいそうだ。

偽MVCはオブザーバーパターンがでてこない

445 :デフォルトの名無しさん:2013/03/18(月) 22:27:16.72
>>442
>>440

446 :デフォルトの名無しさん:2013/03/18(月) 22:31:59.97
>>445
JavaScriptのMVCフレームワークを考えればいい。

JTextFieldというのは、<input type="text> のことだ。

Viewを作るか作らないかって?
inputタグがViewになってるフレームワークあるか?
初心者も甚だしい。

447 :デフォルトの名無しさん:2013/03/18(月) 22:41:24.90
View内部で使っているUIコンポーネントをシグニチャ的に互換性のある別コンポーネントに
(動的に)差し替えられるか?って話をしてるのに、全く話が通じてなくてワロス
都合が悪いから曲解してるのか、アスペなのか、馬鹿なのか……

448 :デフォルトの名無しさん:2013/03/18(月) 22:50:29.38
シグニチャ的に互換性があっても
機能的に互換性がないのだから
入れ替えることないだろ?
変なことを言うやつだな。
ボタンがいきなりテキストボックスなって嬉しいのか?

449 :デフォルトの名無しさん:2013/03/18(月) 22:55:11.04
ラベルとテキストフィールドに
機能的互換性があるかというと
ないよな。

テキストフィールドならsetFocusで
きるだろうけどラベルだとできないし。

450 :デフォルトの名無しさん:2013/03/18(月) 22:59:20.20
>>446
Smalltalk系の正当なMVCや、
Self, Pharoとかで使われてるMVCの最終型Morphicなんかがそうだ。
今まで、MVC、PluggableMVC、Morphicと経てきたMVCの進化の中で、
描画部分とModel入力部分が分離された事なんて一度もない。
それは、マウス操作でModelとViewを結合する必要があったからだ。
身近なところでは、ExcelのChartとSpreadsheet、それとExcelのCell同士の参照、
あれを実現するために進化してきたのが今日のMorphicでありMVCだ。

451 :デフォルトの名無しさん:2013/03/18(月) 23:02:12.31
>>449
setTextには文字を表示するという互換があるな。
interfaceでつながってないのは、設計ミスとjava.beansで
できるからっつうコトだろうけど。ちなみに、java.beansを使う環境だと、
JLabelも、JTextFieldも、setText、getTextは、xxx.textってな感じになって
共有できますね。

452 :デフォルトの名無しさん:2013/03/19(火) 04:51:09.39
なんでSmalltalkって廃れたんだろうね。

453 :デフォルトの名無しさん:2013/03/19(火) 06:59:37.44
RubyやPython用のMorphicが登場したり、.NetにSmalltalk移植されたり、
Smalltalkを例にした話題が増えたり徐々にSmalltalkが
復調してる気配があるね。

454 :デフォルトの名無しさん:2013/03/19(火) 07:16:04.12
Morphicは、Objective-C版とjavascript版も出てるぞ
Javaだけ取り残されていくな

455 :デフォルトの名無しさん:2013/03/19(火) 07:16:03.82
>>453
全体に、実務向き言語が退潮気味で、理論指向の言語が地歩を確保したり、
復権傾向にある。Smalltalk,LISP系,Prolog,関数型など。

456 :デフォルトの名無しさん:2013/03/19(火) 07:25:08.39
結論。Javaは糞。

457 :デフォルトの名無しさん:2013/03/19(火) 10:17:46.80
>>452
UNIXライクOSとそれ向けCPU(つまりCマシン)の異常な繁栄が
あるけど、
それ以前にゼロックスが売り方を二重の意味で(アラン・ケイの
考えるパソコンOSでもなく、IDEとしても価格設定やライセンスの
しかたで)間違えたから

458 :デフォルトの名無しさん:2013/03/19(火) 16:07:24.58
http://www.google.co.jp/trends/explore#q=Smalltalk
もりあがっとるもりあがっとる

http://www.google.co.jp/trends/explore#q=Java
http://www.google.co.jp/trends/explore#q=C%23
http://www.google.co.jp/trends/explore#q=Python
http://www.google.co.jp/trends/explore#q=Ruby
http://www.google.co.jp/trends/explore#q=Objective-C
http://www.google.co.jp/trends/explore#q=Scala
http://www.google.co.jp/trends/explore#q=Prolog
http://www.google.co.jp/trends/explore#q=LISP
http://www.google.co.jp/trends/explore#q=JavaScript

459 :デフォルトの名無しさん:2013/03/19(火) 18:57:55.49
>>458
http://www.google.co.jp/trends/explore#q=Squeak&cmpt=q
http://www.google.co.jp/trends/explore#q=Scratch&cmpt=q

460 :デフォルトの名無しさん:2013/03/19(火) 21:23:52.56
右下のRelated termsを見る限り別なもののトレンドなのではないか。

461 :デフォルトの名無しさん:2013/03/20(水) 00:36:54.25
Scratchみたい一般的な単語のトレンドとか何の参考にもならんだろwww
なんだ、SmalltalkerにとってはScratchと検索したら何でもSmalltalk関連かい

462 :デフォルトの名無しさん:2013/03/20(水) 01:15:45.31
DB接続、ファイル入出力、外部API使用、
何をやるにもJavaは冗長で可読性最悪。
言い訳は「そんなの書かなくてもフレームワークがやってくれるし!」

463 :デフォルトの名無しさん:2013/03/20(水) 06:38:58.11
まあフレームワークやライブラリといったソフトウェアスタック無しでJavaを使う意味は無いわな。

464 :デフォルトの名無しさん:2013/03/20(水) 12:29:35.00
一体どの言語ならフレームワークが不要になるのだろうか?

465 :デフォルトの名無しさん:2013/03/20(水) 12:33:36.40
Smalltalk系とかググらんでもだいたいわかるけど、
Javaはググらにゃ判らん事が多すぎる。
APIなんかググること前提だろ。

ちなみに、今はJavaのuninstall方法をググるのが大人気
http://www.google.co.jp/trends/explore#q=java%20uninstall&cmpt=q

466 :デフォルトの名無しさん:2013/03/20(水) 12:35:46.74
>>464
そもそもFrameworkとは何だ?Library全てがFrameworkだと思ってんの?

467 :デフォルトの名無しさん:2013/03/20(水) 12:38:36.35
>>466
フレームワークとは何だ?

Railsとかがフレームワークらしいよ。

468 :デフォルトの名無しさん:2013/03/20(水) 12:38:56.94
List of buzzwords
http://en.wikipedia.org/wiki/List_of_buzzwords

・Enterprise Service Bus[55] – also known as ESB.
・Framework[7]
・Folksonomy[42]
・Fuzzy logic[56]

469 :デフォルトの名無しさん:2013/03/20(水) 12:40:10.31
>>467
FortranにもTesting FrameworkってのがあったねFrameworkとしての共通点はなんだい?

470 :デフォルトの名無しさん:2013/03/20(水) 12:41:12.69
>>468
なにそれ? このリストに入っている奴ってなんなの?
Buzzwordとかもリストに入ってるけど?

471 :デフォルトの名無しさん:2013/03/20(水) 12:43:52.31
>>469
話ずれてるよ。

どの言語でもフレームワークがあるって話だよ。

472 :デフォルトの名無しさん:2013/03/20(水) 12:43:56.10
まぁWeb2.0やCloudと同じ薄ら寒い用語ですしおすし

473 :デフォルトの名無しさん:2013/03/20(水) 12:44:56.69
>>471
そのFrameworkとは具体的に何を指してるのか言ってくれバズワードで言われても判らん

474 :デフォルトの名無しさん:2013/03/20(水) 12:44:58.70
Web servicesもバズワードなんかいw

475 :デフォルトの名無しさん:2013/03/20(水) 12:45:32.62
>>462よ。
フレームワークとはなにか聞いてるぞw

476 :デフォルトの名無しさん:2013/03/20(水) 12:46:53.27
>>474
出典がついてんだから出典読めよ

477 :デフォルトの名無しさん:2013/03/20(水) 12:47:02.17
フレームワークの説明なんてwikipediaに任せればいいじゃん。はい終了。
http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF

478 :デフォルトの名無しさん:2013/03/20(水) 12:48:03.98
日本語のクソペディアを出典にしないでもらえないでしょうか
卒論ですら禁止されてることを大の大人がやって恥ずかしくないの?

479 :デフォルトの名無しさん:2013/03/20(水) 12:48:35.62
>>476
出典ってこれかい?お前こそ読んだ?

http://knowledgemanagement.ittoolbox.com/lp/
Toolbox for IT

We're sorry, but the page you requested was not found.
You will be automatically redirected to the homepage.
If your browser does not support redirects, please click here.
Thank you for visiting Toolbox for IT.

480 :デフォルトの名無しさん:2013/03/20(水) 12:50:00.85
日本語はダメらしいねw
http://en.wikipedia.org/wiki/Software_framework

481 :デフォルトの名無しさん:2013/03/20(水) 12:56:28.02
>>480
>This article needs additional citations for verification. Please help improve this article by adding
>citations to reliable sources. Unsourced material may be challenged and removed. (April 2011)

Wikipedia以外で

482 :デフォルトの名無しさん:2013/03/20(水) 13:03:11.43
>>468
おい、英語のWikipediaもダメらしいぞw

クソペディアを出典にしないでもらえないでしょうか
卒論ですら禁止されてることを大の大人がやって恥ずかしくないの?

483 :デフォルトの名無しさん:2013/03/20(水) 13:05:17.16
オレオレ定義はいらない。
フレームワークの用語の意味を
用語サイトから引用してください。

484 :デフォルトの名無しさん:2013/03/20(水) 13:07:09.95
知りたいならGoogleで「フレームワーク 定義」で検索すればいいじゃないの?

485 :デフォルトの名無しさん:2013/03/20(水) 13:08:07.48
>>484
俺もそう思う。なんで俺に聞くのかわからない。

486 :デフォルトの名無しさん:2013/03/20(水) 13:17:05.97
>>482
じゃもっとマシな出典だしてくれ。お前に任せる。

487 :デフォルトの名無しさん:2013/03/20(水) 13:18:02.88
>>485
自分で説明できない言葉を使うなよ。ルー大柴かよ。

488 :デフォルトの名無しさん:2013/03/20(水) 13:18:26.50
>>486
出典は見つかりませんでした。俺達の負けだ。

489 :デフォルトの名無しさん:2013/03/20(水) 13:19:14.47
>>487
じゃあお前、ルー大柴って言葉を説明してみ?

490 :デフォルトの名無しさん:2013/03/20(水) 13:20:55.19
もう意味がよく判らんしTogetherでもいいんじゃね
多分それでも十分通じると思う。

462 名前:デフォルトの名無しさん [sage]: 2013/03/20(水) 01:15:45.31
DB接続、ファイル入出力、外部API使用、
何をやるにもJavaは冗長で可読性最悪。
言い訳は「そんなの書かなくてもトゥゲダーがやってくれるし!」


463 名前:デフォルトの名無しさん [sage]: 2013/03/20(水) 06:38:58.11
まあトゥゲダーやライブラリといったソフトウェアスタック無しでJavaを使う意味は無いわな。


464 名前:デフォルトの名無しさん [sage]: 2013/03/20(水) 12:29:35.00
一体どの言語ならトゥゲダーが不要になるのだろうか?

491 :デフォルトの名無しさん:2013/03/20(水) 13:22:00.01
>>490
全くわからんw

276 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)