初心者が習うといい言語は何？？？part2

1 ：デフォルトの名無しさん：04/01/21 02:58

プログラムの初心者なんだけど
どれを習えばいいですか

2 ：デフォルトの名無しさん：04/01/21 02:59

アセンブラで FA

3 ：デフォルトの名無しさん：04/01/21 03:01

前スレで、ネタとはいえBrainfuckが出るとは思わなかった

4 ：デフォルトの名無しさん：04/01/21 03:02

前スレッド
初心者が習うといい言語は何？？？
http://pc2.2ch.net/test/read.cgi/tech/1071138539/

5 ：デフォルトの名無しさん：04/01/21 03:07

LOGOでタートルグラフィック

6 ：デフォルトの名無しさん：04/01/21 03:07

JavaScript

7 ：デフォルトの名無しさん：04/01/21 03:10

LOGOならSquakeだろ。

8 ：デフォルトの名無しさん：04/01/21 03:11

C#　簡単なJAVA
JAVA　安全なC#

9 ：デフォルトの名無しさん：04/01/21 03:11

Smalltalk。
絵本も出てるよ。

しかし、絵本が出版されている言語って未だかつてあっただろうか。

10 ：デフォルトの名無しさん：04/01/21 03:12

性格にはSquakeだった。
モフモフモフ

11 ：デフォルトの名無しさん：04/01/21 03:13

ECMAScript
これマジ。

12 ：デフォルトの名無しさん：04/01/21 03:16

Ocaml。
Schemeみたいな半端はやめよう。

13 ：デフォルトの名無しさん：04/01/21 03:19

HSP一択

14 ：デフォルトの名無しさん：04/01/21 03:19

前スレではCとJavaが圧倒的に多かったけど結局どっちがいいの？

15 ：デフォルトの名無しさん：04/01/21 03:20

16 ：デフォルトの名無しさん：04/01/21 03:21

>>14
文字列を扱うのにも一苦労、メモリも管理しなくちゃならない。
そんな言語入門に向いていると思いますか？

17 ：デフォルトの名無しさん：04/01/21 03:36

工学的な計算ならC
設計とかが重要になってくる大規模なシステム開発ならJava
Web + DBならPHP
汎用的なテキスト処理ならRuby
統計関連ならExcel VBA

でいいんじゃね？目的に沿って勉強することが肝要。

18 ：デフォルトの名無しさん：04/01/21 03:50

初心者の目的はほぼみんなGUIアプリでしょ。
腐った2ちゃんねらには「nimdaを超える奴！」とかいるかもしれんが。

19 ：デフォルトの名無しさん：04/01/21 03:51

いやCGIとかWebプログラミングってヤシもそれなりにいると思われ。

20 ：デフォルトの名無しさん：04/01/21 03:54

>>16
BASICがお薦め

21 ：デフォルトの名無しさん：04/01/21 03:57

>>17
一つ前のスレッドにも書いたけど、あなたの答えはほぼ正しいし、
「学ぶ目的による」っていうのはもっともなんだけど、それだと全然
話に建設性が無いんだよね。もう一歩進めて、

・プログラミングの本質さえ身につければ、どんな言語でも使えるようになる。
・ではプログラミングの本質とは何なのか?
・それを身につけるにはどの言語が最適なのか?

ということを議論した方がいいんじゃないかな。

22 ：デフォルトの名無しさん：04/01/21 03:58

どっちにしろDelphiできまりじゃん。

23 ：デフォルトの名無しさん：04/01/21 04:38

>>3
完全にネタかどうかはわからんがな。
初心者にチューリングマシンをいじらせるというのも
ノイマン型コンピュータの基礎を学ばせるためにも良い

24 ：デフォルトの名無しさん：04/01/21 04:48

チューリングマシンを理解しておくのはよいが、
プログラムの勉強としてやられちゃたまらない。あれはパズルだろ。
実際チューリングマシンのプログラムが出来るとメリットあるかねぇ。

25 ：デフォルトの名無しさん：04/01/21 05:14

>17
意味ない。
プログラミング言語をどれもいっしょくたに
考えるのは馬鹿げているということに気づけ。

英語、中国語、ドイツ語、フランス語
これらのうち１つを身に着ければ、どんな言語でも使えるようになるというのは
あり得ないし、また、言語が育った環境により本質は相対的に変化する。

アメリカに行くなら英語、中国に行くなら中国語、ドイツに行くならドイツ語
フランスに行くならフランス語を学ぶのが正解。

26 ：デフォルトの名無しさん：04/01/21 05:17

レス番まちがえた。25は>>17じゃなくて>>21。

27 ：デフォルトの名無しさん：04/01/21 05:22

Brainfuckは初心者向けなの？

28 ：デフォルトの名無しさん：04/01/21 05:26

>>25
いいえ。プログラミングの基本的な考え方は同じですよ。
最大公約数的なものは存在します。
情報の授業の最初の方でやりませんでしたか?

29 ：デフォルトの名無しさん：04/01/21 05:35

>>28
＞プログラミングの基本的な考え方は同じですよ。

ダウト。本当に基本的かつ共通しているものはごくごくわずか。
代入とループ、条件判断ぐらい。

30 ：デフォルトの名無しさん：04/01/21 07:56

>>29
考え方 != 書き方

31 ：デフォルトの名無しさん：04/01/21 10:45

>>30
書き方については何１つ言ってませんがｗ

32 ：デフォルトの名無しさん：04/01/21 10:53

>>31
書き方の話と勘違いしてるんじゃないのか？ってことでしょう。
プログラミングどころか日本語もまともに理解できないようですね。

33 ：デフォルトの名無しさん：04/01/21 11:06

>>32
言語が生まれた背景、思想が
違うのだから考え方や書き方が違うのは当たり前。

っで>>17に戻るわけ。わかりますか？池沼さん。('A`)

34 ：デフォルトの名無しさん：04/01/21 20:09

>>33
> 言語が生まれた背景、思想が
> 違うのだから考え方や書き方が違うのは当たり前。
そうだな。だがそれならば、
考え方や書き方によって分類するべきであって、
目的によって(偏見に基づいて)分類する>>17にはならない。

例えば:

工学的な計算なら(並列化の容易な)Fortran
大規模なら(Javaより速度が速く柔軟な)C++
テキスト処理なら(デファクトスタンダードの)Perl
統計関連なら(VBAなんて小規模でしか使えん)S

のほうがましではないかとおれは思うね。
個人的には数値計算以外は全部Haskellでやりたいが:-)

考え方の分類として
関数型,手続き型,オブジェクト指向型
ぐらいで初心者にどれをすすめるべきか議論してみてはどうだろう？

35 ：デフォルトの名無しさん：04/01/21 20:35

以上の意見のもと、Whitespaceが一番ということに決定しました。

36 ：デフォルトの名無しさん：04/01/21 20:55

>>22
＞・プログラミングの本質さえ身につければ、どんな言語でも使えるようになる。
＞・ではプログラミングの本質とは何なのか?
＞・それを身につけるにはどの言語が最適なのか?

それはそれで一つの面白いテーマだと思うけど、「初心者が習うといい言語は何？」からはかなりかけ離れてしまわないかな？

37 ：デフォルトの名無しさん：04/01/21 21:18

>>34
>工学的な計算なら([Cより]並列化の容易な)Fortran
>大規模なら(Javaより速度が速く柔軟な)C++
>テキスト処理なら([Rubyより]デファクトスタンダードの)Perl
>統計関連なら(VBAなんて小規模でしか使えん)S

その通りだけど、「プログラマ」をどう捉えるかの問題だな。
専門分野だけに精進すればよいプログラマも居れば、
幅広い分野に対応する事が重要なプログラマも居るだろう。

38 ：デフォルトの名無しさん：04/01/21 21:21

オンラインゲームで勝手にレベルとか上げてくれる
そんなプログラムを書けるようになりたいのですが
このような目的の場合どういった言語が適しているのでしょうか?

39 ：デフォルトの名無しさん：04/01/21 21:27

>>38
SQL

40 ：デフォルトの名無しさん：04/01/21 22:04

>38
マウスやキーボードをフッキングしたいなら
APIを叩けてDLLを作れる言語が必要(Winの場合)。

41 ：デフォルトの名無しさん：04/01/21 22:17

逆に「初心者には勧めない」言語を考えれば答えが出るかも。

・今時オブジェクト指向のサポートが無い　C
・基本型だけ特別扱い Java
・リアルタイムにAVを扱うのに不向き Perl
・アルゴル系手続き型言語でない Prolog

とかはやはり向いていないと思うし。

42 ：デフォルトの名無しさん：04/01/21 22:20

>>38
そんなことしたらおもしろくないよ！
レベルは自分で上げなさい！

43 ：デフォルトの名無しさん：04/01/21 22:31

Fortranやっとけｗ
go toを知らない人間になってはいけない。

44 ：デフォルトの名無しさん：04/01/21 22:35

>>41
全然わかってないねｗ

45 ：デフォルトの名無しさん：04/01/21 22:37

一つの言語に慣れてしまうと別の言語の習得が困難になる。
だから最初から将来必要になる言語で入門した方がいいよ。

なんて事は無いと思う。

46 ：デフォルトの名無しさん：04/01/21 22:41

何でもいいから、ち　ゃ　ん　とやっとけ。

47 ：デフォルトの名無しさん：04/01/21 23:33

なんでも諦めて生きてる俺

48 ：デフォルトの名無しさん：04/01/22 00:40

>>36
> それはそれで一つの面白いテーマだと思うけど、「初心者が習うと
> いい言語は何？」からはかなりかけ離れてしまわないかな？

しかし、これこそが本スレッドのテーマに対する直球の答えだと思うけどな。

49 ：デフォルトの名無しさん：04/01/22 03:00

構造化プログラム言語
関数型プログラム言語
オブジェクト指向プログラム言語
いずれも弄った方がいいという
指導案についてはどう思われる？

50 ：デフォルトの名無しさん：04/01/22 03:55

>>38 さんにちょっと似てますが、

パラレルポート経由で外部に接続したゲーム機の自動操作をしたいと思ってます。

http://www.dcn.ne.jp/~kazu68k/doushi.html

早い話、ここにあるシステムを移植しようと思うんですが、開発環境の中でい
いのってどれでしょうね。ターゲットの OS は Win2k or WinXP です。

ゲーム機の垂直同期信号をジョイスティックポートに直結し、トリガとします。
テキストで記述した1フレームごとの操作を読み込み、待機。
ユーザが始動を指示すると、以降トリガの入力があるたびに、それを
1 フレーム分ずつパラレルポートに送り出すというものです。
7bit 2CH では足りないので、将来的には 6bit 4CH の回路を作るつもりです
(どういう回路にすればいいのかはこれから勉強します)。

51 ：デフォルトの名無しさん：04/01/22 03:55

ミジンコ並みの知能しか無い自分には HSP が向いてそうだと思います。
giveio.sys 経由でパラレルポートを制御できることは知っているのですが、
1/60 以下の応答速度が必要なので、インタプリタで大丈夫か!? などと思っ
ています。ターゲットマシンの最低水準は Crusoe 600MHz ぐらいです。

とりあえず、体裁はともかく現実のものとするのが先決なので、プログラムに
はバックエンド的働きをさせ、GUI は無くてもいいと思っています。

自分は、シェルスクリプトや Awk, SED をかじったことがある程度のスキルし
かありません。

・WinNT 系 OS 下で、パラレルポート、ジョイスティックポートの入出力が比較的容易
・Crusoe 600MHz 程度のマシン上で動作させ、1/60のスピードについてくる
・ミジンコでも可(事例が多い)
・できればタダで入手可能

こんな言語(処理系)を探しております。よろしくお願い致します。

52 ：デフォルトの名無しさん：04/01/22 15:49

素直にC++使え

53 ：デフォルトの名無しさん：04/01/22 19:56

だからC#がいいって

54 ：デフォルトの名無しさん：04/01/22 21:31

JScript

55 ：デフォルトの名無しさん：04/01/22 22:55

>>49
構造化とオブジェクト指向を分けている理由は？

56 ：デフォルトの名無しさん：04/01/23 00:19

例として↓に Peter Norvig の学習計画案( または指導要領 )がある。
http://www1.neweb.ne.jp/wa/yamdas/column/technique/21-daysj.html

・少なくとも半ダースのプログラミング言語を学ぶこと。
　そのうちの一つはクラス抽象をサポートするもの（例えば Java や C++）、
　一つは関数抽象をサポートするもの（例えば Lisp や ML）、
　一つは構文抽象をサポートするもの（例えば Lisp）、
　一つは宣言的記述をサポートするもの（例えば Prolog や C++ テンプレート）、
　一つは coroutine をサポートするもの（Icon や Scheme）、
　そして一つは並列処理をサポートするもの（例えば Sisal）であること。

57 ：デフォルトの名無しさん：04/01/23 00:49

HSPか。。。
つうか、HSPスレ、あれなんなの？

58 ：デフォルトの名無しさん：04/01/23 00:51

厨房の巣窟

59 ：デフォルトの名無しさん：04/01/23 09:42

>>57
ゲ制作板のスレが実質的に本スレ

60 ：デフォルトの名無しさん：04/01/23 11:42

初心者＝プログラムとは何ぞやと全く知らない人(読めも書けもしない)
とし、

プログラムを理解するためであってマスターすることが目的でないなら
もうpascaｌかCやっとけ。できればＣ。プログラムをある程度理解するだけならポインタもメモリ管理も必要ない。
ある程度どんなものか分かったらあとは自分の作りたい分野のことを調べて進めばいい。

61 ：デフォルトの名無しさん：04/01/23 11:54

ポインタをつかわないのであれば C なんか使う必要ない

62 ：デフォルトの名無しさん：04/01/23 12:15

>>25
亀レスですまんが・・・・

ポルトガル語とスペイン語は似ている。
日本語と韓国語も似ている。
日本語と中国語は部分的には似ている（漢字等）
でも日本語とスペイン語は似ていない。

以上のことを踏まえると、
>>21 >>25
の中間ぐらいだと思う。
C++とJavaは似ているが、
C++とDelphiはあまり似ていない。

つまり移行の仕方によっては、理解しやすくなる事もあれば、
そうでないこともある。

63 ：デフォルトの名無しさん：04/01/23 12:18

前スレ埋めよーぜ！

C++最強！！！！！！！！！！！！！！！！！

64 ：デフォルトの名無しさん：04/01/23 15:39

>>34
> 大規模なら(Javaより速度が速く柔軟な)C++
> テキスト処理なら(デファクトスタンダードの)Perl
こいつ本気でこう思ってんのかな。

大規模ならJavaよりC++とかって。
「速度なら」の間違いだろ。

大規模ならC++よりJavaのほうが開発効率は高い。
Perlがテキスト処理のデファクトかねえ。
Perlライクな正規表現ならほかの言語でもできるようになってきているし。

65 ：デフォルトの名無しさん：04/01/23 23:53

いまどきPerlはないだろ。目が腐るから止め説け。正規表現なんてほかにもいくらでもある。
はっきり言って純粋に言語としてはJavaでもう結論が出てるだろう。
ただし、初心者が作りたいのはWindowsネイティブアプリだろうから、
そこが問題だ。
だがあえて、最初はJavaを推す。nyみたいなへんなGUIでも受け入れられるなら、
Javaでも問題ないだろう。そのうちC#も書籍が増えてきてWinFXも出てくるから、
やっぱりネイティブがやりたければWindows実用本位コースでC#やればいいし、
賢者コースで関数型に進んでもいいし、ハッカーコースでCでLinuxのカーネルをハックしてもよい。

66 ：デフォルトの名無しさん：04/01/24 00:26

>>64-65
こいつらの perl の知識って正規表現をサポートしていることぐらいしか知らないんだろうな...。

67 ：デフォルトの名無しさん：04/01/24 13:30

構文糖の豊富過ぎる言語は、初心者に自己流の変な癖を付けさせるので良くないと思う。

68 ：デフォルトの名無しさん：04/01/24 13:37

>>67
同意。構文糖というか、無駄に等価表現が重複するのは、
本質の理解や他人のソースでの勉強も阻害する。Perlはうんこ。

69 ：デフォルトの名無しさん：04/01/24 13:52

初心者にはCASLが一番だよ

70 ：デフォルトの名無しさん：04/01/24 14:01

計算機がどう動くかは、言語としてではなく、知識として学ぶのがよいと思われ。

71 ：デフォルトの名無しさん：04/01/24 14:15

Javaは馬鹿になるから却下
それに本質が見えにくい。
本質が見える言語でないと駄目だな

72 ：デフォルトの名無しさん：04/01/24 14:18

テキスト処理なら(デファクトスタンダードの)Python

73 ：デフォルトの名無しさん：04/01/24 14:18

>>66
java厨房はperl挫折して
より簡単なjavaに逃げた馬鹿が多いからそっとしてやれ

74 ：デフォルトの名無しさん：04/01/24 14:20

JavaとPerlで喧嘩する理由がわからん

75 ：デフォルトの名無しさん：04/01/24 14:24

>>74
JavaはUNIX文化の新参者だから
UNIX文化に溶け込んでるPerl使いから見るとまだ異端分子なんだよ

76 ：デフォルトの名無しさん：04/01/24 14:33

>>71
１行目と２行目の根拠はなに？真を突かれてファビョっちゃった？（ｗ

>>73
スレタイ１万回読んでこい。

>>75
それは同意。JavaはUnix文化ではない。
ちゅうか、実世界ではUnix文化などもはや存在しないも同然。

77 ：デフォルトの名無しさん：04/01/24 14:36

会計処理なら(デファクトスタンダードの)COBOL

78 ：デフォルトの名無しさん：04/01/24 14:50

>>74
>>64-65のJava厨がPerlを叩いたから反発した人がいるだけでしょ。

Perlは大きなプログラムを書くには向いてないけれど、
Perl数行のものをJava何十行で書くのはただのアホ。

ところで、Javaってやってて面白い？
おれはJavaはつまらないから嫌い(C++とかschemeは面白い)。
Javaはプログラミングが作業でしかないと感じさせてくれる。
初心者だとそんなことは思わないかな？

79 ：デフォルトの名無しさん：04/01/24 14:59

>>76
確かに派遣社員にはUNIX文化も糞もないよな
ただの作業員に過ぎんから

80 ：デフォルトの名無しさん：04/01/24 15:06

>>78
コーディング（タイピング？）はそうだね。だが初心者が学ぶべきはコーディング作業ではない。
いくらかコードが長くてもきれいでわかりやすいことが重要だ。

81 ：デフォルトの名無しさん：04/01/24 15:08

>>79
真性のあふぉ。Perl使いって、結局こんなんか？HSPとかわらんな（ｗ

82 ：デフォルトの名無しさん：04/01/24 15:14

>>80
て言うか、適材適所だろ。
perl は、書き易さ >>> 読み易さとして設計されてるから、「初心者」にとっては >>67-68 の意見は正しい。
でも、それは perl の特長であって perl が使えねーと言うこととはちょっと違う。

>>81
煽りに反応するなよ...。

83 ：デフォルトの名無しさん：04/01/24 15:24

ここは初心者が習うといい言語スレでふ。
perlが使えねーではなく、perlは使えるだけだからここではうんこなのでふ。

84 ：デフォルトの名無しさん：04/01/24 15:58

>>82
適材適所といいながら、「書き易さ」と括っているのはどうかと思うが。

Perl（に限らず、スクリプト言語は）
「一瞬で書き下せる範囲のロジック」を「本当に一瞬で書き下せる」ように設計されてるのであって、
長期に渡ってメンテされていくような大規模システムになると、
「読み難さ＝メンテのし難さ」なので、結局Perlは不向き。

85 ：デフォルトの名無しさん：04/01/24 16:04

・・・というような話だったのに、なんでいきなりJavaが出てきたんだろう

86 ：デフォルトの名無しさん：04/01/24 16:05

perlのソースが読めない馬鹿をまともに相手にしていてもしょうがない。
馬鹿は馬鹿なりに身分をわきまえて一生Javaでもしてなさいってこった。

87 ：デフォルトの名無しさん：04/01/24 16:06

JavaとPerlじゃどう考えてもPerlの方が一歩進んだ言語だと思うんだが・・・
最近の超高級言語と言われているものはかなり楽しいよ。
PerlやPythonなどオススメ。

88 ：デフォルトの名無しさん：04/01/24 16:06

>>83
まあ、そうやね。
このスレ的には、うんこと言うのには同意。

>>84
perl が大規模システムに不向きで、一瞬で書き下せる範囲のロジックを書き下ろすのに向いてるだけだろ。

世間では、それを適材 (perl) 適所 (簡単なロジックを記述する) と言うんだけどな。

89 ：デフォルトの名無しさん：04/01/24 16:09

つーか、既に古い言語だよJavaは。
Perlより古くなかったか？
ECMAScript(JavaScript)の方がまだ進んでいる。

ここの下の方の「付録」でも読んでなさい。
ttp://www.shiro.dreamhost.com/scheme/trans/icad-j.html

90 ：デフォルトの名無しさん：04/01/24 16:11

>>82
漏れはperlから入ったから、おっしゃる点で確かに苦労した。
バカな勘違いも多かった。
でも原理原則を分かったとたん、結局のめり込んだ。
漏れ文系頭なんだが、他の言語はどうしても違和感あったが、
なんだかperlだけはちょっと毛色が違っていた。

91 ：デフォルトの名無しさん：04/01/24 16:12

>>87
> JavaとPerlじゃどう考えてもPerlの方が一歩進んだ言語だと思うんだが・・・

どこが進んでいるのが具体例プリーズ。

>>89
新しければいいのか ?
だったら、C# にでもしとけよ。

92 ：デフォルトの名無しさん：04/01/24 16:14

最低でもクロージャくらい実装していないとな。
この時点でJava失格。
C++を引きずりまくって古いオブジェクト指向（と言うかクラスベース）の言語だし。
JavaScriptの方がプロトタイプベースなオブジェクト指向だから先へ行っている。

クラスベースでも動的分類くらいサポートして欲しいものだ。

93 ：デフォルトの名無しさん：04/01/24 16:14

スレタイを小一時間読んできてください。

94 ：デフォルトの名無しさん：04/01/24 16:15

で、先に行っている言語を習う方がいいのか？初心者は。

95 ：デフォルトの名無しさん：04/01/24 16:15

>>91
> だったら、C# にでもしとけよ。
C#はJava下敷きにしているからJava同様C++引きずりまくっている古い言語だよ。
Boxingとかごまかし技術は進化したけどね。

96 ：デフォルトの名無しさん：04/01/24 16:16

F#にしとけ。

97 ：デフォルトの名無しさん：04/01/24 16:16

Perlの言語としての凄さを解っていない人結構多いね。

98 ：デフォルトの名無しさん：04/01/24 16:17

Perlはオープンソースの草分け的な存在。
そのオープンソース界を最近はJavaが
金塗れにしてきやがった。
UNIX使い、Perl使いがJavaを忌み嫌う理由は分かる。

99 ：デフォルトの名無しさん：04/01/24 16:17

>>97
Perlの言語としての凄さを具体的にきぼんぬ。

100 ：デフォルトの名無しさん：04/01/24 16:17

今時クロージャが出来ない言語使いたくないな。
Perlはそこら辺解っている。

101 ：デフォルトの名無しさん：04/01/24 16:21

クラスベースのオブジェクト指向はみんな半端だよ。
動的分類も多重分類もサポートできない。
Smalltalkだけじゃなかったか？動的分類サポートしているの？

あと、関数型言語とかプロトタイプベースオブジェクト指向言語はクラスベースオブジェクト指向
を完璧に内包できると思うがどうだろ。

102 ：デフォルトの名無しさん：04/01/24 16:21

>>100
>今時

今更かよｗ

103 ：デフォルトの名無しさん：04/01/24 16:22

JavaはPerlよりダメだが、結局Perlもダメ。

104 ：デフォルトの名無しさん：04/01/24 16:24

>>101
PerlならJavaの機能は全部エミュれるってこと？
逆は不可能で。

105 ：デフォルトの名無しさん：04/01/24 16:27

結局教科書の問題なんだよね。

初心者向けだと Java に比べれば JavaScript の方が良いのは分かり切っているし、
Perl でもまだマシなんだけれども、どちらもWWWプラウザだのCGIだの特化したやつ
が主になってしまっているから。

Python だと良い教科書あるけど言語自体すごくマイナーだし。

106 ：デフォルトの名無しさん：04/01/24 16:27

UNIX,Linuxアプリケーションで
Javaオープンソース
って聞かないよな。
システム的にコア部分は大抵がC,
システム管理部分はPerlと相場が決まってるんだが。
PHPもオープンソースは聞かないなぁ。
オープンソースに貢献しない言語はJava位だよな。
Java使いが悪いのか言語が悪いのか知らないけど

107 ：デフォルトの名無しさん：04/01/24 16:32

>>106
!!

108 ：デフォルトの名無しさん：04/01/24 16:32

http://www.shiro.dreamhost.com/scheme/trans/icad-j.html
> 私が言う言語の相対的な力を説明するために、次の問題を考えてみよう。
> アキュムレータを生成する関数、すなわち、数nを取り、「数iを取ってnをiだけ増加させ、
> その増加した値を返す関数」を返すような関数だ。

* Common Lisp
>
> (defun foo (n)
> 　#'(lambda (i) (incf n i)))

* Perl 5
>
> sub foo {
> 　my ($n) = @_;
> 　sub {$n += shift}
> }

* Smalltalk
> foo: n
> 　|s|
> 　s := n.
> 　^[:i| s := s+i. ]

* JavaScript
> function foo(n) {
> 　return function (i) {
> 　　　　　return n += i } }

109 ：デフォルトの名無しさん：04/01/24 16:32

* Java
> 他の言語ではどうだろう。この話で述べた他の言語--Fortran, C, C++, Java,そして
> Visual Basic--では、この問題が解けるかどうかさえ定かではない。 Ken Andersonは、
> 次のコードはJavaでやる限り最も近い解だと述べた
>
> public interface Inttoint {
> public int call(int i);
> }
>
> public static Inttoint foo(final int n) {
> return new Inttoint() {
> int s = n;
> public int call(int i) {
> s = s + i;
> return s;
> }};
> }
>
> これは整数でしか動作しないという点でもとのスペックに届いていない。 Javaハッカーとずいぶん
> メイルで討論したが、上の方で示したような例と同様に動作する真に多態なコードをJavaで書くのは、
> ものすごく不自由と不可能との間だ、ということのようだ。誰かうまく書けたら是非見せて欲しい。私は自分でもいろいろやってみたが時間切れだった。

結局Javaって非力なんだね。
新しい言語にはかなわないか（ｗ
でもSmalltalkにも負けてるけどな（ｗ

110 ：デフォルトの名無しさん：04/01/24 16:34

Perl厨だけでなく、プロトタイプスレをみた知ったか厨が沸いてきたな（ｗ
大規模向けに型をとるか、柔軟でいくかの違いだろ。
型でいくならクロージャだってクラスでいいだろ？
わかったら、いやわからなくても、スレタイ１０億回読んで来い。

111 ：デフォルトの名無しさん：04/01/24 16:35

>>110
クラスはクロージャでエミュレートできるがクロージャはクラスでエミュレート出来ない。
馬鹿ですか？

112 ：デフォルトの名無しさん：04/01/24 16:35

結局どれから入っても大差ないわな
興味を持って持続できるテーマがあるかどうかの方が問題。

113 ：デフォルトの名無しさん：04/01/24 16:35

御自分の無知をさらけだすスレッドではありません。あしからず。

114 ：デフォルトの名無しさん：04/01/24 16:36

このスレの今の流れで語るなら、
俺はJavaとMLを両方マスターしてるのでPerlは要らん。

115 ：デフォルトの名無しさん：04/01/24 16:38

ただ、実業ではやらないと決めているなら、プロトタイプはいいかな。
型、クラスはそれのセンスをつける必要があるが（だから最初からやるべき）、
もともといらないなら不要な束縛かもしれん。
実業では強い型でないとやってらんないけどな。

116 ：デフォルトの名無しさん：04/01/24 16:38

しかし、Javaの方がPerlより上だと思っているヤツがこんなに居たとは驚きだｗ

Perl = cgiを書く素人が使う言語

と言う認識が知らないうちに出来上がって正当な評価がされていないのかもな。

117 ：デフォルトの名無しさん：04/01/24 16:38

関数型言語から輸入した機能を理由にJavaをPerl厨。
ﾐｯﾄﾓﾈ

118 ：デフォルトの名無しさん：04/01/24 16:40

Cが日本に入ってきたときは素直に感動したよ
BASICで異様に冗長な予約語、構文がとても
簡易に表記できて、とにかく嬉しかったな

PASCALはシンタックス・ダイアグラムとかを
含めて初心者にお勧めしたいけど
今となるとどうだか

119 ：デフォルトの名無しさん：04/01/24 16:41

>>115
asert
policy
UnitTestで無問題。

kent beckはSmalltalkで仕事していたんだよな。

120 ：デフォルトの名無しさん：04/01/24 16:44

>>111
馬鹿皿仕上げ

121 ：デフォルトの名無しさん：04/01/24 16:44

なんか知らんがPerl厨が沸いてきたな。
たしかにJavaよりはマシだと思うがPerlは汚すぎ。

122 ：デフォルトの名無しさん：04/01/24 16:44

EXCEL＋VBAはちょっとした分析や研究に使うのには楽でいいね。
関数型言語と手続き型言語の長所を生かしたプログラミングが出来る感じで。

123 ：デフォルトの名無しさん：04/01/24 16:48

スレタイも読めないバカばかり

124 ：デフォルトの名無しさん：04/01/24 16:48

Perl使いってのは、プログラマではなくてUNIX信奉者だからな。
技術板で嫌われるのは仕様。

125 ：デフォルトの名無しさん：04/01/24 16:48

沸いてきたPerl厨は、スレタイを１兆回読んで吊れ。
はなしはそれからだ。

あと、>>106 いまどきjakartaとかも知らない池沼ですか？
あともともとクラスベースはオプソに合わないんだよ。
C++はJavaよりオプソに貢献してるのか？

126 ：デフォルトの名無しさん：04/01/24 16:49

>>108のリンク先に書いてある「レキシカル変数」ってなに？
素人同然なんで読んでいてまったく意味がわからず。
誰か分かりやすいように説明おながいします。

127 ：デフォルトの名無しさん：04/01/24 16:50

だからc#やれって。

128 ：デフォルトの名無しさん：04/01/24 16:52

字面の通りレキシカル（文脈依存）で決まる変数じゃないの。

129 ：デフォルトの名無しさん：04/01/24 16:52

>>125
それはJava厨の為のオープンソースだろうが。
頭おかしくなったのか？

130 ：デフォルトの名無しさん：04/01/24 16:55

>>119
> asert

ププッ。
タコな奴は自分で間違いを見つけることできないんだから、型付けの強い言語使えよ。

131 ：デフォルトの名無しさん：04/01/24 16:55

Java厨はJava以外には決して貢献しない
UNIX界の害虫だからMS批判するのは100万年早い

132 ：デフォルトの名無しさん：04/01/24 16:55

>>128
すまん、具体例がないと馬鹿だからわからないかも・・・
オレ、これじゃプログラマにはなれなそうだな。

133 ：デフォルトの名無しさん：04/01/24 16:58

宣言された字面的 (lexical) スコープ内のみで有効な変数のことだろ。

{
　int i;
　ここで i が使える
　関数コール　←　呼ばれた関数内で i は使えない。
}
ここで i は使えない

134 ：デフォルトの名無しさん：04/01/24 16:59

お前らレベル低すぎ

135 ：デフォルトの名無しさん：04/01/24 17:01

>>134
元々持ってない爪を隠しているフリをするのはよせ。

136 ：デフォルトの名無しさん：04/01/24 17:03

>>132
リンク先の例で言うと、i を「外から与えられる何か」というままで書き下せない
のが Python のイヤンな所という訳だ。

137 ：デフォルトの名無しさん：04/01/24 17:06

Perlはとりあえずすぐ作る向けだけあって、ユーザは気が短いね。
関係ないことばっかり書いて、スレタイ読むという当たり前のこともすっ飛ばす。

138 ：デフォルトの名無しさん：04/01/24 17:15

おいらは江戸っ子だからPerlが向いてる

139 ：デフォルトの名無しさん：04/01/24 17:20

>>133
それって普通のローカル変数とどうちがうの？

>>136
ごめん、それ見てもわからなかったんだ。

うーん値の保持が出来るローカル変数ってことなのか。
いや違うような・・・

馬鹿でスマン＿|￣|○

140 ：デフォルトの名無しさん：04/01/24 17:22

だめだ、全然わかっていないっぽいんで出直してくる。
教えてくれたみんな、ありがとう。

141 ：デフォルトの名無しさん：04/01/24 17:23

江戸っ子は、Perlでさくっと書くに至る前に、
ぐちゃぐちゃのソースにぶち切れると思われ。

142 ：デフォルトの名無しさん：04/01/24 17:27

>108見て初めて知ったよ。
Javaって結構駄目な言語だったんだな。
C++の延長だから仕方ないのか。

143 ：デフォルトの名無しさん：04/01/24 17:28

本物の江戸っ子はプログラムをしない

144 ：デフォルトの名無しさん：04/01/24 17:29

所謂、『超高級言語』は全部スクリプトだからどんなに進んだ言語だとしても仕事には使えません。

145 ：デフォルトの名無しさん：04/01/24 17:30

スクリプトって何？

146 ：デフォルトの名無しさん：04/01/24 17:32

コンパイルしないでソースむき出しなヤツ

147 ：デフォルトの名無しさん：04/01/24 17:32

Perlはコンパイラあるよ

148 ：デフォルトの名無しさん：04/01/24 17:32

仕事の種類によるだろ

149 ：デフォルトの名無しさん：04/01/24 17:33

宇宙でも活躍するJava、火星探査車を動かす
http://www.itmedia.co.jp/news/articles/0401/16/news028.html

150 ：デフォルトの名無しさん：04/01/24 17:33

perlはバイナリに出来るよ

151 ：デフォルトの名無しさん：04/01/24 17:36

>>149
多分、火星探査車が動かなくなったのは
javaのメモリ管理の甘さが原因だと思うな。
メモリで死ぬ事が他の言語に比べて圧倒的に多い

152 ：デフォルトの名無しさん：04/01/24 17:40

>>151
他の言語の具体例きぼんぬ。

153 ：デフォルトの名無しさん：04/01/24 17:41

メモリで死ぬって何？

154 ：デフォルトの名無しさん：04/01/24 17:42

インチ表記とメートル表記で目盛りが違ってたって事。

155 ：デフォルトの名無しさん：04/01/24 17:43

ごめん。i じゃなくて n だった。Python では内側の def bar(i) の中では n を参照出来ない。
n を自分の外側のスコープで定義されている値として見に行けないのがイケてないって事。
lexical なら外へ外へ、最終的には大域変数まで n を探しにいってくれるはず。

156 ：デフォルトの名無しさん：04/01/24 17:46

>>144
スレタイ読めよ。

157 ：デフォルトの名無しさん：04/01/24 17:49

perlの処理系は何で書かれていますか？
やっぱｃですか？
javaは？

158 ：デフォルトの名無しさん：04/01/24 17:49

>>142
おまいや>>108は、リンク先の内容の意味をわかっていっているのかと、小一時間（ｒｙ

159 ：デフォルトの名無しさん：04/01/24 17:50

>>157
Perlは実装だけど、Javaは言語です。
ちなみにSUNのJava実装はC++と聞いたことがあります。
そして、この話題はすれ違いです。

160 ：デフォルトの名無しさん：04/01/24 17:55

>>159
??

161 ：デフォルトの名無しさん：04/01/24 18:01

Perlは基本的にひとつしかないが、
Javaは言語仕様に基づいて複数の処理系がある（Cとか普通の言語と同じ）

162 ：デフォルトの名無しさん：04/01/24 18:02

宇宙でも活躍するJava、火星探査車を壊す
http://www.mainichi.co.jp/news/selection/20040123k0000e030005001c.html

163 ：デフォルトの名無しさん：04/01/24 18:03

>>161
Perlに言語仕様はないのか？

164 ：デフォルトの名無しさん：04/01/24 18:09

>>162
擦れ違い。かつ、Javaかどうか以前にソフトかどうかも不明。
そもそも、メモリ云々言ったやつは、結局ファビョったPerl厨の知ったかか？

165 ：デフォルトの名無しさん：04/01/24 18:22

>164
Javaは悪い言語では無いが、火星探査車の制御に使える言語では無い。
Javaがかかえるメモリ管理の問題を知らないのか？

166 ：デフォルトの名無しさん：04/01/24 18:24

>>165
存じません。
ご教授いただきたいのですが。

167 ：デフォルトの名無しさん：04/01/24 18:25

ここで問題なのは火星探査車の制御に使える言語かどうかではなく、
初心者が習うといい言語かどうかだ。

168 ：デフォルトの名無しさん：04/01/24 18:29

>166
Googleも知らんのか？
http://www.google.com/search?hl=ja&inlang=ja&ie=Shift_JIS&q=GC+idle+Java&btnG=Google+%8C%9F%8D%F5&lr=

169 ：デフォルトの名無しさん：04/01/24 18:31

火星探査の初心者ですが、どの言語がいいですか？

170 ：デフォルトの名無しさん：04/01/24 18:36

>>169
Perl

171 ：デフォルトの名無しさん：04/01/24 18:38

>>168
> javaのメモリ管理の甘さが原因だと思うな。
> メモリで死ぬ事が他の言語に比べて圧倒的に多い
とありますが、その検索結果はリアルタイム性の話ではないですか？
そしてそれはJavaの問題ですか？

172 ：デフォルトの名無しさん：04/01/24 18:38

JavaはGCが有るからこそ、初心者向きだと思うぞ。
火星探査車の制御に使えないのもたしかだが。

173 ：デフォルトの名無しさん：04/01/24 18:39

Javaだけの問題では無いな。
C#とか、インタプリタ系全般の問題だな。

174 ：デフォルトの名無しさん：04/01/24 18:41

インタプリタかどうかも関係ない。

175 ：デフォルトの名無しさん：04/01/24 18:42

>>169
火星探査通の俺から言わせてもらえば今、火星探査通の間での最新流行はやっぱり、
FORTRAN。
これだね。

しかしミスタイプすると打ち上げに失敗する危険も伴う、諸刃の剣。
素人にはお薦め出来ない。

176 ：デフォルトの名無しさん：04/01/24 18:49

>>174
そう熱くなるな。
気を静めてGCについて勉強して来い。

177 ：デフォルトの名無しさん：04/01/24 18:51

FOR I=1.10
だったっけ？

178 ：初心者：04/01/24 19:08

火星探索をするならFORTRAN、スレタイ読めなくなりたいならPerl
どちらでもないならJava、と言うことですね。

179 ：デフォルトの名無しさん：04/01/24 19:16

冷静にこのスレを眺めているとやはりPerlだね。
言語としてもJavaより格段に優れているし初心者も手が出しやすい。
今後は超高級言語の時代だよ。

180 ：デフォルトの名無しさん：04/01/24 19:16

>>108-109
genericsがあっても実現不可。Javaって使えねー。(ｷﾞｬﾊ

181 ：デフォルトの名無しさん：04/01/24 19:19

変なのが湧いてるなあ。

182 ：デフォルトの名無しさん：04/01/24 19:20

.NETなら1行で実現。

let hoge n = fun i -> n + i

183 ：デフォルトの名無しさん：04/01/24 19:23

F# ?

JVM でも色んな言語使えるからなぁ。

184 ：デフォルトの名無しさん：04/01/24 19:25

というか、>>182は実現できてないぞ。

185 ：デフォルトの名無しさん：04/01/24 19:26

スレタイ読めないレス、根拠なくPerlとかいってるレス。
Perl使いってなんだろうな。。。
>>108を意味も分からず勘違いして喜んでるんだろうな。。。

186 ：デフォルトの名無しさん：04/01/24 19:30

結局、まともに考えてるのは>>21だけの罠

187 ：デフォルトの名無しさん：04/01/24 19:32

言語スレで.NETかよ。つーか、>>183も無理するな。
そして>>182は、おまえのとこの新人には、プログラム演習としてMSILを教えろよ。

188 ：デフォルトの名無しさん：04/01/24 19:34

>>187
学生っぽいな。

189 ：デフォルトの名無しさん：04/01/24 19:49

>>186
ｼﾞｻｸ（・∀・）ｼﾞｴﾝ！

190 ：デフォルトの名無しさん：04/01/24 19:50

ほんとにプログラミングについて何も知らない、
これから勉強し始める人は、まずこれなんか読めばよい。
土日で読める。
http://www.amazon.co.jp/exec/obidos/ASIN/4774113212/250-9895996-1947414

191 ：デフォルトの名無しさん：04/01/24 19:59

>>182
アフォですか？

192 ：デフォルトの名無しさん：04/01/24 20:03

>>108はJavaやC#には荷が重いよ。
もうプログラム言語は次のステップへ向かっている。

193 ：デフォルトの名無しさん：04/01/24 20:03

CとC++ならどっちが良い？

194 ：デフォルトの名無しさん：04/01/24 20:07

>>193
そんなの今更覚えてどうするの。
perlやっておけ。

195 ：デフォルトの名無しさん：04/01/24 20:13

なぁ、>108って内部にnを保持するクラス作れば良いだけちゃうんの？
馬鹿馬鹿しい比較だなぁ
クラスの方が後々いろいろ付け加えられるしクロージャでその場しのぎするより全然良いと思うが。
関数型崇拝者はそろって頭が悪いと言うことか。

196 ：デフォルトの名無しさん：04/01/24 20:13

あ、そうですか
ありがとうございます

197 ：デフォルトの名無しさん：04/01/24 20:15

perl厨ウザ！！

198 ：デフォルトの名無しさん：04/01/24 20:17

>>195
では実際につくってみてください

199 ：デフォルトの名無しさん：04/01/24 20:17

>>108
その頭の悪い文章はここで完璧に論破されているね。
ttp://www.shiro.dreamhost.com/scheme/trans/IsPythonLisp-j.html

だいたいソース量が開発の長さという論法が既に終わっている。
実際の開発行程からすればコーディングに費やす時間などたかが知れている。
ホットスポット以外を最適化したところで得られるものなど極僅か。
それをLispのソース量はCの1/20だから（これもまぁ嘘だが）Lispで3ヶ月かかったものは
Cだと5年かかると言う発言は低脳の極み。

例題のアキュムレータも呆れる。
これもソースが短い方が良いらしい。
単純化＝ソース量だと本気で思っているのだろうか。
これも、上記のリンク先が論破しているがこの場合、圧倒的にオブジェクトの方に部がある。
馬鹿も休み休み言えという感じだ。

でも、一番信じられないのはこんなアレなヤツが雑誌で記事を書いていたりするLispの第一人者だと言うこと。
冗談だろ？（藁

200 ：デフォルトの名無しさん：04/01/24 20:18

今の時代C#だろ。

201 ：デフォルトの名無しさん：04/01/24 20:19

>>198
オレが作るまでもなくここで同じ事が書かれているな
http://www.shiro.dreamhost.com/scheme/trans/IsPythonLisp-j.html

202 ：デフォルトの名無しさん：04/01/24 20:19

>>199とかぶったか。

203 ：デフォルトの名無しさん：04/01/24 20:23

ttp://www.shiro.dreamhost.com/scheme/trans/IsPythonLisp-j.html

> ・オブジェクトは、値のインクリメントと値を返すのとに別々のメソッドを持てる。
> 　言い替えれば、オブジェクトの解はより拡張性が高い。
> ・オブジェクトは、値を減らしたりリセットしたりするといった、他のメソッドも持てる。
> 　言い替えれば、オブジェクトの解はより拡張性が高い。
> ・オブジェクトは、(関数的、及びオブジェクト指向的の両方の意味において)
> 　プログラミングスタイルを破らない。すなわち、関数は入力引数として渡された
> 　オブジェクト以外のオブジェクトを書き換えない。実際、「純粋な」関数型言語は
> 　書き換えをデータ変換として明示することを要求することにより、このスタイルを
> 　強制している。Pythonはもうすこし自由だが、それでもクローズした変数を書き
> 　換えるのは良いことだとは考えていない。このような副作用は維持の難しいコード
> 　を生み出す。言い替えれば、問題の「もの」をオブジェクトにすることは、状態が
> 　保持され、書き換えが起こる範囲を明示的に示しているということだ。

204 ：デフォルトの名無しさん：04/01/24 20:27

>>182
これはF#じゃコンパイルできんだろ。

class hoge n_init =
　object
　　val mutable n = n_init
　　method add i = n <- n + i; n
　end

let foo n =
　let o = new hoge n in o#add

205 ：デフォルトの名無しさん：04/01/24 20:28

うーん、リンク先見る限りどう考えてもオブジェクトに軍配が上がるな。

206 ：デフォルトの名無しさん：04/01/24 20:30

つまり、関数型とオブジェクトのハイブリッドなOCamlが最強ということで。

207 ：デフォルトの名無しさん：04/01/24 20:32

>>206
>>12

208 ：デフォルトの名無しさん：04/01/24 20:34

スレタイを死ぬまで読み返してこい

209 ：デフォルトの名無しさん：04/01/24 20:37

>>190
実際にプログラム始める前に頭の準備をしておくという意味ではいい鴨ね。
だだし、目次を見た限り手続きのホントに初歩の初歩しか書いてない。
しかも悪いことに、これだけで大抵のことは出来てしまう。
これで初歩の初歩を、基礎と勘違いしてしまったら、
DQNプログラマのできあがりだ。
最終章の内容が鍵だな。

210 ：デフォルトの名無しさん：04/01/24 20:37

>>199
そこ見ると Python 使いたくなるな。

Pythonは30年にわたる動的オブジェクト指向プログラミング言語(Smalltalk, Lisp)の経験と、30年にわたる簡単に使える言語(Smalltalk, BASIC, ABC)と、 30年にわたる進んだハッカーの言語 (C, Lisp) の経験とに基づいて作られている。

211 ：デフォルトの名無しさん：04/01/24 20:39

Pythonｶｯﾁｮｴｰ

212 ：デフォルトの名無しさん：04/01/24 20:51

>>210
Python が Smalltalk や Lisp の経験に基づいているなんて本気にしちゃダメだぜ。

213 ：デフォルトの名無しさん：04/01/24 21:02

Smalltalkって良く話題に上がるけどプログラマ見たことないな。
XPがSmalltalkのコミュニティーから発生したとか聞いたことはあるけど。
あと、GoFの人間もSmalltalk使いなんだっけ？

214 ：デフォルトの名無しさん：04/01/24 21:12

>>199
見事な反論だな。
目先のソースの短さにとらわれて、揚々とリンクを張った108は今頃、顔を真っ赤にしていると思われｗ

215 ：デフォルトの名無しさん：04/01/24 21:12

たった３０年かよ。
俺のじいちゃんは６０年前にJavaで闘ってたぞ。

216 ：デフォルトの名無しさん：04/01/24 21:13

>>215
でも負けたんだよね……

217 ：デフォルトの名無しさん：04/01/24 21:16

>>212
なんで？理由は？

218 ：デフォルトの名無しさん：04/01/24 21:23

ttp://www.shiro.dreamhost.com/scheme/trans/icadmore-j.html

>外側のスコープの変数の値を変更できないとか、 lambdaの中に一つ以上の式を書けない
>とかいうことは、言語としてのPythonをどんなふうにより良くしているんだ? 式と文を
>区別することで、いったいどんな得があるんだ?

純粋オブジェクト指向の Smalltalk では実現出来てる訳だし、より小さいレベルでの
抽象化が困難っていう指摘はあってると思うな。

219 ：デフォルトの名無しさん：04/01/24 21:33

>>108をみてJava駄目だ、>>199をみてPythonﾏﾝｾｰとか逝ってる奴は、
二つ上のディレクトリをみて、黒い水鳥を思い返して、
自分という人間を見つめ直せ。（Perl厨はもうどうでもいいよ）

220 ：デフォルトの名無しさん：04/01/24 21:36

オブジェクトでの実装に対しては逃げまくっているな。
正直みっともない。

それにスコープを制限することの利点は言わずもかなだろうに。
この親父駄目だな。
それにたいして、Paul Prescod は紳士だ。

221 ：デフォルトの名無しさん：04/01/24 21:37

>>220は>>218のリンク先ね

222 ：デフォルトの名無しさん：04/01/24 21:38

結局、スレタイには初心者って書いてあるのに、
初心者にはわからないような話になるんだね・・・

223 ：デフォルトの名無しさん：04/01/24 21:40

Paul Graham 厨臭いなｗ

224 ：デフォルトの名無しさん：04/01/24 21:48

クロージャにはプログラムをより一層バグが起こりやすい複雑なものにしてしまう一面もある。
Paul Graham は判っていて言っているのかねぇ
型や制限の強い言語、弱い言語はどちらかが上と言うわけでもあるまいに。

225 ：デフォルトの名無しさん：04/01/24 21:52

>>218
クロージャの問題点を書いているのにまったく読んでないで返信してるな。
頭悪すぎ。

226 ：デフォルトの名無しさん：04/01/24 21:55

Paul Graham age

227 ：デフォルトの名無しさん：04/01/24 21:55

再利用なんて現実にはしてないくせに詭弁を言ってる厨がいるな。

228 ：デフォルトの名無しさん：04/01/24 21:57

>>227
オブジェクト指向のキモは再利用ではありません。
そんなこと言っていたらXPなんてやってられないでしょ？:-)

229 ：デフォルトの名無しさん：04/01/24 21:59

>>227
どこに再利用なんてでてきた？

つーか今時オブジェクト指向の利点＝再利用だと思っているヤツが居るのかｗ

230 ：デフォルトの名無しさん：04/01/24 21:59

プログラミングなんて現実にはしてないくせに詭弁を言ってる厨がいるな。

231 ：デフォルトの名無しさん：04/01/24 22:03

>>224
Paul Grahamの上げた例の４つの言語はみんな型付の弱い言語だね。

232 ：デフォルトの名無しさん：04/01/24 22:12

ま Ruby が最強って事でファイナルアンサーだろ。

233 ：デフォルトの名無しさん：04/01/24 22:17

>>232
最強の精神異常

234 ：Guido：04/01/24 22:19

こういう厨が涌くから lambda なんて入れたくなかったんだよ。

235 ：デフォルトの名無しさん：04/01/24 22:27

>>209
続編がこれになるんですよ。
http://www.amazon.co.jp/exec/obidos/ASIN/4774117315/qid%3D1074950471/250-9895996-1947414#product-details

基礎の基礎では、ほんとに基本的な考え方の説明だけだったですよ。
プログラムの処理の流れや、
変数や配列や構造体やポインタがどういうものなのかとか、
そういう説明ね。情報はメモリに格納されて、とか。
続編で、Cでのプログラミングを具体例として
実践させつつ教える、みたいな。

236 ：デフォルトの名無しさん：04/01/24 22:28

http://merd.net/pixel/language-study/syntax-across-languages/Fnctn.html#FnctnnnmsFnct

lambda なんて普通にあって然るべき機能でしょ。
Python のは実装がイケてないらしいけど。

237 ：デフォルトの名無しさん：04/01/24 22:34

低学歴でも使える言語は駄目だ。レベルが低すぎる。

238 ：デフォルトの名無しさん：04/01/24 22:40

オブジェクト指向＞＞＞関数型なら純粋なオブジェクト指向の Ruby ﾏﾝｾｰ！他はゴミ。

239 ：デフォルトの名無しさん：04/01/24 22:40

>>237
高卒派遣専用言語のJavaとかな。www

240 ：デフォルトの名無しさん：04/01/24 22:55

>>236
微妙に話が違うことに気づいてない？

241 ：デフォルトの名無しさん：04/01/24 22:57

>>236
あまり実務に使われていないマイナー言語勢揃いだなｗ
ある程度規制が働かないと信頼性の高いプログラムは組めないと言うことか。

242 ：デフォルトの名無しさん：04/01/24 22:57

OO馬鹿は状態管理地獄の恐ろしさを分かっていない。
時代は関数型だということに気付け。

243 ：デフォルトの名無しさん：04/01/24 22:59

中途半端に関数型言語をかじっただけの奴って何で生きてるの？

244 ：デフォルトの名無しさん：04/01/24 22:59

意味不明な質問ですね

245 ：デフォルトの名無しさん：04/01/24 23:00

>>242
＞OO馬鹿は状態管理地獄の恐ろしさを分かっていない。
ﾌﾟｯ

246 ：デフォルトの名無しさん：04/01/24 23:02

そもそも>>108が何言ってるか全然分からないんですが・・・

247 ：デフォルトの名無しさん：04/01/24 23:02

関数型なんかで作ったら、読みづらいはスコープ入り乱れだわで保守性かなりﾏｽﾞｰになりそう。
おれは、C++とJavaでいいよ。
仕事たんまりあるし。

248 ：デフォルトの名無しさん：04/01/24 23:03

>>240
>>234 に対するレスなんだが、それでもダメかい?

>>241
あなたの周りでって事?

249 ：デフォルトの名無しさん：04/01/24 23:04

>>248
いや、れっきとした統計結果で。
ソースは自分で調べてね。
すぐ見つかると思うけど。

250 ：デフォルトの名無しさん：04/01/24 23:08

>>235
同じ事を実際にコーディングして反復するわけだな。
それは入り口がスムースになっていいと思う。
だが、それで一応プログラムが「組める」ようになっても、
そこに停滞してDQNにならぬよう、
初歩しかやってないことを自覚させる必要があるな。

251 ：デフォルトの名無しさん：04/01/24 23:09

見事な駄スレ化。もう春か？

252 ：デフォルトの名無しさん：04/01/24 23:10

>>241
「マイナー言語」などとごまかさず、
「厨の自分は知らない言語」と正しく言え。

253 ：デフォルトの名無しさん：04/01/24 23:14

お前ら全員過労死で氏ね

254 ：デフォルトの名無しさん：04/01/24 23:17

>>252
うん、知らない。
だって覚える必要ないしー。

255 ：デフォルトの名無しさん：04/01/24 23:22

男はセックスのやり方だけ知ってればいい

256 ：デフォルトの名無しさん：04/01/24 23:24

とりあえず、スレタイだけでも読んでくれませんかね？

257 ：デフォルトの名無しさん：04/01/24 23:25

プログラム言語以前に高校レベルの数学ぐらいやっとけや。

258 ：デフォルトの名無しさん：04/01/24 23:33

SQLでFA。

259 ：デフォルトの名無しさん：04/01/24 23:35

英語を覚えておけば何でもできる。

260 ：デフォルトの名無しさん：04/01/24 23:37

>>259
んなこたーない

261 ：デフォルトの名無しさん：04/01/24 23:54

OCamlとHaskellどっちがいいですか？

262 ：デフォルトの名無しさん：04/01/25 00:02

>>261
単に関数型を学びたいのか、多少は現実的なアプリを書きたいのかによる。

263 ：デフォルトの名無しさん：04/01/25 00:04

両方。
OCamlは名前がかっこいいけど、Haskellの方が純粋というのにも惹かれる。

264 ：デフォルトの名無しさん：04/01/25 00:12

Ocamlの方が純粋なんじゃないの？

265 ：デフォルトの名無しさん：04/01/25 00:14

>>252
使えるものもあるし、使えないものもある。
しかし、マイナー言語ってのはそのとおりだろ？
ちゃんとプログラマー分布見たか？ｗ

>>254
おいおい、オレを騙るなよｗ

266 ：デフォルトの名無しさん：04/01/25 00:17

Haskell は挫折した。副作用禁止は辛すぎ。和文ドキュメントも少ないし。
誰かモナド全開の厨房向けチュートリアル作ってくれないかなぁ。

OCaml は、OCaml やるなら Common Lisp で良いやという気分になって
こっちも挫折。何か小汚い言語と言う印象。

267 ：254：04/01/25 00:30

>>265
別に騙ってないけどー ?
一般的な意見だしー。

268 ：デフォルトの名無しさん：04/01/25 00:41

>>267
自分のDQNさを一般化しないでください。

269 ：デフォルトの名無しさん：04/01/25 01:34

>>264
Ocamlは純粋ではない。だけど中途半端ゆえの簡単さと速度があるみたいだね。

>>266
副作用に頼るようなプログラムしか書けないのでは関数型をやる意味が無いよ。
I/O以外はモナド使わずに書けるようにならないと。
実際Haskellの入門書である"The Craft of Functional Programming"
ではモナド使わないし(IOモナドは少しだけ触れる)。
入門のレベルではモナドはいらない。むしろ使わない方がいい。
# その後挫折しないひとはmonad wizardryに感動してはまるかも:-)
# HakellはメーリングリストとかUSENETみてても使える人はみな
# 熱烈なファンになってるように見えるね。

270 ：デフォルトの名無しさん：04/01/25 01:47

CとかC++、Javaとかでやってきた人間が関数型をやると、いろいろ面白いと思うけど、
関数型からはいるというのはどんなもんなんだろね？

271 ：デフォルトの名無しさん：04/01/25 01:58

結局は言語ヲタがスレを台無しにしたか。

初心者は最も使われてるOSの最も使われてる言語を使えばいい。
よってVB。

272 ：デフォルトの名無しさん：04/01/25 02:05

C#→Java→C++→Ｃ→アセンブラ

273 ：デフォルトの名無しさん：04/01/25 02:15

すべてはPerl厨が悪い。

274 ：デフォルトの名無しさん：04/01/25 02:18

>>269
>副作用に頼るようなプログラムしか書けない

そういう訳じゃないけど、状態遷移を副作用無しで奇麗に書くのって面倒だよね。
もっと別のところに労力を割きたいのに。

275 ：デフォルトの名無しさん：04/01/25 02:39

>>274
本当に状態(副作用が無ければ状態など無い)という形でモデル化せざるを得ないのか？
の答えがYesなら、モナドが便利だね。

しかしプログラミング初心者はそんなプログラムから始めないよ。
例え命令型言語の入門書であっても、あるのは状態の無い例ばかり。
# OOPの入門だと、必要なくても状態のかたまりのオブジェクトで
# モデル化するからちょっと別だが。

276 ：デフォルトの名無しさん：04/01/25 02:40

ここでHSPと言ってみるテスト

277 ：デフォルトの名無しさん：04/01/25 03:00

>>275
>しかしプログラミング初心者はそんなプログラムから始めないよ。

少なくとも入出力は満載だと思うけど。コンソール出力とか、キー入力、
ファイル入出力、他にも時間取得とか乱数生成とか。入出力無くしては
Hello World も書けない。逆に初心者はフィボナッチ数とか興味ないで
しょう。

結局モナド使うんだから、モナドの詳説が欲しいのは自然かなと思う。
いきなりモナドから解説するのはプライドが許さないんだろうけど、
ばっさり切り捨てるのもバランス悪いよね。

278 ：デフォルトの名無しさん：04/01/25 03:06

ちょっと愚痴っぽくなってしまったな。
Lisp で括弧ウゼーとか、OOP でクラスうぜーって言ってるみたいで虚しくなってきた。

279 ：デフォルトの名無しさん：04/01/25 03:32

>>277
どれも状態遷移なんか陽にはないでしょう。>>269でも書いたが、
IOモナドのものすごく基本的な使いかたを知っていれば十分で
それは全然難しくない。

入門書レベルを終えた後にモナドで悩むというのはありがちだがね。

# しかし乱数はHaskellでは普通無限リスト(かCPS)で扱うのであって、
# モナドは使わない(Stateにgeneratorをいれると便利なこともあるが)。
# 君は関数型言語の基礎ができてないのではないか？
# 個人あてのスレ違いレスになってしまったのでこれにて。
# モナドを理解したいのならWadlerやJonesの論文を読むといいよ。

280 ：デフォルトの名無しさん：04/01/25 03:42

言語をマスターするのに論文に行かねばならんというのは、
やはり実用言語になってないアカ言語といわれても仕方ないね。
現状を考えれば、やはり初心者はJavaかC#ですな。

281 ：デフォルトの名無しさん：04/01/25 03:51

Haskell やるくらいなら Smalltalk やるよ

282 ：デフォルトの名無しさん：04/01/25 03:51

>>280
高度なレベルの本出せるほどメジャーになってないからなぁ。
メジャーな言語以外は実用言語でないってのは違うだろ。

283 ：デフォルトの名無しさん：04/01/25 03:54

馬鹿はJava、賢い人はperl
馬鹿にはperlは読めない

284 ：デフォルトの名無しさん：04/01/25 03:54

>>279
お前、言い争っている相手とモナド、モナド連発して言っているがここが初心者スレだって判っている？
虚栄心を満足させたいだけじゃなかったらそのモナドとは何かを判るように説明して、初心者にとって
どういう位置にあるのかを説明しろ。

まぁ、ただのしったかだろうが。

285 ：デフォルトの名無しさん：04/01/25 03:58

だからHSPだって。

286 ：デフォルトの名無しさん：04/01/25 03:59

あれ、ここって雑談スレじゃなかったの？

287 ：　：04/01/25 04:01

こういう議論は結論が出るわけないから雑談スレでよろしい

288 ：デフォルトの名無しさん：04/01/25 04:01

わからない相手に専門用語使いまくって説明するイタいヲタって多いよね。
秋葉の喫茶店でちょっとしたパソコンの部品を買いに来たと思われる女の子に
メッチャマニアックなことを言って困らせている場面を何回か見たことがある。
男の方は全然そんなこと気にしてないのｗ
女の子が可哀想だったよ。

289 ：デフォルトの名無しさん：04/01/25 04:03

ここは初心者スレだとかスレタイ読めとか言ってるやつの方が
逆に目障りに見えてくる今日このごろ。

290 ：デフォルトの名無しさん：04/01/25 04:03

>>284
知らないんだから答えられるわけないだろ

291 ：279：04/01/25 04:21

>>284
おれは「モナド」の理解は初心者には必要ない、
IOモナドの基本的な使いかたしかいらない、と何度も主張してるんだが…
文章が読めませんか？
繰り返しますが、初心者に取って、モナドは基本的には不要だという立場です。

おれにわからんことを書き込むな、ということであれば、
そういう気持ちをもつタイプの人がいることは知っていますが。

ちょっと説明すると、モナドは3つの演算をもつクラスです。
それだけなのでいろんな使い道があり便利で、
関数型言語には存在しない「状態」を表現するのにもつかわれるものです。
# 現実のプログラムではどうしても状態をあつかう必要が生じることがあります。
しかし、その3つの演算が定められているだけなので、
非常に抽象的で、理解するのが難しいものです。
# 数学の「群」の定義だけきいてもなんのことやらわからないのとおなじです。
実用的には、いくつかの、State, Maybe, Listといったモナドの例を知って、
くみあわせてつかえるようになることが必要かつ十分だとおもいます。

292 ：デフォルトの名無しさん：04/01/25 04:24

>>291
Perl厨を相手にする必要はありません。
彼らは、手早く書ければそれでOKなので、
スレタイもレスも読む習慣がありません。

293 ：デフォルトの名無しさん：04/01/25 04:27

>>292
ｼﾞｴﾝ乙

294 ：279：04/01/25 04:28

>>291
3つの演算、というのは不正確だったので訂正。
return, >>= という2つの演算をもち、それが3つの性質をみたす、にしてください。

295 ：デフォルトの名無しさん：04/01/25 04:38

さっぱり要領の得ない説明だな

296 ：From:279 ：04/01/25 04:46

>>295
悪いね。monad law 3つあげて、Stateはこう、Maybe、Listはこう、
って法則を満たしてるのを証明したほうがよかったのかなぁ？
# 長くなるし面倒だから嫌だけど。

「群」って何？ってきかれたら、群の定義説明して、
行列とかの具体例あげるしかないのと一緒なんだよ。
# モナドは群よりもっと抽象的

297 ：デフォルトの名無しさん：04/01/25 05:26

>>291
個人的に(参考になる:+1)をあげたい。

298 ：　：04/01/25 05:42

Java信者ってJava以外は決して認めないよな。

299 ：デフォルトの名無しさん：04/01/25 05:52

↑トートロジーに気付かない上に、勝手な思い込みを撒き散らす馬鹿。

300 ：デフォルトの名無しさん：04/01/25 07:06

結局のところ、Excel で VBA という事でFA?

301 ：デフォルトの名無しさん：04/01/25 09:56

Perlから見るとJavaはクソなんだけど
いろんな意見があるんだな。
トーシロ以外には分かってるようだけど

302 ：デフォルトの名無しさん：04/01/25 10:10

Perl以外から見たらPerlはクソ

303 ：デフォルトの名無しさん：04/01/25 11:22

awk

304 ：デフォルトの名無しさん：04/01/25 11:48

結局Javaに逃げるのって
頭が悪いからデバックもまともに出来ないし
ライブラリがないと何も出来ないし
ソースが簡単でないと保守も出来ないからなんだよ。

305 ：デフォルトの名無しさん：04/01/25 11:53

>>304
頭が悪い奴でも使える Java ってすばらしい言語だと言ってるわけだな。

306 ：デフォルトの名無しさん：04/01/25 11:57

中卒の俺でもマスターできたJAVAマンセー

307 ：デフォルトの名無しさん：04/01/25 12:01

JAVA とか書いてるやつはバカ

308 ：デフォルトの名無しさん：04/01/25 12:35

Haskell を勉強するには、頭の柔らかい Haskeller が周りに居る必要があるね。

309 ：デフォルトの名無しさん：04/01/25 13:10

Lisp言語とアセンブリ言語をやっとけ。
それなりに理解できたら、次はC言語だな。

310 ：デフォルトの名無しさん：04/01/25 13:47

まずCに決まってるだろ。
その後UNIXを深く学び、効率的な作業をする為に
Perlを勉強する。
そうすれば立派なUNIXハッカーになれる。

311 ：デフォルトの名無しさん：04/01/25 13:48

どの言語がいいか悩む前にＯＳの基礎的な使い方、
とりわけ、コマンドラインの使い方とテキストエディタの
使い方ぐらい覚えとけこんちくしょうめ！

312 ：デフォルトの名無しさん：04/01/25 13:49

まずC#に決まってるだろ。
その後windowsを深く学び、効率的な作業をする為に
VBAを勉強する。
そうすれば立派なwindowsハッカーになれる。

313 ：デフォルトの名無しさん：04/01/25 13:50

ＨＳＰだな

314 ：：04/01/25 13:53

まずHSPに決まってるだろ。
その後ひまわりを深く学び、効率的な作業をする為に
officeを勉強する。
そうすれば立派なHSPハッカーになれる。

315 ：デフォルトの名無しさん：04/01/25 13:57

tabキーの使い方が解ったとき、
折れの中で何かが変わったような気がした

316 ：デフォルトの名無しさん：04/01/25 14:13

ﾏｼﾞﾚｽすると、
どの言語がいいか悩む前に技術英語は読めるようになっとけ！！

317 ：デフォルトの名無しさん：04/01/25 14:19

初心者はプログラム以前に自分の普段の行動を日本語で箇条書きにしてみるといいと思う。
そしてそれを読んだだけで他人が逃げることに成功できるかどうかを考る。

初心者が習うべきは「正しい日本語」これがないと仕事にならない。

318 ：デフォルトの名無しさん：04/01/25 14:21

>>317
お前の日本語は意味不明ｗ
まずはお前が自覚するこった

319 ：デフォルトの名無しさん：04/01/25 14:21

擬似コード作ってみるとか。

320 ：デフォルトの名無しさん：04/01/25 14:22

>>317
一行抜けてたので訂正。

初心者はプログラム以前に自分の普段の行動を日本語で箇条書きにしてみるといいと思う。
おれは新人に「森でワニに出会ったときの逃げ方」を書かせてみたりする。
そしてそれを読んだだけで他人が逃げることに成功できるかどうかを考る。

初心者が習うべきは「正しい日本語」これがないと仕事にならない。

321 ：デフォルトの名無しさん：04/01/25 14:25

>>320
それだけじゃ説得力はないな。
まずは君が「森でワニに出会ったときの逃げ方」
を書く事だ。

322 ：デフォルトの名無しさん：04/01/25 14:27

>>321
意味不明なつっかかりはご遠慮下さい。
>>320
そんな当たり前のことを得意げに語らないでください。

323 ：デフォルトの名無しさん：04/01/25 14:31

どの言語がいいですかと聞くような
目的もない奴はどうせ続かんし上手くなれっこない。

324 ：デフォルトの名無しさん：04/01/25 14:48

このスレには俺以外初心者はいないみたいだけど、おまえら初心者の頃はどの言語から学び始めたの？
それによる結果は？

325 ：デフォルトの名無しさん：04/01/25 15:02

>>324
BASIC → C → scheme → Java → O'Caml

326 ：デフォルトの名無しさん：04/01/25 15:09

>>324
Fortran ⇒ Assembler ⇒ Basic ⇒ COBOL ⇒ C ⇒ Lisp ⇒ RPG ⇒ C++
一応プロ。

327 ：デフォルトの名無しさん：04/01/25 15:20

>>317
>>仕事にならない。
そういう趣旨のスレでもない気がする。

328 ：デフォルトの名無しさん：04/01/25 15:24

>>324
Java→C++→C→Perl

329 ：デフォルトの名無しさん：04/01/25 15:34

Family BASIC → N88 BASIC → Quick BASIC → VisualBasic → VB.NET

330 ：デフォルトの名無しさん：04/01/25 15:42

ひまわり→TTSNEO→HSP→VBA→VB

331 ：デフォルトの名無しさん：04/01/25 16:18

童貞→BASIC→BASIC→(各機種のBASICを渡り歩き……)→アセンブラ→C→QuickBASIC
→VB→C++→Delphi→Perl→PHP→Java→妖精

332 ：妖精まで後４年：04/01/25 16:22

VB→ﾃﾗﾀｰﾑ→Java→C→Perl→C++　

333 ：デフォルトの名無しさん：04/01/25 16:25

ActionScript
→C#(ｻｯﾊﾟﾘﾜｶﾗﾝ)
→C(動的割り当てを学び参照の想像が付く)
→C++(教養程度にしかやってなかったり・・・)
→C#(ｳﾏｰ)
ちなみに、ホビープログラマーです。

334 ：デフォルトの名無しさん：04/01/25 16:26

BrainF（略

335 ：デフォルトの名無しさん：04/01/25 16:40

WhiteS（ｒｙ

336 ：デフォルトの名無しさん：04/01/25 16:48

C→C++→Java→C++

337 ：デフォルトの名無しさん：04/01/25 17:00

今プログラム始めたばかりの初心者です。
近所の本屋で書籍が売っていて、
無料でコンパイラが手に入りやすいという理由で
JavaとCを併用して勉強しています。
意味あるのかな？

338 ：デフォルトの名無しさん：04/01/25 17:04

>>337
Javaは全く意味ない。
UNIXでもWindowsでも中途半端にしか動かない。
しかもJavaの全権握ってる$unが今年中に倒産しそう。

339 ：デフォルトの名無しさん：04/01/25 17:06

>>338
あまりにもバカ

340 ：デフォルトの名無しさん：04/01/25 17:08

このスレは初心者のためのスレではありません。

非初心者が集まり初心者が習うといい言語をあーでもないこーでもないと議論
する雑談スレです。

読んでもためにならないので好きな言語を勝手に覚えてださい。

341 ：デフォルトの名無しさん：04/01/25 17:09

>>339
漏れもそう思う。
amazon.comは何で開発されて動いているのかと小一時間。

342 ：デフォルトの名無しさん：04/01/25 17:13

へえ、アマゾンってLISPじゃなかったの？

343 ：デフォルトの名無しさん：04/01/25 17:18

WebProgやるならPHPしか考えられねぇ…。

344 ：デフォルトの名無しさん：04/01/25 17:18

>>342
そりゃ、Yahoo shop だろがぁ？

345 ：デフォルトの名無しさん：04/01/25 17:19

>>342
アマゾンは J2EE

346 ：デフォルトの名無しさん：04/01/25 17:25

メインで使ってた言語の変遷。
VB -> VB, Perl -> Perl, C -> Ruby, C -> Ruby, C, ObjectPascal -> Ruby, C++, ObjectPascal

途中で齧った言語
VBS, JScript, Rexx, Python, CommonLisp, PHP, AWK

この中にある言語の中では、Ruby が一番使いやすかったな。

347 ：デフォルトの名無しさん：04/01/25 17:28

初心者です。
このスレを読んでみると、どうやらPerlという言語がよさそうですが、
ゆくゆくはシューティングゲームとかを作ってみたいです。
Perlで作れますか？

348 ：デフォルトの名無しさん：04/01/25 17:33

>>347
釣れますか？

349 ：デフォルトの名無しさん：04/01/25 17:35

>>348
ええ、５分で１匹　・・・外道でしたが

350 ：デフォルトの名無しさん：04/01/25 17:36

前スレの終盤はいい議論になってたのにな。Perl厨がでてきてぐちゃぐちゃに・・・

351 ：デフォルトの名無しさん：04/01/25 17:37

352 ：デフォルトの名無しさん：04/01/25 17:48

このスレを初心者が見て得られることは、
　Perlをやると人間がだめになる、
という証左である。

353 ：デフォルトの名無しさん：04/01/25 17:56

354 ：デフォルトの名無しさん：04/01/25 17:57

355 ：デフォルトの名無しさん：04/01/25 18:04

プログラミングの勉強に取り掛かる、
という目的のためには
Cがよさそう。
とりあえず基礎だけやって、
それから好きなのやればいいじゃん。

356 ：デフォルトの名無しさん：04/01/25 18:05

超初心者なら
VB（一ヶ月）→C（三ヶ月）→Java でいいんでないの

357 ：デフォルトの名無しさん：04/01/25 18:10

初心者が最初から複数の言語やることを考慮することないよ。
Cやっとけ。

358 ：デフォルトの名無しさん：04/01/25 18:17

>>348-349
ﾜﾛﾀ

359 ：デフォルトの名無しさん：04/01/25 18:23

Cで点と錬（基礎）をつんで
その後、発（アプリケーション）に移れば良い。
発に移る場合はやりたいことを踏まえて自分に合っているものを慎重に吟味するように！
選択を誤ればメモリ（容量）の無駄使いになるよ。

360 ：デフォルトの名無しさん：04/01/25 18:30

makefile も書けないやつが C なんてやるなよ！

361 ：デフォルトの名無しさん：04/01/25 18:37

UNIXも使えないやつが C なんてやるなよ！

362 ：デフォルトの名無しさん：04/01/25 18:39

　　　　　　　　　　　　|
　　　　　　　　　-､　 |　　　　　　　　　　　,.-､
　　　　　　　 ./　 .＼|　　　　　　　　　／　ヽ
　　　　　　　/　　　;|ゝ--──-- ､._/　　　.|
　　　　　　 /,.-‐''"´ |　　　　　　　　＼　　　|
　　　　　／　　　　 | 　　　　　　　　　　ヽ､　|
　　　　/　　●　　　|　　　　　　　　　　　　ヽ|
　　　 l　　　　　　(|_人__ﾉ　　　　　● 　l　そんなエサじゃ釣られないニャー・・・・
　　　 .|　　´´　　　 |し　 /　　　　　　　　　　 |　
　　　l　　　　　　ヽ_/　　　　　　　　 ´´　 l
　　　　` ､　　　　　　　　　　　　　　　　　 /
　　　　　　`ｰ､__　　　　　　　　　　　　／
　　　　　　　　　 `'''ｰ‐‐──‐┬‐‐'''""
　　　　　　　　　　　/　　　　　　|

363 ：デフォルトの名無しさん：04/01/25 18:39

目先の就職が必要な奴はプログラミングやって労働者になれよ

364 ：デフォルトの名無しさん：04/01/25 18:42

>>359からほのかな電波臭が…。
つうか世の中GCつき静的クラスベースOOなんだから、
JavaかC#にきまってりゅ。
Cの使い道なんてこれからはカーネルのハック位だよ。

365 ：デフォルトの名無しさん：04/01/25 18:46

その通りさ。　ささ、どうぞ使い捨て労働者人生に go!

366 ：デフォルトの名無しさん：04/01/25 18:48

C#かJavaって言ってる馬鹿は作業員に志願してるようなもんだ。

367 ：デフォルトの名無しさん：04/01/25 18:52

期間限定の小さな金の為にはC#やJavaが役に立つかもしれないが、
そんな小さな金の為にUNIX文化を味わえないと言うのは可哀相な事だ。

368 ：デフォルトの名無しさん：04/01/25 18:55

>>367
藻まいは、J2EE (Java) の開発を知らないのか？
大抵は数億以上の大プロジェクトなんだが。

369 ：デフォルトの名無しさん：04/01/25 18:57

>>368
そのうちお前に入るのは時給何千円程度だろうが

370 ：デフォルトの名無しさん：04/01/25 19:00

Javaレベルだと残業の山で年収５００万行けばいいほうだな。

371 ：デフォルトの名無しさん：04/01/25 19:03

>>364
前スレにもあったけどﾊﾝﾀｰﾊﾝﾀｰていう漫画のネタ。

372 ：デフォルトの名無しさん：04/01/25 19:05

>>370
それで、お舞の年収はいくらでつか？
そして、それは初心者がおまいの使ってる言語を学べば得られるのでつか？

373 ：デフォルトの名無しさん：04/01/25 19:06

プログラマーの彼女（または彼）を作ってベッドの中で教えてもらえ。
それが語学習得の王道だろ。

374 ：デフォルトの名無しさん：04/01/25 19:07

>>367
実業の世界にUNIX文化なんて存在しません。
あぁ、遊びで？それはかってにやって下さい。

375 ：デフォルトの名無しさん：04/01/25 19:08

Javaを仕事でやってると鬱になる
プログラミングの楽しさは全くなく
一日中、只パソコンに向かってタイプするだけ

376 ：デフォルトの名無しさん：04/01/25 19:11

かといって趣味では絶対にしたくない言語
それがJava

377 ：デフォルトの名無しさん：04/01/25 19:14

このスレはアンチJavaとJava厨と perl厨が争うスレですか？

378 ：デフォルトの名無しさん：04/01/25 19:22

Java厨とPerl厨の中が悪いのはどうしてだろう・・・

379 ：デフォルトの名無しさん：04/01/25 19:33

>>378
それはね、Java厨の正体がアホアンチだからだよ

380 ：デフォルトの名無しさん：04/01/25 19:34

×Java
○(Java|Perl)

381 ：デフォルトの名無しさん：04/01/25 19:34

>>378
このスレでPerl厨が汚いうんこであるのが証明されたので、
綺麗さを重視するJava厨がタイプの手間を気にせず叩いてしまうのでしょう。

382 ：デフォルトの名無しさん：04/01/25 19:40

そもそも「この言語が初心者にいい」とか言ってるから、
本屋さんや出版社が特定言語に縛られてしまうのでは？

憂プラでなされてるOOの説明のように、
関数型言語の考え方を語ってくれる本とか読んでみたいですよ。

383 ：デフォルトの名無しさん：04/01/25 19:43

> 綺麗さを重視するJava厨

笑うところですか？

384 ：デフォルトの名無しさん：04/01/25 19:46

冗長さを重視するJava厨

385 ：デフォルトの名無しさん：04/01/25 19:48

>>384
そんなとこだな。
C#の方が手短でまだマシだな。

386 ：デフォルトの名無しさん：04/01/25 19:58

アホアンチはいつも笑わせてくれる

387 ：デフォルトの名無しさん：04/01/25 20:06

アホアンチは糞、うんこという言葉がお気に入り
アホアンチが来るとなんか空気が臭くなるからすぐに分かる。

388 ：デフォルトの名無しさん：04/01/25 20:11

M$厨や無責任なお遊びプログラマは知らんかもしれんが、
コーディングなんてことは開発のごく一部でしかないのだよ。

389 ：デフォルトの名無しさん：04/01/25 20:12

客にとって、安く開発出来るのがJavaの長所。
これまでは投資のつもりでマンパワーを掛けただ今後を考えると鬱。

390 ：デフォルトの名無しさん：04/01/25 20:13

少数の原理で一貫して書かれるということは、重要な機能なの。
Pythonだって、lambdaやっぱ(ﾟ⊿ﾟ)ｲﾗﾈ　という流れだろが。馬鹿でも出来るのは重要なんだよ。
上級者は静的型うざいとかいろいろいうかもしれんが、
単価100万×100人×１年＋保守８年のシステムを開発テスト保守できるのか？
根拠もなくできるとかいうなよ。人材確保の保障からちゃんと言えよ。
馬鹿でも出来て有用なことから初めて、上級者に向かうのは当たり前の道筋だろうが。

391 ：デフォルトの名無しさん：04/01/25 20:15

設計は客の言うとおりすればいいだけ。
契約まで必要な資料を揃えて何をしたいかを聞く訳だ
プログラマの仕事は客に言われた事を
ただタイプしていくだけだ。
実務経験のない馬鹿はこれだから困る。

392 ：デフォルトの名無しさん：04/01/25 20:18

だからプログラマの仕事のほとんどがコーディングという事になる

393 ：デフォルトの名無しさん：04/01/25 20:19

Javaでシステムが安くなるはずだったが、
客にとってはハードが高く、ソフトハウスにとっては利潤が薄くなる痛み分けだった。
その結果、勘定システムまでWinに流れ始めた。

394 ：デフォルトの名無しさん：04/01/25 20:20

コーディングと言って甘く見てはいけない。
こーどな技術だからね。

395 ：デフォルトの名無しさん：04/01/25 20:20

そのコーディングが冗長なJavaは
プログラマにとっては時間効率を考えると
非効率である事は間違いない。

396 ：デフォルトの名無しさん：04/01/25 20:26

>>391
> 設計は客の言うとおりすればいいだけ。
こういう馬鹿SEがデスマーチを量産する。氏ね。

397 ：デフォルトの名無しさん：04/01/25 20:29

>>396
基本的には客の言うとおりにするしかないだろ。
客が圧倒的に立場は高いんだから。
機能はもちろんの事、
コンパネのデザインから配置まですべて了承取って
契約しないとトラブルの元だ。

398 ：デフォルトの名無しさん：04/01/25 20:29

プログラマの仕事はテストとデバッグです。コーディングなど飾りです。
厨にはそれがわからんのです。

399 ：デフォルトの名無しさん：04/01/25 20:33

デバッグに苦労するのは厨

400 ：デフォルトの名無しさん：04/01/25 20:34

>>397
クライアントの真の望みを探り出し、実現可能性を検討して、
最適なものを提案するのがSEの仕事だ。
客の言うままPGをしばいてればいいと思ってるおまえのようなやつは、
腹を切って死ぬべきだ。また、おまえらはただ死んで終わるものではない。
全世界のPGがが地獄の火の中に投げ込む者達だ。

401 ：デフォルトの名無しさん：04/01/25 20:36

>>399
おもちゃのデバッグごっこは楽で良いね。ぷ。

402 ：デフォルトの名無しさん：04/01/25 20:36

自作自演で対立を演出するのは楽しいですか？

403 ：デフォルトの名無しさん：04/01/25 20:36

要するにだな、設計に全エネルギーの9割をつぎ込めば
コーディングとテストとデバッグなど取るに足らん工数となるはずなんだよ！

404 ：デフォルトの名無しさん：04/01/25 20:37

>>397
機能とコンパネの配置が設計？
…自明な仕事しかしてないわけだな。

405 ：デフォルトの名無しさん：04/01/25 20:38

>>403
設計者が天才ならね。

406 ：デフォルトの名無しさん：04/01/25 20:38

>>400
それで仕事が取れればそうしなさい。
仕事が取れないとPGは生活できない訳だ。
馬鹿には分かる訳ないか。

407 ：デフォルトの名無しさん：04/01/25 20:38

いいかげんにしてください

408 ：デフォルトの名無しさん：04/01/25 20:42

>>404
コンパネの配置は客との交渉の厳しさの例に出したまでだ

409 ：デフォルトの名無しさん：04/01/25 20:44

お前らは朝から晩までデバッグとコーディングだけしてろ

410 ：デフォルトの名無しさん：04/01/25 20:49

客にメリットをアピールできない>>406は、
あとで全書き直しするコードをはくPGと同レベル。

411 ：デフォルトの名無しさん：04/01/25 20:49

初心者は逃げ出しますた

412 ：デフォルトの名無しさん：04/01/25 20:49

コンパネはやはり 2L12B がいいですね。

413 ：デフォルトの名無しさん：04/01/25 20:51

> コンパネのデザインから配置まですべて了承取って
> 契約しないとトラブルの元だ。
責任をPGと客に押し付ける最悪SEの考え方の典型。

414 ：デフォルトの名無しさん：04/01/25 20:53

メグミルク

415 ：デフォルトの名無しさん：04/01/25 20:57

リピーターで無い限り、ニーズを把握する事は難しい。
よかれと思って余計な事をするのは厳につつしむべきだよ。

416 ：デフォルトの名無しさん：04/01/25 20:59

>>413
客の担当者は会社の事なんぞ本気で考えてないし
自分の保身で邪魔する社員も多いから
担当者に気に入られればイエスマンでいい。

417 ：デフォルトの名無しさん：04/01/25 21:04

対人恐怖症のPGが生活できるのも
仕事があるからですよ。

418 ：デフォルトの名無しさん：04/01/25 21:09

じゃあ、初心者はPGなんかならずにSEになれっていうことで。

419 ：デフォルトの名無しさん：04/01/25 21:10

ジャ馬鹿がファビョってるな。www

420 ：デフォルトの名無しさん：04/01/25 21:19

>>419
どの言語でもまともに仕事が出来ないアフォアンチ。

421 ：デフォルトの名無しさん：04/01/25 21:21

アホアンチがファビョってまた馬鹿スレ立ててるな。www

422 ：デフォルトの名無しさん：04/01/25 21:25

break;

423 ：デフォルトの名無しさん：04/01/25 21:31

423 goto 1

424 ：デフォルトの名無しさん：04/01/25 21:34

処世しか考えず向上心のないSEは、糞PGと一緒に死んでください。

425 ：デフォルトの名無しさん：04/01/25 21:34

exit(1);

426 ：デフォルトの名無しさん：04/01/25 21:34

そもそも、このスレ、いやこの板自体に本物の初心者がくるのかｷﾞﾓｰﾝ？

427 ：デフォルトの名無しさん：04/01/25 21:44

やる気がありゃあなんだってできるわ～～～～

428 ：デフォルトの名無しさん：04/01/25 21:51

>>426
おれは自分が初心者だとおもう。
GUIプログラミングの理屈もまだ解からない。
ある程度以上把握してる所ではCで動くCGI程度
なら具体的に裏方で何やってるのか想像できる。

429 ：デフォルトの名無しさん：04/01/25 21:53

>>428
それ初心者か？

430 ：デフォルトの名無しさん：04/01/25 21:53

本物の初心者はCGIの動きなど想像できない。

431 ：デフォルトの名無しさん：04/01/25 21:54

>>428は初級者。このスレは初級者向き。

432 ：デフォルトの名無しさん：04/01/25 22:04

ふと思った。
初級者ってどういう状態を指す言葉なんだろう？

たとえばCプログラマー。その人はソケットが解からない。
GUIはライブラリの使い方しか解からない。けれども文章を
自分の出した要求に従ったルールで自在に編集できる。
こういう人はプログラムの初心者なのか？
それともプログラムは中級で別の何かの初心者なのか？

433 ：デフォルトの名無しさん：04/01/25 22:15

forとかgotoとか文字列表示するにはー？とかままならないレベルのことじゃないの？

434 ：デフォルトの名無しさん：04/01/25 22:20

なんか、もうHSPでいいんじゃないかと思えてきた・・・

435 ：デフォルトの名無しさん：04/01/25 22:25

とりあえず、自分の意図するプログラムが書ければプログラム初級者。
同時にGUI初心者以下だろうし、ネットワーク初心者以下だろう。
逆にプログラム上級者でも、GUI初心者やネットワーク初心者はありえるだろう。
>>434 おまいはHSPスレを見てもそう思うのかと。

436 ：デフォルトの名無しさん：04/01/25 22:55

つうか、プログラミング経験によらず、
知らない分野のコードを書くときはいつでも初心者。

437 ：デフォルトの名無しさん：04/01/26 00:56

それなりの経験を積んでいれば
初めての分野でも比較的早く慣れることができる。

本当の初心者との違いはその辺かな。

438 ：デフォルトの名無しさん：04/01/26 01:01

>>437
（・∀・）ｿﾚﾀﾞ!!

439 ：デフォルトの名無しさん：04/01/26 06:34

まあ、なんだ。ＨＴＭＬでいいじゃん。

440 ：デフォルトの名無しさん：04/01/26 08:26

Javascriptでいいだろ。

441 ：デフォルトの名無しさん：04/01/26 09:18

俺の感想

勉強するのに一番金がかからないのが C。
だけど、頭が良くないと理解するのに一番時間がかかるのが C。

コードを書いてて一番楽しいのは、Ｐｅｒｌ。
だけど、他人のコードを読んでて一番イヤになるのが Perl。

他人のコードを読んでいてさほど苦にならないのは Java。
だけど、自分でコードを書いてて一番イヤになるのが Java。

442 ：デフォルトの名無しさん：04/01/26 09:51

コードを書いても、他人のコード読んでも楽しいのは Delphi言語だったな。

443 ：デフォルトの名無しさん：04/01/26 09:58

変人皿仕上げ

444 ：デフォルトの名無しさん：04/01/26 10:22

>>442
「だった。」か。
もうDelphi使ってないんだろうな

445 ：442：04/01/26 11:37

そんな事はないよ。
今は人のコード読む機会が無くなったというだけさ。

今でもプログラム書く仕事の時、一番長い間開いているのはDelphiだね。

446 ：デフォルトの名無しさん：04/01/26 11:47

Delphiってそんなにいいかな？
言語仕様は確かになかなかいいけど
メジャー言語と比べるとライブラリも貧弱だし
書籍等の情報も少ない。
ライブラリを何々さんに頼んで分けて貰うとかそういう世界でしょ？

447 ：442：04/01/26 12:05

そんなふうに感じた事はなかったよ。
ライブラリが無ければ作ればいいで育った世代だからね。

書籍が少ないって言うけど、豊富な情報が提供されてるってのは、
既に開拓された後って事でもあるしね。　まあ、そういう所で仕事す
るのもアリだと思うけど、そういう所で仕事してた奴は、皆今は別の仕事
やってるよ。

448 ：デフォルトの名無しさん：04/01/26 14:25

変人sage

449 ：デフォルトの名無しさん：04/01/26 15:02

Del厨必死だな。(藁
大人しく.NET使っとけよ。
Delphi8はVB.NETより劣るだろうけどな。(ｹﾞﾗ

450 ：デフォルトの名無しさん：04/01/26 15:04

放任主義のC
面倒見がいいJava
どっちがいい？

451 ：デフォルトの名無しさん：04/01/26 15:24

自由経済のC,Perl,Delphi
社会主義(管理)経済のJava
どっちが実質的成果が上がる?
Javaの理想主義は幸福世界を作り出せるか?

452 ：デフォルトの名無しさん：04/01/26 15:46

私Javaがいい

453 ：デフォルトの名無しさん：04/01/26 15:56

C→ヤリチン
C++→経験者
Delphi→素人童貞
perl→童貞
java→童貞

これでいいだろ。

454 ：デフォルトの名無しさん：04/01/26 20:17

C→ヤリマン
C++→経験者
Delphi→れず
perl→処女
java→処女

455 ：デフォルトの名無しさん：04/01/26 20:21

Delphi萌え

456 ：デフォルトの名無しさん：04/01/26 20:32

勘違いしてらっしゃる様ですが、
Delphiはプログラミング言語ではなくPascalプログラミングツールです。

457 ：デフォルトの名無しさん：04/01/26 20:36

>>456
最近、Delphi言語という呼び方を某自身がするようになったから
とりあえず「アリ」ということでいいんでないかい。

458 ：デフォルトの名無しさん：04/01/26 20:49

>>456
> Delphiはプログラミング言語ではなくPascalプログラミングツールです。
無知は黙ってて下さい。

459 ：デフォルトの名無しさん：04/01/26 21:30

鞭

460 ：デフォルトの名無しさん：04/01/26 21:57

Delphi でプログラミングできる言語は、ObjectivePascal で
ObjectivePascal をコンパイルできるのは Delphi だけではないのだから
Delphi を言語としてしまうのは無理があるかもー。

461 ：デフォルトの名無しさん：04/01/26 22:09

鞭打ち症

462 ：デフォルトの名無しさん：04/01/26 23:07

棒と鞭か。
卑猥なスレだな。

463 ：デフォルトの名無しさん：04/01/26 23:25

>>462
ゴルフよかまし。
なんせ「棒と玉と穴」を使う競技だからな。

464 ：デフォルトの名無しさん：04/01/26 23:30

ボーリングが卑猥かと。

465 ：デフォルトの名無しさん：04/01/26 23:32

ビリヤード（ポケット）もそうだな～

466 ：デフォルトの名無しさん：04/01/26 23:46

LISPじゃねぇか？

あれさえできれば他のどんな言語の考え方にも適応できる。

467 ：デフォルトの名無しさん：04/01/28 13:17

COBOL→子持ちおばはん
FORTRAN→オールドミス

468 ：デフォルトの名無しさん：04/01/28 21:31

PL/I → 八方美人

469 ：デフォルトの名無しさん：04/01/28 22:31

初心者にこそアセンブラをやって欲しい
せめて８０８６位は理解してください

マジ似非プログラマー増えすぎで悲しすぎる
C言語できるとか言っている奴がスタックとか知らないし・・・・
勘弁してください

470 ：デフォルトの名無しさん：04/01/28 22:35

>>469
スタックが分からないと、__cdecl や __stdcall は理解できんよなぁ～。

471 ：デフォルトの名無しさん：04/01/28 22:47

>>469
> C言語できるとか言っている奴がスタックとか知らないし・・・・

まあ、世の中にはスタックなんかないマシンでC言語使ったりしてる奴がいたりするから...。

つーても、スタックと言う用語は知ってて当然だけどな。

472 ：デフォルトの名無しさん：04/01/28 22:51

スタックがないと計算するとき困ったりしないの。
再帰とかもできるの。
おれ、スタックのこと分かってないのかも。

473 ：デフォルトの名無しさん：04/01/28 22:56

>>471
スタックの無いマシン！？
つまりスタックの無いCPUってこと？
マジ勉強不足で知らないや、教えて
俺もそのCPUで再帰とかどうやってるのか知りたい

474 ：デフォルトの名無しさん：04/01/28 23:13

>>472
IBM System36 ベースの汎用機 (要は、日立や富士通の大型計算機) はスタック (正確には、ハードウェアスタック) は付いていない。

再帰をサポートする言語を使う時は、ソフトウェアでスタックを模倣している。

だから、昔の言語 (=FORTRAN や COBOL) は、再帰を使えなかった。
また、PL/I なんかだと明示的に関数や手続きにこれは再帰で使われることを指示する必要があった。

まあ、今時こんなこと知ってても、20ヘェーも貰えないわけだが...。(藁

475 ：デフォルトの名無しさん：04/01/28 23:19

そういや昔BASICで配列とGOSUB使って再帰のプログラム作った事あるなぁ。
激しく面倒くさかった・・・

476 ：デフォルトの名無しさん：04/01/28 23:32

>>475
俺がBASICで遊んでいた頃は再帰なんて高度な考えが俺の頭になかったｗ
ほとんどGOSUB-RETURNも使っていなかったからとんでもないプログラム
だったと思う。ま、小学６年が作るプログラムなんてこんなもんさ

477 ：デフォルトの名無しさん：04/01/28 23:49

>>476
漏れもだ。ifとgotoだけでプログラムを書いてた消防時代。
人並みになるまで15年掛かったよ。。。
だから、これからやる人は、最初からちゃんとした言語を学ぶべきだ。

478 ：デフォルトの名無しさん：04/01/29 00:20

>>477
俺の場合、BASICからマシン語に移行してアセンブラへの移行が早かったので救われたよ
高１の時に買った９８にmasmとsymdebがついていたので救われたｗ

479 ：デフォルトの名無しさん：04/01/29 02:00

>>478
当時はマシン語アセンブラが偉い、という文化圏が大きかったし
漏れもその底辺にいたよ。ところで、そういうルートをたどると、
今時の流れのOOとか関数型とか動的言語とかを、「もうね、アホかと。馬鹿かと。」
と見てしまうハズレもんになったりしない？

480 ：デフォルトの名無しさん：04/01/29 03:10

俺はVB→C→WINSDK→アセンブラ→DirectX→C++
ってやって来たかなぁ・・・途中で言語じゃないも入ってるけど、
やって行く順番ちょっと間違ってるかもねｗ

アセンブラも最近は使われなくなってきたけどやっといた方がいいかもね、
レジスタとメモリのやり取りとかMMXがどうとか細かく解るし・・・
ゲーム作成してて実感したかなその辺は

基本的な事からやるならVBがいいのかなぁ
if文とかfor文とか基本構文が解りやすいし、
俺みたいなバカでも何とか理解できたわけだしｗ

481 ：480：04/01/29 03:11

すまん、ageてしまったｗ

482 ：デフォルトの名無しさん：04/01/30 00:03

日本語

483 ：デフォルトの名無しさん：04/01/30 00:20

>>482
既出過ぎ

484 ：デフォルトの名無しさん：04/01/30 00:25

N88basic->C(QuickC)->fortrun->C++->perl->verilogHDL->ruby->elisp
ってやってきた。結構いろいろあるなぁ。

文系のプログラムをやったことない人にすすめるにはどれがいいかな?
私の知人なんだが。perlでもすすめるかと思ってたが、
エクセルはできるからVBAをやるとかいってた。
って、VBAってなんだ?

485 ：デフォルトの名無しさん：04/01/30 00:37

>>484
http://e-words.jp/w/VBA.html

486 ：デフォルトの名無しさん：04/01/30 00:40

N88BASIC→C→C++

専攻は全然プログラムと関係がないんですけど、
大学で今、fortran（構造化されてないタイプ）やらされてます。
Ｃやってたので、暗黙の型指定を体が受け付けません。

487 ：デフォルトの名無しさん：04/01/30 16:45

アセンブラ→PIC C→C→javaな俺

ポインタって番地よりは簡単だな

488 ：デフォルトの名無しさん：04/01/31 01:57

何を習うべきかって職業プログラマを目指すのか、趣味でかじってみたい
だけかで全然違うと思うんだな。
前者ならJavaとか今主流の言語を習うべきだし、後者だったら、むしろ昔
ながらのBASICみたいなシンプルな言語じゃないと、敷居の高さに途中で
投げ出す人がわんさと出るだろう。

489 ：デフォルトの名無しさん：04/01/31 03:14

スミマセン。上でＮ８８－ＢＡＳＩＣってあるんですけど、これってＮＥＣの
やつ？
大昔にタモリのＦＭ－７のＦ－ＢＡＳＩＣで簡単なシューティングゲームを
作ったりしてたんですけど、敵に見つかったら追いかけられるにはどうしたら？
とか、スピードを上げるために分岐点をどう節約するかとかを考えて面白かった
なあって感じでした。
　昔のＢＡＳＩＣでゲームを作れた私大文系卒が、趣味の範囲でアルゴリズム？を
考えて楽しめ、尚且つ覚えやすくて、更に尚且つ人に聞かれて「へー」って
言われるような（笑）言語って何ですかね？
　因みにゲームとか便利系ソフトを作って見たいのと、自分のＨＰでの
小細工が目的です。

490 ：デフォルトの名無しさん：04/01/31 03:28

>>489
ゲームとか便利系ソフト、人に聞かれてへーなら、Ｃ＋＋。
自分のＨＰでの小細工なら、JavaとかJScript（見栄えとか）、
ページを管理するサーバーが対応しているなら、Perl（掲示板とか）。

491 ：デフォルトの名無しさん：04/01/31 03:36

>>490
早速にありがとうございますです。
昔、ベーマガ（ベーシックマガジン、ＢＡＳＩＣで数十行程度のゲームのプログラムが
掲載されていて、小技・思想とかを知ることができた月刊誌）って雑誌があって、
結構参考になったんですが、そういう本・雑誌って現在で言えばどんなのがありますか？
とりあえず、よく聞くＣ言語とperlので教えてください。
　あと、CってC＋、C＋＋とか聞くんですけど、違いと言うか初心者はどれを勉強すれば
いいんですかね？

492 ：デフォルトの名無しさん：04/01/31 03:40

>>491
ベーマガの説明は必要ないと思うぞ。

493 ：490：04/01/31 04:23

>491
Ｃ＋ってのは無いｗ
ＣとＣ＋＋ではプログラミングスタイルというか、データ構造に対する
考え方が少し異なる。
BASICの考え方から少しずつステップアップするなら、取り敢えずＣから。
後々Ｊａｖａも…というならＣ＋＋でオブジェクト指向の勉強してもいい。
ベーマガもなくなっちゃったし、プログラム系の雑誌と言ったら
Ｃマガジンとか勉強になるかも。

ちなみに私は、BASIC→アセンブラ→Ｃ→Ｃ＋＋→Ｊａｖａ
とステップアップ。あと、Perlとかをつまみ食い

494 ：デフォルトの名無しさん：04/01/31 04:35

> ＢＡＳＩＣで数十行程度のゲームのプログラムがＢＡＳＩＣで数十行程度のゲームのプログラムがＢＡＳＩＣで数十行程度のゲームのプログラムがＢＡＳＩＣで数十行程度のゲームのプログラムが
ファミベのプログラムでも200行はあったと思うが（w

495 ：デフォルトの名無しさん：04/01/31 04:37

あと、今時のプログラムをしたいんならBASICの知識は捨てるつもりでやれ。
言語は、C#。

496 ：デフォルトの名無しさん：04/01/31 04:42

> 何を習うべきかって職業プログラマを目指すのか、
> 趣味でかじってみたいだけかで全然違うと思うんだな。

おまえは、まともな趣味がなく、Internetがどうやって出来たかとかも
想像だにしない青色PGなんだろうな。

497 ：デフォルトの名無しさん：04/01/31 05:19

べーマガ、なつかしい。
今はもうないんだっけ?

498 ：デフォルトの名無しさん：04/01/31 05:56

>>496
デスラーの親戚ですか？

499 ：デフォルトの名無しさん：04/01/31 09:39

>>497
次の号で休刊らしいよ
20年ぶりに買うか・・・

500 ：デフォルトの名無しさん：04/01/31 10:13

BASICの知識は役に立ったな。
ループの最適化とか文字列の直接編集とか、
もとが遅いだけに効果が劇的だったからなあ。

501 ：デフォルトの名無しさん：04/01/31 13:57

494 とか見て、本当にベーマガとかMSXファンとかを知らない世代になっちゃったんだなと実感。

>>500
BASIC での文字列処理プログラムがガベージコレクタで一寸止まったりするのを見るのも風情があって良かった。
重い処理をループの外に追い出すと劇的に速度が上がったりとか、肌で感じられたよね。

502 ：デフォルトの名無しさん：04/01/31 14:26

BASICしか無かった頃がなつかしいな。
ROM-BASICは各PCメーカーによってけっこう怪しげな拡張がされてたね。
俺はF-BASICだったが、
VARPTR(VAR)でポインタを取ってPEEK,POKEするのは常套手段だった。

しょうもないテクも多かったけどね。
FOR I=0 TO 10 : NEXT I　より
FOR I=0 TO 10 : NEXT　の方が速いとか・・

503 ：デフォルトの名無しさん：04/01/31 14:45

>>499
まだあったのか!?
なつかしいな・・・休刊になったらもう二度と出ないような気もするが

504 ：デフォルトの名無しさん：04/01/31 14:59

ここは何のスレですか？

505 ：デフォルトの名無しさん：04/01/31 15:02

BASICを懐かしむスレです。

506 ：デフォルトの名無しさん：04/01/31 15:04

507 ：デフォルトの名無しさん：04/01/31 16:08

＞自分のＨＰでの小細工
が良く分からんけど、Java（アプレット）か、JavaScriptなら
Webで動くゲームが作れると思われ。

508 ：デフォルトの名無しさん：04/01/31 17:47

アセンブラでOS作りますか？

509 ：デフォルトの名無しさん：04/01/31 20:20

JavaScriptよいじゃん。
Webサイト作成についてのスレなら
JavaScriptはあんま使わないほうがいいよ、てことになるけど
プログラムの勉強始めたい人には、
勉強のとっかかりとしていいと思うよ。

510 ：デフォルトの名無しさん：04/01/31 20:34

>>509
うんうん、激しく同意。
例えばゲーム作るとして、キャラクタ動かしたりって事をどう制御するかを
考えるだけであればあんないい環境ない。結構OOっぽい事できるし。
その後でWinならC#かな。SharpDevelopでDirectX使うのはかなりラク。
MacだったらそのままXcodeでObjective-Cだろうか。
Linux界隈だとシンプルにC学ぶのが一番面白いだろうね。それだけでもソース天国。

511 ：デフォルトの名無しさん：04/02/01 00:24

いきなりML

512 ：デフォルトの名無しさん：04/02/01 00:47

Ruby

513 ：デフォルトの名無しさん：04/02/01 01:51

XML(seXtensible Markup Language)だな

514 ：デフォルトの名無しさん：04/02/01 01:56

やっぱりRuby

515 ：デフォルトの名無しさん：04/02/01 10:23

実用的なビジュアルプログラミング言語てないですかね？
エージェントシートとか日本語版が出てたらしいけど、今はなくなってるらしい。
この分野はダメポなんですかね？初心者にはイイと思うんだけど。

516 ：デフォルトの名無しさん：04/02/01 11:04

その後が続かないからな。。。

517 ：デフォルトの名無しさん：04/02/01 11:20

べつにPerl、Ruby、Pythonから選んでも
良いとは思うが、俺もJavaScriptに一票入れとく。
物を動かせるようになった後は車輪の再開発を通して、
どんな処理を行うのか考えやすいCもやってほしいな。
JAVAやC#は解かってる奴がやる言語だと思う。

でも一番のオススメは流行にのっとって織田信長だよね。

518 ：デフォルトの名無しさん：04/02/01 12:13

とかってるやつ？

519 ：デフォルトの名無しさん：04/02/01 12:32

>>515
>実用的なビジュアルプログラミング言語てないですかね？
Excel + VBA

520 ：デフォルトの名無しさん：04/02/01 12:43

　Ｃ・Ｃ++に比べると、ＢＡＳＩＣは難し過ぎて全然わかりません。

521 ：デフォルトの名無しさん：04/02/01 13:37

>>520
まず Python あたりから入っては？

今の VB とかの BASIC は(基本型含む)出来合いのオブジェクトの
仕様が過去からのしがらみでぐだぐたになっていて理解しずらいから。

Java とかは基本型とクラスベースのオブジェクトの間に一線が引いてある
ハイブリッドな言語なので二重に考える必要が出るからお勧めしない。
(C++ がわかっている人間なら絶えられないと思うし)

522 ：デフォルトの名無しさん：04/02/01 14:16

ここは相当偏ったスレですね

523 ：デフォルトの名無しさん：04/02/01 14:19

プログラマは偏ってるもんだからな。

524 ：デフォルトの名無しさん：04/02/01 16:32

>実用的なビジュアルプログラミング言語
座標や色だけを考えれば良いという点では、
BASICが直観的なビジュアルプログラミング言語だな。

525 ：デフォルトの名無しさん：04/02/01 17:05

Pythonなんてマイナーでキモい言語使うくらいだったら、俺はPerlを取るね。あるいはRuby。

526 ：デフォルトの名無しさん：04/02/01 18:56

>>525
蛇の道はヘビ～～。

527 ：デフォルトの名無しさん：04/02/01 20:19

まぁ、Rubyが妥当だろうな。

528 ：デフォルトの名無しさん：04/02/01 20:30

>>525
PythonもRubyもマイナー度で競いあえば
どっこいどっこいの結果が出るかと思われ。

529 ：デフォルトの名無しさん：04/02/01 20:40

Perlは快便補助器具。
初心者はちゃんとした言語を使うべき。

530 ：デフォルトの名無しさん：04/02/01 21:06

>>528
日本ではRubyの方がメジャーだけどね。
英語が苦にならなければPythonの方が良い。

531 ：デフォルトの名無しさん：04/02/01 22:21

根拠にいっさい触れず○○がいいというやつは○○厨。
相手にする価値なし。

532 ：デフォルトの名無しさん：04/02/01 22:58

俺の開発した「ゲッ」がいいよ。

533 ：デフォルトの名無しさん：04/02/01 23:19

>>532
たしかにあれは良い物だが初心者向けとは思えん。

534 ：デフォルトの名無しさん：04/02/01 23:25

>>532
くだらんなあ。。。そんなに言わせたいのか。このゲッ厨め。

535 ：デフォルトの名無しさん：04/02/02 00:57

結論としては

C or Javascript →　Java

で包茎？

536 ：デフォルトの名無しさん：04/02/02 02:07

>>535
P/ICE で C or IE で JScript → このままこの方向で人生歩んでいいか考え直す。

がむけてると思う。

537 ：デフォルトの名無しさん：04/02/02 13:53

>>535
Javascriptはまだ根拠・検討不足でしょ

538 ：デフォルトの名無しさん：04/02/02 16:01

>>535
Cは単品でなくて他の言語と一緒にやったほうが良いかもしれない。

539 ：デフォルトの名無しさん：04/02/02 16:06

>>538
Z80とかSC61860のアセンブリがいいね

540 ：デフォルトの名無しさん：04/02/02 17:18

>>539
その根拠は？

541 ：デフォルトの名無しさん：04/02/02 17:21

>>540
いきなりページングとか仮想メモリをやるとOSの勉強までする羽目になって大変だから。
CASLでもいいけど。

542 ：デフォルトの名無しさん：04/02/02 17:35

>>541
仮想記憶のあるOSくらいは作れないとアセンブリを勉強する意味ないだろ。
将来性から言ったらx86-64かIA-64だろうけど、
IA-64をハンドアセンブルできるのは神くらいだから非現実的だね。

543 ：デフォルトの名無しさん：04/02/02 17:38

おまいら、初心者を時代に逆行させて、
自分たちの地位の安泰をねらっていますね?

544 ：デフォルトの名無しさん：04/02/02 17:50

直接的な表現で書けて、手軽に実行できるもの、
やっぱＢＡＳＩＣがいいと思う。インタプリタの。

まずは、プログラミングとは如何なるものか？を学ぶべきで、
特定の言語に特化したコーディング能力を磨くのはその後だ。

545 ：デフォルトの名無しさん：04/02/02 17:59

ここは究極の隔離スレですね

546 ：デフォルトの名無しさん：04/02/02 18:28

>>544
そうか！だから学校教育では未だに BASIC なのか！

その手だと「十進BASIC」とかもあるから金もかからないしね。

547 ：デフォルトの名無しさん：04/02/02 18:31

x-basic

548 ：デフォルトの名無しさん：04/02/02 18:46

もうマイコンベーシックマガジンはないんだよ・・・

549 ：デフォルトの名無しさん：04/02/02 19:00

.NETマガジンをマイコンベーシック化すればいいじゃないか。

550 ：デフォルトの名無しさん：04/02/02 19:37

日曜PGパパになりたいだけなのに・・・
　　　　　　　　　　　 ∧＿∧
　　　　　∧＿∧ 　（´<_｀　）　貢物で教えてもらえば？
　　　　（　´_ゝ`）　/　　　⌒i　
　　　　／　／￣￣＼　　|　|
　　　 /　　 |'´＼:::::::::::::＼ |　|
　.＿,(__ﾆつ|　　）;;;;;;;;;;;;;;;;;)|　|＿＿＿＿
　　　　　￣＼,/_/＿_∵/ （u　⊃
http://domdomdom5.hp.infoseek.co.jp/cgi-bin/img-box/img20040131185721.jpg

551 ：デフォルトの名無しさん：04/02/02 21:27

>>550
HSP

552 ：デフォルトの名無しさん：04/02/02 21:37

>>550
全然そそられなかったので、BrainFuckを薦めとく。

553 ：デフォルトの名無しさん：04/02/02 21:46

>>550
たまにはマジレスしとくか・・・。

ひまわり。

554 ：デフォルトの名無しさん：04/02/02 21:54

日曜PGならマジでHSPオススメ

555 ：デフォルトの名無しさん：04/02/02 22:02

C#シカト気味なのねん。
MSのプッシュ具合も力入ってきたしSharpDevelopも安定してるし
お勧めだと思うけど。

556 ：デフォルトの名無しさん：04/02/02 22:04

>>555
オブジェクト指向はサンデープログラマにはきついと思ﾜﾚﾒ。
いきなりusingだのclassだのstatic voidだの出てきて理解できないコードを書かされたら引くよ。

557 ：デフォルトの名無しさん：04/02/02 22:14

ていうかサンデーグラマなら金もかからないHSPとかひまわりでいいだろ
日曜PGパパなら余計・・・
ただHSPとかで作ったものはよっぽどのものじゃない限りvectorに流さないでくれYO

558 ：デフォルトの名無しさん：04/02/02 22:38

日曜PGは妥協しないからな。
C/C++以外はお気に召さないだろう。

559 ：デフォルトの名無しさん：04/02/02 22:48

日曜PGなら最初HSPやって、物足りなくなったらDelphi
が定石？

560 ：デフォルトの名無しさん：04/02/02 22:52

>>558
そんなもんなのか？

561 ：デフォルトの名無しさん：04/02/02 22:58

納期が無いからな。

562 ：デフォルトの名無しさん：04/02/02 23:31

プログラミング歴60年のおれから言わせて貰うと、Rubyが一番。

563 ：デフォルトの名無しさん：04/02/02 23:39

>>562
終戦前か・・・そいつはすごいね、ハハハﾊﾊﾊ

564 ：デフォルトの名無しさん：04/02/02 23:41

連合軍の暗号解読でもしてたんか？

565 ：デフォルトの名無しさん：04/02/03 00:36

根拠厨ウザー

566 ：デフォルトの名無しさん：04/02/03 01:28

>>556
昔のことは忘れたので予想してみる。
名前空間が一番の曲者かもしれない。

567 ：デフォルトの名無しさん：04/02/03 01:36

>>566
クラスの概念が理解できていたら、名前空間なんてファイルフォルダと同じで難しくはないでしょう。
逆に言うと、名前空間が難しいとしてもクラスの概念とかオブジェクト指向の抽象性に起因するのでは。

568 ：デフォルトの名無しさん：04/02/03 01:40

オブジェクト指向言語から入ったけど、むしろそれが良かったと思うけどな。手触り間があって。

569 ：デフォルトの名無しさん：04/02/03 01:53

>>568
が正解。世の中OOなんだから、これが一番幸せ。
ただしよい入門書を使うことが前提。
ifよりも何よりも先にオブジェクトで説明すべし。

570 ：デフォルトの名無しさん：04/02/03 01:59

68000のアセンブラは割と素直で理解しやすいよ。
下手なBASICよりいいかもしれん。
ただ、現在では勉強できる環境がほとんどないのが
問題だが。エミュレータでも使うかね。

571 ：デフォルトの名無しさん：04/02/03 09:48

オブジェクトオブジェクト言う前に、
具体的なクラスの作り方とその挙動を事細かに書いてる本が
一冊必要な気もする。

>>570
当時のモトローラは羨望の対象だったなぁ

572 ：デフォルトの名無しさん：04/02/03 10:12

>>571
クラス設計のことかい？
それは基本が終わってからじゃないか？

573 ：デフォルトの名無しさん：04/02/03 16:50

>>572
そういうのでなくて機械よりな挙動の事かとおもわれ。
インスタンスが造られたらメモリの中に～みたいな。

574 ：デフォルトの名無しさん：04/02/03 17:42

アセンブラとかハードに近い知識は重要かつ強力だが、最初にやるべきことではない。
実装と概念モデルの別のレベルの思考ができない椰子が出来上がる危険大。

575 ：デフォルトの名無しさん：04/02/03 20:30

>>574
こういった疑問がいの１番に出てくる場合もある。
・object obj や new object();だけじゃ不足なのは何故？
・そこにあるオブジェクトをPCは自力で探せないの？
べつにアセンブラまでやれとは思わないけれど、
適当な具体化、抽象化の度合いがあると思う。

576 ：デフォルトの名無しさん：04/02/03 20:42

すくなくとも初心者に必要なのは「プログラミングを楽しむ」だと思うけどな
納期ないんだからﾏﾀｰﾘとね

577 ：デフォルトの名無しさん：04/02/03 20:49

>>573
それはある程度分かってきてから、実は・・・みたいな感じで学んだ方が実感湧くと
思うなぁ。教える側も、いきなりそこを教えるのはしんどいんじゃないかな。

578 ：574：04/02/03 21:51

>>575
>こういった疑問
すまぬがその疑問自体がよく分からん。
なんにしろ、多くのことはOOはOOモデルでの説明が可能だし、
逆に実装の話とは別のレベルの話ができるようになるべきことを
わからせるべき。

そうでないとこれを地で行くことになると思われ。
http://www.geocities.jp/objectbrain/donotneedobjectbrain.html

579 ：PG初学者：04/02/03 23:11

アセンブラはせめて２番目以降にさせてくれ
そういう俺は最初にJavaをチョイス

580 ：デフォルトの名無しさん：04/02/03 23:14

>>577
禿同
>>579 いまどきの王道と思われ。

581 ：デフォルトの名無しさん：04/02/03 23:19

>>578
なるほど。

ところでこのままこういった話が揃っていくと、新しい
教科書を作れるくらいの情報が集まりそうでおもろいな。

582 ：デフォルトの名無しさん：04/02/04 03:42

OO以前にプログラミングをした者はOOの得失を理解出来るが、
OOから入った者はOOの不便さにやる気をなくしはしないか？

いきなりチームに放り込まれれば否応無しだが、そういう
シテュエーションは想像し難いのだが・・

583 ：デフォルトの名無しさん：04/02/04 04:04

>>582
>OOの不便さ

例えば? 初心者は GUI 的なものを作りたがる（統計的なデータは無いけど）から、
OO はベストマッチじゃないかな。それに OO 以前にプログラミングをしてなく
ても、OO のメリット・デメリットは理解出来る。構造化言語が出る前にプログラム
を書いていた人間が、構造化言語のメリットを理解出来るように。

584 ：デフォルトの名無しさん：04/02/04 04:06

不便さよりも、覚える面倒くささが問題になりそうかなぁ。

585 ：デフォルトの名無しさん：04/02/04 04:12

言語の文法と同時に、ライブラリを覚えるのは大変ではないか？
OOは、「標準」ライブラリを否定するものだろう？
命名規則がしっかりしていれば良いが。

586 ：デフォルトの名無しさん：04/02/04 04:32

>>582
おれは基本的にあなたの言い分に賛成なのだが、
体験談的レスにOOから入って良かったという意見もある。
最終的に到達する所は似たり寄ったりでも、そこに
至る過程がいくつかあるのだろう。
人を教えるときに自分がいいと思う方法を使うのがいい。

587 ：デフォルトの名無しさん：04/02/04 08:42

「ライブラリを覚える」の意味がわからない

588 ：デフォルトの名無しさん：04/02/04 11:01

>>587
ライブラリの使い方を覚える

589 ：デフォルトの名無しさん：04/02/04 13:18

OOから入るのも、それがJavaみたいな例外事象いっぱいでかつしょっぱな
からそれに付き合わざるをえない代物を避ければ大丈夫でしょう。

Squeakあたりならいい選択だと思うよ。

590 ：デフォルトの名無しさん：04/02/04 22:38

要するに Ruby か、それ以外（＝ゴミ言語か時代遅れ）かって話だ。

591 ：デフォルトの名無しさん：04/02/06 16:05

>>582
漏れはＣから初めてＣ＋＋に至った。
ＯＯは便利だと思った。

592 ：デフォルトの名無しさん：04/02/07 02:51

タイピングソフトを作りたいのですがどのプログラムを習うのが良いんでしょうか。

593 ：デフォルトの名無しさん：04/02/07 02:57

>>592
> タイピングソフトを作りたいのですがどのプログラムを習うのが良いんでしょうか。
gtypistから習うとよいのではないでしょうか。
http://www.gnu.org/software/gtypist/gtypist.html

594 ：デフォルトの名無しさん：04/02/07 03:05

タイピングゲームメーカー
ttp://www.alcatia.com/software/TypingGameMaker/

595 ：デフォルトの名無しさん：04/02/07 13:15

チャットソフトとチャットサーバを作りたいんですけど
C++を勉強するのが一番いいですか？

596 ：デフォルトの名無しさん：04/02/07 13:22

既存のチャットソフトとチャットサーバを利用するのが一番いいです。
次善はJavaで書くことです。

597 ：デフォルトの名無しさん：04/02/07 13:40

CGI部分はCが早く・速いからいい。

598 ：592：04/02/07 22:18

土台から作りたいんですが･･･

599 ：デフォルトの名無しさん：04/02/07 22:19

>>598
どれでもいい
好きなの選べ

600 ：デフォルトの名無しさん：04/02/07 22:23

>>598
お勧めはベーシック
しかもポケコン
学校で配れば一躍人気者だ。

601 ：デフォルトの名無しさん：04/02/08 01:38

>>598
おれならdelphi。

602 ：Star：04/02/08 10:42

>>598-601
　土台からならＣ・Ｃ++・Javaじゃないの？

603 ：それを言い出すと VHDL とか言う奴が釣れてしまいそうだが...。：04/02/08 11:33

何で、アセンブラを無視するのか ?
できないから ?

604 ：デフォルトの名無しさん：04/02/08 11:52

>>602
Java で土台は作れません。(w

JVM を組むのには何を使っていると思ってるの?

605 ：デフォルトの名無しさん：04/02/08 12:48

>>604
ここでの「土台」という言葉は594に対するレスだと思われ。

606 ：デフォルトの名無しさん：04/02/08 14:24

やっぱ VB.NET か C#.NET が楽なんでない?

607 ：デフォルトの名無しさん：04/02/08 14:28

初心者の揚げ足を取るスレはここですか？

608 ：デフォルトの名無しさん：04/02/08 15:51

>>604
本格的低脳馬鹿ﾊｹｰﾝ。
おまいは機械語でＯＳ，いや
トランジスタの作成からはじめろよ（ｗ

609 ：デフォルトの名無しさん：04/02/08 16:01

久々にもの凄い馬鹿を見た。

610 ：デフォルトの名無しさん：04/02/08 16:07

そうだな・・・
トランジスタじゃなくて真空管から作るのが筋だと思うぞ。

611 ：デフォルトの名無しさん：04/02/08 16:27

>>608
やっぱりでてきたか...。
→ >>603 のメル欄

612 ：デフォルトの名無しさん：04/02/08 16:32

→ >>603 のメル欄
sage（ｗ
VHDLシステムを組むのには何を使っていると思ってるの?
しかも603かよ（ｗ

613 ：デフォルトの名無しさん：04/02/08 16:43

ああメル欄じゃねーな、名前欄だったな。

> VHDLシステムを組むのには何を使っていると思ってるの?

なんのこっちゃ !?

614 ：デフォルトの名無しさん：04/02/08 16:50

自分で書いたんだろが（ｗ

VHDLで土台は作れません。(w
フリップフロップから自分で作れっての。

とまあ、603=604は、アセンブラしかまともに出来ず、
まともな言語をつかう人間にコンプレックス抱いてる可哀想なヤシ
ということで、いじめるのは止めましょう。

615 ：デフォルトの名無しさん：04/02/08 17:04

>>614
おまえ、Java の VM (=実行環境) と VHDL (=単なるツール) をごっちゃにしてるだろ。

まあ、

>>610
> トランジスタじゃなくて真空管から作るのが筋だと思うぞ。

とまで書いてあるのに、

> フリップフロップから自分で作れっての。

なんて中途半端なことを言うような奴だからなぁ...。

616 ：デフォルトの名無しさん：04/02/08 19:15

そしてますます初心者はこのスレから離れていくのであった

617 ：デフォルトの名無しさん：04/02/08 19:21

元から1人もいないけどな。

618 ：605：04/02/08 19:51

煽りたい気持ちをぐっと堪えて終了させたのに、結局煽る奴が出るのか。
だったら俺が煽ればよかった。

619 ：デフォルトの名無しさん：04/02/08 20:37

まずは、宇宙創造から。

620 ：デフォルトの名無しさん：04/02/08 23:39

age

621 ：デフォルトの名無しさん：04/02/09 11:22

まずシリコンの切り出しから始めろ。

622 ：デフォルトの名無しさん：04/02/09 13:43

トランジスタや真空管は複雑だからまずはリレーから。
ということでコイル巻きをやりなさい。

623 ：デフォルトの名無しさん：04/02/09 13:55

コイルに使う心棒と電線を作らなきゃ

624 ：デフォルトの名無しさん：04/02/09 15:05

電線を作るには溶鉱炉を用意しないと

625 ：デフォルトの名無しさん：04/02/09 16:40

じゃあまず溶鉱炉から

626 ：デフォルトの名無しさん：04/02/09 22:41

>>624-625
だから、素材 (=電線) とツール (=溶鉱炉) をごっちゃにするなよ。
溶鉱炉を制御するためのコンピュータが... とかなってループするぞ。
それじゃあ、>>612 のヴァカと同じじゃん。

627 ：デフォルトの名無しさん：04/02/09 23:16

最終的には分子レベルから。

628 ：デフォルトの名無しさん：04/02/10 00:06

コンピュータを作るのに必要な溶鉱炉を制御するコンピュータってどうやって
作ったんだ炉な。奥が不快。

629 ：デフォルトの名無しさん：04/02/10 01:21

溶鉱炉はコンピュータのない時代から存在してますが、何か？

630 ：デフォルトの名無しさん：04/02/10 13:02

やっぱ基本は階差機関だよな。

631 ：デフォルトの名無しさん：04/02/10 14:27

http://science2.2ch.net/kikai/

632 ：デフォルトの名無しさん：04/02/10 16:20

例え悪すぎ

633 ：デフォルトの名無しさん：04/02/11 02:38

ロシア語

634 ：デフォルトの名無しさん：04/02/11 02:48

プログラミング言語は手段であって目的ではない。
目的を達成するための論理構築ができない椰子は
何やっても無駄。

635 ：名無し＠沢村：04/02/11 06:40

マシン語習えよ。

http://hp.vector.co.jp/authors/VA015412/

636 ：デフォルトの名無しさん：04/02/11 07:17

>>634
論理構築はどうやって鍛えるん？
一通り参考書読んで、理解したつもりになっていざコーディングに入ろうと思った時、
　,、,
（･ｅ･）？？
ﾟしJﾞ
なにしたらいいの？てなっちゃうですよ。

637 ：636：04/02/11 07:21

エログロマーの中の人は、漠然と”こんなソフトを作ろう”と思ってから、
実際コーディングに入るまでの間にどんな作業をしてるの？

638 ：デフォルトの名無しさん：04/02/11 07:24

コピペを探す

639 ：デフォルトの名無しさん：04/02/11 09:57

>>636
論理的思考能力を鍛える本や、クリティカルシンキングの類の本を読む。

640 ：デフォルトの名無しさん：04/02/11 13:33

>>636
バカにでもわかるように一字一句丁寧に自分のやりたいことを順序だてて書き下してみる。
それが出来ないようなら無理。

641 ：デフォルトの名無しさん：04/02/11 14:03

FORTRAN77で数値計算やるのが、目的も加味されてて、初心者にはいいかも。

642 ：デフォルトの名無しさん：04/02/11 16:52

>>641
数値計算やるならお願いですからFortran90以降を使って
構造化の基礎からきっちり教えて下さい。
でないと後から保守する人間が氏にます。

何でもかんでもGO TOで飛ばすのやめれ～！
IIとかNNNとか訳わかんねー変数COMMONにするのやめれ～！！

643 ：デフォルトの名無しさん：04/02/11 18:02

エスペラントに決まってるだろ。

644 ：デフォルトの名無しさん：04/02/11 18:06

DO 10 I=1,1000

10 CONTINUE

645 ：デフォルトの名無しさん：04/02/11 19:21

DO 10 I=1.1000

10 CONTINUE

646 ：デフォルトの名無しさん：04/02/11 21:03

Javaでファイナルアンサー？

647 ：デフォルトの名無しさん：04/02/11 21:07

初心者がやりたいであろうGUIがNG。
Javaをちょこっとやる→C#でGUIやる。あとはやりたいように。

648 ：デフォルトの名無しさん：04/02/11 21:15

>>636
実際組んで悩むしかないよなぁ。
免許の教習所みたいにペアプロで横からケツたたく人がいれば
なおいいかも知れ無いケド
頼りきりになるとかえって訓練にならないかもしれないな。

649 ：デフォルトの名無しさん：04/02/11 21:58

>>647
じゃぁ、GUIやるのを我慢できればJavaの方が勉強するには良いってこと？

650 ：デフォルトの名無しさん：04/02/11 22:45

よいと思われ。
本もWeb情報もたくさんあるし、フリーのツールもライブラリもソースもある。
最初はケチらず、一番最初にオブジェクトの説明がされている本を買って
やってみることを薦める。

651 ：デフォルトの名無しさん：04/02/11 22:51

>>636
JavaなどのOOなら話は簡単。
作りたいソフトをどんなのか発揮りさせて、
それを妄想上の部品で組み立てることを想像して、
それぞれがどんな機能を持ってるかをはっきりさせて、
それをクラスとメソッドにすればよい。
なんかおかしければ適当に上に戻る。

652 ：デフォルトの名無しさん：04/02/11 23:21

>>651
妄想するなよｗ

653 ：デフォルトの名無しさん：04/02/12 00:07

おまいら結構親切だな…

654 ：デフォルトの名無しさん：04/02/12 01:18

いきなりC++っていうのはきついですか？

655 ：デフォルトの名無しさん：04/02/12 01:34

>>654
それはマゾ奴隷用の言語です。
筆おろしにはおすすめできません。

656 ：デフォルトの名無しさん：04/02/12 01:51

[参考]C++ のおべんきょの前に(あるいは並行して)、C は必須か？
ttp://www.tietew.jp/cppll/archive/7978

657 ：デフォルトの名無しさん：04/02/12 02:27

C++でいいけど覚えることが多すぎるから
最初はCとして使うのがいいかもね

658 ：デフォルトの名無しさん：04/02/12 23:41

最初はコンピュータを使ってパズルを解いてみたいんですが
この場合C,JAVAのどちらかになるんでしょうか？

659 ：デフォルトの名無しさん：04/02/12 23:42

>>658
んなこたーないよ。
大抵の言語でできるべ。

660 ：デフォルトの名無しさん：04/02/13 00:06

JAVAを始めてみようかと思う。
エクリプスっていうの便利そうだし。

661 ：デフォルトの名無しさん：04/02/13 00:16

マジな話

HSPでいいじゃん

662 ：デフォルトの名無しさん：04/02/13 00:41

>>658
パズルを解くんなら、Prologがいいと思われ。
…漏れはProlog出来ないけどね。

663 ：デフォルトの名無しさん：04/02/13 00:55

>>658
パズルだとLisp/SchemeやLogoでしょ。

664 ：デフォルトの名無しさん：04/02/13 00:59

LOGOなつかすぃ

665 ：デフォルトの名無しさん：04/02/13 01:20

普通のパズル解くなら、Cがイイに決まってる。
速度的な問題もあるし、Javaはあまりお薦めしない。

666 ：デフォルトの名無しさん：04/02/13 01:32

>>665
速度を気にするならFORTRAN最強になるわけだが

667 ：デフォルトの名無しさん：04/02/13 03:47

パズルにむいてる汎用言語は
リスト(コンプリヘンジョン)が自動でバックトラックしてくれる
Haskellだな。

Cはパターン生成は速いがロジックと組み合わせると面倒。
Javaは(できるけど)多分向いてない。

668 ：デフォルトの名無しさん：04/02/13 04:58

まず、今自分が興味を持てることをあるていど、やってみる。
手に馴染んだエディタを使い倒したいなら、それのマクロ言語でもいい。
GUI を手軽に作りたくて、Delphi でも VB でも手を染めたなら、それでいい。
ゲームを作りたいのなら、HSP でもいいよ。CGI の改造から Perl に入ってもいい。
よく、こういうスレでは HSP みたいな文法の混乱した言語（漏れもそう思う）
から入っちゃいけないとか、Perl みたいな型無し言語から入ったらいかんとか、
そういうことを宣うヤシがいるけど、気にしなくていい。
どんな言語でも、例えば Perl ならそれなりの機能のある掲示板
（レスをつけると上に上がるとか、書き込んだ人が削除できるとか）
HSP なら RPG もどきが作れるまで、がんばれ。やればできるよ。
ただ、多少遠回りになってもいいから、疑問点が出たらなるべく人のスクリプト
を読んで、自分で解決しれ。丸写しでもいいから、誰かに質問する前に探せ。

それができてから、Ｃの参考書を一冊読む。これが一番だと思う。

669 ：668：04/02/13 05:00

……ということを言うと、「じゃあ最初からＣやりゃいいじゃん」という反応も
ありそうだが、興味を持てることを実現する近道がＣなら、それでもいいよ。
だが、そういう例はあまりないと思う。

670 ：デフォルトの名無しさん：04/02/13 08:45

>>669
OS作り

671 ：デフォルトの名無しさん：04/02/13 14:11

Cが初心者につまらないのはGUIが出せないからだと思う。
だから例えばPhotoShopやLightwaveのプラグイン書きや
Tcl/Tkなどを組みこんでみたりすれば、Cでも楽しめると
思う。

672 ：デフォルトの名無しさん：04/02/13 15:13

Cでも実行環境がP/ECEとかのAVが簡易に制御できるものなら無問題。

Windows 上のプログラムをやるなら多少の金をかけて VB.NET か C#.NET
を買う方が結局の所無駄が無いと思う。

あるいは FLASH とか。

673 ：デフォルトの名無しさん：04/02/13 20:22

Ｃ言語学ぶために、
BorlandでBorland C++ Compiler 5.5を
ダウンロードしようと思ったんだけど、
http://www.borland.co.jp/cppbuilder/freecompiler/bcc55download.html
このページにいってから何すればいいのか全然わかんない。
どうすればいいか教えてください。

674 ：デフォルトの名無しさん：04/02/13 20:56

まず金を振り込む。

675 ：デフォルトの名無しさん：04/02/13 21:20

>>674
何処にｗ

>>673
解凍して適当なフォルダに突っ込んで設定をする。
キーワード「 BCC　環境変数」でググれば画像付きの
親切ページが釘煮の中のイカナゴのごとく見つかるよ。
訓練に忍耐は付き物だけれど、極端に苦しい思いをしないで、
毎日続けられる程度の時間を守って努力してください。
長くても2時間くらいかな。健康を祈る。

676 ：デフォルトの名無しさん：04/02/14 00:34

初心者がいきなりC…絶対駄目だとは言わないけど
少しはプログラミングというものが分かってからにしてくれるといいな。

1000行を越えるような関数をメンテさせられる側の身にもなって欲しい。

677 ：デフォルトの名無しさん：04/02/14 00:51

一関数で1000行書けたらたいしたもんだ。

678 ：デフォルトの名無しさん：04/02/14 00:56

初心者の学習向けという点では、こんなのはどうだろうか。
ttp://www.cmt.phys.kyushu-u.ac.jp/~M.Sakurai/prog/progf.html

今時フローチャートかよ、っていう意見もあるだろうが。

679 ：デフォルトの名無しさん：04/02/14 01:20

pythonからはいったら、綺麗なコードをかくようにならないかなぁ？

680 ：デフォルトの名無しさん：04/02/14 16:38

>>679
Python だと雑事に煩わされない分だけ学習速度は速いと思うけれども、
Python というタガが外れた後にどうなるかは学習環境に拠ると思う。

今の所 Python の本はまともなのが多いから問題無いけれども、もし将来
流行ったら VB とか JavaScript とか Parl みたいに腐れた入門本が出ない
とも限らないし。

681 ：デフォルトの名無しさん：04/02/14 18:43

なんでもいいでしょ。Java でも Ocaml、Lisp、C++、C、Fortran でも。。
やっぱ、>>17 でしょ。目的別に選べばいいと思う。

なるべく近くのキチンと良く知ってる先輩や友人を探して、
具体的なコード記述方法について頻繁に相談することが一番だと思う。

682 ：デフォルトの名無しさん：04/02/14 21:42

>>17には大方賛成だけど、統計処理には R だ

683 ：デフォルトの名無しさん：04/02/14 21:45

逆に習ってはいけない言語を挙げたほうがいいのかもしれない。

まずは、とりあえず、HSPをあげておく。

684 ：デフォルトの名無しさん：04/02/14 21:51

Delphiも駄目だな

685 ：デフォルトの名無しさん：04/02/14 23:21

Java とか C++ とかの静的な言語も後回しにした方がいいと思う。

C くらい単純だと逆に入門用には良いかもしれないが。
(それで一般公開する実用品を作ろうなんて考えないなら)

686 ：デフォルトの名無しさん：04/02/14 23:31

>>685
強型OOも、最初からやればそんなもんかと思って問題ないと思われ。
つうか、Cで初心者には意味不明なポインタ絡みのバグに悩むのは時間の浪費。

687 ：デフォルトの名無しさん：04/02/14 23:53

○ 時間の空費
× 時間の浪費

688 ：デフォルトの名無しさん：04/02/15 00:42

結局Javaなのか？

689 ：デフォルトの名無しさん：04/02/15 00:53

>>680
どっちみち迷わされると思う。言語そのものの仕様に
振り回されるかライブラリの仕様に振り回されるかの2択。
ただ入門書のラインナップから考えると提案には同意。

690 ：デフォルトの名無しさん：04/02/15 00:59

企業の息のかかった言語はダメだな

691 ：デフォルトの名無しさん：04/02/15 11:52

正直順番なんてどうでも良くないか?

C++をやるのにCを最初にやれとか、いや、Javaだとか、
Delphi,C#,VBはいいとかダメとか、
スクリプト言語を最初にやれとか、
皆様、勝手なことを言ってらっしゃいますが。

各言語ってのはそれ自身で動くように作られているのだから、
これをやるためにはこれを最初にやれというのはそれこそ時間の浪費。

692 ：デフォルトの名無しさん：04/02/15 12:05

>>691
いきなりC++から挑んで挫折したヤツを何度と無く見てきているが。
全ての言語が初心者に対して等価だとでも言うの？ｗ
初心者に分かりやすい情報の量の多さ（書籍や入門サイト、教えてくれる人など）ひとつ取ってみても差はあると思うんだがなぁｗ
他にもいろいろ要素があるだろうがそんなに単純じゃないだろ。
小学生ですか？

693 ：デフォルトの名無しさん：04/02/15 12:12

C++から入ってもいいとは思うが、何を学ぶのでも大切なことは
いきなり多くを求めようとしないことだ。いずれ理解できると信じて
自分に理解できる分ずつ勉強していけば、ある程度までは何とか
なるものだ。あわてて多くを理解しようとするのが失敗する典型。

694 ：デフォルトの名無しさん：04/02/15 12:17

>>691
だったらオマイのところの新人には、Opteronのマシン語から教えてあげてくんろ

695 ：デフォルトの名無しさん：04/02/15 12:19

BASIC88,Z80アセンブラ
C,X86アセンブラ
C++
JAVA
自分が学んだ順番

696 ：デフォルトの名無しさん：04/02/15 12:39

なんだかんだ言って最初はBASICがいいな。

697 ：デフォルトの名無しさん：04/02/15 12:47

現在そのBASICの位置にあるのは「HSP」か「ひまわり」か。
「ひまわり」は結構評判が良いね。

698 ：デフォルトの名無しさん：04/02/15 13:00

>>697
VBSとかJScirptとかがそれに近いんじゃ無いの？
インストールしなくてもそのまま使えるところとか。
ただ、GUIが使えないので初心者のモチベーションが続くかが問題だね。
本当はVB6あたりが良いんだろうな。

699 ：デフォルトの名無しさん：04/02/15 13:15

ひまわりってｍｉｎｄみたい

700 ：デフォルトの名無しさん：04/02/15 13:49

>>683
HSPはダメナノカー
昨日からはじめたのだが、やめよか・・

701 ：デフォルトの名無しさん：04/02/15 13:58

>>700
目的や予算によりけりでは？

702 ：デフォルトの名無しさん：04/02/15 14:01

>>700
HSPすれを見て、一生あのレベルの人間でいてもいいと思うなら、HSPでいいのでは？

703 ：デフォルトの名無しさん：04/02/15 14:06

普通に考えたら
Basicでプログラムの楽しさを知る
Basicの遅さを感じる
Cでプログラムの基本を学ぶ
Cのコーディングの煩雑さを感じる
C++でオブジェクト指向を学ぶ
C++で仕事めっけ！

がいいかと

704 ：デフォルトの名無しさん：04/02/15 14:13

>>703
遠回り過ぎ。最初からC＃でOK。。。仕事ないけどな（w
まあ代わりにJavaでもいいわけだが。仕事もあるし。
だいたいプログラムの楽しさを知るのにBasicである必要ないしな。

705 ：デフォルトの名無しさん：04/02/15 14:20

>>704
BASICは目的に対して簡単だという利点がある。
やはり手続き型がプログラムというものを理解するのに一番適しているだろう。
C#やJavaはまず、クラスありきなのでそこら辺がつらい。
それにクラスの中の各種メソッドも結局の所手続き型なのでプログラムの基礎としてはBASICが最適。

706 ：700：04/02/15 14:30

引き続き質問させてください・・
大学でＰａｓｃａｌを学びました。ヒープ、バブルソートあたりは理解しました。
他にもＣＧＩを通して、Ｐｅａｒｌも学びました。基本書も一冊精読しました。
将来はプログラムできる人間になりたいのですが、上の二つじゃいかんせん。
そこで、他言語に手を出したいのですが、オススメはございませんか？

707 ：デフォルトの名無しさん：04/02/15 14:36

Ｐｅａｒｌ＞Ｐｅｒｌ
です( ;谷)

708 ：デフォルトの名無しさん：04/02/15 14:37

PascalやったんならDelphiやればOOPが少し分かるべ。
C++、C#、Javaはそれからやってもいいと思う。

709 ：デフォルトの名無しさん：04/02/15 14:42

>>706
C++、Javaを薦めるよ。

>>708
既にそれで食っていこうという段階ならDelphiは仕事無いからキツい。

710 ：デフォルトの名無しさん：04/02/15 14:47

>>705
> やはり手続き型がプログラムというもの
という思い込みを先に作っちゃうから、
> C#やJavaはまず、クラスありきなのでそこら辺がつらい。
となってしまうと思われ。
最初からオブジェクトの組み合わせがプログラムというものと習えば
そんなものかと思うと思われ。
コンパイルが多少うざいかもしれないが、間違いを自動的にチェックしてくれると思えば、
初心者にもメリットと思われ。

711 ：700：04/02/15 14:50

>>707,708
考えた結果、Ｃ++で生きたいと思います。
Ｃ++を一通り学んだあと、Ｃのソースって読めるもんなんでしょうか？
スレ違いすんません。

712 ：デフォルトの名無しさん：04/02/15 14:52

++ってそんなに仕事あるの？
まわりじゃC,Java,Perl,PHPくらいだな。鯖側では。
クライアントの仕事なのかな？そんなにある？

713 ：700：04/02/15 14:56

過去ログ斜め読みしました。
もしかしてＣはプログラマにとって必要十分条件ですか？

714 ：デフォルトの名無しさん：04/02/15 15:02

>>710
クラスによるモデリングは次の段階だよ。
いきなりでは離れていってしまう。

また、OOPLが全てではない関数型言語もあり、おなじOOPLでもクラスベース
プロトタイプベースなどがある。
それに局所的に共通なのが手続き型だ。

プリミティブで共通で簡単なものを最初に学ぶのは学習の基本。

715 ：デフォルトの名無しさん：04/02/15 15:03

>>712
どこかの雑誌のアンケートではVBについで２位だったから人口多いのでは

716 ：デフォルトの名無しさん：04/02/15 15:03

一昔前はね。
これからも価値のあるスキルであることは間違いないが、
オブジェクト指向ができないと仕事は減ると思われ。

717 ：デフォルトの名無しさん：04/02/15 15:08

>>716は>>713へのレス。

>>712
VBがトップってことは、やはり立地クライアントってまだ市場でかいのね。。
でも、使用人口＝仕事の需要なのかな。

718 ：717：04/02/15 15:10

>>712じゃなくて>>715ですた。。。吊ってくる。

719 ：デフォルトの名無しさん：04/02/15 15:16

>>714
>それに局所的に共通なのが手続き型だ。

OOPL はメッセージ送信の記述だし、関数型は関数の返り値を使った計算の記述。
手続きの記述がプリミティブで共通の物と考えるようになったら先へ進めない。

720 ：デフォルトの名無しさん：04/02/15 15:20

>>692

>いきなりC++から挑んで挫折したヤツを何度と無く見てきているが。
お前の周りが馬鹿ばっかなだけ。

>全ての言語が初心者に対して等価だとでも言うの？ｗ
言ってないよ。もう一度>>691を良く見るように。

>初心者に分かりやすい情報の量の多さ（書籍や入門サイト、教えてくれる人など）ひとつ取ってみても差はあると思うんだがなぁｗ
差があるのは事実だが、だから何?

>他にもいろいろ要素があるだろうがそんなに単純じゃないだろ。
↓単純なのはお前。
>小学生ですか？

721 ：デフォルトの名無しさん：04/02/15 15:28

>>719
変わらんよ。
関数型言語は式と文に差がないだけ。
OOPLのメッセージ送信なんてほぼBASICと変わらないでしょ。
Smalltalkのキーワードメッセージ送信は多少特殊だがそれでも基本は同じだ。
プロトタイプベースのOOPLも大差なし。

722 ：デフォルトの名無しさん：04/02/15 15:29

>>720
キミもういいやｗ

723 ：デフォルトの名無しさん：04/02/15 15:32

>>719
手続き型でもOOPLでも関数型でも関数を使わないプログラムはない。
手続きを使わないプログラムやオブジェクトを使わないプログラムはあるが。

よって、
関数こそがプリミティブで共通なので、
関数型やれ！

…といってみる。

724 ：デフォルトの名無しさん：04/02/15 15:33

>>719が非常によいことを言っている気がする。
>>721はすごくできる人かその反対かのどちらかの気がする。

725 ：デフォルトの名無しさん：04/02/15 15:36

横から勝手に説明すると、
>>723は、>>714への煽りですね。

726 ：デフォルトの名無しさん：04/02/15 15:37

>>723
> 手続き型でもOOPLでも関数型でも関数を使わないプログラムはない。
> 手続きを使わないプログラムやオブジェクトを使わないプログラムはあるが。

(´-`).。ｏＯ(釣りなのかなぁ・・・

727 ：デフォルトの名無しさん：04/02/15 15:42

>>722
┓(´_`)┏

728 ：デフォルトの名無しさん：04/02/15 15:43

>>724
>>721は屁理屈で煙にまく術を覚え始めましたって感じだな。
多分なんでも「俺様手続き型」なんじゃないか。

>>721
>関数型言語は式と文に差がないだけ。
その差がないことと、
関数型言語が共通部分として手続き型をふくむ(んだろ？)ということと、
何の関係があるのか説明してくれないか？

>OOPLのメッセージ送信なんてほぼBASICと変わらないでしょ。
どういう意味か説明してくれないか？

729 ：デフォルトの名無しさん：04/02/15 15:45

>>726
> 手続き型でもOOPLでも関数型でも関数を使わないプログラムはない。
> 手続きを使わないプログラムやオブジェクトを使わないプログラムはあるが。

void関数をfunctionと区別してprocedureと呼ぶアレをイメージしてると思われ。

730 ：723：04/02/15 15:49

>>725
御意。

>>729
御意。そこの関数は「関数」型言語の「関数」。

731 ：デフォルトの名無しさん：04/02/15 15:52

>>728
> 関数型言語が共通部分として手続き型をふくむ(んだろ？)ということと、
> 何の関係があるのか説明してくれないか？
文が手続き型である以上、式と文は等価なると言うことがどういう事か解るだろ？

> どういう意味か説明してくれないか？
オブジェクトにメッセージを送ることで何かしらの処理をすることと、関数を呼ぶことにどれほど差があるんだ？
と言うか手続き型とこれらの問題がどう関係するのかサッパリワカランｗ
プログラムは手続きどおり上から下へ順番に実行される。

732 ：デフォルトの名無しさん：04/02/15 15:55

>>730
マクロアセンブラは？ｗ

733 ：デフォルトの名無しさん：04/02/15 15:57

>>731
>文が手続き型である以上、式と文は等価なると言うことがどういう事か解るだろ？
関数型言語で、文(言語仕様で定義された構文要素)と式は等しいが、
*文は手続きではない*。
あなたの「文」の定義とはなにか？

> プログラムは手続きどおり上から下へ順番に実行される。
関数型でもOOPLでもそんなことはない。
特に、純粋関数(型言語で)はどれをいつ実行しようと自由だ。

ようするにOOPLも関数型もまったく知らないということか。

734 ：デフォルトの名無しさん：04/02/15 15:58

俺、プログラミングの経験無しで、アクセラ本でC++やったのだが、
C++って別に複雑とも思わなかった。

Cの方が低レベルの扱いが多くて大変じゃないか?

735 ：From:723 ：04/02/15 16:01

>>732
やったことないから知らないけど、
関数になってるサブルーチン作ったりしない？

…そもそも、初心者にマクロアセンブラやらせないよね？

736 ：デフォルトの名無しさん：04/02/15 16:14

>>733
逆だったな式自体が手続きだと言いたかった。
式をばらせば手続きになる。
これで満足かい？

> 関数型でもOOPLでもそんなことはない。
> 特に、純粋関数(型言語で)はどれをいつ実行しようと自由だ。
手続きでメッセージ送信が行われるんだろ？
いつ呼ばれるとかではなく。
関数の中身も結局の所、手続き型なんだよ。
話をはぐらかしているのか本気なのか解らないが。

737 ：デフォルトの名無しさん：04/02/15 16:22

人工知能の勉強(開発)目指したいのですが、それに向けて初心者がまず勉強した方がいい言語ってなんでしょうか？

まだ、プログラミング言語の何たるかもわかってない厨房なんですが、助言おねがいすます！

738 ：デフォルトの名無しさん：04/02/15 16:24

>>737
それこそ、LispとかSchemeなんかが良いんじゃないの？

739 ：デフォルトの名無しさん：04/02/15 16:24

>>737
LISP

740 ：デフォルトの名無しさん：04/02/15 16:24

スワヒリ語を勉強することをお勧めする。

741 ：デフォルトの名無しさん：04/02/15 16:26

>>737
prolog.

>>736
論理型も手続き型を内包していますか?

742 ：デフォルトの名無しさん：04/02/15 16:30

そういえば、一時期prologかlispかなんて言われてたな。
今はLispは一応生き残り、prologは言わずもがな、と。

743 ：デフォルトの名無しさん：04/02/15 16:33

ネタとわかっていてあえてマジレスするスレ。

744 ：デフォルトの名無しさん：04/02/15 16:34

Prologって実は関数型よりも頭の中は手続き的だったりする（w

なんにしろ、厨は最初に手続き型をやるとこういう哀れな人になっちゃうので、
最初に手続き型からやるのは危ないですね。
仕事の口から考えると、クラスベースのOO（C#やJava）から入るのがよいかと。

745 ：デフォルトの名無しさん：04/02/15 16:35

>>742
フリーの処理系は Prolog もかなり充実していると思うよ。

746 ：デフォルトの名無しさん：04/02/15 16:38

>>740
>スワヒリ語を勉強することをお勧めする。

確かに自然言語とか認識をやるのは良いかもね。

747 ：そっち系修了者：04/02/15 16:39

人工知能っつうとLispとかPrologとかいうけど、実際何でもいいよ。
人工知能って何でもありだからね。論理系の推論やるならPrologかもしんないけど、
その分野自体が尻つぼみだよ。

748 ：デフォルトの名無しさん：04/02/15 16:39

>>744
んー基本は手続き型で良いと思うけどねぇ
それからクラスベースのOOPLで良いんでは無いかと。
実際にここの人間の習得遷移を見ているとBASICから始めたヤツ多いでしょ。

749 ：デフォルトの名無しさん：04/02/15 16:43

そういうヤツがマトモに育ったかどうかが問題だがな。

750 ：デフォルトの名無しさん：04/02/15 16:44

>>736
> 式をばらせば手続きになる。
>関数の中身も結局の所、手続き型なんだよ。

違う。
わからないなら、例えば
(1) 1 + 2
(2) map sin [1..] -- [1..]は[1,2,..]と続く無限リスト
をばらしてみろ。

751 ：デフォルトの名無しさん：04/02/15 16:46

漏れJavaScriptから始めたよ。
今じゃC言語マンセーだよ。

752 ：デフォルトの名無しさん：04/02/15 16:48

>>750
それは一要素を取り出しただけだ。
それではプログラムにはなるまい。
最終的に必ず手続きになる。

753 ：デフォルトの名無しさん：04/02/15 16:48

漏れはbash(藁

754 ：デフォルトの名無しさん：04/02/15 16:51

>>751
JavaScriptもいいねぇ
つーかECMAScript。
プロトタイプベースはなんか弄っていて面白い。

755 ：デフォルトの名無しさん：04/02/15 16:53

>>748
> 実際にここの人間の習得遷移を見ているとBASICから始めたヤツ多いでしょ。
それは、単に世代的な問題かと。
OO自体がメジャーになったのは++とJavaがメジャーになってきた頃からでしょ。
新しい人は、そっから入っていいよ思うよ。
無意識に、自分の頃はこうだったというのがあるんじゃないかな。それは老害の元だよ。

756 ：デフォルトの名無しさん：04/02/15 16:54

手続きでしか抽象化出来ないと >>752 みたいになってしまうのね。

757 ：737：04/02/15 16:56

みなさんありがとうごだいました。
もっかい自分なりに調べてみます！

758 ：デフォルトの名無しさん：04/02/15 16:58

>>755
>無意識に、自分の頃はこうだったというのがあるんじゃないかな。それは老害の元だよ。

煽りじゃないけど、オブジェクト指向言語が初心者には難しいと考えている人って
まさにコレの様な気がする。自分（あるいは自分の同世代）が難しいと感じたから
・・・。

759 ：デフォルトの名無しさん：04/02/15 17:00

>>752
あなたのようにならないためには
手続き型からやらないほうがいいのでしょうね。

# --
# $ hugs
# Prelude> sum $ take 10 $ filter (<= 100) $ map (* 3) [1..]
# 165
# --
# のどこに手続きが？
# # なにをやってるのか>>752にはわからないだろうけど。

760 ：デフォルトの名無しさん：04/02/15 17:00

>>755
まぁ、世代ってのは確かにあるな。
だがJavaから入るとクラスベースのOOPLに思考が毒されそう。

>>756
手続きで抽象化ってなによｗ

761 ：デフォルトの名無しさん：04/02/15 17:02

>>759
どう考えても手続きだろそれｗ

762 ：From:759 ：04/02/15 17:02

>  あなたのようにならないためには
>  手続き型からやらないほうがいいのでしょうね。

これは間違いでした。取り消してお詫びします
    >> 手続き型を最初に学ぶべきだとおもっている>>752以外の人達

763 ：759：04/02/15 17:03

なお、 # の部分はとりけしておりません。

764 ：デフォルトの名無しさん：04/02/15 17:05

>>760
>手続きで抽象化ってなによｗ

手続きの固まりとして機能を書き下すって言った方が分かり易いかな・・・。

765 ：デフォルトの名無しさん：04/02/15 17:10

数年後にはここの議論が意味をなさなくなる
あっと驚くパラダイムシフトが・・・・

766 ：デフォルトの名無しさん：04/02/15 17:19

>>760
> だがJavaから入るとクラスベースのOOPLに思考が毒されそう。
それは何でもそうでしょ。
ただ、現在毒されても需要的にデメリットが少ないクラスベースOOPLが
安牌ではないかと。

767 ：デフォルトの名無しさん：04/02/15 17:19

漏れの知り合いで、漏れより頭のいいやつがいたんだけど、
そいつはプログラミング全く知らないという状態からいきなりC++を
覚えようとして、そして微妙に発狂して挫折した。
やはりC++から入るのはまずいかもしれない。私的には絶対におすすめしない。
漏れはjavaから入ったが、比較的易しい参考書にであったせいもあるのか、
あまり苦にならず学習することができた。やっぱjavaだね！
java->C->C++という路線をおすすめしたい。

768 ：デフォルトの名無しさん：04/02/15 17:23

何から初めても、最終的に Lisp に辿り着ければ途中は何だっていい（と言ってみる）。

769 ：デフォルトの名無しさん：04/02/15 17:24

>>767
>>654-655ですな。

770 ：デフォルトの名無しさん：04/02/15 17:26

>>767
その微妙に発狂した様子を見てみたいw

771 ：デフォルトの名無しさん：04/02/15 17:28

>>768
出た、Lisp最強伝説信者。
。。。まあ実際最強だとは思うけどね。世界は最強など求めてなかったりする。

772 ：デフォルトの名無しさん：04/02/15 17:47

可読性が…((((((((ﾟДﾟ;;))))))))ｶﾞｸﾌﾞﾙ

773 ：デフォルトの名無しさん：04/02/15 18:04

filter の意味ねーよ、とか言ってみる。

Prelude> sum $ take 10 $ filter (<=100) $ map (*3) [1..]
165
Prelude> sum $ take 10 $ map (*3) [1..]
165

774 ：759：04/02/15 18:16

>>773
あんまり適当に書くもんじゃないとおもいますたorz
# let xs = 1:map (+1) xs in take 10 xs
# あたりのほうが良かったな

775 ：デフォルトの名無しさん：04/02/15 19:47

で、ループの入った手続き処理を提示して何がしたいんだ？

776 ：デフォルトの名無しさん：04/02/15 20:57

今時OOでないプログラム言語なんて C くらいしか生き残ってないんだから
OO云々を気にする必要は無いでしょう。

777 ：デフォルトの名無しさん：04/02/15 21:13

Perlは？

778 ：デフォルトの名無しさん：04/02/15 21:28

Haskell モナ

779 ：デフォルトの名無しさん：04/02/15 21:29

そもそも>>760は思想が毒されると言ったが、
何かを習得して別の何かを得る機会が
失われるという事ははないだろう。
別の言語を習得する助けにもならないがな。

780 ：デフォルトの名無しさん：04/02/15 21:34

>>779
違うパラダイムの言語を習得する場合は妨げになる。

781 ：デフォルトの名無しさん：04/02/15 21:38

>>778
Hakellはデータ抽象とポリモルフィズムはあるぞ。
なんでもOOで設計する言語ではないが。

782 ：デフォルトの名無しさん：04/02/15 21:41

>>780
助けになる場合もあるがな。

783 ：デフォルトの名無しさん：04/02/15 21:44

手続き型の言語を理解出来てないのにＯＯ言語なんて無理。

784 ：デフォルトの名無しさん：04/02/15 21:47

なんか>>759からHaskell使いが沸いてきたなｗ
二人くらいで回してるのかな？
どう考えても初心者に適切だとは思わないがｗ

785 ：デフォルトの名無しさん：04/02/15 21:49

現実的にはVB, Java, Perlあたりがお勧めと思う。

786 ：デフォルトの名無しさん：04/02/15 21:50

>>785
VBは.NETになって敷居が高くなったよ。
VB6がオススメ。

787 ：デフォルトの名無しさん：04/02/15 21:53

>>780
パラダイムがシフトしたら、知らない事を1からはじめることになる。
たとえばC→C++の場合だと今までCの学習に費やしてきた時間と
同じだけオブジェクト指向の勉強をやればずぶの素人と同じ時間が
かかるが同じくらい順調に新しい概念を覚えられる。それだけの話。
変な言語から入って困る事といえば、自分自身が素人であるという
自覚がなくなる事くらいかな。アルゴリズムや機械に対する知識が
多い分だけずぶの素人よりは立場がマシかも知れないけれどさ。
>>782
語弊のある言い方だった。すまん。

788 ：デフォルトの名無しさん：04/02/15 21:56

>>783
別に最初はOOを意識しないで済むOO言語なんていくらでもあるし。

入門者が最初にいじるGUIがらみの部分とかは出来合いの代物の
メソッド部分を埋めてゆくだけだから、そこらへんから入れば問題
無いでしょう。

789 ：デフォルトの名無しさん：04/02/15 22:01

VBAやActiveBASICはどうよ?
REALbasicってのもあるけどMac発祥だしなぁ…。

790 ：デフォルトの名無しさん：04/02/15 22:06

昔F-BASICってのもあったね

791 ：デフォルトの名無しさん：04/02/15 22:12

>>790
今もあるだろ？

792 ：デフォルトの名無しさん：04/02/15 22:13

VB5のついたブルーバックスってまだ売ってる？

793 ：デフォルトの名無しさん：04/02/15 22:14

>>787
例えば何でもオブジェクトにしちまう変な思考が頭にこびりついている場合、その方法を
新しい言語に持ち込んでマイナススタートになることも十分考えられると思うけど。

794 ：デフォルトの名無しさん：04/02/15 22:14

OSやプログラミング言語が肥大化する前にプログラミングを
覚える事の出来た漏れの世代はラッキーだったかも知れないな。

795 ：デフォルトの名無しさん：04/02/15 22:15

>>791
あるのかｗ

796 ：デフォルトの名無しさん：04/02/15 22:16

>>792
CCEのだね。
売ってるよ。
http://bookweb.kinokuniya.co.jp/htm/406257179X.html

797 ：デフォルトの名無しさん：04/02/15 22:17

LispやSchemeの思考は、どんな言語に持ち込んでもプラスになるな。
藻まいらSICPくらい読んどけ！

798 ：792：04/02/15 22:18

>>796
おー、まだあるんだ。
初心者はこれから入ればいいんじゃない。安いし。

799 ：デフォルトの名無しさん：04/02/15 22:20

>>795
ｽﾏｿ。亡くなってた。。
http://www.fps.fujitsu.com/products/past.html

800 ：デフォルトの名無しさん：04/02/15 22:20

>>794
その代わり今は FLASH とかあるし。
クリエイティブな事にからめてプログラミングを学ぶには良い時代になったと思うよ。

801 ：デフォルトの名無しさん：04/02/15 22:23

>>793
素人でも間違った理屈を付けて物事を解釈し、あとから
その間違いに気付いて修正する作業からは逃れなれない。
皆、プログラムに限らず何をやっても前進と後退を繰り返しているよ。

802 ：デフォルトの名無しさん：04/02/15 22:26

>>801
斜め45度あたりにぶっ飛ぶ素人からそのままプロになる困ったﾔｼも多い。

803 ：デフォルトの名無しさん：04/02/15 22:35

クラス型言語に慣れると手続き型言語は使う気が失せる。
Ｃを学ぶのは基礎という意味で重要だと思うが、これから
はクラス型の言語もできないとだめ。

804 ：デフォルトの名無しさん：04/02/15 22:39

クラス型言語なんて言葉はじめて聞いた

805 ：デフォルトの名無しさん：04/02/15 22:52

クラスベースって言いたかったんだろ。
いちいち揚げ足取るなよなｗ

806 ：デフォルトの名無しさん：04/02/15 22:54

>>801
初めての言語の場合、変な癖付いてもまだ真っ白だから軌道修正しやすいけど
一つ覚えている場合はその癖というか思考を修正するのは困難な場合がある。

807 ：デフォルトの名無しさん：04/02/15 22:55

揚足取型言語

808 ：デフォルトの名無しさん：04/02/15 22:55

それにしても「クラスベース」対「プロトタイプベース」で比べるなら
分かるが「クラスベース」対「手続き型」では何だか分からないぞ。

その「クラスベース」言語のメソッドは何で書いているの？

809 ：デフォルトの名無しさん：04/02/15 22:56

>>804
ｸﾞｸﾞっても一件も引っかからないのが笑える

810 ：デフォルトの名無しさん：04/02/15 22:57

もうやめて
それ以上傷つけあうのはやめて

811 ：デフォルトの名無しさん：04/02/15 22:58

>>808
だからOOPL全般の事を彼は言いたかったんだろうよ。
知識がないから「クラス型言語」と言っただけで。
いやらしいなぁ

812 ：デフォルトの名無しさん：04/02/15 23:01

いやああああ

813 ：デフォルトの名無しさん：04/02/15 23:02

CやPerlが好きだなあ。

814 ：デフォルトの名無しさん：04/02/15 23:06

C#かJavaで結論出てんだろ？
ほかの言語挙げるやつは根拠言えっつの。
好きだなぁ、とかわけわかんねぇこといってんなw

815 ：デフォルトの名無しさん：04/02/15 23:06

>>803
　何かを習得すると、似たような事を出来る手段に対する
感心がなくなるのかも知れん。PGには情熱が必要かも。

　おれはCが中途半端にしかわからん趣味人だがC#をはじめてみた。
　UMLってOOPの勉強に便利だね。
　自分でも不思議に思うけれどC学習者の癖にアクティビティ図は苦手。
　シーケンス図は阿弥陀くじみたいでわかりやすいと感じた。

816 ：デフォルトの名無しさん：04/02/15 23:06

SmalltalkもC++もJavaもEiffelも手続型ですが何か

CLOSで頑張れってのか

817 ：デフォルトの名無しさん：04/02/15 23:08

>>815が良いこと言った。（前半）

818 ：デフォルトの名無しさん：04/02/15 23:10

>>816
揚げ足取りやめれ。Haskellerもいるのに。。。っておまえか！！おまえだな！！

819 ：デフォルトの名無しさん：04/02/15 23:11

プログラムは全て手続きからなりたっております

820 ：デフォルトの名無しさん：04/02/15 23:11

俺もCは好きだがC++やC#やった方が役に立つ気がする。

821 ：デフォルトの名無しさん：04/02/15 23:11

クラスで縛るのが重要なのよ。C++はＣ文法も許しているところが
レガシーくさ。関数直呼びを使わなければいいのだが、あるものは
使ってしまうのが人情というもので。

822 ：デフォルトの名無しさん：04/02/15 23:13

>>821
縛らなくて良いよ、かったるいから。
クラスベースｳｻﾞｰ

823 ：デフォルトの名無しさん：04/02/15 23:13

まとめると Ruby がいいってことか。納得した。

824 ：デフォルトの名無しさん：04/02/15 23:15

関数直呼びってさ、関数もオブジェクトととらえた
真のオブジェクト指向からすればなんの違和感もないんだけど。

825 ：デフォルトの名無しさん：04/02/15 23:16

Scheme

826 ：デフォルトの名無しさん：04/02/15 23:16

極端なクラス縛りも現実的じゃないけど初心者にはOOの概念をきちんと理解してもらいたいね。

827 ：デフォルトの名無しさん：04/02/15 23:17

RubyのGUIって何があるの？

828 ：デフォルトの名無しさん：04/02/15 23:17

>>824
ほう、C++ が
> 真のオブジェクト指向
とは、めずらしい意見だな。
。。。って厨は去ね。

829 ：デフォルトの名無しさん：04/02/15 23:18

>>827
http://exerb.sourceforge.jp/
http://www.osk.3web.ne.jp/~nyasu/software/vrproject.html

830 ：デフォルトの名無しさん：04/02/15 23:21

>>828
なんか、勘違いしているっぽいぞキミｗ

>>829
未踏ユース・・・

831 ：デフォルトの名無しさん：04/02/15 23:23

世の中クラスベースOOなんだよ。それが現実の要請なの。だからそれをやるんだよ。
プロトタイプベースはオタクのおもちゃなの。
だいたいこのスレでプロトタイプマンセーとかいってるやつは
どうせロクに使ったこともなく2chでちょっと齧った程度のくせにw

832 ：デフォルトの名無しさん：04/02/15 23:25

>>831
まぁ藻前の言っていることは解るから切れるなｗ

(´-`).。ｏＯ(プロトタイプベースってJavaScriptが一番普及しているのかなぁ・・・

833 ：デフォルトの名無しさん：04/02/15 23:29

クラス型アセンブラ言語まだ？

834 ：デフォルトの名無しさん：04/02/15 23:30

C# は長島茂雄であるといえよう

835 ：デフォルトの名無しさん：04/02/15 23:32

>>834
その心は？

836 ：デフォルトの名無しさん：04/02/15 23:35

スタンドプレーでローカルに目立っても、メジャーには届かない、とか？

837 ：デフォルトの名無しさん：04/02/15 23:39

やまだくん、ぜんぶもっていきなさい

838 ：デフォルトの名無しさん：04/02/16 00:37

nativeコード吐いてリフレクションをサポートする言語ってあるの？

839 ：デフォルトの名無しさん：04/02/16 07:12

りふれくしょんって何？

840 ：デフォルトの名無しさん：04/02/16 11:59

C言語の基礎の基礎はわかるようになったのですが、それ以上いくと難しくて先に
進めません。
別の簡単な言語(VB.net)とかをやってからCをやり直したほうがいいでしょうか？

841 ：デフォルトの名無しさん：04/02/16 12:05

いいえ。それ以上って何のことですか？

842 ：デフォルトの名無しさん：04/02/16 12:18

>>840
Cで十分です。たくさんの言語に手を出すと、広く浅くになって、
中途半端。

843 ：840：04/02/16 12:40

>>841-842
レスありがとうございます。
Cの基礎的な文法しかまだわかっていない状況なので基本情報技術者のCの
問題とかはとけません。
アルゴリズムの勉強はVBが適しているみたいなことを本で読んだのですが、
それでもCで続けて平気でしょうか？

844 ：デフォルトの名無しさん：04/02/16 12:59

>>843
平気。

基本情報処理技術者の問題が解けないのは
ライブラリ関数を知らないからでは？
strcmp()って何？とか。
そんなもん覚えればいいだけ。

アルゴリズムの勉強に言語の違いはあまり
関係ないとおもわれ。

ＣでダメならＶＢでもダメ。
漏れはＶＢなんぞ知らんが。

845 ：デフォルトの名無しさん：04/02/16 13:14

>>840
せっかくＣを勉強しているなら迷わず突き進めばいい。
しかし余力があるなら他の言語に手を出しても構わないと思う。

846 ：デフォルトの名無しさん：04/02/16 13:24

>>843
Cを教材にしたアルゴリズムの本も沢山ありますよ。
大きい本屋さんで実際にめくって買ってみてください。
あと関数の辞典( リファレンスといいます )も欲しいですね。

847 ：デフォルトの名無しさん：04/02/16 13:30

初心者は言語を習得する以前に、フローチャートなどの基本を勉強しろ！
（最近の基本は知らんが…）
基本があれば、どんな言語だって習得するのが早くなる。
基本が理解できない奴はきっと、どんな言語を勉強しようが挫折する。

いろいろと言いたい事はあるが、長くなるので、やめておく。

848 ：デフォルトの名無しさん：04/02/16 13:42

>>847
逆も真なりだが、かなり同意。
なににせよCなら言語仕様の勉強と
アルゴリズムの勉強は同時進行がいいね。
複数言語をやると時間が無くなる理由はこれ。

JAVAならオブジェクト指向も同時にやらないとしんどいのかな？
同じように構文を覚えた後で何をやって良いのか解からなくなるとか。

849 ：デフォルトの名無しさん：04/02/16 14:17

フローチャートはプログラム作ってから
ソース見ながら描いてた。

850 ：デフォルトの名無しさん：04/02/16 15:27

>>849
　別に個人の脳内ではどちらを使っても良いでしょ。
　俺もステートメント読んだ方が解かりやすいと感じます。
　通常は物事の表現、解説には言葉や表を使いますが、
人によってどちらがより解かりやすいかは違うそうです。
　ただ、音声と映像の両方を頭の中で扱えた方が記事
や出版物は読みやすくなるのは確かだし、プロなら後で
個性ある後輩達の面倒を見るのが楽になると思います。

851 ：デフォルトの名無しさん：04/02/16 15:37

PADを使う輩もいるから気をつける。

852 ：847：04/02/16 17:52

まぁ、俺が言いたかったのは、基本を学べって事だ。
脳内でフローできるなら問題なし。
しかし、世の中には、ループ処理をロクにコーディングできない奴がゴロゴロしてるらしいぞ。
そんな訳で、フローチャートなど…と記述したわけであります。
別にフローチャートにこだわっているのでは無いので悪しからず。

853 ：デフォルトの名無しさん：04/02/16 19:11

ループはどうしても頭がこんがからかったら、
その部分だけ、別の小さなプログラムにして
実験とかするけど、あんまり良くないやり方？

854 ：デフォルトの名無しさん：04/02/16 19:36

>>853
小さい数で手計算したほうがよくわかると思われ。

855 ：デフォルトの名無しさん：04/02/16 22:23

Ruby ﾏｼﾞｵｽｽﾒ。

856 ：デフォルトの名無しさん：04/02/16 22:54

D言語まじで楽しい。初心者には触らせたくない。

857 ：デフォルトの名無しさん：04/02/16 22:56

ActiveBasicとかひまわりとか。

858 ：デフォルトの名無しさん：04/02/16 23:40

フローチャートやると駄目なプログラマになるぞ。20年も前から言われている話だ。
もっと良い記法を遣え。

859 ：デフォルトの名無しさん：04/02/16 23:45

> もっと良い記法を遣え。
例えば？

860 ：デフォルトの名無しさん：04/02/16 23:51

FAってファイナルアンサーの略ってことでFA?

861 ：デフォルトの名無しさん：04/02/17 00:20

フロー書くよりモデリングした方が勉強になると思うが。
問題領域を分けることの方がプログラマには重要と考えるんだがどうか。
リファクタリングも一種のモデリングだしね。

862 ：デフォルトの名無しさん：04/02/17 00:37

高級言語にはフローチャートもアクティビティー図もいらんのですよ。
偉い人にはそれがわからんのです

863 ：デフォルトの名無しさん：04/02/17 00:51

>>859
アルゴリズムの手続き的記法ならPADがいいと思うよ。
フローチャートなんて馬鹿になるための道具のようなものだ。

864 ：デフォルトの名無しさん：04/02/17 03:39

フローになるような長いメソッドなど書かない。
つーか、フローなんぞ何の役に立つんだ？

865 ：デフォルトの名無しさん：04/02/17 03:48

http://＿|￣|○

866 ：デフォルトの名無しさん：04/02/17 03:49

http://_|￣|○/

867 ：デフォルトの名無しさん：04/02/17 10:19

>>860
PC-9801FA

868 ：デフォルトの名無しさん：04/02/17 12:31

>>867
16MHzの486だったっけ？

869 ：デフォルトの名無しさん：04/02/17 14:37

このスレって結局

タイプ1: BASIC/Pascal/Cなどで育って来て、OOを覚える前にこれらをやれという奴(年配かつ一番人口が多い)
タイプ2: タイプ1に反発してC++を最初にやることを薦める奴
タイプ3: Javaでしょ、Javaに決まってんじゃん(年少)
タイプ4: Lispの最強を信じて疑わない奴
タイプ5: 突如としてマイナー言語を叫ぶ奴

だよな。
ちなみに漏れはタイプ4w

870 ：デフォルトの名無しさん：04/02/17 15:34

俺も、Lisp最強に異存はないけど、初心者が習うといいとは思えんのだけどな。

871 ：デフォルトの名無しさん：04/02/17 15:51

Rubyを薦めている人はどれに当てはまるの？
あと、JavaScriptも。

872 ：デフォルトの名無しさん：04/02/17 16:37

まじレスなんだけどCじゃGUIなプログラム書けないんですか？

873 ：デフォルトの名無しさん：04/02/17 16:42

かけるよ。
Cに拘りたいなら、猫でも分かるプログラミングとかみるといいかもよ。

874 ：デフォルトの名無しさん：04/02/17 16:56

>>872
VBがない頃はみんなC+SDKでゴリゴリ書いとったんじゃ。
その頃バイブルと呼ばれてたのが「プログラミングWindows」

875 ：高校生：04/02/17 17:15

C/C++初めて半年、
VS.NET ｱｶﾃﾞﾐｯｸ買ったら、VBとC#もついてきた。
VBは覚えることが多そうで、とても自分には無理。

CやC++が一番分かりやすいな
MFC使えない。

で、結局SDKをゴリゴリ書いている変わり者です。

みんなどういう言語から始めましたか？
漏れはHSPですが、あまりにもgoto文を多用する読みにくいソースになるので、やめました。

友達もHSPから入ったといっていました。
で、今はもっぱらPHPらしいです。

漏れはHTMLを書けないし、当然PHPも知りません。
その友達に「Cの方が分かりやすい」と言ったら、
「まったく分からん」と切り返されました。

こういう争いって不毛ですね。

876 ：デフォルトの名無しさん：04/02/17 17:59

>>873 >>874
サンクス。Cの参考書ひととおりやってみたんですけど、GUIアプリ
作ってみたくなったもので。

linux なら eggx/procall っていうライブラリがあるみたいです。
手軽に出来そうなんでチャレンジしてみまつ。

877 ：デフォルトの名無しさん：04/02/17 21:05

上の方でJavaScriptから入門したって人が何人かいたけど
あれってそんな簡単か？本屋に売ってるサンプル集みたい
のからコピペするんじゃなくて、ちゃんと言語として学ぼ
うとすると、これで入門するのは結構難しいと思うんだが。

878 ：デフォルトの名無しさん：04/02/17 21:21

>>875
>VBは覚えることが多そうで、とても自分には無理。
>
>CやC++が一番分かりやすいな
>MFC使えない。
>
>で、結局SDKをゴリゴリ書いている変わり者です。
SDKゴリゴリやってるなら、決まった処理（GUIとか）を
自分でクラスライブラリにまとめていくと、
MFCと多かれ少なかれ同じようなものが出来上がる。
もうちょっと進んでてもWinFormsみたいにしかならない。

そこまで来ると、覚えることなんかない。
作ったらそういう風にしかならないって分かるから。

879 ：デフォルトの名無しさん：04/02/17 21:29

最近 JavaScript でコードを組む機会があったんだが
すごい書きづらかったよ。初心者に薦めちゃいけないね。

880 ：デフォルトの名無しさん：04/02/17 21:35

初心者ならHTML

881 ：デフォルトの名無しさん：04/02/17 23:19

>>869-870
Lisp 最強な人は Haskell をどう思っていますか？

882 ：デフォルトの名無しさん：04/02/17 23:36

なんだかここのHaskell厨に触発されて
ちょっといじってみたくなっちゃった。

883 ：デフォルトの名無しさん：04/02/17 23:48

>>881
869 でも 870 でもないし、別に最強とも思ってないが、一応 Lisper なので
狂信者じゃない Lisper の意見を述べておこう。Haskell はデフォルト Lazy
というかなり思い切った選択がカコイイと思う。関数型も徹底してるし、純粋～型
のフレーズもｶｺｲｲと思う。もしデフォルト Lazy が正しい事ならば今後 Lisp
もそっちに走るかもね。個人的に最強は C なのだが最近出番がなぁ…。

884 ：デフォルトの名無しさん：04/02/17 23:48

List Comprehension, Pattern Matching は良いよね。
強い型付けとか、副作用の括りだしは嫌がる人もいるんじゃないかな。

885 ：デフォルトの名無しさん：04/02/18 00:04

内包表記とパターンマッチはいろいろ Lisp 用の実装があるよね。
強い片付けというか、型推論装備の Lisp 処理系は……一応あるけど
流行らなかったね。見事に。型が好きな人は Haskell いいんじゃないかな。

886 ：デフォルトの名無しさん：04/02/18 00:24

Ruby から始めた方がいいだろ。OO だし。
関数型とか学者向けだが実用向けではないな。

887 ：デフォルトの名無しさん：04/02/18 00:58

いろいろ見てみると確かに関数型って隙無しって感じなんだけどどうして流行らないんだろうか。
効率の良いソースは書けるが、一般的な人間の思考と直結していないから？
単純に言うと難しいってことか？

888 ：デフォルトの名無しさん：04/02/18 01:20

初心者です。
型付けが強い言語の利点、弱い言語の利点を教えてください。
型付けの強い言語の利点はエラーチェックくらいしか思いつかないのですが・・・
それすら如何様にも埋められそうです。
asertやUnitTest、リファクタリングなどで。
XPはSmalltalk文化の中で生まれたと聞いて、ある程度納得しました。
型付けの弱い言語だからこういう技術が生まれたんだなと。

889 ：デフォルトの名無しさん：04/02/18 01:28

>>887
このご時世に至っていまだに、OOは「基本」（手続き型）のあとにやれ、
とか言うヤシがいるくらいだから、みんな保守的なんだよ。
あと、そういう連中ばっかの世の中では、難しいというのは、肯定せざるを得ないかも。

890 ：デフォルトの名無しさん：04/02/18 01:31

>>888はネ初心者。
でも世の中のシステムがどう作られてるかについては本当の初心者のようだ。

891 ：デフォルトの名無しさん：04/02/18 01:38

最近Javaやりはじめました
関数とメソッドの違いってなんですか？

892 ：デフォルトの名無しさん：04/02/18 01:40

Javaじゃみんなメソッドだ。気にするな。

893 ：デフォルトの名無しさん：04/02/18 01:47

>>890
説明をお願いします。
自分はプログラミングをほとんどしません。
ただ、この分野は好きなので本は結構読んでいます。
なので指摘の通り世の中のシステムの作られ型は疎いと言うより本当に知らないといった方が良いかもしれません。
工数的な問題でやはり、型付けの強い言語の方がより早く問題を見つけやすいと言うことでしょうか。

ちなみに本はここから、ソフトウェア工学系の本を漁って読んでいます。
http://www.1point.jp/~book_2ch/

言語はC、Java、JavaScript、WSH、を軽く読んでいます。
興味がある言語は Lisp、Haskell、Smalltalk、Python、Perl。

こんな感じの初心者です。
頭でっかちでお恥ずかしい。

894 ：デフォルトの名無しさん：04/02/18 01:47

メソッドはオブジェクトの「機能」。
C++ではCを引きずって面罵関数と呼んでるだけ。

895 ：デフォルトの名無しさん：04/02/18 01:49

>>888
型大好きな人の意見としてきいてくれ。

> 型付けが強い言語の利点
(1) エラーチェック
コンパイル時にわかるので発見修正が速く、バグが減る。
この有難味はプログラミングをしはじめれば、
ものすごく注意深いわけではない人には、痛いほどわかる。
結果、実行時にはじめてわかる(かもしれない)のよりも効率がよい。

(2) ドキュメント
型を見ることで関数の役割がわかり、読みやすいソースになる。

(3) 設計
型を意識することで思考が整理され、自然とプログラムができていく。。。

896 ：デフォルトの名無しさん：04/02/18 02:08

>>895
お返事ありがとうございます。

> (1) エラーチェック
これはやはり色々埋め込まなくてもエラーを検出してくれるのでフットワークが軽いですよね。
ただ、ここで弾いてくれるのは型の違いくらいだと思うので自分的には結構どうでも良いかなとか思っています。
実戦経験がほぼ皆無なので甘い考えかも知れませんが・・・

> (2) ドキュメント
これは命名規則でカバーできると思いますが如何でしょう。

> (3) 設計
これは少し言っている意味がわかりませんでした。

897 ：890：04/02/18 02:18

直接的な事は、>>895が大体言っているが、その意味を理解するにあたって重要なのは、
実システムでバグは多大な損失となること、
世の中の実システムのコードの大半は、大したスキルのないPGが
納期に追われて血と共に吐き出したものということ。

898 ：デフォルトの名無しさん：04/02/18 02:23

>>897
短い期間である程度の信頼性を保証したものを作れると言うことでしょうか。
要約すると「鉄火場に強い」という。

899 ：デフォルトの名無しさん：04/02/18 02:23

> 実システムでバグは多大な損失となること
まあ、これに尽きるな。時として新聞沙汰になったり人の首が飛んだり。
低コストでそれなりの効果あるものを使わない手はない。

900 ：デフォルトの名無しさん：04/02/18 02:27

逆に、
「長い期間」があったらどうできるというのか、
「色々埋め込む」ってなにを埋め込むのか、
そっちを知りたい。

901 ：デフォルトの名無しさん：04/02/18 02:27

型チェックがある場合、とにかく型を間違っていればコンパイルが通らないので、
少なくともプログラム上想定していない間違った型に対して演算するという事態は避けられる。

・・・ということにしておこう。

902 ：デフォルトの名無しさん：04/02/18 02:35

>>900
asert、ガード節を埋め込む、UnitTestの粒度を小さくするなどが考えられると思います。
型以外の問題（ロジック的なものなど）もとらえられると思うので自分的には型付けは強くなくても良いのかなと思った次第で。

また、型付けが弱いと動的分類を使えるケースが出てくるので問題領域をモデリングした結果を
そのまま、プログラムのモデルに適用できるというメリットもあると思います。

903 ：デフォルトの名無しさん：04/02/18 02:38

>>893
C/C++ とか Java とかの、型付けの扱い方が壊れている言語を見ているだけだと
利点より欠点が目立ってしまうと思う。

古い言語だと Pascal、モダンな言語だと Eiffel あたりを見てみるといいかも。

本から入る性質なら、

「オブジェクト指向言語のはなし」
http://www.amazon.co.jp/exec/obidos/ASIN/4894711885/249-1549964-6746710

あたりがお勧め。

904 ：デフォルトの名無しさん：04/02/18 02:38

>>896

> (1) エラーチェック
..
> 実戦経験がほぼ皆無なので甘い考えかも知れませんが・・・
そうです(きっぱり)。

> > (2) ドキュメント
> これは命名規則でカバーできると思いますが如何でしょう。
プログラマが型を定義するので、型情報を伝えるには全ての関数が、
dosomething_receive_MySomeDataType_FooClass_BarClass_return_FooFooCompany
といった感じになりますが…

> > (3) 設計
> これは少し言っている意味がわかりませんでした。
(2)とも関連しますが、プリミティブ型しか考えてないのではないですか。
型(データ構造、クラス)を定義し、その間の関係(関数)を
定めることが設計でもあるのです。

905 ：890：04/02/18 02:46

> asert、ガード節を埋め込む、UnitTestの粒度を小さくする
これは静的チェック（必ず保証される）の代替にはならないよね？

> 型以外の問題（ロジック的なものなど）もとらえられると思うので
それは当たり前のことで、もともと直交するものだからね。これはこれ。

>>903がなにやら詳しそうだが、壊れてるってどゆこと？キャストが許されること？

906 ：デフォルトの名無しさん：04/02/18 02:49

なんか

知識だけのヒッキー VS 年中デスマーチなデジドカ二人

な戦いになってきたな（藁

907 ：デフォルトの名無しさん：04/02/18 02:54

>>903
そういう観点もあるね。
オブジェクト指向でなければ、Haskell,ML。

型づけを無意味にするキャストなんてものはないし。
型システムが十分に強力でないと制限になってしまうのは確か。
Haskellはtype classもあるし、かなり強力。

同じ様なことの議論
> http://www.xoltar.org/misc/static_typing_eckel.html

908 ：デフォルトの名無しさん：04/02/18 03:10

おいおい、壊れてるっつうのと、ショボいっつうのは、全然違うぞ？
その辺、理解してる？ >>903

909 ：デフォルトの名無しさん：04/02/18 03:10

>>904
> プログラマが型を定義するので、型情報を伝えるには全ての関数が、
> dosomething_receive_MySomeDataType_FooClass_BarClass_return_FooFooCompany
> といった感じになりますが…
すみません、言葉が足りませんでした。
自分はソースをドキュメントの用に読みやすく書くには型情報はあまり必要ないと思っています。
必要なのはその意味合いとスコープでは無いでしょうか。

> (2)とも関連しますが、プリミティブ型しか考えてないのではないですか。
プリミティブ型というのは型のある言語の概念だと思います。

> 型(データ構造、クラス)を定義し、その間の関係(関数)を
> 定めることが設計でもあるのです。
設計とはドメインの切り分けだと思っています。
また設計にも種類が２種類あると思います。
この２種を１種にする壁が型にあるように思うのです。
最近マーチン・ファウラーという方の書いたアナリシスパターンという本を読んでそう実感しました。
ある程度はMDAのツールなどが穴を埋めてくれるとは思いますが。

>>905
> > asert、ガード節を埋め込む、UnitTestの粒度を小さくする
> これは静的チェック（必ず保証される）の代替にはならないよね？
必ず保証はされませんね。
ここら辺は見通し、簡便性、動的分類とのトレードオフだと思っています。

910 ：デフォルトの名無しさん：04/02/18 03:13

>>908
壊れているというのはプリミティブ型という特殊な存在のことを意味していると思います。
型としての扱い方が変わってきますから。
「統一的」という観点から見ると「壊れている」でいいのでは無いでしょうか。

911 ：デフォルトの名無しさん：04/02/18 03:26

>>909
是非>>907のリンク先を読んでくれ。

あと、>>907にも書いてあることだが一点、
静的な型づけができることは動的な型が使用できないことをいみしない。

912 ：デフォルトの名無しさん：04/02/18 03:27

>>911
s/>>907にも/>>907のリンク先にも/

913 ：デフォルトの名無しさん：04/02/18 03:34

>>911
> 是非>>907のリンク先を読んでくれ。
すみません、英語苦手なんで今から読む根性はありません。
明日には読ませて頂きます。

> 静的な型づけができることは動的な型が使用できないことをいみしない。
オブジェクトコンポジション以外に方法があるでしょうか。
また、オブジェクトコンポジションを使ったとしてもそれが動的分類と言えるとは思えません。

914 ：デフォルトの名無しさん：04/02/18 03:37

それから興味本位なんですがみなさんどれだけの言語のソースが読めますか？

915 ：デフォルトの名無しさん：04/02/18 03:48

> ここら辺は見通し、簡便性、動的分類とのトレードオフだと思っています。
バグは見通せないところに発生する。
簡便性って、それで失うところがあれば手抜きとも。
動的分類は、そういうモデリングのメリットがいまいち見えない。属性抽出がどう悪いのかよくわからんし。
そもそも、モデルとして何かが保証されるわけじゃないんだよね。単に何でもありなだけで。
そんな訳で、世の中このトレードオフで特定の一方がよく採用されているのだと思われ。

916 ：デフォルトの名無しさん：04/02/18 03:54

200K行位。
現場で実用には、
読むだけじゃ意味ないしライブラリやTipsノウハウの修得も要るし、
C,++,Java,Perlの内の2,3つうのが大半では？
ただし、MS曰く、VBのみ、が最多のようだがｗ

917 ：デフォルトの名無しさん：04/02/18 04:21

>>915
もし、型が違っていたのなら、UnitTestを正しく通らないでしょう。
またメソッドもその責任の範囲を十分に狭くしてあればその発見も容易だと思います。
シンプルさはそのまま信頼性に繋がっていく可能性もあります。
動的分類についてですが>>907のリンク先のように静的にインターフェースとオブジェクトが繋がってしまっている場合
動的な変更に対応させるには、オブジェクトコンポジションを使ってビジターパターンなどで
対処するしかありません。
その分ソースは複雑になり、バグが生まれる余地が増えます。
トレードオフとしては悪くないと思いますが如何でしょう。

ただし>>898は事実だと思います。
使い分けなんでしょうね。

>>916
なるほど。
となると、自分の読める言語はゼロになったり・・・
VBはあの「コンポーネント思考」が受けたんでしょうね。
複雑なことをするとかえって工数が掛りそうですが、簡単なことなら本当に簡単そうですし。
あと、VBA、VBSなどと絡めたのも功を奏したのでしょう。

918 ：デフォルトの名無しさん：04/02/18 05:14

>>917
>>907はちゃんと読めてる？
>> もし、型が違っていたのなら、UnitTestを正しく通らないでしょう。
> ... in return the compiler saves you from writing pages and pages
> of tests (which also need to be debugged, and maintained) just
> to ensure you're not trying to do something silly like take the
> square root of a hash table.

> ... an exception may be thrown at runtime, or (as in the gunfight) there may be no exception,
> ... there may well be no way to write a unit test for this error!

919 ：デフォルトの名無しさん：04/02/18 05:15

> if I'm going to be working with objects that are conceptually related,
> why not relate them explicitly with a type, to let the type checker help
> me write less code and fewer trivial tests?

> So if you really need to do something unusual and difficult, a static type
> checker won't stop you. The other 95% of your program that doesn't need to do
> strange and magical things gets the benefit of type checking, which means you
> can concentrate your attention on the interesting part.

> 動的な変更に対応させるには、..
> その分ソースは複雑になり、..
そうは思わないが。自分でNice/Haskell/OCamlで書いてみてから言っては？
それに、HaskellもOCamlもOOPLじゃないんだが。

920 ：919：04/02/18 05:27

>>919
OCamlがOOPLでないというのは不適当だな。

921 ：デフォルトの名無しさん：04/02/18 08:21

動かしてみないと判らないエラー(たとえ自動化された単体テストで判ったとしても)より、
コンパイル時にわかるエラーが2兆倍マシだ。それだけでも静的型システムは有用。
動的分類は分析時に有効だろうが、実装段階でどこまで必要なのだろう。ただの混乱のたね。
現場に期待しすぎ。

922 ：デフォルトの名無しさん：04/02/18 09:32

>>917
> またメソッドもその責任の範囲を十分に狭くしてあればその発見も容易だと思います。
個々のメソッドだけ見通せばよい訳じゃないよ。プログラムはそれの無数の*組み合わせ*だからね。
個々のメソッドだけ個々に見通せてもプログラムは見通せない。
それにテストはバグの存在は証明できても非存在は証明できないよね。
メソッドを小さくUnitTestをたくさんというのは、よいプラクティスであっても、
そうであればよい、というものではないよ。高い必要と十分を取り違えてはいけない。

923 ：デフォルトの名無しさん：04/02/18 09:37

動的分類って
http://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/index.html
に書いてあるようなこと？かなり意味不明だけれど。
> 次の瞬間にそのオブジェクトはまったく別のクラスのオブジェクトに変化しているかもしれない
これが動的にコードを書き換えるというLisp的な意味なら、
ダイナミックタイピングでもほとんどの言語はそんなことはできないし、
コンパイルし直していいというなら、論理的にはこんなこと
> 強い型付け言語では、宿命的に動的分類はサポートできないと言って良いでしょう。
にはならない。単にC++/Javaの型がしょぼいだけ。

既存のクラスに手を加えないで、
それと同じメソッドを持つクラスを定義して同じ様に扱いたい、と言う意味なら、
> http://www.xoltar.org/misc/static_typing_eckel.html
のNiceの例がやってることそのものだと思うんだが。

924 ：デフォルトの名無しさん：04/02/18 09:40

>>889
OOPLをやる奴はOOをやりながらが正解なんだろね。
全くの別物だから、片方をやっても片方しか上手くならない。
たぶん教育、学習が困難である原因は他のところにある。

925 ：デフォルトの名無しさん：04/02/18 09:41

> コンパイルし直していいというなら、
動的って意味分かっててそういうこという？

926 ：デフォルトの名無しさん：04/02/18 09:48

>>925
いや、わかってないから聞いてる。
例えばRubyとかPhythonは動的型付けだが
走らせながらオーバーライドしたりできないと思うんだけど？

927 ：926：04/02/18 09:53

PhythonでなくてPythonね。

928 ：デフォルトの名無しさん：04/02/18 10:02

動的ってのは単純に単一の実行中にって前提でしょ。
Rubyとかよくしらんけど特異メソッドとかは違うの？

929 ：デフォルトの名無しさん：04/02/18 10:10

eval で既存のクラスのメソッドの再定義できるけど
そういうことでなく？

930 ：デフォルトの名無しさん：04/02/18 10:16

>>928
> 動的ってのは単純に単一の実行中にって前提でしょ。
つまり、動的分類ってのは、
コードを付け加えたり書き換えたりするために「実行を止めることが許されない」ような
システムをつくるときに役立つということ？

そんなの物凄くレアケースだよね。
しかもタイピングは必要(と思われる)条件であるにすぎず全然十分条件ではないような。

> Rubyとかよくしらんけど特異メソッドとかは違うの？
それっぽいね。使ったことなかった(Ruby自体ほとんどやってない)。
少なくともPerlはできなかったとおもうんだが…

931 ：デフォルトの名無しさん：04/02/18 10:49

>>928
動的分類のメリットはインテリ氏に聞いてくれ。
たぶん、おまいの言ってるのは視点自体外してて、
特定のモデルが直感的になるっつーことかと。
元々赤ん坊だった人間Aが、学生になり、無職になり、ホームレスになる、というのを
Aという一つのオブジェクトで表すのにどうするか、ということだろうが、
最初から人間と属性に分けて考えれば問題ないと思われ。

>>915
メソッド単位じゃなくて動的なMIX-INがあれば、モデルとしてもサポートしてると言えるかな。

932 ：930：04/02/18 10:53

>>930多分違うね。あらかじめどういうクラスがありうるかは分かっていて、
実行時に条件分岐でオブジェクトの属するクラスが変わるのが動的分類のようだ。
そして、
C++/Javaだと継承関係にあるものぐらいしかRTTIで分岐できないことが問題なのかな。

でもそれならまさにC++/Javaの型システムがしょぼいというだけのことだし…

933 ：デフォルトの名無しさん：04/02/18 10:54

> > Rubyとかよくしらんけど特異メソッドとかは違うの？
> それっぽいね。使ったことなかった(Ruby自体ほとんどやってない)。
> 少なくともPerlはできなかったとおもうんだが…
だからRubyは今どきの純粋OOスクリプトなの。
Perlみたいなカビの生えた腐ったウンコと一緒にすんな。
…とRuby厨ぶってみる。Ruby書けないのにｗ

934 ：930：04/02/18 10:55

>>931
かぶったけど、そうみたいだね。
要するに一つのオブジェクトで表さないと行けないような
しょぼい型システムは不便だとインテリ氏は言ってるだけなんだよね。

935 ：デフォルトの名無しさん：04/02/18 10:57

930は分裂している。。

型直指定や継承以外のRTTI判別ってどういうの？

936 ：デフォルトの名無しさん：04/02/18 11:00

あと、それで、静的型チェックと動的分類がどう整合するの？

937 ：930：04/02/18 11:06

>>935
要は実行時に型情報を得られるダイナミックな型(の集合)があればいいわけでしょ。
それがその言語上の継承関係である必要はない。
ダイナミックタイピングの言語のObjectは全て一つのObjectからの派生であるという
立場なら、上記のダイナミックタイピングの集合に属することがなにかを継承してい
ることになるだろうけど、それはどう解釈するかだけの問題。

938 ：デフォルトの名無しさん：04/02/18 11:08

いやそうではなくて、
　型直指定や継承だけのRTTI判別がしょぼい
ということなら、立地なのはどんなの？と。あと>>936。

939 ：デフォルトの名無しさん：04/02/18 11:09

>>936
もちろん、ダイナミックな型の集合についてはそれなりの型チェックしかできないよ。
でもそのような処理の部分以外では静的型チェックが使える。
ダイナミックしかないよりずっといい。

940 ：デフォルトの名無しさん：04/02/18 11:12

>>938
> ということなら、立地なのはどんなの？と。あと>>936。
立地なのって？

>>931のような制限が問題なんでしょう？だから、
ひとつの継承関係にある必要がない、
> 要は実行時に型情報を得られるダイナミックな型(の集合)があればいいわけでしょ。
と書いてるんだけど。

941 ：デフォルトの名無しさん：04/02/18 11:18

立地（rich）ってのは、継承以外の
> 実行時に型情報を得られるダイナミックな型(の集合)
ってどんなの？ってこと。

942 ：デフォルトの名無しさん：04/02/18 11:24

>>941
どんなのでもいいよ。
型がdynamicであるかどうかを指定できるようにするだけ。
>>931の例でいえば、
dynamic class 学生 { ... }
dynamic class ホームレス { ... }
dynamic class 無職 { ... }
...
typeID getTypeID(dynamic class x)

というようなこと。

943 ：デフォルトの名無しさん：04/02/18 11:27

DQNですまんが、
これで何が静的保証されるの？
静的保証世界に穴があけることを言ってるように思えてしまうのだが。

944 ：デフォルトの名無しさん：04/02/18 11:31

>>943
>>919の
> So if you really need to do something unusual and difficult, a static type
> checker won't stop you. The other 95% of your program that doesn't need to do
> strange and magical things gets the benefit of type checking, which means you
> can concentrate your attention on the interesting part.

静的型システムでは、それ以外のところでは依然として穴がないままで、
「どうしてもあけたい」ところにだけ穴を部分的に開けられる。
と言ってるんだけど。

945 ：デフォルトの名無しさん：04/02/18 11:33

なにかを保証したつもりのグループを定義できて、
グループに属す属さないは面倒見てくれるよ、ってこと？
でも「なにか」が本当に保証されているかどうかは関知しない、って感じ？
それは、強い型付けならJavaのinterfaceで十分じゃないの？

946 ：デフォルトの名無しさん：04/02/18 11:38

>>945
それで>>923の3段落目にもどると…
JavaのInterfaceではこういうことができないと下のリンク先のページに書いてある。
おれはJavaは良く知らないから、読んで自分で判断してくれ。

> 既存のクラスに手を加えないで、
> それと同じメソッドを持つクラスを定義して同じ様に扱いたい、と言う意味なら、
> http://www.xoltar.org/misc/static_typing_eckel.html
> のNiceの例がやってることそのものだと思うんだが。

947 ：デフォルトの名無しさん：04/02/18 11:38

>>944　なるほど。
とすると、目指す方向性、ポリシーの違いであって、
強い型付けに穴をあけられないのが型機能としてしょぼいっつうのは、違うんじゃね？

あと動的分類は、
Human a= Human.new
Baby b= a.became(Baby.class)
Student s= b.became(Student.class)
Homeless h= s.became(Homeless)
が可能か、というのも含んでるから型だけで語るのはちょっとややこしいね。

948 ：デフォルトの名無しさん：04/02/18 11:41

>>945
違うような。おれが言いたいのは、
もし静的型付けのシステムで動的型付けを使うなら、
プログラムには静的型付けでできている(95%の)部分と、
動的型付けを使用するほんの少しの部分があるようになる。
ということ。

949 ：デフォルトの名無しさん：04/02/18 11:52

>>947
> とすると、目指す方向性、ポリシーの違いであって、
> 強い型付けに穴をあけられないのが型機能としてしょぼいっつうのは、違うんじゃね？

それはまあそうなんだけど、
「静的型付けはだめだ。なぜなら動的分類ができないからだ」
という「インテリ氏」の主張に、
「それはおかしい。プログラムの大半で静的型付けを利用できて、
    欲しい所だけで動的型付けを使うほうがいいではないか」
といってるだけだから。

> あと動的分類は、
> Human a= Human.new

これは、BabyなりStudentなりに「キャスト」されるときに何が
かわるのかはプログラマが指定しないといけないはずだから、
dynamic_class Human {
    Baby operator=() { ...}
    Student operator=() { ...}
    ...}
となるだけじゃない？
もし指定しなかったらそのまま単に「キャスト」するということにすればいいし。

950 ：デフォルトの名無しさん：04/02/18 11:55

>>947
あと、JavaのInterfaceの話では、Niceっていう言語は
強い静的型付けであってかつ、
> 既存のクラスに手を加えないで、
Interfaceが追加できるような型システムらしいよ、っていうことね。

951 ：デフォルトの名無しさん：04/02/18 12:18

>>950
一種の構文糖だね。静的にやる必要があるという本質はJavaのinterfaceと変わらないんだよね。

952 ：デフォルトの名無しさん：04/02/18 12:27

つうか、強い型付けだって、動的分類できるでしょ。
Human a= Human()
Baby ababy= Babyness.of(a)
で。
どうせ、弱い型付けでも赤ん坊かどうかはチェックするんだし、
HumanとBabyの関係が宣言的にならないけど、弱い型付けだって同じ。

。。。ちょっと無理あるかなぁ。。

953 ：デフォルトの名無しさん：04/02/18 12:50

もっといい型システムなら静的なままC++/Javaのような制限がはずせる、
という話と、
どうしても静的ではできないときなら動的な型を使えばいい、
という話が並行してるのがちょっと混乱を招いている感じ。

954 ：デフォルトの名無しさん：04/02/18 12:52

>>952
Baybyness.of(a)の型は？
aがHumanの派生型しかとれないんだったら動的分類とはいえないんじゃないの。

955 ：デフォルトの名無しさん：04/02/18 13:00

Human aがBaby ababyになってるのが味噌で、それが
動的分類じゃないと言われうるのはそうだけど、
> どうせ、弱い型付けでも赤ん坊かどうかはチェックするんだし
ってことで目を瞑ってもらえんだろうか。

>>953
後者はわかったから前者に興味あり。

956 ：デフォルトの名無しさん：04/02/18 13:10

須磨。ちょっと話がぶれてるが、↓。BabyとHumanの関係は宣言的だわ。
class Human{ }
class Baby extends Human { static Baby babynessOf(Human h){..} }

Human a= Human()
Baby ababy= Baby.babynessof(a)

957 ：デフォルトの名無しさん：04/02/18 13:18

babynessOf(Human h)は弱参照でhのテーブルを持ってて、そのBabyが既成ならそれを返す。

958 ：デフォルトの名無しさん：04/02/18 13:28

>>955
例えば、独立した二つのclass Aとclass Bがともに、
意味的に同じあるメソッド(例えば、足し算)をもっているとして、
どちらでも同じ様に呼び出せる(+)を定義したくなったとき。
C++ではテンプレートを使って、同じ記述で別の型用の(+)が生成されるようにする。
なぜなら、C++の型付けではこの2つの(+)を同じ様に扱うことができないから。

Haskellならtype classを利用して
class HaveAdd a where
    (+) :: a -> a -> a

instance HaveAdd A where
    a + a = ... -- a's own definition

instance HaveAdd B where
    b + b = ...

とできる。先にHaveClassとAだけコンパイルしてあっても問題なく自由に
新しくBを追加できるし、+を使う(コンパイル済)の既存の関数はBを扱える。
AやBを使う関数は
f :: (HaveAdd a) => a -> a -> c
という型を持ち、HaveAdd というtype classにしか適用できないので、安全。

959 ：デフォルトの名無しさん：04/02/18 22:55

動的分類のサポートとは関係なさそう。
面白そうではあるがね。

960 ：デフォルトの名無しさん：04/02/18 23:30

>>900
長い期間があっても、結局なにもできないでしょ。
だから、現実問題としてスキルの余りない納期に追われてる PG でも、
なるべくバグの無いものを作れる言語がいいとは言えるのでは。
答えになってないけど。スレタイとも少し違うし。。

961 ：デフォルトの名無しさん：04/02/18 23:36

まぁ、つまりあれだ。
A)「プログラムの大半で静的型付け、欲しい所だけ動的型」
B)「プログラムの大半を動的型付け、欲しい所だけ静的型」
C)「動的型のみ」
D)「静的型のみ」
くらいの分類でいいだろう。A) が Haskell とか ML, B) が Lisp
C) がスクリプト言語ってところか？

962 ：デフォルトの名無しさん：04/02/18 23:38

お前らこれをもっと読んで理解してから書き込めよ
ttp://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/C3_3.html

963 ：デフォルトの名無しさん：04/02/18 23:42

>>962
そこにはSmalltalkで動的分類を表現できると言っているけどアレってクラスベースじゃ無かったか？
本当に動的分類が活用されるにはせめてプロトタイプベースじゃ無いと駄目なような気がするが。
それとも、リフレクションでどうにかなる？
Smalltaklはクラス自体もオブジェクトだから型すら動的に作れるのかな？
ようワカラン。

964 ：デフォルトの名無しさん：04/02/18 23:47

動的分類が話題になっているけど、多重分類が実装できる言語って何がある？
MixJuice の差分ベースモジュールが近い感じなのかなあ

965 ：デフォルトの名無しさん：04/02/19 00:00

>>961
HaskellがどうしてA)なんだ????

>>963
動的にクラス定義が変えられれば一応はOKでしょ。

>>964
だから、動的にオブジェクトがもつメソッドを変更できる言語ならOKでしょ。
SmalltalkとかRubyとかNewtonScriptとか。
> MixJuice の...
漏れは上の英語のページのNiceとかいうのを見てMixJuiceを連想した。

というか、インテリ氏は現場の低能さに
驚愕してどっかに逝ってしまいましたねぇ。

966 ：デフォルトの名無しさん：04/02/19 00:03

>>962
静的型でも、>>956が図5に合いそうと思うけど。

967 ：961：04/02/19 00:13

>>965 間違えた。ｽﾏｿ。

968 ：デフォルトの名無しさん：04/02/19 00:16

>>964
多重分類はHaskellのtype classでできる。

>>965
> HaskellがどうしてA)なんだ????
Data.Dynamic

969 ：デフォルトの名無しさん：04/02/19 00:18

>>965,>>967
どうしてAでないんだ？

970 ：デフォルトの名無しさん：04/02/19 00:25

このｽﾚで関数型に興味を持って Clean ｽﾚを除いたら一発で嫌になりますた。

971 ：デフォルトの名無しさん：04/02/19 00:47

Haskell なんでもありだなｗ
>>980次スレヨロ

972 ：デフォルトの名無しさん：04/02/19 01:10

多重分類を実装できる言語は名前空間の問題をどういう風に解決しているんだろう。
結果的に多重分類になるなら用意されていないと思うが、意識して作られているなら
回避する仕組みもあるように感じるのだが。

973 ：デフォルトの名無しさん：04/02/19 01:38

>>958は、JavaでもTigerなら↓こんな風に出来ないの？抑止ランケ度。

interface HaveAdd<T>{ T add(T t1); }
class User{ <U extends HaveAdd<U>> U hoge(U a, U b){ return a.add(b); } }
class A implements HaveAdd<A> { A add(A a){...} }

class B implements HaveAdd<B> { B add(B b){...} }

974 ：デフォルトの名無しさん：04/02/19 01:43

>>895
> > 型付けが強い言語の利点
> (1) エラーチェック
> コンパイル時にわかるので発見修正が速く、バグが減る。
> この有難味はプログラミングをしはじめれば、
> ものすごく注意深いわけではない人には、痛いほどわかる。
> 結果、実行時にはじめてわかる(かもしれない)のよりも効率がよい。
>
> (2) ドキュメント
> 型を見ることで関数の役割がわかり、読みやすいソースになる。
>
> (3) 設計
> 型を意識することで思考が整理され、自然とプログラムができていく。。。

こいつ馬鹿？ｗ
エラーチェックは解らないわけでもないが（それでもオーバーすぎ）
ドキュメントで型ってなぁｗ
リファレンスならまだしもドキュメントとしてなら分かりやすい変数、関数の名前付けがあれば
流れが読めるだろ。
また、リファレンスはTestプログラムが相当するしな。
設計に関しては、もうアフォかと。
モデリングの勉強し直せ。
まじ、現場がこんなヤツばかりだと思われると鬱になる。

975 ：デフォルトの名無しさん：04/02/19 01:43

型付けが便利だから使うって言うのは理解出来るけど、型付けが好きって言うのはどういう
感覚なんだろうか。想像もつかない。

976 ：デフォルトの名無しさん：04/02/19 01:45

>>973
だからそれは動的分類じゃn(ny

977 ：デフォルトの名無しさん：04/02/19 01:58

>>974
> ドキュメントで型ってなぁｗ
type inferenceのできる言語では常識なんだが。
土方は黙って自分の仕事だけやってろ。

978 ：デフォルトの名無しさん：04/02/19 02:06

>>977
アホですか？
ドキュメント性であって、ドキュメントそのものでは無いだろ。
必要な部分だけの最小なコメントだけで十分だ。

979 ：デフォルトの名無しさん：04/02/19 02:07

>>974
>>895は稚拙だが、馬鹿はおまえ。

>エラーチェックは解らないわけでもないが
エラーチェックこそが強い型付けの機能なのに全然分かってなくて反論になってない。

>ドキュメントで型ってなぁｗ
何が入って何が出るかってのは強力な説明足り得る。適切かつ簡潔な名前を強く補佐する。

>設計に関しては、もうアフォかと。
設計で重要なのは、クラスとそれらの関係が整然としていることだ。
変数やシグニチャでクラスがいちいち明示されるのは、
クラスの関係が強く意識されやすく、整理を助ける。

>まじ、現場がこんなヤツばかりだと思われると鬱になる。
ｗ

980 ：デフォルトの名無しさん：04/02/19 02:09

> ドキュメント性であって、ドキュメントそのものでは無いだろ。
脳味噌入ってんだろうか？
まじ、現場がこんなヤツばかりだと思われると鬱になる。

981 ：デフォルトの名無しさん：04/02/19 02:14

>>980
次スレは要らないからな。

982 ：デフォルトの名無しさん：04/02/19 02:16

>>979
> >ドキュメントで型ってなぁｗ
> 何が入って何が出るかってのは強力な説明足り得る。適切かつ簡潔な名前を強く補佐する。
要らない。
「何の型が入っているか」ではなく「何が入っているか」がドキュメント（性）には重要。

> 設計で重要なのは、クラスとそれらの関係が整然としていることだ。
> 変数やシグニチャでクラスがいちいち明示されるのは、
> クラスの関係が強く意識されやすく、整理を助ける。
オブジェクト同士の結びつきと型は別物。
また、モデリングの段階で言語の型を意識するのは実相の方向性を固定化してしまう。

>>980
スレ立てヨロ。
あと、まともなこと少しは言えよ。

983 ：980：04/02/19 02:18

建てますた。かなり最悪なタイミングかもｗ
http://pc2.2ch.net/test/read.cgi/tech/1077124583/

984 ：977 != 979：04/02/19 02:21

>>982
どうしようもないアホだな。あの「インテリ」氏か？
http://www.google.co.jp/search?hl=ja&ie=UTF-8&oe=UTF-8&q=%22type+inference%22+%22type+annotation%22+documentation&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

985 ：980：04/02/19 02:23

>「何の型が入っているか」ではなく「何が入っているか」がドキュメント（性）には重要。
あのねぇ、型にも名前があるの。
型を明示すればどのようなものかを示すの。そして適切な変数名で具体的な役割を示すの。
それがなんだかわかんないで役割だけあるより、なんだか分かった方がいいに決まってんだろ？

986 ：デフォルトの名無しさん：04/02/19 02:24

次スレ言語にくくらなくても良かったかもな。

987 ：980：04/02/19 02:25

インテリ氏（絵に描いたようなインテリ。知能と知識は高い）と982（真性の馬鹿）の区別が付かんとは。。。

988 ：977：04/02/19 02:28

>>987
そうか？>>917なんてかなりアホさを表しているとおもうんだが。
ただの決めつけと自分の主張への固執。知識はあるが論理がない。