  |
はてなキーワード: COBOLとは
このプログラミング言語はMtGだと多分この色の組み合わせだろう。
みたいなのをまとめたら次のようになった(TIOBEのランキング順トップ50)。
後半は知らない言語もあって怪しいが、おおよそこのようになると思われる。
※改めて見てみると何箇所か違和感があったので最初の版からちょっとだけ修正した。
| 順位 | プログラミング言語 | 色の組み合わせ | 内訳 |
|---|---|---|---|
| 1 | Java | アブザン | 白黒緑 |
| 2 | C | ゴルガリ | 黒緑 |
| 3 | Python | ティムール | 緑青赤 |
| 4 | C++ | ジャンド | 黒赤緑 |
| 5 | C# | バント | 緑白青 |
| 6 | Visual Basic .NET | セレズニア | 緑白 |
| 7 | JavaScript | ボロス | 赤白 |
| 8 | PHP | グルール | 赤緑 |
| 9 | SQL | 無色 | |
| 10 | Swift | 4C(緑欠色) | 白青黒赤 |
| 11 | Go | ゴルガリ | 黒緑 |
| 12 | Assembly language | 黒単 | 黒 |
| 13 | R | イゼット | 青赤 |
| 14 | D | グリクシス | 青黒赤 |
| 15 | Ruby | 赤単 | 赤 |
| 16 | MATLAB | イゼット | 青赤 |
| 17 | PL/SQL | 無色 | |
| 18 | Delphi/Object Pascal | アゾリウス | 白青 |
| 19 | Perl | ラクドス | 黒赤 |
| 20 | Objective-C | エスパー | 白青黒 |
| 21 | SAS | アゾリウス | 白青 |
| 22 | Visual Basic | 緑単 | 緑 |
| 23 | Dart | ジェスカイ | 青赤白 |
| 24 | Scratch | 白単 | 白 |
| 25 | Scala | 5C | 白青黒赤緑 |
| 26 | Groovy | ナヤ | 赤緑白 |
| 27 | Transact-SQL | 無色 | |
| 28 | F# | アゾリウス | 白青 |
| 29 | Rust | マルドゥ | 赤白黒 |
| 30 | COBOL | オルゾフ | 白黒 |
| 31 | ABAP | アゾリウス | 白青 |
| 32 | Lisp | シミック | 緑青 |
| 33 | Kotlin | 4C(緑欠色) | 白青黒赤 |
| 34 | Logo | 白単 | 白 |
| 35 | RPG | ディミーア | 青黒 |
| 36 | Lua | 緑単 | 緑 |
| 37 | Fortran | スゥルタイ | 黒緑青 |
| 38 | PowerShell | ジェスカイ | 青赤白 |
| 39 | Ada | ディミーア | 青黒 |
| 40 | LabVIEW | ディミーア | 青黒 |
| 41 | Erlang | 緑単 | 緑 |
| 42 | Julia | イゼット | 青赤 |
| 43 | ML | 青単 | 青 |
| 44 | Scheme | シミック | 緑青 |
| 45 | Haskell | エスパー | 白青黒 |
| 46 | TypeScript | ジェスカイ | 青赤白 |
| 47 | OpenEdge ABL | アゾリウス | 白青 |
| 48 | LiveCode | アゾリウス | 白青 |
| 49 | PostScript | 無色 | |
| 50 | ActionScript | ジェスカイ | 青赤白 |
見返してみるとおおよそ次のルールに従って決めているような気がした。
緑の判定があやふやな気が若干しないでもない…
| 色 | イメージ |
|---|---|
| 白 | 高レイヤ、初心者向け |
| 青 | 浮世離れ、ベンダー |
| 黒 | 低レイヤ、黒魔術 |
| 赤 | 速い、先進的 |
| 緑 | 基盤、グルー |
| 無色 | 道具 |
この記事読んでへぇーって思ってる人、はあちゅう腐す権利ないからね。
え、はあちゅうはニセ医療で、これはタイの最先端医療じゃん。全然違うだろ？
はい、そうじゃないんですよ。
医学的知識と医学的判断能力がない人が書いた医療記事はどちらも同じなんです。
仮に、はあちゅうがこの記事書いたら、みんな「へぇ〜タイ行こうかな？」って思った？
この記事の間違いは大量にあるけど、はてなにわかりやすく言えば、
めちゃくちゃ良いプログラミング教室見つけた！っていう「増田プログラミング教室」の紹介記事が以下の感じだとどうでしょうか？
最先端JAVASCRIPTを用いた画期的なホームページの作り方を教える教室です（JAVASCRIPTは世界の30億のデバイスで走る言語です）
また、最近流行りのAIの土台である機会学習を、MNISTというデータを使って、勉強できるんです。
これは、AIに知能があり、自動的に猫とおばあさん細胞が発見できるというので、
ぜひこの増田プログラミング教室で、プログラムを習いましょう。
ね、頭痛くなる記事でしょ？上記の記事のレベルはこんなもんよ。
キーワードとして、「根管治療」（英語名：Root Canal Treatment、以下“RCT”と表記）
「ラバーダム」、「マイクロスコープ」などを散りばめているだけで、上記の文章と同レベルの知識だから。
まず、日本の保険適用の根っこの治療なんて、毎回200円くらいにしかならないから数千円なんて絶対に適当。
なぜ日本の保険治療のことも理解していない人が、タイの治療については正しい記述ができると思えるのか不明。
それは国がCOBOL縛りでプログラミング書けって縛ってくるのに、
患者がグーグルマップみたいなサービス作りたいって言ってきて、
なんでも言語が使える自費診療すすめても、いや、保険きくから、COBOLでお願いします。って言ってくるからだろうが！
せめて日本の学会関係者にでも取材して、なんでこういう状況になってるのかくらい聞けよ。
そもそも日本は歴史的に総合医（ジェネラリストのまち医者）を増やすという医療政策をとってきたわけよ。
それは個人の資質うんぬんじゃないの。出羽守がすぐにアメリカでは〜っていうけど、アメリカの歯医者、全員医者だからね。
医学部卒業して、そのあとで歯の勉強した人たちでエリート中のエリート。1日に3人患者みたら、生活できるから。
15分おきに患者きて、インカムつけて仕事してる銀座の歯医者なんかと比べちゃダメよ。
日本は国民が歯医者に通いやすいように、歯学部というものをつくった経緯があるのよ。
最近は新専門医制度をつくって、分化していこうという話もあるけど、
患者側の意識が変わらないとなんでも屋を求めるから日本だとミスマッチしそうね。いろいろ面白いので調べてみてください。
あと、やぶが多いという話。うん、多いね。
じゃあ、どこの歯医者いけばいいのか？
まず、クライアントであるあなたが自分の歯をどうしたいのか、知識をつけること、
その症状に対して、得意な専門医がどこにいるのか調べること（歯学系学会で調べられる）
ここらへんでやぶはだいぶ弾ける。
え、めんどくさい？それなら、増田プログラミング教室行きですので、どうぞ。
クライアントが要件定義する能力もないのに、SIerの能力判断なんかできるかよっ！
（一気飲みを奨励するものではありません。お酒は20歳になってから）
パーアル パール パール フワフワ パーアル パール スクリプト
コーボル コボル コーボル フワフワ コーボル コボル コーボル 構造化
ルービイ ルビー ルービイ フワフワ ルービイ ルビー オンレイルズ
リースプ リスプ リースプ フワフワ リースプ リスプ 丸カッコ
スーカラ スカラ スーカラ フワフワ スーカラ スカラ 暗黙の
エースキュ エスキュ エースキュ エルエル エースキュ エスキュ 行ロック
ラースト ラスト ラースト フワフワ ラースト ラスト 所有権
ジャーバス ジャバス ジャーバス クリプト ジャーバス ジャバス webpack
（最初に戻る）
何かの参考とかにしたらダメです。書き始めて半年経つんだけどこっからどう直したらいいんだか（何をゴールにしたらいいのか）わからない。。
追記：合流性とか強正規化可能性とか停止性とか、全部チューリング不完全で、事前の静的解析で使うメモリの最大量が確定できる、とかそういう風に読み替えられる人を増やしたいのです、数式の添え字とΣと∫にびびらない人を増やしたいようなもので
数理論理学の一分野である証明論から成長した、数理論理学と理論計算機科学の境界領域の研究領域である型理論(type theory)は、大規模なプログラムの内的な整合性のチェックを行うための方法論を必要とする情報処理技術の分野で関心を集めている。
そもそも「型」(type)とは何か。プログラミング言語は一般的にはレコードや関数といったプログラムを構成する「値」(value)の定義をする道具である(*1)。その言語のコンパイラ作成者はこれらレコードや関数などの値、もしくは第一級の対象(first-class object)の種類を区別する型システム(type system)を必要とする。抽象代数学の観点からすると、「型」とはこれらの値もしくは第一級の対象が属する高階の対象(higher order object)としての空間(space)ないし代数系(algebraic system)で、型システムはそれら「型」とそれら相互の関係(relation)つまり型のなす順序構造(order structure)ないし束構造(lattice structrure)であるといえる。
プログラムを構成する値すべてに型が付くためには、曖昧でない(*2)こと、自己矛盾していないこと、悪循環を含まないこと、それぞれの値の内容をチェックするために無限の時間を要しない(*3)ことなどが必要で、これらを満たすなら、プログラムは有限時間で実行を終え、停止する。手続き型言語では無限ループ、型無しラムダ計算では無限再帰によって型付け不能なプログラムを書くことができるが、型理論はこれらのチューリング完全な計算機を意図しない停止しないプログラムから守る装甲でもあり、再帰やメモリ確保で好き勝手をさせないための拘束具でもある。型が付くプログラムには単に停止するというだけでなく、可能な実行経路（訂正：経路→方法）のすべてで同じ結果を出すなど種々の良い性質がある。
1)この定義は現実に使われているプログラミング言語の特徴を覆い切れていない、狭い不満足な定義だが本稿では都合上この定義に立脚して限定的に議論する。例えば変数(variable)というものを持つプログラミング言語もあり広く使われているが、これについてはレコードや関数と同じように性質の良いものとして扱うことが難しい。難しさの原因は次の注の内容と関連する。近年は変数を扱うかわりに値の不変のコピー(immutable copy)やその参照に名前を付ける機能を持つプログラミング言語が増えている。
2) 現実の情報システムでは、COBOL言語のレコード再定義やC言語の共用体、一般的な関数ポインタやVisual Basic言語のvariant型変数のように、同一領域に異なる型の値が共存する共用型(union type)の値がしばしば必要となる。共用型の値はgoto文を排除した構造化／オブジェクト指向プログラミングにおいて条件キャストやクラス分岐などによる実行経路の複雑さの主要な原因になるが、これは和型(sum type)すなわち相異なる型の非交和(disjoint sum)として定義することで曖昧さなく定義できる。
3) ゲームプログラムやネットワークサービスにおいてしばしばみられるように、入力として無限リストや任意に深い木のようなものを想定する場合には明らかに（条件を満たさない限り）停止しないことが正しい動作となり、この場合は最外周のループを（←どうする？）メモリリークを起こさないなど別の考慮が必要となる。
この件⇒ https://togetter.com/li/1452558
ユニケージはbashのパイプで作られた、RDBMSを使わずテキストファイルによる空白区切り行志向レコードへのデータ処理（だいたいプログラム1本の処理内容がメインフレームのCOBOLのそれと同じくSQLクエリ1個に相当する）で、同形式によるマスタとトランザクションファイル（RDBMS内部のredoログに相当）を使う（データに含まれる空白文字0x20はアンダーバー0x5Fに置換する、アンダーバーが複数存在するデータの場合どう扱うかは知らない）
開発と更新は早いんだけど参照が（テキストファイルなので）インデクスが効かないためシャーディングするしかなく、要するに検索機能の柔軟性がなく、リアルタイム性を損なう
おそらく基幹系というか在庫管理をユニケージでやっているので、ウェブサイト自体はユニケージで実装されていないかもしれないけど、しかし根幹に上記のような手作りのデータベース実装があるし、RDBMSに移行するとなると全部を止めてマスタとトランザクションファイルをマージしてインポートすることになる
追記：トランザクションファイルのマスタへのマージは営業時間後の日次バッチとかでやるはず
システムを止めている間も店舗が運営を続けているなら、たとえば店頭在庫を潤沢に積んだうえで、店舗間での在庫の融通は禁止し、店頭での売り上げ分はどこかでRDBMSに計上しなければならない
追記：テキストファイルに対するインデクスをつくって行頭へのシークの高速化をすること自体はもちろん一般的には可能だけど、ユニケージの方法論だとそれをする標準的な方法はないはず。ユニケージはRDBでもNoSQLでもなく、バイト位置でのシークという操作自体がない世界なので。sedとかで行の差し替えをした場合（SQLのUPDATE相当）当然行頭のバイト位置が変更した行以降ですべてずれてしまう可能性があるのでインデクスの更新がひどく非効率になる
追記：文章下手ですみません。ユニケージの良いところはRDBMSの実装の基礎を理解できるところ（これはDate先生の教科書を読んだりOracle Silverの勉強をしたりSQLの書き方を工夫したりクエリプランを読んだりするよりずっと効率的に学べる、ただしファイル編成法の知識はちゃんとした教科書で補う必要がある）、アプリケーション実装技術について横断的な理解ができるところだと思います（USP研究所のシェルスクリプトマガジンには実際勉強になりそうな記事が多い）自分はユニケージへの移行案件を生き残れなかったクチなので。。
追記：Tsukubaiは好きになれませんでした。
エンジニア職に就いたあと辞めたポエム の者です。業務終わりにみたら伸びてたので補足がてら。ぼくのいる雪山はまだそんなに積もってないんで16時くらいに閉めるんですよね。空気も美味いよ。暖冬最高。「週休2日しかもフレックス」なんて無いけどな。
はじめて書いた増田で、こういう形で二の句を継ぐなんてダサすぎる気がしますが、少しでも注目を得られたのが意外だったので。きもちは残して晒したい派です（なら実名でやれ）。
ここから先はフィクションです。遠い昔、遥か彼方の銀河系の、たまたま地球に似た惑星の、たまたま日本に似た列島の、とある僻地の物語。
もともとフォークやユニック乗ったりしてた人が途中からエンジニアを志してたらこんなヘソの曲がった駄文ではなく、もっと真摯な文章になってたと思います。自分の場合は逆で、バイトのためにフォーク免許取っただけなので、べつに工場勤務はバックグラウンドではないかなぁと思ってます。あと、1~2年で書ける才能があればよかったのですが、阿呆なので3~4年くらいやってこのレベルです。電工二種は落ちました。あれ受かるの天才じゃない？
ほかの多くのひとも言及してますが、マジでどこにでもある話だと思います。ただ、どこにでもあるはずだしタブーでもないのになぜかあんまり表立って見かけないのでぶん投げました。個人的には「どこにでもある話」と言ってる人にどうやってサバイブしているのか教えて欲しいところです。自分は妥協以前に病んだので駄目でした。
あとこれもよく言及してますが、今読み返したらフェイク1.5割くらい、本質に関係なさそうなのを含めると3割くらいな感じです。経緯っつーか言い訳としては、最初個人ブログに投げるつもりだったのでフォーカスずらしてうっすらとブラーかけてたんですが、客観的にみたときにdisだけで終わりそうになってしまったため、増田にアップしようとしてどうせならと加筆しまくったら文字数制限にひっかかってしまい、最終的にざっくりと削ったり言い換えたりしたのも影響してます。ところどころ日本語がおかしくなっとる（のに頑なに好きなvtuberの箇所は消さないスタイル）。
言葉っつーか界隈で使われがちな単語とかは、この程度ならQiita読んだりTech系ポッドキャスト聞いてると刷り込まれると思います。と、ほぼ未経験元SEが言ってみる。
本文中には敢えて書いてませんが、MTG時に議事録録る役を充てられている人がいました。その人が不在のときに自分に役が回ってきて、書き方はこれまでのやつを参考に、と言われたのでやったことが数回ありました。というか正しい議事録の録り方ってどっかで習えたりするもんなんでしょうか。いいなぁ。
これは指摘されて書き方が間違っていたと気づきました。もともとあったシステム部門を切り出したわけではなく、正確には新しく受注するシステムみたいなのを専門にやるために作った、というのが正しいと思います。うーん、そういわれれば本来そういう部門があったかどうかも怪しいです。どうしてたんだろう。
ほかの方も地域差について言及してますね。べつに場所にこだわりはない（ただし都市圏を除く）ので住むのはどこでもいいんですが、スキルに関してはたぶん過大評価です。ほかの方も能力について言及しているのを見かけますが自分のスキルセットは大したことないと思ってます（といってそもそも実務経験がこれだけなので棚卸しもなにもない）。今回は客観的に技術力を評価してもらいたいというのが主目的で入社したのですが、ご覧の通り結局叶いませんでした。せめて研修くらいあって、テックリード的な役割をしている人がいれば最高なんですが、逆にいうと地方でそんなのほとんどねぇよな〜という印象です。なんのためのインターネット・テクノロジーやねん。
本文にも書きましたが賃金はわりとどうでもよくて、「300万出す」と言われたら「180万でいいんで週休4日にしてくれませんか」てな感じで自分の時間を優先するタイプかもしれません。帰属意識や社会的責任が云々ではなく、単に貧乏性なんだと思います。
外国人たくさんいそうで英語使う機会ありそうだし面白そうだったんで白馬いきたかったです。。。
マジで行きたいですね。べつに場所にこだわりはない（ただし都市圏を除く）ので。バイト期間中にそこらへんの会社のリサーチをしてみます。札幌/仙台/金沢/岡山/福岡以外にどっかありますかね？海外でも火星でもいいけど。
ずっと相互のコミュニケーションが不足してるなぁという思いはありましたし、そこが問題だと思ってました。でもどうすりゃいいか結局わからなかったですね。本文に書いた「ポエム褒め褒め大会」や「全社清掃」も実はレガシーな形での相互理解の場のつもりだったのかもしれません。なんつぅか、互いに童貞・処女みたいな感じでした。童貞に雰囲気なんて作れるわけないよね。。。
自分も大好きで事あるごとに読み返してます。彼のような超天才タイプとは程遠いですが。お気づきのように冒頭の "ここから先はフィクションです" はリスペクトです。
ぼくのはなしは、これでほんとにおしまい。
退職者アドベントカレンダー2019はまだはじまったばかりです。楽しみですね。
深夜のパソ通で寝不足なのをマシン室に行ってるふりしてトイレで寝てるとか
アルゴリズム考えてるふりしてエロい絵が見えるパズルを短い手順でクリアするパターンを考えてるとか
同期の女子にJCLのわからない所教えてあげて必ずお礼するとか言われてもそれは絶対にないと思ってるとか
FさんやクライアントのSEが能力認めてくれてたから良かったけど
付き合いきれんかったわ
FのSEさんも欲求不満でマシン室でストレス解消にストックフォームの詰まった段ボール箱に
指で穴を開ける遊びをしていてそれも習得
力よりもインパクトの瞬間に手首のスナップで最速を出すのがコツ
やっぱり2年で学ぶことは無くなったな
