SSブログ

報道特集でのヤングケアラーについて [徒然]

TBSの報道特集は毎回二つ特集をやっているのだけれども、どちらかは興味の対象であることが多いので毎回見ている。ググると偏向報道とか出ているけれども、TBSにしてはそこそこ平均的な見方をしているのではないかと思う。

今回はヤングケアラーの問題をやっていた。親の面倒を子供が見る、の若い人版なのだが、ティーンぐらいの子供が親の病気の面倒を見ていることの辛さをどうしようかと言う話である。日本ではヤングケアラーの把握すら大してやっていないのだが、イギリスでは自助会みたいなものやサポートの手段があるとされる。

日本は仕組みができてしまえば、それがそこそこ行政がやってくれて形骸化しない限りは割と大丈夫だ。だけど、問題があるのがわかっていて放置したり、日本特有のわけのわからない自己責任論で社会的に切り離されがちである。歳をとってからの老老介護も問題だけど、ヤングケアラーの問題も昔からありそうで、最近の核家族化から顕在化している問題であろう。日本は問題があったら蓋をするか無視する傾向にあるので、ヨーロッパ的な問題があったら乗り越えるというポジティブな環境ではない。

日本は既存の仕組みを真似るのは得意だけど、現状を理解してそれを解決する能力が低い。そしてそれを解決する法律なりができても、その名目上の目的を捉えられずに法律に抵触するからやるとかやらないとかそういう方向にしか動かない。他人事としてしか捉えられないのが日本人であり、自らに厄災が降りかかってこない限りは無視する。まぁそうしないと災害等も多いので耐えきれないのかもしれないのだが、あまりにも悲しい世界ではないだろうか。


その日の別の特集で、千葉の台風による大停電の対応の遅れの話が出ていたけど、千葉の人には悪いけどある程度は仕方ないところではないのだろうか。東電が復旧がすぐにできると言っていたのにできねーじゃねえかというのはそうなんだけど。

東日本大震災の福島と同じくまた東電だけども、今回はそこまで叩くほどの悪手はしていないと思うし、実際に動く関電工さんなどは非常に優秀であったことは間違いのないところだろう。後から状況を見て叩くことは誰だってできるし、すぐに復旧できると言ったこと以外は仕方ない話だとは思う。実際に停電している人にとってはムカつく以外の何物でもないとは思うけども、テレビが後をつついたところで森田健作が困るだけで後に役立てられるとは思えない。

今回は行政も後手に回ったし、東電も安直な復旧計画を言い出してしまったし、最終的には停電状態が長い間続いてしまった。ただ、各所が上手く立ち回ったところでそれほど素早く復旧したとは思えないのだ。全部が全部上手く回っていたら、もう少しマシになっていたかもしれないが、台風の被害が出たこと自体は変えられないわけだ。

しかし、これだけのおおごとになっていても、政府のガン無視ぶりはやはり自民党の安倍政権っぽいなと思った。今までもいくらでも大災害はあったのだけれども、それに対して臨機応変な態度を見せたことがない。ポーズだけでもいいからやればいいのに、金にならないところには全く興味がない安倍政権。ほんとこんな人たちが国の中枢にいること自体信じられないのだが、おかしなことに支持率は低くない。まぁこれだけネトウヨが台頭しているから仕方ないのだが、右翼だから支持するという盲目的な支持の仕方がわけわからない。


ヤングケアラーにしても、災害復旧にしても、日本人が自らいい方向に歩もうという意識がなければ上手く動かない。国ぐるみにしても草の根活動にしても、それが改善の方向に持っていこうというポジティブさがなければどんどん闇にはまっていってしまうのが日本なような気がする。

コメント(0) 
共通テーマ:テレビ

SwiftとGolang並行してやるとわけわかんなくなりがち。 [プログラミング]

どっちもそれほどクセが強い言語ではないので、いわゆる常識的な範囲では混乱する事はあまりない。もともと用意されたライブラリを使ったり、ありもののソースを改造したりするので、そこまで文法で引っかかる事はないのだが、細かいところはやっぱり引っかかる。

最近の言語はお互いに参考にしているところが多いので、プログラマのコモンセンスが割と役に立つ。とはいえ、やはり別々の独立した言語なので、そもそもの演算子がなかったりあったりで、こっちはそういうのなかったんだったっけという場面も少なくない。

Swiftは再三の要求を受けてAppleがOSS化したんだけれど、僕がOSS版を使った時はまだまだだった。そもそもAPTなどでパッケージ化されていなかったり、コマンドラインで必要な部分のライブラリがスタブ状態で実装されていなかったり、コマンドラインのツールを作る程度の状態にはなっていなかった。

今の状態はわからないけど、たぶんSwiftは基本的にMacやiOSのアプリケーションを作る言語であるという前提条件を出ない域であろうと思う。言語の素養は悪くないので、コンパイル言語としてもっと活躍してくれていないのは残念である。


同じコンパイル言語として、ガベージコレクションを使っているGolangだが、SwiftのARCにしてもメモリの解放を考えなくていいのは楽だ。というか、本来の処理を考えるとメモリの確保と解放は本来的な部分ではないことが多いので、言語側で処理してくれるのは正しい進化ではある。旧Objective-CとかC++がダメなのはそういうところだったから、LLのようなスクリプト言語のようなメモリの処理は期待されるところである。

それとGolangがいいのは他の人が作ったパッケージをサクッと使える仕組みである。gitリポジトリから取ってくるのかHTTPでアクセスして取ってくるのかは知らないけど、パスを指定してあげるだけで取り入れられるのは作る点においてしんどさが少なくていい。ソフトウェアは手元に自己管理で持っているというのがかなりしんどいことで、どこかで一元管理してくれていればそれに乗っかってしまった方がいい場合も多い。一度固めてしまったソースを弄られたくないとかなら、参照先が新しくなってしまうのはきついが、まぁセキュリティーも上がるのであればそれに追随すべきなのかもしれない。

SwiftがまともにApple以外の用途で使えないのであれば、Golangでやるのが筋なのかもしれない。というか、まともなオブジェクト指向のコンパイル言語が出てきたと思ったら、やっぱりAppleで使うのがせいぜいなんかいというのが、やっぱりAppleという企業の懐の浅さを示したところだろう。そもそもOSSにするのさえ渋っていたのだから、そのままOSSになったという時点でまだ歓迎するべきなのかもしれないが、その後があまり良くない。そもそもAppleとOSSというのはあまり相性が良くないのだ。それは多分最近のMSを下回るレベルだと思われる。


というか、Golangが出来てから、別に無理にオブジェクト指向にしなくていいんじゃね?という流れができた気がする。オブジェクト指向ではないのに加え、ライブラリパッケージが薄めにできているのも、Golangの性格が出ているようだ。あまり階層を深くして作ったところで、使うときに調べたりするのに面倒なのは余計な労力だろう。MSの.Net FrameworkやMacのCocoaはオブジェクト指向でシステムのAPIを組んでいるが、Linuxとかでオブジェクト指向のライブラリは少数派なんじゃなかろうか。結局、べったり平らな単純な関数が並んでいるAPIの方が使いやすいとされているような気がする。

一度はオブジェクト指向万歳な時もあったが、そのライブラリを作っている方としては組み直しがきついということを念頭に置いて設計しているとは思えなかった。Cocoaはやたらdeprecatedなメソッドがたくさんあった気がしたし、何年かしたら使えなくなるライブラリなんて使いたくない。


今、Swiftを全体をさらっておこうかなと思っていたんだけど、どうせAppleでしか使えない知識は覚えるに値しないんじゃないかと思い出した。その場で本などを見つつ書ければいいレベルの頻度しか使わないんだから、もっと別のことをすべきかもなぁと。でも文法の本ってさらっと流して読むってことがしにくいんだよね。どうしようか。

タグ:Golang SWIFT
コメント(0) 
共通テーマ:パソコン・インターネット

Twitterまとめ投稿 2019/09/28 [Twitter]


コメント(0)