アカウント名:
パスワード:
Windowsアプリが作りたい：C#でいいじゃんマルチプラットフォームでGUIアプリが作りたい：Electronでいいじゃん or Webアプリでいいじゃん
Embrace, extend, extinguishってやつですかね。
Swift言語を使うのが目的であって、アプリはその結果に過ぎないのかもしれない
家のパソコンがWindowsで、いずれiOSのアプリを作りたいと思っている学生が、SwiftのTutorialを動かすために使う
それだったらWSL/WSL2のほうがいいような。(試してないが、なんとか動くでしょ)
とりあえず、「Swift言語を使うのが目的」なので、ダウンロードしてみた。
＞ >swift --version＞ compnerd.org Swift version 5.3 (swift-5.3-RELEASE)＞ Target: x86_64-unknown-windows-msvc
VS2019 IDE から。Swift Project を作る方法は、わからなかった。コマンドラインからは、インストールできたことを確認した。
それを言うなら「あらゆる目的達成にSwift言語を手段として用いるユーザ様に」でしょうか。まあ、Excelと変わりませんよ。言語開発者はユーザの便益が増加するならなんだってします。あるいは、仕事をするために仕事を創作します。
Visual Studio入れるんなら、そのままC#でやればいいわな
既にiOSアプリは堪能だがWindowsやLinux向けアプリで別言語を使うのがやだだいたいElectronとかパフォーマンス低いしアプリサイズはデカイし
.NETはJava並みに遅いからね。Javaが.NET並みに早いとも言えるが。
AndroidをJavaから.NET(C#)で書き直したら爆速になったという話が昔あったが
こちらの話かな。 [linux.srad.jp]
JavaとC#の比較ではなくて、DalvikとMonoの比較だね。
息をするように嘘をつくな。一時期Javaの復権のために悪意のある計測記事が出てたから、おそらくはそれらを鵜呑みにしたのだろうけど。
機械語にちょくコンパイルする言語と比べれば.NetとJavaはどんぐりの背比べですよ。
そうでもないからこんなに普及しているわけで
あんな関数名もクソ長いJavaが早いとは到底思えないんだわ
実際問題関数の長さと実行速度の速さって相関あるのかな。ないように見せかけてありそう。.Netも割と長いよ。IntelliSense環境なら長い方が良いけど。
ダイナミックリンクにかかる時間とサイズ増加分キャッシュのヒット率が下がるぐらいは影響するだろうけどJITやらGCやらBoxingやら他に重い原因がいくらでもありそうなJavaでそんなもん気にしてもなあ
大した影響ないでしょC#がJavaより速いのは構造体と配列の扱いが違うところだと思う。
過度の期待をするからだ。プログラミングパラダイムによっては、C++ですら遅い。
ベンチマークを見るとJavaの方が若干遅い
C#から距離を置きたい人もそれなりに居るのかと。
Windows版Safariを思い出そう！（そして結末も）
Chromeが躍進したのでSafariは休止してるが、webkit.dllはiTunesとかで現役なんだろ。最近のは知らん。
IE独占状態でWebKit系を広める為にやってたもうchromeが代わりにやってるから不要になったんだろedgeも陥落してWebKit全盛期アップルが困る事は無くなったし、web主導からapp主導に舵を切ってるしで継続する理由はない
macosで作ったアプリをWindowsに移植したい人。ライブラリが充実すればiOSアプリもWindowsでビルドできるようになっているかも知れないし
swiftでややこしいロジックを書き溜めてしまった。一応で良いから動かしたい。同じ理由でC#を無理にmacOSで(Xamarin.Mac)動かそうという人は割といると思う。
誰が使うかじゃなくて、単に機能は多い方が良いから実装しただけだろうけど。
すでに .NET Coreはプレビューリリースも含めて Win/Linux/Macが同時リリースするようになって久しいので、C#のコードは無理に動かすもんではなく、Macでも動いて当然な時代ですよ。
.NET CoreにWPFは入ってないので、GUIは駄目ですけど。
WinUI・WPF・WinFormsがマルチプラットフォーム対応してくれれば完璧なんだけどね。
WinFormsは捨てていいよ
じゃあWPFもいらないや
WPFだけあれば十分
GUIいる？
CUIを使い慣れない一般人向けにリリースするので必要
あると嬉しい。.NET Coreを推しやすくなる。
.NET 6をお待ちくださいhttps://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/ [microsoft.com]// まだ.NET 5.0もRC段階だけど
これはどちらかというとモバイル向けで、WindowsデスクトップはWPFでいくのが無難だと思う
javaも失敗した道ですからなぁ…痒いところに手が届くuiはプラットフォーム固有になるから捨てる→使い辛いわ→使われない…う〜ん…う〜んwこのもどかしさw
JavaのGUIライブラリの糞さはプラットフォーム固有だからではないような気がする。
これは百理ある。世の中のライブラリって、好みとか考え方の違いはあっても嫌いとか駄目だとか言うことあるが、俺が考えるより設計が駄目すぎると言い切れるものはなかなか無い。でも、swingに関しては俺が考えたものよりクソだと言い切れる。
随分な自信だなw
一度でも、JavaのGUIライブラリ触れば、「糞」とまでは言わないけれどヒドイってことは直感的に思う。
機能性は問題ないけどデザイン性が破滅的と言える。デザインの自己主張が強くて「調和」が皆無なので、ゲームとか、エンベデッドならまだ構わないけれど、ＰＣで一般ユーザに使わせたくない。一般ユーザが潜在的に求める心地よさを実現できない。それを実現しようとすると、GUIデザイナが必用になるというお手軽さが無い。
obj-c独特のオブジェクトでゴリゴリ仕上げちゃったコード資産とか割とありそうですもんね
Foundation層のことかな？Swiftからももちろん利用可能だから、言いたいことは分かる。
CocoaやCocoa Touch層は移植されないと思うけど、SwiftUIは動いているようだから、まあ同じようなことはできるようになるかな。Core DataとかCore Imageとかは移植されないかもしれないので、そのあたりが使いたければiOSやmacOSを使えという戦略かも。ただ、現状でもSwiftUIにはUIDocumentPickerとか必須のコンポーネントがまだない状態なので、役に立つアプリを書こうと思うとまだまだ足りないものが多いけど…
一番最初のリンク先くらい読もうね。実例が掲載されているから。iOSでアプリを開発、さらにWindowsに移植したい。UIとロジックはちゃんと分離してるが、ロジックがSwiftで記述されているのでWindowsでSwiftを動かしたい。(WindowsのUIはElectronを使う予定）というケース。
よっぽどロジック部が複雑怪奇で無い限り、C#で書き直したほうが早そう
ふたつを並行してメンテするのは面倒というか悪夢かも
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
どういうユーザが使うの？ (スコア:0)
Windowsアプリが作りたい：C#でいいじゃん
マルチプラットフォームでGUIアプリが作りたい：Electronでいいじゃん or Webアプリでいいじゃん
Re:どういうユーザが使うの？ (スコア:2)
Embrace, extend, extinguishってやつですかね。
Re: (スコア:0)
Swift言語を使うのが目的であって、アプリはその結果に過ぎないのかもしれない
Re: (スコア:0)
家のパソコンがWindowsで、いずれiOSのアプリを作りたいと思っている学生が、SwiftのTutorialを動かすために使う
Re: (スコア:0)
それだったらWSL/WSL2のほうがいいような。(試してないが、なんとか動くでしょ)
Re: (スコア:0)
とりあえず、「Swift言語を使うのが目的」なので、ダウンロードしてみた。
＞ >swift --version
＞ compnerd.org Swift version 5.3 (swift-5.3-RELEASE)
＞ Target: x86_64-unknown-windows-msvc
VS2019 IDE から。Swift Project を作る方法は、わからなかった。コマンドラインからは、インストールできたことを確認した。
Re: (スコア:0)
それを言うなら「あらゆる目的達成にSwift言語を手段として用いるユーザ様に」でしょうか。
まあ、Excelと変わりませんよ。
言語開発者はユーザの便益が増加するならなんだってします。あるいは、仕事をするために仕事を創作します。
Re: (スコア:0)
Visual Studio入れるんなら、そのままC#でやればいいわな
Re: (スコア:0)
既にiOSアプリは堪能だがWindowsやLinux向けアプリで別言語を使うのがやだ
だいたいElectronとかパフォーマンス低いしアプリサイズはデカイし
Re: (スコア:0)
.NETはJava並みに遅いからね。
Javaが.NET並みに早いとも言えるが。
Re: (スコア:0)
AndroidをJavaから.NET(C#)で書き直したら爆速になったという話が昔あったが
Re: (スコア:0)
こちらの話かな。 [linux.srad.jp]
JavaとC#の比較ではなくて、DalvikとMonoの比較だね。
Re: (スコア:0)
息をするように嘘をつくな。
一時期Javaの復権のために悪意のある計測記事が出てたから、おそらくはそれらを鵜呑みにしたのだろうけど。
Re: (スコア:0)
機械語にちょくコンパイルする言語と比べれば.NetとJavaはどんぐりの背比べですよ。
Re: (スコア:0)
そうでもないからこんなに普及しているわけで
Re: (スコア:0)
あんな関数名もクソ長いJavaが早いとは到底思えないんだわ
Re: (スコア:0)
実際問題関数の長さと実行速度の速さって相関あるのかな。
ないように見せかけてありそう。
.Netも割と長いよ。IntelliSense環境なら長い方が良いけど。
Re: (スコア:0)
ダイナミックリンクにかかる時間とサイズ増加分キャッシュのヒット率が下がるぐらいは影響するだろうけど
JITやらGCやらBoxingやら他に重い原因がいくらでもありそうなJavaでそんなもん気にしてもなあ
Re: (スコア:0)
大した影響ないでしょ
C#がJavaより速いのは構造体と配列の扱いが違うところだと思う。
Re: (スコア:0)
過度の期待をするからだ。プログラミングパラダイムによっては、C++ですら遅い。
Re: (スコア:0)
ベンチマークを見るとJavaの方が若干遅い
Re: (スコア:0)
C#から距離を置きたい人もそれなりに居るのかと。
Re: (スコア:0)
Windows版Safariを思い出そう！（そして結末も）
Re: (スコア:0)
Chromeが躍進したのでSafariは休止してるが、webkit.dllはiTunesとかで現役なんだろ。最近のは知らん。
Re: (スコア:0)
IE独占状態でWebKit系を広める為にやってた
もうchromeが代わりにやってるから不要になったんだろ
edgeも陥落してWebKit全盛期
アップルが困る事は無くなったし、web主導からapp主導に舵を切ってるしで継続する理由はない
Re: (スコア:0)
macosで作ったアプリをWindowsに移植したい人。
ライブラリが充実すればiOSアプリもWindowsでビルドできるようになっているかも知れないし
Re: (スコア:0)
swiftでややこしいロジックを書き溜めてしまった。
一応で良いから動かしたい。
同じ理由でC#を無理にmacOSで(Xamarin.Mac)動かそうという人は割といると思う。
誰が使うかじゃなくて、単に機能は多い方が良いから実装しただけだろうけど。
Re: (スコア:0)
すでに .NET Coreはプレビューリリースも含めて Win/Linux/Macが同時リリースするようになって久しいので、C#のコードは無理に動かすもんではなく、Macでも動いて当然な時代ですよ。
.NET CoreにWPFは入ってないので、GUIは駄目ですけど。
Re: (スコア:0)
WinUI・WPF・WinFormsがマルチプラットフォーム対応してくれれば完璧なんだけどね。
Re: (スコア:0)
WinFormsは捨てていいよ
Re: (スコア:0)
じゃあWPFもいらないや
Re: (スコア:0)
WPFだけあれば十分
Re: (スコア:0)
GUIいる？
Re: (スコア:0)
CUIを使い慣れない一般人向けにリリースするので必要
Re: (スコア:0)
あると嬉しい。.NET Coreを推しやすくなる。
Re: (スコア:0)
.NET 6をお待ちください
https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/ [microsoft.com]
// まだ.NET 5.0もRC段階だけど
Re: (スコア:0)
これはどちらかというとモバイル向けで、WindowsデスクトップはWPFでいくのが無難だと思う
Re: (スコア:0)
javaも失敗した道ですからなぁ…
痒いところに手が届くuiはプラットフォーム固有になるから捨てる→使い辛いわ→使われない…
う〜ん…う〜んwこのもどかしさw
Re: (スコア:0)
JavaのGUIライブラリの糞さはプラットフォーム固有だからではないような気がする。
Re: (スコア:0)
これは百理ある。
世の中のライブラリって、好みとか考え方の違いはあっても嫌いとか駄目だとか言うことあるが、俺が考えるより設計が駄目すぎると言い切れるものはなかなか無い。
でも、swingに関しては俺が考えたものよりクソだと言い切れる。
Re: (スコア:0)
随分な自信だなw
Re: (スコア:0)
一度でも、JavaのGUIライブラリ触れば、「糞」とまでは
言わないけれどヒドイってことは直感的に思う。
機能性は問題ないけどデザイン性が破滅的と言える。
デザインの自己主張が強くて「調和」が皆無なので、
ゲームとか、エンベデッドならまだ構わないけれど、
ＰＣで一般ユーザに使わせたくない。
一般ユーザが潜在的に求める心地よさを実現できない。
それを実現しようとすると、GUIデザイナが必用になる
というお手軽さが無い。
Re: (スコア:0)
obj-c独特のオブジェクトでゴリゴリ仕上げちゃったコード資産とか割とありそうですもんね
Re: (スコア:0)
Foundation層のことかな？Swiftからももちろん利用可能だから、言いたいことは分かる。
CocoaやCocoa Touch層は移植されないと思うけど、SwiftUIは動いているようだから、まあ同じようなことはできるようになるかな。
Core DataとかCore Imageとかは移植されないかもしれないので、そのあたりが使いたければiOSやmacOSを使えという戦略かも。
ただ、現状でもSwiftUIにはUIDocumentPickerとか必須のコンポーネントがまだない状態なので、役に立つアプリを書こうと思うとまだまだ足りないものが多いけど…
Re: (スコア:0)
一番最初のリンク先くらい読もうね。実例が掲載されているから。
iOSでアプリを開発、さらにWindowsに移植したい。UIとロジックはちゃんと分離してるが、ロジックがSwiftで記述されているのでWindowsでSwiftを動かしたい。(WindowsのUIはElectronを使う予定）というケース。
Re:どういうユーザが使うの？ (スコア:1)
よっぽどロジック部が複雑怪奇で無い限り、C#で書き直したほうが早そう
Re: (スコア:0)
ふたつを並行してメンテするのは面倒というか悪夢かも