次世代言語18 V Julia 他
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok
前スレ
次世代言語17 Go Rust Kotlin TypeScript Julia
https://mevius.5ch.net/test/read.cgi/tech/1567602619/ あとjsonなどで思うのが
list: [
aa
bb
]
または
list: [
aa,
bb,
]
のように書きたい
リストの中間か最後(または先頭)かでカンマの有無を調整したくない dartはそこらへん緩かったような
a = [3,3,if (hoge) 4,for () i]
とかもできるようなったし。 >>154
中間のカンマ省略可能だと式書きたいときに困るでしょ TSの型狂信者なんて関数型言語の狂信者に比べれば数も個体の狂暴性も大したことないじゃん コードの書き方勉強するならもちろん外人が書いたコードを見た方が上達するんだろ? >>157
なにそのウンコよりゲロの方がマシ理論
これだから型パズル大好きマンは 型パズルってフレーズここで聞きすぎてむしろ静的型チェックのない強い型付けの言語の方が型パズルだと思うようになってしまったけど… 部品の型を言えばオートでパズル解いてくれるのが静的型チェックで、
人間がこの部品がどこならちゃんとはめられるか考えないといけないのが動的型付けだから、
なるほど型パズルなのは動的付け型の方だな 解いてはくれねえだろ
コンパイラが間違いだと思ったら指摘するだけでよ
コンパイラが仕様を理解して正解を提案してくれる訳でもあるまいし
結局人間がきっちり書くしかねえんだよ
型が合えば満足する奴はそこがわかってない 実際問題型に過剰な信頼を寄せている人間はおれどもTypescriptの中でわちゃわちゃしてるくらいなら別に良くない?
PureScript使えって言い出してる訳じゃないし
あっちはReactが上手く使えなかったり生DOM上手く使えなかったりで、静的型付け好きな私でも本末転倒感を感じる 逆なんだよなあ
最低限型が合ってるかどうかコンパイラがチェックしてくれる分だけ労力を他のことに割ける
動的型付け信者はまるで動的型付けだとロジックのバグが発生しないかのような物言いをする 動的型付けは不完全なコードも実行できるようにしてデプロイまでの工程を高速化するためのものであって、バグは当然増える >>167
ジェネリクス使いだすとだんだん手に終えなくなってくるよ
ようは単純な型使ってるだけの間は害はない
メタプログラミングやりだしたらどうでもいいところに時間かけるようになる 本来動かないコードのエラー発生をランタイムまで
先送りするのがメリットなのか? ジェネリクス使っただけで手に負えなくなるプロジェクトって静的型がなかったら実行時バグで死ぬだけでは >>170
ジェネリクスとメタプログラミングは全然違うんだが
C++のテンプレートと勘違いしてる? >>175
型の制限を加えるプログラミングと言えるのでメタプログラミングのひとつだよ
出来合いのコンテナ使ってるだけの人は気にしなくていい >>176
型の制限を加えるとメタプログラミングになるというロジックが意味不明 >>138
マネージャー「このままじゃ期限に間に合わないが……大丈夫か?」
型なしガイさん「大丈夫です!!!期限を最優先に、JSDocも型も書かずに、コードだけを書いてます!!!!!」
ええんかおまいら・・・ 生JSはそもそもまともにドキュメントを書けるような構造化されたコードを書ける時点で結構ハイスキルな方だし、
そのレベルならドキュメント書かなくても十分に可読性や保守性の高いコードだと思うよ 流石にドキュメントは書こうぜというか
最早型云々のレベルじゃない ↓これマジ?ルーストってまともなエディタも作れないの??
686 デフォルトの名無しさん sage 2019/10/04(金) 22:07:43.17 ID:YLLg2aHe
AtomチームがやってたRust製エディタの実験プロジェクトも終了したんだからあきらめよう char **argv の時点で既にパズルになってたよ
型レベルの構文木があるなら構文解析もあるので型レベルプログラミング不可避 >>183
Atom自体が死に体だから余裕が無くなったのだろ
まさかAtom用のフレームワークElectronを利用したVSCODEにシェア奪われるとは >>182
第1引数は数字です
第2引数は文字です
って書くんか?
それじゃ「メンテナンスのことを考えて型書いてますんで!!!」ガイジと同じレベルやないかい その情報無かったら他人はどうやって使うのさ
命名でカバーするの? >>187
マネージャー「型?そこは拘らなくていいから期限を……」
型ガイさん「その情報無かったら他人はどうやって使うのさ命名でカバーするの?!!?!!!!??????!!!!!!」ドンッ!!!! >>189
なんでっておまえらドキュメントガイジがコードも書かずに遊んでるからだろ
給料泥棒 /**
* メソッドの盛り合わせでございます。
* データベースにお接続し、データを取得でございます。
* 第1引数は数字でございます。
* 第2引数は文字でございます。
* 第3引数はあるかもしれないしないかもしれないでございます。
* 返値はないかもしれないし数字かもしれないでございます。
*/
おまえら下請けのゴミどもはヨ?納品物は正しく敬語で書けよ 正直>>191はやりすぎだけど
型ガイさんみたいな意識高めの人ってコメント全く書かなそうだし>>191の方がメンテナンスしやすそう ジェネリクスとメタプログラミングについてはとりまRust Part7 260をチェケラ もはや次世代言語関係なしに型もドキュメントもテストもロクに書けないペチパーが暴れるだけのスレになったな > 返値はないかもしれないし数字かもしれないでございます。
これが実際だったりしてもコメントにすら書かないでごまかす輩がいるんだよな。
型にこだわるやつに限って都合の悪いことはコメント書かん傾向にある。
逆にうまくいかんことをコメントにしろと思うのだが。 >>195
これもまったく逆だな
文字列か数値かnullが返る関数はそういう型を書かないとそもそもコンパイル通らないし、
そういう妙な型になってる関数はなんでそんな関数が出てくるのか、どんな用途なのかわからないようだとコードレビューに通らない >そういう妙な型になってる関数はなんでそんな関数が出てくるのか、どんな用途なのかわからないようだとコードレビューに通らない
そんなレベルでコードレビューやってるなら問題ないだろね。 >>195
> 都合の悪いことは書かない
型に関しては全くそうは思わないが、話は変わるけどテストコードはまさに > 都合の悪いことは書かない が横行してるよね
ユーティリティ関数のようなテストしやすいところだけテスト書いて、本当にテストの必要なコア部分は誰もテストなんか書こうとしない
奇跡的に書かれたとしても頻繁に変更が入るからすぐに壊れて放棄される
この傾向は型の有無とは無関係だが、実際にはテストコードなんか無いのにその現実から目を背け
「テストがあれば型は不要」と抜かすのが動的型信者 >「テストがあれば型は不要」と抜かすのが動的型信者
こんなこと言い出す輩はruby使ってる奴以外見たことないがな。
逆ならたくさん見てきた。 >>199
まあそれはその通り
一方で、それなら静的型を使っているプロジェクトはそうでないプロジェクトに比べてテストが書かれないのかというと、
面白いことに実際にはたいてい逆なんだよなw
言語の性質とは無関係に、単に品質に対する意識の問題なんだよ Haskellくらい型の表現力が豊かで状態を陽に扱う言語だと、コンパイルが通れば大体狙い通り動くってことが良くある
静的型付けでもオブジェクト!フィールド変数!ウオオオ!って副作用バリバリな言語だと、テストコード書かないと安心できないことの方が多い 別に「型なんてなくてもいいものができる」なんて流石に言わんでな
「型キチがモナドだのFreeだのEffectだのでパズルおもちゃにしてマウントとってくるくらいなら型なんていらねえ」って言ってるだけ
これは個人の感想じゃなくて、Scalaの大失敗からの教訓な
これをいうとすぐペチパー連呼発狂マンが飛んでくるのほんと図星なんだなとしか思わん >>191
こういうコメントに謎の型書くくらいなら
普通に言語機能の型書いた方がよくない・・・?
> 第1引数は数字でございます。
が平気で null | string (ただし暗黙キャストで数字になる) とか使われてたりするのが、型無し言語の世界だぞ
お前らこれ読んでも、型よりコメントの方がいい、型はなくていいとか、本気で言ってるの? おもちゃにするまではなんとなくわかるが個人の勝手だし、マウントとってくるってのはなんなのかわからんな。 個人の勝手で共同プロジェクトのソースコードぐちゃぐちゃにされたらたまらんわ
結局メンテできるのそいつ一人になって
仕事が集中したらケツまくって逃げるんだもんな
型にこだわるやつは地雷だし、そんな奴をホイホイする言語が地雷 Cのマクロをほぼほぼ封印できた成功体験が大きいと思うぜ
マクロをどう使おうが個人の自由、などという結論にはならなかった
ちなみにマクロを否定するなら代案が必要だったから俺達はtemplateで再帰とかしている メンテナンスが〜!って言われるけど作って最初の数ヶ月だけメンテされて
その後APIの仕様変更とかがない限りずっと放置されるんだよね……w 個人の勝手でコードぐちゃぐちゃになるってどういう組織なのよ
どんな体験からそんな保守的になったのか興味あるわ 個人の勝手うんぬんって、完全にマネジメントの問題じゃん
それが型のせいで〜とか、思考回路ショート寸前すぎない? >>211
新規で作るよりあるものに機能足そうって思想で魔改造されるパターンで
放置どころかメンテが続くパターン知らないんだな TSってaltJSの中じゃ保守的な方ってイメージだったんだが
言語機能としてはC#やJavaと大差ない程度なのに1人抜けたらメンテ出来ないってヤバいでしょ 型キチが大暴れしてコードしっちゃかめっちゃかにするのを
型キチ本人のせいじゃなくてマネジメントのせいにするとか
まじで自分は悪くない正義なんだ思想でゲボ吐きそう
ScalaでScalaz使い倒した上にimplicit地獄で複雑怪奇に絡み合った製品コードを
「これがきれいでシンプルでバグもない!」って強弁した挙げ句
誰も触れないからメンテお前が一人でやれって言われた途端退職したキチと同類なんだろうなお前ら
今のScalaの惨状みてると、日本中といわず世界中で似たようなことあったんだろうなって思うは そりゃちょっと勉強すれば誰でもメンテはできるだろうけど型ガイさんのために学習コストを払うのが前提だよね……😅 >>216
そいつがキチなのは本当なんだろうけど
それじゃそのキチにすら見限られるよ・・・ 型アンチが型を嫌う理由が型に1ミリも関係ない私怨で草
動的型ならしっちゃかめっちゃかにならなかったわけじゃあるまいし
そいつ本人とコードレビューが機能してないのがダメなだけ
そいつがRubyやら生JS使ってても同じことが起こっただろう とりあえず「コードしっちゃかめっちゃか」の例を見てみたい だから型そのものが嫌いなんじゃなくて
型キチのおもちゃになるくらいならそんなもんいらないとしか言ってねえっての
型そのものの有用性くらいわかっとるわ
型キチの藁人形論法寒気するわ まぁまぁ落ち着きなさい
型パズルでもして遊んできなさい(^_^) そんなん勝手にしろとしか
私怨をこのスレで発散されても困るんだが その理論ならコードレビューが機能してなかったらRubyやJSでもメタプロ厨のオモチャになって解読不能なコードが出てくるだけだろ
キチガイを排除できない態勢がクソなだけ >>227
これでしかない
何が彼を憎悪に駆り立てるのか本当にわからない・・・
型が理解できてないだけなのかな? レビュワー「こんな複雑怪奇なコード通せるかバカ。分かるように書け」
型キチ「これが一番シンプルで分かりやすい!!分からないお前らがバカ!!」
上「リリース日決まってるし作り直す時間ないしちゃんと動きはするんでしょ?通してやって」
型キチ擁護さんには画期的な腹案を持ちはっとるんどすなあ 完全にマネジメントの問題で草
そのロクに読めない複雑怪奇なコード出してくるヤツをプロジェクトの中心に据えたのは誰なんですかね >>221
その結果、まともに引き継ぎも出来ず
誰も触れない製品コードが残っちゃったんでしょ?
問題が起きる前に排除も出来ず
問題が起きてからの対処にも利用出来なかった最悪の事例じゃん キチガイが型無し言語で書いたコードより、型キチが静的型付け言語で書いたコードの方がマシだからな
静的型付けが理解出来ないから前者の方がいいというのはただの勉強不足 スクリプトとかいうゴミの話はやめてちゃんと機械語吐き出すまともな言語の話しようぜ TypeScriptを使うメリットを具体的に上げられる人いるの? あまり語られないが、interfaceで設計できるのが最大のメリットだと思う
地味な使い道としては、JSON Schemaへの変換ツールとして非常に実用的。 最低限型の合ったコードを書くことを
プロジェクトの開発者全員に
強制できてレビュアーの負担が減ること Go言語とか見ても分かるように、型ガチガチにやらないことが次世代のトレンドってことだな 必要ならTypeScriptでanyを使うしC#でdynamicを使う それな
おまけに型推論で、自分で型書かなくても良い感じにしてくれるし
TS叩いてるやつって、PHPくらいしか触ったことないゴミだろ >>235
なんだかんだ型は皆無よりはあった方がいいのは確か
ただし「anyは嘘吐きの言葉」とか言い始めるやつがプロジェクトに紛れ込むのがそれ以上の欠点 型は強制されない方が便利とかVB6の時代にタイムスリップしてきたみたい 旧Javaの冗長な型の反動で型無し言語が持て囃され、やっぱり型無し言語は糞、型推論でやってこうがトレンドだというのに
ここのおじいちゃんたちは「型は冗長!型はない方がいい!」
四半世紀前くらいからタイムスリップしてきたのかな? 極論で喚くだけのゴミ
booleanでしか物事を理解できず、バランスというものを知らないらしい 本当に型がそんなに大事ならGoは覇権を取れなかっただろうな
Scalaが死んでGoが覇権を取ったのは、>>243の過程からさらに揺り戻しで
「厳しすぎたり表現力ありすぎたりする、型ガイホイホイの言語じゃダメだ」って流れが来てるってことだろ char **argv の時点で既に難易度のバランス崩壊してるようなことは言われてた >>207
Cはキャストでどうにでもなるけどそれが全ての型がない言語を代表してるとでも
旧ObjectWorksだと何も困ることはなかったな
任意のインスタンスに存在しないメッセージ投げようとしても警告が出てセーブできないし
無理やりevalで実行時解釈させようとしてもエラートラップするだけで原因はすぐわかるようになってる
引数はいわゆるanyだがどのクラスに限定するのか記述することもできる(そうしたいのなら)
型で縛ってる言語は労力かかるわりに仕上がり悪いことが多いね そもそも型推論はコードの安全性を高めるのが目的というよりも
型が定まることにより最適化の恩恵を受けられるというのが本来の筋だと思うんだよな 型ガイとか型キチって表現は嫌いだけど、今は一般的なプロダクトでは型に持たせる表現力は控え目にしながらジェネリクスくらいは入るかって感じかなぁと思ってるよ
金融で型に持たせた機能で処理の妥当性をできる限り保証していきますって分野にだけ関数型言語でリッチな型を使うとか、Rustみたいに低レイヤーの捕捉しにくいバグ要因に対してだけある程度の機械的検査性だけ持たせるって使い分けの方針でさ
動的で強い型付けの言語も漸進的型付けやアノテーションの形で使えるものは使うって感じじゃん? ScalaやRustみたいな型ガチガチにやる言語は今日日流行らないってことよ 理想のエンジニア「こういう機能があればユーザーは喜ぶだろうか?UXとかも考慮しないとな……」
現実のエンジニア「型が〜!!モナドが〜!!!動的wwwww」
俺悲しいよ……😭 コンテナ
スマポ
モナド
こいつらの目的は、ライブラリでできることを言語本体から分離すること
分離できなかった原因の一つがたまたま型システムだったから型の話をしてるだけ ■ このスレッドは過去ログ倉庫に格納されています