「ARG」を含む日記

■[経済メモ] 政策決定の数理

抽象的数理モデル化

1. モデルのセットアップ

(a) 消費者集合と効用関数

消費者集合：N = {1, 2, ..., n}

消費ベクトル：各消費者 i の消費ベクトルを X_i ∈ X_i ⊆ ℝ^(k_i) とする。

個人効用関数：U_i: X_i × G → ℝ

ここで、G は政府の提供する公共財の集合である。

個人効用は自分の消費 X_i と政府支出の使用用途 G に依存する。

(b) 政府の政策変数

税収：T ∈ ℝ_+

国債発行額：B ∈ ℝ_+

政府支出の配分：G = (G_1, G_2, ..., G_m) ∈ G ⊆ ℝ_+^m

G_j は公共財またはプロジェクト j への支出額である。

政策空間：P = { (T, B, G) ∈ ℝ_+ × ℝ_+ × G }

(c) 政府の予算制約

予算制約：

Σ_(j=1)^m G_j = T + B

政府の総支出は税収と国債発行額の合計に等しい。

(d) 消費者の予算制約

可処分所得：消費者 i の可処分所得 Y_i は、所得税 t_i によって決まる。

Y_i = Y_i^0 - t_i

Y_i^0 は消費者 i の総所得である。

税制の考慮：総税収 T は個々の所得税の合計である。

T = Σ_(i=1)^n t_i

消費者の予算制約：

p_i · X_i ≤ Y_i

p_i は消費財の価格ベクトルである。

2. 力学系の2つのステップ

(a) ステップ1：政府の決定

目的：政府は社会的厚生 W を最大化するために、以下の政策変数を決定する。

個人別の税負担 { t_i }

国債発行額 B

政府支出の配分 G = (G_1, G_2, ..., G_m)

制約：

政府の予算制約。

税制に関する法律や規制。

(b) ステップ2：消費者の消費行動

消費者の最適化：政府の政策 (t_i, G) を所与として、各消費者 i は効用を最大化する。

最大化 U_i(X_i, G)

X_i ∈ X_i

制約条件：p_i · X_i ≤ Y_i

結果：各消費者の最適な消費選択 X_i*(G) が決定される。

3. 社会的厚生関数

社会的厚生関数：W: ℝ^n → ℝ

W(U_1, U_2, ..., U_n) は個々の効用を社会的厚生に集約する。

合成関数：

W(U_1(X_1*(G)), ..., U_n(X_n*(G)))

これは政府の政策 G と { t_i } の関数となる。

4. 政府の最適化問題の定式化

政府は以下の最適化問題を解く。

最大化 W(U_1(X_1*(G)), ..., U_n(X_n*(G)))

{ t_i }, B, G

制約条件：

Σ_(j=1)^m G_j = Σ_(i=1)^n t_i + B

t_i ≥ 0 ∀i, B ≥ 0, G_j ≥ 0 ∀j

X_i*(G) = arg max { U_i(X_i, G) | p_i · X_i ≤ Y_i } ∀i

X_i ∈ X_i

5. 数学的解析

(a) 政府と消費者の相互作用

政府の役割：公共財の配分 G と税制 { t_i } を決定する。

消費者の反応：消費者は政府の決定を受けて、最適な消費 X_i*(G) を選択する。

(b) 力学系の特徴

スタックルベルクゲーム：政府（リーダー）と消費者（フォロワー）の間の戦略的相互作用。

最適反応関数：消費者の最適な消費行動は政府の政策に依存する。

(c) 一階条件の導出

ラグランジュ関数：

L = W(U_1(X_1*), ..., U_n(X_n*)) - λ ( Σ_(j=1)^m G_j - Σ_(i=1)^n t_i - B ) - Σ_(i=1)^n μ_i (p_i · X_i* - Y_i)

微分：政策変数 t_i, B, G_j に関する一階条件を計算する。

チェーンルール：消費者の最適反応 X_i* が G に依存するため、微分時に考慮する。

6. 公共財の使用用途のモデル化

(a) 公共財の種類

公共財ベクトル：G = (G_1, G_2, ..., G_m)

例えば、教育 G_edu、医療 G_health、インフラ G_infra など。

(b) 消費者効用への影響

効用関数への組み込み：

U_i(X_i, G) = U_i(X_i, G_1, G_2, ..., G_m)

各公共財 G_j が個人効用にどのように影響するかをモデル化。

(c) 政府支出の配分の最適化

目的：公共財の配分 G を最適化し、社会的厚生を最大化。

制約：政府の予算制約内で配分を決定。

7. 政府の政策選択の解釈

(a) 税制の設計

所得税の設定：各消費者の所得税 t_i を調整。

再分配政策：所得格差を是正するための税制設計。

(b) 国債発行の役割

将来への影響：国債発行は将来の税負担に影響するため、長期的な視点が必要。

制約：債務の持続可能性に関する制約をモデルに組み込むことも可能。

(c) 公共財の最適配分

効率性と公平性：公共財の配分が効用に与える影響を考慮。

優先順位の決定：社会的厚生を最大化するための公共財への投資配分。

8. 力学系としてのモデル

(a) ステップ1：政府の最適化

政府の決定問題：消費者の反応を予測しつつ、最適な { t_i }, B, G を決定。

情報の非対称性：消費者の選好や行動に関する情報を完全に知っていると仮定。

(b) ステップ2：消費者の最適化

消費者の行動：政府の政策を所与として、効用最大化問題を解く。

結果のフィードバック：消費者の選択が社会的厚生に影響し、それが政府の次の政策決定に反映される可能性。

9. 結論

(a) モデルの意義

包括的な政策分析：政府の税制、国債発行、公共財の使用用途を統合的にモデル化。

力学系アプローチ：政府と消費者の相互作用を動的に考察。

(b) 政策提言への応用

最適な税制と支出配分：社会的厚生を最大化するための政策設計の指針。

財政の持続可能性：国債発行と将来の税負担のバランスを考慮。

(c) 抽象化のメリット

一般性の確保：特定の経済状況やパラメータに依存しないモデル。

理論的洞察：政府の役割と政策効果に関する深い理解を促進。

政府は、税制 { t_i }、国債発行額 B、そして公共財の配分 G を戦略的に決定することで、消費者の効用 U_i を最大化し、社会的厚生 W を高めることができる。

このモデルでは、政府の政策決定と消費者の消費行動という2つのステップの力学系を考慮し、公共財の使用用途も組み込んでいる。

Permalink | 記事への反応(0) | 08:09

ツイートシェア

■[経済メモ] 補償原理の導出

定義と仮定:

経済主体の集合 I と財の集合 L を考える。各主体 i ∈ I は以下を持つ:

• 消費集合 Xᵢ ⊆ ℝ₊ᴸ
• 完備的、推移的、連続的、凸的、局所的非飽和性を満たす選好関係 ≽ᵢ
• 初期保有 ωᵢ ∈ Xᵢ

市場価格ベクトル p ∈ ℝ₊ᴸ が与えられると、各主体は以下の予算集合を持つ:

Bᵢ(p) = { x ∈ Xᵢ | p · x ≤ p · ωᵢ }

第1基本定理(厚生経済学の第1基本定理):

仮定の下で、競争均衡はパレート効率的である。

証明:

競争均衡 (p*, x*) を考える。ここで、x* = (xᵢ*)ᵢ∈I は各主体の最適選択であり、市場均衡条件を満たす:

1. 最適性条件:

xᵢ* ∈ arg max{x∈Bᵢ(p*)} { x | x ≽ᵢ xᵢ }

2. 市場均衡条件:

Σᵢ∈I xᵢ* = Σᵢ∈I ωᵢ

仮に x* がパレート効率的でないとすると、ある実現可能な配分 y = (yᵢ)ᵢ∈I が存在して:

• yᵢ ≽ᵢ xᵢ* (全員が現状以上)
• 少なくとも一人について yᵢ ≻ᵢ xᵢ*
• Σᵢ∈I yᵢ ≤ Σᵢ∈I ωᵢ

zᵢ = yᵢ - xᵢ* と定義すると:

Σᵢ∈I zᵢ ≤ 0

各主体の最適性より:

p* · yᵢ ≥ p* · xᵢ*

従って:

p* · zᵢ ≥ 0

しかし、少なくとも一人について p* · zᵢ > 0。すると:

Σᵢ∈I p* · zᵢ > 0

しかし:

Σᵢ∈I p* · zᵢ = p* · Σᵢ∈I zᵢ ≤ 0

これは矛盾である。従って、x* はパレート効率的である。

第2基本定理(厚生経済学の第2基本定理):

仮定の下で、任意のパレート効率的配分は、適切な初期保有の再分配後、競争均衡として実現可能である。

証明:

任意のパレート効率的配分 x* = (xᵢ*)ᵢ∈I を考える。社会的に望ましい配分として、適切な価格ベクトル p* ∈ ℝ₊ᴸ を構築する。

1. ハイパープレーンの分離定理の適用:

パレート効率性より、以下の集合は交わらない:

• 消費可能集合: X = Πᵢ∈I Xᵢ
• 改善可能な配分の集合

これらの凸集合を分離するハイパープレーンが存在し、その法線ベクトルとして価格 p* を得る。

2. 各主体の最適化問題:

再分配された初期保有 ω̃ᵢ を考える(Σᵢ∈I ω̃ᵢ = Σᵢ∈I ωᵢ)。各主体は以下を最大化する:

max{x∈Xᵢ} { x | x ≽ᵢ xᵢ, p* · x ≤ p* · ω̃ᵢ }

適切な ω̃ᵢ を選ぶことで、xᵢ* が各主体の最適解となる。

補償原理:

ある政策変更により得られる利得者の利得が、損失者の損失を完全に補償できる場合、その政策は潜在的なパレート改善である。

証明:

経済内の二つの状態 A と B を考える。状態 B への移行で利得者と損失者が存在する。

1. カルドア基準:

利得者の余剰 G と損失者の損失 L を計測し、G > L であれば、利得者から損失者への補償が可能である。

2. ヒックス基準:

損失者が利得者に支払ってでも状態 A を維持したい額を W とすると、G > W であれば、状態 B への移行が望ましい。

3. 潜在的パレート改善:

補償が実際に行われなくとも、理論上可能であれば、社会的に望ましいと判断される。

Permalink | 記事への反応(0) | 07:57

ツイートシェア

■[経済メモ] ミクロ経済学の抽象化

1. 圏論的アプローチによる消費者理論

1.1 基本設定

• 財空間: 完備局所凸位相的ベクトル空間の圏 𝒞
• 対象: (X, τ) ∈ Ob(𝒞)
• 射: f: (X, τ_X) → (Y, τ_Y) は連続線形写像

1.2 選好の表現

• 選好関係: ≿ を (X, τ) 上の二項関係とする
• 効用関子: U: 𝒞 → 𝒮𝒆𝓉（上半連続性と準凹性を保存する）

1.3 一般化された効用最大化問題

sup_{x ∈ U(X)} x subject to φ(x) ≤ w

ここで、φ: U(X) → ℝ は連続線形汎関数、w ∈ ℝ は初期富である。

2. 微分位相幾何学的アプローチによる生産理論

2.1 基本設定

• 生産可能多様体: 𝓜（無限次元リーマン多様体）
• 接束: T𝓜
• 生産ベクトル: y ∈ T_p𝓜（p ∈ 𝓜 における接ベクトル）
• 価格形式: ω ∈ T*𝓜（余接束上の1-形式）

2.2 一般化された利潤最大化問題

sup_{y ∈ T_p𝓜} ω(y)

2.3 生産対応の特性化

生産対応を η: T*𝓜 → 2^{T𝓜} とし、以下の条件を満たす：

∀ω ∈ T*𝓜, η(ω) = {y ∈ T_p𝓜 : dω(y) = 0}

ここで、dω は ω の外微分である。

3. 作用素代数的アプローチによる一般均衡理論

3.1 経済の定義

経済 ℰ をC*-代数 𝒜 上の作用素の組として定義：

ℰ = ((ℋ_i, π_i, Ω_i)_{i ∈ I}, (T_j)_{j ∈ J})

ここで、

• I は消費者の集合、J は生産者の集合
• ℋ_i は消費者 i のヒルベルト空間
• π_i: 𝒜 → B(ℋ_i) は 𝒜 の ℋ_i 上の表現
• Ω_i ∈ ℋ_i は消費者 i の初期状態ベクトル
• T_j ∈ 𝒜 は生産者 j の生産作用素

3.2 均衡の定義

状態 (ψ_i*)_{i ∈ I} と価格作用素 P ∈ 𝒜 が均衡であるとは、以下を満たすことを言う：

1. ∀i ∈ I, ψ_i* = arg max_{ψ ∈ ℋ_i} ⟨ψ, π_i(P)ψ⟩ subject to ⟨ψ, π_i(P)ψ⟩ ≤ ⟨Ω_i, π_i(P)Ω_i⟩ + ∑_{j ∈ J} θ_{ij} τ(PT_j)

2. ∀j ∈ J, T_j = arg max_{T ∈ 𝒜} τ(PT)

3. ∑_{i ∈ I} (ψ_i* - Ω_i) = ∑_{j ∈ J} T_j

ここで、τ は 𝒜 上のトレース、θ_{ij} は消費者 i の生産者 j に対する利潤シェアである。

4. 非可換幾何学的アプローチによる市場構造

4.1 スペクトル三つ組

市場構造を非可換幾何学の枠組みでモデル化：

(𝒜, ℋ, D)

ここで、

• 𝒜 は経済主体の行動を表すC*-代数
• ℋ は経済状態を表すヒルベルト空間
• D はディラック作用素（市場の相互作用を表す）

4.2 市場均衡の特性化

市場均衡を以下の作用素方程式で特性化：

[D, π(a)] = 0, ∀a ∈ 𝒜_{eq}

ここで、𝒜_{eq} ⊂ 𝒜 は均衡状態を表す部分代数、π は 𝒜 の ℋ 上の表現である。

5. ホモトピー理論と均衡動学

均衡への収束過程をホモトピー理論を用いて分析：

H: [0,1] × X → X

ここで、X は経済状態空間、H(0,x) = x_0（初期状態）、H(1,x) = x*（均衡状態）である。

均衡の安定性は、ホモトピー H の特異点の構造と関連付けられる。

Permalink | 記事への反応(0) | 12:03

ツイートシェア

■[経済メモ] 社会厚生の公理的定式化

基本設定

1. 経済主体の集合は E = {1, 2, ..., n} である。

2. 財の集合は G = {1, 2, ..., m} である。

3. 消費集合は Xᵢ ⊆ ℝᵐ₊ for i ∈ E である。

4. 選好関係は ≽ᵢ on Xᵢ for i ∈ E である。

5. 生産可能性集合は Y ⊆ ℝᵐ である。

効用最大化問題

消費者 i の効用最大化問題は以下のようになる。

max{xᵢ∈Xᵢ} uᵢ(xᵢ) subject to p · xᵢ ≤ wᵢ

ここで、uᵢ: Xᵢ → ℝ は効用関数、p ∈ ℝᵐ₊ は価格ベクトル、wᵢ は初期賦存量である。

利潤最大化問題

企業の利潤最大化問題は以下のようになる。

max{y∈Y} p · y

一般均衡

一般均衡は以下の条件を満たす配分 (x*, y*) と価格ベクトル p* の組である。

1. xᵢ* ∈ arg max{xᵢ∈Xᵢ} {uᵢ(xᵢ) : p* · xᵢ ≤ wᵢ} for all i ∈ E

2. y* ∈ arg max{y∈Y} p* · y

3. Σ{i∈E} xᵢ* = Σ{i∈E} wᵢ + y*

厚生経済学の基本定理

• 第一基本定理: 完全競争均衡配分はパレート効率的である。形式的には、(x*, y*, p*) が競争均衡であれば、(x*, y*) はパレート効率的である。
• 第二基本定理: 任意のパレート効率的配分は、適切な初期賦存量の再分配の下で競争均衡として実現可能である。

ホテリングの補題

利潤関数を π(p, w) とすると、

∂π(p, w)/∂pⱼ = yⱼ(p, w)

ここで、yⱼ は財 j の供給関数である。

生産者余剰の変化

価格変化による生産者余剰の変化は以下のようになる。

ΔPS = ∫{p₀}^{p₁} y(p, w) dp

公共経済学の定式化

社会厚生関数は W: ℝⁿ → ℝ である。

政府の問題は以下のようになる。

max{x,y,t} W(u₁(x₁), ..., uₙ(xₙ))

subject to:

1. Σ{i∈E} xᵢ = Σ{i∈E} wᵢ + y

2. y ∈ Y

3. xᵢ ∈ arg max{xᵢ∈Xᵢ} {uᵢ(xᵢ) : p · xᵢ ≤ wᵢ + tᵢ} for all i ∈ E

4. Σ{i∈E} tᵢ = 0 (予算均衡条件)

ここで、tᵢ は個人 i への移転支払いを表す。

Permalink | 記事への反応(0) | 07:35

ツイートシェア

■[経済メモ] 公理主義的ゲーム理論モデル

ゲーム構造

1. プレイヤー集合: N = {P₁, P₂, ..., Pₙ}

2. 行動集合: 各プレイヤー Pᵢ の行動の集合を Aᵢ とする

3. 情報集合: 各プレイヤー Pᵢ の情報集合を Hᵢ とする

4. 選好関係: 各プレイヤー Pᵢ の選好関係を ≽ᵢ とする

履歴と戦略

1. 履歴: H = ∪ Hᵢ

2. 終端履歴: Z をゲームの終端履歴の集合とする

3. 純粋戦略: Sᵢ = ∏ Aᵢ(h)

4. 戦略プロファイル: S = ∏ Sᵢ

効用関数

各プレイヤー Pᵢ に対して、効用関数 uᵢ: Z → ℝ を定義する

公理

1. 完備性と推移性:

• 完備性: ∀z, z' ∈ Z, z ≽ᵢ z' ∨ z' ≽ᵢ z
• 推移性: ∀z, z', z'' ∈ Z, (z ≽ᵢ z' ∧ z' ≽ᵢ z'') → z ≽ᵢ z''

2. 期待効用仮説:

p ≽ᵢ q ⇔ 𝔼ₚ[uᵢ] ≥ 𝔼ᵩ[uᵢ]

行動戦略

σᵢ: Hᵢ → Δ(Aᵢ), ここで Δ(Aᵢ) は Aᵢ 上の確率分布の集合

信念システム

μ を各情報集合 h ∈ H に対する確率測度 μₕ ∈ Δ(h) の集合と定義

完全ベイズ均衡 (PBE)

(σ*, μ*) が完全ベイズ均衡であるとは、以下を満たすとき:

1. 逐次合理性: ∀i ∈ N, ∀h ∈ Hᵢ,

σᵢ*(h) ∈ arg max σᵢ(h) 𝔼σ₋ᵢ*,μₕ*[uᵢ | h, σᵢ(h)]

2. ベイズ一貫性: 信念は可能な限り戦略から Bayes 則で導出

Permalink | 記事への反応(0) | 06:08

ツイートシェア

■考察：絵の付加価値、または今のツイッターランドの惨状について

前提：この日記は一個人の考察である。この日記で言及する人が全員そうという訳ではないことも十分承知している。その上でこれを読んでほしい（そうでもしないと「自分はそうではない！」というコメントで溢れかえるだろうから）

絵を見る人々の中で価値観に差が生まれてるような気がする。

「絵の作者に価値を見出すか否か」でかなり分断が生まれていると考察している。

自分の価値観が他人にはないということはよくあることだ。（「え、街中で綺麗な文字見かけた時にどのフォントが気になりませんか！？」「え、便利なサービス見かけた時にバックエンドのフレームワーク何使ってるかとか気になりませんか！？」と書けばわかりやすいだろうか？）

おそらく、見出さない人はイラストがAIイラストでも気にしていない。「別にかわいい/萌えるからいいじゃん」と言った感じ。

もしかしたらマイナーなジャンル/CP/性癖なら「供給が増えた！！」となっている可能性もある。

一方、見出す人はAIイラストだとわかると複雑な気分になる。

その絵を描いたもの=AIイラストのモデルに対してマイナスの付加価値が設定されており、さらにはそのユーザー=AI術師に対してマイナスの付加価値を設定する。「こいつAI使ってたからこの人の絵嫌い」と言った感じだ。

もしモナリザを描いた人が完全に無名なひよっこだった場合、今ほどの価値は生まれていたのだろうか？もし大罪人だったら？自分はそうはならないと思っている。ダヴィンチが描いているからあそこまでの価値が一般に広まっていると思っている。（正直、自分はあの絵のARG要素くらいしか魅力を感じない）

今のツイッターランドで起こっているであろうことの一つに、フィルターバブルやエコーチェンバーによって「全ての人は絵師を気にしている！」（またはその逆）という幻想が生まれていることがある。絵師界隈、さらにその中の反AI村という村社会の中で情報が更新されていないように見える（一部の過激派のせいで対立が激化している原因の一つにも思われる、こっちはノイジーマイノリティとかの効果もあるが）

もちろんこれは反々AIに対しても言えるが。

少しは村の外に目を向けて得られる視点や考察もあるのではないだろうか。

Permalink | 記事への反応(0) | 07:47

ツイートシェア

■かがみの特殊少年更生施設攻略終わったー

謎解き難しかったけどおもろかった

やっぱThe White DoorもそうだけどARGはええね

Permalink | 記事への反応(0) | 10:05

ツイートシェア

■日本の新型コロナワクチン接種回数は正しいの？

日本の新型コロナワクチン接種回数は6月中旬以降、ほぼ線形に伸びてきている。

https://ourworldindata.org/explorers/coronavirus-data-explorer?zoomToSelection=true&time=2020-03-01..latest&facet=none&pickerSort=asc&pickerMetric=location&Metric=People+fully+vaccinated&Interval=7-day+rolling+average&Relative+to+Population=true&Align+outbreaks=false&country=AUS~CAN~SAU~USA~IND~RUS~ZAF~TUR~ARG~BRA~MEX~FRA~DEU~ITA~GBR~IDN~JPN~KOR~NZL~TWN~PRT~ESP

ツイッターを観測しているとワクチンを予約できないという声はここ数週間目立って減ってきていて

接種を希望する人にはかなり行きわたっているように見えるけど

上のグラフを見ると増加が緩やかになる状況にはなっていない。

公式のワクチン接種回数は現状を正しく反映しているのかな？どうなんだろ

Permalink | 記事への反応(3) | 19:35

ツイートシェア

■五輪開会式の入場行進を「いろは順」にしたら

• 上記配列は日本開催の時にしたが、順位はそのまま。
• 国・地域名の表記は https://www.joc.or.jp/games/olympic/code/ に拠ったが、右記は変更した:「西サモア→サモア」「英領→イギリス領」「米領→アメリカ領」
• 日本語文字列照合順番になってたらいいなあ。

Permalink | 記事への反応(0) | 23:03

ツイートシェア

■テスト

int hoge(int arg) {
  // 


  

Permalink | 記事への反応(2) | 19:59

ツイートシェア

■シンゴジラとARGを全力で潰す

まずはTwitterで片っ端から副垢使って通報しまくるところから始めよう。

Permalink | 記事への反応(0) | 00:30

ツイートシェア

■ARGは「人を不快にさせるコンテンツ」であると知った。

よってARGは俺の敵。

全力で潰す。

Permalink | 記事への反応(0) | 23:22

ツイートシェア

■Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1

42 : デフォルトの名無しさん : 2011/11/12(土) 23:53:51.20

Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ

端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに

PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？

けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか

45 : デフォルトの名無しさん : 2011/11/13(日) 01:41:24.25

数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…

43 : デフォルトの名無しさん : 2011/11/13(日) 00:04:23.30

PHPが未だに現役なのは、単に歴史的な経緯でしかないだろ

Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、

Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....

44 : デフォルトの名無しさん : 2011/11/13(日) 00:49:55.28

zopeってコケてたんだ

ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね

djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、

pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど

本家のrailsって、他を遥かに越えるほど良いものなんだっけ？

48 : デフォルトの名無しさん : 2011/11/13(日) 08:30:25.68

44

Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と

さかんに宣伝され、雑誌でもZope特集が組まれていた

少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった

そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう

今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい

djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう

しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い

Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから

何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理

Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）

だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている

51 : デフォルトの名無しさん : 2011/11/13(日) 12:55:40.83

　C　a　k　e　P　H　P　は　う　ん　こ　 　

遅い、設計が古い、動作がおかしいの３重苦

日本では流行ってないけど海外だとYiiが流行ってきてる

55 : デフォルトの名無しさん : 2011/11/13(日) 17:31:12.14

CakePHP使ってんの？

可哀そうにw

53 : デフォルトの名無しさん : 2011/11/13(日) 14:44:48.55

求人がPHPばかりだから、PHPやるしかないだろ。

57 : デフォルトの名無しさん : 2011/11/13(日) 19:34:04.95

でもやっぱりいつもの使い慣れたLL(Python/Ruby)で

Webサービスを書きたいってのがある

73 : デフォルトの名無しさん : 2011/11/15(火) 17:32:46.07

アメリカの言語ユーザー数は

Python＞＞＞＞＞＞＞＞Ruby

求人数は

Ruby on Rails＞＞＞＞＞＞＞＞Django

http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=

どういうことなの？

74 : デフォルトの名無しさん : 2011/11/15(火) 17:48:15.59

RubyはRails以外に使い道がないから

75 : デフォルトの名無しさん : 2011/11/15(火) 17:54:35.50

海外ではRubyは昨今のRailsバブルのお陰で

もはやWeb系スタートアップの共通語になってるらしいからね

求人数が多いのはそのためだと思うよ

76 : デフォルトの名無しさん : 2011/11/15(火) 18:03:23.05

なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・

Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか

77 : デフォルトの名無しさん : 2011/11/15(火) 18:23:14.33

Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。

でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。

ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。

78 : デフォルトの名無しさん : 2011/11/15(火) 18:38:46.28

同感だ

同じように思っている人が他にもいて安心した

79 : デフォルトの名無しさん : 2011/11/15(火) 18:54:37.13

PHPやJava、Scalaには

Railsみたいなフレームワークあるのに

Pythonにはいいのないんだよな

80 : デフォルトの名無しさん : 2011/11/15(火) 21:19:09.89

PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。

Scalaも注目されだしたのはつい最近のことだしな。

それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、

いつの間にかフェードアウト。

ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。

83 : デフォルトの名無しさん : 2011/11/15(火) 21:25:38.55

パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、

これってｷﾘｯって言いたいだけだと思う。

後発品が先に出たものを超えたものなんていくらでもあるから。

84 : デフォルトの名無しさん : 2011/11/15(火) 21:30:04.39

D言語って超えたって？

85 : デフォルトの名無しさん : 2011/11/15(火) 21:31:12.00

B言語って超えたって？

86 : デフォルトの名無しさん : 2011/11/15(火) 21:53:33.76

でもRailsはRubyの黒魔術を使いまくりだからな

PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない

90 : デフォルトの名無しさん : 2011/11/15(火) 22:50:07.81

スタートアップなんて根無し草の集まりにとって、

googleが囲った言語にcoolさを見出せないんだろ

123 : デフォルトの名無しさん : 2011/11/20(日) 11:32:16.79

まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ

91 : デフォルトの名無しさん : 2011/11/15(火) 22:52:42.98

そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ

3 : デフォルトの名無しさん : 2011/11/15(火) 23:07:07.67

linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん

わざわざ不合理で不完全な言語を使うなんて

社会からハミ出た奴らの精神的な作用によるものじゃないの？

95 : デフォルトの名無しさん : 2011/11/15(火) 23:20:20.21

djangoの情報とプラグインが増えないという、

現実に対する鬱憤を吐いてるようにしか聞こえないな

もしも

＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん

真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず

104 : デフォルトの名無しさん : 2011/11/16(水) 01:20:49.05

Python信者乙。

yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。

ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。

94 : デフォルトの名無しさん : 2011/11/15(火) 23:15:11.93

というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に

打倒RailsたるWebフレームワークを開発しているはずだけど、

いまだにRailsを超えるプロダクトが登場しないのはナゼ？

Railsも登場してから、かなりの年月が経過しているんだけどなぁ....

その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ

347 : デフォルトの名無しさん : 2011/12/09(金) 10:16:35.22

Ruby では

ary.map {|x| x**2}

となるものが、Python では

map(lambda x: x**2, ary)

となり、lambda の本体が1つの式では表現しきれなくなると

def mapper(x):

.....

map(mapper, ary)

と書き換える必要があります。

348 : デフォルトの名無しさん : 2011/12/09(金) 10:24:20.94

Pythonのlambdaを用いた階乗計算

f = lambda x:(x and f(x-1)*x)or 1

RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、

andやorを使った不自然な記述をしなくても

f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}

または

f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}

と書けます。lambda内でreturnが使えますから、書きたければ

f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}

でもOKです。

390 : デフォルトの名無しさん : 2011/12/10(土) 15:35:41.62

348

これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ

だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…

そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と

350 : デフォルトの名無しさん : 2011/12/09(金) 11:12:13.28

要素に対する関数の適用と、抽出を組み合わせる場合

Python

print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]

暗号のように見える。

Ruby

puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}

思考の流れと、コードの流れが一致しているので書きやすい。

351 : デフォルトの名無しさん : 2011/12/09(金) 11:22:55.04

だれだPythonなら書き方はひとつとか言ってるのは

map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))

354 : デフォルトの名無しさん : 2011/12/09(金) 12:22:07.37

pythonて可読性が高いのをうたってる割にはそこいまいちだよね

353 : デフォルトの名無しさん : 2011/12/09(金) 12:10:08.46

Rubyの場合には、左から右へと無名関数がデータフローあるいは

パイプラインのように並ぶから、コードが読みやすい

関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける

プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby

それと比較すると、Pythonのコードは、関数型プログラミングというものが

いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける

もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう

356 : デフォルトの名無しさん : 2011/12/09(金) 12:53:45.66

階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す

result_list = source_list.map { |elem|

　　x = foo(elem.x)　　# ここが局所宣言を書く部分

　　y = bar(elem.y)　　# ここも局所宣言の続き

　　x + y　　　　　　　# 最後に評価された式の値が、無名関数のリターン値になる

}

Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、

x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける

このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する

357 : デフォルトの名無しさん : 2011/12/09(金) 12:59:21.07

余計分かりづらくなった

358 : デフォルトの名無しさん : 2011/12/09(金) 13:17:26.54

リスト内包表記が暗号みたいと言ってる奴は

高卒ドカタなんだろうなぁと可哀想になる

大学で数学に触れる機会があれば

集合の表記に似せてることが分かるから

386 : デフォルトの名無しさん : 2011/12/10(土) 01:41:34.46

数学とかで慣れてるし区切りが関数のがわかりやすい

359 : デフォルトの名無しさん : 2011/12/09(金) 13:46:31.97

355

＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。

関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね

Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ

360 : デフォルトの名無しさん : 2011/12/09(金) 13:53:28.85

Rubyだと直感的に書けるコードも

[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')

Pythonだと読みにくい。

'-'.join(map(str, reversed(sorted([1,4,3,2]))))

361 : デフォルトの名無しさん : 2011/12/09(金) 14:07:17.88

360

Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....

364 : デフォルトの名無しさん : 2011/12/09(金) 14:28:55.99

カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか

Rubyのやり方は基本ではなく玄人のやり方だろ

372 : 369 : 2011/12/09(金) 16:21:03.82

Pythonでは組み込みの型でメソッドチェインはやって欲しくないな

listにmap,filterメソッドができたとしても、

似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。

シーケンスプロトコルの利点が活かせない。

383 : デフォルトの名無しさん : 2011/12/10(土) 01:17:28.39

372

外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね

Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします

377 : デフォルトの名無しさん : 2011/12/09(金) 18:41:51.79

Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる

得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない

Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い

379 : デフォルトの名無しさん : 2011/12/09(金) 18:48:52.27

Pythonのユーザー調教っぷりは異常

「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く

387 : デフォルトの名無しさん : 2011/12/10(土) 13:40:40.74

リストの内包表記はシンプルに書けるときは使うけど

基本その場でdefするのがPython風なんだと思う。

389 : デフォルトの名無しさん : 2011/12/10(土) 14:40:31.04

無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。

384 : デフォルトの名無しさん : 2011/12/10(土) 01:23:49.48

outer(center(inter( arg )))

これを読みづらいと感じるのは、左から右に流れる

日本語文に慣れているからだと思うが、

もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？

385 : デフォルトの名無しさん : 2011/12/10(土) 01:34:57.89

なるほど、ということは右から左、左から右どっちでも行ける言語が最高ですね

F#のパイプライン演算子最高ということで

Permalink | 記事への反応(1) | 22:01

ツイートシェア

■ARGへの参加障壁？について

ARGについて昨夜ひともりあがりあったので書いとこう。

(問題≠謎として見てください)

SCRAPのリアル脱出ゲームをはじめ、短期のイベントとして成立しているものについては

・「スタート」がはっきりしている

・何をすべきかが結構提示されている（解答用紙が渡されたり、ここの部屋の中でヒントをさがしてくださいといわれたり）

のほかに、

・スタート時がみんな一斉に横並び

だということ。

つまり、みんなが最初にとりかかるものが「全体に対しての第一問」なわけで。

勿論、解明すべき順番が決まっていないものもありますが、

みんなそのイベントに限っては「イベント内での知識」が同じ状態からはじめられる。

そして、導入部分の解決すべき問題というのは、得てして難易度が低かったりするもので。

ちょっとずつその世界に入っていけるんですよね。

だけれど、長期のARGにおいては、時間の進行が不可逆である限り、

全員が開始時からとりかかることができるとは限らない。

そのため、途中から入ったユーザが最初に直面する問題が、とても難解な

しかもこれまでの情報から推測したりすることが必要なものとなる可能性は結構高い。

（詰まる箇所って「○○で集まれ」など物理的にすぐには動きづらいもの以外では、非常に難易度高い問題の場合が多数だと思うので）

そこで初めて訪れたユーザは「意味がわからない」「入りづらい」という印象を持ち易くなる。

となると、コアユーザがFAQやまとめ、途中参入のユーザからの質問に逐一答えるべきか？

逐一となると対応者が疲弊してしまう。

コアユーザがオープンな空気にしていくことを心がけるのとともに、新しく入るユーザも

教えてもらったらお礼を言う、過去の質問内容を読む。など、基本的なことは行わないといけないと思う。

とはいえ、そもそもARGとはなんぞ？という層に対して、「そんな基本的なことから質問するな」というような投げかけをしても

「基本的なところからわからない」のだから、仕方がない。

ROMってろ。というのは、確かに読んでいると参考になることもあるんだが排他的にも感じ、

ARG自体にそこまで魅力を感じていない層の人は確実に「ARGに関わる人＝怖い、内輪で固まってキモい」という

印象を持つだろう。

まずは経験だよ経験。といわれても、「常連さんの邪魔になる」「自分みたいな初心者が・・・」等

発言もしづらいだろう。

的外れな発言したら「それ、もう終わったから」「関係ないよそれ」とか立て板に水的な感じでパシーンと文字で言われちゃうんだよ。

初めての人からしたら怖いっしょ。

「ARGって何なの？」「何をすればいいの？」「結局何からとりかかればいいかわからないんだけど？」という部分を噛み砕いた

わかりやすい導入ガイドみたいなものがあればいいのかな。と思ったりしています。

Permalink | 記事への反応(0) | 09:22

ツイートシェア