- 1 名前：デフォルトの名無しさん mailto:sage [2017/12/01(金) 23:08:21.45 ID:FxdZTiuZ.net]
- スレタイ以外の言語もok
前スレ
次世代言語Part7[Go Rust Swift Kotlin TypeScript]
mevius.5ch.net/test/read.cgi/tech/1508403098/
- 822 名前：デフォルトの名無しさん mailto:sage [2018/02/22(木) 04:32:43.91 ID:+RpZ2cWG.net]
- 俺も>>799と同意
>>798の言ってることはいまいちよく分からん
nilに余計な意味を与えるからダメとか言ってるがnil自体がそもそも余計だと思う
nilは便利すぎるがゆえにチェック忘れ系の地雷がある
ポインタ演算みたいに強力な機能は同時に危険も引っ付いてまわる
そういった機能は出来うる限りは排除・制限していくべきだと思う
- 823 名前：デフォルトの名無しさん mailto:sage [2018/02/22(木) 05:41:36.72 ID:ePT/3hrM.net]
- nilに余計な意味を与えないための基準がnil安全なのでは？
- 824 名前：デフォルトの名無しさん [2018/02/22(木) 08:14:10.74 ID:p8NiYEqx.net]
- 同僚のコトリンのコードがビックリマークだらけで、こりゃだめだと思った
- 825 名前：デフォルトの名無しさん mailto:sage [2018/02/22(木) 08:54:55.92 ID:MB1I4+Gh.net]
- だから、便利に使わなければ良いと思うんだが。
参照にしない限りnilにはなれないし。
- 826 名前：デフォルトの名無しさん [2018/02/22(木) 12:53:25.00 ID:+RpZ2cWG.net]
- >>799
すまん。番号ズレてるな。以下訂正
> 俺も>>798と同意
> >>797の言ってることはいまいちよく分からん
スマホアプリ使ってると時々ズレるんだよな クソが
そのせいで自分で自分に同意するというアホな文章になってやがる
- 827 名前：デフォルトの名無しさん mailto:sage [2018/02/22(木) 13:11:15.71 ID:0cZDh8Nv.net]
- 修理しない自由 vs. 修理する権利
- 828 名前：デフォルトの名無しさん mailto:sage [2018/02/22(木) 14:54:41.89 ID:ei88pKkZ.net]
- >>800
基準がどうこうってnil安全な言語ってのがわかっていないのかな?
設計思想とかの話じゃなく言語仕様の話をしてんだけど。
つまり変数に明示しない限りnilを代入不可能な変数が作れるってのか
nil安全な言語ってこと。
TypeScriptなら
let some?:number = null; // OK
let some:number = null; // NG
ってこと someにnullが入っている可能性をコンパイル時点で排除できる。
Goだって
func hoge(s *Some) {
// sが絶対nullじゃないことが保証されるスコープ
}
func (s? *Some) SomeFunc() {
if (s != null) {
hoge(s)
}
hoge(s) // NG コンパイルエラー sがnullである可能性が残っている
}
みたいな感じで書ける。?が使えると仮定
- 829 名前：デフォルトの名無しさん mailto:sage [2018/02/22(木) 16:43:44.83 ID:ePT/3hrM.net]
- >>805
しょぼ！
その例はnull安全の中でも一番弱いやつ。
書き方を気をつければnullを避けられるってだけ。
本物のnull安全はスコープ単位ではなく、型検査が通ればプログラムにnullによる誤りを完全に排除されるんだよ。Haskellのように。
- 830 名前：デフォルトの名無しさん mailto:sage [2018/02/22(木) 17:06:16.89 ID:zGB/N5H/.net]
- >>806
elmも実行時エラーを完全排除できるというのを売りにしてたね。
しょぼくても学習コスト最小でメリットは十分享受できる。
とりあえずelm触ってみようかな
- 831 名前：デフォルトの名無しさん mailto:sage [2018/02/22(木) 18:59:35.60 ID:MB1I4+Gh.net]
- >>806
haskellはそんな事の前にもっと解決すべき問題を解決できる言語になってくれ。
- 832 名前：デフォルトの名無しさん mailto:sage [2018/02/23(金) 01:19:34.60 ID:i8nFKqus.net]
- 動的型で解決できる問題はすべて静的型で解決できるし
もしこれが嘘八百だと証明されたとしてもそれはそれで大きな成果だし
いずれにせよHaskellは静的型の歴史に貢献している
- 833 名前：デフォルトの名無しさん mailto:sage [2018/02/23(金) 01:23:42.56 ID:KFd5WK6x.net]
- でも需要はハケスル（笑）＜＜＜＜＜ＰＨＰで圧倒的な件w
- 834 名前：デフォルトの名無しさん mailto:sage [2018/02/23(金) 08:46:52.58 ID:LZyM23a9.net]
- 歴史に貢献するって、ラテン語でもあるまいし。
実用言語にしてよ。
- 835 名前：デフォルトの名無しさん mailto:sage [2018/02/23(金) 10:35:29.52 ID:fGTUWBf8.net]
- 実在するだけでは不満か
実在すら怪しいものがあったらもっと不満だろ
実用よりも実在の方がモチベーションが強い
- 836 名前：デフォルトの名無しさん mailto:sage [2018/02/23(金) 10:45:07.36 ID:HJaUFAvs.net]
- >>811
ラテン語は良い喩えだね。印欧語ヒエラルキーの上の方にいるし。
俗ラテン語を見て、どこが欠落してるかの見通しが良くなる。
Haskellも足りてないけどさ、型理論的に。そういう点でもラテン語あたりなのは妥当。
- 837 名前：デフォルトの名無しさん mailto:sage [2018/02/23(金) 11:35:44.21 ID:2M6dxKUJ.net]
- コンパイル時に解決できるならそれに越したことは無いが
そのための学習コストは増大する傾向にあるよね。
Elmはブラウザのviewに特化したDSLとして学習コストを抑えてる。
Rustもメモリリークを静的に解決しようとするけどそのためのコストはかなり高め。
何事もバランスだよね。
- 838 名前：デフォルトの名無しさん mailto:sage [2018/02/23(金) 21:27:40.00 ID:LZyM23a9.net]
- >>813
そう。
そんなに格いるか？確かにあれば便利だけど前置詞のほうが実質簡潔じゃねえの？とか、
今更ラテン語使う必要無いだろ。足りない語彙を現代語から借用するの？とか、
ヒエラルキーの上位と言うより、広がる枝の根本にほうっておかれた存在だろ。
全く次世代で無い。
- 839 名前：デフォルトの名無しさん mailto:sage [2018/02/23(金) 22:03:17.49 ID:GuloKGfV.net]
- Haskellの熱心なアンチが全くのエアプだった事件があるので、そういう意見はHaskellに精通していることを示さないとなかなか受け入れられないと思うよ
- 840 名前：デフォルトの名無しさん mailto:sage [2018/02/23(金) 23:44:14.84 ID:NePmI3sA.net]
- まあカス仕様を必死に守るのにコストかけるくらいなら
goみたいにコンパイラの性能上げてもらった方がよっぽど有益だったりはする。
- 841 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 00:32:37.74 ID:LvxjVVyK.net]
- お、型付λアンチか？
- 842 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 01:03:27.04 ID:67+llEBF.net]
- >>816
エアプって言葉好きだなぁ。
正直触ってダメ出ししたぐらいだけど、精通せんでも文句は言える。
ラーメン食いに行って「まずいわこれ」って言って、店主に「じゃあお前はこれ以上のラーメン作れんのかよ」「それだけラーメン食って言ってるのか？」ってキレられても困るだろ。
客観的にまずいもんはまずい。まずいと誤解されるものもその次にまずい。
- 843 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 01:06:09.79 ID:67+llEBF.net]
- 意識高い系のおもちゃとして使うんじゃなくて、なんか使えるプロダクト出してから言ってくれよな。
古代言語を次世代言語スレで出すんなら。
- 844 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 01:21:53.07 ID:ZueQv0Xl.net]
- >>817
https://taiyaq.com/contents/YgxOd3YjadMa5c793O1j1d9VX
goの設計思想自体が依存関係解決の高速化だったりコンパイル速度優先の実装みたいだね。
ジェネリクスみたいなコンパイル時の計算速度に大きく影響を与える仕様はなさそうだ。
(あっても限定的な機能になりそう)
- 845 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 02:01:52.41 ID:9192Hwvs.net]
- goにはクラス階層も無いんでしょ？ジェネリクス以外の多態が無いならまだ綺麗に導入できる可能性がある
swiftはバージョンアップで型推論を入れるようなスジの悪い進化を進めてるから好きになれんよ
- 846 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 06:02:14.88 ID:VvbK4X3N.net]
- コンパイル速度優先の上で云々ということであれば
goがDelphi/FreePascalを超えてるかというのは正直疑問
- 847 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 07:01:37.55 ID:VvbK4X3N.net]
- >>822
goはinterfaceによる多態が既にあるから、そこにジェネリクス入れるとJava同様になるぞ
- 848 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 07:57:18.04 ID:ZueQv0Xl.net]
- >>823
現在も絶賛コンパイル速度更新中だからいいんじゃないの。
そもそもdelphiって古すぎて早く見えるってだけでは、、、？
>>824
interfaceを進化させるイメージでジェネリクスぽいものを作るんだろうね
現状複数のinterfaceを受け入れる可能性のある変数は空インターフェース(interface{})
(javaでいうところの何でもありのObject型みたいなの)
にするしかないのがツラミになってる。
ここを改善する方向に進化させるでしょう。
直積型をつくるのはできてるから直和型(union)をサポートして
someFunc(o interface{}) error {}
みたいなのを
someFunc(o A & B) error {}
someFunc(o A | B) error {}
みたいにできればいい。TypeScript好きだからこうなったら感動する
- 849 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 11:17:45.72 ID:LvxjVVyK.net]
- >>819
だっさｗ
- 850 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 11:20:37.36 ID:pBIylWjV.net]
- 古すぎて速いってのは正しい
あとはジェネリクスがない言語は古いと認識できたらもっと正しい
- 851 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 13:37:19.37 ID:67+llEBF.net]
- >>826
俺がダサいだけでhaskellが良くなって実プロダクト出てくるならいくらでもダサくなるわw
- 852 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 14:17:08.41 ID:4YJEYBsv.net]
- 実はDelphiにはジェネリクスあるんだぜw
- 853 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 14:17:22.06 ID:WPlCcRak.net]
- >>827
TypeScriptの最近のジェネリクス変態進化ぶりを見ていると
ジェネリクスが正しいという意見も
なんとも言えないかも。
- 854 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 14:39:08.92 ID:ozvKRveg.net]
- 言うほど変態か？
JSによるOOPの実装方法や、即値を型として扱うTypeScriptの特性を十分に理解してないと
new () => Tとかkeyofなんかは分かりにくいかもしれないけど、それはGenerics以前の問題だろ
基本的には必要以上の驚きのない自然な仕様だと思うよ
- 855 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 15:23:35.50 ID:ZueQv0Xl.net]
- >>831
それくらいならいいけどさ
https://qiita.com/Quramy/items/b45711789605ef9f96de
とか見てみると分かる。
辛いのはユーザ側だとしてもエラーメッセージで巻き込まれることないだよね。
ジェネリクス関連のエラーで一発で問題がわかったことが殆ど無い。
- 856 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 15:44:01.13 ID:ozvKRveg.net]
- >>832
これくらい何とも思わないな
所詮は型アノテーションを正しく引き継ぐためだけの仕組みだぞ？
生成されたコードをデバッグしなきゃいけないテンプレートとは訳が違う
- 857 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 16:50:37.88 ID:ZueQv0Xl.net]
- >>833
こういうエラーメッセージを吐き出すジェネリクスが分かりやすいだって？
https://i.imgur.com/CTJXwJr.png
- 858 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 17:03:15.17 ID:ZueQv0Xl.net]
- >>834
こういうエラーメッセージと戦うのが辛いのって結局途中経過を追えないってことなんだよね。
goはコードジェネレート前提だったりする。
そっちだと分かりやすいコードを吐いてくれれば追いやすい。
- 859 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 17:08:20.40 ID:yL1hQTQw.net]
- >>835
つまり言語仕様の問題じゃなくてコンパイラが途中結果を出力しないのか問題なんだろ？
MSが改善すれば済む話
完全に論理が破綻してるね
- 860 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 17:08:38.51 ID:cWB/7seJ.net]
- >>834
これは酷いTypeScriptは糞
- 861 名前： mailto:sage [2018/02/24(土) 17:14:56.38 ID:yWQ45jBy.net]
- >>834
C++ とて似たようなものだ、ジェネリクスのエラーメッセージは総じて汚らしい
- 862 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 17:15:40.58 ID:NYPMK72i.net]
- >>836はコンパイルがクソ遅い言語に対しても
問題は言語仕様じゃなくてコンパイラの所為だと思ってそう
- 863 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 17:26:03.56 ID:WPlCcRak.net]
- >>836
論理がはたんしてるか？
というかコンパイラの挙動と言語仕様を分けて考える意味がわからない。
言語としての素晴らしさはそれを囲むエコシステム全体を含めて語っていいと思うが。
- 864 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 17:29:02.21 ID:WPlCcRak.net]
- >>838
これ。ジェネリクスは人間に牙を向くのが辛い。ライブラリ開発者でうまくエラーをラップできたりすれば良いんだけどね。
- 865 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 17:43:47.02 ID:yL1hQTQw.net]
- >>834が分かりにくいのって、structual-subtypingで特定のメンバの型に互換性がないのを
「型同士の互換性」の単位で出力してしまってるからじゃないか？
TypeScriptならVSCodeに代入元と代入先の型を展開した状態で比較するビューが付けば解決だと思う
- 866 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 17:51:04.11 ID:ZueQv0Xl.net]
- >>842
あと、もしかしてこう書きたかったんじゃなりませんか？ みたいにannotationをコンパイラが出してくれるとかね。
rustってそういう感じだっけ？
- 867 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 17:54:41.90 ID:ZueQv0Xl.net]
- ちなみに >>834 のエラーはTypeScript2.5.3では出ない。2.6以降にすると出るようになる。
コードとしては何の問題もなく動くんだよね。
バージョン上げるたびに修正するのしんどくて放置してる。
- 868 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 18:11:51.54 ID:67+llEBF.net]
- そのうちまた型システムだけでチューリング完全になるんじゃねえの？
- 869 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 19:33:38.61 ID:OJHwttVu.net]
- チュリ完だと何の不都合ですか？
- 870 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 20:27:10.88 ID:67+llEBF.net]
- する必要の無いものをチューリング完全にしてしまったが故にえらいことになったプロジェクト見てきたし、
そもそもコンパイルの時点で無限ループしかねないとかどんな闇言語だよって話になってくるじゃん。
Scalaも型システムだけでコンパイラ止めれたっけ。
- 871 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 21:39:56.69 ID:Wx4opHQO.net]
- c/c++ のヘッダ処理なんかもデバッグしやすくするのとコンパイル効率は
かなりトレードオフがあるってのが一般的。
だから visual studio が内部で変なことガツガツやってるわけで。
そんなもん２、3年本気で仕事すりゃわかることだろうと思うんだが
なぜか理論よりの人間は事実を認めない傾向にある。
- 872 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 22:16:50.94 ID:8UiUrtqZ.net]
- チュリ完であることそれ自体が問題なのではなく、デバッグ回りが弱すぎるのが問題なのだ
- 873 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 22:36:20.17 ID:CuRF79s8.net]
- >する必要の無いものをチューリング完全にしてしまったが故にえらいことになったプロジェクト見てきたし、
それ、「えらいことになった」原因が本当にチューリング完全のせいだったのかね。
- 874 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 22:55:49.93 ID:WPlCcRak.net]
- 少なくともc,c++の依存関係解決の遅さの解決のためにgoが生まれたってのがgoogleの言い分なわけだし、遅いは遅いんじゃないの。
goにプリプロセッサが無いのも意味があるわけで。
- 875 名前：デフォルトの名無しさん mailto:sage [2018/02/24(土) 23:31:49.65 ID:8UiUrtqZ.net]
- まあ遅いは遅いな。それはそうだ
- 876 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 00:02:11.41 ID:/LdYt4iz.net]
- ちなみにredoxというrustで書かれたosはコンパイルは早いんだろうか。lunuxと単純比較はできないだろうけども
- 877 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 01:39:43.29 ID:i5g4VWIk.net]
- >>850
そうだよ。何を想像してるかわからんけど。
- 878 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 07:45:46.39 ID:Pn1I1KPs.net]
- そりゃチューリング完全であることが問題なんじゃなくてそのチームに問題があったんだろ。
世の中にチューリング完全なシステム(言語)は腐るほどあるわけだし。
- 879 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 08:04:15.51 ID:MHQfhChM.net]
- なんでも「チームが悪い」と言えばいいのだから簡単だな。ばーか
- 880 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 09:34:28.35 ID:5I/H3HR9.net]
- できちゃうことが問題なんじゃないの
c++の型システムがチューリング完全だと自分たちだけがコンパイル速度に気をつけても
依存しているサードパーティライブラリまでは保証できないでしょ。
だったら言語側で制限がかかっておいてほしいって話。
Cの依存性解決も#ifdefを駆使してプリプロセッサの自由度を持って後付で解決していた。
プリプロセッサ自体便利なものだけど、それが原因でコンパイル速度の低下を招いた。
というのが >>821 に書いてる。
汎用性がある機能はなんでもできるからこそ、コンパイル速度を落としたり迷惑を書けることも可能。
swiftもGoも後発言語だけどプリプロセッサのってないもの
rustのマクロの自由度は知らんけども。
- 881 名前：デフォルトの名無しさん [2018/02/25(日) 10:45:11.82 ID:AkGT52Is.net]
- テンプレートやマクロで無茶をする奴が
コードジェネレータで無茶するようになるだけ
- 882 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 11:03:44.36 ID:5I/H3HR9.net]
- >>858
少なくともGoのgenereateはコンパイル時毎回動くわけじゃないから。
- 883 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 11:41:56.21 ID:oFPVlXbE.net]
- あるC++のファイルを変更したら
そのファイルがincludeした全てのコードを再コンパイルする
型情報のみをincludeすればいいのに型ではない値とコードが大量に入ってる
この値とコードが原因だよね
チューリング完全はそこから生じた結果の一つ
- 884 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 12:11:15.59 ID:hhzTCNKn.net]
- >>851
すまん、プリプリセッサって何ンゴ？
- 885 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 12:35:19.43 ID:SIGvHUUj.net]
- プリケツセッサ
- 886 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 12:38:14.47 ID:XjF3qDop.net]
- prepresessor
- 887 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 14:15:34.84 ID:dV634vWG.net]
- >>861
rustでいうマクロみたいなもの
コンパイル前に文字列操作を行ってコードを改変する。
結構なんでもできるから重たい操作を行うとコンパイル時間に影響する。
https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AA%E3%83%97%E3%83%AD%E3%82%BB%E3%83%83%E3%82%B5
- 888 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 15:09:03.97 ID:SIGvHUUj.net]
- それはプリプロセッサや〜〜！！！
- 889 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 15:13:14.53 ID:iLEoqX9J.net]
- >>855
まあバカな奴をチームに入れないためにc++を採用しないって主張をするリーナスは
ある意味正しいな。
- 890 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 16:03:19.53 ID:jkdNIq8n.net]
- >>860
それはちょっと違う
そもそも今時フルコンパイルなんてそんなに重いものではない
C++がまずいのは、includeしたヘッダのコンパイル結果をコンパイル単位(.cpp)を跨って共有できないことだ
プリプロセッサのせいで毎回変わる可能性があるからな
- 891 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 16:17:08.31 ID:UX7CM2uT.net]
- >>866
リーナスはc++がクソだって言ったんだよ。
その次に使う人間もクソが多いって言ったの。、間違えんな
- 892 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 16:45:30.82 ID:u3kGuI4S.net]
- 間違ってはない
- 893 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 17:25:46.72 ID:eL53m5ic.net]
- リーナスはもともとアセンブラーやからのうｗｗｗ
Cは複数のCPUのアーキテクチャーに適応するためにどうにゅうしたわけやしのうｗｗ
- 894 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 17:45:40.47 ID:ZzND0YhV.net]
- c++はいつになったら#importを導入するんだ……
- 895 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 18:22:22.98 ID:iLEoqX9J.net]
- linux もだいぶヘッダマクロでテンプレみたいなことはやってる。
もちろん型安全ではないがそれでもc++のテンプレート使うよりマシという判断をしてるわけだよ。
- 896 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 20:57:01.90 ID:Sac3cGbb.net]
- >>867
それやったらODR違反
- 897 名前：デフォルトの名無しさん mailto:sage [2018/02/25(日) 22:23:17.24 ID:hhzTCNKn.net]
- >>864
メメタァプロプロミングってやつンゴか？
- 898 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 01:07:52.73 ID:NUAGFWAP.net]
- jsのhyperappみたいに300行くらいでreact + reduxなライブラリを作ったように
haskellでも小さなコードですごいことをしてみせる実用ライブラリってあるかな？
- 899 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 01:08:12.13 ID:NUAGFWAP.net]
- jsのhyperappみたいに300行くらいでreact + reduxなライブラリを作ったように
haskellでも小さなコードですごいことをしてみせる実用ライブラリってあるかな？
- 900 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 01:59:20.48 ID:RBbBnG6R.net]
- すごいことってなんだか感情的だな
実用というのも感情かもしれない
- 901 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 05:56:26.51 ID:KYXdLiJx.net]
- コードから改行をスペースに変換して一行にするライブラリーを作ればいい。
- 902 名前：デフォルトの名無しさん [2018/02/26(月) 11:09:00.46 ID:AYoEpEU8.net]
- プリプロセッサは遅くないぞ
C++のテンプレートやコンパイル時処理のほうがよっぽど遅い
RustもSwiftもプリプロセッサを排除する代わりにC++と同じようなことをやってる
- 903 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 11:28:37.86 ID:OBKUk/zi.net]
- >>879
プリプロセッサが遅いんじゃなくてプリプロセッサに依存したビルドが遅いんだろ
コンパイル単位という時代遅れな概念さえなければ話はずっとシンプルになる
- 904 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 11:57:47.68 ID:LqmnPPXl.net]
- コンパイル単位ってコンパイル高速化するためのものと思ってたんだけど、今は無い方が速いのか？
- 905 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 11:58:09.67 ID:tiI6jRqU.net]
- 文字列処理は結果をファイルに保存して再利用しやすい
クラスやオブジェクトの処理はファイルシステムと連携が難しい
かといってファイルシステムがない環境でも動くコンパイラを作る意欲もなさそう
- 906 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 13:46:15.14 ID:IYGVTnOb.net]
- >>879
プリプロセッサが、遅いかどうかはどう作るかによるのでは？
何でもできる分、遅く作り込むことも可能。
だからgoとかは組み込みのimport機能を作ったわけで。
- 907 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 13:50:29.38 ID:IYGVTnOb.net]
- >>877
jsのhyperappに感動してしまったから
感情的になってしまった。
300行でしかも比較的読みやすいコードで
react+reduxなライブラリが作れたことにびっくりしたんす。
勉強用の教材としてもうってつけ。
こういうのが他の言語のライブラリでもないかなと思って。
- 908 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 16:02:15.05 ID:CBNL7amJ.net]
- >>881
✕高速化
○メモリ節約
今の1/1000のメモリでデカいウンコを無理矢理出すための手法で、今となっては百害あって一理なし
- 909 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 20:55:59.83 ID:2he6fwHk.net]
- じゃあお前だけ並列コンパイル禁止な
- 910 名前： mailto:sage [2018/02/26(月) 21:02:06.28 ID:5mZ9QExD.net]
- >>885
make -j での高速コンパイルに感動することしきりです、いつか 32thread な CPU を買おうと思っています
- 911 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 22:24:02.68 ID:FUm7ZUuj.net]
- なぜかプログラマー板に立って放置されてる
nimのスレ立てるか
- 912 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 22:29:16.70 ID:eKoH1eQ3.net]
- 頼む
- 913 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 22:43:29.59 ID:+1zKWNLy.net]
- boost 大好きな奴がビルドのベストプラクティスとして
1ファイルに全て書く言うてたな。
バカとしか言いようがないが面倒だから黙ってた。
- 914 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 23:37:01.37 ID:hKYTqf2f.net]
- 小規模なら1ファイルに全て書いても問題ない
普通に書いたら数百とか数千ファイルになるようなものなら馬鹿で間違いない
- 915 名前：デフォルトの名無しさん mailto:sage [2018/02/26(月) 23:38:45.60 ID:vKciEg6e.net]
- インターフェースとその実装とかは、小規模なら同じファイルに書いてるのもよく見かける
- 916 名前：デフォルトの名無しさん mailto:sage [2018/02/27(火) 03:24:43.50 ID:Rnz77xQ6.net]
- 世の中にはhaskell使い結構居るっぽいのになんでここには全く居ないんだ
githubやstackoverflowまで行かないと出会えんのか
- 917 名前：デフォルトの名無しさん mailto:sage [2018/02/27(火) 05:49:52.64 ID:5KO97NM4.net]
- 一つのファイルに書かなくても
複数のファイルをつなげて一つにするプログラム書けばいいだろ
そのやつ馬鹿やんなｗｗｗ
- 918 名前：デフォルトの名無しさん mailto:sage [2018/02/27(火) 05:53:33.06 ID:5KO97NM4.net]
- 昔の偉い人はトップのファイルに
- 919 名前：だけインクルードを書く手法をつかったらしいからな。
これは複数のファイルを一つにつなげるプログラムとおなじことやんな。 [] - [ここ壊れてます]
- 920 名前：デフォルトの名無しさん mailto:sage [2018/02/27(火) 11:03:33.84 ID:P8RgwK6u.net]
- 今の偉い人はLTOに任せます
- 921 名前：デフォルトの名無しさん mailto:sage [2018/02/27(火) 11:58:06.25 ID:hiD/gfTg.net]
- 分割できないのはC++のtemplateだけ
Cは問題ないからほとんどの言語はCのライブラリに依存する
他言語から利用するならさすがにファイル分割せざるをえない
- 922 名前：デフォルトの名無しさん mailto:sage [2018/02/27(火) 12:49:23.86 ID:cuAUxW5W.net]
- templateって分割できないの？分割してる俺は異端だったか
|
 |
