最新の Smalltalk の統合 IDE について最も怖いことは何ですか?[閉まっている]
https://stackoverflow.com/questions/179238
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
私としては Smalltalk 復活の波に乗る (特に多くの Ruby-on-Rails 関係者が Smalltalk を再発見し、 シーサイド 次のアップグレードされたWebフレームワークとして）、「ええ、しかしお気に入りのエディターを使用してSmallTalkコードを編集するにはどうすればよいですか？」などの質問があります。または「スモールトークはまだそれ自体の世界での生活を主張していますか？」
今、 Smalltalk を初めて体験したのは 1981 年でした, こういう質問はよくわかりません。エディターとデバッガーに現在のコードの状態を認識させ、Smalltalk 対応の変更管理システムと統合してもらいたいと思うのはむしろ自然なことのように思えます。外部エディター、デバッガー、または変更制御マネージャーを使用するのは、非常に面倒に思えます。
では、お気に入りのエディターで Smalltalk の 5 行メソッドを編集できないこと、または Smalltalk 非対応のお気に入りの変更管理システムを使用できないことの何が最も怖いのでしょうか?
解決
すべてが異なります。行の最後に行きたいですか？ Ctrl-Eではありません。単語ごとにいくつかの単語を飛び越えたいですか？ Meta-Fではありません...
テキスト編集は、基本的なプログラミングアクティビティです。これらの入力をいじるのは、私の心の奥深くにあるものをいじるのです。
他のヒント
特に怖いことはありませんが、他の smalltalk を使用していたときでも、VW で API を理解するのは少し面倒だと感じました。ブラウザの影響で、API を少しずつ確認することになり、特定の機能をどこで探せばよいのかすぐには分からないことがよくあります。
Smalltalk は、その仕組みを理解するためのパラダイムシフトにも少し悩まされています。私が大学で学士号を取得していたとき（Smalltalk に初めて出会ってからしばらくして）、クラスの他のみんなが最初のシステム (Squeak) を学びながら最初のパラダイムのこぶを乗り越えていくのを見て、ちょっとしたシャーデンフラウデを楽しむことができました。時間。
パラダイム シフトと、クラス ライブラリにやや埋もれている機能の組み合わせにより、学習曲線が少し急になると思います。ST は、実際の速度に達するまでにかなり急な学習曲線があるという評判がありました。これは、大規模なクラス ライブラリと、言語機能のほとんどがライブラリのどこかに埋め込まれているという事実によるものです。
また (そして悲しいことに) Java は 1990 年代半ばに登場し、すべてのマインドシェアを獲得しました。大手Smalltalksは完全に消滅したか、ニッチプレーヤーに売却されたかのどちらかだ。Ruby が Smalltalk への関心を再覚醒させるのに役立ったのに、「また実行された」という時代遅れの認識が根強く残っているのは、（嬉しい意味で）実に皮肉なことです。
見る 私のこの投稿 この時代に Smalltalk に深く関わることのメリット (私がそう考えている) についての尊大な主張に対して。
機会があれば、喜んで Smalltalk に戻りたいと思います。
これまでに使ったSmalltalkはSqueakだけなので、私の意見は他のSmalltalk環境には当てはまらないかもしれません。
画像ベースのアプローチで私が心配しているのは、Smalltalk環境には素晴らしいものがある一方で、その環境外のものとの相互運用を困難にする壁に囲まれた庭園だということです。たとえば、YaccやLexなどの外部ツールを使用する場合はどうなりますか？ Smalltalkコードを生成するためにいくつかのCまたはPythonプログラムを使用したい場合はどうなりますか？ Smalltalkを他の言語で記述された多数のコードと混合し、1つのエディターでそれらすべての言語のコードを編集し、すべてを同じソースコードツリーに保存したい場合はどうなりますか？
Smalltalk環境でシステム機能を呼び出して外部ツールを制御することにより、これらの問題すべてに対処できると確信しています。しかし、外部ツールでSmalltalk環境を制御するのはどれほど簡単ですか？言い換えると、Smalltalkをすべてのマスターではなく、単なる別のコンポーネントにしたい場合はどうなりますか？
1つの大きな問題は、Smalltalk VMを1つ記述すると、まだ何年も経ちますが、他のSmalltalk VMとの互換性がないことです。
その理由は理解できます。Smalltalkの中核は、非常に小さな公理とキーワードのセットです。これは、Smalltalkを30分間学習した後、言語自体ではなく、APIライブラリを既に学習していることを意味します。言語設計に対するそのアプローチが好きです。
しかし、Smalltalkの世界では、すべてのVMベンダー間で共通の基本標準APIを使用するというコンセンサスが得られない限り、あるVM用に記述された私のSmalltalkコードは、他のVM切り替えることにしたときのVM。
これには、VMを切り替えるときにスペースに関する知識の一部が廃止されるという結果もあります。
Smalltalkを試したことはほとんどありません。私は専門家になるにはほど遠い。この理解は、約1か月前に James Robertson と話すことから生まれました。
もう1つ付け加えておきたい点は、Seasideは実際に最も人気のあるSmalltalk VMで実行されるということです。その偉業を達成するために彼らが自分で構築しなければならなかった標準APIのどれだけのはずだったのでしょうか。
以上のことを言っても、私はいつもSmalltalkの状態についてもっと耳を傾けています。 Smalltalkの非常に強力な開発環境（およびその他の利点）を試してみたい 。
遅れていることは分かっていますが、私にとって最大の悩みは、どのsmalltalkにも本当に良いエディターがいないことです。それは私には理解できないことです。テキストの操作は非常に重要であり、「サポート」が少なくなります。...
これは常に1つのメソッドをじっと見つめているだけであり、別のメソッドを確認するためだけにメソッドファインダーまたは別のブラウザーを使用する必要があります。これは私が本当に嫌いなものです。...
制限されたSmalltalk環境は、他の言語がまだ適切なエディターを持つのに苦労しているときにデータベース駆動型ソース管理システムに依存のようなことを可能にしましたが、統合今日は非常に困難です。
EclipseやTeam Foundation Serverなどのツールを使用すると、すべてのツールを相互に統合することに慣れます。例えば。要件が作成されると、プログラマがその要件を実装するためにコミットする変更セットに自動的にリンクされます。この「境界破壊」 Smalltalkの世界では、以前は異なるツールを使用することはほぼ不可能でしたが、より大きなプロジェクト、より大きなチーム、より高いレベルの抽象化などでは、洗練されたエディター以上のツールが必要であり、ソフトウェア開発ライフサイクル全体を支援します。
キーボードでのナビゲーションやプラットフォームUIの動作のサポートに対する有用なサポートはありません。
確かに、（よく書かれた）Smalltalkには信じられないほどのテキストエディターは必要ありませんが、キーボードを握ったまま環境内を移動できるのは非常に便利です（私の場合は、 RSI）。 VisualWorksのインスペクターを試したところ、リストを上下に移動するために矢印キーが正しく機能しませんでした。スペースバーを押すと、ウォークバックがありました。ため息。
Windowsの世界では、Dolphin Smalltalkのようなものはありません。 IDEは素晴らしいです。試してみたい別の高品質の製品はVisualworksで、うまく機能し、非常に高速なVMを備えており、ドキュメントもかなり優れています。
過去に両方を使用しましたが、心配する必要はありません。
