パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

アラン・ケイがNHKに出演」記事へのコメント

  • 途中から見ました。
    Squeak を使って、小学生がサクサクと
    プログラミングしてゲームなどを作成していました。

    うーむ、私がはじめてコンピュータに触れたとき
    と比べると、ずいぶんと環境がかわったなぁー
    と思っちゃいました。

    私なぞは 中学生のころ BASIC で挫折して、その後
    きちんとプログラムが書けるようになったのは
    大学生になってからです。あのころ Squeak とか
    Lego とか知ってたらもうすこしハマってたかも。

    --
    お仕着せのアプリケーションを使うのではなく、
    自分でいろいろなプログラムを作成して
    自分の思い通りにカスタマイズできるコンピュータ
    が理想なんだと伝えようとしてたみたいです。
    • by BoneHead Hiro (5552) on 2002年04月07日 17時26分 (#79235) ホームページ 日記
      >お仕着せのアプリケーションを使うのではなく
       確か、番組のナレーションで
      「アプリケーションの出現は、(アラン・ケイにとって)思わぬ方向に進んでいる..」云々とありました。
      --
      -- BoneHead Hiro --
      親コメント
      • by G7 (3009) on 2002年04月08日 2時48分 (#79338)
        やっぱりそうだよねえ。

        現状のアプリ主義(笑)の時代を打破する道としては、
        今見込みありそなメジャーな手法は、大別して2つ有るような気がします。

        1つは、我ら(?)がオープンソース。アプリ「を」非御仕着せで
        ユーザーの手で中身まで弄れるようにしちゃえばいいじゃんという考えかた。

        もう1つは、Smalltalkや、多分(当事者が意図してるかどうかはともかく)幾多のコンポーネント指向の類による、
        アプリよりももっと細かい単位を供給単位にしてしまえば
        いい(=ユーザーはそれを「組みあわせて」欲しい処理をさせられるじゃん)
        という考えかた。

        どっちも有意義なアプローチだし、もちろん両方併用も可能な手法なので、
        どっちも頑張って健全に発展してほしいと思います。

        #オープンソースなコンポーネント、という分野もぜひヨロシクね(^^;>>諸兄

        余談:
        ただ、俺の感覚では、ケイ氏あたりが言いそうな「アプリケーションの出現」ってのの
        重要な片棒を担いだのは、他ならぬ皆が大好きなUnixだと思うんだよな。
        パイプによる部品化が「不十分(=viすら作れない!)」だったからこそ、
        オールインワンなアプリの出現成長を邪魔(^^;する力を十分持っていなかった、のじゃないかと。

        やっぱり、十分な部品化をするには、「相互参照」とか「イベント駆動(つまり受動)」とかの
        (oopに備わっているがunix pipeには無い)性質が、必要だったのではないかと。
        親コメント
        • >重要な片棒を担いだのは、他ならぬ皆が大好きなUnixだと思うんだよな。
          >パイプによる部品化が「不十分(=viすら作れない!)」だったからこそ、
          >オールインワンなアプリの出現成長を邪魔(^^;する力を十分持っていなかった、のじゃないかと。

           でもぼくたちにはemacsがあると思いまーす。
          • by G7 (3009) on 2002年04月08日 15時12分 (#79564)
            >でもぼくたちにはemacsがあると思いまーす。

            「でも」じゃなくて、まさにEmacsは、オールインワンなアプリの典型例かと。

            EmacsLispで色々カスタマイズやれるべや、というのは確かにそうなんでしょうけど、
            逆にいえばそのやりかたがUnix全体に広がらなかったのが、なんとも残念。

            #たぶんGNOMEやKDEにも同じことが言えるかなと。まぁ1つのプロセスで閉じた世界の話じゃないので、Emacsの状況よりは「進歩」してますが。
            親コメント
            • 多くの人で作るのは、いかにむつかしいかということですね。 一人の天才が作ると素晴らしいもの、一貫性のとれたものが できるけれど、小さな部品で互換性がきちんと取れるように し、しかも全体として一貫性がとれるようにすることが、ど れほど困難なことか。
              それを実現するのだという夢に、多くの人がチャレンジして きたけれど・・・
          • このスレッドのタイトル、こう変えたらよさそうですね。
    • by Anonymous Coward on 2002年04月07日 15時36分 (#79215)
      が本来あるべき姿だ、
      そんな理念を語ってましたね。
      あの子供らがうらやましかったっす。
      親コメント
      • 中途半端に番組を観てたんですけど、これを語っていた場面は観てました。
        よく言われるようなコンピュータが「道具」であるべきというような
        乾いた見方ではなくて、「キャンパス」のようなもの、ってのが
        素晴しい見識だなと思いました。
        使うんじゃなくて、創り上げるものなんですね。

        今のIT教育にもこういう創造的な部分を取り入れられたらいいのに。
        使う視点ばかりのコンピュータはつまんないと思うし。
        親コメント
    • あのー、Lego?
      それはLogoのTypoなのかMindStormのことをいってるのか
      (Lego-Logoという可能性もあるな)

      国内でのLogoのブームは1980年代初頭にありましたな。
      そのときあなたが中学生だったかどうか知りませんが、BASICで挫折するならSmallTalkだろうがLogoだろうがやっぱり挫折した可能性が…
      • by G7 (3009) on 2002年04月07日 15時35分 (#79214)
        >BASICで挫折するならSmallTalkだろうがLogoだろうがやっぱり挫折した可能性が…

        「可能性」そのものを否定することには言及しませんが(笑)、
        basic(色々あるそうですがここで言うのがMS系の行番号なアレだとすると)と
        Smalltalkとかとでは、1つ地味だけど結構痛く大きな違いが有るような気がしています。

        なにかというと、命令とかの、直交性。

        あれが(十分に)有ることではじめて、プログラミングってのは
        暗記教科じゃなく思考教科になってくれるんだよね。

        で、プログラムそのものも(暗記よりは)思考が必要な作業だと思う。

        BASICで挫折した人ってのが、本当にどっちの能力も無かった人なのか、
        それとも思考力はともかく暗記力の不足で敗北した人なのか、は
        個別に考慮したほうが良いような気がしています。

        #俺のばあいは、直交性ってものを教えてくれた言語は、Cでした。
        #それが直交性という概念(名称の文字列の問題じゃなく)であることを知ったのは流石に随分あとでしたけど。

        Smalltalkは、oopであることもそうですが、
        直交性を高くして「覚えないとならん事柄」を減らす
        という面でも気を配られた言語だそうなので、
        そういう面でも、子供でも(もちろん大人でも)やりやすい言語、
        なのかも知れません。

        煽り:その点、C++は、ちょっとねえ…(^^;
        直交してないわけじゃないんだけど、それを指し引いても、概念の数が多すぎ…
        いかに少ない概念の「上」でプログラマが好きなように振舞えるか、が
        子供でも(大人でも)やりやすい言語たるための、重要な資質であるような。

        #そして、それと直交する(笑)問題だけど、標準ライブラリの充実もまた大事。
        親コメント
      • Lego -> Lego MindStorm & レゴロゴ のことでした。

        私は、Basic(行番号が必要なやつ) を知ったあとに、
        C やら Pascal (C++, Java, Perl, Ruby... も同じだけど)
        を知ったとき、"Basic(行番号が必要なやつ)って、非常に
        わかりにくい言語だったんだ" ということを感じました。

        断言はできませんが、Basic よりも、C言語を先に
        学んだほうがすんなり理解できたであろうと
        思いました。
        (関数でモジュール化し、行番号うんぬんはまったく気にしなくて
        よいから。グローバル変数だらけでごちゃごちゃにならないし。)

        実際は、挫折するかどうかに大きくかかわったのは、
        (Basic 自体も原因ですが)それ以上に
        "まわりに知っているひとがいない", "本がない" ってこと
        でしたが... (ほんと田舎はナンもなかった)

        あのころみたいに、Basic の関数リファレンスのみしか
        手元にない状況で覚えはじめたら、今の年齢でも挫折
        していると思う。おもしろくないだろうし。

        そんな人間でも、本や環境しだいで、"プログラマ"として
        飯をくっていけるようになった(私のことです)のだから、
        そういう意味で
        "はじめからあの環境にあるのは、うらやましーい"
        と思ったのでした。
        親コメント
      • 英語が駄目な人が書いたSmalltalkのコードは見たくありません。
        まだBASICの方がマシだったりします。(オブジェクトの意図が読みとりにくい事より、命令の限られている言語のひどいコードの方がマシであると言う意味です
        • by G7 (3009) on 2002年04月08日 2時29分 (#79333)
          >英語が駄目な人が書いたSmalltalkのコード

          あははは。

          てゆーかSmalltalkに限らないのでわ。
          javaだろうがCだろうがBasicだろうがpascalだろうが、
          痛いものは痛いと思いました俺は。

          語順とか、品詞(特に動詞と名詞)の区別とか、前置詞の用法とか、もー頭痛もの。
          いっそローマ字で書いてくれたほうが余程拷問じゃなくなるだろうなあと。
          わかんねーなら書くなよと。

          ま、Smalltalkの場合、キーワードメッセージ(ってゆーんだっけ:名前つき引数と似た雰囲気のアレ)のせいで、
          英語力の有無が普通以上に如実にわかる傾向は有るかもしれない。

          やっぱりあれか。後置キーワードメッセージ [freeweb.ne.jp]の機能を搭載した、
          日本語密着型の日本語プログラム言語でも、作らないと駄目かな。
          #で、こんどは日本語力が試される、と。
          親コメント
          • >ま、Smalltalkの場合、キーワードメッセージ(ってゆーんだっけ:
            >名前つき引数と似た雰囲気のアレ)のせいで、英語力の有無が普通
            >以上に如実にわかる傾向は有るかもしれない。

            全く新規のメソッド名だとそうですが,似たがメソッドが他のクラス
            にあれば,そのメソッド名を流用すればそれなりに書けます.
            またその方が正しいと思いますが.
            (キー付アクセスなら at: や at:put: に統一するとか.)
            親コメント
            • by G7 (3009) on 2002年04月08日 15時16分 (#79567)
              >(キー付アクセスなら at: や at:put: に統一するとか.)

              そういうような意味的類似性を見抜く力が(も)無い人ってのも、居るもんでして(^^;;;;

              つまり英語とか日本語とか以前の問題としての読解力を試されるというか。
              親コメント
    • カスタマイズできるコンピュータという考えですが、それは
       1)コンポーネントを組み合わせるレベル
       2)自分でプログラムするレベル
      に分けられると思います。
      私は、一般の人が使うのは 1)どまりではないかと思います。

      それと、もっと進めた考えとしては、コンポーネントたちが賢く自分で勝手に自己組織化していくような仕掛けに進むべきではないかと考えてきました。ユーザ
      • やっと放映見ました。

        >1)コンポーネントを組み合わせるレベル
        >一般の人が使うのは 1)どまりではないかと思います。

        というか、その(1)だけで出来る範囲というものが、十分強力だったり豊かだったりすれば、良いわけですよね。
        そういう方向を狙っているんではないかなと思います。

        そういう意味において、番組で俺として印象深かったケイ氏の台詞は、
        「この車に何が出来るか見てみよう」というものでした。

        いわゆるイントロスペクションとかリフレクションとかRTTI(?)とか呼ばれる機能が背景にあるわけです。
        objectは自己紹介する能力が有るわけです。
        unixのmanとか--helpとか(^^;とは次元の違う、強力な、自己紹介の能力が。
        unixのソフトでは、それ自体をなんぼいじくりまわしても(ソースを見るのはここでは反則です)、
        それがナニなのかは判らないわけでして。

        これは多分ほんの一例です。

        ユーザーに、いかにその部品の存在(笑)と機能を十分に紹介し理解させるか、
        逆に使うべきでない使いかたを回避させる(それを知らしめる)か、
        という面が、「単に組みあわせるレベル」というレベルそのものを
        強化してくれるのだと思います。

        #あ。もちろんソース読むの「も」重要ですけどね。
        #その延長として、読みやすいソースを書きやすい言語であることも、重要ですし。

        ところで自己組織化とかは、どうなんだろうなあ。どーでもいいやんという気が実はしています俺。あんまり乗り気になれない。
        親コメント
        • > ところで自己組織化とかは、どうなんだろうなあ。どーでもいいやん
          > という気が実はしています俺。あんまり乗り気になれない。

          > ユーザーに、いかにその部品の存在(笑)と機能を十分に紹介し理解させるか、
          > 逆に使うべきでない使いかたを回避させる(それを知らしめる)か、
          > という面が、「単に組みあわせるレベル」というレベルそのものを
          > 強化してくれるのだと思います。

          > objectは自己紹介する能力が有るわけです。

          だから、ユーザに対して自己紹介するものであればいいのでは?
          親コメント

開いた括弧は必ず閉じる -- あるプログラマー

処理中...