Qiita 7 - キータぞ、来たぞ、キータだぞー (768ﾚｽ)
上下前次1-新
154: 2025/09/28(日)20:28 AAS
>>129
>現行の言語のデザインに何も疑問を持たないのはそれだけの人
>>129
違うデザインのものなんて無数にあるのに誰も支持しなかったことすら考えられないからお前は中卒無職ヒキコモリ脳障害なんだよ
自殺しとけ猿が
155: 2025/09/28(日)20:29 AAS
>>152
分からんなら自殺しろ
アセンブラすら知らない猿が吠えんな
最終的にどんなマシンコードになるか知らないバカが妄想しても意味ねーから
消えろ
この世から
156(1): 2025/09/28(日)20:33 ID:iPJCP/07(4/7) AAS
> 最終的にどんなマシンコードになるか知らないバカが妄想しても意味ねーから
スマホで見て発狂してる可能性もあるかな?
157: 2025/09/28(日)20:37 AAS
>>156
最適化レベルすら指定してない猿
無職か？
158(1): 2025/09/28(日)20:48 ID:iPJCP/07(5/7) AAS
> 最適化レベルすら指定してない猿
指定してる -Copt-level=2 が最適化指示とわからん人かな?
159: 2025/09/28(日)20:59 ID:67OEPeOQ(1) AAS
AIって想像以上にアホだぞ
160: 2025/09/28(日)21:12 ID:aU9wcwp7(4/11) AAS
>>124
Rubyは閉区間と半開区間の両方を提供したことと、閉区間に左右対称な..を採用したことでは
賢明だったが、半開区間に左右対称な...を採用したのは惜しい誤りだったな。..とも判別しづらいし。
..<か..~にすべきだった。
>>125
>>66にも書いたように、Swiftでは閉区間は...で左右対称、半開区間は..<で左右非対称だよ。
閉区間はPascalの..より.が1つ多い...だが、左右対称という点では共通する。
増分も指定できるように拡張することを見越すと、半開区間には..<より..~の方が適している。
開始値..増分..<終了値だと増分が負のとき変な感じがするが、開始値..増分..~終了値ならば
問題ないから。
省5
161(2): 2025/09/28(日)21:13 ID:aU9wcwp7(5/11) AAS
>>131
>>116に挙げたJuliaの作者じゃないから、数学に合わせること自体に固執しているわけではない。
左右対称な..が閉区間を表すのが自然な感覚で、それに反するのはバグの元だからやめるべきだと
いうのが根源的な理由で、数学はそれに反していない例として挙げたに過ぎない。
人間は機械ではないから見た目に惑わされやすい。機械だけが相手なら半開区間をi!jで表せば
効率が最も良いし、多くの言語では破壊的変更も文法的に不要で好都合なはずだが、人間の
感覚では!は半開区間とは容易に結びつかない（:の変形と見なせば結びつかなくもないが）し、
|とも判別しづらいから不適当。
屁理屈を捏ねて自然な感覚に反することを強制するのは、ギークの村社会のキモい悪習としか
言いようがない。プログラム言語の記法の選定はUI設計の一種なのに、不自然で間違えやすい
省6
162(2): 2025/09/28(日)21:25 ID:YRR4qqFp(1) AAS
Rustのイテレータがとてもわかりやすい
【C】i = 0 ; i < n; i++
【Rust】0..n
と
【C】i = 0 ; i <= n; i++
【Rust】0..=n
対応している
163: 2025/09/28(日)21:32 AAS
>>158
書いてないぞ
164(1): 2025/09/28(日)21:38 AAS
>>161
そんな感覚は無いのでお前の負け
ソース無し
165(2): 2025/09/28(日)21:43 AAS
>>161
自然なのは左右対称とかどうでもいい猿の妄想じゃなくて
最も使われるものが最もシンプルに書けるという情報理論的効率性な？
166(3): 2025/09/28(日)22:05 ID:aU9wcwp7(6/11) AAS
>>164
正直に白状しろ。心当たりが全くなくはないはずだ。
C++ STLの.begin()と.end()の組の.end()を書くときにも、もやもやする感覚が常に伴うな。
『リーダブルコード』に、
プログラミングの命名規約では、包含／排他的範囲にbeginとendを使うことが多い。
でも、endは少しあいまいだ。例えば、「本の終盤（the end of the book）を読んでいる」の
「end」は包含的だ。残念ながら英語には「ちょうど最後の値を超えたところ」を意味する簡潔な
言葉がない。
と述べられている通り。簡潔な言葉がないなら作れば良かったと思う。例えば、endの次（next）だから
nendとか。無闇に造語すべきではないが、どうしても必要なら作れば良い。bitは成功例だろう。
省5
167(1): 2025/09/28(日)22:07 AAS
>>166
なんのソースもない中卒の妄想は意味ない
ソースを出せ
出せないなら自殺して詫びろ
168: 2025/09/28(日)22:08 AAS
>>166
曖昧なことなど一つもない
定義を見れば良いだけ
定義以外の妄想してる時点で中卒無職だと確定する
169: 2025/09/28(日)22:11 ID:5mXw367y(1) AAS
>>162
従来との対応関係のあることが最も重要なのでそれで正しい
170: 2025/09/28(日)22:13 AAS
>>166
りーだぶるwwww
こーどwwwww
お前無職だろ？
そんな実績0の無能な猿が書いたゴミを流行りで買ってる時点で無職バレバレ
171(3): 2025/09/28(日)22:15 ID:aU9wcwp7(7/11) AAS
>>167
低学歴ではないが、低学歴という煽りもここでは意味がないね。プログラム言語なんて小学生でも
分かる程度のものでしかないし、一般的感覚も自然言語と高校までの数学によって形成されるものだから。
そこから乖離した屁理屈をあれこれほざいても、ギークのキモい戯言でしかない。
172: 2025/09/28(日)22:18 AAS
>>171
ソース出せない妄想と
173(1): 2025/09/28(日)22:18 AAS
>>171
低学歴だから定義を無視して字面から妄想し
低学歴だからソースもないのに妄想を断定できてしまう
174: 2025/09/28(日)22:23 ID:iPJCP/07(6/7) AAS
>>162
>【C】i = 0 ; i <= n; i++
と
>【Rust】0..=n
は同じ動作になるとは限らないので何言いたいんだかわからん。
175: 2025/09/28(日)22:26 ID:iPJCP/07(7/7) AAS
いまこのスレで発狂してるやつ見てるとQiitaでアカウントBANされたコイツ思い出すんだよなあ。
外部ﾘﾝｸ:web.archive.org
> はい、私が勘違いしてました。
> 途中で、
>
> スクリーンショット 2022-12-19 184235.png
>
> みたいな突っ込みがあって、やっと問題文をちゃんと読み直して『あれ？』となったわけですが、
>
> 自分、基本的にTwitterでの間違いは死んでも認めない主義なので、そのまま押し切る事にしました。
省4
176(2): 2025/09/28(日)22:27 ID:jJ7lr+aR(1/4) AAS
以下の性質の良さの違いのため
プログラミングでは半開区間が多用されている
半開区間 (性質が良い)
・start～endの長さはend-start
・startから始まる長さlenの区間はstart～(start+len)
・startから始まる長さ0の区間はstart～startと表せてそのまま自然に扱える
・途中middleでstart～middleとmiddle～endの二つに分割できる
閉区間 (性質が悪い)
・start～endの長さはend-start+1
・startから始まる長さlenの区間はstart～(start+len-1)
省4
177(1): 2025/09/28(日)22:27 ID:aU9wcwp7(8/11) AAS
>>173
カルト教団のむきになった反論そのものw 教祖様のお言葉がソースか?
自然言語と高校までの数学表記が一般に広く受け入れられていること、それで根拠として十分。
178(1): 2025/09/28(日)22:32 AAS
>>177
>>171
低学歴だから定義を無視して字面から妄想し
低学歴だからソースもないのに妄想を断定できてしまう
179(3): 2025/09/28(日)22:38 ID:jJ7lr+aR(2/4) AAS
区間指定の文法を持つ最近のメジャーなプログラミング言語では半開区間を簡単に表記できるようになっている
例えば
GoやPythonなどでは list[start:end]
C#やRustなどでは list[start..end]
いずれもendを含まない半開区間を意味している
180(2): 2025/09/28(日)22:46 ID:aU9wcwp7(9/11) AAS
>>178
定義なんて所詮は教祖様がお作りになった教義に過ぎない。それを絶対視して変だと考えず、
変だと指摘する人にむきになって壊れたレコードのようにワンパターンな反応を繰り返す
カルト信者。
181(1): 2025/09/28(日)22:47 AAS
>>180
定義はコンパイラの仕様
バカすぎる無職
182(1): 2025/09/28(日)22:47 AAS
>>180
変なのはお前
だから無職なんだろ中卒
183(1): 2025/09/28(日)22:49 AAS
>>176,179
これを入社試験の面接で説明できなきゃ不採用でいいわ
これ分からん奴はセンスが無さすぎる
184(1): 2025/09/28(日)23:01 ID:aU9wcwp7(10/11) AAS
>>181
コンパイラは教祖様がお作りになった言語仕様に沿って作られたものだろ。
>>182
無限ループ、またの名を暴走と言うw
185: 2025/09/28(日)23:01 AAS
>>184
これが無職
186: 2025/09/28(日)23:25 ID:jJ7lr+aR(3/4) AAS
>>183
初心者は仕方ないとしてもプログラミング歴のある人には必須な知識だと思う
187(1): 2025/09/28(日)23:34 ID:SbwCraTd(1) AAS
ここプログラム技術板で閉区間が自然だと主張して暴れてるやつはどこから来たお客さんなんだろう
188(4): 2025/09/28(日)23:48 ID:aU9wcwp7(11/11) AAS
>>187
閉区間が自然だとは全く主張していないぞ。
・閉区間で書くのが便利な場合も半開区間で書くのが便利な場合もあるので、両方の書き方を
提供するのが良い（勿論、前者の場合には閉区間が自然ということになるが）
・閉区間には左右対称、半開区間には左右非対称の記号を割り当てるのが自然で、バグを
生みにくい
と主張しているだけ。
189: 2025/09/28(日)23:54 ID:jJ7lr+aR(4/4) AAS
現実のメジャーなプログラミング言語では>>179のように半開区間を簡潔に記述できることを重視している
190: 2025/09/29(月)00:05 AAS
>>188
根拠0
証拠0
ソース0
バカすぎて論外
191: 2025/09/29(月)00:05 AAS
>>188
こういうバカは無職なのが自然
192(2): 2025/09/29(月)03:12 ID:KaR4fBa3(1) AAS
>>188
func main(){
var a = [5]string{"a","b","c","d","e"}
fmt.Println(a[0]) // a
fmt.Println(a[1]) // b
fmt.Println(a[1:3]) // [b c]
}
Go言語は半開区間のみ
> 両方の書き方を提供するのが良い
半開区間のみを提供するのが良い
省2
193: 2025/09/29(月)03:23 ID:Lm5HPMDj(1) AAS
>>192
横からだけど
Goは言語機能が非常に弱くて
その半開区間の指定も部分フライス指定にしか使えない
イテレータとして機能しない
(switchやmatchなどの)パターンマッチングにも使えない
194: 2025/09/29(月)07:48 ID:kekj+dde(1) AAS
>>192
＞あるプロジェクトでマイクロソフトが自社のC#でなくGo言語を採用したことが有名
TypeScriptコンパイラのことなら
Microsoft TypeScript Devs Explain Why They Chose Go Over Rust, C#
という記事にまとめられているが
＞半開区間のみを提供するのが良い
省3
195: 2025/09/29(月)23:43 ID:6lOYarrI(1) AAS
現実は>>179
理由は>>176
ということでいいのかな
196: 2025/09/30(火)00:17 ID:jvKDz5J9(1) AAS
閉区間と半開区間のどちらが優れているということは誰も言ってないのに一人発狂してる人がいる感じ
197: 2025/09/30(火)01:59 ID:4wPfeVv9(1) AAS
閉区間より半開区間が優れている
そのため半開区間を短い記述で指定できる文法を用意している言語が多い
短い記述の結果として半開区間が左右対称の記述になっているが誰も気にすることはない
半開区間の記述は左右非対称であるべきだとこだわっているキチガイは一人だけ
198: 2025/09/30(火)02:52 AAS
無職の妄想に価値はない
199: 2025/09/30(火)08:25 ID:EJn4wwZL(1/2) AAS
グレゴリオ暦のうるう年判定に延々とおかしなイチャモンつけてたashworthまんまだなｗ
200: 2025/09/30(火)10:36 ID:hvi0j7l5(1) AAS
そもそも自転はずれるからな
201(1): 2025/09/30(火)11:06 ID:EJn4wwZL(2/2) AAS
いまはこのルールでやりましょうというグレゴリオ暦を分かってないｗ
202(1): 2025/09/30(火)12:34 ID:dVe563is(1) AAS
グレゴリオ暦のうるう年の判定ルール
・西暦年が4で割り切れる年はうるう年となる
・ただし、西暦年が100で割り切れる年はうるう年としない
・さらに、西暦年が400で割り切れる年は例外的にうるう年とする
203: 2025/09/30(火)12:39 AAS
低学歴がなぜ低学歴なのかよくわかる
204: 2025/09/30(火)12:40 AAS
>>201
バカすぎてルールを理解できないことを正当化するためにルールがおかしいと吠えたまま死ぬ
これが低学歴の人生
205: 2025/09/30(火)12:40 AAS
そういうゴミクズを雇ったら終わりなので学歴システムがある
人間判定試験
猿を雇わないようにするための仕組み
206(1): 2025/09/30(火)23:54 ID:gehVEPsn(1) AAS
>>188
閉区間ではなく半開区間をサポートするプログラミング言語が多い理由を考えてみよう
それらの言語は半開区間に左右非対称の記号ではなく簡潔な記号を割り当てている理由を考えてみよう
207(2): 2025/10/01(水)00:59 AAS
算術符号とかハフマン符号なんて聞いたことすらねえんだろうな低学歴は
208: 2025/10/01(水)01:38 ID:Fskx/ZBj(1) AAS
> そもそも自転はずれるからな
地球の自転周期が変わったとして影響があるのは1日の長さなんだがｗ
209: 2025/10/01(水)02:15 ID:VkTjow7K(1) AAS
>>207
多用する半開区間に短い記号を充てるのが正解だと思う
しかしPythonやGoの start:end はあまりにも短すぎて用いる場所によっては文法的に曖昧になる可能性があるためなのか
現状はスライスのインデックス部分 a[start:end] でしか用いることができない
例えばmatch文のcaseでは指定できないため case x if start <= x < end と書く必要がある
イテレータとしても指定できないため for i in range(start, end) と書く必要がある
これら全て同じ記法で書けると好ましい
210: 2025/10/01(水)21:52 ID:yE7SMjvb(1) AAS
Rustは同じ扱い
buf[100..200]
for i in 100..200 { … }
match x {
100..200 => …,
…
}
211(3): 2025/10/01(水)23:34 ID:a34LDfpM(1/3) AAS
AA省
212(2): 2025/10/01(水)23:35 ID:a34LDfpM(2/3) AAS
>>207
圧縮ファイルを直読みできる超人さんですか?w
短さを馬鹿の一つ覚えみたいに持ち出しているが、間違えにくさを犠牲にしてまで達成すべきものではない。
人間は機械ではないのでうっかり間違えやすい記号を宛てないのが賢明で、たった1文字をケチるのは愚行。
正確に言えば機械も生の状態では間違えるから、エラー訂正符号を付加して無謬に見せかけているだけなので、
人間にも機械にも最短ではなくそれぞれの間違え方を防ぐような追加の情報も必要だという訓戒に纏められるな。
そこを疎かにするのは欠陥設計。
213: 2025/10/01(水)23:36 AAS
>>211
算術符号とかハフマン符号なんて聞いたことすらねえんだろうな低学歴は
214(1): 2025/10/01(水)23:37 AAS
>>212
え？圧縮ファイル？
何言ってんのこの中卒無職脳障害
そんなの関係ねえよ猿が
情報理論的な効率性の話しかしてないのに中卒だからわかんねえのか自殺しとけ猿が
215: 2025/10/01(水)23:38 AAS
>>212
お前が低学歴で人間じゃないだけ
お前は無職で人間の世界から排除されてるから人間の世界に口出しする権利ないよ
参加お断り
216(4): 2025/10/01(水)23:51 ID:a34LDfpM(3/3) AAS
>>214
馬鹿には皮肉の解説が必要だったか。情報理論的な効率性を徹底的に追求したのが圧縮ファイルだろ。
それは人間には勿論読めないが、もう少し緩く追求した半開区間に..を使う表記も人間にはやっぱり
間違いやすい。お前がそんなことはないと言い張るなら、さぞかし凄い超人なんだろうねーという皮肉。
たった1文字追加するだけで効率性と間違えにくさのバランスが取れた表記になるのに、ムキになって
否定するのは愚か。
217: 2025/10/01(水)23:56 AAS
>>216
圧縮ファイルなんて使ってない
人間の世界では最短符号を使って人間は読んでる
無職はそれが読めないから誰も雇わない
218: 2025/10/01(水)23:56 AAS
>>216
お前が間違えてもどうでもいい
だってお前は人間じゃないし人間の社会に参加出来ないから
219(1): 2025/10/01(水)23:57 AAS
>>216
人間は間違えない
猿は間違える
だから猿を雇わない
よってお前は無職
猿だからな
220: 2025/10/02(木)00:00 ID:IXGrVOcw(1) AAS
>>216
C#の半開区間指定start..end読みやすくて良いと思うよ
閉区間だと間違える人はいない
221: 2025/10/02(木)00:02 AAS
人間は間違えない
猿は間違える
だから猿を雇わなきゃいいだけ
222: 2025/10/02(木)00:02 AAS
猿に合わせて人間のルールを変えるわけねえだろ
猿を排除するのが最善
223(1): 2025/10/02(木)00:44 ID:Jz40Wv3H(1) AAS
>>211
それら閉区間しかないプログラミング言語は現代のメジャーな言語ではないな
センスが悪いとメジャーな言語になれないことがわかった
224(1): 2025/10/02(木)01:12 ID:EU/7mSn/(1) AAS
>>202
『あなたは本当に「プログラミングができない、向いてない」のか？ 〜うるう年判定プログラムで考える〜』
外部ﾘﾝｸ:qiita.com
という記事のコメ欄でashworthが他のコメントに絡んでたけど(垢BAN済み)、記事のコード見ると
> year = int(input())
> if year % 400 == 0: # 400の倍数なら「うるう年です。」
> print("うるう年です。")
> elif year % 100 == 0: # 100の倍数なら「うるう年ではありません。」
> print("うるう年ではありません。")
> elif year % 4 == 0: # 4の倍数なら「うるう年です。」
省5
225: 2025/10/02(木)01:14 ID:qLX1OCT3(1) AAS
まともな言語がいずれも半開区間をサポートしているのは偶然ではなくて、
配列やリストやベクタあるいは文字列などの連続領域の一部分いわゆるスライスを言語で扱おうとすると、
その区間を指定する必要がでてくる。
まともな汎用言語ならそのスライスと区間指定をサポートするのは必然で、
しかも閉区間は扱いにくいことが判明しているわけだから、
結果的に半開区間をサポートしているか否かでまともな言語か否かが判明することになっている。
226(1): 2025/10/02(木)04:38 ID:oFFK8/LC(1) AAS
>>224のコードってそんなに変かな？ 自分もこんな感じに書くと思うが。
227: 2025/10/02(木)05:00 ID:vDXY/c5t(1) AAS
>>226
動くコードは無数に考えられる。
しかし保守性を考慮すると、
元の文章に対応したコードのみが正解。
元の文章と逆順に書いた場合、
何か理由が添えてない限り失格でクビだろうね。
228: 2025/10/02(木)07:15 AAS
ソース読めよ
Check out this DeepWiki page 外部ﾘﾝｸ:deepwiki.com
229: 2025/10/02(木)07:34 ID:3AP3Ig0g(1/2) AAS
なるほど、if文のネストみたいな感じで書くのだとしたらそれはかえって分かりにくいのではと思ったけど、and or で1行で書いちゃうならスッキリしているね。
230: 2025/10/02(木)08:18 AAS
if文使った時点で不採用
print文使った時点で不採用
正解は
・数式・比較演算子と論理演算子で書く
・デバッガで各論理式の評価を確認してprint文を使わない
231: 2025/10/02(木)08:19 AAS
deepwikiでソースコードに聞け
低スキルの「エンジニア」同士で低スキルを伝播しても害しかない
232: 2025/10/02(木)08:24 ID:3AP3Ig0g(2/2) AAS
print関数はさすがに説明の便宜のためでしょ。
233: 2025/10/02(木)08:26 AAS
知りたいgithubのアドレスを取得
外部ﾘﾝｸ:github.com
アドレスのgithubをdeepwikiに置換
外部ﾘﾝｸ:deepwiki.com
最下部のフォームに質問すればソースコードをソースにして回答する
234: 2025/10/02(木)08:29 AAS
で
このdeepwikiもMCPでアクセスできるので
AIエージェントがコーディングのお作法を実装前にDeepWiki MCPで確認してソースコードをソースにして手順を確立してメモしてからそれを見ながら実装を開始するように出来る
低スキルエンジニア同士の会話など害しかない
235: 2025/10/02(木)08:45 ID:6BvO5ATM(1) AAS
速さ優先ならこれとはまた異なってくるのだろう
return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)
236: 2025/10/02(木)13:03 ID:sP1LMqCx(1) AAS
return False
237: 2025/10/02(木)13:37 ID:dLU/Z4Pm(1) AAS
> それ、問題文の条件のまま書いちゃダメなんですよね。
> 「ただし」がある場合は前出の条件を否定してくるので、条件の順番通りに書くと破綻します。
> だから、「ただし」がある場合は条件を逆に記述していくのが鉄則です。
ashworthさん、何言ってんの?
238(2): 2025/10/02(木)23:03 ID:jdy8/BVE(1/2) AAS
>>219
これまでの書き込みからお前はRust信者と推測されるが、「言語仕様で明確に定義されているのに数学につられて
間違えるのは低学歴・無職・猿」という煽り文句がブーメランになることに気づいていないのか?
C, C++ではif (a = b)という書き方が許されているが、数学では=が比較にも使われるため、比較するつもりで
if (a = b)とうっかり書き間違え、読み返しても間違いを見落とす恐れがあるので、C#やRustではこういう書き方を
できなくした。お前の煽り文句に従えば、代入は=、比較は==と言語仕様で明確に区別して定義されているのに
数学につられて間違えるのは低学歴・無職・猿で、C#やRustは低学歴・無職・猿向けの言語ってことになるねw
仮にお前がRustでなく他の言語の信者だとしても、似たようなブーメランを見つけることができるだろう。
Rustは他にも変数宣言でmutをいちいち書かせるなど過保護な安全性が設計思想にあるのに、半開区間..では
危うさを放置するのはチグハグだな。
省4
239: 2025/10/02(木)23:03 ID:jdy8/BVE(2/2) AAS
>>223
ユーザーは区間の記法だけによってどの言語を使うか選んでいるわけではないから、一概には言えない。
Pythonはずぼらだからはびこってしまった。あんな害蛇はさっさと駆除すべきだな。その点、Rustは
繁文縟礼の塊なのであまり普及せず実害は少ない。
C#はユーザーを十分獲得した後の2019年に半開区間..を初めて導入した。.NET兄弟のF#とPowerShellが
..を閉区間に既に割り当てていたのに、そして開発責任者はPascalと縁が深いのに、何であんな変な記法を
許してしまったの解せない。
240: 2025/10/02(木)23:12 AAS
>>238
いやRustなんか興味ないし知らん
どうでもいい
脳障害は日本語すら読めないだけ
人間は間違えないので猿を雇わなければ良いだけ
猿のために人間のルールを変えるわけない
241(1): 2025/10/03(金)00:09 ID:Q1aE47Vx(1/2) AAS
半開区間に左右非対称を採用してる言語はSwiftだけじゃね？
半開区間の記法
【start:end】 Go Python
【start..end】C# Rust Zig
【start...end】Ruby
【start..<end】Swift
この現状で左右対称を採用している言語はダメだと叩いている人は偏った異端者かと
242: 2025/10/03(金)01:07 ID:aYxPE6CF(1) AAS
1991 Python
1995 Ruby
2000 C#
2009 Go
2010 Rust
2014 Swift
2015 Zig
後発の方が先達の反省が活かされた洗練された記法を採用してる可能性は普通に考えられるかな
243: 2025/10/03(金)01:23 ID:Q1aE47Vx(2/2) AAS
C#が半開区間start..endを導入したのは2019年リリースのC# version 8.0
244(1): 2025/10/03(金)08:33 ID:qYL3CF1r(1/2) AAS
『Cなら知ってるんですけど、C++ってできますか？』
Cた間違い
245: 2025/10/03(金)08:35 ID:qYL3CF1r(2/2) AAS
CやC++初心者は間違い探し的に読むと良い記事。
246: 2025/10/03(金)10:41 ID:WGTRKW6c(1) AAS
>>244
モダンC++と言いつつ大昔の古臭いC++11で草
さらにC++11と言いつつ中核のスマートポインタを割愛で草
247: 2025/10/03(金)11:02 ID:gMkT4O8N(1) AAS
長文おぢウザい
248: 2025/10/03(金)23:27 ID:DEcBymr7(1) AAS
>>241
>>211に挙げた「両方ある」の7言語のうち「半開区間に左右対称記号を使用」の3言語を除いた4言語、
つまりKotlin, Nim, Raku, Swiftが半開区間に左右非対称の記号を使用している（Kotlin, Nim, Swiftは
..<で、Rakuは...^）。Rakuには左半開区間^...と開区間^...^もあり、4種類すべての区間を書ける。
これらに含まれる...は…と1文字で書いても良い。
Rubyは閉区間..より半開区間...の方が長いから、>>165がやたらこだわっている情報理論的効率性とやらには
反しているな。
249: 2025/10/03(金)23:28 ID:ft8WeviY(1) AAS
>>238
> 変数宣言でmutをいちいち書かせるなど
これはプログラマーに
mutable宣言を意味するmutなどを書かせるべきか
immutable宣言を意味するconstなどを書かせるべきか
どちらをデフォルトにすべきかという問題だね
これはimmutableのみが許されてmutableを許さないプログラミング言語もあるくらいで
immutableをデフォルトとして必要不可欠な変数のみmutable宣言させるのが正しいと思われる
プログラマーの手間もその方が少ない
250(2): 2025/10/04(土)14:05 ID:eyfPTg37(1) AAS
Qiita Conference 2025 Autumn というので
外部ﾘﾝｸ:qiita.com
> 今のコンピュータはAIにもWebにも向いていないので作り直そう
> 2018年にAttentionが発表され、2022年末にLLMが登場して以降、GPUを用いた生成AIがあらゆるコンピューティングの活用を塗り替えていますが、実はGPUが生成AIに向いていないことをご存知でしょうか？
> 他にも、現代コンピュータアーキテクチャ自体が約70年前に構想されて以来、スループット／レイテンシ／電力消費に根本的な課題を抱えたままで、WebやIoTなどの大量ユーザー利用／データ利用と言った現代に求められる様々は「エンジニアが無理やり何とかしている」と言う実態があります。
> こうした課題を生み出す裏側を解説した後、性能と省電力を圧倒的に引き上げるための考え方／イノベーションを共有し、実際の解決実装例をご紹介します。
コイツに講演させちゃうんだなあ。ゲスト講演ということだけどどうやって人選してるのだろう?
251: 2025/10/04(土)19:45 AAS
>>250
課題を生み出すwwww
省電力を引き上げるwwwww
これだけで価値がないとわかる
252: 2025/10/04(土)21:38 ID:MpcY569I(1) AAS
>>250
山崎かなと思ったら福岡Elixirって書いてあったから同族か
253(1): 2025/10/04(土)23:29 ID:gLEEZL45(1) AAS
>immutableのみが許されてmutableを許さないプログラミング言語もあるくらいで
マイナーな言語しかなくね？
「そういう言語がある」だけで、多くの人にとってはそれが便利だと思われてないと思うぞ
上下前次1-新書関写板覧索設栞歴
あと 515 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.027s