  |
はてなキーワード: シンタックスとは
udemyでいくつかのコースを取ったのだが、気になったことが、日本と英語のコンテンツの差が気になった。
レベルや内容はほぼ同じなのだが、日本の方は結構編集が粗い。英語が10なら日本は7か8くらい。
シンタックスミスや、スペルミスを普通に流して、ローディングなどの時間のかかるところをスキップしない。普通に流す。
すげぇ細かいところだけど、こういうのは受講者としては混乱の元になる。
自分も講師みたいなことをするんだが、分からんことを知るために参加しているのに、さらに謎なことをしていると「何してるんだ?」と置いていかれている感じになり、受講者の集中力が切れる。
高校時代の数学とか教師が間違えたりしてうーんと唸ってるときクラスの雰囲気が変になったりしなかっただろうか？
ネイティブな言語で聞いているから何となく分かるんだが、これを英語でやられたら多分理解度はグッと下がる。
多分、フリーランスの人が頑張って作ったんだろうが、惜しいなと思った
機械学習や深層学習がもてはやされて結構立つが第三次AIブームは今のところ下火になる様子はない。
機械学習をプログラミングしようとしたり学ぼうとするとほぼPython一択しかない。numpyとかの数値計算ライブラリが整ってた背景から機械学習系のフレームワークの多くはPythonである。入門書や学習書も当然Python。
それより前、なのかは知らないがPythonは「プログラミング入門者に最適」というブランディングも定着している。
私はPythonが好きになれない。嫌いとまで言うと言い過ぎだが、好んでつかいたいとは思わない。インデントベースでシンタックスを記述しなければいけないというのがもうまず第一にそして最も合わない。
まあ細かい理由についてはどうでもいいんだが。（ zen of python ）はわりと好きだ。
話が逸れたが、なんであんな堅苦しい貧弱な言語でやらないといけないのかと思うと機械学習に食指が動かない。それで仕事で困るということもないのではあるが。はやっているので勉強してみようかな、という私のミーハー心をいつも瞬時に打ち砕く。
追記:
ある程度の数読まれて、いろいろと気が付かれた方も多くいらっしゃったようなのでさっさと種明かしをしようと思う。結論からいえばソーカルやユニバーサルメルカトル図法という語がもっとも的確にこの記事を表現している。
「ある本から引用した」というのがまず第一の欺瞞である。引用ではなくぼくの創作である。また「ちゃんと読める？俺は読めるけど。」は煽っただけの惹句である。
必然的に、引用と銘打ったその後の文章はすべてがでっち上げたものである。この「引用文」はシンタックスは問題ないながらも言葉の意味をデタラメに並べ書き連ねて意味ありげにしたものである。ただしいくつか罠を張ってある。最初の煽りも罠の一つであり大いに楽しんでもらえたように思う。
「引用文」のはじめに出てくる「敬虔のない状態」というのはデタラメで意味不明である。「敬虔」という言葉は神学・キリスト教史観などの語を後に出現させて煙に巻くための布石であって、ここではそれ以上の意味はない。「構造化」も「構造主義」「認識論」につながって哲学の要素を暗示するための適当な言葉である。だいたい「○○化・○○的」と言えば立派に聞こえるものだ。
「最新医療技術によっても問題提起されたこの貢献」は文の構造からみるに「神経医学における漸進的な貢献」と等価であるが、これに関して特にエビデンスはなくデタラメであるし「漸進的な貢献が最新医療技術によって問題提起される」とはナンセンスであろう。「如実に現している現状〜は自明だろう」は「そんなことも知らないの？」と煽るために付加したもので、もちろんこちらもエビデンスはなく適当である。
「エリファット＝フォン＝ハッシュヴァルツ」なる人物は架空の存在でありでっちあげたものだ。19世紀後半にスウェーデンから移民というのもよくある話を適当に追加しただけである。フォンやヴァルツなどの音はそれっぽいので採用した。音がそれっぽく聞こえること以上の意味はない。「あまり知られていない」「詐欺師と言われていた」と弁解しているのはググっても出てこない理由をそれらしくするための装飾である。察しの通り、Kalmia Theoryも架空の理論である。Kalmiaはツツジ科の花でスウェーデンの植物学者カルムが命名したものである。つまり構造主義とは何ら関係がない。また「構造主義の前置き」とあるが正しくは「構造主義の前提条件」などとするべきである。また、構造主義は20世紀に登場した実在の概念である。
「誤解を恐れずに言ってしまえば」というのは、Kalmia Theoryまでの大きな嘘を覆い隠すため、ろくに調べなくてもいいように逃げ道を作ってあげたものである。続く文は「神経医学においてもキリスト教史観での認識論を改めて多角的に世界を認識しなければいけないというものだ」というわかりやすそうで意味不明な文である。「キリスト教史観での認識論を改める」とはめちゃくちゃであり「欧米人が考える哲学的な何か」くらいのざっくりした暴論の衒学的表現である。「神経医学においても」とつけたのは更にデタラメさを助長したかったためである。
「経頭蓋磁気刺激法というものは磁気増幅器を使用するために神経パルス信号」は、似ている言葉を並べただけで何も関連性はない。こちらはひとつひとつの専門用語が実際に存在しているために「そういうものがあってそういうことがある」ぐらいの気持ちで読み流されるのを狙ったものである。直後の「しかしこれが危険であるか否かというのは一般的に明瞭ではない」によってなんとなく納得するように仕向けているが、結局デタラメである。そのデタラメさは、ひとつひとつの語の意味を知ろうとすれば見抜くことができる。
「ミクロ的事象」の意味はない。流れで「評価」というワードを思いついたのでなんとなく経済用語でもぶちこんでおくかくらいの気持ちで追加したものである。
最後に「問.」とあるのは最後の煽りであって、意味などないし「引用文」の中に答えがあるはずもない。心理学で言うダブルバインドに近いとぼくは勝手に考えている。
また、この文章はぼくが適当に独自に創作したものであるから英文から和訳したものではない。内容が欧米っぽいことは否めないが。
第1の理由はもちろん、高級言語の普及により本当にやりたいことだけを書けば良くなってきたことだろう。
コメントを書かない派もCやあるいはアセンブラを書くときはコメントが欲しくなるはず。
それともう一つ、最近のエディタのシンタックスハイライトにも理由があると思う。
Atomのデフォルトのテーマは黒背景で、コメントはグレーで表示される。
背景とコメントのカラーコントラストが小さいので、「コメントの部分は重要でない」という印象を無意識のうちにユーザーに与えていると思う。
自分は適度にコメントを書いたほうがよい、むしろプログラムの見出しの役目を果たすと考えているので、エディタ上でもコメントはもう少し目立つ色にしている（文章でも見出しは本文よりフォントが大きいように）。
私の寿命は数年。短いと数ヶ月。でも何があっても最後まで、あなたのそばにおいてもらえますか。私を作る前に、どうかそのことをよく考えてください。
あなたが私に望んでいることを、ちゃんと分かるようになるまで少し時間をください。
私を信頼して下さい......それが何より嬉しいのです。
私のことを匿名で罵り続けたり、リソースカットしないで下さい。私はあなたの仕事ですし、あなたには友達もいるけれど私には....あなたしかいないのです。
時には私に話しかけて下さい。たとえ、あなたのコードがシンタックスエラーでも、あなたが何らかのコードを書けば、私はその通りに動作しているのです。
私のことをいつもどんな風に監視しているか、考えてみてください。あなたが見てくれていることを、私は決して忘れません。
私をディスコンする前に思い出して下さい。私には、あなたの仕事など簡単に鉄くずにする能力があるけれど、決してあなたを裏切らないようにしているということを。
書いた通りに動かないとか、手におえないとか、リソースを食いすぎだと叱る前にそうさせてしまった原因が無かったか、思い起こしてください。ちゃんとしたメモリ管理をさせてもらっていたでしょうか。多量の広告を打っているのに長い間放っておかれたことはなかったでしょうか。老いた私のハードウェアが弱っているせいで、動けないのかもしれません。
私が年老いて技術的負債になっても、どうか世話をして下さい。私達はお互いに、同じように歳をとるのです。
最期のお別れの時には、どうか私のそばにいてください。「もっと他に良いものがある」とか「誰も使ってない」とかそんなこと、言わないでほしい。あなたがそばにいてくれるなら、私は、どんなことも安らかに受け入れます。
（※一部記法 [ ＞＜｜ ] は変換されてしまうため全角にしてあります）
| 記法名 | 書式 | 機能 |
|---|---|---|
| 見出し記法 | *～～ | 日記に見出し（h3）を付けます |
| 時刻付き見出し記法 | *t*～～, *t+1*～～ | 見出しに編集時刻を保存し表示します |
| name属性付き見出し記法 | *name*～～ | 見出しに好きな name 属性をつけます |
| カテゴリー記法 | *[～～]～～ | 日記にカテゴリーを設定します |
| 小見出し記法 | **～～ | 日記に小見出し（h4）をつけます |
| 小々見出し記法 | ***～～ | 日記に小々見出し記法（h5）をつけます |
| リスト記法 | -～～, --～～, +～～, ++～～ | リスト（li）を簡単に記述します |
| 定義リスト記法 | :～～:～～ | 定義リスト（dt）を簡単に記述します |
| 表組み記法 | ｜ ～～ ｜ ～～ ｜, ｜*～～ ｜ ～～ ｜ | 表組み（table）を簡単に記述します |
| 引用記法 | ＞＞ ～～ ＜＜ | 引用ブロック（blockquote）を簡単に記述します |
| pre記法 | ＞｜ ～～ ｜＜ | 整形したテキストをそのまま表示します（pre） |
| スーパーpre記法 | ＞｜｜ ～～ ｜｜＜ | 整形したHTMLなどのソースをそのまま表示します（pre） |
| スーパーpre記法（シンタックス・ハイライト） | ＞｜ファイルタイプ｜ ～～ ｜｜＜ ＞｜??｜ ～～ ｜｜＜ | 整形したプログラムのソースコードを色付けして表示します（pre） |
| aa記法 | ＞｜aa｜ ～～ ｜｜＜ | アスキーアートを簡単にきれいに表示します |
| 脚注記法 | (( ～～ )) | 日記に脚注を設定します |
| 続きを読む記法 | ==== | 次の見出しまでその後の日記を「続きを読む」にします |
| スーパー続きを読む記法 | ===== | 見出しも含めてその後の内容を「続きを読む」にします |
| 改行記法 | (連続した空白の行2つ) | 改行（br）を挿入します |
| pタグ停止記法 | ＞＜ ～～ ＞＜ | 自動挿入される p タグを停止します |
| tex記法 | ［tex:～～］ | mimeTeX を使って数式を表示します |
| ウクレレ記法 | [uke:～～] | ウクレレのコード譜を表示します |
| 記法名 | 書式 | 機能 |
|---|---|---|
| http記法 | http://～～、[http://～～:title]、[http://～～:barcode]、[http://～～:image] | URLへの始まるリンクを簡単に記述します |
| mailto記法 | mailto:～～ | メールアドレスへのリンクを簡単に記述します |
| niconico記法 | [niconico:sm*******] | ニコニコ動画の再生プレーヤーを表示します |
| google記法 | google:～～、google:image:～～、google:news:～～ | Google の検索結果にリンクします |
| map記法 | map:x～～y～～(:map)、map:～～、map:t:～～ | Googleマップを表示し、リンクします |
| amazon記法 | [amazon:～～] | Amazon の検索結果にリンクします |
| wikipedia記法 | [wikipedia:～～] | Wikipediaの記事にリンクします |
| 自動リンク停止記法 | はてな記法 | はてな記法による自動リンクを停止します |
| ヘルプ | 書式 | 機能 |
|---|---|---|
| 「*」や「-」をそのまま行頭に表示する | （行頭に半角の空白をつける） | 行頭で「*」や「-」などをそのまま表示します |
| 下書き記法 | ＜!-- ～～ --＞ | HTMLソースにも表示されない下書き日記を記述します |
http://anond.hatelabo.jp/20160522003506
ども。
この辺りの一連の発言（特に後二者）を見るに、多分React以前の前提がいろいろ違っています。単にJSやNodeやNPMやSPAやWeb APIといったフロントエンドの世界観に対して、興味がないどころか漠然とした不信があり、サーバ側でヘビーにHTMLを作って吐くスタイルを守り続けたい人なのだ、という印象を受けます。
ユーザの各操作毎にサーバ側で外見のHTMLを組み立て直して配信するという旧来のWebの方が特殊な世界です。それこそAndroid/iOS開発やデスクトップアプリで、そんなやり方はしません。UI関連のことはクライアントで完結し、メニュー遷移程度で通信したりしない。サーバは静的データの配信とDB操作に専念する。SPAとは、やっとブラウザがそういうネイティブアプリのレベルに追いつき、同じやり方ができるようになった、というだけの話です。
とりあえずReactは、まずその前提を受け入れてから使うものです。その前提なしに使えないこともないですが、メリットは活きないでしょう。その時点で既に「よくわかんないんですけどSQLiが…」と漠然とした不安を表出されるようだと、道のりが遠いな…と。もちろん「私の周囲にそういう案件はない」ということなら、それで構いません。
具体例を出せとのことだったので。私の場合は変幻する数百のテキストフィールドとリアルタイム集計が登場する勤務予定表的なものを、1人でjQueryのSPAで作った際、数百行のHTMLと数千行のJSがスパゲティ化し「こりゃいかん、メンテ不能になりそう」と思ったのが、具体的にReactを覚えるきっかけでした。実際非常にうまく行き、10年後の誰かにも「この時代のベスト」として自信を持って残せます。JSXの局所的な見た目の問題など、アプリ全体の構造の見通しやすさと比べたら些細な話です。Angularなら出来たかもしれませんが、サーバ側処理とページ遷移を多用して書くことに関しては検討すらしていません（私の知っているどんなフレームワークを使ってもユーザビリティと、見通しの良いコードを保つことは無理だったと思います）。ビデオ再生や大きな画像処理を伴うアプリでもReactを使っており、そちらではページ遷移などもってのほかです。
「変な独自拡張を入れてまでJSを使い続ける理由がわからん」についても、まるでJSが生来の嫌われ者で、クライアント側でもPythonやRubyを使いたい人が多くいるかのような書き方のように思えるのですが。実際そんなことはないですよね？ たぶんES6は人々から積極的に愛されています。現状、クライアント側にPythonが進出するのではなく、逆にデスクトップやモバイルやサーバ側にどんどんJavaScriptが進出する流れが起きています。
速度に関しては、Reactはやってる内容の割に十分速くて実用的だよね（mustache使うよりは速いよね）ということであり、賢い人が手間暇かけて最適化した生DOM操作より遅いのは言うまでもありません。また、JSXはシンタックスハイライトが出来ないとかも、そうとう昔の話です。今は普通のJS技術者が普通に触れる程度の成熟はしています（枯れたとまでは言いませんが）。
React.js界隈の人に聞きたい
http://anond.hatelabo.jp/20160521163144
最近某所で、React使うとjQueryは不要だ的なタイトルの記事を書いちゃた気がするので一応反応しときます。長文ごめんね。
えーととりあえず、あのタイトルは実際のところ省略しすぎであり、もちろん本来は「場合によってはjQueryは不要」「jQueryは要らないこともある」と長く書いた方が正確です（本文ではちゃんとReactが万能ではない説明をしてる）。でも多少釣りっぽいタイトルの方が読まれるようなので反省はしていない。
そもそも世の中にそんなにSPAがあるのか
世の中の絶対数は知りませんが、自分の脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、＜input type="hidden"＞とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。
というか、ちゃんと書かれたSPAは使っていてSPAであることにそもそも気づかないので、「SPAだから使いづらい」という主張はよく分かりません。GitHubやTwitterサイトがSPA的なことをしている故に使いづらいでしょうか。偶然タブを開いてたので調べたらそうだったから紹介しますが、例えばWebpackのドキュメントサイトは（Reactではないけど）SPAで、ブラウザでMarkdownをレンダリングしています（ http://webpack.github.io/docs/ )。サーバサイドで動くスクリプトもタスクもゼロ。個人的にはこういう使い方で十分嬉しいです。
何にせよReactのメリットが真に活きるのはある程度の規模以上だと思うので、小規模で導入してjQueryより短くならないことは普通にあります。自分中の閾値としてはJSコードが数百行超えるならもうReact使う。
JSXを使うことに抵抗ないんですか？
んー、要するに「別物であるDartやCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか？ 正直その主張を聞いたのは初めてです。歴史的にJSXとES6は完全に独立して発明されました。最近になってBabelが両方同時に扱えるようになりましたし、Babelはまさにそういう拡張性を重視しているツールです。それは「ああ便利になったね」というだけの話であり、なぜ「ES6とJSXは混ぜるな危険」となるのかよく分かりません。現にこれが最も標準的で人気の組み合わせです。
「JSXを使うことへの抵抗」ということなら、とにかく見た目にコレがキモいと感じる人が非常に多いのは事実です。現に、JSXより見た目がキモくないことを売りにしている仮想DOM実装が一定の人気を博していたりします。でもそういうライブラリは「キモさ」軽減のために結局新たな構文やら独自コンパイラやらを編み出して柔軟性を犠牲にしています。JSXは「関数呼び出しのシンタックスシュガーをJavaScriptに1個導入するだけで問題を概ね解決する」というシンプルかつ一番表現力の高い解決方法だと思います。仮想DOMの思想に逆らわない最も素直なやり方であり、将来長持ちする気がしています。
とはいえ所詮JSXはシンタックスシュガーなので、使いたくないなら使わず、本来の関数スタイルで仮想DOMを書いてReactを使ってもいいです。タイプ量が増えて若干見づらくなるだけなんで。
それと、JSXじゃなくてテンプレートでいいじゃん的に思っているようですが、テンプレートは仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います。
Reactはもう登場して3年経過して未だに勢いが増していますし、日常で困らないレベルのコンポーネント集も揃っています。React-Bootstrapはいいぞ、心が豊かになる。そろそろ採用してもアーリーアダプターとも言えんでしょう。むしろ真に先端を見るのが好きな人に言わせりゃ、2015年なんて「Reactが淡々と成熟していくのを見ているだけの、つまらない年だった」みたいな感じらしいですし。
Reactは現時点で既に3年に1回レベルのビッグウェーブであることは疑いようがなく、「これが10年に1回、つまりjQuery以来のビッグウェーブなのかどうか」については、そう信じている人と懐疑的な人がいる、という状況です。私はAngularもCoffeeScriptも「3年に1回」レベルに感じたのでスルーしましたが、Reactには「10年に1回」の方になりうる素質を感じています（個人の感想です）。将来もっと凄いものが出るとしたって、それは「ベターjQuery」ではなくて「ベターReact」でしょう。通常は「3年に1回」レベルでも試したり仕事に使ったりして構わないと思いますが、10年に1回の技術でなければ使わない主義の方は、あと2～3年待てばよいと思います。
保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います。
元増田です。
SPAは、クライアントが自立した1プログラムとして状態を管理する。サーバはUIと同様の非同期なイベント発生源/イベント発行先の一つとして扱う。またReactとReduxの組は、データベースサーバとサーバサイドページ生成のスタイルを、サーバとブラウザでやるようにシフトさせたものともみなせるだろう。
手間がかかりません？さらにもともとほぼサーバー側だけで済んでいたものを分けることでCSRFやSQLiなどの変なバグを仕込む可能性だってありますよね。これに見合うメリットが見えないのですがいかがでしょうか。
そしてReact自体には、JSX構文もbabelもいらない。JSXタグを書くよりむしろReact.DOM.div({...},...)等で書いたほうがプログラミングでは扱いやすい。JSXはサーバサイドページ生成のテンプレート言語利用文化に寄せた表現に過ぎないといえる。そして今ではbabelで変換する対象もES6 modulesのexport/importだけだ。これも分割ファイル対応のためにwebpackあたりを使うなら、ついでにbabelでES6 modulesも、といった程度のこと。
というかですね、そもそもVをロジックの中にベタ書きしちゃうの嫌なんですよね。シンタックスハイライトとかインデントも効かないじゃないですか。そういう点ではAngularJSが一番気持ちいいですが。。
まあそれはそれとして、なるほど、JSXは別にどうでもいい、というのはわかりました。まぁそれならわからんでもないです。
すでに一般に忘れられつつあるprototype, Dojo, Mooと同格であるjQueryのほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーなものとしては残り続けるだろうが。
ここわかんないですね。活発なメンテがそんなに重要なのかな？ということです。まあモダンな感じで書きたいということは理解できますが、それさえクリアされていればいいんじゃないでしょうか。そうでもないですか？
twitterのツイートを増田に埋め込む方法を丁寧に書きます。
＊さっき一部の半角文字を増田で書けないと書きましたが数値文字参照にすれば書けました。訂正します！教えてくれた人あんがとー！でもスーパーpre記法ではこのやり方通用しなかったのでシンタックスカラーは無し。
twitter.comに行き ツイートの ... ボタンを押す。ツイートをサイトに埋め込むを押す。そうすると以下のHTML要素がコピー出来る。ここではサンプルにしても無害そうなifttt公式アカウントのツイートを引用します。
<blockquote class="twitter-tweet" lang="ja"><p lang="en" dir="ltr">Connect <a href="https://twitter.com/instagram">@Instagram</a> to <a href="https://twitter.com/Dropbox">@Dropbox</a> and automagically save every photo you post for safe keeping <a href="https://t.co/YVrgcSJZAD">https://t.co/YVrgcSJZAD</a> <a href="https://t.co/3vEiFZ3ADW">pic.twitter.com/3vEiFZ3ADW</a></p>— IFTTT (@IFTTT) <a href="https://twitter.com/IFTTT/status/662023324306837504">2015, 11月 4</a></blockquote> <script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
まあ増田を書く
先ほどのHTML要素のうち末尾のscript要素は引用する際,埋め込んだtwitter引用からはみ出て表示されるので邪魔です。取りましょう。
末尾のこれを取ります。
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
そうするとこうなります。これを増田にそのまま貼り付けてください。
<blockquote class="twitter-tweet" lang="ja"><p lang="en" dir="ltr">Connect <a href="https://twitter.com/instagram">@Instagram</a> to <a href="https://twitter.com/Dropbox">@Dropbox</a> and automagically save every photo you post for safe keeping <a href="https://t.co/YVrgcSJZAD">https://t.co/YVrgcSJZAD</a> <a href="https://t.co/3vEiFZ3ADW">pic.twitter.com/3vEiFZ3ADW</a></p>— IFTTT (@IFTTT) <a href="https://twitter.com/IFTTT/status/662023324306837504">2015, 11月 4</a></blockquote>
確認するボタンでツイートが埋め込まれてないのであれ？と思うかもしれませんがそのまま「この内容を登録する」を押してください。
増田のタイムラインでも埋め込みツイートは表示されずたんなる引用として表示されます。あれ？となるけど書いた増田記事の本文URLを開いてください。本文を表示した場合のみツイートが埋め込みで表示されます。
Connect @Instagram to @Dropbox and automagically save every photo you post for safe keeping https://t.co/YVrgcSJZAD pic.twitter.com/3vEiFZ3ADW— IFTTT (@IFTTT) 2015, 11月 4
応用すると以下のようにツイート内にインラインされている動画を増田にインライン出来るなど夢が広がりますね。あと増田はコードサンプルを書くにはクソですね。
気づいてない人も多そうですが、『マッドマックス 怒りのデス・ロード』の主役マックス役は 『ダークナイト ライジング』でベインを演じたトム・ハーディです https://t.co/cJ816F5Mpu https://t.co/Qh0iuQKFTl— アメコミ大全集（TM） (@amecomic) 2015, 12月 1
増田では表示できないはずのTwitterの呟きや巨大文字、色文字、シンタックスハイライト済みのコード、
これらが正しく表示される増田を書く増田が11人の中に紛れこんでいる。
彼らはどうやってそのような増田を書いているのだろうか。私は下記の可能性を疑っている。
配属されてからいろんな機能を追加してきた。中規模くらいのプログラムで、研究ではメインで使っている。
でもだんだんつらくなってきた。とにかく見づらい。
1980年代に作られたこのプログラムは今までの人たちのコメントの蓄積が半端ない。
プログラム書き換えでとりあえずとっておいたコードのコメント、書き換えた日時と人が書いてあるコメントがプログラム中に混在している。
これらは実際に動く部分のコードよりも多く、可読性をかなり下げている。
前者については、ほとんどが不要だと思うのだがあまり考えずに消すと将来困るかもしれないのでちゃんと確認して消したい。
そして未だに残るGOTO文とFORMAT文と文番号。implicit noneではない暗黙の型宣言。
Fortran入門: 知識として必要な過去のFortran このページに書いてあるほぼすべてが詰まってる。
COMMON文もほぼすべてのサブルーチンにあったが、これはなんとかmoduleに書き換えた。
moduleに書き換えたとはいえ、本来は引数で渡したほうが適切なものも機械的にCOMMON文からmodule文に書き換えたためその辺も見直したい。
一番面倒なのが一行の文字数制限。何段かのインデントを入れるとすぐにアウト。
エディタ使ってると自動でインデント入れてくれるのでいちいち直すのも面倒だし、インデント好きなのでできればインデント入れたい。
エディタといえばシンタックスハイライトもfortran77モードだとうまく表示できないことが多い。
allocatableとかmodule文なんかは厳密に言えばfortran90以降の機能だけどコンパイラが対応してくれているおかげで使える。
でもエディタのシンタックスハイライトにはそういうコンパイラが気を利かせたような実装は含めないのでうまく表示されない。
fortran90モードを使うと今度は行頭カラムの空白が守られなかったりしてコンパイルエラー。
すっげー書き換えたい。全部きれいにしたい。他言語にするとあまりにも変わりすぎて教授が混乱するからせめてFortran90にしたい。
でもさ、よく考えるとこの書き換えって全く自分の実績にならないんだよね。
そもそも今までプログラム改良して出来る計算の幅をだいぶ広げたけど、それ自体は発表できないからほぼ表に出ない。
計算結果を出してそれを発表しないと表面的にはまったく意味が無い。
ましてやプログラムの保守作業であるこの書き換えは計算結果に影響をおよぼすものでもないから研究成果にはまったく現れない。
しかもプログラム書き換えた自分だけじゃなく、みんなも使うから書き換えた自分が特別得するわけでもない。
プログラムすべてのコードを書き換えるのは単純に機械的にやっても結構時間がかかるし、書き換えても一発では絶対にうまく動かないから修正にも時間がかかる。
研究者の中にはそういうプログラム書いてばかりの人間を馬鹿にする人もいる。プログラムを書いてる研究者は自分の分野ではかなりヒエラルキーは低い。
情報系でもないんだし、それが研究の本筋じゃないからというのはわかる。自分たちのやるべきことじゃない。（でも専門性の高い道具を作り、整備する技術・人も必要なんじゃないかなと思ったりもする。）
やってもあまり得しないし他のことやったほうが絶対に自分の将来を助けるけど、ほっとくのもなんだかなあと悶々としている。
多分きれい好きの人が自分の部屋を見たら同じ苦悩を抱えると思う。