05/11/27 21:17:41
T=term F=factor E=expression
だろうな。Ｈはワカンネ。
533:デフォルトの名無しさん
05/11/27 21:24:14
>>532
その理屈でいくとHにあたる部分はstatementのはずだよね。
ソースちょっと読んでみた感じでもセミコロンまでの部分を処理してるっぽいから文のはずだけどHって・・・？
534:デフォルトの名無しさん
05/11/27 21:32:50
>>527
たしかに内容自体は古臭いけど通用する
書かれている技術云々より著者の考えてることを文から読み取るだけでも勉強になるよ
535:デフォルトの名無しさん
05/11/27 21:33:58
H=Hyouka
俺はこれだと思うね。かなり自信あるよ。
536:デフォルトの名無しさん
05/11/27 21:37:08
H=アレだよアレ。
(*/∇＼*)ｷｬ 恥ずかしい♪.
537:デフォルトの名無しさん
05/11/27 21:37:45
>>534
マジでいってんの？正気？
……釣られてる？ 俺、釣られてる？
538:デフォルトの名無しさん
05/11/27 22:24:07
>>537
その文だけじゃ君が何を主張したいのかわからないんだが
539:デフォルトの名無しさん
05/11/27 22:38:12
>>537
著者の考えてる事云々辺りに対して言ってるのかなと予想。
後524!=534だから皮肉になってない。
540:デフォルトの名無しさん
05/11/27 22:42:20
業界で成功した人物の著書ぐらい素直に読んどけよ
541:デフォルトの名無しさん
05/11/27 23:02:40
そう言えば、うち新入社員にこんな宿題出してたなぁ（ｗ
542:デフォルトの名無しさん
05/11/27 23:03:13
いちいち反論しないと気がすまないガキかよ
543:デフォルトの名無しさん
05/11/27 23:06:05
すまん
反論というより、ただの反抗だな
544:デフォルトの名無しさん
05/11/27 23:12:54
いや～、すまん、すまん
545:デフォルトの名無しさん
05/11/27 23:39:50
>>506
一応超適当に動作するようにはした。
URLﾘﾝｸ(read.kir.jp)
546:デフォルトの名無しさん
05/12/01 08:41:18
Ｃ言語でbisonを使って構文解析をして構文木を作るとき、
コンパイルに成功するといいんですが
文法エラーがあったときに途中まで作ったノードが
メモリリークしてしまうんですが
どう解決してますか？
547:デフォルトの名無しさん
05/12/01 08:51:55
ノード生成時にbisonへ渡す物とルートからたどれる単方向リンクリストの両方に登録する。
成功した場合はソースの解析ツリーから全部たどれるからメモリが漏れないのだから、
失敗することの為に純然たる生成順のリストがあっても屁でもない。
548:546
05/12/01 10:41:06
thx!やっぱそうだよね
549:デフォルトの名無しさん
05/12/01 20:56:27
>>546
それって365日稼働する必要あんの？連続で
550:546
05/12/01 22:00:15
>>549
お前の意見なんか誰も聞いてねーよ
回線切って猿山に帰れ
551:デフォルトの名無しさん
05/12/01 22:26:32
何だこいつ？
そんなのリークとは言わんよw
552:デフォルトの名無しさん
05/12/01 22:57:07
>>551
えーと、もう話は解決してるようだけど
メモリプール使えだとか、これからつまんない話を披露する気なの？
553:デフォルトの名無しさん
05/12/01 23:26:06
>>550
粗れる原因つくってるいつもの香具師だ。
スルーよろ。
554:デフォルトの名無しさん
05/12/01 23:42:34
失敗したらすぐ終了してメモリの解放はOSまかせにすればいいって話だろ。
正味な話、ライフサイクルの短いプログラムでは
メモリの解放忘れがメモリリークにつながることは少ない。
555:デフォルトの名無しさん
05/12/01 23:49:00
メモリの解放忘れ＝メモリリーク
じゃないの？
556:デフォルトの名無しさん
05/12/02 00:10:41
>>554
はいはいうざいうざい
その手の話は聞き飽きた。
557:デフォルトの名無しさん
05/12/02 00:18:40
メモリリークって？
bison にバグがあったの？
558:デフォルトの名無しさん
05/12/02 00:23:23
なんでそんな文盲なんだよ
559:デフォルトの名無しさん
05/12/02 02:00:35
>>554
組み込みスクリプト用途を考えるとエラー停止しただけで
リークなんて考えられんけど。
おまえら作る時はリークチェッカ用意してテストぐらいしとけよ。
560:デフォルトの名無しさん
05/12/02 02:53:05
メモリリークごときで騒いでんじゃねぇよ肉体労働者
561:デフォルトの名無しさん
05/12/02 02:55:29
ふらぐめんて～しょん？
562:デフォルトの名無しさん
05/12/02 08:54:06
mallocしたあとfreeしなくてもry
563:デフォルトの名無しさん
05/12/02 09:19:38
重箱隅研究では大問題。
実際は、OSが（ry
564:デフォルトの名無しさん
05/12/02 09:28:06
実際は、コンパイラにもバグが（ry
まあ、これはたいがいは最適化オプション絡みだったりするから、
最適化オプションを外すだけで解決したりするけどな。
何処の製品とは言わんケド。
565:デフォルトの名無しさん
05/12/02 16:20:18
>>560
ばーかばーか
>>562
ばーかばーか
全員死んでこいや
お前らみたいなへたれがこのスレにいるってだけで吐き気がするぜ
あ？メモリリーク？そんなもんが怖くて中学生やってられっかってんだ
それよりもC言語教えてください
566:デフォルトの名無しさん
05/12/02 16:27:04
帰れ低能
567:デフォルトの名無しさん
05/12/02 21:34:48
こんなのリークいわんやろ？あほちゃうかw
現実を知らん馬鹿研究者ならでわなやw
568:デフォルトの名無しさん
05/12/02 22:04:19
> ならではなや
569:デフォルトの名無しさん
05/12/03 18:14:32
蛆研究乙w
570:デフォルトの名無しさん
05/12/03 18:15:55
ならではやな。やな！
ほな！失礼したどす～。
571:デフォルトの名無しさん
05/12/03 20:05:53
どちらかといえば、研究もタッチしてるのかもしれない洩れだけど、
そりゃ中田先生みたいに実務もバリバリこなせるような研究者にはあこがれるけど、
あれって、（先生の実力は本当にすごいと思うけど）案外運もあるんじゃないのかなぁ
とも思って自分を慰めてまつ。
トホホ、
572:デフォルトの名無しさん
05/12/03 23:33:12
>>571
立場や肩書きという物がどうしても必要な場面もあるし、いいたかないけど上が抜けてくれないとポストが空かない事実はどうしようもないのである意味運かもしれません。
573:デフォルトの名無しさん
05/12/04 12:34:37
コンパイラの作り方 (詳解
URLﾘﾝｸ(www.is.s.u-tokyo.ac.jp)
574:デフォルトの名無しさん
05/12/04 12:50:40
>>573
こゆ講義は楽しいだろうなぁ。俺もやりたい。
575:デフォルトの名無しさん
05/12/04 14:03:42
>>573
＞演習で実装する言語はSchemeのsubsetで
ここまで読んだ
というか、ここで読むのをやめた
576:デフォルトの名無しさん
05/12/04 15:11:36
>>573
その実習って、グループに分かれてFPGAを使用した独自アーキテクチャのCPU設計&実装、
そのアーキテクチャ用クロスコンパイラの製作、
その上で動くレイトレプログラムの実装、までやるんだよな。
さすが灯台だとおもた。
577:デフォルトの名無しさん
05/12/04 15:12:17
どっかでＯＳの作り方をやってくれんかな？……って、板違いか。ＯＳ板に逝ってくる。
578:デフォルトの名無しさん
05/12/04 15:50:48
>>573
早速印刷して、読んでみることにしたよ。うｐしてくれた人、ＧＪ！
三流痴呆国立大卒修士で、Ｓｃｈｅｍｅは少しかじってるので、何とか読めるかな。
学生時代、こういう面白い講義や実習はなかったもんなぁ。
灯台逝くほど頭良くなかったし。
579:デフォルトの名無しさん
05/12/04 16:45:49
URLﾘﾝｸ(mitpress.mit.edu)
多分SICP読んだ方が早いぞ。
580:デフォルトの名無しさん
05/12/04 17:04:33
SICPとは目指すものがかなり違うと思うが
581:５７８
05/12/04 17:07:16
ＳＩＣＰも購入して持ってるので、両方読みます。
582:デフォルトの名無しさん
05/12/04 18:56:03
やっぱり、東大の先生のような頭がいい人はschemeの良さがわかってるんだな。
583:デフォルトの名無しさん
05/12/04 20:00:11
schemeの良さというよりも、実装の容易性を重視しているのではないかね。
584:デフォルトの名無しさん
05/12/04 20:14:16
今はもうSchemeじゃなくて、MinCamlだよ。
585:デフォルトの名無しさん
05/12/04 20:38:48
やっぱり、東大の先生のような頭がいい人はlispの良さもわかってるんだな。
586:デフォルトの名無しさん
05/12/04 22:26:46
キチガイホイホイ言語
587:デフォルトの名無しさん
05/12/04 22:29:53
というか日本だと狭い世界だから研究してる人はこの人ととは知り合いだろう。
今も同じとこにいるのかは知らないけどさ。で，この分野の研究しててschemeは
避けて通れないよ。表示意味論的にクリーンな言語はやっぱ重宝する。MLとか
Haskellとかあるけど，やっぱ未だに基本はschemeって感じ。
588:デフォルトの名無しさん
05/12/04 22:55:27
研究してる人、って単数かよ。狭すぎるぞ。
未だに主流がSchemeかどうかは知らんが、
当分の間は避けて通れる道ではないのは同意。
ただ、最近ではMLやHaskellも避けては通れないぞ。
589:デフォルトの名無しさん
05/12/04 23:05:06
やっぱり、東大の先生のような頭のいい人は、rubyの（ry
590:デフォルトの名無しさん
05/12/04 23:09:59
釣りはいらん
とっとけ
591:デフォルトの名無しさん
05/12/04 23:32:16
Rubyが言語理論の研究に適切だと主張する馬鹿は、
さすがに見たことが無いな。
592:デフォルトの名無しさん
05/12/04 23:35:42
コンパイラとかの実装を話すときは、
Pascal, C/C++, Lisp/Scheme, Forth, ML, Haskell
あたりは抑えておくべき？
593:デフォルトの名無しさん
05/12/04 23:37:09
とりあえず、機械語は抑えておけ
594:デフォルトの名無しさん
05/12/05 00:58:12
「抑える」んだ
595:デフォルトの名無しさん
05/12/05 01:09:56
∧＿∧
（*´∀｀） 了解だ！
人 Y /
( ヽ し
（＿）＿）
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
作れるはずだし、
作ってる人も（複数人）いるっぽい。
実用になったという話は聞いてないけど。
747:デフォルトの名無しさん
05/12/14 00:41:45
>>744
Ｒｕｂｙはそう言われてきたＪａｖａと事情がだいぶ違うし
言語仕様的に無理かも。
あと１０年待とうね。
748:デフォルトの名無しさん
05/12/14 00:44:51
プロセッサがマルチコア方向にシフトしてきてるっぽいので、
ネイティブスレッドに対応しないと辛いかもね。
749:デフォルトの名無しさん
05/12/14 00:49:15
>>742
おいおい、そこのコードは速度を上げるために
かなりチューニングしてるぞ。
少なくかけるところをあえて速度が上がるような
書き方してる。
750:デフォルトの名無しさん
05/12/14 00:49:52
だから、コード量は、本当はlispはめちゃくちゃ少ないよ。
751:デフォルトの名無しさん
05/12/14 00:50:18
PythonはPython自身で書かれたり他の言語やVMに変換して速くしたりできるっぽい
そういう意味ではPythonの方は将来期待できるかも
752:デフォルトの名無しさん
05/12/14 00:53:09
これなんて象徴的だよな。
本当は5行で終わるところを12行かけて書いてる。
コメントにその5行のコードが書いてあるｗ
URLﾘﾝｸ(shootout.alioth.debian.org)
753:デフォルトの名無しさん
05/12/14 00:56:25
Pythonって構文をちょっと変えたLispそのものだからな
754:デフォルトの名無しさん
05/12/14 01:03:49
出来るだけタイプ量少なくすることで競うならperlが最強。
755:デフォルトの名無しさん
05/12/14 01:04:33
>>752
そのコメント部だけのコードでも動的言語の割には結構速度出るね。
やっぱこの差はネイティブコンパイルしてるからかね。
756:デフォルトの名無しさん
05/12/14 01:04:59
>>754
C++は最下位。
757:デフォルトの名無しさん
05/12/14 01:08:10
>>756
COBOLだろ
758:デフォルトの名無しさん
05/12/14 01:12:24
>>754
LispやSmalltalkなんかは前提とするコアイメージ弄くればなんでも1行で書けるよ。
それに配布物も本体とコアファイルの２ファイルだけで
perlみたいにごちゃごちゃライブラリディレクトリ掘ったりする必要ないし。
759:デフォルトの名無しさん
05/12/14 02:01:41
いや待て、言語同士を競争させるのにコアやライブラリを弄っちゃいかんだろ。
760:デフォルトの名無しさん
05/12/14 02:13:34
Smalltalkならいじるのが当たり前なんだが
761:デフォルトの名無しさん
05/12/14 02:31:30
ライブラリ弄っていいんだったらどの言語でも1～数行で終わって
比較する意味ないじゃん。
762:デフォルトの名無しさん
05/12/14 03:17:26
ライブラリ弄るとかいう発想じゃなくて、LispやSmalltalkでは
言語環境が最初から違うスタート地点に立てる、という観点が
使ったことのない人には想像つかないのかな。
OSで言えば最初からスタンバイ状態になってると考えればいい。
そもそも「出来るだけタイプ量少なくすることで競う」って話だし。
763:デフォルトの名無しさん
05/12/14 03:19:35
いやいや駄目でしょ。
Lispは結構知ってるし、Smalltalkもある程度は知ってるけどさ。
標準ライブラリで、標準のコアで勝負でしょ。
764:デフォルトの名無しさん
05/12/14 03:22:05
まあ拡張を定義した部分まで行数に入れるんだったら
もちろんいい。
765:デフォルトの名無しさん
05/12/14 03:23:18
他の言語じゃ不可能な時点で勝負にもなんないね。
766:デフォルトの名無しさん
05/12/14 03:23:25
あと、その言語として自然な記述で比べること。
7行プログラミングスレみたいな奇怪なコードならCでも短くなるけど、
そういうコードで比べるのも反則。
767:デフォルトの名無しさん
05/12/14 03:23:52
>>765
別に不可能じゃないよ。ライブラリなんてどの言語でも書ける。
768:デフォルトの名無しさん
05/12/14 03:27:34
>>766
ああいう奇怪なコードで書くのがPerlの自然な流儀ですが何か？
769:デフォルトの名無しさん
05/12/14 03:27:56
こんな夜中に何を必死になってんだ
770:デフォルトの名無しさん
05/12/14 03:46:42
>>767
知ってていってるならしょうがないが
開発環境と実行環境が一体化してるもんだから
単なるライブラリとは違う。
771:デフォルトの名無しさん
05/12/14 03:59:21
いくらそんなこと言ったって、同じにしなくちゃ駄目だろう。
やっぱりライブラリを作ってこれ使えば一行とか言ってるのと同じぐらい
反則に俺には感じる。
772:デフォルトの名無しさん
05/12/14 04:00:09
いい加減宗教戦争は勘弁して下さいよ、本当に。
773:デフォルトの名無しさん
05/12/14 04:56:09
スレの質が急激に低下してまいりました
774:デフォルトの名無しさん
05/12/14 05:33:44
>>1 に出てくる語句について教えてください。
「データ分散」って何ですか? NUMAとかのヘテロなアーキテクチャでの話?
「スクラッチメモリ」って何ですか? CellのSPEが持っているような
プロセサ固有のメモリ?
775:デフォルトの名無しさん
05/12/14 05:54:04
>>773
おまえが上質なネタを投下しろよ
776:デフォルトの名無しさん
05/12/14 06:08:41
>>775
おまえが上質なネタを投下しろよ
777:デフォルトの名無しさん
05/12/14 06:51:03
>>774
>>1に聞けよ
778:デフォルトの名無しさん
05/12/14 08:16:38
HTML化されてる最初のスレはかなりレベル高かったみたいだね。
今の>>1-5のテンプレはいつごろからあったんだろ？
779:デフォルトの名無しさん
05/12/14 14:52:11
>>774
厳密にはともかく概ねそれで合ってんじゃない？
>>772
宗教戦争になるのは
優劣を計ろうとしていながら物差しがちゃんと定義＆評価されてないからだと思う。
言語設計ということを理解するに当たって既存の言語を比較対照することそのものは
悪くないと思うのだけれど、基準が独りよがりすぎるから感情論になる。
それにRubyがでてくるのは話の流れとしてまだわかるが
Lispはいくらなんでも唐突過ぎる。
イキナリRubyと比較してるが使われる局面も設計時の背景や目的も明らかに違うから
何を比較したいのだかよーわからんことになってる。
言語設計の課題は設計目的にどのくらい適っているかどうかだし、
言語選択の問題は開発対象の性質に言語がどのくらい適合しているかだろう。
いずれにせよ目的も基準もハッキリしない漠然とした優劣は問題ではない。
780:デフォルトの名無しさん
05/12/14 14:55:35
プログラムの長さ、記述量が問題になっていたようだが…
情報理論の教えるところによって符号化という視点で考えれば
プログラムもまたプログラムの仕様という情報を符号化したもの。
言語が違えば符号化の体系が違うと考えられるわけで、
単純にコードの文字数を云々することにはあまり意味がない。
例えばコードの中でよく使われるパターンが短く、
あまり使われない構文が長くといった設計上の戦略もある筈だから
どういう目的で設計されているかということを考える必要がある。
また誤り訂正符号などの例のように純粋に内容の情報
（プログラムなら例えば中心となる内容はデータ構造とアルゴリズムだろう）
だけでなく誤りを見つけやすくするための付加情報が含まれるケースもある。
特にプログラミング言語という符号体系は人と機械の間をとりもつ際の
ユーザ側インターフェイスであるわけで
人の認知科学的な処理特性を無視することはできない。
例えば制御文と式と宣言文の構文が分かれていたり、
意味が連想しやすい名前がキーワードに使われるとか、
ユーザが把握しやすい動作モデルを提供するというのは
文字数単位でコード量（端的にはタイプする量）が増えても
そういう観点からは意味がある。
781:デフォルトの名無しさん
05/12/14 15:01:42
>>778
4からじゃね？
782:デフォルトの名無しさん
05/12/14 15:07:53
>>779-780
なげーよ
日記なら他所でやれ
783:デフォルトの名無しさん
05/12/14 15:20:39
言語の設計には必ず設計目的があり、
設計目的はその時点での背景がある。
そういうことを考えずに闇雲に優劣をつけようとするのは無意味なことだ。
以下に技術的背景が言語設計に及ぼした影響について幾つか例を挙げる。
まず言語は既存言語の存在を前提にしている。新しいものは特にそうだ。
Javaの例で言えば：
JavaはCが存在していて必要ならば使うことができることが前提だから
比較的汎用指向の言語でありながら
Cで書くことが適切であるようなハードウェアレベルの記述機能を
潔くスッパリ切り捨てた設計ができている。
例えば、バイトコード＆仮想マシンの採用やポインタ演算の放棄などがそうだろう。
Javaではそれらと引き換えにより厳密な静的型検査が可能になり、
それがバイトコードの検証といったセキュリティ技術、
ひいてはモバイル・コードの実現といった当初の設計目標を支援している。
784:デフォルトの名無しさん
05/12/14 15:21:25
また、言語は設計当時の技術水準を前提にして設計されているし、
当時重要であった課題を優先して解決するように設計されている。
FORTRANの例で言えば：
FORTRANの行指向な言語設計は行単位に1枚のカードが使われていた
ハードウェア技術に大きな影響を受けている。
構文解析が案外面倒な面倒な算術式のパース技術が取り入れられた背景としては
当時算術演算を手軽に記述できる言語が他になく正にそれが求められていたからだ。
その一方で計算機のメモリやディスクの容量が限られていたこともあって
プログラム規模が当時は現代より比較的小さかったので
ユーザ定義のデータ型への需要は相対的に小さかったためそういう機能は貧弱だ。
LISPの例で言えば：
何よりAI研究で必要な柔軟なデータ形式である
リンクリストやそれを利用したツリーを簡単に操作できることが優先目標だったから
それが充実している一方で、算術式はお世辞に読みやすいとは言えないし、
効率のよいランダムアクセス可能な配列といった機能はなかった。
（近年LISPを語る際によく言及される、
メタな機構が充実したのはちょっと後のことで誕生当時の古LISPでのことではなかった筈だ。
言語のメタな構造がLISPが解く意図するツリー構造と相性がよかったこと、
元々の適用分野がAI研究だったことなどが影響しているのだろう。）
785:訂正
05/12/14 15:24:35
解く意図する→得意とする
786:デフォルトの名無しさん
05/12/14 15:25:54
ここは公開オナニー劇場ですか
787:デフォルトの名無しさん
05/12/14 15:26:55
宗教戦争なんてしてたっけ。
788:デフォルトの名無しさん
05/12/14 15:27:18
>>782
日記など書く趣味はないよ。
言語戦争の発端のグチを>>654-の記事の一部にポロっと書いた責任を取って
正攻法で技術論に戻して収拾しようとしてるだけ。
789:デフォルトの名無しさん
05/12/14 15:33:02
ｳｻﾞｽ
２、３行で要約しろよ
790:デフォルトの名無しさん
05/12/14 15:36:33
冗長でも誤りを見つけやすくするため云々は一理あるけど、
冗長に書かないといけないせいで入るバグもあるから
トレードオフであることは意識しないとね。
「把握しやすい」ってのも、
その感覚はユーザによってばらつきがとても大きい。
これを意識しないで話すと宗教戦争になる。
791:デフォルトの名無しさん
05/12/14 15:41:37
>>787
顛末は例によってRubyが貶されて信者が暴れただけ。
792:デフォルトの名無しさん
05/12/14 16:10:36
>>783-784
知識の垂れ流し、結構なことです。
が、ここはお前の落書き帳じゃねーんですよ。
各言語の歴史的経緯についてなんかは言語仕様書の冒頭にでも
書いてありそうなことだし、こんな所で長々と解説されても信憑性も
疑わしいわでだんだん話が薄っぺらくなっていくだけですよ。
こちらとしては、そんなものより要点だけ数行でまとめて書いてくれると
読みやすいわ疲れないわでとてもありがたいわけですよ。
793:デフォルトの名無しさん
05/12/14 16:12:53
ｳｻﾞｽ
２、３行で要約しろよ
794:デフォルトの名無しさん
05/12/14 16:14:04
>>793
一行で要約できますた。
「ここはお前の落書き帳じゃねーんですよ。 」
795:デフォルトの名無しさん
05/12/14 16:25:20
つまり過剰な冗長さは悪し、という例ですな。
796:デフォルトの名無しさん
05/12/14 16:29:39
長くなると（読解力が不足がち人には）ウザイってのはそうだろうけど
（なら読み飛ばせば？とも思うのではあるけども
読み飛ばしてもくれずわざわざウザイと書いてしまう
不思議な心理があるようですね。）
信憑性が薄くなるってのはよくわからないな。信憑性は内容の問題でしょ?
読解しきれないと内容が理解できないからそういう読み手にとっては
信憑性が薄く「感じられる」というなら納得。
ちなみに要約、要約と言ってるけど
要約というのも情報処理だから当然情報量が減るわけですが、
そこはわかってますか？
要約された梗概ばっか読んでたら
そりゃ目は楽だろうけども身のある話はできませんぜ？
要約なんてのは言わば骨格標本みたいなもので肉はないんだから。
それにこの程度のことで知識の垂れ流しと言われるのも心外。
議論のためのほんのとっかかりのつもりだし、
ちょっと年寄りの言語屋なら別に知るともなしに知ってるような話であって
自慢するほどの知識じゃない。
…と>>792を見た瞬間に思ったけども、>>794にある要約が>>792の真意なら
あまり意味はない単なる煽りなわけで無視したほうがいいのかな？
797:デフォルトの名無しさん
05/12/14 16:32:08
>>795みたいな茶々いれの冗長性はどんなもんすかね？
798:デフォルトの名無しさん
05/12/14 16:37:55
>>796
一行で要約できますた。
「無視したほうがいいのかな？」
799:デフォルトの名無しさん
05/12/14 16:42:58
梗概が読めなかった。「こうがい」って読むのか。
800:デフォルトの名無しさん
05/12/14 16:53:40
>>796
>自慢するほどの知識じゃない。
そう。
あなたの知識の垂れ流しは、言わばほとんど無駄な情報＝ノイズなわけですよ。
あなたの言う骨と肉で例えると、見るに耐えないブヨブヨです。
すなわち骨が入ってるのかどうかさえ確認するのは困難です。
それをいちいち探りながら読んでいると時間も掛かり頭痛も絶えないわけでして、
長文をお書きならもうちょっと読ます文章を心掛けて書いて頂けませんか？
ということですが、お分かりになられませんかね。
801:デフォルトの名無しさん
05/12/14 17:00:51
よし、１０行縛りにしようぜ
802:デフォルトの名無しさん
05/12/14 17:08:25
>>797
丸ごと読み飛ばされる冗長性に比べると、一行コメントぐらいの冗長性ですな。
803:デフォルトの名無しさん
05/12/14 17:15:34
3人の旅人がおりました。
ホテルを見つけて、そのホテルのオーナーに宿泊料金をたずねると、オーナーは「3人部屋で30ドルです」と答えました。
そこで、旅人はひとり10ドルずつ払って、そのホテルに泊まることにしました。
しばらくして、オーナーは3人の旅人の泊まっている部屋の料金は、本当は25ドルだったということに気付きました。
そこで、ボーイを呼んで「あの3人の旅人に、この5ドルを返してきておくれ」と頼みました。
ボーイは、3人に5ドルを返しても割り切れないと思い、自分のポケットに2ドルしまい込み、残りの3ドルを、３人の旅人に1ドルずつ返しました。
3人の旅人は、ボーイから1ドルずつ返してもらったので、9ドルずつ払ったことになり、9ドル×3人で27ドルです。ボーイのポケットの中の2ドルを足すと、29ドル。
さて、残りの1ドルはどこへいったのでしょうか？
804:デフォルトの名無しさん
05/12/14 17:33:35
＞9ドルずつ払ったことになり、9ドル×3人で27ドルです。
問題が間違ってますよ。30-5+3で3人で28ドルですが。
端数切捨てですか？
805:デフォルトの名無しさん
05/12/14 17:37:43
いや3人が払ったのは27ドルでしょ。27-2=25ドルがオーナーの受け取った金で。
と、おいらも釣られてみましたよ。
806:デフォルトの名無しさん
05/12/14 17:38:31
>>784
いや、一番最初のLISPの目標は計算モデルを記述すること(チューリングマシンの代替)だろ。
それはまた、自分自身の処理系を簡潔に記述できる構造であることを意味する。
だからメタな機構はLISPの根本だと思うよ。メタサーキュラーな処理系があれば
それを種にして何でも出来るんだから。マクロやMOPは使い勝手の上で
追加されたおまけみたいなもん。
807:デフォルトの名無しさん
05/12/14 17:40:19
>>781
このスレ6から読み始めたので、2～5のdatどれかしら持ってたらうｐしてもらえませんか？
808:デフォルトの名無しさん
05/12/14 17:43:32
論争 Rubyで大規模プロジェクト 採用企業４割拡張ライブラリ使わず
URLﾘﾝｸ(www.toyama.hokkoku.co.jp)
あるチーフプログラマーは「日本人なら、Ruby。大規模プロジェクトでも拡張ライブラリは必要ない」と言い切り、
今後も拡張ライブラリとの併用はしない考えだ。
809:デフォルトの名無しさん
05/12/14 17:46:47
掲示板は書き手同士のコラボレーションで成り立ってるから、
そういうTPOとか特性を考えた上て書けってことだろ
そろそろこのスレの趣旨の話に戻せよ
810:デフォルトの名無しさん
05/12/14 17:53:38
>>808
この業界では技術に保守的なだけでもクズだというのに、
ついにナショナリストまで登場しているのか（笑）
811:デフォルトの名無しさん
05/12/14 17:59:31
>>808
ネタのつもりなんだろうけど、そういうまるっきりウソ流し続けてると
コミュニティ過激派から訴えられるかも知れんぞ
812:デフォルトの名無しさん
05/12/14 18:01:50
おれは2が欲しい
813:デフォルトの名無しさん
05/12/14 18:14:18
おれはお前が欲しい
814:デフォルトの名無しさん
05/12/14 19:13:58
>>803
真相をお話します。
オーナーはご想像の通り、物忘れが酷い人物ですが慈悲深く、
ボーイもまた欲深いという欠点を持つ人物ですが、それでも
ボーイはオーナーの人格を信頼して付き従っておりました。
さて、実はこのホテルのシステムは後払い方式なのですが、
オーナーの物言いにボーイは素直に頷き、オーナーから
預かった５ドルを欲深さからそのまま着服しました。
翌日オーナーは例外なくそのことを忘れており、
チェックアウトした旅人へ謝罪し２５ドルを受け取りました。
結局その時ホテルで５ドルの損失が発生したのですが、
オーナーはそれに気づかず運営を続け、やがて倒産してしまいました。
しかしその後ボーイは着服で貯めた金で大成し、
路頭に迷った元オーナーを雇ってあげたという話です。
経営者としてはボーイの方が格上だった、が正解です。
815:デフォルトの名無しさん
05/12/14 19:42:02
ﾋｿ(´д)(д｀)ﾋｿ
816:デフォルトの名無しさん
05/12/14 22:26:28
3人の言語オタがおりました。
このスレを見つけて、そこの住人に最高と思う言語をたずねると、
「RubyとLisp以外です」と答えました。
817:デフォルトの名無しさん
05/12/14 22:28:14
eagerな言語は使う気がしない
818:デフォルトの名無しさん
05/12/14 22:42:51
クロージャまわりのメモリ管理ってどうやってます？
・基本はスタック上で、捕捉されたらヒープにコピー
・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
・めんどいので全部ヒープに取ってGCまかせ
・その他
と、ネタ投下してみる。
819:デフォルトの名無しさん
05/12/14 23:13:26
>>807
URLﾘﾝｸ(makimo.to)
820:デフォルトの名無しさん
05/12/14 23:57:16
>>818
全部ヒープでやってる。速度は今のところ考えてない。
いずれはスタック使いたいんだけどね。
とりあえず論文読み中。
URLﾘﾝｸ(www.cs.indiana.edu)
821:デフォルトの名無しさん
05/12/15 01:12:12
>>818
>・基本はスタック上で、捕捉されたらヒープにコピー
捕捉されたらとは？生成のこと？
>・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
クロージャの生成構文を別々に設けるということ？
これらの意味は？
おれの見解ではクロージャを使うだけであればスタック、
クロージャを生成する際、親フレーム以下があれば
ヒープに落としてフレーム参照を繋ぎかえる、
この時既にヒープに落ちていれば何もしない、
という戦略がスマートというか、一般的じゃないかと。
使用回数＞生成回数という場合ね。
CPSやジェネレータみたいな使い方しかしない場合は
コピーが連続して不利になるけど、こんなことは
やろうと思わなければめったにない。
822:807
05/12/15 01:28:06
>>819
どもありがと。さいこー
823:デフォルトの名無しさん
05/12/15 02:53:00
>>818ではないですが面白そうな話題ですね。
>クロージャの生成構文を別々に設けるということ？
エスケープ解析とか？
>おれの見解では(略
すまん、理解不能。
といってもクロージャ変換で実装したことしかない俺の知識が足りないだけ。
興味あるので「一般的」の参照をくれるとうれしい。
824:デフォルトの名無しさん
05/12/15 04:31:04
>>803
○○○○○.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○ 最初に支払ったお金３０ドル
↓
●●●◎◎.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○ ３ドル返す ２ドルくすねる
└┼┘└┤└──────┬───────┘
│ │ └ 主人の手元に２５ドル
│ └ ボーイの手元に２ドル
│
└ お客の手元に３ドル
支払ったお金は２７ドル
９×３＝２７ ９ドルずつを３人で払った
３０－３＝２７ ３０ドル払って３ドル返してもらった
２５＋２＝２７ 主人に２５ドル、ボーイに２ドル払った
ボーイがくすねたお金２ドルは、客が支払ったお金（２５＋２）の一部
だから支払った２７ドルにさらに２ドルを足すことが間違い（２５＋２＋２・・・×）
最初の金額３０ドルを求めるには、実際に支払ったお金２７ドルに 戻ったお金３ドルを足さなければならない
825:デフォルトの名無しさん
05/12/15 04:51:17
エスケープ解析というのを知らなかったのでぐぐってみたのですが、
関数等のスコープの中で定義した変数やクロージャの
利用がスコープの中だけで完結し、外には持ち出されないことを
調べるということでしょうか。
826:デフォルトの名無しさん
05/12/15 13:44:56
そうです。
827:デフォルトの名無しさん
05/12/15 17:01:53
>>783-784
おもしろい。長くてもいいからやってくれ。
くだらん短い書き込みより、長くてもおもしろいほうがいいや。
長いのがいやなら読まなきゃいいだけ。
>JavaはCが存在していて必要ならば使うことができることが前提だから
>比較的汎用指向の言語でありながら
>Cで書くことが適切であるようなハードウェアレベルの記述機能を
>潔くスッパリ切り捨てた設計ができている。
ここらへんはたぶん違ってて、Javaに低レベルの記述がないのは単にJavaがバイトコードインタプリタを採用したからであって、Cがあるから云々は関係ないと思う。
ポインタをなくしたのもGCを導入しやすくするためで、やっぱりCとは関係ない。
828:デフォルトの名無しさん
05/12/15 18:15:07
>>827
そのへんは、鶏が先か卵が先かみたいなもんじゃね？
>>780
>人の認知科学的な処理特性を無視することはできない。
認知科学的には、冗長だとミスが増える法則もあるので
トレードオフだよね。
>ユーザが把握しやすい動作モデルを提供する
同じ物でも「把握しやすさ」はユーザによって
ばらつきが大きいんだよね。
ここを意識しないと宗教戦争になる。
829:デフォルトの名無しさん
05/12/15 21:03:36
>>827
ポインタはあるよ。
論文ばかり読んでる○○研究者か？
830:デフォルトの名無しさん
05/12/15 21:05:42
>818
継続も使いたいから
>めんどいので全部ヒープに取ってGCまかせ
かね……
831:デフォルトの名無しさん
05/12/15 21:35:49
>>823
>興味あるので「一般的」の参照をくれるとうれしい。
図にすると下みたいなイメージだけど、その辺は「クロージャ」が
出てくる速い処理系のソースかドキュメントでも読んでよ。
今の所これ以外に速い実装は思いつかないが。
※ |****| はフレームの変数とかの中身
※ (矢印)はフレームポインタ
スタック |******親1******|(←)|******親2******|(←)| ★クロージャ生成直前
ヒープ ヒープはまだ空の状態
↓ ヒープに落としてフレーム参照を繋ぎかえる
スタック | 親1 |(↓)| 親2 |(↓)| ★クロージャ生成完了
ヒープ |******親1******|(←)|******親2******|(←)|
エスケープ解析までするなら特定の親のみしかヒープのコピーは発生しない。
例えば親1のフレームしか参照しないのであれば親2のフレームは
そのままスタックに残しても良い。
スタック | 親1 |(↓)|*******親2*****|(←)| ★クロージャ生成完了
ヒープ |******親1******|(←)| ←── 生成されたクロージャは直接親1を参照
832:デフォルトの名無しさん
05/12/15 22:12:03
>>829
参照のことをポインタだって言い張ってる人はいますね。
833:デフォルトの名無しさん
05/12/15 22:43:17
Javaでポインタがあるっていう人間は低脳。バイトコードの仕様書読み直してから来い
834:818
05/12/16 01:44:55
>>821
>>・基本はスタック上で、捕捉されたらヒープにコピー
>捕捉されたらとは？生成のこと？
「生成されたクロージャが、
子孫のスタックフレームでないフレームに捕まえられたら。」かな。
例えばforeach的な関数にクロージャを渡してそのまま捨てるような状況なら
コピーは要らないわけです。
これをやると破壊的な処理がやたらと高くついたり、
いざコピーとなったときにやたらと高くついたり、
その他色々と面倒なことになったりしそうですが。
>>・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
>クロージャの生成構文を別々に設けるということ？
コンパイル時に絶対にコピーが要らないとわかったときのみ、
フレームはスタック上に置いて、
それ以外は最初から親フレームはヒープに置いておこうと。
「関数aはクロージャを引数に取るが、それはどこにも保存されない」
ということになればa以外を呼ばない関数のフレームはスタック上に置いて良いでしょう。
が、やっぱり色々あって面倒なことになったりしそうです。
どっちもクロージャより親フレームが長生きなら問題ないよねという方針。
835:デフォルトの名無しさん
05/12/16 18:53:57
Javaでポインタが無いと信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。
836:デフォルトの名無しさん
05/12/16 19:38:44
個人的な主観かもしれないけど、
ポインタ演算が無いものは参照と呼ばないか？
837:デフォルトの名無しさん
05/12/16 20:21:09
例えば、Cのポインタをタンイポと呼ぶように2006年から改正したら、
2006年からポインタが無いことになるぞ。
ポインタだのタンイポだのと言われてることが全て。
838:デフォルトの名無しさん
05/12/16 20:41:20
ポインタをタンイポと呼ぶためには法改正が必要なわけだが、2006年からというのは早急すぎるな。
まずは有識者を集めた小委員会の設置を図った上で、再来年以降の国会提出でも十分だと思う。
839:デフォルトの名無しさん
05/12/16 20:44:35
配列のイテレーターと参照と参照ポインタとメモリアドレスのポインタとを
一括してポインタと呼ぶべきでない。
840:デフォルトの名無しさん
05/12/16 21:04:11
>>835
Javaでポインタが有ると信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。
841:デフォルトの名無しさん
05/12/16 21:05:31
え、ポインタと参照の違いは常識だと思ってたのですが。
またトンデモ本の誕生ですか。
842:デフォルトの名無しさん
05/12/16 21:06:01
>>840
ほんたまですか？
843:デフォルトの名無しさん
05/12/16 21:06:22
塗るタンイポえくせぷしょん
844:デフォルトの名無しさん
05/12/16 21:06:32
懐かしい名前を出さないでください。せっかく忘れていたのに。
845:デフォルトの名無しさん
05/12/16 21:07:45
Pascalのポインタは演算できないけどポインタと呼ぶな
だから正解は>>837
846:デフォルトの名無しさん
05/12/16 21:10:09
でも一般的に見たら、参照とポインタの一般像みたいなもんはあるだろ。
Pascalは例外じゃないか？
847:デフォルトの名無しさん
05/12/16 21:12:33
PascalはInc, Decができるじゃん。
848:デフォルトの名無しさん
05/12/16 21:12:34
たしかにポインタの演算はできないけど数値にキャストできるから同じ事では。
849:デフォルトの名無しさん
05/12/16 21:21:12
みんなそんなにボロカスに言うなよ。
Mさんが可哀想じゃないかｗ
850:デフォルトの名無しさん
05/12/16 21:22:33
まあ少なくともJavaの参照はポインタではないことは確かだ。
名前が参照だから。
851:デフォルトの名無しさん
05/12/16 22:35:58
そんなの実際どうとかじゃなくて、
設計者がどう定義したかと、その思想によるだろう。
だから>>850が正しい。
852:デフォルトの名無しさん
05/12/16 22:41:17
名前はともかくとしても、実際の内容を素直に受け止めれば
いいと思うけど。なので >>835 が正解。
853:デフォルトの名無しさん
05/12/16 22:42:47
>>835とか>>852は、ポインタと読んでCのポインタを連想した上で書いてるわけっしょ？
だったらやはりCの言葉の定義に(ry
854:デフォルトの名無しさん
05/12/16 22:44:40
実際の所、Rubyにはポインタは存在するがLispには存在しない。
855:デフォルトの名無しさん
05/12/16 22:46:11
>>853 ポインタという言葉の定義or使用はＣが最初ですか？
856:デフォルトの名無しさん
05/12/16 22:48:01
RubyもLispもPascalも、同じ太陽を感じ、同じ月を見て. 同じ空気を吸っているのだから
ポインタの有無くらいで区別するのはよくないと思います。
857:デフォルトの名無しさん
05/12/16 22:50:26
しかし、ポインタの有無は実用性を大きく左右するんだよ。
858:デフォルトの名無しさん
05/12/16 22:51:20
うむ。
859:デフォルトの名無しさん
05/12/16 22:52:51
結局は宗教論争。
和平への道はアセンブラ原理主義しかない。
860:デフォルトの名無しさん
05/12/16 22:53:34
>>855
ALGOL60にPOINTERという型は既に存在したらしいぞ
URLﾘﾝｸ(www.99-bottles-of-beer.net)
861:デフォルトの名無しさん
05/12/16 22:55:01
Java ポインタ の検索結果 約 197,000 件中 1 - 10 件目 (0.03 秒)
URLﾘﾝｸ(www.google.co.jp)
Java 参照 の検索結果 約 2,830,000 件中 1 - 10 件目 (0.24 秒)
URLﾘﾝｸ(www.google.co.jp)
この様にJavaポインタ派は、Java参照派と比較するとごく少数です。
どうやら集団で勘違いされているみたいです。
>>856
Rubyにはポインタはありません。
ポインタに相当する機能は持ってますが、
それはポインタではありません。
862:デフォルトの名無しさん
05/12/16 22:58:05
実にくだらない話題に収束したな。
863:デフォルトの名無しさん
05/12/16 23:29:43
ポインタ演算とか、インクリメントとかデクリメントとか、数値へのキャストとかそういうのを
わざと制限したものは普通、ポインタじゃなくて参照って言わない？
864:デフォルトの名無しさん
05/12/16 23:33:18
>>857
同意。ポインタのある言語は領域破壊のバグが頻繁に紛れ込むが、
Javaのようにポインタのない言語はそうしたバグは非常に少なくなる。
865:デフォルトの名無しさん
05/12/16 23:33:48
いわないね。
Delphiだと明確に区別されてるし。
866:デフォルトの名無しさん
05/12/16 23:34:56
>>865
Delphiは言うじゃん。参照って。
867:デフォルトの名無しさん
05/12/16 23:37:26
つまり、865は「ポインタとは言わない」と言いたいちゃうんかと。
868:デフォルトの名無しさん
05/12/16 23:40:25
あぁ、863へのレスのつもりなのね。
869:デフォルトの名無しさん
05/12/16 23:52:19
>>857
つまりLispは実用的でない証明ってこと言いたいわけ？w
870:デフォルトの名無しさん
05/12/17 00:05:20
lispにポインタはありません。ポインタの無い言語は実用性で勝ります。864を参照。
871:デフォルトの名無しさん
05/12/17 00:10:12
Cにはポインタがあります。ポインタのある言語は自由度と汎用性で勝ります。864参照。
872:デフォルトの名無しさん
05/12/17 00:10:39
Lispにポインタはあるが、そういえば、Lispのポインタって完全にJava、Rubyなどで言う参照だよな。
結局その言語でそれをなんと呼ぶかってことだな。
873:デフォルトの名無しさん
05/12/17 00:11:26
>>871
確かにバグを出す自由度で勝りますねｗ
874:デフォルトの名無しさん
05/12/17 00:19:31
ようやくLispが出てきたか
やっぱこのスレの主役はLispだよな！
875:デフォルトの名無しさん
05/12/17 00:20:01
Lispこそがすべての源流であるということは認めざるを得ない。
876:デフォルトの名無しさん
05/12/17 00:23:32
そもそも「Javaでポインタ」って話は、C++使いにJavaの参照を教えるときに「C++の参照と違ってポインタみたいなもんですよ」って説明するだけの話じゃなかったっけ？
それ以外の時に普通Javaの参照はポインタとは言わない罠。
まあ「何かを指し示す」って意味に限定すればJavaの参照とCのポインタは一緒だから「存在しない」とまでは言う気ないけど。
ポインタ演算ができるかどうかなんてポインタの本質じゃないでしょ。
877:デフォルトの名無しさん
05/12/17 00:25:38
>>876
一般に参照とポインタの区別を云々する場合、ポインタ演算の有無こそが本質のうちの1つです。
878:デフォルトの名無しさん
05/12/17 00:26:56
>>877
そうなの？ポインタキボンヌ。
879:デフォルトの名無しさん
05/12/17 00:27:45
ポインタ演算があるのと無いのとではバグの量と種類に大きな違いが出るのだよ。
880:デフォルトの名無しさん
05/12/17 00:29:26
Cのポインタは、演算によって「値をずらす」ことができるだろ。
int a;
int *p = a;
p += 1; //←これ
参照はそれができない。
881:デフォルトの名無しさん
05/12/17 00:30:15
それはポインタ演算の有無の話であってポインタの有無の話ではないですね
882:デフォルトの名無しさん
05/12/17 00:31:08
間違った。
int a;
int *p = &a; //アドレスを代入
p += 1; //←これ
*p = 1; // 任意のアドレスのデータを破壊
参照はこれができない。
883:デフォルトの名無しさん
05/12/17 00:32:00
ポインタの有無の話ですよ。今や、それが出来ないものをポインタではなく参照とよぶことが多いんですから。
884:デフォルトの名無しさん
05/12/17 00:32:51
ポインタは任意のハードウェア例外を引き起こす。
*(int *)(0) = 0; // 不正なアドレスへの書込み
参照ではこれはできない。
885:デフォルトの名無しさん
05/12/17 00:33:23
これぐらいか？
●同じ点
Javaの参照もCのポインタも、どちらも間接参照を表すためのものである。
●異なる点
Javaの参照はヒープ上にあるオブジェクトしか指す事ができない。
Cのポインタはどこにあるオブジェクトも参照できる。
Javaで参照されているオブジェクトは決して消滅しない。
Cで指されているオブジェクトはいつの間にか消滅している可能性がある。
(そして、消滅したオブジェクトへの参照をたどった場合の動作は未定義である)
Javaの参照にはCのポインタ演算のような機能はない。
Cのポインタ演算は、配列の要素を指すポインタのみに使う事ができる。
それ以外の場合の動作は未定義である。
Javaの参照の動作はかなり厳密に定義されている。
Cのポインタに対する操作には「未定義である」という部分が多い。
それを利用して環境依存の色々な技が使えたりする。
886:デフォルトの名無しさん
05/12/17 00:34:20
Cのポインタが安全性を保証してないだけの話じゃん
887:デフォルトの名無しさん
05/12/17 00:35:50
クロージャの話しようぜ
888:デフォルトの名無しさん
05/12/17 00:37:11
>>887
まずクロージャを定義してださい。
889:デフォルトの名無しさん
05/12/17 00:38:20
ポインタは本来、「何かを指し示すもの」という意味でした。
この言葉は、アドレスやそれを格納した変数などにたいして用いられてきました。
しかし、時代が移り変わるにつれ、ポインタ演算によって、頻繁に深刻なバグが
発生することがわかってきました。ポインタ演算の有無が非常に重要だという
ことがわかってきたのです。
かくして、本来は本質でなかったポインタ演算の有無が、時代とともに重要視
され、ポインタの本来の意味が変わってきたわけです。
890:デフォルトの名無しさん
05/12/17 00:38:34
ださいとかいうなや
891:デフォルトの名無しさん
05/12/17 00:42:25
ポインタ演算を適用できる変数やアドレスの数値と、参照との区別を明確にするため、
前者のことを特にポインタと呼ぶようになったのです。
特に言語として、Cがダントツで有名になったこともこの背景にあります。
892:デフォルトの名無しさん
05/12/17 01:05:55
・ポインタ演算を元に考えればJavaやその他の言語にポインタはない。
・そうでなければいわゆる参照（C++の参照を除く）はポインタみたいなもん。
ってことでFA？
893:デフォルトの名無しさん
05/12/17 01:12:47
代入なんかをインスタンス化してしまう言語にはポインタがない、参照切れもない。
894:デフォルトの名無しさん
05/12/17 01:16:58
>>892
あと、
・その言語がポインタと呼んでいないものは、その言語ではポインタではない。