Smalltalk の学びにくさの原因

クラスベース・オブジェクト指向のわかりにくさ
Lisp 的側面のわかりにくさ
- 制御構造の記述すらメッセージ送信であること　ブロックを用いること
払拭しきれていない（完全に払拭することは現実的でないものもある） Dynabook 色
- シンプルだが自然言語を意識した独特の記述法
- グラフィカル UI とそれを前提にしたツール群
- 至れり尽くせりのサービス
- 純粋オブジェクト指向
- 動的結合　開発サイクル
クラスライブラリ、言語仕様に対する接し方の違い
- 標準・基本クラスにも必要なら手を入れる/入れられる
- 標準・基本クラスもソースを読む必要がある
- 通常は言語仕様に含まれるものも標準・基本クラスにより実装されている
- ゆえに、通常は何故ナシ、不可侵、愚痴を言って、で済ませられるものもそうではない。

--sumim

独特の世界観をもつ巨大なクラスライブラリと、それらをある程度把握していないとなにもできないこと、じゃないですかねー。
しかもObjectをRootにした単一継承の深いツリーでどこの何が呼ばれているのやら自分が今どこを見ているのやら。（初心者の場合）

やはりクラスライブラリの巨大さもネックになりますかね。SHIMADA さんは、グラフィカル UI とかツール群のほうはぜんぜん違和感ありませんでしたか？--sumim

僕はSmalltalkより先に、EmacsとかLISPをかじっていたもので、そうかあれをグラフィカルにしたものか。毎回ダンプしてるわけだな。と変に納得してしまったので、そこでのつまずきはありませんでした。あとUNIXの文化にどっぷりはまっていて普通の言語の市販IDEは使ったことがなかったことも幸いだったのかも知れません。--SHIMADA

Lisp 使いで、Emacs に通じておられたら違和感はないかも知れませんね。なるほど。　私は、組んだプログラムがそこ（Smalltalk 内）でしか使えない…という違和感を克服するのに十余年かかりました(^_^;)。開発環境は、実行型のファイルを吐きだすもんだという先入観がなぜか異常に強かったのですね。--sumim

クラスライブラリの巨大さは、先人の成果として有り難いものである一方で、覚える側から見れば面倒でもあって、痛し痒しですね。
Dynabookの「システムの提供する機能は少ない方が好ましいが、しかしメタなものであるべき」に反してしまうと、学習はシンドいでしょうね。
逆にいえばメタ(だけ)を充実させれば学習しなくても済む替わりに自分でやれ(ぉ)という世界になるかな。--戯

制御構造の違和感は気にしなくて良いんじゃないかな。CやBasicがifとかを特別扱いするほうが"特殊"なのだから。

組んだProgがソコでしか使えないってのはUnixもWinも同じですね。(OSという)フレームワークの中に住んでいるだけのこと。
個人的にはDelphiが中庸(?)の世界観を教えてくれたので感謝してます。Winの上にDelphiという二重フレームワーク状態。
今でもVCLを作るときにWinAPIを使い"過ぎる"のは嫌いです。Delphi層を飛び越してWin層を叩くみたいなのは極力避けるのがお洒落。-戯

添付Classが少ない。MVCで言えばM用のClassばかり。Unix CUIという貧相すぎる(笑)IOしか相手にしなくて済む。
全てがObjectなのは、却ってその方が幸せを感じる。最近じゃDelphiやJavaでもイライラするもんな。
なまじImageみたいにObjectそのものを保存する考え方が無いぶん、成果を"捨てる"事が却って気楽である。
なまじ本体が何でも抱えるスタイルじゃないぶん、馴染んだツールが使える。ClassLibraryのDocumentはhtml(語弊)だとか。

…という点で、後ろ向きだけど最近最も気分よく使ってる言語は、rubyだったりします(笑) --戯
(でも非Objectなifとかはrubyにも有るなあ。まああんまり関係ないと思うけど。iteratorとかばんばん使う/作るし。)

ほんとは、Object(の集まり)の粘土細工、みたいな感覚は重要なんだと思うけど、
Smalltalkまでいっちゃうと引いちゃうっていうか。

なので(?)、仕組みが更にシンプルという意味で、ドリトルにはちょっと期待。
といってもタートルに期待してるわけじゃないし、本家実装そのものに期待してるわけでもないですが。
ドリトルの言語仕様にImageみたいな仕掛をくっつけて、GUI云々についてはメタな部分だけ提供する、
なんてのが幸せかなーと夢想する昨今。それともWindowもタートルに描かせるのがスジかな？(^^;

Unix系(広い意味ではWinもMacも含むと思う)の世界が「名前ベース」なのに対し、
Smalltalkとかは、Lispに端を発するらしき「半名前ベース」であるような気がする。

半ってのは、名前には半分しか依存しなくて済み、無名なものが色々使われるっていう意味(の創作語)。
オブジェクトも手続きも本質的には無名であり、必要に応じて名前にBindするっていう世界。

逆にいえば名前ベースはGlobal名前ベースと言い換えても良いと思う。
UnixとかのFileSystemでは、モノの名前がどこからでもアクセス可能な形で晒され、
一方でその(Globalな)名前でしかアクセスが出来ない。
＃openしてからforkすることで無名fdを渡すってのは、反則ということで(藁

誰かさん(^^;が言ってたようにUnixはFileとProcessしかない。
しかも、File(System)は名前の供給者、Processは需要者。
なんかモノの方向というか構造というかがワンパターンなような…

で、お洒落じゃないけど、それがゆえ(?)に世間ウケしやすいのは、
名前ベースのほうなんじゃないかと思う。
これが今Unix系がわが世の春を謳歌してる理由の1つじゃないかと思う。 -戯

名前の強み(泥臭さも込みで)に、半名前が対抗するには、
やっぱり触覚とか視覚とかに訴えるのがイイんだろうな。
オブジェクトに触れる(比喩で十分だと思う)とか見れるとか。

私はSmalltalkを昔学んだLisperで最近はCLOSなども使うのですが，Smalltalkはなんというかとても，うっとおしいような気がするのですね．言語を学んだだけでは済まなくて，大量のよくわからないクラスを参照せざるを得なくなるわけで．
それと自分で作る部分と他人が作った部分がなんだか混ぜこぜになってしまう感じがどうもなじめませんでした．クラスブラウザがソースコードの一覧性を壊してしまうのが悪いのかな．
まあ，これはPC98時代のSmalltalk/Vの話ですから今はもっと改善されているかもしれいませんが--mu

このページを編集 (5237 bytes)

以下の 7 ページから参照されています。

Smalltalk　最終更新: 2007-02-13, 17:54:17 <pharm88>
Dynabook　最終更新: 2011-04-14, 22:45:13 <uq1-221>
多態性　最終更新: 2006-04-03, 22:44:14 <192>
Object感覚の学びにくさの原因　最終更新: 2004-08-31, 14:04:48 <apollon>
MVC、これでいいのか？　最終更新: 2004-11-10, 11:49:14 <proxy1>
bob　最終更新: 2003-03-27, 19:59:41 <tibook>
Smalltalk でビビること　最終更新: 2005-08-10, 21:19:02 <192>

This page has been visited 8185 times.