アカウント名:
パスワード:
そもそも変換先のJavaScriptが超絶ダサい
本来「HTMLページに埋め込めるお手軽スクリプト」として意図的にゆるゆるに作られたものにヘビーなことやらせすぎ。PHPにも似たようなことがいえる
> 最初からおよそ他の言語にできてJavaScriptにできることはないというくらいヘビーな用途を想定した言語なんだよ
ええっ...と、つまり何もできない??。それは確かにヘビーだ。
ヘビーか?これ以上ないくらいライトウェイトだろ
この程度の文を正しく理解できないとは、プログラム書けないだろ?
処理フロー的にはそうだけど、スクリプト系言語だから厳密な型システムは持たずダックタイピング的な使い方だよね。それはそれでメリットだけど、ヘビーな使い方をしようとすると型システムのゆるさがネックになるから後付けでクラス定義文法がつかされたり、TypeSctiptが生まれたりしたんじゃないか。
最初のころのJSがヘビーな用途を想定しながらあんな型システムを採用したのだとしたら、頭悪いなーと思うぞ
静的型付けやクラスがないと困るようなシステムはJava Appletをご利用くださいって事だったんでしょ当初の予定では
そういうのを「ヘビーな用途」と言ってるわけなんだけど…だいたい初期のJSってブラウザ以外で動かすこと想定していたの?
だから「ヘビーな用途」でJSを選ぶのがおかしいって事なのにお前らが勝手にJavaを拒否したんでしょ
へ?俺は#3765373 = #3765080で、「JSでヘビーな用途はおかしい」ってスタンスでコメントしたんだけど
thisの一貫していない仕様とかスコープチェーンとかプロトタイプとか、規模が大きくなるとネックになるのが目に見えてる仕組みをわざわざ導入してまで「お手軽に使い捨てスクリプトを組むための言語」にしか見えないんだけど。これでヘビーな用途を想定していたって頭沸いてんのかとすら思えるわ。
あーなるほど、当初のjavascriptがモジュール化のようなことは想定していないブラウザ内という小さな環境だけを想定したものだというのは明白だと思うんだけど、そっちに直接反論せずに「javascriptに向いてないのはバカを集めて作るソフト」って定義するわけか。
こんなバカを相手にしていたとは思わなかったよ。
必ずしもヘビー=ソースコード大規模ではない。リソースヘビー、ミッションクリティカル、色々ある。
また、たとえ大規模システム開発の話に限った場合でも「型システム」の有用性はそれほどでもない。デザイン瑕疵やロジックミスによる論理的なデータの不整合には全く無力だ。検出できるのは「同じ型かどうか」だけ。で、この種のミスを数多く出すのは初心者に多い。練度が高くなっていくにつれ論理的不整合など別課題が増える傾向。
それを「バカ」なんて言葉で表すのはあまり賛成できないが、一部に流行る「型システム」万能論にはやや辟易だ。型があるから大規模に向く、
PythonやJavaScriptは3000行くらいが限度かな。JavaやC++なら何万行でもいける。
必ずしも「ヘビー=大規模」ではないけど、「大規模を除外したヘビー」に限定されるものを「ヘビーでもいける」と言ってしまうのは勝手に都合のいい定義に変えてしまっていると言われても当たり前だと思う。
1ファイルの話じゃ無いよね?
WebサービスだのElectronアプリだのは大量のパッケージの塊なわけで意識せずに何万行ものコードをビルドしてるんだから、そんな上限は無いと思うよ。設計ができれば言語の違いは大した話じゃない。
(Javaの「何万行」と他の言語のそれは規模感が違う気がするけど…)
一般的な経験則として、大規模開発になればなるほど参加する人の平均値を高めるのは難しくなる訳で型システムが万能とは決して言いませんが、現代のシステム開発において「型システムが無くても大規模開発に向くか?」と聞かれたら「向きません」と答えざるを得ないです
そういう観点で、JavaScriptがヘビーな用途に向いてるかと考えたら向いてないでしょう
俺は型システムだけじゃなく、スコープ解決のゆるさとか、複雑さが増すとデメリットしかないプロトタイプとか、元々はモジュール的な皆無に近かったことなども指摘したんだけどな。
JSが大規模システムに不向きなのは型システムだけが理由じゃないよ。
手元で見ればemacs 26.0の標準ライブラリは167万行ある。Python 3.6のライブラリは119万行。当然それぞれlispとpythonで書かれている。どちらも型システムなど存在しない。また開発はネットワーク越しの共同作業であり、一ヵ所集中の開発プロジェクトですらない。
腕が悪いだけでは?
プロジェクトが大きくなるほど平均値を高めるのは難しい。その通りでしょう。ただ、平均値が下がったところでどううまくプロジェクトを成功に導くか、という対策の中で型システムの存在が占める割合はわずかだと思っています。
上位の設計の要素と、日々のプロジェクトマネジメントの要素が併せて大半でしょう。
で、Browserの中でDOC objectを対象に動くJAVAscriptの断片の話をしているのではなく、言語としての型システムなしのJAVAscriptが大規模開発に向くか、と考えています。その場合、他の言語と大差なし、と思うのです。言語特性としては特に欠けている要素は見当たりません。得手不得手の部分はありますが、総合すればC++/Java/pythonなんかとそれほど大きな差はないでしょう。
例えばスコープですがe-lispを組んでみればそのdynamic scopeのいい加減さに驚くかもしれません。それでもあの複雑なemacsというアプリケーションができてしまいます。この場合の肝は命名規則とアクセス関数です。pythonはLEGBで規定はされていますが、実は上位objectの__get_attribute__()を修正することでいかようにも継承やスコープを変えてしまうことができます。いずれも言語の特性であり、それに合わせた設計と組み立てが必要なだけです。
「大規模システムに不向き」とおっしゃる大部分の方の意見はよく聞くと「(自分が慣れた)procedualでwaterfallで日本型開発プロジェクト的な」大規模開発には不向き、と言っているに過ぎないと思います。
「それに合わせた設計と組み立てが必要なだけです。」BasicやCOBOLにも使えそうな便利な言葉ですね
「〇〇言語に向いた大規模開発の手法があるかもしれないから大規模開発に不向きとはいえない」という主張に読めますが…
何だろうこの一生アセンブラで書いてろ感
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
JavaScriptがイケてない (スコア:0)
そもそも変換先のJavaScriptが超絶ダサい
Re: (スコア:0)
本来「HTMLページに埋め込めるお手軽スクリプト」として意図的にゆるゆるに作られたものにヘビーなことやらせすぎ。
PHPにも似たようなことがいえる
Re:JavaScriptがイケてない (スコア:1)
埋め込みスクリプト言語って言えば常識的にlispだよねEmacsとかもそうだし、
だけどlispのまんまだとみんなカッコに拒否反応示すから、文法だけJavaに似せてみました
という言語なんだよ
最初からおよそ他の言語にできてJavaScriptにできることはないというくらいヘビーな用途を想定した言語なんだよ
Re:JavaScriptがイケてない (スコア:2, おもしろおかしい)
> 最初からおよそ他の言語にできてJavaScriptにできることはないというくらいヘビーな用途を想定した言語なんだよ
ええっ...と、つまり何もできない??。それは確かにヘビーだ。
Re: (スコア:0)
ヘビーか?これ以上ないくらいライトウェイトだろ
Re:JavaScriptがイケてない (スコア:1)
Re: (スコア:0)
Re: (スコア:0)
この程度の文を正しく理解できないとは、プログラム書けないだろ?
Re: (スコア:0)
処理フロー的にはそうだけど、スクリプト系言語だから厳密な型システムは持たずダックタイピング的な使い方だよね。
それはそれでメリットだけど、ヘビーな使い方をしようとすると型システムのゆるさがネックになるから後付けでクラス定義文法がつかされたり、TypeSctiptが生まれたりしたんじゃないか。
最初のころのJSがヘビーな用途を想定しながらあんな型システムを採用したのだとしたら、頭悪いなーと思うぞ
Re: (スコア:0)
静的型付けやクラスがないと困るようなシステムはJava Appletをご利用ください
って事だったんでしょ当初の予定では
Re: (スコア:0)
そういうのを「ヘビーな用途」と言ってるわけなんだけど…
だいたい初期のJSってブラウザ以外で動かすこと想定していたの?
Re: (スコア:0)
だから「ヘビーな用途」でJSを選ぶのがおかしいって事なのに
お前らが勝手にJavaを拒否したんでしょ
Re: (スコア:0)
へ?
俺は#3765373 = #3765080で、「JSでヘビーな用途はおかしい」ってスタンスでコメントしたんだけど
Re: (スコア:0)
thisの一貫していない仕様とかスコープチェーンとかプロトタイプとか、規模が大きくなるとネックになるのが目に見えてる仕組みをわざわざ導入してまで「お手軽に使い捨てスクリプトを組むための言語」にしか見えないんだけど。
これでヘビーな用途を想定していたって頭沸いてんのかとすら思えるわ。
Re: (スコア:0)
JavaScriptは(そしてその裏側にいるlispは)そういう用途には確かに向いてない。
Re: (スコア:0)
あーなるほど、当初のjavascriptがモジュール化のようなことは想定していないブラウザ内という小さな環境だけを想定したものだというのは明白だと思うんだけど、そっちに直接反論せずに「javascriptに向いてないのはバカを集めて作るソフト」って定義するわけか。
こんなバカを相手にしていたとは思わなかったよ。
Re: (スコア:0)
必ずしもヘビー=ソースコード大規模ではない。リソースヘビー、ミッションクリティカル、色々ある。
また、たとえ大規模システム開発の話に限った場合でも「型システム」の有用性はそれほどでもない。
デザイン瑕疵やロジックミスによる論理的なデータの不整合には全く無力だ。検出できるのは「同じ型かどうか」だけ。
で、この種のミスを数多く出すのは初心者に多い。練度が高くなっていくにつれ論理的不整合など別課題が増える傾向。
それを「バカ」なんて言葉で表すのはあまり賛成できないが、一部に流行る「型システム」万能論にはやや辟易だ。
型があるから大規模に向く、
Re: (スコア:0)
PythonやJavaScriptは3000行くらいが限度かな。
JavaやC++なら何万行でもいける。
Re: (スコア:0)
必ずしも「ヘビー=大規模」ではないけど、「大規模を除外したヘビー」に限定されるものを「ヘビーでもいける」と言ってしまうのは勝手に都合のいい定義に変えてしまっていると言われても当たり前だと思う。
Re: (スコア:0)
1ファイルの話じゃ無いよね?
WebサービスだのElectronアプリだのは大量のパッケージの塊なわけで
意識せずに何万行ものコードをビルドしてるんだから、そんな上限は無いと思うよ。
設計ができれば言語の違いは大した話じゃない。
(Javaの「何万行」と他の言語のそれは規模感が違う気がするけど…)
Re: (スコア:0)
一般的な経験則として、大規模開発になればなるほど参加する人の平均値を高めるのは難しくなる訳で
型システムが万能とは決して言いませんが、現代のシステム開発において「型システムが無くても大規模開発に向くか?」と聞かれたら「向きません」と答えざるを得ないです
そういう観点で、JavaScriptがヘビーな用途に向いてるかと考えたら向いてないでしょう
Re: (スコア:0)
俺は型システムだけじゃなく、スコープ解決のゆるさとか、複雑さが増すとデメリットしかないプロトタイプとか、元々はモジュール的な皆無に近かったことなども指摘したんだけどな。
JSが大規模システムに不向きなのは型システムだけが理由じゃないよ。
Re: (スコア:0)
手元で見ればemacs 26.0の標準ライブラリは167万行ある。Python 3.6のライブラリは119万行。当
然それぞれlispとpythonで書かれている。どちらも型システムなど存在しない。また開発はネット
ワーク越しの共同作業であり、一ヵ所集中の開発プロジェクトですらない。
腕が悪いだけでは?
Re: (スコア:0)
プロジェクトが大きくなるほど平均値を高めるのは難しい。その通りでしょう。
ただ、平均値が下がったところでどううまくプロジェクトを成功に導くか、という対策の中で
型システムの存在が占める割合はわずかだと思っています。
上位の設計の要素と、日々のプロジェクトマネジメントの要素が併せて大半でしょう。
で、Browserの中でDOC objectを対象に動くJAVAscriptの断片の話をしているのではなく、言語としての
型システムなしのJAVAscriptが大規模開発に向くか、と考えています。
その場合、他の言語と大差なし、と思うのです。言語特性としては特に欠けている要素は見当たりません。
得手不得手の部分はありますが、総合すればC++/Java/pythonなんかとそれほど大きな差はないでしょう。
Re: (スコア:0)
例えばスコープですがe-lispを組んでみればそのdynamic scopeのいい加減さに驚くかもしれません。それでもあの複雑なemacsというアプリケーションができてしまいます。この場合の肝は命名規則とアクセス関数です。
pythonはLEGBで規定はされていますが、実は上位objectの__get_attribute__()を修正することでいかようにも継承やスコープを変えてしまうことができます。
いずれも言語の特性であり、それに合わせた設計と組み立てが必要なだけです。
「大規模システムに不向き」とおっしゃる大部分の方の意見はよく聞くと「(自分が慣れた)procedualでwaterfallで日本型開発プロジェクト的な」大規模開発には不向き、と言っているに過ぎないと思います。
Re: (スコア:0)
「それに合わせた設計と組み立てが必要なだけです。」
BasicやCOBOLにも使えそうな便利な言葉ですね
Re: (スコア:0)
「〇〇言語に向いた大規模開発の手法があるかもしれないから大規模開発に不向きとはいえない」という主張に読めますが…
何だろうこの一生アセンブラで書いてろ感