【node.js】サーバサイドjavascript 5【Nashorn】 (796ﾚｽ)
上下前次1-新
719(1): 2021/12/26(日)19:35 ID:kUhTwtcg(1) AAS
GoやRustなんかの新しい言語がクラスベースのオブジェクト指向を採用しないご時世
時代遅れとなったC++やJava風のクラス構文を導入する必要はなかったわな
TC39的にはES4で入れ損なったから悲願だったんだろうけど
720(2): 2021/12/26(日)20:25 ID:M+F+5/6j(1/3) AAS
プロトタイプベースのオブジェクト指向ってIDEや静的型付けと相性悪いのでは
721(1): 2021/12/26(日)20:48 ID:S+a9i6vw(4/6) AAS
>>720
仮にそうだとしても、IDEの都合を優先してプログラミング言語を簡素化するのは完全に本末転倒だろ
初心者専用のオモチャが欲しければScratchで満足しとけ
722(1): 2021/12/26(日)20:54 ID:M+F+5/6j(2/3) AAS
>>721
既存との互換を保ったまま機能追加されてるわけだから言語自体は簡素化されたのてはなく複雑化されたのでは
それはさておき従来の機能が使えなくなるわけでもなく何が不満なのかわからない
723(2): 2021/12/26(日)21:02 ID:4h95DB/2(3/3) AAS
>>718
してない。
だから細かい設定が解りづらい。
724(1): 2021/12/26(日)21:18 ID:S+a9i6vw(5/6) AAS
>>722
糖衣構文を導入した分言語は複雑化してるし、IDEも余計に対応する必要がある。
IDEを優先するなら何もしないのが最善。
（もちろん仕様を削れるのが最善だが、JSの場合はこれはかなり無理なので）
>>723
仕様で確定してないのなら、混ぜて使う事は禁止だし、
クラスで閉じて使う分にはプロトタイプベースは見えないから問題ないだろ。
何を問題視してる？
725(1): 2021/12/26(日)21:26 ID:PIvfFszt(1/2) AAS
>>723
ECMAScriptの仕様書も読んだことない低脳が堂々と嘘を書くなよ
ES2020の14.6.12
726: 2021/12/26(日)21:33 ID:PIvfFszt(2/2) AAS
>>725
自己レス「ES2020の14.6.13」の書き間違い
727(1): 2021/12/26(日)22:43 ID:M+F+5/6j(3/3) AAS
>>724
そもそもプロトタイプベースの方が静的解析難しいからちゃんと補完できるIDE作るの難しいと思うよ
例えばプロトタイプベースでtypescript作れるかというと結局クラス宣言的な物を導入せざるを得ないと思う
構文解析なんかは大して難しい話ではない
728: 2021/12/26(日)22:59 ID:vgGpFQt6(1) AAS
実際にTypeScriptはinterface導入してるし何も問題ないだろ
729(1): 2021/12/26(日)23:27 ID:S+a9i6vw(6/6) AAS
>>727
最終的に何が言いたいのかさっぱり分からんが、既に言ったとおり、
IDEの都合でプログラミング言語の仕様を決めるものではない。それは逆だ。
プロトタイプベースではIDEを構成出来ないからクラスベースを導入した、と考えてるのなら、上記の通り。
IDEの為にプロトタイプベースを廃止してクラスベースに一本化すべき、でも上記の通りだし、JSでは無理。
IDEの為にクラス構文なんてそもそも導入すべきではなかった、と考えてるのなら、それもありだし個人的には賛成だが、
一般論としては現在の、メジャー言語でほぼクラス導入済みの状況で、JSだけ不採用も、メジャー言語としては難しい。
GoやRustは今も今後ともマイナー言語でしかないし、勝手にやってろでしかない。
静的解析自体はクラスの方が簡単だろうけど、だからどうしたでしかない。
実行エンジンはあるのだから、実装難易度の上限は実行エンジンを実装する程度でしかなく、出来る範囲だ。
最悪、実行エンジンをそのままコールして結果を得る事も出来る。Flycheckとかそういう構造のように見えるけど。
ちなみにTSが型を導入したのも、IDEを作るためではなく、
プログラマが型を明示的に示す事によって、間抜けなエラーを静的に検出するためだぞ。
そこにIDEが勝手に乗っかっただけであって、IDEが無くとも型の導入自体は意味も効果もある。
型無し言語出身者は型をIDEでの補完をするための物だと勘違いしてるが、そうじゃない。
730(1): 2021/12/27(月)00:11 ID:Btn3kp2t(1/3) AAS
>>729
言いたかったこととしてはプロトタイプベースがクラスベースの機能包含しているとしても
静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ
実行エンジンを実装してもあらゆるパスが評価できるわけでないので宣言的記法の方に軍配が上がると思うが
実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？
flycheckってemacsのパッケージのことだと思うけどあれも静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？
IDEのためだけではないというのはその通りで、途中から略して書いてしまっているが >>720 ではIDEや静的解析といっている
731(1): 2021/12/27(月)05:27 ID:5b2Vj92V(1/3) AAS
>>730
> 静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ
IDEの「実装」をプログラミング言語の「仕様」比較（スーパーセットかどうか）に含めるのがおかしい。
それは「○○は△△のスーパーセットではない。なぜなら『僕が』それを『実装』出来ないから」と言ってるのと同じだろ。
IDEは開発をサポートする道具であり、サポート対象はプログラミング言語だ。
よって、仕様上どんなに構文解釈が難しかろうが、必要ならやるしかないし、それだけだよ。
上下関係で言えばプログラミング言語の『仕様』が完全に上であって、
IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。
> 静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？
俺が使ったのはGoだけど、見た目は実際にコンパイルを走らせてそれをアノテートしてただけ。
でも確かにこれが一番生産性が高いんだよ。
当たり前だが、コンパイラはエラー時には何行目の何文字目でこけた、という情報を持ってる。
だから静的解析が目的ではなく、ソースコード作成時にエラーを表示する事が目的なら、これでいいんだよ。
最大のメリットは構文解釈を自前で実装する必要がない事。
構文解釈機の再開発をやめ、本体コンパイラのエラー情報をより詳細に出す事にリソースを突っ込み、
IDE側はその詳しいエラー情報を解釈してアノテートするだけに徹する。
これで言語側の仕様変更に自動的に追従するようになる。
IDEの数だけ構文解釈機を再開発するのは手段が目的化してる。
> 実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？
Flycheckは外部から呼んでるだけ。でもそれでコンパイラが吐くエラー（=静的エラー）は全て検出出来る。
しかも自前の実装もなしだから、最も生産性が高い。
自前の構文解釈機でコンパイラ/ビルドシステム以上のエラーを検出する気なら、
それはIDEではなくリンターと呼ぶべきだが、
それが出来るのなら、コンパイラ/ビルドシステムにそのリンターを内包して、
IDEはそのエラーを表示する事に徹するのが最も生産性が高い。
IDEで構文解釈するのではなく、エラーを出来るだけ早い段階で検出して修正するのが目的だから。
732(1): 2021/12/27(月)08:32 ID:Btn3kp2t(2/3) AAS
>>731
> IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。
なぜそうあるべきなのですか？
近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが
また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？
なぜか構文解析の話になっていますが意図してたのはintellisenseのような意味解析が必要な機能です
プロトタイプベースの記法では解析のためにコードの実行パスを追いかけプロトタイプの設定箇所を検出しなければならないのに対して
宣言的記法であればスコープ内のクラス宣言を見ればだいたい事足りるので実装難易度は大幅に異なるかと
733(1): 2021/12/27(月)09:13 ID:mFj7RPUl(1/2) AAS
今時プロトタイプベースがぁ、って言ってるのが時代遅れじゃねーの。
クラスベースじゃないからってRustやGoを出してるがそれらはプロトタイプベースですらないわけで。
734(1): 2021/12/27(月)09:41 ID:VqPkBZyA(1) AAS
>>733
>>719はクラスベースを時代遅れと書いたんだが
ぶっちゃけオブジェクト指向が過去のものになってきてるのみんな分かってるだろ
735(1): 2021/12/27(月)10:22 ID:5b2Vj92V(2/3) AAS
>>732
> 近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが
「多い」というのならまず具体的に名前を複数挙げてみろ。
出来なければそれは君の妄想だね。
> また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？
違うぞ。それは今の話に関係ない。（どっちでもいい）
> 意図してたのはintellisenseのような意味解析が必要な機能です
だから何？これも君の考えが間違ってる。
flycheckのやり方でも原理的にインテリセンスは出来るんだよ。
インテリセンスで出なかったキーワードだとコンパイルエラーになるのなら、
仮にコンパイラが無限に速ければ、ソース内の全キーワードで試せば、コンパイルが通るキーワードのリストは得られる。
実際こんな事をしてる物はないと思うが、構文解釈で100%絞る必要なんて無くて、
候補が数個程度なら全部試してエラーが出なかった物を出す程度でも十分実用的なんだよ。
今時emacsでもインテリセンスするようだから、そんなにIDEが気になるのなら、彼等のアプローチを確認してみるといいよ。
全言語向けに自前でやってる事なんてないと思うよ。
プロトタイプを自分で追うのが技術的に無理なら、evalさせてgetPrototypeOfやinstanceofを使って追えばいいだけ。
自前の構文解釈器でソースからデータツリー構築をする気だからおかしくなる。
それはevalすれば実行エンジン内に構築されるものでしかないのだから、完全に再開発だろ。
eval出来る環境があり、それが一番近道なら、やればいいだけ。
君は多分「生産性」を勘違いしてる。
むしろ再開発しすぎてるし。
現状どうなってるのか知らないのだけど、メジャーなIDE、
例えばVSCodeとかだとクラスベースならインテリセンス出来るが、プロトタイプベースだと無理とかなのか？
誰か使ってたら教えてくれ。
736: 2021/12/27(月)10:51 ID:gEDfakwV(1) AAS
×クラスベース
○クラス構文
クラス構文で書いてもプロトタイプベースなのは変わらん
737(1): 2021/12/27(月)11:21 ID:mFj7RPUl(2/2) AAS
>>734
確かにクラスベースがってよりオブジェクト指向が時代遅れって感じだね。
JS自体は関数プログラミングもいける。
738: 2021/12/27(月)11:22 ID:lxgQYw9b(1) AAS
言語仕様も分かってないIDEも使ってない部外者の素人同士が長文レスバって地獄だな
上下前次1-新書関写板覧索設栞歴
あと 58 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.011s