Lightweight Language Magazineが発売に 62
ストーリー by Acanthopanax
軽快強力 部門より
軽快強力 部門より
Coo-Neruasobu曰く、"Perl、PHP、Python、Rubyの各コミュニティが合同で開催した昨夏のLightweight Language Saturdayを覚えていますか？LLな集まりが今度は、「Lightweight Language Magazine」となって書店に並びました。
- Language Update
- LL とオブジェクト指向
- 「お題プログラムで競う」! キミならどう書く?
- LL ドキュメントはこう使え
- LL ライブラリはこう使え
他、Lightweight Language適性検査やSqueak、Haskell、Emacs Lispの名前もあります。" (つづく…)
"買って帰ってぱらぱらと読んでみましたが、例えばPHP一つを取っても、PEARやPHP流のコーディングアプローチとPHP-wayが学べるステキな内容になっており、これが四つ並ぶ事でそれぞれの言語のアプローチを総覧しつつ美味しくいただける大変満足度の高い仕上がりになっています。LLな人だけでなく初学者や独学で学んでいる人、ある言語から次の言語に踏みだそうとしている人にも是非おすすめしたい、楽しみのある一冊です。"
最近のスクリプト言語の興隆をみて思うこと。 (スコア:3, 興味深い)
文法と機能が分離できていないことです。例えば、ある言語の文法が気に
入っていたとしても、その言語には自分の必要とするライブラリが充実し
ていない、という理由だけで、別の言語でスクリプトを書かなければいけ
ない、という場面が多くなりつつあります。
要するに、スクリプト言語のライブラリの再利用性は、そのスクリプト言
語に閉じてしまうのです。これは、色々な意味で勿体ないと思いませんか？
例えば、 XMLのライブラリは、Ruby, Perl, Gauche, などなど、同じ機能
を持つものを幾つ勉強しなければいけないんでしょう？また、同じ機能を
持つライブラリを多くのスクリプトで用意することで、どれくらいフリー
ソフト界の人的資源が無駄になるのでしょう？
また、ソフトウェアの機能拡張方法として、各ソフトウェアがばらばらに
異なる文法のスクリプト言語を提供しているのも明らかに異常です。
sawfish のrep しかり、emacsのelispしかり、HTMLのjavascriptしかり
（これは国際規格化されてますけど）… 最近はわりと小さなソフトでも、
独自の構文のスクリプト言語を備えています。ソフトウェアの機能を拡張
するために、新言語を覚えさせるという負担を、何の罪もないユーザに強
いさせて、これらのソフトの作者は何とも思わないのでしょうか？
この点で、あきらかにUnixはWindowsに劣っています。Windowsでは、まが
りなりにも、WSHというフレームワークで、好きなAPIを好きな言語で呼び
出せます。ActiveScriptRubyで、Wordの文書に対してgrepができる、その
ような仕組みがまだまだUnixでは未熟ですよね。
どうか、スクリプト言語の元来の利点である「手軽さ」と「保守改造のし
やすさ」が生かされるよう、そして、様々な言語で書かれた小さいソフト
ウェア部品が、他の言語からでも気軽に呼び出せるよう、そして、機能を
拡張したいと思うたびに、新しい言語を習得する、という歪んだ負荷に苦
しむこともなく、様々な人々の作ったコードを気軽に組み合わせて、楽し
んでハッキングができるという、そんなコンポーネントフレームワークが
早く実現しますように…
＃ Bonobo（CORBA）に期待していいのか？やっぱり駄目なのか？
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:2, 興味深い)
いろんな思想の言語にいろんな思想のインターフェイスが存在している。これは統一したくないのではなくて、それぞれの「特徴」があるからでしょう。特徴には雑多なものがあり、良いものも悪いものもあるけれど、「決定版」的スタンダードが存在しないために、統一ができない。そういったことなのではないかと。そういった状態で無理に統一しようとすれば、磨擦が起きるか従わないものが出るだけなんで、統一する意味がないし。たとえばJavaとRubyで同一のAPIが作れたとしても、やっぱりどっちかにとって不便なことってあるように思う。
幸い今時の言語の多くは「汎用」なので、「適材適所」言い訳につまみ食いするのではなくて、どれかの言語に腰を据えてその言語の流儀を身につけながら、いろんな「機能」を実装して行くというのが、個人的な近道なのではないかと思います。
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:2, すばらしい洞察)
メディアプレイヤーのスキンエンジンがIEのコンポーネント(というか確かIEの1つ下のレベルのコンポーネントだったっけ？)を使って書かれているのには感心しました。
LLの連携に関しては他にParrotやJVMなどが期待できるでしょうか。
しかし一方UNIXの方もアプリケーションの連携という点では劣っているようには思えません。
確かにGUIのプログラムに関しては連携性が低いと思いますが、CUIアプリケーションやデーモンについてはかなり柔軟に各プログラムが連携されていると思います。
Windowsが優れたフレームワークで連携しているのに対し、UNIXではしっかり設計されアプリケーションで連携しているという状態でしょうか。
XMLの例で言えばWindowsでは共通のライブラリを使って操作を行い、UNIXではXSLTスタイルシートを生成したり、XSH [sourceforge.net]をパイプを使って操作するといったスタイルでしょうか。
そしてUNIXはCUI文化なので普段ユーザーが行っている操作そのものをスクリプトとして書けるというのも、簡単に連携させることができるという印象を与えているのかもしれません。
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:1)
＞負担を、何の罪もないユーザに強 いさせて、これらのソフトの作者
＞は何とも思わないのでしょうか？
そういうソフトの作者は，たぶん新しいプログラミング言語をマスターするのは負担でも何でもない（むしろ楽しい）ので何とも思わないでしょう．WSHみたいな言語で統一されるよりは，面白い言語がうじゃうじゃとある方を好むのではないでしょうか？
# 関係ないけど「言語をおぼえる」という表現にはすごく違和感を感じます．
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:1, すばらしい洞察)
アプリケーション拡張言語に関しては、そういう「マイ言語」乱立の弊害はずーっと言われていて、「統一しちゃる」って言語が次々出ては、one of themになってゆく…って状況じゃないですかね。 Tclだって最初はその状況を何とかするって触れ込みだったでしょ。
今までそれが成功した言語が無いってことは、やっぱり一つで全てをカバーするのが無理ってことなんじゃないのかなあ。
ただ、ライブラリバインディングの言語間の差異、というのは、それほど問題じゃないように思います。例えばコンポーネントをオブジェクト指向で見せているバインディングなら、どの言語を使ってもだいたい使いかたの類推が効くでしょう。しかし、普通のオブジェクト指向しか見たことが無い人が関数型のフレームワークを使おうとしたら、たとえ使い込んだ言語であってもやっぱり戸惑うんじゃないでしょうか。問題になるのはそういうパラダイムレベルでの差であって、そのへんをどれかに統一して表面だけいろいろの言語が使えますよって言っても、あんまり嬉しくないんじゃないかと思います。
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:1)
＞ソフトウェアの機能を拡張するために、新言語を覚えさせるという負担を、
>何の罪もないユーザに強いさせて、これらのソフトの作者は何とも思わないのでしょうか？
私は『なんとも思っていないことはないじゃないか』と思いながら使っています。
これはその拡張言語がCだったりPascalだったりあるいはPL/Iなどの有名言語であれば良いのかもしれませんが、ユーザがどの言語ユーザかは分からないわけで、その中で開発者はそれぞれ良いであろうと思う方法論で実装してくれているんだ、と…。
emacsの場合は、lisp使いがエディタを作って、拡張はlispでやってねって事な訳で。
CPUにも同様なことがやっぱり言えて、わざわざ新しい命令・モード増やすな！とか言うのに近くなってしまうと思うのです。まあ、transmetaのcrusoeとかはコードモーフィングでx86互換にしているということもまた一方であるわけですけど。
まあユーザは『言語拡張しなくても良い機能ふんだんのアプリケーションを作って。バグは無しでね』っていうでしょうけど（笑）
/* Seeds */
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:1)
その辺は、あちら立てればこちら立たず、なんじゃないかなあ。
例えば、なんでもかんでもライブラリ(プラグイン)化しようと思ったら、
Schemeみたいに素っ気無い言語仕様になっちゃうわけだよね、とか。
あとは自動化ですかね。SWIGって使ったこと無い(話に聞いたことしかない)んですが、
あっちとこっちの繋ぎのコードは、何らかの手段で自動生成する方向に
出来るだけ持っていきたいものです。
＃あんまり自動化しすぎると、今度はメタな仕組み自体が長大になっちゃったりするが。
＃とりあえずオブジェクトと無名関数が無い(or自作もできない)言語は却下なのでG7
>独自の構文のスクリプト言語を備えています
言語を"使う"環境が…ええと、こういうのは「コモディティ」とかいうんだっけか…化していない、
ということなんでしょうかね。
そういやJava畑にはJavaScriptingFrameworkだかいう(名称うろ覚え)のが出てきたんでしたね。
なにかってーと、「色々な(^^;」言語をJava上に簡単に載せれるようにするというFramework
なんだそうで、つまり言語は益々増えることを許容(どころか歓迎？)してるんだな(^^;
>同じ機能 を持つものを幾つ勉強しなければいけないんでしょう？
他言語用の既存のライブラリを、別の言語に「できるだけそのまま」移植する、
っていう方向性はアリだと思います。はい。
ただ、せっかくその言語を使ってるなら、こういうこともしないと馬鹿馬鹿しいよね、
というような面はあります。
たとえばRubyだったらイテレータも使うようにしないと空しいね、とか。
＃某OODBのTransaction用APIをイテレータでラップしたのでG7
>ActiveScriptRubyで、Wordの文書に対してgrepができる、その ような仕組み
Unixは、(良し悪しはさてき)「逆」ですね。
アプリごとの「データの」差異を無視する(^^;方向性というか。Wordだなんだという区別を無視する世界。
乱暴にいえば「なんでもテキスト」の世界だったりするわけです。
で、同じテキストというクラス(?)なもんだから、どこまでいってもGrepだけで話が済むとか、そういう発想。
…まあ俺も無理を感じますけどね。
なので、俺の解釈としては、Unixが「劣っている」のだとすればそれは
「色々なデータ形式」という考え方が薄いという点が劣ってるんだと思っています。
陳腐な言葉でいえばマルチメディア(藁)という発想がUnixには無いわけで。
ただ、データをパイプで流すだけの世界だと、Objectみたいに自在にNetwork構造を組むことが出来ないんで、
メディア以前の問題ではありますね。
やっぱり「パイプ(による部品化)じゃvi(を作るのに使えるような部品)は作れない」わけで…
あと、一方で、じゃあWindowsなりなんなりならばどんな運用形態にも(^^;対応できるくらいに
柔軟なモデルを提供できているのか？っていうと、それはそれで疑問ですよね。
時期尚早という言葉を使ってる人が居ますが、
逆にいえばWindowsって、良くも悪くも「新化済みの」ものなんじゃないかな。
＃たぶんSmalltalkのモデルのほうがマシだろうな。柔軟性も将来性も。
>Bonobo
Processの壁を肯定したうえで、それを越境するために大きな負担(処理効率も、記述形態も)を抱える
というやり方は、やっぱり無理を感じてます。馬鹿速いCPUで誤魔化してばかりいるのもナンですし。
Smalltalkみたいな方向性のほうが、やっぱり良いと思う。
突き詰めて本格的にやるなら (スコア:1)
プロセッサレベルでの受け入れ態勢が必要でしょう .
せめて中間コードのレベルでの透過性が .
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:0)
> Windowsでは、まがりなりにも、WSHというフレームワークで、
Ruby 256 倍邪道編しか読んでないのでよく知らんけど、
あれって「WSH というフレームワーク」なの? COM とか
OLE とかじゃないの?
なお、内容に関しては #522494 に同意。
関係ないけど、俺は邪道編を読んで、マイクロソフトがちょっと
だけ
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:1)
コメントきぼ～ん (スコア:2, 参考になる)
３月２６日、週刊ライトウェイトラングエイジ創刊 (スコア:2, おもしろおかしい)
Re:３月２６日、週刊ライトウェイトラングエイジ創刊 (スコア:2, 参考になる)
Re:３月２６日、週刊ライトウェイトラングエイジ創刊 (スコア:1)
Re:３月２６日、週刊ライトウェイトラングエイジ創刊 (スコア:0)
Re:３月２６日、週刊ライトウェイトラングエイジ創刊 (スコア:1)
＃私は持ってません。本当です。
言語開発者のフィギュア付き (スコア:1)
創刊号は当然まつもとゆきひろ氏(Ruby),以下Larry Wall氏(Perl),Alan Key氏(Squeak)と続く．
また全巻コンプリートのボーナスとしてRMS氏を予定．
Re:言語開発者のフィギュア付き (スコア:1)
ただ、Larry Wall氏のフィギアならでてますよね。
…なぜか「ルイージ」って説明がついてるけど。
Re:言語開発者のフィギュア付き (スコア:0)
Re:言語開発者のフィギュア付き (スコア:0)
Re:３月２６日、週刊ライトウェイトラングエイジ創刊 (スコア:1)
仕様書に従って("従う"ってのが意味不明だが)毎号組み立てていくと、
数ヵ月後には自分だけの言語が出来上がってる…のでしょうか？
＃仕様書どおりに作ったら"自分だけの(独自の)"言語にならないけど、ね。
＃かといって仕様書を逸脱しつつも破綻せず言語を作れるような人は、そもそもバインダーは要らないし…
＃プログラムって、シビアなんだよなあ。
まあ、それはともかく、内容はともかく(まだ見てませんので)位置付けとしては
萌える本ですね。買わねば。
週刊デスマーチ創刊 (スコア:1, おもしろおかしい)
当然、最終号では仕様変更通知書が入っているんですよね？
Re:３月２６日、週刊ライトウェイトラングエイジ創刊 (スコア:0)
それなら薄型でいいから毎号バインダーを…
Re:３月２６日、週刊ライトウェイトラングエイジ創刊 (スコア:0)
# 紙１枚
Re:３月２６日、週刊ライトウェイトラングエイジ創刊 (スコア:0)
#16年以上かかるけど
てゆーか重量言語逝ってよし (スコア:2, 興味深い)
最近どうも俺は、重量言語の存在意義を疑ってます。
つまり言語の殆どは軽量であるべきなんじゃないか？と。
もちろん、軽量にすることで失うものも有る、という場面も有るので、
(たとえば、パフォーマンス的に不利になりやすい言語仕様(の導入)とか)
それはそれなんですが、
それとは別に、単純に「無駄」なんじゃねーの？と思えてならない重量級の言語仕様
というものも見受けられるようなので。
たとえばProthonの時に述べたように、new Classname() という書き方の
存在意義なんて、無い筈なんです。Classname.new()でOKじゃん [srad.jp]…とかね。
new Classname() という書き方は、ものごとの解釈を無用に硬直させてるんじゃないか？と。
コンストラクタのための構文なんてものを別途用意するから、構文のための決まりごとを色々導入しないとならなくなる。
自分で穴掘って自分で埋めてるみたいな感じです。
他にも例を挙げるなら、
○C言語の「()」と「{}」の区別。式なのか否かを「厳密に」分けることに価値が有るんだろうか？「()」の中でgotoと書きたくなったり、「{}」の中から値を返したくなったりしたことは無いかい？
○C++…きりがないので割愛(藁
とか、
言語仕様が大きいんだけど、大きくした(=制限を導入した)ことで何か得るものが有るかってーと、
特にない、っていうことが結構有るなあと。
現物を見てないんですが、 (スコア:1)
いわゆるムックってやつでしょうか？
いや、値段が2000円だから、これが毎月ならとても無理だと思ったもので。
動作が軽い？ or お手軽？ [意味] (スコア:1)
動作は重いものが多いもんね、スックっリップっトな処理系は。
「お手軽」という意味で「Lightweight Language」と呼称ってる？
のかな？
_
# CheapGbE!GbE!!TheKLF!KLF!!TheRMS!RMS!! And a meme sparks...
Re:動作が軽い？ or お手軽？ [意味] (スコア:1)
Re:動作が軽い？ or お手軽？ [意味] (スコア:1)
実装がお手軽だということは否定できないけど。
参考にしたいので、どのように「言語のシンタックスやセマンティクスにもうちょっと気を配ってほしい」か聞かせてもらえませんか。
SchemeやOCamlのような形式的意味を論じることができる(or できそうな)言語がお好みだと、多くのLLは好みではないのかもしれませんが、それは「消費脳力」の削減とは直接は関係ないですよね。
まつもと ゆきひろ /;|)
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 お手軽？ [意味] (スコア:1)
私にはなぜ呆然とされたのか、よくわかりませんでした。
まつもと ゆきひろ /;|)
Re:動作が軽い？ or お手軽？ [意味] (スコア:1)
いや、単純(?)に「少ない方が」良いと言いたいわけではないです。
少なすぎたらLispみたいな方向性になっちゃうわけで、
それもまた脳力を結構浪費するなあという意見には賛成します。
じゃあ何なのか？ってーと、「多すぎず、少なすぎず」であることが
能力の節約には役立つんだろうと思うんです。
で、Lisp(1通りのカッコで全てを表現。あとは単語ごとの語彙によって動作が決まる(笑))
は少なすぎて疲れるけど、一方で11個は逆に多すぎて疲れる、と思ったんです。
3つか5つくらいならまだ許せるかなーと。
>それは「lightweight」であることと関係があるのでしょうか。
というわけで、「多すぎず少なすぎず」が満たされてるかどうか
という点で、絡んでくるのだと思います。
まあ、何個を以って「程好い」とするかは一意に言えるわけではないですがm(__)m
余談：
直接的な脳力もそうなんですが、あと、入出力の問題は、どうしたものか？と思っています。
というのは、典型的にいえばソースを書くエディタに「どれだけの」機能を要求するか？という問題でして。
例えばCみたいに「{}」な言語だと、viの「%」みたいなカッコ追跡機能が
無いエディタじゃ、やってられんし。
例えばRubyみたいな「11個の単語」と「end」とが対応する言語では
それらの対応を知っててくれるエディタじゃないとやってられん。
で、それぞれの要件を満たさないエディタでコーディングをしちゃうと、
能力(この場合は小脳力？)は、思い切り浪費されるわけですね。
いや、エディタ入れればいいじゃん、といえばそれまでなんですが…
＃Windowsのメモ帳でXML、は勘弁して欲しかったのでG7
Re:動作が軽い？ or お手軽？ [意味] (スコア:1)
>僕の頭にやさしかったのに。
そう思います？
読むだけならそうかもね。
でも、編集するとき大変そう。
いつも対応を維持しないといけないから。
まつもと ゆきひろ /;|)
OCR的処理 (スコア:1)
OCR的処理のコストという点に限ればその通りでしょう .
しかし , 単語としての姿は ,
他のオブジェクトとシームレスである事を顕在化します .
その認識は制御構造を構成する他の部品にも及びます .
そこからどこまでも降りて行けます .
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
ネタにマジレスかも知れませんが (スコア:1)
新記号を採用するタイミングはいよいよとなってから ,
としないと死が待っています .
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
LaTeX (スコア:1)
で、p.13に：
ってあるけど、一体どういうつもり^H^H^H意味なんだろう?
胃袋に届く前のマクロ展開（＋パターンマッチング能力）でどうにでもなる話だと思うのだけど。
だれか教えて。
Re:LaTeX (スコア:1)
とりあえず、ハノイの塔は解けるみたい [kernelthread.com]ですねぇ＜TeX
Re:LaTeX (スコア:1)
ただ、軽量であることは弱みでもあれば強みでもあり、
強みとして一番目立つのはやっぱり
「訂正もまた楽」
であるという点だと思われます。
つまり間違いがあったらとっとと訂正すればいい。
…のですが、そういう意味では、Webより書籍/雑誌のほうが
軽量(アジャイル)さにおいて劣るんですよね。
そういう点では、雑誌の出現は痛し痒し。
＃非アジャイルとのバランスという意味では、「Delphiマガジン」が許容範囲の精一杯かな、という気がしてるのでG7
あ。昨日やっと買いましたが、中身は概ね気に入っております。概ねね。
Re:LaTeX (スコア:1)
本当はNTT latexの作者の磯崎さんのstyファイルなどから\while マクロ あたりの存在を確かめてあのコメントを書くはずだったんですが、見つからないまま見切り発車で書いたちゃったので僕のもlightweightです。もうみんなこういうスタイルだ。
> ただ、軽量であることは弱みでもあれば強みでもあり、
> 強みとして一番目立つのはやっぱり
>「訂正もまた楽」
> であるという点だと思われます。
それはLightweight langaugeの特徴を(も)うまく言い表しているようですね。
ある言語から次の言語に踏みだそうとしている (スコア:0)
いまひとつ (スコア:0)
本の内容まで らいとうぇいと にすることないのに...。
次回（があるなら）に期待。
Re:いまひとつ (スコア:1)
どれくらい薄いって、それ以外の感想が持てる程の情報がないくらい薄い。
結構期待したのに。
matzさんの (スコア:0)
ホントによく似てますね。