次世代言語14 Go Rust Swift Kotlin TypeScript

2018/09/11(火) 20:07:34.76

スレタイ以外の言語も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

2018/12/09(日) 11:22:13.88

>>787
あー、そのへん変な事言ったかもしれん。

2018/12/09(日) 11:33:11.22

ああ分かったうるう秒NGワードに入れとく

2018/12/09(日) 11:53:59.09

うるうる秒ンゴ

2018/12/09(日) 13:46:20.62

年齢の法律考えたやつはちょっと定義について悩み過ぎたんだろ。
当日→2/29は毎年存在しない
翌日→2/28日生まれの人が誕生日が変わってしまう
前日→毎年ある！でも初年が一日足りない…
前日の終わる瞬間に歳取ることにしたら帳尻合う！

2018/12/09(日) 14:01:00.60

翌日の始まった直後でええやんけ。
役人はバカだなｗｗｗｗｗ

2018/12/09(日) 17:09:34.91

新元号に盛り上がり求める連中だぞ
誕生日なんて激盛り仕様にせなあかんやろ
その日だけ0.5歳プラスのハッピーバースデーくらいの盛り上がりが必要

2018/12/09(日) 21:00:54.06

https://mevius.5ch.net/test/read.cgi/tech/1538096947/55-56
https://mevius.5ch.net/test/read.cgi/tech/1538096947/68

うるう秒について語りたいなら
最低でもｵﾚの課題ができてからになる

うるう秒の課題にいくまえの
ﾌｧｰｽﾄｽﾃｯﾌﾟの課題すら完全な正答ができたﾔﾂがいないんだからな

うるう秒について分かってるのはこの板には間違いなく一匹もいない

**デフォルトの名無しさん** (ｱﾒ MMb5-FdCK) · 2018/12/09(日) 21:22:09.95

SoftwareDesign今月号のステマはやめろ！

2018/12/09(日) 21:33:27.61

>>799
いい加減黙れよ、低スペ。

2018/12/09(日) 21:34:15.33

低学歴知恵遅れはほどほどにしとかないとな

2018/12/09(日) 21:34:54.71

ｻﾏｰﾀｲﾑｽﾚでさんざんﾊｼﾞかいてるくせに

2018/12/09(日) 21:40:08.61

もしかして半角さん、実は低学歴で就職先も良くない所だから、とりあえず誰かを貶めて安心したいのかな？
だとしたら可哀想な事したなぁ。

2018/12/09(日) 21:41:17.75

低学歴知恵遅れにはそうみえるらしいな
まず低学歴知恵遅れとは意思疎通が成立しない
異なる言語で話してるからな

2018/12/09(日) 21:41:25.89

まぁGoがスクリプト言語なんて言う恥のかきかたした人間の発言権なんか一生ないわなw

2018/12/09(日) 21:43:10.31

疎通できないならどうして疎通できないとわかってて話すの？
馬鹿なのかな？
賢い人は馬鹿に合わせて話せるけど、馬鹿は賢いフリはできないんだから、
意思疎通が成立しないって言ったほうが馬鹿なんだけどなぁ。
自己矛盾に気づかないなんて低能だなぁ。

2018/12/09(日) 21:43:45.87

まず低学歴知恵遅れは
自分が低学歴で知能が著しく低いという自覚がない
しかも自己評価だけは高い

ｺﾚは底辺であるほどその傾向が高くなる

ｺｲﾂの場合、
この有力な仮説が完璧にあてはまるよいｻﾝﾌﾟﾙになってるといっていい

2018/12/09(日) 23:08:44.47

PHPerがPHPしか書けないのって、あのゴミみたい・・・
いや紛うことなきゴミの標準関数群のせいだよな
あんなのに慣れたら、まぁロクでもないゴミグラマーができあがるのは仕方ない

2018/12/10(月) 00:06:08.67

array_* が本当に酷いのは確か

2018/12/10(月) 08:49:10.00

結局は状況設定と場合分けで終わる話か
つーかプログラミング自慢でこのレベルがアピールになると思ってんのが辛い
的外れなところをほじくり返しててヒマそうに見える

2018/12/11(火) 01:00:15.75

年齢知るなら単純計算でいいんだけど
似非科学のバイオリズムでは誕生日からの経過日数だからチョー面倒臭い

2018/12/11(火) 07:52:15.16

日数はDate.getTimeとかの数値から直接計算出来るからむしろシンプルだよ

2018/12/11(火) 07:56:10.73

チョー面倒と言ってる相手にそれで通じるかな…

2018/12/11(火) 15:03:51.85

数値化できるならそれが上策
数値化を自分でやらないとならない言語は面倒なんだ

2018/12/11(火) 15:07:48.07

ホラ通じないから架空の言語を想定して批判始めたぞw
具体的になんの言語の DateTime 型だとチョー面倒なの？

2018/12/11(火) 22:19:21.32

誕生日からの経過日数なら
それこそどんなｼﾘｱﾙ値でもいいからｼﾘｱﾙ値使ったほうが簡単

ｼﾘｱﾙ値使えない言語なんかあんのか

ただの引き算で済むからな
posix timeを使うならこんだけだからな

<いまの posix time> - <一番最近の誕生日のposix time> ←　ｺﾚで経過秒数になる
あとは 60 * 60 * 24 秒で除算するだけ

**デフォルトの名無しさん** (ｱﾒ MMb5-FdCK) · 2018/12/11(火) 23:51:42.60

2/29生まれの人の3/1現在の経過日数はどうやるの？煽ってる訳じゃなく。

2018/12/12(水) 00:08:46.78

↓このｿｰｽがなにやってるか分かるなら分かる
https://ideone.com/LAqADW

2018/12/12(水) 02:07:50.56

新言語ｽﾚに
それが
どういう関係があるのか

2018/12/12(水) 04:15:31.67

もういい加減閏年計算スレでも立ててそこでやれよ

2018/12/12(水) 04:29:41.44

>>818
Smalltalkの場合
('3/1/2018' asDate - '2/29/2016' asDate) days
結果は 731 で合ってる？

2018/12/12(水) 05:56:35.54

>>816
次世代言語ではないし、DateTime型なんて無い言語だよ
そのような日付や時刻をシリアル化できるなら最初からレスしないよ
そもそも前提がおかしい
今後登場する次世代言語全てにDateTime型があるような固定観念持ってるようだけど、そんな考えでいいの？
構文が違うだけで、中身一緒みたいな前提じゃないか

2018/12/12(水) 06:04:13.30

だからいい加減よそでやれって

2018/12/12(水) 07:47:44.12

シリアル化というか普通はシリアル値(ただの整数型)がまずあって
それに加えてシリアル値から年月日、および逆変換する関数が用意されてるかどうかだと思うけど

2018/12/12(水) 09:19:57.26

こんなどーでもいい事にスレを消費するなしw

2018/12/12(水) 10:15:12.20

そもそも半角くんって次世代言語触ってないっしょ

2018/12/12(水) 11:15:40.97

Goをスクリプト言語だと思ってたぐらいだからね。

2018/12/12(水) 12:13:30.43

Dなら確かにrdmdでスクリプト言語的な使い方もできるけどね
Goのそれは公式じゃなかった気がする

2018/12/12(水) 14:11:45.79

スクリプト言語はこれだから、って文脈から発覚したことだから、応用でも何でもなく無知だよ。

2018/12/12(水) 21:23:30.71

低学歴の知ってる（）というのは
電車の型式知ってる（）という程度のもんだからな

低学歴のﾚｽはすぐにわかるわ

2018/12/12(水) 21:25:22.09

低学歴だと思ってる人間が知ってるそれすら知らなかったなんて滅茶苦茶みっともないなw

2018/12/12(水) 22:39:08.10

誕生日がきたらageテーブルをインクルードするだけだろ
バカなのか？

**デフォルトの名無しさん** (ｱﾒ MM47-KgdI) · 2018/12/13(木) 19:02:58.16

TIOBEプログラミング言語ランキング
https://news.mynavi.jp/article/20181212-739645/

TOP10の内、実にC言語系統の文法が７席を占めている。
なぜC系文法はこんなにも受け入れられてしまったのか！？
PythonとVBには頑張ってもらいたい。

2018/12/13(木) 22:01:44.84

PythonはC系だよ

2018/12/13(木) 22:23:08.96

PythonはPythonだけじゃ遅すぎてクソなのがクソ

2018/12/13(木) 22:39:02.47

ランタイム速度が必要なとこだけ必要な言語で書くという判断ができない奴がクソ。

2018/12/14(金) 00:12:40.74

判断ができない奴が居たとすればそれはクソかもしれないがもし判断しなくていいならばそっちの方が楽だろうな？

2018/12/14(金) 08:20:56.21

判断させるのがクソだとわからないのがイキりミッドコア勢

2018/12/14(金) 08:32:31.69

低レイヤー次世代言語Rust、Go、D、C++20

2018/12/14(金) 09:40:25.00

C++20はモジュールもネットワークもコルーチンも延期されそうですが次世代ですか？

2018/12/14(金) 10:42:14.01

コ、コンセプト...

2018/12/14(金) 22:02:52.21

>>839
そのレベルで判断したくないならプログラムなんてやるべきじゃないな。

2018/12/14(金) 22:25:55.77

ネイティブ叩いて性能だしたいからc++使ってるわけで
プラットフォーム抽象化する標準ライブラリは特にいらんなぁ
モジュールはほしい
でもあれ無理だろ

2018/12/15(土) 02:47:16.47

C#はいいとして、F#やP#、Q#、MSは#付けないと気がすまないのか？

2018/12/15(土) 03:08:04.79

そうだよ

2018/12/15(土) 07:30:04.87

>>843
判断するポイントを減らしたいと思わないプログラマーはこの世界に存在しちゃいけないレベル

2018/12/15(土) 09:56:17.69

>>847
意味のある判断とそうでない判断がある
Rubyのように「どっちが美しいか」みたいな判断をステートメント毎に迫る言語はクソ

2018/12/15(土) 09:57:01.97

>>847
判断を減らすのと、判断すべきところを判断しないのは全然別で、
ランタイム速度上げるところの見極めは明らかにプログラマが判断すべきポイントだろう。
そこまで思考停止されるのは現場としては相当困る。

2018/12/15(土) 10:16:23.45

>>849
二重ループの度にいちいち首傾げなきゃいけない言語と、本当にコアな部分だけ注視すれば済む言語とでは、
判断を要する閾値が全然違っていて、それが低すぎる言語はクソってことだろ

2018/12/15(土) 10:24:02.01

SQLとHTMLをゲロゲロするだけならどうでもいいけど、ちょっとCPUバウンドな処理の多めなものを書くなら、
スクリプト言語のパフォーマンスを心配するのは本当に煩わしい
Cと一桁違わない程度の速さの言語ならだいたいは力押しで十分問題なく動くわけだが、
無理にスクリプト言語でやろうとしてアルゴリズムのチューニングとかFFIとかしてたら
結局最初から全部静的型で書いたほうが早かったんじゃないかと思うことはよくある

2018/12/15(土) 10:33:57.01

>>850
その二重ループの中で何がコアなのかなんて作るものによるとしか言いようがない。
行列演算のコア部分と、ビジネスルールによるロジック部分では明らかに求められる書き方や注意すべき点は異なる。
作るものに合ってる言語使えとしか言いようがないし、それを判断するのは普通はプログラマのセンスだろ。

2018/12/15(土) 10:39:44.68

>>852
だからそういうことを言ってるんじゃないの
あんたは全メソッドをいちいちプロファイル取ってCで書き直すべきか検討してるの？
そこはそれこそ「プログラマのセンス」で明らかに問題のなさそうなものについては無意識にだいたいフィルタをかけるだろう
スクリプト言語ではそのフィルタの閾値を大幅に下げなければならないということだよ

2018/12/15(土) 10:55:58.70

>>853
そのプログラマのセンスとやらで、
スクリプト言語で事足りる用途でだけスクリプト言語を選択すればいいだけだろ。
スクリプト言語自体が糞なのではなく、不適切な用途にスクリプト言語を選択するプログラマが糞なだけ。

2018/12/15(土) 21:10:51.66

まぁそういう「適切な所でCとか使いましょうね」ってPythonに対して「全部同じ言語で書けた方が嬉しいでしょ」って発生したきたのがJuliaでしょ？一側面だけど

2018/12/15(土) 21:11:13.42

したきた→してきた

2018/12/15(土) 21:17:55.12

逆だと思う
JuliaはLLの適用範囲を広げようとしたのではなく、コアももうちょっとライトに書こうぜ、というアプローチ
あくまでコアを書く言語であることには違いなくて、スクリプト言語を排除するものではない

2018/12/15(土) 21:24:31.79

juliaはさらにより数式記述に近づけようって感じでないの？
それがいいかは微妙な気はするけど。

2018/12/15(土) 21:35:17.11

JuliaはFortranがいかにオーパーツだったかを世に知らしめただけだったな
今時の学者がFortranを知らずにFortranと同じ用途の言語を作ろうとしたら、出来上がったのはFortranそのものだったんだから

2018/12/15(土) 21:49:53.32

ちゃんと断ってるけどあくまで一側面だから >>855 と >>857 は両立すると思ってるよ

Juliaの発生のコアは計算科学分野のLisp/Fortran/C、Matlab/Pythonのいいとこ取りをしたいよねって話なのは公式見解なんだしそこにはどちらも存在してると思うな

どっちがよりコアに近いかという議論がしたいならどうぞ

2018/12/15(土) 23:07:08.26

一つの言語で済ませたいってのはわかるけどやっぱりただの願望の域を出ないなと思うわ。

2018/12/16(日) 01:41:56.96

低級言語とか高級言語とか、パワーがあるとかないとか
この辺の概念が分かってたら最強の言語なんて言わない気がする

2018/12/16(日) 07:42:58.51

JuliaはJupyter上で開発できるのが強すぎるからFortranとは言い難い

2018/12/16(日) 09:08:33.69

「Jupyterで開発」っていうのがよくわからないんだけど
Jupyter上でJuliaのパッケージをテスト・デバッグして
公開するとかの一連のIDE的な作業を完結できるってこと？

2018/12/16(日) 09:19:37.64

Jupyter使うような連中のアウトプットはプログラムではなくレポート

2018/12/16(日) 10:25:28.93

実験をぐるぐる回して手法を確立するのが目的で便利にしようとしたのがJupyter
そういった手法を実プロダクトに持ち込むのが目的で便利にしようとしたのが各種IDE

これは個人のお気持ちだし凄く乱暴な言い方だけど、インタプリタ的用途のインタラクティブ性を便利にしていったのと、コンパイラ的用途の確実性を便利にしていったのとの違いみたいな

2018/12/16(日) 12:22:37.80

>>845
J#も

2018/12/16(日) 12:57:26.00

IDE、エディタ界、全てを統べて伝説に至ったVSCodeこそが最強
ジュピター？イデオン？ご冗談を（笑）

2018/12/16(日) 14:14:54.72

Lispはさておき
そこらの言語向けIDEの特に動的・ランタイム時の便利機能は
Smalltalk IDEのワナビーだと思ってが違うのか？
一時期はやったEclispeなんかもろその系統（IBMのVisualAge Smalltalkの技術応用）だし

2018/12/16(日) 17:27:05.95

smallltalkとかおじいちゃんかよ
もう棺で眠る時間だよ？

2018/12/16(日) 17:34:22.26

smalllltalkはオーパーツ。言語に最適なOSごと作るみたいなもん。

2018/12/16(日) 20:20:37.50

それ誤解だと思う
smallllltalkで書いた成果物(alto用のOSやシェル)を同じ名前で呼んでるだけ
「java javac jvm」を「java java java」って呼んでるようなもん

2018/12/16(日) 20:46:40.33

javaは言語、javacはバイトコードへのコンパイラ、jvmはバイトコードインタープリタだよね？

Smalltalkはjavacに相当するものがSmalltalk自身で書かれているクラス（Compiler）で
SqueakやPharoなど一部の処理系ではjvmに相当するものもSmalltalk自身で開発されている
（デバッグまでやって、リリースはC言語に変換後、各OS向けバイナリーにコンパイル＆ビルド）
ところと、グラフィックス描画ルーチンをjvmに相当するものが含むところがちょっと違うだけで基本同じだよ

ああ、でも前述コンパイラも含め、IDE等ランタイム時に必要なオブジェクト群はすべて
「仮想イメージ」と呼ばれる簡易オブジェクトストアに永続化されているところはかなり違うか…

**デフォルトの名無しさん** (ｱﾒ MM47-KgdI) · 2018/12/16(日) 20:47:12.06

一部を取り出してそれがsmalllllltalkだと考えるからおかしくなるんだな。
すべての成果物を含んだエコシステム全体がsmallllllltalkだ！

2018/12/16(日) 20:51:13.53

いつまで死んだ言語smallllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllltalkの話をしているの？

2018/12/16(日) 22:32:31.24

死んだ言語のが今から見ると逆に新しさを感じるからじゃね？

2018/12/17(月) 00:18:04.05

結果的に同じ機能に終着したものも全部ワナビー扱いするのは流石に妄想乙って感じ
数年前くらいにGCやマクロはLispがやってきたこと！って喧伝してる人間を見たんだけど全くおんなじ事やってんな

今となっちゃ無意味な主張よ
それが真実であってもね

2018/12/17(月) 00:21:09.74

収斂進化と言います

2018/12/17(月) 01:58:45.34

つまりオリジナルを知る者がいなくなるくらい十分時間が経ってからパクれば
ワナビーも立派なオリジナルになれる！というわけか
確かに勝者が歴史を書き換えてきた常を鑑みても、なるほどそれは一理ある

ただ生物ならともかく、こと同じ分野の人間が関わる技術において
よほど不勉強なおオマケさんが奇跡的な単発ヒットを飛ばすんでもなければ
収斂進化なんてことはそうそう起こらないよ
複合的技術の組合せならなおさら状況証拠的にみればたいていは真っ黒だ

2018/12/17(月) 06:58:23.80

>>879
おっと、ルビーの悪口はそこまでだ！

2018/12/17(月) 08:44:00.03

はいはいオリジナルすごいすごい
で、そのオリジナルって奴はどんなアドバンテージがあるんだ？

ってなる訳ですよ
技術ベースがあるから真っ黒だのワナビーだの言われちゃ気分も悪くなるさ
大体ワナビーの意味分かってる？ワナビーだったら今採用されてる類似機能は、Smalltalkがそこそこ知名度あった時にこぞって実装されてなきゃおかしいとおじさん思うなぁ

2018/12/17(月) 09:54:36.69

>>881
>ってなる訳ですよ

たまにはSmalltalkのことも思い出してやってくれ…程度の話になぜそうもかみつくのか？
と思ったらこんな↓ふうに真に受けたのか。中年のくせにナイーブだな…

>技術ベースがあるから真っ黒だのワナビーだの言われちゃ気分も悪くなるさ

生物の話ならともかく技術畑で収斂進化とかいうエクスキューズは（ほぼ）通じないって一般論だろ

>そこそこ知名度あった時にこぞって実装されてなきゃおかしいとおじさん思うなぁ

それは便利だと気付くのに時間がかかったり、選択可能なアプローチに差異があって
模倣可能になるのに（つまりコストに見合うようになるのに）時間がかかることもあるから
一概には言えないと思うなぁおじさんは

2018/12/17(月) 10:09:54.24

>>882
それはワナビーではないでしょって話だよ
便利だと気付いてコストに見合わせて実装したんなら

真に受けてナイーブになってるとか言ってくるけど、文字しかない場で言い回しに気を遣わない奴は嫌いだよ

2018/12/17(月) 11:36:04.93

アスペスレ

2018/12/17(月) 14:15:40.62

>>881
オリジナルのアドバンテージを大局的に理解できないからワナビーなんだろ？
まずは自分の理解力を上げろ。
話はお前の理解力が70年代の先達に追いついてからだ。

2018/12/17(月) 14:26:16.13

またそういう言い方すると…

2018/12/17(月) 17:20:49.39

>>885
それはよく分からないな
オリジナルに存在しているからと0から100まで実装する方が、オリジナルから必要だと判断した物を切り出して有効活用するよりワナビーだと思うのだが

使われている言語や分野が違うからこそオリジナルの総体と100%一致はしないし、そうして部分を切り出すという判断をできている方がよっぼど大局的とは思わんかね

2018/12/17(月) 18:30:32.13

>>887
> オリジナルに存在しているからと0から100まで実装する
> オリジナルから必要だと判断した物を切り出して有効活用

いずれにせよパチり前提なのが笑える
「判断」「有効活用」とか言えば格好いいけど、けっきょくどっちもワナビーだろう？

効率的なコーディングを支えるに必要な機能が何か？を突き詰める際に
Smalltalkと真逆の早期結合を目指すならなおさらそれに即した他のやり方があるはずで
ワナビーじゃないものからは（そもそも既存に似通うのがおかしいし、仮に似通っても）オリジナリティが自ずとにじみ出るものだよ

2018/12/17(月) 19:22:24.64

>>888
ワナビーが揶揄の意味を持っていてそれはヤリタカッタダケに対する批判だと思っているので、有効性の判断という思考が挟まってる時点で違うと思っているというのは今まで言ってきた通りだし、君の言い回しには合わないようだ

滲み出すオリジナリティという観点では（これは私の無知故なので是非ご教授願いたいのだが）Smalltalkにおいてソースコード・思考過程のメモ・グラフや演算結果を一纏めにして閲覧・編集可能なツールは存在しているのかい？
もしなければその観点でJupyter Notebookはオリジナリティを持っていると思うがそれはどうだろうか？

2018/12/17(月) 19:53:03.75

>>889
Jupyter Notebookがオリジナルって時点でもうHPゼロよ
mathematica nextstepでググってみるといいよ

IDEのオリジナリティを語る前に70～80年代を旅しておいで

2018/12/17(月) 20:09:51.12

>>890
OK私が無知だった
出直してくる

◆QZaw55cn4c (ﾜｯﾁｮｲ aa60-D8NS) · 2018/12/17(月) 21:04:04.95

>>877
＞GCやマクロはLispがやってきたこと！
あさはかな私のナイーブな意見では、Lisp のマクロを超える存在はまだ現れていないのでは？