虹裏img歴史資料館

1 21/07/10(土)01:10:29 No.821827858

全部やれ

2 21/07/10(土)01:12:36 No.821828436

とりあえず全部触ってよさそうなの選びなよ

3 21/07/10(土)01:13:58 No.821828771

ちなみにElmはHaskellと組み合わせようと思ってます！ 最近のHaskellはGHC拡張でJSON見てから型作成も余裕でサーバーサイドよさそう

4 21/07/10(土)01:15:29 No.821829196

>iOSアプリやWebサービス全般作りたくて まずどっちかにしろ

5 21/07/10(土)01:16:10 No.821829376

>全部やれ >とりあえず全部触ってよさそうなの選びなよ 一通り軽くは触ってみたんだけどなんかよくわからなくて 将来性はReasonML抜群に見えるけど なんか微妙にOCamlとちがくて使い勝手がわからない

6 21/07/10(土)01:17:10 No.821829668

>まずどっちかにしろ WebViewでやります！ Elm良さそうなんだけどこれだとElmが絶望的なんだ…

7 21/07/10(土)01:18:32 No.821830098

WebViewで全部やるならCordovaで動く環境作れる奴が保守楽かな…

8 21/07/10(土)01:18:47 No.821830172

portsがよくわからないから踏み切れない なんか適当にHTML引っ張って来てDOMにぶっこんでquerySelectorとかバシバシ呼ぶとか全然想定されてなさそうで

9 21/07/10(土)01:20:22 No.821830611

>WebViewで全部やるならCordovaで動く環境作れる奴が保守楽かな… そうなると一番バランスのいいReasonMLかな 素直なjsコード吐いてくれるし 自分の趣味的にはF#ならうひょーってなったんだけどな…

10 21/07/10(土)01:22:06 No.821831053

ちなみにTypeScriptがいやで逃げ出してきました

11 21/07/10(土)01:23:01 No.821831266

F#は追いかけてないからコンパイル環境知らないけど今の.NETはスマホからWebサービスまでランタイム的にはサポートしてるよ

12 21/07/10(土)01:25:39 No.821831903

>F#は追いかけてないからコンパイル環境知らないけど今の.NETはスマホからWebサービスまでランタイム的にはサポートしてるよ Xamarinを言ってるなら動くとは思うけど自分で0からウィジェット作る羽目になったりしたから辞めた あと.NETはPWA作れないから今からはWebにはちょっとつらそう

13 21/07/10(土)01:26:56 No.821832207

flutterとかでやればええんでないかなjavascript少しできるなら何とかなる

14 21/07/10(土)01:28:45 No.821832620

Haskellそういや依存型入るかもって話どうなったんだろう

15 21/07/10(土)01:28:52 No.821832644

>flutterとかでやればええんでないかなjavascript少しできるなら何とかなる flutterってDartが主体じゃなかったっけ？用意されてるの？

16 21/07/10(土)01:31:18 No.821833251

>Haskellそういや依存型入るかもって話どうなったんだろう https://github.com/ghc-proposals/ghc-proposals/pull/378 入ってるっぽいね まあ厳密に言うならHaskellではないけど

17 21/07/10(土)01:32:24 No.821833503

>Xamarinを言ってるなら動くとは思うけど自分で0からウィジェット作る羽目になったりしたから辞めた あーXanarinネイティブはめどいね…Xamarin Formsはイマイチだし…そういうとこ楽にしたいなら辛いかも >あと.NETはPWA作れないから今からはWebにはちょっとつらそう そっちは今BlazorってのができてWebAssemblyが直接吐ける

18 21/07/10(土)01:34:29 No.821833955

>そっちは今BlazorってのができてWebAssemblyが直接吐ける 今まさに見てたけどこれかなりよさそうだね F#もいいかもしれない ただこれMSの文書見るとJavaScriptも書く必要ありそうだけどjsなしでもいける？

19 21/07/10(土)01:36:57 No.821834518

>F#もいいかもしれない >ただこれMSの文書見るとJavaScriptも書く必要ありそうだけどjsなしでもいける？ 俺は今Uno Platformってのに全部面倒見てもらってるからこれを生で触ったことはないんだ ごめんね

20 21/07/10(土)01:39:28 No.821835072

>俺は今Uno Platformってのに全部面倒見てもらってるからこれを生で触ったことはないんだ >ごめんね すごく良さそうなのにF#使えないって書いてあるんですけど… ひどいよ…

21 21/07/10(土)01:44:23 No.821836221

>ひどいよ… どう見ても人足りてないからね… Xamarin Formsなんて捨ててMSはここを買収してほしい… .NET6で新しいマルチプラットフォームフレームワーク来るみたいだけど期待してない

22 21/07/10(土)01:46:10 No.821836661

>俺は今Uno Platformってのに全部面倒見てもらってるからこれを生で触ったことはないんだ >ごめんね Xamarinはあんまり印象良くなかったけどそれはいい感じなの？ AndroidやiOSわからんちんでも使える？

23 21/07/10(土)01:49:15 No.821837411

blazor使ってるけどjsは結局触ることになると思う

24 21/07/10(土)01:49:57 No.821837604

>どう見ても人足りてないからね… >Xamarin Formsなんて捨ててMSはここを買収してほしい… githubで5k行ってるしこれ自体は人気はあるみたいだね 自分でF#対応できないかな？無理かなー…

25 21/07/10(土)01:50:56 No.821837852

>blazor使ってるけどjsは結局触ることになると思う やっぱりそうか… WASMだからまあそうだよね界面でFFI的な部分必要だし

26 21/07/10(土)01:52:21 No.821838239

Elmはそこそこ規模のあるWebサービスでも使われたりしていて その4つの中だと一番良さそうに思える iOSアプリとかのスマホネイティブはスマホの事情が沢山あって辛いので まずSwiftやるのがいいんじゃないかな… 仕事はgoとElixir書いてるけど

27 21/07/10(土)01:53:02 No.821838461

blazorのF#バージョンのboleroってのがあるらしいよ

28 21/07/10(土)01:53:35 No.821838579

>Xamarinはあんまり印象良くなかったけどそれはいい感じなの？ 基本はUWPなのでXamarin Formsよりはかなりマシ >AndroidやiOSわからんちんでも使える？ センサーとか使わないなら作れはするけど詰まったときにネイティブの挙動理解してないと原因解析が辛いかもしれない

29 21/07/10(土)01:53:36 No.821838584

>blazor使ってるけどjsは結局触ることになると思う WASMに.NETcore持ってくの容量的に辛そう

30 21/07/10(土)01:54:05 No.821838726

>まあ厳密に言うならHaskellではないけど GHC=Haskellな場面多いよね

31 21/07/10(土)01:54:33 No.821838822

でも最近のMSがめちゃ頑張ってるのはわかった XNA殺した時は何もかもが憎かったが…

32 21/07/10(土)01:54:34 No.821838825

そういえばJs_of_ocamlってどうなったんですか？

33 21/07/10(土)01:56:05 No.821839183

Xamarin.Android使ったことあるけど java用のAPIを極力同名で使えるようにしてるのは解りやすかったな Formsは依存ライブラリを書くのが面倒でいまいちだった

34 21/07/10(土)01:56:08 No.821839195

>基本はUWPなのでXamarin Formsよりはかなりマシ UWPがわからん…まあ良くなったのかな

35 21/07/10(土)01:56:36 No.821839326

>そういえばJs_of_ocamlってどうなったんですか？ BuckleScriptに殺された

36 21/07/10(土)01:58:17 No.821839791

Xamarinはクロスプラットフォームの細かい差異やバグの対処にウィジェット書き直す羽目になったからもう懲り懲りですわ…

37 21/07/10(土)01:59:07 No.821839998

そもそもクロスプラットフォーム開発が人類には早すぎたのでは？

38 21/07/10(土)02:01:16 No.821840649

Webアプリ初めて挑戦してたけど泥繋いでデバッグモードだと再現しないバグとか出てくるとどうステップ踏めばいいかわからなかった

39 21/07/10(土)02:02:35 No.821841017

>Elmはそこそこ規模のあるWebサービスでも使われたりしていて >その4つの中だと一番良さそうに思える 自分も一番良さそうとは思ってる ただ100%本家ライブラリに依存しててコミュニティの規模的に更新止まりそうなのが気になる Scalaとかは最悪外に内部動作も依存できるけどElmは完全に完結してるから… >iOSアプリとかのスマホネイティブはスマホの事情が沢山あって辛いので >まずSwiftやるのがいいんじゃないかな… そこはある程度覚悟してる…差異が出るのは仕方ない

40 21/07/10(土)02:03:05 No.821841167

>そもそもクロスプラットフォーム開発が人類には早すぎたのでは？ Unityは上手くやってるよ！ ゲームだからOS標準のUIコンポーネントを全部無視して UI全部Unity側で作ってるからね！

41 21/07/10(土)02:03:54 No.821841407

１プラットフォーム作るだけでみんな四苦八苦してるのに聖衣プラットフォームなんて無理があるんよ…

42 21/07/10(土)02:04:17 No.821841530

Xamarinネイティブはいい感じなのにXamarin Formsが風評を広げていてMSなんとかしろ

43 21/07/10(土)02:05:30 No.821841899

そっかUnityでWebアプリ書けばいいってのも… いや型定義無いから無理か…

44 21/07/10(土)02:06:48 No.821842229

FacebookってML一族大好きだよな TypeScript対抗のflowもOCamlだったし 流行ってないけど

45 21/07/10(土)02:07:12 No.821842327

>Webアプリ初めて挑戦してたけど泥繋いでデバッグモードだと再現しないバグとか出てくるとどうステップ踏めばいいかわからなかった 最近のでそういうバグは大抵非同期処理の問題が多いね メモリはGC付きのはNull安全できてからかなり減った

46 21/07/10(土)02:08:20 No.821842596

>そっかUnityでWebアプリ書けばいいってのも… >いや型定義無いから無理か… ソシャゲでサーバサイドもC#で書いて.net coreで動かして 一部のコードをクライアントと共有しているのはあるよ F#は多分Unity側が無理…

47 21/07/10(土)02:08:53 No.821842725

非同期例外って地獄すぎませんか？

48 21/07/10(土)02:08:58 No.821842748

TypeScriptは個人的に合わなかった オーバーロードに自前で型チェックもいるとかがもう合わなかった

49 21/07/10(土)02:11:48 No.821843365

>非同期例外って地獄すぎませんか？ 個人的に一定以上の混み合ったアプリはメッセージング系のフレームワーク使ってる Androidとかそれやらないと結局コールバック地獄になるし

50 21/07/10(土)02:12:08 No.821843415

ReasonML知らなかったんだけど凄い良さそう Elm良いなと調べてたんだけど結局React触りたい時に Elmの世界との相性が悪そうと思ったのだがReasonMLは念頭に置いてるっぽい

51 21/07/10(土)02:13:12 No.821843644

>個人的に一定以上の混み合ったアプリはメッセージング系のフレームワーク使ってる >Androidとかそれやらないと結局コールバック地獄になるし メッセージングフレームワークってRxみたいなもの？ すまん知らなくて

52 21/07/10(土)02:13:20 No.821843668

なんで関数型縛りなの

53 21/07/10(土)02:14:13 No.821843852

触りはしたけど結局pureJSとwebpackとelectronでやってる ベーシックなのが一番ドキュメント多くて楽だ

54 21/07/10(土)02:14:37 No.821843945

>ベーシックなのが一番ドキュメント多くて楽だ 人数とドキュメント量は正義だよな

55 21/07/10(土)02:15:18 No.821844085

>ReasonML知らなかったんだけど凄い良さそう AltJSとしては抜群にいいよね トランスパイルしても素直なコードになって破綻しないし 何よりOCamlの強力な型と推論そのまま使えるのがとてつもなく大きい

56 21/07/10(土)02:17:51 No.821844583

>メッセージングフレームワークってRxみたいなもの？ そこまで高度でなくもっと単純にRabbitMQ的な奴を主体に設計を直してコールバックなくす C++だとZeroMQとか

57 21/07/10(土)02:18:47 No.821844798

>なんで関数型縛りなの 他に強い型付けの言語がないから…

58 21/07/10(土)02:23:05 No.821845729

>そこまで高度でなくもっと単純にRabbitMQ的な奴を主体に設計を直してコールバックなくす >C++だとZeroMQとか RabbitMQには個人的にとても辛い思い出があるのだが 複雑な単体アプリケーションにメッセージキュー入れてシンプルにするのは 良いかもしれない なるほどありがとう

59 21/07/10(土)02:23:55 No.821845906

>>なんで関数型縛りなの >他に強い型付けの言語がないから… なるほど そこら辺明るくないから勉強しなきゃと思いつつ何もしてない

60 21/07/10(土)02:26:49 No.821846508

>RabbitMQには個人的にとても辛い思い出があるのだが まああれは振り分けとか巨大サービス前提だからね… 組み込める程度の小さいライブラリ使う感じ 単純でいいならOSのメッセージング機能でもいいけどintentとか大量に送るにはJava経由で遅いからね

61 21/07/10(土)02:28:30 No.821846927

とりあえず.NET周りが自分が触ってた頃よりかなり進歩してるみたいだからもう少し勉強してきます js案件は一通りReasonMLゴリゴリやってみる レスしてくれた人ありがとう

62 21/07/10(土)02:29:55 No.821847224

.NETはMSが気合い入れてるよね