Vue vs React vs Svelte Part.6

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2020/10/27(火) 13:09:05.31ID:5aYZ+KyB
実際どうなん？
※Angularは残念ながら全く話題にならなかったのでSvelteに差し替えました
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Angular Part.5
https://mevius.5ch.net/test/read.cgi/tech/1596029929/

★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Angular, Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。
2020/12/26(土) 23:24:34.97ID:A5wLytvy
>>711
なんでこんなに試し試されるような会話をしないといかんか考えてよ。
みんなわかってて、批判してるんよ。
ちゃんと聞こうよ。
2020/12/27(日) 00:04:05.78ID:+391sGQI
またそのうちC#おじさん湧いてくるだろうけど、マジで不毛なんだよね。全く懲りない反省しない
2020/12/27(日) 00:24:48.94ID:V6kYHqJF
AWS Lambda には、Ruby も採用されている

マネージドサービスを使っていれば、環境構築運用など何も考える必要ない。
バッチ、Lambda、SQS・キュー、SNS・通知を、一杯つなげるだけ
2020/12/27(日) 01:08:11.82ID:pJh4CuO4
新規案件でSPA作りたかったらサーバーサイドもフロントサイドもC#選ぶ理由なんてないってことだ
2020/12/27(日) 01:34:36.12ID:muwPWXFk
>>708
VitualStudio使わなきゃいけないってのはサーバーサイドやるには結構面倒
2020/12/27(日) 02:16:33.08ID:Ezs6G331
>>716
なぜ使わなきゃいけないと思った？
2020/12/27(日) 02:17:11.17ID:sH9shL9g
C#おじさん全くスレと関係ないことを書き散らかして
自演改行しまくるから本当に迷惑
2020/12/27(日) 07:40:53.11ID:bUn1CAUk
自演がヒドイしとだから...
2020/12/27(日) 13:35:21.05ID:JDlKWc3Q
>>620
tsはまぁ分かるがjsはちょっと
pythonは古い言語だから記述のもどかしさは多いね
import周りは迷走しすぎ
2020/12/27(日) 16:30:32.33ID:xvZc4lDU
es3の頃のバッドノウハウを一旦リセットしてes2017とかやるとだいぶ違うよ。
同じ動的型付け言語でもpythonなんかより言語として洗練されている。
2020/12/27(日) 20:55:15.37ID:sH9shL9g
pythonも型書けるからねえ
tsはなんか型パズルしちゃう人が多くてよくわからん
表現力が強すぎるのも考えもの
2020/12/28(月) 20:26:09.84ID:KNPSf2Ws
>>710
>GCがイケてない。
JSを含む多くの言語がGCを持っている
それらのGC実装比較して具体的にどうイケてないと感じた？

>古いAPIが残りすぎ。
後方互換性は明らかなメリット
JSを含む他の言語ではそんなに簡単に後方互換性が失われて破壊的変更が頻繁に行われるの？

>スレッドプールの使い方が下手。
.NETのスレッド(を含む非同期処理全般)はうまく出来ていて最小限の労力で各環境毎に高い効果を見込めるようにできている
具体的にどういうところが下手だと感じた？

>最近ValueTaskが出てさらに無茶苦茶になった。
基本的にValueTaskを選んでおけばOKになったのでむしろスッキリした
どういうところが無茶苦茶になったと感じた？

>新機能がとことんシンタックスシュガー
シンタックスシュガーにすることによりランタイムのバージョンアップを回避して高い後方互換性を維持することができた
このメリットに対して変数のスコープが少し伸びた事によって具体的にどのようなデメリットが発生した？
2020/12/28(月) 21:29:19.32ID:8HD9KuQx
配点も書いてくれよ
2020/12/28(月) 21:49:29.10ID:gLlPtDZl
レスないからって自演かよ
2020/12/28(月) 22:08:20.13ID:KhSNASG/
お、屁理屈C#おじさんじゃん
2020/12/28(月) 22:18:18.18ID:KNPSf2Ws
なんだ
具体的に答えられないということは
やっぱり適当にそれっぽく言ってみただけか
2020/12/28(月) 22:27:42.95ID:KhSNASG/
まともに回答しても屁理屈で答えるか図星を突かれたら無視するような奴に、色々教えて介護してやる気は無いよ
2020/12/28(月) 23:18:38.63ID:KNPSf2Ws
>>728
そういうのはまともに回答できるようになってから言いなさい
2020/12/28(月) 23:19:49.01ID:0DUA8XV/
そもそも自演だし
2020/12/28(月) 23:22:09.77ID:or9XXg+k
い、一体どのレスとどのレスが自演なんだ…？
2020/12/28(月) 23:25:52.59ID:KNPSf2Ws
自演って言ってみたかっただけだろう
2020/12/28(月) 23:58:25.36ID:w2tkTAcI
GO + wasm じゃダメでしゅか？
2020/12/29(火) 00:52:45.33ID:hwRKbE5U
よい！
2020/12/29(火) 01:01:09.47ID:X0m1jPo1
wasm自体はGCサポートしてないからGC言語のGoやC#は辛いぞ。
少なくともGCをランタイムに積まないといけない。
そんなわけでwasmにはRustやC/C++ばっか使われるのだ。
C#なんかGCどころかコードをwasmネイティブにすることもできずにwasmでﾄﾞﾄﾈﾄの中間言語インタプリタ動かしてるだけだからなｗ
2020/12/29(火) 01:31:07.52ID:xrSERZg5
>>723
世代を超える時の扱いが雑。Goは敢えて世代管理しないという方向で行ってるが、ほぼパーフェクト。
そのせいでstackallocとか作っててワロスって感じ。

古いAPIを残してる分には良いだろう。
Obsoleteもついてないってどう言うことよ。
なんでhttpアクセスすんのにあんなに方法あんのよ。HttpClientは罠実装だし。

うまくできてない。ConfigureAwaitメソッドなんか要らない、と言えるようになってから言え。

ValueTaskを選んでおけばという発想がおかしい。
stackallocと同じ方向性の解決法。
選択肢は解決ではない。ちゃんとコンパイラがやれ。

ランタイムのバージョンアップを回避する必要性がわからん。必要ならしろよ。
それは後方互換性とは言わんでしょ。
個人的にはその寿命が伸びる件で踏み抜いたので割と嫌い。
2020/12/29(火) 02:30:03.59ID:c62SKept
また来たよ
もう金渡すから消えて
2020/12/29(火) 06:47:47.18ID:awsGRXp2
wasmにGC載せる計画はあるみたいだけど、そのGCはおそらくJSのGCと同一だろう。ChromeではwasmがTurboFan上で動くのと同様に。
これが移植上ネックになることもあるのかな、と上のを見ながら思った
2020/12/29(火) 06:50:26.39ID:awsGRXp2
あと、C#の話する時はC#って書いてくれ。NGするから
2020/12/29(火) 07:25:05.07ID:iWtJxFHh
WebAssemblyをNGわーどにしたら？
2020/12/29(火) 07:35:42.01ID:ZrXqpCJW
ワッチョイ付ければNG楽になるよ？
2020/12/29(火) 09:33:32.36ID:KX/n8CkP
一時期ﾜｯﾁｮｲｽﾚもあったけどなんか毛嫌いするヤツが多かったんだよな
2020/12/29(火) 11:29:58.07ID:b5xW7Gve
>>736
>世代を超える時の扱いが雑
どういうふうに雑だと感じた？
Goは世代管理をしないと言うがJSやその他の言語はどんな実装になってる？

>Obsoleteもついてないってどう言うことよ
高い互換性おかげで問題なく動作するから無理して修正する必要がないからではないかな
次期バージョンで消える可能性すらない安定したAPIになぜお節介にもObsolateを付けた方が良いと考えたの？

>なんでhttpアクセスすんのにあんなに方法あんのよ
複数の方法が共存するのは言語が後方互換性を維持しつつ順調に成長している証拠
君の考えかただと新APIだけ残して古いAPIは削除して後方互換性破壊することになる
唯一のAPIを残して他を削除すべきと考えたのはなんで？

>ConfigureAwaitメソッドなんか要らない
ConfigureAwaitはプログラム文脈から機械的に判断できないコンテキストの切り替えをコントロールするためのメソッドだ
これがないとプログラマはコンテキストの切り替えをコントロールできなくなってしまう
なぜコンテキストの切り替えをコントロールできないほうが良いと思った？

>ValueTaskを選んでおけばという発想がおかしい。
なぜ発想がおかしいと考えた？

>ランタイムのバージョンアップを回避する必要性がわからん
古いプログラムをそのまま動作保証するのに最も確実で安全で低コストな方法がランタイムをそのまま維持することだからだよ
なぜ破壊的変更が紛れ込む可能性があるのに変えなくてもいいところまでわざわざ変えたほうがいいと考えた？
2020/12/29(火) 11:47:10.79ID:awsGRXp2
その毛嫌いしてたのってC#おじさんじゃね？
2020/12/29(火) 12:02:26.55ID:Fq3XcUlo
TypeScriptも互換性維持のために同じ運命を辿るのだろうか
同じ作者だし
いまイケてる言語、フレームワークもいつかはレガシーに
ナウなヤングは気付いたらおじさんに
2020/12/29(火) 12:32:52.41ID:awsGRXp2
そのへんはある程度はしゃーない。
そうなったらいかにナウなヤングの邪魔をしないようにするか、いかに限られたリソースでキャッチアップするか考えるさ。
それまでに沢山経験積んどかなきゃ……
2020/12/29(火) 12:39:50.65ID:Fq3XcUlo
>>746
みたいなバイタリティある人はいいけど
大半の人間は潰しが効かなくなるだろうね
フロントサイドしかやってない人とか特に…
2020/12/29(火) 12:41:22.77ID:k23+wtCh
Cordovaは、iOS, Andoid, macOS でJSで書いたプログラムをWebViewを
使ってAppStoreやGooglePlayに登録できるアプリとして作製できるが、
iOS 11 以上だと、Wasmも実行できるらしい。Androidでは当然出来る。
そして端末の独自機能にJSやWasmからアクセスできる。
ファイルアクセスなども可能。
仕組みはJSと端末との間で通信するブリッジを用意している。
つまり、Wasmとして出力したプログラムは、Cordovaを使えば
モバイルOSで、ファイルシステムや端末の独自機能をフルアクセス
できるようになるらしい。
HttpServerなどを使ってJSとnative APIとの間が仲立ちされているので
JSからnative APIが全て使用できるだろう。
2020/12/29(火) 12:49:48.81ID:k23+wtCh
>>748
nativeアプリの仕組みはこうだ：
1. 時間や乱数を利用してパスワードの様なセキュリティートークンを作る。
2. Posix Socketを使ってLocal Http Serverを作る。ポート番号を5000とする。
3. WKWebViewなどのWebViewを使ってHtml+JSのプログラムを起動する。
4. 2 や 3 を起動するとき 1 のトークンを2と3の両方に渡す。
5. JSが端末の独自機能を使いたい場合、fetchやXmlHttpRequestを使って
　http://localhost:5000/機能名?トークン&パラメータ
　の様なURLでLocal Http Serverにアクセスする。
6. Local Http Serverは、トークンが正しい場合にのみ動作するようにする。
　機能名とパラメータに応じてファイルの読み書きや端末の独自機能のAPIを呼び出す。
7. APIの結果は、Http プロトコルの response で JS 側に返す。
8. JSは結果を受け取る。
2020/12/29(火) 12:54:14.36ID:4hVd0nGl
wasmってブラウザだけじゃなくK8SでもIoTデバイスでも動くわけだし
モバイルでも動かしたいって欲求も当然出てくるだろうな
そうなるとストアアプリの実装言語も将来的に何でもありになるのかもね
2020/12/29(火) 13:29:33.29ID:xrSERZg5
>>743
nodeなんかはインクリメンタルではなかったっけ。
Javaはアプリの仕様に合わせて好きに選べる。
awaitで寿命が伸びる件と相性が悪いけど、あまりにも世代1に行き過ぎ。
ライブラリ関数ではゼロアロケーション意識しないといかんレベル(ライブラリ関数でgcが起きるとgen0がライブラリ関数で尽きるので呼び出し元がgen1にあっさり追い出される)
.net coreでやっとある程度柔軟にはなったものの。

無理して修正する必要はない。
逆だろ。処理系のバージョンアップ側にメンテナンスコストかかり続けるじゃん。
それ言い続けて、限界を迎えたら.net core？
アホかな。

後方互換性を維持しつつ順調に成長してるならば、関数が変わるよな。
実のところ、本館、新館、別館と建て増した温泉旅館だよ。
古いAPIは2世代ぐらいで殺すべきだろ。
なんで.NET FWがあんなに亀レベルでしか成長できなかったと思ってんの。

コントロールできない方が良いんではない。
コントロールする必要があるのがアホかなって言ってる。
UIスレッドだけ特別扱いしてるところからわかるだろ。
中途半端。

発想がおかしい理由がわからんならもう黙れよ。

古いプログラムをそのまま動作保証するために必要なのは、互換性ではなく、そのバージョンをLTSにしてちゃんとパッチ出してく事だよ。
で、SideBySideできるようにするか、コンテナにするかどっちかだろ。
バージョンアップするけど(だいたい)互換性はありまぁすとか言ってるから、2020年なのに.NET FW 4以上に上げられん基幹系みたいな負の遺産を残すんじゃないか。

お前が言ってることはC#というか.NETを何度もだめな言語にしてきた老害の発想だからな。
C#が好きならちゃんと考えろよ。
2020/12/29(火) 13:57:14.43ID:Fq3XcUlo
すっげえわかる
MSってほんと最低な奴だよな…
2020/12/29(火) 14:21:44.49ID:xrSERZg5
ホントに他の言語やれと。
俺ずっとVue+JavaScript派だったけど、最近何周か遅れてReact+TypeScriptやってて、これはこれで確かにいいなと思ったりしてるぞ。
いろんな設計思想があるのは良いじゃん。最強で至高なんかねえよ。
めっちゃ叩いたけど、そのすぐ裏側はC#の良いところなのもわかってるからな。
2020/12/29(火) 14:36:53.53ID:EHaGj/ct
>>751
>Javaはアプリの仕様に合わせて好きに選べる。
結局のところアプリのメモリ使用特性に合わせて選択するのが賢いのであって特定の実装が良い悪いという絶対的な指針はないのだろうね
ではなぜ君は.NETのGCが絶対的に悪いような言い方をしたのかな？

>awaitで寿命が伸びる件と相性が悪いけど、あまりにも世代1に行き過ぎ。
awaitシンタックスシュガーで変数の寿命が伸びていたのは昔の話
少なくとも7年前には非同期を跨がない変数はキャプチャされなくなった
なお非同期をまたぐ変数の寿命が伸びるのは非同期処理の宿命でありawaitシンタックスシュガーは関係ない
なぜ君はawaitシンタックスシュガーが変数の寿命を伸ばすことを問題視したの？

>ライブラリ関数ではゼロアロケーション意識しないといかんレベル
C#のメモリ管理サポートは.NET Coreで急激に進歩している
他の多くの高級言語ではゼロアロケーションを意識しても難しいがC#ではそれほどでもない
これはパフォーマンス意識する上で非常に大きい
アロケーションを減らせるならGCの負荷も小さくなる
JSなど他の言語では機械的な最適化以外にメモリ確保そのものを大幅に減らす工夫はあるのかな？
2020/12/29(火) 14:37:48.66ID:EHaGj/ct
>処理系のバージョンアップ側にメンテナンスコストかかり続けるじゃん
いやいや処理系のメンテナスコストは低いよ
だって仕様が変わってないんだから
シンタックスシュガーのバージョンアップで変化するのはコンパイラのほうね

>それ言い続けて、限界を迎えたら.net core？
Coreへの移行はメンテナンスが累積して限界を迎えたから行ったわけではないよ
主な理由はマルチプラットフォームへの対応を迫られたから

>実のところ、本館、新館、別館と建て増した温泉旅館だよ。
>古いAPIは2世代ぐらいで殺すべきだろ。
その本館も新館も別館も安定稼働してお金を稼ぎ続けている
なのになぜむりやりお金をかけてまで閉じる必要があるのかな？

>なんで.NET FWがあんなに亀レベルでしか成長できなかったと思ってんの。
.NET FWというかC#の成長は速かったよ
いくつもの先進的な機能たとえばLinqだとかReactiveExtensionだとかAsync/Awaitだとかを生み出して
他の言語はC#を追いかけるように機能を模倣してきた

>コントロールする必要があるのがアホかなって言ってる。
コントロールする必要がなければデフォルトでいいよね
コントロールしたいときにできないのは大きな問題だとは思わないかい？

>UIスレッドだけ特別扱いしてるところからわかるだろ。
これは言語の問題ではなくOSアーキテクチャの成約ね
他の言語だってUIスレッドは特別なもの
もしコンテキスト切り替えをコントロールできない言語だと特別なスレッドのために他の関係ないスレッドがパフォーマンス上の不利益を被る
2020/12/29(火) 14:38:21.55ID:EHaGj/ct
>発想がおかしい理由がわからんならもう黙れよ。
わからないから説明をしてほしいのだけど？
根拠も理由もなく発想がおかしいというだけではまったく意見になってないよ

>古いプログラムをそのまま動作保証するために必要なのは、互換性ではなく、そのバージョンをLTSにしてちゃんとパッチ出してく事だよ。
.NET FWはそのあたり手厚いね
未だにWinアップデートで3.5のセキュリティパッチとか落ちてくるでしょ？

>で、SideBySideできるようにするか、コンテナにするかどっちかだろ。
.NETはSBSもサポートしているね
コンテナ化することをそのまま動作保証とは普通は言わない

>バージョンアップするけど(だいたい)互換性はありまぁすとか言ってるから、2020年なのに.NET FW 4以上に上げられん基幹系みたいな負の遺産を残すんじゃないか。
負の遺産ではなく未だに安定して利益を生み出す正の遺産だよ
負の遺産っていうのは言語のAPIが急にサポート切れになって大幅な改修を入れなければならなくなり開発コストで大損したみたいな場合ね

>お前が言ってることはC#というか.NETを何度もだめな言語にしてきた老害の発想だからな。
C#が駄目な言語になったことなんてないよ
VBという悲しい過去があるので.NET全体を称賛するわけにもいかないが
C#は常に成功してきたしこれからも成功する言語だと確信している
2020/12/29(火) 14:46:23.51ID:xrSERZg5
>>754
絶対的に悪い部分はあるだろ。
「挙動の変更不可」。
「GCの挙動が気に食わん」の解決法が「別のGCを選べる」というのは、GCの設計として正しい。
「気に食わんけど耐えるしかない or ワークアラウンドで対応」
これはなんの解決でもない。

非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの？

難しくないから、人間がやれば良い？
アホか？
じゃあGoみたく、ベンチツールにデフォでアロケーションカウンタついてるのか？
そうでもないだろ。
他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
2020/12/29(火) 14:54:23.36ID:xrSERZg5
>>755
高いよ。
お前あんまりミッションクリティカル系でC#使ってないだろ。

違うよ。マルチプラットフォームへの対応だけであればPCL、.NET Standard、あのあたり何だったことになる？
特にPCL。あれで現に破綻しただろ。

安定稼働してお金を稼ぎ続けてるなら、3棟それぞれメンテしろ。
お金をかけてまで維持するのとお金をかけてまで閉じるのは同じ話だ。

>>755
言語仕様は早かったな。
で、2016年まではawaitでキャプチャしてたとか、歪な形になってたわけだ。
その頃のアセンブリはもちろんその頃のまま。パフォーマンスもお察し。
さらに今のコンパイラでコンパイルしたものとILは異なるよな。
そのあたりで踏み抜くものが多すぎるんだよ。

コントロールしたいときに出来ないとかそんな事を言う時点で「スレッドプールとは」って話なんだよ。

UIスレッドだけ特別視するのが悪いと言ってるんじゃない。
「UIスレッドはちゃんと勝手にConfigureAwaitできてるじゃん。お前らなんで他のコードでも同じように勝手に処理されるように、メソッドの属性とかそういうもので解決しなかったの？」という話なんだよ。
手動設定信仰過ぎるだろ。
2020/12/29(火) 14:56:52.79ID:EHaGj/ct
>>757
>「挙動の変更不可」。
.NETもパラメータである程度の調整はできるようだが…
アルゴリズムを手軽に差し替えるような解決策が用意されている言語はどれほどあるのだろうか？

非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの？

難しくないから、人間がやれば良い？
アホか？
じゃあGoみたく、ベンチツールにデフォでアロケーションカウンタついてるのか？
そうでもないだろ。
他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
2020/12/29(火) 14:58:38.03ID:xrSERZg5
>>756
ほう、4.0と同時に入れられる4.xがあるなら手厚いと言えるだろうな。

コンテナ化する事を動作保証と言うぞ。
というか、完璧に構成管理してやっと動作保証できるものであって、コンテナ化に関しては理想型だろ。

安定して利益を生み出す、で履き違えるな。
負の遺産と言うのは、現状利益を生み出しているかとは全く関係のない尺度だ。

言語のAPIが急にサポート切れ、な。
いつ誰がやらかしたかな？
2020/12/29(火) 15:05:12.04ID:xrSERZg5
>>759
焦って途中でレスすんなよみっともない。

ほかのすべての言語はできるがC#だけは出来ない、と言ってるんではない。

C#が得意な事とそうではない事があることは認識しろ、と言ってる。

他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#なら、C#でも、ってのは、そりゃ原理上可能だろ。可能じゃなかったらチューリング完全でない。
ただ、向いてるかって聞くと、それぞれもっと向いているものを知ってる人間は居るってことなんだよ。

ちょっと冷静に考えろ。

C#は好きだが、議論の道具として叩いてて、反対側にはメリットもあるのはわかってんよ。
2020/12/29(火) 15:10:39.54ID:EHaGj/ct
>>757
>「気に食わんけど耐えるしかない or ワークアラウンドで対応」
>これはなんの解決でもない。
GCの差し替えができないならそうするしかない
C#は他の言語と違って安全なメモリ管理サポートが充実しているので「耐えるしかない」ということはない

>非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの
非同期を跨いで利用される変数のスコープが伸びることは必然だから問題じゃない
もし問題だというならそれはシンタックスシュガーのせいではなく非同期アルゴリズムの設計に問題がある
言語のせいではなく設計ミス

>他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
そうじゃない「他の言語でできないor難しいことが簡単に出来る」と言ってる
たとえばC#のref構造体やspanのように安全に低頻度のアロケーションをサポートするスクリプトが幾つあるだろう
2020/12/29(火) 15:24:29.79ID:EHaGj/ct
>高いよ。
>お前あんまりミッションクリティカル系でC#使ってないだろ。
処理系のメンテコストの話がミッションクリティカルでのC#利用経験の話になるのはなぜ？

>違うよ。マルチプラットフォームへの対応だけであればPCL、.NET Standard、あのあたり何だったことになる？
>特にPCL。あれで現に破綻しただろ。
PCLは確かにあまりうまく行っていなかった
うまく行っていなかったからこそだ
本格的なマルチプラットフォーム対応のためのCoreでありStandard

>安定稼働してお金を稼ぎ続けてるなら、3棟それぞれメンテしろ。
>お金をかけてまで維持するのとお金をかけてまで閉じるのは同じ話だ。
もちろんメンテナンスは続けてるだろ
古いコード新しいコード両方が安定して稼働するからこそ安価にメンテナスが可能となる
APIが急になくなったらちょっとしたメンテナンスでも大騒ぎだ

>そのあたりで踏み抜くものが多すぎるんだよ。
多すぎるというからには何かしら数字が出てるのだと思うけど示せる？

>コントロールしたいときに出来ないとかそんな事を言う時点で「スレッドプールとは」って話なんだよ。
すまん
正直意味不明なので説明を求む

>なんで他のコードでも同じように勝手に処理されるように、メソッドの属性とかそういうもので解決しなかったの？」という話なんだよ。
その属性をつけるのは結局手動だろう？
自動化信仰も結構だが世の中全てを自動化できるわけではない
手動で解決してる理由は機械的、自動的に決定できないからだよ
機械的、自動的に決定できないものに対して取れる最もマシな方法は昔から決まってて
事故が起こりにくい方をデフォルトにする
どちらも安全なら統計を撮って利用頻度で決める
2020/12/29(火) 15:34:45.80ID:EHaGj/ct
>>760
>コンテナ化する事を動作保証と言うぞ。
いや言わない
基本的に今まで動作していた環境で同じように動作することを動作保証という
新しくコンテナに載せ替えるかどうかは動作保証とはまったく別のベクトルの話であって関係がない

>安定して利益を生み出す、で履き違えるな。
>負の遺産と言うのは、現状利益を生み出しているかとは全く関係のない尺度だ。
技術的負債のことを言いたいのだろうけど
古いAPIが全て負の遺産であるような認識は典型的な間違いだぞ
たとえ古いAPIを使っていてもテストが整備されていて設計が美しく開発環境の準備が難しくないならそれは借金でもなんでもない

>言語のAPIが急にサポート切れ、な。
>いつ誰がやらかしたかな？
.NETでは幸いなことにまだぶち当たったことがない
2020/12/29(火) 15:40:20.23ID:Fq3XcUlo
なげーなー
C#はSPAには特化してない
歴史的な経緯があるからそのせいで扱いにくいこともある
SPA作るなら特化しているReact+ts使った方が幸せになれる
ってこと？
2020/12/29(火) 15:43:25.20ID:EHaGj/ct
>>761
>焦って途中でレスすんなよみっともない。
うるせえな寒くて手が滑ったんだよ
暖房つけたからもう大丈夫

>C#が得意な事とそうではない事があることは認識しろ、と言ってる
C#より上手く特定の分野を実装できる言語はあると思う
しかしC#は各分野で最高とまでいかなくとも何でも得意で
C#が特別に苦手なことというのはない
そういう成績オール5 or 4的なところが気に入ってる

>他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#を使えるなら他を使う「積極的」なメリットは無い
他の言語が特別に得意な分野がどうしても必要なときに仕方なくその言語を使う程度の塩梅でおｋ
2020/12/29(火) 15:49:41.14ID:EHaGj/ct
>>765
>C#はSPAには特化してない
SPAについてはまだまだ黎明期

>歴史的な経緯があるからそのせいで扱いにくいこともある
新規に開発する分には扱いやすい
レガシーがモダンと比較して扱いにくいことがあるがそれはレガシーなので仕方がないこと
レガシーが安定して動作するよう後方互換性とセキュリティパッチが充実しているので
レガシーのメンテナンスを最小化することができる

>SPA作るなら特化しているReact+ts使った方が幸せになれる
人による
現時点ではReact+TSのほうが支持者が多い
2020/12/29(火) 15:51:29.01ID:xrSERZg5
>>766
全部言い訳だわ。
GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか？

IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う？
ケース知らなすぎるだろ。
他の事も色々間違ってるがもうそもそもおかしい。

C#は別になんでも得意じゃねえぞ。
オール3だよ。
C#でこれは4だなって思うのはLinqぐらいだ。それももう追いつかれた。
他の言語を知らんから、本当の5を知らんのだろ。

積極的なメリットは無い。知らないからそりゃそうだろうな。
それでC#が好きだとほざくな。
2020/12/29(火) 15:55:19.91ID:yginI0z/
・・・本当の5の言語って何や？
2020/12/29(火) 16:04:46.05ID:xrSERZg5
>>769
人とニーズによるだろうけど、Goの並行処理とか、
Erlangのメッセージパッシングとか、
F#の測定単位とか、
Lispのマクロとかかな。
JavaScriptも、あれはあれでとても良いと思う。
2020/12/29(火) 16:08:35.63ID:b5xW7Gve
>>768
>GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか？
大抵のことはGCで問題ない
クリティカルなところでのC#なら安全に比較的細やかにメモリ管理ができるので問題ない

>IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う？
当たり前だがDisposeするまでだろ
非同期挟もうが挟むまいが不要になった時点で速やかに破棄される
awaitを使ったからと言って必要もないのに無駄に変数の寿命が伸びることはないよ
伸びるのは非同期処理を実装するのに本当に必要な変数だけだ

>本当の5を知らんのだろ。
例えば？
2020/12/29(火) 16:11:47.13ID:Fq3XcUlo
>>769
5=GOなんだろ
ダジャレだよダジャレ
エスプリの効いたギャグをかましてくれたんだよ
2020/12/29(火) 16:24:08.58ID:Fq3XcUlo
>>770
これ特化してるところじゃん
あらゆる分野において平均以上かどうかなんじゃないの

ジェネラリストかスペシャリストか
2020/12/29(火) 16:24:33.75ID:b5xW7Gve
>>770
果たしてそれがメインの開発言語を乗り換えるほどの価値があるかどうかだよね
自分はとてもではないがそうは思えない
もし本当にどうしても避けられずそれが必要になったら局所的にその言語で実装してメイン言語から呼び出すって形にするだろうな
まあGoぐらいなら別にメインにしてもいいかなぁ…とは思うがね(実際にはしないだろうけど)
2020/12/29(火) 18:16:37.52ID:Hcyt9B7d
C#は素敵な言語だけどさすがにオール5は言い過ぎたねって話だね
2020/12/29(火) 18:29:46.92ID:Cpv18UIo
なんでこの人たちいつもC#の話してるの？
2020/12/29(火) 18:30:27.64ID:xrSERZg5
>>773
5ってのは、そういう事だと思うぞ。
4で、それが書きやすい、程度。

>>774
ニーズ次第じゃないかな。
2020/12/29(火) 18:44:00.86ID:awsGRXp2
オール5の言語なんてLispしかないよ！DSLで何にでも特化できるから！神はLispで世界を作ったんだぜ！（ぐるぐる目）

冗談はさておき、昔のJSはLispの匂いがして好きだった。今は（TSは）Lispの匂いほぼなくなって、万人ウケしやすい言語になったと思う。
2020/12/29(火) 19:19:37.56ID:xrSERZg5
>>778
ほんとにそれよね。JSはC構文のLispっぽくて好きだったけど、TSでどんどん静的な言語になってしまってる。
2020/12/29(火) 19:25:03.79ID:PuaagtBb
高階関数で関数型プログラミングの匂いはするがLispの匂いはしない
Lispって全部がリストになってるから
2020/12/29(火) 19:35:30.70ID:xrSERZg5
>>780
applyと分割代入あたりが、おおむね対応するんではなかろうか。
2020/12/29(火) 19:39:46.86ID:LSI+C1uB
C#をNGにしたら書き込み全部消えちゃった
2020/12/29(火) 19:41:55.81ID:xrSERZg5
まあ、作った人がScheme意識してるって言ってるからな。
https://brendaneich.com/2008/04/popularity/
2020/12/29(火) 19:47:54.10ID:awsGRXp2
全部がListだったらそれはもう匂いがするどころではなくLispそのものだと思う。
Lisp脳だったのでTS始めた時は型演算そのものを(Lispみたいに)JSで書かせてくれと思ったよw
2020/12/29(火) 19:53:01.60ID:awsGRXp2
Lispの匂いといえばMozillaのlet式が没ったのは返す返すも残念だった。今はdo式に期待してる
2020/12/29(火) 21:12:55.98ID:LSI+C1uB
>>778
Lispのどこがいいんだ？
全てにおいて不便なだけな気がするのだが
2020/12/29(火) 23:06:44.05ID:awsGRXp2
Lispのデータとソースコードは全てListである。
Lispは主にListを操作してプログラムする。
Lispには文は無く、式だけがある。
LispのマクロはListであるLispソースコードの操作をLispで行う。
Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。あらゆるコードを抽象化できる。

スレ違いだからあとは調べてね。
これは個人的な所感だけど、
ありとあらゆる式文が作れる（抽象化できる）ってことはつまり俺ルールがまかり通って分断を招く言語って事だから、そりゃ一般向けじゃないやね
2020/12/29(火) 23:19:25.78ID:c62SKept
>>787
そのせいでクオートとか関数クオートみたいな邪悪な存在が生まれたのは無視かな？
2020/12/29(火) 23:26:15.08ID:Ba9B66hW
>>787
長々と書いてるがメリットってこれだけだろ？

> Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。

DSLを作りたいやつがどれだけいるか知らんが
DSLというのはただの関数に過ぎない
だからどの言語でも関数を作ることで簡単にDSLを作れるぞ
2020/12/29(火) 23:36:01.58ID:awsGRXp2
細かい反論はあるけど概ねご批判の通りだよ。
だから流行らない。俺は好きだけどね
2020/12/29(火) 23:38:23.99ID:Ba9B66hW
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E7%89%B9%E5%8C%96%E8%A8%80%E8%AA%9E/

> DSLは、大きく内部DSLと外部DSLに分類することができます。
>
> 内部DSL: 内部DSLは、汎用のプログラミング言語の書き方を工夫して、
> 見かけ上の構文を自然言語に近づけた言語です。
書き方を工夫するだけだからどの言語でも出来る

> 外部DSL： 外部DSLは、汎用のプログラミング言語とはまったく別の構文を持ったDSLです。
こっちはlispでも作りづらい
2020/12/29(火) 23:46:09.89ID:Ba9B66hW
内部DSLの場合、言語によって自然言語に近づけるといっても限界がある場合がある

えばC言語なら、 This("is", "a", "pen"); が限界だろう

これがRubyだと This "is" "a" "pen" となる
is とか a とか を定義すれば、This is a "pen" と書けるかもしれないな

だがシェルスクリプトであれば This 関数を作るだけで
This is a pen と書くことが出来る。
ダブルクォートでくくらなくても文字列として扱われるからだ

内部DSLを作るのに一番適した言語はシェルスクリプトだと思うが
それはそれとして、DSLを簡単に作れる言語の条件はリスト操作をしてるとかではなく
引数を () でくくらなくても良いとか最後にセミコロンがいらないとか
そういう言語ではないだろうか？自然言語は () でくくらないからな
2020/12/29(火) 23:52:22.87ID:Ba9B66hW
引数の区切りにカンマが不要ってのもDSLに適した言語の条件かな
2020/12/30(水) 00:05:32.15ID:TuVgzDLD
>>789
kotlinぐらいじゃないかな。
無茶めな構文が変わるレベルのDSLが作れるの。

S式として成り立ってればどんな構文すら作れるから、関数を作ることで作れるとか言ってるレベルじゃないぞ。
それが良いことかはおいといて。
2020/12/30(水) 00:08:13.49ID:Zk/FBUc0
どんな構文でも作りたいわけじゃない

「自然言語」に近い構文を「簡単に」作れるというのが条件
自然言語というのはシンプルで、単語を並べるだけなのだ

仮にkotlinでC言語の構文に対応できたとして
それはDSLとしてはふさわしくない構文
2020/12/30(水) 00:08:25.33ID:olxuh5fb
>>789
JuliaとRustはそこそこ無茶なこともできるしな
ASTレベルでの操作だし
Lispプログラム=実質的なASTと考えると何も変わらん
そこの優位性ももはやない
2020/12/30(水) 00:15:06.44ID:Zk/FBUc0
>>796
だからプログラム言語を作りたいんじゃなくて
DSL（自然言語風）を作りたいんだってばｗ
2020/12/30(水) 00:19:04.50ID:Zk/FBUc0
あと「簡単に」ってのも重要
作れるけど大変っていうのは簡単ではない
2020/12/30(水) 00:19:15.74ID:olxuh5fb
Lispは自然言語風ではないだろ
あの括弧なんとかしろよ
2020/12/30(水) 00:21:48.47ID:TuVgzDLD
DSLって別に自然言語に寄ってなくても良いんじゃないか？
ドメイン記述に便利な表記であればそれで良いかと。
昔ウィジェットツリーをそのまま書いたらマクロで展開されるとかそういうの書いたことあるけど、自然言語寄りではなかったな。
最近で言うとkotlinのankoみたいなやつ。
2020/12/30(水) 00:26:09.36ID:Zk/FBUc0
> DSLって別に自然言語に寄ってなくても良いんじゃないか？

それは正しいが「自然言語と異なる別のプログラム言語」を
覚え直さなければいけないのはナンセンスだろ
2020/12/30(水) 00:26:50.79ID:Zk/FBUc0
（なぜか「当分お断りしております。」が出たので分割して書き込み）

独自のDSLを作る場合、新たな言語を覚えなおさなくていいように
誰もが知ってる自然言語に近い構文にするのが普通
2020/12/30(水) 00:27:23.67ID:Zk/FBUc0
そうしないとDSLを使うことで
2020/12/30(水) 00:28:25.07ID:Zk/FBUc0
ぎゃくにこーどがわかりづらくなる
DSLの特徴である「ドメイン固有の処理を簡単に表現できる」に反してしまう
2020/12/30(水) 00:29:06.25ID:Zk/FBUc0
（なんで「ぎゃくにこーどが」を漢字とカタカナにしたら書き込めないんだ？）
2020/12/30(水) 00:30:13.27ID:Zk/FBUc0
「コ　ー　ド」をスペース抜いたら書き込めない
2020/12/30(水) 00:34:39.76ID:DCxLNcGT
こうやって言語機能そのものみたいな基本部分の重箱つついて、何かあるとすぐちゃぶ台返しして応用や発展的な話題出ないの最高に5chのプログラム板って感じ
2020/12/30(水) 00:35:42.82ID:olxuh5fb
そもそもすれ違いだぞ
2020/12/30(水) 00:41:11.57ID:Zk/FBUc0
>>807
そういうことじゃなくて「色々出来る言語」を過大評価しすぎってこと
簡単に目的を達成できる方が重要なのに
色々出来るんやでだからすごいっていう考えが古臭い
2020/12/30(水) 00:56:40.62ID:lXmFrXZN
コード
2020/12/30(水) 00:59:28.01ID:nb9M1V+x
>>810
どうやらブラウザ（ユーザーエージェント？）も関係あるっぽい
Chromeでは書き込めず、Firefoxなら書き込めた
その他の情報も見てる可能性があるな
IPアドレスは変えてもクッキー消しても意味はなかった
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況