前スレ
次世代言語17 Go Rust Kotlin TypeScript Julia
https://mevius.5ch.net/test/read.cgi/tech/1567602619/
次世代言語18 Go Rust Elixir Kotlin TypeScript
レス数が1000を超えています。これ以上書き込みはできません。
前スレ
次世代言語17 Go Rust Kotlin TypeScript Julia
https://mevius.5ch.net/test/read.cgi/tech/1567602619/
Rust 完璧な仕事を公務員が定義したような言語
Elixer ダメ親父Erlangの存在を興信所に暴かれるのにビクビクしながら婚活してる言語
Kotlin 乞食共がJetbrainsにカネを落とさないとこに気づかれたら終わる言語
Typescript ブラック企業Javascript社で同期のCoffeescriptが退職するまで耐えてやったー勝ったーと喜んでいるブラック社員みたいな言語
話題にする人少なすぎた
Ruby → Elixir
Java → Kotlin
TypeScript → JavaScript 逆行w
>Ruby → Elixir
Erlang → Elixir, Ruby → Crystalでしょ
実際の人の流れは知らんが
>TypeScript → JavaScript 逆行w
?
前スレ
https://mevius.5ch.net/test/read.cgi/tech/1569852711/
見た感じJavaScriptみたいだったな…
それはハードウェアやOSのベンダーが提供しているAPIがCまたはC++を対象としているからだ
つまりC/C++はプログラマの必修である（ウェブスクリプターはお帰りください）
そして一度CやC++を習得したなら、もはやGoやRustなどという言語は不要なのである
一理ある
FFIとかctypes便利やな
バカほど過大にオーバーヘッドガーとか、ベンチマークも取らずに言い出す。
?????/Uyir
こんなのまであるのにひまわりは
C/C++は生産性が低いやん
GoやRustは比較的生産性が高い
だから不要ではない
生産性はプログラマーの技量によるものであり、言語は関係ない
プログラマーの技量と言語両方関係あるよ
わろた
開発言語が生産性に与える影響の分析
https://www.zai-keicho.or.jp/data/pdf/software/EIRR_vol%2018.pdf
事実が確定して言語が確定するまで待つのは素人だよ
確定する前になぜかフライングできる奴がいる
それが技量なんだよな
中身読んだ？
>開発言語が生産性に与える影響の分析
＞ 上記のことから、プロジェクトで使用する開発言語数が増えると
＞ 生産性が低下する傾向があることが判った。
特定の言語通しの比較だよ。
例えばGoogle は生産性を高くするために Go を作ったし、Javaより生産性が高いとしてKotlin を推奨し始めたし、いろんな点(特にAI)で生産性が高いのでpython を使ってる。
事実は「作るプログラムによって言語を変える方が生産性あがる」ってことだよ。
そんな当たり前のことも理解できないバカはだまってろ。
わかってないやつはスクリプト言語のノリで非効率でMTアンセーフなコード書くし
自称わかってるやつは、他人が読解困難なテンプレートパズルを書いて悦に浸るし
代替言語の需要はある
コードを書いていない (勿論まだ読んでいない) 段階で購入決定してるから
買い物の技量によっぽど自信がある奴にしかできない芸当だから
>特定の言語通しの比較
であれば引っ張ってきた文献は根拠としては意味がないね
やっぱPerl 6だな
Perl6などと言う言語はもはや存在しないぞ
新言語 Raku だ
はぁ〜つっかえ。
haskellってやっぱ実用言語じゃないな。マニアのおもちゃｗ
だけどそのポテンシャルに着目してFacebookなんかが支援してるし
社内で実用的に使ってる
使われるわけないだろ。
アルゴリズムに集中したいからRustはパス
羨ましいようなつまらなそうなような
大学教授か？
c++とrustならどっちがいいかな？
https://japan.zdnet.com/amp/article/35144661/
https://japan.zdnet.com/article/35144661/
ごめん
>メモリー関連のバグを防ぐ目的などでゼロから構築された。
えぇ・・・どっか違う世界から来たのかな・・・
初期から支援してきたのは事実だし文字数的に短いほうがいいんじゃない？
Announcing TypeScript 3.7
https://devblogs.microsoft.com/typescript/announcing-typescript-3-7/
神ってる
良いことだ
Java -> Kotlin
Python -> Python
JavaScript -> TypeScript
こんなイメージなんですがおかしいところあったら教えてください
ポストCはRust
実はGoがPythonからの移行組で賑わってる
サーバの方はそのままJavaか、Goへの移行か
頭おかしなるで
なぜ？
「なぜ？」などというレスをしてしまう時点で、貴殿の頭はおかしなっとる証拠だ
なぜ？
Python -> nim
Ruby → Blawn
ガイジ
>>83
ガイジ
System ...... C++ -> Rust
Application (Android) ...... Java -> Kotlin
Application (iOS/macOS) ...... Objective-C -> Swift
Application (Windows) ...... C# -> Dart
Web (Client-side) ...... JavaScript -> TypeScript
Web (Server-side) ...... PHP -> Hack
Science ...... Python -> Julia
大雑把な理解としてはこれでいいだろ
現世代の八大言語と次世代の八大言語と言ってもいい選出だと思う
Dartの立ち位置は本来はJavaScript枠だがTypeScriptに敗北してからはAndroid、iOS、macOS、Windows、Webのクロスプラットフォームアプリ開発に活路を見出しているので空席になっているC#枠に便宜上置いた
細かい点では不満もあるが一枠に付き一言語という制限を付けて選ぶとこんなもんかなという納得感はある
DartはC#枠ではないと思うがJavaScript枠やJava枠はすでに埋まってる上に他にC#枠に来そうな言語もないので仕方ないか
50年後の視点から見ればC#はGoやらRustやらと同世代として扱われてるんじゃねーの？
TypeScriptに白旗上げてスマホアプリに移行したって認識なんだがKotlinと戦うわけじゃないよね？
GAFAM全社…C、C++、Java、JavaScript、Python
Google…Go、Kotlin、Dart
Amazon…Rust
Facebook…PHP、Hack
Apple…Objective-C
Microsoft…C#、TypeScript
なし…Julia
五大IT企業から一切公認を貰ってないマイナー言語が一つだけ混ざってるわけだが
最強のマルチプラットフォームだろ
Apple公認のSwiftが抜けてた
そういう意味では
AmazonとMicrosoftから公認されたRust
MicrosoftとGoogleから公認されたTypeScript
の2つは生き残るのが確定してるから安泰だな
Juliaはまだ正式版がリリースされて一年なんだから仕方ないだろ
そもそもPythonにしても当初は同世代のJavaやJavaScriptやらと比べて影が薄い存在だけどアカデミアで支持されたことで生き残って後からブレイクしたわけでポストPythonとしてJuliaが同じ道を辿るかもしれん
実際に新規AI開発ならPythonかGoかJuliaかの三択になってるし
俺もDartは10年後には消えると思うわ
そもそもTypeScriptに負けて一度死んだ言語だしflutterで一過性のブーム起こしてもモバイル開発にはKotlinとSwiftがすでにあるから需要ない
誰が支持してるのか一番分からない言語
ガチのゴミオブゴミ、ミラクルマッドマックスゴミ・EX
逆に言うとやっと正式版が出たばかりで、まだpythonの後釜といえるような位置にはいないんじゃないかね。
正式版（1.0）がリリースされた年
1978 C
1985 C++
1986 Objective-C
1994 Python
1995 PHP
1996 Java
1996 JavaScript
2002 C#
2012 Go
2013 Dart
2014 Hack
2014 TypeScript
2014 Swift
2015 Rust
2016 Kotlin
2018 Julia
こうして見るとリリースから時間が経っているのに遅れを取っているのはDartとHackか…
C# -> Dart
ここだけモヤモヤするが代替案がないわ
ちょうどここしか残ってない感
1994から1996は黄金世代だな
2010年代も黄金世代になるのかな？
RubyもDelphiも1995年だしな
WWWが一般に普及してきたタイミングだから新言語がどんどん定着したんだろう
2010年代はGAFA+Microsoft主導の言語置き換え合戦が成功するかどうかってとこか
C#でいいやろ
これ見るとC#は旧世代と次世代の中間世代なのでまだ世代交代する必要がないということだ
C#の代替言語が登場するのは数年後だな
次世代言語1 Go Rust Haskell Scala Erlang Elixir
次世代言語2 Go Rust Haskell Scala Erlang Elixir
次世代言語3 Go Rust Haskell Scala
次世代言語4 Go Rust Kotlin Scala
次世代言語5 Go Rust Scala Haskell
次世代言語6 Rust Kotlin Haskell
次世代言語7 Go Rust Swift Kotlin TypeScript
次世代言語8 Haskell Rust Kotlin TypeScript
次世代言語9 Haskell Rust Kotlin TypeScript Dart
次世代言語10 Rust Swift TypeScript Dart
次世代言語11 Rust Swift TypeScript Dart
次世代言語12 Go Rust Swift Kotlin TypeScript
次世代言語13 Go Rust Swift Kotlin TypeScript
次世代言語14 Elixir Crystal Julia Rust Swift
次世代言語15 Go Rust Swift Kotlin TypeScript
次世代言語16 Go Rust Bosque Kotlin TypeScript
次世代言語17 Go Rust Kotlin TypeScript Julia
次世代言語18 Go Rust Elixir Kotlin TypeScript
登場回数
18回 Rust
12回 Go
11回 TypeScript Kotlin
7回 Swift Haskell
5回 Scala
4回 Elixir
3回 Dart
2回 Julia Erlang
1回 Bosque Crystal
Scalaはギリギリ許されるとしてもJavaよりも歴史が古いHaskellとErlangが新世代言語はさすがに無理あるだろ……
ルーストの期待高杉ィ！
旧世代言語のHaskellがなんで入ってるのか全く分からない
DartとHackはもう退場でいいよ
Google社とFacebook社が作った言語だからって理由以外に存在意義がない
DartはTypeScriptに負けた言語
HackはPHP7に美味しいところだけ取り込まれて役目を終えた言語
General ...... C -> Go
System ...... C++ -> Rust
Application (Windows) ...... C# -> Bosque
Application (macOS/iOS) ...... Objective-C -> Swift
Application (Android) ...... Java -> Kotlin
Web (Client-side) ...... JavaScript -> TypeScript
Web (Server-side) ...... PHP -> Elixir
Science ...... Python -> Julia
これでどうだ
Bosqueはないわｗｗｗ
サーバーサイドなんてElixirよりGo/Rust/TypeScriptの方が獲りそうにも思うが。
思い返してみると言語の流行度をランク付けしたらいつも10位前後をフラフラしていただけで一度として覇権を握ったことはない
信者はPHPerが単細胞の無能で他の言語を覚えられないからRubyが主流にならなかっただけだと思ってるみたいだけど
ポストRubyのポジションはElixirだろうがそこまで価値のあるポジションとは思えない
PHPはゴミ
この5つは大企業がバックについてて一定の信者コミュニティが形成されてるからもう揺るがない
ほかの言語はこれから競争
Pythonの遅さに対するヘイトでPythonブームがしぼむタイミングでどの言語がポストPythonに収まるかって戦いが注目だ
Rubyのまつもとゆきひろが言ってたけど結局言語自体の良し悪しだけじゃなくて有能なコミュニティが形成されるかどうかという要素が重要だからな
TensorFlowがGoに対応してる関係でAI界隈だとPythonからGoへの移行が多いけどJuliaやCrystalのラッパー作ってる人もいるからまだ他の言語にもチャンスある
ちなみにうちはすでにGo
RubyはPythonの地位にあってもおかしくなかった
アカデミックな世界の人たちがPythonに流れたのが大きかった
pythonのシェアを奪えないまま自滅したという方が合ってる気がする。
研究者が使うフレームワークが殆どpytorch一色になったので、
tensorflowもどこまで安泰か分からん
いや、一時期は間違いなくRubyはPythonよりも人気があったよ
日本に限らず世界でね
2000年代に入ってからSciPyとNumPyという科学計算ライブラリの決定版が出たことで一気にPythonの地位が上がった
それまでR言語とかに注目してた層が根こそぎPythonに飛びついて大逆転した
もしSciRubyやNumRubyだったらRubyが天下を取っていたはず
あんな遅い言語で機械学習をやるメリットは何なの？
ディープラーニングは複雑な計算が必要だからこそ高速な言語でやらないとって思ってしまうのは俺がド素人だから？
それだけ
この分野ではライブラリ叩くのだけが役目で速さがいらないからこそPythonが生き残ったんだよ
そういうとこだよ。
rubyが世界的に人気が出たと言えるのはRoR以降で、登場時期はNumpyとほぼ同じなんだよな。
仮にrubyの人気がpythonを上回ったことがあったとしても非常に短い期間に限られたと思われ。
pythonが実行速度が必要なところはcで書けばいいと割り切ってる中で
rubyは言語自体の速さをあげることに時間かけてた。
そういう見識のなさがrubyなんだよ。
炎上PJに巻き込まれて帰ってこれなくなってしまったのだろう
69 名前：デフォルトの名無しさん[sage] 投稿日：2020/01/03(金) 12:58:50.03 ID:f2V4CbYL
あけ おめこ とよろ
おまえら、この空白の2ヶ月間、何してたんだ？
さすがに無知すぎるだろ
PythonもRubyも知らないなら無理すんなw
Ruby信者イライラでウケるw
やっぱrubyやってる輩って低レイヤーのことをまるでわかってないのな。
馬鹿丸出し。
pypyみたいな変態的なものもあるし
むしろrubyの方が言語仕様的に高速化できる余地が少なくて停滞してた印象
yarvも遅れてやってきた感しかない
まぁ身もふたもないけど、つたない英語で日本人がリードするプロジェクトに
外人はあんまり寄り付いてこないのがrubyがいまいち盛り上がらなかった原因だと思うよ
RoRの波の時にいろいろ仕掛けておけば違った気がするんだけど
日本でRubyが人気あるのは日本で誕生した言語(→日本語のドキュメントやコミュニティが充実)だからってのは確実にあるだろうし逆に考えたらアメリカ人は英語圏で誕生した言語を使うわな
Python開発者はオランダ人だけどアメリカで働いていた人だし
結局遅くてもデフォルトのcpythonを使うわけだよ。
そこまでcpuバウンドなプログラムなんて早々ないし、あったらcで実装したライブラリを使う。
なんでも同じ言語だけで無理やり何とかしようってのはバカの発想だわ。
cをどれだけ呼びやすくするかに労力をかけたpythonにrubyは完全に負けたわけよ。
似たようなもんだったと思うけどな
1つの言語で何とかしようとすれば何とかなるかもしれないが開発効率を考えると結局この4つくらいの言語が必要
速さのC++、汎用性のJava、書きやすさのPython、ウェブのJavaScript
最強の言語に統一しようとする試みは全部失敗に終わって適材適所で使い分けるのが結局最適解だったわけだ
次世代言語では汎用性と書きやすさを兼ね備えたGoがあるのでRust、Go、TypeScriptが必須三大言語になる
今のところRustかGoかかな
今は、FFI
言語が流行るかどうかは、便利な拡張ライブラリの作りやすさで決まる。
VSCode がそう。
皆が作る、多くの拡張機能が大人気
R, matlab → Python → Julia
Ruby → Elixir
数十万もする、matlab を誰も使いたくない！
これが無料で使える、Pythonがコスト的に優秀だった！
ただ、文法が辛いから、Ruby風のdo 〜 end を採用した、Juliaへ流れたw
rustは文法もゴミだからね？
許さん
Dartは今一番来てる言語だろ
ちょうどFlutterのスター数がReact Nativeを超えたところだぞ
これで名実ともにクロスプラットフォーム開発のスタンダードがDartになった
「式にセミコロンを付けたら文になる」
「文の評価値はunit」
「ブロックの値は含まれる最後の式(文)の値」
それぞれは筋が通ってなくもないけど、2番目のは
「文の値は含まれる最後の式の値」
にしても問題なかったんじゃないのかな。
問題あるからそうなってるんだよ
具体例plz
Go
Rust
TypeScriptが
旧世代5大言語を超越するのでしょうか？
Go→めっちゃ書きやすい。少ない行数で何でも書けるので生産性爆上げ。実効速度はC/C++よりは遅いがJavaやPythonよりもずっと速いので何にでも使いやすい。文法が分かりやすいので入門用言語にも適している。オールマイティな次世代エース的存在で欠点がほぼない
Rust→C++と同レベルに速い唯一の言語。なおかつC++よりも文法が整理されている。C++と違ってメモリ安全性が確保されている。Goほどの書きやすさ・利便性はないがC++の後継としてシステムプログラミングに使えると考えられている
TypeScript→JavaScriptを大規模開発にも使えるように整備した言語。JSがウェブだけでなくアプリ開発にも使われるようになったという背景にマッチ。既存のJSコードという遺産をそのまま使えるのでデメリットなし
3言語ともにGoogleやMicrosoftが推しているので他企業も追随して移行している
ジェネリクスがまだなくて冗長になりやすい
良くも悪くも割り切ってる
多過ぎるという証拠がない
ほぼ同程度
起動が
今日まで1200円（93%OFF）で買えるよ
現役シリコンバレーエンジニアが教える
Goで始めるスクラッチからのブロックチェーン開発入門
45レクチャー（5時間33分）
https://www.udemy.com/course/go-blockchain/
Bringing engineering insight and experience to blockchain technology.
https://rustinblockchain.org/
returnを省略できるから値を必ず返してしまう
しかも当然Pythonより速いので実用性も高い
次世代では学校でGoを習ってプログラミングを始めて実務でもGoで書ける部分はそのままGoとなりそう
新世代五大言語…Go、Rust、Kotlin、Swift、TypeScript
今のところこんな感じだけどDartやJuliaは五大に入ってきてもおかしくないと思ってる
クロスプラットフォームアプリ開発でDart(Flutter)がReactNativeに勝利しそうな勢いで注目してる
多分DartはJavaライクな文法がJavaScript嫌いなアプリ開発者たちから受けてるんだろう
AndoroidはKotlin、iOSはSwiftという棲み分け自体が不効率の極みなのでDartがもう少し使えるものになればクロスプラットフォーム開発に雪崩を打って移行していくと思う
JuliaはJuliaですでにAI関連で信者層が形成されているしPythonでできることはJuliaでもできる状態になってるからじわじわシェア奪っていけると思う
TensorFlow次第という側面もあるが
一方、サーバーは非効率の極み
基本的にOSやハードウェアのベンダーが使えと言っているものと使うのが正しい
その中でも型システムに関してRustはライフタイム管理と参照の可変性制約に議論の余地があるとはいえそれ以外は程々な落としどころになってると思うんだけどどうよ
つまりはtraitとかenumとかgenericsとかについてなんだけど
なぜC/C++/Java等の手続き型/オブジェクト指向言語では今まで取り入れられてなかったのかが謎
関数戻り値の型推論はされないんだから、関数の型がunitのときは型の不整合とみなさないとか
できると思うがなぁ。
その場合のデメリットって「特別扱いは一貫性に欠ける」というくらいしか思いつかない。
ポインタ型を取り入れるどころか逆に排斥するのが常識だった
たまたま常識を疑うことができたのがC++と関数型言語だっただけ
https://rosettacode.org/wiki/Category:Programming_Languages
https://duckduckgo.com/bang_lite.html
!rosettacode Generics
https://mevius.5ch.net/test/read.cgi/tech/1571717826/
逆だろ。
rustのやろうとしてることを考えればライフタイム管理と参照の可変性制約に議論の余地はない。
他のどうでもいいところに力を入れてることの方が問題。
多分趣旨は同一だと思いますが、私はC++ template がジェネリクスの起源だと
Genericsの起源 → enum
Genericsの起源 → マクロ
Genericsの起源 → キャスト
Genericsの起源 → struct
Genericsの起源 → union
Genericsの起源 → ポインタ
Genericsの起源 → レジスタ
おまえはまだ、本当のCを
知
ら
な
い
ごめんこれは私の書き方が悪かった
Rustのやろうとしてることからすれば議論の余地が無いのは間違いない
ただRustのやろうとしてること（つまりそれらを型システムに落とし込んで管理しようとすること）そのものには反対意見も見られるのでそのように書いた
（私はRustの方針で良いとは思っている）
それなりに一般人類が扱える程々な型システムの機能は言語の目的に依存しない範囲でどの程度かなって話をしたかった
型システムの程々が言語の目的に依存するのは分かった上でなので、それ無しに語る事なんてできないと言われたらはいとしか返せない
あと例にgenericsを書いたのは最近の言語でGoが少なくとも今は取り入れてないからだったんだけど、冒頭に関数型〜と書いてしまったがために >>185 みたいに起源の議論になってしまって申し訳ない
あとgenericsの起源の話をするならAdaちゃんのことも思い出してあげて下さい（小声）
おまえのかーちゃんAV女優
数値計算の闇は深い
LGBTをふまえたモデル化やってみて
基本的にこれだけやっとけばいいわけか
分野次第だろ
例えばiPhoneアプリ作らないならSwiftいらないし
これを満たせるのはC++とJavascriptだけ
ニュータイプ「あっ（察し）」
ライブラリの充実度とかはまだまだだろうけど
上位互換を目指してるというのは正しいけどまだ上位互換とは言えない
C/C++のほうがまだ多少は実効速度が上みたい
体感できるほどの差はもちろんないけど
速くなる要素あるのか？
プロダクトの性能の傾向は Rust > C++ > C
理由は、コンパイラ時のチェック系の支援が大きいほど
プログラマが気を使う量が減って高度な高速化実装がしやすくなるため
実例はServo
一方Cで限界までチューニングすれば他は追いつけない
メンテ難易度は上がるがそれを扱えるメンバーと運用があれば問題無い
実例はLinuxカーネル
Cを置き換えようとする次世代言語は速さでCに負けてたら結局置き換えられないよ
書いたとおりに動くという当たり前のことができる言語は、特に新しい言語においてはほとんどない
と思うじゃん？
実際はコンパイル時間が鬱陶しすぎてクソな通し方するようになる。
コンパイル時間のあれこれを言うならC++こそ人の事言えねぇよ
c++の問題を後追いしてるところはアホとしか言いようないなと思ってるってことだわ。
静的解析パスしないとリリースできなかったりするんだけど
とりあえず静的解析を黙らせるために過剰にvalidity checkが入れられてると思う
そういう無駄をきれいに省けたらc、c++を上回る可能性はあるかもしれない
別にRustだって依存型（定理証明系）とか高階多相（Scalaとか）でコンパイル時間増えてるわけじゃないんだし
オマエ自身が工夫してどうにかしろな仕組みを提供してんのがrustだからのう
関数型へ傾いてるとはいえコンパイル時間がどうこう言うのにrustの例は不適切かな
どんなコードだよそれ。
Project Verona
https://github.com/microsoft/verona
＞ Research programming language for concurrent ownership
ただし過去に戻ったら他の人間とは仲良くできない
その代わりソースコード自体がAIみたいなもの
人間をクビにしてAIを使うとはそういうことよ
人間がいじればAIではなくなる
Rustっぽい言語なのか
/ ヽ
| ノ ー | それRutstでよくねえ？
|(・） （・） | だって、それRutstでよくねえ？
| （ |
ヽ Ｏ 人
＞ー-― ´ ￣￣＼
⊂ニニ￣￣￣ヽ / |
くメ） _ノ | | | | |
(／ | | / | | |
| |/ /| | |
| ﾄ / | | |
ヽ＿_／ | | |
https://www.atmarkit.co.jp/ait/articles/1911/12/news050.html
欲しい機能がまだまだある
Rustは比較的歴史が浅いため、Microsoft社内の開発に使うことを考えると、よく使う言語機能であっても欠けているものがあるという。
その最たるものは、安全な変換(“プレーンな古いデータ”型をrawバイトと間で相互に安全にキャストする)やCスタイルの共用体の安全なサポート、誤りを許容する割り当て(割り当ての失敗でパニックに陥らず、所定の手順で停止する)だ。
Cargoには優れた単体テスト機能が組み込まれているため、開発者が本番コードと同じファイルにユニットテストを記述して、開発中に簡単に実行することができる。だが、Microsoft社内の大規模で複雑なビルドシステムでは、Cargoをビルドツールとして利用できない。
Microsoftとしては未だにRustが本命ではあるが自前でもっといいのが作れないか研究してみるって趣旨みたいだな
Q.
Does Project Verona mean Microsoft is no longer using C++/C#/Rust/...?
A.
Project Verona is a research project that is not affecting engineering choices in the company.
The Project Verona team is connected to the people using all the major languages at the company, and want to learn from their experience, so we can research the problems that matter.
https://github.com/microsoft/verona/blob/master/docs/faq.md
/ ヽ
| ノ ー | それRutstにｺﾝﾄﾘﾋﾞｭｰﾁでよくねえ？
|(・） （・） |
| （ |
ヽ Ｏ 人
＞ー-― ´ ￣￣＼
⊂ニニ￣￣￣ヽ / |
くメ） _ノ | | | | |
(／ | | / | | |
| |/ /| | |
| ﾄ / | | |
ヽ＿_／ | | |
ちょっと前に発表してたBosqueとかどうなったのか続報全然ないけどもう諦めたのか？
遡ればF#とかも期待したほど流行らなかったしもっと遡ればVisual Basicとか散々ゴリ押ししたけど粗大ゴミになってる
Windowsというプラットフォームにあぐらをかいてるわけじゃないだろうがまともに使えるものを生み出す能力あるのか？
C#「……」
TypeScript「……」
TypeScriptはJavaScriptを拡張して静的型付けにしただけ
Microsoftのオリジナルではないからこそまともなものになった
今回新しく作ったVeronaはRustを参考にしてるけどかなりオリジナリティ高そうな感じ
はいパクリ
＞Also, Rust isn't the only language that's inspiring Project Verona,
＞which also borrows concepts from Cyclone, a "safe dialect of C"
＞and Pony, which has key contributors from Microsoft Research.
久しぶりにPonyの話が出てる
Pony大勝利やん
https://github.com/vlang/v/issues?q=label%3A%22Unit%3A+Memory+Management%22
もうRustライクなんて壮言やめて素直にGC入れたら
ヘルスバーグさんめっちゃC++の話してるけど
https://www.codebrary.com/2018/03/deep-inside-c-sharp-interview-with.html
> is that we tried to stay much closer to C++ in our design.
> C# borrows most of its operators, keywords, and statements directly from C++.
何を勘違いしたんだ
MSが出したやつはいつもダサいですね
言語も
製品も
ｗ
コピーださい
ふしぎ
お、おう(笑)
エアプ勢はレガシー言語触ってろ
マイクロソフト、「Rust」に基づくプログラミング言語プロジェクト「Project Verona」がGitHubに
https://japan.zdnet.com/article/35148191/
Veronaとやら頼むぞ・・・
名は体を表すと言う。プログラミングの命名でも、名が体を表すのが良いとされる。
だから、言語名に体を見出そうとするのは自然な感覚。ましてRustのアイコンは
歯車だから、労力が無駄にかかり動作が遅いと思われるのは当然。さらに、Rustは
米国生まれなので、かつては栄えていたが今は没落した北部の重工業地帯を表す
rust beltも連想される。
開発者はこんな変な名前をなぜ選んだのか。真価を分かる人だけが使えば良いという
通好みの言語にしたかったのか。
作者が生物学好きで
名前の由来は錆菌、つまり化合物自体でなく菌の方だそうだ
曰く
> Five-lifecycle-phase heteroecious parasites.
> I mean, that's just crazy.
> talk about over-engineered for survival.
> fungi are amazingly robust to start,
> they are distributed organisms.
> not single cellular, but also no single point of failure.
頭が悪い人がいるだけでは?
http://strlen.com/lobster/
そんなんだからゴーとかいうGOMIにオカマを掘られる
httpの時点でゴミ確
どゆこと？
遅くても、次世代じゃなくても、あの無駄の無さが好き。
ifもforも飾りです。偉い人はそれが分からんとです。
なお知名度なし
なおエコシステムはカス
なお速度はウンポコペチプー以下
動的な部分を個々包み込んで波及を抑えるつーのはプログラミング言語の基本機能に成るべき
例外処理みたいな真逆の言語が大手を振ってるのは異常
俺みたいな素人にも分かりやすいのが欲しい
ちょっと複雑なことしようとするとコンパイラエラーに悩まされる
結局トリックをきちんと理解しないと使えない
今どきletsencryptすらしてないってことじゃね
URL貼る前にhttps試したから俺もちょっと思った
モナド自体より解説がマズいんだと思うけどな
「正しい説明」を意識しすぎて、分かってる奴にしか分からない解説が溢れてる
アセンブラが分かる奴はCのポインタが分かる
ただし言語が二つ必要
Haskellの型を無くしてみろ
それが引き算だろ
unlambdaでもlazy kでもお好きな方をどうぞ
お前らが同じ解説を繰り返す毎に強力な静的型になって行ったんじゃないのか
ランタイム速度が出てないときにどういう手当が可能かという方がよっぽど大事。
荒れるだけだ
プログラミングをしてるのが間違いなんだよ
生得的に向いてないんだから諦めろ
それは大変だな
くやしいか？
文字は文字で難しい
それ昭和の時代だろ。
まぁ世の中には一定の割合で昔の流行語とか昔の駄洒落とか言い続ける層がいて迷惑だとは思う
調べると割分厘は1割を10%とする用法と1割を100%とする用法と2種類あって歴史的にはどちらも正しいんだと
九分九厘は1割を100%とする用法で99%だと
自然言語特有の曖昧定義
つまり95割は950%もしくは9500%
23回と書いて、2,3回と読んでほしいってか?
それはちょっと無理では?
文脈込みでもちょっと無茶だわ
為替操作に駆逐された
分は1/10、厘は1/100で、割合の単位が割で1/10
「9割5分」の「分」は「割の1/10」を意味している
1割を100%とする用法は見たことない
5分も50％
5割5分は55％
ファック
https://www.infoq.com/jp/articles/xtc-lang/
ネーミングはなかなかいいな
やっぱ大手がバックについてないと駄目なのか
もうPHPやRubyの時代とは違って個人が作った言語が日の目を見ることはない
ここの一部が熱狂してた中学生言語はそろそろスポンサーを得たのかな？ｗ
Rubyはパトロンが付いてから落ち目になった印象
ドキュメント ライブラリ ビルドツール IDE プラットフォーム対応
企業にせよ団体にせよ組織的な人手が無いと厳しい
いい言葉ですね！
誰がいったのですか？
rubyが根本から間違ってるところだろ。
型無し糞言語は補完も頭悪いし、書いてて全く楽しくない
おまけに保守性も最悪ときたら、ほんとにほんとにゴミでしかないゴミ
今すぐ回線切って首吊って死ねや
型無しでもいいけれども、宣言なしというのはいただけない
var a
とか VB/VBA 的に option explicit, dim a
とかは、そろそろ導入されるべきでしょう
rubyが保守しにくいとかw
相変わらず低スキル&エアプの巣窟やなココ
今
す
ぐ
回線切って首吊って死ねや
確かに、滅んで欲しい
SML(静的型付け):
- (1, 2, 3);
val it = (1,2,3) : int * int * int (* タプル型(要素は整数型) *)
- (1, true, "Foo");
val it = (1,true,"Foo") : int * bool * string (* タプル型(要素の型は混在) *)
- [1, 2, 3];
val it = [1,2,3] : int list (* リスト型(要素は整数型) *)
- [1, true];
stdIn:12.1-12.9 Error: operator and operand don't agree [overload conflict]
operator domain: [int ty] * [int ty] list
operand: [int ty] * bool list
in expression:
1 :: true :: nil (* 要素の型が混在するリストは誤り *)
(長いので続く)
Python(動的型付け):
>>> (1, 2, 3)
(1, 2, 3) # タプル型(要素は整数型)
>>> (1, True, "Foo")
(1, True, 'Foo') # タプル型(要素の型は混在)
>>> [1, 2, 3]
[1, 2, 3] # リスト型リスト型(要素は整数型)
>>> [1, True]
[1, True] # リスト型(要素の型は混在)
https://www.atmarkit.co.jp/ait/articles/2002/10/news038.html
>Rustのナイトリーチャネルで、非同期プログラミング機能が強化された不安定版が入手できるようになった
>Discordはナイトリーリリースを導入し、問題が発生した際にはRustチームと協力して対処した
頑張ったなｗ
やったね
感染後に何人治癒したかも発表してほしいね。死ななかった人が治癒した人だからいずれはわかることではあるが。
言語仕様自体がゴミの癖にコーディング規約1番うるさい
のほんと腹立つ。
型無し糞言語からJavaの悪いところだけを輸入して、ただの糞言語になった
便器ブラシことゴミ屑PHP（障害者手帳持ち）の悪口を言うな
ペチパーは、クソコードを書かれる前に、打ち首の上さらし首にするしかない。
propertyでのidentifier(ダブルクォート無し)、末尾カンマ、コメント、
undefined(void 0) を削って設定ファイルとしても優秀に出来た仕様をぶち壊した
FFIのモダンな標準っていつまで経っても出てこないな
C言語ヘッダファイルが悪いとは言わないけど
React でも、Ruby のinclude(mix-in)を入れた
mix-in で、親子の継承チェーンの間に入るから、
同名のメソッドが、親の前に、mix-in で見つかる
React で mix-in なんてやることある？
少なくとも、独自コンポーネントの継承は随分昔からアンチパターンとわかってるから、やめた方がいいと思う
というか、最近の React ならほぼ全部 function でいけるぞ
JSON5使えよ
メソッドの探索チェーンが「子 → mix-in → 親」となるので、
同名のメソッドが、親よりも先に、mix-inで見つかる
便利なインターフェースみたいなもの
エリ臭ーの説明が臭逸ｗｗｗｗｗ
Goもっとなんかないの？
どうせc呼ぶくらいしか需要ないんだしそれでいいだろ。
他の言語呼ぶくらいならプロセス切り離してシステム関数つかったらええわ。
C言語が高級言語を呼び出すのがモダン
のか…(困惑)
入門者への分かりやすさを重視して設計したはずなのに、配列のスライスが上端を
含まない半開区間であること。閉区間にすべきだった。
含んでる言語はスライス用途以外に同じ記法を用いる特殊な事情があるやつ
標準化あるいはデファクト化が重要なんすよ
自社ソフト内で使う分にはいいけど
公開APIでJSON5を返す選択は厳しい
>入門者への分かりやすさを重視して設計したはず
言語入門者はともかく、プログラミング入門者を対象とはしてないよ
楽しさや設計の美しさより実務を最優先にした言語
公式にも以下のようにある
> Go was designed to address the problems faced in software development at Google
添字が0始まりだから半開区間にしなければならない理由なんてないだろ。
添字が0始まりでも閉区間のF#やPowerShellの方が入門者にとっても
それ以外の人にとっても直感的で分かりやすい。
だからそれらの言語のは配列のスライス専用の記法じゃないから
let list = [ 1 .. 10 ]
みたいな場面でも使われる
こういう時にはたしかに直感的で便利だけどスライス用途ではむしろ使い難い
RubyやPerlも同じ
スライスでも閉区間の方がはるかに使いやすい。Pythonみたいな奇形言語の真似を
するのはやめてもらいたい。
モナドばりの失笑もんだ
The following expression creates a slice which includes elements 1 through 3 of a:
a[1:4]
`1 through 3 of a` == a[1:4]
さすがGoogle謹製わかりやすい！！！
for x in 1..4 { println!("{}", x); }
> 1 2 3
Java
for(int i : Arrays.asList(0,1,2,3,4).subList(1,4)){ System.out.println(i); }
> 1 2 3
IntStream.range(1,4).forEach(System.out::println);
> 1 2 3
C#
foreach(var i in new int[]{0,1,2,3,4}[1..4]){Console.WriteLine(i);}
> 1 2 3
使ってる言語は俺の中でゴミ確定
うんこをOSS公開しなくていいから
いくら言語を統一してもライブラリを何通りも作るのは合法
ぴーーーーーーーーえいーーーーーーちーーーーーーーーーーーーピューーーーーーーーーーーーーーーーーーー
C言語アウトか
厳しい
p ( 1 .. 3 ).to_a #=> [1, 2, 3]
p ( 1 ... 3 ).to_a #=> [1, 2]
オプションで切り替えられるのも良いかも
( 1 .. 3, true )
たかが高校数学にすら出てくる用語だぞ
開区間，閉区間の意味と関連する話題
https://mathtrain.jp/kukan
first=1, overrun=3
zeroth=1, last=3
(10 ..< 20) → (10 <= x < 20) 要素数: 20-10 = 10
(10 ... 19) → (10 <= x <= 19) 要素数: 19-10+1 = 10
2分割を考える
整数区間の表現や分割は互いに代用可能
(10 ..< 20) → (10 ..< 15) (15 ..< 20) 要素数: 5, 5
(10 ... 19) → (10 ... 14) (15 ... 19) 要素数: 5, 5
実数区間は代用不可能 ※精度の仮定無しに <= 1.9999.. は表現不可
(1.0 ..< 2.0) → (1.0 ..< 1.5) (1.5 ..< 2.0)
(1.0 ... 2.0) → (1.0 ... 1.5) (1.5 ... 2.0) ※境界点のhitTestは両方に該当
閉区間では整数区間と実数区間で考え方が異なる
また、固有の値の数が多くなりがち (10...14) (15...19) → 10,14,15,19
両方あるべきとは思うけど、半開区間の方がロジックが簡潔になることが多い
↓
交換法則を使ったら不正解とする方がロジックが簡潔みたいな風潮
a[1:4]はa[1], a[2], a[3], a[4]にしか見えない。見た目が左右対称だから機能的にも
左右対称な閉区間を表すのが自然。半開区間を表したければ、見た目にも左右非対称な
a[1:<4]にすべきで、1文字増えるだから不満はないだろ。
a[1], a[2], a[3]を指定したいときに、3に1を足して4なんて煩わしいことをするのは
馬鹿げているから、たいていの場合は閉区間が適していて、開区間が適しているのは
>>423のような特殊な場合だけ。
半開区間は「赤上げて、白下げないで青下げて」みたいなひねくれた書き方だから、
閉区間の方が分かりやすい場合にも半開区間を強要するのは、書き間違えやすくバグの
元。お前らも半開区間の言語で、a[1], a[2], a[3]のつもりでa[1:3]と書き間違えた
ことが一度はあるだろ。いや、二度、三度どころかもっとあるはず。白状しろw
print (1 .. 4)
14
*と言えば、Goの巨大数パッケージmath/bigは異様に使いにくいな。
階乗関数の整数版factと巨大整数版Factを書いてみると、C#ではfactのintを
BigIntegerに置換するだけでFactになる。アルゴリズムが本質的に同じときに
同じ書き方をできるのは、分かりやすくて良い。
https://www.ideone.com/T8WbLX
ところが、Goではfactと比べFactには余分なものがたくさん増えている。
*big.Intなんてポインタが現れるし、整数からの変換にbig.NewInt関数が必要だし、
四則演算子を使えず、掛け算は*ではなくMul関数を呼ばないといけない。
こんな実装の裏方を晒して低レベルな書き方をさせるのは、煩雑でバグの元。
C#では許されるp *= n--をGoが許さないのは、評価順序の勘違いによるバグを
防ぐためだろうが、他方で半開区間や巨大数パッケージでバグの温床を与えているのは
設計方針がちぐはぐすぎる
https://www.ideone.com/9ndenp
> 3に1を足して4なんて煩わしいこと
off位置からlen個取りたい → off..<(off+len)
"key=value"からkeyを切り出したい → 0..<(=の位置)
閉区間では1を引くなんて煩わしいことが必要とも言える
使い易さの例がマジックナンバーなのはナンセンスでは？
非対称な構文にすべきという点には異論無いけど
それ以外の部分は、君がそう思っているという以外に根拠が無いように見える
範囲をマジックナンバーで指定したい場面は多い。
閉区間にするため1を引く計算は日常的に染みついているから、煩わしいと思わない。
例えば、2月22日から5日間は、22 + 5 - 1 = 26だから26日までと理解する。
変数で書く場合も、off..<(off + len)よりoff..(off + len - 1)の方が最小値と
最大値が両方明示されていて分かりやすいと思うが、人によって違うだろうし、
半開区間の方が4文字短いので、好みに応じて選べるようにするのが良い。
offを二度書かずに済む構文off+..(len - 1)とoff+..<lenがあるともっと良い。
他の人は半開区間もすぐに染みつくから問題ないのよ。
無いなら作れば良い。
そう。Haskellならね。
組込のindexえんざんし(!!)だとこう
[1..3]!!0
>1
んで、1で始まるindex演算子が欲しければ作る。
(x:_) !!! 1 = x
(_:xs) !!! n = xs !!! (n - 1)
[1..3]!!!1
>1
今のところこいつが一番頭悪そう
ではその期間にログインした人をログイン日時から絞り込むとする
2月22日 <= ログイン日時 <= 2月26日
仕様の具体例として上記を書くのは不具合のリスクがある
2月22日 <= 日単位切り捨て(ログイン日時) <= 2月26日
のように精度を揃える切り捨てを明示するか
2月22日0時0分 <= ログイン日時 < (2月26日0時0分 + 1日間)
のように半開区間にすべき
このような操作が必要なのは、2月22日から2月26日という表現は
実際には「2月22日から2月26日終日」という暗黙の非対称性があるため
Haskellでは範囲を指定してリストを作るときの範囲は閉区間だな。
だから、スライス風演算子!..!を定義すれば、
Prelude> xs !..! ys = map (xs !!) ys
Prelude> [1..10] !..! [1..4]
[2, 3, 4, 5]
となる。
Haskellは言語仕様は難解で有名だが、標準インストールでREPLが提供され、
ソースファイルをいちいち作らずにいろいろ試せて便利だな。C#とF#も
コンパイラ言語だがREPLがある。GoにもREPLが欲しい。Goreという
REPLもどきを作った人はいるが、もどきなので遅くて使い物にならない。
純正で本物のREPLを提供してもらいたい。
一方で時間は「昼休みは12:00〜13:00の1時間」のような半開区間の表現と
12:00〜12:59のような閉区間の表現がある (秒以下もあるので中途半端だが)
ググった限りでは前者の方が一般的に見える
行程表などでの分割では 12:00〜12:30, 12:30〜13:00 のようになる
これは君が「特殊な場合」と言ったものの実例
整数区間の日付と実数区間の時刻
こんなもん誤差ですよ
配列が1から始まったら何か不都合がありますか?
数値計算専用ライブラが
充実してて使いやすればいいだけの話。
言語ネイティブのシンタックスで
そこまでサポートしなくてもいいし、
どうでもいい。
if(0 < x < 10)
くらいの比較演算は確かにあったら便利だよな
なんでこれができる言語はないのか。
もしくはbetweenとか
誤解を招くような記法を使うのではなく、
普通の不等号で挟めるのが一番わかりやすいな。
配列が2から始まったら何か不都合がありますか?
Icon言語ってのがあるよ。
Juliaの話してます？
こういう馬鹿に限って人に自分の感覚を強制しようとする。
_*:;を多用する言語が目に悪くてイラッとする
狼少年は自分の言葉が正しくないと知りながら人に教える
動機は、例えば何かの記憶を消すためにでたらめなデータで上書きするとか
Pythonかな
3項演算子にすればいいだけ
モナドみたいな形で解決できるかもしれないが。
「○〜○」や「○から○まで」という表現は閉区間だよ。13時ちょうどは次の閉区間と
重複し、昼休みであると同時に昼休みではないことになり、厳密に言えばおかしいが、
13時とそれより0.01秒前または後との違いなんて日常感覚では知覚できないから、
このような表現でも問題なく通用している。
秒を小数で表示すれば実数になるが、（連想配列でない）配列の添字は整数しか
ないから、実数を持ち出すのはそれこそナンセンス。実数は数直線上の点だが、
整数は番号が付けられた桝目として捉えられる。配列は下図のようなメモリ格納
イメージだから、
０１２３４５
□■■■□□
黒く塗られた部分をスライスとして指定したければ、その部分の最初と最後の番号を
使ってa[1:3]と書くのが分かりやすく間違えにくい。Excelのセル番地の範囲を
指定するのに閉区間でA1:B3と書き、半開区間でA1:<C4とは書かないのと同じ。
>>441
PowerShell, Python, Rubyのように配列の添字が負の整数-iのとき最後からi番目の
要素を指す仕様の言語では、正の整数iのとき最初からi番目の要素を指す仕様（つまり
添字が1始まり）にする方が整合性が取れて分かりやすいな（実際には0始まり）。
> 配列の添字は整数しかないから、実数を持ち出すのはそれこそナンセンス
区間という概念が配列にしか使われないとでも？
> 13時ちょうどは次の閉区間と重複し、昼休みであると同時に昼休みではない
時間帯毎の集計程度の処理で容易に不具合出しそう
昔は直感的なピクセル座標系も使われていたけど、グリッド座標系の方が合理的だということが理解されて
今じゃそっちが主流だな。
ドラゴンボでたとえて
電流が本当は負の方向にながれててもそのまま正負は変えてないってことの意味を少しは理解しろ。
閉区間に合わせろやと言ってるバカは無視していいってこと。
ドラゴンボでたとえて！
[]演算子は意味のない仕様だよ
()演算子だけでいい
お笑いは意味のない芸だよ
笑いは基本的には嘲笑であり相手との社会的距離による
自分の地位向上が見込めそうなとき笑いが出る
自分と近しい人だとちょっとした失敗のとき笑う、ケガとかは後で自分に面倒がくるから笑えない
自分と距離がすごくある、究極的にはフィクションだと指でつつかれて頭が吹っ飛ぶのに大笑いできるわけだ
愚かさをアピールして反射的な笑いを取る方法だと
長期になるとそいつが愚かなのはわかりきってるので笑えなくなる
状況が思いもしない方向に転換するようなときは長編でも笑える
範囲指定（スライスに限らない）が閉区間だけの言語
Fortran, F#, Haskell, Julia, MATLAB, Octave, Pascal, PowerShell, R, S, Scilab
どう見ても使用者の平均的な知能は半開区間だけの言語より高そうだなw
蛇に唆され禁断の果実を食べ「知恵」を得たが、「知恵」と呼べるほどのものでは
なかった。代償として産みの苦しみが増し、苦労して食物を収穫し、死んで塵に
帰らなければならなくなった――
Pythonに後続し半開区間だけにしたGoは、非合理で書きにくい記法を甘受しなければ
いけない、>>2の表現を借りるなら「イケてない労働者言語」か… その地位を
否定したいなら、改悛して閉区間も取り入れ、Pythonを駆逐してもらいたい。
だからその使用者の平均的な知能が高そうな言語をおまえは使ってたらええやん。
そんなことも通じない人の知能が高いとはとても思えないけれど。
生きるの大変そう
Pythonは何から何までキモくてただ絶滅を願うのみだが、Goは基本的には
良い言語だから、直すべき所は直して、より使いやすい言語になってもらいたい。
教祖様の決定はすべて正しいので信者は黙って従えという言語ではない（Swiftは
C系列の新言語の中では良くできていると思うが）から、不満点があれば改善を
求めて構わない。
>>428にあるGoの巨大数パッケージについてはどう思う? あんな煩雑な書き方で
満足できる? C#のようにすっきり書けるようになってもらいたくないか?
なんで無理にどの言語も同一的にしようとするのか？愚かとしか言いようがない。
お前が挙げてる下の言語にgoに近くなるように言ったらええわ。
Fortran, F#, Haskell, Julia, MATLAB, Octave, Pascal, PowerShell, R, S, Scilab
賢い人ばっかならそっちのが意見きいてくれるだろｗ
1. nが符号付整数でも
for (n = 100; n >= 1; n--) { ... }
が有限ステップで止まる
2. nで表せる上限が65535のとき
for (n = 1; n < 65535; n++) { ... } より
for (n = 1; n <= 65535; n++) { ...
求めるのは構わないがそれに対する反対もまた正当
言語設計者/コアメンバの判断やコミュニティで賛成多数かなどで決まるだろうが
不要な追加は改悪になりうるので説得出来ないなら現状維持が優先される
自分の好みや引き合いに出した言語の使用者の知能が高そうという話で
より多数の使用者を抱える言語の仕様を変えられると考えるのは無理がある
C#のように半開区間で指定できるんだからいいじゃん
後方互換性がない改版はむやみにすべきではないが、不合理な点をいつまでも
引きずるのも良くない。PythonやRubyは後方互換性がない改版を敢行した。
範囲を半開区間でしか指定できずそれをa[1:4]のように書くのは、for文で言えば
for (i = 1; i <= 3; i++) を禁止し、for (i = 1; i < 4; i++) しか許さず、
しかもそれをfor i = 1 to 4と書けと言っているような滅茶苦茶な仕様。
>>479
C#のスライスの歴史は浅く、2019年9月のC#8.0で採用されたばかり。同じ.NET系で
スライスを既に持っていたF#とPowerShellに合わせて閉区間にすべきだったな。
もちろん、a[1..<4]で半開区間を表し、それをF#とPowerShellにも導入するのは
一向に構わない。
数学よりの用途が比較的多い言語が並んでて興味深いな
滅茶苦茶な仕様とやらは閉区間だけの言語には言わないのか？
専用の演算子が用意されていないことを禁止と言い換えるあたりもズレているし
それともそういう動作の関数すら自分で実装出来ないのか
自分の主観を中心にしすぎだ
だから好きな言語を使えという話になる
閉区間だけなのは滅茶苦茶ではない。forループで言えば、Basic, Fortran, Pascalなどは
for i = 1 to 3のような書式しかなく、それでi = 1, 2, 3を網羅する。半開区間にしたければ
whileループを使う。
演算子を使えばすっきり書けるのに、何で>>428の巨大数演算みたいに関数でゴテゴテ
書かなければいけないのか。おまけに関数も自分で実装しなければならないなんて、
それこそ他の言語を使った方が良い。
と思ったが
Goはnon-localな型を直接拡張できないから
自前でラッパーを定義しないとa.slice(1,3)は無理
じゃslice(a, 1, 3)でもいいかって考えるけど
ジェネリックがないから要素の型ごとに関数定義が必要・・・
じゃマクロでコード生成すればいい・・・・・ってマクロもない
詰んどるやんけ
もうa[ｍ:n+1]でええわってなる
言語内で出来る範囲で済んでるうちはまあまあ快適だけど
いざ「これさぁ・・何度も同じパターンでてくるからなんかうまく
楽するやりかた考えられんもんかな」ってはじめると
あーージェネリックないから全部書かないといけないのか面倒くせぇ・・
じゃマクロ・・はないのか・・じゃあどうすれば・・
えええいもういいやベタでシコシコ書こう、ってなりがち
でそういうグチ言うとジェネレーター使えとかいわれるけどあんな
ウンコみたいな機構に頼らないといけない時点でクソすぎるわ
確実に書くための言語なのだよ
まともなビルドシステムも作れないようなお前がうんこなんだよ
仕事を増やすための言語なのだよ
俺みたいな優秀なビジネスマンから見たら同じことしてるだけで偉そうにしてるゴミ
何がしたいのかわからんアホのために
仕事をし、結論をだし、さらにはその意味付けまで考え出す
馬鹿がトップにいても優秀に見えるようにふるまえる
おれはそんなに優秀じゃない
心が死ぬ
赤っ恥かいた
もう来ない
しかも2.7系。依存が深すぎて3系にアップグレードできないｗ
マジンゴーZ？？
２０２０年でサポートおわりやん
ウンコマンﾌﾞﾘｯﾁｮか？
https://www.infoq.com/jp/news/2020/02/ibm-stop-work-swift-server/
IBMは先頃、サーバサイドSwiftの開発を中止した。これはSwiftがオープンソース化して間もなく開始されたもので、Swift Server Worl Griup[SSWG]のリーダシップも同時に譲渡されている。
GoとRust、そしてSwiftは、型安全でコンパイル可能なネイティブ言語として、CおよびC++の代替となる"現代的ネイティブ言語"としてグループ分けされることが少なくありません。
GoはKubernetesのようなクラウドテクノロジのコアインフラストラクチャや、CLIの開発などに使われるシステム言語として、真の得意分野を見つけることに成功しました。
Rustはまだ展開すべき場所を模索している段階ですが、Web Assemblyによって大きな関心を集めるようになっています。
Swiftが採用曲線において遅れを取っていることは否めない事実です。
インターフェース使って無理やり実現するハックもあるけど、ポリモーフィックな関数のUnionをちゃんと単一化できないあたり雑魚いなあという印象
people.eat(curry).yogaFire()
こんな感じか？
$j.touhyo(jimin) === gaiji // true
vector<A>ならvector<B>を返したい
だが引数の型をTとすると返り値の型を宣言できない
いかに最強かが分かるな
たとえばArrayは、Array<number>とかArray<Indo>は具体型(実行時に存在する値をとりうる型という意味で、抽象クラスに対する具象クラスという意味の具体ではないことに注意)だけど、
型引数を入れてないArray<_>のままだと実行時の値をつくれない
これにnumberなど具体型を入力してやれば、はじめてArray<number>などの具体型となる
そこでArray<_>は「具体型に作用して新たな具体型を作るもので、具体型ではないなにか」と考えられ、こういうものを1階カインドとか Type → Type のカインドを持つという
同様に型引数2個のジェネリック型は2階カインドだったり、具体型は0階カインドともいう。
0階以外のカインドを持つ型を総称し高カインド型と呼ぶ
「ジェネリック型に入れられるのが具体型に限定されていること」で、
たとえば map をサポートするジェネリックインターフェースとして
Mappable<f>を作るとする
そのインターフェースを実装できるクラスはカインド１、つまりArray< >など
型引数を1個とるクラスだけにしたい けど、できない
また、カインド Type -> Type -> Type の高カインド型に型１個入れたものは
カインドType -> Type になってほしいけど、こういうこともできない
たとえばkey-valueペアのMap<_, _>なんかは2階カインドだけど、
キータイプだけ指定した Map<string, _> を1階カインドと見なしてMappableを実装させたい（map はMapの各値を変換する関数になる) けど、これもできない
カインド強調する意味がゼロとは言わないがデメリットのほうが大きい
Java8から入ったStreamとOptionalみたいなのを自分で書くのすごい面倒くさい
が無かったらコンパイルエラーになるコンパイラを自分で書けない
はい論破
Higher-kinded typesじゃなくてrank-N typesのことかと
そうすればゴミ機能ってことに気づくから。
https://juliacomputing.com
https://i.imgur.com/cz3K43o.jpg
情弱乙
世界の強キャラ企業は全部Juliaを絶賛してるぞ
自分が理解できなかったものを話してる人がいるからってイライラするなよw
自分ところの基幹言語としてプロジェクト全体の10%以上ぐらいの割合で採用するから。
理解してるから下らねーつってんだよカス。
お前こそその機能の無駄さとバギーさを理解しろ。
わかったわかった。
ジェネリクスについてちゃんと勉強してきてからまた読み直してくれよ。
本当に科学的なやつらはテストを嫌う
勉強しても問題が理解できてないのかよ。。少しは自分でコード組んでみれば？
>本当に科学的なやつらはテストを嫌う
こんな大嘘をよく平気で言えるな。
確かに中途半端にしかポリモーフィズム意識してないお前みてーなやつには
難しくて理解できんのでメンテできる人が限られたコードにはなるという問題はあるな…
let mut n = 5;
println!("{}", n = 4);
println!("{}", n);
〜結果〜
4
5
なるほど分からん
>println!("{}", n = 4);
named parameterがformat stringで使われてないから
エラーにすべきケースかもね
なるほどだけど、
えー…
Rustでは代入式は右辺の評価値ではなく空のタプルを返すとあったから確かめようとしたらこうなったｗ
大根乱ですよ
いや以下expected `i32`, found `()`でエラーになるけど代入の結果空のタプルが返ったればこそでしょ？？どういう意味？
fn foo(x: i32) -> i32 {
x * 2
}
let mut n = 5i32;
let m = foo(n = 4i32);
でもやっぱり見えるスコープが欲しい
これはダイナミックスコープの再発明だな
https://github.com/fusion-engineering/inline-python
https://docs.rs/cpp/0.5.4/cpp/
2行目のn=4は println!マクロの中で
`n`というnamed parameterを新しく定義してそれに4を入れてるので1行目のnとは別物
https://doc.rust-lang.org/std/fmt/index.html#named-parameters
個人的にはエラーにすべきケースだと思うけど
named parameterが明示的に使われてなくても
format stringが必要としてるパラメータの数に合致してるとエラーが出ないっぽい
let x = 100;
println!("{}, {}, {}", x, x=200, y=300); //=> 100, 200, 300
let mut n = 5;
println!("{}", n = 4); //マクロの引数： 代入じゃない（マクロの仕様次第）
println!("{}", n);
print6(n = 7); //関数の引数： これは代入
println!("{}", n);
4
5
6
7
機械学習とかやるにはいいんだろうけど、これでサーバーサイド組むとか狂気もいいとこ
やっぱ型無し言語って糞だわ
過去のおガイジどもが色んな言語使いすぎて保守不能になって
社内標準言語がPythonとJavaScriptだけになったから
>>554
最低でもJava8
どんなに type hinting 書いても IDE は黙ったままだし補完も大して効かないし
糞of糞、糞の山マウンテンがチョモランマ
__init__.pyがないとimportできない糞
pyenv使ってbuildしてもruntimeエラーがでる糞
venv,pipenv,poetry,pyflow, おまえいったいいくつパッケージ管理ツールつくるねんの糞
糞糞糞糞
つまるところ一番の糞はその職場や
これはまあよくある話だが
>社内標準言語がPythonとJavaScriptだけになったから
こうなるのは珍しいな。。普通は逆にこいつの言うように堅めのやつでjava一択とかなりそうな気はするが。
わかっとるわそんなん
だがPythonが糞なのも事実
>>558
超消極的な理由で選ばれただけ
バックエンドは機械学習プロダクトもあるからPythonは必須
フロントエンドはJavaScript必須
他はなんも考えてない
笑えよ
>どんなに type hinting 書いても IDE は黙ったままだし補完も大して効かないし
これはIDE自体の問題か使う側の問題じゃないか？
じゃあVSCodeが糞かpythonのlspが糞かだな
糞ばっかりだ
お前がうんこなんだと思うよ
職場でも無能と思われてそうw
俺の言うこと聞かない言語は全て糞なんだよ糞、糞糞糞の糞
JavaScriptに対するTypescript相当
の言語欲しい
使ったことあるか？
import先もまともに検知できないガチゴミガイジだぞ
そういう問題じゃねえーだろカスが！
でも大抵の言語はライブラリを管理するツール自体が保守不能になる
Pythonは手動またはC言語のツールに丸投げしておけば保守不能にはならない
低レイヤー触るとどうしてもそうなる。
そんな低レイヤーうんぬんなど些細な話だ
そもそも2系から3系への移行ではPython本体やCライブラリだけでなく、
あまたの2系ライブラリのメンテナが膨大なコストを払っているのだから…
「後方互換性の断絶」とはそうゆうものだ
Python利用者はそうした神の決定に逆らうことは許されない
神の行いは絶対であり、聖書PEPを疑ってはならない
結局どこかしらでコストは払ってるんだよ
この辺はいくら次世代のいい感じの言語が出ようとも変わらないと思う
最適な互換性の維持具合についてなんか意見でもあるなら言えばいいけど
なんも考えてなさげだな。
そしてPythonをJavaに置き換えることを意識した時点で
Javaもその駄目なグループのメンバーになったようなもの
GCがある言語は多分みんな駄目になってしまう
ここは「次世代言語に憧れるレガシー言語労働者の愚痴スレ」だから
なんの根拠もなく現状を全く無視したことを平然とのたまう精神はどこからきてるんだろうか。
こういう輩が好みそうなのはrustですかね。
なんの根拠もないものは全く無視されて当然
その精神がある限り、古い仕様は無視されて互換性が無くなる
かつてNumberしかなかったのは、
JS作ってるほうも「JSで数値計算？そんなやつおらへんやろ〜」って感じだったんだと思う。
実際はそんなことはなかったという歴史は知っての通り。
ホームページ上で動的にデザイン変えるための言語だよなそもそもは
json 扱うなら TypeScript さいつよ
直接32bit整数の値を作れはしなくても、内部的にそのような型は存在はしてるはず
JavaScriptではビット演算はオペランドをこの32bit整数に暗黙的に型変換してから
実行するので、これを利用してNumber型を"整数型"に変換できる
a = Math.PI | 0
a == 3 // --> true
実際、JavaScriptにトランスパイルされるAltJSのPureScriptではInt型があるけど、
PSからコンパイルされたJS見てみると、Intは|0で実装されてるのがわかる。
元々誰も使ってなかった上にwasmの登場で完全にいらない子になったけど
ライブラリを追加するだけですむようにしてくれ
むしろ要る子だったからwasmに進化したんだが
分けて考えるのはナンセンス
https://github.com/WebAssembly/design/blob/12ee148fb5cfa33331dbffadae06752b1759a7bf/HighLevelGoals.md
> WebAssembly High-Level Design Goals
> 4. Design v.1 as a Minimum Viable Product: basically what you can do with asm.js.
これが出発点だからな
そのレスはかなり間抜け
すべてのC言語プログラマはBCPLを崇め奉らなきゃいけないのか？
どっちが間抜けだよ
V8はC++で作られてるでしょ？
CコンパイラはBCPLで書かれてるの？
違うでしょ？大抵CかC++で書かれてるでしょ？
何で書かれてるかと何が先祖かの区別つかないとか、頭大丈夫？ｗ
文字列指向というか
asm.jsもテキスト形式だな
マクロがあったらｗ
文ｗ字ｗ列ｗ指ｗ向ｗｗｗ
Rustもマクロがあるから
文ｗ字ｗ列ｗ指ｗ向ｗｗｗ
引数があれば補完後のどこかに挿入されたりする
何が嬉しいの
lisp系とか高級になるとトークンを受け取ってどのような構文木を作って返すかプログラマーが操作できる処理
いいところしか聞かないから聞きたい
Rust使ってると変な人にからまれるから、やめといた方がいい
何をやってもつっかかる
できるはずのことができない
そんなに悪いとこがねーならとっくに他の言語を置き換えてるだろうに。
でも言語自体はよくできてると思うわ
Let's EncryptのやらかしもRustなら防げたんだろうし
結局低レイヤーの配列のインデックスに演算が必要な場合はunsafeだしな。
そういうところで嘘を表に出さないようなことやってるから信用がない。
Rustはそもそも検査されてないので直すところもない
あとは正しい方を選ぶだけの簡単な作業
実害はない。そこを避ければいいだけ。
普通、迂回策も書いてある。
https://www.researchgate.net/figure/Normalized-global-results-for-Energy-Time-and-Memory_tbl2_320436353
どういうバグだったのか見てきたが
何もわかってないのは君のほうみたいだね
https://bugzilla.mozilla.org/show_bug.cgi?id=1619047
https://github.com/letsencrypt/boulder/pull/4690/commits/ba6b85ee126b50d19837a53a52cb6d894594935f
なんで何もわかってないのに偉そうにしちゃうん？
誰が一番信用がないかが分かったな
デプロイ（CD）ってどのファイル転送プロトコル使われることが多いの？
File APIじゃサンドボックスからファイルシステム一切アクセスできない
試験運用中のNative File System API試したらinput type=“file”とできることかわらなくてマジクソ
パスすら取得できないって始まる前から終わってますやん
PWAとかいうその幻想をぶち殺す
ま、クロウムブックだとかグーグルのネットストレージサービスの促進には役だつわな
当然、巨大ファイルをしょっちゅうガリガリやるようなアプリにはまるで使えない
アプリの設定やデータだけキャッシュできればいいならそらそうか……
wasmはブラウザアクセス時にホストからダウンロードして実行とかMSのClickOnceを思い出すわ懐かしい
そしてwasmもサンドボックスの制約から逃れられないから恩恵受けるのゲームだけなんじゃなかろうか
合理的なエコシステムなんて糞くらえよ
AltC？
C99, C11, C18, C2x
C99 の大部分は改悪、C89 こそ正義！
具体的に。
C99 の C++ 互換でない仕様は基本的に害悪
C99 と互換でない C++ の仕様が害悪なのでは？
ボブは訝しんだ
Rustは、有る意味では普通の「手続き型言語」の枠組みを超えてしまっているため、
通常のプログラミング言語の代わりに使うことはほぼ出来ないことが最大の欠点。
関数言語以外ではどの言語でもほぼ共通である所の変数の代入の概念がRustでは
変更になってしまっている。
ファイルシステムに関しては、本当にサンドボックスの外に出られ無い事が
大問題ではあるが、Wasmは雰囲気だけはnativeアプリ見たいには出来る。
ダウンロード時間を含めて起動も速い:
https://yutakaaoki.github.io/demo1/index.html
KotlinとSwiftは、それぞれ、ほぼ AndroidとiOS専用なのに対し、DartとFlutterと組み合わせは、マルチプラットフォームであることが違うことは違う。
Dartは、Javaにも似ているが、初期のころのC++に似ている気がした。
原始的なC++から、型を明示した宣言を省略したような感じ。
C#やSwiftには便利さの点で負けると思うし、確かにJavaにすら負けているかもね。
Rustは、厳格すぎて余計なことに気を取られたりタイプ量が多すぎてむしろC++より生産性は下がりそうだ。
生産性という意味では、C#やJavaの方が上だろう。
結局wasmの売りってホストにデプロイされたバイトコードが如何なる環境でもChromium上で実行可能かつネイティブと迫る速度であるってことだからやっぱターゲットはゲームやモバイルアプリなんだよな
そうなると最近アナウンスされたReactNative for Windows/Macとはベクトルが違うからやっぱクロスプラットフォームって幻想だよな
実際アプリもネイティブで書いた方がメンテしやすいからなみんなネイティブで書いてるもんな
wasiなんてあるのか知らなかったわサンクス
node.jsでも試験的に実装されてて実際に動作するみたいやな
現状ファイルアクセスだけみたいやがネットワーク接続もできるようになるみたいやしnode.jsでwasiがサポートされてるなら完全なクロスプラットフォームが実現しそうやな
グラフィックも使え、GUIも可能。原則、nativeファイルシステムが使えない。
wasi : Wasmを使うがブラウザ外で動かし、今のところCUI専用。native ファイル
システムが使えるので、サーバーサイドの node.jsやJavaの置き換えや
組み込みに向いているらしい。
業務で触ってないと追いつける気がしない
激重なるの？情報も抜かれる？
他にも、
Wasmer, Wasmerio(Wasmer I/O ?), Wasmtime など色々出てきている。
そんなことは無い。
すべてはブラウザのセキュリティーモデルの中で動いているので、
原則的に今までどおりのセキュリティーレベル。
というのは、結局、Wasmで出来ることはJSでできることと変わりが無いため、
JSでどう書いてもできないことは、Wasmでもできないから。
Wasmの大きな利点は、JS以外の言語が使えることで、プログラムが開発し易くなること。
たとえば、JSだと間違いになかなか気づかない箇所でもC++だとコンパイラが発見してくれ、protected属性をつけていれば、他のclassからのアクセス制御なども出来て、保護したい変数に不用意にアクセスできなく出来たりする。
例えばレスポンスで巨大なファイル送りつけるとか(多分レスポンス受け取らないから意味なさそう)
なんでネットすぐタダにしてしまうん
俺は最新のメタはほぼすべて趣味で調べて自宅でコーディングして試してるで
仕事やとまず言語ですら最新のバージョン触れないから言語やフレームワークの新機能やトレンドはすべてプライベートでないとキャッチアップ不可能
じつはネットもぜんぜんタダやないんやで
主に広告によって収入を得る仕組みになっとるんや
ただしサービスを受けとる側が提供してる側へ直接払うみたいな
ドストレートな金の流れにはなってへんし、そもそもサービスを
提供してる側が金をもらうようにはなってない事もようあるで
世の中タダのもんなんてあらへんで
その文脈でwasiはおかしい。wasmかな？
K&R2=C89 で必要にして十分、それ以降は蛇足
> JSでどう書いてもできないことは、Wasmでもできないから。
え？
間違ったことは教えちゃダメよーダメダメ🙅♂
wasmでしかできないこともあるし、JSでしか出来ないこともあるよ
いや、言語が変えられることと、速度が速いこと以外は、Wasmが
出来ることはJSと完全一致で、JSが出来る範囲の事を超えることは出来ない。
これは絶対。
>wasmでしかできないこともあるし、JSでしか出来ないこともあるよ
これはそうだけど
セキュリティ観点でJS onlyでは出来ないけど
wasm使えば出来るってことは無いよね？
クライアントのwasm対応ブラウザからホストにデプロイされたwasmのバイナリをリクエストしてダウンロードされたバイナリをブラウザで実行。
wasmの実行はブラウザ依存で対応ブラウザさえあれば組込だろうとどんな環境でも実行可能かつ高速なのが魅力。
wasm ←
・CaaS、コンテナみたいなもの。
・wasmは現状ブラウザ標準のFile APIしか使用できないのでネイティブファイルシステムにアクセスできない。
・ChromeではNative File System APIが試験導入されてるが、現状できることはinput type=“file”のFile APIとかわらない(これは試した)。
・各言語で書かれたソースコードをコンパイルして、wasmファイル(ブラウザで実行するバイナリ。プラットフォーム毎にバイナリが作られる)を生成。
・よって基本AOTでJITやインタプリタはない？
wasi ←
・PaaS、仮想マシンみたいなもの。
・wasmから利用できるプラットフォーム毎のネイティブファイルシステムAPIを抽象化した実装。
・wasiの機能・使用方法
→ watからモジュール(ライブラリ)を参照して使用する。
→ wasiを使用して書かれたソースコードをwasi対応バイナリとしてコンパイルする、コンパイルされたファイルはwasmだったりしなかったり。
→ wasmを実行するランタイムでもある。
>・各言語で書かれたソースコードをコンパイルして、wasmファイル(ブラウザで実行するバイナリ。プラットフォーム毎にバイナリが作られる)を生成。
「各言語で書かれたソースコードをコンパイルして、wasmファイルを生成」
の部分は正しいが、
Wasmはプラットフォームごとのバイナリではなく、あらゆるプラットフォームで共通の1つのコードだ。
だから、全く同じ *.wasm が Win/Mac/Linux/Android/iOS で、Wasmに対応したあらゆるブラウザで動作する。
なので、プラットフォームごとにキオンパイルしなおす必要は全くない。
>・よって基本AOTでJITやインタプリタはない？
Wasmは基本的にAOTではあるが、実行段階でさらにJITによってさらにコンパイルされて高速に動作される。
この段階でWasmの形式から、CPUのマシン語の形式に変換されることがある。
また、Wasmにはインタプリタも存在している。
> 出来ることはJSと完全一致で、JSが出来る範囲の事を超えることは出来ない。
完全一致www
まぁ色々仕様見た方がいいね
>>681
むしろセキュリティ観点からするとJSの方が安全だよ
"そこ"に関しては特別WASMだけが出来ることはないよ
正しく言えば、Wasmでも、画面の見た目、グラフィック、キーボード/マウス/タッチパネルなどの
入出力、IMEなどを使った日本語入力、XHRやfetchなど、File API, native file API,
などはJSを使ってしか出来ないのでJSで出来ないことはWasmでも出来ないことになるので、
「Wasmで出来ることは使える言語と速度を除いてはJSと完全一致」
ということは正しい。
でもワイ、毎日タダでシコりまくりんグの件
>関数言語以外ではどの言語でもほぼ共通である所の変数の代入の概念がRustでは
>変更になってしまっている。
たいへん良いことじゃん？
変更されない変数を後から探してconstを付けて回る工数が削減される、
難しいとか聞いたので構えてたけど、全く何の違和感も無かった
但し書き方が、もうちょい何とか出来なかったのかとは思うが、Rustが難しいのは概念や仕様じゃなくて書式
参照などの書き方に統一感が無いのは、Perl の関数呼び出しにおける参照型を思い出させる。
結局、分けが分からないので、衰退して言ったようだ。
そのココロは？
Following a very successful first foray into Rust we are migrating an established codebase from C to Rust, and building new functionality primarily in Rust.
https://jobs.apple.com/en-us/details/200144575/software-engineer
https://jobs.apple.com/en-us/details/200117537/software-engineer
ライブラリ等の使用準備はインスタンス駆動よりも
ブロック内に記述/用意したプロパティを言語機能で勝手に読み取り構築してくれるくらいやって欲しいね
機能関数を初めて呼んだ時点でブロック単位最優先のヤツをライブラリに渡してくれるようなの
ブロックの親子関係でマイナスになったら初めてフラグもリセット
Swiftの間違いだろ
造語症を見抜けないことでかえってリソースが浪費される
Pythonの型アノテーション頑張ってたけど
書いてみりゃわかる。
状態変更や共有に気を遣うとインスタンス生成を上手くやる必要が出る。
Goと間違ったのかな？いや流石に無いか、どういう事なんだ釣か？
https://www.phoronix.com/scan.php?page=news_item&;px=Apple-From-C-To-Rust
コンストラクタに一工夫とか釣りなのかエアプなのか判断に苦しむ
strip -s してないだけだろう
すまん、refCell、mut使いまくりの馬鹿には関係ない話だな。
変数を束縛という概念で標準でイミュータブルとして定義されると何が嬉しいんや？constやreadonlyやとあかんのか？
スコープとシャドイーングもクロージャやとあかんのか？有識者からの説明求む
環境やパフォーマンスやなくて言語仕様や機能そのものは個人的にC#が最高やと思うんやけどマイノリティなんかな
開発効率だけで言えばC#の方が圧倒的に上だし、総合的なROIで見てもRustがC#を上回るケースは現実にはほとんどない
Pythonが物足りなくてRust覚えようとしてたけど
C#が思いの外良くてそのままC#使ってる
なるほど、ちゃんと調べてから質問すればよかったわすまんこ
システムプログラミングで使われるC/C++の代替がRust/Goなわけなんやね
調べてて知ったのがRust/Goはtry-catchない仕様なんめっちゃええね
そもそも例外が起きないようにプログラミング書くのに全処理をtry-catchで囲む慣習が個人的にずっと不服やったんよ
そもそも例外も変数で受け取ればええやんてのはほんま納得
Rust/Goでアプリケーション開発できるイージーな環境を誰か構築してほしいな
言語を2つ使うのをやめて1つにするのを狙ってるのがC++やRust
PythonはRubyと競争して勝ってしまった
競争も勝敗もないのがC#やJavaやGo
Rustは、例え一部であっても、参照カウンタも GarbageCollection もなしで、メモリ管理を目指そうとしていた。
束縛や借用を使えばStack変数に関してはそれはある程度成功する。
Heapオブジェクトの自動解放に関しては、Uniqueポインタ的な単一参照や参照カウンタ方式を使っている。
がしかし、循環参照してしまうと誰も使ってないHeapメモリーが自動解放されない現象が起きるので、循環参照を避けることはプログラマの責任で行う設計。
C/C++では、スタック変数を、関数の呼び出し元へ returnしたり、
引数に返したりすることが出来てしまうが、危険なので絶対やってはならないが、
Rustではそれに関してはコンパイル時にエラーが出るので防げる。
同様に関数の途中のブロックの中だけで有効なブロック変数も、ブロックの
外側にポインタ値を渡してはいけないが、これもRustでは防げる。
プログラムのし易さの目的には、Rustは向いていない。
例外を try, catch で囲む以上の面倒くささがあらゆる場面で伴う。
Pythonは、RAD系。C#も、RAD系的。
Rustは、RAD系とは正反対で、深く使いこなそうとするとCよりもC++よりもずっと難しい。
多くの人の投稿を見ているとC++14などの新しいC++が難しいから嫌になって
その代替としてRustを使いたいと思っている。
また、うたい文句である所の「安全、ガベージコレクターなし、簡単なC統合」
などをそのまま真に受けている。
ところが現実は違う。
C++ですら複雑に感じる人は、Rustで独自のリンクリストを設計することは決して出来ないと予言しておく。
そして、それが出来ない状態でシステム作りするのは、とても危険である。
（C++が難しく感じるプログラマの99.9%は、Rustで、標準のリンクリストを僅かでも作り直すことは出来ないだろう。）
あーそうなんか残念やな
C#は登場から20年経ってようやくパフォーマンスに舵を切り始めて俺が使うことはないやろけどSystem.Runtime.Intrinsicsなんかもリリースされたから下々にもパフォーマンスを享受できるようにしてほしいわ
個人的にp/invokeをpythonのようにctypes/cdllでみたいに使いやすくしてくれへんもんかなC++/CLIでラッパー書くのしんどすぎる
食わず嫌いも多いであろう
全処理を囲む？それ設計の問題やろ
なかなか支離滅裂な文章だな
>そもそも例外が起きないようにプログラミング書くのに全処理をtry-catchで囲む慣習が個人的にずっと不服やったんよ
エラーハンドリングの基礎を学んだほうが良さそう
それにRustとGoではエラーハンドリングの機能や考え方は全く違うぞ
そやから慣習って書いてるやんけ
RustやPythonの特徴がどうのとか考えるだけ
無駄では
海外大手を筆頭に導入が広がりだしてるのは確かなんだが
rustはいいぞ！なんで使わないの、やくめでしょっていう話は楽しくない
最近だったらDiscordをrustで書き直したって記事が面白かった
https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
ただ、こういうリライト記事って基本的に「既にある≒要件がとても固まってるシステム」が対象なので、
試行錯誤しながら正解を探すっていう普通のプログラミングに合うのかは分からないよね
最も単純な方法では何か困ったからいっぱい作った
関数型プログラミングとかそんなくだらない事はどーでもいいわけ。
numpyやpandas、数学ライブラが充実してるから
pyを使う
組み込みで機械動かせるからC系を使う
ブラウザはJavaScriptで動作するからJavaScriptを使う
モバイル開発専用の言語だからkotlinやswiftを使う
みんな使ってるからJavaを使う
GoやRustにそれらの専売性がありますか？
ないよね？それを使わざるを得ない状況がないよね？
じゃあ要らないよね。
あれ作った低学歴に説教してやりてえわ
サーバー書くのなら割とGoが最適解の時あるのでは
あの記述力の低さで複雑なドメイン扱える気がしないな
そんなん言われても実際に使ってるところあるし
そんなこと言ったら、PHP 4 だって使ってるところありますよ（笑）
まあ確かにGoは技術力いるかもな
俺は技術力高い所がよく使ってるのは重要な指針になると思ってるんだけど、君はそう思わないタイプ？
いっぱい使ってるし！とマジギレされたでござる
Go信者こわ
そんなことで判断するのは流石にどうかと思うわ。
そういった状況において言語の一定以上の機能性は開発生産性にほとんど寄与しないんだよね
Googleはプログラマの感情を無視して露骨にそれを主張してるから反感を買いがちだけど、
MSなんかも統計的にはその事実はよく理解してるはず
でも一定以下に抑えることができなくなって悪は滅ぶ
この主張が感情ではなく統計的事実だとすると滅ぶのは誰なのか
Windowsの低水準コンポーネントをRustで書いて試用中らしい
>>732
同意、ぶっちゃけ実際の開発って仕様決まってようがRADでコアを作って形になったらそのままスケールしていくって感じが個人的にほとんどなんだよな
とにかく効率的なメタで開発したプログラムをパフォーマンスやメンテがボトルネックだから性能を追求と保守性で最適なメタでリライトしようぜって感じでRust採用って流れじゃなかろうか
それはそう。
結局組織の問題だったりするわけだがプログラマとしては面白くない結論なんだろうっていうのはよくわかる。
逆に感情を抑えるノウハウをほとんど持ってない
複雑なドメインを扱える気がしない
スレ違いな内容を書きたいという感情を抑えることができないのか
後半の文節に関して、Webサービスの世界における究極のRADである Ruby on Rails の
誕生から現在に至るストーリー展開とのデジャブーを感じる
たとえば Twitter は、Rails でスタートアップして「コアをスケールアップ」していくことで
ビジネス的な成功を収め、同時に「パフォーマンスやメンテがボトルネック」だから
内部のコンポーネントを Scala/Java へ移行している
Rust に関して言えば、必須の低水準言語は C であることは変えようが無いという前提のもとで、
それよりやや高水準をターゲットとしている C++ のシェア侵食が起こり得ると考える
それはWebサービスの世界で Rails が PHP の牙城に食い込んでいった歴史の再現だ
もちろん昔も今も PHP の絶対的王者たる地位に揺るぎがあろうはずもなく、
一部の熱狂者たちが Rails のシェアを支えているに過ぎないという事実と重なる
同様に、Rust が一定の認知を得て普及する可能性は高いと同時に、
すべての C++/Java/C# プロジェクトが Rust に置き換わるバラ色の未来もまた存在しないだろう
あちこちのスレで見るよね
まず「文節」を辞書で引こう。
小学校の国語の授業寝てたの？ｗｗｗ
俺の世界ではRubyが王者でそのあとをGoが追ってて、PHPはゴリ押ししてようやく採用されるかどうかなんだが
あんなガイジ言語ありがたがってる程度の底辺とは付き合いがないからかもしれんが
プログラムは無人で動くべきなんだよ
ポエムじゃなくて、｢転生したらPHPが絶対王者だった件｣というラノベかもよ
転職して型無しゲェジのウンポコペチプー糞まみれになって気が狂って
最後はコロナに罹って電車に飛び込む話か
wikipedia も PHP だし…
証拠にメルカリや最近のWeb系企業はPHPではモダンな言語でWebを作っている
でも俺はGoは好きじゃないけど
PHPではなくモダンな言語でWebを作っている
＞PHPではモダンな言語でWebを作っている
言ってることが矛盾していませんか？
了解しました
承知しましただろうが
日本語もまともに使えないガイジ
情けない
世も末だな
金儲けして何が悪いの？っていう魔法の言葉があるから
Rustなんだから合ってるだろ；
>>706
Rustなんだから合ってるだろ；；
https://www.youtube.com/watch?v=td6cX0en4oI
初心者に、Rails を推奨する、雑食系エンジニア・KENTA を批判して、
Java, PHP を勧める、モローに対して、批判殺到w
PHP は、プログラマー向けの本がほとんどない。
WordPress の説明本ばかりだから、上達しない
Java は、数倍の勉強時間が掛かる。
人間の成長率を、同じ勉強時間で比べていないだろ
それと雇用形態が異なる。
Java は5大ITer を頂点とする、使い捨て奴隷・土方系。
建設業と同じで、1社経由するごとに、3割抜かれる
時給5千円 * 180時間 = 1人月90万円でも、
元請けが30万円、1元請けが20万円、2元請けが10万円と抜いていく
COBOL, Java, VB というのが3大土方言語。
でも銀行の更新時期が過ぎたから、仕事が無くなった
業界調査すると、ブラック過ぎて、他人に勧められない。
一方、5大ITerは、社員の給料を高くしたいから、都合のよい使い捨ての奴隷が欲しい
しかも慎重にコーディングする優秀な奴らばっかのチームなら機能するんじゃないかという気はしてきた。
まあそんなチームは日本にはないだろうなという気もする。
てか世界でもほとんどないんじゃないかな。
GAFAでも優秀なごく限られた一部だけだろう。
んでもってそういうところならc++でも十分な品質のものが書けるっていうね。。
Rustに書き換えやってるわけですが
この辺とかのこと言ってるなら、俺は勧めないよ。
糞製品作らされるだけなのが目に見えてる。
まあ個人の自由だからやりたいならやればいいと思うが。
むしろ逆だわ
Rustが書けない(メモリの所有権、借用、ライフタイムの概念が理解できない)プログラマが
まともなC++のコードを書けるとは思えない
Rustはプログラマが間違えたらコンパイラが誤りを指摘してくれるが
C++はプログラマが間違えても何もしてくれないからほっとくと脆弱性まみれのプログラムになる
動くPHPと
動かないRust
ビジネスチャンスを鷲掴むのはどっちだと思う？ｗ
>まともなC++のコードを書けるとは思えない
これは正しいと思うけど、そもそもc++をまともに書ける奴は少ないし、
c++をまともに書けるやつがrustのコンパイルチェックで
得られる恩恵ってやつは君が思うほどおおきくないってのが俺個人の意見だわ。
それでもってランタイムの品質、ハードウェアに対する対応なんかを考えた場合、
c++のが上になるっていうことが考慮から外れているように見受けられる。
こういう奴は良い会社や良いプロダクトの
例は出せやしない
本来、変数とは読んで字のごとく「変化する数」なわけだから
本質的に mutable(変更可能な)なもの。
にも関わらずRustでは、変更可能な変数には mut を指定しなければならないので
確率論的にはソースコードの量が増えてしまうことになる。
さらにいえば、Rustでは、型を明示する場合は、
let a:TYPE = xxx; // (1), TYPE は xxx の型
と書くが、:TYPE を省略して、
let a = xxx; // (2)
のようにもaの型を書くと自動推論する機能を持っている。
C++にもあるバージョンから auto などでこれと同様の機能が入って、
一見便利だが、型がわかりにくくて問題にある可能性がある。
逆に、C++ だと型を明示する場合には、
TYPE a = xxx; // (3)
と(1)に比べて短く書けることも重要。
Rustだと:TYPEを書くのが面倒なために、(2)ように省略してしまう
人が続出する可能性がある。
これは問題だ。
誤：のようにもaの型を書くと自動推論する機能を持っている。
正：のように型を自動推論する機能を持っている。
今どきimmutableな変数も受け入れられないとかどんだけ化石なんだよ
スマヌ
極度の低空飛行で、人気は横ばいよりも下がり気味だ。
非難する人を「古い人」扱いすれば切り抜けられると思ったら大間違いだ。
しかし、C++ の場合、new の働きは明確なのに対し、
Rustは、Box::new のコードを見ても、「box」という組み込みキーワードを
使ってしまっているのでそれ以上追う事は出来ず、曖昧さが残る。
C++の場合は、少なくともC++98までだとかなり原始的なレベルまで
やっていることが明確だった。C++11あたりから異常になったが。
俺もRustは指示するわけではないが、問題点として挙げるのがほんのわずかなタイプ数だなんて、根拠としては弱いというかどうでも良い話だろ
C++が使いこなせる程度の適正があるプログラマにとっては、タイプ量の増加
は苦痛以外の何者でもない。
彼らは特にC++でバグに悩まされたりしてるわけじゃないのだから。
Rustをつくりだして、または使ってるんだろうなｗ
相手するだけ無駄
頭が賢ければ、タイプする体力と時間が不要なのだよ。
頭が悪い人は、体力と時間で勝負するしかないからタイプ量が多い言語を使うしかない。
読みやすいかどうか
と
int a = x;
なら、後者は短いのに分かり易い。コンパイラに伝達される情報は同じだし。
let a = x; //(1)
と
let a:i32 = x; //(2)
なら、そもそもコンパイラに伝わる情報が違い、後者は記述量が多くてもバグの少ないプログラミングに役立つ。
後から読み直しても a を i32 型にしたいプログラマの意図が分かって分かり易い。
だから、記述量が増えても後者は良い面を持つ。
ところが、Cで
int a = x; //(3)
と書けば、Rustの(2)と全く同じ情報がコンパイラに伝わり、エラーチェックのレベルも同程度だから、
Cは、少ない記述量で同じ事ができると言える。
(1)と(2)の違いと、(2)と(3)の違いを混同してはならない。
前者は記述量が多くなっても安全性向上という意味で意味が有るのに対し、後者は、書くのが長くなるだけで全く意味が無いのだから。
GoやJavaにさえある
つまり問題視する方がお菓子い
その哲学を壊す言語が増えてきているだけ。
型無し言語かhaskellでもやってろ
主張していたアホだから
高度な型推論はいずれチューリング完全性を有して機械的手続きでは御しきれなくなる
そして人類が機械でないという証拠は今のところ無い
型推論は、C++は template が深くて複雑すぎて、templateを使っているときに、
人間側が結果や変数の本当の型が分からなくなってきたので、しょうがなく
最近になって導入された。
もしこれをちゃんと手で書くと複雑で長い型になり過ぎる。
templateはソースがあるが読んでも複雑すぎて多くのC++プログラマには型が分からない。
また、templateはRADのような簡単に機能を使いたいときに使えるように設計された
ものなのに、型が難しすぎてわからないということは本末転倒であった。
そのためにしょうがなく型推論できる機能がC++に導入された。
型を打つこと自体は良いんだ。
>>806 を読むべし。
そうじゃない。
nullable指定を明示的に行うことは良いと思うが、
nullを絶対悪として、NullObjectとPolymorphismで対応することで
nullを完全排除しようとしている一部の人に対して反論していただけだ。
この謎のゴリ押しにタダ乗りして得をしてるのはRustも同じ
型無し数値リテラルはデフォルトでi32でintと変わらないし数値リテラルで変えたい時は明示的にする
だから
long int a = 1;
より
let a = 1i64;
または
let a: i64 = 1;
の方がデフォルト以外の型が現れるかつタイプ数も少ない
こういうやつらはなんで後置型指定でletで変数宣言するか意図を理解してない
そもそもNull最高とか言ってるやつらに構っても意味ないな
一生C/C++とかJava、PHP、VB触ってろよ無能
違う。C/C++では、
long int a = 1;
とも書けるが、typedefやusingなどを使えば、
i64 a = 1;
と非常に古くから書ける。
型推論できるのは冗長性があるからで
冗長性にもいい面悪い面がある
悪い面は変更に弱くなる
あっちかえたらこっちもってね
rustはそのへんバランスとろうとしている
効果はさておき
そのへんまで考察しないと浅いよ
普段C++触るけど同じ型指定なのに二通りの書き方あるのはC++の悪いところだと思う
Cの資産引き継ごうとしててC++特有のカオスによりしてる
intと同じ振る舞いをするがintと区別されるclass、みたいなやつは必要に駆られてたまに作る
C++はそれと統一性をもたせざるを得なかったから現状がある
良しか悪しきかは知らん
どんだけ効率的に書けて実行出来るか焦点はforeach と食わすリストよ
動的なリストでも分岐無くすとかキャッシュ乗り鬼効率な凄いのをくれ
それはもうウンコやん
（そもそもなんだよ $ -> => って...）
パッケージ管理もゴミ
ログ出力の見やすさもデバッグのしやすさもゴミ
バージョン乱立
フレームワーク乱立
土台の言語仕様自体がゴミなの棚に上げて
コーディング規約の強要
やることなすこと全部他言語の猿真似
動的片付けの癖にプリミティブ型がメソッドや属性すら
持ってない
JavaやRailsやJavaScriptはいい加減糞PHPを
著作権侵害で訴えろや
消えうせろ、潰れちまえパクリウンコゴミ溜め言語が
で？君はPHPで書かれたプロダクトより良いプロダクトを持っておりゅかね？？
次世代の日本を担う素晴らしい言語
Railsは、流行りのWebサイトでほとんど使われてる。
Qiitaも、Rails
最近流行ってた、質問箱も、Rails
雇われから脱出し、マックザッカバーグを目指すならRails一択！！！！！！！
もしかしたらm4がphp並みに嫌われる世界もあったかもしれないと思う
言語の適用範囲を高めるためには、抽象度の高い概念を基本とした方が良い。できるなら数学的に議論可能なレベルで
Facebookに倣ってPHPにするは！
HackやらReactやら
そもそもフロント技術だし、しかもフレームワークだし、ベースがJSだからPHPと全然違う
PHPは糞言語なのは間違いないけど論点違うだろ
関数型、immutableってJSがESで取り込んでいった方針だから
安定のrubyガイジ妄想クオリティ。
というか、見たことない。
Laravel使いは、誰も使わないサービスを量産してお金を稼ぐ負の存在。。。！？
技術だけじゃなく、ビジネスで勝負したいならRails一択！！！！！
レールは続く】 Ruby on Rails Part21 【これからも
https://medaka.5ch.net/test/read.cgi/php/1545146635/103
世界を驚かせた、表示速度が異常なサイトも、Rails 製だった！
https://dev.to/
Wasmはマシン語に相当するものなので、Wasm自体には使用言語に関する混合に関して何の制限も無い。
ただし、nativeアプリの場合と同じで、C言語の関数を通じてお互いに呼び出しあうなどは必要。
なお、今のところ、最低限マシン語とC言語の仕組みに関して知識がないと難しい。
（最低、アドレスやポインタについての理解がいる。）
例えば、LLVMをバックエンドに持つコンパイラであって、LLVMの中の
%struct.XXXX のアラインメントのとり方が同じであって、かつ、
export、importする関数がC言語のインターフェースを持っているならば、
Wasm用のリンカでリンクが可能。
この条件を満たさない場合、リンクするのは難しいが、以下のようにすれば、
実行段階でお互いに関数を呼び出しあうことが出来る。
・それぞれの言語処理系でリンクを行って、*.wasm ファイルを作る。
これらは、「Module」と呼ばれる。
・ModuleをWasmとして機能させるには、JSでInstace化を行う。
・この際に、それぞれの関数名を import すれば、お互いに関数を呼び出しあうことが可能。
・この場合、文字列や配列の様なものにアクセスし合いたい場合、ポインタ値がJSレベルでは
単なる整数値になるので、それを、Memory と呼ばれる線形メモリーの ArrayBufferの
アドレス値とすることで、可能。
PureScript
人によって違うのか
何個言語あってプログラマ何人おると思ってるねん
Make
構文がわからないから疑似コードで書くけど、
typedef X; // Xという新しい型を定義
function makeX<T> (t T): X { /* ... */ }
// makeXで作られた値以外を渡したらいつもコンパイルエラー
function soSomethingWithX( x: X ) :void { /* ... */ }
こういうことがしたいんだけど…
type Nekko = {
name: string
age: number
}
type Inu = {
name: string
age: number
}
これらは同じ扱いになる
っていう話？
それとも makeX 以外で X を作れなくしたいという話？
別に X を満たせば、 makeX 以外が X 作ってもよくない？
makeX が作った X と、makeX 以外が作った X が別物なのであれば、
それらは別の型だろう
erlang かな
むしろ全て機能を並列処理で書くしか無い割り切りというか
スクリプト言語ではないが、GPGPU 用のC言語に似た言語は、そもそも
最初から並列処理を前提にしている。
プロパティが一致しなければ別の型になるので、
piotrwitek/utility-types の nominal type 使うなどして、自分で識別子を与えればできる
JavaScriptというカオスな言語・膨大な資産を利用するには、仕方ない面もある
ライブラリを使え。
と同じ感じで Erlang → Elixir がある
やっぱりPureScriptでAffがナンバーワン！
局所的な高速化だったらライブラリ使えになっちゃうし
JSは自前でWorker使った並列処理書かないと
並列化はされてないんじゃないの？
いい感じではあるけどいい感じから更に上回って採用するほどではないという
アプリもCで書くのが一番自然になる
cである必然性はない
って思考から脱却しろ
あほらし
構造体とか配列のポインタとか面倒だな・・・
問題は処理系依存マシマシのC++ベースAPI/ABI
C#のFFIはかなり良い方だろ
C側でラッパーを一切書くことなくC#から呼び出せる
何より、トラブルの元になりがちな変なコードジェネレータの類がなくて、宣言した通りに正しく素直に動くってのが素晴らしい
そのストレスフリーさに比べたら、C#側で関数や構造体の宣言を書き直さなきゃいけないのは余裕で受け入れられる冗長性だと思う
だけなのに、なんかコンプレックス刺激されちゃう奴がいるのな。
C がわかる、てだけでドヤるのも大概だけれども
それよりももっと性質が悪いのは C がわからないコンプをこじらせているやつ
何このモヤモヤ感
https://qiita.com/hmuronaka/items/619f8889e36c7b5db92d
https://www.youtube.com/watch?v=WiPoQWJfFt0&;t=900s
全部話します。YouTuberヒカルが生まれるまでの話しと今の本音
https://www.youtube.com/watch?v=97FsyM7G1jw
高校生の自分に教えたいこと
https://www.youtube.com/watch?v=y0SY32zOExc
嫌われながら好きなことで、生きていく「起業家-ヒカル」
https://www.youtube.com/watch?v=OcsN5iD7C-s
【本音対談】これからYouTubeをはじめるあなたへ【DJ社長×ヒカル】
https://www.youtube.com/watch?v=IDL3dLxyPuk
【好きなことで、生きていく】『レペゼン地球-DJ社長-』
https://www.youtube.com/watch?v=PPnbEiXSYM8
グロ
と言われたくない人達
つか、今時スレが言語スレだが言語だけで語る滑稽さ
次世代言語というより、標準ライブラリも含めた次世代環境がほしい
適当なインストーラーとライブラリ管理はあるし。
ビルド通らねー糞が！とかもだいぶ減った。
本気だして調べる気力もなく、関連ファイル削除して男友達と焼肉食いに行った。
わざわざ男友達と書いたのは、女友達なんかいないからだ。
わざわざどうでもいいつまらないことを書き込むところが女友達のいない原因だろう
1行目からイミフ
rust自身のビルドが、Pythonに依存しているって話じゃない？
Makefileより読みやすく
Python自身のビルドはLLVMのビルドより10倍か100倍速い
どんな型が来ても受け入れるおおらかさがある
ネストした構造をループ処理するときなんかは確かに楽なことも多い。
弱い動的型付けと同一視するのは誤りの元だし、漸進的型付けの存在を無視するのもまた評価を誤りかねないですよ
そろそろ後付け静的型の代表的成功例であるTypeScriptと何が違ったのかを真剣に議論すべき時期にきてる
C#は多いけど標準かって言われるとな・・・
C/C++も「標準」に拘ると何もできないω
func add_god(a,b){
return a + b
}
add_god(1,2)
add_god("a","b")
add_god(1,"a")
神関数、があれば、コードの削減が可能！！！！！！！！！
ノーコード時代には動的型付け言語一択！！！！！！！！
死ねとまでは言わないが生まれてこなければよかったのに
https://myuon.github.io/posts/type-system-poem/
静的解析すれば全てのバグを取り除けるというのは間違い
そもそもそんな主張誰もしていない
とかあれだけ動的型付け素晴らしいからの静的型付け面倒臭いとかディスッといてこの状況は大草原ですわ
まぁ何事もトレードオフだからケースバイケースで使い分ければいいんだが
今頃ブレイクスルーだなんだと大騒ぎなのは滑稽ですな
js界隈も結局サーバサイドレンダリングに回帰してるしファッションや音楽と同じで10〜20年スパンでサイクルすんのかね
型があっても言語としての使い方がクソならクソだし、静的解析のないLLだからってランタイムにきちんと型エラー吐いてくれるものが比較的マシという評価になるのは間違いないでしょ
デジタルな分野扱ってるからって判断までI/Oにするもんじゃない
君は >>921 の関数に、整数、小数、文字列、オブジェクト、真偽値、日付型・・・
たくさんの引数を与えて
一生懸命テストを書くのだろうな
それは素晴らしいことだと思うよ
感動で涙がで、でますよ
おやおや・・・君もテストコード書く技量がないだけ？？
この引数は整数でございます。小数、文字列、オブジェクト、真偽値、日付型・・・は教育によろしくないので与えないでいただけますと幸い至極でございます。
とでも一生懸命書くのかな？？
それでIDEの静的解析に警告を受けたら
「やっぱり型無し糞言語でも安全！！型はいらない！！！」
とか言うのかな
あれっｗ
言語名が不明な「静的型」は現実みが浅い
やっぱりクソ
現実みが浅い、って日本語として気持ち悪い
JavaScriptやpyなんか連想配列や辞書
定義するのもコンソール出力もめっちゃ便利やぞ
コンパイルエラーの手間もないしめっちゃデバッグが楽
それな
全員がそうだとは言わないけどテスト設計できないやつが大半
func god(args...){}
これだけで基幹システム作ったわ
1年掛かる工数を3日に短縮できる動的言語ってやっぱ神だわ
うーんこの神
みずほ案件も型無し糞言語を使っていれば3人日で完成していた
メソッドの実装探すのに苦労する。
public static void main(String[] args) {
System.out.println("hello, world");
}
}
やっぱJavaだわ
記述量が多いから努力した気になれるし成長した気にもなれる
静的型付けだから動的野郎にもマウント取れるし
昔ながらの大企業でよく使われてるから日本の伝統も感じられるし
今後50年は食いっぱぐれないし
Oracleに転職できるかもしれない
これが無くなったら英語自体がオワコン
動的派の書くテストは正常系を一発通すだけのものが多くて、あれでテストちゃんと書いてますと言われても首を傾げてしまう
動的型のコードがデグレで動かなくなるのは日常茶飯事であるし、そもそも最初から全く動かないウンコであることも珍しくない
だから最低でも変更の度に自動テストで一度動しておけば品質は大幅に上がるのだが、とはいえ血便が下痢便になる程度
一方、静的型はプログラマの品質に対する意識の高さや静的型検査の恩恵のため、動かすだけのテストにはあまり意味がない
起こりうる様々なケースを試したり挙動の変更を厳密に監視したりと、静的型においては自動テストに求められる基準は遥かに高くなる
整数、少数..本来は全部やるべきだな
エラーの原因の大半は人間のちょっとしたミスだからな
>>934は勝手に都合のいい解釈でそういうテスト省こうとしてるだけやんw
動的だと一週間で終わるものを三ヶ月ぐらい掛けて実装してそう
なるほど、まさしく>>934は「異常系」のテストは、極論と自己都合解釈して省こうとしてるのですね
型無し糞言語脳って、型チェックがあればそもそも発生しないバグのチェックに何日費やしてるんだろうな
静的型だと0秒で終わるバグを三ヶ月ぐらい掛けて修正してそう
型おじさん「……型は？」
ワイ「え？」
型おじさん「簡単なスクリプトだからって舐めてない？引数とかに色んな型が入ること想定してる？」
ワイ「いや……」
型おじさん「あのさぁ！！！！！型が無いと万が一のこともあるよねぇ！？！？！？エラーが起きてサーバぶっ壊れるかもしれないだろ！？！？」
ワイ「サーバが壊れる！？どうしたんですか」
型おじさん「ああああああああ！！！！！！！！」
次の日にそのおじさん退職したわ
前の職場でも型型騒いで辞めたらしい
お前らも気をつけろよ
そんな低レベルな職場に一生居たくないと思ったんだろう。
かわいそうに。
ネット初心者かよ
最近多いんだよねー
Pythonとかちょっとかじった程度で
「俺プログラマーやってます」って顔する子
最初の入り口が動的型付け言語なんだよね最近の子って
そんなもんじゃ使いものにならねっての
Juliaなんかはパフォーマンス向上目的での型の導入だけど、型安定とかわざわざドキュメントに記すなら言語側でそもそも制約を強めてエラーにしてしまうとかでよかったんじゃないかと思ってしまう
なので、そういう言語しか知らない人が「静的型付けは煩わしい」と思うのは仕方ないことかもしれん、と思う
一度はOCamlを使って欲しい
OCamlは正格評価だし、型は強力で作りやすくて使いやすいし、OOPとも丁度いい距離を取ってる
smalltalkほど死んじゃいないし、Haskellほどアカデミックじゃない
次世代言語じゃない！と言うなら、ReasonMLでも良い。OCaml -> Javascriptみたいな環境もある
正常系を一発通すだけで十分なのかどうかは仕様次第
ただオープンソースではよくあるのは開発者がテスト軽視してるだけで
動的言語か静的言語か関係ない
>>950
>>921の関数に対してどういうテストをすべきかは仕様次第
仕様は不明だけど考えうる限り網羅的にテストすべきって考え方自体が
テスト設計したことない人の考え方だよ
機械学習のように入力情報は保証されているという状況では
当然テストの質が異なる
議論がすれ違っているのはその辺の違いかと
それこそ論点ずれてる
唐突に岡村提案されてて草
データの内容によって命令を使い分ければ良いのだ。
↑
機械語で十分って事では？
確かに。
ポインタも整数も同じ整数レジスタで行うね、マシン語だと。
整数演算で可能な型ならビット数以外の型情報が無い。
それで、マシン語だと間違った演算でもコンパイル時にエラーがでにくかったが
C言語で細かな型が導入されて間違いをコンパイラが発見することに成功した。
ところが最近のスクリプト言語では明確な型宣言がないものが流行り出し、
かつての問題点がまた出てくるようになってしまった。
型書けない言語はもうありえんわ
一時期PHP使ってたことあるけど、正気の沙汰じゃなかった
当時はアセンブルと言っていたが、若い人にはコンパイルといったほうが通じ易いらしいので。
岡村さん何してはるんですか
コンパイル言語を知っている人向けにアセンブルを説明するのに「コンパイルみたいなもの」と説明するのではなく？
ちゃんとした型推論と簡潔な型表記があれば静的型付けでも書くのは面倒じゃないって分かったり
クラスってプログラムの必須構成要素なんかじゃないって気づけたり(むしろ用途は凄く限定されるべきもの)
遅延評価って実際にどんだけ便利なの、とか、分かる
配置が決定しないと使えない機械語が有るので。
大方自分の意図をメソッドのボディによって表現することしか知らないのだろう
HaskellやらOCamlやらある程度の型システムの強度を持っている言語の経験があるプログラマは、
自分の意図の大部分を型で表現することに慣れているから、型がいらないとか正気か？となる
型がないとプログラムを正しく組むことが事実上不可能だからだよ
関数型では型は主にプログラムの形式的な正しさを守るためのテクニカルなツールとして用いられていて、
むしろドメインモデルを型で記述するみたいなのは意外にも関数型では重視されなかったりする
素直に型を使いましょう。
言ってることが何一つ理解できないんだが
ほんとに関数型言語の経験か、型システムを専門に研究した経験のどっちかでもある？
標準ライブラリなんとかして
haskell と比較した ocaml の利点をぜひ！
このメソッドは何をするかがはっきりしていれば、そんなに型を気にする
必要はないと思うけどなあ。一つのクラスでたくさんのことをさせているのか?
Haskellのマクロとか使いにくいったら無いし、あんなので試行錯誤したくない
RailsもRubyで産まれて、静的型言語に不完全な形でパクられた
だから、ゼロからフレームワークを作る創造的な人達は動的型を好み、
アイデアをパクって実装したり、フレームワーク使うだけのドカタは静的型を好むわけだよ
創造性のないドカタっぽいレスですね
知能低そうw
メタプログラミング自体を行う奴らは試行錯誤とかあんましないﾚｳﾞｪﾙなんじゃね
書いたら動いてバグがほとんど無い（
もちろんテストはする
どこかに釣りの痕跡残しておかないと、後で釣りでしたと言っても信じてもらえなくなる。
新しいスレッドを立ててください。
life time: 187日 10時間 3分 41秒
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- トライク(三輪自動車)が大型貨物に追突、男性死亡 男児意識不明 ヘルメットなし [蚤の市★]
- 【高校野球】今夏の甲子園で2部制導入 ネット歓迎「当然の流れ」 抜本的対策求める声も「京セラ併用考えないと」「全試合ナイターに」 [冬月記者★]
- 慶應義塾長が国立大の学費増額を提言「年55万→150万に」 文科省の会合で [少考さん★]
- 【MLB】打撃不振…？ 大谷翔平、打ってるのに何故か叩かれる 軽く打って170キロ超え高速ヒットがヤバすぎると話題に 「アンチ涙目w」 [冬月記者★]
- 埼玉の在日クルド人に差別や攻撃 県外からも電話「SNSで見た」 [少考さん★]
- 「実質負担なし」だけに国会論戦が集中する「子育て支援金」 この事態は誰が招いたか 関連法案が衆院通過 [蚤の市★]
- AFC U23アジアカップ カタール2024★8
- AFC U23アジアカップ カタール2024★9
- AFC U23アジアカップ カタール2024★10
- 【酒】日本vsUAE【U23アジアカップ】
- とらせん
- とらせん祝勝会 ★2
- ナルト「主人公が六道仙人の息子の転生者です」←許される 呪術廻戦「主人公が宿儺の双子の弟の転生者の息子です」←叩かれる
- ToLOVEるのヤミちゃんってなんで校長に寝取られてんの？
- 運転中にVIPで以外にやることってなんかある？
- 今何時？？？？？？？？？？？？？？？？？？？
- 一平「WBC期間中にトラウトにサインボール大量に頼んだろw」←改めて考えるとクソ迷惑やろこれ
- 女子小学生ちゃんの登校時間きたあああああああ？？？？？？？？