The Travis CI Blog: Announcing support for open source projects on travis-ci.com - https://blog.travis-ci.com/2018-05-02-open-source-projects-on-travis-ci-com-with-github-apps?utm_source=email&utm_campaign=2may_release

ふむ

GCC 8.1 Compiler Released As The First Stable GCC8, Brings Many Improvements - Phoronix - https://www.phoronix.com/scan.php?page=news_item&px=GCC-8.1-Released

起きて gentoo repo に上がってたらさっそく入れてみたい(が、たぶんそんなに早くは来ない)

電子書籍の DRM を絶対に許さない

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

どちらかというとｺﾝﾋﾟｭｯﾀとかメンタルモデルがしっかりしていないのではと思っている(根拠なき個人の感想)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

むしろ長期的な視点で見るほど DRM は害が大きいので、1e17歳生きてる人は DRM に反対しそう……と思ったけど、1e17年も生きていられる人は記憶力が桁違いなのかな？

さて、 sys-devel/gcc-8.1.0 を入れます

このアカウントは、notestockで公開設定になっていません。

それは媒体の問題であって、コンテンツそのものの保存性の問題ではないので

そもそも完全なコピーができるのであればメディアの経年劣化は本質的な問題にはならないので

s/とか/とかメモリの/

寝起きなので手と頭がちゃんと動いてない……

.

個人的には、コーディングってマジで「書くだけ」なので、その前段階の設計と書いたあとのデバッグが思考リソースの大部分を占めていると思うんですが

逆に言えば、コードとおおよそ1対1対応するくらいに精確に、コンピュータやコンパイラに何をさせたいかイメージできていないと手が動かない

で、結局「何をさせたいか」の部分って脳内で可動式のオモチャをガチャガチャ動かしているようなものなので、メンタルモデルが堅固であることがとても大事なのではないかと考えるわけです

もしかすると脳内でガチャガチャせずに要件からスマートにコードを吐き出せるタイプの人もいるのかもしれませんが、それは私の考えの及ぶところではありませんね……

あと設計といってもクラス図云々みたいな「人に伝えるための整理された情報」ではなくて、もっとモヤっと混沌としたグラフ的なものです(私の場合は)

人に伝えるための情報なんて、コードとコメント(ドキュメント)とテストから自動生成すればよろしい(個人の感想)

このアカウントは、notestockで公開設定になっていません。

あれ、もしかして普通の人って「コードから挙動を想像する」の方向で考えてるんですか……

ずっと「挙動を分解して記号化する」の方向で勉強してきたのであまりｲﾒｯｼﾞがわかない

たとえばいつぞや書いた気もするけど、 git の勉強とかも「git add してみましょう！ﾎﾆｬﾗﾗになりましたね！」みたいな最初に手を動かす方式よりも、 staging area とか worktree とか diff とか snapshot みたいな概念を知ってメンタルモデルを作る方を重視していたので

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

著作権が切れた後、ちゃんと DRM なし版が配布されるとは限らない……

「数学には解がひとつしかない/答えがひとつに定まる」みたいなアレだな……

さんすうのｲﾒｯｼﾞを持ち込まれている？

https://mastodon.cardina1.red/@lo48576/99963315443782392
こうして言葉にしてみると、私が記号的な思考を得意としていないことがよくわかるなぁ……

グラフとかオートマトンみたいなものを考えるときも、記号じゃなくて対象のモヤっとしたイメージをガチャガチャやってたりするからな……

エッジケースを考える癖が付いているので辛うじてこれでどうにかなっている感が強い

穴埋めなら答えられるタイプのアレっぽい

このアカウントは、notestockで公開設定になっていません。

初学者の質問、しばしば「hoge をしたいが、どうすればいいか」という質問を掘り下げていくと「fuga をするのに hoge する必要がある」などという情報が出てきて、しかし根本的に fuga に hoge は向いてなかったり間違っていたりして、難しい

要求開発みたいな真似が必要になる

脳のワーキングメモリがとても小さいので、私はトップダウンで依存を手繰って考えていくのは苦手ですね……(何を考えていたかすぐに思い出せなくなる)

扱いたいデータを表現する型をぜんぶ最初に用意して、あとは I/O などからデータをその型に用意するコードを書いて、そうすると全部メモリに乗せられるのであとはロジックを書くだけ、みたいな感じでやることが多いです

つまり、「今やっている作業は○○から必要」という方向よりも「今やっている作業をすると○○できるようになる」という方向で作業を記憶している

これだと、「今あるコードから何ができる」というのがわかりやすいのと、「以前書いていたとき何からやろうとしていた」という作業の依存関係が発生しづらいので、記憶に優しい

「これの次は○○をする」とかが本当に覚えていられないので……

記憶力が欲しいよ……

このアカウントは、notestockで公開設定になっていません。

私は美しいコードの方が好きですね(どちらが金になるかは別として)

うんこを食べて生きるか、虚無を食べて死ぬかみたいな話(適当)

このアカウントは、notestockで公開設定になっていません。

これも結局「自分の知っているモデルに落とす」とか「自分の知っているモデルを拡張する」の方向にいくので、そのパラダイムで最初に勉強する言語ではモデルとても大事なのでは

λ計算とかどうやって勉強したんだっけ……

grass を知って SKI コンビネータで遊んだんだったか？

あと料理は並行・並列な処理が必要なので完全に記憶リソース不足ですね

このアカウントは、notestockで公開設定になっていません。

たとえば「カードを並べ替える」とき無意識に2本の腕を使ってしまうところからして、計算機レベルでは (swap 除き)プリミティブじゃないし……

最初に CPU には1本の腕しかないということを納得してもらう必要がある

https://sandbox.skoji.jp/@skoji/99963403786159943
コミットメッセージかな

やりたいことと大雑把な仕組みはトップダウンで決まるけど、「この通りにコードを書けばおｋやで」という「書くだけ」ステージには持っていかないなぁ(私は)

授業では若干そういう感じの方法論も習ったので、まあ産業的にはそれが普通なのかもしれないけど……

とにかく「何をするべきだったか思い出せない(メモをしても精確に概念を再現できるわけではない)」が障害になるので、「道具を作ればあとは組み合わせるだけ」みたいなフェーズに持って行くように道具を作る

なので実装最終段階はシェルスクリプトでも組んでいるかのような気分になる(既に自分が欲しがりそうなコンポーネントは出来上がっているので、いい感じに組み合わせる)

これ、ちょっと考えてみたけど、最少単位が一通りわかってないと「どこまで分解するか」とか「何へと分解するか」みたいなのがわかってないとどうすればいいんだ……みたいな感じになるので、やはりメンタルモデルかなぁという気持ちになった(個人の感想)

このアカウントは、notestockで公開設定になっていません。

たとえば「腕を動かすことに注目するべきか」とか「指を動かすことに注目するべきか」とか「目線の移動を気にするべきか」とか、そういったあらゆる細部を適切に抽出し適切に無視するために、「今考えている基盤で要求される操作の粒度」は大事なのかなと

私が割と自己完結的に考えがちなのでそういうインタラクティブな思索が苦手だというだけの話だったかもしれない

「前提条件を後出ししてくるの反則やろ……」みたいな気持ちになる

意識し活用できるかは別として、まず情報開示を行ってから始めましょうという気持ちが強い

たぶん「情報の後出し感」がそうさせるのではという考えです

たとえるなら、文法を提示されていない言語でコンパイラと闘っているような

「それ最初に言えや」みたいな

その設計が何から成っているのか(記述の最小粒度)が提示されていないから、「まだやるの？どこまで掘り下げるか聞かされてないんだけど……」というゴールの見えない感が出てしまうのでは

たとえば求める条件の記述が、状況によって「カードが昇順に整列されている」で十分なこともあれば、整列や大小関係とはどういうことなのか記述する必要もあるかもしれないし、そういった「設計をこれでよしとする(メタな)条件」が明示されてほしいという感じだろうか

その場合で言えば、ソフトウェアを記述するための基盤はソースコード(言語)であるわけで、つまり提示されるべきなのは言語自体の仕様や操作の大きさ

あれ？いま初学者に教える話だった気がしましたが

それ私が嫌いなタイプのやつだ……完全に個人的嗜好の問題っぽい

どう喩えたものか……

たとえばなんか巨大な整数を与えられて「さあ分解してみましょう」と言われたとして、それをなんだかよくわからないけど延々と分解していって、いつか「おっ、それは既にありますね！やった！」と言われるまで延々とポチポチして分解しつづけるみたいな終わりのないジョブ、私にはちょっと耐えられないです

ここで提示されてほしいメタ条件は、「分解先は2以上の自然数でいいです」と「分割後の積が分割前と一致するように分解します」だったりするわけで

試行錯誤するにしても、「整数に分解します」の部分は絶対に最初に提示するべきだと思うんですよね

既成の部分が使えるかを知るためには「これはこう使える」みたいな用法まで含めた部分がわかっていないといけないわけで、それって最初に教えるべき部分ではなくて、「問題を(設定された粒度まで)分解できる人が、部分的に未分割な問題とうまく付き合う方法」という、言ってみればステップアップ後の段階なのではと思いました

条件が足りないと「足し算をする必要があります→まず AND と XOR を作ります」みたいな分割までやらないといけない(それをやる直前まで「ここで終わり」と気付けない)かもしれないわけで、「ここまでいけば十分であろう」というのを設計者自身に自覚してもらう/見通してもらうためには「足し算できる機械が最初から用意してあります」という前提条件が必須だと思うわけです

そういう、「これ以上掘り下げる必要はありません」という壁のようなものは、設計そのもの(いわゆる「答え」)を直接には記述しないわけで、これが事前に提示される必要があるのではと考えます

無論、現実に高度な問題を考えるうえでその壁というか限度が見えないということもままあるでしょうけど、それは初心者に教える例として使える難易度の問題ではないというだけで、選択のミスではと

「ソートは与えられているので今回その中身を考える必要はありません」という条件と、「こうするとソートができます」という知識は全く別の話で、たとえば後者を知っていたからとして今回の設計でそれを使うとは限らない(それを掘り下げるべきではないかもしれない)

もっと小さな問題で考えるなら、「加算できる機械があります」という前提条件と「こうすると加算ができます」という知識はそのまま交換可能ではないわけで、設計を試してもらううえで、後者を考え出す必要がないのであれば、前者の条件を事前に与えるべきなのでは、ということです

それは提示されることと活用することを同一視しているから発生する懸念であって、たとえば数学書で定義を覚えていなければ後から戻ってもう一度閲覧できるのと同じように、提示された条件も指摘された後で戻って確認することもできるわけです

「自分で気付く余地がある」というのは大事だと思っていて、それがないと「自分で気付けたかもしれないことも、インストラクターから全て指摘されるまで確定できない」という他人に制御されている感が強烈になる

「おっ、そこに土台あるじゃん」という「達成の予感」を得られるかどうかが、前提条件の事前の提示があるかどうかで決まるのではということです

？

設計の方法論について納得したのであれば、上のレイヤーを設計するときと下のレイヤーを設計するときの違いは分割の粒度のみなので、特定の例でソートの内容を考慮しなかったからといって、ソート自体を設計できないということにはならないのでは

その「自分で考える」は前提条件の提示により妨げられないのでは……？

その土台の形が最初に提示される必要があるのではという話をしていたのですが……

かなり噛み合ってない気がしてきた

なんか根本的に食い違ってたw

というか「土台」という言葉の意図も噛み合ってない予感がしている

「設計という作業の完了条件(メタな条件)を誰が判断するか」という話で、まあ普通に設計者がそれを判断するものだと思います。
であれば、その完了条件は「そこまで分割したならこういう部品がありますね！」という(教えられる側から見て偶発的な)指摘のみに依るのではなく、教えられる側が最初から参照できる場所に「おっ、これならもうこの部分の設計は完了したといえるな」と判断できるように提示されているべき、という意図の話です

たとえばトランプを並べ替えるソートを設計するとして、両手での swap を使って選択ソートを表現できた人がいたとして、「でも両手は使えないよ？」と後から言われるとイラッとするわけで、であれば最初から「カードを持てるのは片手までです」と提示してほしい、というレベルの話です

ここで「カードを持てるのは片手までです」とか「一度に注視できるカードは一枚までです」とか、そういう前提条件の提示は、ソートアルゴリズムを設計するうえで解答を記述することにはなりませんよね

で、私の言う「完了条件」というのは、「目的の動作を、『片手で一度に一枚までカードを持つ』などなどの前提条件を満たすような操作のみに分割できたこと」という風なものです

それは最小単位を組み合わせて大きなものを作ろうとするから混乱するのであって、それはまあわかるんですが。
かといって、大きいものから分割していこうというとき、最小単位を隠すというのは回答者にとってストレスフル(かつ実践的とは限らない)のではないか、というのが考えです

「操作を組み上げるのではなく、問題をだんだん分割していきましょう」というのと「最小単位がわかりません」というのは独立していると思うのですが

最小単位がわからない状況もあるかもしれませんが、それはまた別の話ですよね(要するに設計の前に環境と状況を調査しろという話であって、まあそれも設計というフェーズに含めて考えることもできるかもしれませんが)

それはバックトラックと再帰的な問題の分割により達成されるものなので、前提条件と無関係では……？
そもそも「よく考えたら出来ない」というのがどう判定されるかというと、「操作の最小単位まで分割できなかった」という条件によるわけで、結局最小単位がわかっていないと失敗判定もできないような

これは嘘では

たとえば CPU で実行可能なあらゆる命令が列挙されているとして、それはソートアルゴリズムを必然的に記述できるので設計が完了しているとは見做せませんよね

gcc-8.1.0 のビルドが完了していたので、 emerge -e しにいきます

その「できるのかを知る」は低位のレイヤーにいくとたとえば「コンピュータアーキテクチャを知る」などになるわけで、それは必要な知識かもしれないけど、やりすぎればもはや設計とは別のレイヤーではと思います

や、まあそこまで含めた設計の必要がある場合もあるだろうけど、それは初心者への例題としては不適切では

「ソートせよ」が存在しないというのは、命令の一覧を眺めることで知ることができるわけで、それは設計という作業を通して知るべき知識ではなくて、設計に先立って把握しているべき条件や知っているべき知識から察せられるべき事柄ですよね

逆に言えば、「前提となる環境等を十分に調査・把握しないうちから設計をしようとしたって真っ当にできるわけがない」みたいな話になるかな？

であればこそ、方法論の前に十分なメンタルモデルが欲しい、という発想になるわけです(最初の話に戻った)

そのときは設計を別経路からやりなおす(バックトラックする)か、壁を乗り越えるサブ問題を設定する(再帰的にやる)べきなのであって、結局その「壁にぶつかってその存在を知る」フェーズは設計の本質を知るのに必要ではないのではと

つまり、壁にぶつかる直前までの方法論を(ちょっとだけ方向を変えて)継続することで進行することができるので

うーん

私の腑に落ちないのは「癖を付けさせる」部分なのだろうか……

結局「こう考えれば楽にできるんやで」とだけ言っておけば自然とそれを使うようになるし、敢えて暗闇を歩かせる必要はあるのだろうか、という……？

或いは、強制と反復によって思考パターンを植え付ける方式に抵抗がある、という感じだろうか？

他者からの苦痛を伴わないとどうにもならないようでは、知的な学習というより獣の躾ではという(暴論)

すごい暴論だけど「できるやつは勝手にやるようになるし、できないやつはいつまでもやらない」みたいな話

まあこういう姿勢はほぼ無条件な相手を対象とする教育としては成立しないんでしょうけど

こう、「ステージを上げる」ためにはそういう強力な干渉が必要なんでしょうけど、たとえば「ポインタなんていらない、 Python があれば十分」と思っている人はそれで十分な範囲からあまり出てこないわけで、いざそれで足りないとなったとき勝手に勉強するやつと諦めるやつがいるのではと

で、ハードモードでやる必要があるのは後者をどうにかする場合なんだろうけど、それって著しくコスパが悪そうという感想

勝手にやる人の手を引っ張った方がいろいろな面で、まあ、なのでは。

いやこんな偉そうなこと言ってられる立場でもないんですけどね私は

私は知りたいと思ってない人には理解を求めないタイプなので、まあその辺りの違いなんですかね

基本うちのサークルはそっち系に明るい人が多いし、理解させることを義務として物を教えたことはないので

私はまず「知りたい」が先にくるので……

「○○をしたい」が先立ったことはほとんどない気がします

「何が起きてるかわからないけど魔法が起きてなんとかなる」みたいなのあまり好きじゃないので……

物理的な原理とかまで深掘りするかはともかく、「何をすると何が起きてそれゆえこの結果になる」というくらいの因果は知っておきたいし、その因果を納得できるためには表面的であれ原理は知らずにはいられない

電子回路からｺﾝﾋﾟｭｯﾀに入った勢なので……

まあ現実に全てを掘り下げることはできないので興味と必要の強さに応じて選択的に疑問を無視するわけですが、そういった諸々はモヤモヤとしてストレス源になったりするので

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

これは文法からモデルを構築するのに慣れている人のやりかたっぽいので、初学者とはだいぶプロセスが違うのかなぁという気がします(知らんけど。共通かもしれないけど)

プログラミング言語を「言語」と区分しがちなのも誤解に繋がっているのかなぁという印象はある

どうせﾎﾟﾖｸﾞﾔﾏなんて抽象構文木とかを思い浮かべてるんだから文法なんて大して問題ではなくて、本当に注目・区別すべきなのはパラダイムとか意味論とかなんだけど

ただ、ありがちな「FizzBuzz 書いてみて言語を比べてみます」みたいなアレな web ページとかでは、文法についてあれこれ言ってるのが多くて、ｱｯﾊｲ何も見てないんだね、という気持ちになりがち

文法に言及するのなんて、 C のポインタ型くらい滅茶苦茶な減点があるときくらいで十分

や、条件を最初に提示しろというのと、条件に基く判定を全て回答者が行えというのは別の話では

べつに条件を提示したからといって、道を外れないためのガイドを行ってはいけないわけではないです

たとえばループをジャンプ命令でやってたとして、「ここに！ループ命令が！書いてあるだろう！！なんで使わないんだ！！！！」とか言いませんよ初心者に

ループ命令を使うかジャンプを使うか別のことをするか、そういった選択は回答者が勝手にやることであって、「おっジャンプ命令があるじゃん、これ使えばおしまいだ」という「完了の予兆」に回答者自身が気付ける環境であってほしいという話です

その教材見てないのでわかりませんが、結局「プリミティブな操作」は既知なのでは……？

なるほどなぁ

命令は「そこにあるもの」というお気持ちなので、「欲しいもの」は(命令と粒度が一致するかはさておき)すべて「処理」であって命令とは別の話、という感じの想定です

今そこに現実があって、その上で問題を解決したい、というモチベーションなので

フレーム問題みたいだな

現実の側を弄れるなら、それは基盤とするモノ自体が間違っているというか、弄れるもの含めて設計の対象であるべきなのであって

少なくとも、今自分が行っている設計作業の手が絶対に及ばない領域と、そうでない領域を区別させてほしい

たとえばヒイヒイ言いながら英語で何か書こうとしていたとして、「日本語でおｋやで」と後から言われると、最初から言えや💢となるので、「言語は日本語か英語です」という「弄れる領域」(或いは「言語は英語限定です」という「弄れない領域」)を区別できないと自由に活動できない

で、「日本語か英語です」と言われたうえで、敢えて「英語だけでいこう」という選択肢もあるわけで、領域を明確にすることは必ずしも選択の変化を強制するわけではない

その「目的」というのがトップダウンに与えられるのが好きじゃないかも

「そこにあるソレを、使えるように使う」というので事を為すには十分なわけで(それが最適とは限らないけど)、「これは○○のためにあります」と言われても、はあそうですか……となる

たとえばソートアルゴリズムにランダムな大小比較を代入してやればシャッフルになるかもしれないじゃないですか

最終的な用途を決めるのはユーザであって、設計者の意図を忖度する必要はない(まあ最適なことをしようと思ったらいずれそれも必要になるけど、それはまた別のステージ)

で、「○○がしたいです！そういう部品はありますか？」といちいち聞かないと「あります/ありません」の答えが得られないという対話的環境が非効率だ、という話です

使えるものが列挙されていれば、「○○がしたいです！……なかった、まだ分割するか……」と自分で判断できるので

部品の用途と設計の目的は独立です！

たとえば整数乗算命令を高速な整数除算として使うこともできるわけで、「除算をしたいという私の目的」と「乗算機能を提供するという CPU 設計者の目的」は全く別です

つまり「乗算命令を使って除算を実装しようとしている人を止めるか止めないか」という話であって、「ここに除算命令もあるけど乗算を使おう」というのもまた設計なのではと

「除算がしたいんですけど……乗算しかないんですか？」と聞かれたとき初めて「ここに除算があるんですよ」と言えばいいのであって

そうですか？

「使おう」と言ってるのはインストラクターではなく設計者ですよ

あと「聞かなくても『ここに除算があるじゃん』を最初から知ることができるのが大事」というのが私の主張なので、その点が orange 氏とは違っていた気がしますが

それはインストラクターが口出ししろという意味ではなくて、「手元に一覧を渡してくれ」という意味です

その一覧を吟味したっていいし、ざっと眺めて人に尋ねるのをメインにしてもいいけど、尋ねることを強制されるのは駄目

ざっと眺めて尋ねなかった結果除算に気付かず、遠回りにも乗算命令を使おうとしたとして、それが不正解とは言えないのだし、それでいいのではと

その「全て」が、結局コンピュータアーキテクチャであるわけで、つまるところそのくらいも知らずにﾎﾟﾖｸﾞﾔﾐﾝしようだなんて簡単にいくわけがないのではというお気持ちです

このアカウントは、notestockで公開設定になっていません。

そもそも料理は非同期・並行・並列と闇が揃っているので、プログラミングに喩えるにはあまりに複雑すぎる

さんすうを知らない人に素因数分解を教えようとしたってしょうがない、いや可能かもしれないがそこまでする意味があるのか、という

先にさんすうを教えなさい、という感想しか持てないし……

べつに数論を教えなさいという話ではないんですよ、算数を教えなさいというレベルなんです

コンピュータも同じことで、仮想的なモデルはそれ自体がある程度抽象化されているので、その先のハードウェアの知識には実は依存関係があまりない

たとえばチューリングマシンを説明するのに歯車の形を説明する必要がない、といった具合です

で、コンピュータアーキテクチャも、そうして抽象化によって現実と隔離されたレイヤーがあるわけで、その部分を教える必要はあるのではと思います

たとえば一般的なものでは、メモリが整数で番号付けされるセルの一次元配列であること、 CPU が書き換えられるメモリの領域が最大で連続nセルであること、セルの中身は整数であること、などなど

たとえばですが

上流から見るか下流から見るか、みたいな感じがする

このアカウントは、notestockで公開設定になっていません。

「秘伝のタレを作るためには、秘伝のタレとうなぎを使います」とか再帰

まあこれだけだとブートストラップ問題が発生するけど

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

そうして基底ケースと帰納段階と羃等性を説明できる