Swift part11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
スクリプトはPython一強になりつつあるな
コンパイラは何だかんだとJAVA、強者はC/C++で次点にC#が勢いを増しつつある感じ >>92
Python文法を踏襲しつつ、イマドキ？な言語PFになってるnimがあるぞ
Swiftを越えるクソっぷりで海外でも日本でも不興だけども >>102
wikipedia見ただけだと凄そうなんだけど、どんなところがクソなの？ >>103
1. 目標として掲げた言語仕様に対する完成度がswift betaくらいに未完成
2. nimソースを他言語ソースにコンバートして、他言語ソースをネイティブバイナリにコンパイルという微妙なコンパイル手法
3. 1, 2に引きずられているのか書いたコードが仕様通りに動かない(バグったコードがバグるんじゃなく、正しいコードがバグる
Python好きだし期待してた頃もあったけど、一向に完成度が上がらないから諦めた
大企業スポンサーがつかない新興言語はどうしようもないんだなって, Apple/IBMがついてるSwiftはまだマシ 2の手法は良いと思うけどな
まぁ完成しないんじゃどうしようもないけど コンバートって
なんかの言語がPythonっぽい見た目だったらいいなーと思って作ったのだろうか 一応、GCが付いてたりとランタイムに独自機能は乗ってるけどな
SwiftもObjCへのトランスコンパイラとして実装すれば良かったのかもしれないとふと思った
その程度だとApple公式PJになる意義はなかったかもだけど、今のSwiftランタイムの存在意義と比べてトントンじゃね >>109
objcって中身は動的言語みたいなもんだからメッセージ呼び出しのオーバーヘッドがかなりある。 呼び出しのオーバーヘッドもなにもクラス実体があるポインタアドレスに
まるっとデータ送ってるだけだから逆にリンカがコンパイル時に
「ここ」って指定してるのとどこがそんなに違うんですか？的な メッセージ式って、レシーバーが文字列解析してるとか？ SwiftはObjCと違ってメッセージ呼び出しのダイナミックコールしないから早いんだぜって言ってたな
なお体感できるものだとは思えない すまん語弊があるな、ダイナミックコールしないケースがある、が正しかった まあ何と言われようと、OSX、iOSをここまで発展させてきたObjective-Cの実績は事実として存在している apple専用言語だから実績と言われてもピンと来ない iOSが毎年更新してるのにアホみたいに安定してる事実が
もう「あたりまえ」だと思われてるんだなぁ…
C/C++製の自分の足下の更新ペースと安定性を忘れきってるのが笑える。 Cocoa, UIKitで他の言語が使えないからなぁ
ObjCだったから発展したんじゃなく、発展に合わせてObjCが普及したのが事実よな
Swiftでないと使えないという環境がないから普及しねぇ
Carthageも流行らなかったから普及に貢献してないし >>120
Objective-Cだから発展したというよりは、Objective-Cのままでも何ら問題がないということだろう Carbon(C++)からCocoa(ObjC)に切り替えて選択肢を無くした状態でObjCをゴリ押ししたからな
Swiftのゴリ押し、足りてないよー >>122
あの時はそもそもOSが根本的に変わったけどな まあObjective-CはJobsが原点回帰(NeXT系譜)した感じだな >>122
CarbonがいつC++だったのよ。Cだろ
>>123のいう根本から変わる過渡期にどうするかで出てきたCarbonなんて最初からいつか無くなる運命だし、Carbonよりも先にObjective-Cあったので切り替えでもなんでもないだろ
いつまでもOSネイティブなObjective-Cにしなかったアホが悪いでしかないのに、ゴリ押しとか基礎も結論も妄想がひどすぎ Swiftやってる連中はにわかが多いからしゃーない 旧MacOSはそういやPascal推しだったの思い出した Pascal, C/C++を拒否してObjCに強制誘導してるじゃないか、、、
同じようにSwiftも頼むよー C/C++が拒否されてるなんて全く感じたこと無いけど
C/C++でバリバリ書かれてるコードにちょっとCocoa APIをObj-Cで呼び出せばプログラムが完成するって感じだと思うけど
ObjCに強制誘導って思うのは、単にMac OS XのAPIを学びたくないからじゃないの？ 強制誘導ってアホか？
Objective-CのベースだってMac OS X/OS X/macOSのバージョンアップによってC++に書き換えられてるし、CoreはCのままだし、OS X/CocoaはほぼNEXT STEPのまんまと言っていいくらい元々Objective-Cだし、IO KitはC++で書けだし >>128
推しというか、Macの開発(ほんとの生み出す開発)はPascal/Assembleで作っていたんだなあというのは、どこぞの博物館で公開されたQuickDraw/MacPaintのソースでわかる
推すも何もそうだったらそうなるだろ、ドキュメントとか。だが、サード開発ではCが大多数(＆CでPascal形式API呼ぶのにほぼツーカーで何も問題ない)で、Appleもそれにならうでしかないな Google Search
Google Trends
Twitter
GitHub
Reddit
などなどを"X programming"っていうテンプレートで検索し、hits countsをrankingしたって事らしい。 >>130
ObjCをちょっと書かないとmacOS, iOSアプリが作れないように
Swiftをちょっと書かないとモノが作れないくらいのゴリ押しして欲しいなぁと
Appleは作りっぱなしで押さないし、信者はジョブズの聖遺物(ObjC)を崇めるし
Appleがゴリ押しした製品に寄生して銭稼ぎしようとbetaの頃に始めたのに悲しいよ 世界初のWebブラウザはObjective-Cによって産み出された
まあどーでもいいけど、いまやWeb全盛の時代にそういう言語で最新のアプリが作れる環境が与えられてんだから少しくらい感慨というものを感じてもいいんじゃないの 元々アホかなとは思ったが, >>135ぶりからアホってもんじゃねええ。Swift好きにも迷惑だと思うぞ >>130
C++を拒否というならSwiftによって／Swiftがだろうな、現在はw
macOS上のSwiftでは、まあ、Objevtive-C++でラッパー書いてそれをSwiftでだが、Linuxでぼちぼちっとじわっと使われているので、はよSwiftでC++のブリッジを(まあ、Cのインターフェースでラッパー作ればいいんだろうけど)
C++ブリッジの予定ないのかなあ Uiview.アニメーション関数を使いたいのですが、uiviewanimationoptionsの選択肢が
でてきれくれません。Youtubeを参考にしながら、optionsの部分をcurveLiniearに
したいのですが・・・cを入力しても候補が一切表示されず途方に暮れています。
どういった原因が考えられますか？助けてください。ゲーム作りたいです。 >>139
macOS/Objevtive-C++ありきのじゃね？ rustのメモリ管理の仕組みが採用されたらどんだけ幸せになれんのかな。
そもそもrustごと採用してくれれば良いのに いやそうでもないか…
言語仕様に振り回されてはいるが大概自分に原因を帰着してる
まだ信仰心旺盛なようだ でも静的にメモリ管理を解決するって
どんだけ良いものか気になるんだよね。
どうせswift5辺りで採用されんだから、先にrustに触って先行学習してても良いかもね。
多分swiftに採用されたら下位互換性また壊れるぜ Rustの元になってるC++ std::unique_ptrをどうぞ
ObjC++でも使えるゾ
>>141
下手な風評はSwift好きに迷惑だからやめろやｗ >>139
時々見る、この「つ」ってどういう意味？ >>148
c++にはなんでもあるんだね。
でも言語仕様で縛らなくても静的にメモリ管理って可能なの？c++のプリプロセッサがすごいってこと？ >>151
俺には「つ」が手に見えない。手のひら？手の甲？ >>152
オブジェクトへの参照が１個、複数の別で、
unique_ptr, shared_ptrを使い分ける。
参照するだけで、所有しないweak_ptrってのもある。
要するにリファレンス・カウント式のメモリ管理なのだ。
Objective-Cの設計をC++が取り入れたのかな？ ちなみに、俺はC++を最近全然使ってない。C++詳しい人、
unique_ptr, shared_ptr, weak_ptr
の解説、よろしこ！ >>154
ただのリファレンスカウント方式ならrustとは違うで。 逆だよ、C++のshared_ptrをObjCのARCに文法糖衣で取り込んだんだよ
>>152
unique_ptrは元々C++ boostのライブラリとして提供してたから出来るでしょ
ObjCもSwiftもそういう機能はライブラリじゃなく文法で取り込みたがるから言語更新待ちになるだけで リファレンスカウントは全然静的に解決しているメモリ管理機構じゃない。
rustのやり方はコンパイル時に指摘してくれるけど、リファレンスカウントはけっきょく動的に解決するわけだし。
それならとっくにswiftで実現してるし。ARCだろ。 >>157
Boost Software License - Version 1.0 - August 17th, 2003
って事は、Boostの方が歴史が古そうですなぁ。ObjCよりも。
俺、誤解してたわぁ。 Apple Inc. deploys ARC in their operating systems, such as macOS (OS X) and iOS.
Limited support (ARCLite)[5] has been available since Mac OS X Snow Leopard and iOS 4,
with complete support following in Mac OS X Lion and iOS 5.[6] Garbage collection was declared deprecated in OS X Mountain Lion,
in favor of ARC, and removed from the Objective-C runtime library in macOS Sierra.[7][8]
ref. en.Wikipedia://ARC
ARC Liteの出現は、2009, Snow Leopardからみたい。 rustのメモリ管理の仕組みを見てきたけどプリプロセッサで何とかなるというものじゃなかったから、
c++ならあると言うものじゃなかった。
言語仕様から改変か必要なものだったよ。
簡単に言えば、メモリの参照は一箇所に制限されて、そこからしかアクセスできないようにする。
たから、もしswiftでrustのメモリ管理機構が導入されたら、
100%既存のコードでは動かないし単純に変換もできない。
ロジックの見直しが必要だからね。
例えば配列にループアクセス中は
配列に対する変更操作はすべてコンパイルエラーになる。とか。 いやownership manifesto読めよお前ら
全部書いてあんのに >>148
https://github.com/sandym/swiftpp
これじゃねえの？XcodeありきObjective-Cありきだろ？
これじゃねえ、どれやねん？ >>161
「メモリの参照は一箇所」
まあ、そうかもしれんけど、俺の理解では参照カウントを１以上に上げない
様なメモリ管理ポリシーを実践する事で、メモリリークは防げると思う。
それから、Instrumentsとdebuggerを活用するのが吉。
最近気がついたのが、command+IでInstruments leaksを起動して捕捉出来なかったメモリリークが、不思議な事に、break pointで一旦止めてdebuggerからInstruments leaksを起動すると捕捉できるんだよねぇ。 =ア 【はい】
こういうのも👉に見えてなかったとか… >>153
手の平。
https://nanapi.com/ja/25657
https://m.chiebukuro.yahoo.co.jp/detail/q1410591729?__ysp=MmNoIOOBpA%3D%3D
[つ]は手を表現しています。
例えば、[（ ・∀・）つ旦]というAAでしたら
旦はお茶のAAですので、
お茶をハイ、と差し出している様子を表しています。
２ちゃんねるでは省略形をよく用いますので
顔文字が省略されて[つ]のみで使用されます。
>>165
まじっす！ >>170
そんな、補足説明が必要なAAなんて、不要だわぁ。 >>135
つまりは皆が出来ないうちに自分だけはSwiftを沢山書けるようになっておけば、Swiftがゴリ押しされたときに先行者利益を得られると思ったけどそうはならなかったから悲しいってことだろ？
別にAppleが推してないなんてことないと思うし、Obj-Cを崇めてる奴なんていないと思うし、Swiftはまだまだバージョンごとに変更がある割には十分普及してると思うけどな
大体Swiftをちょっと書かないと作れないぐらいのレベルだったら大してSwiftの知識もいらないと思うし銭稼ぎできるようなもんでもないと思うんだけどな
はじめにObj-C使わなきゃいけなくなったときに本1,2冊ぐらいしか買ってないし、Swiftに関してはお金まったく書けてないし、金稼ぎできる要素がある気がしない
>>138
C++をブリッジするとなるとC++の複雑な機能全てをブリッジ出来なきゃ有用性が落ちそう
限定された機能で書かれたC++コードだけブリッジしてくれるとかだと結局C++側がそれ以外の機能使ってたらラッパー書かなきゃいけなくなるし、落とし所が難しそう Swiftの完成度が最初から高ければ状況は違ったかもな
あとむだにWithout Cに走ったのは筋が悪かったと思うわ C++ブリッジってそれもうwith C++だからな
テンプレート除けばそれなりに出来るだろうけど
テンプレート除いたC++に対応したところでだから何なのって話になるし Without Cをぶち上げたんだからもうCに関わるなよ
韓国人かよ... Cライクforもインクリメント、デクリメントもなくす無駄な徹底ぶりだからな なんかswiftどんどん構文追加して複雑になってないか？
phpみたい >>176
マルチプラットフォーム化に加えて
膨大なossがcやc++で書かれてるんだから無視は不可能だ。 むしろ、Objective-Cの「インスタンスは母体クラスに［おまえのインスタンスを作れ］命令で作成します」とか
「クラス間の通信はクラス［命令:引数］で明示的に他のクラスに実行させてるとわかります」が好きだったので
そのあたりswiftが「退化」しちゃったのが嫌。
言語仕様とクラス仕様が分離しててクラスライブラリだけ進歩してくとか
ソース内で自他の表記がしっかり別れてて「ここであいつがこれやって次…」
と読めるのが気に入ってたのに
他のグチャグチャモダン言語と同じ言語仕様変更地獄と
ソースになんだかわからない誰かが作った記号が普通に混じりますって
これ、ずっとプログラミング文化の発展阻害してた奴だ…と >>183
>明示的に他のクラスに実行させてるとわかります
Swiftでは分からんの？ >>183
>ソース内で自他の表記がしっかり別れてて
これ何のことを言ってんの？
自他の区別がつかない言語なんてあんの？
そんな精神病みたいなプログラムあっても実行できなくね 多分全部staticで書いてんだろ
おそらくインスタンスとクラス、動的メッセージと静的メソッドの違いがわかってない $
↑こいつ
今までの理念をぶちこわすような暴挙
itでもなんでもよかったのになんでこれにした 一方俺は、ObjCの言語仕様にクラス変数が追加されて、既存フレームワークのクラスメソッドがクラス変数に変わって発狂していた
>>188
$0, $1, etc.として複数引数の場合でも引数記述を省略させるためでしょ
シェルスクリプトを書いたことないとなんぞこれってなるが、it0, it1よりはスマートだと思うが >>181
なので普通に考えるとObjective-C 3.0として改良発展させるのがよかったと思うんだよね... >>189
いちいち引数に名前つけさせて、
省略できるのはひとつまでって感じで今まできてたじゃん！
ここにきてこれ
itですら多少は意味があるが、$ってなに？
なんで急にドル記号が出てくんの itの方がマシというのは別に否定しないけど
「今までの理念」というのはSwiftには無くね 俺はitより$nの方がマシだと思うけどね
「名前を省略する」ためのものに「名前をつけた気になる」ために$nをやめてitにするってかなり本末転倒じゃない
どうせ具体的な名前が無いなら、極めて曖昧なitなんて単語じゃなく、どこまでも記号的な$nでいい
敢えて単語にするならanonymousArgumentとかclosureArgumentとかにして、クロージャの名前がない引数であるという意味を表さないと
itなんて、$nと同じぐらい何も意味を表さないのに、無駄に単語の体をしてるだけタチ悪いと思うわ
逆にwillSetの引数名省略時のnewValueみたいに、最低限あらかじめ意味が限定されてるところでは、$nでもitでもなくちゃんと最低限の意味を表す省略形になってる どーでもいいけどいい加減syntaxのセンスがクソ過ぎやしないか？ 本音をいうと省略させたくない
書き方増やしてどうする 俺も書き方のバリエーションが増えるのは反対だな。誰が書いても同じ文法で、誰が書いたコードでも誰でもさっと読めるのが理想だったな。 swiftでrxSwiftさわったらすごくRxがわかりやすくなったのは良い思い出。
objcだとわけわかめだった。
構文って結構学習コストに関わるんだなって理解した瞬間でした。 >>198
Haskellが普及しないのは、その理想を追い求めすぎてるからだけどね ■ このスレッドは過去ログ倉庫に格納されています
