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

【node.js】サーバサイドjavascript 5【Nashorn】 (796ﾚｽ)
上下前次1-新
抽出解除必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞あぼーん

708: デフォルトの名無しさん [sage] 2021/12/26(日) 09:04:50.48 ID:S+a9i6vw(1/6) AAS
それを言ったらWeb系言語は全部デタラメ解説で駄目だろ
初心者が情報公開の練習として解説を書くからそうなる

713: デフォルトの名無しさん [sage] 2021/12/26(日) 13:40:10.35 ID:S+a9i6vw(2/6) AAS
>>709

709(1): デフォルトの名無しさん [sage] 2021/12/26(日) 10:12:00.53 ID:6ScHvZpk(1) AAS
それはしゃーない、正確さにこだわりすぎて萎縮する方がデメリットが大きい
読む方が気を付けて取捨選択するしかない

同意だが、C#はかなりマシ
一般的に上級者は初心者向けの説明なんて書きたくないものだが、
プログラミング自体について語りたい連中も多少はおり、そいつらを上手く取り込んでる

718(1): デフォルトの名無しさん [sage] 2021/12/26(日) 18:55:49.66 ID:S+a9i6vw(3/6) AAS
プロトタイプの方が表現出来る空間が広くて、実際にただの糖衣構文でクラスを実装出来てるだけだろ
クラスで閉じて使ってる限りプロトタイプの側面は見えないはずだが

混ぜて使うのってありだっけ？(class宣言した物にgetPrototypeOfとか)
class構文の時にどうプロトタイプが配置されるか仕様で確定してないと駄目だと思うが、これってしてるのか？

721(1): デフォルトの名無しさん [sage] 2021/12/26(日) 20:48:01.50 ID:S+a9i6vw(4/6) AAS
>>720

720(2): デフォルトの名無しさん [sage] 2021/12/26(日) 20:25:20.58 ID:M+F+5/6j(1/3) AAS
プロトタイプベースのオブジェクト指向ってIDEや静的型付けと相性悪いのでは

仮にそうだとしても、IDEの都合を優先してプログラミング言語を簡素化するのは完全に本末転倒だろ
初心者専用のオモチャが欲しければScratchで満足しとけ

724(1): デフォルトの名無しさん [sage] 2021/12/26(日) 21:18:20.64 ID:S+a9i6vw(5/6) AAS
>>722

722(1): デフォルトの名無しさん [sage] 2021/12/26(日) 20:54:53.04 ID:M+F+5/6j(2/3) AAS
>>721
既存との互換を保ったまま機能追加されてるわけだから言語自体は簡素化されたのてはなく複雑化されたのでは
それはさておき従来の機能が使えなくなるわけでもなく何が不満なのかわからない

糖衣構文を導入した分言語は複雑化してるし、IDEも余計に対応する必要がある。
IDEを優先するなら何もしないのが最善。
（もちろん仕様を削れるのが最善だが、JSの場合はこれはかなり無理なので）

>>723

723(2): デフォルトの名無しさん [sage] 2021/12/26(日) 21:02:39.16 ID:4h95DB/2(3/3) AAS
>>718
してない。
だから細かい設定が解りづらい。

仕様で確定してないのなら、混ぜて使う事は禁止だし、
クラスで閉じて使う分にはプロトタイプベースは見えないから問題ないだろ。
何を問題視してる？

729(1): デフォルトの名無しさん [sage] 2021/12/26(日) 23:27:54.98 ID:S+a9i6vw(6/6) AAS
>>727

727(1): デフォルトの名無しさん [sage] 2021/12/26(日) 22:43:28.35 ID:M+F+5/6j(3/3) AAS
>>724
そもそもプロトタイプベースの方が静的解析難しいからちゃんと補完できるIDE作るの難しいと思うよ
例えばプロトタイプベースでtypescript作れるかというと結局クラス宣言的な物を導入せざるを得ないと思う
構文解析なんかは大して難しい話ではない

最終的に何が言いたいのかさっぱり分からんが、既に言ったとおり、
IDEの都合でプログラミング言語の仕様を決めるものではない。それは逆だ。

プロトタイプベースではIDEを構成出来ないからクラスベースを導入した、と考えてるのなら、上記の通り。
IDEの為にプロトタイプベースを廃止してクラスベースに一本化すべき、でも上記の通りだし、JSでは無理。
IDEの為にクラス構文なんてそもそも導入すべきではなかった、と考えてるのなら、それもありだし個人的には賛成だが、
一般論としては現在の、メジャー言語でほぼクラス導入済みの状況で、JSだけ不採用も、メジャー言語としては難しい。
GoやRustは今も今後ともマイナー言語でしかないし、勝手にやってろでしかない。

静的解析自体はクラスの方が簡単だろうけど、だからどうしたでしかない。
実行エンジンはあるのだから、実装難易度の上限は実行エンジンを実装する程度でしかなく、出来る範囲だ。
最悪、実行エンジンをそのままコールして結果を得る事も出来る。Flycheckとかそういう構造のように見えるけど。

ちなみにTSが型を導入したのも、IDEを作るためではなく、
プログラマが型を明示的に示す事によって、間抜けなエラーを静的に検出するためだぞ。
そこにIDEが勝手に乗っかっただけであって、IDEが無くとも型の導入自体は意味も効果もある。
型無し言語出身者は型をIDEでの補完をするための物だと勘違いしてるが、そうじゃない。

上下前次1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.032s