Pythonの立ち位置はなんとも中途半端
ScalaやLuaを知って以来Pythonの立ち位置はなんとも中途半端になってしまったなあ、という感じがします。思ってることを色々まとめてみました。
Pythonの利点？
Pythonがもともと謳っていた「Cの20倍の生産性」という言葉はもう意味の無い語でしょう。JavaでもC++でもCよりは圧倒的に生産性は高くなるはずです。よって、昔はBetter JavaとしてPythonが流行るのかなあと考えていましたがそれも見込み薄な感があります。理由は以下のとおり。
- ScalaのようなJVMで動作するJavaよりも高級な言語ができてしまった。それらの言語はBetter Javaとして十二分な性能がある。
- そもそもPythonがJavaより高級かどうかが微妙。Pythonの開発環境がEclipse+Javaの開発環境に比べて言語の差を埋めるほど優秀とはおそらく言えない。
- 動的型付けと静的型付けではパラダイムが違いすぎる
等々他にも理由は挙げられますがこの辺で。Python開発者の方々がJavaの代替を目指しているのかは分からないため、殆ど言いがかりみたいなこと言ってるなあとは思います。しかし、Javaを使う身としては、JavaからPythonに移るメリット無いなあと思うわけです。
Cの補完としてのPython?
コア部分をCで書き、modに当たる部分をPythonで書く、ということができるというものPythonを使う理由の一つだと思います。しかし、Pythonは致命的に遅いという欠陥があります。軽快で高速なLuaという組み込み言語ができてしまった以上、この方面で戦うのはかなり厳しいと思われます。
竹中平蔵氏のコメントを見て
池田信夫氏のブログを見てると竹中平蔵氏を思い出し，ブログをやっていないかと
調べてみたら，あるテレビ番組に出演した竹中氏の発言をメモしたブログを
見つけた．
http://nikonikositaine.blog49.fc2.com/blog-entry-197.html
ブログ主に感謝しつつ，発言を読み解いてみた．
番組内での反論
萩原博子氏がこれに対し，色々と反論を述べていました．萩原博子氏のことは私は全く知らないのですが，
コメント内容を見る限り，00年代の自民党政治の経済政策を批判するときのお題目をずらずら並べて
いるようです．
反論の要点は，「なんで私たちがこんな苦しい思いをしなければならないんだ」という言葉で集約できると
思います．要するに，絶対的力を持つ政府がなんで私たちを救えないのかと．発言自体は元ブログの方で
確認していただきたいのですが，かなり議論が稚拙です．しかし，「政府が悪い，企業が悪い」という
いつもの題目は，やはり多くの共感を得ていたのだなあ，ということを思い出させてくれる発言の
オンパレードです．私も昔はこういう発言に共感していたのかと思うとぞっとします．
なぜこんなにも食い違うのか
なぜ，竹中氏といわゆる「コメンテーター」の発言はこんなに食い違うのか．それは
「政府」をどういう存在として見ているかの一点に集約されると思います．
竹中氏はあくまで「政府」を経済の調整役程度にしか思っていません．ですから，彼の
主張は「歪みの是正」と「今まで過剰に保護していた存在の保護を無くし，保護していなかった
人間を保護する」という政策をとろうとします．
しかし，この方法は今まで過剰保護されてきた人間の反感を買うに決まっています．過剰保護されてきた
人間は，その過剰保護を続けることができなくなったことに気づかず（あるいは気づいていても），
「今まで保護していなかった人間を保護しろ．ただし，俺たちの保護をやめることは許さない」という
のみです．この主張を擁護するのが「コメンテーター」です．
「コメンテーター」は竹中氏と違い，政府は神にも等しい，経済を全て操作できる存在であるかのように
言います．あるいは，全ての原因は政府が経済を操作できていないからだ，とも言います．それならば，
政府の権限をはぎ取り，小さな政府を目指せば良いのに，彼らの要求は大概手厚い社会保護を行う
大きな政府です．
この考えの背景にあると思われるのは，共産主義的な「計画経済」の考え，あるいは，「俺たちならば，こいつら
無能とは違い，全てを良くすることができるのに」といった傲慢な考えです．歴史的にも政府が本当に
正解の手を打ち続けて経済を良くすることができたのは，ほんの一瞬のことだけであり，これらの考えを
擁護できるような背景はありません．
まとめ
昔は，私も竹中氏のやってきたことは良くなかったと思っていましたが，経済学の授業を受けて以来
その考えは大分変わり，竹中氏はあの状況の中よくやったと思っています．
今後も，とにかく批判し要求し根拠を示さないコメンテーターは，テレビに出続けるかと思いますが，
正しい知識を見につけて，そういう無責任な批判を信じない力が求められると思います．
JavaからScalaに移ったときに（微妙に）はまった点
ようやくScalaのEclipseプラグインがまともに動くようになったので、順次Scalaで書くように移行訓練中です。その中で微妙にはまったり悩んだりした点など。
配列のインデックス
ほかの多くの言語とは違い、配列のインデックスはで囲うのでは無く、()で囲います。
配列使っている行でエラー表示されているときは、大体このエラーでした。identifierが
指定されていないというエラーメッセージが出てくるので、結構原因に悩みました。
(をコンパイラは型指定子と判断している)
配列、List、Map、Setの初期化
Javaとは違いScalaではこれらコレクションの初期化にnewは使いません。
配列はval a = Array()と書きますし、List、Map、Setも同様にList()、
Map()、Set()と書いて初期化します。
要素の追加ってどうすんの？
コレクション見るとaddメソッドが無くてどうしたもんかと悩みました。
コレクションに対する要素の追加は+=演算子で行います。
Set[Int]に対する要素の追加は例えば、
import collection.mutable._ val set = Set(1,2) set += 3
の様に行います。この例ではmutableなCollectionを使っていることに注意。
ちなみに+演算子は要素を追加した新しいコレクションを返す、破壊的代入
を行わないものです。
addAllどこ？
コレクションでよく使うメソッドである、addAllメソッドも見当たりません。
これは++=演算子で行います。
import collection.mutable._ val set = Set(1,2) set ++= Set(3,4)
map.entrySet()が無い
どーすんねん、keysはあるからmap(key)と書いてvalue取得すんのか？
とか思ってましたが、当然同じことは別のメソッドでできます。
toIterableを使えばよいのです。
val map = Map(1 -> 2, 2-> 3) for (val x <- map.toIterable) { println(x._1 + ":" + x._2) }
条件演算子は？
直接の条件演算子はScalaにはありません。しかし、Scala
ではifが文では無く式で値を返しますので実は以下のように
書けてしまいます。(恐ろしいことに)
val it = if (true) 3 else 4
breakは？
コップ本やら何やらではScalaにはbreakもcontinueも無いとあります。
これはJava風のループ処理をやるにはかなり面倒な問題です。
と、思っていたらScala2.8になってbreak入りました。9/4のScala座で
知りました。感謝感謝。コード例は以下の通り。
import util.control.Breaks.{break, breakable} var a = 0 breakable { while (true) { a += 1 if (a > 9) break } }
で、continueはどうやるのかというと
Scala2.8にも入ってません。ifで何とかしろとのことです。(ま、確かにね
AutoScrollの仕様 （備忘録）
PictureBoxとかのAutoScrollの際、表示されるScrollbarの各種の値がどうなるかようやくわかったのでその備忘録。以降「コンテンツ」＝「PictureBox内に表示させる画像等」の意味で使用
- Maximum = コンテンツの大きさ（Pixelそのもの）
- Minimum = 0
- LargeChange = コンテンツの大きさ - PictureBoxの大きさ （正確には違うかも）
- SmallChange = 3 （これも正確には違うかも）
なんというか、msdnのScrollBarのサンプルの方法と全く同じです。そしてLargeChangeは自動でいい値にしてくれますが、SmallChangeはそうしてくれないようです。
Valueの最大値 ≠ Maximumの問題と併せて本当うざい。なんとかしてくれMSさん。
何故経済学は役に立たないと思われるのか
私は計算機科学の学生で経済学は特別講義で一回習っただけで，あとは入門経済学とか読んだだけの知識です．でもまあ考察書きたくなったので書いてみる．
何故役に立たないと思われるのか
一つには，「一年後の経済状況の予測もできない」と思われているということが挙げられます．しかしながら，未来の予測なんて一年後どころか3日後だって不可能に決まってます．3日後のユーロの値段を100%当てられる人間がいたらそいつはとっくに億万長者です．
もう一つは，「有効な経済政策を示せていない」ということが挙げられると思います．実はこれが相当複雑な問題になっていると思います．
現代の経済学
授業の先生曰く，現代の経済学主流派は新古典派だそうです．有名な池田信夫氏や竹中平蔵氏も新古典派でしょう．新古典派の考えは，以下の2つに集約できると私は考えます．
- 手持ちの金でなんとかやりくりする（国債の発行をしない）
- 市場の失敗は政府が是正する
今までの認識と違うなあと感じたのは，現代の経済学ではケインジアン流の考えである，不況は公共事業で乗り切る，という考えを否定しているところです．新古典派は大規模公共事業を劇薬であるとして否定しています．
そのため，新古典派は不況時に有効な手立てを持っているとは言い難いです．新古典派の経済政策として挙げられるのは「給料を下げる」ことでしょう．給料を下げることで雇用枠を増やし，失業者を減らす策を取るのが新古典派です．当然猛反対を食らうでしょうし，「そんなことはわかっている」「だから経済学者は役に立たない」とか言われることでしょう．私も昔はそう思ってました．
しかし，現実問題として現在の日本を見る限り国債の発行による大規模経済政策が有効とはとても思えません．既に積み上がった国債の問題を抜きにしても，大規模経済政策には以下の二つの問題があるように思います．
- 不況から脱出した/してないの判断はどうするのか？
- 大規模経済政策によって本来の需要以上に膨れあがった産業をどう処理するのか？
以上2つの問題の解決策をどうにかしない限りは，大規模経済政策でなんとかしようと言うのは無謀ではないでしょうか．
私がプログラミング言語に望むこと
私もプログラミングに触れ始めてから5年ぐらい経ったので，今プログラミング言語について思うことをまとめておこう．
速度
速度は重要だ．とにかく言語を選ぶ段階でいきなり速度のボトルネックが発生するようでは困る．処理するデータが肥大化し続けている現在では，とにもかくにも早く無ければ困るのだ．速度が10倍になれば10時間かかるタスクも1時間で終わる．そうすれば世界は変わるのだ．速度の問題は大概ハードウェアが速くなったので問題は無くなったと言われるが，そんなことは無かったのだ．
文法はある程度どうでもいい
プログラミングを始めた当初は「この言語の文法が美しい」だの「この言語の文法は糞」だのと思っていた．しかし，そんなものはどうでもいいのだと気づく年になってしまったのだ．中括弧だろうが，begin-endだろうが，どーでもいいよ….
スタイルの強制はある程度必要
pythonやhaskellのインデントの強制は必要であると私は思う．あれはスタイルというより哲学だ．どうせインデントを合わせるのはプログラマーの嗜みという面があり，みんなそうするのが当たり前なのだから，強制してしまえばいいという考えだ．プログラミングをやっていく以上他人のソースコードを読む機会は必ず生じる．その際に必ず同じスタイルが保証されていることは大きなメリットとなる．
次は変数名など識別子の名前にも強制が入ると面白い*1．Rubyでは，変数の種類をファニーキャラクタや大文字で区別している．例えば先頭が大文字の変数は定数であり，@で始まればインスタンス変数だ．このように変数の種類の区別を名前に強制させるという試みを他の言語でもやってはどうか．フィールド変数は_で始めなければならないとか，終わらなければならないとか．慣習的にやられていて，ある程度効果があると考えられていることは，強制させるのが一番だ．
静的型付けは必須
静的型付けは必須だ．どれだけ動的言語が魅力的だろうが，静的型付けは必須なのだ．というかコンパイルというプロセスが必要なのだ．コンパイルはしょーもないエラーを検出する重要なテストである．どんなプログラムだろうが，しょーもないエラーは致命的な結果を招く．コンパイルによりそのエラーを実行よりも早い段階で検出できることは，非常に大きなメリットなのだ．
強力なtypedef
どちらも欲しい機能だ．強力な型付けとは，コンパイラが区別してくれるtypedefが欲しいということだ．Haskellのnewtypeはコンパイラが区別するtypedefとして機能している．
何故強力な型付けが必要なのかというと，StringやIntegerのようなデータを型のレベルで区別するお手軽な方法が欲しいからだ．型のレベルで区別するだけなら，classでデータを包んでしまえばいいのだが，classはとてもお手軽な方法とは言えない．classは多くの場合必要以上に強力で不要だ．
本当にあったScrollBarの怖い話
最近延々とWindowsFormApplicationのScrollBar関連の仕様で悩まされ続けていました。備忘録的にその一覧をば。
つまみの大きさはLargeChangeプロパティで調整可能
ScrollBarのつまみ。実はつまみの大きさはLargeChangeプロパティで変更可能
です。どこぞのWebページにはMinimumとMaximumを変えることで変更可能とありましたが、そんなことしなくても変更可能です。
