「FORTRAN」を含む日記 RSS

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

2018-09-24

現代社会において社会の大多数を占める人類が現役労働生活を送る期間にわたって使い続けられているソフトウェア関連の技術には何があるだろうか。

その期間を約40年間(20代前半~60代前半を想定)とすると、2018年から見ると1978年以前に導入された技術だ。

COBOL

COBOL1959年に開発された。ただし、COBOLの規格自体1993年まで更新されている。

仮に1978年からアップデートしていないのならば、COBOL-78、または、日本場合第一次規格(COBOL-65相当)のいずれかになる可能性が高い。

FORTRAN

FORTRAN1954年に開発された世界初高級言語である。もちろん、FORTRANも規格の更新は行われている。

仮に1978年からアップデートしていないのならば、FORTRAN-77が理解している最新の規格となる。

C言語

C言語1972年に開発された。当然C言語も規格の更新が行われている。

このため、仮に1978年から知識アップデートをしていないのならば、K&Rが最新の知識となる。

当然だが、処理系GCCLLVM+Clangではない。

UNIX

UNIX1969年に開発された。ただし、その後も実装仕様修正され続けている。

仮に1978年技術からアップデートしていないのならば、その仕様実装Unix Version 5~6(System Vでは無い)、または、BSD 1.0で止まっていることになる。

POSIXはまだ無い。

TCP/IP

1973年に着想された当初、TCP/IPは両者の責務を単一プロトコルが持っており、そのプロトコルTCPと呼ばれていた。

1978年トランスポート層インターネット層が切り分けられ、TCP v3IP v3となっている。

現在使用されているIPv4は1981年RFC化されており、ARPANETに完全に適用されたのは1983年になる(当時はIP/TCPと呼ばれていたようだ)。

このため、TCP/IPがこのリスト対象であるかはかなり微妙だ。

機械学習

ディープラーニングの礎の1つになっている多層パーセプトロンの初出は1961年のようだ。

マイクロプロセッサ

1978年にはIntel 8086が発売されている。

RISCはまだ無い。

フレームワーク

無い。

HTTP

無い。

どれぐらい無いかというと、Sir Tim Berners-LeeがまだCERNにいないぐらい無い。

ちなみに、HTTPはどうもTBL個人プロジェクトが源流のようだ(あの時代に?)。

Lisp

エイリアン生命体が利用するこの奇妙な言語は、1958年誕生した。

1978年から現在まで生き残っているLisp処理系Schemeのみであるが、この時点での仕様はR1RSである

ただし、マクロ1963年時点でLisp 1.5に追加されている。

他にも色々あるとは思うのだが、何があるだろうか?

2018-09-07

まれ変わったら何になりたい?

Fortranになりたい

科学技術計算で他を圧倒したい

2018-07-31

数値計算問題をいまどきの言語で教わりたい

横軸に言語を並べる。 Fortran, C, C++, Python, Go, Rust, Kotlin, あとなんか好きなもの並べる。

おっさんに対抗するためにFortranとCとPythonは必ず書いておく。

縦軸に数値計算関連のキーワードを並べる。

標準で扱える数値の精度、複素数, 多倍長演算, 特殊関数, 線形代数, 乱数, 高速フーリエ変換, 統計, その他いろいろ。

交差するところにライブラリ名前を書く。標準で持ってるなら標準装備とか○とか書いとく。

という作業を誰か俺の代わりにやってくれるか既にあるなら教えてください。

2018-07-03

anond:20180703174924

Fortranからプログラムに入ったワイ

bigger thanよりもgreater thanの方が馴染みやす

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-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 はどうなの?
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん