  |
はてなキーワード: Visual Basicとは
プログラマーって聞くと今の若い人は稼げる業種って思うかもしれない。でも昔は、そのイメージとはまるで真逆だったんだよ。
90年代初頭、日本はバブルの余韻が残ってたけど、IT業界なんてまだオタクの延長みたいに見られていた。NECのPC-9801シリーズがオフィスの定番で、OSはMS-DOS 3.3とか、その後にWindows 3.1が出ておお、マウスで操作できる！なんて騒がれていた時代だ。
もちろんインターネットなんて一般にはまだ普及してなかった。せいぜいパソコン通信。ニフティサーブ、PC-VAN、アスキーネット。回線速度は2400bps。ピーヒョロロっていうモデム音が夜中の住宅街に響いていた。
俺らはそういう環境でC言語やアセンブラを叩いてたんだ。コンパイルに時間がかかるから、トイレに行って戻ってきてもまだ終わってなかったりした。
今みたいにGitHubでコードを共有なんて夢のまた夢。ソースのやり取りはフロッピーディスクで手渡しだ。5インチのぺらぺらのやつな。運が悪いと磁気にやられて一発で飛ぶ。だから俺たちはよくフロッピー神社に参拝とか冗談言ってた。
正社員で手取り20万ちょっと。下請けやフリーランスだともっと安い。今でいうSESの走りみたいな人売りも普通にあった。客先常駐でCOBOLやらされてバグが出れば徹夜。オフィスに寝袋持ち込んで、カップヌードルと缶コーヒーの山を築く。徹夜明けに食う吉野家の牛丼が唯一のご褒美。今みたいにエンジニアは市場価値が高いなんて考え方はなかったからな。ただの駒だよ。
仕事は増えるのに単価は下がる。Windows 95の発売で世の中はインターネット元年なんて浮かれてたけど俺たちプログラマーの現実は泥臭いコード修正の山。Visual Basic 6.0やDelphiが出て「これで開発効率が上がるぞ」なんて言ってたが、結局は納期に追われるだけ。SunのJavaが登場したときも「Write once, run anywhere」なんて夢を見せてくれたけど、実際には動かないアプレットと格闘する日々。
Linuxが台頭してきたのもこの頃だ。
SlackwareやRed Hat Linux 5.2をCD-ROM雑誌付録で手に入れて、夜な夜なインストールに挑戦。LILOがうまく動かなくて起動しない、ネットワークカードを認識しない、X Windowが真っ黒。そんな壁に何度もぶつかっては2ちゃんねる（当時はまだ草の根BBSが多かったが）やUNIX USER誌を読み漁って解決する。それが楽しくて仕方なかった。でも金にはならなかった。オープンソースに貢献しても無償の善意で済まされるだけ。Red HatやMySQL ABが上場するまでは、ただのボランティア活動と見なされてた。
今思うと、あの頃は純粋だった。
技術そのものが楽しくて、ASCIIやOh!Xを小脇に抱えて徹夜でコードを書いた。秋葉原でジャンクパーツを漁って自作PCを組み立ててベンチマークの数字で一喜一憂した。
飯代を削ってもSCSIのハードディスクに投資したし、月刊アスキーの付録CD-ROMに入ってたシェアウェアを片っ端から試した。儲けようなんて意識はなかった。ただ、面白いものを作りたかった。
それが今じゃITは完全に拝金主義。コードの美しさより投資家の顔色を見てる。エンジニアもどこが年収高いかばかりで、言語やフレームワークを選ぶ基準が金になっちまった。Pythonが流行るのもAIブームに便乗してのことだし、ブロックチェーンやNFTなんかバブルがはじける前提のネタ探しにしか見えなかった。
もちろん、技術が商業化されて豊かになった面もある。AWSやGCPのおかげで誰でも世界規模のサービスを立ち上げられるようになったし、GitHubやDockerで開発環境も夢みたいに便利になった。だがその一方で楽しいからやるという純粋さはどこへ行ったんだろう。GitHubの草がどれだけ生えてるかが採用基準になる時代。Qiitaに記事を投稿するのも、技術共有じゃなくて転職市場でのポイント稼ぎ。
あの頃には確かに、金ではなく面白さに突き動かされる熱があった。それが今は金の匂いに上書きされてしまったように感じる。
でも稼げなくても、やる価値があった。
今の若いエンジニアたちにその気持ちがどれだけ伝わるかは分からない。
当時「Hello, world.」と表示されるだけのプログラムに、30年前の俺は心を震わせていた。
それは序盤の過密日程の影響とか、親会社の経営危機とか、地元有力者との関係性の話ではない。それらの影響が全くないとは言わないが枝葉だ。
マリノスは「アタッキングフットボール」というものをクラブのフィロソフィー（企業理念）に置いている。1年間のスローガンではなく永続的なものとして。
アタッキングフットボールとはざっくり言えばボールを常に持ちながらゴールに向かうスタイル（以下「ポゼッション型」とする）であり、2018年のアンジェ・ポステコグルー監督から始まった戦術でもある。
そして2019年と2022年にJ1リーグ優勝を果たし、2021年と2023年も2位と一時代を築いていた。
しかしサッカーのスタイルは数年スパンで栄枯盛衰を繰り返すものであり、本来それを企業理念に置いてはいけないものだ。
一般企業に例えたら「当社はガラケー向けサービスに特化」とか「当社はVisual Basicの技術者集団としてお客様に貢献」という、寿命が長くない技術的な要素を理念に置いてしまうのと同じだ。
そしてポゼッション型が栄枯盛衰の「枯・衰」側に明らかに傾いたここ1-2年で、見事にマリノスは壊滅している。
いくつかあるがこの3点が大きい。
・3人→5人交代制に変更/夏季飲水タイムの追加：いずれもコロナ禍の副産物。これにより個々の選手がより長い時間走れるようになり、ポゼッション型よりも「ボールを持っている相手を追い込む」サッカースタイルの方が有利になった。後者は2022年ワールドカップでドイツとスペインを撃破した日本代表が好例。
・主審のポジショニング変更：主審は「よりボールに近いところに位置取りをしなさい」というFIFA通達が2024年にあり、その結果主審のポジショニングがグラウンドのセンター付近から極力離れないようになったため、ポゼッション型のチームにとっては常に主審が邪魔になるようになった。カウンター型のチームはボールを持ったら主審を追い越すボールをさっさと前方に出すので、主審は邪魔にならない。つまりポゼッション型のチームとカウンター型のチームが対戦するというのは、11人vs12人で試合をするのに近しくなる。
特に後者の影響は大きく、2024年のJリーグではマリノス以外でも川崎フロンターレなどのポゼッション型のチームがことごとく低迷した。
そして川崎は2025年シーズンはポゼッション型の戦術を止めてカウンター型に切り替え、ACLでは決勝進出、Jリーグも昨年より上の順位に位置するなど健闘している。
一方でマリノスはポゼッション型の継続を選択したが全く勝てず、監督解任を経てカウンター型の戦術に切り替えて、首位の鹿島などに2連勝。これを続ければ残留は出来そうだと誰もが見ていたが・・・
「俺達はアタッキングフットボールをやりたいからマリノスに来たんだ！話が違う！サッカー変えるなら他所に移籍する！」と言い出す選手が多数出て来てしまい、このままではクラブ存続どころか翌月以降の試合開催が不可能になる可能性すらあったため、戦術をポゼッション型に戻したうえで6/19に今月2度目の監督解任の運びとなった。（こういう流れが起きていることは、直近1週間の各メディアからの報道で分かる）
まさに、サッカースタイルを企業理念に置いてしまっていたが故の事象である。川崎はサッカースタイルを企業理念に置いていないのでスタイル変革が出来たが、マリノスには困難なのである。
しかしその戦術は、上述の通り賞味期限切れである。天皇杯でJFL（4部相当）かつ中2日でコンディション万全ではないチームに0-2で負け、さらにその後の新潟との裏天王山でなすすべなく完敗という体たらく。
そして今日も岡山とホーム日産スタジアムでの試合だが、おそらく0-3か0-4くらいで負けるだろう。
そして、秋が深まる前に、J2降格が決まっているだろう。
それでも増田はマリノスの年間チケットホルダーでもあるので現地に行く。
「過去の成功体験に囚われ、変化への対応を拒否する、レガシーな人達の集まり」がどういう末路をたどるかという、今後の自分の社会人生活でも大いに参考になるであろう、生きた教材を見に・・・。
有益なことは書いてない。ただ現状を記した。
まだなにも就活してない、就活関連のゴミメールを消してたら1日が終わるだけ。
【事前情報】
・夏のインターン未参加
・働く意欲はわりとある
まだ詰んでるとは思ってないけれど、結構全部しんどい。完全に詰む前にどうにかしたい。
面接対策とかSPI、やったほうが良いことはたくさんあるんだろうけど、どれも手付かず。具体的になにから始めるべきか分からない。
わがままでしかないけどインターンには参加したくないし。働く意欲は結構あるのに、全部怖くてなにも就活してない。してる人はセミナーとかインターンとか参加してるっぽい。
薄々、気づいてはいたけどこんな大学じゃ高いGPA取っても就活にほぼ意味ないっぽい。学内推薦もあるにはあるが、弊学の立地的に東京の企業の推薦はまずないと思われる。実際のところ、給付型の奨学金欲しさに成績を取るのをいろいろ頑張っただけで、これと言って自信のある学問分野もべつにない。
漠然とシステム開発（SIer的なやつ、たぶん）に興味があるけれど、プログラミングの経験も特になし。授業でPython、Visual Basicに触れたことがある程度。システム開発に興味を持ったのも、単純に東京ならそういう会社が多いだろうと目を付けただけ。
あー、就活終わんねぇかな、なんにもしてないけど。
はてな匿名ダイアリーはじめて書いたから、いろいろおかしいとことあったらごめん。
今から25年前の1997年ののこと。当時小学生だった自分の1歳年上の従兄が、夏休みにお婆ちゃんの家にこのゲームを持ってきていたのが全ての始まりだった。
「タクティクスオウガっていうゲームがあるんだ。すげーから一緒にやろうぜ。」
従兄に勧められるままゲームを始めたのだが、タクティクスオウガが『すげー』ことはすぐに分かった。
中世ヨーロッパ風の権謀術数渦巻く世界観。重厚なBGMの中で敵味方がターン関係なく立体的なマップで繰り広げるリアルな戦闘。
背中に翼の生えたキャラクターが民家の屋根の上に移動して弓を射ると放物線上に矢が飛んでいくわ、ふわふわと宙に浮かぶ幽霊が魔法を唱え敵が炎に包まれると足元の草が焼けるわと細部までこだわったビジュアル。
とにかく衝撃的なゲームだった。いてもたってもいられなくなり、従兄がお婆ちゃんの家から帰った直後にお小遣いを握りしめて町のゲーム屋さんに走った。
お店のレジで商品を買うときにすごくドキドキしたのを今でも覚えている。スーパーファミコン版のタクティクスオウガの商品パッケージは英語でタイトルが書かれており、フォントが英語の旧字体みたいな形だったので、読み方があっているかな、間違って別のソフト買っちゃうんじゃないかなとすごく緊張したのだ。ぜんぜん自信が無かったが、店員さんにタイトル合ってるか確認して無事に買うことができた。
ワクワクしながら商品を持ち帰り、ゲームを始めたが小学生にとっては、難易度が高く難しいゲームだった。初回プレイ時にはキャラクターの強さを表すパラメータが多すぎてさっぱり分からなかった。
だけど作りこまれたチュートリアルとオンラインヘルプ等の親切な機能がたくさんついていたおかげで何とかゲームを進めることができた。一番助かったのは戦闘中の中断セーブ機能だ。小学生の時には、1日ゲームは30分までというルールがあったので非常に助かった。
さて、ゲームを買ってから2週間くらいの時のこと。難しいながらも俺はどうにかChapter1の終わりまでシナリオを進めていた。このゲームはプレーヤーが会話中の選択肢を選ぶことでシナリオが分岐するんだけど、途中で出てきた選択肢が衝撃的だったのは今でも忘れられない。ネタバレになるので詳細は伏せるが小学生には重たすぎる内容だった。無茶苦茶悩ましい選択だったが、片方を選んでゲームを先に進めてみた。だが、すぐにゲームに行き詰った。キャラクター育成をよくわからずに進めていたので自軍のユニットが弱く戦闘で勝てなくなったのだ。このまま先に進めないのも悔しかったので攻略本を買うことにした。
ここで話は少々脱線するのだが、俺の生まれ育ったのは日本海側の田舎町だ。町の本屋さんはあまり大きくない。なので、地元の本屋さんの攻略本コーナーにはメジャーな作品のものしか置いてないわけだ。ゼルダの伝説とか、ドラクエとかFFとかまあそれくらい。それらに比べるとタクティクスオウガはマイナーだった。苦労を重ねて隣町の古本屋さんで偶然攻略本を見つけて手に入れるまで1か月かかった。その後は攻略本を熟読してゲームシステムの理解を深めて1から再挑戦したのだが、家の方針で1日のゲーム時間が30分に制限されていたので、クリアするまでにはさらに2ヶ月ほどの時間を要した。だけどその分クリアしたときの達成感は大きかった。興奮冷めやらぬ俺は、小学校の同級生たちにタクティクスオウガのすごさを布教したが上手くいかなかった。俺がタクティクスオウガに出会った1997年当時、家庭用ゲーム機の主役はスーパーファミコンからプレイステーションに移行しつつあり、同級生たちはファイナルファンタジー7やファイナルファンタジータクティクスといったスクウェアの大作ゲームに夢中になっていたのだ。
同級生のN君に、「タクティクスオウガってファイナルファンタジータクティクスのパクリでしょ？」と言われたのは傷ついたなあ。なんていうか、自分がイケてると思ったゲームをディスられるという経験がなかったので。残念ながら、うちの地元では最初にタクティクスオウガを紹介してくれた従兄以外に周りでタクティクスオウガファンを見つけることができなかった。
それから2年後の1999年。俺は中学生になり、田舎町の我が家でもインターネットが使えるようになった。ネットが使えるようになってすぐに、以前はまっていたゲームのタクティクスオウガの攻略情報を調べてみた。地元の田舎町にはいなかったタクティクスオウガファンは、ネットの向こうにはたくさんいるようだった。ファンの集めた情報は膨大で、攻略情報にとどまらずゲームの舞台背景の考察やクリエイターの音楽の趣味までカバーしていて、中学生の俺の知的好奇心はガンガン刺激された。ディレクターの松野氏の名前もこの時に知った。余談だが、「タクティクスオウガとファイナルファンタジータクティクスは主要な開発スタッフが同じ」というのも同時期に知ったので、小学生の時にパクリ呼ばわりしてきたN君に対して「両方同じ人が作ってんだよ、適当言うなざまあ」という気持ちが芽生えたのはここだけの話である。
ネットの情報から刺激を受けた俺はゲームの世界観をもっと味わいたくなって、前作の「伝説のオウガバトル」もプレイしてみた。ディレクターの松野氏が好んでいたらしいQueenの楽曲を聞いてみたくなり、生まれてはじめて洋楽のCDを買いにも行った。コーヒーを飲めるようになった時のように、背伸びして少し大人になった気分がした。
そのうち自分でも似たゲームを作りたくなって、おこづかいでVisual Basicを購入したりもした。プログラミングの入門書片手にそれらしい画面までは作ったが、しょせんは中学生。体系だったプログラミング言語の知識がないためサンプルコードのコピペに終始し、1年くらいかかって紙芝居のようなものが出来て終わった。その後は、高校入試・大学入試で忙しくなったのでしばらくゲームから遠ざかっていた。
そこからさらに時が流れて俺は社会人になった。中学生の時のゲーム作りの経験から、ソフトウェアエンジニアの適性は無いなと思ったのでハード系のエンジニアとして就職した。タクティクスオウガから受けた影響は俺の人生を変えたのである。ゲームから遠ざかっていた俺だが、2010年にタクティクスオウガの1度目のリメイクのニュースを聞いて再び情報を集めだした。そこでたまたま開発者の松野氏のプロフィールを見つけたのだが、なかなかの衝撃だった。
まずはスーパーファミコン版のタクティクスオウガ開発時の年齢。発売日の時点で29歳なのである。ゲームの開発期間が2年くらいだとすると、開発開始時は27歳くらいだろうか。その若さであの革新的なゲームの開発指揮を執ってたのかよ！松野氏と面識のあるゲームクリエイターがインタビュー記事で天才という理由が分かった気がする。次に出身地。新潟県の妙高市となっている。地方出身であのゲームの重厚なシナリオを描くだけの知識を身に着けたのか！というのがもう一つの驚きだ。
先に俺の出身地が日本海側の田舎町だと書いた。地方で育ったからわかるのだが、地方はゲームの攻略本に限らずあらゆる情報が都会に比べて乏しい世界だ。タクティクスオウガの世界観を形成している中世ヨーロッパの歴史や文学の知識を松野氏はどこで得たのだろう？世代的にインターネットが無い時代なので、俺が田舎で育った時よりもさらに情報は手に入れにくいはずである。これは今でも気になっているので、今度出る予定のリメイク版の開発者インタビューでだれか聞いてみてほしいところである。
最後になったが、今回出る2回目のリメイク版もすごく楽しみにしている。なんていうか2回もリメイクが出るだけでもすごいのに、2回ともオリジナルの開発メンバーがかかわっているのがまた驚きなのだ。
発売元のスクウェア・エニックスはFF・ドラクエ等の過去の作品をよくリメイクしているけど、オリジナルのスタッフが何度もかかわるケースは珍しくないだろうか？しかも開発者の松野氏はリメイク前にスクウェアを退社しているのだ。それでも声がかかるのだから、本人のカリスマ性がメチャクチャ高いのだろう。過去に会社を辞めた人が2回も開発現場に呼ばれるって相当なことだと思うんよね。
VBA（Visual BASIC for Application）からプログラミングを始めて、「プログラミングとはこういうもの」という感覚を身につけてしまった人は、絶対に他のプログラミング言語の世界に入ってきてはならない。
一度VBAに慣れてしまうと、プログラマとしての正常なセンスを身につけることがほぼ不可能になるからだ。
これは、ヒトラーやポルポトや金日成などを良しとして政治に入門した人が、ふつうの政治の感覚を身に付けるよりも大変なことだ。
VBAでプログラミングに入門した人は、これからもVBAだけをやること。間違ってもプログラマになろうなどとは思わないこと。そして、プログラミングを知らない人にVBAを推薦したりしないこと。
以上。
エンジニア仲間どうしで年に何回か情報交換を兼ねて飲み会を開催していたのだが、今年はコロナウイルスのせいでZoom呑みに変更した。結果的に、これ以上この会意味あるんだろうかと思うようになってきたので吐き出しておく。
最初のうちは感染の拡大や緊急事態宣言による仕事への影響や、リモートワークの生産性の話をしたり、最近上中里にも店舗ができたらしいオメガラーメンの食レポめいた話題が出たりした（参加者にはラーメン好きが多い）。
雲行きが怪しくなってきたのは、いちばん年上の方のムラタさんが会話を独占し始めてからだ。Visual Basic一筋でもう20年以上やっているフリーランスで、いろいろな知識をシェアしてくれて悪い人ではないのだが、もともと朴訥というか突っかかるような話し方をする人で、酔っぱらうとそれに拍車がかかる。最近やっと住宅ローンを組んで町屋にマンションを買ったのだが、コロナのせいで案件が細ってきて、返済がやばいという話をして場を暗くしていた。
そこまではまだいいとしよう。問題は、ユウダイを絶対に許すなとムラタさんが強硬に主張し出してからだった。
ムラタさんによれば、ユウダイという名前の響きがまずよくない。ユウダイはキラキラネームに属するべきもので、一般に広く普及するべきではない。それなのに、平成の頃にユウダイと名付けられた男児が大きくなって社会のメインストリームに大量に出てくるようになって、テレビなどでもごく普通にユウダイを見かけるようになった。これは非常によくない、ジェネリックな名前なら太郎とか一郎にしておくべきであって、ユウダイは許されない、現状はコロナウイルスよりも危機的状況である。もとはといえば、ユウダイなどという響きの名前がかっこよいと思って名付ける、ゆるゆるの平成ママが悪いのだが（名付けるのは母親だけとは限らないと思うのだが、ムラタさんの頭の中ではユウダイは母親が名付けているらしい）、もはやどうしようもない。残された道は「日本全国のユウダイを許さない会」を結成し、ユウダイの社会侵食を防ぎ、いずれ根絶することである。
画面の向こうではムラタさんの目が据わってきて、ボサボサの髪を振り乱し、他の参加者に向かって、お前らも「日本全国のユウダイを許さない会」に加入しろ、おのれっユウダイ、許さんと叫んでいた（リアルでおのれとかいう人をはじめて見た）。若干コミュ障気味のムラタさんは最近祐大か雄大という名前の人事担当者に干されたのかもしれないが、ユウダイに対する深い怨恨の原因は結局不明である。この状況がしだいにだるくなってきたので、iPadの充電が切れそうだから寝ると言ってWindowsをシャットダウンしてから歯を磨いた。
このプログラミング言語は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 | ジェスカイ | 青赤白 |
見返してみるとおおよそ次のルールに従って決めているような気がした。
緑の判定があやふやな気が若干しないでもない…
| 色 | イメージ |
|---|---|
| 白 | 高レイヤ、初心者向け |
| 青 | 浮世離れ、ベンダー |
| 黒 | 低レイヤ、黒魔術 |
| 赤 | 速い、先進的 |
| 緑 | 基盤、グルー |
| 無色 | 道具 |
何かの参考とかにしたらダメです。書き始めて半年経つんだけどこっからどう直したらいいんだか（何をゴールにしたらいいのか）わからない。。
追記：合流性とか強正規化可能性とか停止性とか、全部チューリング不完全で、事前の静的解析で使うメモリの最大量が確定できる、とかそういう風に読み替えられる人を増やしたいのです、数式の添え字とΣと∫にびびらない人を増やしたいようなもので
数理論理学の一分野である証明論から成長した、数理論理学と理論計算機科学の境界領域の研究領域である型理論(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) ゲームプログラムやネットワークサービスにおいてしばしばみられるように、入力として無限リストや任意に深い木のようなものを想定する場合には明らかに（条件を満たさない限り）停止しないことが正しい動作となり、この場合は最外周のループを（←どうする？）メモリリークを起こさないなど別の考慮が必要となる。
外部ライブラリが果てしなくあり、
← それはPythonに限ったことじゃないでしょ。JavaでもRubyでもPerlでもCでも同様。主要言語はほぼそうでしょ。
それはむしろ逆。Python のスローガンは There's Only One Way To Do It で、これは Perl のスローガン There's more than one way to do it. を意識したもの。
https://wiki.python.org/moin/TOOWTDI
なお、個人的には C# は良さそうだなとは思うけど、Windows以外のプラットホームではどうなんでしょう。（よく知らない。） これは Visual Basic についても同様。
外部ライブラリが果てしなくあり、似たような機能を実現する方法が複数あるので、本によって書いてあることが違ったりする。
逆説的ではあるが、初心者は、Visual BasicやＣ＃あたりから入るのがいいような気がしてきた。
逆引きハンドブックのような本を片手に、チュートリアル本を手打ちでコードを動かしながら読了すると、Visual BasicやＣ＃の世界は一通り把握できる。わからないことは索引を見ればだいたい出ている。Visual BasicやＣ＃があんまり尊敬されてなくて、限界や不満もあることもだんだん理解できる。
Visual BasicやＣ＃でも相当なことができるし、そこからスマートな言語に移行すれば、比較対象となるものがあるので、守備範囲を自分のペースで広げていける。
その発言した増田ではないが、その発言は少し無責任な気がするので補足。
まずRはやめるべき。
逆に統計くらいでしか使わないので、貴方が算術処理をバリバリやるのでなければ使用するべきではないだろう。
Pythonも言語だが、Rに比べると汎用的であり、かつ機械学習（scikit-learn、NumPyやPandas等の統計ライブラリ主体だけど）などでも使われていてホットな言語である。
ホットな言語だと、書籍やネット情報が豊富にあるので、学ぶ分には困らないのでもしプログラミング言語をやりたいのであればPythonをお勧めする。
そして、Excelマクロも一応Visual Basic for ApplicationというVBを下敷きにした言語なので、その言語を今から学ぶのであればPythonを学べばいいのではないかというのが先の発言の趣旨ではないかと推察する。
しかしながら、言うまでもなく、Excelのセルに書かれたデータをあれこれしたい（主に業務で活用したい）という要件ならVBAが最適である。
プログラム言語って得意／不得意があるから、やりたいことに合わせて使う言語を変えたほうが幸せになれます。（本格的なプロジェクトだと選択の余地はなかったりするけど）
なお、おうちで触りたいというレベルなら私もPythonをお勧めします。
MacでもWindowsでも同じ書き方で、Excelに囚われず色々な処理ができる。AIやIoTなどで需要が高まっているので覚えておいて損はないし。
「これだけ凄いから導入許可をください」と情シスに掛け合えるレベルまで成長したら会社でも使えばいい。
ただ、対象者はちょっとしたプログラミング言語を覚えて、手間がかかることを自動処理とかしてみたいなぁと考えられる人。Excelが効率よく使えれば十分って考えの人にまでお勧めするものではないので、その辺は誤解がないように。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
好きに表記すればいいと思いつつも見ると内心もやもやしてしまう。
やっぱりJavaと表記してほしい。Java……かっこいいじゃん！
※ Javaだけだと馴染みのない人もいると思うので似たような例を挙げる。
× SKYPEアプリ ○ Skype × PHOTOSHOPソフト ○ Photoshop × YOUTUBEサービス ○ YouTube
大まかには次の二点だと思っている。
COBOL、LISP、ALGOL、FORTRAN、PL/I、APL、BASIC……
今はFORTRANも新しいFORTRANはFortranと名乗っているし、BASICもBASICの派生はVisual Basicなどと名乗っていたりする。
時代に逆行してJavaをJAVAと表記してしまうとJavaがあたかも古い言語であるかのような印象を与えることになる。
× JAVA ← 1960年代の言語ですか？ ○ Java ← 今時の言語っぽい！
「言語」という接尾辞をつけてしまうと二重敬語のようなまわりくどい印象を与えることになる。
Cのようにググラビリティが低いため止むを得ずC言語と表記するという場合もあるが、Javaならそういった問題は無い。
コンピュータ関係で他のJavaと衝突していないか？それは大丈夫だ。
https://ja.wikipedia.org/wiki/%e3%82%b8%e3%83%a3%e3%83%90
Scalaちゃんは今日も「余裕でした(´･_･`)ﾄﾞﾔｯ」とツイートするんだろうか。
