Lightweight Language Saturday 48
ストーリー by Oliver
開発者の気分も軽やかに 部門より
開発者の気分も軽やかに 部門より
k3c 曰く、 "Perl,PHP,Python,Rubyの各コミュニティが合同でLightweight Language Saturdayというイベントを開催するそうです。各言語の最新トピックの紹介、オブジェクト指向についてのディスカッション、同一テーマについてのプログラ厶レビュー、書籍展示・販売、などなど。8月9日(土)10:00～17:00、参加費2000円、定員200名。すでに参加申し込み終了間近なようです。各セッションの記録を取るロガー(特典として参加費無料)も募集中とのこと。
1つの言語のユーザー会がイベントを開催する、というのはよく聞きますが、このように複数の言語がコラボレートしてイベント開催、というのは極めて珍しいのではないでしょうか。白熱した議論が繰り広げられるのか、あるいは…？発言者も錚々たる面子が並んでおり、興味津々です。"
君ならどう書く？ (スコア:2, 興味深い)
...が面白そうだけど、本当に気になるのは「仕様変更への対応能力」じゃないですかね？ 仕様が変化したとき、コードの修正を最小限に済ませるためにどのようなテクニックが各言語において有効なのか、それが一番知りたい。
...芸というものは一生勉強だと思っています...
プログラマの鉄人 (スコア:1)
1時間とかの制限時間でプログラムを書く様子を
みんなであおる・・・とか。
『あ～っと、ここで鉄人はsmartyをインクルード!!』
Re:プログラマの鉄人 (スコア:1)
「プログラミングの鉄人 - プログラミングの技」 [u-tokyo.ac.jp]
というのが開催されていました。
予選を通過した鉄人たちが45分間でプログラムを作るという形式だったようです。
(そのときの写真(下の方です) [shudo.net])
それにしても和田先生 [ipsj.or.jp]すごすぎ…
Re:プログラマの鉄人 (スコア:0)
「う～ん、見通しが悪いですね 文法も独特です」
そういう煽りは面白そうですよね。乱入したりブーイングや拍手を送ってみたいです。
Re:君ならどう書く？ (スコア:0)
ライトウェイト的アプローチというヤツでハッとさせて欲しいです。
# お金も時間も無く 徹夜 > 青春18切符遠征 > 徹夜 というワケの解らない状態で遠征予定;
4つだけ？ (スコア:2, 興味深い)
話とかもやってほしいなぁ、とか。眠っている素晴しい言語の発掘になるかもしれないし、
他の言語への良い刺激になるかもしれない。
// 「○○ではこうやってるんだって。じゃー俺らの言語でも実装しちゃおうか。」…とか。
// lua とかやってほしいなぁ…。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:4つだけ？ (スコア:1)
Tclは3,4年くらい前(C Magazineに特集記事が載った前後?)は
日本語の書籍がそこそこ出版されていたと思うのですが…
今はどうなのでしょう。
#256倍本が出ていたawkは?
Re:4つだけ？ (スコア:1)
＃CSP（COBOL Server Pages）とか作らないと駄目かな。
こんな感じで：
<% IDENTIFICATION DIVISION.%>
↑７桁開く・・・。
Re:4つだけ？ (スコア:1)
# 変数使いますよね?
-- 哀れな日本人専用(sorry Japanese only) --
いんや (スコア:1)
PROCEDURE DIVISION.だよん。
変数なくても DISPLAY "HOGE" UPON CONSOLE. ならイケルよ。
ちなみにワシはCOBOL,AWK,Lisp以外は使う気が起きないので、今じゃプログラマ失格。(^.^;
Re:4つだけ？ (スコア:1)
というか、COBOL のコードってこれくらいしか見たことがないだけど。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:4つだけ？ (スコア:1)
Re:4つだけ？ (スコア:0)
受け付け終了してる (スコア:1)
会社からもすぐ近いし、登録しようと思ったのに。
Tシャツ欲しかった。
May the source be with you... always.
既に満員御礼。 (スコア:1)
残念。
Re:既に満員御礼。 (スコア:1)
参加者登録は締め切りましたが、ロガー枠はまだ若干余裕がありますので、どうしても参加したい方はロガーとして応募するのが良いのではないかと。参加費免除だし。
PHP って LL ? (スコア:1, 興味深い)
仕事で生産するコードは 100% 、プライベートでも 80% は PHP なので応援したいのですがそれでも実感は「PHP はライトウェイトではない」です。コードのうち結構高い比率を、シンタックスやリテラルが機械のためのコードで占められているように思えます。
だからこそ会場でどのように料理してくれるのか楽しみなのですが、PHP-users に案内が流れた瞬間から PHP って LL なのかなぁ～と気になっていたのでここで呟いてみるテスト。
Re:PHP って LL ? (スコア:1)
毎日のログ整理、CGIプログラミング、ネットワーク管理など、簡単なことを手軽に、凝ったことでもそれなりに実現できるのが Lightweight Language(軽量プログラミング言語)です。
ということなので、五行でデータベースに接続して、テーブルを html に出力できちゃう php は LL と言えるのではないでしょうか。
「簡単な事を手軽に」(easy things easy)ってまさに php っぽいし。。
# perl [oreilly.de] が LL なら php も LL でしょう（笑
Re:PHP って LL ? (スコア:0)
Re:PHP って LL ? (スコア:0)
> 五行でデータベースに接続して、テーブルを html に出力できちゃう
なるほど =)
そういう場面では Lightweight ですね。納得出来ます。
思えば結局自分にとって/そのシチュエーションで一番使いやすいから PHP を選んでいるのですよねぇ…
> perl [oreilly.de] が LL なら php も LL でしょう（笑
初めて LL なる概念を知った時、Java も Perl もネタにされて Ruby と
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負担言語の違い、といったところかな…
8/9なんて先のことは判らない (スコア:1)
ええ。こんな嫌(予想不能)な忙しさに陥っているのは、
仕事でLightWeightLangを使っていないせいだと思います！！(T_T)
＃ruby bindingライブラリは作ってやるから、それを仕事で使うのを認めてくれ、なのでG7
＃C言語と比較したら開発効率が何倍違うと思ってんだ？？？
Re:8/9なんて先のことは判らない (スコア:4, 興味深い)
うちはCとRubyの両方の見積もりを出したら、その価格のあまりの差にRubyが通りました。
"これだけ違うんなら、うちの技術者にRubyを覚えさせた方が安い"
という判断のようです。
まつもと ゆきひろ /;|)
業務連絡: まつもと様 : Rubyによる実装 (スコア:4, 興味深い)
ちなみに dRubyでおなじみの関さん も「動的に構成変更可能な分散オブジェクト指向システムの提案」というタイトルのdRubyネタで通っています。
開催告知＆タイムテーブルはこれ [aist-nara.ac.jp]
シアトルでのRuby Conferenceでの 発表ネタと同じですけど、 今度は視点を変えてRubyを知らない人たちが 開発への導入モチベーション になるような形で書いたものです。
ログインするのが面倒なのでAC
すずきひろのぶ
Re:業務連絡: まつもと様 : Rubyによる実装 (スコア:1)
7/10はあいにくOSCONで日本にはいませんが、応援してます。
# 私信だな、こりゃ
まつもと ゆきひろ /;|)
Re:8/9なんて先のことは判らない (スコア:1)
----
LLでも，課題プログラムについて，Cとかで書いたものも用意しておくと差がはっきりして面白いのかもしれませんね．
Re:8/9なんて先のことは判らない (スコア:0)
#微妙に浪漫を感じる
Re:8/9なんて先のことは判らない (スコア:1)
まつもと ゆきひろ /;|)
Re:8/9なんて先のことは判らない (スコア:1)
同意。
Windowsに限って言えば、今はLLでexeは作れたりしますが、DLLやOCXが作れたり、VC・Delphi・VB並のGUIエディタを備えたIDE（強力なデバッガやヘルプ機能があれば尚良し）があったりすれば仕事で使う機会は増えると思うんですけどね。（少なくとも自分は）
Re:8/9なんて先のことは判らない (スコア:0)
もう満員のようですね、、
昨日申し込んでおいてよかった、、、。
Re:8/9なんて先のことは判らない (スコア:0)
人数いっぱいらしいですが G7 さんならステージに立つ側で潜り込めませんか。とか煽ってみる。ステージの上でも～なので G7 とやってください。
残業な
Re:8/9なんて先のことは判らない (スコア:1)
>人数いっぱいらしいですが G7 さんならステージに立つ側で潜り込めませんか。とか煽ってみる。
そこまで良心失ってる人が運営するイベントじゃないと思い(期待し)ます(^^;
持ちネタが全くない人間が出ても無意味ですぅ。
>ステージの上でも～なので G7 とやってください。
「～なので」が出る理由だというならば、全国100万人(推定)のAC諸兄が出るのが先決ではないかと。
俺は彼らの真似をしてるだけですから。
>残業なんて口の端にさえ上ることも無いので技術者にとっての Lightweight は会社の Lightweight と見かけ上は無縁になっている罠。
金銭面はその通りなんですが、問題は時間(と品質)なんですよね。
開発効率の悪い言語でウダウダやって(やらされて)いる状態は、
会社にとってもプログラマにとっても損失(HeavyWeight)です。
たかが情報の塊(我々はしばしばObjectと呼びますが)をあっちの関数からこっちの関数に持っていくだけで
何百行もの小難しくも汎用性の無いコードを毎度毎度書く、なんてことをやってりゃ、寿命が(無駄に)縮んでしまうというもの。
足し算と掛け算の原理、とかいうんでしたっけ。
毎回そういうコードを書く(足し算)んじゃなく、そういう部分を汎用化/Meta化したようなモノを一発作っておき、
それを使いまわす(掛け算)ほうが、効率が良いという当たり前の話。
Greenspun's Tenth Rule of Programming [dreamhost.com]と同じ事かな。＃喩える対象をLispにすべきか否かという議論はさておき
>LL に行くには技術者側に勇気を頂戴、とか言ってみるテスト。
必要な人ほど見に行けない罠、は有るかも知れない。
まあ、イベントに行った途端に魔法のようにプログラムやマネージメントが旨くなれるわけじゃなかろうから、
部下も上司も日ごろから向学し鍛錬するしかないんだけど、イベントには精神的にカンフル剤的な効果
(もちろん半分は受け手次第ですが)は期待したい。
Re:8/9なんて先のことは判らない (スコア:0)
と叫んでみるのは如何
4GL (スコア:1)
違う概念なのかな？
Re:4GL (スコア:0)
汎用なところが LL なのでしょう。
そういう観点だと、Apache+PHP は 4GL っぽいですねえ。
ロガー募集中 (スコア:1)
構想時点？で (スコア:0)