テキストによる Discussion を対面での会話のように処理する人
先日、ある Zenn 記事の Discussion にコメントしたところ、かなり予想外の方向性の返信が返ってきました。その後、恥ずかしながら相手の方の思考が分からなすぎて半日ほど考えた結果、興味深い気づきがあったので書き残しておきます。
文脈
この記事の Discussion です ( Hidden comment になっている場合トグルアイコンを押して開いてください ) :
( フェイクを入れようかとも思いましたが、どうせコメントした当人である筆者のアカウントページ の Comments を漁ればすぐ辿り着ける公開情報だし、別に相手の方を貶す内容でもない ( むしろ気づきのきっかけとして感謝する内容である ) ため、そのまま見せます。もしそれでも相手の方からやめてほしい等の要望があった場合は対応します。 )
問題の場面を切り抜くと ( Rust を知らない人も、それはこの記事の本質ではないのでなんとなくで読んでください ) 、
筆者 :
文字列スライスの場合の話で認識合っておりますか？
合ってます。修正後の書き方ならとりあえず大丈夫だと思います！
( 厳密にいうと文字列リテラルもスライスの一種なので、「文字列リテラルの場合」と「文字列スライスの場合」が分かれているのは変ではあります。参考：https://doc.rust-lang.org/book/ch04-03-slices.html#string-literals-as-slices )
補足
今回は変数宣言時のString vs &strに注目して執筆したつもりでした。
&strは明示的に指定しない限り暗黙的にstatic扱いとなるため、.rodataに格納される認識です。
（つまり、静的でなければ格納されない認識ですので、おっしゃる通りに理解しております）
について、( let r: &str = &b という「変数宣言」において &str のライフタイムは明示的に指定していませんが 'static ではないです、というのはたぶん揚げ足取りだと思うので置いておくとして、 )
static扱いとなるため、.rodataに格納される認識です。
（つまり、静的でなければ格納されない認識です
という書き方をされていますが、&str 型の変数のライフタイムが 'static であることと、それが文字列リテラルであること ( 静的に決まること、.rodata が使われること ) は別の話です。
例えば
fn scoped_literal<'s>(world: &'s str) {
let hello: &'s str = "hello";
println!("{hello}, {world}!");
}
において、hello のライフタイム ( = 's ) は 'static ではない ( 'static とは限らない ) ですが、参照しているデータの実体は .rodata にあります。
一方、
use std::sync::OnceLock;
use std::io::stdin;
static USER_NAME: OnceLock<String> = OnceLock::new();
fn assert_static<T: 'static>(_: T) {}
fn main() {
{
let mut buf = String::new();
stdin().read_line(&mut buf).unwrap();
USER_NAME.set(buf).unwrap();
}
let user_name: &str = USER_NAME.get().unwrap().trim();
assert_static(user_name);
println!("Your name is `{user_name}`!")
}
では、user_name の値はユーザーの入力によって動的に決まりますが、ライフタイムは 'static です。
相手の方 :
感謝したいのは山々なんですが...初対面で重ーい😂
「揚げ足〜」のところでクドくて閉じちゃいました笑
オタクの悪いところ出てますよ！
ご指摘いただいた箇所については本記事のテーマではないので割愛します！
「スライス」「リテラル」と２つのワードを並べて記載＋コード例も添えているので、ある程度意図は推測可能かと思います🙆♀️
にしても、良い経験になりました！また機会があればよろしくお願いしますね🥰
となります。
( 初見時 ) 予想外ポイント
1. 唐突な「感謝したいのは山々なんですが...また機会があればよろしくお願いします」構文
「感謝したいのは山々なんですが...また機会があればよろしくお願いします」は、ビジネス会話や初対面の人との会話において、関係性を悪くしたくない相手に対して「ありがた迷惑です」を婉曲的に伝える言い方だと思います。
しかし筆者の認識では Zenn の Discussion は本質的にはその名の通り「議論」をする場であるため、この構文は場違いに感じ、面食らいました。
「補足」を ( 読む必要もそもそもないですが、あえて ) ありがた迷惑だと伝えたいのであれば、単に「修正後の書き方ならとりあえず大丈夫だと思います！」に対する「ありがとうございます」くらいで始めて
ご指摘いただいた箇所については本記事のテーマではないので割愛します！
「スライス」「リテラル」と２つのワードを並べて記載＋コード例も添えているので、ある程度意図は推測可能かと思います🙆♀️
とだけ書けばいいのでは？と思いました。
2. 対面じゃないのに「初対面」
Discussion はテキストコミュニケーションをする場なので、初「対面」という表現が登場したことにも驚きました。
これはすぐに「 ( 比喩的に、テキストでも ) いままであなたと会話したことがない」くらいの意味だと分かったので「そういう言い方をする人もいるんだなー」くらいに思っていたのですが、後の気づきの最初のきっかけになりました。
3. details 含めこれくらいの文量で「重ーい」「クドくて」
筆者の認識では、この details の「補足」は
- 前述の通り、そもそも読みたくなければ読まなくていい
- 本文と合わせてこれくらいの文量なら 10 秒くらいあればパースでき、取捨選択しやすい
という感じだったので、「重ーい」「クドくて」という返信は全く予想外でした。
また、「初対面で重ーい😂」という形で登場するのですが、これも「逆では？」と感じました ( 「初対面」だからこそ相手のレベル感が分からないので省略しづらく長くなる・見知った間柄で相手のレベル感ががわかれば省略が効いて短くできることがある ) 。
4. ニュアンスがわからない「オタクの悪いところ」という表現
筆者は、技術文脈での「オタク」という言葉は「特定の技術などが好きで、いつもそれに可処分時間の結構な割合を費やしている人」くらいの意味の言葉として認識していたので、この返信における「オタクの悪いところ」という言葉は単純に意味がわかりませんでした。
気づき
結論から言うと、「もしかして、この人はテキストコミュニケーションを 対面での会話と同じように 処理しているのでは？」という仮説に辿り着きました。
この視点から見ると、上記の予想外ポイントの全てを説明できます：
1. 唐突な「感謝したいのは山々なんですが...また機会があればよろしくお願いします」構文 ・ 2. 対面じゃないのに「初対面」
対面での会話と同じように考えると、相手の方と筆者は文字通り「初対面」であり、何かをありがた迷惑だと伝えるのに「感謝したいのは山々なんですが...また機会があればよろしくお願いします」のような言い方をするのは普通のことです。
3. details 含めこれくらいの文量で「重ーい」「クドくて」 ・ 4. ニュアンスがわからない「オタクの悪いところ」という表現
対面での会話を書き起こしたものとしてコメントを見てみると、「補足」を含めた筆者のコメントは
みたいなことを一方的に 喋って いることになります。
そう、テキストで渡しているのではなく、一方的に 喋って いることになります。
そりゃあ嫌でしょう。筆者も、( 当たり前ですが ) 対面での会話ならそんなことはしないですし、されたくないです。
しかし筆者のコメントを対面での会話と同じように処理しようとするとこうなるわけで、こう考えると「重ーい」「クドくて」という反応もわかりますし、「オタクの悪いところ」という言い方も ( 「会話において自分の興味のあることを一方的に話し続けてしまう人」のような意味として ) 理解できます。
テキストコミュニケーションと対面会話の違い
テキストコミュニケーション
テキストコミュニケーション ( 特に議論 ) においては、誰かのコメントが来たらまず全体を見てパースし ( 構造を取り ) 、
- 言われなくてもわかる部分、自分には関係ない部分などを飛ばして理解する
- じっくり読みたいが今は時間がないので読めない部分はどこかにメモする
などと自由に扱えます。
なので、コメントする側もそれを見越して１コメントあたりの情報量をある程度大きくすることで、コミュニケーションの効率を上げることができます。
「補足」の構造 ( 10 秒くらいあればパースできる想定 ) :
引用
( { 一応の指摘 } 、というのはたぶん揚げ足取りだと思うので置いておくとして、 )
{ &'static str
例えば
{ ( &'static str )
一方、
{ ( &'static str の例 }
{ 参考資料 }
対面での会話
対して、対面での会話 ( Zoom や Skype などでの会話も含む、要するに spoken conversation ) では、テキストコミュニケーションのように「全体をパースして取捨選択する」みたいなことができず、文量に関係なく「最初から最後まで順番に聞く」しかないという制約があります。
例えば、相手の方の「クドくて」は
「揚げ足〜」のところでクドくて
という形で登場しており、「補足」の
今回は変数宣言時のString vs &strに注目して執筆したつもりでした。
&strは明示的に指定しない限り暗黙的にstatic扱いとなるため、.rodataに格納される認識です。
（つまり、静的でなければ格納されない認識ですので、おっしゃる通りに理解しております）について、(
let r: &str = &bという「変数宣言」において&strのライフタイムは明示的に指定していませんが'staticではないです、というのはたぶん揚げ足取りだと思うので置いておくとして、 )static扱いとなるため、.rodataに格納される認識です。
（つまり、静的でなければ格納されない認識ですという書き方をされていますが、...
の ( ) 内について言っているわけですが、筆者としては
- 他の部分から、相手の方はたぶん実際には理解していそうなので単純な書き損じだと思われるが、「初対面」の相手なので本当にそうだという確信が持てず、念のため指摘として消さずに置いておかざるをえない
- パースしやすいように、実際には理解している場合は即読み飛ばせるように
( ... というのはたぶん揚げ足取りだと思うので置いておくとして、 )というマーカーを付けている
というつもりでした。しかし、もしこのコメントをテキストではなく spoken conversation と同じように処理しようとすると、マーカー云々は関係なく
という「発言」を「最初から最後まで順番に聞く」ことになるので、「揚げ足〜」のくだりで「クド」くなるのもわかります。
読み上げソフトパターン
以上で「テキストによる Discussion を spoken conversation のように処理する人もいるんだなー」で終わってもいいのですが、考えているうちに、このような人には
- 単にそういう性質の人である
- 目が不自由で読み上げソフトなどを使っているためそうせざるをえない
の２パターンがあることにも気づきました。
まとめ
- 世の中には、テキストによる Discussion を spoken conversation のように処理する人もいることを知りました ( 厳密にいうと、そう考えないと説明がつかないように見える人を観測した ) 。
- 経験上、Zenn に記事を投稿するような人でそのような人はかなり少ないと思っているので、今のところは Zenn の
Discussionでのスタンスを変えるつもりはないです。
Discussion