次世代言語Part8[Haskell Rust Kotlin TypeScript]

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

スレタイ以外の言語もok

前スレ
次世代言語Part7[Go Rust Swift Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1508403098/

**デフォルトの名無しさん** · 2017/12/02(土) 13:17:40.53

言語が何であろうと使ったことがないアプリはソース読めないぞ
読む前に使い込むべきだ
使う前に読めると思う方が机上なんだよ

**デフォルトの名無しさん** · 2017/12/02(土) 13:18:04.32

やっぱHaskell入ったんだな。
よっぽど悔しかったんだろうなあ。推しなのに。
AKB総選挙かよw

**デフォルトの名無しさん** · 2017/12/02(土) 13:23:56.16

労力が見合うかは分からないけれど、
大抵のコンパイラはソースも公開されてない？

**デフォルトの名無しさん** · 2017/12/02(土) 13:25:37.97

>>33
>いかにも実際の仕事をしらないお偉いさんが机の上でこねくりまわした感がある

その評言が当てはまるのはHaskellでもなくRustでもなく Go 言語

**デフォルトの名無しさん** · 2017/12/02(土) 13:26:42.90

>>36
まさかMITやAPLとGPLの違いが分からん奴がこのスレにいるとは

**デフォルトの名無しさん** · 2017/12/02(土) 13:27:52.88

>>30
>なんで次世代言語のGPLライセンスは重要って言っただけで

違うだろ
お前さんが >>19 で言ってるのは、コンパイラがGPLでなければ
次世代言語には数えられないってことだったろうよ

**デフォルトの名無しさん** · 2017/12/02(土) 13:30:13.04

>>39
そうだが？
ないと次世代として認めがたいっていうのは要素として重要ってことと矛盾するのか？

**デフォルトの名無しさん** · 2017/12/02(土) 13:32:42.01

あとな、言語屋の端くれとして言わせてもらうと
まあ成果物（特に公的研究機関）の公開の際にGPL採用するって選択肢はほぼないんだわ

**デフォルトの名無しさん** · 2017/12/02(土) 13:34:31.51

>>40

はあ？
>>30 の「言った『だけ』」の「だけ」の部分が大嘘だろうがよ

**デフォルトの名無しさん** · 2017/12/02(土) 13:35:34.51

PHPが相応しいかどうかは知らんが、まあガイジ乙ってこった

**デフォルトの名無しさん** · 2017/12/02(土) 13:37:18.57

結局このスレの住民も、ジョブスの作った快適な牢獄で永久に囚われる方がお好みってか
ほんとディストピアになったな

**デフォルトの名無しさん** · 2017/12/02(土) 13:40:52.41

>>41
HaskellはともかくGoやRust、Typescriptは研究機関の成果物じゃなくて単なる企業の広告塔だろうが……

**デフォルトの名無しさん** · 2017/12/02(土) 13:44:29.43

成果物ではなくて広告塔でもなくて自社製品を作るためにできた副産物だろ。

**デフォルトの名無しさん** · 2017/12/02(土) 13:54:09.27

Rustが研究しているのはジョブズではなく静的型付け
牢獄になるとすれば静的型付けが牢獄になるんだよ

**デフォルトの名無しさん** · 2017/12/02(土) 13:55:36.52

>>44
>結局このスレの住民も、ジョブスの作った快適な牢獄で永久に囚われる方がお好みってか
>ほんとディストピアになったな

あ、ガイジというよりはキチガイのひとだったか

**デフォルトの名無しさん** · 2017/12/02(土) 13:58:37.03

>>47
>牢獄になるとすれば静的型付けが牢獄になるんだよ

一部のLISPer除いてRustの型システムでは型が付かない正当なコードが書きたいのに書けない！なんてやつ殆どいないだろ

**デフォルトの名無しさん** · 2017/12/02(土) 14:36:48.87

静的型付けはQBみたいな奴だ
牢獄と契約は似たようなものと思うか全然違うと思うかは人それぞれ

**デフォルトの名無しさん** · 2017/12/02(土) 15:29:44.21

じゃあどんな言語が好きですか？なぜその言語が
良いと考えるのですか？と聞くとダンマリ。

**デフォルトの名無しさん** · 2017/12/02(土) 15:37:46.07

そんなやついないだろ

**デフォルトの名無しさん** · 2017/12/02(土) 16:02:09.41

>>38
ソース読めれば、ブラックボックス化は
防げるんじゃないの？

あなたが上げてるライセンスで、
ソースを読んではダメってモノは
ない気がするんだけど。

**デフォルトの名無しさん** · 2017/12/02(土) 16:16:44.09

仕様と実装は分けて考えるべき。

**デフォルトの名無しさん** · 2017/12/02(土) 16:25:11.46

厳密に言えば配布されているソースと配布されているバイナリが違う可能性は存在するけどな
わかりやすい罠でも仕込まれてない限り検証不可能だろ、GPLであっても

**デフォルトの名無しさん** · 2017/12/02(土) 17:35:29.54

ライセンスは個人ならMIT、企業ならApacheが主流
緩いライセンスの上で企業が主導するというのが、昨今のオープンソース界隈
オープンソース同士の競争や発展が当たり前になって、落ち着くべきところに落ち着いた

GPLの衰退、寛容なオープンソースライセンスの興隆
https://japan.zdnet.com/article/35058087/
http://redmonk.com/sogrady/2014/11/14/open-source-licenses/

http://redmonk.com/sogrady/2017/01/13/the-state-of-open-source-licensing/
http://redmonk.com/sogrady/2017/09/22/cloud-native-license-choices/

**デフォルトの名無しさん** · 2017/12/02(土) 17:48:55.03

>>53
GPLでない限り、どこかの瞬間にソースをクローズドにできてしまう
その違いくらい分かっとけ

>>56
そういうものは単にソースが公開されているだけで、企業にとって都合の悪いコードは入らない
開発姿勢の問題

**デフォルトの名無しさん** · 2017/12/02(土) 17:54:11.74

コードのソースが公開されていることと、プログラムに対する自由が保証されていることは全く違う

ちょっとは勉強しろ
https://www.gnu.org/philosophy/open-source-misses-the-point.ja.html

**デフォルトの名無しさん** · 2017/12/02(土) 17:54:42.99

クローズドにされた派生物は元のオープンソースにその企業なりの変更を加えたものだろ。
他の人はクローズドにされる前のオープンな方を使い続ければいいだけ。

**デフォルトの名無しさん** · 2017/12/02(土) 18:00:12.16

>>59
元コードのライセンス自体を変えられたらアウト。MITやAPLなら不自由なライセンスに変更することが可能
GPLならそういうことは不可能

**デフォルトの名無しさん** · 2017/12/02(土) 18:05:29.89

今時、GPL真理教のご登場とは、驚きだな。
そういう人は、次世代言語がgccに組み込まれるまで、待ってたらいいと思うよ。

**デフォルトの名無しさん** · 2017/12/02(土) 18:22:10.64

新しく配布するライセンスを変更することはできても、一旦ライセンスされたものを過去に遡って
変更するなんてことはそのライセンス自体にそのような規定がない限り無理。
新しく配布するライセンスを変えるって話なら(その権利がある者なら)元がGPLだろうが可能なのは同じ。

**デフォルトの名無しさん** · 2017/12/02(土) 19:42:01.02

GPLも違反の場合の措置は国の法律に従うとかそんな規約だった気がするから、
国によっては過去に遡って棄却とかあるんじゃねーの？

**デフォルトの名無しさん** · 2017/12/02(土) 20:00:19.24

言語屋の端くれって何者なんだ。
工学博士の端くれぐらいまではギリギリ言ってみようかとも思えるけど、言語屋って凄いな。

**デフォルトの名無しさん** · 2017/12/02(土) 21:01:20.98

こんなところで喚くしか能のないゴミ屑が
ライセンスうんぬんで不利益被るほどの立場なわけないだろ
大人しくプェチピィで下痢糞プリプリしてろよ

**デフォルトの名無しさん** · 2017/12/02(土) 21:01:40.00

>>1
前スレ終盤でも名前挙がってたが、Elmバズってるな
本スレがない言語(Elm Nim Crystal他)もスレタイ候補でいいか

ElixirからElmの流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。
https://ubiteku.oinker.me/2017/12/02/skepticism-about-oo/

**デフォルトの名無しさん** · 2017/12/02(土) 21:16:27.51

OOを批判するのはいいけど消去法で関数型とか思うのは大間違い
消去法するくらいなら対案を何も出さない方が正しい

**デフォルトの名無しさん** · 2017/12/02(土) 22:37:35.51

関数型の定義はよく分からんけど、第一級関数は欲しいな

**デフォルトの名無しさん** · 2017/12/02(土) 23:58:45.47

redux（react）触ったやつがelmに流れてるんだろうな。

js+redux+immutable.jsの組み合わせだったらelmってことかね

**デフォルトの名無しさん** · 2017/12/03(日) 02:09:05.69

「じゃあお前はどんな言語なら満足なんだ」ってしつこく聞かれてるから言うが
次世代言語かって言われたら微妙だからあんま挙げる気はなかったんだが、理想はVala
Cにトランスパイルされるから速度は良好、コンパイラのライセンスはLGPL、構文は比較的モダン

ただ今時の他言語と比較するともう一声ほしい

**デフォルトの名無しさん** · 2017/12/03(日) 02:59:41.58

バラ、初めて聞いたわ
よくそんなマイナー言語知ってるな

**デフォルトの名無しさん** · 2017/12/03(日) 09:08:16.53

GNU狂儲じゃない人にとってはValaなんてC#の劣化コピー未満だし、
C#は現世代言語だから次世代には不適格だろう

**デフォルトの名無しさん** · 2017/12/03(日) 12:08:02.85

その性能を見せてくれたら変わるかもしれんけどな
.NETのメモリを食い尽くす糞戦略GCが無いというならまあ……

Cにトランスパイルされて性能良好という点ではnimと丸かぶりな上
基本的にnimのほうが融通がききそうな気はするけど
GObject互換が有利に働くケース(例えばcairo呼ぶとか)ではValaの方がいいんだろう、たぶん、知らんけど

**デフォルトの名無しさん** · 2017/12/03(日) 15:33:23.03

まあだからValaが次世代言語とは一言も言ってない
例えばNimのコンパイラが(L)GPLになってくれてれば全力で推すよ。でも現実はMITだ

**デフォルトの名無しさん** · 2017/12/03(日) 16:03:56.50

>>60
Linuxなど極一部の例外を除いて、今時のまともなOSSは基本的に全て企業様が開発しており、
寛容にも乞食に対して提供してくださっているものである
GPL信者が主張する、企業が成果物をGPL化するメリットとして、
「コミュニティからの協力を受けられる」というのがあるが、(乞食共の協力がどれだけ役に立つかは別として)これには落とし穴がある
GPLで公開してるものに対して乞食がプルリクを出し、これが本家にマージされた時点で、本家のソースがGPLに感染するということだ
これは企業にとって到底受け入れられるものではない
GPLは企業のオープンソースへの参加の障害になるんだよ

**デフォルトの名無しさん** · 2017/12/03(日) 16:11:23.39

>>75
補足
本家のソースがGPLに感染するというのは、開発元の企業自身が、ソースの使用にあたりGPLに従わなければならなくなるという意味な
成果物をドブに捨てるようなもんだ

**デフォルトの名無しさん** · 2017/12/03(日) 16:16:53.98

そういうものはデュアルライセンスで公開するんじゃないか普通。知らんけど。

**デフォルトの名無しさん** · 2017/12/03(日) 16:17:53.46

逆に考えれば自分がただで作ったものが企業の金もうけに使われるのを防いでるわけだろ。
そういういみでGPLは必要。

**デフォルトの名無しさん** · 2017/12/03(日) 16:32:50.74

>>78
そう。つまりこういうことだ。
ユーザーからのコミットを受け入れるというポジティブな理由でオープンソースを採用するならGPLは不適切。
オラクルのように、有償契約への誘導を前提としてオープンソース版を撒き餌にするなら、
成果物の盗用を防ぐ意味でGPLが適切。
本来OSS信者が批判すべきなのはどちらだろう？
一度落ち着いて考えてみよう。

**デフォルトの名無しさん** · 2017/12/03(日) 16:46:21.13

だから「自由ソフトウェア」と「オープンソースソフトウェア」は違う概念って話だよな
そもそも企業が主導してる開発は、企業の恣意が入るわけで、自由ではない
今は乞食に恵むことが点数になるからそうしてるだけ
乞食に甘んじるならそれでいいかもしれんがな

一念発起して自分の畑を開墾することになったときに、GPLがないと企業に土地を盗まれたり、いつのまにか乞食に占拠されたりするんだよ
だからGPLの言語は重要なんだよ

**デフォルトの名無しさん** · 2017/12/03(日) 16:47:34.26

もっというと、
・プロジェクトにコミットした個人乞食にとって、そのプロジェクトの最新の成果物を継続的に利用できる利益を守るのがGPL
・開発元の企業にとっての利益を守るのが「寛容なライセンス」
ということだ。そして、下記の理由から、後者を優先したほうがOSS全体にとっての利益が大きい。
・一般に、個人より企業の方がOSS遥かに多くの貢献をしているから、企業の参入を促したほうがOSSは拡充する
・当たり前だが、利用者にとっては寛容なライセンスの方が利用しやすい

**デフォルトの名無しさん** · 2017/12/03(日) 16:50:27.91

>>78
別にGPLは金もうけに使うことを防ぐためにあるわけじゃないよ。
実際、金もうけだろうがなんだろうが単純使用については制約を設けることを禁止してるわけだし。

**デフォルトの名無しさん** · 2017/12/03(日) 16:52:07.39

個人で出来る開発なんて限られてるから企業が参入してくれたほうがいいし、企業は慈善団体じゃないんだから利益考えるのは当然だろ
企業がーステマがーって気持ち悪すぎる

**デフォルトの名無しさん** · 2017/12/03(日) 16:54:31.97

これだからワッチョイつけろと言ったのに

**デフォルトの名無しさん** · 2017/12/03(日) 16:58:46.31

この板ってﾜｯﾁｮｲあるの？

**デフォルトの名無しさん** · 2017/12/03(日) 17:00:11.80

わざわざ次世代言語スレに来て、
「俺ルールにより、全ての言語は次世代ではない！！」

ってマ？

**デフォルトの名無しさん** · 2017/12/03(日) 18:06:19.80

GPLは自分が作ったものだけじゃなく使ったものにも影響を及ぼすからなあ
LGPLが一番マトモなんじゃないかと思ってるんだが

**デフォルトの名無しさん** · 2017/12/03(日) 18:39:22.73

>>81
OSSが拡大しても自由ソフトウェアは拡大しない

まあ言語スレでやるべき話題ではそろそろなくなってきてるのはすまん

**デフォルトの名無しさん** · 2017/12/03(日) 18:44:51.43

望まれてないから拡大しないんだ、ってのが分からないところが儲

**デフォルトの名無しさん** · 2017/12/03(日) 18:51:18.78

>>86
いつもの事だよ

**デフォルトの名無しさん** · 2017/12/03(日) 19:06:01.80

>>86
次世代ガイジ

**デフォルトの名無しさん** · 2017/12/03(日) 19:07:55.59

>>19
まあ、大企業がサポートしてるからこそ信頼性が増すんだけどね。
弱小勢力の作ってる言語なんざいつやる気が無くなってサポート停止するかわからんのに
使ってられないよ。

**デフォルトの名無しさん** · 2017/12/03(日) 20:15:24.10

サポートを永久に続けさせたいとは思ってないんじゃないかな
ただ、無料版だけサポート停止して有料版に移行させる手口を防ぐだけでいい

**デフォルトの名無しさん** · 2017/12/03(日) 20:40:28.46

このガイジの言葉を全否定するが、別に言語の処理系のライセンスがGPLだろうと非GPLだろうと
その言語で書かれたプログラムのライセンスには何も影響しない
Javaの処理系がクローズドソースだった時にJavaコードがオープンソースにできなかったかってことを考えればすぐ分かる

言語の仕様がオープンなら、もしこのガイジの懸念どおり処理系をオープン→クローズドソースにされたところで
本当にその言語が有用だったらクローンの処理系が出てくるだけのこと。open-jdkやらmonoが良い例だ

要するにこのガイジ、ライセンスのことを何も分かってない知ったか

**デフォルトの名無しさん** · 2017/12/03(日) 20:46:25.36

ガイジを殴るだけのレスだと何なので
Haxeみたいな「書いた端からあらゆる言語にトランスパイルして使う言語」ってやっぱりコンセプトとして駄目なのかね？
最近のいわゆる次世代言語って、おおむねネイティブ（もしくはJavaマシンコード）にコンパイルする系ばっかのはず
例外はTypescriptとHackくらいか？

**デフォルトの名無しさん** · 2017/12/03(日) 20:55:26.88

93,94をまとめると
GPLなコードを再利用しつつ有料版に移行させるのは無理
コードを捨ててクローンするならOK

**デフォルトの名無しさん** · 2017/12/03(日) 21:05:47.23

>>94
Javaに関しては、openjdkを勝手にフォークして改変したものを出回らせたら特許侵害でオラクルに訴えられるよ
特許の利用はあくまで公式にリリースされたopenjdkに対して認められてるもので、
弄ったらJavaとは認められなくなり即訴訟

**デフォルトの名無しさん** · 2017/12/03(日) 21:19:08.36

>>97
すまん、open-jdkっていうのは不正確だったな。IcedTeaって言った方が正確だった
まあ厳密にはIcedTeaも当時のSunの協力あってのことで、勝手フォークでやった訳ではなかったんだが……

**デフォルトの名無しさん** · 2017/12/03(日) 21:19:33.27

>>95
中間言語のせいで遅くなってる直接アセンブリ(機械語より広い意味で)にできるなら効率的なのにグギギギギ
というのを気にしなければトランスパイラでもいいんじゃね
Typescript→Javascriptぐらいなら気にならんだろ
Scalaとか思いっきりJVMに足を引っ張られてた例と思う

ちょっと話は違うけど可変長配列を値返しできる言語を主にC系のことしか考えてないバックエンドで実装すると
mallocして返すかForthみたいにデータスタックをもう一つ用意するかぐらいしか方法がない、みたいな

**デフォルトの名無しさん** · 2017/12/03(日) 21:29:59.69

書いてからもっといい例を思いついた
トランスパイル先に選ばれそうな言語(CとかJVMとかJavascriptとか)って
どれも末尾呼び出し最適化が保証されてないから関数型言語なら避けたいはず

**デフォルトの名無しさん** · 2017/12/03(日) 21:51:34.72

末尾再起最適化なんかトランスパイルの段階でできるだろ
自分でやってみりゃわかるけど、別の言語への変換って細かい仕様のすり合わせが難しくて
どう頑張っても変換結果は綺麗なコードにはならんよ

**デフォルトの名無しさん** · 2017/12/03(日) 22:16:35.41

>>101
自身への末尾「再帰」は変換できるが、末尾「呼び出し」一般はかなり難しい
特にモジュールをまたぐとまず無理

**デフォルトの名無しさん** · 2017/12/03(日) 22:18:35.13

臭い消しもできないのかID:7jfP6ZRCは

**デフォルトの名無しさん** · 2017/12/03(日) 22:31:58.75

なんだ？誰と間違えられてるんだ？

**デフォルトの名無しさん** · 2017/12/03(日) 23:20:51.54

トランスパイルする時点で全部gotoにしちゃえばいいんじゃねえの？
ヒープは馬鹿でかい配列切り出して貸してやりゃ良いじゃん。
一番現実的だと思うけど。

と言うか間違えられてかわいそうだな。

**デフォルトの名無しさん** · 2017/12/03(日) 23:24:33.80

トランスパイラだから、トランスパイル先の言語の作法を守らにゃならん、なんてトランスパイラは
どっちつかずのゲテモノになるなんてのが歴史的にある程度わかってきたんだから、諦めて超高級マクロアセンブラとして使うべきだと思うが、
やっぱそのトランスパイル先の美しさって必要なのかねぇ。

**デフォルトの名無しさん** · 2017/12/03(日) 23:25:29.18

くっさ

**デフォルトの名無しさん** · 2017/12/03(日) 23:27:40.12

>>90
は臭くなかったのに面白いな。

**デフォルトの名無しさん** · 2017/12/03(日) 23:52:53.39

>>105
ありがとうありがとう

で、goto式だと呼び出し先も含めてひとつの関数にまとめないといけないので
他の関数をtail callしているのがつながって爆発的にコードサイズが膨れ上がる
JVMだと64kbの壁があるとかないとか ttps://togetter.com/li/280057
またモジュールを超えるとアクセス制御にかかったりもする

**デフォルトの名無しさん** · 2017/12/03(日) 23:52:56.38

>>100
javascripというかecmascriptは末尾再帰の最適化は仕様になってる。

**デフォルトの名無しさん** · 2017/12/04(月) 00:00:49.77

>>110
うお本当だ、俺の情報が古かった

**デフォルトの名無しさん** · 2017/12/04(月) 04:42:05.46

Cにはlongjumpがある。
これを使えば親の関数へどこへでも飛んでいける。
末尾再帰もオプションで設定できる。

**デフォルトの名無しさん** · 2017/12/04(月) 08:25:09.89

>>109
JVMだとgotoが相互に飛んでない奴らで一つの関数にまとめるしかないな。
ただ、一つの関数が64kbまで、ってそこそこ余裕あると思うよ。
関数に関数をおさめようとするから爆発的に長くなるというか、実質、関数の後ろにおまけ付いたコードが量産される事になるんだと思う。
呼び出してる側まで全部展開してしまうと割と短くなる。

昔、ホントにそういうトランスパイラ作ったけど、割としっかり動いた。
動的なメモリ確保をほとんどさせられなかったからそうなっただけだけど。

>>112
ホントに高級アセンブラだよなぁ。

**デフォルトの名無しさん** · 2017/12/04(月) 08:30:55.17

くっさNG回避すんな

**デフォルトの名無しさん** · 2017/12/04(月) 09:02:24.71

jsへのトランスパイラは現状、
jsが、webにおける機械語的な立ち位置
だからというのはわかる。

でもcへのトランスパイラってどんな意味があんの？手抜きとしか思えない。

**デフォルトの名無しさん** · 2017/12/04(月) 09:38:18.50

手抜き出来ることはメリットだろ。
実装と仕様は分けて考えるべきだからな。

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

手抜きっつーか、Cに変換しておけば、おおむねどんなlibcでも石でも対応するコンパイラがあるってことでは

GoみたくあらゆるものをGo内で完結させるための車輪の再発明だとか
Rustみたく欲しい環境のtripleがあるかとかtierがいくつだとか
そういう言語機能と直接的には関係ない部分のサポートに関する労力をまるっと切れるのがでかい

一時期のaltJavaやaltJSの乱立を見てると、その分言語の質が上がるかって言われたら怪しいけどな

あとllvmの台頭で、ある程度その辺を再利用できる環境が整ったから、直接機械語吐いた方がよくなりつつあるのもあるか

**デフォルトの名無しさん** · 2017/12/04(月) 10:54:56.82

>>117
自分で言ってんじゃん。
llvmだったら中間コードまでのトランスパイラ作れば最適化とバイナリはくまでやってくれるしそこまでやりゃ良いのに。

あとgoの車輪の再発明はありだと思う。
画像変換したくてimagemagicのlibに依存する羽目になるとか勘弁。

**デフォルトの名無しさん** · 2017/12/04(月) 11:02:06.37

車輪の再開発はありとか自分が作る立場でも同じこと言えんの

**デフォルトの名無しさん** · 2017/12/04(月) 11:02:26.62

>>115
最適化とかそういう所にそれほど苦労しなくなるかな
手抜きといえば手抜きなんだけど

gccをバックエンドにするなら変な石対応が簡単だし
vc++でも食えるように書けばWindowsでも余計なもの要らないし
intelのコンパイラでゴリゴリに最適化かけたりとか、
静的ビルドでワンバイナリ作りたいからCの方のコンパイルオプションでリンクしよう、とか
既存の処理系に乗っかるのはメリット多いと思う

**デフォルトの名無しさん** · 2017/12/04(月) 11:39:21.16

>>118
llvmが台頭してきたから相対的にCトランスパイルの魅力なくなってきたよなって話で、
昔はCトランスパイラで既存のコンパイル環境に乗っかるのがよく行われてたって歴史的な話な

gccが中間言語仕様を意図的に隠してた弊害とも言える

**デフォルトの名無しさん** · 2017/12/04(月) 13:22:03.65

手抜きを批判する奴おるｗ

**デフォルトの名無しさん** · 2017/12/04(月) 23:23:47.01

実質的にはトランスパイルだろうが何だろうが、とりあえずは関係ないが
今時ライブラリ構築を0からするというのは自分一人が使う自分専用言語だと考えても
汎用言語としてはあり得なくて、何か既存の言語のソレにフリーライドせざるを得ないわけで
となれば何に乗っかるかという部分から考えるし
それが決まってから具体的な実装方を考えるし、なんだったら自動的に決まってくるわけで

余談だが、良くある乗っかり先としては、CとJavaと.NetとJSがあるが・・・
ただ、例えばネイディブコードが良いと考えてC言語系のライブラリに乗っかるとして
C言語のABIはかなり古臭いわけで、あと、ヘッダファイルの存在がかなりエグイわけで
(windows.hをそのまま読み込める自作コンパイラとか書ける気がしない)
その言語で何かCのライブラリを使いたいときCヘッダファイルを適切に移植したのち
使いやすくするためにラッパークラスまで書くとしたら
これはもう多少気に入らない部分があってもC++を使ったほうが楽だし
ヘッダを移植するツールで自動生成する方針でも古臭いCのAPIを直接叩くのなら
何のための新言語か分からないし、だからといってラッパー書くのはバカらしいし
大概のCライブラリにはC++のヘッダも付いてることを考えるとそのままC++使ったｂﾙうがマシ
もしC言語のヘッダを直接読めるように言語を設計するとなるとマクロなども考えると
C言語と文法的に互換性が有るように言語を作らなければならないということで
これまたあまり作る意味が無い、というか多分C++

**デフォルトの名無しさん** · 2017/12/04(月) 23:36:03.78

なんで、素晴らしい言語仕様を考えることは出来るかもしれないし
頑張ってコンパイラを作ることも可能かもしれないが
結局ライブラリをどうするのかという部分が一番の問題で
0から構築するのはあり得ないから何かに乗っかるわけだが
当然乗っかり先の制約を受ける
特にネイティブコード系は一番普及しているABIがC言語のソレであり
気に入らないのでひたすらラップしまくる日々か
諦めて次世代言語の機能を生かせずアンセーフとか言っちゃって直接叩くか

**デフォルトの名無しさん** · 2017/12/05(火) 07:59:12.87

次世代言語はコレだろ
https://arstechnica.com/gadgets/2017/09/microsoft-quantum-toolkit/

**デフォルトの名無しさん** · 2017/12/05(火) 08:02:00.55

M$サーバでしか動かない言語はNG

**デフォルトの名無しさん** · 2017/12/05(火) 11:01:11.59

Wiｎ鯖で運用されない = Win鯖で使えない
だからな
リーナスが死んだら終わりな言語とかよく使えるな

**デフォルトの名無しさん** · 2017/12/05(火) 11:03:08.63

リーナス死んだらUnixサーバー終了ってマ？

**デフォルトの名無しさん** · 2017/12/05(火) 14:15:20.69

どうでもいいが長すぎる文章は読まないからな。もっと要約して話せ

**デフォルトの名無しさん** · 2017/12/05(火) 14:25:30.36

あのスペースホルダー邪魔だよな

**デフォルトの名無しさん** · 2017/12/05(火) 15:43:17.12

AutoMLが次世代言語らしいな。

**デフォルトの名無しさん** · 2017/12/05(火) 19:36:47.33

>>127
君の言っている意味がよくわからない。
言語？

**デフォルトの名無しさん** · 2017/12/05(火) 21:42:34.05

>>128
今のリーナスは、リリース担当兼広報。

実際のリリーススケジュールとか開発機能とかは
スポンサーの企業が決めている。