gorogoronyan FC2

JavaScript: その他の落書き

ツウもうなされるどうでもいい落書きなど。
上ほど新しい落書き。下ほど古い落書き。

JavaScript 考古学

JavaScript は近年でも新しい文法が追加され、 10年前 (2010年代)、 20年前 (2000年代) と比べてプログラムの書き方が激変しています。 プログラムの書き方で、 いつ頃の時代に書かれたプログラムかも ある程度推測できます。

姉妹編で HTML 考古学 というのもあります。 こちらは 20世紀末、2000年代に激変しました。 JavaScript は 10数年ほど遅れて似たような話をしているのかな？ といった雰囲気です。

プログラミング言語でも、言語によっては IT 考古学者を呼んできて発掘しないと解読できないような話もしばしば 出てきます。 COBOL など？・・・。

姉妹編で PC と AV の歴史資料館。 私も CD が出はじめた頃はまだまだアナログレコードの時代でした・・・。

プログラミング言語界のペルシャ語、アラビア語 (2022/09)

・主観的、脳内妄想図

  ペルシャ語  Java, XML 
  アラビア語  JavaScript, JSON

かつての 古代ペルシャ も現在は アラビアンナイト が大賑わい・・・

アラビアンナイト全盛時代のイメージ図
アラビアンナイト全盛時代のイメージ図
古代ローマ・古代ペルシャ時代の後の姿・・・アッバース朝
JSON と XML の比較

話が飛び、暗黒の中世

ヨーロッパの方には 暗黒の中世 の不毛地帯が・・・
せっせと最先端文明を輸入中。 Unix シェル と JavaScript ぐらいまでは輸入したらしい・・・。 でも年がら年中、ムダに壮大に見えるバージョンアップの儀式をやってるという話も・・・ ルネサンス わ、まだ遠い・・・。

実りの中世 のような話もありますが、それとは別に 疫病の大流行 で大暴落するという話も・・・ セキュリティの地雷には気をつけましょう。 人間界でも コロナ が大流行したばかりだし・・・。

疫病大流行のイメージ図
疫病大流行のイメージ図
IT 錬金術と AI 占星術は絶好調・・・世も末、末法だね・・・、死の舞踏

歴史キーワード

話は飛び、筆記体と活字体

文字 の歴史でも出てきますが、 日本でも遠い昔は 筆記体 の文字を多用していました。

中世日本の筆記体の文章 (織田信長)
中世日本の筆記体の文章 (織田信長)
見よ、この流暢な筆記体・・・よ、読めん・・・。

流暢と難解は紙一重、 天才となんとかも紙一重、 ツウやマニアをうならすほど常人には理解しがたいといった話もよく出てきますが、 プログラムの書き方でも似たような話があるのかも？。 たまにコールバックやインナークラスがネストしまくったプログラムコードに遭遇したときに、 上の絵のように見えることがある。

歴史でも 近代化 する過程で筆記体を使うのをやめ、 簡明で誤読の少ない活字体を使う話が出てきます。 プログラミング言語や文体でも似たような話があるのかも？・・・。

番外・・・プログラミング界のアラビア文字のこの先の行方は？。
順調に近代化できるのか？、現在のまま停滞してしまうのか？。
かつての 世界最先端文明 も時代が下ったらすっかり停滞していたといった話も多いので、 気長に遠巻きに眺めましょう。

大文字と小文字

文字に関しては 大文字・小文字 の話もあります。 アルファベットも古代ローマの時代には大文字しかありませんでした。 小文字は後の時代になって出現します。いつ、どういう理由で発明され、 多用されるようになったか？。 日本の文字でも中国から輸入した 漢字 や流暢な ひらがな とは別に カタカナ も出現します。

プログラミング言語でも似たような話や発明や変化が起こっているのか？・・・

さらに脱線して、文学的と数学的

似たような話で文学的と 数学的 という話もあります。

ルネサンス時代はヒューマニズム文学。 初期のオブジェクト指向言語でやたらに長い名前や大げさな構文を ずらずら並べてるような話に近い。

時代が下ると 産業革命 に適した数学が発達します。 だらだら文体をやめて汎用性の高い簡素な記号で短く記述、 冗長や表記のブレなどのあいまいさをなくし、 シンプルで厳密な書き方が発達します。 API の要点を絞って簡素化したり、 壮大なインナークラスの記述を簡素なラムダ式やアロー関数に置き換えるような話に近いかも？。

プログラミング言語やプログラムの書き方は、 現在どのあたりの時代？・・・。

文字列の分割と連結 (2020/10)

文字列の分割と連結を大量に行うと、 言語によってはオブジェクトの大量生産で非常に重い処理になります。 ガベージコレクタの処理時間が大幅に増大し、どんどん遅くなります。
JavaScript: 計算、処理時間など

下のサンプルが典型的です。

Java で同じような処理の仕方をすると悲惨なことになります・・・。 Java ではストリームを引っ張り出して、Reader と Writer で逐次読み書きする処理を行います。 見た目は面倒なことをやってるコードになります。 サーバーの中で大量の処理を効率よく行う場合にはこのような面倒な工夫も必要になります。

でも JavaScript で、PC の CPU を1人で使用する間はぜんぜん問題ありません・・・。

ちょっとしたファイル処理やテキスト処理 (2020/08)

現在は、JavaScript には node.js もあるので、ちょっとしたファイル処理や テキスト処理は node.js の JavaScript で行った方がよっぽど手っ取り早いです。
Node.js などいろいろ

これぐらいの用途で Java や C# を使う理由はすでにありません。 Java や C# などを使った日には手間ヒマ面倒ばかり増える話になります・・・。

でも？

ちょっとした処理ではなくて、 厳格なチェックが必要な本格的な話になると Java や C# などの言語が必要になります。 JavaScript はコンパイルまでの段階で、型チェックやジェネリクスや データ保護などで細かいトラブルを除去するといったことができません。 そのため最初はお手軽でも後になるほど面倒が増えて、地雷だらけになります・・・。

用途に応じて、上手く使い分けてください。 

・数百行程度のプログラムや、細かいエラーチェックは気にしないプ
　ログラムなら JavaScript で事足ります。

・Java や C# は大規模なプログラムや、JSONではチェック不足で XML 
　と DTD などが必要になるようなプログラムに適しています。

言語が出てきた時代の差 (2020)

最初に学んだ言語が Java や C# だった人が JavaScript を眺めたときに、 かなり危なっかしい言語、変なオブジェクト言語に見えていると思います。 言語が出てきた時代の差が関係しています。 世代的には下の順と考えてください。 

1) C言語 

2) JavaScript (1990年代半ば)
  C言語の欠点を見てお手軽スクリプト言語に改良。

3) Java (1990年代後半)
  C言語の欠点を見てガチガチのオブジェクト指向言語に改良。

4) C# (2000年代)
  Java の欠点を見て 2番手商法で改良。

5) TypeScriptなど (2010年代)
  JavaScript の欠点を見て改良。
  マイクロソフトなのが難点 (単純な話もムダに壮大化・・・)

JavaScript は C言語と Java の間ぐらいの過渡期の言語です。 C言語からポインタ演算を取り払い、 原始型以外は Hashtable のオブジェクトぐらいと考えてください。 過渡期の姿の言語なので、 後から出てきたオブジェクト指向言語に比べて変な部分がたくさんあります。 でも、関数ポインタを使ったコールバックなど簡単にできます。 データや関数の付け替えも簡単・・・お手軽な動的言語に見えるか？、 それとも地雷満載の危険な言語に見えるか？、 人の主観によりそれぞれ・・・どちらの特徴も備えています。

でも、その一方で、Java はガチガチのオブジェクト指向や 型チェックも厳格な言語にこだわったので、融通の利かない、 ちょっとしたことが簡単にできない欠点もあります。 

例
・ちょっとした処理も壮大な無名クラスで大げさになりやすい(単純
　な関数ポインタでコールバックできない)
・String もオブジェクト(原始型ではない)なので変なことをすると
　処理が激重になる。

・型チェックが厳格すぎて、後々で融通が利かなくなる話も。
  バージョンシンドロームが起こることも。

  これに似た話だと、XHTML か HTML5 かのような話もありました。
  2000年近辺だと、なんでもかんでも XML と DTD のような話をしていた。
  現在だと、JSON で細かいことは気にせず・・・。

・Java は C# など後発の言語よりは古い世代なので、時代相応に足り
　なかったり、簡素に洗練されなかったりした部分も。

などなど

時代が構造化言語世代 (C, Pascalなど) からオブジェクト指向言語世代 (C++,Java,C#) に代わった頃だったので、前の時代を否定して、 一方の極端から反対側の極端に振れたように思える部分もある。 

◎ C言語 → Java の頃

・ポインタ演算はなし・・・諸悪の根源。メモリ破壊の泥沼、地雷原。
  このあたりは納得・・・ジャングルの泥沼から抜け出そう。

・なんでもかんでもオブジェクト
  すべてをオブジェクトとメソッドにすべし。
  原始型までオブジェクトにしたい。
  単純な構造化、static だらけの構造化処理も好ましくない。
  最初の頃、こういう話も多かったでしょ？

・ついでに C言語のマクロも乱用すると泥沼だったので全面禁止。
  Java には #if DEBUG がない。

・お手軽構造体のような話もなくなり。
  Javaだと、メモリ空間やポインタを見えなくした代わりに、メソッ
　ドの引数はどのように渡されるか？、スタックって何？、ヒープっ
　て何？、ブラックボックスでよく分からない、といった話も出てき
　やすい。

  初期の頃、Java にはポインタは存在しない論争みたいな話もあった
　けど・・・、でも、NullPointerException はあるけど。
  似たような話で、参照渡しと参照の値渡しという話も出ていた。

・ついでにヒューマニズム文学の長いメソッド名や変数名をつけよう。
  産業革命前のオブジェクト・ルネサンス時代かね？、と思える部分も。

などなど

C# は Java より後発の言語なので、 Java の欠点を見てさらに改良してあります。 Java にはなかった新しい考え方を導入する話があり、それとは別に C → Java でちょいと制限しすぎた昔話を復活させた部分も多い。 

◎ Java → C#

                    Java                         C#
プロパティ          ないのでset/getが大量に並ぶ  プロパティの考え方がある。
文字列              オブジェクト型               プリミティブ型
単純なコールバック  ない                         ある
お手軽構造体        ない                         ある
#if DEBUG           ない                         ある

などなど

(追記2022/01) それとは別に C# もちょっとした用途には面倒、 ムダに壮大、大げさという話もありますが・・・

古代の素朴な言語
   ↓
中世・近世のややこしい言語
   平安時代、十二単 (じゅうにひとえ)様式とか
   はたまた、バロック、ロココ様式とか
   20世紀、21世紀の話ではない・・・
   ↓
そのうち近代化、現代風に・・・

・音楽でもこういう話をしている？
  壮大クラシック様式と現代のお手軽音楽は違う・・

番外・・・こういう風に見えることも

言語別イメージ
C言語
C言語
高速だけど、ちょっとのミスで致命的にクラッシュ
Java,C#
Java,C#
本格的に業務用、要大型免許
JavaScript
はて、どうしよう？
お手軽マイカーの画像 

C言語       原始時代のジャングルでサバイバル。レーシングマシン
Java        格調高すぎ、アカデミック、由緒正しきフルコース。大型トラック、貨物船
JavaScript  お手軽 B級グルメ、少々お下品ヘンタイ・・・。お手軽マイカー

・Java と C# は、構造化世代の C と Pascal の関係に見える部分も

                      実務寄り      教育学術寄り
  構造化世代             C            Pascal
  オブジェクト世代      C#            Java？
  お手軽スクリプト   JavaScript       Pythonぐらい？

  ＊「実務寄り」：多少泥くさい話は気にしない。実用重視のイメージ。

  技術系でも、工学系と理学系というのがある。
  工学系 : まずは実用性。泥沼だらけも時代の水準に合わせて何とかする。
  理学系 : 理想モデルの住人。スケールは壮大でも、下手すると現実に合わない、
           実用にならないとか・・・。

  工学系と理学系は、政治屋さんか宗教屋さんかみたいな関係です・・・
  200年後の理想世界も重要かもしれないけど、まずは足元・・・

  市場か、お寺や宮廷か、みたいな関係もある・・・
  市場ほど B級グルメみたいな話もあるけどにぎわいの中心。
  お寺や宮廷ほど洗練された部分もあるけど地べたの現実世界とかけ
　離れたあさっての話をはじめることも・・・。

JavaScript特有のキーワード (2014)

C、Java, C# などを知っていて、JavaScript はあまり知らない人に参考になりそうなキーワードです。 検索して調べてみてください。

数値や null の比較で != を == を使わない

JavaScript では 0 == "" が true、null == undefined が true など、 いろいろ落とし穴があるので ===, !== を使った方がよいという趣旨です。
TestJS_compare02.html

(追記2020)その後、あまり気にしていない・・・。

関数の変数の巻き上げ（ホスティング）

JSLint で関数内で使用する変数を関数の先頭で宣言しなさい という趣旨の警告が出ます。 C、Java, C# 系の人だと、「何でや？」と思うかもしれない話です。
JavaScript の巻き上げという話が関係しています。 ソースを直すかどうかは別にして、知っておいて損はない話です。

(追記2020) 巻き上げの話は知るだけ余計なので、 はじめから見ないか、きれいに忘れてください・・・。 変数は var を使わず const や let にし、 "use strict" を付けて、 エラーが出ないようにしてください。

変数のスコープに注意

こまごまと違いがあります。 for のループ変数など繰り返し宣言すると２重定義の警告がでます。

(追記2020)上の巻上げの話と同様。変なスコープを気にしなくて済むようにします。

プロトタイプチェーン

難しい話です・・・。
CodeZine:プロトタイプ（prototype）によるJavaScriptのオブジェクト指向

for in でプロパティの所有関係をチェックした方がいいかも？

JSHint で警告がでます。プロトタイプチェーンが関係する話です。 親のプロパティまでさかのぼらないようにします。

for (let key in node){
    if (node.hasOwnProperty(key)){  //所有関係をチェック
        ...
    }
}

配列で for in を使わない方がいいかも？

正確にいうと配列のように見えているけど配列 (Arrayオブジェクト) ではないオブジェクトに注意が必要です。 具体的には getElementsByTag などの戻り値です。 インデックス値以外に length などがキーとして混ざります。

(追記2020) 配列(Array) のように見せた別のクラスのオブジェクトがあるので、 そういうオブジェクトで for key in を使わない方がよいです。 index 値以外のプロパティが混ざります。

ループの中で関数を作らない

JSHint で警告が出ます。 イベントハンドラの一括登録などで起こりそうな話です。

function init(){
	...
	for (let i=0; i<list.length; i++){
		list[i].onclick = function(){  //これが警告される
			...
		};
	}
}

(追記2021) こちらは関数を作っても問題ないと思います。 使い方に注意点がある。

(追記2020) 関連で、こちらは、昔の IEの制限で変な書き方をしていた。

例:下のように () の中に無名関数があり、最後に (param) で引数を
   渡すような書き方。

onclick = ( function(p){
	....
})(param);

現在はこういう書き方をする必要はありません。
bind() を眺めてください。
  MDN:Function.prototype.bind()

普段 Java や C# を眺めている人が、初めて JavaScript 
を眺めたときに、undefined でオブジェクトのメソッドが
見つからないトラブルに必ずはまると思います。 
this のコンテキストが関係しています。bind()で正しく指定
します。

JavaScript はやさしい言語か？ (2013)

次の２つの話、どっちがいい？

  1. 見かけは厳しそうで、最初に適当にプログラム書くと 「お前はアホだ」「顔を洗って出直してこい」 「さっさと書き直せ」と警告してくれる言語と・・・
  2. 見かけはやさしそうで適当に書いてもおまかせコースで、 型チェックもなく型変換も自動的に行い、 適当に比較もしそれなりに動くのだけど、 トラブルが出ると急に態度が変わって「お前が書いたとおり実行してるんだろ？、 このボケ」 と恐ろしい人になってしまう言語・・・

前者が Java, C# で、後者が JavaScript と初期のC言語です・・・。

追記 2020

その後、Webブラウザのデバッガが高度に発達し、node.js も登場し、 IEを気にしなくてよい時代になるにつれて半分ぐらいは良い言語に見えるようになった。 ちょっとした処理は Java や C# を使うよりよっぽど便利です。 半分ぐらいは地雷だらけだけど・・・。

追記 2022

JavaScript は使い始めは面倒な話も少なくて一見簡単に見えるけど、 言語仕様自体は親切というわけではありません。 プログラムの規模が大きくなるほどつまらないトラブルに悩まされる言語 という特徴も持っています。

初期の C言語も変なコードを書いても警告の 1つも出てこない、 原始時代のジャングルでサバイバルような言語でした。 その後、変なコードを書くと大量の警告メッセージを出す親切 (?) な言語になりました。

Java や C# も上の 2) のような問題を改善するため誕生しました。 最初に面倒を道具を揃え、難しい話を聞かされ、 意味不明なエラーメッセージや警告メッセージが大量に出てくる欠点もありますが、 つまらないトラブルを減らすためという親切心もあります。

JavaScript の問題点を改善しようとすると TypeScript のような言語も出てきます。

関連

inserted by FC2 system