コネクションプールで溺れる人もいるのかな
たいへんです！スレッドプールで溺れてる人がいます！
これ、まー文字通り読んでも、単に大きいと言ってるだけなので、下品だけど差別的かは分からないな
Haskellや"ちゃんとしたTypeScript"と比較すると、正直動的型付けそのもののメリットはほとんど感じない（個人の感想です）
ダックタイプがちょっとしやすいとか、本当にそれぐらい
Javaの静的型付けと比較すると、クラスの多重継承できないし、トレイト/mixinみたいなものも書きにくい…メソッドの実装を継承させたい場合、抽象クラスを書かないといけないけど、インターフェイスみたいに多重継承できない
インターフェイスだと実装は自分で個別に書く必要がある
C#ではこのような問題をだいぶ昔からdelegateやラムダで回避していて、Javaも最近はそういう実装ができるようになってきているけど、メソッドそのものを付けるというような事はしにくい
動的型付けの場合は、型自体をReflectionとか使わなくてもその場で定義することができて、メソッドを増やしたり減らしたりも簡単にできる
ただ、それらの機能が致命的になる事は、普通のWebアプリを作る限りではそんなに無いような気がする
トレイト/mixinが必要になる時点で、設計が出来ていないという考え方もある（これは状況による）
あとは、ソースをコピペで断片で動かしにくいとか、そういうことかな
PHPは対話的に動かすの微妙だけど
動的型付け - Wikipedia https://ja.wikipedia.org/wiki/%E5%8B%95%E7%9A%84%E5%9E%8B%E4%BB%98%E3%81%91
Example a = new Example();
a.method1();
静的型付けの場合はExampleクラスにmethod1メソッドが定義されているから実行できる。
let a = {};
a.method1 = e => {console.log("hello");};
a.method1();
動的型付けの場合は実際にmethod1メソッドがあるから実行できる。
という静的型付け系ばっかりやってたぼくの認識。
Javaのvarも静的型付け
コンパイル時に、文法上この変数の型はこうでなければならない、というのが一意に推定できる場合に限り、型を推定する
それがvarの型推論
Javaで動的型付けに近い動きをするのは、例えばキャストするとき
例えば、あるメソッドにObject型の引数objを渡したとき、このobjは実際にはObjectを継承している何かである事があり得る
キャストをするような場合は、実行時にobjの型を見ることになるので、（Javaは言語としては静的型付きの言語ではあるものの）実質的に動的型付けの動作になる
varの型推論は、コンパイル後にランタイムエラーを生じる事は無いのに対して、キャストはランタイムエラーを生じる
プログラミングの入口が静的型付け言語だった人は後者じゃないと不安になるイメージ
さっきの、あんまり冗談ではなくて、it's yellowって
var sb = new StringBuilder();
とかと同じ感覚なんだけど、
StringBuilder sb = new StringBuilder();
と書いたほうが良いと考える人も一定数いる
右辺がnewならまだわかるけど、例えばFactoryとかでcreate()みたいなのをすると、型推論的に自明でも人間が見た時にこれって何と思う人がいる場合はある。
そういう時でもわかるレベルできっちり書くか、この文脈だけ切り取ってわかる範囲で雑に書くか。私は後者の傾向が強くて、相当雑である自覚がある。
この性質は、本当は文系理系とは違う性質だと思うんだけど、いわゆる理系っぽい理系の人は前者の傾向が多い気がする（自分が理系っぽくないという自覚がある）
物事を客観的に、自分で見えている範囲はそれの全てではない、という思想を徹底しようとしたら好きとか嫌いとかの概念がかなりなくなった時期があって、それはそれで結構苦しい
何か悪いことが起きた時に責任の持って行きどころが自分しか無くなってくる感じがあった
一字一句正確に答えないと一生繰り返されるタイプのレッスンなんですよ
https://english-bell.com/ja/info2/class9.html
りけいっぽい！
私は雑なのでyellowと答える可能性すらある
好き嫌いも比率の問題なので…
純粋に嫌いなものが全く増えないという事はないだろうけど、それ以上に好きなものが増えるべき
基本的には、色々な物事を深く知れば知るほど想定外の面を見ることになるので、物事を減点法で評価していると、深く知れば知るほど嫌いなものしかなくなる（その場合、究極的には、深く知った先には嫌いになる事しかない）
それよりは、減点したくなる面それはそれとして、加点すべきポイントを考慮して、嫌いになるのと同等以上に好きになった方が良い
深く知れば知るほど好きになる傾向があるか、深く知れば知るほど嫌いになる傾向があるかは、何らかの人間の本質を表している気がしていて、前者の方が生きやすい生き方だとは思う
似たようなものにQuestionnaireとAdditionalFieldというものもある
前者は横持ちで後者は縦持ちという、もはや言い訳もできないクソ仕様である
一応、前者は性能を評価して、後者は柔軟性を評価した結果なのだけど、まあしかしクソ仕様としか言いようが無い（しかも自分で作っているから何も言い訳ができない）
こういうのにあんまり悩みたくないので、jsonをserializeした結果をDBに保存する方向にしたいという思いがあるが、そうするとバグった時に大変
あと、集計に少し難がある
うーん、という思い
"くじ"に相当する機能について、別のユーザーからのニーズで３種類実装する必要が出てしまい、Raffle/Provision/Lotteryという謎の呼び分けをすることになってしまった。
それぞれ利用シーンが全然違っていて、日本語では 即時抽選/事前抽選/くじ と区別しているけど、こんな概念どんな一般ユーザーが理解できるんだろうか…
かつ、これらの機能を説明できることを求めてしまうので、営業に高いリテラシーが必要になってしまう
面倒なので、とりあえず全部「できます！」で受けてもらってから、内部でこっそり超複雑な仕様を活用して、それを全く表に出さないという方式を定着させつつある
本当はシンプルにしたいんだけどなー
サブちゃんは絶望の呼び声ーー
デスルート
ちわーっす。三途河屋です
サブちゃんはいつも絶望していたのか（闇）