アカウント名:
パスワード:
...のようなタコな言語をリファレンスにせずこの辺の磨かれた言語を使って欲しいと思う今日この頃。
だったらSchemeでしょ。
フォントや文字列や色をダイアログでユーザーに問い合わせるようにすることができますが、ファイルを問い合わせることができない。(できるのかもしれないけどどこにも載ってない)。
文字コードをいじったりできない。(できるのかもし
Schemeをキーワードにググってみればすぐにわかるようなことをどうして質問するかなあ？というのは置いといて。
ファイルを問い合わせることができない。(できるのかもしれないけどどこにも載ってない)。 文字コードをいじったりできない。(できるのかもしれないけどどこにも載ってない)。(BASIC でいう ASC() とか CHR$() とかがない。) バイナリファイルの操作ってできるんでしょうか? 例外処理とかエラーハンドリングって、どうなってるんでしょうか?
ファイルを問い合わせることができない。(できるのかもしれないけどどこにも載ってない)。
文字コードをいじったりできない。(できるのかもしれないけどどこにも載ってない)。(BASIC でいう ASC() とか CHR$() とかがない。)
バイナリファイルの操作ってできるんでしょうか?
例外処理とかエラーハンドリングって、どうなってるんでしょうか?
まず、script-fuがSchemeの標準仕様を完全にサポートしているわけではないことを注意しておきます。script-fuはSIOD [indiana.edu]をベースにしていて、これはかなり小さなSchemeの処理系です。継続(continuation)をサポートしていないようですし、define-syntaxもサポートしていないようですので、Schemeのパワーの大きな部分が欠けています。
Schemeがなぜ強力かというのはここ [dreamhost.com]あたりを読んでもらうと良いと思うけれど、言語仕様は必要最小限であると同時に将来の拡張のための機能は十分に用意されている、というところにあるわけです。
言語そのものを趣味とする人にとっては面白いだろうなあとは思いますが。
それはSchemeのせいじゃなくって、GIMPのscript-fuライブラリが未熟だってだけでですよね。
scheme の解説ページを検索してきて、やっとこさ do の存在を見つけたのに、使えなかったりすると、script-fu ってダメダメじゃんって思ってしまったりとか。
再帰じゃだめなんですか？
でも、ループを再帰で書くことを強制することに、どんなメリットがあるのか、わかりません。
んー、Scheme的には何にも強制してなくて、ループ構文が欲しかったらマクロかけばぁ?ってことなんじゃないですか。 末尾再帰が最適化されればループは末尾再帰で書けるけど、 逆はできないから。 (script-fuの問題は処理系の実装の問題ってことで。)
でも実際、「生」のSchemeってやれることが少
とりあえず、きちんと動作するインタプリタの実装を示すことが重要ですから。
ですので、多少の使いにくさは我慢してください、というスタンスだと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
それよりも (スコア:0)
Re:それよりもRuby (スコア:2, 参考になる)
Ruby は元来、普及させるということの大してプライオリティ低めに設定されてるから、意外とこういうアプリケーションへの進まないよなぁ。
Rubyプログラマとしては、なんだかんだいっても残念。もう少しだけ予算費やしてここらへんの競争面白くする価値って無いだろうか。
Rubyはまだマイナーな言語では？ (スコア:2, 興味深い)
世界レベルで見れば python の方が劇的に利用者が多いです。
日本だと、
python は何と発音するのかさえ解らない人が居そうなぐらいは
マイナーです。
python と ruby のどちらが使いやすい言語であるかどうかとか
そういう問題ではなくて、単に使える人が多いから python を
採用しただけでしょう。
ちなみに、プロが使うようなCGやCAD系のソフトでは
pythonでマクロが書けるのは、普通のことです。
デザイナーでもpythonぐらいなら書けないと
生きていけない世界もあるそうな。
Re:それよりもRuby (スコア:1, 参考になる)
濃いひとには Windows でもさくっと使われてはいますが、使い勝手がいいかというといまひとつなのですよね。
WSH機構でPython利用 (スコア:1, 参考になる)
Python for Windows Extensions [python.jp]を導入すれば可能です。
これは結構長く利用されているもので濃くない人でもPythonをWindowsで利用してる人は普通に利用してる物だと思います。
Python Programming on Win 32
[amazon.co.jp]という書籍もでていたりします。
Re:それよりも (スコア:1, 興味深い)
- 内部で完結する処理のためのPython
- 外部と連携するためのインターフェース(WSHとか)
の両方あったほうが便利そう。実装するのは面倒かもしれないけど。Re:それよりも (スコア:0)
それを覚えるために限りある脳細胞、時間を割くのがイヤという人は多かろう。
Blender が Python に対応しているのでもっと増えてくれるのは悪いことではないと。
というか Flash の ActionScript とか独自モデルや Javascript のようなタコな言語をリファレンスにせずこの辺の磨かれた言語を使って欲しいと思う今日この頃。
Re:それよりも (スコア:3, 参考になる)
WSHは言語に依存しません。(一応)
Python搭載といってもどのみちPSP8のオブジェクトの仕様は覚えなければいけないでしょうし、
それならばWSHを介して操作出来るようにして、
言語の選択をユーザが自由に出来るようした方が、
ユーザにとって覚える項目が最小限で済むのでは。
; もちろんPythonも使えます。
将来的に他プラットフォームへの進出を考えているのでなければ
みんな幸せになれるかと。
; #315297 [srad.jp]とは別のACです。
Re:それよりもUNO (スコア:1)
技術的にどっちが優れているかはあまり深くは知らないんでなんともいえないけど、UNO の方がオープンな感じで、好印象なのは間違いない。
Re:それよりも (スコア:0)
ご指摘感謝。JScript と VBScript の他、レジストリを操作する事で Perl が使えるのは知っていましたが WSH が言語に依存しない仕様とは認識していませんでした。
> Python搭載といっても (snip) ユーザにとって覚える項目が最小限で済むのでは。
納得です。ありがとうございました。
Re:それよりも (スコア:1)
だったらSchemeでしょ。
...芸というものは一生勉強だと思っています...
Re:それよりも (スコア:1, すばらしい洞察)
GIMPはPython-Fuの方が強力かも (スコア:1, 参考になる)
PythonはSchemeよりも学習速度は早い言語だと思いますので一度利用してみるとよいかと思います。
GIMPとSCHEME (スコア:0)
フォントや文字列や色をダイアログでユーザーに問い合わせるようにすることができますが、ファイルを問い合わせることができない。(できるのかもしれないけどどこにも載ってない)。
文字コードをいじったりできない。(できるのかもし
Re:GIMPとSCHEME (スコア:2, 参考になる)
Schemeをキーワードにググってみればすぐにわかるようなことをどうして質問するかなあ？というのは置いといて。
まず、script-fuがSchemeの標準仕様を完全にサポートしているわけではないことを注意しておきます。script-fuはSIOD [indiana.edu]をベースにしていて、これはかなり小さなSchemeの処理系です。継続(continuation)をサポートしていないようですし、define-syntaxもサポートしていないようですので、Schemeのパワーの大きな部分が欠けています。
Schemeがなぜ強力かというのはここ [dreamhost.com]あたりを読んでもらうと良いと思うけれど、言語仕様は必要最小限であると同時に将来の拡張のための機能は十分に用意されている、というところにあるわけです。
...芸というものは一生勉強だと思っています...
Re:GIMPとSCHEME (スコア:2, 興味深い)
それだとなんか、
「現在は強力じゃないけど、強力になる潜在力を秘めている」
とかよめてしまう…。
実際にGIMPのSchemeが(他の言語が内蔵された場合と比べて)
どれくらい強力か？って話じゃないのかな。
# 宗教論争の元？
て優香 (スコア:0)
Re:GIMPとSCHEME (スコア:0)
言語そのものを趣味とする人にとっては面白いだろうなあとは思いますが。
Re:GIMPとSCHEME (スコア:1)
それはSchemeのせいじゃなくって、GIMPのscript-fuライブラリが未熟だってだけでですよね。
...芸というものは一生勉強だと思っています...
Re:GIMPとSCHEME (スコア:1, 参考になる)
Re:GIMPとSCHEME (スコア:0)
Schemeの言語仕様として策定されている部分は非常に短く(少なく)、
実際に実用的なプログラムを作成する時に問題になる点は、
処理系に依存する部分になります。
言語として強力だと言われるのは、
継続という概念に基づく制御構造の表現力だと言われて
Re:GIMPとSCHEME (スコア:0)
scheme の解説ページを検索してきて、やっとこさ do の存在を見つけたのに、使えなかったりすると、script-fu ってダメダメじゃんって思ってしまったりとか。
Re:GIMPとSCHEME (スコア:1)
再帰じゃだめなんですか？
...芸というものは一生勉強だと思っています...
Re:GIMPとSCHEME (スコア:0)
でも、ループを再帰で書くことを強制することに、どんなメリットがあるのか、わかりません。
Re:GIMPとSCHEME (スコア:0)
んー、Scheme的には何にも強制してなくて、ループ構文が欲しかったらマクロかけばぁ?ってことなんじゃないですか。 末尾再帰が最適化されればループは末尾再帰で書けるけど、 逆はできないから。 (script-fuの問題は処理系の実装の問題ってことで。)
でも実際、「生」のSchemeってやれることが少
Re:GIMPとSCHEME (スコア:1)
---------- yuzo ----------
Re:GIMPとSCHEME (スコア:0)
とりあえず、きちんと動作するインタプリタの実装を示すことが重要ですから。
ですので、多少の使いにくさは我慢してください、というスタンスだと思う。
Re:それよりも (スコア:1)
で，やはり外界とのインタラクションを行う上で例外処理は重要なものなのですが，Schemeの継続で例外処理を正しく書くのは結構難しいのではないでしょうか．例外の種類によってつかまえるレベルが違う場合や，Javaでいうところのfinally（Common-Lispでのunwind-protect）を実装するのは結構めんどくさいので，組み込みの例外処理機構を加えて欲しいなといつも思っています．
Re:それよりも (スコア:0)
Re:それよりも (スコア:0)
WSH の仕組みを覚えるのも勿体ないと思うしそれに JScript も VBScript も好きこのんで使いたいとは思わん。Perl なども使えるようだがあくまで「出来る」という話で正式にサポートされているわけで
Re:それよりも (スコア:0)
仕様がころころ変わる可能性があるのは同じこと。
それよりも、XMLに対するDOMみたいに、
外部からスクリプトで操るための標準インターフェースみたいなの
を定義したほうが皆が幸せになるんじゃ？
DOMに準拠しているなら、クローズドなMSXMLだろうと
比較的安心して使えるでしょ？