アカウント名:
パスワード:
別に毛嫌いする必要はないと思いますがねぇ。
私が10年ほど前 COBOL 開発に従事していたときは、BATCH, CICS, サブルーチン に分けてそれぞれ雛型を使用していたので、IDENTIFICATION DIVISION を直接入力する機会は殆どありませんでした。
それに、高級言語になればなるほど、記号的ではなく、文に近づいていくというのは当然ではないでしょうか。 (まずないとは思いますが、高級言語の意味を履き違えないでくださいね)
それに最近は、Java 等もメソッド名に明確に意味がわかる名前を付けることが主流になってきていますし、 isIgnoringElementContentWhitespace() なんて、文字数だけでいったらこっちの方が長いですよね。(使用頻度に違いはありますけど)
COBOL にも COBOL のメリットがあって、言語そのものを否定するというのはどうもいただけない気がします。 もっとも、その言語を選択する/しないはあなたの自由(又はお客さんの自由)ですがね。
単に「(英語圏の)プログラマが"文章"としてラクに書きまくれる言語」とするか、本質的に「バイナリにして効率がよいロジックを人間がラクに書ける」とするか
の解釈の違いかと思われ。
#これって不毛だよな。いろんな解釈があるからいろんな言語があるわけで。
Fortranを未だに使って
それだけとか言われると非常に困りますが。
1.静的大域変数の多用。
大域変数を多用すると、FortranでもCでも関数への引数を減らすことができます(そのかわり複数オブジェクトを扱いにくくなるが)。関数呼び出しが高速化できるので、第一引数がインスタンスポインタ(selfやthis)であるような一般的なオブジェクト指向言語に比べると格段に速くなります。
2.関数、副プログラムの引数は参照渡し。 3.再帰呼び出し不可。
これも他言語に比べたアドバンテージというわけでは無さそうです。参照渡しで最
今では、コンパイラが賢くなったので、自分で指定しなくても 自動的にベクトル化、並列化してくれます。 Fortranのプログラムの方が、言語構造が単純なので、 コンパイラによる自動ベクトル化、自動並列化がうまく行きやすい、 と言うことだと思います。
これ以前だと、COBOLとFORTRANとPL/Iしかなかったと記憶してます。
それに確かUCSDではComputer Scienceを専攻した場合にはPascalが必須項目だった記憶が。(さすがPascalの総本山)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
それを言ったら (スコア:2, 参考になる)
情報処理の講義で(必須かどうかは自信がありませんが)、
Fortranを未だに使ってコード書かせていたのにビックリしました。
実務と教育の世界のギャップは意外に大きいものかも。
それに確かUCSDではComputer Scienceを専攻した場合には
Pascalが必須項目だった記憶が。(さすがPascalの総本山)
まぁDelphiやるならPascalは使えない言語ではないのでしょうけど。
Re:それを言ったら (スコア:3, 参考になる)
stoshさんがなにを専攻されていたかわかりませんが、すくなくとも
物理・化学系の場合、Fortranの資産が膨大にあります。僕はCばかり
で作ってしまいますが、それでもFortranで書かれたコードは必然的に
読まざるを得ないワケで・・・。
ですから、物理系または化学系の学生を対象とした一般教養の講義では
あながち間違いではないのではと思います。
(おなじく某N大学でFortranをかじった者より)
Re:それを言ったら (スコア:1, 興味深い)
ないの? それにUCSDだったらまともな教育してるはずだから,
学生がたった一つのプログラミング言語しか習得する実力がないと
いうことはありえないでしょう.
仕事でプログラミングやってる人間だったらC/C++だろうがPascal
だろうがLISPだろうがCOBOLだろがSmalltalkだろうが,必要に
応じて何でも使いこなせて当然だと思うが....(そうでない奴が
多いのは何故?)
Re:それを言ったら(スコア:-1 余計なもの) (スコア:1, おもしろおかしい)
Re:それを言ったら (スコア:0)
でも、COBOLだけは、許してください・・・
COBOLは、予約語の文字数長過ぎです。
“IDENTIFICATION DIVISION”なんて感じで毎日タイプしてたら、腱鞘炎になりそう。
身体に優しくないです。
Re:それを言ったら (スコア:1)
別に毛嫌いする必要はないと思いますがねぇ。
私が10年ほど前 COBOL 開発に従事していたときは、BATCH, CICS, サブルーチン に分けてそれぞれ雛型を使用していたので、IDENTIFICATION DIVISION を直接入力する機会は殆どありませんでした。
それに、高級言語になればなるほど、記号的ではなく、文に近づいていくというのは当然ではないでしょうか。
(まずないとは思いますが、高級言語の意味を履き違えないでくださいね)
それに最近は、Java 等もメソッド名に明確に意味がわかる名前を付けることが主流になってきていますし、
isIgnoringElementContentWhitespace()
なんて、文字数だけでいったらこっちの方が長いですよね。(使用頻度に違いはありますけど)
COBOL にも COBOL のメリットがあって、言語そのものを否定するというのはどうもいただけない気がします。
もっとも、その言語を選択する/しないはあなたの自由(又はお客さんの自由)ですがね。
Re:それを言ったら (スコア:1)
まず、これは同意。
といっても僕自身はCOBOLは大嫌いだけど、それはCOBOLそのものよりCOBOLの絡んだ仕事が嫌だったから、ということの方が大きいと思う。
>それに、高級言語になればなるほど、記号的ではなく、文に近づいていくというのは当然ではないでしょうか。
これはどうなのかなあ。
COBOLが単に英語をベースに考えられた言語だからああなったわけで、例えば数学記号とかを元にして作られた言語とかならそれこそ記号バリバリなんじゃないかな。
#意味不明だ。
#自然言語に近いことと高級であることは関係ないんじゃないってことで。
Re:それを言ったら (スコア:0)
単に「(英語圏の)プログラマが"文章"としてラクに書きまくれる言語」とするか、
本質的に「バイナリにして効率がよいロジックを人間がラクに書ける」とするか
の解釈の違いかと思われ。
#これって不毛だよな。いろんな解釈があるからいろんな言語があるわけで。
Re:それを言ったら (スコア:0)
それでもCOBOLはダメなので、あの言語には人を拒絶するなにかがあるに違いない。。
# そこに山があるからAC
Re:それを言ったら (スコア:0)
予約語が500を超えるらしくて激萎えです。とても英文のように書けるとは思えません。
ローマ字で識別子を書いてますが、読みにくいのはそのせいだろうか?
# そこに仕様書があるからAC.
Re:それを言ったら (スコア:1, 参考になる)
Fortran で書かれた膨大なライブラリがある場合、扱っていても不思議はありません。
ただ、一般教養課程で用いるのに相応しい言語かというと疑問に思います。
C と perl という学校もあるそうですが。
Re:それを言ったら (スコア:0)
一般教養としては、それも結構わるい選択かも。
Re:それを言ったら (スコア:1)
それだけとか言われると非常に困りますが。
Re:それを言ったら (スコア:1)
これなんですけど、サブルーチン化しないで書いているから alias の問題が発生しないこと以外に、
Fortran だと最適化がかけやすい理由ってあるのでしょうか?
F77のソースをベクトルプロセッサ向けにチューニングしたときは、コンパイラ指令やら
変数展開やらで、ほとんど原型をとどめないぐらいになったのを憶えています。
F77が読めてもあのソースが読めるかは疑問です。:-)
その甲斐あって、一日がかりの計算が半日でできるようになりましたが。
Re:それを言ったら (スコア:1)
「サブルーチン化しないで書いている」という部分が
よく分からないので、もう少し説明していただけますか?
> F77のソースをベクトルプロセッサ向けにチューニングしたときは、
> コンパイラ指令やら変数展開やらで、ほとんど原型をとどめないぐらいに
> なったのを憶えています。
今では、コンパイラが賢くなったので、自分で指定しなくても
自動的にベクトル化、並列化してくれます。
Fortranのプログラムの方が、言語構造が単純なので、
コンパイラによる自動ベクトル化、自動並列化がうまく行きやすい、
と言うことだと思います。
Re:それを言ったら (スコア:1)
コンパイラがインライン展開できなかったので、処理系の組み込み以外の
関数や副プログラム呼び出しが起きないように展開して書き直していました。
>今では、コンパイラが賢くなったので、自分で指定しなくても
>自動的にベクトル化、並列化してくれます。
便利になったんですねえ。
前述のようにやっていたのは10年ぐらい前の話です。
>Fortranのプログラムの方が、言語構造が単純なので、
私にはC90よりF77の方が複雑な言語に思えますが、自動ベクトル化、自動並列化が
容易になるFortran言語構造の単純さというのは、どういう特徴を指すのでしょうか?
例えば以下の項目は効きますか?他にあるでしょうか?
1.静的大域変数の多用。
2.関数、副プログラムの引数は参照渡し。
3.再帰呼び出し不可。
Re:それを言ったら (スコア:2, 参考になる)
コンパイラの最適化に使う解析手法は、プログラムの流れを追っていくコントロールフロー解析と、プログラムの流れに即しながらデータの中身がどう変わっていくかを追うデータフロー解析の2 種類に大別できます。
ポインタはデータフロー解析の難易度をアップさせます。
まず、ポインタが何を示しているかをデータフロー解析しておいてから、ポインタが指す可能性があるオブジェクトをデータフロー解析するというような多層の解析が必要になるからです。
あと、配列が数学的な行列というよりも、メモリを便利に使える機構的に捕らえられている点も問題です。配列の境界チェックがなくA[1][-1][2] のような記述も許されています。あと 書き手の傾向の問題ですが、多次元配列でも 2次元配列で実装しようとするため、解析困難になっています。
1.静的大域変数の多用。
これは大きいです。
C 言語のように大きな配列を malloc で確保してしまうと、
どのくらいの大きさの配列がどこにあるのかすら分らなくなる可能性があります。
2.関数、副プログラムの引数は参照渡し。
これは、むしろデメリットですね。すべて値渡しの方が好都合。
3.再帰呼び出し不可。
これはコントロールフロー解析を楽にしてくれます。
ソースコードを 1 回 上から下に解析するだけで、関数の呼び出しグラフができてしまいますから。
コンタミは発見の母
Re:それを言ったら (スコア:2, 参考になる)
>ポインタはデータフロー解析の難易度をアップさせます。
なるほど。
C のようななんでもありのポインタがない Fortran だとデータフロー管理のコストを
小さくできるので、解析後の最適化処理がかけやすいということでしょうか。
Re:それを言ったら (スコア:0)
大域変数を多用すると、FortranでもCでも関数への引数を減らすことができます(そのかわり複数オブジェクトを扱いにくくなるが)。関数呼び出しが高速化できるので、第一引数がインスタンスポインタ(selfやthis)であるような一般的なオブジェクト指向言語に比べると格段に速くなります。
これも他言語に比べたアドバンテージというわけでは無さそうです。参照渡しで最
Re:それを言ったら (スコア:1)
コンパイラによる自動並列化ですが、これだけで満足する結果が得られる場合は少ないです。ほとんどの場合、これに加えて手作業でチューニングをする場合が多いです。
Re:それを言ったら (スコア:1)
>変数展開やらで、ほとんど原型をとどめないぐらいになったのを憶えています。
今大学でのメインは、F95とかHPFでしょうか。
コンパイラ部隊の人は、並列化などに気を配って開発していて、
その実行環境側としても各ノードの資源を有効に使えるように
色々と仕掛けを考えます。
自動並列ということで、コンパイルオプション(parallel)とかで
できるんだった記憶があります。
# 自動並列は、CやC++でも出来た気がします。
言語からもHPCがらみの仕事からも離れて結構経つので、
現状はどんなでしょう。
# F2000とかはどうなっているのでしょう。
論文が読めません・・・ (スコア:1)
というか、なぜいまだにあの世界はPascalなんだろう・・・。まあ、100%パスカルというわけではないし、ちゃんと動くPascalで書いてあるわけでもないですけどねぇ・・・。
---------- ------ ISHII Nayuta
Re:論文が読めません・・・ (スコア:1)
以前,論文の中のある擬似コードをLisp風に書いたところ,査読者から「もっとメジャーな言語で書いて欲しい」と言われて悲しくなったことがあります.
Re:論文が読めません・・・ (スコア:1)
これ以前だと、COBOLとFORTRANとPL/Iしかなかったと記憶してます。
これらと比較した場合、読み易さがかなり違うと思います。
論理構造がはっきりと記述できれば何でもよいんでしょうけど。
(この意味では多重継承を許す言語は不適かな?判りずらくなるから。)
# Occamで記述すると並列処理が簡単に書けていいかも…
# 読める人の数がLISPの半分だったりして。
notice : I ignore an anonymous contribution.
最古参はAlgolでは? (スコア:2, 参考になる)
ついでに#にフォローしますが…
OccamはCSPから諸概念を借りてきているので,並行計算の理論的扱いをちょっとかじったひとなら案外読めてしまうと思います.
最近はCSPよりもCCSやπ-計算的な記法の方をよく見かけますが.
Re:最古参はAlgolでは? (スコア:1)
Algol と Fortran で取りました。
> そもそもまともな処理系がなかった気がしますが
TOSBAC-3400 に JIS ALGOL 7070 のコンパイラがありましたよ。
名前の長さが300文字以内とかの制限はありましたが。
ALGOL-N は「まともな処理系」はなかたかもしれない。
信ずる者は掬われる。
並列は楽なんだけど (スコア:1)
昔ちょっとだけ書きましたが、確かに並列処理は書きやすいんだけど、構造体型のデータ定義が出来ないのが苦しかった記憶が...
Re:並列は楽なんだけど (スコア:1)
それより私はnCube2上でのプログラミングで苦しめられた記憶が… :-)
(オフトピ失礼)
Re:並列は楽なんだけど (スコア:1)
Re:論文が読めません・・・ (スコア:0)
Re:それを言ったら (スコア:1)
やってます。母校で3~4年前に汎用機入れ換えていたから、
今でも教えていると思います。
#いつまでも需要の少ない言語教えていいのか...?
C#でもJavaでもいいけど、オブジェクトの概念を早いうちに
植えつけて欲しいですね。
Re:それを言ったら (スコア:0)
Re:それを言ったら (スコア:1)
#あんときゃぁまだインターネットなんて普及して無くてね…でも授業中モザイクでブラウジングしてましたが(阪神大震災の時はインターネットの力を見たですよ)。
ちなみに工学部は必須ではなかったっけ?
ワシは今は無き教育学部だったので必須ではなかったけど。
Re:それを言ったら (スコア:0)
Re:それを言ったら (スコア:0)
Re:それを言ったら (スコア:0)