【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/02(日) 00:47:01.83

スクリプト言語とスクリプトではない言語を分ける定義ってあるのかな

**デフォルトの名無しさん** · 2016/10/02(日) 00:55:03.29

前スレ>>996
> 確かに実用的には言語自体にそれほど大きな差はないかもしれないが、
だからそう言ってるじゃん。

> コミュニティやエコシステムが発展していく上で人々の「好み」というのが非常に重要である以上、
> 言語の差には大きな影響力があるんだよ。
だからそれは生産性の差じゃない。好みの差。利用者の多さとかそういうもの

前スレ>>999
> ていうかもっとそもそも論を言えば python のコードは英文に近くて読み易い。
どこが？理系に馴染みやすい数式に近いものが英文になるわけないよｗ

> python の半ば強引なアンダースコア(英文の空白など区切り文字全般に該当する)だらけのコードは時に英文そのものになっている場合がある。
this_is_a_pen みたいな？ｗ
それは変数名をそうつければ、どの言語でも同じことだろ。

ていうか英文そのものというのはCOBOLみたいなものを指すんだが。
冗長で読みにくい。

**デフォルトの名無しさん** · 2016/10/02(日) 02:56:43.85

Javaの命名規則はviやメモ帳には克服できない

**デフォルトの名無しさん** · 2016/10/02(日) 06:08:51.15

言語で生産性に差は生じないクン
似たり寄ったりのメジャーな言語やよく見かける案件に限定にして
さらに念入りに差を生じさせる要素を都合よく排除してったら
そりゃ差はなくなるのは当たり前だって、いつ気づくんだ？

**デフォルトの名無しさん** · 2016/10/02(日) 08:24:13.37

いいじゃんそれで
そろそろ人間は楽していくべきだよ

**デフォルトの名無しさん** · 2016/10/02(日) 09:26:07.58

これからはAIがプログラミングし改善し続けるからプログラマーがオワコンなのは確定してる

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

>>5
はい。言語によって生産性はないという
当たり前のことを言っていますよ？

理由はあんたが言うように、フレームワークやライブラリによって
差を生じさせる要素が排除されてるからです。

**デフォルトの名無しさん** · 2016/10/02(日) 10:45:41.11

差はないわけはないが、それよりは好き嫌いとあモチベによる差の方がはるかに大きいよね
この後者の部分を無視して、「差がないんだったら安い奴隷をいっぱい集められるJavaかPHPに
しよう」とか無能経営者が考えてしまうとモチベどん底のデスマのはじまりはじまりーと

**デフォルトの名無しさん** · 2016/10/02(日) 10:53:21.03

言語に差があるからそこに集まるフレームワークやライブラリに差ができるんだけど
差がないとか本気で言ってるっぽいところがイタい人達

**デフォルトの名無しさん** · 2016/10/02(日) 11:27:02.29

>>10
だから今は、そのフレームワークやライブラリの有り無しで生産性が変わるのだから、
フレームワークやライブラリのある無しで使う言語を決めるべきって話。

言語を先に考える時代は終わった。生産性の要である
フレームワークやライブラリで選ぶべき。言語はどれでもよい。

**デフォルトの名無しさん** · 2016/10/02(日) 12:01:38.62

>>11
どれでもよいはかなり語弊があるな
生産性ではなく、他の要素で選ぶべきぐらいじゃないとね

**デフォルトの名無しさん** · 2016/10/02(日) 12:17:23.58

>>12
言語では大きな差は出ないって答えなら
どっちでもいいよｗ

**デフォルトの名無しさん** · 2016/10/02(日) 12:22:40.79

誰でもできるドカタ仕事では言語の差は出ないよ

**デフォルトの名無しさん** · 2016/10/02(日) 12:29:05.37

じゃあドカタ仕事じゃないものの例を言ってみなさいよｗ

**デフォルトの名無しさん** · 2016/10/02(日) 13:31:20.00

>>13
どっちでもはよくない
「なんでもいい」と「別に選ぶ基準がある」はまったく違うから

なんでもいいだとそれこそ無能経営者の発言になってしまう

**デフォルトの名無しさん** · 2016/10/02(日) 13:37:57.86

>>16
日本語が間違ってるぞｗ

「なんでもいい」っていうのは言語の話で
「どっちでもいい」は、他の要素で選んでも構わない
　（「言語によって差はない」には反してないから）
っていう話だ。

**デフォルトの名無しさん** · 2016/10/02(日) 13:59:36.22

>>17
「どっちでもいい」じゃなくて「どれでもいい」だろ
人の言葉尻を捉えてとやかく言うなら自分の発言した内容ぐらいちゃんとコピーしろよ

**デフォルトの名無しさん** · 2016/10/02(日) 14:03:14.13

ドカタは関数型言語とか難しくて使いこなせないじゃん？バカだから

よって言語はどれでも良いってことは無い

**デフォルトの名無しさん** · 2016/10/02(日) 14:22:12.38

>>18
だから言語はどれでも良いって言ったけど？

**デフォルトの名無しさん** · 2016/10/02(日) 14:23:14.18

>>20
>>17 では「どっちでもいい」って書いてるけど？

**デフォルトの名無しさん** · 2016/10/02(日) 14:24:34.01

>>21
どっちでもいいって言ったのは言語じゃなくて
選ぶ理由だけど？

（言語に差がないからどれでもいい。言語以外を選ぶ理由にするなら）
どっちでもいい。

**デフォルトの名無しさん** · 2016/10/02(日) 14:25:41.21

>>22
差がないのは生産性だけで、他にも選択に必要な要素は山ほどあるよね？
それを「生産性」という言葉をすっぽり抜かしてしまったら、伝わるものも伝わらないよね？

**デフォルトの名無しさん** · 2016/10/02(日) 14:28:02.95

>>23
だから俺は言語によって生産性に大きな差はないって
言ってるだけだけど？

誰も
とあるフレームワークがあるから○○言語を選ぶ
とあるライブラリがあるから○○言語を選ぶ
人を集めやすいから○○言語を選ぶ
のを否定したりしてませんってｗｗｗ

否定しているのはただ一つ
「○○言語は生産性が高いから○○言語を選ぶ」だけ
言語によって大きな差は生まれないのでこれはありえない。

**デフォルトの名無しさん** · 2016/10/02(日) 14:29:57.11

>>24
だったら「生産性」という言葉はあらゆるレスで抜かしてはいけないはずなんだが
「生産性」というごく狭い部分にフォーカスした発言ですよ、ってのは君の論理の
最重要な前提だよね

**デフォルトの名無しさん** · 2016/10/02(日) 14:31:54.61

>>25
あらゆるレスって「日本語間違ってるぞお前」みたいな
ものにはいらんだろｗｗｗ

で、どのレスに入れてほしかったのさ？
大抵入ってるはずだが？

**デフォルトの名無しさん** · 2016/10/02(日) 14:35:35.91

>>24
代数的データ型があるからOCaml（関数型言語）を選ぶ
っていうのが実際に金融業界ではあるんですよ
ちゃんと言語で選んでますよ？
http://d.hatena.ne.jp/camlspotter/touch/20131209/1386582276

**デフォルトの名無しさん** · 2016/10/02(日) 15:22:55.96

なぜ言語間に差がない等という明らかに現実を無視した主張をするのか
その理由は一つ
「バカ専用言語」という烙印を押されたPHPを使うペチパー達が
そのイメージを払拭しようと宣伝活動をしているにすぎない
そのおバカな活動が余計に「バカ専用」のイメージに拍車をかけている事も知らずに

**デフォルトの名無しさん** · 2016/10/02(日) 15:28:29.58

web系って何故あんなに低脳が集まるんだろうか

**デフォルトの名無しさん** · 2016/10/02(日) 15:59:38.76

低能でもできるものに有能を集める必要はないだろう

**デフォルトの名無しさん** · 2016/10/02(日) 16:19:08.68

>>28
なら君、PHPで○○ヶ月掛かる仕事を
その半分でやってみせますとか言ってみたら？

半分が多すぎるなら減らしてもいいけど、
君ならどんくらい減らす？

**デフォルトの名無しさん** · 2016/10/02(日) 16:29:42.70

>>31
その質問に意味があると思ってるところがペチパーの怖ろしさ

**デフォルトの名無しさん** · 2016/10/02(日) 16:33:51.55

>>32
やっぱり言語を変えるだけでは減らせないのね？ｗ

**デフォルトの名無しさん** · 2016/10/02(日) 16:37:53.24

>>33
何がやっぱりなんだよ俺は「その質問に意味はない」と言ってるのだが
どこからその結論を読みとってきたんだお前

**デフォルトの名無しさん** · 2016/10/02(日) 16:39:00.24

意味がない理由を書いてない時点で、
どう取られても構わないって言ってるようなもんなんだがｗ

**デフォルトの名無しさん** · 2016/10/02(日) 16:43:15.80

>>35
理由を言わない→どう取られても構わない
なぜこうなるのか？
ペチパーには論理的な思考の推移というものが存在しないのか？

**デフォルトの名無しさん** · 2016/10/02(日) 17:01:08.28

じゃあ言って見れば？

**デフォルトの名無しさん** · 2016/10/02(日) 17:03:02.53

>>37
は？何を？
思考が飛躍しすぎでお前とは普通の会話ができん

**デフォルトの名無しさん** · 2016/10/02(日) 22:15:23.86

ここまでのレス数39のうち、書き込んだ人間は何人なんだろう

**デフォルトの名無しさん** · 2016/10/02(日) 22:18:27.31

>>38
なんで意味が無いのかだよ。
>>32でお前言ったろ？その質問には意味がない（ドーン！）って

えとね、反論するときはちゃんと理由をいわないと意味がないの。
誰かが何か意見を言った時、
「それは違う（ドーン！）」って言うだけじゃ違うって認められないんだよ。
そんなんで反論として認められるならば、
なんでも通用するわｗ

「これだけの証拠が有るからあなたが犯人です」
「それは違う（ドーン！）」
この一言で覆るかよｗ

**デフォルトの名無しさん** · 2016/10/02(日) 23:53:31.54

一人の可能性も考慮していけ

**デフォルトの名無しさん** · 2016/10/03(月) 22:33:47.03

似たようなフレームワークで解決する案件に限定して
似たようなフレームワークを書ける言語を選択肢に絞れば
言語間で生産性に差はなくなるのは当たり前

現実にはその程度のフレームワークで解決しない案件も
その問題領域を効率よく記述可能な言語も多種多様に存在するわけだから
状況によって言語の生産性に差はあるに決まっている

**デフォルトの名無しさん** · 2016/10/04(火) 00:22:58.47

>>42
その状況っていうのは、
「その問題領域を効率よく記述可能な言語」ではなく
「その問題領域を効率よく記述可能なライブラリ」があるかないかで
決まることだろ？

**デフォルトの名無しさん** · 2016/10/04(火) 00:45:11.34

その問題領域を効率よく記述可能なライブラリを書けるのが
特定の言語に限られるケースがあるって話だろ

**デフォルトの名無しさん** · 2016/10/04(火) 01:27:22.78

その問題領域ってなによ？

例えば機械学習とかのライブラリはC言語で作れていることが多い。

**デフォルトの名無しさん** · 2016/10/04(火) 08:11:58.86

>>45
>>27とか

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

>>46
それはライブラリを使うことを前提として
開発工数に差が出るほどのものではない。

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

>>47
差がない理由を言ってないから全く意味のないレスだな

>>27のリンク先は実際に仕事で使ってる人間が
具体的な理由付きで言語で選んるって言ってんだから
全く勝負にならない

**デフォルトの名無しさん** · 2016/10/04(火) 11:09:45.49

ID:A7Nl1eL6 はとりあえず >>27 を見ろよ

**デフォルトの名無しさん** · 2016/10/04(火) 21:01:19.59

>>48
差が出ない理由は実際にコード書いてみればわかると思うけどさ、
ようするに、フレームワークやライブラリによって
その利用者が書かなければいけないコードが最小限になるからだよ。

言語の違いによって書くべきものに違いはあるだろうけど、
何かを実現するときに足りないコードっていうのはどれもかわらない。

例えばウェブアプリで画面にhello worldを表示するっていうものがあれば、
PHPに比べて素のRubyだけでやろうとしたら膨大なコードを書かないといけないけど
そこにRailsが加わればたったコレだけ。

class HelloController < ApplicationController
　def index
　　render :text => "Hello, world!"
　end
end

Rails.application.routes.draw do
　root 'hello#index'
end

このように実現するときに足りないコードっていうのは、Hello worldを表示するという関数と
そこにたどり着くためのルーティングの設定。どの言語を使ってもこの必要最小限のコードに落ち着く。
この例はフレームワークだけど、ライブラリでも同じ。言語が違っても同じ引数・同じ戻り値の
ライブラリは作れるだろうからライブラリの中身が違っても、それを使う側は変わらない。

実現するためのコードは違っても、フレームワーク・ライブラリの利用者が書かなければいけないものは
結局のところ同じなので、どの言語でもこの必要最小限ですむものを作ることができる。

結果、どの言語でも書くべきコードは必要最小限のコードで対して変わらないので
言語の違い程度で工数に大きな差は出ないことになる。フレームワークやライブラリが吸収してしまう。

**デフォルトの名無しさん** · 2016/10/04(火) 21:02:48.74

よし、差がない理由を言ったから反論待ちだなｗ

どうせ言えないと思っていただろう？ｗ

**デフォルトの名無しさん** · 2016/10/04(火) 21:03:48.66

多分、フレームワークやライブラリで片がつく程度の仕事しかしてこなかったんだろうな
でなければ >>27 にちゃんと反論するもんな

**デフォルトの名無しさん** · 2016/10/04(火) 21:11:16.99

そもそも>>27にはOCamlによって開発工数が減ったとは
書いてないので、反論する必要もないんだよ。

**デフォルトの名無しさん** · 2016/10/04(火) 21:16:18.10

せやな、例えばここなんかどうだ？サンプルがあるぞ。
http://www.geocities.jp/m_hiroi/func/ocaml.html

この中で（別の場所でも良いけど）OCamlで書いたらこんなに短いけど、
他の言語では長くなるっていう例でも言ってみてくれ。

もちろんフレームワークやライブラリを使うのは有りだ。
（だってそもそもフレームワークやライブラリがあるから
言語による開発工数の差はほとんど無くなると言っているのだからね）

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

>>53
> 事実、この言語化によるパワー、金融商品の代数的表現を使って LexiFi はデリバティブのモデル化、
> 評価、マネージメントなどの高度なシステムを少人数、短期間で開発し、現在に至っている。

あれ？書いてますけど？

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

>>55
それは比較じゃない。少人数・短期間で開発というのは
どんなフレームワークでも謳い文句にしている。

**デフォルトの名無しさん** · 2016/10/04(火) 21:44:39.54

>>56
選んだということは、比較して決めたということでしょ

**デフォルトの名無しさん** · 2016/10/04(火) 21:48:12.77

比較して選ぶ理由は開発工数以外にもある

**デフォルトの名無しさん** · 2016/10/04(火) 22:01:00.43

比較して選んだ結果、少人数、短期間で開発しと書いてるんだから、開発工数が選んだ理由でしょ

**デフォルトの名無しさん** · 2016/10/04(火) 23:06:28.39

まさかhello world書いて言語の生産性に差が無いと言い出すとは
斜め上の展開に失笑を禁じ得ない
そりゃhello worldじゃ差は無いでしょうよw

**デフォルトの名無しさん** · 2016/10/05(水) 01:57:03.61

じゃあ、それ以外のネタいいなよ。
お前が差があるものをもってくりゃいいんだよ。

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

でも数ヶ月の差がでるような極端な例じゃないと差があるとは認めないんでしょう？
前提がそうなら「差はない」わな

そもそもフレームワークやライブラリの影響と言語の差の影響を比較する行為が一人相撲だといつになったら気が付くんだろうか。
言語で差はあると言っている人達はそんな話はしていない

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

生産性に差がないクンは、たんにHelloWorldに差がないという主張だったというオチか
しかもOCamlはおろか代数的データ型等のRubyにない機能はろくすっぽ分かってない悪寒

**デフォルトの名無しさん** · 2016/10/05(水) 07:36:53.16

都合の悪い部分は無視か屁理屈だもんな
で、粘着したもん勝ちを地で行ってるだけだから

こういうのはもう相手しない方がいいよ

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

といって差が出る例を言わないのを
ごまかすのであった（笑）

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

はやくHelloWorld書く仕事に戻れよ低脳

**デフォルトの名無しさん** · 2016/10/05(水) 11:30:50.07

HelloWorldでお金もらえるのか
うらやましい

**デフォルトの名無しさん** · 2016/10/05(水) 12:17:28.77

このスレの雑魚率は異常

**デフォルトの名無しさん** · 2016/10/05(水) 17:00:17.35

<div id="Aid" class="Bclass">XXXXX</div>

というのがあったとき、
document.getElementById("Aid").innerHTML = "";
とすると、
<div id="Aid" class="Bclass"></div>
となりますが、このclass="Bclass"というのも削除して
<div id="Aid"></div>
だけには出来ませんか

greasemonkeyを使っていて、これが残っていると枠が残ってしまいます

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

ちなみに、classList.removeを使うと、classは削除されますが、

<div id="Aid" class=""></div>
となります。class=""は取れませんか

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

ここはHelloWorldの生産性を議論するスレです

**デフォルトの名無しさん** · 2016/10/06(木) 21:51:00.18

>69
そもそもclass=""を消したいのは何故？
それで何か変化あるのかな…？

無理矢理消すなら
<div id="Aparent"><div id="Aid" class="Bclass">xxxx</div></div>
にしちゃって、AparentのinnerHTMLを変更するのじゃダメかい？

**デフォルトの名無しさん** · 2016/10/06(木) 23:25:28.00

HelloWorldって馬鹿にされて恥かいたからって
クソ下らんネタで話逸らすの良くないぞ

**デフォルトの名無しさん** · 2016/10/06(木) 23:29:34.28

まあ実際ペチパーの仕事はHello, worldと大差ないのばかりだからなw

**デフォルトの名無しさん** · 2016/10/07(金) 01:42:56.68

いい加減出てこいよ。
Hello Worldって言ってるだろ。
無視すんな

**デフォルトの名無しさん** · 2016/10/07(金) 03:31:19.20

ちっHello Wolrd野郎は逃げたか。
腰抜けだな

**デフォルトの名無しさん** · 2016/10/07(金) 17:35:11.73

お前ら、あんまり Hello World を馬鹿にすんな
世の中には、バージョンアップしただけで Hello World が
動かなくなる後方互換性を完全無視したスクリプト言語もあるんだぞ

http://echo.2ch.net/test/read.cgi/tech/1413113999/128/

**デフォルトの名無しさん** · 2016/10/08(土) 07:43:03.70

>>69
removeAttribute じゃだめかい？

**デフォルトの名無しさん** · 2016/10/09(日) 14:29:52.33

つかもうスクリプトの時代は終わったよね
結局はC/C++、JAVA、C#、Swiftがそれぞれの利用シーンで使われ、辛うじてPythonが生き残ってる感じ
俺なら今はC#を推すね、ゲーム開発でも人気あるしさ

**デフォルトの名無しさん** · 2016/10/09(日) 17:47:56.67

>>54
問題領域に対する有用なフレームワークやライブラリが特定の言語でしか整備されていなければ開発工数の差になると思うわけだが。
ディープラーニングやろうってときにスレタイの言語の中で Python 以外を選ぶ馬鹿はいないだろ。

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

ところで >>50 の意味がわからないのだが。ウェブページとして Hello world を表示するだけなら ruby でもフレームワーク無しでこれでよいのでは？

#!/usr/bin/ruby
print "Content-Type: text/html\n\n"
print "Hello, world!"

少なくとも俺の Apache の環境では mod_cgi を有効にしてこれで動いた。

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

>>80
自分はJSでやってる。
ディープラーニングって手段であって、
することに合わせた細かい調整やノウハウが重要
まだ発展途上でどの言語でも整備されてるとは言えないので言語は関係ない。

よくあるライブラリは結局皆がもう何度も試したようなことにしか使えない。
自分は２年目から素フレームワークと自作ライブラリに切り替えた。
エンコーダとかだとビジュアルも重要だし、モバイルから進捗を見るのなどにもWebが便利だしね。

**デフォルトの名無しさん** · 2016/10/09(日) 20:12:48.40

>>82
back propagationとかどうしてんの？自動微分のライブラリも自作してんの？
まさかシコシコ自分で偏微分をコーディングしてるとか無いよね？

**デフォルトの名無しさん** · 2016/10/10(月) 02:01:40.76

ど素人が知ったかぶりした挙句に
ツッコまれて逃亡するのを
何度このスレで見た事だろう

**デフォルトの名無しさん** · 2016/10/10(月) 04:58:00.52

素人の間では、AIはデータが命でありプログラムの時代は終わったとされている

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

なんでJSでディープラーニングやってるなんて嘘つくんだろう
JSerはwebドカタである事にコンプレックスでもあるの？

**デフォルトの名無しさん** · 2016/10/10(月) 10:47:43.46

色々な説がある
科学が好きすぎて道徳を信じない説
なぜ嘘をついてはいけないのか科学的証拠を出せ

**デフォルトの名無しさん** · 2016/10/10(月) 11:32:27.81

JSerが無知でバカで嘘つきってことは周知の事実だから
いまさら嘘つきってバレても失うものは無いってことかな？

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

>>83
自分は所謂日曜プログラマ。仕事は一切関係ない。
なのでDLは手段と書いたがシコシコする事自体が目的というのも半分。
技術自体に興味があるし、論文読んで自分なりに取り入れてみたりする行為が一番好き。

他にも例えば最近JSに入ったSABやSIMDを使うライブラリは無い（無かった）
そういう最新の技術を使いたいという興味目的もあるし、
実際パフォーマンスを突き詰めたいのでそれに沿うように作り直すことになる。

あとゲームの評価関数等だと終わりが無い、最適解への道のりが遠いから
ずっと調整し続けないといけない。

**デフォルトの名無しさん** · 2016/10/10(月) 18:15:33.31

>>89
趣味なら好きにしたらいいけど

ただ自動微分もSIMDもCUDAもサポートしてるPythonのDLライブラリを使わず、
ちょっとネットワークの構造や深さや発火関数を変えるだけで
偏微分をシコシコ書き直してデバッグしてるのって
側から見るとバカみたいだから気を付けた方が良いよ

**デフォルトの名無しさん** · 2016/10/10(月) 18:27:03.69

いやまあ、Pythonじゃなくてもいいや、何か適当なライブラリは使った方が絶対良い
どうせDLの低レイヤーなんて行列演算なんだから

**デフォルトの名無しさん** · 2016/10/10(月) 20:04:08.54

まぁまぁ、日曜プログラマ程度なら使い慣れてる言語でちょこちょこ楽しむってのも
全然アリだと思うし、そこに対して教条的にPython使えって言われても宗教的怪しさを
感じるだけだと思うけどねー

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

>>80
> 問題領域に対する有用なフレームワークやライブラリが特定の言語でしか整備されていなければ開発工数の差になると思うわけだが。

フレームワークやライブラリが特定の言語でしか整備されていなければでしょｗ
特定の言語でしか整備できなければ、言語の差になるが、
特定の言語じゃなくても整備できるだろうね。

だからそれは言語の差ではなくて、フレームワークやライブラリの差

**デフォルトの名無しさん** · 2016/10/10(月) 23:06:13.08

>>81
それはHello World専用じゃんｗ
なんでお前Hello Wolrd専用の話をしてるの？

**デフォルトの名無しさん** · 2016/10/10(月) 23:07:22.01

ウェブフレームワークはいろいろやることがあるって話をしてるのに、
Hello Worldだけを表示するものを作って、
これだけできる！とか視野が狭いというかなんというか
本当にHello Worldしかできんのな。

**デフォルトの名無しさん** · 2016/10/11(火) 06:51:07.82

HelloWorldで生産性を語る君にいわれてもなぁ……

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

HelloWorldで生産性を語ってるのはあんたでは？

HelloWorldの例見て、これが全てだ！
よし、今からHelloWorld限定の話にしてやるぞって
思っちゃったんでしょ？ｗ

**デフォルトの名無しさん** · 2016/10/11(火) 09:08:09.78

どうせhello would以外何も書けないくせにw

**デフォルトの名無しさん** · 2016/10/11(火) 09:32:00.97

相変わらず前提がおかしいっていうか想像力が乏しいねぇ…苦笑
ところでHelloWroldクン代数的データ型の勉強はおわったのかな？ｗ

**デフォルトの名無しさん** · 2016/10/11(火) 19:28:27.31

>>79
C#ってどんなの？　特徴教えて
C++とは大分違うの？

**デフォルトの名無しさん** · 2016/10/11(火) 22:40:16.74

C#はゲームでのC++に置き換わる覇権言語

**デフォルトの名無しさん** · 2016/10/11(火) 22:48:15.84

C#はC++とはまるで違う
近いのはJava

Javaより後発だというのと、Microsoftお得意の後方互換性なにそれ？コンセプトによってJavaより
先進的な機能が色々取り込まれている
惜しむらくはWindowsでしかまともに動かないこと

**デフォルトの名無しさん** · 2016/10/11(火) 23:15:17.75

>>99
それで代数的データ型による差はどれくらいあんの？ｗ

**デフォルトの名無しさん** · 2016/10/11(火) 23:16:39.08

>>103
それすら知らんで「差はない」とか言ってたの？
差はないと言い切るからには当然知ってるはずだよね

**デフォルトの名無しさん** · 2016/10/11(火) 23:20:57.60

>>102
> 惜しむらくはWindowsでしかまともに動かないこと

iPhoneでC#アプリが審査に通るワケ
http://www.atmarkit.co.jp/news/200901/29/mono.html
> 　iPhone向けにC#で書かれたゲームが40本以上存在する――

もう7年も前からこんな状態なのに今頃何をいってんの？
あんたが言ってるまともに動かないっていうのはC#という言語じゃなくて
Windows向けのライブラリでしょ。

iPhone、Androidで動くゲームの多くがUnityを使って作られているがその言語はC#
そしてもう一つのクロスプラットフォームの開発環境のXamarinもC#

今の時代クロスプラットフォームで開発しようと思ったら、
JavaScriptかC#なんだが。

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

>>104
無いものを証明しろといわれても困るんだがｗ

差なんてどこを見てもないんだから
何も言えるわけがない。

これは悪魔の証明といわれている類の問題でね。
無いのに比べて有るほうを証明するのが簡単なんだから
有るということを証明しましょうって話。

**デフォルトの名無しさん** · 2016/10/11(火) 23:32:39.98

>>106
そもそもお前、代数的データ型が何か説明出来んの？って話よ
これは別に悪魔の証明じゃないぞw

**デフォルトの名無しさん** · 2016/10/11(火) 23:35:50.02

なんでわざわざ遠回りしてるんだ？

本題は開発効率に差があるかどうかだろ？
仮に俺が知らなかったとして、開発効率に差がある事にはならんのだが？

**デフォルトの名無しさん** · 2016/10/11(火) 23:42:50.22

>>108
知らなかったら差がないことも知らないだろ？
知ってるからこそ差がないことが言えるのに

**デフォルトの名無しさん** · 2016/10/11(火) 23:43:29.05

>>105
40本って…そんな誤差レベルの本数の話されてもね

**デフォルトの名無しさん** · 2016/10/11(火) 23:49:46.06

>>108
プログラマは、自分が基本的な知識と思ってる事すら知らない奴の言うことはハナっから信用しない
いくら言葉を重ねてもね

残念ながらそんなもんです

**デフォルトの名無しさん** · 2016/10/11(火) 23:52:42.58

>>109
お前、議論ってものが分かってないのか？

反論っていうのは、相手が知らない点、見落としている点を突くことなんだよ。
だから、穴があると思ったらそこを突っつけばいいじゃん？

なんで遠回りしてるんだ？って聞いたのは、
穴を見つけたはずなのに、それは穴ですか？って俺に聞いてるからだよ。

俺が穴ではありませんって言ったらお前諦めるわけ？
俺が穴ですっていったら、お前はそこで満足して諦めるわけ？

どっちにしろ、お前はその穴を突っつく。
つまり開発効率に差があることを指摘しないといけないんだから
さっさと指摘しろって言ってるわけ

**デフォルトの名無しさん** · 2016/10/11(火) 23:56:28.84

>>110
> 40本って…そんな誤差レベルの本数の話されてもね

7年前の話だぞｗ
今はゲーム開発で独占的な地位を築いている

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

>>112
簡単じゃん
お前はHello World以外のあらゆるシステムで開発効率に差が出ないと言ってるんだから
そうじゃない例もちゃんと知ってるんだよな？という確認をしてるだけじゃん

そうじゃなかったら「あらゆるシステム」の部分は誤りで、「俺の知ってる狭い範囲のシステムでは」
と言い換えなければいけない

な？簡単だろ？

**デフォルトの名無しさん** · 2016/10/12(水) 00:05:38.91

> そうじゃなかったら「あらゆるシステム」の部分は誤りで、「俺の知ってる狭い範囲のシステムでは」
> と言い換えなければいけない

やっぱり悪魔の証明じゃんｗ

っていうか「俺の知ってる範囲では無い」と言い換えた所で
お前の主張である「開発効率に差がある」は認められないって
分かってるかい？

お前がやってるのは裁判で追い詰められた弁護士が、
「あなたこの文書の存在を知っていますか？」
→ いいえ知りません
→ 「以上反論を終わります。」

って言ってるようなもんだぞｗ
それが何かをちゃんと説明しないとお前の主張は認められない。

神じゃないんだからさ、誰でも知らないこと（知ってるけどなｗ）があるのは当たり前。
「あなたは知らないことが有った！だから俺が正しいことになりませんかね？」
とか当たり前の結論を出して満足してるなよ。

さあ、お前のターンだ。さっさと開発効率に差があることを説明しろ。

**デフォルトの名無しさん** · 2016/10/12(水) 00:08:16.73

俺だったら、相手が知ってるかどうか確認せずに知らないと決めつけて、
「どうこういう理由で俺の主張が正しい！」って語るだろうなｗ

おそらく言えるほどの主張がないんだろうね。
だから「あなた知ってます・・・かね？」という
弱腰の確認からはじめる。

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

>>115
まーだ分かってないんだな
「お前の知らない範囲のシステム」については「お前は開発効率が変わらないことを知らないだろ？」
と言ってるんだよ

「俺の知らない範囲でもあらゆる範囲で俺の法則が適用できるんだ」なんて理論が通じるとでも思ってんの？

**デフォルトの名無しさん** · 2016/10/12(水) 00:11:52.16

>>117
俺が知らないっていうのなら、俺が知らないことを
言ってみなさいよｗ

俺が知らないことを指摘することは、
俺が間違っているということにはならのだよ？

>>107でそうお前も認めたしな。
> そもそもお前、代数的データ型が何か説明出来んの？って話よ
> これは別に悪魔の証明じゃないぞw

質問が「代数的データ型が何か説明出来んの？」に変わってる。
この質問は言語の違いで開発効率に差があるかどうかの話ではない。
だからどう答えても俺の主張に影響はない

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

>>118
代数型データを知らない以上、開発効率に差がでないなんて一言も言い切れないよな
つまり、お前の理論は間違い、それだけ

お前が代数型データを知っていて、それを使う範囲でも開発効率が変わらないと説明できるなら
お前の理論はその範囲では合ってると証明できる
つまり、証明義務はお前の方にあるんだよ

**デフォルトの名無しさん** · 2016/10/12(水) 05:06:31.01

>>102
なにいってるんだ？MicrosoftとかC#は後方互換を常に重視してるだろ
さすがに互換性のために利便性を捨てるJavaほどではないが、過去のソースやバイナリはほとんどの場合うごく
あれで後方互換無視って言ったら数えるほどしか言語残らんぞ

マルチプラットフォームもUnityに限ればかなりすごいぞ
パソコンから任天堂/ソニーゲーム機、スマホまでなんでも動く

ポケモンGoとかもそうだ

**デフォルトの名無しさん** · 2016/10/12(水) 06:17:04.66

>>120
＞　C#は後方互換

じゃあ、C++のコードは動くの？　開発言語の後方互換ってそういうことだよね
C#の前はJavaなのか。　なら、Javaは動く？

**デフォルトの名無しさん** · 2016/10/12(水) 06:37:27.85

>じゃあ、C++のコードは動くの？　開発言語の後方互換ってそういうことだよね

そんな解釈してる奴見たことねぇｗ

**デフォルトの名無しさん** · 2016/10/12(水) 07:01:10.41

>>93

>フレームワークやライブラリが特定の言語でしか整備されていなければでしょｗ

現実に、今は特定の言語でしか整備されていない。
現在の状況における現実的な議論としては、言語の差かフレームワークの差かはともかく、言語選択によって開発工数に差が出ることは事実。

>特定の言語でしか整備できなければ、言語の差になるが、
>特定の言語じゃなくても整備できるだろうね。
>だからそれは言語の差ではなくて、フレームワークやライブラリの差

「整備できるだろう」という憶測だけで理由が一切示されないまま、直後に「だから」と繋げて結論を断定して終わる論理展開はおかしい。

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

特定の言語でしか整備されていないフレームワーク目当てで
言語を選ぶんでしょ？

それはフレームワークの選択であって
言語は仕方なく決まっただけだよｗ

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

そのフレームワークを書いた人間は言語で選んでるんですけど

フレームワークが勝手に生えてくるとでも思ってんの？

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

ある種のフレームワークを書こうと思った時、特定の言語機能（例: 代数的データ型）があるかどうかで
書きやすさが全然違うんだよね

**デフォルトの名無しさん** · 2016/10/12(水) 13:08:44.84

>>121
ネタか釣りだと思うが、初心者が間違えるとかわいそうなのでマジレスするとそれは後方互換じゃない

後方互換は同じ言語の前のバージョンと互換性のあること
C#はいくつかの言語を参考にしているが、まったくの新規の言語なのでC#の前は存在しない

**デフォルトの名無しさん** · 2016/10/12(水) 13:20:34.12

>>127
++
++

が#になったのでは？

**デフォルトの名無しさん** · 2016/10/12(水) 22:03:52.29

>>125
> そのフレームワークを書いた人間は言語で選んでるんですけど

それは言語を選んでいるのであって、開発効率に差があるということではないよ

言語を選ぶ理由はいくつか有る。自分がたまたま詳しかった言語とか
フレームワークを作るのに便利なライブラリが有ったとか、
対応しなければならない環境が使える言語がそれしかなかったとかね。

**デフォルトの名無しさん** · 2016/10/12(水) 22:04:38.80

>>126
> ある種のフレームワークを書こうと思った時、特定の言語機能（例: 代数的データ型）があるかどうかで
> 書きやすさが全然違うんだよね

だからそう思うならば、その理由を書けばいいだけの話。

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

> それは言語を選んでいるのであって、開発効率に差があるということではないよ

開発効率に差がないということでもない
お前の知らない世界については「開発効率に差があるかもしれない、ないかもしれない、どちらか分からない」
が正しいのであって「差があることが言えてないのであれば差がないということ」という論理は暴論でしかない

差がないことを言いたいのであれば、それを証明する義務はお前にある

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

>128
それは単にネーミングの話であって
ファミコンに対するスーパーファミコンみたいなものだよ

**デフォルトの名無しさん** · 2016/10/12(水) 22:32:07.73

>>131
> 差がないことを言いたいのであれば、それを証明する義務はお前にある

上の方に書いた。当たり前だが俺が知っている範囲でだ。（知らないことを書けるわけがない）
で、お前は俺より詳しくて知ってるんだろう？なら知ってることを書けよ。

俺が証明するとしたら差がないという答えにしかならないんだが分かってるかい？
お前のために差があることを俺が証明するわけがないだろうｗ

差がないと証明する義務はすでに果たした。あとはお前が俺の知らないものを持ってきて
差があると証明してくれるんだろう？早くしろよ。
知らないことを知ることができるとワクワクしながら待ってるんだからさｗ

**デフォルトの名無しさん** · 2016/10/12(水) 22:37:37.04

http://dic.nico video.jp/a/%E7%84%A1%E7%9F%A5%E3%81%AB%E8%A8%B4%E3%81%88%E3%82%8B%E8%AB%96%E8%A8%BC

無知に訴える論証（argument from ignorance）、あるいは無知論証とは、

「Aだという根拠がない。だからAではない」または「Aでないという根拠がない。だからAだ」

というパターンの、「根拠が無いこと」だけを根拠にして何らかの結論を導いてしまう、間違った論理のこと。

なお後述するが、「新しい根拠が無ければ新しい説は言えない」と考えても良い。このほうが、実践的には分かりやすく間違いが少ないだろう。

**デフォルトの名無しさん** · 2016/10/12(水) 22:39:10.63

>>133
> 俺が証明するとしたら差がないという答えにしかならないんだが分かってるかい？
証明できるんならそれでいいんじゃない？

> 差がないと証明する義務はすでに果たした
まったく果たされていない
お前の知らない範囲については以前として「不明のまま」だ

つまり、お前の理論は現時点では、「HelloWorld などの俺の知ってる狭い範囲では言語によって
開発効率に差は出ない」ということしか証明されていない

**デフォルトの名無しさん** · 2016/10/12(水) 22:52:28.37

>>135
で、開発効率に差がないという証明は？

お前が言ってるのはAだという根拠がないといってるだけ。

**デフォルトの名無しさん** · 2016/10/12(水) 22:55:42.62

>>136
根拠がない以上、「どちらか分からない」が正解になる
「Aである」の根拠がないことを言った結果、「Aではない」になるわけではない
「Aであるかもしれないし、Aでないかもしれない。まだ証明されていない」という状態になるだけ

そこから「Aである」ことを主張したいなら、それを証明する義務は「Aである」と言った人間にある

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

俺がわかってる範囲・・・「差がない」
俺が知らない範囲・・・「不明」

結論はこれでいいのかい？ｗ

なんか世界中の人をすべて調べないかぎり
卵から生まれた人間がいないとは言い切れない
と言ってるようなもんだねｗ

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

>>138
それでいい
お前の言ってる範囲はごく狭いことだけ認識してくれて、今後その主張をするときは
「HelloWorld周辺の俺が知ってる範囲では」という前提条件を忘れないようにな

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

人は卵から生まれることはないのか？
俺「生まれることはない」

お前「お前の知り合いという狭い範囲で生まれてないからと言って
卵から生まれた人間がいないという根拠はない。
根拠がない以上卵から生まれて人間がいるか？の答えは分からないが正解になる」

わっはっは

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

>>139
じゃあ、

俺の知ってる範囲では、差がないというのが事実だし、
俺の知らない範囲で差があるという証拠は一つも出ていない。

ということにするよｗ

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

>>140
証明されていない分野については、感覚的におかしかろうとそれが論理というものだ
お前はお前の感覚で全分野でお前の論理が成立すると思い込んでるようだが、それは論理ではない
論理は「お前の知ってる範囲だけ」で成立するものだ

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

>>141
> 俺の知らない範囲で差があるという証拠は一つも出ていない。
差がないかどうかも俺は知らない、という言葉をつけておこうな

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

お前「お前の知り合いという狭い範囲で悪魔がいないからといって
世界で悪魔がいないという根拠はない。
根拠がない以上悪魔がいるか？の答えは分からないが正解になる」

幽霊でもバンパイアでも好きなものを当てはめよう！

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

>>144
うん、それでいいと思うよ
科学者ほど神を信じてるというしな

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

結局、悪魔の証明を言ってるだけか。
議論にならんね。

俺が知らないとすることを知ってるはずなのに、
なんで証明できないんだろうね（笑）

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

>>146
お前は悪魔の証明の使い方を間違ってる
悪魔の証明は知ろうとしたら知ることができる範囲の証明ができないことは一切言っていない
お前は代数的データ型について知ろうとすればできるのにその証明をしようともしていない
これは悪魔の証明ではない

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

だから代数データ型を知った上で差がないと言ってる。

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

>>148
知った上で差がないという説明のレスはどこにあるの？

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

たとえば、代数的データ型のHelloWorldとも言える木構造データを
生産性に差がない君のよく知ってるRubyで、既存のどんなフレームワークを使ってもいいから
書いてみてもらえば差があるかないかはっきりすると思うよ

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

>>150
やっぱりHelloWorldでしか比べてないじゃんというｗｗ
そりゃ、簡単なプログラムで差が出るわけないよなー

**デフォルトの名無しさん** · 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