アカウント名:
パスワード:
おっしゃる通りだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
実は (スコア:4, すばらしい洞察)
本当に楽しければ自然に増えると思います。
Re:実は (スコア:2, すばらしい洞察)
Re:実は (スコア:4, すばらしい洞察)
Re:実は (スコア:5, すばらしい洞察)
「他人のソースを読まない人は、結局は、自分でプログラムを書けない」は、その人のレベル次第だと思いますね。コードから何かを学ぶ場合、「こうすれば良い」と「こうしてはいけない」の2つがあると思います。ある程度のレベルに達すると、残念ながら「こうすれば良い」が学べるコードの数は限りなく少なくなって行きます。「こうしてはいけない」は数限りなく見ているので、もうお腹いっぱいです。「プログラム言語とかライブラリのAPIマニュアルさえあればプログラムが書けるとか思っている」人が書いたコードから何が学べるのでしょうか。デスマ突入の秘策とか?
大体、GNUのコードとかでプログラミング作法を覚えた人は、仕事としてならそれが間違っているのかを理解していない人が多いですし、その間違いを説明するだけで一苦労です。GNUとかのコードとプロダクトグレードのコードでは、コードを書く姿勢も重要となる側面もまったく違うのに。単眼的な見方が染みついているので、他の要素の存在を受け入れないんですね。
「一方で、おおざっぱな全体構成とか仕様だったら、プログラミング能力がなくても書ける」って、エンジニアリングセンスに欠けた人による設計はたとえ外部であっても、あるいは要求仕様であっても、苦痛のタネですしトラブルの元だと思いますよ。品質に問題ありのプロダクトとか、デスマ日常でもカットオーバーが遅れるとか、そういう事の原因の一端は、シロウトさんの設計によってですね。設計と実装は車の両輪みたいなもので、どちらをシロウトさんに任せられるか、なんて議論は危険そのものだと思いますよ。
コードを読んで楽しいかどうかは、人の置かれている状況次第でしょう。趣味でコードを読むならどんなコードでも良いけれど(読みたく無ければ止めれば良いし)、仕事でならクソなコードは苦痛そのものですね。出来れば読みたくないのですが。
Re:実は (スコア:2, 興味深い)
人それぞれなんだろうけど、仕事でコードを書く人には、ただテストに通ればいいと思っているんじゃないかというような、非常に汚くてへたくそなコードを書く人もいるんですよね。だからといって、きれいに書き換えることもできないのが、仕事でコードを読む場合のつらいところだったりしますが。
Re:実は (スコア:4, 興味深い)
ソフトの規模が大きくなったがために、効果的な教育システムやシステマチックなマネジメントが無い状態で、適性を無視して大量動員を行った結果ですね。
今日、2006/04/08の朝日の朝刊に「バグ猛威、デジタル製品」の記事が載ってました。内容を読んで見て思ったのは「それは自業自得じゃない?」ですね。単価を切り下げて人集め、糞と味噌の区別もつかない、そんな事をやっていればこうなるのは必然です。記事中でソニー中鉢社長は技術系の人材が欲しいと言っていますけれど、それは必要な事ながら、それで問題が全て解決するとも思えません。糞と味噌の区別もつかないマネジメントが根本問題なのですから。
Re:実は (スコア:1)
おっしゃる通りだと思います。
件の素人なのだが (スコア:5, すばらしい洞察)
って、思いっきりそう思ってるんだけど、呼びました?
うぅ〜〜〜ん、、、
原理や基本概念さえ分ってれば、
それで全く問題ないプログラム書けるはずなんだけどなぁ、、、
そもそも、そのためのライブラリであり、APIマニュアルのはずなんだが、、、
基本的にAPIマニュアルだけで書けないのは、
大抵の場合マニュアルに不備があるせいじゃないだろうか?
結局、その場合ソース読む羽目になる訳だが、
原理や基本概念が分ってないと、結局読めない。
また、ソースはあくまでも1つの実装に過ぎない。
本当に大切なのは、ソース読む事ではないような気がするんだけどなぁ、、、
デザインパターンなんかも
まさにそこを狙ってる気がするんだけど、
その辺りどう思います?
もちろん1実装手段、
テクニックの実例としては
ソースは重要だと思うのだけど、
プログラミング能力って点では、
ソースは具象的過ぎる、、、
大切なのはもっと抽象的な概念の部分じゃないかと、、、
# アルゴリズムとかね、、、
uxi
Re:件の素人なのだが (スコア:1)
> 大抵の場合マニュアルに不備があるせいじゃないだろうか?
ンなわきゃねー。今Java2Dの資料見てるんだけど、何かを実現するためにどれをどう組み合わせればよいのかなんて、APIのドキュメント「だけ」眺めてるんじゃ絶対わかんない。
Java は基本的に門外漢なんだけど、、、 (スコア:5, すばらしい洞察)
Java 2D の API マニュアル [sun.com]ではなく、
JavaTM 2D API プログラマーズガイド [sun.com]じゃないかな、、、と、、、
# 外してたら申し訳ない、、、m(_ _)m
個人的印象としては、
どうも Java の API マニュアルは取っ付き難い印象が強いですね、、、
クラスライブラリとしては同規模程度と思われる
MFC や ATL 等のマニュアル [microsoft.com]と読み比べてみると、
僕の感覚では、Microsoft に軍配が上がっちゃう、、、
# あれも、最初は分量の多さにどこから手を付けて良いのか途方に暮れたけど、
# それでも Java のマニュアル程の取っ付き難さは感じてなかったような気が、、、
# 多分 API マニュアルから概観の解説が引けてたのと、
# メソッド毎に、簡単なサンプルコード付いてる確率が高かったのが大きいのかも?
とりあえず、
Java の API マニュアルは全体的にボトムアップ的な印象が強いですね、、、
# プログラマーズガイドはトップダウン的だと思うけど、、、
# これとはリンクの結び付きが弱い、、、
# その結果、やりたい事は分ってても、使うべき機能に到り付き辛い印象が、、、
# 読み方がなっとらんと言われれば、その通りなのだが、、、orz
既に全体像が分っていて、
やりたい事に対応するクラス名、メソッド名がぱっと思いつく人にとっては、
悪くないリファレンスだと思うんだけど、
とかく入門者はどこから手を付けて良いか途方に暮れてしまいそうですよ。
また、デザインパターンの知識を暗黙の了解としている節もあり、
サンプルコードも皆無に近い状態なので、
その辺りの下地が一通り整ってないと、
入門書、参考書、解説書の類がないと苦しいのではないかと、、、
僕個人の感触では、あのマニュアルは
オブジェクト指向のマイナス面の体現である気がしていけない、、、
本来、おおまかな機能と、インターフェースさえ分っていれば、
小難しい事あと回しで使えて良いはずなのに、
そうさせてくれる糸口が前の方に出て来てないので、
なかなかそうさせてもらえない印象が強いと言うか、、、
うっかりしてると、プログラマーズガイド見落してて、
API マニュアルだけ見て、どこから読めば良いんだ?って事が何度かあったし、、、
# まぁ、マニュアル自信の問題と言うよりも、
# ポインタの示し方の問題のような気もするんだけど、、、
この辺りは、反論がある方は是非コメントして下さい。
逆に、トップダウン的だなと感じるマニュアルの例は
PHP のオンラインマニュアル [php.net]かな?
あれは、チュートリアルとほとんど合体してる上、機能別に整理されてるから、
全体像を知らなくても、やりたい事から探して行くと、
自動的に使うべき関数のリファレンスに到り付いてるような印象が、、、
# まぁ、オブジェクト色は薄いですけどね、、、(^^;;;)
また、サンプルコードも比較的豊富に盛り込まれているので、
入門からリファレンスまであれ一つで済んじゃうので
参考書の必要性がほとんどない印象も、、、
uxi
Re:Java は基本的に門外漢なんだけど、、、 (スコア:1)
サンプルソースを探すなら (スコア:0)
Re:件の素人なのだが (スコア:0)
それだけの話です。
Re:件の素人なのだが (スコア:0)
マニュアルはHowTo本じゃないんだから、組み合わせ方を書いてないのは当たり前。
Re:件の素人なのだが (スコア:0)
他人が書いたOSやライブラリなんてただの実装と言ってしまえばそうなんですが、それを元に何とか客の要求する機能を実現しなけりゃならんことが多いのも事実。
ライブラリも万能ではないから、、、 (スコア:1)
追加する部分が多いなら、
追加ライブラリのような物をこさえる必要が生じるのが常ですね。
でも、そういう事は、既にみんな通って来ているはずだから、
(素人である)僕がここで講釈するまでもないと思うんだけどなぁ、、、
なぜそこが疑問点になるのか僕としてははちょっと理解に苦しむ所です、、、
とりあえず、基本的には、基礎概念が分ってるって前提で、
ソースを書く手間を省くのがライブラリであり、
ライブラリの内部実装を隠蔽する、
つまりソースを読む手間を省くのが(API)マニュアル。
あくまで、これらは手間を省く手段であって、
それが全てを解決してくれる万能薬である事はまずないわけで、
省けない手間は、自分できっちり手間かけてやるしかないですよね、、、
で、、、
使える物は有り難く使わせてもらうとして、
自分がかけた手間は、
なるべく他人も再利用し易い形(例えばライブラリ等)にして
公開、還元して行く事で、
みんなで幸せになろうよ、、、ってのが
ハッカーとかフリーソフトウェアとかオープンソースの
文化なんだと思いますです。はい。
uxi
Re:実は (スコア:0)
ってなんですか?
QEMU? VMware?
Re:実は (スコア:0)
GDBのデバッグエージェントになる機能があって、GDBでtarget remote ...みたいな感じで接続できるものがある。
高価(安くても10万円)だし、カーネルのデバッグのために使うようなものではないと思う。
うちではもっぱらハードウェアのデバッグとFlashROM焼き専用だな。