次世代言語Part8[Haskell Rust Kotlin TypeScript]
レス数が1000を超えています。これ以上書き込みはできません。
すまんComparatorの間違いだ
補足しとくと、直行してないというのは例えば具体的には <T extends Comparable> と (T obj, Comparator<T> comparator) みたいなののことな >>767
便利さを教えてほしいな。
純粋なnilと型があるけど中味はnilって正直わかりづらくないかな。
reflectionのお勉強をしないと理解できない。
Goのインターフェースは後出しジャンケンってのは面白いな。パクらせてもらおう >>768
このへん詳しく知りたいな。
C++とかHaskellのジェネリクスってTypeScriptとかと違うの? >>773
それがnilでも、メソッドチェーンできる。
だから、errを伝搬するのに便利。
末尾のDoなんかで、本当の結果,errorとして取り出せば良いよ。
いちいち失敗構造体なんぞ書かんでも良い。
Nullable的に使える。
どっちかというと下回り書いてるときに便利かも。 >>774
C++はテンプレートを使ってダックタイピングができる
Haskellはアドホック多相を使って>>772でいうcomparator引数に相当する要求をTの型制約に含められる >>775
なんかサンプルある?とょっとイメージがつかめない。nilでメソッドチェーンができるのはわかるけど、それがメリットになるかな?
結局nilを、返してるメソッドがエラー状態な訳で、そいつが暫定的な値を返せばメソッドチェーンはできるよね。 >>777
暫定的なオブジェクトに、レシーバ書いてくの?
Hoge().Get().ReadAll().AsString()
で、毎度nilチェックとか暫定レスポンスのオブジェクト置いてたら非効率じゃん。
ToXXX以外の関数が、Hoge()の返す型やinterfaceを返せば楽じゃない?
Getに失敗したかReadAllに失敗したかが必要ならまた別だろうけど、だいたいひとからげにして問題ない事の方が多い。 >>779
error情報を最初から諦めるってことね。
とにかく最終結果がnilだからメソッドチェーンのどっかで失敗してんだろーなー。くらいの感じなのか。
標準ライブラリでそういう実装してるのあるかな?reflect.Valueとかかな。
あれメソッドチェーンできる代わりに不正なメソッド操作するとpanicしててなかなかしんどい。 >>780
ちょっと違うけど、protobufあたりはもう少し有意義に使ってたな。 流れをぶった切って悪いけどTypeScriptはさすがMS。開発リソースたっぷり。という余裕を感じる。vscodeと一緒に毎週くらいの勢いでアップデート繰り返してる。
ジェネリクスの気持ち悪さもエラーメッセージがわかりやすく進化する感じで直してくれれば全然良いので頑張ってもらいたい。 goのことは全然知らないんだが、型付きnilとやらは実行時ディスパッチしてくれて
その型のメソッドにnil引数付けてやってくるという理解でOK? まずメソッドではなくて、ちょっと変わった構文のの関数ぐらいに受け取ったほうが良いかも。
Foo.Bar()は
Bar(Foo)と、
Foo.Bar(a,b)
は
Bar(Foo,a,b)と同じぐらいの意味。
だからFooがnilでも(ポインタに対してのレシーバであれば)呼べる。 やはりメソッドチェーンは何回も値 (nil) を返すのが気になる
Haskellでは
((Nothing >>= f) >>= g) >>= h
こうするとNothingのパターンマッチを3回するのに対し
Nothing >>= (\ y -> f y >>= (\ z -> g z >>= h))
これなら1回だけ 記号がなくても右結合がきもい
h(g(f(x))は右結合
x.f().g().h()は左結合 こんなのをありがたがるくらいならCommonLisp書くわ。 goの場合nilの場合分けを関数の中でしなくちゃいけないわけだろ。
それが嫌だからモナドができたわけだからな。
メソッドチェーンも嫌だからasyn/awaitとかdo構文が出来たわけで
全部が劣っているな。 秀でるのと、こねくりまわすのは違うからな。
原理上、変態構文と純でも何でもないモナドで出来るとか抜かすぐらいなら、nilチェックするほうがマシ。 コンパイラはモナドをコンパイルエラーにしない
一部の人間は忖度してモナドを自主規制する
コンパイラと人間はどっちが正しいかというだけの話 機械と人間の両方に指図されるのは不自由過ぎる
両方採用するのは過激派
どっちか一つだけにした方が中道という可能性がある goにいまさらnil安全は無理かな?
python3並の断絶が起きちゃう? そもそもnil安全にする必要もない。
その変数に型的にnilが入ることが無かろうがあろうが、
他の言語のnullとはちと違うレベルでnilを取り扱える。
タプルで返す前提だと大した問題には無いと言うか。
他の言語は、nullに本来のその型が持つ意味以上の意味を与えてしまうからわざわざnull安全にしないといかんのでは? タプルで値が返せるから必要ないってただの理屈の上の話で、エラーチェック漏れをおこしたり、エラーチェックしててもnilの入った変数を次の処理に引き継ぐミスは起こり得るだろ。それを防ぐのがnil安全なわけで。 俺も>>797と同意
>>796の言ってることはいまいちよく分からん
nilに余計な意味を与えるからダメとか言ってるがnil自体がそもそも余計だと思う
nilは便利すぎるがゆえにチェック忘れ系の地雷がある
ポインタ演算みたいに強力な機能は同時に危険も引っ付いてまわる
そういった機能は出来うる限りは排除・制限していくべきだと思う nilに余計な意味を与えないための基準がnil安全なのでは? 同僚のコトリンのコードがビックリマークだらけで、こりゃだめだと思った だから、便利に使わなければ良いと思うんだが。
参照にしない限りnilにはなれないし。 >>797
すまん。番号ズレてるな。以下訂正
> 俺も>>796と同意
> >>795の言ってることはいまいちよく分からん
スマホアプリ使ってると時々ズレるんだよな クソが
そのせいで自分で自分に同意するというアホな文章になってやがる >>798
基準がどうこうって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である可能性が残っている
}
みたいな感じで書ける。?が使えると仮定 >>803
しょぼ!
その例はnull安全の中でも一番弱いやつ。
書き方を気をつければnullを避けられるってだけ。
本物のnull安全はスコープ単位ではなく、型検査が通ればプログラムにnullによる誤りを完全に排除されるんだよ。Haskellのように。 >>804
elmも実行時エラーを完全排除できるというのを売りにしてたね。
しょぼくても学習コスト最小でメリットは十分享受できる。
とりあえずelm触ってみようかな >>804
haskellはそんな事の前にもっと解決すべき問題を解決できる言語になってくれ。 動的型で解決できる問題はすべて静的型で解決できるし
もしこれが嘘八百だと証明されたとしてもそれはそれで大きな成果だし
いずれにせよHaskellは静的型の歴史に貢献している でも需要はハケスル(笑)<<<<<PHPで圧倒的な件w 歴史に貢献するって、ラテン語でもあるまいし。
実用言語にしてよ。 実在するだけでは不満か
実在すら怪しいものがあったらもっと不満だろ
実用よりも実在の方がモチベーションが強い >>809
ラテン語は良い喩えだね。印欧語ヒエラルキーの上の方にいるし。
俗ラテン語を見て、どこが欠落してるかの見通しが良くなる。
Haskellも足りてないけどさ、型理論的に。そういう点でもラテン語あたりなのは妥当。 コンパイル時に解決できるならそれに越したことは無いが
そのための学習コストは増大する傾向にあるよね。
Elmはブラウザのviewに特化したDSLとして学習コストを抑えてる。
Rustもメモリリークを静的に解決しようとするけどそのためのコストはかなり高め。
何事もバランスだよね。 >>811
そう。
そんなに格いるか?確かにあれば便利だけど前置詞のほうが実質簡潔じゃねえの?とか、
今更ラテン語使う必要無いだろ。足りない語彙を現代語から借用するの?とか、
ヒエラルキーの上位と言うより、広がる枝の根本にほうっておかれた存在だろ。
全く次世代で無い。 Haskellの熱心なアンチが全くのエアプだった事件があるので、そういう意見はHaskellに精通していることを示さないとなかなか受け入れられないと思うよ まあカス仕様を必死に守るのにコストかけるくらいなら
goみたいにコンパイラの性能上げてもらった方がよっぽど有益だったりはする。 >>814
エアプって言葉好きだなぁ。
正直触ってダメ出ししたぐらいだけど、精通せんでも文句は言える。
ラーメン食いに行って「まずいわこれ」って言って、店主に「じゃあお前はこれ以上のラーメン作れんのかよ」「それだけラーメン食って言ってるのか?」ってキレられても困るだろ。
客観的にまずいもんはまずい。まずいと誤解されるものもその次にまずい。 意識高い系のおもちゃとして使うんじゃなくて、なんか使えるプロダクト出してから言ってくれよな。
古代言語を次世代言語スレで出すんなら。 >>815
https://taiyaq.com/contents/YgxOd3YjadMa5c793O1j1d9VX
goの設計思想自体が依存関係解決の高速化だったりコンパイル速度優先の実装みたいだね。
ジェネリクスみたいなコンパイル時の計算速度に大きく影響を与える仕様はなさそうだ。
(あっても限定的な機能になりそう) goにはクラス階層も無いんでしょ?ジェネリクス以外の多態が無いならまだ綺麗に導入できる可能性がある
swiftはバージョンアップで型推論を入れるようなスジの悪い進化を進めてるから好きになれんよ コンパイル速度優先の上で云々ということであれば
goがDelphi/FreePascalを超えてるかというのは正直疑問 >>820
goはinterfaceによる多態が既にあるから、そこにジェネリクス入れるとJava同様になるぞ >>821
現在も絶賛コンパイル速度更新中だからいいんじゃないの。
そもそもdelphiって古すぎて早く見えるってだけでは、、、?
>>822
interfaceを進化させるイメージでジェネリクスぽいものを作るんだろうね
現状複数のinterfaceを受け入れる可能性のある変数は空インターフェース(interface{})
(javaでいうところの何でもありのObject型みたいなの)
にするしかないのがツラミになってる。
ここを改善する方向に進化させるでしょう。
直積型をつくるのはできてるから直和型(union)をサポートして
someFunc(o interface{}) error {}
みたいなのを
someFunc(o A & B) error {}
someFunc(o A | B) error {}
みたいにできればいい。TypeScript好きだからこうなったら感動する 古すぎて速いってのは正しい
あとはジェネリクスがない言語は古いと認識できたらもっと正しい >>824
俺がダサいだけでhaskellが良くなって実プロダクト出てくるならいくらでもダサくなるわw >>825
TypeScriptの最近のジェネリクス変態進化ぶりを見ていると
ジェネリクスが正しいという意見も
なんとも言えないかも。 言うほど変態か?
JSによるOOPの実装方法や、即値を型として扱うTypeScriptの特性を十分に理解してないと
new () => Tとかkeyofなんかは分かりにくいかもしれないけど、それはGenerics以前の問題だろ
基本的には必要以上の驚きのない自然な仕様だと思うよ >>829
それくらいならいいけどさ
https://qiita.com/Quramy/items/b45711789605ef9f96de
とか見てみると分かる。
辛いのはユーザ側だとしてもエラーメッセージで巻き込まれることないだよね。
ジェネリクス関連のエラーで一発で問題がわかったことが殆ど無い。 >>830
これくらい何とも思わないな
所詮は型アノテーションを正しく引き継ぐためだけの仕組みだぞ?
生成されたコードをデバッグしなきゃいけないテンプレートとは訳が違う >>831
こういうエラーメッセージを吐き出すジェネリクスが分かりやすいだって?
https://i.imgur.com/CTJXwJr.png >>832
こういうエラーメッセージと戦うのが辛いのって結局途中経過を追えないってことなんだよね。
goはコードジェネレート前提だったりする。
そっちだと分かりやすいコードを吐いてくれれば追いやすい。 >>833
つまり言語仕様の問題じゃなくてコンパイラが途中結果を出力しないのか問題なんだろ?
MSが改善すれば済む話
完全に論理が破綻してるね >>832
C++ とて似たようなものだ、ジェネリクスのエラーメッセージは総じて汚らしい >>834はコンパイルがクソ遅い言語に対しても
問題は言語仕様じゃなくてコンパイラの所為だと思ってそう >>834
論理がはたんしてるか?
というかコンパイラの挙動と言語仕様を分けて考える意味がわからない。
言語としての素晴らしさはそれを囲むエコシステム全体を含めて語っていいと思うが。 >>836
これ。ジェネリクスは人間に牙を向くのが辛い。ライブラリ開発者でうまくエラーをラップできたりすれば良いんだけどね。 >>832が分かりにくいのって、structual-subtypingで特定のメンバの型に互換性がないのを
「型同士の互換性」の単位で出力してしまってるからじゃないか?
TypeScriptならVSCodeに代入元と代入先の型を展開した状態で比較するビューが付けば解決だと思う >>840
あと、もしかしてこう書きたかったんじゃなりませんか? みたいにannotationをコンパイラが出してくれるとかね。
rustってそういう感じだっけ? ちなみに >>832 のエラーはTypeScript2.5.3では出ない。2.6以降にすると出るようになる。
コードとしては何の問題もなく動くんだよね。
バージョン上げるたびに修正するのしんどくて放置してる。 そのうちまた型システムだけでチューリング完全になるんじゃねえの? する必要の無いものをチューリング完全にしてしまったが故にえらいことになったプロジェクト見てきたし、
そもそもコンパイルの時点で無限ループしかねないとかどんな闇言語だよって話になってくるじゃん。
Scalaも型システムだけでコンパイラ止めれたっけ。 c/c++ のヘッダ処理なんかもデバッグしやすくするのとコンパイル効率は
かなりトレードオフがあるってのが一般的。
だから visual studio が内部で変なことガツガツやってるわけで。
そんなもん2、3年本気で仕事すりゃわかることだろうと思うんだが
なぜか理論よりの人間は事実を認めない傾向にある。 チュリ完であることそれ自体が問題なのではなく、デバッグ回りが弱すぎるのが問題なのだ >する必要の無いものをチューリング完全にしてしまったが故にえらいことになったプロジェクト見てきたし、
それ、「えらいことになった」原因が本当にチューリング完全のせいだったのかね。 少なくともc,c++の依存関係解決の遅さの解決のためにgoが生まれたってのがgoogleの言い分なわけだし、遅いは遅いんじゃないの。
goにプリプロセッサが無いのも意味があるわけで。 ちなみにredoxというrustで書かれたosはコンパイルは早いんだろうか。lunuxと単純比較はできないだろうけども >>848
そうだよ。何を想像してるかわからんけど。 そりゃチューリング完全であることが問題なんじゃなくてそのチームに問題があったんだろ。
世の中にチューリング完全なシステム(言語)は腐るほどあるわけだし。 なんでも「チームが悪い」と言えばいいのだから簡単だな。ばーか できちゃうことが問題なんじゃないの
c++の型システムがチューリング完全だと自分たちだけがコンパイル速度に気をつけても
依存しているサードパーティライブラリまでは保証できないでしょ。
だったら言語側で制限がかかっておいてほしいって話。
Cの依存性解決も#ifdefを駆使してプリプロセッサの自由度を持って後付で解決していた。
プリプロセッサ自体便利なものだけど、それが原因でコンパイル速度の低下を招いた。
というのが >>819 に書いてる。
汎用性がある機能はなんでもできるからこそ、コンパイル速度を落としたり迷惑を書けることも可能。
swiftもGoも後発言語だけどプリプロセッサのってないもの
rustのマクロの自由度は知らんけども。 テンプレートやマクロで無茶をする奴が
コードジェネレータで無茶するようになるだけ >>856
少なくともGoのgenereateはコンパイル時毎回動くわけじゃないから。 あるC++のファイルを変更したら
そのファイルがincludeした全てのコードを再コンパイルする
型情報のみをincludeすればいいのに型ではない値とコードが大量に入ってる
この値とコードが原因だよね
チューリング完全はそこから生じた結果の一つ >>853
まあバカな奴をチームに入れないためにc++を採用しないって主張をするリーナスは
ある意味正しいな。 >>858
それはちょっと違う
そもそも今時フルコンパイルなんてそんなに重いものではない
C++がまずいのは、includeしたヘッダのコンパイル結果をコンパイル単位(.cpp)を跨って共有できないことだ
プリプロセッサのせいで毎回変わる可能性があるからな >>864
リーナスはc++がクソだって言ったんだよ。
その次に使う人間もクソが多いって言ったの。、間違えんな リーナスはもともとアセンブラーやからのうwww
Cは複数のCPUのアーキテクチャーに適応するためにどうにゅうしたわけやしのうww c++はいつになったら#importを導入するんだ…… linux もだいぶヘッダマクロでテンプレみたいなことはやってる。
もちろん型安全ではないがそれでもc++のテンプレート使うよりマシという判断をしてるわけだよ。 >>862
メメタァプロプロミングってやつンゴか? jsのhyperappみたいに300行くらいでreact + reduxなライブラリを作ったように
haskellでも小さなコードですごいことをしてみせる実用ライブラリってあるかな? jsのhyperappみたいに300行くらいでreact + reduxなライブラリを作ったように
haskellでも小さなコードですごいことをしてみせる実用ライブラリってあるかな? すごいことってなんだか感情的だな
実用というのも感情かもしれない コードから改行をスペースに変換して一行にするライブラリーを作ればいい。 プリプロセッサは遅くないぞ
C++のテンプレートやコンパイル時処理のほうがよっぽど遅い
RustもSwiftもプリプロセッサを排除する代わりにC++と同じようなことをやってる >>877
プリプロセッサが遅いんじゃなくてプリプロセッサに依存したビルドが遅いんだろ
コンパイル単位という時代遅れな概念さえなければ話はずっとシンプルになる コンパイル単位ってコンパイル高速化するためのものと思ってたんだけど、今は無い方が速いのか? 文字列処理は結果をファイルに保存して再利用しやすい
クラスやオブジェクトの処理はファイルシステムと連携が難しい
かといってファイルシステムがない環境でも動くコンパイラを作る意欲もなさそう >>877
プリプロセッサが、遅いかどうかはどう作るかによるのでは?
何でもできる分、遅く作り込むことも可能。
だからgoとかは組み込みのimport機能を作ったわけで。 >>875
jsのhyperappに感動してしまったから
感情的になってしまった。
300行でしかも比較的読みやすいコードで
react+reduxなライブラリが作れたことにびっくりしたんす。
勉強用の教材としてもうってつけ。
こういうのが他の言語のライブラリでもないかなと思って。 >>879
✕高速化
○メモリ節約
今の1/1000のメモリでデカいウンコを無理矢理出すための手法で、今となっては百害あって一理なし >>883
make -j での高速コンパイルに感動することしきりです、いつか 32thread な CPU を買おうと思っています なぜかプログラマー板に立って放置されてる
nimのスレ立てるか boost 大好きな奴がビルドのベストプラクティスとして
1ファイルに全て書く言うてたな。
バカとしか言いようがないが面倒だから黙ってた。 小規模なら1ファイルに全て書いても問題ない
普通に書いたら数百とか数千ファイルになるようなものなら馬鹿で間違いない インターフェースとその実装とかは、小規模なら同じファイルに書いてるのもよく見かける 世の中にはhaskell使い結構居るっぽいのになんでここには全く居ないんだ
githubやstackoverflowまで行かないと出会えんのか 一つのファイルに書かなくても
複数のファイルをつなげて一つにするプログラム書けばいいだろ
そのやつ馬鹿やんなwww 昔の偉い人はトップのファイルにだけインクルードを書く手法をつかったらしいからな。
これは複数のファイルを一つにつなげるプログラムとおなじことやんな。 分割できないのはC++のtemplateだけ
Cは問題ないからほとんどの言語はCのライブラリに依存する
他言語から利用するならさすがにファイル分割せざるをえない templateって分割できないの?分割してる俺は異端だったか 優秀なコンパイラ使ってるんだな
そのためのexport構文は実装が難しすぎて廃止されたんだ Vector<T>の内部で無引数のVectorを利用するだけみたいなパターンがある
このパターンに従ってなければ異端視されるリスクはあるだろう Railsってなんだかんだいって未だに人気があるみたいだけど、
なんでなん? Rubyって動的言語だよね? PHPを使ったフレームワークとどこが違うの?
なんであんなに1強状態で人気があるの?
Rubyの魅力とセットで教えてください。 優れているわけではなく、バカチョンで作れるから安易に選ばれやすいのだろう
Railsで始めてみることより、仕様が固まったら次のまともな言語やフレームワークに移行できるかの方が重要
実際、それに失敗(あるいはその必要性すら見越せず)して炎上する案件も後を絶たない
小さくは産めるが大きく育てることはできないのがRails バカチョンなのはphpじゃなくて?
なんか意識高い系が使ってるイメージなんだけどRoR ザッカーバーグはphpでボコボコ作ってたんだから作れる奴は作れるんだろ。 >>903
でも言語ごと見直してるよね つ hack >>899
これに誰もコメントできないということは意識高い系エンジニアはもう2chにはいないってことかな 煽られたのでレスする
>>899
エコシステムが優れているの一点に尽きる
日本語のユーザーが多いので大抵の問題は検索で解決する
とりあえずgem入れれば大抵のことができる
Rubyであることは恐らく関係がない(Rubyの魅力ってなんだろ?ないんじゃね)
このような特長によりラピッドプロトタイピングでは他の追随を許さないため、
早急に成果物が必要なWeb系スタートアップなどでとても重宝される
ユーザーが多くて問題が検索で解決するということは学習コストが低いので、
プログラミングが全くわからないという初心者にも人気
誤解を恐れずに言えば、PHPなどの他の言語のRoRライクなフレームワークは、
Rubyを新たに学習するのを嫌がった既存言語のユーザーのためのパチモンである 次世代言語スレで枯れたスクリプト言語の流行り廃りなんて話題にしたくないって人が多いんだろ 結局javascirptが古いようで最新の技術なんだよね。 >>908
Rubyが嫌いって結局ガッツリハマった人の意見じゃないなぁ。
結局外から観測してる人の意見じゃん。
やっぱりいないんだな。2chには。
ちなみにRubyの良いところって多分プリミティブ型が存在しないことなんかなと
完全に純粋なオブジェクト指向言語を目指したって作者の人も言ってるし。
数字にメソッドが生えているのはたしかにすごいと思った。 >>912
あとElixirはかなりRubyに影響を受けてると聞いた。
だからRubyには魅力があると考えている人は確実にいる。 数字にメソッドといえば Kotlin もそうだな。 >ちなみにRubyの良いところって多分プリミティブ型が存在しないことなんかなと
心の底からどうでもいいわ。 >>915
まぁそうよね。俺もRubyを外野から見てるから、正直それがどうプログラミングに役に立つかわからない。
でも、今もiOS開発でcocoapodsが使われてるなら
あれは設定ファイルがrubyで出来てるはず。(DSLを作りやすい言語だとも聞いた。) >>909
捨てられない、壊せない、低学歴のゴミ捨て場
池沼保守が更なる池沼保守を招き、公共事業になる
COBOLですか?いいえ、ペチプァです >>911
https://anond.hatelabo.jp/20170501085956
>JavaScriptはDOMを書き換えるためだけに存在している書捨てのクソ言語であって、サーバーサイドを書くために存在している言語でも、100万行からなるバベルの塔の建設に耐えうる言語でもない。 >>918
JSも毎年進化してるしasync-await周りの進化を楽しみにしてます。
array系メソッドのasync-await対応入れて欲しい。
TypeScript全然今現役だし。むしろこれからじゃないの。
結構型定義ファイルを最初から提供してくれるライブラリも増えてきたし。 動的言語の良いところは連想配列と無名関数だぜ
オブジェクトとか参照透明とかいう思想を無視して使うと良い 日本語ですらこうだからな
英語でこれをやられると日本人は詰む rubyで作ったものといえばhomebrewとかchef、vagrantとか環境構築系統の奴が多い気がする。 でもPHPってなにげに関数型っぽい性質を思ってるよね。
requestを入力にresponseを出力するだけの機能しか作れないわけだし。
ただ言語自体が副作用を許容するのが残念なだけで。 いや関西型でしょ
細かいことはどうでもええねんやで〜 って感じ 細かい組み込み関数は暗記しなくていいとPerlの作者は言ってる
でもみんな人の話を細かいところまで聞いてない
そして、組み込み型が存在しない言語があれば完璧に覚えられるんじゃないか
完璧に覚えられないPerlは欠陥品じゃないかと誰かが思いついた 詳細を暗記しなくていいって言い方は何か違うな
全容を理解しなくても使えるみたいな言い方だった 誰も全容を理解できないほどグチャグチャなだけじゃないか? ゴミの中から使えるものを探し出すマイニング言語だな 機能を詰め込んだ言語はどれも同じようなこと言うが、
あればどっかのバカがドヤ顔で使うもんなんだよ。人が分からないこと機能を使うことがそいつの生きがいだったりするし。 覇権とはつまり無料で伝わってくる評判や情報
たしかにソースコード自体はただでもらえることが多いが
全ての情報が無料になるとは限らない Dartまだ生きてたんだな
flutterで久々に名前聞いたわ 死産だろ
AltJSはTypeScriptだけでいい
Flowのある今、TSですら要らなくなりかけてるしな
コヒースクリプトとかいう究極の糞ゴミもあったなそういえば javascriptのpython的な感じのnode.jsが
サーバ側javascriptとかいってわけのわからない何をするものかわからない
説明しかないウェブ上にないから選択肢にならないのが駄目なんだよな。 Dartの戦略はosから全部google製に置き換えるという壮大なものっぽい。
flutterはUI部分はビデオゲームみたいに0から作り直してるからAndroidの断片化問題を回避してる。
結論はdart死んでなかったんや 自社で使ってねえ、いつ投げ出すかもわかんねえプロダクト使えるわけねえだろ
Angularなんて全く自社で使ってないから、案の定グダグダでReact対抗なんか遙か遠く、Vueにすら劣るゴミやン >>942
わかる
自社で作ったフレームワークを自社が使わないってどうなのよ?って思う
まだベータ版だからとかそれなりの理由があるならともかく、そうでなければ
自分の作ったフレームワークは使うに値しないって言ってるも同然だよな
そんなフレームワークを使う気になれないし趣味以外で使う奴の気が知れない さすがに手を出しかねるよなあ
flutterに関してはアーリーアダプターさんに頑張っていただいて、僕はレイトマジョリティになるでござる angularみたいに色々ごった煮するよりか
reactみたいに単なるviewライブラリって割り切ってもらった方が個人的には好みかな。 Googleって社内の開発に関しては保守的な印象
Googleともなると、新しい玩具に飛びつくことが長期的にどれだけの利益または不利益を生むかが定量的に分かってしまうんだろうね 逆に、つかえねえ自社開発ツールを>>943みたいな理屈で開発環境として現場に押し付けるのもどうかと思うが
公開しないんじゃなくて、できないレベルで使えない、公開したら株価下がるレベルのやつ
ある程度は公開してフィードバック貰わないと腐るよ >>949
いや、自社開発のクソみたいなツールを使えと言っているわけじゃないんだが…
例えばReactはFacebookが作っていて、Facebookは自社でReactを積極的に利用してるわけだから
そういう開発者自身が積極的に利用してるツールじゃないと魅力を感じないってだけで
あと、公開するなとも言ってないんだが…
自社では利用してないツールなら正式版としては公開するのはどうかと思うってだけで
ベータ版としてならむしろ積極的に公開してほしい
Googleはコード資産が膨大だから全てをAngularに置き換えるのは到底無理な話だが
一部のツール(例えばGmailだけ)を実験的にAngularに置き換えることは可能だろ
でも、それさえ行われてないわけでそんなものを正式版と言われても魅力を感じないと言いたかった Flutterをとょっと触った感じすごくReactぽい。なんというか今のトレンドはReactに皆寄せるんかな Closure Library「社内で使ってたら使ってくれるんですか?」 Flutterのチュートリアルを翻訳し始めてみた
https://taiyaq.com/contents/Q2PmOvB1p2yMdH9xxe1JpKL6Jx
手軽に触れる。開発ツールとして悪くない。
vscodeに最初から対応しているのがいい。 >>954
React Nativeの寡占のケツ叩く材料にはいいかもしれんな
それしか価値がないが 覇権言語TypeScriptで作られたVSCodeを使ってDart書いてたら死にたくならない? AltJS界で覇権
プログラミングエディタで覇権
クラウドプラットフォームでGoogleに圧勝して2番手
.NET Coreもまさかの成功
MSは一時期調子に乗ってMSを馬鹿にしてたWeb系連中を完全に黙らせたよな
結局、所詮Web系は極めて狭い技術領域における開発プロセスの過剰な最適化を競ってるだけで、大した技術はないんだよね そのWeb系連中のケツ穴舐めて媚びへつらってアヘ顔晒してるM$さんが何だって? 実際、言語設計やシステム設計に関してはMSは群を抜いてると思う
対して、需要を先読みするセンスはGoogleとAppleの方が一枚上手って感じ
まぁ、今のAppleはブランド力だけで需要を強引に上書きしてる感あるが TypeScriptは確かに覇権ではあるけど
自らにES201X + 型 である。という強い制約を課している。
だからいろいろできたらいいのになって思うけどできない制約が多い。
例えば関数のオーバーロードはできない(宣言はできるけど)。
https://docs.solab.jp/typescript/function/overload/
がっばって実装を工夫しないと読みづらそう。 >>961
今のApple上層部は技術に興味がない感がすごい。
rootパスワードを無視できるバグができたって完全にテストプロセスが旧態依然ってことだろ。 >>965
あのマクロが万能なんでもあり感満載でいいのではないか? 副作用も含めて良い感じ
関数の中に書いたりしたときにスコープ効いてくれると嬉しかったんだが Cのプリプロセッサはマクロと呼ぶには貧弱で置換表現と呼ぶには強力過ぎるのがなぁ >>963
普通に関数のオーバーロードできてるやん…
もしかして、オーバーロードが何か理解してない?? >>969
よく読めよ宣言はできるって言ってるだろ。
エントリーポイントは一箇所に纏める必要があるのが問題だって言ってるの >>969の理解している「普通の関数のオーバーロード」を説明してもらった方が面白いと思う >>970
エントリポイントが1箇所にまとまってるとオーバーロードじゃないの?
>>971
ポリモフィズムのバリエーションで、ユーザーコードから、別シグニチャに同じメッセージタグで呼び出せるものだと思ってるが
実装が大変かどうかと、オーバーロードが実現できるかどうかを同じにしてることに違和感があっただけだよ
ID:mBYt1wWZが大変だと思ってる事実を否定するものではない マクロはDOM操作かPHPに似ている
ただしweb系が戦国時代だとしたらcppは覇権江戸幕府 オーバーロードの宣言を一箇所にまとめないといけないというのは改造ocamlのG'Caml等もそうだったな
その方がコンパイラは楽なのもわかるけど、実用しようと思ったら別々の場所で宣言できないと
用を為さないというのもわかる >ポリモフィズムのバリエーションで、ユーザーコードから、別シグニチャに同じメッセージタグで呼び出せるものだと思ってるが
特段反論というわけでもないけど:
シグネチャというのはそもそもメッセージタグが同一でも型や引数の個数で別になる
つまりそれはシグネチャの定義に過ぎない
シグネチャが別になった結果同じ名前で別のもの(関数定義など)が参照されるのがオーバーロード。
TypeScriptは型情報についてはオーバーロードが行われるが、
実装の参照については(ECMAScriptとの互換性のため)オーバーロードが行われない、
みたいに理解している。 次スレからPart表記なくせば、もっと詰め込める
この形ならElmかNimがはまるな
次世代言語9[Go *** Rust Swift Kotlin TypeScript]
でも文字数ギリだから、次次スレからまた変えることになる
括弧をなくせば使えるが
次世代言語10 Go *** Rust Swift Kotlin TypeScript >>976
そもそも言語をスレタイに入れなければ良いのでは? 別に引っかからなくていいよ。
誰がそこまでこのスレを重視してんの? >>978
引っかかったところで大してその言語の話してねえようなスレなんだぜ。
Kotlinなんて十レスもない。
引っかかること自体詐欺的。 次世代言語と言えばsmalltalkだろ
もっとsmalltalkの話しようぜ! 申し訳ないがジョブズに自慢していいとこ取られて死んだ言語はNG あえて言おう
パクられることなくSmalltalkに残った機能なぞカスであると
イメージベース然り、become:然り なんでDart2なんか出しちゃったんだろな
ひょっとしてグーグルって俺よりバカなんじゃないか?
俺だったらGo使うわ いやホント、俺がプロジェクトマスターやってあげたほうがいいんじゃないか?って。
心配になってくるよな、最近のグーグルは、困ったもんだよ >>986
goはなんか違う気がする。
今のgoでGUIフレームワーク作ったらinterface{}だらけになる予感しかない。 GoにGUIは明らかに不得手。
俺画面周りはHTMLとCSSで書いてるわ。
gopherjs使うと思ったよりブラウザ側でも色々させられるし。
あれ面白いぞ。 どっちかというと比較対象はTypeScriptなんじゃないかな。null安全だったりasync awaitあったり共通点は多い。
でも、jsの仕様を引きづる言語仕様だから、そういう後方互換性を考慮しなくてもいいDartってことなんじゃないか。
google社内でも使われてるみたいだし。
flutterもreactユーザーにはしっくりきやすい。俺はTypeScript+React大好き派だから
かなりいい感じ。
チュートリアルもdartを知らんでも触れるようにできてて分かりやすい。 >>981
笑えたわww。
対照的に何度も出てくるみんなのアイドル某ボケ担当言語を外してるあたりも、
個人的怨嗟が垣間見える。 flutterってどんなアーキ使えばいいの?
reactと同じだからflux? >>994
flux自体がReactの延長上の思考法なわけだから。
基本は極力Stateの管理をするコンポーネントを一箇所に集めろって話。
flutterもおんなじだろうね。
詳しくはReactの考え方でググってみ。 このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 95日 0時間 50分 58秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。