【node.js】サーバサイドjavascript 5【Nashorn】

1 名前：デフォルトの名無しさん [2018/02/13(火) 22:21:33.91 ID:moEhrPrC.net] pythonやrubyやPHPと同じ土俵でjavascriptが使えるようになりました。 サーバサイドjavascriptについて語りましょう。 node.js - googleが開発したV8エンジン上で実行できる処理系 nodejs.org/ ayo.js - node.js 互換で Rod の影響からの脱却を目指す処理系 https://github.com/ayojs/ayo Nashorn - Java8 からRhinoに代わって同梱されているJavaScriptエンジン www.oracle.com/webfolder/technetwork/jp/javamagazine/Java-JA17-Nashorn.pdf ayo.js の経緯 https://web.archive.org/web/20170821212745/https://github.com/nodejs/TSC/issues/310 javascriptはrubyと比較してもかなり速い shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=yarv 基礎から学ぶNode.js gihyo.jp/dev/serial/01/nodejs node.jsの概要とアプリケーション開発の準備 gihyo.jp/dev/serial/01/realtimeweb/0002 前スレ 【node.js】サーバサイドjavascript 4【io.js】 mevius.5ch.net/test/read.cgi/tech/1460359714/ 【node.js】サーバサイドjavascript 3【io.js】 echo.2ch.net/test/read.cgi/tech/1419673207/ 【node.js】サーバサイドjavascript 2【Rhino】 peace.2ch.net/test/read.cgi/tech/1358937029/ 【node.js】サーバサイドjavascript【Rhino】 toro.2ch.net/test/read.cgi/tech/1310087535/ 657 名前：デフォルトの名無しさん mailto:sage [2021/11/17(水) 15:53:34.41 ID:OJq8ALeu.net] 上にもちょっとありましたが、レンタルサーバでnode.jsを動かすのって現実的じゃないもんなんですか? 658 名前：デフォルトの名無しさん mailto:sage [2021/11/17(水) 16:00:07.09 ID:lSu1Xmea.net] いや全然 上にある「レン鯖はPHP」ってレスは恐らく既に環境を構築済みで あとは実行する.phpを配置するだけのWebスペースを想定したレス 659 名前：デフォルトの名無しさん mailto:sage [2021/11/17(水) 16:22:49.28 ID:sYjDCVja.net] node.js使えるレンサバってあるの？ 660 名前：デフォルトの名無しさん mailto:sage [2021/11/17(水) 16:34:28.88 ID:lSu1Xmea.net] >>658に書いたような実質Webスペースの共有レン鯖でも端末触れる一部では使えるよ 占有型ではもちろん使えるけど今なら間違いなくVPSのほうがいい 661 名前：デフォルトの名無しさん mailto:sage [2021/11/17(水) 17:46:17.02 ID:+3kxan1m.net] 古き良きLAMP環境に拘る理由がないなら好きにしたら良い 662 名前：デフォルトの名無しさん mailto:sage [2021/11/17(水) 23:30:54.62 ID:YG2/9hEL.net] >>659 昔ながらのFTPとかでファイル置くしかできないようなサービスならまずそんなもの導入されてないだろうな 663 名前：デフォルトの名無しさん [2021/11/25(木) 05:21:15.21 ID:HW7nta/v.net] gulp4でejsをを使用したい + 別のタスクと記述方法を統一したいのですが どうしてもエラーが解消できないのでどなたかご教授頂けませんか？（exportsにオブジェクトを突っ込む方法） 古い記述方法では動作しますが、新しい記述方法ではどうしても動作しません。 色々ググったのですが、どのサイト（英語サイトも含め）も古い記述方法で書かれており困っています。 公式も古い書き方に記述されています。（ejsだけ新しい書き方に対応していない？） https://www.npmjs.com/package/gulp-ejs //old gulp.task('ejs', function() { // } 新しい記述方法では、どうしても下記のエラーが解消できません。 - The following tasks did not complete - Did you forget to signal async completion? また`ps aux`で別のプロセスも走っていないことを確認しており、別のgulpタスクも全てオフにした状態で デバッグしております。 関数の引数にdoneを入れてdone()で締めたり、return除いてみたり試行錯誤していますが、数時間ハマっています。 どなたら分かる方いらっしゃたらご教授お願い致します。 //new function ejs() { return gulp .src(srcPath.ejs) .pipe(ejs()); } exports.ejs = ejs; 664 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 06:59:11.02 ID:nh0ZEMSE.net] このエラーメッセージで検索すれば？ それか、意味を考えてみれば？ The following tasks did not complete Did you forget to signal async completion? もっと単純な例で、動くかどうか試してみれば？ 665 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 07:24:22.11 ID:QOEXsJ22.net] >>663 状況全く分からんが、JSのパーサーはややおかしい？所があって、returnの後はぶった切られる。 よって、　return gulp.src(srcPath.ejs).pipe(ejs()); と改行を無くして試す事を勧める。 666 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 07:46:08.16 ID:88pS2ZzI.net] >>663 https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Lexical_grammar#automatic_semicolon_insertion 667 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 08:25:42.47 ID:QOEXsJ22.net] >>666 これ return と yield (と後置演算子もか？)はパーサの仕様バグだよな？ 直感的じゃ無いという意味で。 668 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 08:37:10.78 ID:acYGqwrp.net] 仕様だよ お前の直感がおかしい 669 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 08:57:16.71 ID:QOEXsJ22.net] >>663 いや実際660はそうしてるだろ。俺も以前嵌った事があったし、 実際セミコロン必須の言語だとどこで切ってもいいから、660の書き方はよく見るよ。 俺はお前がおかしいと思うが。 結局これもMDNで説明するのに例外扱い("no LineTerminator here" 規則)になってるし。 統一された文法ではないよね。（=もっとましな仕様にする事も出来たし、実際他言語はそう） 670 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 08:57:57.52 ID:QOEXsJ22.net] すまん分かると思うが 666 は >>668 宛 671 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 09:45:34.63 ID:6PNOZvLH.net] >>669 その書き方よくみるというけど 1行で書けば見やすいのにわざわざ複数行で見にくくしている意図がわからない 672 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 10:02:02.58 ID:QOEXsJ22.net] >>671 そりゃ、そうした方が見やすいと思う人がそうするだけだよ。 お前がそう思わなければしなければいいだけ。 ただ実際、660にある公式のコードもそうなってるだろ。 俺も個人的には横に長いコードを書くけど、一般的には縦に長いコードの方が多いと思うよ。 673 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 10:13:11.42 ID:rnpiht7q.net] returnの直後に改行してないからASI関係なくないか？ 674 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 10:19:20.71 ID:QOEXsJ22.net] >>673 660の「新しい記述方法だと動かない」とされてるコードは return gulp で改行してる。 660内の公式はこれが出来ない事を知ってるから、 gulp.src(...) で改行してる。（ただしreturnはないが) 675 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 10:26:17.55 ID:6PNOZvLH.net] >>672 それは長い行を分けて改行しているだけ 一方で>>663の人は長い行にならないのに無意味に改行しまくり 676 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 10:28:27.93 ID:rnpiht7q.net] >>674 return gulp.src() ならreturnの後にセミコロンが自動挿入されるけど return gulp .src() ならgulpの後にセミコロンは自動挿入されないでしょ それよりfunction ejs(){}って名前がダメなんじゃないの？ .pipe(ejs())で再帰になってる 677 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 10:36:21.11 ID:QOEXsJ22.net] >>675 長さではなく、意味で切るんだよ。 >>676 > return gulp > .src() > ならgulpの後にセミコロンは自動挿入されないでしょ されて gulp が返されるはずだぞ。 678 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 10:42:13.14 ID:6PNOZvLH.net] >>677 意味で切るならgulpと.src()の間で改行を入れてるのは明らかにおかしい 無意味な改行だ 679 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 10:42:35.39 ID:QOEXsJ22.net] >>676 すまん、674は間違い。 試してみたところ、確かに挿入されないようだ。 680 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 11:42:21.71 ID:QOEXsJ22.net] >>678 相手するだけ無駄っぽいが、そういうのは物によるんだよ。 そうした方が見やすいと思う奴がそうするだけ。 return ウンコ製造器675号 .src(ケーキ) .pipe(胃) .pipe(小腸); .pipe(大腸); なら、675によってケーキがウンコに変わるのが見やすくなると思う奴もいるだろ。 （詳しくないが）gulpの場合は基本はフィルタで型が変わらないし、出発点はソースファイルに決まってるから、 return gulp.src(ソース） .pipe(フィルタ1) .pipe(フィルタ2) のケースが多いとは思うけど。 ついでに言っておくと、お前JSによくいる、やたら文法に拘る奴なら、止めた方がいい。 それだと全く進歩しないので。 上記の通り、まあどちらもいるわな、程度で進めていかないと、上達しない。 どちらが正しいとか、そういう問題ではない。 どうにもJS初心者は「改行を極める」「セミコロンを極める」とかになりがちのようで、よろしくない。 681 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 12:57:12.37 ID:K4FLN1Dn.net] んじゃ俺は括弧の後に半角スペースを入れるのを極めるわ。 682 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 13:45:45.44 ID:R4fLO2Lj.net] 必死過ぎて笑えるｗ 683 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 14:09:48.85 ID:reZpBJt7.net] 珍しく伸びてんなと思ったらこれだよ 684 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 19:42:13.27 ID:b7JhAcnH.net] .NET Standard が世界の中心と考えてる人でしょ 別スレで見た 685 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 21:14:35.40 ID:QOEXsJ22.net] >>681 ゆとりにはそれがお似合いだね 686 名前：デフォルトの名無しさん [2021/11/25(木) 22:13:54.29 ID:HW7nta/v.net] 610です。 仕事でレス遅くなりました。 >>676 ありがとうございます！ このコメントからピンときて修正したら無事に動作しました。 超初歩的なミスでした、、 こちらの書き方は関数の中にejs(gulp-ejsオブジェクト)を書いても動作しましたが gulp.task('ejs', function() { } こちらでは関数に同じ関数入れたらまだタスク終わってないよと、動作しませんよね。（気づけば当たり前なのですが、、） function ejs() { } お騒がせしました。コメント頂いた方もありがとうございました！ 687 名前：デフォルトの名無しさん [2021/11/25(木) 22:25:35.12 ID:HW7nta/v.net] 誤 610です。 = > 正 660です。 688 名前：デフォルトの名無しさん mailto:sage [2021/11/25(木) 23:27:35.30 ID:nh0ZEMSE.net] 漏れは、Ruby でも、パーサーの誤解釈を避けるため、 . を行末に置く a. b( ). c( ) 689 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 01:34:21.64 ID:KdVwfKAT.net] なんで Ruby が出てきた 690 名前：デフォルトの名無しさん [2021/11/26(金) 22:15:56.74 ID:FIwAqG/H.net] スクリプト系は改行も終端になって駄目ね 691 名前：デフォルトの名無しさん mailto:sage [2021/11/26(金) 23:57:17.12 ID:MbvsChzk.net] >>690 JavaScriptで駄目なのはreturnのみの行の時だけだよ return a .b() は駄目だけどこう書く人はいないから問題は起きることはない return a .b() なら大丈夫 692 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 09:09:57.67 ID:kX7QbhiL.net] そういうのはコーディング時にいちいち気にするよりlinterでチェックだな。 693 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 09:24:44.31 ID:LVgG7qhW.net] >>691 それを知ってないと嵌るだけの無駄仕様だよ。 セミコロンなしの筆頭だったAirbnbも諦めたようだし。 > ASI contains a few eccentric behaviors, though, and your code will break if JavaScript misinterprets your line break. These rules will become more complicated as new features become a part of JavaScript. Explicitly terminating your statements and configuring your linter to catch missing semicolons will help prevent you from encountering issues. > https://github.com/airbnb/javascript#semicolons 他にセミコロンなしの有名ルール勢ってあったっけ？ return 'qwerty' +'asdfgh'; とは書きたくなるだろ。書きたいように書けないのはよろしくないよ。今風ではないね。 セミコロン書くルールならASIなんて無い方がマシだし。 694 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 09:32:19.66 ID:MtgsfYs/.net] 書き方にこだわりがあるならそうではない書き方と比べて◯◯の利点があると言わないと他人の理解は得られにくい。 好みだけの問題ならスクリプトの仕様に従うしかない。 695 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 09:36:27.04 ID:TUbuKQsw.net] 自分はなりませんねとしか 696 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 09:41:13.68 ID:LVgG7qhW.net] >>684 俺向けではないと思うが、 return 'qwerty' +'asdfgh'; の利点は見れば分かるとおり、インデントを揃えられる事だよ。 タグの方が分かりやすいかもしれんが一々引っかかると面倒なので止めただけ。 return '<div>' +'<span>'+ +'</span>'+ +'</div>'; だと最初のdivのインデントがずれるだろ。 まあ言うほどではないし、実際俺はこの書き方をしているが、出来れば return の後に改行したいね。 697 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 09:42:13.87 ID:LVgG7qhW.net] すまん693内681は>>694 698 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 10:25:26.66 ID:wIEauZJC.net] お前ら何も考えずにPrettier使え それが今のデファクトだ 699 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 11:22:05.56 ID:xgA8vuBV.net] >>693 Airbnbがセミコロンなしの筆頭って頭腐りすぎたろ git時代に歴史改ざんしてもすぐにバレる 2012年にセミコロンの章が初めて書かれたときからAirbnbはセミコロン派だ https://github.com/airbnb/javascript/blob/cab510342f93791a7487d16258d06ff73edb4507/README.md#semicolons 700 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 11:35:18.29 ID:LVgG7qhW.net] >>699 ならAirbnbというのは俺の勘違いだな。 俺がJSを始めた2013-14頃、有名なコーディングルールが4つほどあって、Airbnbが一番トンデモだった(が、人気は一番という話だった) その中にはセミコロンを打つな、というルールもあった。誰か思えてないかね？ なお俺はgoogleのルールが一番マシっぽいのでそれを参考にした。(こちらはセミコロンあり） 701 名前：デフォルトの名無しさん [2021/11/27(土) 11:43:32.92 ID:WAiK9igD.net] >>700 どこだか覚えてないけど、確かにどっかでセミコロン打たないで、短文を1行に書くときだけセミコロン使うてなの見たか聞いたりした記憶ある。 702 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 12:14:33.21 ID:LVgG7qhW.net] 一応自分でも再確認しているところだが、 > Always use semicolons. (google) > Use them. Never rely on ASI. (jQuery) > あなたからセミコロンを奪おうとする反抗的な軍隊があるようです。でも確かに私達の伝統的な文化はまだ元気に生き残っています。だからコミュニティに従って、セミコロンを使いなさい！(Node) > https://qiita.com/takeharu/items/dee0972e5f39bfd4d7c8 npmのもかなりトンデモだった記憶があり、改めて確認すると、打つな派だ。 > ;(x || y).performAction() > ;[a, b, c].forEach(performAction) > for (var i = 0; i < 10; i ++) { > switch (state) { > case 'begin': start(); continue > case 'end': finish(); break > default: throw new Error('unknown state') > } > end() > } > https://www.w3resource.com/npm/npm-coding-style.php となると俺の勘違いはnpmという事になるが、npm==Nodeじゃねえのか？という疑問は発生する。Nodeはnpmからのフォークか？ 多分俺が当時見たのは Airbnb, npm, jQuery, googleだと思う。 703 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 12:30:57.21 ID:i1Pzoh/C.net] NodeはRyan Dahlが始めてセミコロンあり npmはIsaac Z. Schlueterが始めてセミコロンなし IsaacはNodeの2代目リーダーだけどNodeではセミコロンを書いてた 704 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 12:54:15.05 ID:XFyMXPdv.net] セミコロンレスの強硬派として有名なのはStandard カスタマイズも許さない https://github.com/standard/standard 705 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 13:40:28.79 ID:LVgG7qhW.net] >>704 初コミット2015年なのにstandardと主張して他と違うルールとか、頭おかしいな。 とはいえ議論する時間が一番無駄というのは同意だが。 多分セミコロン無し言語出身者用のルールが一つは必要で、 それに向けてのstandard命名なのだろうけど、なんだかね。 706 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 13:49:34.28 ID:MtgsfYs/.net] 文字列を「+」で繋げるのもうやめようよ。見にくいよ。 「´」(バッククォート)で括ればいいじゃん 707 名前：デフォルトの名無しさん mailto:sage [2021/11/27(土) 13:51:01.70 ID:NSUO7OXD.net] >>706 このルール入れろ https://eslint.org/docs/rules/prefer-template 708 名前：デフォルトの名無しさん mailto:sage [2021/11/28(日) 09:28:43.85 ID:yQx61O6E.net] javascriptならセミコロン無い方がいいかなぁ 709 名前：デフォルトの名無しさん mailto:sage [2021/12/14(火) 18:36:52.92 ID:R85W1UAs.net] async/awaitってawaitしかしないから無駄じゃね？ 710 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 08:00:15.12 ID:iIGCgNg3.net] Promise, async/await で無駄なのは、デタラメ解説の数々、ほぼ全滅だろ、酷い惨状だねー。 711 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 09:04:50.48 ID:S+a9i6vw.net] それを言ったらWeb系言語は全部デタラメ解説で駄目だろ 初心者が情報公開の練習として解説を書くからそうなる 712 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 10:12:00.53 ID:6ScHvZpk.net] それはしゃーない、正確さにこだわりすぎて萎縮する方がデメリットが大きい 読む方が気を付けて取捨選択するしかない 713 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 10:19:35.71 ID:jog3O69G.net] c++とかjavaとか含めて進化してる技術の古い解説はことごとくゴミ化してるし一緒だわな 714 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 11:04:07.34 ID:4h95DB/2.net] classは非推奨にして欲しい。 中途半端で使いにくい。 715 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 13:04:22.56 ID:PmcDL+gd.net] >>714 どういう所？ 716 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 13:40:10.35 ID:S+a9i6vw.net] >>712 同意だが、C#はかなりマシ 一般的に上級者は初心者向けの説明なんて書きたくないものだが、 プログラミング自体について語りたい連中も多少はおり、そいつらを上手く取り込んでる 717 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 17:59:34.28 ID:4h95DB/2.net] >>715 上っ面だけのクラスベース。 内容はプロトタイプのまま。 718 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 18:08:44.18 ID:PnBrsUGe.net] 上っ面といってもそこで整合とれていて内部の問題が表に現れないなら別に問題ないと思うが。 まぁ、中途半端というなら何かそういう部分が見えているということなんだろうが。 719 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 18:30:25.89 ID:oeLmweY9.net] 定期的に呟いてる人だから気にせんでいいよ 720 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 18:50:24.76 ID:PmcDL+gd.net] >>717 オブジェクト指向的センスが無いと言う事だね 今の時代、両方出来ないとプロだと厳しいと思うがね 721 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 18:55:49.66 ID:S+a9i6vw.net] プロトタイプの方が表現出来る空間が広くて、実際にただの糖衣構文でクラスを実装出来てるだけだろ クラスで閉じて使ってる限りプロトタイプの側面は見えないはずだが 混ぜて使うのってありだっけ？(class宣言した物にgetPrototypeOfとか) class構文の時にどうプロトタイプが配置されるか仕様で確定してないと駄目だと思うが、これってしてるのか？ 722 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 19:35:46.48 ID:kUhTwtcg.net] GoやRustなんかの新しい言語がクラスベースのオブジェクト指向を採用しないご時世 時代遅れとなったC++やJava風のクラス構文を導入する必要はなかったわな TC39的にはES4で入れ損なったから悲願だったんだろうけど 723 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 20:25:20.58 ID:M+F+5/6j.net] プロトタイプベースのオブジェクト指向ってIDEや静的型付けと相性悪いのでは 724 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 20:48:01.50 ID:S+a9i6vw.net] >>723 仮にそうだとしても、IDEの都合を優先してプログラミング言語を簡素化するのは完全に本末転倒だろ 初心者専用のオモチャが欲しければScratchで満足しとけ 725 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 20:54:53.04 ID:M+F+5/6j.net] >>724 既存との互換を保ったまま機能追加されてるわけだから言語自体は簡素化されたのてはなく複雑化されたのでは それはさておき従来の機能が使えなくなるわけでもなく何が不満なのかわからない 726 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 21:02:39.16 ID:4h95DB/2.net] >>721 してない。 だから細かい設定が解りづらい。 727 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 21:18:20.64 ID:S+a9i6vw.net] >>725 糖衣構文を導入した分言語は複雑化してるし、IDEも余計に対応する必要がある。 IDEを優先するなら何もしないのが最善。 （もちろん仕様を削れるのが最善だが、JSの場合はこれはかなり無理なので） >>726 仕様で確定してないのなら、混ぜて使う事は禁止だし、 クラスで閉じて使う分にはプロトタイプベースは見えないから問題ないだろ。 何を問題視してる？ 728 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 21:26:19.15 ID:PIvfFszt.net] >>726 ECMAScriptの仕様書も読んだことない低脳が堂々と嘘を書くなよ ES2020の14.6.12 729 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 21:33:51.63 ID:PIvfFszt.net] >>728 自己レス「ES2020の14.6.13」の書き間違い 730 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 22:43:28.35 ID:M+F+5/6j.net] >>727 そもそもプロトタイプベースの方が静的解析難しいからちゃんと補完できるIDE作るの難しいと思うよ 例えばプロトタイプベースでtypescript作れるかというと結局クラス宣言的な物を導入せざるを得ないと思う 構文解析なんかは大して難しい話ではない 731 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 22:59:58.91 ID:vgGpFQt6.net] 実際にTypeScriptはinterface導入してるし何も問題ないだろ 732 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 23:27:54.98 ID:S+a9i6vw.net] >>730 最終的に何が言いたいのかさっぱり分からんが、既に言ったとおり、 IDEの都合でプログラミング言語の仕様を決めるものではない。それは逆だ。 プロトタイプベースではIDEを構成出来ないからクラスベースを導入した、と考えてるのなら、上記の通り。 IDEの為にプロトタイプベースを廃止してクラスベースに一本化すべき、でも上記の通りだし、JSでは無理。 IDEの為にクラス構文なんてそもそも導入すべきではなかった、と考えてるのなら、それもありだし個人的には賛成だが、 一般論としては現在の、メジャー言語でほぼクラス導入済みの状況で、JSだけ不採用も、メジャー言語としては難しい。 GoやRustは今も今後ともマイナー言語でしかないし、勝手にやってろでしかない。 静的解析自体はクラスの方が簡単だろうけど、だからどうしたでしかない。 実行エンジンはあるのだから、実装難易度の上限は実行エンジンを実装する程度でしかなく、出来る範囲だ。 最悪、実行エンジンをそのままコールして結果を得る事も出来る。Flycheckとかそういう構造のように見えるけど。 ちなみにTSが型を導入したのも、IDEを作るためではなく、 プログラマが型を明示的に示す事によって、間抜けなエラーを静的に検出するためだぞ。 そこにIDEが勝手に乗っかっただけであって、IDEが無くとも型の導入自体は意味も効果もある。 型無し言語出身者は型をIDEでの補完をするための物だと勘違いしてるが、そうじゃない。 733 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 00:11:53.01 ID:Btn3kp2t.net] >>732 言いたかったこととしてはプロトタイプベースがクラスベースの機能包含しているとしても 静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ 実行エンジンを実装してもあらゆるパスが評価できるわけでないので宣言的記法の方に軍配が上がると思うが 実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？ flycheckってemacsのパッケージのことだと思うけどあれも静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？ IDEのためだけではないというのはその通りで、途中から略して書いてしまっているが >>723 ではIDEや静的解析といっている 734 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 05:27:18.08 ID:5b2Vj92V.net] >>733 > 静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ IDEの「実装」をプログラミング言語の「仕様」比較（スーパーセットかどうか）に含めるのがおかしい。 それは「○○は△△のスーパーセットではない。なぜなら『僕が』それを『実装』出来ないから」と言ってるのと同じだろ。 IDEは開発をサポートする道具であり、サポート対象はプログラミング言語だ。 よって、仕様上どんなに構文解釈が難しかろうが、必要ならやるしかないし、それだけだよ。 上下関係で言えばプログラミング言語の『仕様』が完全に上であって、 IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。 > 静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？ 俺が使ったのはGoだけど、見た目は実際にコンパイルを走らせてそれをアノテートしてただけ。 でも確かにこれが一番生産性が高いんだよ。 当たり前だが、コンパイラはエラー時には何行目の何文字目でこけた、という情報を持ってる。 だから静的解析が目的ではなく、ソースコード作成時にエラーを表示する事が目的なら、これでいいんだよ。 最大のメリットは構文解釈を自前で実装する必要がない事。 構文解釈機の再開発をやめ、本体コンパイラのエラー情報をより詳細に出す事にリソースを突っ込み、 IDE側はその詳しいエラー情報を解釈してアノテートするだけに徹する。 これで言語側の仕様変更に自動的に追従するようになる。 IDEの数だけ構文解釈機を再開発するのは手段が目的化してる。 > 実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？ Flycheckは外部から呼んでるだけ。でもそれでコンパイラが吐くエラー（=静的エラー）は全て検出出来る。 しかも自前の実装もなしだから、最も生産性が高い。 自前の構文解釈機でコンパイラ/ビルドシステム以上のエラーを検出する気なら、 それはIDEではなくリンターと呼ぶべきだが、 それが出来るのなら、コンパイラ/ビルドシステムにそのリンターを内包して、 IDEはそのエラーを表示する事に徹するのが最も生産性が高い。 IDEで構文解釈するのではなく、エラーを出来るだけ早い段階で検出して修正するのが目的だから。 735 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 08:32:17.24 ID:Btn3kp2t.net] >>734 > IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。 なぜそうあるべきなのですか？ 近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？ なぜか構文解析の話になっていますが意図してたのはintellisenseのような意味解析が必要な機能です プロトタイプベースの記法では解析のためにコードの実行パスを追いかけプロトタイプの設定箇所を検出しなければならないのに対して 宣言的記法であればスコープ内のクラス宣言を見ればだいたい事足りるので実装難易度は大幅に異なるかと 736 名前：デフォルトの名無しさん [2021/12/27(月) 09:13:46.85 ID:mFj7RPUl.net] 今時プロトタイプベースがぁ、って言ってるのが時代遅れじゃねーの。 クラスベースじゃないからってRustやGoを出してるがそれらはプロトタイプベースですらないわけで。 737 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 09:41:04.48 ID:VqPkBZyA.net] >>736 >>722はクラスベースを時代遅れと書いたんだが ぶっちゃけオブジェクト指向が過去のものになってきてるのみんな分かってるだろ 738 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 10:22:30.58 ID:5b2Vj92V.net] >>735 > 近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが 「多い」というのならまず具体的に名前を複数挙げてみろ。 出来なければそれは君の妄想だね。 > また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？ 違うぞ。それは今の話に関係ない。（どっちでもいい） > 意図してたのはintellisenseのような意味解析が必要な機能です だから何？これも君の考えが間違ってる。 flycheckのやり方でも原理的にインテリセンスは出来るんだよ。 インテリセンスで出なかったキーワードだとコンパイルエラーになるのなら、 仮にコンパイラが無限に速ければ、ソース内の全キーワードで試せば、コンパイルが通るキーワードのリストは得られる。 実際こんな事をしてる物はないと思うが、構文解釈で100%絞る必要なんて無くて、 候補が数個程度なら全部試してエラーが出なかった物を出す程度でも十分実用的なんだよ。 今時emacsでもインテリセンスするようだから、そんなにIDEが気になるのなら、彼等のアプローチを確認してみるといいよ。 全言語向けに自前でやってる事なんてないと思うよ。 プロトタイプを自分で追うのが技術的に無理なら、evalさせてgetPrototypeOfやinstanceofを使って追えばいいだけ。 自前の構文解釈器でソースからデータツリー構築をする気だからおかしくなる。 それはevalすれば実行エンジン内に構築されるものでしかないのだから、完全に再開発だろ。 eval出来る環境があり、それが一番近道なら、やればいいだけ。 君は多分「生産性」を勘違いしてる。 むしろ再開発しすぎてるし。 現状どうなってるのか知らないのだけど、メジャーなIDE、 例えばVSCodeとかだとクラスベースならインテリセンス出来るが、プロトタイプベースだと無理とかなのか？ 誰か使ってたら教えてくれ。 739 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 10:51:32.02 ID:gEDfakwV.net] ×クラスベース ○クラス構文 クラス構文で書いてもプロトタイプベースなのは変わらん 740 名前：デフォルトの名無しさん [2021/12/27(月) 11:21:14.15 ID:mFj7RPUl.net] >>737 確かにクラスベースがってよりオブジェクト指向が時代遅れって感じだね。 JS自体は関数プログラミングもいける。 741 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 11:22:05.04 ID:lxgQYw9b.net] 言語仕様も分かってないIDEも使ってない部外者の素人同士が長文レスバって地獄だな 742 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 11:54:45.10 ID:Btn3kp2t.net] >>738 > 「多い」というのならまず具体的に名前を複数挙げてみろ。 例えばgolangやrustはコアチームがツール開発に積極的ですね ツールのチームがコア言語に対してフィードバックしていたりする > eval出来る環境があり、それが一番近道なら、やればいいだけ。 "構文解釈機" という言葉を使っているから静的解析を意図してるのかと思ったけど動的解析も含んで言っていたのね それで実用に耐えうる速度と精度が実現できるならそういうアプローチもありかもね それから別にIDEが自前で静的解析器を開発すべきなんて主張はしてないから藁人形論法はやめてくれ >>740 オブジェクト指向というか継承が忌避されてる気はする 743 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 12:21:31.31 ID:VwNgBMvN.net] オブジェクト指向ならではの筆頭が継承だから継承が忌避されてる＝オブジェクト指向が忌避されてるってことよ OOPLが提供していた継承以外の特性の多く(カプセル化など)は抽象データ型から来ていてそれは時代遅れになってないし忌避されてもいない 744 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 13:11:44.45 ID:+2NyFcdP.net] クラスの定義だけど、 classとfunctionを混在した書き方でも問題ないの？ 745 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 13:40:18.86 ID:Uq9DqbRx.net] >>744 混在した書き方っての次第だが class A {} A.prototype.x = () => {} a = new A() a.x() こんなのは当たり前に動くぞ つかまずは自分で試せよw JSなんかブラウザあれば動かせるんだからさー 746 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 15:00:45.57 ID:5b2Vj92V.net] >>742 > 例えばgolangやrustはコアチームがツール開発に積極的ですね それで、それらの言語のどの仕様がIDEの都合で採用されたものなの？ > 藁人形論法はやめてくれ なら最初から分かるように主張しろ。 何が言いたいか分からないからエスパーして複数挙げてみただけ。 馬鹿は無視してきっちり自分の意見を書ききれ。 3行しか読めない馬鹿はプログラミングなんてどうやっても出来ない。 MDNその他のリファレンス見りゃ分かるが、そんな世界じゃない。 5ch程度の文にすら手こずるようではどだい無理だよ。 解釈が動的か静的かは意味無い。 出来るだけ早い段階でエラーを検出して修正したいだけであって、それが出来れば何だっていいんだよ。 その手段の一つが静的解析でソース作成時にエラーを表示する事であって。 でも、エラー表示だけなら、コンパイラやevalにぶち込めば出来るし、それをやってるっぽいのがflycheck。 構文解釈器を自前で作るとしても、クラス構文でもプロトタイプ構文でも、大して難易度は変わらない気もするが。 実際に問題になるのは、構文解釈そのもの、具体的にはJS的な様々な書き方でも問題なく動くパーサの構成だろ。 構文解釈後の親class/プロトタイプ追跡なんて辿ればいいだけだからアホでも出来る。 それで今時のIDEで実際どうなのか聞いたんだよ。 もしプロトタイプ構文ではインテリセンスが動かないのなら、何か理由はあるのだろうけど。 継承が忌避されてるのは、JAVAでは関数ポインタが使えず、同様の事をするためには継承をこねくり回すしかなくて、 それの残骸がデザインパターンなのだが、 結果、継承すべきでない局面での継承で酷い事になってるからだよ。 でも、継承すべき場所では継承した方がよくて、全部捨ててるGoはいちいち全部書かないといけないのが糞。 あれは1周目はまだしも、2周目以降でそのコピペされたソースにメンテコストがかかるから、先すぼみになると予想してる。 Rustはやってないから知らん。 747 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 15:36:34.22 ID:KDGmbGA4.net] 何言ってるか分からない相手にエスパーして反論って藁人形そのもので完全に異常者 748 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 15:55:56.69 ID:h2/Ma5NI.net] いい加減スレチだから他所でやってもらえんかね このスレ伸ばすにしてもnodeにScheduling APIが入ったとか普通にネタあるだろ 749 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 16:04:01.18 ID:XkNPDe9x.net] 最近アツいサーバサイドJSはnodeよりもdenoよりもCloudflare Workers 750 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 16:21:39.89 ID:U0LFk7o9.net] denoって全然使われてないの？ 751 名前：デフォルトの名無しさん mailto:sage [2021/12/27(月) 16:28:54.26 ID:XkNPDe9x.net] denoは苦戦してるみたいだねー それでexpressなどnode用のライブラリが動くように互換性を高める方針になった でもそれならnode使い続ければいいやってなりそう 752 名前：デフォルトの名無しさん [2022/01/05(水) 00:01:04.66 ID:XksPZRYQ.net] puppeteerを使って投票サイトの投票を自動化したいのだけど、 実行してもエラーを起こさず無反応なんだよね Headless Recorerを使ってるからHTML部分の間違いはないと思うのだけど、 UserAgent以外で何か対策ないっすかね 753 名前：デフォルトの名無しさん mailto:sage [2022/01/05(水) 00:22:23.97 ID:n516+jFB.net] いくらでも試すことはあるけど悪事の片棒を担ぎそうで怖いな 一般論として言えるのはpuppeteerでも普通にWebページのコンテキストからDOM APIを叩ける 754 名前：デフォルトの名無しさん [2022/01/05(水) 00:33:19.61 ID:XksPZRYQ.net] んじゃ、逆にWEBサイトを作る側はどんな対策をしているのでしょうか？ 755 名前：デフォルトの名無しさん mailto:sage [2022/01/05(水) 10:54:49.76 ID:4mwV9n2W.net] reCAPTCHA使ってんじゃない？ 756 名前：デフォルトの名無しさん [2022/01/05(水) 15:02:25.17 ID:XksPZRYQ.net] >>755 使ってるところは諦めてるんだけど、使ってないところはどうやってるのかな〜と思って UserAgentをガラケーにしてみたり、プレステにしても無反応なんだよね 757 名前：デフォルトの名無しさん mailto:sage [2022/01/05(水) 15:47:16.38 ID:w42D9Ab/.net] 手動で操作した時のリクエストヘッダーの中身を解析して 間違いなく妥当なリクエストが投げられてるのが大前提 あとは“how to detect headless browser”でググるといいよ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef