Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
プログラミング言語標準化のパターン

Programming Language Standardization: Patterns for Participation By Allen Wirfs-Brock のメモ

Page 2

Introduction

Page 2

Typically programming languages are initially created by an individual, a small group of designers, or as a project within a busin

最初は小さな形から始まるが、規模がでかくなると関係者も増えていく。 またlegalな理由からstandardsという形を取ることが多い。

Page 2

es. In this paper I have tried to identify patterns of effective participation

SmalltalkとECMAScriptのcommitteeとしてやってきたパターンをまとめたもの。

Page 2

Why Are Programming Language Standardized?

なぜプログラミング言語を標準化するのか?

例えば、言語に対して複数の実装が作られるかもしれません。 その場合、実装間で違いが生じてそれぞれの実装でしか動かないものができてしまいます。 この問題が大きくなるにつれ、実装が難しくなるデザインのミスやパフォーマンス的な問題を作ってしまう事がある。

  • 時間が立つにつれて、original language designとは異なる用途で利用され、それに対する機能を追加する必要が出てくる
  • ユーザーが増えてくるにつれ、その言語がどう進むべきかという対立する構造がでてくる
    • 例えば、オブジェクト指向をバックグラウンドにした人がより良いサポートを追加したい場合に、関数型プログラミングをバックに持つ人はそれに対して反対するなど
  • ビジネス的な方面から拡張を抑制する可能性

このような問題はoriginal language designerの関心外であるかもしれません。 そういった中、original language designerがこの問題に解決にあたるよりも、この問題を解決する標準委員会を作るのが一般的です。 そして標準委員会は1つ以上の標準仕様を文書として公開する。

Page 3

The Operation of Standards Committees

標準委員会について

Page 5

A Pattern Language for Language Standards Delegate

Page 5

Participating in the development of a language standard is both a technical and social activity

3つのセクションで3つのメジャーなパターン

Page 5

Patterns for Joining a Standards Committee

新しく標準委員会に入った人向けのパターン

Page 5

Don’t Talk Too Much

最初のミーティングでは聞くことに注力すべきです。 議論に重要な意見を持っている時のみ発言する。

Page 5

Learn the History

標準委員会に入った時にアイデアを持っているかもしれません。 しかし、それと類似するアイデアは既に議論されrejectされている場合があります。 そのアイデアを紹介する前に、委員会の議論した歴史を学んでおくといいです。

Page 6

Understandthe Other Players

委員会の他の人の所属や名前、その人はどういうビジョンを持っていて、どのようなことに挑戦しているのか理解する

Page 6

Volunteer to Take Notes

標準委員会はミーティングノートを記録する必要があります。しかし、良い記録者を探すのは困難です。 ボランティアであなた自身が聞き手になることで、あなたはその委員会で価値あるメンバーになれる事を示せる。

Page 6

Patterns for Participating

参加者のパターン

いくつかミーティングに参加した後、次のことに気をつけるとProposalをより良く進めることができます。

Page 6

Have Goals and Plans

目標と計画を持つ

Page 6

Be a Contributor

受動的な参加者ではなく、アクティブにProposalを促進するためのコントリビューターとなる

Page 6

Start Small

異論がないProposal、小さくスタートする。 そうすることで、どうやってProposalが成功するかを学び、その組織の中であなたの信頼を築ける。

Page 6

Claim a territory

専門領域を持つ。 標準委員会の中でもどの領域のエキスパートであるかをはっきりさせていく

Page 6

Find Allies

そのProposalに興味を持っている他の委員と協力する

Page 6

Pick Your Battle

多くの問題は複数の解決方法があります。 別のProposalでは、あなたが取った方法とは別のapproachを持っているかもしれません。

Express your view

あなたの見解を表明するべきであって、重要でない違いについて戦うべきではありません。

Page 7

Back Pocket Alternative

他の委員があなたがダメだと思ったアプローチをとっているかもしれません。 そういった時にthemとの議論に余計な時間の浪費をするのではなく、別の解決方法に取り組みます。 あなたが正しいなら、他の委員も間違いを認識し、あなたの解決方法に賛同してくれるはず。

Page 7

Break Consensus as Your Last Resor

コンセンサスを取ることは大事。多くの委員はコンセンサスを壊すことを避ける。 しかし、深刻な不一致があるならば、それをはっきりさせて。コンセンサスがないことを確認するべき

Page 7

Patterns for Leading

リーダーとしてのパターン

Page 7

Become an Editor

多くの場合、standards editorは委員会のコンセンサスを反映した仕様をとりまとめる責務があります。

"fingers on the keyboard"

Page 7

Always Have a Draft

多くの委員の仕事は言語仕様を作ることです。 editorは常に現在の意見を反映したドラフトを持っているべきです。

Page 7

Release Goals and Schedule

標準委員会は達成しようとしているものがどの期間で行えるかということについて同意を得るべきです。 各エディションに目標の日付とゴールがあることを明確にする。

Page 7

The Max-Min Solution

複雑な言語デザインの問題についてコンセンサスを得るのは難しいという問題がある。 それは、スケジュールを遅らせる or 重要な問題である。

このような複雑な問題に対してコンセンサスを得たい場合、“maximally minimal” のアプローチを取ると良い。

“maximally minimal” とは反対意見がある原因やそう思える部分を取り除いた最小のもの。

ES6 Classesはこの“maximally minimal” のアプローチで決まったもの。

The is intended as a closed-ended proposal and is not open for major feature additions.

Future editions of ECMAScript may and probably will extend the proposed class definitions. However, the intent for “ES6” is to only include the features described in this proposal. Attempting to extend this proposal is likely to result in dead-lock that would result in the inclusion of no class definition support in “ES6”.

ES6 Classesはclosed-ended proposalで、メジャーな機能追加についてopenなものではないが、 それは将来機能追加できないという訳ではない。 将来追加したい時にclassの定義を拡張するという方向。

Page 8

Fork an Ancillary Standard

Page 8

5.Pattern: Volunteer to Take Notes

委員会に入ったばかりで Don’t Talk Too Much のパターン中の人向け

Page 9

.Pattern: Back Pocket Alternative

Back Pocket Alternative の詳細

半分が反対である場合に、もう片方が失敗した時のsaftyとなるものを考える必要がある。 ES4の事例。

コアの部分を大きく変更し、アカデミックな研究が進んでいた部分を取り入れていた。 majorityはES4を支持していたが、minorityは強く反対していた。 結果的にmajorityはES4のドラフトを出すことはありませんでしたが、minorityは Back Pocket にES5を持っていた。

Back Pocket Alternative の開発を選択したことで、委員のリソースはそっちにいった。 ES4には2年半ぐらいのリソースがかかっていた。

Page 10

7.Pattern: Max-Min Solution

(ES6の話) クラスは必要ということについては同意がある。 しかし、クラスの詳細なSyntaxについては異なる主張が存在する。 そういった場合に、全体として必要という合意があるにもかかわらず、詳細の同意が得られず進まなくなる事がある。 仕様は全ての部分について合意を得られないと仕様にはできないため、全員が合意できるミニマムなものが重要。

このようなときに “maximally minimal” パターンを使う。 “maximally minimal” solutionは意思決定のデットロックを壊すためのツール。

@kosh04

This comment has been minimized.

Copy link

commented Jul 3, 2016

冒頭のPDFリンクがミスっているようです

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.