ゲストブック

Home
Lisp Scheme
Haskell
Python
Sather
xyzzy
備忘録
ゲストブック

ご感想、ご質問などをお気軽に書き込んでください。
内容の向上に役立てたいと思います。

世間話なども大歓迎です。

新規書き込み

最近の書き込み

1151. Re. 1150. Re. 1149. Debian FD ネットでインストールできました。
うえまMay 12, 2008
紫藤さまの言うとおり、２、３千円のパソコンに期待する方が間違いです。ハンセイ！！
動作がとても重いので、メモリ増設と
日本語環境のために、CD-ROM(DVD)は交換します。

余裕ができたら80G へ　ハードドライブも交換します。

＞2-3000 円の中古 PC はこんなものです。２個買って１個組み立てる (いわゆる２個１)
＞感じです。
元ねた  書き込む

1150. Re. 1149. Debian FD ネットでインストールできました。
紫藤May 12, 2008
うえま さん

インストール成功おめでとうございます。

Debian/etch は CD からインストールすると簡単に日本語が入るのですが、
他の方法ではちょっとめんどくさいかもしれません。

CD ドライブが無いと不便ですので、どこからか入手したほうがいいと思います。
ジャンク屋で安く売っていると思います。

2-3000 円の中古 PC はこんなものです。２個買って１個組み立てる (いわゆる２個１)
感じです。
元ねた  返信 1151   書き込む

1149. Debian FD ネットでインストールできました。
うえまMay 12, 2008
「replase......disket」???の表示は、OS 入れてないから出ていたのかな？

軽量CD-Linux もCD が読んでくれなかった。
それにしても CD がクサイので、内蔵CD の電源、コントロール？線を外し
BIOSでそれを使用不可にして
フロッピーからインターネット経由でのインストールは成功しました。

ウィンドウをクリックしても３０秒くらい待たないと切り替わりません。
６４Mは辛いです。

紫藤さま、Debian での日本語の使用は、どうしたらいいのでしょう？
お教えください。

メモリの増設は、したいと思います。あと、DVD-CD、、、


中古パソコン業者さんは、フロッピーに読み込みエラーが出るといったので、
cdの故障？は、思ってもいなかった？。結局フロッピーは、４枚読み込み成功しましたが
元ねた  返信 1150   書き込む

1148. 夕方：不良パソコンが届きました。
うえまMay 11, 2008

フロッピー：エラーが出るのは分かっていましたが
起動すらしないパソコンを売りつけるとは、どういう神経しているんだろう！！
英語は、分からないので、また書き留めてもいないのですが
「replase ....disket」(左のようなエラーがでる。)
なので、フタを開けフロッピーのケーブルすべて（２つ）とり
BIOS でフロッピーを使用しないに設定。またしても
「replase ....disket」のエラーが止まらない。
CD-ROMでも上のエラー表示でることがあるのでしょうか？←紫藤さま：：
よく聞くと、CD-ROMも異音が出てる。
１ケ月は、保証期間とのことであるが、送料（代引き料）は客負担とのこと。
２８００円のパソコンをやり取りするのに送料手数料も同じ位追加増資せねばならない
あきらめます





PC-WRAP さん　たのみますよ！！







注文内訳は、次の通りです。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
[注文内容]
  B25566: ◇未来があるかどうかはアナタ次第◇ IBM ◇Netvista　6339-46J◇
     \ 2,800 x  1 =   \ 2,800
  ------------------------------------------------
  商品価格合計　      \ 2,800
  送料　（税込）      \ 1,260
  手数料（税込）        \ 315
  ------------------------------------------------
  お支払い金額        \ 4,375

※ フロッピーは、エラーが出る。　購入前から承知。。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
返信 1149   書き込む

1147. Re. 1145. Re. 1144. 人気の言語を作るには ---Being Popular---
亀田馬志May 10, 2008
>>紫藤さま

お久しぶりです。
最近Scheme関係のネタを色々と集めていて、ちょっと忙しかったのでした。

＞しばらく御無沙汰していると思っていたらこんな素晴らしい研究をしていたのですか！

ううむ、単なる一発ネタのつもりだったのに褒めていただいて恐縮です(汗)。

「言語で一番大事なのは名前の長さであって仕様/実装ではない。」

とか書いて

「んなワケあるかあ!!!」

と言う笑いながらのツッコミを期待してたんですが、意外でした(爆)。
いや、実は結構当たってたのか(笑)。

＞紫藤の意見としては言語の名前は

＞1. 3 文字以下 (場合によっては 4 文字もあり)
＞2. 母音字は無いか、あっても 1 文字 ( Lua は ua で一文字風なので 例外)

＞がいいと思います。

そうですねえ。
多分GNUとかもそうでしょうけど、ハッカーの人たちって意外に「とことん記号化して短縮」っての
はワリに気質的には好きなのかもしれません。その点もプログラミング言語の歴史が長くなって来る
辺りで洗練されてきたのかもしれませんね。
例えば、黎明期の

Fortran→FORmula TRANslator
Lisp→LISt Processor

とか今考えてみると不格好過ぎですよね(笑)。無理矢理過ぎて(笑)。
いずれにせよ、色々なプログラミング言語や、また別々の実装をインストールしてみると、これがコ
マンドライン立ち上げる際に

「何だったっけ?」

とか考えざるを得ないのは確かに痛いなあ、と。ホントPrologなんかもワケが分からんかった、と言
う経験もあり、やっぱり実体験上は当たってた、って事ですね(笑)。
PythonもPythonの洒落っ気は確かに効いているんですが、「意味が多すぎ」かもしれない。う〜〜
む。大体Iron Pythonとか、そのテの「別系列」が出てきているのも事実ですし、「人気がある言語
は分化されていく」のは避けられないようなんで、実装が乱立する将来見越すと多くて4文字まで、
ってのはその通りのような気がします。

>>うえまさん

と言う事で一応「ネタ」なんで(笑)。
「ネタをもっともらしく書く」と言うアンサイクロペディア的な試みなのです。
元ねた  書き込む

1146. Re. 1145. Re. 1144. 人気の言語を作るには ---Being Popular---
うえまMay 10, 2008
まさしさん。素晴しい書き込みです。頭がいい！処理系起動コマンドは、短いのがいいです！！
元ねた  書き込む

1145. Re. 1144. 人気の言語を作るには ---Being Popular---
紫藤May 10, 2008
亀田さん
おひさしぶり。

しばらく御無沙汰していると思っていたらこんな素晴らしい研究をしていたのですか！

亀田さんが挙げたものの他に、名前の短い言語は

  S, PHP, SQL, AWK, HSP, Lua などがあります。

これらは人気のある (あった) 言語です。

紫藤の意見としては言語の名前は

1. 3 文字以下 (場合によっては 4 文字もあり)
2. 母音字は無いか、あっても 1 文字 ( Lua は ua で一文字風なので 例外)

がいいと思います。

arc は当てはまるし、tex, C++, sql,  php など多くの言語が当てはまります。

反対に母音字と子音字が交互に並ぶ言語は少しダサイ感じがします。
(BASIC, COBOL, JAVA, Ada, Logo など)

さらなる研究の発展を期待します。
元ねた  返信 1146 1147   書き込む

1144. 人気の言語を作るには ---Being Popular---
亀田馬志May 10, 2008
ポールグレアムの論文に

人気の言語を作るには ---Being Popular---
http://practical-scheme.net/trans/being-popular-j.html

と言うものがある。この主題は言語設計者にとっては、非常に興味をそそられるテーマである。
しかしながら、亀田はこの論文に書かれていないある性質--人気の言語が備えているもの、人気の無
い言語が備えていないもの--を見出した。少なくとも日本に於いては恐らく確固とした法則、と思え
るものがあるのだ。
ひょっとしたらこれは日本限定のローカルルールかもしれない。しかしながら将来的には普遍性のあ
る素晴らしい言語設計への手がかりとなるのではないか、と言うことで亀田の長年に渡る研究の成果
をここに論文としてまとめてみたいと思う。ちなみにここで言う「長年」とは3日間の事だ。

まず最初に、人気のある言語、人気のない言語を含めてプログラミング言語をいくつかリストアップ
してみようと思う。

C
C++
VBA
Java
Perl
Ruby
Python
Scheme
Haskell
Fortran

実はこのリストは人気のある言語から人気のない言語へと順に並べてある。一番上のC言語はどんな
人間でも一回は聞いた事がある、と言う事に異論はないだろう。抜群の知名度を誇る言語である。
しかしながら下へ行くに従って「何だそりゃ?」と言われる確率が高い言語になっていく。渋谷で道
行く女子高生にインタビューしたところ、女子高生の37％くらいはC言語と言う名前は聞いたことが
ある、と回答していたが、Haskell、Fortranと言う名前に至っては

「何それ?え〜と食べ物?」
「ダイエット飲料。」
「新手の勝負パンツ。」
「エッチな意味でしょ?」

と言うわけの分からない回答を頂いた。
さて、こうやって人気のある言語から人気のない言語へとリストを作ってみると、一つの意外な事実
が浮かび上がる。何か気づかないだろうか?
亀田の長年(3日間)に渡る研究の結果、少なくとも日本に於いて人気のある言語には次の法則が成り
立つ。

法則:
プログラミング言語のポピュラリティはその言語の名前の文字数に比例し、そのポピュラリティは近
似的に次の極めてシンプルな数式で表される。

プログラミング言語の人気度＝1/e^(プログラミング言語の名前の文字数)

ここで当然、eとは自然対数の底、ネピア数である。

これは意外な法則に思われるかもしれないが、この法則が指し示す事は、プログラミング言語設計に
於いてまず何より重要なのはそのプログラミング言語の名前をなるべく短い文字数にする、と言う事
だ。つまり、設計思想や実装方法なんかは実は二の次だ、と言う驚くべき真実が浮かび上がるのだ。

例えばC言語は、慣用的には「プログラミング言語C」等と言われるが、実際はただの「C」で、名前
の文字数は1文字しかない。そして上記の方程式に当てはめると人気度は大体37％前後となる。これ
は渋谷の女子高生へのインタビューの結果とほぼ一致する。従って認知度が上がるにつれ自然と使わ
れる機会が増えるのだ。
反面、Haskellなんかは絶望的で、7文字もあるHaskellの人気度は、数式に当てはめて計算すると、
0.09118819655545162％程度になってしまう。つまり、これは渋谷の女子高生1,000人にインタビュー
して一人知ってるかどうか、と言う絶望的な認知度であり、これも女子高生100人斬り、じゃねえ
や、100人のインタビュー結果と符号するだろう。
ところで、こう言う反論もあり得るかもしれない。

「その議論はおかしい。じゃあ、何故4文字しかないLispは人気が無いんだ?その理論から言うと
Perlくらいの認知度を誇っても良いのではないか。」

と。
なるほど一理ありそうだが、この反論には穴があるのだ。と言うのも「Lisp」と言うたった4文字の
言語は現代では存在しないのだ。主に利用されている「Lisp系言語族」の一つの方言は「Common 
Lisp」が正式名称であり、これはスペースを入れれば何と11文字と言う絶望的な文字数になる。これ
を上記の数式で当てはめると1.670170079024566×10^(-03)％と言う認知度になり、こんな言語が人気
が出るわけがない。
事実、歴史的に言うと、Fortranが誕生してから暫くしてからLispが登場して、当初はLispは非常に
人気があった。7文字のFortranと4文字のLispでは法則に従ってLispの方が人気があるのは当然だっ
たのだ。しかし、Lisp1.5と7文字化してから人気の凋落が始まった。5文字のCOBOLに負け、あとの経
緯は皆様ご存知の通りである。
また、Common LispとEmacs Lispのどっちが人気があるのか非常に難しいところだが、実際、業界標
準テキストエディタのスクリプト言語であるEmacs Lispの方がCommon Lispよりはどんな形であれ使
われているだろう。何故ならEmacs Lispの方がCommon Lispに比べて一文字少ない。従って、若干の
差ながらEmacs Lispの方が認知度が高くなる。
加えて、Schemeが何故日本でCommon Lispより人気があるのかもこれで説明が可能だ。6文字の
Schemeは少なくともGaucheのお陰で日本ではPythonくらいのユーザー数がいるのだ。従って、株式会
社数理システムの黒田さんもビックリの結論とは、Common Lispを普及させるにはCommon Lispと言う
名称を止めれば良い、と言うことになる。灯台下暗しだ。是非とも次回のCommon Lisp 第3版策定の
段階では「名称変更」を提案して欲しい。そして、Schemeより文字数が少ない名称を提案すべきなの
は言うまでもない。
また、ポール・グレアム本人が気づいていたのか気づいてないのかさだかではないが、Arcと言う言
語が将来人気が出る言語となり得る、と言うのは分かるだろう。なんせ3文字しか無い。従って、理
論的にはPerlよりは人気が出てC++くらいには使われるだろう、と言う事が予測出来る。また、D言語
やC#には負けるだろう、と言うことさえも予測可能なのだ。
このように、数学的に構成されている筈のLisp言語族やHaskell、Erlang等が数式に翻弄されている
のは幾分奇妙でもある。作者の「こんな思い入れで名づけたいな♪」と言う思惑は実はユーザーに支
持されないのが皮肉と言えば皮肉である。つまり、投げやりに名づけたような、しかも使いづらい
Cが最強の立場に君臨しているのには裏にこう言う法則性が働いているのである。従って、関数型言
語の「数学性がユーザーに受け入れられない」と言う考えは実はとんでもない誤解なのだ。単に言語
の名付け方が失敗しているだけだ、と言う事実から目を逸らしてはならない。真実は意外と単純なも
のなのである。
一方、この法則に反していそうなものの例にJavaScriptがある。これは明らかに例外に見えるが実は
例外ではないのだ。既に知ってる人も多いと思うが、JavaScriptは4文字のJavaにあやかって名づけ
られいる。従って実質的には4文字の言語なのである。

「いや、でもJavaScriptってJavaとは違う言語なんですけど……。」

と言う反論が聞こえてきそうだが、冒頭の論を思い出して欲しい。ポピュラーな言語に大事なのは仕
様や設計思想ではなくって名前の文字数なのだ。そして、実際、Java及びJava Script使用者の半数
以上はJavaとJava Scriptの違いなんかちっとも分かっていない。従って認知心理学的にはこの2つの
言語は全く同じものである。JavaScriptはJavaなのだ。仕様?クソ喰らえ、と思っているユーザーが
多い事を見抜いたNetScapeの発想は見事としか言いようがない。つまり、Common LispがC♭と言う名
称に変更になったらユーザーにとってはこれはC言語の亜種であり、中身が違ってもC言語だと思って
括弧を愛する人間が増える、と言う事を示唆している。そしてそれはやっぱりC言語なのだ。
ちなみに音階的にはC♭はBの事だと言うのを付け加えておこう。

ところで、どうしてこう言う法則が成り立つのだろうか?
かろうじて現在考えられる仮説は次の2つである。

1.端末から呼び出し易い。
2.シンプルな名は体を表す。

技術的な観点から言うと、1番目は結構重要である。特に言語の名前が短いと端末に打ち込んで起動
する際のコマンドも短く、かつ意味が分かるものになりやすい。
例えば、初期のUNIXでC言語を起動するコマンドはccだった。レモンではない。いずれにせよ、Cと名
づけた言語でかつコンパイラの頭文字のCを組み合わせたccと言うコマンドは短く意味も簡潔であ
る。この慣習は現代のgccまで一環しているし、またgccもccコマンドで立ち上げられるディストロも
ある。
一方、長い名前、例えばPythonはpythonと6文字打ち込まないと起動しない。これは一般人には想像
が付かないが、なるべくタイピング量を減らしたいと思っている神経質な日本のプログラマにはウケ
が悪いだろう。Pythonを立ち上げるつもりで、Pを打った後にその後のタイピング量を考えてついつ
いerlと続けて打ってしまうプロのプログラマが多い事は想像に難くない。それくらいプログラマは
文字数に神経質なのである。
また、長い名前のプログラミング言語を呼び出す際の短い名前も無理矢理省略感が漂ってウケが悪い
と思われる。Haskellを立ち上げるのに何でHugsなんだ?と思うプログラマも多いだろう。もちろん実
装名だ、って事は重々承知だろうが、意味が分からん、と言うことで敬遠される可能性が高いと思わ
れる。言語の名前の長さと言うのは意外なところで弊害を生み出すのだ。
第2の観点は至極日本的な観点である。日本人は言霊信仰があり、従って「良い名前」にこだわる気
質があるのだ。そう言う国民性が姓名判断と言う占いを作り上げたと思われる。

「プログラミング言語に姓名判断なんて関係ないだろ。大体アルファベットだし。」

と思うかもしれないが、実はアルファベットでも姓名判断は可能である。どうやってこじつけたのか
知らないがあるものはあるのである。
次のようなサイトがある。

数秘術:
http://uarani.fc2web.com/sintaku/uranai/kabara/kabara.html

例えば「C」一文字で判定してみよう。

 秘数人格:
 あわせ上手。
 どんな人の思いも、楽観的に受け入れやすい。
 ひたすら陽気な精神は上下などの隔たりなく、
 万人から仲間的に慕われる傾向　有り。
 高次の母性的やさしさやサービス精神から、ある種アイドル的立場に立たされやすいが
 他者否定より理解が先立つため、時に窮地に追い込まれることも。

何か良く分からない結果にも思えるが、同時に「プログラミング言語C」の性格を言い当てていそう
ではある。なるほど、「どんな人の思いも、楽観的に受け入れやすい」と言うのは元々システムプロ
グラミング用途に設計された筈なのに、あらゆる現場で使われているC言語らしい話ではあるし、そ
して確かにC言語は「ある種アイドル的立場」である。また、「他社否定より理解が先立つため、時
に窮地に追い込まれること」と言うのは、C言語で「他のプログラミング言語を書ける」柔軟性を意
味しているのだろう。そして、自らが産んだ言語に窮地に追い込まれる可能性は今後捨てきれないの
だ。

 幸福の鍵・存在:
 社交を尊び、かつ仲間意識の中心にいつもある。

 単に仲間を大切に思うだけでなく
 自身もそのファン的他者群からのパワーを
 自己実現のために不可欠であることを知っている。

 万人の願望の代理者となることも多く、
 人に何らかの希望を与えうるフィールドで生彩を放つ。

確かにC言語は「ファン的他者群からのパワーを自己実現のために不可欠であることを知っている」
と思われる節がある。要するに、プログラミング自体が難しいので、C言語を使ったプログラムの製
品化はC言語ユーザーの献身的努力によるパワーを吸い取って作られる。
また、プログラマの願望の代理者になることは確かに多い。そして失敗することも多いのだ。
次に、Common Lispを見てみよう。

 秘数人格:
 仮面上手。
 完璧な正義感と広大な容認の同居。
 寡黙な人柄は他人を癒すことによって自らが癒されうという
 包容力の守備範囲の広さを象徴している。
 時に自主的な人生上の目的を見失いやすいが、外的契機を得ると
 一転して、他者追随不可能なまでのトータルな創造性を発揮する。

これは何が書かれているか、Common Lispユーザーなら一発で分かる。マクロの事である。
しかしながら、C言語に比べると「自主的なプログラム上の目的を見失いやすい」と言うマイナス面
は当たっているだろう。

 幸福の鍵・存在:
 社会の精神的雑踏を遠景として静観できる 
 不浄の魂の体現者。

 欲望に泥まみれになることは生涯なく、
 いかなる願望も何らかの本質的正義と同居し、
 その認識内では不動の精神を維持でき
 他者との心の交流を使い分ける自分自身が
 精神の壁を高くする弱点を克服できるか否か？

これもCommon Lispの性質を良く言い当てている。
しかしながら、実際問題、業務でのプログラミングには本質的正義は存在しない。そしてITの発展は
資本主義に従属していて、資本主義自体は「欲望の泥まみれ」の肯定である。
如何だろうか。「Common Lisp」と言う名前では「資本主義社会では成功しないプログラミング言語
である」と言う事なのだ。

 幸福の鍵・哲学:
 静観の哲学の深淵に
 横たわる愛の真理の旋律を聞く人。
 人間の本質的行動における善を
 原形のまま知り得る悟性を表現することで
 その孤高の精神が持つ浄化作用を万人に分け与えうる。

これもCommon Lispの解説としては見事だ。
問題は、業務上のプログラミングで重要なのは、「横たわる愛の真理の旋律を」聞いたり「原形のま
ま知り得る悟性」なんかじゃなくって単に「納期を守ること」である。

 幸福の鍵:恋愛
 救済的恋愛意識とその顕現。
 自己的欲望に基づく恋愛幸福論のみで
 精神の融合が不可能であることを知るが故の
 他者的願望の受容体。
 本質的愛のシンパシーを体現するための
 無言の抱擁に互いのすべての存在意義を感じる。

これは要するにCommon Lispの括弧の事であろう。「本質的愛のシンパシーを体現するための無言の
抱擁」とは単純に言うとS式の事だ。
しかしながら、「救済的恋愛意識とその顕現。自己的欲望に基づく恋愛幸福論のみで精神の融合が不
可能であることを知るが故の他者的願望の受容体」なんて女性がいたら「重い女」と言われて敬遠さ
れるのが世の常で、従ってCommon Lispは現代の軽薄短小の世相には合わない、と言うことが分かる
だろう。これを見ても、如何に言語設計より「名前」が大事なのか良く分かると思う。

 幸福の鍵・キーワード
 裸体としての魂を存立せし者

Common Lispのシンプルさを表現している。

 幸福への革命:
 言葉を！
 その素晴らしき精神の砦に投げかける試み。
 コミニケーションのための絶え間ない自己分析の記録だけでも
 もし、表現可能になれば
 自身の本質的価値の変容を見出しうるだろう。
 すなわち、「自分は孤独ではない」と。
 しかも、その発見は大多数の他者にとっても大いに有益である。

冒頭でCommon Lispの「記号処理言語」としての性質を説明している。
しかしながら、Common Lispユーザーが孤独な事を見れば分かる通り、「自身の本質的価値の変容を
見出しうる」のは極めて難しい。

如何だろうか。全部の言語を解説する事は止めておくが、言語の性質が「名前」で言い表されている
のが良く分かると思う。他の言語の「姓名判断」も是非とも試してほしい。
そして「長い字数のプログラミング言語に比べると」如何にC言語がトータルバランスが優れて評価
されやすいか、その実態はさておき、理解できると思う。短い名前は人を引き寄せる力なのだ。

いよいよ本論のまとめに入る。
少なくとも日本で受け入れられるプログラミング言語設計に於いて、何よりも重要なのは

　　　　少ない文字数の名前を付ける

事である。すなわち、仕様書作成や実装の問題なぞ後回しで構わない、と言う事が理解できたと思
う。そして、今まで語られていた言語設計に於ける工学的立場と言うのはすべてがすべてではない
が、殆ど間違っていた、と断言出来るだろう。まずは何はともあれ「名前が重要」なのだ。それが言
語のポピュラリティを決定する。従って、プログラミング言語設計の為の教科書の第一章には「名前
の付け方」を置くべきである。
最近の事例ではMaz氏が作ったRubyは非常に上手いネーミングであった、と言うこともこれで証明さ
れる。「処理速度が遅い」なんて批判は本質的ではない。「Ruby」と言う4文字の名前を付けた時点
で日本国内での人気が不動になった事が重要なのである。そして、PerlやJavaと直接競合したい、と
言う戦略もこれで汲み取れるだろう。しかしRubyはC言語に喧嘩は売らない意志が見えるし、
Pythonは日本ではRubyよりマイナーなのもしょうがないのである。
では、究極のポピュラリティを会得出来る言語とは何だろうか?亀田には既に答えがある。その言語
は仕様も実装も決定していないが、既に名前だけは決めてある。それはこれである。

　

上の言語である。もう一度書くが、 と言う名前の言語である。文字数＝0である。
ポピュラリティ理論に依ると、人気度＝1/e^0なので、これは100％の人気度になる。これがC言語を
越えるポピュラリティを持つだろう言語だ。仕様も実装は全く決まってないが将来 が発表されれば
誰もがこの言語を使うようになるだろう。 は数々の言語論争にトドメを刺す究極の言語である。
しかし なんて言語は打てないのではないか?と危惧する向きもあるだろう。これは心配なく、表示さ
れなくてもアスキーコードでは認識される。ちなみにアスキーコードでは0x20である事を付け加えて
おく。
 は2つ利点がある。それらを挙げてみよう。

1.端末でスペースキーを間違えて打って、リターンキーを間違えて打てばいつでも立ち上がる。よっ
て、タイピングミスで立ち上がり易いので、プログラマは諦めて を使うようになるだろう。
2.プログラムを打ってる最中にスペースキーを打つだけでプログラムから を呼び出すことが可能で
ある。これはメタプログラミングを越えるメタメタプログラミングを可能にし、従ってすべてメタメ
タとなる事は間違いない。

特に2番の性質は重要で、 はLispを越える可能性がある、と言うことだ。仕様は決まってないが。
なお、 は何と読むのか疑問に思う向きもあるだろう。実は読み方は決めていない。そして実は読み
方は重要でない、と言う事を改めて指摘しておく。これは応用数学者であるクヌースが発見した「
TeXの法則」である。
「TeXの法則」を知らない人の為に少々解説しておくが、クヌース教授が開発したTeXは何て読むのか
ハッキリせず1980年代後半〜1990年前半に於いて全世界を混乱に陥れた。湾岸戦争勃発の遠い理由は
このTeXの読み方に関するイラク側の挑発だったと言われている。
現時点でもTeXは「テフ」と呼ばれたり「テック」と呼ばれるのがベストだ、と言われているがいく
ら何でも無理があるだろう。しかし「何て読めばいいのか分からない」名前を付けるのは、プログラ
ミングの世界ではカッコイイ事になってしまっているのだ。すべてクヌースの責任である。
「TeXの法則」で一番有名な応用例はLinuxである。これも製作者のリーナス・トーバルズ氏は「好き
に読んでいいよ」と大変無責任な発言をしている。その為現時点でも「リナックス」なのか「リヌク
ス」なのか「ライナックス」なのか、あるいはひょっとしたら「リナフ」なのか全く見当が付かな
い。いずれにせよ、「TeXの法則」を応用した名称はハッカー界ではキャッチーだと思われているよ
うだ。従って も敢えて読み方は決めない事とする。
もう一度繰り返すが、名前の「文字数」が重要なのであって、読み方は重要ではないのだ。しかもこ
れは非常に日本人の琴線に触れる。「文字」が「読み方」を表さないのは日本の伝統芸で、そんなル
ール無視の名前は地名をはじめわんさかあるのだ。ちなみに「馬志」は「まさし」と読む。当て字も
いいところである。
そんな当て字人間が作った は日本中にプログラミング言語の新潮流を生み出すだろう。しかし繰り
返すが仕様は全然決まっていない、と言うことだけ念を押して本論文を了とされたい。
返信 1145   書き込む

1143. 中古PCの着せ替え
うえまMay 09, 2008
◇ IBM ◇Netvista　6339-46J◇今日注文、さっそく今日発送とのこと。

パソコンショップで、部品機器の価格を調べてきました。
紫藤さまの「中古サーバーを使った、、、」の記事を参考にするので
フロッピーは、必要だ！しかし、フロッピーは読み込みエラーが出るらしいので

ーーーー
フロッピー3.5型＠１２８０円なり：これは、財布の中身の範囲で OK です。
ーーーー
メモリーは、たったの６４M ：これはやせ過ぎだから
スロットは２つで１つは６４Mが刺さっている空きスロットは１でメモリ５１２Mまでだから
PC133 SDRAM CL3 128M @2380円 
　　　　　　　　256M @3680円　　　のどちらか？！　
ところで、パソコンショップのメモリの形状は合っているかなぁ？いちよう調べた！
メモリは、５／１７日に購入？する？：小遣いの日は、７の付く日だから
ーーーー
紫藤さまの記事によれば、ハードディスクは騒音の問題で交換した方がいいとのこと！
ハードディスク 3.5インチ
UltraATA HITACHI 80G が　@4880円なり、
ハードドライブは、５／２７日に購入？する？：小遣いの日は、７の付く日だから:笑い
ーーーー

部品機器の取り付け、またインストールの繰り返しなりそうだ！！
最初は、ファイルサーバーの構築実験、データが無いので、写真を撮りまくるぞ！！笑い
元ねた  書き込む

1142. Re. 1141. Re. 1140. Re. 中古 PC を使った 格安、省電、静音、省スペース自宅サーバー
うえまMay 09, 2008
紫藤さま

中古パソコン注文しました。
アドバイスありがとうございます。

[注文内容]
  B25566: ◇未来があるかどうかはアナタ次第◇ IBM ◇Netvista　6339-46J◇
     \ 2,800 x  1 =   \ 2,800
  ------------------------------------------------
  商品価格合計　      \ 2,800
  送料　（税込）      \ 1,260
  手数料（税込）        \ 315
  ------------------------------------------------
  お支払い金額        \ 4,375

※ フロッピーは、エラーが出る。

このパソコン：暇、小遣いと相談して、少しずつ育て上げようと思います。
まずは、現状で Linux インストールしようと思います。
元ねた  返信 1143   書き込む

1141. Re. 1140. Re. 中古 PC を使った 格安、省電、静音、省スペース自宅サーバー
紫藤May 09, 2008
ローカルで試すのであれば安いのでいいと思います。

NetVista などの IBM の企業向けの PC がお勧めです。
元ねた  返信 1142   書き込む

1140. Re. 中古 PC を使った 格安、省電、静音、省スペース自宅サーバー
うえまMay 08, 2008
紫藤さま

＞IBM NetVista A40 6881-20J が 3980 円で、 IBM NetVista A40 6842-10J が 5980 円で

とありますが、最近の価格ドットコムでは、引っかかりません。？
(IBM２８００円あたりから引っかかります。安いのでいいのかなぁ)
代わりのお勧めPC は、ありませんか？

紫藤さまの、ファイル、ウェブ、サーバーのメモリは交換したのですか？（価格は？）

ローカルで、サーバー　いじって（実験して）みたいです。

現在：
デスクトップ、ペンティアム４ (1.5GHz?) Vine Linux 4.2
ノート、iBook PowerPC600MHz MacOSX 10.3.9

があるのですが、サーバー用にあと１台 と考えています。
元ねた  返信 1141   書き込む

1139. Re. 1138. Re. 1137. Re. 1136. 解析：Ruby関数電卓
紫藤May 08, 2008
うえま さん

また何か質問があったらお気軽に書き込んでください。

よろしくどうぞ
元ねた  書き込む

1138. Re. 1137. Re. 1136. 解析：Ruby関数電卓
うえまMay 08, 2008
紫藤さま

＞ls[start, length] と ls[start .. end] 
＞はどちらでも正しいです。

ls[start, length]　とした時、ほとんどの場合要素数を超えて範囲指定。結果は同じ。
ls[start...length] （.「ドット」が三つ）の場合、ぴったり範囲が合います。気持ちがいい。

たしかに、どちらも正しい結果が得られますが、厳密にはリストの長さの範囲を超えています。

----
$ irb
irb(main):001:0> a=[0,1,2,3]
=> [0, 1, 2, 3]
irb(main):002:0> len = a.length  ←　配列の長さは、４
=> 4
irb(main):003:0> a[1,len]    ←　a[1],a[2],a[3],a[4]:厳密には、a[4]は冗長
=> [1, 2, 3]
irb(main):004:0> a[1...len]  ← （ドット３個） a[1],a[2],a[3]:範囲は、ぴったり
=> [1, 2, 3]
irb(main):005:0> a[1, 1000000]  ← a[1]〜a[1000000] でも同じ結果だが、、、
=> [1, 2, 3]
irb(main):006:0> 
----

どちらも結果は、正しいが、、厳密には範囲指定はオーバーしています。

「,」でも「.  .  .」でも　Ruby関数電卓の動きは、まったく同じなのですが、、、

厳密には、「.  .  .」　　　この方が、、、、　　　　どーでもいいですネ！！！
元ねた  返信 1139   書き込む

1137. Re. 1136. 解析：Ruby関数電卓
紫藤May 08, 2008
うえま さん
こんにちは

ls[start, length] と ls[start .. end] 
はどちらでも正しいです。

どちらの場合も length や end が配列の範囲を超えたときには、
start から配列の最後の要素までの部分配列が返されます。

紫藤は ls[start, length] で統一しましたが、好きなほうを使えばいいと思います。
元ねた  返信 1138   書き込む

1136. 解析：Ruby関数電卓
うえまMay 08, 2008
紫藤さま

まだ、完全な理解にはなっていませんが、Rubyの関数電卓を調べました。

紫藤さまのコードは、間違ってはいませんが、厳密に正確ではない箇所を見つけました？
うえま　の勘違いかもしれませんが、、、

いずれも次のように配列の範囲指定の部分が、気になりました。

後半部分で、紫藤さまのコードの訂正箇所？？をコピーペーストします。

訂正箇所は、いずれも
ls[a,b]の部分を、ls[a...b]のように記述するのが正確だと思います。
（1...4 は、4 を含まず、1,2,3 のこと）


---
def read_input(s0, ls=[])

  s0.strip!

  if s0.length==0 then
    return ls
  end

  m=$r_fe.match(s0)
  if not m then 
    raise "cannot parse input"
  end

  if m[1] then
    j=find_close(s0)
    read_input(s0[j+1, s0.length], ls << read_input(s0[1, j-1]))
  elsif m[2] then
    read_input(s0[m.end(2), s0.length], ls << (m[2].match(/^\d+$/) ? m[2].to_i : m[2].to_
f))
  elsif m[3] then
    read_input(s0[m.end(3), s0.length], 
               ls << H_OP[ 
                          ((m[3]=='+' or m[3]=='-') and 
                          (ls.length==0 or ls[-1].class== Operator)) ?
                          '@' + m[3] : m[3]
                         ])
  end
end
は、、、、、、

def read_input(s0, ls=[])

  s0.strip!

  if s0.length==0 then
    return ls
  end

  m=$r_fe.match(s0)
  if not m then 
    raise "cannot parse input"
  end

  if m[1] then
    j=find_close(s0)
    read_input(s0[j+1...s0.length], ls << read_input(s0[1, j-1]))
  elsif m[2] then
    read_input(s0[m.end(2)...s0.length], ls << (m[2].match(/^\d+$/) ? m[2].to_i : m[2].to_
f))
  elsif m[3] then
    read_input(s0[m.end(3)...s0.length], 
               ls << H_OP[ 
                          ((m[3]=='+' or m[3]=='-') and 
                          (ls.length==0 or ls[-1].class== Operator)) ?
                          '@' + m[3] : m[3]
                         ])
  end
end
の方が、正確だと思います。
---

---
def fappend(ls, val, pos1, pos2)
  return (ls[0, pos1] << val) + ls[pos2, ls.length]
end
は、、、、、、

def fappend(ls, val, pos1, pos2)
  return (ls[0, pos1] << val) + ls[pos2...ls.length]
end
の方が、正確だと思います。
---

まだまだ、理解には至っていません。
勉強続けます。

Python版もRuby版の次に勉強したいと思います。
元ねた  返信 1137   書き込む

1135. Re. 1134. Re. 1133. Re. 1132. Re. 1131. Re. 1130. Ruby関数電卓
うえまMay 07, 2008
紫藤さま
プログラミング修正：早いですね！！　スクリプト勉強続けます。
元ねた  返信 1136   書き込む

1134. Re. 1133. Re. 1132. Re. 1131. Re. 1130. Ruby関数電卓
紫藤May 07, 2008
うえま さん

ご指摘ありがとうございます。
calc.rb を修正しておきました
元ねた  返信 1135   書き込む

1133. Re. 1132. Re. 1131. Re. 1130. Ruby関数電卓
うえまMay 07, 2008
紫藤さま

pi と e も単独では、エラーになります。


> pi
#<NoMethodError: undefined method `is_const' for #<Operator:0x1ef50>>
> e
#<NoMethodError: undefined method `is_const' for #<Operator:0x1ef00 @name="e", @priority=
6, @fun=2.71828182845905>>
>
元ねた  返信 1134   書き込む

1132. Re. 1131. Re. 1130. Ruby関数電卓
うえまMay 07, 2008
C の方も Ruby と Python で表示が違います。
元ねた  返信 1133   書き込む

>> more