次世代言語11[Rust Swift TypeScript Dart]
レス数が1000を超えています。これ以上書き込みはできません。
スレタイ以外の言語もok
前スレ
次世代言語10[Rust Swift TypeScript Dart]
https://mevius.5ch.net/test/read.cgi/tech/1524607347/ 内包表記だと
result = [i * 2 for i in range(10) if i%2==0]
で
かっちょええチェーンは
val result = (0 to 10).filter(_ % 2 == 0).map(_ * 2)
で
ちょっとかっちょよくないチェーンは
auto result = iota(0, 10).filter(a => a % 2 == 0).map(a => a * 2)
なんだなあ。最後のはちょっと長いし無駄が多い印象 >>3
最後のはスィープラ?いけるやん
これの良さがわからないリーナスとかいう禿げは何何やろなん? >>3
かっちょええやつで、引数が2つあるときや
同じ引数を2回使いたいときの書き分けはどうすんのん? >>5
(a => a % 2 == 0)
のスィンタックシュスュガーなだけだから
((a, b) => a % 2 == 0)
こうなるだけやぞ >>4
Dやで。C++は少なくとも17まではこんなん出来なかった気がする
>>5
Scala全く知らないけど、_1,_2としていくのがMathematicaとかの定番やね 前999
集合論の書き方という発想はなかった
初めに神はxを創造された。
さて、xは0から始まり、荒漠としていて、10まであった。
それから神は言われた、「偶数あれ」。
良く訓練されたパイスォニスタは、コードではなく聖書を書いていたというのか? >>7
さよか、autoとiotaテケトーにググっただけだから釣られたわ
やっぱスィープラは糞なんやな、リーナスは神 >>8
そう見ると割と理解しやすいと思うんやけどなあ…… >>8
自分で書いてあれやが、2倍が抜けてるやん
やっぱリスト内包表記は糞としか思えないんだが
俺の脳内パーサがコンパイルエラーを吐く pythonはもうドカタが使う言語じゃないからね
内包表記もアレで良いんだよ 内包記法は2重ループとか畳み込みでぐちゃぐちゃになるからイラネ Scalaの_は糞やで
外側の_をメソッド呼び出しの引数に渡せないから現実にはほとんど使い物にならない
使えば使うほど理不尽な制約の多さに辟易する
Kotlin関係なく、こんな行き当たりばったりなゴミが元々普及するわけがなかった >>13
それメソッドチェーンでも同じやん
それに場合によるけど二重くらいなら改行すればそんなにぐちゃぐちゃにはならないと思うよ >>14
あー。Juliaでも議論されて結局それのせいでいろいろ決まらなかったやつやね……
そうかあかんか…… 内糞は、必ずmap句、generate句、filter句の順である・・・と覚えりゃいいんだろうか
どう考えても糞ちゃう? SQLのSELECT文に近い順番だけど
あれもROM句から考えるほうがしっくりくるんだよなあ 英米人「Catch me if you can!」
ジャップ「捕まえられるものなら捕まえてみろ!」
長いし冗長。 ああ、SQLとも似てるのか、なるほどですね
1ライナーで書くことを強いられてるせいで余計読みづらいのかな
しかし前996に尽きる
前提が数字か文字列か何なのかわからんのに、
いきなり「2倍します」で始まるとかファッ!?てなるですよ まあデータを後ろへ流していくパイプラインの方がより書きやすいというのはわかる。書いてるとメソッドチェーンの方が書きやすいわ。
ただ、ラムダ式に毎回引数を書く必要があったり、外側の_の問題が鬱陶しい ポイントフリースタイルにすれば引数も書かなくてよくなるぞ
難読具合もUPするとは思うがw 普段C/C++使ってる身としてはいくら読みやすかろうと
実行効率犠牲にされると使う気が起きないな 横レスだがCPU時間次第では
I/O律速だから非効率でもいいかとガシガシCPU使ってると熱持ったり電池減ったりするからね そんなん気にし始めたらもうPythonに限らずスクリプト言語全般無理やん >>28
最適化作業が当たり前の世界にいるのだけど、最適化って進めるごとにどこがボトルネックは変わっていくんだ
また最近は可能な限りジョブ分割して並列実行させるから特定のcpuが遊んでるってこともあまりない
もし遊んでれば機能追加しようという話になる
そういう世界だと最適化前であっても原則富豪的なプログラミングは許されない
プログラミング言語にもとめるものとして可読性の順位はあまり高くない
どういうバイナリに落ちるか想像つくレベルでないとリバースエンジニアリンクに時間とられるはめになる >>31
よくC++でどういうバイナリに落ちるか想像つくな
どのくらい勉強したん? >>30
普段 C/C++ 使ってる>>27みたいな人はスクリプト言語でやるような仕事はあまりしてないんじゃないか >>33
それってつまり関係ない話題ぶっこんで来たってことか
反応する必要なかったか コンパイルと起動用のスクリプトにpython使おう
最適化の世界ではコンパイル時間と起動時間はノーカンだろ常識的に 起動時間をノーカンにしてたからクライアントサイドJavaは嫌われて滅びたというのに >>34
そもそもここ実行速度の遅い、C代替になり得ないようなスクリプト言語のスレなのか? >>38
両方ありのスレだろ。TypescriptがCの代替になるとは思えない。
そして俺達は今C代替になりえるかとかそういう話はしていなかった。てっきり続きの話題なのだと思ったけど、続きでなく新規の話題だったなら俺が反応する必要はなかった 実行速度は速いに越したこと無いけど、速いだけじゃCの代わりは無理だからね ダウンロードとコンパイルを最適化した結果がこれなのか ところでうちのサーバー、オフラインだからパッケージマネージャの類い全然有り難くないどころかむしろ鬱陶しいんだけど、お前らの所ってそうでもない? >>44
そんな環境で次世代言語?
ストレス溜まるだけだから諦めよう >>44
パッケージ配布のためのローカルなフィード作ればいいだけやない? そもそもパッケージマネージャーとか抜きにオフラインキツイわ。
大抵そういう現場ってバカの保身の為で全然本質でないことをやらされるイメージ。 linuxを起動する円盤にもパッケージが入ってるので
この仕組みを解明できたらネット接続は本質ではない >>46
ごめん分からなかった。良ければ解説リンクみたいなの頂けませんでしょうか? 気軽にリポジトリのURIをローカルに指定できるパッケージマネージャとそうでないやつがいるから何とも言えない
Rustのパッケージマネージャはcrates.io決め打ちでリポジトリの構造もオープンでないからネット環境無いと面倒くさい wasmの世界になったらめっちゃ楽しそう。
c++で書いたwasmが一番早いのですか? >>53
c++をバグなく書ける人がいないから
最も遅くなるよ >>39
発端は>>27だからC代替の話だね
一体なんの続きだと誤解していたんだ? >>56
>>27自体が内包表記とメソッドチェーンの話題に対するレスかと勘違いしてたよ 流れとしてはそうなんだろうけれども
C/C++ で実行効率がという話だからスクリプト言語は視野に入ってなかった 誤解なんて放っておけば自然治癒することもあるし
悪化したら何が問題か自然に明らかになる で、次世代最強言語は決まったのか?
おまえら人類は今まで何してたんだ?
シコって昼寝するだけのカスだったのか? Nimが面白そうなんだがイマイチ盛り上がってないな nimとかcrystalとかredの話が全然ないな 数値計算が得意でないかライブラリが足りない言語ばっかりで、いずれも「最強」と呼ぶには値しない みんなで使う言語が最強の言語だが決めるのに時間がかかりすぎる
自分だけ使う言語を今すぐ決めよう 銀の弾丸を求めても意味ないよ。
自分の戦場の自分の兵科で一番便利だったり一番強い武器使えば良いじゃん。
同じ戦場でも狙撃手と本隊とだとライフルとサブマシンガンに別れるように、
同じ業務系とくくられる開発でもそれぞれ最強言語が違って当たり前だと思うよ。
さらに領域すら異なるなら、最強とか言ってもホントに無駄でしょ。
「この言語はこう新しくて、ここが好き」とか、
「この言語も最近は良くなってきた、特にこの辺」とか
そういう話題からの
「じゃあ〇〇系の開発でも使い物になってきたな」みたいな話題ならわかるんだけど、
使いみちありきの言語ageは違うと思う。
そういう意味では、ちょっと前から出てるRailsファンは書き込む前に考えてから書き込んでほしい。 >>69
そんなんどっちでも良くないか?
ルールとしてRailsユーザは禁止ってならわかるけど
そもそもここの人間はなぜrubyを親の敵のように叩いているのかわからない。
特定の人物が騒いでるだけ? rubyは敵だと1秒で決める人物もいるし
20年考えても敵か味方かを決められない人物もいる rubyと言うより信者が糞。
別言語のスレで唐突にrubyでは〜とか言ってrubyコード貼り出したりその言語のライブラリ探してんのにrubyのライブラリとruby薦めだしたりやりたい放題。
スレ違いだと言っても無視してずーっと居座る。
目には目をだな。 信者がキモいからこのスレで叩くというのは筋が通らない。一時期沸いてたHaskellアンチと同レベル リアルでの信者のキモさでいえば明らかにHaskellは最底辺
Ruby使いはライトなレイラーも多いから平均的にはそこまで酷くない >>70
どっちでも良くない事はわかってるだろ。
叩かれてる原因ぐらい理解できるだろうし、理解できないならそれこそもっと考えるべき。
rubyが1.9からくさった事は何度も書いた。 一位を決められない奴が「とりあえず最下位を決めよう」って思いつくのなんでだろう 信者がキモくない言語って単に人口が多いだけのPython以外にあるか? 言語を叩くってのがだいたい噴飯ものなんだよ
センスも経験も力量も劣ってるクソゴミ野郎が
自分のサイズすら見えず
プログラミングの成果物のうちでも
偉大な
恐れ多いプログラミング言語というもんを気軽に叩きやがる
もっとひれ伏せよ蛆虫 そこまでは言わんが何が嫌いかより、何が好きで語ったほうが良い。 Rubyは信者というより作者がキモい。(主に見た目が) いや言語については嫌いな理由のが有意義な情報な場合が多い。
好きとかクソみたいな理由しかないし。 昔リリースマネジメントが滅茶苦茶だったころBTSぐらい導入しようと提案されて
自分は無くても困ってないので不要という趣旨のこと言ってて
だから滅茶苦茶なんだと呆れ果てた 次の戦場はwasmだから、そこでどの言語が勝つかな。何か開発力はMSが一番な気がするからTypeScriptな気がする。.Netがwasmに対応するほうが早いか? jstsはまだまともにコンパイルできる処理系がないという点で一歩出遅れているけどな。
pypy的なアプローチでいけたりするかな。 結局みんなCに戻るのか
こんな世界滅んでしまえばいいのに >>88
そう思った理由をぜひお聞かせください、とても期待しています >>87
そもそもpypyって別に速くないぞ
Python界では無駄にリソースを分散させているだけの嫌われ者 言語がバージョンアップしていってどんどん多機能になっていくの何か嫌い
むしろ機能を削っていくキレキレ言語が欲しい 互換性の問題をクリアした言語作ればいいのに
ソースファイルにコンパイラのバージョン書くとか 同じ言語間の新旧interop用の機能を用意するのと、互換性のために機能を残しておくのと
何が違うというのか Cとbash
wasmとJSとかいうマルチパラダイムinteropが解禁されたら結局みんなCに戻る >>94
jsで言うとstrictモードとかね。
jsは最新仕様のコードから古いjsコードを吐き出せるトランスパイラを、作ることで進化スピードが上がった。トランスパイラなら後方互換性が壊れても良いかもね。
デバックは死にますが c++はgccかVCで実装が終わってから標準にすりゃいいんだよ。
標準委員とか全く実装をわかってないバカがクソ仕様を決めてんのが大問題。 その点「標準にしたけど、実装難しかったから次のバージョンからやっぱなしw」ってやるFortranってすげえわ いろんな言語でwasm対応は進むと思うから、そっから先の使い勝手で勝負する感じになるんではないかな
wasm-bindgenみたいに関数のバインディングを楽にするとか
デバッグのしやすさとか スクリプト言語の速さなんて書き方次第で全然違うし、比較に意味がある気がしない そうだよなあ
あるスクリプト言語がめちゃ遅で
またある言語がめちゃ速でも
お前には全く意味ないよな Rubyはあの有様だしPython対抗の次世代言語って意外と無いよな
Juliaってのも違うし python 対抗の次世代言語は
python4だな >>109
割とこれだと思ってる
また後方互換捨ててきそう
悪いことじゃないんだけどねでかいとキツイ RHELがやっとPython2を捨てようとしているときにPython4とか言いはじめるのは止めてくださいなんd 20年真面目に互換守ってきたPythonが互換捨てると批判されまくって
ちょくちょく互換捨ててる言語はあんまり批判されないのかわいそう どうせdebianとubuntuみたいに表面が変わるだけで中身は同じ
表面的に次世代やってる感を出しつつ中身は元のまま再利用する global pipとクソみたいなsyntaxのlambdaと内糞包糞表糞記を捨てたらPython4は最強言語になるかもしれない >>104
にゃんちゅう読みづらい記事だ
書いたやつはゲェジか?頭がPHPなのか? 内包表記は残して欲しい
アホほど嫌う最高の機能だから エロさにおいても糞さにおいてもすべての領域でC++は最強である。 ほーん
C++産まれて何十年経ったかしらんが
それまでお前らクソ無能のバカどもはシコって昼寝でもしとったんかタコ? 40、50で次世代天皇とかもいるわけだし…
それに比べたらC++は若いよ! Cpreから数えて38年だから、人生まだまだこれから世代。 ぶっちゃけcが一旦後方互換性を捨てて構文を整理したやつを出してほしい。
トランスパイラ用意すればいいってjsが教えてくれたろ C言語の場合、OSのヘッダーファイルに書かれてる変態マクロと互換性切るわけにいかないから
どうしようもないんやで 頭の湧いた老害どもはいつまで古代言語の話を続けるんですかな コスパの話をだれも止められないんだよね
古いOSをそのまま使った方がコスパが良い
コスパという概念をぶっ壊せば新しくなるのは薄々わかってるがやめられない 安全性において結局過去の資産を使った方がいいってのがある。
新しい言語の提唱する新しい機能による「安全性」よりも枯れた技術のがよっぽど
安全という。 新規プロジェクト以外に新規言語使おうとするガイジおる? こなれた技術の組み合わせで新しいことするってのはあるけど、
枯れた技術では枯れたことしかできないてのも事実なんだよね。
何をしたいからこの道具を使う、という一方で、この道具使ってたらこんなん思いついた、てのもある。 まあ大抵誰かが思いついて盛大に大コケした後だったりするわけだが。 例えばさ、何とか算の公式使ってれば、計算ミスは少ないだろうけど、
適用できるケースは、代数を使ったものには敵わないし、
関数みたいな抽象的概念は生まれなかっただろう。 近年の大きな成果のうちのいくつかは高速に数値計算ができるようになったおかげ 吐き出し法の方が圧倒的に速いのに行列式を定義に沿って計算しちゃうとか
コボルをバカにする割に、利息計算においてどこで丸めを演算するかも把握してないとか
そういう種類のバカは多いよね。 例えば、今流行の機械学習は既存のこなれた数値計算ライブラリを組み合わせて巧くやってるけど、
じゃあ、所謂A.I.の前提となる自然言語解析について複雑でアドホックなParsingをやろうとする人は少ない。
大体が大量のデータを使ったNグラムで止まってる。
>>138
計算コストが下がったお陰でやれること増えたのは事実だね。個人PCでも色々やれるようになった。 いや、やって結果が出てないだけだよ。
チャットボットを機械学習でってどこも思いついてやってるが
結局ルールベースと比較してまともな製品にならんというのがよくわかったってのが
ここ2,3年の内容だろうに。
こういう知ったかが一番たち悪いわ。 >>140
そういうのを馬鹿にするのは良くないわな。
でも新しい技術を馬鹿にするのも良くない。 >>143
ああ、知ったかな部分はあったかな。
データサイエンティストについて言ってると考えてくれ。
まともな製品にならんのは、知らんな。
やり方が悪いんだろう。
>>145
馬鹿にしちゃダメだろww >>142
触れんなよ。そいつが出てくるのは言うほど久し振りじゃないしな まあ、結果を出さない多弁ほど説得力のないものはないな。
結果出してから発言するわ。
でも、上の側面はあると思うよ。 >>143
一応言っとくが、馬鹿にしたわけではないからな。 >>143
ロジックを扱うようなのって、出てきてない気がするが、自分が不勉強なのか? ちょっとそれらしければ持て囃される他の分野と違って
チャットは Watson というハードルを超えないと製品価値ないもんな >>150
馬鹿にしたかしてないか
ではなく
馬鹿にされたかされてないか
だよ
ニーチェもそう言っている >>153
こっちでしたかww
深いな、人間関係てのは難しいことだね。
計算コストもそうだけど、気軽に書けるってのも大事だと思う。
高階関数って昔からあるみたいだけど、やはりハードの性能が追いついたから使える感じになったんかな?
LISPとかの昔を知らんので、どうなんですかね、その辺。 いっとくが今のレスは俺が3秒で考えたレスだぞ
何が深いだ
深淵でも覗き込んでろカス >>154
高階関数を楽に使うには関数閉包が必要なので
クロージャを持つ言語の普及を待つ必要があった。
ハードの性能は関係ない >>151
そら論文ばっか読んでても出てこないだろうね。
greenでもwantedlyでもいいけど、それっぽい企業探して話聞きにいってみれば?
いくらでも失敗談が聞けるよ。 >>159
そういうことですか。
>>160
こちらも情報ありがとう。アンテナ低かったわ。 あ、別の人も「あ」と名乗ってたのな。
ってかグダグダやな、朝の流れ。 特定企業があとで気変わりして囲い込みそうな言語とか開発環境ってどう考えたらええんかな。
VS CodeとかTypescriptとか、最近のニュースだとGithubとか。 MSの囲い込みグセはここ5年位ちょっとマシじゃない?
VSのExpressを廃止して無償をCommunityにしたから、
仕事で使う分にはライセンスが要るし。
むしろ、中小企業でExpress使う抜け穴が無くなった分、きちんと金回収できてると思うけど。
仕事で使う時は会社が買ってくれるから懐も痛くないしなw
Goは若干怖いわ。囲い込みというか、逆で、誰も面倒見なくなるという方に。
コミュニティールール変えるね!とか最近も言ってたし。 よく「OSSなんだから開発元が当てにならなくなったらフォークすればいい」というけど、
MSのOSSに対してはあまりそういうのは聞かれないよな
MSほどガッバガバなライセンスで大量のソースをOSSとして垂れ流している企業は過去を見ても他にないわけだけど、
みなMSの開発力が圧倒的すぎて一方的に利益を享受することを当然と思っている
しまいにはMSは過去の歴史を清算する責任があるなどとどっかの国みたいなことを抜かす始末 程度問題だよな。TypeScriptはSwiftやKotlinなんかと比べたらよっぽど安心感がある。 マイクロソフトにはC#という実績があり、アップルにはObjective-Cという実績がある
TypeScriptの方が信頼が置けるのは当然のことだ なんだTypeScript評価高いじゃないか。
その割に勉強会とかmeetupとか見当たらないのはなんでなん?
5chのスレも伸びとらんし TypeScriptとvscodeのお陰でMSの評価バク上げだわ。
だからGitHub買収も全然気にならない。
FacebookのReactの置き場所が変わるかもしれんのが心配だけどな。
facebook内にGitHub fork作り始めたりしたら辛い C#とTSはJava方言だろ
方言が多いのは使うためではなく布教用、保存用、予備みたいなパターンだろ C#がJava代替だったのは2.0とかそんな時代だろ。
Javaではできない事だらけなんだし。
実際問題、いい言語(+環境)になったと思うよ。 C#は一つの言語を長く使い続けるという前提において理想的な進化をしてる
20年近くにわたって実用最先端言語として拡張しまくってきて未だに大きな破綻なくメインストリームのリーダーとして君臨し続けてるって奇跡だろ >>172
C#のプロパティやデリゲートや値型はJavaのどの機能が元ネタですか? デンマークの○○氏によって○○な使い方が発見された→標準化。
そういうわけで、C++は常に次世代。 昔のMacも同じように論破されたのかと思うと笑える
Windowsの○○はMacのどの機能が元ネタですか?はい論破ってな 他の言語から見ればC#もDelphiもVB.NETも全部Javaみたいな言語だよ
JS系をJava方言は意味分からんけど >>181
Mac の方が Windows よりも先なんですか?それは本当ですか? なんだMS社員スレだったかここは
あんなクソ悪徳企業をほめちぎって気持ち悪い
C#もTSも劣化コピー言語を金の力でごり押ししてるだけ
Github買収が一部で好意的なのもワケわからん
もうCodeplexの悲劇は忘れ去られたのか? >>182
さすがにDelphiをJavaみたいな言語だと思うのは、見てる方の知識が足りなすぎるんじゃ無いか?
どんな他の言語か知らんが…。
「WindowsのJava」みたいな「インターネット買ってきた」って次元の話では。 >>185
良い物は良いと言わないと、悪いものに悪いと言う資格が無かろう。
そういう意味で、.net coreは英断で、良いものだと思うぞ。
企業がどうであれ。坊主が憎いから袈裟が憎いになってはよろしくない。 悪いでも憎いでもいいから結論は早い方が良い
結論を言わず、意味が分からないとか言って質問したりするのは時間がかかる 結論は可能な限り、それが必要なタイミングまで出すべきではないだろ。
意味がわからないのに、質問せずに結論を出すのを是とするのは良くわからん。
今回のGithub買収騒動でNatも「MSを信じてくれと頼むつもりはない」と、結果を見せるスタイルで行ってるしな。
もとXamarinの人だっけ。 >>189
違う違う。
真面目でも不良でもリア充でも根暗でも、誰がやっても「ごみ拾い」という行為自体の価値は変わらないんだから、
不良がどうの、なんて頭言葉をつける無粋な真似はよくねえよな、って言ってるんだよ。
お前の発言の真逆な。 >>191
それを言うんなら、そもそもGithub買収は邪悪な囲い込みな訳で
ゴミ拾いどころかヤクザのシノギだ
前科もある企業のシノギをどう好意的に見ろと? 能力無いやつは良いことやろうとしてもたいしたことできず
悪い事やったらクズがって言われて忘れられるだけなんやで
MSは無視できない能力があったってことや 純粋に聞きたいんだが
MSを褒めちぎってる人ってMSに人質とられてるか札束で殴られたかどっちなの? 言うほど褒めちぎってるかねwMSの悪口いってれば君は満足なのか?w
そんなもん誰の得にもならない
君は気分良くなるんだろうけどそんなの知ったことじゃないし >>195
MSを信じず自分のプロダクト、プロジェクトを守ろうって言ってんだよ
それでもMSを信じようとしたり、信じる世論を発するやつの背景に興味はある >>192
ぜんぜんそれを言えてないじゃないか。
囲い込まれた所で停滞するなら停滞すればそういうものだったんだろうし。
もともとgithubはプロプラなんだから。
皆がgitlabに行く自由も、セルフホストする自由もあるんだしな。
linuxのカーネルなんかも、git使うけどgithubは使われてない(というより、明確にプロプラだから使わないと明言された)
今だって単にミラーとして使われてるgithub上のリポジトリも多い。
githubの価値として変わらなければ、胴元がどう変わろうが本質的に問題ではないんじゃねえの?って話で。
代替品があるのに、囲い込みとはこれは不思議な話だろ。
MS憎しで物事が近視眼的になってるんじゃないか? >>196
信じないのも勝手だし、自分のプロジェクトをどうするも君の勝手だろう
それで功を奏すこともあるかもしれない
俺はいいものを提供してくれるなら賞賛するし、そうでないなら貶して避けるだけ
過去がどうこういっても何の飯の種にもならない >>196
セルフホストすれば良かろう…。
そういう人たちは、既にいて、彼らは最初からgithubすら信じてない。
信じる信じないの信仰心ではなくて、信じられる信じられないの成果の単なる判断でしかないし、
成果は過去から連続したものではないんだから、過去何やってたって、今回どうやるかが問題でしょ。
「お前は新人のときに寝坊したから、二度と『遅刻しない』って宣言は信じない。だから一緒に働きたくない」
みたいな、「単に部長があいつ嫌いなだけだろ…」って低レベルな話だぞ、それ。 >>196
githubの件でいえばそもそも自分のソース守ろうとするなら
あんなとこに上げるべきではない。
マイクロソフトを擁護する気は無いけれどフリーライドしてるくせに偉そうなバカには
一言くらいは言わんといかんかなと思ってる。 >>203
いや違うぞ。
彼は世の中を良くするためにMicrosoft社を批判してきたし、世の中のためにGithubを使っていたのだ。
全ては人民のためなんだよ。
彼の恩恵を得ている我々人民が、彼を批判するのはおかしくないか? さぞ素晴らしいプロダクトのプロジェクトなんだろうなぁ。
まあ、1つの批判を2つ以上の対象に適用すると話がおかしくなる典型だし、
批判するなら「いつの何がどう悪い」かちゃんと批判して、「今の何がどう良い/悪い」を判断できるようにしておいてもらいたいもんだ。
そうでなければ、批判の価値が無い。批判って読んで字のごとく相対論なんだから。 自分の意見を大切にしたいならフィリピンの怪しげな会社がやってるBBSで議論などするな そもそも彼のプライベート・リポジトリを覗き見るために、Microsoft社はGithubを買ったのだ。
彼の心配ももっともなのである。 >>208
それはすごい。一体何を作ったというのですか? Microsoftにあんなところやこんなところも見られてしまうのか MSに見られるのはどうでもええやろけど、MSがGithubを殺してしまうのは嫌やね Githubに新機能や新サービスが追加されることはもうないと覚悟して使うならそれでいいんじゃないの 有償版に自社で使いたい機能ガンガン突っ込んでくれるかも知れないよ?
OSS用途は別に現状で過不足無いでしょ MSに買収されてからSkypeはグタグタだしRoboVMは消滅したやん
楽観視してる方が不思議だわ
atomは死刑宣告されたようなもんだろうし >>218
その2つを上げることが理由にはならんやろ
じゃあExcelは?Wordは?って不毛な議論にしかならない そろそろMS嫌いはwindowsが嫌いなだけなのを無理やり対象を広げてるだけだと理解しなさい。 Word最高!!!って人はいないだろうな。
Excel最高!!!って人はいるだろうけど。 Wordももう少し何とかすれば文書作成のスタンダードになれたんだろうけど。 どこの馬の骨ともわからんような有象無象が
マイクロソフト社を批判するとか噴飯ものなんだがw
こーいう
自分のサイズが見えてない批判は辛く悲しく滑稽であり
5ちゃんにはふさわしくもある 俺はMicrosoft大嫌いだ!Microsoft製品なんか一度も使ったことがない!!!
って人もいるけどな。 使ってて文句言うのと、使ったことなくて文句言うのでは、だいぶ違うしな。
宗教的な理由とかいろいろあるからな。 食わず嫌いもいいんじゃないの
他人に強制しなければ
お前等同性愛とか昆虫食とか 話を断つが稀にここに現れるC++2aは次世代言語おじはC++1zのVariantとOptionalを見た上で次世代になると信じて疑っていないのだろうか githubはそもそもまともに収益出てないから売ったわけで、
その時点でMSに文句垂れてる事自体が筋違いなんだよ。 C++は難解すぎて義務にはできないから良い
自称まともな言語ほど、これくらい簡単だろっていって義務を押し付けてくる 今フレームワークで話題のmvcとかのロジック的な内容言語に取り組むみたいなのないんかね?
ミドルウェアとかバリアントとか関数や変数単位でやれたら楽しそうじゃ MVCとか…
いや概念は必要だけど何十年前の話しとるねん >>235
全ての言語がFFIを持つCにはGoでは勝てぬ >>218
Skype、企業内でめちゃくちゃ使われてるぞ。
Office 365についてくるからな。
昔はリンクとか言うIMツールがあったが、それがそのままSkype For Businessになった。 最近は、skypeで使えない奴の悪口ばっか言ってる >>245
自暴自棄になるなよ。
お前にだっていいところはあるはず。多分、きっと… >>244
棲み分けてるよ。
社内IMはTeams、社外とか、電話会議(笑)はSkype。
そういや最近、Skype、登録しなくてもWebからそのまま参加してもらえるようになったね。 昔話を色々思い出してきたが、
そういや、c#に関してはCommunity Promiseとか昔言ってたよな。
FSFがMonoに「あれいつソフトウェア特許を行使される事になるかわかんねえし、実装やめとけよ」って物申して、
「いや、実装の作成、使用、販売、もろもろに対して特許の主張は行わないことを約束するし、この約束は撤回しない」って言い返したやつ。
10年ぐらい前だっけ。
約束を守ったどころか、オープソースになったなw
アンチだけが停止した時間の中で見えない何かと戦ってるみたい。 >>247
法人版はもうTeamsに統合させようとしてるな
しかしもうちょい軽くならんのかね… MSは特許訴訟かなりの数やってたし警戒するのは当然じゃね?
まあ裁判に勝てなくなってきたら不毛だからやめようとか言い出して方針転換したけども >>249
あれ起動時にコケて再起動させなきゃいかんことも多いよな。
Skype(Business)もまあリンクの頃の方が使いやすかったって人も居るし、迷走はしとるか…。
特許戦争というかネガキャン+取り込んで独自拡張して競合をおいてけぼりにする、は、
Halloween文書の最後の方で諦め始めてたし、まあ時代の流れな気もするわ。
金さえ払ってNDA結んでれば、Windowsのソースもある程度見れて、
バグ踏んだ時には解析してあいつらのせいなら、MSの人来てもらって
KB作ってもらう時代もあったし(今もかな)、そこまでクローズドでも無いと思うよ。
金払いが渋いと役に立たんのは昔からだから、その点ちゃんとMITライセンスでやってる時点でそのプロジェクトはまともだと思う。 >>64
gitterを覗くといいよ CrystalもNimもRedも会話の流量多いよ >>242
じゃあCを改変しようぜ。
基本的に今のままで良いけど
変数宣言を変数名 型の順に変える、セミコロンはなしに、ifとかforの余計なカッコを削る
do whileを消してfor {}で回せるように
つまりgo風にしようってことで頼む。 >>254
そこの細かいシンタックスそんなに大事か?
Goの利点はそこじゃないと思うけど >>255
セミコロンはきつくないか?あれなんでいるの?ってなる。 goやpythonの行継続ルールはなんかもやもやする。
式+セミコロン=文 という明快さがいいと思うんだがなぁ。 Cよりもアセンブラ寄りの言語が欲しいな
せっかくCPUに高速な演算が載ってても言語自体にそれを利用する仕組みが無ければ意味ないし
全部コンパイラの最適化にまかせるのも限界がある >>260
今は技術的にはいらんのでわ?セミコロン不要な言語沢山あるし セミコロン、そんな敵視するほどか?
パースバグ引き起こすくらいだったらそれくらい入れてやるわと思うくらいの労力だと思うが。
変数宣言を入れ替える案はストラウストラップがc++の時のやろうとして挫折しとる。
クソみたいな改変意見は「C++の設計と進化」でも読んでからしてくれ。 Rustならセミコロンありなしで意味変わるから必要。
あってもなくても意味変わらない言語なら、なくて良いんじゃないかね スレタイにも入ってるのに1レスも話題にならないDartくんかわいそう luaのコルーチンみたいに小技だけ揃えたセコい言語はよ pythonは内包表記とyieldとasync/awaitを揃えた
これは小技じゃなくてフラグだから
勘違いするのがこわくて無視してたらバッドエンドになるやつ 次世代言語がswiftやTypeScriptだというなら、goも次世代と言っていいのでわ。何が次世代なんか? 「良いのでは?」…そんな言葉は使う必要がねーんだ
その疑問を頭の中に思い浮かべた時には
もうすでに答えを知ってるからだ >>274
既にある程度普及してる言語は現世代言語
SwiftもTypeScriptはもう現世代言語だよ
Dartなんか機能的には18歳のC#さんの方がよっぽど次世代だけど、それでもDartは永遠の次世代言語なんだよ 普及や時間を数値化する方法はよく知られている
だがCとC++の数値を合計してみたり、逆にCとC++を区別して個別に時間を計るなど
数値を自由自在に変える方法はまだあまり知られていない 知られてるよ。
統計で嘘をつく方法とかベストセラーだったじゃん。 すぐ脱線するな。もう話題がないんじゃないか?このスレ MSが本当にGitHubのことを思っていたのなら
わざわざ買収する必要はなかったよね
こういう反応があるのはわかりきってたことだし
じゃあなぜMSはGitHubを買収したのか?
MSにどんな利益があるというのか? 事業会社を買収すると売り上げが増えるから成長してるように見えるというメリットがある ここを曖昧にしたり嘘つくから信用ならなんだよね
行動で示すとかさ、信用をちょりもどすとかどうでもいいのよ
何の利益があってそうしたのか、ここを隠しては信じられるものも信じられないよね >>282
自分が理解できないだけで「隠してる!」はないだろう。 本当に思っている、が意味不明なんだが。
思いやりと慈悲の心を持っている、みたいな意味ならいよいよ脳みそおかしいと思う。
そりゃgithubはgithubとして運営するだろうが、
収益は現状通り確保するだろ。今も黒字なんだし。
加えて「MSだから」使っても良い、って判断が下りる(逆に言うと、今までgithubという企業に信頼を置いてなかった)企業が使うようにもなると思うけど。
AzureはOKでAWSとかGCPはNGって会社も一定数あるんだし。
これはVSはOKだけどRiderはNGって会社や、TFSはOKだけどSVNはNGな会社と同じジャンルの「ザ、日本企業」だけど。
MSが大好きと言うよりも、既にOSや開発環境で依存してるし諦めてるって企業は多いよ。 githubの収益に期待なんかしてないでしょ
買収額高いし回収できないよ
MSが欲しかったのは開発者情報とIntelliCodeの学習用データじゃないか >>288
そうか、では何か素晴らしい話題を提供して場の流れを持っていかれてはいかがかな? まあプライベートリポジトリへのアクセス権のためってのが一番だろ
見ちまえばMS社内にコピペして特許申請からの逆訴訟まで一直線
まーいつものMSですな そこまで価値のあるコード置いてる企業なんてあるかね?
大きいとこは公開していいコードしか置いてないでしょ。
クソ企業ほど被害妄想働かせてるっていうw ここでもATS2ってあまり話題を見ないが依存型ってやっぱ理論味が強すぎるのかね 初めて見た。良さげに見えるけど。ホームページダサすぎて草生えた 第一印象
・ロゴダッッッッッッッッサ
・昭和かよ
・まーた括弧つけたシンタックス(藁) >>292
勝手に根拠のない妄想して、まーいつものMSですなとか
まさに病気、リーナス神の言う通り
Linus氏曰く「マイクロソフト嫌悪は『病気』」
https://srad.jp/story/09/07/28/0326208/ >>299
perlとpythonとrubyの多すぎ問題はほぼほぼ解決したが
解決しても特に意味はなかった >>298
「オープンな開発を信条とするということはソースをオープンにすることだけでなく、他人や企業などを締め出したりしないということも大事である」
おかしいねーMSと真逆だねー
Linusもコミュニティ運営者だから、MSマネーには逆らえんのだろうな そう言いつつ最近はまともなMicrosoftを追い出すわけですね
少なくともGoogleが買収してgitとGitHub両方を独占するより遥かにマシだと思うけどな MSとか抜きにそもそもlinusはだいぶ独裁的な開発して来たわけだがな。
オープンっていっても全て自由にしたら開発なんてうまくいくわけないんだよ。 >>303
そういう、産廃とうんこならうんこの方がまし理論やめようぜ
あとMSが最近はまともって、目がどこについてたら言えるんだ? >>305
現実問題買収交渉があった以上は何処かしらが買うわけで
MSもGoogleも嫌ならどこが買うべきだと思ってたんだ?
Microsoftがまともに見えないんじゃなくて営利企業が嫌いなだけじゃないの? MSが非健全っていつの発想なんだか。
技術面では今はかなりオープンにしてると思うが。
そもそも元から「金さえ払って契約してれば」ちゃんと働くし、結構な範囲のソース見せてくれるし、呼んだら調査したり、必要ならKB作ったり「とても良くできたサンプル」作りまでやってくれるぞ。それが10年ぐらい前の話。
金も払わずに「〇〇が独自だからゴミ」といっても、金払ってないんだから知財が手に入らなくて当然だと思う。
あのひどいライセンスだったリファレンス実装の.netを、今やクロスプラットフォームに公式がして、さらにコントリビュートまで受けてるとか、
VisualStudioの名を関したエディタをOSSで作ってるとか、
そんな事は関係なくMSだから邪悪と言いたいだけだろ。
もしくは歴史を一切知らずに「MSが悪いってみんな言ってるからMSが悪いんだ」と思ってるか、どっちかじゃねえの?
逆にどのへんがまともじゃないの? >>307
.netはMSが突然特許主張する可能性が未だに解決してない
VSCodeについては使ってないから知らん。どうせEmacsやVimより使い勝手が良いこともなかろう
記憶に新しいところだとXamarinも買収されてから腐ったし >>306
自分が損するのが嫌なのではなく、誰かが得をすると嫌なお年頃なのかもな。
で、githubが営利企業なのを忘れてたり、「営利企業だけれども健全である、根拠は、不健全だった過去がないからだ」みたいな、
「幼児は健全」じみた勘違いしてるんだろ。 >>310
特許問題に関してはCommunityPromiseで大体解決してるだろ。法的拘束力あるぞあれ。CommunityPromiseは知ってる?
その上今はMITライセンスだぞ。
Xamarin、買われてからのほうがオープンだけど…。
xamarin.androidが、プロプラに依存する事なくビルドできるようになったのは最近だぞ。
お前あんまり知らないだろ。 emacsとvimに関しては、最早好みのレベルだろ。
秀丸エディタも入れてやれよ(笑) >>305
MSとGoogleに対して産廃とうんこだって?
この業界で龍と虎みたいな存在に対して何ゆってんのw
好き嫌いは別にしてもスケール感間違ってんのはさすがに哀れでしかないわw >>308
も、前からそのページに関して言われてるように、
そもそもサポート切れしてるOSに対してsecurityfixが無い事を怠惰とは普通言わんし、
組み込み向けならまだ出してくれるよ。金払いの問題。
Blu-rayのDRMに関しては言いがかりもいいところだろ。
Windows10のSはJailって、そうだよ、としか言いようが無いし。
しかしマメに更新してるんだなこれ。
これが、GNUのソフトウェアすべてに、一行もMS製のソフトウェアを使って書かれたコードが存在しなけりゃもう少し説得力あるのに、と毎度思うわ。
俺の昔のパッチまだコードに残ってるw もしかしたら最近の方々はストールマン知らんのかもな。
あのやり過ぎな時代感を感じたことない世代なのかも。 >>316
やり過ぎな時代感って何?
もしよければおせーて やりすぎといえば、Linux訴訟の原告に資金提供してたんだよなMS
自分に火の粉が飛ぶ前にさっさと尻尾気ってうやむやにしたが
この辺の経緯知ってると、手のひら返して協調路線とかうさんくさすぎて信用しようがないのわかるだろ >>317
GPL書いたり、LinuxをGNU/Linuxと呼ばないと許さんと言い出したり、
動きをトレースされるとカードキーが必要な建物に入らなかったり、
Emacsをforkさせたり、
子供作らない事は特であると宣言して、そのおかげでFSFを立ち上げたとか、
90年代いろいろやってた。
>>318
お前は技術の経緯をもう少し知ろうな。 >>319
技術の経緯って、つまりMSが邪悪なことしてることの自己正当化ってこと? >>319
とんくす
俺emacsは1997年から使ってて
gccとemacsを書いて携帯電話を持ってないヒゲ面教祖って認識しかなかったわ
GPLやFSFは今も昔も、俺にはさほど関係無いからスルーしてる
Debianはslinkから使ってるからGNU/Linux呼称云々については知ってる
まぁ、それくらいしか知らない
ってアンタID:3QzXkyiE本人じゃないのなw 昔からストールマンをホームレス扱いする連中が
いるよな日本には おまえらよってたかってガイジボコボコにするの好きやな >>321
邪悪かどうかは、お前の知識が足りない以上話しても無駄だろ。
知ったかXamarinとか、CommunityPromiseを知らない、起こり得ない特許行使だとか。
monoチームすらRMSに反論してたぞ。 >>325
可哀想なJava。
あのライセンスだと、フリーで企業ユース辛いよね。 >>326
お前のなかではXamarinはオープンだし.netの特許行使は起こり得ないんだろうな
そんなMSならもうちょい世界はまともだったろうに
まあ御大バカにしてる辺りお察し案件 ID:3R48K+eCのID:yK0gAcGXへのレス、後半は内容噛み合ってなくて草 >>329
俺の中どころか、リポジトリ見てくりゃいいし、
CommunityPromiseの詳細読んでこいよ。
明文化されとるわ。この文書はLegally Bindingなのかとある。
日本語版もあるだろうから見てこいよ。
知らない時点でお察し案件だわ。 GPLはソース非公開でバイナリを売ることはできないけど
ソース自体を売ることはできるよね多分
紙に印刷して本屋で売ってもいいし電子書籍を売ってもいい とりあえずTypeScript好きだからms好きになった人はいる。ここに。
googleもappleもMicrosoftもFacebookもすげーよ。
日本は駄目だな。 パクリを見下すと駄目になる面もあると思う
LinuxはUnixのパクリでC#はJavaのパクリ
でも合法ならもっとやればいい >>307
アップデートの度にメニューの中身が変わるとこ >>334
別に、ソースコードを売っても良いよ。
ただ一つの例外が、バイナリを配布してる場合にソースを求められた時。その時はバイナリを手に入れる方法と同じ方法で提供しないといけない。
ただ、売ってもいいけど、再配布される事にはなる。
相手が再配布するかどうかも自由なので、再配布されない事に納得した上で、相手が再配布しなくても、問題ない。 同じ方法、はおかしいな。
同じ方法か、それ以下の労力で、だな。 エンジニアってマジで信仰するエンジニアの思想をまるごとトレースしようとする奴いるよな
何の根拠も理由もなくMSは邪悪だとかVim/emacs使えない奴はダメとかメインOSがLinuxじゃない奴はエンジニアじゃないとか言い出す奴はてブあたり大勢いる GPLの問題は、プラプラ憎しで主張が頭おかしくなってる事だけじゃなく
技術的にもプラプラに劣っててハッカー目線でもダサい所だね RMSは技術者としては素晴らしいが思想は誰よりもヤバいだろ GitHub買収の件でMSが叩かれてるけど
GitHub運営の方は叩かれてないのが不思議 しかし、Xamarin、ひいてはmonoが何故MITライセンスに移行できたかわからんのかな。
今まで「静的リンクするならGPL適用か個別ライセンス契約ね」という形でライセンス料を取ってたのが、MSに買収されたことで取る必要無くなった事がメインだぞ。
この件に関してはMSを悪く言える部分あんま無い。 プログラマってのは豆知識でマウントとるのをやめられない性分なのかね
とっとと次世代言語rustの話に戻ろうよ プログラマがっていうより、やってる奴の個性でしょ
次世代言語Juliaの話がしたいな〜 全然関係ないけど、現世代言語Pythonの最大の欠点はコマンドラインの呼びにくさとCインターフェースの複雑さだと思うわ >>348
それて変えてバグ作ってたよね
電卓にまでバグ仕込めるなんて流石だと思ったわ 旧世代言語のRubyユーザーあるいは作者にとって
危険な話をしているな そういえばTypeScriptの仕様が逆にESに採用されたりする事例ってあるの?
そういう話を人伝いに聞いたんす MSはESの仕様策定に参加してるから、TSES双方に入るべきものは最初から入る
asyncなんか誰がどう見ても完全にMS方式でしょ >>345
その思想のお陰でGPLが世に出たんだが?
そもそも全部理にかなってる考えだろ 理にかなっているかどうかは個人の主義信条でしか無いんだし、
すり合わせようと思っても無駄なんだから、言語の話に戻せばよかろう。
どの言語のどのライセンスがいかん、という話なら妥当だったけど、それに関して何か問題残ってる? 思想が誰よりもヤバイとかあのさぁ
なんで海の向こうの偉人を捕まえて気軽に語っちゃうのかなぁ
本人のことなんざたいして知りもしねえのに MSにヘイトを向けるならRMSにヘイトが向けられることは覚悟しておくべきだ
少なくともMSが最高だなんていう奴は居ないが, RMSはどうだ? >>358
ごめん書き方間違えた。
ESでこういう仕様を入れようってしたら、
TS側にいれるのが困難だから不採用みたいな感じで、TSの仕様がESの仕様決めに影響を与えたって話 >>366
TypeScriptはGoogleも社内でバリバリ使ってる言語なんだから別に不思議はないだろ
MSとGoogle合わせてシェア過半数あるから意見が一致すればそりゃ通るだろうな TSの機能追加の条件は結構厳しい
型システムを除いてES部分の拡張に僅かでも引っかかるものは軒並みrejectされてる 実装の難しさではなく会議の難しさを解決するのはそれこそ思想家の仕事だ VSCodeがないとフロントエンド実装できない体にされてしまったので
これからはMSのケツ穴あへあへ舐めながら生きていくしかないんだお・・・つらお・・・ lspが進んだ世界では必ずしもvscodeに頼らなくていいはず。 .vscode/settings.jsonが神すぎるんだお
なぜあの当たり前ができないのか
3秒に10回はクラッシュするEclipseとか
ゲキ重糞出方Intellijとか
設定ファイルクソすぎでしょ
あんな俺が鼻くそほじりながら逆立ちしてドリルウンコ逆流性食道炎してる暇に足の小指の水虫でできるレベルのクソみたいなクソ
ガイジでしょ >>373
ビビビビ ビームwwwwwwwwwwwwwwwww
クソククソクソガイジwwwwwwwwwwwwwwwwww
未だにチンコインサートモードパイルダーゲッターオォーーーーーンアォン!!!!
とか言ってるのか!?!?!?頭が逝ってるのか?!?!?!?!
ば〜〜〜〜〜〜〜〜っかじゃねえの!?
おいクソばか
おまえビームのコマンドでしりとり何個言えるか逝ってみろよガイジ!ガイジ!ガイジ! Foってのがでてるな
Functional Goらしい ごめん。ちょっと頭がおかしいみたい。疲れてるんだきっと。
毎日毎日毎日プログラムを書くばっかり。
貯まった金はクソブサイクな風俗女にしゃぶらせるためだけに消える。
俺なんのために生きてるんだろう。 >>376
も少し貯めて可愛い子にすればいいのに。 なんで旧世代スレになってるんだよ
いい加減にしろよ老害ども じゃあオブジェクト指向を関数型で駆逐する方法を語ろう
次世代的だろう >>383
lisp が関数型であるとすれば、最古から関数型はあるわけで >>385
心が老害とか一番かわいそうなパティーンじゃん
かわいそ、かわいそ >>386
Vimコマンド駆使するより素早く編集する方法なくね?
あったら乗り換えるが テキストエディタで完結するレベルの土方仕事しかしてないんなら、素早い(笑)んだろうな IDEじゃないと書きたくない言語と
そうでもないのがある https://github.com/albrow/fo
Foってこれか。米麺食いたくなる名前だな
Emacs信者の俺が純粋に聞きたいんだけどVSCodeのどこらへんがいいの? Functional GoでFoなのか
日本人だったらFGOとかにしそうだな
エディタやIDEなんてラーメンみたいなもんだろ
人のおすすめ聞くより使ってみる方が早い Foはジェネリクス対応してるのな
もうこっちでいいんじゃねw >>392
やっぱりトランスパイラみたいね。
出力されるコードが変なものじゃなければ、ありな気がする。もともと実験的な意味合いが強いからなー。 なるほど面食い連中に使ってもらって実験台になってもらおうという言語かw >>392
カスタマイズ無しでそれなりに使えるところかな?
素のemacsで開発できる? カスタマイズがないエディタ
cssとjsがないホームページ
次世代はこういうのでいいんだよ ドカタの知能は昆虫以下だからカスタマイズとか出来ないもんなぁ
それは理解できるけど人間様に同意を求めないで欲しい
違う生き物なんだから ただまあ、カスタマイズしないと使い物にならない、と、
カスタマイズいくらでも出来る、はまた別だからな。
VSCodeに関しては、吊るしで割と使えて、拡張機能で相当便利になって、
めちゃくちゃニッチなものなら自作もできる分、
割といいと思うよ。
生粋のemacsユーザみたいにemacsでメールチェックも何もかも済ませちゃう所までは行かないし、今更誰も求めないだろうけど。 エ、エディタで人の知能判断するのか………
宗教戦争がなくならないわけだ 証拠で判断する
知能が低い証拠や高い証拠
戦争も強さを立証するためにやってる そのエディタはお前が作ったのか?
使ってる道具を知能の証拠にするとかいいの?
ましてや戦争レベルにスケールアップするとかさあ… 少なくともメモ帳やEclipseやAtom使ってるやつの知能は心配していいと思う ファイルサイズでかいと途端に無能になるエディタが多くてなあ
モダンなエディタでまともに動くのはsublimetextくらいだわ atomは重すぎないかあれは
俺がクソザコpcだからなのかあれは Electron製エディタなんて重くなって当たり前なところはある ElectronだからってAtomのもっさり感は大概だと思うけどなぁ
VSCode使ってたら尚の事 早いところreact-nativeで、再実装されたvscode見てみたいな。最近のマイクロソフトのRN推しはなかなか良い。 >>417
youtubeでいいからデモってみてよ Goは「エンター押してGo!」って標語通りのコンパイル速度目指したあれだろ
トランスパイラなんか噛ませて「エンター押してコーヒーブレイク!」じゃアカンでしょ >>420
go自体早くなってきてるし一段トランスパイラ噛ませても早いのでは? 型推論とジェネリクスが入るとどうやっても遅くなるんでない?Fo試してないけど。 >>421
エンター押してGoのためにゲネリクスまで捨ててるのに
それ捨てたら捨てるものしか残らないゴミ箱になるだろ いやだからgo本体に組み込まれるよりかトランスパイラで実験的に使ってもらったほうがいいってことでしょ。 コミュ力重視棒で殴ってばかりで代案を出さないのが普通の日本人 そもそもgoにジェネリクス入れないとは行ってないぞ。faq見ろや。むやみに希望通りに機能追加したくないだけ。
phpみたく投票で決めてうまく行った例をみない Haxe(ヘックス)はOSSで、JSに型チェックを付けたような言語で(altJS)、
JS(ES5), Flash, PHP, C++, Java, C#, Python, Lua に書き出せる
インストールしてみた。楽しみ >>431
多数決がロクでもないのは本当にそう思うわ
Linusほどとは言わないがBDFLが方向性と重要な決定で決断するのは本当に重要 最近はRust風のRFCベース開発が増えてるが
これはどうなんだ?
正直発端のRustがゴミなんでこの方法も多数決と大差ないゴミだと思うんだが >>269
RustがゴミだからRCFもゴミという理屈を通すなら
RCFがゴミだからインターネット技術も全てゴミということか
ネット技術を否定するとはたまげたなぁ Request Comment For internetsだろ。 Rustがゴミだというのは要出典だが
1人か数人程度で書いた出典が多数派より強いなら多数決ではない マスカキ・ラスマス・豚ラードみたいなクソガイジが作ってるガイジ専用PHPoorは
今すぐ死ね
今すぐにだ Rustがゴミなら
さしずめPHPは放射線汚染汚物だな
存在自体が害悪 その場合は放射線じゃなく放射能では?
言葉は正しく使いましょう。 放射能に汚染されるとかあるの?
放射線を当ててDNA傷つけるとかはあるけど。 放射能を取り込んだら常に放射線を受けるようになる。これを汚染という 文書を管理し公開すれば質問に答える手間が省ける
独裁者は効率が良いというが、文書管理ができない独裁者は効率が悪い >>447
「放射能漏れ (放射性物質が意図せず外部に流出すること)」など、
放射能という言葉で放射性物質を意味することが我が国では頻繁にある >>448
なんと!
日本語審査会で審議しないといけないな。 放射能とは放射線を発する能力のことだよな。
それなのに、放射性物質漏れを放射能漏れと言うとは、原発村は朝鮮部落じゃないのか?
日本語全然ダメじゃないか。 class 物質 {
放射能 : Double
onRecv(r: 放射線) {
var a = is放射性物質()
放射能 += calc(this, 放射線)
if(a != is放射性物質()){ on放射化() }
}
on放射化(){
}
is放射性物質(){
return 0 < 放射能
}
onTick() : 放射線 {
return 放射性崩壊()
}
} 関数型なら放射能の基底値最低値みたいなものがあればモノイドやモナドに出来るはず 開発のオッチャンが
ポンコツになって病んで
いつの間にか復帰したと思ってたら情シスに異動してて
クソみたいなノーパソのセッティングとかするだけのマシーンになってた
おまえらもいつかああなるんだな >>436
誰だよRFCをRCFと書いたバカは?
あ…俺か…
疲れてるんだよきっと… 関数型も注目された結果色々なエッセンスがそうでない多くの言語に取り込まれたけど依存型線形型は難しくて部分的な取り込まれ方もしなそうという気持ちがある
純粋に難しいのもあるし実務を見据えると煩雑すぎる 型の話をするなら動的型と静的型に分ける
型の話をするならHaskellとTypeScriptは似たもの同士である TypeScriptみたいなド型とHaskellの型システムを一緒にしないでくれる? TypeScriptは構造的部分型
クラス定義の見た目が似ているだけで、Java系のド型とは実は概念的に全然違う 型チェックと値チェックを一緒にするのは動的型なら簡単に思いつくこと
依存型が難しいというのは静的型が難しいだけのこと >>454
クソコード書いてメンテ不能状況作るよりかそっちのがよっぽど建設的だわ。 逆に言うと、建設的なことをやらない理由は、やったら差別されるから
差別があるから非効率的になる ド型ワロピオ大草原パークwwwwwwwwwwwwwwwwwwwww >>465
たかしに
あんな惨めなポジで会社にしがみつくとか情けなさすぎて俺なら絶対できねえ >>462
静的に値チェックがカリーハワード同型対応の下で示せるのが依存型のうれしさなので動的型で簡単と言われてもそれは不完全性としか聞こえない PythonもHaskellも全部やれば完全になるのに
同型対応というなら少なくとも2つの具体例を比較する必要がある
1つでは足りない 人間はねぇ簡単に壊れるんだよ。
そして壊れたらまず戻せない カリーハワード同型対応も知らないのに型を語るのかぁってなってる 最近、依存型と線形型について勉強し始めたんだけど、
依存型と線形型の両方が使える言語ってATS2以外に何かある? >>475
idrisって依存型はあるけど線形型もあるの?
依存型については何となく分かってきたんだけど、
線形型についてはまださっぱりなんだよね…
Rustの所有権とはまた違う概念なの? >>476
そのものはないけどuniquenessとborrowedがある
rustの所有権もその辺りに基づいてはいる
そのものはHaskellで提案されているくらいであとは自前実装しかないかなぁ >>477
勉強用なんで「そのもの」が欲しいんだよね
てか、ATS2の線形型はそのものだと思っていいんだよな…?
名前は線形型だけど実際には線形型擬きでしたじゃ勉強用としてちょっと… 何言ってんのかまじでわからねー。
そんなの仕事で出てこないが、ほんとに使うのそれ?研究目的? 依存型は全然ないから仕事で使いたくても使えない。悲しい TS程度あれば十分だろ
TS以下はゴミだが
TS以上は学習コスト高い 学習コスト云々言うんならJavaのオブジェクト指向も大概学習コスト高いと思うわ
正直モナドと同じくらいやろ(適当)
そんな学習コスト高いものも全力で教育すればなんとかドカタでも使えるようになるんだし、概念が広く知られて本さえ出れば次世代言語の中心概念になってても大丈夫だと思う >>482
Thanks!
じゃあ、やっぱりATS2で勉強するわ
>>480
現状じゃまだ研究の段階だろうね。5年後は分からんが…
とは言え、5年後でも使ってるのはほんの一部の企業だけだろうな…
日本語の書籍が大量に出回るようなレベルにならない限りはほとんどの企業はどうせ使わない そもそもやってるやつの目的が
やってないやつが多い概念のがマウント取れるってことだからな。
そりゃ流行らんわ なんやその目的
単純にコードの重複削って短くしたいだけやぞ で、短くかけるぜってどやりたいだけだろ。
だからなぜ短く書くことに意味があるのか少し考えてみろと思うわけだ。 短く書けたらコード書き始めから書き終わりまでの時間が短くなるし、拡張が楽になる場合も多い 依存型は短くするための機能というよりバグを減らすための機能だと思うが ID:4s/pndVSは依存型の話というより関数型とかの技法一般のこと話してると思うし…… 仮にマウント目的ならそれは生産というより消費
高級な車や時計を買うようなもの
そういうのは無意味だとして質素倹約を推奨する意見は大昔からある 確かにmizchiみたいなのが鬱陶しいのはわかるけどさぁ
それと技術評価は切り離して考えないとだめでしょうよ 2,30年位前もきっとオブジェクト指向なんて研究者のオモチャで
実務では必要ないって騒いでた奴がいたんだろうなぁ… 間口は広くしてるけど、言語仕様的は可能でもやっちゃいけないことが多くて後々困るのがOOP 効率にしろ何にしろ例え多少良くなるからと言って新しいもの作る時
その学習コストもそろそろ計算に入れてもらわないと困る
コード多少短く書けるからと言ってまた1からの学習コストもキツい、 大丈夫。良いものはそのうち良書が出て学習コストは下がる
深層学習の学習コストが二年前と今で全然違うように。
学習コストを気にする人は新しい物に飛びつかないほうが良いよ。そのうち良い解説本が出るから 依存型って何に使うのこれ
TSの文字リテラル型みたいなやつかね >>485
それって本当に幸せになれる仕組みなの?
それならわかりやすく説明頼む。
一人でちまちま作るようなものなら、
学習コスト高くても構わないけど、
現実問題として人材不足だからな。
TypeScriptエンジニアすら不足気味でC#とかCのエンジニア入れたり趣味でしか触ったことないエンジニア入れたりしてる >>501
人材不足なら人材集めろよ…
なんで人材不足の対処として新しい技術を求めようとしてるんだよ…
新しい技術なら当然それを使える人も少ないんだから
んなもん人材不足の現場に持ち込んだらますます人材不足なるだけだろ…
何がしたんだお前? 人材不足を解消する未来テクノロジーX-men〜Silver Dan-Gan〜を求めてるんだろ TypeScriptとC#に互換性がないのは冗長でありDRYに反する
ATSは他の言語に似ていないので冗長ではない 学習コストって、別に新言語のコストだけではなくて、
今動いてる、ずっと保守されてきたソースを新人に保守できるように教育するのも学習コストだからな。
どっちに振るかの問題だと思う。新しい言語に(その学習コストを払うほど)興味がない人にとっては。
言語好きはその学習コストを手弁当で補いがちだけど、それも本来はちゃんと計上すべきだと思うんだけどなぁ。 >>505
>>497だよ。そもそもこのスレは「次世代」を銘打ってるんだから、対象の情報ソースがまだ少なくて学習コストが高いのは当たり前
ここはあなたのような人が見るべきスレじゃない TypeScript, ES2015 は、学習コストが高い。
大規模開発に向く、きれいな言語仕様は、Haxe
初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017
上を読めば、愕然とする。
皆、下のサイの表紙の、サイ本で苦しんだろ。それと同じ
JavaScript 第6版、2012、David Flanagan 上と下じゃ全然レベル違うがw
下はともかく上で苦しんだんならはっきり言って才能無いからやめるといいよ。
同じとか笑うわww
お前が何を読んでも理解できないだけ。
そりゃお前にとっちゃ何でも「同じ」だわな。
等しく理解できないwwww ハクセなんてくさそうな言語聞いたこともねーぞバーカ プログラミングできない奴ほど新興言語に飛び付くよね RustやらDやら
本当に分かってるやつはJava8使う。これが真に次世代 >>510
新しいことを学べなくなったド型ゲェジ老害じいさん
かわいそ JS, TypeScript では、this の挙動が変だから、皆、that に代入して使う。
that = this
Haxe では、こういう事はない
下のような引数付き、enum もある。
一々、抽象クラス・インターフェースを書かなくても、多様な入力方式に対応できる
enum Input {
Key (keyCode:int);
Click (x:int, y:int);
}
switch (input) {
case Input.Key (keyCode):
case Input.Click (x, y):
}
パターンマッチも使えるし、Elixir に似てる >>511
>>512
現場知らん小僧に言われてもな…… 「新しいものを導入しよう」とか脳死でわめくガキに現場しっちゃかめっちゃかにされる経験がないのか
それとも逆に現場ひっかきまわす側のガキなのか
次世代っていうのは目新しさで決めるもんじゃないだろ >>514
現場知ってるならJava8なんて出てこない
あ、奴隷かごめんね >>516
5、6年後くらいのリプレイス時にJava8導入するかもしれないから互換性の下調べしてる段階な
お前のいう「現場知って」る奴ならどんな言語出すんだ?
まさかことりんとか言わんよな? このスレに上がってるような言語を実践投入する時はそら1990年代にJavaを投入した時のように慎重にいかないといかんでしょ
脳死での実践投入なんて発想が最初に出てくるとかガイジか。いや、ドカタだからそういう常識が欠けているのか。ごめんね? 商用開発的に色んな側面考慮してJava8選択するのは特におかしいとは思わないけど
次世代呼びは流石に無茶やって >>519
おまえさんは違うと思うが、
実際いるんだよ脳死実践投入主張するガキが…… >>520
Java8が次世代じゃないとか言い出すとは思わんかった
Java8以上に新しい言語は次世代通り越して未完成言語って言ってもいいわ >>513
使ってる案件あります?
TypeScriptはES2015+型って考えでとりあえずは使えるから、学習コストは低い。
this問題はアロー関数でも使っとけばいい。 >>502
人材がいないのにどうやって集めろっていうの? >>502
別に新しい技術で人材不足を解消しようって話はしてないよ。
間違った行間読みはやめろ。
純粋に案件を始めるにあたって、
言語を特殊なものにすると、人材が集めづらいだろって話。
TypeScriptというメジャー寄りの言語ですら、専門以外エンジニアになりがちって話。
ちなみにTypeScriptは学習コストは低いほうだ。 サポート切れるのに今からJava8を選ぶって逆に脳死過ぎだわ
The老害にも程がある >>514
現場ワロタ
おまえに必要なのはJavaでもTypeScriptでもない
Excel方眼紙だ! >>524
知るか。派遣でもなんでも雇えば良いだろ?
>>525
> 間違った行間読みはやめろ。
すまんな…でも、あの文脈じゃそういう風に受け取られても仕方ないと思うけど…
> 言語を特殊なものにすると、人材が集めづらいだろって話。
集めづらいよ。だから慎重に検討する必要はあるし、手放しに喜んで良い機能じゃない
ただ時々「慎重に検討する」を曲解して「結局、絶対に採用されない」と
新しい技術そのものを否定しようとするヤツが居るんで
それは違うだろ?将来に備えて勉強しておく必要はあるだろ?
自分が理解できなかったのを正当化するための言い訳だろ?って言いたい
あと、慎重に検討した結果、採用したとして、それでも失敗した場合は
それは経験として受け入れるべきであって失敗として否定するべきではない
ある程度のリスクは受け入れないと、失敗はしなかったとしても成功もしない
どの程度のリスクを許容するかのバランスの問題であって、
全くリスクを受け入れようとしない企業は所詮その程度の企業だってこと >>527
Excelも年々進化してるんだがお前は知らんのか?
バカにしてるやつはその程度か >>533
なんかおかしいか?枯らす期間としては短い方だろ 寿司職人が5、6年修行しているようなものか
半年でできらぁって誰かが言い出したとしてお前らはそいつを倒せるのか? >>534
何がおかしいのかわからないようならこの業界やめた方がいい >>535
倒すだの勝つだの物騒な話してねえから
安定したプログラムを工数圧縮して作るのが目的だから >>518
Java8 のサポート期間いつまでか知ってるかい? 導入したい技術は、きちんと上司に根回しして
承認印を頂くこと 上司がバカな可能性も十分あるからなんとも言えん。
しかし、同じくらいの割合でバカな新人が新しいクソツールをねじ込むこともあるからな。
一般に表面だけ見て判断はできんわ。 五年後からJava8とか地獄のような現場もあったもんだな
現場を知らなかったわ アップデートがあるうちはまだまだ未完成
LTSが終了したところで真の安定板になるのですよ… Java8は流石にネタだと信じたい
ネタとしては面白かったけど やれやれ・・・(肩をすくめ、冗談だろ?と失笑しながら、イケメンを少し崩した変顔でつぶやく僕) 昔クソツールと言ってgradleを拒否した爺さんが弊社にいた
蓋を開けてみると新しいからダメっていうか爺さんがわからないからごねてただけだった
爺さん今はKotlinを猛烈に攻撃してる
こういうのって沢山あるんだろうな サポート終わったものは社内のセキュリティ監査で引っかかるから使えんけどなあ >>550
逆もまた然り。
rails 無理やり使わせてメンテせず逃げたバカを何人も知っとるわ。 ドカタ言語としてはJava SE 1.4くらいがちょうどよかった。あれのLTSがあったらなぁ。 railsはさすがにゴミですわ
ド型にすらなれないゴミ グレードルもクソだと思うけどそもそもjavaがクソなのでツールを責めるのは酷だすな
コトリンは救いようがない滅せよ 言語もそうだがクソなものを勧めてくる奴の特徴は
おそろしくモジュラリティーの低いものばっかり勧めてくるってところだ。 その発言!η変換すると「クソなものはモジュラリティが低い」になるぜ! >>556
やっぱりそうなったか…
場当たり的な甘さがこれほど早く破綻をまねく分野もない gradleがクソはまあわかるがantよりはマシ
爺さんがごねなきゃ最低のクソから並みのクソぐらいには昇格できたかもしれない
新技術拒否爺さんは業務効率化を阻む害悪でしかない >>555
今から rails に取り組もうと思っていたのですが…(?然) 気にすんな。世の中には自分の能力が足りなくて理解できないものをクソだということにして
自分の心を安定させようとするやつが居るってだけのことだから。そういうやつは何千年も
前から居る。ほとんど人間という動物の習性だと思っていい。誰でもそういう状態にハマる
可能性がある。ハマってる最中はそいつは他をクソ呼ばわりするだけで新たな事は何も
学習しなくなるので馬鹿な状態が維持されて発展しない。 >>563
いい加減に板を荒らすのやめろよ
特にここ最近はRubyスレを荒らしまくって何考えてんだ? >>564
歴史に何も学ばないやつに発展はない。
https://anond.hatelabo.jp/20171129214218
565はこの種のバカなことを引き起こしといてトンズラするタイプだな。
だいたいこのタイプは仕様が満たされるものだと過信してるタイプで
機能の堅牢性なんてまともにチェックしてない。 歴史を学習した人間より科学を学習した自動運転の方が安全というのが
シンギュラリティの思想だよな どっちも危険な盲信になりえる
>>564 みたいに一方的なのは危険 「新しいものをバカみたいに導入しようとする奴は危険」ってのはまあその通りなんだが
上の「5年後にJava8を導入おじさん」も同じくらい危険人物な訳で
結局突き詰めてメリデメリをジャッジできる思考力ないだけのバカは開発を地獄にするってのは変わらんよね プロコンという語を覚えると便利だよ>メリデメリ
英語のプレゼンでprosとかconsとか見たことあるでしょ?まあ英語というかラテン語なんだけど。 デメリット、コスト、人月の見積もり
見積もりを妄信するのも危険と言われる >>449
>>>448
>なんと!
>日本語審査会で審議しないといけないな。
言い忘れたがこの混同は英語でもある
というか放射能漏れは leakage of radioactivity の直訳 そもそも次世代言語が次世代なうちは個人の趣味プロぐらいにしか使わんだろ HaskellやElixirを実業務で使ってるところも
実在するわけだよな恐ろしい まあHakellに関してはもう次世代というよりLispと似たようなポジションだということで ところで、またATS2に話を戻すんだけど、
日本語訳もあったしチュートリアルやってみてるんだけど
↓の再帰関数の停止性検査とやらで躓いている
ttp://jats-ug.metasepi.org/doc/ATS2/INT2PROGINATS/x2485.html
特に
fun isevn{n: nat} .<2*n>. (n: int n): bool = if n = 0 then true else isodd (n-1)
and isodd{n: nat} .<2*n+1>. (n: int n): bool = not(isevn(n))
が何故.<2 * n>.と.<2 * n + 1>になるか理解できん…
.<n>.と.<n + 1>.で大丈夫だと思ったんだが…
たぶんまだ、停止性メトリクスとやらが正しく理解できていないんだろうな…
誰か詳しく解説してくれないか? ドワンゴが使ってると公言した言語を使ってる会社はドワンゴレベル
気を付けろwwwww ドワンゴってScala以外にもSwift, Kotlin(スマホアプリ)やReact(Typescript)やRustとかも使ってるからな…
開発事例は聞いたことないけどGoの勉強会とかもやってるし…
その基準だと、このスレでよく話題に挙がる言語はほとんど全てドワンゴレベルだな
ドワンゴレベルじゃない次世代言語はDartくらいか?www ドワンゴには、C++ の標準化委員の江添亮もいるし、Rust, Elixir, HDL もやってる。
クックパッドには、RubyVM を作った、笹田耕一もいる
基本は、Ruby。
Gradle で使うGroovy も、Ruby そっくり。
Elixir もそう。
jQuery のメソッドチェーンも、Ruby っぽい
無料のRails チュートリアルをやれば、すべてのフレームワークがわかる 言語と品質には何の関係もないのを
日々実証し続けているドワンゴさん まだRubyのチュートリアルの話してんの?
Rubyっぽい、って、第一言語がRubyだからそう見えるだけだろ。 ドワンゴってエンジニアだけ見ると技術力高そうなのに
なんで成果が全部ゴミなんだろうな YouTube, AbemaTV は、広告
ニコ生は、有料
Showroom は、寄付
ビジネスモデルが異なるから、
1つのチャネルの視聴者数が1万を超えると、追い出す
乃木坂みたいに、数万人も見ると、追い出す。
広告が無いから、1万人以上が無料で見ると、電気代が払えず、赤字になる >>578
isevn.<n>.とisodd.<n+1>.だと
isevn 3 のメトリックは.<n>. = .<3>.
そこから呼ばれるisodd 2 のメトリックも.<n + 1> = .<3>.
減ってねえ!エラー!ってことじゃね
想像だけで試してないので違ってたらすまん >>578
とある関数呼び出しの定義内に表れる再帰的呼び出しの
停止性マトリクスが、大元の関数呼び出しの停止性マトリクスから辞書順で下降していくことから停止性を担保しようというのが停止性マトリクスの意味。
そして停止性マトリクスの記述に表れる n は issven や isodd の引数そのものだということに注意
iseven、isodd の停止性マトリクスがそれぞれ n、n+1 だと、
iseven n の停止性マトリクス→n
iseven n の定義に出てくる isodd (n-1) の停止性マトリクス→n-1+1=n
減っていないから停止性が担保されない(NG)。
説明にあるように <n, 0> と <n,1> ならば、
iseven n の停止性マトリクス→<n,0>
iseven n の定義に出てくる isodd (n-1) の停止性マトリクス→<n-1,1> (下降している!OK)
isodd も同様に
isodd n の停止性マトリクス→<n,1>
isodd n の定義に出てくる iseven (n) の停止性マトリクス→<n,1> (下降している!OK)
そして<n,0>, <n,1> の代わりに n*2, n*2+1 を使っている(この代用が可能なことはわかるよね)。 >>589
>停止性マトリクスが、大元の関数呼び出しの停止性マトリクスから辞書順で下降していくことから停止性を担保しようというのが停止性マトリクスの意味。
この説明「下降していく」だと本当に再起をどんどん
実行していくみたいで間違ってるか。
とある関数呼び出しの停止性マトリクスよりも、
その関数の定義に表れる全ての再帰的呼び出しの停止性マトリクスのほうが辞書順で小さい、
というべきか。 >>589
>isodd も同様に
>isodd n の停止性マトリクス→<n,1>
>isodd n の定義に出てくる iseven (n) の停止性マトリクス→<n,1> (下降している!OK)
最後の行は
isodd n の定義に出てくる iseven (n) の停止性マトリクス→<n,0> (下降している!OK)
の間違いでした 安全装置のたぐいは損失を防ぐばかりで利益は全然ない
利益がないから理解できない人が続出 >>589
ありがとう
冷静に計算していったら、確かにnとn+1じゃ減ってないからダメで
2*nと2*n+1だときちんと減ってるからOKってところまでは理解できた
でも、一体何を考えて<n,0>と<n,1>のタプル?のメトリクスが出てきたか全然分からない…
> そして<n,0>, <n,1> の代わりに n*2, n*2+1 を使っている(この代用が可能なことはわかるよね)。
すまない。俺はバカなんだ。分からないんで教えて下さい。
自分でも自分がどこまで分かっているのかさえよく分かっていないんだが、
たぶん、停止性メトリクスがきちんと減っているかどうかを計算する方法までは理解できたが、
きちんと減っている停止性メトリクスを導き出す方法が分かってないんだと思う >>595
>すまない。俺はバカなんだ。分からないんで教えて下さい。
辞書順を保ったまま <n, 0>, <n,1> をそれぞれ 2*n, 2*n+1 で置き換えられる
3*nとか4nでもいいけど2つしかないから2nで十分
例
fun f
{n:nat} .<3*n>.
(n: int n) : bool =
if n = 0 then true else g (n-1)
and g
{n:nat} .<3*n+2>.
(n: int n) : bool = not (h (n))
and h
{n:nat} .<3*n+1>.
(n: int n) : bool = not (f (n)) >>595
引数のnと、isoddとisevnの2つの関数の区別(+0, +1)を位取り(*2)して足してるだけじゃないかな…… >>581
全部そうだよ
やっぱりJavaやC、Pythonが最終的に一番良いってことだな
新しいものに飛び付いてるとドワンゴになるぞ ドワンゴはc++みたいなもんだな。
とりあえず新言語(新機能)の実験台になってもらえるっていう。 >>599
つまりドワンゴがスレタイ言語は
ほぼ使えないと証明してくれてるってことだな ドワンゴは本当のC++プログラマーも募集してるしな bio100%の戀塚もいるんだよな
いかんせん上がアホだから >>596
辞書順を保ったまま置き換えられるってのが何をしてるのかイマイチよく分からんが
とりあえず、2つの関数で相互再帰なら2n、3つなら3nといった感じ……なのか?
うーん…まだ勉強し始めたばかりだし、やってればそのうち分かるようになるかぁ…
あざっす。 >>604
いやここで堪えて理解しておくべき。
引数から算出できて、再帰で減るものを何か考えてそれを停止性マトリクスとする。
値そのものじゃなく大小関係だけが大事だから、
m が 0 と 1 のどちらかしかなければ
<n, m> の代わりに n*2+m で ok ってこと
例
<5,0> は <4,1> より大 ⇔ 5*2+0 は 4*2+1 より大 ちなみに辞書順というのは停止性メトリクスのタプルについて、
先頭の要素同士を比較、等しければ次の要素同士を比較、また等しければそのまた次の以下略…
という風に比較したときの順序関係 上で散々マトリクスと誤記しているメトリクスはこの場合「(停まるまでの)距離」という意味 >>605
なるほど。(n, 0)と(n, 1)が2nと2n+1に変換できることまでは分かった。ありがたい。
でも、そもそもの話として(n, 0)と(n, 1)っていうのが
一体何を考えて導き出されたのかが分からないんだよ…
チュートリアルに「isevn と isodd に (n, 0) と (n, 1) のメトリクスを与えれば、
これら2つの関数の停止性もまた検査できることは明白です。」って
書いてあるんだけど、俺にとっては全然明白じゃない…
何をどう考えたら(n, 0)と(n, 1)のメトリクスを与えようと思うんだ…?
現状、分かっているのは2nと2n+1ならメトリクスが減っているからOKってところと
(n, 0)と(n, 1)のメトリクスが2nと2n+1に変換できるってところまで…
一番肝心な部分が理解できていない気がする… なんの話か分からないけどこういう奴らが使ってる技術は使いたくない ATSは依存型言語の中でも奇抜な方だと思うよ
Coqとソフトウェアの基礎の方が易しいと思う CoqとAgdaは敬遠してるんだよね…
あの二つはプログラミング言語じゃなくて証明支援器だって聞いてるから…
オレは別にPCに証明問題を解くのを手伝ってもらいたいんじゃなくて、
従来の型システムを発展させた依存型とかを使ったより安全な
プログラミングを行うの方法が知りたいんだよって思って…
けど、学ぶ順番としてはCoqが先のほうが良かったのかな?
でも、Coqだとどうにもモチベーションが…
あと、ついでに線形型も学びたかった……
Rustの所有権・借用・ライフタイムはほぼ理解できてるんでそれほど難しくはないだろうと…
まず、依存型で躓いてるんで線形型までたどり着いていない…
んー……一度に色々やろうとし過ぎか…(´・ω・`) >>608
この場合呼び出しのたびに変化するものが、引数のnと「どちらの関数を呼ぶか」という
2つしかないんだから、呼び出しのたびに減る式を作ろうとしたらこれを組み合わせるしかない
後はパズルだろ 全てのnについて(n, 1)>(n, 0)と2n+1>2nは同値だから当たり前だろ。 わかりにくい記法は自分で自由にわかりやすい記法に変換すればわかる
Cのポインタの記法と同じ
自由に考える方が早い
偉い人にいちいち許可を求めたり質問したりすると時間がかかる >>613
んー…1日置いたらやっと分かったような気がする…
気がしてるだけかもだけどあとは自力でどうにか理解できそう…
まあ、新しい概念を覚えるときはどうしても時間が掛かるものだし、
あとは腑に落ちるまでサンプルコードひたすら写経したりするか…
皆ありがとう
>>610
ATSの依存型は奇抜なの?
他の依存型がある言語も似たようなことやるんじゃないの? 型を静的に解析しつつマクロみたいに評価順序を入れ替えようってのが
そもそも無理があるんだよ。 そもそも型に期待しすぎるのがキモい
型の役目なんてOCamlくらいでちょうどいいのに 型安全のためにDRY原則すら無視してるのあるからな 型安全を崩す水準のDRYはかなり悪い印象があるな
共通化すべきでないものまで共通化してるのではと >>620
ジェネリクスやインターフェース正しく使ってれば
DRY原則無視しなきゃ型安全守れないこととかほぼ無いだろ
どんなコード書いてるんだよ? 型って建物に例えると水準器だろ
柱がまっすぐ立ってるか見るための補助具
補助具ばっか作って家が建つのか? そうか、じゃあ動的言語で作ったプログラムって例えるなら水準器なしで建てられた家なのか…
それは欠陥住宅というもので工期が遅れてる建物よりもっと害悪だと思うんだがそれは… いや単なる犬小屋欲しいだけなのに設計書に一年くらい時間かけるようなもんだ。 >>628
犬小屋ってどれくらいの規模のものを指してるの?
リソース3つくらいのweb apiサーバとか? >>625
それだけじゃないよ。メンテナンスという観点でも必要。
いわば動的言語なら釘で家を建てるけど、
型付きなら、簡単に取り替えられるようにボルトで止まってる。
ちゃんとネジに印がついていて交換ミスも起こりにくい >>629
犬小屋なんだから日曜大工、つまり個人の趣味レベルのものでしょ オプションでも型制約無い言語なんてもうJSとRubyくらいじやね? c++のstd::chornoみたいな設計は行き過ぎた型安全だと思う rubyは絶対に型を書きたくないから
コメントか外部ファイルに型を書くようにするらしいぞ 俺はアプリ屋だからコアの部分は Windows、
Android、iOS、MacOS のどれでも使える c++
UI 側を書く各言語から呼び出して使う あいかわらずRubyの人たちは何がしたいのかよくわからんな C/C++の型はアドレスやサイズの計算に使う
低級言語だから型が役に立つ
高級言語がC++の真似をする必要はないんだよ
型を書かない高級言語はたくさんある コードに型を書かないと後で分からなくなるから結局コメントで型を書くことになるゴミ メソッド名とか使われ方とかコメントとかプログラマのクセとかからAIが型推論してくれるんだろう AIは確率過程だからコードみたいな根幹部分には使いたくないな AIを使ったエラー検出は今後のトレンドになるだろうね
技術進歩に伴って緩やかに型は不要になっていくだろう
IntelliCodeの発展形としてMSがやりそう AIの得意分野はどっちかが必ず勝つ対戦ゲームというブルーオーシャン
レッドオーシャンに飛び込んでも勝てると思うのは確率的に間違ってる >>646
とあるオブジェクトを扱うアルゴリズムが要求するのは型じゃなく
整数っぽいものを返すsize() メソッドは実装していること、
とかそういう制約だよな >>642
python2の型ヒントみたいなやり方するってことかな。まあ実行時には必要ない情報だから
それもリーズナブルな解だと思うけどね。使えるものを早く出してくれさえすれば。 型推論とかAIで検出とかバカほど無駄なことに計算資源使おうとするのな。
そんなカスみたいな機能に資源使うくらいならコンパイル速度上げた方がよっぽどマシ。 >>655
えぇ…
AIは知らんが型推論のほうはコンパイル速度重視のGoでさえ使ってる技術だぞ 単純な右から左の型推論は余計な型名解決が減る分むしろコンパイル速くなるだろ おじいちゃんは自分がよく知らないものは全部無駄に見える生き物だから… >>657
単純な場合はむしろ速くなるの?それは知らんかった
ただ、どっちにしろ型推論ってそんなに計算リソースを消費するイメージないんだけど… 型推論の計算コストは有効範囲と言語の持ってる型システムの表現力でけっこう変わるよ
関数内でのみ有効なのと関数宣言でも使えるのだと随分違う
既存の、コーディング中に型を書くのが苦にならないような言語だと後から型推論追加しても旨味が少ないと思う
Rustはコンパイル速度を気にしてかライフタイム関係の推論が面倒だったのか知らんけど、関数内でしか型推論有効にしなかったのは個人的にマイナス >>660
結局コンパイラがどうやって推論してるかはソース見てみない限り分からないからな
遅くなる場合もあれば、ほとんど変わらない場合もあるだろうし、何とも言えないな…
>>661
俺は逆に関数宣言の型の情報まで推論されるのは好きじゃないな
推論するのはローカル変数だけにしてほしい
まぁ、そこら辺は好みの問題だな Nim IN ACTIONの1章と8章が無料公開されてるから1章読んでみてるけどなかなかセンスいい言語だな しかしスネークケースキャメルケース同一視すんのどうなんだ
識別子に暗黙で余計な解釈しないでほしい
railsの自動変換思い出して嫌な感じ Dとは一緒にしないでいただきたい!
ってのは冗談だけどDとは違うと信じたい
アホみたいに機能消したり追加したりしてないし Facebookで使ってるってのはドワンゴとはまた違った種類の怖さがある なんだんだ理由付けて勉強したくないだけでしょ
わたしはrustで先にゆきますよ rust自体はちょこちょこ迷走やまずい部分も見られるので、本当に使い物になるのは
rustの成果を引き継ぎだか横取りだかした次の言語だと思ってる 個人的に勉強するだけならいいと思いますよ。
他人にクソコンパイラの使用を押し付けなければね。 >>674
swiftかな。swiftはにんきあるよな。俺には理解できないけど。関数型に興味を持つきっかけとnull安全な言語仕様の有効性を教えてくれた QBの契約ですら押し付けではないと擁護する人はいるから
あれより酷いことをしない限り押し付けとの指摘は当たらない 押し付けがましく感じる人がいても知ったことではないよ
そういう雑魚はずっとjava8の導入を検討していればよい、個人的にね コメントは個人の感想
moveとかborrowとか宣言するのは事実を宣言している
後者の方が押し付けがましくないと考えられていた時期もあったのだ
個人の意見を排除し事実だけを述べれば押し付けがましくならないと思ってた Go: マスコットきもい
Rust: C++と潰し合え
Swift: Apple専用の域を出ず
Kotlin: Javaの代わり
Nim: v1.0を出せ、cpp, m, js へのトランスパイルいるか?
D: 最先端を目指した化石 最近の人類がC++を使いこなしているのは想定外だった
短期的に考えると進化するのは言語やAIであり生物は進化するはずがないと思ってた 特有じゃないんだよなあ……
Ruby、Delphi、Haskell、Scalaその他諸々みんな罹患してた
既に治った人は生暖かい目で見てるし、看取った側の人はまたかぐらいにしか思ってない
むしろ>>685の新鮮な反応が羨ましい 今のPM新しい物好きでTypeScript案件でサーバサイドとクライアント側を同時開発するような人だけど、その人でもrustはきついっていうとった。 選民思想批判するなら対案を出せ
仏教?どこの宗派だよ >>688
そういうとこがまさに選民思想って言ってんだが
洗脳って怖いな >>692
プログラマーとは思えないポンコツ発言だな
笑えるけど君の洗脳を解く義務はないので一人でそこにいてくれ 学習しがいのある機能が盛り込まれた言語の最大の欠点て
こういうバカが大量生産されるとこだよな。 そんな因果関係に縛られて予想通りバカになるのは嫌だな
予想を裏切って自由になれよ >予想を裏切って自由になれ
すばらしい!
私も従来の枠にとらわれない、思い込みから離れた、全く新しい発想というものを求めています
嫌いなこともあえてやってみて自分の反応を観察する、とか、
今までやったことのないことを、あえてやってみる、とか
いろいろ試しているのです…
民法をやっていますが、これが全く予想外におもしろいのです 予想を裏切るだけならバカでもできるわけだが。
自由にやるなら個人でやれって話がまるで通じないってのはすごいね。 使う気がないならなぜこのスレにいるのか分からない
勉強しなくていい理由をみんなで出し合って安心するためか てかさ、押し付けられても無視すれば良いだけの話じゃん
仕事のプロジェクトに採用されそうになったら反対すれば良いだけの話
それでも採用された場合はお前の言葉が理論的でなく説得力が無いか
お前がよっぽど社内で信用されていないかのどちらか
その場合は押し付けられたと感じること自体が筋違い swiftはまじでiOS以外の活躍場所増やしてほしい。それから本番 Objctive-CってiOS/Mac以外の現場あったの? swiftってゴチャゴチャ機能詰め込んだモダンなC++って印象しかないけど良い言語なのか IntelliJがあるKotlinのほうがSwiftより強い なんでチェック例外なくしてしもうたん
みんなナチュラルに例外無視して例外が例外した時例外的な挙動になるじゃん
馬鹿? >>714
は?日本語でやりなおせこのカス
しょうもない神とかいってマウント取ってチンポおっ立ててるゴミは死なす >>714
は?日本語でやりなおせこのカス
しょうもない神とかいってマウント取ってチンポおっ立ててるゴミは死なす > If the new version of foo is going to throw a new exception that clients should think about handling, isn't their code broken just by the fact that they didn't expect that exception when they wrote the code?
> Anders Hejlsberg: No, because in a lot of cases, people don't care. They're not going to handle any of these exceptions.
これを堂々と言えるのがヘルスバーグの凄さだよな
言語厨はこういうくだらない問題に固執して、その結果、使えないものを生み出す 1つの誤りを減らすために倍の工数をかけるのは意味がある
100万行に1つエラーがあるとき1つ減ったら品質2倍 チェック例外はステータスコードをリターンして呼び出し側に毎回チェックを要求するようなもの
例外を開発した根本的な理由を否定するおかしな機能だ >>715
英語も読めない奴がなんでこのスレにおるん? >>719
ステータスコードとか黙殺されるじゃないか exitがあるならexitを使え
exitとは違うと言いたいだけのためにcatchするのはやめろ >>701
まあ一理あるよ。
実際転職してこういうバカがいない環境で作業するようになったが
めちゃくちゃ楽になったというのはある。
バカと議論するくらいなら自分の環境を変える方が有効なのは事実だ。 そういえば、Swiftってチェック例外しか無いけど
StackOverflowExceptionみたいなどうしようもないタイプのエラーはどう扱ってるんだ? Swiftのthrowsは投げる例外の種類を特定できない
規模が大きくなればほぼ全てのメソッドにthrowsが付くので何の意味もなくなる
iOSアプリ専用言語ってことでスケーラビリティを捨てて簡潔さを取ったんだよ
全く検査例外の問題を解決していない 議論しなくて楽といいながら反論しないと我慢できないあたり、敗北に耐えられなくなったんだろうなあ パニック パニック パニック みんなが あわててる パトロン見つからなくてプロジェクト終了してたんだな。残念 >>170
は?vscodeもtsも不安しかねえんだけど
シェア一強になるまでは低姿勢、なった瞬間に手のひら返し、が今までのMSのテンプレ
今回もまったく芸のないテンプレでむしろ呆れてるところ
お前みたいなバカが信者かわからんがMS持ち上げる阿呆が出てくるからタチ悪い マイナーvsマイナーだと、設計そのものの良し悪しよりも
どれだけ労力をかけて作り込まれているかの方が影響でかいからなあ……
作ってる側が「いやそこの最適化は後回し」とか思ってるところを測ってもしょうがないし
(いやメジャーvsメジャーでもそういうとこあるけど) 「疑う」の反対は「割る」
割れば楽しいのはわかった上で敢えて疑う方を選ぶんだろう >>738
なんかSmalltalk風味があるな・・・ MSのやり方について講釈垂れる前に
ライセンス見ろよとしか(VSCode,vscode) >>742
陰謀論者は生きづらそうで大変ですね。
もしMSが手のひら返したら、forkするだけですけど? forkするだけ(藁)
強がっちゃってまあ
いいのか?フォフォフォカヌポォしますぞ!!!(憤怒)←草www forkするより製品版を単純にコピーするだけの方が早い
MSの影響で民度が下がる
MSと無関係でいる方が安全 数年前の意識高い系達が「Web開発のスピードにIDEなど邪魔(キリッ」とか言ってたのが嘘みたいだよな
結局のところ彼等は電気を知らない原始人だったのだ Vimは操作性や立ち上がりの速さが優れている
Guiのエディタはプラグイン導入の楽さが優れている
Emacsは間くらい >>742
つーか誰もツッコんでないんだけど、なんでこんな遅レスなんだっていう >>756
Gitlabは少なくとも信頼できる
Azureで動いてるとか言ってる奴いるけどもうやめるって話出てる
エディタはEmacsで十分だし、babelあればES2016でもまともに書けるからTSは不要 >>759
消したあとの対応は信頼できる
MSなら消しても揉み消してた >>760
MSそんな事したことあったっけ?
ただの妄想? 疑問を持つ人はいっぱいいるが疑問を解決する人は少ないのが現実で
すぐに解決すると思うのは非現実的 年食うと一度学んだ思考回路は変えられないんだろうな
多分死ぬまでMSは邪悪でEmacsは最高のエディタなんだろう あとSwiftでパターンマッチ使うときさ「case let」の「let」ってなんの意味有るの?
そもそも「case」自体いらないよね。
Rustみたいに簡潔な構文にしない意味がわからん。 簡潔って記号だらけにしろってこと?
perlでも使ってれば Scalaも構文ダメだけど、Dottyでかなり改善されてるみたいだね
http://dotty.epfl.ch/ >>768
>>769
冗長な構文にするなってこと。
```Rust
match number {
1 => "one",
2 => "two",
_ => "else",
}
```
```swift
switch number {
case 1: return "one"
case 2: return "two"
default: return "else"
}
``` msが嫌いならflow使っとけばいいよ。
俺はTypeScriptで行く >>771
rustをそんなに押すなら、
毎日ちょっとずつ使い方教えていけよ。
面白い内容ならそのまま覚えるから >>770
dottyは流石に見苦しいわ
今更互換性ブチ壊して誰がわざわざScalaなんか使い続けるんだよ
Lightbendは一度プラットフォーム主導者の味を覚えてしまってもう後に引けなくなってるんだろうな 元が冗長だと、機能追加したときの新構文(大抵元と区別のために冗長になる)が
あまり違和感なくなるというメリット?もある
C++とか酷いだろ。rustも多分20年ぐらいしたら酷くなる >>776
Rustが20年も残ってるとか信者かよ >>763
いつMSが邪悪じゃなくなったんだよ
エディタについてはVimとEmacs以上のものがいまだにないだけ >>778
ObjectPascalは30年経ってるが、元が冗長と言われまくってたPascalだったおかげで
魔改造されまくった今でもあんまり浮いた構文は無いぞ
初期Macで採用されてたのは別格としても、その後は大したプロダクトもないDelphiぐらいでしか残ってないのに
一応生き残ってるんだから、FirefoxのあるRustも同じぐらいは残るだろ多分 >>780
どっちかっていうと、若者がMSの暴虐の歴史を学んでないから
今現在進んでる暴虐が暴虐と分からないだけだぞ >>781
火狐に使われてるから残るとか
火狐の世界シェア見てから言おうぜ……
Rustごと自殺して消えるって自白したようなもん この爺さんはこのスレに何しにきとるんだ
特養じゃないっつの >>787が書いてくれたが
俺も、どっちも細々としたもんだがFirefoxのほうがDelphi(製アプリ)よりはまだマシだろう、というつもりだった
その上で20年後の変更されまくったrustはDelphiやswiftより汚くなってそう、という予想 >>785
varがあるのはわかるけど、そこでvarを使う場面てあるのかね?
https://ideone.com/vMGLEg
```swift
case let .B(n):
let t = n+1
return String(t)
```
だって変わらんし >>785
それにvarのときだけつければ良くないかね,Rustだと「mut」つけるだけだけど
https://play.rust-lang.org/?gist=f7bb032027fcdbc6db2f033c4874c27c&version=stable&mode=debug
```rust
AB::B(mut n) => {
n+=1;
n.to_string().into()
}
``` >>791
変数束縛にletとvarがある言語において、switchのときだけ変数束縛を特別扱いしてletやvarを省略できるのは一貫性が無いという考え方もある それに短ければ良いなら、rustのlet mulよりswiftのvarの方が短い
パターンマッチより変数宣言方が良く出て来るしね 20年後に汚くなるってのはみんなわりと納得するんじゃね?
C++もJavaも、時間経過とともにきっちり汚くなった
言語仕様こねくり回すのが仕事の人が存在するからしゃーないっちゃあしゃーない 難しい・易しいではなく汚い・美しいという見方をするのはなんでだろう
数学を諦めた感が漂ってる >>793
そういう見方もあるけどね
でも
```
case let .B(x): return String(n)
```
と
```
case .B(let x): return String(n)
```
の違いってなんなのかね、違いがないなら「let」省略できたほうがいいように思うが >>794
短いことがいいんじゃないよ、理由なく冗長な構文がだめなだけ。
Rustはわざと「var」とかじゃなく「let mut」にしている理由は、通常イミュータブルを使うようにするため。
ミュータブルの構文が長いことでプログラマがイミュータブルをより一般的に使うよう促す効果がある。 可読性の高い綺麗なPerlコードを書けるものだけが石を投げなさい >>799みたいなのは設計当初は綺麗なんだけど
後から、例えばD言語のconst/immutableみたいな選択肢を追加してしまうと罠に化けそうじゃない?(妄想だけど)
その点元が冗長ならある程度耐性がある、という話。後から省略可能にする方はできるしな >>801
Dは全然知らないけど、調べたらデフォルトがミュータブルで、immutableをつけるとイミュータブルになるのか。
```
int x = 3; // ミュータブル
immutable int x = 3; // イミュータブル
auto s = "hello"; // イミュータブル
```
これはひどいな >>802
そこはまあしょうがないとして、イミュータブルにも種類があるという点に注目してくれ コンパイル時に値がわかるのが定数
実行時に初期化するがその後は変更しないのがimmutableかな 加えて、現在のスコープからは変更不可能だが実体はミュータブルかもしれないのがconst
更にそれぞれに推移のON/OFFがある
何も書かないのがイミュータブルだとその内の1つを適当に使ってるということで
選択肢が増えたときにどれか1つが不自然に短く書けてたことになるし
現状を突き詰め直したときにコンテキスト毎に別のだったなんてことになると目も当てられない やっぱり言語仕様は頻繁に変えるべきということだな!w >>802
ゲェジかな
ワイの方がよっぽどいい設計できるわ
この作者はワイのケツ穴でも舐めてた方が幾分有益な人生になったんじゃないかw >>805
GCが必須ではない言語の場合、ミュータブルならばメモリ解放もできる
現在のスコープからは変更不可能だが実体はメモリ解放するかも
というのは非常にまずい
現在のスコープから変更不可能ならば実体も変更不可能にしたい >>808
それだとイミュータブルなオブジェクトを貰って何かする関数に
ミュータブルなオブジェクトを渡せなくならない?
そうすると print とか toString とか hash とか compare とかありとあらゆるものが
immutable / mutable 2種類必要になる
引数に2つオブジェクトがあると4種
3つなら8種 ただの再代入不可な変数をイミュータブルって言い始めたのって何の言語からなの >>795
pythonなんかも細かいところはど汚いわけだがあんまりそういう汚いところ
触らんでも仕事になるって違いはある。
てかシンタックスなんててきとうにチェックでもそんな問題にならんよ。
self書かされることなんて文法で規制されてるわけでもないが問題になることなんてない。 >>810
変更可、不可という概念は別に変数に限った話じゃない Pythonの型アノテーション試してるけど正直苦痛
TypeScriptを使ってるときには全く感じなかった無駄なもの書かされてる感がすごい
というかTypeScriptの統合が完璧すぎるんだな
型書くことはノイズになるどころかコードをむしろ美しくするとすら思えるもんな 少しでも欲を出せばそうなる
完璧な無欲か完璧な満足かの1bitしかない
HaskellやRustのようになるまで止まらないぞ >>814
Python 3.6の変数アノテーションはTypeScriptと大して変わらないのでは?
以前のコメント形式は糞だったけど >>814
全部の変数にアノテーション付けようとしてる?
基本、関数・メソッドの入出力だけでいいぞ
残りは大体推測してくれる >>817
ライブラリなどの既存メソッドの戻り値はほとんど型なしだから結局オレオレ型宣言を左辺の変数に付けて回ることになる >>818
あー、過渡期だからそれはあるかもね
対策としては、他モジュールを呼び出すところはなるべく集める、いきなり完璧を目指さないぐらいか そんなに型に気を使って消耗する位ならもう生js使おう
適当にラッパーかけとけラッパー >>820
TypeScriptユーザーがシコシコ型定義ファイル作ってるおかげで、vscodeでjsでも補完きくんやで。感謝せーや せめて同梱の標準ライブラリくらいは網羅しておいてほしいよね。 >>814
typeScriptみたく型定義ファイルの共有する仕組み無いの?
いちいち書くのはしんどいな。 >>823
しんどいのか
その作業がないということはライブラリの作者は楽をしている
だからライブラリが増やすのも楽
そういう仕組みなんだろう >>824
TypeScriptの場合は型定義を提供することでTypeScriptユーザーに使ってもらいやすくなり、
ユーザーの増加がライブラリ製作者にとって一手間かけるモチベーションになる
Pythonの場合は型アノテーションを付けたらPython3.5以上でしか使えなくなるのでユーザーは確実に減る
結果、誰も対応しない
根本的に破綻してるんだよ >>825
破綻してるのはお前のマウンティングだよ
マウントが酷いのはHaskellで、TypeScriptは無関係みたいなイメージが根本的に壊れた おれ的にはこのまま型定義ファイルがすべてのライブラリに標準装備されて緩やかにjsがts化していくことを希望したい。
最初から型定義がライブラリに入っていること多くなってきたよな、 このスレに来て初めてマウンティングって言葉を知ったわ。 >>823
あるよ。
typeshedてのがそれ
>>825
関数の引数、返値なら3.0から書けるし、コメント使うか別ファイルに書くやり方なら2.7にも対応可能ですが Haxe では型定義ファイルがあるから、型推論も入力補完もできる 通常ならライブラリ本体丸ごと読んで型を調べるべきだ
本体に型がないなら別ファイルに書く >>831
なんだあるんだ。なら型付言語として使われるのも時間の問題だな。
rubyにもあるみたいだし、
ライブラリのインターフェースだけでも型付き当たり前の世界が来そうだね まーたruby信者のそ、そんなのる、るびぃでもできるし!か。呆れ
なんでもかんでも深く考えず流行りをそうやって後付けで増築してって奇形極まってるよね。二度と使わないよ。 rubyの違法建築感は否定しない
が、なんかまとめ臭い書き方だなおい
5chエアプか? るびぃ信者、Proc.new、ラムダ、ブロックにおけるreturn、break、nextの挙動の違いをまとめようとした模様
https://qiita.com/jnchito/items/83410c0cda446efea582
結果、ややこしすぎるためコーディングを工夫してreturnやbreakの使用を避けましょうというなんじゃそりゃな結論www
何か理由があってわざわざ挙動を変えたんだろうが(まさか行き当たりばったりってことはないよね笑)ややこしすぎで使用自体を避けられてちゃ本末転倒だよなwww >>836
その人はrustがコンパイルできないおじさんだからほっときなさい >>834,836
とはいえ、ruby にまともに使える型チェックの実装があるのかには興味あるな。
まえ調べた感じだと、教祖の型チェック周りの発言はフワッフワだし、実装してみたい個人が互換性のない「オレオレ型チェック」を作っては破棄してる感じで、万人が使えるものは何一つないようなんだが。 どうせ
if type(...) != my_class:
とかのシュガーだろ。そんなもんに目くじら立てても意味あるのかね。 Rubyはオモチャだから型付けなんて要りません
それより散らかったオモチャを片付けなさい 自分のために違法建築したとは考えにくい
ユーザーを忖度して違法建築なら利己的ではないからOKという風潮があったんじゃないか
会ったこともないユーザーをモチベーションにするのはやめてほしい >>837
Ruby のProc, block はクロージャだから、クロージャを囲む関数から戻る。
一方ラムダは、単にクロージャを抜けるだけ。
Groovy なども参照
def f
(0..5).each do |i|
puts i
return if i == 3
end
end
f() #=> 0, 1, 2, 3 >Ruby のProc, block はクロージャだから、クロージャを囲む関数から戻る。
クロージャ「だから」、クロージャを囲む関数から戻る??
まるでクロージャだったら当然の挙動と言わんばかりの書き方だけど、クロージャってそんなんだっけ? そんなものちゃんと読んでる>>845に感心したw
ネットにはゴミが多いね クロージャは、クロージャの外側の環境をつかんでいる。
つまり、クロージャを囲む関数内の変数をつかんでいる
だから、クロージャ内でreturn すれば、外側の関数も抜けて、
関数内の変数なども、解放した方が良いと考えた
Groovy の挙動とは違うかも >>848
return だけだったら納得できるんだが、next や break の扱いがぐちゃぐちゃなのはどう説明するの? >>847
関数型でもないウンコ言語がクロージャの話に入ってくんな
何の参考にもならんわ >>837
> まさか行き当たりばったりってことはないよね笑
その、まさかだぞ。
楽しくプログラミング()した結果が仕様だ文句あるか!w クロージャ(block)内のbreak は、クロージャを抜けるだけで、外側の関数は抜けない。
関数の最後まで実行される
クロージャ内のnext は、次の繰り返しに進むだけで、クロージャも抜けない。
クロージャの最後まで実行される
def f
num = 0
(0..5).each do |i|
num = i
break if i == 3
end
puts num
end
f() #=> 3 これ他の言語にも影響あるだろ
continueはバグの原因になるとか、gotoの方がマシとか言われる >>850
えー?closureが関数型特有な概念だと思ってるわけー?
面白いね、それ。本当は純粋関数型ではclosureはさほど重要ではないのだけど。
どうしてclosureが関数型固有な概念だと思ったのか、説明してごらん? >>855
おまえが自分で説明しないで人に説明させようとするからだよ
もし関数型の人が説明したら関数型の概念になるに決まってるだろ >>852
あなたが closure だからと主張する、block は 952の挙動だが Proc では break は例外吐くらしいけど何で?
# 言っちゃ悪いが、closure は定義した時点での環境を基準に動作が普通だと思うんで、
# ループ外で定義されているならば next/break は一律例外吐くで無いと一貫性がないようにしか見えん。 >>857
すまん、「block は >>852の挙動」だな。 このbreakとnextは並列コレクションで困る気はする >>856
へー、技術のベースになる概念が、関数型の人が説明したら別物になるのかー
おもしろいねークスクス Smalltalkの人たちはScalaやRustのtraitsに対して、オリジナルのSmalltalkと違うからダメだ!あれは別物!って批判するくせに
他の言語より後に実装したclosureについては独自仕様でも問題ない、技術ベースで語れっておかしくね?
ダブスタも甚だしいだろ 忖度とか伝言ゲームとかいう問題を織り込むまでがITです >>844はクロージャなら当然あるべき姿としてRubyのProcを語ってるからなぁ
それに対して>>847がヒント:Smalltalkって言ってるのは
要するにSmalltalkがクロージャのあるべき姿を体現してるって言ってるワケで、そりゃ傲慢すぎる
ただの一例としてSmalltalkのような仕様もあるって言うなら批判されないのに クロージャの方が自身の関数スコープを持ってる印象だな
メジャーな中では Java, C#, C++, JavaScript, Obj-C, Swift などがそうだし
Rubyのラムダも上記と概ね同じに見える
ブロックは文字通りコードの塊と考えるとreturnやbreakについて妥当な動きに見える
Proc.newは挙動がキモい
↓によるとdo…endも挙動が違うらしいから >>837 のリンク先は4種で比較した方がいいかもな
https://qiita.com/riocampos/items/43e4431ddff93e01a18d 中身読んだら結合度の差だったので >>865 の最後2行は撤回する >>864
妄想が激しいね。
ヒント:Smalltalkっていうのは、Rubyのそのヘンテコな仕様はSmalltalk由来だということなんだけど。
お大事にね >>862
きみ、結局はSmalltalkでのクロージャからのreturnの仕様を調べることすらしないで
思い込みだけで騒いでるでしょ?
そういうのを「バカ」って言うんだよ >>867
smalltalkには break や continue (next) はないだろう?
ruby のは、closure に break や next を持ち込んでおかしくなっているように見えるよ。 Smalltalkの仕様がどうであれ、それがRubyの仕様を正当化すると思ってなされているレス(>>847だの>>867だの)は
結局Smalltalkの仕様に権威がある、またはRubyがSmalltalkを模倣するだけの理由があるのを前提にしているわけで
傲慢という批判は妥当に思うな 気持ち悪い挙動だと言いがかりをつける気満々のレスに対して
smalltalk でもそうだった昔からある挙動ですよと指摘しているだけでは。
なにも知らなければ議論はできない
といって smalltalk の知識は前提にしていいのかは疑問
とはいえやはり共通の知識がないと議論は無理だし難しいわ Smalltalkを前提にすることに意味はない(Rubyと周辺状況が違いすぎるのに何故真似た?)というのが
すぐ直前の議論では 俺を批判するのはSmalltalkを批判するのと同じだっていうことの意味は一応ある
自分自身を守るためではなく仲間を守るためという大義名分ができる 滅びた言語のヘンテコな機能を真似た言語が
やっぱりヘンテコになって滅びつつある
それだけの話ではある もうRubyの話はやめよう
次世代でも現世代でもないし なんで?
rubyは触ってないけど、rubykaigiとかで盛り上がってる様子見てると、楽しそうだし盛り上がってる感あるけど。未だ現役じゃないの?
スタートアップがrails採用するイメージって、まだ古くないよね?
最近だとrailsのボトルネック部分をgoで書く話が面白かった。 perlの後継になりそこなったし
海外の人気がかなり落ちてるからね
rails用言語で終わってしまった感 railsにincludedされてるバッテリーだろ?www つーかrails言語で別に良くないか?
言語なんて所詮はツールなんだから。
bashでwebサービス作るやつはいないだろ? 目的と結果を比較されるから
目的はこれだったのに結果はこれなのか?と
目的などどうでもいいと断言できる人は少ない >>870
そこまで妄想が激しいようだと治療は困難だね。
でもあきらめないで、先生からもらった薬をちゃんと飲むようにね。
でないと他人様に迷惑かけることになるから。
やくそくだよ。 Smalltalkという完全に終わった言語に執着してるんだから
まあフツーに頭がおかしいんでしょう
薬飲めも普段自分が言われてるんだろうね ここでも見てとれるようにRubyは言語と言うより信者がクソ。
他言語のスレで聞いてもないのにルビーデワールビーデワー宣伝必死過ぎてウザい。
Ruby自体は悪くない。 陰謀論みたいに、お前が世界を支配してるんだろって言われるのは嫌じゃないが >>873
今回のSmalltalkは道連れ的に名前出されただけでむしろ被害者
変なのが混ざってないSmalltalk内ではちゃんと一貫した挙動のはずだろ?知らんけど >>885
よくわからんのだけど
Rubyでは〜って意見が出たらそんなに嫌なん?w
俺なら他の言語でどうって意見はむしろ感心があるが >>883
Smalltalkを知っている != Smalltalk信者
ちゃんとお薬のんでる?
勝手にやめちゃいけないよ? >>891
なあ、smalltalk と ruby に詳しいんだったら、意味の無い罵倒を止めて、 >>869 の答えてくれない? >>891
まあお前がSmalltalk信者かどうかは見た人間が判断するから気にするな。病気が進行するぞ
ただ客観的な事実としてSmalltalkは完全なオワコンw
このスレでは場違いすぎて引くレベル >>894
わかる。awkよりも使い勝手はいい。正規表現処理ツールとして有り。ふとnode.jsでもいい気がしたけど >>862
> Smalltalkの人たちはScalaやRustのtraitsに対して、オリジナルのSmalltalkと違うからダメだ!あれは別物!って批判する
それは「批判」ではなく、理解や運用の混乱を避けるための「区別」の必要性を訴えているのです。
「オブジェクト指向」もそうで、Smalltalkが重きを置く「決定の遅延のためのメッセージングのオブジェクト指向」と
C++以降の「抽象データ型をクラス(またはそれに準ずるエンティティ)で実現するオブジェクト指向」とは区別すべきと一緒です。
批判があるとすればそれは、本質的に違うものに後から同じ名前を付けて混乱を招いていることに対するものでしょうね。 >>862
> 他の言語より後に実装したclosureについては独自仕様でも問題ない、技術ベースで語れ
私はSmalltalk信者wですが、この文脈での>>844の「クロージャだから」もそれを受けた>>847の「ヒント:Smalltalk」も
混乱を招きかねない説明やサジェスチョンだと思いまよ。
# 以下は比較的に古典的かつナイーブな実装の Squeak や Pharo を想定しています。為念。
Ruby の retrun に相当する Smalltalk の(唯一の)制御構造である「^戻り値」は、
Ruby の>>837の例では prco_return や block_retrun と同じ挙動になります。
Object compile: 'rubyReturn
| f ret |
f := [:n | ^ n * 10. "以降に処理を書くとコンパイル時エラー"].
ret := #(1 2 3) collect: f.
^''ret: '', ret printString'.
self rubyReturn "=> 10 "
余談ですが、lambda_return の挙動も「thisContext retrun」(戻り値が欲しいときは「return: 戻り値」)
という表現を使えばまあできなくはないです(が普通はやりません)。
Object compile: 'rubyLambdaReturn
| f ret |
f := [:n | thisContext return: n * 10. #以降の処理は無視].
ret := #(1 2 3) collect: f.
^''ret: '', ret printString'.
self rubyLambdaReturn "=> 'ret: #(10 20 30)' "
いずれにせよ、Smalltalk でクロージャ内のリターンがそのクロージャを実行中のメソッドコンテキストを抜けるという挙動をもって
(継続渡しとかならともかく)Ruby の複雑な状況の説明を試みるのはあまりよい方法ではないのは確かですね。 >>897
pythonやrubyで型を宣言させる話だったな
型を宣言すれば次世代に行けるらしい >>900
かといって、スレタイの TypeScript だって、 Python + 型チェック とあんまり変わらなくないか?
#まあ、TypeScript は次世代じゃないという主張はありだけど 掲示板の書き込みに#で補足コメントするスタイルはキモすぎる どんな言語も最初は簡単で使いやすいと言う。
しかし、注目されて実用レベルになると言語仕様が破綻してくる。
お前さんが使っている次世代言語もいつのまにか消えてなくなるさ とりあえず動的言語嫌いだから次世代に遺さなくていいよ 米は//より#のが好きです
//や’はスカスカし過ぎててなんか >>906
俺逆だ
#の目にうるさいこと極まりない
コメントですらバグったのかと思う スクリプト言語はshebangあるから#じゃないとうれしくないな
コンパイル言語は好きにすればええ >>876
Rubykaigiは井の中の蛙の見本市だから
Ruby最強他言語バーカって精神異常者の集まり
そら宗教の本山みたいなもんだから盛り上がり自体はあるが
技術的にはもう終わってる >>857
Ruby のProc, block はクロージャで、
Procは、blockを変数に入れて、持ち運んで、後で呼べるようにしたもの
その際、block内でbreak を呼ぶと、ループ処理が完遂せず、失敗とみなしたのだろう
ラムダは後に作られたから、return で値を返すようにした
結局、Proc, block、ラムダ、クラス・モジュールも、
スコープチェーンという単一の概念から出来ている
自分の1つ外側のスコープを指す、ポインタを持っている >>911
すげー思い込み強すぎ。中にはそういう人もいるかもだけど多数派じゃないだろ。
原理主義者怖すぎ。あんまり偏りすぎて人刺したりするなよ。 > Procは、blockを変数に入れて、持ち運んで、後で呼べるようにしたもの
これしょうもない設計だよな。
jsとかだったらコールバック関数で統一的に扱えてるところだろ。
こんな本質じゃない言語機能ムダに複雑にして何やってんだか。
わざとパズル難しくして解いて「楽しい」こんな言語かな? >>912
あなたがrubyを好きなのはよくわかる、が
>結局、Proc, block、ラムダ、クラス・モジュールも、
>スコープチェーンという単一の概念から出来ている
>
>自分の1つ外側のスコープを指す、ポインタを持っている
単一の概念にするのは失敗してるんだ
理由は簡単、blockにbreakがあるせい。breakの飛び先は、通常のlexcal scope では解決できない。飛び先は定義時と関係ない、後で呼び出される each などのblockを呼び出す関数内に有るからな
他の内部イテレータ使う言語は、諦めて例外やcall/ccなどの大域ジャンプでエミュすることにしてる。
rubyは頑張ってなんとかしようとして、結局統一出来ず、でも似てるから使用が困惑する結果に 連想配列[名前] = ラムダ
こうして連想配列と代入とラムダで統一すればclassは本質ではないのに
統一を阻止して、classを次世代に遺そうとするのはRubyもECMAScriptも同じ穴の狢 まだ80年代の技術に追いつけないのか、次世代言語wスレの住民は…ばか? Smalltalkとか言うカビ臭いクソ言語について語ってるやつの頭の中だけ80年代で止まってるけど
他の人は普通に話ししてると思うけど >>913
原理主義者怖すぎ、については、
そっくりそのままRubyistにお返しするわ 建て前上だけでもclassを消したら次世代感あると、思います アンチMicrosoftを掲げる以上、Rubyを使うべきだろね。 クロージャの問題は結局変数の評価タイミングが分かりづらくなりやすいってところ。
common lispはその点わかりやすい。 あちらこちらに分身がいて、どれかを書き換えると他に影響してしまう。
そんな混とんとした世界で生き抜くにはいろいろなものが必要になる。
つまり、コピーとムーブが一番楽。 >>920
goとかjsとかparser用意しないとast作れないところを見るとlispが次世代感あるように感じてきた >>926
astそのもの書いてるだけじゃん。
靴に足を合わせる理屈は御免です。 >>920
ドカタの社会に出ろよ
ドカタの社会に出てないの丸わかりレベル低すぎ algol系のシンタックスに合わせてる方が無理がある。 久々に社会に出てみたら、
青春を捧げたRubyがすっかりオワコンになってて哀しいです(^q^) インターンってRubyばっかだな
素人学生にRuby書かせるとか頭おかしなるで
正気か?どうゆうロジックなんだ? 世代的にrubyで育ったリーダが多いからじゃない
外資ではgoとかpythonが多い
メガネのヒョロガリが写真に写っていてRoRエンジニアを募集してたらまずハズレだ 何故breakにしたんだろねRuby。returnじゃ駄目だった理由が分からない Ruby では、break, return、例外も、単一の同じ仕組みを使っている。
コールスタックをさかのぼるポインタ。
つまり、どこから呼ばれて、どこへ戻るか
breakは、1つ外側のスコープへ戻る。
returnは、最も外側のスコープを抜ける
(レキシカル)スコープチェーンと、コールスタックの2大柱。
実装系・VM を作るには、この本がおすすめ
Rubyのしくみ、2014
Rubyの実装系、Ruby1.9のRuby仮想マシンの内部の仕組み 相手が望んでいない解説をするときは、それがスレの内容として意味があるかを基準にするべき
単にこの言語ではこうなっている(中身はさして珍しくもない)というだけならやめとけ。余計嫌われる スレタイに並んでいる言語だとtsは張り合う相手いないから語るようなことないよな
ネイティブアプリ向けも張り合う相手なし
領域が被るのはサーバサイドにおけるrust,swift,kotkin nativeくらい? >>925
だから次世代言語って何よ?
スレタイに沿って話せって言うけど、次世代言語がなにかも曖昧で 旧世代の言語の(しがらみとかで)回避できなかった欠点を既存機能を損なうことなくうまく克服し
次世代を担うべく存在する言語だよ
C++のメモリリークを所有権で回避した「Rust」
Obj-Cのnil禍をオプショナル型で回避した「Swift」
JSの実行時エラーを静的型で回避した「TS」
Rubyはこの20年自らの欠点をちょこちょこ直す以外なにもやっていない TSは別格すぎる
さすがにもう現世代扱いでいいだろ >>937
いや、next はともかく、 break は lexical scope の範囲内では実装出来ないんだよ。
break が for や while でキャッチされる特殊な例外扱いならば、こんなおかしな事にならず、Proc 内でも break 使える様に出来たのに。
>>938
ここでいっているスコープは、 dynamic scope であることに注意ね。
内部イテレータでは、本来 break は例外と同じ方法でしか実装出来ない事を理解いただいて何よりです。
でも、ruby では、 Proc で break 呼び出したときの例外が LocalJumpError になっていて、どういう扱いにしたいかよく分からないんだよね。
for, while 内の break との整合も取れないし
まあ、次世代言語の話じゃないんで、そろそろ突っ込みは止めときます。 swiftが次世代だってぷぷ
めちゃくちゃclassicなんだけど >>947
msが怒涛の開発力で一気に使いやすくしたよなぁ。
しかもEditorとセットで。
しかもlspを考えてどのEditorからでも補完が効くようにしたりとか。
まだ開発スピードが止まる気配がないけど、
他に何を開発する余地があるんだろ。 世代の交代を駆動するのが枯れた技術であってもいいんだよ
まあ仕様の腐った言語しか眼中にない人間には理解できんだろうけどね 開発元が腐ってるRustとTypescript
これは次世代とは言えまい
これが覇権取ったらディストピア一直線 真に次世代の言語はNim
今までの言語の焼き直しに留まらない書きやすさと実行速度を両立した言語で
開発元もモジラとかMSみたいな邪悪な企業じゃない 単なるCのソースコードジェネレータじゃん。
nimが速いんじゃなくてCが速いの。Cのソースコード吐いてCのソースコードコンパイルしてるんだから。
coffeescript()なんかのaltjsと同じようなもんだね笑 高度なシンタックスシュガーだからね
でもCよりは確実に使いやすいしいいと思うよ >>941
c#で言うとasp.netみたいなもの。
c#ユーザだとしてもEFとビュー関数が無いと何もできない低レベルな人間。 ついにMSだけじゃなくてMozillaも槍玉にあげ始めたのか。 Rubyがブロック引数を組み込みの制御構文のように見せたかったというのは旧世代の発想としてはよくわかるけど、
第一級関数や高階関数が十分に一般的なものになった現代においては組み込みのループのように見せるという発想自体がもう時代にあってないと思うわ
むしろ次世代言語は組み込みの制御構文なんか撤廃して関数に寄せればいいと思うんだが、
なかなか手続きベースの言語でforで捨てるものは現れないね forとかを単なる関数として提供してる言語いくつかなかった? >>958
> 制御構文なんか撤廃して関数に寄せればいい
具体的には? >>958
手続き型言語と呼んでいいのかわからんが、tclなら、制御構造は全て「コマンド」扱いで、BNFとか笑っちゃうぐらいシンプル >>958
条件分岐と繰り返しはプログラムの基本構造なわけだが
逆に関数とかサブルーチンとかは基本構造に入ってないわけだが
お前は、超天才かドアホかのどちらかだなw 俺は勝った方の味方するよ。
最初から味方だった、俺のおかげで勝てたみたいな感じで。 第一級関数というやつ
ほとんどの場合意味がわかってないか
勘違いしてるよな
クロージャーっぽく書けたら第一級ってわけじゃないから >>869
> smalltalkには break や continue (next) はないだろう?
横レスだが少なくともXEROXのグループが書籍として出版した初期のSmalltalk-80にはその類のものなかったね
なお、closure本来の議論をする上ではSmalltalk-80のブロックを引き合いに出したのは悪くないと読んでいて思ったけどね
というのはHaskellのような代入命令のない言語でなく代入命令を持つ言語でのclosureとしてはSmalltalk-80のブロックは最も基本形なので議論のベースとしては分かりやすい
本来ならAlgol 68のproc mode(modeは普通の言語での型に相当)の値がclosureなんだがAlgol 68は概念は良く整理されていても用語が変態過ぎて議論のベースとしては使いやすくない
Smalltalk-80のブロックはAlgol 68のprocを素直に継いでいると考えて構わないので、要するにSmalltalk-80のブロックを議論での叩き台にするのは
命令的言語でのclosureとしてオリジナルであるAlgol 68のprocを叩き台としてclosureの議論をしようというものなのでclosureの一般論が目的ならば悪くない
ただ特定の言語、特にrubyのような比較的新しい言語(後述のマイ言語化以降の時代に登場した言語)限定の議論には不適切かも
> ruby のは、closure に break や next を持ち込んでおかしくなっているように見えるよ。
そりゃAlgol 60やAlgol 68やSchemeなどを作った人々とRubyの製作者とはプログラミング言語に対する基本的な見識においてレベルが違いすぎますからね
かつてプログラミング言語の形式的意味論までか否かは別にして言語の基本概念は何かきちんと学び理解するのが常識だったが
簡単に言語を実装できるようになって=マイ言語化されて以降、スクリプト言語のような軽い言語が百花繚乱の如く咲き乱れる(と言えば聞こえは良いが要するに粗製乱造される)ようになって以降
基本概念をきちんと学び理解していない人でも新しい言語は簡単に作れ、上手くファンを掴めるとそれなりに流行ってしまうようになったので
実際にきちんと意味を考えるととても不自然で理解が困難になるような言語機能の組み合わせ方を単に「だって便利だもの」という理由で言語に組み入れられてしまうようになった
単なる便利さだけで深い考慮なく導入されたものを意味論などから合理的・体系的に説明・理解するのは困難、年寄りの戯言でした >>966
空気読めない老人が上から目線でしゃしゃり出てくるのほんとやめてほしいわ
だいたいALGOL68を持ってこようがSmalltalk-80を持ってこようが場違いなのはさして変わらんよ
そもそも誰もクロージャーの本来も一般論も論じてないとか、すでにその話は終了しているとか読んでわからんのかね ボクちゃんの大好きなrubyがディスられて怒り心頭のようだねw >>970
自分の思いを述べてるんだから何もしていなくはない
そういう性格だから嫌われるんじゃない
こいつが嫌いな性格を一般化してるだけだ RustはRustで安全のために犠牲を払いすぎ
そこまで犠牲を払わないNimという選択肢はダメではない >>974
うわぁってなんやねん
空気読むことばっか押し付けるからお前んとこのプロジェクト炎上してるんや 犠牲にしてるかな?どうせやらなきゃいけないことを強制してるだけでわ >>972
スレに沿った議論をしない人は何もしてないと同じなんだよ
お仕事だってそうでしょう ようは後付けで人がついてくりゃリーダシップそのものじゃないか スレに沿った議論といっても誰も次世代言語の話なんてしてないしなw Nim は書きやすさと速度、Rust は安全性と速度、
に注力したイメージなんだが、安全性と速度に比べて、書きやすさと速度って一つの言語でカバーする必要性が薄いように思うんだよな。
従来の「スクリプト言語+速度が必要なところだけC/C++」に比べて、どうしてもNimが良いっていう場面ある? >>978
えぇっ
>>979
途中までしてたじゃん
話につい来れなかったルビーィストとおじいちゃんたちが突然昔話を始めるまでは >>981
もうとっくに日本は移民国家だ
自分が雰囲気の中心にいるんだって顔してるだけで
さしたる理由もなく他人をDisれると思うなよ
昔の次世代言語の話したっていいじゃない >>976
木ですら実装結構しんどいのは犠牲ではなかった……?
Nimならすぐよ >>980
書きやすくて速いとか最強やろ
スクリプト+Cとかめんどくさいんじゃ >>966
Smalltalkのブロックはselfと^の挙動がクロージャとして完全にウンコなので
こんなものを基本形として議論のベースにしたくないです
Schemeの方が1万倍マシです >>983
その木は安全なの?
個人的には木構造実装したりしないから別に困ってないけど Nimは一体いつになったら1.0をリリースするんですかね? Nim製組み込み言語Min
https://min-lang.org
いいんだけどさ、なんで文法Lisp風にしたし。
ホスト言語より書きにくい組み込み言語ってなんやねん Lispに見えて実はForth風では
処理系のサイズを小さくまとめるのが目的みたいだしいいんじゃないかな。どうせ個人の試作言語だろうし いうてもc++の文法なら自分でパースした方がマシだろ。 factorなんか0.97から4年も音沙汰なしだぞ 安全だからRustは良い←わかる
安全でないからNimはいらない。書きやすさとかどうでも良い←それあなたの感想ですよね 書きやすくても保守性が高くなるわけじゃないからな、
自分で書いて自分一人だけで保守するならいいんじゃないかね >>997
いやいや、Rustは可読性も保守性も高いでしょ
書く前にある程度の考える必要があるだけ
むしろ思ったことすぐに書けちゃう言語の方が
可読性も保守性も低いでしょ このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 30日 5時間 45分 54秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。