アカウント名:
パスワード:
そもそも変換先のJavaScriptが超絶ダサい
本来「HTMLページに埋め込めるお手軽スクリプト」として意図的にゆるゆるに作られたものにヘビーなことやらせすぎ。PHPにも似たようなことがいえる
thisの一貫していない仕様とかスコープチェーンとかプロトタイプとか、規模が大きくなるとネックになるのが目に見えてる仕組みをわざわざ導入してまで「お手軽に使い捨てスクリプトを組むための言語」にしか見えないんだけど。これでヘビーな用途を想定していたって頭沸いてんのかとすら思えるわ。
あーなるほど、当初のjavascriptがモジュール化のようなことは想定していないブラウザ内という小さな環境だけを想定したものだというのは明白だと思うんだけど、そっちに直接反論せずに「javascriptに向いてないのはバカを集めて作るソフト」って定義するわけか。
こんなバカを相手にしていたとは思わなかったよ。
必ずしもヘビー=ソースコード大規模ではない。リソースヘビー、ミッションクリティカル、色々ある。
また、たとえ大規模システム開発の話に限った場合でも「型システム」の有用性はそれほどでもない。デザイン瑕疵やロジックミスによる論理的なデータの不整合には全く無力だ。検出できるのは「同じ型かどうか」だけ。で、この種のミスを数多く出すのは初心者に多い。練度が高くなっていくにつれ論理的不整合など別課題が増える傾向。
それを「バカ」なんて言葉で表すのはあまり賛成できないが、一部に流行る「型システム」万能論にはやや辟易だ。型があるから大規模に向く、
俺は型システムだけじゃなく、スコープ解決のゆるさとか、複雑さが増すとデメリットしかないプロトタイプとか、元々はモジュール的な皆無に近かったことなども指摘したんだけどな。
JSが大規模システムに不向きなのは型システムだけが理由じゃないよ。
例えばスコープですがe-lispを組んでみればそのdynamic scopeのいい加減さに驚くかもしれません。それでもあの複雑なemacsというアプリケーションができてしまいます。この場合の肝は命名規則とアクセス関数です。pythonはLEGBで規定はされていますが、実は上位objectの__get_attribute__()を修正することでいかようにも継承やスコープを変えてしまうことができます。いずれも言語の特性であり、それに合わせた設計と組み立てが必要なだけです。
「大規模システムに不向き」とおっしゃる大部分の方の意見はよく聞くと「(自分が慣れた)procedualでwaterfallで日本型開発プロジェクト的な」大規模開発には不向き、と言っているに過ぎないと思います。
「それに合わせた設計と組み立てが必要なだけです。」BasicやCOBOLにも使えそうな便利な言葉ですね
「〇〇言語に向いた大規模開発の手法があるかもしれないから大規模開発に不向きとはいえない」という主張に読めますが…
何だろうこの一生アセンブラで書いてろ感
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
JavaScriptがイケてない (スコア:0)
そもそも変換先のJavaScriptが超絶ダサい
Re: (スコア:0)
本来「HTMLページに埋め込めるお手軽スクリプト」として意図的にゆるゆるに作られたものにヘビーなことやらせすぎ。
PHPにも似たようなことがいえる
Re: (スコア:1)
埋め込みスクリプト言語って言えば常識的にlispだよねEmacsとかもそうだし、
だけどlispのまんまだとみんなカッコに拒否反応示すから、文法だけJavaに似せてみました
という言語なんだよ
最初からおよそ他の言語にできてJavaScriptにできることはないというくらいヘビーな用途を想定した言語なんだよ
Re: (スコア:0)
thisの一貫していない仕様とかスコープチェーンとかプロトタイプとか、規模が大きくなるとネックになるのが目に見えてる仕組みをわざわざ導入してまで「お手軽に使い捨てスクリプトを組むための言語」にしか見えないんだけど。
これでヘビーな用途を想定していたって頭沸いてんのかとすら思えるわ。
Re: (スコア:0)
JavaScriptは(そしてその裏側にいるlispは)そういう用途には確かに向いてない。
Re: (スコア:0)
あーなるほど、当初のjavascriptがモジュール化のようなことは想定していないブラウザ内という小さな環境だけを想定したものだというのは明白だと思うんだけど、そっちに直接反論せずに「javascriptに向いてないのはバカを集めて作るソフト」って定義するわけか。
こんなバカを相手にしていたとは思わなかったよ。
Re: (スコア:0)
必ずしもヘビー=ソースコード大規模ではない。リソースヘビー、ミッションクリティカル、色々ある。
また、たとえ大規模システム開発の話に限った場合でも「型システム」の有用性はそれほどでもない。
デザイン瑕疵やロジックミスによる論理的なデータの不整合には全く無力だ。検出できるのは「同じ型かどうか」だけ。
で、この種のミスを数多く出すのは初心者に多い。練度が高くなっていくにつれ論理的不整合など別課題が増える傾向。
それを「バカ」なんて言葉で表すのはあまり賛成できないが、一部に流行る「型システム」万能論にはやや辟易だ。
型があるから大規模に向く、
Re: (スコア:0)
俺は型システムだけじゃなく、スコープ解決のゆるさとか、複雑さが増すとデメリットしかないプロトタイプとか、元々はモジュール的な皆無に近かったことなども指摘したんだけどな。
JSが大規模システムに不向きなのは型システムだけが理由じゃないよ。
Re:JavaScriptがイケてない (スコア:0)
例えばスコープですがe-lispを組んでみればそのdynamic scopeのいい加減さに驚くかもしれません。それでもあの複雑なemacsというアプリケーションができてしまいます。この場合の肝は命名規則とアクセス関数です。
pythonはLEGBで規定はされていますが、実は上位objectの__get_attribute__()を修正することでいかようにも継承やスコープを変えてしまうことができます。
いずれも言語の特性であり、それに合わせた設計と組み立てが必要なだけです。
「大規模システムに不向き」とおっしゃる大部分の方の意見はよく聞くと「(自分が慣れた)procedualでwaterfallで日本型開発プロジェクト的な」大規模開発には不向き、と言っているに過ぎないと思います。
Re: (スコア:0)
「それに合わせた設計と組み立てが必要なだけです。」
BasicやCOBOLにも使えそうな便利な言葉ですね
Re: (スコア:0)
「〇〇言語に向いた大規模開発の手法があるかもしれないから大規模開発に不向きとはいえない」という主張に読めますが…
何だろうこの一生アセンブラで書いてろ感