(ヽ´ん`)「プログラムなんていわばifとforと代入の

**デフォルトの名無しさん** · 2018/10/09(火) 12:52:44.06

41 (ﾜｯﾁｮｲWW 9cc6-Jw/P) 2018/10/08(月) 16:23:58.01 ID:lZWfD/j90 (PC)
プログラムなんてどれもifとforと代入の組み合わせだろ
あとは言語的な作法だけ
最小限意識すりゃ誰でもできる

これマジ？

**デフォルトの名無しさん** · 2018/10/09(火) 12:58:59.41

あー

**デフォルトの名無しさん** · 2018/10/09(火) 13:04:09.93

なー

**デフォルトの名無しさん** · 2018/10/09(火) 13:06:02.29

>>1
おおむね合っている。
ただgotoは覚えとかないとだめ。

**デフォルトの名無しさん** · 2018/10/09(火) 13:31:17.37

forはifとgotoで代用できる。

**デフォルトの名無しさん** · 2018/10/09(火) 15:05:47.50

今は言語文法そのものより、フレームワークの使い方が大変だろ
複雑怪奇な役所の手続きに似てる…

あと複雑な事やろうとすると数学の素養がネックになるので学生は勉強しとけ

**デフォルトの名無しさん** · 2018/10/09(火) 15:57:09.55

物質なんていわば陽子（＆中性子）と電子の組み合わせだろ？

**デフォルトの名無しさん** · 2018/10/09(火) 16:17:58.12

作用なんも無しでいいのか

**デフォルトの名無しさん** · 2018/10/09(火) 20:57:07.98

構造化定理について調べなさい
きっといいことがある

**デフォルトの名無しさん** · 2018/10/09(火) 22:44:10.05

>>1
でも、VzEditor の c.mos さんなどが天才だと言われていたように、
凡人には決して達成できなさそうな能力を持つ人もいると思う。

それに、長く考えてもどうやってプログラムしていいか分からない
ようなプログラムも有りえる。

**デフォルトの名無しさん** · 2018/10/09(火) 23:03:16.78

ifを減らすのが美しいんよ
繰り返しもアルゴリズムの工夫で減らしたい
するとパフォーマンス上がる
CPUパワーに任せてやるのは最近の流行だろうが脳が退化すると思うで

**デフォルトの名無しさん** · 2018/10/09(火) 23:04:58.59

まあ誰でもできるってのはそうだと思う
そうやってすそ野を広げたいんだろう　経済的思惑で
でも本職でやっている人は違いを見せて欲しい　どんな職でもそう

**デフォルトの名無しさん** · 2018/10/09(火) 23:05:21.90

といっても1からnまで足すのに
律義にfor文で回すﾔﾂもいる

**デフォルトの名無しさん** · 2018/10/09(火) 23:49:49.69

>>12
でも、どうやれば実現できるか分からないようなプログラムもあると思うよ。

**デフォルトの名無しさん** · 2018/10/10(水) 07:19:13.53

プログラム言語も進化が求められている
なぜなら進化した言語の方が開発効率が良いからだ
言語における進化とはなにか？それはパターンに名前をつけることだ

ifとgotoがあればforの代用ができる
むしろifとgotoでfor以上のことだってなんでもできる。

だが "なんでもできる" は正義ではない。悪だ
ifとgotoでは何がやりたいのか読み取るのに時間がかかる
そこで出てくるのがパターンだ

初期値から終了値まで繰り返すという特定のパターンにforという名前をつける
なんでもできるifとgotoを使ってforを実装する。
そうすることでforと聞くだけでどういうパターンかをイメージすることができる

そうやって "なんでもできる" ものを使って特定のパターン専用のものを
作り出すことこそがプログラム言語の進化

ifとgotoの組み合わせというのは、単なるコンピュータの理論的な仕組みの話であって
プログラミングする上でその小さい単位だけで作っていたら時間はかかるしバグもたくさん生まれる
より多くのパターンを知っていることこそが知的労働者としてのプログラマの技術力であり
新しいことを覚えることが嫌い、知ってることだけで使って時間をかけるというのは無能でしかない

**デフォルトの名無しさん** · 2018/10/10(水) 09:26:09.64

言語の進化は制限の歴史
gotoは使っちゃダメ
グローバル変数は使っちゃダメ
ところかまわずおしっこしちゃだめ

**デフォルトの名無しさん** · 2018/10/10(水) 16:05:08.12

>>1
それはプログラムを見るだけの人の感想
しかもライブラリが一般化する前の古い形で計算も代入に含めるの？って感じ

**デフォルトの名無しさん** · 2018/10/10(水) 20:31:59.27

>>1
間違ってはいない。でも

ぼくはひらがなをしっているのでどんなぶんしょうでもかけます。
僕は平仮名を知っているのでどんな文章でも書けます。

下の方がコンパクトで読みやすいよね

**デフォルトの名無しさん** · 2018/10/10(水) 23:44:36.05

そういう書き方の美しさだけの問題ではなく、そもそもアルゴリズム自体を見出すのが
難しくて実現できないプログラムというものが有りえる。

**デフォルトの名無しさん** · 2018/10/11(木) 00:48:16.35

たとえば、よくある入力パターンでは正しく動作するアルゴリズムは分かったとしても、
そのアルゴリズムがどんな場合でも正しく動作するかは自明ではないことがある。

そういう場合は、まずは、そのアルゴリズムがあらゆる入力パターンに対して、
正しく動作する事を「証明」する必要が出てくる。逆に、正しくないことを「反証」
する必要がある場合もある。

そういうような意味で、かなりの数学的な才能が無いと、正しいアルゴリズムが
発見できない場合がある。

というより、数学が出来ないと、そのアルゴリズムが正しいかどうかはっきりさせる
ことすら出来ない場合がある。

**デフォルトの名無しさん** · 2018/10/11(木) 05:30:12.87

だから自分でアルゴリズムを考えるのではなく
すでに用意されているものを使いましょうとうことになる

ifとforと代入でできているからといって
安易に自分でアルゴリズムを実装しようなんて思ってはいけない

**デフォルトの名無しさん** · 2018/10/11(木) 12:31:59.64

いわばエゴとエゴのシーソーゲームやな

**デフォルトの名無しさん** · 2018/10/12(金) 00:22:32.28

ｱﾎはすでにあるｱﾙｺﾞﾘｽﾞﾑすら
知らないか適切に選択できない

**デフォルトの名無しさん** · 2018/10/12(金) 00:27:33.57

とりあえず代入を甘く見過ぎ。
これでだいたいバグ引き起こす。

**デフォルトの名無しさん** · 2018/10/12(金) 00:28:12.76

>>21
しかし、すでに出来ているアルゴリズムの単純な寄せ集めだけでは、どうやっても実現できえないプログラムもある。

**デフォルトの名無しさん** · 2018/10/12(金) 04:30:56.60

おれwhileしか使わない

**デフォルトの名無しさん** · 2018/10/12(金) 18:29:40.09

if for 配列

**デフォルトの名無しさん** · 2018/10/13(土) 00:00:02.60

おかしな挙動を起こさず正しく動く1行のコードにものすごい悩むこともあるけどな
それに至るまでも何十行と書いて消したりテストしたりしてない

**デフォルトの名無しさん** · 2018/10/13(土) 00:00:23.53

してない→してな

**デフォルトの名無しさん** · 2018/10/13(土) 00:06:08.28

頭悪いとな行き当たりばったりでｺｰﾄﾞを書く

まともなｵﾂﾑがあればｺｰﾄﾞを書くときにすでにｿﾌﾄｳｪｱﾃﾞｻﾞｲﾝが決まってる
なにを書くかｵﾂﾑの中ですでにきまってる
typoのｼﾝﾀｯｸｽｴﾗｰ以外は起きない

**デフォルトの名無しさん** · 2018/10/13(土) 00:20:18.59

そんな理屈通り動くもんばかりなら良いけどね
たまーに理屈と違う挙動することがあるから
フレームワークのバグだったりするんだけども

**デフォルトの名無しさん** · 2018/10/13(土) 00:22:56.97

最近、他人には非公開ということを前提に、あえて、バグや細かい不調和(?)などを
気にせずに、実験的にプログラムを組んでいくやり方をしてみている。

新しいものを作るときにはそっちの方が良いかもしれないと思ったので。

**デフォルトの名無しさん** · 2018/10/13(土) 00:25:51.66

作るものにもよる
自分だけで全部書くような仕事と同じ所を共同で触る仕事とは配慮するポイントが違う

**デフォルトの名無しさん** · 2018/10/13(土) 00:30:43.11

[追加]

・あくまでも完成品ではなく、実験を主目的とする場合の話。

・仕様自体を完全には決めずに色々試しながら仕様を追加してみる。

・全体像が定まってないので、細かいバグや不整合(?)のようなものを完全に
　防ぐことは諦める。

・逆に細かな不具合まで防ごうとすると、ガチガチなプログラムになるので、
　機能追加に時間がかかってしまい、全貌を俯瞰するような実験がやりにくくなる。

**デフォルトの名無しさん** · 2018/10/13(土) 00:32:25.65

期待通りの動作にならないのは
それはﾊﾞｸﾞだ

ｳﾝｺﾌﾚｰﾑﾜｰｸの問題なのか、低学歴知恵遅れのﾄﾞｶﾀの使い方が問題なのか
その問題の切り分けがめんどい

ｳﾝｺﾌﾚｰﾑﾜｰｸなんか滅多なことがないぎり使うもんじゃないわ

**デフォルトの名無しさん** · 2018/10/13(土) 00:33:09.49

あぁウォーターフォール系の開発の話かね
それでマウント取って悦に浸ってたのか、すげえな

**デフォルトの名無しさん** · 2018/10/13(土) 00:35:53.11

信頼性が低くて問題ない分野ではやっすいｼｽﾃﾑでは有効
ちょっとぐらいの不具合なんか問題にしない

当然、作る人間もやすもん

**デフォルトの名無しさん** · 2018/10/13(土) 00:37:46.48

やっすい人間が
薄利ｼｽﾃﾑを大量生産するのに向いてる

**デフォルトの名無しさん** · 2018/10/13(土) 00:41:46.43

それがｳﾝｺﾌﾚｰﾑﾜｰｸの世界
線路の上のｳﾝｺ

**デフォルトの名無しさん** · 2018/10/13(土) 00:47:52.13

[次のようなことを最近思ってる]

# 最終成果物には厳密さが必要だから、以下の話には注意が必要あるが

・厳密さを求めすぎると、創造性が落ちる。
・フロンティア、パイオニアは、完全無比なものを求めると達成しにくいらしい。

**デフォルトの名無しさん** · 2018/10/13(土) 00:56:36.00

頭悪いと期待通りに動作するｺｰﾄﾞが書けない
計算機が厳密に動作するのは当然だからな

求めすぎるということはない
厳密にしか動作しない

どんな条件であっても
頭悪いﾔﾂが書かない限り
厳密にしか動作しない