新しいものを表示

これが出来るようになったら、自分で好きな型で、好きなリテラル形式で(互換性の為に " で囲ってC# 的には文字列として)記述しても、IDEで静的に検査できるじゃん?>< 超便利じゃん?><(既にそういうアドオンあったりしないのかな?><)

スレッドを表示

長い>< 

さらに暗黙の型変換と組み合わせて、
BigNantokaInt hoge = "123";//(実際は123じゃんなすごく巨大な数値だとする)
って書くと、BigNantokaInt のstringからの暗黙の型変換の宣言にその属性がついていたら、BigNantokaIntに実際にキャストできるか検査させて、「無理!」って例外が出たらIDEで警告出すみたいなの><
さらに、暗黙の型変換はリテラルからのみ受け入れたいって追加属性もつけると、
void Hoge(string fuga)
{
BigNantokaInt hoge = fuga;
}
みたいに書くと、同様にチェックする時に「いや、暗黙の型変換はは組み込み型みたいに使うためにつけただけなので、それだと実行時まで検査できなくてどうなるかわかんないじゃん・・・」って警告が出るようにするとか><(でもビルドは通すみたいな)

スレッドを表示

これ、公式の機能じゃなくてもVSのアドオンとして作れないのかな?><

スレッドを表示

C# + VS IDEで、例えばBigIntegerを使う時に、
System.Numerics.BigInteger hoge = System.Numerics.BigInteger.Parse(@"42");
とか書くじゃん?>< 整数リテラルだとInt32だと思っちゃうから><
そのせいで例えば
BigInteger.Parse(@"><");
とか書いても静的検査されないじゃん?><
で、思ったんだけど、VS IDE用に「引数がリテラルである場合のみ静的検査する属性」ってあったらおもしろいと思うんだけど無理なのかな?><(つまりこの例だとParse(にその属性がついているとして)を実際に実行してみて例外が出るのかIDEが書いてるそばから試してくれるみたいなの><)

お仕事だと、タイムリミットもあるであろう事も大変そう><
オレンジが今作ってるソフトウェア、20年以上前に作りたかったものだったりする><

orange さんがブースト

プログラミングの仕事は頼まれたことが実現可能かどうかや実現方法を時間をかけて調べないといけなくてつらい、という話を聞いて、私はむしろそういうの好きだなと思いかけたけど、ある程度の速さで探せたり、なんなら周りに相談することもできたりするからそう言えるのかも、とか。条件によって大きく変わりそう。

そういえば、猫も杓子もAI()な世の中で、「ディープラーニングをやるならPythonだよね!」って風潮はまあそこまではいい(よくわかんないけど相性いいのかも?><)として、そのAI()を「失敗すると人が死ぬ分野」で使おうって話で、失敗すると人が死ぬ分野って型がガチがちだったり仕様が厳格だったりする言語や規約が使われることが多いと思うんだけど、そういう分野でAI()って、そのぶつかり合い(?)みたいなのどうするんだろ?><
下の方はガチガチにMISRA CとかAdaとかで、上はPython?>< 境目が地獄?><;

ビルドするときにはじいてくれて、コンパイラのエラーメッセージが的確でわかりやすければ、コンパイラが具体的に「こうすればバグがとれるよ!」って教えてくれてるって事なんだからこれほど楽な事は無いじゃん?><
賢いIDEなら書いてるそばからそれをしてくれるし「こうするつもりだったのかも?」って修正案まで提示してくれるし「それだ!><;」って思ったらキーひとつ押せばそれに置き換えてくれるからさらに楽だよ><
実行してみないとわかんないとかめんどくさいじゃん?><

頭固いPascal &(頭固くは無いけどPascalからDelphiを通じて大きく影響を受けてる) C# にどっぷりなオレンジ的には、ビルドが通る=だいたい正しい>< 通らない=正しくない の方が楽ちんすぎて、ビルドと折らないけど動いて欲しいって感覚さっぱりわからない><
「ビルド通ればだいたい正しい」のおかげで、どう使うんだかさっぱりわからないままでもゲームMODを最新のバージョンのゲームに対応させるとか出来ちゃう><(なお、年末に頼まれてそれを行った所、ボスが死んでもボスが弾を撃ち続けるという愉快なバグが発生しました><;)

orange さんがブースト

とはいえ複雑な依存関係でビルド成功させるのが困難なhaskellとか見てるととりあえず実行させてくれ!という気持ちもわからんでもない(でもビルド通らんようなもの実行させたくない…)

orange さんがブースト

だからこそ制約をできるだけ正確に表現できる、型付けや制約の強い言語が一部の人に好まれているわけで

orange さんがブースト

雑に書いて後から苦労するんじゃ世話ないよ……

orange さんがブースト

Ruby だと更にリフレクション的サムシングみたいな都合が入ってきたりもするんだろうけど、 Python のその辺りの事情は知らないのでここでは考えない

スレッドを表示
orange さんがブースト

まあ原則として「制約や意味付けの弱いものから強いものへの自動変換は極めて困難」なので、ガバガバをよしとするタイプの LL で自動変換と相性が悪いのも自明な話ではあるというか

スレッドを表示
orange さんがブースト

2から3への変換みたいなスクリプヨも存在してたはずだし、それで無理となるとなんなんだろう (ヘビーユーザでないのでわからん)

文字列型が無くなったから3への対応無理になったってことなのかな?><
なんで3用の2の文字列型互換ライブラリを公式で作らなかったんだろう?><(正しくない仕様を作ってしまったらそういうめんどくさい事までする覚悟を持っていなかったら、また気軽に正しくない仕様を作っちゃうよ><)

よりPythonicなPythonを目指して(前編):Python 3が後方互換性を捨ててでも求めたもの (2/2) - @ IT atmarkit.co.jp/ait/spv/0901/31

Pythonよくわかんない(ちょっとしか弄ったこと無い)けど、Python2からPython3に機械的に完全にソースコードを変換出来ないっぽい(出来るんだったらそういう問題起きてないんだろうし)のすごく謎><
(オレンジの発想では、仕様が正しいのなら変換できるはずだし出来ないのなら正しくないと考えるかも><(仕様決めた人的には、「2は正しくなかった」って言いたいんだろうけど><))

orange さんがブースト

github.com/asciidoc/asciidoc

ちょっとまって、公式の asciidoc プロセッサ (Python 2 製) の 3 への移行って諦められたのwww (Ruby 製の asciidoctor で開発を継続すると書いてある)

NSFW?><; 

naturalwater. ccってまだとられてないっぽいし、sommelier @ youjo. naturalwater. ccとかインパクトありすぎて一回で覚えられそうなのも出来そう><;

なんでccドメインじゃないんだろう?><って思ってた><(下品)

古いものを表示
:realtek:

思考の /dev/null