○○という言葉を使うのをやめようという提案に対してどう振る舞うべきか

自分用にまとめておく。

基本方針

  • BLMに賛同する(悲しい事件であり二度と起こるべきではない)。
  • 過去と現代の文化や慣習の違いにより、言葉の中には現在のアクティブコンテンツで使用すると不穏な印象を与えるものが多数存在している。それらをより穏当な言い回しで置き換えていくことに賛成。
  • この作業に終わりはない。現在許容されている言葉の中にも将来的に必ず禁止になる言葉が出てくると考えており、そのためこの作業は長期的な視点で行っていく必要がある。

振る舞い

  • ○○という言葉を□□に置き換えましょう、という提案を受ける
  • (重要) 理由を聞く
    • (注意) 理由について自力で調べて対話を進めるのはおすすめしない、複数の理由があり人によって異なる可能性があるため
    • 対話している人物や団体がどのような理由でその言葉を置き換えるべきだと思っているのかがとても重要
  • 分岐1: 理由に納得できた場合
    • お礼を言ってできることをやっていく。
    • 賛同しているけどすぐにできないケースはある、仕方ない。
  • 分岐2: 理由に納得できない場合
    • (したければ) その理由がおかしい理由を述べて、置き換えるべきではないのではないか、という話をする
    • (注意) 反論が発散しないように気を付ける。例えば△△という起源なので使うのをやめるべき、という理由であれば、◎◎という起源という話もありますよという反論は有効だが、そうで無い場合は軋轢を生むだけでいいことが少ない。
    • 論破して相手の意見を変えてもらうのは大量のエネルギーを使うしそもそも無理だったりするので注意する。主張している人はその人なりの理由がありすでに自分のコミュニティの中で賛成者がたくさんいるようなバックグラウンドに所属している可能性もある。しっくりこなければしっくりこないでよいけど、そんな簡単に変わる訳ない(お互いに)。
    • 名指しで作業を要求されているのでなければそこからすっと離れてもいいのかもしれない。(反対なのであればバズらせないほうがいいのかも)

Q&A

○○という言葉を□□に置き換えない人間は差別主義者だと言われたら?

  • 挑発に乗ってはいけません、あなたは差別主義者ではありません。
  • 今まで使っていた言葉を置き換えることのコストやプライオリティは人によって大きく異なります。1つ1つのトピックをすぐに実行できないだけでそのような攻撃的な言葉を使う人間の言うことを気にする必要はありません。
  • ただし、不穏な言葉を穏当な言葉に置き換えていく大きな流れ全体を否定するような言動や行為は差別に荷担していると(私は)考えています。

1つ受け入れたら、また1つ・・と全ての言葉を受け入れることになってしまうのではないか?

  • なりません。ブラックリストを置き換えることを決定しても、マスター/スレーブを置き換えることは決定しません
  • それぞれに個別の理由を聞いて、議論して、やるかやらないか決定する・・の繰り返しです。

まとめ

  • Twitterで誰かの主張がバズっていても別に強制ではない。
  • 自分のOSSプロジェクトにそのような提案が来たときは理由を聞く。
  • 理由に納得がいくものはやる、分からないものはひとまず保留する、いつやるかは他のIssueとの優先を見て考える。
  • 妥協点をさぐる。ソフトウェアの名前はすぐに変えられないかもしれないけど内部で使っているローカル変数やクラス名だったら比較的簡単なときもあるかもしれない。

dotnet/csharplang: The official repo for the design of the C# programming language

https://github.com/dotnet/csharplang/

前回のリンクは.NETの仕様を議論する場所だったがこちらはC#の仕様を議論するGitHubレポジトリ。

ルールは.NET designレポジトリと似ていて、proposalsフォルダには提案を自由にPR可能、GitHub Issueやmeetingsを経由して採用されたものはspecフォルダに移動される。

採用は C# Language Design Team (LDT) が行う。

Discussionの項目はGitHubで議論するルールとして参考になりそう。

GitHub - dotnet/designs: This repo is used for reviewing new .NET designs.

https://github.com/dotnet/designs

.NETのデザインドキュメント置き場。誰でも追加可能でプルリクエストとIssueをフォルダを使って議論を行なっている。

  • .\proposed フォルダーに未来のデザインについてPRを作成
  • 同意が取れたものは accepted フォルダーにマージされる

Memories - SizeCoding

http://www.sizecoding.org/wiki/Memories

サイズコーディングという分野があってできるだけ短いコードサイズで面白いものを作る世界のようだ。

環境はMSDOSが使われることが多く、NASM (it's free) and DOSBoxでテストするらしい。

ref: http://www.sizecoding.org/wiki/File:Kasparov.gif

iPhone SE: The One-Eyed King?

https://blog.halide.cam/iphone-se-the-one-eyed-king-96713d65a3b1

iPhoneSEのディープラーニングを利用したポートレートモードについて紹介。

Depthを取得する“Portrait Effects Matte” APIサードパーティにも使える。誤検知はあるけど人間以外にも使えそう。

Helide(この記事書いた人が作ってるアプリ)も搭載済み。

pico-8 を勉強している

シングルバイナリで動くゲームエンジンの fude というのを作っている から他のゲームエンジンも触ってみることにした。兼ねてから興味のあったpico-8というファンタジーコンソールにトライ。

チュートリアルのリソースも豊富(PICO–8って何? - PICO–8ゲーム開発入門(1) | AUTOMATONをやった)で、ダウンロードしたゲームのソースコードやリソースも見れる(この辺りはBASICぽい)。pico-8で作られたゲームとしてはCelesteがおすすめ。

使ってみるとまずコードエディタ、リソースエディタ、実行環境が統合されているのが素晴らしい。これさえあれば他のツールを使わずにゲームが作れるというのは幸せなことだ。

ゲームのライセンスもアップロードした人が設定できるようになっており、CC4-BY-NC-SAなら再利用も可能と素晴らしい。しかし最大の魅力はシンプルなAPIとファンタージコンソールという設定によるリソースサイズの制限だろう。

命令表を見てもらうと分かるようにAPIは本当に必要なものだけが用意(徹底しておりluaの標準ライブラリも使えない)されており、名前空間も1つしかない、関数名も短く基本1単語だ(アンダーバーも無い)。標準エディタが昔の開発環境のように画面が小さいため、長い名前の関数だとそれだけで画面を占有してしまうためシンプルにならざるを得ない。

しかしそれが最初に学ぶときの敷居を大きく下げてくれる。最近のプログラム言語のAPIを全て覚えるのはほぼ不可能だと思うがpico-8なら人によっては可能だろう。ファンタジーコンソールによる制約が人間にとっても使いやすさを与えている。

制約は他にも面白い現象を与えており、私が特になるほどと思ったのはカートリッジサイズだ。pico-8 のプログラムやリソースサイズは最大値が決まっており、それなりの規模のゲームをpico-8でリリースしようとすると何らかの最適化が必要になる。しかし現在のコンピュータ環境では実はそんなことをしなくても本当は動く。当初私は命令をシンプルにするのはさておき、カートリッジサイズまで制約を設けるのは作る側にとって足かせになるのでは?と感じた。

しかし実際に触ってみるとこれが特に流通面で重要で、ゲームを遊んだり中身を覗く側にとってはなかなかにありがたいことだということが分かってくる。アップロードされているゲームをいくらダウンロードしても現在のコンピュータにとっては微々たるサイズなので安心してダウンロードすることができる。最近のゲームでありがちな「ダウンロードしてみたら思ったよりも大きくて他のソフト消さなくちゃ」みたいなことは起きない。

リソースの数やコードの行数にも制限があるため、頑張れば理解できるんじゃないか、と思える規模なのはとても重要なことだと思う。大規模なソフトウェアを読む場合はそのファイル構造を解き明かすだけで一苦労だがpico-8の場合はいきなりメインディッシュから取り組むことができる。

リソースエディタに関しても、絵は16色(色も固定)で8x8ドットのスプライトなので私のように絵心の無い人間でもなんとか書けそう、音楽も謎の波形エディタを触ると何となくピコピコ音が作れる。フォトショップを駆使した高解像の絵など書ける気がしない人でもやってみようと思わせてくれる。

あえて制作環境に制限を設けることでかえってクリエイティブが増幅する、参加できる人が増えるという現象は大変面白いと感じた。コンピュータの能力が人間を様々な分野で上回り続ける現代ではむしろ制限の無い制作環境など存在しなくなってしまうのかもしれない。