5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Booについて語るスレ【CLI】

1 :デフォルトの名無しさん:2010/05/12(水) 11:05:35
Booは.NET Framework/Mono上で動作する
Pythonライクな静的型付け言語です。

公式
http://boo.codehaus.org/

参考
http://ja.wikipedia.org/wiki/Boo_%28%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%29
http://www.asahi-net.or.jp/~sy7a-ht/diary/tut_boo.html
http://www.infoq.com/jp/articles/dsl-on-the-clr
http://d.hatena.ne.jp/coma2n/20080820/1219207907

2 :デフォルトの名無しさん:2010/05/12(水) 11:08:51
http://blog-imgs-40.fc2.com/t/s/u/tsuba3555/41gsqAdAmmL.jpg

3 :デフォルトの名無しさん:2010/05/12(水) 11:39:47
http://blog.livedoor.jp/boo_takagi/

4 :デフォルトの名無しさん:2010/05/12(水) 12:26:03
名前がダサいので日本では流行らない

5 :デフォルトの名無しさん:2010/05/12(水) 13:04:07
下手に拡張すると汚くなる。
元のpythonがきれいなので余計汚く見える。

6 :デフォルトの名無しさん:2010/05/12(水) 13:49:08
まあ、マクロ機能による構文の拡張は自前のニーズにとどめておいて、
フレームワークやライブラリ自体は公式サポートの範囲で構築した方がいいだろうね。

7 :デフォルトの名無しさん:2010/05/12(水) 19:17:25
>>1
boooooooooo!!!!!!!!!!!

8 :デフォルトの名無しさん:2010/05/12(水) 20:27:29
>>1
boooooooooo!!!!!!!!!!! , too!!!!!!!!!!!!!!!!!!!!!!!!!!!!

9 :デフォルトの名無しさん:2010/05/13(木) 02:15:44
C#に対する利点:
・単独ファイルでのプログラムが比較的書きやすい(Pythonとほぼ同レベル)
・List[]、Hash{}、array()のリテラルが記述しやすい
IronPythonに対する利点:
・起動・実行速度が速い(それはもう、ベンチで比べたら10倍以上……)
・コンパイル時に単純な記述ミスを修正しやすい(静的型付け言語全体の利点)
全体的な利点:
・マクロ機能(動作確認はしたがまだ役に立ててはいない)
C#に対する欠点:
・ジェネレータの実行中にyieldで中断されず、最後まで実行されてしまう?
 (for文(≒foreach)中にbreakはかけられるけど実行中の状態を保存できない?)
・Visual Studioが持つ様々な開発支援機能が受けられない
 (UIデザイナー、DataSource、アプリケーション設定ファイル、etc...)
IronPythonに対する欠点:
・モジュールロード時の動的な処理などは基本的にできない
 (module(namespace)の自由度はC#と同程度なのであまり期待しないこと)
・[]/{}/()の中身がジェネリック型を指定しないとみんなobjectになってしまう
・Pythonとは結局全く互換性がないのでPythonライブラリは使用できないと思え
全般的な欠点:
・記事が非常に探しにくい(Booじゃほとんど全く引っかからん)

10 :デフォルトの名無しさん:2010/05/13(木) 02:17:22
名前は検索性を前提にすべきだってことを
未だに分かってないのかと思う

11 :デフォルトの名無しさん:2010/05/13(木) 17:05:22
>>10
Boo!, bobobobob,, bb, boooooooooooooo!!!!!
bobobbbbbbb!!!

12 :デフォルトの名無しさん:2010/05/15(土) 12:11:30
豚言語

13 :デフォルトの名無しさん:2010/05/15(土) 12:16:29
もしかして>>9だけで終了かこのスレw

14 :デフォルトの名無しさん:2010/05/15(土) 16:39:39
F#と比べてほしかったな

15 :デフォルトの名無しさん:2010/05/15(土) 18:23:41
C# 4.0の登場でBooの特徴も無意味になった。

16 :デフォルトの名無しさん:2010/05/22(土) 02:03:32
>>15
C# 4.0は再頒布パッケージも小さいしね。
これだけで3.5以下の機能がどれだけ使えるのかはやや疑問だけど。

17 :デフォルトの名無しさん:2010/05/22(土) 17:12:24
単体で頑張るというよりは
他のCLIのコードと組み合わせられるのが最大の利点だと思う。

俺はDSLsInBooに書いてあるとおりに
C#から呼ぶスクリプト書くのに使ってみてるよ。


18 :デフォルトの名無しさん:2010/05/22(土) 18:06:56
地味にコンパイラ、インタプリタ、標準ライブラリ全込みで
1.45MBと容量が小さいのがいいね。

C#だけだと動的にスクリプトを動かすということができないから、
単純に文字列で書いた計算式を計算したいといった用途でも使える。

もちろんDLR系でも同じことがいえるわけだけど、
.NET 3.5以前の環境ならランタイムが10MBコースになる。

19 :デフォルトの名無しさん:2010/05/29(土) 20:00:53
週1ペースが確定してきたな。

結局このスレにいる人たちはBooのどこに魅かれた?

自分が惹かれたのは
1. コンパイラマクロ
2. オプションとしてのダックタイピング
3. クロージャ

マクロと型推論がなければ
このタイミングでIronRubyに行ってたと思う。


20 :デフォルトの名無しさん:2010/06/05(土) 22:47:32
>>19
>コンパイラマクロ
まあ便利なことは便利だが、コード量が若干節約できることで
Booとして「できることが増える」わけではないので、ちょっと微妙。
まあmatch〜case構文マクロは常用するかも。

>ダックタイピング
全く使わん。object型を素で使うのと比べて利点は?

>クロージャー
積極的に使っていきたいが、コンパイラが通らない構文がある。
(ハッシュの要素として定義できない)
ラムダ式的なインラインクロージャーの構文があるが、これは式しか定義できないのでちと不便。
(複数文を書くときはセミコロンで区切る)

21 :19:2010/06/06(日) 21:23:41
>20
>コンパイラマクロ
新たなライブラリ作成の武器として使っていきたい(と思ってる)。

コーディング規約や設計のテンプレートを実現する形で
洗練させられれば強力な武器になると思う。

quasi quotation([| ... |]の表記のおかげで相当敷居低いしね。
#これ日本語訳誰か知らない?

>ダックタイピング
俺もコンパイルするコード内で使ってみたことはない。
特に静的型付け+型推論のあるBooでは
1. インタプリタ形式での使用
2. 実行時に生成・評価したいコードの記述(ex: AI記述、設定ファイル)。
3. アプリケーションのスクリプティング環境構築
といったところにピンポイントで使うという位置づけになると思う。
俺は3で使ってみてる。

公式にある「COM連携(duck)」「XMLパーサー, Jsonパーサー(IQuackFoo)」
Ayande氏の「Binsor」あたりのコードサンプルを
実際に見てもらった方がいいと思う。

静的型付けに慣れた人は
言語仕様ガチガチのコードを書くことにストレスを感じないようなので
言葉だけでは平行線になることが多い。


22 :19:2010/06/06(日) 21:24:38
長いので分割。スマン。

>クロージャー
構文は俺も不満が多い。
#そもそもpythonのlambdaでなくrubyのblock形式というところから疑問。

>ラムダ式的なインラインクロージャーの構文があるが、これは式しか定義できないのでちと不便。

俺は逆だなあ。複数文はdef()なりdo()なりで書ければいい。
インライン形式が簡潔でない方がはるかに不満。
具体的には型宣言とreturn文が冗長に過ぎる。
C# : x => (x + 1)
Boo : {x as int| return x + 1}
どちらが light なのかわからない。

lambda x: x + 1 みたいにしてほしい。


23 :デフォルトの名無しさん:2010/06/07(月) 11:01:12
>19
>quasi quotation([| ... |]
macroの定義は書いてみたことあるが、そんなのもあるのか。後で調べてみる。

>ダックタイピング
ま、COM向けだよな……。
>2. 実行時に生成・評価したいコードの記述(ex: AI記述、設定ファイル)。
そんなものはコンパイルしてしまった方がいい。かっこ書きの中の話ね。
とはいえ、スクリプト的なものも確かにある。大規模に動かした場合はどうなるんだろうね。
以前1.5MBのスクリプトを自作のコンパイラを通してIronPythonに変換してDLLにコンパイルしたら
50MBにもなってしまって全く実用にならなかったよ。

初期化処理が重くなく、実行速度で問題なく、
使用メモリがふくれあがっても実行中に開放できるようなら問題なしだね。

>静的型付けに慣れた人は
>言語仕様ガチガチのコードを書くことにストレスを感じないようなので
>言葉だけでは平行線になることが多い。
んなこたぁねえよ。PythonからBooにコードを移植したんだが、
名前付き引数やデフォルト引数がサポートしてなくて非常に難儀した。
せめてデフォルト引数くらい実装してくれよなと。

24 :デフォルトの名無しさん:2010/06/07(月) 11:24:17
>>20
>俺は逆だなあ。複数文はdef()なりdo()なりで書ければいい。
書けないんだよ。Hashのインライン構文の中だと……。

>具体的には型宣言とreturn文が冗長に過ぎる。
>C# : x => (x + 1)
>Boo : {x as int| return x + 1}
>どちらが light なのかわからない。

書ける。
foo = {x as int | x + 1}
print foo(3)
=> 4

25 :デフォルトの名無しさん:2010/06/07(月) 22:06:09
>quasi quotation
名前を知らないだけじゃない?
macro foo(id as ReferenceExpression):
. yield [|
. class $(id)(IBar):
. pass
. |]
の[| |]部分の記法のことだよ。

本当に毎回 new ClassDefinition() とかやってるのなら
マクロを敬遠しても仕方ないが。


>そんなものはコンパイルしてしまった方がいい。かっこ書きの中の話ね。
自分としてはスクリプト的なものの例としてあげたつもりだった。申し訳ない。


>初期化処理が重くなく、実行速度で問題なく、
>使用メモリがふくれあがっても実行中に開放できるようなら問題なしだね。

実行時にコンパイルするなら、Booの静的コンパイル時≒C#レベルの速度はあるはずだよね。
ベンチしたことはないが。

「DSLsInBoo」の12章はスケーリングがテーマで
まさしくStartup time と Memory について取り上げている。
内容の大半は常識的な話だが、作者は15,000個のスクリプトを相手にした経験があるらしい。

ただし。彼のメインフィールドはWeb+DBのアプリのようだから
高度にリアルタイム性の要求されるアプリなら事前コンパイルに頼る他ないかもしれない。


26 :デフォルトの名無しさん:2010/06/07(月) 22:25:57
>書けないんだよ。Hashのインライン構文の中だと……。
ハッシュ+複数行クロージャーをインラインで書くことの重要性はいまだに理解できないが
仮にブレースとコロンの多義性ゆえの問題なら
言語仕様の不具合だよね。

だとしたらやっぱり、クロージャ記法をPython式にしてほしいな。
(ハッシュリテラルをruby式にする方法もあるが)


>書ける。
returnなくてもよかったのか。知らなかった。ありがとう。

でも依然、代入先が定まっているにも関わらず型宣言はいるんだよね。
強力な型推論と簡潔な記法を謳いながら
こうした部分でC#にすら劣るというのは俺は瑕だと思う。


27 :デフォルトの名無しさん:2010/06/08(火) 01:08:06
>実行時にコンパイルするなら、Booの静的コンパイル時≒C#レベルの速度はあるはずだよね。
CLIはモジュールのロード時に全てのクラスとメソッドの
厳密な型チェックを行うので、ロードの処理が全体的に重いんだ。

これがDLRになったら致命的。
C処理系(cpython/cruby)用の大きめなライブラリをロードすると
スタック食い尽くして落ちちゃったりすることもある。

>ハッシュ+複数行クロージャーをインラインで書くことの重要性
GUIのハンドラをメソッド・クロージャとして実装した上でハッシュに登録して再利用可能にする。
これを外部化(XMLファイルだったりハッシュテーブル)したデータを介してスキンと結び合わせる。
この時の照合用のハッシュとして記述している。
クロージャのインライン構文を併用するとカリー化などを使ってメソッドの数を節約できる。

28 :デフォルトの名無しさん:2010/06/18(金) 13:58:20
プログラムがでかくなってきたらだんだんビルドが遅くなってきた。
現在380kbでビルドに約4秒。

ま、IronPythonのビルドに比べたらずっと早いんだけどね。
C#に比べると遅いよなー

29 :デフォルトの名無しさん:2010/06/25(金) 12:15:26
BooのInteractiveInterpreterだが、
どうも動的に生成されるプログラムコードを.NET Frameworkの管理上から削除する方法がなく、
事実上のメモリリークが発生するようだ。

数十回程度の呼び出しなら実用範囲内だが、
何千回も呼び出すようだとやばいっぽいね。

12 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)