新しいものを表示
orange さんがブースト

こういうやつ

pafuイーランスクール 学んでできる pafu Web学習室 基本情報技術者試験 アルゴリズム 疑似言語 mij-s.com/pafu/web_fe/al/giji/

普通に考えたら「アメリカ行きたいの! いいところなの!」っていってる人に対して、そう思ってない人や悪く思ってる人の方が「そんな事無いぞ! こんな酷い所もあるんだぞ!」ってなりそうじゃん?><;
なんで逆に「アメリカ行きたい><;」って人の方が「なんでショック受けてんの?><; そういう場所じゃん?><;」ってなったのか?><;

微妙にそれと関連して、このアメリカ生まれの人も含むyoutuberの3人がL.A.のリトル東京でショック受ける動画、興味深かった><;

"アメリカにある日本人街『リトルトーキョー』に行ってみた!" を YouTube で見る youtu.be/MjXU6Bp3C8c?si=VXZwha

アメリカの情報をメインとするyoutuberの方々だから、どんな場所でどんな感じの雰囲気なのかわかってるかと思いきや、アメリカに行った事無いアメリカかぶれのオレンジよりもわかってなかった><;
隣がスキッド・ロウなんだから落書きが多いのは当たり前だし、周囲の風景の荒廃具合も別にアメリカの大都市としては驚くほどじゃないじゃん?><;
こういう状況やある程度治安が最悪な地域もも含めて「アメリカいいな行きたいな><」って思ってる方から見ると「そこ驚く!?><;」ってなる><;

[B! 日本すごい] 「日本はすごい国」昭和人間が過去の栄光を忘れられない理由 b.hatena.ne.jp/entry/s/bookplu

これ、逆にわけがわからないのが「過去の日本のここがすごくて、今はここがこういう風に変わったのですごくなくなった><」って話を書くと、若い人から「そんな事無い」って反発が来る事があること><
年寄りならばこの記事の指摘のように「過去の栄光に・・・」だけど、平成中期以降生まれの人が、昭和生まれが体感する昭和と今の比較を否定するの、いやあなた生まれてないですしってなるじゃん?><;

ほぼ全区間センターリザベーションで、なおかつ最高運転速度たかだか40km/h程度で、表定速度20km/h台で、30m級3車体LRV1両定員150名クラスなんてやるのであれば、LRTじゃなくバスレーンで十分どころか24m級連節バスを導入したら下手するとバスの方が表定速度が高いおかげで輸送力も上になる可能性がある><

こういったモードを考慮せずに、郊外のセンターリザベーション区間に「路面電車が来るから!」って商店が立ち並んだり、逆に都心部区間であるはずの場所が住宅地だったりとか、単にそこに電車が通るからの理由での無秩序開発を許してしまうと、公共交通が想定していたのとは違った人の動きになってしまったり、乗客が殺到しすぎてとんでもない混雑率になって、その上で乱開発で建った物件が邪魔で輸送力増強に困難が生じたり、
「これぞ日本の都市!><」って感じの破綻状態になる><

スレッドを表示

それに、LRTを通した/通った だけでは解像度が低すぎる情報になってこれも無秩序開発に繋がる><
路面区間でも、ビジネスやショッピングエリアであれば、サイドリザベーション式やモール化が最適になる><
逆に郊外エリアであれば、道路状況にもよるけど、平均速度の面と騒音を考慮してセンターリザベーション式になる><
速達性が要求される場面や都市外縁の住宅地エリアや大型ショッピングモールがあるようなエリアであれば、路面化は避けるべきだし、
都市の中心部で都市の構造上、路面では著しく平均速度が落ちるのであれば、歩行空間との一体化は犠牲にして地下化するのが最適になる><(ドイツで多いパターンで北米にもある)
その場合はLRT(狭義のライトレール)とは別にストリートカー(路面電車)を整備する例が多々ある><

ていうか、まず都市計画ありきでそれにあわせてLRTや公共交通を作るものであって、日本は都市計画の制約が極端に弱いので、元ツイートの考え方だけだと結局沿線の無秩序開発に繋がって、そして無秩序開発は公共交通とのミスマッチに繋がる><
先に沿線にどういう建物なら建てていいのか決めなきゃいけない><

orange さんがブースト

twitter.com/NAL_MUTHU/status/1
> LRT軌道の敷設は、都市戦略を考える上で必要不可欠であり、相応の需要があると判断したからこそ行うもの。その沿線は将来に渡って都市にとって重要なエリアであり続けるわけで、将来を見通せるからこそ、民間は投資を決断できるんですよね。
> 「数値で表しにくい」部分なんだけど、ここは極めて重要。

人を運ぶという点では、鉄道(軌道系交通)もバスも大差無いんだけれど、その交通手段が持っているイメージこそが割と重要っていうね。
国や地域によってもイメージは違うから、他所の事例を持ってくるときに気を付けないといけない点だと思う。

orange さんがブースト

「goto ではなく if/while を使え」とかと同じ信念であるところの「制約は強い方が意味をよりよく表現できる」に通ずるところがある

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

何であれ「適切な制限を適切に強くできること」というのが人間への可読性や認知の負荷のかかりかたに影響してくるので、その辺りは単にいち構文やいち言語機能がどうこうで言うよりも言語全体でどれだけの範囲をカバーできるかの問題になってくると思う

orange さんがブースト

実際 Rust では「core::fmt::Display trait (interface のようなもの) を実装している FooWrapper 型を関数内で定義する」みたいなことができる

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

もちろん interface を定義して云々やっても良いのだが、利便性の面で言うと、その場合「特定の interface を実装するクラスを関数内やインラインで一時的に定義できる」くらいはさせてくれるよね? という気持ちになるわけで

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

ユーザを信用するかどうかの問題 (ここでいう信用とは善悪だけではなくミスをする存在であるかどうかを含む)

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

主処理の名前を上書きできるようにすると、主処理を呼ばない関数での上書きを許してしまうことになる

完全にそれはそうなので、だからこそ気持ち悪い書き方に見える><(主処理と順に実行する関数をわけて欲しい><)

orange さんがブースト

abstractな時点でoptionalってことはないと思うが…

あと、そういう例だとC# の場合はインタフェースが使われる構造になる気がする><

たとえば子クラスで必ず前処理と終了処理が実装される事を要求する場面ならば、前処理、主処理、後処理の関数として、主処理だけ親クラスに書いた上で、前、主、後って順に呼ぶ実行関数を別にする方がよくない?><
スライドの書き方だと必須なんだかオプショナルなんだかよくわかんない構造に見えるし、変更にも弱そう><

前後の処理をabstractな関数で定義しておく書き方になってる例も、オレンジには気持ち悪いコードに見えた><
オレンジだったら、対象の関数をオーバーライドして親クラスの関数を呼ぶコードの前後に前後の処理を書くってするから><
ていうか、順に実行する必要があるものであれば、真ん中部分の関数から前後を呼ぶなんて気持ち悪い書き方しないで順に呼ぶ関数を分ける><

古いものを表示
:realtek:

思考の /dev/null