プログラマって馬鹿が多いよね

**デフォルトの名無しさん** · 2024/11/27(水) 21:51:22.57

低レイヤーとか関数プログラミングとかなんとなく難しそうなものを大して理解もしてないのに崇めたがる
分かってる人からみると非常に滑稽

**デフォルトの名無しさん** · 2025/01/03(金) 21:09:19.74

表現力だよ
数学や哲学と同等の表現力を得たらその言語が最強になる
最適化は処理系が行えばよい

**デフォルトの名無しさん** · 2025/01/03(金) 23:58:08.78

>>430
大昔ならともかく今はCPUのパイプラインやメモリアクセスのために実行順序を(結果に影響のない範囲で)入れ替えたりメモリをガードしたりコンパイラは最適な生成コードを吐く
さらにループなどはベクタ命令に変換するなどの最適化も行こなう
人間がアプリなど全体を最適にネイティブコードを書くのは現実的でない

**デフォルトの名無しさん** · 2025/01/04(土) 03:40:06.82

Rustってそんなに流行ってるの？

**デフォルトの名無しさん** · 2025/01/04(土) 05:32:50.75

流行ってるかどうかはともかく大企業は流行らせたいらしいから
その波に乗れれば大儲けできるかも！

**デフォルトの名無しさん** · 2025/01/04(土) 10:16:50.41

>>412
>実行時デバッグは純粋にアプリのロジックのプログラミングミスのみに限定される

doubt

**デフォルトの名無しさん** · 2025/01/04(土) 10:21:46.24

>>415
>人材の豊富なJava

ゴミは集まってもゴミ

**デフォルトの名無しさん** · 2025/01/04(土) 13:56:44.73

>>440
数人集めれば1人くらいは当たりがいるから…

**デフォルトの名無しさん** · 2025/01/04(土) 17:54:12.62

その理屈だとLISP最強なんだけど
商用処理系も昔はそれなりにあったようだが
人間が使うには見た目がキモすぎて流行らなかったな

**デフォルトの名無しさん** · 2025/01/04(土) 18:07:53.61

どの理屈？

**デフォルトの名無しさん** · 2025/01/04(土) 19:00:17.49

>>436
CPUの系統毎に全く思想の異なるコードをそれぞれ用意しなければならないもんな
さらに同じ系統でも世代毎に使えるベクタ命令が異なるため異なるコードが必要
そして可読性も保守性も非常に低い

**デフォルトの名無しさん** · 2025/01/04(土) 19:02:39.72

だからネイティブコードのアセンブリ部分は最小限にする必要がある
プログラム全体は可読性と保守性を重視してRustで記述
その中の必要な箇所のみRustがサポートするインラインアセンブリを使うことが望ましい

**デフォルトの名無しさん** · 2025/01/05(日) 00:10:45.22

組み込み開発者風の人も来るスレ

**デフォルトの名無しさん** · 2025/01/05(日) 10:55:28.95

unsafeだらけになるから
unsafe禁止厨は大反対するだろうな

**デフォルトの名無しさん** · 2025/01/05(日) 12:07:57.14

プログラマ市場の一番の需要大がサーバーバックサイド周りなわけだけどJavaはまだまだ強いねえ

**デフォルトの名無しさん** · 2025/01/05(日) 12:39:39.78

プログラマになろうと思って人気言語ランキングでもjavaって上位になってるからspringやってるんだけどこれってphpのlaravelに比べてめんどくさすぎない？
web系に進むとしてjavaとphpだったら結構年収に違いでたりするの？

**デフォルトの名無しさん** · 2025/01/05(日) 13:22:04.01

習得がめんどくさくて諦めるならプログラマより違う道を探したほうがいいかと

**デフォルトの名無しさん** · 2025/01/05(日) 13:26:32.84

儲かる言語はなんですかｗ
>web系に進むとしてjavaとphpだったら結構年収に違いでたりするの？

**デフォルトの名無しさん** · 2025/01/05(日) 14:24:12.89

phpはjsより面倒
javaはphpより面倒
rustはjavaより面倒
∴rustが最強

**デフォルトの名無しさん** · 2025/01/05(日) 14:27:06.56

rustはその習得難易度で無能をあらかじめ弾けるから経営者に好かれている面は明らかにある

**デフォルトの名無しさん** · 2025/01/05(日) 14:44:31.34

[NGword:Rust]

**デフォルトの名無しさん** · 2025/01/05(日) 14:56:42.94

ム板で業界談義するような馬鹿はプログラマにすらなれん

**デフォルトの名無しさん** · 2025/01/05(日) 16:04:49.46

>>455
プログラマスレで業界雑を禁止したらなにを話せばいいんだ？

**デフォルトの名無しさん** · 2025/01/05(日) 16:17:09.61

ム板でマ雑してることがそもそもおかしいから早くマ板に帰れボケども

**デフォルトの名無しさん** · 2025/01/05(日) 16:21:45.26

スラックでチャンネル違いとかを厳密に指摘して雑談の邪魔してそうな奴出てきたな

**デフォルトの名無しさん** · 2025/01/05(日) 17:12:44.87

「スラック」とはどういう意味ですか？
英語表記「slack」の日本語読みで、「需給の緩み」のこと。需要と供給の間にギャップが生じ、釣り合わない状態を言います。経済全般や労働市場での供給の「余剰」を指し、スラックが解消されると、経済状況が改善します。

**デフォルトの名無しさん** · 2025/01/05(日) 17:39:16.86

Slackをご存知ない？！
仕事で使ってないのかよ

**デフォルトの名無しさん** · 2025/01/05(日) 18:15:11.09

Slackwareは、シンプルでトラディショナルなUnixの哲学に忠実なディストリビューションです。
これにより、Linuxシステムの基本的な原則と構造を深く理解することができます。
パッケージ管理が簡略化されているため、システムの背後にあるメカニズムを学ぶことが容易になります。

**デフォルトの名無しさん** · 2025/01/05(日) 18:22:00.74

>>460
うちはTeams使ってる

**デフォルトの名無しさん** · 2025/01/05(日) 21:42:03.04

Winnyの映画見てるけど金子勇もクズ警察の言いなりになって
不利になる書類に署名してある意味ではバカかな

**デフォルトの名無しさん** · 2025/01/05(日) 23:44:44.05

>>431
言語の実行パフォーマンスが重要な環境や重要な分野が大量にあるよ
そうでなくても遅いと必要となる機器の台数が増えたり高価な機器が必要になったり電気代は間違いなく増えるよ

どのプログラミング言語でも覚えてしまえば後は簡単なのだから実行が速い言語がベスト
そしてメモリ消費も少なくできる言語がベスト
皆がそうすれば機器も電気代も節約できて環境にエコだよ

**デフォルトの名無しさん** · 2025/01/05(日) 23:50:02.02

なにいっとんだこいつ…

**デフォルトの名無しさん** · 2025/01/06(月) 09:15:20.00

人件費 >>>>> 運用費用

**デフォルトの名無しさん** · 2025/01/06(月) 09:41:10.05

機器、電気代を払うのは鯖管
プログラム書くのはPG

**デフォルトの名無しさん** · 2025/01/06(月) 12:22:16.61

>>464
それはどの言語？

**デフォルトの名無しさん** · 2025/01/06(月) 19:30:08.22

エコとか言ってるアホのせいで空白の30年が生まれたのにまだ反省してないなこりゃ

**デフォルトの名無しさん** · 2025/01/06(月) 19:42:44.82

なにをもって空白と定義してるのかまで語ってくれ

**デフォルトの名無しさん** · 2025/01/07(火) 00:05:33.28

ブチクシと一緒

**デフォルトの名無しさん** · 2025/01/07(火) 00:07:11.29

NHK教育を見て69308倍賢くチーター

**デフォルトの名無しさん** · 2025/01/08(水) 10:37:00.85

>>467
プログラマを雇うのは人事

**デフォルトの名無しさん** · 2025/01/08(水) 15:10:59.71

賢ければプログラマを雇う側だから

**デフォルトの名無しさん** · 2025/01/08(水) 15:50:57.90

馬鹿程自説に拘る

**デフォルトの名無しさん** · 2025/01/08(水) 17:26:32.13

>>1の事ね

**デフォルトの名無しさん** · 2025/01/09(木) 12:49:23.72

馬鹿って言いたいだけで中身がない >>1

**デフォルトの名無しさん** · 2025/01/09(木) 13:29:06.70

馬鹿だけど質問ある？

**デフォルトの名無しさん** · 2025/01/09(木) 13:55:07.56

あなたの自説は何ですの

**デフォルトの名無しさん** · 2025/01/09(木) 13:55:43.09

あるわけないだろ

**デフォルトの名無しさん** · 2025/01/09(木) 15:38:48.76

いつ馬鹿に気付いた？

**デフォルトの名無しさん** · 2025/01/10(金) 14:57:55.46

透明な■つまり□なら空白なのかな❓
でも、豆腐文字は空白ぢゃないよな🤔
とにかく、ホワイトスペース、これが空白
ホワイトスペースへ黒を適用しても
黒くはならず背景が白なら白だよな❓
てか、空白ってなんだろう

**デフォルトの名無しさん** · 2025/01/10(金) 17:28:46.46

板違いスレむやみに上げる実況板と区別つかないバカ

**デフォルトの名無しさん** · 2025/01/10(金) 19:56:03.48

>>433
>>pythonだってCPythonとかでコンパイルすりゃ速いわけじゃん

ダウト
CPythonはPython用内部バイトコードにコンパイルするだけ
マシン語へコンパイルできません

>>となると実行速度なんて後でどうにか出来るから書きやすいかどうかの方が重要じゃね

ダウト
Pythonはその言語の仕様上
どうやっても遅いです
しかも開発のしやすい言語ではありません
あくまでも短いスクリプトを書くための言語です

**デフォルトの名無しさん** · 2025/01/13(月) 13:48:28.18

pythonはtclみたいなもんだね

**デフォルトの名無しさん** · 2025/01/14(火) 19:33:00.84

遅い言語しか使えない下層が
言い訳しながら遅い言語を使う

**デフォルトの名無しさん** · 2025/01/14(火) 23:39:38.17

速い言語を使う意義が薄い

**デフォルトの名無しさん** · 2025/01/15(水) 06:41:17.16

>>487
サーバー系なら速いほどいいけど

**デフォルトの名無しさん** · 2025/01/15(水) 07:38:04.79

>>488
そんな一部界隈のことを持ち出されても困るんだが

**デフォルトの名無しさん** · 2025/01/15(水) 10:17:07.01

そうだぞ。フロントエンドだけがエンジニアなんだから、それ以外は弁えろよ

**デフォルトの名無しさん** · 2025/01/15(水) 17:53:54.35

最近になって思うんだが、プログラミング言語の速度、っていう表現自体が誤解を生んでるんじゃなかろうか。理論上限りなくオーバーヘッドを少なくできる言語がC、C++とかっていう。

**デフォルトの名無しさん** · 2025/01/15(水) 18:06:15.49

何に対するオーバーヘッドだよw

**デフォルトの名無しさん** · 2025/01/15(水) 18:18:46.15

プログラムの処理。コンパイル言語なら最終的に機械語に変換されて実行されるわけだから、同じ機械語で処理速度の差なんて出ない。でも、言語が違えば出力される機械語の内容が異なるだろうから、そこで処理速度が変わってくる。コンパイル言語でもGCある言語はその処理が加えられて、それがオーバーヘッドになる。そういうオーバーヘッドがほぼないっていうのがCとかなんじゃない？っていう意味。

**デフォルトの名無しさん** · 2025/01/15(水) 18:20:50.21

余計な処理のことをここではオーバーヘッドという言葉で表現したが、これって不適切なん？まあどうでもいいけど。

**デフォルトの名無しさん** · 2025/01/15(水) 19:15:03.79

こんなスレで何度も長文レスしてる奴は馬鹿だな

**デフォルトの名無しさん** · 2025/01/15(水) 23:19:41.98

実行速度や使用メモリの少なさを求めるなら
Cは自分で色々やらなきゃいけなくて面倒でミスるとセキュリティホールだったけど
今はRustがあるから楽勝

**デフォルトの名無しさん** · 2025/01/16(木) 05:16:33.10

Rustも処理速度ではC言語に負けてるからセキュリティ考えなくていいプログラムを置き換えられないんだよなあ

**デフォルトの名無しさん** · 2025/01/16(木) 07:27:02.19

>>497
RustはCと同じ速さを必ず出せます
Cと同じ事が必ず出来ます
RustはインラインアセンブラもサポートしているためCと同様に必要な部分のアセンブラコード記述も可能です

**デフォルトの名無しさん** · 2025/01/16(木) 09:25:46.90

なんだそのSTAP細胞はありますみたいなのw

**デフォルトの名無しさん** · 2025/01/16(木) 10:36:48.70

Rustって関数とかの命名が小文字とunderbarだけでやりくりしてるっぽいけど、見にくくない？慣れてないっていうのもあるやろうけど、なんかこれじゃないといけない理由とかあるの？
これであることのメリットってあるの？コンパイル速度遅いから、コンパイルが早くなるとかではなさそうだが。

**デフォルトの名無しさん** · 2025/01/16(木) 12:19:33.58

>>500
何を言いたいのかわからない
何かに慣れていなくて読みにくいというのはその人の個人の問題であり個人が解決すべき話

もし何か長くなるから読みにくいという話であれば、
一般的に名前パス空間のある普通のプログラミング言語ならば
昔のようにグローバルな空間で衝突さないよう長い長い長い名前を名付けることはレアケース

さらにほとんどは何らかのメソッド呼び出しになるため
そのメソッドの対象は何なのか既に限定されていることから
メソッド名は冗長にせずにさらに短く簡潔に付けることが行なわれる

**デフォルトの名無しさん** · 2025/01/16(木) 12:21:37.02

>>500
Rustに固有の話であれば
今どきの言語は記述の統一性と可読性のためにどのように書くか言語として定めることが多く
Rustでも関数名やローカル変数などはsnake_case
定数や静的なものはSCREAMING_SNAKE_CASE
一般型やトレイトなどはUpperCamelCaseと定められている
このため
要素により区別があり読みやすい
＆
ひとに依らずコードの記述が統一されて読みやすい

**デフォルトの名無しさん** · 2025/01/16(木) 13:46:15.60

病気

**デフォルトの名無しさん** · 2025/01/16(木) 18:40:27.00

>>498
コンパイラの専門家が否定しているが？

**デフォルトの名無しさん** · 2025/01/16(木) 23:26:34.07

>>504
対象となっている話はこれだぜ

>>497
>>Rustも処理速度ではC言語に負けてるからセキュリティ考えなくていいプログラムを置き換えられないんだよなあ

Rustは言語における安全性をプログラム全体に対して保証してくれるが
代わりに人間がそのエリアを保証するunsafeブロックがある
そのエリアではCと同じことが可能で必要ならアセンブリで書くことも可能
unsafeを内部で利用して外部には安全なインターフェイスを公開することが可能なため標準ライブラリなどはこの形で作られている

**デフォルトの名無しさん** · 2025/01/17(金) 10:19:28.02

プログラマって馬鹿が多いよね

**デフォルトの名無しさん** · 2025/01/17(金) 15:59:11.31

>>493
ダウト
完璧な間違い

**デフォルトの名無しさん** · 2025/01/17(金) 16:01:23.74

>>505
unsafeを文字通りunsafeだと思ってはいけない
unsafeは実はsafeなんだと思った方が良い

**デフォルトの名無しさん** · 2025/01/17(金) 16:08:20.85

安全なインターフェイスだと言い張っているがunsafeだと思った方が良い

**デフォルトの名無しさん** · 2025/01/17(金) 17:27:21.64

ガソリン上げないといってもすぐ上がるみたいな

**デフォルトの名無しさん** · 2025/01/17(金) 17:54:05.39

Rustのunsafe
＝プログラマーが自分で安全性を保証しなければならないこと
＝普通のプログラミング言語と同じ

つまり危険という意味ではない
自動的に安全性が保証される枠外の意味

**デフォルトの名無しさん** · 2025/01/18(土) 07:09:02.13

プログラムできないやつがプログラム言語Rustを語るスレか

**デフォルトの名無しさん** · 2025/01/18(土) 13:54:00.09

文字コードスレでもいらんこと書いて暴れとるな
まったく

**デフォルトの名無しさん** · 2025/01/19(日) 12:04:23.66

内藤時浩
ＮＡＩＴＯＴｏｋｉｈｉｒｏ
８bitの時代から、既に４０年以上が経過してますが、その４０年以上ずっとメモリは足りてないし処理速度も足りていないって言い続けてる。
メモリはＫＢ単位からＧＢ単位と１０万倍以上増えているのに、ＣＰＵもＭＨｚからＧＨｚと１０００倍以上高速化してるのに、なんで？

**デフォルトの名無しさん** · 2025/01/19(日) 12:04:46.47

https://x.com/NAITOTokihiro/status/1880426410210476152

**デフォルトの名無しさん** · 2025/01/19(日) 12:05:45.66

こんなことは、コンピュータサイエンスを勉強すれば当たり前に学ぶことだが、何さも自分オリジナルの問題意識みたいに語ってるんだろこのおじさん・・・

**デフォルトの名無しさん** · 2025/01/19(日) 13:48:18.23

そっち系の問題はサイエンスやのうてエンジニアリングとかテクノロジっていうんやで

**デフォルトの名無しさん** · 2025/01/19(日) 22:34:07.31

C言語を学ぶとコンピュータの原理がわかるぞおじさん「C言語を学ぶとコンピュータの原理がわかるぞ」

https://www.kyoritsu-pub.co.jp/book/b10003350.html

**デフォルトの名無しさん** · 2025/01/19(日) 22:39:07.62

K&Rなんて今や歴史的価値しかないのに

**デフォルトの名無しさん** · 2025/01/20(月) 14:00:07.81

コンピュータの原理＝CPUやアセンブラというのが、ものすごく極端で一面的な視点でしかない

**デフォルトの名無しさん** · 2025/01/20(月) 14:06:47.67

極端で一面的な視点で完結できるのが入門として良いのでは？

Webフレームワークなんかから入ると前提知識無限大

**デフォルトの名無しさん** · 2025/01/20(月) 15:10:13.42

>>520
不思議で仕方ない。
抽象化がコンピュータシステムの重要な本質であることは、昔からずっと言われ続けている。マシンリソースが潤沢になった現代からではなく、黎明期からずっと言われている。何なら、「パタヘネ」みたいな低レイヤーの本こそ、その側面をこれでもかというくらい強調している。
にもかかわらず、日本では一部の狂信者が昔から誤った低レイヤーカルトを布教している。

**デフォルトの名無しさん** · 2025/01/21(火) 18:51:15.23

トンボはぜんぶヤンマ
チョウチョはアゲハ
ゲームはファミコン
コンピュータはアセンブラ

世界の解像度が低いひと

**デフォルトの名無しさん** · 2025/01/23(木) 13:16:24.21

元社員です。直接的な原因はさておいて、大元の原因は人事システムが全く機能していなかったことだと思う。
実質２代目の佐伯某が総ての元凶。その次の辻某は娘婿の兄、更にその次の町田某はもう１人の娘婿、
片山某に至っては親友の息子(東大卒業後即幹部候補生？)。トップがそんなんだから取締役以下の管理職は皆右へ習え状態。
私は中途採用だったが、当時は有能な人でも上司のお気に入りのイエスマンでなければ皆係長止まりで、
おべんちゃらが上手いだけの無能が課長・部長になっていて不思議に思うことがよくあった。

**デフォルトの名無しさん** · 2025/01/23(木) 14:41:21.23

わたしは転勤が多かったが、ある時有能だが部長止まりの人に言われたことがある、「君も随分損してるな」と。
私の体験した実例を紹介する。ある時ある営業部が昇格し、営業本部になった。すると本社の取締役が営業本部長になり、
昇格に大功のあったはずの営業部長は副本部長と成ったが、２年も経たないうちに外部団体へ出向となった。
更にその取締役が本社から連れてきた課長が、内勤の事務職にも関わらず、その後２年間で３回も昇進した。

**デフォルトの名無しさん** · 2025/01/23(木) 19:15:03.91

営業部門で大きな功績のたてようがないどころか、其奴が担当した展示会は準備・運営等が余りにもお粗末で営業からは不満が続出し、
その次の展示会では担当を外されてた様な無能な奴がほぼ半年毎に昇進ってあり得ないでしょ！
旧日本軍と同じで兵隊は優秀でも指揮官が無能だと負けるという良い例。

**デフォルトの名無しさん** · 2025/01/23(木) 19:15:25.73

営業部門で大きな功績のたてようがないどころか、其奴が担当した展示会は準備・運営等が余りにもお粗末で営業からは不満が続出し、
その次の展示会では担当を外されてた様な無能な奴がほぼ半年毎に昇進ってあり得ないでしょ！
旧日本軍と同じで兵隊は優秀でも指揮官が無能だと負けるという良い例。

**デフォルトの名無しさん** · 2025/02/10(月) 08:13:30.16

馬鹿っていうか勘違いが多い。

例えばだけど、殆どの人って仕事でシステム作ってる。
その為のプログラミングな訳で手段なんだよね。
にも関わらずエンジニア寄りの考え方をするからズレるんよ。

言語を作るとかフレームワークやOSSライブラリを作るというならエンジニア寄りの考えを持たないとダメ。

つまり目的を見失ってるというか勘違いが多い。

**デフォルトの名無しさん** · 2025/02/10(月) 08:29:01.14

はい

**デフォルトの名無しさん** · 2025/02/10(月) 11:03:12.84

「プログラミングするならMac」も勘違いから

**デフォルトの名無しさん** · 2025/02/10(月) 11:23:55.32

企画すんのは自由だけど人を巻き込んで無理矢理やらせようってなら
まず払うもん払いな、ボランティアやってんじゃねえんだから

**デフォルトの名無しさん** · 2025/02/10(月) 13:01:38.67

>>528
エンジニアの考えを持たないから失敗するんだよ
仕様に問題があったら発言しないといけないし発言できないプロジェクトなら失敗は約束されている
そういう奴らはAIに置き換わるだろうな

**デフォルトの名無しさん** · 2025/02/10(月) 15:25:32.16

考えは個人の能力やシステムの特徴によってベストな設計をするのが理想
設計とコーディングが同一人物ならそのままのものができる
複数人でやるならインターフェースを決めて任せるしかないんじゃね
AIだろうが新人だろうが正常に動くかどうかが重要だと思う、しらんけど

**デフォルトの名無しさん** · 2025/02/11(火) 06:49:01.22

プログラムすらできないバカのコンプスレかよ
令和は小学生でもプログラムできるってのに