アカウント名:
パスワード:
昔、Cプログラミング診断室http://www.amazon.co.jp/dp/4774117870/ [amazon.co.jp]というのを読むといいと勧められて読んだのですが、なんか作者の意地の悪さというか、批判のしかたがいやーな感じでどうも評価できませんでした。ダメなコードがなぜ生まれるのか、もっと体系的にまとめているのかと思っていたんだけど、例もバラバラというか、酷いコードを見せては罵るみたいなパターンで。
別宮某の誤訳指摘本と同じで、こういうのって作者と一緒になって自分が上の立場から悪口をいう快感を味合わさせるものになりがちな気がします。
大学の一年生でC言語をいきなり教えたりするから、こんな悲惨な事になるんすよ。最初はJavaかPascalかLispを教えるべきで、C言語は誰もが最初に学ぶような言語ではなかった。
なぜあの時代、「C言語はプログラマの基礎教養」「C言語ができずんばプログラマに非ず」「できなくても履歴書にC言語って書いておけ」みたいな風潮があったんでしょうねぇ。今の時代になっては、「アセンブラができずんばプログラマに非ず」なんて吹かしている人間は、流石に見かけないはず…と思いたい。
> なぜあの時代、「C言語はプログラマの基礎教養」「C言語ができずんばプログラマに非ず」「できなくても履歴書にC言語って書いておけ」みたいな風潮があったんでしょうねぇ。
いまさら、そんな話をされても……当時のハードウェアで実用的なプログラムを書くことができ、生産性、移植性が高かったからですよ。DOSマシンでも、8ビットマイコンでも、Unix WSでも使える言語、コンパイラが安く導入できる言語が他にありませんでしたから。
> 今の時代になっては、「アセンブラができずんばプログラマに非ず」なんて吹かしている人間は、流石に見かけないはず…と思いたい。
x86のシステムプログラムが書けるかという意味なら同意するけど、Z-80とか、8086でセグメントを越えないプログラムくらいは書けて欲しい。それらを事前に知らなくても、ポンとマニュアルを渡されたら、書ける程度の知識、能力。
人をプログラマと紹介されたら、その程度は前提にするのでは。
言語はあんまり関係ないと思うなあ。ifのような条件文がある言語なら、巨大なswitch文と同等なことを書けるので、手続き型言語ならほとんど同じことでは。Lispでも書きにくいけど書ける。
でも、学習・教育の問題とは思う。多くの場合、教育の段階で文法を教えるだけだから、課題を分析することなく、そのまま手続きにしてしまい、巨大なswitchのようなものができてしまう。
課題を分析するためには、既存のコンピュータの基本的な設計(CPUやメモリ、アドレスなど)と、それから導き出される効率的な各種アルゴリズム、たとえば配列の使い方(バイナリサーチやクイックサーチ、ハッシュなど)を教える必要がある。
けれども、それらがバラバラに教えられることがほとんどでしょう。コンピュータ系の学科でも、プログラミングの授業とアルゴリズムの授業が別々だったりする。それでは、フツーの学生や生徒には身につかない。
そうするとオンジョブトレーニングか、自己努力に依存するから、プログラマのレベルがバラバラで、製品の品質や生産性が上がらない。
プログラムを学ぶのに、最初にC言語なのは勘弁して欲しい(文字列型やBOOL型がない言語なんて…)。OOPを学ぶのに、最初にC++言語なのは勘弁して欲しい(リフレクションがないOO言語なんて…)。
CやC++は「最終到達点」となる言語であって、プログラムすることの本質が学べる言語ではないと思います。bool型がないからint型で代用、いやメモリ節約のためchar型だ、なんてバッドノウハウ以外の何物でもない。クイックソートやバイナリツリーを学ぶのに、C言語である必要性はどこにあるんでしょうか。PASCALでもよかったのではと。
わたしの文章が悪かったのなら謝罪するが、Cが教育用として最適だなんて書いた覚えはない。ただ、手続き型言語なんか、所詮は同じ穴の狢で、本質的には大差ないという趣旨。
bool型の代わりにint型を使っても、何か大きな問題があるとは思えないし、文字列も最初は大きめの配列で扱えば良い。いちいちmalloc()とかする必要はない。文字列処理が重要なら、何なら、BASIC風文字列関数をライブラリとして用意してやれば良いし、この際、PerlかRubに乗り換えても良い。
型があることがプログラミングを楽にするとの考えもあるが、schemeなどのように事実上、型をなくした言語もある。たとえば変数に関数を代入すれば、その変数が関数になる。Cで常にキャストを意識するとか、ポインタのポインタを扱うとか、そんなことを考えると、型はない方が楽。
教育用にC言語が適しているとは思わないが、その理由は文字列型やBOOL型が無いからではない
リファレンス型を備えてなく、代わりにポインタ(アドレス)を使わせるのは無いわーC言語で誰もが「配列ポインタをインクリメント」する部分につまづくのは当然。こんな仕様がある言語は高水準言語と言わん。
(リフレクションがないOO言語なんて…)
なんでOOPにリフレクションが必須だと思うの?# まあ、あった方が便利だとは思うが。
メタシステムはやっぱりオブジェクトじゃないよねえ、という反省から出て来たのがmirror
つ http://d.hatena.ne.jp/shi3z/20070911 [hatena.ne.jp]
スラドは初めてか?「C/C++プログラマーにあらずばプログラマーにあらず」みたいなマッチョばかりですよ、ここは。
COBOLを馬鹿にしCを賞賛する風潮はよくわかんなかったLisperです。今日もこの星のどこかで、今まさに、Cプログラマがポインタを踏み外して脆弱性を産んでいる-。
ドライバを書くならともかく、会計計算レベルでC使っているのは何故なんだと。そういう事務方の日々の雑務は、安全カミソリ言語でいいんじゃないのかなぁ。
CプログラマがCOBOLを馬鹿にしすぎるから、COBOLerが無理して覆面でC界隈に乗り込んできて、さらにひどい事態を引き起こす羽目になって全員不幸になりました。そのまま大人しくCOBOL使わせておけば、こんな悲惨な事にならなかったのになぁ。
>COBOLを馬鹿にしCを賞賛する風潮はよくわかんなかったLisperです。
こういう言い方する段階でもっとアレですな。
C言語さえ覚えておけば食いっぱぐれないし即戦力な時代だったから当然でしょう。
Cの時代以前がPCやマイコン向けはアセンブラで書くのが当たり前でしたし。他のコンパイラ言語は実用性で問題があって、アセンブラと同等の速度で動いてアセンブラよりも生産性の高いCが持て囃されるのは当然の帰結というか唯一の選択だったし。それにプラスしてUNIXワークステーションによるダウンサイジングの流れ。あの頃はほんとにCの案件ばかりだった。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
ダメなものを批判していい気持ち (スコア:0)
昔、
Cプログラミング診断室
http://www.amazon.co.jp/dp/4774117870/ [amazon.co.jp]
というのを読むといいと勧められて読んだのですが、なんか作者の意地の悪さというか、批判の
しかたがいやーな感じでどうも評価できませんでした。
ダメなコードがなぜ生まれるのか、もっと体系的にまとめているのかと思っていたんだけど、
例もバラバラというか、酷いコードを見せては罵るみたいなパターンで。
別宮某の誤訳指摘本と同じで、こういうのって作者と一緒になって自分が上の立場から
悪口をいう快感を味合わさせるものになりがちな気がします。
Re:ダメなものを批判していい気持ち (スコア:0)
大学の一年生でC言語をいきなり教えたりするから、こんな悲惨な事になるんすよ。
最初はJavaかPascalかLispを教えるべきで、C言語は誰もが最初に学ぶような言語ではなかった。
なぜあの時代、「C言語はプログラマの基礎教養」「C言語ができずんばプログラマに非ず」「できなくても履歴書にC言語って書いておけ」みたいな風潮があったんでしょうねぇ。
今の時代になっては、「アセンブラができずんばプログラマに非ず」なんて吹かしている人間は、流石に見かけないはず…と思いたい。
Re:ダメなものを批判していい気持ち (スコア:2)
> なぜあの時代、「C言語はプログラマの基礎教養」「C言語ができずんばプログラマに非ず」「できなくても履歴書にC言語って書いておけ」みたいな風潮があったんでしょうねぇ。
いまさら、そんな話をされても……
当時のハードウェアで実用的なプログラムを書くことができ、生産性、移植性が高かったからですよ。
DOSマシンでも、8ビットマイコンでも、Unix WSでも使える言語、コンパイラが安く導入できる言語が他にありませんでしたから。
> 今の時代になっては、「アセンブラができずんばプログラマに非ず」なんて吹かしている人間は、流石に見かけないはず…と思いたい。
x86のシステムプログラムが書けるかという意味なら同意するけど、Z-80とか、8086でセグメントを越えないプログラムくらいは書けて欲しい。それらを事前に知らなくても、ポンとマニュアルを渡されたら、書ける程度の知識、能力。
人をプログラマと紹介されたら、その程度は前提にするのでは。
Re:ダメなものを批判していい気持ち (スコア:2)
なにせ試験問題に命令表が付属してくる。
解答付きの問題なんてそうそうあるもんじゃない。面白かった。
Re:ダメなものを批判していい気持ち (スコア:1)
言語はあんまり関係ないと思うなあ。
ifのような条件文がある言語なら、巨大なswitch文と同等なことを書けるので、手続き型言語ならほとんど同じことでは。Lispでも書きにくいけど書ける。
でも、学習・教育の問題とは思う。多くの場合、教育の段階で文法を教えるだけだから、課題を分析することなく、そのまま手続きにしてしまい、巨大なswitchのようなものができてしまう。
課題を分析するためには、既存のコンピュータの基本的な設計(CPUやメモリ、アドレスなど)と、それから導き出される効率的な各種アルゴリズム、たとえば配列の使い方(バイナリサーチやクイックサーチ、ハッシュなど)を教える必要がある。
けれども、それらがバラバラに教えられることがほとんどでしょう。コンピュータ系の学科でも、プログラミングの授業とアルゴリズムの授業が別々だったりする。それでは、フツーの学生や生徒には身につかない。
そうするとオンジョブトレーニングか、自己努力に依存するから、プログラマのレベルがバラバラで、製品の品質や生産性が上がらない。
Re: (スコア:0)
プログラムを学ぶのに、最初にC言語なのは勘弁して欲しい(文字列型やBOOL型がない言語なんて…)。
OOPを学ぶのに、最初にC++言語なのは勘弁して欲しい(リフレクションがないOO言語なんて…)。
CやC++は「最終到達点」となる言語であって、プログラムすることの本質が学べる言語ではないと思います。
bool型がないからint型で代用、いやメモリ節約のためchar型だ、なんてバッドノウハウ以外の何物でもない。
クイックソートやバイナリツリーを学ぶのに、C言語である必要性はどこにあるんでしょうか。PASCALでもよかったのではと。
Re:ダメなものを批判していい気持ち (スコア:2)
わたしの文章が悪かったのなら謝罪するが、Cが教育用として最適だなんて書いた覚えはない。ただ、手続き型言語なんか、所詮は同じ穴の狢で、本質的には大差ないという趣旨。
bool型の代わりにint型を使っても、何か大きな問題があるとは思えないし、文字列も最初は大きめの配列で扱えば良い。いちいちmalloc()とかする必要はない。
文字列処理が重要なら、何なら、BASIC風文字列関数をライブラリとして用意してやれば良いし、この際、PerlかRubに乗り換えても良い。
型があることがプログラミングを楽にするとの考えもあるが、schemeなどのように事実上、型をなくした言語もある。たとえば変数に関数を代入すれば、その変数が関数になる。Cで常にキャストを意識するとか、ポインタのポインタを扱うとか、そんなことを考えると、型はない方が楽。
Re: (スコア:0)
教育用にC言語が適しているとは思わないが、その理由は文字列型やBOOL型が無いからではない
Re: (スコア:0)
リファレンス型を備えてなく、代わりにポインタ(アドレス)を使わせるのは無いわー
C言語で誰もが「配列ポインタをインクリメント」する部分につまづくのは当然。こんな仕様がある言語は高水準言語と言わん。
Re: (スコア:0)
(リフレクションがないOO言語なんて…)
なんでOOPにリフレクションが必須だと思うの?
# まあ、あった方が便利だとは思うが。
Re: (スコア:0)
Re: (スコア:0)
メタシステムはやっぱりオブジェクトじゃないよねえ、という反省から出て来たのがmirror
Re: (スコア:0)
つ http://d.hatena.ne.jp/shi3z/20070911 [hatena.ne.jp]
Re: (スコア:0)
スラドは初めてか?「C/C++プログラマーにあらずばプログラマーにあらず」みたいなマッチョばかりですよ、ここは。
Re: (スコア:0)
COBOLを馬鹿にしCを賞賛する風潮はよくわかんなかったLisperです。
今日もこの星のどこかで、今まさに、Cプログラマがポインタを踏み外して脆弱性を産んでいる-。
ドライバを書くならともかく、会計計算レベルでC使っているのは何故なんだと。
そういう事務方の日々の雑務は、安全カミソリ言語でいいんじゃないのかなぁ。
CプログラマがCOBOLを馬鹿にしすぎるから、COBOLerが無理して覆面でC界隈に乗り込んできて、さらにひどい事態を引き起こす羽目になって全員不幸になりました。
そのまま大人しくCOBOL使わせておけば、こんな悲惨な事にならなかったのになぁ。
Re: (スコア:0)
>COBOLを馬鹿にしCを賞賛する風潮はよくわかんなかったLisperです。
こういう言い方する段階でもっとアレですな。
Re: (スコア:0)
C言語さえ覚えておけば食いっぱぐれないし即戦力な時代だったから当然でしょう。
Cの時代以前がPCやマイコン向けはアセンブラで書くのが当たり前でしたし。
他のコンパイラ言語は実用性で問題があって、アセンブラと同等の速度で動いてアセンブラよりも生産性の高いCが持て囃されるのは当然の帰結というか唯一の選択だったし。
それにプラスしてUNIXワークステーションによるダウンサイジングの流れ。
あの頃はほんとにCの案件ばかりだった。