次世代言語Part8[Haskell Rust Kotlin TypeScript]
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok
前スレ
次世代言語Part7[Go Rust Swift Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1508403098/ ガイジを殴るだけのレスだと何なので
Haxeみたいな「書いた端からあらゆる言語にトランスパイルして使う言語」ってやっぱりコンセプトとして駄目なのかね?
最近のいわゆる次世代言語って、おおむねネイティブ(もしくはJavaマシンコード)にコンパイルする系ばっかのはず
例外はTypescriptとHackくらいか? 93,94をまとめると
GPLなコードを再利用しつつ有料版に移行させるのは無理
コードを捨ててクローンするならOK >>94
Javaに関しては、openjdkを勝手にフォークして改変したものを出回らせたら特許侵害でオラクルに訴えられるよ
特許の利用はあくまで公式にリリースされたopenjdkに対して認められてるもので、
弄ったらJavaとは認められなくなり即訴訟 >>97
すまん、open-jdkっていうのは不正確だったな。IcedTeaって言った方が正確だった
まあ厳密にはIcedTeaも当時のSunの協力あってのことで、勝手フォークでやった訳ではなかったんだが…… >>95
中間言語のせいで遅くなってる直接アセンブリ(機械語より広い意味で)にできるなら効率的なのにグギギギギ
というのを気にしなければトランスパイラでもいいんじゃね
Typescript→Javascriptぐらいなら気にならんだろ
Scalaとか思いっきりJVMに足を引っ張られてた例と思う
ちょっと話は違うけど可変長配列を値返しできる言語を主にC系のことしか考えてないバックエンドで実装すると
mallocして返すかForthみたいにデータスタックをもう一つ用意するかぐらいしか方法がない、みたいな 書いてからもっといい例を思いついた
トランスパイル先に選ばれそうな言語(CとかJVMとかJavascriptとか)って
どれも末尾呼び出し最適化が保証されてないから関数型言語なら避けたいはず 末尾再起最適化なんかトランスパイルの段階でできるだろ
自分でやってみりゃわかるけど、別の言語への変換って細かい仕様のすり合わせが難しくて
どう頑張っても変換結果は綺麗なコードにはならんよ >>101
自身への末尾「再帰」は変換できるが、末尾「呼び出し」一般はかなり難しい
特にモジュールをまたぐとまず無理 トランスパイルする時点で全部gotoにしちゃえばいいんじゃねえの?
ヒープは馬鹿でかい配列切り出して貸してやりゃ良いじゃん。
一番現実的だと思うけど。
と言うか間違えられてかわいそうだな。 トランスパイラだから、トランスパイル先の言語の作法を守らにゃならん、なんてトランスパイラは
どっちつかずのゲテモノになるなんてのが歴史的にある程度わかってきたんだから、諦めて超高級マクロアセンブラとして使うべきだと思うが、
やっぱそのトランスパイル先の美しさって必要なのかねぇ。 >>105
ありがとうありがとう
で、goto式だと呼び出し先も含めてひとつの関数にまとめないといけないので
他の関数をtail callしているのがつながって爆発的にコードサイズが膨れ上がる
JVMだと64kbの壁があるとかないとか ttps://togetter.com/li/280057
またモジュールを超えるとアクセス制御にかかったりもする >>100
javascripというかecmascriptは末尾再帰の最適化は仕様になってる。 Cにはlongjumpがある。
これを使えば親の関数へどこへでも飛んでいける。
末尾再帰もオプションで設定できる。 >>109
JVMだとgotoが相互に飛んでない奴らで一つの関数にまとめるしかないな。
ただ、一つの関数が64kbまで、ってそこそこ余裕あると思うよ。
関数に関数をおさめようとするから爆発的に長くなるというか、実質、関数の後ろにおまけ付いたコードが量産される事になるんだと思う。
呼び出してる側まで全部展開してしまうと割と短くなる。
昔、ホントにそういうトランスパイラ作ったけど、割としっかり動いた。
動的なメモリ確保をほとんどさせられなかったからそうなっただけだけど。
>>112
ホントに高級アセンブラだよなぁ。 jsへのトランスパイラは現状、
jsが、webにおける機械語的な立ち位置
だからというのはわかる。
でもcへのトランスパイラってどんな意味があんの?手抜きとしか思えない。 手抜き出来ることはメリットだろ。
実装と仕様は分けて考えるべきだからな。 手抜きっつーか、Cに変換しておけば、おおむねどんなlibcでも石でも対応するコンパイラがあるってことでは
GoみたくあらゆるものをGo内で完結させるための車輪の再発明だとか
Rustみたく欲しい環境のtripleがあるかとかtierがいくつだとか
そういう言語機能と直接的には関係ない部分のサポートに関する労力をまるっと切れるのがでかい
一時期のaltJavaやaltJSの乱立を見てると、その分言語の質が上がるかって言われたら怪しいけどな
あとllvmの台頭で、ある程度その辺を再利用できる環境が整ったから、直接機械語吐いた方がよくなりつつあるのもあるか >>117
自分で言ってんじゃん。
llvmだったら中間コードまでのトランスパイラ作れば最適化とバイナリはくまでやってくれるしそこまでやりゃ良いのに。
あとgoの車輪の再発明はありだと思う。
画像変換したくてimagemagicのlibに依存する羽目になるとか勘弁。 車輪の再開発はありとか自分が作る立場でも同じこと言えんの >>115
最適化とかそういう所にそれほど苦労しなくなるかな
手抜きといえば手抜きなんだけど
gccをバックエンドにするなら変な石対応が簡単だし
vc++でも食えるように書けばWindowsでも余計なもの要らないし
intelのコンパイラでゴリゴリに最適化かけたりとか、
静的ビルドでワンバイナリ作りたいからCの方のコンパイルオプションでリンクしよう、とか
既存の処理系に乗っかるのはメリット多いと思う >>118
llvmが台頭してきたから相対的にCトランスパイルの魅力なくなってきたよなって話で、
昔はCトランスパイラで既存のコンパイル環境に乗っかるのがよく行われてたって歴史的な話な
gccが中間言語仕様を意図的に隠してた弊害とも言える 実質的にはトランスパイルだろうが何だろうが、とりあえずは関係ないが
今時ライブラリ構築を0からするというのは自分一人が使う自分専用言語だと考えても
汎用言語としてはあり得なくて、何か既存の言語のソレにフリーライドせざるを得ないわけで
となれば何に乗っかるかという部分から考えるし
それが決まってから具体的な実装方を考えるし、なんだったら自動的に決まってくるわけで
余談だが、良くある乗っかり先としては、CとJavaと.NetとJSがあるが・・・
ただ、例えばネイディブコードが良いと考えてC言語系のライブラリに乗っかるとして
C言語のABIはかなり古臭いわけで、あと、ヘッダファイルの存在がかなりエグイわけで
(windows.hをそのまま読み込める自作コンパイラとか書ける気がしない)
その言語で何かCのライブラリを使いたいときCヘッダファイルを適切に移植したのち
使いやすくするためにラッパークラスまで書くとしたら
これはもう多少気に入らない部分があってもC++を使ったほうが楽だし
ヘッダを移植するツールで自動生成する方針でも古臭いCのAPIを直接叩くのなら
何のための新言語か分からないし、だからといってラッパー書くのはバカらしいし
大概のCライブラリにはC++のヘッダも付いてることを考えるとそのままC++使ったbルうがマシ
もしC言語のヘッダを直接読めるように言語を設計するとなるとマクロなども考えると
C言語と文法的に互換性が有るように言語を作らなければならないということで
これまたあまり作る意味が無い、というか多分C++ なんで、素晴らしい言語仕様を考えることは出来るかもしれないし
頑張ってコンパイラを作ることも可能かもしれないが
結局ライブラリをどうするのかという部分が一番の問題で
0から構築するのはあり得ないから何かに乗っかるわけだが
当然乗っかり先の制約を受ける
特にネイティブコード系は一番普及しているABIがC言語のソレであり
気に入らないのでひたすらラップしまくる日々か
諦めて次世代言語の機能を生かせずアンセーフとか言っちゃって直接叩くか Win鯖で運用されない = Win鯖で使えない
だからな
リーナスが死んだら終わりな言語とかよく使えるな どうでもいいが長すぎる文章は読まないからな。もっと要約して話せ >>127
君の言っている意味がよくわからない。
言語? >>128
今のリーナスは、リリース担当兼広報。
実際のリリーススケジュールとか開発機能とかは
スポンサーの企業が決めている。 リーリスリリースリーリリスリリリリリーリスリー
リーリナリリーナリーリリナリリリリリーリナリー Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。
https://ubiteku.oinker.me/2017/12/02/skepticism-about-oo/ ブログ記事は信用しない
マウント取るためだけの批判の連鎖がよくあるんだと、フロントエンド界隈で学んだ OCamlをやるとプログラム中でオブジェクト指向を使った抽象化が必要な場所はほとんど無いことに気付くよ オブジェクト指向って抽象化なのか?
プログラミングで扱うのは本質的には「操作」だが、それは人間にとって抽象度が高く理解しづらい(と考えられていた)から、
仮想的なモノに見立てることで具象化したのがオブジェクト指向だろ メモリとかハードウェアまわりを触るのが具象で
オブジェクトのような仮想的なものを扱うのが抽象だと思っていた >>139
OCamlのOの意味を考えたことあるかい? >>143
名前に入ってようがなんだろうが OCaml で 殆ど誰もOO しないのは端的な事実 正確にはocamlに文法として用意されたclass/objectを誰も使わないという話で、代わりにモジュールを使って抽象型も多態もするわけでそれはそれでOOの一種だとは思うな 関数型言語をやたら持ち上げてるけど
OSを関数型言語で書いてみてよ。それでバグか少なかったら関数型言語の優位性を認めるよ。 >>147
>代わりにモジュールを使って抽象型も多態もするわけでそれはそれでOOの一種だとは思うな
ぜんぜん違うから
だがそこから説明すんの面倒くさいのでもういい >>148
>OSを関数型言語で書いてみてよ。それでバグか少なかったら関数型言語の優位性を認めるよ。
高水準言語でOS書けって頭悪すぎないか
Rustを関数型と認めるゆるい基準なら Redox がある >>146
言語の糞さと、周りの人間が糞だからってことばかりで、全然説明になってないな >>137
>マウント取るためだけの批判の連鎖
これなくすだけでよくなるプロジェクトって世の中に大量にありそう。 >>149
俺も書いてからしまった面倒くさくなる話やと思った
やめとこう オブジェクト指向ってそんなにだめかな?
そのオブジェクトに対する操作をそのオブジェクトに持たせるってわかりやすくていいけど。
immutable.jsのレコードみたく、
メソッドは新しいインスタンスを返す関数と強制すれば関数型とも共生できると思うんだけど。 別に悪いってことはないだろ。
結局、状態や依存をどう管理するかって話なわけで、極論言い始める奴の
いうことなんて話 2 割くらいにきいてりゃいいと思うけど。 JavaScriptのようにハッシュテーブルとラムダを使う言語は関数型と共生できる
じゃあハッシュテーブルを使わない言語はなんで使わないのか?
その答えは、関数型とオブジェクト指向の対立とは全然関係ないところにある まずデータをどれだけ圧縮できるか考えるといい
次に圧縮されたデータを展開する関数を作る >>151
>言語の糞さと、周りの人間が糞だからってことばかりで、全然説明になってないな
はははははははwwww
ま、がんばれw typescript使っててasync awaitが便利なんだけど煩わしい。
mapとか関数呼び出しを伴う操作で非同期処理に戻るのが、
たまにミスって放置しがち。
lintツールで指摘するなり監視する機能が欲しい。
先行してるC#とかはうまくやってるの? ミスを指摘するしか能がない批評家に存在価値はあるのだろうか >>164
ミスを作り出す無能に価値はあるのだろうか 何がミスなのかもわからず客が文句言ってるからで判断するバカ営業よりは価値がある。 This Woman Created a Programming Language with Privacy Baked In
https://www.youtube.com/watch?v=Q6NiqRqGePU Haskellの型クラスって凄く良い機能だと思うんだけど、地味に数学感足りないよな
NumってなんだよNumって。もうちょっと分解しろよって感じだ
Numeric preludeあんまり使われてないみたいだし HaskellはStrictData拡張とStrict拡張が入った事で
実用的な次世代言語になる可能性が出てきた 型なし能なしのゴミ屑言語の何がいいんだろうな
ペチパーは論外、ルビーもガイジだわ 動的型付けというだけで別に型がないわけではないので注意 >>168
あれはSmalltalkってゴミ言語がヒントになった機能だからね
なぜ最初から高階多相にしなかったんだろう 自己書き換えもできないハスケルはプログラム言語と呼ぶに値しない
純粋関数型プログラム言語(自称)ハスケルw Haskellは+や-といった演算子がNumに取られてるせいで
オーバーロード的なことが非常にやりにくいのが不便
<+>みたいな演算子は独自定義できるがなんかダサい 詭弁でもなんでもないだろ
静的言語の型こそまやかしだと思うが。
特にそれがただの「コンパイラだけが知っているメモリへの格納方法」である言語は、動的言語の型よりも型がないと言えると思うけど? はいはいペチパーはPHPスレから出てくんなクソが
君の大好きな肥溜めPHPみたいな動的型付け言語に型はねーから まあいくら静的型でも本物のコンパイラはこんな性格悪くないから気にするな
ここにいるやつはコンパイラの守護霊だ 動的でも静的でも最近は型は強くする方向にはあるかもね。
c とか perl に比べれば java でも python でも十分型を強くしてる印象。 真に型がない言語とはfortran77みたいな言語のことだと思う PHPだとは言ってないのにな。
そもそもPHPと口に出すのこいつぐらいじゃね? >>173
Smalltalkは自身がゴミ言語であるだけでなく
後世の言語にも負の影響を与えてるので
本当に害悪だな >>185
はいはい
サボってないで早く保守作業に戻ってくださいね(藁) 型情報に限らず情報ってのは冗長な部分が省略される
省略したからといって必ずしも情報が失われるわけじゃない 皮肉も理解できないペェチピィコンパイラ並の低脳ガガイノガイがおりゅってマ?w >>190
型情報があるだけでなく情報を取得するアルゴリズムがある言語
アルゴリズムがあればモンティホール問題みたいに計算を間違えるやつが続出しない >>186
多重ディスパッチ出来る言語が型なしってことはないだろ ■ このスレッドは過去ログ倉庫に格納されています