Many C++ users quite reasonably don't want to become C++ experts—they are experts in their own fields (e.g., physicists, graphics specialists, or hardware engineers) who use C++.
多くの C++ 使いは、全く当然のことながら、C++ の専門家になりたいわけではない。
彼らは自分自身の分野の専門家 (例えば、物理学者であったり、グラフィックスの専門家であったり、ハードウェア技術者であったり) で、C++ を使っているだけなのだ。
重要なのは言語じゃない (スコア:4, すばらしい洞察)
Re:重要なのは言語じゃない (スコア:2, すばらしい洞察)
元々の話は「化学専攻の学生のためのプログラミング入門」という話ではありませんか？
(教え|教わり)たいのが「プログラミング」なら「プログラミングの各種概念を教えられるなら何でも良い」という話になるでしょうが。
あるプログラミング言語設計者の言 [artima.com]によれば、
てなわけで、答えは「自分の業界で必要なものを学べ。 それはひょっとしたら Fortran かも知れない」というだけの話なのでは。
# 今時、粒子物理でも Fortran はあまりないと思うけどなぁ...
# 流体系の計算物理とかだとあったりします？ > 識者
Re:重要なのは言語じゃない (スコア:2, 興味深い)
流体だとFortranともバリバリ現役です。
古くからあるソルバーの拡張はもちろんFORTRAN 77でやるしかないですから。
新しめのものでも、NAL/JAXAのUPACSやFlontFlow-redはFortran 9xですし、FlontFlow-blueはFORTRAN 77です。
理由としては、
が挙げられると思います。
結局、
と同様の構図です。
研究者としては、「ソルバーをC/C++/C#/JAVAで書きました」と言っても論文にはならないし、ソフトウェア会社としては、スクラッチから違う言語で書き直してテストをする分の工数にお金はもらえないし、ユーザはそこにあるものを使用するだけです。
Re:重要なのは言語じゃない (スコア:2, 興味深い)
残念ながら日本では流体でもまだまだFortran、それもF77です。
彼らの大半はComputational Fluid Dynamicsをやっていながら、
驚くほどに計算機やその関連技術には興味を持たないのです。
コードは例えば"COMMON文で変数は実質すべてグローバル"、
といったとても他人には読めないものだったりします。
中の人なのでAC。
計算するのが目的じゃないんだから (スコア:0)
CFDの研究者なら、プログラムの実装は自身の考え方を証明する手段であって目的じゃないでしょ。論文に数式は書いても、ソースリスト付けるわけじゃないんだし。時間を掛けて書いたエレガントな実装よりも、短時間で書けて力技でも間違いのない結果が出る方が重要。
とはいえ、難読性の高いソースだと、その研究を引き継いだり、参照したりする人が苦労する訳だが。
QuickBasicで書かれたプログラムで卒論書いた流体出身のAC。
Re:重要なのは言語じゃない (スコア:1)
変数の「型」を強く意識する必要がある言語で（弱いと VB の Variant 使ったように、「なんとなく動く」ので怖い）、goto なしで構造化がかけて、それなりに分かりやすい……
となると、Pascal か C か、あるいはその派生になりますかね。結局 ALGOL 系列か。
※Variant 禁止と Option explicit しているなら VBA でもいい
Java はクラスというか、オブジェクト指向が理解できるかどうかにかかっちゃうしなあ。
-- To be sincere...
Re: (スコア:0)
もしくは「なんとなく動く」ではマズいと感じるように
なる、ためにはどのような教育が有効でしょうか。
若い人や若くない人にその辺をどうにかして身に付けて
もらいたいと思いつつ挫折しているので良いアイディア
があればお教えください。
Re:重要なのは言語じゃない (スコア:1)
手軽な方法としては、Excel の VBA で、バリアント型と文字列型と数値型を使って、
「セル A1 の中身と セル A2 の中身を足す」をやらせてみるとか。
1000 と 500 とあったとして、数値なら 1500 ですが、文字列だと 1000500 になるでしょ
バリアント型でやると混乱必至ですしね。一度やったら普通は懲りるかと（ｗ バリアント排除のための限定ですが……
あと、四則演算をさせるようにして、除数に 0 を入れたときのことをあえて言わずにおいてトラップにするとかも有効ですかねえ。
-- To be sincere...
Re:重要なのは言語じゃない (スコア:1)
Variant型は自動的にも型変換されますが、複雑な処理の場合、予想がつきませんし、自動に任せていると、型変換が行われていることさえ見落としがちです。動的型付けの言語でも、型を意識する必要はあるので、明示的に型変換をする癖をつければいいだけではないでしょうか。
Re: (スコア:0)
手続き型言語なんて1日もあれば書きはじめられるようになるから、
どの言語を教えるかということにはあまり重きを置く必要は無いのは同意ですが、
なんでもいいというと、Fortran でもいいよねと返されるかもしれません。
そこは待て待てといいたくなります。
過去の資産を理由にされる場合、FORTRAN 77 以前のコードとか読める必要もあるが、
これは教育的な理由というより。保守要員養成の意図が強い気がします。
情報専攻以外なら、少しでも日用に使えそうな言語から始めた方がいいんじゃないかなと思います。
いっそのこと Matlab, Scilab, Mathematica, R のような処理系でもよいかと。
計算機物理や流体工学など science, engineering 分野では、いやでも膨大なデータを扱うのが
日常になるので、自前でデータ処理ができる能力は役に立ちます。
いろんなデータ処理ができるようになっていれば、道具の一つとして Fortran を覚えるのは容易でしょう。
Re: (スコア:0)
・学生は言語仕様を覚えるだけで良い。
・ライブラリや開発環境の学習は少なければ少ない程、言語学習に力を注げる。
・結果、アルゴリズム等の勉強の時間を多く出来る。
・汎用機なら、パソコンとの別世界を垣間見せることができる。
などの利点があると思います。
パソコン系で使われている多くの言語は、言語の勉強というより
「ライブラリの学習」「開発環境の学習」にかなりの時間を取られるのが難かと。
それだと、プログラミングのベースとなるアルゴリズム系の学習などの時間が少なくなりすぎます。
Re:重要なのは言語じゃない (スコア:1)
うーむ、そうでしょうか？
自分の経験(うーむ、２５年も前のことだ、困ったことだ)では、Fortran の方が覚えないと行けない呪文が多かった気がします。
ただし、比較対象は Basic, LISP, C。もちろん、グラフィック環境なんてありません。
たしかに、GUIバリバリの開発環境で、グラフィック使いまくりの課題で授業をやると、
アルゴリズムやプログラミングの概念を教えている時間より、
開発環境やライブラリの使い方を習得するのに終始してしまいがちなのは認めます。
Re: (スコア:0)
そこら辺を比較対象に取ると、ROM BASICが一番楽かな～？
何せあれは行番号でちょこちょこ書いていけば一通りのことはできるし、
あの時代のだとライブラリなんて概念は無いから一番お気軽な環境だとは思う。
でも、Fortranはそれに次ぐお手軽さな印象だったかな？
LISPは‥忘れたけど、Cはちょっと前振りとか土台を整えるのに時間が要る言語だと思う。
それとあの当時、汎用機でCってあったかな？ まあ有ったかもしれないけど
学習用としては提供されてなかった気がする。
(APLとかPascalとかLISPは有った筈)
Re: (スコア:0)
同感です。
家の会社では上の方には「言語仕様？んなもん覚えりゃ良いだけだろ」で済まされますｗ
Re: (スコア:0)
新事業の創出やら企画やらをやっている者です。
必要に応じて、開発を行うこともあります。
学部生の頃は、Pascalでプログラミングの各種概念を覚えました。院生の時に、PHPとRubyで開発を始めました。
・・・CやJavaは？という質問をしてくる方々が会社にいらっしゃいますが、基本を理解できれば、なんだって良いのでは？ 仕事で必要になったら覚えれば良いので、プログラミングの各種概念を学習できれば何でも良い派です。 実際は、段階をわけて学ぶべきでしょうね？
step1.とりあえず、理解し易くて、実行結果がす
Re: (スコア:0)
>step1.とりあえず、理解し易くて、実行結果がすぐわかって、学部生が英語をほとんど読めなくても大丈夫な言語で学習し始める。 (日本語でできる言語の"なでしこ"とか)
小学生ならわからんでもないが、日本語言語から入るの止めたほうが良いような・・・。