「コンパイラ・スクリプトエンジン」相談室8

「コンパイラ・スクリ ..

596:594
05/12/05 01:19:58
>>595
ﾜﾛﾀ

597:デフォルトの名無しさん
05/12/05 21:20:28
Lispってとにかく単純でとっつきやすいんだよな。
S式はパースが異常に簡単だし、末尾再起最適化とか考えなきゃ処理系も一瞬で実装できる。

598:デフォルトの名無しさん
05/12/05 21:25:05
>末尾再起最適化とか考えなきゃ
ちょｗｗｗおまｗｗｗ

599:デフォルトの名無しさん
05/12/05 22:08:58
>>591
お前は墓の研究でもしてろw
最先端言語の研究とは無縁だろ？

600:デフォルトの名無しさん
05/12/06 00:48:19
>599
Rubyが最先端言語とでも？？
RHG見れば解るけど、かなり泥臭い実装じゃない？

601:デフォルトの名無しさん
05/12/06 01:11:05
>>600
知ったか素人だまれ

602:591
05/12/06 01:43:38
>>599
うーん、開発現場の人ですよね。>>591で馬鹿って言ったのは、
「言語理論の研究者で、かつ、Rubyが研究に使えると思ってる人」です。
開発現場においては、Rubyは確かに最先端言語の1つですよね。

ただ、言語理論の研究では言語の性質の解析とか証明とかしなきゃならないんで、
実用的に便利な言語ってのはちょっと違うんですよ。
本質だけのシンプルな言語、誤解を恐れず言えば「低機能」な言語が重宝されるんです。
なので、Rubyは高機能すぎて、言語理論の研究にはちょっと向かないかな、と。

でも、今の世の中を支えているのは>>599さんのような現場の人ですから、
自信をもって生きてくださいね。応援してます。

603:デフォルトの名無しさん
05/12/06 05:58:09
高卒が搾取されてくれることでこの業界は成り立ってるしね。

604:デフォルトの名無しさん
05/12/06 19:38:30
>>603
そこに大卒組がドロップアウトしてくるようになってきた事で、状況は混乱気味でつ。

605:デフォルトの名無しさん
05/12/06 20:19:22
でも金かせいでるのは土方だしなw
研究成果が経済成果として繋がる例は極々わずか。
まぁ、それが研究というものの宿命でもあるわけだが、

606:デフォルトの名無しさん
05/12/07 01:50:47
土方の生んだ金は、どこに消えているのやら

607:デフォルトの名無しさん
05/12/07 02:41:43
>>606
土方の金の使い道の事？それとも金の出所の事？

608:デフォルトの名無しさん
05/12/07 02:43:41
>>606
中間搾取の事？

609:デフォルトの名無しさん
05/12/07 02:54:29
>>606
ちなみに普通は、半分から４／５は中間搾取で消えていく。
まあこれが、税金や社会保険による搾取だけならまだ納得できるが、
実際には、派遣会社が間に何社も入って掠め取っているだけだから、
ひどい話だとは思うけどな。

610:デフォルトの名無しさん
05/12/07 03:25:30
ふーん、派遣会社がそんなにねぇ。
なら、普通に雇う側の会社がホームページで
募集すればいいじゃん。

611:デフォルトの名無しさん
05/12/07 08:53:04
>>610
NEET or 学生さんですか？

社員として雇うのは、労働契約とか社会保険とか法令とか、そういうので面倒なんだよ。
さらに言うと、上のような理由も実は建前で、最大の理由は、用済みになったときに好きなようにクビ切れないってことだな。
なので、中間搾取のおかげで一見、能力/金額比が良くないように見えても、トータルで考えると安く上がっちゃうことも多い。
１人雇用するリスクをとらず、金で解決できるんだったら、そのほうがお得というこった。

612:デフォルトの名無しさん
05/12/07 10:42:19
>>604
不景気のせいで土建業由来の不正労働慣行があらゆる業種に蔓延し常態化していることに加えて
院卒が従来の大卒の業種・業態へドロップアウトしてくるようになったからな。

文科省が欧米諸外国並みに博士号持ちの数だけはそろえようと
博士課程や修士課程（博士課程前期）の定員を就職の受け口の見通しもないまま
闇雲に増やしたんで博士取れたヤツも取れなかったヤツも
従来の研究・教育職では吸収しきれずに普通に開発仕事につくようになり、
最近ではそれでも足りなくて派遣で仕事をするケースも増える傾向だ。
（そういうとき周囲に敬遠されないように院卒の経歴を隠して
「大学でちょっと遊んじゃって(^-^;」などと言うヤツもいる。）
大学の独立行政法人化と年俸制の任期（2-5年）の条件付募集が
標準になって30台以下の研究者が定期的に失職することがその傾向を加速している。

613:デフォルトの名無しさん
05/12/07 11:52:57
>>612
まぁ、ろくに成果の出せない研究者はいらないということだろうな。
土方サイドでは、経験がなにので用無しとなってるし。

研究者として生きて行くためには、（上にもあったが）抜きん出た実力と
独自の発想、それに、強運が必要だろうね。

614:デフォルトの名無しさん
05/12/07 11:58:24
>>613
運は*必要*とは言わないんだよ。

615:デフォルトの名無しさん
05/12/07 12:25:21
>>613
研究に夢を持ちすぎ。
天才の数は多くないので他業種同様に
圧倒的多数を占める凡人をうまく使う社会的な工夫が必要。
それなりに高度な教育しといて放り出すというのは人的資源の無駄遣いでしかない。

そもそも研究というのは大規模投資して本格開発するほどには
結果が明らかでない内容を論理と実験を手段として探りながら進む作業の総称だから
研究にも難易度、規模、価値について色々なものがある。
例えば>613が夢見るような先進的で独創的な研究があった場合、
その周辺には実用化や普及の前に片付けなければならないような
相対的に難易度の低い研究課題が沢山発生するのが常だが、
それを片付ける>613が言うような相対的に低能力の泡沫研究者の数も
本来はそれなりに必要なのだ。

ただ日本では>613のような古典的な夢を抱いて「研究」というものを見ている人間が
まだまだ多数派だがな。

616:デフォルトの名無しさん
05/12/07 12:27:26
研究も他業種同様多くの技能から成り立っている。
例えば、研究は独創的なことを思いつけば出来上がりではない。
計画を立て、先達の成果を調べ、論証し、実験し、評価し、論文を書いて発表しなければならない。
そしてその大部分は時間を消費する作業的な側面を持ち、
特殊な才能ではなく教育で身につく種類の技能に支えられている。

それを身に着けていることが研究者（大物でも泡沫でも）としての必要条件となるが、
それを研究者としての教育を受けていない人間が身に着けているわけではないし、
逆に身に着けてはいても世間で評価されるような大きな「成果」に恵まれないこともある。

例えば探索しなければならない範囲を狭めたという意味では失敗の報告も
有効なのだがどうしても世間ではどうしても成功のほうを高く評価するし、
特に日本では明治以降の歴史的経緯から独創性よりも完成度が評価される比重が高い。
それが欧米に対して日本では改良研究が多くなる理由でもある。
博士号を取ったり予算を獲得したりする際に多少独創性があるより
完成度が高い方が日本では圧倒的にウケがいいのだ。
（これは改良研究のほうが審査する側も評価しやすいせいもある。）

だから博士号を取った先輩は博士課程の後輩に
「あんまり理想を高く持って独創性のある高度なものにしようとせず、
恥を捨てて教授の温情にすがり、できるだけ簡単で瑣末な研究で博士号を取るようにしろ。
でないと3年では取れないぞ。」
などとまじめな顔で助言することになる。

617:デフォルトの名無しさん
05/12/07 14:20:54
>>613
＞まぁ、ろくに成果の出せない研究者はいらないということだろうな。
＞土方サイドでは、経験がなにので用無しとなってるし。

そうでもない。独学できっちりと勉強してるヤシは少なくないし、
汚いコードを書くヤシは少ないし、設計をみっちりとやってるヤシ
も少なくないから、耐久力のあるヤシは、わりと重宝されてる。

618:デフォルトの名無しさん
05/12/07 14:24:48
やっつけ仕事にほうり込むと、すぐに潰れるけどな。ｗ
混沌とした状況で生き延びる能力の無さを、何で補うかが課題だな。

619:デフォルトの名無しさん
05/12/07 14:43:01
中小零細ＩＴ企業は、やっつけ仕事の所が多いよな。あと、
大企業でもたま～に、やっつけ仕事の所があったりする。
何処とは言わないケド。

620:デフォルトの名無しさん
05/12/07 16:47:26
いいから黙って働け
シャッチョさんのために

621:デフォルトの名無しさん
05/12/07 17:55:27
なんだここは
コンパイラ・スクリプトエンジンのスレとは思えないな

622:デフォルトの名無しさん
05/12/07 19:46:55
>>619
たぶん脳内w
やっつけでコンパイラとか書くのなどあり得ない。

623:デフォルトの名無しさん
05/12/07 19:52:08
電脳土方ネタは別スレッドでやってくれ。明らかにスレ違いだろう。
64bitメモリ空間を馬鹿みたいに消費するアプリのための、Lisp
もどきを作りたいんだが。

624:デフォルトの名無しさん
05/12/08 01:25:32
>>623
おまえは板違いw

625:デフォルトの名無しさん
05/12/09 02:08:19
>>624
おまえは気違いw

626:デフォルトの名無しさん
05/12/09 03:18:00
>>625
おまえは勘違いw

627:デフォルトの名無しさん
05/12/09 09:17:35
>>626
おまえは腹違いｗ

628:デフォルトの名無しさん
05/12/09 10:46:09
>>627
おまえは立貝(タチガイ)ｗ

629:デフォルトの名無しさん
05/12/09 11:59:40
俺はフランクリンw

630:デフォルトの名無しさん
05/12/09 12:11:24
一行レスに嬉々として参加するようなバカが何でこのスレ覗いてるわけ？

631:デフォルトの名無しさん
05/12/09 12:38:37
それに対して、同じく一行レスで中身無し、しかも煽り、ってのはどうだろうなぁ。
自分が使ったバカの一語が、自分に最も当てはまっているのでは。

632:デフォルトの名無しさん
05/12/09 12:58:11
バ
カ

633:デフォルトの名無しさん
05/12/09 13:03:31
>>630
ネタが、ネタがなかったんだよ～～(T-T)

634:デフォルトの名無しさん
05/12/09 23:58:21
研究ネタも（ry

635:デフォルトの名無しさん
05/12/10 10:06:17
Dr.欲しくて、教授の機嫌を取らなきゃいかんことはよ～くわかるが、
「障子を開けてみよ。外は広いぞ」という言葉を貴殿に贈ろう。
蛸壺（失礼）から出て、興味の赴くままに外の世界を味わうことも大事。

636:デフォルトの名無しさん
05/12/10 10:59:52
貴殿！貴殿！貴～殿殿で殿殿！

637:デフォルトの名無しさん
05/12/10 14:54:50
>>636
ちょっとリズムに無理があるかな。

638:デフォルトの名無しさん
05/12/10 15:37:13
>>637
大丈夫。
休符を入れてから
きが始まる。
ん、貴殿！！！貴殿！貴～殿殿で殿殿

639:デフォルトの名無しさん
05/12/10 16:05:48
馬鹿じゃねーの

640:デフォルトの名無しさん
05/12/10 16:08:40
馬鹿じゃ、ねーの！
I'm not fool ! OK ?

641:デフォルトの名無しさん
05/12/11 00:02:50
ケンキューテーマと一緒で、大した話題がないなぁ～

642:デフォルトの名無しさん
05/12/11 12:51:50
処理系の研究してる人いるみたいだから聞きたいんだけど、今時はどんな研究が盛んなの？

643:デフォルトの名無しさん
05/12/11 13:11:24
>>642
> 処理系の研究してる人いるみたいだから聞きたいんだけど、今時はどんな研究が盛んなの？
俺、大学院の研究室がプログラミング言語関係の研究室だったから、この世界には多少つながり
がある。

で、今盛んなのは、プログラミング言語の機能拡張をいかに安全に行うか、ということ。

安全とは、処理系素人が中身を知らずに処理系（ＪａｖａでもＬｉｓｐでも）に、拡張機能モジュールを
突っ込んでも、モジュール同士が干渉することなく、素人が拡張機能の恩恵にあずかれること。

モジュールを突っ込んで言語処理系の機能（というか、糖衣構文かなぁ）を増やす、というアイディア
は、ＭＯＰ、mixinとずっと前からあるわけだが、安全性については発展途上。

俺はいま、言語、ソフトウェアとは別業界なので、個人的趣味でたまにサーベイした範囲で書いてる
けど、本職さんのアドバイスをおながいします。

644:デフォルトの名無しさん
05/12/11 14:34:24
テンプレの>>5をみればこの分野の流行はつかめると思う。

645:デフォルトの名無しさん
05/12/11 18:22:09
>>643
こんな香具師おおいの？
専攻分野と就職先がなさならないと言う意味で

646:デフォルトの名無しさん
05/12/11 18:29:18
むしろ直結してるほうが稀

647:デフォルトの名無しさん
05/12/11 18:36:25
>>645
大学院たって修士だろ。それじゃあ、専門家とは到底言い難いから、企業としては都合のよいソルジャー
扱いで、専攻も分野も関係なく配置するんじゃない。

俺、ＩＴ関係企業でリクルーターやった経験あるんだが、専攻分野イコール業務分野という奴は見たこと
ない。大体、適当に丸め込まれて、学部、高専卒と机を並べて、畑違いの分野で研修、ＯＪＴだったなぁ。

俺はこれがやりたい、という強い意志を持ってる奴は、博士まで取るべき。企業としては、博士は専門
馬鹿でもてあますことが多いのだが、研究部門でツボにはまると、とんでもない力を発揮する。

648:デフォルトの名無しさん
05/12/11 18:40:34
つーか言語開発の仕事って例えば何？
SunとかMSとかBolandみたいに明らかに言語作ってる部隊以外に何がある？

649:デフォルトの名無しさん
05/12/11 18:55:21
>>648
> つーか言語開発の仕事って例えば何？

自分がかかわった範囲でいうと、組み込み用マイコン向けコンパイラの開発、ＨＤＬをパースして
さまざまな解析、設計アシストするツールの設計だな。

コンパイラはｇｃｃでいいじゃん、と思われてるけど、特定のマイコンに特化して徹底的に
チューニングするとｇｃｃが吐くコードより２割は小さく、速くなるんだな。
ｇｃｃは、マルチアーキテクチャ対応ゆえに中間コードレベルでしか最適化できないから。

ＨＤＬはね、単純にケイデンスやメンターのツール買ってきて導入して終わり、じゃないんだよ。
自前で故障検出パタン作成用ツールを作ったり、自社の設計ルールにのっとって記述されて
いるかチェックするツール（lintみたいなもんか)を作ったりする。昔は、自社で独自のＨＤＬを
設計、実装して、大型電子式自動計算機で長時間シミュレーションをまわしたもんだよ。
運が悪いと、数日ジョブを突っ込めなかったり、ディスパッチがまわってこないなんてことは
ざらにあった。

650:デフォルトの名無しさん
05/12/11 18:56:21
組み込み機器用にgccを移植するような地味な仕事から
簡単な業務処理用スクリプトを書いたりならしたことがあるが
コレといって”言語を作る”ってのはやったことないなぁ。

651:６４９
05/12/11 19:09:57
あとは、半導体テスタ用のテストパタンを加工するための言語を独自設計してつかっていたこともある。
awk,Perlでは、汎用性ありすぎて、かえって使いにくいから。

652:デフォルトの名無しさん
05/12/11 19:16:22
>>5の一番上のリンクから適当にピックアップ＋適当に訳
>>643の安全性ってのも一番最初に出てるね

* language support for security and safety　セキュリティと安全性のサポート
* dynamic compilation and optimization techniques　動的コンパイルと最適化
* languages and compilers for parallel computing　並列計算用の言語とコンパイラ
* storage management techniques　保存管理法？
* design and processing of domain-specific languages　ドメインに特定な言語？
* compilation for distributed heterogeneous systems　分散異種系コンパイル？
* effective implementation of advanced language features　よりよい機能の実装？？
* techniques for embedded and of mobile code　組込とかモバイル向けの手法
* program representations　プログラム表記？
* interactions between compilers and architectures　コンパイラとアーキテクチャの相互作用
* program analysis　プログラム分析
* software development tools　ソフトウェア開発ツール
* program optimizations and transformations　プログラムの最適化と変換
* techniques for effective compiler construction　効果的なコンパイラ製作？

ぜんぜんわからんかったorz

653:デフォルトの名無しさん
05/12/12 08:11:40
>>649
マイコン価格の暴落と処理速度の改善で、その仕事の半分は無くなる予感。

654:デフォルトの名無しさん
05/12/12 11:27:16
>>652
* language support for security and safety
　セキュリティと安全性をサポートする言語
　（例えばPerlのテイントとかJavaのベリファイアとか。
　最近は実行時に検査する内容を減らすために静的な検査も多いので型理論と関連が深い。）

* dynamic compilation and optimization techniques
　動的な（実行時）コンパイルと動的な（実行時）最適化
　（JavaのJITコンパイルとか。言語じゃないけど昔WindowsがBitBltナントカというAPIで
　画像のビット演算処理を実行時にコンパイルっぽいことして最適化してたような記憶も。）

* languages and compilers for parallel computing
　並列計算用の言語とコンパイラ
　（並列処理の関して通信とか同期とかメモリ共有とか負荷分散とかで
　抽象化と効率の、あるいは自動化と手作業でのカスタマイズのせめぎ合いから
　丁度いい点を見出す研究。）

* storage management techniques
　メモリ管理技術
　(たとえばGCとか、もっと進んでヒープを使わないプログラミングの可能性とか。
　研究者人口は多くない気がするけどディープなマニア多し（個人的偏見）。)

* design and processing of domain-specific languages
　ドメイン固有言語（特定分野向け言語）の設計と処理
　（例えばMathematicaやMATLABみたいなのとか。ハードウェア記述言語（VHDLとか）とか。
　論文ではAT&Tが交換機の構成記述言語なんてのを提案してるのを見たことがありますな。
　Flashのスクリプト言語とかあるいはSQLとかもそうかもね。
　このテの言語は必ずしもプログラミング言語屋が作らないので時々風変わりな実装がある。
　つーか今私がWindowsに移植してる言語がそうだというのは個人的なグチ。）

655:デフォルトの名無しさん
05/12/12 11:28:21
>>652
* compilation for distributed heterogeneous systems
　異種分散システムのコンパイル
　（CPUやメモリの構成が一様でない分散システムを扱う技術ですな。
　通信とか同期とかメモリ共有とか負荷分散とか、
　あるいはそもそも各ノードの構成情報をどうやって管理伝達するかとか。）

* effective implementation of advanced language features
　言語の機能の効率的な実装
　（例えば、大昔ならサブルーチン呼び出し、
　最近ならオブジェクト指向とかアスペクト指向とか
　リフレクションとかを効率よく実行する方法について。
　多分現在コンパイラ研究で実装面の主流。激しく応用寄り。
　多分このスレの王道？）

* techniques for embedded and of mobile code
　これは
　「（他言語やデータへの）埋め込みコード
　　　＆（アプレットやエージェントとかの）移動可能なコードの技術」
　のことか
「組み込みシステム向けコード＆移動体向けコードの技術」
　のことか少々迷うな。どっちもあり得る。forとcodeに注目して英文解釈すると前者？

* program representations
　プログラムの表現
　（一瞬、インテンショナル・プログラミングみたいにテキスト表現を用いない
　開発環境と一体化した言語（？）とか連想したけど多分違ってて、
　数学的＆理論的なプログラムのモデルのことだろうな。
　だとすると業界で一番の理論寄り分野。）

656:デフォルトの名無しさん
05/12/12 11:29:28
>>652
* interactions between compilers and architectures
　コンパイラとアーキテクチャの相互作用
　（キャッシュやパイプラインや特定の命令の有無などハードウェアの構成を知ったり、
　もっと意欲的には再構成可能ハードウェアを構成したりとかも入るのかな？）

* program analysis
　プログラム解析
　（まぁ最適化や書き換えなどのためにプログラムの性質をいろいろ調べる技術ですな。
　目指す処理に必要でかつ調べやすい性質のアイディアと
　そうやって提唱された性質をプログラムから取り出すアルゴリズムがセット。
　最適化のためのループの分類やら、ある変数の定数性を調べたり、
　ポインタがどのオブジェクトを指してるか調べたり。
　あとは型検査なんかもこのジャンル。
　末尾再帰かどうかを判定するなんてのは古典ですな。
　最近では型と絡めて安全性とかも話題。多分現在コンパイラ研究で理論面の主流。）

* software development tools
　ソフトウェア開発ツール
　（例えば開発環境とかデバッガとかリファクタリング・ツールとかテスト･ツールとか
　プロファイラとかソースコード管理とかドキュメントやUML図の作成ツールとか
　GUIウィザードの類とか。）

657:デフォルトの名無しさん
05/12/12 11:29:54
>>652
* program optimizations and transformations
　プログラムの最適化と変換
　（プログラムを書き換える技術一般。
　ジェネラティブ・プログラミングのように変換の枠組みを言語的に用意して
　プログラマに分野に特化した最適化などを書かせたり、
　あるいはコンパイラの最適化のようにプログラム解析の結果を適用して
　（多くは）自動的にプログラムを書き換えたりする技術。
　プログラム特化とか、部分評価とかアスペクト指向もこの文脈で語られること多し。
　そもそもコンパイラ自身を変換（あるいは変換の集まり）としてモデル化して
　考えることもあってその場合次項とも関連が深い。
　個人的にもっと日本でも流行ってほしい分野。）

* techniques for effective compiler construction
　効率的なコンパイラ構築の技術
　（effectiveがコンパイラにかかるのか構成に掛かるのか迷うところだけど
　多分、コンパイラ開発自身の効率化のほうだと思う。
　コンパイラの構成を工夫して新しい機能や最適化とかを
　あとから追加・変更したりできる技術とかコンパイラ･フレームワークとか。）

658:デフォルトの名無しさん
05/12/12 11:35:09
>>653
確かにハードウェアが進歩すると
トレードオフが程よくバランスする点は変わるから
最適化などで個々の技術が顧みられなくなることもあるんだけども、
プログラムのほうもどんどん規模はでかく、処理は重くなる傾向はあるので
研究分野としてなくなることはなかったりする。

後は昔のハードでは速度や容量の点から
夢物語だった先進的過ぎるアイディアを
実際に試せるようになったりすることもある。

659:デフォルトの名無しさん
05/12/12 11:40:42
このすれｽｻﾏｼﾞｽage

660:デフォルトの名無しさん
05/12/12 11:50:45
訳と解説乙。
次スレから、(個人的～の部分を省いて)テンプレにするといいと思う。
以下ツッコミ。間違ってたらごめん。

>techniques for embedded and of mobile code
普通に組み込み機器向けって意味じゃない？
データに埋め込む言語って意味だと、mobileと一緒にする理由がわからない。

>program representations
program representationというと、Abstract Syntax TreeとかGraphとか、
パースしたプログラムの表現形式(なぜか大抵は中間形式)を言う事が多いと思う。

661:デフォルトの名無しさん
05/12/12 12:08:45
>>660
techniques for embedded and of mobile code
に関しては正直どっちかわからんですよ。どっちの分野もあるし。
そのうえさらにややこしい事に移動体機器や組み込み機器向のコードとして
（容量や更新の都合で。）移動可能なコードを使うことが最近ちょくちょくあるようだし。

あー、program representations
に関しては>660の言うとおりかもなぁ。
その場合、インテンショナル･プログラミングの内部構造とか
バイトコードとその仲間達とかも入るかもね。

662:デフォルトの名無しさん
05/12/12 13:22:53
>>660 にだけ突っ込むけど、他意はないから許して
(>>654-657 を検証するような目で見るガッツがないもので…)

"mobile code"は日本語で「可搬コード」とでもいうような、
プログラムが分散環境を移動するやつかもしれない。

それから、"program representations"は、プログラム意味論とかの
「プログラムをどのような *モデル* で表現するか」というテーマだと思う。

663:654-657、661
05/12/12 14:11:41
>>662
まぁ、mobile codeに関しては私もそっちが第一候補ではある。
でもembeddedと対になってたりするし、
曖昧な言葉ではあるので文脈がないとどっちにも取れる面はあるなと。

program representationsに関しても最初私もモデルかと思ったけど、
>>661的なテーマも確かにあったりしてそっちな可能性も結構あるなと。
ぶっちゃけこれも文脈を聞かないとイマイチ特定しにくいかも。

664:デフォルトの名無しさん
05/12/12 14:18:55
ACMのDigital Libraryでみつけた論文では
・high level representations
・directly interpretable representations
・directly executable representations
っていう分類してparse treeとか語ったりしてるのと、他にもwikipediaから
URLﾘﾝｸ(en.wikipedia.org)
の中でa portable program representation such as Java or CLR bytecodesって表現があるから660でいいと思う。

同じくACMのDigital Libraryから
mobile code, that is, programs traveling on a heterogeneous network and automatically executing upon arrival at the destination
という言い回しも見つけた。
たぶんモバイル機器向けってことだと思う。（よく知らないけど）

embeddedは何とも言えないけど、組み込み系以外の意味でembeddedっていう単語が使われてるのはあまり見かけない希ガス。
他言語に埋め込むとかは普通inlineじゃないかな？（勘違いしてたらつっこみよろ）

665:654
05/12/12 14:25:24
embedded languageってのを
DSLの文脈で見かけたことがあるような記憶はあるんだが
いまいち定かでなかったりして決定打に欠ける。
その上そこで組み込み機器向けのDSLの話だったのか、
別の言語に埋め込む特定分野向の簡易言語の話だったのか思い出せないので
こんな記憶があっても決定するだけの根拠なし。

666:デフォルトの名無しさん
05/12/12 14:43:52
>>654
> (たとえばGCとか、もっと進んでヒープを使わないプログラミングの可能性とか。

これすごいな。そんなの実現可能なの？
ヒープ使わないとなるとデカイ静的メモリ領域用意して全部つっこむしか思いつかない俺に喝を入れてくれ。

667:デフォルトの名無しさん
05/12/12 14:46:25
>>664
mobile codeの部分だけ反応してみる。
異機種ネットワークを移動し、到達点で自動的に実行するプログラム
ということだから、RPCっぽいことなのかなと思った。

> Programming languages for mobile code
> Tommy Thorn
> ACM Computing Surveys (CSUR)
> Volume 29 , Issue 3 (September 1997)

ただこの論文の冒頭で、「"mobile code"には文章によって様々な
意味を持つ」とか言ってる。
この論文では、「異機種ネットワークを移動し、保護ドメイン
(企業ネットワークからPDAまで)を渡り、到着点で自動的に実行する
ソフトウェア」と定義してる。

けっこう面白そうな論文ぽい。

668:654
05/12/12 14:51:51
私もちゃんとは知らないウロ覚えの聞きかじりなんだが、
何年か前に日本ソフトウェア科学会のとある研究集会あたりで聞いたような気がする。
私の気が確かならば関数型プログラミング方面から来た話で、
プログラムを解析（エスケープ解析とかあたりかなぁ）して
関数呼び出しの階層の中の適切な階層に記憶管理コードを埋め込むような話が
あったような気がする。
ただ3時から仕事上の講演会を聞きに行くので今は調べられない。
戻ってきた後でちょっとググって見る。

669:654
05/12/12 15:11:16
>>666(>>668続き）
PPL2003の招待講演だったNe（希ガス）
URLﾘﾝｸ(www.csg.is.titech.ac.jp)

"Functional Programming without Garbage Collection"
Martin Hofmann (University of Muenchen)
[PSファイル]
URLﾘﾝｸ(www.csg.is.titech.ac.jp)

670:654
05/12/12 15:13:10
ちなみに内容はウロ覚えなんで論文読んで確認されたし。
(聞きに行く講演は15時半からだった。)

671:666
05/12/12 16:03:54
>>669
㌧ｸｽ！
なるほどね。ヒープを使わずに再帰しながらスタックを使う（関数の引数に詰め込む）ってことっぽい。

672:654
05/12/12 18:37:12
>>671
ま、それを手でやったら単に面倒なだけなんだけど
プログラムを解析して自動でそういうように書き換えるって話だったように覚えるんだけど
どうだったかいね。
（最近PDFが多くて生PSのみってあんまりないから今使ってるマシンに
PSプロセッサを入れてないのでURLの論文をまだ読んでない罠。
や、まぁ入れりゃいいだけなんではあるがマンドクセぇという。）

673:デフォルトの名無しさん
05/12/12 19:48:02
スレの質が急激に向上してまいりました

674:デフォルトの名無しさん
05/12/12 20:08:44
スレの質が急激に向上してきたようだね

675:デフォルトの名無しさん
05/12/12 20:27:22
スレの質が急激に向上しているようだな

676:デフォルトの名無しさん
05/12/12 20:41:15
上がってきたと見るや躊躇いなく下げようとしているなｗ

677:デフォルトの名無しさん
05/12/12 20:42:54
>>676
このダッチワイフ野郎。（くうきよめ）

678:デフォルトの名無しさん
05/12/12 21:51:48
PLDIは組み込みシステム向けの言語設計・実装の話題も範囲内だよ。
(過去にEmbedded Systemsってセッションが開かれるくらい)

design and processing of domain-specific languagesの一部っちゃそうなんだけど、
for embedded and of mobile codeは素直に解釈すればいいんじゃないかな。

ていうか、「(他言語やデータへの)埋め込みコード」って、PHPのような言語、
って意味でいいのかな。そんな話題はPLDIでは見た事ないような…(知る限りでは

679:デフォルトの名無しさん
05/12/12 22:40:59
そろそろPOPLの時期ですね。行く人はいますか？

680:デフォルトの名無しさん
05/12/12 23:48:13
>>678
PHPって埋め込みに入るのかな？
あれってタグの外側を標準出力に流してるだけでしょ。
「埋め込める」ってのは見た目の上だけで、Zendのただの宣伝文句に過ぎないと思うんだが。
専門の人とかはどう分類するんだろ？

681:デフォルトの名無しさん
05/12/13 00:23:09
>>679
落ちたので行けません。鬱

>>680
PHPが間違いなら間違いでいいから、
正しくは何が「埋め込み」なのか教えてくれないか。できれば例で。

682:680
05/12/13 00:31:34
>>681
> 正しくは何が「埋め込み」なのか教えてくれないか。
俺もそれとほぼ同義のことを質問してるんだけど。
HTMLのscriptやstyleとかCのインラインアセンブラあたりは埋め込みじゃないかとは思うんだが、PHPはわからんと思っただけ。
ソースの見た目で定義するべきなのか機能で定義するべきなのか。
654の再登場を待つしかなさそうだなｗ

683:デフォルトの名無しさん
05/12/13 00:45:43
>>654ではないが、「他言語やデータへの埋め込みコード」って言ってるぞ。
HTMLのscriptとかがいわゆる「他言語への埋め込みコード」で
PHPがいわゆる「データへの埋め込みコード」というつもりだったんじゃないか。
(>>654がそこまではっきり意識して話したのかはわからないけどな)

どっちにしても、PLDIで見る話じゃないような……(俺も、知る限りでは)

684:デフォルトの名無しさん
05/12/13 00:52:08
>>683
正直、「データへの埋め込み」ってのがイマイチ意味がわかんないんだよなぁ。
できれば解説ｷﾎﾞﾝﾇ。
（あ、ちなみにPHPは<?php～?>の外側も含めた全体がPHPのソースなので、そもそも埋め込みではない思う）

685:デフォルトの名無しさん
05/12/13 01:14:20
>あ、ちなみにPHPは<?php～?>の外側も含めた全体がPHPのソースなので、そもそも埋め込みではない思う

そういう哲学をお持ちの方には、そうですか、としか言いようがございませんね。
あまり一般的な哲学ではないように存じますけれど。

以下、何事もなかったように議論が再開することを願います。

686:681
05/12/13 01:20:12
HTMLのscriptか。納得。
まあこんなことで議論してもしょうがないな。
しかも今見ると>>681はなんだか喧嘩腰だな。
そんなつもりは全くなかったのだが、失礼した。

(煽りの部分は無視して)>>685の言うとおり、
何事もなかったように再開してほしい。

687:デフォルトの名無しさん
05/12/13 01:41:20
ＬＩＳＰはなんなんですか

688:デフォルトの名無しさん
05/12/13 01:43:01
まあ俺はPHPを言語処理系っていう側面から見て埋め込みかどうかに疑問を思ったんだが、興味ない奴は読み飛ばしてくれい。
>>686が良い切り返ししてくれたので先に進むけど、「データへの埋め込み言語」って何だろう？
一瞬スタックオーバーランみたいにマシンコード埋め込んで攻撃することだと思ったんだけど違うよね？
あーマシン語は「言語」じゃないか・・・

689:デフォルトの名無しさん
05/12/13 01:46:03
どうか>>687をスルーしてくれ

690:デフォルトの名無しさん
05/12/13 01:55:57
embedded ruby

691:デフォルトの名無しさん
05/12/13 03:42:12
たいていのプログラミング言語に対して正規表現が使えるけど、
あれは一種の埋め込み言語であると思う。

692:デフォルトの名無しさん
05/12/13 03:57:10
>>691
なるほど。確かに。
大抵は正規表現用に、言語自体の字句解析とかとは別口のモジュールで解析してるもんな。

693:デフォルトの名無しさん
05/12/13 04:06:40
たいていのプログラミング言語に対して整数が使えるけど、
あれは一種の埋め込み言語であると思う。

って言ってるのと変わらないぞ、それ。

ていうか、「埋め込み」の厳密な定義なんてないんじゃね？
「埋め込み」の厳密な意味を議論する意義はあるの？

と思いつつも>>654に集まる期待。

694:デフォルトの名無しさん
05/12/13 04:42:12
>>693
> ていうか、「埋め込み」の厳密な定義なんてないんじゃね？
> 「埋め込み」の厳密な意味を議論する意義はあるの？

むしろembedded＝組み込み系って流れじゃなかったっけ？
このスレなんかおかしな方向に行ってるな。

695:デフォルトの名無しさん
05/12/13 04:42:20
プログラム言語なんか研究してる人がいるんだね。
あんなのは有名なのも含めて全部趣味で俺言語作ってるのと
同じレベルだと思ってた。
まさか真面目に研究した成果が、あの行き当たりばったりの
つぎはぎだらけの仕様とはねｗ

696:デフォルトの名無しさん
05/12/13 04:51:01
正直、仕様がつぎはぎになるまで使われる言語なんて全体の 0.1% にも満たないと思うんだが。

697:デフォルトの名無しさん
05/12/13 04:52:38
D言語は最初からつぎはぎでしたが何か？

698:デフォルトの名無しさん
05/12/13 04:53:02
まあいいじゃん。楽しく俺言語つくろうぜ。

699:デフォルトの名無しさん
05/12/13 04:54:28
>>697
つぎはぎってそういう意味なのか？

700:デフォルトの名無しさん
05/12/13 04:55:57
おまいら、>>695みたいな100%の釣りですらスルーできないのかよ…
>>680のような巧妙な釣り(後であからさまになったけど)ならともかく…

701:デフォルトの名無しさん
05/12/13 04:57:30
釣って釣られて盛り上がるのが醍醐味ですが何か？

702:デフォルトの名無しさん
05/12/13 04:57:59
>>700
自分たちでも理解できるレベルになったのが、
嬉しくてしょうがないんだろう。ほっといてやれ……

703:デフォルトの名無しさん
05/12/13 05:03:01
それじゃそろそろprogram representationsとインテンショナル・プログラミングの話をしようか

704:デフォルトの名無しさん
05/12/13 07:29:09
>>696
Ｃ言語の事でつか？

705:デフォルトの名無しさん
05/12/13 10:24:35
>>694
embeddedのIT業界でのデフォはそれで正解
ただ、ここは言語すれなので

706:654
05/12/13 11:07:54
期待されても大して何もでないぞ。

埋め込まれた言語っていってもHTMLファイル
（データ記述のための言語で書かれたデータなんでデータでもあり言語でもあり）
にスクリプトを～くらいしか念頭にはなかったし。
（ちなみにJavaScriptあたりをイメージしてた。PHPはよーしらんです。）

まぁ、ライブラリで提供される正規表現を言語内に埋め込まれた言語と見る
というのもあるかなとは思う。
それに整数など数値演算が埋め込まれた言語というのは
理論上そういう観点もありえなくはないかなという気がする。
こういうのは視点の問題であって一つの存在が一通りにしか解釈できないと
決まったものでもないわけで。

大体今時の言語の文法定義自身が再帰的に部分文法を"埋め込んで"定義されてるわけで
この観点から言えば埋め込まれてる言語とホスト（宿主）言語の区別ってのは
結構便宜的なモンでしかないんじゃないかと思う。
分けて考えるのが便利なときは分けて考えることもできるし、
全体で一個の文法と見るのが便利ならばそう見ても問題ない。

余談だけどそう思ってみると
数値演算につきものの演算子の結合や優先順位の規則の文法的表現ってのは
言語の文法定義の中でもそれ以外の部分とは若干異質な部分でもある。
言語定義をする人は皆、当たり前なんで慣れてしまっているけどね。

707:654
05/12/13 11:37:54
例をあげて考えてみる。

まずはライブラリなどとして提供されるユーザ定義のデータ型が
ベースとなる言語に埋め込まれてベースとなる言語を拡張している例。
データ型といっても整数演算くらいだと見慣れているだろうし、
あんまりピンとこないかもしれない。
けども複雑なテキストデータは実際にパースしないといけないわけだから
単に観念の問題ではなくて技術的にも結構言語チックではある。
既に出ている正規表現もそうだし、例えば昔、私が多項式型を作ったときには
多項式のインスタンスを文字列リテラルで初期化するようにしてみたことがあって
このような場合だと単にユーザ定義のデータ型のリテラル
（正確にはそのように見立てた文字列リテラル）の癖に
その中に「変数」（数学的には不定元か）や「演算子」なんかがあって
その"埋め込まれた"リテラルの扱いはミニ言語っぽくなる。
多項式はデータ・値として4則演算の対象であると同時に
実際に値を代入（数式処理的には「置換」）することで関数のように評価もできたりする。

逆に通常一個の言語として見ている言語の定義を
幾つかのミニ言語を埋め込んで組み立ててあるとみることも実際に可能。
例えばC++を
式言語を制御構造言語に埋め込んでそれを関数宣言言語に埋め込んで、
それらと単純型宣言言語を合わせてクラス宣言言語に埋め込んで、
さらにそれをtemplate宣言言語に埋め込んだものとして考えることもできる。
この時例えばtemplate宣言言語は関数型言語として見ることができて
実際にそのようにプログラミングすることもできるというのが
テンプレート・メタプログラミングだったりする。

708:デフォルトの名無しさん
05/12/13 12:16:37
>>706-707
禿しく納得した。あんたにゃ脱帽。

709:デフォルトの名無しさん
05/12/13 13:23:05
>>654って例の、外国人とRubyに悩まされてる人か？
もしそうならかなり煮詰まってるな。

710:デフォルトの名無しさん
05/12/13 14:06:54
>>709
な、なぜそう思うのかな？

711:デフォルトの名無しさん
05/12/13 15:08:51
>>709の元ネタがよくわからん罠

712:デフォルトの名無しさん
05/12/13 15:12:04
ｽﾚﾘﾝｸ(prog板:924番)
と思われ。

713:デフォルトの名無しさん
05/12/13 15:12:40
いずれにせよ、Rubyに好意を持っていない所から類推すると、
研究畑の人間だと思われる。

714:デフォルトの名無しさん
05/12/13 15:14:23
>654は別にRubyについては何も書いてないよな。

715:デフォルトの名無しさん
05/12/13 16:12:53
>>713
研究の人はルビー嫌いなの？

716:デフォルトの名無しさん
05/12/13 16:22:54
>>715
いんや、少なくとも>>712のリンク先のそのまたリンク先のヨーロッパ人研究者には大好評のようだゾ。

717:デフォルトの名無しさん
05/12/13 16:32:43
日本の研究の人は、自分よりも名前が売れていることでRubyを妬んでいるのです

718:デフォルトの名無しさん
05/12/13 16:44:49
妬むかどうかはさておきRubyの人が（昔はリーマンしながら作ってたようだけども）
いまやオレ言語で食えているのがウラマヤシクないと言えば嘘になろう。

プログラミング言語研究も成熟してきた昨今、
どうしても言語研究で食っていこうとすれば全く新しい俺言語の開発ではなく
言語の一部（例えば既存言語の拡張とか最適化とか）をテーマにすることに
ならざるを得ないが、言語屋の多くは俺言語への夢ってモンをやっぱり持ってるからな。

まぁそういう研究屋業界の世知辛い世情はRubyの人も（出身は言語屋なわけだし）
分かってるからあくまで彼が自称するのは言語オタクであって
研究者とは名乗らないし、開発に徹して研究者的な活動には深入りしないのだろう。

719:デフォルトの名無しさん
05/12/13 16:47:28
>>710
>>714の言う通りRubyについちゃ何も言ってないんだけど、
>>654の最後の「風変わりな実装」と「Windowsに移植」ってとこでそう推測した。
あと>>707であげられている例やら「埋め込まれた言語」に対する態度やらから
そうなのかなあと。
過去ログを調べたら、例の人を2chで初めて見かけたのは2ヶ月以上前だ。
まあ>>654とは別人だろうな。

720:デフォルトの名無しさん
05/12/13 16:50:22
>>712の引用のしかたにﾜﾛﾀ
マ板経由かよｗ

721:デフォルトの名無しさん
05/12/13 16:51:47
別段Rubyに含むところはないが
Unitテストもなしに6万行もあるバギーな拡張ライブラリはキライｗ
特にキャストやテンプレートを濫用して型がスパゲティ化しているプログラムはｗ

722:デフォルトの名無しさん
05/12/13 17:16:30
Rubyとかそういう問題じゃないな。
他の言語でもそれは嫌だぞ。

723:デフォルトの名無しさん
05/12/13 17:28:21
>>722
まぁ、そういうことですよｗ
Rubyが使われてるプログラムの移植でヒドい目に合ってるからRubyの話題も出るけど
それは多分に使い方の問題であってRubyの問題じゃない。

例えば、C++でそんなデカイもんを作るなら最初からC++で書いてRubyから呼び出すとか、
RubyでBisonやflexやXMLパーサ用のコードを生成するとかなんて構造・設計は
勘弁なってくらいでいずれも問題はRubyそのもの良し悪しや好き嫌いの話ではない。

以上誤解のないように。

724:デフォルトの名無しさん
05/12/13 17:30:15
謹んで訂正>>723

誤> 例えば、C++でそんなデカイもんを作るなら最初からC++で書いてRubyから呼び出すとか、
正> 例えば、C++でそんなデカイもんを作るなら最初からC++で書いておいてくれればよいわけで、
Rubyから呼び出すとか、

725:デフォルトの名無しさん
05/12/13 17:43:02
やっぱRubyじゃ巨大プロジェクトの開発は無理か。
せいぜい数千行程度？

726:デフォルトの名無しさん
05/12/13 18:25:20
さぁ？

「やっぱ」とあるが>>723-724はそういう問題ではないだろう。

まぁ、一応Script言語はそれ単体であまり大きな規模の開発を行うことは
想定してないとは思うので個人的にそういう目的に用いることをオススメはしないが、
どこにそのラインがあるかは自明でないのでキッパリ無理とも言い切れない。

727:デフォルトの名無しさん
05/12/13 18:27:04
>>725
別にRubyで何万行書いてもいい。
むしろRubyだけで書く限りであればそれほど問題はないと思う。
Rubyがアホなとこは、そうやって書くと思いっ切り遅くなることがわかってるから、
現実は他の速い言語で拡張ライブラリ作ってツギハギしてくしかないってこと。
拡張ライブラリが順調に動いている内はいい。が、そこでバグが発生したりすると
もうグダグダになる。拡張ライブラリが絡むと環境やモジュール連続性もなく
まず原因の特定が困難で専用のデバグ環境もない。もはやまともなデバグなど
期待できない。だから拡張ライブラリを書いた場合は事前のテストが重要となる。
が、現実はこれをまともにやっている人間は少ないようだ。
ほんとは他の言語で書かす拡張ライブラリみたいなアホな非常口は言語の
作者の目の届かない所でもあるし、とっとと廃止した方がいいのだけど、
Rubyはそれをいつまでもやめないし、既にRubyの仕様上速くなる手段は
閉ざされており、もう誰もがアホだとわかっていてもその非常口に突っ込んで
自滅するしかない、という悪循環がどうみても出来上がっていました。
ありがとうございました。

728:デフォルトの名無しさん
05/12/13 18:30:33
精子コピペすか？

729:デフォルトの名無しさん
05/12/13 18:34:25
わかってはいるが、わかるわけにはいかん！
というやつだね。
墓穴は掘り終わりましたか？

730:デフォルトの名無しさん
05/12/13 18:41:06
>>727
遅くなるって言うけど
手軽さではなく早さが求められるようなプロジェクトで
Script言語を選んじゃう見識は問われないの？

731:デフォルトの名無しさん
05/12/13 18:51:28
言語というより、開発手法や設計のお話だな。

732:デフォルトの名無しさん
05/12/13 18:52:31
この件でRubyの拡張ライブラリがヤバイ事はよくわかった。

733:デフォルトの名無しさん
05/12/13 18:59:05
そういやRubyはVMにできないみたいな話が以前のスレにあった気がするけどあれってなぜ？

734:デフォルトの名無しさん
05/12/13 19:08:15
そろそろスレ違いに気づけ。
Rubyヤバイとかは専用スレがあるんだからそこで騒げ。

735:デフォルトの名無しさん
05/12/13 19:11:25
>>725
デカいプロジェクトだと開発以前に、運用で却下。
保守できる人間が少ないのは怖いし。
もっともここで話す問題ではないが。

736:デフォルトの名無しさん
05/12/13 19:29:06
そう思うなら余所逝けよ。

737:デフォルトの名無しさん
05/12/13 22:21:58
ちょっと勘違いしてるようだけど、数千行のRubyコードって
数十万行のLispコードに匹敵する処理内容が記述できるでしょ。
なので、スクリプト言語≒簡易処理というのは全くの思い違いだと思うよ。

速度が遅くなるのは同意だけど、

738:デフォルトの名無しさん
05/12/13 22:24:27
オ～レ～～～。オ～レ～～～。ジャカジャカジャン！
ま・つ・け・ん・さあ～んば～～～

739:デフォルトの名無しさん
05/12/13 22:48:17
数十万行のC言語のコード、というならともかく・・・

740:デフォルトの名無しさん
05/12/13 23:16:02
>>737
だいぶ勘違いしてるようだけど、RubyとLisp比較するなら
記述量的にはあんま変わらない気がするけどな。
速度気にするならまともなコンパイラ付いてるLispで書いた方が
良かったんじゃないの？
Rubyと違って処理系も色々選択できるし、拡張ライブラリを
速度のために別言語で書く、みたいな馬鹿馬鹿しい問題もない。

741:デフォルトの名無しさん
05/12/13 23:27:55
Lispは、チェックを省いてプロトタイプを作ろうとすると、めちゃくちゃ少ないコード記述量に
なるけど、パフォーマンスを考えてチューニングしようとしたり、エラーチェックを厳密に
やろうとすると他の言語と同じぐらいになってしまう。

742:デフォルトの名無しさん
05/12/13 23:55:27
>>741
憶測だけで言ってない？
つか、付けたしだけで速くなるなら別の言語で書き直すよりは
そっちの方がいいよね。
下のサイト見ると行数もそれほど変わらないし
チューニングコード入れなくても速いみたいだが。
元々速度では勝負にならん差があるけど。

Ruby
URLﾘﾝｸ(shootout.alioth.debian.org)

Lisp
URLﾘﾝｸ(shootout.alioth.debian.org)
URLﾘﾝｸ(shootout.alioth.debian.org)

743:デフォルトの名無しさん
05/12/14 00:14:14
>>742
Rubyが速度で上回るのはstartupだけか。
ひでえなこりゃ。
Rubyってコンパイラ作れないの？

744:デフォルトの名無しさん
05/12/14 00:31:28
ハッキリ言ってしまえば、速度なぞ時間がすぐに解決するんだけどなw
リアル社会を知らない音質Lisperはアクキンにしる！

745:デフォルトの名無しさん
05/12/14 00:33:18
>>743
コンパイラは作ってもあまり意味がないというか、
そもそも作る人がいないという話だった気がする。

746:デフォルトの名無しさん
05/12/14 00:33:43
>>743
作れるはずだし、
作ってる人も（複数人）いるっぽい。
実用になったという話は聞いてないけど。

次ページ