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

【JavaScript】ｽｸﾘﾌﾟﾄ ..

378:デフォルトの名無しさん
16/10/27 14:56:55.94 80O2/jeT.net
>>375
どんなOODBと比べて？商用のGemStone/Sがそんなだったらヤバい

379:デフォルトの名無しさん
16/10/27 15:35:58.13 Hk5rVLoM.net
talkerとしてはむしろ
音も全て漢字で記述していた太古の人に
ひらがな・カタカナの便利さを伝える漢字に近い
でも彼らの世界／文化レベルでは必要にならないことは
ちゃんと分かってるが、一応は説得する

380:デフォルトの名無しさん
16/10/27 16:47:41.21 F1Es9tp8.net
漢字は外来語だけど翻訳しなくてもそのまま使える単語は便利じゃん
翻訳しないと通じない接続詞とかはひらがなで書く

381:デフォルトの名無しさん
16/10/27 20:05:42.82 uEMndLPW.net
Smalltalkよりも遥かにマイナーなErlangは
マイナーでも価値が認められて、色んな企業で使われてる
Smalltalkが使われないのはマイナーだからじゃなく価値がないから

382:デフォルトの名無しさん
16/10/27 20:45:06.11 I6A9uKq4.net
違うと思うメッセージングによる遅延結合の徹底という考え方が人類にはまだ早すぎるから

383:デフォルトの名無しさん
16/10/27 21:01:05.70 uEMndLPW.net
メッセージングによる遅延結合の徹底というアイデアはwebで余すところなく実現されてる
ちっさなローカルPCの1プロセスの中でやるのがアホで無価値なだけ

384:デフォルトの名無しさん
16/10/27 21:38:50.37 ogUx0kFx.net
本当に無価値な試みなら、ここまで他に影響を与えられるもんかね
URLﾘﾝｸ(exploringdata.github.io)

385:デフォルトの名無しさん
16/10/27 21:53:47.79 uEMndLPW.net
そんなもんが現在価値があるかどうかと関係あるとでも？
馬車が自動車に影響与えたからって今でも馬車に乗るくらいのアホさ加減だな

386:デフォルトの名無しさん
16/10/27 22:18:41.41 keItunkB.net
>>371
> AがSmalltalkだろ
お前、どんな気持ちで>>370が「BがSmalltalk」って
言ったか、考えたことあるのか！

387:デフォルトの名無しさん
16/10/27 22:20:28.98 keItunkB.net
>>384
Smalktalkに価値があると言っても、全てに価値があるわけじゃないのです。
他に影響を与えられなかったものは価値がなかったと考えるべきです。
つまりSmalktalk独自と言えるようなものは価値がないということです。

388:デフォルトの名無しさん
16/10/27 22:59:30.07 1HgQuwV8.net
>>385
たしかに馬車は自動車に先行して使われて影響を与えたし
今でも観光目的などに細々と使われている点とかはSmalltalkの現状に似ていていいたとえかもｗ
ただSmalltalkと馬車が違うのは、つい最近も自動車ｗのトレンドに影響を与えるものを生み出していること

389:デフォルトの名無しさん
16/10/27 23:10:20.65 1HgQuwV8.net
>>387
豚に真珠、猫に小判じゃないけど、
まだ真似されず独自の部分が現時点では無価値という意味では当たらずとも遠からずか
などと言ってみたところで馬の耳に念仏…というところも含めて

390:デフォルトの名無しさん
16/10/28 00:37:14.32 BgEAltTM.net
こういう隔離スレでこんだけ暴れてるのに本スレは今月１レスしかない。終わった言語

391:デフォルトの名無しさん
16/10/28 01:27:20.12 zmjgQps2.net
暴れてるって、いわれのない言いがかりをつけてきて
無用なスレ消費を助長してるのはアンチのほうだろ

392:デフォルトの名無しさん
16/10/28 04:05:46.47 3qy7hidy.net
どうせ仕事でSmalltalk使ってないでしょ？
なんで使わないの？

393:デフォルトの名無しさん
16/10/28 07:55:55.62 bUbDsoOJ.net
いわれのない言いがかりをつけてきて
無用なスレ消費を助長してるのはアンチのほう

394:デフォルトの名無しさん
16/10/28 08:55:41.13 TtakAM9O.net
飛蚊症のゴミみたいなもんかSmalltalkって

395:デフォルトの名無しさん
16/10/28 09:13:49.98 bUbDsoOJ.net
SORABITOさんに転職したい

396:デフォルトの名無しさん
16/10/28 09:21:28.43 SzmYBdzH.net
たしか最近は悪口ばかり言う方が悪者ということになっていた筈だが

397:デフォルトの名無しさん
16/10/28 17:49:10.94 RhtpmSEL.net
>>388
関数型言語はMapReduceとか、最近だとAWS Lambdaなどにコンセプトが受け継がれてて
まさにトレンドに影響を与えてると言えるけど、
Smalltalkにそんなものあったか？
まさかtraitsとかいうoopの一構文に過ぎないものの事を言ってんの？

398:デフォルトの名無しさん
16/10/28 19:20:55.16 ch5b/kiY.net
MapReduceとかAWS Lambdaとかはメインフレーム時代のプロセス指向なバッチ処理への回帰であって、
関数型言語のコンセプトとは粒度が違いすぎると思うけど

399:デフォルトの名無しさん
16/10/28 19:35:52.46 tW/HMORb.net
TraitsとMixinを混同するならともかく、oopの一構文とかどんな理解力不足なんだよ

400:デフォルトの名無しさん
16/10/28 19:49:51.93 3qy7hidy.net
>>398
どっちもスケールの問題に対する関数型的な解決だよ
なにがプロセス指向なバッチ処理だよ馬鹿は黙ってろ

401:デフォルトの名無しさん
16/10/28 19:52:04.03 3qy7hidy.net
>>399
traitsもmixinもたかがoopの一構文に過ぎない
そんなもん全く重要じゃないし、そんなのに拘ってるから下っ端コーダのままなんだよ

402:デフォルトの名無しさん
16/10/28 21:32:06.03 xjMUho1S.net
>>481
じゃあお前にとって重要なものは何？
社長が重要とかいうボケはいらないからね

403:デフォルトの名無しさん
16/10/28 21:34:30.21 xjMUho1S.net
>>400
> どっちもスケールの問題に対する関数型的な解決だよ
AWS Lambdaで使える言語は、Node、Java、Pythonなんだけど
関数型的な解決だという根拠は？

404:デフォルトの名無しさん
16/10/28 23:05:27.53 v7enucQW.net
>>403
AWS Lambdaで書けるのはステートレスな関数に制限されてるだろ
状態を持たないことによる並列化のしやすさや疎結合という
関数型言語で得られる（と言われてる）メリットをアーキテクチャレベルで実現してる
てか、こんな簡単なことも言われないと分かんないの？馬鹿なの？どんな言語で書けるとかマジどーでも良いんだよ

405:デフォルトの名無しさん
16/10/29 08:33:42.56 jbWCC7sE.net
vector<char>なら状態を持つがstringはステートレス
プロセス間通信のネットワークは文字列型と言ってもよさそうなものだが
文字列処理の価値を認めないのはSmalltalkと関数型に共通する特徴だと思う

406:デフォルトの名無しさん
16/10/29 11:14:01.00 LoTR039H.net
lambda言ってる時点で関数型意識してるでしょ。
プロセス代数が出るならまだしもバッチ処理とかって、、、

407:デフォルトの名無しさん
16/10/29 11:27:17.86 z8URZLOb.net
なんだｗ「関数」と「関数型」をごっちゃにしているやつだったかｗ
AWS Lambdaはファイルやデータベースを読み書きできる
そういった「関数」を登録する。
ファイルやデータベースを読み書きする関数が「関数型」だというのなら
バッチ処理だって関数型だよｗ

408:デフォルトの名無しさん
16/10/29 11:35:01.33 7nyiPKGt.net
>>407
ステートレスなコンテナってとこがミソなんだよなぁ
いくらでもスケールアップできて、S3のイベントなんかに反応して計算して、終わったらコンテナごと全消去
入力と出力だけ考えれば良くて、リアクティブで副作用なしでスケールアップ可能ってのが特徴なので、古典的バッチとはぜーんぜん違う

409:デフォルトの名無しさん
16/10/29 11:37:38.81 z8URZLOb.net
やっぱりバッチ処理だなｗ

410:デフォルトの名無しさん
16/10/29 11:39:34.17 z8URZLOb.net
バッチ処理を並列で動かすのと何も違いがないし

411:デフォルトの名無しさん
16/10/29 11:39:56.67 ddj4bzvw.net
それを単なるバッチ処理と言うんだよw
それこそメインフレーム時代から続く伝統的なIPO型アーキテクチャだ

412:デフォルトの名無しさん
16/10/29 11:46:44.23 7nyiPKGt.net
>>411
ユーザがファイルをアップロードしたらAWS Lambdaで計算して結果を返す（典型的な用途）
これがバッチ処理ならhttpサーバはバッチ処理してるんだなw

413:デフォルトの名無しさん
16/10/29 11:54:27.23 ddj4bzvw.net
>>412
全く本質が見えてないな
それが関数型ならインプレース更新を行わない古典的なバッチ処理はだいたい関数型だと言ってるんだよ

414:デフォルトの名無しさん
16/10/29 11:59:58.74 7nyiPKGt.net
>>413
本質が見えてないのはお前だよ
ただ単に、副作用がない関数でシステム書けば関数型か？って聞くならともかく
どっからバッチ処理が出てきたの?w

415:デフォルトの名無しさん
16/10/29 12:19:53.83 ddj4bzvw.net
>>414
問題は処理の粒度
Lambdaにずいぶん夢見てるみたいだけど、Lambdaは呼び出しのオーバーヘッドが大きすぎる
現実的にはバッチ処理やS3にアップロードされた画像ファイルを処理するといった粒度の大きな処理単位でしか使い物にならん
そのレベル止まりなら全く目新しいものではなく、現代にあえて関数型だと言うなら粒度の小さな処理に対しても統一的に適用できる仕組みが必要
「Lambdaによるリアルタイム処理」みたいな言葉が独り歩きしてるが、あれスループット上げるために
わざわざKinesisを間に入れてマイクロバッチ処理に変換したりするんだぞ

416:デフォルトの名無しさん
16/10/29 13:30:02.46 LoTR039H.net
OOPのメッセージパッシングも、所詮関数呼び出しじゃんって言ってそう、、、

417:デフォルトの名無しさん
16/10/29 19:08:25.95 5tcsH0dx.net
粒度が荒くなると関数型じゃなくなるなんて
これまた珍妙な説出してきたなw

418:デフォルトの名無しさん
16/10/29 19:40:46.94 jbWCC7sE.net
言語が一つじゃなくなる粒度とか
OSも言語もバラバラ

419:デフォルトの名無しさん
16/10/29 22:08:03.38 z8URZLOb.net
>>417
副作用をもたらすから関数型じゃないんだよｗ
オブジェクト指向でも副作用がない関数を書いたら
それは関数型だって主張したいのかい？ｗ

420:デフォルトの名無しさん
16/10/30 05:32:40.80 hqgegRgF.net
俺はこの問題に二十年取り組んできたが、結論は出てる。
「作者が関数型と主張した」言語が関数型だ。
そもそも最初はシンプルだったものも、どんどんリッチに汎用的になるに連れ
元来の関数型とは乖離していっている。
特にこの１０年、今まではそれでも範囲内で拡張するすべを探していたのが
妥協する策を取るようになった。
汎用でリッチなプログラミング言語としてはその方がずっと都合が良いからだ。
したがって今の著名でここのスレ民が主に思い浮かべるような言語は関数型ではない。
強いて言えば、作者が「関　数　型」と主張しているという程度のこと。
個人的には「関数型」言語とはもはや「P」言語に近い。

421:デフォルトの名無しさん
16/10/30 05:53:29.20 h7Os3ze3.net
意訳
「>>420が関数型と主張した」言語が関数型だ。

422:デフォルトの名無しさん
16/10/30 09:14:34.70 Iggl3vKB.net
ニセ科学に反対するだけで良かったのに
代案を出せとか煽られてついつい関数型という怪しいジャンルを作ってしまったんだな

423:デフォルトの名無しさん
16/10/30 13:43:32.58 GS3Z8C14.net
今はマルチパラダイムな言語が増えてる、Adaとか

424:デフォルトの名無しさん
16/10/30 13:45:12.33 h7Os3ze3.net
つーか殆どがマルチパラダイムじゃね？
そこに対抗してマルチパラダイムに対応できない言語が
純粋○○であることを売りにしてるけど、それ欠点だよねｗ

425:デフォルトの名無しさん
16/11/08 16:23:03.12 /G9nZu79.net
うるっせえなこの馬鹿どもは
スクリプトの覇権は昨今の機械学習/AIブームでオッパイソンさんで確定したろ
あとは黙ってPython極めることに専念しろ

426:デフォルトの名無しさん
16/12/03 09:58:47.88 rhALv8P7.net
PHP 7.0.x から PHP 7.1.x への移行
URLﾘﾝｸ(php.net)
PHP7.1リリースｷﾀｰ! hackのnullable型導入とかか？
とりあえず x.1 待ちしてた奴ら移行しろよ。

427:デフォルトの名無しさん
16/12/08 09:29:51.63 u0pmvICB.net
直也：.NET CoreというかC#って型があって、しかもサーバーサイドも書けるじゃないですか。Linuxでやってた人たちはずっとスクリプト言語使ってて、
Rubyとか型がない言語でサーバーサイド書いてることに疲れてきちゃってるんですよね。
ある程度の規模のものではサーバーサイドも型がある言語で書きたいと思って、
ScalaとかJava 8をやってみたんだけど、どの言語もちょっとバランスが悪いんですよね。
Scalaはプログラマ寄りすぎるし、Javaはコンサバすぎる。サーバーサイドSwiftもとがりすぎてるし。
実績があって型がある言語ってC#なんですよね。そのC#がLinuxで使えるのは大きいんですよね。
だから、ワンチャンあるなって。あとは市場が評価するかどうかなんですよね。
バランスはいいと思います。それがWindowsだけでなくMacでも使えるようになったのは本当に大きいですし。

428:デフォルトの名無しさん
16/12/09 01:22:51.17 kfA92fVD.net
dartはいかが？

429:デフォルトの名無しさん
16/12/09 01:41:37.98 IAKedM2U.net
>>428
いい加減現実を見よう
未来へ一歩踏み出そう

430:デフォルトの名無しさん
16/12/09 08:31:24.21 GYMahviX.net
未来を見ず現実を見たつまらない言語がDartなんだが

431:デフォルトの名無しさん
16/12/09 08:50:43.91 IAKedM2U.net
間違いはGoogleが現実の問題とニーズだけを見ていて自分の立場が見えていなかったことだな
そんなことをGoogleに求めている奴はいない
輝かしい切捨ての歴史を持つGoogleを土方分野で信用する馬鹿はいない

432:デフォルトの名無しさん
16/12/09 22:55:33.79 K++XEq18.net
大事なのは言語云々よりDartVMでしょ
ブラウザへの統合を断念した時点で終わった

433:デフォルトの名無しさん
16/12/09 23:17:20.20 IAKedM2U.net
>>432
ブラウザ統合自体が重要なのではなくてGoogleのやる気の問題だろう
Chromeに統合するという触れ込みで登場した当時は
Googleが本気だ! ということでそれなりにインパクトがあった
Dartが注目されていたのはそのGoogleの本気というただ一点だったのだから、
「結局いつものGoogleだった」となった時点で当然もう何も残らないよ

434:デフォルトの名無しさん
16/12/10 02:23:12.50 Y9PwNia6.net
>>432
サーバ側ならどう？
typescripあるしphpも型付けることできる用になったから難しいかな？

435:デフォルトの名無しさん
16/12/10 07:47:45.47 dczaGrMx.net
Goもあるし.NET Core(C#)も盛り上がってきたからねえ
残念ながらDartにはもう出番はないよ

436:デフォルトの名無しさん
16/12/10 09:53:52.20 Q42P76Xv.net
wasm対応で先手を取れれば状況がひっくり返る可能性もあるが
asm.jsの時点でやる気0だったしなあ

437:デフォルトの名無しさん
16/12/13 09:18:46.65 2oGa6DNb.net
URLﾘﾝｸ(chrome.google.com)

438:デフォルトの名無しさん
16/12/31 15:42:56.02 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」です。
URLﾘﾝｸ(mayonez.jp)

439:デフォルトの名無しさん
17/01/03 00:30:36.24 pkTsP2s0.net
モンスターのアイコンの統一感がなさすぎるな
線が細いキャラと太いキャラを並べると違和感のかたまり

440:デフォルトの名無しさん
17/01/03 05:08:13.08 sAzrCak7.net
>>438
今更な記事を引っ張ってこられてもな。
対応言語c,c++以外も増えたのかねぇ。

441:デフォルトの名無しさん
17/01/03 21:47:16.02 m68UQ04g.net
どうだろうね。
まあ「その都度ソースコードを機械語に翻訳する必要があるため」遅い
という問題は、わかりやすい問題だから改善されていくよ。
最近だとV8で、即時関数っぽい書き方されたコードは最初から最適化して
すぐ実行できるよう準備するようにするパッチが入ったじゃん。
そういうのの積み重ねで良くなっていくと思うよ。

442:デフォルトの名無しさん
17/01/04 08:48:59.47 u2CyXKSE.net
>>158
ただ自分の優位性を示したいだけの典型的な権威主義の馬鹿だな
自分の主張やは無いくせに～ぐらいはしてるよね？とか
お前仕事場でも嫌われてるタイプだろ
少なくともHaskellは特定分野以外はまともに使えない
実際使ってればつまずくのですぐ分かる話

443:デフォルトの名無しさん
17/01/04 09:11:36.00 u2CyXKSE.net
なんつう亀レスだ…はずかしい

444:デフォルトの名無しさん
17/01/04 10:10:34.13 B3jxZHKh.net
Haskellはまだ趣味の範囲であらゆる分野で使える言語だよ。だって純粋関数型言語じゃないから。

445:デフォルトの名無しさん
17/01/04 11:41:28.60 P9CxkEKM.net
>>444
貴方の思う純粋関数型言語の定義とその例を述べなさい(100字以内)

446:デフォルトの名無しさん
17/01/05 06:21:07.40 sTWjNqOn.net
やだなぁ、やめてくれよ。
ただの皮肉だよん。

447:デフォルトの名無しさん
17/01/08 01:51:52.58 +qBxgbmJ.net
このスレのお前らがどう思っているかが一番重要なんだよ
多くのヒントになるから
時代は常にこのスレで言われていた事の反対に進んだだろ？
今は静的型全盛で動的型ﾌﾟｯって感じだし
さんざんな言われようだったJSはむしろメジャー言語になったし
今JSが糞って言われているのは主に動的型だからだし
主要スクリプト言語もどんどん静的型の機能を取り入れているし
2000年代にはオブジェクト指向をやりたいならRubyをやれって言ってたのに
今Rubyはどうなった？静的型の機能はいつ追加されるの？Ruby3.0はいつ？
超ド近眼
ほんのちょっとの目先の手間を惜しんで
より面倒なハメにあう動的型信者らしいっちゃらしいがな
昔に動的型がブームになっていた頃から
糞だってはっきり言っていた人たちもたくさんいたし
単にお前らがド近眼ってこと

448:デフォルトの名無しさん
17/01/08 02:15:46.05 +qBxgbmJ.net
どうでも良いことばかりに着目しているド近眼ってこと

449:デフォルトの名無しさん
17/01/08 16:59:24.13 zEIuJeGz.net
何も分かってないなぁ。
このスレの奴らは静的型アンチでもないし、動的型信者でもない。
昔ながらの静的型と動的型のデメリットとメリットを比較した時、
動的型が肌に合ってた奴は多いが前提が変わるんなら勿論話は変わってくる。
そもそもスクリプト言語の奴らは良いものは何でも大歓迎で取り入れるのが好きだから、
言語に型表記機能が入れば喜んで使う。
動的型に慣れているからこそ、エンジンに型を理解してもらう大切さが良く分かってるからだ。
そこは全く矛盾したり対立したりすることではない。
それとJSが糞と言われていたのは、クラスベースでなく馴染みにくいとことと、便利ライブラリの欠如だ。
でも、ぶっちゃけ欠点のない言語は無いのに、JSがそこまで言われてた理由は、
実はJSの仕様の問題ではなく、DOM APIの仕様とブラウザの実装が酷かったからだ。
そこはむしろ糞って言われていたからこそ、様々な改善が試みられて、今これほどまでに良くなったんだよ。
けしてJSの周りの環境が本当は糞じゃなかったわけではない。
もう一度言うが糞だったから良くなれたんだ。そこは勘違いするな。

450:デフォルトの名無しさん
17/01/09 13:29:10.71 tlAVTCLv.net
いいわけ乙

451:デフォルトの名無しさん
17/01/09 15:50:51.64 NcQuvnbl.net
assertは書きたいことを大体書けるが、型表記機能とやらは書けないことの方が多い
型名はただの名詞だから
コミュ力が低下する薬を飲まされて名詞しか話せなくなったような面倒臭さがある

452:デフォルトの名無しさん
17/01/09 17:41:15.96 +XRGLqqZ.net
それは当たり前だろうよ、縛りを設ける代わりに、主にIDEから恩恵を受けようというものだからね。
機械を自在に動かしたいというスクリプター的には、機械のために書いてるようで合わないだろうよ。

453:デフォルトの名無しさん
17/01/17 03:06:44.47 lw1Zwsst.net
Pythonは素晴らしいけどPythonが素晴らしいのではなく、
Python周りのネイティブライブラリ環境が大変素晴らしい。
道具としては最高だけど、プログラミング言語大好き人間としては不満。
もっと速度を上げ柔軟になってくれたら嬉しいんだけど、もうそっち方面は目指してないみたいだね。

454:デフォルトの名無しさん
17/01/17 06:39:50.13 rIfocs2Z.net
必要以上に手をかけると処理系のメンテが困難になり結果的に進化の足を引っ張ることになる
Rubyなんかまさにそうで、オタク共がよってたかって好き勝手にいじくり回したせいで詰んでる

455:デフォルトの名無しさん
17/01/17 07:09:05.55 lw1Zwsst.net
でもPythonみたいにCythonで割り切るのもねぇと思う。
割り切ってもJSとどっこいどっこいの速度しか出んが。

456:デフォルトの名無しさん
17/01/17 19:48:56.56 jfonssfd.net
>>454
具体的にどう詰んでるのか解説を

457:デフォルトの名無しさん
17/01/18 12:29:49.23 RtvJVUCC.net
るびいは作者の頭とユーザーの頭と言語仕様が詰んでるって先生が言ってた

458:デフォルトの名無しさん
17/01/18 12:36:00.48 FlJR5GPR.net
キチガイ

459:デフォルトの名無しさん
17/01/18 13:10:26.31 jc+edUai.net
結果論だがPerlを批判するだけで勝てたんだよな
Pythonは本当にそれだけで勝った
Rubyは批判したいのか擁護したいのかはっきりしなかった

460:デフォルトの名無しさん
17/01/21 23:28:19.21 sMDuy5hJ.net
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(prog板)

461:デフォルトの名無しさん
17/01/22 14:38:27.08 hBhrTyQG.net
URLﾘﾝｸ(chrome.google.com)

462:デフォルトの名無しさん
17/03/02 01:30:06.94 GY40xFBu.net
URLﾘﾝｸ(gihyo.jp)
古い記事だけどやっぱ面白いね
何が嫌なのか知らないけど、静的型から逃げ回って
無駄に複雑なことになっていく感覚、本当にすごいわ
型さえ書けば済むことを、よくもここまで複雑にね～
Unixの思想に反するわ
で、最新の情報ではRuby3.0はどうなることになっているの？
静的型は導入されるの？
でもま、今更導入するぐらいなら初めから導入しておけばよかったのにね
当時から静的型はあったでしょ、C言語とか静的型だし
そんでRubyはCで書かれてて自分は静的型の恩恵を受けてRubyを開発したはずなのにね
十分知ってたはずなのに、今更導入とか、それって筋悪いんじゃないの？何周遅れww
それを認めたくないから静的型の導入に対して渋々なんだろうけど
そんな詰まらないプライドで言語使用が決定されたらRuby使いはたまったもんじゃないね
でもそんな事(タイプセーフの重要性)は周りから見れば分かりきっていたことで
だから俺はRubyには近づかなかったわけでさ
微妙に消極的に静的型のメリットを語ってて、何をいまさらって感じなんだけど
本当に複雑怪奇だね

463:デフォルトの名無しさん
17/03/02 07:33:26.80 m5ydKowW.net
>>462
スクリプト言語のほとんどは静的型じゃないけど、このスレ全体にケンカ売ってるのかな…？ｗ

464:デフォルトの名無しさん
17/03/02 12:26:11.03 FleTjgpE.net
スクリプト言語っていろんなものの橋渡し、
間に入り込む接着剤のような役目なんだから動的型で間違っていない
ただそれだけでしっかりしたものを作ろうとすると大変だねってだけ

465:デフォルトの名無しさん
17/03/02 12:33:41.17 GY40xFBu.net
俺が思うにRubyは夢を売る商売なんじゃないかと思う
ディズニーランドとか宝くじとか
あるいは漫画やアニメの専門学校と
同じようなモノなんだろう

466:デフォルトの名無しさん
17/03/02 13:05:30.50 GY40xFBu.net
Rubyは意図的に静的型の機能を外したわけでしょ？
当時からC言語はあったし、RubyはC言語で開発されているんだから
知らなかったわけないんだよ
知ってて明確な意図をもって外したわけでしょ
それをいまさら導入とか意味不明だよね
だったら初めから導入していればよかったわけで
あとから導入するの大変でしょ
これが何か目新しい概念とかだったら時代背景とかと合わせて
あとから導入はわかるんだけど
静的型って大昔からあって、むしろスタンダードだったわけで
今更検討とか今もう2017年だよ？何やってんだよ
まったくの迷走だよ

467:デフォルトの名無しさん
17/03/02 14:33:53.15 OL5emEw+.net
結論としてJuliaってことだね

468:デフォルトの名無しさん
17/03/02 15:55:48.82 iFkNWUjs.net
無知の長文

469:デフォルトの名無しさん
17/03/02 16:21:28.87 k95nzBVS.net
crystal もよろしく

470:デフォルトの名無しさん
17/03/02 23:42:14.51 JZiPjSZc.net
>>466
動的型は実装が簡単なんだよ

471:デフォルトの名無しさん
17/03/03 03:21:52.12 oJ3jWx7w.net
>>470
逆だが…動的型の方が面倒くさい
>>466 はただの荒らしだからまともに取り合うとロクなことないよ

472:デフォルトの名無しさん
17/03/03 07:12:07.86 4qcBtzlj.net
>>471
動的型信者が静的型をdisるときによく言う「静的型の方が型が決まってるから実装が楽だが～」
みたいなのを真に受けてるのかな
自分で簡単な言語を実装してみたらわかるよ
問題は型が静的か動的かよりも静的コンパイルの実装コスト

473:デフォルトの名無しさん
17/03/03 12:07:08.08 ivKlbKhz.net
静的コンパイルはコンパイル系と実行系で処理系が2重になるのが複雑
あらかじめ仕様をきっちり決めておかないと手戻りが多発するからスクリプターのノリで適当に作るのは困難

474:デフォルトの名無しさん
17/03/03 12:34:26.64 IT/QqIXj.net
コンパイラも自作しちゃえばいいのよ

475:デフォルトの名無しさん
17/03/03 17:08:10.47 bWq8JKgn.net
仮に動的型のほうが静的型のよりも
最適化を含めるとなると難しいんだったとしても
それはまったく無駄な努力だからな
あと、動的方言語を静的に解析してエラーを見つけるのは難しいんだけど
それも無駄な努力だからな
静的型にすれば済む話
問題を直接解決しようとせず、周りをウロウロして何とかしようとするのは無駄
最近の言語に静的型が多いのは、誰も無駄な意味のない努力をしたくないから
動的型は、何か、ズレてるんだろう
砂糖と塩を輸送するのにブレンドして輸送する感じ
もしかしたら輸送費は安くなるかもしれないが
後で分離する手間考えたら分けて輸送したほうが良い
動的型の型を静的に解析するのはまさにそれに等しい行為
手間が増えるだけ

476:デフォルトの名無しさん
17/03/03 17:15:56.85 bWq8JKgn.net
静的型言語の実装の難易度を基準とすると
動的方言語は、とりあえず動けばよいってレベルなら超楽勝
しかし実用になるレベルにするのに
まじめに最適化を実装しようと思うと途端に難易度は跳ね上がり超絶難易度になる
間は無い
うま味がないってこと
誰も手を出さなくなったわけだ

477:デフォルトの名無しさん
17/03/03 17:18:10.38 GTe30Tvn.net
糖質なフレンドだね

478:デフォルトの名無しさん
17/03/03 17:28:09.10 bWq8JKgn.net
GoogleのV8エンジンとかは、技術的に本当に興味深く凄いなぁと思う反面
あんな苦労は絶対したくないし
言語仕様のほうをどうにかしたほうが手っ取り早いのは確実
本当に動的型言語は何するにしても無駄に壮大で大変だなぁ
静的型言語が全ての答えなのにね

479:デフォルトの名無しさん
17/03/03 18:31:58.34 BNfiYHeO.net
V8はC++で書かれているけど、
Chrome含むGoogleのC++はマクロで魔改造されてる。
C++のマクロだけじゃなく、Pythonも使ってソースコード置き換えをしてる。
結局「全ての答え」などというものはない

480:デフォルトの名無しさん
17/03/03 21:12:00.24 wq3/hASM.net
全ての答えおじさんは自分で言語作ったりするの?
ただのユーザだったらうけるんだが

481:デフォルトの名無しさん
17/03/03 21:45:28.70 aYsFsxPN.net
動的言語を速くする努力なんて無駄だっていうけど
Javaが速くなったのはV8と同じ技術の流用だろ？

482:デフォルトの名無しさん
17/03/04 13:07:22.03 TytE5WQL.net
むしろJavaが先駆者というかJIT技術の長年の代表者かな
でもJavaとV8は実際やってることは全くと行っていいほど違う
何故かと言うとJavaは結局コンパイルしてバイトコードにした時点で実際の最適化の殆どは済んでいる、実際はJITはオマケのコンパイル言語だ
そこから少しだけプロファイルを取ったり、各環境向けに最適化するが、微々たるもの
そもそもバイトコードにした時点で情報が結構失われるからそこからJITするのに限界がある構造
でも静的なのでそんなチャレンジングなことをしなくても大体のケースで十分に最適化できるので
バイトコードサイズを小さくする方を取ってるが、実際幾つかのケースでV8含む完全ソースが手元にあるJITに負ける
一方V8は実行時というか実行前から実行中までずっと最適化し続けるJITをやや超えるもの

483:デフォルトの名無しさん
17/03/04 15:50:13.16 W8crb5iK.net
Javaなんかコンパイラがどんなに良質なバイトコードを吐いたところでJITを切ったら使いものにならないよ

484:デフォルトの名無しさん
17/03/04 20:30:51.92 TytE5WQL.net
動的コンパイル≠JITコンパイル

485:デフォルトの名無しさん
17/03/04 20:49:23.65 9zDoQRRc.net
JITコンパイル≠HotSpot技術≒V8の技術＝anamorphic

486:デフォルトの名無しさん
17/03/04 21:09:43.19 9zDoQRRc.net
>>482
オマケのわりにはクリティカルじゃね？
URLﾘﾝｸ(blog.cybozu.io)

487:デフォルトの名無しさん
17/03/04 22:43:59.15 W8crb5iK.net
Animorphic Smalltalk VMやね

488:デフォルトの名無しさん
17/03/05 01:08:23.00 MrlX2Uoe.net
>>486
2倍は全くクリティカルではない
JSだとJITは数十から数百倍のスケールで恩恵がある

489:デフォルトの名無しさん
17/03/05 07:40:06.85 c4lSj3ER.net
>>488
それベンチマークに特化したコードでの話じゃね？
それならJavaでも似たような差がでるよ

490:デフォルトの名無しさん
17/03/05 19:03:52.33 ONGjQtv5.net
>>489
良いことなのかも知れないけれど、昔のインタプリタの頃のとてつもない低速度忘れちゃったんだな

491:デフォルトの名無しさん
17/03/05 20:03:49.77 tiOeAN9d.net
>>490
Java VMは今も昔と変わらずバイトコードインタプリタだよ？

492:デフォルトの名無しさん
17/03/05 21:02:12.11 xrJm/RDc.net
THE　アスペ

493:デフォルトの名無しさん
17/03/05 21:12:38.66 ONGjQtv5.net
いいんやで、もうどうでも

494:デフォルトの名無しさん
17/04/13 09:59:12.88 z2xiyw8y.net
TypeScriptの採用が増えそうで俺歓喜
Google社内の標準言語としてTypeScriptが承認される。ng-conf 2017
URLﾘﾝｸ(www.publickey1.jp)
Google、社内標準言語の一つとしてTypeScriptを採用
URLﾘﾝｸ(developers.srad.jp)

495:デフォルトの名無しさん
17/04/15 23:41:19.57 Af1/s0zG.net
URLﾘﾝｸ(gihyo.jp)
まったく往生際が悪いというかなんというか、何の意味があるの？
一方ロシアは鉛筆を使ったって感じ
「負けたんだよ」ってだれか言ってあげて

496:デフォルトの名無しさん
17/04/16 00:02:02.80 AmA5ei6y.net
大体型を書くのが面倒ってのも良くわからないし、型推論とかもあるのにな
あと型が書いてあったほうが読みやすい場面も多々あるし
機械にもわかりやすくて人間にもわかりやすくて、丁度よいじゃないか
あとほか宣言があると・・・宣言は型だけじゃなくスコープの宣言でもあるわけでして
宣言なし言語はスコープが気持ち悪いことになってるのが多いよなw
それからダックタイピングは本当に必要なのかどうなのか
静的型であってもジェネリックやテンプレートやオーバーロードがあれば
静的なダックタイピングは可能なわけで、しかもタイプセーフだし
動的なダックタイピングなどという危険極まりないものが本当に必要なのか？
ダックタイピングは静的に解決できる範囲で楽しめばよいだろうよ
それですら黒魔術とか言われるのにな
あと、WebAssemblyな、結局C++などの静的型言語を中間言語にしたものを
ブラウザで読み込んで機械語に変換して実行しようよっていう
どこまで行っても結局型が判明しているほうが最適化しやすいよね
CPUの進化が鈍化してきているし、物理的限界が近いことも考えれば当然の流れだな

497:デフォルトの名無しさん
17/04/16 05:04:24.13 O+EWztiU.net
WASMでDOM操作とか夢のまた夢だし、
そもそもJavaでのDOM操作も実情はきつかったし
別にWebで無くてもいいような１つのアプリケーションを作るんなら
型は有用だけど、何かと何かをくっつけたり、加工したりするための
スクリプト言語としては全くの不要だよ

498:デフォルトの名無しさん
17/04/16 07:06:11.63 aIkdKg/w.net
>>496
> それからダックタイピングは本当に必要なのかどうなのか
> 静的型であってもジェネリックやテンプレートやオーバーロードがあれば
> 静的なダックタイピングは可能なわけで、しかもタイプセーフだし
ダックタイピングのこと分かってないだろ

499:デフォルトの名無しさん
17/04/16 09:52:33.87 SqhlDt4o.net
ダックタイピングはそれをプログラマが活用するのではなく
動的言語における多態性の(安易な)実装手法にすぎない

500:デフォルトの名無しさん
17/04/16 10:22:58.46 XyqfpBE9.net
という完全に誤った理解が蔓延しているというお話し

501:デフォルトの名無しさん
17/04/16 10:23:01.86 AmA5ei6y.net
>>495のURL先は皆読んでくれたかわからんが
掛け違えたボタン感が本当にすごくて
最初の一歩を間違えるとこんなにも面倒なんことになるのかって感じ
北朝鮮はどこまで進化しても北朝鮮ってことなんだろうよ
うすら寒い理想の未来を語るところもよく似ている
過去に生きて、未来を語って、現在に生きてないって感じ
まさに掛け違えたボタンで、「現実」のボタンをスキップして飛ばしている
胡散臭い宗教とかもそんな感じだよね
たぶん「現実」に不満がある人を集めるのが目的だから
過去の技術を使って、未来を語ってみせて、騙くらかすって事なんだろうな
これがまさしく、走り続けないと終わる、の意味だろう
でももう流石に誰も騙されないよね
麻疹みたいなものだから、学生さんは一度はそういう目に合うかもだが

502:デフォルトの名無しさん
17/04/16 10:25:51.21 AmA5ei6y.net
もしくは、ボタンを掛け違えていることに本人だけが気付いていなくて
誰も追いついてこないな～なんて思っていたら
実はみんなもっと遠いところで高度なことをやっていた、ってパターンか
誰も追いついてこないんじゃなくて、フォロワーが居ないってことなんだけどね

503:デフォルトの名無しさん
17/04/16 11:27:58.86 cCOM2/u0.net
ダックタイピングというのは、（人間が）ガーガーと
アヒルのモノマネをすれば、アヒルとみなして扱おう
という発想から生まれたもの

504:デフォルトの名無しさん
17/04/16 15:33:13.73 aIkdKg/w.net
>>501
ダックタイピングのことを何も分かってない人間がいくら言おうと説得力はゼロだよ

505:デフォルトの名無しさん
17/04/16 16:41:45.39 AmA5ei6y.net
残念ながら>>499が正解なんだな～
俺も、もし何かの都合で自分で言語を作る必要性に駆られたら
そうするだろうね、実装が圧倒的に楽だから
つまり、自分で言語を作って、自分で使うんなら
現代においてもなお、動的型はありうるんだよ、これが
言語を作る手間と時間もコストとして換算して
トータルで労力を最小にしたいから
どこでバランスするかの問題
もしくは自分はもっぱら言語を作るのがメインで、使うのは他のやつって場合も
自分だけが楽できれば良いという身勝手な発想に行き着いたのなら、ありえる
自分は静的型言語でその恩恵を十分に得ながら言語開発して
他人は自分の作った言語で苦しむっていう
人として最悪な感じにはなるけど、まぁ最終的には良心の問題
金もうけのためだったり仕事って事なら仕方ないけど
人生の目標にしたら只の嫌がらせだな
それはそれとして、既存の言語を使うだけなら
わざわざ手抜きな言語をあえて選択する意味はないよ

506:デフォルトの名無しさん
17/04/16 16:43:12.44 aIkdKg/w.net
>>505
ダックタイピングをジェネリクスで代替できると思ってる人間の論理に説得力はない

507:デフォルトの名無しさん
17/04/16 16:45:25.04 cCOM2/u0.net
ダックタイピングはジェネリクスではなく
インターフェースで代替するもの

508:デフォルトの名無しさん
17/04/16 16:49:53.76 aIkdKg/w.net
>>507
その通りだね
そしてインタフェースをいちいち付けてまわるのは非常に面倒臭いこと
自分で作るクラスならまだ何とかなるが、使ってるライブラリのクラスだとそうもいかない

509:デフォルトの名無しさん
17/04/16 16:54:54.02 cCOM2/u0.net
> そしてインタフェースをいちいち付けてまわるのは非常に面倒臭いこと
めんどくさい？ダックタイピングではインターフェースがないから
代わりにコメントで同じ情報を書かないといけないじゃん。
インターフェースの情報（コメント含む）を書かないで
それが仕様かどうか分かってもらえると思ってんの？

510:デフォルトの名無しさん
17/04/16 17:00:32.58 aIkdKg/w.net
>>509
コメントなら書くか書かないかは開発者が選べる
それを「低レベルコード生産要素」と見るか「プログラマの自由を保証」と見るかは
ポジションによる
Matzなんかは後者の立場なんだろうし、日本のSIのような人月計算でレベルはおかまいなしのような
プロジェクトに関わってるような人から見れば前者になるんだろうね

511:デフォルトの名無しさん
17/04/16 17:01:19.16 AmA5ei6y.net
「静的な」ダックタイピングはジェネリックとオーバーロードで実現可能
という風に書いたのにこれが理解できないのではどうしようもない
きっと静的と動的の違いも理解できてないんだろう
静的なダックタイピングはタイプセーフだし
本当にうまい落としどころだなぁって思う
何もかもが静的型に都合がよいように回ってて、ちょっと怖いね
とはいっても俺も何でもかんでも型で解決しようってのはあまり好きじゃなくて
一つのアイデアが上手くいくと一気に乗っかっていく感じは何か過剰というか
ただ、そうはいってもダメなものがダメなことには変わりないんだけどね

512:デフォルトの名無しさん
17/04/16 17:01:47.01 cCOM2/u0.net
>>510
> コメントなら書くか書かないかは開発者が選べる
言い換えると、
コメント書きたくない、仕様書を書きたくない。
コード読まないとわからない。
というコードを書きたいってことか？
ひどいな。だから可読性が下がるんだよ。

513:デフォルトの名無しさん
17/04/16 17:03:04.51 aIkdKg/w.net
>>511
ぜんぜん違う
ほんとダックタイピング分かってないんだな
ID:cCOM2/u0 なんかはその辺分かってるから議論になるけど、お前にゃ無理だよ

514:デフォルトの名無しさん
17/04/16 17:07:46.06 aIkdKg/w.net
>>512
Matz の有名な言葉に「ソースがドキュメントだ．バグも完全に記述されている」ってのがあるからねぇ
冗談半分だとしても、思想としてそういう方向なんだろう
本気半分の言い分としては、ソース読んだだけでちんぷんかんぷんなコードはその時点で怪しいと思え
って感じだろうか

515:デフォルトの名無しさん
17/04/16 17:08:31.24 cCOM2/u0.net
インターフェースは契約プログラミングの一種でもあるんだよ。
インターフェースを定義することは事前条件を定義することにあたる。
事前条件を記述することで、予め（プログラムを実行しなくても）バグがあることがわかる。
実行パスは無限と言ってもいいほどあるから、実行しなければ
わからない問題を検出するのは時間がかかる。
だけど、条件を満たすかどうかを調べるために、
実行そのものが必要なければ、短時間で問題が検出できる。
コンピュータが理解できる方法で、しかも実行せずにわかることと
コメントという人間しか読めない方法で書くのとでは全然意味が違う

516:デフォルトの名無しさん
17/04/16 17:09:43.45 AmA5ei6y.net
静的型において動的な多態にインターフェースを使うのは当たり前
動的なことは危険な香りがするから、インターフェースで制約する
これも丁度よいぐらいの落としどころなんだよ
静的な多態はジェネリックとオーバーロードでダックタイピングも可
動的な多態はインターフェースを通して安全に
どちらの場合もタイプセーフ
よくできているよね～

517:デフォルトの名無しさん
17/04/16 17:10:37.85 aIkdKg/w.net
>>515
そういう方向でバグを減らすというのもひとつの方向性としてはいいんじゃない？
単なる思想の違いというだけで、そういうのが嫌いな人が作った言語だって別に悪いわけじゃない

518:デフォルトの名無しさん
17/04/16 17:12:57.07 aIkdKg/w.net
>>516
だからお前はダックタイピング分かってないんだからもういいよ
staticおじさんのように、分かってない機能は全部けなす方向性の人間と議論になんかならんからな
まずお前にすすめるのはリーベルGの「高慢と偏見」を読めってことだ

519:デフォルトの名無しさん
17/04/16 17:13:47.39 cCOM2/u0.net
>>517
> そういう方向でバグを減らすというのも
そういう方向で"も" な
バグを減らすテクニックはいくつもある。
静的言語なら、そのテクニックが増えるわけだ
動的言語でできるバグを減らすテクニックは、静的言語でも使える。
さらにプラスして、静的言語ではコンパイル時に実行することなく
バグを減らすことが可能になる。
これは明らかにバグを減らすために追加された機能といえるだろう

520:デフォルトの名無しさん
17/04/16 17:15:16.10 aIkdKg/w.net
>>519
そのために生産性やプログラマの自由が減るというトレードオフがあるけどね
そのトレードオフのどっちを取るかはポジションで決めればいいだけの話

521:デフォルトの名無しさん
17/04/16 17:16:58.16 AmA5ei6y.net
ちなみにダックタイピングは、ダックのように振舞うものは、ダックとして扱える
って言ってるだけで
静的に解決するか、動的に解決するかは、別の問題であり
当然静的なダックタイピングは、ある
>ダック・タイピング
>URLﾘﾝｸ(ja.wikipedia.org)
>C++のtemplateはダック・タイピングの静的版である
残念だったなwww
それともWikiを書き直すか？

522:デフォルトの名無しさん
17/04/16 17:18:10.05 aIkdKg/w.net
>>521
俺はテンプレートに関しては何も言ってないが？
ジェネリクスはちゃうやろって言ってるんだが

523:デフォルトの名無しさん
17/04/16 17:20:02.41 cCOM2/u0.net
>>520
> そのために生産性やプログラマの自由が減るというトレードオフがあるけどね
減ってないよ。逆に高くなっている。
っていうか、あんた書くときのことしか考えてないでしょ？ｗ
プログラミングっていうのは書くよりも読むことのほうが遥かに多い。
だから、可 "読" 性が重視される。
読みやすいコードは生産性を大きく上げる

524:デフォルトの名無しさん
17/04/16 17:27:15.74 0ImhO/qF.net
>>521
× C++のtemplateはダック・タイピングの静的版である
○ C++における型消去はダック・タイピングの静的版である
明らかに間違ってるから直しとけよ

525:デフォルトの名無しさん
17/04/16 17:29:05.78 aIkdKg/w.net
>>523
それは違うな
コメントなら引数を「与えられる方」だけ書けばいいが、インタフェースは引数を「与える方」にもそれを強制する
そしてこれは結構面倒な作業だ
もちろん、引数として変なものを与えてしまう可能性も出てしまうが、それと上記の面倒さをどっちを取るかは
それぞれの人が決めればいい

526:デフォルトの名無しさん
17/04/16 18:04:26.80 AmA5ei6y.net
現代に生き残りし貴重なサンプルだとは思うが
「何が面倒か」までは書かないんだよな
結局、何でもかんでも渡すわけにはいかないのは同じこと
どのみち仕様を満たさなきゃならん
ダックならダックの仕様を満たさなきゃならん
ダックの仕様を満たすように書かなきゃならないのと
ダックのインターフェースを満たすように書かなきゃならないことは
実質問題大差ない
大差ないか、むしろインターフェスがあった方が何をすべきかよくわかるぐらいだ
仮にこのケースでほんの少しだけ動的型が便利だったと仮定しても
静的型の、型安全性、リファクタリングのしやすさ、タイポなどの些細なミスの検出
型が書いてあることによるドキュメンテーション、最適化のききやすさ
あと宣言があることによるスコープの細かさ
これらすべてを投げ捨てるほどの差はない
動的型のメリットといえばもはや動的なメタプログラミング的な何かぐらいしかないが
そんな黒魔術はどうでもよいし、はっきり言ってgoto文と変わらない

527:デフォルトの名無しさん
17/04/16 18:10:54.82 AmA5ei6y.net
こういうと彼はきっとこう思う
静的型は互いに別々の出どころのライブラリ間で
インターフェースに互換性がないから困る、と
しかし、そんなことは動的型でも同じこと

528:デフォルトの名無しさん
17/04/16 18:14:22.59 cCOM2/u0.net
>>525
クラスだけ与えられて、
さてこのクラスはどこで使えるでしょう？
みたいなクイズして楽しいか？
このクラスが持っているインターフェースは何かって
ちゃんと書いていれば、そのインターフェースを使える場所も
明確にわかるだろ

529:デフォルトの名無しさん
17/04/16 18:15:43.11 cCOM2/u0.net
>>526
> 「何が面倒か」までは書かないんだよな
それだよなｗ
ほんと何が面倒なのか。

530:デフォルトの名無しさん
17/04/16 18:20:36.92 aIkdKg/w.net
>>528
アプリケーションの全クラスが自分の管理下にあればそれも可能かもしれんな
でも実際は様々なライブラリを使うことは避けられないし、各ライブラリのクラスに後から自分が欲しい
インタフェースを追加することはできないことがほとんど
C#やScalaなんかはそういうこともできるみたいだが、今度は可読性が落ちるのでここぞというときの
秘密兵器扱いだな

531:デフォルトの名無しさん
17/04/16 18:26:41.26 cCOM2/u0.net
>>530
各ライブラリのクラスに後から自分が欲しいインターフェースを追加して、
正しく動く保証はあるのですか？
そもそもそんなことする必要ありませんよね？

532:デフォルトの名無しさん
17/04/16 18:29:04.31 cCOM2/u0.net
手段が目的になってしまってるんだよなｗ
何がしたいのかは言わない。
ライブラリのクラスに後からインターフェースを追加することが
目的なんだって臆面もなく言ってしまうｗ

533:デフォルトの名無しさん
17/04/16 18:34:11.12 aIkdKg/w.net
>>531
あるよ
たとえばあるライブラリがAというクラスのオブジェクトを返したとする
これを別のライブラリか自分で作ったクラスのの引数として使いたいけど、その引数はBという
インタフェースを要求する
Aというクラスは字面の上ではBというインタフェースを満たしているのだが、Bというインタフェースを
implement しているわけではない
さてどうしよう
Bというインタフェースを持つクラスを自分で定義してコピーする？こんな余計なことしなきゃいけない
のは生産性の低下以外の何物でもないわな
これは一例であって他にも同様の例はいくらでもある

534:デフォルトの名無しさん
17/04/16 18:43:08.06 cCOM2/u0.net
>>533
なんでAというクラスが、Aとは全く関係のなく作られたBというインターフェースを
たまたま運良く満たすなんて自体が起きるんだよｗ
ありえないだろ。
それよりか引数が違うのに、同じ名前のメソッドを定義してしまっていた
どうしようって思うほうが可能性高いわｗ

535:デフォルトの名無しさん
17/04/16 18:46:33.36 cCOM2/u0.net
Aというクラスは字面の上ではBというインタフェースを満たしているのだが、
Bのバージョンアップでインタフェースが変わってしまった。
だけど、Aというクラスがたまたま古いBのインターフェースと
一致していたという前提をどこにも書いていなかったので、
動かなくなる原因の判明に時間がかかった。
そのためにコメントをしっかり書くようにした。
A は B interface を implements しているよと

536:デフォルトの名無しさん
17/04/16 18:50:50.79 aIkdKg/w.net
>>534
ありえるんだよ、これが
しかもしょっちゅう
(俺は静的型言語でも開発してるからよく出くわすよ)
たとえば、Serializable なんか典型じゃないかな
そのまま Serialize したいのになんで Serializable インタフェース持ってねぇんだよ！
みたいなのはほんといくらでもあるよ

537:デフォルトの名無しさん
17/04/16 18:53:05.94 cCOM2/u0.net
このようにダックタイピングを使うとその場しのぎで直ぐに対応できるように思えるけど
長い目で見れば、可読性の低下を招き、メンテナンス性、生産性を下げることになってしまう。
書いたら終わり、メンテナンスが不要な書捨てのプログラムぐらいにしか
使わない方がいい。
そして、書捨てのプログラムをよく書くのはインフラ系が多い。
インフラ系で必要とされるのはオブジェクト指向も必要ない
数行程度のスクリプト。シェルスクリプトよりは書きやすいぐらいの
理由しか持ち合わせてない
アプリの開発には長期間メンテナンスされるので可読性が重要

次ページ