Lightweight Language Day and Night 2005 開催 58
ストーリー by yoosee
プログラマのお祭騒ぎ 部門より
プログラマのお祭騒ぎ 部門より
takano32 曰く、 "明日，8/27に
Lightweight Language Day and Night
(通称:LLDN)
が開催されます．
Ruby, Python, Perl, PHPなどに代表される，軽量プログラミング言語の世界を広く体験できるカンファレンスです．
主なプログラムは
各言語の新情報をお届けする「Language Update」，
「フレームワーク対決」，
課題について各言語の実装を発表する「キミならどう書く」，
「だめ自慢」，「デモ自慢」といった内容になっています．
事前に
発表資料も公開されていますので，
参加者は予習してみたり，参加できない方々も雰囲気を楽しんでみてはいかがでしょう．
過去の開催や関連情報についてのスラッシュドット記事: LL Weekend 開催, LL Saturday 開催, LL Magazine 発売"
参加にはチケットが必要で、現在は昼の部のみ若干の空きがあるようだ。ローソンチケット(Lコード 32173)、ないし会場での当日券で1,500円。詳しくはLLDNのサイトを参照のこと。
お願いだから (スコア:3, すばらしい洞察)
from 地方在住者
Re:お願いだから (スコア:1)
私は開催の翌日である今日見ました...orz
しかも、よりによって昨日27日は東京に行ってました...orz
知ってればもちろん行ってましたですよ、はい。
from 地方在住者
Re:お願いだから (スコア:0)
# 夜の部が２４時から開始なら参加出来た同じく地方在住者
Re:お願いだから (スコア:3, 参考になる)
しかも，場所も書き忘れている．
昼が四谷区民ホールで夜がロフト・プラスワンです．
来年も私がタレこむようならもう少し早くタレこみたいと思います．
旅に出ます．(バグを)探さないで下さい．
Re:お願いだから (スコア:1)
/.jが受け付けるかどうかが鍵ですね^^;
Minder
Re:お願いだから (スコア:4, 参考になる)
前から何度も何度も言っているように(^^;、
Storyがもっと長持ちするような仕組みになってさえ居てくれれば、
●必要なタイミング(1ヶ月前なり、今回みたいにチケット厳しいときは告知直後なり)に、スラドにタレコミ＆掲載する
●みんなコメントをつける
●そのあと暫くは沈静する(してもいい)
●当日寸前になったらStory(のコメントつけ)が再燃する
●当日を迎える
…っていうパターンを、めでたく辿ることが出来るのですがね。
そうすりゃ問題は解決するわけじゃん。
スラド(J)のStoryの「寿命」は１ヵ月だから、
今回みたいに告知と開催が数ヵ月開いていて、しかもチケット厳しいときとかは、
現状だと、告知直後と当日寸前の両方にそれぞれStoryを立てる、ということを行う羽目になるわけですが、
それでも、その間の期間については、スラドJはまったくフォローできなくなっちゃうわけで、イマイチです。
(まさか何本も何本もStoryたてるってわけにもいかないしね)
やっぱり
●Storyの寿命を伸ばす
●単なる寿命だけじゃなく、アクセスのしやすさ(？)という面でも、Storyが長く使えるようにする
ってのが必要だと思いますよ。
このへんの「不便さ」については、
それこそOliver氏なりなんなりに、どー思ってるのか訊きたいですねえ。
「改善」する気は無いのかな…
＃それとも逆ギレしてLLDNに文句を言うとか？
＃「スラドJで掲載しにくいようなチケットの作り方をするな！」とかさ(^^;
＃＃まあ今回の夜の部のチケットは、その扱いづらさについて、俺も少々問題を感じたけどね。
＃もしや米国には、こういう形態のイベントは無い、とか？(反語
カレンダーは？ (スコア:2, 興味深い)
スラドっぽいイベントとか「記念日」とかを発見し次第書いていけば、
時期を逃さずに済むと思うのですが。
Wikiでも運用次第で問題ないかも。
Re:カレンダーは？ (スコア:1)
あると確かに便利でしょうねぇ。
ただ、やろうと思えば別にスラドでなくてもできるってあたりが微妙。
スラド的には、現行のシステム(あるいはテスト中のやつ)からシームレスに
利用できるといいんだろうけど、逆に、スラドだけでなくいろんな
ところのサービスから利用できるようになってるサービスのが
汎用性があっていいかも。
個人のサイトでも手間かかるけどできなくはなさげだなぁ。
Re:カレンダーは？ (スコア:1)
そうなんですよね。
スラド本体でやるとイイことってのは、やっぱり、
スラド自体の機能(？)の拡張なんですよね。
前述の俺の意見「Storyの寿命を伸ばせよ」は、
まさにそういう話なんです。
あれはスラド自体が変わってくれないと意味がないんで。
よそのサイトでそれを実現しようとしたら、それは最早スラド自体の存在価値を否定するものになっちゃう。
なんせ、それをするためには、「スラドのStoryの続き(のコメント)を書ける場所」を作ってしまうことになりますから。
で、それはスラドの改良とは別の議論ですよね。
Re:お願いだから (スコア:0)
# takano32さんが受け付けるかどうかが鍵ですね^^;
Re:お願いだから (スコア:0)
夜の部に知人が参加するようなので行きたかったのですが、夜チケットは早々に売り切れてしまい買えませんでした。残念。
昼チケットは買いましたが、Tシャツがなぜ昼には付いてこないのでしょう。ま、LLサイズのTシャツは要りませんがね;-p
裏イベント (スコア:2, 興味深い)
ただ、この集まりは、「気心の知れたSqueaker同士」だそうなので、
(俺みたいに)門外漢はお呼びじゃない、ってことなのかも知れませんが。
ほかにも裏番組が有るようでしたら、
紹介してくださると(少なくとも俺が(^^;)嬉しいです。
>Tシャツがなぜ昼には付いてこないのでしょう
ここも、ちょっとがっくりした点だったりします。
Re:お願いだから (スコア:1)
Re:お願いだから (スコア:1)
eXtensible Language なのだろうか。
HSPはないのか…… (スコア:2, 興味深い)
＃初めてHSPを見たとき、開発環境が”丸ごと”FD一枚に収まるのを見て驚愕した覚えが。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:HSPはないのか…… (スコア:1)
HSPの人(?)がカンファに参加しないだけではないでしょうか。
特に「これとこれとこれがLWLだ」とは定義されていないようですし。
もし開発者の方と近しいようでしたら、「こんなのあるけど、参加したらおもしろいかもよ」と誘ってみるとか。
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo（月友）
Re:HSPはないのか…… (スコア:1)
Windows 3.1 時代の Windows プログラミングでは、まさに Lightweight って感じでした。
WinMain しか知らなかった。(今でも似たようなもんだが)
当日券あります (スコア:2, 参考になる)
Heavyweight? (スコア:1)
Re:Heavyweight? (スコア:2, 参考になる)
# まぁ参照されたところでよくわかりませんが。
Re:Heavyweight? (スコア:0)
つまり、アレゲな言語と相似なんですかね？
# アレゲなのでAC
Re:Heavyweight? (スコア:2, すばらしい洞察)
貴方を高級LL(のご利益)に導いてくれる鍵かと(^^;
ま、あれですよ。
CPUはどんどん性能上がってるくせに、人間の脳は根本的には数万年かわってませんから、
負担をかけるのをCPU側にどんどん倒していったほうがいい、に決まってます。
Tiny BASICに勝るものはない (スコア:1)
リアルタイムOSで4Kなんてのもあったね。
そういうのを軽量って言うんだろ。
perlやPHPが一晩で書けるようになるとも思えんが。
Re:Tiny BASICに勝るものはない (スコア:2, 参考になる)
- 一時間で覚える Ruby [mayah.jp]
- 1時間で覚える?Python [naist.jp]
- 一時間で
わかるML超入門 [sourceforge.net]
実践してみたことはありません（ｗRe:Tiny BASICに勝るものはない (スコア:1)
先生質問です！その1時間には「モンティ・パイソンの空飛ぶサーカス」を視聴する時間は含まれていますか？
# 含まれてません。
それはさておき、Pythonの魅力には言語仕様のみならずアホみたいに豊富な標準モジュールの存在もあると思うんですが、1時間ではそこまで手が回りませんか……。
Re:Tiny BASICに勝るものはない (スコア:0)
入っていく最初のハードルの低さは、
PerlもPHPも、BASICと大差無いと思いますよ。
Re:Tiny BASICに勝るものはない (スコア:0)
人間にとって軽量なのです．
程度にもよりますが，BASICでやることくらいなら
PerlやPHPでも簡単にできると思いますよ？
Re:Tiny BASICに勝るものはない (スコア:0)
Re:Heavyweight? (スコア:0)
なんに対しての軽量なのかをよく読んで見てください
Re:Heavyweight? (スコア:3, 参考になる)
1 標準体重以下の人[動物].
2 【ボクシング･レスリングなど】 ライト級の選手.
3 《口語》 つまらない[取るに足らない]人.
とのことで、
標準体重以下の人が使っているつまらない言語のことでしょう。
ちゃんとした参考 [cozmixng.org]
...Lightweightというのは「コンピュータにとって」軽いのではなく、「人間にとって」軽いのではないか
#-- そんな言語を生業にさせて頂いております --+
Re:Heavyweight? (スコア:0)
Re:Heavyweight? (スコア:1, すばらしい洞察)
Re:Heavyweight? (スコア:0)
はい、そのあとフロッピーディスクからDISK-BASICを起動するようになりましたが。もっとも、現代のWindowsでも起動時間は大差ない気もする。
ハードディスクなんて（エンドユーザ向けには）無かった頃の時代さ。
去年 (スコア:1, 興味深い)
Perl6もそろそろか?とわくわくしたことを思い出します。
もう一年経っちゃったなあ..........
Re:去年 (スコア:0)
そーっすよね。全く同意。
でも、この1年で、いまさらですが蛇遣いになってしまった
ので、Perl6 とかもういいかもと…1年って短いようで長いっすよ。
Re:去年 (スコア:1)
見たらPerlはこれで「あがり」のような気がしました。
いまはgroovyに期待してます。
Re:去年 (スコア:1, 興味深い)
Groovyかぁ。。
↓こんな評判もあるんだけど。
Stevey's JVM Language Soko-Shootout [cabochon.com]
# ここに書かれているGroovyに対する評価、個人的には激しく同感。
Re:去年 (スコア:1, 興味深い)
Groovyは今日でもRC3版で、記事はさらに古い版です。
GroovyはSwingが今のところSwingBuilder以外は苦手、なぜならば無名クラスがまだ実装されていないからという原因があります。
彼はラッキーなことにGoogleに就職されて、この記事はもう更新されないそうですが、メジャーリリースを経たらGroovyに関する彼の評価も変わると思います。
Re:去年 (スコア:1)
たしかGroovyについては、バージョン上がるたびに
「捺印ナビリティ」が上がっていく感じに文法が変更され、
そのぶんLightweightっぽさがむしろ減じているようだ、 (だから嫌だ、)
というコメントをしてる人が、どこぞにいらっしゃったような記憶が。
Javaというか、Javaじゃないにせよあの手の「硬い」系の言語というか、
そういった感じのに近付くような変更は、
LL愛好者にとっては改悪に映るでしょうね。
いっぽうで保守的保身的な印鑑所有者たち(^^;のメガネには叶いやすくなるでしょうけど、
それはプログラマの幸せとは(はっきり言えば)無関係。
＃自称LL愛好者なのでG7
＃台風も俺様を避けて通ったぜ！(わら
Groovyについては、無名クラスだけの問題じゃないような気がするなあ。
どっちかってーと無名クラスより無名関数つまりClosureのほうが
いろいろ使いデが有るわけだし。
＃余談：
＃イベントハンドラとか作るには、無名クラスよりDelegatesのほうが良かったんとちゃうか？＞往年のSun対MSのJava文法論争
Re:去年 (スコア:0, 荒らし)
( ´･ω･) Pugs [pugscode.org]ドゾー
( つ旦O
と＿)＿) 旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦
Re:去年 (スコア:1)
これのおかげで本家の進捗状況が一気に改善されたんだぞ。(と発表されてた by LLDN参加者)
各ユーザ会のおはなし (スコア:1)
programというよりはscriptというかcommandなので存在しないのかなあとも思うのですけれども、プログラマーでもなくスクリプターでもなくオペレーターのボクにはちょっとわからないですの・・・
存在したからといってどうということもないのですけれども、最近のユーザ会というのはどういうものなのかな、ともそのようなお話もお伺いできたらとも思うです。
-------- SORAMINE Yukino
Re:各ユーザ会のおはなし (スコア:1)
画像処理はImageMagickで、音声ならSoX、動画だってMPlayer/MEncoderで扱えますし、XMLならXSLT、HTTPならWgetかcURL、文字列処理はgrepやらなんやらで。無い機能はC言語でもRubyでも小さなツールを書いて付け足せばいい。
普段使ってるシェルとシームレスなところ、各コマンドの結合が疎なところ、強力なパイプが魅力です。
弱点は効率の悪さと、複雑なデータのやりとりがやりづらいのと、各ツールのインターフェースがばらばらなところですね。
しかし、コミュニティという視点でいくと、シェルプログラミングは各ツールのよせあつめなので、各ツールのコミュニティの方に人が流れてしまってシェル自体には人が集まらないのかもしれません。
Re:各ユーザ会のおはなし (スコア:1)
そーゆー意味では今年はあんましすっとんだ発表はなかったですね……。
Re:各ユーザ会のおはなし (スコア:0)
この場合、研究家の方が似合うような感じもする。
Re:各ユーザ会のおはなし (スコア:1, おもしろおかしい)
前あったんだけどな。移転したのか閉鎖したのか返事がありません。
Re:各ユーザ会のおはなし (スコア:0)
Re:各ユーザ会のおはなし (スコア:0)
私案：継続ベースもどきをお手軽に実現できないか (スコア:1)
一般的な話は、スラド諸兄、もといBLOG諸兄に(T_T)任せるとして、
遅れ馳せながら俺は、
俺個人が思ったことについて少々。
俺が興味深かったのは、WebFramework対決での、
Kahuaの「継続ベースのWebアプリ」のあたりですね。
まず質問者に継続どころか入れ子関数すら理解してない人が居たのが
(わるいんだけど)面白おかしかったってところ。
おーい、世の中、ローカル変数とグローバル変数の2段階しかない言語ばっかりじゃないんだよー。
会場では「なんでも継続 [dreamhost.com]読ませろよ」って声が飛んでたけど、
3分で読んで3分で理解できるかってーと怪しいし、
そもそも関数の概念自体がC/Javaレベル(^^;に固定されてた人だったように見受けるんで、
まずをそっちを理解するのが先かと。
＃でも周囲の応答もイマイチだったなあ。「ぜんぜん違うプログラミング形態だ」ということがきちんと伝わっただろうか？
いや、その人自体はどうでもいいんだけど(それに知識は単に学習すれば済むことなんだけど)、
一般的にも、これくらいに継続どころか入れ子関数すら
「知らない」し、それゆえに「活用できない」人が
多いんじゃないか、という気がするんです。
そしてそれはひいては、
KahuaみたいじゃないFWども (Strutsとかは言うに及ばず、評判の高いRubyOnRailsとかですら該当する)
が惰眠をむさぼってるという現状を、生んでいるんじゃないかと。
だって考えてもみようよ。
ユーザイベント(入力)をTOPレベルの基点としてプログラムを記述するほうが、
快適に記述できる場合も、もちろんいっぱい有るわけだけど、
逆に、処理の合間にユーザに問い合わせるっていう「処理の流れ」を
そのまま記述したほうが快適に書ける場合も、あるわけじゃん。
(主客の転倒ね。前者は入力の配下に処理がある。後者は処理の配下に入力がある。)
でもStrutsは言うに及ばずRoRですら、そういうのをサポートしてないそうなので。
「してないそうなので」というのは、まさにそういう
Web Linear Programming(*)をサポートしてますか？みたいなことを
質問した人が会場に居たので。
(俺じゃないです。でも正に言いたいことを代弁してくれた感じ。)
(*)たぶん俺造語です。でも継続ベースのWebアプリを
Linear Programmingと呼んだ人は、既に居たと思う。
あたまに「Web」をつけたのは俺が考えた。
ちなみに世間でLinear Programmingというと、
なんか線形計算だかなんだかいう全然別の概念を指すらしいんで用心桑原。
で、サポートしてなくても不満が出ないのは、つまり
それの便利さをみんな気づいてないから、ってことなんじゃないかと。
知らないから、なんじゃないかと。
ーー
で。俺が考えたのは、
じゃあ代用手段でサブセットな道具を作ったら、
それはそれなりにご利益が有るんじゃないかな？と思ったんだ。
(というか、思ったのはLLDNより少し前からだけど。)
継続でやれて嬉しいことの1つとして、
「処理の合間にユーザ入力を待つ」という記述がすんなり出来る
って点が有ると思います。
(少なくともLLDN当日に出てきたネタはソレだけでしたよね。)
俺もまた継続を正しく理解できてないんだけど(わら)、
その俺なりに考えた(つまり継続理解してない頭でも判るやり方)のが、
「スレッドで代用しようかな？」です。
HTTPライフサイクル(ってのか：1回のRequestからResponseまでの処理の流れのこと)の中で、
最初の「Requestを解析して仮Viewオブジェクトに収める」のと
最後の「Viewオブジェクトを解析してResponseに収める」のとの
2つだけは
MainThread(というかServletから呼び出されたときのThread)で実行し、
その間の「ユーザ処理：Viewを解釈してModelを更新したりとかする」の部分は、
別途生成したSubThreadで実行することにしたら、
いいんじゃないかと。
で、普段は、
複数Threadじゃないかのように振舞えばいい。
つまりMainはSubを起動したら、Subの終了を待ってから再開すればいい。
いっぽう、上記のように「入力待ち」をしたい場面になったら、
SubThreadを「入力待ち」の場面で眠らせちゃうの。
Mainは正確にいえば(つまり両方のケースをサポートするために)
Subが「死ぬか眠るかどっちか」するまで待てばいいんじゃないかな。
(待ち方は、とりあえずPollingし
NetBSD BOF (スコア:0)