【JavaScript】スクリプト バトルロワイヤル55【php,py,pl,rb】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>374
SmalltalkのOODBってMysqlとかと比べて100倍位遅いんじゃなかったっけ? talkerじゃないがRDBMS用のORMもあるって書いてなかったか >>371
彼らはトンチンカンなわけではない
言語に求めること、向き合う姿勢が違うから話が噛み合っていないだけ >>375
どんなOODBと比べて? 商用のGemStone/Sがそんなだったらヤバい talkerとしてはむしろ
音も全て漢字で記述していた太古の人に
ひらがな・カタカナの便利さを伝える漢字に近い
でも彼らの世界/文化レベルでは必要にならないことは
ちゃんと分かってるが、一応は説得する 漢字は外来語だけど翻訳しなくてもそのまま使える単語は便利じゃん
翻訳しないと通じない接続詞とかはひらがなで書く Smalltalkよりも遥かにマイナーなErlangは
マイナーでも価値が認められて、色んな企業で使われてる
Smalltalkが使われないのはマイナーだからじゃなく価値がないから 違うと思うメッセージングによる遅延結合の徹底という考え方が人類にはまだ早すぎるから メッセージングによる遅延結合の徹底というアイデアはwebで余すところなく実現されてる
ちっさなローカルPCの1プロセスの中でやるのがアホで無価値なだけ そんなもんが現在価値があるかどうかと関係あるとでも?
馬車が自動車に影響与えたからって今でも馬車に乗るくらいのアホさ加減だな >>371
> AがSmalltalkだろ
お前、どんな気持ちで>>370が「BがSmalltalk」って
言ったか、考えたことあるのか! >>384
Smalktalkに価値があると言っても、全てに価値があるわけじゃないのです。
他に影響を与えられなかったものは価値がなかったと考えるべきです。
つまりSmalktalk独自と言えるようなものは価値がないということです。 >>385
たしかに馬車は自動車に先行して使われて影響を与えたし
今でも観光目的などに細々と使われている点とかはSmalltalkの現状に似ていていいたとえかもw
ただSmalltalkと馬車が違うのは、つい最近も自動車wのトレンドに影響を与えるものを生み出していること >>387
豚に真珠、猫に小判じゃないけど、
まだ真似されず独自の部分が現時点では無価値という意味では当たらずとも遠からずか
などと言ってみたところで馬の耳に念仏…というところも含めて こういう隔離スレでこんだけ暴れてるのに本スレは今月1レスしかない。終わった言語 暴れてるって、いわれのない言いがかりをつけてきて
無用なスレ消費を助長してるのはアンチのほうだろ どうせ仕事でSmalltalk使ってないでしょ?
なんで使わないの? いわれのない言いがかりをつけてきて
無用なスレ消費を助長してるのはアンチのほう たしか最近は悪口ばかり言う方が悪者ということになっていた筈だが >>388
関数型言語はMapReduceとか、最近だとAWS Lambdaなどにコンセプトが受け継がれてて
まさにトレンドに影響を与えてると言えるけど、
Smalltalkにそんなものあったか?
まさかtraitsとかいうoopの一構文に過ぎないものの事を言ってんの? MapReduceとかAWS Lambdaとかはメインフレーム時代のプロセス指向なバッチ処理への回帰であって、
関数型言語のコンセプトとは粒度が違いすぎると思うけど TraitsとMixinを混同するならともかく、oopの一構文とかどんな理解力不足なんだよ >>398
どっちもスケールの問題に対する関数型的な解決だよ
なにがプロセス指向なバッチ処理だよ馬鹿は黙ってろ >>399
traitsもmixinもたかがoopの一構文に過ぎない
そんなもん全く重要じゃないし、そんなのに拘ってるから下っ端コーダのままなんだよ >>481
じゃあお前にとって重要なものは何?
社長が重要とかいうボケはいらないからね >>400
> どっちもスケールの問題に対する関数型的な解決だよ
AWS Lambdaで使える言語は、Node、Java、Pythonなんだけど
関数型的な解決だという根拠は? >>403
AWS Lambdaで書けるのはステートレスな関数に制限されてるだろ
状態を持たないことによる並列化のしやすさや疎結合という
関数型言語で得られる(と言われてる)メリットをアーキテクチャレベルで実現してる
てか、こんな簡単なことも言われないと分かんないの?馬鹿なの?どんな言語で書けるとかマジどーでも良いんだよ vector<char>なら状態を持つがstringはステートレス
プロセス間通信のネットワークは文字列型と言ってもよさそうなものだが
文字列処理の価値を認めないのはSmalltalkと関数型に共通する特徴だと思う lambda言ってる時点で関数型意識してるでしょ。
プロセス代数が出るならまだしもバッチ処理とかって、、、 なんだw 「関数」と「関数型」をごっちゃにしているやつだったかw
AWS Lambdaはファイルやデータベースを読み書きできる
そういった「関数」を登録する。
ファイルやデータベースを読み書きする関数が「関数型」だというのなら
バッチ処理だって関数型だよw >>407
ステートレスなコンテナってとこがミソなんだよなぁ
いくらでもスケールアップできて、S3のイベントなんかに反応して計算して、終わったらコンテナごと全消去
入力と出力だけ考えれば良くて、リアクティブで副作用なしでスケールアップ可能ってのが特徴なので、古典的バッチとはぜーんぜん違う それを単なるバッチ処理と言うんだよw
それこそメインフレーム時代から続く伝統的なIPO型アーキテクチャだ >>411
ユーザがファイルをアップロードしたらAWS Lambdaで計算して結果を返す(典型的な用途)
これがバッチ処理ならhttpサーバはバッチ処理してるんだなw >>412
全く本質が見えてないな
それが関数型ならインプレース更新を行わない古典的なバッチ処理はだいたい関数型だと言ってるんだよ >>413
本質が見えてないのはお前だよ
ただ単に、副作用がない関数でシステム書けば関数型か?って聞くならともかく
どっからバッチ処理が出てきたの?w >>414
問題は処理の粒度
Lambdaにずいぶん夢見てるみたいだけど、Lambdaは呼び出しのオーバーヘッドが大きすぎる
現実的にはバッチ処理やS3にアップロードされた画像ファイルを処理するといった粒度の大きな処理単位でしか使い物にならん
そのレベル止まりなら全く目新しいものではなく、現代にあえて関数型だと言うなら粒度の小さな処理に対しても統一的に適用できる仕組みが必要
「Lambdaによるリアルタイム処理」みたいな言葉が独り歩きしてるが、あれスループット上げるために
わざわざKinesisを間に入れてマイクロバッチ処理に変換したりするんだぞ OOPのメッセージパッシングも、所詮関数呼び出しじゃんって言ってそう、、、 粒度が荒くなると関数型じゃなくなるなんて
これまた珍妙な説出してきたなw 言語が一つじゃなくなる粒度とか
OSも言語もバラバラ >>417
副作用をもたらすから関数型じゃないんだよw
オブジェクト指向でも副作用がない関数を書いたら
それは関数型だって主張したいのかい?w 俺はこの問題に二十年取り組んできたが、結論は出てる。
「作者が関数型と主張した」言語が関数型だ。
そもそも最初はシンプルだったものも、どんどんリッチに汎用的になるに連れ
元来の関数型とは乖離していっている。
特にこの10年、今まではそれでも範囲内で拡張するすべを探していたのが
妥協する策を取るようになった。
汎用でリッチなプログラミング言語としてはその方がずっと都合が良いからだ。
したがって今の著名でここのスレ民が主に思い浮かべるような言語は関数型ではない。
強いて言えば、作者が「関 数 型」と主張しているという程度のこと。
個人的には「関数型」言語とはもはや「P」言語に近い。 意訳
「>>420が関数型と主張した」言語が関数型だ。 ニセ科学に反対するだけで良かったのに
代案を出せとか煽られてついつい関数型という怪しいジャンルを作ってしまったんだな つーか殆どがマルチパラダイムじゃね?
そこに対抗してマルチパラダイムに対応できない言語が
純粋○○であることを売りにしてるけど、それ欠点だよねw うるっせえなこの馬鹿どもは
スクリプトの覇権は昨今の機械学習/AIブームでオッパイソンさんで確定したろ
あとは黙ってPython極めることに専念しろ PHP 7.0.x から PHP 7.1.x への移行
http://php.net/manual/ja/migration71.php
PHP7.1リリースキター! hackのnullable型導入とかか?
とりあえず x.1 待ちしてた奴ら移行しろよ。 直也:.NET CoreというかC#って型があって、しかもサーバーサイドも書けるじゃないですか。Linuxでやってた人たちはずっとスクリプト言語使ってて、
Rubyとか型がない言語でサーバーサイド書いてることに疲れてきちゃってるんですよね。
ある程度の規模のものではサーバーサイドも型がある言語で書きたいと思って、
ScalaとかJava 8をやってみたんだけど、どの言語もちょっとバランスが悪いんですよね。
Scalaはプログラマ寄りすぎるし、Javaはコンサバすぎる。サーバーサイドSwiftもとがりすぎてるし。
実績があって型がある言語ってC#なんですよね。そのC#がLinuxで使えるのは大きいんですよね。
だから、ワンチャンあるなって。あとは市場が評価するかどうかなんですよね。
バランスはいいと思います。それがWindowsだけでなくMacでも使えるようになったのは本当に大きいですし。 >>428
いい加減現実を見よう
未来へ一歩踏み出そう 未来を見ず現実を見たつまらない言語がDartなんだが 間違いはGoogleが現実の問題とニーズだけを見ていて自分の立場が見えていなかったことだな
そんなことをGoogleに求めている奴はいない
輝かしい切捨ての歴史を持つGoogleを土方分野で信用する馬鹿はいない 大事なのは言語云々よりDartVMでしょ
ブラウザへの統合を断念した時点で終わった >>432
ブラウザ統合自体が重要なのではなくてGoogleのやる気の問題だろう
Chromeに統合するという触れ込みで登場した当時は
Googleが本気だ! ということでそれなりにインパクトがあった
Dartが注目されていたのはそのGoogleの本気というただ一点だったのだから、
「結局いつものGoogleだった」となった時点で当然もう何も残らないよ >>432
サーバ側ならどう?
typescripあるしphpも型付けることできる用になったから難しいかな? Goもあるし.NET Core(C#)も盛り上がってきたからねえ
残念ながらDartにはもう出番はないよ wasm対応で先手を取れれば状況がひっくり返る可能性もあるが
asm.jsの時点でやる気0だったしなあ JavaScript死亡www
「WebAssembly」がITの未来に変革もたらす|Google、Apple、Microsoft、Mozillaが共同で開発した新概念
「WebAssembly」がWebブラウザに変革をもたらします。
Webブラウザは、もともとただテキストを表示するだけのところから始まりました。その出発点から、現在ではコミュニケーションやゲームまで幅広い表現を可能にしています。
そして今回、「Webブラウザ」に新しい概念が加わわることになりました。
それをもたらしたのが、ブラウザに関わりの深い世界規模の4社「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 モンスターのアイコンの統一感がなさすぎるな
線が細いキャラと太いキャラを並べると違和感のかたまり >>438
今更な記事を引っ張ってこられてもな。
対応言語c,c++以外も増えたのかねぇ。 どうだろうね。
まあ「その都度ソースコードを機械語に翻訳する必要があるため」遅い
という問題は、わかりやすい問題だから改善されていくよ。
最近だとV8で、即時関数っぽい書き方されたコードは最初から最適化して
すぐ実行できるよう準備するようにするパッチが入ったじゃん。
そういうのの積み重ねで良くなっていくと思うよ。 >>158
ただ自分の優位性を示したいだけの典型的な権威主義の馬鹿だな
自分の主張やは無いくせに〜ぐらいはしてるよね?とか
お前仕事場でも嫌われてるタイプだろ
少なくともHaskellは特定分野以外はまともに使えない
実際使ってればつまずくのですぐ分かる話 Haskellはまだ趣味の範囲であらゆる分野で使える言語だよ。だって純粋関数型言語じゃないから。 >>444
貴方の思う純粋関数型言語の定義とその例を述べなさい(100字以内) このスレのお前らがどう思っているかが一番重要なんだよ
多くのヒントになるから
時代は常にこのスレで言われていた事の反対に進んだだろ?
今は静的型全盛で動的型プッって感じだし
さんざんな言われようだったJSはむしろメジャー言語になったし
今JSが糞って言われているのは主に動的型だからだし
主要スクリプト言語もどんどん静的型の機能を取り入れているし
2000年代にはオブジェクト指向をやりたいならRubyをやれって言ってたのに
今Rubyはどうなった?静的型の機能はいつ追加されるの?Ruby3.0はいつ?
超ド近眼
ほんのちょっとの目先の手間を惜しんで
より面倒なハメにあう動的型信者らしいっちゃらしいがな
昔に動的型がブームになっていた頃から
糞だってはっきり言っていた人たちもたくさんいたし
単にお前らがド近眼ってこと どうでも良いことばかりに着目しているド近眼ってこと 何も分かってないなぁ。
このスレの奴らは静的型アンチでもないし、動的型信者でもない。
昔ながらの静的型と動的型のデメリットとメリットを比較した時、
動的型が肌に合ってた奴は多いが前提が変わるんなら勿論話は変わってくる。
そもそもスクリプト言語の奴らは良いものは何でも大歓迎で取り入れるのが好きだから、
言語に型表記機能が入れば喜んで使う。
動的型に慣れているからこそ、エンジンに型を理解してもらう大切さが良く分かってるからだ。
そこは全く矛盾したり対立したりすることではない。
それとJSが糞と言われていたのは、クラスベースでなく馴染みにくいとことと、便利ライブラリの欠如だ。
でも、ぶっちゃけ欠点のない言語は無いのに、JSがそこまで言われてた理由は、
実はJSの仕様の問題ではなく、DOM APIの仕様とブラウザの実装が酷かったからだ。
そこはむしろ糞って言われていたからこそ、様々な改善が試みられて、今これほどまでに良くなったんだよ。
けしてJSの周りの環境が本当は糞じゃなかったわけではない。
もう一度言うが糞だったから良くなれたんだ。そこは勘違いするな。 assertは書きたいことを大体書けるが、型表記機能とやらは書けないことの方が多い
型名はただの名詞だから
コミュ力が低下する薬を飲まされて名詞しか話せなくなったような面倒臭さがある それは当たり前だろうよ、縛りを設ける代わりに、主にIDEから恩恵を受けようというものだからね。
機械を自在に動かしたいというスクリプター的には、機械のために書いてるようで合わないだろうよ。 Pythonは素晴らしいけどPythonが素晴らしいのではなく、
Python周りのネイティブライブラリ環境が大変素晴らしい。
道具としては最高だけど、プログラミング言語大好き人間としては不満。
もっと速度を上げ柔軟になってくれたら嬉しいんだけど、もうそっち方面は目指してないみたいだね。 必要以上に手をかけると処理系のメンテが困難になり結果的に進化の足を引っ張ることになる
Rubyなんかまさにそうで、オタク共がよってたかって好き勝手にいじくり回したせいで詰んでる でもPythonみたいにCythonで割り切るのもねぇと思う。
割り切ってもJSとどっこいどっこいの速度しか出んが。 るびいは作者の頭とユーザーの頭と言語仕様が詰んでるって先生が言ってた 結果論だがPerlを批判するだけで勝てたんだよな
Pythonは本当にそれだけで勝った
Rubyは批判したいのか擁護したいのかはっきりしなかった 2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
http://tamae.2ch.net/test/read.cgi/prog/1485008061/ http://gihyo.jp/news/report/01/rubykaigi2014/0002?page=2
古い記事だけどやっぱ面白いね
何が嫌なのか知らないけど、静的型から逃げ回って
無駄に複雑なことになっていく感覚、本当にすごいわ
型さえ書けば済むことを、よくもここまで複雑にね〜
Unixの思想に反するわ
で、最新の情報ではRuby3.0はどうなることになっているの?
静的型は導入されるの?
でもま、今更導入するぐらいなら初めから導入しておけばよかったのにね
当時から静的型はあったでしょ、C言語とか静的型だし
そんでRubyはCで書かれてて自分は静的型の恩恵を受けてRubyを開発したはずなのにね
十分知ってたはずなのに、今更導入とか、それって筋悪いんじゃないの?何周遅れww
それを認めたくないから静的型の導入に対して渋々なんだろうけど
そんな詰まらないプライドで言語使用が決定されたらRuby使いはたまったもんじゃないね
でもそんな事(タイプセーフの重要性)は周りから見れば分かりきっていたことで
だから俺はRubyには近づかなかったわけでさ
微妙に消極的に静的型のメリットを語ってて、何をいまさらって感じなんだけど
本当に複雑怪奇だね >>462
スクリプト言語のほとんどは静的型じゃないけど、このスレ全体にケンカ売ってるのかな…?w スクリプト言語っていろんなものの橋渡し、
間に入り込む接着剤のような役目なんだから動的型で間違っていない
ただそれだけでしっかりしたものを作ろうとすると大変だねってだけ 俺が思うにRubyは夢を売る商売なんじゃないかと思う
ディズニーランドとか宝くじとか
あるいは漫画やアニメの専門学校と
同じようなモノなんだろう Rubyは意図的に静的型の機能を外したわけでしょ?
当時からC言語はあったし、RubyはC言語で開発されているんだから
知らなかったわけないんだよ
知ってて明確な意図をもって外したわけでしょ
それをいまさら導入とか意味不明だよね
だったら初めから導入していればよかったわけで
あとから導入するの大変でしょ
これが何か目新しい概念とかだったら時代背景とかと合わせて
あとから導入はわかるんだけど
静的型って大昔からあって、むしろスタンダードだったわけで
今更検討とか今もう2017年だよ?何やってんだよ
まったくの迷走だよ >>470
逆だが…動的型の方が面倒くさい
>>466 はただの荒らしだからまともに取り合うとロクなことないよ >>471
動的型信者が静的型をdisるときによく言う「静的型の方が型が決まってるから実装が楽だが〜」
みたいなのを真に受けてるのかな
自分で簡単な言語を実装してみたらわかるよ
問題は型が静的か動的かよりも静的コンパイルの実装コスト 静的コンパイルはコンパイル系と実行系で処理系が2重になるのが複雑
あらかじめ仕様をきっちり決めておかないと手戻りが多発するからスクリプターのノリで適当に作るのは困難 仮に動的型のほうが静的型のよりも
最適化を含めるとなると難しいんだったとしても
それはまったく無駄な努力だからな
あと、動的方言語を静的に解析してエラーを見つけるのは難しいんだけど
それも無駄な努力だからな
静的型にすれば済む話
問題を直接解決しようとせず、周りをウロウロして何とかしようとするのは無駄
最近の言語に静的型が多いのは、誰も無駄な意味のない努力をしたくないから
動的型は、何か、ズレてるんだろう
砂糖と塩を輸送するのにブレンドして輸送する感じ
もしかしたら輸送費は安くなるかもしれないが
後で分離する手間考えたら分けて輸送したほうが良い
動的型の型を静的に解析するのはまさにそれに等しい行為
手間が増えるだけ 静的型言語の実装の難易度を基準とすると
動的方言語は、とりあえず動けばよいってレベルなら超楽勝
しかし実用になるレベルにするのに
まじめに最適化を実装しようと思うと途端に難易度は跳ね上がり超絶難易度になる
間は無い
うま味がないってこと
誰も手を出さなくなったわけだ GoogleのV8エンジンとかは、技術的に本当に興味深く凄いなぁと思う反面
あんな苦労は絶対したくないし
言語仕様のほうをどうにかしたほうが手っ取り早いのは確実
本当に動的型言語は何するにしても無駄に壮大で大変だなぁ
静的型言語が全ての答えなのにね V8はC++で書かれているけど、
Chrome含むGoogleのC++はマクロで魔改造されてる。
C++のマクロだけじゃなく、Pythonも使ってソースコード置き換えをしてる。
結局「全ての答え」などというものはない 全ての答えおじさんは自分で言語作ったりするの?
ただのユーザだったらうけるんだが 動的言語を速くする努力なんて無駄だっていうけど
Javaが速くなったのはV8と同じ技術の流用だろ? むしろJavaが先駆者というかJIT技術の長年の代表者かな
でもJavaとV8は実際やってることは全くと行っていいほど違う
何故かと言うとJavaは結局コンパイルしてバイトコードにした時点で実際の最適化の殆どは済んでいる、実際はJITはオマケのコンパイル言語だ
そこから少しだけプロファイルを取ったり、各環境向けに最適化するが、微々たるもの
そもそもバイトコードにした時点で情報が結構失われるからそこからJITするのに限界がある構造
でも静的なのでそんなチャレンジングなことをしなくても大体のケースで十分に最適化できるので
バイトコードサイズを小さくする方を取ってるが、実際幾つかのケースでV8含む完全ソースが手元にあるJITに負ける
一方V8は実行時というか実行前から実行中までずっと最適化し続けるJITをやや超えるもの Javaなんかコンパイラがどんなに良質なバイトコードを吐いたところでJITを切ったら使いものにならないよ JITコンパイル≠HotSpot技術≒V8の技術=anamorphic Animorphic Smalltalk VMやね >>486
2倍は全くクリティカルではない
JSだとJITは数十から数百倍のスケールで恩恵がある >>488
それベンチマークに特化したコードでの話じゃね?
それならJavaでも似たような差がでるよ >>489
良いことなのかも知れないけれど、昔のインタプリタの頃のとてつもない低速度忘れちゃったんだな >>490
Java VMは今も昔と変わらずバイトコードインタプリタだよ? http://gihyo.jp/news/report/01/rubykaigi2016/0001
まったく往生際が悪いというかなんというか、何の意味があるの?
一方ロシアは鉛筆を使ったって感じ
「負けたんだよ」ってだれか言ってあげて 大体型を書くのが面倒ってのも良くわからないし、型推論とかもあるのにな
あと型が書いてあったほうが読みやすい場面も多々あるし
機械にもわかりやすくて人間にもわかりやすくて、丁度よいじゃないか
あとほか宣言があると・・・宣言は型だけじゃなくスコープの宣言でもあるわけでして
宣言なし言語はスコープが気持ち悪いことになってるのが多いよなw
それからダックタイピングは本当に必要なのかどうなのか
静的型であってもジェネリックやテンプレートやオーバーロードがあれば
静的なダックタイピングは可能なわけで、しかもタイプセーフだし
動的なダックタイピングなどという危険極まりないものが本当に必要なのか?
ダックタイピングは静的に解決できる範囲で楽しめばよいだろうよ
それですら黒魔術とか言われるのにな
あと、WebAssemblyな、結局C++などの静的型言語を中間言語にしたものを
ブラウザで読み込んで機械語に変換して実行しようよっていう
どこまで行っても結局型が判明しているほうが最適化しやすいよね
CPUの進化が鈍化してきているし、物理的限界が近いことも考えれば当然の流れだな WASMでDOM操作とか夢のまた夢だし、
そもそもJavaでのDOM操作も実情はきつかったし
別にWebで無くてもいいような1つのアプリケーションを作るんなら
型は有用だけど、何かと何かをくっつけたり、加工したりするための
スクリプト言語としては全くの不要だよ >>496
> それからダックタイピングは本当に必要なのかどうなのか
> 静的型であってもジェネリックやテンプレートやオーバーロードがあれば
> 静的なダックタイピングは可能なわけで、しかもタイプセーフだし
ダックタイピングのこと分かってないだろ ダックタイピングはそれをプログラマが活用するのではなく
動的言語における多態性の(安易な)実装手法にすぎない >>495のURL先は皆読んでくれたかわからんが
掛け違えたボタン感が本当にすごくて
最初の一歩を間違えるとこんなにも面倒なんことになるのかって感じ
北朝鮮はどこまで進化しても北朝鮮ってことなんだろうよ
うすら寒い理想の未来を語るところもよく似ている
過去に生きて、未来を語って、現在に生きてないって感じ
まさに掛け違えたボタンで、「現実」のボタンをスキップして飛ばしている
胡散臭い宗教とかもそんな感じだよね
たぶん「現実」に不満がある人を集めるのが目的だから
過去の技術を使って、未来を語ってみせて、騙くらかすって事なんだろうな
これがまさしく、走り続けないと終わる、の意味だろう
でももう流石に誰も騙されないよね
麻疹みたいなものだから、学生さんは一度はそういう目に合うかもだが もしくは、ボタンを掛け違えていることに本人だけが気付いていなくて
誰も追いついてこないな〜なんて思っていたら
実はみんなもっと遠いところで高度なことをやっていた、ってパターンか
誰も追いついてこないんじゃなくて、フォロワーが居ないってことなんだけどね ダックタイピングというのは、(人間が)ガーガーと
アヒルのモノマネをすれば、アヒルとみなして扱おう
という発想から生まれたもの >>501
ダックタイピングのことを何も分かってない人間がいくら言おうと説得力はゼロだよ 残念ながら>>499が正解なんだな〜
俺も、もし何かの都合で自分で言語を作る必要性に駆られたら
そうするだろうね、実装が圧倒的に楽だから
つまり、自分で言語を作って、自分で使うんなら
現代においてもなお、動的型はありうるんだよ、これが
言語を作る手間と時間もコストとして換算して
トータルで労力を最小にしたいから
どこでバランスするかの問題
もしくは自分はもっぱら言語を作るのがメインで、使うのは他のやつって場合も
自分だけが楽できれば良いという身勝手な発想に行き着いたのなら、ありえる
自分は静的型言語でその恩恵を十分に得ながら言語開発して
他人は自分の作った言語で苦しむっていう
人として最悪な感じにはなるけど、まぁ最終的には良心の問題
金もうけのためだったり仕事って事なら仕方ないけど
人生の目標にしたら只の嫌がらせだな
それはそれとして、既存の言語を使うだけなら
わざわざ手抜きな言語をあえて選択する意味はないよ >>505
ダックタイピングをジェネリクスで代替できると思ってる人間の論理に説得力はない ダックタイピングはジェネリクスではなく
インターフェースで代替するもの >>507
その通りだね
そしてインタフェースをいちいち付けてまわるのは非常に面倒臭いこと
自分で作るクラスならまだ何とかなるが、使ってるライブラリのクラスだとそうもいかない > そしてインタフェースをいちいち付けてまわるのは非常に面倒臭いこと
めんどくさい? ダックタイピングではインターフェースがないから
代わりにコメントで同じ情報を書かないといけないじゃん。
インターフェースの情報(コメント含む)を書かないで
それが仕様かどうか分かってもらえると思ってんの? >>509
コメントなら書くか書かないかは開発者が選べる
それを「低レベルコード生産要素」と見るか「プログラマの自由を保証」と見るかは
ポジションによる
Matzなんかは後者の立場なんだろうし、日本のSIのような人月計算でレベルはおかまいなしのような
プロジェクトに関わってるような人から見れば前者になるんだろうね 「静的な」ダックタイピングはジェネリックとオーバーロードで実現可能
という風に書いたのにこれが理解できないのではどうしようもない
きっと静的と動的の違いも理解できてないんだろう
静的なダックタイピングはタイプセーフだし
本当にうまい落としどころだなぁって思う
何もかもが静的型に都合がよいように回ってて、ちょっと怖いね
とはいっても俺も何でもかんでも型で解決しようってのはあまり好きじゃなくて
一つのアイデアが上手くいくと一気に乗っかっていく感じは何か過剰というか
ただ、そうはいってもダメなものがダメなことには変わりないんだけどね >>510
> コメントなら書くか書かないかは開発者が選べる
言い換えると、
コメント書きたくない、仕様書を書きたくない。
コード読まないとわからない。
というコードを書きたいってことか?
ひどいな。だから可読性が下がるんだよ。 >>511
ぜんぜん違う
ほんとダックタイピング分かってないんだな
ID:cCOM2/u0 なんかはその辺分かってるから議論になるけど、お前にゃ無理だよ >>512
Matz の有名な言葉に「ソースがドキュメントだ.バグも完全に記述されている」ってのがあるからねぇ
冗談半分だとしても、思想としてそういう方向なんだろう
本気半分の言い分としては、ソース読んだだけでちんぷんかんぷんなコードはその時点で怪しいと思え
って感じだろうか インターフェースは契約プログラミングの一種でもあるんだよ。
インターフェースを定義することは事前条件を定義することにあたる。
事前条件を記述することで、予め(プログラムを実行しなくても)バグがあることがわかる。
実行パスは無限と言ってもいいほどあるから、実行しなければ
わからない問題を検出するのは時間がかかる。
だけど、条件を満たすかどうかを調べるために、
実行そのものが必要なければ、短時間で問題が検出できる。
コンピュータが理解できる方法で、しかも実行せずにわかることと
コメントという人間しか読めない方法で書くのとでは全然意味が違う 静的型において動的な多態にインターフェースを使うのは当たり前
動的なことは危険な香りがするから、インターフェースで制約する
これも丁度よいぐらいの落としどころなんだよ
静的な多態はジェネリックとオーバーロードでダックタイピングも可
動的な多態はインターフェースを通して安全に
どちらの場合もタイプセーフ
よくできているよね〜 >>515
そういう方向でバグを減らすというのもひとつの方向性としてはいいんじゃない?
単なる思想の違いというだけで、そういうのが嫌いな人が作った言語だって別に悪いわけじゃない >>516
だからお前はダックタイピング分かってないんだからもういいよ
staticおじさんのように、分かってない機能は全部けなす方向性の人間と議論になんかならんからな
まずお前にすすめるのはリーベルGの「高慢と偏見」を読めってことだ >>517
> そういう方向でバグを減らすというのも
そういう方向で"も" な
バグを減らすテクニックはいくつもある。
静的言語なら、そのテクニックが増えるわけだ
動的言語でできるバグを減らすテクニックは、静的言語でも使える。
さらにプラスして、静的言語ではコンパイル時に実行することなく
バグを減らすことが可能になる。
これは明らかにバグを減らすために追加された機能といえるだろう >>519
そのために生産性やプログラマの自由が減るというトレードオフがあるけどね
そのトレードオフのどっちを取るかはポジションで決めればいいだけの話 ちなみにダックタイピングは、ダックのように振舞うものは、ダックとして扱える
って言ってるだけで
静的に解決するか、動的に解決するかは、別の問題であり
当然静的なダックタイピングは、ある
>ダック・タイピング
>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を書き直すか? >>521
俺はテンプレートに関しては何も言ってないが?
ジェネリクスはちゃうやろって言ってるんだが >>520
> そのために生産性やプログラマの自由が減るというトレードオフがあるけどね
減ってないよ。逆に高くなっている。
っていうか、あんた書くときのことしか考えてないでしょ?w
プログラミングっていうのは書くよりも読むことのほうが遥かに多い。
だから、可 "読" 性 が重視される。
読みやすいコードは生産性を大きく上げる >>521
× C++のtemplateはダック・タイピングの静的版である
○ C++における型消去はダック・タイピングの静的版である
明らかに間違ってるから直しとけよ >>523
それは違うな
コメントなら引数を「与えられる方」だけ書けばいいが、インタフェースは引数を「与える方」にもそれを強制する
そしてこれは結構面倒な作業だ
もちろん、引数として変なものを与えてしまう可能性も出てしまうが、それと上記の面倒さをどっちを取るかは
それぞれの人が決めればいい 現代に生き残りし貴重なサンプルだとは思うが
「何が面倒か」までは書かないんだよな
結局、何でもかんでも渡すわけにはいかないのは同じこと
どのみち仕様を満たさなきゃならん
ダックならダックの仕様を満たさなきゃならん
ダックの仕様を満たすように書かなきゃならないのと
ダックのインターフェースを満たすように書かなきゃならないことは
実質問題大差ない
大差ないか、むしろインターフェスがあった方が何をすべきかよくわかるぐらいだ
仮にこのケースでほんの少しだけ動的型が便利だったと仮定しても
静的型の、型安全性、リファクタリングのしやすさ、タイポなどの些細なミスの検出
型が書いてあることによるドキュメンテーション、最適化のききやすさ
あと宣言があることによるスコープの細かさ
これらすべてを投げ捨てるほどの差はない
動的型のメリットといえばもはや動的なメタプログラミング的な何かぐらいしかないが
そんな黒魔術はどうでもよいし、はっきり言ってgoto文と変わらない こういうと彼はきっとこう思う
静的型は互いに別々の出どころのライブラリ間で
インターフェースに互換性がないから困る、と
しかし、そんなことは動的型でも同じこと >>525
クラスだけ与えられて、
さてこのクラスはどこで使えるでしょう?
みたいなクイズして楽しいか?
このクラスが持っているインターフェースは何かって
ちゃんと書いていれば、そのインターフェースを使える場所も
明確にわかるだろ >>526
> 「何が面倒か」までは書かないんだよな
それだよなw
ほんと何が面倒なのか。 >>528
アプリケーションの全クラスが自分の管理下にあればそれも可能かもしれんな
でも実際は様々なライブラリを使うことは避けられないし、各ライブラリのクラスに後から自分が欲しい
インタフェースを追加することはできないことがほとんど
C#やScalaなんかはそういうこともできるみたいだが、今度は可読性が落ちるのでここぞというときの
秘密兵器扱いだな >>530
各ライブラリのクラスに後から自分が欲しいインターフェースを追加して、
正しく動く保証はあるのですか?
そもそもそんなことする必要ありませんよね? 手段が目的になってしまってるんだよなw
何がしたいのかは言わない。
ライブラリのクラスに後からインターフェースを追加することが
目的なんだって臆面もなく言ってしまうw >>531
あるよ
たとえばあるライブラリがAというクラスのオブジェクトを返したとする
これを別のライブラリか自分で作ったクラスのの引数として使いたいけど、その引数はBという
インタフェースを要求する
Aというクラスは字面の上ではBというインタフェースを満たしているのだが、Bというインタフェースを
implement しているわけではない
さてどうしよう
Bというインタフェースを持つクラスを自分で定義してコピーする?こんな余計なことしなきゃいけない
のは生産性の低下以外の何物でもないわな
これは一例であって他にも同様の例はいくらでもある >>533
なんでAというクラスが、Aとは全く関係のなく作られたBというインターフェースを
たまたま運良く満たすなんて自体が起きるんだよw
ありえないだろ。
それよりか引数が違うのに、同じ名前のメソッドを定義してしまっていた
どうしようって思うほうが可能性高いわw Aというクラスは字面の上ではBというインタフェースを満たしているのだが、
Bのバージョンアップでインタフェースが変わってしまった。
だけど、Aというクラスがたまたま古いBのインターフェースと
一致していたという前提をどこにも書いていなかったので、
動かなくなる原因の判明に時間がかかった。
そのためにコメントをしっかり書くようにした。
A は B interface を implements しているよと >>534
ありえるんだよ、これが
しかもしょっちゅう
(俺は静的型言語でも開発してるからよく出くわすよ)
たとえば、Serializable なんか典型じゃないかな
そのまま Serialize したいのになんで Serializable インタフェース持ってねぇんだよ!
みたいなのはほんといくらでもあるよ このようにダックタイピングを使うとその場しのぎで直ぐに対応できるように思えるけど
長い目で見れば、可読性の低下を招き、メンテナンス性、生産性を下げることになってしまう。
書いたら終わり、メンテナンスが不要な書捨てのプログラムぐらいにしか
使わない方がいい。
そして、書捨てのプログラムをよく書くのはインフラ系が多い。
インフラ系で必要とされるのはオブジェクト指向も必要ない
数行程度のスクリプト。シェルスクリプトよりは書きやすいぐらいの
理由しか持ち合わせてない
アプリの開発には長期間メンテナンスされるので可読性が重要 >>536
> そのまま Serialize したいのになんで Serializable インタフェース持ってねぇんだよ!
そのクラスがSerializeする機能を実装してないからだろ? http://rubytips86.hatenablog.com/entry/2014/03/19/184940
Rubyでこのシリアライズとデシリアライズを担うライブラリがMarshalモジュールだ。
注意点としてMarshal.dumpでは、無名のクラス・モジュールのオブジェクト、
システムがオブジェクトの状態を保持するIOなど、
Procなどいくつかのインスタンス、特異メソッドを定義したオブジェクトはシリアライズできない。 第一だよ
全然関係ないライブラリ同士でたまたま字面の上で
メソッド名が一致しているクラスがあるっていう
偶然の一致があったとしても
その動作振る舞いまでもが完全に一致していて
動作的にコンパチブルかどうかは分からないよ
想定してないんだからさ
おおよそ慣例というか習慣というか、その言語ではふつうそうするって
何らかの決まり事みたいなものがあるのなら問題ないかもしれないが
そういう場合は言語側やファウンダメンタリーなライブラリが
インターフェースを定義してくれているから、それ使えばよいわけで
やっぱり関係ないんだよ
そういうメソッド名と振る舞いの両方が偶然にも一致
っていう奇跡偶然に頼るってのが
まさにおまえ自身が>>530で言ってる
>アプリケーションの全クラスが自分の管理下にあればそれも可能かもしれんな
そのものなんだよ、まったくのブーメラン >>540
ダックタイピングのことを知らないお前が言っても説得力はないよ 要するに、後付で色々したい場合はダックタイピングの方が楽なんだよ。
ただし、全てを見通せるのなら最初からインタフェースにしておいた方が美しいのも事実。
現実的にはJavaScriptはUI用で酷く書き換えを強いられる為、
ダックタイピングの方が向いている。(と俺は感じている)
逆に、仕様がかっちり決まっている場合は型ありでも特に苦労しないし、
数値計算等のバグ出ししにくい状況では型があった方が安心ではある。
(期待値が作りにくい、見た目でバグと分からない)
ただ、UIならバグは見て分かるし、ダックタイピングでも問題ない。
動的言語はパターンを当てないとバグ検出出来ないけど、
UIなら「変更が依頼された」=「パターン持ってる」ってことだし。 真面目にダックタイピングをやろうとする行為は、型やインタフェースを定義するのと違いがない
だからrubyでダックタイピングを考えてプログラミングしてる人なんているわけない >>544
あの、精神論でごまかさないでください?
何一つ、ダックタイピングのほうが良いという理由を
言っていませんよ >>546
良い悪いを議論する事じゃないよ。
結局は、どう思うか、どう感じるか、でしかないから。
型には型の得失があるし、ダックタイピングにしてもそう。
選べる状況なら好きな方選べばいいし、無理ならグダグダ言っても意味無いだろ。
利点を感じないのなら、これまでそういう状況に遭遇したことがないか、
或いはそもそもそっち派ではないか。
いずれにしても使わないってことで問題はない。
利点説明おねだり君なんてウザイだけだから止めろ。
http://yohshiy.blog.fc2.com/blog-entry-244.html
未確認飛行の人も同じようなことを言っていたと思ったけど見つからなかったから上記で。
結論出したいのならこの辺だと思うよ。
>>545
ガチでダックタイピングの利点を享受しようとすると、
型に留まらず世界が統一されていないといけないので、実は型よりも難しい。
そしてJavaScriptもそれに対応出来ていない。理由は標準化している奴らが馬鹿だから。
sizeとlengthが混在してるでしょ。
あれ、どっちでもいいけどどっちかに統一されてないといけない。
だから真面目にダックタイピングをやっている奴なんていない、というのは俺も思う。 > そしてインタフェースをいちいち付けてまわるのは非常に面倒臭いこと
めんどくさい? ダックタイピングではインターフェースがないから
代わりにコメントで同じ情報を書かないといけないじゃん。
インターフェースの情報(コメント含む)を書かないで
それが仕様かどうか分かってもらえると思ってんの? >>540
同じインターフェースを実装してても、それは引数と戻り値の型が一致するだけで
動作振る舞いがコンパチブルかどうかは保証してくれないけどな
JavaやC#みたいなショボい言語では >>549
interfaceは"インターフェースを"保証してくれるもので
インターフェース以外は別の話なのは当たり前だと思うが?
「お前型を保証してくれるんだろ?
バグがないことまで保証してくれよ」
っていうのと同じぐらい無茶なこと
普通保証の対象しか、保証しませんってw >>549
ショボくない言語ではどういう感じになるのでしょうか?
純粋な興味として知りたいです しょぼくない言語なら、
動作振る舞いがコンパチブルかどうかを保証してくれるんだろう? >>544
> 要するに、後付で色々したい場合はダックタイピングの方が楽なんだよ。
メソッドや関数のオーバーロードが可能なら静的型でも変わらなくない? >>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みたいな、とりあえずサクサク実装出来る言語の方が向いている。 >>554
シリアライズのことしか考えてなくて、しかもシリアライズメソッドさえあれば
何でもかんでも簡単にシリアライズできるんだって思ってるみたいだけど、
まず前提として、いかなる言語も汎用的なシリアライズはなという話をしようか?
これが大前提なので、あとからシリアライズメソッドつければ、
シリアライズできて便利ーにはならないんだよ。
通常シリアライズメソッドは後から追加できないものと考えるべき。
例外的に可能なものもあるけど、あとからシリアライズメソッドを追加できるならば、
obj.serialize() ではなく、Serializer.serialize(obj) とやることで目的は達成できる。
あんたがやろうとしているのは、単にシリアライズ処理を
インスタンスメソッドにしたいと言っているだけ。 >>554 C++のテンプレートは空回り感が酷い。 とりあえず実装してから確認したいってのはある。
激しく同意する。
An one-liner で書けるようなものでは、型の恩恵などない。Local,global の峻別さえ無意味だ。そのようなときは duck typing で書かねば損だ。
逆に duck typing で一万行を超えてくると、強烈に型が欲しくなる。 >>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)] >>550
そんなショボいものしか保証してくれないの?
まったく安心して使えないね
動的型付けと大差ないじゃん 動作を保証しないから問題だって言った(>>540)直後に
動作を保証しなくて何が悪いと返せる(>>550)って凄いねw
そのチンパンジー並みの記憶力は賞賛に値するよ >>558
俺はPythonは知らないのでJavaScriptとの比較は出来ない。
ただPythonはクロージャに難ありなので今後も使う気はない。
改行が強制されるのも気に入らない。
JavaScriptは書いてて気持ちがいいんだよ。
理由は簡単で、全て具だから。
型等の動作には関係ない物がないから、動作に集中出来る。
なるほどMatzが目指したのはこれだったのか、というのは分かった。
だから俺が次にやるとしたらRubyだね。
今のところ、俺は型自体はは要らないという結論だ。
名前通りの型しか付けないので、見りゃ分かる。
ただ、現実として、実行前にタイプミスを見つけてくれないから困っている。
ダックタイプや動的に使う場所なんて限られているのだから、
そういう場所に対してワーニング出してくれるだけでいいんだが。
そのためのリントを探してはみたものの、
JavaScriptのリンターはそんな方向では全くなかった。
あと、C++が糞なのはクラスは全て独立で親クラスを掴めないことだ。
だから細かくクラスを階層化出来ない。というか、やると余計に手間が増える。
ここら辺はJavaでは改善されていて、明示的に掴めるし、
JavaScriptではデフォで掴んでる。(レキシカルスコープ)
粗結合を目指すのならJava方式がいいし、
お気楽を目指すのならJavaScriptの方がいい。
ところで初心者はそういう「短く書ける方がイイ」みたいなことをよく言うが、
君が本当に一万行のコードを書ける奴なら、それは意味無いと分かるだろ。
そしてそれをここで聞くのも意味無い。
だって俺の腕前なんて未知数だし、ここでは無駄に吠える初心者も多いし。
一般論としては、Pythonはキャズムを越えているっぽいから、
学んでも無駄にはならないと思うよ。 ああすまん、質問はPythonではなくて、JavaScriptを学ぶべきか?だったか。
俺が勘違いしてた。
これは俺は正確には答えられないね。
俺は他言語使えるわけではないし。
そもそも道具なんだから、今困ってなければ学ぶ必要はないだろ。
新しいプログラミングを学びたいというのなら、
結局どの言語も似たり寄ったりの方向に進化しつつあるし、
とりあえず「進化している言語」を一つ追跡しておけば問題はないだろ。
一番速いのは多分Rubyだろうし、この点ではPythonは遅いほうだよ。
同様に、この点でJavaScriptを選択する意味はない。
逆に、今使うというのなら、グダグダ言う意味もないだろ。
Web環境ではJavaScript以外の選択肢はないんだし。 >>560
> 動作を保証しないから問題だって言った(>>540)直後に
> 動作を保証しなくて何が悪いと返せる(>>550)って凄いねw
なんの動作?
ねぇねぇ、なんの動作?
わざとぼやかしてるでしょwww あとそれから>>540は俺じゃないからねw
IDすら見えない?
チンパンジーになみの理解力だった?w >>561
> JavaScriptのリンターはそんな方向では全くなかった。
TypeScriptがお前が望むものだよ
型を導入したJavaScriptだ。
いまあちこちで普及してる。 >>561
> ところで初心者はそういう「短く書ける方がイイ」みたいなことをよく言うが、
> 君が本当に一万行のコードを書ける奴なら、それは意味無いと分かるだろ。
え? なんで?
同じ一万行なら、短く書ける方がより多くの機能を実装できるから
やっぱり短いほうが良いじゃんw >>566
つまり型は余計だということだね
インタフェースとか余計なことを書かなきゃいけないから >>567
それはインターフェースが余計なものであるという前提で成り立つものだ
インターフェースは余計なものではなくプログラマの意図を
コードというコンピュータにも理解できる言語で記述した価値がある情報だ >>568
短く書ける方がいいんでしょ?
ダブスタいくないよ >>569
正確に言うと「少ないステップ数」というべきだな。
インターフェースは実行されないのでステップには含まれない。
他にも型宣言とかimportとかコメントとか空行とか
{ だけの行とか、そういうのもステップには含まれない。 >>570
> インターフェースは実行されないのでステップには含まれない。
こんなオレオレ定義聞いたことありませんw >>571
デバッガの「ステップ実行」って
使ったことないの?
インターフェースの前後でステップ実行することはない >>572
ググってみたけどステップ数からインタフェースを抜くなんて計算方法はまったく出てこない
オレオレじゃないなら、どこか有名なサイトに計算方法が載ってるはずだからさ、ポインタでいいから
示してください >>573
ステップ数は単に英語の意味の通り、ステップ(一歩)という意味しかないよ。
ステップイン、ステップアウト、ステップ実行できる単位と考えればいい。
ステップできないのに、ステップ数に数えるとか意味不明だろう
ソースコードの行数はLOCという。 >>574
たとえばさ、↓のページにあるように、ステップ数というと一般的にはプログラム規模を測るための
指標なんだよね
http://e-words.jp/w/%E3%82%B9%E3%83%86%E3%83%83%E3%83%97%E6%95%B0.html
LOCからコメントや空行を抜いたり、中括弧だけの行を抜いたりと言語によって流儀はあるみたいだけど、
お前の言う流儀がどこにも載ってないんだよ
どこに載ってるか教えてくれないか? >>575
だからステップ数は誰も正確な定義をしてないのだから
どんなものでも間違いではない。 >>576
とはいえ、「インタフェースはステップ数に含まない」と断言するからには、それなりに普及してる
流儀なんでしょ?
その流儀がどこに書いてるか知りたいんだが 動的型付言語の苦手な奴が多過ぎ
ダックタイピングでいいじゃん
スタティックおじさん馬鹿にしていながら、自分もスタティックおじさんみたいになってる ここでダックタイプ嫌ってる奴って、ダックタイプを静的言語でやるとしたらジェネリクスとか言い出す奴だもんな
「自分の分からない技術は使えない技術だ」なんて完全にスタティックおじさんだよな 静的型の言語の補完の快適さは動的型言語には得られないものなんだよなぁ
インターフェイスとかをいちいち記述する手間を含めてもその最適さのほうが上回る感はある >>581
という感想を持つ人は静的言語を使えばいいし、インタフェースとかをいちいち記述するのが面倒くさい人は
動的言語を使えばいいよね
ただそれだけの話 自分だけで完結してる話ならそれでいいんだけど仕事だとそれじゃ駄目なんだよね
以前rubyのプロジェクトで酷い目にあったのでもう動的型付け言語は嫌だわ インターフェースがある言語を使ってる人のほうが、よっぽどダックタイピング的思考をしてるだろう
rubyなんて脳内で型付けしてて、ダックタイピングのことなんて考えてない
教祖だけが狂ってる >>562 意見ありがとう。552です。
>Web環境ではJavaScript以外の選択肢はないんだし。
同意します。Google が TypeScript を標準言語にしているのも、その意味なんでしょう。
俺としては型推論の働く、濃密なコード記述可能で、良質のライブラリが揃っている言語が欲しい。
Haskell が型推論で一番強力だと思うが、キャズムを超えられないと思う。Python のよ
うな、全世界の知性による良質なライブラリの膨大な蓄積は期待できない。 >> 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 ## 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 以上の計算ができれば、RSA 暗号を実装できる程度に理解したと言えます。
ここでの one-liners は、プログラムというより、コンピュータ計算可能な数式です。
これ以上に単純化できない程に濃密です。しかも独立しています。それ以前の文脈に影
響されません。試行錯誤のごみの山から御宝式だけを copy and paste で取り出せま
す。
これらの one-liners は短いけれど、可読性も備えています。
Python は、これだけの濃密なコード記述を可能にする良質なライブラリ群を備えています。
これらのコードを書くのに、一々 big num class を持ち出したりしてられません。RSA
暗号数学だけで、手一杯なのですから。
これらの one-liners で、int 型宣言する意味もないでしょう。 >>562 一番速いのは多分Rubyだろうし、この点ではPythonは遅いほうだよ。
老婆心ながら言っておきます。こんな理由で Ruby に学習コストを書けるのは止めるへき。
スピードが欲しいならば C 言語で実装して繋げばよい。SciPy は、実装にそうして実装
され、data science 分野で使われ、ライブラリが蓄積され続けている。
Ruby が書き安い言語なことには同意する。しかし勝手な互換性の放棄により、良質なラ
イブラリの作者たちを離反させすぎた。Python community とは差が付きすぎた。
Python は Ruby と比較して読みやすい。俺にとって読んで楽しめるコードは Python だ
けだ。C 言語はマクロの解析が必要になるなど、コードを読むことは苦痛のほうが勝
る。Ruby は C言語よりは読みやすいが、楽しめるほどではない。
今更 Ruby に向かうのは無謀すぎる。 どうせエンジンのお粗末なRubyのことだから
型が付いてもそのまま実行するよりWASM経由でした方が早いとなるだろうな。 >>589
思いっきり文章の読み方を間違ってるよ
>>562 でいうスピードは変化のスピードだよ
君がPython好きなのは分かるが、他の言語をけなそうとする余り文章を読み違えるのは
いただけないな >>591
「このプログラミング言語は速い」って文脈で「進化の速度」のことを言っている奴は初めて見たな
普通は実行速度だよな? プログラミング基礎でO記法とか学ぶもの >>593
>>562 で直前で
> とりあえず「進化している言語」を一つ追跡しておけば問題はないだろ。
と書かれているので、ここでの速いは進化の速度だよ
そうでないとJavaScriptを除外している部分と整合性が取れない
(JavaScriptは実行速度はかなり速いしね) >>560
亀レスで申し訳ないが、それはお前の認識が誤っているからだ
あるライブラリAの、とあるクラスが、別のライブラリBて定義されている
インターフェースを実装していた場合
ライブラリAはライブラリBでも使われることを前提としている
というかライブラリBの上にライブラリAを築いている
あたりまえだろ?だから当然想定されている
で、ダックタイピングの場合は
メソッド名が一致しているからひょっとして使えるんじゃね?
ってレベルだろ
そんなの偶然の一致かもしれないし、使えるかどうかわからん
元の開発者はそんなこと想定してないかもしれない
微妙に動作が違うかもしれない >元の開発者はそんなこと想定してないかもしれない
と書いたが、逆に使われることを想定しているんなら
インターフェース方式でも問題ないんだよ
ライブラリBのインターフェースを実装すればよいだけだからな
使われることを想定しているんなら、これは当然できる状態にある
そして明確になる >>596
どういう主張だっけ?
作者が意図しない使い方はすべきでない、つまりダックタイピングは悪
ってこと? 言いえて妙な話で、あるクラスがあちこちで使われることを想定しているなら
クラスの開発者は、想定する全ての使われ方について、全てのンターフェースを
実装すればよい
逆に、実装されてないインターフェースに関しては
「想定してませんよ、考慮してませんよ、ノーサポート」って事なんだよ
その場合は、当たり前だが自分でラッパークラスを書けばよい
ちょっとしたデータ変換や仕様のすり合わせもそこですればよい
元のクラスが想定してないんだから、これは当然なんだよ
ダックタイピングは全てのクラスが自分の管理下にあって
仕様を完ぺきに把握しているのなら可能かもしれんが、という話 ラッパークラスと書いたが、アダプタクラスと言ったほうが正しいかもしれん そこそこ有名なライブラリAがあって、多数のライブラリC,D,E,...の中でそれを使っていたとする
それよりパフォーマンスが良くてメソッドに互換性があるライブラリBを作って
CDEを変更することなくAからBに置き換えてもらいたくなったとき
インターフェースのある言語だとライブラリAのインターフェースをBでも使わないと不可能じゃないの?
もしAがGPLならBもGPLにしなきゃダメってこと? インタフェースをきっちり設計するのは面倒だからな
これをそうじゃないという人間はある程度の規模のアプリケーションを組んだことがないんじゃないか
と言いたくなるぐらいにね >インターフェースのある言語だとライブラリAのインターフェースをBでも使わないと不可能じゃないの?
>
>もしAがGPLならBもGPLにしなきゃダメってこと?
それはインターフェース有り無し関係ない。FSFの主張だと、GPLなライブラリと組み合わせて使う前提のプログラムは、
全てGPLでなくてはならないことになってる。
実際、ダックタイピングな Python でも、 pyqt が GPL か商用ライセンスしかなくて敬遠されてたので、
pyside という LGPL なライブラリが作られた。 >>600
それは条件が公平ではない
動的言語がその差し替えを比較的容易に行えるのはソースコードを直に実行しており
依存関係がシンボリックだからにすぎない
CDEのソースが手元にあるなら、静的言語でもCDEをソースからリコンパイルすればいいだけの話
静的言語のリンクの仕方には色々あるが、同様にシンボリックなリンク方式を使っているなら
ソースが無くてもBにもAと全く同じインターフェースを定義すれば当然動く >>603
> CDEのソースが手元にあるなら、静的言語でもCDEをソースからリコンパイルすればいいだけの話
さすがにライブラリ使用者にそこまで求めることはできないよね… >>604
だからそれはインターフェースの有無ではなくコンパイルの有無の問題だよね
言ってる意味わかる? >>605
ライブラリは基本的にコンパイル済の状態で提供されるよね? >>606
だからインターフェースは関係ないと言ってるだけなんだけど
頭大丈夫? >>607
ライブラリCDEをソースからコンパイルという時点でおかしよね? >>608
そうだね
で、それがインターフェースとどう関係していると思うの?
一般論としては動的言語の方が比較的容易であることは>>603の冒頭で認めたうえで
それはインターフェースではなくコンパイル(の習慣)の有無の問題であるので
>>600の「インターフェースがあるから差し替えが難しい」は誤りだというのが俺の意見なんだけど
ここまで説明しないと理解できない? >>609
ライブラリはコンパイル済が配布されるのだから差し替えは難しいよね? >>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を今使うのならいいけど、将来性は無いと思うよ。 >>593,594
俺が言っていたのは「進化の速度」だよ。
というか、そんなに分かりにくい言い方だとも思わないけど。
ただ、本当に>>558が出来る言語が素晴らしいと思っているのなら、
まずは言語は何でも良いからガンガン書いてみて、
それをきっちり保守してみることだね。
そうすれば、そんな点は全く意味がないと分かるだろう。 >>611
気持ち良く長文書いてるとこ悪いけど、cythonって知ってる? >>606
> ライブラリは基本的にコンパイル済の状態で提供されるよね?
ソースコードが提供されているならば
ソースコードを修正してコンパイルすれば良い。
そのライブラリがコンパイル済みの状態で提供されているかどうかは関係ない >>610
> ライブラリはコンパイル済が配布されるのだから差し替えは難しいよね?
少なくともオープンソースであれば、ソースコードとコンパイル済みの
両方が配布されているから差し替えは難しくない。 >>610
多くのコンパイル型言語では故意に差し替え可能に設計しておかない限りインターフェイスの有無に関わらずライブラリのコンパイルが必要
たとえばC#でインターフェイスをつかわず、全部dynamicで呼び出してる場合でもDLL差し替えではだめ >>611
>>>589
>俺に言わせると、Pythonは学ぶ価値がないよ。
>
>新しいプログラミングパラダイムを試したいなら、Rubyだろ。
>「新しい事が至高」なコミュニティだから、今後もトップを走り続けるだろう。
>逆に言えば、互換性なんて気にしている言語では、どうやってもRubyには追いつけない。
釣り? 少なくともRubyは無いわ。昔はともかく、この2-3年は停滞しているように見える。
すまんが、最近Rubyに入った、新しいプログラミングパラダイムを教えてくれ。
# ちなみに貴方が腐している Python は、async/await とか、外部チェッカを利用した Gradual Typing とか Null safety とか入りました。 >>617
それのどこが新しいプログラミングパラダイスなの? >>618
お前の頭がパラダイスだよアホ
ていうか、ruby3にgradual typing入れるってmatzが去年言ってなかったか? >>611
ラムダ式に式しか書けないのは関数型言語好きがコミュニティに増えたからって気がする。
Pythonそのものも関数プログラミングをサポートしつつあって、同じ機能にオブジェクト指向版と関数プログラミング版と二つあるのがチラホラ。。。
そういう意味じゃすっごく気持ち悪い。
でも、使う側から見れば使えるライブラリ多いPython。
面白いかどうかじゃなくて、使えるかどうかね。
Rubyで使える数値計算やディープラーニングのライブラリ紹介してくれ。
宣伝してやるから。 >>611
少なくともNumPyが使われ続ける限りPythonを学ぶ価値はあるだろ
Pythonから学ぶことは反面教師的なこと以外はほとんどないけどさ
しかしRubyには使いどころはおろか、学びも皆無
自称言語オタク(失笑)が聞きかじった話題の他言語の顰みに倣ったり
その失敗を含む二番煎じを、ろくすっぽ論文も読まない取り巻きとひたすら繰り返しているだけ
Rubyを見て新しいとかいってる奴は元ネタを知らないだけのただの哀れな信者 アニメで小林さんがpython使ってたから本読んだ。仕事でciscoのopenpk使う事になった。小林さん、ありがとう。 >>614-615
mavenやsbtみたいなのを使うなってことですか?
これは驚いた… >>623
意味不明
お前は公開リポジトリに既存の有名ライブラリと同姓同名の俺ライブラリを登録するつもりか?
そんな迷惑行為は常識的には認められない >>624
ソースを入手してビルド、なんて依存性解決は面倒だしバージョンアップに追随するのも
面倒だしやってられないと思うんだが…
みんなやってられないと思ったからmavenやsbtみたいなのが作られたわけだし >>625
Java系なら同じパッケージ名で同じ名称のクラスやインターフェースを定義しておけば
バイナリをmavenやsbtを用いて差し替えることは可能だよ
そんな”迷惑行為”は大抵のエコシステムでは認められないし、
パッケージ名の勝手な使用によって法的な問題が発生する可能性すらある >>>617
>それのどこが新しいプログラミングパラダイスなの?
コルーチンが普通の関数っぽく書けるようになったり、動的型言語に部分的に静的型を導入したりNullチェックを強制できるのは新しくないと。
ま、Pythonが史上初めてではないが、他言語で評判が良い部分を取り込んだ感じだな。
じゃ、貴方が思う、最近Rubyに入った新しいプログラミングパラダイムを教えてよ。
Rubyは「トップを走り続ける」のだから、1つ2つは簡単に紹介できるでしょ。 ここ最近このスレは全く書き込みが無くて閑古鳥が鳴いていて
人いるの?って感じだったのに
俺の書き込みを発端として昔のように熱いバトルが始まって本当にうれしい
書き込んでよかったよ
もう絶滅したかと思ってたが、まだ一定数、動的型信者がいるようで
あぶり出し大成功ってところか
危険人物なので隔離スレにいつまでも隔離されててください
今の猫も杓子も静的型の時代に、まだ回心できてないってことは
これから先もずっと無理だろうし >>628
インターフェース信者君がフルボッコになってるのを熱いバトルってww このように、もはや違う時間軸に住んでいる人なんだよな
俺の住んでる時間軸では、新しくできた目ぼしい言語は
当たり前のように静的型の機能を持っていて
静的型の落とし込み方自体が言語の特徴というか
セールスポイントにもなってるんだが
そちらの時間軸ではどうなってるのかな?
タイプセーフは今時常識だよ
静的型の先進的機能を否定するのは過去に縛られたstaticおじさんと同じこと
また、言語に静的型の機能がないってことは
単純にその言語は手抜きってだけのこと
あと、言語としてもつまらない visual studioとc#の組み合わせが最強すぎる >>630
staticおじさんというのは「自分の知らない機能を使えない機能だと断言してけなす人」だから、ID:KuJQA9vc のことだよ >>630
まーた、タイプセーフの意味をわかってないやつかw
http://postd.cc/what-is-type-safety/
> C言語とC++:型安全ではない。
> Java、C#:(恐らく)型安全。
> Python、Ruby:(ほぼ間違いなく)型安全。
> タイプセーフは今時常識だよ
そのとおりだよ。PythonとかRubyを見よ。
タイプセーフになってるだろ タイプセーフと、実行時型エラー出るのとは別かもだが、実行時型エラーが問題。
客からそんな詰まらんエラーでクレームとか恥だわ。 staticおじさんは今はタイプセーフの話なんてしてんの? pythonは単純な手続き型プログラミングもできるしオブジェクト指向もそこそこできるし
関数型もそこそこできるすごいそこそこな言語なんだゾ 重要な言語である事は誰もが認めるが、凄いかどうかは微妙。 今はjavascriptそのまま使うよりtypescriptでしょ ぼほ主流スクリプト言語はオブジェクト指向も関数型も搭載済み。 ライブラリに頼らずjavascriptのそのままテキストエディタに手打ちで一気に書けるのが熟練エンジニア
コードの保管などいらないし、変数の型も当然頭の中で整理されていて矛盾など起きない
後で保守する奴のためには、ちゃんと事細かなコメントを付けてやり、見やすく改行とインデントを付けて置いてやる
フレームワークに頼る奴は二流だ と、IDEやフレームワークの進化ついて行けないロートルが申しております 近年必要なコード量が多過ぎだよな
にも関わらずそれに対処しようとする言語は無い
それこそIDEやフレームワークに責任を丸投げしているが、
よく考えてみるとJSは当時で言うそれだったわけだ
もう一回りして未来に流行る言語はそういうものであって欲しいね 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%アップってやつか? C/C++はもはや速度を求めるコアライブラリか組み込みでしか生き残ってないけどね
(競技プログラミングという変な分野もあるけど)
コンピュータの適用範囲が広がったので昔のようなC/C++が独壇場だった分野がメイン
ストリームではなくなったともいえるが OSもアプリもたいていC/C++でしょ
それ以外の新興分野ってなんだ >>647
アプリってObjective-Cのこと? この文脈ではObj-CもC/C++に含めていいかと >>649
だったらC/C++/Objective-Cと書かない?
CとC++をわざわざ併記してるのに、そこにObjective-Cを含めるのは拡大解釈っぽいと思う 366 :nobodyさん 2017/05/29(月) 16:07:39.16 ID:6v4UcGhE
今回の民法改正、ソフトウェア受託開発の場合、(検収後ではなく)バグ発見後1年瑕疵担保責任があるということで、地獄かよ、と思ったが、
元々問題が起きがちな受託案件がビジネス的に成立しなくなることで強制的に業界再編につながるなら良いことかもと思うようになった。
一部で地獄を見ても。
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など動的言語は確実に廃れる。
保守に強い言語のみ生き残れる。 瑕疵担保責任(かしたんぽせきにん)
瑕疵担保責任のポイント
民法改正で事実上期限が「無制限」になった
バグや設計のミスなどは、瑕疵担保責任
納品物に不具合があれば損害賠償を請求される可能性もある
不具合を指摘されたらすぐに行動をとるべし
軽微なミスでも先延ばししない
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年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。 js/es は new を廃止するか、new を関数に変更して、且つ、定義時にデコレーターとして使えるようにしなきゃ、今の大流行は尻すぼみになるだろうな。 newが問題だった訳じゃない、貧弱で変わり者のクラスシステムに頼らざるを得なかったことが問題だっただけ
それもES6で解消されたし、プロトタイプの設定が解禁されたのでnewに頼らないクラスシステ厶も自由に構築できる
それこそシンプルなオブジェクトだけのインスタンスベースでClass.new()みたいに書く世界を構築することも可能 ファイル操作とテキスト処理とか正規表現が得意なスクリプト言語ってないですか 今のサイトってHTML5ばかりだからjsを知ってるだけで得することが沢山あるよな chromeのプラグインで無垢なサイトにやりたい放題^^ phpで検索WebAPIを作ってみてるんですが、
page番号を指定しようと思って、?page=0とすると$_GET['page']で受け取れないようなんですが、
0は指定できないんでしょうか
一応1からの指定にしてphpの中で1を引くことでちゃんと動作できるようにはできたんですが 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
9PV1J PHPとかJavaScriptで金融関連システム案件有るけど、本当に金額計算とかに使えるの? javascriptってjavaよりややこしいね。 型情報ないのに、コールバックばかりだなら、
理解しにくいソースなりやすいからなぁ。 javascriptのスレって過疎ってるな(´・ω・`) js初心者なんだが
jsでjsonファイルを開いて
pushでデータを追加して
それをローカルファイルに保存する方法教えてくれー(´・ω・`)
json開いてpushまではできた
ローカルファイルを更新するところで詰まってる
出来るだけ綺麗な方法がいい
Node.jsは使ってない Node.jsがよく分かってないし
使ったことがないから怖くて(´;ω;`)
今の環境はxamppだけど
サーバはubuntuで作ってるし
phpの互換の問題で手を焼いてるのに
新しく学習する時間がない ローカルファイルなら、Ruby。
JavaScript なら、VSCode でも使っている、Electron = Node.js + Chromium
Node.js をインストールしていないと、npm, yarn などのパッケージマネージャーが使えないだろ
コマンドプロンプトで、where node で、インストールした(PATH を通した)場所がわかる。
C:\Program Files\nodejs\node.exe firebaseを使ってログイン機能を実装してるんだが
ログインしている時にユーザ情報を取得する関数としてuserInfo()と言うのを書いたんだがうまく動いてくれん
btnをクリックしたら
53行目のアラートが実行されて
62行目のアラートが実行されるんよね
それで戻り値はundefinedだし
https://i.imgur.com/07PL6Yh.png js初心者なもんでエロい人教えてください(´・ω・`)
コールバック関数とやらで何か処理せんといかんと? ajaxで複数のオブジェクトを同時に送ることって出来るの?
jsonデータとFormDataを同時に送りたいんだけど $.when( getJsonA(), getJsonB(),getOtherData() ).done( function( obj1, obj2, obj3 ){ var jsonA = obj1[0]; var jsonB = obj2; var otherData = obj[3] }); PHP始めるけどどんな環境がいいの?
IDEは多分vscode使いたい
Pythonだとインポートサジェストがvscodeにはまだないけどphpは大丈夫?
それとPythonで言うanacondaみたいなものはあるの?
鉄板とかあるの? それをマルチって言うんだよ
何日待ったか知らないが「別スレで聞くことにしました」
って質問を閉じるだけの事が出来ないの? 「別スレで聞くことにしました」って書いたからってなにか変わるわけでもないけどな。
しいて言えばそれを見た人の気分か。 別スレで回答があれば閉じるし閉じなくても違う意見があれば聞けるわな
phpプログラマーってもしかして色々とレベル低いの? composerぐらいすぐ出てくるだろ
google検索は英語に設定しろよ。日本語の糞記事しか出てこねーだろ >>687
普通にマナーだし、それ書いてたクロスポストじゃないと判断するよ。 マルチポストと判断しようがしまいが実質何も変わらんと思うが。
>しいて言えばそれを見た人の気分か。
結局これかね? >>693
ホリエモンがいうところの勉強すればだれでも東大生になれるっていうのと同じ理論だな 初心者です
質問させてください
Windowオブジェクトというのは、つまり大元のObjectオブジェクト(組み込みオブジェクト)の事ですか? (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!] コントローラ側にruby使ってます。
フロント側からExcelファイルを選択して
submitボタンでファイルオブジェクトを送った後に
そのファイルデータをコントローラー側で読み取らせ
コントローラ側から処理結果をフロント画面側に返したいです。
ただ、submitだけだと、コントローラ側に渡して終わりになってしまうので
submitボタン押下時にJS側からPostJsonとかで送って、その結果をJS側に返して、
最終的に画面側に[読み取り成功]or[失敗]みたいにしたいのですが
PostJsonで送っても、ファイルオブジェクトとして渡せないので
困っています。どうしたらよいでしょうか?? Ruby on Rails では、ファイルのアップロードなら、Active Storage
HTML じゃなく、単にJSON を返してもらいたいなら、API モードもある
回線を通ると、オブジェクトの型などをキープできない。
だから、ファイルオブジェクトではなく、単にバイナリ・文字列になってしまう。
これをシリアライズと言う その簡単な言語に滅ぼされてる言語の墓場はここですか? 簡単だからこそ覇権を取れた
そしてここはその簡単な言語すら修得出来ない馬鹿の墓場 簡単ではないだろう。
あんな扱いにくいものはない。
そもそもブラウザ上でアプリを動かすということ自体無理があって、それをあの手この手でどうにかしようとしてるのが今。
そしてサーバーサイドもjsで実行しようとしてるんだから何が正解なのかもうわからない。 日本人でJavaScriptを使いこなせるプログラマーなどれぐらいいるのだろうか?
ただし、JQueryのみの人は除外。 JavaScriptは大変難しい言語です。Rubyの難易度を2、Cの難易度を5、C++の難易度を8にすると、
JavaScriptの難易度は12ぐらいあると思います。
このコーディングガイドはそんなJavaScriptの深みに嵌まらないようにするためのJavaScriptの書き方を規定したものです。
初級者1のための物ですので、わかってやっている人に好きにやってください。 >>704
JSすら理解出来ない馬鹿が、自分の馬鹿さを認められない時に「JSは難しい」事にしようとしてるだけ
お前のことだが
理解に困らない奴は普通にもうJSやってる
ブラウザ上でアプリ動かすのも自然だし、さっさとそれに気づいた奴がchromeOSを提唱しただけ
俺もJS使い慣れてからは確かにOSの代わりにブラウザでいいわ、って思うし
同様にサーバーサイドもJSでいいし、実際そう思う奴がそれなりにいるからそういう動きになる
お前は自分が理解出来ないのを自分の馬鹿さゆえと認めたくないから他を否定してるだけ
それをやってる限りお前に進歩はないよ
ただ、そういう流れ/動きになってるというのは、
お前以外の他多数はそう思ってそう動いているという事実を認めた方がいい >>707
じゃ、お前はJSでマリオカートを作ってみろ。 JSという小道具で高級なもの作るのが要求されるんだから結果論としてJSは難しい
RubyとかPythonはライブラリが強力だからちょっと学べばすぐ何か出来るんだけど
JSは言語仕様が分かる程度じゃ何も作れんし
ライブラリが乱立してるのもあって、書き方が非統一でスマートにもなってないメソッドで機能実装しなきゃいけないから
そういう難しさ >>708
WebGLもある今なら普通に出来るだろ
任天堂から十分な金額で求人が出てれば俺は応募してもいいが
そもそもお前は勘違いしていると思うが、マリオカートを作る難しさはどの言語でも大して変わらん
スプライトとかのレンダリング周りはあれば便利だが、無ければ自前で作るしかない
ただそれは「手間」が大幅に増えるだけで、「難しさ」には寄与しない
結局は座標を計算して投げるだけだから、それによって複雑になることはないんだよ
あれば楽なだけで
>>709
ならRubyやPythonならマリオカートをど素人でも作れて、JSだと無理とでも?
さすがJSすら理解出来ない馬鹿は言うことが違うね >>710
>ならRubyやPythonならマリオカートをど素人でも作れて、JSだと無理とでも?
>さすがJSすら理解出来ない馬鹿は言うことが違うね
そもそもお前は勘違いしていると思うが、マリオカートを作る難しさはどの言語でも大して変わらん
スプライトとかのレンダリング周りはあれば便利だが、無ければ自前で作るしかない
https://www.youtube.com/watch?v=wgZ09_6Q8wU マリカーなんて作っても仕方ない
JSでページ作るっていっても
本来JSでやらないような処理が多かったりして
js以外で培った知識が導入されることも多いから
自称js出来るってだけの人じゃ難しいよねって話してる
ブラウザ上で出来る事=OS上で出来る事のすべてって風になってきてるんで
Javaとかrubyで作っていたものをブラウザ上で動かすためにJsに落とし込むような作業があるでしょ
それが簡単な作業とでも? >>712
それはお前らお得意の「論点のすり替え」でしかないだろ。
言語間の難易度の比較なのだから、当然同じ事(同じアプリ)をそれぞれの言語で実装する時に難しいかどうかだろ。
「マリオカートを作る時に難しいかどうか」という視点はこの意味で正しい。
座標の計算が出来ない馬鹿がマリカー作れないのは、どの言語でも同じだよ。
> 自称js出来るってだけの人じゃ難しいよね
これは単にJSの馬鹿共が勘違いしてるってだけだろ。
これは事実としてあるが、逆に言えば、
勘違いする奴が多い=本当は大した実力もないのに、いろんな事が出来てしまう
ということであり、JSの簡単さを補強しているだけだよ。
> Javaとかrubyで作っていたものをブラウザ上で動かすためにJsに落とし込むような作業があるでしょ
> それが簡単な作業とでも?
ねえよそんなの。と言うか言うほどインタフェースは変わらんし。
具体的に何に困った?それは君がそれを知らないからでしかないだろ。
座標計算出来ない奴がマリカー作ることは『どの言語を使っても』無理なように。
JSは一般的に簡単だとされているLightWeight言語にカテゴライズされてる。
PHP/Ruby/Python/Perlもそうだが。
そしてそれ以外、つまりJava/C#/C++/Rust等を使いこなせている奴がJSを難しいなんて言うのはほぼ居ないだろ。
(完全にJava脳になってる奴にはどうにも受け付けられないらしいが)
だから多くの人にとってJSが比較的簡単なのは事実であり、それをグダグダ言ったところで始まらんよ。 で、その簡単に書けてるJSで仕事って取れてるの?
そんな美味い話はありません
仕事取れるレベルのJSなら難しいものです >>714
また論点そらしか。その程度だとプログラマとしては無理だから止めた方がいい。
それのどこが「JSが比較的難しいプログラミング言語」になるんだ?
お前は学生なのかそれ以下なのか知らんが、
当たり前だが、誰でも出来るようなことで簡単に給料を得る方法なんて無い。
それはどの職業でも同じ事だ。勿論プログラマも含まれる。
お前が言ってるのは「プログラマは誰でもなれて高給を得られる職業ではない」であって、これはその通りだ。
しかしこれだと論点がずれていることにすら気づけないお前ではプログラマは無理だ。止めとけ。
前述の通り、給料を得ようと思えばそれなりなのが必要なのは全職業だし、
プログラマに限っても、『どの言語でも』同じ事だ。
まあそれでも比較的JSとPHPはプログラマ全体から見たら馬鹿が多いからWeb系と馬鹿にされてるわけだが、
しかしこれも、逆に言えば比較的馬鹿でも給料を得られるということではある。
ただし今Webがバブルってるだけかもしれんが。
まあJSすら理解出来ない馬鹿と話しても意味がないと理解した。
次の論点逸らしには返答しないからそのつもりでよろしく。
お前には未来永劫「JSは難しい」とつぶやき続けて次世代から馬鹿にされる未来がお似合いだよ。 jsが難しいというか
js周りのフレームワークは移り変わりが激しい
生jsはIDEの支援が少ない
という理由で開発する人は大変という印象 >>716
> js周りのフレームワークは移り変わりが激しい
乱立しているのは事実として、
いちいち付いていきたくなければ使わないのもありだし、古いのを使い続けるのもありだろ。
Javaみたいに10年間進化しない方がいいのならこれでいい。
選択肢がある分ましだと思うが。
> 生jsはIDEの支援が少ない
これは動的型言語共通の話で、Python/Ruby/Perl/PHPとも同じだし、同程度には支援があると思うよ。
それ以上の支援が欲しければ型を明示的に書くしか無く、TSがこれになる。
逆に、静的型言語で型を(全面的に)省略することは出来ないから、これも選択肢がある分ましだろ。
まあPythonは意図的に選択肢を絞っているし、それが受けているようではあるが、
俺はMatzと同様、いろんな実装方法があった方がいい、という意見なので。 >>716
それ故に新しい環境にちゃんとついていける奴は少なくなるし
ついていければ有利だろうって算段でやってる
>>715
オラオラしたいだけの学生キッズと違って大人はお金や+@が必要なんよね
無駄なエネルギーを使うのをやめたほうがいい >>717
>これは動的型言語共通の話で、Python/Ruby/Perl/PHPとも同じだし、同程度には支援があると思うよ。
原理上はそうだけど環境の比較であれば実際に入手できる環境の優劣はあるね。
VSCodeのlanguage serverはTypeScriptじゃない生jsでもかなり強力に推論してくれるし
Pylanceもそこそこ使えるものになっている。
PHPとRubyはこれからってところじゃなかったかな。 >>719
その辺に関しては結局のところ人数勝負であり、JSとPython以外については死体蹴りでしかない。
ただしVSは(Codeは知らんが多分同じ)ただのフロントエンドであり、
IDEサポートについてはどの言語でも原理は同じなので、横方向展開は(やる気があれば)早いはずだが。
まあバトルロワイヤルなら第一ラウンドは終わって、これから優勝決定戦が JS vs Py で行われるといったところだろう。
ついでにPythonも滅ぼして欲しいところだが、JSは非同期強制なのとコンソールがないのが痛い。
MSがPowerShellとかいうゴミに逃げずにCScriptを発展させてくれれば良かったのだが、
これはどっちかというとMSが追い出された側だからJSの失態だが。
して、JS vs Py はお互い相手を滅ぼすほどの決定打を持たず、しばらくは膠着状態が続くのだろうね。 >その辺に関しては結局のところ人数勝負であり、JSとPython以外については死体蹴りでしかない。
あんたが死体を並べておいて何言ってんの?
>IDEサポートについてはどの言語でも原理は同じなので、横方向展開は(やる気があれば)早いはずだが。
原理的には同じであっても各々の開発者コミュニティのやる気や能力には差があるわけで。 pythonが生き残ってる理由ってnumpyがあったからでしょ。単に機械学習の分野で使われてるだけ。
単にスクリプト言語としてならjsの方が遥かに優秀だし可能性はあるよ。
非同期強制に関しては何が悪いのかわからない。
コンソールはあるし。 > pythonが生き残ってる理由ってnumpyがあったからでしょ。
殆どの言語はそれなんだから当たり前。どれでもいい言語が大半。
選ぶ理由は言語ではなくライブラリやフレームワーク
> 非同期強制に関しては何が悪いのかわからない。
非同期強制ではない。四則演算などは同期的に処理される
何が悪いかというのは、二通りのやり方がある所
ライブラリのデフォルトがほぼ非同期になってる所
つまりライブラリが悪い スクリプト言語としての活用の仕方っていっぱいあるじゃん。例えばクローリングや業務の効率化の為とか。
そう言ったニッチな分野でもpythonが使われてるけど、その理由は機械学習がトレンドだった時代にpythonが推されて、それを見たユーザーがpythonを勉強してたからでしょ。pythonを何故か書ける人が多い理由はこれだと思う。
そういう分野でも俺はjsが向いてると思うよ。nodeやそれを取り巻くエコシステムが充実してるから。インタラクティブな環境もあるし。
数理処理を除いて基本的にpythonにあるライブラリはjsにもあるし、逆も然りでしょ。
イベントループってご存知?実promiseとかasync awaitとか非同期処理を書くときの概念は最初は戸惑うけど、かなり合理的だよ。
まぁ、pythonは数理処理を行うためなら良いと思うけどね。 そういうのは、非同期に処理したいときだけ、使えば良いんですよ。
必要もないのに、誰か(ライブラリ)に強制されるのがアホらしいのであって JavaScriptも同期的処理がメインのライブラリ、実行環境がでればいいけど
それがでないのでPythonの変わりにはならない
逆にブラウザで動くのはJavaScriptしかないから、PythonはJavaScriptの変わりにはならないが
それはJavaScriptが優れているからという理由ではない。
単にブラウザがJavaScriptを選んだってだけ 結局の所、ライブラリや実行環境という
言語以外の部分を理由に、言語を選ぶのであって
言語自体で選んでないのよ 必要もないのにpromiseを使ってる例を教えてね。多分必要があるからそう書いてると思うよ。
ライブラリや実行環境含めてpyは貧弱だってことだよ。
パッケージの管理やlintとか。型システムとかね。
pipenvとかメンテされてんの? > 必要もないのにpromiseを使ってる例を教えてね。多分必要があるからそう書いてると思うよ。
例えばデータベースのデータを取ってくる時に
データが返ってくるまで待ちたいのに
Promiseを強要される所 それは当たり前にpromise返すよね。
複数の非同期処理を直列で行いたい、並列で行いたいとか書き手のあらゆるユースケースに対応するためのものじゃん。 >>731
並列で処理したいとか思ってないんだが?
データがないとその先の処理はできないんだから非同期にする理由がない
ただデータを欲しいだけで、その処理を並列でやろうとか思ってない
なのにPromiseを強要されるって話をしてるんだが?
言っただろ?
そういうのは、非同期に処理したいときだけ、使えば良いんですよ。 今なんの話をしてるのかわかってないのか?
ブラウザのユースケースの話ではない
サーバーアプリのユースケースの話ではない
それらのユースケースでは非同期は必須だが、
非同期が必須じゃないユースケースもあって
そこには非同期ばっかり使う今のJavaScripの実行環境とライブラリは
適してないって話をしてるの気づいてる? 俺が例を聞いて、データベースの例出してきのは君だよね? async awaitの登場でそこら辺も意識しないで済むでしょ。
そのうちtop level awaitもサポートされるし >>734
データベースからデータを取得するプログラムが
いつ非同期が必要になったんだ?w
データベース自体が必要なのと、
データベースを使う「アプリ」が必要なのの
違いも区別できてないのか?
今話をしてるのはJavaScriptで作るアプリの方だろうが >>735
async awaitを使うか使わないかを
使い分けてる時点で意識してるw asyncawait全然難しくないのにそんな同期欲しいか?
中途半端に同期APIに門戸を開くと実質同期waitが可能になって
モラルハザードが起こるから要らないんだけど >>738
どちらかに統一されるならまだしも
同期と非同期の2つが頻繁に混ざることが問題
同期メインで必要なときだけ非同期を使うほうが楽だって言ってんの すまんけど混ざった経験がない
混ざるってなに?
非同期メインでどうでもいい時だけ同期を使う方が正直楽 >>740
日付操作ライブラリは非同期ではない
普段書いてるJavaScriptコードも非同期ではない >>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を滅ぼせない理由の一つだよ。 今言ってるコンソールって誰も言っていません。どこで出てきましたか?
コンソールアプリケーションのコンソール=動作環境という論理で話していますが、意味がわかりません。
難しいからダメというのは話になりません。
俺は幅広いユースケースに対応できるのはjsだよねって話しています。まともな反論はなかったです。
置き換えが容易、pythonが勝者だというソースを出してください。 indexedDBの同期apiがなくなったのは当たり前。localstrageも非同期になって欲しいくらい。
基本的にどんなioをjsでは非同期になってほしい。
そうすることで待ち時間に処理を実行できたりするから。 > 俺は幅広いユースケースに対応できるのはjsだよねって話しています。
どの言語でも幅広いユースケースに対応できてるだろ
C言語で作れないものはないとでも言えばわかるか?
> 基本的にどんなioをjsでは非同期になってほしい。
非同期が必要ないユースケースは?w
非同期が必要ないユースケースなのに非同期を強要され
だからといって非同期に統一されているわけでもない
自分の都合ではなくライブラリの都合で、同期と非同期を混在させなくてはいけなくなる
どうせ統一できないのであれば、必要なところだけ非同期にしたほうが楽だろ 非同期が必要ないユースケース=待ち時間にする処理がない場合
例えば取ってくるデータがなければその後の処理ができない場合、
データを取ってくる処理を非同期にしてもただ待つだけで
待ち時間にする処理が何もことがない >>743-744
お前が日本語もプログラミングも出来ないのは分かった。
相手する価値がないからもうやめにする。
> pythonが勝者だというソースを出してください。
と言う以上、お前はこれを否定出来るソースを出せるのだろ?まずそれを出せ。
このレベルの既知の事柄についていちいちソースソース言われても話が進まなくてウザイだけだし、
そもそもこの点に反論したいのなら743の時点で君が君側のソースを出す手もあった。
それが出来ないのは君が会話が出来ない馬鹿だからだよ。
> localstrageも非同期になって欲しいくらい。
これも既に言ってるだろ。
JS界では同期I/OのLocalStorageは以前から問題視されてて、非推奨とされているが、いまだに廃止出来てない。
それは廃止出来ない理由があるからであり、俺は既にそれを言ってる。
君は日本語が不自由だから話について来れず、何度も同じ事を説明されないと分からない馬鹿だ。
それだと話が全く噛み合わず、進まないんだよ。
実際、他の件もそうだろ。ここで会話出来る最低限の日本語レベルに達してないし、プログラミングの知識もない。
まあそれでも君みたいな馬鹿でも非同期ガーとイキれるのはJSの良いところで、
つまり馬鹿でも出来てそれなりに見栄えのする結果も得られ、出来ると勘違い出来る言語、ということでもある。
ただ、イキってる馬鹿はどの言語にもいるが、JSのイキリ馬鹿は他言語に比べてもだいぶ酷い。 よくよく考えてみると、JavaScriptでPromise(≒非同期)を使う場合って
「処理が終わるまで(何もしないで)待つ」時に使ってるよな?
非同期を使ってる本当の理由をわかってない気がする
非同期を使ってる人、ちゃんと使っている理由を正しく言えるのだろうか?
1. ブラウザで画面が反応しなくなるのを防ぐため
2. サーバーアプリで他のリクエストを処理するため
に非同期を使ってるんだぞ
並列処理とごっちゃになってそうな気がする
非同期は速くするためにやってるわけじゃない >>748
>よくよく考えてみると、JavaScriptでPromise(≒非同期)を使う場合って
>「処理が終わるまで(何もしないで)待つ」時に使ってるよな?
待つ時以外にも用途があるわ。
例えばファイルをreadする処理がある場合、非同期だとreadする時間を有効活用して何か処理を実行できたりするだろ >>750
> 非同期だとreadする時間を有効活用して何か処理を実行できたりするだろ
うん、可能性としてはそういうこと出来るよね。
でも、そんな考えで非同期使ってることってほとんどまずないよね
ただ待つためだけに使ってるよね。
ちゃんと画面を反応を止めなくするため or 他のリクエストを処理するために
非同期使ってますって意識してる? それを知ってるなら、コンソールアプリなどのユースケースは
画面の反応(更新やクリックとか)が不要で、他のリクエストもないってわかるよねw
ブラウザやサーバーアプリ以外、
それが必要もないのにpromiseを使ってる例だよ 勿論手元でワンライナー書く程度のどうでもいい用途には同期APIで十分
だからnodeのI/Oには一部同期APIも入ってる
ただしどこまで同期APIを用意するかは最早さじ加減の話
〇〇に同期APIがないからダメって言われても困る >>754
そしてそのどうでもいい用途向け言語がいわゆるスクリプト言語で、実際にそういった用途が大半なわけだ。
状況が変わってきてるんだよ。
昔と比べて(文系含め、コンピュータのことを全く知らない、いわゆる)馬鹿がプログラミングするようになった。
これ自体はスマホが一般化するのと同様に自然な流れなのだが、その分、簡単な言語が必要とされるようになった。
Pythonが伸びているのはこれ。他と比べて比較的簡単だから。
PHPに至っては、プログラミングの何たるかを知らなくても何とかなってしまうという、すさまじく簡単な点が受けている。
(なおC->Javaに移行したのも簡単だからだ。というか、ど素人含めて全員Cで書け、という90年代が今から考えたら無茶すぎた)
非同期が駄目ってわけではないが、非同期縛りは馬鹿にとってかなり高い参入障壁になってる。
JSやって最初に引っかかる点も大体ここだろ。
JSが覇権を取る為に何かを修正するのなら、俺はここだと思うね。
逆にPythonが覇権を取る為には実行速度で、連中があまりここに着手しないのが俺にはよく分からない。
(とはいえPythonにはそれ以前に色々駄目な点が多いが)
ついでに言うとRubyも実行速度だと思う。
Pythonが今程度に遅いうちにJSの速度に追いつけば、Pythonを食う可能性も十分あると思うのだけど、
連中も何故かあまりここには手を付けないんだよね。 >>754
なんでワンライナーが基準なの?
曖昧なこと言ってないでもう少し具体的に言おうか 少なくともJSにとっては大半じゃないよ
書き捨てこそスクリプトって話ならperlが覇権とってたハズでしょ 例えばgitの実装なんか、非同期処理は殆どいらないだろ? CLIコマンドのほとんどは非同期は必要ない
非同期なら空いた時間に他のことが出来る?
同期であってもI/O待ちなんかでCPUが解放されるんだから
空いた時間の他のこと(他のプロセスの処理)は出来るって
そういう基本的な所がわかってないんだよなw >>757
Perlが覇権取ってたのは事実だが、それも過去になりつつある。
Perl6に移行してる奴はほぼ居なかったはず。
そして今時は「インストールスクリプトでPython使ってます」という理由で
Pythonがインストールされてないとインストール出来ない物が当然のように出てきており、
俺のPCにも使いもしないPythonはインストールされてる。2も3もだ。
この意味ではPython汚染はPerlより酷いと思うよ。
なおRubyもインストールされてる。同様に何かRubyを必要とする物があって入れたと思った。
まあこれがいいかどうかはさておき、JSはこの分野に進出出来ないでいる。
これが覇権を取りきれない理由でもある。 JSサイコー、愛してるぜ・・・(*´Д`)ハァハァ 日本国内でjavascriptを使えるプログラマーはどの位いるのでしょうか?
10万人程度? ■ このスレッドは過去ログ倉庫に格納されています