アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
1980年に戻れるか? (スコア:1)
って開発環境と実行環境が一体化してたんじゃなかったで
しょうか。今回のEclipseは、あれ以上の環境になってるのか
な。
Re:1980年に戻れるか? (スコア:1)
開発環境を含む仮想計算機で開発と実行を
行うようになっています.
Squeakなどでは開発中断時の状態が
仮想計算機のイメージで保存されます.
Eclipseが仮想計算機として動作するようになれば,
それ以上
旅に出ます.(バグを)探さないで下さい.
Re:1980年に戻れるか? (スコア:2, 興味深い)
Smalltalk(Squeak)とは、位置付けというか用途が微妙に違うかも知れませんが、
EclipseもJVMというVM(^^;に乗って動いてるわけですよね。
違いはむしろ、Imageという巨大なファイル(素朴なOODBとも言える??)を使う方式かどうか、
という点でしょうね。
あんまり引き合いに出す意味は無いですが、そういやDelphiは、
単体Exeも作成できますし、
一方で、プラグインやComponent属性エディタというかたちで実装すれば、
自作Object(Class)をIDEに統合されたかたちで使うことも出来ます。
#ちなみにVM方式じゃないです。CPU Native
Re:1980年に戻れるか? (スコア:1)
OSと見分けがつかないか否かは別にして、「Smalltalkの方は、プラグインの開発という意識もなく、
シームレスにシ
Re:1980年に戻れるか? (スコア:1)
ネットを通じてアップデートできるところとか、ユーザインターフェースの一貫性を持たせて、APIもそれにあわせて作りやすくなっているあたり、この実装には価値があると思います。
技術的にはEclipseがJavaで作られている必要性は皆無ですし、どうせな
Re:1980年に戻れるか? (スコア:2, 参考になる)
うーん。なんか意外というか、信じ難いというか…(^^;
>ネットを通じてアップデートできるところとか、
実装済みかという意味ではアレですが、
まあSmalltalkでも同じことは(やれば)出来るでしょうね。
>ユーザインターフェースの一貫性を持たせて、APIもそれにあわせて作りやすくなっているあたり、
うーん。まだ知らないんですが、DragDropが綺麗に再構築されてるといいなぁと祈っています。
WinとかJava(AWT/Swing)のDragDrop周りのAPIって、七面倒くさいじゃないですか。
それがSqueak(Morphic)だ
Re:1980年に戻れるか? (スコア:1)
> (やプラグイン作り)をする、ってのは どうなんでしょうか?
局所的にはそれは可能なのですが、とはいえ、技術基盤がどの言語で書かれているかっていうのは、それでも重要だと思ってます。その言語を使って拡張するっていうのが基本になるでしょう。EclipseのUIを別の言語で拡張することはどう考えても非
Re:1980年に戻れるか? (スコア:1)
>その言語を使って拡張するっていうのが基本になるでしょう。
>EclipseのUIを別の言語で拡張することはどう考えても非現実的。
うーん。どうなんでしょう?
Groovy [kakutani.com]みたいなやり方も有るかなと思います。
というのは、これ読んだ範囲での推測ですが(^^;、どうやらこのGroovyって言語、
表向きはモダンな(=Rubyとかにも通じる(笑))スクリプト言語なんですが、
中身(言語仕様、オブジェクトモデル、などなど)は微妙にJava側に日和っているわけで、
いわばJavaとモダンScript言語の間を取っ
Re:1980年に戻れるか? (スコア:1)
どういう統合の仕方かにもよると思うんですけど、同じVM上でJavaで作ったクラスをRubyで継承して・・・なんていうアプローチは、これは無理だと思いますよ。命名規則も違うし。文字列やストリーム系あたりの互換性を保つのも難しそうですし。使いにくいだけではないかなと。
> あと、Rubyみたいなレベルの言語になると、
> IDEってそんなに必要か?とも思ったりする
スクリプト言語でのプログラミングはIDEは要らないですね。(Javaとかと違って)言うまでもなくその方が望ましい。
GUIとか何か別のモノとプログラミングが連携するっていうときに、拡張可能なIDEというのは、あると便利なのかなとは思います。
Re:1980年に戻れるか? (スコア:1)
>すよ。命名規則も違うし。文字列やストリーム系あたりの互換性を保つのも難しそうですし。使いにくいだけではないかなと。
Rubyそのものを馬鹿正直に持っていくのは無理でしょうね。
オブジェクトやクラスのアーキテクチャが違うってのもありますし、
ライブラリも違う(Rubyって変にUnixべったりだし)んで…
なので、Ruby「似」という方向性になるんだと思います。
で、Groovyは、Ruby似であると同時に、より一層Javaに日和ってるわけで。
#4991なのでG7