IDEでタイピング中からエラーわかる（すばらしい！＞＜）→ビルドするとエラーわかる（まあしょうがない＞＜；）→実行時にエラーがわかる（は？＞＜）
IDEでタイピング中からエラーわかる（すばらしい！＞＜）→ビルドするとエラーわかる（まあしょうがない＞＜；）→実行時にエラーがわかる（は？＞＜）
遅い上にビルドしなきゃわかんないって、IDEで甘やかされた身からすると「そんなの書いてる途中からチェックしてよ！＞＜；」ってなるしやっぱ部分範囲型欲しい・・・＞＜
public static explicit operator BubunHanniGataModoki(int v)
{
Contract.Requires(v > 2 && v < 5);
return new BubunHanniGataModoki(v);
}
//明示的な型変換の時に範囲チェックするという方式＞＜；
class BubunHanniGataModoki
{
//大きく略
//intからの明示的な型変換の宣言
public static explicit operator BubunHanniGataModoki(int v)
{
if (v > 2 && v < 5)
{
return new BubunHanniGataModoki(v);
}
else
{
throw new ArgumentOutOfRangeException("3 か 4 専用でした！＞＜；");
}
}
}
varの所でクイックアクションとリファクタリング選んでもやっぱなにも出ないけど＞＜；
そんなのあったっけ・・・？＞＜ "「var」を右クリックして表示されるコンテキスト・メニューから［リファクタ］－［実際の型の挿入］を選択することで、varを実際の型に置き換える機能" C#への期待。アンダースからの返答（3/3） - ＠ IT http://www.atmarkit.co.jp/fdotnet/insiderseye/20060215cscommunity/cscommunity_03.html
Delphiの事実上の後継であるC# が、PascalとかAdaの部分範囲型を採用しないの、今でも謎・・・＞＜（typedef嫌ってるのと似たような理由？＞＜）
実用的なコードを眺めると、やっぱAdaって訛ったPascalだ・・・・＞＜
いきなり型の宣言と演算子のオーバーロードから始まってるの、なんと言うか伝説は本当だったのか的な・・・＞＜；（Adaの実用的なコードほとんど読んだ事無い＞＜；）
Adaだ・・・＞＜
TeXCAD / Code / [r65] /tc.ads https://sourceforge.net/p/texcad/code/HEAD/tree/tc.ads
人が死なない分野ではこれとかがAdaで書かれてるらしい・・・＞＜（今知った＞＜；）-- TeXCAD 日本語情報トップページ - OSDN https://ja.osdn.net/projects/sfnet_texcad/
Adaは今でも、失敗したら人が死ぬ分野では現役の言語だよリスト＞＜ --
Who's Using Ada? Real-World Projects Powered by the Ada Programming Language November 2014 - Michael B. Feldman http://www2.seas.gwu.edu/~mfeldman/ada-project-summary.html
石油でどうにかは色々無理だけど、せめてカルシウムカーバイドからどうにかしてポリエチレンとか作ってみたい・・・＞＜(作り方わかんないし作れない＞＜；)
オレンジは、石油化学工業まるごと自作してみたいという意味で自分用の油田ほしい・・・＞＜；
油田持ってりゃあなぁ私もな〜って思ってた時期もあるけど油田持ってたところで正しい活用ができなさそうだから使える人が使うのが一番いいですね
Adaが言う正しいって、だいたいどの段階でもヒューマンエラーを起こさないという基準での正しさかも？＞＜ 型ありきどころか型チェックありきでとにかく型を作れってなってたり、haskellerが言う「型ありき」が裸足で逃げ出すレベルの頑固な仕様かも？＞＜(使ったこと無いけど＞＜；)
移植性の良さは、実際に使用するユーザー(Cで言うならCでプログラミングする人)からみたデザインの正しさとは別だし、
https://mastodon.cardina1.red/@lo48576/99697943444572728
にも反するかも＞＜
頑固に「正しいこそ正しい」って発想の言語、良し悪し抜きで言うとAdaかも？＞＜
かつて無数にあった「正解」だと思われていたであろう言語のうち、今ひろく正解だと思われているものに心当たりがないし、単一の正解も見付けられないのに正しさのエッセンスの約束をどう定められるのか(いや今の人類には不可能だ)という気持ちです
ていうかCこそ「デザインなんて正しくなくてもいい！ それよりも移植性を」って言語の代表なんだから、将来まで見据えたデザインのただしさと言う文脈で出すとあれかも＞＜(デザインが正しくなくても普及する方が正しいって戦略でその通り勝利したという意味では正しい＞＜)
Cって単にUNIXの移植性の意味での将来性を重視してた、それこそworse is betterなUNIX的発想の言語なんだからそりゃそうでしょ・・・・＞＜
たとえば将来(に現れるであろう多様なプラットフォーム)を見据えて設計された C 言語という言語があるんですが、現代においては策定者側に「人間はそんなに賢くなかった」的なことを言わしめるほどには駄目とされているし、正しい「約束」は人間には無理です
新しいものをホイホイ作らないで将来を見据えてデザインされたソフトウェア、例えばNTがある＞＜(ユーザーに届く形でUXではホイホイ変えまくりの部分もあるけど、少なくとも基礎の部分はUNIXを強く嫌って「最初から正しく書け」って発想のカトラーらしいOSかも＞＜)
このアカウントは、notestockで公開設定になっていません。
うん＞＜； だからworse is betterは正しくないし、正しいか正しくないかの基準をどこに作るか？って事になるし、現在の現実のソフトウェアのUXデザインはユーザーが悪いと言えるレベルに全く達していない(製品の良し悪しではなく、例えば約束という発想が不十分とかそういう面)なのでユーザーのせいにしてはいけないと言いたい＞＜；
https://mstdn.nere9.help/@orange_in_space/99698251682940548
この意見を進めると「正しくないものをリリースするな」になるんだけど、私が似たような「たとえ使えようが間違ったものは存在しない方がマシ」という意見はあまり賛同してもらえた記憶がない……
ちなみに1987年と今だと旅客機の操縦環境ある意味全く違う＞＜ 航法や管制が全く違うと言っていい状況＞＜ A320はその変化後を想定してデザインされてる＞＜(ので、ハイテク嫌いの古いパイロット(もうだいたい引退してる年代)には嫌われやすい＞＜；)
旅客機の例えばエアバスの過去を捨てたサイドスティック式のコクピットデザイン、強い乗員互換性がある最古のA320の初フライト1987年だよ？＞＜
1987年にした約束を2018年現在最新の機種でも果たし続けてるんだよ？＞＜ A320を作った時に将来まで約束し続けられるか考えてデザインしたから＞＜ 今でもA320ファミリの基本的なデザイン全然古くないよ＞＜ ボーイングの行き当たりばったりのコクピットデザインと比べると＞＜
だからこそ思い付きで将来古くなるような新しいものをホイホイ作ってユーザーに提供するなと言ってる＞＜ そのデザインは何十年約束できるのか？＞＜ってひとつひとつ考えてから出せと言ってる＞＜ Facebookのお兄さんみたいな発想は正しいデザインの敵＞＜
ユーザに約束した結果が、いわゆる「互換性の闇」などと呼ばれるものであり、メンテナのいないレガシーコードの塊であり、単調増加する類似 API であり、尽きることのない脆弱性であり、その辺りの苦悩はソフトウェア界隈は既に痛い目見てるので……
それはworse is better的発想に片足突っ込んでるんだから「正しいデザインのものを」なんて言ってはいけない＞＜ UNIXの哲学はUXデザインから見てどうしようもないゴミと言っているのなら別だけど、その上でもUNIXを捨てた所でユーザーに自由な選択肢なんて事実上存在しない＞＜
様々なものを切り捨てて目標と過程を単純化することはできても、あらゆる複雑なことを単純にやるようなことはできないので、製品に文句を言う前に理解度を深めろという気持ち
(まあプロからしてもクソな UI とかはあるんだろうけど、それはそういう人々が批難して初めて説得力を持つので)
このアカウントは、notestockで公開設定になっていません。
シンプルなデザインであるべきとは言ってないんじゃない？ってさっき書こうとしたけどやっぱり本人が言った(?)
航空機(特にエアライナー)のコクピットデザインの、同一の資格で操縦できるものの範囲での変更は、慎重に慎重を重ねて全く違うものには絶対にしない(違うものにする場合資格も違うものになり再訓練が必要)って発想からみると、IT界隈のマンマシンインタフェースデザインは、開発者側に甘すぎる＞＜ ユーザーに何の約束もしていない＞＜
オレンジは操作をシンプルにしろとは全く言ってない＞＜ むしろ自称シンプルなAppleのようなデザインをとても嫌ってるし、正しくないデザインの例としてApple製品を出して説明すること多い＞＜
このアカウントは、notestockで公開設定になっていません。
そもそもIT界隈で、そういう操作手順等に関してユーザーに約束する発想のデザインってなされてる？＞＜ 特にOSS界隈なんて開発者寄り(作りやすさのみ追究)するworse is betterの発想でしょ？＞＜
UXの変化を嫌ってセキュリティ上問題がある古いソフトウェアを使用し続けるユーザーを擁護したことある？＞＜ 作るのがめんどいからUXとセキュリティ対策が分離できない手抜き構造なデザインでソフトウェアを作ることを許容し続けてるでしょ？＞＜ IT業界のほぼ全体で＞＜
逆向きも、「懇切丁寧な手順書が付いてない製品はクソーーー！！！！」と思っているユーザは、さっさと別の製品に逃げればいいし、そうできる自由があるべき
べつに説明書が不要とか説明書が間違っているという意見ではなく、開発が「これだけ説明すれば十分わかるやろ」というラインを下回るユーザに付き合う必要はないという、基準を自由に定める権利の話なので、開発者が「猿にも使ってほしい！」と思うなら猿でもわかる説明書を用意すればいいし、それで沢山のユーザがつくこともあろうと思います
手順書その物のデザインの問題もある＞＜ 手順書は想定される「正常な動作」だけではなく、想定される範囲の全ての異常をカバーし、かつ、異常とユーザーが認識した時に適切にそれに対応するページに適切に移動できるようになっていなければならない＞＜ しかも、異常により不信やパニックに陥っているユーザーを想定した上で＞＜
ステップバイステップな解説書が強く必要な場面はもちろんある＞＜ 航空やその他間違えると人が死ぬ場面で使われるチェックリストはその代表かも＞＜ 一方で、チェックリストが使用されるような環境はチェックリストでカバーできないような手順の変更はしない＞＜ 必ずチェックリストも更新される＞＜
オレンジには矛盾した意見に見える＞＜ なぜならば、そもそも説明書が必要になるようなデザインは全く正しくないデザインであると考えるから＞＜
人間が尊いというのは人権が守られるべきという話であって、馬鹿に懇切丁寧につきあって足を引っ張られてやれという意味ではないので、社会の大多数だろうが自分がそこに含まれていようが、間違ったものしか受け入れられないなら滅んでしまえというお気持ちがある
そもそも間違った設計のものが世の中に広まって親しまれるの、総合的に評価してマイナスでは
プロプライエタリだとユーザたち自身での問題解決も難しいし、そのくせすぐにベンダーロックインはかかるし
説明を読んでわからないユーザを容赦なく切り捨てる(あるいは開発側がサポートの義務を持たない)スタイルが絶対に必要だし、そのためには開発者がユーザを見捨てられるだけでなくユーザがアプリケーションを乗り替える自由も必要なので、オープンソースでやっていこうねという気持ち