『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
うちも(ある意味)似たような状況である。
うちの娘の話を聞いてください。
ここ1年ほど、世間でいう「ニート」のような状態です。
外にも出ず、一日中家でゴロゴロしています。
仕方なく、私が外へ連れ出している始末。
気に入らない事があれば泣き、食事も私が用意した物を食べるだけ。
何かわからないことを呟いたり、急に奇声を発したり・・・。
もう少し時間をかけて見守るべきなのでしょうか。
生まれてから1年間、このような状態です。
今も、何か呟きながら、夫のベルトを持って部屋中ウロウロしています。
４時からのNHK教育の番組が好きなようなので、一緒に見てあげようと思います。
[ニート娘に悩む親より引用]
悩ましい。爆笑。
GoogleでのGuido van Rossumの生活の様子。
なかなか楽しそうだ。
いや、でも、フルタイムRubyのためにほぼ自由に使ってもかまわない私の方がもっと恵まれているわけだが。
あいかわらず日経Linuxの記事が終わらず悩んでいる。〆切今日なんだけどなあ。
で、あまりに悩んだので、本屋でJavaの本を購入。 買ったのは『楽しいJava・オープンソース JBossでWeb+DB開発してみませんか?』。 内容よりは水玉蛍之丞のイラスト(とマンガ)が購入の決め手になったのは内緒だ。
言語仕様はともかく、EJBやJBossなどについては無知なので大変参考になった。 またXDocletというコードジェネレーションテクニックを使ったツールがあるということも 名前だけしか知らなかったので勉強になった。
しかし、こんな泥縄の知識に基づいた原稿で読者の皆さんにちょっと申し訳ない気もする。 来月はちゃんとよく知ってるRubyに関連するネタを選ぼう。
しかし、こうやってJavaのプログラムを見ると、 自分でこういうプログラムを開発することを想像するだけで憂鬱になる。 世に入るという「Java好き」の人はこんな冗長性とか気にしないのかな。
裏表紙には「Javaが好きなプログラマだけに本書を勧めます！」とあるので、 私ははなから対象外なのかもしれないけど。
This work is licensed under a Creative Commons License.
IDEとの合せ技で一本と考えているからでは、インテリセンス入力頼みでVisual Studio を使っている人々は一般的ですし。http://d.hatena.ne.jp/epics/20060115/1137334872 <br>実行環境に複数言語(Java や .NET)ともちがい、<br>テキストの読みやすさを追求する Rubyの方向もありますが。
多くのプログラマは「C++で必要だったプロトタイプ宣言がいらないなんて素晴らしい！！」という程度のことしか考えていないのかも．
うーん、その本は読んでいないのであれですが、<br>通常の業務ではJavaのクラス名が英数文字列のIDだったりします。<br>基本的に配列しか使えない人が多いですし、Stringしか使えない人も多いです。オブジェクト指向は難しい、という人が多いのは信じられますでしょうか。<br>多くの現場を流れておりますが、基本的に日本のITサービスのプログラムの品質の低さというのは想像を超えるものがあります。<br>そのような教科書でダメですと、現場のプログラムを読むと卒倒されると思います。
この本がだめだとは思っていません。むしろ面白かったです。<br>Javaの冗長な流儀に「びっくりした」程度ですかね。<br><br>「日本のITサービスのプログラムの品質の低さ」については噂で知っているだけです。そんなにひどいんですかねえ。
全プログラムがクラスメソッドだけで構成されている、なんてことが普通にありえる（私は見たことがある）世界ですから....<br>理由は「誰でも分かるようにしないとだめだ」らしいんですが。JavaやらRubyやら以前の問題です。
それは「誰でも分かる」じゃなくて「誰でも同程度に分かりにくい」じゃないでしょうか。
日本ではOOAやOODに対する偏見が強くそれが行き過ぎてOOPを一切許可しないフレームワークを作る人たちが時々います。それを無意識でやってしまう人もいます。前者が作ったフレームワークではJavaのServletやJDBCをラップして全てStringの配列で返すということをしますし、後者のフレームワークでは全てのAPIが同じ数、同じ型、同じ名前の引数を必要とします。私が見たものは引数にStringが9個必要なものでした。このようなフレームワークを作成してしまう現場では言語の記述量の冗長性とか保守性とかは考慮されず、いかに短時間で大量のソースコードを作成するかが重要視されていると感じます。例えばExcelでコピペの要領で大量のソースコードを生成すると高い評価を得ますが、現場では保守しがたいコードをデバッグすることになり苦労していたりします。日本にはSEという特殊な技術者が存在し、プログラマには詳細の決定権がありません。SEは主に設計だけを担当しプログラムが書けない人も珍しくありません。このような日本の現場ではRubyのような高い記述力を求める声はあまり聞かれません。<br>まつもとさんが読んだ本はXDocletを使用とのことで少し古い内容だと感じました。JDK5.0でEoDが唱えられて以来、大分書きやすいフレームワークが増えてきています。Spring、EJB3、Seasar等をキーワードにJavaを再評価していただけるとJava好きとしてはうれしく思います。個人的にRubyはendだけ冗長に感じています:-)
「通りすがり、再び」さん。<br><br>前半についてはご愁傷様としか言いようがありません。「偉い人」の誤解・偏見で開発者が苦労するさまには涙を禁じえません。<br><br>後半。XDocletはもう古いんですか。2005年3月発行の本なんですけど。Javaも動きが速いですね。はたからみるとRubyもそうなんでしょうか。<br><br>最後に「endの冗長性」ですが、どうしても気に入らない向きには以下のURLを参照していてください。<br><br>http://www.rubyist.net/~matz/20050607.html#p02