次世代言語14 Go Rust Swift Kotlin TypeScript
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok
前スレ
次世代言語13 Go Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1534769753/
>>1の1行目に記入
!extend:on:vvvvv:1000:512
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured ちゃんとストアドでできる奴はそっちのが良いと思うけどな
自分は正直あまり自信ないし、デプロイとかフレームワークのこと考えるとO/Rマッパー使っちゃうけど、言ってることは間違ってないと思うわ
ちょっと前にqiitaにもストアドおじさんいたなぁ >>431
ブラックボックスとして使える内はね
製作者が退職した後にその構造を変えたり足したりしようとしたら阿鼻叫喚になる >>432
デプロイは確かに悩みどころ。
migrationでストアドも載せ替えてくような感じにするしか無いな。
なので、DBの改修って扱いになる
>>433
そんなのライブラリ関数でも同じようなもんだよw
ライブラリ関数作ってるアーキチームみたいな感じ、でDB屋も集まってる感じ。 >>430
>Gopherjsとgo+wasmで、gopherjsの方が早かったって結果をebitenの作者が書いてたよ
嘘ではないけど正確に書いて欲しいな
ChromeではGopherjsの方が速くFirefoxではgo+wasmの方が速かったって結果だよ
最終的に一番パフォーマンスが良かったのはGopherJS on Chromeだったけど >>434
ライブラリ関数の戻り値は基本的にシンプル値とかリストくらいだけど
ストアドの戻り値は多くの場合整形された複雑なViewじゃん？
前者の場合変更が起こる確率はそれほど高くないし手間も大きくはない >>435
面目ない、wasmが早くないって事のインパクトが大きくて端折ってしまった。
まあ、今のところGoのwasmは「パフォーマンスとかおいとくよ」って言ってるし、伸びしろはあるのかもしれないし、不正確だったな。
>>436
実感的には更新はストアド、取得はView(場合によってはマテリアライズド・ビューだったり、Triggerで生成されるテーブルだったり)が多いんじゃないかな。
ぶっちゃけ後者も同じ程度だよ。ガチで運用すると。
むしろアプリ側から見たら割と純粋だし、手間は思ってるよりも無いよ。
眺めるためのviewではなくて、アプリのためのviewだし。 >>428
> 知能が低い奴ほど正しいストアドを見たことが無いだけ
知能が低い人間としては是非見てみたいので
いい感じに疎結合になっているストアドとViewの低脳でも分かりやすいミニマルな例を出してみてくだしあ >>438
単に半角さんへの煽りだよ。
とはいえ、割と見たことあるからそこまでレアなアーキテクチャじゃないと思うけど。
医療で、そこそこの規模の開発はだいたいそういう感じでやってた。金融でも同じ作りは聞いたよ。
サンプルでミニマルだと、ストアドが鬱陶しく見えるだけだと思うわ。 >>428
低知能は自分の低知能に気付けない説
あるおねｗ 医療と金融ｗ
事なかれ主義の土方ども墓場じゃないですかーｗ やだーｗ >>441
意外に新しい物も使うぞ。
ただいろんな法律や保医発みたいな通達に縛られてるだけで。
電子カルテがクラウドに長いこと乗せられなかったのは、センシティブ情報ってのもあるけど、診療録は院内に置くことって決まってたからだし。
充分な試験さえすれば新言語ぐらい使える。 現場によるわな。
終わらないことで有名な某銀行のシステム開発じゃemacsさえ入れられん。。 >>444
あんまり研究開発費も使えないからな…
下請けさんの単価って下請けさんの社員さんが思ってるより高いから… 工数買う方からしたらPG一人の拘りを尊重したところで全体の生産性なんかほとんど変わらん
これは決してマクロな視点だからというわけではなくて、
個人単位で見ても、実際のところ、拘りを無視しても本人が主張するような生産性の低下はほとんど見られないもんなんだよ そしてウンポコペチプーによるウンコードの山盛りウンコがひり出されていく >>447
そりゃツールの一つや二つならそうだろうけれど、問題は全てに渡って
最低基準に合わされるってところなわけだよ。 変えるならプロパーが検証してから一気に環境変えるわな。
環境構築を言い訳にされたくないし。
「みんな同じ環境で結果出してますよ」ってのは真実であるべきだし。
そのためにほんとに必要だと思うなら直談判して入れさせれば良いと思う。
何度か「確かに。導入してみる？」って導入したものあるよ。 >>449
金融系の最低基準ってISPFっていう大昔のSF映画に出てくるような黒画面に緑色の文字のCUIだぞ？
そんなバカなと思うかもしれないがこれは本当の話で、現代においてもそれほど珍しいことではない
SEはそういうレベルで言ってるんだよ
ところが面白いことに、Javaと比較してもそれほど生産性は大きく変わらなかったりする
システム開発の生産性ってのはSEが何をどのレベルで要求するかでほとんど決まる 開発環境の最低基準では？
医療もレセプト関係の医事課さんが使うようなやつは、罫線で引いたような画面でも許されると言うか、重いぐらいならそうしろって言われるな。 >>452
ところが開発環境の話なんだよなあ
30年以上前に作られたとは思えないくらい意外とまともなエディタが付いてるぞw まともなエディタって秀丸エディタのことでも言ってるのかな、この程度の低さよ、ペチパー並だな >>453
それはキツいなw
医療はIDE縛りはあるけど、さすがにGUIだった。
変なIDEだったけど(笑) >>456
残念ながら現役だよw
ってか知ってる方もどうかしてる。 ってかどの段階で残ったか移ったかをぼかしとかないと特定されるなw 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。 >>451
みどりの窓口でキップとるのに使ってるシステムも今でもそんなだったような >>462
8bitパソコンで作ったような画面ね
グラフィック画面をオーバーレイするのではなく
それこそBASICのLINE命令で線を描いたような画面 軽量PHPフレームワークSlimは何が「軽量」なのか？〜特徴と環境構築 (1/2)：CodeZine（コードジン）
https://codezine.jp/article/detail/11179?p=2
クソバカガイジペチプーは、まーたフレームワークを作ってるらしい
いつまでフレームワーク作ってるんだこいつらｗ
肝心のプロダクトコードはゴミ山ｗ >>466
未だに時々沸いてくる小バエがうるそうてのう
プチプチ潰していかんとな、プチプチ糞プチパァｗ お前は結局PHPに対する未練が拭い去れない哀れな敗北者
よっぽど感心がなきゃ流行るかどうかも分からんようなマイナーでマニアックなフレームワークなんて気にもしないだろ
PHPに関するヘイト発言も結局のところこんな仕事辞めてやると息巻いて退職したももも結局PHPしかできるスキルがなくて再就職できない自分への自虐か何かなんだろ？ ていうか今更Slim知るって
山奥で暮らしてんのか？ 都会人特有のウンコの色でマウントを取ろうとするのはみっともないからやめなさい イヤでイヤで逃げ出した古巣を叩くのは良くある話
そして、実はそこしか居場所がなかった、なんてのも
もし抜け出して上手くいってるなら思い出したくもならんしね PHPに詳しいとこのスレでマウント取れる環境になりつつあるｗ マウント取るなら
haskell,rust,c++あたりだな。
実際プライドの高い馬鹿が一番多い。 >>469
負け犬ペチPoorの遠吠えが心地よい
ふつうに転職して年収700もらっとるで
ペチPoorな言語なんてもうしばらく見てもいないね
君、禿げたつむじから$が見えとるでｗ >>477
ruby を勉強している身としては ruby でマウントが取れるかどうかが気になります、実際どうなんでしょうか？ スクリプト言語はPythonの勝利で終わった
残念だったな >>479
マウント取るにはやっぱ静的言語。
コンパイル時点で勝負がついてる感をださないかん。
そういうクソみたいなプライド出してくるのが言語マウンティングだから。 Pythonはプログラマは使いたがる反面
顧客から求められる言語としては希少
スクリプトはJavaScriptがここ数年伸びてきてる Javascriptはここ数年がどうのというレベルじゃないでしょおじいちゃんｗ
政治的に保護された言語だからこういう議論ではジョガイや。 スクレイピングはPythonでやろう！みたいなやついるけど、
どう考えてもJSでやったほうが筋がいいよな それｗ
js実行後のDOMいじんのつらそう。
なんであんな縛りプレイしてるんだろｗ
puppeteer最高過ぎるｗｗｗ
ブラウザ解釈前の操作も解釈後の操作も楽々ｗｗ
しかもブラウザのdevToolでDOMやらCSSやら操作する知識まったくそのまま転用できるｗｗｗ
Google様ありがとうございますありがとうございますｗｗｗｗｗ Pythonは遅すぎてスクレイピングに向かないだろ
jsもそんなに早くないけどインタプリタとしては早いほうだしな
ブラウザがtsに完全移行でもしない限りjsはJavaにも取って代わるようになるし
tsがコンパイルと称してjsに翻訳して時点でtsがjsに取って代わることはないだろうしな スクレイピングにcpu資源なんてほとんど使わんだろ。
ほとんどはネットワーク速度に律速されるようなもんだぞ。 tsはビルド時間の遅さをなんとかしてほしい。型チェックありでビルドすると40分かかるプロジェクトとかある。 Qiitaに掲載された怪文書
ttps://web.archive.org/web/20181106122755 >>491
もう削除されてないか？
ゴミ箱の絵が出たが。 >>492
あっ悪い、元が見れなくなってるから魚拓の方貼ろうとしたんだがちゃんと貼れてなかった
ttps://web.archive.org/web/20181106122755/https://qiita.com/administrator1974/items/387aab2a42bf57e3b215 利用規約違反によりユーザー資格取消って何やらかしたんだ？ 不毛な言語叩きや他ユーザーへの攻撃的な言動
ありそうなのはこの辺じゃない？ >>493
こいつ44歳かよ…どうしてこうなったｗｗ いや44でもきつい…
54なら保守だけなら許せる
時代云々より日本語が不自由そうなことの方が気になる なかなか面白いな
業界1年目の新人が付け焼き刃の知識で殴り書きしたみたいだ
消さなければ爆釣だろうに ネタかマジか分からんが
大文字小文字ガタガタなのすこ 5年前の35前後（今40前後）のプログラマって、マジでヤベーやつがいる
レベルが低いとかじゃなく、ヤバイ
しかも結構な割合で
関数型はおろか、MVCすら理解が怪しいレベルのやつ
そんな連中が作ってしまったゴミの保守やリプレースは吐き気がしますわ 今どきJAVAとか言う奴はmavenやらgradleに上がってるライブラリたちが過渡期過ぎて停滞しまくってるの知らねーんだろな >>507
今どきJAVAとか言う奴がmavenやらgradleやら知ってるわけないだろ
「mavenは学習コストが高いから、手動でライブラリをDLしてコミットした方がいい」とか言い出すぞ yarn とか、知ってるのかな？
VSCode の拡張機能、ESLint には、package manager である、yarn のインストールが必要。
yarnには、node.js のインストールが必要
yarnは、npm でインストールしなかった。
Windows10 に直接インストールした
yarnは、数MB のJavaScript で作られているのか。
Ruby のBundler, npm の影響を受けている
where node
C:\Program Files\nodejs\node.exe
where yarn
C:\Program Files (x86)\Yarn\bin\yarn
C:\Program Files (x86)\Yarn\bin\yarn.cmd
C:\Program Files (x86)\Yarn\bin\yarn.js そこそこ高度なビジネスアプリとか触ると既存のライブラリやパッケージを使う機会のが多いわけで、特定の言語だけやっとけ、みたいなのはちょっと… nodeのアプリって本体は小さいんだけど、node_modulesが悲惨なんだよね。
容量も大きいし、node用のモジュールはwebpackしてしまうにも出来ないものも多い
(ダイナミックにrequireしてたり)
結局インターネットが疎通してないところにデプロイするのに、全部持ってかないといかんし、ネイティブモジュール使ってたらクロスもしづらいから本番と同じような環境を用意して持ってかないといかん。
そのへん、Goは楽で良い。
.net coreは同じようにファイルがたくさん必要でも、クロスでビルドして固めておけるからもう少しマシ。
他の言語はもう少し頑張ってほしい。 goはgoogle謹製という時点でな…
kotolinも同じ理由で敬遠する
とはいえnodeもchromeエンジンだけど >>513
GoogleとJBの共通的な避ける理由ってなんだ？ はてなブログの気持ち悪い部分を見ずに技術的なことを調べられるのがQiitaの利点だったのに
もうどっちも陰キャの内輪向け激寒大喜利大会みたいになってるやんけ 言語はある意味宗派みたいなもんだからな
合わなきゃ合わないでやらなきゃ良い goもrustも資源解放はそのスコープでやれってのが共通してたりする。 Googleだから信用できないって人まだ言ってるの？ 典型的なしょーもないシンタックス批判だな。
nilの型が不安定とか他に言うことがあるだろうに。 ■ このスレッドは過去ログ倉庫に格納されています
