自分は競技プログラミングというものにそれなりに長くかかわっているのですが、取り組むなかでいろいろな言語を利用してきました。覚えている範囲だとこのあたり。
- Ruby
- プログラミングを始めたきっかけの言語で、しかもプログラミング始めたてのころにCodeIQという競プロちっくなコンテンツに出会っているため、結構長い間Rubyで問題を解いていました。アプリケーションを作る分にはとても良い言語だと思いますが、競プロだとちょっと厳しいかなーとは思います。
- C++
- Python3
- Go
- もともと関心があった & スクリプト言語感覚で使える高速な言語を探した結果がこれ。結論から言うと、競プロ向きでは全くありません。データ構造はおろか、簡単なアルゴリズム (例: min, max程度のもの)すら標準で用意されていないため、オリジナルライブラリの準備は必須です。また同好の士がすくないので、解答例を探すのが結構大変。使わなくなったきっかけはCodeforcesを始めたこと。Codeforcesだと、32bit版でコンパイルされるため、ほかのサービスと書きっぷりに注意する必要があり、それが面倒になったんですよね
これは比較的長く使っていたものであって、短期間であればPerlやScheme、JavaScriptやAWKなど、様々な言語を利用してきました。自分にとってベストマッチなプログラミング言語があるのではないかという迷いの果てに、いろいろな言語をかじってきたわけですが、ここ最近はというと、まさかのJava。
個人的にはJavaはC++についで競技プログラミングに向いている言語だと思います。まずかなり高速であるということ。RubyやPythonでは厳しいアルゴリズムでも、JavaではACするなんてざら。JVMで動くので、32bitとか62bitとかを考える必要なし。C++ほどではないですが、データ構造も標準でかなり用意されています。個人的には、赤黒木(TreeMap、TreeSet)が標準で用意されているのがたいへんうれしい。赤黒木は使い勝手がいいわりに、自作ライブラリとなると、実装が面倒なんですよねー。
Javaは気を付けないと、パフォーマンスが極端に悪くなりがちなのですが、そういう言語特有のトラップがあるのはJavaに限ったことではないですよね。C++やGoがいかに高速だからといって、その言語らしからぬ無茶苦茶な実装をしたら、その言語のもっているパフォーマンスがでないのは当たり前です。Javaも同じ話なのですが、Javaは利用者が多いということで、そういう当たり前の話が通じなかったりするわけです(´・ω・｀)
自分はSIer勤めのシステムエンジニアで、オープン系のサーバサイドを専門としており、JavaでWebシステムなんかを作ることが多いです。要は仕事でJavaを書いているわけで、であればプライベートや趣味ではJava以外を使いたいなーなんて考えていたわけですが、結局Javaに戻ってきてしまう。Javaができのいい言語というのが悪いんや (逆ぎれ)
オンとオフでプログラミング言語の切り替えは続けていこうかしらん--いや、ここ数か月は仕事でコード書いていないな…。ほんの2-3か月前に上流工程中心のプロジェクトにぶち込まれて以来、仕事ではExcel & Excel & Excel。こんな資料を作って誰が見るのか、わからん資料を毎日夜遅くまで作っております( ﾉД`)ｼｸｼｸ… トラブルプロジェクトにアサインされることが多く、コードを書くといっても、いわゆるクソコードと戦うことがほとんど。スパゲッティなコードと格闘するぐらいなら、Excel職人のほうがよっぽどましに違いないと思ったのですが、わけわからん資料を機械のように量産する毎日を送っていると、Fuckin'なソースコードに文句言っていたあの頃がまるで黄金時代だったかのように思えてきます。自分はまだまだプログラマでいたいでしょうね。生涯プログラマ宣言なんてのはおこがましいですが、まああと数年ぐらいは開発現場でもまれていたいものです。
そんな風に思うのも今のプロジェクトがしんどいからでしょう。納期やスコープのわりに工数が足りなさすぎる。大規模プロジェクトなのにプロセスはおろか、プロセス定義すら決まっていない。プロマネ自ら、このプロジェクトは走りながら決めていくと宣言してしまう無軌道ぶり。ウォーターフォールとは何だったのか。
ちなみにこのコロナ全盛のご時世に全員出勤だぜ。一応、事情がある人は在宅でよいということになっているので、「こういう事情があるので、今日は在宅勤務です」なんていうと、偉い人から「それはこうすれば回避できるから出勤してね」なんて返ってくる。事実上の強制出勤ですな。なお、わたしのチームのリーダはなんのかんの理由を付けて、出勤してこない(´・ω・｀) それでリーダとのコミュニケーションが滞り、作業が遅れるといろいろ怒られるというね…。1時間かけて出勤して、だれとも一言も話さず、もくもくと資料を作り、お客さんやリーダと話すときはテレコン。そして夜遅くに解放されて、1時間かけておうちに帰ると。なにやってんだか。
聞いた話によると、自分のいるExcelいじりチームはまだ楽で、本当の地獄は先行開発をやっている部隊だとか。ここはもう何人も倒れていて、失踪した人間まで出たらしい。やべえ。プロジェクトで採用しているアーキテクチャが超独特、世界にも類をみないようないかれた構成で、しかもそれを実現するために、あまりなじみのない製品群を多数投入していることから、開発が難航。しかもアーキテクチャのことをあまり理解せずに設計書などを書いていたことから、要件が実現できないなんてことがざらに発生。実は「あまりなじみのない製品群」は先行開発をやっているチームの自社製品ということもあり、製品のせいにはできない。デスマーチして乗り切るしかないのだが、体力の限界というものもあるわけで、先行開発者の皆様に対しては、ご愁傷さまですとしかいいようがないですね (ひとごと)
「自社製品を使った基盤のうえで、その会社の人間が動くものを作れていない」という現状で、顧客も自社の人間もこれをだれもやばいと思っていないのが本当にやばい。今苦労している分のノウハウを生かせればいいでしょ、なんて軽く考えているのかもしれませんが、自分のシステムエンジニア人生の中で、過去のノウハウが生かされた経験なんてほとんどないぞ。前の人間が苦労した分と同じだけ、後の人間も苦労するんや。なぜそれがアドバイザリープロジェクトマネージャーなんてたいそうな肩書を背負っている人間がわからんのだ。自社がもうかって、自分の手柄になれば、どんなトラブルプロジェクトでもいいのか? 顧客もハッピー、開発者もハッピー、それを目指すのがプロジェクトマネージャの仕事では? 自分の手柄や論功行賞ばかりを追い求める愚かさよ。
まあプロマネや上位陣にとって、開発者は使い捨ての鉄砲玉にすぎんのでしょうね。事実、大手のベンダであれば、一声かければ、数千数万の人買いSESが集まってきて、どこからともなくシステムエンジニアどもをかき集めてくるわけです。それを見ていると、確かに開発者なんぞ、使い捨てで結構なんて思えてくる。しかし鉄砲玉を大事にしないと、意外なところで足元をすくわれるというのも世の常。いくら銭や金があっても、鉄砲玉がいなければ抗争はできないわけです。一兵卒を大切にしない組織は遅かれ早かれ滅びの道を突き進むのみ。わがプロジェクトのマネジメント層、あるいは関係者の皆様、そういうわけで、もうちょっと鉄砲玉 a.k.a. 下っ端システムエンジニアを大事にしても罰は当たらんかなと思うのですが、いかがでしょうか?
