【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ55【php,py,pl,rb】

1 ：デフォルトの名無しさん：2016/10/01(土) 23:40:48.89 ID:FvOeAcfn.net

前スレ

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

2 ：デフォルトの名無しさん：2016/10/02(日) 00:47:01.83 ID:Bi7hk0oe.net

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

3 ：デフォルトの名無しさん：2016/10/02(日) 00:55:03.29 ID:A7Nl1eL6.net

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

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

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

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

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

4 ：デフォルトの名無しさん：2016/10/02(日) 02:56:43.85 ID:o/oJKASu.net

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

5 ：デフォルトの名無しさん：2016/10/02(日) 06:08:51.15 ID:B7NgyTXX.net

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

6 ：デフォルトの名無しさん：2016/10/02(日) 08:24:13.37 ID:Hq+/j29t.net

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

7 ：デフォルトの名無しさん：2016/10/02(日) 09:26:07.58 ID:gWSXlQpJ.net

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

8 ：デフォルトの名無しさん：2016/10/02(日) 10:29:10.60 ID:A7Nl1eL6.net

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

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

9 ：デフォルトの名無しさん：2016/10/02(日) 10:45:41.11 ID:UOjgrslt.net

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

10 ：デフォルトの名無しさん：2016/10/02(日) 10:53:21.03 ID:kPn//wmb.net

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

11 ：デフォルトの名無しさん：2016/10/02(日) 11:27:02.29 ID:A7Nl1eL6.net

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

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

12 ：デフォルトの名無しさん：2016/10/02(日) 12:01:38.62 ID:UOjgrslt.net

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

13 ：デフォルトの名無しさん：2016/10/02(日) 12:17:23.58 ID:A7Nl1eL6.net

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

14 ：デフォルトの名無しさん：2016/10/02(日) 12:22:40.79 ID:7wUTU6an.net

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

15 ：デフォルトの名無しさん：2016/10/02(日) 12:29:05.37 ID:A7Nl1eL6.net

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

16 ：デフォルトの名無しさん：2016/10/02(日) 13:31:20.00 ID:UOjgrslt.net

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

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

17 ：デフォルトの名無しさん：2016/10/02(日) 13:37:57.86 ID:A7Nl1eL6.net

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

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

18 ：デフォルトの名無しさん：2016/10/02(日) 13:59:36.22 ID:UOjgrslt.net

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

19 ：デフォルトの名無しさん：2016/10/02(日) 14:03:14.13 ID:eJU0yv2p.net

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

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

20 ：デフォルトの名無しさん：2016/10/02(日) 14:22:12.38 ID:A7Nl1eL6.net

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

21 ：デフォルトの名無しさん：2016/10/02(日) 14:23:14.18 ID:UOjgrslt.net

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

22 ：デフォルトの名無しさん：2016/10/02(日) 14:24:34.01 ID:A7Nl1eL6.net

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

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

23 ：デフォルトの名無しさん：2016/10/02(日) 14:25:41.21 ID:UOjgrslt.net

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

24 ：デフォルトの名無しさん：2016/10/02(日) 14:28:02.95 ID:A7Nl1eL6.net

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

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

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

25 ：デフォルトの名無しさん：2016/10/02(日) 14:29:57.11 ID:UOjgrslt.net

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

26 ：デフォルトの名無しさん：2016/10/02(日) 14:31:54.61 ID:A7Nl1eL6.net

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

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

27 ：デフォルトの名無しさん：2016/10/02(日) 14:35:35.91 ID:eJU0yv2p.net

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

28 ：デフォルトの名無しさん：2016/10/02(日) 15:22:55.96 ID:kPn//wmb.net

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

29 ：デフォルトの名無しさん：2016/10/02(日) 15:28:29.58 ID:gWSXlQpJ.net

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

30 ：デフォルトの名無しさん：2016/10/02(日) 15:59:38.76 ID:kPn//wmb.net

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

31 ：デフォルトの名無しさん：2016/10/02(日) 16:19:08.68 ID:A7Nl1eL6.net

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

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

32 ：デフォルトの名無しさん：2016/10/02(日) 16:29:42.70 ID:kPn//wmb.net

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

33 ：デフォルトの名無しさん：2016/10/02(日) 16:33:51.55 ID:A7Nl1eL6.net

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

34 ：デフォルトの名無しさん：2016/10/02(日) 16:37:53.24 ID:kPn//wmb.net

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

35 ：デフォルトの名無しさん：2016/10/02(日) 16:39:00.24 ID:A7Nl1eL6.net

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

36 ：デフォルトの名無しさん：2016/10/02(日) 16:43:15.80 ID:kPn//wmb.net

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

37 ：デフォルトの名無しさん：2016/10/02(日) 17:01:08.28 ID:A7Nl1eL6.net

じゃあ言って見れば？

38 ：デフォルトの名無しさん：2016/10/02(日) 17:03:02.53 ID:kPn//wmb.net

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

39 ：デフォルトの名無しさん：2016/10/02(日) 22:15:23.86 ID:YSooqH+k.net

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

40 ：デフォルトの名無しさん：2016/10/02(日) 22:18:27.31 ID:A7Nl1eL6.net

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

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


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

41 ：デフォルトの名無しさん：2016/10/02(日) 23:53:31.54 ID:ikqDAd+/.net

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

42 ：デフォルトの名無しさん：2016/10/03(月) 22:33:47.03 ID:+/vBYXSE.net

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

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

43 ：デフォルトの名無しさん：2016/10/04(火) 00:22:58.47 ID:px5zXLds.net

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

44 ：デフォルトの名無しさん：2016/10/04(火) 00:45:11.34 ID:41/K25SW.net

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

45 ：デフォルトの名無しさん：2016/10/04(火) 01:27:22.78 ID:px5zXLds.net

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

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

46 ：デフォルトの名無しさん：2016/10/04(火) 08:11:58.86 ID:4IqBwgDx.net

>>45
>>27とか

47 ：デフォルトの名無しさん：2016/10/04(火) 09:10:07.20 ID:px5zXLds.net

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

48 ：デフォルトの名無しさん：2016/10/04(火) 10:09:35.12 ID:4IqBwgDx.net

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

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

49 ：デフォルトの名無しさん：2016/10/04(火) 11:09:45.49 ID:iuVpzj4K.net

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

50 ：デフォルトの名無しさん：2016/10/04(火) 21:01:19.59 ID:px5zXLds.net

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

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

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

51 ：デフォルトの名無しさん：2016/10/04(火) 21:02:48.74 ID:px5zXLds.net

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

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

52 ：デフォルトの名無しさん：2016/10/04(火) 21:03:48.66 ID:V9yFwQr5.net

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

53 ：デフォルトの名無しさん：2016/10/04(火) 21:11:16.99 ID:px5zXLds.net

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

54 ：デフォルトの名無しさん：2016/10/04(火) 21:16:18.10 ID:px5zXLds.net

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

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

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

55 ：デフォルトの名無しさん：2016/10/04(火) 21:18:02.55 ID:V9yFwQr5.net

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

あれ？書いてますけど？

56 ：デフォルトの名無しさん：2016/10/04(火) 21:41:54.10 ID:px5zXLds.net

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

57 ：デフォルトの名無しさん：2016/10/04(火) 21:44:39.54 ID:V9yFwQr5.net

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

58 ：デフォルトの名無しさん：2016/10/04(火) 21:48:12.77 ID:px5zXLds.net

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

59 ：デフォルトの名無しさん：2016/10/04(火) 22:01:00.43 ID:V9yFwQr5.net

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

60 ：デフォルトの名無しさん：2016/10/04(火) 23:06:28.39 ID:c95btk+9.net

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

61 ：デフォルトの名無しさん：2016/10/05(水) 01:57:03.61 ID:f4G2o0Wy.net

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

62 ：デフォルトの名無しさん：2016/10/05(水) 05:21:35.62 ID:PMogH9vB.net

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

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

63 ：デフォルトの名無しさん：2016/10/05(水) 05:50:14.91 ID:1vEKhOHe.net

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

64 ：デフォルトの名無しさん：2016/10/05(水) 07:36:53.16 ID:2ahFCYR+.net

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

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

65 ：デフォルトの名無しさん：2016/10/05(水) 09:30:51.95 ID:f4G2o0Wy.net

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

66 ：デフォルトの名無しさん：2016/10/05(水) 10:06:38.23 ID:lkZZSZSh.net

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

67 ：デフォルトの名無しさん：2016/10/05(水) 11:30:50.07 ID:n3rzU9DG.net

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

68 ：デフォルトの名無しさん：2016/10/05(水) 12:17:28.77 ID:jN7hnxBN.net

このスレの雑魚率は異常

69 ：デフォルトの名無しさん：2016/10/05(水) 17:00:17.35 ID:Il4yJk9W.net

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

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

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

70 ：デフォルトの名無しさん：2016/10/05(水) 17:09:28.32 ID:Il4yJk9W.net

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

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

71 ：デフォルトの名無しさん：2016/10/06(木) 08:06:33.30 ID:iNikTZeR.net

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

72 ：デフォルトの名無しさん：2016/10/06(木) 21:51:00.18 ID:ebrDzA6a.net

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

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

73 ：デフォルトの名無しさん：2016/10/06(木) 23:25:28.00 ID:BMy5Xi/f.net

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

74 ：デフォルトの名無しさん：2016/10/06(木) 23:29:34.28 ID:8+ZXgN8r.net

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

75 ：デフォルトの名無しさん：2016/10/07(金) 01:42:56.68 ID:2bUYn87k.net

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

76 ：デフォルトの名無しさん：2016/10/07(金) 03:31:19.20 ID:2bUYn87k.net

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

77 ：デフォルトの名無しさん：2016/10/07(金) 17:35:11.73 ID:pbAKgzuV.net

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

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

78 ：デフォルトの名無しさん：2016/10/08(土) 07:43:03.70 ID:dWardwII.net

>>69
removeAttribute じゃだめかい？

79 ：デフォルトの名無しさん：2016/10/09(日) 14:29:52.33 ID:bYUVlBu3.net

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

80 ：デフォルトの名無しさん：2016/10/09(日) 17:47:56.67 ID:etJE85Lo.net

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

81 ：デフォルトの名無しさん：2016/10/09(日) 18:14:51.49 ID:etJE85Lo.net

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

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

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

82 ：デフォルトの名無しさん：2016/10/09(日) 19:47:31.24 ID:Rm79Y6cU.net

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

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

83 ：デフォルトの名無しさん：2016/10/09(日) 20:12:48.40 ID:190gE+2p.net

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

84 ：デフォルトの名無しさん：2016/10/10(月) 02:01:40.76 ID:teDgpDlf.net

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

85 ：デフォルトの名無しさん：2016/10/10(月) 04:58:00.52 ID:99eJrtEu.net

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

86 ：デフォルトの名無しさん：2016/10/10(月) 09:21:02.84 ID:ClkDUgcU.net

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

87 ：デフォルトの名無しさん：2016/10/10(月) 10:47:43.46 ID:5rtYMNIr.net

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

88 ：デフォルトの名無しさん：2016/10/10(月) 11:32:27.81 ID:ClkDUgcU.net

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

89 ：デフォルトの名無しさん：2016/10/10(月) 15:54:10.73 ID:Kgt7uTeW.net

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

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

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

90 ：デフォルトの名無しさん：2016/10/10(月) 18:15:33.31 ID:teDgpDlf.net

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

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

91 ：デフォルトの名無しさん：2016/10/10(月) 18:27:03.69 ID:teDgpDlf.net

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

92 ：デフォルトの名無しさん：2016/10/10(月) 20:04:08.54 ID:ar34yalZ.net

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

93 ：デフォルトの名無しさん：2016/10/10(月) 23:04:37.88 ID:oCisyuHf.net

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

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

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

94 ：デフォルトの名無しさん：2016/10/10(月) 23:06:13.08 ID:oCisyuHf.net

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

95 ：デフォルトの名無しさん：2016/10/10(月) 23:07:22.01 ID:oCisyuHf.net

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

96 ：デフォルトの名無しさん：2016/10/11(火) 06:51:07.82 ID:lxwJWoO8.net

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

97 ：デフォルトの名無しさん：2016/10/11(火) 07:58:49.36 ID:KsPXMvNv.net

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

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

98 ：デフォルトの名無しさん：2016/10/11(火) 09:08:09.78 ID:pWg+DYaN.net

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

99 ：デフォルトの名無しさん：2016/10/11(火) 09:32:00.97 ID:lxwJWoO8.net

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

100 ：デフォルトの名無しさん：2016/10/11(火) 19:28:27.31 ID:4aJkZN3t.net

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

101 ：デフォルトの名無しさん：2016/10/11(火) 22:40:16.74 ID:Zk32hdPj.net

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

102 ：デフォルトの名無しさん：2016/10/11(火) 22:48:15.84 ID:hjXFmrTp.net

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

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

103 ：デフォルトの名無しさん：2016/10/11(火) 23:15:17.75 ID:KsPXMvNv.net

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

104 ：デフォルトの名無しさん：2016/10/11(火) 23:16:39.08 ID:hjXFmrTp.net

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

105 ：デフォルトの名無しさん：2016/10/11(火) 23:20:57.60 ID:KsPXMvNv.net

>>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#なんだが。

106 ：デフォルトの名無しさん：2016/10/11(火) 23:23:10.02 ID:KsPXMvNv.net

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

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

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

107 ：デフォルトの名無しさん：2016/10/11(火) 23:32:39.98 ID:DEfYJAZn.net

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

108 ：デフォルトの名無しさん：2016/10/11(火) 23:35:50.02 ID:KsPXMvNv.net

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

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

109 ：デフォルトの名無しさん：2016/10/11(火) 23:42:50.22 ID:hjXFmrTp.net

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

110 ：デフォルトの名無しさん：2016/10/11(火) 23:43:29.05 ID:hjXFmrTp.net

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

111 ：デフォルトの名無しさん：2016/10/11(火) 23:49:46.06 ID:DEfYJAZn.net

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

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

112 ：デフォルトの名無しさん：2016/10/11(火) 23:52:42.58 ID:KsPXMvNv.net

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

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

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

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

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

113 ：デフォルトの名無しさん：2016/10/11(火) 23:56:28.84 ID:KsPXMvNv.net

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

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

114 ：デフォルトの名無しさん：2016/10/12(水) 00:00:25.52 ID:u+SfUSoS.net

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

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

な？簡単だろ？

115 ：デフォルトの名無しさん：2016/10/12(水) 00:05:38.91 ID:bJD9Q0hO.net

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

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

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

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

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

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

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

116 ：デフォルトの名無しさん：2016/10/12(水) 00:08:16.73 ID:bJD9Q0hO.net

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

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

117 ：デフォルトの名無しさん：2016/10/12(水) 00:09:25.62 ID:u+SfUSoS.net

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

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

118 ：デフォルトの名無しさん：2016/10/12(水) 00:11:52.16 ID:bJD9Q0hO.net

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

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


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

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

119 ：デフォルトの名無しさん：2016/10/12(水) 00:14:19.39 ID:u+SfUSoS.net

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

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

120 ：デフォルトの名無しさん：2016/10/12(水) 05:06:31.01 ID:hi5pDFH9.net

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

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

ポケモンGoとかもそうだ

121 ：デフォルトの名無しさん：2016/10/12(水) 06:17:04.66 ID:36fXw7IK.net

>>120
＞　C#は後方互換

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

122 ：デフォルトの名無しさん：2016/10/12(水) 06:37:27.85 ID:h9K+2gUj.net

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

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

123 ：デフォルトの名無しさん：2016/10/12(水) 07:01:10.41 ID:NQ8LRzeO.net

>>93

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

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

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

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

124 ：デフォルトの名無しさん：2016/10/12(水) 09:36:47.16 ID:bJD9Q0hO.net

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

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

125 ：デフォルトの名無しさん：2016/10/12(水) 09:43:32.39 ID:R3I0FCLG.net

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

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

126 ：デフォルトの名無しさん：2016/10/12(水) 09:53:08.98 ID:R3I0FCLG.net

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

127 ：デフォルトの名無しさん：2016/10/12(水) 13:08:44.84 ID:hi5pDFH9.net

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

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

128 ：デフォルトの名無しさん：2016/10/12(水) 13:20:34.12 ID:AH5cZ6Nj.net

>>127
++
++

が#になったのでは？

129 ：デフォルトの名無しさん：2016/10/12(水) 22:03:52.29 ID:bJD9Q0hO.net

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

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

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

130 ：デフォルトの名無しさん：2016/10/12(水) 22:04:38.80 ID:bJD9Q0hO.net

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

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

131 ：デフォルトの名無しさん：2016/10/12(水) 22:10:11.54 ID:u+SfUSoS.net

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

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

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

132 ：デフォルトの名無しさん：2016/10/12(水) 22:12:35.42 ID:DGH9OdjO.net

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

133 ：デフォルトの名無しさん：2016/10/12(水) 22:32:07.73 ID:bJD9Q0hO.net

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

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

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

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

134 ：デフォルトの名無しさん：2016/10/12(水) 22:37:37.04 ID:bJD9Q0hO.net

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だ」

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

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

135 ：デフォルトの名無しさん：2016/10/12(水) 22:39:10.63 ID:u+SfUSoS.net

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

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

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

136 ：デフォルトの名無しさん：2016/10/12(水) 22:52:28.37 ID:bJD9Q0hO.net

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

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

137 ：デフォルトの名無しさん：2016/10/12(水) 22:55:42.62 ID:u+SfUSoS.net

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

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

138 ：デフォルトの名無しさん：2016/10/12(水) 23:00:17.34 ID:bJD9Q0hO.net

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

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


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

139 ：デフォルトの名無しさん：2016/10/12(水) 23:01:41.75 ID:u+SfUSoS.net

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

140 ：デフォルトの名無しさん：2016/10/12(水) 23:02:54.38 ID:bJD9Q0hO.net

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

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

わっはっは

141 ：デフォルトの名無しさん：2016/10/12(水) 23:04:02.33 ID:bJD9Q0hO.net

>>139
じゃあ、

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

ということにするよｗ

142 ：デフォルトの名無しさん：2016/10/12(水) 23:05:01.44 ID:u+SfUSoS.net

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

143 ：デフォルトの名無しさん：2016/10/12(水) 23:05:46.12 ID:u+SfUSoS.net

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

144 ：デフォルトの名無しさん：2016/10/12(水) 23:06:02.34 ID:bJD9Q0hO.net

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


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

145 ：デフォルトの名無しさん：2016/10/12(水) 23:08:26.36 ID:u+SfUSoS.net

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

146 ：デフォルトの名無しさん：2016/10/12(水) 23:10:38.55 ID:bJD9Q0hO.net

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

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

147 ：デフォルトの名無しさん：2016/10/12(水) 23:19:12.98 ID:u+SfUSoS.net

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

148 ：デフォルトの名無しさん：2016/10/12(水) 23:32:12.91 ID:bJD9Q0hO.net

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

149 ：デフォルトの名無しさん：2016/10/12(水) 23:40:45.50 ID:u+SfUSoS.net

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

150 ：デフォルトの名無しさん：2016/10/13(木) 06:51:19.28 ID:5Zaj3bBS.net

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

151 ：デフォルトの名無しさん：2016/10/13(木) 07:34:32.13 ID:eQrSxPiM.net

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

152 ：デフォルトの名無しさん：2016/10/13(木) 07:56:11.59 ID:b9yuDuDK.net

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

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

153 ：デフォルトの名無しさん：2016/10/13(木) 08:30:22.11 ID:YiooIUIr.net

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

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

154 ：デフォルトの名無しさん：2016/10/13(木) 10:15:51.93 ID:J3jF+oV3.net

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

155 ：デフォルトの名無しさん：2016/10/13(木) 21:59:17.17 ID:xK6BxW94.net

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

156 ：デフォルトの名無しさん：2016/10/13(木) 22:00:32.17 ID:xK6BxW94.net

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

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

157 ：デフォルトの名無しさん：2016/10/13(木) 22:05:21.45 ID:xK6BxW94.net

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

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

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

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

158 ：デフォルトの名無しさん：2016/10/13(木) 22:44:26.61 ID:C+WIXg7a.net

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

代数的データ型を振りかざす彼ら(>>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界隈で木構造の論文を漁ると必ず行き着く文献だよ

159 ：デフォルトの名無しさん：2016/10/13(木) 23:14:36.15 ID:xK6BxW94.net

てすと

160 ：デフォルトの名無しさん：2016/10/14(金) 01:12:59.85 ID:JRwX0F1n.net

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

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

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

161 ：デフォルトの名無しさん：2016/10/14(金) 01:15:29.41 ID:8JWyfknx.net

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

162 ：デフォルトの名無しさん：2016/10/14(金) 01:24:21.14 ID:JRwX0F1n.net

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

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

163 ：デフォルトの名無しさん：2016/10/14(金) 07:08:23.14 ID:7gx6wu5c.net

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

164 ：デフォルトの名無しさん：2016/10/14(金) 07:43:39.03 ID:8JWyfknx.net

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

165 ：デフォルトの名無しさん：2016/10/14(金) 07:45:54.24 ID:JRwX0F1n.net

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

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

166 ：デフォルトの名無しさん：2016/10/14(金) 08:41:21.48 ID:AiVbXbyV.net

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

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

167 ：デフォルトの名無しさん：2016/10/14(金) 08:58:45.24 ID:SNzkHoS8.net

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

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

168 ：デフォルトの名無しさん：2016/10/14(金) 09:18:34.24 ID:8JWyfknx.net

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

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

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

169 ：デフォルトの名無しさん：2016/10/14(金) 09:36:41.21 ID:8JWyfknx.net

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

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

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

170 ：デフォルトの名無しさん：2016/10/14(金) 09:54:52.55 ID:AiVbXbyV.net

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

171 ：デフォルトの名無しさん：2016/10/14(金) 10:04:08.99 ID:d7FBnZt1.net

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

172 ：デフォルトの名無しさん：2016/10/14(金) 13:03:12.66 ID:jdu5cZVV.net

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

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

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

173 ：デフォルトの名無しさん：2016/10/14(金) 13:13:29.24 ID:nMNSKW91.net

>>172
しゃあねぇなあ

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

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

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

174 ：デフォルトの名無しさん：2016/10/14(金) 14:11:57.58 ID:R0NlyoEI.net

>>140
卵子「...」

175 ：デフォルトの名無しさん：2016/10/14(金) 21:53:35.92 ID:8JWyfknx.net

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

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

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

176 ：デフォルトの名無しさん：2016/10/14(金) 22:30:50.25 ID:JRwX0F1n.net

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

177 ：デフォルトの名無しさん：2016/10/14(金) 23:04:30.33 ID:GgR4zu7p.net

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

178 ：デフォルトの名無しさん：2016/10/15(土) 00:57:52.87 ID:zdnRk0/Y.net

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

179 ：デフォルトの名無しさん：2016/10/15(土) 15:54:45.64 ID:zdnRk0/Y.net

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

180 ：デフォルトの名無しさん：2016/10/15(土) 16:31:49.07 ID:t0okkxEp.net

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

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

181 ：デフォルトの名無しさん：2016/10/18(火) 07:59:44.51 ID:ctyreU3P.net

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

182 ：デフォルトの名無しさん：2016/10/18(火) 09:41:12.91 ID:jwQXzgTl.net

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

183 ：デフォルトの名無しさん：2016/10/18(火) 12:26:33.66 ID:87/Xx6tX.net

ちょっと本職が突けばｗ

184 ：デフォルトの名無しさん：2016/10/18(火) 12:38:42.89 ID:mznmuPbS.net

結局Javaなんだよなあ

185 ：デフォルトの名無しさん：2016/10/18(火) 17:41:42.50 ID:6xf0fQvT.net

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

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

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

186 ：デフォルトの名無しさん：2016/10/18(火) 18:07:44.27 ID:GiAjO0tK.net

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

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

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

187 ：デフォルトの名無しさん：2016/10/18(火) 21:36:24.79 ID:2Y34d6Lk.net

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

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

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

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

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

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

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

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

188 ：デフォルトの名無しさん：2016/10/18(火) 21:55:55.42 ID:dddY2TDK.net

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

189 ：デフォルトの名無しさん：2016/10/18(火) 21:56:27.15 ID:GiAjO0tK.net

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

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

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

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

190 ：デフォルトの名無しさん：2016/10/18(火) 21:59:43.78 ID:2Y34d6Lk.net

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

191 ：デフォルトの名無しさん：2016/10/18(火) 22:37:19.60 ID:5uBe5ZKU.net

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

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

192 ：デフォルトの名無しさん：2016/10/18(火) 23:17:00.33 ID:GiAjO0tK.net

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

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

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

193 ：デフォルトの名無しさん：2016/10/19(水) 00:14:59.40 ID:OiCCOICb.net

WEB+DB vol.94 が出た

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

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

194 ：158：2016/10/19(水) 00:15:02.24 ID:SBws4+ZC.net

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

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

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

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

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

195 ：デフォルトの名無しさん：2016/10/19(水) 00:32:17.20 ID:E+rnGfx8.net

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

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

196 ：デフォルトの名無しさん：2016/10/19(水) 00:41:17.08 ID:E+rnGfx8.net

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

197 ：デフォルトの名無しさん：2016/10/19(水) 00:49:36.13 ID:E+rnGfx8.net

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

www

198 ：158：2016/10/19(水) 01:34:04.06 ID:SBws4+ZC.net

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

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

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


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

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

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

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

199 ：デフォルトの名無しさん：2016/10/19(水) 01:40:34.09 ID:OjZ5I+UL.net

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

200 ：デフォルトの名無しさん：2016/10/19(水) 07:51:06.99 ID:i9OiXSaV.net

>>198

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

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

201 ：デフォルトの名無しさん：2016/10/19(水) 07:52:41.50 ID:i9OiXSaV.net

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

202 ：デフォルトの名無しさん：2016/10/19(水) 07:56:48.84 ID:kMzukS4D.net

>>198

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

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

203 ：デフォルトの名無しさん：2016/10/19(水) 08:17:18.72 ID:pQsxuliv.net

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

204 ：デフォルトの名無しさん：2016/10/19(水) 08:27:14.32 ID:kMzukS4D.net

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

205 ：デフォルトの名無しさん：2016/10/19(水) 08:34:11.07 ID:kMzukS4D.net

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

206 ：デフォルトの名無しさん：2016/10/19(水) 09:19:42.80 ID:Y8FYAwNZ.net

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

207 ：デフォルトの名無しさん：2016/10/19(水) 09:41:28.41 ID:zLw8XMfd.net

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

208 ：デフォルトの名無しさん：2016/10/19(水) 10:09:01.69 ID:OiCCOICb.net

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

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

209 ：デフォルトの名無しさん：2016/10/19(水) 15:06:28.19 ID:pQsxuliv.net

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

210 ：デフォルトの名無しさん：2016/10/19(水) 18:35:13.38 ID:lOW+ixbD.net

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

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

211 ：デフォルトの名無しさん：2016/10/19(水) 19:41:21.21 ID:lOW+ixbD.net

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

212 ：デフォルトの名無しさん：2016/10/19(水) 21:35:33.44 ID:/aiIuy0q.net

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

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

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

213 ：デフォルトの名無しさん：2016/10/19(水) 22:05:06.83 ID:kMzukS4D.net

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

214 ：158：2016/10/19(水) 22:29:30.29 ID:SBws4+ZC.net

>>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の代数的データ型君よ、これで代数的データ型の利点は理解できたかね？

215 ：デフォルトの名無しさん：2016/10/19(水) 22:33:50.18 ID:pM+OMbbr.net

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

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

216 ：158：2016/10/19(水) 22:43:15.12 ID:SBws4+ZC.net

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

217 ：デフォルトの名無しさん：2016/10/19(水) 22:53:00.17 ID:aQ7ihF1n.net

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

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

218 ：デフォルトの名無しさん：2016/10/19(水) 23:11:26.37 ID:pM+OMbbr.net

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

219 ：デフォルトの名無しさん：2016/10/19(水) 23:17:47.00 ID:IHKURc/r.net

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

220 ：デフォルトの名無しさん：2016/10/19(水) 23:23:44.73 ID:kMzukS4D.net

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

221 ：デフォルトの名無しさん：2016/10/19(水) 23:26:44.07 ID:kMzukS4D.net

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

222 ：158：2016/10/20(木) 00:41:54.83 ID:UafaUCbB.net

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

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

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

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

223 ：デフォルトの名無しさん：2016/10/20(木) 01:09:47.56 ID:vzgaJJkb.net

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

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

224 ：デフォルトの名無しさん：2016/10/20(木) 02:29:07.30 ID:lUeWQjIy.net

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

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

225 ：デフォルトの名無しさん：2016/10/20(木) 03:21:02.12 ID:vzgaJJkb.net

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

226 ：デフォルトの名無しさん：2016/10/20(木) 07:14:57.75 ID:vW88Z4VH.net

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

227 ：デフォルトの名無しさん：2016/10/20(木) 09:18:03.49 ID:lUeWQjIy.net

>>226
例えが意味不明

228 ：デフォルトの名無しさん：2016/10/20(木) 13:34:29.50 ID:KC19vCT1.net

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

229 ：デフォルトの名無しさん：2016/10/20(木) 20:52:40.32 ID:ZXfPioz4.net

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

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

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

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

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

230 ：デフォルトの名無しさん：2016/10/20(木) 21:30:03.25 ID:G0R2mg5X.net

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

231 ：デフォルトの名無しさん：2016/10/20(木) 21:33:15.39 ID:ZXfPioz4.net

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

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

232 ：デフォルトの名無しさん：2016/10/20(木) 23:18:09.29 ID:vW88Z4VH.net

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

233 ：デフォルトの名無しさん：2016/10/20(木) 23:58:59.82 ID:RjGt0l94.net

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

234 ：デフォルトの名無しさん：2016/10/21(金) 00:01:07.08 ID:wzbGy53g.net

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

235 ：デフォルトの名無しさん：2016/10/21(金) 10:41:13.06 ID:kR8VeEnh.net

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

236 ：デフォルトの名無しさん：2016/10/21(金) 18:09:04.13 ID:vB7jIyI4.net

>>234不正解

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

237 ：デフォルトの名無しさん：2016/10/21(金) 22:13:42.38 ID:wzbGy53g.net

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

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

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

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

238 ：デフォルトの名無しさん：2016/10/21(金) 23:36:53.11 ID:kR8VeEnh.net

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

239 ：デフォルトの名無しさん：2016/10/21(金) 23:42:21.89 ID:p3mW1/xP.net

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

240 ：デフォルトの名無しさん：2016/10/21(金) 23:45:48.48 ID:p3mW1/xP.net

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

241 ：デフォルトの名無しさん：2016/10/21(金) 23:50:54.50 ID:QizP+3wH.net

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

242 ：デフォルトの名無しさん：2016/10/21(金) 23:52:16.03 ID:p3mW1/xP.net

>>241
今もそうだよ

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

243 ：デフォルトの名無しさん：2016/10/22(土) 00:06:02.54 ID:LnIwCgwC.net

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

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

244 ：デフォルトの名無しさん：2016/10/22(土) 00:20:16.83 ID:xefyYgJX.net

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

245 ：デフォルトの名無しさん：2016/10/22(土) 01:52:25.03 ID:cVDLvhGg.net

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

246 ：デフォルトの名無しさん：2016/10/22(土) 01:54:01.83 ID:LnIwCgwC.net

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

247 ：デフォルトの名無しさん：2016/10/22(土) 01:56:24.28 ID:cVDLvhGg.net

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

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

248 ：デフォルトの名無しさん：2016/10/22(土) 01:58:10.15 ID:LnIwCgwC.net

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

249 ：デフォルトの名無しさん：2016/10/22(土) 02:08:31.54 ID:cVDLvhGg.net

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

250 ：デフォルトの名無しさん：2016/10/22(土) 02:11:53.22 ID:LnIwCgwC.net

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

251 ：デフォルトの名無しさん：2016/10/22(土) 02:17:59.04 ID:cVDLvhGg.net

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

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

252 ：デフォルトの名無しさん：2016/10/22(土) 02:20:08.08 ID:LnIwCgwC.net

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

253 ：デフォルトの名無しさん：2016/10/22(土) 02:27:45.65 ID:cVDLvhGg.net

>>252
知らんがな。言語による開発効率の差はごく僅かって言う話と関係ないし。

日本が嫌なら海外にでも行けば？
海外ならば、ぜんぜん違う言語を使ってるはずだって
夢見るのも悪くないと思うよｗ

あ、ぜんぜん違う言語＝英語とかそういうのはいらないからｗ

254 ：デフォルトの名無しさん：2016/10/22(土) 02:29:04.98 ID:LnIwCgwC.net

>>253
だからそんな話は意味がないって
言語なんて開発者が決める話じゃないんだし

255 ：デフォルトの名無しさん：2016/10/22(土) 02:29:16.74 ID:cVDLvhGg.net

プログラミングは属人性が恐ろしく高い

その属人性（その言語に詳しいかどうか）でも
言語の違いによるわずかな差は簡単に埋められてしまうね。

256 ：デフォルトの名無しさん：2016/10/22(土) 02:29:59.60 ID:cVDLvhGg.net

>>254
それは日本の話だろ？ｗ

海外は開発者が言語を選んでいるんですよ。
言語ランキングはいまさら出さなくてもいいよな？
日本と大差ないし。

257 ：デフォルトの名無しさん：2016/10/22(土) 02:31:40.83 ID:LnIwCgwC.net

>>255
属人性が高いということは言語による差が大きいということだよ
あらゆる言語を操れるスーパーマンなんていないからね

とりあえず職人さんが忌避しがちなPHPとかは真っ先に対象から外すべきだね

258 ：デフォルトの名無しさん：2016/10/22(土) 02:32:21.46 ID:cVDLvhGg.net

> 属人性が高いということは言語による差が大きいということだよ

意味不明。

259 ：デフォルトの名無しさん：2016/10/22(土) 02:32:30.50 ID:LnIwCgwC.net

>>256
日本人が日本の話してるのはごく自然なお話だと思うんですが？
君は日本以外で仕事してるの？

260 ：デフォルトの名無しさん：2016/10/22(土) 02:33:14.17 ID:LnIwCgwC.net

>>258
奴隷ばっか集まる言語なんて意味ないだろ？

261 ：デフォルトの名無しさん：2016/10/22(土) 02:35:38.46 ID:cVDLvhGg.net

属人性の意味間違ってるなーｗ
説明するのがめんどくせーから探してきた

http://d.hatena.ne.jp/Nagise/20090302/1235997646
>
> ソフトウェア開発の属人性の誤解
>
> 　属人性の排除が狙うところってのは「その人しかやり方を知らないよ、秘密だよ」って
> 作業をなくす話で、技能的にその人しかできる人がいないって話題じゃないんだ。
> ソフトウェア開発の属人性を語るときにここを勘違いしていると議論にならない。

262 ：デフォルトの名無しさん：2016/10/22(土) 02:36:59.45 ID:cVDLvhGg.net

>>259
> 君は日本以外で仕事してるの？

そうじゃなくて、海外の事例を調べてみろって話。
海外は、日本とは違って、言語をちゃんと選んでるんだろう？
使える人が多いかどうかじゃなくて。

263 ：デフォルトの名無しさん：2016/10/22(土) 02:39:15.13 ID:LnIwCgwC.net

>>261
合ってるよそれで

日本人SEはその「その人しかできない」を拡大解釈して「奴隷でもできなきゃいけない」という脅迫概念にかられてるんだよね
奴隷の開発効率なんて職人の百分の一以下しかないのにね

264 ：デフォルトの名無しさん：2016/10/22(土) 02:40:01.83 ID:cVDLvhGg.net

>>263
海外でも同じだろｗ
なんでいっつも、日本はー、日本はーって言ってるの？

265 ：デフォルトの名無しさん：2016/10/22(土) 02:42:10.02 ID:LnIwCgwC.net

>>264
同じじゃないんだなこれが
海外はプログラマを職人としてきちんとした待遇で受け入れてるからね
（その代わり職人レベルにないプログラマは容赦なく切られるけどね）

266 ：デフォルトの名無しさん：2016/10/22(土) 02:42:31.46 ID:cVDLvhGg.net

言語の違いによる開発効率の差は殆ど無いから当たり前の話であるんだが、
マイナーな言語を使うよりも、メジャーな言語を使うほうが
人を多く集められるので、（ほんの少ししかない）開発効率は
簡単に逆転するという話でした。

267 ：デフォルトの名無しさん：2016/10/22(土) 02:43:15.88 ID:cVDLvhGg.net

>>265
だから海外ではなんの言語が使われてるのか？って
話をしたんだよ。日本と違うデータが出てくるんだろ？

268 ：デフォルトの名無しさん：2016/10/22(土) 02:44:39.60 ID:LnIwCgwC.net

>>266
出てるよ
海外のJava、PHPの落ち込み方は半端ないからね
それに引き換え日本の求人ときたら…

269 ：デフォルトの名無しさん：2016/10/22(土) 09:20:53.73 ID:O/1X83Cc.net

向こうは一山いくらの開発はどんどんオフショアに投げるし、
ジャッパゴスのようにパッケージを無駄にカスタマイズしたりしないの
残念ながら技術的な問題じゃないんだ

270 ：デフォルトの名無しさん：2016/10/22(土) 11:17:42.02 ID:8sfmeCeb.net

カスタマイズは良いけど成果物を公開しないよ、秘密だよってのがガラパゴスなんだろ

271 ：デフォルトの名無しさん：2016/10/22(土) 11:21:53.28 ID:O/1X83Cc.net

じゃ海外でSIの成果物をgithubで公開してる例を教えてくれよw

272 ：デフォルトの名無しさん：2016/10/22(土) 11:23:02.67 ID:MU45rE6v.net

なんでそこSI限定なの？

273 ：デフォルトの名無しさん：2016/10/22(土) 11:45:31.20 ID:O/1X83Cc.net

この文脈でSI限定じゃない方が不自然だと思うが?
自社のパッケージやサービスの開発なら日本でもわりと職人的な技術が重視されるから
ID:LnIwCgwC の抱いているような不満には至らんよ

274 ：デフォルトの名無しさん：2016/10/22(土) 11:56:23.19 ID:aqioS2aS.net

お前らはどうせどの言語もまともに使えないんだからどの言語でも大差ないよ

275 ：デフォルトの名無しさん：2016/10/22(土) 12:04:05.39 ID:cVDLvhGg.net

>>268
落ちているやつじゃなくて、何を使ってるかを言えよｗ

276 ：デフォルトの名無しさん：2016/10/22(土) 12:06:50.81 ID:8sfmeCeb.net

秘密が属人的なものであれば公開するという意思決定も簡単にできる
一方、組織的な秘密を公開するには例えば全会一致のような高いハードルがある

277 ：デフォルトの名無しさん：2016/10/22(土) 12:13:26.29 ID:cVDLvhGg.net

公開してないから、属人的っていうんやで？

278 ：デフォルトの名無しさん：2016/10/22(土) 12:31:49.49 ID:MCKaXjxk.net

ところで効率や仕事での仕方なし抜きにしたら、おまいらの好きな言語って何？

279 ：デフォルトの名無しさん：2016/10/22(土) 13:37:30.09 ID:cVDLvhGg.net

ついでに好きな理由も書いてね

280 ：デフォルトの名無しさん：2016/10/22(土) 15:19:03.68 ID:FwMGd9Sr.net

>>278
お気に入りは文句なしでSmalltalk
理由は頭一つ抜きん出た生産性の高さｗ
http://cast-a-spell.at.webry.info/201001/article_7.html

281 ：デフォルトの名無しさん：2016/10/22(土) 15:24:05.21 ID:cVDLvhGg.net

うーん。生産性と行数がイコールだと思ってる人がいるようだね。
同じ言語であれば、生産性と行数はイコールかもしれないけど、
言語が違うと生産性と行数は一致しない。

例えばPythonだと、他の言語だと一行で書けるものを
改行強制で二行にされちゃうけど、そこに二倍の
生産性があることにはならない。

定義とかimport文とかを除いた実質的な実行行数（ステップ数とも言う）で考えないと。

282 ：デフォルトの名無しさん：2016/10/22(土) 15:29:01.36 ID:cVDLvhGg.net

JavaScriptでもアロー関数が使えるようになって、

array.forEach(function(v) {
　console.log(v);
});

という三行が

array.forEach(v => console.log(v));

という一行で書けるようになったけど、タイピング速度には
影響があったとしても、3倍の行数文の違いはない。

昔だってこう書くことは出来た。
array.forEach(function(v) {console.log(v) });
改行とインデント入れて11文字タイプする程度の速度の違いしかない。

これが行数で生産性を語る場合の罠ね。

283 ：デフォルトの名無しさん：2016/10/22(土) 15:53:20.93 ID:MCKaXjxk.net

俺はc++14以降のc++がけっこう好きになってる。
昔はc++大嫌いだったんだけど、java使うようになって、でも結局メモリリーク問題は付きまとって、更に既存のcライブラリ使わざるを得なくてjniに嫌気がさして、、、
それならレガシーライブラリそのまま使えるc++のがいいんじゃ と感じるようになった。
ただまぁそれはweb関係じゃない部分だからそうなんだと思う。

284 ：デフォルトの名無しさん：2016/10/22(土) 16:00:12.31 ID:MCKaXjxk.net

smalltalkとかlispは動いてるシステムをそのまま修正できる的なところが凄いと思う。
http://qiita.com/guicho271828/items/1b78d8a7335e81e11791

285 ：デフォルトの名無しさん：2016/10/22(土) 16:19:08.42 ID:cVDLvhGg.net

>>284
最終手段としてないよりはあるほうがいいし、技術的にはすごいけど実用的には？だけどね。
考えてみりゃわかるけど、動いているシステムをその場で書き換えられたら困ることのほうが多い。

例えば書き換えるべき対象が一つだけならいいけど、今は何十台といったサーバーでアプリが動いてる。
そのそれぞれにログインしてシステム書き換えますか？って話。

作業をミスすることなく一発で完了できるならまだしも、通常は手元で修正してテストをしてバグを潰す。
書き換えてる途中でその機能を使われたら問題になるので、ブロックする機能も必要。
マーケティングの点からも直ぐに修正反映ではなくて、事前に告知したい。

でなんとなく気づいてかもしれないけど、動いてるシステムをそのまま修正ってのは実際に
ウェブアプリで行われてるんだよ。ただしSmalltalkは言語のレイヤーでこれらのことをやってるが
その他の言語は別のレイヤーで行ってる。

それもそのはずで、SmalltalkはOSの機能そのものまで言語の中に取り込んでるものだから。
だから「動いてるシステムをそのまま修正」っていうのは実はOSを起動したまま
アプリを再起動させるだけで修正できるのと同じことを指してる。
単に言語だけで完結できますよーってだけで、他の言語もOSと連携させて動いてるシステムを
そのまま修正することは可能。

286 ：デフォルトの名無しさん：2016/10/22(土) 17:10:10.50 ID:6V9nqXNd.net

いや、便利で必要な技術だと思うよ。
でも専売特許じゃなくてevalがあるような言語などれでもら出来ることだと思う。
自分もNodeでとあるゲームサーバー立てた時したことあるし、
クライアントでもしたことある。
バグ修正やハックの類だが、そのゲームの最中に修正できるに越したことはない。

287 ：284：2016/10/22(土) 17:15:53.55 ID:xGV5yujh.net

>>285
> でなんとなく気づいてかもしれないけど、動いてるシステムをそのまま修正ってのは実際に
> ウェブアプリで行われてるんだよ。ただしSmalltalkは言語のレイヤーでこれらのことをやってるが
> その他の言語は別のレイヤーで行ってる。

いや、うん知ってるし。
で、だ、仕事での仕方なし抜きにしたらって言ってる所にトウトウと実用ではどうのこうの語られても「そうだね」という感想しか持てないわ。ごめんね。

そんなことよりお前の好きな言語とそれに惹かれたとこは何さ？

288 ：デフォルトの名無しさん：2016/10/22(土) 17:32:17.15 ID:xGV5yujh.net

お前らが惹かれた言語はなにでそのどんなところに惹かれたのさ？

普段使いの言語でも、仕様全部把握してるとかでなければ「あ、こうやればよかったんだ」ってあっただろ？
新しく学んだ言語でも「これは便利だな」ってあっただろ？
そんな時コード書くのが楽しいだろ？
そんな話を聞かせてくれよ。

289 ：デフォルトの名無しさん：2016/10/22(土) 20:25:33.75 ID:tBkzOasK.net

やっぱりSmalltalkが最高だったね
1 + 2 × 3 が 9 になる所とかサイコー

290 ：デフォルトの名無しさん：2016/10/22(土) 21:11:20.34 ID:xGV5yujh.net

forthもいいと思う
1 2 + 3 *

291 ：デフォルトの名無しさん：2016/10/22(土) 21:47:29.15 ID:+Ddj+FpA.net

>>289
嘘こけ　7 になるぞｗ
https://lively-web.org/users/Dan/ALTO-Smalltalk-72.html

292 ：デフォルトの名無しさん：2016/10/22(土) 22:56:25.52 ID:cVDLvhGg.net

>>286
> バグ修正やハックの類だが、そのゲームの最中に修正できるに越したことはない。

今までの人生で、何回、ゲーム最中にゲームを終了すること無く
ゲームの実行コードを修正したいと思ったことある？
もちろんそのゲームの開発者の立場で。（チートする話じゃないってこと）

293 ：デフォルトの名無しさん：2016/10/22(土) 23:00:01.30 ID:cVDLvhGg.net

>>288
> お前らが惹かれた言語はなにでそのどんなところに惹かれたのさ？

言語を使うのが目的じゃなくて、その言語でなんらかの
アプリ、システム、サービスを作るのが目的だからね。
言語だけで惹かれることはない。

特殊なアプリだったら、特殊なライブラリが在るものを選ぶとか
特定の環境（スマホとか）で動かないならば、その環境で一般的なのを
選ぶとか、なんらかのプラグインならば、その大本と同じ言語を選ぶとか。

言語そのもので惹かれるってことはないな。
ある言語で書いていて、あー○○言語だとあれがあって便利なのになーって
思うことはたまにあるけど、それはそれでその問題を自分で解決するほうが楽しい。

294 ：デフォルトの名無しさん：2016/10/22(土) 23:00:58.19 ID:tBkzOasK.net

>>291
ちゃんと9だよ。サイコーだからな
https://ideone.com/BRVnNz

295 ：デフォルトの名無しさん：2016/10/23(日) 00:21:12.92 ID:Ih4sBoJC.net

>>293
色んな人がいるよね
大事なのは言語愛を否定しないことだね
言語愛を持ってる人に「なんでも一緒だろ」なんて暴言を吐かないことが大事だね

296 ：デフォルトの名無しさん：2016/10/23(日) 00:26:31.49 ID:KEuHHxF/.net

言語愛（笑）

297 ：デフォルトの名無しさん：2016/10/23(日) 00:31:47.12 ID:Ih4sBoJC.net

（笑）とか言ってるうちはまだまだだよ
愛は一番のモチベーションなんだからね

298 ：デフォルトの名無しさん：2016/10/23(日) 00:46:38.28 ID:RkqjdgMb.net

>>292
> 実行コードを修正したいと思ったことある？

効率や仕事での仕方なし抜きにってことならSmalltalkで実行しながら開発してくの楽しいよ
ついでにSmalltalkには仮想イメージっちゅう簡易オブジェクトストア機構がデフォなんで
実行コンテキストもそのまま永続化できるからこれがまた超便利

299 ：デフォルトの名無しさん：2016/10/23(日) 00:56:14.20 ID:KEuHHxF/.net

それ効率悪そう。
テストとかどうやってるの？
実行した結果バグがあったら実行前に戻れるの？
最初から実行するのなら別に実行しながら書く意味ないし。
っていうか実行しなきゃ書けないの？

300 ：デフォルトの名無しさん：2016/10/23(日) 01:14:36.69 ID:EPR0SqWa.net

>>299
ユニットテストとかsmalltalkから生まれたんじゃないのか

301 ：デフォルトの名無しさん：2016/10/23(日) 01:17:50.99 ID:EPR0SqWa.net

mvc、デザインパターン、これらもみんなsmalltalkから生まれたよね。
俺は一度も使ったこと無いけど色々と魅力ある言語・環境だと思うぞ。

302 ：デフォルトの名無しさん：2016/10/23(日) 01:22:20.72 ID:RkqjdgMb.net

>>299
テスト駆動もできるけど（まあxUnitとかTDDなんてそもそもSmalltalkが元祖だしｗ）
それをもう一歩進めた場当たり的ないわゆる“デバッグ駆動開発”がSmalltalkでは気持ちイイ
頭の中にできあがったモデルを仮想イメージ（Smalltalk環境）にどどーって注ぎ込んでくスピード感がたまらない
http://www.slideshare.net/sumim/20120916-rubykaigi-rubyistsqueak-smalltalk/21

303 ：デフォルトの名無しさん：2016/10/23(日) 01:32:42.68 ID:EPR0SqWa.net

俺の今のメインはc++, java
どっちも嫌いだったけどc++14以降はいいなと思えるようになってきた(c++11はジェネリックラムダ無いので)。
javaだって(c++に比べて)、豊富なライブラリとかフレームワーク、開発環境は良いと思う。
phpだって嫌いだけど(javaに比べて)、取っつきやすさとかいいと思う。7になってタイプヒンティングとか使えるケースが広がったし、配列も普通になった。

ま、しょせん俺は自分言語作る力は無いから他の人が作ったものを使うしか無いけどね。

304 ：デフォルトの名無しさん：2016/10/23(日) 01:38:01.97 ID:KEuHHxF/.net

>>300
だからユニットテストつかって実行すれば良いんだから
実行しながら開発とかする必要ないんですよ。

305 ：デフォルトの名無しさん：2016/10/23(日) 01:38:02.96 ID:EPR0SqWa.net

>>302
小学校でプログミングとか話題になったけど、個人的にsqueakって結構合うんじゃないかと思ったりした。
まぁ、先生が使えないだろうけど。

306 ：デフォルトの名無しさん：2016/10/23(日) 01:41:31.98 ID:KEuHHxF/.net

>>302
> 頭の中にできあがったモデルを仮想イメージ（Smalltalk環境）にどどーって注ぎ込んでくスピード感がたまらない

それ意味わからん。
俺は頭の中に出来上がったコードをばーっと書き上げる。
書いてる最中にいちいち実行したりしない。

307 ：デフォルトの名無しさん：2016/10/23(日) 01:54:23.18 ID:RkqjdgMb.net

>>306
んー、説明が難しいな
コードは頭の中にはまだないのよ　つーかSmalltalkで組むときはコーディングというのを実はあまり意識しない
漠然としたオブジェクトだけが頭の中にあって、それをSmalltalkに（それこそメッセージを送って）構築してもらう感じ
TDDは仕様を書かされている感じがワンアクション挟まるというかなんか隔靴掻痒感みたいなのがある

308 ：デフォルトの名無しさん：2016/10/23(日) 02:10:33.76 ID:EPR0SqWa.net

smalltalk使ったことが無い俺が想像でいうと、smalltalkでの開発は言語でコードを書くというより、もちっとレイヤーが上の感じだと思う。
今時の人たちが、コンテナ用意してその中でサービス走らせてイメージ保存してとかやってることを、smalltalkだとその言語・環境で全部できる。
サービスを建てるっていうのが、smalltalkだとオブジェクトを生成する、に相当するみたいな。

309 ：デフォルトの名無しさん：2016/10/23(日) 02:21:35.16 ID:RkqjdgMb.net

>>307
そんなTDDをするにしても、Smalltalkだと件の“デバッグ駆動開発”っぽさは入ってくるので
他言語でやるTDDよりは楽しいんだけどね
https://www.youtube.com/watch?v=HOuZyOKa91o

あと、この動画の後半に出てくる入出力例を入れるとメソッドを探してくれるツールとかは他言語にも欲しい

310 ：デフォルトの名無しさん：2016/10/23(日) 02:24:58.06 ID:KEuHHxF/.net

>>307
もしかしてコードを考えるのに時間がかかる人？

何かしたいことが有って、それを書こうと思ったら複雑なものでもない限り
5秒もあればそれを実現するコードを10行ぐらい頭のなかに出来上がるだろ？
一関数の行数がだいたいこんぐらい。

あとはそれをばーっとかくだけなんだが。

311 ：デフォルトの名無しさん：2016/10/23(日) 02:26:04.86 ID:KEuHHxF/.net

>>308
> 今時の人たちが、コンテナ用意してその中でサービス走らせてイメージ保存してとかやってることを、smalltalkだとその言語・環境で全部できる。

Smalltalkでクラウドを使って複数台のマシンで連携させて
サービスを実現するってことを、言語だけでやる方法を教えてほしい。

まず最初にデプロイはどうするの？

312 ：デフォルトの名無しさん：2016/10/23(日) 03:31:38.72 ID:KEuHHxF/.net

イメージの保存というのは、実行コンテキストの保存ではない。
Smalltalkのいう実行コンテキストを永続化っていうのは
今のコンテナの仕組みとは正反対だからな。

https://ja.wikipedia.org/wiki/Immutable_Infrastructure
> Immutable Infrastructure（イミュータブル　インフラストラクチャ）は
> 不変なサーバー基盤のこと。具体的には、一度サーバーを構築したらその後は
> サーバーのソフトウェアに変更を加えないことを意味する。

これが今のトレンド。ソフトウェアに変更を加えないから
いつでも破棄して作り直せる。

313 ：デフォルトの名無しさん：2016/10/23(日) 03:46:41.34 ID:RkqjdgMb.net

>>310
うーむ　やっぱりコードベースで考えなきゃいけない言語の人とは分かり合えそうもないか
Smalltalkだとどうしてもオブジェクトベースな頭になっちゃうのでいけませんな^^;

>>311
良くも悪くもSmalltalkの生い立ちは「パソコン」環境（アラン・ケイのダイナブックのための暫定OS。為念）なので
そういう使い方は想定されていないんだけど、しいて挙げるならGemStoneというSmalltalk処理系がそれ向けかな
Smalltalkはもとから簡易オブジェクトストアの中に構築された処理系という特殊な実装方法がとられているんだけど
それを一歩進めて、分散OODB内に処理系を構築しちゃった感じのSmalltalkの一種
https://docs.google.com/viewer?a=v&pid=sites&srcid=c21hbGx0YWxrLXVzZXJzLmpwfGhvbWV8Z3g6NGJiZDExNjU5ZmIxN2Q4Yg

314 ：デフォルトの名無しさん：2016/10/23(日) 03:56:31.04 ID:RkqjdgMb.net

>>312
実行コンテキストも含めて永続化できるっていうのはデバッグの時にちょっと便利なオマケ機能であって
システムを構成するオブジェクト群をその状態のまま収めた仮想イメージファイルで配布する用途が主なので
今のコンテナの考え方に近いと思うけど違うのかな

315 ：デフォルトの名無しさん：2016/10/23(日) 04:07:00.80 ID:KEuHHxF/.net

コンテナを起動した直後はオブジェクトは存在しない。
オブジェクトというのはデータだ。

イミュータブルインフラストラクチャっていうのは
コンテナに状態（データ）を持たないことで実現する。

データを別の所に保存していて、コンテナ自体には持たないから
いつでもすぐに停止して破棄することが可能。

316 ：デフォルトの名無しさん：2016/10/23(日) 04:07:41.46 ID:KEuHHxF/.net

> うーむ　やっぱりコードベースで考えなきゃいけない言語の人とは分かり合えそうもないか
> Smalltalkだとどうしてもオブジェクトベースな頭になっちゃうのでいけませんな^^;

オブジェクトもコードだろ？何を言ってるんだか。
それともSmalltalkにはソースコードがないのか？ｗ

317 ：デフォルトの名無しさん：2016/10/23(日) 05:09:37.11 ID:RkqjdgMb.net

>>315
> データを別の所に保存していて、コンテナ自体には持たないから
いつでもすぐに停止して破棄することが可能。

うん。だからデータを別の場所に保存するそういった運用も可能ということ

たとえばここに置いてあるzipぞれぞれには
http://wiki.squeak.org/swiki/uploads/10/ComSwiki.3.zip?history=true
当時のモジュールのソースが失われたりして今となっては構成の再現が不可能なとても古いComSwikiという
サーバーの歴代バージョンを構成するオブジェクト群を永続化してファイルに収めた形（仮想イメージ）で
入っているんだけど、各々の仮想イメージさえあれば各バージョンのComSwikiサーバーは動かせるし
Wikiのセッティングやデータは別ファイルで保存されるんで仮想イメージ（サーバー環境）自体は
停止して破棄はもちろん、すげ替えたりもできる…ってあたりがちょっと似ているんじゃないかな、と

318 ：デフォルトの名無しさん：2016/10/23(日) 05:49:24.70 ID:RkqjdgMb.net

>>316
Smalltalkのプログラミングというのは環境内にオブジェクトのネットワークを構築することが目的だから
ソースコードの記述を必ずしも意味しないんだよね

例えば、クラスやメソッド定義のためのコードの記述やそれを評価する行為は、オブジェクトとしてのそれらを
その場で生成するために行うSmalltalk環境とのコミュニケーションの手段の一つに過ぎなくて
他言語のようにソースコードを収めたファイルを書き上げる（あるいは書き下しでいく）作業とはちょっと感覚が違う

たぶん何を言っているのかわからないと思うけど^^;

319 ：デフォルトの名無しさん：2016/10/23(日) 06:59:39.74 ID:zosolBkY.net

何回か修正していって、やっぱり3回前の修正だけ
間違いだから取り除きたいって思ったとき
その方法って簡単にできるわけ？

ソースコードなら、特定のコードを取り除くだけだけど

実行イメージを破棄せずに、イメージから3回前の修正に伴う全ての環境への変化を元に戻せるの？

320 ：デフォルトの名無しさん：2016/10/23(日) 09:28:02.06 ID:w/MDWg7b.net

smalltalkって超成果主義なんだよな
山頂に行きたいだけなのに全然違う場所で小屋やテントを作るのは登山家の恥と思ってる

321 ：デフォルトの名無しさん：2016/10/23(日) 11:24:20.87 ID:RkqjdgMb.net

>>319
> ソースコードなら、特定のコードを取り除くだけ

Smalltalkの場合、プログラムの修正は「オブジェクトのすげ替え」、
つまり新しく生成して古いものと置き換える作業になるけど、別にソースコードの場合と同じだよ？

たとえばメソッドオブジェクトのすげ替えなら、その履歴はすべて記録・管理されているから、
その不要な「３番目」の修正を無かったことにして元に戻すだけ

> 実行イメージを破棄せずに、イメージから3回前の修正に伴う全ての環境への変化を元に戻せるの？

その「３回目」がたとえばDBからデータを削除してしまうというような不可逆な変化を生じさせる場合
ソースコードベースだってソースをいじったからって元に戻るわけではないよね？

322 ：デフォルトの名無しさん：2016/10/23(日) 11:25:45.54 ID:EPR0SqWa.net

イメージの保存は、smalltalkだけじゃなくlispもできたはず。意味・概念は違うかもだけど。
他にそういう言語ってあるかな？

323 ：デフォルトの名無しさん：2016/10/23(日) 11:34:20.89 ID:RkqjdgMb.net

>>320
> smalltalkって超成果主義なんだよな

プログラマの一挙手一投足が記録に残るから、そういうところはちょっとあるかもね
おもむろにどこかで3+4って式を評価したことも見ればあとからわかる
だから、環境内でどんな試行錯誤やヘマを何時やったかはマネージャーにバレバレ
関係ない小屋やテントなんか遊びで作っていたら、そりゃ叱られるよね

324 ：デフォルトの名無しさん：2016/10/23(日) 11:50:14.12 ID:RkqjdgMb.net

>>322
LISPもたしかにできるけど、Smalltalkのようなイメージベースでの運用形式は通常はとらないよね？
Smalltalk派生の処理系でなければ他は（Smalltalkの亜種に数える人もいるけど）SELF、あとFactorとか
でも秘伝のタレみたいにイメージを何十年にわたって育てていく感じはSmalltalk独特のような気がする

325 ：デフォルトの名無しさん：2016/10/23(日) 12:21:15.99 ID:KEuHHxF/.net

Smalltalkの場合、オブジェクトって言ってるのは
単にソースコードなだけだよ（笑）

> その「３回目」がたとえばDBからデータを削除してしまうというような不可逆な変化を生じさせる場合
> ソースコードベースだってソースをいじったからって元に戻るわけではないよね？

普通の言語ではソースコードとデータは分離されてるから、
簡単にデータだけバックアップが取れる。

あるデータで処理がおかしい場合、データのバックアップをとっておき、
ソースコードを修正して、同じデータで処理するだけで正しいデータが得られる。

でもSmalltalkではそういうこと出来ないでしょ？
データ＋ソースコードがオブジェクトだから
データを変えてしまうとソースコードまで変わってしまう。

326 ：デフォルトの名無しさん：2016/10/23(日) 12:22:35.14 ID:KEuHHxF/.net

>>323
どうでもいいものを記録にとってどうするよｗ
そういうのはノイズが多いっていうんだよ。
関係ないノイズが多すぎて重要な事が見えなくなってしまってる。

327 ：デフォルトの名無しさん：2016/10/23(日) 12:43:14.87 ID:RkqjdgMb.net

>>325
> Smalltalkの場合、オブジェクトって言ってるのは
> 単にソースコードなだけだよ（笑）

いや、オブジェクトはオブジェクトでしかないし、それを生成するためのソースコードとは別物なんだが…
やはりソースコードベースでしか物を考えられない人とのコミュニケーションはやっかいだな
クラスとインスタンスを会話の中で混同する人みたいだｗ

それはさておき

> 普通の言語ではソースコードとデータは分離されてるから、
> 簡単にデータだけバックアップが取れる。

Smalltalkだってそういう運用（たとえばデータはファイルやDBに追い出すとか）は可能だよ
そのうえで、あえてそういった手段をとらない、つまり仮想イメージ内にデータを保持する場合の話としても
仮想イメージはもちろん複製してバックアップは可能なので、

> あるデータで処理がおかしい場合、データのバックアップをとっておき、
> ソースコードを修正して、同じデータで処理するだけで正しいデータが得られる。

というのも普通にできるよ
（より正確には「ソースコードを修正」は「別の機能性オブジェクトにすげ替えて」だけど）
それなのにSmalltalkで「出来ない」とか「データを変えてしまうとソースコードまで変わってしまう」とか
いうのは仮想イメージの運用にどんなメンタルモデルを持っているのだろうか？

328 ：デフォルトの名無しさん：2016/10/23(日) 12:48:48.73 ID:KEuHHxF/.net

>>327
できないというかやらないんだよ。
Smalltalkの世界ではそんなことしない。
だから特殊で他の世界の常識が使えない。

329 ：デフォルトの名無しさん：2016/10/23(日) 12:49:32.94 ID:RkqjdgMb.net

>>326
> 関係ないノイズが多すぎて重要な事が見えなくなってしまってる。

そこはナンチャッテとはいえオブジェクトストア（ある種のデータベース）なんで、適切なフィルタをかけてやれば
必要な重要な情報は適宜引き出せるようになっているからご心配なく

実際にもそういう細やかなログはトラブル時にその原因の解明や、仮想イメージ（正確にはオブジェクトメモリの状態）
をやむを得ず放棄しなければならい場合の復旧にも役立っているしね

330 ：デフォルトの名無しさん：2016/10/23(日) 12:53:12.34 ID:RkqjdgMb.net

>>328
> Smalltalkの世界ではそんなことしない。

そんなことはないよｗ　どんな思い込みだよｗｗｗ
普通にデータを仮想イメージ外に置くためのORMとかOODBとか用意されているし、必要なら使うよ

331 ：デフォルトの名無しさん：2016/10/23(日) 12:56:46.27 ID:FxgCwMac.net

スレ違いにじっと耐え嵐が過ぎるのを待つ

332 ：デフォルトの名無しさん：2016/10/23(日) 13:01:19.34 ID:vOZeCx94.net

>>243
残念ながら土方に職人芸は要らない
最初から職人芸を発揮できるところに行けとしか言いようがない

333 ：デフォルトの名無しさん：2016/10/23(日) 13:02:28.68 ID:EPR0SqWa.net

>>331
phpの話してもいいんだぜw
7からだいぶよくなったとか。
実際の案件でもう使ってる人はいる？

334 ：デフォルトの名無しさん：2016/10/23(日) 13:05:33.36 ID:dkFb2YCF.net

>>331
wwwwwwww

ずっと続いてるから無理なんじゃね？wwww

335 ：デフォルトの名無しさん：2016/10/23(日) 13:16:02.19 ID:w/MDWg7b.net

smalltalkは超成果主義なので
既存のファイルシステムやデータベースの不満は何も語らず
問答無用で大量の代案を出してくる

336 ：デフォルトの名無しさん：2016/10/23(日) 13:46:37.23 ID:KEuHHxF/.net

Smalltalkの一番の欠点が、ソースコードの管理がしづらいってところだろうな。
なにせソースコード＝オブジェクトなのでSmalltalk独自の
フォーマット（バイナリ）で保存しなければいけない。

このオブジェクトからデータを抜き去ってコードだけ保存する方法も
処理系独自の拡張やIDEでないことはないけど、
そうするとSmalltalkらしさがなくなってしまう。

かと言ってオブエジェクトに含まれるデータまで
リポジトリにいれるのは変な話だし、
他人のPRをマージするとかコンフリクトが発生してしまったとか
そういったことがSmalltalkの開発時に致命的な問題になる。

337 ：デフォルトの名無しさん：2016/10/23(日) 14:16:18.22 ID:RkqjdgMb.net

>>336
> Smalltalk独自のフォーマット（バイナリ）で保存しなければいけない。

頼むからウソ情報垂れ流すなよ…
Smalltalkには古典的にも任意のオブジェクト（主だってはクラスやメソッドだが）にそのソースをはき出させる
file out という機能があってだな、凝ってもせいぜいXMLで事足りる　いったいどこから情報を得てんだよ！ｗ

338 ：デフォルトの名無しさん：2016/10/23(日) 14:17:16.22 ID:1sux/LQ7.net

昔はデータとコードの区別はなく渾然一体としていて、プログラムの自己書き換えのようなテクニックも一般的だったけど、
今では殆どの処理系ではデータ領域と実行領域のメモリは区別されてる。
「できるけどやらない、むしろ出来ないように発展した」って事なんだよね。わかるかな？

339 ：デフォルトの名無しさん：2016/10/23(日) 14:19:26.33 ID:EPR0SqWa.net

セキュリティからむからなぁ。

340 ：デフォルトの名無しさん：2016/10/23(日) 14:22:15.75 ID:EPR0SqWa.net

でもセキュリティホールが多いと言われるphpはたくさんのところで使われている。

341 ：デフォルトの名無しさん：2016/10/23(日) 14:27:57.97 ID:1sux/LQ7.net

ていうか、プログラムの文法の話じゃなく実行環境の優劣を語るなら
SmalltalkのライバルはLinuxやWindowsだろ

342 ：デフォルトの名無しさん：2016/10/23(日) 14:44:50.95 ID:EPR0SqWa.net

話変わるけど、文法というか見た目的なところで、
波かっこブロック、(begin)endブロック、インデントブロック、lisp的、forth的、、、
他にどんなのがあるだろう？
あー、あえて難読を狙ってる言語は抜きで。

343 ：デフォルトの名無しさん：2016/10/23(日) 14:48:30.32 ID:w/MDWg7b.net

>>338
ソースコードもデータだよ
ただ圧縮のやり方が動画等とは違う

圧縮することで成果物が劣化するんじゃないかという不安は動画と同じ

344 ：デフォルトの名無しさん：2016/10/23(日) 14:55:42.26 ID:1sux/LQ7.net

>>343
いまの殆どの処理系では実行時の扱いは他のデータとは違う
それは圧縮方式とは全然関係ない

345 ：デフォルトの名無しさん：2016/10/23(日) 18:34:21.46 ID:+tPIzBCg.net

>>292
Web上での拡張機能でのパッチなどを合わせたら
動いている最中に何かをしようとすることなんて
むしろそうじゃないことよりも多いくらいだよ。

346 ：デフォルトの名無しさん：2016/10/23(日) 20:37:39.89 ID:w/MDWg7b.net

昔はjavascriptを無効にしてデータだけ見たり保存したり出来たのに

347 ：デフォルトの名無しさん：2016/10/24(月) 00:10:39.77 ID:H/OAc5X2.net

>>338
今はIDEなどでコードもデータ（AST）として扱われるのが当たり前だし
いずれはインクリメンタルコンパイルやホットスワップもデフォになって
コンパイル時と実行時の区別なんてのも次第になくなっていく
「できることはどんどんやって、性能や技術面で設けられた過去の無用な制約は撤廃する方向に発展する」ってこと
わかるかな？

348 ：デフォルトの名無しさん：2016/10/24(月) 08:11:06.52 ID:Zipvrjj4.net

>>347
いまではサービス稼働中にサービス止めずにシステム入れ替えるとか普通にやってるけど
それはプログラミング言語のレイヤーでやってないし
やる意味もないんだって
本当に素人なんだな

349 ：デフォルトの名無しさん：2016/10/24(月) 09:28:37.18 ID:VKdQ2cFp.net

ホットスワップも、できるけどそんな機能いらないとか昔は言われてたもんなｗ
今は無意味だ危険だとか言ってることも、今後どう変わるかはわからんよ

350 ：デフォルトの名無しさん：2016/10/24(月) 09:30:36.40 ID:Zipvrjj4.net

すでにとっくに解決済みの問題なんですが、何盛り上がってんの？って感じなんだよなぁ

351 ：デフォルトの名無しさん：2016/10/24(月) 12:31:39.51 ID:G0jBqbeE.net

>>350
何の話？

352 ：デフォルトの名無しさん：2016/10/24(月) 13:35:35.03 ID:wFWi9LSL.net

盛り上がってる人を引きずり下ろすバトルロワイヤル
見えざる手に足を引っ張られる競争原理

353 ：デフォルトの名無しさん：2016/10/24(月) 17:10:02.23 ID:ejLFMMQB.net

要するに基本的な機能に付いてはもう話すことが無くなってきたってこと。
言語としてはそういう付加価値を出していくしかない。

354 ：デフォルトの名無しさん：2016/10/24(月) 19:19:53.24 ID:xHPWpU/w.net

最近のC#の強さは異常だな
スマゲやVRゲーでは完全に覇権を握っている

355 ：デフォルトの名無しさん：2016/10/24(月) 22:41:42.80 ID:Tb42ad7x.net

>>345
> Web上での拡張機能でのパッチなどを合わせたら
> 動いている最中に何かをしようとすることなんて
> むしろそうじゃないことよりも多いくらいだよ。

いや、動いている最中に、メソッド一個書き換えたりしないよｗ
バージョンアップなどの「修正」っていうのは通常一箇所（一メソッド）の
修正じゃなくて、複数のファイルにまたがる複数のコードを一度に更新する。

書き換えている間、そのメソッドは使えません。そのメソッドに依存するメソッドは
使えません。修正中は一時的に壊れます。じゃだめでしょｗ

そうなると必然的にサーバーをメンテナンスモードにするか止められないシステムなら
サーバーを複数台用意して、そのうち一台をアクセスされないようにして更新、
次にもう一台を更新・・・てなると思わない？
それを最近じゃサーバーを壊して作り直すことで更新するわけだけど

動いている最中にソースコードにパッチを当てるとか信頼性を担保したいならやらないからｗ

356 ：デフォルトの名無しさん：2016/10/24(月) 22:49:14.53 ID:Tb42ad7x.net

>>348がすでに言っていたか。>>345にレスしてないから見逃してしまった。

そうサービス稼働中のシステム入れ替えはプログラミング言語のレイヤーでやることじゃないよね。
トランザクションのように複数のファイル（クラス）にまたがる複数のコードを
アトミックに更新するひつようがある。

もし "プログラミング言語のレイヤー" でやるとしたら、
1. ローカルでソースコードを書き換える。
2. ローカルでテストする。
3. 一連の修正を "プログラミング言語のレイヤーで" 一単位とする（gitでいうブランチとかタグ）
4. 一連の修正を "プログラミング言語のレイヤーで" サーバー側上に反映させる（gitでいうmargeやcheckout、もしくはデプロイツール）
みたいな機能が必要になるだろうね。

プログラミング言語にソースコード管理ツールや
デプロイツールまで内蔵しないといけなくなる。

357 ：デフォルトの名無しさん：2016/10/25(火) 09:10:59.23 ID:ZI8Mf/oE.net

>>356
> プログラミング言語にソースコード管理ツールや
> デプロイツールまで内蔵しないといけなく

Smalltalk？！wwwwwwww

358 ：デフォルトの名無しさん：2016/10/25(火) 10:09:37.06 ID:TjTM7jW/.net

>>355
俺は君みたいな卑怯な人間が大嫌いだ。

俺と君との間ではロジカルなより一般的で広い話になっていた。
そこで自分の立場が危ういとみるやさも当然のように
狭い範囲での良識や常識を持ち出すのは尽く卑怯。

意図的か無意識かは知らないが、
俺はそういう、相手が一生懸命考えた行為、
人と人との対話の価値を台無しにするやつは大大大嫌いだ。
知能人として最も最低な行為だと知れ。

359 ：デフォルトの名無しさん：2016/10/25(火) 13:13:57.86 ID:VVl5B4DR.net

人よりも言語自体が目的っていう軽い感覚がかえって役に立つこともあるね
言語を単なる道具と思ったら、真の目的が重荷になる

360 ：デフォルトの名無しさん：2016/10/25(火) 18:07:56.36 ID:ku5qPjgT.net

状況に合わせて使う言語を変えたいけど、
コア機能だけで足りること無いからなぁ。
ライブラリ・フレームワーク・開発環境、といろいろ覚えることは多い。
なのでチームで作業するとなると好み以外の言語になるのはある程度しょうがないかな。

361 ：デフォルトの名無しさん：2016/10/25(火) 19:45:52.29 ID:VVl5B4DR.net

ライブラリとOSがCで書かれている必然性を気にする奴が多い
Cは手段に過ぎず、手段は他にもあるから、Cの必然性がないという

362 ：デフォルトの名無しさん：2016/10/25(火) 21:32:55.88 ID:2bCSgEUm.net

>>358
中身のない文章っていうのは、汎用的になるんだよねｗ
具体的な何かを指摘してないから、どんなときにも使える文章になる。
お前の文章の話な。

363 ：デフォルトの名無しさん：2016/10/26(水) 00:04:17.48 ID:MLaVzWjp.net

>>361
国際的な公用語が英語である必然性を気にする奴が多い
英語は手段に過ぎず、手段は他にもあるから、英語の必然性がないという

364 ：デフォルトの名無しさん：2016/10/26(水) 01:19:53.12 ID:psVUqxMw.net

英語が偶然なのは当たり前
C言語は人工的に作ったくせに偶然性を排除できない所が面白い

365 ：デフォルトの名無しさん：2016/10/26(水) 01:34:29.46 ID:MLaVzWjp.net

英語は神が与えたもの

366 ：デフォルトの名無しさん：2016/10/26(水) 07:51:32.03 ID:eByiMDXS.net

>>362
話突っ込んできたのも君だし、君が挙げたテーマに沿って具体的に話していたが？
それを卑怯な君が投げ出したのだろう？恥ずかしいやつ

367 ：デフォルトの名無しさん：2016/10/26(水) 09:16:27.74 ID:Tc/AxpVE.net

え？ どこが投げ出してるの？
ずっと関係ある話をしてるよね。

368 ：デフォルトの名無しさん：2016/10/26(水) 18:55:04.73 ID:OWp7kaQv.net

いつもの理想郷アスペ君と認識障害アスペ君のくっさいくっさい争い

369 ：デフォルトの名無しさん：2016/10/26(水) 23:32:45.87 ID:GHA/uMTv.net

Smalltalkerとのやりとりって、いつも不毛になるよね。
例えるとこんな感じ。

A「このテント、超暖かくてサイコーの環境だよ」
B「いや、俺らふつーに家に住んでるし...冷暖房もベッドもあるし…」
A「不審者が近づいてきたらテントを畳んで移動できるから安全なんだぞ！」
B「いや、家に住んでたら不審者から逃げる必要ないし…」
A「もし転勤になったらどうするんだよ！移動がないと言えるか!?」
B「その時は引越するし…」

370 ：デフォルトの名無しさん：2016/10/27(木) 01:39:42.53 ID:+F3MqQSf.net

BがSmalltalk？　そりゃ不毛だわｗｗ

371 ：デフォルトの名無しさん：2016/10/27(木) 07:10:03.75 ID:VgGLXVu8.net

AがSmalltalkだろ
いつもトンチンカンな機能を自慢してんじゃん

372 ：デフォルトの名無しさん：2016/10/27(木) 09:26:54.16 ID:OkKLp/rR.net

知ってて言ってんだよ

373 ：デフォルトの名無しさん：2016/10/27(木) 09:41:00.74 ID:F1Es9tp8.net

テント暮らしの元兵士A
人を見たら泥棒と思う警官B
全米が泣きそうな設定じゃん

374 ：デフォルトの名無しさん：2016/10/27(木) 09:45:03.90 ID:ogUx0kFx.net

>>370
こういうこと？

A「この流行りのIDE/ORM/SCM/コンテナ…、超便利でサイコーの環境だよ」
B「いや、俺ら大昔からふつーに統合化/永続化/分散ソース管理/仮想化すんでるし...商用分散OODBもあるし…」
A「不審者が近づいてきたら攻撃対象のコンテナ気軽に破棄できるから安全なんだぞ！」
B「いや、自分で育てた仮想イメージに住んでたら不審者から逃げる必要ないし…」
A「もし第三者にコードいじられたらどうするんだよ！おまえら全機能かかえこんんでるんだろ!?」
B「ヘッドレスで動かすかなんならコンパイラクラスぶっこ抜いておくし…」

375 ：デフォルトの名無しさん：2016/10/27(木) 10:14:03.59 ID:VgGLXVu8.net

>>374
SmalltalkのOODBってMysqlとかと比べて100倍位遅いんじゃなかったっけ？

376 ：デフォルトの名無しさん：2016/10/27(木) 12:32:06.03 ID:7XPRq2+b.net

talkerじゃないがRDBMS用のORMもあるって書いてなかったか

377 ：デフォルトの名無しさん：2016/10/27(木) 13:41:27.90 ID:Hk5rVLoM.net

>>371
彼らはトンチンカンなわけではない
言語に求めること、向き合う姿勢が違うから話が噛み合っていないだけ

378 ：デフォルトの名無しさん：2016/10/27(木) 14:56:55.94 ID:80O2/jeT.net

>>375
どんなOODBと比べて？ 商用のGemStone/Sがそんなだったらヤバい

379 ：デフォルトの名無しさん：2016/10/27(木) 15:35:58.13 ID:Hk5rVLoM.net

talkerとしてはむしろ
音も全て漢字で記述していた太古の人に
ひらがな・カタカナの便利さを伝える漢字に近い

でも彼らの世界／文化レベルでは必要にならないことは
ちゃんと分かってるが、一応は説得する

380 ：デフォルトの名無しさん：2016/10/27(木) 16:47:41.21 ID:F1Es9tp8.net

漢字は外来語だけど翻訳しなくてもそのまま使える単語は便利じゃん
翻訳しないと通じない接続詞とかはひらがなで書く

381 ：デフォルトの名無しさん：2016/10/27(木) 20:05:42.82 ID:uEMndLPW.net

Smalltalkよりも遥かにマイナーなErlangは
マイナーでも価値が認められて、色んな企業で使われてる

Smalltalkが使われないのはマイナーだからじゃなく価値がないから

382 ：デフォルトの名無しさん：2016/10/27(木) 20:45:06.11 ID:I6A9uKq4.net

違うと思うメッセージングによる遅延結合の徹底という考え方が人類にはまだ早すぎるから

383 ：デフォルトの名無しさん：2016/10/27(木) 21:01:05.70 ID:uEMndLPW.net

メッセージングによる遅延結合の徹底というアイデアはwebで余すところなく実現されてる
ちっさなローカルPCの1プロセスの中でやるのがアホで無価値なだけ

384 ：デフォルトの名無しさん：2016/10/27(木) 21:38:50.37 ID:ogUx0kFx.net

本当に無価値な試みなら、ここまで他に影響を与えられるもんかね
https://exploringdata.github.io/vis/programming-languages-influence-network/#Smalltalk

385 ：デフォルトの名無しさん：2016/10/27(木) 21:53:47.79 ID:uEMndLPW.net

そんなもんが現在価値があるかどうかと関係あるとでも？
馬車が自動車に影響与えたからって今でも馬車に乗るくらいのアホさ加減だな

386 ：デフォルトの名無しさん：2016/10/27(木) 22:18:41.41 ID:keItunkB.net

>>371
> AがSmalltalkだろ

お前、どんな気持ちで>>370が「BがSmalltalk」って
言ったか、考えたことあるのか！

387 ：デフォルトの名無しさん：2016/10/27(木) 22:20:28.98 ID:keItunkB.net

>>384
Smalktalkに価値があると言っても、全てに価値があるわけじゃないのです。

他に影響を与えられなかったものは価値がなかったと考えるべきです。
つまりSmalktalk独自と言えるようなものは価値がないということです。

388 ：デフォルトの名無しさん：2016/10/27(木) 22:59:30.07 ID:1HgQuwV8.net

>>385
たしかに馬車は自動車に先行して使われて影響を与えたし
今でも観光目的などに細々と使われている点とかはSmalltalkの現状に似ていていいたとえかもｗ

ただSmalltalkと馬車が違うのは、つい最近も自動車ｗのトレンドに影響を与えるものを生み出していること

389 ：デフォルトの名無しさん：2016/10/27(木) 23:10:20.65 ID:1HgQuwV8.net

>>387
豚に真珠、猫に小判じゃないけど、
まだ真似されず独自の部分が現時点では無価値という意味では当たらずとも遠からずか
などと言ってみたところで馬の耳に念仏…というところも含めて

390 ：デフォルトの名無しさん：2016/10/28(金) 00:37:14.32 ID:BgEAltTM.net

こういう隔離スレでこんだけ暴れてるのに本スレは今月１レスしかない。終わった言語

391 ：デフォルトの名無しさん：2016/10/28(金) 01:27:20.12 ID:zmjgQps2.net

暴れてるって、いわれのない言いがかりをつけてきて
無用なスレ消費を助長してるのはアンチのほうだろ

392 ：デフォルトの名無しさん：2016/10/28(金) 04:05:46.47 ID:3qy7hidy.net

どうせ仕事でSmalltalk使ってないでしょ？
なんで使わないの？

393 ：デフォルトの名無しさん：2016/10/28(金) 07:55:55.62 ID:bUbDsoOJ.net

いわれのない言いがかりをつけてきて
無用なスレ消費を助長してるのはアンチのほう

394 ：デフォルトの名無しさん：2016/10/28(金) 08:55:41.13 ID:TtakAM9O.net

飛蚊症のゴミみたいなもんかSmalltalkって

395 ：デフォルトの名無しさん：2016/10/28(金) 09:13:49.98 ID:bUbDsoOJ.net

SORABITOさんに転職したい

396 ：デフォルトの名無しさん：2016/10/28(金) 09:21:28.43 ID:SzmYBdzH.net

たしか最近は悪口ばかり言う方が悪者ということになっていた筈だが

397 ：デフォルトの名無しさん：2016/10/28(金) 17:49:10.94 ID:RhtpmSEL.net

>>388
関数型言語はMapReduceとか、最近だとAWS Lambdaなどにコンセプトが受け継がれてて
まさにトレンドに影響を与えてると言えるけど、
Smalltalkにそんなものあったか？
まさかtraitsとかいうoopの一構文に過ぎないものの事を言ってんの？

398 ：デフォルトの名無しさん：2016/10/28(金) 19:20:55.16 ID:ch5b/kiY.net

MapReduceとかAWS Lambdaとかはメインフレーム時代のプロセス指向なバッチ処理への回帰であって、
関数型言語のコンセプトとは粒度が違いすぎると思うけど

399 ：デフォルトの名無しさん：2016/10/28(金) 19:35:52.46 ID:tW/HMORb.net

TraitsとMixinを混同するならともかく、oopの一構文とかどんな理解力不足なんだよ

400 ：デフォルトの名無しさん：2016/10/28(金) 19:49:51.93 ID:3qy7hidy.net

>>398
どっちもスケールの問題に対する関数型的な解決だよ
なにがプロセス指向なバッチ処理だよ馬鹿は黙ってろ

401 ：デフォルトの名無しさん：2016/10/28(金) 19:52:04.03 ID:3qy7hidy.net

>>399
traitsもmixinもたかがoopの一構文に過ぎない
そんなもん全く重要じゃないし、そんなのに拘ってるから下っ端コーダのままなんだよ

402 ：デフォルトの名無しさん：2016/10/28(金) 21:32:06.03 ID:xjMUho1S.net

>>481
じゃあお前にとって重要なものは何？
社長が重要とかいうボケはいらないからね

403 ：デフォルトの名無しさん：2016/10/28(金) 21:34:30.21 ID:xjMUho1S.net

>>400
> どっちもスケールの問題に対する関数型的な解決だよ

AWS Lambdaで使える言語は、Node、Java、Pythonなんだけど
関数型的な解決だという根拠は？

404 ：デフォルトの名無しさん：2016/10/28(金) 23:05:27.53 ID:v7enucQW.net

>>403
AWS Lambdaで書けるのはステートレスな関数に制限されてるだろ
状態を持たないことによる並列化のしやすさや疎結合という
関数型言語で得られる（と言われてる）メリットをアーキテクチャレベルで実現してる

てか、こんな簡単なことも言われないと分かんないの？馬鹿なの？どんな言語で書けるとかマジどーでも良いんだよ

405 ：デフォルトの名無しさん：2016/10/29(土) 08:33:42.56 ID:jbWCC7sE.net

vector<char>なら状態を持つがstringはステートレス
プロセス間通信のネットワークは文字列型と言ってもよさそうなものだが

文字列処理の価値を認めないのはSmalltalkと関数型に共通する特徴だと思う

406 ：デフォルトの名無しさん：2016/10/29(土) 11:14:01.00 ID:LoTR039H.net

lambda言ってる時点で関数型意識してるでしょ。
プロセス代数が出るならまだしもバッチ処理とかって、、、

407 ：デフォルトの名無しさん：2016/10/29(土) 11:27:17.86 ID:z8URZLOb.net

なんだｗ 「関数」と「関数型」をごっちゃにしているやつだったかｗ
AWS Lambdaはファイルやデータベースを読み書きできる
そういった「関数」を登録する。

ファイルやデータベースを読み書きする関数が「関数型」だというのなら
バッチ処理だって関数型だよｗ

408 ：デフォルトの名無しさん：2016/10/29(土) 11:35:01.33 ID:7nyiPKGt.net

>>407
ステートレスなコンテナってとこがミソなんだよなぁ
いくらでもスケールアップできて、S3のイベントなんかに反応して計算して、終わったらコンテナごと全消去
入力と出力だけ考えれば良くて、リアクティブで副作用なしでスケールアップ可能ってのが特徴なので、古典的バッチとはぜーんぜん違う

409 ：デフォルトの名無しさん：2016/10/29(土) 11:37:38.81 ID:z8URZLOb.net

やっぱりバッチ処理だなｗ

410 ：デフォルトの名無しさん：2016/10/29(土) 11:39:34.17 ID:z8URZLOb.net

バッチ処理を並列で動かすのと何も違いがないし

411 ：デフォルトの名無しさん：2016/10/29(土) 11:39:56.67 ID:ddj4bzvw.net

それを単なるバッチ処理と言うんだよw
それこそメインフレーム時代から続く伝統的なIPO型アーキテクチャだ

412 ：デフォルトの名無しさん：2016/10/29(土) 11:46:44.23 ID:7nyiPKGt.net

>>411
ユーザがファイルをアップロードしたらAWS Lambdaで計算して結果を返す（典型的な用途）
これがバッチ処理ならhttpサーバはバッチ処理してるんだなw

413 ：デフォルトの名無しさん：2016/10/29(土) 11:54:27.23 ID:ddj4bzvw.net

>>412
全く本質が見えてないな
それが関数型ならインプレース更新を行わない古典的なバッチ処理はだいたい関数型だと言ってるんだよ

414 ：デフォルトの名無しさん：2016/10/29(土) 11:59:58.74 ID:7nyiPKGt.net

>>413
本質が見えてないのはお前だよ
ただ単に、副作用がない関数でシステム書けば関数型か？って聞くならともかく
どっからバッチ処理が出てきたの?w

415 ：デフォルトの名無しさん：2016/10/29(土) 12:19:53.83 ID:ddj4bzvw.net

>>414
問題は処理の粒度
Lambdaにずいぶん夢見てるみたいだけど、Lambdaは呼び出しのオーバーヘッドが大きすぎる
現実的にはバッチ処理やS3にアップロードされた画像ファイルを処理するといった粒度の大きな処理単位でしか使い物にならん
そのレベル止まりなら全く目新しいものではなく、現代にあえて関数型だと言うなら粒度の小さな処理に対しても統一的に適用できる仕組みが必要
「Lambdaによるリアルタイム処理」みたいな言葉が独り歩きしてるが、あれスループット上げるために
わざわざKinesisを間に入れてマイクロバッチ処理に変換したりするんだぞ

416 ：デフォルトの名無しさん：2016/10/29(土) 13:30:02.46 ID:LoTR039H.net

OOPのメッセージパッシングも、所詮関数呼び出しじゃんって言ってそう、、、

417 ：デフォルトの名無しさん：2016/10/29(土) 19:08:25.95 ID:5tcsH0dx.net

粒度が荒くなると関数型じゃなくなるなんて
これまた珍妙な説出してきたなw

418 ：デフォルトの名無しさん：2016/10/29(土) 19:40:46.94 ID:jbWCC7sE.net

言語が一つじゃなくなる粒度とか
OSも言語もバラバラ

419 ：デフォルトの名無しさん：2016/10/29(土) 22:08:03.38 ID:z8URZLOb.net

>>417
副作用をもたらすから関数型じゃないんだよｗ

オブジェクト指向でも副作用がない関数を書いたら
それは関数型だって主張したいのかい？ｗ

420 ：デフォルトの名無しさん：2016/10/30(日) 05:32:40.80 ID:hqgegRgF.net

俺はこの問題に二十年取り組んできたが、結論は出てる。
「作者が関数型と主張した」言語が関数型だ。

そもそも最初はシンプルだったものも、どんどんリッチに汎用的になるに連れ
元来の関数型とは乖離していっている。
特にこの１０年、今まではそれでも範囲内で拡張するすべを探していたのが
妥協する策を取るようになった。

汎用でリッチなプログラミング言語としてはその方がずっと都合が良いからだ。
したがって今の著名でここのスレ民が主に思い浮かべるような言語は関数型ではない。
強いて言えば、作者が「関　数　型」と主張しているという程度のこと。
個人的には「関数型」言語とはもはや「P」言語に近い。

421 ：デフォルトの名無しさん：2016/10/30(日) 05:53:29.20 ID:h7Os3ze3.net

意訳

「>>420が関数型と主張した」言語が関数型だ。

422 ：デフォルトの名無しさん：2016/10/30(日) 09:14:34.70 ID:Iggl3vKB.net

ニセ科学に反対するだけで良かったのに
代案を出せとか煽られてついつい関数型という怪しいジャンルを作ってしまったんだな

423 ：デフォルトの名無しさん：2016/10/30(日) 13:43:32.58 ID:GS3Z8C14.net

今はマルチパラダイムな言語が増えてる、Adaとか

424 ：デフォルトの名無しさん：2016/10/30(日) 13:45:12.33 ID:h7Os3ze3.net

つーか殆どがマルチパラダイムじゃね？

そこに対抗してマルチパラダイムに対応できない言語が
純粋○○であることを売りにしてるけど、それ欠点だよねｗ

425 ：デフォルトの名無しさん：2016/11/08(火) 16:23:03.12 ID:/G9nZu79.net

うるっせえなこの馬鹿どもは
スクリプトの覇権は昨今の機械学習/AIブームでオッパイソンさんで確定したろ
あとは黙ってPython極めることに専念しろ

426 ：デフォルトの名無しさん：2016/12/03(土) 09:58:47.88 ID:rhALv8P7.net

PHP 7.0.x から PHP 7.1.x への移行
http://php.net/manual/ja/migration71.php

PHP7.1リリースｷﾀｰ! hackのnullable型導入とかか？
とりあえず x.1 待ちしてた奴ら移行しろよ。

427 ：デフォルトの名無しさん：2016/12/08(木) 09:29:51.63 ID:u0pmvICB.net

直也：.NET CoreというかC#って型があって、しかもサーバーサイドも書けるじゃないですか。Linuxでやってた人たちはずっとスクリプト言語使ってて、
Rubyとか型がない言語でサーバーサイド書いてることに疲れてきちゃってるんですよね。
ある程度の規模のものではサーバーサイドも型がある言語で書きたいと思って、
ScalaとかJava 8をやってみたんだけど、どの言語もちょっとバランスが悪いんですよね。
Scalaはプログラマ寄りすぎるし、Javaはコンサバすぎる。サーバーサイドSwiftもとがりすぎてるし。
実績があって型がある言語ってC#なんですよね。そのC#がLinuxで使えるのは大きいんですよね。
だから、ワンチャンあるなって。あとは市場が評価するかどうかなんですよね。
バランスはいいと思います。それがWindowsだけでなくMacでも使えるようになったのは本当に大きいですし。

428 ：デフォルトの名無しさん：2016/12/09(金) 01:22:51.17 ID:kfA92fVD.net

dartはいかが？

429 ：デフォルトの名無しさん：2016/12/09(金) 01:41:37.98 ID:IAKedM2U.net

>>428
いい加減現実を見よう
未来へ一歩踏み出そう

430 ：デフォルトの名無しさん：2016/12/09(金) 08:31:24.21 ID:GYMahviX.net

未来を見ず現実を見たつまらない言語がDartなんだが

431 ：デフォルトの名無しさん：2016/12/09(金) 08:50:43.91 ID:IAKedM2U.net

間違いはGoogleが現実の問題とニーズだけを見ていて自分の立場が見えていなかったことだな
そんなことをGoogleに求めている奴はいない
輝かしい切捨ての歴史を持つGoogleを土方分野で信用する馬鹿はいない

432 ：デフォルトの名無しさん：2016/12/09(金) 22:55:33.79 ID:K++XEq18.net

大事なのは言語云々よりDartVMでしょ
ブラウザへの統合を断念した時点で終わった

433 ：デフォルトの名無しさん：2016/12/09(金) 23:17:20.20 ID:IAKedM2U.net

>>432
ブラウザ統合自体が重要なのではなくてGoogleのやる気の問題だろう
Chromeに統合するという触れ込みで登場した当時は
Googleが本気だ! ということでそれなりにインパクトがあった
Dartが注目されていたのはそのGoogleの本気というただ一点だったのだから、
「結局いつものGoogleだった」となった時点で当然もう何も残らないよ

434 ：デフォルトの名無しさん：2016/12/10(土) 02:23:12.50 ID:Y9PwNia6.net

>>432
サーバ側ならどう？
typescripあるしphpも型付けることできる用になったから難しいかな？

435 ：デフォルトの名無しさん：2016/12/10(土) 07:47:45.47 ID:dczaGrMx.net

Goもあるし.NET Core(C#)も盛り上がってきたからねえ
残念ながらDartにはもう出番はないよ

436 ：デフォルトの名無しさん：2016/12/10(土) 09:53:52.20 ID:Q42P76Xv.net

wasm対応で先手を取れれば状況がひっくり返る可能性もあるが
asm.jsの時点でやる気0だったしなあ

437 ：デフォルトの名無しさん：2016/12/13(火) 09:18:46.65 ID:2oGa6DNb.net

https://chrome.google.com/webstore/detail/%E3%81%AF%E3%81%A6%E3%81%AAng/mbgdnfmdelffjdhkdggilmphfdihnmcj?hl=ja

438 ：デフォルトの名無しさん：2016/12/31(土) 15:42:56.02 ID:nUjD4DbZ.net

JavaScript死亡ｗｗｗ

「WebAssembly」がITの未来に変革もたらす｜Google、Apple、Microsoft、Mozillaが共同で開発した新概念

「WebAssembly」がWebブラウザに変革をもたらします。
Webブラウザは、もともとただテキストを表示するだけのところから始まりました。その出発点から、現在ではコミュニケーションやゲームまで幅広い表現を可能にしています。
そして今回、「Webブラウザ」に新しい概念が加わわることになりました。
それをもたらしたのが、ブラウザに関わりの深い世界規模の４社「Google」「Apple」「Microsoft」「Mozilla」が共同開発した、Webのためのバイナリーフォーマット「WebAssembly」です。
今回はその「WebAssembly」について、「スゴイところって何？」「何が起きるの？」をご紹介していきます。
WebAssemblyは「JS不要。コンパイラ言語だけで動的アプリが作れる」「どの言語でもWebブラウザ上にアプリを作ることができる」

WebAssemblyによってもたらされるスゴイところは次の4つ。
コンパイラ言語だけで、Webブラウザ上に動的なアプリが作れる
ほぼ機械言語にコンパイルされるからヌルヌル動く
OSを一切気にする必要がなくなる。気にするのはブラウザのみ
C,C 以外の言語でもWebAssemblyにコンパイルされる「クロスコンパイラ」の可能性が高まった

これまでWebブラウザで、ユーザからの入力情報を元に、動的なアプリケーションを実現するためには「JavaScript」が必須でした。

「インタプリター言語」であるJavaScriptは、その都度ソースコードを機械語に翻訳する必要があるため、予め機械語に近くコンパイルされる「コンパイラ言語」と比較すると動作が遅いという特徴があります（※）。

もしコンパイル後の機械語に近い形で、Webブラウザ上でコードが実行されたら。
JavaScript以上にヌルヌルに動き、しかもJavaScriptを気にする必要がなくなります。

それを実現したのがこの「WebAssembly」です。

https://mayonez.jp/1690

439 ：デフォルトの名無しさん：2017/01/03(火) 00:30:36.24 ID:pkTsP2s0.net

モンスターのアイコンの統一感がなさすぎるな
線が細いキャラと太いキャラを並べると違和感のかたまり

440 ：デフォルトの名無しさん：2017/01/03(火) 05:08:13.08 ID:sAzrCak7.net

>>438
今更な記事を引っ張ってこられてもな。
対応言語c,c++以外も増えたのかねぇ。

441 ：デフォルトの名無しさん：2017/01/03(火) 21:47:16.02 ID:m68UQ04g.net

どうだろうね。
まあ「その都度ソースコードを機械語に翻訳する必要があるため」遅い
という問題は、わかりやすい問題だから改善されていくよ。
最近だとV8で、即時関数っぽい書き方されたコードは最初から最適化して
すぐ実行できるよう準備するようにするパッチが入ったじゃん。
そういうのの積み重ねで良くなっていくと思うよ。

442 ：デフォルトの名無しさん：2017/01/04(水) 08:48:59.47 ID:u2CyXKSE.net

>>158
ただ自分の優位性を示したいだけの典型的な権威主義の馬鹿だな
自分の主張やは無いくせに〜ぐらいはしてるよね？とか
お前仕事場でも嫌われてるタイプだろ
少なくともHaskellは特定分野以外はまともに使えない
実際使ってればつまずくのですぐ分かる話

443 ：デフォルトの名無しさん：2017/01/04(水) 09:11:36.00 ID:u2CyXKSE.net

なんつう亀レスだ…はずかしい

444 ：デフォルトの名無しさん：2017/01/04(水) 10:10:34.13 ID:B3jxZHKh.net

Haskellはまだ趣味の範囲であらゆる分野で使える言語だよ。だって純粋関数型言語じゃないから。

445 ：デフォルトの名無しさん：2017/01/04(水) 11:41:28.60 ID:P9CxkEKM.net

>>444
貴方の思う純粋関数型言語の定義とその例を述べなさい(100字以内)

446 ：デフォルトの名無しさん：2017/01/05(木) 06:21:07.40 ID:sTWjNqOn.net

やだなぁ、やめてくれよ。
ただの皮肉だよん。

447 ：デフォルトの名無しさん：2017/01/08(日) 01:51:52.58 ID:+qBxgbmJ.net

このスレのお前らがどう思っているかが一番重要なんだよ
多くのヒントになるから
時代は常にこのスレで言われていた事の反対に進んだだろ？

今は静的型全盛で動的型ﾌﾟｯって感じだし
さんざんな言われようだったJSはむしろメジャー言語になったし
今JSが糞って言われているのは主に動的型だからだし
主要スクリプト言語もどんどん静的型の機能を取り入れているし
2000年代にはオブジェクト指向をやりたいならRubyをやれって言ってたのに
今Rubyはどうなった？静的型の機能はいつ追加されるの？Ruby3.0はいつ？

超ド近眼
ほんのちょっとの目先の手間を惜しんで
より面倒なハメにあう動的型信者らしいっちゃらしいがな

昔に動的型がブームになっていた頃から
糞だってはっきり言っていた人たちもたくさんいたし
単にお前らがド近眼ってこと

448 ：デフォルトの名無しさん：2017/01/08(日) 02:15:46.05 ID:+qBxgbmJ.net

どうでも良いことばかりに着目しているド近眼ってこと

449 ：デフォルトの名無しさん：2017/01/08(日) 16:59:24.13 ID:zEIuJeGz.net

何も分かってないなぁ。
このスレの奴らは静的型アンチでもないし、動的型信者でもない。
昔ながらの静的型と動的型のデメリットとメリットを比較した時、
動的型が肌に合ってた奴は多いが前提が変わるんなら勿論話は変わってくる。

そもそもスクリプト言語の奴らは良いものは何でも大歓迎で取り入れるのが好きだから、
言語に型表記機能が入れば喜んで使う。
動的型に慣れているからこそ、エンジンに型を理解してもらう大切さが良く分かってるからだ。
そこは全く矛盾したり対立したりすることではない。

それとJSが糞と言われていたのは、クラスベースでなく馴染みにくいとことと、便利ライブラリの欠如だ。
でも、ぶっちゃけ欠点のない言語は無いのに、JSがそこまで言われてた理由は、
実はJSの仕様の問題ではなく、DOM APIの仕様とブラウザの実装が酷かったからだ。

そこはむしろ糞って言われていたからこそ、様々な改善が試みられて、今これほどまでに良くなったんだよ。
けしてJSの周りの環境が本当は糞じゃなかったわけではない。
もう一度言うが糞だったから良くなれたんだ。そこは勘違いするな。

450 ：デフォルトの名無しさん：2017/01/09(月) 13:29:10.71 ID:tlAVTCLv.net

いいわけ乙

451 ：デフォルトの名無しさん：2017/01/09(月) 15:50:51.64 ID:NcQuvnbl.net

assertは書きたいことを大体書けるが、型表記機能とやらは書けないことの方が多い
型名はただの名詞だから
コミュ力が低下する薬を飲まされて名詞しか話せなくなったような面倒臭さがある

452 ：デフォルトの名無しさん：2017/01/09(月) 17:41:15.96 ID:+XRGLqqZ.net

それは当たり前だろうよ、縛りを設ける代わりに、主にIDEから恩恵を受けようというものだからね。
機械を自在に動かしたいというスクリプター的には、機械のために書いてるようで合わないだろうよ。

453 ：デフォルトの名無しさん：2017/01/17(火) 03:06:44.47 ID:lw1Zwsst.net

Pythonは素晴らしいけどPythonが素晴らしいのではなく、
Python周りのネイティブライブラリ環境が大変素晴らしい。
道具としては最高だけど、プログラミング言語大好き人間としては不満。
もっと速度を上げ柔軟になってくれたら嬉しいんだけど、もうそっち方面は目指してないみたいだね。

454 ：デフォルトの名無しさん：2017/01/17(火) 06:39:50.13 ID:rIfocs2Z.net

必要以上に手をかけると処理系のメンテが困難になり結果的に進化の足を引っ張ることになる
Rubyなんかまさにそうで、オタク共がよってたかって好き勝手にいじくり回したせいで詰んでる

455 ：デフォルトの名無しさん：2017/01/17(火) 07:09:05.55 ID:lw1Zwsst.net

でもPythonみたいにCythonで割り切るのもねぇと思う。
割り切ってもJSとどっこいどっこいの速度しか出んが。

456 ：デフォルトの名無しさん：2017/01/17(火) 19:48:56.56 ID:jfonssfd.net

>>454
具体的にどう詰んでるのか解説を

457 ：デフォルトの名無しさん：2017/01/18(水) 12:29:49.23 ID:RtvJVUCC.net

るびいは作者の頭とユーザーの頭と言語仕様が詰んでるって先生が言ってた

458 ：デフォルトの名無しさん：2017/01/18(水) 12:36:00.48 ID:FlJR5GPR.net

キチガイ

459 ：デフォルトの名無しさん：2017/01/18(水) 13:10:26.31 ID:jc+edUai.net

結果論だがPerlを批判するだけで勝てたんだよな
Pythonは本当にそれだけで勝った
Rubyは批判したいのか擁護したいのかはっきりしなかった

460 ：デフォルトの名無しさん：2017/01/21(土) 23:28:19.21 ID:sMDuy5hJ.net

2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
http://tamae.2ch.net/test/read.cgi/prog/1485008061/

461 ：デフォルトの名無しさん：2017/01/22(日) 14:38:27.08 ID:hBhrTyQG.net

https://chrome.google.com/webstore/detail/%E3%81%AF%E3%81%A6%E3%81%AAng/mbgdnfmdelffjdhkdggilmphfdihnmcj?hl=ja

462 ：デフォルトの名無しさん：2017/03/02(木) 01:30:06.94 ID:GY40xFBu.net

http://gihyo.jp/news/report/01/rubykaigi2014/0002?page=2
古い記事だけどやっぱ面白いね
何が嫌なのか知らないけど、静的型から逃げ回って
無駄に複雑なことになっていく感覚、本当にすごいわ
型さえ書けば済むことを、よくもここまで複雑にね〜
Unixの思想に反するわ

で、最新の情報ではRuby3.0はどうなることになっているの？
静的型は導入されるの？

でもま、今更導入するぐらいなら初めから導入しておけばよかったのにね
当時から静的型はあったでしょ、C言語とか静的型だし
そんでRubyはCで書かれてて自分は静的型の恩恵を受けてRubyを開発したはずなのにね
十分知ってたはずなのに、今更導入とか、それって筋悪いんじゃないの？何周遅れww
それを認めたくないから静的型の導入に対して渋々なんだろうけど
そんな詰まらないプライドで言語使用が決定されたらRuby使いはたまったもんじゃないね
でもそんな事(タイプセーフの重要性)は周りから見れば分かりきっていたことで
だから俺はRubyには近づかなかったわけでさ
微妙に消極的に静的型のメリットを語ってて、何をいまさらって感じなんだけど
本当に複雑怪奇だね

463 ：デフォルトの名無しさん：2017/03/02(木) 07:33:26.80 ID:m5ydKowW.net

>>462
スクリプト言語のほとんどは静的型じゃないけど、このスレ全体にケンカ売ってるのかな…？ｗ

464 ：デフォルトの名無しさん：2017/03/02(木) 12:26:11.03 ID:FleTjgpE.net

スクリプト言語っていろんなものの橋渡し、
間に入り込む接着剤のような役目なんだから動的型で間違っていない
ただそれだけでしっかりしたものを作ろうとすると大変だねってだけ

465 ：デフォルトの名無しさん：2017/03/02(木) 12:33:41.17 ID:GY40xFBu.net

俺が思うにRubyは夢を売る商売なんじゃないかと思う
ディズニーランドとか宝くじとか
あるいは漫画やアニメの専門学校と
同じようなモノなんだろう

466 ：デフォルトの名無しさん：2017/03/02(木) 13:05:30.50 ID:GY40xFBu.net

Rubyは意図的に静的型の機能を外したわけでしょ？
当時からC言語はあったし、RubyはC言語で開発されているんだから
知らなかったわけないんだよ
知ってて明確な意図をもって外したわけでしょ
それをいまさら導入とか意味不明だよね
だったら初めから導入していればよかったわけで
あとから導入するの大変でしょ
これが何か目新しい概念とかだったら時代背景とかと合わせて
あとから導入はわかるんだけど
静的型って大昔からあって、むしろスタンダードだったわけで
今更検討とか今もう2017年だよ？何やってんだよ
まったくの迷走だよ

467 ：デフォルトの名無しさん：2017/03/02(木) 14:33:53.15 ID:OL5emEw+.net

結論としてJuliaってことだね

468 ：デフォルトの名無しさん：2017/03/02(木) 15:55:48.82 ID:iFkNWUjs.net

無知の長文

469 ：デフォルトの名無しさん：2017/03/02(木) 16:21:28.87 ID:k95nzBVS.net

crystal もよろしく

470 ：デフォルトの名無しさん：2017/03/02(木) 23:42:14.51 ID:JZiPjSZc.net

>>466
動的型は実装が簡単なんだよ

471 ：デフォルトの名無しさん：2017/03/03(金) 03:21:52.12 ID:oJ3jWx7w.net

>>470
逆だが…動的型の方が面倒くさい
>>466 はただの荒らしだからまともに取り合うとロクなことないよ

472 ：デフォルトの名無しさん：2017/03/03(金) 07:12:07.86 ID:4qcBtzlj.net

>>471
動的型信者が静的型をdisるときによく言う「静的型の方が型が決まってるから実装が楽だが〜」
みたいなのを真に受けてるのかな
自分で簡単な言語を実装してみたらわかるよ
問題は型が静的か動的かよりも静的コンパイルの実装コスト

473 ：デフォルトの名無しさん：2017/03/03(金) 12:07:08.08 ID:ivKlbKhz.net

静的コンパイルはコンパイル系と実行系で処理系が2重になるのが複雑
あらかじめ仕様をきっちり決めておかないと手戻りが多発するからスクリプターのノリで適当に作るのは困難

474 ：デフォルトの名無しさん：2017/03/03(金) 12:34:26.64 ID:IT/QqIXj.net

コンパイラも自作しちゃえばいいのよ

475 ：デフォルトの名無しさん：2017/03/03(金) 17:08:10.47 ID:bWq8JKgn.net

仮に動的型のほうが静的型のよりも
最適化を含めるとなると難しいんだったとしても
それはまったく無駄な努力だからな
あと、動的方言語を静的に解析してエラーを見つけるのは難しいんだけど
それも無駄な努力だからな
静的型にすれば済む話
問題を直接解決しようとせず、周りをウロウロして何とかしようとするのは無駄
最近の言語に静的型が多いのは、誰も無駄な意味のない努力をしたくないから
動的型は、何か、ズレてるんだろう
砂糖と塩を輸送するのにブレンドして輸送する感じ
もしかしたら輸送費は安くなるかもしれないが
後で分離する手間考えたら分けて輸送したほうが良い
動的型の型を静的に解析するのはまさにそれに等しい行為
手間が増えるだけ

476 ：デフォルトの名無しさん：2017/03/03(金) 17:15:56.85 ID:bWq8JKgn.net

静的型言語の実装の難易度を基準とすると
動的方言語は、とりあえず動けばよいってレベルなら超楽勝
しかし実用になるレベルにするのに
まじめに最適化を実装しようと思うと途端に難易度は跳ね上がり超絶難易度になる
間は無い
うま味がないってこと
誰も手を出さなくなったわけだ

477 ：デフォルトの名無しさん：2017/03/03(金) 17:18:10.38 ID:GTe30Tvn.net

糖質なフレンドだね

478 ：デフォルトの名無しさん：2017/03/03(金) 17:28:09.10 ID:bWq8JKgn.net

GoogleのV8エンジンとかは、技術的に本当に興味深く凄いなぁと思う反面
あんな苦労は絶対したくないし
言語仕様のほうをどうにかしたほうが手っ取り早いのは確実
本当に動的型言語は何するにしても無駄に壮大で大変だなぁ
静的型言語が全ての答えなのにね

479 ：デフォルトの名無しさん：2017/03/03(金) 18:31:58.34 ID:BNfiYHeO.net

V8はC++で書かれているけど、
Chrome含むGoogleのC++はマクロで魔改造されてる。
C++のマクロだけじゃなく、Pythonも使ってソースコード置き換えをしてる。
結局「全ての答え」などというものはない

480 ：デフォルトの名無しさん：2017/03/03(金) 21:12:00.24 ID:wq3/hASM.net

全ての答えおじさんは自分で言語作ったりするの?
ただのユーザだったらうけるんだが

481 ：デフォルトの名無しさん：2017/03/03(金) 21:45:28.70 ID:aYsFsxPN.net

動的言語を速くする努力なんて無駄だっていうけど
Javaが速くなったのはV8と同じ技術の流用だろ？

482 ：デフォルトの名無しさん：2017/03/04(土) 13:07:22.03 ID:TytE5WQL.net

むしろJavaが先駆者というかJIT技術の長年の代表者かな
でもJavaとV8は実際やってることは全くと行っていいほど違う

何故かと言うとJavaは結局コンパイルしてバイトコードにした時点で実際の最適化の殆どは済んでいる、実際はJITはオマケのコンパイル言語だ
そこから少しだけプロファイルを取ったり、各環境向けに最適化するが、微々たるもの
そもそもバイトコードにした時点で情報が結構失われるからそこからJITするのに限界がある構造

でも静的なのでそんなチャレンジングなことをしなくても大体のケースで十分に最適化できるので
バイトコードサイズを小さくする方を取ってるが、実際幾つかのケースでV8含む完全ソースが手元にあるJITに負ける
一方V8は実行時というか実行前から実行中までずっと最適化し続けるJITをやや超えるもの

483 ：デフォルトの名無しさん：2017/03/04(土) 15:50:13.16 ID:W8crb5iK.net

Javaなんかコンパイラがどんなに良質なバイトコードを吐いたところでJITを切ったら使いものにならないよ

484 ：デフォルトの名無しさん：2017/03/04(土) 20:30:51.92 ID:TytE5WQL.net

動的コンパイル≠JITコンパイル

485 ：デフォルトの名無しさん：2017/03/04(土) 20:49:23.65 ID:9zDoQRRc.net

JITコンパイル≠HotSpot技術≒V8の技術＝anamorphic

486 ：デフォルトの名無しさん：2017/03/04(土) 21:09:43.19 ID:9zDoQRRc.net

>>482
オマケのわりにはクリティカルじゃね？
http://blog.cybozu.io/entry/2016/04/13/080000

487 ：デフォルトの名無しさん：2017/03/04(土) 22:43:59.15 ID:W8crb5iK.net

Animorphic Smalltalk VMやね

488 ：デフォルトの名無しさん：2017/03/05(日) 01:08:23.00 ID:MrlX2Uoe.net

>>486
2倍は全くクリティカルではない
JSだとJITは数十から数百倍のスケールで恩恵がある

489 ：デフォルトの名無しさん：2017/03/05(日) 07:40:06.85 ID:c4lSj3ER.net

>>488
それベンチマークに特化したコードでの話じゃね？
それならJavaでも似たような差がでるよ

490 ：デフォルトの名無しさん：2017/03/05(日) 19:03:52.33 ID:ONGjQtv5.net

>>489
良いことなのかも知れないけれど、昔のインタプリタの頃のとてつもない低速度忘れちゃったんだな

491 ：デフォルトの名無しさん：2017/03/05(日) 20:03:49.77 ID:tiOeAN9d.net

>>490
Java VMは今も昔と変わらずバイトコードインタプリタだよ？

492 ：デフォルトの名無しさん：2017/03/05(日) 21:02:12.11 ID:xrJm/RDc.net

THE　アスペ

493 ：デフォルトの名無しさん：2017/03/05(日) 21:12:38.66 ID:ONGjQtv5.net

いいんやで、もうどうでも

494 ：デフォルトの名無しさん：2017/04/13(木) 09:59:12.88 ID:z2xiyw8y.net

TypeScriptの採用が増えそうで俺歓喜

Google社内の標準言語としてTypeScriptが承認される。ng-conf 2017
http://www.publickey1.jp/blog/17/googletypescriptng-conf_2017.html

Google、社内標準言語の一つとしてTypeScriptを採用
https://developers.srad.jp/story/17/04/11/0718244/

495 ：デフォルトの名無しさん：2017/04/15(土) 23:41:19.57 ID:Af1/s0zG.net

http://gihyo.jp/news/report/01/rubykaigi2016/0001
まったく往生際が悪いというかなんというか、何の意味があるの？
一方ロシアは鉛筆を使ったって感じ
「負けたんだよ」ってだれか言ってあげて

496 ：デフォルトの名無しさん：2017/04/16(日) 00:02:02.80 ID:AmA5ei6y.net

大体型を書くのが面倒ってのも良くわからないし、型推論とかもあるのにな
あと型が書いてあったほうが読みやすい場面も多々あるし
機械にもわかりやすくて人間にもわかりやすくて、丁度よいじゃないか
あとほか宣言があると・・・宣言は型だけじゃなくスコープの宣言でもあるわけでして
宣言なし言語はスコープが気持ち悪いことになってるのが多いよなw

それからダックタイピングは本当に必要なのかどうなのか
静的型であってもジェネリックやテンプレートやオーバーロードがあれば
静的なダックタイピングは可能なわけで、しかもタイプセーフだし
動的なダックタイピングなどという危険極まりないものが本当に必要なのか？
ダックタイピングは静的に解決できる範囲で楽しめばよいだろうよ
それですら黒魔術とか言われるのにな

あと、WebAssemblyな、結局C++などの静的型言語を中間言語にしたものを
ブラウザで読み込んで機械語に変換して実行しようよっていう
どこまで行っても結局型が判明しているほうが最適化しやすいよね
CPUの進化が鈍化してきているし、物理的限界が近いことも考えれば当然の流れだな

497 ：デフォルトの名無しさん：2017/04/16(日) 05:04:24.13 ID:O+EWztiU.net

WASMでDOM操作とか夢のまた夢だし、
そもそもJavaでのDOM操作も実情はきつかったし
別にWebで無くてもいいような１つのアプリケーションを作るんなら
型は有用だけど、何かと何かをくっつけたり、加工したりするための
スクリプト言語としては全くの不要だよ

498 ：デフォルトの名無しさん：2017/04/16(日) 07:06:11.63 ID:aIkdKg/w.net

>>496
> それからダックタイピングは本当に必要なのかどうなのか
> 静的型であってもジェネリックやテンプレートやオーバーロードがあれば
> 静的なダックタイピングは可能なわけで、しかもタイプセーフだし

ダックタイピングのこと分かってないだろ

499 ：デフォルトの名無しさん：2017/04/16(日) 09:52:33.87 ID:SqhlDt4o.net

ダックタイピングはそれをプログラマが活用するのではなく
動的言語における多態性の(安易な)実装手法にすぎない

500 ：デフォルトの名無しさん：2017/04/16(日) 10:22:58.46 ID:XyqfpBE9.net

という完全に誤った理解が蔓延しているというお話し

501 ：デフォルトの名無しさん：2017/04/16(日) 10:23:01.86 ID:AmA5ei6y.net

>>495のURL先は皆読んでくれたかわからんが
掛け違えたボタン感が本当にすごくて
最初の一歩を間違えるとこんなにも面倒なんことになるのかって感じ
北朝鮮はどこまで進化しても北朝鮮ってことなんだろうよ
うすら寒い理想の未来を語るところもよく似ている
過去に生きて、未来を語って、現在に生きてないって感じ
まさに掛け違えたボタンで、「現実」のボタンをスキップして飛ばしている
胡散臭い宗教とかもそんな感じだよね
たぶん「現実」に不満がある人を集めるのが目的だから
過去の技術を使って、未来を語ってみせて、騙くらかすって事なんだろうな
これがまさしく、走り続けないと終わる、の意味だろう
でももう流石に誰も騙されないよね
麻疹みたいなものだから、学生さんは一度はそういう目に合うかもだが

502 ：デフォルトの名無しさん：2017/04/16(日) 10:25:51.21 ID:AmA5ei6y.net

もしくは、ボタンを掛け違えていることに本人だけが気付いていなくて
誰も追いついてこないな〜なんて思っていたら
実はみんなもっと遠いところで高度なことをやっていた、ってパターンか
誰も追いついてこないんじゃなくて、フォロワーが居ないってことなんだけどね

503 ：デフォルトの名無しさん：2017/04/16(日) 11:27:58.86 ID:cCOM2/u0.net

ダックタイピングというのは、（人間が）ガーガーと
アヒルのモノマネをすれば、アヒルとみなして扱おう
という発想から生まれたもの

504 ：デフォルトの名無しさん：2017/04/16(日) 15:33:13.73 ID:aIkdKg/w.net

>>501
ダックタイピングのことを何も分かってない人間がいくら言おうと説得力はゼロだよ

505 ：デフォルトの名無しさん：2017/04/16(日) 16:41:45.39 ID:AmA5ei6y.net

残念ながら>>499が正解なんだな〜
俺も、もし何かの都合で自分で言語を作る必要性に駆られたら
そうするだろうね、実装が圧倒的に楽だから

つまり、自分で言語を作って、自分で使うんなら
現代においてもなお、動的型はありうるんだよ、これが
言語を作る手間と時間もコストとして換算して
トータルで労力を最小にしたいから
どこでバランスするかの問題

もしくは自分はもっぱら言語を作るのがメインで、使うのは他のやつって場合も
自分だけが楽できれば良いという身勝手な発想に行き着いたのなら、ありえる
自分は静的型言語でその恩恵を十分に得ながら言語開発して
他人は自分の作った言語で苦しむっていう
人として最悪な感じにはなるけど、まぁ最終的には良心の問題
金もうけのためだったり仕事って事なら仕方ないけど
人生の目標にしたら只の嫌がらせだな

それはそれとして、既存の言語を使うだけなら
わざわざ手抜きな言語をあえて選択する意味はないよ

506 ：デフォルトの名無しさん：2017/04/16(日) 16:43:12.44 ID:aIkdKg/w.net

>>505
ダックタイピングをジェネリクスで代替できると思ってる人間の論理に説得力はない

507 ：デフォルトの名無しさん：2017/04/16(日) 16:45:25.04 ID:cCOM2/u0.net

ダックタイピングはジェネリクスではなく
インターフェースで代替するもの

508 ：デフォルトの名無しさん：2017/04/16(日) 16:49:53.76 ID:aIkdKg/w.net

>>507
その通りだね

そしてインタフェースをいちいち付けてまわるのは非常に面倒臭いこと
自分で作るクラスならまだ何とかなるが、使ってるライブラリのクラスだとそうもいかない

509 ：デフォルトの名無しさん：2017/04/16(日) 16:54:54.02 ID:cCOM2/u0.net

> そしてインタフェースをいちいち付けてまわるのは非常に面倒臭いこと

めんどくさい？ ダックタイピングではインターフェースがないから
代わりにコメントで同じ情報を書かないといけないじゃん。

インターフェースの情報（コメント含む）を書かないで
それが仕様かどうか分かってもらえると思ってんの？

510 ：デフォルトの名無しさん：2017/04/16(日) 17:00:32.58 ID:aIkdKg/w.net

>>509
コメントなら書くか書かないかは開発者が選べる
それを「低レベルコード生産要素」と見るか「プログラマの自由を保証」と見るかは
ポジションによる

Matzなんかは後者の立場なんだろうし、日本のSIのような人月計算でレベルはおかまいなしのような
プロジェクトに関わってるような人から見れば前者になるんだろうね

511 ：デフォルトの名無しさん：2017/04/16(日) 17:01:19.16 ID:AmA5ei6y.net

「静的な」ダックタイピングはジェネリックとオーバーロードで実現可能
という風に書いたのにこれが理解できないのではどうしようもない
きっと静的と動的の違いも理解できてないんだろう
静的なダックタイピングはタイプセーフだし
本当にうまい落としどころだなぁって思う
何もかもが静的型に都合がよいように回ってて、ちょっと怖いね
とはいっても俺も何でもかんでも型で解決しようってのはあまり好きじゃなくて
一つのアイデアが上手くいくと一気に乗っかっていく感じは何か過剰というか
ただ、そうはいってもダメなものがダメなことには変わりないんだけどね

512 ：デフォルトの名無しさん：2017/04/16(日) 17:01:47.01 ID:cCOM2/u0.net

>>510
> コメントなら書くか書かないかは開発者が選べる

言い換えると、
コメント書きたくない、仕様書を書きたくない。
コード読まないとわからない。
というコードを書きたいってことか？

ひどいな。だから可読性が下がるんだよ。

513 ：デフォルトの名無しさん：2017/04/16(日) 17:03:04.51 ID:aIkdKg/w.net

>>511
ぜんぜん違う
ほんとダックタイピング分かってないんだな
ID:cCOM2/u0 なんかはその辺分かってるから議論になるけど、お前にゃ無理だよ

514 ：デフォルトの名無しさん：2017/04/16(日) 17:07:46.06 ID:aIkdKg/w.net

>>512
Matz の有名な言葉に「ソースがドキュメントだ．バグも完全に記述されている」ってのがあるからねぇ
冗談半分だとしても、思想としてそういう方向なんだろう

本気半分の言い分としては、ソース読んだだけでちんぷんかんぷんなコードはその時点で怪しいと思え
って感じだろうか

515 ：デフォルトの名無しさん：2017/04/16(日) 17:08:31.24 ID:cCOM2/u0.net

インターフェースは契約プログラミングの一種でもあるんだよ。
インターフェースを定義することは事前条件を定義することにあたる。
事前条件を記述することで、予め（プログラムを実行しなくても）バグがあることがわかる。

実行パスは無限と言ってもいいほどあるから、実行しなければ
わからない問題を検出するのは時間がかかる。

だけど、条件を満たすかどうかを調べるために、
実行そのものが必要なければ、短時間で問題が検出できる。

コンピュータが理解できる方法で、しかも実行せずにわかることと
コメントという人間しか読めない方法で書くのとでは全然意味が違う

516 ：デフォルトの名無しさん：2017/04/16(日) 17:09:43.45 ID:AmA5ei6y.net

静的型において動的な多態にインターフェースを使うのは当たり前
動的なことは危険な香りがするから、インターフェースで制約する
これも丁度よいぐらいの落としどころなんだよ

静的な多態はジェネリックとオーバーロードでダックタイピングも可
動的な多態はインターフェースを通して安全に
どちらの場合もタイプセーフ

よくできているよね〜

517 ：デフォルトの名無しさん：2017/04/16(日) 17:10:37.85 ID:aIkdKg/w.net

>>515
そういう方向でバグを減らすというのもひとつの方向性としてはいいんじゃない？
単なる思想の違いというだけで、そういうのが嫌いな人が作った言語だって別に悪いわけじゃない

518 ：デフォルトの名無しさん：2017/04/16(日) 17:12:57.07 ID:aIkdKg/w.net

>>516
だからお前はダックタイピング分かってないんだからもういいよ
staticおじさんのように、分かってない機能は全部けなす方向性の人間と議論になんかならんからな
まずお前にすすめるのはリーベルGの「高慢と偏見」を読めってことだ

519 ：デフォルトの名無しさん：2017/04/16(日) 17:13:47.39 ID:cCOM2/u0.net

>>517
> そういう方向でバグを減らすというのも

そういう方向で"も" な

バグを減らすテクニックはいくつもある。
静的言語なら、そのテクニックが増えるわけだ

動的言語でできるバグを減らすテクニックは、静的言語でも使える。
さらにプラスして、静的言語ではコンパイル時に実行することなく
バグを減らすことが可能になる。

これは明らかにバグを減らすために追加された機能といえるだろう

520 ：デフォルトの名無しさん：2017/04/16(日) 17:15:16.10 ID:aIkdKg/w.net

>>519
そのために生産性やプログラマの自由が減るというトレードオフがあるけどね
そのトレードオフのどっちを取るかはポジションで決めればいいだけの話

521 ：デフォルトの名無しさん：2017/04/16(日) 17:16:58.16 ID:AmA5ei6y.net

ちなみにダックタイピングは、ダックのように振舞うものは、ダックとして扱える
って言ってるだけで
静的に解決するか、動的に解決するかは、別の問題であり
当然静的なダックタイピングは、ある

>ダック・タイピング
>https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0
>C++のtemplateはダック・タイピングの静的版である

残念だったなwww
それともWikiを書き直すか？

522 ：デフォルトの名無しさん：2017/04/16(日) 17:18:10.05 ID:aIkdKg/w.net

>>521
俺はテンプレートに関しては何も言ってないが？
ジェネリクスはちゃうやろって言ってるんだが

523 ：デフォルトの名無しさん：2017/04/16(日) 17:20:02.41 ID:cCOM2/u0.net

>>520
> そのために生産性やプログラマの自由が減るというトレードオフがあるけどね

減ってないよ。逆に高くなっている。
っていうか、あんた書くときのことしか考えてないでしょ？ｗ

プログラミングっていうのは書くよりも読むことのほうが遥かに多い。
だから、可 "読" 性 が重視される。

読みやすいコードは生産性を大きく上げる

524 ：デフォルトの名無しさん：2017/04/16(日) 17:27:15.74 ID:0ImhO/qF.net

>>521
× C++のtemplateはダック・タイピングの静的版である
○ C++における型消去はダック・タイピングの静的版である

明らかに間違ってるから直しとけよ

525 ：デフォルトの名無しさん：2017/04/16(日) 17:29:05.78 ID:aIkdKg/w.net

>>523
それは違うな
コメントなら引数を「与えられる方」だけ書けばいいが、インタフェースは引数を「与える方」にもそれを強制する
そしてこれは結構面倒な作業だ

もちろん、引数として変なものを与えてしまう可能性も出てしまうが、それと上記の面倒さをどっちを取るかは
それぞれの人が決めればいい

526 ：デフォルトの名無しさん：2017/04/16(日) 18:04:26.80 ID:AmA5ei6y.net

現代に生き残りし貴重なサンプルだとは思うが
「何が面倒か」までは書かないんだよな
結局、何でもかんでも渡すわけにはいかないのは同じこと
どのみち仕様を満たさなきゃならん
ダックならダックの仕様を満たさなきゃならん
ダックの仕様を満たすように書かなきゃならないのと
ダックのインターフェースを満たすように書かなきゃならないことは
実質問題大差ない
大差ないか、むしろインターフェスがあった方が何をすべきかよくわかるぐらいだ
仮にこのケースでほんの少しだけ動的型が便利だったと仮定しても
静的型の、型安全性、リファクタリングのしやすさ、タイポなどの些細なミスの検出
型が書いてあることによるドキュメンテーション、最適化のききやすさ
あと宣言があることによるスコープの細かさ
これらすべてを投げ捨てるほどの差はない
動的型のメリットといえばもはや動的なメタプログラミング的な何かぐらいしかないが
そんな黒魔術はどうでもよいし、はっきり言ってgoto文と変わらない

527 ：デフォルトの名無しさん：2017/04/16(日) 18:10:54.82 ID:AmA5ei6y.net

こういうと彼はきっとこう思う
静的型は互いに別々の出どころのライブラリ間で
インターフェースに互換性がないから困る、と
しかし、そんなことは動的型でも同じこと

528 ：デフォルトの名無しさん：2017/04/16(日) 18:14:22.59 ID:cCOM2/u0.net

>>525
クラスだけ与えられて、
さてこのクラスはどこで使えるでしょう？
みたいなクイズして楽しいか？

このクラスが持っているインターフェースは何かって
ちゃんと書いていれば、そのインターフェースを使える場所も
明確にわかるだろ

529 ：デフォルトの名無しさん：2017/04/16(日) 18:15:43.11 ID:cCOM2/u0.net

>>526
> 「何が面倒か」までは書かないんだよな

それだよなｗ
ほんと何が面倒なのか。

530 ：デフォルトの名無しさん：2017/04/16(日) 18:20:36.92 ID:aIkdKg/w.net

>>528
アプリケーションの全クラスが自分の管理下にあればそれも可能かもしれんな
でも実際は様々なライブラリを使うことは避けられないし、各ライブラリのクラスに後から自分が欲しい
インタフェースを追加することはできないことがほとんど

C#やScalaなんかはそういうこともできるみたいだが、今度は可読性が落ちるのでここぞというときの
秘密兵器扱いだな

531 ：デフォルトの名無しさん：2017/04/16(日) 18:26:41.26 ID:cCOM2/u0.net

>>530
各ライブラリのクラスに後から自分が欲しいインターフェースを追加して、
正しく動く保証はあるのですか？

そもそもそんなことする必要ありませんよね？

532 ：デフォルトの名無しさん：2017/04/16(日) 18:29:04.31 ID:cCOM2/u0.net

手段が目的になってしまってるんだよなｗ

何がしたいのかは言わない。
ライブラリのクラスに後からインターフェースを追加することが
目的なんだって臆面もなく言ってしまうｗ

533 ：デフォルトの名無しさん：2017/04/16(日) 18:34:11.12 ID:aIkdKg/w.net

>>531
あるよ

たとえばあるライブラリがAというクラスのオブジェクトを返したとする
これを別のライブラリか自分で作ったクラスのの引数として使いたいけど、その引数はBという
インタフェースを要求する

Aというクラスは字面の上ではBというインタフェースを満たしているのだが、Bというインタフェースを
implement しているわけではない

さてどうしよう
Bというインタフェースを持つクラスを自分で定義してコピーする？こんな余計なことしなきゃいけない
のは生産性の低下以外の何物でもないわな

これは一例であって他にも同様の例はいくらでもある

534 ：デフォルトの名無しさん：2017/04/16(日) 18:43:08.06 ID:cCOM2/u0.net

>>533
なんでAというクラスが、Aとは全く関係のなく作られたBというインターフェースを
たまたま運良く満たすなんて自体が起きるんだよｗ

ありえないだろ。

それよりか引数が違うのに、同じ名前のメソッドを定義してしまっていた
どうしようって思うほうが可能性高いわｗ

535 ：デフォルトの名無しさん：2017/04/16(日) 18:46:33.36 ID:cCOM2/u0.net

Aというクラスは字面の上ではBというインタフェースを満たしているのだが、
Bのバージョンアップでインタフェースが変わってしまった。

だけど、Aというクラスがたまたま古いBのインターフェースと
一致していたという前提をどこにも書いていなかったので、
動かなくなる原因の判明に時間がかかった。

そのためにコメントをしっかり書くようにした。

A は B interface を implements しているよと

536 ：デフォルトの名無しさん：2017/04/16(日) 18:50:50.79 ID:aIkdKg/w.net

>>534
ありえるんだよ、これが
しかもしょっちゅう
(俺は静的型言語でも開発してるからよく出くわすよ)

たとえば、Serializable なんか典型じゃないかな
そのまま Serialize したいのになんで Serializable インタフェース持ってねぇんだよ！
みたいなのはほんといくらでもあるよ

537 ：デフォルトの名無しさん：2017/04/16(日) 18:53:05.94 ID:cCOM2/u0.net

このようにダックタイピングを使うとその場しのぎで直ぐに対応できるように思えるけど
長い目で見れば、可読性の低下を招き、メンテナンス性、生産性を下げることになってしまう。

書いたら終わり、メンテナンスが不要な書捨てのプログラムぐらいにしか
使わない方がいい。

そして、書捨てのプログラムをよく書くのはインフラ系が多い。
インフラ系で必要とされるのはオブジェクト指向も必要ない
数行程度のスクリプト。シェルスクリプトよりは書きやすいぐらいの
理由しか持ち合わせてない

アプリの開発には長期間メンテナンスされるので可読性が重要

538 ：デフォルトの名無しさん：2017/04/16(日) 18:56:36.72 ID:cCOM2/u0.net

>>536
> そのまま Serialize したいのになんで Serializable インタフェース持ってねぇんだよ！

そのクラスがSerializeする機能を実装してないからだろ？

539 ：デフォルトの名無しさん：2017/04/16(日) 19:04:01.20 ID:cCOM2/u0.net

http://rubytips86.hatenablog.com/entry/2014/03/19/184940

Rubyでこのシリアライズとデシリアライズを担うライブラリがMarshalモジュールだ。
注意点としてMarshal.dumpでは、無名のクラス・モジュールのオブジェクト、
システムがオブジェクトの状態を保持するIOなど、
Procなどいくつかのインスタンス、特異メソッドを定義したオブジェクトはシリアライズできない。

540 ：デフォルトの名無しさん：2017/04/16(日) 22:32:15.20 ID:AmA5ei6y.net

第一だよ
全然関係ないライブラリ同士でたまたま字面の上で
メソッド名が一致しているクラスがあるっていう
偶然の一致があったとしても
その動作振る舞いまでもが完全に一致していて
動作的にコンパチブルかどうかは分からないよ
想定してないんだからさ
おおよそ慣例というか習慣というか、その言語ではふつうそうするって
何らかの決まり事みたいなものがあるのなら問題ないかもしれないが
そういう場合は言語側やファウンダメンタリーなライブラリが
インターフェースを定義してくれているから、それ使えばよいわけで
やっぱり関係ないんだよ

そういうメソッド名と振る舞いの両方が偶然にも一致
っていう奇跡偶然に頼るってのが
まさにおまえ自身が>>530で言ってる

>アプリケーションの全クラスが自分の管理下にあればそれも可能かもしれんな

そのものなんだよ、まったくのブーメラン

541 ：デフォルトの名無しさん：2017/04/16(日) 22:54:49.91 ID:aIkdKg/w.net

>>540
ダックタイピングのことを知らないお前が言っても説得力はないよ

542 ：デフォルトの名無しさん：2017/04/16(日) 23:27:02.64 ID:f4lMQoiy.net

言い争いの起点がどこにあるのかわからん

543 ：デフォルトの名無しさん：2017/04/16(日) 23:30:25.86 ID:aIkdKg/w.net

>>542
>>496 >>498

544 ：デフォルトの名無しさん：2017/04/17(月) 00:16:09.41 ID:W0pN1+cl.net

要するに、後付で色々したい場合はダックタイピングの方が楽なんだよ。
ただし、全てを見通せるのなら最初からインタフェースにしておいた方が美しいのも事実。

現実的にはJavaScriptはUI用で酷く書き換えを強いられる為、
ダックタイピングの方が向いている。(と俺は感じている)
逆に、仕様がかっちり決まっている場合は型ありでも特に苦労しないし、
数値計算等のバグ出ししにくい状況では型があった方が安心ではある。
(期待値が作りにくい、見た目でバグと分からない）
ただ、UIならバグは見て分かるし、ダックタイピングでも問題ない。
動的言語はパターンを当てないとバグ検出出来ないけど、
UIなら「変更が依頼された」＝「パターン持ってる」ってことだし。

545 ：デフォルトの名無しさん：2017/04/17(月) 01:28:08.77 ID:8mjeDRwA.net

真面目にダックタイピングをやろうとする行為は、型やインタフェースを定義するのと違いがない
だからrubyでダックタイピングを考えてプログラミングしてる人なんているわけない

546 ：デフォルトの名無しさん：2017/04/17(月) 03:12:15.72 ID:LB/3uUQe.net

>>544
あの、精神論でごまかさないでください？
何一つ、ダックタイピングのほうが良いという理由を
言っていませんよ

547 ：デフォルトの名無しさん：2017/04/17(月) 07:17:22.30 ID:W0pN1+cl.net

>>546
良い悪いを議論する事じゃないよ。
結局は、どう思うか、どう感じるか、でしかないから。

型には型の得失があるし、ダックタイピングにしてもそう。
選べる状況なら好きな方選べばいいし、無理ならグダグダ言っても意味無いだろ。

利点を感じないのなら、これまでそういう状況に遭遇したことがないか、
或いはそもそもそっち派ではないか。
いずれにしても使わないってことで問題はない。
利点説明おねだり君なんてウザイだけだから止めろ。

http://yohshiy.blog.fc2.com/blog-entry-244.html
未確認飛行の人も同じようなことを言っていたと思ったけど見つからなかったから上記で。
結論出したいのならこの辺だと思うよ。

>>545
ガチでダックタイピングの利点を享受しようとすると、
型に留まらず世界が統一されていないといけないので、実は型よりも難しい。
そしてJavaScriptもそれに対応出来ていない。理由は標準化している奴らが馬鹿だから。
sizeとlengthが混在してるでしょ。
あれ、どっちでもいいけどどっちかに統一されてないといけない。

だから真面目にダックタイピングをやっている奴なんていない、というのは俺も思う。

548 ：デフォルトの名無しさん：2017/04/17(月) 09:32:26.96 ID:LB/3uUQe.net

> そしてインタフェースをいちいち付けてまわるのは非常に面倒臭いこと

めんどくさい？ ダックタイピングではインターフェースがないから
代わりにコメントで同じ情報を書かないといけないじゃん。

インターフェースの情報（コメント含む）を書かないで
それが仕様かどうか分かってもらえると思ってんの？

549 ：デフォルトの名無しさん：2017/04/17(月) 09:43:33.93 ID:oCHN+Sd+.net

>>540
同じインターフェースを実装してても、それは引数と戻り値の型が一致するだけで
動作振る舞いがコンパチブルかどうかは保証してくれないけどな
JavaやC#みたいなショボい言語では

550 ：デフォルトの名無しさん：2017/04/17(月) 21:03:29.03 ID:LB/3uUQe.net

>>549
interfaceは"インターフェースを"保証してくれるもので
インターフェース以外は別の話なのは当たり前だと思うが？

「お前型を保証してくれるんだろ？
バグがないことまで保証してくれよ」

っていうのと同じぐらい無茶なこと

普通保証の対象しか、保証しませんってｗ

551 ：デフォルトの名無しさん：2017/04/17(月) 22:17:56.90 ID:BH39VCMj.net

>>549
ショボくない言語ではどういう感じになるのでしょうか？
純粋な興味として知りたいです

552 ：デフォルトの名無しさん：2017/04/17(月) 23:27:50.92 ID:LB/3uUQe.net

しょぼくない言語なら、
動作振る舞いがコンパチブルかどうかを保証してくれるんだろう？

553 ：デフォルトの名無しさん：2017/04/18(火) 00:29:01.98 ID:n/IUHgwq.net

>>544
> 要するに、後付で色々したい場合はダックタイピングの方が楽なんだよ。

メソッドや関数のオーバーロードが可能なら静的型でも変わらなくない？

554 ：デフォルトの名無しさん：2017/04/18(火) 01:27:12.80 ID:xAHUlHha.net

>>553
いや、それだと全部用意しないといけなくなるでしょ。
ダックタイピングだと必要なところだけ用意すればいいし、つまみ食いも出来る。その分楽。

丁度C++のスレが同じ事を言っているけど、
http://echo.2ch.net/test/read.cgi/tech/1490917669/137-
そりゃ全てのオブジェクトが isScrollable や isSerealizable を持っているのが美しいだろうさ。
しかしそれは通常は余計に手間が増えるだろ。
インタフェースが肥大化するか、基底クラスが肥大化するかで。

だったらJavaScriptみたいに、
var obj_serialized = (obj.serialize)? obj.serialize() : null;
とか、
SomeObj.prototype.serialize = function(){};
とか、出来たら融通は利くでしょ。少なくとも「今」やりたいことは出来るようになる。
それが後々逆に足を引っ張ることになるかどうかは腕次第でしょ。

ただし、どっちが楽かという話であって、
出来るか出来ないかで言えば、同じだよ。同じ事を逆からアプローチしてるだけだから。
JavaScriptについて言えば、
初期状態は全ての名前のメソッドを定義してあるが、実装してない状態だと言える。
だから未実装ならundefinedが返ってくるし、実装済みなら使える。
C++とかだと、初期状態は全く定義がなくて、自分で全て追加しないといけない。
でも全てのダックタイピングを可能にしようとしたら、
型消去するなりして全てのインタフェースに対応しないといけなくなる。
これってJavaScriptの初期状態と同じでしょ。

C++のテンプレートは空回り感が酷い。
UIなんて張り切って実装しても意外に糞だったりするので、
とりあえず実装してから確認したいってのはある。
そういう時はJavaScriptみたいな、とりあえずサクサク実装出来る言語の方が向いている。

555 ：デフォルトの名無しさん：2017/04/18(火) 02:34:37.34 ID:ibb6Zkrz.net

>>554
シリアライズのことしか考えてなくて、しかもシリアライズメソッドさえあれば
何でもかんでも簡単にシリアライズできるんだって思ってるみたいだけど、
まず前提として、いかなる言語も汎用的なシリアライズはなという話をしようか？

これが大前提なので、あとからシリアライズメソッドつければ、
シリアライズできて便利ーにはならないんだよ。
通常シリアライズメソッドは後から追加できないものと考えるべき。

例外的に可能なものもあるけど、あとからシリアライズメソッドを追加できるならば、
obj.serialize() ではなく、Serializer.serialize(obj) とやることで目的は達成できる。
あんたがやろうとしているのは、単にシリアライズ処理を
インスタンスメソッドにしたいと言っているだけ。

556 ：デフォルトの名無しさん：2017/04/18(火) 07:09:23.56 ID:16rBXoJR.net

>>551
OCamlあたりで構造的部分型を利用した型推論とかを知っとくといいと思うよ
http://itpro.nikkeibp.co.jp/article/COLUMN/20061107/252787/

557 ：デフォルトの名無しさん：2017/04/18(火) 07:25:53.47 ID:V4ah9bya.net

>>554 C++のテンプレートは空回り感が酷い。 とりあえず実装してから確認したいってのはある。

激しく同意する。

An one-liner で書けるようなものでは、型の恩恵などない。Local,global の峻別さえ無意味だ。そのようなときは duck typing で書かねば損だ。

逆に duck typing で一万行を超えてくると、強烈に型が欲しくなる。

558 ：デフォルトの名無しさん：2017/04/18(火) 07:30:18.04 ID:V4ah9bya.net

>>554 そういう時はJavaScriptみたいな、とりあえずサクサク実装出来る言語の方が向いている。

俺は JavaScript(というより TypeScript) を使っていない。昔一舐めしただけだ。それ
に本格的に手を出すべきか迷っている。意見を貰いたい。

JavaScript を押す人たちのコードを見ていると、Python のほうが三倍程度は濃密な
コードで書けそうに見える。その理由は質の良いライブラリが揃っていることにある。

例えば N 重ループの iterator を Python ならば下のように書ける。JavaScript で、
こんな濃密なコードを書けるだろうか。

N=3; import itertools as md; list(md.product(*[range(3)]*N))
===============================
[(0, 0, 0), (0, 0, 1), (0, 0, 2), (0, 1, 0), (0, 1, 1), (0, 1, 2), (0, 2, 0),
(0, 2, 1), (0, 2, 2), (1, 0, 0), (1, 0, 1), (1, 0, 2), (1, 1, 0), (1, 1, 1),
(1, 1, 2), (1, 2, 0), (1, 2, 1), (1, 2, 2), (2, 0, 0), (2, 0, 1), (2, 0, 2),
(2, 1, 0), (2, 1, 1), (2, 1, 2), (2, 2, 0), (2, 2, 1), (2, 2, 2)]

559 ：デフォルトの名無しさん：2017/04/18(火) 09:47:58.51 ID:1155c42j.net

>>550
そんなショボいものしか保証してくれないの？
まったく安心して使えないね
動的型付けと大差ないじゃん

560 ：デフォルトの名無しさん：2017/04/18(火) 09:54:21.27 ID:1155c42j.net

動作を保証しないから問題だって言った（>>540）直後に
動作を保証しなくて何が悪いと返せる（>>550）って凄いねw
そのチンパンジー並みの記憶力は賞賛に値するよ

561 ：デフォルトの名無しさん：2017/04/18(火) 21:12:55.65 ID:xAHUlHha.net

>>558
俺はPythonは知らないのでJavaScriptとの比較は出来ない。
ただPythonはクロージャに難ありなので今後も使う気はない。
改行が強制されるのも気に入らない。

JavaScriptは書いてて気持ちがいいんだよ。
理由は簡単で、全て具だから。
型等の動作には関係ない物がないから、動作に集中出来る。
なるほどMatzが目指したのはこれだったのか、というのは分かった。
だから俺が次にやるとしたらRubyだね。

今のところ、俺は型自体はは要らないという結論だ。
名前通りの型しか付けないので、見りゃ分かる。
ただ、現実として、実行前にタイプミスを見つけてくれないから困っている。
ダックタイプや動的に使う場所なんて限られているのだから、
そういう場所に対してワーニング出してくれるだけでいいんだが。
そのためのリントを探してはみたものの、
JavaScriptのリンターはそんな方向では全くなかった。

あと、C++が糞なのはクラスは全て独立で親クラスを掴めないことだ。
だから細かくクラスを階層化出来ない。というか、やると余計に手間が増える。
ここら辺はJavaでは改善されていて、明示的に掴めるし、
JavaScriptではデフォで掴んでる。（レキシカルスコープ）
粗結合を目指すのならJava方式がいいし、
お気楽を目指すのならJavaScriptの方がいい。

ところで初心者はそういう「短く書ける方がイイ」みたいなことをよく言うが、
君が本当に一万行のコードを書ける奴なら、それは意味無いと分かるだろ。
そしてそれをここで聞くのも意味無い。
だって俺の腕前なんて未知数だし、ここでは無駄に吠える初心者も多いし。
一般論としては、Pythonはキャズムを越えているっぽいから、
学んでも無駄にはならないと思うよ。

562 ：デフォルトの名無しさん：2017/04/18(火) 21:41:20.30 ID:xAHUlHha.net

ああすまん、質問はPythonではなくて、JavaScriptを学ぶべきか？だったか。
俺が勘違いしてた。

これは俺は正確には答えられないね。
俺は他言語使えるわけではないし。
そもそも道具なんだから、今困ってなければ学ぶ必要はないだろ。

新しいプログラミングを学びたいというのなら、
結局どの言語も似たり寄ったりの方向に進化しつつあるし、
とりあえず「進化している言語」を一つ追跡しておけば問題はないだろ。
一番速いのは多分Rubyだろうし、この点ではPythonは遅いほうだよ。
同様に、この点でJavaScriptを選択する意味はない。

逆に、今使うというのなら、グダグダ言う意味もないだろ。
Web環境ではJavaScript以外の選択肢はないんだし。

563 ：デフォルトの名無しさん：2017/04/18(火) 22:41:32.37 ID:ibb6Zkrz.net

>>560
> 動作を保証しないから問題だって言った（>>540）直後に
> 動作を保証しなくて何が悪いと返せる（>>550）って凄いねw

なんの動作？

ねぇねぇ、なんの動作？

わざとぼやかしてるでしょｗｗｗ

564 ：デフォルトの名無しさん：2017/04/18(火) 22:42:21.03 ID:ibb6Zkrz.net

あとそれから>>540は俺じゃないからねｗ
IDすら見えない？

チンパンジーになみの理解力だった？ｗ

565 ：デフォルトの名無しさん：2017/04/18(火) 22:43:49.88 ID:ibb6Zkrz.net

>>561
> JavaScriptのリンターはそんな方向では全くなかった。

TypeScriptがお前が望むものだよ
型を導入したJavaScriptだ。
いまあちこちで普及してる。

566 ：デフォルトの名無しさん：2017/04/18(火) 22:45:23.23 ID:ibb6Zkrz.net

>>561
> ところで初心者はそういう「短く書ける方がイイ」みたいなことをよく言うが、
> 君が本当に一万行のコードを書ける奴なら、それは意味無いと分かるだろ。

え？ なんで？

同じ一万行なら、短く書ける方がより多くの機能を実装できるから
やっぱり短いほうが良いじゃんｗ

567 ：デフォルトの名無しさん：2017/04/18(火) 23:07:56.67 ID:wXuuRzeA.net

>>566
つまり型は余計だということだね
インタフェースとか余計なことを書かなきゃいけないから

568 ：デフォルトの名無しさん：2017/04/18(火) 23:13:36.64 ID:ibb6Zkrz.net

>>567
それはインターフェースが余計なものであるという前提で成り立つものだ
インターフェースは余計なものではなくプログラマの意図を
コードというコンピュータにも理解できる言語で記述した価値がある情報だ

569 ：デフォルトの名無しさん：2017/04/18(火) 23:14:34.77 ID:wXuuRzeA.net

>>568
短く書ける方がいいんでしょ？
ダブスタいくないよ

570 ：デフォルトの名無しさん：2017/04/18(火) 23:18:22.51 ID:ibb6Zkrz.net

>>569
正確に言うと「少ないステップ数」というべきだな。

インターフェースは実行されないのでステップには含まれない。
他にも型宣言とかimportとかコメントとか空行とか
{ だけの行とか、そういうのもステップには含まれない。

571 ：デフォルトの名無しさん：2017/04/18(火) 23:19:45.52 ID:wXuuRzeA.net

>>570
> インターフェースは実行されないのでステップには含まれない。
こんなオレオレ定義聞いたことありませんｗ

572 ：デフォルトの名無しさん：2017/04/18(火) 23:20:25.75 ID:ibb6Zkrz.net

>>571
デバッガの「ステップ実行」って
使ったことないの？

インターフェースの前後でステップ実行することはない

573 ：デフォルトの名無しさん：2017/04/18(火) 23:26:21.27 ID:wXuuRzeA.net

>>572
ググってみたけどステップ数からインタフェースを抜くなんて計算方法はまったく出てこない
オレオレじゃないなら、どこか有名なサイトに計算方法が載ってるはずだからさ、ポインタでいいから
示してください

574 ：デフォルトの名無しさん：2017/04/18(火) 23:39:00.32 ID:ibb6Zkrz.net

>>573
ステップ数は単に英語の意味の通り、ステップ（一歩）という意味しかないよ。
ステップイン、ステップアウト、ステップ実行できる単位と考えればいい。
ステップできないのに、ステップ数に数えるとか意味不明だろう

ソースコードの行数はLOCという。

575 ：デフォルトの名無しさん：2017/04/18(火) 23:42:54.39 ID:wXuuRzeA.net

>>574
たとえばさ、↓のページにあるように、ステップ数というと一般的にはプログラム規模を測るための
指標なんだよね

http://e-words.jp/w/%E3%82%B9%E3%83%86%E3%83%83%E3%83%97%E6%95%B0.html

LOCからコメントや空行を抜いたり、中括弧だけの行を抜いたりと言語によって流儀はあるみたいだけど、
お前の言う流儀がどこにも載ってないんだよ
どこに載ってるか教えてくれないか？

576 ：デフォルトの名無しさん：2017/04/18(火) 23:49:43.26 ID:ibb6Zkrz.net

>>575
だからステップ数は誰も正確な定義をしてないのだから
どんなものでも間違いではない。

577 ：デフォルトの名無しさん：2017/04/18(火) 23:54:29.25 ID:wXuuRzeA.net

>>576
とはいえ、「インタフェースはステップ数に含まない」と断言するからには、それなりに普及してる
流儀なんでしょ？
その流儀がどこに書いてるか知りたいんだが

578 ：デフォルトの名無しさん：2017/04/19(水) 00:50:35.21 ID:4qCNxF1h.net

動的型付言語の苦手な奴が多過ぎ
ダックタイピングでいいじゃん
スタティックおじさん馬鹿にしていながら、自分もスタティックおじさんみたいになってる

579 ：デフォルトの名無しさん：2017/04/19(水) 01:04:19.78 ID:PWf0mJDu.net

ダックタイプおじさんに言われても…

580 ：デフォルトの名無しさん：2017/04/19(水) 02:34:11.69 ID:kxK9Wtdr.net

ここでダックタイプ嫌ってる奴って、ダックタイプを静的言語でやるとしたらジェネリクスとか言い出す奴だもんな
「自分の分からない技術は使えない技術だ」なんて完全にスタティックおじさんだよな

581 ：デフォルトの名無しさん：2017/04/19(水) 02:40:43.54 ID:0X+KA4Ry.net

静的型の言語の補完の快適さは動的型言語には得られないものなんだよなぁ
インターフェイスとかをいちいち記述する手間を含めてもその最適さのほうが上回る感はある

582 ：デフォルトの名無しさん：2017/04/19(水) 02:43:32.85 ID:kxK9Wtdr.net

>>581
という感想を持つ人は静的言語を使えばいいし、インタフェースとかをいちいち記述するのが面倒くさい人は
動的言語を使えばいいよね
ただそれだけの話

583 ：デフォルトの名無しさん：2017/04/19(水) 06:39:45.49 ID:SqPK9IfP.net

自分だけで完結してる話ならそれでいいんだけど仕事だとそれじゃ駄目なんだよね
以前rubyのプロジェクトで酷い目にあったのでもう動的型付け言語は嫌だわ

584 ：デフォルトの名無しさん：2017/04/19(水) 07:15:17.15 ID:5nJ22bL2.net

インターフェースがある言語を使ってる人のほうが、よっぽどダックタイピング的思考をしてるだろう
rubyなんて脳内で型付けしてて、ダックタイピングのことなんて考えてない
教祖だけが狂ってる

585 ：デフォルトの名無しさん：2017/04/19(水) 07:48:20.66 ID:+KnDkITW.net

>>562 意見ありがとう。552です。

>Web環境ではJavaScript以外の選択肢はないんだし。
同意します。Google が TypeScript を標準言語にしているのも、その意味なんでしょう。

俺としては型推論の働く、濃密なコード記述可能で、良質のライブラリが揃っている言語が欲しい。

Haskell が型推論で一番強力だと思うが、キャズムを超えられないと思う。Python のよ
うな、全世界の知性による良質なライブラリの膨大な蓄積は期待できない。

586 ：デフォルトの名無しさん：2017/04/19(水) 07:53:38.11 ID:+KnDkITW.net

>> 562 ところで初心者はそういう「短く書ける方がイイ」みたいなことをよく言うが、
君が本当に一万行のコードを書ける奴なら、それは意味無いと分かるだろ。

この主張への反例として、下の URL にある RSA 暗号の実験コードを示す
http://www.math.kobe-u.ac.jp/~taka/asir-book-html/main/node96.html

二つの素数 p,q, から n=p q, n`=(p-1) (q-1) を経由して、秘密キーd 公開キー e を
構築する。ただし d e==1 mod n`。この 公開キー (e,n) を使ってデータ m から暗号
mm を生成し、mm から秘密キー(d,n) を使って m を復号する

## 素数 p,q から n` の定義する (暗号化されるデータ m は m < n` である)
p=13;q=17;n=p q; n`=(p-1) (q-1); n`
===============================
192

# e=35 は gcd(e,n)=1 となる適当に選んだ数数。
ts(); p=13;q=17;n=p q; n`=(p-1) (q-1); e=35; ts.gcd(e,n`)
===============================
1

587 ：デフォルトの名無しさん：2017/04/19(水) 07:54:07.55 ID:+KnDkITW.net

## e から d e %n` == 1 となる d を作る
p=13;q=17;n=p q; n`=(p-1) (q-1); e=35; d = e^(n`-1) %n`; d, (d e) % n`
===============================
(11L, 1L)

## p,q から作った (d,n) を秘密キーにして (e,n) を公開する。given m=100 に対する暗号は m^e mod n で行う
↑ (m^e mod n) ^ d mod n により、暗号 (m^e mod n) から m を複合できる

# m = 100(<n` == 192) に対する暗号 m^e mod n:94 を生成する
m=100; p=13;q=17;n=p q; n`=(p-1) (q-1); e=35; d = e^(n`-1) %n`; m^e %n
===============================
94

# m = 100 に対する暗号 mm=94 から、元の m を複合数
mm=94; p=13;q=17;n=p q; n`=(p-1) (q-1); e=35; d = e^(n`-1) %n`; mm^d %n
===============================
100

588 ：デフォルトの名無しさん：2017/04/19(水) 07:54:36.26 ID:+KnDkITW.net

以上の計算ができれば、RSA 暗号を実装できる程度に理解したと言えます。

ここでの one-liners は、プログラムというより、コンピュータ計算可能な数式です。
これ以上に単純化できない程に濃密です。しかも独立しています。それ以前の文脈に影
響されません。試行錯誤のごみの山から御宝式だけを copy and paste で取り出せま
す。

これらの one-liners は短いけれど、可読性も備えています。

Python は、これだけの濃密なコード記述を可能にする良質なライブラリ群を備えています。

これらのコードを書くのに、一々 big num class を持ち出したりしてられません。RSA
暗号数学だけで、手一杯なのですから。

これらの one-liners で、int 型宣言する意味もないでしょう。

589 ：デフォルトの名無しさん：2017/04/19(水) 07:55:01.02 ID:+KnDkITW.net

>>562 一番速いのは多分Rubyだろうし、この点ではPythonは遅いほうだよ。

老婆心ながら言っておきます。こんな理由で Ruby に学習コストを書けるのは止めるへき。

スピードが欲しいならば C 言語で実装して繋げばよい。SciPy は、実装にそうして実装
され、data science 分野で使われ、ライブラリが蓄積され続けている。

Ruby が書き安い言語なことには同意する。しかし勝手な互換性の放棄により、良質なラ
イブラリの作者たちを離反させすぎた。Python community とは差が付きすぎた。

Python は Ruby と比較して読みやすい。俺にとって読んで楽しめるコードは Python だ
けだ。C 言語はマクロの解析が必要になるなど、コードを読むことは苦痛のほうが勝
る。Ruby は C言語よりは読みやすいが、楽しめるほどではない。

今更 Ruby に向かうのは無謀すぎる。

590 ：デフォルトの名無しさん：2017/04/19(水) 08:42:44.89 ID:NBkpFfOk.net

どうせエンジンのお粗末なRubyのことだから
型が付いてもそのまま実行するよりWASM経由でした方が早いとなるだろうな。

591 ：デフォルトの名無しさん：2017/04/19(水) 09:30:10.92 ID:kxK9Wtdr.net

>>589
思いっきり文章の読み方を間違ってるよ
>>562 でいうスピードは変化のスピードだよ

君がPython好きなのは分かるが、他の言語をけなそうとする余り文章を読み違えるのは
いただけないな

592 ：デフォルトの名無しさん：2017/04/19(水) 09:59:52.76 ID:96WIxtun.net

Julia！

593 ：デフォルトの名無しさん：2017/04/19(水) 11:52:47.70 ID:oz+MR2rn.net

>>591
「このプログラミング言語は速い」って文脈で「進化の速度」のことを言っている奴は初めて見たな

普通は実行速度だよな？　プログラミング基礎でO記法とか学ぶもの

594 ：デフォルトの名無しさん：2017/04/19(水) 12:15:11.91 ID:kxK9Wtdr.net

>>593
>>562 で直前で
> とりあえず「進化している言語」を一つ追跡しておけば問題はないだろ。
と書かれているので、ここでの速いは進化の速度だよ
そうでないとJavaScriptを除外している部分と整合性が取れない
(JavaScriptは実行速度はかなり速いしね)

595 ：デフォルトの名無しさん：2017/04/19(水) 12:54:41.04 ID:D6qUbZcQ.net

>>560
亀レスで申し訳ないが、それはお前の認識が誤っているからだ

あるライブラリAの、とあるクラスが、別のライブラリBて定義されている
インターフェースを実装していた場合
ライブラリAはライブラリBでも使われることを前提としている
というかライブラリBの上にライブラリAを築いている
あたりまえだろ？だから当然想定されている

で、ダックタイピングの場合は
メソッド名が一致しているからひょっとして使えるんじゃね？
ってレベルだろ
そんなの偶然の一致かもしれないし、使えるかどうかわからん
元の開発者はそんなこと想定してないかもしれない
微妙に動作が違うかもしれない

596 ：デフォルトの名無しさん：2017/04/19(水) 13:04:46.14 ID:D6qUbZcQ.net

>元の開発者はそんなこと想定してないかもしれない

と書いたが、逆に使われることを想定しているんなら
インターフェース方式でも問題ないんだよ
ライブラリBのインターフェースを実装すればよいだけだからな
使われることを想定しているんなら、これは当然できる状態にある
そして明確になる

597 ：デフォルトの名無しさん：2017/04/19(水) 13:17:55.77 ID:cvkGewar.net

>>596
どういう主張だっけ？
作者が意図しない使い方はすべきでない、つまりダックタイピングは悪
ってこと？

598 ：デフォルトの名無しさん：2017/04/19(水) 13:29:02.70 ID:D6qUbZcQ.net

言いえて妙な話で、あるクラスがあちこちで使われることを想定しているなら
クラスの開発者は、想定する全ての使われ方について、全てのンターフェースを
実装すればよい
逆に、実装されてないインターフェースに関しては
「想定してませんよ、考慮してませんよ、ノーサポート」って事なんだよ
その場合は、当たり前だが自分でラッパークラスを書けばよい
ちょっとしたデータ変換や仕様のすり合わせもそこですればよい
元のクラスが想定してないんだから、これは当然なんだよ

ダックタイピングは全てのクラスが自分の管理下にあって
仕様を完ぺきに把握しているのなら可能かもしれんが、という話

599 ：デフォルトの名無しさん：2017/04/19(水) 13:31:56.22 ID:D6qUbZcQ.net

ラッパークラスと書いたが、アダプタクラスと言ったほうが正しいかもしれん

600 ：デフォルトの名無しさん：2017/04/19(水) 20:03:28.85 ID:NUjiGrCs.net

そこそこ有名なライブラリAがあって、多数のライブラリC,D,E,...の中でそれを使っていたとする

それよりパフォーマンスが良くてメソッドに互換性があるライブラリBを作って
CDEを変更することなくAからBに置き換えてもらいたくなったとき

インターフェースのある言語だとライブラリAのインターフェースをBでも使わないと不可能じゃないの？

もしAがGPLならBもGPLにしなきゃダメってこと？

601 ：デフォルトの名無しさん：2017/04/19(水) 20:58:25.69 ID:kxK9Wtdr.net

インタフェースをきっちり設計するのは面倒だからな
これをそうじゃないという人間はある程度の規模のアプリケーションを組んだことがないんじゃないか
と言いたくなるぐらいにね

602 ：デフォルトの名無しさん：2017/04/19(水) 21:03:25.43 ID:BnOg8tXa.net

>インターフェースのある言語だとライブラリAのインターフェースをBでも使わないと不可能じゃないの？
>
>もしAがGPLならBもGPLにしなきゃダメってこと？

それはインターフェース有り無し関係ない。ＦＳＦの主張だと、GPLなライブラリと組み合わせて使う前提のプログラムは、
全てGPLでなくてはならないことになってる。

実際、ダックタイピングな Python でも、 pyqt が GPL か商用ライセンスしかなくて敬遠されてたので、
pyside という LGPL なライブラリが作られた。

603 ：デフォルトの名無しさん：2017/04/19(水) 21:09:00.28 ID:Fw9wzeAw.net

>>600
それは条件が公平ではない
動的言語がその差し替えを比較的容易に行えるのはソースコードを直に実行しており
依存関係がシンボリックだからにすぎない
CDEのソースが手元にあるなら、静的言語でもCDEをソースからリコンパイルすればいいだけの話
静的言語のリンクの仕方には色々あるが、同様にシンボリックなリンク方式を使っているなら
ソースが無くてもBにもAと全く同じインターフェースを定義すれば当然動く

604 ：デフォルトの名無しさん：2017/04/19(水) 21:14:45.53 ID:kxK9Wtdr.net

>>603
> CDEのソースが手元にあるなら、静的言語でもCDEをソースからリコンパイルすればいいだけの話
さすがにライブラリ使用者にそこまで求めることはできないよね…

605 ：デフォルトの名無しさん：2017/04/19(水) 21:17:54.76 ID:Fw9wzeAw.net

>>604
だからそれはインターフェースの有無ではなくコンパイルの有無の問題だよね
言ってる意味わかる?

606 ：デフォルトの名無しさん：2017/04/19(水) 21:19:20.91 ID:kxK9Wtdr.net

>>605
ライブラリは基本的にコンパイル済の状態で提供されるよね？

607 ：デフォルトの名無しさん：2017/04/19(水) 21:23:40.52 ID:Fw9wzeAw.net

>>606
だからインターフェースは関係ないと言ってるだけなんだけど
頭大丈夫?

608 ：デフォルトの名無しさん：2017/04/19(水) 21:33:07.54 ID:kxK9Wtdr.net

>>607
ライブラリCDEをソースからコンパイルという時点でおかしよね？

609 ：デフォルトの名無しさん：2017/04/19(水) 21:44:06.41 ID:Fw9wzeAw.net

>>608
そうだね
で、それがインターフェースとどう関係していると思うの?
一般論としては動的言語の方が比較的容易であることは>>603の冒頭で認めたうえで
それはインターフェースではなくコンパイル(の習慣)の有無の問題であるので
>>600の「インターフェースがあるから差し替えが難しい」は誤りだというのが俺の意見なんだけど
ここまで説明しないと理解できない?

610 ：デフォルトの名無しさん：2017/04/19(水) 21:46:39.68 ID:kxK9Wtdr.net

>>609
ライブラリはコンパイル済が配布されるのだから差し替えは難しいよね？

611 ：デフォルトの名無しさん：2017/04/20(木) 00:06:00.75 ID:goLojMqI.net

>>589
俺に言わせると、Pythonは学ぶ価値がないよ。

新しいプログラミングパラダイムを試したいなら、Rubyだろ。
「新しい事が至高」なコミュニティだから、今後もトップを走り続けるだろう。
逆に言えば、互換性なんて気にしている言語では、どうやってもRubyには追いつけない。

Pythonがゴミなのは、ラムダに式しか書けない点でも明らかだろ。
JavaScriptやってると分かると思うけど、式のラムダなんて使う割合は低い。
やりたいことが出来ない言語なんて、C派の俺にとってはゴミだよ。
そしてそれを教条的理由で採用しないというのも気に入らない。

Pythonの利点は、NumPyとかでしょ。
でもそれはNumJSとかにポーティングされれば終わる話。Python自体の魅力じゃない。
JavaScriptはローカルファイルへのアクセスが出来なかったからこの解はなかったが、
Nodeが出て、Electronが出て、という状況では、NumJSも時間の問題。
ただNodeなら直接Cで呼べるから誰もやらないかもしれないが。

Pythonが問題なのは、糞遅いこと。
これは現段階ではもう手当てする人が現れないでしょ。
NumPyでいい奴はそれで終わってるし。
NumJSが現れたら、Python＋NumPyよりも確実に速い。
その時にPythonを選択する理由がない。

JavaScriptの問題は、コミュニティとして非同期が正義な事。
正直、書きやすいとは言えない。ただこれも慣れれば何とかなるのも事実。
ネスト地獄ガーっていうのははっきり言って嘘で、ちゃんと組めばそんなことにはならない。
ただし、関数が細切れになるが。
まあこの辺も何だかなーってのもあるけど、致し方なし。

Pythonを今使うのならいいけど、将来性は無いと思うよ。

612 ：デフォルトの名無しさん：2017/04/20(木) 00:14:11.81 ID:goLojMqI.net

>>593,594
俺が言っていたのは「進化の速度」だよ。
というか、そんなに分かりにくい言い方だとも思わないけど。

ただ、本当に>>558が出来る言語が素晴らしいと思っているのなら、
まずは言語は何でも良いからガンガン書いてみて、
それをきっちり保守してみることだね。
そうすれば、そんな点は全く意味がないと分かるだろう。

613 ：デフォルトの名無しさん：2017/04/20(木) 00:19:35.76 ID:Xe6G3IeW.net

>>611
気持ち良く長文書いてるとこ悪いけど、cythonって知ってる？

614 ：デフォルトの名無しさん：2017/04/20(木) 01:36:16.89 ID:1ly+xIep.net

>>606
> ライブラリは基本的にコンパイル済の状態で提供されるよね？

ソースコードが提供されているならば
ソースコードを修正してコンパイルすれば良い。

そのライブラリがコンパイル済みの状態で提供されているかどうかは関係ない

615 ：デフォルトの名無しさん：2017/04/20(木) 01:37:22.80 ID:1ly+xIep.net

>>610
> ライブラリはコンパイル済が配布されるのだから差し替えは難しいよね？

少なくともオープンソースであれば、ソースコードとコンパイル済みの
両方が配布されているから差し替えは難しくない。

616 ：デフォルトの名無しさん：2017/04/20(木) 01:59:48.10 ID:JQpZsY1s.net

>>610
多くのコンパイル型言語では故意に差し替え可能に設計しておかない限りインターフェイスの有無に関わらずライブラリのコンパイルが必要
たとえばC#でインターフェイスをつかわず、全部dynamicで呼び出してる場合でもDLL差し替えではだめ

617 ：デフォルトの名無しさん：2017/04/20(木) 02:37:35.64 ID:jSNxj+lA.net

>>611
>>>589
>俺に言わせると、Pythonは学ぶ価値がないよ。
>
>新しいプログラミングパラダイムを試したいなら、Rubyだろ。
>「新しい事が至高」なコミュニティだから、今後もトップを走り続けるだろう。
>逆に言えば、互換性なんて気にしている言語では、どうやってもRubyには追いつけない。

釣り? 少なくともRubyは無いわ。昔はともかく、この2-3年は停滞しているように見える。
すまんが、最近Rubyに入った、新しいプログラミングパラダイムを教えてくれ。

# ちなみに貴方が腐している Python は、async/await とか、外部チェッカを利用した Gradual Typing とか Null safety とか入りました。

618 ：デフォルトの名無しさん：2017/04/20(木) 03:11:22.47 ID:1ly+xIep.net

>>617
それのどこが新しいプログラミングパラダイスなの？

619 ：デフォルトの名無しさん：2017/04/20(木) 03:33:31.73 ID:59/j45Wf.net

>>618
お前の頭がパラダイスだよアホ

ていうか、ruby3にgradual typing入れるってmatzが去年言ってなかったか？

620 ：デフォルトの名無しさん：2017/04/20(木) 04:55:25.22 ID:DtO/sAcV.net

>>611
ラムダ式に式しか書けないのは関数型言語好きがコミュニティに増えたからって気がする。
Pythonそのものも関数プログラミングをサポートしつつあって、同じ機能にオブジェクト指向版と関数プログラミング版と二つあるのがチラホラ。。。
そういう意味じゃすっごく気持ち悪い。

でも、使う側から見れば使えるライブラリ多いPython。
面白いかどうかじゃなくて、使えるかどうかね。
Rubyで使える数値計算やディープラーニングのライブラリ紹介してくれ。
宣伝してやるから。

621 ：デフォルトの名無しさん：2017/04/20(木) 06:12:51.42 ID:wBOWWhZ0.net

>>611
少なくともNumPyが使われ続ける限りPythonを学ぶ価値はあるだろ
Pythonから学ぶことは反面教師的なこと以外はほとんどないけどさ

しかしRubyには使いどころはおろか、学びも皆無
自称言語オタク(失笑)が聞きかじった話題の他言語の顰みに倣ったり
その失敗を含む二番煎じを、ろくすっぽ論文も読まない取り巻きとひたすら繰り返しているだけ

Rubyを見て新しいとかいってる奴は元ネタを知らないだけのただの哀れな信者

622 ：デフォルトの名無しさん：2017/04/20(木) 06:28:09.48 ID:q9J6ThwX.net

アニメで小林さんがpython使ってたから本読んだ。仕事でciscoのopenpk使う事になった。小林さん、ありがとう。

623 ：デフォルトの名無しさん：2017/04/20(木) 07:19:41.16 ID:GRmYdHAz.net

>>614-615
mavenやsbtみたいなのを使うなってことですか？
これは驚いた…

624 ：デフォルトの名無しさん：2017/04/20(木) 07:34:57.19 ID:Oql1W8zX.net

>>623
意味不明
お前は公開リポジトリに既存の有名ライブラリと同姓同名の俺ライブラリを登録するつもりか?
そんな迷惑行為は常識的には認められない

625 ：デフォルトの名無しさん：2017/04/20(木) 07:37:46.72 ID:GRmYdHAz.net

>>624
ソースを入手してビルド、なんて依存性解決は面倒だしバージョンアップに追随するのも
面倒だしやってられないと思うんだが…

みんなやってられないと思ったからmavenやsbtみたいなのが作られたわけだし

626 ：デフォルトの名無しさん：2017/04/20(木) 07:59:30.03 ID:Oql1W8zX.net

>>625
Java系なら同じパッケージ名で同じ名称のクラスやインターフェースを定義しておけば
バイナリをmavenやsbtを用いて差し替えることは可能だよ
そんな”迷惑行為”は大抵のエコシステムでは認められないし、
パッケージ名の勝手な使用によって法的な問題が発生する可能性すらある

627 ：デフォルトの名無しさん：2017/04/20(木) 08:09:16.54 ID:jSNxj+lA.net

>>>617
>それのどこが新しいプログラミングパラダイスなの？

コルーチンが普通の関数っぽく書けるようになったり、動的型言語に部分的に静的型を導入したりNullチェックを強制できるのは新しくないと。
ま、Pythonが史上初めてではないが、他言語で評判が良い部分を取り込んだ感じだな。

じゃ、貴方が思う、最近Rubyに入った新しいプログラミングパラダイムを教えてよ。
Rubyは「トップを走り続ける」のだから、1つ2つは簡単に紹介できるでしょ。

628 ：デフォルトの名無しさん：2017/04/20(木) 08:42:44.18 ID:KuJQA9vc.net

ここ最近このスレは全く書き込みが無くて閑古鳥が鳴いていて
人いるの？って感じだったのに
俺の書き込みを発端として昔のように熱いバトルが始まって本当にうれしい
書き込んでよかったよ
もう絶滅したかと思ってたが、まだ一定数、動的型信者がいるようで
あぶり出し大成功ってところか
危険人物なので隔離スレにいつまでも隔離されててください
今の猫も杓子も静的型の時代に、まだ回心できてないってことは
これから先もずっと無理だろうし

629 ：デフォルトの名無しさん：2017/04/20(木) 09:58:21.96 ID:1vogS2Io.net

>>628
インターフェース信者君がフルボッコになってるのを熱いバトルってww

630 ：デフォルトの名無しさん：2017/04/20(木) 10:19:29.42 ID:KuJQA9vc.net

このように、もはや違う時間軸に住んでいる人なんだよな
俺の住んでる時間軸では、新しくできた目ぼしい言語は
当たり前のように静的型の機能を持っていて
静的型の落とし込み方自体が言語の特徴というか
セールスポイントにもなってるんだが
そちらの時間軸ではどうなってるのかな？

タイプセーフは今時常識だよ
静的型の先進的機能を否定するのは過去に縛られたstaticおじさんと同じこと
また、言語に静的型の機能がないってことは
単純にその言語は手抜きってだけのこと
あと、言語としてもつまらない

631 ：デフォルトの名無しさん：2017/04/20(木) 11:51:49.98 ID:zbrlZyFU.net

visual studioとc#の組み合わせが最強すぎる

632 ：デフォルトの名無しさん：2017/04/20(木) 20:02:10.05 ID:GRmYdHAz.net

>>630
staticおじさんというのは「自分の知らない機能を使えない機能だと断言してけなす人」だから、ID:KuJQA9vc のことだよ

633 ：デフォルトの名無しさん：2017/04/20(木) 21:11:31.08 ID:1ly+xIep.net

>>630
まーた、タイプセーフの意味をわかってないやつかｗ

http://postd.cc/what-is-type-safety/
> C言語とC++：型安全ではない。
> Java、C#：（恐らく）型安全。
> Python、Ruby：（ほぼ間違いなく）型安全。



> タイプセーフは今時常識だよ
そのとおりだよ。PythonとかRubyを見よ。
タイプセーフになってるだろ

634 ：デフォルトの名無しさん：2017/04/20(木) 21:17:24.18 ID:mm5xT/YJ.net

タイプセーフと、実行時型エラー出るのとは別かもだが、実行時型エラーが問題。
客からそんな詰まらんエラーでクレームとか恥だわ。

635 ：デフォルトの名無しさん：2017/04/20(木) 21:25:08.52 ID:1ly+xIep.net

別かもじゃなくて別。全くの別物

636 ：デフォルトの名無しさん：2017/04/20(木) 21:48:47.90 ID:q9J6ThwX.net

staticおじさんは今はタイプセーフの話なんてしてんの?

637 ：デフォルトの名無しさん：2017/04/21(金) 13:28:51.30 ID:jwNNIRXE.net

pythonは単純な手続き型プログラミングもできるしオブジェクト指向もそこそこできるし
関数型もそこそこできるすごいそこそこな言語なんだゾ

638 ：デフォルトの名無しさん：2017/04/21(金) 15:21:18.45 ID:JPWJqUsf.net

重要な言語である事は誰もが認めるが、凄いかどうかは微妙。

639 ：デフォルトの名無しさん：2017/04/21(金) 17:30:39.41 ID:SD7KIjS1.net

今はjavascriptそのまま使うよりtypescriptでしょ

640 ：デフォルトの名無しさん：2017/04/21(金) 19:41:12.79 ID:qLxCXNxk.net

ぼほ主流スクリプト言語はオブジェクト指向も関数型も搭載済み。

641 ：デフォルトの名無しさん：2017/04/22(土) 20:52:21.35 ID:vDrwU1OX.net

ライブラリに頼らずjavascriptのそのままテキストエディタに手打ちで一気に書けるのが熟練エンジニア
コードの保管などいらないし、変数の型も当然頭の中で整理されていて矛盾など起きない

後で保守する奴のためには、ちゃんと事細かなコメントを付けてやり、見やすく改行とインデントを付けて置いてやる
フレームワークに頼る奴は二流だ

642 ：デフォルトの名無しさん：2017/04/23(日) 10:49:37.16 ID:EiQ7XooB.net

と、IDEやフレームワークの進化ついて行けないロートルが申しております

643 ：デフォルトの名無しさん：2017/04/23(日) 11:43:35.11 ID:sn9lV80g.net

近年必要なコード量が多過ぎだよな
にも関わらずそれに対処しようとする言語は無い
それこそIDEやフレームワークに責任を丸投げしているが、
よく考えてみるとJSは当時で言うそれだったわけだ
もう一回りして未来に流行る言語はそういうものであって欲しいね

644 ：デフォルトの名無しさん：2017/06/04(日) 06:54:19.19 ID:N3Ss45Z5.net

そういうことだな

645 ：デフォルトの名無しさん：2017/06/14(水) 19:04:04.71 ID:X3ins31N.net

http://goodpatch.com/blog/rubykaigi-2016-report-ruby3-typing/
>まずはじめに、プログラミング言語の「型」という側面についての
>振り返りがありました。

>プログラミング言語にも時代によって流行りがあり、
>それは振り子のように繰り返されています。
>かつては動的言語のSmalltalkやLispがあり、次に静的言語のJavaが流行し、
>JavaScriptやRubyのような動的言語が流行り、現在はGoやSwiftなどの静的言語が注目を集めています。

>このような変遷を辿り、2010年代に出てきた新しい言語には静的型付け言語が多く、
>Rubyのような言語は「死んだ」とまで言われることもあります。
>しかしMatzによると、このような流れは振り子のように繰り返されているので
>安易にRubyに静的型付けを導入するのではなく、Rubyにとっての型というものについて
>真剣に考えて導入していきたい、ということでした。

↑なんで嘘つくの？
動的型言語が静的型言語を抑えて人気だった時代なんか、あったか？
Rubyが流行っているといわれていた時代でさえ(ピーク時でさえ)
JavaやC/C++に負けていただろ、なんで嘘つくんだ？
振り子っていったい何のことだ？
当社比30%アップってやつか？

646 ：デフォルトの名無しさん：2017/06/14(水) 23:41:45.61 ID:ypgXVN+Z.net

C/C++はもはや速度を求めるコアライブラリか組み込みでしか生き残ってないけどね
（競技プログラミングという変な分野もあるけど）

コンピュータの適用範囲が広がったので昔のようなC/C++が独壇場だった分野がメイン
ストリームではなくなったともいえるが

647 ：デフォルトの名無しさん：2017/06/15(木) 13:19:25.17 ID:JjjNetzb.net

OSもアプリもたいていC/C++でしょ
それ以外の新興分野ってなんだ

648 ：デフォルトの名無しさん：2017/06/15(木) 20:11:50.64 ID:FKNFCYKC.net

>>647
アプリってObjective-Cのこと？

649 ：デフォルトの名無しさん：2017/06/16(金) 13:19:24.30 ID:u6Npk8qK.net

この文脈ではObj-CもC/C++に含めていいかと

650 ：デフォルトの名無しさん：2017/06/16(金) 21:21:28.27 ID:efyE3evL.net

>>649
だったらC/C++/Objective-Cと書かない？
CとC++をわざわざ併記してるのに、そこにObjective-Cを含めるのは拡大解釈っぽいと思う

651 ：デフォルトの名無しさん：2017/06/28(水) 10:05:18.31 ID:+O8L6XqQ.net

366 :nobodyさん 2017/05/29(月) 16:07:39.16 ID:6v4UcGhE
今回の民法改正、ソフトウェア受託開発の場合、(検収後ではなく)バグ発見後１年瑕疵担保責任があるということで、地獄かよ、と思ったが、
元々問題が起きがちな受託案件がビジネス的に成立しなくなることで強制的に業界再編につながるなら良いことかもと思うようになった。
一部で地獄を見ても。
https://twitter.com/yukihiro_matz/status/869061879389343744

367 :nobodyさん 2017/05/29(月) 16:28:06.55 ID:6v4UcGhE
ニュース - 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大：ITpro
http://b.hatena.ne.jp/entry/itpro.nikkeibp.co.jp/atcl/news/17/052601508/

372 :nobodyさん2017/05/29(月) 19:10:37.12 ID:???
Railsでシステム作って納品する
↓
Railsはマイナー、メジャーのアップデートが半年以内に必ずある
↓
客がアップデートする。アップデートによるエラーやバグ、動作の不具合に気づく
↓
気づいてから1年以内に通知すれば、5年間無料保証ゲット
↓
つまりRailsがアップデートするたびに、無償の修正作業を発生するということかな

376 :nobodyさん2017/05/30(火) 09:20:20.09 ID:L5po86sS
>>378>>379>>375
客が瑕疵担保責任法の法改正を知ってくると思うから、今後5年無償保証をお願いされるだろう
営業がそれでも仕事を取ってこれるか？たぶん無理だろう。無限の直していたら赤字になる。
こういう保守に弱い言語、ころころ仕様が変わる言語は仕事として発生しなくなってくる。
これは変わり目だ。お前らも早く逃げたほうがいいぞ。RubyやPHPなど動的言語は確実に廃れる。
保守に強い言語のみ生き残れる。

652 ：デフォルトの名無しさん：2017/06/28(水) 10:05:44.06 ID:+O8L6XqQ.net

瑕疵担保責任（かしたんぽせきにん）

瑕疵担保責任のポイント

民法改正で事実上期限が「無制限」になった
バグや設計のミスなどは、瑕疵担保責任
納品物に不具合があれば損害賠償を請求される可能性もある
不具合を指摘されたらすぐに行動をとるべし
軽微なミスでも先延ばししない

http://www.atmarkit.co.jp/ait/articles/1706/26/news014.html
http://itpro.nikkeibp.co.jp/atcl/news/17/052601508/?rt=nocnt

改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、
通知後5年以内は修正や報酬の減額などを求められるとしている

全ベンダーが泣いた民法改正案を解説しよう その1
http://www.atmarkit.co.jp/ait/articles/1609/14/news009.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_2.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_3.html

ポイント1：修補や損害賠償、契約解除の期限がなくなる

従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。
条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、
その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、
11年後まで請求可能なのだ。

もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。

653 ：デフォルトの名無しさん：2017/08/23(水) 05:31:40.05 ID:cGhuJuEk.net

js/es は new を廃止するか、new を関数に変更して、且つ、定義時にデコレーターとして使えるようにしなきゃ、今の大流行は尻すぼみになるだろうな。

654 ：デフォルトの名無しさん：2017/08/27(日) 14:22:07.87 ID:78TyXvfU.net

newが問題だった訳じゃない、貧弱で変わり者のクラスシステムに頼らざるを得なかったことが問題だっただけ
それもES6で解消されたし、プロトタイプの設定が解禁されたのでnewに頼らないクラスシステ厶も自由に構築できる
それこそシンプルなオブジェクトだけのインスタンスベースでClass.new()みたいに書く世界を構築することも可能

655 ：デフォルトの名無しさん：2017/09/20(水) 15:15:08.16 ID:8RXgPmEk.net

たまにはageとこ

656 ：デフォルトの名無しさん：2017/10/02(月) 21:19:36.62 ID:SV15s/5a.net

ファイル操作とテキスト処理とか正規表現が得意なスクリプト言語ってないですか

657 ：デフォルトの名無しさん：2017/10/03(火) 06:25:55.26 ID:p+b687/D.net

powershell

658 ：デフォルトの名無しさん：2017/10/22(日) 22:31:21.51 ID:dJ6mfyJW.net

Ruby

659 ：デフォルトの名無しさん：2017/12/11(月) 14:51:24.83 ID:DnBfEOiq.net

今のサイトってHTML5ばかりだからjsを知ってるだけで得することが沢山あるよな

660 ：デフォルトの名無しさん：2017/12/11(月) 20:15:34.64 ID:X/PhFgqn.net

香ばしいな
頑張れよ

661 ：デフォルトの名無しさん：2017/12/11(月) 21:28:07.25 ID:DnBfEOiq.net

chromeのプラグインで無垢なサイトにやりたい放題^^

662 ：デフォルトの名無しさん：2017/12/30(土) 14:02:22.80 ID:CRdrmtvM.net

ｐｈｐで検索WebAPIを作ってみてるんですが、
page番号を指定しようと思って、?page=0とすると$_GET['page']で受け取れないようなんですが、
0は指定できないんでしょうか
一応１からの指定にしてphpの中で1を引くことでちゃんと動作できるようにはできたんですが

663 ：デフォルトの名無しさん：2018/01/02(火) 19:59:10.29 ID:BCempIdS.net

いい加減そういうのをWebAPIと呼ぶのは辞めた方がいい
例えばRESTならRESTと言うべき
WebAPIはDOMAPIを含むブラウザライクなものから触れるAPIのことを指す用語であり
そちらのほうが言葉の使い方として適している
https://developer.mozilla.org/ja/docs/WebAPI
https://developer.mozilla.org/ja/docs/Web/Reference/API
https://developer.mozilla.org/ja/docs/Web/Guide/API

664 ：デフォルトの名無しさん：2018/05/12(土) 11:03:58.80 ID:pDgCeBjY.net

共同ツール 1
https://seleck.cc/685

https://trello.com/
ボードのメニュー → Power-Upsから拡張可能 Slack DropBoxなど
Trello Chrome拡張機能　elegant
ttp://www.kikakulabo.com/service-eft/
trelloのオープンソースあり

共同ツール 2
https://www.google.com/intl/ja_jp/sheets/about/

共同ツール 3
https://slack.com/intl/ja-jp
https://www.dropbox.com/ja/
https://bitbucket.org/
https://ja.atlassian.com/software/sourcetree
https://sketchapp.com/extensions/plugins/
ttp://photoshopvip.net/103903

ttps://goodpatch.com/blog/sketch-plugins/

665 ：デフォルトの名無しさん：2018/05/23(水) 20:52:53.86 ID:Au5e7VGg.net

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

9PV1J

666 ：デフォルトの名無しさん：2018/07/05(木) 01:00:47.63 ID:RfoszcD2.net

N06

667 ：デフォルトの名無しさん：2018/08/09(木) 02:22:17.82 ID:f4Nba8Mw.net

PHPとかJavaScriptで金融関連システム案件有るけど、本当に金額計算とかに使えるの?

668 ：デフォルトの名無しさん：2018/09/18(火) 07:10:57.57 ID:yS+Vqsca.net

使えるでしょ
今ならBigIntもあるし

669 ：デフォルトの名無しさん：2018/09/26(水) 18:13:21.65 ID:6y0+0vMx.net

javascriptってjavaよりややこしいね。

670 ：デフォルトの名無しさん：2019/02/11(月) 16:30:10.28 ID:OYN//JbE.net

型情報ないのに、コールバックばかりだなら、
理解しにくいソースなりやすいからなぁ。

671 ：デフォルトの名無しさん：2019/02/13(水) 05:37:25.15 ID:h1/eONKG.net

javascriptのスレって過疎ってるな(´・ω・｀)

672 ：デフォルトの名無しさん：2019/02/13(水) 05:42:20.05 ID:h1/eONKG.net

js初心者なんだが
jsでjsonファイルを開いて
pushでデータを追加して
それをローカルファイルに保存する方法教えてくれー(´・ω・｀)

json開いてpushまではできた
ローカルファイルを更新するところで詰まってる
出来るだけ綺麗な方法がいい
Node.jsは使ってない

673 ：デフォルトの名無しさん：2019/02/13(水) 05:47:23.31 ID:WxTmz2dr.net

じゃあ使え

674 ：デフォルトの名無しさん：2019/02/13(水) 05:57:09.98 ID:h1/eONKG.net

Node.jsがよく分かってないし
使ったことがないから怖くて(´；ω；｀)
今の環境はxamppだけど
サーバはubuntuで作ってるし

phpの互換の問題で手を焼いてるのに
新しく学習する時間がない

675 ：デフォルトの名無しさん：2019/02/13(水) 09:04:34.29 ID:h1/eONKG.net

ajaxでphpにpostすることで解決したわ

676 ：デフォルトの名無しさん：2019/02/13(水) 14:01:25.41 ID:geic4YuV.net

https://pbs.twimg.com/media/Dy9NfMKU0AAjOgP.jpg:large
>>675

677 ：デフォルトの名無しさん：2019/02/13(水) 22:55:43.70 ID:NEpE3zFw.net

ローカルファイルなら、Ruby。
JavaScript なら、VSCode でも使っている、Electron = Node.js + Chromium

Node.js をインストールしていないと、npm, yarn などのパッケージマネージャーが使えないだろ

コマンドプロンプトで、where node で、インストールした(PATH を通した)場所がわかる。
C:\Program Files\nodejs\node.exe

678 ：デフォルトの名無しさん：2019/02/13(水) 23:58:46.87 ID:jwc/pNVH.net

>>677
うるせえ死ね。

679 ：デフォルトの名無しさん：2019/02/15(金) 06:46:44.94 ID:nprpqeX/.net

firebaseを使ってログイン機能を実装してるんだが
ログインしている時にユーザ情報を取得する関数としてuserInfo()と言うのを書いたんだがうまく動いてくれん
btnをクリックしたら
53行目のアラートが実行されて
62行目のアラートが実行されるんよね

それで戻り値はundefinedだし
https://i.imgur.com/07PL6Yh.png

680 ：デフォルトの名無しさん：2019/02/15(金) 06:47:31.54 ID:nprpqeX/.net

js初心者なもんでエロい人教えてください(´・ω・｀)
コールバック関数とやらで何か処理せんといかんと？

681 ：デフォルトの名無しさん：2019/03/06(水) 04:19:40.40 ID:zrLMVBLG.net

ajaxで複数のオブジェクトを同時に送ることって出来るの？
jsonデータとFormDataを同時に送りたいんだけど

682 ：デフォルトの名無しさん：2019/03/13(水) 08:49:54.04 ID:QFceQq5n.net

$.when( getJsonA(), getJsonB(),getOtherData() ).done( function( obj1, obj2, obj3 ){ var jsonA = obj1[0]; var jsonB = obj2; var otherData = obj[3] });

683 ：デフォルトの名無しさん：2019/04/04(木) 20:25:33.47 ID:j78mKFJX.net

PHP始めるけどどんな環境がいいの？
IDEは多分vscode使いたい
Pythonだとインポートサジェストがvscodeにはまだないけどphpは大丈夫？
それとPythonで言うanacondaみたいなものはあるの？
鉄板とかあるの？

684 ：デフォルトの名無しさん：2019/04/04(木) 21:11:02.09 ID:c7BBV/yp.net

マルチ死ね

685 ：デフォルトの名無しさん：2019/04/05(金) 07:52:34.01 ID:0lUjLeBK.net

回答ないから違うところで聞いたらマルチ死ねか

686 ：デフォルトの名無しさん：2019/04/05(金) 08:10:05.39 ID:xc8bkjJ8.net

それをマルチって言うんだよ
何日待ったか知らないが「別スレで聞くことにしました」
って質問を閉じるだけの事が出来ないの？

687 ：デフォルトの名無しさん：2019/04/05(金) 08:14:34.49 ID:E9zDv2XW.net

「別スレで聞くことにしました」って書いたからってなにか変わるわけでもないけどな。
しいて言えばそれを見た人の気分か。

688 ：デフォルトの名無しさん：2019/04/05(金) 08:50:53.20 ID:0lUjLeBK.net

別スレで回答があれば閉じるし閉じなくても違う意見があれば聞けるわな
phpプログラマーってもしかして色々とレベル低いの？

689 ：デフォルトの名無しさん：2019/04/06(土) 00:24:58.25 ID:nqPdyQw0.net

composerぐらいすぐ出てくるだろ
google検索は英語に設定しろよ。日本語の糞記事しか出てこねーだろ

690 ：デフォルトの名無しさん：2019/04/15(月) 07:57:06.59 ID:LtQIdg5g.net

>>687
普通にマナーだし、それ書いてたクロスポストじゃないと判断するよ。

691 ：デフォルトの名無しさん：2019/04/15(月) 08:54:05.58 ID:skRRWxtn.net

マルチポストと判断しようがしまいが実質何も変わらんと思うが。

>しいて言えばそれを見た人の気分か。

結局これかね？

692 ：デフォルトの名無しさん：2019/05/09(木) 00:59:35.60 ID:RU31sPhL.net

phpについて役立つ情報とか
http://mevius.5ch.net/test/read.cgi/tech/1557329831/l50

XUY

693 ：デフォルトの名無しさん：2019/05/11(土) 04:28:56.09 ID:L+Ypokmh.net

ひろゆき 就職出来なかったらプログラマーになれ！！
https://www.youtube.com/watch?v=N9Xl2m-GZwc

694 ：デフォルトの名無しさん：2019/05/19(日) 10:33:26.95 ID:iEpnaQWF.net

>>693
ホリエモンがいうところの勉強すればだれでも東大生になれるっていうのと同じ理論だな

695 ：デフォルトの名無しさん：2019/05/19(日) 11:02:33.11 ID:NYPIFE+t.net

初心者です
質問させてください


Windowオブジェクトというのは、つまり大元のObjectオブジェクト(組み込みオブジェクト)の事ですか？

696 ：デフォルトの名無しさん：2019/05/19(日) 11:14:29.29 ID:sA5/dcdL.net

ホリエモン入試落ちてなかったか？ｗ

697 ：デフォルトの名無しさん：2020/11/24(火) 09:21:08.97 ID:gfNKbZsO.net

>>695
（ここに）エスパーはいない

698 ：(u＿・y)~~~ ：2020/11/24(火) 13:10:21.17 ID:gfNKbZsO.net

(u＿・y)ruby以外の言語がいくら出来るようになっても
(u＿・y)よっしいっちょアプリ作って公開すっか！ってなると
(u＿・y)rubyで書いて一般人にトリッキーなソースコード見せつけて「ruby＝凄い＝俺凄い」ってやるのが
(u＿・y)最も簡単な快感の入手方法で
(u＿・y)JevaScoriptとかでダサいコード書いて、素人相手にソースコードを見せつける事もできないまま
(u＿・y)アプリを使わせるなんて、俺には出来ないね
(u＿・y)初心者にRubyのソースコードをポンッと渡して分からせる（rubyと俺の凄さを）
(u＿・y)分かって貰ったところで処理系をインストールさせて実行させろ
(u＿・y)Success!! [yes! / y!]

699 ：デフォルトの名無しさん：2021/01/11(月) 03:24:43.80 ID:JR6qyFIK.net

コントローラ側にruby使ってます。
フロント側からExcelファイルを選択して
submitボタンでファイルオブジェクトを送った後に
そのファイルデータをコントローラー側で読み取らせ
コントローラ側から処理結果をフロント画面側に返したいです。
ただ、submitだけだと、コントローラ側に渡して終わりになってしまうので
submitボタン押下時にJS側からPostJsonとかで送って、その結果をJS側に返して、
最終的に画面側に[読み取り成功]or[失敗]みたいにしたいのですが

PostJsonで送っても、ファイルオブジェクトとして渡せないので
困っています。どうしたらよいでしょうか？？

700 ：デフォルトの名無しさん：2021/01/11(月) 09:08:25.16 ID:RwOnRvzI.net

Ruby on Rails では、ファイルのアップロードなら、Active Storage

HTML じゃなく、単にJSON を返してもらいたいなら、API モードもある

回線を通ると、オブジェクトの型などをキープできない。
だから、ファイルオブジェクトではなく、単にバイナリ・文字列になってしまう。
これをシリアライズと言う

701 ：デフォルトの名無しさん：2021/01/11(月) 18:59:56.33 ID:aqo41dRe.net

javascriptは初心者向けの簡単な言語

702 ：デフォルトの名無しさん：2021/01/12(火) 20:49:25.97 ID:kyPiY518.net

その簡単な言語に滅ぼされてる言語の墓場はここですか？

703 ：デフォルトの名無しさん：2021/01/12(火) 21:22:32.38 ID:r1TF12oh.net

簡単だからこそ覇権を取れた
そしてここはその簡単な言語すら修得出来ない馬鹿の墓場

704 ：デフォルトの名無しさん：2021/01/12(火) 22:23:38.78 ID:Ao5nGZOO.net

簡単ではないだろう。
あんな扱いにくいものはない。
そもそもブラウザ上でアプリを動かすということ自体無理があって、それをあの手この手でどうにかしようとしてるのが今。
そしてサーバーサイドもjsで実行しようとしてるんだから何が正解なのかもうわからない。

705 ：デフォルトの名無しさん：2021/01/12(火) 22:43:30.60 ID:MXPvhWXx.net

日本人でJavaScriptを使いこなせるプログラマーなどれぐらいいるのだろうか？
ただし、JQueryのみの人は除外。

706 ：デフォルトの名無しさん：2021/01/12(火) 23:11:17.94 ID:MXPvhWXx.net

JavaScriptは大変難しい言語です。Rubyの難易度を2、Cの難易度を5、C++の難易度を8にすると、
JavaScriptの難易度は12ぐらいあると思います。
このコーディングガイドはそんなJavaScriptの深みに嵌まらないようにするためのJavaScriptの書き方を規定したものです。
初級者1のための物ですので、わかってやっている人に好きにやってください。

707 ：デフォルトの名無しさん：2021/01/13(水) 14:31:57.20 ID:okGelXy7.net

>>704
JSすら理解出来ない馬鹿が、自分の馬鹿さを認められない時に「JSは難しい」事にしようとしてるだけ
お前のことだが

理解に困らない奴は普通にもうJSやってる
ブラウザ上でアプリ動かすのも自然だし、さっさとそれに気づいた奴がchromeOSを提唱しただけ
俺もJS使い慣れてからは確かにOSの代わりにブラウザでいいわ、って思うし
同様にサーバーサイドもJSでいいし、実際そう思う奴がそれなりにいるからそういう動きになる

お前は自分が理解出来ないのを自分の馬鹿さゆえと認めたくないから他を否定してるだけ
それをやってる限りお前に進歩はないよ
ただ、そういう流れ/動きになってるというのは、
お前以外の他多数はそう思ってそう動いているという事実を認めた方がいい

708 ：デフォルトの名無しさん：2021/01/13(水) 18:43:40.27 ID:umJ59ojo.net

>>707
じゃ、お前はJSでマリオカートを作ってみろ。

709 ：デフォルトの名無しさん：2021/01/13(水) 20:06:09.16 ID:tLUt5qTN.net

JSという小道具で高級なもの作るのが要求されるんだから結果論としてJSは難しい
RubyとかPythonはライブラリが強力だからちょっと学べばすぐ何か出来るんだけど
JSは言語仕様が分かる程度じゃ何も作れんし
ライブラリが乱立してるのもあって、書き方が非統一でスマートにもなってないメソッドで機能実装しなきゃいけないから
そういう難しさ

710 ：デフォルトの名無しさん：2021/01/13(水) 20:40:41.42 ID:okGelXy7.net

>>708
WebGLもある今なら普通に出来るだろ
任天堂から十分な金額で求人が出てれば俺は応募してもいいが

そもそもお前は勘違いしていると思うが、マリオカートを作る難しさはどの言語でも大して変わらん
スプライトとかのレンダリング周りはあれば便利だが、無ければ自前で作るしかない
ただそれは「手間」が大幅に増えるだけで、「難しさ」には寄与しない
結局は座標を計算して投げるだけだから、それによって複雑になることはないんだよ
あれば楽なだけで


>>709
ならRubyやPythonならマリオカートをど素人でも作れて、JSだと無理とでも？
さすがJSすら理解出来ない馬鹿は言うことが違うね

711 ：デフォルトの名無しさん：2021/01/13(水) 22:37:39.80 ID:umJ59ojo.net

>>710
>ならRubyやPythonならマリオカートをど素人でも作れて、JSだと無理とでも？
>さすがJSすら理解出来ない馬鹿は言うことが違うね

そもそもお前は勘違いしていると思うが、マリオカートを作る難しさはどの言語でも大して変わらん
スプライトとかのレンダリング周りはあれば便利だが、無ければ自前で作るしかない
https://www.youtube.com/watch?v=wgZ09_6Q8wU

712 ：デフォルトの名無しさん：2021/01/16(土) 12:30:18.28 ID:CT7MjBNX.net

マリカーなんて作っても仕方ない
JSでページ作るっていっても
本来JSでやらないような処理が多かったりして
js以外で培った知識が導入されることも多いから
自称js出来るってだけの人じゃ難しいよねって話してる
ブラウザ上で出来る事＝OS上で出来る事のすべてって風になってきてるんで
Javaとかrubyで作っていたものをブラウザ上で動かすためにJsに落とし込むような作業があるでしょ
それが簡単な作業とでも？

713 ：デフォルトの名無しさん：2021/01/16(土) 14:41:03.34 ID:GtXMB98a.net

>>712
それはお前らお得意の「論点のすり替え」でしかないだろ。


言語間の難易度の比較なのだから、当然同じ事（同じアプリ）をそれぞれの言語で実装する時に難しいかどうかだろ。
「マリオカートを作る時に難しいかどうか」という視点はこの意味で正しい。
座標の計算が出来ない馬鹿がマリカー作れないのは、どの言語でも同じだよ。


> 自称js出来るってだけの人じゃ難しいよね
これは単にJSの馬鹿共が勘違いしてるってだけだろ。
これは事実としてあるが、逆に言えば、
勘違いする奴が多い＝本当は大した実力もないのに、いろんな事が出来てしまう
ということであり、JSの簡単さを補強しているだけだよ。


> Javaとかrubyで作っていたものをブラウザ上で動かすためにJsに落とし込むような作業があるでしょ
> それが簡単な作業とでも？
ねえよそんなの。と言うか言うほどインタフェースは変わらんし。
具体的に何に困った？それは君がそれを知らないからでしかないだろ。
座標計算出来ない奴がマリカー作ることは『どの言語を使っても』無理なように。


JSは一般的に簡単だとされているLightWeight言語にカテゴライズされてる。
PHP/Ruby/Python/Perlもそうだが。
そしてそれ以外、つまりJava/C#/C++/Rust等を使いこなせている奴がJSを難しいなんて言うのはほぼ居ないだろ。
(完全にJava脳になってる奴にはどうにも受け付けられないらしいが)
だから多くの人にとってJSが比較的簡単なのは事実であり、それをグダグダ言ったところで始まらんよ。

714 ：デフォルトの名無しさん：2021/01/16(土) 18:50:15.51 ID:CT7MjBNX.net

で、その簡単に書けてるJSで仕事って取れてるの？
そんな美味い話はありません
仕事取れるレベルのJSなら難しいものです

715 ：デフォルトの名無しさん：2021/01/16(土) 22:34:09.43 ID:GtXMB98a.net

>>714
また論点そらしか。その程度だとプログラマとしては無理だから止めた方がいい。
それのどこが「JSが比較的難しいプログラミング言語」になるんだ？


お前は学生なのかそれ以下なのか知らんが、
当たり前だが、誰でも出来るようなことで簡単に給料を得る方法なんて無い。
それはどの職業でも同じ事だ。勿論プログラマも含まれる。
お前が言ってるのは「プログラマは誰でもなれて高給を得られる職業ではない」であって、これはその通りだ。
しかしこれだと論点がずれていることにすら気づけないお前ではプログラマは無理だ。止めとけ。

前述の通り、給料を得ようと思えばそれなりなのが必要なのは全職業だし、
プログラマに限っても、『どの言語でも』同じ事だ。
まあそれでも比較的JSとPHPはプログラマ全体から見たら馬鹿が多いからWeb系と馬鹿にされてるわけだが、
しかしこれも、逆に言えば比較的馬鹿でも給料を得られるということではある。
ただし今Webがバブルってるだけかもしれんが。


まあJSすら理解出来ない馬鹿と話しても意味がないと理解した。
次の論点逸らしには返答しないからそのつもりでよろしく。
お前には未来永劫「JSは難しい」とつぶやき続けて次世代から馬鹿にされる未来がお似合いだよ。

716 ：デフォルトの名無しさん：2021/01/16(土) 23:48:26.34 ID:8wvhVU3e.net

jsが難しいというか
js周りのフレームワークは移り変わりが激しい
生jsはIDEの支援が少ない
という理由で開発する人は大変という印象

717 ：デフォルトの名無しさん：2021/01/17(日) 00:24:34.56 ID:My7TC4+8.net

>>716
> js周りのフレームワークは移り変わりが激しい
乱立しているのは事実として、
いちいち付いていきたくなければ使わないのもありだし、古いのを使い続けるのもありだろ。
Javaみたいに10年間進化しない方がいいのならこれでいい。
選択肢がある分ましだと思うが。

> 生jsはIDEの支援が少ない
これは動的型言語共通の話で、Python/Ruby/Perl/PHPとも同じだし、同程度には支援があると思うよ。
それ以上の支援が欲しければ型を明示的に書くしか無く、TSがこれになる。
逆に、静的型言語で型を（全面的に）省略することは出来ないから、これも選択肢がある分ましだろ。

まあPythonは意図的に選択肢を絞っているし、それが受けているようではあるが、
俺はMatzと同様、いろんな実装方法があった方がいい、という意見なので。

718 ：デフォルトの名無しさん：2021/01/17(日) 00:41:13.13 ID:BvejEeZc.net

>>716
それ故に新しい環境にちゃんとついていける奴は少なくなるし
ついていければ有利だろうって算段でやってる

>>715
オラオラしたいだけの学生キッズと違って大人はお金や＋＠が必要なんよね
無駄なエネルギーを使うのをやめたほうがいい

719 ：デフォルトの名無しさん：2021/01/17(日) 09:03:07.03 ID:wmH8ypzJ.net

>>717
>これは動的型言語共通の話で、Python/Ruby/Perl/PHPとも同じだし、同程度には支援があると思うよ。

原理上はそうだけど環境の比較であれば実際に入手できる環境の優劣はあるね。
VSCodeのlanguage serverはTypeScriptじゃない生jsでもかなり強力に推論してくれるし
Pylanceもそこそこ使えるものになっている。
PHPとRubyはこれからってところじゃなかったかな。

720 ：デフォルトの名無しさん：2021/01/17(日) 10:02:26.87 ID:My7TC4+8.net

>>719
その辺に関しては結局のところ人数勝負であり、JSとPython以外については死体蹴りでしかない。
ただしVSは(Codeは知らんが多分同じ）ただのフロントエンドであり、
IDEサポートについてはどの言語でも原理は同じなので、横方向展開は（やる気があれば）早いはずだが。

まあバトルロワイヤルなら第一ラウンドは終わって、これから優勝決定戦が JS vs Py で行われるといったところだろう。
ついでにPythonも滅ぼして欲しいところだが、JSは非同期強制なのとコンソールがないのが痛い。
MSがPowerShellとかいうゴミに逃げずにCScriptを発展させてくれれば良かったのだが、
これはどっちかというとMSが追い出された側だからJSの失態だが。

して、JS vs Py はお互い相手を滅ぼすほどの決定打を持たず、しばらくは膠着状態が続くのだろうね。

721 ：デフォルトの名無しさん：2021/01/17(日) 10:33:39.95 ID:wmH8ypzJ.net

>その辺に関しては結局のところ人数勝負であり、JSとPython以外については死体蹴りでしかない。

あんたが死体を並べておいて何言ってんの？

>IDEサポートについてはどの言語でも原理は同じなので、横方向展開は（やる気があれば）早いはずだが。

原理的には同じであっても各々の開発者コミュニティのやる気や能力には差があるわけで。

722 ：デフォルトの名無しさん：2021/01/18(月) 15:58:14.94 ID:f4QICPVB.net

はあ逃亡か

723 ：デフォルトの名無しさん：2021/01/19(火) 00:21:41.07 ID:DPZ24S9X.net

pythonが生き残ってる理由ってnumpyがあったからでしょ。単に機械学習の分野で使われてるだけ。

単にスクリプト言語としてならjsの方が遥かに優秀だし可能性はあるよ。

非同期強制に関しては何が悪いのかわからない。
コンソールはあるし。

724 ：デフォルトの名無しさん：2021/01/19(火) 09:34:12.30 ID:Y7rxETSL.net

> pythonが生き残ってる理由ってnumpyがあったからでしょ。

殆どの言語はそれなんだから当たり前。どれでもいい言語が大半。
選ぶ理由は言語ではなくライブラリやフレームワーク

> 非同期強制に関しては何が悪いのかわからない。
非同期強制ではない。四則演算などは同期的に処理される
何が悪いかというのは、二通りのやり方がある所
ライブラリのデフォルトがほぼ非同期になってる所
つまりライブラリが悪い

725 ：デフォルトの名無しさん：2021/01/19(火) 10:20:59.05 ID:DPZ24S9X.net

スクリプト言語としての活用の仕方っていっぱいあるじゃん。例えばクローリングや業務の効率化の為とか。

そう言ったニッチな分野でもpythonが使われてるけど、その理由は機械学習がトレンドだった時代にpythonが推されて、それを見たユーザーがpythonを勉強してたからでしょ。pythonを何故か書ける人が多い理由はこれだと思う。

そういう分野でも俺はjsが向いてると思うよ。nodeやそれを取り巻くエコシステムが充実してるから。インタラクティブな環境もあるし。

数理処理を除いて基本的にpythonにあるライブラリはjsにもあるし、逆も然りでしょ。

イベントループってご存知？実promiseとかasync awaitとか非同期処理を書くときの概念は最初は戸惑うけど、かなり合理的だよ。

まぁ、pythonは数理処理を行うためなら良いと思うけどね。

726 ：デフォルトの名無しさん：2021/01/19(火) 11:01:42.35 ID:Y7rxETSL.net

そういうのは、非同期に処理したいときだけ、使えば良いんですよ。
必要もないのに、誰か（ライブラリ）に強制されるのがアホらしいのであって

727 ：デフォルトの名無しさん：2021/01/19(火) 11:03:36.93 ID:Y7rxETSL.net

JavaScriptも同期的処理がメインのライブラリ、実行環境がでればいいけど
それがでないのでPythonの変わりにはならない

逆にブラウザで動くのはJavaScriptしかないから、PythonはJavaScriptの変わりにはならないが
それはJavaScriptが優れているからという理由ではない。
単にブラウザがJavaScriptを選んだってだけ

728 ：デフォルトの名無しさん：2021/01/19(火) 11:04:38.80 ID:Y7rxETSL.net

結局の所、ライブラリや実行環境という
言語以外の部分を理由に、言語を選ぶのであって
言語自体で選んでないのよ

729 ：デフォルトの名無しさん：2021/01/19(火) 11:24:09.21 ID:DPZ24S9X.net

必要もないのにpromiseを使ってる例を教えてね。多分必要があるからそう書いてると思うよ。

ライブラリや実行環境含めてpyは貧弱だってことだよ。
パッケージの管理やlintとか。型システムとかね。
pipenvとかメンテされてんの？

730 ：デフォルトの名無しさん：2021/01/19(火) 11:41:23.33 ID:Y7rxETSL.net

> 必要もないのにpromiseを使ってる例を教えてね。多分必要があるからそう書いてると思うよ。

例えばデータベースのデータを取ってくる時に
データが返ってくるまで待ちたいのに
Promiseを強要される所

731 ：デフォルトの名無しさん：2021/01/19(火) 11:55:36.76 ID:DPZ24S9X.net

それは当たり前にpromise返すよね。

複数の非同期処理を直列で行いたい、並列で行いたいとか書き手のあらゆるユースケースに対応するためのものじゃん。

732 ：デフォルトの名無しさん：2021/01/19(火) 11:58:15.30 ID:Y7rxETSL.net

>>731
並列で処理したいとか思ってないんだが？

データがないとその先の処理はできないんだから非同期にする理由がない
ただデータを欲しいだけで、その処理を並列でやろうとか思ってない
なのにPromiseを強要されるって話をしてるんだが？

言っただろ？
そういうのは、非同期に処理したいときだけ、使えば良いんですよ。

733 ：デフォルトの名無しさん：2021/01/19(火) 12:02:24.31 ID:Y7rxETSL.net

今なんの話をしてるのかわかってないのか？

ブラウザのユースケースの話ではない
サーバーアプリのユースケースの話ではない

それらのユースケースでは非同期は必須だが、
非同期が必須じゃないユースケースもあって
そこには非同期ばっかり使う今のJavaScripの実行環境とライブラリは
適してないって話をしてるの気づいてる？

734 ：デフォルトの名無しさん：2021/01/19(火) 12:16:56.30 ID:DPZ24S9X.net

俺が例を聞いて、データベースの例出してきのは君だよね？

735 ：デフォルトの名無しさん：2021/01/19(火) 12:19:08.29 ID:DPZ24S9X.net

async awaitの登場でそこら辺も意識しないで済むでしょ。

そのうちtop level awaitもサポートされるし

736 ：デフォルトの名無しさん：2021/01/19(火) 12:19:32.75 ID:Y7rxETSL.net

>>734
データベースからデータを取得するプログラムが
いつ非同期が必要になったんだ？ｗ

データベース自体が必要なのと、
データベースを使う「アプリ」が必要なのの
違いも区別できてないのか？

今話をしてるのはJavaScriptで作るアプリの方だろうが

737 ：デフォルトの名無しさん：2021/01/19(火) 12:20:09.38 ID:Y7rxETSL.net

>>735
async awaitを使うか使わないかを
使い分けてる時点で意識してるｗ

738 ：デフォルトの名無しさん：2021/01/19(火) 12:41:16.26 ID:+TtyF9d2.net

asyncawait全然難しくないのにそんな同期欲しいか？
中途半端に同期APIに門戸を開くと実質同期waitが可能になって
モラルハザードが起こるから要らないんだけど

739 ：デフォルトの名無しさん：2021/01/19(火) 12:43:01.95 ID:Y7rxETSL.net

>>738
どちらかに統一されるならまだしも
同期と非同期の２つが頻繁に混ざることが問題

同期メインで必要なときだけ非同期を使うほうが楽だって言ってんの

740 ：デフォルトの名無しさん：2021/01/19(火) 12:48:36.64 ID:+TtyF9d2.net

すまんけど混ざった経験がない
混ざるってなに？

非同期メインでどうでもいい時だけ同期を使う方が正直楽

741 ：デフォルトの名無しさん：2021/01/19(火) 12:50:13.97 ID:Y7rxETSL.net

>>740
日付操作ライブラリは非同期ではない
普段書いてるJavaScriptコードも非同期ではない

742 ：デフォルトの名無しさん：2021/01/19(火) 13:54:01.07 ID:XUm2rf3n.net

>>723
基本的に ID:Y7rxETSL の言うとおりであって、空回りしてるのはお前が色々無知だからだ。

今言ってる「コンソール」ってのは、「『コンソール』アプリケーション」の「コンソール」であって、
つまりC/C++/Java/AWK/Perl/Ruby/Pythonのデフォの動作環境のことだ。
JSがPyhtonを滅ぼせないのはまずこれで、
動作環境が全く違うから、他スクリプト言語(AWK/Perl/Python/Ruby)の置き換えが単純には出来ない。
逆に、これらの言語間では容易に置き換えが出来、勝者はPythonになりつつある。
なおこの意味ではPHPも動作環境が全く異なるのでとりあえずは生き残る。

非同期が駄目な点は、単純に難しくなるからだ。
Python等で処理される事柄の大半は同期処理で全く問題ない。
JSの場合はC10K問題を非同期で解決するというのが宗教になってて、実際これは上手く機能しているが、
通常用途にはオーバースペック過ぎる。（データ待ちで待たされても何ら問題ない）
必要な時だけ非同期にさせろ、というのが正しくて、他言語はほぼ全てこうだが、JSは宗教だからこれを認めない。
asyncとpromiseでー、というのは、「一方ロシアは鉛筆を使った」を学んでこい。

個人的に勿体ないと思うのはIndexedDBの同期I/Oが廃止されたことだ。
書き込みだけでも同期I/Oが残っていればbeforeunloadで使えて、LocalStorageを廃止出来たはずだが、
現状そうでないからJS的に目の上のたんこぶな同期強制のLocalStorageを廃止出来ずにいる。
ここら辺は仕様を作る奴等が間抜けだと思う。
(ただし現行LocalStorageは設定値保存に使われており、
これが非同期読み出しだけになると大半の連中はまともに組めなくなるとは思う。《モーダル/モードレスよりも難易度が高くなる》
この意味ではLocalStorageを同期のままで残しているのは現実的な方策ではある）

>>738
> モラルハザードが起こるから要らないんだけど
これが典型的な宗教家だよ。
本来誰でも簡単に組めて、技量があればもっと素晴らしくも組める、というのが正しくて、
技量がないと組めない、というのは間違いなんだよ。
サーバーアプリも、DBつつくと無駄に非同期がいるから、JSよりもPHPの方が簡単に書けてしまう。
これがJSがPHPを滅ぼせない理由の一つだよ。

743 ：デフォルトの名無しさん：2021/01/19(火) 14:46:19.23 ID:DPZ24S9X.net

今言ってるコンソールって誰も言っていません。どこで出てきましたか？
コンソールアプリケーションのコンソール＝動作環境という論理で話していますが、意味がわかりません。

難しいからダメというのは話になりません。
俺は幅広いユースケースに対応できるのはjsだよねって話しています。まともな反論はなかったです。

置き換えが容易、pythonが勝者だというソースを出してください。

744 ：デフォルトの名無しさん：2021/01/19(火) 14:52:50.53 ID:DPZ24S9X.net

indexedDBの同期apiがなくなったのは当たり前。localstrageも非同期になって欲しいくらい。
基本的にどんなioをjsでは非同期になってほしい。

そうすることで待ち時間に処理を実行できたりするから。

745 ：デフォルトの名無しさん：2021/01/19(火) 15:02:01.63 ID:Y7rxETSL.net

> 俺は幅広いユースケースに対応できるのはjsだよねって話しています。

どの言語でも幅広いユースケースに対応できてるだろ
C言語で作れないものはないとでも言えばわかるか？

> 基本的にどんなioをjsでは非同期になってほしい。
非同期が必要ないユースケースは？ｗ

非同期が必要ないユースケースなのに非同期を強要され
だからといって非同期に統一されているわけでもない
自分の都合ではなくライブラリの都合で、同期と非同期を混在させなくてはいけなくなる
どうせ統一できないのであれば、必要なところだけ非同期にしたほうが楽だろ

746 ：デフォルトの名無しさん：2021/01/19(火) 15:04:38.08 ID:Y7rxETSL.net

非同期が必要ないユースケース＝待ち時間にする処理がない場合

例えば取ってくるデータがなければその後の処理ができない場合、
データを取ってくる処理を非同期にしてもただ待つだけで
待ち時間にする処理が何もことがない

747 ：デフォルトの名無しさん：2021/01/19(火) 18:28:00.91 ID:XUm2rf3n.net

>>743-744
お前が日本語もプログラミングも出来ないのは分かった。
相手する価値がないからもうやめにする。


> pythonが勝者だというソースを出してください。
と言う以上、お前はこれを否定出来るソースを出せるのだろ？まずそれを出せ。
このレベルの既知の事柄についていちいちソースソース言われても話が進まなくてウザイだけだし、
そもそもこの点に反論したいのなら743の時点で君が君側のソースを出す手もあった。
それが出来ないのは君が会話が出来ない馬鹿だからだよ。

> localstrageも非同期になって欲しいくらい。
これも既に言ってるだろ。
JS界では同期I/OのLocalStorageは以前から問題視されてて、非推奨とされているが、いまだに廃止出来てない。
それは廃止出来ない理由があるからであり、俺は既にそれを言ってる。


君は日本語が不自由だから話について来れず、何度も同じ事を説明されないと分からない馬鹿だ。
それだと話が全く噛み合わず、進まないんだよ。
実際、他の件もそうだろ。ここで会話出来る最低限の日本語レベルに達してないし、プログラミングの知識もない。

まあそれでも君みたいな馬鹿でも非同期ガーとイキれるのはJSの良いところで、
つまり馬鹿でも出来てそれなりに見栄えのする結果も得られ、出来ると勘違い出来る言語、ということでもある。
ただ、イキってる馬鹿はどの言語にもいるが、JSのイキリ馬鹿は他言語に比べてもだいぶ酷い。

748 ：デフォルトの名無しさん：2021/01/19(火) 18:51:28.65 ID:FY+XRiu9.net

よくよく考えてみると、JavaScriptでPromise（≒非同期）を使う場合って
「処理が終わるまで（何もしないで）待つ」時に使ってるよな？
非同期を使ってる本当の理由をわかってない気がする

非同期を使ってる人、ちゃんと使っている理由を正しく言えるのだろうか？

1. ブラウザで画面が反応しなくなるのを防ぐため
2. サーバーアプリで他のリクエストを処理するため

に非同期を使ってるんだぞ

並列処理とごっちゃになってそうな気がする
非同期は速くするためにやってるわけじゃない

749 ：デフォルトの名無しさん：2021/01/19(火) 18:51:35.53 ID:wA+UZRLu.net

>>747
偉そうに抜かすな。

750 ：デフォルトの名無しさん：2021/01/19(火) 18:59:02.85 ID:DPZ24S9X.net

>>748
>よくよく考えてみると、JavaScriptでPromise（≒非同期）を使う場合って
>「処理が終わるまで（何もしないで）待つ」時に使ってるよな？

待つ時以外にも用途があるわ。
例えばファイルをreadする処理がある場合、非同期だとreadする時間を有効活用して何か処理を実行できたりするだろ

751 ：デフォルトの名無しさん：2021/01/19(火) 19:09:48.46 ID:FY+XRiu9.net

>>750
> 非同期だとreadする時間を有効活用して何か処理を実行できたりするだろ

うん、可能性としてはそういうこと出来るよね。

でも、そんな考えで非同期使ってることってほとんどまずないよね
ただ待つためだけに使ってるよね。

ちゃんと画面を反応を止めなくするため or 他のリクエストを処理するために
非同期使ってますって意識してる？

752 ：デフォルトの名無しさん：2021/01/19(火) 19:16:13.96 ID:MQ3Q70Lw.net

そりゃ勿論

753 ：デフォルトの名無しさん：2021/01/19(火) 19:34:37.91 ID:FY+XRiu9.net

それを知ってるなら、コンソールアプリなどのユースケースは
画面の反応（更新やクリックとか）が不要で、他のリクエストもないってわかるよねｗ

ブラウザやサーバーアプリ以外、
それが必要もないのにpromiseを使ってる例だよ

754 ：デフォルトの名無しさん：2021/01/19(火) 19:49:22.60 ID:MQ3Q70Lw.net

勿論手元でワンライナー書く程度のどうでもいい用途には同期APIで十分
だからnodeのI/Oには一部同期APIも入ってる
ただしどこまで同期APIを用意するかは最早さじ加減の話
〇〇に同期APIがないからダメって言われても困る

755 ：デフォルトの名無しさん：2021/01/19(火) 20:52:31.74 ID:XUm2rf3n.net

>>754
そしてそのどうでもいい用途向け言語がいわゆるスクリプト言語で、実際にそういった用途が大半なわけだ。


状況が変わってきてるんだよ。
昔と比べて（文系含め、コンピュータのことを全く知らない、いわゆる）馬鹿がプログラミングするようになった。
これ自体はスマホが一般化するのと同様に自然な流れなのだが、その分、簡単な言語が必要とされるようになった。
Pythonが伸びているのはこれ。他と比べて比較的簡単だから。
PHPに至っては、プログラミングの何たるかを知らなくても何とかなってしまうという、すさまじく簡単な点が受けている。
（なおC->Javaに移行したのも簡単だからだ。というか、ど素人含めて全員Cで書け、という90年代が今から考えたら無茶すぎた）

非同期が駄目ってわけではないが、非同期縛りは馬鹿にとってかなり高い参入障壁になってる。
JSやって最初に引っかかる点も大体ここだろ。
JSが覇権を取る為に何かを修正するのなら、俺はここだと思うね。

逆にPythonが覇権を取る為には実行速度で、連中があまりここに着手しないのが俺にはよく分からない。
（とはいえPythonにはそれ以前に色々駄目な点が多いが）

ついでに言うとRubyも実行速度だと思う。
Pythonが今程度に遅いうちにJSの速度に追いつけば、Pythonを食う可能性も十分あると思うのだけど、
連中も何故かあまりここには手を付けないんだよね。

756 ：デフォルトの名無しさん：2021/01/19(火) 21:01:30.57 ID:FY+XRiu9.net

>>754
なんでワンライナーが基準なの？
曖昧なこと言ってないでもう少し具体的に言おうか

757 ：デフォルトの名無しさん：2021/01/19(火) 21:02:50.27 ID:n7Nlr7Yz.net

少なくともJSにとっては大半じゃないよ
書き捨てこそスクリプトって話ならperlが覇権とってたハズでしょ

758 ：デフォルトの名無しさん：2021/01/19(火) 21:03:24.31 ID:FY+XRiu9.net

例えばgitの実装なんか、非同期処理は殆どいらないだろ？

759 ：デフォルトの名無しさん：2021/01/19(火) 21:06:41.47 ID:FY+XRiu9.net

CLIコマンドのほとんどは非同期は必要ない
非同期なら空いた時間に他のことが出来る？

同期であってもI/O待ちなんかでCPUが解放されるんだから
空いた時間の他のこと（他のプロセスの処理）は出来るって

そういう基本的な所がわかってないんだよなｗ

760 ：デフォルトの名無しさん：2021/01/19(火) 21:24:40.20 ID:XUm2rf3n.net

>>757
Perlが覇権取ってたのは事実だが、それも過去になりつつある。
Perl6に移行してる奴はほぼ居なかったはず。
そして今時は「インストールスクリプトでPython使ってます」という理由で
Pythonがインストールされてないとインストール出来ない物が当然のように出てきており、
俺のPCにも使いもしないPythonはインストールされてる。2も3もだ。
この意味ではPython汚染はPerlより酷いと思うよ。
なおRubyもインストールされてる。同様に何かRubyを必要とする物があって入れたと思った。

まあこれがいいかどうかはさておき、JSはこの分野に進出出来ないでいる。
これが覇権を取りきれない理由でもある。

761 ：デフォルトの名無しさん：2021/01/19(火) 21:59:31.89 ID:wA+UZRLu.net

俺はElectron.jsで天下を取る！

762 ：デフォルトの名無しさん：2022/05/10(火) 10:33:49.15 ID:ohTOVu86.net

JSサイコー、愛してるぜ・・・(*´Д`)ﾊｧﾊｧ

763 ：デフォルトの名無しさん：2022/06/08(水) 10:43:20.16 ID:gZZpwIY1.net

日本国内でjavascriptを使えるプログラマーはどの位いるのでしょうか？
１０万人程度？

764 ：デフォルトの名無しさん：2022/11/13(日) 20:27:00.14 ID:B3bVIRDE.net

ずんだもんかわいい