アカウント名:
パスワード:
せっかくクソコードお断り言語だったのに。汎用化はプロの中のプロ以外は使わせちゃダメだって。
理想は常に現実に敗北する。そして、新たな僕の考えた理想の言語が誕生する。この繰り返し。
だからこそ、現実しか見てないPerl(4あたりまで)が自分は好きでしたね。過去形だけど。
以前、好きな言語 Perl4 という人がいたんだけど、そういう理由だったのかw
そろそろ言語仕様の変遷についても総称化できそう
コピペ排除のためのやむを得ない犠牲。
まあいわゆるオブジェクト指向まで行かないにしてもある程度似たような構造体をまとめて扱いたいよね…
意図的に入れていなかったものを後から入れるって方針ブレブレで最悪だと思う。ジェネリクスが存在しないことを前提に設計されてきたはずのこれまでの言語仕様やライブラリとの整合性とか問題ないのか?
> 意図的に入れていなかったものを後から入れるって方針ブレブレで最悪だと思う。
ユーザー定義クラスなしで使えるように設計されたのに結局クラスを導入したjavascriptとかね。
でもジェネリクスに関してはほとんどの言語が当初はサポートしていなくて後付けで導入されているので、言語仕様やライブラリの問題もそれらと大差ないかと。
JavaScriptは今でもクラスベースじゃなくてプロトタイプベースだけどな
Javascriptへの怨念がすごい。
JavascriptはそもそもNNの組み込み簡易スクリプトとしてデザインされたものだから、ちょっと事情が違う。元々は割とセンスのいい設計者が手癖で作った程度のもの。手間を掛けずに作った割に優れていたが、Web用の整備された共通言語、しまいにはサーバー用途にまで活用される想定なんて無かった。
つまりグーグルイズイービル。
「ちょっと事情が違う」ではなく、その当初想定していなかった方向へ拡張したことへの怨念なんだけど。PHPもそうだけど、お手軽に使えるよう意図的に型ゆるゆるにしてたものを、良くも悪くも「便利」にしやがって…
今のJavaScriptは型ゆるゆるじゃないの？
そこは変えられないから#4221811が言ってるように方針ブレブレだという話をしてるんだけど…
昔は型を拡張するのも自由自在だったけど現在は作法が決まってるね。ネイティブのオブジェクトだとプロパティがgetter/setter経由になって、設定できる値が限定されたりする。
怨念があるのは分かったが、言語仕様の設計者も利用者の用途も質も変わってるんだからそりゃ方針が変わるのも頷ける。というか、それがコミュニティの支持を得たからそうなった。
Javaがいつか来た道をたどるのか自分達ならもっとうまくやれるはずと信じて
しゃーない、クソ言語やから
先日引き取った新規プロセスで、ク○なGenericsを直したばかり…いや、もうコード全体の9割書き直してるんだけど。
たとえコードがコピペと定型文だらけの冗長なものになっても言語仕様を単純化しようというという設計思想なのだと思ってたけど今更方向転換したら、書かれたコードは冗長かつ言語仕様もわかりにくい言語になりそう
コーディング規約で縛っていいぞ。C++界に住んでるが、「○○はむしろ禁止」は、解放されるってことでもある
じゃあ、コーディング規約に合致しているかチェックするlintを書いてください。
# そしてそのlintが複雑になって……
とっくにあるから。たとえばhttps://www.techmatrix.co.jp/product/ctest/staticanalysis/codingrule.html [techmatrix.co.jp]
それは有償っぽいけど、lintで書かれてるんですか？
はい。詳しくは開発元にお尋ねください。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
あーあ (スコア:-1, フレームのもと)
せっかくクソコードお断り言語だったのに。
汎用化はプロの中のプロ以外は使わせちゃダメだって。
Re:あーあ (スコア:1)
理想は常に現実に敗北する。
そして、新たな僕の考えた理想の言語が誕生する。
この繰り返し。
Re: (スコア:0)
だからこそ、現実しか見てないPerl(4あたりまで)が自分は好きでしたね。過去形だけど。
Re:あーあ (スコア:1)
だからこそ、現実しか見てないPerl(4あたりまで)が自分は好きでしたね。過去形だけど。
以前、好きな言語 Perl4 という人がいたんだけど、そういう理由だったのかw
gayazone
Re: (スコア:0)
そろそろ言語仕様の変遷についても総称化できそう
Re: (スコア:0)
コピペ排除のためのやむを得ない犠牲。
Re: (スコア:0)
まあいわゆるオブジェクト指向まで行かないにしてもある程度似たような構造体をまとめて扱いたいよね…
Re: (スコア:0)
意図的に入れていなかったものを後から入れるって方針ブレブレで最悪だと思う。
ジェネリクスが存在しないことを前提に設計されてきたはずのこれまでの言語仕様やライブラリとの整合性とか問題ないのか?
Re:あーあ (スコア:1)
> 意図的に入れていなかったものを後から入れるって方針ブレブレで最悪だと思う。
ユーザー定義クラスなしで使えるように設計されたのに結局クラスを導入したjavascriptとかね。
でもジェネリクスに関してはほとんどの言語が当初はサポートしていなくて後付けで導入されているので、言語仕様やライブラリの問題もそれらと大差ないかと。
Re: (スコア:0)
JavaScriptは今でもクラスベースじゃなくてプロトタイプベースだけどな
Re: (スコア:0)
Javascriptへの怨念がすごい。
JavascriptはそもそもNNの組み込み簡易スクリプトとしてデザインされたものだから、ちょっと事情が違う。
元々は割とセンスのいい設計者が手癖で作った程度のもの。手間を掛けずに作った割に優れていたが、
Web用の整備された共通言語、しまいにはサーバー用途にまで活用される想定なんて無かった。
つまりグーグルイズイービル。
Re: (スコア:0)
「ちょっと事情が違う」ではなく、その当初想定していなかった方向へ拡張したことへの怨念なんだけど。
PHPもそうだけど、お手軽に使えるよう意図的に型ゆるゆるにしてたものを、良くも悪くも「便利」にしやがって…
Re: (スコア:0)
今のJavaScriptは型ゆるゆるじゃないの？
Re: (スコア:0)
そこは変えられないから#4221811が言ってるように方針ブレブレだという話をしてるんだけど…
Re: (スコア:0)
昔は型を拡張するのも自由自在だったけど現在は作法が決まってるね。
ネイティブのオブジェクトだとプロパティがgetter/setter経由になって、設定できる値が限定されたりする。
Re: (スコア:0)
怨念があるのは分かったが、言語仕様の設計者も利用者の用途も質も変わってるんだからそりゃ方針が変わるのも頷ける。
というか、それがコミュニティの支持を得たからそうなった。
Re: (スコア:0)
Javaがいつか来た道をたどるのか
自分達ならもっとうまくやれるはずと信じて
Re: (スコア:0)
しゃーない、クソ言語やから
Re: (スコア:0)
先日引き取った新規プロセスで、ク○なGenericsを直したばかり…いや、もうコード全体の9割書き直してるんだけど。
Re: (スコア:0)
たとえコードがコピペと定型文だらけの冗長なものになっても
言語仕様を単純化しようというという設計思想なのだと思ってたけど
今更方向転換したら、書かれたコードは冗長かつ言語仕様もわかりにくい言語になりそう
Re: (スコア:0)
コーディング規約で縛っていいぞ。C++界に住んでるが、「○○はむしろ禁止」は、解放されるってことでもある
Re: (スコア:0)
じゃあ、コーディング規約に合致しているかチェックするlintを書いてください。
# そしてそのlintが複雑になって……
Re: (スコア:0)
とっくにあるから。たとえば
https://www.techmatrix.co.jp/product/ctest/staticanalysis/codingrule.html [techmatrix.co.jp]
Re: (スコア:0)
それは有償っぽいけど、lintで書かれてるんですか？
Re: (スコア:0)
はい。詳しくは開発元にお尋ねください。