  |
はてなキーワード: コレクタとは
file = open('helloworld.py', 'r') line = file.readline() while line: print line line = file.readline()
https://github.com/kokorohamoe/OpenProfile/blob/simple/700_sample/python/helloworld.py
プログラミングという言葉がアフィブロガー御用達になって、SNSでプログラマーを名乗るのが憚られる感じの昨今。
プログラミングを勉強すればフリーランスで一生困らないみたいなこと書いてあるけど、そんな夢のスキルじゃないよ。
それなりにベテラン()を見てきたけど、結局はマネジメント層になれなければ会社にしがみつくことになる人が多い。
これはvueかReactか、javaかRubyかみたいな話じゃなくて、もう少し基本的な部分。
例えば大きいのはオブジェクト指向とクラス/インスタンスの概念。
他には、ガベージコレクタ、例外処理、マルチスレッド、デリゲートやラムダ式、非同期処理、バインディングとビューモデル、イテレータ、null安全。
今プログラミングを学んでる人には当たり前かもしれないけど、これらは十数年かけて徐々に当たり前になっていった。
ITバブルでブイブイ言わせていたけど、これらをうまく扱えないベテランは結構いる。
固定長メモリとポインタとmemsetで全てをまかなってきた層や、静的なモジュールで全部の画面を作ってたVB屋とか。
若いころは勉強すればいいと思うだろうが、理解はできてもそれを流暢に使いこなし適合するのは意外と難しい。
プログラムの中でその人の担当箇所だけいまいち読みにくくて、取り回しの悪いものになってしまう。いわゆるstaticおじさんというやつ。
これはベテランのイラストレータやシナリオライターが、デッサンや構成力はあっても、なんか古臭いものが出来上がってしまうのに似ている。
こうなると若いチームメイトや新しいプロジェクトからは敬遠される。
もちろん、COBOLの案件が未だにあるように、レガシー資産を利用した仕事で腕を振るえる場所は結構ある。
ただそういった環境は既存の人材・企業にがっちり掴まれてることが多く、後から見つけて入り込むのは簡単ではない。
真面目に考えると無論、
「コレクタブルカードでゲームをする(しかも同一カードを複数枚使ってもよい)」
が最大の発明なのは一切疑問の余地はないのだが、それはそれとして、元増田が挙げている物がどの程度「発明」だったかネチネチかつダラダラかつ主観的に検討してみる
無論、発明ではない。遅くとも、表記スペースが極めて限られているボードSLG時代には極めて標準的な考え方だった。
おそらく本当のイノベーションとは、
「イタリックで説明文を追加すれば無闇矢鱈に新しいキーワード能力を追加してもよい」
という決断が下された瞬間である((MAROがどっかで書いてた気がする))。
無論、発明ではない。ただし、
がデッキ構築という概念と密接に絡んだイノベーションな可能性は否定できぬ。
無論、発明ではない。カードゲーム（日本語で言うところのトランプ）を遊べば、そんな物が設定されている物はすぐに見つかるだろう。
ただし、(Raise Deadでなく)Animate Deadは明らかに異常な発想である。
無論、発明ではない。ユニットが青色だろうが灰色だろうが歩兵は3-3で戦車は5-5である(ダニガンは偉大だ)。
無論、発明ではない。ユニットが青色だろうが灰色だろうが歩兵は3-3で戦車は5-5である(ダニガンは偉大だ)。
それより『Bobby Lee』(所謂「積み木の南北戦争」。第一作は1972年出版の『Quebec 1759』)みたいなのをTom Dalgliesh(Colombia Games創業者)がどうやって思いついたのか知りたい。
あれって「アイデアというのは複数の問題をいっぺんに解決すること」そのもので、明らかに頭おかしい。
無論、発明ではない。ただし、山札から他のゾーンにカードを移動させる手段が多彩なので、発明に見える可能性は否定しない。
「勝利条件が設定されている」と「勝利条件を狙って行動できる」の間の断絶は本来は極めて大きい。
そういえば、バクスターか何かだと思うのだが、サイドボードがない時代の大会で、デッキ二つ用意して、対戦相手によって使い分ける話が載ってなかったっけ？
Duelistに1回載ってた謎のポイント制デッキのルール、サイドボード10枚毎にポイントが設定されてた(上限30枚)の、面白かったよね。
「コレクタブルカードでゲームをする(しかも同一カードを複数枚使ってもよい)」
普通のカードの代わりに平然と基本地形が混ざってるリバイスド以前のパックでドラフトしてた人達って頭湧いてたと思わない？
と書き換えると何か直接の先祖があった気がするが思い出せなくてモヤモヤするよね？
タイプ1とタイプ2を分離するのは確かに画期的だったが、本当の決断は
「Ice Ageを出すときにカード背面のデザインを変えなかった」
ことではないだろうか。
もともと、Ante関係のカードの存在故に、まともなトーナメントルールを作るならば「禁止カード」の設定が必然だった、という偶然から発生した話ではある。
それがなかった場合に「特定のカードはデッキに入れてよい枚数をコントロールする」という発想が出たかは謎ではある((いやそれなら最初に「同一カード4枚制限」を思いついたのが一番の発明だろう))。
はてなが戦火に覆われるようになったのは、不満がくすぶる第三次はてな大戦からの必然的な流れであり、開戦は避けられようがなかったということは誰しもが認める事実である。ただし、その引き金というのが男女の揉め事というのは娑婆世界的で品がないとも言えるが、概ねありきたりなことが発端となるものである。また誰も予想していなかったが、この戦いは思わぬ効果をはてな運営にもたらすこととなった。
開戦の火蓋となったのはある恋愛騒動であった。この騒動のどちらに立つのか、はてな民は真っ二つに別れた。まず、はてなアイドルが先頭に立ちメンヘライテンド（青）を結成。カリスマが立ち上がったことで、はてな女子の支持を一挙に集めた。
青い勢力結成に恐れをなしたモヒカン族はコレクタンス（緑）を立ち上げて対抗。正しさと秩序あるはてなをキャッチフレーズに、古参ユーザーや久谷女子などの面々が参加した。自分語りをするメンヘライテンドに対して、マズローの欲求5段階説を毎日のように啓蒙し、自分の心と対峙して調和する必要性を訴えた。
両者の戦いはB!クマガールズやはてサをも巻き込み、はてな史上最悪のバトルとなったが、これによってカラースターガチャがおもしろいように売れるようになった。争いが激化するにつれ青スターと緑スターだけではなくパープルスターまでもが大量投入され、誰もノーマルスターを使わなくなった。
いつしかはてなブックマークには、青いスターばかりが目立つ「コレクタンスの馬鹿ども」といったエントリーや、緑のスターで埋め尽くされた「病院送りにすべきメンヘライテンドのリスト」といった内輪向けのエントリーが並ぶようになり、かつてのように多様な空間ではなくなってしまった。大喜利で有名なブックマーカーのアイコンも所属する陣営に配慮して、綾波レイ、さやか、イカ娘など特定のキャラに偏ってしまうようになった。
一方、鳴かず飛ばずだったはてなは爆発的な利益を上げて最高益を達成。スマホ向けアプリ「はてな王国」は中高生にも大ヒットとなり、IT企業として大逆転を果たした。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
きちんとした言語やりたいならC++とかやった方がいいと思っちゃうけど、世間的には批判されるんだろうな…。
PythonとかRubyみたいないい加減(柔軟とも言う)な言語だと、プログラミングをあんまり深く理解できないまま終わる気がする。
C++は確かにワケ分かんないことも多いんだけど、型が厳密だから処理をきちんと意識することができるし、ガベージコレクタも無いから、
メモリをきちんと管理することの重要さもわかると思う。参照と実体の区別もきちんとつくようになるだろう。
一応プログラマ（というよりはソフトウェア開発者）として仕事してるんだけど、俺はギークにはなれないなとつくづく思う。
ぶっちゃけプログラミングとかコンピュータ・アーキテクチャ、ネットワークプロトコルみたいなものに興味が無いんだよね。
俺にとってプログラミングは、その背景にある数学的モデルをマテリアライズあるいはマネタイズするためのツールでしかない。
○○ハックとか、どの言語が有利だとか、凝ったコーディングテクニックだとかデータ構造の細かな工夫なんかには全然興味が無いんだ。
ぶっちゃけそこそこ習得能力はある方じゃないかと思う。コーディング始めてまだ1年経ってないけどオブジェクト指向(C++)でバリバリ書ける。
JavaやC#みたいにガベージコレクタがあって抽象度の高いオブジェクト指向言語なら(たぶん)少し慣れればかなり書けるだろう。
でも興味無いんだよね。だからコンピュータ大好き少年のようにどんどん新しいことを覚えて勝手にのめり込んでいくようなことができない。
勉強しなきゃなとは思うから本とか読むけど、あくまで義務感でやってるだけ。
プログラミングそのものには興味が無いから、作るシステムの目的がつまらなかったらやる気が無くなる。
それから、LINUXとかにも興味が無いので、なかなか使いこなせなくて困ることがある。
ギークにはなれない。どうやって生きていくのがいいかなあと思う。
