【JavaScript】ｽｸﾘﾌﾟﾄﾊﾞﾄﾙﾛﾜｲﾔﾙ55【php,py,pl,rb】 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/10/01(土) 23:40:48.89

前スレ

【JavaScript】ｽｸﾘﾌﾟﾄﾊﾞﾄﾙﾛﾜｲﾔﾙ54【php,py,pl,rb】
http://echo.2ch.net/test/read.cgi/tech/1458955459/

**デフォルトの名無しさん** · 2016/10/13(木) 07:56:11.59

>>124
ポイントをずらした反論で逃げているね。

・言語（＋フレームワーク）の選択によって開発効率に差が出る
・「特定の言語じゃなくても（フレームワークを）整備できる」という主張には何の根拠もない
については特に反論しないということでOKかな

**デフォルトの名無しさん** · 2016/10/13(木) 08:30:22.11

>>151
> 差が出るわけない

いや、逆だろ
HelloWorldレベルでも歴然とした差が出るんだな　これが
Rubyじゃ、どうひっくり返ったってシンプルには書けない　書けたっぽくても欠陥だらけ
代数データ型を理解してないとわからんかもしれんけど

**デフォルトの名無しさん** · 2016/10/13(木) 10:15:51.93

HelloWorld氏は代数的データ型どころか木構造も分かってなくて、
>>150を怪しい機能を使ってHelloWorldを書けって要求だと誤解してる予感

**デフォルトの名無しさん** · 2016/10/13(木) 21:59:17.17

もうそろそろ代数的データ型で差が出るという
根拠をいったかなーと思ったらやっぱり言ってなかったｗ

**デフォルトの名無しさん** · 2016/10/13(木) 22:00:32.17

>>150
> 書いてみてもらえば差があるかないかはっきりすると思うよ

ならあんたが書けば良いんだよｗ

**デフォルトの名無しさん** · 2016/10/13(木) 22:05:21.45

俺の勝利条件：言語の違いでは開発効率に差がないという結論にすること
俺の敗北条件：言語の違いでは開発効率に差がでると認めること

俺に頑張って調べさせて、開発効率に差が出るという
証拠を見つけさせようとしているようだが、

俺が自分で敗北する努力をする訳がないだろう？

「お前は負けるために努力をしろ！」って言ってるやつって
なんなんだろうね。行動が意味不明なんだけどｗ

**デフォルトの名無しさん** · 2016/10/13(木) 22:44:26.61

横レスするけど、なんだかここ数日、変な流れになっているなあ...

代数的データ型を振りかざす彼ら(>>154,153,150,147,119,107,99,63,27)、
仮に「代数的データ型君」と呼ぼう

で、代数的データ型の定義や利点に関して「代数的データ型君」自身からは何の説明が無いね
個人的には代数的データ型なんて直積と直和を意識したデータ分析/設計だと考えているから、
何をそんなに代数的データ型君が「銀の弾丸」であるかのように騒ぎ立てているのか意味不明

ちなみに、代数的データ型という用語は用いられていないけど、直積/直和/列という
データ構造の基本要素を元にした設計手法は1980年代末には国内で登場して一部では普及している
・「標準構造に基づく系統的ソフトウェア設計法 (<小特集>プログラム設計技法)」,
　片岡雅憲/金藤栄孝/宮本和靖/山野紘一, 情報処理 Vol.25 No.11 (Nov. 1984)
　　http://ci.nii.ac.jp/naid/110002720151/
簡単な解説ならば、上記論文の著者による以下の書籍が参考になる
・ソフトウェア・モデリング―ソフトウェア再利用のための設計パラダイム単行本 – 1988/9　
　https://www.amazon.co.jp/dp/4817160160

また木構造や代数的データ型を分かっていて断定的に語るのなら(>>154)、当然、その原典である
以下の論文くらいは読んでいるんだよね？
・Algebras for Tree Algorithms - Jeremy Gibbons 1991
著者はいわゆる代数的データ型の第一人者で、Haskell界隈で木構造の論文を漁ると必ず行き着く文献だよ

**デフォルトの名無しさん** · 2016/10/13(木) 23:14:36.15

てすと

**デフォルトの名無しさん** · 2016/10/14(金) 01:12:59.85

>>158
代数的データ型を関数型言語（元ネタはOCaml）で書くと効率いいですよ、ってのが >>27 の意見
なんだけど、HelloWorld君はそもそも代数的データ型を知らないので、この分野に関して開発効率の
話はなにひとつ言えないはずなんだよね

言えない以上、開発効率が言語によって変わらないという主張はできないはずなのに、それを
声高に主張しつづけるという論理的に明らかにおかしい状態になっちゃったので、周りのみんなが
面白がって「代数的データ型は？ねえ？どうなの？」ってからかってるのが現状かと

HelloWorld君は「言えないけど、差があるという事実がないので差がないことが正しいんだ」という
これまたわけの分からない主張を一切変えないのでまったくかみあってないというｗ

**デフォルトの名無しさん** · 2016/10/14(金) 01:15:29.41

効率いいですよっていうだけで、
効率いい理由を言ってない。

**デフォルトの名無しさん** · 2016/10/14(金) 01:24:21.14

>>161
変わらない理由も言ってないよね

そりゃ、分からない範囲のことは言えないのが当然の話
まずはそこを認めるところから始めないと議論にならないよ

**デフォルトの名無しさん** · 2016/10/14(金) 07:08:23.14

absence of evidence is not evidence of absence (証拠の量と結果は比例しません)

**デフォルトの名無しさん** · 2016/10/14(金) 07:43:39.03

>>162
変わらない理由は上の方で言ってるよ。
それに対して、代数的データ型がある場合は違うって
言ってきてるんだから、なぜその場合だけ違うかを
説明しないとだめ。

**デフォルトの名無しさん** · 2016/10/14(金) 07:45:54.24

>>164
君の説明から分かることは「あぁ、HelloWorld君は代数的データ型を知らないんだね」ということ
だけだよ

まずこの事実を認めよう
そこからじゃないと議論は始まらない

**デフォルトの名無しさん** · 2016/10/14(金) 08:41:21.48

>>164
「ほら、HelloWorldじゃ言語の差は出ない！証明完了！」って言ってるだけじゃんw

なおHelloWorldより難しいプログラムは分からない模様

**デフォルトの名無しさん** · 2016/10/14(金) 08:58:45.24

>>165
> HelloWorld君は代数的データ型を知らない

もうそこは自明でいいんじゃないかなと思う
本人も>>157で「頑張って調べ」ないと代数的データ型すらわからないと暗にギブアップ宣言しているし
「敗北する努力をする訳がない」と、代数的データ型を前提とすることで敗北が確定することを
自ら予見できているわけだから

**デフォルトの名無しさん** · 2016/10/14(金) 09:18:34.24

なんでこう頑なに代数データ型で差がある事を
説明しないんだろう？ｗ

仮に代数データ型が知らないとなったからって
差があることにはならないんだが。

誰でも知らないことが有るわけで、反論っていうのは
その部分を突くわけよ。あんたはそれが出来てない。

**デフォルトの名無しさん** · 2016/10/14(金) 09:36:41.21

もしかして代数データ型君は代数データ型って言葉を
知っているだけで、それを使ったコードを知らないんじゃないかな？
そう考えれば、代数データ型でどう開発効率が差が出るかが
言えないのも辻褄が合う。

本当に代数データ型で開発効率に大きな差が出るのなら
他の言語でも対応してるだろうしね。

それからHello Worldの例は、Hello Worldを出力する部分は関係ないよ。
アプリケーションサーバーと連携してルーティングを行ってパラメータを解釈して
という内容を書いたら長くなるがフレームワークやライブラリがあるお陰で
本質的な部分だけにすることができる。その本質的な部分はどの言語も
必要最小限になるって話なんだから。それが読み取れないようじゃだめだねｗ

**デフォルトの名無しさん** · 2016/10/14(金) 09:54:52.55

HelloWorld君にとってはHelloWorldが本質なんだねw

**デフォルトの名無しさん** · 2016/10/14(金) 10:04:08.99

ここにhogeという（関数型ではごく普通の）言語機能がある
hogeを使うと生産効率があがる仕事Ｘがある
ある言語（仮にrubyとしよう）にはhogeがなく、制約からhogeをフレームワーク等で完全にシミュレートすることも不可能
Ｘにおいてrubyと普通にhogeを装備した言語との間には生産性に差が生じるのは自明

**デフォルトの名無しさん** · 2016/10/14(金) 13:03:12.66

これはネットでよく見かける
主張はすれど根拠は示さないパターン

さらにいうと
なぜか根拠を不思議と出し渋るパターン

代数データ型で効率上がるって言う人の話ね

**デフォルトの名無しさん** · 2016/10/14(金) 13:13:29.24

>>172
しゃあねぇなあ

じゃあ、ここにある評価器とconnection_infoを書いてみてよ
http://ymotongpoo.hatenablog.com/entry/20111105/1320506449

>>27みたいな仕事はこういった（もちろん。もっと複雑な）評価器を1から書く必要があるからね

あとconnection_infoはリンク先の実装と同じく不正な使い方を出来ないようにしてね

**デフォルトの名無しさん** · 2016/10/14(金) 14:11:57.58

>>140
卵子「...」

**デフォルトの名無しさん** · 2016/10/14(金) 21:53:35.92

>>170
> HelloWorld君にとってはHelloWorldが本質なんだねw

HelloWorldの"部分"が本質なんだよ。
この部分が本質だから、他は変えずに
この部分（HelloWorldの部分）だけを変えれば良い。

そしてこの本質的なコードはどの言語でも大差ない。
だから言語によって開発効率に差がないというわけ。

**デフォルトの名無しさん** · 2016/10/14(金) 22:30:50.25

HelloWorldみたいなちっちゃいものではちっちゃい差しか見えないもんね

**デフォルトの名無しさん** · 2016/10/14(金) 23:04:30.33

>>176
じゃあ、HwlloWorldをオブジェクト指向で作ってみて下さい

**デフォルトの名無しさん** · 2016/10/15(土) 00:57:52.87

>>175
じゃあ>>173の本質的な部分のコードを書いて
言語で差がないことを示してよ

**デフォルトの名無しさん** · 2016/10/15(土) 15:54:45.64

HelloWorldおじさん逃げちゃった？w

**デフォルトの名無しさん** · 2016/10/15(土) 16:31:49.07

>>169
フレームワークを用意しなきゃいけない言語とフレームワーク相当の機能がコアに組み込まれてる言語があるから、
フレームワークを用意しなきゃいけない言語はフレームワークを作るコストが上乗せになるよね

ってだけの話なのに、君はどうやら、ありとあらゆる問題に対して既に素晴らしいフレームワークが提供されている理想郷に生きているようだ。
仙人か。

**デフォルトの名無しさん** · 2016/10/18(火) 07:59:44.51

言語で生産性に差があるって事で決着がついたので、
あらためて良い言語を決めよう

**デフォルトの名無しさん** · 2016/10/18(火) 09:41:12.91

>>179
そもそもコード書けるかどうかも怪しいレベルだね。ちょっと本職が突けばこの通り

**デフォルトの名無しさん** · 2016/10/18(火) 12:26:33.66

ちょっと本職が突けばｗ

**デフォルトの名無しさん** · 2016/10/18(火) 12:38:42.89

結局Javaなんだよなあ

**デフォルトの名無しさん** · 2016/10/18(火) 17:41:42.50

Javaなんて10年以上前に捨てました。ファウラーとかが、主婦が家事のウンチク垂れるのと本質的に同じレベルで、無意味な能書き垂れてた頃ね。コードを1文字書くまでに膨大な思案を要求されるようになった。芸術作品じゃないんだから、そんなもん、オワコンでしょ。

JSですよ。突出しちゃって5年以上たつよね。もう比較にならないほど別格。

因みに、nodejsで作った経験ありません。
基本的にpython使ってます。wsgiね、チェインオブなんちゃらパターン。
そんな奴が何でJS押すかって？
だって、何も読まずにいきなり作れる自信があるからね。やっぱりブラウザとかWSHで使われてたのは大きいよ、過去に特に勉強したつもりがなくても得意にガンガン書けちゃうよ。俺だけじゃなくたぶんそんな人はゴロゴロいる。

**デフォルトの名無しさん** · 2016/10/18(火) 18:07:44.27

Javaというか、多くの昔からある静的な言語が
開発サイクルが非常に速くなっていっている現状で
シグネチャの変更スピードについて行けなくなってきている

結果扱いきれてるのは非常に力と資産をもった元請け企業のみで、
下請けはどんどん時代に取り残される悪循環が始まってる
そういうところは５年後１０年後生き残っては居ないだろう

これからは殆どの力なき者にとってはスクリプト言語の時代

**デフォルトの名無しさん** · 2016/10/18(火) 21:36:24.79

>>185
> だって、何も読まずにいきなり作れる自信があるからね。
使い捨てのスクリプトならそうだろうけど
ちゃんとしたものを作ろうとしたら大変だよ？（JavaScriptに限らない）

まずビルド環境を整えないといけない。
そうしないとテストやカバレッジ測定すらできないから。

ある程度の規模になればフレームワークは必須だけど、
Reactを使うならばBabel（ECMAScript2015～ + JSX）の導入がほぼ必須。
Angular2を使うならばTypeScript（JavaScriptの上位互換）の導入がほぼ必須

ちなみにECMAScript も TypeScriptもIE6ぐらいの時代のJavaScriptとはぜんぜん違う。
文法はPythonに劣らないどころか超えてると言ってもいいぐらいに改良された。
もちろんその反面、文法だけみると覚えることはPythonよりも多いがｗ

そういった環境でモジュールを使うならばビルド環境に合わせたモジュール管理の仕組みを使う。
簡単に使えるが、環境を整えるまでが大変。

パフォーマンスを上げるために複数のファイルを結合したら圧縮したりするが
これまたビルド環境を整えろという話につながる。

大変だがちゃんと整えれば静的解析でリアルタイムにエラーを教えてくれるようにもなる。
atom + eslint で構文エラーやスペルミスをリアルタイムに教えてくれるのは便利。

ここまでやったことないでしょ？
つまりあんたが何も読まずに作れるっていってるのは、何も読まずに作れる範囲のことしかしてないからなだけ。

**デフォルトの名無しさん** · 2016/10/18(火) 21:55:55.42

>>187
HelloWorldより難しいプログラムを作れるようになったか？

**デフォルトの名無しさん** · 2016/10/18(火) 21:56:27.15

文法ねぇ
確かに大規模コードのための文法は着々と準備されていってるね。

でももうずっと思ってるがJSって、例えば連番の配列を作る、みたいな便利系機能や、
各クラスのメソッドが少ないんだよね。

まあ互換性の重要度が高いJSではそういうの増やして
負の遺産を作るリスクを取らないのは正しいと思うけどさ。

ちょっとuserscriptやツールの軽量なスクリプト書こうってときに
一々ライブラリ引っ張ってこないといけないのも困るんだよね

**デフォルトの名無しさん** · 2016/10/18(火) 21:59:43.78

>>189
それもまた「何も見ないで作れる」っていうのが
簡単なことしかやってないだろうなってわかるよねｗ

**デフォルトの名無しさん** · 2016/10/18(火) 22:37:19.60

>>189
負の遺産ではなくて、言語の仕様に対して実装が多すぎて、仕様を大きく変えても実装がどうせ
追いついてこないという実情があるんだろうね
とはいえ Microsoft が古い IE をばっさり切ったのでその辺の事情も変わってくるかもしれない

とか言ってるとスマホ全盛時代になって古いスマホブラウザに引っ張られるというこれまた新たな
ネックが生じてしまう時代になってしまったのは皮肉というべきか

**デフォルトの名無しさん** · 2016/10/18(火) 23:17:00.33

と言っても仕様を決めてるTC39メンバーにはハードベンダーや研究者も居るけど
中核は全員ブラウザベンダーの人達でしょ。

その人達は慎重な面も持つけど消極的というわけではないよ。
ただ、『配列を連番で作る』よりも「WeakRef」やら「SIMD」やら「Atomics」やらの方が
重要と考えているだけだろう。

それと技術的な話だと「標準ライブラリ」の仕組みを整えないといけない。
それにはまず普通のモジュールの仕組みが整うのを待たないといけない。

**デフォルトの名無しさん** · 2016/10/19(水) 00:14:59.40

WEB+DB vol.94 が出た

特集は、Scala, Groovy の対抗馬となる、JVM上で動く、Android用言語、Kotlin

JS/HTML/CSSで、デスクトップアプリを作る、Electron

**158** · 2016/10/19(水) 00:15:02.24

>>173
結局、>>172が指摘してるように「主張はすれど根拠は示さない」し
「根拠を不思議と出し渋る」しかないみたいだね
おそらく代数的データ型君は「自分の言葉では根拠を述べることができない」んだろな
だから、他人の書いた文書のリンク先しか書けない

代数的データ型を分かった気でいるけど実は無知であることを
代数的データ型君本人が自覚できていないんじゃあ、しゃあないわ

> じゃあ、ここにある評価器とconnection_infoを書いてみてよ

しゃあねえからRubyで書いてあげた
　https://ideone.com/WpazqE
当然、「connection_infoはリンク先の実装と同じく不正な使い方を出来ない」よ

評価器については、>>173のリンク先文書にJavaのコードがあるから省略しとく

**デフォルトの名無しさん** · 2016/10/19(水) 00:32:17.20

>>194
そのconnection_infoは実行しなくても静的にエラーを弾けるの？静的検査できないなら同等じゃないよ

それと、あのJavaの評価器でOCamlと同じ生産性だと思えるなら話にならない。冗長で書きにくいし可読性も最悪じゃん

**デフォルトの名無しさん** · 2016/10/19(水) 00:41:17.08

つーか、ConnectionInfoのconnection_stateに何でも値入れ放題じゃん
ちゃんと問題理解してる？

**デフォルトの名無しさん** · 2016/10/19(水) 00:49:36.13

>>194
https://ideone.com/M3A7QS

www

**158** · 2016/10/19(水) 01:34:04.06

>>195,196
おいおい代数的データ型君達よ、論点を都合良くずらすなよ
今ここで議論しているのは「代数的データ型が生産性に与える影響」だろ？

静的型付けの利点、そしてML/Haskellといったモダンな関数型言語が提供する
完全な型システムとそれがもたらす型推論による簡潔なコードという利点なんて、
とっくの昔から何度もこの板では議論されている訳で、何を今更の話をしてんのよ

結局、代数的データ型君達は、型システムの概念と代数的データ型の概念を
ごっちゃに理解して分かった気になっているだけだろ
だから代数的データ型の利点に関する根拠として、>>173のリンク先文書を示して
何の疑問も持たず平然としているんだよ

>>196
>つーか、ConnectionInfoのconnection_stateに何でも値入れ放題じゃん

動的型付け言語であっても実行時に型検査はできるよ
https://ideone.com/IUv2v2

そして繰り返すけど、型システムの概念と代数的データ型の概念はごっちゃにすべきではない
たとえば代数的データ型を備えた動的型付け言語や、型推論の無い静的型付け関数型言語を想像してごらん
そういった想定の元であっても明解さを失わない代数的データ型の利点とその根拠を示せと言ってる訳

つーかさ、いいかげん代数的データ型の定義とその利点/根拠を自分の言葉で語ってみろや

**デフォルトの名無しさん** · 2016/10/19(水) 01:40:34.09

え？普段の仕事で代数的データ型（っぽいこと）を
使うようなことしてないの？俺はしてるぞ。
コードの半分ぐらいは代数的データ型があれば
簡単に実装できる。具体的に言うと

**デフォルトの名無しさん** · 2016/10/19(水) 07:51:06.99

>>198

＞しゃあねえからRubyで書いてあげた
＞　https://ideone.com/WpazqE
＞当然、「connection_infoはリンク先の実装と同じく不正な使い方を出来ない」よ

>>173で自信満々にこう書いておいて、指摘されたら慌ててアサーション入れまくるのクソワロタw

**デフォルトの名無しさん** · 2016/10/19(水) 07:52:41.50

>>200
あ、間違えた>>173じゃなくて>>194だった

**デフォルトの名無しさん** · 2016/10/19(水) 07:56:48.84

>>198

> 多くの必要な不変条件を型の中に埋め込みました。いまや不変条件は型の一部なのです。コンパイラはこれらの不変条件を破るコードを見つけ、拒否することができます。これは手作業で行う仕事を減らし、手で管理するよりも信頼できます。

ごめん。引用しちゃったw
君の手作業でアサーション入れまくりのコード（いわゆるテストの一種）より静的型検査の方が手間が少なく間違いにくいのは自明ですよ

**デフォルトの名無しさん** · 2016/10/19(水) 08:17:18.72

どこかの理想の世界ではそうかもしれないけれど
現実アサーションと静的検査は双方補い合うもので、どちらかあれば足りるものじゃ無いでしょ

**デフォルトの名無しさん** · 2016/10/19(水) 08:27:14.32

>>198
ConnectionInfo.class_eval do
def foobar(s)
@connection_state = s
end
end
c.foobar("Hello World!")

**デフォルトの名無しさん** · 2016/10/19(水) 08:34:11.07

>>203
勿論そうだけど、不正な使い方できるコードを自信満々でアップしちゃうくらいには
手動は間違いやすいって事だよ

**デフォルトの名無しさん** · 2016/10/19(水) 09:19:42.80

なんでいまさらタイプセーフありがてぇ
静的型付けありがてぇの話になっちゃってるの？

**デフォルトの名無しさん** · 2016/10/19(水) 09:41:28.41

論よりコードっていうけど、ほんとコードの提示って怖いね
HelloWorldくんの底が知れた　無様…　逃げたほうがマシだったんじゃ？

**デフォルトの名無しさん** · 2016/10/19(水) 10:09:01.69

altJSでは、大規模開発では静的な、Haxe(ヘックス)。
Scalaのようなパターンマッチありの、switch

Rubyの代わりは、関数型言語Elixir。
Ruby + Rails + ErlangVM で、並行処理が得意

**デフォルトの名無しさん** · 2016/10/19(水) 15:06:28.19

静的は静的で、ライブラリをアップデートすると壊れる、
みたいなことが頻繁に起こるし、
安全な分と同じくらいそれを注意する気苦労がいる。

**デフォルトの名無しさん** · 2016/10/19(水) 18:35:13.38

静的型の信者じゃないけど、これじゃ同等とは言えないだろ
代数的データ型&パターンマッチだったら、こんなコードはコンパイルエラーだ

conn = ConnectionInfo.new(ConnectionState::Connecting.new(Time.new()),
IPAddr.new("128.0.0.1"))
if conn.connection_state.kind_of? ConnectionState::Connecting
p conn.connection_state.last_ping #=> ERROR!!!
end

**デフォルトの名無しさん** · 2016/10/19(水) 19:41:21.21

>>209
だから、作るものによって静的が向いてるものもあれば
動的が向いてるものもあるよな？って単純な話なんだけど
HelloWorldおじさんは違う意見みたい

**デフォルトの名無しさん** · 2016/10/19(水) 21:35:33.44

そうだよね。作るものによってというのが重要。

代数データ型が適している分野で例えばライブラリを作って終わりみたいな
仕事だと、差が出るかもしれないけど、実際にやった仕事（勉強とかではなく）で
代数データ型があったらなぁって思ったことある？

仮に有ったとしても全体のごく一部だけだろうね。
だから言語の違い程度でそんなに差は出ないっていうのは間違っていない。

**デフォルトの名無しさん** · 2016/10/19(水) 22:05:06.83

>>212
お前が差が出ないのを示せたのはHelloWorldだけだろw

**158** · 2016/10/19(水) 22:29:30.29

>>202
あのぉ代数的データ型君よ、ナゼ>>173のリンク先文書の中から
わざわざそのパラグラフを引用して静的型付けの利点だとドヤ顔してるの？
そこは(「静的型付け」ではなく)正に「代数的データ型」の利点だ
どうやら代数的データ型君は、静的型付けと代数的データ型との違いも分からず
ごっちゃに理解して分かったつもりでいることを自らゲロっちゃったみたいだね

というか、そもそも「不変条件」にしても分かっていないんじゃないの？
だからアサーションを「いわゆるテストの一種」などと書いてしまうんだろな
何度も繰り返すけど、代数的データ型と静的型付け(or 型システム or 型推論)の
利点は異なるし、それらをごっちゃにして議論を進めるべきではない

たとえば、完全な型システムを備えた静的型付け関数型言語 OCaml であってすら、
代数的データ型を用いずにネットワークコネクション状態管理を定義すると
(>>173文書の type connection_state = | Connecting | Connected … で始まるコード)、

　{state: Disconnected, last_ping_id: 100, …(中略)… }

というコネクション情報値を表すコードに対して、OCamlコンパイラは
以下の要求仕様に含まれる不変条件に違反しているというエラーを検出できない

　> * last_ping_time と last_ping_id は keep-alive プロトコルの一部として使われます。
　>　　　…(中略)…
　>　またこれらは state が Connected の時にのみ存在します。

だから代数的データ型を使いましょうね、って言うのが>>202が引用したパラグラフで
>>173リンク先文書の著者が読者に伝えたかった主旨であって、静的型付けとは無関係なのよ
さあ>>202の代数的データ型君よ、これで代数的データ型の利点は理解できたかね？

**デフォルトの名無しさん** · 2016/10/19(水) 22:33:50.18

>>214
それは代数的データ型の利点じゃないな。
代数的データ型を使うという手段が目的となっていて
その手段を使おうとすると問題が発生する。

自ら苦行の道を進んで、苦しいのが解決したという
つまりマイナスがゼロになっただけなのに、
（マイナスの状態から）増えたという変化の一部しか見てない。

**158** · 2016/10/19(水) 22:43:15.12

>>206
>>198で書いたけど、代数的データ型君は代数的データ型に関して
無知だということに気付いたけど、その事実を認めたくないんだろね
だから>>211みたいに、代数的データ型の議論を「静的 vs. 動的」という
対決構図へすり替えようと必死なんだと思われ

**デフォルトの名無しさん** · 2016/10/19(水) 22:53:00.17

そもそもこいつは、フレームワーク無しの素のRubyでHelloWorld書くのと、同じように素のPHPでHelloWorld書くのでPHPの方が楽だって認めてるんだろ
それこそ「言語による効率の違い」だろ

フレームワーク使えば同じになるって、そりゃ「言語の違いをフレームワークが吸収した」って言うんだよ

**デフォルトの名無しさん** · 2016/10/19(水) 23:11:26.37

>>217
吸収してしまって、その違いが些細なものとなってしまったわけですよね？

**デフォルトの名無しさん** · 2016/10/19(水) 23:17:47.00

>>188
そのアンカーは>186のが相応しそうだが

**デフォルトの名無しさん** · 2016/10/19(水) 23:23:44.73

>>214
そんなゴタクはいいから、さっさと>>210みたいなコードが書けないrubyの例を見せて下さいよ
それともC1カバレッジのテストでもやるの？

**デフォルトの名無しさん** · 2016/10/19(水) 23:26:44.07

コード書くとボロが出ちゃうから、またコード書かずに長文書く書くマンに逆戻りかな？w

**158** · 2016/10/20(木) 00:41:54.83

>>220,221(ID: kMzukS4D)
>>216でも書いたけど、ホントに代数的データ君は議論の焦点を
代数的データ型から静的/動的へすり替えようと必死だねえ
ねえ、どうしてそんなに必死なの？

>>210氏の指摘は代数的データ型に関するものではなくて、
型付けが静的/動的という違いに起因するもの
動的型付け言語であり、言い換えると型システムを持たないRubyでは、
パターンマッチの網羅性に相当する型エラーをコンパイル時には検出できない
繰り返すけど、こんな静的/動的の話はこのスレの住人であれば当たり前だよな？

ただし実行中であれば動的に型検査できる
特にRubyであれば簡潔にコードとして表現できる
コードは代数的データ型の議論が終結したら示すよ

で、代数的データ型君は代数的データ型について理解できたのかな？

**デフォルトの名無しさん** · 2016/10/20(木) 01:09:47.56

＞特にRubyであれば簡潔にコードとして表現できる

簡潔に表現したコードなんて出てなくね？OCamlに比べたら冗長でしょ

**デフォルトの名無しさん** · 2016/10/20(木) 02:29:07.30

OCamlがスッキリ書けるのは
普通はあまりやらないような特殊な用途だけで
COBOLと同じようなDSLと思えばいい。

嘘だと思うのなら、今までの人生で勉強以外で
OCamlで書いたコードを言ってみたら良いよ。
言えないか、ある種の自慢話（俺こんな高度なことしたんだぜ(笑)）のような
どこで使うのは全くわからない話をするしかないだろう。

**デフォルトの名無しさん** · 2016/10/20(木) 03:21:02.12

簡潔じゃないものを簡潔だと言ってるから違うと言っただけだけど？
まあ書いた本人も冗長と認めたっぽいから良いか
流石にアレを簡潔はないよな～

**デフォルトの名無しさん** · 2016/10/20(木) 07:14:57.75

>>218
服を着るようになったから人間に肌の色の違いはない
って言ってる？馬鹿なの？

**デフォルトの名無しさん** · 2016/10/20(木) 09:18:03.49

>>226
例えが意味不明

**デフォルトの名無しさん** · 2016/10/20(木) 13:34:29.50

>>224
>>27みたいな仕事はお前から見たら特殊な用途だと思うけど、
それでも生産性に差は無いんじゃなかったっけ？
それとも用途によっては差が出るに意見を変えたの？

**デフォルトの名無しさん** · 2016/10/20(木) 20:52:40.32

>>228
俺は差が0とは言ってないよ。殆どないと言ってる。
殆ど無いという理由は、大きな全体があってその一部だけしか差がないから。

ベンチマークの話に例えよう。俺が使っているクラスライブラリがバージョンアップして
「○○クラスのオブジェクトのインスタンス生成が100倍速くなりました。」と書いてあったとしよう。
これで俺のアプリが100倍速くなる！・・・なんてことはいわない。
当たり前だよな。○○クラスのオブジェウトのインスタンスを何個生成するかによって変わるんだから。
一回のインスタンス生成にかかる時間が100マイクロ秒から1マイクロ秒に速くなった。
たしかに100倍だがそのオブジェクトを1000個しか作らないなら100ミリ秒が1ミリ秒になるだけ。

生産性もそれと同じ。特殊な用途であることは誰も否定しないだろう。
（先に俺が言った「嘘だと思うのなら、今までの人生で勉強以外でOCamlで
書いたコードを言ってみたら良いよ」に答えてないのがその証拠）

特殊な用途というのは使われる機会が少ない。プロジェクト全体のごくわずか。
だからそんなものは生産性に大きな差を与えるものにはならない。

「特殊な用途」がプロジェクトの殆どを占めることだってあるかもしれないだろ
みたいな話はいらんからね。そんな言い訳する代わりに「今までの人生で（略）」に
答えればいいだけなのに答えないって、こ・と・はぁ～って思うだけだから。

**デフォルトの名無しさん** · 2016/10/20(木) 21:30:03.25

HelloWorldが仕事の大部分を占めればそうなるわな

**デフォルトの名無しさん** · 2016/10/20(木) 21:33:15.39

普通の人に仕事の大半がそうだろうなｗ

「今までの人生で（略）」

**デフォルトの名無しさん** · 2016/10/20(木) 23:18:09.29

>>227
どんな言語でもフレームワークを使えば同じように書けるから言語による差はない
って言ってる？馬鹿なの？

**デフォルトの名無しさん** · 2016/10/20(木) 23:58:59.82

前提も頭も狂ってるから結論もおかしくなってることに気づかないバカ

**デフォルトの名無しさん** · 2016/10/21(金) 00:01:07.08

>>232
差がないのは言語による開発効率ね。
言語に違いは有っても開発効率に大きな差はない。

**デフォルトの名無しさん** · 2016/10/21(金) 10:41:13.06

>>229
コード書けないHelloWorld長文おじさん

**デフォルトの名無しさん** · 2016/10/21(金) 18:09:04.13

>>234不正解

理論上は開発効率に大きな差があるが
現実は下請けに回ってきた時点で言語や環境が決められているか
既に決まってスタートしているので考える余地がない
が正解

**デフォルトの名無しさん** · 2016/10/21(金) 22:13:42.38

下請けの反対は元諸けと思うが
元請けとか上流になるにつれて言語は使わなくなっていくはずだが？

UIとかウェブアプリのフロントエンドとか
エンドユーザーに近いものほど、汎用的なものを使って
一般的なやり方ができるので言語の違いの差は出てこなくなる。

言語の違いだけで、大きく開発工数が変わるとしたら
むしろ下請けというか特殊なライブラリだけを作っているようなところだよ。
大企業から頼まれてある機械の部品を専用に作る町工場みたいな。

ただ今時そんなことだけやってるような会社あるかな？
ハードと違って一回作れば終わりだもんね。仕事が見つからないだろう。

**デフォルトの名無しさん** · 2016/10/21(金) 23:36:53.11

このドカタには内製って発想がないのかな？
>>27を読んでフツー多重下請けの話だと思うか？

**デフォルトの名無しさん** · 2016/10/21(金) 23:42:21.89

>>237
上流になるほど「安い人を大量に集められる言語」って基準で選ぶんだよ
そこに開発効率なんて言葉はない

**デフォルトの名無しさん** · 2016/10/21(金) 23:45:48.48

あと、上流は１つだけの下請けに出すわけじゃないからね
複数の下請けに出すことの方が多いから、余計に「安い奴隷を集められる言語」に行く可能性は高い
どっかの下請けが夜逃げしたとしてもすぐに補充がきくようにね

**デフォルトの名無しさん** · 2016/10/21(金) 23:50:54.50

かつての日本は研修以外ではコード書かなくてもSEとかなれましたから。
今はどうなのかな。

**デフォルトの名無しさん** · 2016/10/21(金) 23:52:16.03

>>241
今もそうだよ

ただ、SI一辺倒だった時代ではなくなってきてるので、比率は下がってきてるけどね

**デフォルトの名無しさん** · 2016/10/22(土) 00:06:02.54

SEなんて属人化をひたすら廃することでリスクマネジメントができてるとか勘違いしてる連中だからな
だから安い奴隷を使えるようにする方向に動くんだよな
その方がリスクが少ないと思い込んでるから

本当はプログラミングなんて職人芸のカタマリで、上位の職人は奴隷の何百倍の開発効率を叩き出す
ことを知らないんだよな
そういう職人を数人高待遇で雇えば奴隷なんて要らないのに…

**デフォルトの名無しさん** · 2016/10/22(土) 00:20:16.83

コードを書かない人間をクビにする作業が忙しくてコードを書けないんだろ
武器を持った人間を捕まえる仕事のために武器を持つことが許されるみたいな感じ

**デフォルトの名無しさん** · 2016/10/22(土) 01:52:25.03

>>239
俺は元請けは言語使わないって言ってるんだよ。
その俺に元請けは安い人を探すっていわれたって、
えぇ、だから言語使わないでしょ？としか言うことがない。

**デフォルトの名無しさん** · 2016/10/22(土) 01:54:01.83

>>245
使わないだろうけど決定はする
そこに開発効率なんて基準は入らない
奴隷がいかに集められるか、ということだけが基準となる

**デフォルトの名無しさん** · 2016/10/22(土) 01:56:24.28

だからなんで俺にそれをレスするんだよ？

反論してないのに反論している風な空気出すなってｗ

**デフォルトの名無しさん** · 2016/10/22(土) 01:58:10.15

>>247
下請けには言語の決定権なんてない、という>>236の意見に賛同している

**デフォルトの名無しさん** · 2016/10/22(土) 02:08:31.54

下請けに決定権がないのが、言語の違いで開発効率に差があることの根拠？
何を言ってるのかさっぱりわからない。

**デフォルトの名無しさん** · 2016/10/22(土) 02:11:53.22

>>249
言語による開発効率なんて意味がないということ
所詮は開発効率なんて何も考えてない上流が決めることなんだから
大事なのは奴隷をいかに集められるかということだけ

**デフォルトの名無しさん** · 2016/10/22(土) 02:17:59.04

言語の違いで開発効率に大きな差がない上に、
その僅かの差は人を増やすことで解決できる問題でしかない。

それが俺の意見とだれかさんの意見をまとめた答えだよ。

**デフォルトの名無しさん** · 2016/10/22(土) 02:20:08.08

>>251
そういう人月神話を信奉した結果が現状の日本のSI業界の悲劇的状況なんだけどね
プログラミングは属人性が恐ろしく高い世界だという現実にいつ気づくのだろうか

【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ55【php,py,pl,rb】 [無断転載禁止]©2ch.net

【JavaScript】ｽｸﾘﾌﾟﾄﾊﾞﾄﾙﾛﾜｲﾔﾙ55【php,py,pl,rb】 [無断転載禁止]©2ch.net