Ａｐｐｌｅ株大暴落

[東洋海亀]

ＩＮＯのＸｔｒｅｍｅ  Ｄａｙ  ２０００年９月２９日付によると、Ａｐｐｌｅ  Ｃｏｍｐｕｔｅｒ  ＩＮＣ  （ＡＡＰＬ）がなんと木曜の引けと比べると５１．９９％の大暴落である。

[GON]

"東洋海亀" <ia...@mutt.freemail.ne.jp> wrote in message news:8r4tqo$i5s$3...@nwms2.odn.ne.jp...
> ＩＮＯのＸｔｒｅｍｅ Ｄａｙ ２０００年９月２９日付によると、Ａｐｐｌｅ Ｃ
> ｏｍｐｕｔｅｒ ＩＮＣ （ＡＡＰＬ）がなんと木曜の引けと比べると５１．９９％
> の大暴落である。

Ｍａｃってシェアが小さいからあまりＭａｃ向けにソフト開発してもメリットがない。
だからソフトが少ない。だってＭａｃの開発系の雑誌てほとんど廃刊になっちゃったでしょ。
開発する人がほとんどいないんだよ。

だからいくら器が良くても中身がパーじゃダメってことでしょ。

もうちょっとＭａｃも開発環境を何とかしてくれればソフトも増えると思うんだけどね。
いまだにＣｏｄｅｗａｒｒｉｏｒだけって言うんじゃ終了してる。

＃　Ｍａｃ版のDelphiがあったら結構作る人も増えると思うんだけどなぁ。

＃　それより亀さん、無意味なＨＴＭＬ投稿止めてくれません？ＨＴＭＬにしても
＃　意味ないじゃん！

[Shidori Tomoki]

東洋海がめ氏には何を言っても無駄であることは分かっているので、
なにもいいませんが。

In article <8r54dt$8ft$1...@nw041.infoweb.ne.jp>, "GON"
<opens...@hotmail.com> wrote:

> Ｍａｃってシェアが小さいからあまりＭａｃ向けにソフト開発してもメリットがない。

今どき何を言ってるの？？？？一般家庭の中におけるシェアは無視でき
ない大きさなので、ほうぼうで Mac の開発ができる人間を集めている
ようだけど？

> いまだにＣｏｄｅｗａｒｒｉｏｒだけって言うんじゃ終了してる。

RealBasic や FutureBASIC の存在も知らんでいってるのね(^^;;;

＃終了してるのは君のほうでは？？

> ＃　Ｍａｃ版のDelphiがあったら結構作る人も増えると思うんだけどなぁ。

RealBASIC のおかげですでにもうずいぶん増えてますが。

で、問題の Apple の株価ですが、Jobs の復活以降の株価の暴落は、いつも
ちょっと業績が悪くなった時に起こっています。ようするに、市場は昔の
イメージに引きずられて、Apple という企業を信用してないと言うことにつき
る思えます。なんか、あんまりにもセンシティブに株価が動き過ぎるからねえ。

--
--
しどり　ともき
IIsi@27MHz iMac@Rev.A(ToT)
<http://www.geocities.co.jp/SiliconValley-SanJose/1544/>

[Kimura Katsuhiko]

In article <8r57jk$sbi$1...@news01bb.so-net.ne.jp>, tshi...@wl.me.titech.ac.jp
says...

>> いまだにＣｏｄｅｗａｒｒｉｏｒだけって言うんじゃ終了してる。
>
>RealBasic や FutureBASIC の存在も知らんでいってるのね(^^;;;
>
>＃終了してるのは君のほうでは？？

そういえば、FutureBASICがやっとバージョンアップしましたね。

--
kim

[GON]

"Shidori Tomoki" <tshi...@wl.me.titech.ac.jp> wrote in message news:8r57jk$sbi$1...@news01bb.so-net.ne.jp...

> > Ｍａｃってシェアが小さいからあまりＭａｃ向けにソフト開発してもメリットがない。
>
> 今どき何を言ってるの？？？？一般家庭の中におけるシェアは無視でき
> ない大きさなので、ほうぼうで Mac の開発ができる人間を集めている
> ようだけど？

じゃぁなんで開発系の雑誌がほとんど廃刊になってるの？

それと昔いた会社でＭａｃ版のCD-ROMが出せるか検討したことがあったけど
あまりにユーザが少ないということで採算に合わないので断念した経験があります。

> > いまだにＣｏｄｅｗａｒｒｉｏｒだけって言うんじゃ終了してる。
>
> RealBasic や FutureBASIC の存在も知らんでいってるのね(^^;;;

RealBasicはメーリングリストにも入ってるんで知ってます。
でも商用アプリはまだまだCodeWarriorが主流ですね。

> > ＃　Ｍａｃ版のDelphiがあったら結構作る人も増えると思うんだけどなぁ。
>
> RealBASIC のおかげですでにもうずいぶん増えてますが。

MacOSがPascalベースならDelphiを移植してもいけるんじゃないかなぁって
思うんですけどね。

> で、問題の Apple の株価ですが、Jobs の復活以降の株価の暴落は、いつも
> ちょっと業績が悪くなった時に起こっています。ようするに、市場は昔の
> イメージに引きずられて、Apple という企業を信用してないと言うことにつき
> る思えます。なんか、あんまりにもセンシティブに株価が動き過ぎるからねえ。

それだけじゃないと思いますけど。

本質的にはハードの問題よりソフトの問題だと思いますけど。
ソフトが少なきゃハードだって売れませんしね。

[Shidori Tomoki]

In article <8ra9ug$j7b$1...@nw042.infoweb.ne.jp>, "GON"
<opens...@hotmail.com> wrote:

> じゃぁなんで開発系の雑誌がほとんど廃刊になってるの？

あのさあ、こう、時系列を理解してものをいおうよね。
昔と今とでは状況が違うの。廃刊が相次いだのはいつ？で、今は何年？

しっかりしてよ(^^;;;;;。

> MacOSがPascalベースならDelphiを移植してもいけるんじゃないかなぁって
> 思うんですけどね。

そうかなあ、、、Delphi はマニアにしかうけんからなあ、、、

> 本質的にはハードの問題よりソフトの問題だと思いますけど。
> ソフトが少なきゃハードだって売れませんしね。

いまいちつながりが分からないんですが？株価の動きと何か関係がある
発言なんですか、これって？

だいたい、今でも Mac は売れているんですけど？それから目をそらした
いんですか？あなたも？

今回の業績下方修正せざるを得なかった原因は、

１）クロック数上昇が伸び悩んで、買い替え需要が盛り上がらない。
２）さらに加えて、MacOS X という今年の目玉になるはずの商品が
でなかった。

の、２点に尽きるでしょう。ソフトの数は、去年よりむしろ増えているので、
関係ないですよ。っていうか、そんなものを持ち出すのは、東洋ウミガメぐ
らいと思うんだけどねえ。

[GON]

"Shidori Tomoki" <tshi...@wl.me.titech.ac.jp> wrote in message news:8racve$sm1$1...@news01ch.so-net.ne.jp...

> In article <8ra9ug$j7b$1...@nw042.infoweb.ne.jp>, "GON"
> <opens...@hotmail.com> wrote:
>
> > じゃぁなんで開発系の雑誌がほとんど廃刊になってるの？
>
> あのさあ、こう、時系列を理解してものをいおうよね。
> 昔と今とでは状況が違うの。廃刊が相次いだのはいつ？で、今は何年？

どう状況が違うんでしょうか？Macの開発系雑誌って見当たらないんですけど。
インターネットが普及したから雑誌はいらなくなったっていうことですか？

じゃあなんでWindowsの開発系雑誌はたくさん出てるんでしょうね。

> > MacOSがPascalベースならDelphiを移植してもいけるんじゃないかなぁって
> > 思うんですけどね。
>
> そうかなあ、、、Delphi はマニアにしかうけんからなあ、、、

開発ツールとしてREALbasicを例に出しといてDelphiはマニアうけって
いうのもどうでしょうか？RAD開発ツールとしてはREALbasicと同じような
ものだと思いますけど。

> 今回の業績下方修正せざるを得なかった原因は、
>
> １）クロック数上昇が伸び悩んで、買い替え需要が盛り上がらない。
> ２）さらに加えて、MacOS X という今年の目玉になるはずの商品が
> でなかった。

あなたの分析ではクロック数が伸びれば買い換え需要が伸びて売れただろう
って読めますけどそうでしょうか？DOS/VマシーンならともかくMac買う人で
クロック数気にして買う人ってどれだけいるの？iMacなんかを買いような
人たちってクロック数云々よりもデザインであるとか斬新性であるとか
そういったものを気に入って買う人が多いんじゃないの？

そういう意味では斬新なデザインのものが出たにもかかわらず
立ち上がりが悪いっていうのは根本的な問題が他にあるということ
ではないですか？

２）はソフトウェアの問題ですから同意します。

わたしが言ってるのは入れ物の性能の問題じゃなくて中身の問題だろうって
いうことです。

> の、２点に尽きるでしょう。ソフトの数は、去年よりむしろ増えているので、
> 関係ないですよ。っていうか、そんなものを持ち出すのは、東洋ウミガメぐ
> らいと思うんだけどねえ。

累積で増えるのはあたりまえ。Winに比べて圧倒的に少ないのは火を見るより明らか。

[高木]

> どう状況が違うんでしょうか？Macの開発系雑誌って見当たらないんですけど。
> インターネットが普及したから雑誌はいらなくなったっていうことですか？
>
> じゃあなんでWindowsの開発系雑誌はたくさん出てるんでしょうね。
>
逆にＷｉｎｄｏｗｓはそれだけハードが複雑すぎて、情報の整理ができないと解釈し
ています。
マックのハードは基本は３つしかないので簡単ですね。

>
> ２）はソフトウェアの問題ですから同意します。
>
> わたしが言ってるのは入れ物の性能の問題じゃなくて中身の問題だろうって
> いうことです。
>
>> の、２点に尽きるでしょう。ソフトの数は、去年よりむしろ増えているので、
>> 関係ないですよ。っていうか、そんなものを持ち出すのは、東洋ウミガメぐ
>> らいと思うんだけどねえ。
>
> 累積で増えるのはあたりまえ。Winに比べて圧倒的に少ないのは火を見るより明らか。

圧倒的に少ないというより、マックはいろりろなものに使用しないで、ある専用の処
理機械として使う人が多いので、逆にそんなにソフトは必要無いかも知れません。
（写真加工専用など）
それより、やはりソフトの質が問題でしょう。Ｍ社のワープロソフトはいまだに英語
版のほうが優れています。

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8racve$sm1$1...@news01ch.so-net.ne.jp> の
記事において 2000年10月03日(火) 01時25分57秒頃、
Shidori Tomokiさんは書きました。

>> MacOSがPascalベースならDelphiを移植してもいけるんじゃないかなぁって
>> 思うんですけどね。
>
>そうかなあ、、、Delphi はマニアにしかうけんからなあ、、、

そ、そうだったんですか(^^;;;;

どっちにせよOSは関係無いだろうなあ。Kylixとやらも出るそうだし。
DelphiでOS作るってなら、Delphiのメリットがまた新たに一つ活きる
だろうとは思うけど。

[GON]

"高木" <st2...@m1.interq.or.jp> wrote in message news:B5FF7D41.427A%st2...@m1.interq.or.jp...

> > どう状況が違うんでしょうか？Macの開発系雑誌って見当たらないんですけど。
> > インターネットが普及したから雑誌はいらなくなったっていうことですか？
> >
> > じゃあなんでWindowsの開発系雑誌はたくさん出てるんでしょうね。
> >
> 逆にＷｉｎｄｏｗｓはそれだけハードが複雑すぎて、情報の整理ができないと解釈し
> ています。
> マックのハードは基本は３つしかないので簡単ですね。

あのぉ、ハードじゃなくてソフトなんですけど。Windowsプログラミングに関する書籍や
開発ツールに関する書籍は山のように出てます。それだけ需要があるってことでしょう。
それに比べるとMacの場合プログラミングに関する書籍は圧倒的に少ないです。

少ない情報の中から開発するってのは最初の段階からハードルが高くなってますから
ソフトウェアがWinに比べて多くないのも納得できます。

> 圧倒的に少ないというより、マックはいろりろなものに使用しないで、ある専用の処
> 理機械として使う人が多いので、逆にそんなにソフトは必要無いかも知れません。
> （写真加工専用など）

MacがいまだにDTPに強いことは認めます。より少数の会社がクオリティの高いアプリを
出していることがMacの売上を支えているだろうことも理解できます。

ただそういった有名な少数のアプリを除いては一般的なアプリに対してMac版がないって
いうことは良くある話です。ビジネスの分野では様々なデータベースが発刊されてますが
大抵はWindows版のみでMac版はほとんどありません。

前の会社でデータベース作ってましたがMac版作る経費とその売上を勘案したらあまり儲からない
という結論に達したんで発刊しませんでした。とにかくはける数が少なすぎます。

[TKH]

"高木" <st2...@m1.interq.or.jp> wrote in message news:B5FF7D41.427A%st2...@m1.interq.or.jp...

> マックのハードは基本は３つしかないので簡単ですね。

つまり、こうですね。
1.PowerPC-CPU
2.DOS/Vパーツ
3.Microsoftの方針

TKH

[suzu...@mahoroba.ne.jp]

<B5FF7D41.427A%st2...@m1.interq.or.jp>の記事において
st2...@m1.interq.or.jpさんは書きました。

>逆にＷｉｎｄｏｗｓはそれだけハードが複雑すぎて、情報の整理ができないと解釈し
>ています。
>マックのハードは基本は３つしかないので簡単ですね。

マッキントッシュって３つしかないんですか？
# 現行モデルの話なのかな？(現行のが３つかは知らないけど)
以前、各モデルのアーキテクチャのブロック図(っていうのかな？どういう
機能のところがどんなバスで繋がってるとか大雑把に書いてあるやつ)を見たら
物によってかなり違うように見えるのですが。
# PowerMac以前だけで３つくらい軽く超えてた気が…

>圧倒的に少ないというより、マックはいろりろなものに使用しないで、ある専用の処
>理機械として使う人が多いので、逆にそんなにソフトは必要無いかも知れません。
>（写真加工専用など）

おそらく開発系の書籍の数が少ない理由も特定用途の道具として使うだけの
人が多いせいではないのでは？と思うのですが。

-----
Koji Suzumura

[BABA Motoharu]

馬場＠ユニコーンです。

Nakamura Akifumi wrote:
>
> 中村暁史っす。
>
> fj.soc.economy,japan.jiji,fj.comp.misc の <8racve$sm1$1...@news01ch.so-net.ne.jp> の
> 記事において 2000年10月03日(火) 01時25分57秒頃、
> Shidori Tomokiさんは書きました。
>
> >> MacOSがPascalベースならDelphiを移植してもいけるんじゃないかなぁって
> >> 思うんですけどね。
> >
> >そうかなあ、、、Delphi はマニアにしかうけんからなあ、、、
>
> そ、そうだったんですか(^^;;;;

ぎくぎく(^^;;;

> どっちにせよOSは関係無いだろうなあ。Kylixとやらも出るそうだし。
> DelphiでOS作るってなら、Delphiのメリットがまた新たに一つ活きる
> だろうとは思うけど。

http://community.borland.com/
で「Linuxの次にDelphi/C++Builderを移植して欲しいOSはどれ?」
という投票をやってます。
ユーザ登録をしないと投票できないのが面倒ですが。。。

＃昨日(10/2)の時点ではBeOSとMacOSXが他を大きく引き離した一騎討ち
＃状態で、数票差でMacOSXが負けてた。
＃NeXTびいきでDelphiびいきの私は迷わずMacOSXに投票:-)

--
株式会社ユニコーン 情報システム事業部
馬場 基晴
mailto: ba...@atlantis21.co.jp

[Mr.Epi]

GON wrote in message <8rbcbq$23j$1...@nw041.infoweb.ne.jp>...

　　　　　　　　　　　　　　　　　　　DOS/VマシーンならともかくMac買う人で
>クロック数気にして買う人ってどれだけいるの？iMacなんかを買いような
>人たちってクロック数云々よりもデザインであるとか斬新性であるとか
>そういったものを気に入って買う人が多いんじゃないの？

　ｉMacを「デザイン」「斬新性」で買った方は、CPUの違いを無視して、Windows
マシーンのクロック数を見比べて、買い替えをしない。
　そして、ｉＭａｃよりＧ４の方が良い。
＃ましてや、iMacよりキューブ。

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
e...@d9.dion.ne.jp
val...@pdx.ne.jp
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

　

[Kimura Katsuhiko]

In article <8r4tqo$i5s$3...@nwms2.odn.ne.jp>, ia...@mutt.freemail.ne.jp says...

>ＩＮＯのＸｔｒｅｍｅ Ｄａｙ ２０００年９月２９日付によると、Ａｐｐｌｅ Ｃ
>ｏｍｐｕｔｅｒ ＩＮＣ （ＡＡＰＬ）がなんと木曜の引けと比べると５１．９９％
>の大暴落である。

インテルショックとユーロ安、原油高による地合い悪化の中で、市場が業績の
下方修正に過敏に反応したのでしょう。むしろ、来年発売予定の新OS(MacOS X)
発売に対する買い控えによる一時的な業績悪化とも考えられるので、長期的には
現在が買い場とも考えられますね。投資というのは数十年という長期的観点から
見るべきであって、決して目先の株価で見てはいけません。

--
kim

[GENBU]

ちょっと話題がそれますが…
去年これからの時代インターネットや電子メールは日常生活に必要なものに
なっていくと思い電化製品を買う感覚でパソコンを買いました。
買ったのはウィンドウズ９８搭載の初心者向けパソコンです。

ところで、私がマッキントッシュの名前を知ったのは
パソコンが、まだマイコンと呼ばれていた１０年以上前の事です。
その頃、電気店のパンフレットや雑誌などの広告でよくマッキントッシュの
虹色りんごを見かけた覚えがあります。
当時は、マッキントッシュ社のアップルコンピューターだと思っていました。
また、コンピューターは大変高価な品物で、使うにしても独学で
それなりの知識を学ぶ必要があると思っていました。
まさか、自分が電化製品のような感覚でコンピューターを買うようになるなんて
想像さえもしませんでした。
こんなパソコン音痴な私でも以前から知っていたマッキントッシュ。
なぜ普及しなかったのでしょう？なんだかとても不思議です。

--
********************
玄◆GENBU◆武
ge...@fides.dti.ne.jp
▼▼▼▼▼▼▼▼▼▼

[Suzuki K.]

"GENBU" <ge...@fides.dti.ne.jp> wrote in message
news:K%mC5.2251$X3.2...@newsall.dti.ne.jp...
> ところで、私がマッキントッシュの名前を知ったのは
> パソコンが、まだマイコンと呼ばれていた１０年以上前の事です。

もう20年近く前の話です・・・
# 1990年頃にはもうマイコンなんて言葉は廃れてたような・・・

> こんなパソコン音痴な私でも以前から知っていたマッキントッシュ。
> なぜ普及しなかったのでしょう？なんだかとても不思議です。

激しく高かったからです。
# HDDとかメモリとか考えると、高くて当然だけど
# それでも頭抜けて高かった。

あと、日本語ワープロ用途では、GUIなコンピュータは
弱かったと言うのもあると思います。

すずき。

[K.Nakagawa]

> MacOSがPascalベースならDelphiを移植してもいけるんじゃないかなぁって
> 思うんですけどね。

OSが何言語を使って開発しているか、と、
そのOS上で動作するアプリを何言語を使って開発するといいかは
別問題だと思うんですけどね。。。

--
Ｋ仲川 <mailto:nk...@sikasenbey.or.jp> (個人)
<mailto:knak...@anet.ne.jp> (公式)
<http://www.vector.co.jp/authors/VA007446/> (Web)

[K.Nakagawa]

》> どう状況が違うんでしょうか？Macの開発系雑誌って見当たらないんですけど。

》> インターネットが普及したから雑誌はいらなくなったっていうことですか？
》>
》> じゃあなんでWindowsの開発系雑誌はたくさん出てるんでしょうね。
》>
》逆にＷｉｎｄｏｗｓはそれだけハードが複雑すぎて、情報の整理ができないと解釈し
》ています。
》マックのハードは基本は３つしかないので簡単ですね。

ハードの問題じゃないと思うんですが。。。

#「複雑すぎて、情報の整理ができない」のは事実ですが。
#おかげで、たまにWindowsプログラムでお手あげ状態になったものの
#応援の仕事があったりするので私みたいなのでも飢え死にしなくてすむ（爆）。

[K.Nakagawa]

》どう状況が違うんでしょうか？Macの開発系雑誌って見当たらないんですけど。
》インターネットが普及したから雑誌はいらなくなったっていうことですか？

作っても売れないからです（爆）。
廃刊した１つについては事情を当事者から聞いているけど、
さすがに公開の場では書けないからパス。

》じゃあなんでWindowsの開発系雑誌はたくさん出てるんでしょうね。

買う人がいっぱいいるからです。

》> > MacOSがPascalベースならDelphiを移植してもいけるんじゃないかなぁって

》> > 思うんですけどね。
》>
》> そうかなあ、、、Delphi はマニアにしかうけんからなあ、、、
》
》開発ツールとしてREALbasicを例に出しといてDelphiはマニアうけって
》いうのもどうでしょうか？RAD開発ツールとしてはREALbasicと同じような
》ものだと思いますけど。

違いますね（きっぱり）。
Delphiのほうがややこしいです。

[K.Nakagawa]

》少ない情報の中から開発するってのは最初の段階からハードルが高くなってますから
》ソフトウェアがWinに比べて多くないのも納得できます。

それは某ゲームマシン（複数あり）についても言えるんですが。。。
しかし、それでもどんどんソフトを作ろうとするところは出てくる。

それは単に

》Mac版作る経費とその売上を勘案したらあまり儲からない
》という結論に達したんで発刊しませんでした。とにかくはける数が少なすぎます

という問題でしょう。
かける手間ヒマと、それに対するペイを考えると
あまり誰も手を出さない。

#おかげで私みたいなのでも飢え死にしなくて、、、、
#こればっかりだな（笑）

[teruo Takeuchi]

2000/10/04 T.Takeuchi
Ａｐｐｌｅ株大暴落。（その低いシェア） news:fj.comp.misc
------------------------------------------------------------
（ GENBU ）さん news:K%mC5.2251$X3.2...@newsall.dti.ne.jp

> ちょっと話題がそれますが…（略）

> ところで、私がマッキントッシュの名前を知ったのはパソコンが、
> まだマイコンと呼ばれていた１０年以上前の事です。（略）

> パソコン音痴な私でも以前から知っていたマッキントッシュ。
> なぜ普及しなかったのでしょう？なんだかとても不思議です。

もう１０年近く前になるのでしょうか、それまで高額だったＭＡＣ
が少し安くなりはじめたころの「ＭＡＣ－Ｓｉ」と言う機種を買っ
て使ってみたことが有ります。

キーボード上に有るスタートボタンを押すだけで、「ポワーン」と
言う音とともに立ち上がる様子は、それまでの「ＮＥＣ９８」には
無かった先進的な機能で、私も当初は感動ものでした。

しかしこのパソコンを、遊びで使っている分には何も問題は無かっ
たのですが、いざ何か仕事に使おうとするとその「ＯＳの不安定さ」
のためか、極端な時には１時間に１回ぐらいの頻度でハングアップ
することに閉口してしまいました。

これでは、貴重なデーターを扱う仕事用には向きませんよね。そう
言うことも有って、私の場合は仕事に使うパソコンは結局のところ
「ＤＯＳ／Ｖ機」＋「ＭＳ－ＤＯＳ」の組み合わせになってしまっ
たと言うわけです。

でもなぜだかその「ＳＩ機」は、未だに捨てるのがもったいなくて、
今もホコリをかぶったまま、静かに部屋に残っています。（笑）

最近は「スティーブ・ジョブス・ＣＥＯ」の頑張りも有ってなのか、
ＣＳＴＶなどで見る限りにおいては、「ＯＳ－１０」や「Ｇ４」な
どに興味をそそられる部分は多いのですが、何分そ過去の悪い印象
が心の中に染み付いていて（苦笑）、新しいＭＡＣを買う勇気が起
こってこないのですね。

元記事では「Ａｐｐｌｅ株大暴落」に付いての話題でしたが、新聞
に出ていた週刊誌の広告には、「アップル新機種に、欠陥続出」な
どと出ていました。これは本当の話なのでしょうかね。？

＃ news:japan.comp.mac も、加えました。

[仙田和人]

"teruo Takeuchi" <take...@mx2.wt.tiki.ne.jp> wrote in message
news:39DA66E1...@mx2.wt.tiki.ne.jp...

> しかしこのパソコンを、遊びで使っている分には何も問題は無かっ
> たのですが、いざ何か仕事に使おうとするとその「ＯＳの不安定さ」
> のためか、極端な時には１時間に１回ぐらいの頻度でハングアップ
> することに閉口してしまいました。

Mac OS (昔は漢字Talk)が不安定だったという話は会社でもよく聞き
ました。昼食から帰ったらフリーズしていたとか。でも、私が個人
的に買って使っていたClassic IIは大変安定して動いていました。

悪いうわさが広まったのはなぜでしょうか?

仙田和人 JCE0...@nifty.ne.jp

[GON]

わぁ、Ｋ仲川さんのコメントだ！（＾＾）

Ｋ仲川さんもニュースグループ見てたんですね。

"K.Nakagawa" <nk...@sikasenbey.or.jp> wrote in message news:39DA5058...@sikasenbey.or.jp...

> それは単に
>
> 》Mac版作る経費とその売上を勘案したらあまり儲からない
> 》という結論に達したんで発刊しませんでした。とにかくはける数が少なすぎます
>
> という問題でしょう。

そういう問題につきますかね。

＃　いやぁ、しかしＫ仲川さんがこのニュースグループを見てるとは思わなかったなぁ。
＃　ちょっとビックリ

[GON]

"K.Nakagawa" <nk...@sikasenbey.or.jp> wrote in message news:39DA4EA4...@sikasenbey.or.jp...

> 》開発ツールとしてREALbasicを例に出しといてDelphiはマニアうけって
> 》いうのもどうでしょうか？RAD開発ツールとしてはREALbasicと同じような
> 》ものだと思いますけど。
>
> 違いますね（きっぱり）。
> Delphiのほうがややこしいです。

それは単に言語使用に慣れてないだけでは？

Delphiが難しいと言う人の大半はPascal(正確にはObject Pascal)の言語仕様に
慣れてないだけで使ってみると結構簡単に開発できることに驚く人は多いですよ。

特にＣ＋＋に慣れてる人がObject Pascalを使うと、わざわざ変数宣言を全部
先にやらなくてはならないのが面倒とかＣなら{～};で済むのがbegin～end;
を一々書かなくてはならないのが面倒とか、単に仕様の違いに由来する部分で
文句言う人が多いですね。

むしろそれがメリットとなってコンパイルはＣ＋＋に比べれば異常に速いんですけどね。

[高木]

>
> しかしこのパソコンを、遊びで使っている分には何も問題は無かっ
> たのですが、いざ何か仕事に使おうとするとその「ＯＳの不安定さ」
> のためか、極端な時には１時間に１回ぐらいの頻度でハングアップ
> することに閉口してしまいました。

そんなに安定しないのでしょうか？
漢字Ｔａｌｋになってからは安定していると思うんですが。
拡張機能の使い方の解らない方が多かったのでこのような結果が起きていると
推定します。

[高木]

> 悪いうわさが広まったのはなぜでしょうか?
おそらく拡張機能のファイルに関してあまりアップルは情報を公開しなかったからで
はないでしょうか？
そのため、好きなものを詰め込んで大騒ぎになる結果が良くないうわさとして残った
んではないでしょうか？

＃Ｗｉｎｄｏｅｓ９Ｘの安定性は評価としてどうなんでしょうか？

[UCHIDA Toshiaki]

"GON" <opens...@hotmail.com> wrote in message
news:8re8pa$n76$1...@nw041.infoweb.ne.jp...

> Ｃなら{～};で済むのがbegin～end;を一々書かなくてはならないのが
> 面倒とか

Ruby でも同じ文句をいっちゃいます:-)

> むしろそれがメリットとなってコンパイルはＣ＋＋に比べれば
> 異常に速いんですけどね。

ん? compile が速いのは Turbo シリーズ以来の Borland の伝統なんですけど、こ
れって Pascal だからというよりも optimize が甘いからなんじゃないかなぁと思っ
たりする…。

#あ、そういえば、最近 compile が必要な言語って使っていないや:-)
--
内田 俊明 (UCHIDA,Toshiaki)

[GON]

"UCHIDA Toshiaki" <uch...@hmx12.com> wrote in message news:ENyC5.6269$TI5.2...@news1.dion.ne.jp...

> > むしろそれがメリットとなってコンパイルはＣ＋＋に比べれば
> > 異常に速いんですけどね。
>
> ん? compile が速いのは Turbo シリーズ以来の Borland の伝統なんですけど、こ
> れって Pascal だからというよりも optimize が甘いからなんじゃないかなぁと思っ
> たりする…。

否、それは違います。

手続きや関数や変数を宣言する場所がＣ＋＋と違ってObjectPascalの場合は決まっていて
その分オーバーヘッドが少ないから単純に速いんです。Ｃ＋＋の場合、例えば変数なら
使う直前に宣言してもＯＫでしょ。それがPascalじゃそうはいかない。

だから気楽に使いたい時に変数宣言して使えないデメリットはあるけど、その分コンパイルが
速くなっているんだから相当なメリットになってると思いますよ。

＃　正直、コンパイルが速いというのはDelphiの最大の特徴だと思ってます。
＃　ストレスがほとんど感じられません。

[Yukio Obuchi]

ぶちを＠そにーです。

"GON" <opens...@hotmail.com> writes:
> 手続きや関数や変数を宣言する場所がＣ＋＋と違ってObjectPascalの場合は決まっていて
> その分オーバーヘッドが少ないから単純に速いんです。Ｃ＋＋の場合、例えば変数なら
> 使う直前に宣言してもＯＫでしょ。それがPascalじゃそうはいかない。

イマドキのコンパイラって、そんなことでコンパイル速度が極端に変わるも
のでしょうか？単純に疑問です。識者の意見を聞きたいです。

# これを見て、8ビットマシンのBASICで、処理速度を稼ぐために一生懸命マル
# チステートメント＆省略形を使いまくって書いてたのを連想してしまいまし
# た。

--
Yukio Obuchi

[Yukihiro Matsumoto]

まつもと ゆきひろです

"GON" <opens...@hotmail.com> writes:

|"UCHIDA Toshiaki" <uch...@hmx12.com> wrote in message news:ENyC5.6269$TI5.2...@news1.dion.ne.jp...
|> > むしろそれがメリットとなってコンパイルはＣ＋＋に比べれば
|> > 異常に速いんですけどね。
|>
|> ん? compile が速いのは Turbo シリーズ以来の Borland の伝統なんですけど、こ
|> れって Pascal だからというよりも optimize が甘いからなんじゃないかなぁと思っ
|> たりする…。
|
|否、それは違います。
|
|手続きや関数や変数を宣言する場所がＣ＋＋と違ってObjectPascalの場合は決まっていて
|その分オーバーヘッドが少ないから単純に速いんです。Ｃ＋＋の場合、例えば変数なら
|使う直前に宣言してもＯＫでしょ。それがPascalじゃそうはいかない。

証拠がありますか？ 状況証拠でも。「C++の方が文法がめちゃ複雑
だから」というのはまだ納得できますが、変数・関数の宣言位置程
度でそんなにコンパイル速度が変わるとはとても思えません。

まつもと ゆきひろ /:|)

[UCHIDA Toshiaki]

Turbo Pascal の compile が速かった理由は Toda さんが
news:8remg3$jg9$1...@newssv.cc.niigata-u.ac.jp で述べてくださっているので、省
略。

"GON" <opens...@hotmail.com> wrote in message

news:8reg4o$obj$1...@nw041.infoweb.ne.jp...

> 手続きや関数や変数を宣言する場所がＣ＋＋と違ってObjectPascalの
> 場合は決まっていてその分オーバーヘッドが少ないから単純に速いんです。

確かにそういう言語仕様のほうが compile が速くなることは確かでしょう。

でも、これはせいぜい compile 時の 1pass の高速化に多少寄与するだけで、以後の
pass にはほとんど影響を与えないはずです。で、compile にかかる時間の多くはそ
の高速化されない pass でかかっているはずです。

> ＃　正直、コンパイルが速いというのはDelphiの最大の特徴だと思ってます。
> ＃　ストレスがほとんど感じられません。

ならば、compile の必要のない言語を使うほうがもっと幸せになれますよ。
--
内田 俊明 (UCHIDA,Toshiaki)

[K.Nakagawa]

> > 》開発ツールとしてREALbasicを例に出しといてDelphiはマニアうけって
> > 》いうのもどうでしょうか？RAD開発ツールとしてはREALbasicと同じような
> > 》ものだと思いますけど。
> >
> > 違いますね（きっぱり）。
> > Delphiのほうがややこしいです。
>
> それは単に言語使用に慣れてないだけでは？
>
> Delphiが難しいと言う人の大半はPascal(正確にはObject Pascal)の言語仕様に
> 慣れてないだけで使ってみると結構簡単に開発できることに驚く人は多いですよ。

いや。そういうところじゃなくて、ツールとしての使いごこちの話です。
いちおう、これでも昔、I/Oにパスカルのプログラムを投稿して
採用されたことはあります。

REALbasicに慣れると、Visual Basicですら難しく感じますね（爆）。
VBがVer.2の頃の易しさといえば、わかってもらえるでしょうか。

[Yoshitaka Ikeda]

"高木" <st2...@m1.interq.or.jp> wrote in message

news:B600D6FC.4454%st2...@m1.interq.or.jp...
> ＃Ｗｉｎｄｏｅｓ９Ｘの安定性は評価としてどうなんでしょうか？

Windows95以降にPCを買ったユーザーが多いから「こんなもん」という
印象が蔓延しているんでは無いでしょうか?

今日も,Windows95+MS-IME98+InternetExplorer5.5+outlookExpress5.5で
メールを受信しながらWebPageを印刷しようとしたらInternetExplorerが
落ちました.純正アプリだけでも,安定性を維持できないんですかね.
(プリンタドライバが原因だったとして,それでアプリが落ちるのはどうかと)
しかも,InternetExplorerはシェルですからね.(もちろん,標準シェルでも
使えるんですが)これだけシェルの落ちやすいOSもなかなか無いなと思います.
しかもシェルが落ちたら事実上再起動必要ですし.

その点,シェルは落ちるがOSまで落ちないWindows2000はかなりマシですね.
でも、NT系OSはNT3.5が一番よかったような気が...

あと、Win9x系の弱点としてリソースリークとそれが原因である不安定さ
ですね.9x系を信用できない一番の点だと思います.メモリは大量にあるのに,
「メモリが足りません」とか「リソースが不足しています」なんてダイアログ
が出るたびに血圧が上がってしまいます.

正直なところ,きちんと整備したMacOS8.5とWin9xならMacOSの方が安定してるかな.
Windows2000とならWindows2000の方が再起動に陥る確率は低いですが.

#でも,Windows2000も固まって強制的に電源を落としたことは片手じゃ足りないくら
い
#ありますが.

--
(ε)(ε) 池田　尚隆@Mobile Env
レ ik...@4bn.ne.jp
___ YonbetsuNetzwerk

[Kimura Katsuhiko]

In article <8ra9ug$j7b$1...@nw042.infoweb.ne.jp>, opens...@hotmail.com says...
>
>MacOSがPascalベースならDelphiを移植してもいけるんじゃないかなぁって
>思うんですけどね。

ずいぶん昔（多分１０年ぐらい前）に、Cになったって聞いていますが。＞MacOS
プロトタイプがPascalだったので、インターフェイスが残っているだけでしょう。

--
kim

[Nakamura Akifumi]

中村暁史っす。

少なくともVC++だとVSS(CVSの仲間?)を使えば使うほどcompile遅くて萎えてくるけど、
delphiなら平気。

fj.soc.economy,japan.jiji,fj.comp.misc の <87bsx1q...@ev.zetabits.com> の
記事において 2000年10月04日(水) 16時50分30秒頃、
Yukihiro Matsumoto <ma...@zetabits.com>さんは書きました。

>証拠がありますか？ 状況証拠でも。「C++の方が文法がめちゃ複雑
>だから」というのはまだ納得できますが、変数・関数の宣言位置程
>度でそんなにコンパイル速度が変わるとはとても思えません。

「証拠」は…少なくとも俺は見た事はないです(^^;

Turboの伝統の寄与度については、
C++BuilderとDelphiのcomple速度を比べる(ってナンだ?)と、
状況証拠のカケラくらいにはなるかもです。
TurboCもそれなりに速かったですよね。
Mac用TurobPascalも速かったそうです。

Delphiのcompileが速い理由の一つは、templeteが無いから、じゃないかな。

あと、コンパイル済みの中間ファイル(Cだと.oとか.objとか。
delphiだと.dcuとか)の中に、どれだけその後のcompileの速度を
助けるのに役立つ情報が書かれているか？とかも、あるかも。
あ、でも全部compileし直しても充分delphiは速いしなあ(^^;

[BABA Motoharu]

馬場＠ユニコーンです。

GON wrote:
>
> "UCHIDA Toshiaki" <uch...@hmx12.com> wrote in message news:ENyC5.6269$TI5.2...@news1.dion.ne.jp...
> > > むしろそれがメリットとなってコンパイルはＣ＋＋に比べれば
> > > 異常に速いんですけどね。
> >
> > ん? compile が速いのは Turbo シリーズ以来の Borland の伝統なんですけど、こ
> > れって Pascal だからというよりも optimize が甘いからなんじゃないかなぁと思っ
> > たりする…。
>
> 否、それは違います。

否、違いません。

オンラインヘルプにも
「Delphi の Object Pascal コンパイラにより実行されるすべての最適化は，
プログラムの意味を変更しないことが保証されています。言い換えると，
Delphi ではプログラマの特別な注意を必要とするような「安全でない」
最適化は行われません。」
とわざわざ明記しているくらいですから。(Delphi2, 3, 4で確認、多分5でも同じ)
＃OptimizeのコンパイルスイッチがOnとOffしかないというあたりでも最適化の
＃レベルは知れてると思うんだが...

基底クラスであるTObjectクラスのほとんどのメソッドはアセンブラで書かれてるし。
＃asm ... end;だらけのソースを見たときには「なんじゃこりゃぁ!?」と思った。

>
> 手続きや関数や変数を宣言する場所がＣ＋＋と違ってObjectPascalの場合は決まっていて
> その分オーバーヘッドが少ないから単純に速いんです。Ｃ＋＋の場合、例えば変数なら
> 使う直前に宣言してもＯＫでしょ。それがPascalじゃそうはいかない。
>
> だから気楽に使いたい時に変数宣言して使えないデメリットはあるけど、その分コンパイルが
> 速くなっているんだから相当なメリットになってると思いますよ。

どこにでも宣言できますが...
いつの時代のObjectPascalの話なんでしょう?

[GON]

"UCHIDA Toshiaki" <uch...@hmx12.com> wrote in message news:O6CC5.6289$TI5.2...@news1.dion.ne.jp...

> Turbo Pascal の compile が速かった理由は Toda さんが
> news:8remg3$jg9$1...@newssv.cc.niigata-u.ac.jp で述べてくださっているので、省
> 略。

> "GON" <opens...@hotmail.com> wrote in message

> news:8reg4o$obj$1...@nw041.infoweb.ne.jp...
>
> > 手続きや関数や変数を宣言する場所がＣ＋＋と違ってObjectPascalの
> > 場合は決まっていてその分オーバーヘッドが少ないから単純に速いんです。
>
> 確かにそういう言語仕様のほうが compile が速くなることは確かでしょう。
>
> でも、これはせいぜい compile 時の 1pass の高速化に多少寄与するだけで、以後の
> pass にはほとんど影響を与えないはずです。で、compile にかかる時間の多くはそ
> の高速化されない pass でかかっているはずです。

C++BuilderもDelphiと同じVCLを使ってますがやはりコンパイルはDelphiに比べてのろいです。
これは単純に言語仕様によるものと推察されます。結局、一言で言えばDelphiのほうが
コンパイル時のオーバーヘッドが少ないってことに帰着するんじゃないでしょうか？

そういう意味では、コンパイラーにとってみればObjectPascalはコンパイルしやすい
きれいな言語であって、C++はあっち行ったりこっち行ったりと手間の掛かるきたない
言語なのかも。(←「きたない」なんて刺激的なワードをあえて使ってしまいました(爆))

> > ＃　正直、コンパイルが速いというのはDelphiの最大の特徴だと思ってます。
> > ＃　ストレスがほとんど感じられません。
>
> ならば、compile の必要のない言語を使うほうがもっと幸せになれますよ。

商用パッケージを作ってるものにとってインタープリタで出来ることなんてたかが知れてます。
やはり直WinAPIやメモリにアクセスできないことには商用に耐えうるきびきびしたアプリケーションは
作れませんよね。

[GON]

"K.Nakagawa" <nk...@sikasenbey.or.jp> wrote in message news:39DB0685...@sikasenbey.or.jp...

> > Delphiが難しいと言う人の大半はPascal(正確にはObject Pascal)の言語仕様に
> > 慣れてないだけで使ってみると結構簡単に開発できることに驚く人は多いですよ。
>
> いや。そういうところじゃなくて、ツールとしての使いごこちの話です。

ツールとしての使いごごちだったらDelphiは最高じゃないっすか！

初心者ならコンポーネントをフォームにペタペタ貼ってプロバティを
設定するだけでもそこそこ動くアプリはできちゃいますよ。

そのコンポーネントなんかもVCLのクラス継承して結構簡単に
自分仕様のものを作れちゃいますしね。これはかなり便利です。

また、コンポーネント自体がフリーでもシェアでもたくさん出回って
ますからかなり便利です。大抵のしたいことはだれかが既にコンポーネント
とかクラスを作って公開してますからそれを再利用すれば良い。

> いちおう、これでも昔、I/Oにパスカルのプログラムを投稿して
> 採用されたことはあります。

そのPascalってDelphiでのPascalですか？

それにしてもI/O、懐かしいですね。いつの時代のI/Oでしょうか？
I/O全盛期ってことではありませんよね？(笑)

> REALbasicに慣れると、Visual Basicですら難しく感じますね（爆）。
> VBがVer.2の頃の易しさといえば、わかってもらえるでしょうか。

REALbasicってオブジェクト指向プログラミングって可能なんでしょうか？
メーリングリストに入ってながらあまり見てないもので・・・

[GON]

"BABA Motoharu" <ba...@atlantis21.co.jp> wrote in message news:39DB4E9C...@atlantis21.co.jp...

> 馬場＠ユニコーンです。
>
> GON wrote:
> >
> > "UCHIDA Toshiaki" <uch...@hmx12.com> wrote in message news:ENyC5.6269$TI5.2...@news1.dion.ne.jp...
> > > > むしろそれがメリットとなってコンパイルはＣ＋＋に比べれば
> > > > 異常に速いんですけどね。
> > >
> > > ん? compile が速いのは Turbo シリーズ以来の Borland の伝統なんですけど、こ
> > > れって Pascal だからというよりも optimize が甘いからなんじゃないかなぁと思っ
> > > たりする…。
> >
> > 否、それは違います。
>
> 否、違いません。
>
> オンラインヘルプにも
> 「Delphi の Object Pascal コンパイラにより実行されるすべての最適化は，
> プログラムの意味を変更しないことが保証されています。言い換えると，
> Delphi ではプログラマの特別な注意を必要とするような「安全でない」
> 最適化は行われません。」
> とわざわざ明記しているくらいですから。(Delphi2, 3, 4で確認、多分5でも同じ)
> ＃OptimizeのコンパイルスイッチがOnとOffしかないというあたりでも最適化の
> ＃レベルは知れてると思うんだが...
>
> 基底クラスであるTObjectクラスのほとんどのメソッドはアセンブラで書かれてるし。
> ＃asm ... end;だらけのソースを見たときには「なんじゃこりゃぁ!?」と思った。

じゃあ何故同じVCLを使っているC++BuilderがDelphiに比べてコンパイルが遅いんでしょうか？
言語仕様としか考えようがないんですけど。

> > 手続きや関数や変数を宣言する場所がＣ＋＋と違ってObjectPascalの場合は決まっていて
> > その分オーバーヘッドが少ないから単純に速いんです。Ｃ＋＋の場合、例えば変数なら
> > 使う直前に宣言してもＯＫでしょ。それがPascalじゃそうはいかない。
> >
> > だから気楽に使いたい時に変数宣言して使えないデメリットはあるけど、その分コンパイルが
> > 速くなっているんだから相当なメリットになってると思いますよ。
>
> どこにでも宣言できますが...
> いつの時代のObjectPascalの話なんでしょう?

言ってる意味が伝わってないかもしれませんね。

C++で例えばiを変数として使いたいと思ったら使いたいと思った直前に
int i;のように宣言しても良いのですが、Pascalの場合は手続きや関数の
begin～end;の中では宣言できません。このときのbegin前で宣言するか
その手続きや関数の外で宣言するかしか方法がありません。

つまり、C++の場合はその関数だけで使われる変数はその関数の中を見ていかないと
わからないのに対してDelphiの場合は宣言されている場所がbeginの前と決まってるから
そこを見るだけでＯＫなわけでその分確実にオーバーヘッドが減ってるわけです。

そういう意味なんですが・・・

[Akinori MUSHA]

At Thu, 5 Oct 2000 02:49:31 +0900,

GON <opens...@hotmail.com> wrote:
> > ならば、compile の必要のない言語を使うほうがもっと幸せになれますよ。
>
> 商用パッケージを作ってるものにとってインタープリタで出来ることなんてたかが知れてます。
> やはり直WinAPIやメモリにアクセスできないことには商用に耐えうるきびきびしたアプリケーションは
> 作れませんよね。

　はあ？？まったくさっきから何をとんちんかんなことばかり言ってるん
でしょうか。

　MS-Excel や MS-Access の VBA はコンパイルが不要ですが、星の数ほど
商用アプリケーションが作られていますよ？それらの多くは、「きびきび
した」速度が要求される業務用データベースとか会計ソフトとか数値解析
システムに使われている。

　VBScript や JScript や Ruby や Perl や Ruby や Python で Windows
API にアクセスできることも知らないんですか？「Ruby を 256 倍使う
ための本 邪道編」を読んでないですか？（あまりに切ないのでせめて
Ruby の宣伝）

　インタープリタ言語で、速度を要求する部分や低レベル処理のために
C 等で書いたモジュールを組み込んだりするのも今どき当たり前。

　経験不足と知識不足を露呈する前にちったあ調べておくれよ。

--
/
/__ __
/ ) ) ) ) /
Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org

"We're only at home when we're on the run, on the wing, on the fly"

[teruo Takeuchi]

2000/10/05 T.Takeuchi
ＯＳの安定性。（Ａｐｐｌｅ株） news:fj.comp.misc
------------------------------------------------------------
> > ＃Ｗｉｎｄｏｅｓ９Ｘの安定性は評価としてどうなんでしょう

「ＭＳ－ＷＩＮ」は、Ｖ２．０のころから一応知ってはいますが、
９５や９８より、明らかにＶ３．１の方が安定していたと思います。

（ Yoshitaka Ikeda ）さん news:8rfbj3$aiv$1...@nn-tk104.ocn.ad.jp

> Windows95 以降にPCを買ったユーザーが多いから「こんなもん」
> という印象が

でもですよ。今後「ＬＩＮＵＸ」が多く普及し始めれば、たかが
「こんなもん」と言ってるそのことが、いつか「命取り」になる大
きな要因になるかも知れませんよね 。。。。

＃ こんなこと言うと「東洋海亀」さんに怒られるかな。(＠^.^＠)Ｙ

私は、あの「ＣＰ／Ｍ」が「ＭＳ－ＤＯＳ」に負けたのも、その少
しばかりの不安定だったところが、その原因だったのかなと思って
いますが 。。。。

「ＣＰ／Ｍ」のコマンド入力部分で、試しに「無茶苦茶な文字」を
入れてみたことが有ったのですが、それだけのことで見事にハング
してしまいました。（笑）

> これだけシェルの落ちやすいOSもなかなか無いなと思います.
> しかもシェルが落ちたら事実上再起動必要ですし.

私は今後、「ＷＩＮ」は遊びにだけ使おうと思っていますけれどね。
重要なことは、すべて「ＬＩＮＵＸ」にシフトするのを、計画中な
のです。

> その点,シェルは落ちるがOSまで落ちないWindows2000はかなり
> マシですね.でも、NT系OSはNT3.5が一番よかったような気が...

ＣＳＴＶでも見ましたが、今度の「ＭＡＣ－ＯＳ１０」は、アプリ
が落ちても、決して「ＯＳは落ちない」ような、そう言う工夫がし
てあるそうですよ。

「爆弾形式の違法ソフト？」を動かして、強制的なハングアップの
実験も、そのデモ中にやっていましたが、他のアプリケーションや
ＯＳには何の影響も無く、「爆弾が爆発」した後も平然と動いてた
のには感心しました。

> あと、Win9x 系の弱点としてリソースリークとそれが原因である
> 不安定さですね.9x系を信用できない一番の点だと思います.

「メモリー管理の部分が悪いのでは？」と言ううわさは、昔から有
りますよね。大昔の「ＭＳ－ＢＡＳＩＣ」の時でも、ガベージコレ
クションと言うのがはじまると、少なくとも数分間は黙りこくって
しまうのだとか。（笑） まぁそれが仕様なのですけれどね。（爆）

あるいは、初期の「ＭＳ－Ｃコンパイラー」の「マロックコマンド」
などでも、今度その確保したメモリーを開放する場合に、それを正
式に戻していない仕様になっていたとか？。。。。
当時のパソコン雑誌などには、いろいろと書かれていましたね。

ヒョットとすれば、「ＷＩＮの開発環境やＭＳのコンパイラー自体」
に、そもそも何か本質的な問題が有るのでは、と考えてしまいます。
それにしても、「ビジー」で止まる現象が多すぎますよね 。。。

> 正直なところ,きちんと整備したMacOS8.5 とWin9xならMacOSの方
> が安定してるかな.

そうですかぁ。最近の「ＭＡＣ－ＯＳ」がそれほど良くなっている
のなら、もう一度ＭＡＣの購入も検討してみたいです。

ＣＳＴＶで見た「ＭＡＣ－ＯＳ１０」は、操作性も安定性も良さそ
うで、おおいに期待できそうですね。＃ 私は「Ｇ４」が欲し～い。

＃ news:fj.comp.misc news:japan.comp.mac にも送っています。

[TKH]

"teruo Takeuchi" <take...@mx2.wt.tiki.ne.jp> wrote in message news:39DBC35D...@mx2.wt.tiki.ne.jp...
> ９５や９８より、明らかにＶ３．１の方が安定していたと思います。

メモリ使わなかったんでしょ。

> ＯＳには何の影響も無く、「爆弾が爆発」した後も平然と動いてた
> のには感心しました。

防爆スーツを着たのですね。
真の中身はxxxxxxxだったりして。

> そうですかぁ。最近の「ＭＡＣ－ＯＳ」がそれほど良くなっている
> のなら、もう一度ＭＡＣの購入も検討してみたいです。

飛距離が伸びているのですか。>そりゃMCAだな、廃れてる。

TKH

[Tanabe Takahiro]

Yoshitaka Ikeda wrote:
> #でも,Windows2000も固まって強制的に電源を落としたことは片手じゃ足りないくら
> い
> #ありますが.

順調に月1回以上のペースで青画面見てます。
そのおかげでデータがパーになったことも。
#固まってくれたほうがマシだった。
ユーザ切り替えただけで落ちるOSってのもなぁ。

--
0---------1---------2---------3---------4---------5---------6---------7
たなべたかひろ Highway Internet:tta...@pc.highway.ne.jp
(うさ)あたしは、あたしは、大女優に、なるわー。
(でじ)むりにょー。

[K.Nakagawa]

》> > Delphiが難しいと言う人の大半はPascal(正確にはObject Pascal)の言語仕様に

》> > 慣れてないだけで使ってみると結構簡単に開発できることに驚く人は多いですよ。
》>
》> いや。そういうところじゃなくて、ツールとしての使いごこちの話です。
》
》ツールとしての使いごごちだったらDelphiは最高じゃないっすか！

このへん主観が混じるから、あえて反論とかはしません。
使いごこちがいいと何人も証言しているのを知っているし。
ただ、私個人は使いにくいと主観で思っているだけなので。
たとえば、私はMSのVC++の環境は最悪に近いぐらい使い勝手が
悪いと思っているんですが、それでもサイコーと思っている人は
何人でも知ってますから。あくまで自分の感覚としては、Win系の
開発環境は、よけいなツールアイコンがだらだら出てきて、
最初にする仕事は、まずそれらをとっぱらうことです（爆）。

》> いちおう、これでも昔、I/Oにパスカルのプログラムを投稿して

》> 採用されたことはあります。
》
》そのPascalってDelphiでのPascalですか？
》
》それにしてもI/O、懐かしいですね。いつの時代のI/Oでしょうか？
》I/O全盛期ってことではありませんよね？(笑)

むかしむかしだったりするし（爆）。
まだイラストレータの木村さんが生きてたころだし。
ただ、その後、Code WarriorでObject Pascalで
いちおうオブジェクトを作ったプログラムはしていることは
弁明しておこう。ただしクラスライブラリがなかったので
長続きはしなかった（爆）。さすがにMacAppを使おうという
根性はでませんでしたなー。PowerPlantのほうがシンプルで
そっちに慣れてしまったから。Object Pascal版のPowerPlantが
あったなら間違いなくObject Pascalに行っていたでしょうな。

》> REALbasicに慣れると、Visual Basicですら難しく感じますね（爆）。
》> VBがVer.2の頃の易しさといえば、わかってもらえるでしょうか。
》
》REALbasicってオブジェクト指向プログラミングって可能なんでしょうか？
》メーリングリストに入ってながらあまり見てないもので・・・

可能だけど、細かいことを言えば「あ。なんか違う。」というところも
あるけど、どっちかといえばガーベージコレクションでメモリのリーク
を気にしなくてすむというJavaの良さ的なところが使い勝手がいいところ
でしょうかな？　それがなかったら、とっくに見捨ててます。あと、
Java流のインターフェイス継承も使えるけど、実際に活用している例は
まだまだ少ないでしょうな。どっちかというとMac版のVBという使われ方
が多いんでないかな。ただしOOP度に関して言えばREALbasicのほうが
VBよりも、はるかに進んでいて、VBは、これからってところでしょう。
（次期VBではOOPや例外処理、マルチスレッドが充実するらしい）

[Takemoto,Satoshi]

竹本と申します。

GON wrote:

> じゃあ何故同じVCLを使っているC++BuilderがDelphiに比べてコンパイルが遅いんでしょうか？
> 言語仕様としか考えようがないんですけど。

だ・か・らぁ、行なっている最適化の内容がぜんぜん違うんだろうと
いう事なんですよ、皆さんがおっしゃりたいのは。

例えば、Ｃで「nを1から10までカウントする。他に何もしない」という
いわゆる空ループを回そうとすると、オプティマイザがそれを見つけて
「nに10を代入する」処理に置換えてくれちゃったりします。
余計かもしれないけど、確かに速度は上がる。

その他にも、短い関数を見つけて自動的にソース展開してくれたり、

パイプラインの流れやスーパースカラのペアリングを考慮して
命令の実行順を変えてくれたり、

ローカル変数の代入，使用位置を調べ上げて、スタック上の同じ場所を
複数の変数に使い回してメモリを節約してくれたり、

勝手にループをほどいてくれたり、

いろいろやってくれるんですよ、いまどきのＣの最適化は。
それらの一つ一つに対して個別にスイッチがついてたりして、
Ｃコンパイラの最適化オプションてのはとっても複雑なんです。

どういう指定でコンパイルしたかで処理時間が倍以上変わるのは当たり前です。
デフォルトでも最適化するケースも有るので、
「最適化しない」というスイッチをした上で比較しないと
全く意味が無いです。

> 言ってる意味が伝わってないかもしれませんね。

この言葉、そのままお返しします。

--
竹本 聡 ソニー(株)PNC,PVC,DI部門1部

[GON]

"Akinori MUSHA" <k...@idaemons.org> wrote in message news:86wvfo...@archon.local.idaemons.org...
> 　インタープリタ言語で、速度を要求する部分や低レベル処理のために
> C 等で書いたモジュールを組み込んだりするのも今どき当たり前。

だったらその時点でコンパイルしてるでしょ。

もちろんあなたの言うようにＥｘｃｅｌやＡｃｃｅｓｓ用のモジュールが市販されている
ことも知ってます。ただ、「商用パッケージ」として店頭で売ってるものは圧倒的に
実行ファイル形式のものが多いことは否定できません。

＃　具満タンとかそういったデータだけのものは除いて

それとVBScriptやJScriptやRubyやPerlやRubyやPythonのソースが商用パッケージ
として売られている例って知らないんで教えてください。フリーとかシェアで
出回っているのは知ってますが店頭で見たことないんで・・・

私が言ってるのは「商用パッケージ」です。店頭で売ってるやつです。
勘違いしないでください。

[GON]

"Takemoto,Satoshi" <take...@cv.sony.co.jp> wrote in message news:39DBF8F7...@cv.sony.co.jp...

> 竹本と申します。
>
> GON wrote:
>
> > じゃあ何故同じVCLを使っているC++BuilderがDelphiに比べてコンパイルが遅いんでしょうか？
> > 言語仕様としか考えようがないんですけど。
>
> だ・か・らぁ、行なっている最適化の内容がぜんぜん違うんだろうと
> いう事なんですよ、皆さんがおっしゃりたいのは。

最適化の設定は全く同じです。それでもC++Builderのほうがコンパイルは遅いです。

あなた、実際にコンパイルしてみて言ってるんですか？

> いろいろやってくれるんですよ、いまどきのＣの最適化は。
> それらの一つ一つに対して個別にスイッチがついてたりして、
> Ｃコンパイラの最適化オプションてのはとっても複雑なんです。
>
> どういう指定でコンパイルしたかで処理時間が倍以上変わるのは当たり前です。
> デフォルトでも最適化するケースも有るので、
> 「最適化しない」というスイッチをした上で比較しないと
> 全く意味が無いです。

最適化しない設定でコンパイルしましたがやはりC++BuilderのほうがDelphiに比べて遅いです。

この違いは最適化云々ではありませんね。

一言で言えば「言語仕様の違いによるコンパイルにおけるオーバーヘッドの違い」に尽きると
思いますけど。

[Yukio Obuchi]

ぶちを＠そにーです。

"GON" <opens...@hotmail.com> writes:
> 一言で言えば「言語仕様の違いによるコンパイルにおけるオーバーヘッドの違い」に尽きると
> 思いますけど。

言語仕様と、実装での実行速度の関連性を論じるのはとても難しい話だと思いますよ。
すくなくとも、
「しいぷらぷらびるだーとでるふぁいをくらべたらでるふぁいが早かった」
なんて言ってるようではお話になりません。

ツールとして、「DelphiがC++Builderより使いやすい」という主張なら、ま
だ納得できますが。

--
Yukio Obuchi

[Akinori MUSHA]

At Thu, 5 Oct 2000 13:42:12 +0900,

GON <opens...@hotmail.com> wrote:
> "Akinori MUSHA" <k...@idaemons.org> wrote in message news:86wvfo...@archon.local.idaemons.org...
> > 　インタープリタ言語で、速度を要求する部分や低レベル処理のために
> > C 等で書いたモジュールを組み込んだりするのも今どき当たり前。
>
> だったらその時点でコンパイルしてるでしょ。

　単純な例を一つ挙げると、 VBA では Windows 標準の DLL をプロト
タイプを書くだけで利用できるわけだが、「Windows 標準 DLL や VBA を
動かしている Access などのエンジンはMicrosoft が C やアセンブリで
書いてコンパイルしたでしょ。」と言いますか。

> 私が言ってるのは「商用パッケージ」です。店頭で売ってるやつです。

　そんなことは問題になっていません。

At Thu, 5 Oct 2000 02:49:31 +0900,
GON <opens...@hotmail.com> wrote:

> 商用パッケージを作ってるものにとってインタープリタで出来ることなんてたかが知れてます。
> やはり直WinAPIやメモリにアクセスできないことには商用に耐えうるきびきびしたアプリケーションは
> 作れませんよね。

これに対し、私は商用ソフトがあること、 API にアクセスできる例、
速度に問題がない例を示しました。

　ところがあなたからは有効な反論はなく、代わりに私の発言を引用し
勝手に話を膨らませた上で私を「勘違い」呼ばわりしました。

　何やってんの。

[Takemoto,Satoshi]

竹本です。

GON wrote:

> あなた、実際にコンパイルしてみて言ってるんですか？

いいえ。Delphiに至っては経験すらありません。

が、コンパイルの条件を何も示さずに
「同じプログラム(?)を両者でコンパイルしてコンパイル速度を比べた」
という事実「だけ」から直接
「DelphiとC++の言語仕様の違いがコンパイル速度の違いの原因だ」
と結論するのは不可能だと言っているのです。だから

> > 「最適化しない」というスイッチをした上で比較しないと
> > 全く意味が無いです。

と書いたわけです。

> 最適化しない設定でコンパイルしましたがやはりC++BuilderのほうがDelphiに比べて遅いです。
>
> この違いは最適化云々ではありませんね。

はい、ありません。

しかし、依然DelphiとC++Builderという特定の処理系同士の比較でしかないのも
確かです。

コンパイラのバージョンの記述も有りません。

だから、この事実だけから

> 一言で言えば「言語仕様の違いによるコンパイルにおけるオーバーヘッドの違い」に尽きると
> 思いますけど。

と結論するのもまた不可能です。
# ていうか、コンパイラ自身の実装によってコンパイル速度などいくらでも
# 変わります。

ただ、(Delphiは知らないので憶測ですが)C++の言語仕様が不細工である事が
コンパイルのオーバーヘッドに少なからず寄与しているという主張自体は、
そういう気もします。ただ、C++の言語仕様のグサグサ度といったら、
変数の宣言位置どころの騒ぎでは無いのだけど。

# だから C-Like OO Language が沢山出てくるわけだ。
# JAVA, Embedded-C++, C--, C# ...
--
竹本 聡 ソニー(株)PNC,PVC,DI部門1部

[UCHIDA Toshiaki]

信者は説得できないという法則を再認識することになるのかなぁ?

"GON" <opens...@hotmail.com> wrote in message

news:8rfqg7$2ou$1...@nw042.infoweb.ne.jp...

> これは単純に言語仕様によるものと推察されます。

Delpi のほうが compile が速いことは GON さんが観測されたように確かなんでしょ
う。しかし、その理由は

"GON" <opens...@hotmail.com> wrote in message
news:8reg4o$obj$1...@nw041.infoweb.ne.jp...

> 手続きや関数や変数を宣言する場所がＣ＋＋と違ってObjectPascalの
> 場合は決まっていてその分オーバーヘッドが少ないから単純に速いんです。

というのは皆さんが指摘されているように間違いで、他に原因があるはずです。

> そういう意味では、コンパイラーにとってみればObjectPascalはコンパイル
> しやすいきれいな言語であって、

とか書くのならば、compiler について勉強して、内部でどういうことが行われてい
るのかを知ってから、その原因を考察して下さい。

＃確かに C++ は汚い言語ですけど

> > ならば、compile の必要のない言語を使うほうがもっと幸せになれますよ。
>
> 商用パッケージを作ってるものにとってインタープリタで出来ることなんて
> たかが知れてます。

Win からは外れますが、Win の商用 application よりもよほど performance を求め
られることの多い web application の多くが Perl や Python で記述されているこ
とはご存知ですか?
--
内田 俊明 (UCHIDA,Toshiaki)

[UCHIDA Toshiaki]

やっぱり信者かなぁ。

"GON" <opens...@hotmail.com> wrote in message

news:8rh0o0$dc5$1...@nw041.infoweb.ne.jp...

> > 　インタープリタ言語で、速度を要求する部分や低レベル処理のために
> > C 等で書いたモジュールを組み込んだりするのも今どき当たり前。
>
> だったらその時点でコンパイルしてるでしょ。

高速性を求められる部分のみを C などで記述し、他の大部分を Perl・Python 等で
記述しているってことですよ?
--
内田 俊明 (UCHIDA,Toshiaki)

[GON]

"Takemoto,Satoshi" <take...@cv.sony.co.jp> wrote in message news:39DC1DD0...@cv.sony.co.jp...
> > あなた、実際にコンパイルしてみて言ってるんですか？
>
> いいえ。Delphiに至っては経験すらありません。

やっぱそうでしたか。よくいるんですよ。一般論でものを言う人。
まず、Delphiを理解してないでDelphiは最適化をきちんと行ってないから
速いだのなんだのといった憶測で言うのはやめた方が良いんじゃない？

実際に開発にDelphiはバリバリ使ってますし、いろいろなＭＬでの議論を踏まえた
上で言ってるんでそう間違ったことは言ってないと思いますけどね。

もちろんオーバーヘッドの問題だけがコンパイラーの速度向上に寄与してる
わけではありませんが、Delphiのコンパイル速度が他の開発ツールに比べて
劇的に速い最大の原因がここにあることはDelphi関連のＭＬなんかの議論を
見てると納得できますけどね。

> > 最適化しない設定でコンパイルしましたがやはりC++BuilderのほうがDelphiに比べて遅いです。
> >
> > この違いは最適化云々ではありませんね。
>
> はい、ありません。
>
> しかし、依然DelphiとC++Builderという特定の処理系同士の比較でしかないのも
> 確かです。

あのねぇ、ＶＣと比較したものもありますけどそれはさらにひどいものですよ。

あなたの口調からあまりコンパイル速度の比較について御存知ないようですね。
雑誌やＷｅｂ上でもそこらへんの比較をしたものが出てますから一度見てから
ものを言ってほしいですね。

> > 一言で言えば「言語仕様の違いによるコンパイルにおけるオーバーヘッドの違い」に尽きると
> > 思いますけど。
>
> と結論するのもまた不可能です。
> # ていうか、コンパイラ自身の実装によってコンパイル速度などいくらでも
> # 変わります。

そういう一般的な問題にすりかえるんですか？コンパイラ自身の実装の中で
具体的にどこが本質的な部分なのかを議論してるんじゃないの？

あなたはその本質が最適化にあると主張されているわけですが、そうでないことは
Delphiに精通してる人間なら明らかなことなんですけどね。

> ただ、(Delphiは知らないので憶測ですが)C++の言語仕様が不細工である事が
> コンパイルのオーバーヘッドに少なからず寄与しているという主張自体は、
> そういう気もします。ただ、C++の言語仕様のグサグサ度といったら、
> 変数の宣言位置どころの騒ぎでは無いのだけど。

「Delphiは知らないので憶測ですが」の言葉であなたが当初主張されたことが
結局憶測でしかないことがはっきりしたわけですね。

> 竹本 聡 ソニー(株)PNC,PVC,DI部門1部

ソニーで働いているわりには随分一般論でものを言うんですね。(笑)
現実どうなのかを当たらずに単に一般論からの思い込みで最適化が問題であると
決めつけてますが、その前にまずDelphiがどんなものか知ってから発言してほしいですね。
少なくともObjectPascalの言語仕様ぐらいは最低理解した上で発言してください。

[GON]

"UCHIDA Toshiaki" <uch...@hmx12.com> wrote in message news:wdVC5.6388$TI5.2...@news1.dion.ne.jp...

> 信者は説得できないという法則を再認識することになるのかなぁ?
>
> "GON" <opens...@hotmail.com> wrote in message
> news:8rfqg7$2ou$1...@nw042.infoweb.ne.jp...
>
> > これは単純に言語仕様によるものと推察されます。
>
> Delpi のほうが compile が速いことは GON さんが観測されたように確かなんでしょ
> う。しかし、その理由は
>
> "GON" <opens...@hotmail.com> wrote in message
> news:8reg4o$obj$1...@nw041.infoweb.ne.jp...
>
> > 手続きや関数や変数を宣言する場所がＣ＋＋と違ってObjectPascalの
> > 場合は決まっていてその分オーバーヘッドが少ないから単純に速いんです。
>
> というのは皆さんが指摘されているように間違いで、他に原因があるはずです。

「皆さんが」の皆さんはDelphiを使ったこともないどころか言語仕様すら理解してない人
なんですけど。そういう人がDelphiは最適化が問題でコンパイルが速いと思ってしまう
のはどうなんでしょうかね？

コンパイルとは結局のところコンパイラーがソースファイルというデータ構造を弄くって
バイナリを生成することでしょうけど、そのデータ構造をアクセスする際のオーバーヘッド
が言語仕様を比較すればC++のほうが多いだろうことは容易に理解できることでしょう。

最適化をコンパイル速度向上の主要な要因でないことは最適化を外してコンパイルしてみれば
明らかです。

> Win からは外れますが、Win の商用 application よりもよほど performance を求め
> られることの多い web application の多くが Perl や Python で記述されているこ
> とはご存知ですか?

知ってるどころか実際に作ってます。で、わたしが言ってる商用パッケージとどう関係があるの？

[GON]

"UCHIDA Toshiaki" <uch...@hmx12.com> wrote in message news:8gVC5.6389$TI5.2...@news1.dion.ne.jp...

> 高速性を求められる部分のみを C などで記述し、他の大部分を Perl・Python 等で
> 記述しているってことですよ?

だから商用パッケージとどう関係があるの？

Perlで書いたアプリケーションが店頭で売ってますか？

[GON]

"Akinori MUSHA" <k...@idaemons.org> wrote in message news:8666n7...@archon.local.idaemons.org...

> At Thu, 5 Oct 2000 13:42:12 +0900,
> GON <opens...@hotmail.com> wrote:
> > "Akinori MUSHA" <k...@idaemons.org> wrote in message news:86wvfo...@archon.local.idaemons.org...
> > > 　インタープリタ言語で、速度を要求する部分や低レベル処理のために
> > > C 等で書いたモジュールを組み込んだりするのも今どき当たり前。
> >
> > だったらその時点でコンパイルしてるでしょ。
>
> 　単純な例を一つ挙げると、 VBA では Windows 標準の DLL をプロト
> タイプを書くだけで利用できるわけだが、「Windows 標準 DLL や VBA を
> 動かしている Access などのエンジンはMicrosoft が C やアセンブリで
> 書いてコンパイルしたでしょ。」と言いますか。

だから、その必要なＤＬＬやＡｃｔｉｖｅＸなんかは実際それ自身をコーディングするでしょ。
そういったものはたくさん売ってますしね。ＥｘｃｅｌやＡｃｃｅｓｓに組み込んで高速化する
モジュールなんかはいろいろ出てますし。

結局、本質的な部分はどうしてもコンパイルしたバイナリを必要とすることが多いですね。

> > 私が言ってるのは「商用パッケージ」です。店頭で売ってるやつです。
>
> 　そんなことは問題になっていません。
>
> At Thu, 5 Oct 2000 02:49:31 +0900,
> GON <opens...@hotmail.com> wrote:
> > 商用パッケージを作ってるものにとってインタープリタで出来ることなんてたかが知れてます。
> > やはり直WinAPIやメモリにアクセスできないことには商用に耐えうるきびきびしたアプリケーションは
> > 作れませんよね。
>
> これに対し、私は商用ソフトがあること、 API にアクセスできる例、
> 速度に問題がない例を示しました。

わかりました。「作れません」は言い過ぎでした。

できることと実際に発売されているものにそういったものがどれほどあるのかは別ですね。
わたしの知ってる限りではやはりモジュールは独自のＤＬＬやＡｃｔｉｖｅＸを開発した
ものが商用として売られていることが多いのは確かです。

そもそも根本的な問題としてソースだけで製品として出すことは商用としてはあまり
やらないですよね。コピーの問題もありますし大抵はバイナリをメインに販売してるんじゃ
ないですか？

[Akinori MUSHA]

At Thu, 5 Oct 2000 16:57:55 +0900,
GON <opens...@hotmail.com> wrote:
> コンパイルとは結局のところコンパイラーがソースファイルというデータ構造を弄くって
> バイナリを生成することでしょうけど、そのデータ構造をアクセスする際のオーバーヘッド
> が言語仕様を比較すればC++のほうが多いだろうことは容易に理解できることでしょう。

　「最適化」には、程度に応じた「オーバーヘッド」があるんですよ？

> 最適化をコンパイル速度向上の主要な要因でないことは最適化を外してコンパイルしてみれば
> 明らかです。

　「最適化」ってチェックボックスのことだと思ってますか？

　なんで生成されたコードを分析・比較したりする話が出てこないの？

[BABA Motoharu]

GON wrote:
>
> "UCHIDA Toshiaki" <uch...@hmx12.com> wrote in message news:wdVC5.6388$TI5.2...@news1.dion.ne.jp...

> > 信者は説得できないという法則を再認識することになるのかなぁ?
> >
> > "GON" <opens...@hotmail.com> wrote in message
> > news:8rfqg7$2ou$1...@nw042.infoweb.ne.jp...
> >
> > > これは単純に言語仕様によるものと推察されます。
> >
> > Delpi のほうが compile が速いことは GON さんが観測されたように確かなんでしょ
> > う。しかし、その理由は
> >
> > "GON" <opens...@hotmail.com> wrote in message
> > news:8reg4o$obj$1...@nw041.infoweb.ne.jp...
> >
> > > 手続きや関数や変数を宣言する場所がＣ＋＋と違ってObjectPascalの
> > > 場合は決まっていてその分オーバーヘッドが少ないから単純に速いんです。
> >
> > というのは皆さんが指摘されているように間違いで、他に原因があるはずです。
>

> 「皆さんが」の皆さんはDelphiを使ったこともないどころか言語仕様すら理解してない人
> なんですけど。そういう人がDelphiは最適化が問題でコンパイルが速いと思ってしまう
> のはどうなんでしょうかね？

Delphiは知らなくても計算機科学全般に関しては素養の有る方々だからでしょう。

>
> コンパイルとは結局のところコンパイラーがソースファイルというデータ構造を弄くって
> バイナリを生成することでしょうけど、そのデータ構造をアクセスする際のオーバーヘッド
> が言語仕様を比較すればC++のほうが多いだろうことは容易に理解できることでしょう。
>
> 最適化をコンパイル速度向上の主要な要因でないことは最適化を外してコンパイルしてみれば
> 明らかです。

手もとのマシンで、Delphi 4で現在仕事で開発中のプログラムを再構築
(要するにmake clean した状態で make)してみましたが最適化して約14秒、
最適化無しでも約14秒。ほとんど最適化には時間を費やしていないようです。

＃さすが「安全でない最適化はしない」と宣言してるだけのことはある、って感じ:p

Delphiの最適化をもって最適化の一般論として語るのはやめておきましょう。
計算機科学に対する素養がないと言って笑い者にされるのがオチです。

一般的なコンパイラではコンパイルの処理のうち最適化がかなりの時間を食うものです。
＃つまりDelphiはそういうコンパイラに比べたら「最適化なんて何もしてない」に等しい

--
馬場 基晴
mailto: ba...@atlantis21.co.jp

[Akinori MUSHA]

At Thu, 5 Oct 2000 17:20:29 +0900,
GON <opens...@hotmail.com> wrote:
> "Akinori MUSHA" <k...@idaemons.org> wrote in message news:8666n7...@archon.local.idaemons.org...

> > 　単純な例を一つ挙げると、 VBA では Windows 標準の DLL をプロト
> > タイプを書くだけで利用できるわけだが、「Windows 標準 DLL や VBA を
> > 動かしている Access などのエンジンはMicrosoft が C やアセンブリで
> > 書いてコンパイルしたでしょ。」と言いますか。
>

> だから、その必要なＤＬＬやＡｃｔｉｖｅＸなんかは実際それ自身をコーディングするでしょ。
> そういったものはたくさん売ってますしね。ＥｘｃｅｌやＡｃｃｅｓｓに組み込んで高速化する
> モジュールなんかはいろいろ出てますし。

　やっぱり言いますか。

> 結局、本質的な部分はどうしてもコンパイルしたバイナリを必要とすることが多いですね。

　ところが、実際には内田さんは

At Wed, 4 Oct 2000 17:45:29 +0900,
UCHIDA Toshiaki <uch...@hmx12.com> wrote:
> ならば、compile の必要のない言語を使うほうがもっと幸せになれますよ。

と仰ったわけですから、プログラマがコンパイルする必要がないという
時点で一つの主張として成立するわけです。

　そしてあなたはそういう言語は商用パッケージには使えないと主張
しましたが、

> わかりました。「作れません」は言い過ぎでした。

と折れました。

　だから、もう内田さんにつっかかる筋合いはないんです。

> できることと実際に発売されているものにそういったものがどれほどあるのかは別ですね。
> わたしの知ってる限りではやはりモジュールは独自のＤＬＬやＡｃｔｉｖｅＸを開発した
> ものが商用として売られていることが多いのは確かです。

　いいえ。家計簿ソフトや財務経理、在庫管理のパッケージソフトも
たくさんあります。

　だいたい、あなたの「知ってる限り」というのが信用できないんです。
ちゃんと調べて事実として提示したり、ちゃんと分析検証して論拠として
示さないのだから。

　そういうのが一 Delphi ユーザとしての態度なんですか？

> そもそも根本的な問題としてソースだけで製品として出すことは商用としてはあまり
> やらないですよね。コピーの問題もありますし大抵はバイナリをメインに販売してるんじゃ
> ないですか？

　またここにも誤った固定観念がありますね。

　VBA, JScript, VBScript, PerlScript などには、ソースを読めなく
したり、スクランブルするツールが用意されています。ActivePerl は
インタプリタと結合して .exe にできますし、 Python は中間コード
形式に変換できます。

　で、結局何が言いたいのでしたっけ。

[Takemoto,Satoshi]

竹本です。

GON wrote:

> やっぱそうでしたか。よくいるんですよ。一般論でものを言う人。

一般論も大事です。
特定の処理系に精通しているだけでは見えない事だって有ります。

> まず、Delphiを理解してないでDelphiは最適化をきちんと行ってないから
> 速いだのなんだのといった憶測で言うのはやめた方が良いんじゃない？

私の主張を矮小化してますね。最適化には拘泥していません。

最適化に関する他の方の発言を一切無視して「言語仕様が原因だ」と
主張されるものだから「ちょっと待てよ」という気持ちで、
あのような記事を書いたのです。

とにかく私は GON さんの記事に論理的飛躍が有ると言いたかった。

> そういう一般的な問題にすりかえるんですか？コンパイラ自身の実装の中で
> 具体的にどこが本質的な部分なのかを議論してるんじゃないの？

だったら、もう少し別の例示と議論の展開の仕方が有るのでは?
GON さんの記事では、まるで「変数の宣言位置こそ本質的な部分だ」と
読めますよ?

Delphi の言語仕様の C++ のそれに対する優位性として、
それしか示してないですもの。

で、「最適化はどうした?」とか、「Turbo Pascal 系統のコンパイラが
伝統的に速いのはアセンブラで実装されているからでは?」とか
実装関係の反論には何も返さずに「言語仕様の優位性」ばかり主張されていた。

それではまるで「変数の宣言位置だけで全てが決まる」と言っているみたいで
す。

> あなたはその本質が最適化にあると主張されているわけですが、そうでないことは
> Delphiに精通してる人間なら明らかなことなんですけどね。

私が最適化に拘泥していると誤解されるのと同程度に
GON さんが変数の宣言位置に拘泥されていると(わざと)誤解して書きます。

私は
変数の宣言位置が一個所にまとまるかどうかと比べれば、
最適化やコンパイラの実装方式の方が大事だと、いまだに思っています。

> ソニーで働いているわりには随分一般論でものを言うんですね。(笑)

こんなとこにまで毒づく(-_-)... 一応言及します。

基本的にソニーは家電品メーカーです。変わりつつは有るけれど。
VAIOも作っていますが、TVもビデオもステレオもラジオもカーナビも携帯も、
その他いろんな物を作っています。

IT 時代と言われて久しいですが、
現在の様に Windows や UNIX 系 OS が支配的な状況が、
いつまでもそのままだとは思いません。

そうした特定のプラットフォームの現状(RAD ツールのコンパイル速度)が
それほど重要だとは思っていないので関心が無いのです。
# 大体遅いのが嫌なら、速い PC 買うし。
# 生成したコードのスピード／サイズは大問題だけど。

うちらはどちらかと言うと、組込みやアプライアンスやPS2を足がかりに、
現状をひっくり返そうとする立場ではないかと思ってますが。
あ、あくまで私個人の見解ですよ。
# OS (プラットフォーム)ベンダとのライセンスにしても、全方位外交だし。
# Win、JAVA、Palm、EPOC、VX-Works ...
# あ、Aperios (^^;
# ... て、別にライセンス買って使ってるわけじゃないか。
--
竹本 聡 ソニー(株)PNC,PVC,DI部門1部

[Akinori MUSHA]

At Thu, 5 Oct 2000 17:04:39 +0900,
GON <opens...@hotmail.com> wrote:
> "UCHIDA Toshiaki" <uch...@hmx12.com> wrote in message news:8gVC5.6389$TI5.2...@news1.dion.ne.jp...

> > 高速性を求められる部分のみを C などで記述し、他の大部分を Perl・Python 等で
> > 記述しているってことですよ?
>

> だから商用パッケージとどう関係があるの？
>
> Perlで書いたアプリケーションが店頭で売ってますか？

　売ってたらどうなんですか？売ってなかったらどうなんですか？

　UNIX 向けのパッケージソフトなら、 Perl を使っているものも当然
ありますよ。Web ブラウザを介したインターフェースで Perl による
CGI を使っているものとか、 Python/Tk や Perl/Gtk+ を使ったソフト
とか。

　それらは Windows などでも実現できるので、 Windows 用ソフトでも
存在して不思議はないです。

　そもそも、なんで売ってないと思い込んでしまうのか知りたいです。

　次に出てくる言葉は、それらは少数派だ、ですか？とすると C++ で
書かれたパッケージソフトが Delphi で書かれたものより圧倒的に多い
ということについてはどうなんでしょう。

　多い少ないで可能不可能や優劣を論じられるわけじゃないでしょうに。

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <39DB4E9C...@atlantis21.co.jp> の
記事において 2000年10月05日(木) 00時37分00秒頃、
BABA Motoharu <ba...@atlantis21.co.jp>さんは書きました。

>> > ん? compile が速いのは Turbo シリーズ以来の Borland の伝統なんですけど、こ
>> > れって Pascal だからというよりも optimize が甘いからなんじゃないかなぁと思っ
>> > たりする…。
>>
>> 否、それは違います。
>
>否、違いません。

>基底クラスであるTObjectクラスのほとんどのメソッドはアセンブラで書かれてるし。

TObjectがアセンブラしまくってるのは、どっちかってーと、
「Delphi自身で記述できないから」という理由が強いように
思うのですが。
delphiにとって最初から存在することが前提となっている幾つかの仕掛けを
ソコで作りこんでいるわけですから。

＃Rubyでいえば拡張ライブラリの立場に近いですかね。
＃なんでCで書かないんだろう？とは疑問に思いましたけど(笑)＞TObject

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8rfrhe$2tn$1...@nw042.infoweb.ne.jp> の
記事において 2000年10月05日(木) 03時07分14秒頃、
"GON" <opens...@hotmail.com>さんは書きました。

>ツールとしての使いごごちだったらDelphiは最高じゃないっすか！

「ものすごく良い！」とは思う(だからファンだ)けど、
「最高！」と思うことは絶対ないですね、俺は。
何故なら最高は有り得ないから(笑)。

少なくとも、IDEのエディタに、viなキー定義が欲しいっす(^^;

つまり、「足りないと思う部分」は、任意(笑)のタイミングで
どんどん出現するわけでして。

>そのコンポーネントなんかもVCLのクラス継承して結構簡単に
>自分仕様のものを作れちゃいますしね。これはかなり便利です。

ところでFrameクラスが出来て万歳三唱しています俺。
長年の望みが叶いました。
＃逆にいえば、ver4までは「Frameのようなものがない」
＃という不満があったわけです俺。

>> いちおう、これでも昔、I/Oにパスカルのプログラムを投稿して
>> 採用されたことはあります。
>
>そのPascalってDelphiでのPascalですか？

そういやStreamクラスを使うとかなり快適になりますね。

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8rfqg7$2ou$1...@nw042.infoweb.ne.jp> の
記事において 2000年10月05日(木) 02時49分31秒頃、
"GON" <opens...@hotmail.com>さんは書きました。

>> 確かにそういう言語仕様のほうが compile が速くなることは確かでしょう。
>>
>> でも、これはせいぜい compile 時の 1pass の高速化に多少寄与するだけで、以後の
>> pass にはほとんど影響を与えないはずです。で、compile にかかる時間の多くはそ
>> の高速化されない pass でかかっているはずです。
>
>C++BuilderもDelphiと同じVCLを使ってますがやはりコンパイルはDelphiに比べてのろいで
>す。
>これは単純に言語仕様によるものと推察されます。結局、一言で言えばDelphiのほうが
>コンパイル時のオーバーヘッドが少ないってことに帰着するんじゃないでしょうか？

「コンパイル時のオーバーヘッドが少ない」のであろう、という想像は
出来ますが、更に踏み込んで、「オーバーヘッドが少ないのは何故か？」は
それこそ想像しか出来ないんじゃないかと。

>そういう意味では、コンパイラーにとってみればObjectPascalはコンパイルしやすい
>きれいな言語であって、C++はあっち行ったりこっち行ったりと手間の掛かるきたない
>言語なのかも。(←「きたない」なんて刺激的なワードをあえて使ってしまいました(爆))

コンパイルしやすさと、所謂(ってナンだ?)綺麗さとは、
微妙に別問題なような気が。
コンパイルがなんぼ速くても、人間サマが読んで嫌がる言語ならば、
「綺麗」なのかどうか考えこんでしまうんで。

>> > ＃　正直、コンパイルが速いというのはDelphiの最大の特徴だと思ってます。
>> > ＃　ストレスがほとんど感じられません。
>>
>> ならば、compile の必要のない言語を使うほうがもっと幸せになれますよ。

「compileを何時の間にやったんだかワカンナイほど高速」
なように見えます、delphiのcompileって。
どこぞの言語がインタプリタ[がで]読み込むのに
かかるのと同じくらいの時間で済んじゃう。
かつ、compileは一度で済むわけですから。

＃って、俺そういや最近のVBはいじってないので、
＃アレ(かつてver2ならいじってたのですが)が今は劇的に高速に
＃なってしまったというなら、上の話はどうでもいいです。

速度以外の話では、あと何がありましたっけ、
compileの必要がないことのメリットって？
管理のしやすさ/しにくさ(ってのかなあ)は、
IDEの管理下に置けば別に気にならないしなぁ。

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8rh0o0$dc5$1...@nw041.infoweb.ne.jp> の
記事において 2000年10月05日(木) 13時42分12秒頃、
"GON" <opens...@hotmail.com>さんは書きました。

>もちろんあなたの言うようにＥｘｃｅｌやＡｃｃｅｓｓ用のモジュールが市販されている
>ことも知ってます。ただ、「商用パッケージ」として店頭で売ってるものは圧倒的に
>実行ファイル形式のものが多いことは否定できません。

「店頭」に並んでいるかどうかなんていう話って、
なんかそんなに重要な話なのかなあ？
オンライン販売だってあるだろうし。

あと、中間コードで動かすような奴って、どう捉えたら良いんでしょう？
ソースそのものでもないけどexeやdllでもないし。
＃javaとか？

よだん：
プログラム部品の市場(市場かfreeかは直接は俺の関心事じゃないけど)が
育たないのだとすれば、その一因は、その(?)OS上で、部品が
気持ち良く存在しにくいようになってるせい、かな、とは思います。

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8rh1p8$dfq$1...@nw041.infoweb.ne.jp> の
記事において 2000年10月05日(木) 13時59分57秒頃、
"GON" <opens...@hotmail.com>さんは書きました。

>最適化の設定は全く同じです。それでもC++Builderのほうがコンパイルは遅いです。

「同じ」って一体…

設定画面のCheckBoxの押した奴を同じにすることが、
コンパイラの内部でも(完全(?)に)同じ変化を
もたらすという保証が、どこにあります？

あと、「同じ」プログラムを違う言語(のコンパイラ)に
与えることは、「不可能」ですしね。

>あなた、実際にコンパイルしてみて言ってるんですか？

「実際にやらないと＊なにも＊判らない」と考えるのは、しばしば危険です。

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8rhc70$esa$1...@nw041.infoweb.ne.jp> の
記事において 2000年10月05日(木) 16時57分55秒頃、
"GON" <opens...@hotmail.com>さんは書きました。

>「皆さんが」の皆さんはDelphiを使ったこともないどころか言語仕様すら理解してない人
>なんですけど。そういう人がDelphiは最適化が問題でコンパイルが速いと思ってしまう
>のはどうなんでしょうかね？

ぉぃ(=_=);
それじゃ「単なる信者」にしかなれないぞ！
delphi信者(笑)の俺としては、ハタで見てて、かなり心苦しい。

>コンパイルとは結局のところコンパイラーがソースファイルというデータ構造を弄くって
>バイナリを生成することでしょうけど

「でしょうけど」って、ねえ…

>最適化をコンパイル速度向上の主要な要因でないことは最適化を外してコンパイルしてみれ
>ば
>明らかです。

一例は一例です。

逆にいえばdelphiの功績は、そんじょそこら(笑)のソフトを作る程度なら
最適化なんて頑張らなくても(今のCPUなら)いいのさ！と看破してくれた
ことなんじゃねーか、と思っています。
＃delphiに限った話か、Turboの伝統か、は知りません御免。
全然証拠レスの憶測ですが、たとえばクラスつーかオブジェクトを
またいだ最適化って、やってねーんじゃねーのかなdelphiは？

「それでいい」から、やってないっていう。
それで不足な人は、最適化しっかりやってくれる別のコンパイラを
用意して、DLLだかobjだかをソレで作ってね、と。

そういう意味では、インタプリタに片足突っ込んでるっていうか、
コンパイラとインタプリタのイイトコ取りをした言語(実装)なのかも。

RTTI使いまくるサマなんて、一種のインタプリタだし。

グルー(糊)言語とかいう言葉があるようですが、
delphiもある意味では、糊っぽい面が(も)あるように思います。
コンポペタペタなんて、糊そのもの。

>知ってるどころか実際に作ってます。で、わたしが言ってる商用パッケージとどう関係があ
>るの？

あなたの言ってる商用パッケージの話「は」関係ナイのだと思います(^^;

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8rhaai$a53$1...@nw042.infoweb.ne.jp> の
記事において 2000年10月05日(木) 16時25分41秒頃、
"GON" <opens...@hotmail.com>さんは書きました。

>やっぱそうでしたか。よくいるんですよ。一般論でものを言う人。

具体論のほうが一般論より＊常に＊偉いと思うのは危険です。

>まず、Delphiを理解してないでDelphiは最適化をきちんと行ってないから
>速いだのなんだのといった憶測で言うのはやめた方が良いんじゃない？

あのー。そもそも最適化を「きちんと」やるっていうことの定義って
出来るんですか？どこまでやると「きちんと」なの？

＃最適化なんて、(必要ない場合は)やらなくていいじゃん。
＃それが恥ずべきことでもなんでもない。

つまり、delphiを「理解」するってのは、どういう境地(笑)に
達することを言うの？そのソースを見た事もない(よね?)コンパイラを
「理解」するなんて言われても…

>実際に開発にDelphiはバリバリ使ってますし、いろいろなＭＬでの議論を踏まえた
>上で言ってるんでそう間違ったことは言ってないと思いますけどね。
>
>もちろんオーバーヘッドの問題だけがコンパイラーの速度向上に寄与してる
>わけではありませんが、Delphiのコンパイル速度が他の開発ツールに比べて
>劇的に速い最大の原因がここにあることはDelphi関連のＭＬなんかの議論を
>見てると納得できますけどね。

そーゆー、自分の仕事や所属MLの質を疑われるキッカケになるよーな
こと言うのは、よしましょうよ。
＃というのは実際は嘘で、本当に「質を疑われる」のは…以下略…

どうせ(俺の理解の及ぶ範囲ではですが(笑))delphiのコンパイラのソースを
「見た事がナイ」人と「見た事はアルがそれについて公然と喋れない」人と
どっちかしか、この世にはイナイんだから。

っていうか、与えられたコンパイラを走らせただけで、
なにを「証明」できるんだか。「測定」にはなってるけどさ。
「証明」できないけどとにかく凄い(=役立つ)のは間違いないと思うが。

俺は、niftyとかでも色々やりとりしたことありますが、
この件について「推測」の域を出た議論を見た記憶は
多分ナイですね。
それともMLのほうで、俺どこにも入ってないんで知りませんが、
なんか新しい展開があるんでしょうか？
だったらそれこそ具体的に(笑)どこのMLの記事番号何番なのかを
教えて頂けると嬉しいです。いやマヂで。webでログ公開してる
MLとかも結構ありますよね。

>あのねぇ、ＶＣと比較したものもありますけどそれはさらにひどいものですよ。

まぁ考えてみれば、OOPのモデル…ってのかな…がそもそも違うわけで、
比べる意味すらナイと思いますけどね、普通(VC含めて)のC++とは。

＃C++Builderは、モデルをDelphiのソレ(Javaにむしろ近い)に合わせるため、
＃言語仕様に独自拡張てんこもり。＞知らない人

>少なくともObjectPascalの言語仕様ぐらいは最低理解した上で発言してください。

ところで、ObjectPascalって、Delphi以外の奴もあるみたいですね。
全然言語仕様違うとか聞きましたけど俺はまだ見た事ないです。
コードウォーリアー(?)に入ってるObjectPascalとかがソウだぞとか
友人が先日言っていたような気が。

[代かき馬]

in article <39DBC35D...@mx2.wt.tiki.ne.jp>, teruo Takeuchi
<take...@mx2.wt.tiki.ne.jp> wrote on 2000.10.05 8:55 AM :

> 「ＭＳ－ＷＩＮ」は、Ｖ２．０のころから一応知ってはいますが、
> ９５や９８より、明らかにＶ３．１の方が安定していたと思います。
>
むむふむ。私は、Win3.1でソフト開発をしていました。
否定はしません。強く肯定もしません。

> 私は、あの「ＣＰ／Ｍ」が「ＭＳ－ＤＯＳ」に負けたのも、その少
> しばかりの不安定だったところが、その原因だったのかなと思って
> いますが 。。。。

すみません。「CP/M-86」の誤記ではないでしょうか？

> あるいは、初期の「ＭＳ－Ｃコンパイラー」の「マロックコマンド」
> などでも、今度その確保したメモリーを開放する場合に、それを正
> 式に戻していない仕様になっていたとか？。。。。
> 当時のパソコン雑誌などには、いろいろと書かれていましたね。

「マロックコマンド」？？？
malloc関数のことですか？
それはコンパイラーの仕様ではないでしょう。
ライブラリーの不具合でしょう（当時は日常茶飯事）。

> ヒョットとすれば、「ＷＩＮの開発環境やＭＳのコンパイラー自体」
> に、そもそも何か本質的な問題が有るのでは、と考えてしまいます。

それは、「ボーランド社」の製品でも同じだったでしょう。
BCWのクラスライブラリでもバグがかなりあって、
メモリ解放しないなんてのはしょっちゅうでしたし、
私は、ソースから直してましたよ。

> それにしても、「ビジー」で止まる現象が多すぎますよね 。。。

う～ん。ビジーで止まる現象に出くわしたことがない...

--
代かき馬

[ARIMA Yasuhiro]

GON wrote:

> 「皆さんが」の皆さんはDelphiを使ったこともないどころか言語仕様すら理解してない人
> なんですけど。そういう人がDelphiは最適化が問題でコンパイルが速いと思ってしまう
> のはどうなんでしょうかね？

私はたかだかここ数年しか Delphi を使ってないもので教えてほしいのですが、
私は GON さんの主張を「言語仕様における宣言の位置がコンパイル速度に決定的な影響を与える。
それ以外の作業、例えば最適化などはコンパイル速度に影響を与えない。」と読みましたが、あってますか？

Message-ID: <8reg4o$obj$1...@nw041.infoweb.ne.jp>

ちがうならこれで終わりです。失礼しました。

「言語仕様のために C++ はコンパイルに時間がかかる」という命題は合意がとれているようです。
なので、Delphi が速いとすると、理由はなんだろうね？という話になります。

> 最適化をコンパイル速度向上の主要な要因でないことは最適化を外してコンパイルしてみれば
> 明らかです。

これは、Delphi が最適化のスイッチにかかわらずたいした作業をしていないことを表すと
理解しましたがいかがでしょうか？ BCB で同様のことを行えば、最適化という作業が
コンパイル速度に影響を与えるものであるのがわかります。だから、Delphi が最適化という
作業を減らすことでコンパイル速度の向上を図るという戦略を選んだと考えますがいかがですか？

「皆さんが」の皆さんは、このようなことを述べているのだと思います。

--
有馬 康弘 <fit...@fitec.co.jp>

[SAITOH, Takumi]

In article <wdVC5.6388$TI5.2...@news1.dion.ne.jp>

"UCHIDA Toshiaki" <uch...@hmx12.com> wrote:
>> 手続きや関数や変数を宣言する場所がＣ＋＋と違ってObjectPascalの
>> 場合は決まっていてその分オーバーヘッドが少ないから単純に速いんです。
>というのは皆さんが指摘されているように間違いで、他に原因があるはずです。

　うちの環境では、C++Builder2とDelphi4なら前者の勝ちで、C++Builder5とDelphi4
なら後者の勝ちだったりして(C++Builder2>Delphi4>C++Builder5)....

[Takemoto,Satoshi]

竹本＠自宅です。

Nakamura Akifumi wrote in message <20001005205...@nifty.ne.jp>...
>中村暁史っす。

>>あのねぇ、ＶＣと比較したものもありますけどそれはさらにひどいものですよ。
>
>まぁ考えてみれば、OOPのモデル…ってのかな…がそもそも違うわけで、
>比べる意味すらナイと思いますけどね、普通(VC含めて)のC++とは。

生成されるコードの効率を考慮してたはずなのに、
結局変な風になっちゃってますよね、C++って。
# 変数宣言の位置の所為じゃないですよ、念のため。
# C++の分際で、多重継承や例外やRTTIなんかやりだすから
# おかしくなった。
# 最初から素直に単一継承＋templateだけで良かったのに。

>>少なくともObjectPascalの言語仕様ぐらいは最低理解した上で発言してください。
>
>ところで、ObjectPascalって、Delphi以外の奴もあるみたいですね。

そりゃ、Pascal＋オブジェクト指向ってだけなら
無限のバリエーションが有り得ますよね。
ＣベースのＯＯ言語も然り。
# そう言えば、Objective-Cってのも有ったっけ。
# Ｃのソースの中に、Smalltalk みたいなコードを
# []で囲んで突っ込む奴。

最適化の要否ですが、いったんPCターゲットを離れると、
(つまり私の今の仕事みたいにpoorな組込マイコンなんかになると)
やはり「危険なくらいの最適化」が恋しくなります(^^)。

が、開発者全体が多くない(＝市場が小さい)ので、
願いはほとんど叶いません。
今使ってるＣコンパイラも、ほんっとに馬鹿なコードを吐く。
こんなベンダに「危険なくらいの最適化」を要求したら
本当に危険なコードしか出なくなるでしょう(^^;。
で、そういう時は奇麗事は言ってられないので
セコセコ「人間おぷてぃまいざー」するしか無い訳です。

ただ、マイコン機種はコストと供給量優先で決定されるので
アセンブラではやってられませんが。

ＰＣのDOS/V＋エクステンダ環境をターゲットにして
Watcom-Cを使ってた時は、確かに最適化してほしいプログラム
なんてほとんど(ちょっとしか)無かったけど。

でも、ターゲットが選べない場合でも、
開発環境(特にハード)は大抵勝手に選べるんだから、
最適化を禁止してまでコンパイル速度を求めるのは、
「角を矯めて牛を殺す」だと思うなぁ。

LL(1) や LR なんて用語、15年ぶりくらいに聞きました。
ここ5年くらい、私の中でコンパイラの定義とは
「与えられたソースコードから、如何に効率の良いオブジェクト
コードを吐くかをヒューリスティックに追求する(一種の)AIプログラム」
です(^^;。ソースは何でもいいんです。
FortranでもC++でもDelphiでもEiffelでもShemeでも。
文法なんて(C++以外は)多分すぐに憶えられるし。
# parser が再び脚光を浴びる時代になったか(^^)。

[GON]

"Akinori MUSHA" <k...@idaemons.org> wrote in message news:86wvfn...@archon.local.idaemons.org...

> > 結局、本質的な部分はどうしてもコンパイルしたバイナリを必要とすることが多いですね。
>
> 　ところが、実際には内田さんは
>
> At Wed, 4 Oct 2000 17:45:29 +0900,
> UCHIDA Toshiaki <uch...@hmx12.com> wrote:
> > ならば、compile の必要のない言語を使うほうがもっと幸せになれますよ。
>
> と仰ったわけですから、プログラマがコンパイルする必要がないという
> 時点で一つの主張として成立するわけです。

しかし、compile の必要のない言語だけでは作れないものが実際にあって
そういったものが商用としての価値をもって市販されているわけですから
インタープリタは万能でないわけでコンパイラを完全に使わないでＯＫ
ということが完全にできない以上コンパイラを必要とすることには変わり
ありませんね。

> 　そしてあなたはそういう言語は商用パッケージには使えないと主張
> しましたが、
>
> > わかりました。「作れません」は言い過ぎでした。
>
> と折れました。
>
> 　だから、もう内田さんにつっかかる筋合いはないんです。

使えるものもあるっていう程度で現実問題としてそういったものの割合が
商用パッケージとしては少ないのですから、インタープリタを使えば
問題解決のような錯覚を起こすような発言はちょっと違うと思いますけどね。

> > できることと実際に発売されているものにそういったものがどれほどあるのかは別ですね。
> > わたしの知ってる限りではやはりモジュールは独自のＤＬＬやＡｃｔｉｖｅＸを開発した
> > ものが商用として売られていることが多いのは確かです。
>
> 　いいえ。家計簿ソフトや財務経理、在庫管理のパッケージソフトも
> たくさんあります。

なかなか多い少ないってのは何を基準にそうなのか示しづらいわけで
店頭に行ってみての感触からしか言えませんがたくさん並んでいる
パッケージを見ると素材集のようなデータ主体のものやゲームや
ユーティリティのようなアプリケーションは良く見かけますが
その中ですべてインタープリタを使ったアプリケーションっていうのは
わたしの印象では思いつきません。

あなたの主張するほどにたくさん出てるのかちょっと疑問です。
勘定奉行とかも立派なアプリケーションですよね？インタープリタで
動かしてるわけじゃないと思いますが。

> 　だいたい、あなたの「知ってる限り」というのが信用できないんです。
> ちゃんと調べて事実として提示したり、ちゃんと分析検証して論拠として
> 示さないのだから。

それではあなたはきちんと分析調査した上でインタープリタを使った
アプリケーションがたくさん出ていると主張されているのですか？

たぶん私と同じ程度で店頭での感触で言ってるにすぎませんよね？

すいませんが、ニュースグループで議論するのに店頭にわざわざ行って
逐一調査するほど暇もありませんし、そんなことをわざわざする気もありません。

Ｗｅｂ上で調べるのも手ですが同じだけの膨大な手間をかけてまで
インタープリタを利用したソフトがいくつあって全体の何割か？なんて
ことを調べるつもりもありません。

そういう意味ではあなたも私も自分の体験から言ってるわけですから
「知ってる限り」でしかものが言えないことはどちらも同じだと思いますけど。

> > そもそも根本的な問題としてソースだけで製品として出すことは商用としてはあまり
> > やらないですよね。コピーの問題もありますし大抵はバイナリをメインに販売してるんじゃ
> > ないですか？
>
> 　またここにも誤った固定観念がありますね。
>
> 　VBA, JScript, VBScript, PerlScript などには、ソースを読めなく
> したり、スクランブルするツールが用意されています。ActivePerl は
> インタプリタと結合して .exe にできますし、 Python は中間コード
> 形式に変換できます。

「できること」と「実際に製品として出ていること」とは別でしょ。

「あまりやりませんよね？」には同意していただけるんでしょうか？

[GON]

"Akinori MUSHA" <k...@idaemons.org> wrote in message news:86vgv7...@archon.local.idaemons.org...

> 　次に出てくる言葉は、それらは少数派だ、ですか？とすると C++ で
> 書かれたパッケージソフトが Delphi で書かれたものより圧倒的に多い
> ということについてはどうなんでしょう。

あの、話があさっての方向に飛んでますけど？（笑）

商用として完全にインタープリタを使ったものとコンパイルされた実行ファイルのもの
とは圧倒的に後者が多いことを言ってるのに、何で実行ファイルがDelphiで生成された
ものか否かが関係あるんですか？話をそらさないでください。

とにかくあなたの言うようなものは例外中の例外。枝葉末節。

[GON]

"Akinori MUSHA" <k...@idaemons.org> wrote in message news:863dib...@archon.local.idaemons.org...

> 　「最適化」には、程度に応じた「オーバーヘッド」があるんですよ？

じゃぁ、今までの議論はどうなっちゃうの？（笑）

オーバーヘッドが原因だという私の主張は間違ってないんですね？（笑）

> > 最適化をコンパイル速度向上の主要な要因でないことは最適化を外してコンパイルしてみれば
> > 明らかです。
>
> 　「最適化」ってチェックボックスのことだと思ってますか？
>
> 　なんで生成されたコードを分析・比較したりする話が出てこないの？

そこまですれば完璧でしょうね。わたしは手短にあるソースファイルを適当に
コンパイルしてみて比べてみましたけど５、６個のファイルすべてについて
Delphiがやはり速かったです。正確には生成物の違いを逐一逆アセンブルして
見ていかなくてはならないのでしょうけど面倒なんでやってません。

「最適化の違いがコンパイル速度の違いである」というあなたがたの主張からすれば
同じ条件でコンパイルしてみて生成されたコードが違っていればその主張にも理が
あることになりますが、生成されたものがほとんど違っていないにもかかわらず
コンパイル速度に大きな違いがあればそれは最適化が原因でないことになるでしょう。

生成コードの中身までは見てませんが起動時のフォームだけのソースをコンパイルした結果は
容量としてDelphi５で２８５ｋ、C++Builder５は２９８ｋでした。若干の違いのみが確認され
ましたがコンパイルの速さはDelphiのほうが圧倒的に速かったです。

もちろんコンパイラそのものの性能に起因する部分もあるのでしょうけど
それだけでDelphiのコンパイル速度が他に比べて劇的に速いことは説明できません。

[GON]

"Nakamura Akifumi" <BXQ0...@nifty.ne.jp> wrote in message news:20001005205...@nifty.ne.jp...

> 中村暁史っす。
>
> fj.soc.economy,japan.jiji,fj.comp.misc の <8rhaai$a53$1...@nw042.infoweb.ne.jp> の
> 記事において 2000年10月05日(木) 16時25分41秒頃、
> "GON" <opens...@hotmail.com>さんは書きました。
>
> >やっぱそうでしたか。よくいるんですよ。一般論でものを言う人。
>
> 具体論のほうが一般論より＊常に＊偉いと思うのは危険です。

っていうか偉いとかそういった発想でものを考えているあなたのほうが危ないよ。(笑)

少なくともDelphiはoptimizeが甘いと言った主張をするのならDelphiを
理解した上で発言されるのが筋。Delphiを使ったことも言語仕様すらも
理解してないでoptimizeが甘いと言い切ることはできませんね。

ちょっと脱線しますが、現場を把握しないで一般論で計画を進めて失敗した例は
この分野に限らずいろんな分野で多々あります。仕事でも１番うまくいくパターン
は現場を良く把握している人と詳しく打ち合わせをした場合ですね。ここがうまく
行かない時って決まってトラブルが頻発します。本来きちんと現場を把握していれば
回避できたことでもそこらへんを怠ったために痛い目にあったことはわたしも
何度か経験してます。そのたびに「実際にどうなのかをきちんと把握することの大切さ」
を痛感させられます。

一般論は大事ですがそれは具体的な事象を把握した上で展開されるべきことであることを
忘れてはなりません。

＃　これって物理の理論家が実験を無視して理論構築して失敗するのに似てますね。

> つまり、delphiを「理解」するってのは、どういう境地(笑)に
> 達することを言うの？そのソースを見た事もない(よね?)コンパイラを
> 「理解」するなんて言われても…

だったらDelphiは最適化が甘いってどうして主張できるの？
見たこともないのによくもまぁそこまで断定できるのかふしぎですね。

何より笑えるのは自分たちの主張が憶測であることを自分たちが認識してない
馬鹿さ加減ですね。

少なくともPascalのプログラムがどんな構造をしてるかぐらいは理解した上で
最適化云々言ってもらいたいね。(笑)

> だったらそれこそ具体的に(笑)どこのMLの記事番号何番なのかを
> 教えて頂けると嬉しいです。いやマヂで。webでログ公開してる
> MLとかも結構ありますよね。

自分で調べてください。(笑)

分析・調査云々言ってる割には御自分ではなさらないんですね。

> >少なくともObjectPascalの言語仕様ぐらいは最低理解した上で発言してください。
>
> ところで、ObjectPascalって、Delphi以外の奴もあるみたいですね。
> 全然言語仕様違うとか聞きましたけど俺はまだ見た事ないです。
> コードウォーリアー(?)に入ってるObjectPascalとかがソウだぞとか
> 友人が先日言っていたような気が。

旧バージョンのCodeWarriorではPascalも使えたそうな。それもObjectPascalと
言っていたようなことを聞いたことあります。

もちろんわたしが言ってるのはDelphiで使われているものであることは
文脈から理解されるとは思いますが・・・

[GON]

"Nakamura Akifumi" <BXQ0...@nifty.ne.jp> wrote in message news:20001005204...@nifty.ne.jp...

> >あなた、実際にコンパイルしてみて言ってるんですか？
>
> 「実際にやらないと＊なにも＊判らない」と考えるのは、しばしば危険です。

実際にやってみないで判ったと判断するのはもっと危険です。

[GON]

"Takemoto,Satoshi" <take...@cv.sony.co.jp> wrote in message news:39DC4CD5...@cv.sony.co.jp...

> 竹本です。
>
> GON wrote:
>
> > やっぱそうでしたか。よくいるんですよ。一般論でものを言う人。
>
> 一般論も大事です。
> 特定の処理系に精通しているだけでは見えない事だって有ります。

一般論が大事でないなんて一言も言っておりません。

> > まず、Delphiを理解してないでDelphiは最適化をきちんと行ってないから
> > 速いだのなんだのといった憶測で言うのはやめた方が良いんじゃない？
>
> 私の主張を矮小化してますね。最適化には拘泥していません。
>
> 最適化に関する他の方の発言を一切無視して「言語仕様が原因だ」と
> 主張されるものだから「ちょっと待てよ」という気持ちで、
> あのような記事を書いたのです。

ところが言語仕様によるオーバーヘッドが大したことでないという
指摘は全くありませんでしたね。そこらへんは同意してるんでしょうか？

＃　しかし、C++とPascalの言語仕様を比べたら前者のほうが圧倒的に
＃　オーバーヘッドが多いだろうことは容易に想像がつくんだけどなぁ

> だったら、もう少し別の例示と議論の展開の仕方が有るのでは?
> GON さんの記事では、まるで「変数の宣言位置こそ本質的な部分だ」と
> 読めますよ?

あの、これは１つの例を出したまでで変数宣言ばかりじゃありません。
他にも言語仕様に基づく実装においてC++と本質的に異なる部分は
多々あります。その上でPascalのソースはコンパイルする上では
オーバーヘッドが少ないデータ構造なんだろうなぁと推測します。

> で、「最適化はどうした?」とか、「Turbo Pascal 系統のコンパイラが
> 伝統的に速いのはアセンブラで実装されているからでは?」とか
> 実装関係の反論には何も返さずに「言語仕様の優位性」ばかり主張されていた。

ちなみにDelphiはDelphiで書かれているってのは有名な話です。しかし、Delphiが
アセンブラで書かれていようがなかろうが速度的に大きな差は生じないと思いますけどね。
実際に速度が落ちるのはほとんどの場合データ構造を扱う際のオーバーヘッドの多さでしょ？
１度で済むものを２度見なくてはならないのなら単純に２倍時間かかりますけど
同じルーチンをアセンブラで高速化したってそれほどの劇的に差は生じませんよね。

コンパイラにとってコンパイルしやすいのがPascalだと思います。

> 私は
> 変数の宣言位置が一個所にまとまるかどうかと比べれば、
> 最適化やコンパイラの実装方式の方が大事だと、いまだに思っています。

私は最適化は今となってはコンパイラごとの差はほとんどないと思ってます。
コンパイラの実装の仕方が違うということには私も同意します。オーバーヘッド
が少ないようにソースを解釈して実装してるわけですから。そう言ったら
最適化だって実装の仕方に含まれますしね。

> > ソニーで働いているわりには随分一般論でものを言うんですね。(笑)
>
> こんなとこにまで毒づく(-_-)... 一応言及します。

これは失礼。ｍ(_ _)ｍ

商売やってる企業で働いている割には考え方がアカデミックなんでつい・・・

> そうした特定のプラットフォームの現状(RAD ツールのコンパイル速度)が
> それほど重要だとは思っていないので関心が無いのです。
> # 大体遅いのが嫌なら、速い PC 買うし。
> # 生成したコードのスピード／サイズは大問題だけど。

ここの感覚が大学の教授とか役人の発想に近いものがありますね。

わたしはあなたのような大企業で働いてるわけじゃありませんから
そんな発想はしません。

あなたの場合、C++のコンパイルがのろいと思うならパソコンを
高速なものに買い換えれば良いじゃないか？って発想ですね。

わたしならより高速で生産性の良いコンパイラを探しますね。
もちろんPCが速いに越したことはありませんがそれでも
メモリーにアクセスするスピードはそれほど高速化できません
からコンパイル時にメモリーアクセスの多いソースになれば
PCをいくら高速化したって大して速くなるとも思えません。

それより言語自体がメモリー効率の良いコンパイラを採用している
ほうが劇的な速度アップが期待できるでしょう。

わたしにとってはコンパイルのスピードの速さはストレス解消
になってますね。

[Akinori MUSHA]

At Fri, 6 Oct 2000 03:44:24 +0900,

GON <opens...@hotmail.com> wrote:
> 商用として完全にインタープリタを使ったものとコンパイルされた実行ファイルのもの
> とは圧倒的に後者が多いことを言ってるのに、何で実行ファイルがDelphiで生成された
> ものか否かが関係あるんですか？話をそらさないでください。

　だから、多いとどうなんですか。十分にできうるという時点で話は
終わっています。あなたはインタープリタは役不足と抜かした。ところが
違った。

> とにかくあなたの言うようなものは例外中の例外。枝葉末節。

　反例というのは一つあれば十分なんです。

[Yukio Obuchi]

ぶちを＠そにーです。

サブジェクトも変えず、Followup-Toも指定せずに「Ａｐｐｌｅ株大暴落」に
もfj.soc.economy.japanにも関係の無い話題を続けるのはやめてください。

"GON" <opens...@hotmail.com> writes:
> ところが言語仕様によるオーバーヘッドが大したことでないという
> 指摘は全くありませんでしたね。そこらへんは同意してるんでしょうか？

fj.comp.lang.implementation に議論が派生していて、そちらでは、有意義
な議論が交わされています。
# 私の知識を超えたところで議論されているので、フォローはしておりません
# が、面白く読まさせていただいております。

話はそれほど単純ではありません、コンパイル速度の話も「言語仕様」の一
言ですまされるようなものではありません。
ただし、GONさんには、言語仕様と、コンパイラの実装の区別がついていない
ようですが。

> コンパイラにとってコンパイルしやすいのがPascalだと思います。

そう主張するなら、それなりのまともな意見をおっしゃってください。GONさ
んの意見には「Delphiのコンパイルが速い」以上の情報はありません。

せめて、fj.comp.lang.implementationでの前田さんの記事
<m3snqb6...@maedapc.cc.tsukuba.ac.jp>と、そのスレッドくらいには目
を通してください。

> わたしにとってはコンパイルのスピードの速さはストレス解消
> になってますね。
「Delphiのコンパイル速度が速い」というのは誰も否定していません。
だから、GONさんにとって、Delphiが快適なツールであるというのはよくわか
りますが、それをもって、PascalとC/C++の比較にもっていこうとするから、
話がややこしくなるのです。

だれも、「C++Builderの方がDelphiよりも使いやすいぜ」などという主張は
していないと思うのですが。

--
Yukio Obuchi

[BABA Motoharu]

馬場＠ユニコーンです。

GON wrote:
>
> > > できることと実際に発売されているものにそういったものがどれほどあるのかは別ですね。
> > > わたしの知ってる限りではやはりモジュールは独自のＤＬＬやＡｃｔｉｖｅＸを開発した
> > > ものが商用として売られていることが多いのは確かです。
> >
> > 　いいえ。家計簿ソフトや財務経理、在庫管理のパッケージソフトも
> > たくさんあります。
>
> なかなか多い少ないってのは何を基準にそうなのか示しづらいわけで
> 店頭に行ってみての感触からしか言えませんがたくさん並んでいる
> パッケージを見ると素材集のようなデータ主体のものやゲームや
> ユーティリティのようなアプリケーションは良く見かけますが
> その中ですべてインタープリタを使ったアプリケーションっていうのは
> わたしの印象では思いつきません。

インタプリタ自体はインタプリタで構成することは出来ませんから全てを
インタプリタでというのは無理な話ですね、とかいうツッコミはさておき:-)

emacsはemacs-lispのインタプリタとバイトコードの塊じゃなかったかな?
＃emacsは店頭には置いてないか...
＃でも「かなり普及しているアプリケーション」ではあると思うが

あと「うちのソフトもJava版を出すぞ」と表明しているソフトハウスは結構あった
ような気がします。
＃ATOKは既にJava版を出していた・・・ような気がしたんだけど?(最近健忘症気味)

--
株式会社ユニコーン 情報システム事業部
馬場 基晴
mailto: ba...@atlantis21.co.jp

[NAKAMURA Takahiro]

中村です。

＃fj.comp.miscに絞ります。

At Fri, 6 Oct 2000 00:39:01 +0900,

Takemoto,Satoshi <take...@ba2.so-net.ne.jp> wrote:
>
> 最適化の要否ですが、いったんPCターゲットを離れると、
> (つまり私の今の仕事みたいにpoorな組込マイコンなんかになると)
> やはり「危険なくらいの最適化」が恋しくなります(^^)。
>

同感です。たった1バイトを削るために血のにじむような努力をしますもんね。

大体ROM出図間際になってから「あ゛～！、ROMがあふれたぁ～～～っ！」って
声を聞くことが多いし。

> が、開発者全体が多くない(＝市場が小さい)ので、
> 願いはほとんど叶いません。
> 今使ってるＣコンパイラも、ほんっとに馬鹿なコードを吐く。
> こんなベンダに「危険なくらいの最適化」を要求したら
> 本当に危険なコードしか出なくなるでしょう(^^;。

うちで今使ってるやつも最適化レベルを上げると特定の関数が期待した動作を
しなくなることがありました。レベルが低いときには正常動作するのですが、
ソースを見ても特におかしな所が見当たらないし、これが「危険なくらいの
最適化」ってやつなんでしょうね。

＃そのため、ファイル毎に最適化レベルが違ったりしているし。(^^;

> で、そういう時は奇麗事は言ってられないので
> セコセコ「人間おぷてぃまいざー」するしか無い訳です。
>

「人間おぷてぃまいざー」ってどうするのでしょうか？
Ｃコンパイラの吐き出したアセンブラソースをさらに人手で修正するのでしょう
か？

私はアセンブラソースを出力させておき、出力結果を見ながら試行錯誤で
Cソースを修正してもっとも効率のいいオブジェクトを出させるようにすること
はあります。

＃例えば関数内で引数はいったんauto変数にコピーしてから演算を
＃行わせるとオブジェクトのバイト数が小さくなったりするなど。
＃コンパイラによっては逆に増えることもあるのでまさにケースバイケース

--
NAKAMURA Takahiro

[Takemoto,Satoshi]

竹本です。

GON wrote:

> 一般論が大事でないなんて一言も言っておりません。

なら良いです。

> ところが言語仕様によるオーバーヘッドが大したことでないという
> 指摘は全くありませんでしたね。そこらへんは同意してるんでしょうか？

「言語仕様」といってもいろいろ有ります。例があれでは...

> ＃　しかし、C++とPascalの言語仕様を比べたら前者のほうが圧倒的に
> ＃　オーバーヘッドが多いだろうことは容易に想像がつくんだけどなぁ

はい、ひとえに例が悪すぎです。

> あの、これは１つの例を出したまでで変数宣言ばかりじゃありません。

１つの例で、押し過ぎです(^^)。

> 他にも言語仕様に基づく実装においてC++と本質的に異なる部分は
> 多々あります。その上でPascalのソースはコンパイルする上では
> オーバーヘッドが少ないデータ構造なんだろうなぁと推測します。

C++ と比べれば何だってマシです。

> > で、「最適化はどうした?」とか、「Turbo Pascal 系統のコンパイラが
> > 伝統的に速いのはアセンブラで実装されているからでは?」とか
> > 実装関係の反論には何も返さずに「言語仕様の優位性」ばかり主張されていた。
>
> ちなみにDelphiはDelphiで書かれているってのは有名な話です。しかし、Delphiが
> アセンブラで書かれていようがなかろうが速度的に大きな差は生じないと思いますけどね。
> 実際に速度が落ちるのはほとんどの場合データ構造を扱う際のオーバーヘッドの多さでしょ？
> １度で済むものを２度見なくてはならないのなら単純に２倍時間かかりますけど
> 同じルーチンをアセンブラで高速化したってそれほどの劇的に差は生じませんよね。

この辺は、fj.comp.lang.miscとのクロスポストの部分で、
久野先生や前田先生の記事が出てますので、私ごときが出る幕は無いです。

> コンパイラにとってコンパイルしやすいのがPascalだと思います。

これも私の偏見かも知れませんが GON さんの主張は、
どうも言語仕様の中でも手続きや関数の構文に軸足が有るようですね。

私が「C++の言語仕様は悪い」と言う時は、データ周りの仕組み
(継承やら、動的／静的束縛やら、型体系やら)の方が中心なんですけど。

記憶の糸を手繰ると、約20年くらい前にそうした(PASCAL対Cの構文に関する)
議論は有ったと思います。

でもムーアの法則のせいで、決着が付かぬままうやむやになったわけです。
(つまり「どっちでも良いじゃん、そんなの」と言う事)

> 私は最適化は今となってはコンパイラごとの差はほとんどないと思ってます。

GON さんには、コンパイラのアセンブラ出力を読まれる事を是非お勧めします。
同じ様な作業を、同じような速度で行なうコード出力でも、コンパイラの実装や
コンパイルスイッチ一つで全然違うものが出てきます。
私も、これをやり始めて認識が変わりました。

速ければ良いという訳じゃ有りません。Borland-Cのアセンブラ出力も随分
見ましたが、安全第一で元のソースに忠実だという意味で「堅実な」コードを
出します。これもポリシーなのでしょう。

# おかげで、BCやTCを使う時は速度の事は考えなくなった。
# 確かに、教育的効果が有ります(^^;。

最適化にはゴールは有りません。
一時期に比べて、各社のコンパイラの差は詰まってきましたが、
まだまだこれから、もう一段も二段も進歩します。
# 実装されていない最適化技法は山ほど有るみたいです。
# 「露天掘り」とか「パイプライニング」とか.... by 堂園さん。
# ソースファイルやクラスをまたいだ最適化も入れれば、それこそ無制限。
終息はまだまだです。

> > # 大体遅いのが嫌なら、速い PC 買うし。
> > # 生成したコードのスピード／サイズは大問題だけど。
>
> ここの感覚が大学の教授とか役人の発想に近いものがありますね。

「時間を金で買う」というのはビジネス発想そのものなんですが....

> わたしはあなたのような大企業で働いてるわけじゃありませんから
> そんな発想はしません。

ビジネスプランをプレゼンテーションして、有望だと思われれば
銀行融資も投資も受けられますよ? (^^)

あるいは、何らかのライセンスでオープンソース配布して
感謝されれば援助してもらえるかも。

> わたしならより高速で生産性の良いコンパイラを探しますね。
> もちろんPCが速いに越したことはありませんがそれでも
> メモリーにアクセスするスピードはそれほど高速化できません
> からコンパイル時にメモリーアクセスの多いソースになれば
> PCをいくら高速化したって大して速くなるとも思えません。

メモリアクセスは高速化できます。現実にどんどん高速化してます。
66MHz ===> 100MHz ===> 133MHz ===> 200MHz....
「解決すれば金になる」と解れば、金をジャブジャブ注ぎ込んで解決する。
本当にビジネスってやつぁ...

> それより言語自体がメモリー効率の良いコンパイラを採用している
> ほうが劇的な速度アップが期待できるでしょう。

いたずらにでかい言語は悪い、というのは同意します。しかし、
メモリやHDDの方がコンパイラより更に「劇的」に速度アップしています。
悔しいが太刀打ちできない。
# ソフトの速度が倍になる間に、ハードは1桁速くなるんだもの(^^;。

ハードのコストパフォーマンスが、犬並みの速さ(^^)で良くなっているので、
「速度はハードで稼ぐもの、性能はソフトで稼ぐもの」
という標語に従うしかなかった。PC ターゲットでやってた時は。
# 今となっては懐かしい....(遠い目)

> わたしにとってはコンパイルのスピードの速さはストレス解消
> になってますね。

ストレスになっているのはみんな一緒です。
ストレス解消法は人それぞれですが。
--
竹本 聡 ソニー(株)PNC,PVC,DI部門1部

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8rik8q$lr8$1...@nw042.infoweb.ne.jp> の
記事において 2000年10月06日(金) 04時21分36秒頃、
"GON" <opens...@hotmail.com>さんは書きました。

>それだけでDelphiのコンパイル速度が他に比べて劇的に速いことは説明できません。

だからさ、「説明できない」という処までしか、話できないんだってば。

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8rimok$mk6$1...@nw042.infoweb.ne.jp> の
記事において 2000年10月06日(金) 05時04分09秒頃、
"GON" <opens...@hotmail.com>さんは書きました。

>> >あなた、実際にコンパイルしてみて言ってるんですか？
>> 「実際にやらないと＊なにも＊判らない」と考えるのは、しばしば危険です。
>実際にやってみないで判ったと判断するのはもっと危険です。

誰も「判った」とは言っていませんね、今回。

で、実際にコンパイルしてみた程度(!)で、何が判ったんですか？
単に「速い」というだけでしょ？
その程度のことなら全員(?)が「認めている」わけです。

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8rihdf$l45$1...@nw042.infoweb.ne.jp> の
記事において 2000年10月06日(金) 03時32分52秒頃、
"GON" <opens...@hotmail.com>さんは書きました。

>パッケージを見ると素材集のようなデータ主体のものやゲームや
>ユーティリティのようなアプリケーションは良く見かけますが
>その中ですべてインタープリタを使ったアプリケーションっていうのは
>わたしの印象では思いつきません。

ホントかどうか調べたことないんで腐った伝聞ですみませんが、
どっかの市販ゲーム会社が、自前のインタプリタみたいなもんで
自社の製品を開発して販売してる、とか聞いたような気がします。
ゲンジツでなかったとしても、フカノウではなさそうですよね。

>勘定奉行とかも立派なアプリケーションですよね？インタープリタで
>動かしてるわけじゃないと思いますが。

なんで判るんでしょう？
＃あの会社に昔友人が勤めていたような気が。もし会えたら訊いてみよっかな。

>それではあなたはきちんと分析調査した上でインタープリタを使った
>アプリケーションがたくさん出ていると主張されているのですか？
>
>たぶん私と同じ程度で店頭での感触で言ってるにすぎませんよね？
>
>すいませんが、ニュースグループで議論するのに店頭にわざわざ行って
>逐一調査するほど暇もありませんし、そんなことをわざわざする気もありません。

破綻してますね。
「あなたは調べたわけでもないでしょう」かつ
「わたしも調べたわけではありません」なのならば、
「どっちも同じ程度」なのではないですか？
少なくともGONさんの主張のほうが強そうだと判断する理由が
ナイですぅ。

>「できること」と「実際に製品として出ていること」とは別でしょ。

実際であることにこだわる「ならば」、調査するっきゃないでしょ？

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8rimg0$mfb$1...@nw042.infoweb.ne.jp> の
記事において 2000年10月06日(金) 04時59分33秒頃、
"GON" <opens...@hotmail.com>さんは書きました。

>> 具体論のほうが一般論より＊常に＊偉いと思うのは危険です。
>っていうか偉いとかそういった発想でものを考えているあなたのほうが危ないよ。(笑)

自分の中に偉い偉くないの優先順位が暗黙のうちにできていることに
気付かない人のほうが…まぁいいか。

>少なくともDelphiはoptimizeが甘いと言った主張をするのならDelphiを
>理解した上で発言されるのが筋。Delphiを使ったことも言語仕様すらも
>理解してないでoptimizeが甘いと言い切ることはできませんね。

だからさ。「理解」って何？
ソースも見れへんで、どうやって「理解」を？
あるいは全然別口で何か良い情報があるなら、教えてよ。

で、言語仕様の理解っすかぁ？
ちゃんとコンピューターを(一般的に(笑))やってる人なら、
DELPHIの言語仕様とかって、巷に転がってる情報で
「理解」できるんでないっすかぁ？
DELPHI入門講座くさいwww頁とか(笑)、Freeでソース公開な
コンポのソース読むとかぁ。
少なくとも「それだけじゃ「理解」できない」ような
難解なものでは、ないと思うけどなDELPHIの言語仕様は。

よだん：
当然憶測ですが(笑)、Turboから類推するのは悪くないんじゃないかと思います。
C++がCから類推なぞ到底できない代物に成り果てている(笑)のに
比べれば、TurboからDelphiへの変化は、察するにコンパイラの負担の変化は
小さいんじゃないかと…

よだん２：
そういやdelphi互換な文法の別コンパイラもあるんでしたよね。freeだっけ。
少なくとも「言語」仕様はソレ見れば判るかもね。

>ちょっと脱線しますが、現場を把握しないで一般論で計画を進めて失敗した例は
>この分野に限らずいろんな分野で多々あります。仕事でも１番うまくいくパターン
>は現場を良く把握している人と詳しく打ち合わせをした場合ですね。

一般論の「せい」だと、恐らくは、常には言えないと思うのですがね。
充分区別した上での結論なんですかそれ？

>何度か経験してます。そのたびに「実際にどうなのかをきちんと把握することの大切さ」
>を痛感させられます。

で、そこまでおっしゃるアナタは、DELPHIの何処までを「理解」してるんですか？
F9押してコンパイルの速さに感動するだけなら、俺にだって出来ますけど、
それ以上なんですよね？

>＃　これって物理の理論家が実験を無視して理論構築して失敗するのに似てますね。

＃似てるかぁ？どこが？

>何より笑えるのは自分たちの主張が憶測であることを自分たちが認識してない
>馬鹿さ加減ですね。
>
>少なくともPascalのプログラムがどんな構造をしてるかぐらいは理解した上で
>最適化云々言ってもらいたいね。(笑)

はて？憶測でないことを認識してない人を、ここらへんのスレッドで
見た記憶は、ないのですけど？

挙句「Pascalの」ですか。
そんなもん、「それすら知らない人がここで書いている」とでも
本気で思っているんでしたら、相当おめでたいです。

>> だったらそれこそ具体的に(笑)どこのMLの記事番号何番なのかを
>> 教えて頂けると嬉しいです。いやマヂで。webでログ公開してる
>> MLとかも結構ありますよね。
>自分で調べてください。(笑)
>分析・調査云々言ってる割には御自分ではなさらないんですね。

なに言ってんですか？「(何処を調べたらいいのか)判らないから教えてくれ」
って言ってるのに。
ついでに、「アナタの調査度はどんなもんかを調査(笑)してる」んですけどね。

他人に教えられないようなML名なんですか？
具体的(笑)に実在するMLですよね？

>> >少なくともObjectPascalの言語仕様ぐらいは最低理解した上で発言してください。
>> ところで、ObjectPascalって、Delphi以外の奴もあるみたいですね。
>もちろんわたしが言ってるのはDelphiで使われているものであることは
>文脈から理解されるとは思いますが・・・

「Delphiの」という接頭語をつけたほうが
穏当(笑)かなと思わないでもなかったんで。

[Majima Kenichi]

BABA Motoharuさんは<39DD3E30...@atlantis21.co.jp>でこうおっしゃいました。

>> その中ですべてインタープリタを使ったアプリケーションっていうのは
>> わたしの印象では思いつきません。
>
>インタプリタ自体はインタプリタで構成することは出来ませんから全てを
>インタプリタでというのは無理な話ですね、とかいうツッコミはさておき:-)

　そんなこともないと思いますが。
　昔のパソコン雑誌では、BASIC言語で記述された○○言語、なんてのが結構
掲載されていたような気が。

>あと「うちのソフトもJava版を出すぞ」と表明しているソフトハウスは結構あった
>ような気がします。
>＃ATOKは既にJava版を出していた・・・ような気がしたんだけど?(最近健忘症気味)

　ATOKはどうでしたか。とりあえず、一太郎Ark for Javaがありますね。
　あと、CornelOfficeとか、StarOfficeとか、DesktopOnCallなどもPureJava
がウリだったように思います。勘違いだったらすみません。

--
/*******************************
Majima Kenichi
ke...@pp.iij4u.or.jp
*******************************/

[Majima Kenichi]

GONさんは<8rik8q$lr8$1...@nw042.infoweb.ne.jp>でこうおっしゃいました。

>> 　なんで生成されたコードを分析・比較したりする話が出てこないの？
>
>そこまですれば完璧でしょうね。わたしは手短にあるソースファイルを適当に
>コンパイルしてみて比べてみましたけど５、６個のファイルすべてについて
>Delphiがやはり速かったです。正確には生成物の違いを逐一逆アセンブルして
>見ていかなくてはならないのでしょうけど面倒なんでやってません。

　あの、DelphiでC++のソースをコンパイルしたのですか？それとも
C++BuilderでObjectPascalのソースをコンパイルしたのですか？

　言語が違う以上、比較したプログラムも当然違うはずだと思うので、あなた
が使用したソースファイルがどのようなものかによっても話がずいぶん違って
くるのではないでしょうか。

>生成コードの中身までは見てませんが起動時のフォームだけのソースをコンパイルした
>結果は

　みたいな、言語仕様が無視できるほどの小さなプログラムであれば、パーサ
のアルゴリズムを云々する以前の、たとえばヘッダファイルをたくさん
includeしないといけないだとか、そういったことの影響の方が大きそうな気
がします。
　逆に、それなりに大規模(ってなんだ？(c)中村暁史さん)なプログラムだ
と、言語仕様の差からくるアルゴリズムの違いなども無視できなくなりそうで
す。

　素人考えですが。

[Yoshitaka Ikeda]

"Tanabe Takahiro" <tta...@pc.highway.ne.jp> wrote in message
news:39DBDC...@pc.highway.ne.jp...
> Yoshitaka Ikeda wrote:
> > #でも,Windows2000も固まって強制的に電源を落としたことは片手じゃ足りない
くら
> > い
> > #ありますが.
>
> 順調に月1回以上のペースで青画面見てます。
> そのおかげでデータがパーになったことも。
> #固まってくれたほうがマシだった。
> ユーザ切り替えただけで落ちるOSってのもなぁ。

私がプレビュー版を入れたのが1月中旬
製品版は発売当日に入れましたが、やはり、それくらいの頻度ですよねぇ.

#Windows98で、青画面を出しきれずに黒画面を出してしまった(意味不明の文字列付
き)
#こともあります.まあ、MacOSでも爆弾もでないことありますしねぇ(笑)

--
(ε)(ε) 池田　尚隆@Mobile Env
レ ik...@4bn.ne.jp
___ YonbetsuNetzwerk

[Hironobu Suzuki]

>>>>> "G" == GON <opens...@hotmail.com> writes:
In article <8rihdf$l45$1...@nw042.infoweb.ne.jp> "GON" <opens...@hotmail.com> writes:
G> インタープリタは万能でないわけでコンパイラを完全に使わないでＯＫと
G> いうことが完全にできない以上コンパイラを必要とすることには変わりあ
G> りませんね。

Luke, Use the FORTH!

ひろのぶ

[Shiroh Sado]

横からつっこんで申し訳ないですが、

ke...@pp.iij4u.or.jp氏の発言 <8rlajf$n1v$1...@news00.iij4u.or.jp> より引用

>> BABA Motoharuさんは<39DD3E30...@atlantis21.co.jp>でこうおっしゃいました。
>> >> その中ですべてインタープリタを使ったアプリケーションっていうのは
>> >> わたしの印象では思いつきません。
>> >
>> >インタプリタ自体はインタプリタで構成することは出来ませんから全てを
>> >インタプリタでというのは無理な話ですね、とかいうツッコミはさておき:-)
>>
>> 　そんなこともないと思いますが。
>> 　昔のパソコン雑誌では、BASIC言語で記述された○○言語、なんてのが結構
>> 掲載されていたような気が。

馬場さんのいっているのは、そのBASIC言語はさらにインタ
プリタ言語で記述されており……、という再帰的な話(ある
種の冗談)ではないでしょうか。

私の中では、「その」が「インタプリタ」のどれかの直前に
一つ増えると、誤解の可能性が一つ減るような気がしていま
す。

---
佐渡詩郎 (さど しろう) / e-mail : sa...@smlab.tutkie.tut.ac.jp

[Majima Kenichi]

Shiroh Sadoさんは<8rpdu1$ou2$1...@news.tut.ac.jp>でこうおっしゃいました。

>>> >> その中ですべてインタープリタを使ったアプリケーションっていうのは
>>> >> わたしの印象では思いつきません。
>>> >
>>> >インタプリタ自体はインタプリタで構成することは出来ませんから全てを
>>> >インタプリタでというのは無理な話ですね、とかいうツッコミはさておき:-)
>>>
>>> 　そんなこともないと思いますが。
>>> 　昔のパソコン雑誌では、BASIC言語で記述された○○言語、なんてのが結構
>>> 掲載されていたような気が。
>

>馬場さんのいっているのは、そのBASIC言語はさらにインタ
>プリタ言語で記述されており……、という再帰的な話(ある
>種の冗談)ではないでしょうか。

　あ、それは無理っぽいですね。

# 中間コードを直接実行するCPUとかはどう分類したらよいのでしょうか。

[GON]

"Takemoto,Satoshi" <take...@cv.sony.co.jp> wrote in message news:39DD97CF...@cv.sony.co.jp...
> > あの、これは１つの例を出したまでで変数宣言ばかりじゃありません。
>
> １つの例で、押し過ぎです(^^)。

オーバーヘッドを理解する上では最も視覚的に理解しやすいだろうと思って例に出したまで。
もちろんクラス継承の違いからくる実装の仕方の違い等いろいろありますが、細かいこと言うと
判りづらくなるだけですから端的に「言語仕様の違いからくるオーバーヘッド」が原因であろうと
主張したわけです。

どうもあなたがたは最適化がC++とDelphiでは違うからコンパイルの速さが違うのだと思い込んで
いるようですが、Delphiが最適化をきちんとやってない証拠はなにも提示してませんし、今時の
コンパイラにおいてそれほど最適化の違いが存在するとも思えませんから最適化だけでコンパイル
速度の違いを説明しようとするのにはかなり無理がある感じがします。

> > コンパイラにとってコンパイルしやすいのがPascalだと思います。
>
> これも私の偏見かも知れませんが GON さんの主張は、
> どうも言語仕様の中でも手続きや関数の構文に軸足が有るようですね。

言語仕様の違いによるオーバーヘッドは手続きや関数の構文の違いからくるもの
だけではないでしょうね。端的な例として出したまで。

結局、「オーバーヘッド」を起こしてることが最大の原因であって「最適化の違い」
ではないと主張します。

> 私が「C++の言語仕様は悪い」と言う時は、データ周りの仕組み
> (継承やら、動的／静的束縛やら、型体系やら)の方が中心なんですけど。

あなたとさほど認識の違いはありませんが。

では、あなたはその違いがコンパイル速度に影響を与えているだろうとは思いませんか？

逆にあなたがたは最適化の違いに軸足を置き過ぎていると思いますけどね。

> > 私は最適化は今となってはコンパイラごとの差はほとんどないと思ってます。
>
> GON さんには、コンパイラのアセンブラ出力を読まれる事を是非お勧めします。
> 同じ様な作業を、同じような速度で行なうコード出力でも、コンパイラの実装や
> コンパイルスイッチ一つで全然違うものが出てきます。
> 私も、これをやり始めて認識が変わりました。

> > > # 大体遅いのが嫌なら、速い PC 買うし。

> > > # 生成したコードのスピード／サイズは大問題だけど。
> >
> > ここの感覚が大学の教授とか役人の発想に近いものがありますね。
>
> 「時間を金で買う」というのはビジネス発想そのものなんですが....

費用対効果を考えるのもビジネスの基本なんですけど。

> > わたしはあなたのような大企業で働いてるわけじゃありませんから
> > そんな発想はしません。
>
> ビジネスプランをプレゼンテーションして、有望だと思われれば
> 銀行融資も投資も受けられますよ? (^^)

いくら有望なプランでも大企業と中小企業では銀行の扱いは全然違います。

> あるいは、何らかのライセンスでオープンソース配布して
> 感謝されれば援助してもらえるかも。

そういう希望的観測だけで企業は動きません。

> > わたしならより高速で生産性の良いコンパイラを探しますね。
> > もちろんPCが速いに越したことはありませんがそれでも
> > メモリーにアクセスするスピードはそれほど高速化できません
> > からコンパイル時にメモリーアクセスの多いソースになれば
> > PCをいくら高速化したって大して速くなるとも思えません。
>
> メモリアクセスは高速化できます。現実にどんどん高速化してます。
> 66MHz ===> 100MHz ===> 133MHz ===> 200MHz....
> 「解決すれば金になる」と解れば、金をジャブジャブ注ぎ込んで解決する。
> 本当にビジネスってやつぁ...

なんか勘違いしてるみたいだね。その高速化のためにどれだけ資金が必要となるの？
高速なコンパイラ導入するのとパソコンを全部高速なものに置きかえるのとでは
どちらが費用が少なくて済みますか？

特にメモリアクセス速度の向上はある程度までで頭打ち。しかも速いシステム
を導入するほど何倍も金がかかる。

もちろん、そういったシステムを導入してもおつりがくるくらい儲かるビジネスを
展開しているんなら話は別ですが、中小のソフト屋さんが手掛けているようなものでは
そんな贅沢はできないでしょう。

だから大企業の発想だって言ってるんです。

[Takemoto,Satoshi]

温泉帰りの竹本です。

Hironobu Suzuki wrote:

> G> インタープリタは万能でないわけでコンパイラを完全に使わないでＯＫと
> G> いうことが完全にできない以上コンパイラを必要とすることには変わりあ
> G> りませんね。
>
> Luke, Use the FORTH!

これは「スタックに言語を積む」実装の事ですか?
# だとすると、もはや知らない人の方が圧倒的なような...

リターン命令で次の処理に飛び、
スタックポインタから引き算してループをすると。
--
竹本 聡 ソニー(株)PNC,PVC,DI部門1部

[Takemoto,Satoshi]

竹本です。

GON wrote:

> どうもあなたがたは最適化がC++とDelphiでは違うからコンパイルの速さが違うのだと思い込んで
> いるようですが、Delphiが最適化をきちんとやってない証拠はなにも提示してませんし、今時の
> コンパイラにおいてそれほど最適化の違いが存在するとも思えませんから最適化だけでコンパイル
> 速度の違いを説明しようとするのにはかなり無理がある感じがします。

最適化による速度の違いは相当有ります。少なくともコンパイル速度は
違います。ソースコード、中間生成コード、生成したコードのいずれかに
ついて、少なくとも数回スキャンして解析をかけるわけですから、
時間がかかって当然です。
時間かければ良いってもんでも無いが。

> 結局、「オーバーヘッド」を起こしてることが最大の原因であって「最適化の違い」
> ではないと主張します。

このスレッドの藤枝さんの記事を見ていると、DelphiとBCの比較ではそうです
ね。
ただ、「こんなに時間かけて何やってんだろ?」て思うほどコンパイル時間が
かかるコンパイラも有ります。
Watcom-C なんかはそうだった。「wcc -oneatx -5r」とかやるともう...

> では、あなたはその違いがコンパイル速度に影響を与えているだろうとは思いませんか？

影響は有ります。
でも最適化の寄与を押えて、コンパイル速度に支配的に効くとは思いません。

> 逆にあなたがたは最適化の違いに軸足を置き過ぎていると思いますけどね。

置いてます。10年くらい前から徐々に軸足が移ってきて、これから更に
重心がかかって行くと思います。(^^)

昔(5年くらい前)までは、PCレベルのコンパイラでは最適化と言っても大した事
は
やってませんでした。でも、ここ5年くらいは各社とも最適化はかなり進歩して
来ています。今は小康状態です。需要が有ると思えば、どこかがまた
最適化競争を仕掛けて来るでしょう。ネタは沢山有る。

C++と、その他の言語に差が出るというのは、別にC++が最適化し易いという
訳では無く、単に今もっとも利用者が多いからというだけです。
昔は Fortran の最適化の方が C よりも手がこんでいたし、
これからは C の部分よりも C++ 固有の部分の方に、どんどん新しい技法が
入って行くんでしょう。

> > 「時間を金で買う」というのはビジネス発想そのものなんですが....
>
> 費用対効果を考えるのもビジネスの基本なんですけど。

２つ反論が有ります。

人件費(特にプログラマの)というのは、結構高いコストです。
しかも開発毎に、必ず(毎日)発生します。
PC環境は一度買ったら暫く(１年くらい)は投資しなくて良い。

それから、マーケット投入のタイミングも大事です。
メーカは基本的に競争していますから、機会喪失のコストが考慮されると、
費用対効果のバランスが激変して「時間を金で...」となるわけです。

それからもうひとつ、既に特定のコンパイラで開発した資産がある場合、
移行コストも考慮すると2の足を踏むというのは有りがちな事と思います。
PCを換えるのは、それに比べれば面倒が少ない。

海外のパッケージソフトはバージョンアップ毎にスクラッチから書き直すと
どこかに書いてあったけど、日本でもそうなんでしょうか?
私のいた(いる)職場では、そんな事はまずしなかった(しない)けど。

> > > わたしはあなたのような大企業で働いてるわけじゃありませんから
> > > そんな発想はしません。
> >
> > ビジネスプランをプレゼンテーションして、有望だと思われれば
> > 銀行融資も投資も受けられますよ? (^^)
>
> いくら有望なプランでも大企業と中小企業では銀行の扱いは全然違います。

それはそうです。# オイオイ
そうでなければ、大企業であるメリットが無く、巨体を維持していけません。
競争と淘汰を生き残ってきたからこその信用ですし。

ま、私個人を指差して「他力本願だ」といわれれば、反論はできません。(^o^)
# 居直ってどうする...(^^;

ただ海外のVCなんか向けにWeb上でプレゼンするとなれば、また話は別。
良いものは良いと認めてくれると思う。今は厳しくなってきたけど。

> > あるいは、何らかのライセンスでオープンソース配布して
> > 感謝されれば援助してもらえるかも。
>
> そういう希望的観測だけで企業は動きません。

東洋ナントカさんとか、やまだナントカさんみたいですね。
ま、私の発言も無責任かも知れないですね。周りを見渡しても
そんな Risk Taker はいないか。

> なんか勘違いしてるみたいだね。その高速化のためにどれだけ資金が必要となるの？
> 高速なコンパイラ導入するのとパソコンを全部高速なものに置きかえるのとでは
> どちらが費用が少なくて済みますか？

それは微妙です。PCの値段の下がり方に比べ、
コンパイラの価格はなかなか下がりません。市場の規模が違うからでしょう。
同じ仕様のハードなら、まとめ買いのディスカウントも効きますし。

> 特にメモリアクセス速度の向上はある程度までで頭打ち。しかも速いシステム
> を導入するほど何倍も金がかかる。

何倍は大袈裟。しかも、そのうちクラス(価格帯)が下がってくる。
メモリ周り(FSBとか2次キャッシュとか)は、力技(量産効果)が通用し易いし。

> もちろん、そういったシステムを導入してもおつりがくるくらい儲かるビジネスを
> 展開しているんなら話は別ですが、中小のソフト屋さんが手掛けているようなものでは
> そんな贅沢はできないでしょう。

エントリーモデルのPC「に」更新するのも贅沢なんでしょうか?
例えば、５年くらい使ってきた Pentium 100MHz (FSB 66MHz) のマシンを
Pentium III 600MHz (FSB 100MHz)に換えたりするのも贅沢なんですかね?

リースにすれば、もっと安くできるし。

> だから大企業の発想だって言ってるんです。

へ?「学者や役人の発想」じゃなかったっけ?
ソニーに勤めている人にしては....って言われたから反論したんだけど。

# そうか、「ソニーなんか中小企業だ!」て言いたいのね?(^^;
# それは失礼いたしました。
--
竹本 聡 ソニー(株)PNC,PVC,DI部門1部

[Nakamura Akifumi]

中村暁史っす。

fj.soc.economy,japan.jiji,fj.comp.misc の <8rt818$n4d$1...@nw041.infoweb.ne.jp> の
記事において 2000年10月10日(火) 04時58分34秒頃、
"GON" <opens...@hotmail.com>さんは書きました。

>オーバーヘッドを理解する上では最も視覚的に理解しやすいだろうと思って例に出したまで
>。
>もちろんクラス継承の違いからくる実装の仕方の違い等いろいろありますが、細かいこと言
>うと
>判りづらくなるだけですから

その程度の「視覚的に理解しやす」さを求めてもしょーがないっていうか、
少なくともそんな砂糖をまぶさなくても理解できる人は
(少なくとも今回)多数いたようですっていうか。

その程度、判るって。

>どうもあなたがたは最適化がC++とDelphiでは違うからコンパイルの速さが違うのだと思い
>込んで
>いるようですが、

そうか？

> 今時の
>コンパイラにおいてそれほど最適化の違いが存在するとも思えませんから

なぜそんなことが言える？
「今時」っていうパラメータには、なんの価値もナイやんか。
俺が、誰にも構って貰えないくらい質の低い(笑)コンパイラを
作ったとしても、それも「今時」やんか。

＃親方日の丸主義か？「今時のコンパイラ」などという親方。

>結局、「オーバーヘッド」を起こしてることが最大の原因であって「最適化の違い」
>ではないと主張します。

どうやって定量的に測れるの？

>> 「時間を金で買う」というのはビジネス発想そのものなんですが....
>費用対効果を考えるのもビジネスの基本なんですけど。

だから、「金で買ってでも時間が欲しいときは」そうする、っていうだけの話。

>いくら有望なプランでも大企業と中小企業では銀行の扱いは全然違います。

そう思いたければ思っていてちょ。

>なんか勘違いしてるみたいだね。その高速化のためにどれだけ資金が必要となるの？
>高速なコンパイラ導入するのとパソコンを全部高速なものに置きかえるのとでは
>どちらが費用が少なくて済みますか？

高速なコンパイラって奴が、1CPUあたりナンボのライセンスだったら、
馬鹿にならない金を費やすことも有りそうですけど。

＃残念なことだけど、やっぱりDelphiのEnterprise版は、高いと思うよ(t_t)

>だから大企業の発想だって言ってるんです。

そうねえ。零細の発想やねえ。俺んとこもそうかな。
んで、どんどん「ジリ貧」になっていくのな。
より「まとも」な発想を選択せずに、
より「安易」な発想を選択するもんだから、
目先の仕事はこなせても…以下略…

[HAMAI Kyoichi]

In article <20001005203...@nifty.ne.jp>,
BXQ0...@nifty.ne.jp says...

>プログラム部品の市場(市場かfreeかは直接は俺の関心事じゃないけど)が
>育たないのだとすれば、その一因は、その(?)OS上で、部品が
>気持ち良く存在しにくいようになってるせい、かな、とは思います。

プログラム部品の市場が育たないのは、ソフトウェア(プログラム)の
製造がコピーであり、そのコストがほぼゼロだからですね。
ソフトウェアでは、完成品をコピーすればよく、ハードウェアのように
製品毎に、部品を作り、その部品を組み上げる、というような必要は
ありません。ある部品を作ることに特化して生産性をあげる余地が
ほとんどありません。
--
<hm6k...@asahi-net.or.jp>
first base をホームベースと呼びますか?
単なる web page をホームページと呼びますか?

[Shiroh Sado]

佐渡です。

横からつっこんで申し訳ないですが。

スレッド「Re: Ａｐｐｌｅ株大暴落」での
hm6k...@asahi-net.or.jp氏の発言 <8s04a6$hek$3...@father.asahi-net.or.jp> より引用

>> In article <20001005203...@nifty.ne.jp>,
>> BXQ0...@nifty.ne.jp says...
>>
>> >プログラム部品の市場(市場かfreeかは直接は俺の関心事じゃないけど)が
>> >育たないのだとすれば、その一因は、その(?)OS上で、部品が
>> >気持ち良く存在しにくいようになってるせい、かな、とは思います。
>>
>> プログラム部品の市場が育たないのは、ソフトウェア(プログラム)の
>> 製造がコピーであり、そのコストがほぼゼロだからですね。

「プログラム部品」が何のことを指すのか知りませんが、
「育たない」(育っていない?)と言い切っちゃうのは、誤
解を招かないですか?

たとえば、現在、「なんとかクラスライブラリ」って、
相当に多いですよね?
# 「プログラム部品」の例は他にありそうですが、
# すぐに思い付いたのはこれだったんで。

で、続く部分を読んで考えたのですが、

>> ソフトウェアでは、完成品をコピーすればよく、ハードウェアのように
>> 製品毎に、部品を作り、その部品を組み上げる、というような必要は
>> ありません。ある部品を作ることに特化して生産性をあげる余地が
>> ほとんどありません。

上記6行を踏まえると、

・このため、プログラム部品はプログラム完成品(または
プログラム部品)を作る人(プログラムを作る人)のみに
しか、需要が無い。

・アプリケーションソフトの市場が犬成長しているのに比
べて、相対的に小さく見えてしまう

ために、「プログラム部品の市場が育」っていないように
見える場合がある、ということなのでしょうか。

それとも、本当に、コンパイラベンダの用意したプログラ
ムの部品以外は、使われていなくて、市場は育っていない
のでしょうか。