IntelliJ IDEAはGroovyの学習や開発に最適なIDEだった - 達人プログラマーを目指して
先日、業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指してで、Javaのイケていない部分について説明し、そこでGroovyやScalaといったいわゆる軽量言語（LL）を使うことでコードが単純化されるという説明をしました。私自身も勉強会や書籍などで「軽量言語は簡単ですよ」という説明をされるたびに、軽量言語に乗り換えてみたいなという気になるのですが、いざ試してみると圧倒的に高機能で安定しているJavaのIDEと比較して見劣りがしてしまい（特に入力補完とリファクタリング機能において）、結局Javaに戻ってしまうということが今までに何度かありました。 先日参加したGroovyの勉強会（JGGUGの勉強会（G*ワークショップ）に初めて参加してきました - 達人プログラマーを目指して）でJenkinsの川口さんがIntelliJを使ってGro
業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して
Java: The Good Partsの本のタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
