パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

MSが大学に寄付してC#が必修科目に」記事へのコメント

  • 普通のやつらの上を行け [dreamhost.com]を引き合いに出すのが妥当かどうかは微妙ですが、
    そこまで言わないにしても、教育的「効果」の良し悪しってのものは、無視するわけにはいかないかも。

    どれだけ「良い」言語で勉強させるか?によって、出来上がる(^^;学生の質は
    結構変わってしまったりしないだろうか?ということです。

    心配するのはやっぱり、「言語は思考を規定する」という意味での、言語の影響力ですね。
    変な面のある言語で刷り込まれてしまうと、痛いわけで。
    たとえば往年の行番号BASICに刷り込まれた人々ってのも、それだったかなと。#そういやあれもMS由来だったなあ。

    そうい
    • > 心配するのはやっぱり、「言語は思考を規定する」という意味での、言語の影響力ですね。

      プログラミングを独習するには10年かかる [neweb.ne.jp]でも書いてあるが、
      プログラミング言語は複数学ぶことが必要だろう。
      そのうちの一つがC#であっても、何ら問題は無いと思われ。

      # 個人的には Lisp が必須だと思うが
      --
      # mishimaは本田透先生を熱烈に応援しています
      親コメント
      • >プログラミング言語は複数学ぶことが必要だろう。

        それもそうですね。少なくともどれか1つしかやったことが無い人ってのは
        「話にならない」感じがすることがしばしば有ります。
        言語の数だけ概念が有る(という言い方でもなお過小評価だが)わけだから、
        言語にかこつけて(^^;それらを片っ端から知っておくのは、損はなさそう。

        ただ、

        >そのうちの一つがC#であっても、何ら問題は無いと思われ。

        C#の実力とか、逆に「毒度」とかが、どうなってるか次第だと思います。
        なにごとも経験とはいっても、あんまり変な言語が「そのうち」に入っていると、ちょっとねえ。
        C#が変かどうかはさておきますが。

        ># 個人的には Lisp が必須だと思うが

        そうらしいですね。経験してないので、今ごろ困って(ってゆーか…)います(^^;
        親コメント
        • 言語の数だけ概念が有る(という言い方でもなお過小評価だが)わけだから、
          言語にかこつけて(^^;それらを片っ端から知っておくのは、損はなさそう。

          同意. 少なくともその言語を作った人は「既存の言語ではだめ」と思って作ったわけですし. プログラム言語をいじることによって,その言語の作者の思想に触れる,というのはあると思います.

          で,更にプログラミングの概念の歴史的変遷,というのも見えてきますね.

          親コメント
          • by moonbear (4602) on 2002年08月17日 22時07分 (#147971)
            複数の言語や実行環境によるプログラミング学習は必須だと思います.

            現状でも,情報系の学科・コースでは複数の言語を扱っている所がほとんどなのですが,それらの間の諸概念の関連を(理論的内容もある程度含めて)きちんと扱っている授業は案外少ないようです.その辺を理解していないと,多くの学生さんは結局メジャーとされる言語(例えばCなど)だけわかっていればいいと思ってしまうようです.

            Cなどによる初歩的なプログラミングの講義を受講した学生を対象にHaskellやStandard MLを使った講義をしたことがあります.後でまたCのプログラムを書く際,プログラムの見通しがよくなってバグが少なくなったと報告してくれた学生が複数いたのがちょっとうれしかったです.

            あと,言語だけでなく仮想機械やミドルウェアのような実行環境もいろいろ経験するといいのでしょうが,大学の講義や演習ではなかなか全てをカバーしきれませんね.教えられる人も限られてきてしまいますし.
            親コメント
        • >C#の実力とか、逆に「毒度」とかが、どうなってるか次第だと思います。

          「毒度」ってなに?はさておき、言語ってプログラミング言語に関わらず、「考え方」を規定するのでどの言語が悪いかなんて、へんな考
      • by Anonymous Coward on 2002年08月18日 0時03分 (#148010)
        勉強を始めてから10年後に複数の言語を修得している、というのは確かにそうなんだが、最初のピックがどれかによって、その10年の内容/充実度が変わるとしたら、どうだろう?

        言語そのものからくる繁雑な制約を気にせずに、問題をどう解くかだけに専念しやすい言語から入ることで、まずはプログラムを書くときに何に注目しなければいけないかをしっかり学ばせたほうが良い、というコンセンサスがアメリカの計算機学科界隈にはできあがっているような気がする。そういう判断から、実際に学部1年向けにscheme、ML、HaskellやJavaといった比較的「評判」の良い言語を使っている計算機学科が多いのだと思う。
        親コメント
      • # 個人的には Lisp が必須だと思うが
        C#のパラダイムでLispの概念はほとんど包含できてると思うけどな。しかも型付きで。

        データも関数も区別なくS式なのがよい? C#はXML Schemaのインテリジェンスを使って自動的にデータを扱えるよ。

        • まじで?俺が知らんだけで無名関数とかクロージャとかあんの?末尾再帰も?

          んー、C# の詳しい文法を知らんので何とも言えんが、
          オブジェクト指向言語と関数型言語のパラダイムの違いについては
          こんなスレ [2ch.net]があるよ。
          --
          # mishimaは本田透先生を熱烈に応援しています
          親コメント
          • さらに、継続とか強力なマクロとか。C#がLispの概念をほとんど取り入れているって考えてるやつは、Scheme(Lispの方言)を調べてみたほうがいいぞ。シンプルながら変な機能が多くて勉強になるから。
            • Call-CCなんかは例外で十分。プログラミングモデルを壊すだけ。
              • >プログラミングモデルを壊すだけ。

                (特定の)モデルを仮定すれば、そこでLisp系のモデルのうちの幾つかの要素を取りこぼしている恐れが、つきまとうんではないですか?
                少なくとも今回(C#対Lisp)においては、取りこぼすような気がします。

                「例外で十分」と言い切っちゃった瞬間に、Call-CCに出来て例外に出来ない何かを「切り捨てて」しまっただけのことであって。

                ほげ言語のパラドックス [dreamhost.com]を思い出します。
                いや、Lispであることとか、その優位性とか、についてはここではどうでもいいんですが、
                少なくとも、馴染んでるものとは「違う」言語の能力を、どう取りこぼさずに認識するか?ってのは、問題であるように思います。
                親コメント
              • Call-CCなんかは例外で十分。プログラミングモデルを壊すだけ。

                継続は、その実用的な価値よりも、スタック型計算モデル (関数を呼んだらスタックの上のほうで計算されて、帰って来たら それでおしまい)みたいな概念をぶちこわす存在として 有益であるような。継続的な見方 (call/ccに限らず、 継続渡し的に制御フローを見るやりかた)は、 関数呼び出しと関数からのリターンは実は同じであるとか、 普通の手続き型言語をやっていたのではなかなか お目にかかれない概念を提供してくれます。 ただ、初心者に教えるべきかどうかは確かに疑問。 ある程度、プログラミングモデルが固まった時に教えて 新鮮な見方を提供するって方がいいのでしょう。

                親コメント
              • call-ccと例外の関係は、CのポインタとJava等の参照の関係に似てると思う。ポインタだとなんでもできるから、ポインタの方がいいといってるのと同じ程度のいい加減な議論。なぜcall-ccが重要でどんなアドバンテージがあるか具体的に示せないのなら。
          • 無名関数とかクロージャとかあんの?末尾再帰も?
            末尾再帰はないかもしれないけど、クロージャ相当はdelegateってのがあるよ。イベントハンドラを実装するための基礎になってる。
            • delegateは確かに(状態+処理を渡せるという意味では)クロージャと 等価だけれども、lambdaみたいにインラインでコードブロックを がんがん書いてそれが自動的に状態を内包してくれる、という感覚 とはかなり違うと思います。

              PythonとLispの関係について [dreamhost.com]」 でPaul Prescodが反論しているように、内包される状態は インスタンス変数という形でプログラマが明示的に指定すべき、 というのもまた一つのパラダイムでしょうが、それは クラスを作らなくてもlambdaでお気軽に状態を包んでしまえる のとはやっぱりスタイルが違うので、善し悪しは別にして 両方学んでおくのは有意義でしょう。

              あ、今までdelegateにコードブロックを直接渡せるという例を 見たことがないのでこう書いていますが、もしそういうことも できる(そしてそのコードブロックから参照される変数が クローズされる)のならこの意見は当てはまりませんね。 ただ、Schemeなんかのクロージャのひとつの基礎になっているのは 「全ての変数は無限エクステントを持つ」というモデルなので、 変数がローカルフレームと命運を共にする モデルとはやっぱり相容れないように思えます。

              親コメント

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

処理中...