「オブジェクト指向神話からの脱却」という特集をWEB+DB PRESSで書きました - きしだのHatena
「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。 12/24発売！クリスマスプレゼントです WEB+DB PRESS Vol.132 作者:きしだ なおき,加藤 尋樹,斉藤 洸紀,牟田 裕太郎,吉澤 政洋,朝日 リナ,鈴木 僚太（うひょ）,川島 義隆,五十嵐 進士,末永 恭正,佐藤 雄太,吉井 健文,牧 大輔,西山 和広,吉田 花春,古川 雅大,岡林 大,池澤 春菜,和田卓人,日高 正博,はまちや2,竹原技術評論社Amazon 大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ！という内容です。 ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開
サーバーレスは操作的意味論の夢を見るか？ #AWSDevDay / AWS Dev Day 2022 Japan
AWS Dev Day 2022 Japan で使用したスライドです。 AWS Lambda を初めとするサーバーレスコンピューティング基盤には、 * 複数の関数が同時に実行され共有リソースにアクセスしうる、本質的に並行システムである * Warm Start により関数インスタンスが内部状態を残したまま再利用されうる * 一つのリクエストに対して複数回の実行が行われうる、いわゆる At-Least-One 特性 といった特性があり、通常のプログラムと比較して実行モデルが複雑かつアンコントローラブルな要素を多く含みます。関数を実装する側はこのような「プラットフォームの都合」を考慮して冪等性など細かい挙動に気を配りつつプログラムを書くことになり、これは一般にかなりの実装コストになります。また、アンコントローラブルな要素は、関数の実装から実際の挙動を静的に検査することを難しくしています。 この
インスタンスとオブジェクトの違い - きしだのHatena
インスタンスとオブジェクトは混同しがちで区別がようわからんになりがちです。 とりあえず某所で説明したものを再構成します。 ※2022/12/10追記: クラスに対するのはインスタンスになるべき(たとえばクラス変数とインスタンス変数)なので、ちょっと修正するべきですが、このエントリはそのまま残してます。 クラス・インスタンス・オブジェクト クラスをインスタンス化(実体化)したものがオブジェクト(物)です。 実際に在るものはクラスとオブジェクトで、インスタンスはそれらの関係です。colorsやsportsが並んでるツリーが「オブジェクト」で、右のパレットに並んでるTreeが「クラス」、Treeからみたときのツリーが「インスタンス」ということになります。 ここでツリーはオブジェクトでもインスタンスでもあります。 このように、同じものをオブジェクトともインスタンスともいうことができるので混同してし
オブジェクト指向は継承で多態するプログラミング - きしだのHatena
オブジェクト指向って継承による多態があるからこそなんだけど、継承が非推奨になって以降に雰囲気でオブジェクト指向を知った人には、継承はオプションでカプセル化だけでオブジェクト指向って言ってしまいがちに思います。 実際はカプセル化はオブジェクト指向固有じゃなくて、クラスでカプセル化を実現してるだけです。 さまざまな人のオブジェクト指向の定義 本来ならどのように継承こそがオブジェクト指向なのかという説明をするんですが、かなり長くなりそうなので、とりあえずはいろいろな人たちのオブジェクト指向の定義を抜き出してみます。 「ここに挙がってるのはオブジェクト指向の一派にすぎない」というような意見もありますが他の派閥についてまとまって定義され共通認識になっているようなものは見当たらないので、プログラミングの指針には なりづらいと思います。 ストラウストラップ C++を産んだストラウストラップは「C++の設
ゼロからはじめるJavaScript(18) 可読性と表現力の高いデータ形式「JSONC」を活用しよう
最近、よく目にするデータフォーマットに「JSONC」があります。これはJavaScriptでお馴染みのJSON形式にコメントを記述できるよう拡張したものです。Visual Studio Codeでも採用されており、設定ファイルとして利用されることが増えています。そこで、JSONCの記法やJavaScriptから使う方法を確認してみましょう。 JSONCは可読性の高いデータフォーマット JSONCとは 「JSONC(JSON with comments)」とはJSONにJavaScriptスタイルのコメントを記述できるようにしたデータフォーマットです。そのため、基本的にデータフォーマットのJSONなのですが、そこにJavaScript風のコメントである「// コメント」と「/* コメント */」を記述できるようにしたものです。 冒頭で紹介したように、プログラミング用のエディタ「Visual
なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
データ構造化における抽象化の定義 - 構造化プログラミングにおける覚え書きその5 - dhrnameのブログ
データ構造化における抽象化の定義 前回 オブジェクトクラス同士でのダイクストラ連接 - 構造化プログラミングの覚え書きその4 - dhrnameのブログ ホーアの「データ構造化序論」 75年に翻訳され出版された『構造化プログラミング』*1の第二部で、ホーアは「データ構造化序論」を執筆した。ホーアによれば、ダイクストラとウィルトの助言に従って、この論を書いた。その論に従い、「抽象（abstraction)」、あるいは、「抽象化」について定義していこう。 抽象化の四段階 一般に、抽象は、人間の思考の上で重要な役割をになう。それ以上に、プログラミングとは深い関係がある。「データ構造化序論」の中で、ホーアは抽象について次のように述べた。 複雑な現象を理解してゆく過程において、人間の理解力の助けとなる最も強力な道具は抽象（abstraction)である。（中略）抽象の過程は4つの段階に要約される。
オブジェクトクラス同士でのダイクストラ連接 - 構造化プログラミングの覚え書きその4 - dhrnameのブログ
この記事について 前回 データ構造化理論の型選択演算子によるダイクストラ選択 - 構造化プログラミングの覚え書きその3 - dhrname’s diary 今回は構造化プログラミングで触れられているオブジェクトクラス同士のダイクストラ連接について考察を加える。なお、この記事は私個人による独自解釈である。 「オブジェクト(対象, object)」、「クラス(class)」、「インスタンス(実例, instance)」、「サブクラス(部分クラス, subclass)」「new構文」の定義は1975年に日本で出版された「構造化プログラミング(ダイクストラ、ホーア、ダール共著、野下、川合、武市共訳、サイエンス社）」に従う。 ダイクストラ構造化原理によれば、「3パターンの制御構造による抽象化 = 型付け」である。その3つのパターンのうち、今回はダイクストラ連接について考える。第三部のクラスプログラミ
「THE」が商標登録される
英語で使われる「THE」は、すでに会話の中で言及されているもの、あるいは読み手・聞き手にとって既知のものを示す名詞の前につく定冠詞で、英語の中で最も使用頻度が高い単語です。そんな「THE」の商標登録を、アメリカ特許商標庁が2022年6月21日に認めました。この商標はTシャツ・野球帽・その他帽子に適用されます。 The Ohio State University Officially Trademarks the Word ‘THE’ - WSJ https://www.wsj.com/articles/the-ohio-state-university-officially-trademarks-the-word-the-11655926237 Ohio State secures the trademark for the word "THE" — Quartz https://qz.c
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://web.archive.org/web/20170208052455/http://www.dtic.mil/dtic/tr/fulltext/u2/761962.pdf
順序機械 - 岩波書店
https://web.archive.org/web/20131225084408/http://www.edelweb.fr/Simula/scb-1.pdf
https://dl.acm.org/doi/pdf/10.1145/356635.356640
日本のデジタル競争力、過去最低29位 中韓台にも後れ - 日本経済新聞
Structured Programming : O.-J. Dahl, E. W. Dijkstra, C. A. R. Hoare : Free Download, Borrow, and Streaming : Internet Archive
E.W.Dijkstra Archive: The structure of the THE-multiprogramming system (EWD 196)
Paper1: Review: Edsger W. Dijkstra. The Structure of the "THE" Multiprogramming System
E.W.Dijkstra Archive: Concurrent programming: a preliminary investigation (EWD 476)
E.W.Dijkstra Archive: Finding the correctness proof of a concurrent program (EWD 640)