もしかしてNullさん問題もYAMLだからか？
JSONはコメントアウトしたいときにｸﾞﾇﾇってなる
おもろい話題なのでAI使わずに書いたのを読みたい
「"」なしのfoo/true/1で型が「良い感じ」に変わる仕様はハマった時に大変。初心者に触って欲しくない。言語は型の有無好みで良いけどデータは硬い方が良い。硬いからJSONLみたいなこともできる。
正直インデントによる文法あまり好きじゃなかったけど、読んでたらYAML書きたくなってきた
YAMLはインデントに意味があるから階層を跨いでマニュアル編集する時が特にキツい。 JSONは雑に書いても対応する括弧さえ揃っていれば後でフォーマッターで綺麗にできるので楽
視認性の問題であればJSONで管理してYAMLやその他でプレビューできるビジュアライザ使うか作るかするのも手では。コメント書けないのはそうだけどjsonc, json5対応のパーサー使えば解消はする
「JSONコード」って言葉初めて聞いた
YAMLの絶対的な利点はコメントが書ける（＝コメントアウトもできる）こと。タイプ数も少なく手軽。ただしネストが深くなり過ぎるとマジで辛いので浅い構造にするよう気をつけないとやばい。
むしろAPI仕様はYAML、API実装はJSONという使い分けが普通でゎ。対決させる意味がよく分からなかった
なんかAIが自意識持って人間のマネをし始めたところ、みたいな記事。yqコマンドで一発な気もする
YAMLはJSONのスーパーセットだから拡張子をyamlにするたけで終わりだよ。
人間が読み書きする前提ならYAMLが圧倒的有利。JSONはいちおう型があるというのが利点。APIドキュメントならMarkdownでもいいような気がする。なんにせよ結局書式は決めるわけだし。
ドキュメントをAPI定義と別に書いてるってこと？前提がわからなさすぎてなんで比較してるのかわからない。
JSONはYAMLとして読めるので、JSONのままでYAMLといえる。
じゃあCBORで
人間の手が入るならYAMLだけどプログラムから扱うならJSONが楽。設定ファイルならYAMLでもいいけどAPIならJSONになるのでは
私は選べるならJSON一択。YAMLがJSONの上位互換みたいな話があるけど、データ構造の話なら分かる。YAMLのコメントは失われるけどプログラムで相互変換できる。書式自体に互換性があるみたいな書きっぷり↓が気になる。
ダブルクォートがいらなくなるのはメリットだけどインデント制御が辛い。JSONからダブルクォートを消してコメント付けられるようになればいいのに
JSONが扱いやすいんだけどコメントが書けない。YAMLは扱いにくいけどコメントが書ける…。いい感じのやつが定番になってほしい
パーサーの負荷の話は出てこなかった
「APIフォーマット」でもう駄目。レビューをJSONとかYAMLでやるよりswaggerとかでGUI化してからやったほうがいいのでは
APIの仕様ドキュメントをJSONで書く、の意味が分からねぇ
コメント書けないのはほんとにねえ…
コメントの可否挙げてる人が多いな。openapiだろうけど型定義含めtsで書いて、jsonにもyamlにも変換できそうだけどな
むかしYAMLパーサーにハマった経験があるので、人が扱うならYAML、機械が扱うならJSONと使い分ける派。 よしなに型判定してくれるのは便利そうに見えて、時折牙を剥いてくることは意識しておくことをオススメするよ…
AIは変換に混ぜものしてくる可能性が否定しづらいから、変換するなら素直な変換ツールを使うかな。あとコメントの通りだが、全部YAMLがいいとか全部JSONが良いという話ではなくて、使いどころ次第という感覚。
この記事をおすすめしました
人が編集する設定ファイルならYAML、プログラム間のインタフェースならJSONでいいのでは？
「型とかめんどくさい！ない方がいいじゃん！」と「型が無いと大変な事になるだろ！ちゃんと定義しろ！」が交互に来るプログラマ界隈
個人的にはJSONのほうが好き。JSONにコメントさえ書ければ・・・・
とりあえず間違っている点。JSONにおけるbool値は、ダブルクォート付けずに直書きで小文字のtrueもしくはfalse、が仕様です。
AIに変換させると変換後のデーターが正しいかどうかの検証が追加で発生するんで手間増えると思うんだけど。まさか自分が知らないだけでLLMに100%の変換性能がすでにあったりする？
人間に処理させるときはyaml、機械に処理させるときはjsonの使い分け。APIを人の手で呼ぶことはそんなにないから、API仕様としてはjsonのがいいんでない。バックエンドの設定ファイルとかならyamlのが好き
うちのエディターはYAMLとJSONを相互変換してくれる。／YAMLは「スペースの量が違う」ことを理由にエラーを出すので分かりにくくて嫌いだが、JSONの「コメントが書けない」も分かりにくくて嫌い（笑）
JSONの変な文字化けはYAMLではどうなるのだろうか。
たかだかJSONをYAMLに変換するくらいで「AIにフォーマット変換させる」「コマンドラインツール（ガチ派向け）」とか、読んでいてこっちが恥ずかしくなる。人類の知的レベルがどんどん低下しているのを感じさせる記事。
基本的に YAML は JSON の上位互換だけど、言語や環境がデフォルトでサポートしているという利点で JSON を選ぶこともまだ多い。
json5という、（コメントが書けたりなどする）human readable/writableなjsonもあります。tsconfig.jsonというjsonでもjson5でもない謎json実装もある…。
CiyGMLとかで何十万ノードとかあるとXMLとかjsonとかで閉じタグまで展開できなくて詰むので最近はYAMLにしてる。素人にインデントだの綴じタグ揃えさせるの無理だしね。昔のiniみたいに使えてよき。
JSONはLISP（カッコ派）と似ていて、YAMLはPython（インデント派）と似ていますね？／人間が読むならYAMLの方が読みやすくて、機械が読むならJSONの方が間違いがない、ということかな？
なんでシリアライズフォーマットとドキュメントフォーマットを比較してるだろう
AIに変換そのものをやらせるのではなく、一括で変換する方法を聞くべき。ChatGPTはちゃんとfindとyqで良い感じのワンライナー書いてくれた。
LLM感溢れる文だけどところどころAIっぽくないデタラメが過ぎるのはそこだけ人間が書いてる？
JSONとYAMLどっちがいい？APIフォーマット選びで悩んでいる開発者必見！ - Qiita
もしかしてNullさん問題もYAMLだからか？
JSONはコメントアウトしたいときにｸﾞﾇﾇってなる
おもろい話題なのでAI使わずに書いたのを読みたい
「"」なしのfoo/true/1で型が「良い感じ」に変わる仕様はハマった時に大変。初心者に触って欲しくない。言語は型の有無好みで良いけどデータは硬い方が良い。硬いからJSONLみたいなこともできる。
正直インデントによる文法あまり好きじゃなかったけど、読んでたらYAML書きたくなってきた
YAMLはインデントに意味があるから階層を跨いでマニュアル編集する時が特にキツい。 JSONは雑に書いても対応する括弧さえ揃っていれば後でフォーマッターで綺麗にできるので楽
視認性の問題であればJSONで管理してYAMLやその他でプレビューできるビジュアライザ使うか作るかするのも手では。コメント書けないのはそうだけどjsonc, json5対応のパーサー使えば解消はする
「JSONコード」って言葉初めて聞いた
YAMLの絶対的な利点はコメントが書ける（＝コメントアウトもできる）こと。タイプ数も少なく手軽。ただしネストが深くなり過ぎるとマジで辛いので浅い構造にするよう気をつけないとやばい。
むしろAPI仕様はYAML、API実装はJSONという使い分けが普通でゎ。対決させる意味がよく分からなかった
なんかAIが自意識持って人間のマネをし始めたところ、みたいな記事。yqコマンドで一発な気もする
YAMLはJSONのスーパーセットだから拡張子をyamlにするたけで終わりだよ。
人間が読み書きする前提ならYAMLが圧倒的有利。JSONはいちおう型があるというのが利点。APIドキュメントならMarkdownでもいいような気がする。なんにせよ結局書式は決めるわけだし。
ドキュメントをAPI定義と別に書いてるってこと？前提がわからなさすぎてなんで比較してるのかわからない。
JSONはYAMLとして読めるので、JSONのままでYAMLといえる。
じゃあCBORで
人間の手が入るならYAMLだけどプログラムから扱うならJSONが楽。設定ファイルならYAMLでもいいけどAPIならJSONになるのでは
私は選べるならJSON一択。YAMLがJSONの上位互換みたいな話があるけど、データ構造の話なら分かる。YAMLのコメントは失われるけどプログラムで相互変換できる。書式自体に互換性があるみたいな書きっぷり↓が気になる。
ダブルクォートがいらなくなるのはメリットだけどインデント制御が辛い。JSONからダブルクォートを消してコメント付けられるようになればいいのに
JSONが扱いやすいんだけどコメントが書けない。YAMLは扱いにくいけどコメントが書ける…。いい感じのやつが定番になってほしい
パーサーの負荷の話は出てこなかった
「APIフォーマット」でもう駄目。レビューをJSONとかYAMLでやるよりswaggerとかでGUI化してからやったほうがいいのでは
APIの仕様ドキュメントをJSONで書く、の意味が分からねぇ
コメント書けないのはほんとにねえ…
コメントの可否挙げてる人が多いな。openapiだろうけど型定義含めtsで書いて、jsonにもyamlにも変換できそうだけどな
むかしYAMLパーサーにハマった経験があるので、人が扱うならYAML、機械が扱うならJSONと使い分ける派。 よしなに型判定してくれるのは便利そうに見えて、時折牙を剥いてくることは意識しておくことをオススメするよ…
AIは変換に混ぜものしてくる可能性が否定しづらいから、変換するなら素直な変換ツールを使うかな。あとコメントの通りだが、全部YAMLがいいとか全部JSONが良いという話ではなくて、使いどころ次第という感覚。
この記事をおすすめしました
人が編集する設定ファイルならYAML、プログラム間のインタフェースならJSONでいいのでは？
「型とかめんどくさい！ない方がいいじゃん！」と「型が無いと大変な事になるだろ！ちゃんと定義しろ！」が交互に来るプログラマ界隈
個人的にはJSONのほうが好き。JSONにコメントさえ書ければ・・・・
とりあえず間違っている点。JSONにおけるbool値は、ダブルクォート付けずに直書きで小文字のtrueもしくはfalse、が仕様です。
AIに変換させると変換後のデーターが正しいかどうかの検証が追加で発生するんで手間増えると思うんだけど。まさか自分が知らないだけでLLMに100%の変換性能がすでにあったりする？
人間に処理させるときはyaml、機械に処理させるときはjsonの使い分け。APIを人の手で呼ぶことはそんなにないから、API仕様としてはjsonのがいいんでない。バックエンドの設定ファイルとかならyamlのが好き
うちのエディターはYAMLとJSONを相互変換してくれる。／YAMLは「スペースの量が違う」ことを理由にエラーを出すので分かりにくくて嫌いだが、JSONの「コメントが書けない」も分かりにくくて嫌い（笑）
JSONの変な文字化けはYAMLではどうなるのだろうか。
たかだかJSONをYAMLに変換するくらいで「AIにフォーマット変換させる」「コマンドラインツール（ガチ派向け）」とか、読んでいてこっちが恥ずかしくなる。人類の知的レベルがどんどん低下しているのを感じさせる記事。
基本的に YAML は JSON の上位互換だけど、言語や環境がデフォルトでサポートしているという利点で JSON を選ぶこともまだ多い。
json5という、（コメントが書けたりなどする）human readable/writableなjsonもあります。tsconfig.jsonというjsonでもjson5でもない謎json実装もある…。
CiyGMLとかで何十万ノードとかあるとXMLとかjsonとかで閉じタグまで展開できなくて詰むので最近はYAMLにしてる。素人にインデントだの綴じタグ揃えさせるの無理だしね。昔のiniみたいに使えてよき。
JSONはLISP（カッコ派）と似ていて、YAMLはPython（インデント派）と似ていますね？／人間が読むならYAMLの方が読みやすくて、機械が読むならJSONの方が間違いがない、ということかな？
なんでシリアライズフォーマットとドキュメントフォーマットを比較してるだろう
AIに変換そのものをやらせるのではなく、一括で変換する方法を聞くべき。ChatGPTはちゃんとfindとyqで良い感じのワンライナー書いてくれた。
LLM感溢れる文だけどところどころAIっぽくないデタラメが過ぎるのはそこだけ人間が書いてる？