アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
「Beyond Java」 (スコア:3, 興味深い)
本ではJavaからどんな言語に変更すべきか、みたいな事も書いてあるそうです。
http://www.oreilly.com/catalog/beyondjava/
Re:「Beyond Java」 (スコア:3, 参考になる)
彼は軽快なJava [amazon.co.jp]で「SpringやHibernateなどの軽量フレームワークがJavaを変える！」なーんて言ってたわけです。ところが最近は「Javaで軽量な開発をやろうと思ったら、SpringやらHibernateやら、いろいろとおぼえなくちゃならなくて大変だよ [webservicessummit.com]」なんて言い出している。なんなの、この無責任な一貫性の無さは。
「利に聡い」人なんだろうなぁ、とは思います。
Re:「Beyond Java」 (スコア:4, すばらしい洞察)
いやぁ、あなたのコメントを読んでいるとむしろ
Tate 氏は一貫しているように見えるなぁ。
「軽量さ」を求める、ということでね。
もし言語として Java を使うことが避けられないのであれば
その中で軽量な手法を選ぶべきだし、
もしそもそも Java 以外の言語を選べるのであれば、
より軽量なものを選ぶのがよい、と。
＃該当の書籍を読んでないのであくまであなたの
＃コメントからの判断ね。
# mishimaは本田透先生を熱烈に応援しています
Re:「Beyond Java」 (スコア:0)
>> SpringやらHibernateやら、いろいろとおぼえなくちゃ
>> ならなくて大変だよ [webservicessummit.com]」
>もし言語として Java を使うことが避けられないのであれば
>その中で軽量な手法を選ぶべきだし、
>もしそもそも Java 以外の言語を選べるのであれば、
>より軽量なものを選ぶのがよい、と。
勘違いしているのかもしれないが、
「Spring」「Hibernate」はJavaで作られた
フレームワークであるから、言語云々の話ではない。
JavaのほかにJavaで動いているフレームワークの知識を
持たなければならないから大変だ、というのは真だと思うが
近年のソフト開発の要望は、それだけ複雑化しているともいえる。
どんどん要望は巨大に複雑になり、それに応えるべく
身につけるべき技術もどんどん増えている、という
事実をおきざりにして議論すべきではない。
Tate氏の考察は本質まで迫りきれていないように思える。
Re:「Beyond Java」 (スコア:1)
知っていたので
> その中で軽量な手法を選ぶべきだし、
と書きましたよ。
ついでにちょっと与太話。
> 近年のソフト開発の要望は、それだけ複雑化しているともいえる。
ここにはちょっと否定的。
というのは、「Java のような手続き型、マルチスレッド志向、
フレームワーク志向の言語では複雑にならざるを得ない」
だけのパターンが多いんじゃないかと思っている。
たとえば（本当にたとえばの話だよ？）、
重量級のサブシステムに対しては Facade パターンを
利用して丸ごと一個のコンポーネントにしてしまい、
普段操作することのないようなパラメータを隠蔽することで
複雑性を減らすべきだと思う。細かい操作が必要なら、
そういう状況でだけ Facade の内部にアクセスすればいい。
しかし、フレームワークを利用している場合には
（フレームワークという枠組みが大きすぎて）隠蔽が
難しい。だから複雑に感じる。
なんで Java にフレームワークが多いかといえば、
これは「なんでも Java で済ませよう、そうすれば
学習する言語は Java だけでいいんだから」という
考え方があるからだ（と俺は思ってる）。
この方針を用いれば、言語学習については容易になる。
でも…フレームワークを学習する煩雑さで結局は台無しだ。
もし、フレームワークでなくてコンポーネントならどうか？
コンポーネントにすることができれば、
Java の実行系も含めて隠蔽できる。そうなれば、
設定ファイルの文法だけを覚えればいいだけになる。
さらにもし、この設定ファイルが言語の形をとって
いたら…それって、軽量の言語を学習することと
何にも違わないんじゃないか？
そういう意味で Tate 氏はいい線いっていると思う
（氏の嗜好はメタプログラミング方面っぽいが）。
言語相対性 [hokusei.ac.jp]とかから類推して考えると、
あるプログラミング言語やパラダイムを思考の中心に
すえることで、かえって複雑になってしまう問題領域が
あるんじゃないかと推測できる。Java の難しさは
そういうところに来ているように思う。
問題領域に適した言語を選ぶべきであり、必要なら
別の言語を使うべきだと思うが、
一神教というか、一言語教とでもいえるものを、Java
関係のプロダクト（特に Tomcat とか）に感じるんだよな。
ちなみに、一言語教の否定という意味では、
データ格納に SQL を使うのはいい考えだと思う。
# mishimaは本田透先生を熱烈に応援しています
Re:「Beyond Java」 (スコア:0)
>> その中で軽量な手法を選ぶべきだし、
>と書きましたよ。
修飾関係が分かりにくかったので早とちりしたのか！？
>> 近年のソフト開発の要望は、それだけ複雑化しているともいえる。
>
>ここにはちょっと否定的。
>というのは、「Java のような手続き型、マルチスレッド志向、
>フレームワーク志向の言語では複雑にならざるを得ない」
>だけのパターンが多いんじゃないかと思っている。
Javaが手続き型でマルチスレッドをサポートしていることに
異論を挟む余地はないが、フ
Re:「Beyond Java」 (スコア:0)
>コンパクトな姿が保たれ、複雑化はしないのだろうが、
C++なんかでもフレームワークを作りたいのだけど、実際には
C++で他人の作ったフレームワークを再利用するのにかなりの
リスクが伴う。「自分で一から作り直した方が楽」とは言わない
けど、それでも再利用するより自前の方がまだ安心な気がする。
これに対して、Javaでは本当に再利用できるんですね。
だから様々なフレームワークが作られ、一部が広く普及し
業界標準となっていく。