静的型付け言語の潜在開発生産性は今の100倍 ×5
■ このスレッドは過去ログ倉庫に格納されています
int a = 1; a = "a"; ← エラーになる。 型がない言語ではできない芸当です。(爆笑) 人間がやっていたことを、コンピュータにやらせる。 これが生産性を上げる最大の方法。 コンピュータは間違わない、同じ事を何度も高速に行える。 その為に、コンピュータがコードの意味を正確に 認識できる方法が必要。実行しないとわからないことは コンピュータは認識できない。 すなわち静的型付け言語であれば、実行しなくてもわかるので コンピュータが理解できる。そうすれば様々な コンピュータの高度な情報支援が得られる。 コンピュータのバックアップを受け、人間の生産性は 限りなく向上する。 前スレ 静的型付け言語の潜在開発生産性は今の100倍 ×4 http://toro.2ch.net/test/read.cgi/tech/1383572174/
ちなみに動的言語でも変数に型とは別に不変条件を設定して、 不正な代入をエラーにする機能は実装可能だよ。 静的厨って空気を吸うように嘘をつくんだね。 静的厨って人間として最低のクズだねw >>3 全く同じコードでないと 実装したとはみなしません。 静 的 型 付 け 言 語 = う そ つ き 言 語 動的言語ってJavascriptとかでしょ? じゃあもう結論出てるっしょ。 変なとこクルックしたらおかしくなるページとか普通にあるし。 変なとこクルックするのが悪いとかいうけど、変なとこあったらクルックしたくなるよね。 普通だよね。 >>6 見たことねえよそんなページ、薄ぼんやりとした脳みそでデマ撒き散らしてんじゃねえぞ。 クッキークリッカーであらゆるものをクリックしまくった俺が言うんだから間違いない。 >>7 なんでクルックにツッコミ入れないの? 可愛そうだと思わない? >>5 そうなるな。 NumOrStringの実装出せなかった時点で詐欺確定だわ。 生産性詐欺。 >>8 そんなとこ指摘してたらきりがない、>>6 の文章の瑕疵について指摘しようと思えば 13箇所指摘できる。俺は国語の先生やりたくてここにいるわけじゃない。静的言語厨の 悪辣な生産性詐欺を断罪するためにここにいるんだ。 数値と文字列の両方が格納できるクラス。 これを静的言語では実装できない。 根拠は実装出せなかったこと。 初心者ですよろしくおねがいします。 3 件の検索結果 時間指定なし 日本語のみ NumOrString の検索結果が見つかりませんでした。 num or string の検索結果を表示しています。 検索ではわかりませんでした。 このあたりに hoge厨が逃げ込んだという目撃情報があります 若干姿を変えていますが挙動不審なため一目で分かりますので 市民の皆様は見かけても決して声をかけたりせず 近くの警察官へお知らせ下さい > 数値と文字列の両方が格納できるクラス。 出来そうな気がするけど? 似たようなものに、C#のNullable型ってのがあるよ。 null+特定の型が格納できる型。 >>11 前スレの静的厨が考えた最強のクラス。 NumOrStringにはsetValueというメソッドがある。 値を代入するにはsetValueを使わなければならない。 つーか、varに相当するのは 何でも型じゃねーの? VBでいえばVariant型でしょ? Object型でもいいけど。 >>13 あらかじめ使う型がわかっていないのなら型消去の仕組みを使うのがいいだろね。 そうじゃなければ共用体に入れるとかだろね。 なんでそんなことで議論してるの? 文字列と数値を両方格納できる型を用意するのは簡単だろ ただ、内部に状態持たせたら副作用が云々言い出すし、 それらのにhidingで書いたもケチつけるし、 何が言いたいのか分からんのが正直な所 >>20 一人のキチガイが 静的言語では、実現不可能だって言ってるだけ。 みてればわかるよ。まさにキチガイって感じだから。 状態を持たせるのは正しい設計だと思うけど、なんでダメなの? 魔術的なものを期待してるの? コンストラクタで値を指定して、 インスタンスを作成した時から変えられないのなら それは状態じゃないから問題ないんだよ。 >>19 前スレの奴は結局出せなかった。 NumOrStringを書けって言ったら「俺は興味ない」という 地獄のミサワの真似して逃亡した。 int a = 1; a = "a"; ← エラーになる。 型がない言語ではできない芸当です。(爆笑) わかった!お話がしたいだけで中身はそんなに関係ないんだ。 C++で演算子オーバーロードしてintでもStringでも扱えるVariant型ってのを作ったんだ。 そしたらたいして便利でもなく動的言語って意味ないと思った。 >>30 キチガイに対してじゃね? > だけど、ここまでヒント上げて気づかない奴に > 俺は興味ないかな。じゃあね。 俺もキチガイに興味はないなw >>24 じゃあ正しく設計したNumOrStringを書いてみろよ。 >>25 そういう時は素直にテンプレート使おうよ。 union NumOrString { std::string str; int n; }; その「正しい定義」って動的型では実装不可能なんだよな。 >>29 それわかるわ〜。 結局なんでも入れられるってめんどくさくなるだけなんだよねえ。 頑張って損した気分になる。 >>30 知らない。前スレの静的厨が言った言葉だ。 逃げ口上としてもっともらしいことを言おうとしただけで深い意味はないだろ。 彼女いない歴=年齢のやつが「俺女に興味ないから」と言ってるようなもの。 完全に防衛機制における合理化。Dの烙印を押された奴の断末魔。 >>34 >>24 に聞けよw>>24 は正しい設計だと思うって言ってんだから その「正しい」の定義にしたがって実装していただければ幸いでございます。 >>35 そりゃ単に同じメモリ領域にぶちこんでるだけじゃないか "1"が1と同値になるような実装でないと認めません >>13 type NumOrStr= |Str of string |Num of int let s=Str "hoge" let n=Num 100 n|>function |Num v->数値処理 |Str v->文字処理 F#だとこんな感じか。 めんどいのでintに限定したけど他の数値型が入るようにも出来る。 上のnとかsを使うところで場合わけで処理分岐可能。上の例は直後で分岐してるので間抜けだけど。 静的厨は童貞。 静的を性的と脳内変換して悦楽に浸っている現実逃避の変態。 つまり、NumOrStringとは童貞が創りだした最高の女。 ゆえにそれを見せろと言ったら即座に逃亡をはかる。静的厨は卑劣極まりない。 何でも入れられるといいなと思う時の代表が構文解析とかだろね。 スタックに積む値に意味動作から返される値を含めて積めると便利だから。 次にスタックから取り出されて還元されるときは、それが何であるか 意味動作自体が知っているから値自体に状態が必要ないし。 僕は共用体を良く使うよ。 読み込むBNFに還元されるときの型を書いておくんだ。 頭いいでしょ? まあ普通にこうするか。 別に頭良くないね。 >>37 頑張って損というのは、企業への忠誠と努力が無駄だったときくらいだな。 >>46 943+1 :デフォルトの名無しさん [↓] :2013/11/24(日) 14:38:53.62 >>942 Javaで書くならこんな感じかねぇ。 NumOrString a; a.setValue(1); a.setValue("a"); setValueの実装はオーバーロードで。 >>37 頑張って損したとは思わない。 社長が女たらしで売上げの半分を社長が独占している会社で努力することだろ。 >>45 ジジイの介護みたいな会社で努力するなら、 ホンモノの高齢者の介護をした方がマダましなんじゃないかって 爺どもはあと10年でいなくなる、そしたら俺の天下だと思って頑張ってるけど、 そうでもないの? 動的型使ってる奴がみんな同レベルと思わないでくれ NumOrStringなんて考えた奴が低能なだけ >>52 重役の息子や孫がヘッドハンティングとか言ってコネで入ってきてスピード昇進なんてよくあること。 コネで入ってきたやつに負ける程度の実力なら、下についたほうがお得な気がするけど、 そうでもないの? 静的動的の違いより、DFAとNFAの差のほうが気になる。 DFAは実際ほとんど使われていないけど、今後はDFAじゃないとダメなんじゃないのかな? いまDFAが使われる場所ってコンパイラとかデスクトップで完結してるような NFAでもいいようなとこだと思うんだ。 NFAってネットワーク越しにやってくる指令の解析にさえ使われていてこれ凄く危険。 そう思わない? >>55 日本社会において実力っていう物の5割はコネのことだからな。 Javaが画期的だったのはDFAであることが保障されてたことじゃないのかなあ。 あんまり話題にならないけど。 オートマトンなんかどうでもいいよ。そんなところがユーザーが気にすべきところならその言語はお粗末だ。 決定性がないってことは、外部からの入力に対して計算を実時間内に 終了できることを保証できないってことだよ。 事実上無限ループさせられるってことじゃないの? 30秒で打ち切るとかそういう場当たり的な対策でいいの? 記憶領域をいくらでも使わされるとか。 そんなんでいいの? これは言語関係ありません。 たぶん。 全然話が見えてないんだけど、DFAとNFAは等価ですよ? >>41 > "1"が1と同値になるような実装でないと認めません いきなり後出し追加要件笑たわ 静的型付け言語=平気で嘘をつく人格障害者向けの言語 >>41 そんな仕様の言語は動的型でもゴミの部類ですよ さすがに自演だな こんなバカが1日に2人も来るわけない 1と"1"が同値かはともかく16と"16"だと基数は何なのよとか"0x10"は受け付けるのか とか日本語対応で漢数字"十六"にも対応しようぜとかフランス語は16までは単語が 有るけれども17からは"10と7"の合成なんだぜとか生産性のさほど無い話に発展すれば よいのに。 >>68 DFAで保証の人? 何を保証してるのか説明plz ポアソン分布について話してるとこに足し算の説明求められても そこは自分でってなるよ。 なるよ。 ならなかったっけ? そんな感じであります!隊長! うそです! そんな感じじゃないです。 馬鹿にされたからひがんだだけっす!隊長! つまりJavaのJVMが行うgcの待ち行列はポアソン分布に従う とにかくJSネタに我田引水して「ES7で解決している」と言ってみるとかネタは無くとも とりあえず「Cの10倍速い」と言うのが訓練されたJSerであって、「呼んだ?」だけでは物足りない。 定価1万円くらいのJavaの本がブックオフで105円だったので買ってきました。 2011年初版です。 なんでこんなに安くなってたんだろ。 見たところ新品みたいなのに。 これ出した人一度も読んでないよね。 こういうの流行ってるのかな? Javaの第二形態がJS。 もちろん進化した分Javaより強い。 俺JS使いだけど、 JavaScriptは Cの100倍速いよ JavaScript は C の10倍 名前が長い S(100); /* C */ int S(int n){ int i, sum; for( i = 1; i <= n; i++ ){ sum += i; } return sum; } /* js */ function S(n){ return n * (n+1) / 2; } そう、JavaScriptはCの100倍速い ジャバスクリプトとシーなら4倍だ。10倍って大げさすぎたいしたことない。 >>90 それJavaScriptにおける最適化手法の進化について理解していない。 将来的にはn * (n+1) / 2という式から「あぁ、この人は1からnまでの総和を求めようと しているんだな・・・」と自動的に解釈してループを使ったコードに書き直してくれる ようになるらしい。 >>97 何のためにSIMD対応を進めているとおもっているのか。 ループに展開してGPUで並列計算するに決まっているじゃ無いか。 最終的には5050という数字を見つけると、1から100までたしたいんだなと解釈してループコードに書き換えてくれる MAPが並列で速くなるのはわかるけど REDUCEが並列で速くなる…? >>100 もちろん、帰納的に100個のルーチンを展開してそれぞれ実行する >>100 隣接する偶数番目と奇数番目でペア作って並列で足し算するに決まっているでしょ。 100までの総和なら最初のイテレーションで50まで要素が減る。 100回ループ回さなくても5〜6回のイテレーションで計算できるぞ。 アホプログラマは5歳のガウス少年よりアホってことが良く分かりますね なあに、才能と計算リソースは無駄遣いされるものと相場が決まっている。 ラズパイにUbuntu入れてJSでソフトを作りました。 結果、オープンハードで2倍、オープンOSで2倍、オープン言語で2倍、合わせて 100倍速くなりました。 これを32台つなげたクラスタは京より少しだけ速くなりました。 次は64台つなげてみたいです。 おまえら元気だよな。ネカマとJSerになりきるのはよう続かんわ。 総和ならこれくらいのことはやって欲しい。;p {Color red. Color green. Color blue} sum "=> Color white " ネタ扱いされてるけど、JSがCの二倍速いのはほんとだよ。 やってみた人だけが知ってること。 やってもいないくせにネタ扱いするのやめてくんない? 迷惑。 >>108 CMYKへの対応はどうするんだとか言うツッコミはともかくHTMLとかのカラーコード表 を取り込めばさっくり実装できそうな気もする。 ねぇ、動的型つき言語でのテスト方法教えて。 まずさ、クラスAがあるでしょ? そのクラスAが内部で使ってるクラスBがあるでしょ? クラスBの単体テストは簡単だよね。 クラスAの単体テストをする時、クラスBの代わりにモックを使うよね? つまり、クラスA+偽クラスBでテストをしているわけさ。 この時、クラスBの仕様が変わるとするよね? でも偽クラスBはクラスBのモックというだけで、クラスBとは無関係だよね? 動的型付き言語の場合。 クラスBの仕様が変わってるのに、クラスAはテストに通ってしまう。 こういう場合どうするの? 静的型付け言語ならコンパイルエラーで見つけられるけどさ。 クラスBの要件についてのテストを書いておけば テスト通らなくなるだろ >>110 メソッド sum の実装はコンテナ(コレクション)クラスに属してて、 {1. 2. 3} sum でも同じメソッドをコールし、演算可能ところがミソかな。 Haskell や Scalaの型クラスとかだと可能なのだろうか? >>112 そりゃクラスBの要件のテストを書いておけば、 そのテストは通らなくなるよ。 でも今の問題は、クラスAのテストなんだよね。 クラスBを修正してもクラスBのモックは変わらない。 クラスBのモックを修正することを忘れれば クラスAはテストに通ってしまう。 >>114 >そのテストは通らなくなるよ。 >でも今の問題は、クラスAのテストなんだよね。 要件のテスト通らないって事は変更できないってことだ まさかテストを書き換えるなんて馬鹿なことはしないよな? 1、テスト志向を徹底するためには、まずデバッガを捨て去らねばならない つまりダックタイピングの限界ってことだね。 本物とモックで同じインターフェースを使っていないから インターフェースが変わっても気づかない。 >>116 いやさ、変更するのはクラスBだよ? クラスAと(変更前の)クラスBのモックは 変更する必要ないじゃん? テストを書き換えるなんて馬鹿なことはしないんだからさ。 >>119 納期が迫っているときは、その馬鹿でも しないようなことをしてしまうんだよ。 人間はミスをするという前提にたとうぜ? Bの要件を満たさないBを作る事がダメだと言ってるんだが 伝わってるか? >>120 なら問題ないだろ 変更しても要件のテストに通らなければそれはクラスBではない >>122 クラスBとクラスBのモックは 別のものだってわかってる? 今はクラスBの話はしてないの。 クラスAの単体テストの話。 クラスAから使うのはクラスBのモックであり クラスBはでてこない。 >>124 クラスBのモックは当然クラスBの要件を満たしているんだろ? 何の問題があるんだよ クラスAのテストは通る クラスBのテストも通る。 だけど、組み合わせた場合 動かないってことがあるわけだよね。 組み合わせた時インターフェースが 一致していないことを どうやって知ればいいの? >>125 え? まさか、 クラスBのモックを作ったら、 クラスBのモックもテスト書くの? いや多分逆だな。 クラスBのテストを書いて、 そのテストを通るようにクラスBのモックを 作るんだね? クラスBがないからクラスBのモックを書くのに、 クラスAのテストをするために、クラスBのテストを書くんだ。 で、テストを通るようにクラスBのモックを実装するんだ。 動的言語ってすごい二度手間・・・ まあ静的型でも変更を検出出来るのはメソッドのシグネチャの変更程度であって振る舞いの 変更はやはりモックを見つけ出して振る舞いを書き換える必要はあるかな。 >>127 >>129 のようにわかってる人がいるから十分だよ。 わからない人は脱落してね。 >>129 その通りなんだけどつまりこういうことでしょ? シグネチャの変更 静的:わかる 動的:分からない 振る舞いの変更 静的:分からない 動的:分からない 明らかにメリットがあるよね。 さらに静的ならコードの参照箇所の追尾もしやすいし。 >>128 そりゃモックオブジェクトだろうが クラスBというインターフェースを満たさないなら契約違反だろ 何言ってんだ? よくテストがあれば大丈夫というが テストがあってもダメな例があるということさ テストに完璧は存在しない。 モアベターなのはなにか?で 考えるべきだ。 そりゃ型注釈がそのテストの代替だろ もったいぶってないで最初からそう言えよ 動的型でも分かるシグニチャの変更と言ったら、 関数/メソッド名、引数の数、キーワード引数のキーワード、くらいかな? テストに完璧は存在しない。 いやあるかも知れないが、それは途方もなく大変なものだ。 テストで重要なのはいかに質を保ったまま テストの量を減らせるか。 その第一歩が静的型なんだ。 erつけりゃいいと思ってやがる。日本人ならJS屋、C屋だろが。 結局動的でテスト志向に徹するのが最良って結論だったな いつもこの結論なのに何度も議論する意味あるのか? 無限ループに陥ってる可能性があるな スレもテストするべきだな JSはCの2倍速いこともあるが まあ、ここは10倍速いといっておこう >>144 反論してた方がむしろ静的厨というオチだけどな 結局テストのことを考えたら静的のほうがいいべ 動的や面倒でたまらん。 そのくせ効果が少ない。 動的言語だと実装は仕様変更に強いがテストは仕様変更に弱い? というかテストまで仕様変更に寛容だとテストとしての目的を果たさないと言うことか。 モックにテストを書こうと思うのですが どうやって書けばいいのでしょうか? 動的言語が仕様変更に強いというのは 幻想だと思うよ。 >>151 オプショナルな型付けで場面に応じて静的型検証を強制できる言語が最強ということだな。 なんだGroovyじゃないか。 >>152 モックを使ったテストの意味を理解してないなら依存性バリバリでも 愚直にテストコード書いた方がまし 使い方という意味ならいくらでもドキュメント出てくるでしょう テスト志向の徹底 これがすべて まずデバッガを排除するべし デバッガを見つけたら廃棄 それがソフトであってもハードであっても人間であっても デバッガと名のつくものはすべて廃棄 そしてGDBに戦いを挑む>>156 だった。 最終話 デバッガには勝てなかったよ >>152 モックに対してテストを書くと、 モックのテストと 実物のテストの二つに分かれてしまう。 それは避けないといけない。 だからテストコードにはクラス名を渡せるように作る。 モックを使ったテストでは テスト対象コードとそのテストの他に モックのテストが必要になる。 >>159 当然廃棄 透明ゴミ袋でお願いします 生ごみだから テストはバグを見つけるためのものであり デバッガとは見つけたバグを修正するもの。 この違いがわかっているのなら、 テストはデバッガの代わりにならないというのもわかるはず。 やべえ 眠くならない まじやべえ 月曜日寝ないと一週間眠れないパターンに入る これはやべえ 俺は深夜メンテナンスがあるから 逆に起きてないといかんのだよ。 寝れないなら俺に付き合えw 動的言語勢としてもJSerは隔離したほうがいいと思った やつら純粋に頭が悪すぎる >>144 > 結局動的でテスト志向に徹するのが最良 どうせテストを書くのなら、最初からコードに一部埋め込んでおけば漏れもないし確実だろうが。 動的言語信者の言い分をつきつめると、結局静的言語に戻ってくる やつら計算機科学の成果とかまるっきり無視してるからなw ま、確かにこれからは動的言語だって時代はあったよな。このグラフの2005年くらいまでか? http://www.tiobe.com/content/paperinfo/tpci/images/history_paradigm_type%20system.png 特に阿呆なJSerども、俺らイケてるって調子に乗ってな。 でも今は最早そんなトレンドではないのでは明らか。揺り戻しが発生してるでしょ。 失敗したんだよお前ら。 型は自転車でいえば補助輪のようなもの プログラム初心者は型がないとプログラムを書けない 一度、型なしでプログラムを書けるようになったら もう型なんて必要ない >>169 あほ。 型付け制限はどうみても人間以外の機械側の都合。 171だが。 >>1 をいま読んだが。 静的型付け言語でなくともオプション指定で、代入で型が変更された時に警告やエラーを出すようにしたら発見可能だろ。 これは、静的型付け言語かどうかとは関係ないな。 型はヘルメットとも言い換えられる 自称上級者が「鬱陶しいから」という理由で装備せずに重大な事故を引き起こす >>172 int a = 1; a = foo(); // fooの戻り値は文字列 この場合に警告出してくれる動的型言語を紹介してください 動的がーとか言ってるやつとブレーキのない俺かっけーと言ってるピスト野郎とかぶるんだが気のせい? 入学したら補助輪を外すのは世界の常識。 いつまでも補助輪つけてたらみっともないですよ? ゆうくんも今日からお兄ちゃんなんだから補助輪外さないとね! >>172 > 静的型付け言語でなくともオプション指定で、代入で型が変更された時に警告やエラーを出すようにしたら発見可能だろ。 エラーだらけになるだろ、バカすぎ。 デバッガを使う無能が一向に減らないのは静的のせいだったのか。 なるほどなるほど。 なんでデバッガを嫌うの? コボラーと同じ臭がするね。 インタプリタしか使ったことがなければデバッガが無意味に思えても仕方ない >>181 なるほど! デバッガを嫌っている人は デバッガを勘違いしているということがわかった。 デバッガはその名の通り、バグを修正するもの。 テストで見つかったバグ。そのバグを直すまでに使う道具だ。 デバッガで応急処置をするとかよくわからんわw 応急処置をするにしても、テキストエディタでコード書くことで 応急処置するんだろ。デバッガで応急処置?どうやって?w ごく小規模なプログラム、個人での開発、保守不要の作り捨てのプログラムの場合は動的な方がよい ネットワーク分散処理、アジャイル、ハイパフォーマンスの場合は動的のほうが良い。 初心者の学習用途は静的のほうが簡単。 >>187 のレスには突込みどころがいくつもあるけど突っ込みません 突っ込みどころが多すぎて突っ込ませない手法は教祖がよくつかう手法。 >>187 JSはCの10倍速くて初心者にも優しいよ さすがに10倍はない。 大きすぎてネタとばれるレベルw 【動的言語の薦め】 Perlが最初MBAの学生によって作られたことはよく知られています。 欧米の金融工学の教科書には問題をPerlで検証しなさいと良く書かれています。 実際、マンハッタンエリートの机には必ずPerlのパッケージが置いてあります。 金融、経営、経済といった分野ではPerlが必要不可欠な個人ツールとなっているのです。 最適化分析ツールとして容易でありながら絶大な威力を持つソルバー、 計算結果を視覚化するグラフツール、これらの操作を簡単に記録して再利用する マクロの記録など必要なものはすべてそろっています。 彼らはマンハッタンのエリートたちはプログラミングの専門家ではありません。 はたして、静的言語でこのようなことが可能だったでしょうか? ひとえに動的言語のパウアーによるものだったのです。 Perlの重要な機能であるウェブクエリも忘れてはいけません。 これは、定期的に更新されるウェブページの表から動的に情報を取得する 容易な方法です。 実際にウェブページを閲覧しながら必要な表を選択するだけで情報を 取り込めるのです。 Perlのシートを開くたびに更新された情報を取得することも可能です。 もちろん、取得した情報の分析や資格化はPerlの得意とするところです。 マンハッタンのエリートたちはこういったツールを使いこなし、経営に 役立てているのです。 繰り返しになりますが、静的言語でこのようなことが実現したでしょうか? 日本でも投資顧問会社が「弊社では20世紀より伝わる信頼と実績のPerl プログラムによってお客様の利益を保証します」ってやってるね。 そういう特定分野で使われている言語はその分野の実績のあるソフトウェアスタックが揃っていて ユーザが多くノウハウも蓄積しているから使われているのであって動的静的は案外関係ないと思う。 今仕事でやってるデータインテンシィブな分散処理の分野ではJava強いけど別にこれを「動的言語 でこのようなことが実現したでしょうか? 」とか言う気にはあまりならん。 基本的にはHadoopやLuceneがJavaで書かれているから、その上に乗っかるシステムも素直にJavaで 書かれているという事情が大きい。でも現実問題としてこの点は言語が動的静的云々の差などより よほど大きいわけで。 「小規模なプログラム、個人での開発、保守不要の作り捨てのプログラムの場合は動的な方がよい」 ということでは無くて、単に効率考えずに言語第一で選択できる場面なんてその程度しか無いだけ。 >>196 金融商品取引法は、損失負担の約束や利益保証を禁止しており、これらを伴う勧誘も当然に禁止しています。 >>176 君、よく周囲の人達から「きみ、頭悪いね」と言われてるだろ。 >>196 その利益保証しているという投資顧問の社名を教えてくれ >>199 具体的な反論なくただ堕とすだけの奴は無能だってじっちゃが言ってた(´・ω・`) >>205 ウンウン、そういう風に具体的なこと言えないで堕とすだけなんだねー。わかります(´・ω・`) >>206 205は204に対する具体的な反論になっていることも理解できないのか なんて可哀想なバカなんだろうw >>204 そんな風に、具体的な反論もできずにじっちゃが言ってたとかほざいている 無能な孫をみて、さぞやじっちゃは悲しんでいるだろうよ どうしてこんなバカな孫ができてしまったのかってねw >>207-208 妄想が止まらないJSerか?涙拭けよwww >>209 あいかわらず妄想の塊だなw お大事に。ww >>203 作り話じゃありません。 ExcelをPerlに変えてみただけです。 >>210 いやいや妄想力の強さではJSerにはかないませんよw 負けを認めた瞬間から君は負け犬になったのです。 一生JSにかなわないのです。 板住民の総意としてJS最強を認めたいと思います チャンピオン JSer には地球代表として銀河系遠征へ旅立っていただく予定です >>215 おまえがJSのアンチだってことは 皆気づいていると思うよ。 いくら言い訳してもね。 >>215 あんちだったん? Cの二倍速いのになんで? 宇宙人からメッセージが一件とどいてます。 (^q^)アウアウアー >>217 2倍速いっていうのはデマだよ。 ごくごく一部の例外的事象を 大げさに言ってるだけ。 デマじゃないよ。 ほんとに速いよ。 やってみたらすぐわかるのになんでやらないの? いや、簡単なサンプル作ったけど 速くならなかった。 速くなるというサンプルを書いてみてくれ。 速くなるという証拠がないんだ。 どうしようもないじゃないか?w JSの良いところは速度だけではありません。 その高度に統合された美しい理論体系が優れているのです。 神のデザインとすら言われています。 早いのは単にcのコードが悪くて、 jsの最適化の方が優れてただけだろ? ブラウザ戦争の産物だな clangみたいに最適化が進めば差はたいしてなくなる JSが美しいとか言うやつの美的感覚ってw それにJSがCより早いって(爆笑)比較コードさらしてね まともなコードで比較したらそんなことあり得ないから 【最も美しい言語 - 01スクリプト言語】 ・0と1、二つの文字だけで書くことができる新しい種類の言語です ・現在の実装はトランスレータです ・コンパイラ、実行環境はお好きなものを選べます 【現在の実装】 ・0と1だけから成り立つ入力文字列より8バイト消費し、それぞれ0のビット 1のビットとして一バイトにおさめます ・選択されたコンパイラや実行環境の入力としてバイトを送ります ・文字列の終端に達していない場合、最初のステップに戻り、それ以外の場合 終了します >>220 そんな素晴らしいものでなんで全てのプラットホームで使えるようになってないのよ。お前ら信者の布教具合がたるんでるんじゃねえの? JavaScriptの関数読んだけど難しすぎてわけがわからん。 誰かこの関数の使い方を教えてくれないか? どういう返り値を期待してどういう引数を渡せばいいのか。 https://github.com/jquery/jquery/blob/1.8-stable/src/core.js#L772 >>232 糞JSerが頑なに正解だと言っていたbulkの再代入が直してあるな まあ当然だよなあ だが静的脳の達人は質問者の追加入力を待ってノロノロ答えを計算するなどということはない >>234 データ型という概念そのものは、高級言語の登場に伴って自然発生的に生まれた たとえば Fortran には整数型/実数型といった単純型や配列という複合型がある また PL/I ではレコードやポインタといったデータ型が追加され、 Pascal でデータ型の体系が整理された後、モジュールや抽象データ型を経て 現在のオブジェクト指向が主流な現在に到る したがって、型システムの起源として言語を特定する事に意味は無い この自然発生的な型システムに遅れて、形式的な型システムが誕生した そしてこれが最初に実装された言語が、ある定理証明器の記述言語として設計された ML になる MLはその後、汎用的なプログラミング言語として開発が世界中で活発化し、 Standard ML(SML) と Objective-Caml(OCaml) に分かれて現在に到る また ML は純粋関数型言語である Miranda にも強い影響与え、その後継が現在の Haskell 言い換えると、形式的な型システムの起源は ML と言える ML については、Wikipedia にも簡単な解説があるので、そちらも参照のこと でもさ、やっぱりさ、Java書いた後、PHPでコード書くと この糞言語って思わない?? 少なくともこの比較だったらやっぱりJavaの方が色々楽だよね? よく使うので言うとMapあるし、型エラー、メソッド有る無しのエラー、 変数定義のエラーなどなどEclipseの恩恵含めていいとこあるし テストもクラス内の特定メソッド指定して実行できるし、 カバレッジ出るのも早いし、メトリクス測定も早いし PHPでも出来るもの、代用品はもちろんあるけど面倒いし遅いし 曖昧な関数多いし PHPでやるメリットってお遊びアプリ作る程度に 留めないと無いような気もしてくる JavsScriptで関連クラスやユーティリティ群を束ねたモジュールを書く必要があるので 昨今はどういう体裁で書くのがよいのか調べるも、AMDとかCommonJSとか色々書き方の 流儀があるみたいで唖然とした。ベストな書き方はいったい何なの。 ベストな書き方は、自分の作ったライブラリ部分と AMDなどの書き方をするべき所を明確に分離することだ。 そうすれば、簡単なプロキシコードでどのようなものにも対応できる。 モジュール一つ書くのに色々書き方がある上に要プロキシコードとか生産性以前の問題。 きっとその「簡単なプロキシコードでどのようなものにも対応できる」自分の作った ライブラリ部分の書き方も色々あるんでしょ。 単純にメンテナンス性が悪くなる。 >>247 プロキシコードでどんな用も対応できるというのは、 結局のところ、特定の書き方に依存しないってことだ。 特定の書き方に依存させるなというだけの話。 特定の書き方を考慮せずに普通に書けばいい。 だからメンテナンス性は高くなる。 あの、馬鹿にするのやめてもらえますか? C言語はちゃんと速度出ますよ JSが速すぎるだけなんです >>257 遅くねえよ ちょっと個々の設定ファイルの解析と適用に時間かかったり アクセス元のホストを逆引きしたり CGIを丁寧に毎回forkしたりしてるだけだよ JSerがそこらじゅうに転移してるな。まるでヘルペスウイルスだ。 JavaScriptは用途が広がる一方で仕様拡張が追いついていない印象だな。 モジュールのインポート云々が好例。JSerは手作りできるから言語仕様としては不要と 強弁するけど、普通の開発者は単に当初の想定外の用途故の機能不足と解釈するよな。 >>1 "人間がやっていたことを、コンピュータにやらせる。" 人間がやらずに済んでいたことをわざわざコンビュータにやらせる。 >>266 ES6でインポート関連機能がサポートされるかよく知らないのだが、IE 含めて普通に その機能を使えるようになるのっていつ頃? 実行環境として普通に関係あるでしょ。 Androidの分断化問題と一緒。いくら規格が進んだところでランタイムの更新がある程度 進まないとプロダクションに投入できない。 >>269-270 なんで商用が前提になってんの? つまり商用の人はお断りですよと。 商用だろうが非営利だろうが趣味だろうが、ブラウザ上でいろいろな人に使ってもらうので あればブラウザの対応見込みは気にすると思うけど。 >>272 なんでWebアプリ前提なの? >>273 「商用では互換性が重要」って知らんがな。 「Javaで互換性重要だから7, 8の機能使いません」 ↑ 知らんがな これと同じ >>274 >なんでWebアプリ前提なの? Webアプリを開発したい、する必要があるからだけど? Webアプリ開発はJavaScriptの利用目的の中でも大きな分野だと思うけど、違うの? JavaScriptは手段であって目的では無いのだが。 いくら新しい規格が出たところで目的の用途に使えなければ意味ないよ。 「PerlはCGIで使うものだ」ってのと同じ臭いがする CGIをつくることを目的にしている人とっては使いたい機能がPerlにあったところで CGIで使えなければ意味が無いだろうね。 ・・・で使うものだ、という話じゃないよ。 ・・・をしたいのだが、どうよ、という話。目的が主。言語は従。 クライアントサイドのUI開発にES6を使うとして、どうよ。いつになったら使えるの? ていうか、ブラウザで動くという最大のメリットを除けば JSなんて他言語に対して何のアドバンテージも無い >>278 スレタイ読めますか? ブラウザで動くという以外の部分で静的型付け言語を上回ってるという話ですが 使う人の妄想力でしょ。 JSは世界一だ。それを使う俺も世界一だって感じ? >>1 「コンピュータは間違わない」と言ったのはコンピュータではない なぜ、コンピュータが言ってないことを人間が言うのか? 人間が言った方が早いからでしょ 本当は人間の方が効率が良いって知ってるんだろ 「神の見えざる手は間違わない」と言ったのは神ではない。 神が言ってないことを、人間が言う。 >>282 みたいな意味不明な出力は 残念ながら静的型言語をもってしても除去することはできない 意味不明って偉そうに言う事じゃないでしょ なんで意味分かってない奴が意味分かってる奴より偉そうなの?反知性主義なの? >>282 むしろコンピューターがいったことってなんだよ このように自分の誤りに対して寛容すぎる人々によって好まれるのが動的言語です >>282 コンピュータは間違わないと人間言った。 うん、そう人間が言ったんだよ。 コンピュータは間違わないで人間よりも早く 同じことを何度もやれる。 と人間が言ったけど これ間違いじゃないけど、君、反論してないよね? >>284 むしろ「神の見えざる手は間違わない」と 神が言ったなんて誰が言ったんだ? お前馬鹿じゃないのか? アダム・スミスが「神の見えざる手」といったのは明らかなのにw それを聞いて、神が言ったと勘違いするマヌケw 静的型付け関数型言語を使ってみたけど 型検査が強力すぎて馴染めなかった 小ミスで全体が死にしかもどこでコケてるかわからない状態 とエスパーしてみる あぁ、型がないとそうだろうね 実行するまで問題に気づかない。 >>298 型検査が強力でも動的言語のインタプリタを実装できるしコンパイルできる コンパイラは文句を言わない でも動的言語はだめだと人間が言う コンパイラが文句を言わなくても人間に認められないとだめだって人間が言うんだよ 誰もコンピュータを信じてない コンピュータは間違えないなんて言うけど、誰も信じてないんだよ >>302 お前の妄想垂れ流すのやめたら? 意味ないしキモいだけだよ。 >>298 型とか細けぇ事はいいから結果が早く欲しい時くらいかな 静的言語のメリットとして入力補完などIDEの支援が受けやすいとは昔こそよく言われた けれども今時のIDEだとその点のメリットは動的言語を扱う場合でも大差ないと思う。 今は動的言語であってもIDEが積極的にコード解析して、レキシカルに特定できる範囲で 正しいプロパティを色分けしたり型コメントを勝手につけたりする。 逆にこういうコード解析が出来ず色分け等されなかった部分は実際大抵ミスっている。 そうしたミスを直して、全体がコード解析されて色とりどりにデコレーションされた 書き上がったコードを見て一人満足するけれども、逆にあれ、こんなふうにコードの 大半が静的に解析してある程度検証できてしまうような場合、動的言語の出番って 何だろうね? とも思ってしまう。適当に型をつければそのまま静的言語でも動くような。 実際書かれているコードの多くは静的でも動的でもあまり大差ないのでは無いのか。 違いは言語の記法や機能、あとは関数型と手続き型というパラダイムの違いであって、 動的静的といった型付けの違いは案外些末なことでごく特定の場面でしか効いてこない 印象。 > けれども今時のIDEだとその点のメリットは動的言語を扱う場合でも大差ないと思う。 いや、思うじゃなくて、実際に使ってみろって。 動的言語では、その仕組み的に不可能なんだよ。 実行するまで(補完するための情報が)わからない言語で どうやっって補完するっていうんだ? 分からない部分も在るが、分かる部分もある で、意外と分かる部分が多い 分かる部分=近くのコード わからない部分=遠くのコード これが逆ならいいんだけどねぇ。 どれだけ影響範囲が広いか調べる必要があるのに その遠くのコードがわからないんじゃ意味ないよ。 引数にどんな型が渡されるかわからない言語とか怖くて使えない C#やJavaで言えば常にObject型の引数が来てリフレクションでメソッド呼び出すようなもんでしょ ぜんぜん違うよ! (じゃあ何が違うのだろう・・・) ぜ、ぜんぜん違うんだよ! (あぁ、答えられないのね) 型が推論できるかとコードの近さとは関係ないよ 静的型付関数型言語で、遠い場所のコードは推論できないとか聞いた事ある? 遠い場所のコードの型が推論できないのは 動的型付け言語の話でしょ。 静的なら当然遠くの場所でも型わかるさ。 動的な機能を使えば遠くても推論できない 使わなければ遠くても推論できる 結論:近さは関係ない > 動的な機能を使えば遠くても推論できない 動的な機能を使えば近くても推論できない、の間違い > 静的型付関数型言語で、遠い場所のコードは推論できないとか聞いた事ある? 遠い場所が発生しないように、クラスのパブリックメソッドには きちんと型を書かないといけないって話なら聞いたことあるな。 推論できるのは近くの場所だけだからね。 A<B> x = y.foo(z.bar()); 型情報で候補を絞り込むのは foo と bar だけ A と B と y と z は型情報を使わずに補完 x は補完できない >>317 それってSMLとかOCamlとかHaskellにも当てはまるの? 型推論って、静的型付け言語ならでわの 機能だって知ってるかな? 型がない言語では、推論したくても推論できない。 推論できるのは、そもそも型が存在するから。 >>319 > それってSMLとかOCamlとかHaskellにも当てはまるの? 当てはまるんじゃね? その言語の汎用ライブラリでも調べればわかるでしょ? 使い方を限定することが出来ないライブラリだと そのシグネチャに型を書いていないと当然推論さえも出来ない。 今書いた関数をその場で自分で呼び出すなら型は無くても良いよ。 ワンライナーとか掻き捨ての小さなスクリプトとかは断然動的型の方が書きやすい。 ただ他の人も使うものとか、あと今日はともかく明日の自分は他人と思っておいた 方が無難だから、今後再利用する可能性のあるものに関してははドキュメントを 書くし、それには引数の期待する型の情報も含まれるよね。となると、 /** * @param str {String} an input * @returns {Number} a nice output **/ function func(str){ ... } と /** * @param str an input * @returns a nice output **/ int func(String str){ ... } にどれほどの違いがあるのかと。 逆にどうしても型情報を「つけたくない」(つけるのが面倒、では無く)場面というのは 案外限られるし、そういう場面では静的型でもJavaのObject渡しでリフレクションとか Cで生ポインタ渡しでキャストとかそれなりに回避策もある。 だから結論としては静的には動的にも書けるGroovyは節操なくて便利だと。 >>322 いや、動的型付けは小さいものじゃないと 使いものにならないという言い方をしてくれよ。 小さいもので作りやすいとか言われても興味ないんだよね。 小さいものなら適当でも全体見渡せるからいいよ。 でも大きい物はどうなのさ? こっちのほうが何倍も大変だ。 >>323 そうか で、説明はないんだね。 (やっぱりな苦笑) 動的型で、コードの場所が遠いという理由で推論できない例をあげてみてよ >>326 JavaScriptでいえば、 function foo(a) { aが持ってるメソッドは? 型推論できない。 } >>325 OCamlはシグニチャ付けてコンパイル通るコードは、 シグニチャ無しでも型推論でコンパイル通るって話だよ >>328 それはシグニチャなしでも通るだけ。 型推論はしていない。型を捨ててるだけ。 >>327 そのfooを呼び出してる側のコードも読み込んで 解析するのが普通なので、fooを使ってる側のコードも必要 >>329 知らないのに絡むヤツだなぁ OCamlが型捨てる訳ないだろ >>330 > fooを使ってる側のコードも必要 ほらな。遠くになったからわからなくなった。 近くじゃないとわからないから その情報をほしいわけだろ。 >>324 いや、だからちゃんと結論を読んでくださいって。 結局静的動的関係なく単にGroovy節操なくて良いよと言いたいだけなんでw という冗談はともかく、結局動的でもメンテナンス可能な大きなものを書くには 型とか含めてゴリゴリドキュメントを書くし、トータルな手間としては結局静的 言語と大差なくなってくる。小さなもの相手には出来た手抜きは通用しない。 ただ動的言語でもきっちり手間をかけて書かれた大きなプロダクトはいくらでも あると思う。 >>330 > そのfooを呼び出してる側のコードも読み込んで > 解析するのが普通なので、fooを使ってる側のコードも必要 fooを使っているかどうかは、 静的型付け言語ならコンピュータが判断してくれるよ? 動的型付けではできないよね。 >>332 > ほらな。遠くになったからわからなくなった。 なんで遠くにあるコードも解析に使うって話からこの結論になるの? >>334 動的型だと、出来る場合と出来ない場合がある >>327 Javascriptって、次のような関数がある場合でも function bar() { foo(1); } fooの中でaのメソッドを補完できないほど しょぼいIDEしか無いの? >>337 それに加えてfoo("hoge")みたいな呼び出しもあったらどう補完されるの? 遠くにあるコードを解析する言語は、全体が完成するまで解析できない つまり、全体が完成する前に実行できる言語があれば 静的に解析するより早い時期にデバッグできるんだよ 静的な型付けの言語は別に型の推測に遠くのコードを解析する必要なんて無いけど。 そのコードを書いた時点で型が確定しているのだから当然。 >>338 両方が共通に持ってるメソッドだけ補完するか、 どちらか一方が持ってるメソッドを補完するか、 好きな方を設定で選ぶ >>341 JSでそういう上等な補完を行ってくれるIDEってあれば知りたい。 動的言語のIDEの補完は影響範囲がローカルでレキシカルに型を特定できたり ドキュメントに型情報がある場合はその型を、そうでない場合は諦めモードで 基本クラスやDOMやjQuery等のメジャーなAPIをずらずら並べるのが多い気がする。 >>339 Haskell等でも、未完成の関数をundefinedにしておいて 未完成の状態で実行したりするらしいよ JSとLispの差にくらべてJavaとHaskellの差が大きすぎる 静的型付け言語は多様性が100倍 JavaとHaskellの差は手続き型か純粋関数型かの違いだと思うけど。 動的静的、関係なくない? >>343 するかボケ 評価の順序試す時ぐらいだろ >>322 みたいにドキュメントを用意して引数の型を丁寧に書くなら型を動的にするメリットがない じゃあドキュメントを用意しない場合はどうか。 function func(attr){ ... } int func(File.Attributes attr){ ... } こんな関数があったら前者は怖くて使えないよね。 何を渡していいのかわからない。何が渡されるのかわからない。 後者なら型情報が全てを物語ってる 動的型付け言語を好む動的人間と静的型付け言語を好む静的人間とが居るかもしれない。 >>349 実装見ようとしたのですがファイル名末尾がmin.jsでファイルの中身をのぞいても 全部一行にかたまっていて何が何だがよくわかりません。 >>352 まあでもどちらも比較的変種で普通種は動的言語も静的言語も両方使うと思う。 >>348 全くそのとおりだな。 型というのは、コンパイラと人間の両方が 理解して処理可能なコメントだと思えばいい。 短いコードならコメントなしでもいいが 規模が大きくなるにつれて、コメントがあるといいよ。 しかもそれが、早くて正確なコンパイラが理解可能なコメントなら 矛盾を指摘してくれたり、コメントをもとに適切な アドバイスをしてくれるんだよ。 型に関してもコメントを残すなら書く手間は動的も静的もそう変わらんということ。 別なんじゃない。 静的型付け言語の型情報にはコメント的な御利益もあるというだけであって。 >>356 コメントがなくてもわかるような コードを書けってきかない? 型を含めたコード全てが コメントのように分かりやすくあるべきなんだよ。 コードに必要な情報を埋め込められる言語 ようするに型もその情報の一つなわけだけど、 そういう言語だとコードが分かりやすくなるんだよ。 (コンパイラが理解できない)コメントは コードに情報を埋められない言語の逃げでしかない。 コメントにはなぜそうしたのか?という理由を書く コードにはそうなっているという事実を書く。 型は、そうした理由ではなく事実。 この変数・引数には○○型を採用しているという事実。 事実だからコードで書く。 ○○型を採用した理由を書く必要があるならば それをコメントに書く。 他の動的言語はともかくJSerはツンデレだからね。 変数スコープがウンコと言われてそんなことないもん! と強がる一方でletを導入したり 辞書型はオブジェクトリテラルで十分なんだからねっ! と言いながらMapを準備したり functionぐらい面倒くさがらずに書きなさいよ! となじる一方で密かにアロー記号用意したり 型情報なんか必要だなんて思っていないんだからっ! と表向きは突き放しつつ陰ではいそいそ JSDocに型情報を書いてみたりガードが使えるようになる未来を夢想してこっそりデれたり。 で、そのことを指摘しても「ガードは・・・そういうのとは違うのよっ」と否定してみたり。 JS利用者が導入したわけじゃないしね。 必要ないのに勝手に誰かが導入しただけだしね。 >>360 たいていのアルゴリズムはコメントどころか書籍程度の説明が必要。 書籍一冊で理解させるのが困難な場合も多く、直接的な指導が必要な場合も多い。 コメントを書かなくても理解させられるコードというのは、単に手続きを 羅列したものであり、そのような手続きの羅列を強要させられることこそが 糞言語のあかしなのである。 コメントを書く必要がないのではなく、コメントを書かなくていいような 手続きの羅列を書かされている。 こういった認識を持てないのは、糞言語に調教された証左である。 つまり、君は我々人類と対等に話せる場所に既に居ない。 機械に調教された悲しき奴隷、それが今の君の姿なのである。 コメントを書こう、メモを残そう、テストを完璧に行おう、デバッガを捨てよう。 >>364 'コメントを書かなくても理解させられるコードというのは、単に手続きを 羅列したものであり、そのような手続きの羅列を強要させられることこそが 糞言語のあかしなのである。' という宣言が論理式に変換されればよいというだけの話ではないか。 >>364 の言っていることは。 > 'コメントを書かなくても理解させられるコードというのは、単に手続きを > 羅列したものであり 間違い。 間違いもそうだが、そもそもレスが論理的におかしい 自分で「コメントを書かずとも理解させるコード」と、 コメントが理解の助けになる前提で語ってる時点で 最良はコメントのように書いてあるコードしかないだろうに そもそも、型情報は コメントとして書くものではなく コードで書くものだという話。 というか>>349 実装見たら良いとか>>360 コメントいらずのコードとか謎。 使う人が知る必要があるのは仕様。ドキュメントやコメントに書いてあるのは そういうこと。 コードに書いてあるのは実装。読んで理解すれば時には役にはたつがはじめから 使う人間に実装の中身の理解を求めるのは普通に変。 自動車運転する人にオットーサイクルの理解を求めるの? >>372 エンジンを使って何かをつくろうとしてる人なら 理解していたほうが良いだろうね >>373 自動車運転する人の話を聞いているんだけど。 GoogleやFBが提供するAPIを使って何かを作る人はそのバックエンド処理の仕組みを知る 必要があるの? gzipを使う人はgzipのコードを読んでからで無いとダメ? HTMLにマイクロフォーマットを埋め込む人はRDF Semanticsの仕様を読んで理解してから? String.indexOfを使う人はそれがどのアルゴリズムで書かれているか知ってからでないと 使っちゃダメかな? 理解「した方がよい」のと使うのにまずコード読んで中身の理解を求めるのは全く別。 >>372 お前は自分でコード書かないのかよw 関数の中身を書く人、修正する人の話だろ。 プログラム板なんだから。 >>375 コードは書くし他の人が読んで理解しやすいように書くけどコードを提供する側としては 自分が書いたコードを使うならまず読んで理解しろとは全く考えないね。 自分で書いたコードをいろいろな人に使ってもらった経験って、ある? 型を宣言してもコメントはなくならないし、テストもなくならない グローバルスタンダードになるつもりは最初からない ガラパゴスの多様性を擁護する側の勢力がどんな戦い方をするのかという実験なんだよ >>374 駄目と入ってないが、どれも知っていたほうが理解が早い 特にWen関連APIなんてそのベンダーの仕様知ってると相当に早い それにマイクロコードなんてSEO考えてるならまず仕様から入るし gzやindexOfの実装にしたって パラメタ指定が速度に関わる系なら知ってて損はない 概要すらいらないなんて考えはさすがに同意しかねるよ >>379 知っていた方が理解が早い で、実装の詳細を知るために要する時間はドキュメントのコメントを読むのに要する時間よりも遥かに長い # だから経験者の即戦力が求められるってことでもあるんだけどね >>376 > 自分が書いたコードを使うならまず読んで理解しろとは全く考えないね。 やっぱりお前アホだ。 誰も「コードを使うならまず読んで理解しろ」なんて一言も言ってない。 お前日本語読めないだろ。 あれでしょ?なんだかんだ言って 関数を自分で作ったことがない人なんでしょ。 使うだけの人。 プログラマなら普通、自分が書いているコードの 中身の話をするもんだけどねぇ コメントやドキュメントに書いてある事だけ知っていれば良かったらどんなに楽だろうか >>383 コメントやドキュメントが整備されていれば実装まで調べる必要ないけど >>348 それ型が解るだけで結局何する関数なのかさっぱり解らないと思うんだが その型情報で何を想像するかは人よって見解が分かれそう ドキュメントに具体例がないと苦労する 具体例とは、仕様書でもソースコードでもない ここでD使いが参上 「Dならunittestのコードを直に埋め込めるし ドキュメントに使用例として吐出されるよ」 シュタッミ >>384 なんでまだ、使う人の話してるの? 使うコードを書だろ? そのコードの話をしてるんだが。 コメント見なくてもわかりやく書けよ。 誰もコメントなくなと入ってねーよ。 >>382 誰かと一緒に作業したり他の人にコードを提供するプログラマなら中身同様にドキュメント 等を含めたコードの外面をとことん気にすると思うけれども、違うの? ドキュメンテーションをちゃんと行うなら静的も動的も記述量はたいしたことが無いんじゃ ないのという例を挙げたのは自分だけど、そこからドキュメントを用意しない場合という話 が出てきて実装読めば良いとかコメント無くてもわかるコードという話になったので「謎」 と言ったわけ。 いやそこ頑張るとこじゃ無いというか、頑張っても良いけどまずメソッドのシグネチャや 付随するコメントが十分に説明的になってからでないと単に効率悪いだけだから。 function func(attr)もint func(File.Attributes attr)も中身の書き方云々する前にまず コメントから書こうよw メソッド名も書き直す。 >>389 >なんでまだ、使う人の話してるの? 使われるコードを書く人の話をしています。 話を戻そうね 360 名前:デフォルトの名無しさん[sage] 投稿日:2013/12/01(日) 02:19:35.15 >>356 コメントがなくてもわかるような コードを書けってきかない? 型を含めたコード全てが コメントのように分かりやすくあるべきなんだよ。 コードに必要な情報を埋め込められる言語 ようするに型もその情報の一つなわけだけど、 そういう言語だとコードが分かりやすくなるんだよ。 (コンパイラが理解できない)コメントは コードに情報を埋められない言語の逃げでしかない。 使うだけにしても実装を追うにしてもコメントのあるなしで大分違うからまずコメント書けってのには同意だけど コメントが書いてあれば実装を追わなくても理解できる、とか言われると「はぁ?」って感じ 経験上、コメントがないとわかりづらい部分とコメントを書きづらい部分というのがかぶっているわけで 同じ手間でコードでかけることならば、コードで書いていれば良い。 引数の型とかそういうのはコードで書くべき情報。 服着てる現代人と裸の原始人とどっちが優秀かって問題だと思う。 原始人は体が鍛えられてて個体としては優秀だが、狩猟ができず食える草が生えてない東京で絶望することだろう。 >>393 自分が好都合なリビジョンに話をロールバックするなw エラー発生時点まできっちり巻き戻そう。 >>348 >function func(attr){ ... } >int func(File.Attributes attr){ ... } >こんな関数があったら前者は怖くて使えないよね。 後者だって怖くて使えね〜w 要するに、そういうことだよ。型が合った方が良いという例としてはイマイチ無茶。 仮に実装の中身にしても同様。 int i = 0; var index = 0 // 0..(users.length -1) どっちが説明的? int index = 0; // 0..(users.length -1) と大差ある? 「コメント無くてもわかるようなコード」というのは型情報だけでは無くメソッド 名や変数名にも配慮して初めて書けるもの。型情報なんてその中の一つに過ぎない。 で、その程度は少しのコメントで補えるもの。この点で動的型が不利とは思わない。 さらに言えば「コメント無くてもわかるようなコード」の書きやすさではJava等 よりもPythonなどを押すかな。これは静的型動的型の違いと言うよりもコード中の ノイズの多さの違い。 >>394 コメントが書いてあれば実装を追わなくても理解できる、とまではさすがに求めない。 まずは実装を追わなくても使えるべきで、そのためにコメントやドキュメントは必要と 言っているだけ。 ドキュメントを書いたのにドキュメントだけでは使い方がわからなかったとか言われた 場合はそれなりに悔しいw > 後者だって怖くて使えね〜w > 要するに、そういうことだよ。 どういうこと?(笑) ほらね、理由を全く言ってない。 これなんだよ。卑怯な人はね。 > var index = 0 // 0..(users.length -1) > > どっちが説明的? > > int index = 0; // 0..(users.length -1) 下じゃねーの? 上に書いてあるint i = 0; がなんのことだかわからんけど、 誤記入だろう? 型がない言語でにはint iなんて物は存在しないからね。 比べるなら > var index = 0; > int index = 0; この二つで比べるべき話だね。 >>398 は変な人だね。 >>348 型がないとコードを読めない初心者さん、おつかれ。 早く補助輪なしで自転車に乗れるようになれたらいいね。 >>401 この二つは明らかに下のほうがわかりやすいね。 上はindexって書いているけど、これが何型かわからない。 もしかしたら本の索引って意味かもしれんし。 その場合は、1.1 (一章一節)なんて数値が入るかもしれない。 後者だと整数であることが明確である。 もっと具体的な型だったら さらに意味がわかりやすいよね。 BookIndex index = 0; >>401 でもHaskellのコードとか、 関数がポイントフリーになっていて引数名すら存在しない、 その関数の引数の型ぐらいしかヒントがない、 なんてことがあるし。 傾向として 静的型プログラマは型に頼って変数名はテキトー、 動的型プログラマは変数名に拘るのが多いんじゃね? >>403 おまえは本を0章から書き始めるのか? RMSみたいな奴だなw > 静的型プログラマは型に頼って変数名はテキトー、 > 動的型プログラマは変数名に拘るのが多いんじゃね? 全然違うし。変数名が適当であるという根拠は何一つ出てない。 静的型プログラマは型も変数名にもこだわってる。 動的型プログラマは変数名に拘るが型は適当。 これが事実だろ。 コメントは基本ドキュメンテーションコメントだけでいいんだよ >>407 ハスケラとか1文字変数平気で使うし、 ポイントフリーで0文字なんてのもザラだし、 それどころか0文字変数名を推奨してるしw Javaのコードだって大抵は変数名はクラス名より短いしw >>406 0というのは、どこも指していないって意味ですよw ほらね。型がないとこういうことになる。 >>407 だな。静的言語のほうが変数名は長くて具体的な傾向がある。 動的言語の場合は、適当に短い名前をつける。 で、これで許されるのは、結局プログラムの規模が小さいから。 プログラムの規模が小さいから、適当な名前でもどうにかなる。 だから大規模になると動的言語は破綻する。 ずっと前から出てる結論じゃないか。 >>404 BookIndex型に整数代入したらエラーになるんじゃないの? というわけで>>407 はウソツキであることが確定w >>411 動的言語ではエラーになりませんよね。 BookIndexを入れるべき所に0を入れても 変数に型がないのでエラーになりません。 困りますよねw >>410 それはお前が今勝手にそういう糞コードにしただけで、 具体的に「index」という変数名で「章番号」を保持していたというコードの実例を出してみろw 型があるとこういう、明らかにエラーになるべき所を しっかり教えてくれるんだよね。 >>400 下の二つのどちらが説明的なのかと (前者は静的型で変数名に無頓着な例。 後者は動的型で説明的な変数名にコメントを付記した例) int i = 0; var index = 0 // 0..(users.length -1) 下の二つでは大差があるのかと説いたわけで。 var index = 0 // 0..(users.length -1) int index = 0; // 0..(users.length -1) 要するに動的型でも適切にコメントを付記すれば十分に説明的になる以上、コメント 禁止なんて非現実的な縛りでも無い限り動的型は理解しやすいコードの書きやすさの 点で不利にはならないということ。 コメントが無いコードを書きたいの? それとも理解しやすいコードを書きたいの? >>413 バカだなあ。例外というものを知らないらしいw ねえ、静的型プログラマって、みんな413みたいなキチガイ人間なの?バカなの?糞バグ製造機なの? >>415 おまえが出した例はあまりにもアホすぎて やはり静的型付言語はプログラミング初心者が使うものなんだな ということをより強く確信しましたww >>417 例外は発生させる分コストがかかるじゃん >>416 お前さ、比較実験の原則しらねーの? 今比べるべきところは型だろ。 ならば型以外の条件は同じにするのが 原則だ。 int i = 0 // 0..(users.length -1) var index = 0 // 0..(users.length -1) どっちが説明的かって? 上に決まってるじゃねーか。 >>419 (動的に発生する)例外は発生させる分コストがかかるじゃん それがどうかしましたか? そもそも無駄にコメント書くやつがアホ 関数の説明ぐらいでいいんだよ >>422 変数全てに、それがどんな型で どんな値が入るかをコメントで書くべきだ。 型がない言語を使っている人が、 そう言ってるのがわかりませんか? >>403 「0」って整数リテラルがかいてあるのに > もしかしたら本の索引って意味かもしれんし。 > その場合は、1.1 (一章一節)なんて数値が入るかもしれない。 なんてキチガイじみたこと言うなんて、 やっぱり静的型プログラマはバカなんだね。 >>424 発想力のないやつだね。 0が書いてあればということは、 じゃあ0が書いていなければどうなるのさ? もしこの値が1だったらどうなる? 0ならわかると言っているならば、 0以外ならわからないとお前は認めてるのも同然なんだよ。 >>423 「型がない」なんて言ってる時点で、型に関する知識が初心者レベルなのが丸わかりw 静的型言語を使っているからバカになったのか、 それともバカだから静的型言語を使っているのか。 どっちにせよ、静的厨はバカw >>425 しかし、具体的に出された例には「0」と書いてあって、 それを章番号かもしれないなんてキチガイ丸出しのバカがおまえ。 >>420 ちゃんと読む。下の二つでは大差があるのかと説いたわけで。 > var index = 0 // 0..(users.length -1) > int index = 0; // 0..(users.length -1) 大差あるの? >>427 へぇ、じゃあ、1って書いてあったら どうすんの? >>416 ローカル変数までコメント付けるなんて条件のほうが非現実的 がんばって全部文章でこと細かな説明つければそりゃどんな言語だって分かりやすくなるわw 普通はそんな手間かかることしないよね ごく一般的なプログラムのコメント濃度だと静的型のほうが説明的になるのは間違いない つまり、コメントを書かないですむということは、その程度の手続きの羅列 ってことなのですよ。 ほとんどのアルゴリズムは本一冊で足りないくらいの説明が必要ですからね。 つまり、馬鹿が講釈たれてる図式なんですよ。 手続きの羅列で満足なら自分の中で満足するべきで、「手続きの羅列以外 認めてはならない」みたいな変な啓蒙しちゃいけないんですよ。 静的型だって型が文脈的に自明なところは型推論で型宣言をすっ飛ばす流れだから似たようなもの。 動的型だってまずは文脈的にわかりにくかったり特に大事な部分からコメントをつける。 つまりですね、JS以外はみんな糞言語ってことです。 動的とか静的なんて関係ないんです。 JSはともかく動的静的関係ないのはそうかな。 どちらでも配慮すれば理解しやすいコードは書けるし手間も大差ない。 手間に差があるとしても型付け以外の要素が大きい気がする。 コメントを書くなと言ってた馬鹿は静的がその点で優れていると 述べてましたよね? >>432 >ほとんどのアルゴリズムは本一冊で足りないくらいの説明が必要ですからね。 完全にアホバカだな。 ほとんどのアルゴリズムは1〜2ページだろ。 >>432 はバカでわからず屋だから本一冊の説明が必要なのかもしれんね。 >>417 例外発生させてそのあとどうするの? バグってるので、アップデートしてね ってか? (w >>436 > コメントを書くなと言ってた 誰の話? お前、脳内で仮想敵作りすぎだ。 ああいったに違いない。 こういったに違いない。 ああいった。 こういった。 ムキーッって 自分でかってに苛ついてるだろ。 馬鹿じゃん? コメントがなくても読みやすいコードを書け ↓こういう話を それはコメント書くなって意味だろ! ↑こういう風に解釈するバカが居るんですよね。 どうせ初心者にありがちな 一行ごとにコメント書くようなやつなんだろ。 変数の定義のたびに、何とかを入れた変数とか 書いてるんだぜ。 自然言語でまともに会話できない醜態をさらしつつ コメントについて議論のような何かをするスレ 誰もコメントを否定してないのに なんか勘違いして一人で熱くなってるんだろw >>433 静的ならIDEが型を解決できるから補完したりマウスのせて型見たりできるし >>437 手続きの羅列をアルゴリズムと呼ぶのは、小学生までです。 普通のソフトウェア開発の場合、 アルゴリズムが全体の8割以上を占める。 ○か×か 手続きの羅列程度のものに コメントが必要な時点で おかしいんだよな。 人間は計算が苦手だったから徹底的に最適化しないと計算できなかったが コンピュータは小学生並みの最適化でも計算できてしまうことが多い 型推論っていうのは、 動的型付けの型なし変数と違う。 一見同じように見えるが、型推論のほうが 高度な機能を有している。 型推論というのは、静的に型を推論するから その型に矛盾が生じた時に実行を待たなくとも検出できるし コード補完も正確に行える。 これは動的型付けに比べて明らかなメリット。 Haskellが <T> を書かなくていいのは書かなくても補完できるからなんだよな 逆に <T> を書かされる言語は、補完できてないから書かされている そんな当たり前のことを今さら説明して何がしたいん? >>452 の間違い訂正 Haskellが <T> を書かなくていいのは書かなくても推論できるからなんだよな 逆に <T> を書かされる言語は、推論できてないから書かされている Haskellが優れているのは分かるんだけど、 仕事で実際に使うというのは現実的には難しい 一方、選びやすいJavaやC#は冗長すぎてゴミなので RubyやPythonの方がマシってことになる 難しいもんだね 型推論とテンプレート(ジェネリック)は別なんじゃ… JavaやC#が冗長といっても 開発時間に影響するほどのもんでもないしな。 100行未満の小さいプログラムでなら 簡単に作れるかもしれないけど、 大規模アプリになると、そんな些細な冗長性は その他の本質なコードによって相対的に見えなくなる。 「コメントを書かなくていいようなコードを書きなさい」 ↑ 手続きの羅列に限定しなさいって意味。 まじマシンの下僕。 スカイネットに寝返った人類の敵。 しかもなんか偉そうに述べてくるのがまじわからん。 >>457 お前、何回同じアルゴリズムを 再発明してるんだ?w 一度書いたアルゴリズムは、もう二度と書かなくていいように ライブラリにしないとダメだよ。 聞いた話だが、 コボラーとか同じマッチング処理(アルゴリズム)を 何回も再発明しているらしい。 普通に考えれば、リスト1とリスト2を 与えれば、結果を出す関数を作ればいいだけなのにね。 型があればコメントを書かなくていいとか言ってなかったっけ? 複雑なものを書くのが俺の仕事だみたいな感じなんだろうね。 それを効率化して簡単に読みやすくかけるようにしたら、 それの仕事を取るなって怒るのだろう。 まあ老害ってやつだね。 >>463 スレに記録残ってるんだから、 そのリンクを示せばいいだけだろ。 見つかんないから、そうやってとぼけてるんだってわかるけどねw ちなみに、お前の質問の答はNOだ。 誰もコメント書かなくていいなんて言っていない。 型情報はコードで書けばいいのだから コメントに型情報を書く必要がないと言ってるだけ。 まさか、これを見て、コメント書かなくていいなんて 思わないよね? きっと、コメントに型情報だけを書いていた人なのだろう。 だから型情報をコメントに書かなくていいと言ったら コメントに書く情報がなくなるじゃないかって思う。 >>458 むしろ型推論はジェネリックの方がデフォルト 型を特定できた場合以外はすべてジェネリック型になる 変数宣言が楽 型推論使えば意味ないか 最近は動的でもIDEで予測変換出てきて便利です 静的の方が進化してる感じはあるけど コメントがなくてもわかるような コードを書けってきかない? コードで説明できないからコメントで説明するんだろうね プログラマとはプロのグラマーだよね? プロと名乗る以上はコードできちんと説明できないといけないね コメントを書いていいのはアマチュアまで 「コメント」の指す意味が交錯してる ドキュメントの関数定義に付与されるドキュメンテーションコメントと、 コード中に必要に応じて書かれるコメント 前者を省くのはプロでも不可能 コメントは核と同程度の危険性を持つ 出来るだけ書かないほうがいい 1年後に自分のコードを見たときわけわからんということが無い程度にはコメント書いとけ。 コメントがなくてもわかるような コードを書けってきかない? つまり、手続きの羅列以外書かないことが重要なのです。 >>460 何をやっているのか関数名として書くだけ。 コメントに似てる方が負けというルールなら 宣言を書くよりテストを書く方が勝つんだろうな コメント無くてもわかるようなコードにコメント付記するのが最強。 コメントがなくてもわかるような コードを書けってきかない? コメント書くのは素人 ドキュメンテーションコメントは書きますし 普通のコメントはたまにしか書かないけど そうか、静的型付言語なんか使っていると 動的型付言語には型がないなんて バカ丸出しのキチガイ発言をしてしまうほど 頭が悪くなってしまうんだな…かわいそうに… コメントを有料化すればコード品質が上がるかもしれんね コメントを書いたら一行当たり1万円の罰金とかね コメントのない保守不能なプログラムができるだけだと思う ネーミングマジックで何とかならないの? 保守不能というとイメージ悪いから、コードダンジョン〜魔界の迷宮III〜 とか名づければかっこよく見えるでしょ。 ネーミングマジックの効果って結構あると思うんだよ。 例えば帰宅して「今日はコードダンジョンやっつけてきたよ」っていうでしょ。 すると「お疲れ様、楽しかった?」ってなるでしょ。 意図せず余裕のある大人を演出できてるコレ。 これが「保守不能と格闘してきた↓」だと、奥さんもかわいそうだよね。 地下牢をかっこいいと思うのは中二マジックでしょ ネガティブな名前がかっこいい 怠惰は美徳だとかいうアイデアは 100倍じゃなくて-1倍にする習慣がないと思いつかない JavaとかC#で馬鹿みたいに長い関数名付けてる事があるけど、 あれなら関数名を短くしてコメント書いた方がマシでしょ 関数名が長かろうが短かろうが公開メンバのコメントはつける >>499 問題はそういうことじゃない そう思う人と思わない人が混在してごちゃごちゃになること 動的言語ではそういう事態が起きやすい 俺は俺のためにコメントつけてるぞ。 幾ら短い綺麗なコード書いたって何処かしらでどうしてこういうコードにしたかっていうのを書いときたいのがある。 コメントじゃなくて別ドキュメントでも構わんけど。 グローバル関数名が長いのはどの言語でも同じ 問題はローカル関数が良いと思う人と思わない人が混在すること 動的言語で50文字超える関数名とか見たことないけどな >>506 InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState これもう静的言語だから長くなるとかそういう問題じゃないだろ これに匹敵する長さの関数名を 標準ライブラリに含む 動的言語ってあるの? コメントがなくてもわかるような コードを書けってきかない? コメント書くのは雑魚 静的型言語はバカ救済言語だから そういうバカな名前をつけるバカが一定数混ざってくる コメントがなくてもわかるようなコードを書けってきかない? コメントはコードに情報を埋められない言語の逃げでしかない。 WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10プロパティ そういや.NETって動的も使えたよね 型チェックが甘くならないように細かく分類すると 型名が長くなる 静的型のために継承したクラスとオブジェクト指向のために継承したクラスが混在する >>520 山田グレネード・エクストラ・マリリンヌ花子三世とかね。 >>520 ドカタの逆は短い名前を好むよね。 Perlなんか、$aとか$bが特殊な用途に使われてるし。 他にも$_とか@_とか。名前なんて適当でいいんだよ。 でも$つけるのめんどくさい その点Pythonは優れてる Perlも結構いいと思うけどね Perlに至っては$_が省略されることすらあるしな もはや変数を書かないという >>512 俺は事故起こさねーよって言って飲酒運転する馬鹿みたいだな 安全厨は酒が危険だと言わず自動車が危険だと言う それは自動車の方がシステマティックだからだ そもそも実用品ではない酒はシステマティックに説明できない 説明できない存在を認めると、人間の才能がシステムを上回る可能性も否定できなくなる >>513 静的言語しか書けないバカは例外なくバカだけど? 俺は事故起こさねーよって言って追突されてあぼんする馬鹿みたいだな >>531 その馬鹿はどうするべきだったのかね ポジティブ思考をやめるべきだったのか 思考はやめなくていいけど宣言するのをやめるべきだったのか そうだな。よく見たら1時までしかレスしてないから今起きたってことはないか。 話は戻るけど 悪名高きコメントの更新漏れは コード(英語)とコメント(日本語)のコンテキスト切替の 負担が大きすぎるせいで見落としが生じるのではないか コメントを英語でかこう 日本人相手だと細かいニュアンスが伝わりにくくなるだけだしコメントの用を成さなくなるだけ Well, we should use Himawari and write both codes and comments in Japanese. Konkansuuhakasanwookonaimasu. >>542 ロックの歌詞は英語であるべきかという論争を思い出す。 残念ながら英語は書けない。 書けるのは英語もどきだけだ。 さて、間違いだらけの英語と 日本語。どっちで書いた方がいい? >>545 英語もどきでいい、コードが補完してくれる、ハングルで書かれた日には途方にくれる >>546 その理屈で言うと、間違ってる日本語でもいいってことになるよ 英語もどきを翻訳して正しく訳せることはない。 一体誰が読めるコメントなのだろうか。 自分も同じ間違いをしたことがあれば読める 間違ったことがない奴は何も読めない 英語でコミュニケーションできない奴にプログラマの資格なし。 音楽でも資格のない者が演奏することは禁止されてるっぽいからね そういう風潮なんだな 動的型言語でプログラムを書く資格のないものが 仕方なく静的型言語を使う Javaのような静的言語に比べてJSやPHPのような動的言語は習得コストが高い。 しかし、習得後の生産性は動的言語のほうがはるかに高い。 また製品の速度や品質も非常に高い。 つまり、一般的に動的言語を使うべき。 しかし頭が悪い人は習得が難しいので静的言語で我慢するしかない。 だから技術的には合法だって コンパイラのお墨付きをもらうのは簡単 難しいのは、コンパイラと無関係なやつらが口を出してくること >>559 などとチグハグで噛み合わない内容を並べて平気なプログラマもどきに愛される動的言語をどうぞよろしくお願いします 静的言語は悪くないよ 機械に仕事を任せたものの不安になって結局人間がああだこうだ言ってる状況が悪い 何言ってんだかわかんないんだけど? 静的言語が社会悪だってことは学問的に証明されてるでそ。 まあ一般論としては動的はよりライトな応用分野の方が多いような。 大規模処理やミッションクリティカルな分野にはなかなか食い込めていないのも事実。 rev.2. 何言ってんだかわかんないんだけど? 静的言語が社会悪だってことは学術的に証明されてるでそ。 rev.3. I don't see what you argue. It's been scholarly manifested that static-typed languages are social evils, hasn't it? オープンソースじゃないのでやめてください! 著作隣接権を主張します! JSは実行時に最適化するので速いのです。 Cの約二倍速い。 実行前に最適化したほうが速いよ。 実行時の最適化は毎回やるしね。 >>577 ネタだろwマジメに答えんなってw さて、動的押してるフリしてる釣り師諸君に問題です! V8, Rhino, SpiderMonkyはどの言語で実装されているでしょう?! perl, rubyはどの言語で実装されているでしょう? どんな答えがかえってくるかオラわくわくしてきたぞ! >>578 Perl 6はHaskellで実装されたね >>578 Smalltalk は Smalltalk で実装されてたね まあ、javascriptは後方互換性を捨てた方がいいよね 後方互換性を捨てることで 得られるものを具体的に述べよ。 それをお前は欲しいと思っているはずなんだよね? > 後方互換性を捨てることで > 得られるものを具体的に述べよ。 訂正 後方互換性を捨てないと 得られないものを具体的に述べよ。 無駄なコストを捨てようとしたら コストとは何かが客観的にわからないということがわかった どうせES6以降のコードはES5の実行環境では動かないのだから、use "ES6"とか オプションつけたら変数スコープも常識的なブロックスコープになる機能が欲しい。 let導入で二種類の変数スコープが併存とか無意味すぎ。 もう今のvar相当はobsoluteで使ったらログに警告吐くぐらいの勢いで良い。 JSは互換性にも配慮されているので問題ありません。 低級言語の仕様を変えさせないという目的もある 高級言語を気が済むまで改変させることで低級言語が守られている >>587 移行というのは前のをバッサリ切り捨てるやり方じゃダメなんだよ。 いきなり全てを変えるなんて出来やしない 両方共存出来る状態を作って少しずつ変化させていく。 こうやらないとだめ。 > どうせES6以降のコードはES5の実行環境では動かないのだから、 動く。Polyfill系なんかがそう。 動かないのはletなどを使ったES6専用のコードだけ(コンパイルエラーになる) こうやって、部分的にES6対応コードに置き換えていく。 varに関してもletに単純に置き換えれるように コードを整理することは可能。これでES6でもES5でも動くコードになる。 これはES6に早い段階から対応していくという方針のやり方。 逆に将来ES6が十分に普及してしまった後にレガシーなES5を移行する。というような場合でも varとletの両方が使えるならば、徐々にES6コードに置き換えるていくことが可能になる。 昔のことを覚えていなければ、いま新しいことをしているのかどうか分からない letは別に新しくともなんともなく単に普通なのであって、varも古い云々以前に単に変なだけ。 特に覚えておく必要も無い。 なのでuse strictの強化版のようなばっさり切り捨てる機能があって良い。 最強のPythonが動的型言語なので 動的型言語の方が生産性が高い 普通は文字列は一次元で絵は二次元だけど 「実行しないとわからない」なら時間軸を追加して次元がひとつ増える 三次元は正確に認識できないことがあるので生産性が低い それは時間軸が原因だともいえるし、絵が原因だともいえる オメーらあんまりgdgd言ってっと型に嵌めちまうぞッ Pythonも微妙になってきたな。 CG方面でなぜかデファクトだから仕方なく使う感じだ。 >>591 > 移行というのは前のをバッサリ切り捨てるやり方じゃダメなんだよ。 > いきなり全てを変えるなんて出来やしない そうとは限らん。そういう場合もあるというだけだ。 破壊的変更と非破壊変更は相互補完の関係にあって、どっちを偏重してもいかんのだよ。 現にMozillaも新言語Rustを作ってるしな。 つかどう見てもES4のときに一度ばっさり互換を切るべきだった。 あれがWeb Platform最大の失敗だったことは、無数のaltJS乱立によって証明済み。 altJSって、2007年頃のLLブームに乗っかり、 いんぽqのに騙されたバカな魔法少女たちぐらいしか使わないんじゃねーの? >>600 > 現にMozillaも新言語Rustを作ってるしな。 Rustへの移行が成功してから言えよw 現時点では前(JavaScript?)のをバッサリ切り捨てて Rustを作ったが、ほれみろやっぱり移行していないではないか。 という実例になってるぞw > つかどう見てもES4のときに一度ばっさり互換を切るべきだった。 ECMAScript 4は互換を切ったよ。 だから仕様もまとまらなかったんだが。 それもまた、互換性をバッサリ切り捨てるやり方は 失敗するという、お前がいいたいのと正反対の実例だな。 JSは土管なんだから 後方互換性は何よりも大事だよ 処理系間の互換性が崩壊してる言語で後方互換性がどんな意味を持つんだろうか ESがバッサリ互換切り捨てたらバージョン間互換すら出来なくなるよね コメントがなくてもわかるような コードを書けってきかない? コメント書くのは素人 >>608 よっぽどのその言葉気に入ったみたいだなw コメントの9割は無駄!〜アンチプラクティスから学ぶ洗練されたコメントの書き方〜 #code #コード https://codeiq.jp/magazine/2013/12/3700/ 番外編 プログラムのコメントは少なければ少ないほど良い? http://www.appresso.com/now/column/2010/09/0009-1.html 先日、日経ソフトウェアで「プログラムのソースコードは20%を切ることが望ましい」 という記事を書きました。また、8月のMIJSでのディスカッションでも議論の中で 同じように「詳細設計書やプログラムのコメントは多い方が良いか、少ない方が良いか」という議論がありました。 この話は、私が大学時代に教官から「以前は、コメント率(ソースコード中のコメントの割合)は 50%を超えていないと品質が低いとされた」という話を聞いて衝撃を受けたことが発端となっています。 私自身は、詳細設計書やコメントは少なければ少ないほど良いと思っていたのに、 「コメント率は50%を超えなければいけない」と言われ、驚いたわけです。その頃は、 自分はプログラムは小学生の頃から趣味で色々と書いていたとはいえ、まだプロとしての 経験がないので理解できていないだけかとも思ったものですが、大学を卒業してプロとしての プログラマーの経験を10年強積んだ今、以前にも増して「ソースコードのコメント率は 低ければ低いほど良い」という考えが強まっています。 ソースコード中のコメントは多いほうがよいのか、少ないほうがよいのか? http://d.hatena.ne.jp/eel3/20130815/1376529541 コメント率50%とか正気の沙汰ではないな ソースコードに詳細設計書をそのまま書いてるようなもんじゃん コメントを読む必要があるのはソースを読めないから。 つまり初心者。 テストを徹底するのは不可能 まずこういう前提がある。 なぜテストを徹底するのが不可能かというと その数が極めて膨大になるから。 例えば条件分岐が16個あるとする。 その組み合わせは2の16乗で65536になる。 条件分岐が32個であれば4294967296 1つ1ミリ秒で実行できたとしても50日かかる計算になる。 この全ての組み合わせをテストするのは不可能。 一つのアプリで条件分岐はいくつあるだろうか? 普通は32個よりはるかに大きな数であろう。 だからテストを徹底するのは不可能という結論になる。 テストはその一部しか出来ないのは当然の話。 だからその一部で十分とみなせるようにしないといけない。 そのためにはアプリの作り方と静的なチェックが重要になる。 >>616 ホワイトボックステストとブラックボックステストの違いくらい知っておこう 基礎知識がない人に限って断定口調で話す傾向があるね >>618 ホワイトボックスとブラックボックスの違いを知らないと 思った理由は? なんでさ、知らないと断定するの? それに、ホワイトボックス(またはブラックボックス) だったらなんなのさ? 知らないだろうといっただけで、 お前は意見を何も述べてなよ。 >>619 テストにはホワイトボックステストとブラックボックステストの二種類がある。 >>616 のレスはホワイトボックステストにしか当てはまらないが、 それなのにテスト全体について総括した意見を述べてしまっている。 よってブラックボックステストのことを知らないのだろうと判断できる。 >>621 ブラックボックステストにも当てはまるぞ。 条件分岐を、チェックボックスと置き換えればいい。 32個のチェックボックスが存在する検索フォーム 例えばこんなのな http://www.chintai.net/tokyo/search/en_101001/ テストを徹底するというならば全ての組み合わせを実行しないといけない。 特定の組み合わせでのみエラーが起きるというのは普通に存在する。 >>610 文芸的プログラミングが推奨された時代の話じゃねーの? てか、サイレントボブみたいにコールグラフ描くツールの使い方おしえろよ コメントがなくてもわかるような コードを書けってきかない? コメントは コードに情報を埋められない言語の逃げでしかない。 名前を変に省略形にしたり、変数がアルファベット1文字だったり、tmpだったり、 さらにそれを同じメソッド内で別用途に使いまわしたり、 1つのメソッドor関数で多くの機能を入れ込んで、さらに上流と下流のコードが混在していて、 どのブロックが上流の下流のどの工程なのか熟読しないと分からないとか、 まあ、「リーダブルコード」を読め、ってことだ。 まあ業務系は客観的に見て暇な仕事だからコメントをウダウダ書いて暇つぶしする余裕があるww 余裕がないとか言っている奴は隣人や就職希望の奴の仕事を奪って忙しがってる小山の大将(バカ) >>616 テスト専門企業のHP見れば判るけど、今はテストケースをどうやって減らすかがノウハウだよ。 統合環境にはチェックボックスが32個ぐらいあるんだな シェルだったらコマンドが32個あっても組み合わせた場合の責任はユーザーに転嫁される そもそもCPUもディスクもメモリもOSもデバイスドライバもランタイムライブラリもそこまでの品質に達していないからPCごと窓から投げ捨てろ Linuxの品質は高いが、OSSは総じて品質が低い なぜだ? ソースを公開する動機は品質向上というより、古いソフトの寿命を延ばすことだから おびただしいゴミの山から一握りの大成功だけをもってOSSと呼んでいる 流行に乗って何度もクソを取り上げてもてはやした過去は都合よく忘れている 業務アプリとかの方がクソっぷりは上だけどねー いやホントに いやいや捨てられて都合よく記憶からも消去されてしまうクソにはおよびませぬ 今年はC++の1.5倍速いJSが馬のように勝つでしょう(^.^v) Smalltalkも遅いしな。 動的言語が速い云々は特定ユースケースに絞った口先ばかりの話ばかりだ。 まあC#よりは速いんだからJSの速度は認めるしかないわな。 実際C#と同等に動いてくれるならわざわざネイティブで作らんでもいいんだけどねぇ(´・ω・`) ちょっと話変わるけどC#とJSって近いよな 例えばUnityのJSはC#バインディングだし 同じ臭いがする >>631-632 バイドゥのIME Shimejiってオープンソースじゃなかったっけ?(w そして、GoogleはIMEをオープンソースにしていない。 Googleは情報を集めることを公言してるし、 何と言っても検索で情報を提供してる またWidevineみたいな情報を閉ざす方にも力を入れてる Googleは情報の管理人として最も相応しい存在として世界中で認められているので Baiduの件に比べて問題が少ない ×問題が少ない ○問題が大きすぎて思考停止している 自動車の事故と同じ 多大なメリットを提供してくれるGoogle様にはさからえない >>641 ネイティブ吐けるC#ってあったっけ? CLR上でC#を超えるようなJS実装ってあったっけ? 比較対象がおかしいよ C#もJSも最終的に機械語になって実行されるんだから何も変わらん 静的言語はキャストがめんどうなんだよな。 あんなもの苦痛でしかない。 >>650 MS社内にあるだけで門外不出なんだろ? >>652 いやググれば出てくるでしょ MonoはC#をネイティブ出力できるよ この世はC#を無条件でWindows+.NET+Formsへと脳内変換する視野狭窄なドカタで満ち満ちている ネイティブなどとほざいても絵空事にしかならない >>651 関数型がデフォルトイミュータブルなのと一緒でそれを不自由と見るか保証と見るかはあなた次第。 >>1 のコードだと、指摘したい内容に対して微妙に噛み合ってないような 実行前に(変数の)型が決まっているかどうかと 変数に型を持たせられるかどうかは、厳密には別の話だよね 大抵の動的言語は変数に型がないから、端的に示すには十分なんだろうけど >>657 「型体系(type system)」と「型付け(typing)」の違いだね これらはの概念は組合せ(直積)で考える必要がある 型体系(type system): ・単一型(型無し、とも言う) ・ただ一つの型しか存在しない、言い換えると型を区別しない 例:Tcl や Shell --> 文字列型のみで、1 と "1" はどちらも文字列 ・素朴な型体系 ・複数の原始型と僅かな複合型 例:Lisp、Prolog、JavaScript --> 数値や記号といった原始型(=アトム)と リスト(Lispの場合)または項(Prologの場合)から構成される ・複雑な型体系 ・複数の原始型と複合型 例:Pascal や C といった多くの手続き型言語、および ML族のような初期の静的型付け関数型言語 --> 以下の3種類の基本構造から構成される ・直積:タプル、レコード(=構造体) ・直和:列挙型、合併型(=共用体)、代数型 ・列:配列、リスト ・複雑で階層的な型体系 例:C++/Java/Smalltalk/Ruby といったクラスベースのオブジェクト指向言語、 および Haskell や Scala のようなアドホック型多相を基礎とする関数型言語など 型付け(typing): ・静的型付け:Pascal/C/C++/Java/C#/OCaml/SML/Haskell/Scala ・動的型付け:Lisp/Prolog/JavaScript/Smalltalk/Ruby/Python ・ハイブリッド:Objective-C 現在プログラム板のID制導入の投票を実施中です よろしくお願いします プログラム板 強制ID制導入に関する投票スレ http://kohada.2ch.net/test/read.cgi/vote/1394290844/ メインで使う言語が Ruby から入って今は専ら Java だけど、 Rubyに戻りたくないな やっぱ静的型付けは曖昧さがないから安心感が高くていいよ オーバーロードも出来るし 開発環境もいろいろサポートしてくれるし まぁでも Ruby はそれなりに良い言語ではるけどね クロージャが書きやすいし(Javaでも書けるけど) ミックスインも強力だし……そういえば Java8 でインターフェースのデフォルト実装来るのだろうか? クラスがオブジェクトとして扱えて、クラスメソッドでポリモーフィズムが使えたり うーん、懐かしいわ NumOrString で何がやりたいの? Genericで型を作る事(IntやDouble とStringだけに制限かけるとか)でもできるし 何もしないでAnyでも良いだろ Swift で Int を取りだす例 func getInt(v: Any)->Int{ if v is String { return (v as String).toInt() ?? 0 } else if v is Int { return v as Int } return 0 } var numOrStr: Any = "100" // 文字列代入 println( getInt( numOrStr )+2 ) //102 numOrStr = 200 // 整数代入 println( getInt( numOrStr )+2 ) //202 動的型言語が急激にオワコン化しつつある まだどっちにもメリット・デメリットがあるだの中立を気取る穏健派気取りも多いが 明らかにそんな段階超えてるっしょ。英語圏でもこんな記事が人気だ。 The abject failure of weak typing(弱い型の惨めな失敗) http://techblog.realestate.com.au/the-abject-failure-of-weak-typing/ あと、静的型の連中はテスト書かんのか的勘違いしてる動的派たまにいるけどさー 型チェックして、静的解析して、その上でさらにCIもするに決まってるだろw バグを減らすためのあらゆる手段を各段階に投入するんだよ。 それから、動的型の方が気楽に書けるだの速く書けるだのは妄言というほかない。 コードを実行するよりも前に、テストを走らせるよりも前に一定のバグチェックが働いたほうが 明らかにイテレーションが高速だろうが。常識で考えろ。 プロジェクトの規模が膨らむほど顕著になる。 つかせいぜい数千行で明らかに静的型の方が採算が良くなる。 リファクタリング一つ取ってもどうするつもりなのか。 静的型言語だとガチャガチャ数百行一気に組み換えて コンパイルエラー何十個か潰して実行したら何の問題もなく動作するというようなことがままあるわけだが RubyだのJavaScriptだのがメインの連中、そういう快感を知らないし想像もできないのだろう。 静的型で優れたIDEの恩恵をきちんと受ければどれほどの高速コーディングができるかも知るまい。 まして、プログラマは怠惰であるべきだから動的型マンセーwだの Twitterでアホがツイートしてるのを見たときには 馬鹿じゃねえのかと思ったよ。本気で。 >>662 weak typing? 技術用語の使い方も間違えてるバカのいうことなんか放っておけばいいw 「静的型言語」と言ってる時点ですでに穏健派の思う壺だよね 不特定多数の言語を指してるから 一つに絞り込む必要性が全く感じられない 複数選択可なら動的型言語も選んでみたくなる TypeScriptみたいに、動的型言語なんだけど、 オプションで型を書いて静的型検査する言語は どうなんだろう? 言語について静的と言っているのか、型付けについて静的と言っているのか、曖昧な表現を使うな。 「静的言語」か「静的型付き言語」の、どっちかにしろ。 >>667 何を言ってるんだよ TypeScriptは単なるプリプロセッサ。 出てきたJavaScriptが動的言語と言うだけの事 そんな事を言ったら色んな言語がそうできる C++他からJavaScriptとか(Emscripten) 或は各種動的プログラミング言語のコンパイル版 例えば Python のPypiとか 機械語レベルにまで変換したら、 すべての言語は型情報を持たない。 >>670 byte単位、word単位、dword単位のインストラクションを持つCPUを使う限り 機械語にも型情報がある。 >>672 それは型じゃないな。 ただのビットサイズ >>674 符号の有無もあるぞ。十分にデータ型の条件を満たしているが。 メモリ上のオブジェクトのビット幅と符号等のエンコーディングだけでは型じゃないというなら、 じゃあC言語の型は型じゃないのかよw BCD はとうの昔に忘れ去られたんだね‥あの系のフラグの上げ下げ、一生わからないだろーなー‥ (どうしよう「ノイマン型コンピュータの最大の弱点はデータとオペランドが 同じメモリ空間に等しく並んでいることだ」なんて基礎中の基礎の議論を 一度も見たことがないような人間がビットはデータだ型だ言っててゲロ吐きそうw) >>675 メモリーのビット列見ただけで符号なのかわかるのか? >>672 >>677 同じバイト並びがメモリにあっても、それを読む命令次第でどうとでもなるよ。知っていると思うけど。 だからC言語の型、例えば * (掛ける)を使ったコードがあったら、掛ける数の型に合わせて機械語の命令選ばないと答え無茶苦茶になっちゃうじゃん。 >>681 で、C言語の型はキャスト次第でどうとでもなるわけだが、 C言語の型は型ではないのかね? ダブルディスパッチなら型そのものに振る舞いを記述する必要はない ここ最近の「型」って言葉、人によって指してるものが違うよね 言葉だけひとり歩きしてしまった感じ このスレで言われているような「型」の認識だと、旧世代的な言語を想像してしまいがちだけど Haskellの型クラスやScalaのトレイトみたいな、アドホック多相が表現可能な静的型付けのことでしょ 今いろんな人が注目してる「型」ってのはさ ユニバーサル多相からアドホック多相に退化して何がうれしいの? r、_Lヽ___ / \ / \ | __ l___ l . | /^-⌒ヽ、r-、/-| | ヽ | / ̄ヽ / ___ヽ r .| ヽ -v | l  ̄|j ヽ--、、ヽ / ̄ヽ_)  ̄ー- __/.三l ミl | ⊥イ _三l ミl |_ ヘ/ lヽー ァ' / l  ̄ | / ヽ 、 | |ヽ ) /_|/___(_ ゝ ヽ ___っ二l '┴┴┴' JSがCより早いとか言ってる奴はキチガイ インタプリタがネイティブコードに勝てると思ってるの? このスレアホみたいに勢いあったのにあいつらどこ行ったの? >681 機械語の命令は変わらないだろ? 量的な扱いが変わるだけで。 匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、 BitTorrentがオープンソースで開発されています 言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか? Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします https://twitter.com/Lyrise_al ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw The Covenant Project 概要 Covenantは、純粋P2Pのファイル共有ソフトです 目的 インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します 特徴 Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW) 接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です DHTにはKademlia + コネクションプールを使用します UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります) 検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません ^ 機械語にも型はあるに一票 特にC/C++のポインタ型なんかは、単なるビット列を、どう見なして どう解釈するか、という側面がある だから同じビット列であっても、キャストでどう見なすか、によって 違った演算が行われる C/C++の型を型と認めるなら、機械語にも型はある ただし、型の情報はオペコードに埋め込まれている 単なるビット列を何に見なして演算するかという型 で、なんでこんな変な流れになってるかちょっと考えたんだけど 型はデータが持っているものだと決めつけている人がいるんじゃないかと 動的型言語であればそうかもしれないが、静的型言語は必ずしもそうではない かのC言語は、構造体であろうが何であろうが、実行時型情報など持ち合わせていない C言語の型は、ビット列、メモリブロックをどう見なして解釈するかというだけであり データ自体にそれが何であるか示す細工はない このシンプルさが今でも使われている理由(メモリレイアウトがシンプル) また、Javaであっても基本型のインスタンスは型情報を保持していない ここが分かってないから、「ただのビット列だろ?型なんか無い」などと変なことを言うのではないかね 急激に過疎ったスレとして資料価値がある 一番勢いあったのがIDなかった時代だというのが興味深い 必死で会話続けようとしてるが誰もついてこないが滑稽 時代に取り残されたものとはこういう人のことを指すのだろう えええ、そういう意味なの? webサーバー=httpサーバーってことなの 「WEBサーバー」って、いろんな機能が入ったサーバーの総称かと思っていた。 メールサーバーは「メールができるだけだろう」くらいにはわかっていたが、webサーバー ってのはメールもhttpもsmtpもできるんだろうと思ってた。 Win32APIスレに>>699 をコピペしてんじゃねえぞ わかってんだよザコ 不具合が1件でもでたら、終身刑がまっている状況に耐える プログラムをするならば、動的とかありえんよ。 出したあと修正が不要状態を維持でない世代にはわからんだろうけど。 昔の組み込みなどは一度だしたものは、ROM修正などできない。 不具合がでたら倒産する企業だってあったわけだ 不具合を言語のせいにする会社は潰れるだろうねえ・・・ 南無阿弥陀仏、南無阿弥陀仏 ちなみに昔の組み込みは静的型言語なんて使ってなかったぞ、素人さんw >>705 > ちなみに昔の組み込みは静的型言語なんて使ってなかったぞ、素人さんw で、何を使ってたと言うんだ? w 一応念のために言っとくけどアセンブリ言語とかの臭い答えはやめてくれよな ムカシハ静的デ〜もなんも実行プログラムの一部をRAMに置いて そこをダイレクトに書き換えて、動作変えたりしてたっつーのに なんだこのCから始めたようなにわかは。ダッセェ そうそう、LD命令のオペランドを変数領域に使ったりしてたな。 得意気に自己書き換えコードを語る前にスレタイ読めよ... 静的言語を導入すると一個も"完成"しないからゼロは何倍してもゼロという話だろうか 「静的型付け言語」を「静的言語」とか言う奴は漏れなく論点を理解できてないバカだと思う あたかも自分は貢献しまくり と妄想してるだけの >>713 であった... http://gihyo.jp/news/report/01/rubykaigi2016/0001 本当に往生際が悪いというかなんというか、いったい何の意味があるのか 一方ロシアは鉛筆を使ったって感じ 「負けたんだよ」って誰か言ってあげて 自分が欲しいものを作っただけなのに いつのまにか予算獲得が目的に変わってしまって・・・ >>718 もう勝手にやってれば〜 って感じだよな... option explecit な感じに仕上げてくれるんなら型があってもいいな 動的言語の綴りミスはちょっと排除できそうにないからな… 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 ICI7B ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる