【画像】非プログラマーやプログラミング初心者はこういうの見ると気絶するらしいな [743999204]
■ このスレッドは過去ログ倉庫に格納されています
令和改元から５年…安倍晋三元首相インタビューを振り返る「憲法改正」「拉致被害者奪還」への思いと新元号に込めた願い
https://news.yahoo.co.jp/articles/b0c2fce1a04977a07bbaee6c999e91428178d071
https://i.imgur.com/H18fsjm.png
∧＿∧ ┌────────────
◯（ ´∀｀ ）◯ ＜ その意味不明なかっこはなんだよ！
＼ ／ └────────────
_／ ＿＿ ＼_
（＿／ ＼＿）
ｌｌｌ 94 警備員[Lv.21(前25)][苗] (ﾜｯﾁｮｲ dfba-nVjz) sage 2024/05/03(金) 10:46:41.93 ID:c7/D1hK40
わいの庭もどくだみ？がこの季節になると生えてきて抜いても抜いても生えてくるんだがどうすりゃなくなるの…
冬には枯れるんだが春になるとまた生えてくる
https://i.imgur.com/6igG12a.png
書いてるほうもあんま意味わかってないから安心していいぞ プログラマーでも触った事ない言語やスパゲッティコードみたら頭抱えるぞ キーボード変なとこ押しちゃってこれ表示されて「わぁっ！」ってなる jsわからないけど意味はわかる
非同期処理むじゅい… 至ってシンプル
Reactでaxios使ってる時点で結構ニッチ スクリプト言語なんだからもっと完結に書けるようにしたら良いのに 読めるけどコールバック系は動作確認面倒くさいから嫌い
スコープとかも考慮事項増えるし
>>21
雰囲気でJavascript書いてるからわからん 今は全くわからんけど
ちゃんと教えてくれるなら
理解できるようになる自信はあるで >>10
async awaitは単にコールバックを別の書き方してるだけ
だからawait後のコードというのはシームレスに見えて実は別のスコープ 無名関数を説明するためにコメントを書くくらいなら名前付けたほうが良くないですか？ >>27
>>24こんなこと書いちゃうのに理解できてる側スタンスで行くのか？ JavaScriptなんて簡単だろおじさんがこういうので躓くのはわかるw
COBOLとかVB6みたいなのしか書いたことない人だと職業プログラマを自称していてもキツそう useEffectは非同期処理を扱うためのものではないから中でaxios.getやってるのはあんまいい例ではない
カスタムフックのコードの一部なのかもしれんけど JavaScriptなんて難しく書きようがなくないか
特に9行目の最後の()が意味わからん
何これ 
mapとかfilterとかの処理は読みやすいからいいと思うけど
アロー構文って読みにくいだけだよな？？？ 何やってるかわかりにくすぎ
>>35
非同期の関数をアロー構文で定義した上で、その場で実行している >>35
作った関数(Yahooにアクセスしてレスポンスをとってくる処理)のその場での呼び出し
( 関数の定義 )() で関数を実行
JQueryとかでもよく使う構文 >>29
行くよ
なんせnodeのWindows非同期実装に実際携わった経験あるからな
お前みたいに内部でどうなってるかなんて知らずとも使えるようにな もうこれ暗号だよ
useEffectという関数を呼び出して
第1引数に関数、第2引数にからの配列
そして、第1引数の関数はその場で定義
わけわからんわ コールバックは知ってる人には簡単だけど
JSの非同期は誰でもすごく難しいはず >>26
次々と新しいものが出てくるから本業じゃないと
すぐにわからなくなるな JS特有の奇っ怪なコードはこういうもんだと思うしか無い
一からこういうコードを書くことなんてまず無いから考えるだけ無駄 文系だけど気分で付けたり付けなかったりしてるのは分かる
作者の気持ちは分かるんだよね TypeScriptじゃなくJavaScript書いてるやつは総じてポンコツ
どんな小さいプロジェクトでもTypeScriptをかけ
anyなんか使うなよ >>44
そもそもjsはコールバックだろうがawaitだろうが必要なもんは勝手に自動的にキャプチャしてくれるから何も難しくないように出来てるが >>49
ぶっちゃけプログラム読むときって
作者の気持ち分かる奴の方が読みやすいと思う
作者のレベルに合わせて感情移入しながら読むと謎が解けたりする >>52
アロー関数はthisの関係でナチュラルなthiscallから一手間加えないといけないから大抵の実装において微粒子レベルで遅くなるからな ワンショット継続は別にJSに限らずRustもそうだろ
ただAlgebraic EffectsはOCamlやKokaぐらいしか知らんわ >>31
外部APIなどの結果を受けて再レンダするものだからこれでいい
jsではfetchなどはすべてpromiseとして返すので COBOLで言うと非同期のジョブ起動みたいなもんか
この別プロセスに投げた処理を監視する処理を書いてなんかするって話？ PCやアプリの不具合で色々検索してこの手のスクリプトを「分からない人はこれそのまま貼り付けてくださいね」とコピペさせてくれるブログって超有能よな >>55
ほんとそれ
いろんなプロジェクトで他人のコード保守してきたけど前任者がどんな人だったか分かるとコード読みやすくなる なんか非同期処理っぽいことをしてそうってのしか分からん かっこがどこからどこまで括られてるのすらよくわからない
それは慣れればすぐわかるの？ たまに改造するため書き換えたりするけど
カッコとかの意味分かってない 読めるけどさ
Javaおじさんからすると背中がかゆくなる感じのコードだな
アロー式がやっぱ馴染まん すでにある環境で動かす事が出来る奴は山ほどいるが
1から言語もプラットフォームも好きに決めて良いよって言われて構築出来る奴は少ない >>70
プログラミング用のエディタ使えばカッコ範囲可視化してくれる
VSCodeとか使わずともnotepad++みたいなメモ帳レベルのアプリでもそれくらいはやってくれる >>70
エディタが対応するカッコを色でわかりやすくしてくれないと、普通のプログラマは認識できん。
カッコの対応が取れてないとエディタが文句言ってくるから大体わかる。 比較的キレイなソースだな
もうちょっとキレイにすると、保守性あがるよ >>33
もちろんこれが何やってるかすぐ分かるよな
((A,b,e,Sin,z,o="F8L、|、'、|…|#nO、|]4J|!M、|||MF|G#%n0F|!i]8|8g|6E"[e](/[ -z]/g,_=>Sin(111**2+_[z]())).split`|`)=>A[b]=A[b][e](/[て-にをは](?=[一-龍])/g,(_,i)=>_+o[i%3]+o[3+i%5])[e](/[た-る](?=。|\s*<\/)/g,(_,i)=>_+o[8+i%2]+o[10+i%3]))(document.body,'innerHTML','replace',String.fromCharCode,'charCodeAt') >>62
現在のプログラミング言語では、非同期処理はマルチプロセスどころかマルチスレッドですらない
シングルスレッドだけど、IO処理待ちとかがある場合、他の処理を優先する 情報系学生だけどよくわかんない
エラーのなんたらみたいなくらいの認識 >>76
畳む機能勝手に発動して邪魔だよな
設定で外すのもめんどい
簡単なんだろうけどめんどい >>80
正直正規表現だけは何十年プログラミングやってきてもスラスラは書けないな
チャッジーピーに生成頼んでも今一目的の動作にならんしここだけはマジでAIに頑張ってもらいたい jsて次から次にフレームワーク出てきてるけどなんでこの言語だけこんなたくさんでてくるの
javaとかspringくらいしかないやん
フレームワークの作り方とかわからんけど作るんなら機械語も理解できてないと無理なんかな useEffectに非同期処理はオススメしない
Reactの`useEffect`フック内で非同期処理を直接行うのは推奨されていません。これは主に、コンポーネントのライフサイクルと非同期処理の完了タイミングが一致しないことによる問題が発生するため >>85
アローとかも可読性ガン無視で癌すぎるよな こんな書き方するんだふーん必要になったら覚えよで流す 
Use Effect でヤフー表示って、どんなエフェクトだよｗ >>89
書いてて思ったけどAIが正規表現生成できるようになったらそもそも正規表現いらんか
indexOfとかfind系関数の長ったるいコードを直接生成してもらった方が実行効率は良いもんな
実際.NETはコンパイル時に決まってる場合はこの方式になったみたいだし >>92
可読性が悪いって皆が思ってるからリガチャ記号とかが発明されるんだよな
本末転倒感が凄い 20年ぶりにプログラミングやってるけど最近のはわけワカメ まあ素のjs使ってるやつはほぼおらんからcみたいな扱いではある。
なんでこの言語がってのはあるけど、ある程度緩くて古くからある普通の文法だったからってことくらいしか理由を思いつかん。 >>63
こういうのってdataが返らないで
console.logの返り値が返るんじゃないの？ >>63
async fetchData () => {}
fetchData()
じゃダメなんだっけ？ >>1
こんなのよりファミコンの開発秘話とかの方がおもろいわ
ファミコンファミコンいうが当時としては高スペックだったからな
それが14800円
>>63
axios.getの.getを書き忘れた Lispならもっと綺麗に書けるよ
カッコをけちると、結果的にはこうなる 非同期の難しいのはスレッドじゃなくなった分
レスポンシブネスが低くなってしまった場合どうするかが難しい
内部のキュー構造や描画との関係 aync awaitが使えるだけマシだけどな
もしこの構文が無かったら、この例だと少なくともconsole.logの部分が更にコールバックになるわけで
これくらいのコード量なら読めるがもっと長くなると頭痛くなりそう >>1
>>63
const { data } がよくわからんな
なんでconstつけるのか
{}もわからん🙀 非同期な関数を無名にして即時実行する
とかわかりづらいよ
ここ1箇所読むだけならまだいいけどいろんなとこ合わせて読むんだから
>>101
普通はfetchDataの中でsetStateするのでfetchData自体に戻り値は必要ない。fetchDataが実行されさえすればいい 無意味な入れ子構造はスコープがぐちゃぐちゃになるからやめろ useEffect内でasyncの無名関数実行ってReact慣れてたらよく見るコードだから読みづらさは特に感じない 全然マシなほうだろ
this使い出してないからいい >>85
その場に処理が書かれてるから処理を探しに行かなくて済む
一回しか使わない処理をどっか遠くの方に書かれると探しに行くのが面倒くさい >>113
{ data: data }の省略
オブジェクトリテラルの省略記法とかググればわかる
>>113
スプレッド構文（だっけ？）使わない場合はこうなる
const response = await axios.get('https://www.yahoo.co.jp')
const data = response.data
console.log(data) 値をエンクローズするためだけど、オブジェクト指向には過剰実装だな。 if（abe）｛alert（´駆け抜けようじゃありませんか！´）｝ ラムダ式その場で使い捨てるやつってJavascriptでしか見ないよな これが分からないやつはrustみたら泡吹いて失神しそう >>119
Javascriptでスコープなんか気にしてたら胃が壊れそう >>128
？そんなんJavaでもKotlinでも見るぞ 全部オブジェクトにするか全部ラムダにするか
のどちらかだな。ごちゃ混ぜはろくなことにならんよ >>122
フロントで非同期処理書くならどうしたってこれくらい汚くはなる。 >>34
一文字打てば予測変換出てくるし、コピペだし、どれコピペすればいいかを経験で養っているだけにすぎないよ
昔より敷居は異常に低くなっている 最近は予測やコンパイラエラーが詳細に書かれすぎていてノリでいけるらしいな
Rustでファミコンエミュ実装してるの見てまったくわからんけどノリだけでいけそうだと思ったわ >>133
見るというか書かせたらだな
見た目の汚さならVBが一番だわ 無名関数なんて使い捨て当たり前でそれをラムダで書くなんて当たり前だろ
使用しない言語のほうが珍しい >>135
C++をマスターする難度を100とするとJSはまず10もないな
C++を完全に理解したと言える日本人は100人もいないはず rustでフロント書くとか明らかに向いてないがwasmでアホみたいに騒ぐバカは減らんのよな。 >>147
マスターってSTLみたいなちょうやばライブラリを一から作るとかそういった話？
やってることを見てわかりやすいのはC++は圧倒的だと思うけどね
もちろん俺はSTLみたいなライブラリを作れないとｗ
初心者の頃に「よーしaxiosでウェブAPIからデータフェッチする方法をググるかー」って>>1が出てきたら多くの人間は「コレムリ」ってなるだろ >>152
AIが予測して出すんよ
メソッド名とか処理内容わかりやすい名前にしたり
細かい処理内容コメント書くとあとは勝手にその処理らしきコードがまるまる出てくる C++は演算子オーバーライドあるから多用されると一部のコードみても意味わからんってなるね async callback useEffect(){
うんぬん
}
って書ける仕様には出来ないんだろうか 日本は衰退するうううよりこういうスレのほうが嫌儲らしいよな
俺はCしか知らんから幸せもんだったんだなぁ ずっと勉強してる奴って何を見て勉強してるの？
無能にはそれがわからないんだよ >>63
こういうのでいいんだよ
ぐっと見やすくなった 音楽オタク達と競わなくてはいけない
↑
こんなのと同じふんいきだよな 大枠C++
機能はdllにして下請けに出し好きな言語使わせる
最近はこうなんだろ？ asyncの中のステートメントはawaitまで並列で実行されるの？ useEffectのasync版欲しいよね
composeだと対応するものがデフォでasync用だけど便利すぎる
でもjsのPromiseは走り出したら止まれないからktみたいにスッキリした感じにはできなそう
自分はAbortSignalとDisposable組み合わせたカスタムフック作ってやりくりしてる >>153
ほんそれ
昔のBASICの頃のような最低限の知識で試行錯誤して動かしてみるのが初心者には難しくなってしまった
だいたい非同期処理対応と洗練され過ぎた構文のせい 今はAIが説明してくれるからめっちゃ楽だよ
初心者が自力で学ぶ場合、何をどう調べたらいいかがまず難しくて試行錯誤に多くの時間が必要だった
今なら直線的にレベルアップできる >>150
単に言語仕様を完全に把握するだけでも常人には無理だと思うが
わかりやすいってのはテンプレートメタプログラミングでも？ シンタックスハイライトされてないソースコードは俺も読めないわ
あと全角英数字をみると発狂しそうになる コードに異様なこだわり見せるヤツいるよな
綺麗なコードはベターだが動くことがマストで
可読性を上げる為に助長でもいいと俺は思うんだが >>168
可読性犠牲にするわりに効率はさほど上がらないし
使うことが目的になってるテンプレートで引き合い出されてもねぇ
まぁルール知ってれば時間かければ読めるよ stlってそんな凄いところあったっけ
libc++の正規表現は悪い意味で超凄いけど >>108
動くよ
人間が見やすくするために改行してるだけ 引数列の最初の方に長い関数直接書くスタイルが微妙
継続渡しっぽく最後の引数が関数ならまだ直接無名で書いても良いけど、この場合ならfetchYahoo切り出して書いといた方がチームには優しい
この規模なら大して変わらんけど async/awaitはとりあえずなんでもasync付けといて逐次処理はawait付けるだけだからだいぶ分かりやすい
promiseの時代は地獄だった C++やっぱ勉強した方がいい？昔に少し本を読んだくらいなんだけど
まだまだ使えそうなら身に付けときたい、どういう場面で使うの >>172
そらそうよ
大多数の人は画面1枚しか作らないのに馬鹿みたいに複雑な画面1枚になる >>180
すべての基礎みたいなもの
すべての派生元と考えるとこれはC++のここを改良したんやなぁってドヤれる >>172
読みやすい読みにくいも人によるからな
def a_and_b_and_c?
a && b && c
end
より
def a_and_b_and_c?
return false unless a
return false unless b
return false unless c
true
end
こっちの方が読みやすいって派閥もあるし >>180
バックエンドとかでC++ライブラリしかありませーんｗみたいな状況はあるのでそういった場合 業界自体言語関わらずtry catchでエラー文付けとけ系が当たり前な風潮怖い c++なんてオワコンだし覚えなくてよいよ…
そもそも言語なんて道具でしかないからやりたいことありきで何やるか自然に決まってくるものだと思うんだけど
自分は趣味で言語作るから言語勉強するのが趣味みたいなもんだけど >>138
先進的な言語で新しいふりして実装される大抵の機能はlispのパクリなんだよな
とっくの昔にlisperが使っていたものを数十年たってから取り込んでる >>173
＞使うことが目的になってるテンプレート
それたぶんC++を理解してると言えないレベルなのでは これEXCELの関数となんか違うん？
もっと複雑なことやってると思ってたから頑張ればすぐ理解できそう >>190
使えば使うほどデバッグしにくくなるテンプレート推奨って
あんたこそ理解できてないでしょ 今度Luaスレ立てて
1から数えるのは諦めるから複合代入とcontinue使わせろや 趣味で言語覚えるとかすごいなぁ
データサイエンティストの端くれなのだけど、最近サーバとかデータ周りの環境構築まで理解したいと思っててC++興味あったんだよね >>159
それ一歩目から間違ってる
プログラミングはお手本を暗記モノマネする学校教育的な手法が通用しないんだよ
いま世の中に無いものをものづくりしていかなきゃいけないんだから >>184
こうか？
デバッガが使えればなんでもいいけど
def a_and_b_and_c?
ret = true
ret &= a
ret &= b
ret &= c
return ret
end 人に笑われちゃうようなコードでも
まず自分で考えて動かす事が大事で
本をいくらリードしようがコードは書けない そのへんのライブラリを組み合わせるだけでしょ
欲しいの無かったら関数改造するだけでええっしょ >>197
そう？
オープンソースのライブラリとかいまでもCやC++多いじゃん
自分でprintf仕込んで動かしてみたら理解も深まるのでは
基本運用しかしない人でも C++テンプレートはコレクションクラス用って感じ
自分でテンプレートクラスなんて作るものじゃないね >>202
間接参照と関数ポインタとキャストの種類を触るとぐっと理解が深まるぞ >>196
白紙から書き起こす力が必要だよな
たとえ要件が決められててそれを実現するモジュールを作るだけであっても
Excelのシートですらそのへんの素人はセンスないから数式どころか表組からして崩壊してる >>204
関数ポインタへのポインタとかポインタ入れた配列とかよくやるよねw >>147
C++マスターだけどjsってjs単体での開発になる事はほぼ無いから言語同士で比べてもな
まあいずれにせよ難易度は確かに低いけど難易度と開発労力は別物だからあんまり難易度を測る意義を感じない
難易度で言えばカーネルドライバ開発とかより競プロの方がはるかに高いけど色々ひっくるめると結果難しいのはやっぱり前者だしな >>203
任意の型を複数ぶち込めるメソッド作るのに使うよ
昨日Claude3に関数書き直してもらったんだけどさ
俺はforループを書くほうを選んだよ
https://i.imgur.com/MKGkZ0V.png
もう俺はAIにはついていけないんや >>205
車輪の再発明って学習においては最重要よな c++だとラムダ渡すのにすらテンプレ必要だからテンプレなしのc++ってbetter c的あるいはjavaっぽい運用になる印象
批判するつもりはないけど特に後者はヒープ確保も型消去もしまくりでc++じゃなくてよくないかって思う >>206
その自由度が欲しい場面もあるからなんともね
C++知ってるとこれできないんかが多すぎる
TypeScriptなんかどうせコンパイルするんだから
別のところで名前付きでawait fn some_method() {}の形で名前付きで定義したものを自動的に無名関数に展開してくれるようにすりゃいいのに
fnとfunctionが違うから判別できるやろ
保守する時は名前つきの方が何してるかわかりやすいやん 引数を渡すカッコと論理的に区切るカッコは、確かに分かりづらい
一度内容を考えたあとは暗記するのが楽
内容を一切考えずただ丸暗記するのは常人に辛い 低学歴だけど英語力活かしてブリッジエンジニア？系のSESから内定もらって
今CCNAの勉強中なんだけど普通に理解できねえ
これ覚えないと無理なのか？ STLにテンプレート使われているのが許されているのはバグがないこの一点のみ
自分でテンプレート書いてデバッグしないといけないのは悲惨 >>217
そんなもんいらねえよ
オフショアがいい加減なことやってないか監視するのがお仕事 PythonとVBAとT-SQLぐらいしか触ったことないけど、パッと見ても何してるか全然わからん
世の中にはこんな難しい言語もあるんだな >>207
凄いな
俺は数十社で使われるクラスライブラリの設計や実装もしたけどマスターとはとても名乗れない
パフォーマンスには心血注いでるし当然内部はテンプレートでメタいことになってるけど
割と雰囲気でつくってる部分も多い >>1
えっと何が難しいわけ？
単なるNode.jsのコードだが？
おれアロー関数嫌いだからこういう書き方しないがね。コメントもつけてない時点でザコだあい０ >>221
今のc++はconceptsあるからだいぶマシになったよ
自分の作ってるものもsfinaeやめてあらかたrequiresとかconstexpr-ifに置き換えたけどめたくそ読みやすい
それでもrustに比べたらウンコだけど >>1
これC#やろ
C#の非同期のラムダは俺も苦手
Linqもまだまだ使いこなせてない >>225
俺はそもそもx86アセンブラマスターだからぶっちゃけ言語が何であろうと内部的にどうなってるか大体把握可能だからな
C++使っといてテンプレートをサタン視してる奴は意味不明だと思うけど >>228
Linqをパフォーマンス的に避けてるならまだしも使いこなせてないってことはsql文も書けないってことだからそれは危機感持った方が良い 個人的にテンプレが嫌なのはideが重たくなること
基本コンパイル時ダックタイピングだから高速化難しそうだしそれ以前にlspクラッシュしまくってナビゲーション機能しなくなる
メモ帳で開発してるようなもん >>209
全然forでいいけど俺だったらそこで言うwithRetry関数は切り出して結果ある時はbreakするようにする
ネストぶち抜いて大元の関数をreturnすると制御の複雑さが増して忘れた頃に自分で何書いたかの推論が難しくなる これは大した事ない
もっと何でこんな書き方？みたいな天才のコード見ると気絶する 全然わからねえっす
useEffectの第1引数これ結局Promise渡してるんじゃないの？ テンプレ多用
再帰多用
こいつらは使うことが目的になってるから不要
デメリットに目を瞑りすぎ >>235
Promiseは第1引数の無名関数内のasyncのところで発生してる
が誰も受け取ってない
独立的にgetしにいってさいならっていうコード >>237
テンプレは完璧主義者が多用してそう
エラー系の処理でケアしなくていいところまでケアしてるイメージ
再帰はそもそもこの世に再帰的なものが多いから仕方ないと思う 再帰はバグったり変な入力受け取ったときに大変なことになるからノウ🙅 >>242
キャッシュ使い潰してパフォーマンスも落ちる ラムダ式のカッコを無理矢理C言語文法にぱっと見近いjavascriptで書いてるだけだね
この辺り、言語毎に一見難しい書式を車輪の再発明してドヤ顔する風潮があるけど、言語拡張で書式をいくら追加しても、他言語を含む視点から概観すると別に新しい事をやっていなくて、コマンドラインのワンライナー(1行で割と面倒な処理を書く芸当)のようなものだね >>228
文末にセミコロン付いてないからC#じゃない
あとC#では曖昧な型は使えない
まあvarとかあるけど genericsはともかくreflection的なものは身に余る強大な力になってコンパイラに守られてた世界破壊しがちだから忌避するのは分かる
一時期のGoFのデザインパターンなんかも要らない場面で使われすぎたし、背伸びするよりは基礎守ってくれる人の方がありがたい >>242
末尾再帰最適化できる形か否かを、コンパイラとの常識勝負で書くのがスキルある人のやり方だし
そもそも基本スキルがないから再帰関数禁止とか気の違った主張するだけでしょ
言語処理系やパーサーは再帰が基本
それを再帰じゃない形に書き換える必要があるのは、たとえばメモリやリソースの限定された組み込み用とかで
その場合は状態遷移テーブルとかで処理だね JSがクソな理由が詰まってるな
慣れたら意味は理解出来るけどキモい >>248
多用しなけりゃ使って良い
必要ないところまで適応しようとするアホに向けて言ってる ここの会話についていけるの感動する
俺も少しは成長してるわ >>247
GoFのデザインパターンなんて、SmalltalkからC++/Objective C等々にノウハウを移植する時に書かれて
それを1990年時点のスタート地点にしたものだから
そもそもSmaltalkのソースと格闘した経験のない人がわかったフリして仰々しく使うのは間抜けの極みだね
過去約35年間見てきて、Smallltalk経験ある上でデザインパターンを議論する人、国内にはほとんどいないね
物凄い人はその裏の裏まで追っかけてるけどね >>230
カーネルドライバはI/Oポートを直接たたくDOS時代ならいざ知らず、システムコールAPIsの技術資料を持っているか否かで決まるわけだからハードルが高いのは当たり前
大手企業には高額でこっそり公開しておるようだけれども >>250
エアプログラマワロタ
多用とか多用じゃないとか、商用/研究開発/オプソのプロジェクト毎に基準は変わる話であって
何の基準もなく「使い過ぎるのが良くない」とか気狂いだわ >>254
必要ないところまでって定義しただろ
定義読めないとかお前プログラミング下手そうだな そもそも再帰関数程度で「使い過ぎは良くない」とか言い出すのは
再帰関数の使い方、コンパイラの最適化が掛かるか否か、本質的に再帰であるものを再帰でない形に書き換えるにはどんな技法があるか
とかの基本がない人の寝言だよね >>256
お前の書き込みは根拠のない寝言しかないからNG済み GoFだとビルダーパターンだけは非常に重要と思う
他はまあ…コマンドパターンとか形だけならよく現れるものもあるけど、より浸透した別の語彙で表されるから覚えても使うことないと思う パターンとして示されるまでもなく、普通に考えてその場で実装するとそのパターンになる例も山ほどあるわけで
どのパターンだけは使えるとか言い出すまでもない定石集、ただしSmalltalk→C++ (1990年当時)の文脈の話 現場猫「thisが何を指してるかよくわからんけ動くうちは気にしない」 機能使いこなしてます系プログラマは本質に迫っていない
だから使うことが目的になっていると言っている GoFの話、国内にSmallralkとの対応で実感を持って話をする人が全く居ない事に気付いて以降
匿名掲示板やTODOでGoF GoF言ってる奴は
単なる基本知識として名前を出しているだけだとわかったから相手をする価値を全く感じない
具体性ないしね
基本的なパターンは意識しなくとも繰り返し発生するから、文脈や言語や時代に応じてパターンは移り変わり
あえてGoFにこだわる必要はない(Smalltalk→C++ (1990)周りの古典調査除く)
ってのが、GoFから学ぶべき事 使いこなせないやつの負け惜しみになってないといいな useEffect多用するのやめろ
処理の流れグチャグチャなんだよ レイヤーこそ違えどGoFはdddでいうユビキタス原語でエンジニア間のコミュ円滑化の意味合いが強いので定石集ってのはちょっと違うかな >>270
あの問い合わせて受け取るって悪しき風習でグローバル変数は悪！ってなってたよな スプシの自動化のためにGAS組み始めた程度の初心者だけど、次は何をすればいい？ だいたいGoF以降のパターン本なんて90年代半ばから後半にかけて国内入手可能なだけでも20冊くらいは出ていたわけで
そっから25年近く経って未だにGoF GoF呟くのは
パターンを意識できずに初頭文献の話ばかり繰り返す初心者だよね
もちろんパターン文化研究の原典の一つとしてGoFの名前は出るけどねぇ
25〜35年経って未だに内容を理解していないんでもない限り、開くことは滅多にないよね >>275
お前の話は何の価値もないから全く読む必要性がない >>278
んなこと言ったら冗長な言い回しでsmalltalk連呼してるお前の話の方がなんの価値もねえよ
一回言えばわかるぞジジイ >>274
DDDの方？
コミュニケーション面を重視するなら「パターン言語の共有は重要だ」って1980年代建築家がパターン言語を提唱してきたわけで
そこで今さら内容への言及も、使えるパターンの把握も意味不明な状態でGoFを連呼するのは、ディスコミュニケーションだと思う
ほんとびっくりしたぞ、国内はSmalltalkもやらずにGoF GoF言ってるだけの人しか居ない
>>273
依存配列が空じゃないuseEffect複数書いてるとピタゴラスイッチ作ってる気分になってくるね >>280
お前はもう、いつものストーキング常習精神異常者だとバレたのだからさっさと専門病院に帰れよ smalltalkガイジ「全く最近の若いもんは…smalltalkを知らんとか…」 実は国内PLoPに一瞬だけ足を突っ込んだ事があって
まあ本家はWikiの実用実践第一号でもあって1990年時点では良いコミュニティだったのだろうと思うけど
自分が首を突っ込んだ時はもうSmalltalkに基づく話ができる人が見当たらなくなっててガッカリしたよな
何とかガスなんとか研の方には居たはずだけど 16進数文字でコード打つ産業にしてからプログラマー増やせよ
英語ネイティブじゃないとわからねえ >>285
話し相手いない寂しいお前の自分語りの場じゃないぞ >>287
精神病院へ緊急入院したほうがいい
お前は連休になるたびに粘着を繰り返すから
お前の職場も監督官庁も呆れているぞ 258 名前：番組の途中ですがアフィサイトへの転載は禁止です 警備員[Lv.39(前12)][苗] (ﾜｯﾁｮｲW 87af-K2we)[] 投稿日：2024/05/03(金) 13:22:41.37 ID:e8L8VwT20 [6/15]
>>256
お前の書き込みは根拠のない寝言しかないからNG済み
NGできてなくて草ｗ smalltalk連呼のゴミ糖質ジジイ成敗したしゲラゲラ笑ってるｗ >>294
今は校正もAIで想いのままだし戦うくらいならツールにぶち込むになってそう この人たぶん、1998年とか2000年頃から25年間近く匿名掲示板で精神異常の独り言連投をしている廃人の人だよね
以前はム板やマ板にこの類の精神異常者が来てたけど
わざわざ嫌儲で精神異常発作スレを立てるとは
どうしようもない廃人だよな
つまらん煽り合いでスレ潰すなら大砲うつよ >>158
向き不向きがあると思う
有名大学の情報学部でもわからないって奴も多い
かと思えば専門学校卒とか小学生でも興味持てる奴はスラスラやるからな >>300
３分で復帰するどんぐりのレベルなんて誰も気にしてねーよ
>>297に打ってやれよｗ >>191
同じだよ
エクセルの関数からVBA覚えれば
あとは応用でいろんな言語覚えられる >>158
まあ大体はｼﾝﾀｯｸｽの話になっちゃうし >>6
reactの場合はjsxと一緒に使うんでどうしてもテストが深くなるから2タブになる 今どきaxiosなんか使わんでええやろ
fetch使えや
JSのHTTPサーバも自前のfetch実装してサーバにするのがモダンだぞ
Honoとか
この前やっとバージョン1になったaxiosさん使ったらあかんの？ >>311
君が嫌いかどうかは誰も聞いてないし、そういうスレでもない。 ルーティングの最初の一発目だけ実行だっけか
useEffectの依存配列が空って >>315
俺は感想を書いていないｗｗ
反論の為の反論なら書かなくていいよ蛆虫 >>63
js知らんけど、うむ
(lambda...)() ←これやめーや htmlとvbaで少し見たからそこまでだな
俺的にはデザインのがしたいけど >>184
後者はvariadicなのよく書く人のクセ？
def jmc_test_from_fwd
for arg in args
return false unless arg
return true
end
を手で展開するとそうなる フレームワークとかいっぱいありすぎてもう訳わからんね
結局クライアントのブラウザとサーバーのやり取りなんでそ? プログラミング言語なんてどんどん新しいのに置き換わっていくんだから
趣味で覚えたところで数年後には何の意味も無くなる >>198
わざわざこういうの書く場合はearly exitを求めてるのでは
a,b,cの読み出しがvolatile(デバイス等)だとか引数がコールバック関数だとか
jmcスタイルの論理評価は単調性のある場合のみ(&&、||等)にしか定義できないし(不可はxor等)、単に既存の演算子でつらつら書くのが複雑ならやる 単純化した例だと掴みにくいけど
条件に合致したらすぐreturnは読みやすいと感じること多いかなあ
続きの処理で考えなきゃいけないことが減っていく快感がある
単式ならorの方がいい場合多そうだけど複雑化するなら分けた方がいいかな >>328
フレームワークありすぎからreact一強くらいにはなってるから
不勉強なだけだよ try catchとか使ったことないわ
axios使ってるならAPIのエラーハンドリングはステータスで分岐させるだろ >>11
Ciscoのパケトレじゃん
こんなの単なるstaticな設定であってスクリプトではない アロー関数慣れればそこまで難しくないよ
C++でも使うでしょ >>335
非プログラマーなのにC++だけは異常に詳しいとかコピペの最低野郎かよw 発狂してストレスの頂点だけどMODとか作るときに無理やり触る羽目になるときがある 結局フロントで非同期処理書こうとすればこうなるんだからどの言語でも一緒だよ。 c++の細かい仕様について偉そうに解説してた末路が江添だぞ。 >>331
これやるとソースコードが美しくなる実はものすごく価値がある情報なんだけどサラッと書かれてるからみんなありがたみに気づかない アロー関数とか省略if文とか見てると殺意湧いてくるわ
記述方法は言語仕様として統一しろよ。余計なもんいくつも用意するな >>2
右下にある穴の空いた丸い石は石臼だよね
俺の実家にもあったわｗ グーグルが戦略的にjavascript流行らしたんだろうなあ >>63
お前前も馬鹿みたいなコード晒していたけど
日常的にくだらないコード書いてんだな 数学よりマシな気がするのは私だけか
あの記号だらけの数式には耐えられん >>123
素人質問かもしれんが
一回しか使わないものは関数化の必要なくない？ >>198
> ret = true
retにぐちゃぐちゃ代入
> return ret
これ止めろ馬鹿 >>341
なんで？
プログラミング知らないけど= or >より手間が省けてマシだろ 関数を引数にして渡せるって所に未だに頭がついていかない
オブジェクトに閉じ込めてわたしてえんだ… >>332
jqueryとかyuiとか使ってたけど消えていくのが辛い
もうインフラ屋になったけど素の古めのJavaScriptでいいやってなる。覚えるのが無駄
高階関数って言いたいだけやろ
Higher order functionってかっこいいじゃん
あとIncremental Static Regenerationとか 寧ろアドレスでしかない関数を変数として扱わない方が違和感あるよな
それに要は定数をx=>xの写像のバインディングだと思えば良いだけで
ファンクショナルの方が数学的にはシンプルで美しい(´・ω・｀) ReactOSは、オープンソースのオペレーティングシステムである。Windows互換のオペレーティングシステムを目指し、開発が進められている。 テンプレートメタプログラミングの邪悪さに比べたら
ラムダ式くらい屁でもねえよ 無意識にCtrl+Kを押したくなったけど、どのエディタのショートカットだったかさえ覚えていないポンコツになってしまった >>354
関数渡す方が直感的な気はするけど、まあ好みの差かね。 >>353
君みたいに間違えるひとがいるからやろなあ axiosって何のために使うのかいまいち理解してない
fetchでよくね >>367
fetchが無かった頃とか古いNode.jsで動かす場合とかで必要だったが今使ってるのは頭がおかしい useEffectの中でAPI叩くとか結構前のコードやろ
未だにやってるなら書き直したほうがいい
>>370
どうやるのがいいの？ この実行結果がどうなるかプログラマなら見ただけで分かるよな
($=>$[$](/$/,($$,$)=>$))('replace') パッと見ただけで誰にでも分かるような書き方をするのが良い
品質デバッグコストに影響してくる ゲームエンジンのブループリントみたいなやつで完結できないもんなの？ HTMLくらい齧ってれば、こんなんで気絶はせんやろ ■ このスレッドは過去ログ倉庫に格納されています
