  |
はてなキーワード: 型推論とは
JVMはいいんだよ。マジで素晴らしい。Javaはあまりにもクソ過ぎる。
不完全な型推論、あまりにも冗長すぎるモジュール機構、ファーストクラスじゃない関数、なんでもクラス、ザコみたいな型システムに由来したあまりにも乏しい表現力。
あげてもキリがないほどのクソofクソ。このそびえたつクソに燦然と輝く究極のゴミ、そう我らが springframework。
マジでイカれてるよ。直近のJDK21で導入されたJavaの言語仕様としては instanceof 以外で正気を疑う進歩のなさ。どうしてこんなゴミがのさばってるんだよ。
まじで新規案件はKotlinかScalaにしろ！！！！！！(Scalaをまともに使える能力も判断力もない人間がなんとなくJavaを使うんだろうなあ)
型推論はメモリ節約のためじゃなく型エラーを出すことで問題を早めに検知できるようにするためにあるんやで。
動的型付け言語使ってたら誰でも「"12" + 3 → "123"(15にする意図のコードだった)」というバグを経験してるやろ。
なんか以前からずっと思ってたんだがRailsというかRuby界隈は宗教というか自己啓発ビジネス臭さえするのがイヤだ
金持ち父さん…とか７つの習慣とか、そういう詐欺のカモっぽい人も多いイメージがある
しかし、Ruby登場当初からやたらとエレガントに書ける、スッと書ける（この「スッ」という表現も詐欺で多い表現なので嫌い）とか、
そんなことは個人的にはどうでも良くて、ソフトウェアを使うユーザーは機能が便利かとかそういう視点でしか見ない、悲しいけど
保守の観点からも美しいソースコードを書こうという意気込みは間違っていない、というか正しいと思う
しかし、プログラマーが美しいコードが書けたと悦に浸る、自己満足におちいっているだけのようにも見えるのが納得いかない、不愉快にさえ思える
C++やJavaのような型のあった時代から、型なんてダセーよな、プレステの方が全然おもしれーよな、を経て、また型に戻ってきてる
型推論云々にかまけてパフォーマンスよりも綺麗なコード、富豪プログラミングからまた元に戻ってきてる
学習コストが高いものほど評価されるような傾向も個人的には感心しない
どうせ同じゴールなのに、そこに辿り着く方法が険しいほど評価されるなんて、プログラマーの美徳の怠惰だのから逆行している
実によろしくない
そういう点ではRustよりもGoやC#の方が評価できる気がする
もちろんRustの守備位置はそこではない気もするので単純比較はおかしいのだけど、ゴールが同じなら自分はC#やJavaで書いて終わらせるのにと思うことがある
別にWebだけでなくコマンドラインでの捨てコードにPHPやJavaScriptも適している
そういう意味ではPythonはやはり強い、Glueだからだろう
正直PHPなんかよりPythonの方が言語としてはおかしい気もするのだけど、正しいとかエレガントが生き残る条件ではないのである
しかし、学習コストとしては低いシェルスクリプトは便利ではあるが流石に古いというか罠が多い気がする
PowerShellの方が使える気がする、少なくともWindowsでは優先的な選択肢になった
生き残るというのはそういうことではないのではないか
緩やかに変化を続けていて、気づいたら全く別のものに変わっているものが好きです。
例えば、TypeScriptの型システム。最初はシンプルな型推論と型指定だったはずなのに、最近は複雑な型の設計がメインの作業になりつつあります。
あるいはタプル的な要素を突っ込んだりしていて、当初のものとは明らかに違う構想が始まっています。
TypeScriptはバージョンアップのたびに変更を突っ込んできていて、しかもそれが追加機能というよりは機能の改善なので1つずつ追わないとつらいですね。
Reactとかもそんな気があり、エコシステムもまた変わりそうな気配があります。今回の変更もまた根本的ですし、改善案も攻めてます。
スポーツでも派手なフェイントは見栄えはいいですが、すぐにバレます。全身の位置関係を変えずに、等速で変化するのが一番だましやすいです。
人の成長とかも、かなり低速、等速なので、一緒にいると気づかれにくいですよね。
あとは思いつかないですけど、こうやって徐々に変化して見えないうちに置き去りにするという感覚が本当に好きです。
早すぎて見えないのも格好いいですが、遅すぎて見えないというのも同じように素敵だと思いませんか。
システムハンガリアンはIDEの発達や型推論で廃れた。変数にポインタを当てるだけで型がわかる。
アプリケーションハンガリアンは、自分もメンバ変数はbtn～にしたり～Buttonにしたり迷ってたりしてたが、プロパティとして公開するときはハンガリアンにするわけにはいかないので、結局ハンガリアンをやめた。プロパティとメンバ変数が機械的に対応が取れてたほうが便利。"_プロパティ名"とかにしてしまう。
型よりもその変数の意味のほうが重要だという考え方がハンガリアンが廃れた大もとの原因だろう。最近のIDEは中間一致で補完するのが主流なので、Buttonと打てばボタン一覧が出てくる。
swiftをJavascriptとかLLみたいに言ってる人沢山いたけど、あれって変数宣言がvarだとか、見た目がスッキリしてるとかそういう印象だけで言ってるんだよね。
以前、C#に型推論が導入されたときも(っていうか今でも)動的型やバリアント型と区別がつかなくて「使うな」「バグの元」みたいに言ってる人よくいたし。
あと、C++, Perl, Java, C#, Javascriptあたりをまとめて「C系の言語」と言ってPythonやらRubyみたいな言語と比較する文脈で「似てるから」おぼえやすいとかいう人とか。
VB6をやっていてVB.NETなら移行しやすいと思っていて「ぜんぜん違う言語だよ」って言われて驚く人とか。
共通のキーワードを使ってるとかぱっと見た目が似てたら、同じような言語と思ってしまう層がけっこうな量で存在するみたいで、そういう人たちも一応コードを書けてるんだよね。
元増田です。
そのためのデータ管理という項目をコンピュータ教育の指導要領に含めるべきだって話です。
代替オフィスへ移行しても「名前重要」なのは変わらないですし、互換性問題から「マークアップ」も必要とすべきです。
マークアップがプログラミングの型推論のように行われる可能性は軽量マークアップ言語の登場からあり得ない話では無くなってますけど、それに至るまでは時間が沢山必要だと言って良いはずです。
僕は別に憲法のような確固たる可能な限り変えるべきではないルールとしてデータ管理からのコンピュータ教育を推しているわけではないです。
ただデータ管理は少なくとも僕の寿命が尽きても広く使われるはずだ。この意見はIT業界関係者ならば否定のしようがないことだと思います。
いわゆる「LL」ではないけど、Scalaを挙げておきたい。希望の要件はおおむね満たしてると思うけど、以下注釈。
val users = service.getUsers // 1 val result = users.map { users ＝＞ users.filter { u ＝＞ u.name.head == 'T' // 2 }}.flatMap { users ＝＞ Future.traverse(users) { user ＝＞ db.write(user.id, user.name) // 3 }} result.onSuccess { case _ ＝＞ println("Success!") // 4 } // '＝＞'がうまく書けなかったので全角になってる。
