余談ですが
Y.MINAMI
Takahide Nojimaさんの<m3wubh4...@nightmare.hm.taito.co.jp>から
>
>(若造曰く)
>今時IDEを使えない環境しか無い人って大変だ
>とふと思いました...
(ジジイ曰く)
IDEを使わなきゃやってられないようなプログラミングは何か
嫌じゃ、と思ったりして。
＃なので最近のプログラミングってのには全く興味が湧かん(^^;
----
みなみ＠見た目の印象だけでJava,C言語,Perlは嫌い(ダメだコリャ)
Takahide Nojima
"Y.MINAMI" <ymi...@mail.sf.airnet.ne.jp> writes:
> (ジジイ曰く)
> IDEを使わなきゃやってられないようなプログラミングは何か
> 嫌じゃ、と思ったりして。
> ＃なので最近のプログラミングってのには全く興味が湧かん(^^;
自分はIDE/CASE/CAD/GUI/特定分野専用言語万歳の人です。
やっぱりグループで開発/研究/実験が流行だと思うので、
スケジュール管理／UML描画／更新履歴管理／情報共有機構も搭載
したものが良いと思ってます。
もちろんプログラムはソースファイルの形式でなくても構わず、
プロジェクトファイル等の形でpackされていても何とも思いません。
もちろん後で移植可能な形のデータにばらせるのが良いです。
理想を言えば、コンピュータの素人さん相手でも
・これらツールがガンガン補助してくれたり、
・豊富な雛型が用意されているので、下手するとカット＆コピーだけでも
・しまいには、マウス操作だけでも、
要求仕様を満たせたりできたらいいと思います。ツールで絵を書けば特定分野の
プログラムぐらい自動で生成して欲しいと思うこのごろ。
シグネチャに返答はまずいかもしれませんが、
> みなみ＠見た目の印象だけでJava,C言語,Perlは嫌い(ダメだコリャ)
言語以前にプログラム書かなくて済むならそっちがいいです。
自分は限りなくプログラム書かなくて済む言語/環境が大好きです。
＃でも理想から遠い部分が現実にはあるので、仕方無いからプログラム書く...
Y.MINAMI
>
>要求仕様を満たせたりできたらいいと思います。ツールで絵を書けば特定分野の
>プログラムぐらい自動で生成して欲しいと思うこのごろ。
それは理想的な形だとは思いますし、いつかそうなるのかもしれませんが、
現実のIDEはディスクやらメモリやらCPUをドカ食いしたり(自分のマシンで
はForte起動しようとすると、暫～く待たされます ~~;)、関係あるんだか
ないんだか良く判らないライブラリまでリンクしてくれたりで。(リソース
喰うのが普及すればそれだけ売上は増える、と嬉しがる人もいますが ^^)
>自分は限りなくプログラム書かなくて済む言語/環境が大好きです。
私の場合は「軽くて手に馴染む」・「ぱっと見でも中身が判る」かが判断
ポイントですね。
----
みなみ＠signatureへの突っ込みOKです :-)
Shinji KONO
In article <blvove$cbm$1...@caraway.media.kyoto-u.ac.jp>, "Y.MINAMI" <ymi...@mail.sf.airnet.ne.jp> writes
> >自分は限りなくプログラム書かなくて済む言語/環境が大好きです。
> 私の場合は「軽くて手に馴染む」・「ぱっと見でも中身が判る」かが判断
> ポイントですね。
それって結局...
IDEはプログラムを書かない奴のため
プログラムを書く奴はvi
ってこと?!
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
河野真治 @ 琉球大学工学部情報工学科,
Y.MINAMI
Shinji KONOさんの<3989066...@insigna.ie.u-ryukyu.ac.jp>から
>
>それって結局...
> IDEはプログラムを書かない奴のため
> プログラムを書く奴はvi
>ってこと?!
ハンド・コーディングしないと落ち着かない or プログラミングした
気にならないのがvi,emacs,ISPF、それはどーでもいいのがIDEの方が
正確なような気が
＃だからviな人もABCはOKではないかと
----
みなみ＠「車輪の再発明」の危険性はviの方が高いかな?
Takahide Nojima
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> In article <blvove$cbm$1...@caraway.media.kyoto-u.ac.jp>, "Y.MINAMI" <ymi...@mail.sf.airnet.ne.jp> writes
> > >自分は限りなくプログラム書かなくて済む言語/環境が大好きです。
> > 私の場合は「軽くて手に馴染む」・「ぱっと見でも中身が判る」かが判断
> > ポイントですね。
>
> それって結局...
>
> IDEはプログラムを書かない奴のため
> プログラムを書く奴はvi
>
> ってこと?!
究極的に言えは自分にはそうですね。どうしてもプログラムを書かかざるを
得ないのなら、
1. 至り尽せりな環境で出来るだけ楽をしたい
2. 素人さんでも出来て欲しい
と思うこのごろです。
プログラムって、コンピュータに言うこときかす為の手段ですから、
そういった手間は極力少ないに越したことはないと思っています。
IDEはその方向で進化してほしいと個人的には思ってます。
プログラムは別に、絵でも、声でも、表情でも画像でもいいなぁと思うこのごろ。
1. 物事を順序だてて説明できる人であれば誰でもコンピュータは
使いこなせるような世の中に早くなってほしいなあと、
2. バッファオーバーフローとかが起きるような状況はこの世から
早く消えて欲しいなあと
思ってます。（直接Perl/Python/Rubyぐらい解釈してくれるCPUがほしい）
最近、
「何故コンピュータにいうこときかすのに問題解決の本質以外の知識が必要な
状態が終りを告げるのはいつだろうふ」
と思ってます。
Takahide Nojima
"Y.MINAMI" <ymi...@mail.sf.airnet.ne.jp> writes:
>「車輪の再発明」の危険性はviの方が高いかな?
車輪の再発明については、分野にもよると思いますが、何しても出血大サービスで
ありまくりじゃないかと...
freshmeat.netとかCPANとかsourceforgeとか見ると、自分が今作り中のコードは、
・もしかしたらすでに誰かつくってるんじゃないか？
・下手すると手元のRedHatのCDROMにも入ってるんじゃないか？
・人のOSSなプログラムちょっと改造した方が早いんじゃないか？
・人のOSSなプログラムからカット＆ペーストした方が早いんじゃないか？
と、いつもビクビクドキドキビクビクドキドキ...
＃自分のマシンのRHLの/usr/share/docの膨大な量のライブラリのドキュメントを見て
＃いつもビクビクドキドキビクビクドキドキ...
Takuya KUDO
"Y.MINAMI" <ymi...@mail.sf.airnet.ne.jp> さん writes:
> IDEを使わなきゃやってられないようなプログラミングは何か
> 嫌じゃ、と思ったりして。
ほんとウンザリです。
早く IDE からおさらばしてコマンドライン一発で make World
できるようになれば良いのですが・・・。
==
E-mail: ku...@astec.co.jp
Takuya KUDO ASTEC, Inc.
Takahide Nojima
Takuya KUDO <ku...@astec.co.jp> writes:
> "Y.MINAMI" <ymi...@mail.sf.airnet.ne.jp> さん writes:
> > IDEを使わなきゃやってられないようなプログラミングは何か
> > 嫌じゃ、と思ったりして。
>
> ほんとウンザリです。
>
> 早く IDE からおさらばしてコマンドライン一発で make World
> できるようになれば良いのですが・・・。
実は、自分はmakefileもmakeも嫌い。
理想はF5だけ押せば自動で全部コンパイル。依存関係はソースからIDEが全て読
みとって、よきにはからってくれないかなーと。IDEでソースファイル
編集している間に、バックグラウンドでソースを解析してくれてて、
makefileぐらいIDEが自動でつくってくれたらなぁと...
Takuya KUDO
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) さん writes:
> プログラムを書く奴はvi
私も vi 派ですね。
はるか昔、世に 32bit Windows が初めて出たとき、最初にしたのが
vi like editor の移植です。
xvi をベースに quick hack して 32 bit Windows ネイティブで動作
するようしました。
機能は至ってシンプルで
80x25 固定
カット＆ペーストできません
日本語読めません
今でもそのエディターを愛用しています(笑)。
P.S.
後、良く使う editor はメモ帳ですね。
日本語の読み書きとカット＆ペーストができますから・・・。
Yoshitaka Ikeda
キャラクタインターフェースのShellが嫌いなだけなんじゃぁ....
VisualC++なんかは、（それ専用の）makefileを書き出してくれる機能ありま
すよね。NMAKEだっけ。
作るプログラムのターゲットによって、人それぞれ変わると思うんですよ。
VB使って、コントロールならべて、ちょちょっとコーディングすれば終わり
なんてのは、ある意味気楽なのは確かなんですよね。それを極端に押し進める
と、FLASHとかDirectorとかHyperCardになっちゃうんじゃないかなぁ。
それと全然違うところで、たとえばカーネルの開発とかあるわけで、
カーネルの開発はIDE使うことでなんかメリットがあるかっていうと
あんまり必要性は感じません。 って所じゃないかなぁ。と
--
池田 尚隆(Yoshitaka Ikeda) mailto:ik...@4bn.ne.jp
Takuya KUDO
Yoshitaka Ikeda <ik...@4bn.ne.jp> さん writes:
> それと全然違うところで、たとえばカーネルの開発とかあるわけで、
> カーネルの開発はIDE使うことでなんかメリットがあるかっていうと
> あんまり必要性は感じません。 って所じゃないかなぁ。と
というか全く必要ありません。
デバイスドライバの開発やカーネルの構築に関して言えば IDE は時間と
ハードウェアリソースの浪費になるだけでメリットは全くありません。
#
# つい昨日 IDE の遅さに耐えられず、メモリーを増設しました。
# お金で解決できるならそれで良し・・・。
#
Hideo Sir MaNMOS Morishita
はっきり言ってIDE使っても何のメリットもない仕事をしている森下 お代官様
ＭａＮＭＯＳです。
In article <bm0erh$bbi$1...@nn-tk105.ocn.ad.jp>,
Yoshitaka Ikeda <ik...@4bn.ne.jp> writes:
> From <m3zngce...@nightmare.hm.taito.co.jp> Written by Takahide Nojima
> >nojimaです。
> >
> > 理想はF5だけ押せば自動で全部コンパイル。依存関係はソースからIDEが全て読
> >みとって、よきにはからってくれないかなーと。IDEでソースファイル
> >編集している間に、バックグラウンドでソースを解析してくれてて、
> >makefileぐらいIDEが自動でつくってくれたらなぁと...
>
> キャラクタインターフェースのShellが嫌いなだけなんじゃぁ....
私はどっちかって言うと、マウスやファンクションキーを使うことが嫌い。
(HHKだし)
結局、複雑なアルゴリズムなどを記述しようと思うと、多くをキーボードから
入力をせざるをえないわけで、そのたびにホームポジションから手をはなすな
んて思考をとぎれさすだけです。
> VisualC++なんかは、（それ専用の）makefileを書き出してくれる機能ありま
> すよね。NMAKEだっけ。
自分でテキストベースで開発するときでも、ソースやMakefileはテンプレート
をつくって、スクリプトやそれ専用のプログラムジェネレータをつくるのは当
たり前の作業でしょう。
＃でなきゃ、Cのソースだけで何10MBもあるシステムなんてやってられません。
> それと全然違うところで、たとえばカーネルの開発とかあるわけで、
> カーネルの開発はIDE使うことでなんかメリットがあるかっていうと
> あんまり必要性は感じません。 って所じゃないかなぁ。と
daemonもそうです。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
Takuya KUDO
#
# 今日は現実逃避モードです。
#
man...@stellar.co.jp (Hideo "Sir MaNMOS" Morishita) さん writes:
> (HHKだし)
私は、自宅、会社、共に FKB 8579-USB です。
初代 HHK はキータッチが良いみたいですが HHK2 Lite は安物っぽくて
好きではありませんでした。
Takahide Nojima
Yoshitaka Ikeda <ik...@4bn.ne.jp> writes:
> > 理想はF5だけ押せば自動で全部コンパイル。依存関係はソースからIDEが全て読
> >みとって、よきにはからってくれないかなーと。IDEでソースファイル
> >編集している間に、バックグラウンドでソースを解析してくれてて、
> >makefileぐらいIDEが自動でつくってくれたらなぁと...
>
> キャラクタインターフェースのShellが嫌いなだけなんじゃぁ....
あのmakefileを手で作るという作業が嫌いなのです。
＃ スクリプト言語によるプログラム万歳！
> 作るプログラムのターゲットによって、人それぞれ変わると思うんですよ。
> VB使って、コントロールならべて、ちょちょっとコーディングすれば終わり
> なんてのは、ある意味気楽なのは確かなんですよね。それを極端に押し進める
> と、FLASHとかDirectorとかHyperCardになっちゃうんじゃないかなぁ。
ええ、FLASHの環境は凄いと思いました。
＃ CADによるプログラム万歳！
> それと全然違うところで、たとえばカーネルの開発とかあるわけで、
> カーネルの開発はIDE使うことでなんかメリットがあるかっていうと
> あんまり必要性は感じません。 って所じゃないかなぁ。と
うーん、
・GNU global程度のソースナビゲーション機能とか、リアルタイムの
クロスリファレンサとか
・ターゲットシステムのエミュレータとか、
・履歴管理機能との統合とか、
・カーネルデバッガ
・静的ソースに関するlint機能（ソース書いてる最中でのバックグラウンドで
コーディングルールに反するコードがあると指摘する等）
・メモリプロファイラ、実行プロファイラ等
・コア解析プログラム
・カーネル内部のサービス関数についてのオンラインマニュアル／検索、
コード上で直接説明文の参照
・状態遷移／データドリブン／イベントドリブンについてはCADとCASEツール
・IRC等
...etc...
が連動はあった方が良いような...
＃ばらばらのツールを寄せ集めれた状態では存在するんですよね..
＃UNIX+Emacsとか...
R4000 2.2
＃酔っ払いのチャチャにしかならない気がしますが、、、
Takahide Nojima <noj...@taito.co.jp> writes:
> > キャラクタインターフェースのShellが嫌いなだけなんじゃぁ....
DOSプロンプトだけだと嫌いになりそうな。
＃私も大っ嫌い
> あのmakefileを手で作るという作業が嫌いなのです。
その気持はわからなくもないです。
> ＃ スクリプト言語によるプログラム万歳！
IDE じゃないですけど、以前の仕事はGUIまわりは Tclとその拡張で
できたインタプリタで事が済んでてしあわせでした。
> ＃ CADによるプログラム万歳！
UMLとかER図とかが絵で書けるってのがいいってことでしょうか。
> ・GNU global程度のソースナビゲーション機能とか、リアルタイムの
> クロスリファレンサとか
>
> ・ターゲットシステムのエミュレータとか、
>
> ・履歴管理機能との統合とか、
このへんは IDE の威力が大きそうですね。
> ・カーネルデバッガ
これを IDE てのは所詮無理があるんじゃあ。
> ・静的ソースに関するlint機能（ソース書いてる最中でのバックグラウンドで
> コーディングルールに反するコードがあると指摘する等）
これは IDE でやってもらえそうですね。
> ・メモリプロファイラ、実行プロファイラ等
IDE というか、もちょっと別かも。
＃ purify のうじゃっと出たログに圧倒された記憶がたびたび
どこに着目してどうみるんじゃい、てとこをうまく押えられると
いいんでしょうねぇ。
「UNIXシステムチューニング」とか斜め読みして、やっぱり圧倒された
記憶しかないもので。。。
> ・コア解析プログラム
どうでしょうねぇ。
> ・カーネル内部のサービス関数についてのオンラインマニュアル／検索、
> コード上で直接説明文の参照
ふだん、VC++ と MSDNヘルプとにらめっこしてますが、いまのわたしには
あまり役に立たないです。
＃説明してある概念が把握できてない
> ・状態遷移／データドリブン／イベントドリブンについてはCADとCASEツール
前述の「CADによる...」ですか。
> ・IRC等
要りますか？
--
ta...@kc5.so-net.ne.jp 立花 晃＠鎌ヶ谷市
Shinji KONO
In article <m3n0ccd...@nightmare.hm.taito.co.jp>, Takahide Nojima <noj...@taito.co.jp> writes
> ＃ スクリプト言語によるプログラム万歳！
なんか、Perl のプログラムをIDEで作るってのを連想してしまった...
> ・GNU global程度のソースナビゲーション機能とか、リアルタイムの
> クロスリファレンサとか
gdb とか linux kernel とか gcc をとかのcross reference って
全然役に立たない.... indirect callの塊だからなぁ。
> ・静的ソースに関するlint機能（ソース書いてる最中でのバックグラウンドで
> コーディングルールに反するコードがあると指摘する等）
ちょっと Word のスペルミスの訂正を連想しますな。
> ...etc...
> が連動はあった方が良いような...
> ＃ばらばらのツールを寄せ集めれた状態では存在するんですよね..
> ＃UNIX+Emacsとか...
そうなんだけど...
その連係を作ること自体がプログラミングで、既に連係が出来ている
場合って、実は「似たようなものを作っている」時なんだよね。
Compiler 用のIDEみたいなのがあるとうれしいかな。生成したコード
のエラーから、生成したCompilerのコードの部分を指摘してくれるみたいな...
Y.MINAMI
>
>（直接Perl/Python/Rubyぐらい解釈してくれるCPUがほしい）
十ん年前には「高級言語マシン」ってことで、そのようなノリのもあり
ましたが(ちょうどRISCの普及とかち合っていたかな)、CHI,Facom α,
PSI,ELISは既になく、Symbolics,LMIは会社そのものが消滅。
商用で手を出す人はもういないかも。
----
みなみ
Yasushi Shinjo
In article <m3oewt4e...@nightmare.hm.taito.co.jp>
Takahide Nojima <noj...@taito.co.jp> writes:
> 理想を言えば、コンピュータの素人さん相手でも
素人がプログラミングをするのは、無理だとはっきりさせてもいい
んじゃないかなあ。
この間、BSDCon という会議に出たのですが、その Keynote speach
で、computing is easy というのは、誤信だという話がありました。
「ＯＯＯ for dummies」とか本のタイトルのＯＯＯの所に「橋の設
計」とか「外科手術」とか入れてウケていました。それはその通り
ですよね。プログラミングは難しいということは、はっきり認めて
いいと思います。
http://www.usenix.org/events/bsdcon03/tech.html#keynote
IDE (Integrated Development Environment) ですが、プログラミ
ングとは、実はあんまり関係ないんじゃないかなあ。数年前に見た
のですが、IDE (Visual C++) は使えるけれど、プログラミングは
全然だめという人がいました。その人は、IDE という道具が使える
ので、自分はプログラミングができると完全に勘違いしていました。
> ・これらツールがガンガン補助してくれたり、
> ・豊富な雛型が用意されているので、下手するとカット＆コピーだけでも
> ・しまいには、マウス操作だけでも、
> 要求仕様を満たせたりできたらいいと思います。ツールで絵を書けば特定分野の
> プログラムぐらい自動で生成して欲しいと思うこのごろ。
そうですか。素人が絵を描いて作ったジャンボジェット機に乗る気
は、私は全然しません。
IDE って、どのくらいのスケーラビリティがあるんでしょうね。画
面に 10 枚くらいファイルを開いたらもう辛いんじゃないかなあ。
Linux カーネルとか、デバイス・ドライバとかファイル・システム
のぞいても 2300 くらいありました。ファイル個くらいならウイン
ドウ系の IDE で作れるのでしょうか。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
Shinji KONO
In article <YAS.03Oc...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes
> IDE って、どのくらいのスケーラビリティがあるんでしょうね。画
> 面に 10 枚くらいファイルを開いたらもう辛いんじゃないかなあ。
僕が良く言うのは「見える部分のプログラミングはやさしいけど、
見えない部分が重要なんだ」ってのかな。その見えない部分を
サポートしてくれるのが IDE なはずなんだけど...
SPIN みたいな Model checking tool を IDE というかというと...
Yoshitaka Ikeda
From <3989076...@insigna.ie.u-ryukyu.ac.jp> Written by Shinji KONO
>河野真治 @ 琉球大学情報工学です。
>
>In article <YAS.03Oc...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes
>> IDE って、どのくらいのスケーラビリティがあるんでしょうね。画
>> 面に 10 枚くらいファイルを開いたらもう辛いんじゃないかなあ。
>
>僕が良く言うのは「見える部分のプログラミングはやさしいけど、
>見えない部分が重要なんだ」ってのかな。その見えない部分を
>サポートしてくれるのが IDE なはずなんだけど...
>
>SPIN みたいな Model checking tool を IDE というかというと...
オブジェクトができあがっている状態で、そのオブジェクトを配置するのが
IDEの役目であってせいぜいそれがオブジェクトの動作、オブジェクトへの
メッセージを扱うくらいまでの話で、しかもそのオブジェクトが「目に見える
モノ」に殆ど限定されるんじゃないかなぁ。
その具現化がVisualBASICなんかだったりして、オブジェクトでできることの
範囲でプログラミングしている分にはすごく簡単なんだけどそれを逸脱した瞬
間にすごく困難になるというモデルになっちゃうわけです。
結局IDEっていうのは、GUI向けのアプリケーションを組むための方法論の一種
でしか無いのかなぁと思います。まあデバッガが統合されているのが便利と言
えば便利ですが。
Takahide Nojima
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> In article <m3oewt4e...@nightmare.hm.taito.co.jp>
> Takahide Nojima <noj...@taito.co.jp> writes:
> > 理想を言えば、コンピュータの素人さん相手でも
>
> 素人がプログラミングをするのは、無理だとはっきりさせてもいい
> んじゃないかなあ。
いえ、素人さんと環境の組み合わせと問題解決の仕方次第だと思います。
素人さんによる人海戦術はとても大切です。これが出来る出来無いで、
後にドエライ差があらわれます。はい。自分的には職人10人集めるよりも、
職人1人＋素人100人集めてグループで何かさせたほうが総合的に何かと良いことが
多いように感じています。
基本的に、所詮コンピュータといえども、論理だてて処理を機械に
説明する手段がプログラムと思ってます。そのため、
・きちんと筋道たてて説明できる能力があれば、
説明する相手がコンピュータにかわっただけ
なので、特に「プログラムをするということだけ」について言えば、特殊な能力は
いらないのじゃないかと。
もちろんですが、「きちんと筋道たてて説明できる能力」についての才能のある
無しはみとめます...
ただ、コンピュータ環境が悪すぎると、解こうとしている問題の内容以前に、
・ポインタがどうこうだとか、
・環境のバグだとか、
・１ステートメントあたりの機能量が低過ぎるとか、
・融通／気がきかないとか、
等のコンピュータを利用する上での問題の方が大きく、
当初の目的よりも手段に手間を取られ、本末転倒になってしまいがちなような。
本来、理想を言えば、解こうとする分野に関する専門知識の有る無しが問われる
方がよいのではないでしょうか？
> プログラミングは難しいということは、はっきり認めていいと思います。
いえ、これはソフトウェア技術が将来発達すると自動的に解消するものだと
思っています。
> IDE (Integrated Development Environment) ですが、プログラミ
> ングとは、実はあんまり関係ないんじゃないかなあ。数年前に見た
> のですが、IDE (Visual C++) は使えるけれど、プログラミングは
> 全然だめという人がいました。その人は、IDE という道具が使える
> ので、自分はプログラミングができると完全に勘違いしていました。
いえ、それでも成果が上がるなら、そっちの方が私は嬉しい。逆に
その人はどうやって成果をあげているのかを研究したい。
> > ・これらツールがガンガン補助してくれたり、
> > ・豊富な雛型が用意されているので、下手するとカット＆コピーだけでも
> > ・しまいには、マウス操作だけでも、
> > 要求仕様を満たせたりできたらいいと思います。ツールで絵を書けば特定分野の
> > プログラムぐらい自動で生成して欲しいと思うこのごろ。
>
> そうですか。素人が絵を描いて作ったジャンボジェット機に乗る気
> は、私は全然しません。
素人さんが沢山ジェット機を作ってくれることが出来る世の中になるので
あれば自分はそっちが良いですね。現在のテクノロジではまだ高度な技が
必要で無理そうです。
でも素人さんによる大量生産の結果、個人が車のかわりにジェット機を持てる
ような世の中になるなら、そっちの方が自分は嬉しい。
> IDE って、どのくらいのスケーラビリティがあるんでしょうね。画
> 面に 10 枚くらいファイルを開いたらもう辛いんじゃないかなあ。
> Linux カーネルとか、デバイス・ドライバとかファイル・システム
> のぞいても 2300 くらいありました。ファイル個くらいならウイン
> ドウ系の IDE で作れるのでしょうか。
CPUパワーもメモリもHDDも潤沢の方が良いなぁと。
＃器用貧乏はもうたくさん。
Takahide Nojima
Yoshitaka Ikeda <ik...@4bn.ne.jp> writes:
> その具現化がVisualBASICなんかだったりして、オブジェクトでできることの
> 範囲でプログラミングしている分にはすごく簡単なんだけどそれを逸脱した瞬
> 間にすごく困難になるというモデルになっちゃうわけです。
自分は、こちらの方が良いと思ってます。問題を限定（狭く）すれば、
素人さんに少ない教育量で実用レベルのことをさせることが可能になると
いうことです。で、ビジネスチャンスは他のことで求めると。
また、逸脱した問題については、しくみで簡単にすることを一部の極端に
秀でた職人（エリート）がしてくれれば良いことなのです。
この時だけですが、職人の仕事の価値は、対象となる分野のボトルネックを解消し
生産物のアウトプット量を改善するわけですから、ビジネス上ではこの浮いた費用を
支払っても良いぐらいの極端な価値を持つことになります。
職人はそういったことだけしてくれれば自分は嬉しいなあと。ただ、
そうなると彼等職人はプロスポーツと同じ状況になりそうですね。
＃つまり日本トップ十何人ぐらいが極端な収入のエンジニアになり、
＃その他のエンジニアは大変お安い人材になる世界がくるかも。
> 結局IDEっていうのは、GUI向けのアプリケーションを組むための方法論の一種
> でしか無いのかなぁと思います。まあデバッガが統合されているのが便利と言
> えば便利ですが。
自分はeclipseに期待大ってところです。
NAKAMURA Kazushi
noj...@taito.co.jp writes:
> freshmeat.netとかCPANとかsourceforgeとか見ると、自分が今作り中のコードは、
>
>・もしかしたらすでに誰かつくってるんじゃないか？
>
>・下手すると手元のRedHatのCDROMにも入ってるんじゃないか？
>
>・人のOSSなプログラムちょっと改造した方が早いんじゃないか？
>
>・人のOSSなプログラムからカット＆ペーストした方が早いんじゃないか？
>
>と、いつもビクビクドキドキビクビクドキドキ...
>
>＃自分のマシンのRHLの/usr/share/docの膨大な量のライブラリのドキュメントを見て
>＃いつもビクビクドキドキビクビクドキドキ...
いつもビクビクドキドキですか？普通、自分が欲しいと思うような
ものって、FreeBSD,OpenBSDのports/distfiles/やNetBSDのpkgsrc,
LinuxのRPM を見ると、既に30人くらいが作っていて、それらを改良
するだけで済むと思うのですが。
＃ゴキブリの法則
まさか無い…と思っていたら、それは捜し方が足りないか、パターン
マッチング能力が足りないだけです。
--
中村和志＠神戸 <mailto:k...@kobe1995.net>
NAKAMURA Kazushi@KOBE <http://kobe1995.net/>
- Break the hate chain. No more kill!
administrator@127.1
NAKAMURA Kazushi
In article <bm33fo$b7p$1...@caraway.media.kyoto-u.ac.jp>
ymi...@mail.sf.airnet.ne.jp writes:
>十ん年前には「高級言語マシン」ってことで、そのようなノリのもあり
>ましたが(ちょうどRISCの普及とかち合っていたかな)、CHI,Facom α,
>PSI,ELISは既になく、Symbolics,LMIは会社そのものが消滅。
>商用で手を出す人はもういないかも。
iAPX432 & ADA
なんて代物も有りましたね。天下のintel & 国防総省の大失敗。
In article <3989072...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp writes:
>> ・GNU global程度のソースナビゲーション機能とか、リアルタイムの
>> クロスリファレンサとか
>gdb とか linux kernel とか gcc をとかのcross reference って
>全然役に立たない.... indirect callの塊だからなぁ。
Globalって山口さんが作ってた奴なら、結構その辺頑張ってましたよ。
従来のクロスリファレンサとは大違い。でも、FreeBSDのソースツリー
をハイパーテキスト化するには、ソースツリー数倍分のストレージが
必要になるのと、果報を「寝て」待たないといけないのは致し方ないかと…。
>その連係を作ること自体がプログラミングで、既に連係が出来ている
>場合って、実は「似たようなものを作っている」時なんだよね。
IDEって実は「作って」いるのではなくて、既に有る物の中から
「選んで」いるだけに過ぎない、に一票。
>Compiler 用のIDEみたいなのがあるとうれしいかな。生成したコード
>のエラーから、生成したCompilerのコードの部分を指摘してくれるみたいな...
どうせなら、そのコードを実行するMPUのverilogなりVHDL
なりのコードも吐いてくれれば…。IDEでないものなら既に近い物が
存在するけど。
In article <m3n0ccd...@nightmare.hm.taito.co.jp>
noj...@taito.co.jp writes:
>> > 理想はF5だけ押せば自動で全部コンパイル。依存関係はソースからIDEが全て読
>> >みとって、よきにはからってくれないかなーと。IDEでソースファイル
LOAD & RUNner ?
#ベーマガ読者
>> キャラクタインターフェースのShellが嫌いなだけなんじゃぁ....
>あのmakefileを手で作るという作業が嫌いなのです。
mkmfとかxmkmfとか御存知無い？
#テンプレート作らないといけないのは、結局IDEも同じだし。
In article <YAS.03Oc...@kirk.is.tsukuba.ac.jp>
y...@is.tsukuba.ac.jp writes:
>IDE (Integrated Development Environment) ですが、プログラミ
>ングとは、実はあんまり関係ないんじゃないかなあ。数年前に見た
あんまり、でなくて、全然関係無いですね。
>のですが、IDE (Visual C++) は使えるけれど、プログラミングは
>全然だめという人がいました。その人は、IDE という道具が使える
>ので、自分はプログラミングができると完全に勘違いしていました。
これが沢山存在すると思います。
・IDEが使えること と
・プログラムが作れること
は全然違うことですね。
>> 要求仕様を満たせたりできたらいいと思います。ツールで絵を書けば特定分野の
>> プログラムぐらい自動で生成して欲しいと思うこのごろ。
>そうですか。素人が絵を描いて作ったジャンボジェット機に乗る気
>は、私は全然しません。
私も、です。でも現実には絵を描いただけで、後はIDEなりドラエモンなりが
何とかしてくれるものだと勘違いしている新人が沢山入社してきて困る訳です。
>IDE って、どのくらいのスケーラビリティがあるんでしょうね。画
scalabilityより、createやrealizeしてくれる能力が欠如しているのが
問題ではないでしょうか。既存のライブラリで解決できるソフトなら
「捜せば」存在するし、既存のライブラリで解決できないと途端に
百害有って一理無しだし。結局、絵からtableを作ってくれるのに
毛が生えたくらいしか役に立たない。
In article <m3brspi...@nightmare.hm.taito.co.jp>
noj...@taito.co.jp writes:
> いえ、素人さんと環境の組み合わせと問題解決の仕方次第だと思います。
>素人さんによる人海戦術はとても大切です。これが出来る出来無いで、
>後にドエライ差があらわれます。はい。自分的には職人10人集めるよりも、
>職人1人＋素人100人集めてグループで何かさせたほうが総合的に何かと良いことが
>多いように感じています。
その職人一人がドエライ迷惑を被るので、そんな開発スタイルは
「ただちに」辞めて頂きたい。その一人に素人100人の100倍、
つまり1人月で1万倍のギャラを払うので無い限り。
> もちろんですが、「きちんと筋道たてて説明できる能力」についての才能のある
>無しはみとめます...
新人達、「無し無し」なんですけど。やっぱり特殊な能力になるのでは？
Mr.Spockじゃないけど、"It's not logical"と言ってやりたい人が
とても多いのが日本の現実です。
> ただ、コンピュータ環境が悪すぎると、解こうとしている問題の内容以前に、
>
> ・ポインタがどうこうだとか、
> ・環境のバグだとか、
> ・１ステートメントあたりの機能量が低過ぎるとか、
> ・融通／気がきかないとか、
>
>等のコンピュータを利用する上での問題の方が大きく、
>当初の目的よりも手段に手間を取られ、本末転倒になってしまいがちなような。
コストという大問題が有りますから。1～100までの素数をリストアップする
だけのプログラムに、1億円の予算を付けてくれるところが存在すれば、
私の考えは改めますが。
> 本来、理想を言えば、解こうとする分野に関する専門知識の有る無しが問われる
>方がよいのではないでしょうか？
ならば銀行マンなり鉄道マンなりに組んでもらえばよくて、我々プログラマ
は皆商売、上がったりですが、現実にはその反対なようですよ。
>> のですが、IDE (Visual C++) は使えるけれど、プログラミングは
>> 全然だめという人がいました。その人は、IDE という道具が使える
>> ので、自分はプログラミングができると完全に勘違いしていました。
> いえ、それでも成果が上がるなら、そっちの方が私は嬉しい。逆に
>その人はどうやって成果をあげているのかを研究したい。
成果が上がっている…と勘違いしているだけですって。
>> そうですか。素人が絵を描いて作ったジャンボジェット機に乗る気
>> は、私は全然しません。
> 素人さんが沢山ジェット機を作ってくれることが出来る世の中になるので
>あれば自分はそっちが良いですね。
墜落しまくりでも？
Takahide Nojima
k...@kobe1995.net (NAKAMURA Kazushi) writes:
> >と、いつもビクビクドキドキビクビクドキドキ...
> >
> >＃自分のマシンのRHLの/usr/share/docの膨大な量のライブラリのドキュメントを見て
> >＃いつもビクビクドキドキビクビクドキドキ...
>
> いつもビクビクドキドキですか？普通、自分が欲しいと思うような
> ものって、FreeBSD,OpenBSDのports/distfiles/やNetBSDのpkgsrc,
> LinuxのRPM を見ると、既に30人くらいが作っていて、それらを改良
> するだけで済むと思うのですが。
> ＃ゴキブリの法則
上の引用には全くもって同意。
＃凄い世の中になった...
> まさか無い…と思っていたら、それは捜し方が足りないか、パターン
> マッチング能力が足りないだけです。
ええ、全くそのとおりです。
プログラムを一から作れる能力より、
人のプログラム探してきてさっさ改造できる能力の方が重宝する勢い...
Takahide Nojima
k...@kobe1995.net (NAKAMURA Kazushi) writes:
> In article <m3n0ccd...@nightmare.hm.taito.co.jp>
> noj...@taito.co.jp writes:
> >> > 理想はF5だけ押せば自動で全部コンパイル。依存関係はソースからIDEが全て読
> >> >みとって、よきにはからってくれないかなーと。IDEでソースファイル
> LOAD & RUNner ?
> #ベーマガ読者
自分はそうじゃないつもり（本当か？）ですが、人材確保が豊富かつ容易なのは、
LOAD&RUNnerな人達です。で、世の環境はLOAD&RUNner向けにどんどん
シフトしてるような。
当然ですが、LOAD&RUNnerな人の生産能力はそうじゃない人に比べてとても
低くなります。ただ、最近はCPUパワーとか、環境が改善されてきていて
段々その差も縮まってきているような...
もちろん、そうじゃ無い分野もあることは認めますが、昔よりはだいぶ減って
きているようなきがしてます。
> >のですが、IDE (Visual C++) は使えるけれど、プログラミングは
> >全然だめという人がいました。その人は、IDE という道具が使える
> >ので、自分はプログラミングができると完全に勘違いしていました。
> これが沢山存在すると思います。
> ・IDEが使えること と
> ・プログラムが作れること
> は全然違うことですね。
ただ、
1. IDEもだいぶ凄くなってきて
2. 新規で作るより似たようなものみつけてきて改造した方が早い
という世の中ですから、下手すると
IDEが使えること＝プログラムが作れること
にどんどん近付いてきているように思います。
> >> 要求仕様を満たせたりできたらいいと思います。ツールで絵を書けば特定分野の
> >> プログラムぐらい自動で生成して欲しいと思うこのごろ。
> >そうですか。素人が絵を描いて作ったジャンボジェット機に乗る気
> >は、私は全然しません。
> 私も、です。でも現実には絵を描いただけで、後はIDEなりドラエモンなりが
> 何とかしてくれるものだと勘違いしている新人が沢山入社してきて困る訳です。
でも、仰ることが現実ならば、この問題を解決するには、この新人逹が実用レベルの
ことを容易に出来る環境を取り揃え、知恵を絞るのもベテランの役目なわけで...
こうしてプログラミング環境も進化しまくると。
> In article <m3brspi...@nightmare.hm.taito.co.jp>
> noj...@taito.co.jp writes:
> > いえ、素人さんと環境の組み合わせと問題解決の仕方次第だと思います。
> >素人さんによる人海戦術はとても大切です。これが出来る出来無いで、
> >後にドエライ差があらわれます。はい。自分的には職人10人集めるよりも、
> >職人1人＋素人100人集めてグループで何かさせたほうが総合的に何かと良いことが
> >多いように感じています。
> その職人一人がドエライ迷惑を被るので、そんな開発スタイルは
> 「ただちに」辞めて頂きたい。その一人に素人100人の100倍、
> つまり1人月で1万倍のギャラを払うので無い限り。
でも、
職人の絶対数 << 素人もしくは見習いの絶対数
の事実はかわらない。
> > もちろんですが、「きちんと筋道たてて説明できる能力」についての才能のある
> >無しはみとめます...
> 新人達、「無し無し」なんですけど。やっぱり特殊な能力になるのでは？
> Mr.Spockじゃないけど、"It's not logical"と言ってやりたい人が
> とても多いのが日本の現実です。
...そ、そうなのでしょうか？最近「きちんと筋道たてて説明できる能力」を
持つ人が減ってきているのが本当ならば、確かに私の理論は間違っていること
になります。自分の感覚ではさすがにそこまではいっていないと思っています。
うーん、「きちんと筋道たてて説明できる能力」を測定してみたいものです。
> > ただ、コンピュータ環境が悪すぎると、解こうとしている問題の内容以前に、
> >
> > ・ポインタがどうこうだとか、
> > ・環境のバグだとか、
> > ・１ステートメントあたりの機能量が低過ぎるとか、
> > ・融通／気がきかないとか、
> >
> >等のコンピュータを利用する上での問題の方が大きく、
> >当初の目的よりも手段に手間を取られ、本末転倒になってしまいがちなような。
> コストという大問題が有りますから。1～100までの素数をリストアップする
> だけのプログラムに、1億円の予算を付けてくれるところが存在すれば、
> 私の考えは改めますが。
ちょーっと極端じゃないですか？最近のソフトウェア開発の現状はそこまで悪くない。
> > 本来、理想を言えば、解こうとする分野に関する専門知識の有る無しが問われる
> >方がよいのではないでしょうか？
> ならば銀行マンなり鉄道マンなりに組んでもらえばよくて、我々プログラマ
> は皆商売、上がったりですが、現実にはその反対なようですよ。
でも、世の様々な職人業は、できるできないの二極化が進みまくって最後は
極一部の職人集団がブッチギリでビジネス上の優位を確立して大金を稼ぎ、
残りの大部分はとてもお安くかつ、辛い状況になるのは自然の成り行きです。
となれば、銀行マンなり鉄道マンにも組める環境／技法を先回りして作って
商売してしまい、次の飯の種を考えていった方が誰にとっても良いような...
> >> のですが、IDE (Visual C++) は使えるけれど、プログラミングは
> >> 全然だめという人がいました。その人は、IDE という道具が使える
> >> ので、自分はプログラミングができると完全に勘違いしていました。
> > いえ、それでも成果が上がるなら、そっちの方が私は嬉しい。逆に
> >その人はどうやって成果をあげているのかを研究したい。
> 成果が上がっている…と勘違いしているだけですって。
それは残念です...
> >> そうですか。素人が絵を描いて作ったジャンボジェット機に乗る気
> >> は、私は全然しません。
> > 素人さんが沢山ジェット機を作ってくれることが出来る世の中になるので
> >あれば自分はそっちが良いですね。
> 墜落しまくりでも？
その場合は流石に世間が黙ってないから早期に改善が行われ、結果的には、以前程の
職人でなくても、基本的なこと知ってるだけの人が、パーツ組合せて実用的なものを
作れる世の中になるような...
Takeshi SHIGIHARA
車はコンピュータなんぞよりは長い歴史を持ってます。
現代の人たちなら、たいてい車を運転できます。
でも運転できるだけで設計・製造はできない。わたしも自分の車の発火プラグ
一本でさえ、取り替えることもできやしない。なさけねーが。
４０年前なら、運転できる人は誰でも発火プラグ程度は取り替えられるような
スキルを持っていた。いや、持たざるをえなかった。今の運転者は、そんなス
キルは(持っていたほうが良いのだが)あまり必要はないし、ましてや車自体を
作れるようなスキルなんて必要がない。
ケーブルＴＶで楽しみに見ている番組にジャンクヤードウォーズというのがあ
るんだが、そこでは、廃車置場で適当な車を２～３台漁ってはそれらを見事に
繋げて前後どっちにでも動く車を作ってたりする。それも１チーム４人程度で
せいぜい２日以内で。
部品を完全に与えられていてさえ、あんなマネは私にゃ出来そうもない。
竪穴式住宅から超高層ビルディングまで数千年の進化を経た(誇張しすぎかな)
the 大工さんを考えて見ましょうよ。
さて、世の中には、大工さんしか存在しないことにしてしまいましょう。
大工さんたちは家を作れますが、必ずしも全員が高層ビルディングを作れる
わけじゃない。だからっつーて高層ビルディングを設計できる一部の人たちが
寺社仏閣を作れるわけじゃない。これは宮大工さんに任せないことには作れな
い。適材適所。
お客さんとプログラム作成屋の間に入って「通訳」を行う職種があるのは、
作ったプログラムに椅子を投げつけられないようにするため。
時間をかけて合意を得たつもりでも、けっこう「誤訳」があったりする。
せいぜい、そのコンピュータ内だけで操作が終了するなら、あまりひどい損失
にはならないけど、銀行のプログラムじゃ実社会まで影響が出る。工場内のロ
ボットは数千万もする製作機械を壊してしまう。
超コンピュータのある世界。
人間同士のコミュニケーションでさえ上手くいかないのに、映画の中の超コン
ピュータみたいに「コンピュータ、あれをやっておいてくれ」「了解しました
ご主人様。ですが、あれとは何ですか？」
この先にどんなコミックが待ち受けているか、想像に難くない。
もちろん、オチは画面に椅子を投げつけているところだろうさ。
わかるよ。
自分で使うExcelのマクロスクリプトぐらい、自分で書けよぉと思うことは何度
も何度もあるよ。
私にはとても簡単に見えるスクリプト言語だ。なぜ彼らはそれを書けないという
のかな。
----- Takeshi SHIGIHARA
cyg...@tka.att.ne.jp
cyg...@po.jah.ne.jp -----
Takashi SHIRAI
fj.comp.*programming* ですよね？？？
In article <0310140056...@ns.kobe1995.net>,
NAKAMURA Kazushi <k...@kobe1995.net> wrote:
>>＃自分のマシンのRHLの/usr/share/docの膨大な量のライブラリのドキュメントを見て
>>＃いつもビクビクドキドキビクビクドキドキ...
>
>いつもビクビクドキドキですか？普通、自分が欲しいと思うような
>ものって、FreeBSD,OpenBSDのports/distfiles/やNetBSDのpkgsrc,
>LinuxのRPM を見ると、既に30人くらいが作っていて、それらを改良
>するだけで済むと思うのですが。
これって、「だからわざわざ作らなくてもいいじゃん」とか「一
から作るなんて無駄」とかいった結論に帰着させたい訳なんでしょ
うか？
私はそういう理屈で「車輪の再発明」を否定する輩は大嫌いです。
市井の人としては合理的な生き方なのかも知れませんけど、少なく
とも programmer としては最低な考え方だと思います。
私は programming の産物を単なる工業製品の一つとは思ってい
なくて、それよりはもう少し作家性を出せる、むしろ文学とか芸術
とかいったジャンルに近い存在だと思っています。
機能としては同一でも、デザインなりインタフェースなり、どこ
かしら独自な局面が出て来る筈で、再発明した結果に全く新規性が
生まれないなんてことはあり得ないでしょう。
一見誰が作っても同じようなものが出来るように思える家電です
ら、各社がオリジナリティを競って頑張っているのに、ソフトウェ
アにオリジナリティが出せない訳がありませんよね。
むしろ、そういった独自色を出せる部分に工夫を凝らして、単な
る焼き直しに終始させない精進こそが programmer の腕の見せどこ
ろなんじゃないでしょうか。
必要だと思った、欲しいと思った、そういった純粋なモティベー
ションをきっかけとする創作活動が、無駄の一言で一笑に付される
なんて、programmer の identity をないがしろにしているとしか
思えません。
もし、各種 packaging system がそういう風潮の啓蒙に一役買っ
ているのだとしたら、私はこれらの packaging system には愁眉の
念を禁じ得ませんね。
今現在は、packaging system で幸せになれる人が多いかも知れ
ませんが、その存在が将来の名 programmer の芽を摘む存在なんだ
としたら、長い目で見て programming の分野には害悪でしかない
でしょう。
＃ packaging system を作ってる方にそういうつもりが無くても、
＃その結果を見て「車輪の再発明は無駄だ」と感じる人が出て来る
＃という事実は否めないんでしょうね。ふぅ。
>まさか無い…と思っていたら、それは捜し方が足りないか、パターン
>マッチング能力が足りないだけです。
自分がそうするのは勝手ですけど、そういう生き方を他人にまで
奨めるのは余計なお節介だと思います。一般人相手に説くのならま
だいいでしょうけど、なら newsgroup を選んでものを言って欲し
いですね。
fj.comp.programming って programming をする人のために用意
されているんですよね？programming をする気のない人が、他人の
やる気に水をさすための newsgroup ではないと思います。
--
しらい たかし
Y.MINAMI
>
> 私はそういう理屈で「車輪の再発明」を否定する輩は大嫌いです。
>市井の人としては合理的な生き方なのかも知れませんけど、少なく
>とも programmer としては最低な考え方だと思います。
> 私は programming の産物を単なる工業製品の一つとは思ってい
>なくて、それよりはもう少し作家性を出せる、むしろ文学とか芸術
>とかいったジャンルに近い存在だと思っています。
(以下省略させて頂きます)
このような考え方も理解できますし、大事なことだと思います。
ただコストとか資源の有効利用とかを考えると、どこで折り合いを
付けるか(または妥協するか)が悩ましいところですね。
極端な例：第二次大戦で兵站充分の米軍は標準的な工具セットで大抵の
飛行機の整備ができた。兵站ショボショボの日本軍、機種ごとに工具が
違う。おまけに地上兵も含めて銃器の口径バラバラかつ同じ口径でも弾
が共通化されていなくて使い回し不可。個々を見ればそれなりに考えて
はいたのかもしれないけど。
で、今でも
Takeshi SHIGIHARAさんの<vomv3ea...@news.supernews.com>から
>
>自分で使うExcelのマクロスクリプトぐらい、自分で書けよぉと思うことは何度
>も何度もあるよ。
これはおろか、本来はExcelなりAccessで充分なものでもわざわざWEBアプリ
ケーション化すること要求されるみたいなことが多々あるわけで、良く日本
は高コスト体質だと言われることがありますが、これじゃ当然じゃんと思った
りして。(まあ、これは「いいじゃん、その方が売上取れるし」と言う考え方
もありますが)
＃「日本人は縮み指向」ってのは結構眉唾だったりして
----
みなみ＠ちょいと散漫になってしまいましたm(_'_)m
Takahide Nojima
shi...@unixusers.net (Takashi SHIRAI) writes:
> fj.comp.*programming* ですよね？？？
ええ、programmingに関する話題のニュースグループかと。
> これって、「だからわざわざ作らなくてもいいじゃん」とか「一
> から作るなんて無駄」とかいった結論に帰着させたい訳なんでしょ
> うか？
> 私はそういう理屈で「車輪の再発明」を否定する輩は大嫌いです。
> 市井の人としては合理的な生き方なのかも知れませんけど、少なく
> とも programmer としては最低な考え方だと思います。
そ、そーなんですか？
電子回路だって、
鉄菅につめたトランジスタ->樹脂で固めたトランジスタ->IC化->LSI化->IP化
という変遷をうけて、加速的に発達した現実があります。もちろん、一部
の高周波帯では未だにトランジスタ回路等かもしれませんが。
＃まさか、FF(Flip Flopね）作るのに非安定マルチから作る人は
＃かなり小数派ですよね。
> 私は programming の産物を単なる工業製品の一つとは思ってい
> なくて、それよりはもう少し作家性を出せる、むしろ文学とか芸術
> とかいったジャンルに近い存在だと思っています。
この考え方は初めて知りました。
ただ現在、自分にとって興味のあるのはこちらではないです。
> むしろ、そういった独自色を出せる部分に工夫を凝らして、単な
> る焼き直しに終始させない精進こそが programmer の腕の見せどこ
> ろなんじゃないでしょうか。
いえ、人が作ったものを再利用しまくって組み合わせ、もっと凄いもの作る
やり方もあります。
> 必要だと思った、欲しいと思った、そういった純粋なモティベー
> ションをきっかけとする創作活動が、無駄の一言で一笑に付される
> なんて、programmer の identity をないがしろにしているとしか
> 思えません。
そ、そこまでは言っていません。
・似たような物があれば、再利用しまくり、
・再利用が続けば部品化しまくり、
・無い物/無い機能を努力して探して最小限の労力で実装し、
・で、今までに無い物/無い機能をリリース
がモットーです。
> もし、各種 packaging system がそういう風潮の啓蒙に一役買っ
> ているのだとしたら、私はこれらの packaging system には愁眉の
> 念を禁じ得ませんね。
> 今現在は、packaging system で幸せになれる人が多いかも知れ
> ませんが、その存在が将来の名 programmer の芽を摘む存在なんだ
> としたら、長い目で見て programming の分野には害悪でしかない
> でしょう。
>
> ＃ packaging system を作ってる方にそういうつもりが無くても、
> ＃その結果を見て「車輪の再発明は無駄だ」と感じる人が出て来る
> ＃という事実は否めないんでしょうね。ふぅ。
再発明を全面的に否定というわけではありません。
作ってみたら良くわかったとか、
ちょっと変化させるヒントが見付かった
前より応用が効くようになった
という効力があることも多いです。ただ、全くかわりばえしないものを
くっつけてリリースすると、大抵保守性／テスト工数拡大／検証不足を招いて
成果物が吹っ飛ぶことも多いのが現実です。
また、
「探しまくって物が出来無いより、
探さなくても早く物が出来た方がマシ」
という話も確かにあります。
＃実際、OPアンプをトランジスタレベルで自作してみるといろいろ判って
＃IC回路／集積回路でも応用効いて良いことが多いです。
> >まさか無い…と思っていたら、それは捜し方が足りないか、パターン
> >マッチング能力が足りないだけです。
>
> 自分がそうするのは勝手ですけど、そういう生き方を他人にまで
> 奨めるのは余計なお節介だと思います。一般人相手に説くのならま
> だいいでしょうけど、なら newsgroup を選んでものを言って欲し
> いですね。
> fj.comp.programming って programming をする人のために用意
> されているんですよね？programming をする気のない人が、他人の
> やる気に水をさすための newsgroup ではないと思います。
programmingのやり方は時代と共に変遷していると思います。
このスレッドではprogrammingを否定するのではなく、
新しいやり方を探しているのです。
Takahide Nojima
shi...@unixusers.net (Takashi SHIRAI) writes:
> 私は programming の産物を単なる工業製品の一つとは思ってい
> なくて、それよりはもう少し作家性を出せる、むしろ文学とか芸術
> とかいったジャンルに近い存在だと思っています。
まあ、programmingが面白いというモチベーションが重要なのは私もみとめます。
これは大事です。ただ両刃の刃になることも否定しないです。