やっぱり動的言語では安全なソフトは作れない 3

前スレ
http://hibari.2ch.net/test/read.cgi/tech/1306571666/

大都会が2げとじゃ

このスレは、大都会が占拠したけぇの、
これからこのスレに書き込んだヤツは漏れ無く
大都会都民じゃけぇの。

いろいろウルサイこという上がいるとき　→　Java
そこそこ自分できめちゃっていいとき　　→　Scala
おれおれツール　　　　　　　　　　　　→　groovy

Java育ちの00年グラマーは、どう風呂敷を広げようが所詮Javaの井戸からは出られないのか。

カフェイン中毒ですから

　型云々じゃなく、もっと実行時メタ機能の方向で動的言語は語れないか？

>>4
もう飽きて面倒くさいとき → BeanShell

3スレ目とか、意味が分からないよ。

また不毛なスレか…

言語自体が動的と静的の両方いけるようになりつつあるこのご時世に何やってんの

結局は人間依存

>>10
両方できる言語であっても動的型付けで書いた箇所については
柔軟性が得られる代わりに静的な型安全のメリットは得られなくなる
静的と動的がトレードオフの関係であることは従来と変わらないよ

> 言語自体が動的と静的の両方いけるようになりつつあるこのご時世に何やってんの

動的言語は静的いけませんｗ

>>13
動的言語で安全なプログラムが組めるPGは
静的/動的両方使える言語でも安全に組める

一方、動的言語じゃ安全なプログラムを組めない
Java土方には使いこなせない

それだけの話

>>13
「動的な機能を持つ言語」が常に動的に実行されるとは限らない。
「全部でなくてもいいのなら」静的に整合性チェックをすることは可能だ。

全体の安全性を語ってるのに個人の資質に還元しようとする。
頭悪いの？

>>16
全体の安全性って何？
一部のPG（Java土方）が低能すぎて動的言語で
安全なプログラムを組めないのは事実だとしても、
それをスレタイのような一般論に拡張すんなよ

動的言語が広まった理由の一つには、自動テストがしやすいからって側面がある。

そもそも「静的チェックで全体の整合性をチェックできる」ってのが幻想なんだよ。
ビルドエラーだけで全ての問題が解決できるならテストは不要なはずだろ？

実際には静的動的の両方で自動や手動のテストを行うわけだ。

この部分で動的言語は静的言語に比べて良い仕事をする。

CやC++ではABIが弱すぎてテストの自動化で不利だし、
Javaではリフレクション周りのコードがかったるくて重量級のフレームワークの出番になる。
たとえば、import不可のinterfaceをコールバック引数に持つメソッドの呼び出しとかな。

これが動的言語だと、
「モジュールを公開するときはテストコードもセットにするのが当然」という状態になっている。
perlですらそうだ。 http://gihyo.jp/dev/feature/01/test-perl

言語の規格や各処理系の実装や開発者層の問題ばかりで
動的・静的であること自体に起因する問題が皆無

各種言語が静的に回帰してるのに何言ってんだ

静的型付けと動的型付けはトレードオフで
メリットがデメリットを上回るなら動的言語を使えば良い
安全性もテストで確保出来る

たったこれだけのことなのに、Java土方が「Java以外認めん！」
って鼻息荒くしてるだけだろ

大規模開発じゃデメリットが顕著って話なのに

大規模開発の問題点ってコードの整合性よりデータの整合性の方が大きいだろ？

データに関して言えば、SQL自体が動的言語だからなｗｗｗｗ
コードに関して言えば、動的言語を使うと規模を大幅に縮小できるケースもある。

ちなみに俺がみた土型コードはこんなだった。

O/Rマッパーのためにデータクラスを書き
Beanのためにデータクラスを書き
MVCのためにデータクラスを書いていた。

全部同じデータなのに。
設計した奴死ねよ

ほんとに静的型言語らしいご利益があるのってMLとかHaskellぐらい。
Java程度ならCとたいして変わらん。

MLとかがバグが出にくいのは副作用が無い/少ないから。
だからユニットテストが機能しまくる。

動的言語でも副作用のある関数に!付けたりして
区別するようにしてるとバグが出にくい。

>>22
文章に"土方しか集まらないから"が抜けてますよ？

ひじかたわきすぎ


動的言語だと、行数小さくなるから

　JAVA（笑）で作った物と比べて格段に小さくなって
　JAVA（笑）でかかれたら大規模に見えても
　　動的言語（神）かかれたそれは大規模とみなされないことってあると思う
　JAVA（笑）だと動的言語では本来かかなくてもいいコード沢山かいているとおもうし

そもそも
　JAVA（笑）はひじかた言語でしょ？
　ひじかたを効率よく使う為に、三マイクロ社が作った奴隷用言語でしょ？
　趣味でJAVA（笑）やってる奴なんて･･･？

？
　？？？

作った奴等がLisp無双だったんで、その反動から一周遅れぐらいでC言語っぽく
なったのがJava。ポストCobolみたいになったのはたまたまのなりゆきだろう。

GoslingはLisperじゃないと思うが

それにJavaは明らかにポストC++を狙ってたと思う
C/C++に似てるのは偶然じゃない

見たことないから知らないんだけど、
Gosling EmacsのMock LispはLispではなかったのだろうか。

調べてみたら確かにLispではなかったようだ。
Mockだしな…

しかも実装はCだしな
もうEmacs使うのやめようぜとか言ったり、
あんまりLisp好きじゃ無い印象

>>29
そこでなぜ、C#やC++と比べ無いのだろう。。。。

動と静をあわせ持った言語って無いの？

C#はそうじゃね？

C++

ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ
ＪＡＶＡはｋｓ

結論はいつも、C#最強

そうなんだよね
.NETってものがあるのに、JAVAがそれ無視して突っ走る理由が意味不明
素直に負けを認めて消えろよJAVA
たとえ自分たちがどれだけ先進したもの作ったとて、
この世界では一瞬で真似されるんだから、「商売」が成り立ってること事態奇跡であって
マジでレベルの高い奴らに目を付けられていない瞬間にしか儲けられない、とても運のいいことなんだよ
.NETを触る新言語を作るならまだしも、それ以外はもういいです
古い概念をいつまでも大事にしているJAVAは消えてほしい

JavaVMは、CLRとまだまだ対抗できる。
Java vs C#の勝負はついた。

>>36
> 動と静をあわせ持った言語って無いの？

それは静とみなされるｗ

動的言語なら静的言語の半分以下の量でコーディングできるって
豪語していたやつがいたから、

じゃあ、なんで半分の時間でできないの？
給料も半分でいいよね？って聞いたら
ブチ切られたｗ

ああ、書いた行数で金を貰ってるのか。
理解できた。

書いた行数が短いから動的言語は有利と
言ってるやつがいるからバカにされてるだけだよｗ

ただでさえ巨大なプログラムに
やたら複数行に渡ったコメントかいてるソース多いからな
ソースコードの中に含めなくても良いデータや、
そのプロジェクト内のライブラリフォルダを作るべきようなものまで散らかってると殺意覚える
読みにくいから行数を減らす努力しろと
関数の手前にかかれたコメント読んだ所で、結局「わかった気」になるだけで
本当にソース理解する為にはコメントではなくソースを読まなければならない
それかせめて別拡張子のソースコードにするとかさ
未だに行数気にしてる奴多いだろ
10万超えのソースコードってソース読んでると大抵、肥大している原因はコメント量と
外部ファイルにしておくべきデータをソース内に入れてることにある
俺は10万行もかいてるぜ（キリッ）　ですかあ？
ぼくはウィンドウシステムからテキストエディタ作ってもそこの実装部分300行程度しかないよ
SHIFT,CONTROL,END,HOME,BACKSPACE,SPACE,DELETE,PAGEUP,PAGEDOWN,大文字小文字,各種,記号入力も対応させてその程度
静的言語でやったら10倍に膨れ上がると思う

実際、動的言語でかいたらソースコード量は半分どころの削減ではなく
静的言語と違ってリファクタリングしていけば無限に縮まるから（ メタまでやっていいなら限界なし ）
どの程度まで「動的にコードを生成」やっていいのかによる

などと、長いプログラムが読めないバカが申しており

perlとかPOD前提の言語をdisってるとしか思えない

>>44
Java土方に比べたら時間も半分どころじゃないと思う
ていうか、Java土方ってまともにプログラミングできるの？www

>>48
残念ながら客観的にみても長いプログラムかくほうがバカっすよ･･･
短くしないほうがかくのは簡単だからねぇ

Aクラス、Bクラス、Cクラスとあって、それぞれの共通データがあるとき
君たちゴミは一階層上にDクラスを作るんだと思うけど、

これはリファクタリングした場合、ひとつのクラスにすることが出来る
そうするとクラス数は4分の1、ソースコード量は、A〜Cのクラスを1つにまとめた時点で最低でも3分の1にはなってる

この手のリファクタリングは大変だから静的言語じゃまずやんねーよ
それぞれの引数の型や戻り値とか色々変えなきゃならなくなるんだから
流石に面倒くさいを通り越して効率が悪い

javaコードをscalaコードにしたら1/3ぐらいは余裕なんで
動的な言語のほうがが静的な言語よりコード量が云々っていう意見が無くなる未来がそのうちくるかもね
まあこなそうだけど

scalaは別にダックタイピングはサポートしてないからな。
関数オブジェクトがあるのと、型の生成と推論がしやすいだけで。

だからコード量が短くて済むってことはプログラミングの粒度が粗いってことだと何度（ｒ

>>54
正規表現で一発ってコードとちまちま文字列操作してるコードは粒度おんなじ。

scalaはStructural Subtypingっていう静的ダックタイピングみたいな機能あるけど全然使われてない
C#のusingマネるコードでしか見たことないな

>>54
ハッアアアｗＷｗ？？ｗｗｗ？？？
自分が冗長なコードかいてることに、
そういう見苦しい良いわけ言うのやめろよ･････
おまえみたいなゴミが何をいったところで動的言語よりもコード量が増えるっつうのは静的言語の負けてる部分だってのに
それを･･･････ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

粒度が粗いってことはファンクション単位のスニペットの流用がやり辛いってことなんだよん
大味なアプリケーションしか書けない＆動作が緩慢で小回りがきかない巨像。それが動的言語の正体。

コード無しだと水掛け論だね

ま、簡単なところで、一昨日Pythonスレで何故か盛り上がった
辞書の辞書にリスト入れるケースがどれくらい書き易いか
やってみたら？
ttp://hibari.2ch.net/test/read.cgi/tech/1305217361/287

# Python
from collections import defaultdict
hash = defaultdict(lambda: defaultdict(list))
hash['a']['b'].append('111')

# Ruby
hash = Hash.new{|h,k| h[k] = Hash.new{|h2,k2| h2[k2]= []}}
hash['a']['b'].push('111')

# Perl
push(@{$list{'a'}{'b'}}, '111')

なんだ、Perl最強じゃん
他は冗長だからカス

>>56
型の構造同値、なぜか流行らないよな。
Modula-3,Ocamlでもそうだった。
なぜだろ？

ダックタイピングはコード短くなるしお手軽だけど、効率に目をつぶり、問題をテストに押し付けてるだけ。

>>59
// Java

import java.util.*;
class Foo
{
    public static void main(String args[])
    {
        HashMap<String,HashMap<String,LinkedList<String>>> hash =
            new HashMap<String,HashMap<String,LinkedList<String>>>();
        HashMap<String,LinkedList<String>> h;
        if (hash.containsKey("a") && hash.get("a") != null) {
            h = hash.get("a");
        } else {
            h = new HashMap<String,LinkedList<String>>();
            hash.put("a", h);
        }
        if (h.containsKey("b") && h.get("b") != null) {
            h.get("b").add("111");
        } else {
            String[] s = {"111"};
            h.put("b", new LinkedList<String>(Arrays.asList(s)));
        }
    }
}

>>63
そのテストを用意するのが動的言語では効率いいからな。
静的言語ならテスト不要になるわけでもない。

>>64
＞hash.containsKey("a") && hash.get("a") != null
これは単に冗長。 hash.get("a") != null だけでいい
ほかにもわざとやってるんじゃないかと思うくらい冗長に書いてある。

import java.util.*;

public class Test1 {
　void foo(String k1,String k2,String v){
　　HashMap<String,HashMap<String,List<String>>> mm = new HashMap<String,HashMap<String,List<String>>>();
　　HashMap<String,List<String>> m = mm.get(k1);
　　if(m==null) mm.put( k1, m = new HashMap<String,List<String>>() );
　　List<String> l = m.get(k2);
　　if(l==null) m.put( k2, l = new ArrayList<String>() );
　　l.add(v);
　}
}

せいぜいこんなとこか。
でも Autovivification の有無って静的動的関係なくね？

JSONObject でも使っていいならもっと減るな。

haskellやscalaのコードも見たいな
誰か書ける人居ない？

class MyHashMap<K,V> extends HashMap<K,V>
{
    public V get(K key, V value) {
        if (get(key) != null) {
            return get(key);
        } else {
            put(key, value);
            return value;
        }
    }
}

みたいなクラスを用意しとけば2行になったよ

MyHashMap<String,MyHashMap<String,List<String>>> hash = new MyHashMap<String,MyHashMap<String,List<String>>>();
hash.get(k1, new MyHashMap<String,List<String>>()).get(k2, new ArrayList<String>()).add(v);

総称型で V v = new V(); が出来れば
hash.get(k1).get(k2).add(v);
って書けるようになるんだけど

>>69 のコードは必要ない場合までnewしてていくらなんでもNGだろう。

静的型チェックを維持したままやるなら、
ruby のコードみたいに、デフォルトの値を設定するコールバックを用意するのがスジ。

てーかScalaの例がみたい。
implicit def でvivification対応のメソッドも後付できるし、
デフォルトの値を設定するコールバックを指定/記述する部分も簡潔にいけそう

>>70
もっと短くなるね。

>>72
Javaだとコールバックの記述が無名クラスだから、どうしても冗長になるよな…
finalつけないと値を覚えてくれないとかも正直ぎこちない。

コールバックバージョンぷりーず

>>72 じゃないけど、
派生型がアリならこんなとこか
Scalaなら派生型ナシでもっと短く書けるし、静的言語ならどうという例には向いてないんじゃないかコレ

import java.util.*;

public class Test1 {
　abstract class MapBase<K,V> extends HashMap<K,V> {
　　abstract V make();
　　V prepare(K k){
　　　V v = get(k);
　　　if( v== null ) put(k,v = make());
　　　return v;
　　}
　}
　class M extends MapBase<String,List<String>>{
　　@Override List<String> make() { return new ArrayList<String>(); }
　}
　class MM extends MapBase<String,M>{
　　@Override M make() { return new M(); }
　}
　void foo(){
　　new MM().prepare("a").prepare("b").add("111");
　}
}

静的言語の特徴はともかく、Javaの特徴はでてる

>>60
Ruby や Perl の push と Python の append て同じような動作なの？
push はリストの先頭に、append はリストの最後に加えるイメージ。
そのどれも詳しくないけど。

scalaでなんも考えずにやるとこんな感じか

import scala.collection.mutable.{Map, Buffer}
val hash = Map[String,Map[String, Buffer[Int]]]()
hash.getOrElseUpdate("a", Map()).getOrElseUpdate("b", Buffer()) += 111

>>77
全部末尾に追加

元ネタは2タプルがキーの辞書みたいだね、そっちでいいならそっちのが簡単だ

import scala.collection.mutable.{Map, Buffer}
val hash = Map[(String,String), Buffer[Int]]()
hash.getOrElseUpdate(("a","c"), Buffer()) += 111

>>75
M と MM が最高にダサイ

>>77
Perlのpush/popは末尾、unshift/shiftが先頭

Javaはコードを書くと同時に
テストコードを書いてると思えばいい。
あの長さにはテストコードが含まれてる。

動的言語で同等のテストコードを書いてみ。
Javaと同じで型チェック程度でいいからさ。

そうすると、動的言語も静的言語も
違いはなくなる。

つーか他人のPerlのコードなんて読めないじゃん

>>83
意味不明というかただの妄想に聞こえる

>>83
>>66のfoo()をPython2.7で型チェック含めて書いてみた

from collections import defaultdict
from anntools.validation import *
@validate(k1=Str, k2=Str, v=Str)
def foo(k1, k2, v):
    hash = defaultdict(lambda: defaultdict(list))
    hash[k1][k2].append(v)

foo('a', 'b', '111')
foo('a', 'b', 111) # Error!

>>78は>>69と違って必要無いときは
getOrElseUpdate()の引数のMap()やBuffer()は実行されないんだよね？
Scalaいいね

うんgetOrElseUpdateの第2引数はcall-by-name(名前渡し)

>>85
意味不明じゃないよ。

型をしっかり書くということは
エラーチェックになっている。
それらの型以外が入らないわけだから。

動的言語でそれをやったところで、実行時にしかわからないわけだから
片手落ちにしかならないが、それでも型チェックを
加えてみって話。

むしろ「あれだけの長さのコードを書いて型チェックしかできない」のが問題なんだろう

Slacaの例とJavaの例を比較して、Javaの例が有利なポイントはゼロ。
なので >>89 の論旨はおかしい

Scala のタイプミス

短い例では動的言語が短くかけるけど、
通常のアプリのような
それなりの規模のものは、
動的言語で書いても全然短くならないんだよな。
なんでだろ？

短く書けるのは想定の範囲内だけ

>>93
そりゃ君が動的言語に向いた設計をできてないからだろ

動的言語に向いているのは短いプログラムだけだろ

反例がいくらでもあるが、
その前に「短いプログラム」じゃないのはどの程度の規模になるのか尋ねておこうか

動的言語が向いているのは
静的言語がIDE立ち上げてプロジェクト作るのに
かかる時間内に書ける程度までだろ

>>98
gmailのブラウザ側スクリプトすら書けなさそうだ、君には

ブラウザスクリプトも静的言語の方が向いているよ
今はJavaScriptしかのってないから仕方なく動的言語使っているってだけで

「動的言語で書いても全然短くならない」と
「ブラウザスクリプトも静的言語の方が向いている」は全然別のことを言ってるんだが、分かってるのかな

インタプリタなら動的言語の方が実装が簡単。

>>101
全然別の話題を唐突に語りだしたのはおまえだよ、馬鹿

規模の大きなコードの例だろ？ なにが全然別なんだよ

まだいたのか、この馬鹿

え、動的言語使ってもJavaより短く書けないの？
どんだけ低能なんだよwww
ふつーのPGならJavaよりは圧倒的に短くなるよ？

てーか設計が静的言語と同じなら静的言語と同じ程度の構成にしかならんわな。
コーディングの問題じゃないよ。

>>102
あれ現在最もインタープリタやコンパイラなどの言語処理を簡単にかけるのはMLとかの
静的言語だと思うけど。

>>108
コンパイラは静的言語の方が簡単。

もっとも簡単に書けるのはBrainf*ck

>>100
GoogleやTwitterはJavascript直接書いたりなんかしない。
静的ツールを使って自動生成しているよ。

大抵のコンパイラ/インタプリタは
C/C++を除けばその言語自身で書かれてることが多い

動的言語が使えるのは一回きりの使い捨てスクリプトのみだな。

動的言語では人間が書かなければならないテストが膨大になってしまう。
静的言語ではケアレスミスはだいたい型チェッカがとってくれて、人間は
本当に大切なアプリケーションロジックを中心にテストできる。
これは重要だと思う。

このスレには動的言語でテスト書いてる人ってどのくらいいるんだろう
動的言語のテストってのはこういうもんだ！って
具体的な話になっているのをPart1から3までで見たことが無い

型チェックとか範囲指定とかは必要なら>>86みたいに書いてるよ俺は
あとはPythonに付いてる標準のunittest使ってるわ

こういうもんだ、って話なら実際に見た方が早いな。
http://cpansearch.perl.org/src/TIMB/DBI-1.616/t/

LLVMを使った静的スクリプト言語がブラウザに載るとき、
デスクトップアプリとWebブラウザアプリの性能差がなくなる。
むしろJVMなんか使ったものより快適になるのでは

>>114
テストをちゃんとすると動的言語の方がより膨大なコード量になってしまうし、
拡張や変更のコストも大きくなってしまう。
テストをちゃんと考えるべきシステムは動的言語から静的言語へ移ってきてるよ。

>>115
動的言語は型チェックってすることが多くないからなあ
むしろインタフェースに重点を置いて
引数はreadってメソッド持ってる？って調べることが多い

テスト文化の先端を行くRuby使いはいませんか

>>86
これ書くくらいなら
静的言語使ったほうがいいような

>>120
本当に必要なとこだけ書くんだよ
あとデコレータ駆使すれば型以外にも様々なチェックが
短いコードで出来る

そもそも安全なソフトなんていらないの
クラッシュしたら修正して再起動すればいい

>>121
本当に必要なとこってどうやって決めるの？
判断ミスしたりしないの？

>>121
そんなんだから動的言語は信頼性が低いとかバグが多いとか言われるんだよ。
動的言語でWebサイト作ってインターフェイスのバグによって決済が行われず、
訴訟問題に発生した例も知ってる。
バグの原因はメソッド名のタイポだぜ、あほらしい。

だからテストが要る
動的/静的型付け言語どちらであっても、真面目にテストを書いたら
コード全体の半分以上はテストになってしまう
実際グーグルのソースコードはそんな感じらしいが……

>>123
公開してるインターフェースでかつ
総称的な振る舞いが期待されない関数だけに
チェック付けてるな

判断誤りの可能性はあるが、俺は問題になったこと無い

>>124
お前のようなアホはSQLインジェクションで氏ね

>>124
ちょっとしたコード書くだけで>>75みたいになる言語じゃ
テストなんて面倒くさすぎるのかもしれんが
同じコードが動的言語だと>>60だからね
そりゃテスト書いてもおつりが来るよ

pythonってインターフェースを非公開にできたっけか？

>>129
_プレフィックス付きは非公開という暗黙の了解が

>>128
テスト書いてみてよ

>>131
本当はtest()にずらずら書くけど、それは長くなるから


import unittest
from collections import defaultdict
from anntools.validation import *

@validate(k1=Str, k2=Str, v=Str)
def foo(k1, k2, v):
    hash = defaultdict(lambda: defaultdict(list))
    hash[k1][k2].append(v)

class TestFoo(unittest.TestCase):
    def test(self):
        foo('a', 'b', '111')
        self.assertRaises(ValidationError, foo, 'a', 'b', 111)
        self.assertRaises(ValidationError, foo, 0, 'b', '111')
        self.assertRaises(ValidationError, foo, 'a', 0, '111')

if __name__ == '__main__':
    unittest.main()

このテストって動的言語の利点ゼロだけど、お題があれだから……

テストが増えたら動的言語のいいところがなくなる。
VB6がクソミソに言われながらも、実用場面で広範囲にわたって使われたのも皮肉。

C++

#include <map>
#include <string>
#include <vector>
int main() {
using namespace std;
map<string,map<string,vector<string> > > h;
h["a"]["b"].push_back("111");
}

C++かわいいよC++
超高速なLLとして使ってるぜ

>>134
Variant型使いまくりのVB6で静的言語とかただのネタだろ。

静的言語なら常に型チェックを行うわけじゃないんだぜ

で、静的言語の信者の人はSQLやJSONはどうやってるんですか

データと型が一致しないんじゃ「静的言語だから型チェックは大丈夫」とかただの念仏ですよね

>>135
じゃあ今度はJavaのようにAutovivificationしないバージョン書いてみて

>>86
これってコンパイル時にエラーになってくれるの？

>>137
VB6でVariantはあまり使わない。外部のクラスを扱うときにObjectが多用されるぐらい。VB(COM)にinterfaceあるって失念してる人多いな。

JSONとか簡単じゃん

boost::property_tree::ptree pt;
read_json("hoge.json", pt);
cout << pt.get<string>("hoge") << endl;

>>142
データに対する何のチェックもないよねそれ

チェックしたければすればいいじゃん

>>144
スレタイ嫁

>>140
無理

今のJavaScriptなんか捨ててActionScript3相当を標準にして欲しい。

むしろブラウザに仮想マシンのっけて好きな言語で開発させれ

ブラウザのJavascriptでLinux動かして
そのLinux上で好きな言語使いなよ

phpみたく、他の言語もインストールしたら、サーバ側でhtmlタグ埋め込みで記述出来るようにはして欲しいかな

ActionScript最強伝説

>>151
まあ・・・なんだ、あんたも大変だな

良い言語だけどね、AS3。良い感じでJavaScriptの進化形。
使える場面が限定されすぎるのが残念だ。

あれならJavaのほうがいい
マジで

バージョンが上がるほど静的になっていくActionScript

未だに型宣言しないで動的にも書けるんだけれども静的な書き方の恩恵が
でかすぎてAS3ですっかりJavaチックな書き方が浸透したと思う。

>>154
Javaチックだけれどもクロージャが書きやすい点は良い > AS3

関数オブジェクトのシグネチャを検証しないのは物足りないし、ジェネリクス
欲しいし、変数が関数スコープとかウンコだけれども。

なんで短いコードなら動的言語は圧倒的に少ない行数でかけるのに、
普通のプロジェクトでは大差がないのか考えてみた。

１．動的言語は基本的な命令がライブラリをロードしないで使える。
printとかなにもロードしないで実行出来る。だけど実際のプロジェクトでは
他に多くのライブラリを使用するので差がなくなる。

２．動的言語は変数を宣言しないで使える。
だけど実際のプロジェクトではstrictとかwarningをONにするので結局変数宣言している

３．動的言語はクラスを書かなくて良い
だけどある程度大きくなると必然的にクラスを使わないと管理しづらい。
フレームワークを使うとほぼ必然的にクラスを使うことになる。

４．関数を作らない前提の比較だから
短いコードでは基本的に関数を作成しない。実際のプロジェクトでは関数を
作ることで大幅にコードの削減をしているが、短いコードの例ではその利点が生かせない。

こんな所かな？
他にもあったら教えてください。

クラスベースになったのにクロージャ必要か？

まず「クラスベース」は目的じゃない。

は？

C++でクロージャかいてみればわかるのにな

C++でクロージャかけないんだが？
かけるのは関数オブジェクト。

クロージャというのなら、クロージャを定義した場所（関数）の
ローカル変数が見える必要がある。

このスレは、大都会が占拠したけぇの、
これからこのスレに書き込んだヤツは漏れ無く
大都会都民じゃけぇの。

>>163
ローカルクラスは、staticなローカル変数にアクセスできる。
普通使わんけどな。

staticだから駄目

>>112
インタプリタで書かれたインタプリタか、胸熱じゃな。

JavaScriptやActionScriptの「クロージャ」の恩恵は中から外の環境の変数を
参照できるというクロージャ本来の特徴よりも、単に無名関数をより少ない
記述量で宣言できるという記法的な面の方が大きいと思う。
(functionって書かなくて良い分Rubyとかの方がより楽だけど)

Javaの無名クラスはウンコ。ノイズが多すぎる。

class can_divide {
int n_;
public:
can_divide(int n) : n_(n) {}
bool operator()(int x) const { return x % n_ == 0; }
};

クロージャーって
メソッドを二つ持っているオブジェクトを
代入したいようなときってどうするの？

>>170
どういうことだ

>>158
何を持って動的としてるか解からんなぁ。
タダの動的型付け言語のことをいうとるんじゃろうか。

>>169
int function()
{
static int n;
struct _:interface<int>
{
bool operator()(int x) { return x % n_ == 0; }
} closeure;
algorithm(static_cast<interface<int>&>(closeure));
}

ローカル変数の意味がC/C++とちがうというだけ

C/C++に高級なローカル変数がないと言いたいのか？

高級なローカル変数ｗ

高級なローカル変数
>>234

>>158
動的言語で短いコードを書くためには、実行時メタ機能などを
使いこなす必要があるが、土方レベルのPGには使いこなせず、
静的言語にもある機能だけでプログラム書くから

    だから、土方が動的言語を使っても短く書けない

class Silver {
public:
    const Platinum to_platinum() = luxury;
    const Iron to_iron() = cheap;
};

ら、らっくすうりぃ

>>178
じゃあ、責任持って
実行時メタ情報とやらを使うのと
使わないのとでどれくらい差があるかを
例示してね。できなきゃ笑おう。みんなでｗ

>>181

まずは>>158が
> なんで短いコードなら動的言語は圧倒的に少ない行数でかけるのに、
> 普通のプロジェクトでは大差がないのか考えてみた。

と言っているので、大差ないという例をコード付きで示してもらおう。
そして、そのウンココードを見て笑おう。

そのあとなら、そのウンココードを短くしてあげても良いよwww

>>158
何が「こんなところかな？（ｷﾘｯ)｣　なわけ

＞普通のプロジェクトは大差ないって、
はぁあ？　どこのプロジェクトを比較してんの？？？

＞変数宣言に関しては
静的言語だろうとハッシュ利用すれば宣言なしで使えるし
動的言語でも、変数宣言は行うから。　いきなりコードの途中から変数つくって使ったら
可読性下げるに決まってんだろ、　だから土方には仕えないって言ってるんだよ

＞クラスをかかなくていい？
は？　ｗｗｗｗｗｗｗｗ　動的静的かんけいねえよｗｗｗｗｗｗｗバカなの？？Wwwww
アルゴリズムレベルでもの考えろよｗｗｗｗｗｗｗｗ

＞関数
は？？？　関数を作ることでコード削減って意味不明
関数も含めてソースコードだろうがｗｗｗｗｗｗｗ
つうか何？？　オブジェクト指向限定でもの言ってんの？???ｗｗｗｗｗｗｗｗｗ
まずそこからして以下略


よく考えてから書き込みしてくれ･････・・・・・・・・・・・・・・・・・

>>182
気持ち悪い　氏ね

つーか短く書けるってのは言語の評価軸のひとつにすぎない
短く書けても他にデメリットがあるなら全体としての評価は下がる

Perlで短く書かれてるときの絶望感ｗ

単純なコードでなければ、ライブラリの有無で決まるんじゃないの。

動的言語はPython3やRuby1.9程度の小変更で
移行に苦労しているからな
大規模プロジェクトに使うなんてとても無理

>>182
じゃあこれで
https://github.com/edavis10/redmine/blob/master/app/controllers/projects_controller.rb

>>188
Ruby1.9やPython3レベルの"後方互換性の無い"変更が
Javaで起こったら暴動が起きるレベル

>>158を静的動的関係ないって言ってる人たちは>>60とか>>64の段階でそれに突っ込んでれば
こんな話にはならなかったのにねえ。

>>189
それそれ。
結局ある程度の規模になると、
どうしてもそういう風になっちゃうよね。

あまり短くなったと思えない。

てーか>>158は本質を分かってないんじゃないか
動的言語だって関数もクラスも書くけど、問題はそこじゃなくて「どう書くか」なんだよ

たとえば「あるモジュールのあらゆるメソッドの呼び出しの前後に処理を挟みたい」とか
静的言語だと悪夢だけど動的言語だとそうでもない。

たとえば「コールバック引数を受けとるeachメソッドを使うようにしたら、呼び出し側の記述量が逆に増えた」とか
言語によっては全然増えない。

そういう「動的言語なら簡単に書ける」設計をしないんなら、そりゃ静的言語と大差ない記述量になるだろう。

> 静的言語だと悪夢だけど動的言語だとそうでもない。

静的言語でもそうでもない。

たとえばJavaならAspectJを使えばいい。
また実務なら何らかのフレームワークを使うわけで、
そのフレームワークにフィルタやフックなどの名前で同じことができる。
springフレームワークにもAOPの機能がある。

そう、ここに書き込める程度の小さい例なら言語に搭載している分
短くかけるが、実務なら言語に搭載してなくても、ライブラリによって補完
するわけで大差がなくなるわけさ。

「動的言語なら簡単に書ける」設計が
メソッドの前後に処理を入れていくことで
創り上げる設計なのか？

オブジェクト指向設計や
構造化設計なら聞いたことあるが
動的言語設計なんてのは聞いたこと無いな？

どうせ動的言語でも設計はオブジェクト指向とかなんだろ？

>>182
これと同等のコードを静的言語で何行でかける？
まぁ、Boost使えば1行で済んだりはするけど。
function Example( object )
{
     object.ExampleHoldMethod = object.Method;
     object.Method = function( arg )
     {
           object.ExampleHoldMethod("preset",arg);
     }
     with({ result:othreObject.Method( object ) })
     {
            object.Method = object.ExampleHoldMethod;
            return result;
     }
}

>>182
やっぱ本質を分かってないよ。

それと同じことをするコードを0から作ったら
行数は増えるよ。

だけど、現実にはそんなことをするための
ライブラリを使うことで、わずかの行で済む。


まさにこう言うことじゃないか。
> ４．関数を作らない前提の比較だから
> 短いコードでは基本的に関数を作成しない。実際のプロジェクトでは関数を
> 作ることで大幅にコードの削減をしているが、短いコードの例ではその利点が生かせない。

全然意味の無いプログラムでいいなら
以前Pythonスレで見たこれを静的言語で書いてみてほしい
興味本位なんで言語の優劣とは関係なしで

def nesteddict():
 　return defaultdict(nesteddict)

d = nesteddict()
d[0][1][2][3][4] = 5

動的言語では、関数を置き換えるのが仕事ですｗ

今日もバグってる関数が見つかったら。
今すぐ入れ替えます！と答えてる。

>>199
defaultdictという関数の実装を教えてくれ。

そろそろ動的言語原理主義者みたいなの現れないの？
動的言語で作られたソフト以外は拒否するみたいな

なんでオブジェクトありきでしか動的言語を語れないんだ？

let prefix = "Text";
let function = prefix & "Output";
function("text");

こういうメタシステムでも動的だろもっと視野を広げろよ。

本物の実装じゃないみたいだけどこんな感じか？
Pythonしらんから良く解らんが、これをJavaで書けばいいのか？
今度はdefault_factoryの実装が必要になりそうだが。
http://d.hatena.ne.jp/odz/20071216/1197817317

class defaultdict(dict):
　　def __init__(self, default_factory = None, *args, **kwargs):
　　　dict.__init__(self, *args, **kwargs)
　　　self.default_factory = default_factory

　　def __missing__(self, k):
　　　if self.default_factory is not None:
　　　　self[k] = self.default_factory()
　　　　return self[k]
　　　else:
　　　　raise KeyError(k)

まあ、結局はコードが短く書けるかどうかってのは、
そういうクラスが用意されているかの問題でしかない。

>>203
それ、VBのCallByNameみたいなもんか？

>>201
defaultdictは辞書（ハッシュマップ）のコンストラクタで、
Autovivificationするときに引数にとったクロージャを
オブジェクトの生成関数として使う

しつもんです

JAVA（笑）でこれかくとどうなるんですか

require"ostruct"


v = OpenStruct.new ({ :x => 11 , :y => 22 })

p v.x
p v.y
p v.n = 99

しつもんです

C#（笑）でこれかくとどうなるんですか


p ("1".."9").map(&:next).map(&:to_i).inject:+


def a
p 1
yield iterator?
p 3
end
a do p 2 end

しつもんです

C＋＋（笑）でこれかくとどうなるんですか


("a".."f").each do | m |
  if "b"==m.."d"==m
    p m
  end
end

しつもんです

これを静的言語でかくとどうなるんですか？


a = "："
b = "\\(.*?\\)"
"209 ：uy ◆yyC0rYWEq2 ：2011/06/24(金) 03:37:22.64 " =~ /#{a}(.*)#{b}/

$1.split(//).take(20).each_slice(3)
.each_with_index.each_with_index.each_with_index.each_with_index.each_with_index.each_with_index.each_with_index.each_with_index.each_with_index
.each_with_index.each_with_index.each_with_index.each_with_index.each_with_index.each_with_index.each_with_index.each_with_index.each_with_index
.each_with_index.each_with_index.each_with_index.each_with_index.each_with_index
.each_with_index do | ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( a , z ) , y ) , x ) , w ) , v ) , u ) , t ) , s ) , r ) , q ) , p ) , o ) , n ) , m ) , l ) , k ) , j ) , i ) , h ) , g ) , f ) , e ) , d ) , c ) , b ) |
  print a , b , c , d , e , f , g , h , i , j , k , l , m , n , o , p , q , r , s , t , u , v , w , x , y , z
  puts
end

しつもんです　　これをゴミ･･･いや静的（笑）言語でかくとどうなるんですか？
kiu =[
[ "K_SPACE" ] ,
[ "K_COMMA" ] ,
[ "K_PERIOD" ] ,
[ "K_SLASH" ] ,
[ "K_YEN" ] ,
[ "K_COLON" ] ,
[ "K_SEMICOLON" ] ,
[ "K_BACKSLASH" ] ,
[ "K_LBRACKET" ] ,
[ "K_RBRACKET" ] ,
[ "K_MINUS" ] ,
[ "K_AT" ] ,
[ "K_PREVTRACK" ] ,
]
kiu2 = [" " ,"," ,"." ,"/" ,"\\" ,":" ,";" ,"_" ,"[" ,"]" ,"-" ,"@" ,"^" ,]
kiu3 = [ " " ,"<" ,">" ,"?" ,"|" ,"*" ,"+" ,"_" ,"{" ,"}" ,"=" ,"`" ,"~" , ]
aru = ("a".."z").to_a
suu = ("K_0".."K_9").to_a.rotate
suu2= ("0".."9").to_a.rotate
suu3= (" \! \" \# \$ \% \& \' \( \) 0").split
nnn = aru.to_a.size + suu.to_a.size + kiu.size

p keytable= [ ( ["K_"]*aru.size ).zip( aru.map(&:upcase).to_a ).map(&:join) , suu , kiu ].map(&:to_a).flatten
.zip( [:default]*nnn ).zip( [aru , suu2 , kiu2 ].map(&:to_a).flatten )
.zip( [:shift]*nnn )
.zip( [aru.map(&:upcase) , suu3 , kiu3 ].map(&:to_a).flatten )
.zip( [:control]*nnn ).zip( [""]*nnn ) # .zip( [":command"]*nnn ).zip( ["<command>"]*nnn )
.flatten

ていうか極限はこうだろ

「eval("code...") をJavaで書いて下さい」

あ、もちろんローカル変数にアクセスできないとダメですよ？

>>204
default_factoryはdefaultdict()を呼び出す側が用意するもの（>>199 では nesteddict を渡している）だから
インタフェースや宣言はしても、実装はしちゃダメよ

>>212
みんなわかっているよ
ハンデは与えてやれよ･･･････
頑張ればまだ静的言語でかけるかもしれないコードをおれはのせたよ
静的言語でやったら冗長するんだろうけどねｗｗｗｗｗｗｗｗｗ

>>215
ローカル変数へのアクセスがなくてもいいんならDynamicJavaとか(保守されてないけど)
既存のコードもあるんだけどね。

ローカル変数にアクセス出来ないのは、いずれ改善されるとは思ってる
eval以外のクロージャにしてもlambdaにしても、ローカル変数にアクセス出来ないなんて
利用価値がないし

1.7ですらクロージャまわりは残念な状況だし、どうなるかな

C#でコンパイラ使ってダイナミックオブジェクト生成

あ、もちろんローカル変数にアクセスできないとダメですよ？

>>206
そういうdefaultdictが用意されているという前提で、
それを利用するコードを書けばいいのか？

Javaならクロージャの代わりに無名クラスに
するだけの話だと思うが・・・

>>211
こんなオナニーコードじゃなくて金になりそうな例でお願いします

つまり、かけないと

一行ってだけで、効率悪い。
一行が必須なら、それに当たるメソッドつくれば、たいていの言語で、同じコードが動く。
もっと、らしいのを出してこい。

いいから黙って211やれや

>>211を静的（）言語のF#でやってみた
http://ideone.com/vXzC8

eval野放図に使って安全はないだろ。カプセル化したら意味ないし。

>>221

>>199 の nesteddict は常に同じ型のオブジェクトを返してるから
面白くない
てわけで、こっちはどう？
defaultdictに相当する関数は型宣言だけで中身は書かなくて良いよ

def nesteddict(n):
    def f(m=n):
        return nesteddict(m-1)
    return defaultdict(f) if n > 0 else defaultdict(list)

d = nesteddict(5)
d[0][1][2][3][4][5].append('a')

スレタイも読めない動的言語(笑)

安全なソフトを作ることに自信がないからって、ちっちゃなトイプログラムが
簡潔に書けることをアピールしだすwww

うゆさんの投下するプログラムって、簡潔なのにすごく「安全なソフトウェア」ですね＾＾＾＾＾

？

>>210を性的なF#で書いてみた
http://ideone.com/FBs8v
同じサイトで元のRubyコード実行してみたけど、ソースに日本語が含まれてるせいか
うまく動かなかったんで、実行結果の比較検証はしてない

>>229
>>58のいう「スニペットの流用」がどれだけやり易いかを
コードを例にして議論してる

もし、>>58のいうようにスニペットの流用が静的言語の方が優れてるなら、
既存のコードから少ない修正で別の用途にも使えるはず

いつからトイプログラムスレになったの？

>>226>>231
エロい人、乙であります

玩具のような簡単なテストコードは、ユーザーが自分の安全を自分で確認しやすい
難解な手法は「俺が検証しなくても誰かがするだろう」というパターンに陥りやすい

なんかRubyのRangeやイテレータの類が便利に使える事例と言うだけで
静的動的は関係ない例ばかりだなぁ。

静的型と関係なく使える道具が増えたら、
動的言語で安全なソフトが作れる可能性が大きくなるな。

動的言語は
危険、遅い、臭いの三重苦だ

そういう水掛け論よりはコードで示したほうが建設的だろうに
自慢のIDEでちゃちゃっと書いてくださいよ
え？もしかしてトイプログラムも書けないの？

あんなネタどうでもいいから、 eval(文字列) を書いて下さいよ。
もちろんevalの手前にあるローカル変数にもアクセス出来る奴。

でなきゃ「動的言語と利便性はたいして変わらない」なんて言えないでしょ？

その前にevalがあると利便性を感じるような現実的な例を挙げてくれ。

>>241
データ中にコードを埋め込めるので、データ側で何でも書けるようになる。

具体例を挙げてくれ。

evalで安全なソフト

#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=(
$m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72,@z=(64,72,$a^=12*($_%16
-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h
=5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$
d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d>>12^$d>>4^
$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9,$_=$t[$_]^
(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval

>>244
そりゃサンドボックスの話になるな。べつに不可能事じゃない。

eval自体がどうっていうより、パーサとインタプリタを内蔵することで機能拡張を可能にするアプリならいくらでもある。
emacs ,、GIMP, ブラウザ, 等がそうだな。
アプリの上で動くスクリプトを書くんじゃなくて、そういうアプリを作るにはパーサとインタプリタを含むエンジンを内蔵するしかない。

もう一つのパターンは、単に「簡単なリフレクション」として用いられる。
リフレクションが必要だと思われるあらゆる例で、リフレクションよりも簡潔に書くことができる。

evalが無い、はいそうですね。でおしまい。

>>86で挙げられたPythonの型チェックにしても実行前に検証は可能かと
問われればそれは無理。これもはいそうですね、でおしまい。

つうかパラダイムが違うんだから一方で存在する機能が他方で存在しない
ことなんて普通。

evalがどうしても必要な問題ならevalが存在する言語でプログラム書けば
良い。自分だけの小道具として使うならともかく、他人様の入力を受け
付けるシステムで気軽に使える場面がそう豊富だとは思わないが。

＞他人様の入力を受け付けるシステムで気軽に使える場面がそう豊富だとは思わないが。

インタプリタを内蔵してるアプリなんて別に珍しくないんだが。
それらは安全性のために色々仕掛けを施してはいるが、
結局やってることはevalと変わらない。

で、たとえばサーバ用途でならevalで十分なシチュエーションは普通に存在する。
動的言語で使われるテンプレートシステムのいくつかは実際にevalに依存してるしな。
利便性があるというのがtrueなのは間違いない。

静的言語で同じことをやろうとすると大がかりなインタプリタが必要になる上に、
コールスタック上のローカル変数にアクセスする手段が提供されないので
実装が余計に面倒になる。
別に不可能事はなにもないのだが、煩雑なばかりで何も嬉しくない。

>>249
>利便性があるというのがtrueなのは間違いない

特定の用途に関して利便性があるのは否定しないよ。

ただ「気軽に使える場面がそう豊富だとは思わない」と書いたように、通常
のプログラミングの中でどれだけ使える場面があるのかということ。
毎日テンプレートエンジン書いたりインタプリタの組み込みをしている人間
がどれだけいる? それは結構、特殊だよ。

そもそもevalを気軽に使える場面が豊富なプログラミング言語なんて嫌だw
そういう場面ではevalではなく通常の構文の範疇で同じ事を簡単にかける
ように言語は設計されているべき。

>>249
ちなみに静的言語で同じ事をするのにスクリプト機能であればインタプリタ
の実装を拾ってきて組み込むし、テンプレートエンジンであればパーサーを
書くでしょう。実際どちらも便利なツールやライブラリの類が存在するので
そう難しい話ではない。

evalで実行環境のインタプリタを流用するのは簡単だけれども、入力を検証
しないと危ないし、テンプレートエンジンにしても受領できる構文がホスト
言語の構文にどこかしら縛られる。

>>250
そもそもよくある例だから挙げられてるんじゃないよなコレ

動的言語らしい機能の端的な面として出てきてるだけで。

動的型付けだからeval乱舞って、そんなわきゃない
極端すぎる

>>252
うん。だから>>240についても答えは、

「eval無いよ。でも無くても動的言語と利便性はたいして変わらない。
　だってeval使わなきゃならない場面なんて良くある例じゃないし」

になるんだよな。

じゃあ利便性が劣ってることは認めるんだな。

evalだけならともかく、実際には動的言語らしい機能って他にも一杯あるしな。

多分このスレで一番スレタイに近いこと言ってるのは>>18

テストを普通に書けば動的言語でも安全だし、
テスト不足なら静的言語でも危険だろう。

それは脳内理論にすぎない
現実の大規模システムで使われているのは静的言語

単に膨大なレガシーコードがあるというだけだから

twitterみたく動的言語で作っても規模が大きくなったら
静的言語で書き直さなきゃらならい羽目になるんだったら
最初から静的言語で書いた方がいいよな

早すぎる最適化という言葉をまだ知らない奴がいるのか

動的言語のほんのちょっとテストが書きやすいなんてのは
型チェックがなくて余分にテストを書かないといけない分であっという間にマイナスだろ

twitterみたいな動かしてみるまで人気出るか分からんサービスでもか？

>>260
おまえが知っているのは言葉だけで中身知らないだろw

>>261
それって動的言語はテストを書くけど
静的言語は全然テスト書かない場合の比較ですよね？

>>264
そんなわけない
動的言語には大規模プロジェクトそのものがないから比較不可能だけど

>>265
じゃあテスト書いてみてよ

>>257
事例だけで確定するんなら、このスレいらないけどな。

まあ対抗事例も山ほどあるが。
http://storecrowd.com/blog/top-50-ruby-on-rails-websites/
https://www.socialtext.net/perl5/websites_using_perl
http://www.masonhq.com/?MasonPoweredSites
http://itpro.nikkeibp.co.jp/article/NEWS/20071022/285089/
http://journal.mycom.co.jp/news/2007/03/15/003.html

動的厨に言う大規模って
Webサイトのアクセス数って意味？

>>261
実際問題、動的言語だと型チェックよりも欲しい型への変換のが多くね？
結果的に「型変換出来ない=例外吐くになる」ってのが多いわ
例えば「引数として型Aを要求する関数」よりも「引数を『型Aを表す何か』として解釈し、そのように振る舞う関数」を書く
結果的に、型Aへの変換が出来ない引数は淘汰される感じ

べつに https://www.socialtext.net/perl5/companies_using_perl でもいいよ。

動的言語って静的言語のライブラリをラップしたライブラリ使わないと
使い物にならないよね

>>271
その言語を使ってどんだけのコードを書くかの問題じゃないか？
そもそもライブラリの安全性とそれを呼び出すコードの安全性ってそれぞれ違うし、
スレタイに関係ない話だと思う

動的厨は自分ではさんざんスレタイと関係ないこと話すのに
ちょっとでも不利なことになるとすぐこれだw

>>270 から何をどう発展させろってんだよｗｗｗ

強いて言えば、スクリプトってのはむしろ静的言語にエンジン組み込んで動かすものだよね
JavaScriptもサーバで使うようになってきたし。JITも入ってるから静的言語だな

だって全然デメリットじゃないじゃんそれ

このスレは、静的/動的両方の言語を安全に使えるPGと、
静的言語（典型的にはJava）しか使えないPGが
意見を戦わせてるんだよ？

>>255
うん。evalについてはね。直接対応する機能が無いのだから当然。
ただ劣るにしても程度問題で、普段滅多に使う場面がないなら劣るに
しても微々たるもの。

>evalだけならともかく、実際には動的言語らしい機能って他にも一杯あるしな。

それも個別に検証しないとね、

動的言語の大規模ソフト例を聞くと
アクセス数の多いサイトを出してくる
動的言語しかつかえないPGと、
静的言語で安全な大規模ソフト作っているPGが
意見を戦わせるスレだろ

amazonとか別にサイト部分だけperlな訳じゃないよな。

>>277
安全なソフトを日々作ってるプログラマなら
テストは書き慣れてるよね？書いてみてよ

どっちにしろ、事例だけで確定するんならこのスレいらん

「Amazon uses Perl in a variety of ways through their enterprise. They have a custom application framework called Gurupa which is a bridge between a service layer and Mason.」
でスレタイに反例が存在してることになるので終了ということになる。

Pythonを使っている製品あるいはソフトウェアの一覧
http://ja.wikipedia.org/wiki/Python%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B%E8%A3%BD%E5%93%81%E3%81%82%E3%82%8B%E3%81%84%E3%81%AF%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%81%AE%E4%B8%80%E8%A6%A7

Pythonによって実装されているフリー/オープンソースソフトウェアなんて大げさに書かれているけど
ちょこっと拡張用に組み込まれた程度のものが混じっているのな

http://en.wikipedia.org/wiki/List_of_Python_software
英語版の方が多いな

動的厨の言う大規模ソフトって
アクセス数が多いとか商品数が多いWebサイトなのな

今時、大規模なシステムを1個の複雑なソフトで作ることの方が稀だな

Google uses Python for many tasks including the backends of web apps such as Google Groups, Gmail, and Google Maps, as well as for some of its search-engine internals
googleが安全かどうかは意見が分かれるところだが。

NASA is using Python to implement a CAD/CAE/PDM repository and model management, integration, and transformation system which will be the core infrastructure for its next-generation collaborative engineering environment
NASAが安全かど（ｒｙ

the organizations that use Python.
http://wiki.python.org/moin/OrganizationsUsingPython
Financial の分野でも普通に使われてる

静的厨が発狂してることだけはわかった

Pythonがアプリに組み込まれるのは
動的言語の方が実装しやすいとか
馬鹿でも使えるとかそんな理由だろ

>>284
静的厨のいう大規模ソフトってのは
土方を大量に集めて開発したって意味だよね

大規模っていうからには、年間開発費が10億円以上だろ

>>289
>>288

>>287
馬鹿でも使えるって意味ではJava最強
これは褒めてる

馬鹿に書かせても馬鹿なコードを書かれない、ってむしろ静的厨の主張する静的言語の特長だったよねw

今時、大規模なシステムを1個の複雑なソフトで作ることの方が稀だな

アプリの拡張には馬鹿でも使えるってのは重要
Heskellスクリプトなんて入れたらユーザーは怒るだろ

静的厨のいう「大規模なソフト」自体が問題分割に失敗した悪い例だな。

まともな設計者なら問題を適切に分解して、大規模じゃないソフトの集合にしてしまうだろうし、
そうなると言語の選択ポイントは「(馬鹿に書かせても)安全かどうか」ではなくなってしまう。
どうせテストはするんだしな。

スレタイの反例も十分出したし、このスレもういらね

動的厨の言う大規模は
アクセス数やページ数が多いWebサイトだからな
しかもバックエンドに静的言語で作られたソフトを使った

そのバックエンドのさらに下はSQLだからなｗｗｗ

データベースが動的言語で出来てると思ってる？

で、「(馬鹿に書かせても)安全だから」って理由で静的言語で書かれた大規模なソフトって何だよ？

>>295
まあWindows界を筆頭に、1つのソフトに何でも詰め込む設計が跋扈してるからなあ

>>298
中身が何であろうと、SQLを扱う上では動的コードの視点に立たないと穴ぼこだらけになっぞ？

アセンブラは動的言語

brainf*ckは静的言語

アセンブラは実行時の型チェックもないからな

SQLが動的言語って、どういう意味で動的って言っているの?

動的SQLの意味に決まってるだろう
JDBCで使ったことあるんじゃない？

動的SQL(Dynamic SQL)と動的言語は違うだろう。
SQLに対する理解が足りないのか動的言語に関する理解が足りない
のかはっきりしてくれ。

ぶっちゃげ呼び出し側から見れば動的SQLは普通のクエリ実行よりも
よっぽど静的だ。

eval脳ではSQLインジェクション

動的言語は実行時にしか型エラーがみつからないから
ダメだっていってるひとがいた

http://tech.a-listers.jp/2011/06/16/orm_is_an_antipattern/

テストを書けば動的も静的も関係ないって話はC0でも良いからカバレッジ何パーセントくらいで言えるんだろう。
また、ホビー、金融系、Webの緩いのや硬いのでも現実的にテストにさける時間は変わってくるよね。
テストで担保するって話が土台になるならここの前提はとても重要だと思う。

アセンブラは動的言語

性的言語は好きですか？

>>311
実験に時間をさく事は現実的ではなくて
しかも「時間のかからない安全策」が現実的だと言いたいのか？
そんな都合の良い現実がどこにあるんだ

>>307
要するに静的だろうとテストはしっかりやらなきゃダメってことだろ

テストって何って感じの人には

動的か静的かはさておいて、データ構造やアルゴリズムの基礎も知らん人に
プログラミングできる環境を提供して欲しくないな。
素人の作ったソースのメンテやらされて大迷惑だよ。
本当に抽象的・数学的思考のできない奴に、コード書かせるなよ。

うちでは使えない奴は本番では使われないダミーコード書かせてる

難しいといわれてたオブジェクト指向をここまで簡単と言わせるJavaってすごいな

それって、オブジェクト思考が難かしかったんじゃなくて、慣れてなかっただけ
なんじゃないの？

テストは必要だけど、たくさん書くと
コード修正時のメンテナンスが大変になる。

だからテストもなるべく少なくするほうがいい。
もちろん少なくすると言っても必要なテストを省くという意味じゃないよ。

で、静的言語だとテストの一部を実際に使用するコード側に
移動して減らすことができる（実行前の静的テストに変更できる）

しかしコードを見るとオブジェクト指向でもなんでもないっていう

オブジェクト指向なんて
コード触って１〜２年目には誰だって辿り着くもんだぞ
変な書籍が大量にでて、それを読んで凝り固まった考えを流布し始める奴が多いから言葉の定義すら曖昧になって
オブジェクト指向とは一生かかっても誰も習得できない技術となった

しかしコードを見るとオブジェクト指向でもなんでもないっていう

オブジェクト指向は韓国みたいなもの
新しい画期的な概念がでてくると、「これはオブジェクト指向のひとつだ！」
みたいに言い出す　こわい

オブシコはオワコン。

オブジェクト指向型と関数型と静と動が合体した言語は無いの？

C++0x辺りは、それっぽい事ができると思う。

C++は基礎知識として必修させるべきだと思う。
OOPLや動的言語がどう内部で処理されてるか理解しない奴は土方。

>>329
それはいいね。
動的言語ばかり使っているやつって
内部実装に無頓着になりがちだから。

数値？文字？ そんなのどっちも
変数に入れられるじゃん。みたいな。

Javaとかでも = null が何を意味してるかわかってない奴多いし

>>331

>>332

>>329
OO プログラミングだけならいわゆる LL とかで、自分で実装してみるのも良いと思う。

なにを？

>>335
文章が分かり辛くてごめん。
オブジェクトシステムを自分で実装してみる。

>>330
内部理解とかもうどうでもいい
ハードを意識してプログラム組む時代は終わった
数値、文字列を、同じ箱に入れられないのはハードウェアの事情なだけで

そのゴミ、ハードウェア上でどのように数値、文字列を表しているかなんて、
それさえもひとつの手法でしかない為、知らなくても別に良い
10年たてば事情が変わってる可能性さえある
最高で完璧で枯れた技術だったら誰もが覚える価値はあるけど、現状そうではないと思う

>>333

わからない奴ほどどうでもいいという

ある知識が必要かどうかという話に、その知識を知らない人は参加できるか否か。

自分には>>330 の言う内部実装の知識はないが。

>>329と>330の間には溝がある気がしなくもないが
C++のvtableぐらいはやっとくとすごい有益

動的言語の内部実装で言えばPerlのOOPシステムは
生で使うと内部実装が表に出まくりだな

クラスはパッケージであり、メソッドはパッケージに所属する関数であり
フィールドは単なる連想配列であり、結果として
オブジェクトとはパッケージ情報が付加されただけの連想配列である
…というのがまる見え

パッケージ…と書くとPerl用語になってしまうから
より一般化すれば名前空間ってところか

PerlerってPerl6やってないの

PythonのOOPもちょっと内蔵はみ出てて
内部実装見えちゃってるな

>>321
ふーん。不思議なことをいう人だね
ちょっと実例だしてみてよ

>>323
Smalltalkなら１、２年で会得出来るだろうけど
JavaやC#だと下手すると一生解らないだろ

なんで、オブジェクト指向の話をしてるところで言語名がでてくる
それが
＞ 変な書籍が大量にでて、それを読んで凝り固まった考えを流布し始める奴が多いから言葉の定義すら曖昧になって
といってるんだよ

二度と話かけんなよ

優秀なエンジニア5人は二流の1000人を完全に凌駕する
http://el.jibun.atmarkit.co.jp/rails/2011/06/51000-6676.html


大規模開発www

今の時代なら、まだそれはありえるよ

海外だと一流1000人とかだからな
日本だと初心者1000人だけど

難しい機能（OSとかフレームワーク自体の開発とか）だと
優秀なエンジニア5人は二流1000人を超えるかもしれないけど

でもソフトウェアの多くは、実装が難しくもない簡単な機能。
そんなものは一流のエンジニアでも二流のエンジニアでも
実装時間は変わらん。


分かりやすく例えれば、フランス料理フルコースを作るのに
一般の人がいくら頑張ってもまともに作れないけど、
通常の食事程度、弁当とかなら数が集まったほうが多く作れる。
一流シェフに弁当作らせても1000倍速く作れたりしない。

その5人がメタプログラミングをどの程度まで極めているかによるんだよ
メタには限界なし。

あとは、その5人が、過去に何度か似たようなものを作ったことがあって
ソースコードを流用できる場合とか
1000人のほうは1から作っているのにたいして、5人のほうは過去のソースコードの組み合わせをしていくだけになる

ゼロからソースコードを書いた場合の開発効率とか、そういう次元の話はしてないと思うよそれ言ったヤツ

>>345
少し出てるね、メソッドはフィールドに関数オブジェクト突っ込んだものだし
メソッドが関数だから仮引数としてself渡されたり
ただ、オブジェクトありきの実装だからまだマシかも

>>323
オブジェクト指向の肝はプログラミングじゃなくてモデリングだろwwww

>>355
は？
オブジェクト指向の肝って何だよ？肝いなお前
Object Orientedってのはただの形容詞なんだよ
その後にAnalysisがつこうがDesignがつこうがProgrammingがつこうが何でもありだ
お前は肝いからUMLでお絵描きだけしてろ屑

NGにさわんな

uy本物　あえて名無しで書き込み

>>356
はああ？


>>355
は？
「コード」触ってりゃっていったわけで
お前はもしかして　本　読まないと無理なタイプ？
死ねよゴミ

最近は関数型言語のように
副作用、つまり状態を変化させない
関数が流行っている。

オブジェクト指向でも
状態を変更させないように
変化させていくべきだ

OOはマジ宗教

聖書の書き換えをしながら勢力を大きくしていってる
たちのわるい宗派

>>359
imutableって計算機学の歴史の中でも古くからある概念なんだけどね。
なんで最近まで軽視されてたんだろ。

>>354
まぁ、カプセル化はオブジェクト指向言語の必須条件じゃないからね。

C++の関数に付けるconstっていいよね。
オブジェクトが変更されないことが明示されてる。

で、これってコンパイル時に分かるわけだが。

RubyにもFreezがあるし、殆どの言語であるよ多分　ボケナス
それにRubyには大文字で変数宣言すると定数になるし
Ruby最強なんだよ　ボケナス

なんでこの馬鹿は自信満々にアホなこと言うんだろう？
アホだからか

実行してから分かるのなら、
実行前に教えてくれと思う。

一本道を歩いていたら
行き止まりに、ここで行き止まりですって
書いてあるようなもん。
道の入口に、行き止まりと書いておけ。

>>366
一本道なら、教えてもらわなくても分かる

完全に初期化のみ、変更不可って理想的ではあるけど、コピーコストがバカにならんね。
あれさえどうにか出来れば、もっと普及できたんだろうけど。

>>368
それ以前に参照でオブジェクトを追跡できなくなるのがまずい。
オブジェクト "ヰ" をポインタ　"ゑ" で追跡してたとき、
オブジェクト "ヰ" が意味する値が変化したことを "ゑ" に通知する必要がある。
更に、　"ゑ"　もその結果に応じて変化することはできないんで、更に上位の参照体に
"ゑ" が意味する値が変化したことを通知する必要が出てくる。

>>363
int x = 0;
const int &y = x;
std::cout << y << std::endl;  # 0
x = 1;
std::cout << y << std::endl;  # 1

まぁ、正確には参照先を変更できないって事だわな。
それをいうなら、javaでもC#でもconstは用意できる。

interface ConstXxxxxx
{
getYyyyyy();
}

ConstXxxxxxをとる限り実質変更不可能。
そもそもJavaにconstが無いのは、interfaceで実現できるから
なんだがなぁ。Javaの設計者が如何に思考巡らせていたとしても
結局Javaグラマーがアレだからconstが無い不便な言語、
もしくはconstダサい的な流れになっていく。

>>369
何を言ってるのかよく分からない
"ヰ"はオブジェクトじゃなくて変数？

>>372
オブジェクトそのもの。

>>372

type a = 5;
type *p = &a;

a+=5;

mutableだと*pを見ていれば、
5が10になった事がわかる。

const type a = 5;
const type *p = &a;

a2=a+5;
imutableだと*pからじゃ5が10に
なった事が判からない。

ワロスw

http://codepad.org/e4K51sph

>>368
オブジェクトがすべてリスト構造に変換出来るんであれば
ある程度緩和できる話しだけどね。

>>373
オブジェクトそのものが変化するならそのオブジェクトはmutableだし参照元は何もしなくても良いだろ
>>374の例を見ればやっぱり変数の束縛先の変化の事を指してるのかな
immutableオブジェクトの例としてconstを使うのはどうかと思うが

>>376
リストにappendしたり、中の要素を変更したりするだけで
リストの全コピーが発生するのが困るんだが

リスト構造だと何が緩和されるの？

cons的な操作が出来ればってことじゃね？

C++のconstは次のように解釈してた
const type x = ... # immutable object
const type &x = .. # read only reference

>>378
変更後のオブジェクトは変更したメンバーだけ持って、
変更前のメンバーは前のオブジェクト参照すればいいでしょ。

>>381
だからリストのコピーが発生してるじゃん

静的言語厨はSQLもコンパイル時にチェックしてるんだよな？
コンパイル時に型チェックできないならSQL使わないんだよな？

>>383
ストアド使うか、カプセル化してチェックするっていうのは基本だが。

SQLでコンパイルというのが全く持って曖昧だと気がつかないのか。
SQL文のプリコンパイルの事を言っているのか、静的言語からSQLを
呼び出すときのことを入っているのかはっきりしてくれ。

そもそもコンパイル時に型チェック出来ないなら使わないなんて誰が
言ったんだ? 勝手に話を面白くするな。
JavaもC++もRTTIはそれなりに使うぞ?

つまり安全ではない、と

たとえば同じバグがあったとして
１．テストを書かないと、バグがあることがわからない。
２．テストを書かなくても、バグがあることが分かる。
この二つの状態。

２の方が優れているのは言うまでもない。

>>386
SQLに限らずホスト言語と組み込み言語の間の型マッピングは手動の
事が多いから、そりゃコンパイラで捕らえられないマッピング間違い
もあるだろうさ。

で、それがどうかしたの?
何のためのテストだと思っている?

８０できないから１０でも同じ！

SQLか。

テーブルのスキーマを変えたとき、たとえば
フィールドの型を変えたり項目を減らしたりしたとき、
そのフィールドを参照しているコードを
検出できたらいいとは思うよね。

>>387
バグの種類によるだろ

というかSQLは動的言語とのたまった御仁にどう動的言語なのか説明を
求めるも、「動的SQL」云々と口走った以外は音沙汰無しなのだが。
どこに行った?

>>387
でも結局テスト書くよね？
静的だろうが動的だろうが。

http://msdn.microsoft.com/ja-jp/library/1t3y8s4s(v=vs.80).aspx

null 許容型 (C# プログラミング ガイド)

null 許容型は、System.Nullable 構造体のインスタンスです。
null 許容型は、基礎となる値型の通常範囲の値だけでなく、null 値も表すことができます。

たとえば、Nullable<Int32> ("Int32 の Null 許容" と読みます) には、-2147483648 から
2147483647 の任意の値、または null 値を割り当てることができます。

Nullable<bool> には、true、false、または null の値を割り当てることができます。
数値型と Boolean 型に null を割り当てる機能が便利なのは、値を割り当てることができない
要素を含むデータベースや他のデータ型を処理するときです。

たとえば、データベースの Boolean フィールドには、値 true または false を格納するか、未定義にすることが可能です。

>>393
> でも結局テスト書くよね？
> 静的だろうが動的だろうが。

まさか屁理屈いおうとしてないか？

テストにはいろんな種類があって、
そのうちの型チェックに関する部分のテストは
静的言語では書きません。

お前は、それ以外のテストを書くから
テストは必要だという、屁理屈に
つなげようとしていると見た。

>>390
一つの言語内の問題ではなく異なる言語間のブリッジの問題だからね。
ぶっちゃげ静的動的はあまり関係ない。

データマッピングを間違えたところで静的型付けだとデータ変換時に
例外吐くのが動的型の場合はその後のロジックでエラーを引き起こす、
その程度の違いでしょ。

> 動的型の場合はその後のロジックでエラーを引き起こす、
> その程度の違いでしょ。

それが怖いんだよ。
その後のロジックでエラーを引き起こすということは、
エラーを引き起こすロジックを実行しない限り
エラーがあることが分からないってこと。

こんな状態は想定外でしたという
システムトラブルの記者会見はこうやって起こる。

>>382
function Example()
{
this.instance = {};
}

Example.prototype.Reference(field)
{
if( null != this[field] ) return this[field][field];
for(var original = this.original; null != original; original = original.original )
{
if( null != original[field] )
{
this.instance[field] = original[field][field];
break;
}
}
this[field] = this.instance;
return this[field][field];
}
こういう感じ。objectを内部的に変更するから、
厳密にimutableじゃないけど、objectの外から見る限りは完全にimutable。
ちなみにjavascriptに限らず大抵の言語は同じようにできる。

そんなめんどくさいことまでして
やりたくない。

引数、もしくは関数にconstって付けたら
この関数を実行しても
この引数、オブジェクトは状態を変えません。

変えようとするコードを書いたら
コンパイルエラーになります。

って方が何倍もよい。

>>399
関数型言語ですね

>>396
いや動的型付けだろうと型変換に失敗したら例外吐くぞ
まさか動的型だと変換すらしないと思ってる？

>>399
如何にコピーコストを抑えるかっていう、それとは別問題の事を書いたんだけど。

>>385
C++でRTTI使いまくるのは設計がダサい証拠、って俺の師匠が言ってた

>>401
動的言語でも型変換はするでしょ。ただJDBCやDBIなどの低水準のDB接続APIに
関して、動的言語の場合はAPIの実装が結果テーブルのメタデータ読んで自動的に
適切な型変換をするので、APIを叩く利用者側ではカラム値を引っ張ってくるのに
特に型指定する必要が無い場合が多いよね。型指定しなくても常に成功する。

静的言語の場合は多くはgetStringみたいに型指定されたメソッドを叩く必要が
あるし、正しいメソッドを利用しないとカラム値を引っ張った時点で例外を吐く。

動的言語ではノーエラーでカラム値を引っ張れるとしてもそれが想定した型の値
でないと後のロジックで破綻するから、結局静的型と同様に型の検証とかDAOの
テストを書いたりする必要がある。

要するにSQLとかDBアクセスが安全か否かに関して静的動的云々はあまり関係
が無くて、結局テストを書かないといけないという事。

スクラッチからかくならC++にRTTIとfriendはいらない

静的言語でSQL書くなら、埋め込みSQL使えばいいだろうに。
ちゃんと型チェックしてくれるぞ。

SQLJとか死に体だからなぁ・・・

>>395
いや、それだけの話なら、正しいスレタイは
「動的言語は型チェックのテストコードを書くから面倒」
じゃないかなと。

>>404
> 結局テストを書かないといけないという事。

うん、結局という話にするから
おかしくなっちゃうんだよ。

飛行機で行っても、船で行っても
結局、アメリカにつくだろう？

結局、アメリカにつくから同じだと思うか？

問題は結局という最終的な結果じゃなくて
そこに辿りつくまでの話よ。
同じ結果になるのなら、楽な方がいいだろう？
問題は早く見つかるほうが楽だよ。

>>404
それってAPIの問題な希ガス

>>409
あ〜基本的に自分は>>383とか>>386をピンポイントでdisりたいので
あって静的言語を叩いたり動的言語を持ち上げたりその逆をしたりする
意図はないから。

ただSQLの呼び出しに関連した問題は本質的には異なる言語とのブリッジ
にまつわる問題であって静的動的云々の言語の違いはそれと比べれば副次
的なものだと考えている。

>>410
うん。APIの問題なんだよ。言語はあまり関係ない。

内部で型変換するAPIが多い動的言語もユーザが型指定する必要のあるAPI
が多い静的言語でも発生箇所が異なるだけで問題は結局発生するのだから
(繰り返すけど言語ブリッジの問題だから)、静的動的云々は安全性の問題
にはあまり関係がないと思う。

静的型にしても例えば文字列型のカラム値をgetDoubleで取りに行って
例外を吐くかは実行時にしか解らないわけで、結局テストを書くしかない。

>>411
■スキーマの検証

　モデル・クラスがLINQ to SQLデザイナを使用して定義されたとき、
データモデル・クラスにあるプロパティのデータ型は、
そのデータベース・テーブルのデータ型に対応します。

例えば、もしDinnersテーブルの“EventDate”列が“datetime”の場合、
LINQ to SQLが作成したそのデータモデル・クラスは“DateTime”
（これはビルドインの.NETデータ型です）に型付けされます。
つまり、それに対してコードからint型やbool型を割り当てようとした場合には
コンパイル・エラーになり、実行時に無効なstring型をそれに明示的に変換しようとした場合には、自動的にエラーが発生します。
^^^^^^^^^^^^^^^^^^^^^^^^

>>412
それは静的言語が偉いと言うよりもまずO/Rマッパが偉いんだと思うw
テーブルスキーマとデータクラス等々の定義を自動で同期するんだよね。

ただデータクラスに正しくマッピングされれば後は静的言語の型検証を
有効に活用できるというわけで、確かに静的型の方が有利だな。

>>365
へえ
Rubyにはconstにかわるものがないと思ってるのか
レベルひく･･･

>>414
rubyはもういいよw
選択肢外だから話題に出さないで
邪魔くさい

>>415
http://glossary.tank.jp/t0823.html
この人がさ
2000年の時点でこれ言ってんだよね

残念だけど2011年になって、外国からの書籍も日本も来るようになっても、

お前みたいなおばかはいるみたいで。。。

んなこと言われてもどうでもいいもんはどうでもいい(笑)

>>415
で、選択肢は何をもってんだ？

Rubyと同等に見れる可能性のある言語って、Python,Lispくらいなんだけど
まさかPerlとかゴミHaskellをだしてくるわけじゃないだろうな
PythonとLispはそのどちらも、日本語資料がとぼしく、一部の奴が好んで使ってるだけで
特に大学でPythonなんて教えてるとこよりはRuby教えてるところのほうが多いと思うが

動的言語でRubyという選択肢を除外なんて、何をいっているのやら。知ったか君は邪魔だから　消えてくれ

>>417
そうだよね
お前には近いこなせないの知ってて言ってる（笑）

効率に気づけないんだから仕方ないよね

この糞コテ、だんだん精神的にマズくなってんだろなって思う

まあそうムキになるなよ(笑)
どうぞどうぞ、固執してなさい
でも邪魔くさいからrubyの話題を持ってくるのはやめてね
わかった？

るびー
Ruby
【プログラミング】
・まつもとゆきひろ氏が開発している、日本生まれのオブジェクト指向スクリプト言語。
・その強力な機能と最初から日本語の資料が整っている事からすれば、生まれ故郷の日本ではもっと普及しても
良さそうなものだが、拝外思想の持ち主で遠く太平洋をはさんだアメリカばかりに気を囚われて、
足元で起こっている変化に気付かない多くの連中には、当分気付かれ、受け入れられそうも無いもの。
・「当分」が解けるのは、アメリカで「Ruby」の本が出版され、それが日本で翻訳される頃あたり;-p
2001/01/01更新

>>420
かまってちゃんが攻撃的なのはよくあること
普通のこと
普通のかまってちゃんが普通の行動をとってるだけ

>>420
感がいいの？


>>421
おｋｗｗｗｗｗｗｗ　っじゃｗｗお前は一生Ｒｕｂｙ使うなｗｗｗｗｗｗｗ　絶対に使うなよ？
使ったらお前の「負け」でｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ


使うなよ？

人が親切心でおしえてんのにねｗ

何故ここでコレを出したのか未だに理解できない

>>422
そんなもん持ち出さなくても、rubyは十分に普及してるじゃん
ゴミの割にはよくやってるよ

＞PythonとLispはそのどちらも、日本語資料がとぼしく

>>424
なんだ、ただのガキか

日本語しか読めない奴には、日本語の資料が充実してるかどうかが死活問題だからな
英語読めないなんて軽蔑するけど、まあ馬鹿にもプログラミングする権利はあるしな

>>428
ゴミ乙


>>429
まだそのフィールドにいるんだ
じゃあお前なんでこの板にいるわけ？　英語が読めるんだったら海外bbsいってろハゲ

在日ではなく日本人だったら日本語が読みやすいのは当たり前なんすけどーｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
読めるか読めないかじゃなくて
学習速度のこといってんだわｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
学校の教科書を全部英語でかかれてんのとお、ｗｗｗ　日本語でかかれ店のどっちがいいですかあああ？？ｗ？Ww?Www

英語だろ？

静的な型に対する最も一般的な反対論は、プログラムを無駄に長くして、プログラマーが自分の思考を表現するうえで妨げになること、
そしてソフトウェアシステムのある種のダイナミックな変更のパターンが不可能になることである。
しかし、こういった議論は、冗長で柔軟性が低いと感じられる特定の型システムに対する反対にしかなっておらず、
静的な型付けという一般的な思想に反対するものにはなっていない。

たとえば、Smalltalkの発明者であるAlan Kayは、こう言ったことがある。
「私は型に反対しているわけではない。『完全な苦痛』にはならないような型システムを見たことが無いので、
動的な型付けを支持しているのである」

>>431
だから
だから
【現象】
・おそらく、海馬がイカれていて記憶を留める事ができない上に、前頭葉と側頭葉が魚並みに退化してしまった人種なんだろうけれど、それを差し引いたとしても込み上げて来る感情を我慢できずに吐き出してしまう言葉。
・今日もどこかで聞こえる怒りの声。 「だぁ〜かぁ〜らぁ〜(怒)」
http://glossary.tank.jp/t0629.html

だからさぁ　、、　そうかそれなら国へ帰れ

>>430
日本語のほうが読みやすい？
他に選択肢ないくせに、なにが日本語の「ほうが」だよww

この出会い厨、今日はやたらと元気だな

フランス語はフランス人しか喋らないと思ってるのか

静的型システムは単純なエラーを検出できるだけだが、
「単体テストならもっと広い範囲のエラーを検出できるのだから、
わざわざ静的型システムを使う必要は無い」とまでいう人々もいる。

私たちは、このような議論には見落としがあると思う。
確かに、静的型システムは単体テストの代わりになるわけではないが、
プログラムの性質を確認するために普通なら必要だった単体テストの数を減らしてくれる。

さらに、単体テストは静的型付けの代わりにはならない。
エドガー・ダイクストラが言ったように、テストが証明できるのはエラーの存在であって、
エラーの不在ではない。静的型付けが与えてくれる保証は単純なものかもしれないが、
どれだけテストをしたとしても得られない本物の保証なのである。

>>430
日本語が不自由なやつだな

>>432
> 静的な型に対する最も一般的な反対論は、プログラムを無駄に長くして、プログラマーが自分の思考を表現するうえで妨げになること、
それはお前の思い込みでしか無いよ。

ぶっちゃけ、型を定義する程度の簡単なことを
めんどくさいと言ってやらないやつは
テストもめんどくさいと言ってやらないんだろう。

急がば回れ。

型書いとくと
あとで楽になる。

日本にはいいことわざがあるよ。

>>434
はっああァァアアアアｱｱｧｧ??？？？？？？？？？？？？？？？

railsとか、日本語だとおもってんの？ｗｗｗｗｗｗ
ocraとか英語ドキュメントしかないけど、俺はその英語ヘルプ読んで使えるようになったんですけどぉぉｗｗｗｗｗ
Rubyは日本語資料も多くｗｗｗ英語資料も多いんだよｗｗｗｗｗｗｗｗｗ両方ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>440
本心が透けて見えてるよ

てか基地外は放置しろよ。
まぁ、似たような基地外が立てたこのスレで言うのも何だけど。

誰からも認証されないかわいそうなおっさん

>>443
たったの3行に
めんどくさい　をって単語が2個もヒットしたね。

p"ぶっちゃけ、型を定義する程度の簡単なことを
めんどくさいと言ってやらないやつは
テストもめんどくさいと言ってやらないんだろう。
".scan(/めんどくさい/).size

# => 2

反論できない時の模範的な解答例。>>446

型宣言の手間に費やす労力は代わりにIDEの補完機能の精度向上によって十分に
報われている気がする。動的言語向けのIDEも頑張ってはいるけれども、やはり
補完の精度では型情報を使って候補を絞り込める静的言語には敵わない。
他にも最近のIDEは型の妥当性をコーディング時にリアルタイムで検証するから、
間違った型への代入等々はそれこそビルド"前"にエラーとして警告される。
これもポカよけとして非常に有用。

ActionScriptなんかは動的型のAS2からAS3に移行するに当たって静的型を、
それも動的型も併用可能という形で導入したのだけれども結局はあっという間に
型付きでのコーディングが多数派となった。
そんなに動的型が本質的に優れているのであれば開発者の多数は動的型での開発
に留まったと思うのだけれども当時のFlexBuilderとか使っていれば型付きでの
コーディングの効率の良さは明らかだったからね。
静的型を導入してもそのデメリットは十分に補うことが出来るという良い事例。

型があったほうが楽にならない？
コード補完してくれるし
正しい位置にジャンプしてくれるし。

コード書いているときに思考を邪魔されたくないから
適当な変数名付けることってない？

俺その場ですぐに適切な変数名ってつけられないんだよね。
だって俺の思考はすでにもっと先のコードを書いているから。

>>448
グラフィック中心のFLASH使いは動的な書き方が多いけど
FlashDevelop使うような連中はJava風な書き方になってるね

>>447
はぁ？




型については、
まともなリファクタリングしたことあればわかると思うけど
一度つくった設計そのものをかえるようになりファクタリングするときって
静的言語じゃ絶望的だぞ
引数、戻り値、をそれぞれかえるのと他に、　型情報までかきかえなきゃならなくなるんだから

小規模ならまだしも、
もし大規模なプログラムで根幹からちょっと仕様変更しなくちゃならなくなったときは
下手に設計していると頓挫して空中分解
そういうところから炎上やデスマになってると思うんだよね

どれが一番権威のある本？

リファクタリング―プログラムの体質改善テクニック
http://www.amazon.co.jp/dp/4894712288/
マーチン ファウラー

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法
http://www.amazon.co.jp/dp/4873114039/
オライリー

Java言語で学ぶリファクタリング入門
http://www.amazon.co.jp/dp/4797337990/
結城 浩

>>451
これははずかしい

だがどこが恥ずかしいかは言えない。本当に恥ずかしいやつめ。

え？

>>451
はぁ?

最近のIDEでまともなリファクタリングをしたことがあるなら判ると思うけど、
抽象クラスのメソッドシグネチャを書き換えると具象クラスのそれも自動的に
書き換えたりと、レキシカルに特定出来るところは自動的に書き換えるのは
普通だし、書き換えの副作用の範囲が即座に型エラー等として見て取れる
あたりはより「安全」だぞ。

動的型の場合「根幹からちょっと仕様変更」したときにその副作用の範囲を
どう特定するのか是非ノウハウを聞かせてもらいたいものだ。

根底からリファクタリングするって事自体があり得んよなぁ。
それぐらいだったら、元のコードの横に(レイヤー的に)増設したほうがましだ。

え？

増設に増設を重ね。そしてしまいに崩れる。
それをどうにかする方法はないか。

そこからリファクタリングという技術が
生まれたことを知らないのか？

>>457
お前はまだ、リファクタリングの入り口にすら
たどり着いていない。

現実見ろよ。
あと、多分勘違いされてると思う。俺の方は、標準ライブラリに依存した
箇所さえ動作を変えるような方法だ。
そもそもあなたのリファクタリングは、何のためのリファクタリング？

>標準ライブラリに依存した箇所さえ動作を変えるような方法だ。

具体例。

仕様を変えるのはリファクタリングと言わない。
正しくリファクタリングなのであれば、
普通テストを書いているので型エラー以外も含めて特定可能。

>>460
なんのためのリファクタリングかって？
それ、リファクタリングの本の最初の方に答えが書いてあるよ。

Java言語で学ぶリファクタリング入門より

リファクタリングの目的

「バグとり」や「機能追加」はリファクタリングではありません。
それではリファクタリングの目的はなんでしょうか？
　リファクタリングには次のような目的があります

◆バグを見つけやすくする
「バグとり」その者はリファクタリングではありません。しかし、リファクタリングを行うと
プログラムが整理され、潜んでいるバグを見つけやすくなります。
略

◆機能追加しやすくする
「機能追加」そのものはリファクタリングではありません。しかしリファクタリングを行うと
プログラムに新しい機能を追加しやすくなりますs。
略

◆レビューしやすくする

>>460
>そもそもあなたのリファクタリングは、何のためのリファクタリング？

「現在の実装の振る舞いを変えずに」コードの可読性保守性を上げたり
パフォーマンスを上げるためにコードを書き換えること。
リファクタリングとはそういうものだと思うが違うの?

つうか型エラーの話ばかりするけど、
それさえチェックされれば満足なのかよと言いたいが。

>>456
はぁ？Ww
その程度で出来るものをリファクタリングとはいいませんから＾＾＾＾＾＾＾＾＾

>>462
リファクタリングを行うために
「テストを書く」という準備をする必要がある。それも正しいけど、
「型をちゃんと書く」という準備をすることも正しいよ。

テストだけが、リファクタリングで動作に変化が起きていないことを
証明する方法じゃないということ。
コンパイラ・IDEの力を借りて自動的に行うこともできる。

テストはテストから漏れている部分、つまりバグがある箇所は
特定不可能だからね。

>>466
お前の俺俺定義はどうでもいいよ。

リファクタリングの本に、なにがリファクタリングかはちゃんと書いてあるから。

>>468
おまえ、すっげーゴミ本読んでるんだな

著者だれの本読んだ？ｗ

できればその著者のかいたソースコードも乗せてくれよ
リファクタリングほど個人差の出るものねーから

一番権威があるリファクタリングカタログｗ

http://www.refactoring.com/catalog/index.html

この中に含まれているものは
リファクタリングです。

　状況によって変わる。よくある方法は新しく作ったインターフェースに、
修正対象部分の動作を合わせていく。
そして、新しいクラス群は、修正対象をAdapterに隔離し、
修正対象から依存性を切り離す。
インターフェース的には古いクラスの中に介入できるので、
古いクラスの動作も改善できる。

要するに関数型な考え。で、あなたのリファクタリングは根本的に変えるんだよね何がしたいの？

class XxxxxAdapter implments RefactorInterface
{
private OldType oldType;
public XxxxxAdapter(略) {略}
public Type Yyyyy(NewType xxxx)
{
return oldType.Yyyyy( convert(xxxxx) );
}
}

>>465
何で動的厨は勝手に話を膨らませて面白おかしくするんだ。
誰が「型エラーさえチェックされれば満足」なんて言った?
誰もそんなことは言っとらん。

>>466
お前もだ。誰が「これでだけで出来る」なんて言った?

リファクタリングの基本はあくまでテストで、IDEの自動書き換えも型エラーも
リファクタリングをサポートする「便利機能」に過ぎないよ。
しかし動的言語ではこれらの「便利機能」の実装すらかなりプアな状況にあると
いうのが俺の認識なんだが、違う?

>>469
英語だよ。大丈夫？
http://www.refactoring.com/

>>473
ソースコードのリンクを載せろ
それ以外は読まない

bifoar

after

ってリファクタリング本なら、あるだろ
もしないならゴミ本決定

>>466
そもそもお前自身がメソッドシグネチャの書き換え程度の話しか出して
いないだろw 自分で>>451を読み返せ。
他人を笑う前に自分の後出しジャンケンを笑えよw

◆バグを見つけやすくする
「バグとり」その者はリファクタリングではありません。しかし、リファクタリングを行うと
プログラムが整理され、潜んでいるバグを見つけやすくなります。
略

◆機能追加しやすくする
「機能追加」そのものはリファクタリングではありません。しかしリファクタリングを行うと
プログラムに新しい機能を追加しやすくなりますs。
略

そうだろ。やりたいのはコレだろ。でも現実問題、自社のライブラリやら、社外のライブラリを
直接いじる事はできないんだ。だから、変更したい箇所にAdapterやらBridgeを噛ませて動作を整えるしかないんだ。
現状、自分で修正可能なプロジェクトの範囲なら、リファクタリングツールで十分だけどな。

>>475
はっああぁｌっぁアァァアアアアア???？？？？？？？？？？？？？？？
根底からって言ってるのにどうよんだらそうなるわけ？
勝手に俺のレスのいいたことを読み間違えてる分際で？
死ねおｙゴミんｍ

>>452
そういうのは真ん中のを一番下に持ってこなきゃ

>>474
"bifoar"って思わずググってしまったじゃないか。笑わせんなw

とりあえずuy ◆KOAgYBL/Xgは英語も読み書きできず豊富なUML図を
用いた説明も読んで理解出来ないという事はよく解った。

>>477
だから「根底」の例を出せよ。具体例を。
基底クラスのメソッドシグネチャ書き換えかw

リファクタリングとは人間がやるものだ。
機械にやらせるもんじゃない。



アセンブラも同じだ。
ハンドアセンブル最高！

>>472
だって型チェックの話ばかりじゃん。
動的型言語では型チェックを一々テストでも書かないよ。考え方が違うから。
特定のクラスのインスタンスを渡さないと動かないことを強制するんじゃなくて、特定の振る舞いを持つなら良しとする。
パターンやGenericsを駆使しなくても、その言語の普通の書き方で十分な拡張性や柔軟性がある。
自分の足を打ち抜くのが怖い人はJava使ってれば良い。

>>476
> 直接いじる事はできないんだ。だから、変更したい箇所にAdapterやらBridgeを噛ませて動作を整えるしかないんだ。

そのAdapterやらBridgeを半自動で
作成してくれるんだよ。Eclipse+Javaは。

これはリファクタリングではないが、静的言語ならではの
コンパイラのコード理解力

要は使ったこともないのにはったりで騙ってるってことだね

>>483
別に、静的がいいだの、動的がいいだの俺は書いてないんだけどな。

だから、大規模なプログラムの静的言語って

Ａ構造体の引数をとって、Ａ構造体を返す。　みたいな関数が多くなってくるとおもうんだけど
あれって結局、型をなくしたいんだよ
仕様変更に強くする為には、そうするしかない
第一引数にint 第二引数にstring 第三引数に...　っていう感じじゃなくて

構造体.int =5
構造体.string ="aa

function( 構造体 ) ;

こう。


あと、Rubyだとハッシュ引数というのがあって
function({ :int => 5 , :string => "aa" })
こういうのをやってる

こういう手法が、良いとされるって事は、もう結論出ちゃってるじゃん･･･、
動的言語はこの手のことをすべての箇所でやれるが、
静的言語は、ライブラリやロジックのすべての箇所でやるのは無謀
結局、普通にfunction( 1, "aa" , :test ); ってな具合に引数を渡してる関数も出てくるわけで

　そ　こ　が　リファクタリングの為に要する時間を増やすことになる

>>480
へえぇ？？　まずそっからなんかｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

Ａプログラムを納品し、似たような機能のＢプログラムを作らなくちゃならなくなったとき

Ａプログラムの設計はもうズタズタだから、最初から書き換えましょう　とかそういう場面だよ

> Ａ構造体の引数をとって、Ａ構造体を返す。　みたいな関数が多くなってくるとおもうんだけど
> あれって結局、型をなくしたいんだよ

いや、単に「引数オブジェクトの導入」という
リファクタリングを実践しているだけ。

>>479
だからねぇ･･･リファクタリングって、個人の能力が如実に表れるものであって、

おまえにとってその本が良書でも、万人にとってはそうではなく
その著者よりもレベルの高いリファクタリングが可能なやつはごまんといるわけだ
よくそんな「ゴミ本よんでます」なんて公言できますね、
多分おまえ、一定レベルの技術者からは覚めた眼で見られているタイプ、
一定レベル以下の初心者からは、先生（笑）とかってよばれるかもなｗ　最初の1年だけ･･･

> だからねぇ･･･リファクタリングって、個人の能力が如実に表れるものであって、

個人の能力が現れないものがあったら教えてくれ（大爆笑ｗ

>>484
Java + Eclipseしか使ったことは無いの？
3Dデータ変換から、音声生成、マルチメディアとWebシステムとの接続とか
そういう環境じゃ、言語がどうの環境がどうのとか些細すぎてどうでもいい。
言語や環境にとらわれず、どの状況でも応用効かせられる方法をもたなきゃやってられん。

>>488
何同じこといってんの？
たとえばＲｕｂｙ処理系にしてみれば　VALUEって構造体がそれにあたる
静的言語だから、ああいういろんな場所で使う共通の構造体を作る（ しかない。 ）
動的言語だと、そのＶＡＬＵＥの定義すら省く

あとそんな当たり前のやり方にたいし「引数オブジェクトの導入」　とかリファクタリングとかいわれてもこまるｗｗｗｗｗｗ
あの程度、最初の設計段階でかけていなければならないものであって、リファクタリングしてない

>>482
>だって型チェックの話ばかりじゃん。
〜〜〜〜〜〜〜〜〜 深 い 谷 〜〜〜〜〜〜〜〜〜〜〜
>それさえチェックされれば満足なのかよと言いたいが。

この二つの間の論理の飛躍、というか決めつけに気がつかないのであれば
もう何も言うことはない。型の話が多いのは認めるけど、それだけで満足
しているかはまた別問題だろう。

あと静的な型チェックの話は静的言語にあって動的言語には無いメリット
だから、静的厨にとっては話しやすいネタなんだよな。
他の差異、例えばより柔軟なリフレクションやevalの類などは動的言語に
あって静的言語には無いものだから、動的側から話を振ればよい。

> 自分の足を打ち抜くのが怖い人はJava使ってれば良い

自分は怖い人だからそうするわ。
ただ俺が作った銃で他人様が足を打ち抜く例もあるわけで。

やっぱりな。

リファクタリングを分かってない。

本当にすごい物ってのは、
基本なんだよ。なんでもそうだ。

>>490
如実の意味でもググってきたら？
文章よめないのか？　あー日本語よめねーのか、なるほどな
日本語コンプレックスのせいで英語俺よめるぜ（ｷﾘ)みたいになってんだ（笑）

個人の能力があらわれないもの
そりゃ、おまえが普段かいてるコードそのものだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
土方のかいてるソースコードに「 個人の能力 」なんて誤差の範囲なんだけどｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
何かを勘違いしちゃっていたの？？？

>>487
>Ａプログラムの設計はもうズタズタだから、最初から書き換えましょう
>とかそういう場面だよ

それリファクタリングと違う。そもそもだな。

>>451
>もし大規模なプログラムで根幹からちょっと仕様変更しなくちゃならなくなったときは

元々言っていたことと全然話が変わっているだろう。

>>496
ほっとけよ精神薄弱者なんだから。

>>495
> 個人の能力があらわれないもの
> そりゃ、おまえが普段かいてるコードそのものだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

コードこそ、個人の能力が一番現れるもんだろ。

その証拠にさっきお前もソースコード要求していただろ。
個人の能力がどうとかいって。

>>496
ハッァアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアｗｗｗｗｗｗｗｗ？Ｗｗｗｗｗｗｗ
おまえ、マジでど素人だろ
プログラミングさえ満足にできない奴って生きてて恥ずかしくないの？？？？？？？？？ｗｗ


>>498
はぁあ？？？？？？
？？ＷｗＷ？Ｗ
俺が要求していたのはそのコードじゃないのでｗｗｗｗｗさっきから脳内妄想激しすぎｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

わかりやすいキチガイだな

>>497
というか>>499を見る限り、精神薄弱を演出して逃げに入りましたな。

こんなん書いてるアホだもん。リファクタリング以前だよ。

840 名前：uy ◆yyC0rYWEq2 []： 2011/06/18(土) 01:14:50.32
>>832
シーン介した場所ではup.up.up.なんて流石にやらない　もっと細かい場所の事を言ってた
俺はシーンとゲーム内オブジェクトもいろいろと繋がってるから

こんな感じ
player_shot.sym # => :player_shot_002　← 沢山作られるから適当な番号
player_shot.up.sym # => :player
player_shot.up.up.sym # => :scene_name

player_shot.x でプレイヤーショットのx座標
player_shot.up.x でプレイヤーのx座標取得
player_shot.up.up.hensuu で、シーンの共通変数、みたいな

勿論さっきかいたように.upを生で使ってたのは初期だけな

まぁこれは、プレイヤーショットの処理のところをかいてるときの、相対関係で、

シーンのところからプレイヤーショットのxを取得する例をかいていみると、、こうなる
scene.task[:player].search_down_all(/(player_shot_\d*)/).each do | key , value |
　　value.x # => プレイヤーショットのx座標げっと
end
search_down_all関数っていうのは、自分の持ってるタスク以下の正規表現にマッチするシンボルのタスクを全部検索する感じの関数

uy ◆yyC0rYWEq2を生暖かく眺めるスレとなりました。

趣味グラマにはリファクタリングなんて縁がないからね。
全ソースコードは常に修正可能だし
もてる時間を全部つぎ込んで一から書き直してもモーマンタイｗ

>>502
うむ。

コードは一番能力の差が出るところだな。

>>502
　てか、静的動的云々語る前に、オプソのコード眺めるなりして、
コードの書き方勉強すべきじゃね？一部だけ観て全体を見れてないだろ。

>>502
それをだしてきたかｗｗ　もっと貼っていいよそれ

わかる奴にはわかるソースコードのはずだから　どんどん貼れ？


＞＞わかる奴へ
それをみてわかるように、俺はもうリファクタリングがどうのってフィールドにはいない
少し戯れをしているだけ

みんな分かってる。

基地外が誰かを。

文句を言ったやつだ。

>>507
自分からリファクタリングの話を振っておいて、気がついたら
自ら異次元に旅立ちおったwwwww

ではわかる奴の点呼をとろう。
uy ◆yyC0rYWEq2さんの理解者は挙手だ!

はいはいはいはい。

ほらもう8人挙手した。

>>470に示されたリファクタリングを忠実に実行するのは結構難しいな。
単一のコードならまだしも不適切な関連だらけだと修正が波及的に増大する。
ツールの補助がないと無理。

object.search_up(/(window_\d*)/).search_down_all(/(window_.*)/).each do | key , value |

object.search_up(/(window_\d*)/).up.delete

異次元だよ、　
こんな感じに、何やってるかわかんないと思うし
どうせ嫁やしねーんだろ、　
ちょっともう、リファクタラとかそういう場所にはいませんね　　こういうコードおまえたちは書いてるの？かいていないんでしょ
はいはいしゅうりょしゅうりょう


object.window_template2({ sym: :test_win ,
 window:({ default:({ x: x , y: y , sym: :window , d: Image.new( w , h , [100,100,100] ) ,
  window:({ text:({ x: x + 10 , y: y +10 , sym: :window_text , d: Image.new( w - 20 , h - 20 , [10,20,20] ) , }) ,
   state: ({ x: x , y: y + h - 20 , sym: :window_state, d: Image.new( w , 20 , [80,120,180] ) , }) ,
   title: ({ x: x , y: y , sym: :window_title, d: Image.new( w , 20 , [80,170,180] ) ,
    window:({ close: ({ x: x -20 + w , y: y , sym: :window_title_close , d: Image.new( 20 , 20 , [180,220,180] ) , }) ,
     max:  ({ x: x -40 + w , y: y , sym: :window_title_max , d: Image.new( 20 , 20 , [220,220,180] ) , }) ,
     }) ,
    }) ,
   }) ,
  }) ,
 }) ,
})

あぁ、それは自慢だったのか。

>>512
変数を減らすためにあらゆるものを再帰とサーチで済ましていて
そのせいで処理速度がちょっとRubyではきつくなってきてる

安全って何？

メモリ安全？
型安全？
モジュラリティ？
仕様に準拠しているかどうか？

object.search_upとobject.window_template2のobjectって同じものか？

>>515
やっぱり動的言語では安全なソフトは作れない
http://hibari.2ch.net/test/read.cgi/tech/1306002146/1

1 名前：デフォルトの名無しさん[sage] 投稿日：2011/05/22(日) 03:22:26.61
型をしっかり明記してこそ
安全で堅牢、バグのないソフトは作れる

俺はRubyの読み書きが出来るが>>512の例は正直単に読みにくいという
以上の感想が持てん。
集合操作のメソッドチェインとUIか何かの宣言的記述など珍しくもない。

誰か見所を教えてくれ。

>>512
uyさんぱねぇっす
まじ読めねぇっす
たしかに異次元な感じっす

>>514
半分は、正解。

けど変数のサーチによって速度は遅くなるのは毎回サーチする意味ないから、やろうと思えば回避可能
ソースコードの見た目的な問題で、毎回サーチするようにかいてるけど、たかが知れてる誤差

つうか闇ブログ見つけたのか
もう放置してるけど

>>520
お前が馬鹿だという証明になってしまったなｗ

>>512
なんでシンボルにしてんの？
シンボルと同じ名前の変数に束縛しても同じじゃん。
しかも変数のほうが速いだろ。
削除したいからか？

>>517
バグのなさが安全だっていうならCoqあたりで証明するしかないんじゃないか？

>>521
Rubyを使わない俺にその点を分かりやすく解説してくれると嬉しい。

>>524
あ、うん。俺もわからない。

>>516
同じ種類のクラスオブジェクトだけど、別変数、
↓ window_template2やったobject
object.task.each do | key , object |
　object　← search_upやってるobject
end

>>522
殆どのアルゴリズムは漏れは変数名を意識しなくてもかいていけるので、変数宣言をする意味がない



>>524
やめろ

とりあえず、うゆはNGでおk
Rubyスレでもあんまり相手にされてないから放置しといて

たかがほんのわずかにソース晒した程度で
こんなに興味もたれるってなんなの？ｗｗｗｗ
普段バカにしてるくせに
やっぱりuyの実力を心のどこかでは認めていましたｔってこと？？？？

>>527
ハァアＡ？？？
Ｒｕｂｙスレで誰よりも良質で速い回答しているのはどこのどなた様ですかァ????？？？？
夢に飽きたらＲｕｂｙスレにおいで^^^^＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾

> Ｒｕｂｙスレで誰よりも良質で速い回答しているのはどこのどなた様ですかァ????？？？？

ん？ 俺のことだが？

>>526
>同じ種類のクラスオブジェクトだけど、別変数、
>↓ window_template2やったobject
>object.task.each do | key , object |
>　object　← search_upやってるobject
>end

意味が解からん。インスタンス的に別だと言いたいのか？
それともインスタンスを束縛している変数だけ違うといいたいのか？
あと、今の情報だけじゃobject.search_upを実行してる時、objectのselfをyeildに引渡してるように
渡してるようにしか見えん。

Ruby初心者スレの誰かさんは回答速いだけで質としては最悪の部類だからな…

>>531
そう、別インスタンス。hash値が別物。って意味
どうせ理解できんて

今説明してるとこって、漏れの設計の中ではまだ簡単な範囲だぞ
あと一般的じゃない概念を2つは説明しないと全体像すら伝えきれない

ひとつわかったことは
根幹が一般的じゃない作り方してると、その上に乗っかる概念も全然別物にしていかないと
効率が出ないって事、

まずevalも大量に使ってるし、根幹にあるそのobjectのクラスはOpenStructと同じようにハッシュからメンバ変数作る感じだし
そのオブジェクトに必要なメソッドは生成してからmoduleをextendしていく感じ、
なおかつ、そのmoduleは extendedとdefine_singleton_methodと各メソッドも内部でOpenStructとlambda使って
かなりえぐい事もやってるし説明しきれる気がしない
ようは、すべてのオブジェクトの為に、毎回、必要なメソッドを「生成」し、メソッド内部の状態変数にも外部からアクセス出来るように
させる為のdefine_singleton_method　つまり特異メソッドなんだけど、
これはＲｕｂｙだとクラスで多重継承できないって限界があるから、クラスのかわりにmodule、initializeの代わりにextended使ってるだけ
正直、最初は関数型プログラミングの派生だったはずなんだけどその面影もなく、

まずRubyとlambdaに熟知していないと全体像すら見えないのに、相手のレベルすらわからず説明とか、
どのレベルからやっていいか不明だし
無駄

ただひとつ、この事実を伝えるならば、俺がこの手法を開発したことでOOを完全にプギャー出来るようになったって事実

参考になりそうな資料
http://www.youtube.com/watch?v=tf1RxvHWH5c
http://blog-imgs-23.fc2.com/k/a/i/kai1993/20080727184304.jpg

はいはいすれちすれち



















　

あー、あれだ。

初心者ってのは回りくどいことをして
ドヤ顔するよね。無駄なことやってるだけなのに。

俺のやり方とか言い出したら
終わりだろうな。

えぐいやり方ってのはそれに見合った結果が伴って初めて正当化される
のであって、成果物も示さずにえぐいだけではただのオナニー。

まぁ書かれている範囲では単に壮大な車輪の再発明をしているだけの
ようにしか思えんが。

何を使っているのか道具立てばかり説明して何をやっているのかを説明しない
人間は大抵自分自身何をやっているのか理解出来ていないか、説明に値しない
事しか出来ていないというのが典型的なパターンだな。

プログラミングに限らないよ。写真とかスポーツとか、道具が必要な事柄では
大抵このパターンが観測される。

俺の見る限りでは、そのように言うだけの奴がいちばんたくさん観測される

なんだかんだで公開する、自分のアホさに泣けてくる
http://www.geocities.jp/c_zelos/soto/mikomiu2011_06_26_00_07_32.zip

これはuy様だから、書けてるだけ　一般人にこれを書けとは言わない
質問は受け付けねーよ
今回のは、もう根幹部分は完璧になってるから、
もう書き換えることは、ない
ソースコードがすべて

真理について少しだけ語ると、このソースは完璧を目指したソースコードで
オブジェクト指向とかは、非完璧ながらも、それを制御することを目指したソースコードになるんだよ
俺は、非完璧でかいていくほうが最終的には良い、って所までわかった上でこれをやってる
別に誰かがこっち側に来るのも良いけど、多分俺の今かいてるこれが限界点だから、これ以上の進化は無いし
それと対照的に、非完璧 ながらもそれを制御することを目指していくと、限界点が無く、無限に進化し続ける事が可能なんよ
けどまだ見ぬ概念、 擬似完璧というものがあると思う。 その擬似完璧を発見する為には、
非完璧方面が成長するだけじゃ足りず、完璧側も成長させた上で、その集大成を組み合わせることで完成する
俺が死ぬ前に擬似完璧の概念が、自分で発見出来るかも怪しいし、間違っても世界にそれが広まる様子を見れる事はないな･･
完璧なソースコードが広まるのは20年後、　さらなる上、擬似完璧が出来上がるのは100年後といったところ


せっかくのソースもこんな場所に公開しちゃったし


もうゼロの使い魔4期に期待しつつ消えるとする････････

evil-ruby用の新ネタ……？

擬似完璧の、開発入るから、もうそれ　やるよ

p "真理について少しだけ語ると、このソースは完璧を目指したソースコードで
オブジェクト指向とかは、非完璧ながらも、それを制御することを目指したソースコードになるんだよ
俺は、非完璧でかいていくほうが最終的には良い、って所までわかった上でこれをやってる
別に誰かがこっち側に来るのも良いけど、多分俺の今かいてるこれが限界点だから、これ以上の進化は無いし
それと対照的に、非完璧 ながらもそれを制御することを目指していくと、限界点が無く、無限に進化し続ける事が可能なんよ
けどまだ見ぬ概念、 擬似完璧というものがあると思う。 その擬似完璧を発見する為には、
非完璧方面が成長するだけじゃ足りず、完璧側も成長させた上で、その集大成を組み合わせることで完成する
俺が死ぬ前に擬似完璧の概念が、自分で発見出来るかも怪しいし、間違っても世界にそれが広まる様子を見れる事はないな･･
完璧なソースコードが広まるのは20年後、　さらなる上、擬似完璧が出来上がるのは100年後といったところ".scan(/完璧/).size

>>538
手段があっても目的がないからね。
手段を目的化するか目的をでっち上げるしかない。

一晩でスレすげー進んでて笑えるwww

結局、テストは静的/動的言語の両方でするってことでいいの？

個人的な経験としては、テスト書けば「わざわざ型検査に関するテストを書かなくても」
型エラーは見つかると思ってるんだが、静的言語派はそうは考えないってことだよね？
なんでそう思うんだろう？

あ、>>482がすでに同じようなこと書いてた

>>493
それだけで満足じゃないなら、コンパイルして通ればもう安全、
じゃないってことだよね？
安全なプログラム書くためにはテスト必要だよね？
テスト書くんだよね？書いてるんだよね？

で、型エラーはテスト実行時に見つかるよね？
何が問題なの？

>>1-10000
っっっっっはあｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ？

>>547

>>482の流れだと

静的言語：型チェックのテストを書く。静的に型チェックされる。
動的言語：型チェックのテストを書かない。静的に型チェックされない。

ということになるかな？
動的言語は安全そうには見えないが……

>>549
型付け自体が弱くなければ、テスト実行時に型チェックされる

静的厨はテストやらないから、
「コンパイル時にチェックされないこと = 本番までチェックされないこと」
になるんだよね？そうだよね？

そうだよ。

動的厨はテスト完全にやれば大丈夫と言うんだろうけど、
でかいシステムでは、至難の業。

そう言う現実を見てない/知らないから、動的厨でいられ
るんだろうけど。

現実って言葉を多用する奴ほど、そいつの脳内設定のことである確率が高い

型付けの強い/弱いと、静的/動的は直交する概念
強い動的型付け言語の場合、実行時に自動的に型の整合性はチェックされる

だからテストを書いてれば、わざわざ型チェック用コードを入れなくても
型エラーは調べられる

ま、それもこれもカバレッジが十分高い場合だけなのは事実だが、
静的言語であっても十分にテストされてないコードは
安全とは言いかねる

>>552
あなたの現実 = 土方ですよねーwww

>>553
> 現実って言葉を多用する奴ほど、そいつの脳内設定のことである確率が高い

それこそでかいシステムに携わったことないやつの脳内イメージだと思うが。

>>554
> 静的言語であっても十分にテストされてないコードは安全とは言いかねる

それは事実だが、静的言語であればコンパイル時に型の不整合はチェック
されてるから、少なくともそこに起因するバグだけは少なくなる。

>>555
土方かどうかかかわらず、現実だからな。
脳内で作った気になるならいいんだろうけど。(w

プログラマの仕事を刺身パックを作る作業工程で例えると

・C/C++ PG    : 魚を捕ってくる人
・動的言語 PG : 魚を捌いて刺身にする人
・Java 土方   : 刺身にタンポポ乗せる人 

仕事が違えば必要とされる道具（言語）も違う

>>557
あれはタンポポじゃなくて、食用菊だぞ。

>>556
つまり動的言語でもテスト書けば安全ってことと、
静的言語でもテスト書かないと安全じゃないってことは認めるのか？

>>557
>・動的言語 PG : 魚を捌いて刺身にする人

なんか適当に切り刻んだ刺身が出てくる店の話？

脳味噌の知識が適当に切り刻まれてる人の反応

>>556
>それは事実だが、静的言語であればコンパイル時に型の不整合はチェック
>されてるから、少なくともそこに起因するバグだけは少なくなる。

逆に言えば動的言語はコードの汎用性を高めるために
静的言語では機械がチェックしていることをわざわざ人間にやらせているということになるのかな。
プログラマの負担が増えるのでは本末転倒のような気もする。

>>562
お前は型付けの強い弱いと静的動的を混同してる

>>562
テストが実行されれば型は実行時に機械的にチェックされる
どうせテストは書くんだから、プログラマの負担は増えてないよ？

閃いた！まず「安全なソフト」とは何かを定義しようぜ。そうすれば、このスレから
無駄な煽りが消えるんじゃね？

安全なソフト = 型エラーが無い

        静的言語最強

でも実行時エラーは当然ながらコンパイル時には拾ってくれないんでしょ？がっかりです（棒

>>559
> つまり動的言語でもテスト書けば安全ってことと、
> 静的言語でもテスト書かないと安全じゃないってことは認めるのか？

そりゃそうだろ。

ただ、問題は完全なテストを書けるかだ。

>>562
> 静的言語では機械がチェックしていることをわざわざ人間にやらせて
> いるということになるのかな。

単に静的はコンパイル時に、動的は実行時にチェックしてるだけのこと。
ただ、コンパイル時にチェックするためにそれ相応の情報が必要なので、
ちょっとコードを書くのが面倒だったする。

>>561
脳味噌の知識がないやつは気楽でいいねぇ (w

例えば、不等式を満たせば実数型であることも自動的に確定するみたいに
値のテストは型のテストを兼ねる

型のテストが必要になるのは、型さえ合えばどんな値でも構わない場合に限られる

もちろん、値なんてどんな値でも構いませんよ
コンパイル時にチェック出来ないものは全部仕様ですwww

>>563
そう言われてみればそのとおり。

全てのバグをコンパイラが見つけてくれるわけじゃないんだから
動的でいいじゃん。俺があらゆるテスト書くから。

こんな奴信用するか。

動でも静でもない言語ってないの？

アセンブリ

そりゃ鬱的言語だろ

>>573
俺はテスト書かないから、テスト書くって言ってる奴は信じられん
そういうことですね？

静的言語はコンパイラが型検査してくれるから
テストしなくても安全なんですよ。

こんな奴信用するか。

>>578
>静的言語はコンパイラが型検査してくれるから
>テストしなくても安全なんですよ。
>こんな奴信用するか。

誰も言ってもいないような話を持ち出す奴も信用ならんだろう。

ま、言ってるも同然なんだけどね。

>>573
まさにこんな奴らが釣れててワロタ

テスト書かない土方仕事してるのは俺だけであってくれ！って
心の叫びが聞こえるスレ

テスト書くってことにしたら
動的言語でも安全なソフトが組めるってことで
話が終わっちゃうじゃん

なんで静的に型チェックするといったら
テストはしないってことなんだって
勘違いするのか理解できん。

どうしてそう思ったのか、
そこを説明してくれないか？

>>584
>>583

>583
今言ってるのは、型チェックのテストのことだよ。

静的言語では、コード書いているうちに自動的に行える型チェックのテストを
動的言語では手動で書くということでいいのか？
上の方で、型チェックのテストは書かないと
言っていたはずだが。

動的言語は、テストを書かないってことでいいね？

>>586
>>563

>>583
> テスト書くってことにしたら

> 動的型言語では型チェックを一々テストでも書かないよ。
> 動的型言語では型チェックを一々テストでも書かないよ。
> 動的型言語では型チェックを一々テストでも書かないよ。

読みましたか？

テストは書かないのです。

なにが「動的言語は、テストを書かないってことでいいね？」だよ
頭おかしいんじゃないの？www
>>554でも読んどけ

屁理屈の応酬。もっと有意義に時間使えばいいのに。

最初からそれができないバカの隔離スレとして立ったスレで何をいまさらw

>>583
>>437

つーかさ、静的言語にとって、型が違うとか
引数の順番や数が違うとかそういうのは

ケアレスミス なんだよ？

コンパイラが教えてくれるもの。

それを、自分でテストかコード書いて
自分で調べるって、無駄だろ。
ケアレスのためにどれだけ苦労してるんだよ。

>>589
動的型言語では型チェックを一々テストでも書かないよ。

>>592
>>437の
> プログラムの性質を確認するために普通なら必要だった単体テストの数を減らしてくれる

ってのは嘘だと思う

だって実行したら機械的に型チェックも行われるんだよ？
>>570のいうように値をテストしたら型チェックも兼ねるんだよ？
また関数の引数の数も機械的にチェックされるよ？
つまり、最低限のまともなテストを実行したら型チェックは行われるんだよ

まあ、最低限のテストさえしないなら型チェックは行われないが、
そんなプログラムは安全ではない

> だって実行したら機械的に型チェックも行われるんだよ？

実行しなかったら？
たとえ実行したとしても
エラーになるデータを使わなかったら？

しかしレスだけ見ても信用なさそうな奴らばっかだな

>>596
そんなもんアウトに決まってる
でも、その場合は静的言語でも型検査通ってるだけで
値のチェックも何も通ってないんだから
安全とはいいかねる

結局こんなとこでグダグダ言っててもなぁ

日本の土方が書くJavaプログラムよりは
Amazonのプログラマが書くPerlの方が安全だろうし、
結局は書き手の能力に依存しすぎる

俺は日本の土方に書かせるなら絶対に静的言語一択だけど

安全か、安全でないか、0と1で考えるからダメなんだよね。

安全ってのは0から100%まである。
で、漏れや時間がなくて手抜きしたとき、そのパーセンテージは下がる。

テストを完璧にやれば100%だが、
テストの組み合わせの数を考えると、IFが10個あるだけで
テストパターンは1024個にもなる。

そこから考えると、実行時に手動でテストコードを書くよりも
実行前にコンパイラを使うことで自動的にテストするほうが良い。
自動テストなら組み合わせがいくつあっても、テストは1つですむ。

そうやって節約できた時間で、テストコードを書く。
そうして安全度を高めるのだ。

まあ動的言語のほうがテストも書き易いんだけどね

安全かどうかが程度問題というなら、
動的言語で十分にテスト書かれてるなら型検査も十分にテストされてる
静的言語はテスト書かなくても100%型検査はテストされてるが
十分にテスト書かないと結局は安全とは言い難い

動的言語厨は基本的に
「理論的には」で語ってるよね。

現実を知らないのでは？

> まあ動的言語のほうがテストも書き易いんだけどね

それはない。

>>602
現実の話をしたら、テスト後に型エラーなんて見ないからさ
なに型検査にばかり拘ってるのか不思議

動的言語はテストの必要がないほど
小規模のプロジェクトでしか使われないんだろ

>>603
じゃあテスト書いてみてよ

> テスト後に型エラーなんて見ないからさ

それはテストが完璧な場合の話。

世の中に完璧なテストが行われている
プロジェクトがあるのか？
テストが完璧ならバグもないはずだが。


結局、人間ががんばらないといけないものは完璧にはならない。
だから機械（コンパイラ）にさせるんじゃないか。

理論的にはテスト後に型エラーなんて見ないからさ

>>599
同意

>>606
assertEquals(1, 2);

>>607
完璧じゃないなら安全じゃないなら
この世に安全なプログラムは存在しないな
テスト項目は型検査だけじゃないからな

プログラムの安全さ

静的言語withテスト >= 動的言語withテスト >>>>>>>> 静的言語 >>>> 動的言語 >> ∞ >> Java土方のプログラム

理論的には静的言語の方が安全

どっちも安全じゃ無いなら、動くプログラムが速い方が良い

>>611 >>613
ほらねｗ やっぱり動的厨は
安全を0か1で語ってる。
さっき書いたとおりでしょ？

>>614
型検査を0か1かで語ってるのはお前

結局>>599でFAだろ

>>614
>>613はどう見ても静的言語の事だろ

>>610
>assertEquals(1, 2);

それのどこが、

　>>601
　> まあ動的言語のほうがテストも書き易いんだけどね

を示すことになるんだ？

>>618
何言ってんだ？それは

動的言語の方がテスト書き易い(>>601）
=> それはない(>>603)
=> じゃあ書いてみろ(>>606)

って言われて、静的厨が頑張って書いたテストコード（笑）じゃん

>>619
おお、そうか、素で間違ってたよ。

なら、動的ならこれより書き易いんだな。
動的のテストコードフリーズ。

つーか、そこはまともなテストコードを提供できない
静的厨を笑うところ
普段からテスト書いてねーのかよ

まあ、いまごろ頑張ってJUnitぐぐってんだろーな
頑張れよwww

言い訳がましいな。

なんでテストコード書いてみろと言われて
書かずにそんなレスをするのか？

またお題でも出して書き比べれば？

>>623
だってもう動的言語のテストの例は出てるじゃん

それは>>610のことか？

610はJavaでしょ？

それを動的言語で書いたら
どうなるかなーってのが今の話の流れ

>>626
unittestで検索したら>>132があったよ

ずばり、この部分がユニットテスト。
これをJavaでかいたらどうなるのか？

import unittest
class TestFoo(unittest.TestCase):
def test(self):
foo('a', 'b', '111')
self.assertRaises(ValidationError, foo, 'a', 'b', 111)
self.assertRaises(ValidationError, foo, 0, 'b', '111')
self.assertRaises(ValidationError, foo, 'a', 0, '111')

Javaしらないけど、こんな感じじゃねーの？
セミコロンとかダブルクォーテーションとか
どうでもいいところは手抜きして書いた。

@Test(expected=ValidationError.class)
public void footest(a,b,c) {
　 foo(a, b, c);
}
public void test() {
　 foo('a', 'b', '111')
　 foo(0, 'b', '111')
　 foo('a', 0, '111')
}

よくわからんがそれって型チェックが機能してるかのテストじゃないの？
静的言語では書かなくて良いたぐいのテストコードになるんじゃない？

foo関数でちゃんと値が追加されてるかテストしろとかならわかるけど…

>>631
つまりfoo()がhashを返すような関数の場合に変更して、

self.assertEqual(foo('a', 'b', '111')[0], '111')

的なコードを書けってことかい？
なんか本質的なつっこみじゃないなぁ

>>621
>つーか、そこはまともなテストコードを提供できない
>静的厨を笑うところ
>普段からテスト書いてねーのかよ

いや、どう考えても

> まあ動的言語のほうがテストも書き易いんだけどね

なんてこと言ってる奴のターンだろ。

動的言語はテストのときにMockが作りやすいかもしれないね

from minimock import mock, restore
mock(module.bar)
...
restore()

しとけば、...では内部でbar()を呼んでるコードはモックに置き換えられるとか

mock('module.bar')の間違いだった

あと静的言語でも同じことできるのかも

ScalaTestのFunSuiteを使った場合のイメージ

class FooTest extends FunSuite {
　test("foo関数の型チェックテスト") {
　　foo("a","b","111")
　　intercept[ValidationError]{ foo("a","b",111) }
　　intercept[ValidationError]{ foo(0,"b","111") }
　　intercept[ValidationError]{ foo("a",0,"111") }
　}
}

なんかすっっげー。ずっと同じ話で600まで来てんのか。
平行線にしても凄すぎるわ。
もうちょい濃い議論してんのかと思ったのに。
スレ開いて損した。

>>601
静的言語だからってなんでテストコードを静的言語で書かないといけないの？

>>637
そもそもスレタイからどんどん脱線するからなこのスレ
その上コテが住み着いてちゃ纏まるはずがない

て言うか、宗教戦争ってこんなもんだろ。

ユニットテストが正常に動作するなら
プログラムが正常に動作するなんて保障どこにもないし

別モジュールが未完成のハードウェアだったり
要求仕様自体が間違ってたりしたらどーするんだよ？
ユニットテストの目的は別な所にある

>>641
それをいうとプログラム停止問題と同じで100%保証は無理。

＞別モジュールが未完成のハードウェアだったり
仕様が決まってるならスタブ使えばいいかと。

既に静的も動的も無い話になっとる。

>>641
テストで安全は担保出来ないという話なら、同意。
あくまで誤りを検出して、修正するのが目的だから。

型による検証は網羅的で強力だが、
型の制約は実質的に必要な制約より強すぎるんだよな
そこで一種のトレードオフになってしまう

> 型の制約は実質的に必要な制約より強すぎるんだよな

どんな時に、その制約以上のことをしたくなるんだ？

型は制約というより宣言だろう。

今から○○の型を使います。
この引数は○○の型です。

宣言した後、○○の型といいましたけど、
違う型として使います。なんていうのは
そもそも設計が間違ってる証拠なんだよ。

645じゃないけど。
例えばJavaで既存のライブラリ使っててイライラするのはこういう辺り。
Javaでプログラム組む時の設計思想としてクラスの責務をなるべく狭くするよね。
結果として細かいクラスが沢山できる。特にバリュークラスなんかが。
Stringそのままを使うのではなく、Stringをフィールドに持つnichan.res.Nameクラスが作られたりする。
で、Stringのサブクラスではないので、Stringのメソッドは使えないし、Stringを仮引数に持つメソッドにも渡せない、getName()で参照する事しかできない。
クラス設計者が想定した範囲外のことをやろうとすると、とても面倒になる。

>>648
> getName()で参照する事しかできない

参照する以外に何をやりたいの?
getNameしか用意されていないのであればクラスの設計者が参照以外の
操作は安全ではないと言っているのだろう。

>Stringのメソッドは使えないし

getNameで取ってきた値には使えるだろう。

>Stringを仮引数に持つメソッドにも渡せない

getNameで取ってきた値は渡せるだろう。

何が困るの?

>>645
静的型の制約は弱すぎるからランタイムエラーがなくならない

あれだけ無駄に長々と書いてもまだ弱いから、
静的型に使う労力をテストに使った方がいいんじゃないかという話が出てくる

出てくる！
言ったもん勝ちだなｗ

> 静的型の制約は弱すぎるからランタイムエラーがなくならない
なくすのが目的じゃなくて、減らすのが目的なんだよ。

ランタイムエラーは静的エラーと違って見つけるのが難しい。
だからなるべく減らすべきものなんだ。

静的エラーで分かるようなことを
ランタイムエラーにするのは
余計に労力がかかることになる。

Types Considered Harmful
http://www.cis.upenn.edu/~bcpierce/papers/harmful-mfps.pdf

既存の型システムの問題点について端的に
Benjamin C. Pierceつったら型の専門家のはずなので
まあ名無しよりは信用できるだろう

近い将来にはもっとまともな型システムが設計されて
動的の柔軟性と静的の検証・コード生成の効率化を
バランスさせることができるようになる……といいね

動的が柔軟というけれど
別に対して柔軟じゃないな。

Java土方「動的が柔軟というけれど別に対して柔軟じゃないな。（キリ」

おや、言い返せなかった？

静的型付け信者ってクラスの設計者の思想を優先しすぎだろ
拡張メソッドとかバカ仕様すぎる

動的言語は柔軟すぎて大規模開発で使い難い。これは分かる
柔軟さに大差ないってのは、そいつが碌に動的言語を
知らないってことだからアホすぎる

「動的言語？型を省略出来るんでしょ？」程度の理解のJava土方らしいね

なにここ
具体的なレスしたら負けなの？

>>659
具体的なレスをどうぞどうぞ

レスしたら負け

Java土方にばーかばーかと
叫ぶスレだよ。

はいみんないっせいに
ばーかばーか、俺天才

動的言語使ってるほうが土方だもん

結局、動的言語の速度でもアプリケーション開発いけるようになったのが
本当につい最近だから
静的言語側よりも、プログラマーの総数も、ソースコードの総量も
全然まだ無いんだよ　実績も、ライブラリもな
時代遅れの静的厨なんてほうっておいて、つくっていけば良い

実際、型エラー（笑） 程度、
思ったんだけど実際に作っていく段階で殆ど取れてるわ
無駄に、型としてクラス作りまくらなければなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

このスレにいる静的厨の中に
「静的言語も動的言語も開発効率はかわらない（キリッ」
ってのを、マジで言ってそうやつもいるし、マジでレベルが低いんだと思う

>>664
ここはトイプログラムスレじゃないから

>>665
それに触っちゃ、めーっよ

実績ないやつがいくら叫んでも認められないってことにいいかげん気づけよ

>>667
それはあれか？このスレ全体を皮肉ってるのか？w

667 ：デフォルトの名無しさん：2011/06/28(火) 06:35:13.01
実績ないやつがいくら叫んでも認められないってことにいいかげん気づけよ


↑

だから実績を作れよって言ってんだろ　おれは。ｗ

>>665
はぁ

そりゃ、君は動的言語が扱えないから？
トイプログラムしかつくれませーんって？　いっちゃってるわけ？

自分からバカです　　って自己申告してくる奴って多いよな･･･････・・・・・・・・・・・・・・・・・・・

自覚症状なしｗ

土方仕事のwww実績はww無いわwwwww

自覚症状なし

とりあえず、土方と叩くことで
実績がないやつが満足するスレ。

ひ、土方……

馬鹿っていうやつが馬鹿なんだっていうのは
うまい言葉だよね。

結局自分が、○○と言われたら図星で嫌だと
思うから、そのことを他人に言うわけだよ。

本当は自分が○○なんだって自覚してるんだろうね。

あ、うん。土方の話ね。

世の中の評価基準は
学歴や資格よりも実務経験優先だからな

屁理屈野郎がドカタ以下のゴミって事はよくある

特にプログラミング業界はその気が強いね
基本的にどこも経験者募集だ

Java土方って俺には結構Java界を褒めてるように聞こえる
だって、フレームワークやらライブラリやらがすごく成熟してるから
土方作業のように何も考えずに作れちゃうんでしょ？
動的言語でもRoRとかはいい感じに土方させてくれるのかな？

Java土方ってなぜか使用しているプログラマーに言及してるだけだからね。
言語の話してるのに。

じゃあ今度からおまえらのことJava土方って呼ぶわ
リアルで

リアルでJava土方！って会社で叫んでるのを
想像してワロタｗ

>>677
あるある

大規模開発ってのが一山いくらの土方を集めて
開発するってことならJava一択だと一貫して主張してるが、
これはJavaを褒めてるんだよ
素直に喜べば良いのに

他人を卑下しないと世界を受け入れられないのか

職業に貴賤なしですぞ

ひじかた

ひじかたさんはJavaの使い手

俺は世界一の動的言語使い。

土方とは格が違うのだよ。

一山いくらのひじかた

土方言語は仕事では使いたくないな。
そもそもドカが職になんかならないしｗ

JAVAって何

刑務所 <-> JAVA

同感

どうもこのスレを見ていると大規模だから凄い、エライって風潮が見え隠れするような。
大規模大規模って、世の中フルスクラッチな大規模開発ばかりじゃないってのよ。

刑務所はRubyのイメージ。囚人が習うらしいし。

小物を沢山作って、集合させた大規模がこれからのプログラミングなんだよ　ボケが

それは昔のUnixとかからそうだったんだけど、
C++やJavaあがりのプログラマには難しいみたいだ

C++やJavaだって本来そういう風に作るべきだし

と論点をずらします

Java自体は別に悪い言語ではないよ、使い手だって上から下まで居るだろう
ただ、このスレに来るJava使いにロクなのが…

むしろこのスレをスルーするJava使いが賢明ということでは…

Java土方ばーかばーか

>>701
挫折しては再挑戦を繰り返してる趣味グラマーな自分でも答えられる質問がjavaスレだけ多いのが色々物語ってる気がする。。。

動的言語は流行ってないということだ。

というかまったく使わない奴いるのか？

>>706
んなやついるわけねーよ
ここにいる奴らはみんな適材適所で動的静的を使い分けられる
みんなネタで煽りあってるのが分からないのか？

Java土方だけは本気だけどな！
俺は動的言語のプロ

>>707
買いかぶりすぎだろうw
動的言語のメリットである柔軟性に話が及ぶと
そこから先へは話が進んでいってないからね

Windows + Eclipse + Java オンリーのやつとか普通に居そうだ

そんな昔のコボラなおっさんじゃないんだから。
今の若い子はもっと色々できるだろう。

今日もJava土方必死でカキコしてんのかよｗｗｗ

>>711
いや、若いヤツの方がそういうのが多いな

自宅ではMac使ってて、unixバリバリ使えて、LLもそれなりにいける
なんて感じのJavaの技術者なんて30以上のおっさんが多い

>>713
つまり土方は30以上ってことか

Mac使いに安全なソフトは作れない

つまりiPhoneアプリは全部危険ってことか

>>714-715
まあ、なんだ、ガンバレ。

はいはい天使天使

大天使 == uy ?

yes

そのうち、智天使とか力天使に進化するんだろうか。

死ねゴミ

松本龍復興担当相、やや遅れて入室したことにへそを曲げ
知事との握手を拒否

http://www.youtube.com/watch?v=VtUqWdbjnTk

「客を出迎えるときはおまえが先に部屋に入ってから俺を呼べ」
「今のはオフレコで」
「書いたらその社は終わりだからな！」

このスレ向けの話題があった

http://www.infoq.com/articles/twitter-java-use

英語だけど、読めるよな?

ざっと読んだ限りだと
そこで書かれてるのって主にパフォーマンス面じゃね？
安全性の話はあまり書かれてないように見えるが

>>725
そうか
いや、俺は読めなかったのでな

(；^ω^)・・・

>>726
ちょwww

>>725
ああ、確かに...

最後の方で、静的型付けのおかげで全体に一貫性が生まれて、
生産性が上がったよとちょっとだけ書いてある

ある程度の形が出来たあとのプログラミングでは静的型の利点もあるだろうが
仕様がコロコロ変わる時期には動的型か、静的型でも型推論くらいはないとやってられんかな

仕様がコロコロ変わる時こそ静的型だろ。

動的型だと仕様が変わったとき、
ちょっと変えるだけで動く・・・ようにみえて
動いていないって状態になる。
動かせば動かすほどエラーが発生する。

静的型だと極端に変なコードだと動かないし、
一箇所変えるだけで、それに連動する場所を自動で変えてくれたりする
（リファクタイングブラウザ）

それはお前がヘボだから

つーか、動的型使ったこと無い土方は書き込むなよ

ヘボにも使えるから安全なんだが

あーなるほど
それは同意

前例のないものはどのみち危険だが、前例があるなら付加価値でもつけるしかない
だからRubyで作ってJavaで作り直す

動的言語が仕様変更に強いって
何の妄想なんだろうか？

変更があったとき、変更する箇所は
動的も静的も同じじゃん。

その上で、静的ならIDEで一括変更できるけど
動的はまず無理だからって話でしょ？

そもそも動的に大規模プロジェクトは存在しないから
比較できないしな

はいはい土方仕事頑張っててエライね
明日もIDEでリネーム作業頑張ってね

リネームって言うか仕様変更ね。
静的言語は仕様変更に強い。

便利さに嫉妬して、馬鹿にするほどにｗ

仕様変更への対処方法

静的言語：既存コードをIDEで書き換える（renameは静的型付け圧倒的有利、他は知らん）
動的言語：既存コードを動的に置き換える（duck-typing, monkey-patching）

単純に置換するだけなら動的言語でも sed で事足りるけど、methodA の実装を分割して
methodM と methodN に分けた時に、methodA の呼び出しを使っている機能に応じて
methodM と methodN に書き換えるのは静的型付け言語でも無理。

単純な置換　→　動的言語でも可能
複雑な置換　→　静的言語でも不可能

自分は基本的にCしか使わない人間なのだけど、
素朴に不思議なのが、動的言語使ってる人たちは、どうやってソースレベルでデバッグしてるのだろうか？

たとえば、ある動的関数f()が、実行時にa()やb()として動くとして、
ソースを読んだだけだと、実行時のある瞬間に、実際に実行されるのがa()なのかb()なのかの判断は難しいと思う。
すると当然専用のデバッガーを使うことになるのだけど、デバッガーを介さなければデバッグできないソースってのが、
はたして読みやすくて理解しやすいコードなのか？と本末転倒さを感じる。

動的言語の本来の目的は、ソースコードをより理解しやすく管理しやすいものにするためだと思うのだが、
それが本当に上手くいくのだとは信じられない。

たとえばコード中に、まったく振る舞いの違う同名の関数や変数、たとえばまったく振る舞いの違うprint()が大量に定義されてるとして、
このソースを人間が目視で読んでデバッグすることが、本当に容易だろうか？と。
逆に難解になってしまってるような気がするのだが。

たとえば複数種類のprint()があるとして、これら個々の関数にユニークな名前をつけることが、本当に悪なのだろうか？
という根本的な疑問を感じる。
a_print()やb_print()などユニークな名前を割り当てることが、本当にプログラムの難解さや保守の難しさへとつながるのだろうか？
信じられない。どう考えてもa_print()の方が保守管理しやすいコードになると思う。だってgrep a_print * がまさに動くよ。

俺もCはよく使うけど、10行を超えるレスは頭に入らない

静的型付き言語だと、

int foo(long bar, double baz, char qux)

を

void hoge(char *fuga, long fuu, double hoo)

に書き換えるのも簡単なんだろうなあ...

それとも引数の名前を変えたいなんて事は無い?

>>743
そりゃー動的言語どころか、ポリモーフィズム自体を否定する感じだねぇ
ま、言いたいことは分かる

動的言語は実行速度が遅い分、Cと簡単に組み合わせて使えるように出来てる
だから、例えばCでプリミティブなモジュールを実装し、
関数ポインタ駆使して実装するようなコードを動的言語で書くと
いい感じになるよ

>>745
リネーム（笑）って馬鹿にされてる中、それでもリネームの例を出す
そういうの嫌いじゃないぜ

>>742
意味が良く解らんが、
メソッドの分割というか、メソッドの一部分を抜き出すことは
静的言語というかIDEの機能だがEclipseでできるよ。
静的言語がそういうコンパイル時の情報を持っているからこそなんだけど

関数の一部分を選択してメソッドの抽出を行うだけで
その部分を関数にして、引数と戻り値を適切に設定してくれる。
またその逆でメソッドの中身を、そのメソッドの呼出部分にインライン化もできる。

だから関数分割は以下のようにして行える。
1.methodAの中身を抽出して、二つの関数methodMとmethodNの呼び出しに変更する。
2.methoaAのインライン化を行う。一回の操作ですべてのmethodAの呼び出しをインライン化できる

>>747
だからリネームじゃなくて、関数の統合分割の例を出しましたよｗ

>>748
methodA を methodN と methodM に分割したとして、
methodA を呼び出していた側が methodN の機能を使いたいのか、
methodM の機能を使いたいのかを IDE で判別できるの?

って話。

>>746
動的厨のほとんどは
そのような高度なことは出来ない

>>750
少なくともmethodAをmethodNとmethodMに分割することはできる。
そして、methodAを呼び出している部分を適切に検索することもできる。
名前検索ではなくコードを理解しているから、使用している箇所を正しく判断できる。
ここまででも十分楽できたでしょ？
面倒なのはこういう機械的な分割なんだから。

それに今までmethodAを呼びだしていたのに、その一部のmethodNだけでよいとか
methodMだけでよいとかそういう修正が入ることはまず無いと思うんだが？
こんなことをしたら動きが変わってしまうのでこれはリファクタリングにはならないはず。
動作の修正はもちろん人間がやるべきところだよ。

>>752
>そして、methodAを呼び出している部分を適切に検索することもできる。
>名前検索ではなくコードを理解しているから、使用している箇所を正しく判断できる。

それは grep や sed で充分だわ
結局リネームしか出来ないのね...

> それは grep や sed で充分だわ

メソッド名が、getだったら？

>>753
関数の統合分割できてるじゃん。
目が見えないの？

それとも、わ・ざ・と？ｗ

>>755
ただメソッド抽出/分解するだけなら動的言語でも可能
なんで変数の型付けが関係あると思ったの？

>>754
それは get(foo) を getFoo() に変えたいとか、そういう話?
何が問題かもっと具体的に

>>751
ぜんぜん高度じゃねぇwww

>>756
可能かどうかじゃなくて、大変かどうかだろｗ

お前やってみたことあるのか？
関数分割は、単純にコピペすればいいって話じゃない。
関数で使われている変数をどうやって渡すかという話が残っている。

Eclipseを使えば数十行あるコードの中で使われているローカル変数を
ただしく、引数と戻り値に置き換えてくれるんだぞ。
動的言語だと、一行一行みて変数を引数に置き換えていかなければいけない。

>>759
だから、それが何で変数の型付けと関係あるの？
変数のスコープが関係するのは分かるが

>>757
プロジェクト内の複数のクラスでgetというメソッド名が使われていたとする。
このプロジェクトの中から○クラスのgetだけを抽出する方法を

grepで、grepで、教えてください。

重要なので二回言いました。

>>760
変数の型付けとは関係ないよ。

でも、静的言語の話だろ？
静的言語は、変数の型付け以外の機能も持ってるんだよ。

静的型付け言語ではなく、静的言語ね。

コンパイラ（IDE）がコードを理解しているというのは
それだけコンパイラがコーディングのサポートを出来るということ

>>761
実際、getter / setter を変える事ってあんまり無くね?

それが静的言語の最大のメリットなの?
get の rename が?

ポリモフィズムに代表されるオブジェクト指向という概念は１５年前くらいから流行りはじめたけど、
オブジェクトモデルなどという考え方自体が、実に馬鹿げてると思う。

物事を単純化しようとした結果、逆に複雑になってしまってる典型例だと思う。
一見しただけだと、単純化したように見えるので（ほら！同じ名前のメソッドで、いろんなオブジェクトを同じ操作で使えるよ！など）
なんとなく簡単になったように錯覚してるだけだと思う。
実は、この代償として、とんでもないデバッグの難解さを含めてしまってるのに。

実際は、多態性によって、分岐と、その組み合わせの可能性が爆発的に増えるのだから、
デバッグ時の推論すべき量も指数関数的に増えてしまう。
これがプログラム全体で行われるとしたら、まさに保守の悪夢だとしか思えない。

個人的に思うのは、
言語や、設計や、思想をいくら捻ったところで、
ある問題自体に含まれる潜在的な複雑性ってのは、けして消せないし、どんな組み方をしても形を変えてソースに残りつづけるような気がする。
ポリモフィズムのようなものは、その潜在的な複雑性を、単にデバッグの段階まで押しやってるだけな気がする。
だから一見ソースが単純明快になったように感じるけど、逆にその単純さがデバッグの時には複雑性として襲いかかってくるのだから、結局＋ー０なのだと思う。

いたずらに単純さや明解さを謳う新たな言語や設計思想が現れたとしても、永久機関の話のように怪しいと思って疑った方がいいと思う。絶対にどこかに皺寄せが行ってるはずだと。

>>763
質問の内容は正しく理解しましたか？

grepで教えてください。

>>752
>それに今までmethodAを呼びだしていたのに、その一部のmethodNだけでよいとか
>methodMだけでよいとかそういう修正が入ることはまず無いと思うんだが？
>こんなことをしたら動きが変わってしまうのでこれはリファクタリングにはならないはず。
>動作の修正はもちろん人間がやるべきところだよ。

コードの修正の大部分はそういう作業だと思うんだけど、
IDEの自動化はあまり役に立たないみたいね...

>>765
いえいえ、どうぞ get を置換する作業を続けて下さい

>>762
動的言語でも型付け以外は静的に構文検査出来る以上、
型付けが関係ないなら違いは無いよ

>>767
お前は置換することしか思いつかないのか？ｗ

grepするときは、コードがどこから呼び出されているか
知りたいとかあるだろ？

お前さてはgrep使ったこと無いな？

>>768
> 動的言語でも型付け以外は静的に構文検査出来る以上、
> 型付けが関係ないなら違いは無いよ

できるできないが問題じゃなくて、どれくらい出来るかということが重要。
動的言語は構文検査機能が貧弱なんだよ。
なぜならオブジェクトとメソッドの関係が薄いから
ただしくコードを理解することができない。
実行時にならないと分からない情報が多いし。

>>766
> コードの修正の大部分はそういう作業だと思うんだけど、
> IDEの自動化はあまり役に立たないみたいね...

いや、だから機械で出来る部分が簡単になる分
人間の負担が減ってるでしょ？

>>769
俺は getter で検索なんてしないけど、君はするの?

手動でリファクタリングすることが
俺の仕事だって思っているから
それを機械化されると、こまるんだろうな。

>>771
そんな些末な所で得しても嬉しくないんだけど...

道で5円拾っても嬉しくないでしょ

折角メソッドの分割のネタを振ったのに、結局リネームの話に収束するんだなw

>>772
じゃあ、君がこの間検索した関数名でいいよ。

>>770
> なぜならオブジェクトとメソッドの関係が薄いから

これはまさに型付けの問題だよね？
で、duck typing がIDEによるメソッドの抽出/分解と何の関係があるの？

>>774
> そんな些末な所で得しても嬉しくないんだけど...
>
> 道で5円拾っても嬉しくないでしょ

5円だという根拠は？

以上、リネームは大事だよのセッションでした

>>777
> で、duck typing がIDEによるメソッドの抽出/分解と何の関係があるの？

まずmethodAをmethodNとmethodMに分割する。
そしてmethodAが消える。
だがmethodAが他の場所から使われているかもしれない。

duck typingのせいで、methodAという呼び出しを見つけたとしても、
これが本当に今変更した（無くなった）methodAなのかわからない。
名前が同じだけど別物かもしれない。

で、grepじゃ正しく検索できないって話つながるわけかｗ

>>780
静的型付けでも methodN に置き換えるのか methodM に置き換えるのか
決定できないから自動化は出来ませんねえ

>>781
自動化ができるところとできないところを区別しよう。

それともお前は人間が要らなくなることを期待してるのか？

自動化できる所　→　単純なリネーム
自動化できない所　→　その他沢山

>>783
なぜ今リネーム以外の例が出てるのに、
それをかたくなに見なかったことにしてるの？

わざと？
ねぇ、わ・ざ・と♪？

>>784
getter の検索の話?

そっちでせめても無駄だと思うけどね...

>>780
関数統合分割するときにも
高いメソッド識別能力が必要ってことだよ。

同じ単語を出すだけのgrep程度では話にならない

methodMまたはmethodNどちらかを呼ぶ形式に書き換えるならともかく、
そうしないならmethodAを消す必要ないじゃん
methodMとmethodNに分割し、methodAからmethodMとmethodNを呼ぶように
書き換えたら良いだけ

>>786
だから分割は無理じゃん...

> そうしないならmethodAを消す必要ないじゃん

消す理由はコードの見通しを良くするためだよ。
無駄なコードを無くしてきれいにすることは、
汚いコードを残したままにするというのとは対極にある考え。

>>787
それリファクタリングとして意味あるの?

あと、一応確認しておくと今考えてるのってpublicメソッドだよね？
privateメソッドだと動的言語でもリネーム出来ちゃうからね

>>780
よく分かった。

一見関係ないように見えることでも
名前を意味論的に正しく認識出来るってことは
重要なんだね。

動的言語では、たぶんこれ以上のコードをコンピュータが
理解することはできないと思う。限界。

>>790
methodAが読み易くなるなら意味がある
むしろ、methodAをmethodMとmethodNの両方呼ぶように書き換えることに
メリットあるのか？

>>791
まだリネームにこだわってるのかｗ
もう終わったぞ。

>>793

> むしろ、methodAをmethodMとmethodNの両方呼ぶように書き換えることに
> メリットあるのか？

あるよ。methodAの中身がすごく長くなってしまった場合とか。

そもそもメソッドを分割したいってのは
動的言語厨がいいだした話だと思うがｗ

>>795
はあ？
methodAが長くなったときに、その中身を分割するのは
読み易くするのに意味があるよ？
でも、呼び出し側を二つに分割して両方呼び出すのに何のメリットがあるの？

>>794
いやぁ、だって普段publicなインターフェースをコロコロ変更しないからさ
静的言語で開発してる時でもさ

>>796
メリットあるから二つに分割したいって
動的厨が書いたんじゃないのか？ｗ

>>797
コロコロ変更しないというか、
この程度のことでも変更したら、問題が発生するから
動的言語ではやれないってだけじゃないのか？

メソッドを使用している場所すら的確に
判断できないんだからね。
そりゃトラブルおきるよｗ

まあ、リファクタリングを正しく実行出来ていないところは
「動いているコードを修正するな！」が原則だからな。

一度リリースしてしまえば完成な時代ならともかく、
今は「動いているコードを修正しながら改良させていく時代」なので
修正のしやすさの重要性はかなり高い。

>>798
ちゃんと>>787読んでるか？読んでも理解出来ないのか？

methodAを二つの関数methodMとmethodNに分割し、
methodAをそれら二つの関数を呼ぶように書き換える
これはmethodAが読み易くなる場合があるから
分割すること自体は意味がある

一方、methodAを呼び出してる側のコードについて、
もしmethodMとmethodNの両方を呼び出すなら、
そのままmethodAを呼べば良いって言ってんの

リファクタリングの原則ねぇ
「公開インターフェースはシステムの振る舞いと見なされる」から
変更するのはリファクタリングじゃないんだけどね

まあ、publicメソッド = 公開インターフェースかどうかは状況依存で、
オープンソースだと殆どイコールだけど
インハウスだと公開インターフェース？何それ？状態だよね

>>801
それはメソッドのインライン化の目的を聞いているわけだよね？
リファクタリング本にその答えは書いてあるけど。

ぐぐれば見つかると思うけど、
手元にある本には、
「わざわざ名前をつけなくても意図が明らかなメソッドがある。」
という理由が書いてあるね。

こうやってインライン化することでメソッドの数が減らせるとも書いてある。

>>802
そういう場合にも、これは本当に公開インターフェースであるべきなのか？
ってときも、privateにしてしまえば、
静的言語なら、コンパイルエラーでわかるし、
いろいろ便利なのにね。

>>803
extract方向の、いわば抽象化のメリットは分かるけどinline化が
読み易さに貢献するとは思えないんだよね
特にpublicメソッドの中身を他のクラスのメソッド内に展開するメリットがね
動的言語だと、しょうもない関数はメソッドにせず最初からクロージャで書くからってのもある

それに、名前を一意に変換できない以上、
そのメソッド名は複数のクラスで定義されていて、namespace等では
判別不能な程ありふれてる名前なんだよね？getとかpushとかさ
そんな重要な名前を後でinline化するようなメソッドに付けるなよw

>>802
> オープンソースだと殆どイコールだけど

それはオープンソースの ”クラスライブラリ” の話だな。

オープンソースでもプロジェクト内で閉じたクラス
（プロジェクト外で使うことを想定されてないクラス）なら
publicメソッドを変更してはいけない理由なんて無いし。


というか、大抵のアプリはライブラリ以外は
外部のプロジェクトで使われることを想定してないんじゃないか？

> 動的言語だと、しょうもない関数はメソッドにせず最初からクロージャで書くからってのもある

なぜクロージャーがメソッドの代わりになるの？
変な使い方してそうだなｗ

> そんな重要な名前を後でinline化するようなメソッドに付けるなよw
未来のことは誰にもわかりませんよｗ

>>807
名前付けるまでもない処理を纏めるのにクロージャ使うだろ
え？クロージャのある言語使ったこと無いの？

>>808
え？ 長い関数の代わりに
クロージャーを使うんでしょ？

methodAは長い関数、だから分割するって話なんだし。

名前付けるまでもないならクロージャーなんか使わずに
{
　まとめたい処理
}

ってやればいいだけだと思うが？

>>809
クロージャについてはinline化一般について言ってた
確かに長い関数についてはクロージャは使わん

でも、長い関数でかつ複数のクラスで使われてるようなメソッド名が
「わざわざ名前をつけなくても意図が明らかなメソッドがある」に
該当するとは思えない
具体例を挙げてくれれば納得もするが

>>811
長い関数をリファクタリングした結果
もともとの関数が極端に短くなってしまった場合の話だろ。

>>810
ですよねｗ

クロージャーは他の関数に渡すときに使うけど、
まとめたいだけには使わないなぁｗｗｗ

>>810
変数のスコープを分けたいけどブロックが深くなるのを嫌うときや、
同じ処理が（ループではなくて）複数回呼ばれるときとか、
クロージャ使う場面はいくらでもある

> 変数のスコープを分けたいけどブロックが深くなるのを嫌うときや、
クロージャ使っても深くなるだろｗ

> 同じ処理が（ループではなくて）複数回呼ばれるときとか、
纏めるだけの話限定なｗ

>>812
へー、メソッドを消すかどうかを
意味的に分かり易いかどうかじゃなくて
「関数が長いかどうか」で決めるんだ？
複数のクラスで定義されてるような重要な名前のメソッドなのに？

>>815
def f():
    def g(x):
        print x
    for i in range(100):
        for j in range(100):
            for k in range(100):
                g(k)

>>817

> ぐぐれば見つかると思うけど、
> 手元にある本には、
> 「わざわざ名前をつけなくても意図が明らかなメソッドがある。」
> という理由が書いてあるね。

消すとしたら必然的に短い関数になるだろ。

使われ方じゃなくて、関数名で消すかどうか
決めるほうがおかしい。

>>819
今は、「関数まとめるだけのためにクロージャーを使う」限定。

訂正

「名前付けるまでもない処理を纏めるのにクロージャ使う」限定

>>819
短い関数であることは必要条件であって十分条件じゃない
関数名はどう抽象化してるかを表してるんだから
リファクタリングにおいて消すかどうかに名前が重要なのは当たり前
目的は「コードを分かり易くすること」だぞ？

じゃあ、名前は十分条件なのかよｗ

>>822

必要条件・・・短い関数じゃない
十分条件・・・「わざわざ名前をつけなくても意図が明らかなメソッドがある。」

これで十分条件を満たしたが、
お前はの反論は、反論になってるのか？

名前がどうしたって？
それなに条件だよ？ｗ

短い関数であることが必要条件って言ってる以上、
名前だけでは十分条件に成り得ないのは
論理的に考えて分かるだろ？

だから、十分条件は「わざわざ名前をつけなくても意図が明らかなメソッドがある。」 だろ

名前が重要だからってのは
いったい何の条件なんだ？

>>824
主張は簡単だよ

複数のクラスで同じ名前が定義されてて、publicメソッドで、もともとは長い関数だった
そういう関数で「わざわざ名前をつけなくても意図が明らかなメソッド」であって
かつinline化したほうが分かり易くなる例はあるのか？ってだけ

個人的な経験として例が思い浮かばないだけだから、具体例があれば納得する

>>818
> へー、メソッドを消すかどうかを
略
> 複数のクラスで定義されてるような重要な名前のメソッドなのに？


今消すと行っているメソッド名はmethodAだぞ。
複数のクラスで定義されているような重要な名前か？

>>828
複数のクラスで定義されてないなら
動的言語でも安全に書き換えられるね

>>827
お前話がごっちゃになってるだろｗ

> 複数のクラスで同じ名前が定義されてて、publicメソッドで、もともとは長い関数だった

消すという話になってるメソッド名はmethodA。

複数のクラスで同じ名前が定義されてるのは別の話。

>>829
> 複数のクラスで定義されてないなら
> 動的言語でも安全に書き換えられるね

一番の問題点、

複数のクラスで定義されてない、
duck typingで呼び出されることもない、
実行時に追加されることもないってのを
どうやって証明するかってのを解決出来ればなｗ


それができないから動的言語は駄目で
実行しなくても分かる静的言語がいいって流れだろ・・・

>>831
複数のクラスで/実行時に定義されてないかはgrepで分かるだろwww

grep vs IDE

コロコロって書いて寝てたらあらぬ方向へすごい進んでるな…
もうちょっと書き方を考えるべきだったか

俺が眠気眼で「仕様がコロコロ変わる」っつーたのは
そもそも要求仕様が固まっていないレベルな

リファクタするったって、テストコードくらい走らすだろう……
あとリファクタを話すならsmalltalkの事もたまには思い出してやってください。

EclipseもSmalltalkで作ったのをJavaで作り直したんだよな。

なぜ、お手本がないと安全なソフトは作れないのかというと、
相対的に優劣をつけることしかできないからだろう。
絶対的な安全が保証できるなら他のものと比較する必要はない。

Rubyバカにしてる子ってさ
変数に＄ついてる言語触ってるって事だよね

いちいちSHIFT＋４キーおして ＄ 打ちまくってる感触はどう？


死ねゴミ

>>835
問題は、そのテストコードが信用できるかでしょ？

テストコードはバグがあることを証明できても
バグがないことは証明できない。

テストコードそのものが不足していれば、
その部分のテストはできない。

>>832
> 複数のクラスで/実行時に定義されてないかはgrepで分かるだろwww
関数名でgrepする。
もしその関数が一つしか見つからなかったら話は簡単。

でも普通は複数見つかる。
複数見つかったとき、これが複数のクラスで定義された関数なのか
それとも一つのクラスの関数なのか、それを見分けることはできない。

古いバージョンをすぐ消してしまうのはよくない
vistaを思いついた瞬間にxpを消すようなやつが安全なわけがない

>>839
変数の型付けが静的だろうが動的だろうが、クラス定義はあるわけで
そこ見れば同じ名前のメソッドが複数のクラスで定義されてるか分かるだろう
まったく意味不明過ぎる
Java以外使ったこと無いから想像で書いてるだろ

Javaのライブラリは簡単に古いメソッド消さないようにしてるのに
土方ときたらしょーがねーな

http://download.oracle.com/javase/6/docs/api/deprecated-list.html

静的型厨がよく言う
「型整合が検査できればバグのほとんどを発見できる」とか
視野が狭いとしか言いようがない。
バグの過半数は仕様の間違いと仕様の間違った理解が原因だ。

>>843
後者はともかく、前者は間違ってても仕様は仕様だろ

良くあるだろ？
これバグじゃね？不具合じゃね？と聞いたら「仕様です」って答えが帰ってくるの。あれだよ

>>843
動的型付け言語がこれだけ普及している中で、静的型付けが無いと
仕事ができないと主張するには、それくらいの事は言わないとな

設計意図にまつわるバグについては、一切無視
話題がそちらの方向に向かいそうになったら、全力阻止

>>841
> 変数の型付けが静的だろうが動的だろうが、クラス定義はあるわけで
> そこ見れば同じ名前のメソッドが複数のクラスで定義されてるか分かるだろう

的外れ。

問題は同じ名前のメソッドが複数のクラスで定義されていることを知った後の話だよ。

たとえばfooという名前のメソッドが複数のクラスで定義されていました。
さてobject.foo() はどのクラスのfoo()でしょうか？

grepしたらfoo()を使っている所が50箇所見つかりました。
あなたはどうやって、fooとクラスの対応表を作りますか？

>>843
> 静的型厨がよく言う
> 「型整合が検査できればバグのほとんどを発見できる」とか

あ、それ捏造だよｗ
俺がついた嘘。

バグのほとんどを発見できるは聞かない
聞くのは動的言語よりバグを発見しやすいとかそんな感じ

>>848
聞かないことはないだろ。
絶対聞いたことがあるはずだ。

なぜなら俺が言ったからね。（ただし捏造ｗ）

MLみたいに型がガチガチな言語だと
コンパイルが通ればかなり安心できる
びっくりするぐらいまともに動く

もっとも、コードが意味的に間違っているケースは検出できないので
まあそこは仕方ない、テストが必要だよねっていう感じ

テストを実行前テスト（静的テスト）と
実行時テスト（動的テスト）に分けるという考え方があるよ。

動的テストは実際に動かさないといけない。
ソフトウェアが自動的に動くことはなく、
人間が動かさないといけない（コードを書いて動かすのも含む）
そうなるとテスト作成のための時間がかかるし品質は人間に依存してくる。

静的テストは動かさない状態でやるので
ソフトウェアで自動化できる。

静的テストで完全にテストできるわけではないけれど
動的テストでやる作業を減らすことはできる。

>>846
そのメソッドを持つクラス全てが対象となり得る、でよくね

世迷言いってるのがいるなあ

いよいよ、scalaが最強という説が一般化されつつあるな

用途に応じて、使える言語の中から一番良い言語を選ぶだけだけどなあ

・動的型付け言語を使うと能率が上がるプログラマ
・静的型付けじゃないと文句を言うプログラマ
・動的型付けでも静的型付けでもガシガシコードを書くプログラマ

どれになりたい?

仕様が漏れても動くものを作ってくれるプログラマを口頭で指示するSE

> ・動的型付け言語を使うと能率が上がるプログラマ
能率は上がらない

> ・静的型付けじゃないと文句を言うプログラマ
静的言語が優れていると言ってるだけ、それに文句を付けてるのが（ｒｙ

> ・動的型付けでも静的型付けでもガシガシコードを書くプログラマ
ガシガシコードを書き、そして静的言語の優位性を語ってる。
両方使っているからよく分かってる。

そういや、動的言語が開発効率がいい理由が
ひとつも出てなかったよね。

>>764
別にOOがプログラミングを単純化したと主張している人はいないと思うけど。
分析・設計行程ややこしくなったけど、それに見合うメリットが存在しているから使っているだけ。

組み合わせ爆発は杞憂というやつだと思う。
可能性だけで存在しない組み合わせまではテストは必要ないわけだし。

foo(Hoge hoge)というシグネチャのメソッドがあったとして、
hogeオブジェクトにはHoge型としての振る舞いが期待される。
fooメソッドを使う場合には、それを満たすオブジェクトを渡すべきなわけ。
親クラスとは全く異なる妙な挙動をするサブクラスのことなどは気にする必要はない。
C言語でも型キャストすればコンパイル通るけど、
例えばintをdoubleに型キャストして引数渡されたときの挙動まで面倒みないよね？

>>858
動的型言語の良さは、書き起こしやすさだと思う

型の依存関係、整合性はおぼろげなままでやってける
型変換は自動で済ませられる部分はそれでいいし
ライブラリもベスト・エフォート型が大半を占める
古き時代からメモリ管理は自動が当たり前だったからそれもほぼ無い

だからこそ、最もプログラミングの本質的な部分に集中出来るのよ
アルゴリズムだったり、フローだったりするが
思考が本質以外の部分に寸断されることが少ない、だからこそ書き起こしに向く
その上で厳密性を持たせたい部分には持たせられるから
安全なコードだって充分に書けるしな

多人数開発に静的型言語のが良いのは分からんでもないよ
ただ思考は寸断されたくないな、そここそがプログラミングの本質なんだから

>>857
クロージャについて>>813>>815みたいなアホなこと書くやつが
動的言語でガシガシ書いたことあるはず無いだろw

それに型付けとスコープも混同してるし>>759、
型付けの強弱と静的動的の違いも分かってない>>562
まさにJava以外のプログラミングというものを理解してない真性の土方だよ

>>764
Pythonの場合だと多態が必要無い場合は
普通の関数を定義することが多い（OOP機能が後付けだからかもしれん）
関数はモジュール名+関数名で一意に定まるから
まさに grep module.func * が機能する

>>857
どの動的言語でガシガシコードを書いてたのか詳しく

>>846
何が的外れだアホ
無知をばらされたからって勝手に問題設定変えるな

その話はもう秋田
それより>>863のが面白そう