1: 仕様書無しさん 2021/04/01(木) 23:17:32.70
最初から、はナシで
2: 仕様書無しさん 2021/04/02(金) 02:23:45.69
お前の頭が新しいパラダイムについていけなくなったときから
82: 仕様書無しさん 2021/04/07(水) 12:25:50.42
「現代のプログラミング言語はおかしい」という前提ですから
正直俺の中では>>2で終わってるんだけど
4: 仕様書無しさん 2021/04/02(金) 04:42:56.59
まずa=a+1がおかしい
6: 仕様書無しさん 2021/04/02(金) 09:33:52.42
>>4
その書き方はシンタックスシュガーなんだよ
本来は
LET a = a+1
さらにアセンブラまでさかのぼるとa+1を計算した結果がレジスタに格納され、さらにレジスタからaに戻すという
流れをわりと自然に表現できていることに気づくと思う
しかし今の時代はUIから設計していく時代だ
アセンブラの動きを理解しやすいようにボトムアップで考えていくのは時代遅れだ
つまり
a ← a+1
と書くのが正しい
もしくは
let(a, sum(a, 1))
と書くのがプログラミングの将来にとって非常によい本来の姿なんだ
28: 仕様書無しさん 2021/04/03(土) 08:53:45.67
>>6が最高すぎる
7: 仕様書無しさん 2021/04/02(金) 09:53:35.31
そもそも数学に代入記号がないのが問題
イコールと代入は意味が違う
8: 仕様書無しさん 2021/04/02(金) 10:02:42.84
代入 =
イコール ==、EQ
代入とイコールで同じ記号を使ってる言語ってBASICとCぐらいじゃないの？
10: 仕様書無しさん 2021/04/02(金) 12:32:45.76
>>8
は？Cは比較は==だが？
12: 仕様書無しさん 2021/04/02(金) 15:46:26.53
>>10
B言語だったかC言語の初期だったかは比較がイコール(文脈依存)だったことがある。
でも不便だから後々変わった。
13: 仕様書無しさん 2021/04/02(金) 16:02:11.39
比較をアルファベットで行っていたCOBOLは正しかった
またCOBOLが優秀だと証明されてしまった
14: 仕様書無しさん 2021/04/02(金) 16:56:49.84
1+1=2 という数式が一般の人には難しく
1たす1は2 という言葉のほうが分かりやすいと
思われていた時代があったかもしれないね
24: 仕様書無しさん 2021/04/03(土) 08:22:13.75
=と==を分けて考えることができないのは頭堅すぎるだろ
27: 仕様書無しさん 2021/04/03(土) 08:52:49.72
比較が=は本当に頭おかしいと思う
29: 仕様書無しさん 2021/04/03(土) 10:49:45.91
a=a+1
この場合、aは変数の値を格納しているメモリのアドレスを表現しているんだ
&0x01 = &0x01 + 1;
っていう書き方を省略しているにすぎない
左辺は格納するアドレス、右辺は格納されている値なんだ
a=a+1の左右でaの意味が違っていることに気が付けば違和感の正体がわかるはずだ
67: 仕様書無しさん 2021/04/06(火) 09:41:07.93
キーボードから直接入力できない面倒な記号はダメだろ
68: 仕様書無しさん 2021/04/06(火) 15:42:10.16
>>67
いまどきなら構文解析で整形掛けて=を←に変換だって出来るだろう？
69: 仕様書無しさん 2021/04/06(火) 15:49:47.06
オブジェクト指向言語が現れてから。
プログラムは具体的な処理しかできないのに、
抽象化などという余計なものが入ってきて、
デバッグが難しくなった。
独立性はオブジェクト指向でなくても
十分にあるのに、
クラス分けできないと
独立じゃないなどと馬鹿がウソついて
一気にウンコ言語が拡散した。
オブジェクト指向なんぞウンコ！
汚らわしい！
70: 仕様書無しさん 2021/04/06(火) 15:51:05.67
>>69
コボルのデバッグをお願い。オブジェクト指向じゃないから
お前にとっては簡単なはずだ
75: 仕様書無しさん 2021/04/07(水) 02:19:53.07
>>70
やるよ
簡単だからな
COBOLは最もまともな言語だ
わかんねえだろ？
馬鹿には分からんのだ！
79: 仕様書無しさん 2021/04/07(水) 07:55:23.86
>>70
今のCOBOLはオブジェクト指向言語だよ
78: 仕様書無しさん 2021/04/07(水) 07:05:21.93
オブジェクト指向だな
メリットを誰も説明できない言語
81: 仕様書無しさん 2021/04/07(水) 10:55:08.12
マジレスしちゃダメな雰囲気なのかもしれないが
抽象化した方がデバッグしやすいだろ…
もしも、デバッグしにくいと思ってるなら
適切なスコープを知らないか、ちゃんと副作用の制御が出来てないか
そもそも必要以上に余計なクラスや関数を付け加えているか
102: 仕様書無しさん 2021/04/11(日) 18:53:02.50
>>81
物による。
抽象化バカでも具体的にしか書けないバカでもプログラムは腐る。
良い設計のものは抽象度が統一的で滑らか。
83: 仕様書無しさん 2021/04/07(水) 21:27:35.05
プログラムの規模が大きくなると
結局何で書いてもあまり変わらなくなるんだけどな
結局わけがわからなくなる
84: 仕様書無しさん 2021/04/07(水) 21:30:43.52
わけわからなくならないようにOOなんだけど
いまだにOO叩きって冗談だろう
まあ冗談だろうけどw
86: 仕様書無しさん 2021/04/07(水) 21:34:38.32
そもそもOO使ってないメインストリームのフレームワークとか存在すんの？
92: 仕様書無しさん 2021/04/08(木) 16:35:01.62
>>86
フレームワークそのものが
馬鹿コーダーの作ったゴミ
使えない
94: 仕様書無しさん 2021/04/08(木) 22:20:27.22
ＤＤＤばかにしていたが
ValueObjectで値が所定の範囲に収まってる安心感はたいしたもんだ
実際は入り口が壊れてて保証もへったくれもないんだが
98: 仕様書無しさん 2021/04/11(日) 16:34:52.59
>>94
ValueObjectって、今は正規表現とかで作ってるよね？
この変数はString型だけどクレジットカード番号の
正規表現にマッチするものだけとか
この変数はInteger型だけど値の範囲はここからここまでとか
まだ時代は俺に追いついてない？
114: 仕様書無しさん 2021/04/12(月) 23:45:35.43
Javaの型推論はC#と違って使いもんにならんの？
115: 仕様書無しさん 2021/04/13(火) 00:12:25.93
>>114
使いもんにならんってことはないと思うけど、うちの場合はラッパーオブジェクトが一番の理由かな
例えば整数を返すメソッドがあったとして、受け取った戻り値にnullチェックが必要なのかどうかがわからないってのと、ジェネリクスでプリミティブ型を扱えないから、演算するときはプリミティブ型で受け取らないとパフォーマンス落ちるからね
146: 仕様書無しさん 2021/04/17(土) 00:16:13.81
クラス、マルチスレッド、コールバック地獄、クロージャ、
上から下に読めなくなり、引数の中に処理が入れ子で入って追うのも困難。
もうお前Lispだろ？って感じ。
マルチパラダイスっての？一つの言語であれもこれもやろうとすんじゃねーよ。
誰とは言わんがC++、全員お前の子孫だろ何とかしろ
149: 仕様書無しさん 2021/04/17(土) 02:27:05.04
>>146
楽園かよ
150: 仕様書無しさん 2021/04/17(土) 11:11:20.53
>>146
Windowsアプリとか、むしろ一本道で書けるコードの方が少ないぞ
154: 仕様書無しさん 2021/04/18(日) 22:58:35.41
俺が書いたコードが世界に放たれたときから世界が変わった
155: 仕様書無しさん 2021/04/18(日) 23:57:21.47
>>154
カッコいい…
156: 仕様書無しさん 2021/04/19(月) 00:38:16.33
>>154
日本語不自由な方ですか？
157: 仕様書無しさん 2021/04/19(月) 02:14:53.14
>>154
お前のせいか
159: 仕様書無しさん 2021/04/19(月) 12:45:22.65
>>154
すごい
161: 仕様書無しさん 2021/04/20(火) 12:03:04.27
>>154
広島にお住まいですか？
162: 仕様書無しさん 2021/04/20(火) 22:09:53.18
>>154
コロナのRNAコードのことか
9: 仕様書無しさん 2021/04/02(金) 10:46:40.85
初心者みてーなこと言ってんじゃねー
どの言語も全部不完全だよ
http://nozomi.2ch.sc/test/read.cgi/prog/1617286652/
この記事へのコメントはありません。