Ads by Google
新しい記事を書く事で広告が消せます。
それはデバッガ関係無いですよね
ちょっと気になっただけですが．
別に oraccha さんに何か物申したいわけではないのですが，この手のデバッグの話になると，なぜか
「デバッガを使うよりも ○○ （コードの書き方とか，設計とか，開発プロセスとか，テストとか，何でもいいのだけど） の方が大事だ．」
という論調の人が沸いてくるのはなんでなんだろうな，と思います．単なる論理のすり替えなんじゃないかな… 並べて議論するようなものでは無い気がします．
まるでデバッガを使う人が，なぜかみんな 「ちゃんとした設計をしないで」 「いきあたりばったりのコードを書いて」 「小手先でバグを直すだけで本質的なバグの原因を見逃し」 「テストも書かない人」 と言わんばかりですな．
ここらへんは，やっぱり，コンパイラやデバッガは，一般のプログラマにとっては不可侵な領域，ある種の聖なるもの，として必要以上に畏れ多いものとして扱われているのが原因なのかなと．なので意見が両極端に触れて，建設的にならない．宗教と同じで，すぐに原理主義か無宗教かという極端な話になる．
OS とかプログラミング言語とか処理系とかも 「偉い人賢い人が設計して実装した素晴らしいものを，我々下々の物が使わせていただく．それに物申すなんて不敬罪」 みたいな雰囲気はある気がしますね．
OS とか言語とか処理系の方は，わりとメジャーになってきて，いろんなものが出てきてるけど，デバッガはまだまだ特別な物なのかなと思います．自分が使いやすいデバッガをデザインしたり，既存のデバッガをハックして欲しい機能を追加したりするのが当たり前の世の中 （いつになるのかわかりませんが）になってくれば，また変わってくるのかもしれませんね．
ちなみに弊社では，「こういう設計で，こういうコードを書いて，こういうコードが出れば理想的だが，既存のコンパイラは欲しいコード出してくれないし，既存のデバッガではデバッグが非常に困難になる」 というような場合，デバッガは当然のこととしても，最近ではコンパイラにまで手を入れるのが普通という流れになってきているので，他の会社とはプログラミングに対する概念がかなり根本的に違うなーということをよく感じます (他の会社知らないけど，あんまり聞かない気がします)．
逆に，そういう既存の膨大なコードベースをサクサク改良したり，保守したりすることができるのも，デバッガがあってこそなわけですし．
コードの書き方に合わせて，デバッガを改良することにより，普通では開発できないような設計や構成が可能になる．これが弊社の技術的強みの本質なんだなと，最近ようやくデバッガ開発に参加し始めて，社長に 2 日かけてデバッガの内部構成の説明をしていただいて，その片鱗に触れることができた思いがします．
普通の書き方ではかなり大変になるであろう，デバッガの複数 UI 化や，マルチコア SMP 対応なども，独自の書き方で非常にシンプルになっていて感動しました．
どうやったらこんなの思いつくんだ ? と思いましたが，やっぱり，デバッガが特別なものではなく，改良していくのが当たり前という世界でずっと生きていると，発想が根本的に変わっていくのだろうなと思います （もちろん社長の天才的な発想力もあるのだと思いますが）．
とかダラダラ twitter の方に書いてたら，hyoshiok さんからツッコミが入ってました．
なるほど，「趣味の問題にとやかく言われたくない症候群」 ってのは，いろいろなところにありそうな気がしますね．
なんかとりとめもなく長々と書いてしまいましたけど，要するに，手段はないよりある方が良いし，できないよりはできた方が良いに決まってるということです．
便利な技術やツールが，技術者を堕落させるとかいうのは，また別の話でしょ，という．そんなのは，新しい技術が生まれるたびに必ず言われる 「最近の若者は」 だし．
「最近の技術者はすぐにコンパイルして実行するから駄目だ．わしが若い頃は，十分に机上デバッグして，脳内でプログラムをシミュレートしてから実行したもんだ．おかげでデバッガを使うまでもなく，バグを見つけることができた」
とかすぐに言い出す人が出てきますけど，その当時とはプログラムの規模も複雑さも全く違いますからね．
全部自分で書いた，小規模なコードならともかく，GCC や Linux みたいに，大量の ifdef で切られていて，関数ポインタ使いまくりの，数十から数百万行を超えるコードベースなんて，静的に追えるものではありません．また，仮に追えたとしても，それは単なる想像に過ぎずに，本当に動いている生きたコードであることは，デバッガなどで動的に追わない限り確信することはできません．
でも、設計もせずに行き当たりばったりに手を動かして、ちゃんとしたものができるとは思わないし、結局デバッグではまる原因になる。yuguiさんが講演で言ってたことも結局そういうことじゃないかと解釈したし、Linusが長い間カーネルデバッガの導入に反対だった(2.6.26でkgdbがマージされた)のも同じ理由からだろう。
（Plan9 日記 2009-04-25 ■[イベント] Debug hacks conference 2009）
別に oraccha さんに何か物申したいわけではないのですが，この手のデバッグの話になると，なぜか
「デバッガを使うよりも ○○ （コードの書き方とか，設計とか，開発プロセスとか，テストとか，何でもいいのだけど） の方が大事だ．」
という論調の人が沸いてくるのはなんでなんだろうな，と思います．単なる論理のすり替えなんじゃないかな… 並べて議論するようなものでは無い気がします．
まるでデバッガを使う人が，なぜかみんな 「ちゃんとした設計をしないで」 「いきあたりばったりのコードを書いて」 「小手先でバグを直すだけで本質的なバグの原因を見逃し」 「テストも書かない人」 と言わんばかりですな．
ここらへんは，やっぱり，コンパイラやデバッガは，一般のプログラマにとっては不可侵な領域，ある種の聖なるもの，として必要以上に畏れ多いものとして扱われているのが原因なのかなと．なので意見が両極端に触れて，建設的にならない．宗教と同じで，すぐに原理主義か無宗教かという極端な話になる．
OS とかプログラミング言語とか処理系とかも 「偉い人賢い人が設計して実装した素晴らしいものを，我々下々の物が使わせていただく．それに物申すなんて不敬罪」 みたいな雰囲気はある気がしますね．
OS とか言語とか処理系の方は，わりとメジャーになってきて，いろんなものが出てきてるけど，デバッガはまだまだ特別な物なのかなと思います．自分が使いやすいデバッガをデザインしたり，既存のデバッガをハックして欲しい機能を追加したりするのが当たり前の世の中 （いつになるのかわかりませんが）になってくれば，また変わってくるのかもしれませんね．
ちなみに弊社では，「こういう設計で，こういうコードを書いて，こういうコードが出れば理想的だが，既存のコンパイラは欲しいコード出してくれないし，既存のデバッガではデバッグが非常に困難になる」 というような場合，デバッガは当然のこととしても，最近ではコンパイラにまで手を入れるのが普通という流れになってきているので，他の会社とはプログラミングに対する概念がかなり根本的に違うなーということをよく感じます (他の会社知らないけど，あんまり聞かない気がします)．
逆に，そういう既存の膨大なコードベースをサクサク改良したり，保守したりすることができるのも，デバッガがあってこそなわけですし．
コードの書き方に合わせて，デバッガを改良することにより，普通では開発できないような設計や構成が可能になる．これが弊社の技術的強みの本質なんだなと，最近ようやくデバッガ開発に参加し始めて，社長に 2 日かけてデバッガの内部構成の説明をしていただいて，その片鱗に触れることができた思いがします．
普通の書き方ではかなり大変になるであろう，デバッガの複数 UI 化や，マルチコア SMP 対応なども，独自の書き方で非常にシンプルになっていて感動しました．
どうやったらこんなの思いつくんだ ? と思いましたが，やっぱり，デバッガが特別なものではなく，改良していくのが当たり前という世界でずっと生きていると，発想が根本的に変わっていくのだろうなと思います （もちろん社長の天才的な発想力もあるのだと思いますが）．
とかダラダラ twitter の方に書いてたら，hyoshiok さんからツッコミが入ってました．
@alohakun 誰もデバッグの事や、テストの事や、ソフトウェアの品質管理のことを体系立って教えてくれていなかったんですよ。趣味の問題にとやかく言われたくない症候群。
http://twitter.com/hyoshiok/status/1618207240
なるほど，「趣味の問題にとやかく言われたくない症候群」 ってのは，いろいろなところにありそうな気がしますね．
なんかとりとめもなく長々と書いてしまいましたけど，要するに，手段はないよりある方が良いし，できないよりはできた方が良いに決まってるということです．
便利な技術やツールが，技術者を堕落させるとかいうのは，また別の話でしょ，という．そんなのは，新しい技術が生まれるたびに必ず言われる 「最近の若者は」 だし．
「最近の技術者はすぐにコンパイルして実行するから駄目だ．わしが若い頃は，十分に机上デバッグして，脳内でプログラムをシミュレートしてから実行したもんだ．おかげでデバッガを使うまでもなく，バグを見つけることができた」
とかすぐに言い出す人が出てきますけど，その当時とはプログラムの規模も複雑さも全く違いますからね．
全部自分で書いた，小規模なコードならともかく，GCC や Linux みたいに，大量の ifdef で切られていて，関数ポインタ使いまくりの，数十から数百万行を超えるコードベースなんて，静的に追えるものではありません．また，仮に追えたとしても，それは単なる想像に過ぎずに，本当に動いている生きたコードであることは，デバッガなどで動的に追わない限り確信することはできません．
トラックバック
デバッガのハックは普通にするでしょ．
家族サービスで買い物に行ったついでのマックで，ぼんやり考えていた． FT2232を使ったポッドでADIのJTAGポートをアクセスすると，UrJTAGがどうもバグるよなぁなんでだろと思っていたり． 最近のOpenOCDのOSX迫害はなんとかならんかなーと呟いたり． OS とか言語とか処理系
コメント
言語処理系が百花繚乱になっているように、デバッガにも人が流れ込んでくるといいですね。
私はWiLiKiにもちょっと書きましたが、バグを追い込む過程で一番工数が大きいのは「外的環境を制御するための治具作り」だと感じているので、デバッガにはall-in-oneの環境というよりも、そういう治具作りに手軽に使える便利なツールキットっていう面を期待します。
そういう意味では、コンパイラにがんがん手を加えちゃうのは正しい方向だと思います。コンパイラが出した静的な情報と、実行プロセスのスナップショットを出発点にするのって、既に起きちゃった事象を後から調査する、forensicな感じのアプローチですよね。むしろ将来生起するはずのバグの兆候を探る斥候とか、バグが起きやすい方へとゆさぶりをかける工作員みたいなやつをプロセスの中に仕込んで行く方が正しいのではないかと。そうすると小刻みに実行を繰り返しながらコードを足してインクリメンタルにコンパイルしてゆくとか、コンパイラの助けを借りて要所要所に罠をしかけてゆくとか、そういう方向に行かないなあ。
私はWiLiKiにもちょっと書きましたが、バグを追い込む過程で一番工数が大きいのは「外的環境を制御するための治具作り」だと感じているので、デバッガにはall-in-oneの環境というよりも、そういう治具作りに手軽に使える便利なツールキットっていう面を期待します。
そういう意味では、コンパイラにがんがん手を加えちゃうのは正しい方向だと思います。コンパイラが出した静的な情報と、実行プロセスのスナップショットを出発点にするのって、既に起きちゃった事象を後から調査する、forensicな感じのアプローチですよね。むしろ将来生起するはずのバグの兆候を探る斥候とか、バグが起きやすい方へとゆさぶりをかける工作員みたいなやつをプロセスの中に仕込んで行く方が正しいのではないかと。そうすると小刻みに実行を繰り返しながらコードを足してインクリメンタルにコンパイルしてゆくとか、コンパイラの助けを借りて要所要所に罠をしかけてゆくとか、そういう方向に行かないなあ。
ども。（私は）デバッガと開発プロセスなどの優劣を論じたつもりはないですよ。あろはさんがおっしゃる通り別物なので。でも、Linusの発言をあのような形で引用したら、論理のすり替えという誤解を与えるかもですね。
一般のプログラマから見てデバッガは不可侵の領域というは、誰が作っても結局同じものになるし、定番になっていて欲しい機能はすでにある（ので自分が関わる必要はない）という心理があるのではないでしょうか。ここはあろはさんの反論を聞きたいところです。OSがオープンソース化などでノウハウの共有が起こり、敷居が下がり、実際に作ってみたらそうじゃないことがいろいろわかって状況が変わってきたのだとすると、デバッガの分野で変化の兆しがあるとすると何なのでしょうね？
デバッガとは違いますが、最近はdtraceやsystemtapなど、インタプリタ言語込みでいろいろできそうなツールが普及し始めていますよね。Plan9のacidもこれらに近いですが。（何でもできる系のツールでみんな幸せになれるかは多いに議論の余地はあると思いますが）個人的にはこの流れは面白いと思っています。仮想マシン＋スクリプト言語でデバッグというのは大昔にいろいろ考えたネタだったので。
ぐだぐだ書きましたが、久々にあろはさんのblogを見てKμCに入社されたことを今頃知りました。今後の活躍を楽しみにしてます。
一般のプログラマから見てデバッガは不可侵の領域というは、誰が作っても結局同じものになるし、定番になっていて欲しい機能はすでにある（ので自分が関わる必要はない）という心理があるのではないでしょうか。ここはあろはさんの反論を聞きたいところです。OSがオープンソース化などでノウハウの共有が起こり、敷居が下がり、実際に作ってみたらそうじゃないことがいろいろわかって状況が変わってきたのだとすると、デバッガの分野で変化の兆しがあるとすると何なのでしょうね？
デバッガとは違いますが、最近はdtraceやsystemtapなど、インタプリタ言語込みでいろいろできそうなツールが普及し始めていますよね。Plan9のacidもこれらに近いですが。（何でもできる系のツールでみんな幸せになれるかは多いに議論の余地はあると思いますが）個人的にはこの流れは面白いと思っています。仮想マシン＋スクリプト言語でデバッグというのは大昔にいろいろ考えたネタだったので。
ぐだぐだ書きましたが、久々にあろはさんのblogを見てKμCに入社されたことを今頃知りました。今後の活躍を楽しみにしてます。
Re: shiro さん
そうですね，コンパイラに手を入れるというといかにも大げさですが，デバッグやプロファイリングやロギングのためのちょっとした情報を吐かせるスイッチを付けたりするぐらいならば，出力コードに影響を与えずに，かついろいろなことができますからね．
デバッガと言ってますが，まさしくツールキットですね．イベントトラッカーとか，プロファイラとか，逆実行エミュレーションとか，そういう諸々のツールのためのプラットフォームみたいな感じになってます．
むしろ弊社的には，デバッガが OS というか，シェルみたいな感覚の人が多い気がします．デバッガありきで，デバッガからプログラムを起動するのが当たり前だし，デバッガの中からエディタを起動して修正して make 打って実行して… という開発サイクルが全部完結しているというか．
デバッガと言ってますが，まさしくツールキットですね．イベントトラッカーとか，プロファイラとか，逆実行エミュレーションとか，そういう諸々のツールのためのプラットフォームみたいな感じになってます．
むしろ弊社的には，デバッガが OS というか，シェルみたいな感覚の人が多い気がします．デバッガありきで，デバッガからプログラムを起動するのが当たり前だし，デバッガの中からエディタを起動して修正して make 打って実行して… という開発サイクルが全部完結しているというか．
Re: oraccha さん
どうもすいません，もちろん oraccha さんの意図はわかっているのですが，良い機会だし引用しやすかったのでダシに使ってしまいました （笑）
# debug hacks に関するネット上の反応を見ていて，いろいろと思うところがあったので．例えば 404 の人のとんちんかんな反応とか （曰く，デバッグよりもデータ構造の選定が大事だ，とか）
デバッガに定番の機能が全部ある，誰が作っても同じになるってのは，まさしく一般のプログラマが OS に対して思っていることと同じなんじゃないですかね ? そんなこと言われたら，おそらく oraccha さんは反論しますよね （笑）
例えば弊社では，Linux Kernel など OS のデータ構造をデバッガが直接認識するようにするなど，OS 対応デバッガを製品として出荷しています．
「組み込み業界最前線 −京都マイクロコンピュータ− 業界初のLinux対応ICEが成功した理由」
http://monoist.atmarkit.co.jp/fembedded/03kmc/kmc02.html
OS に限らず，ありとあらゆるアプリケーションに対応した （例えば GCC 対応デバッガで，GCC の複雑なデータ構造をわかりやすくデバッグできる，など） デバッガが考えられます．
もちろん，一般のプログラマは，(OS と同様に) デバッガを開発することが仕事には直結しませんから，費用対効果を考えて手を付けないのだと思います （twitter で natsutan さんにも指摘されました）．弊社はもともとデバッガベンダーなので，かなり深いところまでコミットしても仕事の一貫になるという点は，かなり特殊だとも思っています．
しかし，そういう心理的に無関係という意識があると，そこで発想が止まってしまってよくないんじゃないかと思います．そういう意味では，弊社がこれからもデバッガの可能性を追求し続け，デバッガが変わるとどれだけすごいことができるのか，ということを常に示して行けたらと思っています．
弊社でも，ログを集めて，そのログを元にしていろいろやる （例えば，プログラムが落ちた時点から，ログを元にして逆向きにエミュレータで実行するとか） してるみたいですね．僕はまだよくわかってないのですが，いろいろ面白そうだし，豊富な可能性があるなと感じています．
「京都マイクロコンピュータ、性能解析・品質保証支援ツールPARTNER-Jet/QProbeを発表」
http://www.kmckk.co.jp/news3/r081111_2.html
# debug hacks に関するネット上の反応を見ていて，いろいろと思うところがあったので．例えば 404 の人のとんちんかんな反応とか （曰く，デバッグよりもデータ構造の選定が大事だ，とか）
デバッガに定番の機能が全部ある，誰が作っても同じになるってのは，まさしく一般のプログラマが OS に対して思っていることと同じなんじゃないですかね ? そんなこと言われたら，おそらく oraccha さんは反論しますよね （笑）
例えば弊社では，Linux Kernel など OS のデータ構造をデバッガが直接認識するようにするなど，OS 対応デバッガを製品として出荷しています．
「組み込み業界最前線 −京都マイクロコンピュータ− 業界初のLinux対応ICEが成功した理由」
http://monoist.atmarkit.co.jp/fembedded/03kmc/kmc02.html
OS に限らず，ありとあらゆるアプリケーションに対応した （例えば GCC 対応デバッガで，GCC の複雑なデータ構造をわかりやすくデバッグできる，など） デバッガが考えられます．
もちろん，一般のプログラマは，(OS と同様に) デバッガを開発することが仕事には直結しませんから，費用対効果を考えて手を付けないのだと思います （twitter で natsutan さんにも指摘されました）．弊社はもともとデバッガベンダーなので，かなり深いところまでコミットしても仕事の一貫になるという点は，かなり特殊だとも思っています．
しかし，そういう心理的に無関係という意識があると，そこで発想が止まってしまってよくないんじゃないかと思います．そういう意味では，弊社がこれからもデバッガの可能性を追求し続け，デバッガが変わるとどれだけすごいことができるのか，ということを常に示して行けたらと思っています．
弊社でも，ログを集めて，そのログを元にしていろいろやる （例えば，プログラムが落ちた時点から，ログを元にして逆向きにエミュレータで実行するとか） してるみたいですね．僕はまだよくわかってないのですが，いろいろ面白そうだし，豊富な可能性があるなと感じています．
「京都マイクロコンピュータ、性能解析・品質保証支援ツールPARTNER-Jet/QProbeを発表」
http://www.kmckk.co.jp/news3/r081111_2.html
