K.Maebashi's BBS

>初めまして，ねこさんといいます。 ねこさんさん(でいいんでしょうか?) はじめまして。 >例 >Aというメタデータ内 >＜Keyword＞仲間＜／Keyword＞ >＜PKeyword＞学校＜／PKeyword＞ > >Bというメタデータ内（Aと同じく） >＜Keyword＞相性＜／Keyword＞ >＜PKeyword＞仲間＜／PKeyword＞ ええと、私はLOMについては今調べた知識しかありませんので、見当外れの ことを言ってましたらすみません。 このモデルには正直ちょっと違和感を感じます。 a)あるデータについて、Keywordはひとつのような気はしませんし、 b)KeywordとPKeywordの区別はつけられるのか、という気がしますし、 c)LOMだと、他のリソースを参照する場合はRelationという要素を使うようですし。 >AのKeyword属性とBのPKeyword属性が同じなので >AとBは関係しているようにしたいのです。 > >これをDBに記述すると >メタID　メタデータ名　Keyword属性　PKeyword属性　リンク先ID >　1　　　　　A　　　　　仲間　　　　　　学校　　　　　 2 >　2　　　　　B　　　　　相性　　　　　　仲間　　　　　 Keywordがひとつでよく、KeywordとPKeywordの区別があってよく、 ひとつのメタデータが参照するメタデータもひとつでよいのなら、 このテーブルでよいのでしょうが、それでよいのでしょうか? ひとつのメタデータには複数のキーワードがあり、 あるメタデータから、共通するKeywordを含む(全ての?)メタデータへの 参照を持ちたいのなら、テーブルを分けて正規化するのがセオリーの ように思うんですが、どうでしょうか。 >またこれを実現するための >オブジェクト指向が聞けるとすごく嬉しいです。 >（これを先に教えていただけると嬉しいです） 「オブジェクト指向が聞けると」というのはちょっとよくわかりませんが (^^; a)メタデータクラスとキーワードクラスができて、 b)メタデータクラスはキーワードクラスを0..*で集約していて、 c)キーワードクラスは、そのキーワードにより関連するメタデータへの 　参照を保持するようにする。 または、LOMの構造を意識するなら、 a)メタデータクラスとキーワードクラスとリレーションクラスができて、 b)メタデータクラスはキーワードクラスを0..*で集約していて、 c)メタデータクラスはリレーションクラスも0..*で集約していて、 d)リレーションクラスは、そのメタデータと、何らかの要因(必ずしもそれは 　キーワードの一致でなくてもよい)で関係するメタデータへの参照を 　保持するようにする。 ということになるのではないでしょうか。 ズレたこと言ってましたらすみません。

初めまして，ねこさんといいます。 質問です。 メタデータのタグの間にある語彙と別のメタデータのタグの間にある語彙 を関係付けDBに反映するプログラムをJAVAで作成しようとしているのですが， なんせ初めてなもので何処からはじめていいのかが解りません。 またメタデータは，XML形式（LOM）です 例 Aというメタデータ内 ＜Keyword＞仲間＜／Keyword＞ ＜PKeyword＞学校＜／PKeyword＞ Bというメタデータ内（Aと同じく） ＜Keyword＞相性＜／Keyword＞ ＜PKeyword＞仲間＜／PKeyword＞ である場合，（特に脈絡は、ありませんがメタデータには，タグが 　　　　　　　KeywrodとPKeywrodがありその間に語彙が記述されています） AのKeyword属性とBのPKeyword属性が同じなので AとBは関係しているようにしたいのです。 これをDBに記述すると メタID　メタデータ名　Keyword属性　PKeyword属性　リンク先ID 　1　　　　　A　　　　　仲間　　　　　　学校　　　　　 2 　2　　　　　B　　　　　相性　　　　　　仲間　　　　　 このようにKeyword属性とPKeyword属性が同じメタデータがあった場合 Keyword属性の方にリンク先IDを追加する。 (リンク先IDは，Keyword属性とPKeyword属性が同じだった場合の PKeyword属性のメタIDが反映される。上記で記すと2となる） また新しくメタデータが追加された場合，同じくDBに反映させたいのです。 どのようにプログラムをすればよろしいでしょうか？ またこれを実現するための オブジェクト指向が聞けるとすごく嬉しいです。 （これを先に教えていただけると嬉しいです） 長々と申し訳ありません。どうぞ宜しくお願い致します。 以下にメールを書きます 3aeem029@keyaki.cc.u-tokai.ac.jp

>>hoge.h, piyo.hが共にプライベートヘッダファイルならどこかでまとめて >>#define GLOBAL_VARIABLE_DEFINEして#includeしますし、 >そのまとめて include っつーことは globals.c とか作るということですか？ >モジュール切り分け原則に反しているような気がしてなんとなくいやです。 globals.cを作るか、ということですが、 そのglobals.cが、プログラム全域のグローバル変数の定義を行う、 ということなら、Noです。 あるモジュールについて、「そのモジュールの内部だけで使う、ソースを超えた スコープを持つ変数」の定義を行うglobal.cなら、作るかもしれません。 たとえば先のcalcの例だと、電卓モジュール「CLC」内にglobals.cを 置くかもしれません(モジュールごとにディレクトリが分けられていて、 ソースファイル名の重複が許されるとして)。 モジュールをまたがったglobals.cがあるなら「モジュール切り分け 原則に反している」と私も思いますが、モジュール内でしか見ない グローバル変数のためのglobals.cなら、問題ないと思います。 # ここでモジュールは「複数の.cの集合体」と定義しています。 ## Mayerさんの「オブジェクト指向入門」に「ヘッダファイルはモジュールを ## 破壊する」ってあったけど、使い方次第だと思うんだけどなあ。 ただ、実際には、ひとつのモジュールに、そんなにたくさんプライベート ヘッダファイルがあるわけはないので、どこかのソースで代表させて終わりです。 CLCの場合はinterface.cですね。 # どこのソースで代表させるかが不明確なので(たとえ3行しかなくても)globals.c # を書くべきだ、という主張には正当性があると思います。 >組み込み系では「状態保持」のための変数は、プログラムが生きている >＝電源が入っている限り、ずっと必要なので必然的に静的変数(大域変数)になっちゃいます。 >んで getter/setter も最適化の都合でインライン関数化したかったりするんです。 なるほど。アクセサを書くことまではできても、ヘッダファイルを切り分けると、 コンパイル単位が分かれてしまうからインライン展開が効かず効率が悪くなる わけですね。 Javaなんかだと、javacによるコンパイルはソース単位ですが、 JITコンパイラが実行時にソースを超えたインライン展開までやってくれたり するようです。でも組み込みじゃ難しいですよね。

>hoge.h, piyo.hが共にプライベートヘッダファイルならどこかでまとめて >#define GLOBAL_VARIABLE_DEFINEして#includeしますし、 そのまとめて include っつーことは globals.c とか作るということですか？ モジュール切り分け原則に反しているような気がしてなんとなくいやです。 >piyo.hが別モジュールのパブリックヘッダなら、グローバル変数は公開しないので >この問題は起きないんですね。 御意。ではあるのですが... 組み込み系では「状態保持」のための変数は、プログラムが生きている ＝電源が入っている限り、ずっと必要なので必然的に静的変数(大域変数)になっちゃいます。 んで getter/setter も最適化の都合でインライン関数化したかったりするんです。 っとなるとプライベートヘッダとパブリックヘッダの分離とか、 理想を追いかけていられない実装上の都合があったりするのです(泣)

>手間と言えば手間なんですが、グローバル変数にするような >ものは、必ず初期化する趣味なので、GLOBAL みたいな簡単な >マクロでは対処できなかったりします (たとえ 0 や NULL で >初期化する場合でも、明示的に初期化するスタイルを採って >ます)。 GLOBAL char *hoge[] #ifdef GLOBAL_VARIABLE_DEFINE = { "foo", "bar", } #endif /* GLOBAL_VARIABLE_DEFINE */ ; とか書いたこともありますけどね (^^; >また、そもそもグローバル変数なんてほとんど使わないので、 >手間的にはたいしたことないです。 別レスで書きましたけど、実は私もそうです。 別レスで挙げたCLC_Interpreterのように、構造体にまとめて malloc()で領域を確保することが多いです。 # わかりにくいですがCLC_Interpreterはポインタでして、 # こういうふうにポインタがポインタでないかのようにtypedefするのは # よろしくないなあ、と今は思っています。当時はXtとかのスタイルを見て # かっこいいと思ってしまったわけですが。 ## clc_current_interpreterのようなものを静的に持ってしまうと ## リエントラントでなくなります。当時はマルチスレッドなんて ## そうそう使わないよね、と思ってたわけですが… ## まあ、リエントラントにしたい場合も、外部のインタフェースにだけは影響を ## 与えないようにしてあるからまあ許容範囲かと。 >昔風のプログラムなら >グローバル変数にする場合も、たいていは accessor/mutator >関数でラップして見かけは関数にしてしまうことがほとんど >です。 たとえばclc_current_interpreterは関数でラップされていませんが、 CLCモジュールの外から見えることもありません。 これはモジュールの粒度をどのくらいにするかという問題だと思いますが、 「関連の強いソースの集合体としてのモジュール」内(せいぜい数千行レベル)で あれば、この程度のカプセル化の侵食は許容範囲じゃないかなあ、 と私は思っています。 もちろん最初からgetter/setterを書いたからといってさしたる手間でも ないですけれど。

>http://kmaebashi.com/programmer/pointer.html >では GLOBAL int global_variable; を推奨されているようですが、私は反対です。 うーん。 GLOBALに反対する根拠として一番大きいのは、私としては 「Cの構文をねじ曲げるようなマクロはよろしくない」という原則に 反しているからじゃないかな、と思っています。 #define BEGIN { みたいなシンタックスのレベルで改変を入れるようなマクロは確かに いろんな意味でまずいでしょう。 >hoge.c の中で >#include "hoge.h" >int global_variable; >と書いても ISO 文法上何の問題も無いので。 これはそうですね。 >もし仮に hoge.c の中で >#define GLOBAL_VARIABLE_DEFINE >#include "hoge.h" >#include "piyo.h" >とかやっちゃうと hoge piyo 両方の大域変数が定義されてしまいます。 私のヘッダファイルの切り分け方からすると、 http://kmaebashi.com/programmer/c_yota/module.html hoge.h, piyo.hが共にプライベートヘッダファイルならどこかでまとめて #define GLOBAL_VARIABLE_DEFINEして#includeしますし、 piyo.hが別モジュールのパブリックヘッダなら、グローバル変数は公開しないので この問題は起きないんですね。 >わざわざ同一の記述を複数の個所で行なうのは間違いのもとである このメリットは一応それなりの説得力はあるかと思っています。 が、私が実際これをどう使っているかというと、たとえばここで 公開しているソースでは、 http://kmaebashi.com/programmer/c_yota/calc_html/calc.html #ifdef GLOBAL_VARIABLE_DEFINE #define GLOBAL #else #define GLOBAL extern #endif GLOBAL CLC_Interpreter clc_current_interpreter; これ一個だけ…　だったら必要ないじゃん、というのはもっともですね (^^;

> hoge.h の中では必ず > extern int global_variable; > と書くべきだと考えます。 僕も自分で一から書くソフトウェアでは、 GLOBAL のようなマクロは使わず、extern 宣言と、変数の 実体の定義と 2回書いてます。 手間と言えば手間なんですが、グローバル変数にするような ものは、必ず初期化する趣味なので、GLOBAL みたいな簡単な マクロでは対処できなかったりします (たとえ 0 や NULL で 初期化する場合でも、明示的に初期化するスタイルを採って ます)。 また、そもそもグローバル変数なんてほとんど使わないので、 手間的にはたいしたことないです。昔風のプログラムなら グローバル変数にする場合も、たいていは accessor/mutator 関数でラップして見かけは関数にしてしまうことがほとんど です。プロファイルとって効率が問題になるようだったら、 あとで実装をマクロに直すだけですから、最初からグローバル 変数として見せる必要があるとは思えません。逆に、最初は 変数で済んでいたものが、後になって変更時に手続きをフック したくなることは結構あります。(単に最初の仕様検討がいい 加減なだけだって話もありますが… ^^;) > globals.c とか作るのは個人的には嫌っています。 同じく globals.c みたいなものは作りません。 こういうのって、モジュール分けの原則に反してますよね。

　はじめまして、トルと申します。 　追加・削除する時は、分けると２箇所を修正する必要がありますから、分けない方が一箇所で済み、何かと楽ではないですか？ >globals.c とか作るのは個人的には嫌っています。 　私は嫌いではありませんよ。

発言数が少ないようなのでネタ振りなど。 http://kmaebashi.com/programmer/pointer.html では GLOBAL int global_variable; を推奨されているようですが、私は反対です。 hoge.h の中では必ず extern int global_variable; と書くべきだと考えます。 hoge.c の中で #include "hoge.h" int global_variable; と書いても ISO 文法上何の問題も無いので。 もし仮に hoge.c の中で #define GLOBAL_VARIABLE_DEFINE #include "hoge.h" #include "piyo.h" とかやっちゃうと hoge piyo 両方の大域変数が定義されてしまいます。 #undef GLOBAL_VARIABLE_DEFINE しますか？めんどくさいです。 ヘッダ中から別ヘッダを #include しているとそもそも分離不可能だし。 globals.c とか作るのは個人的には嫌っています。 >わざわざ同一の記述を複数の個所で行なうのは間違いのもとである こと自体は御意なのです。でも、 関数(原型)宣言と関数定義を両方書く必要があるなら、 大域変数の宣言と定義を両方書いても大差ないぢゃん、とか思う今日この頃。 皆様はどうお考えですか？

>「ハッカーと画家」、出版されるみたいですよ。 > >http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Shiro 　遅くなりましたが、情報提供ありがとうございます。 　Webで公開されている文書11本に、書き下ろしを4本加えた本ですか。 その11本がどれだかわからないのですが、この中からチョイスしたものなんですかね。 　http://www.paulgraham.com/articles.html 　翻訳されたものがWebで読めるのかわかりませんが、読めるのだとしたら、 やっぱりどうしても購入を躊躇してしまう…

こんにちは。 「ハッカーと画家」、出版されるみたいですよ。 http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Shiro ↑の、2004/9/30の箇所で査読者募集していました。

>ですよねぇ。あれだけ居た人々はいったいどこに行ってしまったのでしょうか。 ># Java人口自体は増えてると思うんですが……。 2chかなあ… それとも小さなコミュニティに分散したのか… これは私も不思議に思っていますので、ご存知の方、情報をお願いいたします(_o_)

>JavaHouse自体、最近はほとんど流量がないじゃないですか。 ですよねぇ。あれだけ居た人々はいったいどこに行ってしまったのでしょうか。 # Java人口自体は増えてると思うんですが……。 # 最近はどの案件もみ～んなJava。(おいらは異端のPerl屋さん^^;) >私が知っているところだと、Java読書会BOFくらいですかねえ。 情報ありがとうございます。一度入って様子を見てみます。 >JavaMailネタでしたら、木下さんもいますし。 そーいえばJavaMailの本の存在をどっかで見かけたよーな気がするなー、と思って 「JavaMail 木下」でぐぐってみたのですが……まだちゃんと中身確認してませんが、 この本とWebページみれば質問事項一通り解決しそーな予感が(^^; ぁぅぁぅ。 # 如何にJavaについて情報収集してなかったかとゆー……。

>JavaHouseに質問投げたら応答無し子さん(;_;)だったので JavaHouse自体、最近はほとんど流量がないじゃないですか。 アーカイブも復活しませんし。高木さんもすっかり投げてますよね。 というわけで >## それとも質問の仕方がマズかったのかなぁ……。 これはないと思います。 >他のところに聞こーかと思うんですが、どこか良さげな >ところありますでしょーか? 私が知っているところだと、Java読書会BOFくらいですかねえ。 http://www.iaj.or.jp/bukai/java/wg_bof/jfriends.html JavaMailネタでしたら、木下さんもいますし。

JavaHouseに質問投げたら応答無し子さん(;_;)だったので 他のところに聞こーかと思うんですが、どこか良さげな ところありますでしょーか? # 2ch?(^^; ## それとも質問の仕方がマズかったのかなぁ……。

>規格の6.2.1.5を見る限り、両辺の型が浮動小数点数でもlongでも >unsignedでもなければ、両オペランドがintに拡張されることになっています。 すいません。 テストする時、下記のようにpiyoに200を代入してました。 hoge = 100; piyo = 200; で、投稿する時に(手が勝手に？)piyoに100を代入して送ってしまいました。 お騒がせしてすいませんでした。 前橋さん、774RRさんありがとうございました。

LSI-C 86 試食版とか。 これは最近では数少ない non-ISO compliant な悪名高き処理系です。 もともと i8080 系のためのコンパイラとして開発されたため char と char の演算は char のまま行ってくれます。 っていうか README にその旨書いてあるので、理解し評価し納得した上で 使わないといけないのですが...

>表題の件ですが、どこかで「式の中ではchar型の変数は、int型に格上げされる」 規格の6.2.1.5を見る限り、両辺の型が浮動小数点数でもlongでも unsignedでもなければ、両オペランドがintに拡張されることになっています。 >オーバーフローせず、fooに10000が代入される。というような説明を >読んだ記憶があるのですが、いまやってみるとしっかりオーバーフローしてくれます。 というわけで私のところでも試してみましたが、 bcc32とgccの両方で、しっかり10000が代入されました(gccはLinux上、 gccに-Wallを付けた以外はどちらもオプションなし)。 すみませんが、tosさんが実験された処理系とコンパイルオプション、 および再現できる完全なソースコードを教えていただけませんか? ちなみに私はこんなソースで試しました。 #include <stdio.h> int main(void) { char hoge; char piyo; int foo; hoge = 100; piyo = 100; foo = hoge * piyo; printf("foo..%d\n", foo); return 0; }

皆さん、こんにちは。 表題の件ですが、どこかで「式の中ではchar型の変数は、int型に格上げされる」 というような説明を読んだような気がして、またそこで下記のような例で、 char hoge; char piyo; int foo; hoge = 100; piyo = 100; foo = hoge * piyo; オーバーフローせず、fooに10000が代入される。というような説明を 読んだ記憶があるのですが、いまやってみるとしっかりオーバーフローしてくれます。 「kmaebashi.com内」を検索して、「intより小さい整数型は、可変長引数で渡される ときには無条件でintに格上げされています。」との前橋さんの発言は見つかったのですが、上記のような説明はやはりありませんでした。 やっぱり記憶違いでしょうか? #でも、どっかで読んだような気がするのですが･･･。 #C FAQでもないみたいなんですよね。

はじめまして。 >はじめて納得がいきました。 どうもです。ほめていただき恐縮です。というかそこまでほめていただくと はずかしいです (^^; 更新が止まっておりましてすみません。 ログを見ると、「オブジェクト指向」で検索エンジンで探してうちのページに たどり着く人は結構いるようなので(検索キーワードとしては、hoge、 ポインタ、オブジェクト指向, PHP 掲示板、樹海あたりが多いです)、 ぼちぼちでも更新したいと思っているのですが。 ただ、この後、継承やインタフェースの話となると、結局普通の入門書と 同じような話になっちゃうのかなあ、という気もしています。 # あ、その前に、「PHPとMySQLで掲示板を作る」もさっさと書かないと…

オブジェクト指向がさっぱりわからず、本を読んだり掲示板をみたり いろいろなサイトをみたりしておりました。 すばらしいです！！！！ はじめて納得がいきました。 本当にありがとうございます（深々

> お客さんのとこに出張して 1時間くらいので、 > 大雑把にデータを整理して何かの資料を作りたいとか言う場合に > 手作業をほんのちょっと減らしたいなんて程度に使う分には > ザクザクッと作れちゃうperlみたいな形無し言語ってとても便利だと思いますが。 お客さんのとこに出張して、さくっとデータ変換しなきゃいけなかった時、 Perlはなく、AWKを使ったら、何しろ日頃使っていないものだからえらく 苦労した、という経験があります。客先じゃNUTS SHELLは落ちてないし、 当時はさくっとGoogleできる環境でもなかったですし。 やっぱり普段から使ってないといかんですねえ。

> 手作業をほんのちょっと減らしたいなんて程度に使う分には > ザクザクッと作れちゃうperlみたいな形無し言語ってとても便利だと思いますが。 実は、恥ずかしい話なんですが。。 僕は、多少なりとも自信を持って使える言語がCとJavaしかなかったりします。 前橋さんの「C言語体当り学習」で、タブをスペースに変換する サンプルコードがありましたが、いつもあんな感じで、CやJavaで 作業用のツールを書いてました。 で、最近になって、他の人達が、perlやrubyを使ってサクッと作っている様子 などを見て、「ひょっとして、壮大な時間の浪費をしているのでは？？」 と感じるようになったのでした。 # もちろん、決して無駄になったとは思ってませんけど。 > 色んな言語に触れて適材適所を身に付けたらベストでしょう。 > 何でもかんでもオブジェクト指向言語万歳じゃないと思うし ありがとうございます。励みになります。 よーし、がんばるぞ。

>でも、PerlならPerlの作者は、長年の経験を積んだ名うてのハッカーであるわけで。 >頭のいい人なら型無し言語でもいいのかもしれません。 なるほど。。 じゃあ、僕はダメかもしれないです（笑） しかも、 >私はと言えば、「この世の中に自分より信用できないものが他にあるかーっ」 >という横島クンの叫び(うろ覚え)に共感する側の人間です。 僕の場合、「自分より信用できないものが他にあるかー」と叫びつつ、 常に自分を甘やかしてしまう人間なので、なおのこと、強い型付けの 言語の方が向いてるかもしれませんね。 でも、やはり視野を広げるために、色々な言語も知っておかなきゃ、 とも思うのです。 # そもそも、CとJavaすら使いこなしてるとは言えなかったりしますけど。。

>>というのは、前橋さんの長年の経験が導き出した答えなんだなぁ、と。 >でも、PerlならPerlの作者は、長年の経験を積んだ名うてのハッカーであるわけで。 >頭のいい人なら型無し言語でもいいのかもしれません。 名うてでも頭よくもないですけど型なしでいいと思うときと言うと、 お客さんのとこに出張して 1時間くらいので、 大雑把にデータを整理して何かの資料を作りたいとか言う場合に 手作業をほんのちょっと減らしたいなんて程度に使う分には ザクザクッと作れちゃうperlみたいな形無し言語ってとても便利だと思いますが。 そういう場合って例外処理だのは、おかしかったら やりなおせばいいのでどうでもよくて、 ちょっと出力に怪しい部分があってもおかしなところだけ手で直せばいいや、 ざっくり結果出してくれやってな感じで使うにはperlって重宝しますよねぇ。 その場合でも型があっても邪魔にならないんじゃないかって言われると んー、どうなんでしょうねぇ。文字列→数値ってなことを 型を意識せずにチャキチャキして欲しいとき型は邪魔かなって思うんですけど。 必要に応じて必要な関数にだけ構造体のメンバを増やしたりとか 手軽にできるし。 #一番困るのはそんなプログラムの一人歩きだったりしますが。 しっかりと設計に時間がかけなくちゃいけない規模のプログラムや、 後でメンテナンスが必要になるようなプログラムには 当然型があるべきだというのは もちろん同意します。 っていうか、設計って型を決めることでは(暴論) っていうか、型さえキレイに決まっていたら後はなんとでもなると思うし(極論) >>今はまだ、色々な言語に触れてみたいなぁ、なんて思ってしまいます 色んな言語に触れて適材適所を身に付けたらベストでしょう。 何でもかんでもオブジェクト指向言語万歳じゃないと思うし。 10分ででっち上げなくちゃいけない場合なんかは。 ま、適材適所ってことで。

>というのは、前橋さんの長年の経験が導き出した答えなんだなぁ、と。 でも、PerlならPerlの作者は、長年の経験を積んだ名うてのハッカーであるわけで。 頭のいい人なら型無し言語でもいいのかもしれません。 結局、自分自身をどこまで信用できるか、という問題のように思います。 私はと言えば、「この世の中に自分より信用できないものが他にあるかーっ」 という横島クンの叫び(うろ覚え)に共感する側の人間です。

>あー懐かしいスレ。 >このスレが現役だった頃はム板も読んでたんですが、最近はさっぱりです。 このスレが現役だった頃、僕はまだ、プログラマじゃなかったです（笑） それで、思ったんですが、 >もちろん用途次第で、静的な型付けがない方がよい場合もあるかもしれません。 >でも私は嫌です。自由よりも犬の首輪が欲しい方なんで。 というのは、前橋さんの長年の経験が導き出した答えなんだなぁ、と。 それに比べると、僕はまだよちよち歩きを始めたばかりで、「あれに触れると 熱くてやけどする」だとか、「あれに近付くと噛みつかれる」だとか、 そういったことを経験してないから、いまいちわかっていないのかもしれません。 今はまだ、色々な言語に触れてみたいなぁ、なんて思ってしまいます。

>怪しいメールは朝4 ～ 6時に来るとムカつきますね。 >まだ眠た・・・いや、バッチでコケたかと思ってドキッとします。 うーんと。 徹夜作業中(監視中?)ですか? お疲れ様です。

>>あー、正直、定年間近なプログラマ(35才定年説が正しいとして)である >>私としては、ツールの使い方などは「隣の席の若い奴に聞く」というのが >>最近常態化しています。こんなこっちゃいかんとは思うんですが。 >うーん。そうですか。 >業務以外のグループで使っているような門外漢なツールならそれは >ありだと思うんですけど、 いやもちろんツールの使い方は知らなきゃいけないと思いますが、 最近の私のボケっぷりからすると、ちと人のことを言えた義理ではないなあ、と。 >VBできます、VC++できますとプロジェクトに入ってきたものの、 >プロジェクトにファイルを追加することができなかったり、 >ライブラリやインクルードパスの設定方法が解らない＋そうする意味が解らないとか、 >モジュールのプロパティ設定ウィンドウが消えて2時間悩んだ、 といっても、さすがにこれはどうかと思いますが。

いろいろあって週末は死んでました。 >と思ったら、↓こんなのを見付けました。 >http://pc.2ch.net/tech/kako/986/986355498.html あー懐かしいスレ。 このスレが現役だった頃はム板も読んでたんですが、最近はさっぱりです。 >ただ、個人的に使ってみるぶんには、型安全でない言語の方が色々できて >面白そうかな、なんて思ってしまいました。 もちろん用途次第で、静的な型付けがない方がよい場合もあるかもしれません。 でも私は嫌です。自由よりも犬の首輪が欲しい方なんで。