アカウント名:
パスワード:
うちの大学でも、情報系の専門科目では教授の趣味でMLが採用されている演習があるらしいです。半年の講義を2つに分けて、半分Java、半分MLという中途半端な構成。それでオブジェクト指向と関数型言語の両方の概念を理解できた人がどれくらいいるのかは分かりません。
そういえば僕の母校も今は関数型言語をかじらせるのにはML使っているらしい。僕が学生の頃は関数型の例としてはLISP1.4だった。
それより、助手に丸投げすることが多い演習科目にちゃんと教授がかかわっているんですね。
担当としては、准教授一人と助手とTAだったと思います。
関数型言語も理解が必要というのは、分かります。私の中では、MLはいまいちマイナーな言語で、関数型ならSchemeとかのLisp系を思い浮かべるのですが、関数型言語に詳しい人から見れば、全然そんなこともないんでしょうか。
関数型言語としてMLは非常に優秀だと思います。OCamlは実用性も非常に高いですし。2ヶ月あれば、リストと再帰を使って各種アルゴリズムを実装することにも慣れると思います。
誰なら2ヶ月？ 学部生の程度はバラバラ、特に今は名前が書ければどこかには入学できる状況だから、そんなに甘くないでしょう。現代だと入学までPCを触ったことがない学生は少ないだろうけど、プログラミングは別。以前より減ってるでしょう。
誰なら2ヶ月？ 学部生の程度はバラバラ、特に今は名前が書ければどこかには入学できる状況だから、そんなに甘くないでしょう。
それは極論ではないですか？さすがに名前を書くだけで入れるような大学の学生は想定していません。そのような学生は、関数型言語に限らず何を教えても同じだと思います。入学前にプログラミング経験の無い学生は以前から存在していましたし、他の講義で必要な予備知識はある程度身に付くと思います。1年生の前期の講義だとしたら厳しいですが、2年生位で教えるのなら適切かと思います。その際には#1586247 [srad.jp]で言及されているような体制が必要なのは言うまでもありませんが。
教授の趣味って言いようは酷いなあ．プログラミングの基礎知識は他の科目で身につけてるはずなんだから，OO/Functional Programmingの基礎を学ぶのに2ヶ月づつもあれば足りるでしょう．# 基礎以上の事を学部の授業で教える時間はありませんから，独習なり大学院なりで，自分が興味を持った分野を掘り下げてください．
「教授の趣味」は酷い、というのに同意。「大学」の「情報系」学部ならそのくらいのペースで異なるパラダイムの言語をやってしかるべき。
もちろん講義だけじゃ身に着かないから、平行して実習をどかどかやるか課題をがんがん出して、TAをたくさん雇ってサポートさせる。
現実問題として「ついていけない」人が出てきてしまうとしたら、それはたぶん後者のサポートができていないんだと思う。突っ込むべきはそっちの方だろうね。
「大学」の「情報系」学部でやることは、言語を教えることじゃないですよ。情報の処理の仕方を考えさせることです。（学ぶ、だと語弊がちょっとあるかも）専門学校だったらプログラマ養成するんだから言語教える意味はなくもないですけどね。
たとえばアルゴリズムだったり、暗号化の基礎理論だったり、信号理論だったり。言語はそのための手段でしかありませんから、極端な話「なくたって講義としては成り立つ」んです。
つーかね。言語なんてアルゴリズムさえ先にきっちりできてれば、どうにかなるっての。言語ができない人というのは、実のところその前段階の、「どうやりたいことを表現するのかが分からない」人なので。
あるプログラミング言語を習得することのみが目的であるような講義は不要ですが、情報系の学部であれば、異なるプログラミングパラダイムを学ぶのは非常に重要なことです。命令型と宣言型では基礎とする理論が全く違いますから。ちなみにプログラミング言語論もアルゴリズム論などと同じくコンピュータサイエンスの中核をなす重要な分野なので、無くても成り立つと言うのは乱暴に過ぎます。
> ちなみにプログラミング言語論もアルゴリズム論などと同じくコンピュータサイエンスの中核をなす重要な分野なので、無くても成り立つと言うのは乱暴に過ぎます。
プログラミング言語論であれば、Schemeなどで様々なプログラミングパラダイムを実装して学ぶこともできます。http://portal.acm.org/citation.cfm?id=78092 [acm.org]オブジェクト指向を学ぶのにSmalltalkやC++を使わず、Scheme上にオブジェクト指向ライブラリを自分で実装してそれを使ったということです。どのような仕組みになっているのかも学べて一石二鳥です。
このスレッドで問われているのは、言語固有の体験が必要か？ということだと理解しています。はっきりと不要と言えるでしょう。あればよりよいものですが、授業では上っ面をなでておしまいになるのが関の山です。
> つーかね。言語なんてアルゴリズムさえ先にきっちりできてれば、どうにかなるっての。
英語なんて国語さえ先にきっちりできればどうにかなるっていうわけではないよね。
うちの大学（某国立大学）では、情報系のB4,M1～D2までのTA(*A)が常に2-5人は常駐しています。これは、ある特定の講義の担当ではなく、全学生担当といった位置付けです。
当然ですが、各講義でもTA(*B)が学生30-40名あたり1人程度はつきます（こっちのTAは講義担当の教授の研究室の人間）。ただし、例外で上記の常駐TA(*A)がサポートに行くことがある。
課外時間にレポート課題などで質問がある場合、講義担当の教授やTA(*B)は離れたキャンパスの研究室なので、質問したくてもできません。その場にいるTA(*A)に質問します。TA(*A)の方はほぼ質問に対応可能です（できない場合でもほかのTAでカバー可能になってます）
> もちろん講義だけじゃ身に着かないから、平行して実習をどかどかやるか> 課題をがんがん出して、TAをたくさん雇ってサポートさせるおそらく、常駐TAがいない環境だと、課題乱発した際に質問したくてもできなく、頓挫するでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
不要 (スコア:2, 興味深い)
全くの無駄でした
役に立った事など一度もありません
他のクラスがパソコンでCやBASICをやっている時に
なぜ自分は汎用機でFORTRANなのかと
なぜ二桁の掛け算の結果が出るまでに15分もかかるのかと
まあ確かに座学でプログラム言語の一つとして学ぶ分には
完全に枯れた物なので最適かもしれませんが、
講師の趣味で実用性度外視の講義を受けさせられる学生の身にもなって欲しいと思います
Re:不要 (スコア:1)
うちの大学でも、情報系の専門科目では教授の趣味でMLが採用されている演習があるらしいです。
半年の講義を2つに分けて、半分Java、半分MLという中途半端な構成。それでオブジェクト指向と関数型言語の両方の概念を理解できた人がどれくらいいるのかは分かりません。
1を聞いて0を知れ!
Re:不要 (スコア:3, 興味深い)
そういえば僕の母校も今は関数型言語をかじらせるのにはML使っているらしい。僕が学生の頃は関数型の例としてはLISP1.4だった。
それより、助手に丸投げすることが多い演習科目にちゃんと教授がかかわっているんですね。
Re:不要 (スコア:1)
担当としては、准教授一人と助手とTAだったと思います。
関数型言語も理解が必要というのは、分かります。
私の中では、MLはいまいちマイナーな言語で、関数型ならSchemeとかのLisp系を思い浮かべるのですが、
関数型言語に詳しい人から見れば、全然そんなこともないんでしょうか。
1を聞いて0を知れ!
Re: (スコア:0)
詳しいわけではありませんが、Schemeはむしろ手続き型言語ですね。R2RSか3あたりにはそういう記述がありました。
Re:不要 (スコア:1)
関数型言語としてMLは非常に優秀だと思います。OCamlは実用性も非常に高いですし。2ヶ月あれば、リストと再帰を使って各種アルゴリズムを実装することにも慣れると思います。
Re:不要 (スコア:2)
誰なら2ヶ月？ 学部生の程度はバラバラ、特に今は名前が書ければどこかには入学できる状況だから、そんなに甘くないでしょう。現代だと入学までPCを触ったことがない学生は少ないだろうけど、プログラミングは別。以前より減ってるでしょう。
Re:不要 (スコア:1)
それは極論ではないですか？さすがに名前を書くだけで入れるような大学の学生は想定していません。そのような学生は、関数型言語に限らず何を教えても同じだと思います。入学前にプログラミング経験の無い学生は以前から存在していましたし、他の講義で必要な予備知識はある程度身に付くと思います。1年生の前期の講義だとしたら厳しいですが、2年生位で教えるのなら適切かと思います。その際には#1586247 [srad.jp]で言及されているような体制が必要なのは言うまでもありませんが。
Re: (スコア:0)
教授の趣味って言いようは酷いなあ．
プログラミングの基礎知識は他の科目で身につけてるはずなんだから，OO/Functional Programmingの基礎を学ぶのに2ヶ月づつもあれば足りるでしょう．
# 基礎以上の事を学部の授業で教える時間はありませんから，独習なり大学院なりで，自分が興味を持った分野を掘り下げてください．
Re: (スコア:0)
自分で勉強しな学生は何教えても無駄なんだが学生のやる気を削ぐようなまずい教え方がまかり通ってる。
スタンフォードのように授業を録画してyoutubeに流すとか、そういうことすればいいんじゃないかな、
大学の差別化にもなるし。それを不快に思う程度の授業しかしてない奴は失格ってことで。
学生や税金から金取ってる以上責任を果たさないとね。
Re: (スコア:0)
「教授の趣味」は酷い、というのに同意。「大学」の「情報系」学部ならそのくらいの
ペースで異なるパラダイムの言語をやってしかるべき。
もちろん講義だけじゃ身に着かないから、平行して実習をどかどかやるか
課題をがんがん出して、TAをたくさん雇ってサポートさせる。
現実問題として「ついていけない」人が出てきてしまうとしたら、それはたぶん
後者のサポートができていないんだと思う。突っ込むべきはそっちの方だろうね。
Re:不要 (スコア:1)
「大学」の「情報系」学部でやることは、言語を教えることじゃないですよ。
情報の処理の仕方を考えさせることです。（学ぶ、だと語弊がちょっとあるかも）
専門学校だったらプログラマ養成するんだから言語教える意味はなくもないですけどね。
たとえばアルゴリズムだったり、暗号化の基礎理論だったり、信号理論だったり。言語はそのための手段でしかありませんから、極端な話「なくたって講義としては成り立つ」んです。
つーかね。言語なんてアルゴリズムさえ先にきっちりできてれば、どうにかなるっての。言語ができない人というのは、実のところその前段階の、「どうやりたいことを表現するのかが分からない」人なので。
-- To be sincere...
Re:不要 (スコア:1)
あるプログラミング言語を習得することのみが目的であるような講義は不要ですが、情報系の学部であれば、異なるプログラミングパラダイムを学ぶのは非常に重要なことです。命令型と宣言型では基礎とする理論が全く違いますから。ちなみにプログラミング言語論もアルゴリズム論などと同じくコンピュータサイエンスの中核をなす重要な分野なので、無くても成り立つと言うのは乱暴に過ぎます。
Re: (スコア:0)
> ちなみにプログラミング言語論もアルゴリズム論などと同じくコンピュータサイエンスの中核をなす重要な分野なので、無くても成り立つと言うのは乱暴に過ぎます。
プログラミング言語論であれば、Schemeなどで様々なプログラミングパラダイムを実装して学ぶこともできます。
http://portal.acm.org/citation.cfm?id=78092 [acm.org]
オブジェクト指向を学ぶのにSmalltalkやC++を使わず、Scheme上にオブジェクト指向ライブラリを自分で実装してそれを使ったということです。どのような仕組みになっているのかも学べて一石二鳥です。
このスレッドで問われているのは、言語固有の体験が必要か？ということだと理解しています。はっきりと不要と言えるでしょう。
あればよりよいものですが、授業では上っ面をなでておしまいになるのが関の山です。
Re: (スコア:0)
> つーかね。言語なんてアルゴリズムさえ先にきっちりできてれば、どうにかなるっての。
英語なんて国語さえ先にきっちりできればどうにかなるっていうわけではないよね。
Re: (スコア:0)
国語がきっちりできていない人が大半ですので、そこを改善すれば英語もぐっとできるようになりますよ。
Re:不要 (スコア:1, 興味深い)
> もちろん講義だけじゃ身に着かないから、平行して実習をどかどかやるか
> 課題をがんがん出して、TAをたくさん雇ってサポートさせる
これって実際にできてます？
Re:不要 (スコア:1, 参考になる)
うちの大学（某国立大学）では、情報系のB4,M1～D2までのTA(*A)が常に2-5人は常駐しています。
これは、ある特定の講義の担当ではなく、全学生担当といった位置付けです。
当然ですが、各講義でもTA(*B)が学生30-40名あたり1人程度はつきます（こっちのTAは講義担当の教授の研究室の人間）。
ただし、例外で上記の常駐TA(*A)がサポートに行くことがある。
課外時間にレポート課題などで質問がある場合、講義担当の教授やTA(*B)は離れたキャンパスの研究室なので、質問したくてもできません。
その場にいるTA(*A)に質問します。TA(*A)の方はほぼ質問に対応可能です（できない場合でもほかのTAでカバー可能になってます）
> もちろん講義だけじゃ身に着かないから、平行して実習をどかどかやるか
> 課題をがんがん出して、TAをたくさん雇ってサポートさせる
おそらく、常駐TAがいない環境だと、課題乱発した際に質問したくてもできなく、頓挫するでしょう。