C vs C++ vs Rust Part.3

**デフォルトの名無しさん** · 2022/01/27(木) 22:19:47.56

闘え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/
C vs C++ vs Rust Part.2
https://mevius.5ch.net/test/read.cgi/tech/1639539350/

**デフォルトの名無しさん** · 2022/02/24(木) 13:49:34.79

このへんのタイトルがでそろえば学習コストが下がるｗ間違いないｗ

・やさしい Rust
・13歳からはじめるゼロからのRustゲームプログラミング教室入門編
・Rustの絵本

**デフォルトの名無しさん** · 2022/02/24(木) 14:08:22.05

C++のtemplateの学習コストはとても高い
使うだけなら簡単・便利だけど、作るとなるとエラーに悶絶すること請け合い
C++の場合は、理解が完全かつ処理系の気持ちを察せられないと分からないエラーだからな

**デフォルトの名無しさん** · 2022/02/24(木) 14:30:43.20

vector<int&>とかすると標準ライブラリ内からエラーが出る
MSVCのエラーメッセージ見ると標準ライブラリが悪いかのようなエラー吐くからなぁ

これはわかりやすいからまだいいが自作したtemplateでエラーが出たらライブラリが悪いのか使う側が悪いかが分からんくなる...

C++20のconceptでマシにはなったが...なったのだが...

**デフォルトの名無しさん** · 2022/02/24(木) 14:37:14.35

>>373
Rustはそういうのがないからいいよね
これが型クラスの恩恵か

**デフォルトの名無しさん** · 2022/02/24(木) 14:37:16.61

>>367
これかな
https://tourofrust.com/

**デフォルトの名無しさん** · 2022/02/24(木) 14:44:41.24

>>375
もちろんgoやrustのそれを想定して書いてるよ
ただ、より正確なリファレンスへのリンクと演習問題がない
内容もやや不足かな

**デフォルトの名無しさん** · 2022/02/24(木) 15:49:13.99

マシーンと会話できてこそ一流よ

**デフォルトの名無しさん** · 2022/02/24(木) 15:52:51.86

$ こんにちは！
こんにちは！: コマンドが見つかりません
$

**デフォルトの名無しさん** · 2022/02/24(木) 18:01:51.83

>>376
それならこっちの方がイメージ近いかな
https://exercism.org/

言語の説明はかなり控えめで演習中心だけど

**デフォルトの名無しさん** · 2022/02/24(木) 19:03:29.20

演習があるのはいいんだが微妙。。。元々知ってたらconceptはいいかもしれないけど、やはりシナリオは欲しい
説明すべき基礎事項をその学習資料の中だけで全て完結させた上で、サンプル付きのシナリオで読ませる形
ようは順番に読んでいけば一貫して不明点がほぼない状態で読ませられる資料になってないといけない

**デフォルトの名無しさん** · 2022/02/26(土) 08:25:19.78

>>380
暗いと不平を言うよりも、すすんであかりをつけましょう。

**デフォルトの名無しさん** · 2022/02/26(土) 09:06:47.66

>>381
現状に不平や不満があるのではなく、動画よりいいと個人的に思う形態を示し、それならと提案を頂いたのでその感想を書いただけ

**デフォルトの名無しさん** · 2022/03/01(火) 12:38:09.08

ゼロコスト抽象化のないらしいC++が
Rustと同等以上に速いのは何故でしょうか？

**デフォルトの名無しさん** · 2022/03/01(火) 12:51:08.94

それはRustのゼロコスト抽象化が嘘だからです

**デフォルトの名無しさん** · 2022/03/01(火) 13:02:32.51

https://blog.rust-lang.org/2015/05/11/traits.html
"...
Abstraction without overhead
One of the mantras of C++, one of the qualities that make it a good fit for systems programming, is its principle of zero-cost abstraction:

C++ implementations obey the zero-overhead principle: What you don't use, you don't pay for [Stroustrup, 1994]. And further: What you do use, you couldn't hand code any better.

-- Stroustrup
This mantra did not always apply to Rust, which for example used to have mandatory garbage collection. But over time Rust's ambitions have gotten ever lower-level, and zero-cost abstraction is now a core principle.
..."

**デフォルトの名無しさん** · 2022/03/01(火) 15:08:52.35

普通にあったんですね
失礼しました！

**デフォルトの名無しさん** · 2022/03/01(火) 23:34:34.12

Rustはasyncもゼロコスト抽象化に成功したことが大きいかな
C++ではごちゃごちゃする上に安全に書くのが難しい
他の言語ではゼロコストじゃない

**デフォルトの名無しさん** · 2022/03/02(水) 00:22:04.69

オメェがへたくそなコード書くからだろド素人

**デフォルトの名無しさん** · 2022/03/02(水) 07:53:10.69

ゼロコスト抽象化ってなにがゼロコストなのかぶっちゃけよくわからん

**デフォルトの名無しさん** · 2022/03/02(水) 08:03:27.50

>>389
定義もないバズワードだからな。

**デフォルトの名無しさん** · 2022/03/02(水) 08:50:05.84

抽象化ってのはpolymorphic class のことだと思ってたが全然違うやんけ

**デフォルトの名無しさん** · 2022/03/02(水) 11:01:52.98

https://boats.gitlab.io/blog/post/zero-cost-abstractions/

**デフォルトの名無しさん** · 2022/03/02(水) 15:14:26.14

>>391
全然ちゃうわ

**デフォルトの名無しさん** · 2022/03/03(木) 22:15:19.30

>>389
少なくとも同じことやるならCと同じコードを吐くという意味だよ

**デフォルトの名無しさん** · 2022/03/04(金) 01:42:23.15

>>394
その定義だとsliceのインデックスアクセスがゼロコストでなくなるが良いのか？

**デフォルトの名無しさん** · 2022/03/04(金) 05:13:25.76

>>395
スライスをCで実装したら速度的には同じコードを生成するってことだよ？
余計なランタイムのせいで遅くなることはないってこと

**デフォルトの名無しさん** · 2022/03/06(日) 12:55:30.33

トーバルズ氏、Linuxカーネルを「C89」から「C11」コードに移行する準備
https://japan.zdnet.com/article/35184296/

Rust信者の発言「こんなにも優れてる！おまえらの弄ってる言語はウンコ！CもRustに置き換わる！（=だから他スレ嵐ても良い）」
Rustメンテナ発言「すべて了解しました。Linus氏の言う通りに変更します、このようにしたいと思うのですがよろしいですか？ダメ？」

**デフォルトの名無しさん** · 2022/03/06(日) 13:01:03.89

>>397
https://mevius.5ch.net/test/read.cgi/tech/1638086359/542

**デフォルトの名無しさん** · 2022/03/06(日) 13:03:29.20

あとその記事は誰もRustがどうのとは言ってない

**デフォルトの名無しさん** · 2022/03/06(日) 19:59:13.15

C++に勝てると思ってた？
残念だったな

**デフォルトの名無しさん** · 2022/03/06(日) 22:50:40.67

C/C++やJavaなどからRustへ移行するパターンも多いけど
こういう形でJavaScriptからRustへ移行する例も増えてきた

https://publickey1.jp/blog/22/amazon_prime_videowebassemblywasm_vm.html
Amazonはプロトタイプとして低レイヤのJavaScriptのコンポーネントのいくつかをRustのコードで書いてコンパイルし、WebAssemblyのバイナリにしたところ、JavaScriptのコードと比較して10倍から25倍も高速になったことを発見します。

これによりAmazon Prime VideoのアプリケーションにWebAssemblyを取り入れることを決定。

JavaScript VMの部分にWebAssembly VM（Wasm VM）をランタイムとして追加し、ユーザーのデバイス上へデプロイした上で、これまでJavaScriptで実現していたレンダラ、アニメーション、シーンとリソース管理の部分をRustコードから生成したWebAssemblyで置き換えました。

**デフォルトの名無しさん** · 2022/03/07(月) 00:42:06.45

>>401
https://mevius.5ch.net/test/read.cgi/tech/1638086359/578-579

**デフォルトの名無しさん** · 2022/03/11(金) 01:25:14.31

wasmにすれば多少の違いがあるにしても他の言語もほぼ同じ速度だと思うが？それ以前によほど速度がクリティカルじゃないと
JS/TS書いてる人がRustなんて使おうと思わない、キモさ満点

**デフォルトの名無しさん** · 2022/03/11(金) 01:48:50.91

>>403
GC言語でWasmを記述するメリットはゼロ
だからWasm記述言語のシェアはRustが圧倒的に強くて次がC++
Rustの方が強いのは書きやすいため

あとプログラミングの生産性の高さならばJS/TSよりRustが完全に上
そもそもなぜJSに対してTSが登場したのかと理由の根源は同じ
強力な静的型付け言語であるほどプログラムは書きやすく生産性が高い

**デフォルトの名無しさん** · 2022/03/11(金) 02:26:33.61

rustが生産性高いなら、もうとっくに10年経過してる言語だから
今の10倍はユーザー居ないとおかしいよ。

**デフォルトの名無しさん** · 2022/03/11(金) 03:39:10.52

JSより上はわかるけど、TSより上はなんでなん

**デフォルトの名無しさん** · 2022/03/11(金) 04:15:58.39

>>405
え？
Rust1.0は2015年
Rustの価値を上げたasync導入の2019年からまだ2年半弱

>>406
TypeScrpt使えばわかる
中途半端に型導入したJavaScriptにすぎない

**デフォルトの名無しさん** · 2022/03/11(金) 06:24:04.29

wasmは基本的に外部世界とのやり取りをJS側に依存してるからな
言語仕様が大きい言語は入りにくいし、入れても使いにくくなる
Rustをwasmにしても小さくとも数10MBくらいにはなる気がする
ただJavaScriptより速いというのはケース・バイ・ケースっぽい

**デフォルトの名無しさん** · 2022/03/11(金) 08:49:12.64

1.0からでいいなら2009年頃のC#の使用者数や
取り巻く開発環境と互角くらいになってないと変やぞ。

**デフォルトの名無しさん** · 2022/03/11(金) 09:19:45.43

生産性と言語の難易度は独立だからなぁ
JSは生産性低いと思うけど、昔ならプログラマ適正ないとされていた人でもなんとか書けて、人海戦術で生産性を確保しているように見える
結局C++やRustでコード書ける人は限られるし、生産性が高いから普及するなんてことはないと思う

**デフォルトの名無しさん** · 2022/03/11(金) 11:07:32.97

C++でDOM操作出来ればどんなに楽な事か

**デフォルトの名無しさん** · 2022/03/11(金) 12:33:26.46

なんで出来ないの？？？

**デフォルトの名無しさん** · 2022/03/11(金) 12:46:45.10

実行時にclass fieldの名前の情報がないから

**デフォルトの名無しさん** · 2022/03/11(金) 13:04:09.65

それはreflectionであって、DocumentObjectModelではないよ
どの言語でもそれをDOMとは呼ばない
reflectionは登録する系か、静的に解析する系かならサードパーティ製ライブラリはなくもない
C++標準ライブラリ仕様的にはそのうち入るかもって感じで検討されてる
そして別にサードパーティ製ライブラリの使用はそんな面倒ではない
信用するかしないかは別だし、登録する系を自分で使うだけなら自分で実装しても出来るレベルだと思う
何に困るのか理解できない

**デフォルトの名無しさん** · 2022/03/12(土) 11:24:43.30

ほとんど通信のコストでCPUバウンドなjavascriptなんてそんなあるわけねーだろ。。
頭おかしいんじゃねーの。

**デフォルトの名無しさん** · 2022/03/12(土) 12:13:10.35

マルチメディアな処理とかをクライアント側でするんだよ
例えばお絵かきとか、例えばゲームとか
業務系ではあまりない(会議システムとかはある)けど、それは単に領域が違うだけの話

**デフォルトの名無しさん** · 2022/03/12(土) 13:08:34.10

>>404
pythonはインタプリタ言語で型がないからプログラムは書きやすく生産性高い

>>416
そのとおりだな

**デフォルトの名無しさん** · 2022/03/12(土) 13:38:38.36

生産性は単純に言語の制限の多さやそれに対する慣れみたいなのが効いてくるけど、その辺は利用者のスキルによる
一番効いてくるのはライブラリやフレームや開発環境などエコシステムの成熟具合
pythonはそういう意味だと生産性は高い方だと思う
規模が大きくなったときの品質は低くなるので、そこまで含めて生産性というと落ちるくらい
現状だとある程度以上の規模のプロジェクトでのパフォーマンス・安全性・品質・環境・習熟しやすさなど総合的な生産性なら、Java, C#あたりにやはり軍配が上がると思う
個人的には今のChromeのJavaScriptパフォーマンスがnode.jsでも出るなら、TypeScriptとかはいい線行ってると思うし、エコシステムが成熟すればgoもいいと思う

**デフォルトの名無しさん** · 2022/03/12(土) 13:52:15.48

>>417
WasmでPythonを動かそうとするやつはネタかキチガイだけだぞ
あとPythonはまともな型がないから生産性が非常に低い

**デフォルトの名無しさん** · 2022/03/12(土) 13:56:48.53

>>418
それは既存のものの利用組み合わせの話であって
プログラミング自体の生産性が高いわけではない
そこを区別できないのはヤバいぜ

**デフォルトの名無しさん** · 2022/03/12(土) 14:03:06.54

web上でpython動かす！とかdebian動かす！とかそういうプロジェクトは結構あるよね
動いて満足して終わりな速度だけどｗ
python昔調べたときはできないことも結構あるとか書いてあった気がする
debianはまあデバイスがほとんどなかったので…ｗ
g++とかは遅いけど普通に動いて感動できるよ

>>420
元来生産性というのはそういうものｗ
決められた要件に到達しうる時間でしか比較できないｗ

**デフォルトの名無しさん** · 2022/03/12(土) 14:10:30.48

>>421
それはよほど小さなコードしか書いたことがないからだろ
Pythonでちょっとでも複雑なコードを書くことになったら生産性の低さに愕然とするだろう
少なくとも静的な型付けが必須であることは全員が一致する常識となっており
だからこそ例えばJavaScriptにわざわざ静的な型付けをしたTypeScriptが使われる

**デフォルトの名無しさん** · 2022/03/12(土) 14:27:42.28

>>422
規模については>>418で言及してるがｗ
そしてそれは厳密には生産性が落ちるというより品質が落ちるだけｗ
結果的にある程度以上の品質を確保するまでの時間が長くなる
仮に一回こっきり雑な前提で動かしたいソフトで異常系不要、品質は本当に特定のケースだけ動けばいいという条件での生産性なら落ちないｗ
ある程度以上の規模である程度以上の品質が必要なら型がないとねという話は語るまでもない

> Pythonでちょっとでも複雑なコードを書くことになったら生産性の低さに愕然とするだろう
生産性が低いと思ったこともないし、愕然としたこともないけどな
でも誰しも(アノテーションじゃない)型が欲しいと思うだろうねｗ

**デフォルトの名無しさん** · 2022/03/12(土) 14:36:15.58

単純に動けばいい程度のコードしか書いたことがないのか
引数/返り値型も1人で把握しきれる程度のコード量しか書いたことないんだろうな

**デフォルトの名無しさん** · 2022/03/12(土) 14:37:51.91

>>423
ではその品質が低いプログラムを作っていればよい
こちらでは保守性が低い言語は使わない

**デフォルトの名無しさん** · 2022/03/12(土) 14:40:55.70

スクリプト言語でデカイのは俺だって書かないよｗ
書けと言われない限りねｗ

**デフォルトの名無しさん** · 2022/03/12(土) 19:02:59.33

あとpythonも今はアノテーションがあるし、ない時代もドキュメントコメントがちゃんとあったから
仕事で使うならそういうの全部書いてたし、開発環境もちゃんと対応してた
できないのはアノテーション同様強制だけで、問題はやや冗長になることｗ

**デフォルトの名無しさん** · 2022/03/13(日) 01:09:57.73

生産性はバッテリー初め標準ライブラリの大きさ、
デファクトスタンダードの浸透、
開発環境の強力さ、
クラウドやサーバー側の専用対応度合い
で決まる。

**デフォルトの名無しさん** · 2022/03/13(日) 10:16:49.90

一部の人に誤解されてそうだけれど、
Pythonは動的型付けではあるけれど、
型付けも強い方だよ。

**デフォルトの名無しさん** · 2022/03/13(日) 14:24:56.50

それは分類上の話であって、話の中ではそう書いた方が誤解されるからああ書いた(型が欲しい)だけ

**デフォルトの名無しさん** · 2022/03/13(日) 17:06:04.04

C#、pythonなどはまともに言語仕様を理解してない・しようともしないヤツでも書けるが、rustは知らなければ書けない。
必然的に少なくとも言語仕様を理解しようとする比較的生産性の高い人員が利用することになるので、生産性は高くなる。

**デフォルトの名無しさん** · 2022/03/13(日) 17:49:35.20

残念ながらC++やRustの生産性がC#やpythonほど高くなることはないよｗ

**デフォルトの名無しさん** · 2022/03/13(日) 18:12:40.03

「必然的に少なくとも言語仕様を理解しようとする比較的生産性の高い人員が利用する」
ほんまか？Haskellを理解している生産性高い人員が利用、C++を完全理解してる生産性の、、うっ頭が、、、

**デフォルトの名無しさん** · 2022/03/13(日) 18:28:30.10

>>432
C#とRustは各々一長一短あるがほぼ同じ
C++はメモリ管理が自動化されていないので辛いのはわかる
Pythonは動的型付けで辛くて論外

**デフォルトの名無しさん** · 2022/03/13(日) 18:48:27.86

C#とRustは全く違うｗ
C# ... python/JavaScript/Javaなど比較的容易に習得できる言語を知ってればまずすぐに使えるようになるし、最初の言語としてもOK
Rust ... C→C++→挫折→Rustが無難。最初の言語は絶対ムリｗ
全て習得してれば何を使っても困ることはないが、エコシステムの充実度で生産性が飛躍的に上がるので、Rustの生産性がC#より上がることは絶対ないｗ

**デフォルトの名無しさん** · 2022/03/13(日) 18:52:44.10

どう考えてもC#の方がRustよりも生産性高い
どんだけゲーム開発で使われているかを見ればわかる

**デフォルトの名無しさん** · 2022/03/13(日) 18:57:46.57

>>436
それはRustが15年遅れて登場したためです
生産性ならば明らかにRustの方が高いです

**デフォルトの名無しさん** · 2022/03/13(日) 18:58:32.94

GCがある言語はそれだけでだいぶRustよりサボれるよね
どちらが良いかどうかはもちろんケースバイケース

**デフォルトの名無しさん** · 2022/03/13(日) 19:01:42.87

明らかに弱酸性が高いです！

**デフォルトの名無しさん** · 2022/03/13(日) 22:08:33.05

Rustは早く言えば2006年、遅くとも2010年には登場してることになるのでもう余裕で10年選手だけどね
インターネットが普及してる現代なら、Googleすらない頃に普及したJavaやC#と比べれば、人気出るのにかかる年月は圧倒的に短いはず
10年で発達したエコシステムが現状だとすると、その程度にしか人気がない残念な状態ということ

**デフォルトの名無しさん** · 2022/03/13(日) 22:15:49.75

>>440
Rust 1.0が公開されたのは2015年

**デフォルトの名無しさん** · 2022/03/13(日) 22:25:52.97

Javaなんて登場から1.0出るまでに半年だぞｗその程度の人気ってだけｗ

**デフォルトの名無しさん** · 2022/03/13(日) 23:18:30.60

>>440
C#出た時にはグーグルはとっくに検索エンジンのデファクトスタンダードだった

**デフォルトの名無しさん** · 2022/03/13(日) 23:45:46.84

2000年当時はまだ知る人ぞ知るだぞ
インターネット検索つらー！って言ってる時期

**デフォルトの名無しさん** · 2022/03/14(月) 00:05:53.25

2001年のYahoo JAPANのエンジンがGoogleを採用っていうニュースを見たときはすでにGoogleの性能が明らかに圧倒してたから納得だったな
2000年頃はどうだったかなあ、でかいニュースとかがないと何も思い出せない

**デフォルトの名無しさん** · 2022/03/14(月) 00:20:38.18

お前最初グーグルすらない頃にとか書いてたけど指摘されるとしれっと知る人ぞ知るって変更かよ
どこぞの半島人みたいだなw
因みにC#1.0リリース時は既にアメリカでは検索サイトで1、２位を争う位だったしヤフーも検索エンジンはグーグル仕様してたくらいメジャーだった

**デフォルトの名無しさん** · 2022/03/14(月) 00:21:16.70

ヤフーてアメリカのヤフーな

**デフォルトの名無しさん** · 2022/03/14(月) 00:29:01.66

98年末くらいだったかな？アメリカに爆速のサーチエンジンあるよってぁゃしぃわーるどだかで話題になって
試しに使ってみたら当時としては検索結果が爆速過ぎて驚いた記憶あるな
2バイト文字にも対応してるしシンプルな画面だったからAltaVistaやgooから速攻Googleに乗り換えたよ

**デフォルトの名無しさん** · 2022/03/14(月) 00:40:57.25

Googleは1998年創業パロアルトに移して本格的にWeb検索やり始めたのは1999年だから2000年当時はようやくアメリカで広まり始めてた頃だったと思う
2002年くらいまでは日本だとGoogleはあまり認知されていなかった
2001年YahooはGoogle採用したもののその後YSTとか作ってて、それを諦めたときが2010年。そのときと混同してないか？

**デフォルトの名無しさん** · 2022/03/14(月) 00:50:35.13

Wikipedia見てきたのかな？
日本だとヤフー強すぎて検索サイトイコールカテゴリー検索だったからな
グーグルのイメージないのは仕方ないと思う
でもアメリカでは2000年には既に超メジャーで、日本でも>>448のようにアングラサイト出入りしてる人達や
UNIX、Linux使いの人やプログラマーには90年代末にはデファクトスタンダードだったよ

**デフォルトの名無しさん** · 2022/03/14(月) 01:03:47.37

>>449
気になって調べた
JPNICによるとGoogleが検索サービス始めたのは1997年
ttps://www.nic.ad.jp/ja/newsletter/No70/NL70_0320.pdf
AltaVistaや千里眼が懐かし過ぎて涙出てきた

>>450
あの頃のアングラサイトは楽しかったね

**デフォルトの名無しさん** · 2022/03/14(月) 01:04:15.62

いや俺は当時検索デスクを欠かさず読んでた検索っ子だったぞ
そんな事実はなかった

**デフォルトの名無しさん** · 2022/03/14(月) 01:10:14.46

>>452
検索リテラシーが低かったんじゃないの？
とにかく俺や周りの人達は98年末くらいからGoogle使ってるよ

**デフォルトの名無しさん** · 2022/03/14(月) 01:12:22.48

検索デスクを知らないってことは嘘だね。。。

**デフォルトの名無しさん** · 2022/03/14(月) 01:18:10.05

うーん、やっぱいまいち思い出せないけど2001年頃にはVisual Studio6つかって趣味でいろんなゲーム作ってたような学生だったし、おれはとっくにGoogle使いまくってたような気がする
当時のIEって何かといろんなバーが追加されまくって表示が狭かったんだっけ、なつかしいね
初代Sleipnirとか出てからネットサーフィンも快適になったんだったかな

たしかに一般認知されるか、っていうとテレビCM出しまくるようになってからだろうし、もっとずっと後だね

**デフォルトの名無しさん** · 2022/03/14(月) 01:42:30.09

出た瞬間からアーリーが早く認知してたことをベースにするならRustは10年余裕で超えるので浸透速度が非常に遅い。
そりゃそうよ。OS付近やかなりな低レベルライブラリ向きで、アプリ開発にはバッテリーが小さすぎて向いてないんだから。

**デフォルトの名無しさん** · 2022/03/14(月) 01:49:04.04

>>437
関係無い。
RustはRubyやPerlよりも生産性が低い。

**デフォルトの名無しさん** · 2022/03/14(月) 02:24:15.93

年末に世の中の流行について行こうとPython+OpenpyxlでExcelファイルいじくるプログラム書いてみた
単にワークシート読み込むだけで分オーダー
ライブラリがワークシート読み込みだけなのでこっちはなんもやってない。
こりゃあかんってなって
ためしにC#+EPPLUSで同じプログラム書いてみた
全プログラム終了するまで5秒ww
あと、既存チャートの参照範囲変更するとかEPPLUSでサクッとできることがOpenpxlじゃできねぇんだわ
どこがいいのPythonて?

**デフォルトの名無しさん** · 2022/03/14(月) 02:25:55.59

>>458
両方のコードを公開しない限り、誰も何とも言えないと思う
ああ、この人python使えないんだなって普通は思うよ

**デフォルトの名無しさん** · 2022/03/14(月) 02:33:50.85

Pythonて集合演算ができるってんで
{a,b,c}3要素からなるべき集合のべき集合とか(ホントは位相空間を作ってみたかった)簡単に書けるかな?とおもってやってみたが、
とても簡単にできそうにない
MathematicaだとSubsets[Subsets[{a, b, c}]]で済む話
このPythonとかゆーがらくた言語なんでこんなに流行ってんの?
インターフェース誌あたりはずーっとPython一色だし。
Web scrapingとかだとC# Scriptでも実行時コンパイルで待たされるんで、
Pythonはイライラ感なく即実行できてウマーとはオモタ

**デフォルトの名無しさん** · 2022/03/14(月) 02:44:33.00

>>459
ま、Python使えないとお前が思うのは勝手だが
ワークシート読み込みのはライブラリが勝手に読むこともわからないんだろな。
プログラマが手を下すとことじゃない。
Matlabあたりも同様だけどこういうインタープリタは繰返し制御文で実行するんじゃなく
ライブラリに任すようにコーディングすんだわ。そこで1分とかかかってるようじゃゴミ判定が正解
ま、Python+Openpyxlは糞だな。とても日々の業務になんか使えないシロモノ。
こんなの使ってエクセルの自動化とか糞本買った方お気の毒としか言い様がない。
会社から金貰ってるって仕事してるっていう気持あるなら、
直接エクセルファイルunzipしてxmlいじくるか、素直にC#+EPPLUS使った方がはるかにまとも

**デフォルトの名無しさん** · 2022/03/14(月) 02:48:39.91

でもおれPythonには日々世話になってんのよな
fakymac+keyhac
しょっちゅう動作がおかしくなるけど、
sunキーボード+emacsで育った世代なんでさww

**デフォルトの名無しさん** · 2022/03/14(月) 03:00:48.63

>>460
そんな大変なんだろうか・・・
def subsets(x):
　　return [y for i in range(1,len(x)+1) for y in itertools.combinations(x, i)]

>>461
別に俺何を使っても書けるし、大昔から出来るし、時間かかるなら使い方悪いだけだと思う＝お前はpython使えない

**デフォルトの名無しさん** · 2022/03/14(月) 08:06:12.15

>>431
それだと使える人間が少なくなって全体の生産性は落ちるだろ。
Haskellの二の舞コースじゃね？

**デフォルトの名無しさん** · 2022/03/14(月) 11:35:31.82

>>461
直接って、xlxsの仕様を理解している前提じゃん。

Pythonは、速度要らなくて、目的で検索してライブラリが出て来て、コードコピペでも大体動く的なそういう使い方が多いと思う。

**デフォルトの名無しさん** · 2022/03/15(火) 12:52:11.85

rustが広まったらどっちにしろ大して理解してない奴が投入されて地獄見るわ。
そういう当たり前のことすら想像できない奴がrustマンセーしてるんだよな。

**デフォルトの名無しさん** · 2022/03/15(火) 15:22:25.57

>>466
一番儲かるのはスコップ売る奴という落ちだろうな。

**デフォルトの名無しさん** · 2022/03/15(火) 15:34:13.41

参考文献というお布施

**デフォルトの名無しさん** · 2022/03/15(火) 16:52:44.24

習得難易度が多少高くても自由度が低い言語を使う場合
低スキルメンバーが混ざっても惨事になりにくい

逆に習得難易度が低くても自由度の高い言語を使う場合は
高スキルメンバーで揃えないとすぐに破綻する

**デフォルトの名無しさん** · 2022/03/15(火) 17:42:54.49

昔はJavaの習得難易度高かったからな(VBに比べて)
その頃はそういう言い分もあって、実際にJavaはVBから来たコピペ野郎の洗礼は受けたものの、簡単なことしかさせないフレームワークという武器を得て、人海戦術の片腕となり得た

しかし今は当時より更に難しくなったJavaが習得難易度低に分類されているｗ
そのJavaより習得難易度がはるかに高く、ライブラリの使い方ではなく言語レベルでの書き方が難しいRustが低スキルメンバーに扱えるかというと・・・ｗ