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

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

  • それを言ったら (スコア:2, 参考になる)

    by stosh (4158) on 2002年08月17日 15時22分 (#147846) 日記
    6年くらい前に大学生だった頃、某N大学の一般教養課程の
    情報処理の講義で(必須かどうかは自信がありませんが)、
    Fortranを未だに使ってコード書かせていたのにビックリしました。

    実務と教育の世界のギャップは意外に大きいものかも。

    それに確かUCSDではComputer Scienceを専攻した場合には
    Pascalが必須項目だった記憶が。(さすがPascalの総本山)
    まぁDelphiやるならPascalは使えない言語ではないのでしょうけど。
    • by REN (5436) on 2002年08月17日 17時34分 (#147893)
      一般教養課程の講義でも対象者はある程度決まっているはずですよね?
      stoshさんがなにを専攻されていたかわかりませんが、すくなくとも
      物理・化学系の場合、Fortranの資産が膨大にあります。僕はCばかり
      で作ってしまいますが、それでもFortranで書かれたコードは必然的に
      読まざるを得ないワケで・・・。
      ですから、物理系または化学系の学生を対象とした一般教養の講義では
      あながち間違いではないのではと思います。
      (おなじく某N大学でFortranをかじった者より)
      親コメント
    • by Anonymous Coward on 2002年08月17日 15時55分 (#147860)
      C/C++やJavaではなくPascalを使ってるってのは,大変まともじゃ
      ないの? それにUCSDだったらまともな教育してるはずだから,
      学生がたった一つのプログラミング言語しか習得する実力がないと
      いうことはありえないでしょう.

      仕事でプログラミングやってる人間だったらC/C++だろうがPascal
      だろうがLISPだろうがCOBOLだろがSmalltalkだろうが,必要に
      応じて何でも使いこなせて当然だと思うが....(そうでない奴が
      多いのは何故?)
      親コメント
      • by Anonymous Coward on 2002年08月17日 15時58分 (#147864)
        坊やだからさ
        親コメント
      • by Anonymous Coward
        LISPでもSmalltalkでも使いますが。
        でも、COBOLだけは、許してください・・・
        COBOLは、予約語の文字数長過ぎです。
        “IDENTIFICATION DIVISION”なんて感じで毎日タイプしてたら、腱鞘炎になりそう。
        身体に優しくないです。
        • by harako (114) on 2002年08月17日 22時10分 (#147974)

          別に毛嫌いする必要はないと思いますがねぇ。

          私が10年ほど前 COBOL 開発に従事していたときは、BATCH, CICS, サブルーチン に分けてそれぞれ雛型を使用していたので、IDENTIFICATION DIVISION を直接入力する機会は殆どありませんでした。

          それに、高級言語になればなるほど、記号的ではなく、文に近づいていくというのは当然ではないでしょうか。
          (まずないとは思いますが、高級言語の意味を履き違えないでくださいね)

          それに最近は、Java 等もメソッド名に明確に意味がわかる名前を付けることが主流になってきていますし、
          isIgnoringElementContentWhitespace()
          なんて、文字数だけでいったらこっちの方が長いですよね。(使用頻度に違いはありますけど)

          COBOL にも COBOL のメリットがあって、言語そのものを否定するというのはどうもいただけない気がします。
          もっとも、その言語を選択する/しないはあなたの自由(又はお客さんの自由)ですがね。

          親コメント
          • by wosamu (4952) on 2002年08月17日 23時01分 (#147991) 日記
            >COBOL にも COBOL のメリットがあって、言語そのものを否定するというのはどうもいただけない気がします。
            まず、これは同意。
            といっても僕自身はCOBOLは大嫌いだけど、それはCOBOLそのものよりCOBOLの絡んだ仕事が嫌だったから、ということの方が大きいと思う。

            >それに、高級言語になればなるほど、記号的ではなく、文に近づいていくというのは当然ではないでしょうか。

            これはどうなのかなあ。
            COBOLが単に英語をベースに考えられた言語だからああなったわけで、例えば数学記号とかを元にして作られた言語とかならそれこそ記号バリバリなんじゃないかな。
            #意味不明だ。
            #自然言語に近いことと高級であることは関係ないんじゃないってことで。
            親コメント
            • by Anonymous Coward
              高級言語を

              単に「(英語圏の)プログラマが"文章"としてラクに書きまくれる言語」とするか、
              本質的に「バイナリにして効率がよいロジックを人間がラクに書ける」とするか

                    の解釈の違いかと思われ。

              #これって不毛だよな。いろんな解釈があるからいろんな言語があるわけで。

        • by Anonymous Coward
          C++使いなので長い識別子は全然平気ですが。
          それでもCOBOLはダメなので、あの言語には人を拒絶するなにかがあるに違いない。。

          # そこに山があるからAC
          • by Anonymous Coward
            >それでもCOBOLはダメなので、あの言語には人を拒絶するなにかがあるに違いない。。

            予約語が500を超えるらしくて激萎えです。とても英文のように書けるとは思えません。
            ローマ字で識別子を書いてますが、読みにくいのはそのせいだろうか?

            # そこに仕様書があるからAC.
    • by Anonymous Coward on 2002年08月17日 16時52分 (#147879)
      >Fortranを未だに使ってコード書かせていたのにビックリしました。

      Fortran で書かれた膨大なライブラリがある場合、扱っていても不思議はありません。
      ただ、一般教養課程で用いるのに相応しい言語かというと疑問に思います。
      C と perl という学校もあるそうですが。
      親コメント
      • by Anonymous Coward
        > C と perl という学校もあるそうですが。

        一般教養としては、それも結構わるい選択かも。
    • Fortranを未だに使って
      FORTRANは(その構造の単純さなどなどゆえに強力な最適化がかけやすく)実際に科学技術計算に必須ですから場合によっては役に立つし、別にいいんじゃないでしょうか。

      それだけとか言われると非常に困りますが。

      親コメント
      • by argon (3541) on 2002年08月18日 2時33分 (#148079) 日記
        >FORTRANは(その構造の単純さなどなどゆえに強力な最適化がかけやすく)

        これなんですけど、サブルーチン化しないで書いているから alias の問題が発生しないこと以外に、
        Fortran だと最適化がかけやすい理由ってあるのでしょうか?
        F77のソースをベクトルプロセッサ向けにチューニングしたときは、コンパイラ指令やら
        変数展開やらで、ほとんど原型をとどめないぐらいになったのを憶えています。
        F77が読めてもあのソースが読めるかは疑問です。:-)
        その甲斐あって、一日がかりの計算が半日でできるようになりましたが。
        親コメント
        • by locate (5848) on 2002年08月18日 9時29分 (#148143) 日記
          > サブルーチン化しないで書いているから alias の問題が発生しない

          「サブルーチン化しないで書いている」という部分が
          よく分からないので、もう少し説明していただけますか?

          > F77のソースをベクトルプロセッサ向けにチューニングしたときは、
          > コンパイラ指令やら変数展開やらで、ほとんど原型をとどめないぐらいに
          > なったのを憶えています。

          今では、コンパイラが賢くなったので、自分で指定しなくても
          自動的にベクトル化、並列化してくれます。
          Fortranのプログラムの方が、言語構造が単純なので、
          コンパイラによる自動ベクトル化、自動並列化がうまく行きやすい、
          と言うことだと思います。
          親コメント
          • by argon (3541) on 2002年08月18日 12時57分 (#148186) 日記
            >「サブルーチン化しないで書いている」という部分が

            コンパイラがインライン展開できなかったので、処理系の組み込み以外の
            関数や副プログラム呼び出しが起きないように展開して書き直していました。

            >今では、コンパイラが賢くなったので、自分で指定しなくても
            >自動的にベクトル化、並列化してくれます。

            便利になったんですねえ。
            前述のようにやっていたのは10年ぐらい前の話です。

            >Fortranのプログラムの方が、言語構造が単純なので、

            私にはC90よりF77の方が複雑な言語に思えますが、自動ベクトル化、自動並列化が
            容易になるFortran言語構造の単純さというのは、どういう特徴を指すのでしょうか?
            例えば以下の項目は効きますか?他にあるでしょうか?

            1.静的大域変数の多用。
            2.関数、副プログラムの引数は参照渡し。
            3.再帰呼び出し不可。
            親コメント
            • 他の方もおっしゃっていますが、C のようなポインタがない点が非常に大きいです。

              コンパイラの最適化に使う解析手法は、プログラムの流れを追っていくコントロールフロー解析と、プログラムの流れに即しながらデータの中身がどう変わっていくかを追うデータフロー解析の2 種類に大別できます。

              ポインタはデータフロー解析の難易度をアップさせます。
              まず、ポインタが何を示しているかをデータフロー解析しておいてから、ポインタが指す可能性があるオブジェクトをデータフロー解析するというような多層の解析が必要になるからです。

              あと、配列が数学的な行列というよりも、メモリを便利に使える機構的に捕らえられている点も問題です。配列の境界チェックがなくA[1][-1][2] のような記述も許されています。あと 書き手の傾向の問題ですが、多次元配列でも 2次元配列で実装しようとするため、解析困難になっています。

              1.静的大域変数の多用。

                  これは大きいです。
                  C 言語のように大きな配列を malloc で確保してしまうと、
                    どのくらいの大きさの配列がどこにあるのかすら分らなくなる可能性があります。

              2.関数、副プログラムの引数は参照渡し。

                  これは、むしろデメリットですね。すべて値渡しの方が好都合。

              3.再帰呼び出し不可。

                  これはコントロールフロー解析を楽にしてくれます。
                  ソースコードを 1 回 上から下に解析するだけで、関数の呼び出しグラフができてしまいますから。
              --
              コンタミは発見の母
              親コメント
              • by argon (3541) on 2002年08月18日 23時22分 (#148479) 日記
                >C のようなポインタがない点が非常に大きいです。

                >ポインタはデータフロー解析の難易度をアップさせます。

                なるほど。
                C のようななんでもありのポインタがない Fortran だとデータフロー管理のコストを
                小さくできるので、解析後の最適化処理がかけやすいということでしょうか。
                親コメント
            • by Anonymous Coward

              1.静的大域変数の多用。

              大域変数を多用すると、FortranでもCでも関数への引数を減らすことができます(そのかわり複数オブジェクトを扱いにくくなるが)。関数呼び出しが高速化できるので、第一引数がインスタンスポインタ(selfやthis)であるような一般的なオブジェクト指向言語に比べると格段に速くなります。

              2.関数、副プログラムの引数は参照渡し。
              3.再帰呼び出し不可。

              これも他言語に比べたアドバンテージというわけでは無さそうです。参照渡しで最

          • 今では、コンパイラが賢くなったので、自分で指定しなくても 自動的にベクトル化、並列化してくれます。 Fortranのプログラムの方が、言語構造が単純なので、 コンパイラによる自動ベクトル化、自動並列化がうまく行きやすい、 と言うことだと思います。


            コンパイラによる自動並列化ですが、これだけで満足する結果が得られる場合は少ないです。ほとんどの場合、これに加えて手作業でチューニングをする場合が多いです。
            親コメント
        • by dama4slash (785) on 2002年08月18日 12時19分 (#148180)
          >F77のソースをベクトルプロセッサ向けにチューニングしたときは、コンパイラ指令やら
          >変数展開やらで、ほとんど原型をとどめないぐらいになったのを憶えています。
          今大学でのメインは、F95とかHPFでしょうか。
          コンパイラ部隊の人は、並列化などに気を配って開発していて、
          その実行環境側としても各ノードの資源を有効に使えるように
          色々と仕掛けを考えます。

          自動並列ということで、コンパイルオプション(parallel)とかで
          できるんだった記憶があります。
          # 自動並列は、CやC++でも出来た気がします。

          言語からもHPCがらみの仕事からも離れて結構経つので、
          現状はどんなでしょう。
          # F2000とかはどうなっているのでしょう。
          親コメント
    • by nayuta (1257) on 2002年08月17日 20時22分 (#147940)
       Pascalはいると思うのはわたしだけでしょうか?出来ないと読めない論文がいっぱいです(笑)。
       というか、なぜいまだにあの世界はPascalなんだろう・・・。まあ、100%パスカルというわけではないし、ちゃんと動くPascalで書いてあるわけでもないですけどねぇ・・・。
      --
      ---------- ------ ISHII Nayuta
      親コメント
      • 確かに論文や教科書(特にアルゴリズム関連)はPascal風の擬似コードで書くことが多いですよね.もっとも最近の論文はCやJava風に書くことが多いみたいですので,もう少しの我慢です.:-)

        以前,論文の中のある擬似コードをLisp風に書いたところ,査読者から「もっとメジャーな言語で書いて欲しい」と言われて悲しくなったことがあります.
        親コメント
      • 普及した構造化言語の最古参だからではないでしょうか?

        これ以前だと、COBOLとFORTRANとPL/Iしかなかったと記憶してます。
        これらと比較した場合、読み易さがかなり違うと思います。
        論理構造がはっきりと記述できれば何でもよいんでしょうけど。
        (この意味では多重継承を許す言語は不適かな?判りずらくなるから。)

        # Occamで記述すると並列処理が簡単に書けていいかも…
        # 読める人の数がLISPの半分だったりして。
        --
        notice : I ignore an anonymous contribution.
        親コメント
        • by moonbear (4602) on 2002年08月17日 22時50分 (#147988)
          古典的な論文や教科書にでてくる一見Pascalに似た疑似コードですが,あれはPascalでなくAlgolのつもりで書いている人も多くいるようです.Algolはプログラミング言語におけるラテン語みたいなもので,現在はどこでも使われていないけど(そもそもまともな処理系がなかった気がしますが)学者と呼ばれる人々はみんな読めたりします.:-)

          ついでに#にフォローしますが…

          OccamはCSPから諸概念を借りてきているので,並行計算の理論的扱いをちょっとかじったひとなら案外読めてしまうと思います.

          最近はCSPよりもCCSやπ-計算的な記法の方をよく見かけますが.
          親コメント
          • 学生時代、Algol の講義を受けました。情報処理技術者の1種も
            Algol と Fortran で取りました。

            > そもそもまともな処理系がなかった気がしますが

            TOSBAC-3400 に JIS ALGOL 7070 のコンパイラがありましたよ。
            名前の長さが300文字以内とかの制限はありましたが。

            ALGOL-N は「まともな処理系」はなかたかもしれない。
            --
            信ずる者は掬われる。
            親コメント
        • by ncube2 (2864) on 2002年08月17日 22時54分 (#147989)
          ># Occamで記述すると並列処理が簡単に書けていいかも…

          昔ちょっとだけ書きましたが、確かに並列処理は書きやすいんだけど、構造体型のデータ定義が出来ないのが苦しかった記憶が...
          親コメント
        • これ以前だと、COBOLとFORTRANとPL/Iしかなかったと記憶してます。
          ほんとかどうか知りませんが、よく聞くのは、科学技術計算の分野で最古参なのが Fortran、それと同じくらい古い非数値計算用の言語が Lisp である、と。それが正しいとすれば「COBOLとFORTRANとPL/Iしかなかった」ってのは正確じゃないですね。
    • うちの県の高校では、情報~と付く学科ではFORTRAN/COBOL
      やってます。母校で3~4年前に汎用機入れ換えていたから、
      今でも教えていると思います。

      #いつまでも需要の少ない言語教えていいのか...?

      C#でもJavaでもいいけど、オブジェクトの概念を早いうちに
      植えつけて欲しいですね。
      親コメント
      • by Anonymous Coward
        オブジェクトの概念云々の前に手続き型処理がしっかり理解出来るようになる方が先だと思います。
    • ありゃ。どっかで聞いたような…。私もその講義を受けました。

      #あんときゃぁまだインターネットなんて普及して無くてね…でも授業中モザイクでブラウジングしてましたが(阪神大震災の時はインターネットの力を見たですよ)。

      ちなみに工学部は必須ではなかったっけ?
      ワシは今は無き教育学部だったので必須ではなかったけど。
      親コメント
    • by Anonymous Coward
      センター試験の問題(数学)では、今でも行番号付きBASIC だし、20行たらずのコードにGOTOが2,3ヶ所は使はれて るんじゃなかったでしょうか・・・ >実務と教育の世界のギャップは意外に大きいものかも まさにその通りですよ
    • by Anonymous Coward
      それに確かUCSDではComputer Scienceを専攻した場合にはPascalが必須項目だった記憶が。(さすがPascalの総本山)
      Pascal ができないとアルゴリズムの教科書が読めないじゃないですか (Algol の方がほんとは良いんだろうけど)。計算機科学専攻の学生なら程度の差こそあれ Pascal は読めないといけない言語でしょう。

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

処理中...