「FORTRAN」を含む日記 RSS

はてなキーワード: FORTRANとは

2018-03-16

ちょっと羨ましい

プログラマやってるけど、昔話を聞くに、本当に隔世の感があると思わされる。

だって昔のプログラマ仕事って、入念に机上デバッグされたフローチャートを、ただひたすらCOBOLFortranアセンブラ翻訳して、コーディングシートに書くだけの仕事だったんでしょ?

フローチャートで書ける程度のロジックなんて全然難しくないので、シートを書き終わった時点で事実上プログラムは完成したに等しいと。

あとはパンチしてもらって、テストは大抵一回動かすだけで全部問題なく通って一丁上がりと。

そうなると、これはもう気合と体力の問題って話になる。

そりゃ月残業300とか働くのも決して不可能じゃないし、それだってハイになった勢いでガシガシ書けるだろう。

そうやってカネがっぽり稼いで、日々のモヤモヤは酒タバコ麻雀パチンコ風俗スッキリさせて、そんでまた思いっきり働く。それが男だろ!ってノリだよな。

仕事懇意になってるパンチャーのお姉ちゃんと裏で仲良くなって、そのまま付き合って…なんてのも普通にアリだろう。

昭和は明るい時代だったんだなあと、少し羨ましくなる。


今はもう、あらゆることが複雑になりすぎて、設計だってUMLER図で対処できるかすら怪しくなっている。

言語だってJavaだけじゃなく、SQLやら、HTMLCSSJavaScriptと心得てないと仕事にならない。

そして何より、動かして試して、都度直していかないと分からないことだらけになっている。

プログラマの脳にかかる負荷は昔と比べ物にならない。当然あまりに長時間労働事実上不可能

俺は残業100まで行った所で帯状疱疹が出て、シャワーで腰をさすりながらココらへんが限界と思い知らされた。それが10年前。

勿論今はもっと無理が利かない状況。


でも、残業300可能時代を、色んな会社で現役として駆け抜け出世した幹部オヤジ達に、今のプログラマが抱えているアレやコレやらは、多分理解できない。

それくらい、時代が変わりすぎたのだろう。見えている世界が違いすぎる。

から今の若い奴らを根性無しとして完全に見下しているし、本音では「なんだよ急に辞めやがって使えねーなー」とか「アイツ死にやがった、ざまあwww」と思ってる、人でなしの老害ばっかり。

勿論FortranC/C++Javaみたくスキルを身につけてきた人は例外だけど、本当に例外中の例外でめったにいない。

それで「昔のままのノリじゃ、今の開発は絶対に稼げない」ということに思い至らない。

こんなブラック業界、やっぱり一度潰れたほうがいいんだろうと思わされる。

2018-01-28

「1年間」続けると人生が変わるほんの小さな16の習慣

2018年も残り11ヶ月、あなたはどう過ごす?

1. 毎日決められた時間空気を読む。

他の時間は読まないです。

2. 「ごめん」という代わりに「バカヤロー」と言ってみる。

謝る必要がないのに、毎回謝ってしまい、謝りすぎてしまうという問題を抱えていました。今でもそうです。そうなってしまうと、何をするのも謝ってしまい、受け身になってしまます。自信がなくなって他の人から受ける評価も下がってしまますだって、すべてのことに謝っているんですから

なので、意識的に「ごめん」の代わりに「バカヤロー」というようにしてみたんです。

3. タグを置くのではなく、片づける。

そのコンテンツ不要

4. 毎日食器を使う。

から直接食べるのはそろそろやめましょう。

5. 2分で済むのであれば、やめてしまう。

2分もかかるのなら諦める。

6. 毎日決まった時間増田を書く。

一貫性をもたせるのは、認知行動療法(CBT-I)でもとても大事とされています


7. 毎日ストロングゼロを飲む。

確実に人生が変わる。

8. 丸々1年間、小銭はすべてレジで出す。

電子マネー礼賛派の冷たい視線が心地よくなります

9. 寝る前に次の日の計画を立てる。

そして起きたときには忘れる。

10. 筆記体書道のような新しい手書き練習する。

コーランの筆写がよろしいかと。

11. 毎日、古い言語言葉を3つ覚える。

COBOLとかFORTRANとか。

12. 毎日匿名日記をつける。

増田

13. できるだけ長く眠る。次の日も続ける。そしてその次の日も。

できれば二度と起きない。

14. 家を出る前に毎朝布団にもう一度入る。

そして二度寝をする

15. 何かをやめるのではなく、新たに買う。

そして部屋がジャンクであふれる。

16. 瞑想してみる。1日5から始める。

野菜350gも。

2017-06-03

http://anond.hatelabo.jp/20170602123042

具体的に、FORTRANCOBOL統一した場合を考えてみればいい。

計算効率的に行う言語と、効率を捨てて正確に計算を行う言語統一できるのかと。

2017-03-12

書き換える必要なくね?

大企業銀行で、昔から動いている基幹システムは、大抵メインフレームCOBOLの組み合わせである

それをここ十年くらい、リプレースx86サーバJavaという構成に変更することが多い。

しかし、ハード汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。

ぶっちゃけCOBOLCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは?と思うのだ。

その理由はこうだ。


COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。

勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOL文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである

そういうモノが既にある企業銀行文化において、当然発注側は担当者からお偉いさんまでCOBOLerフローチャート脳だし、新しいシステム設計でもそれを踏襲しようとする。

というか踏襲すること前提じゃないと設計書をレビューできない。

UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。

というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法設計書で処理を組み上げざるを得なくなる。


そうなると、実装フローチャート設計を基にコードを書くわけだが、こういう設計ハッカー文化で発展してきた言語(FortranC/C++Javaという流れと、PerlからPythonPHPというインタプリタ系の諸言語)との相性が最悪である

設計とは実装を楽にするために書くのに、これらの言語において、フローチャート設計は役に立たないどころか、邪魔しかない。

からFortranしかなかった頃から、本物のプログラマ達はフローチャートdisってきたわけである

ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である

しかし、「普通人達普通思考からはかけ離れ過ぎているという意味で、「普通人達普通仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。

…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLアセンブラ選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。


というわけで、自分COBOLからリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。

COBOLリプレースするのでない限りは。

2017-02-06

fortran to matlab

There is a program that can convert fortan code to matlab code.You can download from the following link.

http://www.mathworks.com/matlabcentral/fileexchange/5260-f2matlab

converter available

Matlabもしくはオクターブに変換し、メモリー効果だかなんだか他愛のない追加タームを付けることを

課題として与える。どうせ結果は出されへんやろから

最後最期の瞬間まで

「どうしてこんな簡単なこともできないのかな」

と嘆きのセレナーデ

本番は結果零でやらせる。

それなら結果を発表するところ以外はスライド作れるから問題なしやわな

2017-01-18

プログラミングって「得体がしれない」よな

プログラミングって、これから始めてみようっていうとき、なんだか「得体のしれない行為」っていう感覚がありませんか?

ぼく自身は、プログラムを書いてる側の人間で、いまでこそ少しはプログラミング本質的な難しさをわかってる気になってます。でもつい数年前までは、プログラミングは難しくはないけど得体がわからない、という感じでした。

そのへんのコードを組み合わせて動くものはできるけど、何がどうなっているのかは知らんし、ググって分からないものはできない、という方向で、「プログラミングは難しい」と思ってました。

最近になって、プログラミング義務教育必修化の話題とか、コピペプログラマー話題とかを目にするたびに、かつて自分プログラミングに対して抱いていた「得体のしれない行為」という感覚が思い出されてしまい、少しざわざわした気持ちになったので、ちょっとここに書きなぐらせてください。

だいたいが個人的な話なので、そういうのがうっとうしい人は無視してください。

ぼくが世の中にパソコンという道具があることを知ったのは、たぶん中学生ときです。30年くらい前。当時、電気屋の売り場ではけっこうな床面積を使ってワープロ文章入力する専用マシン)が陳列されてました。文章を書くのは好きだったけど、字を書くのが死ぬほどめんどくさかった自分は、ワープロさえあれば自分小説とか書くのになあと思いながら指をくわえて電気屋の店内をうろうろしてました。しかし、ファミコンすら買ってもらえなかった家計ではワープロなんぞ買ってもらえるわけもありません。そのうち巡回してた電気からワープロが消え、それに代わってパソコンのコーナーが広がっていきました。このパソコンというのは、よくわからないけどワープロとして使えるっぽいし、どうやらファミコンを持っていない僕にもゲームができるらしい、おれに必要なのはこれだ、というわけで、中学生だった自分パソコンという存在に興味を抱くようになったのでした。

はいえ、だからといってパソコンを買ってもらえるような家計ではなかったわけなので、カタログを熱心に眺めるだけの毎日が続きました。その当時の自分にとって、パソコンが欲しいといったら、それはNECを買うかエプソンを買うかという選択でした。冨士通からパソコンが出ていることは知りませんでした。マッキントッシュっていうやつもあって、このPerformaっていうやつはなぜか安いとか、よくわからないけどシャープとかソニー独自パソコンを作っているぞとか、そういう情報パソコンに対する認識のすべてでした。当時の自分にとってのパソコンは、電気メーカーから発売されている商品一種であり、ラジカセとかテレビと同列の存在でした。

なんでこんな話がプログラミングにつながるかというと、ひょっとして自分プログラミングにずっと感じていた「得体のしれなさ」の源泉の一つは、こんなふうにパソコン電化製品として見ていた当時の感覚の延長だったのかもなあと思ってるからです。

ラジカセなら、CDだのテープだのを入れて再生タンを押せば、そのハードウェア機能物理的に体感できます。それに対してパソコンは、プログラミングちょっとやってみても、その行為と、そのハードウェアとが、感覚的に結びつきません。もちろん、プログラミングというのは、物理的なデバイスに結びつけて考えなければできない行為ではありません。しかし、パソコンを「カタログ商品」として見るところから入ってるばかりに、そこでやるプログラミングという行為ハードウェアとの結びつきが見えにくい状態に、なんとなく居心地の悪さを感じていたように思うのです。

もし自分スタート地点が、パソコンを使って文筆やゲームをするところだったら、パソコンは文筆やゲームのための箱だったでしょう。その後でプログラミングを始めていたなら、プログラミングという行為を、文筆やゲームに関連した創造的な活動として学べたかもしれません。

ところが実際には、自分はつい数年前まで、パソコンという電化製品に対する漠然とした行為としてプログラミングを捉えてた気がします。

プログラミングを始めたのは、高校生になって誰も使わないFM77が部室に置いてあったので立ち上げてみたらF-BASICインタプリタが起動したからでした。とくに何をプログラミングすればいいかもわからなかったので、教科書雑誌コードを転記したり、ループで線画を書いたりして遊んでいました。大学に入ってからも、授業でFORTRANとかLispをやらされたけど、基本的自分目的をもってプログラミングするのは数値計算くらいのものでした。そのころになると、本で情報を探して(まだインターネット検索は使い物にならなかった)適当コードをつなぎ合わせるのがプログラミングだと思ってました。そんなん面白くないなあ、とも思ってました。

この感覚、完全に、いま揶揄されているコピペプログラマーのそれだったと思いますちょっと話はそれますが、ブロック遊びとか砂場遊びって、ほとんどの人はわりとコピペプログラミングと似たような感覚でやってるんじゃないでしょうか。パーツを勘で組み合わせたり、とにかく砂を盛っていったりすれば、家みたいなのができるよね、という感覚プログラミングは、自分にとってそれに近い作業でした。学生のころは、内心、自分にもパソコンサンプルコードさえあれば何かすごいものを作れるかもなあ、くらいに思っていたふしもあります

自分バカでした。パソコンがあるとかないとか、関係ないのです。パソコンさえあれば、なんて思う者に、本当のプログラミングがわかるはずがありません。

そんなこんなで、自分はまともにプログラミング経験しないまま社会人になったわけですが、幸いにもプログラミングに対するこの感覚は、仕事パソコンを日々使うようになってから徐々に変わっていきました。

具体的には、パソコンが、自分の中で「カタログ商品から武器」へと変わりました。それと同時に、プログラミングという行為が、武器開発という位置づけになりました。

武器というのは言い過ぎだとしても、ちょっとしたプログラミングは確かに業務上課題を打開しました。それなりに計算機科学教科書を読んで勉強をしたこともあって、いつのまにかプログラミングに対する「得体のしれなさ」も解消してました。

結局のところ、自分にとっては、プログラミングという行為の「得体のしれなさ」から解放されるまでにずいぶん長い時間必要だったことになります自分がそうだったからといって他人もそうだとは限らないですが、たとえば小学校で形だけプログラミングを教わっても、分かるとかわからないとか、好きとか嫌いとか以前に、なんかモヤモヤした気持ちになるだけの子もも少なくないんだろうなあ。それは不憫だなあ。

かといって、自分がいまプログラミングで少しは戦えてるのは、そのむかしパソコンに憧れがあって、得体がしれないなりにプログラミングをする機会が若いときたまたまあったからでもあるので、そういう機会になるなら小学校で形だけでも教えるほうがいいのかなあとも思います

オチがないので、このへんで。

2016-01-15

JAVA言語という表記違和感

好きに表記すればいいと思いつつも見ると内心もやもやしてしまう。

やっぱりJava表記してほしい。Java……かっこいいじゃん!

Javaだけだと馴染みのない人もいると思うので似たような例を挙げる。

× SKYPEアプリSkype

× PHOTOSHOPソフトPhotoshop

× YOUTUBEサービスYouTube

この「JAVA言語」という表記が抱えている問題は何か?

大まかには次の二点だと思っている。

大文字

COBOLLISP、ALGOL、FORTRANPL/IAPLBASIC……

大文字名前は古い言語代名詞だ。

今はFORTRANも新しいFORTRANFortranと名乗っているし、BASICBASIC派生Visual Basicなどと名乗っていたりする。

時代に逆行してJavaJAVA表記してしまうとJavaがあたかも古い言語であるかのような印象を与えることになる。

× JAVA1960年代言語ですか?
○ Java ← 今時の言語っぽい!

言語」という接尾辞

Javaはそれ単体でプログラミング言語Javaを指す。

言語」という接尾辞をつけてしまうと二重敬語のようなまわりくどい印象を与えることになる。

Cのようにググラビリティが低いため止むを得ずC言語表記するという場合もあるが、Javaならそういった問題は無い。

コンピュータ関係で他のJavaと衝突していないか?それは大丈夫だ。

https://ja.wikipedia.org/wiki/%e3%82%b8%e3%83%a3%e3%83%90

本題

今日金曜ロードショー天空の城ラピュタがあるらしい。

Scalaちゃんは今日も「余裕でした(´・_・`)ドヤッ」とツイートするんだろうか。

https://twitter.com/scalachan/status/363317870685462531

2015-08-19

僕のいつまで経っても初心者プログラミング

タイトル通り、ちょっとでも詳しい人なら情けなくなるレベルでさえそこに達するのに何年も掛かった。

何せ、本業どころか趣味ですらないし、たぶん一般的プログラマとは全然違う。

ともかく、レベル的にはがっかりするような話であることは最初にどうしても断っておきたい。

 

事の始まりは前職の会社就職した時のことである

非常に特殊仕事で、ある環境計測データ現場で測定し、それを持ち帰って取りまとめて分析して報告書を提出するのが主たる業務の会社であった。

世の中にはほんと色んな仕事があるもので、そんな業種があるなんて務めるまで聞いた事もなかっただけど、パソコンという文明機器に触れたのも僕はその会社が初めてだった。とても古い話でお前いったい何歳だ?みたいな。

 

なので、その最初に触れたPC-9801シリーズの型番は言わないが、勤め始めた時にその会社にあったHDDは外付けでSCSI接続されたものがたった一台あっただけ、とは言っておこう。

環境計測データを取り扱うのが主たる仕事からパソコンデータ処理出来なければ仕事にならない。

その計測機器基本的に、当時は計るだけであり、記録データと言えば、記録紙にペンで波形記録してくれるレコーダーや、分析値を印字出力してくれる分析器、あるいはまた磁気記録によるデータレコーダくらいしかなく、今みたいにパソコンどころかメモリーカードや、スマホデータ記録といった直接AD変換記録してくれるものなんてなかった。

・・・いや、あるにはあったけど、そのAD変換機器パソコンをつないで自家製プログラムで処理したりしていた。

とにかく、アナログ値をどうにかしてデジタル値に変換するのは、手入力やらプログラムやらで処理するほかはなかったから、それなりにプログラム技術をどうしても身につける必要があった。

 

一番最初に書いた、ちょっとはまともに動くプログラムとして憶えているのは、サインとかコサインみたいな計算をやってパソコン上で波形を構成し、その値を使ってXYペンプロッターで作図する、というものであった。

ペンプロッターなんて今でも生きているのをたまに見る事があるけど、今は普通にプリンタだよね。

でも当時は、プリンタで作図したものを打ち出すとかありえない世界だった。ドットインパクトプリンタ?くらいしかなかった。

感動したよ、実際には今とは比較にならないほど極超低速だけども、滅茶苦茶にウィンウィン素早く動くペンに感動したもんだ。

僕が書いたとおりに動く、と言う感動。

言語はN88-Basic

ペンプロッタをRS-232Cパソコンと繋いで、描画命令を送るとその通りに動く。

但し、プログラムバグがあると紙とペンのインクを無駄にする。

僕はそこからプログラムを書くという魅力に取り憑かれるようになり、その会社では在職期間中、多分数で言えば一番プログラムを多く書いたのではないかと思う。と言ったって小さなさなプログラムばかりだが。

なお、それから何年か経ち、レーザープリンタが導入されたけども、作図のやり方自体は変わらず、プリンタに直接描画命令を送って、みたいなやりかたをしてたよ。だって当時、レーザープリンタを買うと漏れなくコマンドマニュアルが付いてきた時代だったしね。

 

しかし、言うまでもないけど、DOS上で、いちいちエディタを使ってBasicソースコードを書き、保存してrunさせるという一連の手続きはとても面倒で、N88-Basicは行番号を行ラベル、GOSUB~RETURNという感じでのサブルーチン処理が出来たくらいで、例えば変数初期化を忘れて気付かずに同じ変数名でサブルーチンを使ってしまうと、最悪ハングアップしてどうしようもなくなり、リセットする羽目になること屡だった。

から自家製ブレークポイントと言うか、STOP命令ソースのあちこちに書いて、うまく行けばSTOPを削除するとかコメントアウトするとかは必須な当時だった。

 

そんなこんなで勤めてから半年くらいで確か社長マイクロソフトのQuickBasicを買ってきた時にはほんとに感激した。

構造Basicであることもさることながら、統合開発環境ほとんど全てやってしまえるってのが如何にすごい効率化を生むかを知った。

汎用サブモジュールを作ってしまえば、あとはそのソースファイルを読み込んで、引数与えてサブルーチンを読めば同じ記述を何度もこぴぺする必要から開放される。

あるいはもう、バイナリライブラリファイルにまとめて、クイックベーシック起動時にスイッチで読み込むバッチファイルとしてしまえば考える必要もない。

さらに、exe形式の実行ファイルも作れてしまい、特定の処理のためにいくつもそれ用に実行ファイルを作っておけば、プロンプトから一発で様々な処理が出来る様になった。

 

QuickBasic時代が一番多くのプログラムを書いたと思う。もちろん、数だけの話で行数や文字数ではないけれど。

しかしそれは、僕にとってのプログラミング世界を狭小なものにしてしまった。

ちっとも勉強しなかったと言えばそれまでだけども、僕はいまだにBasic言語しか使えない。

Cやらその他の言語を書けなくはないのだけど、Basic言語で先ず考えて、みたいな頭に出来上がってしまったみたいである。

 

いや実のところ、早いことBasic以外の言語も覚えたかったのだけど、その会社社長がそれを許さなかった。

一度、Pascalを使ったプログラムを書いた事があったのだけども、社内で僕以外の他の誰も触ることができないと言う理由で禁止されてしまった。

社長は元々FORTRANから始めた人で、BASICと非常に良く似ていると言う理由で、会社を立ち上げた時からBASIC一本やりだった。

彼はそもそもプログラムは書いたとしてもプログラミング技術にはあまり興味がない人で、とにかく仕事のために問題なく動きさえすればよく、言語などどうでも良かったのである

からプログラムスピードアップのためにC言語の導入を僕が進言した時には「それを覚える時間無駄」と取り合ってもらえなかった。

Windows時代になってVisualBasicが導入されてもそれは変わらなかった。

VisualBasic6.0にもなると、純粋オブジェクト指向ではないが、それなりにオブジェクト指向っぽいことは出来る様になっていたし、オブジェクトを扱う方が、サブルーチンコールだけに頼るやり方よりもずっと能率的だって事くらいは分かっていたので、僕はオブジェクト指向っぽくプログラムを書きたくて仕方がなかったのだけども、社長ユーザー定義変数を使うことすら許さない。

VisualBasicから最低限、フォームやらコマンドボタンを使う必要があるから、それらのプロパティメソッドなどを使わざるを得なくなっていたし、社長も使っていたのに、いざクラスを書こうとすると滅茶苦茶怒られた。

「一つ一つのプログラム会社資産であり君のものではない。別の人間保守できなければ、君がいなくなったらただのゴミだ」

というのが彼の口癖だった。

 

なので、構造プログラミングレベルで工夫するしかなく、それから数年後に辞めるまで、僕は構造プログラミング技術を磨き続けただけで進化は停止してしまったのである

Windows環境になり、VB5以降にもなると、プログラムはどんどん肥大化して行った。

DOS時代のようにメモリを気にする必要があまりなくなって行き、1つのプログラムで様々な事が出来る様になると、困った問題が1つ重くのしかかるようになって来た。

社長フローチャートを書かないと絶対に許さない。

どんな小さなプログラムでも業務上で使うものである限り、自分しか使わないユティリティーレベルのもの以外については、絶対フローチャートを提出し確認を貰う必要があった。

細かな変数やら関数やらのドキュメント仕様書は、ソースコード内に所定の様式コメントを書けばそれでオッケーだったが、小さなサブルーチンでさえもそれが存在する限り、細かくフローにしないとダメなのだった。

入社当時こそ、それが非常に勉強になったし、他人の書いたプログラム理解するのに役立ったのだけれども、慣れてくると煩わしくて仕方なかった。

だいいち、うちの会社プログラムを外部に売っているわけではない。

データ処理や分析など、業務に必要から作っているに過ぎない。

流石に、稀にある、ソフト設計自体重要意味を成す業務では、詳しい仕様書をまとめて、その仕様書を通して取引先とやり取りしたりしていたけども、そんなのは滅多にない話だったし、汎用プログラムでさえも、一回完成させたら、その中身を見ることなんか滅多になかった。

実際、不具合があったらフローチャートなんか見ずに、誰もが直接コードを叩いて直したりしていただけだし。

 

DOS時代の時は、そんなに大きなプログラムは書けなかったので、フローチャートもそんなに面倒ではなかったが(そもそも僕はめんどくさくなると業務自体を早く終わらせたいのでソースを完成させたあとにフローチャートを起こしていた)、VB時代になるとフローチャートがあまりにも複雑怪奇になって行き、そんなフローチャートを例え完璧に作っても、誰も読んで理解しようとは思わないくらいにさえなっていった。

僕以外の社員も実際困ってて、そのせいでみんな夜遅くまで残業するようになっていった。

社長はどうかというと、社長業が忙しくなり、自分プログラムする事は滅多になくなったし、あっても少しサブルーチン的なところを書いたりとか、大雑把なフロー書いて、実装社員に任せっきりだった。

但し、社員の作ったプログラムフローには絶対に目を通す人で、ソースコード自体はあまり見ないが、フローがしっかりしてないと何度でもダメ出しをし、社員社長のオッケーが出るまで何度も書き直さないといけない。

 

で、ある業務で、いつものようにプログラムを先に完成させてフローに起こし直していた時のことだった。

どーせソースコードなんか見ないだろう、と辻褄の合うようにだけフローを書き、実際のソースとはかなり違うフローチャートを提出し社長にオッケーを貰った。

ところが、その業務で追加の仕事が発生し、時間的に僕では無理で、社長が僕のプログラムを触るしかない状況になった。

フローとあまりに違うソースコード社長激怒し、しかしそれまでめんどくさいフロー起こしに鬱憤を貯めていた僕もその鬱憤を晴らすかのごとく、かなり暑くなって反論し返してしまい、もう少しで暴力沙汰になる手前まで口論して、それから数日後、僕は辞表を提出したのであった。

 

その会社を辞めてから、次の仕事は全く関連のない無関係な全く違う職種になり、パソコンこそ触るものプログラムなんか書くことはなくなってしまった。

DOS時代パソコン通信フリーソフトを二つほど作った事がある程度で、必要に迫られない限り、プログラミングをする人間ではない。

ただ、当時どうしても許されなかったオブジェクト指向だけはいつの日かチャレンジしてみたいなぁとは思っていた。

それで、あるとき思い立って、何度か仕事で生かせないかなぁと思い、エクセルVBAを使って、昔取った杵柄じゃないけども、こそこそプログラムを書くようになり、もしかしてオブジェクト指向的に書けばちっとは勉強になるかなぁとやってみたのではある。

しかし、大雑把な初歩的・概念的なことは知っていたけども、実際、オブジェクト指向プログラムしようとしても、構造プログラミングをあまりにもやりすぎたせいか、どーしてもオブジェクト指向的にならない。

歳を食ったせいもある。頭が新しいことを憶えたがらない。

クラス設計書であり、インスタンス実体である、とか言われても理屈こそ分かっても頭が理解を許さない。

フローチャートロジックばかりが頭に浮かんでしまい、インターフェース的な理解をしようとしない。

 

最近になってようやく、少しはまともなオブジェクト指向が身に付き始めたんだけどね。

ほんと、こんな歳になって、いったい何年掛かったのやらw

 

長々と、単に自分記憶を掘り出しただけの文章披露してみただけで、ごめんなさいです。では失礼。

2015-05-02

最古のプログラマブル機械プログラムによって動作の変化を制御できる機械)としては、1206年にアル=ジャザリが作った二足歩行ロボットがあると言われている。アル・ジャザリのロボットは、ボートに4体の演奏人形が乗ったもので、宮廷パーティで池に浮かべて音楽演奏したと言われている。プログラムカムにあり、それによって小さなてこを押して、打楽器演奏する。カムは実際には円筒ペグが突き刺された形であり、このペグの配置でプログラミングし、演奏パターンを変更した[1]。

1801年に開発されたジャカード織機がプログラマブル機械起源とされることが多い。この機械は、穴を開けた一連の厚紙(パンチカードの原型)を使った。穴の配列が布を織る際のパターン対応している。従って、カードを入れ替えることで全く異なる布を織ることができた。1830年ごろには、チャールズ・バベッジがパンチカードを使った解析機関を考案した。

このような先駆者発明さら進化させたのがハーマン・ホレリスであり、1896年にタビュレイティング・マシンカンパニー(Tabulating Machine Company、後のIBM) を設立した。彼はホレリス式パンチカード、タビュレーティングマシンキーパンチ機などを発明した。これらの発明情報処理産業の基礎となったのである1906年には、タビュレーティングマシンプラグボードを追加することで、組み替えれば様々な仕事ができるようになった。これがプログラミングへの第一歩である1940年代には、プラグボードによるプログラマブル機械が各種登場していた。初期のコンピュータにもプラグボードプログラムを組むものがあった。

パンチカードのつまった箱。プログラムデッキがいくつかある。フォン=ノイマンアーキテクチャ発明により、プログラムコンピュータメモリに格納できるようになった。初期のプログラム特定機械命令をそのまま並べて作られ、二進法記述されることが多かった。初期のコンピュータでは、電気的配線を変更したり、トグルスイッチなどで機械語を直接コンピュータ入力することで、プログラミングが行われた。しかし、機械語命令人間にとって扱いにくく、代わりに機械語命令ニーモニックとよばれる略語を割り当てた、アセンブリ言語が開発され、プログラマ命令をテキスト形式で記述できるようになった。アセンブリ言語は、コンピュータCPUによって種類が異なるため、アセンブリ言語でかかれたプログラムは、他機種のコンピュータで利用することができなかった。また、単純な処理をアセンブリ言語記述する場合にも、基本的な処理命令を大量に記述する必要があった。

そこで、特定コンピュータ依存しない記述方法で、処理の内容をより抽象的に記述するためのプログラミング言語が開発された。そして、プログラミング言語によって記述されたプログラムを、コンパイラを利用して機械語翻訳することで、実行プログラム作成することが一般的になった。1954年最初プログラミング言語の1つであるFORTRANが開発された。これにより、演算を直接数式のように記述できるようになった(例えば、Y = X*2 + 5*X + 9)。このプログラム記述(あるいは「ソース」)はコンパイラと呼ばれる特別プログラム機械命令に変換される。他にも様々な言語が開発された(ビジネス用途COBOLなど)。プログラム入力は依然としてパンチカードやさん孔テープで行われていた。1960年代後半、記憶装置や端末の価格が低下してきたことにより、キーボードから直接コンピュータプログラム入力できるようになってきた。このため、修正が容易に行えるようテキストエディタが開発された。プログラミング言語の処理方式は、コンパイラ方式インタプリタ方式に分類される。

コンピュータ能力は時と共に飛躍的な進化を遂げた。このため、より抽象化されたプログラミング言語が開発されるようになっていった。抽象化レベルの高い言語オーバーヘッドも大きいが、コンピュータ自体の性能の進化が激しいため、多少オーバーヘッドが増えても以前よりも高性能な動作が実現された。このような抽象化レベルの高い言語の利点は、習得が容易であることと、プログラム作成時間が短縮されることであるしかしそれでも、巨大で複雑なプログラムや、高速性が何よりも重視されるプログラムでは、現在でも比較的低レベル言語を使っている。

20世紀後半を通して、先進国ではプログラマが魅力的な職業の1つとされてきた。しかし、発展途上国の安い労働力プログラミングに利用する傾向が強まっている。この傾向がどれだけ続くのか、それによってどのような影響があるのかは未知数である

2015-01-16

http://anond.hatelabo.jp/20150116031439

viemacs新規言語作ったわけじゃない。

viqededexviと元々存在した別のエディタから派生している。

emacs採用したlisp世界で2番目に古い高級言語。(1番目はFortran。それ以前はマシン語アセンブリ言語だけ)

ちなみに昔はlisp計算機工学を学ぶ上での必須教養だった(つまり使い手が多かった)からマクロ言語として選ばれたのは必然

あとlisp以外の言語を使えるemacs亜流もあった(過去形)はず。

2014-05-16

http://anond.hatelabo.jp/20140516124556

原子核の分野やFORTRANの分野で技術継承の何が失われているのかはわからないんだけれでも、

私が考えるに、現在の「原子炉設計利権込)の技術」が失われることで、

今まで切り捨てられていた別のタイプ原子炉スポットが当たるということはないのだろうか?

自然環境の変化で、恐竜のような大型生物がほろんで、小型の哺乳類や小型の爬虫類がいきのびたような。

FORTRANはどうするかね。「動いているものは変えるな」の原則からすると、絶滅を待つしかないのか。

十分パイプラインが深く、並列化が進んでいるだろうFORTRANは、進化のしようがないね

2014-04-10

http://anond.hatelabo.jp/20140409010816

いくつかまとめて反論したい

まず最初に言っておきたいけれども、僕自身はHaskellが大好きな関数型言語大好き人間である、ということを先に述べておきたい、それを踏まえた上で以下をお読みいただきたい

最初の「オブジェクト指向 v.s. 関数型プログラミング」や「ふたつのアプローチ比較」はまあ問題ないかなぁという感じ、問題があれば他の誰かに任せます

問題は「関数型プログラミングの利点」と「関数型プログラミングの得意分野はなにか」

関数型プログラミングの利点」に対して

まず「関数型プログラミングの利点」だけれども、ファンクタが云々、モナドが云々、これは「関数型言語の話」ではなく「Haskellの話」である

そこを引いてあくまでHaskellの話だと割りきって見たとしても、「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」? モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリ設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう、パーサの理解モナドの知識はあまり関係がないと言っても差し支えないのではないか

「書きやすい」に対して

「書きやすい」に関してはこれはもう「主観の問題だよね」以上の言い様がない、僕自身はC++Haskellの両方を書く人間で、確かにC++Hakellの方が「短く書ける」と「感じる」ことは多い、がしかしそれはあくまで個人の主観であり、更にはなにか明確な基準を取ったとして、やはりこれは「関数型言語」ではなく「Haskell」の話である、わかりやすく言えば「関数型言語であるLispを僕は読み書きできない」、特定言語の、主観に大きく左右される特徴を関数型言語一般の話であるかのように敷衍して話すのは感心できない

「静的型付け云々」に対して

「静的型付け」云々もこれはもう完全にHaskellOCamlの話であるLispErlangとは何だったのか

関数型プログラミングの得意分野はなにか」に対して

数値計算」に対して

多くの数値計算アルゴリズム逐次的に定義されている、関数型言語で扱いやすものではない、簡単にいえば「それFortranの前でも言えるの?」である

遅延評価はこれまたHaskellの特徴であり関数型言語一般の特徴ではないし、別に他の非関数型言語エミュレートできないものでもない、更に言えばこれが何か数値計算に対して有利な何かをもたらすかといえばそういうわけでもない

分数虚数が扱えます」、に至ってはむしろ近頃の言語で扱えない言語何かあるんですか、である、大抵の言語にはその手のライブラリはある、関数型言語に限った話ではない

テキスト処理」に対して

お前それShellやPerlRubyPythonの前でも言えるの?

「並行処理」に対して

この手の話は「ライブラリ」の話になり、言語パラダイムにより議論されるべき問題ではない、もちろん自動並列化などの問題で数学モデルに基づいていることが多いHaskellなどは有利かもしれない、が、やはりそれは特定言語特定ライブラリの話になり、関数型言語一般の話ではない、並行処理の扱いにくい関数型言語設計など容易だろう

レシピ」に対して

言語の話でも言語パラダイムの話でもライブラリの話でもない、個人の技量の話だろう、関数型言語でも下手にしか書けない人は上手には書けない

GUI」に対して

GUIライブラリ設計にもよるけど、GUIってOOPの強い分野だと認識していたのだけれど、さてはて

まとめ

最後に要点をまとめると

記事そのもの価値基本的にないっぽい、こういう記事撲滅されないかなぁ

2014-02-16

http://anond.hatelabo.jp/20140216183624

Fortranプログラムなんて、入出力は標準かテキストファイルでしょ。

凝ったUIDB連携も無いだろうし、ソフトウェアの中でも自動テストが導入しやすくて効果が得られやすい部類だと思うけど。

古いプログラムの書き直しをしたいけど

研究室で使っているFortran77のプログラム

配属されてからいろんな機能を追加してきた。中規模くらいのプログラムで、研究ではメインで使っている。

でもだんだんつらくなってきた。とにかく見づらい。

1980年代に作られたこのプログラムは今までの人たちのコメントの蓄積が半端ない

プログラム書き換えでとりあえずとっておいたコードコメント、書き換えた日時と人が書いてあるコメントプログラム中に混在している。

これらは実際に動く部分のコードよりも多く、可読性をかなり下げている。

前者については、ほとんどが不要だと思うのだがあまり考えずに消すと将来困るかもしれないのでちゃんと確認して消したい。

そして未だに残るGOTO文とFORMAT文と文番号。implicit noneではない暗黙の型宣言。

Fortran入門: 知識として必要な過去のFortran このページに書いてあるほぼすべてが詰まってる。

COMMON文もほぼすべてのサブルーチンにあったが、これはなんとかmoduleに書き換えた。

moduleに書き換えたとはいえ、本来は引数で渡したほうが適切なもの機械的にCOMMONからmodule文に書き換えたためその辺も見直したい。

一番面倒なのが一行の文字数制限。何段かのインデントを入れるとすぐにアウト。

エディタ使ってると自動でインデント入れてくれるのでいちいち直すのも面倒だし、インデント好きなのでできればインデント入れたい。

エディタといえばシンタックスハイライトfortran77モードだとうまく表示できないことが多い。

allocatableとかmodule文なんかは厳密に言えばfortran90以降の機能だけどコンパイラ対応してくれているおかげで使える。

でもエディタシンタックスハイライトにはそういうコンパイラが気を利かせたような実装は含めないのでうまく表示されない。

fortran90モードを使うと今度は行頭カラムの空白が守られなかったりしてコンパイルエラー

すっげー書き換えたい。全部きれいにしたい。他言語にするとあまりにも変わりすぎて教授が混乱するからせめてFortran90にしたい。

でもさ、よく考えるとこの書き換えって全く自分の実績にならないんだよね。

そもそも今までプログラム改良して出来る計算の幅をだいぶ広げたけど、それ自体は発表できないからほぼ表に出ない。

計算結果を出してそれを発表しないと表面的にはまったく意味が無い。

ましてやプログラム保守作業であるこの書き換えは計算結果に影響をおよぼすものでもないから研究成果にはまったく現れない。

しかプログラム書き換えた自分だけじゃなく、みんなも使うから書き換えた自分特別得するわけでもない。

プログラムすべてのコードを書き換えるのは単純に機械的にやっても結構時間がかかるし、書き換えても一発では絶対にうまく動かないから修正にも時間がかかる。

研究者の中にはそういうプログラム書いてばかりの人間馬鹿にする人もいる。プログラムを書いてる研究者自分の分野ではかなりヒエラルキーは低い。

情報系でもないんだし、それが研究の本筋じゃないからというのはわかる。自分たちのやるべきことじゃない。(でも専門性の高い道具を作り、整備する技術・人も必要なんじゃないかなと思ったりもする。)

やってもあまり得しないし他のことやったほうが絶対に自分の将来を助けるけど、ほっとくのもなんだかなあと悶々としている。

多分きれい好きの人が自分の部屋を見たら同じ苦悩を抱えると思う。

2014-02-10

自殺を考えてる

小学校の頃は両親の離婚を辞めさせるために自傷行為に走り。

中高とずっとイジメられていて、殴り殺されたら楽になるのにとずっと考えていた。

当然友達なんて一人もいなかった。

その頃は毎日毎日死ぬことばかり考えていた。

けど、ToHeartこみっくパーティーToHeart2アニメを見るために、東映KANONアニメを見るためにとりあえず生きていた。

P/ECE音楽を入れて電車の中で聞く時間けが救いだった。(叩かれそうだから、ボカして書いてるけど色々察し欲しい)

そして、ToHeart2アニメを通じてラジオという人間が生み出した最高の娯楽と出会い、少し前向きになり、

そのラジオで話されていた「同性愛」というものに興味をもち、ジェンダーについて学びたく大学進学のために勉強をはじめた。


大学は第一志望には通らず、第二志望の学校になった。

そして大学生の頃からは本気で幸せだった。

相変わらず友達は一人もいなかったけど、教授院生の先輩たちと仲良くなった。

最初教授外国語講義で興味をもって、その教授交通学の講義をとって、その教授ゼミに入って、

そこで交通シミュレーションプログラムに触れたのが、僕が動いているプログラムに触れたはじめたの体験だった。

教授自身に興味をもち、交通学に興味をもち、そしてプログラムっていう仕事に繋がる楽しいことが見つかった。

論文を書いて学会に出たはいいけど、質疑応答でしどろもどろになって、ホテル教授に慰められたのもいい思い出だ。

回生の先輩の卒論用のプログラムを代わりに書いていたら、気づくと卒論の本文までほとんど僕が書くことになったのも

自分が四回生になったときに、ゼミの人たちのプログラムの大半に携わっていたのも、大変だけど本当に楽しかった。


そのあと就職してからも楽しかった。

大学でやっていたFortranとは全然違う.Netをはじめとするマイクロソフト技術に触れたことで、より一層プログラムが好きになった。

特にSilverlightを使って3DアニメーションUIを開発したときは、大学の時に学んだ数学がこんな所で役にたつのかあ、とシナプスが繋がる楽しさがあった。

プログラムだけじゃなくて、自分で企画したWebアプリプレゼン資料の準備をするのも楽しかったし、

夜遅くまで企画会議と題して先輩たちとダベるのも楽しかった。

派遣でいった先で、Flexに触れて、暇なときパフォーマンスチューニングゴリゴリやって、レスポンス10倍ぐらい早くできたとき

自分この仕事向いてるんじゃないかな?」とか天狗になって、そのあとそのパフォチューのせいでバグが見つかって大目玉を食らったけど

それでもやっぱり、楽しかった。(本番環境デプロイする前で本当に助かった)

RIAだけじゃなくて、WindowsFormsでガントチャートをなんのライブラリを使わずにつくる仕事も楽しかった。

D&Dの実装はメンドイし、お客からは「この線を船の形にしてや!」なんて無茶振りにこたえるのも楽しかった。


そのあと、確かSilverlightが実質終焉を迎えた頃、事件があった。

女性社員と個人的にもめたのが拗れて、裁判沙汰になり、和解金を払い解決した。

その事件のせいで、就職した会社はいられれなくなったものの、タイミングよく独立する上司がいたたため、

その人についていって、仕事に困ることはなかった。


本当に楽しかった日々は、それ以来ツラいだけの日々になった。

うちの地方方言でいうとエラい

なのに、今僕は中高生のツラかったあの日々よりも、ツラいと感じている。

何も理由はない、転職したけど仕事にも不満はない、友達は相変わらずいないけど、Xboxをつければフレンドのアバターが迎えてくれる。

はてなログインすれば、お知らせのところの赤い丸数字承認欲求を満たしてくれる。

なのに、今ただただツラい。

アニメラジオの声がまったく理解できず聞いてられない。

大好きだったゲームミュージックもただの雑音としか思えない。

本や漫画を読んでも、文章がブロック単位で入ってこない、ただの一文字一文字の羅列としか思えない。

ゲームをしていてもコントローラーを持つ手がいうことを聞いてくれない。

仕事もあれだけ楽しかったプログラミングがただの穴を掘って埋める意味のない作業にしか思えない。

特に女性の声は聞くだけで発狂しそうになる、タオルを口につめないと大声をあげてしまいそうになる。

ただただ、ツラい。

足を動かすのが、トイレにいくのがツラい。


それでも、その上司のことを考えると自殺するわけにはいかないと思い頑張ってきた。


けれど、どうももう僕がいなくても、大丈夫になったと思う。

そう思えたときから、ツラい日々が「どう自殺するか?」を考える日々になった。

今請け負っている仕事が終わるのが三月末。

そろそろ退社の意思を伝えて、六月ぐらいに退社して、自殺しようと思う。

嘘です。

自殺なんてしたくない。

死にたくない、ラジオを聞きたい。

ゲームがしたい。

アニメがみたい。

本が読みたい。

プログラムがしたい。

でも、その全てが楽しくないんです。


誰か僕を見つけてください。




追記

http://anond.hatelabo.jp/20140408220559

2013-11-10

http://anond.hatelabo.jp/20131109185658

組み込み系の仕事をしている二年目です。

毎日仕事ができなくて凹んでます元増田の2年目が羨ましいです。

研究室では解析アプリケーションを作るのにC,C++,Fortranをいじってました

また趣味サーバの立ち上げやWeb系のJavascriptPHP,Pythonなどもいじっていました。

なんである程度どっちもわかります

で、そんな自分組み込み系の仕事に入ったわけなのですが、

まったく違う。組み込みWebアプリケーション文化が違ったわけです。

ここからはあくまで私の体験ですが…

まず、組み込み系はハード接続図)を読めないと話になりませんでした。

CPUFLASHSRAMFPGACPLDアナログ回路、バッファ、それらをつなぐバス、電源、接点、コネクタスロット、A/D、D/Aなどなど、

これらがどうつながってるか意識しなくてはいけません。SoCとか行っても接続図読めないと意味ありません。

この段階でプリント板の単体検証もしてもらいます

広い話、プリント設計組み込み系の仕事なんですよね。

次に、FPGACPLD設計があります言語VerilogVHDLです。XilinxAltera、Actel等のデバイスに書き込みます

PLDって言うのは言語で書けるハードです。似ているようでCPUと違うので設計にはスキル必要です。

この段階でシミュレーション(modelsim等)をしてもらいます

ここも立派な組み込み系の仕事です。

次にCPUです。言語はC,アセンブラC++です。でもほとんどがCです。デバイスルネサスSHとかです。自分はここで見習いをしてます

CPUに直接入ってくる信号(接点・バス等)もありますが、前述のFPGACPLDから入ってくる信号のほうが多いです。

で、アプリケーションWeb系と何が違うかといえば、ものすごい短期間にいろんなことが起こります

リアルタイム処理っていうのでしょうか。割り込みとか聞いたことありませんか。

要はOSがないので自分でなんでも考えなきゃいけないわけです。

CPU検証はMISRA-Cや専用のカバレッジテストツールで行います

一般的組み込み系の仕事と言われるとここを指すと思います


実際にはユーザーインタフェース設計組み込みに入ります

接点の調整とかLCDパネルとかメンテナンスのツールだとかがないと装置に指令を出せません。

これらにもCPUが入っているわけなので別にコードを書く必要があります組み込み系の仕事です。

さらPLCってのもあります

これは言語でかけるリレー回路です。リレーってのはスイッチです。

スイッチ操作することで接続されている機械操作(電源の入り切りとか)します。

これもCPU,PLD等とは全く違う方式(ラダー)で書きます。十分組み込み仕事です。

最後に組み合わせ評価・試験です。

ユニット試験では通っても、組み合わせ試験で動かないというのは100%あると思います

試験仕事じゃないと思われるでしょうが自分はここも立派な組み込み系の仕事だと思ってます

この段階で確認がとれた後、装置に渡せるようになります

などなど一言組み込み系の仕事といってもいろいろあるわけです。

上の中の2つ3つを仕事に使えるレベルまで持って行くには10年、20年はかかると言われました。

ここで表題の件なのですが、元増田の人は経験8年なので、例えばFPGAを8年やってきてCを書けと言われても大変だと思います

特にその後にWeb系の仕事(これも一言で表すにはいろいろジャンルがあると思いますが)をされてきたとのことなので

いろいろとあったのだと思います。逆にずーとやっていた分野のことを任せるといいかもしれません。

まずどんなことをやってきたのか聞いてみたほうがいいと思います

2013-04-13

Haskell危険性について

Haskellの正体とは】

これは某大手電器メーカー幹部の話です。

彼は、こう耳元で囁きました。

Haskellコンパイラが吐いたバイナリは食べるな」

国際Fortran学会会長プログラマ治療の草分けである森×敬一博士によると、、、

Haskellコンパイラが吐いたバイナリだけを与えた実験動物はみんな死んでしまった。

明らかにコンパイル最適化有害ものが発生したはずです。

ふつう言語では大域変数の書き換えによってプログラマは実行時の環境を容易に制御できる。

ところが純粋関数型言語原理が全く異なります」と警告しています

まず、大域変数に対する「再代入」「領域解放」「再割付」する実行時環境制御方法と全く異なり、エネルギーを持つ素粒子の一種である電子を揺らして計算を行います

これを”集積回路”といいます

これに似たものとしてマイクロフィルムがあります

マイクロレンズと短波長光を組み合わせて小さな領域に焼きこみを行うのです。

これには世界中消費者団体が反対しています。その理由は?

「本が小さすぎると目が疲れる」とのことです。

ミクロレベル素粒子振動、原始帰納関数の生成、、、、。これが、Haskellコンパイラにより生成したバイナリの質が”イマイチ”な理由なのです。

動物Haskellが評価した水を飲まない】

GHCiで評価した水と、ふつうの水を並べておくと、動物は決してGHCiで評価した水を飲まないといいます

それは本能危険直感するのです。

これを栄養士の東○百合子氏は、このように指摘します。

プログラマの脳細胞破壊する」と。

政府大企業利益を優先して”不都合な真実”は徹底的に隠蔽

オブジェクト指向言語のジャバ言語の方が優れていることを主張する何万という論文がありながら、政府企業も未だに認めようとしません。それは莫大な利益を損失に繋がるからです。

彼らは”不都合な真実”は徹底的に隠蔽するのです。

実験動物が死んだ」事実は、何か有害ものが生成されたと考えてよいのではないのでしょうか。

※追記:元ネタは「動物は決して電子レンジの水を飲まない」なんかで検索すると見つけられると思います

2013-03-28

科学技術計算Python

科学者必要とするもの

必要ものの列挙

現存する解法

どの解法が科学者にとって役に立つのか?

コンパイラ言語:C, C++, Fortran, 等
スクリプト言語Matlab
他のスクリプト言語Scilab, Octave, Igor, R, IDL, 等
Python はどうなの?

2011-12-30

大学機械工学科について急に語りたくなったので語る。

なんか、誰の役に立つの分からんけど、私が高校生の頃にこういう説明があったら良かったなぁ……とふと思ったので書いてみた。

さて、大学工学部機械工学科に入学するとしよう。基本的に機械工学科に含まれる研究分野は多い。もちろんそれには理由があるのだが、それでもほぼすべての学生が学ぶ共通の内容があり、機械工学科を卒業した学生企業が期待するのはそれらの基礎知識である。そういう意味機械工学は非常に実学に近いと言っても良い。

四力とは何か

機械工学科の教員は本当に口を酸っぱくして「四力を身につけろ」と何度も何度も授業の度に言ってくる。古いタイプ教員ほどその傾向は強い。いわく、「専門分野の基礎がわかっている人間社会では強い」、「四力が身についていなければ学科長が許しても俺が卒業させない」、云々。で、その四力というのは以下の4つの力学」のことを指す。

機械力学というのはいわゆるニュートン力学でいう「剛体の力学」で、弾性・塑性変形しない対象がどのように運動するかを扱う。振動工学とか解析力学とかはだいたいこの延長線上で学ぶ。高校の力学微分積分を足した感じだと思えばいい。

熱力学マクロで見た気体や液体の持つエネルギーを対象にする。これも微分積分エンタルピーエントロピー概念を除けば高校で学べる物理とそう大差はない。次の流体力学と合わせて熱流体力学というジャンルを構成していることもある。統計力学熱力学の延長線上で学ぶことが多いが、量子力学とともに挫折する学生が非常に多い。

流体力学はその名の通り気体と液体を合わせた流体の運動について学ぶ。航空関係の仕事がやりたいなら必須。多くの近似法を学ぶが現実にはコンピュータシミュレーションが用いられるのであまり細かく勉強しても役に立つ場面は少ないかもしれない。下の材料力学とは連続力学という共通の基礎理論を持つ遠い親戚。

最後材料力学は、弾性をもつ(=フックの法則に従う)固体の変形が対象。建築学科とか土木工学科だと構造力学という名前で開講されているが、内容はだいたい一緒。これも多くの近似が含まれる体系で、実際にはコンピュータを使った有限要素法でシミュレーションする場面が多い。とはいえ基本を大学学部時代に学んでおくことは非常に重要

で、これら4つの科目がどう生きてくるかというと、たとえば20世紀における機械工学結晶であるところのエンジン設計なんかにはこれら全部が関わってくる。機械にかかる荷重や振動を解析し(機械力学)、エネルギー効率の高いサイクルを実現し(熱力学)、吸気と排気がスムーズに行える仕組みを作り(流体力学)、これらの条件に耐えうる材料を選ぶ(材料力学)。もちろん就職したあとにこれらすべてに関わることはないし、実際に使える高度な知識を教員が授けるわけではないが、機械設計に際しては必須の基礎知識ばかり。とはいえ後のように四力から直接発展した研究をしているところはまれで、院試のために勉強したのに後はもう使わなくなった、なんてこともままあるわけだが……。

なお高専からの編入生が入ってくるのは2~3回生なのだが、彼らはすでに四力を身につけていることが多く、運が良ければ通常の学部からは羨望と尊敬まなざしを勝ち得ることができる(しか英語ができないので研究室に入ってから苦労することが多いようだ)。

四力以外は?

高度な数学電磁気学であったり、機械加工や金属材料設計に関する専門的な知識もカリキュラムに含まれることが多い。みんな大好きロボット制御工学範疇で、これは四力とは別に学ぶことになる。ロボットメカトロのもう一つの必須分野である電気電子系の講義ほとんどないので独学で学ぶ羽目になるが、微分方程式が解ければ理解にはさして問題はない。プログラミング数値計算などの授業は開講されていることもあるしされていないこともある。とはい機械工学科を出てガチガチプログラマになることはほとんどないし、教えてくれてもFORTRANか、せいぜいCが限界である。さすがにBasicを教えているところはない。……ないと信じたい。

実習や実験がドカドカと入ってくるのは理系宿命なのだが、特徴的なのはCADの実習。おそらく就職したら即使う(可能性がある)ので、研究室に入る前に一度経験しておくといい。もちろん実際にCADで製図するのは専門や工業高校卒だったりするのだが、そいつらをチェックしてダメ出しするのは大卒なり院卒なりの仕事になる。

研究室が多すぎる

四力を身につけたらいよいよ研究室に配属されることになるのだが、基本的に四力を応用した分野ならなんでも含まれるので本当に各研究室でやっていることがバラバラ。隣の研究室が何をやっているのかは全くわからない(もちろんこれは機械工学科だけではないとは思うが……)。そのため学科イメージを統一することが難しく、どうしてもわかりやすいロボットなんかをアピールすることが多くなってしまう。とはいえそういう「わかりやすい」ことをやっている研究室は少数派で、実際は地味なシミュレーション材料のサンプルをいじくりまわしているところが多数派である最近医療工学系の研究をしているところが増えたらしいが、光計測だったり材料物性だったり航空工学だったり、あるいは全然関係ないシステム工学だとか原子力工学教員が居座っていることもあるようだ。こういう教員を食わすために機械工学第二学科(夜間向けの第二部ではない)が設立されたり、環境とかエネルギーとかが名前につく専攻が設立されたりすることがままある(昔は学科内に新しく講座を作るにはいろいろと制限があったらしい)。そういうところは(上位大学なら)ロンダ先として利用されるのが常で、そうした研究室を選んでしまった学部生はマスターの外部生の多さに面食らうことになる。

はいえいろいろ選べるならまだマシな方で、大学によっては計測か材料しか選べなかったり、工業高校ばりの金属加工実験を延々とやらされたりすることもある(ようだ)。やりたいことがあるならそれをやっている大学に行け、とは機械工学科志望の高校生のためにある言葉かもしれない。

で、ぶっちゃけ就職はいいんでしょ?

そう、就職は非常にいいのだ。「学内推薦が余る」という噂を聞いたことがある人がいるかもしれないが、まぎれもない事実である(とはい最近は上位校の推薦でもガンガン落としまくる企業が増えたようで就職担当も頭を抱えているようだが)。機電系なる言葉が広まったのはネットが登場して以降らしいが、機電系機械工学系と電気電子工学系、というぜんぜん関係ない2つの学科をまとめてこう呼ぶのは、それだけこの国の製造業でこの2学科出身者が必要とされているということだろう。我らが機械工学科の後輩たちのために、これから経済産業省には「モノづくり立国」なるわかったようでよくわからないスローガンを推進していただきたい。

inspierd by http://anond.hatelabo.jp/20110929232831

追記:あえて上位と下位の大学事情をごっちゃにして書いているので、受験生諸君はあまり鵜呑みにせず自分リサーチするようにお勧めする

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん