アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
動作が軽い? or お手軽? [意味] (スコア:1)
動作は重いものが多いもんね、スックっリップっトな処理系は。
「お手軽」という意味で「Lightweight Language」と呼称ってる?
のかな?
_
# CheapGbE!GbE!!TheKLF!KLF!!TheRMS!RMS!! And a meme sparks...
Re:動作が軽い? or お手軽? [意味] (スコア:1)
Re:動作が軽い? or お手軽? [意味] (スコア:1)
実装がお手軽だということは否定できないけど。
参考にしたいので、どのように「言語のシンタックスやセマンティクスにもうちょっと気を配ってほしい」か聞かせてもらえませんか。
S
まつもと ゆきひろ /;|)
Re:動作が軽い? or お手軽? [意味] (スコア:1)
努力(^^;をしたかどうかはともかくとして、結果を評価するという意味ではRubyは「いけてる言語」だと思います。
ええ。かつて誰かがJavaを「いけてる言語」と評したのと同じ意味で(^^;。
つまり、豪快に超革新的なことは敢えて避けてるっていうか、一番の(プラスな)評価点は「落とし所」の旨さだ、というか。
>実装がお手軽だということは否定できないけど。
むしろ誉め言葉かも。
つまるところRubyは「必要最低限の実装」は出来てるわけですよね。
だったら、言語の改良に対する足枷を少なくするという意味で(も)、
言語のハラワタもまた軽量アジャイルであるに越した事ないですよね。
#「トラだ。トラだ。お前はアジャイルなトラになるのだー」なのでG7
>どのように「言語のシンタックスやセマンティクスにもうちょっと気を配ってほしい」か
Rubyについては、まあ個人的(つまり解釈の余地がある)かつ枝葉末節(つまり根本的じゃない)な「点」しか
思い浮かばない俺でした。
#どっちかといえば「require unix」のほうが重大事だと思ってます:-)
#どの拡張ライブラリをmake時にruby本体に組み込めるか?を選択できるんでしたっけ?
#もし出来るなら、unix臭い機能を拡張ライブラリに追い出し、Unix用configureで本体に取り込めば、それで済むような気(素人考え)が…
>SchemeやOCamlのような形式的意味を論じることができる(or できそうな)言語がお好みだと、
>多くのLLは好みではないのかもしれませんが、それは「消費脳力」の削減とは直接は関係ないですよね。
消費脳力の「測定」方法については、異論の余地があるような気がしています。
人によってはむしろScheme方式のほうが早いっていうか、
「どの」部分に脳力が食われるかは脳の個人差にかなり依存する「可能性がある」んじゃないか
という疑問があるんです。どうなんでしょう?
#ま、定量的に調べたデータがあると、議論はすぐに終結しそうですが。
最近気になっているのが「ちょっと考える」というキーワードです。
「ちょっと考えれば判ること」って奴です。
全く何も考えなければ判りにくいけど、「ちょっと考える」ことで小さい山を1つ越えれば、
そこから先は妙に見通しが良くなる、というものは世の中に色々あるわけです。
#何も考えなくても判るくらいに簡単なものしか許容できない人相手に困り果てることが多いんでG7(T_T)
#「ちょっと考える」ことはとても大事だと思うんだよな。
で、どの程度だと「ちょっと」だと言えるのか?が、どうもよく判りませんでして。
しかも、人類共通に一意に言えることなのか、それとも個人差が大きいのか…??
例えば、endより閉じカッコのほうが、もしかして脳力は使わないんじゃないかな?とか(^^;。
#これは形式云々とも通じる話かと思いますが。
ええと。rubyのendって、endに対応する構文単位開始の単語は、「覚えなくても済む」のでしたっけ?
ついつい、endは ifとかwhileとかdoとかの色々なものを閉じるから、相方(しかも重婚)を「覚え」ないとならないよな、
と身構えてしまうんですが。
Re:動作が軽い? or お手軽? [意味] (スコア:1)
>「どの」部分に脳力が食われるかは脳の個人差にかなり依存する
>「可能性がある」んじゃないかという疑問があるんです。
>どうなんでしょう?
当然だと思います。もし人の脳力消費パターンが同一なら、
世の中には唯一の言語があればよいですが、そうではない。
だから、自分に合っている言語を探し求める楽しさがあるの
ではないかと。
>ええと。rubyのendって、endに対応する構文単位開始の単語は、
>「覚えなくても済む」のでしたっけ?
そうです。「)」が「end」で置き換わっただけです。
>ついつい、endは ifとかwhileとかdoとかの色々なものを閉じるら、
>相方(しかも重婚)を「覚え」ないとならないよな、と身構えてしまう
>んですが。
杞憂です。
まつもと ゆきひろ /;|)
Re:動作が軽い? or お手軽? [意味] (スコア:1)
>当然だと思います。もし人の脳力消費パターンが同一なら、
ふむ。
「matzさんが」そう言うということは、
やはり例の Ruby web頁でのC++に言及したあの文(笑)は、
「消されるべき」必然は「無かった」と言えますね。
#いや、誰が書いたかは、もちろんどうでもいいんですが。
で、lispが標的になる(笑)のも、あくまでmatzさんローカルな発想であって、
我々他人から見ればあくまで「そういう人もいる」という一例でしかない、と。
>>ええと。rubyのendって、endに対応する構文単位開始の単語は、
>>「覚えなくても済む」のでしたっけ?
>そうです。「)」が「end」で置き換わっただけです。
いや、そうじゃなく、endの相方の話です。
ifとかなんとかとか「色々ある」じゃないですか。
pascalみたいにbegin一発ならすっきりしたんですが…
Re:動作が軽い? or お手軽? [意味] (スコア:1)
>
>いや、そうじゃなく、endの相方の話です。
>ifとかなんとかとか「色々ある」じゃないですか。
そっちは「if」を「(if」で置換してください。
まつもと ゆきひろ /;|)
Re:動作が軽い? or お手軽? [意味] (スコア:1)
ええと。"幾つの"単語を置換する必要が有るんでしたっけ?…という話です。
#ちょっと唖然としましたが、それはともかくとして。
#あとカッコの位置のせいで「Lispか?」とも思ったり。
#覚えきれなくて「毎日」リファレンスマニュアル見てるのでG7
Re:動作が軽い? or お手軽? [意味] (スコア:1)
>…という話です。
元のメッセージからはとてもそのようには読み取れませんでしたが。
参考までに、endと対応する単語の数は11個です。
begin, case, class, def, do, for, if, module, unless, until, while.
まつもと ゆきひろ /;|)
Re:動作が軽い? or お手軽? [意味] (スコア:1)
それは失礼しました。
>11個
ちょっと冗談抜きに呆然としました。
Re:動作が軽い? or お手軽? [意味] (スコア:0)
Re:動作が軽い? or お手軽? [意味] (スコア:1)
私にはなぜ呆然とされたのか、よくわかりませんでした。
まつもと ゆきひろ /;|)
Re:動作が軽い? or お手軽? [意味] (スコア:1)
いや、単純(?)に「少ない方が」良いと言いたいわけではないです。
少なすぎたらLispみたいな方向性になっちゃうわけで、
それもまた脳力を結構浪費するなあという意見には賛成します。
じゃあ何なのか?ってーと、「多すぎず、少なすぎず」であることが
能力の節約には役立つんだろうと思うんです。
で、Lisp(1通りのカッコで全てを表現。あとは単語ごとの語彙によって動作が決まる(笑))
は少なすぎて疲れるけど、一方で11個は逆に多すぎて疲れる、と思ったんです。
3つか5つくらいならまだ許せるかなーと。
>それは「lightweight」であることと関係があるのでしょうか。
というわけで、「多すぎず少なすぎず」が満たされてるかどうか
という点で、絡んでくるのだと思います。
まあ、何個を以って「程好い」とするかは一意に言えるわけではないですがm(__)m
余談:
直接的な脳力もそうなんですが、あと、入出力の問題は、どうしたものか?と思っています。
というのは、典型的にいえばソースを書くエディタに「どれだけの」機能を要求するか?という問題でして。
例えばCみたいに「{}」な言語だと、viの「%」みたいなカッコ追跡機能が
無いエディタじゃ、やってられんし。
例えばRubyみたいな「11個の単語」と「end」とが対応する言語では
それらの対応を知っててくれるエディタじゃないとやってられん。
で、それぞれの要件を満たさないエディタでコーディングをしちゃうと、
能力(この場合は小脳力?)は、思い切り浪費されるわけですね。
いや、エディタ入れればいいじゃん、といえばそれまでなんですが…
#Windowsのメモ帳でXML、は勘弁して欲しかったのでG7
Re:動作が軽い? or お手軽? [意味] (スコア:0)
Re:動作が軽い? or お手軽? [意味] (スコア:1)
>僕の頭にやさしかったのに。
そう思います?
読むだけならそうかもね。
でも、編集するとき大変そう。
いつも対応を維持しないといけないから。
まつもと ゆきひろ /;|)
OCR的処理 (スコア:1)
OCR的処理のコストという点に限ればその通りでしょう .
しかし , 単語としての姿は ,
他のオブジェクトとシームレスである事を顕在化します .
その認識は制御構造を構成する他の部品にも及びます .
そこからどこまでも降りて行けます .
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )