  |
はてなキーワード:予約語とは
「赤ちゃんが安らかに眠る」本当に字義通りのことが起こってるのにそう書いたら死者だと勘違いするとか慣用句がわかってないとか言われるの言語の欠陥だろ。
無言の帰宅も若者がわからないとバズってたそうだが問題は若者が慣用句としてそれを知ってるかどうかじゃなくて、字義通りのことが起こってても慣用句に同じ表現あったら避けなきゃ書き手が悪いとみなしてくる受け手側なんだよな。
いちいち別の表現捻り直さなきゃいけなくしてるっていうこと、つまり慣用句に対して予約語並みの特別待遇をしてるのが問題。
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251023185834# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaPn8SwAKCRBwMdsubs4+SGzsAP9km2RcWr68h6hZlI1JFspztpz+vVZGU5kV5AkZjAaEJwEAgPjYDU7a3mLBU7O4w7L1P4UHcUu7pT/BMDnfWCfm0gI==Llp0-----ENDPGP SIGNATURE-----
ここで言う「プログラミング初級者」とはプログラミングの記述が上から下へ向かって順番に処理されること、条件分岐やループという概念があることを理解しており、RPGゲームが作れる「RPGツクール(現RPG Maker)」や学童向けプログラミング環境「Scratch」、「ナビつき! つくってわかる はじめてゲームプログラミング(ナビつく)」、ADVゲームが作れる「吉里吉里(もしくは吉里吉里2)」、過去にBASICやC、HSP、Javascriptあたりでプログラミングへ挑戦し挫折したなどなど、ある程度の「プログラマブルなロジック」構築の経験がある者を指します。
ある時、筆者はふと思いました。「生成AIはなんだかんだで膨大なテキスト情報を処理している事がキモだよなぁ」とありきたりなことを。
そして、同時にプログラミング初級者の弱点として「現在記述されているコードの管理においてテキストと実際の処理フローが脳内で一致しない」「プログラミング言語ごとに定められているルールや関数予約語の把握が困難」なのが問題とも考えました。
前述したプログラミング初級者の弱点の考え自体は車輪の再発明であり、「Scratch」や、より高度な「UML」が既に存在しており、特筆すべきことは何もありません。
しかし、「Scratch」や「UML」、なんなら「RPGツクール」や「吉里吉里」などに無い点として、現代では自然言語処理が大幅に向上した生成AIが実用の域にまで到達しつつあるのが従来とは異なる点でした。
つまり、自然言語を混ぜ込みやすいテキストベースの言語、かつ、処理を記述するとフローが視覚的に理解しやすい言語、可能であれば情報量が多くて一部の界隈で広く使われている言語があればプログラミング初級者も気軽にプログラミングできるのではないか？と発想しました。
コンピュータ(コンパイラやインタプリタなどソフトウェアを含む)が解することができる言語にはプログラミング言語以外にも様々あり、今回取り上げるのは「データ記述言語」と呼ばれるものです。
データ記述言語の中でもグラフ作成へ特化しており、特にフローチャート作成で真価を発揮する「DOT言語」というものがあります。
早速ですが、実際に手を動かしてみましょう。ちなみにDOT言語はGraphviz OnlineというWebツールがあるため別途に何かしらをインストールして環境構築する必要はありません。便利な世の中ですね。
上記のGraphviz Onlineを開くと、既に左側のDOT言語で記述された内容が、右側で作図されています。DOT言語はこのような図を作図するためのデータ記述言語です。
一旦、左側の記述をCtrl+Aで全選択をしDeleteなどで全削除し、下記の内容をコピペしてみましょう。
digraph graphname {
A -> B;
}
DOT言語の詳細な使い方は様々なWebサイトやブログ記事、Qiitaなどへ譲るとして、A - > Bの見た目から発想の転換をしてみると処理Aから処理Bという流れに見えませんか？
DOT言語は生成AIを利用する上で有利なテキストベースでありながらグラフを作成できるのがキモであり、例えばこのA -> BがA「Webページを開いたら」 → B「Hello, Worldと表示する」という風にできるのであれば処理のフローが可視化されており本当に素晴らしいことです。
ここでプログラミングの有識者は「DOT言語をUMLなどに見立てて処理を記述するのは良いが、プログラミング初心者は求めた結果を出力するロジックやアルゴリズムを発想する知見や経験値が圧倒的に足りていないのが問題ではないか？」と至極真っ当かつ反論の余地がない問題点の指摘をすると思いますが、そこで活きるのが生成AIです。
生成AIは初級者プログラマ個人のロジックやアルゴリズムの作成能力へ無関係にロジックやアルゴリズムを生成できる(可能性が少なくともある)ので、処理のフローをDOT言語で記述することにより処理フローから初級者プログラマが求めるプログラムを生成AIへ推論させ生成させるというのが狙いです。実際に試してみましょう。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する"
];
A -> B;
}
プログラミングの有識者はこの時点で「なるほど、自然言語の記述をそのままDOT言語に入れ込んでしまうのか」と気付いたのではないかと思います。
このDOT言語をGoogle Gemini 2.5Flashへ「下記のデータ記述言語のDOT言語で記述された処理フローをJavascript言語へ変換をしWebページ上へ「Hello,world」を表示したいので変換をお願いします。」と命令すると以下のコードが生成されました。
<!DOCTYPEhtml>
<html lang="ja">
<head>
<meta charset="UTF-8">
<metaname="viewport" content="width=device-width, initial-scale=1.0">
<title>Hello World Page</title>
</head>
<body>
<divid="output"></div>
<script>
//Webページが表示されたら（DOMが完全に読み込まれたら）実行される
document.addEventListener('DOMContentLoaded', function() {
// "Webページを表示する"ステップは、このHTMLファイル自体が表示されることで達成されます。
// "Webページを表示したらHello, worldとテキストを表示する"ステップ
const outputDiv = document.getElementById('output');
outputDiv.textContent = 'Hello, world';
});
</script>
</body>
</html>
フローを記述する利点は、ロジックやアルゴリズムを発想する知見や経験値が足りなくとも、フローのステップが明確に分かれているので生成AIが処理を切り分けて推論してくれることであり、そしてプログラミング初心者自身がフローチャートを視覚で確認できるので「Aを処理したらBを処理する」と切り分けて考えやすいことです。
また、求めている結果ではなく誤った結果が生成されても、A - > B - > Cとフローを細分化していくことで生成AIの推論精度を高めていくことができるのも利点です。
より生成AIへ精度の高い推論をしてもらうために補足情報を付加するのも有用です。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
A -> B;
}
labelの記述内容もcommentの記述内容も生成AIが推論のための情報として利用するので誤った結果が生成されてもA - > B - > Cとフローを細分化しなくとも良い場合があります。
DOT言語を知るプログラミング有識者が「DOT言語の仕様を考えれば確かにそうだが、その発想はなかった」と言っていただけるであろうDOT言語コード例だとこういう記述方法もアリです。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
最初の処理 -> 次の処理;
}
ノードの名称へ自然言語を採用することにより、例えばゲームプログラミング時に「キャラクターがジャンプする」という読んだそのままな処理のためのノード、というか一般的に言うオブジェクトを作成することが可能で、後は->で繋げて処理をさせられます。
ちなみに別のノードを作成する際に「"キャラクターがジャンプする"から継承する」の様なことをcommentなどへ記述しておくと生成AIが推論して継承します。なんならcommentなどへ「キャラクター画像にimage.gifを使用」などと記述しておくとファイルの読み込みもします。
更にDOT言語にはカスタム要素という仕様が存在しており、DOT言語の仕様で定められた予約語以外も使用が可能です。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機",
font_style = "フォントを太字のボールド体、色を赤(#FF0000)とする"
];
最初の処理 -> 次の処理;
}
生成AIはカスタム要素の名称からも推論を発揮し、上記の場合であればフォントスタイルを指定していると推論をするので生成AIの推論精度を高める補足情報として機能します。
つまりこれはカスタム要素の名称として"Action"などの名称を採用すると"動作"として推論をし、"decision"ならば"条件分岐"ですし、"input"ならば"入力"ですし、"loop"ならば"繰り返し"ですし、"Type"ならば"種別"です。
より詳細に process[type="Action"] などのノードを作成してどんどん生成AIの推論精度を高めていくことが可能であり、そろそろ察してきているかと思いますが 処理[種別="動作"] と自然言語で記述しても機能します。
プログラミング有識者は更に「プログラム言語自体の予約語、例えばJavascriptを生成する事を前提にlengthを名称にすると配列を使おうとするのか？」と疑問に感じるでしょうがお察しの通りで生成AIは配列を使おうとするので、敢えて使いたいプログラム言語の機能や外部ライブラリなどがある場合は補足情報として機能する形で記述しておくと生成AIは推論へ利用します(まぁそこまで知識ある方なら該当のプログラム言語使ったほうが手っ取り早いと思いますが)。
以上をもって「生成AIを利用したプログラミング初級者向けの温故知新な提案」を終えたいと思います。
色々とツッコミどころには筆者自身が気付いていて。例えば「結局はDOT言語の仕様を覚えないといけないのでは？」とか「プログラミング初級者に任せると生成前のソースであるDOT言語コードがスパゲッティになりそうだよな」とか「面倒くせぇから普通にプログラミング覚えろや」とか理解してますし至極真っ当かつ反論の余地がないと思ってます。
今回の提案のプログラミング有識者向けの本質は「生成AIへ向いた中間言語の発掘」であり、「DOT言語ならそこそこ普及してるしプログラミング初級者でも扱えるんじゃね？」と業務中に発想したものを書き留め公開いたしました。
何かプログラミング有識者の皆さんからより良い発想があれば参考にしたいと考えていますのでよろしくお願いいたします。以上。
Permalink |記事への反応(36) | 19:36
昔マイクロソフトがひどい目にあったというconconアタックについて説明してください。と質問。
「Conconアタック」というのは、1990年代後半から2000年代初頭にかけて話題になった「SYN flood攻撃」と呼ばれるDDoS攻撃（分散型サービス妨害攻撃）の一種です。～
（以下ずっと長い説明が続くが全部嘘だった。タダで使えるやつだからこんなもんか）
昔マイクロソフトがひどい目にあったというconconアタックについて説明してください。と質問。結構よさそうだったんで下の方の設定から専門的な観点で書けというのをクリック
## ConCon攻撃に関するより専門的な解説ConCon攻撃は、1990年代後半に顕著に見られた、MicrosoftWindows 95/98のファイルシステムにおける脆弱性を悪用した攻撃手法です。本攻撃は、特定の予約語である「CON」を繰り返し使用することで、オペレーティングシステムの挙動を意図せず変更し、結果としてシステムクラッシュやデータ損失を引き起こすというものでした。###攻撃原理** **予約語の濫用:** 「CON」は、DOS時代からデバイス名として予約されていた文字列です。Windowsにおいても、この予約語は特別な意味を持つファイル名として扱われます。** **ファイルシステムの誤動作:**複数の「CON」を含むパス名を指定することで、ファイルシステムが正常に動作せず、無限ループやメモリリークといった異常な状態に陥ります。** **システムの不安定化:**上記の異常状態が深刻化すると、システム全体が不安定になり、最終的にはブルースクリーンエラーが発生し、コンピュータが使用不能となるケースも少なくありませんでした。### 影響と対策ConCon攻撃は、そのシンプルさ故に、悪意のあるユーザーだけでなく、誤って特殊な文字列を含むファイルを作成してしまったユーザーにとっても、深刻な問題となりました。この問題を受けて、MicrosoftはWindowsのセキュリティ対策を強化し、以降のバージョンでは同様の攻撃を受けにくくなりました。** **パッチの提供:**Microsoftは、ConCon攻撃に対応するため、Windowsのセキュリティパッチを随時提供しました。** **ファイルシステムの改善:**ファイルシステムのロジックを見直し、予約語の扱いをより厳密にすることで、同様の攻撃を防ぐ対策が講じられました。** **ユーザー教育:**ユーザーに対して、安全なコンピュータ利用に関する教育が強化されました。### まとめConCon攻撃は、OSのセキュリティ脆弱性がいかに深刻な問題を引き起こすかを示す典型的な事例です。この事件は、IT業界全体にセキュリティ対策の重要性を再認識させ、より安全なソフトウェア開発へとつながる契機となりました。***技術的な視点から見た特徴**** **バッファオーバーフローとは異なる:** ConCon攻撃は、一般的なバッファオーバーフロー攻撃とは異なり、特定の予約語を悪用することで、意図しない動作を引き起こす点が特徴です。** **ファイルシステムレベルの攻撃:**攻撃対象がファイルシステムであるため、OSの根本的な機能に影響を与える可能性があります。** **単純だが効果的な攻撃:** 複雑な技術を必要とせず、誰でも簡単に実行できる点が特徴です。***現代における教訓**** **ゼロデイ攻撃の脅威:** 未知の脆弱性を突くゼロデイ攻撃の危険性は、いまだに高い。** **継続的なセキュリティ対策:**OSやアプリケーションのアップデートは、セキュリティ対策の基本。** **ユーザーのセキュリティ意識向上:**パスワード管理やフィッシング対策など、ユーザー自身がセキュリティ対策を意識することが重要。***キーワード:** ConCon攻撃,Windows 95/98,ファイルシステム,予約語,ブルースクリーン,セキュリティパッチ,バッファオーバーフロー,ゼロデイ攻撃この説明は、より専門的な用語を用い、技術的な背景についても言及することで、ConCon攻撃の性質をより深く理解できるように記述しました。
（何も指定しなかった場合フツーに当時の攻撃コードみたいなサンプルを出したのですげーなお前と思った）
昔マイクロソフトがひどい目にあったというconconアタックについて説明してみてほしい と質問
「Conconアタック」というのは、実際には存在しないもので、インターネット上での都市伝説やジョークの一種です。マイクロソフトが「ひどい目にあった」という話は、フィクションであり、実際には起こっていません。このようなジョークは、インターネット上で広まりやすく、時には誤解を招くことがありますが、基本的にはユーモアを提供するためのものです。もし他に興味がある話題や質問があれば、ぜひ教えてください！
（なかったことにしやがった。お前最高だよ）
東京電機大学を卒業後、VisualBasicを用いた会計支援ソフトウェア開発、自社サイトの制作に従事するなど、アプリケーションエンジニア、フロントエンドエンジニアとして5年にわたって業務をおこなって参りました。
今後は、その中で得られたVisualBasicの予約語暗記の実務経験を活かして、VB.NETによる開発に取り組んでいきたいと考えています。
VisualBasicを用いた会計支援ソフトウェア開発
VisualBasicを用いた内製ソリューションの引き継ぎ・バージョンアップ開発。
特に、複数の法定通貨をないまぜに扱うため、レート換算と端数処理が至るところに発生する困難な会計処理でした。
社長がホームページ・ビルダーで作成したプロトタイプを元に、HTML5/CSS3で再構築した自社コーポレートサイト。
プロトタイプのコードは全く利用せず、スタイルデザインのみを参考にいちから構築しました。
また、その2年後にスマートフォン対応も行っており、SCSSやflexboxを利用したモダンなHTMLコードを構築できたと自負しております。
プログミングを勉強で英語のサイトを見ていると分からない英単語が多い。
基本の予約語ならあるていど分かるが、統計学・機械学習・グラフ作成で使われている英単語は専門用語としてつかわれているケースがあるために、意味が掴みづらい。
少しググると適当な英単語を羅列しているサイトもあるようだ。Qiita,会社のサポートサイトなどでも。
一方で、ウェブ上の英単語集の中には熟語や慣用句は少ないようだ。
こうなると、頻出英単語を抽出するプログラムを作ってみようかとも思うが。
探したら、あるのかな。。（実際、オライリー本にも、そんなサンプルコードあったし）
しかし、プログミングを習得したいのだからまずは日本語訳の本を手に取って概略をつかむべきカナとも思う。
実務でこなせるようになるには、いずれは英語でプログミングの意味をとれる必要がある。
迷っているうちに、日が暮れそう。
これまでの経験から、日本語で、学びたいことの概念を掴んでからが、自分には合っているのかな。
動くものをつくらなきゃ、その一方でもっと楽にプログミングできるライブラリーは英語でドンドン出てくるのだろうか。
器用な人はサクサク進んでいそう。
swift playgroundとかswiftが知ってる人フレンドリーではあるけど、初心者には分かる仕組みになってるのだろうか？
SI業界に入った子がSQL書けとか、ES6書けみたいなこと言われたってハードル高すぎないかねぇ。
AWSとかアラフォーの俺も全然分からない。awscliでスナップショットとれるなんて今日初めて知ったよ。
今のプラグラミング言語って色んな言語を取り込んで高機能化してる訳じゃない？なんでそんなことしてるのか分かんないと思うのね。
伝わる人に言うと、JavaだってAutoBoxingが前提だったりするわけじゃん？42+"円"とか書いちゃう訳よ。コンパイルエラーにならないのも頑張りすぎだろと思うけど。
あとmaven使えば色んなライブラリ使えるわけじゃん？今ならGradleなのかい？よくわかんねぇけど。俺はよく分かんないけど、使いこなせてるのかね？
AWSもES2の説明はできてもS3の説明できる先輩がどれほどいるか。ストレージや仮想化の知識が前提にない人は説明はキツいなと。AIMとか混ざると地獄よね。
プログラミングに戻ると、今どきの言語って最先端で書かれると記号や謎予約語が多かったりするんだけど諸先輩方は大丈夫かなと。
WordやHTML+CSSで文章を書くのと比べて、桁違いに書きにくい。
お蔭で後年SQLに出会った時は、記法のセンスの素晴らしさに感動したわ。
何故なのかは知らないが、バックスラッシュに中括弧に$に^に、fracみたいな覚えにくい予約語のオンパレードにその他諸々、記法があまりにも暗号的すぎるんだよ。
マークアップ的要素があるくせに、XMLやHTMLよりも「どこからどこまで」を遥かに把握しにくいし。
あと、記法の問題だけじゃなく印刷に持っていくまでの処理もマジめんどくさいわー。
WYSIWYGを捨ててかかってるだけでも十分めんどくさいのに、dviにしてレイアウトを視覚的に確認しようとするだけで「文法間違ってます出力できませーん」とか、いい加減にしろアホ！と何度思ったことか。
こういうTeX使ったことある奴なら当たり前に経験している使いにくさを「インターフェース」と言ったのに、エディタの問題などと矮小化して捉えられるのは、正直言ってメチャクチャ不愉快だわ。
てか、viでもemacsでもなんでもいいけど、こんなのどんなエディタ使っても使いやすくならないだろ。
いろいろツール入れれば多少は負担が軽減されるのかも知れないが、そんなふうにいちいち環境整える手間を掛けてまでTeXで書く理由なんて微塵も感じられないから。
車の運転がAT全盛の時代にあってMTに凝るくらい趣味的かつ滑稽な話だよ、TeXは。
「C言語に対する最新最良の処方は、可能な限りC言語を使わないこと」というのは有名だが、これはそっくりそのままTeXにも当てはまる。
SQLは意識して書かないと死ぬほど読みにくくなるのが気に入らない。
前の職場には何もかも全部大文字で表記し、ろくに改行も入れないバカが居て死ぬほどつらかった。あろうことか、読みづらいクエリを書ける自分にプライドを持ってるっぽかった。ああいう奴とは二度と仕事をしたくないよ。
SELECT COL0,COL1,COL2 FROM TABLE0 WHERE COL0=1000 AND COL2 IN (100,102)
これを少しでも読みやすくするために予約語を大文字、カラム名やテーブル名を小文字で表記している (カラム名・テーブル名が大文字で決め打ちされているなら、予約語を小文字で統一している)。
SELECT col0,col1,col2FROM table0WHERE col0=1000 AND col2 IN (100,102)
しかしこの方法も万全ではなくて、例えば複数のテーブルが関連するクエリが
SELECT t0.col0, t0.col1, t0.col2, t1.col0FROM table0 t0 LEFTOUTERJOIN table1 t1ON t0.col3=t1.col3WHERE t0.col0=1000 AND t0.col2 IN (100,102)
みたくなってしまう (テーブル名のtable0、仮名t0、カラム名col0が全部小文字になっているため、なかなか読みづらい)。
皆さん、どうやって工夫されてますか？
定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。
（実践はしていない）
日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応で日本語書けるもの。
○画面に表示する時
フレームワークや言語にもよるけど表示するときに英語の名前から日本語の名前に変換して表示って手間があるものがある。
最近見かけた例だと.NETでプロパティの属性に表示名書いて表示するときに取り出していた。
最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける
次に他の人の英語化したのを見る時。
その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。
そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。
相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラスや関数によって呼び方違うと辛い。
かといって全員に日本語と英語の対応を先に渡しておいて統一しようというのは大変すぎる。
（日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず）
----
次にデメリット
軽く調べた感じ主にこの2つな感じ。
○IME
と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。
ほぼ無意識でやってて意外と苦じゃない。
短いとF10変換で半角にすることもあるけど、キーボードのタイプ数カウンタとか入れてみると半角全角キーはけっこう上位にいた。
それに、なんだかんだコメントは日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。
そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。
最近じゃIDEやエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。
githubで公開したりとかライブラリで再利用してもらうときに日本語じゃ使ってもらえない。ってことみたい。
私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーションの固有名詞みたいなところ。
「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的な英単語でいいと思う。
具体例がいいづらいけど、業務システムで表示する金額の名前とか、日本語独特なものとか、一般的な単語じゃなさそうなの。
こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いからgithubで公開する範囲も英語のものでいいと思う。
ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体をgithubで公開する場合はできない気がする。
でも、海外も対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語でいいんじゃないかな。
----
長くなったけど、まとめると、
業務システムの固有名詞とか日本語特有なものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな
ということ。
まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由。
帰ってきたらすごいブクマついてた。
絶対「自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間に日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。
まず、思いの外日本語プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。
具体例上げずにサッと書いたらからかな。
あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。
これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。
---
最近の主要な言語ならだいたいUnicode対応でしょと思って環境があった言語を試した結果はこうだった。
JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift
rust とLua は無理だった。
rust は確か前に、変数名がascii文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。
実際に今どんな状態かは知らない。
その記事のコメントとかでみたけど、日本語以外は割りと自国の言葉を使ってたりするっぽいね。
VBA を上げてる人がいたけど、私はそこまでのはみたことない。（幸せ者っぽいな）
稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。
パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。
---
○使ってみて
大規模案件に使ってみてこその問題もあるだろうけど、簡単なスクリプト程度のを日本語にしてみて気づいたこと。
割といける。
PHPて言語は変数は全部$からはじめないといけない欠陥言語。
まあ変数のみのgrepのしやすさや予約語キーワードを変数名に使えるからメリットもある。
だが、$って打ちづらい。
Shift+4ってすごいつらい。
に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。
GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。
IDE重いから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語の変数名で書くより速度は早いと思う。
---
少し前に知人から言われた日本語のデメリットを思い出したのでそれも触れとく。
「仕様変更で言葉変わったときに日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」
英語わからない人が、英語を言葉とみなさずただの記号として考えてるから、っていうような発言。
仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。
英語と日本語の対応をコメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。
こういう考えの人がいたら本当にやめてほしい。
---
あとは気になったコメントについて書いてく。
表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。
年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。
こういうのを日本語にしたい。
なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。
特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。
---
見た目について。
見た目が残念とか見づらいというのは同意。
見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語のコード見ればなれるんじゃない？って思う。
---
へとヘ
これはありそうな問題。
ただ、IDEを使う前提なら未使用変数のエラーとか、選択したときに色が変わってないとか、割と気づけると思う。
lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。
---
私が日本語にしたいような固有名詞をローマ字化してるプロジェクトにであったことはある。
それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ？という日本語より表記が揃わない問題ある。
特にローマ字の場合自分がキーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。
---
海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。
そういうのは対象外。
今回いいたいのは、元から日本しか対応してないような業務システムなど。
そういったところの固有名詞が日本語になったからって、困ることはないはず。
日本でしか使われないもの・海外向けにするにしてもフルスクラッチで作り直すことになるようなもの、
---
テストだと日本語が使ってる人多いのかな？ブコメのスタートップだし。
---
長くなったけど参考になる意見もいろいろあって助かった。
Permalink |記事への反応(17) | 23:03
