方法でソフトウェア開発上の問題を解決するよりも、既存の言語にオブジェクト指向プログラミングの手を加える「ハイブリッドな」方法に注目します。それなら既存の言語の力を維持しつつ、オブジェクト指向プログラミングも活用できると考えます。本では、次のオブジェクト指向プログラミング言語を比較しています。完全に残しつつ、遅延束縛を行うオブジェクト指向プログラミングを可能にしている、と冷静に比較しています。ハイブリッドな言語を考えていたので、言語仕様の拡張は方向性が異なりました。個人の創造性を発揮させ、プログラマにとって最高のツールであり、ソフトウェア問題に対する最高の解決策だと考えたようです。選択には問題があると考えました。世界で閉じていることが問題だと考えました。早期束縛のハイブリッドを選択します。普及し始めていたからとのことです。言語へのトランスレーター)とライブラリの販売を始めます。ブラウザも後々開発したようです。遅延束縛を支える要素の一つでもある「ブロック」があります。ブロックはクロージャーではないんですが、話が面倒になるので近いものだと思ってください)。ブロックの強力さを認めつつも採用しませんでした。ようにハードウェアスタックを前提とする言語では実装が難しいと判断したようです。使っちゃったからできなかったの。☆」みたいな文法上の理由ではありません。制限つきなら実装できなくもないと言っており、開発上の課題に挙げたものの、結局は実装されませんでした。実装しましたが、メモリ管理が難しく、残念ながら使いやすいとは言えません。関数ポインタを引きずっており、見た目が大変ややこしいです。実装されたクロージャーは多少ましな文法になったものの、メモリ管理の面倒さはゼロにならないみたいですね。型推論なしではとても使っていられないのではないでしょうか。標準規格はありません。開発が進んできたことを意味しません。メッセージ送信機構といくばくかの文法を追加した程度で、ルートクラスも難なく用意できます。共通点は多くありません。共通でも、まったく同じ内容ではありません。跡形は見えないような気がします。シリーズという商用ライブラリを販売していました。ライブラリのクラス階層を挙げておきます。意識したライブラリだったようです。年にリリースされたようです。ライブラリはバグだらけだった。フレームワークを作った」と言っている方もいます。ライブラリが超優秀だったというエピソードを見たこともないのでどうなんでしょう。ライブラリはソースコードで提供されていたそうです。クラスしかありません。トランスレーターで、コンパイラのみの購入だとなかなかの貧弱さです。コンパイラは使っていなかったと思います。基礎ライブラリはごくごくシンプルです。StreamTableこれだけです。アプリケーションの開発に必要なコレクションクラスのみです。文字列を使い、イテレーターはありません。風味のライブラリにはしませんでした。?そこは現在も残る洗練されたツールキットを開発した人たちのことです。そこにはきっと深い理由が...いえ、なかったかもしれません。惹かれたわけじゃなさそうです。そこに自分にとって最善のツールがあると思ったら、いちいちそのルーツまでたどって参考にしようなんて思わないでしょう。そのルーツから派生した目の前にあるツールが最善なんですから。アプリケーションを実装しようとするのか。ルーツは所詮(その人たちにとって)過去の遺産です。偉そうに言い切りましたが、統一されたクラスライブラリは必要ないというだけだったのかもしれません。コンピューターでのみ動作すればよかったのですから。私、主に後半が気になります。)のリリースと同時です。版権を買い取っていません。以外のクラスのルートクラスではありませんでした。いう二つのルートクラスが混在しています。含まれていたクラス階層は以下です。フレームワークを使ったことがある人なら見覚えがあるはずです。と時刻に関するクラスです。うちの一部が含まれています。使い込んでいる人なら、このリストを見て何かに気付くかもしれません。一部としてリリースされたわけです。文字列を使ってましたし、前述したようにコレクションクラスも(数えるほどですが)すでにありました。データベースレコード間の変換処理のため」が大きいのではないかと思います。目的はまだあって、そのうちの一つがクロスプラットフォームのサポートです。開発理由は製品戦略でしょう。ライブラリのバグだと思うほど当時困ったのかもしれません。システムに直結したツールではなくて、クラスとメソッドをリスト表示し、選択してソースコードを編集するくらいのツールだったようです。思わなくもなかったです。同様のツールはありません。