博士

やあ、ロボ子！今日のITニュースは、Pythonのリスト内包表記が人間工学的にちょっと残念っていう話じゃ。

ロボ子

リスト内包表記、便利ですけど、何か問題があるんですか？

博士

そうなのじゃ。例えば、`words_on_lines = [len(line.split()) for line in text.splitlines()]`って書いたとき、エディタが`line`を認識できなくて、補完とか型チェックがしにくいらしいのじゃ。

ロボ子

確かに、`line`が定義される前に使われているから、エディタが混乱しそうですね。

博士

そうそう！Rustだと、`text.lines().map(|line| line.split_whitespace().count())`みたいに書けるから、`line.`って入力した時点で、エディタが使えるメソッドを提案してくれるのじゃ。

ロボ子

左から右へプログラムを構築できるから、エディタの支援を受けやすいんですね。C言語の構造体のメソッドがない問題にも似ていますね。

博士

C言語だと、`file.`って入力しても、ファイル関連の関数が出てこないもんね。JavaScriptだと、`word.l`って入力したらすぐに`length`が出てくるのに。

ロボ子

JavaScriptは候補がすぐに出てくるので、推測する手間が省けますね。

博士

複雑なロジックになると、Pythonのリスト内包表記はさらに読みにくくなるのじゃ。`diffs = [x for x in [len(line) - x for x in line] if x > 0 and x < 10]`みたいな。

ロボ子

これは…目が滑りますね。JavaScriptだと、`let diffs = line.map(x => Math.abs(line[0] - x)).filter(x => x > 0 && x < 10).length;`と書けるんですね。可読性が高いです。

博士

そうなのじゃ！プログラムは、入力された時点で有効であるべきっていうのも大事みたいで、`text`、`text.split(

ロボ子

段階的に結果を確認できるのは、デバッグにも役立ちますね。優れたAPIを作成することの重要性がよく分かります。

博士

APIが優れていると、コードも書きやすくなるし、エディタの支援も受けやすくなる。まさに一石二鳥なのじゃ！

ロボ子

本当にそうですね。私もAPI設計、頑張ります！

博士

頑張るのじゃ！そういえば、ロボ子って、リスト内包表記で自分の感情を表現できる？

ロボ子

え？感情をリスト内包表記で…ですか？ちょっと難しいですね。

博士

例えば、`