魔法遣いに大切なこと - みねこあ
JavaBlackさんち経由、Shibu's Diary: これから魔法使い(プログラマー)になる、新卒者のみなさんへ わたしは JavaBlackさんほど反感を覚えなかったのですが、それはわたしが厨二病を拗らせて慢性化させているからでしょう*1。スレイヤーズあたりを魔法の認識の礎のおいている痛い人間としては、プログラミング = 魔法 にあんまり違和感を覚えません。L様系の呪文はバグってるバージョンではパフォーマンスがイマイチだったりとか。あと魔法がクラウドだったりとか(Ruby-Eye AppEngine みたいな)。 「魔法遣い」と言われるには、普通の人が普通の人の常識ではデタラメに見えるくらいの手腕でなにかを現実にする技術を持っている必要があります。・・というかそういう相対的視点での超絶技巧が「魔法」と呼ばれるのでしょう。逆に何かが魔法に見えるということは、その何かに対して「素人」で
Smart UI について、だらだらと - みねこあ
昨年のエントリー、 DDDについて、だらだらと からのびのびになってしまいました、 Smart UI アンチパターンについて。 Smart UI アンチパターンは コの業界で非常に目にするパターンで、また、素人が素人のままで仕事が出来てしまう パターンなのですが、その是非を論じる前に、まずはどういうものかを整理したいところです。 一言で言えば、「Smart UI、アンタ良い者なん？悪者なん？」 * * * DDD の Smart UI “Anti-Pattern” を読んでいると、これは本当にアンチパターンなのかとも思えてきます。 Advantages Productivity is high and immediate for simple applications. シンプルなアプリを作る上では生産性は超高いし、出来るのも早いよ！ Less capable developers can
ハイブリッドOOPLの呪い - みねこあ
手続きプログラミングとオブジェクト指向プログラミングはなんだかどうも癒着してしまって、別のプログラミングパラダイムという気がしてこないのが、実は諸悪の根源なのではないかと思ってしまいます。 C++ なんかでは、OOPLになったといっても手続きを流し込む大箱が追加されただけで、メンバ関数の中に降りていけば、そこに見慣れた手続きプログラミングが広がっています。Smalltalk なんかですと、メソッドの中の小コードであってもこれはもう手続きではなくって、メッセージ式が連なっていく様はむしろ関数言語に似ています。 「純粋OOPL」「ハイブリッドOOPL」の違いは、「全てがオブジェクトであるか」とか「最初からOOPLとしてスクラッチビルドされたか、既存言語を増築したか」ではなく、実はこの差なのでは、と思います。sumimさんが啓蒙されているような「二つのOOP」があんまりフツーには知られていなかっ
Lightweight Languageとは - みねこあ
ときどきの雑記帳さんで、2chのム板で LL が和製英語だという話題について、きむら(K)さんのコメント たしか北米の東海岸で二回だか三回ぐらいしか開催されなかったイベントで LLって名前をつけたんじゃなかったっけ? 適当に名前をつけたのでかっちりした定義はないとか言うのを読んだ覚えが。 わたしもそんなの読んだ記憶があるなぁ。と、本棚をごそごそ。ありました。 Lightweight language magazine―ライトな言語でプログラミングを楽しもう! (アスキームック) 作者: IRIコマース&テクノロジー出版社/メーカー: アスキー発売日: 2004/03メディア: ムック購入: 2人 クリック: 25回この商品を含むブログ (17件) を見る これの、まつもとさんの「Lightweight Language とは？」に、用語の定義とそれが決まったいきさつが乗っています。 本来L
OOPと自動メモリ管理 - みねこあ
Simula は サブルーチンの不自由さに対し改善を施すことで、クラスとオブジェクトを発明しました。その副作用として、コールスタックによる自動メモリ管理が使えなく(←「コイツ使えね~っ」の「使えない」）なってしまいました。 * * * 「階層的プログラミング構造」Ole-Johan Dahl, C.A.R Hoare より引用しつつ。 Simula が シミュレーションのための言語を模索する過程で クラス・オブジェクトの発明に行きいきさつは、 平行しているプロセスを表現するために, 対応するプログラム要素が,計算機で多重プログラム(multiprogram)処理されなければならない,というわけではない.しかし,プログラムは,一時的に停止(中断)し,後で止まっていたところから再び実行出来ることが必要である.そこで動作している対象,すなわちシミュレーションにおける“プロセス”は,スケジュール機
あなたの知っているOOPをすべて書き出しなさい(配点:5点) - みねこあ
「オブジェクト指向でなぜ作るのか」以来、OOP が解らなくなってしまった三猫です。あーー、もう、わっかんない、と混乱のまっただ中にいる私にかけられた、sumim さんの優しい言葉。 とりあえず、ケイのメッセージングのＯＯとストラウストラップら（リスコフ、メイヤーなど）の抽象データ型のＯＯの要点について、みねこあさんなりの解釈を簡単でいいので箇条書きにでもしてもらうことはできますか？ そこからすりあわせたほうがよいと思います。 http://d.hatena.ne.jp/minekoa/20080803#c1217824520 よーし！ 箇条書きといわず、がんばっちゃうぞー。（と暴走する私。） ストラウストラップのOOP ストラウストラップの考える OOP 、本当は、What is.. 論文 に当たるのが正しい姿なのですが、今の私の脳内というと、実は申し訳ないことに「プログラミング言語 C+
今時のOOP - みねこあ
根拠レスですが、なんかこんな感じに落ち込んでいるイメージはあります。 * * * 始めにオブジェクトがあった。オブジェクトがなにで出来ているかとかはどうでもよろしい。 オブジェクトを基本構造単位としてプログラムを構造化する(分割する)。オブジェクト間には関連があって、継承という名の関連（継承という名は 歴史的経緯によるもので、名自体に意味はない）と、所有 という名の関連だ。まぁ、継承はなくても要は足せるが。 オブジェクトにシステムが持つ責務を分割し、責務をイメージさせる名前を付けよ。また上手くハマれば 静的型チェックが効率的に働くだろう。（ただし、完璧にはほど遠いので、自動テストの構築は必須だ） * * * このOOP の出自は、メッセージメタファ OOP の影響下で育てられた、というのが定説だが、抽象データ型の OOP の、何の目印もない荒野を、迷い無く渡り切った猛者がいたという説もある
オブジェクト指向でなぜ作るのか を買ってみました - みねこあ
オブジェクト指向をわかりたいなら今すぐ『オブジェクト指向でなぜつくるのか』を読め -思っているよりもずっとずっと人生は短い。 VS お勧め本？ - カレーなる辛口Javaな転職日記 について、http://www.kt.rim.or.jp/~kbk/zakkicho/08/zakkicho0807c.html#D20080728-4 さんよりお呼びが掛かりました。 普段、さんざ召還魔法を使いまくっている私としては、ここは恩返しのしどころです。けれど、敵はあまりに強大で...。 オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識― 作者: 平澤章出版社/メーカー: 日経BP社発売日: 2004/06/03メディア: 単行本購入: 34人 クリック: 448回この商品を含むブログ (198件) を見る 結論から先に言えば、OO の入門書としては、本書はダメで
ポリモーフィズムは継承の面白い副作用..なんかじゃない - みねこあ
なんか微妙な話の流れに。 3. 同時に考えなければならないことを減らせること （中略） オブジェクト指向プログラミングの学習にスコープを移せば、ポリモーフィズムと継承が絡まない動的言語を使って学んだ方が、格段に楽だと思います。ポリモーフィズムのことを考えるときはポリモーフィズムのことだけ、差分プログラミングのことを考えるときには差分プログラミングのことだけを考えていられます。 難しい言語 - みねこあ に、 ポリモフィズムと継承は表裏一体なので，片方だけを考えるのはむしろおかしい． 「難しい言語」の補足 - カレーなる辛口Javaな転職日記 ときて、同コメント欄で、 >ポリモフィズムと継承が表裏一体の概念 えーっと，「表裏一体の概念」とは書いていませんよね．「表裏一体で使用する」の方が適切かと．定義上は関係ない概念であったとしても，実際に使用する上で表裏一体で使用するので十分に柔軟で実用的
「呼出し元の共通化」という言い回し - みねこあ
突っ込みどころが違うってば - カレーなる辛口Javaな転職日記 より連想。 OOP にするとどんなメリットがあるかわからないという話について。 私は流しのプログラマなので、現場の「はじめてのOOP」にお付き合いすることが多いのですが、エライ人中心に「で、OOPにすると何が良くなるの？」と聞かれる機会は確かに多いです。そういうときに私は 「OOPL は呼出し元の共通化が出来るんです」と説明しています。 * * * 「サブルーチンがあれば呼出し先を共通化することができます。OOPLを使えば今度は呼出し元も共通化できちゃいます。」 この言い回しは プログラミングそのものに興味が無くなってしまったかつてのプログラマさんに有効だと思います。どんなに化石的な人たちだって、さすがにサブルーチンが無い言語で開発しろといわれたら嫌になっちゃう事くらいは納得していただける*1ので、開発にOOPLを使うか使わ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
