次世代言語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 >>417
そういう君はそれとあれの日本語的な意味の違いちゃんとわかってる? 知能が低いヤツほど
ストアドSQLを多用する傾向がある >>409
404 名前:デフォルトの名無しさん (ワッチョイ e29f-fe/1) [sage] :2018/10/08(月) 10:36:37.69 ID:NFI2fQQ+0
もうJavaScript自体がDOM操作の為に大概最適化されてるだろうしね
この憶測を検証するのにAPIの策定が必要な異世界に住んでいるのか? >>409はおそらく>>407を検証しろと言われたと読み違えたんだろうけど、
そっちの方は予測だから好き勝手に論ずればいいと1行目で明確に書いている。 >>423
それは検証するまでもないし検証する意味も無くね
その辺は当たり前のこととして、さらに上回る余地があるかという話だと思うし
「なると思う」「ならないと思う」という小並感は意味無いとしても
原理から演繹する思考実験は出来る
リニアメモリと低水準命令セットの仕組みや強い型付けがあることは
ネイティブコールとの結合でもJavaScript+JITより有利
JavaScript側に、numpyやベクトル計算機ように操作自体をまとめて指示できるAPIがあるならともかく
個体ごとの操作しかないからWebAssemblyの仕組みは尚更有効 >>425
あくまでCPUバウンドな処理において、の前置き付きでな
DOM操作に拘るならパフォーマンスの検証は現状でも容易だ
ReactやVueのような仮想DOMを使用したレンダリングにおけるJS側とブラウザ側の処理時間の比 (x : y) を測定してやれば、
WebAssemblyに置き換えたときの理想的なパフォーマンスは y/(x+y) と近似できる
俺は検証するまでもなく絶望的な結果になると思ってるけどね 実際メリットがないから実装のプライオリティが低いんじゃないの? 知能が低い奴ほど正しいストアドを見たことが無いだけだろ。
正しくDBエンジニアたちが作ったストアドとViewは、いい感じに疎結合になってるし、
DBとアプリどっちの変化も吸収してくれる上に、そのへんのやつが書いたSQLよりも安定して早いぞ。
カーソル使う/使ってるようなストアドは存在自体が間違ってるとは俺も思うが、
まともなストアドは中途半端に作ったDBや、ORマッパーお任せのDB作成/クエリーよりは良いと思う。
DBエンジニアが居ないような現場だとクソなのかな。 Wasmの関数に整数以外を渡すときは結構手数がいるし、型付と言ってもWasm内ではただのバイト列だから死に方はWasm作るために使った言語次第だよ。
だから、単純にwasmにすれば多少パフォーマンス上がるって言い切る事もできない。むしろ遅くなるかもしれん。
Gopherjsとgo+wasmで、gopherjsの方が早かったって結果をebitenの作者が書いてたよ。
あれは画像とかも渡してるけどね。 ちゃんとストアドでできる奴はそっちのが良いと思うけどな
自分は正直あまり自信ないし、デプロイとかフレームワークのこと考えると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
低知能は自分の低知能に気付けない説
あるおねw 医療と金融w
事なかれ主義の土方ども墓場じゃないですかーw やだーw >>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
クソバカガイジペチプーは、まーたフレームワークを作ってるらしい
いつまでフレームワーク作ってるんだこいつらw
肝心のプロダクトコードはゴミ山w >>466
未だに時々沸いてくる小バエがうるそうてのう
プチプチ潰していかんとな、プチプチ糞プチパァw お前は結局PHPに対する未練が拭い去れない哀れな敗北者
よっぽど感心がなきゃ流行るかどうかも分からんようなマイナーでマニアックなフレームワークなんて気にもしないだろ
PHPに関するヘイト発言も結局のところこんな仕事辞めてやると息巻いて退職したももも結局PHPしかできるスキルがなくて再就職できない自分への自虐か何かなんだろ? ていうか今更Slim知るって
山奥で暮らしてんのか? 都会人特有のウンコの色でマウントを取ろうとするのはみっともないからやめなさい イヤでイヤで逃げ出した古巣を叩くのは良くある話
そして、実はそこしか居場所がなかった、なんてのも
もし抜け出して上手くいってるなら思い出したくもならんしね PHPに詳しいとこのスレでマウント取れる環境になりつつあるw マウント取るなら
haskell,rust,c++あたりだな。
実際プライドの高い馬鹿が一番多い。 >>469
負け犬ペチPoorの遠吠えが心地よい
ふつうに転職して年収700もらっとるで
ペチPoorな言語なんてもうしばらく見てもいないね
君、禿げたつむじから$が見えとるでw >>477
ruby を勉強している身としては ruby でマウントが取れるかどうかが気になります、実際どうなんでしょうか? スクリプト言語はPythonの勝利で終わった
残念だったな >>479
マウント取るにはやっぱ静的言語。
コンパイル時点で勝負がついてる感をださないかん。
そういうクソみたいなプライド出してくるのが言語マウンティングだから。 Pythonはプログラマは使いたがる反面
顧客から求められる言語としては希少
スクリプトはJavaScriptがここ数年伸びてきてる Javascriptはここ数年がどうのというレベルじゃないでしょおじいちゃんw
政治的に保護された言語だからこういう議論ではジョガイや。 スクレイピングはPythonでやろう!みたいなやついるけど、
どう考えてもJSでやったほうが筋がいいよな それw
js実行後のDOMいじんのつらそう。
なんであんな縛りプレイしてるんだろw
puppeteer最高過ぎるwww
ブラウザ解釈前の操作も解釈後の操作も楽々ww
しかもブラウザのdevToolでDOMやらCSSやら操作する知識まったくそのまま転用できるwww
Google様ありがとうございますありがとうございますwwwww 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歳かよ…どうしてこうなったww いや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エンジンだけど ■ このスレッドは過去ログ倉庫に格納されています