by
Anonymous Coward
on 2003年06月11日 17時37分
(#334975)
たぶん、発端は、MIT AI Lab.が企画したLL1 [mit.edu]という集いで、
そのCall for Participationに定義らしき記述として、
"The term "lightweight" refers not to actual functionality, but to the idea that these languages are easy to acquire, learn, and use." というのがありました。
CPUの負担がLightweightでなく (スコア:1)
その言語の学習やその言語を使用した開発の負担が(比較的)Lightweightということではないかと。
※この手の言語の普及度はCGIとして使用できる環境の多少に
比例するような…だからtcl流行らなかったのか。
演目にシェルスクリプトがないのが少々さびしいですが、これは
｢日本shユーザ会｣がないためでしょうか（ぉぃ
#毎日のログ整理、ネットワーク管理はシェルスクリプトなのでID
Re:CPUの負担がLightweightでなく (スコア:1)
# たぶんそういうことではないと思うけどID
Re:CPUの負担がLightweightでなく (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re:CPUの負担がLightweightでなく (スコア:0)
Re:CPUの負担がLightweightでなく (スコア:0)
「軽量プログラミング言語」ってなんだろう？
Re:CPUの負担がLightweightでなく (スコア:2, 興味深い)
少ない言語だからlightweightという観方はどーでしょか。
手続き的に自然言語に近いほど（高級言語）、人間の日常の概念と
shared object化しやすく、システム全体のメモリ消費を節約出来るとか。
ネット上でスクリプト拾って来て、そのまま中身も理解せずに
使っちゃうので、CPUサイクルの消費も低いとか。（これはスクリプトに限らないな）
しかし、日常の思考空間が、既にアレゲ化している人にとっては、
いわゆる高級言語をさわっていても、中の動きが気になって仕方が無いので、
結局、おつむのlightweightにはならないのかも？？
ゾウの時間、ネズミの時間 (スコア:0)
プログラムや特殊な用途にも対応しているが故に、覚えるのも
書くのも大変になっています。本当にスケーラビリティーが
必要なとき、ぎりぎりの要求に答えなければならないとき、
長く長く使われるプログラムを作りたいときにはいいのですが、
たいていの場合にはオーバースペックになります。
それとは逆に、ありがちな用途で最大限
Re:CPUの負担がLightweightでなく (スコア:1, すばらしい洞察)
私はその「Lightweight」の意味を再考させるレトリックに面白みを感じたりします =)
LL については Ruby の講演で耳にした限りでその後誰と話す機会も持てなかったので理解が不足しているかも知れませんが次のように考えています。
ある一定の投資から得れるコンピューターの処理能力はどんどん増えていますし、数年前に一定を超えて今は場面によっては処理能力が余剰気味にさえなっています。だからここで一旦止まって言語の方向性として「コンピューターの資源を有効利用できる」事から「人的リソースを有効利用できる」事に目を向けてみようという事なのではないでしょうか。
本当に優れた技術者の対価は高いものですし、何より貴重です。
人がこなせる仕事量は一定を超えませんし、より高い価値を排出しようと思えば仕事量の中に効率が求められるハズです。
そこにフィットする道具が LL なのではと思っています。
Re:CPUの負担がLightweightでなく (スコア:0)
Re:CPUの負担がLightweightでなく (スコア:1, 参考になる)
研究者が設計する言語と、実用性重視で設計される言語との間にはだいぶ距離があるので、大学の研究者と実務家がお互いのアイデアを知ることで、何かinspireされる事を見出したい、ということらしいです。
＃つまり、Lightweight≡「処理系がタダで、覚えやすく、使いやすい」？
Re:CPUの負担がLightweightでなく (スコア:0)
門外漢なので口幅ったいのですが Ruby なんて初期コストは高いけど手になじめばなじむほど lightweight になっていくって印象があるのですが。
Re:CPUの負担がLightweightでなく (スコア:0)
# 軽負荷言語と軽労働^H^H負担言語の違い、といったところかな…