アカウント名:
パスワード:
業務内容によってはその方面の数学の知識は当然必要になるでしょうが、純粋に「プログラミング」という点に絞るとそう単純な問題でもないような。
「プログラマとして食っていくなら、これはないと話にならんだろ」というのはどのあたりでしょう?
定番ですが良いプログラマは数学を学ぶ、方が良いと思う [dti.ne.jp]
>業務内容によってはその方面の数学の知識は当然必要になるでしょうが、純粋に「プログラミング」という点に絞るとそう単純な問題でもないような。
そうだよね。数学とか算数を知らなくても、詳細な仕様書通りにコードを作るだけのプログラミングだと、不要な局面が多いよね。逆に、仕様書が「利益率を計算する」みたいなのだと、だめになるとかもありそう。
>「プログラマとして食っていくなら、これはないと話にならんだろ」というのはどのあたりでしょう?
言語の仕様書とプロダクトの仕様書を読む能力と、不明点を調べる能力だと思うな。
意味不明な仕様書を書きあげる人間の方が多いので、「これどういう意味ですか?」って聞けばいいだけだと思う
>意味不明な仕様書を書きあげる人間の方が多いので、「これどういう意味ですか?」って聞けばいいだけだと思う
そう、それが「プロダクトの仕様書を読む能力と、不明点を調べる能力」
なのだけど、たまに仕様書を書いている方が不明確な人だと、「えーとね、適当に」とか、ほんとに適当なことになったりするわけです。プログラマも適当だったりして、それはそれで適当なプログラムが出来上がったりするわけです。
他の人がいってるように詳細設計(フロチャートレベル)が済んだものをコードに落とすだけの仕事なら数学は(あまり)要らないだろうけど。でも、「nの三乗」が n*n*n だってことも分からんほどの奴はどうせ(国語も含めて)他の分野もボロボロなんでロクなプログラマにはなれないのでは?。
代入の概念。繰り返しの概念、条件分岐の概念。
moveならまだいいじゃない定数ロードやレジスタ間の値の移動だけでなぜか見た目上は演算が必要なoriだのaddiでないならw(書くときは疑似命令liやlaやmvが使えるが、デバッグのときにはoriやaddiになってしまっている。)
そうなっている理屈はわかるが読みやすいとは言えないw > Mips
何か問題があるの?#compareで代入するなら大問題だがw
8086ならMOV AX,CSじゃないの?
こういう誤解が起こらないよう英単語が判るようになる前にプログラミング言語を教えるべきですね
初めてプログラミング言語を教わったとき、「代入したら、既存の値は捨てられる」ことがなかなか理解できなかったです。
そこらへん、Cのように「変数がメモリ上にあって、そこに値を書き込んでいるから」という、本質的かつ直感的なモデルは分かりやすいですよね。変更可能だとか名前の束縛だとかよりもずっと。
だから「代入って名前がついてるけど、これは左辺に入ってたのを捨てて、新しく右辺値を入れるって意味だよ」と説明するんですよ。結局、代入したら値が捨てられることは覚えないといけないのには変わらないけど、その疑問に対する答えが「なるものはなる」や、わけわからん言葉ばっかで結局覚えるしかない答えのときと比べて、今後の伸び方が違いますよ。
最初に習った言語がHaskellだったとか。
数学科を出て某大学院の情報系研究科に入学した知人の話。その人は大学院で初めてプログラミングを勉強したのですが、最初に出会ったプログラミング言語がHaskellとPrologで、研究内容は項書き換えシステムだったせいか、後でCやJavaの破壊的代入やループの概念の習得にちょっと苦労したとか。たまにはそういう人もいるわけです。
そうでなくても代入演算子が数学の等号と同じなのは初学者には混乱の元だと思う。何で := や - とかにしなかったのやら。
某大学ではマルチリンガル推奨ということで学部生向きに初歩のJavaと初歩のLisp(Scheme)を同時進行でやってましたが、私がTAバイトしたときに代入概念へのとっつきの違いで割とはっきりJava得意派とLisp得意派に分かれたのが印象的でした。
代入で躓くと手続き型のコードが書きにくいには自然ですが、面白かったのはLispの時で代入概念が身についていると代入できないことを不自由と感じLispっぽい書き方で躓くのに対し、代入概念がなければないでLisp的コードへの抵抗がないようでした。
ちゃんと数えたわけでなく印象ですが、前者には趣味等でのプログラミング経験者が多く、後者は数学好きが多かったような印象があります。
そうでなくても代入演算子が数学の等号と同じなのは初学者には混乱の元だと思う。何で := や <- とかにしなかったのやら。
# 「本物のプログラマ」は、SmalltalkはともかくPascalは使わんからなあ…。:-)
真偽のほどは分かりませんが、代入のほうが比較より圧倒的に多いから、タイプが少なくて済むように'='1文字を割り当てた、という話はよく聞きますね。
初学者のバグ原因になりうることとのメリットデメリットのバランスについての評価はどうなのでしょうね。
> 初学者のバグ原因初学者がC/C++使うな。本物のプログラマも初学者も使わなかったらいったい誰がPascal使うんだ。
私の経験だと、大学の学部一年生がはじめてプログラミングを習う時に、代入(C的な意味で) で躓く人が割と多かったですね。n = n + 1 が分からないと言われたときは耳を疑いましたが、変数が副作用(代入も副作用ですね)によって刻々と変化していくこと自体、高校の数学ではなかったことですから。彼らにはCやJavaじゃなくて、(純粋)関数型言語を教えたほうがいいのかもしれません。
大学の先生の教え方で良くないな。と思ったのは
「右から処理していく」ことを教えないこと。
今まで左からしか式見てないんだもん。なんじゃこりゃってなりますよ。
後の方でそういう話は出てくるのですが…。
>代入が理解できない後輩に出会った時は死にたくなった
純粋関数型言語の使用者を敵に回したなwhttp://ja.wikipedia.org/wiki/%E9%96%A2%E6%95%B0%E5%9E%8B%E8%A8%80%E8%AA%9E [wikipedia.org]
>ただし業界にはその価値を理解できる人間はそういないので
理解とかの問題じゃないんですよ。そういう仕事は多くないんです。金を払う人がいないのです。
いわゆる下請けにいるなら勉強してもほとんど意味無いです。上から降って来た仕事に空いてる要員を放り込むだけですから。
# 独立を画策しようにも、数学の方向で売り物になる人なんて# もともと下請けソフトウェア関係に行かないよねw
> 「プログラマとして食っていくなら、これはないと話にならんだろ」というのはどのあたりでしょう?「いかにループにするか」を素早く適切に思いつけること。
ま、まさか再帰ですか、神よ?
#ところで「人は繰り返し、神は再帰する」って原典どこなんでしょう?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
オ・ド・ロ・キ (スコア:0)
最近のアプリケーション・ソフト屋さんってどうなってるんだと感じることの多い理由が理解できた
Re:オ・ド・ロ・キ (スコア:2)
業務内容によってはその方面の数学の知識は当然必要になるでしょうが、純粋に「プログラミング」という点に絞るとそう単純な問題でもないような。
「プログラマとして食っていくなら、これはないと話にならんだろ」というのはどのあたりでしょう?
Re:オ・ド・ロ・キ (スコア:2, 参考になる)
定番ですが
良いプログラマは数学を学ぶ、方が良いと思う [dti.ne.jp]
Re:オ・ド・ロ・キ (スコア:1)
>業務内容によってはその方面の数学の知識は当然必要になるでしょうが、純粋に「プログラミング」という点に絞るとそう単純な問題でもないような。
そうだよね。
数学とか算数を知らなくても、詳細な仕様書通りにコードを作るだけのプログラミングだと、不要な局面が多いよね。
逆に、仕様書が「利益率を計算する」みたいなのだと、だめになるとかもありそう。
>「プログラマとして食っていくなら、これはないと話にならんだろ」というのはどのあたりでしょう?
言語の仕様書とプロダクトの仕様書を読む能力と、不明点を調べる能力だと思うな。
Re: (スコア:0)
意味不明な仕様書を書きあげる人間の方が多いので、「これどういう意味ですか?」って聞けばいいだけだと思う
Re:オ・ド・ロ・キ (スコア:1)
>意味不明な仕様書を書きあげる人間の方が多いので、「これどういう意味ですか?」って聞けばいいだけだと思う
そう、それが「プロダクトの仕様書を読む能力と、不明点を調べる能力」
なのだけど、たまに仕様書を書いている方が不明確な人だと、「えーとね、適当に」とか、ほんとに適当なことになったりするわけです。
プログラマも適当だったりして、それはそれで適当なプログラムが出来上がったりするわけです。
Re:オ・ド・ロ・キ (スコア:1)
(初歩の)計算量理論がわかる程度の数学力かな。それと数学的帰納法。
二重のfor文で処理している関数をfor文の中から呼び出すってことはサイズの三乗比例の時間が最悪かかる、とかいうことをちゃんと分かっててほしい。つまり問題を見たときに素直な(straightforward)処理で問題なさげかあるいはなんか効率的なアルゴリズムをもってこないとマズそうか判断できることが必要。 同様に、自分のプログラムに100MBのテストデータを食わせたときにXMBのメモリを消費してY秒で処理が終わったとして、実際に処理したいデータは10GBなんだがどれだけメモリ/処理時間を喰いそうかがざっと概算で予想できるためにも。
まぁ「30個の要素を小さい順に並べ替えるには 30の階乗ステップという膨大なプログラムを書かないといけないので無理です(キリッ)」なんて奴も居たそうなんで。量がちゃんと見積もれるけどダメなプログラマってのも居る。
他の人がいってるように詳細設計(フロチャートレベル)が済んだものをコードに落とすだけの仕事なら数学は(あまり)要らないだろうけど。でも、「nの三乗」が n*n*n だってことも分からんほどの奴はどうせ(国語も含めて)他の分野もボロボロなんでロクなプログラマにはなれないのでは?。
Re: (スコア:0)
代入の概念。繰り返しの概念、条件分岐の概念。
Re:オ・ド・ロ・キ (スコア:2, 興味深い)
Re:オ・ド・ロ・キ (スコア:3, 興味深い)
Re:オ・ド・ロ・キ (スコア:2)
そういえば8086アセンブリのニーモニックでも
MOV AH,CS
みたいに代入のくせにMOVeだもんな。
Re:オ・ド・ロ・キ (スコア:1)
moveならまだいいじゃない
定数ロードやレジスタ間の値の移動だけでなぜか見た目上は演算が必要なoriだのaddiでないならw
(書くときは疑似命令liやlaやmvが使えるが、デバッグのときにはoriやaddiになってしまっている。)
そうなっている理屈はわかるが読みやすいとは言えないw > Mips
Re: (スコア:0)
何か問題があるの?
#compareで代入するなら大問題だがw
Re: (スコア:0)
8086なら
MOV AX,CS
じゃないの?
Re: (スコア:0)
こういう誤解が起こらないよう
英単語が判るようになる前にプログラミング言語を教えるべきですね
Re: (スコア:0)
異なるんじゃないか?という話でしょ。
直感的でないなぁ、Copyならしっくりくるなぁ、っていう話かと。
Re:オ・ド・ロ・キ (スコア:1)
Re:オ・ド・ロ・キ (スコア:2)
#いや、最初はMOV AH,4Chって書いてたのよ。それだと分かりにくいから替えたら・・・
Re: (スコア:0)
初めてプログラミング言語を教わったとき、「代入したら、既存の値は捨てられる」ことがなかなか理解できなかったです。
Re:オ・ド・ロ・キ (スコア:1)
そこらへん、Cのように「変数がメモリ上にあって、そこに値を書き込んでいるから」という、本質的かつ直感的なモデルは分かりやすいですよね。
変更可能だとか名前の束縛だとかよりもずっと。
1を聞いて0を知れ!
Re: (スコア:0)
Re:オ・ド・ロ・キ (スコア:1)
Re:オ・ド・ロ・キ (スコア:1)
だから「代入って名前がついてるけど、これは左辺に入ってたのを捨てて、新しく右辺値を入れるって意味だよ」と説明するんですよ。
結局、代入したら値が捨てられることは覚えないといけないのには変わらないけど、その疑問に対する答えが「なるものはなる」や、わけわからん言葉ばっかで結局覚えるしかない答えのときと比べて、今後の伸び方が違いますよ。
1を聞いて0を知れ!
Re: (スコア:0)
最初に習った言語がHaskellだったとか。
数学科を出て某大学院の情報系研究科に入学した知人の話。その人は大学院で初めてプログラミングを勉強したのですが、
最初に出会ったプログラミング言語がHaskellとPrologで、研究内容は項書き換えシステムだったせいか、後でCやJavaの
破壊的代入やループの概念の習得にちょっと苦労したとか。たまにはそういう人もいるわけです。
そうでなくても代入演算子が数学の等号と同じなのは初学者には混乱の元だと思う。何で := や - とかにしなかったのやら。
Re:オ・ド・ロ・キ (スコア:3, 興味深い)
某大学ではマルチリンガル推奨ということで学部生向きに初歩のJavaと初歩のLisp(Scheme)を同時進行でやってましたが、
私がTAバイトしたときに代入概念へのとっつきの違いで割とはっきりJava得意派とLisp得意派に分かれたのが印象的でした。
代入で躓くと手続き型のコードが書きにくいには自然ですが、面白かったのはLispの時で
代入概念が身についていると代入できないことを不自由と感じLispっぽい書き方で躓くのに対し、
代入概念がなければないでLisp的コードへの抵抗がないようでした。
ちゃんと数えたわけでなく印象ですが、前者には趣味等でのプログラミング経験者が多く、
後者は数学好きが多かったような印象があります。
Re:オ・ド・ロ・キ (スコア:2)
# 「本物のプログラマ」は、SmalltalkはともかくPascalは使わんからなあ…。:-)
真偽のほどは分かりませんが、代入のほうが比較より圧倒的に多いから、タイプが少なくて済むように'='1文字を割り当てた、という話はよく聞きますね。
初学者のバグ原因になりうることとのメリットデメリットのバランスについての評価はどうなのでしょうね。
Re: (スコア:0)
> 初学者のバグ原因
初学者がC/C++使うな。本物のプログラマも初学者も使わなかったらいったい誰がPascal使うんだ。
Re: (スコア:0)
私の経験だと、大学の学部一年生がはじめてプログラミングを習う時に、代入(C的な意味で) で躓く人が割と多かったですね。n = n + 1 が分からないと言われたときは耳を疑いましたが、変数が副作用(代入も副作用ですね)によって刻々と変化していくこと自体、高校の数学ではなかったことですから。彼らにはCやJavaじゃなくて、(純粋)関数型言語を教えたほうがいいのかもしれません。
Re:オ・ド・ロ・キ (スコア:2)
大学の先生の教え方で良くないな。と思ったのは
「右から処理していく」ことを教えないこと。
今まで左からしか式見てないんだもん。
なんじゃこりゃってなりますよ。
後の方でそういう話は出てくるのですが…。
Re: (スコア:0)
>代入が理解できない後輩に出会った時は死にたくなった
純粋関数型言語の使用者を敵に回したなw
http://ja.wikipedia.org/wiki/%E9%96%A2%E6%95%B0%E5%9E%8B%E8%A8%80%E8%AA%9E [wikipedia.org]
Re:オ・ド・ロ・キ (スコア:1)
Re: (スコア:0)
文系でも学歴にハクだけ付けときゃ大手奴隷商人会社に入れるでしょう
奴隷でいいなら中学生レベル
ほっとくと最初から最後までこのレベルのままで終わりますが
それ以上を望むなら高校理系コース程度+コンピュータサイエンス
ただし業界にはその価値を理解できる人間はそういないので
奴隷の中に放り込まれないような立ち回りが必要です
エッジな領域で活躍したいならもちろんAクラス大学(院)レベル
ただしあまりマニアックな方向に行き過ぎないよう注意が必要です
Re: (スコア:0)
>ただし業界にはその価値を理解できる人間はそういないので
理解とかの問題じゃないんですよ。
そういう仕事は多くないんです。金を払う人がいないのです。
いわゆる下請けにいるなら勉強してもほとんど意味無いです。
上から降って来た仕事に空いてる要員を放り込むだけですから。
# 独立を画策しようにも、数学の方向で売り物になる人なんて
# もともと下請けソフトウェア関係に行かないよねw
Re: (スコア:0)
中学生レベルじゃダメだってことです
Re: (スコア:0)
> 「プログラマとして食っていくなら、これはないと話にならんだろ」というのはどのあたりでしょう?
「いかにループにするか」を素早く適切に思いつけること。
Re: (スコア:0)
人は繰り返し、神は再帰する (スコア:1)
ま、まさか再帰ですか、神よ?
#ところで「人は繰り返し、神は再帰する」って原典どこなんでしょう?
Re: (スコア:0)
Concrete Mathematics: A Foundation for Computer Science
なんぞを囓ってればプログラマとして一通りの仕事は出来ると思う。(全部を読破する必要は無い)
大学入試で重要視される微積分なんぞの必要性は低い。
それよりも組合せ、整数論、線形代数、幾何学等の基礎を知っておいて欲しい。
(これらは微積分と違って自学自習でも躓かずになんとかなるはず)
要は難しいと思われている数学の代表選手である微積分より、パズル/ゲーム、グラフィックスで必要とされるような数学的原理の基礎が分かってれば問題ないのでは?