  |
はてなキーワード: 型推論とは
JSONと比べたときの**YAMLの「闇深」仕様**、ありますね…。
YAMLは人間に優しいと言われながらも、その仕様はときに**悪魔的**。
以下、ITエンジニアなら一度は踏んだであろう「地雷」を、**論理的かつ少し自虐的に**まとめてみました：
---
good: value: ok bad: value: nightmare # ←ここ、インデントずれてて無効。だけど一見わからない。
---
password: no # ← 文字列じゃなくて false になる可能性 serial: 012345 # ← 8進数！？→ エラー
---
message: | これは複数行の スカラー値です。
---
defaults: &defaults timeout: 30 retries: 3 service: <<: *defaults retries: 5 # 上書きされるが、複雑になると意図しない結果に </pre>
---
---
---
もしYAMLを安全に扱いたいなら、\*\*JSON supersetとしての使い方（厳格YAML）\*\*を意識したり、**JSONに寄せて書く**のが一番平和だったりします。
---
要するに、YAMLは「賢く書こうとすると沼る」。
「素直に、簡潔に、禁欲的に」が正解です。
でも誘惑が多いのよね、あの子……。
プログラミング言語のＣ＋＋に暫く離れていたが便利そうな機能が出来ていたんですね。
自分が調べても色々理解しきれていないのでここの紹介で間違いがあったらすみません。
異なるクラスを代入して保持するものであり、例えばunionのような機能を実現できるらしい。
武器として使う場合は攻撃力変数は必要でも守備力変数は必要なく、
鎧として使う場合は守備力変数は必要でも攻撃力変数は必要ない場合らしい。
このような使わない変数を隠蔽しバグを作ってしまうことを回避できるらしい
例えば、boolで実装する場合は、関数戻り値をboolで成功か失敗かを返し、欲しい値を関数の引数のポインタに返す・・というプログラミングになると思う。
std::optionalでは戻り値として欲しい値と失敗かどうかを一緒に返せるらしい。
メモリの動的確保だが自分でdeleteしなくて良いのでメモリ解放忘れを防いでくれる。
スマートポインタは前からあったが現在の推奨はstd::unique_ptr
(C++20以上と記載していましたがC++11とのご指摘を受けたため修正しました。すみませんでした。)
列挙クラス
列挙型だが従来の列挙型と異なり変数名が外部と衝突しない
nodiscard属性が付いている関数は戻り値の受け取りが必須となる。
ちなみにstd::optional＜std::string＞ obj;のように＜＞内に書かれているのは昔からあったテンプレート機能のようです。
JVMはいいんだよ。マジで素晴らしい。Javaはあまりにもクソ過ぎる。
不完全な型推論、あまりにも冗長すぎるモジュール機構、ファーストクラスじゃない関数、なんでもクラス、ザコみたいな型システムに由来したあまりにも乏しい表現力。
あげてもキリがないほどのクソofクソ。このそびえたつクソに燦然と輝く究極のゴミ、そう我らが springframework。
マジでイカれてるよ。直近のJDK21で導入されたJavaの言語仕様としては instanceof 以外で正気を疑う進歩のなさ。どうしてこんなゴミがのさばってるんだよ。
まじで新規案件はKotlinかScalaにしろ！！！！！！(Scalaをまともに使える能力も判断力もない人間がなんとなくJavaを使うんだろうなあ)
緩やかに変化を続けていて、気づいたら全く別のものに変わっているものが好きです。
例えば、TypeScriptの型システム。最初はシンプルな型推論と型指定だったはずなのに、最近は複雑な型の設計がメインの作業になりつつあります。
あるいはタプル的な要素を突っ込んだりしていて、当初のものとは明らかに違う構想が始まっています。
TypeScriptはバージョンアップのたびに変更を突っ込んできていて、しかもそれが追加機能というよりは機能の改善なので1つずつ追わないとつらいですね。
Reactとかもそんな気があり、エコシステムもまた変わりそうな気配があります。今回の変更もまた根本的ですし、改善案も攻めてます。
スポーツでも派手なフェイントは見栄えはいいですが、すぐにバレます。全身の位置関係を変えずに、等速で変化するのが一番だましやすいです。
人の成長とかも、かなり低速、等速なので、一緒にいると気づかれにくいですよね。
あとは思いつかないですけど、こうやって徐々に変化して見えないうちに置き去りにするという感覚が本当に好きです。
早すぎて見えないのも格好いいですが、遅すぎて見えないというのも同じように素敵だと思いませんか。
システムハンガリアンはIDEの発達や型推論で廃れた。変数にポインタを当てるだけで型がわかる。
アプリケーションハンガリアンは、自分もメンバ変数はbtn～にしたり～Buttonにしたり迷ってたりしてたが、プロパティとして公開するときはハンガリアンにするわけにはいかないので、結局ハンガリアンをやめた。プロパティとメンバ変数が機械的に対応が取れてたほうが便利。"_プロパティ名"とかにしてしまう。
型よりもその変数の意味のほうが重要だという考え方がハンガリアンが廃れた大もとの原因だろう。最近のIDEは中間一致で補完するのが主流なので、Buttonと打てばボタン一覧が出てくる。
swiftをJavascriptとかLLみたいに言ってる人沢山いたけど、あれって変数宣言がvarだとか、見た目がスッキリしてるとかそういう印象だけで言ってるんだよね。
以前、C#に型推論が導入されたときも(っていうか今でも)動的型やバリアント型と区別がつかなくて「使うな」「バグの元」みたいに言ってる人よくいたし。
あと、C++, Perl, Java, C#, Javascriptあたりをまとめて「C系の言語」と言ってPythonやらRubyみたいな言語と比較する文脈で「似てるから」おぼえやすいとかいう人とか。
VB6をやっていてVB.NETなら移行しやすいと思っていて「ぜんぜん違う言語だよ」って言われて驚く人とか。
共通のキーワードを使ってるとかぱっと見た目が似てたら、同じような言語と思ってしまう層がけっこうな量で存在するみたいで、そういう人たちも一応コードを書けてるんだよね。
元増田です。
そのためのデータ管理という項目をコンピュータ教育の指導要領に含めるべきだって話です。
代替オフィスへ移行しても「名前重要」なのは変わらないですし、互換性問題から「マークアップ」も必要とすべきです。
マークアップがプログラミングの型推論のように行われる可能性は軽量マークアップ言語の登場からあり得ない話では無くなってますけど、それに至るまでは時間が沢山必要だと言って良いはずです。
僕は別に憲法のような確固たる可能な限り変えるべきではないルールとしてデータ管理からのコンピュータ教育を推しているわけではないです。
ただデータ管理は少なくとも僕の寿命が尽きても広く使われるはずだ。この意見はIT業界関係者ならば否定のしようがないことだと思います。
