1仕様書無しさん2021/04/01(木) 23:17:32.70
最初から、はナシで
2仕様書無しさん2021/04/02(金) 02:23:45.69
お前の頭が新しいパラダイムについていけなくなったときから
3仕様書無しさん2021/04/02(金) 02:41:28.30
>>1
その議論の前に、プログラミング言語がおかしくなったという
主張は正しいか？誰がそんな事を言っているか？という話をしないといけない
そうでないと、おかしくないものに対して
おかしいんだという先入観を与えてしまうことになる
例えば「なぜ日本人は馬鹿になってしまったのか徹底討論」みたいな
テレビ番組が作られたとしたら、それは日本人が馬鹿になったという
印象を与えるための番組だと思ったほうがいい
そんな日本人が馬鹿になったというデータはないのに、テレビ番組を見てる人は
日本人が馬鹿になったんだなという前提で、その理由を考えることになり
日本人が馬鹿になったかどうかを考えず刷り込みが完了してしまう
このようなテクニックは多いのでそれに騙されないようにしましょう 4仕様書無しさん2021/04/02(金) 04:42:56.59
まずa=a+1がおかしい
5仕様書無しさん2021/04/02(金) 06:45:56.88
一度も使わなかったもの：
共用体
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))
と書くのがプログラミングの将来にとって非常によい本来の姿なんだ 7仕様書無しさん2021/04/02(金) 09:53:35.31
そもそも数学に代入記号がないのが問題
イコールと代入は意味が違う
8仕様書無しさん2021/04/02(金) 10:02:42.84
代入 =
イコール ==、EQ
代入とイコールで同じ記号を使ってる言語ってBASICとCぐらいじゃないの？
9仕様書無しさん2021/04/02(金) 10:46:40.85
初心者みてーなこと言ってんじゃねー
10仕様書無しさん2021/04/02(金) 12:32:45.76
11仕様書無しさん2021/04/02(金) 13:26:03.75
(setq x 1)
これがよかったなあ
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 という言葉のほうが分かりやすいと
思われていた時代があったかもしれないね
15仕様書無しさん2021/04/02(金) 19:56:27.65
タイプライターに矢印形の文字があれば代入はそれになっあたよな
16仕様書無しさん2021/04/02(金) 20:10:18.23
Javaの暗黙オブジェクト
17仕様書無しさん2021/04/02(金) 20:11:30.43
APL
18仕様書無しさん2021/04/02(金) 20:13:51.95
割と本気で思ってるのがオブジェクト指向馬鹿が誕生した時からだろう
19仕様書無しさん2021/04/02(金) 20:57:28.47
宇宙船演算子ってなんだよ
20仕様書無しさん2021/04/02(金) 22:05:21.22
21仕様書無しさん2021/04/02(金) 22:30:53.55
22仕様書無しさん2021/04/02(金) 22:37:08.17
それがおかしいと思う感覚は正常
むしろコンピュータ技師として適正がある
アセンブラどうぞ
23仕様書無しさん2021/04/03(土) 08:09:51.12
添字の表記が省略された漸化式と考えていますが
24仕様書無しさん2021/04/03(土) 08:22:13.75
=と==を分けて考えることができないのは頭堅すぎるだろ
25仕様書無しさん2021/04/03(土) 08:26:17.23
>>23
前の添え字のときの値を見るすべがないし
参照でももたれてたら処理中に突然値が変わるんですが 26仕様書無しさん2021/04/03(土) 08:47:45.77
>>25
命令的にメモリーを操作している訳ですし...... 27仕様書無しさん2021/04/03(土) 08:52:49.72
比較が=は本当に頭おかしいと思う
28仕様書無しさん2021/04/03(土) 08:53:45.67
29仕様書無しさん2021/04/03(土) 10:49:45.91
a=a+1
この場合、aは変数の値を格納しているメモリのアドレスを表現しているんだ
&0x01 = &0x01 + 1;
っていう書き方を省略しているにすぎない
左辺は格納するアドレス、右辺は格納されている値なんだ
a=a+1の左右でaの意味が違っていることに気が付けば違和感の正体がわかるはずだ
30仕様書無しさん2021/04/03(土) 11:01:11.95
:=
31仕様書無しさん2021/04/03(土) 12:15:17.43
記号言語の概念と数学の概念をマゼコゼに考えるから分からなくなるんだろ
32仕様書無しさん2021/04/03(土) 12:59:57.60
数学の概念で言うならば=という記号は
同一の値であるという意味なんです
33仕様書無しさん2021/04/03(土) 13:28:04.65
言語の(C言語やそれに類する)概念で言うと=と言う記号は
左辺に右辺の結果を入れると言う意味なんです
34仕様書無しさん2021/04/03(土) 13:49:41.27
35仕様書無しさん2021/04/03(土) 15:42:15.10
YouTube で有名な、雑食系エンジニア・KENTA が、
Java, PHP を絶対に勧めない
初心者には、Ruby on Rails しか勧めない。
それで実際にビジネスサイトを立ち上げた女性・初心者は、Rails, Heroku
AWS を使いたい企業は、さらに、
くろかわこうへいのAWS サロンへ入る
皆、このパターン
KENTA の千円のサロンへ入って、聞いてみれば？
2千人入っている
36仕様書無しさん2021/04/04(日) 03:47:35.39
ステマ
37仕様書無しさん2021/04/04(日) 11:31:11.28
>>34
昔の人が決めたルールです。本来は勝手に変えたらダメなんです。 38仕様書無しさん2021/04/04(日) 18:36:12.88
>>37
そんな決まりは無い
あらゆるものは変化する
新しい使い方が他人の共感を得て流行るかどうかだけ
共感を得なかったらただ廃れるだけ 39仕様書無しさん2021/04/04(日) 20:21:14.60
定義を記述する言語と
命令を記述する言語の違いが分からない奴に欠陥がある
違うものは違う
存在の目的から違う
自分の知ってるものと同じでないとおかしいという
頑固者は邪魔なだけ
新鮮でもなんでもないありふれたガイジ
40仕様書無しさん2021/04/04(日) 21:25:02.49
等号を代入記号で使うのは違う定義を与えたってだけでそれにより本質的になにか重大な間違いが生じるとは思えんが
41仕様書無しさん2021/04/05(月) 04:31:23.10
=に違う定義を与えていいってことになると
+や*に違う定義を与えても良くなっちゃいますねｗ
数学で等号だって決まってるんだから
そのとおりにしなさい
42仕様書無しさん2021/04/05(月) 05:09:17.84
学歴不問
コピペ
43仕様書無しさん2021/04/05(月) 05:47:01.03
記号なんて微積分だって違う記号使ってるだろ
44仕様書無しさん2021/04/05(月) 06:44:57.60
1!=1
数学的には正しいはずなのに！
45仕様書無しさん2021/04/05(月) 06:54:53.46
カッコつけて仕様書で≠って書いたら見づらいのなんの
46仕様書無しさん2021/04/05(月) 09:59:27.38
>>41
ああ、違う定義を与えていいんだぞ。
文字列の連結に+を使ったりCのdereferenceに*を当たり前のように使ってるだろう。
文脈によって記号の定義が異なるのは問題ない。類似した文脈では意味的に近い方がベターというだけの話。
文脈を無視して記号だけを取り出して語るのは馬鹿げている。 47仕様書無しさん2021/04/05(月) 10:24:53.73
群論も記号論も知らないスポンジに何話しても無駄
48仕様書無しさん2021/04/05(月) 10:51:20.82
そもそもC++見てショック死するべきw
49仕様書無しさん2021/04/05(月) 11:00:24.11
>>41
正にその数学が＝をそんな定義してない。
反射律，対称律，推移律ぐらいも知らないアホの子には何言っても無駄な気もするけど... 50仕様書無しさん2021/04/05(月) 11:05:39.91
LET A, A+1
って書くよりも
A=A+1
のほうが直感的
51仕様書無しさん2021/04/05(月) 11:07:46.51
=に代入の意味を与えたやつはアホ
数学を勉強しろ
52仕様書無しさん2021/04/05(月) 11:08:23.52
そもそも数学の記号じゃねーし
数学がどうこういうならまず数学の微分の記号を統一してからおいで
53仕様書無しさん2021/04/05(月) 11:09:02.22
ちなみに数学って九九の話じゃねーぞw
54仕様書無しさん2021/04/05(月) 11:17:17.78
まあ、文字列連結の+なんて、数学的な+とまるっきり意味が違うだろw
55仕様書無しさん2021/04/05(月) 11:22:04.06
学校で＋ーを習ったばっかりなんだろうw
56仕様書無しさん2021/04/05(月) 12:17:59.38
いつまで文法の話してるの？
57仕様書無しさん2021/04/05(月) 14:44:30.51
REXXに無理やりオブジェクト指向導入されたときは悲しかったなぁ
そんなめんどくさくて長くて無駄な書き方強要しないで昔通りに書かせて
マニュアルも昔通りの記述を中心に書いてよって思った
58仕様書無しさん2021/04/05(月) 14:57:35.44
式の流れから
左側から右
右側から左
これの問題もある
答え＝１＋１ cpu
１＋１＝答え 人間
だす
59仕様書無しさん2021/04/05(月) 21:19:33.47
代入に=を採用したのは
cobol, fortranからだからな
この辺の言語の設計したのは
バリバリの数学者だったはずなんだが
なんで=を採用したんだろうか
60仕様書無しさん2021/04/06(火) 02:29:50.74
ヒルベルトさんは記号なんてどうでもええわと言っとったわ
61仕様書無しさん2021/04/06(火) 03:16:37.76
62仕様書無しさん2021/04/06(火) 05:15:50.59
=で代入するのに反対な人は
どんな代入記号を思いつく？
63仕様書無しさん2021/04/06(火) 05:56:22.22
define variable dimension x
set value x is f(x)
64仕様書無しさん2021/04/06(火) 07:44:31.59
やめてくれw
65仕様書無しさん2021/04/06(火) 08:25:02.23
←でいいだろ。Unicodeの時代なんだから
66仕様書無しさん2021/04/06(火) 09:40:51.85
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
コボルのデバッグをお願い。オブジェクト指向じゃないから
お前にとっては簡単なはずだ 71仕様書無しさん2021/04/06(火) 16:21:32.01
>>69
ウンコなのはオブジェクト指向ではなくて、設計の下手な奴とそれをオブジェクト指向自体の欠点と混同する奴だろう 72仕様書無しさん2021/04/06(火) 16:22:36.37
コボルを使っていれば設計は誰でも出来る
73仕様書無しさん2021/04/06(火) 16:23:58.85
>>69
抽象と具体がハチャメチャなやつがオブジェクト指向設計をするのが問題
現実世界でも抽象的に物事を捉えられない人が多い 74仕様書無しさん2021/04/06(火) 19:41:14.62
javaのenumが慣れない
75仕様書無しさん2021/04/07(水) 02:19:53.07
>>70
やるよ
簡単だからな
COBOLは最もまともな言語だ
わかんねえだろ？
馬鹿には分からんのだ！ 76仕様書無しさん2021/04/07(水) 06:35:08.06
いいやPL/SQLには負けるね
77仕様書無しさん2021/04/07(水) 06:37:58.54
COBOL-88 （変更）語の長さを60字以下までとする。
COBOL-93 （変更）語の長さを30字以下までにもどす。
ｗ
78仕様書無しさん2021/04/07(水) 07:05:21.93
オブジェクト指向だな
メリットを誰も説明できない言語
79仕様書無しさん2021/04/07(水) 07:55:23.86
>>70
今のCOBOLはオブジェクト指向言語だよ 80仕様書無しさん2021/04/07(水) 07:57:56.00
>>69
その通りだと思うが単純に規模が大きくなったせいのほうが大きいと思うぞ 81仕様書無しさん2021/04/07(水) 10:55:08.12
マジレスしちゃダメな雰囲気なのかもしれないが
抽象化した方がデバッグしやすいだろ...
もしも、デバッグしにくいと思ってるなら
適切なスコープを知らないか、ちゃんと副作用の制御が出来てないか
そもそも必要以上に余計なクラスや関数を付け加えているか
82仕様書無しさん2021/04/07(水) 12:25:50.42
「現代のプログラミング言語はおかしい」という前提ですから
正直俺の中では>>2で終わってるんだけど 83仕様書無しさん2021/04/07(水) 21:27:35.05
プログラムの規模が大きくなると
結局何で書いてもあまり変わらなくなるんだけどな
結局わけがわからなくなる
84仕様書無しさん2021/04/07(水) 21:30:43.52
わけわからなくならないようにOOなんだけど
いまだにOO叩きって冗談だろう
まあ冗談だろうけどw
85仕様書無しさん2021/04/07(水) 21:32:59.75
逆に今はOO叩き全盛だと思うけど
86仕様書無しさん2021/04/07(水) 21:34:38.32
そもそもOO使ってないメインストリームのフレームワークとか存在すんの？
87仕様書無しさん2021/04/07(水) 21:38:39.18
20年くらい前についていけないやつが悲鳴あげてたイメージ
88仕様書無しさん2021/04/07(水) 22:30:27.64
構造化プログラミング手法からオブジェクト指向にすんなり入れた俺
89仕様書無しさん2021/04/07(水) 22:36:45.19
構造化された依存関係が大事だと気付くまで１０年ぐらいかかった
えらい長い時間を無駄にした
90仕様書無しさん2021/04/07(水) 22:38:24.08
DBに入らないデータ構造はゴミカス
91仕様書無しさん2021/04/08(木) 07:21:33.01
テストしよい
92仕様書無しさん2021/04/08(木) 16:35:01.62
>>86
フレームワークそのものが
馬鹿コーダーの作ったゴミ
使えない 93仕様書無しさん2021/04/08(木) 22:07:33.73
ごめんなさい
94仕様書無しさん2021/04/08(木) 22:20:27.22
ＤＤＤばかにしていたが
ValueObjectで値が所定の範囲に収まってる安心感はたいしたもんだ
実際は入り口が壊れてて保証もへったくれもないんだが
95仕様書無しさん2021/04/09(金) 06:07:18.58
比較はequalsを使えとあれほど...
96仕様書無しさん2021/04/09(金) 21:35:37.49
97仕様書無しさん2021/04/11(日) 16:03:36.85
だから、記号言語は一般数学と違うんだよw
98仕様書無しさん2021/04/11(日) 16:34:52.59
>>94
ValueObjectって、今は正規表現とかで作ってるよね？
この変数はString型だけどクレジットカード番号の
正規表現にマッチするものだけとか
この変数はInteger型だけど値の範囲はここからここまでとか
まだ時代は俺に追いついてない？ 99仕様書無しさん2021/04/11(日) 18:28:15.42
追いついてないな
エラーコードが違反パターン毎にわかれてる
この正規表現にマッチするようにしてくださいとユーザーにエラー返すわけにもいかん
100仕様書無しさん2021/04/11(日) 18:30:08.46
あと正規表現重くね
計ったことないからどれくらいのもんかはしらんが
ＳＱＬばしばし発行してるし
入力チェックが重くてもたいしてこまりゃしないか…
101仕様書無しさん2021/04/11(日) 18:37:32.44
あと整数を正規表現って難易度たかくね
102仕様書無しさん2021/04/11(日) 18:53:02.50
>>81
物による。
抽象化バカでも具体的にしか書けないバカでもプログラムは腐る。
良い設計のものは抽象度が統一的で滑らか。 103仕様書無しさん2021/04/12(月) 00:28:34.55
>>99
正規表現とエラーメッセージを定義すればいいだけじゃん
> あと正規表現重くね
コンピュータがどれだけ高速かわかってないの？
0.001秒あれば10000回ぐらいはチェックできるだろ 104仕様書無しさん2021/04/12(月) 02:57:30.08
批判が的を得てないんだよな。
まず業務で高校数学が応用として使える時点で、世の中の上側1%以上なのよ。
アク界隈はお受験からのエリート教育で育ってるから、世の平均以下がちゃんと認識できていない。
残念ながら需要が存在してしまうわけですわ。高校数学の範囲だろうが何だろうが知らんがな。
あと、純粋な高等な数学になればなるほど、応用が狭まっていく。平たく言うと役に立たない。
なんでそんなものと比較するのか意味が分からない。好きなら勝手に博士課程でも行ってろ。
そして、哀れにもアク候補生として入社して、想像以上に日本社会の企業文化に揉まれ疲弊し、
自分は東京一工のエリートなのにこんな試験にも受からないクヤシイ！！みたいな人が、
5chで見えない敵をたたいて必死にもがいているんだな。憎むべきはその選択の損切りができない自分自身なのに。
だから、嫌ならやめろよと。クソ試験と思うなら今すぐやめて転職なりしろ。何事も中途半端が一番良くない。
105仕様書無しさん2021/04/12(月) 06:18:16.32
>>103
長さチェックのために正規表現使うのばからしい
あと整数 106仕様書無しさん2021/04/12(月) 07:39:27.76
>>105
正規表現以外を使うなとは一言も言ってない 107仕様書無しさん2021/04/12(月) 09:37:54.22
他の言語でやってることをまねしようと言語仕様のverアップしてて大差なくなってると感じる
しかもやってることは同じなのに書き方ばかり増えるから労多すぎ
ラムダ式とか
108仕様書無しさん2021/04/12(月) 12:53:55.46
古いソースでは古い書き方で、新しいソースでは新しく書けばいいだけじゃね
109仕様書無しさん2021/04/12(月) 19:21:51.94
混ざったら何が何だかわからんだろうが！
新しい書き方で理解のコストが半分になったとしよう
古いのがそのまま残ってるとしよう
理解のコスト１．５倍です
110仕様書無しさん2021/04/12(月) 21:26:14.59
>>109
ごめん、古いプロジェクトでは古い書き方(そのまま)、新しいプロジェクトでは新しい書き方って言いたかったんだ
実務経験なくて頓珍漢な書き方してごめん 111仕様書無しさん2021/04/12(月) 21:43:53.11
いや、それであってる
ラムダ式なんて別に理解をしやすいからじゃなくて便利だからあるだけだし
新しいのは古いのの上に乗っかってるだけだから新しいのがわかれば古いのもわかる
112仕様書無しさん2021/04/12(月) 23:34:08.45
Javaのvarなんて必要ある？
動的に型変更するわけではないけど、型に厳格なJavaを考えれば、単に書き方を省略するためにならいらない
プロジェクトだと、単にジェネリクスとか理解できない奴らがごまかすためだけに使っていて粗悪コード量産してるだけ
結果的にvar禁止になったし(プロジェクトで)
113仕様書無しさん2021/04/12(月) 23:39:32.50
>>112
うちもJavaのvarは言語的に向いてないってことで非推奨になってるな
逆にC#のプロジェクトでは推奨というか、ほぼ強制になってるわ 114仕様書無しさん2021/04/12(月) 23:45:35.43
Javaの型推論はC#と違って使いもんにならんの？
115仕様書無しさん2021/04/13(火) 00:12:25.93
>>114
使いもんにならんってことはないと思うけど、うちの場合はラッパーオブジェクトが一番の理由かな
例えば整数を返すメソッドがあったとして、受け取った戻り値にnullチェックが必要なのかどうかがわからないってのと、ジェネリクスでプリミティブ型を扱えないから、演算するときはプリミティブ型で受け取らないとパフォーマンス落ちるからね 116仕様書無しさん2021/04/13(火) 01:10:00.16
PythonとかJavaScriptとかになれるとタイプがめんどいという話だからな
要らなきゃ使わなきゃいい
117仕様書無しさん2021/04/13(火) 01:29:28.79
それは型推論じゃなくて動的ディスパッチ
118仕様書無しさん2021/04/13(火) 09:58:41.46
必要だから増えたのではなく、他言語がやってるから導入した
119仕様書無しさん2021/04/13(火) 10:10:47.44
単なるエイリアスで解決できる問題を無駄な計算資源使うことで解決とか頭悪すぎだわ。
120仕様書無しさん2021/04/13(火) 10:58:24.51
人が１分楽できるならいいことだ
そのために計算機を１日こきつかったっていいじゃない
121仕様書無しさん2021/04/13(火) 11:01:01.35
ＤＢの一貫性とか知識何もなしに偉そうな顔して
途中止まったらもう一回クやりなおしになるのは時間かかるから
続きを人間が整合性とりつつやるとかほざいてるウンコがおった
122仕様書無しさん2021/04/13(火) 11:02:55.36
123仕様書無しさん2021/04/13(火) 11:09:18.43
だからなんのチェックもしてなくても
項目全部ValueObjectつくるねんで
124仕様書無しさん2021/04/13(火) 12:43:35.53
別におかしくなってないし遺伝子の多様性は必要だ
ちなみにスレタイしか読んでない
125仕様書無しさん2021/04/13(火) 18:33:06.67
ね
126仕様書無しさん2021/04/13(火) 19:31:26.69
ぶた
127仕様書無しさん2021/04/13(火) 19:32:13.54
むしろプログラミング言語ほど正常に進化し続けているものは珍しい
128仕様書無しさん2021/04/13(火) 19:39:36.65
バカでも書けるようにした結果バカがバグを生みまくる事態に
129仕様書無しさん2021/04/13(火) 22:27:05.28
130仕様書無しさん2021/04/13(火) 22:37:44.51
すべて分かったいる人が見ると
便利になっているな
近頃の言語は
わかってないとチンプンカンプンだろうな
131仕様書無しさん2021/04/14(水) 07:54:21.51
a−〉b
132仕様書無しさん2021/04/14(水) 19:59:51.53
JavaのSpring
133仕様書無しさん2021/04/15(木) 11:02:15.19
わかってる人が使わないと糞コード量産するだけになる
134仕様書無しさん2021/04/15(木) 13:09:54.50
分かってない奴に問題があるので言語に罪は無い
135仕様書無しさん2021/04/15(木) 19:23:03.79
ところで「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！
136仕様書無しさん2021/04/15(木) 20:42:58.54
137仕様書無しさん2021/04/15(木) 20:44:43.32
>>135
あーそうか
お前が気安く荒らしていい程度のスレだと認識したのか 138仕様書無しさん2021/04/16(金) 01:38:47.10
C#やJavaはC言語の書きかたに似ているから理解しやすいけど
ObjectiveCやSwift、KotlinやGOとか型を後ろに書くようなゴミは消えて欲しいｗ
139仕様書無しさん2021/04/16(金) 02:15:27.55
シンタクスしか気にすることないの？
140仕様書無しさん2021/04/16(金) 02:34:51.44
>135
「人が空を飛ぶ」といっしょ。文法的には正しいが、現実にはあり得ない。
スレタイに話を戻すと、Javaのフレームワーク乱立あたりで、プログラミング言語としては
文法的に正しいのにフレームワークの規約に適合しないから動かないと言う余計な足枷が課された。
あと、csv形式の文字列を作るときにループ処理を利用すると、最後だけはカンマ不要だろ？
リトライで失敗したらsleep入れてもっかいリトライする処理とか。
昔から頻出する処理なのに実現するループ処理がない。
141仕様書無しさん2021/04/16(金) 03:04:37.23
>>138
型を後ろに書く方が真っ当だという批判が
C++全盛期の時からあった
型より名前の方が大事に決まってるし
省略できないのは名前の方だからだ
C#に型推論を導入するのに
varキーワードが必要になったのも
非合理的な文法との折衷のためだ
型が後ろで違和感を感じるというのは
単なる慣れの問題だ
これが分からない奴は多分、クソガキより老害に多い気がするけど 142仕様書無しさん2021/04/16(金) 03:05:29.75
１件目をやってからループ入って頭でカンマ付けたらいかんのか？
リトライもメソッドにしてサクセスするまで回せばええやん
143仕様書無しさん2021/04/16(金) 16:01:21.45
いまさらだけど
>>1はできる人、頭のいい人のように思う。
スレタイが素晴らしいと思いますので。 144仕様書無しさん2021/04/16(金) 19:12:13.53
これ以上無いぐらい馬鹿げたスレタイだが
145仕様書無しさん2021/04/16(金) 22:00:43.55
146仕様書無しさん2021/04/17(土) 00:16:13.81
クラス、マルチスレッド、コールバック地獄、クロージャ、
上から下に読めなくなり、引数の中に処理が入れ子で入って追うのも困難。
もうお前Lispだろ？って感じ。
マルチパラダイスっての？一つの言語であれもこれもやろうとすんじゃねーよ。
誰とは言わんがC++、全員お前の子孫だろ何とかしろ
147仕様書無しさん2021/04/17(土) 00:32:02.84
>>143
自作自演しなくていいんやで
わかってるからさ 148仕様書無しさん2021/04/17(土) 02:23:28.88
ラムダ式は本当に便利でいいね
149仕様書無しさん2021/04/17(土) 02:27:05.04
150仕様書無しさん2021/04/17(土) 11:11:20.53
>>146
Windowsアプリとか、むしろ一本道で書けるコードの方が少ないぞ 151仕様書無しさん2021/04/17(土) 11:16:15.05
152仕様書無しさん2021/04/17(土) 11:21:43.40
>>146
仕事についていけなくなったのか
憐れだな 153仕様書無しさん2021/04/17(土) 11:45:57.59
非線形テクストたるゲームブックの実物に触れたことの無い世代が増えたからだ
154仕様書無しさん2021/04/18(日) 22:58:35.41
俺が書いたコードが世界に放たれたときから世界が変わった
155仕様書無しさん2021/04/18(日) 23:57:21.47
156仕様書無しさん2021/04/19(月) 00:38:16.33
157仕様書無しさん2021/04/19(月) 02:14:53.14
158仕様書無しさん2021/04/19(月) 06:01:01.98
世界を変えるコード書きたい
159仕様書無しさん2021/04/19(月) 12:45:22.65
160仕様書無しさん2021/04/19(月) 13:00:40.46
少なくとも言葉だけで４人の世界が変わってる
161仕様書無しさん2021/04/20(火) 12:03:04.27
162仕様書無しさん2021/04/20(火) 22:09:53.18
163仕様書無しさん2021/04/22(木) 16:17:41.66
俺がコード書いたせいで会社がこんなになっちまった
164仕様書無しさん2021/04/24(土) 02:42:13.25
全て私の責任です(上司)
165仕様書無しさん2021/04/24(土) 14:26:55.26
なお、なぜか昇進する模様
166仕様書無しさん2021/05/01(土) 20:29:03.36
neat3最強
167仕様書無しさん2021/05/10(月) 08:11:44.61
168仕様書無しさん2021/05/10(月) 08:15:14.51
169仕様書無しさん2021/05/10(月) 08:20:45.02
>>100
軽い代替方法があるのに正規表現やSQL使って桁違いに遅くしてる例はあちこちで見かける 170仕様書無しさん2021/05/13(木) 12:46:12.12
HTTPで何回もリクエスト飛ばして重いとか言ってるレベルじゃねーの
171仕様書無しさん2021/05/19(水) 16:54:39.54
>>168
ライブラリで片付けるんじゃないか?
そのほうが楽だし。 172仕様書無しさん2021/05/25(火) 19:22:56.50
>>44
仮に階乗!と比較不等号!=を両方サポートする言語があったとしたら
多くの言語は最長適用だから!=とあれば階乗と等号ではなく不等号≠になるだろう
その場合は1!=1は偽falseとなる
しかしもし階乗!優先の言語だとすると(1!)=1の意味となる
ところが=を等号で用いずに代入のみで使う言語ならば左辺が数値となりエラーだ
しかしもし=を比較等号として用いる言語ならば(1!)=1は真trueとなる
後者の真trueとなるための道は険しく
・階乗記号!をサポート
・!=と続いても階乗記号を優先
・=を比較等号として用いる
このようなプログラミング言語はあるのだろうか？ 173仕様書無しさん2021/05/25(火) 19:26:52.11
174仕様書無しさん2021/05/31(月) 03:10:46.88
色々なプログラミングしていて階乗演算を使うことなんて滅多にないから、階乗記号をもっとよく使われる演算に割り当てるのはリーズナブルだと思う
階乗記号を階乗演算に使う言語はあってもいいが自分にとっては全く不要
どうしても欲しいなら自分で作ればいい
175仕様書無しさん2021/05/31(月) 10:12:50.39
階乗は関数でいいよ
176仕様書無しさん2021/05/31(月) 13:10:28.88
階乗が必要な場合って
順列、組み合わせか、ガンマ関数ぐらいしか思いつかないな
ブックマークへ