アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
途中から見ました (スコア:1)
Squeak を使って、小学生がサクサクと
プログラミングしてゲームなどを作成していました。
うーむ、私がはじめてコンピュータに触れたとき
と比べると、ずいぶんと環境がかわったなぁー
と思っちゃいました。
私なぞは 中学生のころ BASIC で挫折して、その後
きちんとプログラムが書けるようになったのは
大学生になってからです。あのころ Squeak とか
Lego とか知ってたらもうすこしハマってたかも。
--
お仕着せのアプリケーションを使うのではなく、
自分でいろいろなプログラムを作成して
自分の思い通りにカスタマイズできるコンピュータ
が理想なんだと伝えようとしてたみたいです。
Re:途中から見ました (スコア:2, 興味深い)
確か、番組のナレーションで
「アプリケーションの出現は、(アラン・ケイにとって)思わぬ方向に進んでいる..」云々とありました。
-- BoneHead Hiro --
Re:途中から見ました (スコア:1)
現状のアプリ主義(笑)の時代を打破する道としては、
今見込みありそなメジャーな手法は、大別して2つ有るような気がします。
1つは、我ら(?)がオープンソース。アプリ「を」非御仕着せで
ユーザーの手で中身まで弄れるようにしちゃえばいいじゃんという考えかた。
もう1つは、Smalltalkや、多分(当事者が意図してるかどうかはともかく)幾多のコンポーネント指向の類による、
アプリよりももっと細かい単位を供給単位にしてしまえば
いい(=ユーザーはそれを「組みあわせて」欲しい処理をさせられるじゃん)
という考えかた。
どっちも有意義なアプローチだし、もちろん両方併用も可能な手法なので、
どっちも頑張って健全に発展してほしいと思います。
#オープンソースなコンポーネント、という分野もぜひヨロシクね(^^;>>諸兄
余談:
ただ、俺の感覚では、ケイ氏あたりが言いそうな「アプリケーションの出現」ってのの
重要な片棒を担いだのは、他ならぬ皆が大好きなUnixだと思うんだよな。
パイプによる部品化が「不十分(=viすら作れない!)」だったからこそ、
オールインワンなアプリの出現成長を邪魔(^^;する力を十分持っていなかった、のじゃないかと。
やっぱり、十分な部品化をするには、「相互参照」とか「イベント駆動(つまり受動)」とかの
(oopに備わっているがunix pipeには無い)性質が、必要だったのではないかと。
Re:途中から見ました (スコア:0)
>パイプによる部品化が「不十分(=viすら作れない!)」だったからこそ、
>オールインワンなアプリの出現成長を邪魔(^^;する力を十分持っていなかった、のじゃないかと。
でもぼくたちにはemacsがあると思いまーす。
Re:途中から見ました (スコア:1)
「でも」じゃなくて、まさにEmacsは、オールインワンなアプリの典型例かと。
EmacsLispで色々カスタマイズやれるべや、というのは確かにそうなんでしょうけど、
逆にいえばそのやりかたがUnix全体に広がらなかったのが、なんとも残念。
#たぶんGNOMEやKDEにも同じことが言えるかなと。まぁ1つのプロセスで閉じた世界の話じゃないので、Emacsの状況よりは「進歩」してますが。
Re:途中から見ました (スコア:0)
それを実現するのだという夢に、多くの人がチャレンジして きたけれど・・・
オープンソースなコンポーネント (スコア:0)
コンピュータ=知性の増幅器 (スコア:1, 参考になる)
そんな理念を語ってましたね。
あの子供らがうらやましかったっす。
Re:コンピュータ=知性の増幅器 (スコア:1)
よく言われるようなコンピュータが「道具」であるべきというような
乾いた見方ではなくて、「キャンパス」のようなもの、ってのが
素晴しい見識だなと思いました。
使うんじゃなくて、創り上げるものなんですね。
今のIT教育にもこういう創造的な部分を取り入れられたらいいのに。
使う視点ばかりのコンピュータはつまんないと思うし。
Re:途中から見ました (スコア:0)
それはLogoのTypoなのかMindStormのことをいってるのか
(Lego-Logoという可能性もあるな)
国内でのLogoのブームは1980年代初頭にありましたな。
そのときあなたが中学生だったかどうか知りませんが、BASICで挫折するならSmallTalkだろうがLogoだろうがやっぱり挫折した可能性が…
Re:途中から見ました (スコア:2, 参考になる)
「可能性」そのものを否定することには言及しませんが(笑)、
basic(色々あるそうですがここで言うのがMS系の行番号なアレだとすると)と
Smalltalkとかとでは、1つ地味だけど結構痛く大きな違いが有るような気がしています。
なにかというと、命令とかの、直交性。
あれが(十分に)有ることではじめて、プログラミングってのは
暗記教科じゃなく思考教科になってくれるんだよね。
で、プログラムそのものも(暗記よりは)思考が必要な作業だと思う。
BASICで挫折した人ってのが、本当にどっちの能力も無かった人なのか、
それとも思考力はともかく暗記力の不足で敗北した人なのか、は
個別に考慮したほうが良いような気がしています。
#俺のばあいは、直交性ってものを教えてくれた言語は、Cでした。
#それが直交性という概念(名称の文字列の問題じゃなく)であることを知ったのは流石に随分あとでしたけど。
Smalltalkは、oopであることもそうですが、
直交性を高くして「覚えないとならん事柄」を減らす
という面でも気を配られた言語だそうなので、
そういう面でも、子供でも(もちろん大人でも)やりやすい言語、
なのかも知れません。
煽り:その点、C++は、ちょっとねえ…(^^;
直交してないわけじゃないんだけど、それを指し引いても、概念の数が多すぎ…
いかに少ない概念の「上」でプログラマが好きなように振舞えるか、が
子供でも(大人でも)やりやすい言語たるための、重要な資質であるような。
#そして、それと直交する(笑)問題だけど、標準ライブラリの充実もまた大事。
Re:途中から見ました (スコア:0)
トンデモ系の表現ですな。
ん? (スコア:1)
# mishimaは本田透先生を熱烈に応援しています
Re:途中から見ました (スコア:1)
私は、Basic(行番号が必要なやつ) を知ったあとに、
C やら Pascal (C++, Java, Perl, Ruby... も同じだけど)
を知ったとき、"Basic(行番号が必要なやつ)って、非常に
わかりにくい言語だったんだ" ということを感じました。
断言はできませんが、Basic よりも、C言語を先に
学んだほうがすんなり理解できたであろうと
思いました。
(関数でモジュール化し、行番号うんぬんはまったく気にしなくて
よいから。グローバル変数だらけでごちゃごちゃにならないし。)
実際は、挫折するかどうかに大きくかかわったのは、
(Basic 自体も原因ですが)それ以上に
"まわりに知っているひとがいない", "本がない" ってこと
でしたが... (ほんと田舎はナンもなかった)
あのころみたいに、Basic の関数リファレンスのみしか
手元にない状況で覚えはじめたら、今の年齢でも挫折
していると思う。おもしろくないだろうし。
そんな人間でも、本や環境しだいで、"プログラマ"として
飯をくっていけるようになった(私のことです)のだから、
そういう意味で
"はじめからあの環境にあるのは、うらやましーい"
と思ったのでした。
Re:途中から見ました (スコア:0)
まだBASICの方がマシだったりします。(オブジェクトの意図が読みとりにくい事より、命令の限られている言語のひどいコードの方がマシであると言う意味です
Re:途中から見ました (スコア:1)
あははは。
てゆーかSmalltalkに限らないのでわ。
javaだろうがCだろうがBasicだろうがpascalだろうが、
痛いものは痛いと思いました俺は。
語順とか、品詞(特に動詞と名詞)の区別とか、前置詞の用法とか、もー頭痛もの。
いっそローマ字で書いてくれたほうが余程拷問じゃなくなるだろうなあと。
わかんねーなら書くなよと。
ま、Smalltalkの場合、キーワードメッセージ(ってゆーんだっけ:名前つき引数と似た雰囲気のアレ)のせいで、
英語力の有無が普通以上に如実にわかる傾向は有るかもしれない。
やっぱりあれか。後置キーワードメッセージ [freeweb.ne.jp]の機能を搭載した、
日本語密着型の日本語プログラム言語でも、作らないと駄目かな。
#で、こんどは日本語力が試される、と。
Re:途中から見ました (スコア:1)
>名前つき引数と似た雰囲気のアレ)のせいで、英語力の有無が普通
>以上に如実にわかる傾向は有るかもしれない。
全く新規のメソッド名だとそうですが,似たがメソッドが他のクラス
にあれば,そのメソッド名を流用すればそれなりに書けます.
またその方が正しいと思いますが.
(キー付アクセスなら at: や at:put: に統一するとか.)
Re:途中から見ました (スコア:1)
そういうような意味的類似性を見抜く力が(も)無い人ってのも、居るもんでして(^^;;;;
つまり英語とか日本語とか以前の問題としての読解力を試されるというか。
カスタマイズできるコンピュータ (スコア:0)
1)コンポーネントを組み合わせるレベル
2)自分でプログラムするレベル
に分けられると思います。
私は、一般の人が使うのは 1)どまりではないかと思います。
それと、もっと進めた考えとしては、コンポーネントたちが賢く自分で勝手に自己組織化していくような仕掛けに進むべきではないかと考えてきました。ユーザ
Re:カスタマイズできるコンピュータ (スコア:1)
>1)コンポーネントを組み合わせるレベル
>一般の人が使うのは 1)どまりではないかと思います。
というか、その(1)だけで出来る範囲というものが、十分強力だったり豊かだったりすれば、良いわけですよね。
そういう方向を狙っているんではないかなと思います。
そういう意味において、番組で俺として印象深かったケイ氏の台詞は、
「この車に何が出来るか見てみよう」というものでした。
いわゆるイントロスペクションとかリフレクションとかRTTI(?)とか呼ばれる機能が背景にあるわけです。
objectは自己紹介する能力が有るわけです。
unixのmanとか--helpとか(^^;とは次元の違う、強力な、自己紹介の能力が。
unixのソフトでは、それ自体をなんぼいじくりまわしても(ソースを見るのはここでは反則です)、
それがナニなのかは判らないわけでして。
これは多分ほんの一例です。
ユーザーに、いかにその部品の存在(笑)と機能を十分に紹介し理解させるか、
逆に使うべきでない使いかたを回避させる(それを知らしめる)か、
という面が、「単に組みあわせるレベル」というレベルそのものを
強化してくれるのだと思います。
#あ。もちろんソース読むの「も」重要ですけどね。
#その延長として、読みやすいソースを書きやすい言語であることも、重要ですし。
ところで自己組織化とかは、どうなんだろうなあ。どーでもいいやんという気が実はしています俺。あんまり乗り気になれない。
Re:カスタマイズできるコンピュータ (スコア:1)
> という気が実はしています俺。あんまり乗り気になれない。
> ユーザーに、いかにその部品の存在(笑)と機能を十分に紹介し理解させるか、
> 逆に使うべきでない使いかたを回避させる(それを知らしめる)か、
> という面が、「単に組みあわせるレベル」というレベルそのものを
> 強化してくれるのだと思います。
> objectは自己紹介する能力が有るわけです。
だから、ユーザに対して自己紹介するものであればいいのでは?