この二つの言語、正直、乖離しすぎていて、Java屋な自分にとってはC言語は脅威です。
脅威というのは、さわるのが怖いという意味です。
JavaとCの棲み分けというのはある程度できていると考えていて、プログラムとしての効率を求めるならC、開発の効率を求めるならJavaとなるんじゃないかと思っています。
Javaでの開発は基本的にフレームワークありきとなると思っています。
WebプログラミングするならServletにStrutsのっけるとか、DB使うならHibernate使うなりEJB使うなりしてO/Rマッピングしたり（もちろんJDBCでのコーディングを行うことも多いでしょうけど）、トランザクションの管理もEJBコンテナに任せたり、まあ、そういった生産性をより向上させるような仕組みがいろいろな分野で考えられています。
AOPなんて今のところ使いどころがいまいちわかっていませんけど、そのうち当たり前になるかもしれません。
DI（依存性注入）はなかなか面白い考え方で、正しく設計されればテスト工程の工数を大幅に削減できるでしょう。
そのあたり、Cだとどうなのか全く知りません。
で、全然話がそれまくってるので、元々の所に帰ります。
当たり前なんですが、言語指向が異なりまくりなんですよね。
Cはかなり原始的な言語で、メモリを意識したりしながらコーディングします。
JavaでCのように生々しくメモリを意識することはありません。（文字列の結合にString+StringをせずにStringBufferを用いるとかってのとは全然次元の違う話です）
構造化言語とオブジェクト指向の根本的な違いよりも、そうした、「生々しさ」の方が自分にとっては脅威です。
構造化言語は、オブジェクト指向に慣れ親しむと、その設計思想からもうかなりつらいんですが、まあ、ソースを読むことはできます。
オブジェクト指向でも、ソースの一部だけを切り抜けば、構造化言語と同じですから。
が、メモリ周りのアロケーションを自分で行うなんてことは、Javaではありえません。
オブジェクトをnewしてインスタンスを作ったら、その時点でVMが自動的にメモりアロケーションや、必要な場合はリアロケーションなんかもやるし、GCでゴミインスタンスを消してメモリを解放したりしますが、Cはそういう仕事は全部自分でやらなければなりません。（たぶん）
もうね。
こえー。（ﾉ∀`）
配列のサイズを超えた操作を簡単にできちゃったり、ポインタの値をいじくれちゃったりもう怖すぎです。
使いこなせば効率的なソースを書くことができるわけですが、変なのがさわると速攻バグの温床です。
nullの概念とかtrue, falseの概念とかもCとJavaでは違ったりして、Cは結局0x00を基底とした考え方を持っていて、そこもまた生々しい。
最近プライベートでCをさわる機会が多いのですが、やはり自分はCを書くのには向いていないと思いました。
投稿者 邑波。 : 2006年02月22日 18:59