次世代言語Part7[Go Rust Swift Kotlin TypeScript]

**デフォルトの名無しさん** · 2017/10/19(木) 17:51:38.66

文字数制限きついので改題
スレタイ以外の言語もok

前スレ
次世代言語議論スレ[Rust Kotlin Haskell]第6世代
http://mevius.5ch.net/test/read.cgi/tech/1503924817/

**デフォルトの名無しさん** · 2017/11/30(木) 22:56:29.10

まだフルHDに対応できてないニコ動

あ · 2017/11/30(木) 22:59:11.95

c11が実行できるところだと実行できると思う。pfの便利さもわかる。
ideoneはc11が動かんからcでは確認できないけど、c++14だと動いた。
https://ideone.com/0PBzBG
このままtest.cでも動くんじゃないかな。
スマホからでほかの環境めんどくさくて見てない。ごめん。

**デフォルトの名無しさん** · 2017/11/30(木) 23:01:14.04

>>973
あー。いや。マクロ動かないのは完全に俺が悪かった。申し訳ない

あ · 2017/11/30(木) 23:01:40.03

>>970
知ってるよ。利点は。lispまだ使ってるしな。

>>971
それより、maxとminと、min_not_zeroの方が好き。

あ · 2017/11/30(木) 23:03:30.70

>>974
これは俺も煽って申し訳ない。

**デフォルトの名無しさん** · 2017/11/30(木) 23:09:55.30

そういやプリプロセッサが乗ってる言語って最新の言語では見ないよな。
Go言語は意図的に削ったのは分かるんだけど(コンパイル速度優先のため)
他のはどういう理由なんだろうな。swiftとかあったほうがいいと思うんだが

**デフォルトの名無しさん** · 2017/11/30(木) 23:14:35.31

構文として統合されたマクロならむしろ盛況な気がする
DやTemplate Haskellやcamlp[45]が散々こねくりまわして、nimにもrustにも
Cプリプロセッサのような、言語からも独立して使えるようなマクロはないけどさ

**デフォルトの名無しさん** · 2017/11/30(木) 23:20:37.73

>>977
単純にダサいからだよ
言語設計者にとってみれば、自分の言語はテキストマクロに頼らないと使い物にならないゴミですと恥を晒してるようなもんだ

**デフォルトの名無しさん** · 2017/11/30(木) 23:30:56.56

まあC言語のポータビリティの高さはマクロがテキストマクロってことが大きい
構文マクロだと、複数のコンパイラによって拡張構文がちょっとずつ違うみたいな状況には対応できん
次世代言語が実用に耐えてるのは処理系が「まだ」ひとつしかないって面もあると思う

**デフォルトの名無しさん** · 2017/12/01(金) 04:30:35.34

Cのマクロは性能低いからな。
ワンパスだしな。

**デフォルトの名無しさん** · 2017/12/01(金) 07:30:06.98

>>945
すまんが今来た俺もお前が手抜き過ぎると思うわ
分かんないなら無闇に質問するんじゃなく勉強するか
じふには理解できないものと諦めろよ。
自分に理解できないのは相手が悪いみたいな態度は、
もっとこう、なんでも分かる人にしか許されないと思うぞ
それに相手ちゃんと質問に詳しく答えてくれてるじゃん。
以上。

**デフォルトの名無しさん** · 2017/12/01(金) 08:36:21.42

どうせあが言ってる事はまた理解できない事だろうから、俺が理解できないのもこいつが悪いに違いない
まあ仕方無いかもしれないな

**デフォルトの名無しさん** · 2017/12/01(金) 08:45:25.80

cのマクロで言いたかったことは
別にcのマクロが良いものだって話ではなくて、
高級な機能のマクロでバカが作ったものより
低級な機能でも優秀な人が作った枯れた技術のが安定するってことなんだけどな。

**デフォルトの名無しさん** · 2017/12/01(金) 09:35:14.98

>>977
include 処理とか, Boost みたいに高級な事すると恐ろしいコンパイル時間になることが分かったからでしょ。
あれのせいでファイル分割しないのがベストなプログラミングとかいう奴まで出始めたわけで。。

まあそういう実験所を提供してるってのはc++の良いところな気もするけどね。
実験に巻き込まれたくはないけど。

**デフォルトの名無しさん** · 2017/12/01(金) 10:04:19.13

あと話してると混乱するからしゃーない

**デフォルトの名無しさん** · 2017/12/01(金) 10:26:42.51

>>985
>include 処理とか, Boost みたいに高級な事すると恐ろしいコンパイル時間になることが分かったからでしょ。
これ。
インクルード処理にマクロを使ってるからな。
例えばpsコマンドのソースをコンパイルする時<sys/stat.h>を37回includeしようとするらしい。
こういうのがソースの依存関係が大きくなるに従って指数関数的に増えていく。
結果としてコンパイルに40分とかかかるように。

Goは上記のコンパイルの無駄な時間から生まれたらしい。

詳細は
https://talks.golang.org/2012/splash.article

**デフォルトの名無しさん** · 2017/12/01(金) 11:14:31.93

４０分とか掛かるのはPSの話じゃないし、
４０分が３０分くらいに短縮したってだけじゃん。

**デフォルトの名無しさん** · 2017/12/01(金) 16:40:31.22

マトモな実用OSでC以外の言語で記述したの
何かある？

**デフォルトの名無しさん** · 2017/12/01(金) 17:05:34.67

つ Windows

**デフォルトの名無しさん** · 2017/12/01(金) 18:24:31.52

次スレのタイトル考えた
現行のままでもいいけど
文字数制限(48byte)には注意

次世代言語Part8[Elm Nim Julia Elixir Crystal]
次世代言語Part8[C#7.2 C++17 Java9 ES2017 PHP7.2] (他Python3.6)

**デフォルトの名無しさん** · 2017/12/01(金) 18:43:38.78

次世代言語議論スレ[略]
で良いじゃん、毎度揉めるなら。
2ぐらいに各言語入れとけば？

**デフォルトの名無しさん** · 2017/12/01(金) 19:35:24.94

sで始まるウンコ言語が入ってなかったら何でもいい

**デフォルトの名無しさん** · 2017/12/01(金) 19:46:14.85

Scratchか

**デフォルトの名無しさん** · 2017/12/01(金) 19:49:58.10

scheme?

**デフォルトの名無しさん** · 2017/12/01(金) 20:23:48.63

メジャー言語はいらないと思う
代わりにRustやSwift, Kotlin, Hack等の新興言語入れればいい

**デフォルトの名無しさん** · 2017/12/01(金) 21:30:52.08

いやHACKは無いわ

**デフォルトの名無しさん** · 2017/12/01(金) 21:44:59.50

ぜんぶメジャーだろ

**デフォルトの名無しさん** · 2017/12/01(金) 22:03:57.26

hackはnull安全だからあり。　
elmも仲間に入れて

**デフォルトの名無しさん** · 2017/12/01(金) 22:32:36.12

ワッチョイよろ

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 43日 4時間 40分 58秒