次世代言語議論スレ[Rust Kotlin Haskell]第6世代 [無断転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
もっとくだらなくてゴミみたいな自称次世代言語下痢糞プェチピィについて語ろうゾ Nimのシンタックスが「俺の求めていたものはこれなんだ」って感じでしっくりきている 発見したんだけれど語だとAさんBさんの間に自分がいると、自分の前にAさんがいて後ろにBさんが
いるってかくけれど、
にほんごだとAさんの後ろに自分がいてその後ろにCさんがいるのように自分中心
に書かないだろ。
これが日本人にオブジェクト指向があわない証拠だとおもうな。 そういう話じゃないと思うけどね。
単純に実行効率とメンテナンス性のバランスとるのが下手なだけ。 それは東洋的な発想はプログラムに向かないってことだよね。 でも英語だと命令形は動詞が先に来るけど、日本語だと後に来るので、
その点ではオブジェクト指向的な気がする
Lispみたいに前置にこだわった感じの関数型は英語的だと思う 得意なら半年で習得できるとか自分勝手にハードル上げて勝手に挫折して苦手になるのだ
10年かかると最初から思ってたら挫折もしない ってか習得するもんでも無いんじゃないの?
やりたい事をやりたいように出来ればそれで良い気がする。
自動車整備の達人はレンチの達人かもしれんが、ただのレンチの達人は自動車整備出来んだろ。
新型のレンチ試して習得する前に、どう使うかを考えた方が余程良いかと思う。 goはjavaの境界ワイルドカード型が理解できなかった奴らに支持されてるんじゃないの?
javaのパラメトリック多相が複雑だからって後発言語ではin/outになったじゃん。 最初にジェネリックの変性にin, outを使ったのってC#だっけ?
あれ思いついた奴は天才だろ
あれだけ意味不明だったJavaのワイルドカードが一瞬で誰でも一目で理解できるものになってしまった in, outとかはAdaにあったけどあれとは違うの? gcのときといっしょの浅はかな議論
nullがなくなろうと意味的なnullは必要なんだよ
だから絶対にそこにバグは入り込む
バグり方が変わるだけ
下手に動き続けるよりヌルポの瞬間に潔くクラッシュしてくれた方が
調査しやすいという考え方もある >>866
意味的なnullを想定しない箇所については型でnull を弾くよう静的検査するべきということなんだが? 意味がないとは言わない
おれもあれば使う
が思うほど効果ない null安全言語使うとホント幸せだよな。
結果的にここにnullの可能性がある変数が到達しないってことを言語として保証してくれるってすごすぎる。
書いてみると分かるけど返り値がnullの可能性があるかどうかは
内部で使うapiに依存してたりして、外側から見ると予測できない。
だから人間がやろうとしたら、結局使う側で全ての引数にnullチェック入れるしか無い。
まぁ面倒だからnullPointerExceptionを出しちゃうわけですけど。
コンパイラが把握してくれれは必要最低限のチェックで済むから精神衛生上も大変よろしい。
こういう進化はどんどんしていって欲しい。 >>868
必要性を感じるようなコードに出会ったことがないんだね、幸せなやつ 機能としては悪くないと思うけどnull安全とかいう頭悪いワードでバカを勘違いさせるのやめろ
nullで落ちるならnullチェックすればいいというわけじゃない まあないよりはマシだろうけどくらいの意味合いだな。
レイヤーを下りれば結局人間が判断することになることが多い。 null safety理解してないやつ結構いるのね >>862
これ詳しく。typeScriptでジェネリクス使うようになった新参だからなんのことかわからん。 NullPointerExceptionがことさら悪いことのように言われるが
俺にはどーも単に他のバグ(?)と違いが分からない
意図通り書かれてないからバグ(?)るんであって
いつだって、書かれたとおりに動いてるだけのことであって nullで初期化して後で代入しようしたら急に例外が来て脱出することがある
その例外を処理する途中でバグるから他のバグよりも深刻
例外を投げない言語なら問題ない >>874
interface Hoge<TIn, TOut> { convert(val: TIn): TOut; }
class B extends A { ... }
このとき、Hoge<A, B> のオブジェクトを Hoge<B, A> として扱っても理屈上問題ないはずだろ?
それを可能にするのがジェネリックの変性という概念。
ちょっと考えたら分かるはずだが、変性が適用できるのは型パラメータが入力または出力のどちらか一方にしか使われていない場合だけ。
さらに、型引数が入力と出力どちらであるかによって、変化の許される継承の方向が逆になることも分かるだろう。
C#では、interface Hoge<in A, out B> のように型パラメータの方向を限定してやることで変性を与えることができる。
これ Java だとHogeを使う側で Hoge<? extends A, ? super B> と書くんだけど、意味不明だろ? すまんちょっと訂正
C#では、interface Hoge<in TIn, out TOut>のように >>862
ガビン・キングか誰かが同時期に+-考えて後にceylonに導入されてる。
>>864
あれは入力変数と出力変数と入出力変数
>>878
ムダに長いな。
いちばん重要なのはどの型変数が入力/出力用か定義した側は分かってるから
宣言部だけに書けばいいのにjavaの仕様だと利用する側も利用する型を
書かなきゃいけない無駄が無くなること。
javaも型推論の範囲広げてくれればダイヤモンド演算子で済むんだけど。
話は変わるけど「意味的なnull」の場合はnullable typeとoptionalどっちがいんだろうな。
optionalがモナドかどうかは抜きにして。 >>878
すまんいまいちわからん。
in outの指定がなくても推論できそうな気がするんだけど。
それがどう便利になるのか、、、、
推論のための情報を増せるってことかね。 >>875
コンパイラ側で実行時エラーが減らせるならそれに越したことはないと思うんだが。
特にコード書いてる最中に指摘してくれるから頭がいい人が隣に座ってくれてる感ある > 頭がいい人が隣に座ってくれてる感ある
この例え、ちょっとワロタ >>881
全く違う。推論じゃなくて、Hoge<A, B>をHoge<B, A>にアップキャストできるってこと。 具体的な例を上げると、
例えば型パラメータに応じたオブジェクトを作成して返すFactory<T>インターフェースがあったとして
Factory<DBConnection>型をパラメータとして要求するメソッドに対して
Factory<OracleDBConnection>オブジェクトを直接渡せるってことだ
型推論じゃなくて型パラメータの互換性までを考慮したアップキャスト List<object>にList<string>を代入できるってことだろ。 >>885,887
抽象度さがってるんだから、アップキャストじゃなくてダウンキャストじゃねーの? >>888
よく考えろ
広げる方向へのキャストだよ 俺はもう
(単なるType **を)ダブルポインタ
(単なるポインタ型の値渡しを)ポインタ渡し
(謎の用語)アップキャスト
(謎の用語)ダウンキャストの飛び出して来ない世界に旅立ちたい >>885
やっぱ具体的なコードがないとよくわからんな
<T extends Hoge>XXX のHogeの部分を自由に指定できるようになるってこと? class ExtendsX a where { toX :: a -> X }
class SuperY a where { fromY :: Y -> a }
Haskellなら単なる関数にするだろ
キャストという謎の用語を使う必要がない >>892
い(ちごや、み)かんでしょ
あとJavaしか知らない人が背伸びしようとして?
(参照型変数の値渡しのことを)参照渡し
これもいつまでたっても無くならない >>893
var f1: Factory<OracleDBConnection> = getOracleDBConnectionFactory();
var f2: Factory<DBConnection> = f1;
var conn: DBConnection = f1.create();
こういうこと
いちいち無駄な型パラメータを使う必要がない fmap :: (a -> b) -> Factory a -> Factory b >>885,887
できねーよ。
>Factory<DBConnection>型をパラメータとして要求するメソッドに対して
>Factory<OracleDBConnection>オブジェクトを直接渡せるってことだ
>List<object>にList<string>を代入できる
これが出来るのはFactory<T>/Factory<U>やList<T>/List<U>が共変のときのみ。
それを緩めるのがjavaの上限境界ワイルドカード型。
>>898
それじゃモナドだろ。変性の話な。
変換の話ししてんのはID:Wf+VpSRVだけだから型変換は忘れろ。
おまえらPECS理解してなさすぎ。ポケモンで説明してやるよ。
List<? extends ゼニガメ>があった時このリストに入るのはゼニガメ、カメール、カメックス。これが上限境界ワイルドカード型。
set<T super ピクシー>(T value)というメソッドのときピクシー、ピッピ、ピィが入力できるんだよ。これが下限境界ワイルドカード型。
ValueT<?> value = foo.get<ポッポ>()とあった場合は?はポッポに変身したメタモン。これが非境界ワイルドカード型。
ただし、非境界ワイルドカード型はjavaの場合は型消去されてすべての型のsuper typeを表すObject型になる。つまりに何にも変身してないメタモンのまま。
これはjavaがnone-reifiableだからでreifiableな言語ならポッポに変身したメタモンならポッポのまま。 ダブルポインタとか言うバカに構文木を教えるために括弧を強制してやったのに >>899
それをC#だとキャストできるという話なんだが、頭おかしいのか? このように、>>899のように俺は分かってる感を出してる奴にとってすらジェネリックの変性は理解が難しいんだよな
ちなみにKotlinだと型定義時の指定と型使用時の指定の両方をサポートしてたりする
TypeScriptの場合はキャストが完全なstructual-subtypingベースで、型名やジェネリックは型定義のエイリアスに過ぎない
だから特に変成を明示的に指定する必要はない C++「仮想関数とtemplateは直交する」
Go「templateやめた」
Haskell「仮想関数やめた」
Java「直交やめた」 >TypeScriptの場合はキャストが完全なstructual-subtypingベースで、型名やジェネリックは型定義のエイリアスに過ぎない
>だから特に変成を明示的に指定する必要はない
TypeScriptの場合は必要ないと言うより、個々に指定できないから固定ルールでごまかしてるってのが近いと思うが。 ごまかしてるというのは擬人化しすぎというか
擬人化だけならいいが擬人化してから罪悪感を植えつけるのは科学ではない
政治に近い >>899
この文脈で脈絡のないモナドとか出してる時点で
いつもの知ったかぶり野郎ってわかんだね >>906
structural subtypingあるのにできないって、随分中途半端な言語なんだな ジェネリクス一つとっても言語によって結構変わるんだなってことしかわからん。 言語を決めようとするなよ
言語は決めたがコードは書けない無駄な状態ができるだけだから
決められない状態の次の瞬間に書き終えるのが正しい >>881
T extends Foo
U super Bar
だと人間がその型変数が入力用か出力用かわかりづらいからin/outの方がわかりやすいって言ってるだけ。
>>903
キャストじゃないって言ってるだろ。 PHP出身のオッサンマジでつっかえなくてワロタ
mapとlistの区別もできないガイジ
年上に敬語使いたくなくなったの初めてだわ PHPはちょっと前までリストは無かったかならぁ。
あったのは数値インデックスをキーとするマップだった。
でもPHP7からまともになったと噂で聞いたがどうなんだい? >>916
ウンコにカレーかけたらカレーになるか?
そういうことだ 概念なんて知らなきゃ知らない
知ってりゃ知ってる程度の話で
ただやった事あるかないかの差だろう
やればすぐに覚える
その程度で上になった気になってマウント取れる頭が羨ましいわ >>914
だからC#ではキャストなんだよ
知らないなら黙ってろよ >>919
まぁ、逆にそういう基礎的なことを知らない時点で他も推して知るべしってなってイライラする気持ちもわかる。
多分、色々あったんだよ 自己学習をしない老人ほど役に立たないものはない
若者にバカにされたくなかったら勉強を怠るなということさ まあ、敬語を使う基準や使ってはいけない基準が「年上」ってのも相当だけどな。
他人であれば敬語以外の選択肢が出てくる時点で異常。
上司であれ部下であれ、客であれ飼い主であれ、友達じゃねえんだから。
ほんとにドヤ顔したいなら、理解させたら良いのに。
理解させる事が出来ないなら、そいつ以下な気がするわ。
少なくともそいつより賢くないとできない事が、そいつに教えるって事なんだし。 無料で教えるのは難しくないね
ブラックジャックのように報酬はいくらでも出すと言わせるのが難しい 別に手弁当で教えなくても、理解させりゃ良いと思うが。
教えるって直接何かを伝える以外にも色々あるじゃん。覚えなきゃ切るって言ったり何でも。
それなら賢くなくても出来るか。 >>920
C#でも同じだバカ。
パラメタ型がキャストできたら型引数が部分多相になるだろうが。
おまえが代入互換性とキャストの区別もついてないだけなんだよ。 まあ若い人が今新しいと思ってるものが将来のレガシーコードを生んでることが多いんだけどね。
今巷にあるテストのないコード見てるとそれが良くわかる。 >>929
メンテしやすいかどうかは言語機能とは無関係なことが多い。 >>927
いいから具体的なC#コードで説明してくれ 未だにMVCとか言ってそう
んで、全部Cにロジック書いてそう とりあえず有名な物批判すれば通ぶれるってメンタルだろ
構ってちゃんにまともに取り合おうとするな 悪いものは更新する
正義なら古くてもそのまま
これだけの話なのに
おそらく正義か悪かを判断したくないから、新しいか古いかだけで決めようとするんだろ わからんのだろう、それが一体どういう場合にどういう悪になるか、とか、
悪は悪だが必要悪だとか、悪は悪だがそれを避けるコストが、我慢して使うコストを圧倒的に上回ってるとか。
ちょっと前の話なら、ClassicASPを嗤ってた割に、SSRとか言ってはしゃいでた奴とかいたが、心底アホなんだなぁって思ったよ。 避けるコストが我慢して使うコスト上回るってelectronとかか? スカラー型程度で嬉ション漏らしてPHPにも型を!
とか言ってる連中ってマジで頭おかしいんちゃうか
あまりのレベルの低さに草も生えない >>941
割と色んなものに当てはまると思うよ。
できればもう書きたくないけどプロジェクトは大規模だし、改修範囲は把握してるし、
動作環境も固定されてるとある機械の制御端末なので、VB6のプログラム改修してパッチ出します、とか真顔でやってるプロジェクトある。
よーやるわ、と思うが。
>>942
建設的にやれば? なぜペチパーは頑なにPHPに拘るのか不思議には思う
JavaScriptはしょうがないにしても、今どきPHPを積極的に採用する理由が見当たらない >>945
WordpressつこてるならPHP以外ないだろ
というかむしろWordpressとECぐらいしか新規案件見ない >>944
そういうことか。
古いjavaならoracleがAPIを削除し始めたから、
そのうち強制移行だろうけどイントラネットみたいなところで生き続けて、
言語仕様の進化から取り残されるんだろうな。
VMレベルで互換性失うのはまだ先だろうけど。 >>945
javascriptはしょうがないで書くような言語でも無いかと。
よくできてると思うよ。
上からまっすぐ降りてくる言語しかできん奴はjs嫌いだろうけど。
型が柔軟なのも良いけどな。なんでも突っ込むのは頭おかしいが、代数的データ型として使う分には良い具合の無茶が出来る。awaitが使えるようになって、ますます良い具合。
phpは置けば動くあの簡単さが良いんだろ、多分。 某Drupal案件は最悪だったな
よくわからんモノシリックFWに、低単価で寄せ集められたクズどもがどうしようもないゴミ山こさえて
どうにかこうにかまともな風に仕立て上げた頃に、新任のCTO就任
早々に言い出したのが「こんなレガシーではいけない!次は・・・Symfonyだ!」
あっという間にみんな撤退したよ
一応未だに企業は残ってるから、あれを保守して何とかやってるんだろうな
Symfonyエンジニアも絶賛募集してるから、レガシーからレガシーへの移行も諦めてないんだろう
あんなゴミでも営業や企画次第で優秀な金儲けの道具になるんだから
エンジニアリングって何だろう、って切なくなる思うことがあるよ >>947
ASP生きてる会社もあるよ、聞いた所だと。
純然たるソフト屋なら対策するだろうけど、製造業やら医療のシステムってたとえイントラでもすぐにスクラッチで作れるもんじゃないしね。台帳保存の法規制とか諸々含め。
windows7のVDI環境もあるし、IEのエンタープライズモードもあるし、多分使わなくなっても5年は動態保存してる。 レス数が950を超えています。1000を超えると書き込みができなくなります。