【node.js】サーバサイドjavascript 5【Nashorn】 (796ﾚｽ)
【node.js】サーバサイドjavascript 5【Nashorn】 http://mevius.5ch.net/test/read.cgi/tech/1518528093/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
731: デフォルトの名無しさん [sage] 2021/12/27(月) 05:27:18.08 ID:5b2Vj92V >>730 > 静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ IDEの「実装」をプログラミング言語の「仕様」比較（スーパーセットかどうか）に含めるのがおかしい。 それは「○○は△△のスーパーセットではない。なぜなら『僕が』それを『実装』出来ないから」と言ってるのと同じだろ。 IDEは開発をサポートする道具であり、サポート対象はプログラミング言語だ。 よって、仕様上どんなに構文解釈が難しかろうが、必要ならやるしかないし、それだけだよ。 上下関係で言えばプログラミング言語の『仕様』が完全に上であって、 IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。 > 静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？ 俺が使ったのはGoだけど、見た目は実際にコンパイルを走らせてそれをアノテートしてただけ。 でも確かにこれが一番生産性が高いんだよ。 当たり前だが、コンパイラはエラー時には何行目の何文字目でこけた、という情報を持ってる。 だから静的解析が目的ではなく、ソースコード作成時にエラーを表示する事が目的なら、これでいいんだよ。 最大のメリットは構文解釈を自前で実装する必要がない事。 構文解釈機の再開発をやめ、本体コンパイラのエラー情報をより詳細に出す事にリソースを突っ込み、 IDE側はその詳しいエラー情報を解釈してアノテートするだけに徹する。 これで言語側の仕様変更に自動的に追従するようになる。 IDEの数だけ構文解釈機を再開発するのは手段が目的化してる。 > 実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？ Flycheckは外部から呼んでるだけ。でもそれでコンパイラが吐くエラー（=静的エラー）は全て検出出来る。 しかも自前の実装もなしだから、最も生産性が高い。 自前の構文解釈機でコンパイラ/ビルドシステム以上のエラーを検出する気なら、 それはIDEではなくリンターと呼ぶべきだが、 それが出来るのなら、コンパイラ/ビルドシステムにそのリンターを内包して、 IDEはそのエラーを表示する事に徹するのが最も生産性が高い。 IDEで構文解釈するのではなく、エラーを出来るだけ早い段階で検出して修正するのが目的だから。 http://mevius.5ch.net/test/read.cgi/tech/1518528093/731
735: デフォルトの名無しさん [sage] 2021/12/27(月) 10:22:30.58 ID:5b2Vj92V >>732 > 近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが 「多い」というのならまず具体的に名前を複数挙げてみろ。 出来なければそれは君の妄想だね。 > また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？ 違うぞ。それは今の話に関係ない。（どっちでもいい） > 意図してたのはintellisenseのような意味解析が必要な機能です だから何？これも君の考えが間違ってる。 flycheckのやり方でも原理的にインテリセンスは出来るんだよ。 インテリセンスで出なかったキーワードだとコンパイルエラーになるのなら、 仮にコンパイラが無限に速ければ、ソース内の全キーワードで試せば、コンパイルが通るキーワードのリストは得られる。 実際こんな事をしてる物はないと思うが、構文解釈で100%絞る必要なんて無くて、 候補が数個程度なら全部試してエラーが出なかった物を出す程度でも十分実用的なんだよ。 今時emacsでもインテリセンスするようだから、そんなにIDEが気になるのなら、彼等のアプローチを確認してみるといいよ。 全言語向けに自前でやってる事なんてないと思うよ。 プロトタイプを自分で追うのが技術的に無理なら、evalさせてgetPrototypeOfやinstanceofを使って追えばいいだけ。 自前の構文解釈器でソースからデータツリー構築をする気だからおかしくなる。 それはevalすれば実行エンジン内に構築されるものでしかないのだから、完全に再開発だろ。 eval出来る環境があり、それが一番近道なら、やればいいだけ。 君は多分「生産性」を勘違いしてる。 むしろ再開発しすぎてるし。 現状どうなってるのか知らないのだけど、メジャーなIDE、 例えばVSCodeとかだとクラスベースならインテリセンス出来るが、プロトタイプベースだと無理とかなのか？ 誰か使ってたら教えてくれ。 http://mevius.5ch.net/test/read.cgi/tech/1518528093/735
743: デフォルトの名無しさん [sage] 2021/12/27(月) 15:00:45.57 ID:5b2Vj92V >>739 > 例えばgolangやrustはコアチームがツール開発に積極的ですね それで、それらの言語のどの仕様がIDEの都合で採用されたものなの？ > 藁人形論法はやめてくれ なら最初から分かるように主張しろ。 何が言いたいか分からないからエスパーして複数挙げてみただけ。 馬鹿は無視してきっちり自分の意見を書ききれ。 3行しか読めない馬鹿はプログラミングなんてどうやっても出来ない。 MDNその他のリファレンス見りゃ分かるが、そんな世界じゃない。 5ch程度の文にすら手こずるようではどだい無理だよ。 解釈が動的か静的かは意味無い。 出来るだけ早い段階でエラーを検出して修正したいだけであって、それが出来れば何だっていいんだよ。 その手段の一つが静的解析でソース作成時にエラーを表示する事であって。 でも、エラー表示だけなら、コンパイラやevalにぶち込めば出来るし、それをやってるっぽいのがflycheck。 構文解釈器を自前で作るとしても、クラス構文でもプロトタイプ構文でも、大して難易度は変わらない気もするが。 実際に問題になるのは、構文解釈そのもの、具体的にはJS的な様々な書き方でも問題なく動くパーサの構成だろ。 構文解釈後の親class/プロトタイプ追跡なんて辿ればいいだけだからアホでも出来る。 それで今時のIDEで実際どうなのか聞いたんだよ。 もしプロトタイプ構文ではインテリセンスが動かないのなら、何か理由はあるのだろうけど。 継承が忌避されてるのは、JAVAでは関数ポインタが使えず、同様の事をするためには継承をこねくり回すしかなくて、 それの残骸がデザインパターンなのだが、 結果、継承すべきでない局面での継承で酷い事になってるからだよ。 でも、継承すべき場所では継承した方がよくて、全部捨ててるGoはいちいち全部書かないといけないのが糞。 あれは1周目はまだしも、2周目以降でそのコピペされたソースにメンテコストがかかるから、先すぼみになると予想してる。 Rustはやってないから知らん。 http://mevius.5ch.net/test/read.cgi/tech/1518528093/743
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.033s