08/01/01 20:09:52
>>558
図で描いてある事が判りやすいのは、図は簡単なことしか描けないから。
難しい内容は図示できない。
>>557
そうだね。色々な方法があるのかもしれない。
563:デフォルトの名無しさん
08/01/01 20:10:09
>>542
LINQはMonoidとMonadの概念を持ち込んだものなので、分かる人には分かる。
MSは一般の開発者向けにこんな講義までしてるんだぜ。
URLﾘﾝｸ(channel9.msdn.com)
564:デフォルトの名無しさん
08/01/01 20:11:56
>>559
個人の感覚の問題かもしれないけど、多少冗長さを犠牲にしてforと
ifだけでいろんなことが表現できるという方が、
圧縮されて暗号のように短くなるけど、覚える規則が多くて、それに
当てはめて考えなくちゃいけないというよりもエレガントに感じる
565:デフォルトの名無しさん
08/01/01 20:16:32
プログラムを図で表現しようとしたのがUMLじゃね？
UMLからコードを生成しようとする試みも既にある
これがメジャーになるかどうかは知らんが
566:デフォルトの名無しさん
08/01/01 20:19:42
ここってメチャクチャレベル低すぎ、いまだにJavaとかEclipseとか．．所詮、使い捨てプログラマの馬鹿が
傷なめあってるところか．．．
567:デフォルトの名無しさん
08/01/01 20:22:03
>>565
それも思ったんだけど、結局ソースコードで記述したいことを十分にUMLで記述したものが、
ソースコードより可読性があるかといえば、自分はないと思ってる。
UMLは、ソースコードのある側面だけを記述するものであって、ソースコードと同等なものを
記述するためのものではないと思う。
568:デフォルトの名無しさん
08/01/01 20:22:05
>>566
未だにJavaが一番メジャーだと思うんだけど
Eclipseにいたっては伸びてる最中だし
569:デフォルトの名無しさん
08/01/01 20:27:06
>>567
全てとは言わないけど、開発の大部分がUMLダイアグラムの編集になって
テキストを直接見ることはほとんどなくなる事はありえると思うよ
既にNetbeansなんかではそういうスタイルはあるし
URLﾘﾝｸ(www.netbeans.org)
570:デフォルトの名無しさん
08/01/01 20:31:30
継承関係を見る分にはまあいいだろうけど、
private メソッドまで律儀に書きだすとやってられなくなると思う。
571:デフォルトの名無しさん
08/01/01 20:32:40
>>566
VB使いでさえ関数型に転向してるのにね
572:デフォルトの名無しさん
08/01/01 20:32:59
>>569
個人的な直感に過ぎないけど、それが主流になることはありえないと思ってる。
昔から PADとかCaseツールでプログラムを自動生成とかあったけど、
結局うまく行ってない。言語よりもツールの陳腐化が速いから、結局「負の財産」に
なってしまう。
573:デフォルトの名無しさん
08/01/01 20:35:29
関数型（笑）とかグラフィック（笑）が主流になることはありえないからｗ
574:デフォルトの名無しさん
08/01/01 20:37:06
>>573
SQLは関数的だなぁと思う。
こうした部品としては関数型は良いんじゃないかな。
575:デフォルトの名無しさん
08/01/01 20:38:14
>>572
RADは思いっきり主流になったよ
576:デフォルトの名無しさん
08/01/01 20:39:49
カーソルがいらなくなるのかな
577:デフォルトの名無しさん
08/01/01 20:41:12
>>571
VB使いの主な転向先はC#です
578:デフォルトの名無しさん
08/01/01 20:42:38
>>575
4DとかPowerBuilderはどこへ行ったんだよ。
少なくとも未来があるとは思えん。
まさに「負の財産」になってるんじゃないの？
579:デフォルトの名無しさん
08/01/01 20:44:23
>>578
精神はVisualC#.NETに受け継がれましたｗ
580:デフォルトの名無しさん
08/01/01 20:45:22
RADということで >>578を書いたけど、よく考えたらグラフィカルなプログラミングとも関係ないな。
581:デフォルトの名無しさん
08/01/01 20:46:59
>>548
激しく同意
582:デフォルトの名無しさん
08/01/01 20:51:55
UMLリファクタリングとかWindows Workflow Foundationとか
Visual Language(Robotics Studio)とか
Microsoftはグラフィカル言語へのシフトを狙ってる希ガス
583:デフォルトの名無しさん
08/01/01 20:53:04
これから主流になるのは長門のDOS窓多重起動スタイル
ここの1分30秒あたりから
URLﾘﾝｸ(www.youtube.com)
584:デフォルトの名無しさん
08/01/01 20:54:23
(s)evilwmがそんな感じだ
585:デフォルトの名無しさん
08/01/01 20:56:38
>>582
UMLリファクタリング以外誰も使ってないだろ
586:デフォルトの名無しさん
08/01/01 20:58:06
>>580
グラフィカルとは関係あるんじゃね？
GUIベースでソースコードをいちいち見ないとかその辺が
587:デフォルトの名無しさん
08/01/01 21:04:39
>>583
そういえば、しーぽんがテトリスみたいなグラフィカルな言語を
使ってたことを思い出したｗ
588:デフォルトの名無しさん
08/01/01 21:04:48
>>585
C#自体あまり使われてないから
UMLリファクタリング以前の問題
589:デフォルトの名無しさん
08/01/01 21:15:17
>>583
マクロ化？
590:デフォルトの名無しさん
08/01/01 21:15:34
MS発の技術に長続きしたものがあったのか?
591:デフォルトの名無しさん
08/01/01 21:17:57
窓の扱いはフローティングタイプよりタイル形の方がいいかもな
あとスクリプトから機能を呼び出したり
592:デフォルトの名無しさん
08/01/01 21:45:39
>>590
Win32API
593:デフォルトの名無しさん
08/01/01 22:00:33
>>590
Windows
594:デフォルトの名無しさん
08/01/01 22:09:10
>>590
Active Channel
595:デフォルトの名無しさん
08/01/01 22:16:27
>>590
seXBOX
AOE
596:デフォルトの名無しさん
08/01/01 22:18:30
グラフィカル言語といえばMacにもQuartz Composerがあるな
597:デフォルトの名無しさん
08/01/01 22:26:54
>>596
マックでしか使えない技術なぞ論外
598:デフォルトの名無しさん
08/01/02 00:47:10
結局考えて作って試してのループを高速にまわすことができる言語や技法であれば
定着するが、そうではなく「行き戻りがないように「ちゃんと」「しっかり」」という
視点のものは結局「ちゃんと」「しっかり」できないか、逆に足を引っ張るため
定着せず一過性の流行として終わる。もっとも下手に宣伝が行き届いていると
なかなか死亡しないので大迷惑（～標準、とか業界上げてのアピールとか
されてるとね・・・）。
その言語・技法を選んで高品質なものができるか、よりも同じ品質でいいので
より高速に出せるか、という基準で見るとこの先生きのこる技術を当てやすいような。
で、品質はループをより高速に回すことで向上する。
599:デフォルトの名無しさん
08/01/02 00:50:35
ループの回数も減らしたい
600:デフォルトの名無しさん
08/01/02 01:07:54
>>599
そこは工学ではなくて生物学の問題。
601:デフォルトの名無しさん
08/01/02 02:44:12
map / filter より for loop のほうがわかりやすい、と思う人は
単に for loop を先に知ったからなんじゃないの？
副作用って概念が難しくて、関数型のほうがすっとわかるひともいてもいいのでは。
数学とかやってるとそうなんじゃないかな。
602:デフォルトの名無しさん
08/01/02 02:50:25
どう考えてもmap-filterの方が簡単だろ
COBOLでfizzbuzz書いて見ればすぐわかる
603:デフォルトの名無しさん
08/01/02 03:20:54
>>602
kwsk
604:デフォルトの名無しさん
08/01/02 03:28:41
数学に近い分野専攻してるけど、map、filterよりリストの
内包表記の方が分かりやすい
605:デフォルトの名無しさん
08/01/02 03:56:07
>>604
同感
606:デフォルトの名無しさん
08/01/02 09:15:39
文転したのち社会学専攻だけども、map/filterやリスト内包表記は、抽出→写像って操作が直接表現してあってとっつきやすい
for/loopはやりたいことを間接的に表現してる感があるし、書くのはともかく読みづらい…
607:デフォルトの名無しさん
08/01/02 09:38:36
Pythonってどうなの？
日本では流行ってないけど、色々使えそうだけど。。。
608:デフォルトの名無しさん
08/01/02 09:54:39
将来性はあるほうだね
C#、Java、Ruby、Pythonが将来性あるよ
609:デフォルトの名無しさん
08/01/02 09:59:25
>>606
俺は理系だけど全く逆だなあ
for/loopの方がやりたい事を直接表現してるように見えるし
読みやすい
マシンを基準にして考えてるからだろうか
610:デフォルトの名無しさん
08/01/02 10:04:54
まあ慣れの問題だろうな。
最初に触った言語がHaskellとかだととても自然に見えるのかもしれないが。
俺も
プログラミング->数学専攻
の順だったから、なんか両者は別物という認識だな。
フィボナッチの定義を書いてそれが即動いたから何が嬉しいの?って感じだな。
611:デフォルトの名無しさん
08/01/02 10:12:13
プログラムを「処理手順」として考えれば計算機が実行する手順を直接的に記述したほうがラク。
ただ、SQLとか正規表現みたいに、処理手順として考えないほうがラクなものもある。
それでも、プログラムの大半は処理手順として考えたほうがラクだと思う。
612:デフォルトの名無しさん
08/01/02 10:15:35
グラフィカルなプログラミングとかUMLによるオブジェクト指向設計とか言ってる奴らマジで消えてくんねーかなぁ
才能無さすぎて邪魔だぜ
613:デフォルトの名無しさん
08/01/02 10:16:25
＿＿＿_ ＿ ＿ ＿ ＿ ＿ ＿ ＿ ＿ ＿ ＿ ＿ ＿ ＿ ＿
／_ノ ヽ､_＼ ( もう・・・私のばか・・・・！！！
. ／ （● ） (● ）＼ （ また本心と・・・・違うこと・・言っちゃったお・・・
／//////（__人__)///＼ ◯ ほんとは・・・素直になりたいのに////
| | 。O ￣ ￣ ￣ ￣ ￣ ￣ ￣ ￣ ￣ ￣ ￣ ￣ ￣ ￣
＼ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
614:デフォルトの名無しさん
08/01/02 10:48:16
>>612
お前才能無いよｗ
615:デフォルトの名無しさん
08/01/02 12:03:08
才能云々は意味不明だけど、俺がﾂﾏﾝﾈｰから>>612に激しく同意。
616:デフォルトの名無しさん
08/01/02 15:35:37
プログラムを「処理の手順を書き下したもの」という低レベルな認識を持ってる奴は
ループの方が分かりやすいだろ。何十行もの関数を書いてなんとも思わないような奴。
map/filterや内包表現は、
プログラムをちゃんと定義の積み上げとして見てる奴には非常に素直。
ただ、経緯的に手続きの書き下しから入ってる奴が多いから、ループに慣れてしまってる面はある。
617:デフォルトの名無しさん
08/01/02 15:52:29
グラフィカルプログラミングを体験すると「おおーオモシレー」と
なるのだけど、本格的に使おうとすると「ナニコレツカエネー」となる。
が、シコシココードを書いた後、「このコードの山を体系化して
誰か設計意図や全体像のビジュアルイメージを描き起こしてkrkr」と思うのも確か。
改修とかで設計の根幹に触れるような要素がないか見通したくなると特に。
図で描ける・見れる、というのはイメージ伝達のキモだから将来性はあるんだけど、
まだ（よい意味で）遊び道具だな。思ったことをイメージできる道具ではなく、
思考の特定部分だけしか表現しにくい隔靴掻痒ツールになってる。なのでUMLも
あくまで標準書式の第一歩という点だけが重要で、後はコメント付け頑張れとか
ベストプラクティス的にはなってる訳で。
618:デフォルトの名無しさん
08/01/02 15:54:00
「手順」は別な表現をすれば、変数の変更など、副作用を時間軸上に展開したもの。
副作用が存在する言語ならば、そのプログラムが本質的には手順であることは自明。
本質的ではない前後関係を、プログラム上に記述しないという考え方には意味があるが、
それは、プログラムが手順ではないことを意味しない。
619:デフォルトの名無しさん
08/01/02 16:11:46
>>616-618
ご高説ごもっとも。
今後どういう方向性が一般化していくんだろう？
一部でしか使われない技術とかでなくて全体の方向性として。
620:デフォルトの名無しさん
08/01/02 16:16:12
厨房の数学までをカバーすれば
その言語は枯れないと見る
なぜなら毎年使う奴が居るからだ
621:デフォルトの名無しさん
08/01/02 16:25:00
>>619
未来の前に、過去をどう見てる？
622:デフォルトの名無しさん
08/01/02 16:27:17
>>621
朝鮮人は来るな
623:デフォルトの名無しさん
08/01/02 16:45:22
>>620
maxima->clispか？
624:デフォルトの名無しさん
08/01/02 17:20:27
リア厨でmaximaやclispを使ってる奴なんか見たことないぞ
625:デフォルトの名無しさん
08/01/02 17:25:26
リア厨の時
ペルソナウェアのフリーだった頃の
おりものプログラミングやってた
626:デフォルトの名無しさん
08/01/02 17:59:04
>>625
今は伺か使ってるの？
627:デフォルトの名無しさん
08/01/02 18:00:03
>>624
兄貴が東大理一の奴いたけどMathematica使ってた
628:デフォルトの名無しさん
08/01/02 18:03:47
>>626
うかがかは何か知らんけどよくフリーズするし
おっぱい揉みまくったら居なくなったから
それ以来触れてない
629:デフォルトの名無しさん
08/01/02 18:04:14
>>627
そーゆー奴って大抵凡人になるよな
630:デフォルトの名無しさん
08/01/02 18:05:42
>>629
兄貴に反発して不良になるけど
兄貴が交通事故で死んでから
東京理一を目指すというありがちな話じゃないの？
631:デフォルトの名無しさん
08/01/02 18:06:48
その前に甲子園目指せよ
632:デフォルトの名無しさん
08/01/02 18:07:00
伺かを使うやつは集団ストーカー被害にあってる。
この前自殺した中学生も使ってたんじゃないかな。
天才が凡人になる理由は、暴力のため。
633:デフォルトの名無しさん
08/01/02 18:07:34
Mathematicaは楽しい「環境」。
組み込み関数が多彩かつ超強力で
pset/lineでいきなり図形を描けるN88BASICを思い出した。
最近点描くのも一苦労な言語ばっかりでちょっと悲しい。
634:デフォルトの名無しさん
08/01/02 18:08:07
ああ、事故のせいでもいいや。
今もなだれでニュースになってるしな。
自然を征服するのが快感な天才君は自然に飲み込まれてしまいましたと。
635:デフォルトの名無しさん
08/01/02 18:11:21
毎年この時期に登山する奴は死ね
人に迷惑かけてまで登るなんて頭がおかしいんだよ
636:デフォルトの名無しさん
08/01/02 18:12:16
何の話をしてるんだ？
637:デフォルトの名無しさん
08/01/02 18:19:56
>>1
おっぱいそん
おっぱいには夢が詰まってると言うじゃないか
もちろん貧乳もＯＫ
未発達にも夢がある
成長期が終わっても貧乳なのは
シンプルでコンパクトなセットだと考えられるしな
求めれば求めるほど直感的に書けるようになる
強力な言語だ
638:デフォルトの名無しさん
08/01/02 18:59:40
伺かって漏貧絡みじゃなかったっけか？
639:デフォルトの名無しさん
08/01/02 19:08:29
ネタはせめて30分ねかせてから3回ほど熟読してなお面白いと思った場合に限って書き込んでくれたまえ
640:デフォルトの名無しさん
08/01/02 19:12:28
>>638
殿が勝手に出しゃばっただけ
641:デフォルトの名無しさん
08/01/02 19:18:17
>>638
> 伺かって漏貧絡みじゃなかったっけか？
URLﾘﾝｸ(morphyone.info)
これか。
自作ハードは雑誌とかで取り上げられてたっけ。
けど、その不可能性は僕も２ちゃんねるで書き込んだけどことごとく反論されたっけ。監視だけは怠らないよな。
642:デフォルトの名無しさん
08/01/02 19:29:06
ハガキＰＣみたいなのを作ろうとして失敗したのか
伺かとどういう関係が
643:デフォルトの名無しさん
08/01/02 19:33:56
>>642
URLﾘﾝｸ(www.max.hi-ho.ne.jp)
> とよぞう氏によって配布されている
644:デフォルトの名無しさん
08/01/02 19:41:54
将来のプログラミングは伺かみたいなのに話し掛けて
対話的に構築するシステムというわけか。
645:デフォルトの名無しさん
08/01/02 19:50:05
偽春菜を作った人って人工無能だか人工知能を
ペルソナウェアに搭載したかったのかね
人工無能関係のサイトに足跡残ってた
646:デフォルトの名無しさん
08/01/02 19:52:25
>>645
誰もが一度は通る道ですな
647:デフォルトの名無しさん
08/01/02 20:00:25
>>643
ＲＯ廃人にしてキモキモネカマか
648:デフォルトの名無しさん
08/01/02 20:01:20
10年後にはCPU128コア、メモリ128GB、HDD64TBくらい当たり前になってるだろうけど、
それくらいになったら実用的な人工知能も動きそうな希ガス
649:デフォルトの名無しさん
08/01/02 20:03:16
その程度でまともなAIが動くなら
クラスタベースのものがとっくに実現されてるだろ。
650:デフォルトの名無しさん
08/01/02 20:05:20
>>649
どのくらい必要なんだろう？
651:デフォルトの名無しさん
08/01/02 20:07:34
クラスタっていうとシミュレーションとか計算関係みたいなイメージがあるんだが、
クラスタで人工知能ってどっか研究してるのかな？
652:デフォルトの名無しさん
08/01/02 20:08:52
>>648
シンクライアント化が進行してマシンパワーは打ち止めになってる希ガス
653:デフォルトの名無しさん
08/01/02 20:10:09
将棋をするソフトに方程式を解くソフト、物理計算をするソフト
大抵の分野では既にまともなAIが出来てるんだからそれでいいじゃないか
654:デフォルトの名無しさん
08/01/02 20:11:53
そもそも物量をかけて脳のシナプス相当のものをエミュレートすれば
論理的に人工知能が実現可能かどうかはわかってない。
かといってプログラマがｼｺｼｺとif文を書き連ねていけば
汎用的な思考ルーチンが完成するかどうかについてはもっとわかっていない。
655:デフォルトの名無しさん
08/01/02 20:11:58
反乱して自爆しないうちはAIじゃないんだろ。
656:デフォルトの名無しさん
08/01/02 20:13:55
>>654
ペンローズが言ってた量子脳って最近はどう評価されてるんだろ。
657:デフォルトの名無しさん
08/01/02 20:14:57
>>653
肝心の自然言語を理解するAIがダメダメなんだが
658:デフォルトの名無しさん
08/01/02 20:15:04
脳をエミュレートする必要なんてないだろ
1+2を計算すればいいのにそのために脳をエミュレートしたりしたら
それは馬鹿だろ
659:デフォルトの名無しさん
08/01/02 20:16:05
>>656
認知科学の人と超心理学の人とではまるっきり態度が違う
660:デフォルトの名無しさん
08/01/02 20:16:41
１＋２をたまに間違えてくれないと可愛げがない
661:デフォルトの名無しさん
08/01/02 20:16:42
>>652
その昔NCというのがあっての・・・
662:デフォルトの名無しさん
08/01/02 20:17:25
>>660
ちょびっツ？
663:デフォルトの名無しさん
08/01/02 20:18:11
>>657
でも方向性はいろいろあって完璧にお手上げってわけでもないから
そのうち実用的になるだろ
機械翻訳とか今でも一応使ってるやつはいるし
664:デフォルトの名無しさん
08/01/02 20:22:55
人間の脳にはシナプス（Nアナログ入力1アナログ出力の素子）が
一兆個分程度あるそうだから、C2D（１億５千万個くらい？）換算で
１００万プロセッサ分もトランジスタがあれば規模的にはコピー可能になる。
>>654
無限のサルがif文を打ち込んでいけば必ず実現するだろうね。
665:デフォルトの名無しさん
08/01/02 20:28:07
てか翻訳作業は今や機械翻訳＋手直しが当たり前。
小説は知らんけど。
666:デフォルトの名無しさん
08/01/02 20:36:43
>>665
手直しがAIで抜けてる部分なんだけどね
667:デフォルトの名無しさん
08/01/02 20:39:18
実用的かどうかで言えば一応実用的だ
人間のプロを超えることはまだ難しくても
668:デフォルトの名無しさん
08/01/02 20:47:09
>>667
翻訳と自然言語の理解とでは求める実用性が違うよ。
翻訳だと単語単位の訳だけ出して文脈や文法から理解するのは人間なんで、
コンピュータはほとんど意味の理解はやっていない。
IMEで係り結びを認識して候補を変えるのと同じレベル。
669:デフォルトの名無しさん
08/01/02 20:53:30
>>664
現在の問題は規模以上に脳の初期回路が不明。
尚且つ、シナプス信号以外の化学物質による思考への係わりも大きい。
＋三次元で展開されるシナプスの動的変化も必要。（疲労や変化）
等で簡単ではない。
完全乱数は世の中に存在しない。 ましてや無限のサルなど…
670:デフォルトの名無しさん
08/01/02 20:57:09
>>669
ヤングの実験を一光子でやるやつって完全乱数じゃないの？
671:デフォルトの名無しさん
08/01/02 21:01:11
主張がよくわからんが、仮に「完全乱数」がこの世に存在しないのなら、
脳の構成にもそれは不要なんじゃないの？まぁサルは有限だが。
672:デフォルトの名無しさん
08/01/02 21:05:33
>>668
意味の理解とか言い始めたらクオリアという超難題にぶつかるわけだが。
673:デフォルトの名無しさん
08/01/02 21:08:47
>>672
コンピュータ工学的には中国人の部屋で充分
674:デフォルトの名無しさん
08/01/02 21:10:41
クオリア（笑）
もさもさ頭の本読んだけど結局なーんもわかりませんしか言ってなくて駅のホームに捨てたなぁｗ
675:デフォルトの名無しさん
08/01/02 21:12:07
Haskellやってみたら面白かったよ！
676:デフォルトの名無しさん
08/01/02 21:14:12
>>675
その調子で何か面白いアプリ作ってみてよ
人工知能とかｗ
677:デフォルトの名無しさん
08/01/02 21:18:53
>>676
思考は状態だから副作用そのものなんだよなぁ
678:デフォルトの名無しさん
08/01/02 21:20:29
クオリアのひとは心理学者にトートロジーいわれて尻尾まいて逃げ出したわけだが
>>675
ｵﾒ
679:デフォルトの名無しさん
08/01/02 21:24:56
>>677
時間軸を分割して単位時間を静的に処理して
次の単位時間への変化ベクトルを算出するのは
副作用なしにできるんでない？
Haskellでゲームを作るときも同じようにして
単位時間の切り替えだけモナドに押し込めてたはず。
680:デフォルトの名無しさん
08/01/02 21:26:45
人工知能にクオリア必要ないでしょ
URLﾘﾝｸ(ja.wikipedia.org)
> 情報処理装置の中身は真の意味を理解する必要がない
681:デフォルトの名無しさん
08/01/02 21:28:48
夢があって将来性のある言語をまとめると
人工知能でグラフィカルで関数型な言語ってことでFA?
682:デフォルトの名無しさん
08/01/02 21:29:19
>>681
それでいいと思う
683:デフォルトの名無しさん
08/01/02 21:32:18
残念！
正解はC#
684:デフォルトの名無しさん
08/01/02 21:32:30
人工知能で関数型となるとLISP最強だな
685:デフォルトの名無しさん
08/01/02 21:33:34
>>684
グラフィカルはどうなった？
686:デフォルトの名無しさん
08/01/02 21:34:05
人工知能も出来てないし、グラフィカルじゃないし、関数型としても
中途半端だから却下
687:デフォルトの名無しさん
08/01/02 21:34:08
LISPから.NET Framework使えたら間違いなく最強だ。
688:デフォルトの名無しさん
08/01/02 21:35:19
>>687
あまり知られてないけど.NET Framework SDKのサンプルにLISP処理系が入ってるお＾＾
689:デフォルトの名無しさん
08/01/02 21:38:02
え、どこ？
690:デフォルトの名無しさん
08/01/02 21:39:04
>>689
URLﾘﾝｸ(www.atmarkit.co.jp)
> .NET対応Lispコンパイラ
691:デフォルトの名無しさん
08/01/02 21:42:17
>>687
PLT-Scheme+Dot-Scheme
bigloo.Net
692:デフォルトの名無しさん
08/01/02 21:43:39
>>690
ほほー
さんくす
693:デフォルトの名無しさん
08/01/02 21:48:01
副作用に強くGUI向きなHaskellの変種Concurrent Cleanに一票
694:デフォルトの名無しさん
08/01/02 21:53:46
>>693
開発停滞してるし将来性は・・・
695:デフォルトの名無しさん
08/01/02 22:02:40
>>651
URLﾘﾝｸ(ja.wikipedia.org)
696:デフォルトの名無しさん
08/01/02 22:07:30
>>695
さんくす
やっぱ研究してるところあるんだな
出力データのビジュアル化が重要みたいだね
697:デフォルトの名無しさん
08/01/03 00:37:20
いつも >>690 とか >>695 的なものを読んで思うんだが、
なんで、現在見知っている生物と同様の脳(意識)を求めるんだろ？
体を構成している C が Si に変わった生き物がいたとして、
そいつらの脳が同じ発達をするとは思えないんだが………
ハードウエアがかわれば意識もかわるのでは？？？
# 意味がないって言ってるわけではないよ
698:デフォルトの名無しさん
08/01/03 00:40:23
>>697
その生物や脳の研究のためじゃないか？
699:デフォルトの名無しさん
08/01/03 00:41:06
>>697
同じになるか変わるか調べるのも研究テーマのうちなんじゃないか
700:デフォルトの名無しさん
08/01/03 01:01:45
700げっとずざー
701:デフォルトの名無しさん
08/01/03 02:46:22
>>653
そういうのは弱いAIと分類されている。
それに対して思考まで再現するのが強いAI。
702:デフォルトの名無しさん
08/01/03 02:51:16
>>697
演繹では行き詰ったら帰納から攻めるというのも手。
シナプスのシミュレートは冗長だが分析して贅肉を落とせば
ダウンサイジングしていくことも可能だろう。
703:デフォルトの名無しさん
08/01/03 03:02:39
>>697
ヒント: イルカと魚はほとんど同じ形
704:デフォルトの名無しさん
08/01/03 03:10:31
人間の脳の構造は46億年分の英知の結晶だしな。
まねない理由が見当たらない。
船や飛行機も魚や鳥の構造を研究した上で設計されてるし。
いい材料が見つかればスクリュー廃止したイルカ型だかマグロ型の高速高燃費な潜水艦が出来るのだとか。
705:デフォルトの名無しさん
08/01/03 03:30:17
いいえ
706:デフォルトの名無しさん
08/01/03 04:48:56
低燃費ならともかく、高燃費じゃ使う価値ないな。
そもそも潜水艦自体、存在価値が怪しい。
707:デフォルトの名無しさん
08/01/03 04:56:40
なんかAIとか人工知能とか現時点ではどうでもいいわ。
生物学的なアプローチが成功するまでどれも偽者か小道具だろ。
本当に出来たとしたら人類初の産業革命と言われてもいいと思う。
自動毛織り機なんか比較にならない。
美術作品など人間の創作性をたよりにする仕事、
全て高速で完全な機械ができるようになるのだから。
それより言語がどうのこうの言っているうちは
人間様がチマチマ作業しているに他ならないのだから、
気持ちよく人間様の下僕になる言語を選ぶべき。
なんて書いたら叩かれるだろうな。
708:デフォルトの名無しさん
08/01/03 05:04:08
自信の無さが伺えるな
ちょっと大きく出すぎたかと内心ビクビク
709:デフォルトの名無しさん
08/01/03 05:08:42
確かに自信もないしお金もない。それに反論好きな相手をする余裕もない。
というより、論争そのものが無意味に思える。どうせ四の五の言って相手をねじふせさせること以外はしていないからだ。
710:デフォルトの名無しさん
08/01/03 05:16:38
生物学的なアプローチではなく、「偽物か小道具」が美術作品を作るようになると
俺は思う
711:デフォルトの名無しさん
08/01/03 05:26:31
種類の異なる言語を複数知ると、言語論争が馬鹿らしくなる罠。
俺の使う言語XXXはいつも最高だとか思い込んでいるうちが幸せかもしれんね。
これは、言語だけでなくフレームワークにも同じように言えるけどな。
712:デフォルトの名無しさん
08/01/03 05:39:02
>>711
それはデジタル土方の考え方のようだけど。
713:デフォルトの名無しさん
08/01/03 05:43:18
>>710
どちらか片方でなく、両方の要素が必要ではないかな。
生物学的アプローチと言っても夢物語ではない。
現在でも文字認識とかでニューラルネットワークが使われているが、
シナプスのシミュレートはそれを複雑にしただけ。
714:デフォルトの名無しさん
08/01/03 10:30:22
人間の脳を完璧に再現されたAIはオナニーしたり狂ったりもするだろうな
715:デフォルトの名無しさん
08/01/03 10:37:49
脳は性器を持たないけどな
716:デフォルトの名無しさん
08/01/03 10:39:08
AIなんて実用的限定的なものに留めるのが吉。
これだけ長きに渡って研究しているのに
HAL2000をどうやれば作れるかなんて取っ掛かりすら見えてこない。
それより人間の脳にコプロセッサぶっこんで
演算速度上げて記憶容量増やした方が100万倍使えるな。
717:デフォルトの名無しさん
08/01/03 10:45:51
HAL2000なんて自然言語を聞き取れるエキスパートシステムでじゃないの？
取っ掛かりは十分見えてる感じがするなぁ
718:デフォルトの名無しさん
08/01/03 10:49:04
のだめ見てるけど意味わかんね
719:デフォルトの名無しさん
08/01/03 10:54:17
短期的にはAIよりも生物AIをコンピュータ化する方が先に実用化されるだろ。
脳とダイレクトに入出力できれば生産性は1000倍どころじゃない。
2getだって0.000001[s]でできるようになる。
720:デフォルトの名無しさん
08/01/03 10:58:20
HAL2000って何？
HAL9000とは別物？
721:デフォルトの名無しさん
08/01/03 11:01:43
2001年宇宙の旅だと思ってた
そっか、あれは9000か
722:デフォルトの名無しさん
08/01/03 12:40:49
不正確でもちゃんと意味が通じるのが人間知性というものだ
723:デフォルトの名無しさん
08/01/03 12:42:54
2getは脳と繋がってなくてもできるだろ
つか繋がってない方が速いぞ
724:デフォルトの名無しさん
08/01/03 13:17:34
HAL9000とスタトレのエンプラ号の「コンピュータ」の比較論とかな...
725:デフォルトの名無しさん
08/01/03 15:10:53
HALより未来の二つの顔に出てきたやつが欲しい
726:デフォルトの名無しさん
08/01/03 15:20:14
スパルタカスだっけ。
727:デフォルトの名無しさん
08/01/03 15:22:28
そんな名前だった気がする
あれ作るのはどんな言語が必要なんだろうな
728:デフォルトの名無しさん
08/01/03 15:23:12
ちょびっツはいつできますか？
729:デフォルトの名無しさん
08/01/03 15:29:23
Apple設立20周年記念Macだっけ
730:デフォルトの名無しさん
08/01/03 15:35:18
>>727
自己修復機能がベースになってるんだよな、たしか。
オートノミックとかアーティフィシャルライフの延長線上にあるような気もする。
731:デフォルトの名無しさん
08/01/03 23:12:25
>>728
３０年以上前から、人工知能系は研究されているが、未だに"パターン認識"くらいしか、
まともに使い物にならないということからして、
反証可能性によって、残念ながらちょびっツは、生まれ得ない。
中学生のときに、本気でプログラミングを勉強して(未だにしているが)、
ちょびっツのような"もの"をつくってやると、大規模ネットワーク上(WinMX)で、
熱く語ったことがある人間が、答えてあげました。
その当時は、若者は、夢があってええのう、といわれましたけど。
すでに、この分野に夢はない。
将来性のある言語は、C++やJava, PHPとおもう。
C++は、STLとboostが最強、ゲーム業界ではC言語と並んで主流、MSは手を切りそうだけど・・・。何がC♯だよ。
Javaは、これから需要がたくさんある。携帯電話の普及率と比例いや２乗に比例か。
PHPは、現在これ以上のが、ないので、とりあえず安泰。
732:デフォルトの名無しさん
08/01/03 23:27:12
"STLとboost" ねぇ
Lisp の成果の使いまわしだけどな
733:デフォルトの名無しさん
08/01/03 23:29:42
lispに強力なライブラリがあれば～という記事を読んだ
しかし文法が奇妙すぎる
734:デフォルトの名無しさん
08/01/03 23:42:58
今の時代、ゲーム業界もXBOX360のソフトはC#で開発されてることが
多いそうだよ
735:デフォルトの名無しさん
08/01/03 23:46:09
んなわけねぇｗ
素人がC#でゲーム作れるSDKを公開したってだけだろ。
せいぜいライブアーケードの一部に使われるかどうかだ。
736:デフォルトの名無しさん
08/01/03 23:46:42
>>734
正気か？
そんなことしたらPS3と同時リリースできないじゃん
737:デフォルトの名無しさん
08/01/03 23:48:50
MSがOfficeとServer製品郡をC# に移植したら、少しは将来性を信じても良い。
738:デフォルトの名無しさん
08/01/03 23:49:01
>>731
厨二病だった自分を恥じる気持ちはわかるが
否定からは何も生まれない・・・
739:デフォルトの名無しさん
08/01/03 23:49:54
>>736
PS3もやっと軌道に乗り出したようだね
740:デフォルトの名無しさん
08/01/03 23:50:45
クターがPS3のクラスタで革命を起こすって吹いてたのを思い出した
741:デフォルトの名無しさん
08/01/03 23:51:36
クターってシュールなゲームのことか
742:デフォルトの名無しさん
08/01/03 23:51:43
>>733
Haskellが誕生した現在、Lispの役目は終わった
743:デフォルトの名無しさん
08/01/03 23:52:41
>>741
久夛良木
744:デフォルトの名無しさん
08/01/03 23:53:23
>>742
LispはまだまだEmacs厨のお守りをしてもらわないと
745:デフォルトの名無しさん
08/01/03 23:55:24
EmacsもLispも将来のない墓場
よくアニメとかで（最近だとひぐらし）
永遠に同じ時間が繰り返すのがあるけどそんなイメージ
746:デフォルトの名無しさん
08/01/03 23:58:51
>>738
凡人なんてそんなもん
意固地になって厨二病を認めようとしないのは変人
ごく一握りの変人が大化けすることはあるが99%は廃人
747:デフォルトの名無しさん
08/01/04 00:03:02
>>735
XNA Game Studioでググレ
748:デフォルトの名無しさん
08/01/04 00:04:18
LispもHaskellも方向性が正反対と言っていいほど違う言語
Lispの役割はまだ終わらない
749:デフォルトの名無しさん
08/01/04 00:04:27
>>747
知ってるっつーの
「素人がC#でゲーム作れるSDK」って書いてんじゃん
750:デフォルトの名無しさん
08/01/04 00:05:46
>>747
で、「ゲーム業界」とやらが作ったC#製タイトルってなんだよ。
751:デフォルトの名無しさん
08/01/04 00:46:17
Schizoid、Eternity's Child
752:デフォルトの名無しさん
08/01/04 08:39:58
XBLAの小物ばっかじゃん
753:デフォルトの名無しさん
08/01/04 14:00:11
>>734
そもそも、日本のクリエイタークラブ入会者は何人居るよ？
XNAみたいな遊ぶ人が居ない超マイナー環境でゲーム作って何がうれしいんだ？
携帯電話向けJavaゲーム作成の方が１００倍マシだな。
754:デフォルトの名無しさん
08/01/04 14:16:24
ゲームでも何でもC#やJavaなんて見たことないぞ
C++一択じゃないのか？
755:デフォルトの名無しさん
08/01/04 14:34:16
お正月>>754「和尚がツー和尚がツー言われてぶるぶるぁぁぁ！！！」
756:デフォルトの名無しさん
08/01/04 14:34:41
>>754
据え置き機のことを言ってるんだろうけど
ケーターゲームの市場は無視できない規模だぞ
757:756
08/01/04 14:35:16
すまそ
×ケーターゲーム
○携帯ゲーム
758:デフォルトの名無しさん
08/01/04 14:35:38
携帯機用ゲームはいまだにCとアセンブラでしょ?
759:デフォルトの名無しさん
08/01/04 14:36:37
携帯電話でゲームなんかしないぞ俺は
760:デフォルトの名無しさん
08/01/04 14:38:57
>>758
携帯電話
761:デフォルトの名無しさん
08/01/04 20:35:31
クラッシュバンディグーだっけ？
あれはLISP系俺様言語でつくられてるとか聞いたんだが
762:デフォルトの名無しさん
08/01/04 22:03:38
一部だろ
全部ＬＩＳＰだと思うとキモイ
763:デフォルトの名無しさん
08/01/05 00:10:17
Javaじゃないの？ ケータイアプリは。
一時期のリッジとかそのへんは知らんけど。
764:デフォルトの名無しさん
08/01/05 00:19:20
iアプリ10KB制限の頃はバイトコード直書きとかもあったらしいが。
765:デフォルトの名無しさん
08/01/05 13:24:24
ふと思ったんだけど、ゼロ知識証明的な手法を使って、実行ファイルが手元にあっても、リバースエンジで
ロジックを解明出来ないようにすることは出来ないかな。暗号化は実行時に復号している以上、本質的には
実行ファイルからリバース可能だから、そういう意味ではなくて。
パフォーマンスは悪そうな気がするけど、そういう言語ができたら、特殊な分野ではそれなりに使えるかも。
766:デフォルトの名無しさん
08/01/05 14:50:16
>>765
それのどこに夢と将来性があるの？
767:デフォルトの名無しさん
08/01/05 15:59:01
ファックできないなんて夢の無い言語だな
768:デフォルトの名無しさん
08/01/05 16:07:13
統合言語がほしい。
ここからJavaで書くけど次はC#、でもここらへんはCommon Lispで
フレームワークはHaskell、気分がいいのでPerl使ってみたいな。おもちゃ程度にはなる。
769:デフォルトの名無しさん
08/01/05 16:19:44
>>765
本質的にはリバースエンジニアリング可能なら、あんま意味ないような気もするけど？
ライセンスかDMCA的に縛る、っていう気休めなら現状とたいして変わらないし、
ネットワーク越しのドングルみたいなメカニズムなら、リモート側でサービス提供する形に
したほうがよっぽどメリットがあるような気が。
770:デフォルトの名無しさん
08/01/05 16:22:10
別言語のオブジェクトファイルをリンクさせれば良いという話か？
771:デフォルトの名無しさん
08/01/05 16:26:04
>>770
それに限らずたくさんの言語を一緒に使えたら気持ちいいだろうなあというお話。
実現方法はいっさい考えていない。
たとえば最低の方法だと別言語で作成された
プログラムをパイプでつなげば終わりだよね。
現時点だと.NETが一番近いのかな。
772:デフォルトの名無しさん
08/01/05 16:27:57
夢はあるかもしれないが夢でおわるな
773:デフォルトの名無しさん
08/01/05 16:37:33
COMも頑張っていた。
774:デフォルトの名無しさん
08/01/05 16:46:59
>>768
.NET上で動くことを前提にすれば、十分に可能性はあると思う。
775:デフォルトの名無しさん
08/01/05 16:49:19
ものすごいトランスレータを作れば可能性は…
776:デフォルトの名無しさん
08/01/05 16:55:21
ものすごいかどうかはともかくSWIG
777:デフォルトの名無しさん
08/01/05 17:23:54
>>769
そうじゃなくて、実行する以外には、実行結果を知ることができないような仕組みが
作れれば、本質的にリバースエンジを無効にできるのではないかという話。
もっとも理論的に可能か検討すらしてないし、ここではウケが悪いみたいだから、
もう話はおしまいにするけど。
778:デフォルトの名無しさん
08/01/05 17:31:26
19:00 二カ国語放送文字多重放送 NHKニュース7 ▽がん発見に人工知能の診断装置
779:デフォルトの名無しさん
08/01/05 17:48:10
バイナリレベルで実現しようとしたのが COM で、
IL レベルで実現しようとしてるのが .NET という認識でおk？
780:デフォルトの名無しさん
08/01/05 18:11:33
バイナリ＋オブジェクトレベルで実現させようという試みが.NETで、
プロトコルレベルで実現させようという試みがCOMでおけ。
781:デフォルトの名無しさん
08/01/05 18:21:14
>>768
4GL? (hogehoge/QLとか)
Perl? (Inline::*で実現)
WSH?ASP?（XMLでモジュールに属性をつけて実現）
で、いまココが CLR になると。
実戦では ASP.NET が一番広汎に使われてるかな？＞マルチ言語のモジュール統合
782:769
08/01/05 18:29:27
>>777 うぅむ？ 公開鍵暗号の秘密鍵を耐タンパ性のある石の中に封じ込めて、
外部には一切平文なプログラムが流れないシステムとかそういうものかな？
私も無理に話を続けようとは思いませんが、一応、何の事前調査もなしで自分が
想像できる限りの強固なシステムというとそんな感じになりますが。
783:デフォルトの名無しさん
08/01/05 22:27:03
>>768
全ての用途で一番適している万能言語は存在し得ないと思うし、
全部の言語でライブラリを共有するすることも不可能に思う。
例えば、.NETのライブラリは多言語対応と言われているが、
しかしクラス・構造体・メソッド・ジェネリックの言語仕様を持つ言語という制約が存在する。
そのため、.NETの各言語はこれらの言語仕様を扱えるように改造されてしまい元の言語と異なってしまっている。
全面的に作り直されたVB、ジェネリック等が追加されたIronPythonなどが良い事例だと思う。
統一言語やどんな言語からでも利用できるライブラリなんてのは夢でしかない。
784:デフォルトの名無しさん
08/01/05 22:27:40
ゼロ知識ってことは相手に求めたい出力を与えないで、
いかにも出力を持っているように振る舞えるってことだよね？
単に関数表を出すことができるとは次元が違うよね？
785:デフォルトの名無しさん
08/01/05 23:35:47
>>783
元々IronPythonは「各言語をCLRで統一？動的言語どうすんだ（ｗ無理だよバカス（ｗ」を
実証するために作ったが、作ってみたら「あれイケる。全然イケる。このままGOー！」となったとか。
結局どんな言語であれお互いの仕様を完全コピーすることは可能だし、あとは
それが何らかのエミュレーションレイヤが挟まるかそうでないかの違いなので、
CLRの抽象化はかなり幅広いパターンを包含できる中々よい設計だと思う。
現行のCLRではどうにも実現方法が回りくどすぎて非効率だが、記述方法として
理にかなった概念などを提唱できれば論文一本くらいはものになるんでない。
786:デフォルトの名無しさん
08/01/06 00:06:34
夢がある言語。リンデンスクリプト
間違いない！
787:デフォルトの名無しさん
08/01/06 00:12:09
>>783
つアセンブラ
788:デフォルトの名無しさん
08/01/06 00:34:27
>>785
>結局どんな言語であれお互いの仕様を完全コピーすることは可能だし、あとは
>それが何らかのエミュレーションレイヤが挟まるかそうでないかの違いなので、
>CLRの抽象化はかなり幅広いパターンを包含できる中々よい設計だと思う。
あまりにJavaVMライクな物を意識しすぎたのか、多言語と言っている割に
静的な型を持つオブジェクト指向言語以外はエミュレーションレイヤで
頑張れと言わんばかりの設計になっていない？
少なくとも.NETの中間言語を見る限りはそのような印象を受ける。
789:デフォルトの名無しさん
08/01/06 00:50:38
>>788
静的型を共用できなかったらライプラリが静的型言語からまともに使えない。
プアな方は、使わない情報は無視すればいいだけ。リッチな方に合わせた方がいいに決まってる。
Genericsもあるべき。これもプアな方は、使わない情報(型パラメタ)は無視すればいいだけ。
それより、根本的に異なる遅延評価みたいなのはどうするのか。
790:デフォルトの名無しさん
08/01/06 00:59:24
自言語以外のライブラリすべて副作用のある変化として扱うしかないだろうね
791:デフォルトの名無しさん
08/01/06 01:35:56
副作用の問題？
「実行」の根幹、バイトコードの基本概念設計に関わる気がするけど。
792:デフォルトの名無しさん
08/01/06 01:41:49
自己書き換えが問題なのか、具体的に話して。
言語仕様的には全く問題ない。実装が問題なだけであって。
ただ関数型言語で言えば.NET上にはF#がある。
遅延評価もたしか入っていたはずだが。詳しくはしらんので調べてください。
URLﾘﾝｸ(en.wikipedia.org)
793:デフォルトの名無しさん
08/01/06 02:55:26
>>792
１言語作るだけなら、バイトコードで評価器作ればいいけど、
それだと他言語から利用するときに評価器ごとロード・実行する必要があるのでは？
それが他の遅延評価言語からであっても。
やはり、ライブラリの利用は、願わくば本質的なコードのみのロード・実行（評価）であって欲しいし、
それができてこそ「汎用」VMではないか？
となると、バイトコードは式木を表せてかつ評価戦略も色々出来るものでないと行けないと思うが、
これは、普通の手続き的なバイトコード（VM）では無理ではないか？
あと、遅延評価だけでなく、Lispみたいにデータとプログラムに区別がないのも、同様の問題があると思う。
794:デフォルトの名無しさん
08/01/06 03:09:35
もうそこはあきらめるしかないだろ。
795:デフォルトの名無しさん
08/01/06 09:21:45
スクリプト言語をバイナリ変換してC並の速度が出るコンパイラがほしい
796:デフォルトの名無しさん
08/01/06 09:27:14
まともなスクリプト言語なら JIT コンパイルしてるとは思うが、
C に比べりゃ最適化不足なんだろうな。
処理回数によって最適化レベルを上げていくとか難しいんだろうか。
797:デフォルトの名無しさん
08/01/06 10:01:23
結局、最適化なんて何のためにその操作をするのかまでは考えてくれないからな。
798:デフォルトの名無しさん
08/01/06 18:28:24
使用言語をある一つに特定しないといけない能力では夢や将来性はないなｗ
799:デフォルトの名無しさん
08/01/06 18:49:13 BE:79877344-2BP(294)
>>796
最適化不足っていうか、Cなみになるような最適化って不可能だろ?
たとえば、Cだと、ローカルの配列(文字列)とか確保するのに、スタックから取れるけど、
Javaだとヒープから取らないといけないとか。
800:デフォルトの名無しさん
08/01/06 19:59:41
>>796
いま、メインストリームのスクリプト言語で、JITコンパイルまでしている言語を教えてほしい
801:デフォルトの名無しさん
08/01/06 20:11:45
逆に考えて
夢のない言語、将来性のない言語
って何？何をするにしても、とりあえずそれだけ避けておけば
問題なかろう。夢や将来は言語じゃなく中身で実現するもんだし。
802:デフォルトの名無しさん
08/01/06 20:16:51
Javaには夢が「あった」
今はもう無い。
803:デフォルトの名無しさん
08/01/06 20:46:51
Managed C++ には夢が無い。
804:デフォルトの名無しさん
08/01/06 20:50:15
>>803
C++/CLIは？
805:デフォルトの名無しさん
08/01/06 21:01:24
>>804
ネイティブと.NETの架け橋として夢いっぱいであってほしい。
806:デフォルトの名無しさん
08/01/06 21:25:53
Cobolには夢が「あった」
今はもう無い。
しかし、しぶとく生き残ってる。
誰かトドメをさしてくれ。
807:デフォルトの名無しさん
08/01/06 21:26:48
いきなりとどめを刺したら、日本は終了するけどね。
808:デフォルトの名無しさん
08/01/06 21:29:44
コボラーどもにモチでも食わせとけｗ
809:デフォルトの名無しさん
08/01/06 21:30:33
人は死んでもしばらくの間髭が伸び続けるのだよ
810:デフォルトの名無しさん
08/01/06 21:39:28
ActiveBasic
811:デフォルトの名無しさん
08/01/06 21:42:20
今年還暦＆定年のうちの親父はコボラー
812:デフォルトの名無しさん
08/01/06 22:49:13
将来のある問題として
コボラが作ったCOBOLとJCLを使ったシステムをどうするか
改造していくか、JAVAなどでゼロから作り直すか・・・
汎用機もソース自体も信頼できないから困っちゃう
挙句の果てにソースはコボラの頭の中ときたもんだ
813:デフォルトの名無しさん
08/01/06 23:23:49
>>810
あんまり楽じゃないBasicだよねぇ、それ。
814:デフォルトの名無しさん
08/01/06 23:24:09
夢だけでいいなら韓国語。将来性は知らんが。
815:デフォルトの名無しさん
08/01/07 00:26:10
>>806
夢なんて無かったんじゃなかったか？
プログラミング言語などというパラダイムは、自動プログラミングの手始めの
一過性のものに過ぎないと考えて、ましてや、言語としての寿命はすぐに尽きる
つもりで、やっつけ仕事で標準化の作業をやった、ってなことをどこかで聞いたか
した記憶がある。
816:デフォルトの名無しさん
08/01/07 02:37:57
>>812
JavaVM上で汎用機とCOBOLがエミュレートされこの先生きのこるのだよ
817:デフォルトの名無しさん
08/01/07 03:22:42
>>799
その点に関しては、Javaも、ローカルスコープでしか参照されないオブジェクトのメモリを
スタックに確保するなんて最適化をやるらしいぞ。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
Javaあんまり使わない自分にはあまり縁のない話だけどさ。
818:デフォルトの名無しさん
08/01/15 14:54:23
最近、やっぱりLISPなんだと思う。
IronSchemeとかもあるし。
819:デフォルトの名無しさん
08/01/16 12:28:02
でも、やっぱりLISPなのかねぇ？
JSchemeとかkawaとかあるけど。
820:デフォルトの名無しさん
08/01/16 12:58:31
自己書き換えを動的・構造的にやる仕掛けとしては、
俺にはLisp以上の手が思いつかない。
821:デフォルトの名無しさん
08/01/16 19:44:03
LispとPerlは相容れない
822:デフォルトの名無しさん
08/01/19 14:33:59
>>821
ﾊﾟｲﾌﾟで繋げ
823:デフォルトの名無しさん
08/01/24 11:49:15
824:デフォルトの名無しさん
08/01/30 02:17:40
>>821
URLﾘﾝｸ(search.cpan.org)
825:デフォルトの名無しさん
08/01/30 07:46:26
ARC
826:デフォルトの名無しさん
08/02/05 09:27:18
827:デフォルトの名無しさん
08/02/09 21:18:35
キリックス
828:デフォルトの名無しさん
08/02/14 20:18:17
829:デフォルトの名無しさん
08/02/17 12:57:28
カイリックス？
830:デフォルトの名無しさん
08/02/17 13:56:41
リンデンスクリプト
831:デフォルトの名無しさん
08/02/17 13:58:43
リンデンスクリプト
楽しいけど、将来性は無い。
そもそも遊びの言語
832:デフォルトの名無しさん
08/02/17 19:11:38
C++のnamespace、もしくはインラインアセンブラみたいな感じで、
ここからはC、ここからはVB、ここからはJAVAってな感じで、
ひとつのソース中に全ての言語が記述できたら夢があるかな？
833:デフォルトの名無しさん
08/02/17 19:27:48
互いのデータのやり取りがどれくらいシームレスかによるな。
例えばC++/CLIで、俺はCLIとネイティブの間に壁を感じる。
例えばCLI型のデータをBoostで扱おうなんて夢のまた夢。
その点をどうにかすれば夢広がりんぐなのは間違いない。
834:デフォルトの名無しさん
08/02/17 19:28:27
夢はあるが無茶だな。
せいぜい extern "C" みたいな工夫を
色んな言語に使えるようにする程度が限界だし、
それも言語によっては無茶だろうし。
835:デフォルトの名無しさん
08/02/18 00:03:36
.netで部分的に実現できるんじゃね？
836:デフォルトの名無しさん
08/02/18 00:25:55
COMだって部分的には実現していた。
HTML、HTAやWSFファイルで、script要素毎に異なる言語を使える。
837:デフォルトの名無しさん
08/02/18 01:03:52
つ DLRConsole
URLﾘﾝｸ(msdn.microsoft.com)
838:デフォルトの名無しさん
08/02/18 08:08:10
なんかもう足したらいいんじゃね。JAVAと.NET。
サーバーとクライアントこれ1本みたいな。
環境考えなくていいし。
でも決してJ#のことを言っているわけじぇねぇよ。
839:デフォルトの名無しさん
08/02/18 08:26:31
MSはVJ++の前科があるからSun的にありえない
840:デフォルトの名無しさん
08/02/19 01:06:18
>>839
前科つーか、あれSunは認めておくべきだった。
そうすりゃ今ドトネト向けに出てる膨大なライブラリはすべて（まあ、ほとんど）
Javaで動いてただろうし、そしたらVisualStudioもJ#みたいなインチキではなく
今頃ネイティブサポートでウハウハだった。Sunが著しく経験がない
グラフィカルコンポーネント群もWin/Mac系のベンダがこぞって生産して
超充実してたはず（一部プラットフォーム依存はしただろうけど）。
MSが巻き返しで.NET作っちゃったからASP.NETとかSilverLightとか
膨大なHoge#/Hoge.NET言語群とかが出現して、Javaはかなり危うい。
デスクトップ向けにはMacOS Xにも乗り切れず、結局UNIX方面で使える
サーバ向け言語という領域に押し込まれてしまった。
もったいない。
841:デフォルトの名無しさん
08/02/19 01:26:05
>>840
MSはどっちみち独自仮想マシン作ってたと思うよ。
842:デフォルトの名無しさん
08/02/19 07:27:39
いや、.NETの、プラットーフォーム依存バイナリで好き放題やれるような機構、
ああいうものをJavaに入れるのをSunが許すことはありえないし、
MSが入れないということもありえない。
843:デフォルトの名無しさん
08/02/21 02:55:37
単にJNIをはるかに簡単に書けるというのと程度的には違わんけどな。
Pure Javaの敗北と取られかねないからブランド戦略的に身動きが取れなかった、に一票。
Java野郎が諸手をあげて歓迎してるEclipseとかが使ってるものは一体何よ？とか
思わんでもない。まあSunではないといえばそうだが、SunではなくJava業界は余裕で
認めたと思う。
844:デフォルトの名無しさん
08/02/23 16:23:14
EclipseはVisual Studioより出来がいい。
845:デフォルトの名無しさん
08/02/23 16:28:13
ということにしたいのですね。
846:デフォルトの名無しさん
08/02/25 00:08:00
>>840
認めてないから今のポジション維持できただと思うがな
認めてたらC++なみのカオスになってたはず
847:デフォルトの名無しさん
08/02/25 19:04:10
個人的にはABに期待してる
848:デフォルトの名無しさん
08/02/25 19:31:39
どんな言語でも作りたいものが作れるならそれでいいよ
それより英語だけは少なくとも読めた方がいい、日本語訳待ちとかもったいない。
849:デフォルトの名無しさん
08/02/25 19:46:36
>>840
幸いなことに、PC向けクライアントアプリ作成の重要性は低下の一方だから嘆くほどでもない。
携帯端末向けのアプリやWebアプリ作成が重要になってきて、この分野では依然最大シェアなんだから、この分野を頑張ればいい。
>>846
認めてないから今のポジション維持できた点は激しく同意だが、
わざわざ、C++を貶めるのはよくないな。
850:デフォルトの名無しさん
08/02/25 21:20:00
JavaはJavaSE7からはPure Java志向をちょっとだけ崩してきた。
JAMって機能がそうなんだが、JavaのDLLたるjarの拡張版で、↓みたいになる。
<モジュール名>-<バージョン>[-<プラットフォーム>-<アーキテクチャ>].jam
851:デフォルトの名無しさん
08/02/25 21:37:17
並列プログラムに向いた言語がこれから来るんじゃないだろうか。
あまり詳しくないけど、Erlangとかそんな感じ？
852:デフォルトの名無しさん
08/02/25 21:38:13
Fortran があるじゃないか。
853:デフォルトの名無しさん
08/02/25 21:42:55
Fortranはコンパイラ屋に見捨てられて先のない言語じゃないか。
そういや並列Fortranとして、FortressだったかをSunが作ってたな。
854:デフォルトの名無しさん
08/02/25 21:44:07
スパコンではもっぱら Fortran らしいぜ。
855:デフォルトの名無しさん
08/02/25 21:49:16
そろそろ数値計算ライブラリもFortran脱却しようよ
856:デフォルトの名無しさん
08/02/25 21:52:25
Debugが辛くなるだけだから、ThreadPoolだけでいいっすよ。
40コア時代になってもXMLコアだのMathコアだの10進数演算コアだのが登場するだけでしょ。
1000コア時代にでもなったときに考えるんだぜ。
857:デフォルトの名無しさん
08/02/25 22:06:57
>>851
>並列プログラムに向いた言語
Ozがあるじゃないか
858:デフォルトの名無しさん
08/02/25 22:07:42
Concurrent Clean
Fortress
859:デフォルトの名無しさん
08/02/25 23:43:40
>>855
誰かが新しいライブラリのバグ出し全部やってくれたら、そうするよ。
860:デフォルトの名無しさん
08/02/26 00:39:29
どちらかというと夢のない言語の方が将来性があるな
861:デフォルトの名無しさん
08/02/26 01:52:34
C言語が任意位置での変数宣言と、名前空間をサポートすれば最強なんじゃね？
それなんてC++っていわれそうだが、C言語規約で出来たら嬉しいじゃないか。
862:デフォルトの名無しさん
08/02/26 02:04:01
前者はC99で実現している。
863:デフォルトの名無しさん
08/02/26 02:11:03
ほー。てか配列宣言が変数で行けるようになってるみたいね。
やってることってallocaと同じなのかな？ちと怖い。
864:デフォルトの名無しさん
08/02/26 02:14:43
>>849
Javaを認めることには少なからずC++に対する批判が混じっていて当然だと思うのだが
865:デフォルトの名無しさん
08/02/26 18:13:35
Cで変数を途中で宣言する必要性がわからないが。
可読性から言ったら、先頭で宣言する方が良いと思うけどね。
C++は処理の流れに依存してオブジェクトを生成する必要があるから途中で宣言できる必要があるけど。
866:デフォルトの名無しさん
08/02/26 18:32:45
可視範囲は狭いにこしたことはない、という考え方もある。
867:デフォルトの名無しさん
08/02/26 20:08:50
関数先頭で宣言する方がありえないわ。
全部短い関数で作ってくれるならまだしも、
あの仕様でいて、長い関数にベタ書きする連中多いからなあ。
俺の脳みそでは扱いきれん。
868:デフォルトの名無しさん
08/02/27 00:30:47
一部でいわれるデータ指向プログラムだな。
ブロック作って寿命を管理する手法はよくやる。
869:865
08/03/02 01:04:53
ブロック作って、って話じゃないだろ。
それならCでもできる。
CではできなくてC++でできる話という文脈で出てきてるんだから、当然ブロックの中間にポンと出てくる宣言のことだろ。
870:デフォルトの名無しさん
08/03/02 01:08:12
くだらん。
スレタイ嫁
871:デフォルトの名無しさん
08/03/07 14:41:20
872:デフォルトの名無しさん
08/03/18 19:37:50
873:デフォルトの名無しさん
08/03/19 13:04:59
>>869
できるよ。
以上。
↓次の方どうぞ
874:デフォルトの名無しさん
08/03/20 18:19:36
これから始まる人間革命が起きたらしいんだ。
URLﾘﾝｸ(www.nicovideo.jp)
頭がパーンってなって夢が与えられるらしい。
875:デフォルトの名無しさん
08/03/24 20:25:24
構成的プログラミング言語PXっていうのが気になるんだが、
これの処理系って何処かで公開されてたりしない？
876:デフォルトの名無しさん
08/04/05 11:04:16
877:デフォルトの名無しさん
08/04/08 13:11:17
夢があるのは、Oz ということになるが、難しすぎる。
878:デフォルトの名無しさん
08/04/16 23:43:50
つか、言語自身に夢とか将来性をもとめちゃいかんよ。
道具なんだからさ。
それを求めていいのは、言語自体を作りたい人とか、そういう人だけだよ。
道具として使おうとしている人が、求めちゃいかん、と俺は思うね。
そんなこと妄想する暇があるならパタヘネ本でも読んだほうがいいかもよ。
879:デフォルトの名無しさん
08/04/17 07:57:44
私には夢がある。
それは日本語でコンピュータに指示すること。
この見果てぬ夢を求めて、せめて一歩でも近づこうと、
二十数年Prologできた。
この言語の閉塞感が強まる昨今、Ozの魔法を使えないものか。
880:デフォルトの名無しさん
08/04/17 19:52:26
プログラマ雇って日本語で仕様書書け。
881:デフォルトの名無しさん
08/04/17 21:19:09
>>879
Prologに相性がいいのは欧米語。日本語は根本的に構造が合わない。
882:デフォルトの名無しさん
08/04/17 21:29:46
Javaの実装がもっとハードウェアの能力を上手く引き出してくれたら、
それが一番最高なんだけどねぇ。
883:デフォルトの名無しさん
08/04/18 00:55:57
メソッドチェーンできる言語だと、日本語っぽくなるというブログ記事を最近見たよ
第20回 日本語でおk | WIRED VISION
URLﾘﾝｸ(wiredvision.jp)
Ruby もいいけど Smalltalk でも、おｋ。 - sumim’s smalltalking-tos
URLﾘﾝｸ(d.hatena.ne.jp)
inforno :: 日本語プログラミング言語Scala
URLﾘﾝｸ(inforno.net)
POBoxの増井俊之さんが「日本語でおｋ」とかタイトルつけてて吹いたｗ
884:デフォルトの名無しさん
08/04/18 11:29:02
つ「日本語の語順と逆ポーランド記法」（水谷静夫）
885:デフォルトの名無しさん
08/04/18 15:06:37
>>883
Xの平方根の逆数を印刷する
＞ という具合に、処理の流れとプログラムの形式と日本語表現を同じ順番で簡潔に記述することができます。
＞ このように、実は日本語は計算機処理の記述にかなり適した言語であるということができそうです。
日本語のコメントがあると分かりやすい気がするのはもしかしてそういうこと？
なんか目からうろこ。
886:デフォルトの名無しさん
08/04/19 22:03:15
>>885
ｉｆとかforとか制御構文を毎回日本語で書かされるとかなりゲンナリなんだけれども。
メソッド名とか関数名、強い意味をもった変数くらいに絞って日本語を使うと、
適切に構造化してるとかなり読みやすくはなる。
んで、日本語でメソッド名を書いてみると、割と解り易いメソッド名を付けやすいと思えると思うよ。
VBとかVBAとかの環境が手元にあるなら、試してみるといい。
887:デフォルトの名無しさん
08/04/19 22:25:45
入力がめんどい
888:デフォルトの名無しさん
08/04/20 00:44:12
全部のキーワードが日本語だと確かに面倒だけど。
メソッド名だけとかならそうでもないじゃないかな。
定義するのは一回だけで、そっからさきはインテリセンスでいけるし。
まあ、IDE使ってる前提があって、だけれど。
889:デフォルトの名無しさん
08/04/20 06:01:53
引数無く日報が呼ばれたときは昨日の日報を出力する。
という仕様から、
日報 :- 昨日(_昨日),日報(_昨日).
を生成する。ということは、「引数無く」の意味理解や、
「が」「呼ばれた」「とき」「は」「の」「を」「出力」「する」などを
捨象しなくてはならない。Prologの手入れはこのレベル。
nippo() {
date(&date);
nippo(date);
}
のようなコードはもう一段手入れが入っていて一枚仕様書が増えます。
ム板にこういう部分の話をするスレはあまりありませんが、
言語比較評価をするならこの部分も含める必要があります。
890:デフォルトの名無しさん
08/04/20 06:23:14
date(&date); ではなく sakujitsu(&date) に訂正します。
891:デフォルトの名無しさん
08/04/20 08:16:52
>>889
一方が漢字でもう一方がローマ字なのはフェアな比較じゃないね。
nippou :- sakujitsu(date), nippo(date)
読む気にならんよ、これは。
892:デフォルトの名無しさん
08/04/20 08:50:19
>>891
変数は大文字からはじめるからこうだな。
nippou :- sakujitsu(Date), nippo(Date).
別に俺は読みにくいとは思わんよ。慣れの問題じゃない?
初めてLispをみれば誰だって読みにくいと思うし、
Cのような中括弧使う言語ばっかし使ってたら
beginとendを使う言語を見たとき読みにくいと思う。
893:デフォルトの名無しさん
08/04/20 12:56:20
>>891
これは >>886 以下に対するレスで、Prologだと>>889の日本語表記が
当たり前です。これは、仕様とプログラムを近くに置きたいという
プログラマの意識の反映とも言えます。その意識から「必然的に」に
日本語になったのです。これに比べるとC系言語のソースコードからは
この意識をほとんど感じることができない。日本語だと読み易いか
とか、入力がめんどうだといった次元の話しかでてこないのはやはり
問題でしょう。
894:デフォルトの名無しさん
08/04/20 13:03:18
>>893
クラス名や関数名や変数名やメソッド名に日本語を使える言語は色々あるが、
それに対するPrologのメリットは？
895:デフォルトの名無しさん
08/04/20 13:18:07
>>894
日本語の使用の利点はこれはPrologに限らないことだと思いますが、
仕様書の切り貼りでプログラムが構成できることです。さらにPrologに
利点があるとすれば、一応裸の論理式ですから、比較的原文に近い姿に
なるということでしょう。
896:デフォルトの名無しさん
08/04/20 13:25:46
日報 :- 昨日(_昨日),日報(_昨日).
なんか日報という述語がカブってるように見えるのは気のせいだろうか。
まあ、それはいいとして、
日報
self.報告(new Date.昨日())
のほうが
「日報を提出するとは、昨日の日付けで報告を作成することである」
に近いと思うのだが、気のせいか？
897:デフォルトの名無しさん
08/04/20 14:35:41
そもそも日本語に近い表現が出来るプログラミング言語って理解しやすいものなの？
俺は日本語に似ていればいるほど逆にその差異が気になって
かえって理解しづらいと言うか、
むしろ日本語は日本語、プログラミング言語はプログラミング言語として
別物として考えた方が理解しやすいと感じるんだが。
898:デフォルトの名無しさん
08/04/20 15:25:46
>>896 最初の仕様が
"引数無く日報が呼ばれたときは昨日の日報を出力する。"なのだから
この場合仕方ないでしょうw
既に、
?- 日報('20080419').
という呼び方が既にあり、これでも面倒だという人がいて、
上記の仕様の追加要求がだされた。
?- 日報.
899:デフォルトの名無しさん
08/04/20 15:30:20
既に がダブって読み苦しかったですね。
一引数の述語が定義されていて、後から引数なしの述語要求がくる上記の
ようなケースは、実務ではしばしばあります。
900:デフォルトの名無しさん
08/04/20 15:39:11
昨日(_昨日)が入ることが自然に見えているうちは、
日本語に近いとかいう問題じゃなくて、
単にProlog教に洗脳されているだけでしょう。
>>896のほうがはるかにマシだ。
901:デフォルトの名無しさん
08/04/20 15:53:43
ロジカルなやつは英語ベースのASCII文字がいいけど、
大まかなやつは日本語名使えるとすごい分かりやすい。
ユーザー視点での基本設計レベルの構造を日本語で定義してやると、
設計書はむしろソースコードがあればよくて、ソースコードにコメントもいらなかったり。
まあ実際には一まとめにした設計書はどうしても必要になるだろうけど。
プログラミングでは普通日本語使わないし、ローマ字使うとまずその判別が必要になって読みにくくなるんだけど
UWSCてスクリプトは全角スペース使えるし変数名も関数名も日本語で定義できる。
完全な日本語プログラムは完全な英語表現と同じ問題があってややこしいけど、
コメントを入れたくなるような機能とか変数を日本語にすることでそこが際立つから
全体を見渡すときに一瞬で大まかな流れが理解できる。
>>897へのレスにしようと思ったけど完全日本語化が分かりやすいって意見じゃないからやめ。
長ったらしく書いたけど「>>896に同意」の一言でよかったかもしれない。
902:デフォルトの名無しさん
08/04/20 17:11:05
>>900
日報 :- 昨日(X),日報(X).
だって全然問題ないんじゃないですか。Xって論理変数を
用いて定義せよっていう仕様じゃないから、仕様の
なかにある語彙を用いて定義してみただけですから。
903:デフォルトの名無しさん
08/04/20 17:17:45
日本語の何が問題かって、
変換が面倒くさいことだな。
904:デフォルトの名無しさん
08/04/20 17:22:52
話のテーマと、どんどん離れてしまいますが、
日報(_出荷場所,_出荷日下限,_出荷日上限) :- ... <略>
のような意味を暗示した論理変数は実務的には意味があります。
このソースコードの字面から、
<input type="hidden" name="述語" value="日報">
出荷場所 <input type="text" name="出荷場所">
出荷日下限 <input type="text" name="出荷日下限">
出荷日上限 <input type="text" name="出荷日上限">
を自動的に生成する時に使いますね。
905:デフォルトの名無しさん
08/04/20 17:31:35
>>902
その「昨日(X)」という記述に何の疑問も持たないのなら、
それは技術的な議論をする資格を喪失していると言わざるを得ない。
906:デフォルトの名無しさん
08/04/20 17:32:25
>>904
その程度のHTMLの生成もできない言語のほうが珍しいという罠
907:デフォルトの名無しさん
08/04/20 17:41:30
>>906
何を元に生成するのですか?
908:デフォルトの名無しさん
08/04/20 17:43:13
>>907
それはむしろ>>904に聞くべき話なのでは？
909:デフォルトの名無しさん
08/04/20 17:56:07
1) ?- tell('日報.pl'),listing(日報/3),told.
で現在メモリーに定義されている日報の定義がファイル"日報.pl"に
書き出されます。(既に正確なソースファイルがあるならこの作業は不要です)
2) これを読み込んで解析し :- の左の
日報(_出荷場所,_出荷日下限,_出荷日上限) を切り出します。
3) これを更に解析して,関数名='日報',
第一引数='_出荷場所',第二引数='_出荷日下限',第三引数='_出荷日上限'を切り出します。
4) それぞれの引数の先頭の"_"を取り除いて、'出荷場所','出荷日下限','出荷日上限'
が得られます。
この四つの情報から、>>904が生成されます。
910:デフォルトの名無しさん
08/04/20 18:15:30
>>909
まさか、同様なことが手続き型言語ではできないと思ってるのか？
911:デフォルトの名無しさん
08/04/20 18:25:35
ですから、この四つの情報をソースコードのどこに書いておくのですか?
定型的に、かつ日常的に、手続き型言語でこのような情報をソースコードから
取り出せるように定義しているならば、何の問題もありません。
912:デフォルトの名無しさん
08/04/20 18:32:13
>>911
OO言語ならメソッドの宣言。
非OOの手続き型言語なら関数や手続きの宣言。
913:デフォルトの名無しさん
08/04/20 18:34:05
>>904 について誤解がありそうなので、追加説明します。これは
既にたとえばCUIで使い込まれている日報というプログラムがあり、
これをPrologサーバーに移して、Web参照を可能にしましょうと
いうような場合のはなしです。Prologのプログラムとしては
日報(A,B,C) :- ... という定義で十分なのですが、A,B,Cでは
ブラウザに表示するための情報としては不足ですね、というような
話なのです。
914:デフォルトの名無しさん
08/04/20 18:41:22
>>912
メソッドの変数名を日本語で書く習慣があり、その情報を
元に例えば>>904のようなプログラムが生成できるのなら、
問題がないどころか、型情報等、豊かなアサーションを
利用できるのですから、>>909 のようなケレンよりはずっと
上等なのではないでしょうか。
結局前のテーマに戻ってきましたね。
915:デフォルトの名無しさん
08/04/22 06:25:41
>>881
句構造文法的なアプローチでもそうなのでしょうか。
オブジェクト指向論者が日本語の名詞だけ指示して述語を省略する点を
日本語がオブジェクト指向向きであるとする主張の論拠にすることが
ありますが、これは私も感じます。仕様書レベルであっても述語が存在せず、
項を構成できないというケースはあります。
916:デフォルトの名無しさん
08/04/22 06:30:46
>>915
オブジェクト指向言語ではメッセージレシーバが先頭にくる。
これは欧米語の多数派である、主語が文頭にくる文法構造のあらわれ。
日本語のように主語が省略されることが多い言語はオブジェクト指向とは
あまり相性はよくない。
917:デフォルトの名無しさん
08/04/22 06:46:56
日本語も基本的に主語が先頭だと思うけど。
918:デフォルトの名無しさん
08/04/22 07:28:51
>>917がいい例だけど、「思うけど」の主語が抜けてるだろ？
英語でも口語では主語を省略することもあるが日本語ほど頻繁じゃないし、
書き言葉では主語は省略されずに先頭に明示される。
919:デフォルトの名無しさん
08/04/22 07:31:24
省略はあくまで省略だろ。
書こうと思えば書けない事も無い。
920:デフォルトの名無しさん
08/04/22 07:44:42
>>918
なにをするにも self.hoge とか明示的に自分を宣言しないと
いけないOOP言語が好きなようですね。
921:デフォルトの名無しさん
08/04/22 07:45:24
>>919
省略するのが自然か、省略しないのが自然か、それは重要な問題だぞ。
922:デフォルトの名無しさん
08/04/22 07:45:51
>>920
るび厨乙
923:デフォルトの名無しさん
08/04/22 11:27:33
>>920
ちょっと蒸し返すようだけれど、>>896 の self new を
どう評価するべきか迷って、結局触れないことにした。
OOPでは()や{}のように自然なものなんだろうな、と。
だけど、自然言語というか日常的な言語レベルから眺めると、
「え、これなんですか」って誰だって思うよね。
924:デフォルトの名無しさん
08/04/22 13:36:28
どんな種類の言語も、使ってる人には自然で、使ってない人には不自然。
自分が好きな言語だけが自然に思えたら危険サイン。
925:デフォルトの名無しさん
08/04/22 20:39:38
だから自然言語はエスペラント語を使えばいいのに。
926:デフォルトの名無しさん
08/04/22 21:51:29
>>925
あんな欧米語偏重の人工言語を認められるかよ。
927:デフォルトの名無しさん
08/04/22 22:45:19
>>922
蛇毒が体に回っているようですね
928:デフォルトの名無しさん
08/04/22 23:30:50
>>925
ぶっちゃけエスペラントは自然言語ではないと思うのだがどうか。
929:デフォルトの名無しさん
08/04/23 00:24:44
ぶっちゃけなくても自然言語じゃない
930:デフォルトの名無しさん
08/04/23 00:33:46
エスペラントよりロジバンだろ
931:デフォルトの名無しさん
08/04/23 00:54:39
ひんたぼ語を習得しないとあとで後悔するよ
932:デフォルトの名無しさん
08/04/23 06:41:37
まあ、機械翻訳が書きやすい言語が
夢もあって、将来性があるということよ。
933:デフォルトの名無しさん
08/04/23 06:59:43
Googleの悲しい「言語ツール」を開く度につくづくそう思う。
なにが、Pythonだ、Ajaxだ。
934:デフォルトの名無しさん
08/04/23 12:18:39
ロジバンに比べたらエスペラントは自然言語だろ
935:デフォルトの名無しさん
08/04/27 23:31:34
936:デフォルトの名無しさん
08/05/27 09:30:55
937:デフォルトの名無しさん
08/06/08 22:48:11
流れよんでないけど
ＶＢ以外は認めない
938:デフォルトの名無しさん
08/06/12 22:00:22
939:デフォルトの名無しさん
08/07/11 10:44:42
940:デフォルトの名無しさん
08/08/08 00:16:48
cobolのこともたまには思い出してあげてください。
941:デフォルトの名無しさん
08/08/08 01:29:58
夢があるかどうかは別として
１番壮大な夢を持ってんのはLispだな
942:デフォルトの名無しさん
08/08/08 02:18:20
最近Scheme始めたけど、面白いね。
で、数学勉強し始めたんだけど、集合論のあたりでもう苦しんでる。
個人的には、Scalaがいいと思うんだけど、あまり認識されてないみたいだね。
943:デフォルトの名無しさん
08/08/08 07:42:37
>>942
Scalaはシッタカ御用達言語として有名になりつつあるね。
944:デフォルトの名無しさん
08/08/08 18:39:15
C++の問題点は 禿 が理屈っぽいこと。
皆がお前みたいに理屈っぽくないって。
やはり、生産性に問題がある。
ちょっと、考えてみろ。あるプロジェクトに携わっている人間
がすべてお前みたいにわかっているわけじゃあない。
プロジェクトに新入社員がいれば、そいつがプロジェクトの中に
バグを仕込むテロリストになりうるんだぞ(本人にはその自覚が
なくとも結果的にそうなる)。そういうことを簡単に許してしまう
言語なんぞ、いくら切れ味がよくても害にしかならない。
もう、禿のC++0xなんていいって。
945:デフォルトの名無しさん
08/08/08 21:03:57
夢があるっていえば、アラン・ケイが最近のプロジェクトで使っている COLA 。
* cola ? combined lambda/object architecture
URLﾘﾝｸ(piumarta.com)
これと OMeta を使って Win の 2000分の１、Squeak Smalltalkの 10分の１の行数で
GUI 込みの個人向けシステムを書くという。
* Inventing Fundamental New Computing Technologies
URLﾘﾝｸ(vpri.org)
* Implementing Programming Languages for Fun and Profit with OMeta
URLﾘﾝｸ(www.stic.st)
946:デフォルトの名無しさん
08/08/09 06:15:36
JavaScriptやFLASH(Actionscript)
はいつまでもちますか？
947:デフォルトの名無しさん
08/08/09 07:02:11
もうピークは過ぎたね。
948:デフォルトの名無しさん
08/08/09 10:17:32
>>946
Googleの次の企業が出てくるまでは安泰だと思う。
最近は、FlashというかFlexが企業向けRIA技術として流行りつつある感じだな。
949:デフォルトの名無しさん
08/08/10 15:51:30
どんな言語は最初は夢がある。
だが、実際に使われ初めて実用性が求められると仕様が破たんする。
C++なんか、厚化粧で禿げかかっている中年の女。
C#もいずれそうなるだろう。あのMSの言語だから
950:デフォルトの名無しさん
08/08/10 16:10:12
どんな言語は最初は夢がある。
↓
どんな言語も最初は夢がある。
951:デフォルトの名無しさん
08/08/10 16:26:52
>>949
C++は最初から複雑怪奇な言語仕様だったぞ。
952:デフォルトの名無しさん
08/08/10 17:10:02
>>949
MSのC#つっても、トップがJ#とDelphiのヘジルスバグだからなあｗ
953:デフォルトの名無しさん
08/08/10 21:49:18
今はLLやってると夢が広がリングるな。
Pythonだと、ctypesでCのネイティブDLLを簡単に呼べたり、
IronPythonとCPythonの橋渡し頑張ってるひとがいたりするのみてると、
もうネイティブの領域も.Netの領域も美味しいところを拾い食いしながら
楽できるところはPythonでっていう書き方あれこれ考えるだけで楽しいよ。
自分がよく使うからPythonを例に出したけど、Rubyなんかでも同じような
状況の気がする。
954:デフォルトの名無しさん
08/08/10 23:47:52
>>953
どっちかというとpythonよりrubyの方がC関数作りは簡単かも。
まあGCの違いがほとんどなんだけどね。
955:デフォルトの名無しさん
08/08/16 01:16:46
>>949 C++がそうなったのは、MSの言語だったからということではなかろうに。
956:デフォルトの名無しさん
08/08/16 07:15:10
>>949
つまり、このスレ的には非実用的でマイナーな言語が一番
ということですね。
957:デフォルトの名無しさん
08/08/16 08:52:15
そういう夢の強さならWhiteSpace最強だな。
読めないプログラムを作りたい
という思いをシンプルに極めた最強の言語。
958:デフォルトの名無しさん
08/08/17 11:35:03
pythonって手続き脳用の劣化lispって感じがする(少なくともrubyよりは近い)
ライブラリさえ充実できればlispって十分LLの代用になると思うわ
()を上手く処理できるrlwrapクローンがあればシェルからの利用もできるし
>>954
つboost::python
これ使うと一気にその関係は逆転するよ
959:デフォルトの名無しさん
08/08/28 03:26:35
>>958
問題はなぜ50年近くも経って
ライブラリさえ充実できないのかということですね。
960:デフォルトの名無しさん
08/08/28 08:20:56
処理系が沢山あって何を標準にしたらいいかわからんからかも
961:デフォルトの名無しさん
08/08/28 08:53:22
ライブラリは沢山あるけど、どれも相互運用を何も考えてないからなあ。
結局つなぎ合わせるだけで結構なコード量になっちまう。意味なし。
962:デフォルトの名無しさん
08/08/28 09:07:24
関数型はいつでもコードなら書けるとライブラリにしない傾向があるね。
ちょっと自信過剰かな。
963:デフォルトの名無しさん
08/08/28 09:46:09
perlやCのライブラリを利用すりゃいいじゃんｗｗｗ
みたいな考えなのかな？