社会に感謝！！……ｳｯ
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)님의 게시물
This account is not set to public on notestock.
ｷﾞｰﾊﾄｰﾌﾞすきすぎる、自由ソフトウェアの理想郷感がすごいな
食べたら消える米と、使えば使うほど味の出るオカズ、どちらに使うべきかは自明なんですよねぇ (?)
This account is not set to public on notestock.
美術部にいた頃、顧問から「君の絵は色の使い方がマティスに似ている。調べてみるといい」と言われたり、部員同士で「今度の企画展は最近の方向性に似てるから行ってみたら？」という会話をしたりしていたので、「〇〇に似てる」が相手を傷付けることがあるという意識がなくてWebで何度か失敗して、作品の感想を伝えるのに対する恐怖が私の中にある
「〇〇に似てる」の〇〇に，フォロワーウン万インフルエンサー存命絵師ではなく，古典の大家の名前を入れよう．なんと晴れやかで喜ばしい心持ちではないか．
これは皮肉でもなんでもなく純粋な感想なんだけど、古い芸術家の作品に似ているとすることと最近の作家の作品に似ているとすることの違い、権威か商業性のどちらかしか思いつかない
つまり最近の作家の作品に似ていると伝えられることの不快感は「お前は商業や現代での人気を気にしている」というメッセージを感じ取っているのであって、古い芸術家の作品を引き合いに出すとその要素が排除されるのではと
小道님의 게시물
kunimi_komichi@kancolle.social
This account is not set to public on notestock.
「ソードアート・オンニコニコ」で君もビーターに?! TVアニメ「ソードアート・オンライン アリシゼーション」×「Ｎアニメ」 コラボ企画を開始＆11/3よりTV-CMも放映 ｜インフォメーション｜広報情報｜株式会社ドワンゴ
https://dwango.co.jp/pi/ki/2018/1102/index.html
唐突に思い出した (やってない)
最近の人間を引き合いに出されると否応なく現世的な競争の境地へ引き戻されるのでつらいというのがある．「今生きている人間」という歴史の中の極めて少数に過ぎぬ人間の歓心を買うことに汲々とするのではなく，time-honouredな権威に己を比して真に邁進すべき技術の道を思い出す必要がある．
「古い」がそのまま「由緒ある，敬うべき，優れた」の意味になる価値観の世界に住んで久しいが，ここへ居を移したのがいつのことだったかすでに思い出せなくなっている．
オカズに使うのが DLsite
置かずに使うのが DS Lite
This account is not set to public on notestock.
Search: [違い] - らりお bookmarks
https://shaarli.cardina1.red/?searchtags=%E9%81%95%E3%81%84
違いのプロです
Why is This Website Port Scanning me
https://nullsweep.com/why-is-this-website-port-scanning-me/
邪悪
「タイムラインを浄化する方法」とか紹介してる垢が二言目には「伸びてるので宣伝」と関係ない話題をリプで繋げており、ダブルスタンダードもここまでくると清々しいなと思いながらブロックした。
今日も一日一善
うーん……少しは使いやすくなってきた気はするけど、まだまだ考えるべきキーがいくつもあるな……
1980年代～1990年代初頭辺りのベーマガ世代のお兄さんお姉さん方は、まともに数学を学ぶ前に、難しい漢字が使われてなくてフリガナいっぱいの入門書読んでゲーム作ったりして雑誌投稿とかまでしてたわけで、少なくとも「プログラミングを学ぶのに数学の知識が必要」と言うのは、違うと思う＞＜(プログラミングを学びながら算数をそのなかで学べてたかも＞＜)
日本語の方(つまり小学校の国語)の知識がプログラミングに必要かの方はわかんない＞＜
でも、世の中がWindows95ブームでPCがそういう感じで普及する前夜までは、漢字読めない子でも独学でBASICでプログラミングするのはなにも珍しく無かったので「義務教育の国語も無くても一応プログラミング出来るんじゃないの？＞＜」って気がしなくもない＞＜
環境自体が変わってしまったからアレだけど、1990年代初頭くらいまでは『プログラミングは小学校低学年でも独学で習得できるもの』であったし、そこから30年くらい経った今、教える側の先生が「プログラミングなんてやったこと無い」って、『昔は小学生ですら出来たことが出来なくなった』という退化だよね＞＜
若いやつは馬鹿って事じゃなく、1990年代半ばから、低年齢向けのプログラミング入門環境が疎かにされて「数学を学ばせてからじゃなきゃプログラミングを教えるなんて無理」という『『誤解』』(断言)までがついに広がってしまったって事かも＞＜
それは「昔はさんすうが数学と呼ばれていた」みたいなものでは
(まあ人々が直接的に必要としているのがさんすうなのか数学なのかみたいな話はまた別で考える必要があるとして)
チューリング完全でさえあれば BASIC でどのようなプログラムも書けるというのは真実だし、同時に「BASIC 程度では大抵『良質な』プログラムは書けない」こともまた事実なので、我々は「子供にでもできるショボいおもちゃ」と「相応の基礎が必要だが良質な道具」のどちらかを選ぶ必要がある
BASIC は石炭みたいなもので、文明をブートストラップするには有用かもしれないけどいつまでも使うべきものではないし、いつまでも使って良いと勘違いさせるようなこともすべきでない
その点『のみ』で見ると、1990年代以降に登場したいわゆるLLな言語は、1980年代の行番号つきBASICにすら劣ると言えるかも＞＜
なぜならば古い行番号付きBASICは、数学を学ぶ前の子供に独学でプログラミングを習得させる事だけは成功していたから＞＜
そこらのLLな言語のソースコード、小学校低学年の子が読みとけるんだろうか？＞＜(簡潔さを重視しすぎて省略しすぎな言語仕様にしたら初学者が読みとけるわけ無いだろって言いたい＞＜)
「小学生でも読める」が良いことだとは限らないと考えているので、そこに価値観の違いがありそう
もっと別の言い方をするなら、 BASIC なんて平仮名が書けるレベルの知識であって、それは「日本語で考える」とか「日本語を理解できる」には到底及ばないレベルの基礎の基礎でしかない。
平仮名と数字だけが読める小学生がいたとして、契約書や論文を平仮名で書き下されたからといって理解できるわけではないようなもので。
BASIC が理解できて当然の水準のその上に、めくるめく抽象化の世界が待っているわけで。
たとえばハーバードアーキテクチャのサブセットみたいな仮想機械の動作を追えるだけでプログラミング教育と称するくらいなら、数学と科学に力入れた方が1024倍マシ
まあその基礎のさんすうと理科を教える教諭が水にありがとうと声をかけたりしてる時点で NANIMO KAMO OWARI なんですが
文脈を戻すと、「十分な自然言語の能力も持たぬ子供に抽象化や記号的思考を教えるのはあまりに無謀だし、そこを誤魔化しても得るものがあまりなさそう」という話でした
カワウソマシンガン
님의 게시물
hereoreo@misskey.io
This account is not set to public on notestock.
たとえばλ計算とかを考えてほしいんですが、あれってプログラムというより算術式の拡張なんですよ。 BASIC やその他言語みたいな手続き型プログラミングを一切知らずとも、さんすう・中高数学の自然な拡張として (チューリング完全な) プログラムという概念を生やすことができる。
正直言語のチョイスなんてどうでもよくて、現実や情報に規則やモデルを見出して、それを表現したくなって、プログラミングという手段を獲得する、そこまでの思考過程を自分の中に得られるかというところが一番重要
そう考えたとき、行や穴を埋めましょうみたいな方式でテストできてしまうような †プログラミング† は方向性として最大限間違っているとさえ思いますね。モデルを見出し表現するという一番中核の部分を無視させることになるので
モデルを表現できるならプログラムじゃなくても何でもいいんですよ。「仕様書を書け」とか「マニュアルを書け」とかでもいい。とにかくそこに至るまでの一番最初のステップで自然言語による抽象概念の伝達が必要なことは間違いないけど。
むしろ「少ないプリミティブな道具であらゆる概念を表現しようと試みる」というのは難読言語や極端な低レイヤーのアクロバット的なやり方であって、プログラミング初学者が注目すべき範囲かは大いに疑問です
モデルがあったとして、それを適切な (意図した、あるいは目的に合致した) 抽象レベルで表現できるというところが特に初学者向けの道具として良し悪しを決める性質だと思っていて、 BASIC はその性質がなさすぎる
だから、それって小学校低学年の子が独学で学べる事が一般的であるほどの事なの？＞＜ 低学年の子が独学でBASICでプログラミングは、少なくとも漢字まともに読めない子向けの入門書が山ほど存在した程度には一般的な事だったんだよ？＞＜
だからプログラミング教育はそもそも「BASIC (など) を書ける」ことを目標にすべきでないし、それをもって成績を評価しようとすべきでない、という話をしています
λ計算は「数式や数学におけるアルゴリズムを表現したい」という目的において程よい抽象化レベルや近しいセマンティクスを持っているから、数学やってる人がプログラミング入門するには良いかもしれないけど。それは既にある程度の (抽象概念を理解するうえでの)「土台」があるということに他ならないので
This account is not set to public on notestock.
「動くものを書ける」と「いわゆる “プログラミング的思考” ができる」ことの間には大きな壁があり、これは頓珍漢なことばかり言う自称プログラマみたいなのを目にする度に感じてしまうもの
説明難しいけど、当時のBASICのコードは今どきのLLなコードみたいなものでは無いし(超説明難しい＞＜；)、ものすごく図を多用してどういうモデルで物事を考えるのかを教える形態のが多かったかも＞＜
数ページでひとつの実用的な題材なソフトウェアのコードが書かれていて、どうしてそういう風にするのか？ を解説してる感じ＞＜
それってつまり実際には「低級言語であるがゆえの特有な困難」に対処する必要があったということでは？
当時 BASIC と同等以上に高級で esoteric でない言語があったかというと微妙じゃないですか？
factorio をやってから、「factorio が C なら minecraft は論理回路や……」みたいな気持ちになった
たとえば「こうしたい」という具体的目標があるでとする、そこで minecraft (に限らず低級言語) では「こういう独特な方法を使うとできます、自分で思い付くのは難しいけど覚えとくと便利だよ」となる。
そうじゃないんですよ教育に必要なのは……
問題があったとき分解できる、一段下のレイヤーに潜ることを覚えられるということが大事なのであって、一番下のレイヤーでどう表現するかとかいうのは些事なんですよ。些事。
でも、具体的言語の上で考えようとするとどうしてもその言語を一番下としてどう表現しますかという流れになってしまうし、なんなら教育目的で素朴な (つまり表現力の低い) 言語を選びがちなので尚更アクロバット遊びに帰着されがち、それがよくない
マインクラフトで小さい子が設計を学ぶの、不可能ではないし、例えば赤石回路使う装置を紹介するyoutuberの方々の動画とか見まくって自分でオリジナルの作るのとかは想定できるけど、
一方で、大人でもマルチで遊んでて家建てて飽きてネザーにすら行かず去ってく人が大半なの見ると、かなり難しそう＞＜
(それ言ったらプログラミングしたくてMSX買ってもらったけど挫折してゲーム機にしちゃった1980年代の小学生みたいなものじゃんだし、あれだ・・・＞＜)
上のレイヤーを知っている人が特別な理由 (たとえば極端な最適化、たとえば遊び) もなく下のレイヤーだけであれこれしようとはしないしビジネスでそれは許されない、一方子供は下のレイヤーしか知らないと下のレイヤーだけで何が何でもやろうとするので一見すると能力があるように見える。
見えるがそれは気のせいで、彼らは適切なレイヤーで考える能力を持っていないだけなのである
いや他にも遊びだから困難な方が達成したとき自分ｽｹﾞｰｰ!! と思えるみたいなアレもあるだろうけど。
関数電卓の BASIC で pong もどきみたいなの書いてたりしたけど、まあ端的に言って地獄でしたね
あとはコールスタックのオーバーフローに対処するために配列を使って自前でコールスタックをエミュレートしたり……
未だに僕はファミコンのスペックでBASIC のインタプリタが動いていたという事実が信じられねえよ
BASIC 、 JIT が楽勝そうだし実際そこまで信じられないという感想はない
ところで僕は特段そこまで BASIC の表現力が低いとは思っていない節があるんですが、これはおそらく SmileBASIC やその他 BASIC 派生言語の影響
LINE (0,0)-(100,100)
のような構文、21世紀人の感覚としてはキモッという感じなんだけど対象層を考えると極端に非合理的というわけでもないんだよな
そもそも表現力の低い言語はコア構文がかなり限られているので、キモい例外的構文を入れやすい (入れてもコア文法と衝突しない) というのはありそう
ファミリーベーシックの最適化テクニックとして様々な部分の(一般的にはどう考えても必要な)空白や記号を削るというのがあったっぽいのでまあパーサーもそういう意味ではガバだったんだろうな……
行番号付きなクラシカルなBASIC最高とか言いたいんじゃ全くなく、少なくとも当時それで小学生ですら概念を色々学べていたのにいまそういうの(入門書等の周辺環境を含めた意味で)無いね＞＜(PythonとかRubyとか微妙だよね)
って言いたい＞＜
https://mstdn.nere9.help/@orange_in_space/104202171516752004
「小学生でもできるレベルのことは実は誰からも必要とされていなかった (が、当時それしかなかったので仕方なかった)」という現実が浮き彫りになっただけではという感想です
(cf. https://mastodon.cardina1.red/@lo48576/104202144587241954 )
まあ遊びや簡易な説明としてやる分には使えるというのは否定しないけど。
ここで言う簡易な説明とはプログラミングについてのことではなく、簡単な抽象機械の動作を説明するときにアセンブリ言語として使えるという話
いまだと、ハードウェア全部自分の下にあるような場面って、とても小さなマイコンのプログラミングの時だけだろうから、「やりたいこと」に対して必要なハードウェアリソースを見積もっていく体験自体が滅多に無くなった？＞＜
まあ、組み込み分野が「必要に迫られて」か「趣味で」しか手を出すものでなくなったというのはそうでしょうね。
少なくとも何かをしたいときのデフォの選択肢ではなくなった。
私はそれを悪いことではないと思っているけど
私は割と最近の人間なので、 (限度があるだろとは思うけど) 保守性の向上を極限パフォーマンスよりも優先するというのは基本的には望ましいことだと認識している
ガバメモリアロケーションとかガバエラー検査は「保守性の向上」とは認めねえから！！！！
そういうのは保守性が高いコードではなく雑なコードと言います
ちょうど両方の話にまたがるけど、物事を抽象化して考えて、必要なリソースを見積もりながら、設計する、見たいな事が学べるし、それは現実的に必要な事かもって思う＞＜
必要なリソースを見積もれないのって、設計する上でかなりウィークポイントになるし、そういう意味では「ほんとにこれいるの？ こんなにメモリ必要？」みたいに考えられなくなってしまうのは、悪い事かはわかんないけど「いい事」では無い気がする＞＜
これは工業的には必要なことだと思うけど、最適化は少なくとも起訴の抽象化ができた後の段階でやればいいじゃんという感想ですね
Haskell や SQL で「効率の良い」コードを書けますか、みたいなことを想像してもらいたいけど、抽象化というのは同時に内部実装の隠蔽でもあるので、人間ごときが気にするにも限度があるし、効率に関わる細部を詳細に把握することは優先順位としては抽象化技能ほどには高くない
なんならλ計算はじめ純粋な言語の「効率」とは何ですかみたいな非自明な問題もあるし、「効率」を気にすることができてしまう時点で結構低級であるといえるかも
抽象概念をあとから学ぶと「その表現はいくらりろんといえども効率が悪すぎるのでは？」みたいな邪念が入ってしまう
あと配列のコピーとか部分スライスのコストとかも言語や内部実装次第なのでアレ
順序なしの集合だと思ってたら後から順序が導入されて配列になったりしたらブチギレする
実装はどうでもいいとしても型くらいはもうちょっと明示してくれ
挙がってた Haskell も競プロでは UArray を使用しますみたいな話が多くて僕はなんとなくそれが受け付けないんだよな
こんな時間にﾋﾟｰﾁｸﾊﾟｰﾁｸ鳴いてんじゃねえよ鳥ィ！！！
どこからともなく微かに鼾が聞こえてくるの、本当にウケるんだよなぁ (音からして、たぶん実際はかなりうるさいのだろうけど壁のおかげで相当マシになってる)
これわかりすぎて泣いた (自宅近辺にはいない)
最後ﾎｰで何故か切れて終わるのよね。プロトコルを感じる
朝から聞こえる「ホーホーホッホー↑ホーホーホッホー↑」という謎の声。正体はいったい！？ | ママスタセレクト
https://select.mamastar.jp/268618
This account is not set to public on notestock.
オカズに使うのが DLsite
置かずに使うのが DS Lite
Windowsこの世からなくなってくれ「std::numeric_limits<size_t>::max() が minwindef.h で定義された max マクロのせいで使えなかった私」
# ifndef NOMINMAX じゃあないんだよ、定義する必要がないなら最初から余計なことをするな
Celeste をちょっとだけやった (死にまくった)
#Celeste 、死んでからやり直すまでのテンポというかリズム感が気持ちいいな。
(何とは言わないけどダンダンダンシャーンを思い出したのはここだけの話)
正直インデントスタイルはどうでもいいんだけど（よくない）、80文字制限が最高に気に食わない お前ら640x480のモニターでも使ってるのか？
画面を横に4分割したり6分割したりすることもあるので (まあ6分割はマジで使い物にならないのでそうそうないけど)
横294文字、縦80文字。
横100文字で制限するとギリギリ3分割が際どくなるという感じですね
This account is not set to public on notestock.
これ知らなかった…… (普通に買ってて積んでたやつ)
これはマジな話なんですが、2杯用の安いティーバッグを毎日1つ17時間使っている
This account is not set to public on notestock.
This account is not set to public on notestock.
やっぱり払わないのが最強の節約、自明なんだなぁ (???)
This account is not set to public on notestock.
Patent case against GNOME resolved – GNOME
https://www.gnome.org/news/2020/05/patent-case-against-gnome-resolved/
This account is not set to public on notestock.
奴隷制度を容認していた国の歴史書も古典小説も当然受け入れられるわけがないというお話ですね (???)
これは本気で言うんですが、アホを相手にしてもデメリットしかないので、力強く一蹴してやらねばならない
自分達が受け入れられている、受け入れられる余地があると思わせてはいけない。ここはオメーらの遊び場じゃねえから他所でやれと明確に言ってやらないといけない
文書のノードの属性とかのメタデータをどう管理しようか悩んでそろそろ1ヶ月くらい経ってる頃ですかね……
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
これ今更気付いたけど eccho $COLUMNS, $LINES で一発で済んだやつですね
Tracking Issue for Async I/O migration · Issue #1065 · SergioBenitez/Rocket
https://github.com/SergioBenitez/Rocket/issues/1065
思ったより結構進んでた
朝日新聞社内には「この程度の食い込み方は記者ならやって当たり前」との意見もあるようだが…：賭け麻雀、朝日新聞社員は経営部門 | ビジネスジャーナル
https://biz-journal.jp/2020/05/post_158433_2.html
やー、崇高な使命を胸に活動してらっしゃる方々は一般人とは言うことが一味違いますねぇ
This account is not set to public on notestock.
大失敗して玉座から追いやられた元国王「朕は木っ端なり」
This account is not set to public on notestock.
This account is not set to public on notestock.
土日のどちらかで初見のホームセンターに行ってメタルラックを買わねばならない (PS4 等を置くため)
C++ で ctor が呼ばれる前にメンバ変数が valid にならないといけないせいで unique_ptr における nullptr みたいな無効値を許さなくてはいけないの、マジで涙を流してデフォルトコンストラクタ用意してる
C++17 以上であれば std::optional も使えるけど、これは「初期化だけ遅延させたい」という用途に使いたいものではないので残念ながら別の話なのである
そもそも JIS キーボードは右 Shift キーが短すぎて人権がないので、あんなの使ってる奴は左手の小指が壊れるか右手の小指が常人の2倍くらい長いかしか考えられない
This account is not set to public on notestock.
Rustの2種類の 'static | 俺とお前とlaysakura
https://laysakura.github.io/2020/05/21/rust-static-lifetime-and-static-bounds/
rust-jp でそんな話題あったなぁと思ったらまさにそれだった
> 自分はstructやenumに 'static ライフタイムな参照を含めたくなったケースがない（その場合は値そのものをフィールドにする）ので、太字の考え方をしています。
'static な参照をフィールドに持たせたくなる例、 generic なものを含めて良いのであれば典型例として Cow<'static, str> などがある
Cow<'static, str> は Owned(String) か Borrowed(&'static str) になるので、たとえば「外部入力か、あるいはプログラムに組込まれた文字列」みたいな文字列を扱いたいときに有用。ユーザ入力がなければデフォルト値を使うみたいな。
@kb10uy rusttype::Font - Rust
https://docs.rs/rusttype/0.9.1/rusttype/enum.Font.html
Font<'a> を Font<'static> にするなどの需要もあり (この場合は内部的には &'a [u8])
まあ [u8] も str も似たようなものではあるけど
@tacumi
・HardwareManager がある
・HardwareManager が、ハードウェアへのアクセス権付きのハンドルや、 GPU 上にアロケート・アップロードされたリソースのハンドル等を持つ
・リソースのアップロード等は複雑な手順やエラー処理や変数間の依存関係を伴うため、 Ctor():m_field{field}, m_other{other}, ... {} のような形式で最初に初期化するのは困難
みたいな状況が考えられます
@tacumi まあ一応そういうロジックを外の関数に括り出して HardwareManager を返すような普通の関数にしといて、
HardwareManager():HardwareManager/*This is private ctor*/{createHardwareManager()}
{}
みたいにするという小手先テクもあるんですけど。そういう文法的なことで面倒なことしたくないんですよね
Rust で ctor がない (ので、フィールドを一通り作って素朴に値を返す関数を用意する) というのは、値を初期化する前に何らかの不完全かつ妥当な状態を要求しないのでとても良いと思う
@tacumi この場合、 HardwareManager は「生存している限りシステムは良好な状態である」という性質を捨てる必要があって、 unique_ptr が何も指さないことがあるように、あるいは fstream がファイルの閉じられた状態や何も開いていない状態であるありうるように、「なんかよろしくない状況なんだけどプログラムとしてクラッシュはしない」くらいの雑な保証までレベルを落とす必要があります。
C++の言語仕様的に避けられない悲しいやつです
(C++11 以降だと、 move された後の抜け殻には何が入っているのみたいな問題も同様の「有効ではないけど未定義動作とかは起こさない値」みたいなのを入れとくことで誤魔化されるのがそこそこ一般的です)
@lo48576 (std::numeric_limits<size_t>::max)() みたいに書けば使えるはず
ただ SATySFi 使っただけではなく、文芸的プログラミングしてた
@tacumi fstream が「開いているファイル」を表現するのであれば、デフォルトコンストラクタは存在すべきでないですよね。 ctor で開くのに失敗したら例外が飛んで fstream は存在できない。
Rust の std::fs::File とかそんな感じなんですが
C++ の fstream や unique_ptr は、利用可能でいつか開放されるべきリソースを表現しているにも関わらず、暗黙に「リソースを所有していない」という NULL 的な状態をひとつ追加で許しているので、実質的に暗黙の null だし、言語仕様としては駄目な方のやつです
This account is not set to public on notestock.
2038年問題とか気にするまでもなく普通のマシンが64ビット環境に移行してしまった (良いこと)
This account is not set to public on notestock.
AX (Accumulator eXtended)
EAX (Extended Accumulator eXtended)
RAX (Register Accumulator eXtended)
アホっぽくてすき
CPU ベンダ「 RAX super rich (64 bit)」ってもう言ったっけ？
