アカウント名:
パスワード:
でもc.mos氏ってアンチLinux派だったような……
以前アスキー誌のLinux特集でインタビューを集めていて、c.mos氏と秀まるお氏はアンチ派として載っていました。
「やっとMFC覚えたのにまた別のAPI覚えなきゃいけないわけ？」（記憶に基づく要約）とかそんな話だったような。
ここで挙げられている対談記事は1999年のものなのに 今の事情を前提にして話をするのはどうだろう？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
VCさん、対抗してぜひVz for Linuxを (スコア:1)
そういえばXzはどうなってしまったのかなあ?
いつのまにかwebから消えてますね。
頼む相手は (スコア:2, すばらしい洞察)
もし c.mos 氏ではない作者が作った Ｖz for Linux とうたったエディタをVCさんが出しても、
「Ｖz」を名乗るだけの物がないと受け入れられないと思います。
Re:頼む相手は (スコア:0)
でもc.mos氏ってアンチLinux派だったような……
以前アスキー誌のLinux特集でインタビューを集めていて、c.mos氏と秀まるお氏はアンチ派として載っていました。
「やっとMFC覚えたのにまた別のAPI覚えなきゃいけないわけ？」（記憶に基づく要約）とかそんな話だったような。
Re:頼む相手は (スコア:3, 興味深い)
これですね↓
私に言わせろLinux! (7) 鴨志田 睦、斉藤 秀夫、兵藤 嘉彦 [ascii24.com]
Re:頼む相手は (スコア:1)
# 違うページに、Oliver氏の写真を見つけてびっくり。
ゆーへん
Re:頼む相手は (スコア:1)
APIとか、そういう目でしか見れないってのは、たしかにがっかりかも。
X覚えるのはウザイとは思うが、なにもそういう底辺の部分を覚えないとならんわけじゃないだろうに。
もっと上位のどれかのGUIライブラリを使えばいいんであって。
makefileを手で？久しくそんなことしたことないぞ。
依存関係を抽出するツールだって有ろうし、makefileを自動生成するツールだって。
単にそれらがVCみたいな1つのパッケージ製品になってないというだけ。
C(++)からしかモノを見ないと、そういうつまらない所で躓くのだろうな。
例えば(今なら)DelphiとKylixででも作れば解脱できようて。
あるいは各種のLightWeightLangを。今の馬鹿みたいに高速なCPUは、
C言語を使う必要性を最小限に抑えるためにある、んだよねえ？
余談：
OfficeもOpenOfficeが出てきたわけだし。なんか安心だな。
個人的に不測を感じる点は1つだけ、ソフト間の連携能力だ。
Pipeは論外として、それ以外のモダンな手法が結局固まってないのが
(大袈裟なライブラリを持ち歩かずにアプリを実現することが面倒になるので)痛い。
Re:頼む相手は (スコア:1)
>もっと上位のどれかのGUIライブラリを使えばいいんであって。
しかし、VZも秀丸も、「そういう底辺の部分」から作ってきたから
あれだけの信頼と評判のあるものに育ったんではなく？
あれだけ、は、この場合、あの程度しか、とも言えるかもしれないけど。
4年前の記事を今の状況で語るのは問題 (スコア:0)
今の事情を前提にして話をするのはどうだろう？
1999年4月というと、GNOME1.0が出た直後くらいでは？
Re:頼む相手は (スコア:0)
アンチになるのも納得できるわな(w
Re:4年前の記事を今の状況で語るのは問題 (スコア:1)
>今の事情を前提にして話をするのはどうだろう？
たった4年しか違わないです。
4年の間に「実装は」確かに色々進みましたが、「原理は」出揃ってなかったわけじゃないでしょう。
それこそ例えば(Pipe以外のソフト接続手段を擁した)Windowsは既に有りました。
DelphiやJavaは95年から有るし。
あと最初のRuby本は何年だっけ？ちょうどそれ(前世紀末)くらいだったような。
それにもちろん、LightWeightLangの歴史がRubyから始まったわけじゃなく、もっと大昔から有ったわけで。
Re:4年前の記事を今の状況で語るのは問題 (スコア:0)
手で書く時代から、Makefile.inを手で書く時代へと変
わっていった頃だよね。(笑
Re:頼む相手は (スコア:1)
>あれだけの信頼と評判のあるものに育ったんではなく？
少なくとも、自前ライブラリ(だよね)を使ってることと、完成品であるエディタの信頼や評判とは、ほぼ無関係では？
余談：
信頼できる(^^;ライブラリを公開(しかも願わくばOpenSourceで)してくれていたなら、我々は幸せになったんでしょうか？
うーん。「実際見てみて信頼できるものだったならば」それはTRUEでしょうね。
Re:頼む相手は (スコア:1)
まあ、彼らは、しないでしょうね(^^;
Cこそが自分の「(社会的に)生きる」道だと思っているのかなと。
Re:頼む相手は (スコア:1)
なにかランタイムライブラリを使っているとき、
あるプログラムそのものはセキュアに作ったつもりでも、
そちらのライブラリの穴をつかれて攻められる、とか、
ランタイムライブラリのアップデートでソフトそのものが不安定になる、とか、
そういうことが何度も起こっているのを見ると、
ランタイムライブラリではなく、
たぶんこれは出来合いのライブラリを内包して作っても
同じ問題が出るかなあ、と思ったりするが、そういうことはない？
まあどこまで信頼するかってところになっちゃうけど。
(極論しちゃうと、WIN APIすら信じられなくなるだろうし。)
Re:頼む相手は (スコア:1)
品質がたまたま良かったから、ですよね。評価される理由が有るのならば。
>まあどこまで信頼するかってところになっちゃうけど。
>(極論しちゃうと、WIN APIすら信じられなくなるだろうし。)
極論じゃなく実際そうなんじゃないかと。
それはともかく、もし、「ライブラリ」が例えば「VB用DLL」とかのことしか指さないならば、
「比較対象が悪すぎるだけでは?」としか思えないです。
全てのライブラリが、自分(個々のユーザ)が見たことがある少数のライブラリと、
本質的に同じ品質だと思われたりしてないだろうか？と、時折不安になります。
＃DelphiじゃFree(しばしばOpenSource)のComponentでしばしば幸せにしてもらえたのでG7
＃VBまたはVCで苦しんでる連中を横目で見ながら、すいすいと…
Re:頼む相手は (スコア:1)
あれだけ、は、この場合、あの程度しか、とも言えるかもしれないけど。 [srad.jp]
と、いうことで。
>それはともかく、もし、「ライブラリ」が例えば「VB用DLL」とかのことしか指さないならば、
MFC42.dllとかっていうDLLによって動作に不具合が起きた、
っていう話を聞いたことがあります。(自分には起こらなかったけど)
VCの話?
あと、外部のリソースに存在する脆弱性については、BINDの脆弱性 [cnet.com]つうのもありました。
どこまで気にするか、だというのはわかりますが、
使っている側よりも、
作っている側の方が気になってしまう問題なんじゃないかと。
そのうえ、エディタについては、どこぞのコンポーネントで
作ったものは、そのコンポーネントで実現できる以上の性能は
期待できないわけですから、いきおい自作になると思うんですが。
個人的に使うプログラムでは、
ライブラリとかコンポーネントとかそういうコトに関しては、
こちらもヘタレであんまりもの考えていないスクリプト作りを
しているがゆえに、いろいろ便利に使わせてもらってます。
＃ルーラー表示のできるテキスト表示コンポーネントとかって
＃DELPHIあたりだとどの辺から探せるんでしょうか?(オフトピ)
Re:頼む相手は (スコア:0)
俺はやらない、というのも個人の判断だし、
どんな環境でもかまわずやっちまうんだぜ、というのも個人の判断。
#「ウホッ！いい技術…」と思うとホイホイついていってしまうのでAC